7 SA1, and writing down what the system must do

7.1 The group that is allowed to want things

SA1 writes stage 1: what the system must be able to do, said as a service, with no mention of which box does it.

That sounds like the easy job and it is not. Stage 1 decides the shape of everything downstream, because a requirement nobody wrote down is a feature nobody has to build, and a requirement written too tightly forecloses designs that have not been thought of yet.

For sensing, SA1 went first and did the heaviest single stretch of work in this area. 640 documents across 11 meetings, from SA1#98-e to SA1#109 SA1, including the busiest meeting anywhere in this record: SA1#101, with 154 sensing documents on the table ^[2].

7.2 The study, and the hole in the record

The study came first, under the acronym FS_Sensing, and it carries 521 documents ^[3]. It produced TR 22.837, which What people want it for, and why that question came first takes apart.

There is one thing this course cannot tell you about it. FS_Sensing has a work plan entry and an approval document, but no work item description on this machine FS_Sensing.

So for the oldest piece of work in the whole area there is no recorded objective, no recorded leadership line and no recorded list of target documents. Everything here about that study comes from the documents it produced and the report it ended in.

7.3 The rule-writing that followed

SP-230750 opened the work item at SA#100 SP-230750, and its objective is short.

KPIs are the numbers a service has to hit — the measurable part of a requirement, as opposed to the sentence that says the capability must exist. Stage 1's job is to fix both, and the register's copy of the objective stops at the first of the things it covers.

The reason the work exists is stated in the same document, and it is the most general statement of purpose in the area: wireless sensing acquires information about a remote object or environment, and the data received about an object and its surroundings can be analysed to obtain meaningful information about it ^[4].

The acronym for that work item is Sensing, and it carries 128 documents ^[5]. Three separate entries in the work plan share it Sensing Sensing Sensing, all pointing at SP-230750, which is one of the two reasons this area is 18 work plan entries under 14 acronyms.

7.4 What a stage 1 requirement actually looks like

Two things are being written at once in a document like TS 22.137, and they read very differently.

A functional requirement says the system must be able to do something: it names a capability, and whoever builds the system has to provide it. A KPI puts a number on it, so that "the system can detect an object" becomes something a test can pass or fail.

The objective names configuration and authorisation as things the work also covers. Those two are the unglamorous half of any stage 1 document and the half operators care about: who is allowed to switch this on, and who is allowed to ask for a result.

That last point is why stage 1 and stage 2 are different documents by different groups. A requirement written with a design already in mind forecloses every other design, and the group that writes requirements is deliberately not the group that draws the architecture.

7.5 What came out: TS 22.137

The specification is TS 22.137, "Integrated Sensing and Communication". It stands at 19.1.0, a Release 19 document, and 119 documents in this record name it TS 22.137. SP-231398 put it to the plenary at SA#102, where it was approved SP-231398.

Its own statement of scope is one sentence: it describes functional and performance requirements for the 5G wireless sensing service ^[6].

What makes it worth reading first is not the requirements but the vocabulary. Three definitions in it are used by every other group in this area, and getting them the wrong way round makes the later documents unreadable.

The word	What it means
5G Wireless sensing	the feature itself: getting information about the environment and objects in it, using NR radio signals [7]
3GPP sensing data	the raw material: data derived from radio signals an object reflected, refracted or diffracted [8]
Sensing result	the product: that data, processed for whoever asked for it [9]

7.6 The change to the general requirements

A new specification is not much use if nothing points at it. So the same work item touched TS 22.261, the overall 5G service requirements, adding a section that points at the new document. Four sensing change requests landed there TS 22.261.

That is a small change with a large effect on findability: anybody reading the general 5G requirements now has a signpost to the sensing ones, rather than having to know that TS 22.137 exists.

7.7 Three entries, one work item

The Sensing acronym is one of the two places where counting this area goes wrong. Three separate work plan entries carry it, one per release or per group, all pointing at the same description document, SP-230750 Sensing Sensing Sensing.

So "the SA1 sensing work item" is one promise recorded three times, not three pieces of work. The document count attached to it — 128 ^[5] — is the same 128 whichever entry you look at.

7.8 The one thread to 6G

One more specification carries SA1 sensing documents: TR 22.870, the 6G use-case study, with three of them TR 22.870.

That is the only place in this entire record where sensing and 6G are linked. Three documents is very little, and this course draws no conclusion from it beyond the fact itself — nothing here says what those three documents propose or whether anything came of them.

7.9 Where SA1 stopped

The last of the study's 521 documents is from SA1#106 ^[3], and the last of the work item's 128 from SA1#109 ^[5]. Nothing since.

Both of its documents exist as approved versions — TS 22.137 at 19.1.0 and TR 22.837 at 19.4.0 — and the plenary signed both off: SP-230506 for the report SP-230506 and SP-231398 for the specification SP-231398.

Stage 1 for sensing is done. Every other part of this area is still moving.

7.10 Where to read the real thing

• TS 22.137 — start here for the whole subject. It is short, and it defines the words TS 22.137.

• TR 22.837 — the use cases behind it TR 22.837.

• TS 22.261 — for where the sensing requirements are pointed at from the general ones TS 22.261.

• SP-230750 — the work item description, for what SA1 promised SP-230750.

Next: the group with more documents in this area than any other, and the one now writing the architecture — SA2, and how the system is put together.