Coverage enhancement has come round three times in NR, and each round attacked a different part of the uplink. Phase 3 is the Rel-20 round, and it is narrower than the two before it. Three objectives, all in the uplink, and all aimed at the part of the call that happens before the UE has any dedicated configuration.

The interesting change is what Phase 3 does with repetition. Rel-18 already repeats a PRACH preamble on the same transmit beam. Phase 3 keeps that and adds something different: the UE sends its preamble on several different transmit beams, and the network tells it which one worked. That is beam diversity rather than energy accumulation, and it costs the same airtime either way.

This page follows the RAN1 agreements from RAN1#122bis through RAN1#125, which is where the design was settled. Where a point was still open when RAN1#125 closed, it is listed as open rather than guessed at.

• Executive Summary
• Acronym
• What is Coverage Enhancement Phase 3, and what is in its scope?
• Which three objectives did RAN approve?
• Where does the work item sit in the RAN1 agenda?
• How does PRACH improve when the UE sweeps its transmit beams?
• How are the transmissions told apart?
• How many transmissions per attempt, and who decides?
• What changes in RA-RNTI and the RAR window?
• How does the UE learn which uplink beam to use?
• Which indication options survived the down-selection?
• Which bits in the RAR uplink grant carry it?
• What does PUSCH repetition scheduled by DCI 0_0 with C-RNTI add?
• What is reused from Msg3 repetition?
• How is the repetition number indicated?
• How does the UE ask for it?
• How far does pi/2-BPSK extend, and what does it buy?
• Why is this really a DFT-s-OFDM question?
• Which MCS entries qualify?
• What is the power gain actually worth?
• How does the network configure it, and how does the UE help?
• What was still open when RAN1#125 closed?
• Reference

Executive Summary

The table below is a lookup rather than a narrative. Each row names an area, what the agreements say about it, and what follows from that.

Acronym

The list is short on purpose. Standard NR vocabulary is left out, because a reader of a 3GPP note already carries it. What remains is the vocabulary of the random access procedure and of the agreements quoted on this page.

What is Coverage Enhancement Phase 3, and what is in its scope?

A work item is only as wide as its objectives, and this one was drawn deliberately narrow. Knowing where the boundary sits explains several agreements that otherwise look arbitrary, because RAN1 kept refusing to widen the design beyond what RAN approved.

Coverage Enhancement for NR Phase 3 is a 5G-Advanced Rel-20 work item. RAN approved it at RAN#108 and revised it at RAN#109, and the scope lives in WID RP-252824. Every RAN1 session on the topic opens by pointing at that document rather than restating it.

Which three objectives did RAN approve?

Three objectives share the work item, and all three act on the uplink. Two of them target the random access procedure, and the third targets the modulation used once the UE is transmitting data. Reading them together shows why the page below is organised the way it is.

The first objective specifies PRACH coverage enhancements, and it is the largest of the three. It covers multiple PRACH transmissions with different Tx beams for the 4-step RACH procedure, and it says the UE may receive uplink beam information after transmitting Msg1. That information assists the UE decision on the Msg3 beam. RAN2 shares this objective with RAN1.

Five notes bound it, and they matter more than the sentence they qualify.

• The phrase "different Tx beams" is written for the purpose of future RAN1 discussions rather than as a final term.
• The enhancements target FR2, and they can also apply to FR1 where applicable.
• They target short PRACH formats, and can also apply to other formats where applicable.
• The PRACH repetitions are transmitted over ROs associated with the same SSB.
• The procedure for repetitions of a PRACH transmission is as in Rel-18.

The second objective specifies enhancements to support PUSCH repetition scheduled by DCI 0_0 with C-RNTI, again shared with RAN2. The third specifies enhancements that improve PUSCH coverage for a higher uplink data rate, by extending pi/2-BPSK to more MCS entries in the MCS tables. That third one sits with RAN1 alone.

Where does the work item sit in the RAN1 agenda?

Finding the contributions is harder than it should be, because the agenda item number moved while the work was running. Anyone searching a TDoc list for a single number will miss half of the documents, so both numbers are worth writing down.

RAN1 opened the work item at agenda item 10.4, titled Coverage Enhancement Phase 3, with the technical discussion at 10.4.1. That numbering held for RAN1#122bis and RAN1#123. From RAN1#124 the same work item moved to 9.4, with the discussion at 9.4.1, and it kept that number through RAN1#125.

The meetings themselves run from October 2025 to May 2026. RAN1#122bis met in Prague, RAN1#123 in Dallas, RAN1#124 in Gothenburg, RAN1#124bis in Malta and RAN1#125 in Dalian. A feature lead ran an email discussion on Rel-20 CE at every one of them.

• Three objectives, all uplink : PRACH with different Tx beams, PUSCH repetition scheduled by DCI 0_0 with C-RNTI, and a wider pi/2-BPSK range.
• The notes are the real scope : FR2 first, short PRACH formats first, and every repetition over ROs associated with the same SSB.
• Rel-18 is the baseline, not the target : the procedure for repeating one PRACH transmission is unchanged, and the new part is the beam sweep on top of it.
• The agenda item number moved : 10.4.1 at RAN1#122bis and RAN1#123, then 9.4.1 from RAN1#124 onward.

How does PRACH improve when the UE sweeps its transmit beams?

At FR2 a random access attempt can fail for a reason that has nothing to do with power. The UE picked a transmit beam, and that beam pointed somewhere unhelpful. Sending the same preamble again on the same beam does not fix that, which is the limit Rel-18 repetition runs into.

Phase 3 answers it by sending the preamble on several different transmit beams inside one RACH attempt. The network only has to hear one of them. Everything in this section follows from that single change. Most of the agreements are bookkeeping. How are the transmissions told apart, how many are there, and what do the timing rules become once one attempt occupies several occasions?

The drawing below shows one RO group as the network sees it. Four ROs run in time order, each carrying the same preamble on a different UE transmit beam, and all of them are associated with the same SSB. The two markers underneath are the timing rules that had to change, because both used to refer to a single occasion.

Figure 1. One RACH attempt spread over an RO group. Both timing rules that used to point at a single occasion now point at the last valid one, which is what makes a group behave like a single attempt.

How are the transmissions told apart?

The receiver has to separate several transmissions that carry the same preamble, and it has two ways to do it. RAN1 settled that question early, at the first meeting of the work item, and kept the answer unchanged afterwards.

Separate ROs, or separate preambles on a shared RO, differentiate multiple PRACH transmissions. The same mechanism covers transmissions with the same transmit beam and with different transmit beams, which keeps one design rather than two. A later agreement lets the network configure those same two mechanisms through RRC parameters, so that different numbers of transmissions can also be distinguished.

One working assumption from RAN1#122bis was confirmed at RAN1#123. Multiple PRACH transmission with different Tx beams is supported for CBRA, for the ReconfigurationWithSync case in CFRA, and for SI request. RAN1 assumes one common solution covers all three cases.

A great deal is simply reused from the same-beam case, which is the fastest way to read this part of the design. The definition and determination of the RO group carry over. So do the definition of the time period, the SSB-to-RO mapping rule, the time offset between RO groups, and the PRACH power control rule. The preamble itself is shared: the same preamble is applied for all the PRACH transmissions in the group.

How many transmissions per attempt, and who decides?

A beam sweep is only useful if it covers the beams that matter, and every extra transmission costs airtime. The number therefore has to be chosen rather than fixed, and RAN1 spent three meetings deciding who chooses it.

The ceiling came first. The maximum candidate value of the total number of PRACH transmissions is 8 per RACH attempt. RAN1#123 then fixed the candidate set itself at 2, 4 and 8 transmissions in one attempt.

Choosing among those values took longer, and the answer is a three-way split based on how the network configures RSRP thresholds. If a single threshold is configured, it decides whether multiple PRACH transmissions with different Tx beams are used at all. The transmission count then follows the number of transmit beams the UE supports, rounded to a candidate value. If multiple thresholds are configured, each threshold maps to one total number of transmissions. If no threshold is configured, both the decision and the count are up to UE implementation.

Which beams to use is a separate question, and it stays with the device. It is up to UE implementation to determine which transmit beams to use, subject to any necessary restriction, and that restriction is still FFS. RAN1#125 also recorded a conclusion rather than an agreement here: there is no consensus to support configuring the UE to use the same transmit beams in part of the PRACH transmissions.

What changes in RA-RNTI and the RAR window?

One RACH attempt now occupies several occasions, so every rule that used to name "the" occasion had to name one of them. Two rules matter, and RAN1 resolved both the same way, by pointing at the last valid RO in the group.

RA-RNTI is calculated based on the last valid RO in the RO group. The RAR window reuses its Rel-18 definition, with the starting point placed after the last symbol of that same last valid RO. That second rule arrived as a working assumption at RAN1#124 and was confirmed with the modification at RAN1#125.

The RO index needed a definition too, because the beam indication described further down carries it as its payload. The RO index is the ascending order of the ROs in the time domain within the RO group. Nothing else is read into the ordering.

A last agreement covers the case where the whole idea fails. RAN1 considers a fallback beneficial when multiple PRACH transmissions with different Tx beams do not succeed. The UE returns to the Rel-18 same-beam behaviour in the following RACH attempts, if configured. The details sit with RAN2.

• Beam diversity, not more energy : the same preamble goes out on several transmit beams, so one blocked direction no longer costs the attempt.
• Two ways to separate the transmissions : separate ROs, or separate preambles on a shared RO, and the same choice covers same-beam and different-beam cases.
• The candidate totals are 2, 4 and 8 : with 8 as the agreed ceiling per RACH attempt.
• RSRP thresholds decide the count : one threshold, several thresholds, or none at all, and the last case hands the decision to the UE.
• Timing rules point at the last valid RO : both RA-RNTI and the start of the RAR window, which is what lets a group act as one attempt.

How does the UE learn which uplink beam to use?

Sweeping beams on Msg1 only pays off if something comes back. The UE has just transmitted the same preamble in four directions, and the network heard one of them. Unless the network says which, the UE is guessing again by the time Msg3 arrives, and the sweep bought nothing beyond a better chance of detection.

This is the part of the work item that RAN2 shares, and it took four meetings and a liaison statement to settle. The path from five candidate options to a bit-level encoding is worth following, because the reasoning explains why an unusual pair of fields ended up carrying the information.

Which indication options survived the down-selection?

Five options went on the table at RAN1#122bis, and they differ in which message carries the indication and how much room that message has. Reading them in order shows the trade the group was making between UE complexity and scheduler freedom.

• Option 1 indicates the beam implicitly, by RA-RNTI.
• Option 2 indicates it explicitly in DCI format 1_0 with CRC scrambled by RA-RNTI, for example in reserved bits.
• Option 3 indicates it explicitly by repurposing one or more fields in the uplink grant inside the RAR.
• Option 4 indicates it explicitly by introducing a new field in the MAC RAR.
• Option 5 indicates it explicitly by repurposing one or more bits in the MAC RAR.

RAN1#123 cut the list to Options 1, 3 and 4, at least for the initial Msg3 transmission. RAN1#124 then narrowed the content rather than the mechanism, by agreeing to indicate only one uplink beam to the UE.

Option 4 needed an answer RAN1 could not give itself, because a new field in the MAC RAR is RAN2 territory. RAN1#124 sent a liaison statement asking whether Option 4 is feasible and, if so, what its advantages and disadvantages look like from RAN2's perspective. A working assumption set the schedule at the same time: down-select between Options 1 and 3 at RAN1#124bis, and bring Option 4 back only if RAN2 confirmed it was feasible.

RAN1#124bis adopted Option 3. The indication is explicit, and it repurposes fields in the uplink grant inside the RAR. Its content is the RO index within the RO group, which is why that index needed a definition at all.

Which bits in the RAR uplink grant carry it?

Repurposing means taking bits that already have a job, so the choice of fields is a statement about which existing function the group was willing to lose first. The answer splits across two fields, and the split is not symmetric.

One bit always comes from the CSI request field, and it is the most significant bit of the indication. Any further bits come from FDRA, and they are labelled N_UL,beam. A one-bit indication therefore uses the CSI request bit alone. A two-bit indication adds one FDRA bit, and a three-bit indication adds two.

Position inside FDRA is specified rather than left to implementation. The N_UL,beam bits are the most significant bits of FDRA after N_UL,hop, and everything remaining after them is decoded as a RIV configuration exactly as before. Figure 2 lays the three cases out side by side.

Figure 2. Where the beam indication comes from. The design spends one CSI request bit first and only then borrows from FDRA, so a one-beam-bit deployment leaves the resource assignment untouched.

One conclusion from RAN1#125 extends the indication beyond the message it was designed for. The UE can refer to the indicated uplink transmit beam for the Msg3 transmission and retransmission, and for the subsequent uplink transmissions. A beam learned during random access therefore does not have to be relearned immediately afterwards.

• The sweep needs an answer to be worth anything : without an indication the UE would guess again at Msg3, and the extra Msg1 transmissions would buy only detection probability.
• Five options became one : explicit indication by repurposing fields in the uplink grant in the RAR, carrying the RO index within the RO group.
• RAN2 decided the shape of the answer : a liaison statement on the feasibility of a new MAC RAR field gated whether Option 4 stayed alive.
• CSI request is spent before FDRA : one bit there is the most significant bit, and only wider indications reach into the resource assignment.
• The beam outlives Msg3 : the same indicated beam applies to Msg3 retransmission and to the uplink transmissions that follow.

What does PUSCH repetition scheduled by DCI 0_0 with C-RNTI add?

NR already repeats Msg3, and it already repeats a PUSCH that a dedicated configuration has described. Between those two there is a gap. A UE that has finished random access but has not yet received RRCReconfiguration is transmitting real data with none of the machinery that normally configures repetition.

The second objective fills that gap. The feature lead used a shorthand worth borrowing. Msg5 stands for the PUSCH repetition scheduled by DCI format 0_0 with C-RNTI before RRCReconfiguration, and post-Msg5 stands for the same thing afterwards. RAN1#123 agreed to support both, with a note to strive for a single mechanism covering them.

What is reused from Msg3 repetition?

Designing this from scratch was never the intention, so the first agreement points at Msg3 repetition and takes its rules wholesale. Knowing which rules moved across, and which one was then corrected, is most of what an implementer needs here.

The RV determination rule carries over, including first RV id determination, RV sequence selection and RV cycling. The available slot determination rule carries over with it. Both apply to PUSCH Repetition Type A only.

RAN1#123 then corrected one piece of that inheritance. The first RV id of PUSCH repetition scheduled by DCI format 0_0 with C-RNTI follows the indication in DCI format 0_0, rather than the Msg3 rule it had just inherited. The agreement says explicitly that it updates the earlier one.

Frequency hopping was settled separately and in two stages. Inter-slot frequency hopping is supported, and intra-slot frequency hopping is not, unless the repetition time is 1. For the hopping offset, the UE follows the Table 8.3-1 determination of TS 38.213 when frequencyHoppingOffsetLists is not configured, and follows the explicit configuration when it is. RAN1#125 also agreed that the repetition is supported when the UE is configured with SBFD symbols.

How is the repetition number indicated?

DCI format 0_0 is the smallest downlink control format in use, which is exactly why this problem is hard. There are no spare bits in it, so any repetition count has to be taken from a field that already carries something else.

Five candidates were listed at RAN1#122bis. The first is at most 2 MSB of the MCS field, and the second is the TDRA. The third is the padding bits, and the fourth is the 2 MSB of the HARQ process number field. The fifth is the DAI field in DCI 1_0 with CRC scrambled by TC-RNTI. RAN1#123 cut that to two, the MCS field and the TDRA, and RAN1#124bis chose the MCS field.

The final encoding from RAN1#125 is adaptive, and it spends only the bits it needs. If a set of two values is configured in SIB1, one MSB of the MCS field selects between them. Otherwise two MSB select from a set of repetition values configured in SIB1, or from a default set when nothing is configured. That default set is 1, 2, 4 and 8.

Taking bits from the MCS field costs MCS resolution, and the group paid that cost explicitly. When one or two MSB carry the repetition count, the values of MCS indicated by the remaining four or three LSB can themselves be configured in SIB1. The wider candidate list for the repetition count is larger than the default set: 1, 2, 3, 4, 7, 8, 12, 16, 20, 24, 28 and 32.

How does the UE ask for it?

Repetition before RRCReconfiguration raises an awkward question of sequence. The UE needs the feature precisely when it has no dedicated signalling to request it with, so the request has to travel inside the random access procedure itself.

Two carriers were considered at RAN1#122bis, Msg3 and the HARQ-ACK of Msg4, and RAN1#123 chose Msg3. RAN1#124bis added the trigger: the request is based on a configured RSRP threshold of a downlink reference signal, so the UE asks only when the measurement says it needs to.

Capability is reported separately from the request. The UE reports its capability to support DCI 0_0 with C-RNTI scheduled PUSCH repetition in the common UECapabilityInformation RRC signalling. RAN1#124 recorded a conclusion that the detailed signalling design for the request before RRCReconfiguration is up to RAN2.

One more control exists for the post-RRCReconfiguration case. RAN1#125 agreed to introduce RRC signalling, sent by the gNB, that disables or enables PUSCH repetition scheduled by DCI format 0_0 with C-RNTI after RRCReconfiguration.

• The feature fills the gap after random access : a UE with no dedicated configuration can still be told to repeat.
• Msg3 repetition supplies the rules : RV determination and available slot determination carry over, for Repetition Type A only.
• The first RV id was the exception : it follows the DCI format 0_0 indication instead, in an agreement that explicitly updates the earlier one.
• The MCS field pays for the indication : one or two MSB carry the count, and the remaining LSB can be reinterpreted through SIB1.
• A measurement gates the request : the UE asks in Msg3 only when a configured RSRP threshold says the link needs it.

How far does pi/2-BPSK extend, and what does it buy?

pi/2-BPSK already exists in NR, and it already improves uplink coverage. Its problem is range. It is available only at the very bottom of the MCS tables. A UE that needs it therefore drops to a data rate far below what the link could otherwise carry.

The third objective widens that range. The gain being chased is not a coding gain, and keeping that in mind avoids a common misreading. The pi/2-BPSK waveform has a lower peak to average power ratio than QPSK, which lets the transmitter run closer to its maximum. The extension is about reaching a higher data rate while keeping that advantage.

Why is this really a DFT-s-OFDM question?

The objective never uses the word waveform, and that hides what it does. The pi/2-BPSK modulation exists in NR only when transform precoding is enabled. Every agreement in this section is therefore a DFT-s-OFDM agreement written in a different vocabulary.

The two MCS tables say so themselves. Table 6.1.4.1-1 and Table 6.1.4.1-2 of TS 38.214 are the PUSCH tables for transform precoding, and the discussion calls them the 64QAM table and the 64QAM lowSE table. A UE reading either of them is already running DFT-s-OFDM.

The signalling points the same way. The new RRC parameter that carries the maximum spectral efficiency is present only when tp-pi2BPSK is enabled, and that switch is the existing NR control for pi/2-BPSK with transform precoding.

Companies framed the scope in those terms too. One proposal restricts the feature to DFT-s-OFDM PUSCH as specified in Rel-15. Another asks for an MCS table with more pi/2-BPSK entries only for DFT-s-OFDM. A third asks for the DFT-s-OFDM MCS table for 64QAM to be enhanced, to match the work item aim of improving cell edge data rates.

So this work widens how far a UE can stay on a waveform that NR already has, and it does not introduce one. That is what separates it from the 6G coverage study, where DFT-s-OFDM is weighed against CP-OFDM and frequency domain spectral shaping is layered on top. Neither of those appears in the agreements or the feature lead summaries behind this page. The 6G coverage enhancement note follows that separate argument.

Which MCS entries qualify?

Deciding the range meant choosing a ceiling and a mechanism, and the two were argued separately. The ceiling arrived first and has not moved since, while the mechanism took three meetings.

pi/2-BPSK is extended to MCS entries with spectral efficiency no larger than N, where N is at most 0.8770. Alongside that, the code rate is doubled so that spectral efficiency stays the same. That second agreement is what keeps the extension honest: the entry delivers the same throughput as before, and the benefit shows up as transmit power rather than as rate.

RAN1#122bis also decided how the question would be answered rather than answering it. Link level simulation decides which MCS entries qualify, and it weighs two effects together. The LLS performance gain is the gain or loss of pi/2-BPSK against QPSK at the same spectral efficiency. The power boosting gain is what the lower PAPR allows on top of that.

Two shapes of answer were then compared at RAN1#123. Option 1 extends pi/2-BPSK to all entries with spectral efficiency at or below N = 0.8770, with the gNB configuring the maximum. Option 2 fixes a value X, either 0.8770 or 0.6016, captures the extension in a modified MCS table, and has the gNB enable or disable the feature by RRC. RAN1#124 adopted Option 1. RAN1#125 confirmed the reach: the extension applies to both Table 6.1.4.1-1 and Table 6.1.4.1-2 of TS 38.214.

The ceiling has a mechanical reason behind it. A pi/2-BPSK symbol carries one bit, so its code rate and its spectral efficiency are the same number. An entry needing a code rate above 1 is not a valid configuration, and one company placed the limit at MCS 6 in the 64QAM table for exactly that reason. The agreed 0.8770 is the highest tabulated entry below the limit, reached at MCS index 6 in the 64QAM table and at MCS index 12 in the lowSE table.

That RAN1#125 agreement also closed a real argument. Several companies preferred extending the 64QAM table alone. Several others were willing to extend the 64QAM lowSE table as well. The feature lead gave the 64QAM table the higher priority while the question stayed open, and the meeting then took both.

What is the power gain actually worth?

A lower peak to average ratio is only worth something if the transmitter is allowed to use it. The size of that prize decides how far up the tables the extension still makes sense, so it is the number the whole objective depends on.

Several companies put the gain at up to 2.8 dB when power boosting is adopted, measured against QPSK for a PC3 UE using DFT-s-OFDM. Two companies recorded the other case. Without power boosting the same gain falls to about 1 dB.

That difference sets the ceiling. Assuming the 2.8 dB, the overall coverage gain of pi/2-BPSK over QPSK holds while spectral efficiency stays below 0.877. The agreed value of 0.8770 comes straight from that boundary.

The feature lead turned the observation into scope. A closed proposal treats the PC3 UE using DFT-s-OFDM with power boosting as the main objective when deciding which MCS entries to extend. A note adds that the extension can also be supported for other UEs. One case was left FFS: whether the extension applies to a PC3 UE using DFT-s-OFDM without power boosting.

How does the network configure it, and how does the UE help?

Option 1 leaves the ceiling in the network's hands, which raises a practical problem. The gNB has to pick a maximum spectral efficiency without knowing how much the lower PAPR is actually worth on a particular device, and that value varies with the power amplifier.

Configuration itself is compact. The gNB configures the maximum spectral efficiency of MCS up to which pi/2-BPSK applies, through a new RRC parameter, and that same parameter implicitly enables the extension. No separate enable flag is needed.

The UE side took longer. RAN1#124bis listed two candidate contents for assistance information. The first is the maximum spectral efficiency of the MCS index the UE prefers. The second is the power gain the UE can obtain with pi/2-BPSK. Four candidate carriers went with them: UE capability report, UAI, PHR and MAC CE. RAN1#125 chose the first content and the first carrier. The UE reports the maximum spectral efficiency of the MCS index it prefers as a maximum, through the UE capability report. That report is a component of the UE feature for pi/2-BPSK extension.

• This is a DFT-s-OFDM feature under another name : pi/2-BPSK exists only with transform precoding, so both MCS tables and the enabling switch are transform precoding ones.
• The ceiling is a spectral efficiency, not an MCS index : every entry at or below 0.8770 qualifies, in both TS 38.214 MCS tables.
• 2.8 dB is what the ceiling rests on : that is the gain with power boosting, against about 1 dB without it, and it is why the benefit stops near 0.877.
• Doubling the code rate holds the rate constant : the extension buys transmit power, and it does not buy throughput.
• Simulation decides the entries : LLS weighs the performance difference against QPSK together with the power boosting the lower PAPR allows.
• One RRC parameter does two jobs : it sets the maximum spectral efficiency and implicitly enables the feature.
• The UE states a preference, not a measurement : it reports the maximum spectral efficiency it prefers, as part of its capability.

What was still open when RAN1#125 closed?

Reading a work item in progress means separating what is decided from what merely looks decided. The agreements above are firm, but several of them carry an FFS that changes how they will be implemented, and a few questions had not been opened at all by RAN1#125.

On the PRACH side, the restriction on UE transmit beam selection is the largest gap. The UE decides which beams to use, subject to any necessary restriction, and that restriction is FFS. Power ramping across attempts is settled in shape rather than in detail. Two rules are supported. Under the first, any changed beam may cause Layer 1 to notify higher layers to suspend the power ramping counter. Under the second, all beams must change before it does.

On the PUSCH side the open items sit around the MCS field. Two FFS points travel with the indication agreement: the mechanism that guarantees configuration flexibility of the MCS index after RRCReconfiguration, and whether the number of MSB used for the indication is itself configurable. The default repetition values were open at RAN1#124bis and closed at RAN1#125, which is a useful reminder that these lists move.

Two smaller openings sit inside agreements that otherwise read as finished. The beam indication borrows bits from FDRA, and the interaction between those borrowed bits and the bits used for frequency hopping is marked FFS. On the pi/2-BPSK side, only one of the two candidate contents for assistance information was adopted. The UE reports the maximum spectral efficiency it prefers, and the alternative, reporting the power gain the UE can obtain, was not taken forward.

Dating any statement about this work item matters more than usual, because these lists moved quickly. The definition of the RO index was FFS at RAN1#124bis and settled at RAN1#125. The default repetition values followed the same path in the same two meetings. A summary written after RAN1#124bis and read after RAN1#125 would be wrong on both points, so the meeting is worth carrying alongside the agreement.

A third group of open points is not RAN1's to close. The signalling design for requesting repetition before RRCReconfiguration is up to RAN2, as is the fallback behaviour when a different-beam PRACH attempt fails. RAN1#125 endorsed an RRC parameter list for Rel-20 coverage in principle, which is the usual sign that a work item is moving from design into specification text.

• Beam restrictions are the biggest physical layer gap : the UE chooses its transmit beams, and the limits on that choice are still FFS.
• The MCS field split is not finished : configuration flexibility after RRCReconfiguration and the configurability of the MSB count both remain open.
• RAN2 holds several answers : the request signalling before RRCReconfiguration and the fallback after a failed attempt were both handed over.
• An endorsed parameter list is the transition marker : RAN1#125 endorsed the Rel-20 coverage RRC parameter list in principle.

Reference

Six of the ten documents listed below were read in full. Five are the ad-hoc chair session notes, which carry every agreement quoted on this page. The sixth is the RAN1#124bis final feature lead summary, which supplies the work item objectives and the working plan. The four remaining feature lead summaries were downloaded and consulted for specific points rather than read end to end.

WID RP-252824 is named in every session note as the document holding the detailed scope. It was not opened for this page, so the objectives quoted here are taken from the feature lead summary that reproduces them. The agenda item number changed during the work item: RAN1#122bis and RAN1#123 used 10.4.1, and RAN1#124 onward used 9.4.1.

References are listed in meeting order, earliest first, with the session notes first within each meeting.

• R1-2508158 (RAN1#122bis) : Session notes for 10.4 Coverage Enhancement Phase 3 (Ad-Hoc Chair, Huawei)
• R1-2508116 (RAN1#122bis) : FL Summary #3 of Coverage Enhancement for NR Phase 3 (Moderator, China Telecom)
• R1-2509451 (RAN1#123) : Session Notes of AI 10.4 (Ad-Hoc Chair, NTT DOCOMO)
• R1-2508612 (RAN1#123) : Final FL's summary on NR coverage enhancements Phase 3 (China Telecom)
• R1-2601508 (RAN1#124) : Session Notes of AI 9.4 (Ad-Hoc Chair, NTT DOCOMO)
• R1-2600688 (RAN1#124) : FL's summary #4 on NR coverage enhancements Phase 3 (Moderator, China Telecom)
• R1-2603276 (RAN1#124bis) : Session Notes of AI 9.4 (Ad-Hoc Chair, NTT DOCOMO)
• R1-2603420 (RAN1#124bis) : Final FL summary and working plan for NR coverage enhancements Phase 3 (China Telecom)
• R1-2605033 (RAN1#125) : Session Notes of AI 9.4 (Ad-Hoc Chair, NTT DOCOMO)
• R1-2604289 (RAN1#125) : FL's summary #4 on NR coverage enhancements Phase 3 (China Telecom)