top of page

NR-NTN Architecture: How 5G NR Connects Smartphones Through Satellites

6 minutes ago
20 min read

Introduction to NR-NTN

NR-NTN (New Radio Non-Terrestrial Network) is an important component of the evolution of 5G connectivity. It extends the 5G New Radio (NR) air interface beyond conventional terrestrial cellular infrastructure by enabling communication through non-terrestrial platforms such as satellites.

Traditional 5G networks rely on terrestrial base stations, commonly called gNBs, to provide wireless connectivity to user equipment (UE). However, deploying terrestrial infrastructure across oceans, remote villages, mountainous regions, deserts, and other underserved locations can be challenging and expensive.

NR-NTN addresses this limitation by enabling compatible user equipment to communicate with a terrestrial 5G network through satellite-based radio access infrastructure.

The Third Generation Partnership Project (3GPP) introduced standardized support for NR-based Non-Terrestrial Networks in Release 17. Subsequent releases have continued to enhance NTN capabilities and related specifications.

In an NR-NTN deployment, a satellite can act as a transparent radio-frequency relay, forwarding signals between a user device and a ground-based network infrastructure. The terrestrial gNB continues to perform essential NR baseband processing, while the satellite payload relays the radio signal between the service link and the feeder link.

Understanding NR-NTN requires examining its architecture, radio interfaces, transparent payload operation, NTN Gateway, gNB processing, and integration with the 5G Core Network (5GC).


NR-NTN 5G Satellite Network Architecture
NR-NTN 5G Satellite Network Architecture

Table of Contents

NR-NTN is a Non-Terrestrial Network that supports the 5G New Radio air interface.

It enables an NR-compatible UE to communicate with a 5G network using a radio access path that includes a non-terrestrial platform, such as a satellite.

Unlike a conventional terrestrial NR deployment, where a UE communicates directly with a terrestrial gNB over the NR Uu interface, an NR-NTN deployment can route the radio signal through a satellite payload and an NTN Gateway.

A representative transparent-payload architecture contains the following components:

  • NR-NTN UE: The user equipment that transmits and receives 5G NR signals.

  • Transparent NTN Payload: The satellite-based radio relay that forwards signals between the service link and the feeder link.

  • NTN Gateway: The ground-based infrastructure connecting the satellite feeder link to the network-side radio access infrastructure.

  • NR-NTN gNB: The 5G NR base station responsible for radio access processing, scheduling, and communication with the 5G Core.

  • 5G Core Network (5GC): The core network responsible for functions such as registration, session management, and user-plane connectivity.

  • User Plane Function (UPF): The core network function that forwards user data between the 5G network and an external data network.

  • Access and Mobility Management Function (AMF): The core network function responsible for access and mobility management.

The exact implementation depends on the NTN architecture. This article focuses primarily on a transparent-payload NR-NTN architecture in which the gNB performs the principal NR baseband processing on the ground.


Why Is NR-NTN Important?

NR-NTN can help extend cellular connectivity to locations where terrestrial coverage is unavailable or difficult to deploy.

Potential application areas include:

  • Connectivity in remote and rural locations.

  • Communication across oceans and maritime routes.

  • Connectivity for aviation and transportation.

  • Emergency communication during natural disasters.

  • Public safety and disaster recovery.

  • Remote industrial operations.

  • Connectivity for selected Internet of Things (IoT) applications.

  • Complementary coverage for terrestrial mobile networks.

NR-NTN does not simply place a conventional terrestrial base station in space. It requires adaptations to the radio interface and network operation to address satellite-specific conditions, including propagation delay, Doppler effects, and satellite movement.


  1. NR-NTN Architecture Overview

A representative NR-NTN architecture consists of a UE, a transparent satellite payload, an NTN Gateway, a terrestrial gNB, and the 5G Core Network.

The end-to-end connectivity path can be represented as follows:

NR-NTN UE ↔ Service Link ↔ Transparent NTN Payload ↔ Feeder Link ↔ NTN Gateway ↔ gNB ↔ 5G Core Network ↔ Data Network

This simplified representation illustrates the main components involved in communication.

The service link connects the UE with the non-terrestrial radio platform. The feeder link connects the satellite payload with the NTN Gateway on the ground.

The NR Uu interface defines the radio interface between the UE and the NR network. In a transparent-payload implementation, the satellite relays the radio signal rather than performing all the NR baseband processing itself.

The feeder-link implementation is different from the standardized UE-facing NR radio interface. It can use implementation-specific radio technology and frequency arrangements. An implementation may also use NR waveforms on the feeder link, provided the overall system is designed accordingly.

The logical interface between the NTN Gateway function and the gNB is implementation-dependent in this representative architecture. Depending on the deployment, Gateway-related functions may be integrated into the gNB implementation rather than represented as a separate standardized network node.


Main Components of NR-NTN Architecture

  1. NR-NTN User Equipment

The UE is the endpoint used by subscribers or applications. It performs NR baseband processing, protocol operations, and radio-frequency transmission and reception.

Depending on the device and deployment, the UE may transmit user data, control-plane signaling, random-access preambles, scheduling requests, and other physical-layer signals.

  1. Transparent NTN Payload

The transparent payload receives the uplink radio signal from the UE, applies appropriate radio-frequency processing, and forwards the signal toward the ground infrastructure.

Typical operations can include frequency translation, RF filtering, and amplification. The exact implementation depends on the satellite payload design.

  1. NTN Gateway

The NTN Gateway provides the ground-side radio-frequency connection to the satellite feeder link. It receives the forwarded uplink signal and delivers it to the network-side gNB processing path.

For downlink transmission, it transmits the signal received from the gNB toward the transparent satellite payload.

  1. NR-NTN gNB

The gNB performs NR baseband processing and radio resource management. It processes uplink transmissions, generates downlink transmissions, manages scheduling, and exchanges control-plane and user-plane information with the 5G Core.

  1. 5G Core Network

The 5GC supports subscriber connectivity and end-to-end service delivery. The AMF supports access and mobility management, while the UPF handles user-plane packet forwarding.

These components work together to deliver connectivity through a satellite-assisted radio access path.


  1. Understanding the NR Uu Interface in NR-NTN

The NR Uu interface is the standardized radio interface between NR user equipment and the NR network.

In a transparent-payload NR-NTN architecture, the service or access link uses the NR Uu interface adapted for NTN operation.

The satellite does not necessarily terminate the complete NR Uu protocol stack. Instead, the transparent payload relays the radio-frequency signal toward the ground network.

This distinction is important because the UE communicates using the NR radio interface even though the physical propagation path includes a satellite.

Terrestrial NR Versus NR-NTN

In a conventional terrestrial deployment, the communication path is generally:

UE ↔ NR Uu ↔ Terrestrial gNB ↔ 5GC

In a representative transparent-payload NR-NTN deployment, the path becomes:

UE ↔ NR Uu Service Link ↔ Transparent Satellite Payload ↔ Feeder Link ↔ NTN Gateway ↔ gNB ↔ 5GC

The principal difference is the additional satellite relay and feeder-link segment.

The presence of the satellite changes propagation conditions, timing requirements, frequency behavior, and certain radio procedures. Therefore, NR-NTN requires specific enhancements to the baseline NR air interface.

Service Link and Feeder Link

The service link and feeder link have different roles.

Service Link

The service link connects the UE with the satellite payload. It carries the NR radio signal associated with the UE's communication with the NR network.

Feeder Link

The feeder link connects the satellite payload with the NTN Gateway. It transports the radio signal between the satellite and ground infrastructure.

The service link is associated with the UE-facing NR Uu radio interface. The feeder link is implementation-specific in the architecture described here and is not inherently required to use the same waveform or frequency arrangement as the service link.

This separation gives network designers flexibility in implementing the satellite-to-ground connection.


  1. Why Does NR-NTN Need Enhancements to the NR Air Interface?

The baseline terrestrial NR air interface was designed primarily around terrestrial radio propagation and network deployment assumptions.

Satellite communication introduces different operating conditions. The 3GPP therefore enhanced NR to support NTN-specific requirements.

Some important challenges include the following.

4.1 Long Propagation Delay

Satellite links generally introduce more propagation delay than terrestrial cellular links because the signal must travel between the ground and a satellite.

The total delay depends on satellite altitude, the UE's location, the Gateway location, the routing architecture, and whether the communication path uses a single or multiple satellite hops.

Longer propagation delays affect procedures such as random access, timing alignment, scheduling, and retransmission.

NTN-aware procedures and timing adaptations help the system operate under these conditions.

4.2 Doppler Shift

Relative movement between the UE, satellite, and ground infrastructure can cause Doppler frequency shifts.

These shifts can affect frequency synchronization and radio reception. Their magnitude depends on factors such as satellite motion, the propagation geometry, and the radio frequency.

NR-NTN systems must account for Doppler-related effects to maintain reliable communication.

4.3 Timing Alignment

In cellular systems, uplink transmissions from multiple UEs must arrive at the receiver within appropriate timing boundaries.

In NTN deployments, the differences in propagation delay between UEs can be substantial. The system must therefore support suitable timing management and timing-advance procedures.

4.4 Random Access

Random access allows a UE to initiate access to the network and establish the necessary radio connection.

Satellite propagation delay and timing uncertainty can affect the random-access procedure. NTN-specific enhancements help accommodate the conditions encountered in satellite communication.

4.5 Mobility and Satellite Movement

A satellite may move relative to the UE and the Gateway, changing the radio geometry over time.

Depending on the orbit and architecture, the system may need to manage changes in satellite visibility, service-link conditions, and access coverage.

NTN mobility procedures and network configuration help support communication as these conditions change.

These enhancements allow NR-based systems to operate in non-terrestrial environments while retaining the broader 5G NR framework.


  1. NR-NTN Uplink Data Flow: From UE to the 5G Network

The uplink is the communication direction from the UE toward the network.

For example, when a user sends a message, uploads a file, or transmits application data through an NR-NTN connection, the uplink radio path carries the information from the UE toward the ground network.

In the representative transparent-payload architecture, the uplink follows several stages.

Step 1: UE Generates Uplink Information

The NR-NTN UE prepares the information that must be transmitted.

This information can include:

  • User-plane data.

  • Access Stratum (AS) signaling.

  • Non-Access Stratum (NAS) signaling.

  • Random-access preambles.

  • Scheduling requests.

  • Other physical-layer control information.

The type of information depends on the procedure being performed.

For user-plane traffic, application data is carried through the appropriate protocol layers before transmission over the NR radio interface.

Step 2: UE Performs NR Baseband Processing

The UE performs the required NR baseband processing to generate the uplink transmission.

Depending on the transmission and protocol procedure, this processing includes channel coding, modulation, resource mapping, and other physical-layer operations.

The UE also applies the necessary RF processing to transmit the signal using the configured NR-NTN radio parameters.

The transmitted signal must comply with the applicable radio requirements for the relevant NTN deployment.

Step 3: Satellite Receives the Uplink Signal

The transparent NTN payload receives the UE's uplink RF signal over the service link.

In a typical transparent-payload implementation, the payload does not perform the complete NR baseband processing required to decode the UE's user-plane packets.

Instead, it relays the received radio signal toward the NTN Gateway.

Where multiple UEs transmit within the same cell's configured radio resources, the satellite payload receives the applicable composite uplink signal within its supported bandwidth and filtering configuration.

Step 4: Transparent Payload Performs RF Processing

The satellite payload applies the radio-frequency processing required by its implementation.

This may include:

  • Frequency translation.

  • RF filtering.

  • Signal amplification.

  • Other payload-specific RF operations.

Frequency translation can map the received service-link signal to the carrier frequency used for the feeder link.

The exact processing depends on the satellite payload and system design.

Step 5: NTN Gateway Receives the Feeder-Link Signal

The satellite forwards the processed uplink signal through the feeder link to the NTN Gateway.

The Gateway receives the RF signal and supplies it to the network-side radio access processing path.

The implementation determines how the Gateway and gNB functions are physically connected and how the signal is presented to the gNB.

Step 6: gNB Performs NR Baseband Processing

The NR-NTN gNB performs the necessary NR baseband processing to recover the transmitted information.

Depending on the signal and procedure, this includes processing the received physical-channel transmission, decoding the relevant information, and delivering it to the appropriate protocol layers.

For user-plane traffic, the gNB processes the radio transmission and obtains the relevant data packets.

For control-plane procedures, the gNB handles the applicable signaling according to the NR protocol architecture.

The gNB then forwards the information through the appropriate network path.

Step 7: gNB and 5GC Process the Information

The gNB interacts with the 5G Core as required by the relevant procedure.

The AMF supports access and mobility management. User-plane traffic follows the applicable PDU session and forwarding configuration.

For an established PDU session, the gNB can forward user-plane packets toward the appropriate UPF over the N3 interface.

The UPF forwards the packets toward the associated data network according to the applicable session and forwarding rules.

Uplink flow summary:

UE → NR Uu Service Link → Transparent NTN Payload → Feeder Link → NTN Gateway → gNB → N3 → UPF → Data Network

This sequence illustrates how a signal transmitted by a UE over a satellite-assisted radio path can reach an external IP network.


  1. NR-NTN Downlink Data Flow: From the Network to the UE

The downlink is the communication direction from the network toward the UE.

Examples include receiving an application message, downloading a file, viewing online content, or receiving other IP-based services.

The downlink follows the reverse radio path, although the network-side processing differs from the uplink.

Step 1: Data Network Sends Packets to the UPF

An external data network provides IP packets intended for the UE.

For an established PDU session, the applicable UPF receives and forwards the user-plane traffic according to the session's forwarding configuration.

Step 2: UPF Forwards Packets to the gNB

The UPF forwards user-plane packets toward the gNB using the N3 interface.

The packets are associated with the relevant PDU session and UE context.

The gNB receives the user-plane traffic and prepares it for radio transmission.

Step 3: gNB Performs Downlink Baseband Processing

The NR-NTN gNB performs the required NR downlink processing.

The scheduler allocates radio resources to the UEs according to traffic requirements, radio conditions, and applicable scheduling rules.

The gNB determines relevant transmission parameters, which may include modulation and coding scheme (MCS), transport-block size, and allocated resources.

The gNB then generates the downlink NR transmission.

Step 4: gNB Sends the Signal Toward the NTN Gateway

The gNB's downlink RF signal is delivered to the NTN Gateway through the implementation-specific connection.

The Gateway transmits the signal over the satellite feeder link toward the transparent NTN payload.

The exact physical and logical arrangement depends on the deployment.

Step 5: Transparent Payload Processes the Downlink Signal

The transparent satellite payload receives the downlink signal from the Gateway.

It performs the required RF operations, which may include frequency translation, filtering, and amplification.

Frequency translation can map the feeder-link signal to the appropriate carrier frequency for the service link.

The payload then transmits the resulting RF signal toward the UE.

Step 6: UE Receives the NR-NTN Downlink Signal

The UE receives the satellite-transmitted signal and performs the necessary RF and NR baseband processing.

The UE monitors the relevant physical downlink control channel (PDCCH) to obtain scheduling and control information when required.

When resources are allocated, the UE processes the corresponding physical downlink shared channel (PDSCH) transmission to recover the transmitted information.

The recovered data is delivered through the relevant protocol layers to the application or service using the connection.

Downlink flow summary:

Data Network → UPF → N3 → gNB → NTN Gateway → Feeder Link → Transparent NTN Payload → NR Uu Service Link → UE

Together, the uplink and downlink procedures provide bidirectional communication between the UE and the 5G network.


  1. Role of the Transparent NTN Payload

The transparent payload is a key component of the architecture described in this article.

It acts as a radio-frequency relay between the UE-facing service link and the ground-facing feeder link.

The term transparent refers to the payload's relay role: it does not perform the full set of NR gNB baseband functions in the representative architecture.

Instead, the principal NR baseband processing remains on the ground at the gNB.

Key Functions of a Transparent Payload

  1. RF Signal Reception

The payload receives radio signals transmitted over the relevant satellite link.

  1. Frequency Translation

The payload may translate the received RF signal to the frequency required for the onward link.

  1. RF Filtering

Filtering helps control the frequency components passed through the payload and supports the intended radio configuration.

  1. Signal Amplification

Amplification compensates for signal-level requirements within the payload's RF chain.

  1. RF Signal Retransmission

The payload retransmits the processed signal over the onward link.

What Does the Transparent Payload Not Do?

In the representative transparent-payload architecture, the payload does not act as a complete terrestrial-style NR gNB performing all UE-facing NR baseband processing.

Functions such as NR scheduling, decoding, and higher-level radio access processing remain associated with the ground-based gNB.

This distinction should not be generalized to every NTN architecture. Regenerative satellite architectures can place additional processing functions on the non-terrestrial platform.


  1. Role of the NTN Gateway

The NTN Gateway provides the ground-side connection between the satellite feeder link and the network infrastructure.

It is an important part of the signal path because the satellite payload must exchange radio signals with the terrestrial network.

Main Gateway Responsibilities

  • Transmitting downlink RF signals toward the satellite.

  • Receiving uplink RF signals from the satellite.

  • Supporting the feeder-link connection.

  • Providing the relevant signal path to the gNB.

  • Supporting implementation-specific RF and infrastructure functions.

The Gateway's exact functional boundaries depend on the system design.

In some implementations, Gateway-related functions may be closely integrated with the gNB infrastructure. Consequently, the Gateway should not automatically be interpreted as a separate standardized NR protocol endpoint.

The distinction between a physical infrastructure component and a standardized logical network function is important when analyzing NR-NTN architecture.


  1. Role of the NR-NTN gNB

The NR-NTN gNB is responsible for the principal NR radio access processing in the transparent-payload architecture.

Although the radio path passes through a satellite, the gNB continues to perform the relevant NR baseband and network-facing operations.

Important gNB Functions

Uplink Processing: Receives the signal delivered through the Gateway path and processes the NR transmission to recover the relevant information.

Downlink Processing: Generates NR downlink transmissions using the appropriate physical channels and transmission parameters.

Radio Resource Scheduling: Allocates radio resources to UEs according to the applicable scheduling and radio conditions.

Control-Plane Handling: Processes relevant NR radio signaling and supports the necessary control-plane procedures.

User-Plane Forwarding: Exchanges user-plane traffic with the 5GC through the applicable interfaces.

Core Network Integration: Interacts with the appropriate 5GC functions to support connectivity and service delivery.

The gNB must also operate with the NTN-specific radio and timing assumptions configured for the deployment.


  1. How NR-NTN Integrates with the 5G Core Network

NR-NTN can use the broader 5G Core architecture for subscriber connectivity, session management, and user-plane delivery.

The non-terrestrial radio access path does not eliminate the need for the core network. Instead, it provides an alternative way for the UE to reach the NR network.

Two important 5GC functions are the AMF and UPF.

Access and Mobility Management Function (AMF)

The AMF supports access and mobility management procedures.

Its responsibilities include relevant registration and access-management functions, subject to the applicable 5GC architecture and procedures.

User Plane Function (UPF)

The UPF forwards user-plane packets between the 5G network and external data networks.

For an established PDU session, the gNB and UPF exchange user-plane traffic over N3.

Example: Sending an IP Packet Over NR-NTN

Consider a UE that sends an IP packet to a remote application server.

  1. The UE prepares the packet for transmission.

  2. The NR radio interface carries the uplink transmission toward the satellite.

  3. The transparent payload relays the RF signal toward the Gateway.

  4. The Gateway delivers the signal to the gNB processing path.

  5. The gNB processes the radio transmission and obtains the user-plane packet.

  6. The gNB forwards the packet toward the appropriate UPF over N3.

  7. The UPF forwards the packet toward the destination data network according to the PDU session's forwarding configuration.

For the return direction, packets travel from the data network through the UPF and gNB, then through the Gateway and satellite relay, before reaching the UE.

This illustrates how satellite-based radio access can be integrated with the familiar 5G Core user-plane architecture.


  1. NR-NTN Frequency and RF Considerations

NR-NTN requires suitable radio-frequency configurations for communication between the UE and the non-terrestrial platform.

The supported frequency bands depend on the applicable 3GPP specifications, device capabilities, and deployment.

The feeder link has its own implementation-specific frequency and RF requirements.

For this reason, engineers should distinguish between the UE-facing NTN service link and the satellite-to-Gateway feeder link when evaluating RF design.

Important RF Considerations

Operating Band: The UE and radio access system must support the configured NTN operating band.

Channel Bandwidth: The RF chain must support the applicable channel bandwidth and signal requirements.

Frequency Translation: The transparent payload may translate signals between service-link and feeder-link frequency arrangements.

RF Filtering: Filtering must support the intended frequency plan and signal characteristics.

Amplification and Link Budget: The system must account for satellite link loss, antenna characteristics, transmit power, receiver sensitivity, and other relevant link-budget parameters.

Frequency Synchronization: Doppler and frequency-reference considerations are important to reliable signal reception.

RF Performance and Compliance: Equipment must satisfy the applicable radio-frequency and performance requirements for its role.

3GPP TS 38.101-5 specifies NR UE satellite-access RF and performance requirements. The corresponding satellite access node requirements are covered by TS 38.108.

Engineers should consult the relevant specification version and release rather than assuming that all bands, bandwidths, or capabilities are supported by every NR-NTN device.


  1. Transparent Versus Regenerative NTN Architecture

NR-NTN systems can use different payload architectures. Two important concepts are transparent and regenerative payloads.

Transparent NTN

In a transparent architecture, the satellite primarily relays radio signals between the service link and the feeder link.

The main NR baseband processing is performed by the ground-based gNB.

Key characteristics:

  • Radio-frequency relay operation on the satellite.

  • Ground-based NR gNB processing.

  • Satellite-to-Gateway feeder-link connectivity.

  • Implementation-specific Gateway integration.

  • Dependence on the feeder-link path to the ground network.

Regenerative NTN

In a regenerative architecture, the non-terrestrial platform performs additional processing functions.

Depending on the design, these functions may include some or more of the processing traditionally performed by ground-based radio access infrastructure.

The exact architecture determines which protocol and baseband functions reside on the satellite and which remain on the ground.

Key Differences

Parameter

Transparent Payload

Regenerative Payload

Primary satellite role

RF signal relay

Performs additional processing

NR baseband processing

Primarily on the ground in the architecture discussed here

May be partly or substantially on the non-terrestrial platform

Ground gNB role

Performs principal NR processing

Depends on the distribution of functions

Satellite processing complexity

Generally lower

Generally higher

Feeder-link role

Carries relayed radio signals

Depends on the selected functional split

Deployment considerations

Satellite relay and ground processing design

Onboard processing, payload complexity, and functional placement

Neither architecture is universally better for every deployment. The appropriate design depends on satellite capabilities, service requirements, deployment constraints, and the intended division of network functions.


  1. Key Technical Challenges in NR-NTN Deployment

Although NR-NTN extends the reach of NR connectivity, engineers must consider several design challenges.

13.1 End-to-End Latency

Satellite propagation adds delay to the communication path.

Latency depends on the orbit, path geometry, processing, feeder-link routing, and overall network architecture.

The satellite's presence alone does not determine the complete end-to-end latency.

13.2 Link Budget and Coverage

Reliable communication depends on the available link budget.

Antenna gain, transmit power, propagation loss, atmospheric effects, interference, receiver performance, and satellite geometry can affect the quality of the connection.

13.3 Doppler and Synchronization

Satellite movement can introduce frequency shifts and time-varying propagation conditions.

The UE and network must use appropriate synchronization and NTN-specific procedures.

13.4 Radio Resource Scheduling

The gNB must schedule radio resources while accounting for the applicable NTN propagation and timing characteristics.

Scheduling and timing procedures must be appropriate for the specific deployment.

13.5 Gateway Availability and Feeder-Link Capacity

The feeder link connects the satellite payload with the ground infrastructure.

Its capacity, availability, frequency plan, and implementation affect the end-to-end service.

13.6 UE Compatibility

Not every 5G smartphone automatically supports every NR-NTN configuration.

Compatibility depends on the device's radio capabilities, supported bands, firmware, network implementation, and applicable service requirements.

13.7 Mobility and Coverage Continuity

Satellite movement and changes in service-link geometry can affect coverage continuity.

The required mobility behavior depends on the satellite orbit, constellation design, network configuration, and service requirements.

Addressing these challenges requires coordinated radio, satellite, Gateway, and core network engineering.


  1. Practical NR-NTN Example: Delivering Connectivity to a Remote Location

Consider a remote location where conventional terrestrial cellular coverage is unavailable.

A compatible UE connects to an NR-NTN service through a satellite-based radio path.

The following sequence describes a simplified user-plane transaction.

Scenario: A user uploads a document to a cloud application.

  1. The UE prepares the IP packets containing the document data.

  2. The UE performs the necessary NR-NTN radio processing.

  3. The UE transmits the uplink signal over the service link.

  4. The transparent satellite payload receives the signal and applies the required RF processing.

  5. The payload forwards the signal over the feeder link to the NTN Gateway.

  6. The Gateway delivers the signal to the gNB processing path.

  7. The gNB processes the uplink transmission and recovers the user-plane data.

  8. The gNB forwards the packets toward the UPF over N3.

  9. The UPF forwards the packets to the external data network.

  10. The remote application receives the uploaded data.

When the application sends a response, the downlink process carries the response packets through the UPF and gNB, followed by the Gateway, satellite payload, and service link to the UE.

This example demonstrates the relationship between NR radio processing, satellite signal relay, and 5GC user-plane forwarding.

It also shows why NR-NTN should be understood as an end-to-end network architecture rather than merely a satellite radio link.


  1. Important 3GPP Specifications for NR-NTN

Engineers working with NR-NTN should consult the relevant 3GPP specifications for detailed requirements and procedures.

The following specifications are particularly relevant to the architecture discussed in this article.

3GPP TS 38.300 — NR and NG-RAN Overall Description

TS 38.300 describes the overall NR and NG-RAN architecture and related procedures. Its NTN-related provisions are useful for understanding how NR supports non-terrestrial operation.

3GPP TS 38.101-5 — NR UE Satellite-Access RF Requirements

TS 38.101-5 defines the UE-side RF transmission, reception, and performance requirements applicable to satellite access.

It is relevant when studying UE capabilities, supported NTN operating bands, and RF conformance requirements.

3GPP TS 38.108 — NR Satellite Access Node RF Requirements

TS 38.108 covers radio transmission and reception requirements for the NR Satellite Access Node.

It is relevant to the satellite-access infrastructure side of NR-NTN RF design.

Why Release and Version Selection Matters

3GPP specifications evolve through successive releases and approved changes.

Release 17 introduced foundational NR-NTN support, while later releases have added and refined capabilities.

Therefore, engineers should identify the release and version relevant to their equipment, implementation, and testing requirements.

For implementation and conformance work, always refer to the applicable specification text rather than relying exclusively on a high-level overview.


Conclusion

NR-NTN extends the 5G NR air interface to non-terrestrial communication environments, helping provide connectivity where conventional terrestrial infrastructure may be limited.

In the transparent-payload architecture, the UE communicates with the satellite over the NR Uu service link. The satellite relays the RF signal through a feeder link to an NTN Gateway, which provides the connection to the ground-based gNB processing path.

The gNB performs the principal NR baseband processing and exchanges control-plane and user-plane information with the 5G Core Network.

On the uplink, data moves from the UE through the satellite relay and gNB toward the UPF and external data network. On the downlink, data travels from the data network through the UPF and gNB before being transmitted through the Gateway and satellite to the UE.

Understanding these interactions is essential for engineers studying 5G satellite access, NR radio procedures, NTN RF requirements, and end-to-end network architecture.

As NTN capabilities continue to evolve, knowledge of NR-NTN architecture will be increasingly valuable for professionals working in 5G, satellite communications, RF engineering, protocol testing, and next-generation network development.


Frequently Asked Questions (FAQs)

  1. What is NR-NTN in 5G?

NR-NTN stands for New Radio Non-Terrestrial Network. It enables NR-based connectivity through non-terrestrial platforms such as satellites.


  1. Which 3GPP release introduced NR-NTN?

3GPP Release 17 introduced standardized foundational support for NR-NTN. Later releases have continued to enhance NTN capabilities.


  1. What is the NR Uu interface in NR-NTN?

NR Uu is the standardized radio interface between NR UE and the NR network. In the transparent-payload architecture, the service link uses this interface, with NTN-specific enhancements to support satellite communication.


  1. What is the difference between a service link and a feeder link?

The service link connects the UE to the satellite payload. The feeder link connects the satellite payload to the NTN Gateway on the ground.


  1. What is a transparent NTN payload?

A transparent NTN payload primarily relays RF signals between the service link and feeder link. In the architecture described here, the main NR baseband processing is performed by a ground-based gNB.


  1. What is the role of an NTN Gateway?

The NTN Gateway provides the ground-side connection between the satellite feeder link and the network infrastructure. It receives uplink signals from the satellite and transmits downlink signals toward it.


  1. Does the satellite perform all gNB functions in transparent NR-NTN?

No. In the transparent-payload architecture discussed here, the principal NR baseband processing remains on the ground. Regenerative architectures can distribute additional processing functions to the satellite.


  1. How does uplink data reach the 5G Core in NR-NTN?

The UE transmits the uplink signal over the service link. The satellite relays it over the feeder link to the Gateway, and the gNB processes the transmission before forwarding user-plane traffic toward the UPF over N3.


  1. How does downlink data reach an NR-NTN UE?

The UPF forwards user-plane packets to the gNB. The gNB generates the downlink NR signal, which is transmitted through the Gateway and transparent satellite payload before reaching the UE over the service link.


  1. Why does NR-NTN need special NR enhancements?

Satellite communication introduces longer propagation delays, Doppler shifts, timing challenges, and mobility-related conditions that differ from conventional terrestrial cellular networks.


  1. Which 3GPP specifications are important for NR-NTN?

Relevant specifications include TS 38.300 for NR and NG-RAN overall architecture, TS 38.101-5 for UE satellite-access RF requirements, and TS 38.108 for Satellite Access Node RF requirements.


  1. Does every 5G smartphone support NR-NTN?

No. Support depends on device hardware, supported radio bands, software, network configuration, and the specific NTN service.


Suggested Internal Linking Opportunities

Add links to related articles on your website where the relevant content is available:

  1. Introduction to 5G Non-Terrestrial Networks (NTN) — Link to your NTN overview article.

  2. NTN Network Architectures Explained — Link to your architecture comparison article.

  3. 3GPP Solutions to NTN Challenges — Link to your article on delay, Doppler, synchronization, and mobility.

  4. 5G NR Architecture and Protocol Stack — Link to your NR architecture article.

  5. 5G Core Network Architecture: AMF, SMF, and UPF — Link to your 5GC article.

  6. 5G Protocol Testing and Log Analysis — Link to your protocol testing and troubleshooting content.

Use descriptive anchor text and link only to published, relevant pages. Replace these suggested titles with the actual URLs of your existing articles.


Suggested External References

For technical accuracy, link to the official 3GPP specification pages for TS 38.300, TS 38.101-5, and TS 38.108. These references allow readers to explore the standardized architecture and radio requirements directly.

 

Comments


  • Facebook
  • Twitter
  • LinkedIn

©2022 by Apeksha Telecom-The Telecom Gurukul . 

bottom of page