3GPP TSG RAN WG1 #123	R1-250XXXX

Dallas, USA, Nov 17th – 21st, 2025

Source:	Chair

Title:	Draft Agenda

Document for:	Decision

Meeting registration:	The deadline is Monday, Nov 10th, 08:00 UTC

Tdoc request:	The deadline is Friday, Nov 7th, 15:00 UTC

Tdoc submission:	The deadline is Friday, Nov 7th, 23:59 UTC

Opening of the meeting (Day 1: 9:00 am)

Call for IPR

I draw your attention to your obligations under the 3GPP Partner Organizations' IPR policies. Every Individual Member organization is obliged to declare to the Partner Organization or Organizations of which it is a member any IPR owned by the Individual Member or any other organization which is or is likely to become essential to the work of 3GPP.

The attention of the delegates to this meeting was drawn to the fact that 3GPP Individual Members have the obligation under the IPR Policies of their respective Organizational Partners to inform their respective Organizational Partners of Essential IPRs they become aware of. The delegates were asked to take note that they were thereby invited: to investigate whether their organization or any other organization owns IPRs which were, or were likely to become Essential in respect of the work of 3GPP. to notify their respective Organizational Partners of all potential IPRs, e.g., for ETSI, by means of the IPR Statement and the Licensing declaration forms (http://www.etsi.org/WebSite/document/Legal/IPRForms.doc).

Competition Law Statement

The attention of the delegates to this meeting was drawn to the fact that 3GPP activities are subject to antitrust and competition laws and that compliance with said laws is therefore required of any participant of this WG meeting including the Chair and Vice Chairs. In case of question, please contact your legal counsel. The present meeting will be conducted with strict impartiality and in the interests of 3GPP. Furthermore, delegates were reminded that timely submission of work items/contributions in advance of WG meetings is important to allow for full and fair consideration of such matters.

Network Usage Conditions

Users shall not use the network to engage in illegal activities. This includes activities such as copyright violation, hacking, espionage or any other activity that may be prohibited by local laws. Users shall not engage in non-work related activities that consume excessive bandwidth or cause significant degradation of the performance of the network. Since the network is a shared resource, users should exercise some basic etiquette when using the 3GPP network at a meeting. It is understood that high bandwidth applications such as downloading large files or video streaming might be required for business purposes, but delegates should be strongly discouraged in performing these activities for personal use. Downloading a movie or doing something in an interactive environment for personal use essentially wastes bandwidth that others need to make the meeting effective. The meeting chairman should remind end users that the network is a shared resource; the more one user grabs, the less there is for another. Email and its attachments already take up significant bandwidth (certain email programs are not very bandwidth efficient). In case of need the chair can ask the delegates to restrict IT usage to things that are essential for the meeting itself. Don’t place your WiFi device in ad-hoc mode Don’t set up a personal hotspot in the meeting room Do try 802.11a if your WiFi device supports it Don’t manually allocate an IP address Don’t be a bandwidth hog by streaming video, playing online games, or downloading huge files Don’t use packet probing software which clogs the local network (e.g., packet sniffers, port scanners)

Consensus Principles Reminder

Decision PCG54/10: PCG approved to incorporate the following text to the agendas of each and every TSG and Working Group on “Consensus principles reminder”: The attention of the delegates to the meeting is drawn to the fact that 3GPP endeavours to reach consensus on all decisions and therefore depends on a cooperative spirit of the Individual Members. In particular, Individual Members are encouraged to seek a consensus-based solution and only to sustain objections as a very last resort, and where absolutely necessary and well justified. The leadership will conduct the present meeting in a manner whereby informal methods of reaching consensus are encouraged, whilst ensuring that well justified concerns are taken into account.

Streamlined Standards

Endorsement RAN#107: RAN endorsed the following working principle for 6G (in RP-250766): 3GPP to create lean and streamlined standards for 6G, e.g., by dimensioning an appropriate set of functionalities, minimizing the adoption of multiple options for the same functionality, avoiding excessive configurations, etc. Any exception to the above shall be well justified.

Check-in for Registered Delegates

The attention of the delegates to this meeting was drawn to the fact that it is not permitted to check in other delegates on their behalf. In the event of technical difficulties preventing check-in, delegates should present themselves in person to the Secretary.

Approval of Agenda

R1-2508300	Draft Agenda of RAN1#123 meeting	RAN1 Chair

R1-2509000	Draft Agenda of RAN1#123 meeting	RAN1 Chair

R1-2508302	RAN1#123 Meeting Timelines, Scope, Process	RAN1 Chair, ETSI MCC

Highlights from RAN plenary

None for this meeting

Approval of Minutes from previous meetings

R1-2508301	Report of RAN1#122bis meeting	ETSI MCC

Incoming Liaison Statements

R19 AI/ML

R1-2508309	Reply LS on UE data collection and data transfer	RAN2, Nokia

Reply LS from RAN2 to SA4’s LS R1-2506712, in which RAN1 was CC-ed. No RAN1 action needed.

R1-2508310	Reply LS on signalling feasibility of dataset and parameter sharing	RAN2, Samsung

Following RAN2 LS R1-2505107, RAN2 replied to SA5’s reply R1-2506712, in which RAN1 was CC-ed. No RAN1 action needed.

R1-2508319	Reply LS on specification of dataset and model parameters exchange	SA5, NEC

Reply LS from RAN2 replied to SA5, in which RAN1 was CC-ed. No RAN1 action needed

R19 SBFD

R1-2508304	LS on SBFD and CA	RAN2, Interdigital

RAN2 is requesting RAN1 to provide TP for supporting SBFD with CA in the stage-2 specification (TS 38.300). RAN1 response needed. To be handled in agenda item 8.3. Moderator Xinghua (Huawei)

Relevant Tdocs:

R1-2508399	Draft reply LS on SBFD and CA	vivo

R1-2508566	Draft reply LS on SBFD and CA	CATT

R1-2508655	Draft reply LS on SBFD and CA	Xiaomi

R1-2508690	Draft reply LS on SBFD and CA	ZTE Corporation, Sanechips

R1-2508707	Discussion on RAN2 LS on SBFD and CA	OPPO

R1-2508767	Draft reply LS on SBFD and CA	Samsung

R1-2508866	Draft Reply LS on SBFD and CA	InterDigital, Inc.

R1-2508920	Draft reply LS on SBFD and CA	Fujitsu

R1-2509012	DRAFT Reply LS on SBFD and CA	Nokia

R1-2509196	Draft Reply LS on SBFD and CA	Qualcomm Incorporated

R1-2509255	Discussion on LS on SBFD and CA	NTT DOCOMO, INC.

R1-2509315	Supporting of SBFD in multi-carrier scenario	ASUSTeK

R1-2509392	Draft reply LS on SBFD and CA	Google

R1-2509402	On RAN2 LS on SBFD and CA	Ericsson

R1-2509430	Draft reply LS on SBFD and CA	Huawei, HiSilicon

R9 A-IoT

R1-2508311	Reply LS on AIoT Device Permanent ID Length	RAN2, Huawei

Reply LS from RAN2 to SA2 to confirm the feasibility of extending the Device Permanent ID while sharing the observation that the less overhead of paging message, the better coverage performance for paging message reception and the pressure of assumption of the total 1000-bit paging message space. RAN1 was CC-ed. No RAN1 immediate action needed. It will be discussed or revisited when SA2 decides to extend the Device Permanent ID.

Relevant Tdoc:

R1-2509197	Discussion on AIoT permanent ID length extension	Qualcomm Incorporated

R1-2508312	LS on Early Alignment on Access Stratum security aspects	RAN2, Vodafone

RAN2 is requesting SA3 to the potential topic for study and concerns were expressed about the impacts, such as potential overhead (e.g., increased message exchange/size in handover signaling, large security overhead for small messages) and processing requirements due to AS security, security for lower layer control information. RAN1 was CC-ed. No RAN1 action needed.

R19 NES

R1-2508305	LS on OD-SSB	RAN2, Apple

RAN2 is requesting RAN1 to take its related agreements on the relationship between SSB-less SCell and OD-SSB Case 1 (i.e. only with OD-SSB but without Always-On SSB) into account and provide feedback if any concern. RAN1 response needed. To be handled in agenda item 8.5. Moderator Seonwook (LGE)

Relevant Tdocs:

R1-2508400	Draft reply LS on OD-SSB	vivo

R1-2508766	Draft reply LS on OD-SSB	Samsung

R1-2508812	Discussion about OD-SSB	ZTE Corporation, Sanechips

R1-2508891	Discussion on RAN2 LS on OD-SSB	LG Electronics

R1-2509391	Discussion on RAN2 LS on OD-SSB	Nokia, Nokia Shanghai Bell

R1-2509425	Discussion on RAN2 LS on OD-SSB	Ericsson

R1-2509431	Draft reply LS on OD-SSB	Huawei, HiSilicon

R19 NR-NTN

R1-2508308	LS on OCC for RACH-less HO	RAN2, Thales

RAN2 is requesting RAN1 to provide feedback if OCC can be supported for RACH-less handover without any further update in their current specifications. RAN1 response needed. To be handled in agenda item 8.7.1. Moderator Mohamed (Thales)

Relevant Tdocs:

R1-2508398	Draft reply LS on OCC for RACH-less HO	vivo

R1-2508554	Discussion on RAN2 LS on OCC for RACH-less HO	NEC

R1-2508565	Discussion on LS on OCC for RACH-less HO	CATT

R1-2508656	Discussion on LS on OCC for RACH-less HO	Xiaomi

R1-2508704	Discussion on OCC for RACH-less HO	OPPO

R1-2508705	Draft Reply LS on OCC for RACH-less HO	OPPO

R1-2508765	Discussion on RAN2 LS on OCC for RACH-less HO	Samsung

R1-2508846	Discussion on RAN2 LS on OCC for RACH-less HO	Ericsson

R1-2508847	Discussion on the LS on OCC for RACH-less HO	ZTE Corporation, Sanechips

R1-2509158	Reply LS on OCC for RACH-less HO for NR NTN Ph3	MediaTek Inc.

R1-2509198	Discussion on OCC for RACH-less HO	Qualcomm Incorporated

R1-2509426	Discussion on OCC for RACH-less HO	Huawei, HiSilicon

R1-2509427	Draft LS reply on OCC for RACH-less HO	Huawei, HiSilicon

R19 IoT-NTN

R1-2509159	Discussion on LS on power ramping and RRC configuration for CB-Msg3-EDT in IoT NTN Ph3	MediaTek Inc.

Related LS has been treated in RAN1#122bis, when it was assigned to AI 8.7.2 led by Gilles (MediaTek), so this contribution will continue to be handled under AI 8.7.2.

R20 IoT-NTN

IMS voice

R1-2508306	Reply LS on issues related to support of IMS voice over NB-IoT NTN connected to EPC	RAN2, Vivo

R1-2508317	Reply LS on issues related to support of IMS voice over NB-IoT NTN connected to EPC	SA3, Vivo

R1-2508318	Reply LS on issues related to support of IMS voice over NB-IoT NTN connected to EPC	CT1, Vivo

Reply LSs to SA2 from RAN2, SA3 and CT1, respectively, in which RAN1 was CC-ed. No RAN1 action needed.

ULBC

R1-2508307	Reply LS on the RAN simulation assumptions, bundling period and SPS for ULBC	RAN2, Qualcomm

Reply LS from RAN2 to SA4, in which RAN1 was CC-ed. No RAN1 action needed.

R19 LB-CA

R1-2508315	LS of RAN4 RRM agreement update on switching pattern application	RAN4, Apple

RAN4 is requesting RAN1 to take its revised agreement on the applicability of switching pattern for SDL SCell for RRM requirements. RAN1 action is needed. To be handled under AI 8.8. Moderator Haitong (Apple)

Relevant Tdocs:

R1-2509316	Discussion on RAN4 LS on RRM agreement update on switching pattern application	Ericsson

R1-2509412	Discussion on the LS of RAN4 RRM agreement update on switching pattern application	ZTE Corporation, Sanechips

R19 UE features

R1-2508313	LS on Rel-19 RAN4 UE feature list for NR (version 3)	RAN4, CMCC

RAN4 inform RAN2 about their output of Rel-19 RAN4 UE feature list for NR. RAN1 was CC-ed. No RAN1 action needed.

R1-2508633	Discussion on RAN2 LS on per band and per BC capability	Nokia

R1-2508698	Discussion on per band and per BC capability	OPPO

Related LS has been treated in RAN1#122bis, when it was assigned to agenda for UE features led by Ralf (AT&T), so these 2 contributions will continue to be handled under AI 9.3.

6GR

R1-2508314	LS on 6GR system parameter evaluations	RAN4, Huawei

RAN4 is requesting RAN1 to provide 6GR system parameters evaluations help RAN4 progress with 6G radio SI, including but not limited to PA modelling discussion that can be applied in RAN1 waveform evaluation. RAN1 response needed. To be handled in agenda item 11.1. Moderator Shinya (DOCOMO)

Relevant Tdoc:

R1-2509256	Draft reply LS on 6GR system parameter evaluations	NTT DOCOMO, INC.

RAN4 6Rx

R1-2508303	Reply LS on Release Independence of 6Rx	RAN2, Qualcomm

Reply LS from RAN2 to RAN4, in which RAN1 was CC-ed. No RAN1 action needed.

R1-2508316	Reply LS on allocation of CN assigned subgroup ID for LP-WUS	SA2, Ericsson

Reply LS from SA2 to RAN3, in which RAN1 was CC-ed. No RAN1 action needed.

R1-2508858	LS out to 3GPP RAN1#123 and RAN3#130 on the availability of draft Group Report DGR003	ETSI ISG ISAC, Interdigital

ETSI’s Industry Specification Group (ISG) on Integrated Sensing And Communications (ISAC) informs its activities and workplan, for information (no action required). No RAN1 action needed.

Pre-Rel-19 E-UTRA Maintenance

Only essential corrections – a rejected draft CR will be marked in red

For maintenance on RAN1 specifications, individual draft CRs are to be submitted. Final endorsed CR will be sourced by “Moderator (company name)” and other co-sourcing companies (if any).

Maintenance issues on Pre-Rel-19 E-UTRA will be discussed in RAN1 adhoc1 session (chaired by Sorour).

R1-2509439	Session Notes of AI 6	Ad-Hoc Chair (Ericsson)

R1-2508868	On Interference Randomization for non-anchor carrier in NB-IoT	Ericsson

R1-2509160	Discussion on interference randomization for non-anchor carrier in NB-IoT	MediaTek Inc., Qualcomm Inc.

R1-2509161	Alignment CR for MAC-CE TA command in IoT NTN	MediaTek Inc.

Pre-Rel-19 NR Maintenance

Only essential corrections – a rejected draft CR will be marked in red

For maintenance on RAN1 specifications, individual draft CRs are to be submitted. For more efficient review, please use/fill the release and WI code fields when requesting tdoc numbers for draft CRs. Final endorsed CR will be sourced by “Moderator (company name)” and other co-sourcing companies (if any).

Maintenance issues on Pre-Rel-19 NR will be discussed in RAN1 adhoc1 session (chaired by Sorour).

R1-2509440	Session Notes of AI 7	Ad-Hoc Chair (Ericsson)

R1-2508401	Draft CR on PUSCH without repetition when two SRS resource sets are configured (Rel-17)	vivo

R1-2508402	Draft CR on PUSCH without repetition when two SRS resource sets are configured (Rel-18 mirror)	vivo

R1-2508403	Views on UL and DL channel reciprocity modelling	vivo

R1-2508506	Correction on L1-SINR reporting in UCI in 38.212	Huawei, HiSilicon

R1-2508507	Correction on the condition for the number of UL PTRS ports in 38.214	Huawei, HiSilicon

R1-2508533	Draft CR on SRS port(s) mapping on OFDM symbol(s)	ZTE Corporation, Sanechips

R1-2508534	Discussion on CPU occupation for P3 procedure	ZTE Corporation, Sanechips

R1-2508552	Discussion on SRS ports mapping in one symbol	NEC

R1-2508556	Draft CR for TS 38.213 on RACH-less handover_Rel-18	NEC,vivo

R1-2508557	Draft CR for TS 38.213 on RACH-less handover_Rel-19	NEC,vivo

R1-2508558	Draft CR for TS 38.214 on DMRS for RACH-less handover_Rel-18	NEC,vivo

R1-2508559	Draft CR for TS 38.214 on DMRS for RACH-less handover_Rel-19	NEC,vivo

R1-2508567	Correction on power control for SRS antenna switching	CATT

R1-2508568	Correction on configuration for TDCP reporting	CATT

R1-2508648	Draft Rel-18 CR for RACH-less handover	Ericsson

R1-2508649	Draft Rel-19 CR for RACH-less handover	Ericsson

R1-2508768	Draft CR on the total number of modulation symbols in case of CP-OFDM	Samsung, ZTE

R1-2508848	Draft CR for TS 38.213 on RACH-less handover	ZTE Corporation, Sanechips

R1-2508849	Draft CR for TS 38.214 on RACH-less handover	ZTE Corporation, Sanechips

R1-2508939	Draft CR on CSI Calculation	Google

R1-2509028	Draft CR on stop condition for recovery search space set monitoring for unified TCI update	Ofinno

R1-2509080	Tx utilization with dualUL	Apple

R1-2509127	Sequence generation for uplink DM-RS in RACH-less HO or RACH-less LTM cell switch	Ofinno

R1-2509128	Draft CR on sequence generation for uplink DM-RS in NTN RACH-less HO in TS 38.211	Ofinno

R1-2509129	Draft CR on sequence generation for uplink DM-RS in RACH-less LTM cell switch in TS 38.211	Ofinno

R1-2509171	Discussions on CSI report priority and CSI computation time for P3 procedure	Sharp

R1-2509217	Clarification on simultaneous PUCCH and PUSCH transmission in CA scenarios	Qualcomm Incorporated

R1-2509252	Discussion on dynamic waveform switching for intra-band CA	ZTE Corporation, Sanechips

R1-2509257	Draft CR on SRI in STxMP SFN non-codebook PUSCH	NTT DOCOMO, INC., NEC

R1-2509328	UCI transmission without configuration of HARQ-ACK codebook	Xiaomi

R1-2509376	Draft CR on UL and DL reciprocity modelling	Ericsson, InterDigital, Intel

R1-2509429	Correction to PRACH signal generation for LTM in TS38.211	Huawei, HiSilicon

Maintenance on Rel-19 NR and E-UTRA

The maximum number of contributions per company/organization/university is limited to 1 per agenda item unless stated otherwise.

For Rel-19 maintenance, only essential corrections will be considered. Only text proposals are to be submitted (no individual draft CRs, please!).

For each text proposal, companies are to provide relevant information (e.g. reason for change, summary of change, consequences if not approved) in a clear and concise manner

Editors to prepare final CRs

Maintenance on Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface

Note: Maximum one contribution per company/organization/university. For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

Specification support for beam management

Specification support for positioning accuracy enhancements

Specification support for CSI prediction

[123-R19-AI/ML] Email discussion on AI/ML – Juan (Qualcomm)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509441	Session Notes of AI 8.1	Ad-Hoc Chair (Ericsson)

R1-2508770	FL summary #0 for AI/ML in beam management	Moderator (Samsung)

R1-2508771	FL summary #1 for AI/ML in beam management	Moderator (Samsung)

R1-2508772	FL summary #2 for AI/ML in beam management	Moderator (Samsung)

R1-2508364	Remaining Issues of Rel-19 AI/ML for NR Air Interface	Ericsson

R1-2508404	Maintenance on AI/ML for NR Air Interface	vivo

R1-2508497	Maintenance of Rel-19 AI/ML for air interface	Huawei, HiSilicon

R1-2508546	Remaining Issues on AIML for NR Air Interface	NEC

R1-2508569	Maintenance of AI/ML for NR air interface	CATT

R1-2508644	Maintenance on Rel-19 AI/ML	InterDigital, Inc.

R1-2508657	Maintenance on AI/ML for NR Air Interface	Xiaomi

R1-2508691	Discussion on maintenance of AI for Air Interface	ZTE Corporation, Sanechips

R1-2508710	Maintenance on Rel-19 AI/ML for NR air interface	OPPO

R1-2508747	Maintenance on AI/ML for NR Air interface	LG Electronics

R1-2508769	Remaining issue on AI/ML for NR Air Interface	Samsung

R1-2508921	Remaining issues on AI/ML for air interface in Rel-19	Fujitsu

R1-2508940	Maintenance for AI/ML for NR Air Interface	Google

R1-2508948	Maintenance on AI/ML for NR Air Interface	Nokia

R1-2508952	Maintenance on AI/ML for beam management	Lenovo

R1-2508997	Discussion on AI/ML maintenance in 5G NR interface	Panasonic

R1-2509057	Maintenance on Rel-19 AI/ML for NR Air Interface	Fraunhofer HHI

R1-2509081	Remaining issues for R19 AI/ML for NR air interface	Apple

R1-2509182	Maintenance on AI/ML for NR Air Interface	Sharp

R1-2509186	Summary #1 of maintenance on CSI prediction	Moderator (LG Electronics)

R1-2509187	Summary #2 of maintenance on CSI prediction	Moderator (LG Electronics)

R1-2509188	Summary #3 of maintenance on CSI prediction	Moderator (LG Electronics)

R1-2509199	Maintenance on AI/ML for NR air interface	Qualcomm Incorporated

R1-2509253	Maintenance on AI/ML for NR air interface	Quectel

R1-2509294	Summary #1: maintenance of specification support for positioning accuracy enhancement	Ericsson Telecom S.A. de C.V.

Maintenance on NR MIMO Phase 5

Note: Maximum one contribution per company/organization/university. For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

Enhancements for UE-initiated/event-driven beam management

CSI enhancements

Support for 3-antenna-port codebook-based transmissions

Enhancement for asymmetric DL sTRP/UL mTRP scenarios.

[123-R19-MIMO] Email discussion on MIMO – Eko (Samsung)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509442	Session Notes of AI 8.2	Ad-Hoc Chair (Ericsson)

R1-2508528	Moderator Summary #1 on UE-initiated/event-driven beam management	Moderator (ZTE)

R1-2508529	Moderator Summary #2 on UE-initiated/event-driven beam management	Moderator (ZTE)

R1-2508530	Moderator Summary #3 on UE-initiated/event-driven beam management	Moderator (ZTE)

R1-2508343	FL Summary Support for 3TX CB-based Uplink; First Round	Moderator (InterDigital, Inc.)

R1-2508405	Maintenance on MIMO phase 5	vivo

R1-2508461	Maintenance of NR MIMO Phase 5	Ericsson

R1-2508490	Maintenance of MIMO Phase 5	Huawei, HiSilicon

R1-2508527	Maintenance on NR MIMO Phase 5	ZTE Corporation, Sanechips

R1-2508551	Remaining issues on NR MIMO Phase 5	NEC

R1-2508570	Remaining issues on NR MIMO Phase 5	CATT

R1-2508653	Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP	Moderator (OPPO)

R1-2508654	Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP	Moderator (OPPO)

R1-2508658	Maintenance on NR MIMO Phase 5	Xiaomi

R1-2508711	Remaining Issues of NR MIMO Phase 5	OPPO

R1-2508773	Remaining issue on NR MIMO Phase 5	Samsung

R1-2508774	Moderator Summary#1 on Rel-19 CSI enhancements: Round 1	Moderator (Samsung)

R1-2508775	Moderator Summary#2 on Rel-19 CSI enhancements: Round 2	Moderator (Samsung)

R1-2508776	Offline Session Moderator Summary on Rel-19 CSI enhancements	Moderator (Samsung)

R1-2508922	Remaining issues on NR MIMO Phase 5	Fujitsu

R1-2509029	Maintenance on NR MIMO Phase 5	Ofinno

R1-2509200	Maintenance on NR MIMO Phase 5	Qualcomm Incorporated

R1-2509313	Maintenance of NR MIMO Phase 5	Nokia Corporation

R1-2509356	Maintenance on NR MIMO Phase 5	Google

R1-2509364	Remaining issues on UE initiated beam report	ASUSTeK

Maintenance on Evolution of NR duplex operation: Sub-band full duplex (SBFD)

Note: Maximum one contribution per company/organization/university. For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

SBFD TX/RX/measurement procedures

SBFD random access operation

CLI handling

[123-R19-SBFD] Email discussion on SBFD – Xinghua (Huawei)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

Adopt the following TP for section 8.1, TS 38.213

8.1 Random access preamble <Unchanged parts omitted> - if a UE is provided tdd-UL-DL-ConfigurationCommon for a cell, a PRACH occasion for the cell in a PRACH slot is valid if - For a first PRACH occasion, - it is within UL symbols, or - it does not precede a SS/PBCH block in the PRACH slot, and starts at least symbols after a last downlink symbol and at least symbols after a last SS/PBCH block symbol, where is provided in Table 8.1-2, and if channelAccessMode = "semiStatic" is provided, does not overlap with a set of consecutive symbols before the start of a next channel occupancy time where there shall not be any transmissions, as described in [15, TS 37.213] - the candidate SS/PBCH block index of the SS/PBCH block corresponds to the SS/PBCH block index provided by ssb-PositionsInBurst in SIB1 or in ServingCellConfigCommon or in SSB-MTC-AdditionalPCI corresponding to the cell, as described in clause 4.1 - For a second PRACH occasion, - it starts at least symbols after a last non-SBFD downlink symbol and at least symbols after a last SS/PBCH block symbol, where is provided in Table 8.1-2, and does not overlap with a SS/PBCH block symbol, and - it is only within SBFD symbols and including at least one SBFD symbol indicated as downlink by tdd-UL-DL-ConfigurationCommon, and in RBs that are both in the active UL BWP and in the UL sub-band if the UE is provided sbfd-RACHSingleConfig, or - it is only within SBFD symbols and is in RBs that are both in the active UL BWP and in the UL sub-band if the UE is provided sbfd-RACHDualConfig, or - it starts from an SBFD symbol and ends in a non-SBFD symbols and is in RBs that are both in the active UL BWP and in the UL sub-band, if the UE is provided sbfd-RACHDualConfig and sbfd-RACHDualConfig-ValidROAcrossSymbolTypes

Agreement

Adopt the following TP to section 6.1.2.1a, TS 38.214:

6.1.2.1a Resource allocation in time domain for SBFD For a UE scheduled with PUSCH transmission occasions across SBFD symbols and non-SBFD symbols in different slots, - if the UE is not configured with sbfd-Config2-Transmission, or if the UE is configured with sbfd-Config2-Transmission and for PUSCH transmissions scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI or RAR UL grant and associated with a PRACH transmission in second PRACH occasions, - the UE transmits only the PUSCH in a valid symbol type; - For Type 1 PUSCH transmissions with a configured grant, the valid symbol type is provided by symbolType in rrc-ConfiguredUplinkGrant in ConfiguredGrantConfig. - For Type 2 PUSCH transmissions with a configured grant or PUSCH transmissions scheduled by DCI scrambled with SP-CSI-RNTI, the valid symbol type is the symbol type of the first PUSCH transmission occasion associated with activation DCI. For Type 2 PUSCH transmissions with a configured grant of PUSCH repetition type B, the valid symbol type is the symbol type of the first actual repetition associated with activation DCI. - For PUSCH transmissions scheduled by DCI format 0_1, 0_2, 0_3, or PUSCH transmissions scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI, RAR UL grant and associated with a PRACH transmission in second PRACH occasions, the valid symbol type is the symbol type of the first PUSCH transmission occasion indicated by the scheduling DCI or the RAR UL grant. For PUSCH repetition type B scheduled by DCI format 0_1 or 0_2, the valid symbol type is the symbol type of the first actual repetition occasion indicated by scheduling DCI. The UE does not expect that the first PUSCH transmission occasion indicated by scheduling DCI or the RAR UL grant is mapped to both SBFD symbols and non-SBFD symbols, except for PUSCH repetition type B. - For PUSCH repetition type A scheduled by DCI format 0_1, 0_2 or 0_3 when AvailableSlotCounting is enabled and K>1 or TB processing over multiple slots or PUSCH repetition type A scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI, or RAR UL grant and associated with a PRACH transmission in second PRACH occasions, - a slot containing the transmission occasion that is not in the valid symbol type is not counted in the number of slots. - In case the valid symbol type is SBFD symbol, a slot is counted in the number of slots if the symbols allocated for the transmission occasion in the slot are all SBFD symbols and not include a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst. - In case the valid symbol type is non-SBFD symbol, if the PUSCH repetition type A is scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI or RAR UL grant and associated with a PRACH transmission in second PRACH occasions, a slot is counted in the number of slots if the symbols allocated for the transmission occasion in the slot are all non-SBFD symbols and not include a DL symbol indicated by tdd-UL-DL-ConfigurationCommon, if provided, or a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst. Otherwise, a slot is counted in the number of slots if the symbols allocated for the transmission occasion in the slot are all non-SBFD symbols and not include a DL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated, if provided, or a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst. - For PUSCH repetition type B, UE drops an actual repetition if the actual repetition is not in the valid symbol type. - otherwise, the UE transmits the PUSCH occasions in SBFD symbols and non-SBFD symbols after applying collision handling in clause 11.1 of [6, TS 38.213], if any. For PUSCH repetition type A scheduled by DCI format 0_1, 0_2 or 0_3 when AvailableSlotCounting is enabled and K>1 or TB processing over multiple slots, a slot is counted in the number of slots if the symbols allocated for the transmission occasion in the slot are all SBFD symbols and not include a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst, or the symbols allocated for the transmission occasion in the slot are all non-SBFD symbols and not include a DL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated, if provided, or a symbol of an SS/PBCH block with index provided by ssb-PositionsInBurst. For a UE configured with SBFD symbols and scheduled with a PUSCH transmission occasion that is mapped to SBFD symbols and non-SBFD symbols within a slot, - If the PUSCH transmission occasion is scheduled for PUSCH repetition type A with AvailableSlotCounting is enabled and K>1 or TB processing over multiple slots, or the PUSCH transmission is scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI or RAR UL grant and associated with a PRACH transmission in a second PRACH occasion, the slot is not counted in the number of slots. - If the PUSCH transmission occasion is a nominal repetition for PUSCH repetition type B, the nominal repetition is segmented into actual repetitions around boundary of SBFD symbols and non-SBFD symbols. If the UE is not configured with sbfd-Config2-Transmission, UE drops an actual repetition if the actual repetition is not in the valid symbol type. - Otherwise, the UE does not transmit the PUSCH transmission occasion.

Agreement

Adopt the following TP in principle to Clause 11.1, TS 38.213.

11.1 Slot configuration <omitted text> When the UE is provided sbfd-Config2-Transmission, the UE can - transmit a first PUCCH or PUSCH or a first repetition of a PUCCH or PUSCH in non-SBFD symbols, and - transmit a second PUCCH or PUSCH or a second repetition of the PUCCH or PUSCH, in SBFD symbols When the UE is provided sbfd-Config2-Reception, the UE can, - receive a first PDSCH or a first repetition of a PDSCH in non-SBFD symbols, and - receive a second PDSCH or a second repetition of the PDSCH in SBFD symbols <omitted text>

Agreement

Adopt the following TP in principle to Clause 9.2.6, TS 38.213.

9.2.6 PUCCH repetition procedure For unpaired spectrum, the UE determines the slots for a PUCCH transmission starting from a slot indicated to the UE as described in clause 9.2.3 for HARQ-ACK reporting, or a slot determined as described in clause 9.2.4 for SR reporting or in clause 5.2.1.4 of [6, TS 38.214] for CSI reporting and having - an UL symbol, as described in clause 11.1, or flexible symbol, or an SBFD symbol as described in clause 11.1, that is not SS/PBCH block symbol provided by startingSymbolIndex as a first symbol, and - consecutive UL symbols, as described in clause 11.1, or flexible symbols, or consecutive SBFD symbols as described in clause 11.1, respectively, that are not SS/PBCH block symbols, starting from the first symbol, equal to or larger than a number of symbols provided by nrofsymbols, and - if the UE is not provided sbfd-Config2-Transmission, and if the valid symbol type for the PUCCH transmission is determined as SBFD symbol, the UE shall only consider slots containing consecutive SBFD symbols, that are not SS/PBCH block symbols, starting from the first symbol provided by startingSymbolIndex, with a length equal to or larger than the number of symbols provided by nrofsymbols. if the valid symbol type for the PUCCH transmission is determined as non-SBFD symbol, the UE shall only consider slots containing consecutive non-SBFD symbols, that are not DL symbols indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided or SS/PBCH block symbols, starting from the first symbol provided by startingSymbolIndex, with a length equal to or larger than the number of symbols provided by nrofsymbols.

Agreement

Adopt the following TP in principle to Clause 6.1.7, TS 38.214.

6.1.7 UE procedure for determining time domain windows for bundling DM-RS <omitted text> Events which cause power consistency and phase continuity not to be maintained across PUSCH transmissions of PUSCH repetition type A scheduled by DCI format 0_1, 0_2 or 0_3, or PUSCH repetition Type A with a configured grant, or PUSCH repetition type B or TB processing over multiple slots, or PUCCH transmissions of PUCCH repetition, within the nominal TDW, are: A downlink slot or downlink reception or downlink monitoring based on tdd-UL-DL-ConfigurationCommon and tdd-UL-DL-ConfigurationDedicated for unpaired spectrum <omitted text> A transition from SBFD to non-SBFD, or transition from non-SBFD to SBFD symbols <omitted text>

Agreement

Adopt the following TPs in principle to Clause 6.3.2.4.1.1, 6.3.2.4.1.2, 6.3.2.4.1.3, 6.3.2.4.1.4 and 6.3.2.4.1.5, TS 38.213.

6.3.2.4.1 UCI encoded by Polar code If the higher layer parameter nrofBitsInUTO-UCI is configured, the procedures in this clause and the clauses it refers to apply by replacing CG-UCI with UTO-UCI in all the notations and texts, when applicable. 6.3.2.4.1.1 HARQ-ACK For HARQ-ACK transmission on PUSCH not using repetition type B with UL-SCH and if numberOfSlotsTBoMS is not present in the resource allocation table, or if numberOfSlotsTBoMS is present in the resource allocation table and the value of numberOfSlotsTBoMS in the row indicated by the Time domain resource assignment field in DCI is equal to 1, the number of coded modulation symbols per layer for HARQ-ACK transmission, denoted as , is determined as follows: where … - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> For HARQ-ACK transmission on PUSCH without UL-SCH, the number of coded modulation symbols per layer for HARQ-ACK transmission, denoted as , is determined as follows: where <omitted text> - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> 6.3.2.4.1.2 CSI part 1 For CSI part 1 transmission on PUSCH not using repetition type B with UL-SCH and if numberOfSlotsTBoMS is not present in the resource allocation table, or if numberOfSlotsTBoMS is present in the resource allocation table and the value of numberOfSlotsTBoMS in the row indicated by the Time domain resource assignment field in DCI is equal to 1, the number of coded modulation symbols per layer for CSI part 1 transmission, denoted as , is determined as follows: where … - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> For CSI part 1 transmission on PUSCH without UL-SCH, the number of coded modulation symbols per layer for CSI part 1 transmission, denoted as , is determined as follows: if there is CSI part 2 to be transmitted on the PUSCH, else end if where <omitted text> - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> 6.3.2.4.1.3 CSI part 2 For CSI part 2 transmission on PUSCH not using repetition type B with UL-SCH and if numberOfSlotsTBoMS is not present in the resource allocation table, or if numberOfSlotsTBoMS is present in the resource allocation table and the value of numberOfSlotsTBoMS in the row indicated by the Time domain resource assignment field in DCI is equal to 1, the number of coded modulation symbols per layer for CSI part 2 transmission, denoted as , is determined as follows: where <omitted text> - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> For CSI part 2 transmission on PUSCH without UL-SCH, the number of coded modulation symbols per layer for CSI part 2 transmission, denoted as , is determined as follows: where - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> 6.3.2.4.1.4 CG-UCI For CG-UCI transmission on PUSCH with UL-SCH and if numberOfSlotsTBoMS is not present in the resource allocation table, or if numberOfSlotsTBoMS is present in the resource allocation table and the value of numberOfSlotsTBoMS in the row indicated by the Time domain resource assignment field in DCI is equal to 1, the number of coded modulation symbols per layer for CG-UCI transmission, denoted as , is determined as follows: where <omitted text> - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text> 6.3.2.4.1.5 HARQ-ACK and CG-UCI For HARQ-ACK and CG-UCI transmission on PUSCH with UL-SCH and if numberOfSlotsTBoMS is not present in the resource allocation table, or if numberOfSlotsTBoMS is present in the resource allocation table and the value of numberOfSlotsTBoMS in the row indicated by the Time domain resource assignment field in DCI is equal to 1, the number of coded modulation symbols per layer for HARQ-ACK and CG-UCI transmission, denoted as , is determined as follows: where <omitted text> - is the scheduled bandwidth of the PUSCH transmission, expressed as a number of subcarriers; - If the PUSCH transmission is in SBFD symbols, only includes subcarriers of the scheduled bandwidth that are both in the active UL BWP and in the UL sub-band, as described in Clause 6.1.2.2.1 in [6, TS 38.214]; <omitted text>

Agreement

Adopt the following TP to section 5.2.2.6, TS 38.214

5.2.2.6 SRS-RSRP measurement resource <Unchanged parts omitted> For SRS-RSRP measurement resource configuration, the number of SRS antenna ports is 1.

R1-2509468	Summary #1 of CLI handling	Moderator (Huawei)

R1-2509470	Summary#1 on SBFD random access operation	Moderator (Huawei)

R1-2508660	Summary #1 of SBFD TX/RX/measurement procedures	Moderator (Xiaomi)

R1-2508661	Summary #2 of SBFD TX/RX/measurement procedures	Moderator (Xiaomi)

R1-2508373	Remaining issues on SBFD	Spreadtrum, UNISOC

R1-2508406	Maintenance on evolution of NR duplex operation: SBFD	vivo

R1-2508504	Maintenance of Rel-19 SBFD	Huawei, HiSilicon

R1-2508540	Maintenance on SBFD procedure	NEC

R1-2508571	Maintenance on SBFD	CATT

R1-2508617	Remaining issues on SBFD Tx/Rx/measurement procedures	Fraunhofer HHI, Fraunhofer IIS

R1-2508659	Maintenance on Rel-19 SBFD operation	Xiaomi

R1-2508692	Discussion on maintenance of SBFD	ZTE Corporation, Sanechips

R1-2508706	Maintenance on NR duplex operation	OPPO

R1-2508777	Remaining issues on NR duplex operation	Samsung

R1-2508869	Maintenance on Rel-19 SBFD operations	InterDigital, Inc.

R1-2508892	Remaining issues on SBFD	LG Electronics

R1-2508923	Remaining issues on SBFD operation	Fujitsu

R1-2508960	Maintenance on SBFD	ETRI, Huawei, InterDigital Inc., Samsung

R1-2509010	Maintenance of SBFD	Nokia, Nokia Shanghai Bell

R1-2509030	Maintenance on evolution of NR duplex operation	Ofinno

R1-2509060	Maintenance on SBFD	Sharp

R1-2509201	Maintenance for NR duplex evolution	Qualcomm Incorporated

R1-2509258	Maintenance on Evolution of NR duplex operation: Sub-band full duplex (SBFD)	NTT DOCOMO, INC.

R1-2509306	Maintenance on SBFD TX/RX/measurement procedures	ITRI

R1-2509310	Remaining issues on SBFD	ASUSTeK

R1-2509381	Maintenance on SBFD operation	WILUS Inc.

R1-2509403	Maintenance on Subband Full Duplex	Ericsson

R1-2509435	Maintenance on NR duplex Operation	Google

Maintenance on Solutions for Ambient IoT (Internet of Things) in NR

Note: Maximum one contribution.

[123-R19-A-IoT] Email discussion on A-IoT – Jingwen (CMCC)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509447	Session Notes of AI 8.4	Ad-Hoc Chair (NTT DOCOMO, INC.)

R1-2508407	Discussion on potential overlapping between TDMed Msg1 transmissions	vivo

R1-2508442	Maintenance on Rel-19 Ambient IoT	CMCC

R1-2508503	Maintenance on Rel-19 Ambient IoT	Huawei, HiSilicon

R1-2508541	Maintenance on Solutions for Ambient IoT in NR	NEC

R1-2508572	Remaining issues on Rel-19 A-IoT	CATT

R1-2508662	Discussion on remaining issues for Ambient IoT in NR	Xiaomi

R1-2508709	Maintenance on Rel-19 Ambient IoT	OPPO

R1-2508778	Maintenance issues on Rel-19 A-IoT	Samsung

R1-2508813	Discussion on remaining issues of Rel-19 Ambient IoT	ZTE Corporation, Sanechips

R1-2508893	Maintenance on Rel-19 Ambient IoT	LG Electronics

R1-2508996	Rel-19 AIoT (Ambient_IoT_Solutions) maintenance	Nokia

R1-2509024	Maintenance of AIoT	Ofinno

R1-2509118	Maintenance of Rel-19 Ambient IoT	InterDigital, Inc.

R1-2509202	Maintenance on Ambient IoT	Qualcomm Incorporated

R1-2509259	Maintenance on solutions for Ambient IoT in NR	NTT DOCOMO, INC.

Maintenance on Enhancements of network energy savings for NR

Note: Maximum one contribution per company/organization/university. For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

On-demand SSB SCell operation

On-demand SIB1 for idle/inactive mode UEs

Adaptation of common signal/channel transmissions

[123-R19-NES] Email discussion on NES– Ajit (Ericsson)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509443	Session Notes of AI 8.5	Ad-Hoc Chair (Ericsson)

R1-2508895	Summary #1 of on-demand SSB for NES	Moderator (LG Electronics)

R1-2508896	Summary #2 of on-demand SSB for NES	Moderator (LG Electronics)

R1-2509165	Summary#1 of R19 maintenance for adaptation of common signalling	Moderator(Ericsson)

R1-2509166	Summary#2 of R19 maintenance for adaptation of common signalling	Moderator(Ericsson)

R1-2508408	Maintenance on enhancements of network energy savings for NR	vivo

R1-2508493	Maintenance on Rel-19 Network Energy Savings	Huawei, HiSilicon

R1-2508522	Maintenance on Enhancements of network energy savings	Nokia, Nokia Shanghai Bell

R1-2508573	Maintenance on enhancements of network energy savings for NR	CATT

R1-2508701	Maintenance on enhancements of network energy savings for NR	OPPO

R1-2508779	Maintenance on Enhancements of network energy savings for NR	Samsung

R1-2508814	Discussion on remaining issues of Rel-19 NES	ZTE Corporation, Sanechips

R1-2508894	Remaining issues on enhancements of NES for NR	LG Electronics

R1-2508941	Maintenance for Network Energy Saving	Google

R1-2509025	Maintenance of Enhancements of NES	Ofinno

R1-2509082	Remaining issues on Rel-19 NES	Apple

R1-2509156	Maintenance on enhancements of network energy savings for NR	MediaTek Inc.

R1-2509167	Final summary of R19 maintenance for adaptation of common signalling	Moderator(Ericsson)

R1-2509168	List of RAN1 agreements for Rel-19 NES WI	Rapporteur(Ericsson)

R1-2509172	Maintenance on enhancements of network energy savings for NR	Sharp

R1-2509203	Maintenance on network energy savings for NR	Qualcomm Incorporated

R1-2509260	Maintenance on enhancements of network energy savings for NR	NTT DOCOMO, INC.

R1-2509311	Remaining issues on OD-SSB	ASUSTeK

R1-2509416	Maintenance for Rel-19 NES	Ericsson

Maintenance on Low-power wake-up signal and receiver for NR (LP-WUS/WUR)

Note: Maximum one contribution per company/organization/university. For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

LP-WUS and LP-SS design

LP-WUS operation in IDLE/INACTIVE modes

LP-WUS operation in CONNECTED modes

[123-R19-LP-WUS] Email discussion on LP-WUS – Xueming (vivo)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

Adopt the following TP to section 7.4.4.1.1, TS 38.211 for alignment.

7.4.4.1.1	Generation of

=============================== Unchanged Text Omitted =========================

The root sequence number is configured by the higher-layer parameter root1 or root2 in lpwus-OverlaidSeqRoots, where root1 is used for the root sequence number when is 0. Otherwise, root2 is used. The cyclic shift is given by:

is obtained as entry of the root sequence numbers configured by the higher-layer parameter XXX and the cyclic shift is given by

where

-	is the number of sequences configured by the higher-layer parameter XXX lpwus-OverlaidSeqNum or lpwus-OverlaidSeqNum-SCS-60kHz or lpwus-OverlaidSeqNum-SCS-120kHz

- is 2 when root2 is configured in lpwus-OverlaidSeqRoots. Otherwise, is 1.

-	is the number of root sequence numbers configured by the higher-layer parameter XXX

========================== End of TP#1 =======================================

Agreement

Adopt the following TP to section 10.4C and 10.4D, TS 38.213 for alignment.

----------------------- Start of Text proposal on 3GPP TS 38.213 V19.1.0-----------------------

10.4C	PDCCH monitoring activation by WUS in RRC_IDLE/RRC_INACTIVE

A UE configured with DRX mode operation and operating in the RRC_IDLE or RRC_INACTIVE state can be provided for LPSS/WUS reception

-	a number of OOK symbols per OFDM symbol, a first RB configured by lpwus-LPSS-StartRB, and an overlaid OFDM sequence per OOK symbol for LPSS reception, and an EPRE ratio relative to SS/PBCH blocks [4, TS 38.211],

-	a number of OOK symbols per OFDM symbol, the first RB, and one or more overlaid OFDM sequences per OOK symbol for WUS reception, and an EPRE ratio relative to SS/PBCH blocks [4, TS 38.211], and

--------------------------------------------unchanged is omitted--------------------------------------------

10.4D	PDCCH monitoring activation by WUS in RRC_CONNECTED

A UE configured with DRX mode operation and operating in the RRC_CONNECTED state can be provided for WUS reception on the primary cell of a cell group

-	a number of OOK symbols per OFDM symbol, a first RB configured by lpwus-StartRB, and overlaid OFDM sequences per OOK symbol for WUS reception [4, TS 38.211], and

-	a number of codepoints provided for the UE by the WUS [6, TS 38.212], by WUS-codepointCONNECTED

----------------------- End of Text proposal on 3GPP TS 38.213 V19.1.0-----------------------

Conclusion

For all the collision cases when MR is in active time and when MR is performing transmission or reception outside active time, as covered by the agreements below, a UE may not monitor LP-WUS. No specification changes.

Agreement (Made in RAN1#121)

As the reply to RAN2 LS in R1-2503616, RAN1 assumes that UE is not able to operate LR and MR simultaneously in Rel-19. RAN1 understanding is that the terminology of LR and MR operations are for discussion purpose and will not be specified

LR operation is the UE operation for LP-WUS monitoring

MR operation is the UE operation for all other NR signals/channels transmissions/receptions in connected mode

Agreement

Adopt the following TP to section 5.1.6.1 and 5.2.2.5, TS 38.214 in principle.

----------------------------------------- Text proposal for TS38.214-j00 clause 5.1.6.1-------------------------------- 5.1.6.1 CSI-RS reception procedure <omitted text> If the UE is configured with DRX and, - if the UE is configured to monitor DCI format 2_6 or WUS and configured by higher layer parameter ps-TransmitOtherPeriodicCSI or lpwus-TransmitOtherPeriodicCSI to report CSI with the higher layer parameter reportConfigType set to 'periodic' and reportQuantity set to quantities other than 'cri-RSRP', 'cri-RSRP-Index', 'ssb-Index-RSRP' and 'ssb-Index-RSRP-Index' when drx-onDurationTimer in DRX-Config [or lpwus_PDCCHMonitoringTimer in [XYZxxx]] is not started, the most recent CSI measurement occasion occurs in DRX active time or during the time duration indicated by drx-onDurationTimer in DRX-Config also outside DRX active time for CSI to be reported; - if the UE is configured to monitor DCI format 2_6 or WUS and configured by higher layer parameter ps-TransmitPeriodicL1-RSRP or lpwus-TransmitPeriodicL1-RSRP to report L1-RSRP with the higher layer parameter reportConfigType set to 'periodic' and reportQuantity set to 'cri-RSRP' or 'cri-RSRP-Index' when drx-onDurationTimer in DRX-Config [or lpwus_PDCCHMonitoringTimer [in XYZxxx]] is not started, the most recent CSI measurement occasion occurs in DRX active time or during the time duration indicated by drx-onDurationTimer in DRX-Config also outside DRX active time for CSI to be reported; - otherwise, the most recent CSI measurement occasion occurs in DRX active time for CSI to be reported. --------------------------------------------- End of Text proposal for TS38.214 sec 5.1.6.1--------------------------- ------------------------------------------ Text proposal for TS38.214-j00 clause5.2.2.5 ------------------------------ 5.2.2.5 CSI reference resource definition <omitted text> When the UE is configured to monitor DCI format 2_6 or WUS, - if the UE configured by higher layer parameter ps-TransmitOtherPeriodicCSI or lpwus-TransmitOtherPeriodicCSI to report CSI with the higher layer parameter reportConfigType set to 'periodic' and reportQuantity set to quantities other than 'cri-RSRP', 'ssb-Index-RSRP', 'cri-RSRP- Index', and 'ssb-Index-RSRP- Index ' when drx-onDurationTimer [or lpwus_PDCCHMonitoringTimer] is not started, the UE shall report CSI with the reportQuantity not set to ‘ssb-Index-SINR’ or ‘ssb-Index-SINR-Index’ during the time duration indicated by drx-onDurationTimer in DRX-Config also outside active time according to the procedure described in Clause 5.2.1.4 if receiving at least one CSI-RS transmission occasion for channel measurement and CSI-RS and/or CSI-IM occasion for interference measurement during the time duration indicated by drx-onDurationTimer in DRX-Config outside DRX active time or in DRX Active Time no later than CSI reference resource and drops the report otherwise; - if the UE is configured with a CSI report configuration containing a list of sub-configurations provided by csi-ReportSubConfigToAddModList, and if the UE configured by higher layer parameter ps-TransmitOtherPeriodicCSI or lpwus-TransmitOtherPeriodicCSI to report CSI with the higher layer parameter reportConfigType set to 'periodic' and reportQuantity set to quantities other than 'cri-RSRP', 'ssb-Index-RSRP', 'cri-RSRP- Index', and 'ssb-Index-RSRP- Index' when drx-onDurationTimer [or lpwus PDCCHMonitoringTimer] is not started, UE shall report a CSI report including one or more sub-reports only during the time duration indicated by drx-onDurationTimer in DRX-Config also outside active time according to the procedure described in Clause 5.2.1.4 if receiving at least one CSI-RS transmission occasion for channel measurement and CSI-RS and/or CSI-IM occasion for interference measurement during the time duration indicated by drx-onDurationTimer in DRX-Config outside DRX active time or in DRX Active Time, per sub-configuration, no later than CSI reference resource and drops the report otherwise, where the sub-configuration is the configured one for P-CSI reporting; - if the UE configured by higher layer parameter ps-TransmitPeriodicL1-RSRP or lpwus-TransmitOtherPeriodicL1-RSRP to report L1-RSRP with the higher layer parameter reportConfigType set to 'periodic' and reportQuantity set to 'cri-RSRP', 'ssb-Index-RSRP', 'cri-RSRP- Index', or 'ssb-Index-RSRP- Index' when drx-onDurationTimer [or lpwus_PDCCHMonitoringTimer] is not started, the UE shall report L1-RSRP during the time duration indicated by drx-onDurationTimer in DRX-Config also outside active time according to the procedure described in clause 5.2.1.4 and when reportQuantity set to 'cri-RSRP' or 'cri-RSRP- Index' if receiving at least one CSI-RS transmission occasion for channel measurement during the time duration indicated by drx-onDurationTimer in DRX-Config outside DRX active time or in DRX Active Time no later than CSI reference resource and drops the report otherwise. --------------------------------------- End of Text proposal for TS38.214 clause 5.2.2.5------------------------------

Conclusion

For Both RRC connected mode and idle/inactive mode, Regarding the minimum gap between two LP-WUS MOs,

No explicit gap is introduced between two consecutive LP-WUS nominal MOs.

Agreement

Adopt the following TP for Section 10.4C in TS 38.213 in principle.

10.4C PDCCH monitoring activation by WUS in RRC_IDLE/RRC_INACTIVE <unchanged text omitted> A UE assumes that WUS occasions occur with a periodicity equal to the I-DRX cycle in the RRC_IDLE/RRC_INACTIVE state [17, TS 38.304]. The UE determines WUS occasions associated with a paging occasion based on PO-to-LO association. A first reference frame of a WUS occasion starts a number of frames prior to the first of a number of paging frames associated with the WUS occasion [17, TS 38.304]. Each number of frames is provided by LO-FrameOffsets. The first WUS monitoring occasion of a WUS occasion starts at an offset provided by offset_firstMO_withinLO relative to the start of the first reference frame. If multiple values for the number of frames provided by LO-FrameOffsets are larger than or equal to the value of XYZ, the UE monitors WUS starting at a WUS occasion corresponding to the smallest of the multiple values. If all values for the number of frames provided by LO-FrameOffsets are smaller than the value of XYZ, the UE monitors PDCCH according to Type2-PDCCH CSS sets associated with the paging occasion and does not monitor WUS. A paging occasion associated with a WUS occasion has index where is a number of paging occasions associated with a WUS occasion, , , , and are defined in [17, TS 38.304], and is defined in clause 7.1 of [17, TS 38.304]. If a number of subgroups per paging occasion, provided by subgroupNumber-PO-WUS, is , the codepoint for the subgroup index in a PO is, and the codepoint for all subgroups in the PO is; otherwise, the codepoint for the PO is If, in a WUS monitoring occasion, a UE determines a codepoint associated with the UE [17, TS 38.304], the UE performs PDCCH monitoring according to Type2-PDCCH CSS sets for the paging occasion associated with the WUS monitoring occasion when a time from the end of the WUS reception to the start of the PDCCH monitoring occasion is not smaller than the value of XYZ; otherwise, the UE is not required to perform the PDCCH monitoring. The UE may also perform PDCCH monitoring for Type2A-PDCCH CSS sets for DCI format 2_7, if provided. <unchanged text omitted>

R1-2509084	Summary #1 on maintenance for LP-WUS operation in IDLE/INACTIVE mode	Moderator (Apple)

R1-2509085	Summary #2 on maintenance for LP-WUS operation in IDLE/INACTIVE mode	Moderator (Apple)

R1-2508410	Summary #1 on remaining issues of LP-WUS/LP-SS design and LP-WUS operation for connected mode	Moderator (vivo)

R1-2508411	Summary #2 on remaining issues of LP-WUS/LP-SS design and LP-WUS operation for connected mode	Moderator (vivo)

R1-2508361	Maintenance of LP-WUS operation	Nokia

R1-2508409	Maintenance on Low-power wake-up signal and receiver for NR	vivo

R1-2508443	Discussion on maintenance issue on Low-power wake-up signal and receiver for NR (LP-WUS/WUR)	CMCC

R1-2508486	Maintenance on LP-WUS/WUR	Huawei, HiSilicon

R1-2508508	Maintenance on low-power wake-up signal and receiver for NR	Ericsson

R1-2508574	Remaining issues on LP-WUS	CATT

R1-2508645	Maintenance on LP-WUS operation	InterDigital, Inc.

R1-2508663	Remaining issues on LP-WUS operation in connected mode	Xiaomi

R1-2508712	Remaining issues on LP-WUS/WUR	OPPO

R1-2508780	Maintenance on Low-power wake-up signal and receiver for NR	Samsung

R1-2508815	Discussion on remaining issues of Rel-19 LP WUS	ZTE Corporation, Sanechips

R1-2508897	Maintenance on Low-power wake-up signal and receiver for NR	LG Electronics

R1-2509083	Maintenance on R19 LP-WUS/WUR	Apple

R1-2509173	Maintenance on Low-power wake-up signal and receiver for NR	Sharp

R1-2509204	Maintenance on Low-power wake-up signal and receiver for NR	Qualcomm Incorporated

R1-2509261	Maintenance on LP-WUS/WUR	NTT DOCOMO, INC.

Maintenance on Non-Terrestrial Networks (NTN) for NR Phase 3, Internet of Things (IoT) Phase 3, and IoT-NTN TDD mode

[123-R19-NTN] Email discussion on Rel-19 NTN enhancement – Mohamed (Thales)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509448	Session Notes of AI 8.7	Ad-Hoc Chair (Ericsson)

Maintenance for Rel-19 NR NTN

Note: Maximum one contribution per company/organization/university for R_NTN_Ph3, potential RAN1 impact from NR_NTN_Ku_bands and NR_IoT_NTN_req_test_enh.

Note: For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

NR_NTN_Ph3

RAN1 impact from NR_NTN_Ku_bands and NR_IoT_NTN_req_test_enh

R1-2508412	Maintenance on Rel-19 NR NTN	vivo

R1-2508487	Maintenance for Rel-19 NR NTN	Huawei, HiSilicon

R1-2508599	Maintenance for Rel-19 NR NTN	CATT

R1-2508664	Maintenance for Rel-19 NR NTN	Xiaomi

R1-2508702	Maintenance for Rel-19 NR NTN	OPPO

R1-2508781	Maintenance for Rel-19 NR NTN	Samsung

R1-2508845	Maintenance for Rel-19 NR-NTN	Ericsson

R1-2508850	Remaining issues on Rel-19 NR NTN	ZTE Corporation, Sanechips

R1-2509006	Discussion on Maintenance for Rel-19 NR NTN	Nokia

R1-2509205	Maintenance for Rel-19 NR NTN	Qualcomm Incorporated

R1-2509262	Maintenance of R19 NR-NTN	NTT DOCOMO, INC.

Maintenance for Rel-19 IoT NTN

Note: Maximum one contribution per company/organization/university for IoT_NTN_Ph3 and IoT_NTN_TDD

Note: For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

IoT_NTN_Ph3

IoT_NTN_TDD

R1-2509207	Feature Lead Summary #1 on maintenance for IoT NTN TDD mode	Moderator (Qualcomm Incorporated)

R1-2508413	Maintenance on Rel-19 IoT-NTN	vivo

R1-2508480	Maintenance for Rel19 IoT-NTN	Nokia, Nokia Shanghai Bell

R1-2508488	Maintenance for IoT NTN Phase 3 and TDD mode	Huawei, HiSilicon

R1-2508600	Maintenance for Rel-19 IoT NTN	CATT

R1-2508665	Maintenance for Rel-19 IoT NTN	Xiaomi

R1-2508703	Maintenance for Rel-19 IoT NTN	OPPO

R1-2508782	Maintenance for Rel-19 IoT NTN	Samsung

R1-2508851	Remaining issues on Rel-19 IoT NTN	ZTE Corporation, Sanechips

R1-2508867	Maintenance for Rel-19 IoT-NTN	Ericsson

R1-2509063	FL Summary #1 for Rel-19 IoT-NTN maintenance	Sony

R1-2509064	FL Summary #2 for Rel-19 IoT-NTN maintenance	Sony

R1-2509065	Final FL summary for Rel-19 IoT-NTN maintenance	Sony

R1-2509135	On scheduling enhancement to IoT NTN TDD	Nordic Semiconductor ASA

R1-2509206	Maintenance for Rel-19 IOT NTN	Qualcomm Incorporated

Maintenance on others

Note: Maximum one contribution per company/organization/university, including MCE Phase 3, LB-CA, 7-24GHz for NR, ISAC, Mobility Phase 4, XR Phase 3, LTE-based 5G broadcast Phase 2 and endorsed R19 TEI proposals.

Note: For more efficient review, please use/fill the WI code field when requesting tdoc numbers according to the proposals for individual items, if any. Maximum one contribution per WI code.

Maintenance on others will be discussed in RAN1 adhoc2 session (chaired by Hiroki).

[123-R19-Others] To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Hiroki

R1-2509449	Session Notes of AI 8.8	Ad-Hoc Chair (NTT DOCOMO, INC.)

R1-2508357	Correction for parameter names for LBCA	Nokia

R1-2508414	Maintenance on Low band carrier aggregation via switching	vivo

R1-2508463	Maintenance of NR mobility enhancements Phase 4	Ericsson

R1-2508505	Measurements related enhancements for LTM	Huawei, HiSilicon

R1-2508521	Maintenance of Rel-19 low band CA via switching	Spreadtrum, UNISOC

R1-2508531	Maintenance on Mobility Phase 4	ZTE Corporation, Sanechips

R1-2508575	Maintenance on measurements related enhancements for LTM	CATT

R1-2508666	Remaining issues on low band CA via switching	Xiaomi

R1-2508708	Maintenance on low-band CA via switching	OPPO

R1-2508783	Maintenance on other Rel-19 topics	Samsung

R1-2508878	Study on 7 - 24 GHz frequency range for NR	Spark NZ Ltd

R1-2508898	Remaining issues on low band CA operation via switching for Rel-19	LG Electronics

R1-2508953	Maintenance on the measurements for LTM	Lenovo

R1-2509031	Maintenance on mobility enhancement phase 4	Ofinno

R1-2509086	FL Summary #1 of NR Mobility enhancement Phase 4	Moderator (Apple)

R1-2509087	FL Summary #2 of NR Mobility enhancement Phase 4	Moderator (Apple)

R1-2509088	FL summary #1 of Low band carrier aggregation via switching	Moderator (Apple)

R1-2509089	FL summary #2 of Low band carrier aggregation via switching	Moderator (Apple)

R1-2509125	Text Proposal for updated Rel-19 ISAC Calibration Results	T-Mobile USA, Ericsson, Xiaomi

R1-2509126	Revised ISAC channel model calibration results	Moderators (T-Mobile USA, Xiaomi)

R1-2509130	Discussion on low-band CA with switching	Ofinno

R1-2509149	Multi-carrier enhancements for NR Phase 3	MediaTek Inc.

R1-2509208	Correction on combination of carrier-switching SRS and UL carrier aggregation [Simul_SRSCS]	Qualcomm Incorporated

R1-2509209	Maitenance on Low-band CA via switching	Qualcomm Incorporated

R1-2509244	Maintenance on Low band carrier aggregation via switching	ZTE Corporation, Sanechips

R1-2509245	TP for ISAC channel modeling	ZTE Corporation, Sanechips

R1-2509247	Maintenance on UL Tx switching for TEI19	ZTE Corporation, Sanechips

R1-2509248	Maintenance on Multi-carrier enhancements for NR phase 3	ZTE Corporation, Sanechips

R1-2509318	Maintenance on ISAC Channel Model	Ericsson

R1-2509340	Feature lead summary #1 on multi-carrier enhancements	Moderator (Xiaomi)

R1-2509341	Feature lead summary #2 on multi-carrier enhancements	Moderator (Xiaomi)

R1-2509357	Maintenance on Mobility Phase 4	Google

R1-2509415	Maintenance for 7—24 GHz channel model	Ericsson

R1-2509428	Maintenance of Rel-19 multi-carrier enhancements	Huawei, HiSilicon

Rel-19 UE Features

The maximum number of contributions per company/organization/university is limited to 1 per agenda item unless stated otherwise.

[123-R19-UE_features] Email discussion on Rel-19 UE features – Ralf (AT&T), Naoya (DOCOMO)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

R1-2509494 is endorsed for updating RAN1 UE features list for Rel-19 NR.

Agreement

Draft LS R1-2509495 is endorsed in principle.

Agreement

Final LS R1-2509496 is endorsed.

R1-2509495	DRAFT LS on updated Rel-19 RAN1 UE features lists for NR after RAN1#123 Wednesday

R1-2509494	Updated RAN1 UE features list for Rel-19 NR after RAN1 #123 Wednesday

UE features Batch A

Note: Maximum one contribution per company/organization/university for NTN_Ph3, IoT_NTN_Ph3, IoT_NTN_TDD, and TEI19 with [Common_PDCCH_rep_TN])

Note: For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

NTN_Ph3

IoT_NTN_Ph3

IoT_NTN_TDD

TEI19 with [Common_PDCCH_rep_TN])

R1-2509436	Session Notes of AI 9.1: UE features Batch A (NR_NTN_Ph3, IoT_NTN_Ph3, IoT_NTN_TDD, TEI19 with [Common_PDCCH_rep_TN])	Ad-Hoc Chair (NTT DOCOMO, INC.)

R1-2508353	UE features Batch A (NTN and TEI19)	Nokia

R1-2508415	Remaining issues of UE features for NR_NTN_Ph3 and TEI (Common_PDCCH_rep_TN)	vivo

R1-2508482	Remaining issues for Rel-19 WIs in UE features Batch A	Huawei, HiSilicon

R1-2508576	Discussion on UE features for NTN	CATT

R1-2508650	UE features Batch A (NR-NTN Phase 3 and TEI19)	Ericsson

R1-2508667	UE features for NTN for NR Phase 3	Xiaomi

R1-2508784	UE features for batch A	Samsung

R1-2508852	Discussion on the UE features Batch A	ZTE Corporation, Sanechips

R1-2508961	Discussion on UE features for NR NTN Phase 3	ETRI

R1-2509090	Views on UE features Batch A	Apple

R1-2509162	Discussions on UE Features for NR NTN Ph3	MediaTek Inc.

R1-2509192	UE features for Batch A	OPPO (chongqing) Intelligence

R1-2509210	UE features for NTN	Qualcomm Incorporated

R1-2509263	Discussion on UE features Batch A	NTT DOCOMO, INC.

UE features Batch B

Note: Maximum one contribution per company/organization/university for NR_duplex_evo, NR_LPWUS, XR phase 3, NR_MC_enh2, and NR_LBCA

Note: For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

UE f NR_duplex_evo

NR_LPWUS

XR phase 3

NR_MC_enh2

NR_LBCA

R1-2509437	Session Notes of AI 9.2: UE features Batch B (NR_duplex_evo, NR_LPWUS, NR_XR_Ph3, NR_MC_enh2, NR_LBCA_Sw)	Ad-Hoc Chair (NTT DOCOMO, INC.)

R1-2508354	UE features Batch B (SBFD and MCE)	Nokia

R1-2508416	Remaining issues of UE features for NR_duplex_evo and NR_MC_enh2	vivo

R1-2508483	Remaining issues for Rel-19 WIs in UE features Batch B	Huawei, HiSilicon

R1-2508509	UE features Batch B	Ericsson

R1-2508577	UE features for SBFD	CATT

R1-2508668	UE features for Rel-19 SBFD operation, multi-carrier enhancements and low band CA	Xiaomi

R1-2508700	UE features for Batch B	OPPO

R1-2508785	UE features for SBFD and MCE Phase 3	Samsung

R1-2508786	UE features for MCE Phase 3	Samsung

(Withdrawn)

R1-2508816	Discussion on UE feature Batch B	ZTE Corporation, Sanechips

R1-2508924	UE features for Msg.3 repetition in SBFD operation	Fujitsu

R1-2509032	Discussion on UE features for evolution of NR duplex operation: SBFD	Ofinno

R1-2509211	UE features Batch B	Qualcomm Incorporated

R1-2509264	Discussion on UE features Batch B	NTT DOCOMO, INC.

UE features Batch C

Note: Maximum one contribution per company/organization/university for NR_AIML_air, NR_MIMO_Ph5, Netw_Energy_NR_enh, NR_Mob_Ph4, LTE_terr_bcast_Ph2 and TEI19 with other than [Common_PDCCH_rep_TN]

Note:For efficient review, please use the following sections in your contribution corresponding to the maintenance issues, if any:

NR_AIML_air

NR_MIMO_Ph5

Netw_Energy_NR_enh

NR_Mob_Ph4

LTE_terr_bcast_Ph2

TEI19 with other than [Common_PDCCH_rep_TN]

R1-2509438	Session Notes of AI 9.3: UE features Batch C (NR_AIML_air, NR_MIMO_Ph5, Netw_Energy_NR_enh, NR_Mob_Ph4, LTE_terr_bcast_Ph2 and TEI19 with other than [Common_PDCCH_rep_TN])	Ad-Hoc Chair (AT&T)

R1-2508355	UE features Batch C (AIML, MIMO, MobEnh)	Nokia

R1-2508417	Remaining issues of UE features for AI/ML for NR Air Interface	vivo

R1-2508484	Remaining issues for Rel-19 WIs in UE features Batch C	Huawei, HiSilicon

R1-2508532	Discussion on UE features Batch C	ZTE Corporation, Sanechips

R1-2508578	Remianing issues on UE features for NR MIMO Phase 5	CATT

R1-2508635	Summary of UE Features Batch C	Moderator (AT&T)

R1-2508669	UE features for Rel-19 AI based CSI prediction	Xiaomi

R1-2508699	UE features for Batch C	OPPO

R1-2508748	Discussion on UE features for AI/ML for NR Air Interface	LG Electronics

R1-2508787	UE features for batch C	Samsung

R1-2509091	Views on UE features Batch C	Apple

R1-2509180	On UE features Batch C	Ericsson

R1-2509212	UE features Batch C	Qualcomm Incorporated

R1-2509265	Discussion on UE features Batch C	NTT DOCOMO, INC.

Release 20 NR

The maximum number of contributions per company/organization/university is limited to 1 per agenda item unless stated otherwise.

Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface enhancements

Please refer to RP-252445 for detailed scope of the WI.

[123-R20-AI/ML] Email discussion on Rel-20 AI/ML – Chenxi (Qualcomm)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509444	Session Notes of AI 10.1	Ad-Hoc Chair (Ericsson)

CSI spatial/frequency compression without temporal aspects (“Case 0”)

R1-2509419	Inference Aspects Of AI/ML Assisted CS Compression in Spatial/Frequency Domain Without Temporal Aspects	TOYOTA Info Technology Center

Inference related aspects

Including target CSI type, measurement and report configuration, CQI RI determination, payload determination, quantization configuration codebook, UCI mapping, CSI processing criteria and timeline, priority rules for CSI reports.

R1-2509214	FL summary 1 on inference related aspects of CSI feedback via two-sided model	Moderator (Qualcomm Incorporated)

R1-2509215	FL summary 2 on inference related aspects of CSI feedback via two-sided model	Moderator (Qualcomm Incorporated)

R1-2509216	FL summary 3 on inference related aspects of CSI feedback via two-sided model	Moderator (Qualcomm Incorporated)

R1-2509217	FL summary 4 on inference related aspects of CSI feedback via two-sided model	Moderator (Qualcomm Incorporated)

R1-2508325	Discussion on inference related aspects for CSI spatial/frequency compression without temporal aspects (“Case 0”)	FUTUREWEI

R1-2508344	AI/ML CSI Spatial/Frequency Compression: Inference Aspects	InterDigital, Inc.

R1-2508362	Inference related aspects of AI/ML for CSI compression	Ericsson

R1-2508374	Discussion on AIML for CSI compression inference related aspects	Spreadtrum, UNISOC

R1-2508418	Discussion on inference related aspects for CSI compression	vivo

R1-2508444	Discussion on inference related aspects of CSI compression	CMCC

R1-2508494	Discussion on Inference related aspects for CSI compression	Huawei, HiSilicon

R1-2508536	Discussion on interference related aspects for CSI compression	TCL

R1-2508561	Discussion on inference aspects of CSI compression	NEC

R1-2508583	Inference related aspects for AI/ML CSI compression	CATT

R1-2508601	Discussion on inference related aspects of AI/ML for CSI compression	China Telecom

R1-2508670	Discussion on inference related aspects of two-sided AI/ML model based CSI feedback	Xiaomi

R1-2508693	Discussion on inference related aspects of CSI compression	ZTE Corporation, Sanechips

R1-2508713	Inference related aspects for AI/ML CSI compression	OPPO

R1-2508749	Discussion on inference related aspects for CSI compression	LG Electronics

R1-2508762	Discussion on inference related aspects for CSI compression	KT Corp.

R1-2508788	Views on inference related aspects of CSI compression	Samsung

R1-2508876	Discussions on Inference Related Aspects for CSI Compression	Sharp

R1-2508884	Discussion on inference aspects for AI/ML-based CSI compression	Panasonic

R1-2509459	Discussion on inference aspects for AI/ML-based CSI compression	Panasonic

(Revision of R1-2508884)

R1-2508925	Discussion on inference related aspects in CSI compression with AI/ML	Fujitsu

R1-2508942	Inference for AI/ML based CSI Compression	Google

R1-2508949	CSI Compression: Inference Related Aspects	Nokia

R1-2508954	Inference related aspects for CSI compression	Lenovo

R1-2508962	Discussion on inference related aspects of CSI compression	ETRI

R1-2508985	Inference related aspects for CSI compression	HONOR

R1-2509009	Discussion on inference aspects of CSI compression	KAIST

R1-2509035	Discussion on Inference related aspects for AI CSI compression	Ofinno

R1-2509092	On inference related aspects for AI based CSI spatial/frequency domain compression	Apple

R1-2509150	Inference aspects of AI/ML-based CSI compression	MediaTek Inc.

R1-2509193	Discussion on inference related aspects in AI/ML based CSI compression	Quectel

R1-2509213	Specification of inference aspects of AIML CSI compression	Qualcomm Incorporated

R1-2509249	Discussion on inference related aspects of CSI compression	Transsion Holdings

R1-2509266	Discussion on the inference-related aspects of AI/ML CSI compression	NTT DOCOMO, INC.

R1-2509317	Discussion on Inference related aspects of Case-0 CSI Compression	Rakuten Mobile, Inc

Other aspects

Including NW and UE data collection for training, performance monitoring, as well as model pairing related issues.

R1-2508326	Discussion on other aspects for CSI spatial/frequency compression without temporal aspects (“Case 0”)	FUTUREWEI

R1-2508345	AI/ML CSI Spatial/Frequency Compression: Other Aspects	InterDigital, Inc.

R1-2508375	Discussion on AIML for CSI compression other aspects	Spreadtrum, UNISOC

R1-2508396	Other aspects of AIML for CSI compression	Ericsson

R1-2508419	Discussion on other aspects for CSI compression	vivo

R1-2508445	Discussion on other aspects of CSI compression	CMCC

R1-2508495	Discussion on other aspects for CSI compression	Huawei, HiSilicon

R1-2508537	Discussion on other aspects for CSI compression	TCL

R1-2508547	Discussion on other aspects of CSI compression	NEC

R1-2508584	Other aspects for AI/ML CSI compression	CATT

R1-2508671	Discussion on other aspects of CSI spatial/frequency compression	Xiaomi

R1-2508694	Discussion on other aspects of CSI compression	ZTE Corporation, Sanechips

R1-2508714	Other aspects for AI/ML CSI compression	OPPO

R1-2508750	Discussion on other aspects for CSI compression	LG Electronics

R1-2508763	Discussion on other aspects of CSI compression	KT Corp.

R1-2508789	Views on other aspects of CSI compression	Samsung

R1-2508828	Other Aspects	Tejas Network Limited

R1-2508861	Views on the lifecycle management for AI/ML-based CSI Compression	Southeast University

R1-2508885	Discussion on other aspects for AI/ML-based CSI compression	Panasonic

R1-2508926	Discussion on other aspects of CSI compression	Fujitsu

R1-2508943	Other Aspects for AI/ML based CSI Compression	Google

R1-2508950	CSI Compression: Other Aspects	Nokia

R1-2508955	Other aspects for CSI compression	Lenovo

R1-2508963	Discussion on other aspects of CSI compression	ETRI

R1-2508986	Other aspects for CSI compression	HONOR

R1-2509036	Discussion on other aspects for AI CSI compression	Ofinno

R1-2509051	Views on the lifecycle management for AI/ML-based CSI Compression	Southeast University

R1-2509066	Discussion on performance monitoring for CSI compression	Sony

R1-2509093	On other aspects for AI based CSI spatial/frequency domain compression	Apple

R1-2509151	Other aspects of AI/ML-based CSI compression	MediaTek Inc.

R1-2509183	Discussions on other aspects for NR air interface enhancements	Sharp

R1-2509218	Specification of other aspects of AIML CSI compression	Qualcomm Incorporated

R1-2509267	Discussion on other aspects of AI/ML CSI compression	NTT DOCOMO, INC.

R1-2509319	Discussion on other aspects of AIML-based CSI compression	Rakuten Mobile, Inc

R1-2509367	Discussion on AIML based CSI compression	ASUSTeK

R1-2509418	Other Aspects of AI/ML Assisted CSI Compression	TOYOTA Info Technology Center

Inter-vendor training collaboration for two-sided AI/ML models

Including specification of standardized dataset format/content plus dataset exchange (“Direction A, sub-option 4-1”), as well as RAN4-triggered issues.

R1-2509095	FL summary # 1 for inter-vendor training collaboration	Moderator (Apple)

R1-2509096	FL summary # 2 for inter-vendor training collaboration	Moderator (Apple)

R1-2509097	FL summary # 3 for inter-vendor training collaboration	Moderator (Apple)

R1-2509098	FL summary # 4 for inter-vendor training collaboration	Moderator (Apple)

R1-2508327	Discussion on inter-vendor training collaboration for two-sided AI/ML models	FUTUREWEI

R1-2508346	AI/ML CSI Spatial/Frequency Compression: Inter-vendor Collaboration	InterDigital, Inc.

R1-2508376	Discussion on Inter-vendor training collaboration for two-sided AI/ML models	Spreadtrum, UNISOC

R1-2508397	Inter-vendor training collaboration for two-sided AIML models	Ericsson

R1-2508420	Discussion on inter-vendor training collaboration for two-sided AI/ML models	vivo

R1-2508446	Discussion on inter-vendor training collaboration for CSI compression	CMCC

R1-2508496	Discussion on Inter-vendor training collaboration for two-sided AI/ML models	Huawei, HiSilicon

R1-2508538	Discussion on inter-vendor collaboration for CSI compression	TCL

R1-2508585	Views on inter-vendor training collaboration for CSI compression	CATT

R1-2508602	Discussion on inter-vendor training collaboration for two-sided AI/ML models	China Telecom

R1-2508630	Discussion on Inter-vendor Training Collaboration for two-sided AI/ML models	NEC

R1-2508672	Discussion on inter-vendor training collaboration for two-sided AI/ML models	Xiaomi

R1-2508695	Discussion on inter-vendor training collaboration for two-sided AI/ML models	ZTE Corporation, Sanechips

R1-2508715	Inter-vendor training collaboration for AI/ML CSI compression	OPPO

R1-2508751	Discussion on Inter-vendor training collaboration for two-sided models	LG Electronics

R1-2508764	Discussion on inter-vendor training collaboration aspects for two-sided AI/ML models	KT Corp.

R1-2508790	Views on inter-vendor training collaboration for two-sided AI/ML models	Samsung

R1-2508886	Discussion on inter-vendor training collaboration for two-sided AI/ML models	Panasonic

R1-2508927	Discussion on inter-vendor training collaboration for two-sided AI/ML models	Fujitsu

R1-2508944	Inter-Vendor Collaboration for AI/ML based CSI Compression	Google

R1-2508951	Inter-vendor training collaboration for two-sided AI/ML models	Nokia

R1-2508964	Discussion on inter vendor training collaboration for two-sided AI/ML models	ETRI

R1-2508979	Discussions on Inter-vendor training collaboration	Sharp

R1-2508987	Inter-vendor training collaboration for two-sided CSI compression	HONOR

R1-2509003	Inter-vendor training collaboration for two-sided AI/ML models	Lenovo

R1-2509037	Discussion on inter-vendor training collaboration for two-sided AI/ML models	Ofinno

R1-2509067	Discussion on Inter-Vendor Training Collaboration for Two-Side AI/ML Models	Sony

R1-2509094	On Inter-vendor training collaboration for two sided AI/ML models	Apple

R1-2509152	Inter-vendor training collaboration for two-sided AI/ML models	MediaTek Inc.

R1-2509219	Inter-vendor training collaboration for two-sided CSI compression use case	Qualcomm Incorporated

R1-2509268	Discussion on the inter-vendor training collaborations for two-sided AI/ML models	NTT DOCOMO, INC.

R1-2509374	Discussion on inter-vendor training collaboration for two-sided models	Indian Institute of Tech (M)

R1-2509401	Inter-Vendor Training Collaboration for AI/ML Assisted CSI Compression in Spatial/Frequency Domain Without Temporal Aspects	TOYOTA Info Technology Center

NR MIMO Phase 6

Please refer to RP-252936 for detailed scope of the WI.

[123-R20-MIMO] Email discussion on Rel-20 MIMO – Darcy (MTK)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509445	Session Notes of AI 10.2	Ad-Hoc Chair (Ericsson)

Improvement of SRS capacity and coverage

Including a) Multiple frequency-domain starting positions for SRS repetition, and b) Cross-slot SRS between one U slot and one adjacent S slot.

R1-2508829	Moderator summary on improvement of SRS capacity and coverage: Round1	Moderator (CATT)

R1-2508830	Moderator summary on improvement of SRS capacity and coverage: Round2	Moderator (CATT)

R1-2508831	Moderator summary on improvement of SRS capacity and coverage: Round3	Moderator (CATT)

R1-2508832	Moderator summary on improvement of SRS capacity and coverage: Round4	Moderator (CATT)

R1-2508347	NR MIMO Phase 6: SRS Enhancement	InterDigital, Inc.

R1-2508368	Improvement of SRS capacity and coverage	MediaTek Inc.

R1-2508371	Improvement SRS capacity and coverage	TCL

R1-2508377	Discussion on improvement of SRS capacity and coverage	Spreadtrum, UNISOC

R1-2508421	Discussion on improvement of SRS capacity and coverage	vivo

R1-2508491	Improvement of SRS capacity and coverage	Huawei, HiSilicon

R1-2508525	Discussion on improvement of SRS capacity and coverage	ZTE Corporation, Sanechips

R1-2508553	Discussion on improvement of SRS capacity and coverage	NEC

R1-2508586	Improvement of SRS capacity and coverage	CATT

R1-2508603	Discussion on SRS capacity and coverage improvement	China Telecom

R1-2508673	Discussion on the improvement of SRS capacity and coverage	Xiaomi

R1-2508716	Discussion on enhancement of SRS capacity and coverage for MIMO phase 6	OPPO

R1-2508756	Improvement of SRS capacity and coverage	Tejas Network Limited

R1-2508791	Views on improvement of SRS capacity and coverage	Samsung

R1-2508919	Discussion on improvement of SRS capacity and coverage	Panasonic

R1-2508928	Discussion on improvement of SRS capacity and coverage	Fujitsu

R1-2508956	Improvement of SRS capacity and coverage	Lenovo

R1-2508965	Discussion on improvement of SRS capacity and coverage for NR MIMO Phase 6	ETRI

R1-2508988	Discussion on improvement of SRS capacity and coverage	HONOR

R1-2509011	Improvement of SRS Capacity and Coverage	Nokia

R1-2509014	On Rel-20 improvement of SRS capacity and coverage	Ericsson

R1-2509068	Discussion on improvements of SRS capacity and coverage	Sony

R1-2509099	On Rel-20 MIMO SRS capacity and coverage improvement	Apple

R1-2509220	SRS enhancements in 5G MIMO Phase 6	Qualcomm Incorporated

R1-2509250	Improvement of SRS capacity and coverage	Transsion Holdings

R1-2509269	Discussion on Improvement of SRS capacity and coverage	NTT DOCOMO, INC.

R1-2509297	Views on enhancements for Improvement of SRS capacity and coverage	KDDI Corporation

R1-2509320	Improvement of SRS capacity and coverage	Sharp

R1-2509358	Discussion on improvement of SRS capacity and coverage	Google

R1-2509362	Discussion on Improvement of SRS Capacity and Coverage	Rakuten Mobile, Inc

R1-2509393	Discussion on improvement of SRS capacity and coverage	NICT

Enhancing DL CSI acquisition

Including a) Early SRS/CSI/CSI-RS triggering, and b) CSI-RS density reduction for 48, 64, and 128 CSI-RS ports.

R1-2508517	Moderator summary on enhancing DL CSI acquisition (Round 0)	MediaTek Inc.

R1-2508518	Moderator summary on enhancing DL CSI acquisition (Round 1)	MediaTek Inc.

R1-2508519	Moderator summary on enhancing DL CSI acquisition (Round 2)	MediaTek Inc.

R1-2508520	Moderator summary on enhancing DL CSI acquisition (Round 3)	MediaTek Inc.

R1-2508328	Enhancing DL CSI acquisition	FUTUREWEI

R1-2508342	On DL CSI Acquisition Enhancements for FR1	Nokia

R1-2508348	NR MIMO Phase 6: DL CSI Enhancement	InterDigital, Inc.

R1-2508363	Enhanced DL CSI acquisition for MIMO Phase 6	Ericsson

R1-2508369	Enhancing DL CSI acquisition	MediaTek Inc.

R1-2508370	Discussion on enhancing DL CSI acquisition	TCL

R1-2508378	Discussion on enhancing DL CSI acquisition	Spreadtrum, UNISOC

R1-2508422	Discussion on enhancing DL CSI acquisition	vivo

R1-2508492	DL CSI acquisition enhancement	Huawei, HiSilicon

R1-2508510	Discussion on enhancing DL CSI acquisition	Quectel

R1-2508526	Discussion on enhancing DL CSI acquisition	ZTE Corporation, Sanechips

R1-2508548	Discussion on Enhancing DL CSI acquisition	NEC

R1-2508587	Enhancing DL CSI acquisition	CATT

R1-2508636	DL CSI Enhancements for NR Rel-20	AT&T

R1-2508674	Discussion on enhancing DL CSI acquisition	Xiaomi

R1-2508717	Discussions on Enhancing DL CSI Acquisition	OPPO

R1-2508752	Discussion on enhancing DL CSI acquisition	LG Electronics

R1-2508757	Enhancing DL CSI acquisition	Tejas Network Limited

R1-2508792	Views on enhancing DL CSI acquisition	Samsung

R1-2508840	Discussions on enhancing DL CSI acquisition	China Telecom

R1-2508882	Discussion on early DL CSI acquisition design	Fainity Innovation

R1-2508929	Discussion on enhancing DL CSI acquisition	Fujitsu

R1-2508966	Discussion on enhancing DL CSI acquisition for NR MIMO Phase 6	ETRI

R1-2508989	Discussion on enhancing DL CSI acquisition	HONOR

R1-2509033	Discussion on enhancing DL CSI acquisition	Ofinno

R1-2509048	DL CSI acquisition enhancements for Rel. 20 MIMO	Fraunhofer IIS, Fraunhofer HHI

R1-2509069	Discussion on DL CSI acquisition enhancements	Sony

R1-2509100	On Rel-20 MIMO CSI enhancement	Apple

R1-2509164	Discussion on Early DL CSI Acquisition Enhancements	Panasonic

R1-2509221	DL CSI acquisition enhancements in 5G MIMO Phase 6	Qualcomm Incorporated

R1-2509270	Discussion on Enhancing DL CSI acquisition	NTT DOCOMO, INC.

R1-2509307	Discussion on DL CSI acquisition	ITRI, Acer Incorporated

R1-2509321	Enhancing DL CSI acquisition	Sharp

R1-2509325	Discussion on Enhancing DL CSI acquisition	IIT Kanpur

R1-2509342	Views on DL Channel acquisition enhancements	CEWiT

R1-2509359	Discussion on enhancing DL CSI acquisition	Google

R1-2509363	Discussion on Enhancement of CSI DL Acquisition	Rakuten Mobile, Inc

R1-2509394	Discussion on enhancing DL CSI acquisition	NICT

Study of Enhancements for solutions for Ambient IoT (Internet of Things) in NR outdoor for active devices

Please refer to RP-252964 for detailed scope of the SI.

[123-R20-A-IoT] Email discussion on Rel-20 A-IoT – Jay (LGE)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2508475	Skeleton of update to TR 38.769	Huawei (editor)

R1-2509450	Session Notes of AI 10.3	Ad-Hoc Chair (NTT DOCOMO, INC.)

Evaluations

Including necessary evaluation assumptions of deployment scenarios for coverage and coexistence, evaluations of achievable cell edge data rate and link budget, as well as applicability and necessity of Device 2b and Device C to given scenarios.

R1-2508742	FL summary #1 for Ambient IoT: “10.3.1 Evaluations”	Moderator (Huawei)

R1-2508743	FL summary #2 for Ambient IoT: “10.3.1 Evaluations”	Moderator (Huawei)

R1-2508744	FL summary #3 for Ambient IoT: “10.3.1 Evaluations”	Moderator (Huawei)

R1-2508329	Evaluations for R20 A-IoT	FUTUREWEI

R1-2508379	Evaluations for outdoor Ambient IoT	Spreadtrum, UNISOC

R1-2508423	Evaluation on Coverage for R20 AIoT	vivo

R1-2508438	Evaluation for Rel-20 AIoT	Nokia

R1-2508447	Discussion on evaluation results	CMCC

R1-2508499	Evaluation for active A-IoT device in outdoor scenario	Huawei, HiSilicon

R1-2508511	Discussion on Rel-20 A-IoT evaluation assumptions and results	Ericsson

R1-2508542	Evaluations for Ambient IoT	NEC

R1-2508588	Evaluation methodology for A-IoT outdoor deployment scenarios	CATT

R1-2508675	Discussion on evaluation methodology for Ambient IoT in NR outdoor for active devices	Xiaomi

R1-2509453	Discussion on evaluation methodology for Ambient IoT in NR outdoor for active devices	Xiaomi	(Revision of R1-2508675)

R1-2508718	Discussion on EVM for R20 A-IoT	OPPO

R1-2508758	Evaluation assumptions for outdoor Ambient IoT	Tejas Network Limited

R1-2508793	Evaluations for Rel-20 Ambient IoT	Samsung

R1-2508817	Discussion on evaluation for active Ambient IoT device	ZTE Corporation, Sanechips

R1-2508899	Evaluations for Rel-20 Ambient IoT SI	LG Electronics

R1-2508990	Evaluation results for Device 2b&C for Ambient IoT	HONOR

(Withdrawn)

R1-2509101	On Rel-20 Ambient IoT evaluations	Apple

R1-2509119	Evaluations for Active Devices in Ambient IoT	InterDigital, Inc.

R1-2509153	Evaluation aspects for Ambient IoT	MediaTek Inc.

R1-2509222	Evaluations for Ambient IoT in NR outdoor for active devices	Qualcomm Incorporated

R1-2509271	Study on evaluations for Ambient IoT outdoor for active device	NTT DOCOMO, INC.

R1-2509327	Evaluation for Rel-20 AIoT	IIT Kanpur

(Late submission)

R1-2509421	Initial evaluations of Ambient IoT for outdoor devices	Sony

Study of air interface for Device 2b/C

Please refer to the first paragraph of objective 1 for the given conditions. Including study necessary and feasible changes to the Rel-19 air interface for Device 2b/C.

R1-2508967	Discussion on air interface for device 2b and device C	ETRI

R1-2508980	Discussion on Air Interface Enhancements for R20 A-IoT	Fraunhofer HHI, Fraunhofer IIS

R1-2508991	Views on air interface for Device 2b&C for Ambient IoT	HONOR

R2D signals, channels, waveform and procedures

Including necessary and feasible change to R2D waveform and modulation, line coding, FEC, CRC and repetitions, bandwidth, timing and Sync signals, L1 control/scheduling, and multiplexing

R1-2508330	Discussion on R2D Air Interface for Device 2b/C	FUTUREWEI

R1-2508380	Discussion on R2D signals, channels, waveform and procedures for Ambient IoT	Spreadtrum, UNISOC

R1-2508424	Discussion on R2D Aspects for R20 AIoT	vivo

R1-2508439	AIoT R2D signals, channels, waveform and procedures	Nokia

R1-2508448	Discussion on R2D signals, channels, waveform and procedures	CMCC

R1-2508500	Study on R2D signals, channels, waveform and procedures	Huawei, HiSilicon

R1-2508512	R2D signals, channels, waveform, and procedures	Ericsson

R1-2508543	Study on R2D signals, channels, waveform and procedures	NEC

R1-2508589	Study of R2D signals, channels, and waveform and procedure of A-IoT enhancement for device 2b/C	CATT

R1-2508604	Discussion on R2D procedures for Ambient IoT	China Telecom

R1-2508676	Discussion on R2D signals, channels, waveform and procedures for Device 2b/C	Xiaomi

R1-2508719	Discussion on necessary and feasible change to R2D for Rel-20 A-IoT	OPPO

R1-2508794	Study on R2D aspects of air interface for Device 2b/C	Samsung

R1-2508818	Discussion on R2D design for active Ambient IoT device	ZTE Corporation, Sanechips

R1-2508834	Discussion on R2D transmission	Transsion Holdings

R1-2508900	R2D air interface for Device 2b/C	LG Electronics

R1-2508914	Discussion on A-IoT Air Interface for R2D	Panasonic

R1-2508957	Discussion on R2D for R20 Ambient IoT	Lenovo

R1-2509102	On R2D design details for device 2b/C	Apple

R1-2509120	R2D Design for Active Devices in Ambient IoT	InterDigital, Inc.

R1-2509154	R2D aspects for Ambient IoT	MediaTek Inc.

R1-2509174	Discussion on R2D signals, channels, waveform and procedures	Sharp

R1-2509194	Discussion on R2D signals, channels, waveform and procedures	Quectel

R1-2509223	Study of R2D designs for Device 2b/C	Qualcomm Incorporated

R1-2509272	Study on R2D design and procedures for Ambient IoT outdoor for active device	NTT DOCOMO, INC.

R1-2509323	Discussion on R2D signals, channels, waveform and procedures for Ambient IoT	TCL

R1-2509329	Discussion on R2D signals, channels, waveform and procedures	IIT Kanpur

R1-2509343	Discussion on R2D signals, channels, waveform and procedures for Ambient IoT	CEWiT

R1-2509380	On AIoT air interface R2D design for Rel.20 Device 2b/C	Sequans Communications

R1-2509422	Consideration on R2D signals and procedures	Sony

D2R signals, channels, waveform and procedures

Including necessary and feasible change to D2R waveform and modulation, FEC, CRC and repetition, bandwidth, timing and Sync signals, multiplexing/multiple access, and scheduling.

R1-2508331	Discussion on D2R Air Interface for Device 2b/C	FUTUREWEI

R1-2508349	Discussion on D2R transmissions for active ambient IoT	TCL

R1-2508381	Discussion on D2R signals, channels, waveform and procedures for Ambient IoT	Spreadtrum, UNISOC

R1-2508425	Discussion on D2R Aspects for R20 AIoT	vivo

R1-2508440	AIoT D2R signals, channels, waveform and procedures	Nokia

R1-2508449	Discussion on D2R signals, channels, waveform and procedures	CMCC

R1-2508501	Study on D2R signals, channels, waveform and procedures	Huawei, HiSilicon

R1-2508513	D2R signals, channels, waveform, and procedures	Ericsson

R1-2508544	Study on D2R signals, channels, waveform and procedures	NEC

R1-2508590	Study of D2R signals, channels, and waveform and procedure of A-IoT enhancement for device 2b/C	CATT

R1-2508605	Discussion on D2R procedures for Ambient IoT	China Telecom

R1-2508677	Discussion on D2R signals, channels, waveform and procedures for Device 2b/C	Xiaomi

R1-2508720	Discussion on Rel-20 A-IoT D2R for Device 2b/C	OPPO

R1-2508795	Study on D2R aspects of air interface for Device 2b/C	Samsung

R1-2508819	Discussion on D2R design for active Ambient IoT device	ZTE Corporation, Sanechips

R1-2508835	Discussion on D2R transmission	Transsion Holdings

R1-2508901	D2R air interface for Device 2b/C	LG Electronics

R1-2508915	Discussion on A-IoT Air Interface for D2R	Panasonic

R1-2508958	Discussion on D2R for R20 Ambient IoT	Lenovo

R1-2509103	On D2R design details for device 2b/C	Apple

R1-2509121	D2R Design for Active Devices in Ambient IoT	InterDigital, Inc.

R1-2509175	Discussion on D2R signals, channels, waveform and procedures	Sharp

R1-2509189	Discussion on D2R multiplexing/multiple access for A-IoT active device	ASUSTeK

R1-2509224	Study of D2R designs for Device 2b/C	Qualcomm Incorporated

R1-2509273	Study on D2R design and procedures for Ambient IoT outdoor for active device	NTT DOCOMO, INC.

R1-2509330	Discussion on D2R signals, channels, waveform and procedures	IIT Kanpur

R1-2509344	Discussion on D2R signals, channels, waveform and procedures for Ambient IoT	CEWiT

R1-2509423	D2R signals, waveforms and procedures for Ambient IoT outdoor devices	Sony

Other procedures

Including necessary and feasible change to other procedures such as for initial frequency acquisition and broadcast information acquisition, random access, DO-A, and power control.

R1-2508903	FL summary #1 for 10.3.2.3 “Other procedures for Device 2b/C”	Moderator (LG Electronics)

R1-2508904	FL summary #2 for 10.3.2.3 “Other procedures for Device 2b/C”	Moderator (LG Electronics)

R1-2508905	FL summary #3 for 10.3.2.3 “Other procedures for Device 2b/C”	Moderator (LG Electronics)

R1-2508906	FL summary #4 for 10.3.2.3 “Other procedures for Device 2b/C”	Moderator (LG Electronics)

R1-2508907	FL summary #5 for 10.3.2.3 “Other procedures for Device 2b/C”	Moderator (LG Electronics)

R1-2508332	Discussion on Other Air Interface Procedures	FUTUREWEI

R1-2508382	Discussion on other procedure for Ambient IoT	Spreadtrum, UNISOC

R1-2508426	Discussion on Other Procedures for R20 AIoT	vivo

R1-2508441	Other procedures for AIoT	Nokia

R1-2508450	Discussion on other procedures	CMCC

R1-2508502	Study on other procedures	Huawei, HiSilicon

R1-2508514	Other procedures of A-IoT	Ericsson

R1-2508545	Study on other procedures for Device 2b and C	NEC

R1-2508591	Study of general procedures of A-IoT enhancement for device 2b/C	CATT

R1-2508606	Discussion on other procedures for Ambient IoT	China Telecom

R1-2508678	Discussion on other procedures for Device 2b/C	Xiaomi

R1-2508721	Discussion on other procedures for Rel-20 A-IoT	OPPO

R1-2508759	Study AIoT air interface for DO-A traffic	Tejas Network Limited

R1-2508796	Study on other procedures of air interface for Device 2b/C	Samsung

R1-2508820	Discussion on other procedures for active Ambient IoT device	ZTE Corporation, Sanechips

R1-2508836	Discussion on other aspects of Device 2b_C	Transsion Holdings

R1-2508860	Discussion on A-IoT other procedures	Panasonic

R1-2508902	Other procedures for Device 2b/C	LG Electronics

R1-2508959	Discussion on other procedures for R20 Ambient IoT	Lenovo

R1-2509041	Procedures for Air Interface of Devices 2b/C	ROBERT BOSCH GmbH

R1-2509104	On other procedures for device 2b/C	Apple

R1-2509122	Other Procedures for Active Devices in Ambient IoT	InterDigital, Inc.

R1-2509123	Considerations for A-IoT other procedures	Semtech Neuchatel SA

R1-2509155	Other procedures for Ambient IoT	MediaTek Inc.

R1-2509176	Discussion on other procedures	Sharp

R1-2509190	Discussion on procedures for A-IoT active device	ASUSTeK

R1-2509195	Discussion on other procedures for Device 2b/C	Quectel

R1-2509225	Study of other procedures for Device 2b/C	Qualcomm Incorporated

R1-2509274	Study on other procedures for Ambient IoT outdoor for active device	NTT DOCOMO, INC.

R1-2509324	Discussion on other procedures for Ambient IoT	TCL

R1-2509332	Discussion on other aspects of Rel-20 AIoT	IIT Kanpur

R1-2509345	Discussion on other procedures for Ambient IoT	CEWiT

R1-2509424	System information and DO-A aspects for Ambient IoT outdoor devices	Sony

R1-2509432	Discussion on other procedures for Device 2b/C	KT Corp.

Coverage Enhancement Phase 3

Please refer to RP-252824 for detailed scope of the WI.

[123-R20-CE] Email discussion on Rel-20 CE– Hang (China Telecom)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509451	Session Notes of AI 10.4	Ad-Hoc Chair (NTT DOCOMO, INC.)

Coverage enhancement

Including PRACH coverage enhancements, PUSCH repetition scheduled by DCI 0_0 with C-RNTI and Extending pi/2-BPSK to more MCS entries.

R1-2508608	FL's summary #1 on NR coverage enhancements Phase 3	China Telecom

R1-2508609	FL's summary #2 on NR coverage enhancements Phase 3	China Telecom

R1-2508610	FL's summary #3 on NR coverage enhancements Phase 3	China Telecom

R1-2508611	FL's summary #4 on NR coverage enhancements Phase 3	China Telecom

R1-2508612	Final FL's summary on NR coverage enhancements Phase 3	China Telecom

R1-2508383	Discussion on NR Coverage enhancement	Spreadtrum, UNISOC

R1-2508393	Discussion on coverage enhancement	LG Electronics

R1-2508427	Further discussions on NR phase 3 coverage enhancements	vivo

R1-2508498	Coverage enhancements for NR Phase 3	Huawei, HiSilicon

R1-2508592	Discussion on coverage enhancement	CATT

R1-2508607	Discussion on NR coverage enhancements Phase 3	China Telecom

R1-2508679	Discussion on coverage enhancement	Xiaomi

R1-2508722	Discussion on further enhancement for coverage enhancement	OPPO

R1-2508755	NR coverage enhancement Phase 3	Tejas Network Limited

R1-2508797	Discussion on Coverage Enhancement	Samsung

R1-2508837	Discussion on coverage enhancement	Transsion Holdings

R1-2508853	Discussion on coverage enhancement	ZTE Corporation, Sanechips

R1-2508913	MCS entries for pi/2-BPSK	Wisig, IITH

R1-2508968	Discussion on coverage enhancements	ETRI

R1-2508998	Discussion on 5G NR coverage enhancement phase 3	Panasonic

R1-2509005	Coverage enhancements for NR Phase 3	Nokia

R1-2509015	Coverage enhancement for NR Phase 3	InterDigital, Inc.

R1-2509038	Views on Coverage Enhancement Phase 3	Ofinno

R1-2509105	Discussion on coverage enhancements for NR Phase 3	Apple

R1-2509138	Discussions on NR coverage enhancements Phase 3	KT Corp.

R1-2509179	Coverage enhancements	Lenovo

R1-2509181	Discussions on further coverage enhancement for NR	Sharp

R1-2509226	Coverage enhancement Phase 3	Qualcomm Incorporated

R1-2509275	Discussions on coverage enhancement	NTT DOCOMO, INC.

R1-2509308	Discussion on NR Coverage enhancement Phase 3	ITRI, Acer Incorporated

R1-2509334	Discussion on Rel-20 Coverage Enhancement	Ericsson (China)

(Withdrawn)

R1-2509346	Discussion on Coverage Enhancements Phase 3	CEWiT

R1-2509365	Discussion on coverage enhancement	ASUSTeK

R1-2509379	Discussion on coverage enhancement	DENSO CORPORATION

R1-2509420	Discussion on Rel-20 Coverage Enhancement	Ericsson

Study on Integrated Sensing And Communication (ISAC) for NR

Please refer to RP-252819 for detailed scope of the SI.

[123-R20-ISAC] Email discussion on Rel-20 ISAC – Yingyang (Xiaomi)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509452	Session Notes of AI 10.5	Ad-Hoc Chair (NTT DOCOMO, INC.)

R1-2509237	Draft TR 38.765 v010: Study on Integrated Sensing And Communication (ISAC) for NR	Xiaomi, China Telecom

Evaluation assumptions and performance evaluation

Including study of metrics, measurements, and relevant measurement quantization for UAV use case.

R1-2509238	Summary #1 on evaluations for NR ISAC	Moderator (Xiaomi)

R1-2509239	Summary #2 on evaluations for NR ISAC	Moderator (Xiaomi)

R1-2509240	Summary #3 on evaluations for NR ISAC	Moderator (Xiaomi)

R1-2509241	Summary #4 on evaluations for NR ISAC	Moderator (Xiaomi)

R1-2509242	Summary #5 on evaluations for NR ISAC	Moderator (Xiaomi)

R1-2509243	Summary #6 on evaluations for NR ISAC	Moderator (Xiaomi)

R1-2508372	Views on evaluation assumptions and performance evaluation for ISAC	Sharp

R1-2508384	Discussion on evaluation assumption and performance evaluation for ISAC	Spreadtrum, UNISOC

R1-2508428	Evaluation methodology and performance evaluation for 5G-A ISAC	vivo

R1-2508451	Discussion on evaluations and measurements for NR ISAC	CMCC

R1-2508464	Evaluation assumptions and performance evaluation of ISAC for NR	InterDigital, Inc.

R1-2508473	Discussion on Evaluation Assumptions and Performance Evaluation for ISAC	Tiami Networks

R1-2508485	Performance metric, methodologies, and initial evaluation results for ISAC	Huawei, HiSilicon

R1-2508593	Discussion on evaluation assumptions and performance evaluation for R20 ISAC for NR	CATT, CICTCI

R1-2508613	Discussion on ISAC evaluation assumptions and performance evaluation	China Telecom

R1-2508618	Evaluation assumptions and performance evaluation for ISAC	EURECOM

R1-2508634	On ISAC performance evaluations and assumptions	Lenovo

R1-2508680	Discussion on performance evaluation for ISAC	Xiaomi

R1-2508723	Discussion of ISAC evaluation in 5GA	OPPO

R1-2508798	Discussion on ISAC evaluation assumptions and performance evaluation	Samsung

R1-2508859	Evaluation assumptions and performance evaluations of ISAC for NR	Nokia, Nokia Shanghai Bell

R1-2508877	Considerations on Evaluations for NR ISAC	CAICT

R1-2508883	Discussion on ISAC Performance Evaluation for 5G-A	NIST

R1-2508938	Discussion on evaluation assumptions and performance evaluation for NR ISAC	Panasonic

R1-2508969	Discussion on evaluation assumptions and performance evaluation for NR ISAC	ETRI

R1-2509002	Discussion on ISAC for NR	Ericsson

R1-2509040	Evaluation assumptions and performance evaluation for NR ISAC	Hanbat National University

R1-2509054	Discussion on Performance Evaluations for Rel-20 ISAC	Google

R1-2509070	Discussion on Evaluation Assumptions and Performance Evaluation of NR ISAC	Sony

R1-2509106	Rel-20 Evaluation assumptions and performance evaluation for 5G-A ISAC	Apple

R1-2509124	ISAC Performance metrics and overhead	T-Mobile USA

R1-2509157	Discussion on ISAC evaluation assumptions and performance evaluation	MediaTek Inc.

R1-2509227	Evaluation Assumptions and performance evaluation for UAV gNB-monostatic sensing	Qualcomm Incorporated

R1-2509246	Discussion on 5G-A ISAC evaluation	ZTE Corporation, Sanechips,VIAVI

R1-2509276	Evaluation assumptions and performance evaluation for ISAC	NTT DOCOMO, INC.

R1-2509293	Discussion on Evaluation assumptions and of ISAC for NR	SK Telecom

R1-2509305	Discussion on evaluation assumptions and performance evaluation for NR ISAC	LG Electronics

R1-2509457	Discussion on evaluation assumptions and performance evaluation for NR ISAC	LG Electronics

(Revision of R1-2508457)

R1-2509326	Evaluation assumptions and Performance Evaluation for Self-Interference Modeling for ISAC	Tejas Network Limited

Non-Terrestrial Networks (NTN) for NR Phase 4

Please refer to RP-251933 for detailed scope of the SI for NR-NTN Phase 4.

[123-R20-NR-NTN] Email discussion on Rel-20 NR-NTN – Mohamed (Thales)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2509446	Session Notes of AI 10.6	Ad-Hoc Chair (Ericsson)

R1-2508470	Work plan for NR NTN Phase 4	Rapporteur (Thales)

R1-2508479	TR 38.742 skeleton for study on GNSS (Global Navigation Satellite System) resilient NR-NTN (Non-Terrestrial Networks) operation	Rapporteur (Thales)

NR-NTN GNSS resilience

R1-2508466	FL Summary #1: Study on GNSS resilient NR-NTN operation	THALES

R1-2508467	FL Summary #2: Study on GNSS resilient NR-NTN operation	THALES

R1-2508468	FL Summary #3: Study on GNSS resilient NR-NTN operation	THALES

R1-2508469	FL Summary #4: Study on GNSS resilient NR-NTN operation	THALES

R1-2508333	Discussion on Rel-20 GNSS resilient NR NTN operation	FUTUREWEI

R1-2508360	PRACH with GNSS unavailable	Eutelsat Group

R1-2508385	Discussion on NR NTN GNSS resilience	Spreadtrum, UNISOC

R1-2508429	Discussion on NR-NTN GNSS resilience	vivo

R1-2508452	Discussion on NR-NTN GNSS resilience	CMCC

R1-2508465	Considerations on NR-NTN Resilience to GNSS Unavailability and Degradation	THALES

R1-2508481	Considerations for GNSS-resilient NR-NTN operation	ST Engineering iDirect

R1-2508489	GNSS resilience for NR-NTN	Huawei, HiSilicon

R1-2508555	Discussion on NR-NTN GNSS resilience	NEC

R1-2508594	Discussion on NR-NTN GNSS resilience	CATT

R1-2509456	Discussion on NR-NTN GNSS resilience	CATT

(Revision of R1-2508594)

R1-2508626	Considerations for GNSS-resilient NR-NTN operation	ESA

R1-2508681	Discussion on NR-NTN GNSS resilience	Xiaomi

R1-2508724	Discussion on NR-NTN GNSS resilience	OPPO

R1-2508754	Discussion on NR-NTN GNSS resilience	Fraunhofer IIS, Fraunhofer HHI

R1-2508760	Discussion on GNSS Resilient NR-NTN Operation	Tejas Network Limited

R1-2508799	Discussion on NR-NTN GNSS resilience	Samsung

R1-2508843	On NR-NTN GNSS resilience	Ericsson

R1-2508854	Discussion on NR-NTN GNSS resilience	ZTE Corporation, Sanechips

R1-2508872	Discussion on NR-NTN GNSS resilience	Airbus

R1-2508875	Discussion on NR NTN GNSS Resilience	Amazon Web Services

R1-2508889	PRACH transmission and detection in NR NTN GNSS resilient operation	Sharp

R1-2508970	Discussion on NR-NTN GNSS resilient operations	ETRI

R1-2508984	Discussion on the GNSS resilient NR-NTN operation	TCL

R1-2508992	Discussion on NR-NTN GNSS resilience	HONOR

R1-2509007	Discussion on GNSS resilient operation for NR over NTN	Nokia

R1-2509016	NR-NTN GNSS resilience	InterDigital, Inc.

R1-2509017	Discussion on NR-NTN GNSS resilience	IMU

R1-2509018	Discussion on GNSS resilient NR-NTN operation	Lenovo

R1-2509071	On NR-NTN GNSS resilience approaches	Sony

R1-2509107	Discussion on NR-NTN GNSS resilience	Apple

R1-2509131	Discussion on NR-NTN GNSS resilience	Ofinno

R1-2509137	Discussion on GNSS resilient NR-NTN operation	TOYOTA Info Technology Center

R1-2509163	GNSS resilient operations in NR NTN	MediaTek Inc.

R1-2509178	Discussion on NR-NTN GNSS resilient operation using synchronization signals	ViaSat Satellite Holdings Ltd, Inmarsat

R1-2509185	Discussion on NR-NTN GNSS resilience	China Telecom

R1-2509228	NR-NTN GNSS resilience	Qualcomm Incorporated

R1-2509448	NR-NTN GNSS resilience	Qualcomm Incorporated

(Revision of R1-2509298)

R1-2509277	Discussion on NR-NTN GNSS resilience	NTT DOCOMO, INC.

R1-2509296	Discussion on GNSS resilient NR-NTN	Panasonic

R1-2509298	Discussion on NR-NTN GNSS resilience	Google Korea LLC

R1-2509301	Discussion of NR-NTN GNSS Resilience	Johns Hopkins University APL

R1-2509304	Discussion on GNSS resilient NR-NTN operation	LG Electronics

R1-2509336	Discussion on GNSS resilience for NR-NTN	CSCN

R1-2509347	Discussion on GNSS Resilient Operation for NR NTN	CEWiT

R1-2509434	Considerations on timing error budget under GNSS resilience in NR-NTN	ISSDU

Non-Terrestrial Networks (NTN) for Internet of Things (IoT) Phase 4

Please refer to RP-251867 for detailed RAN1 scope of the WI (Placeholder only, will start from RAN1#124)

Semi-persistent scheduling for DL/UL data transmission for voice packets

Rel-20 Study of 6GR

Please refer to RP-252912 for the scope of the SI. The maximum number of contributions per company/organization/university is limited to 1 per agenda item unless stated otherwise.

Note: Additional more guidance/information, please refer to R1-25xxxxx (Highlights from RAN#109)

R1-2509278	Workplan for Rel-20 Study of 6GR	NTT DOCOMO, China Mobile, AT&T, Vodafone

R1-2509279	Skeleton for TR 38.760-1 “Study on 6G Radio RAN1 aspects” v0.0.2	NTT DOCOMO, INC.

Overview of 6GR air interface

High level design proposals/principles/target, including scalable 6GR design (e.g., what design is scalable, what design is unscalable), support of minimum spectrum allocation, coverage, MRSS, synchronization signal structure and periodicity, operation of bandwidth/band adaptation, spectrum utilization and aggregation framework, harmonization of TN and NTN, and others (if any).

Note: To avoid distributing proposals of a same topic to different sub-agendas, please organize the proposals according to above highlights.

[123-R20-6GR-Overall] Email discussion on Rel-20 6GR-Overall – Shinya (NTT DOCOMO)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Chair note:

For the discussion of “Re-use of existing 5G mid-band (~3.5GHz) site grid for 6G deployments in at least around 7 GHz and targeting comparable coverage to 5G mid-band”, to give a reference methodology of the coverage of mid-band (~3.5GHz) with a list of factors and their corresponding values, where all the factors will be used for the coverage assumption of around 7GHz.

Agreement

For the discussion of “Re-use of existing 5G mid-band (~3.5GHz) site grid for 6G deployments in at least around 7 GHz and targeting comparable coverage to 5G mid-band”,

The link budget template candidates 1 and/or 2 are used to calculate the metric(s), with potential update in RAN1#123.

[From RAN1 perspective, FFS

Alt1: required data rate for 6G deployment should not be lower than the target data rate for existing 5G mid-band, to be confirmed by RANp

Alt2: required data rate for 6G deployment is comparable to the target data rate for existing 5G mid-band, to be confirmed by RANp

Striving for same coverage during initial access/random access for existing 5G mid-band and 6G deployment, to be confirmed by RANp]

Following deployment scenarios are considered

Dense urban

Rural

Urban macro as high priority

Sub-urban macro

Following carrier frequencies are considered to calculate the metric(s)

[4 GHz] as the existing 5G mid-band, to be confirmed by RANp

7 GHz as 6G deployment

Template in R1-250nnnn is to be used for collecting inputs on the values from companies.

Note: Proposal 5.3 is not used to provide methodology and analysis to RAN to determine the coverage target(s)

Agreement

If the minimum spectrum allocation is 3MHz with 15kHz SCS for 6GR,

Opt1: Design of the common signals/channels (at least for SSB) for initial access by assuming bandwidth larger than 3MHz, which is applicable to any spectrum allocations with adjustment, if applicable

Opt2: A single design of the common signals/channels (at least for SSB) for initial access by assuming minimum spectrum allocation as target bandwidth 3MHz, which is applicable to any spectrum allocations

Agreement

Skeleton for TR 38.760-1 “Study on 6G Radio RAN1 aspects” v0.0.3 in R1-2509569 is endorsed.

Agreement

For scalable 6GR design for diverse device types, RAN1 can at least consider the following, targeting applicable to all 6G device types,

Basic initial access procedures from RAN1 perspective

Other PHY features after initial access procedure, e.g., Other DL/UL control, scheduling/HARQ

Coverage features to meet the identified coverage target

Energy saving both at BS and UE sides

MRSS

Note: whether these features are supported, mandatory or optional is separate discussion

R1-2509288	FL summary#1 on overview of 6GR air interface	Moderator (NTT DOCOMO)

R1-2509289	FL summary#2 on overview of 6GR air interface	Moderator (NTT DOCOMO)

R1-2509290	FL summary#3 on overview of 6GR air interface	Moderator (NTT DOCOMO)

R1-2509291	FL summary#4 on overview of 6GR air interface	Moderator (NTT DOCOMO)

R1-2509292	FL summary#5 on overview of 6GR air interface	Moderator (NTT DOCOMO)

R1-2508320	More high level views on the 6GR air interface	FUTUREWEI

R1-2508334	Nokia Views on Selected Aspects of 6G Radio Air Interface	Nokia

R1-2508352	Overview of the 6G air interface	Ericsson

R1-2508386	Overview of 6GR air interface	Spreadtrum, UNISOC

R1-2508430	Overview of 6GR air interface	vivo

R1-2508453	Overview of 6GR air interface	CMCC

R1-2508472	Overview of 6GR air interface	THALES

R1-2508474	Discussion on Overview of 6GR Air Interface	Tiami Networks

R1-2508476	Overview of 6GR air interface	Fraunhofer IIS, Fraunhofer HHI

R1-2508523	Overview of 6GR air interface	TCL

R1-2508560	Overview of 6GR air interface	NEC

R1-2508579	Outline and highlight of 6GR air interface	CATT, CICTCI

R1-2508614	Overview of 6GR air interface	China Telecom

R1-2508619	Overview of 6GR air-interface	Lenovo

R1-2508621	Discussion on 6GR Waveform	Lenovo

R1-2508637	High-Level Considerations for the 6GR Air Interface Design	AT&T

R1-2508682	6GR air interface design overview	Xiaomi

R1-2508725	Overview of 6GR air interface	OPPO

R1-2508733	Overview of 6GR air interface	Huawei, HiSilicon

R1-2508741	Overview of 6GR air interface	InterDigital, Inc.

R1-2508800	Design of 6GR air interface	Samsung

R1-2508824	Overview on 6G Air interface	Tejas Network Limited

R1-2508825	Evaluation Assumptions for 6GR Air Interface	Tejas Network Limited

(Withdrawn)

R1-2508855	High-level views on 6GR	ZTE Corporation, Sanechips

R1-2508862	Features for 6GR Air Interface	National Spectrum Consortium

R1-2508873	Positioning, Navigation and Timing (PNT) in 6G NTN-TN harmonization	Airbus

R1-2508874	Overview of 6GR air interface	Amazon Web Services

R1-2508880	Overview proposal of 6GR air interface	Panasonic

R1-2508908	Views on overall design and techniques for 6GR air interface	LG Electronics

R1-2508918	Fujitsu’s view of 6GR air interface	Fujitsu

R1-2508936	Overview of 6GR air interface	NVIDIA

R1-2508945	Overview of 6GR Air Interface	Google

R1-2508971	Overview of the 6GR air interface	ETRI

R1-2508993	Discussion on overview of 6GR air interface	HONOR

R1-2509013	IMU Views on 6G Radio Air Interface	IMU

R1-2509026	Discussion on 6GR Air Interface	Ofinno

R1-2509061	Overview of 6GR air interface	Sharp

R1-2509072	Overview of 6GR air interface	Sony

R1-2509108	Overview of 6GR air interface	Apple

R1-2509134	General aspects of 6G IoT	Nordic Semiconductor ASA

R1-2509139	Overview of 6GR air interface	KT Corp.

R1-2509141	Overview of 6GR air interface	MediaTek Inc.

R1-2509170	Discussion on 6G Radio for NTN	TOYOTA Info Technology Center

R1-2509229	Overview of 6GR air interface	Qualcomm Incorporated

R1-2509280	Discussion on overview of 6GR air interface	NTT DOCOMO, INC.

R1-2509333	Discussion on 6GR air interface	IIT Kanpur

R1-2509337	Views on 6GR air interface	CSCN

R1-2509339	Overview of 6GR air interface	KDDI Corporation

R1-2509348	Overview of 6G Air Interface	CEWiT

R1-2509355	Overview of 6G Radio air interface	ITL

R1-2509366	Discussion on the Overview of 6GR Air Interface	Rakuten Mobile, Inc

R1-2509382	Overview of 6G Radio air interface	WILUS Inc.

R1-2509395	Views on 6GR sync signal structure	NICT

R1-2509397	Addressing CAPEX/OPEX requirement in RAN1	Vodafone, AT&T, BT, Bouygues Telecom, Deutsche Telekom, Orange, Telecom Italia, Nokia, China Unicom

Evaluation assumptions for 6GR air interface

Discussions on models, scenarios, parameters, and methodology, metrics/criteria, as well as traffic model that can be commonly used for evaluating technology proposals.

[123-R20-6GR-Evaluation] Email discussion on Rel-20 6GR-Evaluation – Jinhuan (Huawei)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

Updating the BS antenna modelling agreed in the last meeting as follows:

For around 700MHz carrier frequency, for BS antenna modelling,

update the (8, 4, 2, 1, 1; x, y) to be (8, 4, 2, 1, 1; 1, 4).

For around 2GHz carrier frequency, for BS antenna modelling,

for outdoor combination 1 (i.e., 32AE/4TXRU), update the (M,N,P,Mg,Ng; Mp,Np) to be (8, 2, 2, 1, 1; 1, 2)

For around 7GHz carrier frequency, for BS antenna modelling,

for outdoor combination 1 (i.e., 768AE/128TXRU), update the (M,N,P,Mg,Ng; Mp,Np) to be (24, 16, 2, 1, 1; 4, 16).

for outdoor combination 3 (i.e., 1536AE/256TXRU), update the (M,N,P,Mg,Ng; Mp,Np) to be (48, 16 ,2, 1, 1; 8, 16).

Agreement

For 6GR evaluation, the layout for system-level simulation is assumed as follows:

Note: Single layer will be prioritized for the evaluations.

Note: The carrier frequency for the corresponding layout for the two layers will be reported by companies for the evaluations.

FFS the minimum distance for random drop in two layers.

Note: for system-level simulation of MIMO schemes, specific assumptions could be discussed under MIMO discussion

Parameters	Indoor Hotspot	Dense Urban	Rural	Urban Macro	Suburban Macro
Layout	Single layer - Indoor floor (Open office), (Room size: 120m x 50m)	Single layer: - Hex. Grid Two layers: - Macro layer: Hex. Grid - Micro layer: Random drop	Single layer: - Hex. Grid	Single layer: - Hex. Grid Two layers: - Macro layer: Hex. Grid - Micro layer: Random drop	Single layer: - Hex. Grid

Agreement

For 6GR evaluation, the total transmit power per BS for system-level simulation is assumed as follows:

Total transmit power per BS	Indoor Hotspot	Dense Urban	Rural	Urban Macro	Sub-urban macro
Around 700MHz	NA	Macro BS: Option1: 44 dBm per 20 MHz Option2: 49 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz
Around 2GHz	24 dBm per 20 MHz	Macro BS: Option1: 44 dBm per 20 MHz Option2: 46 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz	Macro BS: Option1: 49 dBm per 20 MHz Option2: 46 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz
Around 4GHz	24 dBm per 20 MHz	Macro BS: Option1: 44 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz	Macro BS: Option1: 49 dBm per 20 MHz Option2: 44 dBm per 20 MHz Option3: 46 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz
Around 7GHz	24 dBm per 20 MHz	Macro BS: Option1: 44 dBm per 20 MHz Option2: 43 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz	Macro BS: Option1: 49 dBm per 20 MHz Option2: 43 dBm per 20 MHz Option3: 46 dBm per 20 MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49 dBm per 20 MHz
Around 15GHz	23dBm per 20MHz	Macro BS: 40dBm per 20MHz Micro BS: 33 dBm per 20 MHz	NA	Macro BS: 49dBm per 20MHz Micro BS: 33 dBm per 20 MHz	Macro BS: 49dBm per 20MHz
Note: BS Tx power scales up with bandwidth proportionally under the limitation of the maximum BS Tx power is 56dBm for outdoor and 33dBm for indoor for the above carrier frequencies.
Around 30GHz	- Option1: 23 dBm per 20 MHz - Option2: 16dBm per 20MHz.	Micro BS: 33 dBm per 20 MHz	NA	Micro BS: 33 dBm per 20 MHz	Macro BS: 33 dBm per 20 MHz
Note: For around 30GHz, BS Tx power scales up with bandwidth proportionally under the limitation of EIRP 75dBm.

Note: Single company Apple objects this agreement with the argument that BS Tx power 56dBm for 400MHz is too small.

Agreement

For FTP Model 3, the packet delay budget (PDB) can be additionally considered,

The latency characteristic of the traffic in RAN side (i.e., air interface) is modelled as packet delay budget (PDB). The PDB is a limited time budget for a packet to be transmitted over the air from a BS to a UE for DL, or from a UE to a BS for UL.

For a given packet, the delay of the packet incurred in air interface is measured from the time that the packet arrives at the BS to the time that it is successfully transferred to the UE for DL, or from a UE to a BS for UL. If the delay is larger than a given PDB for the packet, the packet is said to violate PDB, otherwise the packet is said to be successfully delivered.

Values for PDB, e.g., {10ms, 20ms, 30ms, 50ms, 100ms, 200ms, 300ms, 1000ms, 2000ms} can be considered.

Which values will be used will consider the use case for the evaluations.

Agreement

For 6GR evaluations related to Massive Communication (IoT),

For comparability with 5G results and verify that 6G can meet the IMT-2030 connection density requirements, the mMTC traffic model from IMT-2020 (TR 37.910) may be used as a starting point. This traffic model can be applied in UL or DL.

FFS: necessity of new traffic model(s) for 6GR evaluation in RAN1, e.g., for the following traffic types.

Triggered/polled reporting

Autonomous reporting (event-driven or periodic)

Remote actuation

Firmware/software upgrade

Working Assumption

For 6GR evaluations related to immersive communications services, the following two amended XR models based on the existing XR traffic model (in TR 38.838) can be considered:

Model-1: eXR model without Haptics

Regarding the statistical parameters for single stream CG traffic model defined in Table 5.4.1-1 TR 38.838, add values for immersive gaming regarding the data rate and the frame generation rate as in red:

Parameters	unit	Baseline values for evaluation	Optional values for evaluation	Values for immersive gaming
data rate: R	Mbps	30, 8	45	100, 300, 500
frame generation rate: F	fps or Hz	60	90,120
PDB	ms	15	10, 30	15, or 10, 30

Regarding the statistical parameters for packet size following truncated Gaussian distribution in Table 5.1.1.1-1 TR 38.838, add values for immersive gaming regarding STD, Max, and Min values as in red:

Parameter	unit	Baseline values for evaluation	Optional values for evaluation for single eye buffer	Values for immersive gaming
Mean: M	byte	R×1e6 / F / 8	R×1e6 / F / 8	R×1e6 / F / 8
STD	byte	10.5% of M	3 % of M	[25 %] of M
Max	byte	150% of M	109% of M	300% of M
Min	byte	50% of M	91% of M	25% of M
R: data rate of the flow in Mbps. F: frame generation rate of the flow in fps. Note that the mean and STD apply before truncation applies. Note that the value of R, F depend on application.

Regarding the statistical parameters for AR UL Model 1 defined in Table 5.5.2.1-1 TR 38.838, add values for UL-heavy video uploading regarding packet size, generate rate, data rate, and PDB values as in red:

Parameters	unit	value	Values for UL video uploading
Packet size	byte	Follows clause 5.1.1.1 (i.e., mean packet size = R×1e6 / F / 8, STD/Min/Max=10.5/50/150%)	1st candidate: Follows clause 5.1.1.1 (i.e., mean packet size = R×1e6 / F / 8, STD/Min/Max=10.5/50/150%) 2nd candidate: Follows clause 5.1.1.1 (i.e., mean packet size = R×1e6 / F / 8, STD/Min/Max=[25]/25/300%)
packet generation rate: F	Hz	60	15, 30
Jitter	ms	Optional, follows the description in clause 5.1.1.2	Optional, follows the description in clause 5.1.1.2
Data rate: R	Mbps	10 (baseline), 20 (optional)	20, 60, 100
PDB	ms	30 (baseline), 10 or 15 or 60 (optional)	10, 15

The jitter is modelled the same as XR traffic model.

Model-2: eXR model with Haptics

Haptics traffic is defined as XR traffic packet generation with co-generated haptics packets.

FFS on how to generate the multi-channel haptics packet including how to handle silent periods of haptics and the haptics packet sizes.

FFS on how to co-generate haptics packets and the XR traffic packets.

Haptics packets has packet delay budget (PDB) of either 12 msec or 30 msec, which can be selected as a traffic model parameter.

Send LS to SA4 to inform about the above agreement and check if SA4 has related inputs for the model.

Note: whether the working assumption can be confirmed relies on SA4’s response

Agreement

For 6GR evaluation, the following are assumed for system-level simulation:

Parameters	Indoor Hotspot	Dense Urban	Rural	Urban Macro	Suburban Macro
ISD	20m, equivalent to 12TRxPs per 120m x 50m	Macro layer: 200m	ISD 1: 1732m ISD 2: 5000m	Macro: 500m	ISD 1: 1299m ISD 2: 1732m
BS antenna height	3m	25m for macro cells and 10m for micro cells	35 m	25m for macro cells and 10m for micro cells	Alt 1: 35m Alt 2: 25m
BS noise figure	Around 7GHz and below: 5dB Around 15GHz and above: 7dB
UE antenna height	TR38.901 Indoor-Office Table 7.2-2	TR38.901 UMi/UMa Table 7.2-1	TR38.901 RMa Table 7.2-3	TR38.901 UMa Table 7.2-1	TR38.901 SMa Table 7.2-5
UE noise figure	Around 7GHz and below: [7, 9]dB Around 15GHz and above: 13dB, 10dB
UE Receiver	MMSE-IRC as the baseline [R-ML Receiver as optional]
UE Power control parameter for UL	Company report
Channel model	TR 38.901 v19.1.0 Indoor-Office	TR 38.901 v19.1.0 UMa/UMi	TR 38.901 v19.1.0 RMa	TR 38.901 v19.1.0 UMa	TR 38.901 v19.1.0 SMa, 0% vegetation.
Numerology	In line with AI 11.3
Scheduling	Proportional fairness (PF)
Inter-cell interference model	Explicitly and realistically modelled
Inter-cell interference estimation model	Alt 1: Ideal, calculated by ground truth channel matrix Alt 2: Realistic model, Company report, e.g., Wishart distribution-based model; retain only diagonal elements of interference Cov. Matrix.
Channel estimation assumption	Alt 1: Ideal for benchmark Alt 2: Realistic, company report, e.g., direct/explicit RS estimation, apply gauss noise to real channel matrix, or random
Feedback assumption	Alt 1: Ideal Alt 2: Realistic, company report, e.g., consider feedback delay and overhead; codebook;
O2I penetration loss (X% high loss, Y% low loss)	NA	Two options are supported: Option 1: 80% low loss, 20% high loss; Option 2: 50% low loss, 50% high loss	100% low loss	Two options are supported: Option 1: 80% low loss, 20% high loss; Option 2: 50% low loss, 50% high loss	Option 1: 100% Low-loss A Model as TR38.901. Option 2: 50% Low-loss A 50% Low-loss Model as TR38.901.
Mechanic tilt	180° in GCS (pointing to the ground) as baseline	90° in GCS (pointing to horizontal direction) as baseline. Company can report if not follow the baseline.	90° in GCS (pointing to horizontal direction) as baseline. Company can report if not follow the baseline.	90° in GCS (pointing to horizontal direction) as baseline. Company can report if not follow the baseline.	Baseline: 95° in GCS (pointing to horizontal direction) for ISD = 1299m; 92° in GCS (pointing to horizontal direction) for ISD = 1732m; Company can report if not follow the baseline.
Electrical tilt	Company can report other values for evaluations.	Company can report other values for evaluations.	Company can report other values for evaluations.	Company can report other values for evaluations.	Company can report other values for evaluations.
Handover margin (dB)	1dB as baseline. 0dB and 3dB as optional configuration.	1dB as baseline. 0dB and 3dB as optional configuration.	1dB as baseline. 0dB and 3dB as optional configuration.	1dB as baseline. 0dB and 3dB as optional configuration.	1dB as baseline. 0dB and 3dB as optional configuration.
UE attachment	Based on RSRP from BS
Wrapping around method	No wrapping around	Geographical distance-based wrapping	Geographical distance-based wrapping	Geographical distance-based wrapping	Geographical distance-based wrapping
Multi-TRP operation, e.g., ideal or non-ideal backhaul/sync	Backhaul: ideal or non-ideal; sync: ideal or non-ideal; Company reports the assumptions of the non-ideal backhaul/non-ideal sync.

R1-2509385	FLS#1 on evaluation assumptions for 6GR air interface	Moderator (Huawei)

R1-2509386	FLS#2 on evaluation assumptions for 6GR air interface	Moderator (Huawei)

R1-2509387	FLS#3 on evaluation assumptions for 6GR air interface	Moderator (Huawei)

R1-2509388	FLS#4 on evaluation assumptions for 6GR air interface	Moderator (Huawei)

R1-2509389	FLS#5 on evaluation assumptions for 6GR air interface	Moderator (Huawei)

R1-2509390	FLS#6 on evaluation assumptions for 6GR air interface	Moderator (Huawei)

R1-2508321	Evaluation assumptions for 6GR air interface	FUTUREWEI

R1-2508335	On Evaluation Assumptions for Study of 6G Radio Air Interface	Nokia

R1-2508431	Evaluation methodology and assumptions for 6GR air interface	vivo

R1-2509504	Evaluation methodology and assumptions for 6GR air interface	vivo

(Revision of R1-2508431)

R1-2508454	Discussion on evaluation assumptions for 6GR air interface	CMCC

R1-2508524	Discussion on evaluation assumptions for 6GR air interface	ZTE Corporation, Sanechips

R1-2508580	Discussion on evaluation assumptions for 6GR air interface	CATT

R1-2508620	Evaluation assumptions for 6GR air interface	Lenovo

R1-2508627	Discussion on 6G Evaluation Requirements	NEC

R1-2508632	Evaluation assumptions for 6GR air interface	InterDigital, Inc.

R1-2508638	Evaluation Assumptions for 6GR Air Interface	AT&T

R1-2508683	Discussion on evaluation assumptions for 6GR air interface	Xiaomi

R1-2508726	Evaluation assumption for 6GR air interface	OPPO

R1-2508734	Evaluation assumptions for 6GR air interface	Huawei, HiSilicon

R1-2508801	Evaluation assumptions for 6GR	Samsung

R1-2508865	Evaluation assumptions for 6GR	Intel

R1-2508909	Discussion on evaluation assumptions for 6GR air interface	LG Electronics

R1-2508934	Evaluation Assumptions for 6GR Air Interface	Tejas Network Limited, CEWiT, IIT Madras

R1-2508937	Evaluation assumptions for 6GR air interface	NVIDIA

R1-2508972	Discussion on evaluation assumptions for 6GR air interface	ETRI

R1-2509052	On Evaluation Assumptions for the 6GR air interface	Google

R1-2509055	NTN Characteristics for the Evaluation Assumptions for 6GR air interface	ESA, Thales, Viasat, Eutelsat, Airbus, SES, Hispasat

R1-2509062	Discussion on 6GR evaluation assumptions	Sharp

R1-2509073	Evaluation assumptions for 6GR air interface	Sony

R1-2509079	Fixed Wireless Access Scenarios	T-Mobile USA, Ericsson, Nokia, MediaTek

R1-2509109	Evaluation assumptions for 6GR air interface	Apple

R1-2509117	Evaluation assumptions for 6GR	Ericsson AB.

R1-2509132	Discussion on Evaluation assumptions for 6GR air interface	Ofinno

R1-2509142	Evaluation assumptions for 6GR air interface	MediaTek Inc.

R1-2509230	Evaluation assumptions for 6GR air interface	Qualcomm Incorporated

R1-2509281	Discussion on Evaluation assumptions for 6GR air interface	NTT DOCOMO, INC.

R1-2509335	Views on evaluation assumptions for 6GR air interface	CSCN

Waveform and frame structure for 6GR air interface

Waveform

Including proposals for improving spectrum efficiency, power efficiency, coexistence and coverage, etc.

[123-R20-6GR-Waveform] Email discussion on Rel-20 6GR-Waveform – Karri (Nokia)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

Add the following metrics for UL PAPR reduction to the existing agreement (made in RAN1#122b)

Net gain@10% BLER assuming similar spectral efficiency and same occupied bandwidth for each compared method

ACLR, EVM, IBE

Agreement

General evaluation assumptions for UL low-PAPR proposals

3GPP 6GR
Carrier frequency and scenario	4GHz
Channel BW	At least 100MHz for Urban (4GHz)
Occupied BW	To be discussed with detailed simulation assumptions
SCS	30 kHz for 4GHz
Channel model	TDL-C 300ns for 4GHz
UE speed	3km/h
Number of Tx antennas for TDL channel	1
Number of Rx antennas for TDL channel	1 and 4 for 4GHz
Number of DMRS symbols/slot (location as defined in NR)	2
Number of PUSCH data symbols/slot	12
HARQ configuration	No retransmissions
Frequency hopping	Disabled

Agreement

For single user evaluation assumption for MCS and subcarriers UL low-PAPR proposals with spectrum extension

No Spectrum Extension	With Spectrum Extension
MCS	#subcarriers	#SCs before extension )	Occupied BW: #SCs after extension ()	Spectrum extension Extension:
NR MCS

For single user evaluation assumption for MCS and subcarriers UL low-PAPR proposals with spectrum truncation

No Spectrum Truncation	With Spectrum Truncation
MCS	#subcarriers	#SCs before truncation )	Occupied BW: #SCs after truncation ()	Spectrum truncation factor Truncation:
NR MCS	𝐵

Note: other values for extension or truncation are not precluded.

Agreement

For both CP-OFDM and DFT-S-OFDM, for single user evaluation assumption for MCS and subcarriers UL low-PAPR proposals with tone reservation.

MCS	Occupied BW: #subcarriers	#reserved tones (inband/sideband)	Ratio of reserve
NR MCS	A/𝐵

Agreement

Table is endorsed to characterize each proposal as a potential RAN1 observation.

Characterization of each waveform proposal

Description
Name of the proposal
Motivation of the proposal	E.g. TN, NTN, ISAC, etc…
Applicable link direction	DL/UL/both
Enhancement to CP-OFDM?	No/Yes
Enhancement to DFT-s-OFDM?	No/Yes
Additional OFDM-compatible waveform?	No/Yes
Target channel(s)/signal(s)	PDCCH/PDSCH/PUCCH/PUSCH/xxx
Target modulation
Motivation / use case	Improved spectral efficiency, …
Key Metric / KPI	Spectral efficiency, …
Key spec impact foreseen
MRSS compatibility	Please explain
Multiplexing/coexistence with other waveforms	Please explain
Multi-user multiplexing	Please explain
MIMO compatibility	Please explain

Agreement

For UL PAPR reduction, values for occupied BW B:

{2, 4, 8, 16, 24, 30, 32, 64, 128, 240, 256} PRBs.

Other PRB allocations are not precluded.

Edge, outer and inner PRB allocations as defined in TS 38.101 should be considered.

Agreement

Performance benefit to be evaluated using both link level and system level simulation.

FFS: metrics

Link level configuration for multi-layer UL waveforms study.

Parameters	Values
Carrier frequency​​	4 GHz
Subcarrier spacing​​	30 kHz​​
UE antenna ports	2, 4
BS antenna ports	64, port reduction is not precluded
FDRA	4, 8, 16, 32, 64​​
Waveform​​s	CP-OFDM DFT-s-OFDM​​
MCS/modulation​​	NR UL MCS table with 256 QAM
Number of layers​	2 layers​​, 4 layers
Channel model​​	CDL-A30​​, TDL-C300, CDL-C300,
UE speed​​	3km/h​​, 30 km/h
Channel est.​​	Practical​
SRS periodicity	To be reported by the company
Receiver	LMMSE
HARQ retransmission​	Disabled
DMRS configuration	Configuration type 1 2 DMRS symbols per slot
Number of PUSCH data	12 symbols
Waveform and MIMO configuration	5G codebook, to be reported by the company
BLER target	10%
Frequency hopping	Disabled
Power class and power mode	Option 1: PC2, total power limited to 26 dBm. MaxRank 2: Each PA is limited to 23 dBm MaxRank 4: Each PA is limited to 20 dBm Option2: PC3, total power limited to 23 dBm. MaxRank 2: Each PA is limited to 20 dBm MaxRank 4: Each PA is limited to 17 dBm

R1-2509530	Feature Lead summary #4 on 6G waveform	Nokia

R1-2508562	Feature Lead summary #1 on 6G waveform	Nokia

R1-2508563	Feature Lead summary #2 on 6G waveform	Nokia

R1-2508564	Feature Lead summary #3 on 6G waveform	Nokia

R1-2508336	Waveform for 6G Radio Air Interface	Nokia

R1-2508367	Considerations for additional 6GR DL waveform	Kyocera Corporation

R1-2508387	Discussion on waveform for 6GR	Spreadtrum, UNISOC

R1-2508394	Discussion on waveform for 6GR	LG Electronics

R1-2508432	Discussion on Waveform for 6GR air interface	vivo

R1-2508455	Discussion on the waveform design for 6G radio	CMCC

R1-2508471	Discussion on waveform for 6GR air interface	THALES

R1-2508595	Discussions on waveform for 6GR	CATT

R1-2508625	Waveform for 6GR Air Interface	Shanghai Jiao Tong University.

R1-2508628	Discussion on 6G Waveform	NEC

R1-2508631	Waveform for 6GR air interface	InterDigital, Inc.

R1-2508647	On 6G waveforms	Ericsson

R1-2508684	Discusson on 6GR Waveform	Xiaomi

R1-2508727	Discussion on waveform and multiple access for 6G Radio	OPPO

R1-2508735	Waveform for 6GR air interface	Huawei, HiSilicon

R1-2508802	Discussion on waveform for 6GR	Samsung

R1-2508833	Waveform for 6G Radio Air Interface	IMU

R1-2508856	Views on the waveform for 6G	ZTE Corporation, Sanechips

R1-2508863	Support for Diverse Waveforms on the 6GR Air Interface	National Spectrum Consortium

R1-2508887	Discussion on waveform for 6GR air interface	Panasonic

R1-2508890	Waveform considerations for 6G Uplink	Wisig, IITH

R1-2508917	Discussions on 6G Waveforms	Lekha Wireless Solutions

R1-2508946	Waveform for 6GR Air Interface	Google

R1-2508973	Discussion on 6GR waveform	ETRI, University of Surrey

R1-2509023	Waveform requirements for 6GR NTN	Aalyria

R1-2509042	Discussion on 6GR waveform design	Hanbat National University

R1-2509049	Discussion on waveform for 6GR air interface	Ruijie Networks Co. Ltd

R1-2509059	Waveform for 6G NR	Cohere Technologies, IIT Delhi

R1-2509074	Considerations for 6GR waveform	Sony

R1-2509110	Waveforms for 6GR air interface	Apple

R1-2509133	Discussion on waveform for 6GR air interface	Ofinno

R1-2509143	Waveform for 6GR air interface	MediaTek Inc.

R1-2509191	Discussion on Waveforms for 6GR	Cohere Technologies, IIT Delhi

R1-2509231	Waveforms for 6GR	Qualcomm Incorporated

R1-2509254	Discussion on waveform for 6GR air interface	Pengcheng Laboratory

R1-2509282	Discussion on Waveform	NTT DOCOMO, INC.

R1-2509303	Discussion on DL DFT-s-OFDM for 6GR	LG Electronics, CATT, Thales, Lenovo, IITH, WiSig

R1-2509322	Study on waveform for 6GR	Sharp

R1-2509338	Waveform design for 6GR air interface	Tejas Network Limited

(Withdrawn)

R1-2509349	Views on 6GR waveforms	CEWiT

R1-2509368	Discussion on Waveforms of 6GR Air Interface	Rakuten Mobile, Inc

R1-2509372	Discussion on Waveform for 6GR Air Interface	Indian Institute of Tech (M)

R1-2509377	Considerations on waveform for 6GR air interface	ITL

R1-2509396	New waveform for 6GR air interface	NICT

R1-2509410	Waveform design for 6GR air interface	Tejas Network Limited

R1-2509413	OSDM for 6GR	University of Sheffield

Frame structure

Including numerology and frame structure (for all duplex types).

[123-R20-6GR-Frame structure] Email discussion on Rel-20 6GR- Frame structure – Xiaodong (CMCC)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Conclusion

Extended CP will not be further studied for TN communication.

Agreement

RAN1 assumes maximum channel bandwidth 800MHz or 400MHz at network side for FR2-1

800MHz or 400MHz, to be down-selected in the future

FFS: 800MHz or 400MHz at UE side.

Agreement

For how to enable UE to support 400MHz bandwidth when a network supports 400 MHz Channel Bandwidth (CBW), the following options 1/2/3/4/5 are considered from RAN1 understanding for studying

Option 5: Variance of Option 3 by assuming single FFT and 2 RF chain.

FFS which aspects of the BB processor in option 3 and 4 should be separated/parallelled.

Note: DL and UL design options may be considered independently.

To provide potential specification impact of each option.

To provide investigations on performance/energy efficiency/cost/complexity for the above options.

Inform RAN4 about the above information.

R1-2509554

R1-2509481	FL summary for Frame Structure (1st round)	Moderator (CMCC)

R1-2508322	Discussion on 6G numerology and frame structure	FUTUREWEI

R1-2508337	Frame Structure and Numerology in 6G Radio Air Interface	Nokia

R1-2508388	Discussion on frame structure for 6GR	Spreadtrum, UNISOC

R1-2508395	Discussion on frame structure for 6GR	LG Electronics

R1-2508433	Discussion on 6GR frame structure	vivo

R1-2508456	Discussion on frame structure for 6GR interface	CMCC

R1-2508462	On 6G frame structure	Ericsson

R1-2508516	Discussion on 6GR Frame structure	TCL

R1-2508535	Discussion of numerology and frame structure for 6GR	Lenovo

R1-2508550	Discussion on frame structure	NEC

R1-2508596	Frame structure for 6GR	CATT

R1-2508615	Discussion on 6G frame structure	China Telecom

R1-2508639	Requirements for 6GR Frame Structure Design	AT&T

R1-2508651	6GR frame structure	InterDigital, Inc.

R1-2508652	Discussion on 6GR Frame structure	Kyocera

R1-2508685	Discussion on 6G frame structure	Xiaomi

R1-2508696	Discussion on 6G frame structure	ZTE Corporation, Sanechips

R1-2508728	Numerology and frame/slot structure for 6G Radio	OPPO

R1-2508736	Numerology and frame structure for 6GR air interface	Huawei, HiSilicon

R1-2508761	Discussion on frame structure enhancements for 6G Radio (6GR) air interface	Tejas Network Limited

R1-2509460	Discussion on frame structure enhancements for 6G Radio (6GR) air interface	Tejas Network Limited

(Revision of R1-2509460)

R1-2508803	Discussion on frame structure design for 6GR	Samsung

R1-2508838	Discussion on 6G frame structure	Transsion Holdings

R1-2508857	Frame Design to Support Efficient MRSS	T-Mobile USA, Nokia, Ericsson

R1-2508881	Discussion on frame structure for 6GR air interface	Panasonic

R1-2508930	Discussion on frame structure for 6GR	Fujitsu

R1-2508974	Discussion on 6GR frame structure	ETRI

R1-2508994	Views on numerology and frame structure design for 6GR	HONOR

R1-2509019	Discussion on 6GR Frame Structure	IMU

R1-2509034	Views on 6G frame structure	Ofinno

R1-2509043	Discussion on 6GR frame structure	Hanbat National University

R1-2509053	Frame Structure for 6GR Air Interface	Google

R1-2509056	Frame Structure for 6GR	Sharp

R1-2509058	On 6G frame structure and numerology	Cohere Technologies, IIT Delhi

R1-2509075	Considerations on 6GR frame structure	Sony

R1-2509111	Numerology and frame structure for 6GR air interface	Apple

R1-2509140	Discussion on 6GR frame structure	KT Corp.

R1-2509144	6G frame structure and numerology	MediaTek Inc.

R1-2509232	Frame sturture for 6GR	Qualcomm Incorporated

R1-2509283	Discussion on Frame structure for 6GR	NTT DOCOMO, INC.

R1-2509312	Frame structure for 6GR	ASUSTeK

R1-2509350	Views on 6GR frame structure	CEWiT

R1-2509369	Discussion on Frame Structure for 6GR Air Interface	Rakuten Mobile, Inc

R1-2509375	Considerations on frame structure for 6GR air interface	ITL

Channel coding and modulation for 6GR interface

Including metrics/criteria that can be used for evaluating technology proposals and for down selecting proposals

R1-2508841	LDPC decoder throughput and chip area	AccelerComm Ltd

Channel coding

[123-R20-6GR-Channel coding] Email discussion on Rel-20 6GR- Channel coding and Modulation – Mengzhu, Chunxuan (ZTE, Apple)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

For Polar code design for UCI with payload size larger than NR range (i.e., larger than 1706 bits), at least the following option is identified for further study

More than 2 segments

Note: The necessity of UCI payload size larger than NR range needs to be confirmed by other agenda(s)

Agreement

For the study of LDPC extension for data rate beyond NR range with acceptable performance-complexity tradeoff,

To provide the initial version of LDPC BG(s) and PCM(s) in the excel spreadsheet by RAN1#124

To provide the required SNR and complexity for target BLER, and the evaluation assumptions of the decoding algorithm

The definition of complexity will be further discussed

FFS: other metrics

Agreement

For the study of LDPC extension for data rate beyond NR range, at least the following evaluation assumptions will be considered.

Parameters	Values or assumptions
Channel	AWGN
Modulation and code rate	Uniform QAM modulations (at least 256QAM,1024QAM) and corresponding code rates in MCS table of 5G NR as starting point
Interleaver	Same as 5G NR
Transport block size (bits with CRC)	TB size reported by company CB size: same as 5G NR CB size: other optional value(s) larger than 8448
Target CB BLER	BLER=10-2, 10-4
Decoding algorithm of LDPC	Layered BP, min-sum Max number of iteration times: 2~20 Decoding order: reversed order

Agreement

For the study of channel coding for small UCI with payload size of 3~11bits, at least considering:

5G RM code

identify the justifiable drawbacks of 5G RM code, if exists, study potential solution(s).

R1-2509580

R1-2508981	FL summary#1 for 6G channel coding	Moderator(ZTE, Apple)

R1-2508982	FL summary#2 for 6G channel coding	Moderator(ZTE, Apple)

R1-2508983	FL summary#3 for 6G channel coding	Moderator(ZTE, Apple)

R1-2508338	Channel Coding in 6G Radio Air Interface	Nokia

R1-2508358	Channel Coding for 6GR Interface	Lekha Wireless Solutions

R1-2508389	Discussion on channel coding for 6GR	Spreadtrum, UNISOC

R1-2508434	Discussion on Channel Coding for 6GR air interface	vivo

R1-2508457	Discussion on channel coding for 6GR interface	CMCC

R1-2508597	Channel coding for 6G network	CATT

R1-2508622	Channel Coding for 6G	Lenovo

R1-2508640	Views on Channel Coding for 6GR	AT&T

R1-2508686	Discusson on 6GR Channel Coding	Xiaomi

R1-2508729	Discussion on 6G channel coding	OPPO

R1-2508737	Channel coding for 6GR air interface	Huawei, HiSilicon

R1-2508804	Discussion on channel coding for 6GR	Samsung

R1-2508821	Discussion on channel coding for 6GR	ZTE Corporation, Sanechips

R1-2508826	Channel coding for 6GR Air Interface	Tejas Network Limited

R1-2508839	Discussion on Channel Coding for Small Block Lengths	EURECOM

R1-2508842	Discussion on channel coding for 6GR	Shanghai Jiao Tong University.

R1-2508870	Channel coding enhancements for 6GR air interface	InterDigital, Inc.

R1-2508910	Channel coding study for 6G	LG Electronics

R1-2508931	Discussion on channel coding for 6GR	Fujitsu

R1-2508935	Discussion on 6G channel coding	C-DOT

(Withdrawn)

R1-2508975	Discussion on 6GR channel coding	ETRI, ESA, Thales

R1-2509047	Study of channel coding aspects in 6G Radio	Fraunhofer IIS, Fraunhofer HHI

R1-2509112	Considerations of 6GR Channel Coding	Apple

R1-2509136	Channel Coding	Spark NZ

R1-2509145	Channel coding for 6GR interface	MediaTek Inc.

R1-2509169	Channel coding for 6GR interface	Ericsson

R1-2509233	Channel coding for 6GR	Qualcomm Incorporated

R1-2509284	Discussion on Channel coding for 6GR	NTT DOCOMO, INC.

R1-2509299	Discussion on channel coding for 6GR air interface	Google Korea LLC

R1-2509351	Views on Channel Coding for 6G	CEWiT

R1-2509370	Discussion on Channel Coding for 6GR	Rakuten Mobile, Inc

R1-2509378	Discussion on 6G channel coding	C-DOT

R1-2509398	On channel coding aspects	Vodafone, AT&T, BT, Bouygues Telecom, Deutsche Telekom, Orange, Telecom Italia, Nokia, SK Telecom, Ericsson, T-Mobile US

Modulation, joint channel coding and modulation

[123-R20-6GR-Modulation, joint channel coding and modulation] Email discussion on Rel-20 6GR-Modulation,joint channel coding and modulation –Jing (Qualcomm)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

For PS/GS fixed MCS performance reporting for 10% BLER (other target x% BLER can also be reported), adopt the following format for simulation as a starting point for result reporting.

NR reference	Scheme A (e.g, PS, 1D-NUC, 2D-NUC etc)
SE	(Mod order, coding rate)	SE point specific parameters	Baseline (uniform QAM) SNR to reach target BLER	Gain/loss in dB wrt NR baseline at target BLER x%
SE x	(modOrder, coding rate)	…
SE y	(modOrder, coding rate)	…
SE z	(modOrder, coding rate)	…
SE point independent assumptions	Common assumptions for the scheme simulated, including channel type (AWGN, SISO, SIMO, MIMO) and antenna configuration, number of spatial layers, number of RB allocated, TB size, shaping algorithm used (including block length), freq domain interleaver applied or not, receiver assumption, precoding assumption, realistic channel estimation, etc

Note: For NR MCS reference, since NR has multiple MCS tables, it is not enough to provide the MCS index. Instead, need to provide the (modulation order, coding rate) pair for the simulated SE

Note: For SE point specific parameters:

For GS, this can be a pointer to the constellation used for this SE point

For PS, this can be a constellation size, coding rate and shaping parameter used for this SE point

Note: Other metrics (at least complexity) will be merged into the same table with other columns, if details of the metrics are agreeable.

Note: For AMC study, if possible, we can use the same table format

Agreement

On how to evaluate complexity, storage requirement, delay and parallelism/serialism for PS and GS compared with uniform QAM.

For PS

The demapper complexity is compared with uniform QAM demapper complexity

Can report the demapper complexity with PS and the demapper complexity of NR MCS with the same spectrum efficiency, and the ratio of the complexities

Also report the number of spatial layers, dm-algorithm used and the receiver type (e.g., LMMSE or rML), and fixed point assumed or floating point assumed.

The Distribution Matcher (DM)/Distribution De-Matcher (DDM) complexity and/or storage requirement as a function of the DM algorithm used (ESS, CCDM, etc), precision of fixed point implementation, block length, and the number of bit levels shaped per symbol

For complexity, can report the complexity normalized by the number of information bits

As a reference, can also report the computation complexity of LDPC decoding with 10 iterations.

For storage requirement, can report the overall storage needed for DM/DDM for supporting all MCS in the MCS table and all shaping related parameters

DM and DDM complexity and storage will be counted separately

The DM/DDM processing delay, parallelism/serialism, as a function of DM design and block length, and their impact to throughput

For GS,

The demapper complexity is compared with uniform QAM demapper complexity

Can report the ratio of GS demapper complexity over the uniform QAM demapper complexity

Also report if 1D-NUC or 2D-NUC is used, # of spatial layers, and the receiver type (e.g., LMMSE or rML)

Also need to report the assumption on complexity counting, e.g, fixed point assumed or floating point assumed

The storage requirement for storing all the constellations corresponding to the MCS indices in the MCS table, as a function of precision of constellation point storage

Processing delay and parallelism/serialism, if applicable, and their impact to throughput

Note: the complexity is represented by the numbers of comparison, addition/subtraction, and multiplication/division operations, normalized by the number of information bits.

Note: For complexity as a function of SE point, will add a column in the already agreed performance reporting table.

Note: For complexity/storage not as a function of SE point, will add a row in the already agreed performance reporting table.

Note: Spec impact will be separately evaluated, include BICM, scrambling, etc

Note:

For 4K uniform QAM DL and 1K uniform QAM UL link level performance study, the following format can be used for performance reporting.

(modOrder, coding rate*1024, SE)	Assumed TX/RX EVM	Channel 1	Channel 2	Channel 3
SNR to achieve target BLER	SNR to achieve target BLER	SNR to achieve target BLER
(10, 900.5, 8.7939) for DL evaluation (8, 916.5, 7.1602) for UL evaluation	Legacy EVM for 1K QAM for DL and 256QAM for UL respectively
(10, 948, 9.2578) for DL evaluation (8, 948, 7.4063) for UL evaluation	Legacy EVM for 1K QAM for DL and 256 QAM for UL respectively
SE1
SE2
SE3
Other parameters

For assumed TX/RX EVM, before we receive any concrete numbers from RAN4, companies can provide their assumptions. One example can be 6dB tighter than the EVM of 1K QAM for DL and 256QAM for UL.

Other parameters include: Channel estimation assumption (genie or realistic), channel configurations (AWGN, SISO, SIMO, MIMO and TX/RX antenna configurations, channel types, number of spatial layers,), assumed residual freq offset range, number of allocated RBs, etc

Two highest MCS points in DL 1K QAM and UL 256QAM in NR added in the table for comparison.

This is preliminary result and not intended for TR

Note: For high order uniform QAM for DL 4K QAM and UL 1K QAM, to provide the UPT with the high order QAM (DL 4K QAM and UL 1K QAM) over the UPT without the high order QAM under the assumed deployment scenario.

Agreement

For PS/GS fixed MCS performance reporting for 10% BLER (other target x% BLER can also be reported), adopt the following format for simulation as a starting point for result reporting.

NR reference	Scheme A (e.g, PS, 1D-NUC, 2D-NUC etc)
SE	(Mod order, coding rate)	SE point specific parameters	Baseline (uniform QAM) SNR to reach target BLER	Gain/loss in dB wrt NR baseline at target BLER x%
SE x	(modOrder, coding rate)	…
SE y	(modOrder, coding rate)	…
SE z	(modOrder, coding rate)	…
SE point independent assumptions	Common assumptions for the scheme simulated, including channel type (AWGN, SISO, SIMO, MIMO) and antenna configuration, number of spatial layers, number of RB allocated, TB size, shaping algorithm used (including block length), freq domain interleaver applied or not, receiver assumption, precoding assumption, realistic channel estimation, etc

Note: For NR MCS reference, since NR has multiple MCS tables, it is not enough to provide the MCS index. Instead, need to provide the (modulation order, coding rate) pair for the simulated SE

Note: For SE point specific parameters:

For GS, this can be a pointer to the constellation used for this SE point

For PS, this can be a constellation size, coding rate and shaping parameter used for this SE point

Note: Other metrics (at least complexity) will be merged into the same table with other columns, if details of the metrics are agreeable.

Note: For AMC study, if possible, we can use the same table format

Agreement

To evaluate the proposal to allow a single spectrum efficiency point to be supported by multiple MCS entries (with different modulation order and coding rate combinations with uniform QAM or with different shaping parameters /coding rate/modulation order for PS/GS).

When providing results, to provide the following information

Details on the design of MCS table with overlapping MCS entries

Performance benefit under different channel and rank assumptions

As baseline, provide performance with legacy 256 QAM MCS table

Can additionally provide performance with legacy 1K QAM MCS table

For PS/GS, provide performance allowing each SE point to be mapped to one or more set of shaping parameters /coding rate

For PS/GS, provide performance allowing each SE point to be mapped to only one set of shaping parameters /coding rate

For uniform QAM, provide performance allowing each SE point to be mapped to one or more modulation order and coding rate pairs

MCS selection mechanism across multiple MCS corresponding to the same spectrum efficiency.

If UE feedback is needed for gNB to select between multiple MCS entries corresponding to the same SE, provide details on what is to be fed back

FFS: How different MPR for different modulation order is captured in the simulation for uplink

FFS: How different EVM for different modulation order is captured in the simulation

For the purpose of this study, the same set of SE points as in legacy uniform QAM table will be used as starting point.

When reporting performance, also report other assumptions, including channel type (AWGN, SISO, SIMO, MIMO) and antenna configuration, number of spatial layers, number of RB allocated, TB size, shaping algorithm used (including block length), freq domain interleaver applied or not, receiver assumption, precoding assumption, realistic channel estimation, etc

To propose how to align shaping parameters or how to align coding rate for facilitating comparison.

R1-2509548	FL summary #3 on modulation, joint channel coding and modulation	Modulator (Qualcomm Incorporated)

R1-2509527	FL summary #3 on modulation, joint channel coding and modulation Modulator (Qualcomm Incorporated)

R1-2509519	FL summary #3 on modulation, joint channel coding and modulation Modulator (Qualcomm Incorporated)

R1-2508339	On Modulation for 6G Radio Air Interface	Nokia

R1-2508356	Modulation, joint channel coding and modulation for 6GR Interface	Lekha Wireless Solutions

R1-2508359	Modulation for 6GR air interface	Ericsson

R1-2508390	Discussion on modulation, joint channel coding and modulation for 6GR	Spreadtrum, UNISOC

R1-2508435	Discussion on Modulation for 6GR air interface	vivo

R1-2508458	Discussion on modulation schemes for 6GR interface	CMCC

R1-2509462	Discussion on modulation schemes for 6GR interface	CMCC

(Revision of R1-2508458)

R1-2508598	Modulation for 6G network	CATT

R1-2508623	Discussion on 6GR modulation	Lenovo

R1-2508641	Views on Modulation for 6GR	AT&T

R1-2508687	Discussion on modulation for 6GR air interface	Xiaomi

R1-2508730	Discussion on modulation, joint channel coding and modulation for 6GR	OPPO

R1-2508738	Modulation for 6GR air interface	Huawei, HiSilicon

R1-2508746	Discussion on modulation for 6GR	Tejas Network Limited

R1-2508805	Disscussion on modulation for 6GR	Samsung

R1-2508822	Discussion on modulation for 6GR	ZTE Corporation, Sanechips

R1-2508871	Modulation, joint channel coding and modulation for 6GR air interface	InterDigital, Inc.

R1-2508888	Discussion on modulation for 6GR air interface	Panasonic

R1-2508911	Discussion on modulation for 6GR	LG Electronics

R1-2508976	Discussion on 6GR modulation	ETRI

R1-2509020	Discussion on Modulation for 6GR Air Interface	IMU

R1-2509044	Discussion on 6GR modulation schemes	Hanbat National University

R1-2509076	Discussion on joint coding and modulation with DBICM	Sony

R1-2509113	On modulation for 6G air interface	Apple

R1-2509146	Modulation for 6GR interface	MediaTek Inc.

R1-2509234	Modulation, joint channel coding and modulation	Qualcomm Incorporated

R1-2509285	Discussion on Modulation	NTT DOCOMO, INC.

R1-2509295	Efficient AIML Constellation Shaping	DeepSig Inc

R1-2509300	Discussion on modulation for 6GR air interface	Google Korea LLC

R1-2509352	Modulation, joint channel coding and modulation	CEWiT

(Withdrawn)

R1-2509371	Discussion on Modulation and JCCM for 6GR Air Interface	Rakuten Mobile, Inc

Energy efficiency

Including evaluation assumptions, proposals for Evaluations, NW power saving, UE power saving, and joint mechanisms taking both NW and UE into account for power saving, targeting to categorize proposals by RAN1#123. From RAN1#124, proposals will be distributed to respective related agenda.

[123-R20-6GR-Energy efficiency] Email discussion on Rel-20 6GR- Energy efficiency – Magnus, Weide (Ericsson, MTK)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Include the following power state for 6G UE power consumption model:

Power State	Characteristics	Relative Power in FR1 (including ~7GHz)	Relative Power in FR2 (including 24.25 GHz – 52.6 GHz)
EE Processing	Processing DL WUS of OFDM-based sequence(s) for wake-up indication and, if applicable, other 6GR signal(s) of OFDM-based sequence(s) for synchronization and/or measurement, in an energy efficient manner, based on the following configuration: FR1 (including ~7GHz) 12-RB and 1/2-RX for reception Residue CFO up to [5] ppm and residue timing offset up to [2] us FFS: Power values X1 for 2-RX FR2 (including 24.25 GHz – 52.6 GHz) FFS Note: No implication on which configuration(s) to be supported by 6GR EE-processing can only be performed during a sleep state with additional power consumption added on top of the sleep power and without triggering transition out of the sleep state. Additional power consumption is the relative power value defined. FFS: Whether/what different value across different sleep states	12 / X1 across 7 symbols for 6GR UE NF	TBD

Agreement

Add the following as one of reference configurations for BS power consumption

Set 4 around 7** GHz
Duplex	TDD
System BW	400 MHz
SCS	30 kHz
Number of TRP	1
Total number of DL TX Rus	256
Total DL power level	[62] dBm
Total number of UL Rx Rus	256
**Pending agreement in 11.2 whether to evaluate 15 GHz.

Agreement

Include the following non-sleep states as 6G UE power consumption model.

Other power state(s) is not precluded

FFS: Configuration and relative power value(s) for EE processing in FR2 (including 24.25 GHz – 52.6 GHz)

Note: Pending agreement in 11.2 whether to evaluate 15 GHz

Power State	Characteristics	Relative Power in FR1 (including around 7GHz)	Relative Power in FR2 (including 24.25 GHz – 52.6 GHz)
EE Processing	Processing DL WUS of OFDM-based sequence(s) for at least wake-up indication and, if applicable, other 6GR signal(s) of OFDM-based sequence(s) for synchronization and/or measurement, in an energy efficient manner, based on the following configuration: FR1 (including around 7GHz) 5 MHz BW, 1-RX / 2-RX for reception; FFS: Power values for 2-RX, i.e., X1, X2, X3 Residue CFO up to [5] ppm and residue timing offset up to [2] us Noise Figure (NF) = 6GR UE NF Reception time up to one slot Note: Whether/how to scale power values for different reception time setting within one slot to be further discussed/decided FR2 (including 24.25 GHz – 52.6 GHz) FFS Note: No implication on which configuration(s) to be supported by 6GR EE-processing can only be performed during a sleep state with additional relative power value added w.r.t. the sleep state and without triggering UE transition out of the sleep state. Additional energy overhead [15], in unit of (relative power x ms), is included for each time entering or leaving EE processing during ultra-deep/deep sleep. Ramp-up or ramp-down time for EE processing is [2] ms.	10 / X1 (during micro sleep) 12 / X2 (during light sleep) 15 / X3 (during other sleep)	FFS
PDCCH-only	No PDSCH and same-slot scheduling; this includes time for PDCCH decoding and any micro-sleep within the slot.	100	175
SSB or CSI-RS proc.	SSB can be used for fine time-frequency sync. and RSRP measurement of the serving/camping cell. TRS is the considered CSI-RS for sync. FFS the power scaling for processing other configurations of CSI-RS.	100	175
PDCCH + PDSCH	PDCCH + PDSCH. ACK/NACK in long PUCCH is modeled by UL power state.	300	350
UL	Long PUCCH or PUSCH or PRACH FFS: Power values for more Tx power levels, i.e., X4, X5, X6, X7	250 (0 dBm) X4 (10 dBm) X5 (15 dBm) X6 (20 dBm) 700 (23 dBm) X7 (26 dBm)	350 (FFS Tx power level)

Agreement

Include the following sleep states for 6G UE power consumption model.

Note: Ultra Deep Sleep is not intended for connected mode

Power State	Characteristics	Relative Power
Ultra Deep Sleep	Time interval for the sleep should be larger than the total transition time entering and leaving this state. Accurate timing or frequency may not always be maintained.	0.05 + Y*
Deep Sleep	Time interval for the sleep should be larger than the total transition time entering and leaving this state. Accurate timing may not always be maintained.	1 + Y* (Optional: 1)
Light Sleep	Time interval for the sleep should be larger than the total transition time entering and leaving this state.	20
Micro sleep	Immediate transition is assumed for power saving study purpose from or to a non-sleep state	45
* Y value equals to 0.1, if EE processing is assumed for the evaluation; zero, otherwise.

Sleep type	Additional transition energy: (Relative power x ms)	Total transition time**
Ultra deep sleep	[40000]	[1600] ms***
Deep sleep	450	20 ms***
Light sleep	100	6 ms
Micro sleep	0	0 ms*
* Immediate transition is assumed for power saving study purpose from or to a non-sleep state ** Ramp-up time is no less than half of the total transition time *** Time for sync/re-sync is not included

Agreement

For evaluation purposes and relative comparison over different candidate energy saving schemes for 6GR, define the following baseline power saving configurations for UE for evaluation purpose for FR1 (including around 7GHz):

5G NR I-DRX (1.28s cycle) for idle mode

Group paging rate (for a PO): TBD

5G NR C-DRX settings of (cycle, on-duration timer, inactivity timer) are assumed for the following 6GR traffic models for connected mode:

VoIP: (40 ms, 8 ms, 10 ms)

FTP3: (160 ms, 8 ms, 100 ms)

Instant message: (320 ms, 8 ms, 100 ms)

XR: (16 ms, 10 ms, 4 ms)

Companies can evaluate and report other traffic(s) and/or configuration(s) with justification

Note: The corresponding evaluation is not intended for energy efficiency comparison with 5G/NR.

Agreement

The following load levels are assumed for BS power savings evaluations:

Empty load:	L = 0%,

Low load:	0 < L ≤ 10%,

Light load:	10 < L ≤ 20%,

Medium load:	20 < L ≤ 40 %,

High load:	L > 40 %.

Agreement

Total DL power level for Set 4 is 57 dBm.

Agreement

The following relative power levels applies to Set 4 for a CAT 1 BS and a CAT 2 BS:

Power state	Set 4
CAT 1 BS	CAT 2 BS
Deep sleep	1	1
Light sleep	31	3.1
Micro sleep	85	7.3
Active DL	530	67
Active UL	175	10

9591

R1-2509404	Summary #1 of 6GR Energy Efficiency Study	Modearators (Ericsson, MediaTek)

R1-2509405	Summary #2 of 6GR Energy Efficiency Study	Modearators (Ericsson, MediaTek)

R1-2509406	Summary #3 of 6GR Energy Efficiency Study	Modearators (Ericsson, MediaTek)

R1-2509407	Summary #4 of 6GR Energy Efficiency Study	Modearators (Ericsson, MediaTek)

R1-2509408	Summary #5 of 6GR Energy Efficiency Study	Modearators (Ericsson, MediaTek)

R1-2509409	Summary #6 of 6GR Energy Efficiency Study	Modearators (Ericsson, MediaTek)

R1-2508323	Discussion on 6G energy efficiency techniques	FUTUREWEI

R1-2508340	Energy Efficiency in 6G Radio	Nokia

R1-2508350	Discussion on energy efficiency for 6GR	TCL

R1-2508391	Discussion on energy efficiency for 6GR	Spreadtrum, UNISOC

R1-2508436	Discussion on 6G energy efficiency	vivo

R1-2508459	Discussion on Energy Efficiency of 6GR interface	CMCC

R1-2508477	6G Study on Energy Savings	Fraunhofer IIS, Fraunhofer HHI

R1-2508478	On 6GR design for energy efficiency	Panasonic

R1-2508581	Discussion on energy efficiency of 6GR	CATT

R1-2508616	Discussion on 6GR energy efficiency	China Telecom

R1-2508624	Discussion on 6GR Energy Efficient design	Lenovo

R1-2508629	Discussion on Physical Layer Design for Energy Savings in 6G	NEC

R1-2508642	Views on Energy Efficiency for 6GR	AT&T

R1-2508646	Energy efficiency in 6GR interface	InterDigital, Inc.

R1-2508688	Discussion on energy efficiency for 6GR	xiaomi

R1-2508731	Energy Saving for 6GR air interface	OPPO

R1-2508739	Views on energy saving for 6GR	Huawei, HiSilicon

R1-2508745	Energy efficiency in 6G	Tejas Network Limited

R1-2508806	Discussion on energy efficiency for 6GR	Samsung

R1-2508823	Discussion on energy efficiency for 6GR	ZTE Corporation, Sanechips

R1-2508864	6GR energy efficiency	Ericsson

R1-2508879	Considerations for 6G energy efficiency	KT Corp.

R1-2508912	Discussion on energy efficiency for 6GR	LG Electronics

R1-2508932	Discussion on energy efficiency for 6GR	Fujitsu

R1-2508977	Discussion on energy efficiency in 6GR	ETRI

R1-2508995	Discussion on energy efficiency	HONOR

R1-2509027	Views on 6GR Energy Efficiency	Ofinno

R1-2509045	Discussion on energy efficiency in 6GR	Hanbat National University

R1-2509077	Considerations on 6GR Energy Efficiency	Sony

R1-2509114	Views on 6G energy efficiency	Apple

R1-2509147	Energy efficiency for 6GR	MediaTek Inc.

R1-2509177	Study on energy efficiency for 6GR	Sharp

R1-2509235	Energy Efficiency in 6GR	Qualcomm Incorporated

R1-2509286	Discussion on Energy Efficiency for 6GR	NTT DOCOMO, INC.

R1-2509309	Discussion on Energy efficiency	ITRI

R1-2509314	Energy efficiency for 6GR	ASUSTeK

R1-2509331	Energy Efficiency in 6GR	Nordic Semiconductor ASA

R1-2509353	Views on Energy Efficiency	CEWiT

R1-2509360	Discussion on 6G energy efficiency	Google

R1-2509361	Energy Efficiency in 6G Radio	ITL

R1-2509383	Discussion on Energy Efficiency for 6G Radio	WILUS Inc.

R1-2509384	Discussion on energy efficiency for 6GR	TCL

R1-2509399	On 6GR energy efficiency power model updates for SBFD	Vodafone, Telecom Italia, Deutsche Telekom, Nokia, Charter, LG Electronics

R1-2509414	Discussion on energy efficiency and energy saving	CAICT

AI/ML in 6GR interface

Collecting AI/ML use cases in all potential components in physical layer design, targeting to select some use cases by RAN1#123. From RAN1#124, selected use cases will be distributed to respective related agenda.

[123-R20-6GR-AI/ML] Email discussion on Rel-20 6GR-AI/ML – Feifei(Samsung)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

Agreement

From RAN 1 perspective, the following use cases can be matched to the identified primary agendas of RAN1

Use cases	Primary agendas
Low overhead CSI-RS or CSI prediction with AI/ML	CSI-RS and CSI acquisition
Low overhead DMRS with AI/ML receiver	UL & DL DMRS associated with PUSCH/PDSCH Note: Sub-Case C: DMRS-free may be related to modulation
CSI compression and feedback	CSI acquisition Note: this may be related to uplink control
AI/ML for beam management and extension	Initial access for Sub-case D Beam management for other sub-cases Note: sub-case A/B/D maybe related to mobility
AI/ML for SRS	Low overhead SRS with AI/ML	SRS
Low PAPR SRS sequence design
AI/ML based SRS power imbalance compensation	Not RAN1-led
AI-enabled UL precoder indication	UL MIMO
AI-based non-linearity handling at transmitter or receiver	Not RAN1-led Note: this may be related to DMRS, SRS, Power control in RAN 1
AI/ML for (de)modulation	modulation Note: Sub-case B may be related to MIMO Note: assuming no change to DMRS
AI/ML based waveform for PAPR reduction	Waveform
AI/ML based HARQ-ACK feedback	Channel coding Note: this may be related to uplink control
PDCCH related	Prior-Information-Aided DCI Decoding	DL control
Lossless DCI Compression
Power control related	UL closed-loop power control	Power control
Pathloss prediction
RACH related design	Early contention resolution in RACH	Random access/PRACH
Low PAPR PRACH sequence design
Site Specific Learning for AI/ML using RAN Digital Twin	Depending on corresponding use case where site specific learning is applicable, e.g., DMRS
Digital twin construction related use cases	AI/ML-enabled RAN digital twin with distributed model	ISAC
Sensing based RAN digital twin construction with NW-side AI/ML model	ISAC
AI for positioning	Positioning related agenda, if any

To accommodate AI/ML service, e.g., token traffic	if any impact, most likely scheduling/HARQ

Agreement

Endorse observation 2.1 ~observation 2.17 in R1-2508811 section 6.

Note: this is to replace the corresponding observation in RAN 1 #122bis

Agreement

For study/evaluation of the performance and feasibility of AI/ML use cases in 6GR, at least the following may be considered

Intermediate performance KPIs (e.g., SGCS), link level KPIs (e.g., BLER) and system level KPIs (e.g., throughput vs overhead), etc

Computation complexity/latency (inference/monitoring)

Power consumption, if feasible to evaluate

Model size

Data collection impact

Scalability (refer to the examples in TR 38.843)

Generalization performance

FFS on whether and how to consider realistic deployment scenarios

Overhead/complexity associated with data collection, inferencing, performance monitoring, online/site specific fine-tuning, inter-vendor collaboration (if applicable)

Online training/fine-tuning training latency, if feasible to evaluate

Inter-vendor collaboration impact, if applicable

Note: Details to be discussed per use case.

Note: above aspects may be considered for both AI/ML and non-AI counter part

R1-2508808	Moderator summary #1 on AI/ML for 6GR	Moderator (Samsung)

R1-2508809	Moderator summary #2 on AI/ML for 6GR	Moderator (Samsung)

R1-2508810	Moderator summary #3 on AI/ML for 6GR	Moderator (Samsung)

R1-2508811	Moderator summary #4 on AI/ML for 6GR	Moderator (Samsung)

R1-2508324	Discussion on AI/ML in 6GR interface	FUTUREWEI

R1-2508341	Views on AI/ML Operation and Use Cases for 6G Radio Air Interface	Nokia

R1-2508351	Discussion on AI/ML-driven use cases for 6GR	BJTU

R1-2508365	AI/ML Use Cases for 6GR Air Interface	Ericsson

R1-2508366	AI/ML in 6GR interface	Kyocera

R1-2508392	Discussion on AIML in 6GR interface	Spreadtrum, UNISOC

R1-2508437	Discussion on AI/ML in 6GR interface	vivo

R1-2508460	Discussion on AI/ML in 6GR interface	CMCC

R1-2508515	AI/ML for 6G Air Interface	InterDigital, Inc.

R1-2508539	Discussion on AI/ML in 6GR air interface	TCL

R1-2508549	Discussion on AIML in 6GR interface	NEC

R1-2508582	AI/ML in 6GR interface	CATT, CICTCI

R1-2508643	AI/ML use cases and framework for 6GR Air Interface	AT&T

R1-2508689	Discussion on AI/ML in 6GR interface	Xiaomi

R1-2508697	Discussion on AI-based Smart Radio for 6G Air Interface	ZTE Corporation, Sanechips

R1-2508732	AIML use cases for 6GR air interface	OPPO

R1-2508740	Views on AI/ML in 6GR air interface	Huawei, HiSilicon

R1-2508753	Discussion on AI/ML in 6GR interface	LG Electronics

R1-2508807	AI/ML Use cases and framework for 6GR	Samsung

R1-2508827	AI/ML Use Cases for 6G RAN	Tejas Network Limited

R1-2508916	Discussion on AI/ML in 6GR interface	Lekha Wireless Solutions

R1-2508933	Discussion on AI/ML in 6GR	Fujitsu

R1-2508947	AI/ML in 6GR Air Interface	Google

R1-2508978	Discussion on AI/ML in 6GR interface	ETRI

R1-2508999	Discussion on AI/ML in 6GR interface	Panasonic

R1-2509001	Views on improved scheduling/HARQ for token traffic	CAICT

R1-2509004	AI/ML in 6GR	Lenovo

R1-2509008	AIML in 6GR air interface	KAIST

R1-2509021	AI and ML in 6GR air interface	NVIDIA

R1-2509022	Discussion on AI/ML in 6GR	IMU

R1-2509039	Views on AI/ML in 6GR interface	Ofinno

R1-2509046	Discussion on AI ML in 6GR air interface	Hanbat National University

R1-2509050	Discussion on AI/ML for 6GR interface	Ruijie Networks Co. Ltd

R1-2509078	Use cases for AI/ML in 6GR Interface	Sony

R1-2509115	On AI/ML for 6G air interface	Apple

R1-2509116	Discussion on AI/ML in 6GR interface	AUMOVIO

R1-2509148	AI/ML in 6GR Air Interface	MediaTek Inc.

R1-2509184	Discussions on AI/ML in 6GR interface	Sharp

R1-2509236	AI/ML in 6GR air interface	Qualcomm Incorporated

R1-2509251	Discussion on AI/ML in 6GR interface	Transsion Holdings

R1-2509287	Discussion on AI/ML for 6GR air interface	NTT DOCOMO, INC.

R1-2509302	Use cases for AI/ML in 6GR interface	KT Corp.

R1-2509354	AI/ML in 6GR Interface	CEWiT

R1-2509373	Discussion on AI/ML in 6GR Interface	Indian Institute of Tech (M)

R1-2509400	On new use cases for AI/ML in 6GR interface	Vodafone, Deutsche Telekom, Nokia

R1-2509411	Discussion on AI/ML-enabled use cases for 6GR	BUPT, ZGC Institute of Ubiquitous-X Innovation and Application, Pengcheng Laboratory

R1-2509417	New use cases for AI/ML in 6GR interface	Pengcheng Laboratory, ZGC Institute of Ubiquitous-X Innovation and Application

R1-2509433	Discussion on AI/ML use cases for 6GR air interface	IIT Kanpur

Initial access

Placeholder only and to be broken down. No contributions before RAN1#124. Including synchronization signal and raster, broadcast signals/channel and physical random access channel, etc.

MIMO operation

Placeholder only and to be broken down. No contributions before RAN1#124.

Physical layer control, data scheduling and HARQ operation

Placeholder only and to be broken down. No contributions before RAN1#124.

Duplexing

Placeholder only and to be broken down or adapted based on the discussion in AI 11.1. No contributions before RAN1#124.

6GR spectrum utilization and aggregation

Placeholder only and to be broken down. No contributions before RAN1#124.

NTN

Placeholder only and to be broken down or adapted based on the discussion in AI 11.1. No contributions before RAN1#124.

Other physical layer signals, channels and procedures

Placeholder only and to be broken down and adapted. No contributions before RAN1#124.

Sensing

Including PHY functions and procedures for sensing technology (e.g., waveform. reference signals, measurement feedback, etc…), aspects of integration with communication services.

Placeholder only and to be broken down. No contributions before RAN1#124b.

Closing of the meeting (Day 5, 4:00 pm at the latest)