Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Radio Access Network

TFS

Transport Format Set

Radio Access Network →

TFS is the configured set of all valid Transport Format combinations, defining possible data block sizes, coding schemes, and timing for a UMTS Transport Channel to enable dynamic rate adaptation.

Introduced
R99
Where
Radio Access Network › UTRAN (3G)
Specifications
7 specs
TFS Description Purpose What changed Neighbours Specifications

Description

The Transport Format Set (TFS) is a core configuration concept in UMTS radio interface Layer 2, specifically for the Medium Access Control (MAC) layer. Each dedicated or common Transport Channel (TrCH) is configured with a TFS, which is a collection of permitted Transport Formats (TFs). A Transport Format itself is a combination of semi-static and dynamic attributes that fully describe how a Transport Block (TB) or set of Transport Blocks is presented to the physical layer for transmission in a given Transmission Time Interval (TTI). The semi-static part includes parameters like the TTI duration, the type of channel coding (e.g., convolutional, turbo), the coding rate, and the size of the CRC. The dynamic part specifies the number of Transport Blocks (TBs) and their size.

Architecturally, the TFS is defined and signaled to the User Equipment (UE) by the Radio Network Controller (RNC) via Radio Resource Control (RRC) signaling during radio bearer setup or reconfiguration. It is part of the Transport Channel information element. The MAC layer in both the UE and the UTRAN (Node B/RNC) uses this set as a constraint. For each TTI, the MAC scheduler selects one specific Transport Format Combination (TFC) from the allowed set, which is a valid combination of Transport Formats across all active Transport Channels of the UE. This selection is based on available data, priority, and granted resources.

How it works involves a two-step process: configuration and dynamic selection. First, the RNC pre-defines the TFS, ensuring all possible data rates and formats needed for the service's QoS are available but within physical layer capabilities. Second, during operation, the MAC entity dynamically chooses a TF from this set for each TTI. In Release 99/4, this selection was largely RNC-controlled via TFCI signaling. In later releases with HSDPA/EUL, the TFS for high-speed channels is still configured by RNC, but the dynamic selection (indicated by TFRI) is done by the Node B's fast scheduler. The TFS thus provides the essential 'menu' of transmission options, enabling rate adaptation while ensuring transmissions remain within predefined, network-controlled bounds for interference and resource management.

Purpose & Motivation

The TFS concept was created to provide a flexible yet controlled framework for variable rate data transmission over the UMTS air interface, moving beyond the fixed-rate channels of 2G systems like GSM. It addresses the fundamental challenge of supporting multimedia services with diverse and fluctuating bandwidth requirements (e.g., voice, video streaming, web browsing) on shared radio resources. Without a predefined set of formats, dynamic rate adaptation would be unbounded and could lead to uncontrolled interference or physical layer incompatibilities between transmitter and receiver.

In the pre-HSDPA UMTS architecture (Release 99), the TFS allowed the RNC to define the possible data rates for a radio bearer statically, while the MAC layer could dynamically switch between them based on traffic volume. This solved the problem of efficiently multiplexing multiple services with different bit rates onto a single coded composite transport channel (CCTrCh). The TFS configuration encapsulates the trade-offs between peak data rate, granularity of rate adaptation, and signaling overhead. Its creation was motivated by the need for a standardized, efficient method to manage the complex mapping between logical channel data flows and the physical layer's transmission capabilities in a wideband CDMA system.

What changed in its specifications

The latest release-to-release comparison of specifications that define TFS. Each summary describes the whole specification, not only this term.

TR 21.905Rel-17 → Rel-18

Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.

Full comparison in TR 21.905 →
TS 25.331Rel-15 → Rel-16

Rel-16 added SR-VCC handover from NR to UTRAN, integrity protection activation, and key set storage. These were the largest feature overviews for TS 25.331.

Full comparison in TS 25.331 →

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

R99 Initial

Introduced as a foundational concept for dedicated channels (DCH). The TFS is configured for each TrCH, allowing dynamic selection of Transport Formats by the MAC based on data availability. Signaling of the selected format is done via the Transport Format Combination Indicator (TFCI) on the physical layer.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj20 3GPP Terminology and Definitions Rel-19 read
TS 25.331 vj01 UTRAN Radio Resource Control Protocol Rel-19 read
TS 25.423 vj00 UTRAN RNSAP Specification Rel-19 read
TS 25.433 vj00 Node B Application Part (NBAP) Protocol Rel-19 read
TR 25.931 vj00 UTRAN Signalling Procedures Examples Rel-19 read
TS 44.160 vg00 GERAN Iu Mode RLC/MAC Protocol Specification Rel-16 read
TR 45.902 vj00 Flexible Layer One (FLO) for GERAN Rel-19 read