Developing and deploying a laboratory infrastructure to support testing 5G and open radio-access network (Open RAN) systems can present a daunting and complex task. Prior to Open RAN, this task was only possible by engaging directly with the large network system vendors. Since then, several open-source projects and organizations have developed materials based on 3GPP and O-RAN Alliance specifications. Those tools and resources make it possible to create a complete 5G deployment, spanning from the mobile core to RAN, providing invaluable resources for engineers.
Open-source activities play an important role because they enable rapid prototyping and verification of the specifications. Those specifications could still be in draft form. Many standardization groups have devised practices and policies to promote the use of open source. These groups include the Internet Engineering Task Force (IETF), guidelines and practices around “rough consensus and running code,” and the Open Software Community (OSC) of the O-RAN Alliance, which have implemented formal programs.
Indeed, one of the most complex aspects involving open-source projects and components in a 5G test lab is where to begin. In this article, we will discuss some fundamental components that engineers can use as starting blocks and explain how open-source software can support Open RAN testing.
To begin the process, you need to first understand some of the major components of a 5G network. In this case, we will generalize the core network as a single component, as multiple open-source options currently implement the core network functions required by 3GPP specifications. The 5G mobile core comprises various individual network functions that enable the services-based architecture defined by 3GPP.
Three well-known examples of open-source systems implementing the 5G core are the Open 5GS project, the free 5GC project, and the Open Air Interface 5G core network component. The former two projects are stand-alone implementations of the 5G core. At the same time, the latter is more tightly coupled with the larger Open Air Interface (OAI) project, which can also provide the RAN.
At UNH-IOL, we frequently use the Open 5GS core, which we deploy as two sets of components. First, we deploy the primary control components, including the access and mobility management function (AMF), 5G session management function (SMF), and others. Second, we deploy the user plane function (UPF), which is responsible for forwarding subscriber traffic from the RAN interfaces to the data network (e.g., the Internet). This effectively enables control/user plane separation (CUPS), with these functions deployed across separate virtual machines. Similarly, we could also implement multiple UPF instances in larger deployments to load balance the subscriber traffic. Figure 1 shows some of the logistics of this deployment in our lab.
Figure 1. The UNH-IOL has deployed this Open 5GS topology for interoperability testing of 5G network components.
From core to RAN
Once the core network is running, the next likely focus will be the RAN. Within this space, we’ll get closer to the leading edge of the open-source development efforts, depending on the directions taken within the deployment. The RAN provides an RF connection between the user equipment (UE) and the mobile core network. That’s an oversimplification, but we’ll stick with that working definition without diving into some complex topics such as handovers, support of multiple cells, carrier aggregation, and so on. Here, the most significant factor in the selection processes will likely center around the radio components, for which we have two options.
First, we could deploy a software-defined radio (SDR) based system that leverages the Open Air Interface project to provide the software and firmware to implement the complete RAN, or more accurately, a good base station. Depending on the SDR hardware selected, it might be possible to connect RF ports directly to the antenna. With care to avoid violating any licensed spectrum, an RF connection to the UE device should be possible. On that note, a lab will also need shielded chambers or RF isolation rooms, but that’s outside the scope of this article.
Another approach to implementing RAN follows the specifications from the O-RAN Alliance, where the gNodeB is disaggregated into discrete components: radio unit (RU), distributed unit (DU), and centralized unit (CU). In this space, the OAI project can provide some software, notably the DU and CU components, which then implement the Open Fronthaul interface (OFH) towards the RU. For the RU, selecting a product from a vendor is necessary because no open-source RUs currently exist.
To ensure the correct transmission of radio signals or frames, the DU and RU need to synchronize time and understand it well enough to support the OFH interface. Again, multiple architectures or approaches are possible, described as different configurations LLS-C1 through LLS-C4. In our lab, we’re currently implementing LLS-C3, with one of the fronthaul switches serving as the IEEE-1588 grandmaster clock, which provides the timing to the RU and DU. Hardware time stamping support is required for the NIC on the DU server and the ptp4l project is used to synchronize the server clocks to the network. Figure 2 shows this configuration in the lab.
Figure 2. For Open RAN, the lab uses this disaggregated topology, which takes network liming into account.
Assuming you will be using off-the-shelf UE devices such as phones, everything is ready to test, right? Well, very nearly. Thus far, a core network and a radio network have been deployed. Barring any configuration issues, the gNodeB should be registered with and connected to the core network. It should provide at least one cell on the desired 5G band for the UE to connect. The UE must authenticate with the network, which depends on the SIM card. In 5G, the authentication works “both ways,” where the UE authenticates the network, and the network authenticates the UE. Without diving through all the details, this requires the network information, i.e., some of the keys provisioned in the core network to match keys within the SIM card, thus enabling the cryptographic challenge/response to successfully complete. It is not possible (for very good reasons) to read these key values from a SIM card.
Some SIM cards are, however, programmable, typically for testing purposes. So, the last part of the laboratory hardware is a small SIM card reader/writer, along with the programmable SIMs. Fortunately, on the programming side, there are some open-source tools that let you program the network key values and the subscriber IDs into the SIM card, making it possible for the authentication to succeed. Tools we’ve used in the lab for this purpose are pysim and sysmo-usim-tool.
Using open-source tools, you can bring the UE device online with a working 5G connection in the lab. All the work here only scratches the surface of the 5G network and testing possibilities. Still, you should enable a lab with open-sourced-based resources capable of supporting more advanced features with proper configuration, such as network slicing or carrier/cell aggregation, just to name a couple of possible topics.