This note follows the beam-management discussion from RAN1#124 through the listed RAN1#126-bis documents. It includes the related initial-access measurement papers where they affect beam acquisition, prediction and readiness. Agreements, agreed study scopes and individual proposals retain their different meanings.

The moderator summaries provide the status of each topic. Individual contributions explain the alternatives behind that status. Here, agreement, agreement to study, offline consensus and proposal retain different meanings. None of these study documents is treated as a completed protocol specification.

• Executive Summary
• Mind Map
• Agreed Items
  • RAN1 #126-bis - Release 20 study
• What changed from RAN1#124 to RAN1#126-bis ?
  • From initial scope to specific study cases
  • Agreements, offline consensus and proposals
  • Frequency, bandwidth and numerology assumptions
• Which QCL assumptions are actually supported ?
  • Supported DL QCL properties
  • Single-source and multiple-source proposals
  • Multiple ports and application rules
• How are DL beams measured and reported ?
  • Inter-symbol and intra-symbol sweeping
  • DL reference-signal timing and port choices
  • L1-RSRP and report content
  • Beam acquisition and reporting during initial access
• What changes for multi-TRP and interference-aware reporting ?
  • Preferred beams versus simultaneously receivable beams
  • L1-SINR and interference-measurement resources
  • TRP and beam measurement limits
• What does beam prediction need to prove ?
  • Set A and Set B benchmarks
  • Cross-frequency prediction and channel assumptions
  • Uncertainty, generalization and trajectory modeling
  • Downloadable prediction matrices and measurement consistency
• When is uplink beam sweeping needed ?
  • DL-derived UL spatial filters
  • Asymmetric operation and UL measurement coverage
  • Reference-signal and procedure choices
• How do Event-1 and Event-2 lead to an action ?
  • Event-1 and Event-2 definitions
  • The agreed UE-initiated framework
  • Event metrics, thresholds and UL signaling
• How could TCI indication and application become faster ?
  • Joint and separate TCI state proposals
  • Activation steps and latency-reduction candidates
  • Readiness and synchronization prerequisites
  • Maintained beam information and differentiated measurement cost
• Update Note
• Reference

Executive Summary

The table summarizes the beam-management outcomes and remaining choices covered by this note through the listed RAN1#126-bis records.

Mind Map

Beam management connects measurement, prediction, reporting and beam application. The branches separate those decisions and their prerequisites. Follow a topic to its detailed section, where the note distinguishes confirmed outcomes from study scopes and individual proposals.

Use + to expand a branch and select a topic to see its description and section link. Drag the background or comment boxes with the left mouse button to pan. Hold the left mouse button and turn the wheel to zoom. Toolbar buttons and keyboard navigation are also available.

NOTE: Connecting lines group related subjects; they do not specify a mandatory procedure. Final comment leaves explain the constraint or status of each topic. An agreement to study an option does not mean that option has been selected.

Agreed Items

The entries below separate confirmed meeting outcomes from the proposals discussed in the technical sections. An agreed study scope identifies what RAN1 will compare; it does not select every option in that scope or define final 6GR behavior.

RAN1 #126-bis - Release 20 study

The explicit #126-bis agreement entries in R1-2608778 support the following outcomes. Their scope is preserved here, including the remaining FFS questions. The synchronization summary R1-2608790 supplies related initial-access discussion but does not turn its proposed agreements into confirmed decisions.

• QCL combinations agreed study: study whether and how to combine one or more QCL properties associated with the same source QCL-RS. No final type table or average-gain selection is implied. (R1-2608778.)
• Simultaneous reception agreed Case-2 study: start with NR L1-RSRP, enable differentiation of RS across TRPs/panels, and study reports of simultaneously receivable beams. Include CJT, SFN and NCJT if supported; the report format remains under study. (R1-2608778.)
• Spatial/temporal prediction  agreed study: consider both network-side and UE-side prediction, their report contents and UE training/inference consistency. Predicted-time information remains FFS. (R1-2608778.)
• Cross-frequency prediction  agreed study: consider both network-side and UE-side approaches, source-frequency Set-B metrics, report content and consistency of the UE model's training and inference conditions. (R1-2608778.)
• Event-2 metric — supported: at least L1-RSRP is supported for event evaluation. L1-SINR remains FFS; this does not settle Event-1 metrics or the UL procedure. (R1-2608778.)

Earlier origins retained: RAN1#126 agreed the five DL QCL properties, DL RS identifier support, the DL-derived UL beam baseline under beam correspondence, and the joint/separate TCI study. RAN1#124 initiated the initial-access beam-operation study. These are carried baselines rather than new #126-bis decisions. (R1-2608778; R1-2608790.)

Still proposals: the one-/two-port beam-RS choice, detailed RS timing support, downloadable matrices, average gain, new events and TCI application shortcuts. Their technical rationale remains in the topical sections, outside the confirmed list.

What changed from RAN1#124 to RAN1#126-bis ?

The references now cover five meetings, from RAN1#124 through RAN1#126-bis. The later records clarify some earlier outcomes and add specific study scopes. They still leave important signal, reporting and application choices open, so the page does not construct a finished procedure from the alternatives.

From initial scope to specific study cases

RAN1#124 collects the initial scope: single-TRP and multi-TRP operation, network-initiated and UE-initiated management, and AI/ML and non-AI/ML approaches. Later meetings define evaluation assumptions, measurement cases and event-driven procedures. The latest listed moderator summary still contains revised proposals and competing alternatives alongside explicit agreements. (R1-2601558, R1-2603475, R1-2604248, R1-2605532)

RAN1#126-bis adds an agreed study of QCL property combinations, simultaneous-reception reporting for Case 2, and UE-side versus network-side prediction. It also supports at least L1-RSRP for Event-2 evaluation. Proposed limits on beam-RS ports and proposed latency shortcuts remain outside those confirmed decisions. The latest available summary is R1-2608778; R1-2608004 through R1-2608008 retain the earlier collection and discussion rounds.

Initial-access beam operation has an earlier origin: RAN1#124 agreed to study acquisition, reporting/refinement and spatial/temporal prediction during access. The #126-bis synchronization papers add alternatives within that scope. They do not establish one new mandatory access sequence merely because a proposed agreement is marked closed. (R1-2608790.)

Agreements, offline consensus and proposals

An agreement to study a mechanism does not mean that the mechanism has been selected. Similarly, an item marked offline consensus should keep that label. The moderator documents sometimes retain successive versions of a proposal. Those versions are alternatives or revisions, not several requirements that a UE must satisfy together.

A later summary can clarify an earlier decision without changing its originating meeting. That is the case for the #126 DL RS identifier, DL-derived UL beam baseline and joint/separate TCI study. In contrast, the #126-bis entries explicitly labeled agreement establish the new study scopes recorded here. Company support lists, revised proposals and online-discussion proposals keep their own status. (R1-2608778.)

Frequency, bandwidth and numerology assumptions

The evaluation assumptions also have a limited meaning. RAN1#124-bis lists 4, 7 and 30 GHz TDD cases. Its SLS table uses 20 MHz at 4 GHz and 100 MHz at 7/30 GHz. It pairs 30 kHz SCS with 4/7 GHz and 120 kHz with 30 GHz. Other assumptions are not precluded. These are simulation reference points, not a final 6G band or numerology specification. (R1-2603475)

• Read the status label before treating a candidate mechanism as agreed behavior.
• The coverage extends through the listed RAN1#126-bis documents; it is not a claim about every later 6G decision.

Beam comparisons also need a stated UE architecture. Analog reception, hybrid subarrays and digital reception expose different numbers of spatial observations at once. A method that removes a sweep through simultaneous reception may increase RF or baseband cost. Evaluate that cost with latency and RS overhead, rather than assuming the same hardware can perform every candidate method. (R1-2607036; R1-2607518; R1-2608236.)

Which QCL assumptions are actually supported ?

QCL is one area where the latest moderator summary gives a concrete agreement. Even here, the supported properties do not settle the source signals, the grouping of properties or every rule for applying them.

Supported DL QCL properties

RAN1#126 agrees to support at least five DL QCL properties: Doppler shift, Doppler spread, average delay, delay spread and spatial Rx parameter. Average gain remains for further study. This is narrower than saying that every property discussed at earlier meetings became part of the baseline. (R1-2605532)

RAN1#126-bis agreed to study whether and how one or more QCL properties associated with the same source QCL-RS should form a combination. This defines a study question; it does not select a final QCL type table. Average gain remains a separate proposal, including whether it belongs in a TCI state. (R1-2607047; R1-2607470; R1-2608778.)

Average gain and delay/Doppler properties serve different receiver assumptions. A gain assumption may help avoid repeated power estimation, but must remain meaningful after power changes or precoding. Contributions therefore disagree on including average gain, retaining legacy gain assumptions separately, or signaling it with beam information. The five confirmed #126 properties do not resolve those alternatives. (R1-2607120; R1-2607651; R1-2607700; R1-2608380; R1-2608427.)

Single-source and multiple-source proposals

The contributions explain why the source question matters. One proposal allows flexible QCL sources and multiple sources, and includes average gain among the candidate properties. Another prefers a single source for tracking and spatial information, at least for single-TRP operation. A further proposal excludes average gain while allowing multiple sources for some property combinations. These are different design choices. (R1-2605391, R1-2605323, R1-2605297)

Multiple sources can describe different properties, or the same properties from several TRPs. Those arrangements are not interchangeable. A superposed multi-TRP target can need per-TRP information, while combining sources for a CSI-RS or TRS may hide information needed for precoding or waste a limited tracking budget. The target signal and transmission scheme therefore belong in the source-selection rule. (R1-2607165; R1-2607470; R1-2608051; R1-2608236.)

A shorter QCL chain can reduce waiting for intermediate RS, but the UE still needs a valid observation for each required property. Candidate sources include SSB, CSI-RS, TRS and DMRS with different availability and spatial filtering. Supporting an on-demand source also needs a rule for acquiring it before applying its assumptions. (R1-2607011; R1-2607047; R1-2607659; R1-2607913; R1-2608079.)

Multiple ports and application rules

The number of antenna ports is another unresolved detail. RAN1#126 discusses extending the wording of the QCL definition to multiple ports. That wording appears in a proposal, so it should not be presented as a completed replacement of the definition. Likewise, an agreement to support spatial Rx QCL does not by itself settle cross-carrier applicability. (R1-2605532)

For this note, the safe interpretation is therefore precise: the five DL properties have explicit support in the meeting record. Source multiplicity, source signal selection and detailed application rules still require their own decisions. A TCI diagram should not silently assume those remaining choices.

• Five supported properties do not imply that every channel uses all five.
• Average gain and detailed QCL source arrangements remain open in the cited agreement.

Cross-carrier spatial QCL and cross-carrier delay/Doppler QCL need separate justification. The #126-bis online proposal starts with all properties within one CC and adds intra-band cross-CC spatial Rx QCL, leaving other cross-CC properties FFS. It remains a proposal. Different RF paths, antenna placement and propagation delays prevent a blanket inference that every property transfers between carriers. (R1-2607610; R1-2607651; R1-2607796; R1-2608778.)

An average-delay offset is another proposal for relating a source and target without assuming identical delays. It needs an explicit interpretation alongside the remaining properties, and any use for UL timing must be evaluated separately from TAG association. Extending a definition to multiple antenna ports alone does not provide those timing rules. (R1-2607071.)

How are DL beams measured and reported ?

The DL discussion separates three questions: how the network transmits reference signals, how the UE sweeps its receive beams, and what the UE reports. The references do not select one common answer for all three.

Inter-symbol and intra-symbol sweeping

RAN1#125 uses inter-symbol network and UE beam sweeping as an at-least-supported study baseline. It also studies intra-symbol alternatives. FDM separates network Tx beams in frequency; CDM separates them by sequences. Sub-symbol TDM is considered for UE Rx sweeping. These candidates should not be read as three mandatory 6G modes. (R1-2604248)

Intra-symbol sweeping trades observation resources for a shorter sweep. FDM assigns different frequency resources to Tx beams; CDM assigns sequences; sub-symbol TDM gives the UE shorter Rx-beam observation intervals. Compare channel selectivity, beam switching feasibility, estimator accuracy and architecture constraints. A lower sweep-slot count does not guarantee higher throughput when PDSCH multiplexing and TBS quantization absorb the resource difference. (R1-2607047; R1-2607262; R1-2607520; R1-2607610; R1-2607831.)

One-shot acquisition can use simultaneous DL observations or a network receiver observing UL SRS. The latency comparison must state RS periodicities, receiver architecture and the need for a subsequent report or beam indication. Hybrid-array and low-resolution digital receiver examples are evaluated proposals, not a guarantee that one SRS replaces every P1/P2/P3 operation. (R1-2607036; R1-2607518; R1-2607577; R1-2608236.)

DL reference-signal timing and port choices

RAN1#126 agrees to study aperiodic, semi-persistent and periodic DL RS for inter-symbol sweeping. It also agrees to support a way for the UE to assume whether DL RS use the same Tx spatial filter. The detailed signal design still has to account for measurement coverage, sweeping latency, RS overhead, complexity and energy consumption. Synchronization-signal design itself is outside this agenda item. (R1-2605532)

The one-port versus two-port question is more than a resource-count issue. One contribution points out that two beams can have similar RSRP but different second singular values. A single-port measurement then misses information relevant to spatial multiplexing. Other contributions favor a simpler baseline or question the need for particular sweeping methods. (R1-2606031, R1-2605840, R1-2605916)

One versus two ports remains a measurement trade-off. Two polarized channel observations can expose rank-related information that strongest-port RSRP misses, but port virtualization, combining and report content determine whether that information helps. One-port proposals prioritize a smaller baseline; two-port proposals seek better selection for multiplexing. Compare the same transmitted energy and resource pattern before attributing a gain to port count. (R1-2607470; R1-2607577; R1-2607700; R1-2607831; R1-2608236.)

The latest online-discussion proposal considers no more than two ports per beam-measurement RS resource and a final decision at RAN1#127. It also proposes at least periodic and aperiodic DL RS, leaving semi-persistent support FFS. These are proposals in R1-2608778; the earlier #126 agreement to study all three time-domain behaviors remains the confirmed scope.

A resource can represent two polarization ports of one beam, or different ports can represent distinct beams in an intra-symbol design. The network must make that interpretation clear before the UE reports a resource or port index. Reusing CSI-RS and defining a dedicated beam RS remain competing choices. (R1-2607217; R1-2607262; R1-2607728; R1-2608272; R1-2608380.)

L1-RSRP and report content

For network-initiated reporting, at least L1-RSRP is supported when applicable, including measured or predicted values. RAN1#126 also agreed to support a DL RS identifier as another report quantity when applicable, and to study aperiodic, semi-persistent and periodic reporting. The #126-bis record explicitly attributes these outcomes to #126; the identifier is no longer labeled only as a proposal here. L1-SINR remains a separate study. (R1-2608778.)

• Keep RS transmission timing separate from report timing.
• The cited documents support specific study directions, not a final DL RS format.

Differential quality values and ordered RS indices can reduce report size, but ordering alone only expresses a ranking. A richer report might add weak-beam information for MU-MIMO, eigenvectors, confidence or subband correlation. Each added quantity needs a downstream use that justifies its payload and measurement cost. These enhancements are proposals beyond the confirmed RS identifier and L1-RSRP support. (R1-2607630; R1-2607796; R1-2608079; R1-2608236; R1-2608536.)

A network-refined analog beam may differ from every measured beam. Its evaluation needs the measured inputs, refined-beam derivation and the UE Rx filter used when the beam is applied. Reusing the old Rx filter saves another measurement but may leave no directly measured RS for later QCL or recovery. Additional sounding can resolve that uncertainty at a resource and latency cost. (R1-2607262; R1-2607470; R1-2607577; R1-2608051; R1-2608236.)

Angular or cluster information is another proposed way to reduce redundant beam feedback. Several strong neighboring beam indices may describe one dominant arrival region rather than independent alternatives. A cluster report can compress that information, but needs a known beam relationship and must retain what the scheduler needs for refinement or pairing. Near-field propagation also limits a direct plane-wave interpretation of a beam index. (R1-2608536.)

Beam acquisition and reporting during initial access

Early acquisition can expose a useful narrow beam before the UE reaches steady connected-mode operation. The available information is limited, however: the UE first needs synchronization, resource locations and a beam association that it can interpret without a complete dedicated configuration.

The candidate starting point uses the SSB selected for access and its PRACH association. Proposals then add CSI-RS, an on-demand signal or SIB1 DMRS for refinement, with SRS as a separate UL option. A second-stage resource needs a known trigger, timing and association to the acquired SSB or access resources. Prediction does not supply missing resource configuration. (R1-2607062; R1-2607111; R1-2607464; R1-2607622; R1-2608461.)

Early reports appear in Msg3, MsgA or later PUSCH, and some proposals use PRACH-resource selection as an implicit beam indication. Those choices have different causal limits. A measurement triggered after Msg2 cannot improve the PRACH transmission that preceded it. Explicit payload must fit the reporting message without undermining the coverage benefit it seeks. (R1-2607208; R1-2607302; R1-2607340; R1-2607716; R1-2607929; R1-2608347.)

Wide discovery beams and narrower access beams can balance coverage, energy saving and subsequent data performance. More distinct beams improve directional resolution but also enlarge the measurement and association problem. Repetition accumulates energy on an existing beam; it does not automatically create a new beam observation or improve angular resolution. (R1-2607156; R1-2607464; R1-2607871; R1-2607900; R1-2607914; R1-2608347.)

Transparent multi-TRP discovery can keep the UE unaware of physical TRP identities. A resource or beam association may still let the network choose the access receiver. Non-transparent alternatives expose TRP information for early selection or CSI, with extra detection and signaling cost. Neither arrangement can be inferred merely from several strong SSB measurements, and SFN gain depends on energy, delay and phase assumptions. (R1-2607404; R1-2607444; R1-2607661; R1-2607737; R1-2607850; R1-2608294; R1-2608461.)

Longer SSB periods, clustered repetitions and on-demand signals change the time until another usable beam observation. A cell-search energy result alone does not establish beam tracking, RLM or connected-mode measurement latency. State the UE mode, available dedicated RS and fallback behavior. The candidate periods and structures remain alternatives in the synchronization discussion. (R1-2607028; R1-2607263; R1-2607451; R1-2607560; R1-2607603; R1-2607777; R1-2608029; R1-2608070; R1-2608479.)

What changes for multi-TRP and interference-aware reporting ?

A list of strong beams does not necessarily tell the network which beams the UE can receive together. RAN1#125 explicitly separates these two reporting cases, which helps explain several otherwise similar-looking proposals.

Preferred beams versus simultaneously receivable beams

Case 1 concerns the preferred N greater than one beams per TRP or across TRPs. Case 2 concerns M greater than one beams from different TRPs that are simultaneously receivable. The agreed study uses NR non-group-based L1-RSRP reporting as a benchmark. It examines reporting format, RS measurement and L1-RSRP calculation. The actual multi-TRP transmission scheme belongs to another agenda discussion. (R1-2604248)

The diagram below keeps that distinction visible. Case 1 supplies beam preferences. Case 2 adds a joint-reception condition. It does not imply that the network must schedule the illustrated pair or use a particular transmission scheme.

Figure 1. The two agreed multi-TRP study cases ask different questions about the reported beams. Beam labels are illustrative.

L1-SINR and interference-measurement resources

L1-SINR introduces another distinction. A strong desired signal can still suffer significant interference. The agreed study therefore compares L1-SINR-based reporting with L1-RSRP-based reporting. It includes intra-TRP and inter-TRP interference and considers channel-measurement resources, interference-measurement resources and report content. (R1-2604248, R1-2605532)

Some contributions propose associating one channel-measurement resource with several interference-measurement resources. The report could then distinguish interference hypotheses for the same desired beam. This is a proposal for richer information, not an agreed universal CMR-to-IMR mapping. (R1-2605391, R1-2605297)

RAN1#126-bis agreed a Case-2 study using NR L1-RSRP as a starting point, with functionality for differentiating RS from different TRPs or panels within or across cells. It studies report content for simultaneously receivable beams and at least CJT, SFN and NCJT, if supported. This extends the agreed study detail; it does not choose a final group format or transmission scheme. (R1-2608778.)

Independently selecting the strongest beam of each TRP can produce an unusable combination. Two selected beams may require incompatible Rx filters on one UE panel, or cause strong mutual interference. Group prediction and group reporting must evaluate the combined reception condition. A per-TRP Top-1 accuracy result cannot establish that condition by itself. (R1-2607071; R1-2607659; R1-2608236.)

Implicit grouping can associate RS resources with TRPs without reporting a physical TRP identifier. Other proposals add an explicit identifier or let a group represent a transmission hypothesis. The report must tell the network whether it contains preferred beams per TRP, selected TRPs, or a jointly receivable combination. Those meanings should survive compression and ordering. (R1-2607011; R1-2607165; R1-2607417; R1-2607630; R1-2607700; R1-2608272; R1-2608356.)

An L1-SINR value needs a defined desired-signal resource and interference hypothesis. One-to-one configured CMR/IMR pairing is a simple candidate; one-to-many or UE-selected pairing can expose more interference conditions. Extra hypotheses cost measurements and report bits, so they need a useful scheduling or pairing decision. (R1-2607011; R1-2607470; R1-2607518; R1-2607520; R1-2608038; R1-2607913.)

Interference-related measurements can differ across UEs when time and frequency observation resources are unspecified. Repetition, SSB symbols, silent resources and load can change the estimated interference even for the same desired signal. Proposed measurement definitions therefore identify or configure those resources. A comparable L1-SINR report needs that context as well as a quantization rule. (R1-2608283; R1-2608347; R1-2608790.)

MU-MIMO selection also needs weak or conflicting spatial directions, not only each UE’s strongest beam. Proposed methods use weak-beam reports, confidence vectors or successive beam exclusion to reduce spatial collisions. Their gain must be compared with L1-RSRP/L1-SINR baselines under equal overhead and load. An exclusion rule that removes too many beams can sacrifice useful diversity. (R1-2607502; R1-2607796; R1-2607831; R1-2608427.)

TRP and beam measurement limits

The practical limit also remains part of the study. RAN1#125 calls for considering the number of TRPs, beams per TRP and total measured beams. Individual resource-count proposals differ. These limits affect measurement time and report size, so the note cannot select a convenient number and call it the 6G capability.

• Preferred beams and simultaneously receivable beam groups carry different information.
• L1-SINR reporting and detailed interference-resource associations remain study and proposal topics.

The #126-bis proposals include more than two TRPs, four-TRP hypotheses and larger beam-resource sets. They distinguish configured resources, measured resources, selected TRPs and active transmission states. A large configured beam pool does not mean every UE measures all beams each period. Capability and overhead comparisons must identify which count actually limits operation. No common maximum follows from the differing proposals. (R1-2607470; R1-2607630; R1-2607831; R1-2608038; R1-2608272; R1-2608380.)

What does beam prediction need to prove ?

The prediction discussion asks whether fewer measurements can provide useful beam decisions. It also asks how that result changes across cells and frequencies. A favorable result in one measurement arrangement does not answer all these questions.

Set A and Set B benchmarks

The agreed evaluation framework distinguishes a larger target set, Set A, from the measured input set, Set B. Benchmark 1 measures Set A without prediction. Benchmark 2 measures only Set B without prediction. A prediction method must be compared with both. Otherwise, a result may hide either the performance lost against fuller measurement or the improvement over the same reduced measurement budget. (R1-2603475, R1-2604248)

RAN1#126-bis agreed to study both network-side and UE-side spatial/temporal prediction. The network-side study includes measured-beam counts per TRP and across TRPs in one report. The UE-side study includes report content and training/inference consistency, such as extending association IDs across cells or TRPs. Temporal prediction also leaves the predicted time-instance information FFS. (R1-2608778.)

For a fair overhead comparison, count the measurements used to collect labels, refresh statistics and monitor performance. A small inference Set B does not make those other measurements free. State whether the prediction target is the best Tx beam, a Tx/Rx pair, a group or future quality. The benchmark must represent the decision the network actually makes. (R1-2607011; R1-2607071; R1-2607217; R1-2607577; R1-2607913.)

Cross-frequency prediction and channel assumptions

RAN1#125 identifies cross-frequency cases such as [4 GHz] to [7 GHz] and [4 GHz] to [30 GHz]. The brackets belong to the study assumptions. The channel-generation procedure preserves multi-frequency correlation using the 38.901 approach before removing source-frequency channels from target TRPs. Different antenna placements and non-collocated deployments need further modeling attention. (R1-2604248)

The contributions do not draw one common conclusion about the harder frequency pair. One proposes deprioritizing 4-to-30 GHz prediction. Another considers cross-frequency candidate-beam prediction feasible. Those positions should remain separate, since deployment, prediction target and performance criteria can differ. (R1-2605840, R1-2606510)

The #126-bis cross-frequency agreement studies both network-side and UE-side prediction. For network prediction, the reported source-frequency Set-B metrics need definition. For UE prediction, report contents and training/inference consistency need definition. It does not establish one model, require a neural network or resolve non-colocated channel-model limitations. (R1-2608778.)

Co-location does not imply identical antenna height, orientation or tilt. Those differences affect the relation between source measurements and target beams even when TRPs share a site. Separate geometry, large-scale-parameter correlation and UE antenna assumptions from the predictor itself. Report target-cell identification and Top-K results where relevant, since a useful candidate list need not have a correct Top-1 beam every time. (R1-2607011; R1-2607071; R1-2607352; R1-2607659; R1-2607967; R1-2608236; R1-2608427.)

For initial access, a UE-side predictor may map acquired wide-beam measurements to narrow candidates before network-side reporting is available. Proposed benefits must be measured over the access procedure, including uncertainty and fallback for a UE without a suitable model. Earlier connected-mode prediction feasibility does not by itself define the access signaling or prove a PRACH coverage gain. (R1-2607062; R1-2607560; R1-2607871; R1-2608215; R1-2608418; R1-2608532.)

Uncertainty, generalization and trajectory modeling

Other proposals emphasize uncertainty reporting, invalid predictions and generalization. A separate contribution warns that long trajectories need realistic LoS and shadow-fading evolution. It also questions non-collocated cross-frequency evaluation without an adequate channel model. These concerns explain why a beam-prediction gain cannot be quoted independently of the evaluation assumptions. (R1-2605942, R1-2606384)

• Use both Set A and Set B benchmarks when interpreting a prediction result.
• The study includes AI/ML and non-AI/ML approaches; prediction is not synonymous with a neural network.

A confidence value should predict actual error under the configured conditions. Proposals consider invalid predictions, sudden blockage, reported measurement uncertainty and the need to suspend predicted events. A receiver-specific gain bias can also affect network-side learning. Define the network action and monitoring procedure before adding a confidence field to every report. (R1-2607470; R1-2607520; R1-2607831; R1-2608079.)

Long trajectories need changing LoS state and correlated shadow fading where appropriate. Static large-scale conditions can create implausible handover or prediction results. Test changed cells, antenna placements and channel states, and identify the associated measurement budget. Results for one fixed trajectory or indoor geometry should not be generalized to every deployment. (R1-2607042; R1-2607071; R1-2608427.)

A prediction-region approach evaluates candidate beams over a range of possible future positions, including a worst-case quality measure. It must also constrain the beam patterns to realizable amplitude/phase controls and count reconfiguration between tracking occasions. A continuously optimized pattern may otherwise show a gain that the assumed array cannot implement. This remains an uncertainty-aware design proposal. (R1-2607042.)

Downloadable prediction matrices and measurement consistency

A downloaded matrix is a proposed way for the network to supply a prediction rule without downloading a complete neural-network implementation. Its usefulness depends on the input measurements, the output meaning and how often the matrix must change for the deployment.

The #126-bis online proposal uses a matrix W with measured Set-B inputs X and predicted Set-A outputs Y. The network may derive W with AI or non-AI methods. Study details include matrix generation, dimensions, quantized inputs and the report metric derived from Y. The proposal is not an agreed matrix format or a selected prediction method. (R1-2607352; R1-2607470; R1-2608778.)

Download cost and lifetime belong in the overhead comparison. A site-specific matrix can exploit stable beam relationships, but a changed array, cell association or measurement normalization can make it stale. Other contributions question whether the download duplicates UE-side inference without a demonstrated benefit. Compare accuracy, compute, storage and signaling against both full measurement and prediction with the same reduced inputs. (R1-2607071; R1-2607352; R1-2607470.)

When is uplink beam sweeping needed ?

The UL discussion starts with a dependency: can a UE determine its UL transmit spatial filter from a DL reference signal? If that is sufficient, a separate UL sweep needs a clear additional purpose.

DL-derived UL spatial filters

RAN1#126 agreed to study the target usage, necessity and procedure of UE UL beam sweeping. Its RAN1 baseline allows the UL Tx beam of a channel or RS to be determined from DL RS, assuming UE beam correspondence. The #126-bis record identifies this as a #126 agreement and records endorsement of the liaison to RAN4. It is therefore an agreed baseline with a stated assumption, rather than only offline consensus. (R1-2608778.)

Asymmetric operation and UL measurement coverage

Earlier versions and individual contributions identify possible exceptions or additional uses. These include asymmetric DL and UL arrangements, such as single-TRP DL with multi-TRP UL. They also include exposure-related transmit-power restrictions and using UL measurements to assist DL beam decisions. These are reasons to investigate UL measurements, not proof that every UE needs an independent exhaustive sweep. (R1-2605532, R1-2606384)

UL-based DL measurement has an important condition in the contributions: the network must receive the UL signal reliably enough. An evaluation contribution discusses benefits under some indoor conditions but limits at a UMa cell edge with poor UL SNR. Reciprocity alone does not remove that measurement-coverage problem. (R1-2605942)

Asymmetric DL and UL TRPs can make a DL-selected beam inadequate for UL reception, even when the UE has beam correspondence. Exposure-related power limits and different Tx/Rx path gains add further conditions. Proposed UE-estimated UL quality may help identify such cases, but its interpretation depends on calibration and the assumed network receiver. (R1-2607165; R1-2607071; R1-2607831; R1-2608427.)

SRS-based DL beam determination can reduce DL sounding and feedback, but only if the network obtains a useful UL observation. The evaluated coverage differs between indoor, UMi and UMa deployments. A bounded SRS enhancement or fallback to DL RS is one proposed response to marginal quality. Count the UL power, repeated observations and displaced traffic before claiming a net saving. (R1-2607036; R1-2607520; R1-2607831; R1-2608236.)

Reference-signal and procedure choices

The references also disagree about how much new signaling is necessary. One favors DL-based UL beam determination as the baseline and investigates exceptions. Another proposes a new UL beam-management RS rather than simply reusing SRS. These positions lead to different overhead and implementation choices. (R1-2605323, R1-2605916)

For now, a procedure description should therefore state its assumption. A DL-derived UL spatial filter, an SRS-assisted decision and a dedicated UL sweep are different candidate arrangements. The listed documents do not establish one mandatory sequence containing all three.

• UL sweeping still needs a justified use case and procedure.
• DL-to-UL correspondence and adequate UL measurement coverage are separate assumptions.

A network receiver can observe several spatial hypotheses digitally or through multiple subarrays, while an analog receiver may need repetitions. SRS-based acquisition therefore needs a stated architecture and a rule for indicating the resulting DL or UL beam. A dedicated UL sweep, existing sounding and UL measurements accompanying an event remain different candidate procedures. (R1-2607036; R1-2607262; R1-2607651; R1-2607831; R1-2608236.)

Retuning, guard periods and available UL symbols can limit a sounding opportunity. A proposed absence of a retuning gap depends on RF settling capability; it is not a universal timing assumption. Initial-access UL sounding must also fit the timing and resources known to the UE, rather than inheriting a fully configured connected-mode SRS procedure. (R1-2607737; R1-2608109; R1-2608461.)

How do Event-1 and Event-2 lead to an action ?

UE-initiated beam management lets the UE report a problem or a better candidate when an event occurs. The references agree on the broad event meanings before they settle the exact measurements, UL signaling and response rules.

Event-1 and Event-2 definitions

Event-1 concerns serving-beam quality falling below a threshold, including beam failure. Event-2 concerns a candidate beam exceeding the serving beam by a threshold. The candidate can belong to the same PCI or a different PCI. Single-TRP operation is the starting point, with extension to multi-TRP operation studied separately. (R1-2603475, R1-2605532)

For Event-2, #126-bis supports at least L1-RSRP as the evaluation metric; L1-SINR remains FFS. That decision does not select the Event-1 metric or every reported quantity. Hypothetical PDCCH BLER concerns decodability on a monitored link, while a candidate without a monitored PDCCH needs a different observable quality basis. (R1-2607047; R1-2608236; R1-2608778.)

The degradation and failure cases can leave very different UL resources usable. Proposed Event-1 designs therefore use separate instances, distinct metrics or two thresholds. Counter/window detection can reject transient changes but adds latency; one-shot detection reacts faster and may trigger on a short disturbance. No common threshold, counter or instance structure is selected by the Event-2 metric agreement. (R1-2607071; R1-2607120; R1-2607262; R1-2607470; R1-2607967; R1-2608272.)

The agreed UE-initiated framework

RAN1#126 agrees on the framework shown below: event detection, UL transmission, network response if any, and UE behavior if any after the response. The conditional wording matters. It leaves room for different procedures instead of requiring a fixed request-response handshake in every case. (R1-2605532)

Figure 2. The agreed UE-initiated framework preserves the conditional network response and subsequent UE behavior.

Event metrics, thresholds and UL signaling

The event quantity and the reported quantity are also separate choices. The study considers measured or predicted L1-RSRP, L1-SINR and hypothetical BLER for event evaluation. Report quantities include L1-RSRP and L1-SINR. It does not follow that every candidate event metric must appear in every report. (R1-2604248)

Event-1 has competing detailed designs. One uses two quality thresholds to distinguish degradation from failure. Another allows multiple Event-1 configuration instances, each with its own evaluation and reporting behavior. Other proposals favor early recovery and avoid PRACH for that purpose, while separate proposals retain PRACH-based recovery or fallback. These alternatives reflect different assumptions about how much connectivity remains. (R1-2605532, R1-2605297, R1-2605323, R1-2605391)

The UL candidates include a notification followed by a report, a notification followed by SRS, and more direct transmission arrangements. PUCCH, PRACH, PUSCH and SRS appear in the discussion. Their names should not be joined into one mandatory message sequence. Likewise, one-shot detection and counter/window-based detection remain competing choices. (R1-2605532)

• Event detection, report content and recovery action require separate decisions.
• Do not replace the agreed Event-1 definition with one contribution's narrower early-recovery proposal.

A notification/report split can provide a short early indication before a larger beam report. A direct PUSCH or PRACH alternative changes the grant, contention and payload assumptions. After beam failure, a UL filter derived from the failed direction may also be unreliable; a candidate-beam PRACH can have a different coverage and timing role from a degradation report on PUCCH. These alternatives still need their own response and fallback rules. (R1-2607047; R1-2607071; R1-2607630; R1-2607831; R1-2608236; R1-2608356.)

An SRS-only event transmission risks losing both the notification and beam information when the network cannot detect it. A separate notification can change that risk but adds resources. Likewise, predicted and measured candidate beams need defined validity and recovery behavior. A report that never arrives cannot serve as the network’s confirmation that a new beam is ready. (R1-2607520; R1-2607651; R1-2607867; R1-2607913.)

The multi-TRP event proposals compare per-TRP or per-TCI evaluation with an aggregate across TRPs. An aggregate needs a defined combination rule and measurement window; a strong surviving TRP can otherwise conceal a failed one. Additional candidate-cell events and autonomous switching remain proposals. They are not new confirmed events simply because several inputs support studying them. (R1-2607120; R1-2608038; R1-2608427; R1-2608778.)

How could TCI indication and application become faster ?

The TCI discussion deals with both the information a state represents and the time needed to use it. The contributions propose several shortcuts, but the latest listed summary does not turn them into one agreed activation procedure.

Joint and separate TCI state proposals

RAN1#126 agreed to study a TCI framework with joint and separate DL/UL states across single- and multi-TRP, cell and carrier operation. Joint states cover at least PDSCH and PUSCH for the study; separate DL and UL states cover at least PDSCH and PUSCH respectively. Other target channels and RS remain FFS. The #126-bis record confirms the #126 origin, without turning this agreed study scope into a completed activation procedure. (R1-2608778.)

Power control, timing-advance-group information and other transmission parameters remain separate study questions. The source-RS content and detailed application rules also retain FFS items. TCI remains study terminology, with final terminology left to the work-item phase. These agreements do not define a finished state format or ASN.1 structure. (R1-2608778.)

A wider TCI application scope can reduce separate beam updates for PDCCH, PUCCH, CSI-RS and SRS, but some signals need independent spatial relations. Multi-TRP transmission, asymmetric DL/UL operation and carrier-specific resources can also require different state associations. The #126-bis proposals differ on a common state, channel-specific exceptions and a separate beam indication versus other QCL information. (R1-2607047; R1-2607262; R1-2607577; R1-2607700; R1-2607913; R1-2608236; R1-2608356.)

Beam indication may need related power-control, timing and scrambling information when it changes a TRP or cell. Those parameters should be coordinated with the transmission that uses the new direction. Associating them with a TCI indication is a proposal for lower-layer operation, not an adopted rule that every beam change updates a complete cell configuration. (R1-2607011; R1-2607047; R1-2607610; R1-2607796; R1-2608380.)

Activation steps and latency-reduction candidates

Some contributions propose removing a separate MAC CE activation step and using DCI for activation and indication. Others discuss retaining or simplifying a multi-level structure, including its relationship with mobility. These are competing control designs. Neither can be called the selected 6G procedure from this reference set. (R1-2605840, R1-2605323, R1-2605942)

A single DCI step, a two-part DCI and retained MAC CE activation trade signaling size against application delay. Group-cast activation or simultaneous updates across carriers add resource-alignment and receiver assumptions. A shorter control exchange is useful only if all affected transmissions use a consistent state at the intended time. These control designs remain alternatives. (R1-2607217; R1-2607577; R1-2607796; R1-2607913; R1-2608380.)

Readiness and synchronization prerequisites

These candidates target different delays. Some reduce measurement waiting; others reduce signaling or acknowledgment steps. A UE that already measured and synchronized to a candidate has different prerequisites from a UE that still needs reference signals. The relevant proposal must therefore state what the UE already knows before claiming a shorter application time. (R1-2605532)

• Reduced TCI latency is a study objective; removal of MAC CE activation is a proposal.
• Readiness, synchronization and confirmation assumptions determine whether a shortcut can work.

Readiness and confidence answer different questions. A beam can have high predicted quality yet need another RS before the UE can apply its timing or spatial filter. Proposed readiness fields distinguish immediate use from preparation or acquisition; proposed confidence fields describe uncertainty in quality or prediction. Neither field alone constitutes network approval to switch. (R1-2607520; R1-2607891; R1-2607913; R1-2608236.)

SSB sparsity can increase the wait for a fresh timing observation. An on-demand signal or an already synchronized candidate may shorten that wait, but the scheduler needs to know which prerequisite is satisfied. Initial-access repetition indices and beam associations must remain interpretable when the transmission pattern changes. A default period alone cannot define a safe beam application time. (R1-2607062; R1-2607716; R1-2607949; R1-2608029; R1-2608418; R1-2608461.)

Maintained beam information and differentiated measurement cost

Keeping candidate information before a beam change can reduce the work after blockage or mobility triggers an update. The cost moves into regular maintenance, so the network needs a useful candidate set and a way to recognize information that has become stale.

One proposal distinguishes serving, candidate and non-serving beams, then separates identification, maintenance, refinement and serving-beam determination. Different categories can use different measurement detail and update rates. Maintaining every observable beam at serving-beam precision would defeat the overhead benefit. This is a proposed framework, not a selected new hierarchy of protocol states. (R1-2607891.)

Static or low-mobility FWA can relax several costs independently: RS/report frequency, reported beam count, TCI switching, event hysteresis and unnecessary multi-TRP differentiation. The proposal uses existing NR ranges as feasibility examples, not as agreed 6GR periodicities. Stationary installation also does not eliminate transient blockage, environmental motion or the need for recovery. (R1-2608017.)

The UE’s measurement obligation matters as much as the configured beam pool. Signaling a bounded search set or maintaining only plausible candidates can reduce work, while sparse observations can slow detection of an unexpected change. Compare long-term maintenance cost and post-event latency together, with the same recovery reliability. (R1-2607891; R1-2608017; R1-2608029.)

Update Note

• 2026-10-16 - Consolidated RAN1#126-bis individual papers and summaries into Agreed Items, study status, QCL, DL measurement, multi-TRP reporting, prediction, UL sweeping, UE-initiated management, TCI application, Reference; corrected earlier outcome labels and added initial-access, prediction-matrix and maintained-beam subsections.

Reference

• R1-2601558 (RAN1#124) : Moderator summary #3 on beam management for DL and UL (Moderators, ZTE, Apple)
• R1-2600038 (RAN1#124) : On beam management for downlink and uplink in 6GR (Nokia)
• R1-2600150 (RAN1#124) : Beam management for downlink and uplink (Huawei, HiSilicon)
• R1-2600193 (RAN1#124) : Discussions on 6GR multi-beam operation (OPPO)
• R1-2600230 (RAN1#124) : Discussion on beam management for downlink and uplink (ZTE Corporation, Sanechips)
• R1-2600762 (RAN1#124) : Views on beam management for downlink and uplink in 6GR (Samsung)
• R1-2600834 (RAN1#124) : On beam management aspects for downlink and uplink (Apple)
• R1-2601027 (RAN1#124) : Discussion on beam management for downlink and uplink (Ericsson)
• R1-2601188 (RAN1#124) : Discussion on Beam management for downlink and uplink (NTT DOCOMO, INC.)
• R1-2601279 (RAN1#124) : Beam management for downlink and uplink (Qualcomm Incorporated)
• R1-2602855 (RAN1#124-bis) : Collection on evaluation assumptions for 6GR beam management (Moderators, ZTE, Apple)
• R1-2603475 (RAN1#124-bis) : Moderator summary #6 on beam management for DL and UL (Moderators, ZTE, Apple)
• R1-2601838 (RAN1#124-bis) : On beam management for downlink and uplink in 6GR (Nokia)
• R1-2601867 (RAN1#124-bis) : Discussion on beam management for downlink and uplink (ZTE Corporation, Beijing Digital Nebula, Sanechips)
• R1-2601932 (RAN1#124-bis) : Beam management for downlink and uplink (Huawei, HiSilicon)
• R1-2602192 (RAN1#124-bis) : Views on beam management for downlink and uplink in 6GR (Samsung)
• R1-2602437 (RAN1#124-bis) : Discussions on 6GR multi-beam operation (OPPO)
• R1-2602679 (RAN1#124-bis) : Views on beam management aspects for downlink and uplink (Apple)
• R1-2602747 (RAN1#124-bis) : Discussion on beam management for downlink and uplink (Ericsson)
• R1-2603019 (RAN1#124-bis) : Beam management for downlink and uplink (Qualcomm Incorporated)
• R1-2603067 (RAN1#124-bis) : Discussion on Beam management for downlink and uplink (NTT DOCOMO, INC.)
• R1-2604244 (RAN1#125) : Collection on advanced DL measurement and report mechanisms for 6GR beam management (Moderators, ZTE, Apple)
• R1-2604248 (RAN1#125) : Moderator summary #4 on beam management for DL and UL (Moderators, ZTE, Apple)
• R1-2603524 (RAN1#125) : On beam management for downlink and uplink in 6GR (Nokia)
• R1-2603685 (RAN1#125) : Discussion on beam management for downlink and uplink (ZTE Corporation, Beijing Digital Nebula, Sanechips)
• R1-2603859 (RAN1#125) : On beam management aspects for downlink and uplink (Apple)
• R1-2604117 (RAN1#125) : Discussions on 6GR multi-beam operation (OPPO)
• R1-2604186 (RAN1#125) : Views on beam management for downlink and uplink in 6GR (Samsung)
• R1-2604266 (RAN1#125) : Beam management for downlink and uplink (Huawei, HiSilicon)
• R1-2604446 (RAN1#125) : Discussion on beam management for downlink and uplink (Ericsson)
• R1-2604699 (RAN1#125) : Beam management for downlink and uplink (Qualcomm Incorporated)
• R1-2604742 (RAN1#125) : Discussion on Beam management for downlink and uplink (NTT DOCOMO, INC. , NTT, Inc.)
• R1-2605528 (RAN1#126) : Collection on pending topics for 6GR beam management for DL and UL (Moderators, ZTE, Apple)
• R1-2605532 (RAN1#126) : Moderator summary #4 on beam management for DL and UL (Moderator, ZTE)
• R1-2605297 (RAN1#126) : Beam management for downlink and uplink (Huawei, HiSilicon)
• R1-2605337 (RAN1#126) : Discussion on beam management for downlink and uplink (ZTE Corporation, Beijing Digital Nebula, Sanechips)
• R1-2605391 (RAN1#126) : On beam management for downlink and uplink in 6GR (Nokia)
• R1-2605840 (RAN1#126) : Discussion on beam management for downlink and uplink in 6GR (Samsung)
• R1-2605916 (RAN1#126) : Discussions on 6GR multi-beam operation (OPPO)
• R1-2605942 (RAN1#126) : Discussion on beam management for downlink and uplink (Ericsson)
• R1-2606031 (RAN1#126) : On beam management aspects for downlink and uplink (Apple)
• R1-2606384 (RAN1#126) : Beam Management for Downlink and Uplink (Qualcomm Incorporated)
• R1-2606510 (RAN1#126) : Discussion on Beam management for downlink and uplink (NTT DOCOMO, INC., NTT, Inc.)
• R1-2605323 (RAN1#126) : DL and UL beam management (MediaTek Inc.)
• R1-2607011 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (ZTE Corporation, Beijing Digital Nebula, Sanechips)
• R1-2607028 (RAN1#126-bis) : 6G Synchronization Acquisition and Beam Measurement (FUTUREWEI)
• R1-2607036 (RAN1#126-bis) : Discussion on beam management for downlink and uplink for 6GR air interface (FUTUREWEI)
• R1-2607042 (RAN1#126-bis) : Discussion on beam management for downlink and uplink in 6GR (Comba)
• R1-2607047 (RAN1#126-bis) : DL and UL beam management (MediaTek Inc.)
• R1-2607062 (RAN1#126-bis) : On  synchronization acquisition and beam measurement (Nokia)
• R1-2607071 (RAN1#126-bis) : On beam management for downlink and uplink in 6GR (Nokia)
• R1-2607111 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (Spreadtrum, UNISOC)
• R1-2607120 (RAN1#126-bis) : Discussion on beam management for downlink and uplink for 6GR (Spreadtrum, UNISOC)
• R1-2607156 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (CMCC)
• R1-2607165 (RAN1#126-bis) : Discussion on beam management for downlink and uplink transmission (CMCC)
• R1-2607208 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement for 6GR (Xiaomi)
• R1-2607217 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (Xiaomi)
• R1-2607262 (RAN1#126-bis) : Discussions on 6GR beam management (OPPO)
• R1-2607263 (RAN1#126-bis) : Discussion on Synchronization acquisition and beam measurement for 6GR (OPPO)
• R1-2607302 (RAN1#126-bis) : Discussion on Synchronization acquisition and beam measurement (ZTE Corporation, Sanechips)
• R1-2607340 (RAN1#126-bis) : Discussions on 6GR synchronization acquisition and beam measurement (vivo)
• R1-2607352 (RAN1#126-bis) : Discussion on beam management for 6GR downlink and uplink (vivo)
• R1-2607404 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (CATT, CICTCI)
• R1-2607417 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (CATT)
• R1-2607444 (RAN1#126-bis) : Discussion on design of the synchronization (Transsion Holdings)
• R1-2607451 (RAN1#126-bis) : Discussion on Synchronization acquisition and beam measurement for 6GR (LG Electronics)
• R1-2607464 (RAN1#126-bis) : Synchronization acquisition and beam measurement for 6GR (Huawei, HiSilicon)
• R1-2607470 (RAN1#126-bis) : Beam management for downlink and uplink (Huawei, HiSilicon)
• R1-2607502 (RAN1#126-bis) : Discussion on AI/ML-based beam management for MU-MIMO in 6GR (Pengcheng Laboratory, BUPT)
• R1-2607518 (RAN1#126-bis) : Discussion on beam management for 6GR downlink and uplink (BeammWave AB)
• R1-2607520 (RAN1#126-bis) : Beam management for downlink and uplink (Kyocera Corporation)
• R1-2607560 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement for 6GR (Samsung)
• R1-2607577 (RAN1#126-bis) : Discussion on beam management for downlink and uplink in 6GR (Samsung)
• R1-2607603 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (China Telecom)
• R1-2607610 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (China Telecom)
• R1-2607622 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (1Finity)
• R1-2607630 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (1Finity)
• R1-2607651 (RAN1#126-bis) : Discussion on beam management for downlink and uplink in 6GR (Lenovo)
• R1-2607659 (RAN1#126-bis) : Beam management for downlink and uplink (NEC)
• R1-2607661 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement during initial access (NEC)
• R1-2607700 (RAN1#126-bis) : Discussion on beam management for downlink and uplink in 6GR (HONOR)
• R1-2607716 (RAN1#126-bis) : Synchronization acquisition and beam measurement (Tejas Networks Limited)
• R1-2607728 (RAN1#126-bis) : Discussion on Beam Management for Uplink and Downlink (Tejas Network Limited)
• R1-2607737 (RAN1#126-bis) : Initial access design for 6GR (Panasonic)
• R1-2607777 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (Quectel)
• R1-2607796 (RAN1#126-bis) : Beam Management for Downlink and Uplink (Google)
• R1-2607831 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (Ericsson)
• R1-2607850 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (CSCN)
• R1-2607867 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (TCL)
• R1-2607871 (RAN1#126-bis) : Synchronization acquisition and beam measurement (Ericsson)
• R1-2607891 (RAN1#126-bis) : Discussion on Maintained Beam Information for 6GR Beam Management (Rakuten Symphony)
• R1-2607900 (RAN1#126-bis) : Views on synchronization acquisition and beam measurement (MediaTek Inc.)
• R1-2607913 (RAN1#126-bis) : Beam management for 6GR downlink and uplink (InterDigital, Inc.)
• R1-2607914 (RAN1#126-bis) : Synchronization acquisition and beam measurement (InterDigital, Inc.)
• R1-2607929 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (Google)
• R1-2607949 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (TCL)
• R1-2607967 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (LG Electronics)
• R1-2608004 (RAN1#126-bis) : Collection on pending topics for 6GR beam management for DL and UL (Moderator (ZTE))
• R1-2608005 (RAN1#126-bis) : Moderator summary #1 on beam management for DL and UL (Moderator (ZTE))
• R1-2608006 (RAN1#126-bis) : Moderator summary #2 on beam management for DL and UL (Moderator (ZTE))
• R1-2608007 (RAN1#126-bis) : Moderator summary #3 on beam management for DL and UL (Moderator (ZTE))
• R1-2608008 (RAN1#126-bis) : Moderator summary #4 on beam management for DL and UL (Moderator (ZTE))
• R1-2608017 (RAN1#126-bis) : On multi-axis beam management overhead reduction for static and low-mobility FWA CPE (HFCL)
• R1-2608029 (RAN1#126-bis) : 6GR Synchronisation and Beam Management (Sony)
• R1-2608038 (RAN1#126-bis) : Discussion on beam management for downlink and uplink (Sony)
• R1-2608051 (RAN1#126-bis) : On beam management for downlink and uplink in 6GR (Fraunhofer IIS, Fraunhofer HHI)
• R1-2608070 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (ETRI)
• R1-2608079 (RAN1#126-bis) : Discussion on beam management for 6GR (ETRI)
• R1-2608109 (RAN1#126-bis) : Synchronization, Frame structure and coverage (Nordic Semiconductor ASA)
• R1-2608215 (RAN1#126-bis) : Synchronization acquisition and beam measurement (Apple)
• R1-2608236 (RAN1#126-bis) : On beam management aspects for downlink and uplink (Apple)
• R1-2608272 (RAN1#126-bis) : Discussion on 6GR Beam Management Framework (AT&T)
• R1-2608283 (RAN1#126-bis) : 6G measurements (T-Mobile USA, Ericsson)
• R1-2608294 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (KT Corp.)
• R1-2608347 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement (NTT DOCOMO INC.)
• R1-2608356 (RAN1#126-bis) : Discussion on Beam management for downlink and uplink (NTT DOCOMO, INC. , NTT, Inc.)
• R1-2608380 (RAN1#126-bis) : Beam management for downlink and uplink (Sharp)
• R1-2608418 (RAN1#126-bis) : Synchronization acquisition and beam measurement (Qualcomm Incorporated)
• R1-2608427 (RAN1#126-bis) : Beam management for downlink and uplink (Qualcomm Incorporated)
• R1-2608445 (RAN1#126-bis) : FL summary #1 of Synchronization acquisition and beam measurement (Moderator (Huawei))
• R1-2608446 (RAN1#126-bis) : FL summary #2 of Synchronization acquisition and beam measurement (Moderator (Huawei))
• R1-2608447 (RAN1#126-bis) : FL summary #3 of Synchronization acquisition and beam measurement (Moderator (Huawei))
• R1-2608448 (RAN1#126-bis) : FL summary #4 of Synchronization acquisition and beam measurement (Moderator (Huawei))
• R1-2608449 (RAN1#126-bis) : FL summary #5 of Synchronization acquisition and beam measurement (Moderator (Huawei))
• R1-2608450 (RAN1#126-bis) : FL summary #6 of Synchronization acquisition and beam measurement (Moderator (Huawei))
• R1-2608461 (RAN1#126-bis) : Discussion on synchronization acquisition and beam measurement for 6GR (Jio Platforms)
• R1-2608479 (RAN1#126-bis) : Discussion of synchronization of 6GR (ASUSTeK)
• R1-2608532 (RAN1#126-bis) : Discussion on Synchronization acquisition and beam measurement (CEWiT)
• R1-2608536 (RAN1#126-bis) : Views on Beam management for downlink and uplink (CEWiT)
• R1-2608778 (RAN1#126-bis) : Moderator summary #5 on beam management for DL and UL (Moderator (ZTE))
• R1-2608790 (RAN1#126-bis) : FL Summary #7 of synchronization acquisition and beam measurement (Moderator (Huawei))