Communications
This article examines Voice over Narrowband Internet of Things Non-Terrestrial Networks (NB-IoT NTN), a standardization work item currently underway in 3GPP Release 20. An IoT technology deliberately stripped of features for simplicity must now be extended to support voice—a capability far from its original design intent. The effort responds to emerging requirements to support voice communications over NB-IoT NTN satellite infrastructure. Building on 4G-LTE based NB-IoT capability first adapted to satellite environments in Release 17, Release 20 extends this technology to address voice use cases not only for smartphones but also devices such as wearables, as well as automotive applications including satellite-based emergency voice services for vehicles.
NB-IoT was introduced in 3GPP Release 13 in 2015 as a device category for Internet of Things applications. The technology was derived from 4G and was developed in parallel with eMTC (evolved Machine-Type Communication), which represented an alternative IoT approach. NB-IoT targets use cases such as smart metering, asset tracking, and environmental monitoring where devices transmit infrequently with small data payloads.
NB-IoT is a vastly simplified and stripped down version of a 4G device. It is designed for peak data rates of only 10 to just above 100 kbps, substantially lower than conventional 4G. It can be deployed in-band with existing 4G spectrum through dedicated resource allocations which prevent smartphone LTE traffic colliding with NB-IoT traffic. The technology achieves extended coverage—up to 20 decibels better than conventional 4G deployments—through transmission repetition mechanisms, allowing connectivity in challenging radio conditions.
Two optimization approaches define NB-IoT deployment modes. Cellular IoT Control Plane Optimization (CIoT CP) conveys user data over the control plane with minimal signaling, similar to SMS. The data is sent over the Non-Access Stratum to the Mobility Management Entity. As a result, Access Stratum security is not supported for the control plane solution. This approach has achieved significant real-world deployment due to its efficiency for small, infrequent data transmissions. Cellular IoT User Plane Optimization (CIoT UP) uses conventional user plane bearers for applications requiring higher reliability or throughput. Both optimization approaches allow data to be sent at an early phase during initial access, avoiding the need for significant protocol configurations before data transmission.
Both approaches incorporate extensive power-saving mechanisms. Extended discontinuous reception (eDRX) cycles allow devices to sleep for extended periods without monitoring for incoming data. Simplified protocol stacks reduce processing overhead compared to full 4G implementations. These features enable NB-IoT devices to operate for multiple years on a single battery charge, a critical requirement for deployed IoT applications such as remote sensors where battery replacement is impractical.
However, NB-IoT does not support connected mode mobility, the capability to maintain an active connection while moving between cells. This reflects NB-IoT''s design for stationary or slowly-moving IoT devices. The absence of connected mode mobility has implications for applications requiring sustained connectivity across coverage boundaries.
NTN standardization in 3GPP began with a Study Item in Release 16, progressing to formal standardization work in Release 17. Release 17 focused primarily on NR NTN but also included NB-IoT NTN development as a separate work item. A foundational Release 17 design decision was device self-synchronization: NR and IoT NTN devices acquire their position via GNSS (Global Navigation Satellite System) and calculate expected signal propagation delays and Doppler shifts based on satellite ephemeris data broadcast by the network. This approach provides flexibility, supporting diverse satellite orbital altitudes: LEO (Low Earth Orbit, 200–1,600 km), MEO (Medium Earth Orbit), and GEO (Geostationary Earth Orbit, 35,786 km).
Both eMTC NTN and NB-IoT NTN were standardized in Release 17. NB-IoT NTN has become increasingly popular due to its relative simplicity of implementation compared to NR NTN. Currently, chipset vendors have begun supporting NB-IoT NTN, and operators have initiated network deployments. NB-IoT NTN thus became the first widely available form of satellite-based 3GPP cellular connectivity. NB-IoT NTN is only supported over 4G Evolved Packet Core (EPC).
Release 19 also extended NB-IoT NTN with capabilities supporting terrestrial network-NTN integration. Terrestrial networks can now broadcast assistance information to devices to facilitate transitions between terrestrial and satellite coverage. Redirection, which is based on network-initiated messages, is now supported from a terrestrial network to a non-terrestrial network.
Additionally, Public Warning System (PWS) notifications, which alert devices of imminent hazards, are now supported over NB-IoT NTN, aligning functionality with terrestrial 4G and 5G deployments. NB-IoT NTN support has also expanded across a range of spectrum bands, further enabling deployment flexibility.
The Release 20 decision to add voice support reflects practical deployment considerations. First, NB-IoT NTN is already being deployed in commercial networks to support IoT use cases, with growing chipset availability. This deployment precedes NR NTN, which remains later in its deployment cycle. Addressing voice requirements now supports already-operational infrastructure rather than deferring to future NR NTN maturity.
Second, NB-IoT is proving to work well in the satellite environment, demonstrating suitability for voice communications over these challenging links.
Third, standardized voice capability extends the addressable market for deployed NB-IoT NTN infrastructure, creating additional revenue opportunities for operators offering satellite connectivity services.
Adding voice capability to NB-IoT NTN involves several technical constraints.
Geostationary access focus: The primary use case for voice over NB-IoT NTN is geostationary (GEO) satellite access. GEO satellites present distinct challenges compared to terrestrial networks. Propagation delays are very significant—exceeding 250 milliseconds for GEO compared to less than a millisecond for terrestrial networks—which impacts real-time communication and call setup. Additionally, NB-IoT NTN lacks connected mode mobility support, meaning active voice calls cannot transition between satellite coverage areas. However, this architectural limitation actually simplifies network design and procedures for GEO access, where satellites maintain fixed positions relative to ground locations and devices do not transition between cells during an active call. The need for mobility between cells is expected to be very rare, as the cells in a Geostationary deployment may have diameters that can exceed 100 km.
Missing protocol features: NB-IoT was never designed to support voice. During its standardization, several features from 4G were deliberately omitted to simplify the NB-IoT device and reduce implementation complexity. As a result, NB-IoT''s original specification did not include several features necessary for voice support. Semi-persistent scheduling mechanisms, which allocate repeating transmission and reception opportunities without per-transmission scheduling requests, and which are key for voice transmission, were not specified. Robust header compression for efficient transmission of IP, UDP, and RTP protocol headers was not standardized as payload was reasonably large compared to the headers. Emergency call procedures, allowing emergency communications without prior network registration, had not been defined. These features must be specified for Release 20.
Data rate constraints: With the tight link budget of the geostationary NB-IoT NTN scenario, data rates of below 10 kbps impose hard constraints on voice quality. Conventional 4G and 5G voice codecs produce bitstreams that would consume excessive bandwidth on NB-IoT channels. Voice support requires specialized low-bitrate codecs, in order to support speech audio quality comparable to that of terrestrial voice services.
An early Release 20 decision addressed whether to implement voice over the control plane or user plane. The approaches can be seen in Figure 1. The CIoT Control Plane approach is the most widely deployed solution for NB-IoT data, but adapting it to support voice would require substantial modifications to control plane architecture and signaling procedures, with cascading implications for network implementations. The CIoT Control Plane solution does for instance not support reconfiguration of the device and it has only limited support for Quality of Service management due to all traffic being carried over the same control plane radio bearer.
Alternatively, user plane deployment would mirror conventional 4G voice procedures, which use dedicated user plane radio bearers. The user plane approach requires significantly less standardization and implementation changes compared to the control plane approach. Finally, 3GPP selected the user plane approach, prioritizing reduced complexity and alignment with existing voice procedures.
Figure 1. A) Showing the CIoT User plane path for voice over NB-IoT NTN, B) showing the CIoT Control Plane path for voice over NB-IoT NTN.
Semi-Persistent Scheduling (SPS) addresses the challenge of allocating transmission opportunities for voice frames. Conventional NB-IoT operation requires explicit scheduling grants for each data transmission, introducing delay and signaling overhead. Semi-persistent scheduling allows a device to receive and transmit data without the need for constantly being scheduled. Under SPS, a device is allocated a recurring pattern of transmission and reception opportunities—for instance, every 40 milliseconds. Once configured, the device can transmit and receive voice frames at these moments without requesting additional grants. While a lot of design decisions of SPS mirrors that of 4G LTE, some changes have had to be made regarding how the SPS is activated and de-activated.
Given NB-IoT''s constrained data rates, efficient transmission of voice frames requires header compression. RoHC (Robust Header Compression) removes redundant information from IP, UDP, and RTP protocol headers and exploits packet pattern predictability to achieve compression. This is specified in Release 20 to reduce protocol overhead, making voice transmission feasible within geostationary NB-IoT NTN's data rate envelope.
GEO satellite uplinks present weak link budgets due to the extreme 35,786 km propagation distance. To close this link budget gap, Release 20 permits device transmit power up to 37 dBm (approximately 5 watts)—substantially higher than typical NB-IoT devices. This power level is necessary to establish reliable uplinks to geostationary satellites.
Release 20 defines procedures for emergency calls without prior network registration. Emergency access allows a device to connect to a network it is not registered to, enabling contact with emergency services. This capability is standard for voice-enabled technologies but had not been specified for NB-IoT.
While above approaches have already been agreed upon, several design choices remain under active discussion.
Voice access control and procedures: Open issues include which voice-related features from 4G and 5G must be supported in Release 20 devices and networks. This involves assessing implementation complexity—which was originally a design objective of NB-IoT—versus the features necessary for voice use cases. Specific examples include whether voice access barring procedures and counter check procedures are needed for NB-IoT voice support. The voice access barring procedures are introduced for normal 4G LTE and 5G NR to manage access attempts to ensure that a cell is not overloaded. While simplified procedures have already been introduced for NB-IoT, these are mainly targeting IoT traffic. 3GPP is discussing enhancements to align with 4G LTE and 5G NR. Counter check procedures are used to monitor whether packet insertions have occurred during a connection and were not introduced for NB-IoT, as NB-IoT was introduced to only support a small amount of data.
Voice codec selection: NB-IoT NTN's limited bandwidth requires a voice codec operating at bitrates far below those of existing 4G and 5G voice codecs. Recent advances in AI-based speech coding have changed what is achievable at such rates, with wideband neural codecs delivering clean-speech quality comparable to AMR-WB at 12.65 kbps (the voice codec widely used for terrestrial HD Voice) at less than a tenth of the bitrate.
To support Voice over NB-IoT NTN, 3GPP has since begun standardizing an Ultra Low Bitrate speech Codec (ULBC) which will operate at two target bitrates, 1.0 kbps and 1.4 kbps. The ceiling data rate envelope of 10 kbps applies only under favorable link conditions: at the edge of a GEO satellite cell, the sustainable data rate may drop to a few kbps. Once protocol headers and retransmission margins are accounted for, roughly 1–2 kbps may remain for the speech audio payload itself. The two target bitrates sit within this budget, offering a quality-preferred operating point as well as a more robust one with additional link margin. As the candidate solutions are expected to be AI-based — a first for 3GPP voice codec standardization — ongoing discussions address design constraints new to speech codec standardization, such as computational complexity and memory limits for neural models, alongside audio bandwidth, algorithmic delay, and training data. Low complexity will be particularly important for the selected codec, given Voice over NB-IoT NTN use cases such as wearables and constrained applications.
Terrestrial-satellite integration: Devices may transition between terrestrial 4G networks and NB-IoT NTN coverage. A key open issue is how to integrate voice over NB-IoT NTN with terrestrial networks (4G, 5G, and future networks) in a simple and efficient manner. Assistance information may be broadcast by terrestrial networks to facilitate rudimentary mobility procedures, allowing devices to transition to NB-IoT NTN coverage when terrestrial service is unavailable.
Voice over NB-IoT NTN in Release 20 extends satellite IoT capability to voice use cases through pragmatic design decisions. The standardization effort is bounded by explicit constraints reflecting both technical feasibility and implementation considerations. Voice support is limited to GEO satellite access, where the stationary coverage model avoids the complexity of supporting connected mode mobility. Voice service quality will be lower than terrestrial services due to geostationary NB-IoT NTN's sub-10 kbps data rate envelope and the long propagation delays and frame losses inherent to the GEO satellite link. Device implementation burden is reduced by selecting the user plane approach, which leverages existing 4G voice procedures.
The work remains ongoing within 3GPP. Several open issues continue to be addressed, including confirmation of required voice control procedures, voice codec selection, and procedures for integrating voice over NB-IoT NTN with terrestrial networks. First published standards are targeted for early 2027.
Release 20 represents the seventh release targeting enhancements to NB-IoT—a technology that remains relevant more than a decade after its initial introduction in Release 13. This continued evolution demonstrates the longevity of well-designed foundational technologies and their capacity to address emerging use cases far beyond their original scope.