BAT

Bearer Association Transport

Protocol →
Introduced in Rel-9 Also in: Services

BAT is a 3GPP protocol mechanism that associates multiple IP flows to specific transport resources, ensuring proper mapping between service data flows and transport bearers to optimize utilization and support QoS.

Category
Protocol
Introduced
Rel-9
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
7 specs
BAT Description Purpose Related Classification Detected Changes Specifications

Description

Bearer Association Transport (BAT) is a fundamental protocol mechanism within 3GPP architectures that establishes and manages associations between service-level bearers and transport network resources. In 3GPP networks, bearers represent logical communication channels with specific Quality of Service (QoS) characteristics, while transport resources refer to the physical or virtual connections that carry the actual data traffic. BAT operates at the interface between the service layer and transport layer, ensuring that service data flows are properly mapped to appropriate transport bearers with matching QoS requirements.

The architecture of BAT involves several key components including the Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), Bearer Binding and Event Reporting Function (BBERF), and various transport network elements. When a service request arrives, the PCRF determines the appropriate QoS policies and communicates these to the PCEF or BBERF. These enforcement functions then use BAT mechanisms to bind the service data flow to a specific transport bearer that can satisfy the required QoS parameters. This binding process considers factors such as bandwidth requirements, latency constraints, packet loss tolerance, and charging characteristics.

BAT works through a series of signaling procedures that establish, modify, and release bearer associations. The process begins with the detection of a new service data flow, typically triggered by application requests or network policies. The enforcement function then evaluates available transport resources and selects an appropriate bearer based on the QoS requirements. If no suitable bearer exists, BAT mechanisms can trigger the creation of a new dedicated bearer. Throughout the session, BAT continuously monitors the association and can dynamically adjust the binding in response to changing network conditions, user mobility, or policy updates.

The protocol's operation is specified across multiple 3GPP technical specifications, with detailed procedures for different network scenarios including fixed-mobile convergence, multi-access edge computing, and network slicing environments. BAT supports both GTP-based and PMIP-based transport protocols, providing flexibility in deployment scenarios. Key aspects include bearer binding decision making, event reporting for policy control, and interaction with charging systems to ensure proper correlation between service usage and transport resource consumption. The mechanism also handles error conditions and recovery procedures to maintain service continuity during network transitions or failures.

Purpose & Motivation

BAT was created to address the fundamental challenge of efficiently mapping service-level QoS requirements to underlying transport network resources in 3GPP architectures. Prior to its introduction, networks struggled with inefficient resource utilization where multiple services with similar QoS requirements would create separate transport bearers, leading to unnecessary overhead and suboptimal network performance. The lack of standardized bearer association mechanisms also made it difficult to implement consistent QoS policies across different network domains and between different operator networks.

The technology solves several critical problems in mobile networks. First, it enables optimal resource utilization by allowing multiple service data flows with similar QoS characteristics to share the same transport bearer, reducing signaling overhead and improving network efficiency. Second, it provides a standardized mechanism for QoS enforcement across the entire data path, ensuring consistent service quality from the user equipment through the radio access network and core network to external packet data networks. Third, BAT supports accurate charging by maintaining proper correlation between service usage and transport resource consumption, enabling sophisticated charging models based on QoS levels and network resource utilization.

Historically, the motivation for BAT emerged with the evolution toward all-IP networks in 3GPP Release 8 and the introduction of the Evolved Packet System (EPS). As networks moved from circuit-switched to packet-switched architectures, there was a need for more sophisticated mechanisms to manage the relationship between services and transport resources. BAT provided the necessary framework to support advanced services like VoIP, video streaming, and enterprise applications that require guaranteed QoS while maintaining efficient network operation. The protocol has evolved to address emerging requirements including network slicing, edge computing, and 5G service-based architectures.

Classification

Part ofQoS
Related approachesPCRFPCEF

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-18 11 changes

In Release 18, the BAT function was enhanced with new capabilities for network-controlled adaptation, specifically introducing a BAT window and a BAT periodicity adaptation capability for uplink SEALDD traffic. The release also added support for a network-determined BAT offset and adjusted periodicity, enabling dynamic optimization of burst arrival timing. These features are signaled through new optional elements like `bat-period-adapt-cap` and `transmisAssistInfo` within the SEALDD framework.

  • Support of BAT window and capability for BAT adaptation TS 29.122CR0658
  • Support of BAT window and capability for BAT adaptation TS 29.512CR1039
  • Network determined BAT offset and periodicity adaption TS 29.512CR1052
  • The correction on BAT window and BAT adaptation capability and the support of provisioning Periodicity Set TS 29.512CR1053
  • Support of BAT window and capability for BAT adaptation TS 29.514CR0483
  • Support of BAT window and capability for BAT adaptation TS 29.565CR0053

+ 5 more changes

Rel-19 10 changes

In Release 19, the BAT function was enhanced with new support for BAT and periodicity adaptation, specifically for uplink SEALDD traffic in HTTP and CoAP-based procedures. This included defining a new `bat-period-adapt-cap` capability element and extending the `transmisAssistInfo` attribute to carry adaptation parameters like BAT offset and periodicity range. These adaptations were integrated into transmission quality guarantee support and SEALDD regular transmission connection establishment procedures.

  • BAT and periodicity adaptation in transmission quality guarantee support in HTTP TS 24.543CR0021
  • BAT and periodicity adaptation in transmission quality guarantee support in COAP TS 24.543CR0022
  • BAT and periodicity adaptation support in SEALDD regular transmission connection establishment HTTP procedure TS 24.543CR0036
  • BAT and periodicity adaptation support in SEALDD regular transmission connection establishment COAP procedure TS 24.543CR0037
  • BAT and periodicity adaptation for HTTP TS 24.543CR0077
  • BAT and periodicity adaptation for CoAP TS 24.543CR0078

+ 4 more changes

Explore further

Broader topics and technologies where BAT plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 24.543 vj50 SEAL Data Delivery Management Protocol Rel-19
TR 26.917 vj00 TV Service Enhancements over 3GPP Rel-19
TS 29.122 vj40 T8 Reference Point for Northbound APIs Rel-19
TS 29.205 vj00 BICC Protocols for Bearer-Independent CS Core Network Rel-19
TS 29.512 vj40 5G Session Management Policy Control Service Rel-19
TS 29.514 vj40 5G System; Policy Authorization Service; Stage 3 Rel-19
TS 29.565 vj40 Time Synchronization Function Services 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.