Analysis of 3GPP CT #112: Reopening the roaming fault line

Three months ago in Fukuoka, 3GPP TSG CT (Core Network and Terminals) reviewed and approved four 6G study items from the CT1 and CT4 working groups but none from CT3, which is the group that owns the strategically important network exposure work. Fast forward to Singapore earlier this month and all working groups delivered: Six new 6G study items were approved across the three groups, so that CT’s 6G study programme now stands at ten items. However, the meeting also reopened the argument over network and roaming selection, as we shall see.

Disclaimer time again: Interpretation and cross-meeting context are mine, based mainly on the draft report published at the close of the meeting. Errors will inevitably be down to me, so as usual I welcome updates and clarifications. Meanwhile, this is the shape of CT’s 6G study activities across the three working groups:

CT1

• NAS protocol

• the umbrella of miscellaneous functions

• network selection

CT3

• Network capability exposure

• AI protocol

• Interworking with external data networks

CT4

• Control plane

• User plane

• Resilience and reliability

• Data framework

CT1 came to Singapore with two main topics that didn’t make it through the earlier CT#111 meeting: The “umbrella” study bundling several smaller items (Unified Access Control, Public Warning System, and protocols for non-3GPP access to the 6G core) and network selection. Both were approved in Singapore. As to why an umbrella approach was taken, that was to prevent multiple separate study items as these are all relatively lightweight areas.

The network selection technical report received strong scrutiny, and appeared to produce the sharpest exchange of the meeting. The objection came from a broad coalition that included vendors (Ericsson, Apple) and operators (T-Mobile US, AT&T and Vodafone) and was a procedural one. They argued that the base requirements work belongs in Stage 1 of TSG SA and starting in CT1 without those requirements is a “shortcut.”

Network selection in idle mode is not a neutral technical area. So called “steering of roaming” is how operators direct their roaming subscribers onto preferred partner networks and is bound up with roaming agreements, commercial terms and often regulation. Changes to roaming behaviour would have financial implications.

There was eventually a resolution, and it is a great example of consensus building and diplomacy. The approved version links tasks to frozen SA1 Technical Specifications (TS) and in so doing highlights the differences between 3GPP’s specifications and reports. A Technical Report (TR) is an informative study document, whereas a Technical Specification is normative, agreed text. Therefore, through some deft handiwork, the plenary ensured that CT1 cannot invent roaming-affecting requirements on its own initiative and can only study what is traceable to the requirements that SA1 has already committed to in a specification. Got that? There may be a test later...

I said resolution, but it wasn’t fully convincing. None of the five objectors appears among the 23 supporting members of the approved Study Item Description (SID). A reminder of how difficult it is to achieve consensus in 3GPP.

The CT3 working group is tasked with looking at interworking with external networks along with policy and charging control. It saw all three of its study areas approved.

Network Capability Exposure is arguably the most politically significant of the three. Capability exposure is the framework that lets external application functions access the network. This subject has been a recurring flashpoint, and the governance question of who owns the 6G exposure architecture has been unresolved across several TSG SA plenaries. CT3’s study is the Stage 3 protocol counterpart: It will analyse candidate protocols for exposing both network and application-enablement capabilities, with explicit hooks into SA work. There are a lot of upstream dependencies in this study, so expect it to be a little tricky.

The AI protocol study means that CT3 now has its own AI protocol study, and CT1 conducts the AI-adjacent work as deferred tasks inside the NAS and umbrella SIDs. There is an interesting note in the SID, flagging that coordination with the IETF (Internet Engineering Task Force) will be needed for the AI-agent protocol work. That is a meaningful external dependency, indicating that CT expects at least part of the 6G AI-agent protocol stack to be dependent on IETF mechanisms rather than being invented wholly inside 3GPP.

Interworking with external data networks is the quietest of the three and we need to wait for September’s plenary to see how this develops.

The CT4 group added one new study this time, centred on Protocol aspects for Data Framework in the 6G core. The data framework study tracks SA2’s work on efficient, scalable data handling and will start with the data collection and transfer protocol aspects, deferring the rest. It is a complement to the control-plane and exposure work, as 6G’s expected heavy reliance on data-driven and AI-driven functions makes a coherent core-network data framework a foundational necessity.

One small item from CT4’s status report is worth highlighting now. On the User Plane study, the report records that RAN3 is waiting for CT4’s work, and that “CT4 and RAN3 will be synchronised after the study is finalised”, which points to a September 2027 date and not the end of this year (as previously thought). The user-plane protocol decision (whether 6G retains GTP-U, moves to something like SRv6, or splits the difference) sits between the CT and RAN TSGs and should be one of the more consequential architectural choices in the 6G core. A mutual-dependency situation could lead to delays, so needs tracking carefully.

An even smaller CT4 note: There’s a new Technical Specification for a Sensing Function service that has begun attracting contributions, which could be an early Stage 3 placeholder for ISAC (integrated sensing and communication).

CT1 agreed to split the 5GS NAS specification into multiple parts for new Release 20 work. This is housekeeping, but is strategically timed. The specification has grown unwieldy across a decade of releases and modularising it now, before 6G NAS work matures, makes the specification easier to implement and sets up CT1’s drafting architecture for the 6G era.

On Release 21 timing, CT did what was expected. The timeline discussion paper from the TSG Chairs was noted and the revised Work Plan reiterates the framing that now governs the whole 6G standards effort. A reminder that Release 21 is the release submitted to ITU-R for IMT-2030, the ASN.1/OpenAPI freeze is no earlier than March 2029, and Rel-20 time is to be split roughly 50/50 between 5G-Advanced and 6G topics.

The CT TSG now has ten study items that are live, each with its schedule to meet the September 2027 deadlines. The harder questions are now:

Will the TS-anchoring discipline hold? The network-selection compromise is good governance, but several work tasks across the new SIDs can only start on legacy requirements, with their 6G-specific substance reliant on SA1 specifications first being frozen. CT1’s own status report concedes there is still no consensus on when the Stage-2-dependent tasks can even start.

The CT4 / RAN3 user-plane seam. We have shifted from “consult RAN3 by December 2026” to “synchronise after the study is finalised”. This is worth watching, particularly alongside RAN’s deferral of migration decisions at the same Singapore meeting. The user-plane protocol choice cannot be made well by either side in isolation.

CT3’s IETF dependency on AI-agent protocols. A 3GPP working group taking a liaison dependency on the IETF for part of a 6G protocol stack is unusual enough to merit attention. It is an early sign of how much of 6G’s AI layer may be assembled from external partners.