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

Glossary term · Protocol

FP

Frame Protocol

Protocol →

FP is a layer 2 data link protocol used in UMTS and LTE to transport user data and control information between network nodes, handling framing, synchronization, and in-band control signaling.

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

Description

The Frame Protocol (FP) is a crucial Layer 2 protocol within the 3GPP UTRAN architecture, responsible for the structured transport of data frames over the terrestrial interfaces connecting Radio Network Controllers (RNCs) and Node Bs (base stations). It operates over the lub interface (between RNC and its controlled Node B), the iur interface (between two RNCs), and the lur interface in certain configurations. FP is not a single protocol but a family of protocol specifications, each tailored for a specific type of transport channel (e.g., DCH, FACH, RACH, PCH, HS-DSCH, E-DCH). Its primary function is to provide framing, synchronization, and in-band control signaling for the user plane and control plane data flowing between these network elements.

Architecturally, FP resides above the transport network layer (which is typically IP or ATM) and below the MAC layer. It encapsulates MAC PDUs into FP frames, adding a protocol header that contains essential control information. A key component of FP is the Frame Protocol Data Frame, which carries the actual user data. Equally important are the control frames, such as Timing Adjustment, Synchronization, and DL/UL Power Control frames, which are used for alignment and management of the radio link. The protocol works in a master-slave fashion, with the RNC typically acting as the master for timing control. It ensures that data frames are delivered with the correct timing to the Node B for transmission over the air interface, managing synchronization to compensate for transport network delays.

FP's operation involves continuous exchange of data and control frames. For a Dedicated Channel (DCH), the RNC sends DL FP frames containing user data to the Node B. The Node B responds with control frames indicating its receiver status and providing timing information. In the uplink, the process is reversed. For shared channels like HS-DSCH (High-Speed Downlink Shared Channel), FP includes mechanisms for flow control, allowing the Node B to signal its buffer status to the RNC to regulate the data flow and prevent overflow. The protocol also supports quality measurement reporting and outer loop power control commands. Its role is foundational: it abstracts the underlying transport network (ATM AAL2 or IP/UDP) and provides a reliable, synchronized, and controllable pipe for the radio access network's user and control traffic, enabling precise coordination between the RNC's scheduling and the Node B's transmission timing.

Purpose & Motivation

The Frame Protocol was created to solve the fundamental problem of transporting time-sensitive digital radio frames over asynchronous terrestrial transport networks in the UMTS architecture. Prior to 3G, base station controllers and base transceiver stations were often connected via synchronous TDM links (e.g., E1/T1), where timing was inherent. With UMTS and the adoption of packet-based transport like ATM and later IP, a new protocol was needed to maintain synchronization, frame alignment, and deliver the necessary control signaling between the RNC and Node B. FP addressed the limitations of using raw transport protocols, which lacked the mechanisms for precise timing control, in-band management, and channel-specific framing required for efficient radio operation.

Its creation was motivated by the need to separate transport technology from radio network functionality, allowing operators to choose their backhaul technology (ATM or IP) independently. FP provides the necessary adaptation layer that ensures the radio interface's stringent timing requirements are met regardless of variable delays in the packet network. It solves critical problems such as compensating for transport delay variation (jitter) to ensure air interface synchronization, enabling efficient flow control for shared channels to manage Node B buffer resources, and carrying radio-related control information (like power control commands) alongside user data without requiring separate signaling connections. This design was essential for the feasibility and performance of the WCDMA-based UTRAN.

What changed in its specifications

The latest release-to-release comparison of specifications that define FP. 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.423Rel-10 → Rel-11

Four Branch MIMO for HSDPA, uplink transmit diversity for HSPA, CELL_FACH enhancements, HSUPA MIMO with 64QAM, multiflow data transmission, and SON enhancements.

Full comparison in TS 25.423 →

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

Frame Protocol was initially introduced in 3GPP Release 99 as a core component of the new UTRAN architecture. The initial architecture defined the fundamental FP data and control frame structures for dedicated channels (DCH) and common channels, operating primarily over ATM AAL2 transport. It established the master-slave timing control mechanism and basic synchronization procedures between the RNC and Node B.

Defining Specifications

3GPP specifications that define or reference FP, 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 23.050 3GPP TS 23.050 R99 read
TS 25.419 vj00 Service Area Broadcast Protocol (SABP) Rel-19 read
TS 25.423 vj00 UTRAN RNSAP Specification Rel-19 read
TS 25.425 vj00 UTRAN Iur Interface User Plane Protocols Rel-19 read
TS 25.427 vj00 UTRAN Iub/Iur User Plane Protocols Rel-19 read
TS 25.430 vj00 Introduction to Iub Interface Specifications Rel-19 read
TS 25.433 vj00 Node B Application Part (NBAP) Protocol Rel-19 read
TS 25.434 vj00 UTRAN Iub Interface Data Transport and Signalling Rel-19 read
TS 25.435 vj00 UTRAN Iub Interface User Plane Protocols Rel-19 read
TR 25.931 vj00 UTRAN Signalling Procedures Examples Rel-19 read
TS 31.113 v800 USAT Interpreter Byte Codes Specification Rel-8 read
TS 32.405 vj00 UTRAN Performance Measurements Specification Rel-19 read