2 What people want it for, and why that question came first

2.1 Why 3GPP asks "what for" before "how"

3GPP splits its work into three stages, and the split decides which group touches a subject first.

• Stage 1 is what the system must be able to do, written as a service.

• Stage 2 is how the system is put together to do it — the functions and the message flows between them.

• Stage 3 is the bytes on the wire.

A new idea therefore starts in stage 1, with a group whose job is to write down what somebody would want, not how it could work. For sensing that group is SA1, and it opened the subject long before any radio engineer was asked whether it was possible.

The first thing SA1 produced was not a rule. It was a study report — a TR, homework a group does before deciding anything, which nobody has to obey. Only after that comes a specification, a TS, which is a rule other people have to follow.

2.2 The study that collected the wants

That study report is TR 22.837, and it is where the ambition of this whole area is written down.

Nine kinds of user in one sentence. Cars that drive themselves and cars that talk to each other, drones, building three-dimensional maps of places, city infrastructure, homes, factories, hospitals and shipping.

That is the widest statement of purpose anywhere in this area, and it is worth noticing what it does not say. It names no mechanism, no accuracy, no frequency and no network function. Stage 1 is allowed to want things.

2.3 What a use case is, as a piece of writing

The word "vertical" in that scope means an industry with its own needs — shipping is one vertical, healthcare another. A use-case study collects what each of them would want, in enough detail that a requirement can later be written from it.

A use case in a stage 1 study is a short, self-contained piece of writing. It says who wants something, in what situation, what the network would have to do, and roughly how well. It does not say which function does it, over which interface, in which message.

That is why a study like this is dominated by proposed text rather than by argument: 2036 of the area's documents are pCRs, pieces of proposed report text, against 968 discussion papers ^{[3] [4]}. Hundreds of companies each offering a paragraph is what a use-case study physically looks like.

2.4 How much work that took

518 documents in the local record name TR 22.837, and 46 of those are change requests — more change requests than any other document in this area has received TR 22.837. It exists at version 19.4.0, which puts it in Release 19.

The group that did it, SA1, filed 640 documents across 11 meetings, from SA1#98-e to SA1#109 SA1. The study itself, under the acronym FS_Sensing, accounts for 521 of the area's documents ^[5].

One meeting stands out from every other meeting in this record: SA1#101 handled 154 sensing documents ^[6]. That is the shape of a requirements study at full stretch — dozens of companies filing use cases into one report at the same time.

All of those figures are floors. Only documents carrying one of the 14 work item acronyms were counted, and 440 documents whose titles say "integrated sensing" or "ISAC" carry no acronym at all ^[7].

2.5 The trail the study left

Four documents mark the corners of the stage 1 work, and each one is a plenary decision.

• SP-220084 opened the study at SA#95-e — a new study item description, approved SP-220084.

• SP-220717 revised it at SA#96 SP-220717. A study is reopened by a revision, never replaced, so the revision is the document the work plan keeps pointing at.

• SP-230506 approved the finished report at SA#100 SP-230506.

• SP-230750 opened the rule-writing that followed, at the same plenary SP-230750.

There is a hole in that trail worth knowing about. FS_Sensing, the oldest work item of the area, has a work plan entry and an approval document but no work item description on this machine FS_Sensing. So for the very first study there is no recorded objective and no recorded leadership line — everything this course says about it comes from its documents and from the report it produced.

2.6 From nine industries to one

The distance between what the study collected and what is being specified is the most useful single fact in this area.

The stage 2 specification now being written covers aerial object detection and tracking, and says so in its own scope ^[8]. Not driving, not factories, not healthcare. Drones.

The security study says the same thing about itself, and names the reason it is scoped that way — it follows the architecture study.

So two separate groups, working on different questions, both narrowed to the same slice. That is what a first release of a feature normally looks like: one use case built properly, with the rest of the study standing behind it as something to come back to.

Whether anybody will come back to it, this record does not say. There is no document here that drops a use case, and no reason recorded for any decision.

2.7 What the requirements kept

The specification that came out of the study, TS 22.137, is short and says of itself only that it describes functional and performance requirements for the 5G wireless sensing service ^[9]. 119 documents in this record name it TS 22.137, against the 518 that name the study report TR 22.837.

That drop is worth reading. A study collects; a specification decides. The number of documents needed to write down what survived is always much smaller than the number needed to argue about what might.

TS 22.137 also did one thing to the wider 5G requirements: four change requests added a section to TS 22.261, the overall service requirements, pointing at the new document TS 22.261. Without that, a reader of the general requirements would have no way of knowing that sensing requirements exist at all.

2.8 Where to read the real thing

This school carries none of the text of these documents. Go to the source.

• TR 22.837 — the use-case study itself, and the place to see all nine industries argued out TR 22.837.

• TS 22.137 — the requirements that came out of it, short and definitional TS 22.137.

• TS 23.137 — the stage 2 specification, to see how narrow the first build is TS 23.137.

Next: how an area of work like this runs from a study to a rule, and how to read the paper trail it leaves — Study first, rules after — and how to read the trail.