What should 6G keep from NR, and where does a new air interface need a different design? The overview contributions connect that question to device cost, coverage, spectrum sharing, energy use, and implementation complexity. A change that helps one of these can make another harder.

Document scope : This page covers the "Overview of 6GR air interface" agenda at RAN1#122, #122bis, and #123, using the supplied TDoc search list and supplementary company filings. The reference cutoff is RAN1#123. The final overview summaries are R1-2506618, R1-2508198, and R1-2509621.

The supplied search list also contains later documents through RAN1#126bis. Those discussions move into specialized agendas, and their later agreements and proposals have not been consolidated into this page. Read the technical status here as the early overview position through RAN1#123, not as the latest 6G air-interface status. Some options described here may have been narrowed or superseded at later meetings.

• Executive Summary
• Mind Map
• Agreed Items
  • RAN1#122 - scope of the common design
  • RAN1#122bis and #123 - more specific study directions
• What should change from NR, and what should stay?
  • Which performance improvement is worth the implementation cost?
• Can one air interface serve very different devices?
  • How can capability signaling avoid another long list of exceptions?
• Which bandwidth is actually being discussed?
  • Should initial access be optimized for the smallest allocation?
• How much synchronization signaling should always be present?
  • Can idle-mode discovery and connected-mode tracking use different signals?
• What does sharing spectrum with NR require?
  • Must NR and 6G share the same signals?
• What should replace the complexity of NR BWP operation?
• Should several carriers remain several cells?
  • Why separate UL and DL carrier choices?
• How do coverage and duplexing constrain the common design?
  • Which duplex modes were included in the early study?
• How far can TN and NTN share the same design?
  • What remains different when timing and GNSS assumptions change?
• What do MIMO and control proposals ask the common framework to support?
  • Can control be simpler without becoming less reliable?
• How do FWA, AI/ML, and sensing fit without separate air interfaces?
• Update Note
• Reference

Executive Summary

Following is a guide to the main choices in the reviewed overview documents.

Mind Map

Which choices shape the common air interface? The map connects device capability and access design to spectrum use, coverage and control. Follow the service branch to see where FWA, AI/ML and sensing add requirements to that framework.

Expand a branch with + to reveal its topics and descriptive comment leaves. Select a topic for a link to its detailed section. Drag the background or a comment leaf to pan. Hold the left mouse button and turn the mouse wheel to zoom around the pointer. The toolbar also provides zoom, Expand all, Collapse all and Reset view. Keyboard users can Tab to controls and press Enter or Space.

NOTE: This map follows the overview source window through RAN1#123. Later specialized-agenda decisions are outside its scope. Connecting lines group related design questions; they do not define a procedure or a finalized architecture. A study agreement is distinct from selecting a mechanism or making it mandatory.

Agreed Items

The final summaries separate meeting agreements from incoming proposals and moderator discussion text. The entries here follow their conclusion sections. An agreement to study a mechanism does not make that mechanism mandatory.

RAN1#122 - scope of the common design

The first overview meeting established the questions to investigate across devices and deployments. Most entries define study scope, with device classification and spectrum assumptions still subject to further discussion in RAN.

• Scalable design : study functions that can apply to all device types, with device-specific additions left for further study.
• Bandwidth : consider the minimum spectrum allocation with RAN4 involvement. Separately study 3, 5, 10, and 20 MHz as the smallest maximum UE RF/BB bandwidth for at least one low-tier device. UL/DL differences and RF/BB differences remain open.
• NR lessons : identify lessons from BWP, spectrum aggregation, duplexing, and LTE-NR DSS. Identify aspects affecting NR-6GR MRSS and synchronization structure/periodicity.
• Coverage and NTN : identify coverage targets across use cases and devices, and identify technical aspects affected by NTN characteristics.

These are historical #122 agreements from R1-2506618. The bandwidth alternatives are not a current list of selected device capabilities. The duplexing study scope is explained under coverage and duplexing.

RAN1#122bis and #123 - more specific study directions

The next two meetings made the design questions more concrete. They identified synchronization and NTN considerations, narrowed the common-function discussion, and established conditional alternatives for initial access in a small allocation.

• RAN1#122bis synchronization : consider raster, spectrum allocation, lowest UE bandwidth, coverage, common device design, deployment, and detection/tracking performance, latency, complexity, and BS/UE energy. Mobile broadband service requirements have high priority. Periodicity aspects are handled under the energy-efficiency agenda.
• RAN1#122bis NTN : consider initial access, coverage, duplexing, capacity, signaling overhead, GNSS operation, varying Doppler/delay, and beamforming/management/hopping.
• RAN1#123 common applicability : consider initial access, other PHY functions after access such as DL/UL control and scheduling/HARQ, coverage, BS/UE energy saving, and MRSS. Whether support is mandatory, optional, or provided at all is explicitly a separate question.
• RAN1#123 conditional 3-MHz study : if the minimum allocation is 3 MHz at 15 kHz SCS, consider either a wider common-signal design with adjustments or a common design targeting 3 MHz. The scope includes at least SSB. This does not select either option.
• RAN1#123 low-tier bandwidth assessment : consider overall device complexity, system performance, and BS/UE energy. Aim for common idle-mode/access signals across devices, with mobile broadband requirements prioritized.
• RAN1#123 coverage method : use the two link-budget template candidates as a starting point, with Rel-15 NR Msg3 as the initial-access reference bottleneck. Data-channel target rates remain for further study in that record.

The sources are R1-2508198 and R1-2509621. The #123 summary also endorses the TR 38.760-1 v0.0.3 skeleton; endorsing that structure does not adopt all technical proposals discussed alongside it.

What should change from NR, and what should stay?

A new radio generation gives the study room to remove old constraints. But replacing a working function also costs implementation effort, testing, and deployment changes. The overview papers disagree on where that balance should sit.

One position follows a keep-change-add approach: retain useful NR mechanisms, change demonstrated weaknesses, and add functions with clear benefits. It argues against optimizing the main design around rare cases. Another emphasizes long-term design freedom without a backward-compatibility constraint to the NR air interface. These positions differ in their starting assumptions, even when both call for simpler implementations. R1-2508352, R1-2509229.

Hardware reuse is a separate question from protocol compatibility. A joint proposal seeks deployment with existing open radios where practical, while allowing new designs when a real deployment need justifies them. Another distinguishes reusing radio units for MRSS from expecting compatibility with a monolithic NR distributed-unit platform. Neither establishes that every existing radio can support every proposed 6G function. R1-2506238, R1-2509229.

Which performance improvement is worth the implementation cost?

The proposed evaluation priorities go beyond peak data rate. They include median and cell-edge performance, bursty traffic, latency tails, and the interaction between uplink and downlink across the protocol chain.

A full-buffer gain may not capture delays before a short packet can be transmitted. Likewise, a downlink improvement can depend on timely uplink feedback. The overview therefore calls for realistic traffic and control procedures in the comparison. A joint operator contribution also asks proponents to explain changes from NR and their performance/complexity trade-offs. R1-2508352, R1-2509141, R1-2509397.

The same joint contribution proposes using BS and UE energy models in the relevant technical agendas. That includes AI/ML, duplexing, and sensing. Its request is to assess energy consequences alongside functionality, rather than assume that a new feature saves energy because it supports an energy-saving use case.

• Keep the comparison concrete : identify the NR baseline, the changed mechanism, and the deployment or traffic condition that benefits.

Can one air interface serve very different devices?

The common-design problem starts before peak data rate. A low-tier device must discover the cell and enter the system. A higher-capability device needs a way to add performance without creating a separate access technology.

One proposed framework starts with a lean mandatory baseline and adds device-specific function sets. It distinguishes scalability within a device type from scalability between types. A function mandatory for a sensing device, for example, would not automatically become mandatory for every UE. The lowest-tier IoT set is suggested as a starting point, while extreme IoT-specific enhancements can remain outside the universal baseline. R1-2508725.

Other proposals emphasize common function features, capability prerequisites, or mandatory capability sets associated with use cases. Their concern is that individually optional features can leave the network unable to rely on a useful combination. However, the #123 agreement only identifies areas to consider as commonly applicable. It explicitly leaves mandatory and optional support to a separate discussion. R1-2508800, R1-2509280, R1-2509621.

How can capability signaling avoid another long list of exceptions?

A capability framework has to express real hardware differences without allowing every possible combination. The contributions connect this to implementation, interoperability testing, and the functions a network can safely assume are available.

Proposals include prerequisites between capabilities, grouped capabilities for a use case, early device identification, and event-based capability updates without returning to idle mode. These are different mechanisms. The overview does not select one common signaling format or a final device-category system. R1-2508352, R1-2508800, R1-2509108.

The joint operator/vendor filings add a deployment concern: declaring a feature mandatory does not establish tested support throughout the ecosystem. They propose meaningful feature groups and aligned testing/certification. That is an input to the study, not an approved certification procedure in these records. R1-2505865, R1-2506238.

• Common applicability is not mandatory support : keep the agreed study scope separate from proposed capability policies.

Which bandwidth is actually being discussed?

The overview uses several bandwidth quantities that can sound interchangeable. They answer different questions: what spectrum the operator has, what a UE can process, and what the common signals need during initial access.

The minimum spectrum allocation concerns the deployment. The smallest maximum supported UE bandwidth concerns a low-tier device's capability. The common-signal bandwidth concerns the access design that devices must receive. RF and baseband bandwidth can also differ, and UL and DL need not have identical capabilities in the candidate designs. R1-2508334, R1-2509108, R1-2509621.

Figure 1 separates these questions. The labels are a conceptual guide to the discussion, not standardized parameter names or an agreed relationship between three numerical values.

Figure 1. A narrow spectrum allocation does not by itself determine the maximum bandwidth capability of a low-tier UE.

Should initial access be optimized for the smallest allocation?

Two approaches remained in the #123 agreement if the allocation were 3 MHz at 15 kHz SCS. One starts wider and adapts; the other targets the narrow allocation from the beginning.

The wider-design position seeks good performance for common deployments, with puncturing or other adjustments for narrow allocations. The narrow-design position seeks one access design usable across allocations without that adaptation penalty. Proposals also consider narrower frequency occupancy with more OFDM symbols or a more compact MIB. These choices affect detection, PBCH performance, and the synchronization raster. R1-2508334, R1-2508725, R1-2509141.

Device proposals illustrate why the quantities must remain separate: one favors 20-MHz RF and BB capability, while another proposes 20-MHz RF with 5-MHz BB. These are #123 company positions, not agreed minimum UE bandwidths. R1-2508733, R1-2508800.

• Keep the bandwidth qualifier : spectrum allocation, signal occupancy, RF capability, and BB capability cannot be replaced by one unqualified minimum-bandwidth number.

How much synchronization signaling should always be present?

Reducing always-on signaling gives the network more opportunities to sleep. But a UE entering the cell still needs to discover it, decode system information, and reach random access with acceptable delay and energy use.

The #122bis agreement therefore treats synchronization as a joint problem involving raster, bandwidth, coverage, detection, tracking, latency, complexity, and BS/UE energy. It also asks whether a single synchronization structure is sufficient. That is broader than choosing an SSB periodicity. R1-2508198.

The proposals span different periodicities and operating roles. One favors a 160-ms default for idle-mode synchronization. Another studies 40/80-ms always-on SSBs for idle/inactive UEs, with on-demand signaling for connected UEs. These values belong to different candidate designs; the overview's conclusion section does not select one universal period. R1-2508352, R1-2509108.

Can idle-mode discovery and connected-mode tracking use different signals?

An idle UE has limited configuration knowledge, while a connected UE can receive dedicated configuration. Several proposals use that difference to reduce how many functions depend on the same always-on signal.

Candidate designs separate cell discovery from connected-mode tracking, beam management, or mobility. One favors on-demand PSS/SSS in addition to always-on idle-mode signals. Another proposes a dedicated mobility reference signal. A third retains periodic TRS as a connected-mode baseline. The common motivation does not make these implementations equivalent. R1-2508352, R1-2509141, R1-2509108.

A sparser synchronization raster could reduce the search burden associated with longer periods. But it also restricts deployment choices. The access design must consider whether a UE can receive the synchronization signal while operating in a narrower, differently located bandwidth. The bandwidth-adaptation discussion cannot assume that this has already been solved. R1-2508334, R1-2509141.

• Count both sides of energy saving : network sleep gains need to be considered alongside UE searching, waiting, and acquisition behavior.

What does sharing spectrum with NR require?

MRSS is a migration mechanism as well as a resource-allocation problem. The proposed designs aim to introduce 6G while NR users remain in the same spectrum, with practical limits on coordination and hardware replacement.

The joint deployment contribution asks for MRSS from the first release, without changes to existing NR UEs. It also asks that waveform, frame structure, and numerology studies consider coexistence early. Other proposals seek alignment of RB and slot boundaries and compatibility with deployed TDD directions. These are design inputs in the overview, rather than a complete agreed MRSS procedure. R1-2505865, R1-2508334, R1-2508352.

Must NR and 6G share the same signals?

Sharing spectrum does not require every signal to be shared. The proposals distinguish partitioning resources, avoiding the other RAT's transmissions through rate matching, and deliberately reusing compatible signals or channel resources.

One position favors transparent TDM/FDM as the baseline where traffic changes slowly and resources can be separated. It questions sharing SSB because that could constrain 6G coverage and energy improvements. Another investigates CORESET sharing and orthogonal DMRS resources for joint spatial multiplexing. A third treats signal sharing as a signal-by-signal feasibility question while retaining rate matching for at least some signals. R1-2508800, R1-2509141, R1-2509280.

The disagreement concerns both overhead and constraints on future design. Sharing a control region may reduce duplicated resources, but can restrict its layout or require tighter scheduling coordination. Separate 6G synchronization can preserve design freedom, while increasing the resources used for coexistence. The overview does not justify converting either approach into a universal rule.

The candidate deployment assumptions also matter. Some proposals focus on collocated NR/6G cells and existing FR1 bands; others leave broader scenarios for study. A result based on a shared site and synchronized scheduling should not automatically be extended to independently coordinated sites. R1-2508725.

• Separate migration goals from mechanism selection : early MRSS support does not establish shared SSB, shared CORESET, or a particular rate-matching design.

What should replace the complexity of NR BWP operation?

The contributions generally recognize the value of operating a UE over less than the full carrier bandwidth. Their disagreement is about how much configuration should change, how fast it should change, and how failures are handled.

Reported concerns include too many BWP-specific parameters, long switching delays, signaling overhead, and disagreement between UE and network after a missed switching command. Switching to a non-overlapping bandwidth makes the last problem particularly relevant because the old control resources may no longer be monitored. These are reported NR lessons in the proposals, not evidence that every BWP deployment has the same weakness. R1-2508733, R1-2509141.

One proposal separates reliable, slower adaptation from fast, limited adaptation for energy saving. Another keeps a fixed anchor BWP containing essential control resources while changing the wider operating bandwidth. A third would avoid dynamic BWP switching if dynamic CORESET/search-space switching already provides the needed behavior. These candidates change different parts of the control relationship. R1-2509229, R1-2509108, R1-2509280.

There is also a proposal to separate scheduling grants from commands that change receive/transmit bandwidth. Its purpose is to avoid combining a data-scheduling decision with a change in where the UE can receive control. Other proposals retain a DCI-based fast mechanism but require resilience to UE/network misalignment. The overview leaves that trade-off open. R1-2508352, R1-2509229.

RAN4 involvement is repeatedly requested because RF switching, center-frequency changes, and power restrictions affect practical behavior. Simplifying RRC parameters alone would not demonstrate a faster or more energy-efficient RF transition. R1-2508334, R1-2509141.

• Define what changes during adaptation : bandwidth, frequency location, control monitoring, and other configuration changes need separate justification.

Should several carriers remain several cells?

The aggregation discussion asks how to use fragmented spectrum without multiplying configuration and control overhead. It also asks whether downlink and uplink should remain tightly paired when their best coverage and capacity resources differ.

One direction retains CA as the main framework and improves activation speed, UL/DL pairing, and coordination requirements. Another maps multiple physical carriers into one cell or logical wideband resource. The proposed names differ, but the intended benefits include less duplicated common signaling and fewer per-carrier scheduling or HARQ constraints. R1-2508334, R1-2508733, R1-2508725.

The multi-carrier-cell proposal is not automatically simpler in every implementation. One contribution asks first for a demonstrated advantage over enhanced CA, then for limits on frequency span, RF chains, and UE capability. Another prioritizes loose network-side coordination so that different sites or schedulers can participate. These conditions matter when comparing the candidate frameworks. R1-2509108, R1-2508334.

Why separate UL and DL carrier choices?

A wider or higher-frequency downlink does not imply that the same carrier is the best uplink. The proposals seek more freedom to use lower-frequency coverage and available uplink resources without adding unnecessary RF chains.

Candidate mechanisms include flexible UL/DL pairing, UL transmit switching, and DL carrier switching. One approach favors deterministic semi-static UL switching patterns. Others seek flexible native switching integrated with retransmissions, repetition, and control. A comparison must preserve the different coordination and processing-time assumptions. R1-2509108, R1-2509141.

Faster SCell activation is another recurring request. Keeping a carrier active can avoid activation delay but consume energy; switching it off reverses that trade-off. Direction-specific activation and on-demand signaling are proposed ways to reduce this conflict. None is established as the final aggregation framework by the overview agreements. R1-2509229, R1-2509280.

• Separate RF capability from resource grouping : putting carriers into one logical cell does not remove the UE's bandwidth, RF-chain, or switching constraints.

How do coverage and duplexing constrain the common design?

The overview connects new-band deployment to existing sites, but does not reduce coverage to one receiver-sensitivity number. Initial access, data rate, antenna assumptions, and the uplink bottleneck all affect the comparison.

The #123 agreement uses Rel-15 NR Msg3 as the initial-access reference bottleneck and considers urban and suburban macro scenarios, both outdoor and outdoor-to-indoor. Its recorded reference frequency is still written as [4 GHz], with 7 GHz for the new deployment. Those brackets are part of the historical uncertainty; this is not a final frequency assumption for all later evaluations. R1-2509621.

Company proposals also use different metrics. One favors MPL for cross-band comparison and MCL for imbalance across channels. Another proposes MaxCL targets linked to specific data rates and receive-antenna assumptions. A larger isolated dB value therefore does not establish better coverage under comparable conditions. R1-2509280, R1-2508352. The later discussion is developed separately in Coverage Enhancement.

Which duplex modes were included in the early study?

The #122 agreement separates modes to consider from modes whose inclusion itself needs study. That distinction matters because an early overview list can otherwise look like a confirmed first-release feature list.

The first group includes full-duplex FDD, semi-static TDD, gNB semi-static SBFD, UE half-duplex FDD, and dynamic TDD. The second asks whether to consider gNB dynamic SBFD, UE SBFD, and gNB full duplex. Other modes are not precluded. This is the scope recorded in R1-2506618.

Subsequent proposals promote network-side semi-static SBFD for uplink coverage and latency, while also raising energy and implementation questions. Low-PAPR uplink transmission, repetitions, antenna changes, and UL/DL decoupling provide other directions. The overview does not quantify one combined gain that can be applied to every channel and deployment. R1-2509229, R1-2508800, R1-2509397.

• Keep the complete coverage condition : metric, data rate, channel, device, and deployment assumptions belong beside a coverage target.

How far can TN and NTN share the same design?

The NTN discussion starts from a practical concern: adding satellite support later can require changes to procedures already fixed for terrestrial use. The proposals seek early commonality while accounting for different timing, frequency, and coverage conditions.

The #122bis agreement identifies initial access, coverage, duplexing, capacity, signaling overhead, GNSS operation, Doppler, propagation delay, and beam management/hopping as relevant aspects. It does not select one satellite constellation, GNSS policy, or universal timing mechanism. R1-2508198.

One proposal separates common basic features from common frameworks that allow NTN-specific variations. It includes waveform, numerology, coding, and modulation in the former, and scheduling/HARQ, access, and beam management in the latter. Another stresses that terrestrial operation should not acquire unnecessary cost or restrictions from that harmonization. R1-2508733, R1-2508800.

What remains different when timing and GNSS assumptions change?

A shared procedure framework still needs to accommodate propagation delay and frequency error. The candidate designs therefore examine synchronization, scheduling timelines, HARQ behavior, and access when GNSS information is unavailable or unreliable.

Proposals range from prioritizing GNSS-less LEO operation to supporting UEs with and without GNSS information in the same cell. Other suggestions include enhanced closed-loop timing/frequency adjustment, reference pre-compensation, and access procedures for temporarily unavailable GNSS. These positions should not be collapsed into a claim that GNSS-free operation was already mandated. R1-2508352, R1-2509229, R1-2509108.

Duplexing is another unresolved boundary. Some proposals focus NTN on FDD, while another asks about available TDD spectrum, guard intervals, half-duplex constraints, and interference between satellites. These are proposed evaluation questions. The common-design agreement does not prove that every terrestrial duplex mode is practical for every satellite deployment. R1-2508334, R1-2509229.

• Common design allows specific constraints : harmonization does not mean identical timing, coverage, or GNSS assumptions.

What do MIMO and control proposals ask the common framework to support?

The overview papers use MIMO and control examples to show where NR complexity accumulates. Their proposals connect reference-signal overhead, feedback timing, carrier coordination, and error recovery rather than treating each mechanism in isolation.

For CSI, candidates include a unified codebook, direct channel feedback, stronger reciprocity-based acquisition, and tracking that uses additional reference-signal opportunities. Proposed reference-signal changes include aperiodic operation, fewer transmitted resources, and adaptation to antenna configuration. These are alternative directions, not one agreed feedback format. R1-2508352, R1-2509141, R1-2508800.

Bursty traffic motivates early CSI and SRS acquisition because waiting for channel information can delay the useful transmission. Mobility proposals similarly seek less duplicated measurement and reporting across beams, TRPs, and cells. Other contributions emphasize unified TCI as a starting point, with different proposed extensions. R1-2508352, R1-2508334, R1-2509141.

Can control be simpler without becoming less reliable?

Control-channel proposals address both routine processing and failure cases. Reducing blind decoding is useful, but the design also needs to recover when a grant or a state-changing command is missed.

Two-stage DCI is proposed to keep the blindly decoded first stage compact and carry more scheduling information in a scheduled second stage. Other proposals retain the NR control structure with selected refinements. Their comparison must include coverage, processing timelines, and error behavior, not only payload reduction. R1-2509141, R1-2508725, R1-2508800.

Specific concerns include NACK-to-ACK errors, unknown TBS after a missed initial DCI, HARQ-ACK codebook mismatch after missed assignments, and BWP state misalignment. Proposed remedies also seek efficient retransmission when only a few code blocks fail. The overview identifies these problems without establishing their final solutions. R1-2509229.

• Evaluate useful packet delivery : feedback, scheduling, retransmission, and processing constraints can change the value of an isolated PHY gain.

How do FWA, AI/ML, and sensing fit without separate air interfaces?

The overview treats new services as tests of the common design. Their physical-layer needs differ, but the proposals repeatedly ask whether existing communication resources and procedures can support them with justified additions.

FWA proposals exploit stationary devices, different antenna/form-factor constraints, and persistent interference conditions. Suggested changes include link adaptation, channel estimation, reference-signal overhead reduction, and interference coordination. A joint filing explicitly recognizes that FWA benefits from reusing the mobile-broadband design while seeking targeted improvements. It does not propose treating all FWA traffic as a separate RAT. R1-2505865, R1-2509141.

AI/ML appears in two different roles. It can improve the radio mechanism, such as CSI acquisition, or create traffic and data-management requirements of its own. A joint proposal asks for consistent data collection, lifecycle management, and operator visibility/control. Another explores token communication and service-dependent error tolerance. Those are proposals; the overview does not authorize replacing ordinary bit-level reliability requirements with a universal semantic metric. R1-2506238, R1-2508725.

Sensing proposals also differ in integration depth. One studies shared communication reference signals alongside dedicated sensing resources. Another favors multiplexing sensing into the communication frame, with minimal disruption to communication. Evaluation requests include missed detections, false alarms, estimation accuracy, and the throughput/latency cost of sharing resources. A communication coverage result alone would not establish sensing coverage. R1-2509229, R1-2508725, R1-2509141.

The #123 summary explicitly separates the overview from detailed waveform, coding, AI/ML, and later initial-access/MIMO/control discussions. That work split is important when reading these proposals: listing a feature in an overview contribution does not settle its physical-layer design. R1-2509621.

• Keep service motivation and adoption separate : a promising use case still needs requirements, realistic evaluation, and a justified implementation cost.

Update Note

• 2026-10-20 - Added Executive Summary, Agreed Items, and the design principles, device scalability, bandwidth, synchronization, MRSS, bandwidth adaptation, aggregation, coverage/duplexing, TN/NTN, MIMO/control, and service discussions. Based on selected RAN1#122–#123 overview passages and supplementary company contributions from the supplied TDoc search set.

Reference

• R1-2506618 (RAN1#122) : FL summary#3 on overview of 6GR air interface (Moderator (NTT DOCOMO))
• R1-2508198 (RAN1#122bis) : FL summary#5 on overview of 6GR air interface (Moderator (NTT DOCOMO))
• R1-2509621 (RAN1#123) : FL summary#6 on overview of 6GR air interface (Moderator (NTT DOCOMO))
• R1-2508334 (RAN1#123) : Nokia Views on Selected Aspects of 6G Radio Air Interface (Nokia)
• R1-2508352 (RAN1#123) : Overview of the 6G air interface (Ericsson)
• R1-2508725 (RAN1#123) : Overview of 6GR air interface (OPPO)
• R1-2508733 (RAN1#123) : Overview of 6GR air interface (Huawei, HiSilicon)
• R1-2508800 (RAN1#123) : Design of 6GR air interface (Samsung)
• R1-2509108 (RAN1#123) : Overview of 6GR air interface (Apple)
• R1-2509141 (RAN1#123) : Overview of 6GR air interface (MediaTek Inc.)
• R1-2509229 (RAN1#123) : Overview of 6GR air interface (Qualcomm Incorporated)
• R1-2509280 (RAN1#123) : Discussion on overview of 6GR air interface (NTT DOCOMO, INC.)
• R1-2505865 (RAN1#122) : 6G Radio Access Needs Overview (T-Mobile USA, Nokia, Ericsson)
• R1-2506238 (RAN1#122) : Views on 6GR Air Interface Design (AT&T, Ericsson)
• R1-2509397 (RAN1#123) : Addressing CAPEX/OPEX requirement in RAN1 (Vodafone, AT&T, BT, Bouygues Telecom, Deutsche Telekom, Orange, Telecom Italia, Nokia, China Unicom)