TDoc Detatils - RACH

6G RACH design is not mainly about inventing a completely new random access procedure. It is more about deciding what should remain stable and what must evolve. NR already provides a strong foundation for PRACH sequence, preamble format, receiver behavior, SSB-to-RO mapping, and 4-step RACH operation. These parts are valuable because RACH is a first-access procedure. It must be reliable before the UE has full uplink synchronization and before the network has detailed UE context. At the same time, 6G introduces new pressure points. Operation around 7 GHz, MRSS, NTN, SBFD, network energy saving, larger access-load variation, and AI/ML-assisted beam prediction all create cases where simple NR reuse may not be enough. The later RAN1#125 contributions keep this controlled-evolution direction, but add more concrete questions: whether zero-padded MLS or Gold-like sequences can help very high Doppler cases, how much capacity is really gained by increasing preamble count, how RACH collision can be resolved faster, whether contention-based RACH-less UL transmission is useful for known-TA UEs, whether PRACH configuration should move away from rigid static tables, and how AI/ML beam prediction can coexist with ordinary random access. So the main insight is still a hybrid design. Keep the proven NR baseline where it protects reliability and implementation simplicity. Add new flexibility only where 6G deployment scenarios create a clear gap. In this sense, 6G RACH becomes a balance between robustness, capacity, coverage, and complexity. It should support new scenarios, but it should not allow the basic random access framework to become fragmented, overloaded, or dependent on uncertain enhancements.

• Executive Summary
• What should be the main design philosophy for 6G RACH: NR reuse, clean-slate redesign, or a hybrid approach?
• Should Zadoff-Chu remain the baseline PRACH sequence for 6G, or should new sequence candidates be reconsidered?
  • Can zero-padded MLS or Gold-like sequences help 6G PRACH in extreme high-Doppler cases?
  • Should 6G support bi-rooted PRACH preambles for high Doppler and GNSS-free NTN?
• How much robustness should 6G PRACH provide against CFO, Doppler, timing error, and NTN-related impairments?
  • How should 6G handle Type-2 false detection in PRACH?
  • How should PRACH evaluation count collisions and false detections?
• How should 6G increase RACH capacity without creating excessive PRACH receiver complexity?
  • How should Massive IoT RACH capacity be evaluated?
  • Should 6G improve capacity by resolving RACH collisions faster?
  • Can 6G use OCC and aggregated Msg2 scheduling for efficient access?
• Should 6G allow PRACH to overlap with PUSCH/PUCCH and rely on advanced gNB receiver processing?
• Should 6G support RACH-less contention-based UL transmission for known-TA UEs?
• Which PRACH formats should be reused from NR, and where are new 6G-specific formats needed?
• What PRACH design is needed around 7 GHz to support both mid-band coverage and high-mobility scenarios?
• Should long PRACH formats based on 5 kHz SCS be supported around 7 GHz for larger cell coverage?
  • What new long PRACH preamble formats are needed around 7 GHz?
  • Should 6G study long preamble formats that fit within 0.5 ms?
• How should RACH be designed for MRSS: shared NR/6G resources or dedicated resources per RAT?
• How should 6G RACH support NTN when UE-side time and frequency pre-compensation is imperfect or unavailable?
• Should 6G aim for a unified TN/NTN RACH design, or allow separate NTN-optimized PRACH formats?
• How should SBFD be integrated into 6G random access without increasing the complexity of normal TDD operation?
  • Should SBFD RO validation be unified with normal PRACH occasion validation in 6G?
• How should 6G redesign PRACH configuration for flexible deployment, clustered ROs, and time adaptation?
  • Should 6G move from static PRACH configuration tables toward parameterized or reduced-table configuration?
  • Should PRACH valid frames be determined relative to SS/PBCH transmission?
  • Should 6G allow partially overlapping ROs for different PRACH formats?
  • How should RACH be configured across multiple carriers?
• How should 6G simplify SSB-to-RO mapping while still supporting beam-based access and clustered SSB/RO structures?
  • Should SSB-to-RO mapping be non-uniform per beam direction?
• Should 6G support dynamic time-domain adaptation of RACH resources based on traffic, NES conditions, or access demand?
• How should 6G random access work in multi-TRP deployments?
• Should 4-step RACH be the single baseline procedure for 6G, with 2-step RACH avoided or treated only as an enhancement?
• How should 6G perform early device or service identification without fragmenting Msg1/PRACH resources?
  • Should 6G use a PRACH preamble plus small payload format for Msg1 indication?
  • What early UE information should be allowed in Msg1 or Msg3?
• Should Msg3-based identification become the default method, with Msg1 partitioning restricted to exceptional cases?
• How should coverage enhancement be built into the 6G RACH procedure across Msg1, Msg2, Msg3, and Msg4?
  • Should 6G support both CFRA and CBRA procedures?
  • How should 6G handle larger Msg3 payload and coverage?
  • What coverage target should 6G RACH consider for IoT and low-rate services?
  • Should repetition configuration be unified across RACH messages?
• How should initial access reuse mobility context from the previous connected state?
• Can AI/ML-based spatial and temporal beam prediction improve initial access before the UE enters connected mode?
• How should AI/ML-assisted RACH handle prediction uncertainty, especially for cell-edge UEs and multi-beam access?

Executive Summary

What should be the main design philosophy for 6G RACH: NR reuse, clean-slate redesign, or a hybrid approach?

6G RACH does not need to be designed as a completely new mechanism. NR RACH already has many proven parts. It has known PRACH formats, known sequence behavior, known receiver structures, and known deployment experience. So these parts can be reused as the baseline. But 6G also brings new deployment cases. It may include 7 GHz operation, MRSS, NTN, SBFD, higher RACH capacity demand, and AI/ML-assisted initial access. Some of these cases may not be fully covered by the existing NR design. So the practical direction is a hybrid design. Reuse NR where it is good enough. Redesign only where 6G creates a clear new requirement.

• Reuse NR as the baseline : NR RACH should be the starting point for 6G RACH. This avoids unnecessary redesign. It also allows 6G to reuse proven PRACH formats, receiver assumptions, and deployment experience where they are still valid.
• Redesign only for clear 6G gaps : A clean-slate design should not be used just for novelty. New design should be introduced only when NR cannot support the required 6G scenario well enough, such as new frequency ranges, new coverage needs, or new deployment constraints.
• Keep PRACH format evolution controlled : Existing NR PRACH formats can be reused for FR1 and FR2. Around 7 GHz, NR short formats can be used as a baseline, but long formats may still be needed to support larger cell coverage.
• Keep the RACH procedure simple : The 6GR would favor 4-step RACH as the baseline. This reduces the number of procedural options. It also avoids making the basic access procedure fragmented or difficult to implement.
• Avoid unnecessary RACH resource fragmentation : Msg3-based identification should be preferred where possible. Msg1-based partitioning should be limited because it consumes PRACH resources and can fragment RACH configuration across many features.
• Support new deployment scenarios carefully : MRSS, NTN, and SBFD should be considered in 6G RACH design from the beginning. But they should not force unnecessary complexity into the normal terrestrial TDD RACH operation.
• Treat AI/ML as an enhancement : AI/ML-based beam prediction can help initial access and random access. But it should enhance the basic RACH procedure rather than replace the fundamental RACH design.

Should Zadoff-Chu remain the baseline PRACH sequence for 6G, or should new sequence candidates be reconsidered?

Zadoff-Chu should remain the baseline PRACH sequence for 6G. The reason is not just that it was used in NR. The reason is that PRACH has a very specific job. It is transmitted before uplink timing is known. So the sequence must work well even when there is timing uncertainty, residual CFO, and Doppler shift. This is especially important for 6G cases such as NTN and high-mobility operation. The document explains that Zadoff-Chu has the key properties needed for this situation. It has CAZAC behavior, strong autocorrelation, low cross-correlation under cyclic shifts, constant envelope, and good tolerance against frequency offset. Other sequences such as m-sequences and Gold sequences may work well in synchronized systems, but PRACH is not a fully synchronized case. So the practical direction is to keep Zadoff-Chu as the baseline and reconsider other candidates only if they can show the same PRACH-specific robustness.

• Keep Zadoff-Chu as the baseline : Zadoff-Chu fits the basic nature of PRACH. PRACH is transmitted when the UE does not yet have uplink timing synchronization. So the sequence must be reliable even when the received timing is uncertain.
• Prioritize robustness to frequency offset : The UE may still have residual CFO after downlink synchronization. In NTN, Doppler shift can be much larger. Zadoff-Chu is considered suitable because it is relatively robust against this kind of frequency error.
• Do not ignore timing uncertainty : PRACH detection is not done in a perfectly synchronized uplink. The gNB detects the preamble by correlation while timing error may still exist. So the sequence must keep good correlation behavior even under timing uncertainty.
• Use CAZAC properties as a key requirement : Zadoff-Chu provides constant amplitude and zero-autocorrelation behavior. This helps PRACH detection and also supports cyclic shifts, which are important for creating multiple preambles from the same root sequence.
• Be careful with m-sequences and Gold sequences : These sequences can have good correlation behavior in synchronized systems. But the document points out that their performance can degrade when timing errors exist, which is exactly the normal condition during initial uplink access.
• Consider other candidates only with strong evidence : A new PRACH sequence should not be selected just because it is new. It should show good autocorrelation, low cross-correlation, constant envelope, timing-error tolerance, and frequency-error tolerance.
• Recognize the remaining Zadoff-Chu limitation : Zadoff-Chu is robust, but frequency offset can still shift the correlation peak. This means timing error and frequency error may look similar at the correlator output. So receiver design still needs to handle this ambiguity.

Can zero-padded MLS or Gold-like sequences help 6G PRACH in extreme high-Doppler cases?

They may help in specific high-Doppler cases, but they should be treated as candidates for study rather than an immediate replacement for Zadoff-Chu. R1-2603519 keeps Zadoff-Chu as the baseline, then identifies a specific weakness: under frequency offset, the Zadoff-Chu correlation peak can shift, and restricted cyclic-shift sets may be needed to avoid false detection. That protects reliability but reduces preamble capacity. The contribution therefore studies sequences whose correlation peak location is more stationary under CFO. A zero-padded MLS design, or a Gold-like sequence with truncation, can improve CFO tolerance and avoid restricted sets, but this comes with tradeoffs such as higher PAPR/cubic metric, possible transmit-energy loss from shorter active sequence length, and the need to keep gNB receiver complexity under control.

• Keep Zadoff-Chu as the normal baseline : The new candidates are motivated by extreme high-Doppler ambiguity, not by a general failure of Zadoff-Chu in normal 6G terrestrial operation.
• Target the restricted-set problem : If a sequence can keep the correlation peak from shifting under CFO, the design may not need root-specific restricted sets. This can preserve more cyclic-shift preambles.
• Use zero padding to widen CFO tolerance : Padding zeros before DFT spreading increases correlation between adjacent subcarriers. This can make the sequence response less sensitive to CFO.
• Recognize the MLS benefit : MLS generation is simple because it uses a linear feedback shift register. It can also keep the peak location more stable under CFO than Zadoff-Chu.
• Do not ignore PAPR and coverage : Zero padding can increase PAPR or cubic metric. If this requires additional PA back-off, the coverage gain from a more robust sequence may be partly lost.
• Protect receiver simplicity : Any new sequence should improve high-Doppler detection without forcing major changes to deployed or expected PRACH receiver algorithms.
• Treat Gold-like performance carefully : The contribution reports promising behavior for a truncated Gold-sequence approach in high Doppler, but the conclusion is still to study the candidate rather than standardize it immediately.

Should 6G support bi-rooted PRACH preambles for high Doppler and GNSS-free NTN?

Bi-rooted PRACH preambles should be studied as an additional option for cases where a single Zadoff-Chu root cannot cleanly separate timing error from frequency error. R1-2604669 keeps Zadoff-Chu reuse as the baseline, but points out that NR PRACH is single-rooted: one preamble is built from repetitions of one ZC root. In high-mobility TN or GNSS-free LEO NTN, residual CFO can be large enough that one root may not provide enough information to resolve both delay and frequency offset. A bi-rooted preamble uses two different ZC roots, for example two conjugate-related roots, so the receiver can use two correlation peak positions to estimate timing and CFO more reliably.

• Keep single-rooted PRACH for normal cases : Typical terrestrial deployments can still use normal Zadoff-Chu PRACH. Bi-rooted preambles are mainly motivated by extreme Doppler or imperfect NTN pre-compensation.
• Use two roots to resolve two unknowns : With two different root sequences, the receiver can obtain two correlation observations. This can help separate timing offset from frequency offset.
• Target GNSS-free LEO NTN : If the UE cannot perform accurate GNSS-based pre-compensation, residual Doppler can be much larger than in normal TN. This is the strongest use case for bi-rooted PRACH.
• Preserve ZC PAPR advantages where possible : If the two sequences are concatenated in time, the PAPR and cubic metric are expected to remain close to ordinary ZC PRACH behavior. Superposed designs may need separate PAPR study.
• Keep receiver complexity manageable : The gNB may need to detect two sequences instead of one, but the contribution treats this as manageable for the specific scenarios where the robustness is needed.
• Do not force one structure too early : The exact relation between the two roots, repetition structure, and mapping from configured root index to root pair remains for further study.

How much robustness should 6G PRACH provide against CFO, Doppler, timing error, and NTN-related impairments?

6G PRACH should be robust enough to work before the UE has accurate uplink synchronization. This is the most important point. During initial access, the UE has already obtained downlink synchronization, but uplink timing is still not aligned. There can also be residual CFO after downlink synchronization. In NTN, this problem becomes more serious because satellite motion can create large Doppler shift and large timing uncertainty. So 6G PRACH should not assume an ideal uplink condition. It should be designed to tolerate timing error, frequency error, Doppler, and imperfect pre-compensation. At the same time, the design should not become unnecessarily different for every deployment case. The practical direction is to keep a robust common PRACH baseline and add extra mitigation only when NTN or high-mobility scenarios require it.

• Design for unsynchronized uplink : PRACH is transmitted before uplink timing is established. So the preamble should tolerate timing uncertainty, round-trip delay, and channel delay spread from the beginning.
• Handle residual CFO : The UE may still have frequency error after downlink synchronization. This can degrade PRACH reception at the gNB, so the sequence and receiver design should be tolerant to CFO.
• Consider Doppler as a core requirement : Doppler is not only a special edge case. It becomes important for NTN and high-speed terrestrial scenarios. PRACH design should therefore consider Doppler tolerance as part of the baseline evaluation.
• Support timing and frequency pre-compensation : For NTN, the UE may use GNSS information or satellite constellation information to pre-compensate timing advance and Doppler. But this pre-compensation may not always be perfect.
• Prepare for imperfect NTN compensation : If timing or frequency pre-compensation is inaccurate, 6G may need additional mitigation. This can include PRACH formats with stronger Doppler resilience and larger timing tolerance.
• Avoid unnecessary NTN-only fragmentation : A unified TN and NTN design should be preferred where feasible. Separate NTN-specific solutions should be introduced only when the common design cannot meet the required robustness.
• Accept that robustness has limits : Even with Zadoff-Chu, frequency offset can shift the correlation peak. This can make timing error and frequency error hard to separate. So 6G PRACH robustness should include both sequence design and receiver-side interpretation.

How should 6G handle Type-2 false detection caused by inter-cell PRACH interference?

6G should treat Type-2 false detection as a real deployment issue, especially when short PRACH sequences are used heavily in midband TDD deployments. Type-2 false detection means a gNB detects a target preamble even though no UE transmitted it in that cell, while a UE in another cell transmitted PRACH. R1-2604669 argues that this is most problematic when neighboring cells reuse the same root sequence. Short PRACH formats have far fewer roots than long formats, and if the number of preambles per RO is increased, root reuse becomes tighter. The practical implication is that capacity expansion by simply adding more preambles per RO can worsen inter-cell false detection unless root reuse and format choice are considered together.

• Account for realistic root reuse : Perfect cell planning cannot always avoid root reuse because sites and UEs are not ideally placed and vertical distribution also matters.
• Recognize short-sequence limits : Short sequence length gives fewer roots. With 512 or 1024 preambles per RO, the same root may need to be reused over a small number of cells.
• Consider pathloss variation : LOS/NLOS and shadow fading can make a UE's PRACH more strongly heard by a distant cell than by its nearest cell, creating false detections in neighboring cells.
• Use long sequences as a mitigation : Long preamble formats provide many more roots and can make root reuse sparser. This can reduce Type-2 false detection pressure.
• Do not evaluate only intra-cell false alarms : PRACH reliability should include inter-cell false detection, not only missed detection and Type-1 false detection inside one cell.
• Aim for root-space comparable to DL planning : The contribution notes that downlink has 1008 PCIs for overhearing avoidance, so a larger PRACH root space is also desirable.

How Should PRACH Collisions and False Detections Be Evaluated?

R1-2604694 clarifies that PRACH evaluation should not mix collision behavior with miss-detection and false-detection metrics. If two UEs transmit the same target preamble and the gNB detects that target preamble, the preamble itself was detected. The collision should be counted separately, because the later contention-resolution failure is a RACH procedure problem rather than a pure preamble-detection failure. At the same time, multi-user evaluation should still plot false detection rate, because cross-correlation among several active preambles can cause the gNB to detect extra preambles that no UE actually sent.

• Separate collision rate from detection metrics : A detected target preamble with multiple UEs behind it should not automatically count as miss detection or false detection.
• Track useless Msg2/Msg3 scheduling : If the receiver detects extra untargeted preambles, the network may transmit Msg2 and reserve Msg3 resources for UEs that do not exist. This is a system-overhead problem.
• Do not rely only on noise false alarm : The NR-style 0.1% false alarm threshold is based mainly on noise. In multi-UE 6G studies, cross-correlation interference can dominate false detections.
• Report false detection rate in multi-user plots : When 2, 4, or 8 UEs transmit in one RO, miss detection alone can look acceptable even while extra false preambles consume resources.
• Keep the metric interpretation procedural : Preamble detection, preamble collision, and contention-resolution success should be evaluated as related but distinct parts of random access.

How should 6G increase RACH capacity without creating excessive PRACH receiver complexity?

6G may need higher RACH capacity than NR. This can come from dense deployments, NTN, MRSS, and more diverse UE access scenarios. But increasing RACH capacity is not only a matter of adding more preambles or more RACH occasions. Each method has a cost. More cyclic shifts can reduce cell-radius support. Longer sequences can require more bandwidth. More FDM RACH occasions can increase PRACH receiver processing load. OCC can help only in some channel conditions and may not work well in multipath. So the document points toward a simpler direction. If 6G needs more RACH capacity, it should mainly increase time-domain opportunities and consider RACH and PUxCH overlap when advanced receiver capability is available.

• Prefer simple time-domain expansion : The document proposes increasing RACH capacity by increasing time-domain allocations. This is simpler than heavily increasing frequency-domain multiplexing or adding many new preamble structures.
• Avoid excessive RO FDM multiplexing : More FDM RACH occasions can improve capacity, but it also forces the receiver to detect multiple PRACH resources at the same time. This can quickly increase gNB receiver complexity.
• Do not reduce cyclic shift spacing too aggressively : Adding more cyclic shifts can create more preambles from the same Zadoff-Chu root. But smaller cyclic shift spacing reduces timing adjustment capability and can hurt larger-cell deployments.
• Use longer sequences carefully : Longer Zadoff-Chu sequences can increase preamble capacity. But they also increase transmission bandwidth, so they must be considered together with the minimum supported initial BWP.
• Be cautious with OCC-based capacity gain : OCC may provide gains in flat-channel or ideal conditions. But in multipath environments, cross-correlation between OCC-coded preambles can appear, which makes detection less clean.
• Do not overestimate preamble-count gain : R1-2603519 shows that with 8 UEs in one RO and 64 preambles, the probability that all UEs are collision-free is only about 63%. More preambles help, but they do not by themselves solve bursty access.
• Account for reattempt cascades : If collided UEs retry in the same later RO, retransmissions can collide again. This may look like a pure capacity shortage even when the retry behavior is part of the problem.
• Allow PRACH and PUxCH overlap where feasible : If the gNB has advanced receiver capability, PRACH and PUxCH overlap can increase effective RACH capacity without reserving too many exclusive PRACH resources.
• Keep capacity improvement receiver-aware : RACH capacity should not be improved only from the UE-side or configuration-side view. The gNB PRACH receiver burden must be considered from the beginning.

How should Massive IoT RACH capacity be evaluated for 6G?

Massive IoT should be evaluated with explicit traffic and density assumptions rather than by extrapolating from today's NR deployments. R1-2604669 notes that PRACH collisions are usually rare in practical NR deployments because Massive IoT traffic is still limited and only a small number of ROs may be enough. But 6G Massive Communication targets much higher connection density, and many devices may attempt access within a short time window. Therefore, PRACH capacity evaluation should use the IMT-2020 mMTC traffic model and 6G connection density assumptions, including bursty access behavior.

• Use the mMTC traffic model as a baseline : The IMT-2020 TR 37.910 traffic model gives a comparable starting point for evaluating Massive Communication access load.
• Use 6G device-density assumptions : The contribution points to 1,000,000 devices per square kilometer as the relevant density target for capacity stress testing.
• Evaluate peak access attempts : For example assumptions, the peak access load can reach about 20 UEs per second per cell for 500 m ISD and about 153 UEs per second per cell for 1732 m ISD.
• Separate normal NR experience from 6G stress cases : Rare PRACH collisions in today's networks do not prove that 6G PRACH capacity is sufficient for future Massive IoT bursts.
• Consider message size and traffic type : Larger L2 PDU sizes, triggered reporting, event-driven reporting, remote actuation, and firmware updates can all change access-load behavior.

Should 6G improve capacity by resolving RACH collisions faster?

Yes. R1-2604694 argues that a practical way to increase usable RACH capacity is not simply to configure hundreds of preambles per RO. With many configured preambles, Type-1 false detection can become very large because cross-correlation among active preambles creates extra detections. The paper gives an example where increasing from 64 to 1024 preambles per RO can make the high-SINR Type-1 false detection rate much worse for 8 active users. A better direction is to keep the preamble set manageable and improve how quickly the system resolves or recovers from actual collisions.

<  R1-2604694 :  Figure 3: Dynamically scheduled RO by MsgX>

<  R1-2604694 :  Figure 4: Multiple-msg2 based RACH contention resolution >

• Keep 64 preambles per RO as a low-risk baseline : Reusing the NR-like limit helps keep false detection under control, especially for multi-user PRACH reception.
• Use MsgX/MsgY for fast retry : After detecting a possible collision, the gNB could send a dynamic MsgX that schedules a short-latency set of additional ROs. The involved UEs then retransmit Msg1 as MsgY in those resources.
• Make additional ROs dynamic : The extra ROs can be aperiodic and one-time-use rather than a semi-static pattern activated through common configuration.
• Exploit spatial separability : If a gNB with multiple receive antennas can distinguish two same-preamble arrivals by spatial direction, it can send multiple Msg2s and separate Msg3 grants.
• Use DMRS RSRP for Msg2 selection : A UE that sees multiple Msg2s can choose the one whose PDSCH DMRS has the stronger RSRP, assuming the Msg2 is beamformed toward that UE.
• Use paging to reduce collisions : For delay-sensitive paged UEs, paging-triggered CFRA or paging-indicated CBRA windows can spread access attempts and avoid everyone selecting the next immediate RO.

Can 6G use OCC and aggregated Msg2 scheduling for efficient access?

R1-2604694 proposes several access-efficiency enhancements after timing acquisition. The common idea is that dense access scenarios, such as Massive IoT or stadium-like bursts, can waste control overhead if every UE is handled through fully separate messages. 6G can study multiplexing and aggregation methods that reduce scheduling latency, overhead, and energy consumption while keeping the basic RACH procedure recognizable.

• Use OCC after timing is available : Msg3, Msg4 ACK, or similar uplink messages can potentially be multiplexed with orthogonal cover codes once TA has been acquired.
• Do not apply OCC blindly to PRACH : OCC is more natural for later uplink messages than for raw unsynchronized PRACH, because timing and channel conditions are better controlled.
• Aggregate Msg2 scheduling : One Msg2 could schedule multiple Msg3 UL grants for UEs whose Msg1 transmissions were received in different ROs, reducing PDCCH/PDSCH overhead.
• Improve burst handling : Aggregated scheduling can reduce delay when many Msg1 transmissions arrive in a short interval and individual Msg2 transmissions would span multiple monitoring occasions.
• Reduce Msg4 payload where possible : The contention-resolution identity carried in Msg4 PDSCH could be reduced or replaced by L1-level identification such as CRC scrambling, if reliability and ambiguity handling are acceptable.

Should 6G allow PRACH to overlap with PUSCH/PUCCH and rely on advanced gNB receiver processing?

6G should consider PRACH overlap with PUSCH and PUCCH, but it should be done carefully. In NR, PRACH resources can reduce the available uplink data and control resources because PRACH and PUxCH compete for uplink capacity. The document argues that newer receiver designs may be able to handle PRACH and PUxCH overlap without seriously degrading PRACH detection. This can make RACH capacity more flexible. It can also support time-domain adaptation of RACH resources. So the direction is not to reserve too many fixed PRACH-only resources. Instead, 6G can allow overlap under controlled conditions, assuming the gNB has enough receiver capability.

• Use overlap to improve RACH capacity : PRACH and PUxCH overlap can increase the effective number of RACH opportunities without always reserving separate uplink resources only for PRACH.
• Reduce uplink resource waste : Fixed PRACH resources may remain unused when there is low access demand. Allowing overlap can make uplink resource usage more efficient.
• Rely on advanced receivers carefully : The design can assume improved gNB receiver processing, but this should not make basic PRACH detection fragile or overly dependent on ideal receiver capability.
• Support time-domain RACH adaptation : Overlap can help the network adapt RACH resources in time, depending on traffic demand or access load.
• Keep scheduler control important : The L2 scheduler should control when PUxCH can use PRACH resources. This avoids uncontrolled interference between random access and normal uplink transmission.
• Avoid unnecessary complexity for all deployments : PRACH and PUxCH overlap should be useful where receiver capability and traffic conditions justify it. It should not force every deployment to support a complex receiver design.
• Make overlap conditional, not blindly enabled : The safest direction is to allow overlap under defined conditions. This gives 6G more flexibility while still protecting PRACH reliability.

Should 6G support RACH-less contention-based UL transmission for known-TA UEs?

R1-2604694 introduces a topic that is adjacent to, but distinct from, ordinary RACH: contention-based PUSCH for UEs that already know their timing advance. For sporadic uplink data, a UE may not need the full Msg1/Msg2 timing-acquisition part of RACH. Dedicated configured grant can also be inefficient if the traffic is rare. A contention-based PUSCH resource pool could let connected, inactive, or even idle UEs with valid TA transmit small uplink data with lower latency and less access overhead.

• Use it only when TA is known : RACH-less contention-based PUSCH is most natural for FWA, low-mobility, inactive, or recently released UEs whose timing is still valid.
• Keep RACH for timing acquisition : If TA has expired or the UE is uncertain about uplink timing, the UE still needs a PRACH-based timing step before sending normal PUSCH.
• Reserve a contention-based PUSCH pool : UEs can randomly select one or more time-frequency resource units based on traffic size and coverage need, then rely on network acknowledgment or retransmission handling.
• Support a TA-acquisition-only shortcut : A UE without valid TA could transmit PRACH on a subset of resources, receive a special Msg2 carrying TA, and then transmit contention-based PUSCH without a Msg3 grant.
• Avoid maintaining TA unnecessarily : Periodic UL transmissions and DL TA commands just to keep sparse-data UEs timed can waste energy and resources. A lightweight TA reacquisition step may be better.
• Keep collision handling explicit : Contention-based PUSCH still has collision risk, so acknowledgment and retransmission behavior must be part of the design.

Which PRACH formats should be reused from NR, and where are new 6G-specific formats needed?

6G PRACH format design should start from NR. This is because NR already defines practical formats for different frequency ranges, cell sizes, and coverage needs. The document suggests that FR1 and FR2 can reuse NR PRACH formats as the baseline. This also helps reuse existing receiver experience and keeps the design aligned with current deployment assumptions. But 6G may also operate around 7 GHz. This range is different. It uses mid-band-like site grids, but it may still need larger cell coverage than short PRACH formats can support. So NR formats should be reused where they fit, and new or adjusted formats should be introduced where 6G deployment conditions create a real gap.

• Reuse NR formats for FR1 : For FR1, the document treats NR long formats based on 1.25 kHz and 5 kHz SCS, and NR short formats based on 15 kHz and 30 kHz SCS, as the 6G baseline.
• Reuse NR formats for FR2 : For FR2, the document takes NR short formats based on 120 kHz SCS as the baseline. This keeps 6G aligned with the small-cell and high-frequency assumptions already used in NR.
• Keep the NR-like PRACH structure : The PRACH preamble should still have CP, one or multiple consecutive symbols, and a guard period when needed. This keeps the signal structure familiar and receiver-friendly.
• Use NR short formats around 7 GHz : Around 7 GHz, the document proposes short PRACH formats based on 30 kHz SCS, using NR short PRACH formats as the starting point.
• Add long formats around 7 GHz : Short 30 kHz PRACH formats may not support enough cell range. So the document proposes long PRACH formats based on 5 kHz SCS around 7 GHz.
• Match format choice to coverage need : Short formats are useful for smaller cells and lower receiver complexity. Long formats are needed when larger cell radius or coverage extension becomes important.
• Avoid new formats without a clear reason : New 6G-specific formats should be introduced only when NR formats cannot meet the required coverage, Doppler tolerance, or deployment need.

What PRACH design is needed around 7 GHz to support both mid-band coverage and high-mobility scenarios?

Around 7 GHz, 6G PRACH has to solve two requirements at the same time. It should support deployment using mid-band-like site grids, so the cell size cannot be treated as very small. But it should also tolerate mobility and Doppler at a higher carrier frequency. The document therefore suggests that short PRACH formats based on 30 kHz SCS can be reused as a baseline, but they are not enough for all coverage cases. Long PRACH formats are also needed. Among the long-format options, 5 kHz SCS is viewed as a practical choice because it can support larger cell range while still maintaining reasonable Doppler tolerance at 7 GHz.

• Start from 30 kHz short formats : Around 7 GHz, 30 kHz SCS is assumed for operation. So NR short PRACH formats based on 30 kHz SCS can be used as the baseline for smaller-cell and lower-complexity cases.
• Do not rely only on short formats : Short formats have shorter symbol time. This limits the supported cell radius. Around 7 GHz, the deployment may still need mid-band-like coverage, so short formats alone may not be enough.
• Add long formats for coverage : Long PRACH formats are needed to support larger cells. They provide longer symbol duration, larger guard time, and better support for round-trip delay and delay spread.
• Use 5 kHz SCS for long formats : The document points to 5 kHz SCS as the basis for long PRACH formats around 7 GHz. It can support almost 30 km range under the assumed delay spread condition.
• Check Doppler tolerance together with coverage : A lower SCS helps coverage, but it can be more sensitive to Doppler. The document compares options and shows that 5 kHz SCS can still support high speeds at 7 GHz.
• Support multiple long-format use cases : The document considers long formats for half-slot allocation, full-slot allocation, coverage enhancement, and long-range operation. This allows different coverage and latency trade-offs.
• Keep NR alignment where possible : The 7 GHz design should not become unnecessarily different from NR. The direction is to reuse NR short formats where they fit and add 5 kHz long formats where coverage requires them.

Should long PRACH formats based on 5 kHz SCS be supported around 7 GHz for larger cell coverage?

Yes. Long PRACH formats based on 5 kHz SCS should be supported around 7 GHz when larger cell coverage is needed. The key reason is symbol duration. A smaller SCS gives a longer symbol time, and this helps PRACH tolerate round-trip delay and delay spread. Around 7 GHz, 6G may still use mid-band-like site grids. So the cell size cannot always be treated as a small-cell case. Short formats based on 30 kHz SCS are useful, but their supported range can be limited. The document shows that 5 kHz SCS can provide much larger cell-radius support while still keeping acceptable Doppler tolerance for high-mobility cases at 7 GHz. So 5 kHz long PRACH formats are a practical extension, not a clean-slate redesign.

• Support 5 kHz long formats : The document proposes long PRACH formats based on 5 kHz SCS around 7 GHz. This is needed because 30 kHz short formats may not provide enough range for larger cells.
• Use them for larger cell coverage : Long formats provide longer symbol duration and more room for guard period. This helps support round-trip delay, delay spread, and wider-area deployment.
• Keep 30 kHz short formats as baseline : The 7 GHz design does not need to replace short formats. Short PRACH formats based on 30 kHz SCS can still serve smaller cells and lower-complexity deployments.
• Balance coverage and Doppler : Lower SCS helps coverage, but it must still handle Doppler at 7 GHz. The document indicates that 5 kHz SCS gives a useful balance between range support and high-speed tolerance.
• Support different long-format purposes : The long-format set can cover different needs such as half-slot allocation, full-slot allocation, coverage enhancement, and long-range operation.
• Avoid unnecessary format proliferation : 5 kHz long formats should be added because they solve a clear 7 GHz coverage gap. New formats should not be added unless they address a real deployment need.

What new long PRACH preamble formats are needed around 7 GHz?

R1-2603519 gives a more concrete starting point for long PRACH preamble formats around 7 GHz. The idea is to keep the NR-like preamble structure, meaning a CP, one or more consecutive PRACH symbols without CP between the symbols, and a guard period when needed. But the format set should cover different time-duration and coverage needs. The contribution therefore suggests 5 kHz-SCS long-format candidates that align with a 30 kHz slot structure: a half-slot format, a full-slot format, a coverage-extension format, and a long-range format. These are not meant to replace 30 kHz short formats. They fill the larger-cell and coverage cases where short formats do not provide enough round-trip-time margin.

• Use sequence duration as a design constraint : The PRACH sequence duration should be long enough to cover the target round-trip time and delay spread. This is the basic reason for using long formats when the cell range grows.
• Keep alignment with uplink symbols : For multiplexing with other uplink signals, the preamble sequence duration should be an integer multiple of the uplink symbol duration. This makes the new format easier to place in the UL time structure.
• Format 4 for half-slot allocation : A half-slot long format can provide more range than short formats while keeping the PRACH occupancy smaller than a full-slot allocation.
• Format 5 for full-slot allocation : A full-slot long format gives more time for the preamble and guard period, which is useful when the deployment needs stronger range support.
• Format 6 for coverage extension : A coverage-extension format can use longer or repeated preamble energy to improve detection where link budget is the main problem.
• Format 7 for long range : A long-range format targets the largest terrestrial cell-size cases around 7 GHz, where round-trip delay and guard time dominate the format choice.
• Leave extreme cases for further study : Air-to-ground, NTN, and possible 15 GHz or 30 GHz requirements are still marked for further study, so the 7 GHz long-format set should not be overloaded with those assumptions too early.

Should 6G study long preamble formats that fit into a 0.5 ms UL slot?

Yes. R1-2604669 adds a different reason for new long formats: not only larger coverage around 7 GHz, but also inter-cell false-detection control in midband TDD. The problem is that common short formats such as NR B4 fit midband TDD slot structures but have only a short sequence length, so the root sequence space is limited. Long sequence length, such as L=839, gives many more roots and can reduce tight root reuse, but legacy long formats may not fit conveniently into a 0.5 ms UL allocation. The contribution therefore proposes studying long-sequence formats with about 0.5 ms target duration.

• Use long sequence length for root-space expansion : L=839 gives many more possible roots than L=139. This helps reduce root reuse across neighboring cells.
• Fit midband TDD constraints : A 0.5 ms target duration makes a long-sequence PRACH format usable even when the uplink allocation is only one 30 kHz slot.
• Candidate F4-1 : A 2.5 kHz SCS, one-repetition, L=839 format has similar low-speed performance to F4-3, but degrades more at medium and high speed because of the longer sequence duration.
• Candidate F4-2 : A 5 kHz SCS, two-repetition, L=839 format occupies roughly similar time-frequency resources to NR B4 and performs slightly better than B4 at 1% missed-detection rate in the evaluated cases.
• Candidate F4-3 : A 5 kHz SCS, one-repetition, L=839 format is shorter and can support time-multiplexing two ROs in the same 30 kHz slot, but it has about 3 dB weaker coverage than B4/F4-2 in low-speed cases.
• Prefer 5 kHz for mobility : The evaluation suggests 5 kHz candidates handle medium and high UE speeds better than the 2.5 kHz candidate.

How should RACH be designed for MRSS: shared NR/6G resources or dedicated resources per RAT?

For MRSS, the safer starting point is to use separate or dedicated RACH resources for NR and 6G. Shared RACH resources may look efficient, but they also create stronger dependency between NR and 6G PRACH designs. If both RATs share the same RACH resources, 6G may need to stay closer to NR format assumptions, timing structures, and receiver behavior. This can limit the flexibility of 6G RACH design. The document therefore suggests dedicated resources as the starting point. This gives 6G more freedom to evolve its RACH design while still allowing efficient multiplexing through flexible configuration.

• Start with dedicated resources : The document suggests separate or dedicated RACH resources for each RAT as the starting point. This makes the initial 6G design simpler and avoids forcing full NR compatibility into every RACH decision.
• Avoid excessive NR dependency : If NR and 6G share RACH resources, the 6G PRACH design may need to remain very similar to NR. This can reduce design freedom for new 6G requirements.
• Keep shared resources as a study topic : RACH resource sharing should not be completely excluded. But if it is considered, its impact on 6G PRACH format, SSB-to-RO mapping, and receiver complexity should be studied carefully.
• Use flexibility for efficient multiplexing : Dedicated resources do not mean inefficient resource usage. 6G can still use more flexible RACH configuration, such as time multiplexing of ROs, to improve resource efficiency.
• Relax backward-compatibility constraints : Dedicated NR and 6G RACH resources allow 6G to introduce new design choices where needed. This is useful when 6G deployment scenarios require different timing, format, or capacity behavior.
• Keep MRSS design practical : The MRSS design should balance spectrum efficiency and implementation simplicity. Dedicated resources provide a cleaner baseline, while shared resources can be studied only if the efficiency gain is worth the added complexity.

How should 6G RACH support NTN when UE-side time and frequency pre-compensation is imperfect or unavailable?

For NTN, 6G RACH should first assume that the UE can apply some level of time and frequency pre-compensation. This can be based on GNSS information or satellite constellation information. With this assumption, the same basic RACH design can be reused for both terrestrial and non-terrestrial networks where feasible. But this assumption may not always hold. GNSS may be unavailable, spoofed, jammed, or not accurate enough. The remaining timing error and Doppler error can still be large. So 6G RACH should have a fallback direction. The baseline should remain unified as much as possible, but additional NTN mitigation should be studied when imperfect pre-compensation creates too much timing or frequency uncertainty.

• Assume UE pre-compensation first : The starting point is that the UE applies timing and frequency pre-compensation before RACH transmission. This can reduce large NTN delay and Doppler effects before the PRACH reaches the gNB.
• Do not assume pre-compensation is perfect : Even with GNSS or satellite constellation information, the UE may still have residual timing and frequency error. In some cases, GNSS may also be unavailable, spoofed, or jammed.
• Keep TN and NTN unified where feasible : The document favors a unified terrestrial and non-terrestrial RACH design where possible. This helps avoid separate market-specific designs and reduces fragmentation.
• Study NTN-specific mitigation when needed : If residual Doppler or timing uncertainty is too large, 6G may need additional mitigation. This can include PRACH formats with stronger Doppler tolerance and larger timing-error resilience.
• Protect PRACH detection reliability : NTN impairment should not make PRACH detection ambiguous or unreliable. The design should consider how the gNB detects the preamble when both timing error and frequency error are present.
• Avoid NTN-only redesign unless necessary : Separate NTN-oriented PRACH features should be introduced only when the common TN/NTN design cannot provide enough robustness.

Should 6G aim for a unified TN/NTN RACH design, or allow separate NTN-optimized PRACH formats?

6G should first aim for a unified RACH design for TN and NTN. This is the cleaner baseline. It avoids creating different RACH designs for different deployment markets. It also keeps implementation and specification complexity under control. But NTN has special problems. Satellite links can create larger timing uncertainty and higher Doppler shift. The document assumes that the UE can apply time and frequency pre-compensation for NTN RACH, based on GNSS information or satellite constellation information. If this works well enough, a unified TN/NTN design is preferred. If it does not work well enough, then NTN-specific mitigation may be needed. So the direction is unified design first, NTN-optimized formats only when the common design cannot handle the impairment level.

• Use unified design as the baseline : The document prioritizes a unified design for terrestrial and non-terrestrial RACH where feasible. This reduces fragmentation and keeps the 6G RACH framework simpler.
• Assume UE pre-compensation for NTN : As a starting point, the UE is assumed to apply timing and frequency pre-compensation using GNSS information or satellite constellation information before transmitting RACH.
• Check whether pre-compensation is enough : The key question is how much residual timing error and Doppler error remain after UE-side compensation. If the remaining error is small enough, the common RACH design can still be used.
• Allow NTN-specific mitigation when needed : If the residual impairments are too large, 6G may need new PRACH formats or other mitigation methods with higher Doppler and timing resilience.
• Avoid unnecessary market fragmentation : Separate NTN formats should not be introduced just because NTN is different. They should be added only when a unified TN/NTN design cannot meet the required reliability.
• Keep the decision impairment-driven : The choice should depend on actual NTN timing and Doppler conditions, not on a fixed assumption that NTN always needs a separate PRACH design.

How should SBFD be integrated into 6G random access without increasing the complexity of normal TDD operation?

SBFD can be useful for 6G random access, but it should not make the basic TDD RACH design more complicated. The document explains that random access in SBFD symbols can reduce latency, improve coverage, extend cell range, and reduce collision probability by creating more available RACH occasions. This is attractive for 6G because SBFD can be considered from the beginning of system design, unlike NR where it was added later under legacy constraints. But normal TDD is still expected to remain the main duplexing scheme. So SBFD should be integrated as a controlled enhancement. It should improve random access where SBFD is used, without forcing extra complexity into ordinary TDD RACH operation.

• Consider SBFD from day one : SBFD should be studied early in 6G RACH design. This avoids the limitation of adding random access support later on top of an already fixed legacy design.
• Use SBFD to increase RACH opportunities : Allowing random access transmission in SBFD symbols can create more RACH occasions. This can reduce access latency and lower collision probability.
• Use SBFD to improve coverage : SBFD symbols may allow longer RACH occasions. Longer RACH occasions can help improve coverage and extend the maximum supported cell range.
• Protect normal TDD simplicity : SBFD should not make basic TDD random access harder to configure or implement. Normal TDD operation should remain simple because it is expected to be the main 6G duplexing mode.
• Avoid legacy-style patching : NR SBFD random access was introduced late and was constrained by the Rel-15 RACH design. 6G should avoid this by designing the SBFD interaction more cleanly from the start.
• Treat SBFD as an enhancement path : SBFD should enhance RACH latency, coverage, range, and collision performance where available. But it should not become a mandatory source of complexity for all TDD deployments.

Should SBFD RO validation be unified with normal PRACH occasion validation in 6G?

Yes, if 6G UEs natively understand SBFD. In NR Rel-19, SBFD random access had to be added while preserving legacy UE behavior, so PRACH occasions in normal symbols and SBFD symbols were handled with separate validation logic and mapping cycles. R1-2604669 suggests that 6G can avoid this retrofit structure. If SBFD symbol type is a native part of the slot/resource validation process, the network can define one grid of potential ROs and the UE can validate each RO against the current TDD/SBFD slot format. This would reduce the need for parallel PRACH occasion types.

<  R1-2604694 : Figure 9: NR single-RACH configuration and dual-RACH configurations  >

• Make symbol type a native parameter : Instead of treating SBFD occasions as a separate resource pool, the symbol type can be part of ordinary PRACH occasion validation.
• Map by RACH configuration, not symbol type : SSB-to-RO mapping cycles can be associated with each RACH configuration. This avoids a rigid first-occasion versus second-occasion split.
• Allow different configurations for different needs : One RACH configuration could use pure UL symbols, while another could use SBFD symbols with denser mapping or different coverage assumptions.
• Allow SBFD-specific power parameters : R1-2604694 notes that PRACH in SBFD symbols may need separate power-control handling, such as a different preamble received target power, because interference conditions differ.
• Define frequency offset relative to usable UL resources : For SBFD symbols, the first RO start-RB may need interpretation relative to the first usable UL PRB rather than a normal full-UL symbol assumption.
• Enhance PRACH tables for SBFD : 6G can start from NR PRACH tables, but should study table entries that locate and densify ROs in both SBFD and non-SBFD symbols more naturally.
• Remove legacy-specific indicators where possible : If 6G UEs understand the unified design, the system may avoid Rel-19 style indicators that only exist to steer legacy behavior.
• Keep the assumption explicit : This simplification depends on whether all relevant 6G UEs are expected to support and understand SBFD operation.

How should 6G redesign PRACH configuration for flexible deployment, clustered ROs, and time adaptation?

6G PRACH configuration should become more flexible than the rigid NR table-based model, but it should not become a fully open-ended configuration that increases signaling and testing burden. In NR, a single prach-ConfigIndex selects a fixed combination of preamble format, periodicity, time-domain location, and related RO parameters. This is compact and deployment-proven, but it couples parameters that 6G may need to adapt independently. R1-2603519 points to a middle direction: use deployed NR configurations as the baseline where they are useful, reduce or simplify the table where possible, and add separately configurable parameters for clustered ROs, clustered SS/PBCH operation, SBFD, and time-domain adaptation.

• Start from deployed NR configurations : The most common NR PRACH configurations can remain a practical baseline, especially for MRSS and deployments that reuse existing site and TDD/FDD assumptions.
• Avoid table expansion for every new case : Extending the NR-style table to cover 7 GHz, SBFD, FR3, NTN, clustered ROs, and time adaptation would create too many rarely used entries and extra signaling.
• Use partial parameterization : A reduced table can cover common cases, while explicit parameters can handle the parts that need flexibility, such as RO clustering, time adaptation, and valid-frame determination.
• Preserve low SIB1 overhead : More flexible PRACH configuration should still respect the RAN2 goal of keeping system information compact. Full parameterization may be too costly if it increases SIB1 size too much.
• Control conformance burden : Too much configurability can increase RAN4 testing combinations. The design should give deployment flexibility without creating an unbounded test matrix.
• Support clustered RO operation : 6G should be able to configure grouped or clustered RACH occasions so that access resources can be placed close to SS/PBCH bursts or adapted for NES and traffic demand.
• Keep receiver impact visible : Configuration flexibility should not silently create many simultaneous frequency-domain ROs or complex SSB-to-RO associations that overload PRACH receiver processing.

Should 6G move from static PRACH configuration tables toward parameterized or reduced-table configuration?

Yes, 6G should study a more flexible PRACH configuration method. The current NR prach-ConfigIndex table is useful because it gives compact signaling and known configurations, but it also couples many parameters together. That coupling can become restrictive for 6G because deployments around 7 GHz, SBFD, clustered ROs, and time-domain adaptation may need independent control of format, periodicity, time location, frequency location, and RO grouping. The practical direction is not necessarily to remove tables completely. A reduced table can keep common configurations simple, while separately configurable parameters can provide the extra flexibility needed for 6G-specific cases.

• Reduce rigid parameter coupling : A single static index can tie together choices that 6G may need to configure independently, especially for new bands and duplexing patterns.
• Keep compact common cases : Reduced table-based configuration is still useful for normal deployments. It avoids turning every PRACH setup into a long parameter list.
• Add separate parameters where needed : Extra parameters can support clustered ROs, time adaptation, and other deployment-specific behavior on top of a reduced baseline table.
• Support around-7-GHz deployment : 7 GHz operation may need a mix of short 30 kHz formats and long 5 kHz formats. Configuration should not make this mix unnecessarily hard.
• Support SBFD without table explosion : SBFD may introduce RACH opportunities in symbols that are not well captured by fixed NR-style tables. Parameterization can avoid adding many rarely used entries.
• Simplify UE requirements : A smaller table plus explicit extensions can reduce the number of rarely used configurations that every UE must understand.

Should PRACH valid frames be determined relative to SS/PBCH transmission?

Yes, this is a useful direction to study for clustered and distributed ROs. In NR, the UE may need to validate PRACH occasions and avoid cases where ROs overlap with SS/PBCH transmission. R1-2603519 suggests a cleaner 6G rule: determine valid PRACH frames with reference to the SS/PBCH burst, such as the frame containing the SSB burst or the consecutive frame, and then select valid ROs within that frame based on UL symbols and the TDD pattern. This can make the PRACH timing relationship more direct and can place ROs close to the latest synchronization and pathloss reference.

• Avoid PRACH and SSB overlap by design : If valid PRACH frames are defined relative to SS/PBCH, the configuration can avoid invalid ROs without relying on complicated UE-side validation.
• Bound the association period : The SSB burst periodicity can naturally bound the SSB-to-RO association, which is helpful when ROs are clustered rather than spread uniformly.
• Keep Msg1 close to fresh measurements : Placing PRACH shortly after the latest SSB burst gives the UE more recent synchronization and pathloss information for Msg1.
• Improve RO clustering for NES : If ROs are clustered after the SSB burst, other frames can be left freer for network energy saving operation.
• Support both clustered and distributed ROs : A unified valid-frame rule should work for clustered RO configurations and more distributed RO configurations, instead of creating separate mechanisms.

Should 6G allow partially overlapping ROs for different PRACH preamble formats?

6G should study partially overlapping ROs when different PRACH formats are configured in the same cell. The motivation is practical resource efficiency. A cell may want long preambles for UEs in poor coverage and short preambles for UEs in better coverage. Reserving fully separate ROs for both formats can consume more uplink time-frequency resources. R1-2604669 notes that NR already allows multiple RACH configurations without an explicit restriction that their ROs must be non-overlapping. The key question is whether simultaneous transmissions in partially overlapping long and short ROs create acceptable interference at the two detectors.

• Use long and short formats for different UE conditions : UEs below a coverage threshold may use long formats, while UEs with better link quality can use short formats.
• Reduce reserved RO overhead : Partial overlap can avoid reserving fully separate resources for each PRACH format.
• Rely on independent detector hypotheses : The gNB can run separate detection for each configured format and candidate preamble set.
• Check cross-format interference : The contribution indicates limited interference due to low cross-correlation between ZC sequences even when the sequence lengths differ.
• Evaluate Type-1 false detection : The important reliability metric is whether one format's transmission causes a false detection in the other format's detector.

How should RACH be configured across multiple carriers?

Multi-carrier RACH should be treated differently for idle/inactive UEs and connected UEs. For idle or inactive UEs, R1-2604669 sees little benefit in virtual carriers that aggregate multiple physical carriers for initial access. In that state, RACH should be supported on physical carriers carrying CD-SSB and SIB1. For connected UEs, the question is more open. If 6G defines a virtual carrier or extends carrier aggregation behavior, PRACH resources may be configured across carriers, including carriers without CD-SSB/SIB1, to support load balancing or connected-mode procedures.

• Keep idle-mode access tied to physical carriers : Idle/inactive UEs should use carriers with CD-SSB/SIB1 because those carriers provide the system information and synchronization basis for access.
• Study connected-mode multi-carrier RACH : Connected UEs may benefit from PRACH allocations on additional carriers if the network can configure and control them.
• Use virtual carriers only if needed : A virtual-carrier concept should be introduced only if carrier aggregation enhancements cannot solve the target problem.
• Consider load balancing : Allowing PRACH on carriers without CD-SSB/SIB1 may help distribute random access or beam/frequency management load for connected UEs.

How should 6G simplify SSB-to-RO mapping while still supporting beam-based access and clustered SSB/RO structures?

6G should keep SSB-to-RO mapping simple enough for real deployment, while still supporting beam-based random access. NR already defines useful mapping cases, such as multiple SSBs to one RO, one SSB to one RO, and one SSB to multiple ROs. These mappings have been deployed and can be retained as the basic direction. But more complex group-based mapping has not been widely deployed. For 6G, the document suggests studying simplification, especially when SSBs and ROs are clustered. The key point is to avoid overly complex SSB-to-RO association and avoid excessive frequency-domain RO multiplexing, because that can increase PRACH receiver burden.

• Retain the basic NR mappings : The three basic mappings can remain in 6G: multiple SSBs to one RO, one SSB to one RO, and one SSB to multiple ROs. These are already known from NR and have practical deployment value.
• Simplify group-based mapping : NR also defines group-based mapping between groups of SSBs and groups of ROs. But this has not been widely deployed, so 6G should study whether it can be simplified.
• Avoid arbitrary many-to-many mapping : SSB-to-RO mapping should not become too flexible in an uncontrolled way. Too much flexibility can make the association difficult to configure, detect, and implement.
• Consider clustered SSB and RO design together : If SSBs are clustered and ROs are also clustered, the mapping rule must be designed carefully. Otherwise, the relationship between beams and RACH occasions can become unnecessarily complicated.
• Limit RO frequency multiplexing : Clustered ROs should not lead to excessive FDM of multiple ROs. Too many simultaneous ROs in frequency can challenge the PRACH receiver.
• Keep beam-based access practical : The mapping should still allow the UE and network to connect the selected SSB beam to the proper RACH occasion. But this should be done with simple and deployment-friendly rules.

Should SSB-to-RO mapping be non-uniform per beam direction?

Yes, this is worth studying. R1-2604694 argues that real cells do not have uniform UE density across all SSB beam directions. In a ray-traced FR2 deployment example, different SSB beams cover very different numbers of potential UE locations, and across multiple cells a small part of the spatial coverage area can host most of the UE population. If every SSB direction gets the same number of ROs, dense directions can suffer higher collision and latency while sparse directions waste uplink resources.

• Match ROs to UE density : Beams that cover denser UE areas can be configured with more ROs, while sparse beams can use fewer ROs.
• Reduce collision in hot beams : Non-uniform mapping increases access capacity where the actual access load is likely to appear.
• Save uplink resources in sparse beams : ROs that would be underused in low-density directions can be moved or reduced.
• Keep UE derivation simple : The mapping should remain understandable from broadcast configuration. Non-uniformity should not make initial access hard for idle UEs.
• Coordinate with clustered RO design : If 6G clusters ROs near SSB bursts, non-uniform per-beam allocation should be handled together with that timing structure.

Should 6G support dynamic time-domain adaptation of RACH resources based on traffic, NES conditions, or access demand?

Yes. 6G RACH should support time-domain adaptation from the beginning. In NR, RACH resources are mostly based on fixed configurations broadcast through system information. This is simple, but it is not always flexible enough when access demand changes. The document points out that 6G should be able to adapt RACH resources based on NES conditions or traffic demand. This means RACH capacity should not be treated as a static resource only. The network should have a way to increase or adjust RACH opportunities when needed, while avoiding excessive frequency-domain multiplexing and receiver complexity.

• Support adaptation from day one : Time-domain adaptation should be part of the initial 6G RACH design. It should not be added later as a patch on top of a fixed RACH framework.
• Adapt to traffic demand : When more UEs need access, the network should be able to provide more RACH opportunities in time. This can improve access success without permanently reserving too many RACH resources.
• Adapt to NES conditions : The document mentions NES as one driver for PRACH time adaptation. This means RACH resources may need to change depending on network energy saving behavior or related operating conditions.
• Prefer time-domain flexibility : Increasing RACH capacity through time-domain allocation is viewed as a simple direction. It can avoid too much RO frequency multiplexing, which may challenge the PRACH receiver.
• Allow new RACH use of UL resources : The document suggests studying the possibility of allowing additional RACH transmission on uplink data or control resources. This can further improve PRACH time adaptation capability.
• Cluster ROs near SSB bursts for energy saving : R1-2604669 argues that longer SSB/SIB1/PRACH periodicity, such as 160 ms, can provide large network energy saving if ROs are clustered close to SSBs.
• Mitigate access delay with SSB repetitions : Longer periodicity can increase initial access waiting time, but the impact can be reduced by providing SSB repetitions within the period and aligning PRACH occasions after SSBs.
• Keep receiver complexity controlled : Dynamic adaptation should not simply create many simultaneous ROs in frequency. The design should increase flexibility while still keeping PRACH receiver processing manageable.

How should 6G random access work in multi-TRP deployments?

For multi-TRP deployments, the baseline should be transparent initial access. R1-2604669 describes a case where several TRPs broadcast the same SSB and SIB1 and together appear as one cell to an idle-mode UE. The UE cannot distinguish individual TRPs during camping, and no TRP ID needs to be exposed in idle mode. In this baseline, the UE transmits Msg1 using the common RACH configuration. The network receives Msg1 at one TRP or beam, sends Msg2 from that TRP, receives Msg3, resolves contention, and then can activate on-demand synchronization signals from the relevant TRP for subsequent connected-mode operation.

• Keep idle-mode TRPs invisible : The UE should camp on the multi-TRP cell without needing to know which TRP will serve the access attempt.
• Use common SSB and SIB1 : Multiple TRPs can transmit the same SSB and SIB1, simplifying cell reselection and improving in-cell coverage through SFN-like behavior.
• Let the network infer the serving TRP : The network can use Msg1 reception to identify the TRP or beam that should continue the random access exchange.
• Activate on-demand synchronization after access : After contention resolution, the selected TRP can transmit on-demand synchronization signals to support subsequent communication or mobility.
• Use this as the evaluation baseline : More advanced multi-TRP RACH enhancements should be compared against this transparent baseline before adding UE-visible complexity.

Should 4-step RACH be the single baseline procedure for 6G, with 2-step RACH avoided or treated only as an enhancement?

Yes. The 4-step RACH procedure should be the baseline for 6G. The reason is not that 2-step RACH has no value. 2-step RACH can reduce access latency by combining Msg1 and Msg3 into MsgA. But it also has limits. It works better in smaller-range conditions because MsgA is transmitted before timing advance is available. For larger cells or cell-edge UEs, the uplink transmission may not stay within the CP protection. So 4-step RACH is still needed as a fallback. If both procedures are treated as equal baseline options, the 6G RACH design becomes more fragmented. The document therefore points to a simpler direction. Avoid multiple basic RACH procedure options and use 4-step RACH as the baseline.

• Use 4-step RACH as the baseline : The document proposes that 6G should support 4-step RACH as the baseline procedure. This gives a stable and coverage-safe starting point for random access.
• Avoid too many procedure options : Multiple baseline RACH procedures can increase specification and implementation complexity. A single baseline keeps the basic access procedure simpler.
• Recognize the value of 2-step RACH : 2-step RACH can reduce latency because Msg1 and Msg3 are combined into MsgA. So it has a useful role in some conditions.
• Recognize the limitation of 2-step RACH : MsgA is transmitted without timing advance. This makes 2-step RACH less suitable for larger cells or UEs farther away from the gNB.
• Keep coverage as a key reason : At the cell edge, uplink timing uncertainty can make 2-step RACH unreliable. This is why 4-step RACH remains necessary for coverage-limited cases.
• Treat 2-step RACH carefully : If 2-step RACH is used in 6G, it should be treated as an enhancement for suitable scenarios, not as a second equal baseline that complicates the whole design.

How should 6G perform early device or service identification without fragmenting Msg1/PRACH resources?

6G should avoid using Msg1 as the main place for device or service identification. In NR, Msg1-based partitioning was introduced for several features, such as coverage enhancement, RedCap, small data transmission, and slicing. This can provide early indication, but it consumes PRACH resources and fragments the RACH configuration. The document therefore points to Msg3-based identification as the better baseline. Msg3 can carry more explicit information without reserving separate preambles or RACH occasions for every feature. Msg1 partitioning should still be possible, but only for cases where early indication is truly necessary.

• Use Msg3 as the baseline : Msg3-based identification should be the normal direction for 6G. It avoids reserving separate Msg1 resources for many different device types, services, or access reasons.
• Limit Msg1 partitioning : Msg1-based identification should be restricted to limited use cases. It should not become the default method because it consumes PRACH resources even when those resources are not fully used.
• Avoid RACH resource fragmentation : If every feature gets its own preamble set or RO partition, the RACH configuration becomes fragmented. This reduces flexibility and increases specification and implementation complexity.
• Keep early indication only where needed : Some cases may still need Msg1-level indication, such as repetition behavior based on UE capability. But these cases should be justified by a clear technical need.
• Use Msg3 to reduce reserved overhead : Msg3 can indicate device or service information after the initial preamble. This avoids reserving PRACH resources in advance for features that may not be active all the time.
• Keep the access framework clean : The main goal is to prevent 6G RACH from repeating the NR pattern where many feature-specific Msg1 partitions increase complexity over time.

Should 6G use a PRACH preamble plus small payload format for Msg1 indication?

6G should study this as a way to provide limited Msg1 indication without further fragmenting preamble resources. R1-2604669 proposes a PRACH format where a small payload of a few bits follows the preamble repetition or repetitions inside the same RACH occasion. After detecting the preamble, the gNB can use the derived timing and channel estimate to decode the appended payload. This is different from 2-step RACH because the payload is not transmitted in a separate PUSCH occasion. It is also different from preamble partitioning because the information is carried by bits rather than by reserving many preamble groups.

• Reduce preamble partitioning : A small payload can carry early information without splitting the preamble pool into many feature-specific groups.
• Keep Msg1 and payload in one RO : The payload is appended within the same PRACH occasion, avoiding the large gap between MsgA PRACH and MsgA PUSCH in 2-step RACH.
• Use it mainly for good or medium link quality : Appending payload consumes time that could otherwise be used for preamble energy, so poor-coverage UEs may need to transmit a full-length preamble without payload.
• Study multi-UE payload multiplexing : If multiple UEs transmit in the same RO, the method for separating their appended payloads still needs study.
• Keep the payload small : The intended use is a few bits for early indication, not a full Msg3 replacement.

What early UE information should be allowed in Msg1 or Msg3?

Early UE indication should be limited to information that changes how the network handles the random access procedure. R1-2604669 follows the RAN2 principle that Msg1 indication should be used only when it affects Msg1 transmission, RAR, Msg3 scheduling, or related procedures, while Msg3 early indication should be used for information that affects Msg4 scheduling or later related procedures. This means 6G should avoid broad device-type or optional-feature indication during random access unless there is a clear procedural reason.

• Allow coarse coverage-level indication : Msg1 can indicate a coarse UE coverage level so the base station can determine whether repetitions are needed for Msg2, Msg3, Msg4, or later messages.
• Avoid premature device-type indication : Device-type discussions are still unresolved at RAN plenary level, so RAN1 should not design Msg1 or Msg3 device-type indication too early.
• Do not use Msg1 for optional MIMO capability : Optional early MIMO features should not force PRACH partitioning. Capability signaling for such optional features should be avoided in Msg1.
• Consider mandatory early CSI in Msg3 : A small mandatory CSI subset, such as coarse CQI or RSRP related to a common feature set, may be more useful in Msg3 because it can help Msg4 scheduling without Msg1 partitioning.
• Keep indication tied to scheduling impact : Early indication should be justified by a concrete change in RAR, Msg3, Msg4, or repetition behavior.

Should Msg3-based identification become the default method, with Msg1 partitioning restricted to exceptional cases?

Yes. Msg3-based identification should become the default direction for 6G RACH. Msg1 partitioning can give early indication, but it does this by reserving separate preambles or RACH occasions for different purposes. This can consume RACH resources even when the corresponding feature is not used. In NR, this approach was added for several features, and the result was more fragmentation and more complexity. Msg3-based identification is cleaner because the UE can first access through a common PRACH resource and then provide more detailed information in Msg3. So the document suggests using Msg3 as the baseline and limiting Msg1 partitioning to cases where early physical-layer indication is really necessary.

• Make Msg3 the default : Msg3 should be the normal place to identify device type, service type, or access purpose. This keeps Msg1 more common and less fragmented.
• Use Msg1 only when needed : Msg1 partitioning should be restricted to limited cases. It should not be used just because early indication is convenient.
• Avoid reserved PRACH overhead : Msg1 partitioning requires separate preambles or ROs to be reserved. These resources may remain unused, but they still reduce the common RACH resource pool.
• Reduce feature-based fragmentation : NR introduced Msg1 partitioning for multiple features such as coverage enhancement, RedCap, small data transmission, and slicing. 6G should avoid repeating this pattern unless there is a clear need.
• Keep Msg1 simple : Msg1 should mainly serve its core purpose: initial uplink access and timing acquisition. Too much feature signaling in Msg1 can make PRACH configuration harder to manage.
• Allow exceptions for strict requirements : Some cases may still need Msg1-based indication, such as cases related to repetition capability or coverage behavior. But these should be treated as exceptions, not the baseline.

How should coverage enhancement be built into the 6G RACH procedure across Msg1, Msg2, Msg3, and Msg4?

Coverage enhancement should be part of the basic 6G RACH design from the beginning. It should not be added later as a separate feature on top of an already fixed RACH procedure. The document points out that 6G may need to support co-located deployments around 3 GHz and 7 GHz. This creates stronger coverage pressure, especially around 7 GHz. It also notes that Msg3 has been one of the main bottleneck channels for random access coverage in NR. So 6G should consider repetition and coverage support across the whole RACH procedure, not only for Msg1. The practical direction is to design coverage enhancement for Msg1, Msg2, Msg3, and Msg4 together.

• Build coverage support into the baseline : 6G should consider coverage enhancement from the first release. This avoids adding repetition later as a patch, as happened in NR.
• Support repetition for all RACH messages : The document proposes support for repetitions across Msg1, Msg2, Msg3, and Msg4. This means coverage should be treated as an end-to-end RACH procedure issue.
• Do not focus only on PRACH : Msg1 is important because it starts the access procedure. But successful random access also depends on Msg2, Msg3, and Msg4. Coverage failure can happen after PRACH detection as well.
• Treat Msg3 as a key bottleneck : The document notes that Msg3 has been identified as one of the bottleneck channels for coverage. So Msg3 repetition or other enhancement should be considered carefully.
• Support 3 GHz and 7 GHz co-location : Co-located deployment around 3 GHz and 7 GHz implies different coverage characteristics. 6G RACH should be able to handle the weaker coverage side without breaking the procedure.
• Jointly process Msg1 repetitions where possible : R1-2603519 proposes studying Msg1 repetitions that allow the access node to jointly process received samples without creating extreme buffering requirements.
• Avoid fragmented coverage features : Coverage support should not create many isolated RACH options. It should be designed as an integrated part of the procedure so that Msg1-to-Msg4 behavior remains consistent.

Should 6G support both CFRA and CBRA procedures?

Yes. 6G should support both contention-based random access and contention-free random access. CBRA is the general-purpose baseline because it allows UEs to access through shared preambles and common RACH resources. CFRA is still needed for controlled procedures where the network can assign a dedicated preamble or resource, such as mobility-related access or other cases where collision avoidance is valuable. Supporting both does not mean the basic RACH procedure should become fragmented. The main point is to keep both access modes available while preserving a common 4-step baseline and avoiding unnecessary feature-specific Msg1 partitions.

• Keep CBRA as the broad access method : CBRA is needed for ordinary initial access because the network does not yet have enough UE-specific context to allocate a dedicated access resource.
• Keep CFRA for controlled access : CFRA can reduce collision risk when the network can provide UE-specific RACH information before the access attempt.
• Do not multiply procedures unnecessarily : Supporting both CFRA and CBRA should not create many different RACH procedures. The baseline should remain simple.
• Align with 4-step RACH baseline : Both access modes can coexist with the 4-step baseline direction. This keeps the procedure coverage-safe and easier to specify.
• Study paging-triggered CFRA : R1-2604694 proposes assigning CFRA resources in paging for delay-sensitive paged UEs so that collision can be avoided before Msg1.
• Use CFRA for early UE context : If the paging-assigned CFRA resource identifies the UE, the network may retrieve stored capability information earlier and schedule later access messages more appropriately.
• Use paging to balance CBRA load : Paging can also steer different paged UEs toward different CBRA time windows or frequencies instead of letting all UEs select the next available RO.
• Use dedicated resources carefully : CFRA resources should be used where the collision reduction is worth the reservation overhead.

How should 6G handle larger Msg3 payload and coverage?

6G should expect Msg3 to become larger and should design Msg3 coverage accordingly. R1-2604669 explains that Msg3 may need a larger payload than NR, partly to simplify transition from inactive to connected state and to carry a larger UE identifier such as I-RNTI. Msg3 may also need room for some early UE indication. A possible Msg3 TBS mentioned in the contribution is 88 bits. Since Msg3 is already a likely coverage bottleneck for random access, increasing the payload makes coverage support more important.

• Assume Msg3 can grow : 6G Msg3 should not be dimensioned only around the NR payload size. Larger UE identity and early indication may require more bits.
• Protect Msg3 coverage : A larger payload can require more robust scheduling, repetition, or resource allocation because Msg3 is one of the weak links in random access coverage.
• Unify Msg3 and PUSCH allocation thinking : Msg3 transmission can be considered together with other PUSCH transmissions so that time-domain resource allocation can stretch across multiple slots when needed.
• Avoid patching repetitions onto a fixed design : NR introduced Msg3 repetition using limited RAR field repurposing. 6G should make coverage support more native to the design.
• Coordinate with early indication design : If Msg3 carries more early information, the payload increase and coverage impact should be evaluated together.

What coverage target should 6G RACH consider for IoT and low-rate services?

R1-2604694 adds a concrete FR1 FDD coverage target discussion for low-rate IoT-like service. The paper identifies 153 dB MCL as a useful study target for roughly 1 kbps uplink data service. At this target, basic data connectivity can be possible with very robust assumptions, but several access and control channels become bottlenecks. PRACH format 2 without repetitions can be short of the target link budget, and PDCCH, PUCCH, and some broadcast channels also need enhancement.

• Use 153 dB MCL as a stress target : This target reflects very extended coverage for low-rate services such as sensors, metering, or basic messaging.
• Do not evaluate PRACH alone : Even if PRACH is improved, access still fails if Msg2 PDCCH/PDSCH, Msg3 PUSCH, Msg4, PUCCH, or SIB1 coverage is insufficient.
• Consider PRACH repetitions or longer preambles : The contribution notes that PRACH format 2 needs repetition or another link-budget enhancement to approach the 153 dB MCL target.
• Recognize FR3 access bottlenecks : For FR3, Msg3, Msg5, short PRACH formats, PDCCH, and broadcast PDSCH/SIB1 can become coverage bottlenecks under the studied assumptions.
• Coordinate RACH and control-channel coverage : Coverage enhancement should be designed across the full initial-access chain, not only as a stronger preamble.

Should repetition configuration be unified across RACH messages?

Yes. R1-2604694 argues that 6G should avoid the NR pattern where repetitions for different random-access messages are added release by release with different mechanisms. Repetition should be a day-one design element for coverage enhancement, with a more unified way to configure Msg1, Msg2, Msg3, Msg4, and later access-related transmissions.

• Use profile-based repetition : A profile can configure repetition numbers for multiple random-access messages together, such as PRACH Msg1 and Msg2/Msg4 PDCCH.
• Allow different repetition needs per message : A profile does not need to force the same repetition number for every message. Msg1, Msg2 control, Msg3, and Msg4 can have different coverage needs.
• Use DCI for dynamic repetition where useful : Scheduling DCI can indicate repetition for messages such as Msg2 PDSCH, Msg3 PUSCH, Msg4 PDSCH, Msg5 PUSCH, or Msg4 HARQ PUCCH.
• Make coverage support native : Repetition configuration should be part of the 6G RACH framework rather than an exceptional add-on.
• Keep the profile understandable : Unified repetition should reduce complexity, not create a large matrix of unrelated options.

How should initial access reuse mobility context from the previous connected state?

R1-2604694 proposes that initial access can be better integrated with mobility history. In NR, when a connected UE is released to idle or inactive, the candidate-cell configuration used for connected-mode mobility is released. If traffic arrives soon afterward, the UE performs initial access and the serving-cell configuration is rebuilt later in the procedure. For low-mobility or recently released UEs, this may be unnecessary delay and signaling.

• Let idle UEs retain candidate-cell configuration conditionally : A UE could keep candidate-cell configuration for a limited time after RRC release, subject to network rules.
• Accelerate transition back to connected : If the UE accesses one of the retained candidate cells, that cell can start scheduling traffic faster using known configuration context.
• Use it for stable mobility cases : The approach is most suitable for slow mobility, short idle intervals, or cases where the network has high confidence in the UE's likely serving area.
• Avoid stale configuration risk : The retained context needs validity conditions, such as a timer or area constraint, so the UE does not rely on outdated mobility configuration.
• Keep initial access fallback intact : If the retained context is not valid, the UE should still be able to perform ordinary initial access without dependency on old configuration.

Can AI/ML-based spatial and temporal beam prediction improve initial access before the UE enters connected mode?

AI/ML-based beam prediction may improve initial access before the UE enters connected mode, but this requires further study. In Rel-19 AI/ML beam management, AI/ML model operation is mainly considered in connected state, where the network can configure the UE with the needed model-related parameters. Initial access is different. The UE may still be in idle or inactive state, and it may not yet have all network-provided information. The document still sees a possible opportunity. If the UE can operate spatial or temporal beam prediction before connected mode, the predicted beam information may help PRACH transmission, Msg2 reception, Msg3 transmission, and Msg4 reception. So AI/ML can be useful, but it should be treated as an enhancement to the RACH procedure, not as a mandatory replacement for basic beam selection.

• Extend AI/ML beyond connected state : For initial access, the AI/ML model would need to work in idle, inactive, or early access states. This is different from Rel-19 beam management, where the model usage is mainly tied to connected mode.
• Reuse Rel-19 beam prediction ideas : The document suggests studying reuse of Rel-19 spatial-domain and temporal-domain beam prediction models for initial access and random access.
• Use spatial prediction for narrow beams : Spatial beam prediction can estimate narrower beams from SSB measurements. This may help improve PRACH coverage, reduce PRACH attempts, or improve transmission and reception of RACH messages.
• Quantify the Msg1 benefit : In the R1-2603519 evaluation around 7 GHz, AI/ML wide-to-narrow beam prediction reduced Msg1 failures from 0.46% to 0.16% for 500 m ISD and from 2.25% to 0.81% for 1000 m ISD.
• Use temporal prediction for future beams : Temporal beam prediction can estimate which SSB beam may be better at a future time. This can help because the best beam at Msg1 time may not be the best beam at Msg2, Msg3, or Msg4 time.
• Prioritize spatial prediction first : The newer contribution gives spatial-domain beam prediction higher priority than temporal-domain prediction, because the temporal gain appears limited for typical baseline SSB periodicities such as 20, 40, 80, and 160 ms.
• Evaluate AI and non-AI baselines together : R1-2604669 emphasizes that AI-based initial-access beam management should be compared against a non-AI baseline before deciding whether to specify it.
• Consider UE-side and network-side models separately : UE-side prediction may require the UE to know the narrow-beam set before access, while network-side prediction may require extra Msg3 measurements that reduce Msg3 coverage.
• Focus on UE-side wide-to-narrow prediction : R1-2604694 argues that initial-access beam prediction is mainly a UE-side problem, where SSB measurements can be used to predict refined beams before connected-mode configuration is available.
• Keep non-predictive UEs supported : The baseline PRACH design should work for UEs that do not support predictive methods. Beam prediction should provide an enhancement path, not a mandatory access dependency.
• Leave prediction method to implementation : The contribution treats the exact predictive method as implementation-specific. The specification should define any needed signaling or resource behavior, not mandate an AI/ML algorithm.
• Consider missing configuration information : Before connected mode, the UE may not know enough network-side information, such as narrow-beam mapping or RO-to-beam association. This may limit how far AI/ML beam prediction can be used.
• Deprioritize unrelated RACH AI use cases : AI/ML power control for PRACH, early contention resolution, and AI/ML low-PAPR sequence design are proposed to be lower priority because supporting evidence is still limited.
• Treat AI/ML as an enhancement : AI/ML can improve initial access if the prediction is reliable and the required information is available. But the basic RACH procedure should still work without depending on AI/ML.

How should AI/ML-assisted RACH handle prediction uncertainty, especially for cell-edge UEs and multi-beam access?

AI/ML-assisted RACH should not assume that the predicted beam is always correct. This is especially important for cell-edge UEs. At low RSRP, even a small beam prediction error can reduce PRACH detection reliability. The document shows that spatial beam prediction can help coverage, but it also shows that prediction errors can have a long tail, especially with larger antenna arrays. Temporal beam prediction also gives useful gains, but Top-1 prediction may still be close to simple sample-and-hold behavior in some cases. So the practical design should use AI/ML prediction as helpful information, not as a single point of failure. Repetition, Top-K beam candidates, and multi-beam access should be considered to protect random access reliability.

• Do not depend only on Top-1 prediction : A single predicted beam may work well in many cases, but it can fail in the tail cases. For cell-edge UEs, this failure can directly reduce PRACH detection probability.
• Pay special attention to low-RSRP UEs : The document treats low-RSRP operation as critical for PRACH. In this region, beam prediction error can remove the benefit of narrow-beam gain and hurt initial access success.
• Use repetition to absorb prediction error : PRACH repetition can help when the predicted beam is not fully reliable. This gives the UE more chances to reach the gNB even when one beam choice is not optimal.
• Consider multi-beam random access : Multi-beam RA attempts can reduce the risk of choosing the wrong beam. This is useful when the AI/ML model gives several likely beams instead of one clearly reliable beam.
• Use Top-K prediction carefully : Top-2 or Top-K prediction may improve reliability, but the UE and network still need a practical way to select, measure, or use the best beam among the candidates.
• Apply temporal prediction beyond Msg1 : The best beam at PRACH transmission time may not remain the best beam for Msg2, Msg3, or Msg4. Temporal prediction can help track beam changes during the random access procedure.
• Keep AI/ML as assistance, not dependency : The basic RACH procedure should still work when prediction confidence is low. AI/ML should improve beam selection and coverage, but should not become the only path for successful access.

Reference

• R1-2600033 : TSG RAN WG1 #124 - On PRACH and RACH procedure
• R1-2603519 : TSG RAN WG1 #125 - On PRACH and RACH procedure
• R1-2604669 : TSG RAN WG1 #125 - Discussion on PRACH and RACH procedure
• R1-2604694 : TSG RAN WG1 #125 - PRACH and RACH Procedure