Description
The Hyper Frame Number (HFN) is a critical component in 3GPP security and protocol mechanisms, functioning as a high-order part of a counter used to generate cryptographic keys and ensure data freshness. It is employed alongside a shorter Sequence Number (SN) to construct a longer, composite COUNT value. For example, in LTE and NR, the COUNT parameter used in ciphering and integrity protection algorithms is typically 32 bits long, composed of a 20- to 25-bit HFN and a 7- to 12-bit SN, depending on the radio bearer and specific protocol. The SN increments with each Protocol Data Unit (PDU) and rolls over upon reaching its maximum value, at which point the HFN is incremented by one, effectively extending the counter's range to trillions of frames, thereby preventing reuse of the same COUNT value within a practical timeframe.
Architecturally, the HFN is maintained independently by both the sender and receiver (e.g., UE and base station or UE and core network) for each radio bearer or signaling connection. Synchronization of the HFN is crucial; it is typically initialized during connection establishment or handover procedures and then updated based on the rollover of the SN. The 3GPP specifications define precise rules for HFN management to avoid desynchronization, which could lead to decryption failures or integrity check mismatches. In scenarios like handovers, the HFN may be transferred or recalculated to maintain continuity. The HFN is also used in other contexts, such as in the Packet Data Convergence Protocol (PDCP) for sequence numbering and in some cases for timing alignment.
HFN's role is fundamental to the security and reliability of mobile networks. By providing a vast counter space, it ensures that the same ciphering key stream is not reused, which is essential to prevent cryptographic attacks such as keystream reuse. It also supports integrity protection by providing input for freshness parameters. The management of HFN is tightly integrated with mobility procedures, including handovers and connection re-establishments, to ensure seamless security continuity. Its implementation is transparent to higher layers but is vital for the underlying security framework that protects user data and signaling across 3GPP generations from UMTS to 5G NR.
Purpose & Motivation
The Hyper Frame Number was introduced to address the limitation of finite sequence number spaces in cryptographic protocols. Early mobile systems used sequence numbers alone for ciphering, but as data volumes increased, these sequence numbers could wrap around too quickly, leading to the reuse of cryptographic keystreams—a severe security vulnerability. The HFN extends the effective counter length, ensuring that the combined COUNT value (HFN || SN) does not repeat during the lifetime of a security key, thereby maintaining cryptographic strength and preventing replay attacks.
Historically, the concept evolved from GSM's ciphering mechanisms and was formally integrated into 3GPP standards starting with UMTS (Release 4) to provide robust security for the new packet-switched domains. The motivation was to support long-lived sessions and high data rates without compromising security. Without HFN, frequent rekeying would be necessary, increasing signaling overhead and potential service disruption. HFN enables efficient, long-term security synchronization, which is especially critical for always-on services and IoT devices with extended battery life. It solves the problem of managing secure communications over potentially years of device operation without key repetition, a foundational requirement for modern mobile networks.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (70 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.
In Release 15, the specific change for the HFN function was the introduction of a CR on HFN maintenance. This work item addressed necessary procedures to ensure the consistent and correct handling of the Hyper Frame Number across new functionalities introduced in the release, such as PDCP duplication. The maintenance update ensured HFN synchronization and management remained robust within the evolved packet core framework supporting multiple radio access technologies.
- Network support for increased number of bearers TS 23.401CR3420
- Introduction of increased number of E-UTRAN data bearers TS 36.331CR3446
- Introduction of PDCP duplication TS 38.323CR0009
- Deliver stored PDCP SDUs for UM DRB at PDCP re-establishment TS 36.323CR0241
- CR on supporting of the ROHC for PDCP duplication TS 36.323CR0243
- Correction on PDCP for eV2X TS 36.323CR0249
+ 24 more changes
In Release 16, the HFN function was updated through specific PDCP protocol enhancements, including corrections for security and duplicate detection, and refined procedures for PDCP re-establishment when using the t-Reordering timer. These changes also introduced support for PDCP operation after DAPS release and allowed for PDCP version changes without requiring a handover. The updates aimed to improve reliability and security for both LTE and NR, particularly in support of Industrial IoT (IIoT) use cases.
- Add new general abbreviations MCC Note: CR cover sheet wrongly shows CR number as "1118". TS 21.905CR0118
- Introducing EHC in LTE PDCP TS 36.323CR0278
- Correction on the number of PDN types stored per APN in the subscription data TS 23.401CR3518
- LTE PDCP corrections for NR IIOT TS 36.323CR0286
- Correction for PDCP status report TS 36.323CR0287
- CR on LTE PDCP re-establishment when t-Reordering is used TS 36.323CR0290
+ 12 more changes
In Release 17, specific PDCP corrections were made for new functionalities including L2 U2N Relay, SL relay, and MBS, which rely on the HFN for security and sequence management. The release also introduced a PDCP Control PDU for UDC feedback and initialization procedures for MRB, operations that depend on proper HFN synchronization. These updates ensured robust HFN handling across the expanded use cases for NR in integrated and sidelink architectures.
- Introducing support of UP IP for EPC connected architectures using NR PDCP TS 36.331CR4763
- Introducing support of UP IP for EPC connected architectures using NR PDCP TS 38.323CR0085
- Correction on PDCP Control PDU for UDC feedback TS 36.323CR0304
- Addition of extended number range for NS value TS 36.331CR4917
- Correction on PDCP for SL relay TS 38.323CR0093
- PDCP Corrections for MBS TS 38.323CR0096
+ 8 more changes
In Release 18, specific enhancements to PDCP procedures were introduced, including PDCP SN gap reporting and corrections to this reporting mechanism. Furthermore, the release defined new network signalling for the maximum number of UL segments and introduced NR sidelink PDCP duplication. These updates provided more granular control over data unit handling and reporting within the radio interface framework.
- Introduction of NR sidelink PDCP duplication in TS 38.323 TS 38.323CR0126
- PDCP SN gap reporting TS 38.323CR0139
- Correction for Delay Critical Indication from PDCP to RLC TS 38.323CR0144
- PDCP SN Gap report Corrections TS 38.323CR0147
- Introduction of network signalling of maximum number of UL segments [Max-RRC-SegUL] TS 36.331CR5084
- Corrections on network signalling of maximum number of UL segments [Max-RRC-SegUL] TS 36.331CR5089
In Release 19, the enhancements and corrections for the PDCP specification, as indicated by the CR titles, were specifically focused on Extended Reality (XR) applications. The changes aimed to optimize data handling for XR services, which involve high volumes of service data units (SDUs) transferred per unit time. These modifications were designed to improve the efficiency and reliability of the data transfer process for XR traffic over the radio interface.
Explore further
Broader topics and technologies where HFN plays a role.
Defining Specifications
3GPP specifications that define or reference HFN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 23.401 vj50 | Evolved Packet System (EPS) Stage 2 Description | Rel-19 |
| TS 25.331 vj00 | UTRAN RRC Protocol Specification | Rel-19 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 36.323 vj00 | PDCP Protocol Specification | Rel-19 |
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TS 36.413 vj10 | S1 Application Protocol (S1AP) | Rel-19 |
| TS 36.423 vj10 | X2 Application Protocol (X2AP) Specification | Rel-19 |
| TS 38.323 vj00 | Packet Data Convergence Protocol (PDCP) | Rel-19 |
| TS 44.160 vg00 | GERAN Iu Mode RLC/MAC Protocol Specification | Rel-16 |