NITZ

Network Identity and Time Zone

Services →
Introduced in Rel-4 Also in: Security

NITZ is a service enabling the cellular network to provide local time, date, and timezone information to mobile devices for automatic time setting.

Category
Services
Introduced
Rel-4
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
5 specs
NITZ Description Purpose Related Classification Detected Changes Specifications

Description

Network Identity and Time Zone (NITZ) is a service defined in 3GPP standards that allows a cellular network to deliver accurate local time, date, and timezone information to User Equipment (UE). It operates by having the network (specifically, the core network entities like the MSC or MME/AMF) send this information to the UE via signaling protocols during procedures such as location registration, call setup, or via dedicated messages. The UE receives this data and uses it to automatically set and update its internal clock and calendar, ensuring it displays the correct local time for the user's current geographical location.

Architecturally, NITZ functionality resides within the core network's control plane. In circuit-switched (CS) domains, it is typically provided by the Mobile Switching Center (MSC), while in packet-switched (PS) domains, it can be supported by the Mobility Management Entity (MME) in 4G or the Access and Mobility Management Function (AMF) in 5G. The service uses existing NAS (Non-Access Stratum) or other layer 3 signaling messages to piggyback the NITZ information. The information transmitted includes the local time (often referenced to Universal Coordinated Time, UTC), the date, the daylight saving time (DST) offset if applicable, and a timezone descriptor. The UE's management layer processes this information, adjusting the device's system time accordingly.

The key components involved are the network entity that originates the time data (which may synchronize to a precise time source like GNSS or NTP), the signaling protocol carrying the NITZ data (defined in specifications like TS 24.501 for 5GS), and the UE's time management client. NITZ messages can be sent unsolicited by the network or requested by the UE. The service also supports the delivery of network identity information, such as the network name, which can be displayed on the UE. This dual function of providing both time and network identity is reflected in its name.

NITZ's role in the network is to provide a universal, network-controlled time synchronization service for mobile devices. It is crucial for time-stamping events like call records for billing, enabling time-dependent features like alarm clocks that survive reboots, and ensuring applications have a correct time reference. It eliminates the dependency on the user to manually set the time or on the device's internal clock, which may drift. In roaming scenarios, NITZ is particularly important as it allows the device to automatically adapt to the local time of the visited network, improving user convenience and service accuracy.

Purpose & Motivation

NITZ was created to solve the fundamental problem of mobile devices displaying incorrect local time, especially after roaming across time zones or following a reboot. Before NITZ, users had to manually adjust their phone clocks, leading to errors, missed appointments, and complications for network operators in billing and time-based service provisioning. The manual approach was also unsuitable for the growing complexity of mobile services and the increasing frequency of international travel.

The service addresses several key issues: ensuring accurate billing records (Call Detail Records timestamped with the correct local network time), enabling reliable device features that depend on accurate time (alarms, calendars), and providing a better user experience by automating time management. For network operators, it provides a mechanism to distribute a single, authoritative time reference across all devices on their network, which is essential for operational consistency and legal compliance in areas like billing accuracy.

Introduced in 3GPP Release 4, NITZ built upon earlier, less standardized methods of time distribution. Its development was motivated by the globalization of cellular networks and the need for seamless roaming. By standardizing the information elements and signaling procedures across different network generations (from GSM/UMTS through LTE to 5G), NITZ ensured backward and forward compatibility. It solved the limitations of relying on the UE's internal real-time clock (which can drift) or external non-cellular sources (which may be unavailable or insecure), providing a reliable, network-centric solution integrated into the core mobility management procedures.

Classification

Related approachesNAS

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (127 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-4, normative work from Rel-15.

Rel-15 24 changes

In Release 15, the primary update for the NITZ function was an abbreviation update, as indicated directly in the Change Request titles. This release did not introduce new procedures or capabilities for NITZ beyond this editorial clarification, with other listed CRs focusing on areas such as PLMN selection, identity handling, and UE configuration parameters.

  • UE configuration for AC 11-15 and MCS (access identity 2) TS 24.501CR0083
  • Storing Configured NSSAI when the PLMN is changed TS 24.501CR0203
  • MCS Indicator and Access Identity 2 TS 24.501CR0614
  • Clarify the method of configuring the UE to use Access Identity 1 TS 24.501CR0255
  • Definition of Primary PLMN ID TS 23.251CR0108
  • Correction to the 5GS identity type IE TS 24.501CR0135

+ 18 more changes

Rel-16 31 changes

In Release 16, the NITZ function was enhanced to support the provision of the PLMN ID and NID (Network Identifier) to the lower layers, as indicated in the CR title. This change ensures that the network identity information is consistently available across the protocol stack. Furthermore, clarifications were made regarding the encoding and octet alignment of identity elements within related procedures.

  • Serving PLMN rate control, general description TS 24.501CR0972
  • Serving PLMN rate control, activation TS 24.501CR0973
  • PLMN ID and NID provided to the lower layers TS 24.501CR1055
  • Abnormal case handling for receipt of 5GMM cause value #11 from a PLMN TS 24.501CR1229
  • "S-NSSAI not available in the current PLMN" when non NSSAA supported UE requesting the S-NSSAI subjects to NSSAA TS 24.501CR1598
  • Usage of PDU session identity for the PDU sessions requested by the TWIF TS 24.501CR1686

+ 25 more changes

Rel-17 42 changes

In Release 17, the NITZ function was enhanced to support the new "PLMN with disaster condition" state, allowing the network to signal this status to user equipment. This update included the transmission of the "PLMN with disaster condition" information element as cleartext. Furthermore, the specifications were refined to clarify UE behavior for network selection and access control when such a disaster condition is indicated by a PLMN.

  • PLMN with disaster condition TS 24.501CR3585
  • Introducing access identity 3 for disaster roamer TS 24.501CR3679
  • Enabling update of SOR-SNPN-SI in a PLMN TS 24.501CR3839
  • PLMN with disaster condition IE as cleartext TS 24.501CR3970
  • The solution to CAG IDs of a PLMN beyond the limit of one Entry-IE part TS 24.501CR4124
  • The solution to CAG IDs of a PLMN beyond the limit of one Entry-Procedure part TS 24.501CR4125

+ 36 more changes

Rel-18 19 changes

In Release 18, the primary update for the NITZ function was the alignment of its abbreviation within the specifications. The release also introduced clarifications and corrections related to PLMN selection and registration procedures, such as the handling of the equivalent PLMN list when a UE registers to two PLMNs and the storage of the NAS security context when registering to a different PLMN on the same access.

  • Equivalent SNPN usage for mobile identity selection TS 24.501CR4840
  • 5GMM cause code #15 indicating Satellite NG-RAN not allowed in PLMN TS 24.501CR6249
  • Handling when FPLMN is declared allowable PLMN by network TS 24.501CR4628
  • Corrections related to cause value #78 PLMN not allowed to operate at the present UE location TS 24.501CR4574
  • Clarification on equivalent PLMN applicability TS 24.501CR4713
  • Alignment of the abbreviation NITZ TS 24.501CR4730

+ 13 more changes

Rel-19 11 changes

In Release 19, the NITZ function's related procedures were updated with new rules for managing forbidden and equivalent PLMN lists. Specifically, the standard now defines that forbidden PLMNs are not to be removed from the Equivalent PLMN list when an emergency PDU session is released. Additionally, corrections were made to the handling of the PLMN-specific counter reset when the UE is registered for disaster roaming services.

  • Storage and replacement of RAT utilization control information associated to the current PLMN TS 24.501CR6460
  • Timer T3540 handling for causes triggering cell or PLMN selection TS 24.501CR6238
  • Addition of a condition for the removal of memorized PLMN and SNPN Ids. TS 24.501CR6548
  • Missing NOTE for T3540 for a UE with high priority access in selected PLMN or SNPN TS 24.501CR6546
  • PLMN-specific counter reset TS 24.501CR6602
  • Missing NOTE for T3540 for a UE with high priority access in selected PLMN or SNPN TS 24.501CR6543

+ 5 more changes

Explore further

Broader topics and technologies where NITZ plays a role.

Defining Specifications

3GPP specifications that define or reference NITZ, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.251 vj00 Network Sharing Stage 2 Specification Rel-19
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 33.303 vj00 ProSe Security Specification for EPS Rel-19
TS 33.503 vj20 Security for Proximity Services (ProSe) in 5G Rel-19