How we reached a common vision on the architecture for 5G non-terrestrial networks in 3GPP Rel-19

The ongoing 3GPP work on Rel-19 is in itself a milestone in the integration of satellite technologies (NTN, Non-Terrestrial Networks) into 5G. Rel-19 will include NTN with a regenerative, or packet-processing, payload, in which a complete gNB is placed on the satellite.

In both Rel-17 and Rel-18, NTN was based on a transparent (bent-pipe) architecture, where the gNB in a textbook example is on the ground and the satellite acts as a radio repeater, as shown on the left side of Figure 1. Transparent architecture was adopted because it limits payload complexity and enables early deployment. In principle, even a previously deployed transparent payload could have been repurposed for Rel-17/18 NR NTN if it supported the correct RF requirements in the appropriate bands. The definition of “Satellite Access Node” adopted in Rel-17 by 3GPP RAN4 (the working group in charge of RF requirements and performance specifications), in practice went beyond the classical transparent architecture and enabled the distribution of certain gNB functions between Earth and space while maintaining the applicability of RAN4 specifications.

Figure 1: Transparent payload vs. regenerative payload

Transparent payload vs. regenerative payload – what’s the difference? 

In comparison to a transparent payload, a regenerative payload with a gNB (shown on the right side of Figure 1) is more flexible and offers better performance, enabling global coverage thanks to the support of the Xn inter-gNB interface for inter-satellite links. Satellite payload implementations gain access to a “toolbox” with all existing 5G functionality that relies on Xn, including inter-gNB mobility, resource coordination and energy saving.

Regenerative payloads make it possible to implement packet switching at various levels directly in the payload using inter-satellite links, without needing to go through the ground segment. NTN based on regenerative payloads is not only more flexible, but also more resilient, due to the ability to route traffic and hand over calls directly between satellites with minimal involvement of the core network on the ground.

A regenerative payload also delivers benefits with respect to the Uu (the interface between the RAN and the UE), including significant reductions in roundtrip time (RTT) for all procedures between the gNB and the UE, including random access and hybrid automatic repeat request (HARQ). These benefits do, however, come at the expense of slightly higher payload complexity and power consumption in comparison to a transparent payload.

The regenerative payload with gNB on board is also a necessary building block for the “store and forward” (S&F) functionality that is part of 3GPP Rel-19 (though only specified for supporting Internet-of-Things UEs). In S&F, all or part of the core network functions are placed on the satellite together with the gNB. S&F enables the NTN to function even if the feeder link is severed, allowing for even higher resiliency in case connectivity to the ground stations is lost. Regenerative payload also makes it possible to terminate connections between UEs directly in the satellites. This will bring so-called “data centers in the sky” even closer to reality and ensure full integration with existing 5G networks.

Taking on a new technological challenge

While bent-pipe payloads have been built for decades and are widely used by the satellites that broadcast TV to our homes today, placing a complete gNB on a satellite is a new technological challenge. Power, complexity, size and weight requirements are most critical for a satellite payload, to an even greater degree than they are in terrestrial networks.

Discussions within the NTN community about payload architectures first started alongside 3GPP meetings for Rel-16. A variety of alternatives were considered, including one based on the NG-RAN split gNB, where the gNB-CU would be on the ground, and the satellite would carry the gNB-DU. On paper, this payload architecture looked like it could reduce payload complexity: a gNB-DU includes a smaller set of functions than a gNB.

Without a complete system view it was not immediately clear that the drawbacks of the gNB-DU option far outweighed its advantages. Initially, many companies only considered the payload complexity and were unaware of the many suboptimal aspects related to network signaling. For this reason, when discussions on the Rel-19 work package started in January 2023, the payload architecture based on CU-DU split had the strongest support.

At this point, all parties involved – manufacturers and operators, both terrestrial and non-terrestrial – came together in an effort to better understand the technical implications of the choice we faced. A situation like this one really highlights the value of open technical discussion in 3GPP.

Making the case for regenerative payload with a gNB

Ericsson’s strong reputation among both terrestrial and non-terrestrial players for our competence on 5G RAN architecture enabled Ericsson delegates to become trusted speaking partners. We had the opportunity to explain our views on why a gNB payload was a much better option than a gNB-DU payload, including the following key points:

• gNB on board fully leverages all available 5G RAN functionality specified since Rel-15.
• The reuse of Xn means that gNB on board natively supports inter-satellite links, inter-satellite mobility, UP routing and S&F.
• In the case of gNB-DU on board, it would not be possible to natively support feeder link switch or S&F.
• In the case of gNB-DU on board, it would not be possible to leverage a standardized direct inter-satellite interface for e.g. inter-satellite mobility. Such an interface is not specified by 3GPP, which means it would have to be proprietary and could therefore increase the development cost.
• From a signaling point of view, a gNB-DU on board would be suboptimal. The RRC termination would be in the gNB-CU on the ground, and frequent DU-CU interactions over the F1 interface on the feeder link would be required – much more so than with a gNB on board.
• The perceived advantage of having only a gNB-DU on board is questionable: the gNB-DU hosts all the RF and physical layer functions, so it accounts for most of the complexity and power consumption in a gNB. “Carving out” a gNB-CU from a payload, then, does not accomplish much.

Implications of the transition from 5G to 6G

Another argument in favor of having the gNB on board is related to the timing of Rel-19 with respect to the foreseen transition between 5G and 6G, as illustrated in Figure 2. CU-DU split was introduced in Rel-15 and is a distinctive feature of NG-RAN. 6G studies are expected to start in 3GPP in Rel-20 (during 2025), and a potential future 6G RAN node can be expected to leverage a different split architecture, so at this point it does not seem justified to envisage the CU-DU split in 6G. Therefore, a gNB-DU payload and its required ground segment may prove challenging in terms of a possible evolution path toward 6G. This is not so (or at least less so) in the case of a gNB payload.

Figure 2: Evolution path toward 6G

The road to consensus can be rocky at times 

Our discussions with the key players and interested parties took a full year, over the span of four TSG RAN meetings. After anchoring our position within a small group of companies, the turning point came when important influencers in the NTN camp started to openly support the gNB payload. At this point the support in favor of CU-DU split could still be estimated at around 40%. But 3GPP works on consensus, so we knew that having roughly 60% support was not sufficient. Therefore, our efforts continued in the months that followed, including many one-on-one meetings where we focused on debunking misconceptions about the CU-DU split for NTN.

When we entered the final discussion in December 2023, the draft Rel-19 work item description for NTN still showed “CU-DU split For Further Study”. In light of this, we considered one further proposal to win over the remaining CU-DU split supporters: describing such payload architecture in an information annex of a normative 3GPP specification. This approach would have enabled the specification of a single architecture option (the typical case in all 3GPP standards) but it would have also enabled the CU-DU split supporters to have their architecture of choice documented in a standard. In the end, our Plan B idea was not needed because all of the companies lined up behind the decision to specify the gNB payload with no objections. This meant that the technical work could begin in all the working groups.

A positive outcome for all involved

Over the course of this long and often intensive process, we have significantly improved our connections with the NTN community and strengthened Ericsson’s reputation as a good speaking partner. Also, in large part as a result of the role we have played in integrating a new vertical industry (NTN) into 3GPP, Ericsson experts have been invited to co-author scientific articles and books on 5G NTN (including on RAN architecture). The outcome of all this work has been very good both for 3GPP and for Ericsson as a company. None of this would have been possible without the hard work of all the people in our internal NTN team and the strong support from the Ericsson 3GPP standardization projects.

Read more: 

Explore more on NTN in the article Using 3GPP technology for satellite communication

Learn more about 3GPP release 19

Non-Terrestrial Networks overview by 3GPP

Explore 5G