A handheld UE talking to a satellite is short of energy at both ends of the link. The usual answer is repetition. Send the same thing several times, let the receiver combine the copies, and trade airtime for link budget. In connected mode this is not new. NR has had PDSCH and PUSCH aggregation since Release 15.

The hard part is initial access. Before RRC setup, the network knows nothing about the UE. There is no dedicated configuration, no UE capability and no CSI. Yet every message from SIB1 to the HARQ-ACK of Msg4 has to close the link. So 3GPP added repetition to the initial access messages one by one, over three releases. This page puts all of them in one place.

The detailed Msg4 PDSCH mechanism is in PDSCH/PUSCH Aggregation Factor. The link budget numbers behind all this are in Link Budget.

• Why Repetition Matters in NTN
• The Message by Message Map
• Before Random Access : SIB1 and Common PDCCH
• Msg1 : PRACH Repetition
• Msg2 : RAR and its PDCCH
• Msg3 : PUSCH Repetition
• Msg4 : PDSCH Repetition
• Msg4 HARQ-ACK : PUCCH Repetition
• How Support is Agreed Before UE Capability
• After RRC Setup : Connected Mode Repetition
• What to Check in a Trace
• References

Why Repetition Matters in NTN

Why do we need repetition at all ? A satellite is hundreds or thousands of km away. The UE is often a phone with a small antenna and a limited transmit power. So the received energy per symbol is low, and there are not many other ways to raise it.

The basic idea of repetition is simple. If the receiver combines N copies of the same transport block, it collects about N times the energy. In the ideal case, that is about 3 dB per doubling. The real gain is smaller, because the receiver has to estimate the channel in each copy, and the phase can change from one slot to the next. That is why DMRS bundling and inter-slot OCC appear later on this page. They try to keep the copies coherent enough to be combined well.

Repetition is not free. Every copy takes a slot that could carry other data, and the transport block arrives later. In connected mode, the network can decide this cost per UE, because it knows the UE capability and gets CSI. During initial access, it cannot. It has to pick the robustness before it knows who the UE is.

There is one more point. The random access procedure is a chain. If Msg3 gets through but Msg4 does not, the procedure still fails. So adding repetition to one message helps only until the next weakest message becomes the limit. This is why the feature grew message by message. Release 17 repeated Msg3. Release 18 repeated Msg1 and, for NTN, the PUCCH that carries the HARQ-ACK of Msg4. Release 19 filled the downlink side for NTN: Type0 PDCCH with SIB1, the other common PDCCH, and the Msg4 PDSCH.

• Repetition trades airtime for energy : Combining N copies gains up to about 10log10(N) dB, less in practice.
• Initial access is the hard case : The network has to choose the robustness before it has UE capability or CSI.
• The chain is only as strong as its weakest message : That is why each release covered a different message.

The Message by Message Map

Before going into each message, it helps to see all of them at once. Two questions matter for every row. Who turns the repetition on, and how does the other side find out ? Most of the cleverness in these features is in the answer to the second question.

The table lists each step of initial access with the release that added repetition to it. The last three columns answer the two questions above. Rel-17 and Rel-18 Msg1 and Msg3 repetition came from the general NR coverage enhancement work, so they are not NTN-only. The Msg4 PDSCH and Msg4 HARQ-ACK features are limited to NTN bands. The Type0 PDCCH repetition has both an NTN and a TN capability.

The sequence diagram below puts the same rows on one random access procedure. Each downlink message is drawn as two arrows, its PDCCH and its PDSCH, because the two are repeated by different features. A repeated step is drawn as a double arrow, and its colour shows the release that added the repetition. A single grey arrow has no repetition at all. The notes on the right show the signal that controls each step.

Figure 1. Almost every step of initial access now has a repetition option. The SIB19 PDSCH and the RAR PDSCH are the exceptions, even though their PDCCHs can be repeated. Each one is switched on by a bit or a resource that already existed before Msg4, because UE capability is not available yet.

• Downlink, before RACH : The PBCH bit and the linked search spaces are Rel-19. The UE needs no request for them. It only needs the capability to combine. The PDSCH follows the PDCCH only for SIB1. Other SI, such as SIB19, gets PDCCH repetition through Type0A CSS and no PDSCH repetition.
• Msg1 and Msg3 : The UE chooses a separate set of RA resources. The choice of preamble itself tells the gNB what the UE wants.
• Msg2 and Msg4 PDCCH : Both DCIs sit in Type1 CSS, so one linked pair protects them both.
• Msg4 and its HARQ-ACK : The UE asks in Msg3, through the LCID. The DCI that schedules Msg4 then sets both repetitions.

I did not find any repetition for the RAR PDSCH itself in the Release 19 specifications. Only the PDCCH that schedules it can be repeated, through the Type1 CSS. The Msg2 section has the details.

Before Random Access : SIB1 and Common PDCCH

The UE cannot even start random access until it has decoded SIB1. In a weak NTN cell, that can already be the first point of failure. Release 19 adds two things here. One is for Type0 PDCCH and SIB1. The other is for the remaining common search spaces.

Start with Type0 PDCCH. For SS/PBCH block and CORESET multiplexing pattern 1, the UE has always monitored the Type0-PDCCH CSS over two slots, n0 and n0+1. In earlier releases the two slots were just two chances. The DCI could be in either. From Release 19, in FR1, one PBCH payload bit changes this. If the bit is 1, the UE assumes that the same PDCCH candidate at the same aggregation level in both slots carries the same DCI format 1_0 with SI-RNTI. So the UE can combine the two copies.

The SIB1 PDSCH follows the PDCCH. A UE that supports it may assume that the PDSCH scheduled by that DCI is also repeated in the same two slots, with the same RV indicated by the DCI. So one bit gives the UE two copies of the PDCCH and two copies of SIB1.

Where does that bit come from ? It is not in the MIB. The MIB in 38.331 v19.4.0 is unchanged, with its one spare bit. The new bit is one of the PBCH payload bits that the physical layer adds next to the MIB, in 38.212 clause 7.1.1. As far as I can tell, that bit position was reserved before Release 19. I think this choice makes sense. A legacy UE ignores a reserved bit and keeps decoding one slot as before, so nothing breaks.

The other common search spaces use a different method. The field searchSpaceLinkingId-CE-r19 links two search space sets of the same CSS type, other than Type0 and Type3, on the same CORESET. The UE monitors the PDCCH candidates in both linked sets for a DCI with the same information. For intra-slot repetition, the second set starts right after the first one ends. This covers Type0A for other SI, Type1 for RAR and Msg4, and Type2 for paging.

< SearchSpaceExt-v1900 and the PDCCH-ConfigCommon list >

Following is based on 38.331 v19.4.0 (Release 19). Only the Release 19 parts are shown; the rest is elided with ....

SearchSpaceExt-v1900 ::=            SEQUENCE {
    searchSpaceLinkingId-CE-r19         INTEGER (0..maxNrofSearchSpacesLinks-1-r17)                     OPTIONAL    -- Need R
}

PDCCH-ConfigCommon ::=              SEQUENCE {
    ...
    [[
    commonSearchSpaceListExt-r19           SEQUENCE (SIZE(1..4)) OF SearchSpaceExt-v1800                  OPTIONAL,   -- Need R
    ...
    ]]
}

One thing confused me here. The new common list in PDCCH-ConfigCommon is a list of SearchSpaceExt-v1800, not SearchSpaceExt-v1900. SearchSpaceExt-v1800 does not carry searchSpaceLinkingId-CE-r19. The dedicated PDCCH-Config does carry a list of SearchSpaceExt-v1900. So in v19.4.0 I could not find how SIB1 links two common search spaces. My guess is that this is an editorial error that a later CR will fix, but I did not find the CR, so please treat it as open.

On the capability side, pdcch-RepetitionType0-r19 covers Type0 PDCCH and SIB1 PDSCH repetition in NTN bands. The companion capability pdcch-RepetitionTypeOthers-r19 covers Type 0A/0B/1/1A/2/2A CSS, and it is mandatory for a UE that supports the Type0 feature. Its value, 1 or 2, tells how the UE counts the two linked candidates for blind decoding. Both have TN versions, pdcch-RepetitionType0-TN-r19 and pdcch-RepetitionTypeOthersTN-r19, so this part is not NTN-only.

• Type0 and SIB1 are switched on by a PBCH bit : The MIB does not change, and a legacy UE does not notice.
• Other common search spaces are linked in pairs : searchSpaceLinkingId-CE-r19 gives PDCCH repetition for RAR, Msg4 and paging DCIs.
• The SIB1 path for linking is not clear yet : The Rel-19 common list points to the wrong extension type in v19.4.0.

Msg1 : PRACH Repetition

Msg1 is the first uplink message, and the UE sends it with no help from the network. So the UE itself has to decide whether to repeat the preamble. Release 18 lets it do that by measuring RSRP. This is part of the general NR coverage enhancement work, but it applies to NTN cells as well.

The network broadcasts up to three RSRP thresholds in BWP-UplinkCommon, one for each repetition number of 2, 4 and 8. The UE measures the RSRP of the downlink pathloss reference and compares it with the thresholds. A lower RSRP means more repetitions. If the RSRP is not below any configured threshold, the UE sends the preamble without repetition.

Then how does the gNB know how many repetitions are coming ? The repetitions do not use the normal RA resources. Each repetition number has its own set, defined by a FeatureCombinationPreambles with msg1-Repetitions set and msg1-RepetitionNum set to n2, n4 or n8. So the preamble that the gNB detects already tells it the repetition number.

At the physical layer, the UE sends the same preamble on a set of valid PRACH occasions. The occasions are consecutive in time, use the same frequency resource and are associated with the same SS/PBCH block. The UE uses the same spatial filter for all of them. If the attempts keep failing, preambleTransMax-Msg1-Repetition sets how many attempts the UE makes with one repetition number before it moves up to the next higher one.

< BWP-UplinkCommon and FeatureCombinationPreambles-r17 >

Following is based on 38.331 v19.4.0 (Release 19). Only the Msg1 repetition fields are shown; the rest is elided with ....

BWP-UplinkCommon ::=                SEQUENCE {
    ...
    [[
    ...
    rsrp-ThresholdMsg1-RepetitionNum2-r18    RSRP-Range                                                      OPTIONAL,  -- Need R
    rsrp-ThresholdMsg1-RepetitionNum4-r18    RSRP-Range                                                      OPTIONAL,  -- Need R
    rsrp-ThresholdMsg1-RepetitionNum8-r18    RSRP-Range                                                      OPTIONAL,  -- Need R
    preambleTransMax-Msg1-Repetition-r18     ENUMERATED {n1, n2, n4, n6, n8, n10, n20, n50, n100, n200}      OPTIONAL   -- Cond Msg1Rep1
    ]],
    ...
}

FeatureCombinationPreambles-r17 ::=   SEQUENCE {
    featureCombination-r17                FeatureCombination-r17,
    ...
    [[
    msg1-RepetitionNum-r18                ENUMERATED {n2, n4, n8, spare1}                                   OPTIONAL, -- Cond Msg1Rep2
    msg1-RepetitionTimeOffsetROGroup-r18  ENUMERATED {n4, n8, n16, spare1}                             OPTIONAL  -- Cond Msg1Rep3
    ]]
}

The UE capability is prach-CoverageEnh-r18, which means support for 2, 4 and 8 PRACH transmissions with the same Tx spatial filter. The second capability, prach-Repetition-r18, is an extra capability for the case where the gap between repetitions in two slots is shorter than a few symbols. Release 19 also added SBFD versions of the three thresholds, but those belong to subband full duplex, not to NTN.

Msg2 : RAR and its PDCCH

Msg2 sits between two uplink messages that can both be repeated, so it is natural to ask whether Msg2 can be repeated too. The answer is half yes. From Release 19, the PDCCH that schedules the RAR can be repeated. The RAR PDSCH itself has no repetition in any release up to Release 19.

Start with the PDCCH. The UE looks for DCI format 1_0 with RA-RNTI in the Type1-PDCCH CSS set, which ra-SearchSpace in PDCCH-ConfigCommon configures. Type1 CSS is one of the CSS types that searchSpaceLinkingId-CE-r19 can link. So the network can configure two linked Type1 search space sets on the same CORESET. The UE then monitors both for a DCI with the same information. For intra-slot repetition, the second monitoring occasion starts right after the first one ends.

One linked pair does more than protect Msg2. The same Type1 CSS also carries the DCI with TC-RNTI that schedules a Msg3 retransmission or Msg4. So the PDCCH repetition covers the Msg4 DCI as well, and that DCI is the one that turns on Msg4 PDSCH repetition and sets the Msg4 HARQ-ACK repetition. If that DCI is lost, neither repetition happens.

Here the open point from the SIB1 section matters directly. The field ra-SearchSpace points to a search space in the PDCCH-ConfigCommon of SIB1. In v19.4.0, the Rel-19 common list there carries SearchSpaceExt-v1800, which has no searchSpaceLinkingId-CE-r19. So I could not confirm from the ASN.1 how a cell broadcasts a linked Type1 pair for initial access. The capability side is clear. The capability pdcch-RepetitionTypeOthers-r19 covers Type 1 CSS, and its TN version covers terrestrial cells.

Then why is there no repetition for the RAR PDSCH ? I could not find a reason in the specifications. One RAR PDSCH can answer several preambles at once, so the gNB cannot shape it for one UE the way it does for Msg4. That may be part of the reason, but I have not seen it stated, so please take it as a guess.

What the gNB can do for the RAR PDSCH comes from Release 15. The DCI format 1_0 with RA-RNTI has a 2 bit TB scaling field. It scales Ninfo by 1, 0.5 or 0.25, as in 38.214 Table 5.1.3.2-2. With the same resources, a smaller transport block means a lower code rate. The RAR PDSCH is also limited to QPSK, because the UE is not expected to decode a PDSCH with RA-RNTI and Qm above 2. So the RAR already goes out in the most robust form that one slot allows.

Msg1 repetition changes two things for Msg2. First, the UE computes RA-RNTI from the last valid PRACH occasion in the set, not from the first one. Second, the RAR window starts after the last symbol of the last PRACH occasion of the transmission. In NTN, the window also starts after the additional offset for the UE-gNB round trip. So a UE that sent eight repetitions starts listening later than a UE that sent one.

• The Msg2 PDCCH can be repeated : Two Type1 CSS sets linked by searchSpaceLinkingId-CE-r19 carry the same DCI with RA-RNTI.
• The same pair protects the Msg4 DCI : Type1 CSS also carries the DCI with TC-RNTI.
• The RAR PDSCH is not repeated : TB scaling and QPSK are the only robustness tools for it.
• Msg1 repetition moves Msg2 : RA-RNTI and the RAR window both follow the last PRACH occasion.

Msg3 : PUSCH Repetition

Msg3 was the first initial access message to get repetition, in Release 17. It is an uplink message, so it is usually the weakest one for a handheld UE. Its design also set the pattern that Msg1 followed later: the UE selects special RA resources, and the gNB finds out from the preamble.

The UE decides first. If the BWP has RA resources both with and without msg3-Repetitions, and the RSRP is below rsrp-ThresholdMsg3-r17, the UE considers Msg3 repetition applicable. Then it selects a preamble from the resources marked with msg3-Repetitions. The gNB sees that preamble and knows that this UE wants a repeated Msg3.

The gNB then decides how many repetitions. It sends the count in the RAR UL grant, without adding a field. The 4 bit MCS field of the grant is split in two. The 2 MSBs select one of four repetition counts from numberOfMsg3-RepetitionsList-r17. The 2 LSBs select one of the first four MCS values in mcs-Msg3-Repetitions-r17. If numberOfMsg3-RepetitionsList-r17 is absent, the four counts are 1, 2, 3 and 4. A Msg3 retransmission scheduled by DCI format 0_0 with TC-RNTI works the same way, except that its 3 LSBs select from all eight MCS values.

So the price of Msg3 repetition is MCS flexibility. With the RAR grant, a repeated Msg3 can use only four MCS values, and the network chose them in advance in SIB1. The table for this split is 38.214 Table 6.1.2.1-1A, shown in PUSCH AggregationFactor.

< BWP-UplinkCommon, Msg3 repetition fields >

Following is based on 38.331 v19.4.0 (Release 19). Only the Msg3 repetition fields are shown; the rest is elided with ....

BWP-UplinkCommon ::=                SEQUENCE {
    ...
    [[
    ...
    rsrp-ThresholdMsg3-r17              RSRP-Range                                                   OPTIONAL, -- Need R
    numberOfMsg3-RepetitionsList-r17    SEQUENCE (SIZE (4)) OF NumberOfMsg3-Repetitions-r17                  OPTIONAL,  -- Cond Msg3Rep
    mcs-Msg3-Repetitions-r17            SEQUENCE (SIZE (8)) OF INTEGER (0..31)                               OPTIONAL   -- Cond Msg3Rep
    ]],
    ...
}

NumberOfMsg3-Repetitions-r17::=         ENUMERATED {n1, n2, n3, n4, n7, n8, n12, n16}

The UE capability is pusch-RepetitionMsg3-r17. One more connection is worth noticing. The Msg3 PUSCH also carries the LCID that asks for Msg4 repetition, as the next two sections show. So in a weak cell, the request for a robust Msg4 itself travels on a repeated Msg3.

Msg4 : PDSCH Repetition

Msg4 carries the UE contention resolution identity and RRCSetup. It is a PDSCH sent before the UE has a dedicated PDSCH-Config, so the ordinary pdsch-AggregationFactor cannot apply to it. Release 19 adds a separate factor for NTN.

This page gives the summary only, because the full mechanism is in Msg4 Aggregation Factor in Release 19. There are three steps. SIB1 broadcasts pdsch-AggregationFactor-r19, n2 or n4, in PDSCH-ConfigCommon. The UE indicates support through the LCID of its Msg3 CCCH. Then the DCI format 1_0 with TC-RNTI turns the repetition on for this one Msg4, by setting the MSB of the MCS field to 1 with IMCS below 29. The UE reads the MSB as 0, so a repeated Msg4 is limited to MCS 0 to 12.

The repeated PDSCH uses the same symbol allocation in every slot and a single transmission layer. The RV of each occasion follows 38.214 Table 5.1.2.1-2, the same table as the ordinary aggregation factor. The UE capability is pdsch-RepetitionMsg4-r19, which applies only to the NTN bands of 38.101-5 Table 5.2.2-1. A UE that reports it also has to report pdsch-RepetitionMultiSlots.

Notice how this compares with Msg3. For Msg3, the gNB learns the request from the preamble and sets the count in the RAR grant. For Msg4, the gNB learns the request from the LCID and only switches the repetition on in the DCI. The count itself is fixed by SIB1 for the whole cell. So the gNB can choose per UE whether to repeat Msg4, but not how many times.

• One factor for the whole cell : pdsch-AggregationFactor-r19 in SIB1 gives n2 or n4.
• On or off per UE : The MSB of the MCS field in the Msg4 DCI decides it.
• NTN only : There is no TN version of pdsch-RepetitionMsg4-r19.

Msg4 HARQ-ACK : PUCCH Repetition

Suppose Msg4 is decoded. The UE still has to send the HARQ-ACK on a PUCCH, and that is an uplink transmission on a common PUCCH resource. If it is lost, the gNB does not know that contention resolution succeeded. Release 18 added PUCCH repetition for this HARQ-ACK, for NTN.

The configuration is in SIB19, the NTN SIB, in ntn-CovEnh-r18. The field numberOfMsg4HARQ-ACK-Repetitions-r18 is a 4 bit bitmap. From left to right, the bits stand for repetition factors 1, 2, 4 and 8. The network sets the factors it allows. If factor 1 is set, at least one other factor must be set too. The threshold rsrp-ThresholdMsg4HARQ-ACK-r18 is optional.

The UE request again uses the Msg3 LCID. A capable UE uses the LCID codepoints for PUCCH repetition of Msg4 HARQ-ACK in two cases. One is when the bitmap is configured with no threshold. The other is when both are configured and the RSRP is below the threshold. The extended LCID table, 38.321 Table 6.2.1-2c, has separate codepoints for RedCap, eRedCap and other UEs. It also has combined codepoints that ask for this and Msg4 PDSCH repetition at the same time.

Then the gNB picks the factor in the Msg4 DCI. If more than one factor is configured, the DAI field of DCI format 1_0 with TC-RNTI selects one of them, as in 38.212 Table 7.3.1.2.1-4. My understanding is that DAI is free here, because there is only one HARQ-ACK bit to report for Msg4 and nothing to count. The UE keeps repeating PUCCH with that factor until it gets a dedicated PUCCH resource configuration.

< SIB19-r17 and NTN-CovEnh-r18 >

Following is based on 38.331 v19.4.0 (Release 19). Only the coverage enhancement field of SIB19 is shown; the rest is elided with ....

SIB19-r17 ::= SEQUENCE {
    ...
    [[
    movingReferenceLocation-r18              ReferenceLocation-r17                           OPTIONAL,       -- Need R
    ntn-CovEnh-r18                           NTN-CovEnh-r18                                  OPTIONAL,       -- Need R
    satSwitchWithReSync-r18                  SatSwitchWithReSync-r18                         OPTIONAL        -- Need R
    ]],
    ...
}

NTN-CovEnh-r18 ::=                       SEQUENCE {
    numberOfMsg4HARQ-ACK-Repetitions-r18     BIT STRING (SIZE(4)),
    rsrp-ThresholdMsg4HARQ-ACK-r18           RSRP-Range                                      OPTIONAL        -- Need R
}

One detail surprised me. This feature has no capability field in UE-NR-Capability. 38.306 lists it in clause 5.4, other features, and says that a UE using one of those LCID codepoints must support it. So the LCID is the only capability report. The feature applies to the NTN bands of 38.101-5 Tables 5.2.2-1 and 5.2.3-1, and to HAPS bands.

How Support is Agreed Before UE Capability

Look at the earlier sections again, and you would notice a pattern. None of these features adds a new message, and none adds a new field to a DCI or to the RAR grant. Each one borrows something that already exists. This section collects those borrowed signals in one place, because they are what you look for in a log.

Why such a careful reuse ? DCI format 1_0 and the RAR grant are read by every UE in the cell, including legacy UEs. Changing their size would break those UEs. A reserved bit or a reinterpreted field does not. The new meaning applies only when both sides have already agreed to it, through SIB1 on one side and the preamble or LCID on the other.

There is also an order to it. Each indication arrives just in time for the message that uses it. The PBCH bit comes before SIB1. The preamble choice comes before the RAR. The Msg3 LCID comes before the Msg4 DCI. UE capability arrives only after RRC setup, which is too late for all of them.

• No new DCI or RAR fields : Every indication reuses a reserved bit, a resource partition, an LCID or an existing field.
• The price is usually MCS range : Msg3 and Msg4 both give up part of the MCS field.
• UE capability is not the source : It arrives after all the messages that need it.

After RRC Setup : Connected Mode Repetition

Once RRC setup is done, the problem becomes easier. The gNB has the UE capability, can configure dedicated parameters and gets CSI. So connected mode repetition is mostly a matter of RRC configuration, and most of it is not NTN-specific. The NTN-specific parts are about keeping the copies coherent while the satellite moves.

The last two rows are the NTN part. DMRS bundling lets the gNB estimate the channel over several slots together, but that only works if the UE keeps phase continuity and power consistency. In an NGSO scenario, the timing drifts quickly. The capability ntn-DMRS-BundlingNGSO-r18 is the capability for DMRS bundling in that case, with pre-compensation that keeps the phase rotation from timing drift within the limit. Its value, n4 to n32, is the longest duration over which the UE can keep this.

Inter-slot OCC is the Rel-19 addition. It applies an orthogonal cover code across the slots of a PUSCH repetition, with length 2 or 4. The idea is that several UEs can share the same repeated PUSCH resource and the gNB separates them by the code. So it is more about the capacity cost of repetition than about extra link budget. The capability pusch-InterSlotOCC-r19 also covers RV cycling across OCC groups and phase continuity within one OCC group, and it reports GSO, NGSO or both.

For the ASN.1 of the PDSCH and PUSCH parts, see PDSCH/PUSCH Aggregation Factor : RRC Parameters.

What to Check in a Trace

A log of NTN initial access with repetition can look confusing, because most of the signals are reused bits. The same MCS value means different things depending on what happened earlier in the procedure. So read it in order, and confirm each agreement before you interpret the field that depends on it.

The most common mistake is to read the Msg4 MCS field as an ordinary MCS. If the UE asked for Msg4 PDSCH repetition and the MSB is 1, an IMCS of 20 does not mean MCS 20. It means MCS 4 with repetition. The same care applies to the RAR grant of a Msg3 repetition preamble, where the 4 bit field is not an MCS index at all.

For the timing of these messages over the satellite link, continue with RACH and Scheduling & Timing.

References

The explanations use these Release 19 versions. The repetition counts in Figure 1 are the allowed values, not values from a real cell.

• 3GPP TS 38.212 V19.4.0 : NR; Multiplexing and channel coding; clause 7.1.1 PBCH payload and Table 7.3.1.2.1-4.
• 3GPP TS 38.213 V19.5.0 : NR; Physical layer procedures for control; clauses 8.1, 8.2, 8.3, 8.4, 9.2.6, 10.1 and 13.
• 3GPP TS 38.214 V19.5.0 : NR; Physical layer procedures for data; clauses 5.1.2.1, 5.1.3.1, 5.1.3.2 and 6.1.2.1.
• 3GPP TS 38.306 V19.4.0 : NR; User Equipment (UE) radio access capabilities; clauses 4.2 and 5.4.
• 3GPP TS 38.321 V19.4.0 : NR; Medium Access Control (MAC) protocol specification; clauses 5.1.1b, 5.1.3 and 6.2.1.
• 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC); Protocol specification.

Related pages on this site :

• PDSCH/PUSCH Aggregation Factor / Repetition : the full Msg4 PDSCH mechanism and the connected mode ASN.1.
• Link Budget : why a handheld UE needs this energy in the first place.
• RACH : the timing side of NTN random access.
• RRC (NR) : SIB19 and the NTN capability fields.