The headlines from Singapore last week belonged to RAN: the Rel-21 timeline was locked and the first 6G study was declared complete (read 6G Future’s RAN report here). However, the TSG responsible for the 6G service and system aspects (SA) spent much of its time focused on a more revealing problem: How do you make decisions on a diverse range of issue like interface names, terminology, how security is incorporated and even the choice of file format for the specifications - when almost every one of them depends on an architecture that remains undecided.
That's the circular dependency that any organisation with numerous parallel work groups must wrestle with. Somehow, the hundreds of standards professionals who are responsible for the ongoing evolution of mobile networks manage to achieve this feat, time after time.
As a special treat, we’ll even reveal the correct acronyms for 6G RAN and core - how awesome is that?
Disclaimer time: What follows is my own analysis on the SA #112 proceedings, based on the Chair’s draft report and the submissions referenced within. I also draw on previous SA plenaries we have covered over the past year, and on our companion RAN #112 coverage from the same week. Oversights, omissions and errors are mine, and I will gladly correct them.
By my reckoning, the 6G system architecture study currently contains 24 key issues, each with initial candidate solution variants (often more than one with more allowed to be added later). The work on defining interim conclusions should begin with the SA WG2 work group in August and is expected to be completed in February 2027, just one month before the March 2027 Stage 1 freeze that the TSGs have jointly confirmed.
SA WG2 notes that it is assuming single-registration-based interworking as the baseline for 6G interworking with other systems. That’s a major commitment, even if it’s still provisional. However, it needs early RAN feedback to establish the RAN–core interactions and their interfaces. Yet RAN can’t offer any migration input until the September plenary. So SA waits on RAN, RAN waits on SA! Standards are tricky beasts.
There are some other issues brewing. For example, progress on the RAN–core interface for everything other than connectivity services will be checked this December. Important as there’s a possible risk on CT/RAN user-plane coordination work.
The SA WG1 reported on progress since the last plenary. Whilst a significant batch of requirements have been approved, there is no agreement on the placement of the requirements for ) for computing, ISAC, immersive and IMS features (essentially, which belong in the 6G-specific spec versus the existing technology-agnostic framework).
The Service Hosting Environment (SHE) definition was approved, reused from 5G and unchanged. However, the 6G Computing requirements definition has stalled, with AT&T flagging the lack of progress and Nokia arguing that this isn’t SA WG1’s decision to make and the group shouldn’t be burning time on it. Compute-in-the-network is one of the new 6G features and the question of which working group owns its requirements is not yet resolved.
The most unusual contribution of the week came from a coalition of government and national-security institutions: the UK’s NCSC, NPL and DSIT, Germany’s BSI, the US National Security Agency, NIST, MITRE, Johns Hopkins APL, NTIA, the FirstNet Authority and others — thirteen co-signatories in all, of which only one (Vodafone) is a commercial operator. Their request, which we can trace back to the 6G Workshop in March 2025, was that TSG SA reinforce “secure by design” as a first principle for 6G. They also request that SA WG2, CT WG4 and SA WG3 be empowered to embed security and resiliency into the architecture, protocols and APIs from the outset. It is no longer acceptable, they argued, to treat security as an afterthought bolted on as an over-the-top layer of cryptography.
The coalition pointed out that every RFC the Internet Engineering Task Force (IETF) publishes is required to carry a security-considerations section, and proposed the same approach for 3GPP: make “Security considerations” a default section in every Key Issue description and solution in the Technical Report. This would give it equal weight to the existing “Description”, “Procedures”, “Services, Entities and Interfaces” and “Issues”, ensuring that security cannot be omitted by default.
Unfortunately today’s working method has SA WG2 design the architecture first and SA WG3 do the security analysis afterwards. To compound matters, the SA WG2 Chair noted, reasonably, that the Working Group doesn’t have the security expertise to make those calls. In the end, a revised version of the paper was withdrawn, and proposal merely “noted”. Bureaucracy may have nobbled this proposal for now, but the IETF approach is too sensible to be ignored completely. Expect it back in September in a more strongly-worded form.
For anyone who has been following our 3GPP reporting since early last year, you will be aware of “Capability Exposure”. This important governance question was postponed at SA #109, deferred after a network-management discussion at SA #110, postponed again later in that same meeting, and sent back to SA WG6 unresolved at SA #111. At SA #112 it surfaced only obliquely, with the SA WG6 Chair clarifying that Capability Exposure is not part of the 6G Application Enablement study and therefore sits under a separate scope.
Translation: It is still not decided.
And the reason is now all too familiar: You can’t define how to expose the capabilities of a 6G system whose capabilities aren’t yet known. Four plenaries in (and a year later), Capability Exposure has become the standard bearer for the whole “decide-the-architecture-first” problem.
Meanwhile, SA WG5 confirmed the structural decision that 6G management will be a separate system from the 6G System itself, consistent with how 4G and 5G were handled. The OAM/management story connects directly to the RAN-side debate over a standardised open 6G-RAN-to-OAM interface. This is the same issue, viewed from the other side.
As part of the Rel-21 timeline work, SA WG2 was requested to develop 6G interface names and a naming convention, especially for RAN–CN interfaces, and report back to the TSGs in September. Ericsson called it a simple task that needn’t consume June meeting time. Qualcomm framed it as normative work, not study work; Huawei narrowed it to the RAN–CN interfaces only; and Nokia wanted to agree only a naming “convention”, not the actual names.
But as Qualcomm pointed out: name the interface and you have implied the architecture behind it. The end result is... we pick it up again in September. The argument is that you cannot responsibly name, expose or define interfaces that have not yet architected.
Related to this, but a separate item on the agenda, is the naming of components, which in theory should be a lot easier as they have already been defined. Yes, well...
A basic terminology document from Ericsson tried to get a common 6G vocabulary endorsed across the TSGs and working groups. The snag was the core network’s short form. MediaTek objected that an over-compressed “6GC” risked being misread as two core networks; Ericsson noted “6G CN” was already in use and saw little value in churning it; and CATT suggested “6GC a.k.a. 6G CN” (yes really). Delegates eventually settled on the gloriously diplomatic “6GC or 6G CN,” and a liaison statement was swiftly approved to tell everyone the terms are endorsed.
Here’s the base set that will now be used:
6GS (6G System)
6GR (6G Radio)
6G RAT (6G Radio Access Technology)
6G RAN (6G Radio Access Network)
6GC or 6G CN (6G Core Network)
It would be easy to file this under light relief (just as RAN3 was dispatched to argue whether the higher-layer split is a “reference” or a “baseline”). However - and stop me if you’ve heard this before - the terminology may have to change depending on the final architecture decision.
The largest single block of discussion in the SA report wasn’t about 6G’s content at all: It was about how 6G’s specifications get authored. The FS_6GSpecs study, run as a joint RAN/SA/CT session, is asking (not unreasonably) whether 3GPP should move off Microsoft Word and toward markdown, Git, the “Forge” toolchain, and standalone ASN.1.
Pushing to trial the new formats were Qualcomm, Ericsson, Nokia and Apple, with Deutsche Telekom making the cleanest argument — that you can’t escape the trap of “no decision without information, no information without trying it” unless you actually run trials. Apple’s contribution was right on the money: Machine readability now matters because people are already feeding 3GPP specifications to large language models, and specs that aren’t machine-readable will produce wrong answers when an LLM ingests them. That is a genuinely new design pressure on a standards process and it is going to grow.
Showing a greater level of caution were Huawei, CATT, China Mobile, Samsung and ZTE. Their case was about resourcing and risk, saying that a trial would mean at least six months for a first loop and a year for anything solid. 6G work is intensifying and competing for the same delegates, and trialling new formats on live 6G Technical Reports risks confusion between two versions of the same document.
The guidance that emerged split the difference and, on the most contested point, Huawei essentially won: The separated-ASN.1 trial continues; interested companies are encouraged to demonstrate Forge on a real, regularly-updated specification; but 6G-related TRs and TSs are not to be used for the trial.
Between the secure-by-design debate and this one, SA #112 spent serious energy interrogating how 3GPP works rather than what it builds. Both are symptoms of a organisation that knows the 5G way of working became strained under its own weight and is trying, cautiously, not to repeat the problem with 6G.
SA’s third quarter is unusually heavy, because August is when the architecture finally starts converging:
SA WG2 architecture conclusions begin: Interim conclusions on the 24 Key Issues start here and run to completion at SA2 #179 in February 2027.
Interface naming decided: The naming-implies-architecture fight returns in the September plenary for an actual decision.
Requirements-placement deadlock: The SA WG1 Chair targets August for resolution.
Capability Exposure: A fifth plenary beckons...
Secure by design, round two: Watch for a more concrete, actionable proposal to replace the withdrawn paper.
Specification modernisation: The FS_6GSpecs project plan and minimum requirements are due, along with the assessment of working-method impact.
Cross-TSG: RAN’s migration-options decision is in September and SA2’s August architecture review is meant to feed into it.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.