PRC

Pseudo-Range Correction

Services →
Introduced in Rel-8

PRC is a correction parameter used in OTDOA positioning to compensate for base station timing differences, improving a UE's location accuracy.

Category
Services
Introduced
Rel-8
Where
Radio Access Network › E-UTRAN (LTE)
Specifications
4 specs
PRC Description Purpose Related Classification Specifications

Description

Pseudo-Range Correction (PRC) is a key parameter in the 3GPP standardized Observed Time Difference of Arrival (OTDOA) positioning method. OTDOA is a network-assisted, UE-based positioning technique where the UE measures the time difference of arrival between reference signals (e.g., Positioning Reference Signals - PRS in LTE/NR) from multiple neighboring base stations (eNodeBs/gNodeBs) and a reference cell. The raw measured time difference is called the Reference Signal Time Difference (RSTD). However, these measurements are not perfectly synchronized due to imperfections in the network's timing distribution.

The PRC is the correction value, transmitted by the network to the UE, that accounts for the relative timing offset between the transmission instants of the positioning reference signals from different base stations. Conceptually, if the UE measures an RSTD, the actual geometric time difference of arrival (which is needed for hyperbolic positioning calculations) is approximately RSTD + PRC. The PRC is typically provided by a Location Server (e.g., Evolved Serving Mobile Location Centre - E-SMLC or Location Management Function - LMF) which has knowledge of the network's timing relationships, often derived from measurements by Location Measurement Units (LMUs) or from the base stations themselves if they are synchronized via GNSS or IEEE 1588.

Architecturally, PRCs are part of the assistance data delivered to the UE in the OTDOA procedure. The UE receives a list of neighbor cells for OTDOA measurement, along with their PRS configuration and the associated PRC values (and possibly a related parameter, RSTD uncertainty). The UE performs the RSTD measurements, applies the received PRCs, and then uses the corrected pseudo-ranges (proportional to the corrected time differences) to solve a set of hyperbolic equations to determine its own coordinates. The calculation can be performed in the UE (UE-based) or the measurements can be sent back to the network for calculation (UE-assisted).

The accuracy of the PRC directly impacts the final positioning accuracy. If the network is perfectly synchronized (e.g., all gNBs have a common time source like GPS), the PRCs would be zero. In real deployments, especially in asynchronous or partially synchronized networks (common in indoor or dense urban scenarios), the PRCs are non-zero and vital. The generation and distribution of accurate, low-latency PRCs are therefore critical functions of the positioning architecture, enabling OTDOA to meet regulatory (e.g., E-911) and commercial location-based service requirements.

Purpose & Motivation

PRC was introduced to enable accurate OTDOA positioning in practical, non-ideal cellular network deployments. The fundamental principle of OTDOA requires that the time of transmission of the positioning signals from different base stations is known relative to a common time reference. In an ideal, perfectly synchronized network, this condition holds, and the UE's raw RSTD measurements directly reflect the geometric time differences. However, achieving and maintaining perfect synchronization across all cells in a large network is costly and often impractical, especially for small cells or in environments where GNSS signals for synchronization are unavailable.

PRC solves this problem by decoupling the requirement for perfect real-time synchronization from the positioning functionality. It allows the network to operate with ordinary synchronization levels (or even be asynchronous) while still supporting high-accuracy positioning. The Location Server calculates the timing offsets between cells based on its knowledge of the network (from LMUs or base station reports) and provides these offsets as PRCs to the UE as correction data. This approach is more flexible and cost-effective than mandating ultra-precise network-wide synchronization.

Historically, as location-based services and regulatory mandates for emergency caller location (e.g., FCC E-911) gained importance, 3GPP needed robust positioning methods for LTE (introduced in Release 9). OTDOA was developed as a primary method, and the PRC mechanism was a key innovation to make it work in real-world conditions. It addressed the limitations of earlier cellular positioning methods like Cell-ID and Enhanced Cell-ID, which offered poor accuracy, and provided a standardized, scalable technique that could leverage the existing cellular infrastructure without imposing prohibitive synchronization requirements, paving the way for subsequent enhancements in NR.

Classification

Part ofOTDOA
Related approachesRSTDPRS

Evolution Across Releases

Rel-9 Initial

Introduced PRC as part of the OTDOA positioning method for LTE. Defined its role in correcting RSTD measurements received from the UE or used by the network. Established the framework where the E-SMLC provides PRCs in the OTDOA assistance data to compensate for eNodeB transmission timing differences, enabling practical deployment of hyperbolic positioning.

Explore further

Broader topics and technologies where PRC plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 25.305 vj00 UTRAN UE Positioning Stage 2 Rel-19
TS 25.453 vj00 PCAP Protocol Specification Rel-19
TS 36.355 vj00 LTE Positioning Protocol (LPP) Rel-19
TS 37.355 vj20 LTE Positioning Protocol (LPP) 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.