SA2, the 3GPP working group that designs the core-network architecture, met in Prague from 12 to 16 October 2026. Most of its agenda belonged to the 6G architecture study (FS_6G_ARC, documented in TR 23.801-01). A study is the stage in which options are assessed and narrowed before binding specifications are written. Our preview of the October meetings described the open choices. This article records what SA2 actually agreed, based on the close-of-meeting draft report and the end-of-meeting chair notes.

The short version: SA2 did not choose an overall 6G core architecture. It noted a consolidated summary of the three candidate options, ran informal show-of-hands polls, and moved the decision to SA2#178 in Calgary (16–20 November 2026). The deadline for that decision was set by the SA plenary. In parallel, SA2 approved a long list of interim agreements, which are principles written into clause 7 of the study report. These are working agreements that later meetings can still revise, and many of them carry editor's notes marking details as "for further study" (FFS).

A sense of scale: about 1,040 documents were allocated to the 6G study's agenda items. Our count from the draft report is that about 95 were approved and about 870 were marked "not handled", which is normal for a meeting this crowded.

What was not decided: the overall architecture

Three candidate architectures are on the table. They differ mainly in where AI and intent handling sit relative to the functions that provide ordinary connectivity. An intent is a request that states a goal rather than a specific procedure. The rapporteurs' consolidated summary describes them like this:

  • Option 1: a logically separate AI domain next to the connectivity domain of the 6G core.
  • Option 2: AI and intent handling provided by 6G network functions.
  • Option 3: AI agents as a fundamental part of the 6G core architecture.

The summary (S2-2610852, last revised as S2-2611236) was noted, not approved. The report records that the text marked as stable "was considered a good step towards a single architecture, but this will not be progressed further."

On 13 and 15 October, SA2 held show-of-hands polls (S2-2611243). The slides state that the results "are informal and non-binding and do not constitute a 3GPP decision, agreement, or Working Agreement." They still show where companies stand:

  • Should essential connectivity procedures, such as registration, mobility and session management, run without relying on AI inference, tools or AI agents? 46 companies said yes and 7 said no.
  • Should AI be involved in essential connectivity procedures to enable dynamic procedure composition? 16 said yes and 30 said no.
  • Which high-level architecture do you support? Option 1 got 26 yes and 16 no. Option 2 got 28 yes and 19 no. Option 3 got 16 yes and 32 no. Companies could answer for more than one option.
  • Should NAS routing be part of the xAMF or a standalone routing function (SRF)? NAS is the signalling protocol between the phone and the core, and the xAMF is the working name for the 6G access and mobility function. For routing inside the xAMF, 36 said yes and 13 said no. For a standalone SRF, 17 said yes and 24 said no.
  • Should the data framework be an evolution of the 5G data functions or new 6G network functions? For new 6G functions, 40 said yes and 1 said no.

A group of operators (AT&T, Boost Mobile, BT, Deutsche Telekom, EchoStar, NTT DOCOMO, T-Mobile USA, Verizon and Vodafone) proposed writing into the report that essential connectivity must not depend on AI functionality. That proposal (S2-2611234) was postponed to November. The SA plenary's guidance (SP-260999) asks for the overall architecture decision "no later than SA WG2#178". The reply to it was also postponed, so that it can report the outcome in November.

What was agreed: interim principles

Control signalling and NAS (KI#1.1)

The interim conclusion in S2-2611351 was approved. It says that for all 6G-capable phones there is only one NAS protocol stack between the phone and the 6G core. Each phone has one control-plane entry point from the 6G radio network into the core. The 6G system has an xAMF that handles registration, mobility and primary authentication, with exactly one serving xAMF per phone. Whether the xAMF is an evolved 5G AMF or a new 6G AMF is still FFS. NAS routing is agnostic to the payload it carries, and a phone performs a single primary authentication. The text adds that it does not decide which core entity terminates the radio-to-core connection. That question stays tied to the open architecture choice.

Operator services (KI#1.2)

S2-2611394 agrees terminology and general mechanisms for operator services beyond connectivity. These mechanisms are service discovery, capability negotiation, authorization, and transport of the related signalling. Such services include sensing, location or computing. The text explicitly does not settle the NAS design. How the radio-to-core interface carries these services is left to RAN3. SA2 also sent RAN3 a liaison statement (S2-2611388) saying that "no agreement has been made yet" on that interface aspect.

Paging and data buffering for inactive phones

A reply to RAN2 and RAN3 (S2-2611352) says that SA2 considers buffering downlink data in the core network feasible for a phone in RRC inactive state. RRC inactive is a low-power radio state. The alternative is buffering in the radio network, with the radio network triggering core paging. The reply states that "there is no consensus on this variant in SA2" and asks RAN for its view.

Service-based architecture (KI#2)

S2-2611359 keeps network functions as the standardized building blocks. It keeps the 6G NRF (registration and discovery) and the 6G SCP (message routing) as logically separate functions that may be collocated, and it supports both direct and indirect communication between functions. Every function, the SCP included, uses NF sets for resilience. The core must also be able to support stateless functions that keep their context in external storage.

Migration from 5G and interworking (KI#17)

Two texts were approved. S2-2611096 sets the target of migration as 6G standalone (6G SA) with the 6G radio specified by RAN. It says migration paths are based on 5G SA to 6G SA. Any additional paths depend on RAN and SA decisions. S2-2611399 makes single registration the baseline for 5G–6G interworking. A phone is registered with either the 5G or the 6G core at a time, and it has one mobility context over 3GPP access. A combined 5G/6G subscriber database (for example a UDM) is supported, and so is a combined user-plane function where IP-address preservation needs one. Dual-registration interworking remains FFS. A Rakuten proposal on interworking with the 4G core (EPC) was postponed after Huawei raised concerns.

Voice (KI#12)

S2-2611262 agrees that 6G voice reuses the existing IMS architecture and procedures over a guaranteed-bit-rate QoS flow, with 6G acting as the IP access network to IMS. IMS is the IP Multimedia Subsystem used for VoLTE and VoNR today. No new Diameter reference points will be defined between IMS and the 6G core. Voice continuity between 6G and 5G radio relies on keeping the phone's IP address, and the detailed handover procedure belongs to KI#17. Whether to adopt a voice fallback solution at all, and which one, remains FFS (S2-2610981).

QoS (KI#5)

S2-2611396 allows an optional user-plane "collaboration layer". Through it, an application in the phone can get network status from the 6G UPF without frequent control-plane signalling, and application servers can pass traffic characteristics, such as PDU set or burst information, to the UPF. L4S congestion marking (ECN), a mechanism that tells applications about congestion early, carries over from 5G. NAS signalling over this layer is not supported, and the protocol is FFS.

Data framework (KI#21)

S2-2611383 says the 6G data framework "shall be based on 6G NF(s)". It provides control, transfer, processing, storage, exposure, and registration and discovery of data. It must avoid collecting the same data twice from one producer and support large, frequent transfers, and it gives the operator control and visibility over collection and exposure. It enforces subscriber permissions, and the interfaces consumers use are non-roaming. Whether it runs over the control plane, the user plane or both is still open. Most other data-framework texts, including use cases and data transfer mechanisms, were postponed.

AI in the core (KI#18)

Only one AI conclusion passed. S2-2611398 agrees that operator control over the network's use of AI is enforced in the 6G core and through OAM, the operator's management system. The core can authorize or block requests that carry intents, per service or per phone or application function. It supports switching AI capabilities on and off per network function. Proposals on intent handling and on monitoring AI performance were postponed or left open.

Computing, location and other areas

  • Computing (KI#22): S2-2611278 agrees that the 6G system supports coordination of computing and communication when requested by a phone or an application function. It introduces a Computing Coordination Function in the 6G core and/or operator platform, and application traffic reaches the operator-controlled hosting environment only via the 6G UPF. The choice among solution variants is FFS.
  • Location (KI#14): S2-2611390 keeps a GMLC and an LMF in 6G. It standardizes network-induced and mobile-terminated location requests for regulatory services, and it allows commercial use of the mobile-terminated method. Whether the data framework or AI is involved is FFS.
  • Also approved: interim agreements on user-plane architecture (KI#4), policy control (KI#6), network sharing (KI#8), localized services (KI#9), fixed wireless access (KI#10), non-3GPP access (KI#11), 6G NTN (KI#23) and IoT features (KI#24). There were also updates to many solution variants for sensing (KI#20) and computing. After SA3's liaison on secure-by-design principles, the architecture requirements now say that the security requirements of SA3's 6G security study (TR 33.801-01) "should be taken into account" (S2-2611326).
  • Postponed or not agreed: network slicing (KI#3, two competing texts), parts of policy control, capability exposure to AI agents and AI services in the 6G-network-for-AI key issue (KI#19, where only bullets 1 and 2 got interim agreements), most data-framework texts and two liaison replies on the data framework, and an LS on 6G QoS for error-tolerant transmission.

What happens next

SA2#178 meets in Calgary from 16 to 20 November 2026. It has to deliver the overall 6G architecture conclusion that the SA plenary asked for, and to report it to TSG SA#114 in December. The postponed operator principle on AI-free essential connectivity and the NAS routing question (xAMF or SRF) are the items most tied to that decision. The approved texts above go into TR 23.801-01. The meeting report itself is still a draft (v0.0.4) until SA2 approves it at the next meeting.

Sources

SA2#177 draft meeting report v0.0.4 (close-of-meeting draft) and end-of-meeting combined chair notes (16 October 2026, 16:30). The approved texts are quoted from the final revisions linked above, read with tracked deletions removed. Show-of-hands counts come from S2-2611243 and the report, and they are informal polls, not 3GPP decisions. Document counts are our tally of the draft report's agenda items 20.6.0–20.6.24.