What is 5G? Everything You Need to Know (Part 2)

In Part 1 of our “Everything You Need to Know” article on 5G, we explored a number of basic areas: 5G’s driving factors, Non-Standalone vs Standalone 5G, the progress of 5G’s rollout, 5G coverage and the notion of public and private 5G. In Part 2 here, as I take a quick break from the hustle and bustle of MWC 2023, let’s take a deeper dive into more of the capabilities and features offered by 5G.

Interworking

It is customary for a new technology to support interworking with previous generations of technology, with 5G being no exception to this. What’s interesting about 5G is the scope of interworking that is supported.

Firstly, with respect to interworking with other cellular technologies, 4G is the main option here. In fact, due to the anticipated switch down of 2G and 3G, 4G is the only option. In particular, the 5G Core network is capable of interworking with the 4G Core network to support seamless handovers between the technologies, which would be useful if you start a call in 5G but run out of coverage; a handover to 4G will hopefully mean that there’s no service interruption. It’s also worth pointing out that there are fallback mechanisms available, generally termed “EPS Fallback” which will see the device falling back to 4G if voice services aren’t supported in the current 5G cell (in a similar way that Circuit Switched Fallback supported 4G). Finally, with some enhancements to the regular 4G Base Station, devices can use a 4G radio but still connect to the 5G Core, which is particularly useful for 4G CIoT devices.

Beyond cellular interworking, 5G can support access to the 5G Core through a variety of different access networks. Wi-Fi is the obvious one that springs to mind, which like 4G offers an Untrusted and a Trusted variant, depending on the level of control the 5G service provider has over the Wi-Fi infrastructure. What is particularly interesting about 5G and Wi-Fi interworking is the fact that even when the device is on Wi-Fi, it can still exchange control signalling with the 5G Core (it couldn’t in 4G). This means that even when the device moves to Wi-Fi, the 5G Core still has a degree of control over the device.

Perhaps what’s most compelling about 5G’s interworking capabilities is the extended set of “other” technologies that 5G can work with. Take residential access for example; with this scenario, devices can connect to the 5G Core via fixed line networks such as xDSL, Cable and Fibre. Moreover, NTN (Non Terrestrial Networks) are a very hot topic at this time, which sees a device connecting to the 5G Core by using satellites or drones instead of communicating directly with a traditional 5G Base Station.

Ultimately, this all contributes to the notion of high availability in 5G, providing subscribers with a variety of access methodologies towards the 5G Core, regardless of their location or connectivity options.

For further information on interworking, we run courses on 5G and 4G Interworking, 5G and Wi-Fi Interworking and finally, 5G Fixed Mobile Convergence.

MEC and 5G

MEC (Multi access Edge Computing) is not a technology that is exclusive to 5G; other cellular technologies such as 4G and alternative access networks such as fixed line can also benefit. The technology itself focuses on pushing compute and storage resources closer to the network edge, which in a 5G network typically means an aggregation point in the 5G RAN or even down to the cell site.

This notion of pushing compute as close to the device’s point of attachment to the network as possible has several benefits but at a high level, we’re really talking about compute offload, latency and network efficiency. If you look at many of the use cases often quoted for 5G, such as AR/VR/XR, V2X, gaming, etc., they often require access to very low latency services. Coupled with the fact they can be associated with very high data volumes, siting the compute and storage resources that they require as close to these devices as possible is a fairly obvious choice; round trip times for user data will be reduced and we can avoid pushing large volumes of traffic across the entire network. Moreover, devices can potentially be made cheaper because their compute requirements could be offloaded to MEC.

Deploying MEC in 5G however is not without its challenges. First of all, an architectural design model needs to be used. At present, there are three options that have been standardized (and others that are not standardized). These include the ETSI MEC architecture, the 3GPP’s EDGE architecture and the GSMA’s Operator Platform. Naturally, there is a degree of crossover between these approaches but moving forward, hopefully we’ll see tighter integration. The key term here is “moving forward” since at present, we’ve not seen a huge number of MEC deployments that have been commercially deployed within 5G; of those that are out there, a lot of focus is towards the lucrative enterprise market, as you might expect.

From an operational perspective, we face the prospect of a device requiring access to MEC resources as and when a MEC application needs to be created. So we have the issue of ensuring that the device is given access to geographically local MEC resources, but we must crucially also cater for devices moving. If a gaming session is started at a particular MEC location but that gaming device moves, the local MEC resources will have to move with it. Figure 2 outlines a basic scenario for MEC which sees the device accessing system or management level resources first of all, which then allocate the device localized MEC resources.

For further information on MEC, take a look at our MEC and 5G course.

Network Slicing

Network Slicing involves the creation of multiple, logical 5G networks over a shared physical infrastructure, with the fundamental goal of monetizing the 5G network. It is essential that 5G does not remain a technology solely for the consumer market (which for a long time 4G was and some would argue still is). For 5G to be a success, it must become a service enabler for a wide array of different market verticals, such as Industry, Healthcare, Agriculture, Logistics, Enterprise; the list goes on.

To achieve this level of diversification, service providers must have a tangible offering that they can take to market. That offering is the 5G Network Slice, allowing network slice customers to pick and choose exactly which characteristics they want their network slice to provide for them. The goal is to create a NEST (Network Slice Template), which will be used by network slice management systems to configure a network slice with the appropriate characteristics, in line with an appropriate SLA (Service Level Agreement).

This “a la carte” approach to building network slices may be some way off. In reality, the go-to- market strategy that mobile service providers will use may be a little more limited to begin with. For example, it might be the mobile service provider who creates the network slice first of all with a set of characteristics that target a specific market vertical, such as an Infotainment network slice targeted for the automotive market. Moreover, it’s possible that customers will share a network slice rather than have exclusive access to a network slice.

Before we see network slices being dynamically created with full control for the network slice customer, there’s a lot that must happen in 5G networks related to overall slice management and resource reservation. One key aspect is the deployment of Standalone 5G; at the time of writing, there are only about 40 operational Standalone networks, with many of them having just launched and hence, network slicing may be some way off in their technology roadmap.

Figure 3 – 5G Network Slicing

For more information on 5G Network Slicing, check out our course.

Cloud and 5G

Although the IT industry has been using cloud-based technologies for some time, the adoption of cloud for cellular is a relatively new phenomenon, perhaps because up until now the techniques used were not considered to be ready for the telco market. Regardless, the use of a more software- centric approach to the 5G architecture has become a fundamental aspect of 5G’s deployment.

Admittedly, I still view 5G from the perspective of network functions communicating with one another in order to perform a specific task or service. It’s easy to overlook the complexity of the infrastructure that makes this happen; there’s no denying the huge impact that cloud technology has had, particularly when you look at the core network, but even in relation to elements of the 5G RAN.

For 5G, we talk about the “Service Based Architecture”, the design model for creating a 5G Core. All of the controlling elements that you need to have a functioning 5G network run as software processes which rely on a shared infrastructure for providing their compute, storage and networking requirements. The point is, we move away from bespoke hardware which we saw in 2G, 3G and the early days of 4G, towards a much more flexible, scalable approach to network deployment.

For this to work, we need data centres which house the common compute, storage and networking resources. Typically, for large scale networks, this will be a private cloud deployment. However, you just need to take a quick look at AWS or MS Azure’s product lineup to see that a public cloud deployment for a 5G network is perfectly feasible. Remember too that this cloud deployment does not have to be within the core; to support MEC and O-RAN, we need cloud resources at the network edge too.

In terms of the technologies used, you will hear of network elements deployed as microservices within Linux containers, all under the control of Kubernetes. This is just scratching the surface; however, there are many, many other elements that complete the picture.

One final point to note – many service providers are opting for a “combined core” approach to their 5G deployment, which follows a gradual migration towards cloud native applications that started with 4G. Therefore, their cloud infrastructure support both a 4G and 5G Core network.

Take a look at this blog if you’d like more detail on 5G and Cloud. Alternatively, you can take a look at our Introduction to 5G and Cloud Computing course.

V2X

V2X (Vehicle to Everything) was first introduced to cellular networks with 4G, although deployment has been relatively limited. There are a number of factors which contribute to why deployment has been slow, ranging from the demand from industry (vehicles rely on sensors on the vehicle rather than input from elsewhere) coupled with the readiness of the 4G infrastructure (investment won’t be made if the business case is not there).

V2X is actually an umbrella term used to refer to a vehicle’s communication with all other entities, including other vehicles, pedestrians, traffic signals, road signs and many more. When specifying connections there are further standardized references:

• V2V (Vehicle-to-Vehicle) is the connection between all vehicles either moving or parked.
• V2I (Vehicle-to-Infrastructure) is the connection to roadway infrastructure. This ranges from traffic signals and road signs to temporary fixtures such as roadworks and construction.
• V2P (Vehicle-to-Pedestrian) is the connection to all other road users, which could be pedestrian smart phones or other devices connected to the network.
• V2N (Vehicle-to-Network) is the connection of the device to the supporting mobile network.

Note that the V2V, V2I and V2P scenarios typically involve a direct connection termed “SL” (Sidelink). The V2N relies on the cellular connection, i.e., LTE or 5G. 3GPP Release 16 in 2019 saw the introduction of NR-V2X, (New Radio V2X) allowing V2X services access to the 5GS (5G System). This included not only key support for autonomous vehicles, but also the delivery of media services to vehicles. It is worth noting that LTE-V2X and NR-V2X are not capable of communicating with each other, however they can co-exist. This enables vehicles to operate V2V LTE-V2X and N-V2X radios simultaneously, enabling backward compatibility to LTE-V2X-only devices.

Release 17 added additional NR-V2X features enhancing the V2X application layer support and Sidelink operation, as well as support for additional use-cases. 5G Release 17 also introduced MBS (Multicast Broadcast Services), which can be incorporated into the V2X data delivery mechanism.

Final Thoughts…

So far we’ve covered a total of 10 areas in relation to 5G – there’s plenty more to cover. We’ll inevitably be providing a part 3 later in the year – please feel free to contact us if you’d like to see some additional topics covered. If you are looking for 5G Core training, look no further than Mpirical, with on-demand learning for an array of telecommunications courses.