Approved single-paging reply
The outgoing reply on a single paging mechanism for idle and inactive in 6G was approved.
Source: R3-263597, 3GPP RAN3 (Outgoing LS. Register status: approved at R3-133.). 3GPP TSG RAN WG3 #133. © 3GPP RAN3.
3GPP Scout / Meetings / RAN3 #133
RAN3 #133Final
RAN3 #133: what was agreed
At a glance
The outgoing reply on a single paging mechanism for idle and inactive in 6G was approved.
Source: R3-263597, 3GPP RAN3 (Outgoing LS. Register status: approved at R3-133.). 3GPP TSG RAN WG3 #133. © 3GPP RAN3.
The register marks ZTE's context-retrieval pCR as not pursued. This does not record approval of its proposal.
Source: R3-263173, ZTE (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © ZTE.
The register marks three P2P pCRs from Qualcomm and co-submitters, Huawei, and Samsung as not pursued.
Sources: R3-263058, Qualcomm (pCR. Register status: not pursued at R3-133.); R3-263110, Huawei (pCR. Register status: not pursued at R3-133.); R3-263139, Samsung (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © Qualcomm, Huawei, Samsung.
- TDocs registered
- 623
- Decisions read
- 9
- Agreements explained
- 5
- Points still open
- 2
Your topic
Follow a topic and get its next outcome by email.
Scout emails you when a new agreement or decision on it is recorded, with the source for each. Or ask Scout and get an answer that cites the exact TDoc. Free to start.
- UE context retrieval with and without Xa connectivityFollowAsk Scout
- Procedures and signalingFollowAsk Scout
- Point to Point Interface (P2P)FollowAsk Scout
- Service Based Interface (SBI)FollowAsk Scout
- When Xa connectivity exists, should context be retrieved directly, and what should the Resume ID identify? NEC, Lenovo, China MobileAsk Scout
Another topic or company? Follow it
What was agreed
| Agenda item | Topic | TDocs | Agreed here | Still open |
|---|---|---|---|---|
| 10.6.1 | UE context retrieval with and without Xa connectivity | 29 | 2 | 1 |
| 13.3 | Procedures and signaling | 31 | 1 | 0 |
| 10.3.1.1 | Point to Point Interface (P2P) | 25 | 2 | 1 |
10.6.1UE context retrieval with and without Xa connectivity
Context retrieval pCR register status
The register records the ZTE pCR as not pursued.
Source: R3-263173, ZTE (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © ZTE.
13.3Procedures and signaling
ISAC procedures register status
The register records Huawei's and InterDigital's contributions, plus Xiaomi's outgoing LS, as not pursued.
Sources: R3-263064, Huawei (Contribution. Register status: not pursued at R3-133.); R3-263100, InterDigital (Contribution. Register status: not pursued at R3-133.); R3-263540, Xiaomi (Outgoing LS. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © Huawei, InterDigital, Xiaomi.
10.3.1.1Point to Point Interface (P2P)
P2P pCR register status
The register records the Qualcomm-led, Huawei, and Samsung pCRs as not pursued.
Sources: R3-263058, Qualcomm (pCR. Register status: not pursued at R3-133.); R3-263110, Huawei (pCR. Register status: not pursued at R3-133.); R3-263139, Samsung (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © Qualcomm, Huawei, Samsung.
Nokia P2P pCR register status
The register records Nokia's P2P pCR as not pursued.
Source: R3-263220, Nokia (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © Nokia.
Who pushed what
10.6.1UE context retrieval with and without Xa connectivity
When Xa connectivity exists, should context be retrieved directly, and what should the Resume ID identify?
The submitted positions favor direct retrieval when Xa exists. China Mobile proposes studying Resume ID identifiers, but these company inputs do not record a meeting decision.
Compare the 3 proposals
| Company | What they propose | Source |
|---|---|---|
| NEC | NEC proposes direct retrieval from the last serving aNB via Xa.Their wordsFor the case UE resumes in a new aNB that has a direct Xa interface to the last serving aNB, UE context can be fetched [...] | R3-263184Proposal 1, paragraph 24 · register: not treated |
| Lenovo | Lenovo proposes direct retrieval from the last serving aNB via Xa.Their wordsProposal 1: For the case that the UE resumes in a new aNB that has an Xa interface with the last serving aNB, the new [...] | R3-263312Proposal 1, paragraph 45 · register: not treated |
| China Mobile | China Mobile proposes studying Resume ID identification of the serving aNB and UE context.Their wordsIn UE context retrieval with Xa connectivity case, RAN3 study resume ID design which may at least include the identification of the last serving aNB [...] | R3-263480Proposal 1, paragraph 19 · register: not treated |
Without direct Xa connectivity, should the CN relay context retrieval or should context remain within the RAN?
Qualcomm and China Telecom propose CN-assisted retrieval or transfer. Vodafone proposes RAN-only context storage and opposes relying on CN-based identification and retrieval.
Compare the 3 proposals
| Company | What they propose | Source |
|---|---|---|
| Qualcomm | Qualcomm supports retrieval via the CN when direct Xa connectivity is unavailable.Their wordsProposal 2: RAN3 to agree that UE context retrieval from the last serving aNB via the CN is supported when direct Xa connectivity between the [...] | R3-263270Proposal 2, paragraph 29 · register: not treated |
| China Telecom | China Telecom proposes RAN-CN retrieval with source-side security verification and context transfer via the CN.Their wordsto specify a new Retrieve UE Context procedure over the RAN-CN interface, where security verification is performed by the source aNB based on information relayed [...] | R3-263263Proposal 4, paragraph 38 · register: not treated |
| Vodafone | Vodafone proposes storing UE context only within the RAN.Their wordsTherefore, even though reducing resume latency is a valid objective, it is proposed to agree that, for RRC Inactive operation, the UE context should be [...] | R3-263092Store UE context only in the RAN, paragraph 42 · register: not treated |
13.3Procedures and signaling
What baseline should guide ISAC procedures and signaling?
AT&T characterizes the TR framework as the baseline, LG proposes Annex text as a baseline, and Huawei proposes Ns management messages. These are company submissions, not a recorded group decision.
Compare the 3 proposals
| Company | What they propose | Source |
|---|---|---|
| AT&T | AT&T describes the TR framework and message flows as the normative baseline.Their wordsThe procedure framework, procedure classes, and high-level message flows are already agreed in TR 38.765 and constitute the normative baseline. | R3-263073Observation 1, paragraph 34 · register: not treated |
| LG Electronics | LG proposes discussing its Annex texts as a baseline for Ns procedures.Their wordsProposal 1: Discuss the texts in Annex as baseline for the general aspects, functions and signaling procedures of the Ns interface. | R3-263417Proposal 1, paragraph 18 · register: not treated |
| Huawei | Huawei proposes Ns setup, configuration update, and error indication messages.Their wordsThe Ns interface management function include the following messages, which can be incorporated into the NsAP: gNB-Initiated Ns Setup: a Class 1 procedure (i.e., Ns [...] | R3-263064Proposal 2, paragraph 32 · register: not pursued |
10.3.1.1Point to Point Interface (P2P)
Which transport protocol should support P2P connectivity services?
The company submissions align on SCTP for connectivity services. They are company positions, not a recorded RAN3 decision.
Compare the 3 proposals
| Company | What they propose | Source |
|---|---|---|
| China Mobile | China Mobile proposes SCTP for the P2P connectivity-services interface.Their wordsProposal 1: The SCTP based protocol is used towards P2P interface for connectivity services. | R3-263477Proposal 1, paragraph 31 · register: not treated |
| AT&T | AT&T proposes maintaining SCTP for the P2P interface.Their wordsRAN3 maintains SCTP as the transport protocol for the 6G RAN-CN P2P interface supporting connectivity services. | R3-263066Proposal 1, paragraph 33 · register: noted |
| Deutsche Telekom | Deutsche Telekom calls SCTP-based P2P the most mature option.Their wordsObservation 1: SCTP based P2P is the most mature option for connectivity services. | R3-263211Observation 1, paragraph 16 · register: not treated |
Company contributions to 3GPP TSG RAN WG3 #133. Each TDoc is © the company named in its row. These are proposals, not decisions.
Still open
Still open
The ZTE pCR was not pursued, so its proposed context-retrieval text has no recorded approval in this register entry.
Source: R3-263173, ZTE (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © ZTE.
The supplied P2P pCR entries record no selected interface approach because they were marked not pursued.
Sources: R3-263058, Qualcomm (pCR. Register status: not pursued at R3-133.); R3-263110, Huawei (pCR. Register status: not pursued at R3-133.); R3-263139, Samsung (pCR. Register status: not pursued at R3-133.). 3GPP TSG RAN WG3 #133. © Qualcomm, Huawei, Samsung.
What to watch next meeting
At the next meeting, check whether context-retrieval proposals receive a recorded disposition after the ZTE pCR was marked not pursued.
Sources: R3-263173, ZTE (pCR. Register status: not pursued at R3-133.); R3-263270, Qualcomm (Proposal 2, paragraph 29). 3GPP TSG RAN WG3 #133. © ZTE, Qualcomm.
Check whether ISAC Ns procedure proposals return in a treated item after the Huawei contribution was marked not pursued.
Source: R3-263064, Huawei (Contribution. Register status: not pursued at R3-133.; Proposal 2, paragraph 32). 3GPP TSG RAN WG3 #133. © Huawei.
Check whether a P2P transport choice is recorded, given the SCTP positions and not-pursued pCRs.
Sources: R3-263058, Qualcomm (pCR. Register status: not pursued at R3-133.); R3-263477, China Mobile (Proposal 1, paragraph 31); R3-263211, Deutsche Telekom (Observation 1, paragraph 16). 3GPP TSG RAN WG3 #133. © Qualcomm, China Mobile, Deutsche Telekom.
Sources
All 20 TDocs cited
- R3-263597 Reply LS to R2-2602817 = R3-262066 and S2-2606684 = R3-263017 on single paging mechanism for idle and inactive in 6G (to: RAN2, SA2; cc: SA3; contact: ZTE). 3GPP RAN3. Outgoing LS. Register status: approved at R3-133.
- R3-263173 (pCR to TR38.760-3) Discussion on UE context retrieval with and without Xa connectivity in 6G. ZTE. pCR. Register status: not pursued at R3-133.
- R3-263058 (pCR to TR 38.760-3) On P2P IF for 6G non-connectivity services. Qualcomm (with T-Mobile USA, NTT DOCOMO, FiberCop). pCR. Register status: not pursued at R3-133.
- R3-263110 Consideration on unified RAN-CN interface solution. Huawei. pCR. Register status: not pursued at R3-133.
- R3-263139 Discussion on P2P based RAN-CN interface. Samsung. pCR. Register status: not pursued at R3-133.
- R3-263064 (TPs for ISAC) Procedures and signaling. Huawei. Contribution. Register status: not pursued at R3-133.
- R3-263100 ISAC RAN-CN procedure model and signaling content. InterDigital. Contribution. Register status: not pursued at R3-133.
- R3-263540 Draft LS on measurement parameter reuse and physical layer definitions for ISAC (to: RAN1; cc: SA2; contact: Xiaomi). Xiaomi. Outgoing LS. Register status: not pursued at R3-133.
- R3-263220 P2P solution with AMF for new Services. Nokia. pCR. Register status: not pursued at R3-133.
- R3-263184 6G paging and UE context retrieval. NEC. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263312 Discussion on UE context retrieval in 6G. Lenovo. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263480 Discussion on UE context retrieval with and without Xa connectivity. China Mobile. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263270 UE context retrieval in 6G Inactive state with single paging. Qualcomm. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263263 Discussion on UE Context Retrieval for 6G Inactive State. China Telecom. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263092 Views on RRC Inactive in 6G and answers to SA2. Vodafone. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263073 Discussion on Procedures and Signaling for ISAC. AT&T. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263417 Discussion on NsAP protocol functions and procedural details. LG Electronics. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263477 Discussion on P2P interface for RAN-CN interface design. China Mobile. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
- R3-263066 Discussion on P2P for RAN-CN Control Plane. AT&T. Contribution. Register status: noted at R3-133.
- R3-263211 Protocol stack considerations for RAN-CN P2P interface for connectivity services. Deutsche Telekom. Contribution. Register status: not treated at R3-133. No decision recorded in the register.
Coverage: RAN3 #133 (Maastricht, 2026-08-24 to 2026-08-28), agenda items 10.6.1, 13.3, 10.3.1.1.
What this page read and what it leaves out
Scout read 9 recorded decisions and 145 company positions or contribution passages on these agenda items (catalog synced 2026-09-29) and cites 9 decisions and 12 positions from 20 TDocs. Every quoted passage was matched verbatim against the TDoc text; the summaries around the quotes are Scout's reading. Register statuses are copied from the 3GPP TDoc register: not treated means a document was not handled on its own, though its content may have fed feature-lead summaries or merged revisions. Not covered: other agenda items and meetings, plenary TDocs and plenary decisions after the meeting, email discussions after the meeting, and anything not yet in the chair notes or register.
The supplied decision items are register outcomes, except for the approved outgoing LS. They do not record substantive decisions on context retrieval, ISAC procedures, or P2P.
Several company positions are marked not treated and therefore are pre-meeting inputs, not evidence of discussion.
Next outcome
Get the RAN3 #133-bis outcome by email.
Scout emails you when RAN3 records a new agreement or decision, with the source for each. Free to start.
- Every new RAN3 agreement and decisionFollow RAN3
Built by 3GPP Scout from the public meeting record (623 TDocs registered, catalog synced 2026-09-29). Significance scores compare each topic's activity at this meeting with the group's topics over the past 12 months. Excerpts are at most 25 words and link to the original on the 3GPP file server.