Description
In the context of 3GPP standards, a Geostationary Earth Orbit (GEO) refers to a specific orbital path used by satellites that are integrated as access nodes within a 3GPP-defined Non-Terrestrial Network (NTN). A GEO satellite is positioned at an altitude of roughly 35,786 kilometers directly above the Earth's equator, moving in the same direction as the planet's rotation. This synchronization results in an orbital period of exactly 24 hours, causing the satellite to remain fixed in the sky relative to an observer on the ground. This stationary characteristic is its defining operational feature.
From a network architecture perspective, a GEO satellite in a 3GPP NTN acts as a radio base station, often referred to as a gNB in 5G terminology, or as a transparent payload that relays signals. It connects User Equipment (UE) on the ground to a ground-based gateway station, which is then connected to the 5G core network. The communication link involves a Service Link (between the UE and satellite) and a Feeder Link (between the satellite and the gateway). Due to the immense distance, GEO links introduce a very high propagation delay of approximately 250 milliseconds for a round trip, which is a critical design constraint impacting protocols and services. The large coverage footprint of a single GEO satellite (covering up to a third of the Earth's surface) is a major advantage for providing ubiquitous coverage over oceans, deserts, and other unserved areas.
3GPP specifications have been adapted to support GEO-based NTN. This involves enhancements to cope with the long delay and high Doppler shift (which is relatively low for GEO but still present), timing advance procedures, mobility management (as handovers are less frequent due to the wide beam), and specific radio resource management techniques. The physical layer specifications (e.g., in 38.101, 38.108) define supported frequency bands and requirements for GEO operation. The system must handle the challenge of link budget due to the long distance, requiring UEs with enhanced capabilities or specialized terminals for reliable connectivity.
Purpose & Motivation
The standardization of GEO satellite operation within 3GPP, starting in Release 12 and significantly expanded for 5G NTN, is driven by the goal of providing seamless, global wireless coverage. Traditional terrestrial networks (cells on towers) are economically and physically impractical for covering vast rural, maritime, and aerial regions. GEO satellites solve this problem by offering a single platform that can provide continuous coverage to an entire continent or ocean basin, filling critical coverage gaps and enabling true ubiquitous connectivity for 5G.
Historically, satellite communication existed as a separate, non-integrated system. The motivation for integrating GEO (and other orbits like LEO and MEO) into 3GPP standards is to unify terrestrial and non-terrestrial networks under a common framework. This allows mobile devices to potentially connect directly to satellites using modified 3GPP protocols, enabling services like emergency communications, IoT asset tracking in remote areas, and backhaul for rural base stations. It addresses the limitations of purely terrestrial networks by ensuring service continuity everywhere, which is essential for mission-critical communications, disaster recovery, and connecting the unconnected, thereby supporting the United Nations' sustainable development goals for universal internet access.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (8 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 18, key enhancements for the GEO function include the introduction of a specific GEO satellite ID type and the support for a local switch via a User Plane Function (UPF) deployed on the satellite itself, particularly for GEO backhaul scenarios. This enables optimized IMS voice communication over GEO satellite access, which is required to support end-to-end latencies of up to 277 ms. The release also provides clarifications for the operation of this local switch, including aspects of N19 forwarding when the local switch is performed via a PSA UPF on GEO satellites.
In Release 19, the GEO function introduced enhancements for IMS-based global call services and provided clarifications for IMS voice over GEO, including a defined upper bound for call setup time. The specifications now explicitly require the 5G system to support GEO-based satellite access with an end-to-end latency of up to 277 ms. Furthermore, mechanisms to optimize IMS voice communication over GEO satellite access were formally mandated.
- Correction on GEO Satellite ID TS 29.571CR0629
In Release 20, the new GEO-specific enhancements focused on improving IMS voice services over geostationary satellite access. This included clarifications for IMS Voice over GEO and the introduction of mechanisms to optimize IMS voice communication to handle the inherent high latency, which can be up to 277 ms end-to-end. The work also explicitly addressed the call setup time for these voice services.
Explore further
Broader topics and technologies where GEO plays a role.
Defining Specifications
3GPP specifications that define or reference GEO, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 22.261 vk30 | 5G System Service Requirements | Rel-20 |
| TS 22.822 vg00 | Satellite Access in 5G Study | Rel-16 |
| TS 22.887 vk00 | Study on satellite access - Phase 4 | Rel-20 |
| TS 23.008 vj00 | Organization of Subscriber Data | Rel-19 |
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TR 23.737 vh20 | Satellite Access in 5G Architecture Study | Rel-17 |
| TR 23.799 ve00 | Study on Next Generation System Architecture | Rel-14 |
| TS 24.301 vj60 | NAS protocol for Evolved Packet System | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 25.172 vj00 | A-GANSS UE Minimum Performance Requirements (FDD) | Rel-19 |
| TS 25.173 vj00 | A-GANSS Performance Requirements (TDD) | Rel-19 |
| TR 28.808 vh00 | 5G satellite integration management study | Rel-17 |
| TR 28.841 vi01 | Technical Report on IoT NTN Enhancements | Rel-18 |
| TS 28.874 vj10 | Study on Management Aspects of NTN Phase 2 | Rel-19 |
| TS 29.212 vj00 | Gx/Gxx/Sd/St Diameter Protocol | 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.523 vj20 | 5G Policy Control Event Exposure Service | Rel-19 |
| TS 29.571 vj50 | Common Data Types for 5G Service Based Interfaces | Rel-19 |
| TS 36.102 vj10 | E-UTRA UE Satellite Access RF Requirements | Rel-19 |
| TS 36.108 vj10 | Satellite Access Node RF Requirements | Rel-19 |
| TS 36.171 vj10 | A-GNSS Minimum Performance Requirements for UE | Rel-19 |
| TS 36.181 vj30 | E-UTRA RF Test Methods for Satellite Access Node | Rel-19 |
| TS 36.521 vj00 | E-UTRA UE Conformance ICS Proforma | Rel-19 |
| TR 36.763 vh00 | NB-IoT/eMTC Support for Non-Terrestrial Networks | Rel-17 |
| TS 37.571 vj00 | UE Conformance for Positioning | Rel-19 |
| TS 38.101 vj31 | NR User Equipment Radio Transmissions | Rel-19 |
| TS 38.108 vj20 | NTN NR Satellite Access Node RF Requirements | Rel-19 |
| TS 38.171 vj10 | 5G A-GNSS UE Positioning Requirements | Rel-19 |
| TS 38.181 vj10 | NR Satellite Access Node RF Testing | Rel-19 |
| TS 38.521 vj20 | NR Physical Layer UE Conformance Testing | Rel-19 |
| TS 38.741 vj00 | NTN L-/S-band for NR Technical Specification | Rel-19 |
| TS 38.811 vf40 | Study on NR Support for Non-Terrestrial Networks | Rel-15 |
| TS 38.821 vg20 | NR Support for Non-Terrestrial Networks | Rel-16 |
| TS 38.863 vj10 | NR NTN RF and Co-existence Spec | Rel-19 |
| TR 38.913 vj00 | Next Gen Access Tech Scenarios & Requirements | Rel-19 |