2 Why anyone wanted it, and who said so

2.1 What this chapter can and cannot answer

Every piece of work in 3GPP is opened by one document a plenary approves, and that document has a section where the people asking say why. It is the closest thing in the whole record to a motive stated out loud.

The register quotes those sections — but not all of them. Of the 155 short names this subject covers ^[10], only the 41 carrying at least 200 documents have their objective and justification stored.

For the other 114 the register holds the work plan row, the counts and the title, and nothing about what the work promised.

Two of the 155 are thinner still: 5GSAT_Ph4 and ANSS have no work item description on this machine at all, so they carry no objective, no leadership line and no list of documents to change ANSS.

That is the honest frame. Inside it, the ten justifications below are word for word what the groups wrote about themselves.

2.2 Connection matters most where there is none

The oldest reason in the pile is also the simplest, and it belongs to the internet-of-things side rather than to phones. This is the whole opening of the Release 17 justification:

Read what is being claimed and what is not. It does not say satellite is better, cheaper or faster. It says there are places with no coverage, that things worth tracking are in those places, and that transport and logistics — ships, lorries, trains, aircraft — are the first industry to name.

That is an argument about geography. Everything the older radio then did about it is The same idea on the older radio, for things that are not phones.

2.3 What Release 17 assumed, and what Release 18 set out to loosen

The most useful justification in the whole register is the Release 18 one for NR, because it opens by writing down what the previous release had taken for granted:

Four assumptions, each of them a constraint somebody later wanted lifted.

• Transparent payload. The satellite is a mirror; the base station is on the ground. The definitions are in What a non-terrestrial network is, in 3GPP's own words.

• GSO and NGSO. Geosynchronous and non-geosynchronous orbits both, but the scenarios are network scenarios, not free choice.

• Power class 3, with a satellite navigation receiver. The device is ordinary in transmit power, and it knows where it is.

• Earth-fixed or moving cells. Whether the patch of ground a cell covers stays put while the satellite moves, or travels with it.

The Release 18 work is named for what it does to that list: enhancements NR_NTN_enh.

The same assumption about the navigation receiver is what a Release 20 study went after directly. Its justification is a plain statement of the dependency:

A device that knows where it is can correct its own timing and frequency before it transmits. A device that does not, cannot — and that sentence is the entire reason FS_NR_NTN_GNSS_resilient exists NR_NTN_GNSS_resilient.

2.4 A band the world had already set aside

Bands are the largest single family of work items in this subject, and their justifications are the shortest. The Ku band one is the clearest example of the form:

The ITU is the international body that divides the radio spectrum, and its three regions cover the world between them.

The argument is one step long: the band is already reserved for satellites everywhere, so 3GPP should write it down. Its core part carries 411 documents ^[11].

2.5 Power, which is why one radio got a second mode

The Release 19 time-division item for the internet-of-things radio is the one place where the register states a physical reason for a design in so many words:

Time division means sending and receiving take turns instead of running at once on two frequencies. Using only some of the subframes — the small time slots a radio frame is cut into — is what "thus limiting power consumption" refers to.

The second sentence gives the other half of the reason: a satellite system that has no paired spectrum to work with can be supported this way IoT_NTN_TDD.

2.6 Something that is already in service

Most justifications argue about what could be. One argues from what is:

This is the only place in the register where a document says of this subject that it is deployed. It is a claim made by the people proposing the next phase, in the document that opened it, and nothing else in the record confirms or contradicts it.

2.7 Four releases of studying, and a fifth opened anyway

By Release 20 the system side had a different kind of argument to make: the weight of everything already done. Its justification opens by counting the releases already spent —

"Integration of satellite components into 5GS has been studied in Rel 16, Rel 17, Rel 18 and Rel-19. Now SA1 is developing TR 22.887 to capture a set of new use cases and potential service requirements:"

— and the stored text stops there, on a colon, pointing at a list of use cases this register does not carry ^[12].

Two things are being said at once. Four releases of architecture study have gone before, and the requirements group is still writing new use cases — so the architecture people asked to open a fifth study to keep up with them FS_5GSAT_Ph4_ARC TR 22.887.

TR 22.887's own scope says what those use cases are about: enhancements of the 5G system over satellite, with multi-orbit satellite access for multiple services named first ^[13].

2.8 A voice call, over a satellite that does not move

The speech coding group appears in this subject only in Release 20, and its justification points straight back at the same study:

IMS is the part of the system that carries telephone calls.

A geostationary satellite sits far enough away that a call over it is a hard problem, and the answer being studied is a speech codec that needs very few bits — an ultra low bit rate codec, with 325 documents behind it already ^[14] FS_ULBC.

The architecture side is chasing the same call from the other end: TR 23.700-19 names support of an IMS voice call over the narrowband internet-of-things radio through a geostationary satellite into the older packet core as the first thing it studies ^[15].

2.9 Two more, from the system half

The protocol groups get handed work by the architecture groups, and their justifications read like handover notes. This one names its inheritance precisely:

Three named problems: putting the base station in orbit, holding a message until there is somewhere to send it, and phone-to-satellite-to-phone traffic. The last of those is defined in What a non-terrestrial network is, in 3GPP's own words.

And one work item is the whole subject turned around. Satellite backhaul does not reach the phone at all; it carries the link behind an ordinary mast:

The UPF is the function in a 5G core that forwards user traffic. "On-board enabled edge computing" therefore means putting that forwarding function in orbit, and local data switching means traffic turning round without going all the way down 5GSATB.

2.10 What to read next, and where the reasons run out

The justifications above are ten of the forty-one the register holds. They are not a summary of why satellites are in 3GPP: they are ten groups' own arguments for ten pieces of work, made to get those pieces started.

For the rest, the shortest route is the work item description itself — the document that opened the row. How the work is cut up, and who carries it explains how to find the right one, and why 155 short names sit on 183 work plan rows.

The shape of those documents is the same every time, which makes them quick to read once you know where to look. Section 3 is the justification — why anybody should be allowed to start. Section 4 is the objective — what they promise to produce.

Everything quoted in this chapter is one or the other, and the method line of each register entry says which section it came from and which file it was read out of.

Two documents carry more of the reasoning than any others in this chapter: TR 22.887 for what the system is being asked to do next TR 22.887, and TR 23.700-19 for what the architecture is doing about it TR 23.700-19.