6 RAN3, and where the radio rule-writing went

6.1 The half of the radio problem that is not radio

A 5G base station is not one box. It is a set of nodes that have to agree with each other and with the core network, over defined interfaces, about what each of them is doing.

RAN1 answers whether a signal can be read. Somebody then has to say which node asks for a measurement, which node makes it, what it sends back and in what message. That is RAN3's ground, and it is where the sensing work moved once the studies were done.

RAN3 has 259 documents on this subject, from RAN3#129-bis to RAN3#133 RAN3. Its reply liaison to SA2, R3-261541, is one of only three liaisons the record marks as actually sent R3-261541.

6.2 What the work item promises

The RAN work item was opened by RP-261566 at RAN#112 RP-261566, and its objective is one of the shortest in this whole area.

Two sentences, and the second one is the more useful. No UE impacts means nothing in the phone changes: no new radio behaviour to implement, no new signalling for a device to support, nothing for a handset maker to certify.

The sensing happens at the base station and stays there. That is what makes this a network feature rather than a device feature, and it is also why the remaining work is about interfaces rather than about the air.

6.3 The three documents it will change

Three radio specifications carry this work, and reading them together explains the move to RAN3 better than any statement of intent could.

• TS 38.300 is the overall description of the 5G radio network — what the radio side is made of and how it behaves TS 38.300.

• TS 38.401 is its architecture — which nodes exist and how they are wired together TS 38.401.

• TS 38.473 is F1AP, the protocol spoken between the two halves of a split base station TS 38.473.

Not one of the three is a physical-layer document. They are the description, the architecture and an interface protocol, which is the work that is left once the question "can it be done" has been answered elsewhere.

The third of them is worth a paragraph on its own, because it is the most concrete. A modern base station is normally split into two parts — one holding the higher-layer processing, one sitting near the antennas — and F1AP is the protocol they speak to each other. Anything the antenna half has to be told to do, or has to report back, ends up as a message in TS 38.473.

The record does not say why the work went to RAN3. It says who leads it and what it targets, and nothing in this data records the reason for any decision. The reading above is the shape of the evidence, not a minuted argument.

6.4 How far it has got

Barely started, and the numbers say so plainly.

• TS 38.473 is named by 5 sensing documents, and none of them is a change request TS 38.473.

• TS 38.300 and TS 38.401 are both listed by the work item as documents it will change, and neither has a sensing change request in this record TS 38.300 TS 38.401.

• The acronym NR_Sensing_bis-Core carries exactly one document, at RAN3#133 ^[2].

One document is not a stalled work item; it is a work item that has just opened. What it does mean is that anybody wanting to know what sensing will look like on the radio side has to read the study report and the work item description, because the specifications do not contain it yet.

6.5 RAN3 was there before it led

It would be wrong to read the 259 documents as the work of the new work item. They are not: the acronym NR_Sensing_bis-Core has exactly one document against it ^[2], and RAN3's total is 259.

Almost all of that traffic was filed while the studies were running. RAN3 was in the room for the radio study, and it was in the conversation with SA2 — its reply liaison R3-261541 is the proof R3-261541.

That is the normal way a hand-over works in 3GPP. A group that will have to write the specification takes part in the study that decides what the specification says, so that when the work item opens there is nobody who has to be brought up to speed.

6.6 Filed twice, on purpose

The work plan carries this work item twice, and a reader who does not expect it will double-count.

• NR_Sensing_bis is the feature NR_Sensing_bis.

• NR_Sensing_bis-Core is its core part NR_Sensing_bis-Core.

Both are described by the same document, RP-261566. Only the core-part entry has a document against it so far.

6.7 Who RAN3 has to agree with

A measurement saying that something is at a particular place is exactly the kind of data privacy rules get written about, and the group studying that is SA3 — Security, applications, management and protocols covers what it has been doing.

The conversation with the architecture side is already on the record. SA2 sent S2-2511045 asking what needed coordinating with RAN S2-2511045, and RAN3's R3-261541 is the reply R3-261541.

6.8 What this means if you build networks

Three practical readings follow from this chapter, and all three are checkable in the same record.

• Nothing changes in handsets. The work item says so ^[1]. A device fleet does not need a refresh for this feature.

• The radio specifications do not describe sensing yet. TS 38.300 and TS 38.401 carry no sensing change request TS 38.300 TS 38.401, and TS 38.473 carries none either TS 38.473. Anybody quoting a radio specification for sensing behaviour today is quoting something that is not in it.

• The place to look instead is the study report. TR 38.765 is approved, at 20.0.0 TR 38.765, and it is where the conclusions the work item builds on actually live.

6.9 Where to read the real thing

The text of none of these is here.

• RP-261566 — the work item description, and the shortest statement of what RAN3 promised RP-261566.

• TR 38.765 — the study report the work item builds on TR 38.765.

• TS 38.300, TS 38.401 and TS 38.473 — the three documents that will carry the result, once the change requests are written TS 38.300 TS 38.401 TS 38.473.

Next, back to the beginning of the chain: the group that wrote down what the system has to be able to do — SA1, and writing down what the system must do.