6G Takes Shape: What the August 2026 Working Groups Actually Agreed

The short version

The 6G architecture is being written now, and the August round produced its first real skeleton. Eleven agreed pseudo-CRs went into TR 23.801-01, the architecture technical report, carrying principles for eleven key issues (KI#1.1, 1.2, 2, 3, 4, 6, 9, 11, 12, 19 and 21). They answer questions that have been open since 6G study began: how voice works, what happens to the control plane, whether network slicing survives, how the radio carries data.

The answers share a pattern. Where 5G worked, 6G keeps it and deletes the options nobody used. Where 5G left a choice, 6G picks one. That is a less dramatic story than a clean-slate redesign, but it is what the record shows.

Three things are worth knowing before the details:

• Release 20 is not 6G. Of 11,497 Release 20 documents, 5,279 (46%) carry a 6G work item code. The other 54% is 5G-Advanced. Release 20 is a study release for 6G and a normative release for 5G-Advanced at the same time. (Across all releases the round produced 5,770 documents with a 6G code; the balance is mostly Release 21, where normative 6G work will land.)
• The September plenaries do not decide the architecture. SA2 agrees interim conclusions; the plenary notes the resulting report version and approves work items and schedules. The architecture decisions described here have already been taken.
• The radio is further behind than the core. RAN1 is still agreeing evaluation methodology and study options. The core has principles; the radio has homework.

What 6G is supposed to be

The architecture decisions below answer to a frame set outside 3GPP: ITU-R Recommendation M.2160-0, "Framework and overall objectives of the future development of IMT for 2030 and beyond", published November 2023. 3GPP's own requirements study, TR 22.870 ("Study on 6G Use Cases and Service Requirements", Release 20), states that it is "structured along the lines of the six usage scenarios, to be addressed in 6G, as identified by the ITU-R":

• Immersive Communication — expanding enhanced Mobile Broadband (eMBB)
• Hyper Reliable and Low-Latency Communication — expanding URLLC
• Massive Communication — extending massive Machine Type Communication (mMTC)
• Ubiquitous Connectivity — coverage for rural, remote, sparsely populated areas and indoors
• Artificial Intelligence and Communication — supporting distributed computing and AI applications
• Integrated Sensing and Communications (ISAC) — wide-area multi-dimensional sensing of connected and unconnected objects

Three of the six are new relative to 5G's triangle of eMBB, URLLC and mMTC. TR 22.870 adds the ITU-R's overarching design principles: sustainability, security and resilience, connecting the unconnected, and "ubiquitous intelligence for improving overall system performance."

This explains the shape of the SA2 agenda. AI, the data framework and sensing sit at the top of the architecture work because two of the six mandated usage scenarios require them, and a third principle — ubiquitous intelligence — runs across all six. It also explains why the radio groups are studying sensing waveforms at all — ISAC is a scenario the framework obliges 6G to serve.

The radio side has its own frame in TR 38.914 ("Study on Scenarios and Requirements for 6G Radio"), which derives minimum technical performance requirements from the same M.2160 capabilities.

The schedule

None of this makes sense without dates. 3GPP set them at TSG#112 in Singapore on 10 June 2026, in the plenary decisions recorded as RP-260868, SP-260595 and CP-261259, and published as the Release 21 timeline.

In parallel, ITU-R Working Party 5D accepts candidate IMT-2030 technologies from February 2027 (WP5D#54) to February 2029 (WP5D#59), with detailed specifications due June 2030 and the M.[IMT-2030.SPECS] Recommendation expected in 2031.

Two things follow. The architecture principles described in this article are being written roughly two years before the specification that will implement them freezes. And the 3GPP ASN.1 freeze of March 2029 falls after the ITU submission window closes, so the material submitted to ITU would have to rest on the December 2028 Stage-3 content rather than the final protocol freeze, unless 3GPP brings the freeze forward. Both schedules have moved before and may move again.

What was actually agreed

Quotations below are from the agreed pseudo-CRs; contributions cited by company name are proposals, and anything marked with an Editor's Note is open.

Voice: IMS stays; the fallback question stays open

The clearest decision of the round. S2-2608665, approved, sponsored by Nokia, T-Mobile USA, Ericsson and ZTE, writes ten principles into the report. The first one settles it:

The existing IP Multimedia Core Network Subsystem (IMS) architecture and procedures are re-used for supporting voice calls in the 6G system, including the HSS which stores all IMS profile and IMS service information.

The 6G system acts as the IP-Connectivity Access Network, exactly as 5G does. Voice uses IMS identities (IMPI, IMPU). The core and the device use the well-known DNN for IMS.

For operators, two consequences matter more than the headline. First, on interworking, the agreement says: "Service continuity for voice between 6G RAT and 5G RAT is supported by maintaining the UE IP address during UE mobility between the RATs." This covers an ongoing call moving between radio technologies, and the document adds that the detailed PDU Session handover procedure "will be specified" later. It is worth being precise about what this does not say: the word "fallback" does not appear in the agreed text at all. Whether 6G will need something like EPS fallback — redirecting call setup to another radio where 6G voice is unavailable — is a separate question that these principles do not answer.

Second, on protocols, the agreement keeps Diameter alive but freezes it: the PCF supports both the Diameter Rx interface and Service-Based Interfaces toward the P-CSCF, and the HSS supports both Diameter (Cx, Dx, Sh) and SBI. A note adds: "No new reference points based on Diameter will be defined between IMS and 6G CN." Existing Diameter deployments keep working; new development goes to SBI.

User plane: the split stays, the options go

S2-2609007 (ZTE, Nokia, Ericsson, ETRI, Samsung) confirms the control/user-plane split survives into 6G — a 6G session-management function decides, one or more user-plane functions execute. The interesting half is what was deleted:

Unnecessary options in CP-UP functional split are removed to simplify CP-UP interactions and multivendor interoperability.

Two named casualties, both traced to specific clauses of TS 23.501: 6G SMF buffering is not supported (in 5G it was optional in the SMF and mandatory in the UPF — 6G drops the optional half), and the 6G SMF does not construct End Marker packets (5G allowed either SMF or UPF; 6G assigns it to one place).

Neither will be noticed by a subscriber. Both are exactly the kind of "implementation choice" that has cost the industry years of interoperability testing, and removing them is the concrete meaning of "simplification" in this release.

What remains contested is the interface itself. Ericsson proposes evolving 5G's PFCP; Ericsson and Nokia jointly propose a hybrid where non-session procedures move to service-based interfaces while sessions stay on PFCP; ETRI, Nokia and LG propose going fully service-based. That fork is not closed.

Network slicing: unchanged where it counts

S2-2609210 (ZTE, LG, Lenovo, Samsung, Huawei, China Mobile, Nokia, Ericsson, T-Mobile USA — an unusually broad sponsor list) opens with:

S-NSSAI (i.e. SST and SD) identifies the network slice, and the S-NSSAI format is kept the same as 5GS.

Slice identification is carried over unchanged. Anyone who built slice-aware operations for 5G keeps them.

A single framework for operator services

The least visible and possibly most consequential agreement. S2-2609034 (Samsung) defines a common service NF that terminates a single NAS association carrying operator service signalling, plus service-agnostic mechanisms for discovery, capability negotiation, authorisation, and transport of both signalling and data.

The agreement then binds the rest of the study to it: sensing (KI#20), AI (KI#19), data (KI#21) and computing (KI#22) reuse these common mechanisms rather than inventing their own, and "service-specific alternatives to the service-agnostic common mechanisms should be avoided, unless justified."

In 5G, each new capability arrived with its own signalling and its own exposure surface. This agreement is an explicit attempt not to repeat that.

Non-3GPP access: a new function, and NAS is dropped

S2-2608612 (Ericsson, Apple, Qualcomm, AT&T, Verizon) introduces a new network function for non-3GPP access, with mutual authentication between device and network over a secure transport layer. And a genuine break with 5G:

The NAS protocol is not used when the UE accesses 6G CN via non-3GPP access.

That principle comes with a caveat in the same document, and it matters: an Editor's Note records that "whether NAS is used via the new NF (as in solution #11.1) or NAS is not used (as in solution #11.3) … is FFS." So the agreed text states the non-NAS outcome while the accompanying note keeps the question formally open — a normal state in a study, and a reminder that agreed principles are not yet specification.

The signalling protocol will be either IKEv2/IPsec or QUIC, also explicitly open. QUIC as a carrier of mobile-core signalling would be a notable departure; it is on the table, not decided.

The direction of travel is nevertheless visible in the discussion that led there. The sponsors catalogue five solution families — NAS-based (as in 5G's N3IWF), a gateway running NAS on the UE's behalf, fully non-NAS using EAP/IPsec/QUIC (as in ePDG), and two hybrids — and record the observation that "a non-NAS based solution is preferrable for 6G. It constitutes a single solution that can cater for all kinds of devices/UEs." The stated motivation is to end the proliferation of N3IWF, TNGF, W-AGF and TWIF that 5G accumulated since Release 15.

AI in the core: the shape is agreed, the architecture is not

This is where reporting must be careful. S2-2609110 (Samsung) agrees that the 6G core studies providing AI inference and training to applications, and names the functional blocks: AI model training management, AI inference management, training and inference operation, and an AI repository.

But the same document carries the line: "Which architecture option(s) will be down-selected is FFS." The competing proposals are live — Nokia, NVIDIA, Federated Telecoms Hub and T-Mobile propose a separate AI domain within the 6G core; Google, ZTE, Ericsson, AT&T and T-Mobile propose roaming support for it; InterDigital and Oracle propose intent handling embedded in existing functions. No winner has been picked. Any report saying 6G "will have an AI domain" is ahead of the record.

The data framework: agreed in ambition, open in mechanism

S2-2609239 (vivo, China Mobile, Nokia, Samsung, Huawei, CATT, OPPO) agrees the framework must avoid redundant collection of the same data from one producer, must support high-volume and frequent transfer, and that a data producer may refuse a collection request.

The Editor's Notes are more revealing than the agreements: "whether data framework is realized over control plane, user plane, data plane and/or combination is to be determined", and who may act as producer or consumer is likewise undetermined. Enforcement of subscriber permission for data collection — the privacy question — is also marked open.

The radio: still choosing how to measure

Seven RAN working groups met, and their output is at an earlier stage. The most consequential agreements are ones of continuity. On sensing, RAN1#126 agreed:

CP-OFDM waveform as defined for 6GR is the starting point for 6G ISAC waveform study. Study on enhancements on CP-OFDM or other waveforms is not precluded.

Read carefully, that is a decision about the sensing study, and it presupposes a 6GR waveform already defined elsewhere — the separate 6GR waveform study, whose own agreements are not in the documents reviewed here. What it does establish is that CP-OFDM, the 5G NR waveform, is the reference point rather than a challenger. The same summary notes CP-OFDM "is used as the benchmark for evaluating the benefits of sensing waveforms."

Modulation is the stronger direct evidence: 6G downlink takes NR's QPSK, 16QAM, 64QAM, 256QAM and 1024QAM as the basis for study; uplink up to 256QAM. Enhancements are not precluded, but the baseline is inherited from NR. On the evidence available here, the 6G air interface is being built as an evolution of NR rather than a clean-slate design — though the definitive waveform decision sits in RAN1 documents outside this set.

The frame structure follows the same logic: 6G's communication frame structure is the starting point for sensing, "in at least the following aspects: frame/sub-frame/slot/symbol structure, CP length, SCS."

Where the radio work is genuinely new is the ~7 GHz band (the upper mid-band, FR3). RAN1 has agreed measured coverage gaps between 7.0 GHz and 5G mid-band at 3.5 GHz for initial access — the physics problem of the band. Related agreements cover longer SSB periodicity (160 ms as a candidate default, versus 20 ms today) for network energy saving, and resource-block boundary alignment between NR and 6G on a shared carrier — the mechanism that would let an operator run both on one carrier.

RAN4 is studying 7 GHz coexistence, spectrum sharing, AI-based radio resource management, and unified 6G measurements. Much of that agenda is evaluation methodology, not design.

Security, management and the parts nobody demos

Two working groups did substantial 6G work that rarely makes summaries.

SA3 (security) spent 52 agreed documents on a single agenda item: Study on Security for the 6G System — a security architecture study running in parallel with SA2's system architecture work.

SA5 (management and charging) concentrated on Study on Charging Aspects of 6G System (41 agreed documents) plus management topics that read like a list of what an autonomous network needs: intent (13), network digital twin (11), cloud (8), management scenarios, and knowledge and semantic management. Charging is the least glamorous item in this article and the one most likely to determine whether any of the new capabilities can be sold: a capability that cannot be metered cannot be billed.

The migration question

For an operator, the most expensive decision of a generation is how to get to 6G at all. The agreed texts touch it from several sides without settling it.

Voice gives the clearest signal: service continuity between 6G and 5G radio is to be provided by preserving the device's IP address during mobility, which presumes the two systems run side by side for years rather than one replacing the other. Network slicing keeps the S-NSSAI format unchanged, so slice-aware operations carry over. The user-plane agreement keeps the CP/UP split; whether the interface itself stays on PFCP is one of three live proposals, and that choice will decide how much of the existing UPF ecosystem carries forward.

RAN1 adds the radio half: "Resource block boundaries alignment is supported between NR and 6GR on a MRSS carrier" — the mechanism that lets an operator run NR and 6G on one carrier through spectrum sharing, rather than clearing spectrum before launch. Longer SSB periodicity, with 160 ms studied as a candidate default against today's 20 ms, is being evaluated explicitly for network energy saving.

What none of the reviewed documents answers is whether 6G radio will attach to an evolved 5G core or require a new one. The architecture work assumes a "6G CN" throughout, and KI#17 (Migration and Interworking) drew 70 documents in SA2 — but no agreed principles for it appear in the pCRs reviewed here. It remains one of the round's open questions.

Satellites: a mandated scenario, not an add-on

Ubiquitous Connectivity is one of the six ITU-R usage scenarios, aimed at "uncovered or scarcely covered areas (e.g. rural, remote, sparsely populated areas, indoors)." That elevates non-terrestrial networks from the bolt-on they were in Release 17 to a capability the framework obliges 6G to serve.

The work is visible but early. SA2 ran a dedicated agenda item on Support of 6G NTN (59 documents), and RAN1 held five rounds of feature-lead summaries on NTN specific requirements and design. Neither produced agreed architecture principles in this round — NTN is where 6G's stated ambition currently runs furthest ahead of its agreed text.

What 5G promised and what 6G promises again

The most useful context is what happened to the previous generation's promises. 5G was sold on network slicing, edge computing and ultra-reliable low-latency communication. Slicing shipped and is identified the same way in 6G — but commercial slice products remain rare. Edge computing got a full architecture (EDGEAPP in SA6) that few operators monetised. URLLC exists in specification and in a small number of industrial deployments.

6G now proposes computing coordination, an AI service layer, and integrated sensing. These are the same kind of promise: capabilities the network exposes to third parties, whose value depends on someone building a business on top. The specification work is real and the engineering is serious. Whether operators sell it is a different question, and the record of the last generation suggests scepticism is the reasonable default.

The single-framework agreement in KI#1.2 is the strongest counter-argument. By forcing sensing, AI, data and compute through common discovery, authorisation and transport mechanisms, 3GPP is trying to make these capabilities cheap to adopt rather than each one a bespoke integration. That is a direct lesson from the 5G exposure sprawl.

What the Madrid plenaries will and will not do

SA#113, RAN#113 and CT#113 meet in Madrid on 14–18 September. In a study phase, plenaries do not re-open architecture; they note the updated technical reports, approve new and revised work and study items, and confirm the schedule.

What they will process in volume is change requests — 2,319 of them in 322 packs. The distribution is the useful number:

Pack counts are per release and sum to more than 322 because a single CR pack can carry mirrored change requests for several releases; 322 is the number of distinct packs.

Nearly half of what the plenaries handle is Release 19 maintenance. The Release 20 change requests are overwhelmingly 5G-Advanced normative work. The 6G study produces almost no change requests — it produces pseudo-CRs into technical reports, which is why the architecture decisions above never appear in this table.

Madrid does have a substantive milestone, and the schedule identifies it: September 2026 is the Stage-2 freeze for Release 20 5G-Advanced. That is what those 927 Release 20 change requests are for. The plenaries are closing the architecture of 5G-Advanced while the 6G study runs on beside it — the clearest illustration of the double life this release leads.

For 6G itself, Madrid is procedural: noting updated report versions, approving study and work items for the next phase, and confirming the timeline that leads to the Release 21 package in March 2027. The following plenaries are Boston in December 2026 and Rotterdam in March 2027.

What is still open

1,843 of the 17,449 documents were never reached — the agenda ran out before the queue did, which is its own measure of how loaded this round was. Of the rest, 2,827 were agreed and 1,058 approved; the largest categories are "noted" (4,386) and "revised" (4,052), the normal churn of a study phase.

One caution when reading any such tally: "agreed" and "approved" mean different things by group and document type. A pseudo-CR is approved in the working group; a change request is agreed in the group and approved at plenary.

Named open items from the agreed text: whether NAS is used at all over non-3GPP access; IKEv2/IPsec versus QUIC; which AI architecture option is selected; whether the data framework rides the control plane, user plane, or both; how subscriber permission for data collection is enforced; and the granularity of network function services in the service-based architecture.

What to watch next

1. The AI architecture down-selection. Multiple credible proposals, no decision, and the outcome determines whether AI is a domain operators can sell or a feature inside existing functions.
2. IKEv2/IPsec versus QUIC for non-3GPP access — a small choice with large implications for how 6G signalling traverses the internet.
3. Whether the user-plane interface goes service-based or stays on PFCP. This decides how much of the existing UPF ecosystem carries forward.
4. RAN1's move from methodology to design — numerology, SSB design and the 7 GHz link budget.

Sources

All material below is published openly by 3GPP and downloadable from its document server.

Agreed contributions (SA2#176, into TR 23.801-01): S2-2609156 (KI#1.1, NAS/control signalling) · S2-2609034 (KI#1.2, common framework for operator services) · S2-2609214 (KI#2, service-based architecture) · S2-2609210 (KI#3, network slicing) · S2-2609007 (KI#4, user plane) · S2-2609143 (KI#6, policy and charging) · S2-2609017 (KI#9, localized service access) · S2-2608612 (KI#11, non-3GPP access) · S2-2608665 (KI#12, voice) · S2-2609110 (KI#19, network for AI) · S2-2609239 (KI#21, data framework).

RAN1#126 summaries: R1-2606567 (ISAC waveform and frame structure) · R1-2606725 (synchronisation acquisition and beam measurement, 7 GHz coverage) · R1-2606731 (modulation and joint channel coding) · R1-2605589 (ISAC integration with communication).

Meeting document lists (all concluded 27–28 August 2026): SA1#115, SA2#176, SA3#129, SA4#137-e, SA5#168, SA6#74 (Prague) · RAN1#126, RAN2#135, RAN3#133, RAN4#120, RAN5#112 (Maastricht) · CT1#162, CT3#148, CT4#136, CT6#127 (Prague).

Framing and schedule: TR 22.870 (Study on 6G Use Cases and Service Requirements) · TR 38.914 (Study on Scenarios and Requirements for 6G Radio) · ITU-R Recommendation M.2160-0 (November 2023) · the Release 21 timeline decided at TSG#112 (RP-260868, SP-260595, CP-261259, 10 June 2026).

Agreed principles enter TR 23.801-01 and remain subject to change until the study concludes.