13 What the shape of the paperwork says, and where the work stands

13.1 Why the pile itself is worth reading

Every chapter before this one reads what people wrote. This one reads the shape of what they wrote — how many documents, of what kind, marked with what, in which years.

That is a cruder instrument and it answers a different question. Not "what does the standard say" but "how much of this is settled, how much is still being argued, and where is the argument".

The local record holds 35306 meeting documents under the 155 short names of this subject ^[1]. Here is what they are.

One warning before any of it. Every number in this chapter was produced by looking for documents that carry one of those 155 short names.

A document about satellites that carries no short name is in none of them, and 6568 documents are in exactly that position ^[2]. Read every figure below as a floor.

13.2 What kind of paper this is

3GPP files a document under a type, and the types are not interchangeable. Half the skill of reading a meeting agenda is knowing which type you are looking at before you open it.

• 12603 are discussion papers ^[3] — somebody's argument, with no text in it that goes anywhere.

• 10374 are change requests ^[4] — the only way a published specification is ever altered.

• 4374 are pCRs ^[5], proposed text for a study report. A study report is written by pasting these in, one accepted piece at a time.

• 2192 are draft change requests ^[6] — a change request being circulated before it is formally offered.

• 1712 are filed as "other" ^[7], and 478 are change request packs ^[8], which are several change requests submitted together.

• 1407 are outgoing liaison statements ^[9] and 898 incoming ones ^[10] — one group formally writing to another.

13.2.1 Why the change request count is the interesting one

A change request is the only way a published specification is ever altered. It names the document, the version, the clause and the exact new words, and it either goes in or it does not.

So 10374 of them ^[4] is a statement about how much existing text this subject has had to move. It is also where a figure like TS 38.133's 1306 change requests in The specifications this work created, and the ones it changes comes from TS 38.133 — that number is a slice of this one.

The pCR count works the other way round. Proposed text goes into a study report that nobody has to obey, so 4374 of those ^[5] is a measure of how much homework was written, not of how much of the standard changed.

13.2.2 The liaison statements are the seam between groups

An outgoing liaison statement is one working group formally writing to another: here is what we decided, here is what we need from you, here is our deadline. There are 1407 of them here and 898 coming the other way ^{[9] [10]}.

For a subject that runs across the radio groups, the system groups and the protocol groups at once, that traffic is the connective tissue. It is also the only place in this record where one group's dependence on another is written down as an event rather than as a sentence in a work item description.

13.3 The outcome words are a document's fate, and never the work's

Every document leaves a meeting with a word attached. Those words are the most misread thing in this whole record, so it is worth taking them one at a time.

7768 are noted ^[11]. The room saw it and did nothing — which is the ordinary end of a discussion paper and says nothing bad about it.

7054 are revised ^[12]. Replaced by a later version, usually the same day and often several times, as a text is negotiated in the room. A busy subject produces revisions the way a busy kitchen produces plates.

5615 were not treated ^[13]. The meeting never reached it. The record does not say why a document was not treated, so nothing more than that can be read off the word.

4298 are agreed ^[14], 3461 available ^[15] and 2365 approved ^[16]. Agreed and approved are the two that end with text going somewhere; available means the file was there to be read.

That matters more here than it sounds, because a reader wanting to know whether something is done reaches instinctively for these words. They are the wrong instrument. The right one is further down this chapter, and it is a number between 0 and 1.

13.4 Which release the documents say they are for

A document also carries the release it is aimed at, and that column tells a plainer story than the outcome words do.

Release	Documents
Rel-15	141 [17]
Rel-16	1226 [18]
Rel-17	8846 [19]
Rel-18	10362 [20]
Rel-19	10927 [21]
Rel-20	2576 [22]
none	1226 [23]

Release 15 is the first study and nothing else. Release 17 is where rules were written for the first time and the count jumps to match. Release 20 is the release being worked on now, so its number is a snapshot rather than a total.

1226 documents carry no release mark at all, which is the same as saying that however this pile is sliced, some of it falls outside every slice.

The three big middle rows are worth looking at together. Release 17 is when the satellite access node and the device requirements were first written; Release 18 and Release 19 are the two phases that enhanced them.

A subject that keeps its volume across three consecutive releases is one that did not turn out to be finished when the first rules landed.

What the column does not say is when any of those releases froze. No store here holds a release date at all, so a release mark is a label on a document and never a point in time.

13.5 Who put the paper on the table

The pile also records who filed each document, and that column is a different kind of reading again: not what was decided, but who turned up with something to say.

2664 different names appear as the writer of one of these documents ^[24]. The eight that appear most:

Filed by	Documents
Huawei, HiSilicon	2287 [25]
Ericsson	2184 [26]
CATT	2076 [27]
Qualcomm Incorporated	1337 [28]
Samsung	1285 [29]
Nokia, Nokia Shanghai Bell	1043 [30]
OPPO	848 [31]
MediaTek Inc.	846 [32]

Those are the names exactly as each document spelled them, which has a consequence worth stating plainly: a company that files sometimes alone and sometimes jointly appears under both spellings and is counted under both. The method line of every one of those entries says so.

So the table is a reading of how the paper was signed, not a league table of companies. It cannot be added up, and nothing here should be read as one firm's total involvement in the subject.

13.6 The years, and why the earliest stamp is a false floor

Each document has the day its file went up on the server. Counted by year:

Year	Documents
2017	74 [33]
2018	328 [34]
2019	918 [35]
2020	650 [36]
2021	3198 [37]
2022	4784 [38]
2023	5619 [39]
2024	7679 [40]
2025	8109 [41]
2026	2890 [42]

The earliest of those upload stamps is 2017-05-27 and the newest is 2026-07-31 ^{[43] [44]}.

Neither is a date about the work. Three meetings in this register sat before that earliest stamp, and the earliest of them started 2010-12-07 RP-50. Old papers were put on the server again in one go, long after they were written.

So the upload column is a floor for the store, not a start for the subject, and the meeting code is what dates the older work. A further 1057 documents carry no upload day at all ^[45].

13.7 Where the work actually stands

The work plan holds no status word. What it holds is a planned start day, a planned finish day, and a completion value between 0 and 1 ^[46].

116 of the 155 short names in this subject carry a completion value of 1 ^[46], which is what the plan writes when the plan for that row is complete. It is not a statement that the group has finished.

That distinction is the whole reason this section exists. A completion value is somebody's judgement about a plan, typed into a spreadsheet and revised when it suits. It is the best measure this record carries and it is still only that.

Two habits make it readable. Read a value together with the planned finish day beside it, because a row at 1 whose planned finish is long past says something different from one still ahead. And read a feature and its parts together, because the parts move separately and often far apart.

13.7.1 Release 17's radio reads as done

NR_NTN_solutions-Core stands at 1 with a planned finish of 2022-06-06, and its performance part stands at 1 with a planned finish of 2023-03-03 NR_NTN_solutions-Core NR_NTN_solutions-Perf.

The feature row above them stands at 1 as well, planned to 2024-12-12 NR_NTN_solutions, and the conformance part below them was planned to 2025-12-12 NR_NTN_solutions_plus_CT-UEConTest.

Those four planned days — 2022-06-06, 2023-03-03, 2024-12-12, 2025-12-12 — are the clearest picture in this record of the order one release's radio work runs in: the rules, then the performance requirements, then the closing of the feature row, then the device tests, each planned after the one before it.

That block is also the biggest in the register: its core part is the largest single short name there is, with 4346 documents ^[47].

13.7.2 Release 19's rules are written and its tests are not

NR_NTN_Ph3-Core stands at 1 NR_NTN_Ph3-Core. The conformance part, NR_NTN_Ph3-UEConTest, stands at 0.14 with a planned finish in 2027 NR_NTN_Ph3-UEConTest.

That gap is the shape to look for in any of these rows. The rules are written and closed; the tests that prove a device implements them are planned to finish later, and until they do a specification exists that nothing can be certified against.

The same split shows one release earlier. Release 17's core and performance parts were planned to finish in 2022 and 2023, and its conformance part was planned to 2025-12-12 NR_NTN_solutions_plus_CT-UEConTest.

Testing lagging the rules is not a Release 19 accident; it is how the work plan is laid out.

For a reader deciding whether to build something, that gap is the number that matters. A specification exists as soon as its core part closes. A device can be certified against it only when the conformance part does.

13.7.3 Release 20 is early everywhere, at very different speeds

Work	Completion value
NR_NTN_GNSS_resilient NR_NTN_GNSS_resilient	0
NR_IoT_NTN_req_Ph2 NR_IoT_NTN_req_Ph2	0.20
NTN_bands_Features_R20 NTN_bands_Features_R20	0.34
IoT_NTN_Ph4 IoT_NTN_Ph4	0.59
5GSAT_Ph4-ARC 5GSAT_Ph4-ARC	0.8
5GSAT_Ph4-SEC 5GSAT_Ph4-SEC	0
5GSAT_Ph4-APP 5GSAT_Ph4-APP	0.25

Two of them stand at 0: the radio study of what to do when the position fix disappears, and the phase 4 security work item. The document that opened the first is RP-261568 RP-261568, approved at the RAN plenary that sat in Singapore from 2026-06-08 RP-112.

Reading down that table tells you where the front edge of the subject is. The system side is furthest along: the phase 4 architecture work stands at 0.8.

The radio side of Release 20 is spread from 0 to 0.59, and the two pieces at the extremes are doing different kinds of thing — one is a study of what to do when the position fix disappears, the other is the fourth phase of an internet-of-things radio that has been specified three times already.

The two phase 4 pieces with no documents at all, security and applications, are the ones covered in Security, the bills, the management, the layer above and the voice. The architecture piece at 0.8 is what both of them are waiting on, which is the ordinary order of things in this subject: the architecture settles, and then the trades can start.

13.7.4 One row says stopped, and it says it in its own name

NR_NTN_combinedLband-Perf is written into the work plan as "STOPPED - Perf. part: …" NR_NTN_combinedLband-Perf. That word is part of the row's title, typed by whoever maintains the plan. It is not a status field, and no other row in this subject carries anything like it.

It is worth knowing precisely because it is the exception. If the plan had a status field, this would not have had to go in the name.

13.8 The version numbers say the same thing from the other side

A specification's version number is a second, independent reading of how far along something is, and it agrees with the completion values.

• TR 23.700-19 exists at 20.0.0 TR 23.700-19 and TR 33.700-30 at 20.0.1 TR 33.700-30. The first part of each is 20, the number of the release they belong to.

• TR 28.894 stands at 0.3.0 TR 28.894 and TR 23.700-02 at 1.1.0 TR 23.700-02. Neither has reached a number whose first part is its release number, and both belong to Release 20 as well.

The specifications themselves keep moving. TS 38.101-5 exists in four releases up to 20.0.0, and its newest file went up on 2026-07-06 TS 38.101-5. TS 38.108 stands at 19.4.0 TS 38.108 and TS 23.501 at 20.2.0 TS 23.501.

13.9 What none of this measures

Everything above is a count of documents in one store or a number typed into one plan. None of it is a measure of quality, of difficulty, or of whether a feature works when somebody builds it.

Three specific traps are worth naming, because all three are easy to fall into while reading a table like the ones above.

• A large count is not importance. It is a count of paper. A short work item that changed one sentence of TS 22.261 can matter more to a product than a large pile of band requirements.

• A completion value is not a promise. It is a plan's own view of a plan. The row for NR_NTN_combinedLband-Perf carries a value of 1 and the word STOPPED in its title at the same time NR_NTN_combinedLband-Perf.

• Two counts here often answer different questions. The yearly counts and the whole-record counts do not cover the same documents, and a count filtered by short name excludes every document that carries none. None of them may be subtracted from another.

And none of it can be set against any other area of 3GPP work, because nothing here counted any other area. The full list of what this record cannot tell you is Reading the record yourself, and what it cannot tell you, and the shelf these numbers are about is The specifications this work created, and the ones it changes.