5G private networks show potential for a wide range of diverse applications. Engineers can implement features to address the requirements of markets such as manufacturing and non-terrestrial networks.
5G private networks embrace a wide range of diverse applications, each requiring a different blend of technical features and capabilities. A private network can be built from a customizable set of baseline technologies comprising a silicon platform, layer 1 PHY, and layers 2 and 3 protocol stack software. Such customization enables systems to address vertical use cases defined in the 5G 3GPP specifications or extend their capabilities further than these where applicable.
Why should engineers developing private networks consider 5G? How do they need to approach their radio access network (RAN) design, depending on the application they’re addressing?
Private 5G network requirements
3GPP defines 5G based on three key use cases:
- Enhanced mobile broadband (eMBB);
- Massive machine type communications (MMTC);
- Ultra-reliable and low latency communications (URLLC).
For applications using 5G private networks, the main area of interest is often in URLLC. For manufacturing and industrial IoT (IIoT) use cases, high reliability is essential to avoid expensive downtime. Low latency is just as important, for example, in industrial automation on a production line or for self-driving trucks or robots in a distribution warehouse. Reduced capacity (RedCap) systems, introduced in 3GPP Release 17, can reduce the cost and power of devices connected to a base station to support large numbers of sensor devices.
If we consider satcomms as another transport network, then eMBB will enable satellites to handle video over 5G, potentially at the edge of existing networks to support traffic offload applications, or to fill in gaps in coverage. For IoT applications, the MMTC capability will enable connectivity via satellites for remote locations and connected cars, ships or trains.
The 3GPP standards provide capabilities aimed at these kinds of vertical applications. For example, 3GPP Release 17, planned for June 2022, adds specific new enhancements both for non-terrestrial networks (NTN) and for URLLC in industrial IoT applications.
3GPP Release 18, due in 2024, will add more capabilities, including more enablers for factories and connected IoT devices, and enhancements in radio resource control (RRC) for NTNs. Not all commercial devices will, however, support these features. For many use cases, engineers will want to evaluate whether going beyond the 3GPP standard enables them to better meet their requirements or create a differentiator.
Manufacturing and IIoT
The manufacturing sector is a major market for private LTE/5G networks, both now and in the future. Analysys Mason forecasts that the sector will account for more than 40% of private LTE/5G network expenditure in 2026, helping manufacturers to increase automation and efficiency.
3GPP is working to include capabilities aimed at industrial applications in the 5G standard. Indeed, Release 16 includes specific support for non-public or private networks, as well as integrating 5G with the IEEE 802.1 specifications for Time Sensitive Networking (TSN). These are important for many industrial and manufacturing applications.
Private network support includes self-assignment of network IDs within the private network or coordinated ID assignment where globally unique IDs can be allocated. These IDs enable network selection and reselection, overload control, access control, and barring, giving the private network owner full control over security and network resource usage.
Adding TSN capabilities enables communication with high availability and reliability features devices and a deterministic latency. Supporting strict synchronization is important for precision control, accuracy, and improvement in process speed. These features broaden how 5G private networks can be used in industry and manufacturing, particularly as the shift to Industry 4.0 adds further demands.
Of course, industrial applications aren’t just about production lines and machine tools. A smart factory can include robots handling multiple tasks, self-driving vehicles, and augmented reality (AR) headsets for employees. All of these add new demands for the bandwidth, reliability and low latency offered by 5G — with a private network the most dependable way to deliver these capabilities.
Non-terrestrial networks
For NTN, particularly satellite, we need a system that can handle issues such as higher latency, high levels of interference, and multiple parallel channels. These include enhancements such as increased timer values to handle larger latencies and enhanced uplink channel scheduling, and random-access channel access procedures. One of the challenges is a large Doppler shift in frequency that varies over time due to satellite movement. To compensate for this Doppler shift, each device on the network must calculate its own frequency adjustment. This requires changes to timing relationships, the Hybrid Automatic Repeat Request (HARQ), and uplink synchronization.
Satellites incur longer propagation delays than many other devices, due to the much longer distances involved. This can make it difficult to achieve the low latencies associated with 5G, which can be as low as 1 msec. To maintain a subjectively good user experience, engineers may need to take a network-level view, ensuring content is distributed in advance as close as possible to the consumer, thus keeping overall latency as low as possible. For example, they can evaluate the use of geostationary, mid-Earth or low-Earth orbit satellite networks and whether a transparent (bent pipe) or regenerative payload option makes sense.
NTNs have been specifically included in the 3GPP 5G RAN standards from Release 15 onwards. 3GPP Release 17 assumes that a GPS/GNSS location capability is present to enable the frequency adjustment calculation for Doppler shift, but the GNSS signals may be weak or even absent at times, making this difficult.
3GPP is considering the regenerative payload option for standardization in Release 18 with three potential design options, including Open-RAN architectures. These are:
- full gNobeB on board,
- gNodeB Centralized Unit (gNB-CU) on the ground, gNodeB Distributed Unit (gNB-DU) on board,
- gNB on the ground, LLS (Low layer split), RU (Radio Unit) on satellite.
All of these options have advantages and disadvantages that network designers must consider. These options include substantial modifications to the protocol stack compared to a terrestrial network.
Customizing 5G systems
Private networks in specific applications add new demands. By their very nature, they permit system designs that step outside the regular network standards — if you are building a closed, private infrastructure, you can make your own decisions where to extend the envelope.
In practice, network engineers are unlikely to have the capabilities, time, or inclination to re-invent the wheel, particularly as the complexity of 5G makes building a dedicated private network a non-trivial task.
The best answer will often be to start with a system that includes hardware and software that can get close to the target requirements, and then customize the features as needed. Engineers can undertake this for themselves or work with third parties who can provide the design resources needed. This means that when they are starting out on a new design, engineers can aim high and work towards their ideal system, rather than having to settle for the closest match from off-the-shelf COTS products.
Open RAN
The shift to open specifications increases flexibility for design engineers, letting them partition their application across different hardware and software blocks in the way that suits best, as well as to pick “best of breed” subsystems for each part.
One of the biggest trends is towards an Open RAN architecture, spearheaded by the O-RAN Alliance. This aims to make the RAN more open, scalable, and interoperable; standard specifications enable a flexible, multi-vendor network.
Figure 1. The O-RAN logical architecture shows how the RAN functions are split into separate components. Source: O-RAN Alliance.
Figure 1 shows the logical architecture of the O-RAN model, with the gNodeB split into central units (CU) and radio units (RU). Additional distributed units (DU) can be added as required. With the gNodeB segmented this way, rather than a single monolithic block, it can be easier to adapt to the specific requirements of private networks. For example, one part of a system may require ultra-low latency while another does not. This split model gives engineers the flexibility to allocate RAN resources accordingly.
For industrial and manufacturing applications, the O-RAN architecture provides new technical capabilities. For example, external data from an industrial control panel can be sent as an input to the service management and orchestration (SMO) platform and used by an AI/ML model to prioritize important data over low priority traffic (Figure 2), thus improving Quality of Service (QoS).
Figure 2. The O-RAN high-level architecture shows how external system data can be fed to the SMO framework. Source: O-RAN Alliance
For the satcom market, the O-RAN architecture provides flexibility in size, weight and power of the non-terrestrial equipment using the alternative architectures mentioned above.
In practice, the O-RAN architecture enables multiple different ways of splitting the components across the available hardware and software resources. Figure 3 shows three possible options for splitting functions in the RAN. Option 2 creates a DU that includes the radio interface. This option is used mainly to separate the control and user-plane functionality between the CU and DU. Use cases focus on non-real time applications with increased latency and reduced bandwidth.
Figure 3. Multiple software modules can be split in different ways across the available hardware processing resources, to meet the demands of particular applications.
Option 6 is a MAC/PHY split where the MAC resides with the CU and the RU includes the full PHY stack. It’s standardized by the Small Cell Forum 5G network Functional Application Platform Interface (5G nFAPI) specifications. This split is useful where only centralized scheduling is required, it also adds supports for multi-vendor RUs with different radio capabilities.
Standardized by the O-RAN Alliance, Option 7.2 remains the most popular split. This option moves most time-domain PHY functions that can be virtualized out of the radio unit and into the DU, leaving only the beamforming and FFT functions in the RU. This split is works well for URLLC and supporting carrier aggregation but requires a fronthaul that supports time-synchronous networking for eCPRI fronthaul.
For many applications, 5G private networks hold the promise of reliable, high-performance connectivity that can provide the required low latency and high data rates. By customizing the 5G RAN, going beyond the 3GPP standards, engineers can build systems that meet their requirements accurately and efficiently.
Paul Moakes, PhD CEng FIET, is Chief Technology Officer at CommAgility. He has previously held positions at Motorola and Blue Wave Systems. He is co-inventor of two patents in the field of MicroTCA and AdvancedMC. He holds a PhD in Electrical and Electronic Engineering from Sheffield University and a First Class Honours degree in Electronic Communications and Computer Systems Engineering from Bradford University.
