RAN3 #131-bis: 6G RAN Architecture and NR ISAC Move Toward June Decisions

RAN3 #131-bis mattered because it narrowed two difficult Release 20 questions: how 6G RAN should interface with the 6G Core, and how NR ISAC should connect the gNB to the Sensing Function. The meeting took place in St Julian’s, Malta, from 13–17 April 2026. RAN3 did not close the biggest architecture decisions, but the group converted several broad debates into text that can be evaluated before RAN#112 in June 2026.

The short version

• RAN3 made progress on the 6G RAN-CN interface, but did not decide P2P vs SBI. The meeting agreed more concrete text for P2P, SBI for connectivity services, HTTP/3-based P2P, and the evaluation criteria for comparing P2P and SBI.

• The 6G Radio architecture study became more structured. RAN3 advanced text on aNB logical nodes, RAN functions, 6G data collection, Higher Layer Split, CP-UP separation, and the Xa interface between aNBs.

• NR ISAC took a clear architectural step. RAN3 captured a direct connection between the gNB and the Sensing Function for sensing control signalling and sensing data delivery, without AMF involvement.

• Measurement Level A is no longer supported for NR ISAC. RAN3 still needs to decide whether Levels B, C, and/or D are supported.

• NR ISAC procedures became more concrete. Sensing Initiation, SF-initiated Sensing Abort, SF-initiated Sensing Modification, and gNB-initiated Sensing Failure Indication were captured. Sensing Modification is now treated as a Class 1 procedure.

• The next meeting matters. RAN3 #132 in Dalian is the last RAN3 meeting before RAN#112 in Singapore, where RAN3 is expected to provide interim 6G study results for higher-level decisions.

Meeting facts

What was RAN3 #131-bis trying to achieve?

RAN3 #131-bis was trying to prepare Release 20 architecture material for decisions that are bigger than one working group. The 6G Radio study expects RAN3 to provide interim results before RAN#112 on the RAN-CN interface and RAN internal interfaces. The RAN-CN interface question is whether the 6G control-plane interface should follow a point-to-point model, a service-based model, or a scoped design that separates connectivity services from future service-specific interactions.

NR ISAC had a different pressure point. RAN1 had already progressed the physical-layer sensing work, while SA2 had progressed system-architecture conclusions. RAN3’s job at #131-bis was to turn that upstream work into RAN-CN architecture, signalling, transport, and procedure assumptions that can fit into TR 38.765 without over-committing unresolved normative choices.

What happened at RAN3 #131-bis?
RAN3 #131-bis moved the 6G RAN architecture and NR ISAC studies from broad option collection toward decision-ready text. The meeting did not close P2P vs SBI for the 6G RAN-CN interface, but it agreed descriptions, protocol-stack options, and evaluation criteria. For NR ISAC, RAN3 captured direct gNB–Sensing Function architecture, dropped measurement Level A, and advanced the main sensing procedures.

Previous Related Post: Previous TSG RAN111 meeting recap

Main technical progress

How did the 6G RAN-CN interface progress?

The 6G RAN-CN interface discussion became more concrete at RAN3 #131-bis. RAN3 did not decide whether the 6G RAN-CN control plane should use a point-to-point interface or a service-based interface. The useful progress was narrower and more practical: RAN3 agreed additional P2P description text, scoped SBI text for connectivity services, an HTTP/3-based P2P stack option, and a focused evaluation framework.

The agreed P2P text in R3-261549 describes a RAN-CN P2P interface as application-layer communication between an aNB and a 6G CN entity by means of elementary procedures. The text also says a point-to-point logical interface is feasible even without a physical direct connection. For connectivity services, the agreed text assumes that an aNB connects with a single type of CN entity, with details subject to SA2.

The HTTP/3-based P2P option in R3-261592 is an important nuance. It means the P2P option is no longer simply “SCTP-like continuation of 5G.” RAN3 is also studying a model where HTTP/3 is logically part of the transport network layer, with RNL messages carried over long-lived HTTP/3 data frames on QUIC streams.

The SBI text in R3-261594 is scoped to connectivity services. The text defines connectivity services as services supported by protocol functions specified in 5GS NGAP for communication between an NG-RAN node and an AMF. For this stage of the SBI study, only direct communication is considered.

The evaluation text in R3-261595 gives RAN3 a more disciplined comparison table. The agreed criteria include deployment, performance, future proofness, standardization effort, interoperability and testing effort, security, operational considerations, and interface robustness. The performance criterion now explicitly includes signalling latency, signalling efficiency, protocol overhead, and processing load.

Did RAN3 #131-bis decide P2P vs SBI for 6G?
No. RAN3 #131-bis did not decide P2P vs SBI for the 6G RAN-CN control-plane interface. The meeting made the comparison more concrete by agreeing text for P2P, SBI, HTTP/3-based P2P, and evaluation criteria focused first on connectivity services.

Why does the 6G RAN-CN interface decision matter?

The 6G RAN-CN interface decision will shape how much of the 5G NG-style procedure model survives into 6G and how much the RAN-CN boundary moves toward a service-based style. A P2P outcome would preserve the RAN3 model of elementary procedures, compact protocol design, and explicit Radio Network Layer and Transport Network Layer separation. An SBI outcome would align more closely with core-network service concepts, but it must still satisfy RAN requirements for latency, robustness, testability, and operational simplicity.

The most useful readout from #131-bis is that the debate is becoming less ideological. P2P now includes SCTP, QUIC, and HTTP/3-based options. SBI is not being studied as a fully general “make everything service based” answer; RAN3 is first scoping the analysis to connectivity services. That shift makes the June discussion more likely to turn on concrete engineering trade-offs.

What changed in the overall 6G RAN architecture?

RAN3 continued to build the 6G RAN architecture vocabulary in TR 38.760-3. R3-261544 captures the 6G RAN as consisting of aNB logical nodes, where an aNB provides 6G user-plane and control-plane protocol terminations toward the UE. The same text says aNB logical nodes may connect with each other by means of the Xa interface and connect to the 6G CN through an aNB–6G CN interface.

R3-261602 adds further structure. It updates “service awareness” to service characteristics awareness, adds MRO alongside ANR and MDT under self-configuration and self-optimization, and lists RAN-hosted functions such as CN node selection for a UE, user-plane and control-plane routing toward CN, connection setup and release, session management, network slicing support, NAS message transfer, RAN sharing, RRM, mobility, and paging.

This is not headline-grabbing text, but it matters. Early 6G architecture work can easily drift into abstract service language. R3-261602 keeps the architecture anchored in concrete RAN functions while still leaving room for service characteristics awareness and future 6G services.

What happened on 6G data collection?

RAN3 agreed to move 6G data collection out of the general-principles section and into a dedicated Data Collection Framework section in TR 38.760-3. R3-261591 says that, as a starting point, 6G data collection supports data collection for RAN3-led AI/ML use cases, while other use cases remain FFS.

The agreed framework captures three important principles. First, reusability of collected data is supported. Second, data collected or generated by an aNB can be used by that aNB and/or made available to other aNBs and/or the 6G OAM system, while additional entities remain FFS. Third, an aNB can request and use data collected from the UE, other aNBs, and/or the OAM system, again with additional entities still FFS.

The practical importance is that RAN3 is separating data collection from data consumption. A 6G AI/ML framework needs to handle who collects data, who stores data, who decodes data, who consumes data, and which security principles apply. Those questions are not identical, especially when UE-originated data, OAM repositories, RAN-led AI/ML use cases, and possible future CN interactions are all in view.

What is the 6G data collection outcome from RAN3 #131-bis?
RAN3 #131-bis created a dedicated 6G Data Collection Framework section and anchored the first phase on RAN3-led AI/ML use cases. RAN3 agreed general principles for data reusability and exchange among aNBs and OAM, while leaving other use cases and additional entities for further study.

How did Higher Layer Split and Xa progress?

Higher Layer Split progressed with a useful guardrail: 6G HLS, if standardized, shall be transparent to the UE. R3-261593 captures benefits of CU-DU separation, including CU centralization and resource pooling, elastic scalability, flexible deployment, and multi-vendor CU/DU selection. The same text starts a separate CP-UP separation discussion by capturing independent scaling and deployment flexibility as benefits.

The Xa interface between aNBs also moved forward. R3-261596 captures control-plane functions including UE mobility management, Xa interface management and error handling for connectivity services, and self-configuration/self-optimization. The user-plane function remains data forwarding.

The Xa result is intentionally conservative. RAN3 captured baseline connectivity functions first and left new-service impacts as FFS. That sequencing is sensible because the RAN-CN decision and the broader 6G service architecture will affect how much service-specific coordination should sit on inter-aNB interfaces.

What changed for NR ISAC architecture?

NR ISAC had the clearest technical outcome of the meeting. R3-261599 captures the direct connection for sensing architecture between the gNB and the Sensing Function, without AMF involvement, for sensing control signalling and sensing data delivery. The same text says the SF selects gNBs for sensing based at least on gNB information including the supported sensing area, and that the gNB decides the TRPs for sensing.

RAN3 also agreed that measurement Level A is not supported. The same TDoc provides a comparison structure for Levels B, C, and D, but those levels remain under discussion. The approved reply LS to SA2 in R3-261541 confirms the same status: RAN3 decided not to support Level A and will continue discussing whether to support Levels B, C, and/or D.

This is a major narrowing of the ISAC design space. Level A corresponds to very low-level raw measurement data. Removing Level A reduces the likelihood that NR ISAC requires extreme raw-data transport between the gNB and the SF in Release 20. The remaining debate over Levels B, C, and D is still important because the selected level set will drive transport, assistance information, gNB processing responsibility, and SF processing responsibility.

What is the biggest NR ISAC outcome from RAN3 #131-bis?
The biggest NR ISAC outcome is that RAN3 captured a direct gNB–Sensing Function architecture without AMF involvement and decided not to support measurement Level A. That removes one high-volume raw-data option from the Release 20 study, while keeping Levels B, C, and D open.

How did NR ISAC procedures and signalling progress?

R3-261600 captures the main sensing procedures for the Nx-AP Sensing Information Transfer function. The agreed procedures are:

• Sensing Initiation: a Class 1 procedure with Sensing Request, Sensing Response, and Sensing Failure.
• SF-initiated Sensing Abort: a Class 2 procedure.
• SF-initiated Sensing Modification: a Class 1 procedure with Sensing Modification Request, Sensing Modification Response, and Sensing Modification Failure.
• gNB-initiated Sensing Failure Indication: a Class 2 procedure.

Sensing Modification is the most useful lifecycle addition. A sensing operation is unlikely to remain fixed after initiation in all deployments. The SF may need to modify an ongoing operation, and the gNB may need to accept, reject, or fail the modification based on radio resources or operational conditions.

The Sensing Request content also became clearer. R3-261600 says the SF sends a Sensing Request including the sensing measurement ID, target sensing area, reporting mode such as one-time or periodic, and optionally transport-layer information for sensing reporting. The supported sensing area and target sensing area share the same representation format, defining a 3D area.

The approved LS to SA2 in R3-261541 is useful because it gives the cross-WG status cleanly. RAN3 told SA2 that supported sensing area can be obtained via OAM and/or signalling, that one-time and periodic sensing data reporting can be supported, and that the Sensing Request needs to include sensing measurement ID, target sensing area, reporting mode, and optional transport network layer endpoint information for sensing data reporting.

What else mattered outside 6G architecture and ISAC?

RAN3 #131-bis also made progress on several non-6G-architecture items. They were not the main story of the meeting, but they are worth tracking.

For Continuous MDT, RAN3 approved a reply LS to SA5 after discussion on whether SA5 wording was aligned with RAN3 expectations around Logged MDT reconfiguration when duration is close to expiry. This was handled as R3-261572.

For PWS over eMTC NTN, the meeting material records agreement to support PWS for eMTC NTN from Release 17, with related CR and LS handling. This is a cross-release alignment item rather than a new architecture topic, but it shows RAN3 continuing to clean up Release 17/18/19 implications while Release 20 studies proceed.

For XR Phase 4, the N3 delay measurement discussion continued. The meeting captured analysis around gNB-initiated DL N3 delay measurement and use of existing DL Sending Time Stamp mechanisms. This looks like progress in analysis and direction rather than a fully closed design.

What did not converge yet?

The open issues from RAN3 #131-bis are just as important as the agreements.

First, RAN3 has not selected P2P or SBI for the 6G RAN-CN control-plane interface. RAN3 agreed descriptions and evaluation criteria, but the final decision remains ahead. The RAN-CN user-plane work also remains on hold pending CT4 input.

Second, RAN3 has not decided whether NR ISAC Nx-AP is NGAP reuse or a new application protocol. R3-261599 captures characteristics and trade-offs for a new AP versus NGAP reuse, but the topic remains FFS and is expected to continue.

Third, RAN3 has not decided the supported NR ISAC measurement level set among Levels B, C, and D. Level A is out, but the remaining levels still need down-selection. That decision will affect transport, assistance information, and the gNB–SF functional split.

Fourth, event-based reporting remains open for NR ISAC. One-time and periodic reporting are supported, but event-based reporting is still tied to the measurement-level decision and further normative discussion.

Fifth, the exact signalling procedure for gNB information remains open. RAN3 agreed that supported sensing area can be provided via OAM and/or signalling, but the exact signalling procedure is not closed.

What should readers watch next?

The next RAN3 meeting to watch is RAN3 #132, 18–22 May 2026, in Dalian, China. That meeting is directly before RAN#112, 8–11 June 2026, in Singapore, where the 6G Radio study expects interim RAN3 input for the RAN-CN and RAN internal interface decisions. RAN3 #133 is scheduled for 24–28 August 2026 in Maastricht, Netherlands.

The most important questions for RAN3 #132 are:

1. Does RAN3 converge on P2P, SBI, or a scoped approach for the 6G RAN-CN control plane?
   The meaningful decision will not be the label alone. The important question is whether the selected model supports connectivity services with low complexity while leaving room for new services.

2. How does RAN3 evaluate P2P and SBI against the agreed criteria?
   The criteria now cover deployment, performance, future proofness, standardization effort, testing, security, operation, and robustness. RAN3 still needs to turn those criteria into a decision-quality comparison.

3. How far does RAN3 take HLS before RAN2 Uu work is settled?
   The UE-transparency principle is useful, but the details of CU-DU and CP-UP split still need coordination with the 6G Uu protocol work.

4. Which NR ISAC measurement levels survive?
   Levels B, C, and D have very different implications for transport and processing. The supported level set will shape the rest of the ISAC RAN-CN design.

5. Does NR ISAC use a new AP or reuse NGAP?
   A new AP may be cleaner for sensing-specific procedures. NGAP reuse may reduce specification count but risks awkward reuse of procedures and IEs designed for a different interface.

Key TDocs referenced

Key terms

Limitations and caveats

This article is a meeting analysis, not an official 3GPP meeting report. Readers should check the final meeting report and later TR versions before treating any item as final specification text.

The RAN3 #131-bis output is still study-stage material for Release 20. Agreed TPs and pCRs can shape TR text, but normative TS work may later narrow, rewrite, or defer details. The article also does not rank company proposals or attribute support to specific companies unless the final TDoc or EoM agenda clearly supports the statement.

The TDoc hyperlinks in this article use official 3GPP meeting-folder ZIP paths rather than exact 3GPP Portal contribution-detail pages. Exact Portal contribution links should be verified manually before publication if the website requires Portal-specific links.

Summary

RAN3 #131-bis was a narrowing meeting. For 6G, RAN3 did not decide P2P vs SBI, but it agreed enough P2P, SBI, HTTP/3-based P2P, and evaluation text to make the next comparison more concrete. For the internal 6G RAN architecture, RAN3 advanced aNB, data collection, HLS, CP-UP separation, and Xa text without prematurely closing new-service details.

For NR ISAC, RAN3 made stronger progress. The meeting captured direct gNB–Sensing Function architecture without AMF involvement, removed measurement Level A from support, clarified one-time and periodic reporting, and advanced sensing initiation, abort, modification, and failure procedures. The next real tests are the Nx-AP decision, Levels B/C/D down-selection, event-based reporting, and the exact gNB information signalling mechanism.

Conclusion

The main takeaway from RAN3 #131-bis is that RAN3 is moving from architecture vocabulary toward decision-ready 6G and ISAC text. The April meeting did not close the biggest choices, but it made those choices harder to postpone: P2P vs SBI for 6G RAN-CN, the shape of 6G internal interfaces, and the transport/procedure model for NR ISAC. I’ll return to these topics after RAN3 #132, because the May meeting should show whether the June 2026 RAN#112 decision point is ready for closure or still too early.

FAQ

What is 3GPP RAN3?

3GPP RAN3 is the RAN working group responsible for RAN architecture and radio-network interface protocols. RAN3 works on interfaces such as RAN-CN, inter-RAN-node, CU-DU, CP-UP, and related application-protocol procedures.

What happened at RAN3 #131-bis?

RAN3 #131-bis advanced Release 20 work on 6G RAN architecture and NR ISAC. The meeting agreed new text on 6G RAN-CN P2P and SBI options, 6G data collection, Higher Layer Split, the Xa interface, and ISAC gNB–Sensing Function architecture and procedures.

Which Release 20 topics progressed most at RAN3 #131-bis?

The most visible Release 20 progress was in 6G Radio RAN3 aspects and NR ISAC. 6G work progressed mainly in TR 38.760-3, while NR ISAC architecture and procedures progressed in TR 38.765.

What are the next steps for the 6G RAN-CN interface?

RAN3 needs to compare P2P and SBI against the agreed evaluation criteria and prepare interim study results for the June 2026 RAN#112 decision point. The key question is whether 6G connectivity services should use a procedure-oriented P2P model, an SBI model, or a scoped design that keeps some service categories separate.

What are the next steps for NR ISAC?

RAN3 needs to decide whether ISAC uses a new AP or reuses NGAP, which measurement levels among B, C, and D are supported, how sensing reports are transported, and whether event-based reporting is supported. Level A is no longer supported, which already narrows the design space.

Links to official 3GPP pages/TDocs:

• 3GPP TR 38.760-3 specification page
• 3GPP TR 38.765 specification page
• 3GPP RAN WG3 meeting folder