GEO

Geostationary satellite Earth Orbit

Radio Access Network →
Introduced in Rel-12 Also in: Radio Access Network, User Equipment, Services, Management, Testing

GEO is a satellite orbit approximately 35,786 km above the equator where the satellite appears stationary, used in 3GPP Non-Terrestrial Networks for wide-area coverage and direct-to-device communication.

Category
Radio Access Network
Introduced
Rel-12
Where
Core Network › 5G Core
Also touches
5 segments
Specifications
37 specs
GEO Description Purpose Related Classification Detected Changes Specifications

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

Part ofNTN
Related approachesLEOMEO

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-18 4 changes

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.

  • Support of local switch via UPF deployed on satellite for GEO backhaul case TS 23.501CR3794
  • Clarification of N19 forwarding for local switch via PSA UPF on GEO TS 23.501CR3999
  • Adding GEO satellite ID type TS 29.571CR0397
  • Clarification of local switch via UPF on GEO satellites TS 23.501CR4422
Rel-19 1 change

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
Rel-20 3 changes

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.

  • Enhancements for IMS-based GEO Global Call Services TS 22.261CR0817
  • CR on IMS Voice over GEO clarifications TS 22.261CR0852
  • Voice over GEO Call Setup Time TS 22.261CR0858

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.

SpecificationTitleRelease
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
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.