1. The question nobody asks: what does the 5G in RedCap actually mean?

When 5G RedCap gets discussed – in press releases, product sheets, industry articles – the conversation almost always focuses on what RedCap does not have. Fewer antenna ports. Narrower bandwidth. Lower peak speeds. The messaging frames it as a stripped-back version of something bigger. And that framing, while accurate in a hardware sense, completely misses the more important point.

The 5G in 5G RedCap is not just a label. It is not marketing borrowed from the full 5G NR spec to make a modest LTE replacement sound more impressive. It is a precise architectural statement. A RedCap device is a genuine 5G New Radio device operating on a genuine 5G Core network. That distinction – what type of 5G it runs on, and why that was a deliberate design choice by 3GPP rather than a technical shortcut – is what separates RedCap from every previous IoT cellular standard.

To understand why that matters, you first need to understand the difference between the two types of 5G that exist in the real world – and why that difference is causing live connectivity failures for IoT deployments right now.

2. What 5G was always meant to be – and why it took so long

When 3GPP began work on 5G through Release 15 (completed 2018) and Release 16 (2020), the technical ambition went far beyond faster phones. The three pillars of the 5G vision were eMBB (enhanced Mobile Broadband – faster speeds), URLLC (Ultra-Reliable Low Latency Communications – for critical industrial and safety applications), and mMTC (massive Machine Type Communications – for high-density IoT). The architecture designed to deliver all three was the 5G Core (5GC), sometimes called the Next Generation Core.

The 5G Core is a cloud-native, microservices-based architecture. Functions like authentication, session management, policy control, and subscriber data management are separated into independent network functions communicating via standardised APIs. It is a fundamental departure from the monolithic, hardware-centric 4G Evolved Packet Core. The 5G Core is what makes network slicing real, what enables true URLLC, and what provides the policy framework for managing millions of IoT devices efficiently.

The problem was commercial timeline. Building a full 5G Core and deploying it nationally takes years. Operators needed to launch 5G products to consumers before that work was complete. So the industry standardised a transition mode: 5G Non-Standalone (NSA), which uses 5G radio access technology bolted onto an existing 4G core. It delivered the bandwidth gains consumers wanted. It required far less core network work. And it could be deployed quickly.

The result is that the majority of 5G deployed in the UK and globally through 2021-2024 is 5G NSA. The speeds are real. But the network core is still 4G, and the features that define 5G’s industrial and IoT potential – slicing, URLLC, proper mMTC support, and the RedCap device category itself – cannot exist on NSA. They require the 5G Core. They require 5G Standalone.

3. The 5G NSA dependency problem: why no 4G means no connection

This is where theory becomes a live operational problem. 5G NSA works by using 5G New Radio frequencies for data throughput while relying on a 4G LTE base station as the anchor for signalling, control, and session management. The technical term is Dual Connectivity – the device is simultaneously connected to both a 5G gNB and a 4G eNB, with the 4G eNB acting as the master node. If the 4G anchor disappears, the 5G NSA connection collapses with it. There is no 5G NSA without 4G.

This dependency has been largely invisible in most deployment scenarios because 4G coverage in the UK is extensive and 5G NSA has typically been deployed on top of good 4G infrastructure. But as 5G SA rolls out – particularly in newer coverage areas, industrial zones, rural locations served by dedicated 5G infrastructure, and venues or sites built around 5G SA from the outset – there are increasingly locations where 5G SA signal is strong and 4G LTE signal is weak or absent.

In those locations, a device that cannot access 5G SA has nowhere to go. It cannot use 5G NSA without a 4G anchor. It cannot use 4G because coverage is insufficient. The result is no connection at all, even though 5G coverage exists at the site.

Why routers that support both SA and NSA are still affected

It is a common and understandable assumption that a router advertising both 5G SA and 5G NSA support has the problem covered – it will simply use whichever mode is available. This is correct at the hardware level. The router modem will attempt SA if available and fall back to NSA if not, or vice versa. But the router cannot override what the SIM is provisioned for.

When the router attempts to register to a 5G SA network, the network checks the SIM subscription profile in its UDM (Unified Data Management). If the profile does not include 5G NR access, the registration is rejected. The router then attempts 5G NSA – which requires that 4G anchor. If 4G is not available, it attempts LTE alone. If LTE is not available either, the device sits with no connection. The router’s dual-mode capability is irrelevant once the SIM becomes the limiting factor.

The practical checklist before any 5G deployment therefore needs to include not just “does this router support 5G SA?” and “is there 5G SA coverage here?” but – critically – “is this SIM provisioned for 5G SA on the networks available at this location?” All three must be true simultaneously for 5G SA to work.

4. 5G SA: the architecture that RedCap is built on

5G Standalone (3GPP Option 2) means a device connects directly to a 5G gNB (base station), which communicates with a 5G Core. There is no LTE anchor, no 4G EPC involvement, no dual connectivity with legacy infrastructure. The entire session lifecycle – registration, authentication, policy enforcement, data session management – happens within the 5G architecture from start to finish.

The 5G Core’s key functions relevant to IoT include the AMF (Access and Mobility Management Function), which handles registration and mobility; the SMF (Session Management Function), which manages data sessions and interacts with the UPF (User Plane Function) to steer traffic; the PCF (Policy Control Function), which enforces QoS and charging policies; and the UDM (Unified Data Management), which holds subscriber profiles including what access technologies and network slices a device is allowed to use.

This matters for IoT because the 5GC supports network slices – logically independent, virtualised portions of network infrastructure with their own QoS guarantees, latency characteristics, and security policies. An operator can create a slice for critical infrastructure with guaranteed low latency, a different slice for mass-market IoT sensors, and another for enterprise private networking. RedCap devices are designed to operate within this sliced architecture.

Compare this to 5G NSA, where the architecture beneath the 5G radio is still the 4G EPC. Network slicing does not exist at the core level. QoS is managed by LTE-era bearers. Device policy is enforced by the HSS (4G subscriber management), not the UDM. RedCap cannot exist on this infrastructure because the device category itself – along with the specific signalling procedures and QoS framework it uses – is defined for the 5G Core only.

5. Why RedCap requires 5G SA – not NSA, not LTE

3GPP Release 17, ratified in 2022, defines the RedCap (Reduced Capability) NR device category. The specification is clear: RedCap UEs operate on 5G NR and require a 5G Core. This is not a contingent requirement or a recommendation. It is a specification boundary. RedCap is a 5G SA technology by definition.

What RedCap reduces – and what it keeps

The reductions in RedCap are carefully chosen to lower hardware cost and power consumption without compromising the fundamental 5G SA feature set. The key reductions are: maximum bandwidth reduced from 100 MHz (FR1) to 20 MHz; receive antenna count reduced to one or two (from up to four); MIMO layers reduced accordingly; peak downlink speed approximately 150-220 Mbps; peak uplink approximately 50-100 Mbps. Optional power-saving features include RRC inactive state enhancements and extended Discontinuous Reception (eDRX).

What RedCap keeps is everything that makes 5G SA meaningful: native registration to the 5G Core, access to network slicing, 5G QoS flow management, support for the 5G security architecture including SUPI/SUCI privacy enhancements, and operation on 5G NR frequency bands where 5G SA offers genuine coverage and capacity advantages over LTE.

Release 18 advances RedCap further

Release 18 (2024) introduced enhanced RedCap (eRedCap), targeting even lower complexity devices with peak speeds in the 10-50 Mbps range. This begins to overlap with what LTE Cat M has covered, but on 5G SA architecture. The 3GPP roadmap is clear: LTE-based IoT device categories will not be further developed. RedCap and eRedCap, both native 5G SA technologies, are the forward path.

6. The wider impact of 5G SA on IoT beyond RedCap

RedCap is the most visible IoT story in 5G SA right now, but it is one part of a much broader shift that 5G SA enables for connected devices and industrial systems.

Network slicing: the end of one-size-fits-all connectivity

The single most transformational capability 5G SA brings to IoT is network slicing. Today, all devices sharing a cell site compete for the same radio and core resources. A streaming phone, a smart meter, a vehicle telematics unit, and a factory safety sensor all sit in the same queue. The network does its best to prioritise based on QoS class identifiers, but there are no hard guarantees.

With 5G SA slicing, an MNO can carve out logically independent network slices with dedicated resources and guaranteed service levels. A utility company running smart grid infrastructure can negotiate a private slice with committed latency under 10ms and guaranteed bandwidth, completely isolated from consumer traffic. A manufacturer running AGVs can guarantee their control traffic never degrades regardless of what else is happening on the macro network. These commitments are enforceable at the architecture level, not just at the policy level.

Private 5G SA networks

5G SA is the foundation for private cellular networks that deliver on the promise. Private LTE has existed for years, but private 5G SA provides cloud-native architecture that integrates with enterprise IT systems, native slicing that allows multiple applications to share the same infrastructure with service isolation, and a device ecosystem that now includes RedCap – enabling lower-cost endpoints alongside high-performance ones. Manufacturing, logistics, ports, mining, healthcare campuses, and large-scale outdoor infrastructure are all active early adopters of private 5G SA in the UK and Europe.

Massive IoT and connection density

The mMTC pillar of 5G SA is designed to support connection densities up to 1 million devices per square kilometre – a figure that reflects the long-term trajectory of IoT in smart cities, smart buildings, industrial floors, and infrastructure monitoring. The 5G Core handles massive device populations more efficiently than 4G, with better support for dormant devices, more granular policy management, and a security framework that scales without the vulnerabilities that accumulate in older protocols.

5G SA and the edge

5G SA’s User Plane Function (UPF) can be deployed close to devices – at the edge of the network or on-premise. This enables Multi-access Edge Computing (MEC) architectures where data is processed locally rather than routed back to a central cloud, reducing latency and backhaul costs. For IoT applications involving video analytics, real-time monitoring, or time-critical control, local UPF deployment with 5G SA changes what is architecturally possible in ways that LTE cannot match.

7. What this means in practice: devices, SIMs and deployments

The architectural clarity of RedCap being a genuine 5G SA technology has significant practical implications that the industry is still catching up with.

The SIM provisioning gap

A SIM – or more precisely, the subscription profile associated with a SIM’s IMSI – must be provisioned for 5G NR SA access by the home network’s subscriber management system (the UDM in 5G SA terminology). This is not automatic. Many IoT SIMs currently in the market were provisioned against 4G HSS infrastructure, with subscription profiles that authorise access to LTE only. Even if the physical SIM is eUICC-capable and the modem in the router supports 5G SA, if the subscription profile does not include 5G NR access, the network will reject the 5G SA registration attempt and the device falls back to LTE.

This is compounded for roaming SIMs, where the visited network’s 5G SA access is governed not just by the SIM’s home profile but by the roaming agreements between the home network or MVNO and the visited MNO. 5G SA roaming agreements are still being established across the UK and European operator ecosystem, and many IoT MVNO products have not yet completed this work for all their network partners.

The release timeline in context

8. The opportunity: why 5G SA is the IoT inflection point

For twenty-plus years, cellular IoT has operated within a fundamental compromise: the network was designed primarily for human voice and data use, and IoT devices were accommodated rather than catered for. LTE Cat M and NB-IoT moved the needle for low-power, low-data applications, but the core network infrastructure remained the same 4G EPC designed for smartphones.

5G SA changes this at the architectural level. For the first time, the network core was designed with machine communications as a primary use case, not an afterthought. The service-based architecture of the 5G Core, the network slicing framework, the UPF’s flexibility, and the RedCap device category are all evidence of a standards process that took IoT seriously when designing the next generation of infrastructure.

RedCap is the most immediately tangible expression of that intent. A device at a commercially viable price point – significantly below full 5G NR modules – operating natively on an architecture that offers slicing, proper QoS guarantees, low latency, and a security framework built for scale. For industries that have been waiting for cellular connectivity to step up – industrial automation, smart utilities, intelligent transport, healthcare monitoring, building management – 5G SA and RedCap together represent the platform they have been waiting for.

The practical work now is making sure the full stack is ready: not just devices, but SIM provisioning, roaming agreements, network coverage, and the systems integration work that turns architectural capability into deployed, working IoT infrastructure. That work is underway. The foundations are solid. And the 5G in 5G RedCap is the most precise two characters in the IoT acronym landscape – because it means exactly what it says.