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

Glossary term · Other

TOW

Time of Week

Other →

TOW is the elapsed time within the current GPS week, used for synchronizing satellite transmissions and calculating position in satellite navigation systems.

Introduced
Rel-4
Where
User Equipment
Specifications
11 specs
Also in
Radio Access Network
TOW Description Purpose What changed Neighbours Specifications

Description

Time of Week (TOW) is a continuous time count used within the framework of Global Navigation Satellite Systems (GNSS), most notably the Global Positioning System (GPS). It is a scalar value that counts the number of seconds that have elapsed since the start of the current GPS week. A GPS week is defined as 604,800 seconds (7 days * 24 hours * 3600 seconds). The TOW count resets to zero at the transition between GPS weeks, which occurs every Sunday at 00:00:00 GPS Time (which is approximately aligned with UTC but does not include leap seconds). The TOW is transmitted within the navigation message from each GPS satellite, specifically in the Handover Word (HOW) of each subframe.

Architecturally, TOW is a core component of the GNSS signal structure. Each satellite broadcasts its navigation data in frames and subframes. The HOW in every subframe contains the TOW count for the start of the next subframe. This allows a GNSS receiver, once it has decoded the HOW from one satellite, to synchronize its internal time base to the precise GPS system time. The receiver uses this TOW information to compute the exact time of transmission for the ranging codes (the pseudo-random noise codes) from each satellite. The accuracy of these timestamps is paramount for calculating the signal travel time, or pseudo-range, from the satellite to the receiver.

In operation, the GNSS receiver performs correlation to acquire the satellite signals. Once a signal is acquired and tracked, the receiver decodes the navigation message to extract the TOW and other ephemeris data. The TOW is used to resolve the integer millisecond ambiguity in the measured code phase. By knowing the precise TOW corresponding to the received signal, the receiver can calculate the full, unambiguous travel time of the signal. This process is essential for computing an accurate position. The Time To First Fix (TTFF) is heavily dependent on how quickly the receiver can obtain a valid TOW. For a cold start, the receiver must decode at least a full subframe (6 seconds) from one satellite to get the TOW, which is a primary factor in the initial TTFF. Assistance data, like predicted ephemeris and time models, can provide an approximate TOW to the receiver, drastically reducing this acquisition time.

Purpose & Motivation

TOW exists as a fundamental timing mechanism within GPS and similar GNSS architectures to provide a common, precise, and continuous time reference for all satellites and users. Before the establishment of a system-wide time like TOW, coordinating signals from multiple, independently moving satellites for precise ranging would be immensely complex. TOW solves the problem of synchronizing the transmissions from the entire satellite constellation and provides users with the critical timestamp needed to measure signal propagation delay.

The historical motivation stems from the core principle of satellite navigation: position is derived from precisely measured distances (ranges) to known satellite locations. To measure distance, one must know exactly when the signal left the satellite and when it arrived at the receiver. TOW provides the "when it left" timestamp in a universal system time. The limitations of not having such a synchronized time would be catastrophic—ranging measurements would be incoherent, and position calculation would be impossible. TOW, along with the GPS week number, creates a continuous, unambiguous timeline for the system.

Its role in TTFF is particularly crucial. The receiver must determine the full signal travel time, which includes an unknown integer number of milliseconds. The TOW value, broadcast every 6 seconds, allows the receiver to resolve this ambiguity. The need to decode this TOW from the relatively slow (50 bps) navigation data link was a primary bottleneck for fast positioning. This limitation directly drove the development of Assisted-GNSS (A-GNSS) technologies, where the network provides the current TOW (or a close estimate) to the UE as assistance data, enabling sub-second TTFF and enabling location services for emergency calls and consumer applications.

What changed in its specifications

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

TS 25.172Rel-11 → Rel-12

Added BDS support for UTRA and LTE. Changes include satellite constellation, assistance data, references, and symbols.

Full comparison in TS 25.172 →
TS 25.305Rel-11 → Rel-12

Rel-12 added support for BeiDou Navigation Satellite System (BDS) for UTRA and LTE, including a network-assisted positioning method, a normative reference to BDS ICD, and a definition for BDS.

Full comparison in TS 25.305 →

Evolution Across Releases

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

Rel-4 Initial

Introduced support for location services (LCS) in 3GPP, which included leveraging GNSS parameters like Time of Week (TOW). The initial architecture in specifications like TS 25.171 defined how UE measurements, including GNSS measurements timestamped with TOW, could be reported to the network for UE-assisted positioning methods, establishing the foundation for cellular-GNSS integration.

Defining Specifications

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

SpecificationTitleRelease
TS 25.171 vj00 A-GPS Minimum Performance Requirements for UTRA FDD UE Rel-19 read
TS 25.172 vj00 A-GANSS UE Minimum Performance Requirements (FDD) Rel-19 read
TS 25.173 vj00 A-GANSS Performance Requirements (TDD) Rel-19 read
TS 25.305 vj00 UTRAN UE Positioning Stage 2 Rel-19 read
TS 25.453 vj00 PCAP Protocol Specification Rel-19 read
TS 36.171 vj10 A-GNSS Minimum Performance Requirements for UE Rel-19 read
TS 36.355 vj00 LTE Positioning Protocol (LPP) Rel-19 read
TS 37.355 vj30 LTE Positioning Protocol (LPP) Rel-19 read
TS 37.571 vj00 UE Conformance for Positioning Rel-19 read
TS 38.171 vj10 5G A-GNSS UE Positioning Requirements Rel-19 read
TS 45.005 vj00 GSM RF Requirements for MS and BSS Rel-19 read