8 SA2, and how the system is put together

8.1 The group that has to make it fit

SA2 writes stage 2: what the system is made of and how the pieces talk. For a new feature that means answering questions nobody else can duck — which function is responsible, what it is allowed to know, who may ask it for something, and what happens step by step when they do.

For sensing this has been the biggest single job in the area. SA2 has 995 documents across ten meetings, from SA2#167 to SA2#175 SA2 — the largest count of any group in this record.

It leads both halves of the architecture work: the study FS_Sensing_ARC and the rule-writing Sensing-ARC FS_Sensing_ARC Sensing-ARC.

8.2 The study

FS_Sensing_ARC carries 706 documents ^[4]. Its own statement of what it is for reads almost identically to the report it produced.

Three things in there set the boundaries of everything SA2 has done since.

• Function enhancement — the architecture may gain functions, or existing functions may gain responsibilities.

• End-to-end service operations and procedures — not a radio question, but the whole chain from whoever asks for a sensing result to whoever produces it.

• A sub-set of use cases — the study never intended to cover all nine industries that TR 22.837 collected.

The reason offered for the work is broader: the growth of wireless technology and the demand for high-quality data transmission, and the integration of sensing and communication as a technology with the potential to change several industries ^[5].

The trail is three plenary documents. SP-250401 opened the study at SA#107 SP-250401. SP-250809 was a revision that was itself revised at SA#108 SP-250809, and SP-250833 is the revision that was approved there SP-250833.

8.3 What came out: TR 23.700-14

The report is TR 23.700-14, and it is named by 657 documents TR 23.700-14 — more than any other document in this area.

It stands at 20.0.0, a Release 20 document, and SP-260110 put it to the plenary at SA#111, where it was approved SP-260110.

Two definitions in it are the vocabulary the rest of the system side uses.

• Sensing Function — the logical function involved in supporting the sensing service ^[6]. "Logical" is doing work in that sentence: it is a responsibility in the architecture, not a box in a rack, and one product may hold several logical functions.

• gNB-based Sensing — the base station acting as the sensing entity, with the definition adding that this implies nothing about where the sensing result is worked out ^[7].

8.4 The rule-writing

SP-260297 opened Sensing-ARC at SA#111 SP-260297, and the acronym already carries 302 documents ^[8].

That is how normative work is normally bound to a study: not "do sensing", but "turn the conclusions of clause 8 into specification text", key issue by key issue. A key issue is a numbered question a study sets itself; the register carries no key issue of any study, only the fact that the work item points at them.

The register's copy of the objective stops after the first one. The rest is in SP-260297, which is one reason to read it rather than this page.

8.5 What is being written: TS 23.137

The specification is TS 23.137, "Integrated Sensing and Communication; Stage 2". It stands at 0.3.0 — below 1.0.0, so a draft — with 262 documents naming it TS 23.137.

Its scope is the narrowest statement in this whole area: the stage 2 of sensing in the 5G system, based on the requirements of TS 22.137, "only focusing on aerial object (e.g. drone) detection and tracking use case" ^[9].

One use case, from a study that considered a sub-set, from a stage 1 study that collected nine industries. That funnel is the honest summary of where this area is.

8.6 The two documents everybody already reads

Sensing does not only create documents; it changes the two that describe the 5G system itself.

• TS 23.501 is the 5G system architecture — the reference model, every network function and what each is for. The sensing work updates the reference model and the network functions in it, in 13 change requests so far TS 23.501.

• TS 23.502 is the procedures of that system — the step-by-step message flows. The sensing work updates procedures and service definitions there, in 8 change requests TS 23.502.

Both counts are small against 995 SA2 documents, and together they are the clearest single measure of how early this work is: the architecture of 5G has barely been altered yet.

8.7 The funnel, in one place

SA2 sits in the middle of the narrowing, and it is easiest to see as four steps.

• F1. SA1 collected nine industries in TR 22.837 TR 22.837.

• F2. SA1 turned that into requirements for the sensing service in general, in TS 22.137 TS 22.137.

• F3. SA2 studied a sub-set of use cases — commercial, automotive, public safety and emergency services are the examples its own objective names ^[1].

• F4. SA2 is specifying one: aerial objects, detected by base stations ^[9].

Nothing in this record says the discarded parts were rejected. They are simply not in the first specification, and no document here records a decision to drop any of them. That distinction matters if somebody asks whether 3GPP has ruled out sensing for vehicles: this data cannot answer that, it can only say what the first specification covers.

8.8 Talking to the radio side

SA2 cannot settle the architecture alone, because half of it depends on what the base station can be asked to do. The record holds that conversation as a pair of liaisons: S2-2511045, SA2 writing about what needed coordinating with RAN S2-2511045, and R3-261541, RAN3's reply R3-261541.

Two of the three liaisons the record marks as sent in this whole area are those two documents, which says something about where the hard boundary is.

8.9 Where to read the real thing

None of this text is carried here.

• TR 23.700-14 — the architecture study, including the clause 8 conclusions the work item is bound to TR 23.700-14.

• TS 23.137 — the stage 2 specification as it is being written TS 23.137.

• TS 23.501 and TS 23.502 — for what sensing is doing to the 5G system proper TS 23.501 TS 23.502.

• SP-260297 — the work item description, for the full list of key issues being specified SP-260297.

Next, the four remaining groups: security, management, the application layer and the protocols — Security, applications, management and protocols.