5 The same idea on the older radio, for things that are not phones

5.1 The half that is not about phones

The line in NR over satellite, release by release put 5G's radio on a satellite. This one did the same thing to the radio before it, and it is a different kind of work with a different reason behind it.

The two radios here are NB-IoT and eMTC — narrow-band internet of things and enhanced machine type communication, as the study report's own title spells them out TR 36.763. They are built for sensors, meters and trackers: things that send very little, very rarely, on very little power.

The justification the Release 17 work item wrote for itself is the plainest argument in this whole subject.

Internet-of-things operation is critical in remote areas with low or no cellular connectivity, and the first industry it names is transport and logistics — maritime, road, rail and air ^[4].

5.2 Release 17: study, then rules, in one release

Unusually, both halves happened inside a single release.

The study is FS_LTE_NBIOT_eMTC_NTN, whose leadership line reads "Lead: RAN1 Secondary: RAN2" FS_LTE_NBIOT_eMTC_NTN. Its study document RP-202689 was approved at RAN#90-e, filed by the study's own rapporteur RP-202689. The report is TR 36.763, which exists in one version, for Release 17 TR 36.763, and the study carries 545 documents ^[5].

Its objective is a piece of scoping rather than a promise: the study evaluates and confirms solutions for the minimum necessary specifications, and its first job is to identify which scenarios apply at all ^[6].

The work item that followed is LTE_NBIOT_eMTC_NTN, again led by RAN1, this time with RAN2 and RAN3 second LTE_NBIOT_eMTC_NTN. Its objective is the shortest in the register:

One sentence, and a note about when. Compare that with the Release 17 NR objective in NR over satellite, release by release, which needed a paragraph of orbits, compatibility and duplexing assumptions.

Nothing new was being invented here: two existing radios were being made to work over a link they were not designed for.

Its work item description RP-211601 came from MediaTek, Eutelsat and others, and was approved at RAN#92-e RP-211601. The feature row carries 689 documents ^[7] and its core part 673 ^[8].

What it changed is a list of twelve LTE documents, and every one of them is a document that already existed LTE_NBIOT_eMTC_NTN.

Among them are the overall description TS 36.300, idle-mode procedures TS 36.304, device capabilities TS 36.306, medium access control TS 36.321, radio resource control TS 36.331 and the two network interfaces TS 36.413 TS 36.423.

5.3 The core network had to be fixed first

A radio that reaches a satellite is useless if the network behind it does not understand what it is looking at. That is why one piece of this work sits outside RAN entirely.

IoT_SAT_ARCH_EPS is architecture support for NB-IoT and eMTC non-terrestrial networks in the evolved packet system — the older core network, the one built for LTE. Its leadership line names SA2, and the groups on its rows are CT1, CT3, CT4, CT6 and SA2 IoT_SAT_ARCH_EPS.

Its objective says what kind of work that was —

"This Work Item covers the following objectives to introduce minimum essential functionality to support NB-IoT and eMTC over Non-Terrestrial Networks in EPS using 5GSAT_ARCH solutions as baseline: Functionality to support NTN for NB-IoT and eMTC for transparent payload based scenarios, including:"

— and the stored text ends there, on a colon, with the list that followed it not held in this register ^[9].

Three things worth reading twice. Minimum essential functionality — the smallest change that works, not a redesign. Using 5GSAT_ARCH solutions as baseline — the answers already found for the 5G core were copied across to the older one.

And transparent payload based scenarios, which is the mirror in orbit rather than the base station in orbit ^[10].

This item sits on five work plan rows rather than one, and carries 518 documents ^[11]. Its work item description SP-211306 came from SA WG2 and was approved at SA#94-e SP-211306.

The document at the centre of it is TS 23.401, the older packet core's own specification, which carries 570 documents of this subject and 568 change requests among them TS 23.401.

Its list of changes also reaches the protocol the device speaks TS 24.301, the network-selection rules TS 23.122 and the interface to applications TS 23.682.

5.4 Release 18: enhancements

IoT_NTN_enh moves the lead: its line reads "Leading working group: RAN2 Secondary working groups: RAN1, RAN4" IoT_NTN_enh. Its objective widens the orbits in exactly the way the NR line did in the same release:

Its justification is the twin of the NR one, and lists the same Release 17 assumptions: transparent payload based geostationary and non-geosynchronous scenarios, power class 3 devices with a satellite navigation receiver, in earth-fixed or moving cells ^[12].

Its description RP-241351 came from the rapporteur at MediaTek and was approved at RAN#104 RP-241351. The core part carries 1386 documents ^[13] and the feature row 272 ^[14].

This is also where the work reaches the radio-requirement shelf of its own: its change list names TS 36.133 for radio resource management and TS 36.102, the device's radio requirements for satellite access IoT_NTN_enh TS 36.133 TS 36.102.

TS 36.102's scope says exactly that — the minimum radio characteristics and performance requirements for an E-UTRA device operating satellite access ^[15].

5.4.1 And a separate item for the numbers

Release 18 also carries a work item whose whole job is to put figures on what Release 17 had described. LTE_NBIOT_eMTC_NTN_req is titled "NB-IoT/eMTC Core and Perf requirements for NTN", and its leadership line is one word, RAN4 LTE_NBIOT_eMTC_NTN_req.

Its objective says so plainly: it specifies the radio and radio-resource management requirements for operation over the functionality defined in the Release 17 work item ^[16].

Its core part carries 341 documents ^[17] and its performance part 344 ^[18] — two rows of nearly the same size, which is unusual and is what a purely numerical work item looks like.

That is the division of labour on this line. RAN1 and RAN2 decide what the radio does; RAN4 decides how well it has to do it; RAN5 decides how that is proved, in a conformance row carrying 330 documents of its own ^[19].

5.5 Release 19: the satellite starts holding messages

IoT_NTN_Ph3 keeps RAN2 leading, with RAN1, RAN3 and RAN4 secondary IoT_NTN_Ph3, and its objective is the most interesting sentence on this whole line —

"The aim of this WI is enhancement of IoT-NTN with the following objectives: Support of Store&Forward (S&F) satellite operation with full eNB as regenerative payload, therefore:"

— stopping, again, on a colon that points at a list this register does not hold ^[20].

Two ideas are packed into that.

Store and forward means the satellite takes the message and carries it until there is somewhere to put it, instead of relaying it live. TR 22.865's scope gives the reason in its own words: store and forward satellite operation for a delay-tolerant communication service ^[21] — a service that can wait. For a sensor reporting once a day, waiting is free.

A full eNB as regenerative payload is the other idea. This register holds no expansion of those three letters, so nothing here says what they stand for.

What it does define is the payload. A regenerative one demodulates, decodes, re-encodes and re-modulates rather than only shifting and amplifying ^[22] — the opposite of the transparent payload the Release 17 work assumed ^[12].

That is a large change for a line whose Release 17 objective was one sentence.

Its justification says why it was worth making: the work was specified in Release 17, optimised in Release 18, and commercial deployment is going on, so further evolution is needed based on real deployments or deployment plans ^[23].

Its description RP-252504 came from MediaTek and was approved at RAN#109 RP-252504. The core part carries 1427 documents over 72 meetings ^[24], and the feature row 120 ^[25].

Its change list reaches TS 36.108, the satellite access node's own radio specification for this radio IoT_NTN_Ph3 TS 36.108.

5.5.1 And a mode of its own

IoT_NTN_TDD is the one item on this line that RAN1 leads, with RAN2 and RAN4 secondary IoT_NTN_TDD. It is narrow and it is unusually well explained:

Everything in that sentence is a limit. TDD — time division duplex — means sending and receiving take turns rather than running on two frequencies at once. The mode is built from minimum necessary changes to the frequency division one.

It is for one unpaired band, a band with no matching second half. Ground deployment is not expected in it. And the feature is explicitly not meant for any band 3GPP already has.

The reason given is power: using the radio resources in only a periodic subset of the subframes limits how much the equipment draws, and the same feature extends operation to an additional non-geosynchronous satellite system ^[26].

The description RP-252935 came from Iridium Satellite LLC and was approved at RAN#109 RP-252935. Its core part carries 354 documents ^[27].

5.6 Release 20: chasing a voice call

IoT_NTN_Ph4 is led by RAN2 with RAN1 and RAN4 secondary IoT_NTN_Ph4, and its change list says its aim more plainly than any objective would.

Six LTE documents appear with the same note written against each of them — to support an IMS voice call over a geostationary satellite via NB-IoT NTN IoT_NTN_Ph4.

They are the physical layer procedures TS 36.213, the overall description TS 36.300, idle-mode procedures TS 36.304, device capabilities TS 36.306, medium access control TS 36.321 and radio resource control TS 36.331.

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

Carrying one over a radio built for sensors and trackers, through a satellite 35,786 km up ^[28], is a long way from the remote-area tracking its first justification described ^[4].

The seventh document on its list is TS 36.102, and the note there is different: to support a device transmit power higher than power class 1 IoT_NTN_Ph4 TS 36.102.

Its description RP-253813 came from vivo and was approved at RAN#110 RP-253813. The feature row carries 103 documents ^[29] and its core part 164 ^[30].

The same call is being chased from the other side of 3GPP at the same time.

The phase 4 architecture study's scope names support of an IMS voice call over NB-IoT NTN via a geostationary satellite connecting to the older core as the thing it studies ^[31], and the speech coding group opened work on a very low bit rate codec for it ^[32].

5.7 The two radio lines, side by side

The two lines were run in the same releases by overlapping groups, and their shapes rhyme. Both opened with a study, both wrote their rules in Release 17, both widened the orbits in Release 18, both called Release 19 phase 3, and both are chasing narrower things in Release 20.

What differs is size. These counts were all made the same way — documents whose work item column names one short name as a whole word — so they answer the same question and can honestly be set beside each other.

Release	The NR line	The internet-of-things line
the first study	124 [33]	545 [5]
the first rules, core part	4346 [34]	673 [8]
enhancements, core part	3249 [35]	1386 [13]
phase 3, core part	2807 [36]	1427 [24]

The first study is the one row where this line is the larger of the two, with 545 documents against 124.

After that the NR line is always the bigger — but its core parts read 4346, then 3249, then 2807, while this line's read 673, then 1386, then 1427. One line is settling down and the other is still growing.

5.8 The shelf this line built

Four documents were created for this radio, and they mirror the NR four exactly.

Document	What it is
TS 36.108 TS 36.108	the satellite access node's radio requirements for this radio
TS 36.181 TS 36.181	the test methods that prove them
TS 36.102 TS 36.102	the device's radio requirements
TS 36.521-4 TS 36.521-4	the device's conformance tests

TS 36.108's scope says it establishes the minimum radio characteristics and performance requirements of a satellite access node supporting standalone NB-IoT operation ^[37], and TS 36.181's names two kinds of node it tests, type 1-H and type 1-O ^[38].

Beside them sits TR 36.764, whose whole scope is one line: a technical report for LTE IoT NTN operating bands ^[39] TR 36.764. It is where the band items of this line put their results.

5.9 Where to read on

The vocabulary this chapter leans on — payload kinds, orbits, the access node — is What a non-terrestrial network is, in 3GPP's own words. The reasons in the justifications are collected in Why anyone wanted it, and who said so, and how the counts were made is How the work is cut up, and who carries it.

For the original documents, the order is the order the work happened: TR 36.763 for the study TR 36.763, then TS 36.108 for what a satellite base station of this radio has to be TS 36.108, and TS 23.401 for what the core network had to learn TS 23.401.