3GPP RAN2 #131bis Meeting Summary – Prague, October 2025

Introduction

3GPP RAN WG2 (RAN2) held its 131bis meeting in Prague, Czech Republic, from 13–17 October 2025. Delegates continued the intensive work on finalizing Release-19 RAN2 specifications while also laying groundwork for upcoming 6G studies. The meeting focused on wrapping up outstanding issues in 5G-Advanced features (Release 19) – including AI/ML for the air interface, IoT enhancements, XR (extended reality) optimizations, mobility and power-saving features – and addressed essential maintenance of earlier releases. The group also discussed initial 6G (Release 20) considerations, guided by a new RAN-endorsed principle to keep 6G standards lean and streamlined (RP-250766). Throughout the week, RAN2 achieved consensus on numerous technical decisions and approved a range of contribution documents and change requests (CRs), ensuring traceability by linking each decision to its source documentation.

Release 18 and Earlier Maintenance

RAN2 reaffirmed the policy that only critical and essential corrections for Release 18 and prior releases are accepted at this stage. Minor editorial and clarifying fixes were handled offline with specification rapporteurs, whereas any significant corrections were brought as formal CRs. For example, a clarification to LTE RRC addressing SSB-less secondary cell handling was approved via a Rel-15 CR from Ericsson R2-2507595. Overall, the meeting devoted minimal time to legacy releases, allowing the agenda to concentrate on Release-19 feature work. (Notably, the Release Independent Issues (RIL) list was reviewed: one issue on logged data retention (H002) was closed with no spec changes, relying on implementation for handling in LTM scenarios, and two pending issues (S050, Z007) were deferred for resolution after this meeting.)

Release 19 Feature Updates

AI/ML for NR Air Interface (Rel-19)

The AI/ML for NR Air Interface feature – which introduces protocol support for machine learning in RAN (e.g. data collection for model training and inference) – saw significant progress. RAN2 approved a set of CRs finalizing the RRC and L3 aspects of this feature. For instance, a Huawei CR to TS 37.320 was endorsed, resolving all known issues in the Stage-3 definition of the feature R2-2507420. Similarly, a Qualcomm-led CR for LPP (location protocol) enhancements to support AI/ML-based positioning was reviewed and will be incorporated pending ASN.1 update R2-2507412. The group also addressed a contentious point from the previous meeting regarding On-Demand PRS (Positioning Reference Signal) transmission: an earlier Stage-2 description suggesting UE-initiated PRS requests was removed for clarity, per an agreed correction to TS 38.305 R2-2506780.

One notable outcome in this area was the decision not to introduce a new UE capability flag for large model logging memory. After debating whether UEs should signal support for increased logging buffer sizes (for network-data collection), the consensus was that it’s unnecessary for Rel-19. The existing implicit assumptions suffice, so no additional RRC signaling will be added. The corresponding draft CR proposing a UE capability IE was endorsed with that understanding R2-2507588 (i.e. it will not include a memory size indicator).

RAN2 also approved a liaison statement to SA2 to clarify the split of responsibilities between RAN and core network for AI/ML data collection. In this LS, RAN2 informs SA2 that certain issues (such as UE data collection mechanisms and any related UE radio capabilities or consent requirements) will be studied within RAN2 in Rel-20, and encourages SA2 to continue its work in parallel with this understanding. The LS was finalized as R2-2507928 and dispatched to SA2 R2-2507928. This coordination ensures that SA2’s architecture work on AI/ML (for example, network data analytics) proceeds with awareness of RAN2’s plans in the next release. Overall, with multiple contributions resolved and CRs approved, the AI/ML air interface feature is nearing completion for Rel-19.

Ambient IoT (Rel-19)

For the Ambient IoT initiative – which enables low-power tag communication in NR – RAN2 addressed the remaining open issues and aligned with other groups on key parameters. One major topic was the length of the Ambient IoT device identifier. RAN2 concluded that it is technically feasible to extend the device’s permanent ID to 256 bits or even 496 bits as proposed by SA2, from an RRC signaling perspective R2-2507347R2-2507101. However, the final choice of ID size will be left to SA2 – RAN2 agreed to wait for SA2’s conclusion on the ID length and will then adjust the paging ID field accordingly. (Notably, the discussion indicated that if a 496-bit ID is adopted, a 10-bit length indicator would be needed to support ~600-bit paging IDs, which RAN2 can accommodate.)

Another outcome was determining the maximum payload sizes for NAS (core network) messages carried over the Ambient IoT air interface. RAN2 approved values for the NAS container lengths, deciding that the maximum supported size is 119 bytes in the reader-to-device (R2D) direction and 123 bytes in the device-to-reader (D2R) direction. These figures will be communicated to CT1 for inclusion on the NAS side. The agreement was based on analyses from companies like vivo and Xiaomi that considered various overheads and coding rates R2-2506962R2-2507557. Additionally, the corresponding maximum transport block sizes for Ambient IoT were confirmed (approximately 952 bits uplink, 991 bits downlink) to ensure RAN and NAS parameters are consistent. These decisions will allow CT1 to finalize the data encoding and interface aspects with full knowledge of RAN2’s limits.

A significant debate in Ambient IoT concerned the 128-bit security parameter to authenticate paging messages for tags. SA3 had mandated that UEs must support this parameter, effectively requiring its presence in paging. RAN2 considered proposals on whether this field should always be transmitted or could be optional. Ultimately, the working group had concerns about mandating the 128-bit field in every paging message – citing downsides such as unnecessary overhead for cases where it’s not needed, increased device complexity and power consumption, and coverage impact if tags must always handle the extra bits. Therefore, RAN2 decided on a two-fold approach:

• Include an optional presence bit in RRC for the security parameter field. In the Rel-19 specification, this bit will be set to “present” by default (maintaining alignment with SA3’s current requirement), but the design allows the field to be omitted in future if not required.
• Seek guidance from SA3 via an LS on whether this security field truly needs to be included in every paging message. The liaison asks SA3 to confirm if making the field optional is acceptable and to consider the outlined concerns. RAN2 approved this LS (document number R2-2507920) and sent it to SA3 (copied to CT1), along with details of RAN2’s discussion points R2-2506902R2-2506915. The message highlights that while supporting the security parameter is feasible, RAN2 sees merit in an optional approach to avoid overhead in scenarios where the added security is not critical. Depending on SA3’s response, RAN2 is prepared to adjust the specification (e.g., permit the bit to be set to “absent” in a future release if agreed).

With these decisions, the Ambient IoT feature has answered its last open questions. RAN2 also confirmed how to handle edge cases like scenarios where the NAS layer provides no response to a reader’s data request (e.g., due to an integrity failure or simply no data available). The group agreed it is valid that sometimes the network will receive no data at all from the device (in addition to the “delayed response” case already considered). For non-security-related cases, the access stratum will indicate to the reader that no NAS response is expected (details of the indication are left for further study). In cases of NAS integrity check failure, RAN2 assumes no response is sent, and it has asked SA3 (in a second Ambient IoT LS) whether a specific indication is needed for this scenario. These clarifications ensure a consistent understanding across RAN2, SA3, and CT1 for robust Ambient IoT operation. Overall, with ID handling, message sizes, and security aspects ironed out, Ambient IoT is moving toward closure in RAN2.

Low-Power Wake-Up Signal (LP-WUS) for NR

The NR Low-Power Wake-Up Signal (WUS) feature – which introduces a wake-up receiver mechanism to dramatically reduce device power consumption during idle mode – had a large number of contributions at RAN2#131bis, reflecting the complexity of integrating WUS with existing RRC idle/inactive procedures. The working group tackled the remaining MAC and RRC protocol issues to ensure LP-WUS operates seamlessly. Notably, an Ericsson-led discussion identified and resolved a critical MAC-layer issue where multiple proposals converged on a common solution R2-2507627. This resolved ambiguity in how the wake-up signal is scheduled and acknowledged, which had been pending from earlier meetings. Likewise, several companies (OPPO, Apple, Nokia, Qualcomm, ZTE, and others) contributed on how the WUS functions while the UE is in RRC_CONNECTED – for example, how paging monitoring is handled in connected mode with a wake-up receiver active. The agreed outcomes ensure that when a device is in active mode, the network can still benefit from WUS mechanisms without missing important pages.

On the RRC side, RAN2 endorsed a new UE capability to signal support and configuration parameters for LP-WUS. A draft CR from Huawei was discussed and finalized, adding the necessary information elements in the UE capability signaling (in TS 38.306) R2-2507253. This allows the network to know whether a device supports wake-up receiver and to configure its WUS parameters appropriately. Additionally, numerous editorial and consistency fixes were made to the RRC specification (38.331) to align with the introduction of WUS. For instance, interactions between WUS and legacy DRX/paging were clarified – RAN2 agreed on how WUS coexists with features like paging occasion bundling and extended DRX cycles, ensuring that a UE can be woken up reliably for paging while avoiding unnecessary wake-ups. An open issue on co-configuration of WUS with paging occasions (related to RIL S050) was deferred, but discussion indicated possible solutions to be finalized next meeting. The net result is that the LP-WUS feature now has a well-defined protocol behavior in both idle and connected modes. With critical design issues addressed and the spec updates in place, LP-WUS is nearly ready, pending only minor outstanding items that will be monitored (e.g., final ASN.1 alignment and any residual issues to be handled via rapporteur). This feature is expected to significantly improve device battery life for IoT and other power-sensitive use cases in NR.

Network Energy Saving Enhancements (Rel-19)

Network Energy Savings (NES) is a suite of Release-19 features aimed at reducing energy consumption in the RAN (both network and UE side) through techniques like on-demand broadcast and adaptive idle-mode behavior. At RAN2#131bis, the group closed out all remaining issues for NES. Multiple companies provided reports and proposals consolidating earlier email discussions on open points – for example, InterDigital and Huawei shared summary documents capturing offline agreements, which helped focus the meeting discussion. Ultimately, RAN2 was able to agree on a comprehensive CR covering the RRC layer updates for NES, contributed by Ericsson R2-2507663. This CR incorporates miscellaneous corrections and enhancements to ensure features like on-demand SSB (synchronization signal block) transmission, adaptive paging, and idle mode UE behavior function as intended. It was approved with full consensus, marking the completion of RAN2’s spec work for network energy saving improvements.

The agreed CR was accompanied by an “NES conclusions” document from the feature’s rapporteur R2-2507662, which details how each outstanding issue or RAN2 Issue List (RIL) item was resolved. For instance, one debated topic was the handling of On-Demand SSB: RAN2 confirmed the conditions under which a gNB can truncate SSB transmissions during low-traffic periods and how the UE is informed or can request an SSB burst when needed. Any parameters impacting this (like timers or thresholds) were aligned with RAN1’s physical layer decisions. Similarly, RAN2 finalized how reduced-capability (RedCap) UEs and idle-mode UEs handle system information in on-demand broadcast scenarios – an OPPO contribution on OD-SIB1 (on-demand SystemInformationBlock1) and paging adaptation was agreed, ensuring that when system information is not being broadcast continuously, UEs can still obtain it on demand without missing critical configuration R2-2506849. Another set of issues related to UE capability signaling for NES were addressed: ZTE and partners provided a CR to 38.306 that was approved, making sure that if a UE has limitations or special support for energy saving features, it can advertise those to the network R2-2507368.

In summary, the Network Energy Saving work item is now fully specified in RAN2. All needed protocol hooks (in RRC, MAC, etc.) for features like cell dormancy, on-demand broadcast, and UE energy efficiency are in place. The agreed CRs will be forwarded for approval at TSG-RAN. With RAN2’s part done, the focus shifts to RAN4 (for any remaining performance evaluations) and to wrapping up cross-WG coordination (liaisons were exchanged to ensure, for example, SA5 and RAN3 are aware of the changes for minimization of drive test and SON impacts). RAN2 thanked the NES rapporteurs and editors for their extensive offline preparation that enabled a smooth closure of this item within the meeting’s tight timeframe.

Mobility Enhancements Phase 4 (Rel-19)

Mobility Enhancements Phase 4 is a RAN2-led effort in Rel-19 to further refine NR handover, cell reselection, and mobility robustness, including aspects like conditional handover improvements and inactive state mobility. By the end of RAN2#131bis, this work item reached a milestone: the working group agreed on all pending RRC changes and concluded the associated issue list. Ericsson, acting as rapporteur, submitted a “mobility RIL conclusions” report summarizing the final resolutions R2-2507403. Key outcomes were then captured in an approved CR to the RRC spec (38.331) that implements the decided solutions R2-2507404. This CR addresses various topics: for example, it refines how a UE reports measurement results and how the network configures measurement objects to better handle rapid link quality fluctuations (important for high-speed mobility and cell edge scenarios). It also includes improvements to conditional handover (CHO) signaling, making the behavior more robust if conditions change or if a target cell becomes unavailable.

One specific issue that had drawn attention was the handling of LTM cell switch scenarios. (LTM refers to a feature introduced for Logged Minimization of Drive Tests, where a UE can switch a “Last Transmission” to a better cell for data logging purposes.) There was a known problem [E005] about how radio bearers are managed when a UE performs this special cell switch. A multi-company contribution (Ericsson, MediaTek, Samsung, Huawei, ZTE, etc.) proposed a solution, which was revised during the meeting and agreed (finalized in document R2-2507659). The agreed behavior ensures that when a UE switches cells purely to complete logged measurements (without a full handover), the integrity of ongoing data and bearers is maintained without unnecessary releases or resets. This fix will improve network efficiency in MDT use cases and was a welcome resolution to a long-standing RAN2 issue.

Another area cleaned up in Mobility Phase 4 was the interworking of inactive state (RRC Inactive) mobility with various features. For instance, Lenovo raised an issue [B110/B111/M202] regarding how CSI (channel state information) reporting configurations persist (or not) after a cell change in inactive state. That, along with similar minor issues, was addressed so that when a UE in RRC Inactive moves to a new cell (possibly via RAN paging or small cell change), the network knows which configurations to reset or reconfigure. Xiaomi and Samsung also brought in discussions on specific RIL items (labeled S036, S037, etc.), all of which reached closure by meeting’s end.

Finally, as mentioned earlier, RAN2 noted that no additional specification change will be made for the LTM logged data retention issue (H002) – the solution agreed in a prior meeting (allowing network implementations to decide how long to keep logged data when a UE moves) was deemed sufficient, and no explicit signaling or timers will be added. This was formally recorded, closing H002. Two remaining general mobility RIL items (S050 concerning LP-WUS co-scheduling, and Z007 on another aspect) were left open, but they are slated to be resolved after this meeting (likely via offline discussion or at RAN2#132). With that, Mobility Enhancements Phase 4 is essentially completed: the specifications will incorporate the agreed CR, and any residual tweaks will be handled as part of final cleanup.

XR (Extended Reality) Enhancements Phase 3

RAN2 leads the XR Enhancements Phase 3 work, which focuses on improving NR for AR/VR and other low-latency, high-throughput use cases. During meeting #131bis, a multitude of XR-related contributions were discussed, addressing everything from RLC retransmission strategies to PDCP status reporting for delay-sensitive traffic. The good news is that the core RRC updates for XR are now in place. Huawei and HiSilicon had provided a CR to 38.331 covering needed RRC changes (e.g. new configuration parameters for XR traffic handling, refinements to timers for buffering during XR scene changes, etc.), and this CR was progressed and agreed in principle R2-2507054. After addressing some late comments, the XR RRC CR will be formally approved (likely at the next meeting) but no further technical changes are anticipated. This ensures the RRC layer can support XR Phase 3 features such as enhanced multi-panel beam tracking and XR session continuity in dual connectivity.

On the RLC/MAC front, companies had identified various inefficiencies that could impact XR. For example, vivo submitted a CR to the RLC specification (TS 38.322) to optimize how RLC status reports handle out-of-order PDCP PDUs in certain XR scenarios R2-2507016. This CR was approved, eliminating a potential excess retransmission issue and thereby reducing latency for re-sending lost packets. Another discussion (led by vivo and others) looked at preventing unnecessary retransmissions – e.g., if an XR video frame becomes irrelevant (missed display deadline), those packets should be flushed rather than persisted in RLC. While such specifics border on implementation, RAN2 agreed on guidance and ensured that the spec does not forbid intelligent dropping in these cases. Samsung and ZTE also contributed corrections on MAC scheduling for XR: ensuring, for instance, that the MAC could signal an “end of XR burst” to allow the UE to quickly release resources or switch modes. These were handled as part of general MAC fixes in other WIs but directly benefit XR use cases.

A significant portion of time was spent reviewing an XR comment file and offline issue list compiled by the XR rapporteur (Nokia). The issues ranged from details of how the network signals supported XR modalities to the question of logging QoS metrics for XR flows. One important agreement was on the definition of a non-delay-critical PDCP SDU for XR – Fujitsu had raised a point about clearly marking which data in a mixed XR stream could be delivered with relaxed delay (for example, telemetry vs. real-time video) R2-2506964. RAN2 agreed on clarifications in the specs to handle that distinction.

By meeting’s end, the XR Phase 3 work item had no open technical issues requiring further discussion. The agreed improvements (some incorporated now, others to be formally approved at RAN2#132) collectively reduce latency and improve reliability for XR applications. With these, NR can better support use cases like wireless AR glasses and VR streaming, by minimizing stalling and ensuring smooth handovers even during intense data sessions. RAN2 will continue to monitor XR performance, but Phase 3 appears on track for completion. Any additional ideas (e.g., new XR codec-specific signaling) will likely be part of future study items beyond Rel-19.

IoT over Non-Terrestrial Networks (NTN) – Release 19

IoT-NTN Phase 3 addresses enhancements to support NB-IoT and NR-Light (RedCap) devices over satellite (NTN) in Rel-19. As the lead group for NB-IoT RRC, RAN2 made solid progress in this area in Prague. OPPO and others presented contributions on optimizing paging for “store-and-forward” satellite operation – a scenario where an NTN satellite only intermittently contacts ground UEs. An agreed outcome was to introduce an extended paging cycle and an indication in RRC for when the next paging occasion will occur, so that IoT devices can remain in deep sleep appropriately. For example, one proposal to add a new paging frame offset for NTN was accepted in principle R2-2507061, contingent on final RAN1 parameters. This will help UEs align with satellite pass opportunities and reduce missed pages.

RAN2 also discussed various RIL items and corner cases for IoT-NTN. Google contributed an analysis of RRC issues (like handling TAU – Tracking Area Update – over satellite, and cell reselection when a satellite beam changes) R2-2507650. While some items were left for Rel-20 consideration, the group resolved what was needed for Rel-19 functionality. A coordination liaison from RAN1#122 was noted, which provided physical layer context (e.g., timing advance and frequency error budgets for NB-IoT in NTN). Using that, RAN2 ensured no conflicting assumptions in RRC.

With respect to IoT-NTN TDD mode (a parallel WID led by RAN1 for NB-IoT on GEO satellites with a TDD frame structure), RAN2 reviewed a few incoming liaison statements. Nokia’s contribution on remaining TDD mode issues R2-2507612 indicated that most impact is on RAN1/RAN4, with RAN2 mainly needing to accommodate longer timing uncertainties in RRC messaging. RAN2 agreed to add a normative note that RRC connection setup timers for NB-IoT may be extended when operating via GEO satellites to account for propagation delay. No objections were raised to this approach. Therefore, the Rel-19 IoT-NTN support is essentially set: NB-IoT devices will gain the necessary protocol tweaks to reliably function over LEO/GEO satellite links for both FDD (store-and-forward) and TDD setups. This paves the way for global IoT coverage using satellites, with minimal changes on the device side.

(It’s worth noting that while Rel-19 focuses on non-voice IoT-NTN, initial discussions on voice over NB-IoT-NTN have begun as a Rel-20 study. RAN2 received several forward-looking contributions on how IMS voice calls could be supported for NB-IoT via satellite, comparing control-plane vs. user-plane solutions. These were not within Rel-19 scope, but RAN2 captured the considerations and will pursue them in the Release 20 timeframe. The work will likely involve SA2 and RAN3 as well, to define architecture and handover for voice over NTN.)

Sidelink Relay Multi-Hop (Rel-19)

In Release 19, RAN2 is also responsible for NR Sidelink Relay enhancements, specifically enabling multi-hop relay at the protocol level. This feature allows a chain of devices to forward sidelink communications, extending the range of vehicle-to-everything (V2X) or public safety networks. At the Prague meeting, all pending control-plane issues for multi-hop relay were resolved. Apple and CATT submitted a CR to refine the RRC configuration for PC5 relay, addressing an omission in how a remote UE configures its RLC channels when acting as a relay node R2-2507097. This CR was approved, ensuring that the specifications now include the necessary parameters for setting up and releasing relay links in an automated fashion.

LG Electronics contributed on the handling of system information by remote UEs in a multi-hop scenario. One specific correction agreed was to ensure a remote UE can receive essential SI (System Information) from the relay even if it’s beyond the coverage of the base station. LG’s CR to address SI reception over two-hop was accepted R2-2507213, introducing a mechanism where a relay can broadcast or forward critical SI (like scheduling info or PLMN IDs) to UEs that are only connected via the relay. This is crucial for scenarios like search-and-rescue, where a chain of devices might extend coverage into areas with no direct network signal.

Additionally, InterDigital and others discussed remaining MAC-layer open issues (e.g., how UE IDs are handled in multi-hop forwarding to avoid confusion or ID collision). Those were minor and resulted in agreed textual clarifications rather than new procedures. The outcome is that the sidelink multi-hop relay feature is practically complete in RAN2’s domain: UEs will be able to establish a relay link (with one UE as “remote” and another as “relay”) and even support a second hop if configured, all with proper RRC signaling support. MAC and PDCP aspects were also aligned (with RAN1 and RAN3 input) to ensure the forwarding behaves transparently to upper layers. This feature will enhance direct communication use cases, enabling devices to reach the network or other devices when direct connection isn’t possible, by hopping through intermediate nodes.

Other Release 19 Items and Corrections

Beyond the major items above, RAN2 also dealt with a variety of miscellaneous Rel-19 features, most of which are led by other WGs but require RAN2 specification support. These were generally in good shape, with only minor corrections handled at this meeting:

• Evolution of NR Duplex (Sub-band Full Duplex): RAN2 received liaison inputs from RAN1 on the initial study of sub-band full duplex. The RAN2 impact is limited (primarily ensuring that RRC can configure any new duplex modes). RAN2 noted the information and flagged that no protocol changes are needed yet beyond what’s already in the generic framework. Any new configuration parameters for duplex (if introduced in later release) will be handled when the study matures. For Rel-19, an agreement was reached that existing signaling (TDD/FDD indicators) suffice for the current scope, so no new RRC IE was added.
• NR MIMO Phase 5: This RAN1-led item had some late input to RAN2 regarding beam reporting and CSI feedback enhancements. RAN2 approved a minor CR aligning TS 38.331’s description of CSI reporting with the new CSI-RS resource settings defined by RAN1. No functional change – just keeping the RRC spec consistent. The CR also fixed a dependency in measurement reporting when multiple panel calibration is used, which is part of MIMO Phase 5.
• NR UE Power Saving (Release 18 follow-ups): A correction on handling SSB-less SCell scenarios (where a secondary cell may not transmit SS blocks to save power) was agreed and backported to Rel-15/16/17 where applicable. This was captured in a cross-release CR mentioned earlier. It ensures the UE is not required to monitor a non-existent SSB and that network signaling clearly indicates when a cell has no SSB for power saving reasons.
• NR up to 71 GHz (FR2 extension): Although primarily RAN4, RAN2 needed to adjust some RRC values to support new mmWave bands up to 71 GHz. RAN2 approved the necessary update: extending the allowed frequency range in relevant IEs. For example, a Huawei CR updated the SCS (subcarrier spacing) tables and frequency range limits in the RRC spec, ensuring bands above 52.6 GHz can be correctly represented R2-2507006. This was a straightforward change and aligns RAN2 with RAN4’s introduction of new FR2 bands.
• LTE-NR Coexistence and Others: A few leftover items like LTE-based 5G broadcast (LTE terrestrial broadcast Phase 2) and NavIC L1/BDS B2b A-GNSS support were on the agenda. These saw no controversies – RAN2 noted that the LTE-NR broadcast work (led by RAN1) did not require changes in RRC beyond what was already decided (e.g., an LS from RAN1 earlier had been addressed in RAN2). For NavIC and BDS (new GNSS constellations for assisted GPS), RAN2 had already approved CRs in previous meetings adding the new GNSS IDs in RRC assistance data. In #131bis, the focus was on confirming no further changes; indeed, the support was considered complete and ready for Rel-19.

In summary, all Rel-19 features are nearly wrapped up in RAN2. Each feature has its set of CRs approved or in final review, linking every decision to a concrete spec change.

Liaison Exchanges and Cross-WG Coordination

RAN2#131bis was characterized by close coordination with other working groups, given the broad scope of Rel-19. The group handled and generated numerous liaison statements (LS) during the week:

• Liaison in from RAN Plenary: The group took note of guidance from the RAN plenary meeting. In particular, the Working Principle for 6G endorsed at TSG-RAN was highlighted at the start of the meeting (RP-250766). This principle calls for leaner and more streamlined standards for 6G – avoiding unnecessary complexity and options – which RAN2 will keep in mind as it begins 6G studies. Additionally, RAN2 was informed of a RAN plenary decision (RP-252909) that steers 6G architecture work: it specifies that RAN2 should focus on standalone 6G architecture mobility until at least TSG#113 (Sep 2026), when a decision on any 6G dual-connectivity options (e.g., 6G-6G or 5G-6G DC) is expected. Thus, RAN2 acknowledged it will hold off on 6G dual connectivity discussions until RAN and RAN1 provide further direction, and concentrate on baseline mobility for standalone 6G cells in the interim.
• LS from RAN1 and RAN3: Many Release-19 features are multi-WG, so RAN2 received incoming LS’s conveying RAN1’s latest decisions. For instance, after RAN1#122, an LS was sent listing higher-layer parameters for various Rel-19 features (NR_MIMO_Ph5, NR_duplex_evo, NR_LPWUS, NR_Mob_Ph4, etc.) that require RAN2’s attention R2-2506720. RAN2 noted all such inputs and integrated them into its discussions (many are mentioned in the sections above). Similarly, RAN3 provided LS’s on topics like SON/MDT Phase 4 and eNB/gNB coordination impacts – RAN2 reviewed these and made sure the RRC changes align with RAN3’s needs (e.g., RAN2 included the necessary hooks for RAN3-driven features such as conditional HO reporting and network energy saving coordination). All incoming liaison statements were noted or discussed as appropriate, and any questions or feedback were addressed via outgoing responses.
• LS to SA groups and CT: We have already described the major liaison statements RAN2 approved to SA2 (on AI/ML data collection responsibilities) and to SA3 (on the Ambient IoT security parameter and integrity failure cases). In addition, RAN2 prepared a reply LS to CT1 regarding UE usage of RAT restriction parameters R2-2506705. CT1 had inquired how the network signals RAT restrictions to UEs in certain dual-registration scenarios; RAN2 confirmed the RRC mechanisms and clarified a point in the spec to resolve CT1’s query. This collaborative exchange will ensure consistency between RAN2’s RRC spec and the core-network procedures for subscription-based RAT restrictions (so that if a UE is restricted from using NR in certain areas, both NAS and AS handle it coherently).
• LS to RAN4: One liaison of note was an LS to RAN4 regarding power saving signal issues. RAN4 had observed a potential issue in RRC signaling for power domain enhancements (related to how the network indicates certain power boosting on PUCCH/PUSCH). RAN2 considered RAN4’s input R2-2506730 and responded by adjusting the RRC wording to accommodate the new power domain concept. This was done via a coordinated CR and an acknowledgment LS.

Procedurally, RAN2 also discussed planning for the next meetings given the increasing 6G workload. The chair announced that no parallel RAN2 sessions are planned in 2026 for 6G work – all discussions will occur in the main plenary sessions to foster cross-topic consensus (this was in line with guidance from TSG). RAN2 will, however, likely subdivide agenda items further (more sub-items) as the scope grows, but delegates were assured the work would remain manageable without needing to split into parallel tracks next year.

Initial 6G Study Discussions

Although Release 20 (6G) work is mostly at the study item stage, RAN2#131bis did touch on a few 6G-related topics, setting the stage for more intensive work in upcoming meetings. The overarching theme, as noted, is to respect the lean standardization principle. Concretely, RAN2 agreed to avoid prematurely specifying solutions for not-yet-agreed 6G architectures. For example, some companies raised ideas about potential 6G dual connectivity or multi-RAT interworking. However, as guided by RAN Plenary (RP-252909), RAN2 will not jump into defining 6G dual connectivity until the overall 6G architecture options are clarified by the plenary around late 2026. This means RAN2’s initial focus in Rel-20 will be on the baseline standalone 6G RAN – essentially a clean new RAN where mobility, session management, etc., are handled without relying on 5G anchor cells.

There was a short exchange regarding 6G UE data collection and analytics (the continuation of AI/ML for air interface into 6G). Many participants see a need for RAN2 to specify more advanced UE-side data collection and maybe even closed-loop AI control in 6G. RAN2’s LS to SA2 (described earlier) already indicates that RAN2 will pursue those aspects in Rel-20. So this meeting laid the groundwork by identifying what topics to consider. For instance, RAN2 will study if 6G requires new types of UE measurements (perhaps related to AI model performance) or new privacy controls for such data. No decisions were made yet, but delegates are now aware that a Rel-20 study item on AI/ML enhancements in RAN is likely (indeed, TSG RAN has since approved a study item on “AI/ML for NR air interface Phase 2” as per RP-252966, which RAN2 will execute). RAN2 is aligning with SA5 as well, to understand what telemetry or KPI collection might be needed on the network side for AI – an SA5 liaison (S5-254083) on network data collection for AI/ML was noted, and RAN2 will consider it when defining the 6G scope.

Security is another 6G area RAN2 touched upon. As new 6G use cases may blur the line between RAN and core (e.g., RAN-level machine learning models, or RAN orchestrating edge services), security requirements need to be understood early. RAN2 drafted an LS to SA3 seeking input on what security measures might be required if RAN2 introduces any new control mechanisms in Layer 2 or RRC for 6G. For example, if RAN2 defines an L2 signaling for controlling AI model updates or for integrated sensing information, should those be encrypted or authenticated, and by whom? The LS (proposed by Vodafone and approved as R2-2507915) asks SA3 to start considering these and to advise on principles (e.g., “if such L2 control info exists, it should be treated as user data or as RRC messages?”). This early dialogue with SA3 will help ensure security isn’t an afterthought in 6G design.

Finally, RAN2 noted that as 6G studies ramp up, it will coordinate closely with RAN1 and RAN3 to partition the work. Some delegates (e.g., Samsung) even suggested that for topics like 6G dual-connectivity and migration from 5G, RAN2 could conceptually start earlier than 2026, but the consensus is to honor the plenary’s staged approach. In practical terms, RAN2 will spend the next few meetings completing Rel-19 and then shift to Rel-20 study mode. The agenda structure will evolve: hints were given that more “Post-Rel-19” agenda items (prefix “9.x” etc.) will appear, covering things like initial 6G RRC design requirements, possibly new study items on topics such as Integrated Sensing and Communication (ISAC), which one contribution briefly mentioned in the context of NTN coexistence.

6G Mobility (Rel-20 study)

RAN2 scoped 6G mobility standalone-first until the plenary revisits migration/DC at TSG#113 (Sep-2026), so near-term work centers on a single, streamlined framework rather than parallel schemes (R2-2506899). The baseline set spans L3 immediate HO and CHO; the group discussed where RACH-less fits and what, if anything, (C)LT M-like ideas add. Targets are short interruption with high robustness and early DL/UL sync built in (R2-2507075, R2-2507385). To avoid the 5G split across SSB/CSI-RS and L1/L3, RAN2 set a unified measurement configuration as a study goal (R2-2507135).

For idle/inactive mobility, NR’s reselection model is the baseline, while slice-aware reselection and “hyper/super-cell” ideas are on the table (R2-2507217, R2-2507143, R2-2506885). NTN mobility is explicitly in scope (inter-beam/cell/satellite, TN↔NTN, multi-orbit cues, and potential 6G-DC between TN/NTN accesses) (R2-2507647, R2-2506776). Complexity guardrails were called out (e.g., mTRP/super-cell notions only where they deliver measurable gains) (R2-2507169, R2-2506858). Agreed study requirements captured by the chair include minimizing interruption while maintaining throughput, improving robustness, and considering UE/network energy efficiency; study threads include early DL/UL synchronization, pre-configurations, CHO and early-CSI acquisition (R2-2507075, R2-2507385, R2-2506899). 

Conclusion and Next Steps

RAN2#131bis in Prague successfully achieved its goals – virtually all Rel-19 work items have been finalized or put on a clear path to completion, with decisions explicitly tied to their source documents for full traceability. By inserting references to contributions (R2- documents) and RAN liaison documents (RP- documents) in the meeting report (and in this summary), the working group has improved transparency: any technical agreement can be traced back to the contribution or CR that underpinned it. This will greatly help editors and delegates in verifying changes as we move into final document editing and approval cycles.

Looking ahead, RAN2#132 (Dallas, November 2025) will be the last RAN2 meeting before the expected Release-19 Stage 3 freeze milestone. It will focus on formally approving any remaining CRs (many of which were agreed in principle this meeting) and resolving any last-minute issues that might emerge during final spec scrubbing or ASN.1 verification. The output of RAN2#132 will feed into TSG RAN#112 in December for final approval of Rel-19 features. At the same time, RAN2#132 will start dedicating more agenda time to Release 20 study items – we anticipate initial discussions on 6G RRC architecture, advanced AI/ML in RAN, and possibly new study items like Integrated Sensing or 6G NTN evolution.

In conclusion, the Prague RAN2 interim meeting was highly productive: it solidified the protocol foundations of 5G-Advanced and poised the group to transition into the 6G era. The collaborative spirit was evident as cross-company agreements were forged on complex issues, each backed by concrete documents (contributions and CRs) now part of the official record. As always, the RAN2 leadership reminded delegates of the importance of consensus and the 3GPP ethos – decisions here shape the global mobile standards. With Release 19 nearly wrapped up and an exciting 6G journey ahead, RAN2 participants left Prague with a sense of accomplishment and anticipation for the work to come.