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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (41 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the specification clarified procedures for TNLA (Transport Network Layer Association) removal. Furthermore, it introduced the concept of an NGAP UE association that can exist in CM-CONNECTED state without being bound to any specific TNLA between the Access Network and the AMF. This provided greater flexibility in managing the transport layer binding for a UE's signalling connection.
- Clarification on the association of an S-NSSAI to a given application TS 23.501CR0154
- Clarification on priority of URSP and configuration of association between application and LADN DNN TS 23.501CR0609
- Using TCP for reliable NAS transport between UE and N3IWF TS 23.501CR0692
- Transport Level Packet Marking TS 23.501CR0942
- Support of RAN initiated multiple SCTP associations TS 38.413CR0021
- Removal of multiple SCTP associations PS: This CR was not implemented as it was not based on the latest version of the spec. TS 38.413CR0084
+ 3 more changes
In Release 16, the TNLA function was enhanced with specific procedures for managing the binding between a UE's NGAP association and its transport layer, including the introduction of a dedicated NGAP UE-TNLA-binding procedure and its subsequent release mechanism. This release also provided corrections and updates to the binding process and its interactions with other network functions. Furthermore, the specifications clarified the state where a UE in CM-CONNECTED state can have an NGAP UE association that is not bound to any TNLA.
- Adding UDR NF Group ID association functionality TS 23.501CR1384
- Update of the NRPPa Transport procedure to support NR positioning TS 38.413CR0396
- Correction of NAS transport for LCS TS 23.501CR1578
- Correction on TNLA binding TS 23.501CR1770
- Requested NSSAI provided at the AS layer TS 23.501CR2038
- Correction on Ethernet Type PDU session and MAC address association TS 23.501CR2463
+ 5 more changes
In Release 17, specific corrections were introduced for the procedures governing Transport Network Layer Association (TNLA) addition, update, and removal. These enhancements provided clarifications and corrections to ensure the reliable management of the binding between a NGAP UE association and a specific TNL association for a given UE. The updates focused on the operational procedures without introducing new interfaces or capabilities.
- Multimedia Priority Service (MPS) Phase 2 support for Data Transport Service TS 23.501CR2536
- Additional authorization functionality in support of MPS for Data Transport Service TS 23.501CR2971
- KI#3, clarification on the TSCTSF functionality and configuration for transport protocols TS 23.501CR3160
- PMF information transported via N4 TS 23.501CR3110
- Layer below IPsec to enable NAT traversal for TNGF/N3IWF access TS 23.501CR3442
- Corrections on TNL association addition, update and removal (E1) TS 37.483CR0056
+ 1 more changes
In Release 18, the TNLA function was enhanced with specific support for interworking with a Time Sensitive Networking (TSN) enabled transport network, applicable when the transport network uses the fully centralized configuration model defined in IEEE 802.1Q. This includes enabling link layer connectivity discovery and reporting for devices attached to the DS-TT and NW-TT, as defined in IEEE 802.1AB. Furthermore, the release clarified the state management of the NGAP UE association, which can exist in CM-CONNECTED state without being bound to any TNLA between the AN and the AMF.
- Interworking with TSN network deployed in the transport network TS 23.501CR3811
- UE Policy Association handling during EPS to 5GS mobility with N26 TS 23.501CR4470
- Handling UE policy association when UE registered over both 3GPP and Non-3GPP access TS 23.501CR4570
- Translation of Internal-External Information for Assisting Application Layer AI/ML Operations TS 23.501CR4191
- ATSSS_Ph3 Enhanced Considerations of MPQUIC Multi-layer Stack Parameter Settings & Logics TS 23.501CR4777
- Correction on Support of Time Sensitive Networking (TSN) enabled Transport Network (TN) TS 23.501CR4955
+ 3 more changes
In Release 19, the TNLA function was enhanced to enable transport-level packet marking, specifically DSCP marking over the N3 and N9 interfaces, based on PDU Set QoS information and PDU Set Importance (PSI). This allows the I-SMF to trigger transport-level marking, providing more granular QoS handling in the transport network. Additionally, mechanisms were introduced for the recovery of N3mb path failures to improve reliability for the unicast transport of multicast sessions.
- Leveraging PDU Set QoS information for DSCP marking over N3/N9 in the transport network TS 23.501CR5407
- XRM_Ph2_KI3 Leveraging PDU Set QoS information for DSCP marking over N3/N9 in the transport network TS 23.501CR6050
- Triggering of Transport Level Marking based on PDU Set Importance in I-SMF TS 23.501CR6193
- Transport level packet marking considering PSI TS 23.501CR6478
- Recovery of N3mb path failure for unicast transport of multicast session TS 37.483CR0146
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.
| Specification | Title | Release |
|---|---|---|
| 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 |