No-Transmit Zone

Description

A No-Transmit Zone (NTZ) is a regulatory and technical concept in 3GPP, particularly relevant for spectrum sharing and radio resource management. It defines a specific geographic region, or in some contexts a set of time-frequency resources, within which a User Equipment (UE) or a base station (gNB/eNB) is not allowed to transmit radio signals. The primary mechanism for enforcing an NTZ is through network-controlled policies delivered to the UE. The network, typically via the Access and Mobility Management Function (AMF) or the Policy Control Function (PCF), can provision the UE with NTZ configuration information, which includes geographic coordinates (e.g., a polygon or circle) and associated conditions.

Architecturally, NTZ management involves several core network functions. The Network Data Analytics Function (NWDAF) or other network exposure functions may determine the need for an NTZ based on external inputs, such as a spectrum access system (SAS) or regulatory database indicating protected incumbent users (e.g., fixed satellite service earth stations). This information is conveyed to the Policy Control Function, which formulates appropriate policies. These policies are then sent to the UE via the Access and Mobility Management Function as part of the UE configuration update procedure or initial registration. The UE's protocol stack, specifically the Radio Resource Control (RRC) layer, interprets these policies and enforces them by prohibiting transmissions when the UE's location (determined via its own GNSS or network-based positioning) falls within the defined NTZ.

The role of NTZ is critical in dynamic spectrum sharing scenarios, such as Citizens Broadband Radio Service (CBRS) or other shared/licensed-shared access regimes. It protects higher-priority incumbent users from harmful interference from mobile network transmissions. When a UE enters an NTZ, it must cease transmissions on the affected frequencies, potentially triggering a handover to another frequency or cell outside the zone. NTZ configurations can be dynamic, changing based on time of day or incumbent activity. This requires continuous UE positioning and policy enforcement. The specifications detail the signaling (e.g., in NAS messages) and parameters (like geographic area description, frequency range, and validity timer) needed to define and manage NTZs effectively across the network.

Purpose & Motivation

The NTZ concept was created to enable coexistence between mobile networks and other radio systems sharing the same frequency band, a problem that became acute with the introduction of dynamic spectrum sharing. Traditional static frequency allocation was insufficient for flexible, efficient spectrum use. Without NTZs, mobile transmissions could cause harmful interference to sensitive incumbent services, such as satellite communications or radar systems, leading to regulatory violations and service degradation for those incumbents.

The historical context includes the opening of shared spectrum bands like the 3.5 GHz CBRS band in the USA and similar bands globally. Regulators required mechanisms to protect incumbent users. 3GPP developed the NTZ framework to provide a standardized, network-controlled method for geographic exclusion of transmissions. This addresses the limitations of previous, more simplistic approaches like static exclusion zones or purely sensing-based solutions, which lacked the precision and policy control offered by integrated NTZ management. It allows mobile network operators to dynamically respect protection zones defined by a central spectrum controller, enabling more efficient and compliant use of shared spectrum resources. The creation of NTZ policies within the 5G core network architecture allows for scalable, automated enforcement essential for large-scale deployments.

Key Features

• Geographically defined area where UE transmissions are prohibited
• Network-controlled via UE policies from PCF/AMF
• Protects incumbent users (e.g., satellite, radar) in shared spectrum
• Dynamic configuration based on external inputs (e.g., SAS databases)
• Integrated with UE positioning for enforcement
• Supports validity conditions (time, frequency range)

Evolution Across Releases

Defining Specifications