“Inside the hall in Barcelona it’s like ‘Star Wars’. Outside on the streets of Barcelona it’s like the ‘bar scene’ from Star Wars…”
As expected “5G” cropped up pretty much everywhere at MWC…
The term is definitely being overused – especially when it comes to flying cars, which face some fairly fundamental design and regulatory challenges that 5G or even 6G aren’t going to help with. There are also ambitious statements being made about its relevance to robotics, with one vendor making the thought-provoking claim that “Cloud Robot is the Killer Application for 5G”.
Let’s bring this back to ground level by considering that 5G network architecture is intended to provide:
- Massive capacity: 1,000 times more than 4G
- Super-fast data rate: 100 times more than 4G
- Ultra-low latency: Less than 1 millisecond
Given that demand for wireless connectivity will continue to increase remorselessly this is great, but the reality is not quite so simple…
5G comes with its own set of problems
Legacy technology will continue to exist and need to be supported.
Even the most optimistic estimates project that 5G will not be more than 55% of traffic by the end of 2024. The rest will use existing 4G, 3G and even 2G infrastructure. All of that infrastructure will need to be maintained.
5G coverage is harder to provide.
5G will use frequencies that aren’t used by 2G, 3G & 4G. They are unused for a reason. They support high bandwidth, but also can be blocked by rain, snow, dust and vegetation. Suddenly my 5G powered flying car ceases to be attractive, and a lot of IoT use cases that assume continuous high bandwidth connectivity need to be rethought…
5G will require a lot of hardware, everywhere, to work.
The frequencies used mean that the effective range is measured in tens of meters, not kilometers. This in turn implies 10-100x as many base stations to cover an area, which obviously implies a significant capital expenditure by someone.
We foresee 5G creating both challenges and opportunities in the following areas:
Management of complex legacy hardware and software stacks
Sooner or later the existing 3G/4G stuff will need to be replaced. In some cases hardware vendors will simply stop supporting the original equipment. In others the open source projects that are used by components will have ceased to be hubs of activity and end up more like abandoned shopping malls, creating support problems. This presents an opportunity for vendors to sell Telecom Application Server type products to virtualize legacy functionality. While it may seem absurd to contemplate selling 3G charging products in 2022, consider that drastic changes in pricing could plausibly lead to replacement costs being less than the annual maintenance cost of a system designed before NoSQL/NewSQL. Here at VoltDB we routinely see customers experience positive sticker shock when they compare our TCO with legacy alternatives.
Massive charging and policy volumes
In the 5G universe charging will almost always be in real time, even for post paid customers. This means that we’ll no longer be able to grab yesterday’s CDRs and create billing records. If we can’t rate and charge as the event is happening we won’t be able to do it at all. This in turn means that High Availability and claims of ‘five nines’ goes from being largely aspirational to having real, measurable commercial impacts. Since handling each record individually is inherently 10x – 100x more expensive than doing it as part of a huge batch we can thus expect a big increase in charging type applications, even if they are ‘after the fact’.
IoT devices as customers and possibly even suppliers.
The tenfold increase in base stations per square km needed by 5G, and their need to be connected to ‘the internet’, poses a huge challenge to CSPs. The paperwork burden alone will be daunting. This will create significant incentives to persuade consumers to accept 5G hardware into their homes by (say) building base stations into IoT devices such as smart fridges, cameras etc. These devices would this be both consumers of the 5G network and integral components of it, leading to negative charging scenarios.
UDSF – The “One Big Database”
One of the more interesting ideas in 5G is that of the UDSF – the ‘Unstructured Data Storage Function’. The idea behind this is that network components might be 100% stateless, like a HTTP server. So every single request will result in at least two round trips to ‘somebody else’s’ database, one to retrieve the state, and a second to update the state. This means that in order to scale you just need to create swarms of new stateless components instead of larger, stateful components and wrestle with the related issues of partitioning / sharding traffic. The downside is that this creates demanding expectations for the UDSF, as in addition to consistently responding in around 1ms it needs to be able to scale elastically without downtime.