Daily Dose of 6G

Where to cut the base station

TR 38.760-3 is the RAN3 part of the 6G radio study — RAN architecture, the interfaces between network nodes, and the 6G data collection framework. It carries the highest version number of the four parts and the oldest upload date. Both facts say the same thing.

Transcribed from 3GPP’s published Release 21 timeline (© 3GPP 2026). The highlighted row is RAN3’s own normative deadline — RAN2 and RAN3 share the Q4 2028 functional freeze, which is why it is highlighted a second edition running.

The record

Refreshed this morning, because the version figure quoted here before came from an older pass. TR 38.760-3, “Study on 6G Radio RAN3 aspects”, 38 series, responsible group RAN3, initially planned Release 20, rapporteur Alexey Kulakov, Vodafone Group Plc. Latest version 0.6.0, uploaded 22 June 2026. Linked work item FS_6G_Radio (1080072).

Put the four parts side by side. RAN1’s -1 is at v0.4.0, uploaded 14 August. RAN2’s -2 is at v0.1.1, its v0.1.0 uploaded the same day. RAN3’s -3 is at v0.6.0 — ahead of both — and untouched since June. The highest version number belongs to the least recently edited document.

Read as this newsletter reads it, that is not neglect. RAN3’s central question is where to draw boundaries — inside the base station, and between it and the core. Those can be chosen before anyone knows the subcarrier spacing. RAN2’s protocol stack cannot; it has to wrap whatever RAN1 settles. RAN3 took its structural decisions early, banked them at v0.6.0, and has been waiting since June on the parts that depend on other groups.

What RAN WG3 owns

3GPP’s group page heads RAN WG3 “UTRAN/E-UTRAN/NG-RAN Architecture and Related Network Interfaces”, and states the group is “responsible for the overall UTRAN/E-UTRAN/NG-RAN architecture and the specification of protocols for the related network interfaces”. The formal terms of reference live in RP-210771, approved at RAN#91-e — not opened for this edition. Where RAN2 owns what happens over the air interface, RAN3 owns everything behind it: the boxes, and the wires between them.

The same weeks, the same cities: RAN3#133 sat in Maastricht alongside RAN1#126 and RAN2#135, RAN3 running seven meeting-numbers ahead of RAN1 and RAN2 nine. FS_6G_Radio closes 4 June 2027, so with #133 gone five RAN3 meetings remain — the identical budget the other two groups have. RAN3#136 ends 28 May 2027, one week out.

Two shapes for a base station

Ericsson’s standardization post of 12 June 2026 — Daniel Chen Larsson, Ricardo Blasco and Per Emanuelsson — gives the clearest public account of what RAN3 has settled: “There will be two design options for providing a base station, excluding the purely radio parts. The first option is to treat the base station as a single unit, as agreed at the start of the 6G study. The second option, agreed in June 2026, is to implement a higher-layer split that, similar to 5G, divides processing into two parts: a distributed unit (DU) and a centralized unit (CU).”

Below that sits the radio itself, and here 3GPP names a seam and declines to specify it. The same authors: “A lower-layer split (LLS) — a multi-vendor interface between the base station’s processing part and the radio unit (RU) — may also be present. The LLS will be defined in a schematic way in 3GPP, with details defined by the O-RAN Alliance.” Xingqin Lin of NVIDIA, in an arXiv overview citing TR 38.760-3 v0.6.0 directly, puts it more sharply: “the RU functions and the interface between the RU and the rest of the aNB remain outside 3GPP specification.”

Point-to-point, not service-based

The other early decision is the interface out of the RAN. 5G’s core is service-based; the question was whether the RAN–core boundary should follow. Ericsson: “it has been decided that connectivity services in 6G should follow a point-to-point (P2P) design, with the protocols realizing this interface to be determined later in the study.” Lin agrees the direction “favors a point-to-point (P2P) application model between the aNB and a 6G CN entity, instead of using a service-based interface (SBI)”, and names four interfaces in scope: CU–DU, CU-CP/CU-UP, RAN–core, and the interface between aNBs.

What 3GPP’s own file server shows

RAN3’s drafting inbox is on the open web, and the directory listing under /FTP/Meetings_3GPP_SYNC/RAN3/Inbox/Drafts/ reads as an agenda. Its 6G conference-block folders: CB #8_6GCharacteristsAndPerformance, CB #9_6G_SA2Reply, CB #10_6GSBI_NewSection, CB #11_6GHLS, CB #12_ISAC_arch, CB #13_ISACproc, CB #20_6GPaging, CB #6GAIML1_Usecase and CB #6GAIML2_framework. A separate search surfaced one more, CB #17_6GDataCollection, holding a draft change request to TR 38.760-3 on the data collection framework — that file returned 403 and was not read.

What is still open

Lin’s overview closes on three unresolved areas, a fair map of RAN3’s remaining five meetings: the RAN–core interface for non-connectivity services, the data collection framework, and AI for 6G RAN. On the second, the ambition is broad and the specification is empty: “6G RAN is expected to support standardized measurement data collection and transport. The architecture must define what data is collected, where it is transported, how it is governed, and how operator control is enforced.”

Four unanswered questions in one sentence — and one of them, governance and operator control, is barely an architecture problem at all. Five meetings.