11 Security, the bills, the management, the layer above and the voice

11.1 Why the last four trades decide whether any of this ships

A radio that works and an architecture drawing that fits are not yet something an operator can sell. Four more questions have to be answered first.

Can it be secured. Can it be billed. Can it be watched and configured like the rest of the network. And can somebody write an application against it without learning core network protocols first.

Those four questions belong to SA3, SA5 and SA6. In Release 20 a fifth group joins them: SA4, the speech coding group.

It is there because somebody wants to make a telephone call through a satellite in a circular orbit 35,786 km above the equator, which appears motionless from the ground ^[6].

The local record holds 551 documents from SA3 SA3, 751 from SA5 SA5, 402 from SA6 SA6 and 272 from SA4 SA4.

All four work the same way. A study report per phase, written as proposed text rather than as rules, and then — sometimes — a work item that edits documents another group owns.

That last part is what makes these five lines easy to miss. None of them creates a big new specification of its own.

Their output is change requests scattered across documents other groups own: the security architecture, the charging records, the network resource model, the service enabler layer.

So a reader looking for "the satellite security specification" will not find one, because there is not one.

The other thing to know is that each of these lines starts later than the architecture it depends on, and says so in its own description.

The phase 3 charging study records that two of its work tasks depend on SA2's phase 3 architecture study finishing FS_5GSAT_Ph3_CH. The phase 4 charging study records a dependency on SA2's progress in one line FS_5GSAT_Ph4_CH.

11.2 Security: a study for every phase, and one work item so far

SA3 is the security group. Its satellite work is four named pieces, and its shape is study, study, work item, study.

Release 18 opened FS_5GSAT_Sec, which the work plan calls a study on security aspects of satellite access, aimed at TR 33.700-28 FS_5GSAT_Sec TR 33.700-28.

Release 19 opened FS_5GSAT_Ph3_SEC, and that is where the weight of the security work sits: 317 documents ^[7], aimed at TR 33.700-29 FS_5GSAT_Ph3_SEC TR 33.700-29.

The work item that followed, 5GSAT_Ph3_SEC, names exactly one document in its own table of what it changes: TS 33.401, the security architecture of the evolved packet system 5GSAT_Ph3_SEC TS 33.401.

That is worth pausing on. The phase 3 security result did not land in the 5G security specification at all; it landed in the older core's security document, which is also where the internet-of-things satellite work lives.

Release 20 opened FS_5GSAT_Ph4_SEC, aimed at TR 33.700-30 FS_5GSAT_Ph4_SEC TR 33.700-30. Its scope is the most specific sentence any of these five trades has written down:

Three ideas are packed into that one sentence. A device that has already proved who it is. More than one satellite in the conversation. And a base station and core that are split between orbit and ground.

The work item that would turn any of that into rules, 5GSAT_Ph4-SEC, carries no document at all in this record 5GSAT_Ph4-SEC. Its own table names one document it would change, and it is TS 33.401 again 5GSAT_Ph4-SEC.

Read the four together and the security line has a plain shape. Three studies and one work item that landed, all of it aimed at questions the architecture raised first: a satellite that comes and goes, a base station split between orbit and ground, and a message that has to be held until there is a path.

Two numbers describe its size and they answer different questions. 551 documents were filed at SA3's own meetings under a satellite short name SA3.

317 documents carry the Release 19 security study's short name wherever they were filed ^[7]. Neither is a share of the other and they may not be subtracted.

11.3 The bills: SA5's charging line

Charging is the machinery that turns a connection into a record somebody can invoice. SA5 owns it, and it has run one study per phase since Release 18.

TR 28.844 was the first, from FS_5GSAT_CH FS_5GSAT_CH TR 28.844. TR 28.846 was the phase 3 study, from FS_5GSAT_Ph3_CH FS_5GSAT_Ph3_CH TR 28.846; its scope says the study stands on TS 22.261 and TR 23.700-29 and then runs straight into a list of aspects that the register does not carry ^[8].

The work item after it, 5GSAT_Ph3-CH, is where charging became rules. Its own table names seven charging specifications and says what each one is to get 5GSAT_Ph3-CH:

• TS 32.240 — support for store-and-forward satellite operation.

• TS 32.251 — new trigger events and charging information for the same.

• TS 32.255 — roaming charging for transparent satellite access, and charging information for an operator selling somebody else's satellite capacity. That document carries 40 satellite documents TS 32.255.

• TS 32.257, TS 32.291 and TS 32.298 — wholesale charging, the charging service interface, and the shape of the record itself.

• TS 32.260 — charging for a call that goes phone to satellite to phone without touching the ground.

Release 20's charging study is FS_5GSAT_Ph4_CH, aimed at TR 28.894, and it stands at a completion value of 0.4 in the work plan FS_5GSAT_Ph4_CH. Its scope names the two things it is chasing:

A voice call over a geostationary satellite, and traffic between two phones that never reaches the ground. Both are architecture work somebody else is still doing, which is why the charging study depends on it.

11.3.1 Why charging is more than an accounting detail

It is tempting to skip a charging chapter. It is a mistake here, because the charging documents are where the commercial shape of satellite access is written down, and that shape is unusual.

Look at what 5GSAT_Ph3-CH's own table asks for 5GSAT_Ph3-CH. Roaming charging for transparent satellite access, where the satellite only shifts and amplifies the signal and the network doing the work is somebody else's.

Charging information for an operator selling capacity it does not own. Wholesale charging between a satellite operator and a mobile operator.

None of those is a technical problem. They are the arrangements that have to exist before a satellite operator and a mobile operator can sell each other anything, written as fields in a record.

And the store-and-forward entries in the same table say something else again: a message accepted now and delivered later still has to be billed, which means the record has to survive the gap.

11.4 The management side, from the same group

Management is the other half of SA5: what an operator sees, sets and measures. It has run for longer than the charging line and it is the oldest of the five trades in this chapter.

Release 17 had FS_5GSAT_MO, a study on management and orchestration with integrated satellite components, aimed at TR 28.808 FS_5GSAT_MO TR 28.808. Release 18 added the same exercise for the internet-of-things side, FS_IoT_NTN, aimed at TR 28.841 FS_IoT_NTN TR 28.841.

The Release 18 work item OAM_NTN is where it became rules. Its table names four documents OAM_NTN: TS 28.541 for the model of what exists in the network, TS 28.552 for the measurements it reports, TS 28.554 for the performance figures, and TS 28.658 for the internet-of-things model.

Release 19 repeated the pattern at a larger size. The study FS_NTN_OAM_Ph2 produced TR 28.874 FS_NTN_OAM_Ph2 TR 28.874, whose scope is two plain sentences:

The work item after it, NTN_OAM_Ph2, names eleven documents to change NTN_OAM_Ph2 — the same four as before plus the older core's models, the requirement documents and the solution sets.

Release 20 opened NTN_OAM_Ph3-OAM, which carries three documents so far NTN_OAM_Ph3-OAM.

The document that takes the most of this work is TS 28.541, the 5G network resource model, with 88 satellite documents against it TS 28.541. Three of these management work items name it, and so does the satellite backhaul management item.

11.5 The layer above: SA6 and the service enablers

SA6 writes the layer an application talks to, so that using a network feature does not mean speaking the network's own protocols. It arrived at satellites in Release 19, after the architecture was drawn.

Its study FS_5GSAT_Ph3_App produced TR 23.700-01 FS_5GSAT_Ph3_App TR 23.700-01, and the report says plainly what kind of work it is:

"Either by defining a new functional model or by enhancing an existing one" is the whole question a layer like this always faces, written into its own scope.

The work item after it, 5GSAT_Ph3_App, answered it by enhancing what was already there. Its table names five service-enabler documents 5GSAT_Ph3_App.

They are TS 23.558 for edge applications TS 23.558, TS 23.434 for the service enabler layer for industries TS 23.434, and TS 23.436, TS 23.433 and TS 23.289 beside them.

TS 23.558 carries 41 satellite documents and TS 23.434 carries 54, and in both cases every one of them is a change request TS 23.558 TS 23.434. That is the signature of an existing document being amended rather than a new one being drafted.

Release 20 opened the phase 4 study, FS_5GSAT_Ph4_APP, aimed at TR 23.700-02 FS_5GSAT_Ph4_APP TR 23.700-02. The work item that would follow it, 5GSAT_Ph4-APP, carries no document at all 5GSAT_Ph4-APP.

11.6 The voice: SA4, and only in Release 20

SA4 is the speech coding group, and it has no history in this subject at all. It appears once, in Release 20, with two named pieces of work.

The study is FS_ULBC, a study on an ultra low bit rate speech codec, and it is not small: 325 documents ^[9], aimed at TR 26.940 FS_ULBC TR 26.940.

Its stated objective is to develop recommendations for possible rule-writing on an ultra-low bit rate codec whose primary application is voice over a geostationary satellite. The sentence then runs into a list of specific objectives the register does not carry ^[10].

What survives is the aim: a codec squeezed hard enough that speech fits through a link to a satellite in that geostationary orbit.

Its justification is the clearest statement anywhere in this chapter of how one group's work becomes another group's problem:

The requirements group wrote a use case. The requirements were going into TS 22.261. Somebody then had to build a codec that could meet them, and that is SA4 arriving in Release 20 with no history in the subject and 325 documents behind its study.

The work item after the study is ULBC-MED, and it carries no document yet ULBC-MED. Its own table names seven documents it would create or change.

They are a general description of the codec, its reference software, its conformance tests, the format it is carried in and how it is offered in a call, the machinery for staying quiet between words, its characterisation results, and one edit to the document that governs media in a call.

Seven documents for one codec is a fair measure of what a speech codec costs in 3GPP, and of how far Release 20's voice-over-satellite idea still has to travel: the study has 325 documents behind it and the work item that would write those seven has none ULBC-MED.

Its description also lists the dependencies, and they run in every direction at once: the radio groups for scheduling and transmit power, SA2 for the phase 4 architecture procedures, CT1 for how the codec is negotiated ULBC-MED.

A single voice call turns out to need almost every group in this course.

11.7 How the five lines sit against each other

Read by phase rather than by group, the pattern is regular and the gaps are where the interesting questions are.

Phase	Security	Charging	Management	Applications	Speech
Rel-17	—	—	TR 28.808	—	—
Rel-18	TR 33.700-28	TR 28.844	TR 28.841, then rules	—	—
Rel-19	TR 33.700-29, then rules	TR 28.846, then rules	TR 28.874, then rules	TR 23.700-01, then rules	—
Rel-20	TR 33.700-30	TR 28.894	rules opened	TR 23.700-02	TR 26.940

Management is the oldest line and the only one with a Release 17 entry. Security is the only one whose Release 20 work item has nothing against it yet. Speech has no history at all and arrives with 325 documents in one release.

The gaps in the top-left corner of that table are the interesting part. In Release 17 there was a satellite radio and a satellite architecture and no security study, no charging study and no application layer.

Those three arrive in Release 18 and Release 19, once there is something concrete to secure, bill and build on.

The gaps in the bottom-right corner are the opposite kind. Release 20's studies are running or done; the work items that would turn them into rules are the ones standing at nothing. That is what the front edge of a subject looks like in a work plan: homework finished, rule-writing not started.

None of that says whether a piece of work is going well or badly, and this record cannot say it either. What the shape does show is order: the trades wait for the architecture, and the architecture is where the phases are decided.

11.8 Where this meets the rest of the course

Everything in this chapter edits documents somebody else owns, so the specifications themselves are the place these five lines meet — that shelf is The specifications this work created, and the ones it changes.

How far each of these pieces has got, in the only measure the work plan carries, is What the shape of the paperwork says, and where the work stands. What none of it can tell you — why a group chose one approach, or when any of it is finished — is Reading the record yourself, and what it cannot tell you.

For the real text, four reports are worth the trip: TR 33.700-30 for the security question TR 33.700-30, TR 28.894 for the charging one TR 28.894, TR 23.700-02 for the application layer TR 23.700-02 and TR 26.940 for the codec TR 26.940.

This school carries the text of none of them.