TNLA

Transport Network Layer Association

Radio Access Network →
Introduced in Rel-15 Also in: Radio Access Network

TNLA is a logical association between two network nodes over the Transport Network Layer, representing a specific transport path for redundancy and load balancing.

Category
Radio Access Network
Introduced
Rel-15
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
4 specs
TNLA Description Purpose Related Classification Detected Changes Specifications

Description

A Transport Network Layer Association (TNLA) is a logical connectivity context established between two peer network functions over the Transport Network Layer (TNL). It represents a specific transport path, identified by a combination of transport layer addressing information. For example, between a gNB (or ng-eNB) and an AMF in the 5G system, a TNLA is defined for the NG interface and is associated with a specific Stream Control Transmission Protocol (SCTP) association. Each SCTP association between the gNB and an AMF, characterized by a specific pair of IP addresses and SCTP port numbers, constitutes one TNLA. A single gNB can establish multiple TNLAs to a single AMF or to multiple AMFs for redundancy and load distribution.

Architecturally, TNLAs are a crucial part of the N2 (NG-C) and N3 (NG-U) interface management. For the control plane (N2), each TNLA supports the transport of NG Application Protocol (NGAP) messages. The AMF and gNB use the TNLA Identifier (TNL Association ID) to reference a specific transport path when sending messages. The setup of TNLAs is part of the NG interface setup procedure. The concept also extends to the user plane, where multiple TNLAs can be used for N3 GTP-U tunnels between a gNB and a UPF, although the management mechanisms differ.

How it works involves several procedures. During initial setup, a gNB discovers available AMFs and initiates the establishment of SCTP associations, thereby creating TNLAs. The gNB and AMF exchange configuration data and assign a TNL Association ID to each. Once established, NGAP messages can be sent over any available TNLA to the peer. The endpoints perform load balancing and failover across TNLAs. If one TNLA fails (e.g., due to a path or SCPT association failure), traffic is seamlessly shifted to another active TNLA, ensuring high availability. The management of TNLAs includes monitoring their status (up/down), capacity, and performance, which is vital for network reliability and efficient load distribution.

Purpose & Motivation

The TNLA concept was formally introduced and emphasized in 3GPP Release 15 as part of the 5G New Radio (NR) architecture to address the requirements for enhanced reliability, scalability, and flexibility in the transport network interconnecting disaggregated RAN and core network functions. Its creation was motivated by the need to move beyond simple point-to-point links. Previous generations had redundancy mechanisms, but 5G's service-based architecture and cloud-native deployment models demanded more explicit and flexible transport path management.

TNLA solves the problem of single point of failure in the transport connectivity between critical nodes like the gNB and AMF. By enabling multiple independent transport paths (TNLAs), it provides inherent redundancy. It also addresses load balancing; network traffic (signaling load) can be distributed across multiple TNLAs to prevent congestion on a single path. This is especially important in centralized/cloud RAN deployments where a central unit may connect to many distributed units and core functions. Furthermore, TNLAs facilitate flexible AMF pooling and load balancing in the core network, as a gNB can have TNLAs to different AMFs within an AMF Set. This allows for efficient resource utilization and graceful maintenance operations without service interruption.

Classification

Part ofTNL
Related approachesSCTP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 1 change

In Release 15, the TNLA function was enhanced to allow an AMF to explicitly command the release or rebinding of the NGAP UE-TNLA-binding for a UE in CM-CONNECTED state while maintaining user-plane connectivity. This was facilitated by introducing a new indicator within the NGAP Setup procedure, where the AMF can signal its intent to perform these per-UE operations, and the 5G-AN may start a timer to control the release. These mechanisms support TNLA load balancing and re-balancing, enabling more dynamic management of transport associations.

  • Clarification for TNLA removal TS 38.463CR0111
Rel-16 3 changes

In Release 16, the TNLA function was enhanced to allow the AMF to explicitly command the release or rebinding of the NGAP UE-TNLA-binding for a UE in CM-CONNECTED state while maintaining user-plane connectivity. This was facilitated by a new indicator during the NGAP Setup procedure, which could trigger a timer mechanism in the 5G-AN to control the binding release. These changes provided clearer procedures for load re-balancing and AMF failure scenarios without disrupting the UE's data session.

  • Correction on TNLA binding TS 23.501CR1770
  • NGAP UE-TNLA-binding update TS 23.501CR2632
  • Interactions with other procedures for the UE TNLA BINDING RELEASE TS 38.413CR0556

Explore further

Broader topics and technologies where TNLA plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 37.483 vj10 E1 Application Protocol (E1AP) Rel-19
TS 38.413 vj10 NG Application Protocol (NGAP) Rel-19
TS 38.463 vj00 E1 Application Protocol (E1AP) Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.