HHashi IP Solutions
NTN IP Intelligence

Regenerative NTN Payloads: Patent Landscape, Satellite gNB & 3GPP IP Opportunities

Regenerative payloads move base station functionality into orbit. This analysis maps the technical architecture — satellite gNB, inter-satellite links, mobility and feeder-link switching — to the patent and 3GPP standards-driven IP opportunities forming around it.

HR
By Hashi IP Solutions
Telecom & Standards Intelligence Team
August 29, 2026 15 min read
#NTN#SEP#Landscape
Layered diagram of a regenerative NTN architecture showing satellite gNB, onboard compute, inter-satellite links, feeder-link switching and ground core network

For most of satellite communications history, the payload was a mirror. A signal went up, was amplified and frequency-shifted, and came back down. The intelligence lived on the ground. Regenerative payloads invert that assumption: the satellite demodulates, decodes, and acts on the signal — and in a 3GPP context, it can host the base station itself. That shift is architectural, not incremental, and architectural shifts are historically where durable intellectual property forms.

"Transparent payloads move bits. Regenerative payloads make decisions — and decisions are where patentable invention concentrates."

Transparent vs Regenerative: What Actually Changes

3GPP's NTN work defines both transparent and regenerative payload architectures. In a transparent architecture the satellite performs radio-frequency filtering, frequency conversion and amplification; the gNB remains on the ground and the satellite is, functionally, a very tall tower with a Doppler problem. In a regenerative architecture the satellite performs demodulation and decoding, and may host the full gNB or a subset of its functions. The consequences ripple across the entire system design: where the protocol stack terminates, how the interface to the core network is carried, how handovers are executed, how the network behaves when the satellite moves out of view of its gateway, and how much compute, memory and power must be flown.

Architectural comparison
DimensionTransparent payloadRegenerative payload
Onboard processingRF filtering, conversion, amplificationDemodulation, decoding, protocol processing
gNB locationGround segmentOn board, in whole or in part
Feeder link carriesRadio waveformBackhaul / interface traffic
Latency profileFull round trip via gatewayLocal termination possible
Inter-satellite routingGenerally not applicableCentral to constellation operation
Complexity movedGroundSpace

Architectural options are described in 3GPP NTN specifications; deployment choices vary by operator and constellation.

The Satellite gNB: A Base Station With Orbital Mechanics

Placing gNB functionality in orbit means the base station is no longer stationary relative to its users, its neighbours, or its own core network. A LEO satellite traverses the sky in minutes; cells sweep across the ground or must be steered to remain fixed; the connection to the ground gateway is itself intermittent and must be handed over. Every assumption baked into terrestrial RAN design — that the base station has stable backhaul, stable neighbours and a stable position — is renegotiated. Functional split decisions become strategic: a full gNB on board maximises autonomy but demands the most orbital compute; a CU/DU split places the distributed unit in space and the centralised unit on the ground, trading autonomy against payload budget.

Technical problems created by an orbital gNB

  • Functional split selection and the interface behaviour it implies across a moving link.
  • Onboard compute, thermal and power budgeting for real-time baseband processing.
  • Radiation-tolerant processing architectures and software update mechanisms in orbit.
  • Synchronisation and timing distribution without continuous ground reference.
  • State handling when the serving satellite changes while the session persists.

Inter-Satellite Links: Routing Inside a Moving Network

Once processing is on board, traffic no longer has to descend to the ground at the first opportunity. Inter-satellite links allow a constellation to behave as a mesh network in motion, forwarding traffic across orbital planes until it reaches a satellite with gateway visibility — or, in future architectures, until it reaches the destination user directly. That capability introduces a routing problem with no terrestrial equivalent: the topology is deterministic but continuously changing, link availability is a function of orbital geometry, and path selection must account for latency, congestion, handover events and regulatory constraints on where traffic may land.

Regenerative traffic path
  1. 01User device
  2. 02Satellite gNB (onboard processing)
  3. 03Inter-satellite link routing
  4. 04Feeder link to gateway
  5. 05Ground core network

The engineering work here spans optical and RF link acquisition and pointing, mesh routing and topology prediction, congestion and QoS handling across a time-varying graph, and the security of traffic transiting multiple spacecraft. These are distinct technical domains, and filings in them may sit with satellite manufacturers, optical component specialists, network software vendors and telecom incumbents simultaneously — one reason the regenerative landscape is harder to read than a conventional RAN landscape.

Feeder-Link Switching: The Handover Nobody Sees

In a regenerative constellation, the link between satellite and ground gateway is itself mobile. As a satellite passes beyond a gateway's horizon, its feeder link must transfer to another gateway — potentially in another country, another regulatory regime, or another operator's ground network — without interrupting user sessions carried over it. This is a handover of the backhaul rather than the access link, and it has no direct terrestrial analogue. Solutions involve predictive scheduling based on ephemeris, make-before-break establishment, buffering and state transfer, and coordination with the core network so that session anchors and user-plane paths follow the switch.

Where feeder-link engineering concentrates

  • Ephemeris-driven prediction and pre-provisioning of the next gateway.
  • Make-before-break switching and interruption-time minimisation.
  • Context and state transfer between gateway sites.
  • User-plane anchoring and re-anchoring strategies in the ground core.
  • Regulatory and landing-rights-aware gateway selection.

Mobility: Three Layers Moving At Once

Terrestrial mobility management assumes one thing moves: the user. In a regenerative LEO system, the beam moves, the satellite moves, and the user may move as well. 3GPP's NTN work distinguishes earth-moving cells, where the beam footprint sweeps with the satellite, from quasi-earth-fixed cells, where beams are steered to hold a ground area for a period before switching. Each model produces a different handover pattern, a different signalling load, and a different set of optimisation problems — conditional handover configuration, measurement reporting adapted to predictable geometry, location-assisted cell selection and the use of ephemeris data broadcast to devices.

Mobility layers in a regenerative constellation

Beam mobility

Satellite / gNB mobility

User mobility

= High-quality, enforceable patent draft

Onboard Compute: The Constraint That Shapes Everything

Every function moved into orbit must be paid for in mass, power, thermal capacity and radiation tolerance. This constraint is what makes regenerative architecture an invention-dense field rather than a straightforward software port: designers are forced to find efficiency where terrestrial designers can simply add a server. Work concentrates on hardware acceleration of baseband functions, workload partitioning between space and ground, virtualisation and containerisation of network functions on constrained hardware, fault tolerance and graceful degradation, and secure over-the-air update of software running on an asset that cannot be visited.

Reading This as a Patent Landscape

A regenerative NTN patent landscape is not one landscape. It is the intersection of several filing communities that historically did not compete: space systems primes, satellite payload and component manufacturers, telecom infrastructure vendors, chipset and modem designers, and network software companies. Mapping it well means clustering by technical function rather than by applicant industry, and separating three questions that are frequently conflated — what is being filed, what is being standardized, and what is being implemented.

Functional clusters worth monitoring
ClusterRepresentative technical scope
Satellite gNB architectureFunctional splits, onboard protocol stack, interface termination
Onboard processingBaseband acceleration, virtualisation, radiation-tolerant compute
Inter-satellite linksOptical/RF acquisition and pointing, mesh routing, congestion control
Feeder-link switchingPredictive gateway handover, state transfer, re-anchoring
Mobility managementEarth-moving and quasi-earth-fixed cells, conditional handover, ephemeris assistance
Synchronisation & timingTiming advance, Doppler pre-compensation, autonomous reference
Security & integrityMulti-hop transit protection, onboard key handling, secure update

Cluster inclusion reflects where technical activity is visible; it implies nothing about patent volume, validity, essentiality or enforceability in any cluster.

Standards-to-Patent Mapping: The Step That Adds Rigour

The commercially useful question is rarely 'who has regenerative NTN patents'. It is whether specific claims read on behaviour that a compliant implementation must perform, or on behaviour a particular product does perform. Answering that requires mapping claim language to normative clauses, procedures and message fields in a named specification release — and distinguishing normative requirements from informative description and from optional features that an implementation may lawfully omit. A patent may be technically excellent, clearly relevant to regenerative NTN, and still not be essential to any standard.

Related Hashi capabilities

Where the IP Opportunities Sit

For organisations building or investing in regenerative systems, the practical opportunities fall into a small number of patterns. First, architectural whitespace: functional split and space-ground partitioning choices are still being explored, and early filings can shape a broad area. Second, constraint-driven invention: solutions that make orbital compute cheaper, cooler or more reliable have value independent of any single constellation. Third, standards-adjacent work: contributions and filings around procedures currently being specified may become relevant to implementations across the industry. Fourth, defensive positioning: understanding third-party filings early is what keeps design-around options open while the architecture is still fluid.

Building a Regenerative NTN IP Position?

Understand the patents, standards, competitors and architectural choices shaping regenerative payload systems before commitments harden.

Discuss your NTN IP strategy

Hyderabad, India — supporting clients across India, the United States, Europe and Asia.

Discuss your NTN IP strategy

Request a regenerative NTN landscape discussion

Tell us which part of the architecture matters to you — satellite gNB, ISL, feeder link or mobility — and we will follow up with a scoped approach.

NDA required

Frequently Asked Questions

Frequently asked questions

A regenerative NTN payload is a satellite payload that demodulates and decodes the received signal and performs protocol processing on board, rather than simply amplifying and forwarding it. In a 3GPP context it can host gNB functionality, in whole or as a functional split, in orbit.

HR
Written by
Hashi IP Solutions
Telecom & Standards Intelligence Team

Share this article

Related insights

All articles

Looking for expert insights?

Connect with our experts to accelerate innovation and unlock IP value.

Explore how AI-driven intellectual property solutions can strengthen your patent strategies, sharpen decisions, and create measurable business value.