Configured Scheduling

Configured Scheduling is a mechanism in which gNB can schedule PDSCH/PUSCH without using DCI for every transmission. I think this is equivalent to SPS in LTE. How gNB can schedule those physical channels without using DCI ? Simple, it configures all the detailed scheduling parameters in RRC and gNB / UE is supposed to transmit PDSCH and PUSCH according to the parameters specified in RRC. This would greatly help gNB reduce the load of PHY/MAC scheduling.

One possible drawback of this mechanism would be that gNB cannot change scheduling parameter for individual transmission, implying that there may be some issues for Radio Link Adaptation when the channel condition goes very bad.

Configured Scheduling mechanism for downlink is called SPS and Configured Scheduling mechanism for UL is called Configured Grant.

It is worth being explicit about what that saving buys, because it is not really about the bits. A DCI is small. What costs you is the sequence :

   dynamic scheduling, uplink              configured grant, uplink

     data arrives in the UE buffer               data arrives in the UE buffer
              |                                            |
     send a Scheduling Request                             |
              |                                    the grant is already there
     wait for the grant                                     |
              |                                            v
     receive DCI with the grant                     transmit immediately
              |
              v
        transmit

Every arrow in the left hand column is a round trip that has to happen before the first bit moves. Configured scheduling deletes all of them. That is why it turns up wherever latency is the requirement rather than throughput - URLLC, industrial control, and voice.

The second saving is PDCCH capacity. A cell with a thousand VoIP users sending a packet every 20 ms would need fifty thousand DCIs per second just to schedule them. With configured grants it needs none, and the control channel is freed for the traffic that genuinely needs dynamic adaptation.

And your caveat is the exact price paid. A dynamic grant is chosen with the channel measurement of the moment ; a configured grant was chosen once, in advance. So the MCS cannot follow the channel, and the network has to pick a conservative one that will still work when conditions are poor. You are trading spectral efficiency for latency and overhead - which is a good trade for a 20 ms voice packet and a bad one for a file download.

	Dynamic scheduling	Configured scheduling
DCI per transmission	one every time	none once running
Uplink latency	SR, grant, then transmit	transmit at the next occasion
Link adaptation	per transmission	fixed until reconfigured
Suits	Bursty, large, variable traffic	Small, periodic, predictable traffic

Configure CS for Downlink / SPS

In the downlink, configured scheduling means that the network commits in advance to transmitting on a repeating pattern of resources, and then simply keeps to it. Instead of announcing every PDSCH with its own DCI, the gNB describes the pattern once in an RRC message - how often it repeats, how large it is, which modulation and coding scheme it uses - and from then on the UE knows where to look without being told each time. The scheduling decision is made once and reused, rather than made afresh every few hundred microseconds.

The reason this is worth doing in the downlink is that a great deal of traffic is far more predictable than the scheduler's per-transmission machinery assumes. A voice codec is the classic case : it produces a packet of almost the same size every twenty milliseconds, for as long as the call lasts. Announcing each of those with an individual DCI is pure repetition - the same grant, over and over, describing something the network already knew it was going to send. Configured scheduling lets the gNB say it once. The saving is not in the bits of the DCI itself, which are few, but in the PDCCH capacity those DCIs would have occupied, and in the blind decoding the UE would have had to perform to find them.

The name is worth taking literally, because it tells you the shape of the mechanism. Semi-Persistent Scheduling is persistent in that the allocation survives from one period to the next without further signalling, but only semi so : it has to be switched on before it does anything, it can be switched off again, and any individual occasion can be overridden by an ordinary dynamic grant. It is a standing arrangement rather than a permanent one, and the diagram below is essentially a picture of that arrangement being set up, running, and then being interrupted.

Reading it from the top, there are three distinct phases to watch for. First the RRC message arrives and the pattern is configured - note that nothing is transmitted on it yet, and the UE simply carries on monitoring PDCCH as usual. Then a DCI arrives that activates it, and the first PDSCH follows. From that point the mechanism is in its steady state, and this is the part that repays attention : the PDSCHs keep arriving on their period with nothing announcing them at all. The last few exchanges in the diagram then show what happens when the network wants to depart from the pattern for one transmission.

The overall procedure for Configured Scheduling for downlink (SPS) can be illustrated as below.

It can be summarized

i) gNB send RRC (RRCSetup or RRCReconfiguration) configuring all the parameters necessary for PDSCH scheduling

ii) UE Monitor PDCCH

iii) When gNB want to start PDSCH transmission, it sends DCI with CS-RNTI and start PDSCH transmission.

Three things in that diagram are worth naming, because they are what the whole mechanism turns on.

1. The "No PDCCH" labels are the point. The first PDSCH is announced by a DCI ; the ones after it are not. The UE knows they are coming because RRC told it the periodicity, so it simply reads the same resources again each period. Everything the feature saves is contained in those two words.

2. Two different RNTIs are doing two different jobs. This is the part that catches people out :

RNTI on the DCI	What it means	Effect
CS-RNTI	Activation or deactivation of the configured schedule	Starts the repeating pattern - or stops it. It does not schedule one transmission, it switches the whole arrangement on and off
C-RNTI	An ordinary dynamic grant	Applies to that occasion only. The configured schedule is untouched and carries on afterwards

That is what the "If received, Overwrite CS" cloud at the bottom of the diagram is saying. A dynamic grant always wins for the occasion it lands on, and the configured pattern resumes at the next period. It is an override, not a cancellation - and it is how the network handles the case where the configured MCS is wrong for one particular moment.

3. There is only one flavour of downlink SPS. Compare this diagram with the uplink one further down and you can see it : downlink SPS always needs an activating DCI with CS-RNTI. There is no downlink equivalent of uplink Type 1. The reason is straightforward - in the downlink it is the network that transmits, so it can simply choose when to start, and an RRC-only arrangement would buy nothing. In the uplink it is the UE that transmits, and there the difference between "start now" and "wait to be told" is a real one.

Configure CS for Uplink

The uplink case looks similar to the downlink one at first glance, but the problem it solves is not the same, and it is worth being clear about the difference before reading the diagram. In the downlink the transmitter is the network, which already knows what it intends to send and when, so configured scheduling there is mostly about not having to repeat itself - it saves PDCCH capacity. In the uplink the transmitter is the UE, and the network has no way of knowing when the UE will have something to send. That changes the nature of the saving completely.

Without a configured grant, a UE with data waiting cannot simply transmit. It has to raise a Scheduling Request, wait for the network to notice and respond, receive a grant in a DCI, and only then send. Each of those steps is a round trip across the air interface, and all of them happen before the first bit of the actual data moves. A configured grant removes the entire exchange : the resources are already allocated, recurring on a known period, so the UE transmits at the next occasion. In the downlink configured scheduling is an efficiency measure ; in the uplink it is primarily a latency measure, and that is why it is the mechanism behind most of the low latency claims made for 5G.

The reason there are two types comes down to a single question - at what moment does the grant become usable? In one arrangement the RRC message contains everything, including the actual time and frequency resources, so the grant exists the instant the UE has applied the configuration and nothing further is needed. In the other, the RRC message sets up all the surrounding parameters but deliberately leaves out the resources themselves ; the grant lies dormant until a DCI arrives to activate it and supply them. The first starts as fast as it is possible to start. The second costs one extra step at the beginning, and buys something useful in exchange - the network can switch it off, switch it back on, or re-point it at different resources using nothing but DCIs, where the first type would need a full RRC reconfiguration to change anything at all.

The illustration below shows both, side by side, and the most useful way to read it is to look for what is different rather than what is present. The two halves are very nearly the same picture. They begin the same way, they end the same way, and the steady state in the middle is identical. Essentially one arrow near the top of the right hand side is the whole distinction between them.

The overall procedure for Configured Scheduling for uplink (Configured Grant) can be illustrated as below. For UL there are two different types of mechanism called Type 1 and Type 2.

In Type 1,

i) gNB send RRC (RRCSetup or RRCReconfiguration) configuring all the parameters necessary for PUSCH scheduling

ii) As soon as UE processed the RRC, UE is expected to transmit PUSCH without any specific lower layer trigger (i.e, DCI Trigger).

NOTE : Even in this situation, UE is supposed to monitor PDCCH just in case gNB transmit other type of DCI.

In Type 2,

i) gNB send RRC (RRCSetup or RRCReconfiguration) configuring all the parameters necessary for PUSCH scheduling

ii) When gNB want to start granting(scheduling) PUSCH, it sends DCI masked with CS-RNTI.

iii) Once UE processed the DCI with CS-RNTI, it is supposed to transmit PUSCH as scheduled in RRC

NOTE : Even in this situation, UE is supposed to monitor PDCCH just in case gNB transmit other type of DCI.

Put the two halves of that picture side by side and the difference is one arrow :

	Type 1	Type 2
Activation	none - RRC is enough	DCI with CS-RNTI
Grant parameters	all in RRC, in rrc-ConfiguredUplinkGrant	in the activating DCI
UE starts transmitting	as soon as the RRC is applied	only after the DCI arrives
Network can retune it	only by a new RRC message	by sending another activating DCI
Suits	A grant that should exist permanently, with the shortest possible start-up	A grant the network wants to switch on and off, or re-point, cheaply

The last row is the practical reason both exist. Changing anything about a Type 1 grant means an RRC reconfiguration - slow, and it interrupts the UE. A Type 2 grant can be deactivated and reactivated with different parameters using nothing but DCIs, which costs almost nothing. Type 1 buys the fastest possible start ; Type 2 buys flexibility afterwards.

NOTE : your NOTE about the UE still monitoring PDCCH is worth underlining, because it is easy to assume configured scheduling means the UE can stop listening. It cannot, and the diagrams show why - both halves end with a DCI(PDCCH)/C-RNTI arriving to override the configured grant. A UE that stopped monitoring would miss it. Configured scheduling removes the need for a DCI before every transmission ; it does not remove the possibility of one.

RRC Parameters

The ASN.1 below is taken from 3GPP TS 38.331 V19.2.0 (Release 19). Field names carry their release suffix, and they are colour coded here so you can see at a glance when each one arrived :

   no suffix   Release 15, the original definition
   -r16 / -v16xx   Release 16
   -r17 / -v17xx   Release 17
   -r18 / -v18xx   Release 18
   -r19 / -v19xx   Release 19

Reading the colours down the page is itself informative. The Release 15 core is short - periodicity, a few power control fields, one HARQ process count. Almost everything else has been bolted on since, and the additions cluster around three themes : unlicensed operation (the COT sharing fields in Rel-16), more repetitions and more HARQ processes for reliability and higher bands in Rel-17, and mobility and SDT in Rel-18.

The ASN.1 answers the Type 1 / Type 2 question

Before reading the whole thing, there is one field worth finding, because it settles the distinction you drew in the section above :

   rrc-ConfiguredUplinkGrant   SEQUENCE {  ...  }   OPTIONAL

        present  ->  every grant parameter is already in RRC
                       nothing else is needed  ->  this is Type 1

        absent   ->  the grant parameters will arrive in a DCI
                       scrambled with CS-RNTI  ->  this is Type 2

So Type 1 and Type 2 are not two different IEs or a mode flag - they are one IE with an optional sub-structure, and its presence or absence is the whole difference. If you are reading a configuration from a log and want to know which type you are looking at, that is the field to check first.

It also explains the timing difference in your two diagrams. In Type 1 the UE can start transmitting as soon as it has applied the RRC message, because the grant is in the RRC message. In Type 2 the RRC message describes everything except the actual resources, so nothing can happen until the activating DCI arrives.

ConfiguredGrantConfig ::=           SEQUENCE {
    frequencyHopping ENUMERATED {intraSlot, interSlot}                 OPTIONAL, -- Need S
    cg-DMRS-Configuration               DMRS-UplinkConfig,
    mcs-Table ENUMERATED {qam256, qam64LowSE}                          OPTIONAL, -- Need S
    mcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE}         OPTIONAL, -- Need S
    uci-OnPUSCH SetupRelease { CG-UCI-OnPUSCH }                        OPTIONAL, -- Need M
  resourceAllocation  ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch },
    rbg-Size ENUMERATED {config2}                                      OPTIONAL, -- Need S
    powerControlLoopToUse               ENUMERATED {n0, n1},
    p0-PUSCH-Alpha                      P0-PUSCH-AlphaSetId,
    transformPrecoder ENUMERATED {enabled, disabled}                   OPTIONAL, -- Need S
    nrofHARQ-Processes                  INTEGER(1..16),
    repK                                ENUMERATED {n1, n2, n4, n8},
    repK-RV ENUMERATED {s1-0231, s2-0303, s3-0000}                     OPTIONAL, -- Need R
    periodicity                         ENUMERATED {
                                    sym2, sym7, sym1x14, sym2x14, sym4x14, sym5x14, sym8x14, sym10x14,
                                    sym16x14, sym20x14,


                                    sym32x14, sym40x14, sym64x14, sym80x14, sym128x14, sym160x14, sym256x14,
                                    sym320x14, sym512x14,
                                    sym640x14, sym1024x14, sym1280x14, sym2560x14, sym5120x14,
                                    sym6, sym1x12, sym2x12, sym4x12, sym5x12, sym8x12, sym10x12, sym16x12,
                                    sym20x12, sym32x12,
                                    sym40x12, sym64x12, sym80x12, sym128x12, sym160x12, sym256x12,
                                    sym320x12, sym512x12, sym640x12,
                                                sym1280x12, sym2560x12
    },
    configuredGrantTimer INTEGER (1..64)                               OPTIONAL, -- Need R
    rrc-ConfiguredUplinkGrant           SEQUENCE {
        timeDomainOffset                    INTEGER (0..5119),
        timeDomainAllocation                INTEGER (0..15),
        frequencyDomainAllocation           BIT STRING (SIZE(18)),
        antennaPort                         INTEGER (0..31),
        dmrs-SeqInitialization INTEGER (0..1)                          OPTIONAL, -- Need R
        precodingAndNumberOfLayers          INTEGER (0..63),
        srs-ResourceIndicator INTEGER (0..15)                          OPTIONAL, -- Need R
        mcsAndTBS                           INTEGER (0..31),
        frequencyHoppingOffset INTEGER (1.. maxNrofPhysicalResourceBlocks-1)  OPTIONAL, -- Need R
        pathlossReferenceIndex              INTEGER (0..maxNrofPUSCH-PathlossReferenceRSs-1),
        ...,
        [[
        pusch-RepTypeIndicator-r16 ENUMERATED {pusch-RepTypeA,pusch-RepTypeB}  OPTIONAL, -- Need M
        frequencyHoppingPUSCH-RepTypeB-r16 ENUMERATED {interRepetition, interSlot}  OPTIONAL, -- Cond RepTypeB
        timeReferenceSFN-r16 ENUMERATED {sfn512}                       OPTIONAL -- Need S
        ]],
        [[
        pathlossReferenceIndex2-r17 INTEGER (0..maxNrofPUSCH-PathlossReferenceRSs-1)  OPTIONAL, -- Need R
        srs-ResourceIndicator2-r17 INTEGER (0..15)                     OPTIONAL, -- Need R
        precodingAndNumberOfLayers2-r17 INTEGER (0..63)                OPTIONAL, -- Need R
        timeDomainAllocation-v1710 INTEGER (16..63)                    OPTIONAL, -- Need M
        timeDomainOffset-r17 INTEGER (0..40959)                        OPTIONAL, -- Need R
        cg-SDT-Configuration-r17 CG-SDT-Configuration-r17              OPTIONAL -- Need M
        ]],
        [[
        srs-ResourceSetId-r18 SRS-ResourceSetId                        OPTIONAL, -- Need R
        cg-LTM-Configuration-r18 CG-RRC-Configuration-r18              OPTIONAL, -- Cond LTM
        cg-SDT-PeriodicityExt-r18          ENUMERATED {
                                    sym1x14x1280, sym2x14x1280, sym4x14x1280 , sym8x14x1280, sym16x14x1280,
                                    sym32x14x1280, sym48x14x1280, sym64x14x1280, sym96x14x1280,
                                    sym128x14x1280,
                                    sym192x14x1280, sym240x14x1280, sym256x14x1280, sym384x14x1280,
                                    sym472x14x1280,
                                    sym480x14x1280, sym512x14x1280, sym768x14x1280, sym944x14x1280,
                                    sym960x14x1280,
                                    sym1408x14x1280, sym1536x14x1280, sym1888x14x1280, sym1920x14x1280,
                                    sym2816x14x1280, sym3072x14x1280, sym3776x14x1280, sym5632x14x1280,
                                    sym6144x14x1280, sym7552x14x1280, sym7680x14x1280, sym11264x14x1280,
                                    sym15104x14x1280, sym15360x14x1280, sym22528x14x1280, sym30208x14x1280,
                                    sym45056x14x1280, sym60416x14x1280, sym90112x14x1280, sym180224x14x1280,
                                    sym4x12x1280, sym8x12x1280, sym16x12x1280, sym32x12x1280,
                                    sym192x12x1280,
                                    sym384x12x1280, sym960x12x1280, sym1888x12x1280, sym3776x12x1280,
                                    sym5632x12x1280, sym11264x12x1280, spare13, spare12, spare11, spare10,
                                    spare9,
                                    spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1
                                            }                          OPTIONAL, -- Cond CG-SDT1
        timeReferenceHyperSFN-r18 INTEGER (0..1023)                    OPTIONAL, -- Cond CG-SDT2
        cg-RRC-Configuration-r18 CG-RRC-Configuration-r18              OPTIONAL, -- Cond RACH-LessHO
        applyIndicatedTCI-State-r18 ENUMERATED {first, second, both, spare1}  OPTIONAL -- Need R
        ]],


        [[
        sbfd-Config2-PUSCH-RB-Offset-r19 INTEGER (0..maxNrofPhysicalResourceBlocks-1)  OPTIONAL, -- Need R
        symbolType-r19 ENUMERATED {sbfd, non-sbfd}                     OPTIONAL, -- Need R
        frequencyHoppingOffset-SBFD-r19 INTEGER (1.. maxNrofPhysicalResourceBlocks-1)  OPTIONAL, -- Need R
        pusch-MutingResources-r19 PUSCH-MutingResources-r19            OPTIONAL, -- Need R
        occ-LengthAndSequenceIndex-r19      CHOICE {
                                               length2   INTEGER(0..1),
                                               length4   INTEGER(0..3)
                                            }                          OPTIONAL -- Need R
        ]]
    }                                                                  OPTIONAL, -- Need R
    ...,
    [[
    cg-RetransmissionTimer-r16 INTEGER (1..64)                         OPTIONAL, -- Need R
    cg-minDFI-Delay-r16                 ENUMERATED
  {sym7, sym1x14, sym2x14, sym3x14, sym4x14, sym5x14, sym6x14, sym7x14, sym8x14,
                                    sym9x14, sym10x14, sym11x14, sym12x14, sym13x14, sym14x14,sym15x14,
                                    sym16x14
                                                    }                  OPTIONAL, -- Need R
    cg-nrofPUSCH-InSlot-r16 INTEGER (1..7)                             OPTIONAL, -- Need R
    cg-nrofSlots-r16 INTEGER (1..40)                                   OPTIONAL, -- Need R
    cg-StartingOffsets-r16 CG-StartingOffsets-r16                      OPTIONAL, -- Need R
    cg-UCI-Multiplexing-r16 ENUMERATED {enabled}                       OPTIONAL, -- Need R
    cg-COT-SharingOffset-r16 INTEGER (1..39)                           OPTIONAL, -- Need R
    betaOffsetCG-UCI-r16 INTEGER (0..31)                               OPTIONAL, -- Need R
    cg-COT-SharingList-r16 SEQUENCE (SIZE (1..1709)) OF CG-COT-Sharing-r16  OPTIONAL, -- Need R
    harq-ProcID-Offset-r16 INTEGER (0..15)                             OPTIONAL, -- Need M
    harq-ProcID-Offset2-r16 INTEGER (0..15)                            OPTIONAL, -- Need M
    configuredGrantConfigIndex-r16 ConfiguredGrantConfigIndex-r16      OPTIONAL, -- Cond CG-List
    configuredGrantConfigIndexMAC-r16 ConfiguredGrantConfigIndexMAC-r16  OPTIONAL, -- Cond CG-IndexMAC
    periodicityExt-r16 INTEGER (1..5120)                               OPTIONAL, -- Need R
    startingFromRV0-r16 ENUMERATED {on, off}                           OPTIONAL, -- Need R
    phy-PriorityIndex-r16 ENUMERATED {p0, p1}                          OPTIONAL, -- Need R
    autonomousTx-r16 ENUMERATED {enabled}                              OPTIONAL -- Cond LCH-BasedPrioritization
    ]],
    [[
    cg-betaOffsetsCrossPri0-r17 SetupRelease { BetaOffsetsCrossPriSelCG-r17 }  OPTIONAL, -- Need M
    cg-betaOffsetsCrossPri1-r17 SetupRelease { BetaOffsetsCrossPriSelCG-r17 }  OPTIONAL, -- Need M
    mappingPattern-r17 ENUMERATED {cyclicMapping, sequentialMapping}   OPTIONAL, -- Cond SRSsets
    sequenceOffsetForRV-r17 INTEGER (0..3)                             OPTIONAL, -- Need R
    p0-PUSCH-Alpha2-r17 P0-PUSCH-AlphaSetId                            OPTIONAL, -- Need R
    powerControlLoopToUse2-r17 ENUMERATED {n0, n1}                     OPTIONAL, -- Need R
    cg-COT-SharingList-r17 SEQUENCE (SIZE (1..50722)) OF CG-COT-Sharing-r17  OPTIONAL, -- Need R
    periodicityExt-r17 INTEGER (1..40960)                              OPTIONAL, -- Need R
    repK-v1710 ENUMERATED {n12, n16, n24, n32}                         OPTIONAL, -- Need R
    nrofHARQ-Processes-v1700 INTEGER(17..32)                           OPTIONAL, -- Need M
    harq-ProcID-Offset2-v1700 INTEGER (16..31)                         OPTIONAL, -- Need R
    configuredGrantTimer-v1700 INTEGER(33..288)                        OPTIONAL, -- Need R
    cg-minDFI-Delay-v1710 INTEGER (238..3584)                          OPTIONAL -- Need R
    ]],
    [[
    harq-ProcID-Offset-v1730 INTEGER (16..31)                          OPTIONAL, -- Need R
    cg-nrofSlots-r17 INTEGER (1..320)                                  OPTIONAL -- Need R
    ]],
    [[


    disableCG-RetransmissionMonitoring-r18 ENUMERATED {true}           OPTIONAL, -- Need R
    nrofSlotsInCG-Period-r18 INTEGER (2..32)                           OPTIONAL, -- Need R
    uto-UCI-Config-r18                      SEQUENCE {
        nrofBitsInUTO-UCI-r18               INTEGER (3..8),
        betaOffsetUTO-UCI-r18               INTEGER (0..31),
         ...
    }                                                                  OPTIONAL -- Need R
    ]],
    [[
    precodingAndNumberOfLayers-v1850 INTEGER (64..1023)                OPTIONAL, -- Need R
    srs-ResourceIndicator-v1850 INTEGER (16..255)                      OPTIONAL -- Need R
    ]]
}

CG-UCI-OnPUSCH ::= CHOICE {
    dynamic                                 SEQUENCE (SIZE (1..4)) OF BetaOffsets,
    semiStatic                              BetaOffsets
}

SPS-Config ::=                  SEQUENCE {
  periodicity  ENUMERATED {ms10, ms20, ms32, ms40, ms64, ms80, ms128, ms160, ms320, ms640,
                                                        spare6, spare5, spare4, spare3, spare2, spare1},
    nrofHARQ-Processes              INTEGER (1..8),
    n1PUCCH-AN PUCCH-ResourceId                                        OPTIONAL, -- Need M
    mcs-Table ENUMERATED {qam64LowSE}                                  OPTIONAL, -- Need S
    ...,
    [[
    sps-ConfigIndex-r16 SPS-ConfigIndex-r16                            OPTIONAL, -- Cond SPS-List
    harq-ProcID-Offset-r16 INTEGER (0..15)                             OPTIONAL, -- Need R
    periodicityExt-r16 INTEGER (1..5120)                               OPTIONAL, -- Need R
    harq-CodebookID-r16 INTEGER (1..2)                                 OPTIONAL, -- Need R
    pdsch-AggregationFactor-r16 ENUMERATED {n1, n2, n4, n8 }           OPTIONAL -- Need S
    ]],
    [[
    sps-HARQ-Deferral-r17 INTEGER (1..32)                              OPTIONAL, -- Need R
    n1PUCCH-AN-PUCCHsSCell-r17 PUCCH-ResourceId                        OPTIONAL, -- Need R
    periodicityExt-r17 INTEGER (1..40960)                              OPTIONAL, -- Need R
    nrofHARQ-Processes-v1710 INTEGER(9..32)                            OPTIONAL, -- Need R
    harq-ProcID-Offset-v1700 INTEGER (16..31)                          OPTIONAL -- Need R
    ]]
}

The fields worth knowing

That is a long IE, and most of it you will never touch. These are the ones that decide how the feature behaves :

Field	What it does
periodicity	How often the grant repeats, in symbols. The enumeration is huge because it has to cover every subcarrier spacing and both normal and extended cyclic prefix - which is why the values are written as symbol counts (sym2, sym10x14 ...) rather than in milliseconds
configuredGrantTimer	How long a HARQ process stays busy after a configured transmission. It stops the UE reusing a process while the gNB may still be trying to decode the previous one
cg-RetransmissionTimer-r16	Added for unlicensed operation. Because a configured transmission may simply never happen - the channel was busy - the UE needs a timer that says "assume that one was lost and try again", without waiting for feedback that will never come
repK and repK-RV	Blind repetition : send the same transport block K times with a fixed redundancy version pattern, without waiting to hear whether the first one worked. This is how configured grants buy reliability when there is no time for HARQ
nrofHARQ-Processes	1 to 16 in Rel-15, extended to 32 by nrofHARQ-Processes-v1700. More processes means more transmissions can be in flight before any of them has been acknowledged
harq-ProcID-Offset	Keeps the HARQ process IDs used by the configured grant out of the way of those used by dynamic scheduling, so the two cannot collide

NOTE : periodicity is the field that decides whether configured scheduling is worth using at all. It has to match the traffic. A VoIP codec producing a packet every 20 ms is the classic fit - the grant arrives just as the packet does. If the periodicity and the traffic do not line up, the UE either sits on grants it has nothing to send in, or has data waiting for a grant that has not come round yet - and in the second case you have made latency worse than dynamic scheduling, not better.

Reference

[1] How 5G reduces data transmission latency

[2] R1-1900609 - 3GPP TSG RAN WG1 Ad-Hoc Meeting 1901 January, 2019