5G/NR

 

 

 

FR2-2 : 52.6 GHz to 71 GHz

 

Release 15 defined FR2 as 24.25 GHz to 52.6 GHz. Release 17 extended NR above that, up to 71 GHz, and split the range into two. The old range became FR2-1, and the new range from 52.6 GHz to 71 GHz became FR2-2. The main target is the 60 GHz band, defined as NR band n263 (57 GHz to 71 GHz). In TS 38.101-2 that band is marked as unlicensed operation, subject to regional regulation.

FR2-2 is not just "FR2 at a higher frequency". It brought two new subcarrier spacings, 480 kHz and 960 kHz, and these are so short that several basic procedures had to change. The UE cannot monitor PDCCH in every slot, one DCI per slot is too much overhead, and the shared 60 GHz band needs channel access rules that work with narrow beams. This page goes through these changes in that order. The general numerology background is in the Numerology page.

Why a new frequency range ?

Why did 3GPP need a separate range above 52.6 GHz instead of simply extending FR2 ? The answer is that the radio conditions change enough to break some Release 15 assumptions. The most important one is phase noise. Oscillator phase noise grows with the carrier frequency. With 120 kHz SCS at 60 GHz, the phase noise causes inter-carrier interference that limits the usable modulation order. A wider subcarrier spacing makes each subcarrier more robust to phase noise.

The second reason is bandwidth. The 60 GHz band offers up to 14 GHz of spectrum, and the channels are expected to be very wide. NR keeps the limit of 275 PRBs per carrier. With 120 kHz SCS, 275 PRBs cover about 396 MHz. A 2 GHz channel is impossible with that SCS. With 960 kHz, 275 PRBs would cover about 3.2 GHz, so a 2 GHz channel fits in one carrier.

The third reason is regulation. In many regions the 60 GHz band is unlicensed and shared with other technologies such as WiGig (IEEE 802.11ad/ay). Some regions require sensing before transmission, and some do not. So NR needed a channel access scheme that the network can turn on or off per cell.

  • FR2 is now two ranges: FR2-1 is 24.25 to 52.6 GHz, FR2-2 is 52.6 to 71 GHz. Release 17 work items often call FR2-2 "NR beyond 52.6 GHz".
  • Band n263: 57000 MHz to 71000 MHz, TDD, unlicensed operation subject to regional regulation.
  • Three drivers: phase noise, very wide channels within the 275 PRB limit, and shared spectrum.

Numerology - 480 kHz and 960 kHz

Release 17 added two numerologies, μ=5 (480 kHz) and μ=6 (960 kHz). 120 kHz (μ=3) is also used in FR2-2. All three use normal CP only. In 38.300 clause 5.1, μ=5 and μ=6 are listed for both PSS/SSS/PBCH and other channels. Note that μ=4 (240 kHz) remains for SSB only, as in Release 15.

The table below shows what this means in time. The numbers are the standard scaling of NR, a slot is 14 symbols and the duration halves with each step of μ. What I want you to notice is the last two rows. A 960 kHz slot is 15.625 μs. In 1 ms there are 64 slots, so anything done per slot in Release 15 now happens 64 times per ms.

 

μ

SCS

Slot duration

Slots per 1 ms

Normal CP

275 PRBs span

n263 channel bandwidth

3

120 kHz

125 μs

8

about 0.59 μs

about 396 MHz

100, 400 MHz

5

480 kHz

31.25 μs

32

about 0.15 μs

about 1584 MHz

400, 800, 1600 MHz

6

960 kHz

15.625 μs

64

about 0.07 μs

about 3168 MHz

400, 800, 1600, 2000 MHz

 

  • Channel bandwidths: from TS 38.101-2 Table 5.3.5-1 for band n263. 480 kHz and 960 kHz SCS are optional for the UE, and so are all their channel bandwidths except 400 MHz.
  • The CP gets very short: about 73 ns at 960 kHz. This works only because narrow beams at 60 GHz reduce the delay spread. It also means that timing accuracy requirements become stricter.
  • Channel spacing: for n263 the nominal spacing between two adjacent carriers is a multiple of 50.4 MHz, which is different from the formula used in other FR2 bands.

In RRC, the two new values appear as extensions of the SCS enumeration. That is why a Release 17 log can show kHz480-v1700 or kHz960-v1700 where you would expect a simple value. The rest of the frame structure is described in the Frame Structure page.

Following is based on 38.331 v19.4.0 (Release 19)

SubcarrierSpacing ::=               ENUMERATED {kHz15, kHz30, kHz60, kHz120, kHz240, kHz480-v1700, kHz960-v1700, spare1}

Initial access in FR2-2

Which SCS does a UE use to find an FR2-2 cell for the first time ? The UE has to search SSBs before it knows anything about the cell, so the number of possible SSB numerologies should be small. Release 17 allows 120 kHz and 480 kHz SSB for initial access. A 960 kHz SSB exists, but TS 38.101-2 says it is not used for initial access. So a cell with 960 kHz data channels still uses a 120 kHz or 480 kHz SSB that idle UEs can find.

  • SSB patterns: 120 kHz uses Case D as in FR2-1. 480 kHz uses Case F and 960 kHz uses Case G (38.213 clause 4.1). Up to 64 SSB beams are supported, as in FR2-1.
  • GSCN for n263: TS 38.101-2 gives separate GSCN formulas for 120 kHz and 480 kHz SSB, so the UE searches a different raster depending on which SSB SCS it assumes.
  • PRACH: the L=139 sequence is supported with 120, 480 and 960 kHz. The longer L=571 sequence works with 120 and 480 kHz, and L=1151 with 120 kHz (38.300 clause 5.3). The longer sequences give a wider PRACH, which helps with the power spectral density limits of the band. Support is a UE capability (widebandPRACH-SCS-120kHz-r17 and widebandPRACH-SCS-480kHz-r17).
  • Msg1 and LBT: whether the UE senses the channel before Msg1 or MsgA is controlled by ra-ChannelAccess-r17, explained in Channel access - LBT and exemptions.

The SSB itself is described in the SS Block page, and the general RACH procedure in the RACH page.

Multi-slot PDCCH monitoring

Here is the first real problem of the short slot. In Release 15, a UE monitors PDCCH per slot, and the blind decoding limits are defined per slot. At 960 kHz, that would mean up to 64 monitoring opportunities in 1 ms. No UE can do blind decoding at that rate, and it would also waste power. So for 480 and 960 kHz, Release 17 defines PDCCH monitoring per group of slots instead of per slot.

The idea is described by a combination (X, Y). X is the number of slots in a slot group, and Y is the number of consecutive slots within the group where the UE may monitor PDCCH. The UE capability says which combinations it supports, and the blind decoding limit applies per group of X slots rather than per slot. 38.213 Table 10.1-2B gives the maximum number of PDCCH candidates per group.

 

SCS

(X, Y)

Max PDCCH candidates per group of X slots

480 kHz

(4, 1), (4, 2)

20

960 kHz

(4, 1), (4, 2)

10

960 kHz

(8, 1), (8, 4)

20

 

Compare this with 120 kHz in Release 15, where the limit is 20 candidates per slot (38.213 Table 10.1-2). At 960 kHz with (8, 4), the UE gets 20 candidates per 8 slots. So in time, the UE blind decodes at roughly the same rate as a 120 kHz UE, because 8 slots at 960 kHz are exactly one 120 kHz slot. The search space configuration points to the monitored slots with a bitmap, as in the listing below.

Following is based on 38.331 v19.4.0 (Release 19)

SearchSpaceExt-v1700 ::=            SEQUENCE {
    monitoringSlotPeriodicityAndOffset-v1710 CHOICE {
        sl32                                     INTEGER (0..31),
        sl64                                     INTEGER (0..63),
        sl128                                    INTEGER (0..127),
        sl5120                                   INTEGER (0..5119),
        sl10240                                  INTEGER (0..10239),
        sl20480                                  INTEGER (0..20479)
    }                                                                                                   OPTIONAL,   -- Cond Setup5
    monitoringSlotsWithinSlotGroup-r17       CHOICE {
        slotGroupLength4-r17                     BIT STRING (SIZE (4)),
        slotGroupLength8-r17                     BIT STRING (SIZE (8))
    }                                                                                                   OPTIONAL,   -- Need R
    duration-r17                             INTEGER (4..20476)                                         OPTIONAL,   -- Need R

    searchSpaceType-r17             SEQUENCE{
        common-r17                      SEQUENCE {
            dci-Format4-0-r17               SEQUENCE {
                ...
            }                                                                                           OPTIONAL,   -- Need R
            dci-Format4-1-r17               SEQUENCE {
                ...
            }                                                                                           OPTIONAL,   -- Need R
            dci-Format4-2-r17               SEQUENCE {
                ...
            }                                                                                           OPTIONAL,   -- Need R
            dci-Format4-1-AndFormat4-2-r17  SEQUENCE {
                ...
            }                                                                                           OPTIONAL,   -- Need R
            dci-Format2-7-r17               SEQUENCE {
                nrofCandidates-PEI-r17          SEQUENCE {
                    aggregationLevel4-r17       ENUMERATED {n0, n1, n2, n3, n4}                         OPTIONAL,   -- Need R
                    aggregationLevel8-r17       ENUMERATED {n0, n1, n2}                                 OPTIONAL,   -- Need R
                    aggregationLevel16-r17      ENUMERATED {n0, n1}                                     OPTIONAL    -- Need R
                },
                ...
            }                                                                                           OPTIONAL    -- Need R
        }
    }                                                                                                   OPTIONAL,   -- Need R
    searchSpaceGroupIdList-r17          SEQUENCE (SIZE (1.. 3)) OF INTEGER (0.. maxNrofSearchSpaceGroups-1-r17)  OPTIONAL,  -- Cond DedicatedOnly
    searchSpaceLinkingId-r17            INTEGER (0..maxNrofSearchSpacesLinks-1-r17)                     OPTIONAL    -- Cond DedicatedOnly
}
  • monitoringSlotsWithinSlotGroup-r17: a 4 or 8 bit bitmap, one bit per slot in the group. A bit set to 1 marks a slot configured for multi-slot PDCCH monitoring.
  • monitoringSlotPeriodicityAndOffset-v1710 / duration-r17: for 480 and 960 kHz, the periodicity, offset and duration are restricted to integer multiples of the slot group length L. The longer periods such as sl20480 are needed because the same time span now holds many more slots.
  • monitoringCapabilityConfig-v1710: in PDCCH-Config, set to r17monitoringcapability to select the Release 17 multi-slot monitoring capability for the serving cell.
  • The other fields: dci-Format4-x is for MBS and dci-Format2-7 for paging early indication. They share the same Release 17 extension but are not FR2-2 features.

Multi-PDSCH and multi-PUSCH scheduling

The second problem follows from the first. If the UE monitors PDCCH only once per slot group, how does the network schedule data in the other slots ? With one DCI per PDSCH, the slots without monitoring would stay empty. So Release 17 lets one DCI 1_1 schedule several PDSCHs, one per slot, in consecutive slots. The uplink already had this from Release 16 NR-U, where one DCI 0_1 can schedule several PUSCHs. FR2-2 reuses that.

The configuration is a special TDRA table. Each row of pdsch-TimeDomainAllocationListForMultiPDSCH-r17 is not one allocation but a list of up to 8 allocations. The TDRA field of the DCI selects a row, and that row says how many PDSCHs are scheduled and where each one is. Figure 1 shows the idea.

960 kHz, slot group of 8 slots (8 x 15.625 us = one 120 kHz slot) PDCCH : CORESET in the first 1 to 3 symbols of slot 0 PDSCH 1 PDSCH 2 PDSCH 3 PDSCH 4 slot 0 slot 1 slot 2 slot 3 slot 4 slot 5 slot 6 slot 7 time DCI 1_1 TDRA field = row k of pdsch-TimeDomainAllocationListForMultiPDSCH-r17 Row k = { SLIV for slot 0, SLIV for slot 1, SLIV for slot 2, SLIV for slot 3 } : up to 8 entries per row Each PDSCH has its own HARQ process and transport block. Up to 64 rows in the table (maxNrofDL-AllocationsExt-r17).

Figure 1. Multi-PDSCH scheduling. One DCI in the first symbols of the monitored slot schedules a PDSCH in each of several consecutive slots, so the slots without PDCCH monitoring still carry data. The CORESET keeps its Release 15 length of 1 to 3 symbols.

Following is based on 38.331 v19.4.0 (Release 19)

MultiPDSCH-TDRA-List-r17 ::= SEQUENCE (SIZE(1.. maxNrofDL-AllocationsExt-r17)) OF MultiPDSCH-TDRA-r17

MultiPDSCH-TDRA-r17 ::= SEQUENCE {
    pdsch-TDRA-List-r17                 SEQUENCE (SIZE(1..maxNrofMultiplePDSCHs-r17)) OF PDSCH-TimeDomainResourceAllocation-r16,
    ...
}
  • pdsch-TimeDomainAllocationListForMultiPDSCH-r17: in PDSCH-Config. Up to 64 rows (maxNrofDL-AllocationsExt-r17), and up to 8 PDSCHs per row (maxNrofMultiplePDSCHs-r17).
  • Each entry is a normal allocation: a PDSCH-TimeDomainResourceAllocation-r16 with its own k0, mapping type and SLIV. So each PDSCH can have a different symbol allocation.
  • Per-PDSCH HARQ: each scheduled PDSCH carries its own transport block and HARQ process. To keep the pipeline full with so many short slots, a UE can support 32 DL and 32 UL HARQ processes in FR2-2 (support32-DL-HARQ-ProcessPerSCS-r17).
  • No CBG with it: the network does not configure CBG based transmission when a DL BWP of the cell uses 480 or 960 kHz. The same applies in some HARQ-ACK codebook cases with multi-PDSCH (38.331 field description of codeBlockGroupTransmission).
  • Uplink: multi-PUSCH scheduling uses the Release 16 PUSCH TDRA list with up to 8 PUSCHs per row (maxNrofMultiplePUSCHs-r16).

Do not confuse this with the Release 18 multi-cell scheduling. Multi-PDSCH scheduling is one DCI for several slots on one cell. Multi-cell scheduling is one DCI for several cells, and it is described in the Multi-cell Scheduling page.

Channel access - LBT and exemptions

The 60 GHz band is shared spectrum, but the rules differ by region. Some regulators require a transmitter to sense the channel first, and others do not. NR therefore made channel access in FR2-2 something the network switches on per cell. When it is off, the UE transmits without any LBT, as in licensed FR2. When it is on, the UE follows TS 37.213 clause 4.4, which is a separate set of procedures from the FR1 NR-U rules.

The switch is channelAccessMode2-r17. It appears in ServingCellConfigCommon, in ServingCellConfigCommonSIB (so in SIB1) and in ServingCellConfig. The 38.331 field description is short: if present, the cell applies the channel access procedures of TS 37.213 clause 4.4, and if absent, it applies none. SIB3 and SIB4 carry the same flag for neighbour cells, so an idle UE knows whether a neighbour applies LBT.

  • Type 1: a random backoff with a fixed contention window. It is used to start a channel occupancy.
  • Type 2: a short deterministic sensing immediately before the transmission.
  • Type 3: transmission without sensing. Inside a channel occupancy initiated with Type 1, a following DL or UL transmission can use Type 3 regardless of the gap. Alternatively, the gNB can set a gap threshold, and above it the transmission uses Type 2 instead (37.213 clause 4.4.4).
  • Beam based sensing: the sensing beam must cover the transmission beams of the channel occupancy. A gNB or UE can sense with one beam covering all of them, or sense on each beam independently, with its own Type 1 counter per sensing beam (37.213 clause 4.4.6).
  • COT sharing: a channel occupancy initiated by the gNB can be used by the UE, and the gNB can share a UE-initiated occupancy. For configured grant PUSCH, the sharing information is carried in CG-UCI with cg-COT-SharingList-r17.
  • Energy detection threshold: in FR2-2 the maximum threshold is computed from the RF output power limit, the maximum EIRP of the intended transmission and the channel bandwidth (37.213 clause 4.4.7). The EIRP used to acquire the channel occupancy also caps the EIRP for the rest of that occupancy.

Then what are the exemptions ? Even where sensing is required, some regions allow short control signalling without sensing. 37.213 clause 4.4.5 uses this for two transmissions: the discovery burst from the gNB, which carries the SSB, and Msg1 of random access from the UE when ra-ChannelAccess-r17 is not configured. The total time of such transmissions over a channel is limited by a maximum ratio over a fixed interval. I could not read the exact values in the extracted 37.213 text, because the symbols were lost. My understanding is that they follow the regional short control signalling rule, which in Europe is 10% of any 100 ms period, but please check the clause before quoting the numbers.

Why exempt exactly these two ? Both are needed before any channel occupancy can exist. A UE that has not found the SSB cannot even start. A RACH attempt that fails LBT just adds delay to the access. If the gNB configures ra-ChannelAccess-r17, the UE senses before Msg1 or MsgA anyway. A UE indicates whether it can do Type 1 and Type 2 in the uplink with type1-ChannelAccess-FR2-2-r17 and type2-ChannelAccess-FR2-2-r17.

Other FR2-2 changes and UE capability

Besides the big items above, FR2-2 changed several smaller things that you will see in configurations and capabilities. Most of them follow the same logic: wider spectrum, shorter slots and stricter power limits. The best place to see the whole picture in one IE is the FR2-2 capability per band, shown in the listing below.

  • Multi-RB PUCCH: in FR2-2, PUCCH formats 0, 1 and 4 can use a configurable number of contiguous PRBs, up to 16 (38.300 clause 5.3). One PRB at high SCS is a very small part of the band, and spreading PUCCH over more PRBs helps with power spectral density limits.
  • Reduced beam switching time: with 15.6 μs slots, the beam switch time becomes a large part of a slot. A UE can report support for a reduced beam switching delay (reduced-BeamSwitchTiming-FR2-2-r17).
  • 64QAM for PUSCH: a separate capability, added to the same IE later (modulation64-QAM-PUSCH-FR2-2-r17).
  • UE assistance: the UE can report a preferred maximum bandwidth and number of MIMO layers for FR2-2 separately from FR2-1 (maxBW-PreferenceFR2-2, maxMIMO-LayerPreferenceFR2-2), also for overheating.

Following is based on 38.331 v19.4.0 (Release 19)

FR2-2-AccessParamsPerBand-r17 ::=       SEQUENCE {
    -- R1 24-1: Basic FR2-2 DL support
    dl-FR2-2-SCS-120kHz-r17                 ENUMERATED {supported}            OPTIONAL,
    -- R1 24-1a: Basic FR2-2 UL support
    ul-FR2-2-SCS-120kHz-r17                 ENUMERATED {supported}            OPTIONAL,
    -- R1 24-2: 120KHz SSB support for initial access in FR2-2
    initialAccessSSB-120kHz-r17             ENUMERATED {supported}            OPTIONAL,
    -- R1 24-1b: Wideband PRACH for 120 kHz in FR2-2
    widebandPRACH-SCS-120kHz-r17            ENUMERATED {supported}            OPTIONAL,
    -- R1 24-1c: Multi-RB support PUCCH format 0/1/4 for 120 kHz in FR2-2
    multiRB-PUCCH-SCS-120kHz-r17            ENUMERATED {supported}            OPTIONAL,
    -- R1 24-1d: Multiple PDSCH scheduling by single DCI for 120kHz in FR2-2
    multiPDSCH-SingleDCI-FR2-2-SCS-120kHz-r17 ENUMERATED {supported}          OPTIONAL,
    -- R1 24-1e: Multiple PUSCH scheduling by single DCI for 120kHz in FR2-2
    multiPUSCH-SingleDCI-FR2-2-SCS-120kHz-r17 ENUMERATED {supported}          OPTIONAL,
    -- R1 24-4: 480KHz SCS support for DL
    dl-FR2-2-SCS-480kHz-r17                 ENUMERATED {supported}            OPTIONAL,
    -- R1 24-4a: 480KHz SCS support for UL
    ul-FR2-2-SCS-480kHz-r17                 ENUMERATED {supported}            OPTIONAL,
    -- R1 24-3: 480KHz SSB support for initial access in FR2-2
    initialAccessSSB-480kHz-r17             ENUMERATED {supported}            OPTIONAL,
    -- R1 24-4b: Wideband PRACH for 480 kHz in FR2-2
    widebandPRACH-SCS-480kHz-r17            ENUMERATED {supported}            OPTIONAL,
    -- R1 24-4c: Multi-RB support PUCCH format 0/1/4 for 480 kHz in FR2-2
    multiRB-PUCCH-SCS-480kHz-r17            ENUMERATED {supported}            OPTIONAL,
    -- R1 24-4f: Enhanced PDCCH monitoring for 480KHz in FR2-2
    enhancedPDCCH-monitoringSCS-480kHz-r17  ENUMERATED {supported}            OPTIONAL,
    -- R1 24-5: 960KHz SCS support for DL
    dl-FR2-2-SCS-960kHz-r17                 ENUMERATED {supported}            OPTIONAL,
    -- R1 24-5a: 960KHz SCS support for UL
    ul-FR2-2-SCS-960kHz-r17                 ENUMERATED {supported}            OPTIONAL,
    -- R1 24-5c: Multi-RB support PUCCH format 0/1/4 for 960 kHz in FR2-2
    multiRB-PUCCH-SCS-960kHz-r17            ENUMERATED {supported}            OPTIONAL,
    -- R1 24-5f: Enhanced PDCCH monitoring for 960KHz in FR2-2
    enhancedPDCCH-monitoringSCS-960kHz-r17  SEQUENCE {
        pdcch-monitoring4-1-r17                 ENUMERATED {supported}        OPTIONAL,
        pdcch-monitoring4-2-r17                 ENUMERATED {supported}        OPTIONAL,
        pdcch-monitoring8-4-r17                 ENUMERATED {supported}        OPTIONAL
    }                                                                         OPTIONAL,
    -- R1 24-6: Type 1 channel access procedure in uplink for FR2-2 with shared spectrum channel access
    type1-ChannelAccess-FR2-2-r17           ENUMERATED {supported}            OPTIONAL,
    -- R1 24-7: Type 2 channel access procedure in uplink for FR2-2 with shared spectrum channel access
    type2-ChannelAccess-FR2-2-r17           ENUMERATED {supported}            OPTIONAL,
    -- R1 24-10: Reduced beam switching time delay
    reduced-BeamSwitchTiming-FR2-2-r17      ENUMERATED {supported}            OPTIONAL,
    -- R1 24-8: 32 DL HARQ processes for FR 2-2
    support32-DL-HARQ-ProcessPerSCS-r17     SEQUENCE {
        scs-120kHz-r17                          ENUMERATED {supported}        OPTIONAL,
        scs-480kHz-r17                          ENUMERATED {supported}        OPTIONAL,
        scs-960kHz-r17                          ENUMERATED {supported}        OPTIONAL
    }                                                                         OPTIONAL,
    -- R1 24-9: 32 UL HARQ processes for FR 2-2
    support32-UL-HARQ-ProcessPerSCS-r17SEQUENCE {
        scs-120kHz-r17                          ENUMERATED {supported}        OPTIONAL,
        scs-480kHz-r17                          ENUMERATED {supported}        OPTIONAL,
        scs-960kHz-r17                          ENUMERATED {supported}        OPTIONAL
    }                                                                         OPTIONAL,
    ...,
    [[
    -- R4 15-1: 64QAM for PUSCH for FR2-2
    modulation64-QAM-PUSCH-FR2-2-r17            ENUMERATED {supported}        OPTIONAL
    ]]
}
  • No 960 kHz initial access entry: there is initialAccessSSB-120kHz-r17 and initialAccessSSB-480kHz-r17, but nothing for 960 kHz. This matches the 38.101-2 note that a 960 kHz SSB is not used for initial access.
  • Multi-PDSCH and multi-PUSCH only at 120 kHz: the listing has explicit entries for 120 kHz. There is no separate entry for 480 and 960 kHz. The likely reason is that multi-slot monitoring makes the feature necessary at those SCS, so it comes with their basic support. 38.331 does not say this directly.
  • Enhanced PDCCH monitoring: one bit for 480 kHz, and a choice of (4, 1), (4, 2) and (8, 4) for 960 kHz, matching the combinations in the table above.
  • support32-UL-HARQ-ProcessPerSCS-r17SEQUENCE: the missing space between the name and SEQUENCE is in the 38.331 text itself. It is kept here as quoted.

The RF side of mmWave UEs, such as antenna modules and beam management, is described in the UE mmWave page. The bandwidth of each frequency range is in the FR and Bandwidth page.

Reference