3GPP TSG SA #113 · Madrid · 15–18 September 2026
Welcome to the second of three special reports covering the September 3GPP plenaries, held earlier this month in Madrid.
Three months ago, following the Singapore plenary, I described the circular dependency at the heart of 6G: SA waiting on RAN for migration input, RAN waiting on SA for an architecture, and a long list of smaller decisions (interface names, capability exposure, security method) queued up behind both. Madrid did not break this circle, but at least it decided who goes first – SA WG2.
This month’s Madrid plenary was chaired once again by Puneet Jain of Intel and was devoid of any headline-grabbing set-piece 6G agenda items (we’ll leave that to the RAN group for now). That being said, there was still plenty of substance and unexpected developments.
First though, the usual caveats. What follows is my own summary of the SA #113 proceedings, based on the Chair’s draft report and the submissions referenced within. I also draw on the SA plenaries we have covered over the past year and on our companion coverage from the same week. Oversights, omissions and errors are mine, and I will gladly correct them. Right, on with the show...
Operator considerations for 6G architecture
The most significant document of the week was a six-slide paper titled “Operator considerations for 6G System Architecture”, submitted by AT&T, BT, Deutsche Telekom, KDDI, KT, NTT DOCOMO, Orange, Rakuten, SKT, SoftBank, Telecom Italia, Telefónica, Telenor, Telstra, T-Mobile USA, Verizon and Vodafone. That is seventeen operators across North America, Europe, Japan, Korea and Australia. No Chinese operators and no vendors.
The paper was careful to say it does not select or exclude any architecture option. What it offered instead was three “operator considerations”, which to be honest push hard against the disclaimer.
Evolution as the starting point: 5G SA and the 5G core are the foundation; reuse and evolve existing functions; new or reorganised functions only with a clear requirement or demonstrated value. “A clean-slate redesign of basic connectivity should not be the default starting point.”
Predictable, interoperable essential connectivity: Registration, mobility, session management and QoS stay sufficiently specified end to end and testable across vendors. AI agent functionality may assist, but its deployment and use “shall remain under operator control”, and essential connectivity “should not depend on AI Agent functionality in order to operate”.
New 6G capabilities where justified: Stay open to AI, data, compute and sensing, but every new function or interface needs a technical, operational, service or business rationale; support progressive introduction and smooth 5G-6G migration.
SA was asked to evaluate architecture choices against a list of criteria, including the popular: “strive for a single, coherent and globally applicable 6G system architecture, minimising unnecessary architectural alternatives and market fragmentation”.
SA WG2 reports the architecture study at 65 per cent, with interim conclusions on 15 of the 24 key issues, “mainly focusing on items with good commonality”. A set of three candidate architectures was “extensively discussed” at the working group’s August meeting in Prague. Its list of controversial issues names the role of AI agents, NAS routing, operator services beyond connectivity, and how to consolidate the overall architecture options. The operators’ second consideration is aimed squarely at the role of Agents.
As for the vendors, Huawei said companies still differ in their understanding of 6G requirements, and Nokia said there is little guidance to give beyond “design a single common architecture” and suggested the operators take their paper to SA WG2 directly. The paper was noted. In other words, acknowledged without action.
Except that action followed anyway. The Chair warned that without a stable architecture decision by this coming November the SA WG2 timeline is in danger. And so the SA WG2 Chair drafted a liaison statement for his own group, but the subsequent argument over that draft reveals some interesting positions:
Deutsche Telekom said that with three architectures on the table, it does not want more than one designed;
Telecom Italia and Nokia reminded the room that avoiding unnecessary options is already an agreed high-level principle for 6G;
Qualcomm pointed out that optional features such as cellular IoT and voice over IMS will create options in the architecture whatever the letter says;
Ericsson observed that fights over single sentences that every company reads differently do not guide anybody;
AT&T said the goal is to settle the high-level architecture within the next two SA WG2 meetings;
Vodafone accepted that compromise is coming but warned against a bad one;
and T-Mobile USA delivered my official line of the week: operators have provided input on this, and so far it seems to have been mainly ignored.
What was eventually approved was as follows:
The decision and conclusions on the overall 6G System architecture should be made as soon as possible and no later than SA2#178 (November 2026). SA2 is asked to report the outcome of the overall 6G System architecture to TSG SA#114. SA#114 will discuss and decide any required next steps accordingly.
At least the operators got a date, but not much else for now. I’ve said this before, but large operator coalitions have a mixed record in this process and are not always a guarantee of success.
The migration decision moves on
If you have read our RAN coverage you may recall that September 2026 was pencilled in as the moment the various 5G-to-6G migration options would be pruned. Unfortunately, it wasn’t. The TSG RAN Chair’s status report to SA records that RAN postponed the decision on any additional migration option by three months to RAN #114. What RAN did agree is that efficient sharing of NR and 6G Radio downlink control channel resources shall be supported, which keeps multi-RAT spectrum sharing (MRSS) as the foundation. And for Option 3 it offered a “simplified variant” that “may be considered for further discussion”, closing with a note saying: “SA will make final decision on this option.”
TSG RAN’s view is that only one 5G/6G dual registration scenario may be considered:
no RAN impact expected or specified;
no core network aggregation and no traffic split;
two single registrations, with the device registered to the 5G core over NR and to the 6G core over 6G Radio at the same time;
network-controlled mobility only;
and a target use case of concurrent 5G voice (VoNR) on the 5G leg with 6G data on the 6G leg.
RAN asked SA WG2 to determine feasibility and reply by RAN #114, and expects TSG SA to take the final decision no later than SA #114.
The ensuing discussion appeared to show how unprepared SA was for the handover. For example, and as mentioned in the post-meeting report:
Sony said the scenario looks very much like a Multi-SIM feature and asked about timing impacts;
Ericsson asked why, if there is no RAN impact, RAN had not simply left the matter to company contributions as the SA groups would;
OPPO asked if SA WG2 confirms feasibility, is the outcome Option 3 plus something, Option 1, or both;
AT&T asked whether RAN had looked at voice fallback in 6G at all;
Huawei wanted SA WG1 to clarify the use cases first;
and Ericsson noted that none of this is in SA WG2’s current work plan.
The Chair’s ruling was that the discussion belongs in SA WG2, that TSG SA will take the final decision and inform RAN. When you put this beside the operator letter then the shape of the next quarter becomes clear: SA WG2 must choose between three candidate architectures and assess a dual registration scenario it did not plan to study. It is also worth recalling that at SA #112 SA WG2 reported single-registration-based interworking as its baseline assumption. A dual registration scenario, however simplified, is very a different.
NGMN, meanwhile, did not deliver the updated operator-view paper on architecture and migration it had promised for September, citing that there was no more guidance possible at this stage, and sent six revised key messages instead. They are worth reading alongside RAN’s offer:
NGMN recommends MRSS as the baseline migration approach;
says alternatives should be pursued only where they address deployment gaps MRSS cannot, with enough incremental value to justify the added device, RAN, core and operational complexity;
and notes that the value of any RAN migration option depends on whether the 6G core is an evolution of the 5G core or “a more distinct architecture”.
H is for interface
In June the interface naming question was sent to SA WG2 with a request to report back in September. SA WG2 duly collected seven company proposals and the spread is... interesting, as you can see from this list of sources and proposals:
Nokia and ZTE: H / H
LG Electronics: H, Na, or alternatives
Deutsche Telekom: “Na”, inspired by RAN3 (Na-C to Na2, Na-U to Na3)
Samsung: A-based naming with common base names
OPPO: 6G2 / 6G3 for the RAN-core control and user planes
CATT: 6G N-based naming, plus separate conventions for tool, agent and data framework interfaces
After an overnight offline session (oh to be a fly on the wall for that), the TSG SA Chair tabled the proposal himself: the “H (number)” naming convention shall be used for reference point naming in the 6G System. This applies to reference points between the 6G RAN and the 6G core, between 6G network functions, between 5G and 6G network functions, between a 6G network function and the data network, and between a UE with 6G capabilities and the 6G core.
So “N” gives way to “H” and the interface formerly known as NG now awaits a number. Why H? Absolutely no idea! Whilst I’m not losing sleep over this, I would welcome enlightenment from anyone who was in the room (i know, it will probably turn out to be something incredibly obvious).
Beyond Release 21
There was good news from SA WG1, as the requirements-placement deadlock we covered in June is over: the SA WG1 Chair reported that “a way forward has been found” on where to place the computing, ISAC, immersive and IMS requirements, split between the dedicated 6G specification and existing specifications, and the first 6G-specific change requests to six of those existing specifications were approved in Madrid. The 6G service requirements work item moved from 20 to 40 per cent completed, although one June problem persists: the difference between the “6G Computing Service” definition and the “6G AI service” for training and inference still needs to be made clearer.
SA WG1 now has two meetings left. In November it expects to resolve most of the outstanding notes, add the computing definition and fine-tune the KPIs, reaching 70 per cent completion by the December plenary. In February it expects to complete the rest and send the specification for approval. At the same time, SA WG1 proposes opening the floor to Rel-22 proposals in the fourth quarter, reasoning that only five SA WG1 meetings separate the end of its Rel-21 work from the end of SA WG2’s.
However, a submission from AT&T, entitled “Beyond Release 21”, pushed the other way: suggesting that the group finish Rel-21 before starting anything new, then either move to a single work stream or cut face-to-face meetings from four to three a year.
The Chair concluded that 6G should be the priority for all groups; the expectation that the final 30 per cent of the Stage 1 work can be completed in a single meeting is ambitious and should be reconsidered; and SA WG1 is requested not to allocate any time to Rel-22 discussions in the fourth quarter of 2026. Some time may be allowed in the first quarter of 2027 depending on progress.
A consequence of this is the decision to open SA #115 in Rotterdam a day early “to have more time for the expected discussions”.
Making steady progress
The issue of “secure by design” returned, as we predicted, though not in the form we expected. Rather than a stronger coalition paper, SA WG3 sent a liaison statement declaring secure by design “one of the key principles guiding 3GPP’s 6G work”, reporting that the principles have been captured in its 6G security Technical Report and asking all recipients to consult SA WG3 on emerging designs at the earliest opportunity.
SA WG3 also had the study on authenticated encryption approved, with conclusions agreed on all key issues. Its study on the security and privacy of integrated sensing and communication (ISAC) was approved, which reads more like a 5G-Advanced conclusion yet ISAC is a headline 6G capability. One to watch. The revised study description for 6G Management and Orchestration was also approved, and the 5G-Advanced Stage 2 freeze was achieved with some minor exceptions.
There were some telling inbound liaisons to the meeting:
the Wireless Broadband Alliance on Wi-Fi and non-3GPP access convergence;
5G-ACIA on migrating private industrial networks from 5G to 6G (passed to the working group chairs);
and the IETF liaison’s update on a prospective working group for agent communication protocols.
Orange’s point on the last one was well made, because if 3GPP is going to depend on IETF protocols, then members need to be inside the IETF work keeping it aware of 3GPP’s timelines.
On ITU-R, TSG SA confirmed and endorsed TSG RAN’s agreements on the 6G submission to ITU. 3GPP will submit only a radio interface technology based on 6G Radio, under the name “6G” with the footnote “Developed by 3GPP as 6G, Release 21 and beyond”. It will be presented at the ITU Working Party 5D workshop in February 2027, then three steps should follow:
an initial template for the June 2027 meeting;
a partial self-evaluation for June 2028;
and the final self-evaluation for February 2029.
RAN intends to approve a self-evaluation study item at RAN #114, which will run up to December 2028.
What to look for at SA #114
Single architecture: SA WG2 is asked to decide and conclude on the overall 6G System architecture as soon as possible and to report the outcome to SA #114, which “will discuss and decide any required next steps”.
Simplified Option 3 decision: SA WG2 feasibility feedback on the dual registration scenario is due to TSG RAN by the December plenary (RAN’s own decisions on additional migration options and split bearer are due that week too).
How to finish the 6G studies: SA #114 must also decide how to move forward to finalise the 6G studies in good time.
SA WG1’s closing plan: This is still at 70 per cent complete, with the 6G Computing Service definition still open.
UE-to-core reference point: whether a 6G UE connects to an AMF inside the 6G core or to a new 6G function.
ITU-R: the self-evaluation study item at RAN #114, ahead of the February 2027 Working Party 5D workshop.
SA WG3 checkpoint: access stratum security for 6G, due in December.
NGMN’s guidance paper: the updated operator view on architecture and migration is promised in the coming months.
For the past year the convenient answer to almost every hard 6G question has been “that depends on the architecture”. The pressure is building. If SA WG2 converges in November, then December’s plenary promises to be the most consequential of the 6G study phase.
Next Up: CT #113 report (still waiting on the chairman’s report to be released)
Previous: RAN #113 report
The proposed split between 5G voice and 6G data raises a practical question: if one registration is lost, what must the UE and the other core preserve? I’d want explicit test cases for incoming voice during data activity, loss and recovery of each registration, and the interruption visible to the user. Those failure cases would help compare the options while the architecture is still under study.