7.1.1 MAC
38.523-13GPP5GSPart 1: ProtocolRelease 17TSUser Equipment (UE) conformance specification
7.1.1.0 Default Pre-Test Conditions for all MAC test cases
The following pre-test conditions shall be applied in all MAC test cases until the test case explicitly over writes these conditions
System Simulator:
– The SS configures the test environment in accordance to the execution conditions in Table 7.1.1.0-1.
UE:
– None
Preamble:
– The SS performs the generic procedure in [4] to get UE in state RRC_CONNECTED in accordance to the execution conditions in Table 7.1.1.0-2 and using the message condition UE TEST LOOP MODE A to return one PDCP SDU per DL PDCP SDU.
Table 7.1.1.0-1: Test environment
Execution Condition |
Cell configuration |
System Information Combination |
IF pc_NG_RAN_NR |
NR Cell 1 |
NR: System information Combination NR-1 |
ELSE IF pc_EN_DC |
E-UTRA Cell 1 is PCell, NR Cell 1 is PSCell |
EUTRA: System information Combination 1 NR: N/A |
ELSE IF pc_NGEN_DC |
NG-RAN E-UTRA Cell 1 is PCell, NR Cell 1 is PSCell |
EUTRA: System information Combination 1 NR: N/A |
ELSE IF pc_NE_DC |
NR Cell 1 is PCell, E-UTRA Cell 1 is PSCell |
NR: System information Combination NR-1 E-UTRA: N/A |
Table 7.1.1.0-2: Preamble parameters
Execution Condition |
Multi-PDN / Multi-PDU Sessions Condition |
Generic Procedure Parameters |
Primary DRB used for Data testing |
IF pc_NG_RAN_NR |
FALSE |
Connectivity(NR), Test loop function(On) One DRB |
Default DRB of the first PDU session on NR Cell |
TRUE |
Connectivity(NR), Test loop function(On) N DRBs (N ≥ 2) |
||
ELSE IF pc_EN_DC |
FALSE |
Connectivity(EN-DC), DC bearer(One MN Terminated MCG bearer and One SN terminated SCG bearer), Test loop function(On) |
SN Terminated SCG bearer unless explicitly specified in test case |
TRUE |
Connectivity(EN-DC), DC bearer(Two MN Terminated MCG bearer and One SN terminated SCG bearer), Test loop function(On) |
||
ELSE IF pc_NGEN_DC |
FALSE |
Connectivity(NGEN-DC), DC bearer(One MN Terminated MCG bearer and One SN terminated SCG bearer), Test loop function(On) |
SN Terminated SCG bearer unless explicitly specified in test case |
TRUE |
Connectivity(NGEN-DC), DC bearer(Two MN Terminated MCG bearer and One SN terminated SCG bearer), Test loop function(On) |
||
ELSE IF pc_NE_DC |
FALSE |
Connectivity(NE-DC), DC bearer(One MN Terminated MCG bearer and One SN terminated SCG bearer), Test loop function(On) |
SN Terminated SCG bearer unless explicitly specified in test case |
TRUE |
Connectivity(NE-DC), DC bearer(N ≥ 2 MN Terminated MCG bearer and One SN terminated SCG bearer), Test loop function(On) |
Table 7.1.1.0-3: Message conditions
Execution Condition |
Message condition exceptions |
IF pc_NG_RAN_NR |
Message with condition AM is used for step 7 in 4.5.4.2 according to [4] |
ELSE IF pc_EN_DC |
Message condition MCG_and_SCG with condition AM is used for step 7 in 4.5.4.2 according to [4] |
ELSE IF pc_NGEN_DC |
Message condition MCG_and_SCG with condition AM is used for step 7 in 4.5.4.2 according to [4] |
ELSE IF pc_NE_DC |
Message condition MCG_and_SCG with condition AM is used for step 7 in 4.5.4.6 according to [4] |
Table 7.1.1.0-4: SDAP Configuration Settings for pc_NG_RAN_NR and pc_NE_DC
Parameter |
Value DRB1 |
Value DRB2 |
Value DRB3 |
default DRB |
true |
false |
false |
mappedQoS-FlowsToAdd |
QFI 1 in Table 4.8.2.3-1 according to TS38.508-1 |
QFI 2 in Table 4.8.2.3-2 according to TS38.508-1 |
QFI 3 in Table 4.8.2.3-3 according to TS38.508-1 |
7.1.1.1 Random Access Procedures
7.1.1.1.1 Correct selection of RACH parameters / Random access preamble and PRACH resource explicitly signalled to the UE by RRC / contention free random access procedure
7.1.1.1.1.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected }
ensure that {
when { SS sends an RRCReconfiguration message including RACH-ConfigDedicated information element }
then { UE sends a prach preamble given in the RACH-ConfigDedicated on the target cell }
}
(2)
with { UE in RRC_Connected state after transmission of a PRACH preamble on NR SpCell received in RACH-ConfigDedicated on the target cell }
ensure that {
when { UE does not receive a matching Random Access response in ra-ResponseWindowSize (hence considers RACH attempt as failed) and PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX }
then { UE retransmits a PRACH preamble received in RACH-ConfigDedicated on the target cell }
}
7.1.1.1.1.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clauses 5.1.2, 5.1.4. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.2]
The MAC entity shall:
…
1> else if the ra-PreambleIndex has been explicitly provided by PDCCH; and
1> if the ra-PreambleIndex is not 0b000000:
2> set the PREAMBLE_INDEX to the signalled ra-PreambleIndex;
2> select the SSB signalled by PDCCH.
1> else if the contention-free Random Access Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
…
1> else if an SSB is selected above:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured or indicated by PDCCH (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to clause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).
1> else if a CSI-RS is selected above:
2> if there is no contention-free Random Access Resource associated with the selected CSI-RS:
3> determine the next available PRACH occasion from the PRACH occasions, permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured, corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7] (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to clause 8.1 of TS 38.213 [6], corresponding to the SSB which is quasi-collocated with the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the SSB which is quasi-collocated with the selected CSI-RS).
2> else:
3> determine the next available PRACH occasion from the PRACH occasions in ra-OccasionList corresponding to the selected CSI-RS (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers, corresponding to the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected CSI-RS).
1> perform the Random Access Preamble transmission procedure (see clause 5.1.3).
NOTE: When the UE determines if there is an SSB with SS-RSRP above rsrp-ThresholdSSB or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS, the UE uses the latest unfiltered L1-RSRP measurement.
[TS 38.321, clause 5.1.4]
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall:
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> start the ra-ResponseWindow configured in BeamFailureRecoveryConfig at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor for a PDCCH transmission on the search space indicated by recoverySearchSpaceId of the SpCell identified by the C-RNTI while ra-ResponseWindow is running.
1> else:
2> start the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission on the search space indicated by recoverySearchSpaceId is received from lower layers on the Serving Cell where the preamble was transmitted; and
1> if PDCCH transmission is addressed to the C-RNTI; and
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> consider the Random Access procedure successfully completed.
1> else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2> if the Random Access Response contains a MAC subPDU with Backoff Indicator:
3> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
2> else:
3> set the PREAMBLE_BACKOFF to 0 ms.
2> if the Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see clause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3> if the Random Access Response includes a MAC subPDU with RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see clause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
5> if the Random Access procedure for an SCell is performed on uplink carrier where pusch-Config is not configured:
6> ignore the received UL grant.
5> else:
6> process the received UL grant value and indicate it to the lower layers.
4> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
4> else:
5> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
5> if this is the first successfully received Random Access Response within this Random Access procedure:
6> if the transmission is not being made for the CCCH logical channel:
7> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
6> obtain the MAC PDU to transmit from the Multiplexing and assembly entity and store it in the Msg3 buffer.
NOTE: If within a Random Access procedure, an uplink grant provided in the Random Access Response for the same group of contention-based Random Access Preambles has a different size than the first uplink grant allocated during that Random Access procedure, the UE behaviour is not defined.
1> if ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if a PDCCH transmission on the search space indicated by recoverySearchSpaceId addressed to the C-RNTI has not been received on the Serving Cell where the preamble was transmitted; or
1> if ra-ResponseWindow configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX has not been received:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers;
4> if this Random Access procedure was triggered for SI request:
5> consider the Random Access procedure unsuccessfully completed.
3> else if the Random Access Preamble is transmitted on an SCell:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> if the criteria (as defined in clause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4> perform the Random Access Resource selection procedure (see clause 5.1.2);
3> else:
4> perform the Random Access Resource selection procedure (see clause 5.1.2) after the backoff time.
The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.
HARQ operation is not applicable to the Random Access Response reception.
7.1.1.1.1.3 Test description
7.1.1.1.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except the following:
– 2 NR cells (NR Cell 1 and NR Cell 2) are configured.
– Test loop function(Off)
7.1.1.1.1.3.2 Test procedure sequence
Table 7.1.1.1.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits an RRCReconfiguration message to handover NR Cell 1 to target NR Cell 2, including RACH-ConfigDedicated information element (Note 1, Note 3) |
<– |
RRCReconfiguration |
– |
– |
2 |
Void |
||||
3 |
Check: Does the UE transmit Preamble on PRACH corresponding to ra-PreambleIndex in step 1 on NR Cell2? |
–> |
(PRACH Preamble) |
1 |
P |
4 |
Check: Does the UE re-transmits Preamble on PRACH corresponding to ra-PreambleIndex in step 1 on NR Cell2? |
–> |
(PRACH Preamble) |
2 |
P |
5 |
The SS transmits Random Access Response on NR cell 2, with RAPID corresponding to ra-PreambleIndex in step 1 |
<– |
Random Access Response |
– |
– |
6 |
Check: Does the UE transmit an RRCReconfigurationComplete message? (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_PSCell_HO AND RBConfig_NoKeyChange. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: For FR1,PRACH preamble format 0 as per TS 38.211[24] Table 6.3.3.1-1 is configured (real network deployment). |
7.1.1.1.1.3.3 Specific message contents
Table 7.1.1.1.1.3.3-1: Void
Table 7.1.1.1.1.3.3-2: RRCReconfiguration for EN-DC (step 1, Table 7.1.1.1.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 with condition EN-DC_HO. |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.1.3.3-2A: RRCReconfiguration for NR/5GC (step 1, Table 7.1.1.1.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
radioBearerConfig |
RadioBearerConfig as per TS 38.508-1[4] Table 4.6.3-132 with conditions DRBn and Recover_PDCP |
n set to the default DRB of the first PDU session |
NR |
rrcReconfiguration ::= SEQUENCE { |
|||
nonCriticalExtension SEQUENCE { |
|||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.1.3.3-3: CellGroupConfig for EN-DC (Table 7.1.1.1.1.3.3-2)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PSCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
reconfigurationWithSync SEQUENCE { |
|||
rach-ConfigDedicated CHOICE { |
|||
uplink |
RACH-ConfigDedicated |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.1.3.3-3A: CellGroupConfig for NR/5GC (Table 7.1.1.1.1.3.3-2A)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
rach-ConfigDedicated CHOICE { |
|||
uplink |
RACH-ConfigDedicated |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
spCellConfigDedicated |
ServingCellConfig |
||
} |
|||
} |
Table 7.1.1.1.1.3.3-4: RACH-ConfigDedicated (Table 7.1.1.1.1.3.3-3 and Table 7.1.1.1.1.3.3-3A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-129 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
cfra SEQUENCE { |
|||
occasions SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
FR1, PRACH Preamble format 0 used |
|
} |
|||
resources CHOICE { |
|||
ssb SEQUENCE { |
|||
ssb-ResourceList SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource { |
1 entry |
||
CFRA-SSB-Resource[1] SEQUENCE { |
entry 1 |
||
ssb |
0 |
||
ra-PreambleIndex |
52 |
Randomly selected |
|
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.1.3.3-5: RACH-ConfigGeneric (Table 7.1.1.1.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-129 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
prach-ConfigurationIndex |
14 |
FR1 |
|
149 |
FR2 |
||
zeroCorrelationZoneConfig |
12 |
FR1 |
|
15 |
FR2 |
||
} |
Table 7.1.1.1.1.3.3-6: ServingCellConfigCommon (Table 7.1.1.1.1.3.3-3 and Table 7.1.1.1.1.3.3-3A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.1.1.3.3-7: BWP-UplinkCommon (Table 7.1.1.1.1.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.1.3.3-8: RACH-ConfigCommon (Table 7.1.1.1.1.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
ssb_perRACH_OccasionAndCB_PreamblesPerSSB CHOICE { |
|||
one |
n36 |
||
} |
|||
prach-RootSequenceIndex CHOICE { |
|||
l139 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell.. |
||
l839 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
PRACH Preamble format 0 used |
FR1, |
} |
|||
} |
Table 7.1.1.1.1.3.3-9: TDD-UL-DL-ConfigCommon (Table 7.1.1.1.1.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 |
|
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 AND SCS30 |
|
1 |
FR1 AND SCS15 |
||
3 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 |
|
10 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 AND SCS30 |
|
1 |
FR1 AND SCS15 |
||
1 |
FR2 |
||
nrofUplinkSymbols |
4 |
FR1 |
|
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 |
|
} |
|||
pattern2 |
Not present |
||
pattern2 SEQUENCE { |
FR1 |
||
dl-UL-TransmissionPeriodicity |
ms2 |
||
nrofDownlinkSlots |
4 |
FR1 AND SCS30 |
|
2 |
FR1 AND SCS15 |
||
nrofDownlinkSymbols |
0 |
||
nrofUplinkSlots |
0 |
||
nrofUplinkSymbols |
0 |
||
} |
|||
} |
Table 7.1.1.1.1.3.3-10: ServingCellConfig (Table 7.1.1.1.1.3.3-3A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.1.1.3.3-11: BWP-UplinkDedicated (Table 7.1.1.1.1.3.3-10)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup |
PUCCH-Config |
||
} |
|||
} |
Table 7.1.1.1.1.3.3-12: PUCCH-Config (Table 7.1.1.1.1.3.3-11)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-Config ::= SEQUENCE { |
|||
schedulingRequestResourceToAddModList SEQUENCE (SIZE (1..maxNrofSR-Resources)) OF SchedulingRequestResourceConfig { |
1 entry |
||
SchedulingRequestResourceConfig |
SchedulingRequestResourceConfig |
entry 1 |
|
} |
|||
} |
Table 7.1.1.1.1.3.3-13: SchedulingRequestResourceConfig (Table 7.1.1.1.1.3.3-12)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-157 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequestResourceConfig ::= SEQUENCE { |
|||
periodicityAndOffset CHOICE { |
|||
sl10 |
2 |
With SCS = kHz15 results in repetition every 10 ms |
SCS15 |
sl20 |
5 |
With SCS = kHz30 results in repetition every 10 ms |
SCS30 |
sl80 |
4 |
With SCS = kHz120 results in repetition every 10 ms |
SCS120 |
} |
|||
} |
7.1.1.1.1a Correct selection of RACH parameters / Random access preamble and PRACH resource explicitly signalled to the UE by PDCCH Order / contention free random access procedure
7.1.1.1.1a.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected }
ensure that {
when { PDCCH control command is received in NR SpCell providing Random Access Preamble }
then { UE sends a PRACH preamble given in the PDCCH Order in NR SpCell }
}
(2)
with { UE in RRC_Connected state after transmission of a PRACH preamble on NR SpCell received in PDCCH control command on NR SpCell }
ensure that {
when { UE does not receive a matching Random Access response in ra-ResponseWindowSize (hence considers RACH attempt as failed) and PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX }
then { UE retransmits a PRACH preamble received in PDCCH control command on NR SpCell }
}
7.1.1.1.1a.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clauses 5.1.2, 5.1.4 and TS 38.212 clause 7.3.1.2.1. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.2]
The MAC entity shall:
…
1> else if the ra-PreambleIndex has been explicitly provided by either PDCCH or RRC; and
1> if the ra-PreambleIndex is not 0b000000; and
1> if contention-free Random Access Resource associated with SSBs or CSI-RS have not been explicitly provided by RRC:
2> set the PREAMBLE_INDEX to the signalled ra-PreambleIndex.
…
1> if an SSB is selected above and an association between PRACH occasions and SSBs is configured:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).
1> else if a CSI-RS is selected above and an association between PRACH occasions and CSI-RSs is configured:
2> determine the next available PRACH occasion from the PRACH occasions in ra-OccasionList corresponding to the selected CSI-RS (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected CSI-RS).
1> else:
2> determine the next available PRACH occasion (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion).
1> perform the Random Access Preamble transmission procedure (see clause 5.1.3).
[TS 38.321, clause 5.1.4]
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall:
…
1> else:
2> start the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission is received from lower layers; and
1> if PDCCH transmission is addressed to the C-RNTI; and
…
1> else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2> if the Random Access Response contains a Backoff Indicator subheader:
3> set the PREAMBLE_BACKOFF to value of the BI field of the Backoff Indicator subheader using Table 7.2-1.
2> else:
3> set the PREAMBLE_BACKOFF to 0 ms.
2> if the Random Access Response contains a Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see subclause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3> if the Random Access Response includes RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for the SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see subclause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × preamblePowerRampingStep);
5> if the Serving Cell for the Random Access procedure is SRS-only SCell:
6> ignore the received UL grant.
5> else:
6> process the received UL grant value and indicate it to the lower layers.
4> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
…
1> if ra-ResponseWindow configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX has not been received; or:
1> if ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if the PDCCH addressed to the C-RNTI has not been received:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTxMax + 1:
3> if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers.
3> else if the Random Access Preamble is transmitted on a SCell:
4> consider the Random Access procedure unsuccessfully completed.
2> if in this Random Access procedure, the Random Access Preamble was selected by MAC among the contention-based Random Access Preambles:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> delay the subsequent Random Access Preamble transmission by the backoff time.
2> perform the Random Access Resource selection procedure (see subclause 5.1.2).
The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.
HARQ operation is not applicable to the Random Access Response transmission.
[TS 38.212, 7.3.1.2.1]
If the CRC of the DCI format 1_0 is scrambled by C-RNTI and the "Frequency domain resource assignment" field are of all ones, the DCI format 1_0 is for random access procedure initiated by a PDCCH order, with all remaining fields set as follows:
– Random Access Preamble index – 6 bits according to ra-PreambleIndex in Subclause 5.1.2 of [8, TS38.321]
– UL/SUL indicator – 1 bit. If the value of the "Random Access Preamble index" is not all zeros and if the UE is configured with SUL in the cell, this field indicates which UL carrier in the cell to transmit the PRACH according to Table 7.3.1.1.1-1; otherwise, this field is reserved
– SS/PBCH index – 6 bits. If the value of the "Random Access Preamble index" is not all zeros, this field indicates the SS/PBCH that shall be used to determine the RACH occasion for the PRACH transmission; otherwise, this field is reserved.
– PRACH Mask index – 4 bits. If the value of the "Random Access Preamble index" is not all zeros, this field indicates the RACH occasion associated with the SS/PBCH indicated by "SS/PBCH index" for the PRACH transmission, according to Subclause 5.1.1 of [8, TS38.321]; otherwise, this field is reserved
– Reserved bits – 10 bits
7.1.1.1.1a.3 Test description
7.1.1.1.1a.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Test loop function(Off).
7.1.1.1.1a.3.2 Test procedure sequence
Table 7.1.1.1.1a.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0A |
SS transmits an RRCReconfiguration message to configure specific parameters. Note 1, Note 3 |
<– |
RRCReconfiguration |
– |
– |
0B |
The UE transmits RRCReconfigurationComplete message. Note 2 |
–> |
RRCReconfigurationComplete |
– |
– |
1 |
The SS transmits a PDCCH order providing Random Access Preamble ID 37 on NR SpCell. |
<– |
(PDCCH Order) |
– |
– |
2 |
Check: Does the UE transmit Preamble on PRACH corresponding to ra-PreambleIndex in step 1? |
–> |
(PRACH Preamble) |
1 |
P |
3 |
Check: Does the UE re-transmits Preamble on PRACH corresponding to ra-PreambleIndex in step 1? |
–> |
(PRACH Preamble) |
2 |
P |
4 |
Check: Does the UE transmit Preamble on PRACH corresponding to ra-PreambleIndex in step 1? |
–> |
(PRACH Preamble) |
2 |
P |
5 |
Check: Does the UE re-transmits Preamble on PRACH corresponding to ra-PreambleIndex in step 1? |
–> |
(PRACH Preamble) |
2 |
P |
6 |
The SS transmits Random Access Response on NR SpCell, with RAPID corresponding to ra-PreambleIndex in step 1 |
<– |
Random Access Response |
– |
– |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: For FR1, PRACH preamble format 0 as per TS 38.211[24] Table 6.3.3.1-1 is configured in order to provide coverage for PRACH preamble format 0 testing |
7.1.1.1.1a.3.3 Specific message contents
Table 7.1.1.1.1a.3.3-1: RRCReconfiguration (step 0A, Table7.1.1.1.1a.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
TS 38.508-1 [4], 2 |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.1.1a.3.3-2: CellGroupConfig (Table 7.1.1.1.1a.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
newUE-Identity |
RNTI-Value |
||
t304 |
ms2000 |
||
rach-ConfigDedicated |
Not Present |
||
} |
|||
spCellConfigDedicated |
ServingCellConfig |
||
} |
|||
} |
Table 7.1.1.1.1a.3.3-3: ServingCellConfigCommon (Table 7.1.1.1.1a.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.1.1a.3.3-4: BWP-UplinkCommon (Table 7.1.1.1.1a.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.1a.3.3-5: RACH-ConfigCommon (Table 7.1.1.1.1a.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
ssb_perRACH_OccasionAndCB_PreamblesPerSSB CHOICE { |
|||
one |
n36 |
||
} |
|||
prach-RootSequenceIndex CHOICE { |
|||
l139 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell |
||
l839 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
PRACH Preamble format 0 used |
FR1, |
} |
|||
} |
Table 7.1.1.1.1a.3.3-6: RACH-ConfigGeneric (Table 7.1.1.1.1a.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigGeneric ::= SEQUENCE { |
|||
preambleReceivedTargetPower |
-104 |
||
preambleTransMax |
n4 |
||
prach-ConfigurationIndex |
14 |
FR1 |
|
149 |
FR2 |
||
zeroCorrelationZoneConfig |
12 |
FR1 |
|
15 |
FR2 |
||
} |
Table 7.1.1.1.1a.3.3-7: TDD-UL-DL-ConfigCommon (Table 7.1.1.1.1a.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 |
|
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 AND SCS30 |
|
1 |
FR1 AND SCS15 |
||
3 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 |
|
10 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 AND SCS30 |
|
1 |
FR1 AND SCS15 |
||
1 |
FR2 |
||
nrofUplinkSymbols |
4 |
||
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 |
|
} |
|||
pattern2 |
Not present |
||
pattern2 SEQUENCE { |
FR1 |
||
dl-UL-TransmissionPeriodicity |
ms2 |
||
nrofDownlinkSlots |
4 |
FR1 AND SCS30 |
|
2 |
FR1 AND SCS15 |
||
nrofDownlinkSymbols |
0 |
||
nrofUplinkSlots |
0 |
||
nrofUplinkSymbols |
0 |
||
} |
|||
} |
Table 7.1.1.1.1a.3.3-8: ServingCellConfig (Table 7.1.1.1.1a.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.1.1a.3.3-9: BWP-UplinkDedicated (Table 7.1.1.1.1a.3.3-8)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup |
PUCCH-Config |
||
} |
|||
} |
Table 7.1.1.1.1a.3.3-10: PUCCH-Config (Table 7.1.1.1.1a.3.3-9)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-Config ::= SEQUENCE { |
|||
schedulingRequestResourceToAddModList SEQUENCE (SIZE (1..maxNrofSR-Resources)) OF SchedulingRequestResourceConfig { |
1 entry |
||
SchedulingRequestResourceConfig |
SchedulingRequestResourceConfig |
entry 1 |
|
} |
|||
} |
Table 7.1.1.1.1a.3.3-11: SchedulingRequestResourceConfig (Table 7.1.1.1.1a.3.3-10)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequestResourceConfig ::= SEQUENCE { |
|||
periodicityAndOffset CHOICE { |
|||
sl10 |
2 |
With SCS = kHz15 results in repetition every 10 ms |
SCS15 |
sl20 |
5 |
With SCS = kHz30 results in repetition every 10 ms |
SCS30 |
sl80 |
4 |
With SCS = kHz120 results in repetition every 10 ms |
SCS120 |
} |
|||
} |
7.1.1.1.2 Random access procedure / Successful / C-RNTI Based / Preamble selected by MAC itself
7.1.1.1.2.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected NR SpCell TimeAlignmentTimer expired, and has UL Data to send }
ensure that {
when { the UL MAC PDU Size is less than messageSizeGroupA }
then { UE transmits a random access preamble using a preamble in group A of random access preambles }
}
(2)
with { UE in RRC_Connected state after transmission of a PRACH preamble on NR SpCell }
ensure that {
when { SS does not answer with a matching Random Access Response within ra-ResponseWindowSize }
then { UE retransmits a PRACH preamble from same group }
}
(3)
with { UE in RRC_Connected state after transmission of a PRACH preamble on NR SpCell }
ensure that {
when { UE receives while ra-ResponseWindowSizeTimer is running MAC PDU containing multiple RARs but none of the subheaders contains a RAPID corresponding to the UE }
then { UE retransmits a PRACH preamble from same group }
}
(4)
with { UE in RRC_Connected state after transmission of a PRACH preamble on NR SpCell }
ensure that {
when { SS sends a Random Access Response including a Backoff Indicator and the Random Access Preamble identifier is different from the value received from the UE }
then { UE triggers RA preamble after a random time between 0 and the indicated Backoff parameter from same group }
}
(5)
with { UE in RRC_Connected state after transmission of a PRACH preamble on NR SpCell }
ensure that {
when { UE receives while ra-ResponseWindowSizeTimer is running MAC PDU containing multiple RARs and one of the subheaders contains a RAPID corresponding to the UE and containing Backoff Indicator }
then { UE stores Backoff Indicator UE transmits RACH procedure MSG3 }
}
(6)
with { UE in RRC_Connected state after transmission of Msg3 on NR SpCell without dedicated preamble }
ensure that {
when { The SS does not schedule any PDCCH transmission addressed to UE C-RNTI before Contention resolution timer expiry }
then { UE transmits a random access preamble using a preamble in the same group of random access preambles as used for the first transmission of Msg3 }
}
(7)
with { UE in RRC_Connected state after transmission of Msg3 on NR SpCell without dedicated preamble }
ensure that {
when { UE receive PDCCH transmission addressed to its C-RNTI before Contention resolution timer expiry }
then { UE considers RACH procedure as complete }
}
(8)
with { UE in RRC CONNECTED state and Random Access Preambles group B is configured }
ensure that {
when { UE has data available for transmission and the MAC PDU Size carrying this data is greater than ra-Msg3SizeGroupA and TimeAlignmentTimer expires }
then {UE transmits a random access preamble using a preamble in group B of random access preambles}
}
(9)
with { UE in RRC_Connected state and having initiated a random access procedure in NR SpCell }
ensure that {
when { The SS transmits a Timing Advance Command in a Random Access Response message }
then {the UE applies the received Timing Advance value in the next transmitted MAC PDU }
}
7.1.1.1.2.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clauses 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.2, 6.1.3.2, 6.1.5 and 6.2.3. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.2]
The MAC entity shall:
…
1> else (i.e. for the contention-based Random Access preamble selection):
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
2> if Msg3 has not yet been transmitted:
3> if Random Access Preambles group B is configured:
4> if the potential Msg3 size (UL data available for transmission plus MAC header and, where required, MAC CEs) is greater than ra-Msg3SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) –preambleReceivedTargetPower – msg3-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-Msg3SizeGroupA:5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Msg3 is being retransmitted):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the first transmission of Msg3.
2> if the association between Random Access Preambles and SSBs is configured:
3> select a Random Access Preamble randomly with equal probability from the Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group.
2> else:
3> select a Random Access Preamble randomly with equal probability from the Random Access Preambles within the selected Random Access Preambles group.
2> set the PREAMBLE_INDEX to the selected ra-PreambleIndex.
…
1> if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and
1> if ra-AssociationPeriodIndex and si-RequestPeriod are configured:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB in the association period given by ra-AssociationPeriodIndex in the si-RequestPeriod permitted by the restrictions given by the ra-ssb-OccasionMaskIndex (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6] corresponding to the selected SSB).
1> else if an SSB is selected above:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).
1> else if a CSI-RS is selected above:
2> if there is no contention-free Random Access Resource associated with the selected CSI-RS:
3> determine the next available PRACH occasion from the PRACH occasions, permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured, corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7] (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the SSB which is quasi-collected with the selected CSI-RS).
2> else:
3> determine the next available PRACH occasion from the PRACH occasions in ra-OccasionList corresponding to the selected CSI-RS (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers, corresponding to the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected CSI-RS).
1> perform the Random Access Preamble transmission procedure (see subclause 5.1.3).
[TS 38.321, clause 5.1.3]
The MAC entity shall, for each Random Access Preamble:
1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if SSB selected is not changed (i.e. same as the previous Random Access Preamble transmission):
2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.
1> select the value of DELTA_PREAMBLE according to subclause 7.3;
1> set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
1> except for contention-free Random Access Preamble for beam failure recovery request, compute the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the Random Access Preamble using the selected PRACH, corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.
The RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:
RA-RNTI= 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id
where s_id is the index of the first OFDM symbol of the specified PRACH (0 ≤ s_id < 14), t_id is the index of the first slot of the specified PRACH in a system frame (0 ≤ t_id < 80), f_id is the index of the specified PRACH in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for NUL carrier, and 1 for SUL carrier).
[TS 38.321, clause 5.1.4]
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall:
…
1> else:
2> start the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission is received from lower layers on the Serving Cell where the preamble was transmitted; and
1> if PDCCH transmission is addressed to the C-RNTI; and
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> consider the Random Access procedure successfully completed.
1> else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2> if the Random Access Response contains a MAC subPDU with Backoff Indicator:
3> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
2> else:
3> set the PREAMBLE_BACKOFF to 0 ms.
2> if the Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see subclause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3> if the Random Access Response includes RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for the SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see subclause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × preamblePowerRampingStep).
5> if the Serving Cell for the Random Access procedure is SRS-only SCell:
6> ignore the received UL grant.
5> else:
6> process the received UL grant value and indicate it to the lower layers.
4> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
4> else:
5> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
…
1> if ra-ResponseWindow configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX has not been received; or
1> if ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if the PDCCH addressed to the C-RNTI has not been received on the Serving Cell where the preamble was transmitted:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTxMax + 1:
3> if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers.
4> if this Random Access procedure was triggered for SI request:
5> consider the Random Access procedure unsuccessfully completed.
> else if the Random Access Preamble is transmitted on a SCell:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2);
3> else:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2) after the backoff time.
The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.
HARQ operation is not applicable to the Random Access Response transmission.
[TS 38.321, clause 5.1.5]
Once Msg3 is transmitted, the MAC entity shall:
1> start the ra-ContentionResolutionTimer and restart the ra-ContentionResolutionTimer at each HARQ retransmission in the first symbol after the end of the Msg3 transmission;
1> monitor the PDCCH while the ra-ContentionResolutionTimer is running regardless of the possible occurrence of a measurement gap;
1> if notification of a reception of a PDCCH transmission of the SpCell is received from lower layers:
2> if the C-RNTI MAC CE was included in Msg3:
3> if the Random Access procedure was initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission; or
3> if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is addressed to the C-RNTI; or
3> if the Random Access procedure was initiated by a beam failure indication from lower layer and the PDCCH transmission is addressed to the C-RNTI:
4> consider this Contention Resolution successful;
4> stop ra-ContentionResolutionTimer;
4> discard the TEMPORARY_C-RNTI;
4> consider this Random Access procedure successfully completed.
…
1> if ra-ContentionResolutionTimer expires:
2> discard the TEMPORARY_C-RNTI;
2> consider the Contention Resolution not successful.
1> if the Contention Resolution is considered not successful:
2> flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTxMax + 1:
3> indicate a Random Access problem to upper layers.
3> if this Random Access procedure was triggered for SI request:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2);
3> else:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2) after the backoff time.
[TS 38.321, clause 5.2]
RRC configures the following parameters for the maintenance of UL time alignment:
– timeAlignmentTimer (per TAG) which controls how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned.
The MAC entity shall:
1> when a Timing Advance Command MAC CE is received, and if a NTA (as defined in TS 38.211 [8]) has been maintained with the indicated TAG:
2> apply the Timing Advance Command for the indicated TAG;
2> start or restart the timeAlignmentTimer associated with the indicated TAG.
…
1> when a timeAlignmentTimer expires:
2> if the timeAlignmentTimer is associated with the PTAG:
3> flush all HARQ buffers for all Serving Cells;
3> notify RRC to release PUCCH for all Serving Cells, if configured;
3> notify RRC to release SRS for all Serving Cells, if configured;
3> clear any configured downlink assignments and configured uplink grants;
3> clear any PUSCH resource for semi-persistent CSI reporting;
3> consider all running timeAlignmentTimers as expired;
3> maintain NTA (defined in TS 38.211 [8]) of all TAGs.
2> else if the timeAlignmentTimer is associated with an STAG, then for all Serving Cells belonging to this TAG:
3> flush all HARQ buffers;
3> notify RRC to release PUCCH, if configured;
3> notify RRC to release SRS, if configured;
3> clear any configured downlink assignments and configured uplink grants;
3> clear any PUSCH resource for semi-persistent CSI reporting;
3> maintain NTA (defined in TS 38.211 [8]) of this TAG.
When the MAC entity stops uplink transmissions for an SCell due to the fact that the maximum uplink transmission timing difference between TAGs of the MAC entity or the maximum uplink transmission timing difference between TAGs of any MAC entity of the UE is exceeded, the MAC entity considers the timeAlignmentTimer associated with the SCell as expired.
The MAC entity shall not perform any uplink transmission on a Serving Cell except the Random Access Preamble transmission when the timeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running. Furthermore, when the timeAlignmentTimer associated with the pTAG is not running, the MAC entity shall not perform any uplink transmission on any Serving Cell except the Random Access Preamble transmission on the SpCell.
[TS 38.321, clause 6.1.3.2]
The C-RNTI MAC CE is identified by MAC PDU subheader with LCID as specified in Table 6.2.1-2.
It has a fixed size and consists of a single field defined as follows (Figure 6.1.3.2-1):
– C-RNTI: This field contains the C-RNTI of the MAC entity. The length of the field is 16 bits.
Figure 6.1.3.2-1: C-RNTI MAC CE
[TS 38.321, clause 6.1.5]
A MAC PDU consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:
– a MAC subheader with Backoff Indicator only;
– a MAC subheader with RAPID only (i.e. acknowledgment for SI request);
– a MAC subheader with RAPID and MAC RAR.
A MAC subheader with Backoff Indicator consists of five header fields E/T/R/R/BI as described in Figure 6.1.5-1. A MAC subPDU with Backoff Indicator only is placed at the beginning of the MAC PDU, if included. ‘MAC subPDU(s) with RAPID only’ and ‘MAC subPDU(s) with RAPID and MAC RAR’ can be placed anywhere between MAC subPDU with Backoff Indicator only (if any) and padding (if any).
A MAC subheader with RAPID consists of three header fields E/T/RAPID as described in Figure 6.1.5-2.
Padding is placed at the end of the MAC PDU if present. Presence and length of padding is implicit based on TB size, size of MAC subPDU(s).
Figure 6.1.5-1: E/T/R/R/BI MAC subheader
Figure 6.1.5-2: E/T/RAPID MAC subheader
Figure 6.1.5-3: Example of MAC PDU consisting of MAC RARs
[TS 38.321, clause 6.2.3]
The MAC RAR is of fixed size as depicted in Figure 6.2.3-1, and consists of the following fields:
– R: Reserved bit, set to "0";
– Timing Advance Command: The Timing Advance Command field indicates the index value TA used to control the amount of timing adjustment that the MAC entity has to apply in TS 38.213 [6]. The size of the Timing Advance Command field is 12 bits;
– UL Grant: The Uplink Grant field indicates the resources to be used on the uplink in TS 38.213 [6]. The size of the UL Grant field is 27 bits;
– Temporary C-RNTI: The Temporary C-RNTI field indicates the temporary identity that is used by the MAC entity during Random Access. The size of the Temporary C-RNTI field is 16 bits.
The MAC RAR is octet aligned.
Figure 6.2.3-1: MAC RAR
7.1.1.1.2.3 Test description
7.1.1.1.2.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Short_DCI condition is applied in NR Serving cell configuration.
7.1.1.1.2.3.2 Test procedure sequence
Table 7.1.1.1.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 0AA is performed IF pc_NG_RAN_NR only. |
– |
– |
– |
– |
0AA |
The SS transmits an updated system information as specified in Table 7.1.1.1.2.3.3-1A. |
– |
– |
– |
– |
0A |
SS transmits an RRCReconfiguration message to configure specific parameters. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
0B |
The UE transmits RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
1 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T1 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC Control Element) |
– |
– |
2 |
40 to 50 TTI before Timer_T1 expires the SS transmits a MAC PDU containing a PDCP SDU of size 56 bits, less then ra-Msg3SizeGroupA (208 bits) on SpCell. (Note 3) |
<– |
MAC PDU |
– |
– |
3 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
4 |
Check: Does the UE transmit preamble on PRACH using a preamble in group A defined in CellGroupConfig in RRCReconfiguration (totalNumberOfRA-Preambles, ssb-perRACH-OccasionAndCB-PreamblesPerSSB and numberOfRA-PreamblesGroupA) on SpCell in frame number X meeting condition nSFN mod 8 =1, subframe number 2,6,9 (FDD FR1), frame number X meeting condition nSFN mod 2 =1, subframe number 8,9 (FR1 TDD) and frame number X meeting condition nSFN mod 4 =1 and slot number 8, 9, 18, 19, 28, 29, 38, 39 , 48, 49, 58, 59, 68, 69, 78, 79 (FR2 120 kHz)? |
–> |
PRACH Preamble |
1 |
P |
5 |
Check: Does the UE transmit a preamble on PRACH, in frame number X+8 subframe number 2,6,9 (FDD FR1), in frame number X or X+2 in subrame number 8,9 (FR1 TDD) and frame number X or X+4 and slot number 8, 9, 18, 19, 28, 29, 38, 39 , 48, 49, 58, 59, 68, 69, 78, 79 (FR2 120 kHz) using the same group A? |
–> |
PRACH Preamble |
2 |
P |
6 |
The SS transmits a MAC PDU addressed to UE RA-RNTI, containing multiple RARs but none of the MAC sub headers contains a matching RAPID on SpCell. |
<– |
Random Access Response |
– |
– |
– |
EXCEPTION: In parallel with step 7, parallel behaviour defined in table 7.1.1.1.2.3.2-2 is executed. |
– |
– |
– |
– |
7 |
Check: Does the UE re-transmit a preamble on PRACH on SpCell using the same group A? |
–> |
PRACH Preamble |
3 |
P |
8 |
The SS transmits a Random Access Response with the back off parameter set to value Index field ’12’ and with the Random Access Preamble identifier different from the value received from the UE in the Random Access Preamble. The SS sets Timer_T2 to the Back off value ‘960’ associated with the Index value ‘12’ and starts Timer_T2. |
<– |
Random Access Response(BI, RAPID) |
– |
– |
9 |
Check: Does UE send a Random Access Preamble on SpCell while Timer_T2 is running? |
–> |
Random Access Preamble |
4 |
P |
10 |
SS sends Random Access Response with an UL Grant of 56-bits, a back off parameter set to value Index field ‘13’ and the Random Access Preamble identifier value set to the same value as received from the UE in the Random Access Preamble. (Note 4) |
<– |
Random Access Response(BI, RAPID) |
– |
– |
11 |
Check: Does UE sends a msg3 in the grant associated to the Random Access ´Response received in step 10 on SpCell? |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
5 |
P |
12 |
SS does not schedule any PDCCH transmission for UE C-RNTI. The SS sets Timer_T3 to the Back off value ‘1920’ associated with the Index value ‘13’ plus Contention Resolution Timer and starts Timer_T3. |
– |
– |
– |
– |
13 |
Check: Does the UE transmit preamble on PRACH using a preamble belonging to group A for time equal to Timer_T3 on SpCell? |
–> |
PRACH Preamble |
6 |
P |
14 |
The SS transmits Random Access Response with an UL Grant of 56-bits and RAPID corresponding to the transmitted Preamble in step 13, including T-CRNTI. |
<– |
Random Access Response |
– |
– |
15 |
UE sends a msg3 using the grant associated to the Random Access ´Response received in step 14 on SpCell? |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
– |
– |
16 |
SS schedules PDCCH transmission for UE C_RNTI and allocate uplink grant. |
<– |
Contention Resolution |
– |
– |
– |
EXCEPTION: In parallel with step 17, parallel behaviour defined in table 7.1.1.1.2.3.2-3 is executed. |
– |
– |
– |
– |
17 |
Check: Does the UE transmit a MAC PDU with C-RNTI containing looped back PDCP SDU? |
–> |
MAC PDU |
7 |
P |
– |
EXCEPTION: Step 17AA is performed IF pc_NG_RAN_NR only. |
– |
– |
– |
– |
17AA |
The SS transmits an updated system information as specified in Table 7.1.1.1.2.3.3-1A. |
– |
– |
– |
– |
17A |
The SS transmits an RRCReconfiguration message to configure specific parameters. (Note 1) |
<– |
NR RRC: RRCReconfiguration |
– |
– |
17B |
The UE transmits an RRCReconfigurationComplete message. (Note 2) |
–> |
NR RRC: RRCReconfigurationtComplete |
– |
– |
18 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T4 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC Control Element) |
– |
– |
19 |
40 to 50 TTI before Timer_T4 expires the SS transmits a MAC PDU containing a PDCP SDU of size > ra-Msg3SizeGroupA (208 bits). |
<– |
MAC PDU |
– |
– |
20 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
21 |
Check: Does the UE transmit preamble on PRACH using a preamble in group B defined in CellGroupConfig in RRCReconfiguration (ssb-perRACH-OccasionAndCB-PreamblesPerSSB, numberOfRA-PreamblesGroupA and numberOfRA-Preambles) on SpCell? |
–> |
PRACH Preamble |
8 |
P |
22 |
The SS transmits Random Access Response with an UL Grant of 56-bits and RAPID corresponding to the transmitted Preamble in step 21, including T-CRNTI. |
<– |
Random Access Response |
– |
– |
23 |
UE sends a msg3 using the grant associated to the Random Access ´Response received in step 22 on SpCell? |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
– |
– |
23A |
SS schedules PDCCH transmission for UE C_RNTI and allocate uplink grant. |
<– |
Contention Resolution |
– |
– |
24 |
Check: Does the UE transmit a MAC PDU with C-RNTI containing looped back PDCP SDU? |
–> |
MAC PDU |
9 |
P |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: MAC PDU size of 56bits is selected to allow UE send status PDU and still stays below the limit of ra-Msg3SizeGrioupA. Note 4: UL grant of 56bits is to make UE not send any loopback data in uplink with msg3. |
Table 7.1.1.1.2.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit msg3 message on SpCell? |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
– |
F |
Table 7.1.1.1.2.3.2-3: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit an PRACH preamble on SpCell? |
–> |
PRACH Preamble |
– |
F |
7.1.1.1.2.3.3 Specific message contents
Table 7.1.1.1.2.3.3-1: MAC-CellGroupConfig (preamble)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-68 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
tag-Config SEQUENCE { |
|||
tag-ToAddModList SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG { |
1 entry |
||
TAG[1] SEQUENCE { |
entry 1 |
||
timeAlignmentTimer |
ms750 |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.2.3.3-1A: SystemInformationBlockType1 (step 0AA and 17AA, Table 7.1.1.1.2.3.2-1)
Derivation path: 38.508-1 [4] table 4.6.1-28 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
servingCellConfigCommon |
ServingCellConfigCommon |
Same contents as in Table 7.1.1.1.2.3.3-4 |
|
} |
Table 7.1.1.1.2.3.3-2: RRCReconfiguration (step 0A and step 17A, Table 7.1.1.1.2.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
TS 38.508-1 [4], 2. |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.1.2.3.3-3: CellGroupConfig (Table 7.1.1.1.2.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
newUE-Identity |
RNTI-Value |
||
t304 |
ms2000 |
||
rach-ConfigDedicated |
Not Present |
||
} |
Table 7.1.1.1.2.3.3-4: ServingCellConfigCommon (Table 7.1.1.1.2.3.3-3, Table 7.1.1.1.2.3.3-1A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
} |
Table 7.1.1.1.2.3.3-5: BWP-UplinkCommon (Table 7.1.1.1.2.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.2.3.3-6: RACH-ConfigCommon (Table 7.1.1.1.2.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
totalNumberOfRA-Preambles |
42 |
||
ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE { |
|||
One |
n32 |
||
} |
|||
groupBconfigured SEQUENCE { |
|||
ra-Msg3SizeGroupA |
b208 |
||
messagePowerOffsetGroupB |
minusinfinity |
||
numberOfRA-PreamblesGroupA |
28 |
||
} |
|||
ra-ContentionResolutionTimer |
sf48 |
||
} |
Table 7.1.1.1.2.3.3-7: RACH-ConfigGeneric (Table 7.1.1.1.2.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigGeneric ::= SEQUENCE { |
|||
prach-ConfigurationIndex |
119 |
As per Table 6.3.3.2-2: of TS 38.211 [24], this results in PRACH preamble transmission in a radio frame meeting nSFN mod 2=1, subframe number 2, 6, 9 and starting symbol 0 using preamble Format A2. |
FR1 FDD |
prach-ConfigurationIndex |
91 |
As per Table 6.3.3.2-3: of TS 38.211 [24], this results in PRACH preamble transmission in a radio frame meeting nSFN mod 2=1, subframe number 4, 9 and starting symbol 0 using preamble Format A2. |
FR1 TDD |
prach-ConfigurationIndex |
6 |
As per Table 6.3.3.2-4: of TS 38.211 [24] and clause 5.3.2 of TS 38.211 this results in PRACH preamble transmission in radio frame meeting nSFN mod 4 = 1, slot number 8, 9, 18, 19, 28, 29, 38, 39 , 48, 49, 58, 59, 68, 69, 78, 79 and starting symbol 0 using preamble format A1. |
FR2 (120 kHz) |
preambleReceivedTargetPower |
dBm-104 |
||
preambleTransMax |
n10 |
||
powerRampingStep |
dB2 |
||
ra-ResponseWindow |
sl8 |
FR1 FDD and FR2 (120 kHz) |
|
sl20 |
FR1 TDD |
||
} |
Table 7.1.1.1.2.3.3-8: Void
7.1.1.1.3 Random access procedure / Successful / SI request
7.1.1.1.3.1 Test Purpose (TP)
(1)
with { UE in RRC_Idle State and need for Updated System information }
ensure that {
when { UE transmitted PRACH preamble and ra-ResponseWindow has expired}
then { UE retransmits the PRACH Preamble }
}
(2)
with { UE in RRC_Idle State and transmitted PRACH preamble for System information request }
ensure that {
when { UE received a RAR message addressed to RA-RNTI and including matching RAPID only }
then { UE considers the RACH procedure to be successfully completed and informs the upper layer }
}
(3)
Void
7.1.1.1.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321, clause 5.1.2, 5.1.3, 5.1.4, and 6.1., 3GPP TS 38.331 clause 5.2.2.2.25. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.2]
The MAC entity shall:
1> if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
1> if the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and
1> if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and
1> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList;
2> if CSI-RS is selected, and there is no ra-PreambleIndex associated with the selected CSI-RS:
3> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7].
2> else:
3> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB or CSI-RS from the set of Random Access Preambles for beam failure recovery request.
1> else if the ra-PreambleIndex has been explicitly provided by either PDCCH or RRC; and
1> if the ra-PreambleIndex is not 0b000000; and
1> if contention-free Random Access Resource associated with SSBs or CSI-RSs have not been explicitly provided by RRC:
2> set the PREAMBLE_INDEX to the signalled ra-PreambleIndex.
1> else if the contention-free Random Access Resources associated with SSBs have been explicitly provided by RRC and at least one SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
1> else if the contention-free Random Access Resources associated with CSI-RSs have been explicitly provided by RRC and at least one CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs is available:
2> select a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected CSI-RS.
1> else:
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
2> if Msg3 has not yet been transmitted:
3> if Random Access Preambles group B is configured:
4> if the potential Msg3 size (UL data available for transmission plus MAC header and, where required, MAC CEs) is greater than ra-Msg3SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) – preambleReceivedTargetPower – msg3-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-Msg3SizeGroupA:
5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Msg3 is being retransmitted):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the first transmission of Msg3.
2> if the association between Random Access Preambles and SSBs is configured:
3> select a ra-PreambleIndex randomly with equal probability from the Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group.
2> else:
3> select a ra-PreambleIndex randomly with equal probability from the Random Access Preambles within the selected Random Access Preambles group.
2> set the PREAMBLE_INDEX to the selected ra-PreambleIndex.
1> if an SSB is selected above and an association between PRACH occasions and SSBs is configured:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers, corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).
1> else if a CSI-RS is selected above and an association between PRACH occasions and CSI-RSs is configured:
2> determine the next available PRACH occasion from the PRACH occasions in ra-OccasionList corresponding to the selected CSI-RS (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers, corresponding to the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected CSI-RS).
1> else if Random Access procedure was initiated for beam failure recovery; and
1> if a CSI-RS is selected above and there is no contention-free Random Access Resource associated with the selected CSI-RS:
2> determine the next available PRACH occasion from the PRACH occasions, permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured, corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7] (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the SSB which is quasi-collected with the selected CSI-RS).
1> else:
2> determine the next available PRACH occasion (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion).
1> perform the Random Access Preamble transmission procedure (see subclause 5.1.3).
[TS 38.321, clause 5.1.3]
The MAC entity shall, for each Random Access Preamble:
1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if SSB selected is not changed (i.e. same as the previous Random Access Preamble transmission):
2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.
1> select the value of DELTA_PREAMBLE according to subclause 7.3;
1> set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
1> except for contention-free Random Access Preamble for beam failure recovery request, compute the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the Random Access Preamble using the selected PRACH, corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.
The RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:
RA-RNTI= 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id
where s_id is the index of the first OFDM symbol of the specified PRACH (0 ≤ s_id < 14), t_id is the index of the first slot of the specified PRACH in a system frame (0 ≤ t_id < 80), f_id is the index of the specified PRACH in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Msg1 transmission (0 for NUL carrier, and 1 for SUL carrier).
[TS 38.321, clause 5.1.4]
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall:
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> start the ra-ResponseWindow configured in BeamFailureRecoveryConfig at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for response to beam failure recovery request identified by the C-RNTI while ra-ResponseWindow is running.
1> else:
2> start the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission is received from lower layers; and
1> if PDCCH transmission is addressed to the C-RNTI; and
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> consider the Random Access procedure successfully completed.
1> else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2> if the Random Access Response contains a MAC subPDU with Backoff Indicator:
3> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
2> else:
3> set the PREAMBLE_BACKOFF to 0 ms.
2> if the Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see subclause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3> if the Random Access Response includes a MAC subPDU with RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see subclause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
5> if the Serving Cell for the Random Access procedure is SRS-only SCell:
6> ignore the received UL grant.
5> else:
6> process the received UL grant value and indicate it to the lower layers.
4> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
4> else:
5> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
5> if this is the first successfully received Random Access Response within this Random Access procedure:
6> if the transmission is not being made for the CCCH logical channel:
7> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
6> obtain the MAC PDU to transmit from the Multiplexing and assembly entity and store it in the Msg3 buffer.
1> if ra-ResponseWindow configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX has not been received; or
1> if ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if the PDCCH addressed to the C-RNTI has not been received:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers;
4> if this Random Access procedure was triggered for SI request:
5> consider the Random Access procedure unsuccessfully completed.
3> else if the Random Access Preamble is transmitted on a SCell:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> if in this Random Access procedure, the Random Access Preamble was selected by MAC among the contention-based Random Access Preambles:
4> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
4> delay the subsequent Random Access Preamble transmission by the backoff time.
3> perform the Random Access Resource selection procedure (see subclause 5.1.2).
The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.
HARQ operation is not applicable to the Random Access Response transmission.
[TS 38.321, clause 6.1.5]
A MAC PDU consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:
– a MAC subheader with Backoff Indicator only;
– a MAC subheader with RAPID only (i.e. acknowledgment for SI request);
– a MAC subheader with RAPID and MAC RAR.
A MAC subheader with Backoff Indicator consists of five header fields E/T/R/R/BI as described in Figure 6.1.5-1. A MAC subPDU with Backoff Indicator only is placed at the beginning of the MAC PDU, if included. ‘MAC subPDU(s) with RAPID only’ and ‘MAC subPDU(s) with RAPID and MAC RAR’ can be placed anywhere between MAC subPDU with Backoff Indicator only (if any) and padding (if any).
A MAC subheader with RAPID consists of three header fields E/T/RAPID as described in Figure 6.1.5-2.
Padding is placed at the end of the MAC PDU if present. Presence and length of padding is implicit based on TB size, size of MAC subPDU(s).
Figure 6.1.5-1: E/T/R/R/BI MAC subheader
Figure 6.1.5-2: E/T/RAPID MAC subheader
Figure 6.1.5-3: Example of MAC PDU consisting of MAC RARs
[38.331, clause 5.2.2.2.2]
UEs in RRC_IDLE or in RRC_INACTIVE shall monitor for SI change indication in its own paging occasion every DRX cycle. UEs in RRC_CONNECTED shall monitor for SI change indication in any paging occasion at least once per modification period if the UE is provided with common search space on the active BWP to monitor paging, as specified in TS 38.213 [13], clause 13.
ETWS or CMAS capable UEs in RRC_IDLE or in RRC_INACTIVE shall monitor for indications about PWS notification in its own paging occasion every DRX cycle. ETWS or CMAS capable UEs in RRC_CONNECTED shall monitor for indication about PWS notification in any paging occasion at least once every defaultPagingCycle if the UE is provided with common search space on the active BWP to monitor paging.
For Short Message reception in a paging occasion, the UE monitors the PDCCH monitoring occasion(s) for paging as specified in TS 38.304 [20] and TS 38.213 [13].
If the UE receives a Short Message, the UE shall:
1> if the UE is ETWS capable or CMAS capable, the etwsAndCmasIndication bit of Short Message is set, and the UE is provided with searchSpaceOtherSystemInformation on the active BWP:
2> immediately re-acquire the SIB1;
2> if the UE is ETWS capable and si-SchedulingInfo includes scheduling information for SIB6:
3> acquire SIB6, as specified in clause 5.2.2.3.2, immediately;
2> if the UE is ETWS capable and si-SchedulingInfo includes scheduling information for SIB7:
3> acquire SIB7, as specified in clause 5.2.2.3.2, immediately;
2> if the UE is CMAS capable and si-SchedulingInfo includes scheduling information for SIB8:
3> acquire SIB8, as specified in sub-clause 5.2.2.3.2, immediately;
1> if the systemInfoModification bit of Short Message is set:
2> apply the SI acquisition procedure as defined in sub-clause 5.2.2.3 from the start of the next modification period.
7.1.1.1.3.3 Test description
7.1.1.1.3.3.1 Pre-test conditions
System Simulator:
– NR Cell 1 and NR Cell 11.
– System information combination NR-3 as defined in TS 38.508-1 [4] clause 4.4.3.1.3 is used in NR Cell 1.
UE:
– None.
Preamble:
– The UE is in NR RRC_Idle mode (state 1N-A) on NR Cell 1 according to 38.508-1 [4] Table 4.4A.2-1.
7.1.1.1.3.3.2 Test procedure sequence
Table 7.1.1.1.3.3.2-1/2 illustrate the downlink power levels and other changing parameters to be applied for the cell at various time instants of the test execution. The exact instants on which these values shall be applied are described in the texts in this clause. Configurations marked "T0" is applied for Preamble. Configurations marked "T1" and "T2" are applied at the points indicated in the Main behaviour description in Table 7.1.1.1.3.3.2-3.
Table 7.1.1.1.3.3.2-1: Time instances of cell power level and parameter changes for FR1
Parameter |
Unit |
NR Cell 1 |
NR Cell 11 |
Remark |
|
T0 |
SS/PBCH SSS EPRE |
dBm/SCS |
-90 |
Off |
The power level is such that SrxlevNRCell1 > 0 |
Qrxlevmin |
dBm |
-106 |
– |
||
Qrxlevminoffset |
dB |
0 |
– |
||
Pcompensation |
dB |
0 |
– |
||
Qoffset |
dB |
16 |
– |
||
T1 |
SS/PBCH SSS EPRE |
dBm/SCS |
-90 |
-84 |
The power level values are assigned to satisfy RNRCell 1 > RNRCell 11 |
Qrxlevmin |
dBm |
-106 |
-106 |
||
Qrxlevminoffset |
dB |
0 |
0 |
||
Pcompensation |
dB |
0 |
0 |
||
Qoffset |
dB |
16 |
– |
||
T2 |
SS/PBCH SSS EPRE |
dBm/SCS |
-90 |
-84 |
The power level values are assigned to satisfy RNRCell 1 < RNRCell 11 |
Qrxlevmin |
dBm |
-106 |
-106 |
||
Qrxlevminoffset |
dB |
0 |
0 |
||
Pcompensation |
dB |
0 |
0 |
||
Qoffset |
dB |
-10 |
– |
||
Note: The downlink signal level uncertainty is specified in TS 38.508-1 [4] clause 6.2.2.1. |
Table 7.1.1.1.3.3.2-2: Time instances of cell power level and parameter changes for FR2
Parameter |
Unit |
NR Cell 1 |
NR Cell 11 |
Remark |
|
T0 |
SS/PBCH SSS EPRE |
dBm/SCS |
-91 |
Off |
The power level is such that SrxlevNRCell1 > 0 |
Qrxlevmin |
dBm |
2* ROUND((-110+Delta(NRfs))/2) |
– |
||
Qrxlevminoffset |
dB |
0 |
– |
||
Pcompensation |
dB |
0 |
– |
||
Qoffset |
dB |
16 |
– |
||
T1 |
SS/PBCH SSS EPRE |
dBm/SCS |
-91 |
-82 |
The power level values are assigned to satisfy RNRCell 1 > RNRCell 11 |
Qrxlevmin |
dBm |
2* ROUND((-110+Delta(NRfs))/2) |
2* ROUND((-110+Delta(NRfs))/2) |
||
Qrxlevminoffset |
dB |
0 |
0 |
||
Pcompensation |
dB |
0 |
0 |
||
Qoffset |
dB |
16 |
– |
||
T2 |
SS/PBCH SSS EPRE |
dBm/SCS |
-91 |
-82 |
The power level values are assigned to satisfy RNRCell 1 < RNRCell 11 |
Qrxlevmin |
dBm |
2* ROUND((-110+Delta(NRfs))/2) |
2* ROUND((-110+Delta(NRfs))/2) |
||
Qrxlevminoffset |
dB |
0 |
0 |
||
Pcompensation |
dB |
0 |
0 |
||
Qoffset |
dB |
-10 |
– |
||
Note: The downlink signal level uncertainty is specified in TS 38.508-1 [4] section 6.2.2.2. |
Table 7.1.1.1.3.3.2-3: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS changes SS/PBCH EPRE level of NR Cell 11 according to the row "T1" in Table 7.1.1.1.3.3.2-1/2. |
– |
– |
– |
– |
2 |
Wait 60s to ensure UE detects NR Cell 11. |
– |
– |
– |
– |
3 |
SS transmits Short Message on PDCCH addressed to P-RNTI using Short Message field in DCI format 1_0. Bit 1 of Short Message field is set to 1 to indicate the SI modification. |
<– |
(Short Message) |
– |
– |
4 |
The valueTag for SIB3 in the SIB1 message is increased and si–BroadcastStatus for SIB3 is set to ‘notBroadcasted’ and SS stops broadcasting SIB3. |
<– |
– |
– |
|
5 |
Check: Does the UE transmit a preamble on PRACH using the preamble indicated by ra-PreambleStartIndex defined in SI-RequestConfig in SIB1 in Table 7.1.1.1.3.3.3-1? |
–> |
PRACH Preamble |
1 |
P |
6 |
Check: Does the UE re-transmit a preamble on PRACH after ra-ResponseWindow using the preamble indicated by ra-PreambleStartIndex defined in SI-RequestConfig in SIB1 in Table 7.1.1.1.3.3.3-1? |
–> |
PRACH Preamble |
1 |
P |
7 |
Check: Does the UE re-transmit a preamble on PRACH after ra-ResponseWindow using the preamble indicated by ra-PreambleStartIndex defined in SI-RequestConfig in SIB1 in Table 7.1.1.1.3.3.3-1? |
–> |
PRACH Preamble |
1 |
P |
8 |
Check: Does the UE re-transmit a preamble on PRACH after ra-ResponseWindow using the preamble indicated by ra-PreambleStartIndex defined in SI-RequestConfig in SIB1 in Table 7.1.1.1.3.3.3-1? |
–> |
PRACH Preamble |
1 |
P |
9 |
The SS transmits a RAR message addressed to UE RA-RNTI including a MAC subPDU with a matching RAPID only. (Note 1) |
<– |
Random Access Response |
– |
– |
9A |
The SS changes the parameter ‘Qoffset’ in SIB3 of NR Cell 1 according to the row "T2" in Table 7.1.1.1.3.3.2-1/2 and starts broadcasting SIB3. |
||||
10 |
Check: Does UE send Msg3 containing an RRCSetupRequest message in the grant associated to the Random Access Response received in step 9? |
–> |
RRCSetupRequest |
2 |
F |
11 |
Check: Does the test result of generic test procedure in TS 38.508-1 [4] Table 4.9.5.2.2-1 indicate that the UE is camped on NR Cell 11 belonging to a new TA? |
– |
– |
2 |
P |
Note 1: The UE will indicate the reception of an acknowledgement for SI request to upper layers after UE receives the RAR message including a MAC subPDU with a matching RAPID only, according to TS 38.321 [18] clause 5.1.4. |
7.1.1.1.3.3.3 Specific message contents
Table 7.1.1.1.3.3.3-1: SIB1 on NR Cell 1 (Step 4, Table 7.1.1.1.3.3.2-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-28 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
SIB1 ::= SEQUENCE { |
||||
si-SchedulingInfo SEQUENCE { |
||||
schedulingInfoList SEQUENCE { |
2 entries |
|||
si-BroadcastStatus[1] |
Broadcasting |
|||
si-Periodicity[1] |
rf32 |
|||
sib-MappingInfo[1] SEQUENCE { |
||||
type |
SibType2 |
|||
valueTag |
0 |
|||
areaScope |
Not present |
|||
} |
||||
si-BroadcastStatus[2] |
notBroadcasting |
|||
si-Periodicity[2] |
rf64 |
|||
sib-MappingInfo[2] SEQUENCE { |
||||
type |
SibType3 |
|||
valueTag |
1 |
|||
areaScope |
Not present |
|||
} |
||||
} |
||||
si-RequestConfig SEQUENCE { |
||||
rach-OccasionsSI SEQUENCE { |
||||
rach-ConfigSI |
RACH-ConfigGeneric |
TS 38.508-1 [4], Table 4.6.3-130 |
||
ssb-perRACH-Occasion |
one |
|||
} |
||||
si-RequestPeriod |
two |
|||
si-RequestResources SEQUENCE { |
1 entry |
|||
ra-PreambleStartIndex[1] |
52 |
|||
ra-AssociationPeriodIndex[1] |
0 |
|||
ra-ssb-OccasionMaskIndex[1] |
0 |
|||
} |
||||
} |
||||
si-RequestConfigSUL |
Not present |
|||
} |
||||
} |
Table 7.1.1.1.3.3.3-2: SIB3 on NR Cell 1 (Preamble and Step 9A, Table 7.1.1.1.3.3.2-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.2-2 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
SIB3 ::= SEQUENCE { |
||||
intraFreqNeighCellList SEQUENCE { |
||||
physCellId |
The cell identity of NR Cell 11 defined in 38.508-1 [4] clause 4.4.2 |
|||
q-OffsetCell |
16 |
Preamble |
||
-10 |
Step 9A |
|||
} |
||||
} |
7.1.1.1.4 Random access procedure / Successful / Beam Failure / Preamble selected by MAC itself / Non Contention Free RACH procedure
7.1.1.1.4.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state with no failureDetectionResources configured and RACH procedure due to beam failure is triggered }
ensure that {
when { contention free random access resources for beam failure recovery request associated with SS blocks are not provided by RRC }
then { UE selects initiates the non-contention free Random Access Procedure }
}
(2)
with { UE in RRC_CONNECTED state and RACH procedure due to beam failure is triggered }
ensure that {
when { contention free random access resources for beam failure recovery request associated with SS blocks are explicitly provided by RRC }
then { UE selects the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SS block and initiates the contention free Random Access Procedure }
}
(3)
with { UE in RRC_CONNECTED state and RACH procedure due to beam failure is triggered }
ensure that {
when { contention free random access resources for beam failure recovery request associated with CSI-RS are explicitly provided by RRC }
then { UE selects the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected CSI-RS and initiates the contention free Random Access Procedure }
}
(4)
with { UE in RRC_CONNECTED state with Preamble transmitted for contention free RACH procedure for beam failure }
ensure that {
when { ra-ResponseWindowBFR expires and the PDCCH addressed to the C-RNTI has not been received }
then { UE retransmits the PRACH Preamble }
}
(5)
with { UE in RRC_CONNECTED state with Preamble transmitted for contention free RACH procedure for beam failure }
ensure that {
when { before expiry of ra-ResponseWindowBFR the PDCCH addressed to the C-RNTI is received }
then { UE considers the RACH procedure to be successfully completed and stops retransmitting PRACH preambles }
}
7.1.1.1.4.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clause 5.1.2, 5.1.3, 5.1.4 and 5.17. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.2]
The MAC entity shall:
1> if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
1> if the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and
1> if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and
1> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList;
2> if CSI-RS is selected, and there is no ra-PreambleIndex associated with the selected CSI-RS:
3> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7].
2> else:
3> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB or CSI-RS from the set of Random Access Preambles for beam failure recovery request.
1> else if the ra-PreambleIndex has been explicitly provided by PDCCH; and
1> if the ra-PreambleIndex is not 0b000000:
2> set the PREAMBLE_INDEX to the signalled ra-PreambleIndex;
2> select the SSB signalled by PDCCH.
1> else if the contention-free Random Access Resources associated with SSBs have been explicitly provided by RRC and at least one SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
1> else if the contention-free Random Access Resources associated with CSI-RSs have been explicitly provided by RRC and at least one CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs is available:
2> select a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected CSI-RS.
1> else if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and
1> if the Random Access Resources for SI request have been explicitly provided by RRC:
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
2> select a Random Access Preamble corresponding to the selected SSB, from the Random Access Preamble(s) determined according to ra-PreambleStartIndex as specified in TS 38.331 [5];
2> set the PREAMBLE_INDEX to selected Random Access Preamble.
1> else (i.e. for the contention-based Random Access preamble selection):
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
2> if Msg3 has not yet been transmitted:
3> if Random Access Preambles group B is configured:
4> if the potential Msg3 size (UL data available for transmission plus MAC header and, where required, MAC CEs) is greater than ra-Msg3SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) – preambleReceivedTargetPower – msg3-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-Msg3SizeGroupA:
5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Msg3 is being retransmitted):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the first transmission of Msg3.
2> if the association between Random Access Preambles and SSBs is configured:
3> select a Random Access Preamble randomly with equal probability from the Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group.
2> else:
3> select a Random Access Preamble randomly with equal probability from the Random Access Preambles within the selected Random Access Preambles group.
2> set the PREAMBLE_INDEX to the selected Random Access Preamble.
1> if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and
1> if ra-AssociationPeriodIndex and si-RequestPeriod are configured:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB in the association period given by ra-AssociationPeriodIndex in the si-RequestPeriod permitted by the restrictions given by the ra-ssb-OccasionMaskIndex (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6] corresponding to the selected SSB).
1> else if an SSB is selected above:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).
1> else if a CSI-RS is selected above:
2> if there is no contention-free Random Access Resource associated with the selected CSI-RS:
3> determine the next available PRACH occasion from the PRACH occasions, permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured, corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7] (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the SSB which is quasi-collected with the selected CSI-RS).
2> else:
3> determine the next available PRACH occasion from the PRACH occasions in ra-OccasionList corresponding to the selected CSI-RS (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers, corresponding to the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected CSI-RS).
1> perform the Random Access Preamble transmission procedure (see subclause 5.1.3).
NOTE: When the UE determines if there is an SSB with SS-RSRP above rsrp-ThresholdSSB or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS, the UE uses the latest unfiltered L1-RSRP measurement.
[TS 38.321, clause 5.1.4]
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall:
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> start the ra-ResponseWindow configured in BeamFailureRecoveryConfig at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for response to beam failure recovery request identified by the C-RNTI while ra-ResponseWindow is running.
1> else:
2> start the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission is received from lower layers on the Serving Cell where the preamble was transmitted; and
1> if PDCCH transmission is addressed to the C-RNTI; and
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> consider the Random Access procedure successfully completed.
1> else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2> if the Random Access Response contains a MAC subPDU with Backoff Indicator:
3> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
2> else:
3> set the PREAMBLE_BACKOFF to 0 ms.
2> if the Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see subclause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3> if the Random Access Response includes a MAC subPDU with RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see subclause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
5> if the Serving Cell for the Random Access procedure is SRS-only SCell:
6> ignore the received UL grant.
5> else:
6> process the received UL grant value and indicate it to the lower layers.
4> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
4> else:
5> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
5> if this is the first successfully received Random Access Response within this Random Access procedure:
6> if the transmission is not being made for the CCCH logical channel:
7> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
6> obtain the MAC PDU to transmit from the Multiplexing and assembly entity and store it in the Msg3 buffer.
1> if ra-ResponseWindow configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX has not been received; or
1> if ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if the PDCCH addressed to the C-RNTI has not been received on the Serving Cell where the preamble was transmitted:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers;
4> if this Random Access procedure was triggered for SI request:
5> consider the Random Access procedure unsuccessfully completed.
3> else if the Random Access Preamble is transmitted on a SCell:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2);
3> else:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2) after the backoff time.
The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.
HARQ operation is not applicable to the Random Access Response transmission.
7.1.1.1.4.3 Test description
7.1.1.1.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.1.4.3.2 Test procedure sequence
Table 7.1.1.1.4.3.2-1/1A illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. Row marked "T0" denotes the initial conditions after preamble, while columns marked "T1"and "T2"are to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause.
Table 7.1.1.1.4.3.2-1: Time instances of cell power level and parameter changes for FR1
Parameter |
Unit |
E-UTRA Cell 1 |
NR Cell 1 |
NR Cell 1 Beam index #1 |
NR Cell 1 Beam index #0 |
Remark |
|
T0 |
Cell-specific RS EPRE |
dBm/15kHz |
-85 |
– |
– |
– |
Beam#1 Switch ON and Beam#0 Switch OFF |
Reference Power |
dBm/SCS |
– |
-88 |
– |
– |
||
CSI-RS EPRE SS/PBCH SSS EPRE, |
dB |
– |
– |
0 |
-57 |
||
T1 |
Cell-specific RS EPRE |
dBm/15kHz |
-85 |
– |
– |
– |
Beam#1 Switch OFF and Beam#0 Switch ON |
Reference Power |
dBm/SCS |
– |
-88 |
– |
– |
||
CSI-RS EPRE SS/PBCH SSS EPRE, |
dB |
– |
– |
-57 |
0 |
||
T2 |
Cell-specific RS EPRE |
dBm/15kHz |
-85 |
– |
– |
– |
Beam#1 Switch ON and Beam#0 Switch OFF |
Reference Power |
dBm/SCS |
– |
-88 |
– |
– |
||
CSI-RS EPRE SS/PBCH SSS EPRE, |
dB |
– |
– |
0 |
-57 |
||
NOTE: "Beam index #1" refers to transmission of the SS/PBCH block with SSB index #1 (according to the ssb-PositionsInBurst) and CSI-RS with index #1 (according to the CSI-MeasConfig being signalled to the UE at step 1/8/17); "Beam index #0" refers to transmission of the SS/PBCH block with SSB index #0 (according to the ssb-PositionsInBurst) and CSI-RS with index #0 (according to the CSI-MeasConfig being signalled to the UE at step 1/8/17). |
Table 7.1.1.1.4.3.2-1A: Time instances of cell power level and parameter changes for FR2
Parameter |
Unit |
E-UTRA Cell 1 |
NR Cell 1 |
NR Cell 1 Beam index #1 |
NR Cell 1 Beam index #0 |
Remark |
|
T0 |
Cell-specific RS EPRE |
dBm/15kHz |
-96 |
– |
– |
– |
Beam#1 Switch ON and Beam#0 Switch OFF |
Reference Power |
dBm/SCS |
– |
-82 |
– |
– |
||
CSI-RS EPRE SS/PBCH SSS EPRE, |
dB |
– |
– |
0 |
-63 |
||
T1 |
Cell-specific RS EPRE |
dBm/15kHz |
-96 |
– |
– |
– |
Beam#1 Switch OFF and Beam#0 Switch ON |
Reference Power |
dBm/SCS |
– |
-82 |
– |
– |
||
CSI-RS EPRE SS/PBCH SSS EPRE, |
dBm/SCS |
– |
– |
-63 |
0 |
||
T2 |
Cell-specific RS EPRE |
dBm/15kHz |
-96 |
– |
– |
– |
Beam#1 Switch ON and Beam#0 Switch OFF |
Reference Power |
dBm/SCS |
– |
-82 |
– |
– |
||
CSI-RS EPRE SS/PBCH SSS EPRE, |
dBm/SCS |
– |
– |
0 |
-63 |
||
NOTE: "Beam index #1" refers to transmission of the SS/PBCH block with SSB index #1 (according to the ssb-PositionsInBurst) and CSI-RS with index #1 (according to the CSI-MeasConfig being signalled to the UE at step 1/8/17); "Beam index #0" refers to transmission of the SS/PBCH block with SSB index #0 (according to the ssb-PositionsInBurst) and CSI-RS with index #0 (according to the CSI-MeasConfig being signalled to the UE at step 1/8/17). |
Table 7.1.1.1.4.3.2-2: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits an NR RRCReconfiguration message to configure parameters for BFR. Note 1. |
<– |
NR RRC: RRCReconfiguration |
– |
– |
2 |
UE responses NR RRCReconfigurationComplete message. Note 2. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
3 |
The SS changes NR Cell 1 power level according to the row "T1" in table 7.1.1.1.4.3.2-1/1A. |
– |
– |
– |
– |
4 |
Check: Does the UE transmit a preamble on PRACH for the non-contention free Random Access Procedure on NR Cell 1 Beam index #1? |
–> |
PRACH Preamble |
1 |
P |
5 |
The SS transmits a MAC PDU addressed to UE RA-RNTI, containing multiple RAR’s and one of the MAC sub headers contains a matching RAPID on NR Cell 1. |
<– |
Random Access Response |
– |
– |
6 |
UE sends a msg3 using the grant associated to the Random Access Response received in Step 5 on NR Cell 1. |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
– |
– |
7 |
SS schedules PDCCH transmission for UE C-RNTI. |
<– |
Contention Resolution |
– |
– |
8 |
The SS transmits an NR RRCReconfiguration to establish random access resources for BFR associated with SS blocks explicitly. Note 1. |
<– |
NR RRC: RRCReconfiguration |
– |
– |
9 |
UE responses NR RRCReconfigurationComplete message. Note 2. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
10 |
The SS changes NR Cell 1 power level according to the row "T2" in table 7.1.1.1.4.3.2-1/1A. |
– |
– |
– |
– |
11 |
Check: Does the UE transmit preamble on PRACH using a preamble with PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SS block provided by RRC on NR Cell 1 Beam index #0? |
–> |
PRACH Preamble |
2 |
P |
12 |
The SS waits for ra-ResponseWindowBFR expire. NOTE: The SS does not transmit Random Access Response to the UE. |
– |
– |
– |
– |
13 |
Check: Does the UE retransmit a preamble on PRACH with ra-PreambleIndex same as the Step 11? |
–> |
PRACH Preamble |
4 |
P |
14 |
The SS transmits a MAC PDU addressed to UE C-RNTI, containing multiple RAR’s and one of the MAC sub headers contains a matching RAPID on NR Cell 1. |
<– |
Random Access Response |
– |
– |
15 |
The SS waits for ra-ResponseWindowBFR expire. |
– |
– |
– |
– |
16 |
Check: Does the UE retransmit a preamble on PRACH? |
– |
– |
5 |
F |
– |
EXCEPTION: Steps 17 to 25 describe behaviour that depends on the UE capability. |
– |
– |
– |
– |
17 |
IF pc_csi_RS_CFRA_ForHO THEN the SS transmits an NR RRCReconfiguration message to establish random access resources for BFR associated with CSI-RS explicitly. Note 1. |
<– |
NR RRC: RRCReconfiguration |
– |
– |
18 |
UE responses NR RRCReconfigurationComplete message. Note 2. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
19 |
The SS changes NR Cell 1 power level according to the row "T1" in table 7.1.1.1.4.3.2-1/1A. |
– |
– |
– |
– |
20 |
Check: Does the UE transmit preamble on PRACH using a preamble with PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected CSI-RS provided by RRC on NR Cell 1 Beam index #1? |
–> |
PRACH Preamble |
3 |
P |
21 |
The SS waits for ra-ResponseWindowBFR expire. NOTE: The SS does not transmit Random Access Response to the UE. |
– |
– |
– |
– |
22 |
Check: Does the UE retransmit a preamble on PRACH with ra-PreambleIndex same as the Step 20? |
–> |
PRACH Preamble |
4 |
P |
23 |
The SS transmits a MAC PDU addressed to UE C-RNTI, containing multiple RAR’s and one of the MAC sub headers contains a matching RAPID on NR Cell 1. |
<– |
Random Access Response |
– |
– |
24 |
The SS waits for ra-ResponseWindowBFR expire. |
– |
– |
– |
– |
25 |
Check: Does the UE retransmit a preamble on PRACH? |
– |
– |
5 |
F |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.1.4.3.3 Specific message contents
Table 7.1.1.1.4.3.3-1: Void
Table 7.1.1.1.4.3.3-2: Void
Table 7.1.1.1.4.3.3-3: RRCReconfiguration (Step 1, Step8, Step17 Table 7.1.1.1.4.3.2-2)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration::=SEQUENCE{ |
||||
criticalExtensions CHOICE{ |
||||
rrcReconfiguration SEQUENCE{ |
||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING |
EN-DC |
|
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.1.4.3.3-4: CellGroupConfig (Table 7.1.1.1.4.3.3-3: RRCReconfiguration)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
spCellConfigDedicated |
ServingCellConfig |
||
} |
|||
} |
Table 7.1.1.1.4.3.3-5: ServingCellConfig (Table 7.1.1.1.4.3.3-4: CellGroupConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
initialDownlinkBWP |
BWP-DownlinkDedicated |
||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
csi-MeasConfig CHOICE { |
Step 1 |
||
setup |
CSI-MeasConfig |
||
} |
|||
} |
Table 7.1.1.1.4.3.3-6: BWP-DownlinkDedicated (Table 7.1.1.1.4.3.3-5: ServingCellConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-11 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-DownlinkDedicated ::= SEQUENCE { |
|||
pdcch-Config |
Not present |
Step 17 |
|
pdcch-Config CHOICE { |
Step 1, Step 8 |
||
setup |
PDCCH-Config |
||
} |
|||
pdsch-Config CHOICE { |
|||
setup |
PDSCH-Config |
||
} |
|||
radioLinkMonitoringConfig CHOICE { |
|||
setup |
RadioLinkMonitoringConfig |
||
} |
|||
} |
Table 7.1.1.1.4.3.3-7: RadioLinkMonitoringConfig (Table 7.1.1.1.4.3.3-6: BWP-DownlinkDedicated)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-133 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RadioLinkMonitoringConfig ::= SEQUENCE { |
|||
failureDetectionResourcesToAddModList SEQUENCE (SIZE(1..maxNrofFailureDetectionResources)) OF RadioLinkMonitoringRS { |
2 entries |
||
RadioLinkMonitoringRS[1] SEQUENCE { |
entry 1 |
||
radioLinkMonitoringRS-Id |
0 |
||
purpose |
rlf |
Step 1, Step 17 |
|
both |
Step 8 |
||
detectionResource CHOICE { |
|||
csi-rs |
0 |
NR Cell 1 Beam index #0 |
|
} |
|||
} |
|||
RadioLinkMonitoringRS[2] SEQUENCE { |
entry 2 |
||
radioLinkMonitoringRS-Id |
1 |
||
purpose |
rlf |
Step 1, Step 8 |
|
both |
Step 17 |
||
detectionResource CHOICE { |
|||
csi-rs |
1 |
NR Cell 1 Beam index #1 |
|
} |
|||
} |
|||
} |
|||
beamFailureInstanceMaxCount |
n1 |
||
beamFailureDetectionTimer |
pbfd1 |
||
} |
Table 7.1.1.1.4.3.3-8: PDSCH-Config (Table 7.1.1.1.4.3.3-6: BWP-DownlinkDedicated)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-100 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDSCH-Config ::= SEQUENCE { |
|||
tci-StatesToAddModList SEQUENCE(SIZE (1.. maxNrofTCI-States)) OF TCI-State { |
3 entries |
||
TCI-State[1] SEQUENCE { |
entry 1 |
||
tci-StateId |
0 |
||
qcl-type1 SEQUENCE { |
|||
cell |
ServCellIndex of NR SpCell |
Cell ID |
|
bwp-id |
0 |
BWP ID |
|
referenceSignal CHOICE { |
|||
ssb |
1 |
SSB index #1 |
|
} |
|||
qcl-Type |
type C |
||
} |
|||
qcl-type2 |
Not present |
||
qcl-type2 SEQUENCE { |
FR2 |
||
cell |
ServCellIndex of NR SpCell |
Cell ID |
|
bwp-id |
0 |
BWP ID |
|
referenceSignal CHOICE { |
|||
ssb |
1 |
SSB index #1 |
|
} |
|||
qcl-Type |
type D |
||
} |
|||
} |
|||
TCI-State[2] SEQUENCE { |
entry 2 |
||
tci-StateId |
1 |
||
qcl-type1 SEQUENCE { |
|||
cell |
ServCellIndex of NR SpCell |
Cell ID |
|
bwp-id |
0 |
BWP ID |
|
referenceSignal CHOICE { |
|||
ssb |
0 |
SSB index #0 |
|
} |
|||
qcl-Type |
type C |
||
} |
|||
qcl-type2 |
Not present |
||
qcl-type2 SEQUENCE { |
FR2 |
||
cell |
ServCellIndex of NR SpCell |
Cell ID |
|
bwp-id |
0 |
BWP ID |
|
referenceSignal CHOICE { |
|||
ssb |
0 |
SSB index #0 |
|
} |
|||
qcl-Type |
type D |
||
} |
|||
} |
|||
TCI-State[3] SEQUENCE { |
entry 3 |
||
tci-StateId |
2 |
||
qcl-type1 SEQUENCE { |
|||
cell |
ServCellIndex of NR SpCell |
Cell ID |
|
bwp-id |
0 |
BWP ID |
|
referenceSignal CHOICE { |
|||
csi-rs |
1 |
Csi-Rs index #1 |
|
} |
|||
qcl-Type |
type A |
||
} |
|||
qcl-type2 |
Not present |
||
qcl-type2 SEQUENCE { |
FR2 |
||
cell |
ServCellIndex of NR SpCell |
Cell ID |
|
bwp-id |
0 |
BWP ID |
|
referenceSignal CHOICE { |
|||
Csi-rs |
1 |
Csi-Rs index #1 |
|
} |
|||
qcl-Type |
type D |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.4.3.3-9: PDCCH-Config (Table 7.1.1.1.4.3.3-6: BWP-DownlinkDedicated)
Derivation Path: TS 38.508-1 [4],Table 4.6.3-95 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDCCH-Config::= SEQUENCE { |
|||
controlResourceSetToAddModList SEQUENCE(SEQUENCE(SIZE (1..3)) OF ControlResourceSet { |
2 entries |
||
ControlResourceSet[1] |
ControlResourceSetid1 |
entry 1 |
|
ControlResourceSet[2] |
ControlResourceSetid2 |
entry 2 |
|
} |
|||
searchSpacesToAddModList SEQUENCE(SIZE (1..10)) OF SearchSpace { |
2 entries |
||
SearchSpace[1] |
SearchSpace with condition USS |
entry 1 |
|
SearchSpace[2] |
SearchSpaceBFR |
entry 2 |
|
} |
|||
} |
Table 7.1.1.1.4.3.3-10: ControlResourceSetId1 (Table 7.1.1.1.4.3.3-9: PDCCH-Config)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ControlResourceSet ::= SEQUENCE { |
|||
controlResourceSetId |
1 |
||
tci-StatesPDCCH-ToAddList SEQUENCE (SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId { |
1 entry |
Step 1 |
|
TCI-StateId[1] |
2 |
entry 1 TCI-State Id 2 |
|
} |
|||
tci-StatesPDCCH-ToReleaseList SEQUENCE (SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId { |
1 entry |
Step 8 |
|
TCI-StateId[1] |
2 |
entry 1 TCI-State Id 2 |
|
} |
|||
} |
Table 7.1.1.1.4.3.3-11: ControlResourceSetId2 (Table 7.1.1.1.4.3.3-9: PDCCH-Config)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ControlResourceSet ::= SEQUENCE { |
|||
controlResourceSetId |
2 |
||
} |
Table 7.1.1.1.4.3.3-12: SearchSpaceBFR (Table 7.1.1.1.4.3.3-9: PDCCH-Config)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-162 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SearchSpace ::= SEQUENCE { |
|||
searchSpaceId |
4 |
||
controlResourceSetId |
2 |
||
searchSpaceType CHOICE { |
|||
ue-Specific SEQUENCE { |
|||
dci-Formats |
formats0-0-And-1-0 |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.4.3.3-13: CSI-MeasConfig (Table 7.1.1.1.4.3.3-5: ServingCellConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-38 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CSI-MeasConfig::= SEQUENCE { |
|||
nzp-CSI-RS-ResourceToAddModList SEQUENCE { |
2 entries |
||
NZP-CSI-RS-Resource[1] |
NZP-CSI-RS-ResourceId0 |
||
NZP-CSI-RS-Resource[2] |
NZP-CSI-RS-ResourceId1 |
||
} |
|||
nzp-CSI-RS-ResourceSetToAddModList SEQUENCE { |
1 entry |
||
NZP-CSI-RS-ResourceSet[1] |
NZP-CSI-RS-ResourceSetid0 |
||
} |
|||
csi-IM-ResourceToAddModList |
Not present |
||
csi-IM-ResourceSetToAddModList |
Not present |
||
csi-SSB-ResourceSetToAddModList |
Not present |
||
csi-ReportConfigToAddModList |
Not present |
||
reportTriggerSize |
Not present |
||
aperiodicTriggerStateList |
Not present |
||
} |
Table 7.1.1.1.4.3.3-14: NZP-CSI-RS-ResourceId0 (Table 7.1.1.1.4.3.3-13: CSI-MeasConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-85 |
|||
Information Element |
Value/remark |
Comment |
Condition |
NZP-CSI-RS-Resource ::= SEQUENCE { |
|||
nzp-CSI-RS-ResourceId |
0 |
||
resourceMapping |
CSI-RS-ResourceMapping with condition TRS |
TS 38.508-1 [4], Table 4.6.3-45 |
|
qcl-InfoPeriodicCSI-RS |
0 |
QCL to SSB #0 |
|
} |
Table 7.1.1.1.4.3.3-15: NZP-CSI-RS-ResourceId1 (Table 7.1.1.1.4.3.3-13: CSI-MeasConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-85 |
|||
Information Element |
Value/remark |
Comment |
Condition |
NZP-CSI-RS-Resource ::= SEQUENCE { |
|||
nzp-CSI-RS-ResourceId |
1 |
||
resourceMapping |
CSI-RS-ResourceMapping with condition TRS |
TS 38.508-1 [4], Table 4.6.3-45 |
|
periodicityAndOffset |
CSI-ResourcePeriodicityAndOffset_Id1 |
||
qcl-InfoPeriodicCSI-RS |
1 |
QCL to SSB #1 |
|
} |
Table 7.1.1.1.4.3.3-16: CSI-ResourcePeriodicityAndOffset_Id1 (Table 7.1.1.1.4.3.3-15: NZP-CSI-RS-ResourceId1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-43 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CSI-ResourcePeriodicityAndOffset ::= CHOICE { |
|||
slots80 |
11 |
FR1 |
|
slots320 |
41 |
FR2 |
|
} |
Table 7.1.1.1.4.3.3-17: NZP-CSI-RS-ResourceSetid0 (Table 7.1.1.1.4.3.3-13: CSI-MeasConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-87 |
|||
Information Element |
Value/remark |
Comment |
Condition |
NZP-CSI-RS-ResourceSet ::= SEQUENCE { |
|||
nzp-CSI-ResourceSetId |
0 |
||
nzp-CSI-RS-Resources SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-ResourcesPerSet)) OF NZP-CSI-RS-ResourceId { |
2 entries |
||
NZP-CSI-RS-ResourceId[1] |
0 |
entry 1 |
|
NZP-CSI-RS-ResourceId[2] |
1 |
entry 2 |
|
} |
|||
trs-Info |
true |
||
} |
Table 7.1.1.1.4.3.3-18: BWP-UplinkDedicated (Table 7.1.1.1.4.3.3-5: ServingCellConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup |
PUCCH-Config |
||
} |
|||
pusch-Config CHOICE { |
|||
setup |
PUSCH-Config |
||
} |
|||
beamFailureRecoveryConfig |
BeamFailureRecoveryConfig_SSB |
Step8 |
|
BeamFailureRecoveryConfig_CSIRS |
Step17 |
||
Not Present |
Step1 |
||
} |
Table 7.1.1.1.4.3.3-19: BeamFailureRecoveryConfig_SSB (Table 7.1.1.1.4.3.3-18: BWP-UplinkDedicated)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-6 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BeamFailureRecoveryConfig ::= SEQUENCE { |
|||
rootSequenceIndex-BFR |
0 |
See TS 38.508-1 [4] clause 4.4.2, Table 4.4.2-2 |
|
rach-ConfigBFR |
RACH-ConfigGeneric |
38.508-1 [4] Table 4.6.3-130 |
|
rsrp-ThresholdSSB |
57(-99dBm) |
||
candidateBeamRSList SEQUENCE (SIZE(1..maxNrofCandidateBeams)) OF PRACH-ResourceDedicatedBFR CHOICE{ |
|||
ssb SEQUENCE { |
|||
ssb |
1 |
NR Cell Beam#1 |
|
ra-PreambleIndex |
56 |
(0..63) |
|
} |
|||
} |
|||
ssb-perRACH-Occasion |
one |
||
ra-ssb-OccasionMaskIndex |
0 |
||
recoverySearchSpaceID |
4 |
||
ra-Prioritization |
Not Present |
||
beamFailureRecoveryTimer |
ms200 |
||
} |
Table 7.1.1.1.4.3.3-20: BeamFailureRecoveryConfig_CSIRS (Table 7.1.1.1.4.3.3-18: BWP-UplinkDedicated)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-6 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BeamFailureRecoveryConfig ::= SEQUENCE { |
|||
rootSequenceIndex-BFR |
0 |
See TS 38.508-1 [4] clause 4.4.2, Table 4.4.2-2 |
|
rach-ConfigBFR |
RACH-ConfigGeneric |
38.508-1 [4] Table 4.6.3-130 |
|
rsrp-ThresholdSSB |
57(-99dBm) |
||
candidateBeamRSList SEQUENCE (SIZE(1..maxNrofCandidateBeams)) OF PRACH-ResourceDedicatedBFR CHOICE{ |
|||
csi-RS SEQUENCE { |
|||
csi-RS |
0 |
||
ra-OccasionList SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS)) OF INTEGER (0..maxRA-Occasions-1) { |
1 entry |
||
INTEGER[1] |
0 |
entry 1 NR Cell Beam#0 |
|
} |
|||
ra-PreambleIndex |
59 |
||
} |
|||
} |
|||
ssb-perRACH-Occasion |
Not Present |
||
ra-ssb-OccasionMaskIndex |
Not Present |
||
recoverySearchSpaceID |
4 |
||
ra-Prioritization |
Not Present |
||
beamFailureRecoveryTimer |
ms200 |
||
} |
Table 7.1.1.1.4.3.3-21: PUCCH-Config (Table 7.1.1.1.4.3.3-18: BWP-UplinkDedicated)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
pucch-Config::= SEQUENCE { |
|||
pucch-PowerControl SEQUENCE { |
|||
pathlossReferenceRSs SEQUENCE (SIZE (1..maxNrofPUCCH-PathlossReferenceRSs)) OF PUCCH-PathlossReferenceRS { |
1 entry |
||
PUCCH-PathlossReferenceRS[1] SEQUENCE { |
entry 1 |
||
referenceSignal CHOICE { |
|||
ssb-Index |
1 |
Step1, Step17 |
|
0 |
Step8 |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.4.3.3-22: PUSCH-Config (Table 7.1.1.1.4.3.3-18: BWP-UplinkDedicated)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-118 |
|||
Information Element |
Value/remark |
Comment |
Condition |
pusch-Config::= SEQUENCE { |
|||
pusch-PowerControl SEQUENCE { |
|||
pathlossReferenceRSToAddModList SEQUENCE (SIZE (1..maxNrofPUSCH-PathlossReferenceRSs)) OF PUSCH-PathlossReferenceRS { |
1 entry |
||
PUSCH-PathlossReferenceRS[1] SEQUENCE { |
entry 1 |
||
referenceSignal CHOICE{ |
|||
ssb-Index |
1 |
Step1, Step17 |
|
0 |
Step8 |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
7.1.1.1.5 Random access procedure / Successful / Supplementary Uplink
7.1.1.1.5.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state with supplementary uplink configured and RACH procedure is triggered }
ensure that {
when { RSRP of the downlink pathloss reference is less than rsrp-ThresholdSSB-SUL }
then { UE performs the Random Access Procedure on the Supplementary Uplink carrier }
}
7.1.1.1.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in TS 38.321: clause 5.1.1 and clause 5.16. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.1]
The Random Access procedure described in this clause is initiated by a PDCCH order, by the MAC entity itself, or by RRC for the events in accordance with TS 38.300 [2]. There is only one Random Access procedure ongoing at any point in time in a MAC entity. The Random Access procedure on an SCell shall only be initiated by a PDCCH order with ra-PreambleIndex different from 0b000000.
NOTE 1: If a new Random Access procedure is triggered while another is already ongoing in the MAC entity, it is up to UE implementation whether to continue with the ongoing procedure or start with the new procedure (e.g. for SI request).
RRC configures the following parameters for the Random Access procedure:
– prach-ConfigurationIndex: the available set of PRACH occasions for the transmission of the Random Access Preamble;
– preambleReceivedTargetPower: initial Random Access Preamble power;
– rsrp-ThresholdSSB: an RSRP threshold for the selection of the SSB. If the Random Access procedure is initiated for beam failure recovery, rsrp-ThresholdSSB used for the selection of the SSB within candidateBeamRSList refers to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE;
– rsrp-ThresholdCSI-RS: an RSRP threshold for the selection of CSI-RS. If the Random Access procedure is initiated for beam failure recovery, rsrp-ThresholdCSI-RS is equal to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE;
– rsrp-ThresholdSSB-SUL: an RSRP threshold for the selection between the NUL carrier and the SUL carrier;
– candidateBeamRSList: a list of reference signals (CSI-RS and/or SSB) identifying the candidate beams for recovery and the associated Random Access parameters;
– recoverySearchSpaceId: the search space identity for monitoring the response of the beam failure recovery request;
– powerRampingStep: the power-ramping factor;
– powerRampingStepHighPriority: the power-ramping factor in case of prioritized Random Access procedure;
– scalingFactorBI: a scaling factor for prioritized Random Access procedure;
– ra-PreambleIndex: Random Access Preamble;
– ra-ssb-OccasionMaskIndex: defines PRACH occasion(s) associated with an SSB in which the MAC entity may transmit a Random Access Preamble (see clause 7.4);
– ra-OccasionList: defines PRACH occasion(s) associated with a CSI-RS in which the MAC entity may transmit a Random Access Preamble;
– ra-PreambleStartIndex: the starting index of Random Access Preamble(s) for on-demand SI request;
– preambleTransMax: the maximum number of Random Access Preamble transmission;
– ssb-perRACH-OccasionAndCB-PreamblesPerSSB: defines the number of SSBs mapped to each PRACH occasion and the number of contention-based Random Access Preambles mapped to each SSB;
– if groupBconfigured is configured, then Random Access Preambles group B is configured.
– Amongst the contention-based Random Access Preambles associated with an SSB (as defined in TS 38.213 [6]), the first numberOfRA-PreamblesGroupA Random Access Preambles belong to Random Access Preambles group A. The remaining Random Access Preambles associated with the SSB belong to Random Access Preambles group B (if configured).
NOTE 2: If Random Access Preambles group B is supported by the cell Random Access Preambles group B is included for each SSB.
– if Random Access Preambles group B is configured:
– ra-Msg3SizeGroupA: the threshold to determine the groups of Random Access Preambles;
– msg3-DeltaPreamble: ∆PREAMBLE_Msg3 in TS 38.213 [6];
– messagePowerOffsetGroupB: the power offset for preamble selection;
– numberOfRA-PreamblesGroupA: defines the number of Random Access Preambles in Random Access Preamble group A for each SSB.
– the set of Random Access Preambles and/or PRACH occasions for SI request, if any;
– the set of Random Access Preambles and/or PRACH occasions for beam failure recovery request, if any;
– the set of Random Access Preambles and/or PRACH occasions for reconfiguration with sync, if any;
– ra-ResponseWindow: the time window to monitor RA response(s) (SpCell only);
– ra-ContentionResolutionTimer: the Contention Resolution Timer (SpCell only).
In addition, the following information for related Serving Cell is assumed to be available for UEs:
– if Random Access Preambles group B is configured:
– if the Serving Cell for the Random Access procedure is configured with supplementary uplink as specified in TS 38.331 [5], and SUL carrier is selected for performing Random Access Procedure:
– PCMAX,f,c of the SUL carrier as specified in TS 38.101-1 [14], TS 38.101-2 [15], and TS 38.101-3 [16].
– else:
– PCMAX,f,c of the NUL carrier as specified in TS 38.101-1 [14], TS 38.101-2 [15], and TS 38.101-3 [16].
The following UE variables are used for the Random Access procedure:
– PREAMBLE_INDEX;
– PREAMBLE_TRANSMISSION_COUNTER;
– PREAMBLE_POWER_RAMPING_COUNTER;
– PREAMBLE_POWER_RAMPING_STEP;
– PREAMBLE_RECEIVED_TARGET_POWER;
– PREAMBLE_BACKOFF;
– PCMAX;
– SCALING_FACTOR_BI;
– TEMPORARY_C-RNTI.
When the Random Access procedure is initiated on a Serving Cell, the MAC entity shall:
1> flush the Msg3 buffer;
1> set the PREAMBLE_TRANSMISSION_COUNTER to 1;
1> set the PREAMBLE_POWER_RAMPING_COUNTER to 1;
1> set the PREAMBLE_BACKOFF to 0 ms;
1> if the carrier to use for the Random Access procedure is explicitly signalled:
2> select the signalled carrier for performing Random Access procedure;
2> set the PCMAX to PCMAX,f,c of the signalled carrier.
1> else if the carrier to use for the Random Access procedure is not explicitly signalled; and
1> if the Serving Cell for the Random Access procedure is configured with supplementary uplink as specified in TS 38.331 [5]; and
1> if the RSRP of the downlink pathloss reference is less than rsrp-ThresholdSSB-SUL:
2> select the SUL carrier for performing Random Access procedure;
2> set the PCMAX to PCMAX,f,c of the SUL carrier.
1> else:
2> select the NUL carrier for performing Random Access procedure;
2> set the PCMAX to PCMAX,f,c of the NUL carrier.
1> perform the BWP operation as specified in clause 5.15;
1> set PREAMBLE_POWER_RAMPING_STEP to
powerRampingStep;1> set SCALING_FACTOR_BI to 1;
1> if the Random Access procedure was initiated for beam failure recovery (as specified in clause 5.17); and
1> if beamFailureRecoveryConfig is configured for the active UL BWP of the selected carrier:
2> start the beamFailureRecoveryTimer, if configured;
2> apply the parameters powerRampingStep, preambleReceivedTargetPower, and preambleTransMax configured in the beamFailureRecoveryConfig;
2> if powerRampingStepHighPriority is configured in the beamFailureRecoveryConfig:
3> set PREAMBLE_POWER_RAMPING_STEP to the powerRampingStepHighPriority.
2> else:
3> set PREAMBLE_POWER_RAMPING_STEP to powerRampingStep.
2> if scalingFactorBI is configured in the beamFailureRecoveryConfig:
3> set SCALING_FACTOR_BI to the scalingFactorBI.
1> else if the Random Access procedure was initiated for handover; and
1> if rach-ConfigDedicated is configured for the selected carrier:
2> if powerRampingStepHighPriority is configured in the rach-ConfigDedicated:
3> set PREAMBLE_POWER_RAMPING_STEP to the powerRampingStepHighPriority.
2> if scalingFactorBI is configured in the rach-ConfigDedicated:
3> set SCALING_FACTOR_BI to the scalingFactorBI.
1> perform the Random Access Resource selection procedure (see clause 5.1.2).
[TS 38.321, clause 5.16]
The Supplementary UL (SUL) carrier can be configured as a complement to the normal UL (NUL) carrier. Switching between the NUL carrier and the SUL carrier means that the UL transmissions move from one carrier to the other carrier, which is done by:
– an indication in DCI;
– the Random Access procedure as specified in clause 5.1.1.
If the MAC entity receives a UL grant indicating an SUL switch while a Random Access procedure is ongoing, the MAC entity shall ignore the UL grant.
The Serving Cell configured with supplementaryUplink belongs to a single TAG.
7.1.1.1.5.3 Test description
7.1.1.1.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that supplementary uplink (SUL) carrier is configured on NR Cell 33.
7.1.1.1.5.3.2 Test procedure sequence
Table 7.1.1.1.5.3.2-1 illustrates the downlink power levels to be applied for the NR cells at various time instants of the test execution. Row marked "T0" denotes the initial conditions, while row marked "T1" are to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause.
Table 7.1.1.1.5.3.2-1: Time instances of cell power level changes
Parameter |
Unit |
NR Cell 1 (NUL) |
NR Cell 33 (SUL) |
Remark |
|
T0 |
SS/PBCH SSS EPRE |
dBm/SCS |
-75 |
N/A |
NR Cell1 Power level is higher than rsrp-ThresholdSSB-SUL. |
T1 |
SS/PBCH SSS EPRE |
dBm/SCS |
-85 |
N/A |
NR Cell1 Power level is lower than rsrp-ThresholdSSB-SUL. |
Table 7.1.1.1.5.3.2-2: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS ignores scheduling requests and does not allocate any uplink grant |
– |
– |
– |
|
2 |
The SS transmits a MAC PDU containing a PDCP SDU on NR Cell 1. |
<– |
MAC PDU |
– |
– |
3 |
The SS changes NR Cell 1’s power level according to the row "T1" in table 7.1.1.1.5.3.2-1. (Note 1) |
– |
– |
– |
– |
4 |
Void. |
– |
– |
– |
– |
5 |
Check: Does the UE initiate the random access procedure on SUL carrier on NR Cell 33? |
–> |
PRACH Preamble |
1 |
P |
6 |
The SS transmits Random Access Response with an UL Grant of 56-bits on NR Cell 1 and RAPID corresponding to the transmitted preamble in step 5. (Note 2) |
<– |
Random Access Response |
– |
– |
7 |
Check: Does the UE send a msg3 using the grant associated to the Random Access Response received in Step 6 on SUL carrier on NR Cell 33? |
–> |
Msg3 (C-RNTI MAC CE) |
1 |
P |
8 |
The SS schedules PDCCH transmission on NR Cell 1 for UE C-RNTI with uplink grant’s UL/SUL indicator set to 1. |
<– |
Contention Resolution |
– |
– |
9 |
Check: Does the UE transmit a MAC PDU with C-RNTI containing looped back PDCP SDU on SUL carrier on NR Cell 33? |
–> |
MAC PDU |
1 |
P |
Note 1: Reduce the NR Cell 1 SS/PBCH EPRE level to ensure that RSRP of the downlink pathloss reference is lower than rsrp-ThresholdSSB-SUL, while UE is still able to receive msg2 and msg4 correctly. Note 2: UL grant of 56 bits is to make UE not send any loopback data in uplink with msg3, according to TS 38.321 [18] clause 5.4.3.1. |
7.1.1.1.5.3.3 Specific message contents
Table 7.1.1.1.5.3.3-1: SIB1 of NR Cell 1 (preamble and all steps, Table 7.1.1.1.5.3.2-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SIB1::= SEQUENCE { |
|||
servingCellConfigCommon |
ServingCellConfigCommonSIB |
||
} |
Table 7.1.1.1.5.3.3-2: ServingCellConfigCommonSIB (Table 7.1.1.1.5.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-169 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommonSIB ::= SEQUENCE { |
|||
supplementaryUplink SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
} |
Table 7.1.1.1.5.3.3-3: BWP-UplinkCommon (Table 7.1.1.1.5.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-14 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.5.3.3-4: RACH-ConfigCommon (Table 7.1.1.1.5.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rsrp-ThresholdSSB-SUL |
76 |
IE value 76 means -80dBm |
SUL |
} |
Table 7.1.1.1.5.3.3-5: DCI Format 0-1 (Step 8 of Table 7.1.1.1.5.3.2-2)
Derivation Path: TS 38.508-1 [4], Table 4.3.6.1.1.2-1 |
|||
Information Element |
Value/remark |
Comment |
Condition |
UL/SUL indicator |
1 |
UE configured with SUL in the cell |
7.1.1.1.6 Random access procedure / Successful/ Temporary C-RNTI Based / Preamble selected by MAC itself
7.1.1.1.6.1 Test Purpose (TP)
(1)
with { UE in RRC Idle state has UL CCCH PDU to send and Random Access Preambles group B is configured }
ensure that {
when { the UL CCCH MAC PDU Size is less than messageSizeGroupA }
then { UE transmits a random access preamble using a preamble in group A of random access preambles }
}
(2)
with { UE in RRC Idle state initiated Random Access procedure to transmit UL CCCH PDU and transmitted MSG3 }
ensure that {
when { The SS schedules any PDCCH transmission addressed to UE Temporary C-RNTI before Contention resolution timer expiry with MAC PDU does not contain a matching UE Contention Resolution Identity MAC CE }
then {UE re transmits a random access preamble using a preamble in the same group of random access preambles as used for the first transmission of Msg3 }
}
(3)
with { UE in RRC Idle state initiated Random Access procedure to transmit UL CCCH PDU and transmitted MSG3 }
ensure that {
when { The SS does not schedule any PDCCH transmission addressed to UE Temporary C-RNTI before Contention resolution timer expiry }
then {UE re transmits a random access preamble using a preamble in the same group of random access preambles as used for the first transmission of Msg3 }
}
(4)
with { UE in RRC Idle state initiated Random Access procedure to transmit UL CCCH PDU and transmitted MSG3 }
ensure that {
when { The SS schedules a PDCCH transmission addressed to UE Temporary C-RNTI before Contention resolution timer expiry }
then {UE assumes RACH procedure as complete }
}
7.1.1.1.6.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321, clauses 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.2, 6.1.3.2, 6.1.5 and 6.2.3. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.1.2]
The MAC entity shall:
1> if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
1> if the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and
1> if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and
1> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList;
2> if CSI-RS is selected, and there is no ra-PreambleIndex associated with the selected CSI-RS:
3> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the SSB in candidateBeamRSList which is quasi-colocated with the selected CSI-RS as specified in TS 38.214 [7].
2> else:
3> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB or CSI-RS from the set of Random Access Preambles for beam failure recovery request.
1> else if the ra-PreambleIndex has been explicitly provided by PDCCH; and
1> if the ra-PreambleIndex is not 0b000000:
2> set the PREAMBLE_INDEX to the signalled ra-PreambleIndex;
2> select the SSB signalled by PDCCH.
1> else if the contention-free Random Access Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
1> else if the contention-free Random Access Resources associated with CSI-RSs have been explicitly provided in rach-ConfigDedicated and at least one CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs is available:
2> select a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected CSI-RS.
1> else if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and
1> if the Random Access Resources for SI request have been explicitly provided by RRC:
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
2> select a Random Access Preamble corresponding to the selected SSB, from the Random Access Preamble(s) determined according to ra-PreambleStartIndex as specified in TS 38.331 [5];
2> set the PREAMBLE_INDEX to selected Random Access Preamble.
1> else (i.e. for the contention-based Random Access preamble selection):
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
2> if Msg3 has not yet been transmitted:
3> if Random Access Preambles group B is configured:
4> if the potential Msg3 size (UL data available for transmission plus MAC header and, where required, MAC CEs) is greater than ra-Msg3SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) – preambleReceivedTargetPower – msg3-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-Msg3SizeGroupA:
5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Msg3 is being retransmitted):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the first transmission of Msg3.
> select a Random Access Preamble3 randomly with equal probability from the Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group.
> else:
2> set the PREAMBLE_INDEX to the selected Random Access Preamble.
11> ifthe Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and
1> if ra-AssociationPeriodIndex and si-RequestPeriod are configured:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB in the association period given by ra-AssociationPeriodIndex in the si-RequestPeriod permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6] corresponding to the selected SSB).
> else if an SSB is selected above:
2> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured or indicated by PDCCH (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB).
1> else if a CSI-RS is selected above:
2> if there is no contention-free Random Access Resource associated with the selected CSI-RS:
3> determine the next available PRACH occasion from the PRACH occasions, permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured, corresponding to the SSB in candidateBeamRSList which is quasi-colocated with the selected CSI-RS as specified in TS 38.214 [7] (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the consecutive PRACH occasions according to subclause 8.1 of TS 38.213 [6], corresponding to the SSB which is quasi-colocated with the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the SSB which is quasi-colocated with the selected CSI-RS).
2> else:
3> determine the next available PRACH occasion from the PRACH occasions in ra-OccasionList corresponding to the selected CSI-RS (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers, corresponding to the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected CSI-RS).
1> else if Random Access procedure was initiated for beam failure recovery; and
1> if a CSI-RS is selected above and there is no contention-free Random Access Resource associated with the selected CSI-RS:
2> determine the next available PRACH occasion from the PRACH occasions, permitted by the restrictions given by the ra-ssb-OccasionMaskIndex if configured, corresponding to the SSB in candidateBeamRSList which is quasi-collocated with the selected CSI-RS as specified in TS 38.214 [7] (the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the SSB which is quasi-collected with the selected CSI-RS).
1> else:
2> determine the next available PRACH occasion (the MAC entity shall select a PRACH occasion randomly with equal probability amongst the PRACH occasions occurring simultaneously but on different subcarriers; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion).
1> perform the Random Access Preamble transmission procedure (see subclause 5.1.3).
NOTE: When the UE determines if there is an SSB with SS-RSRP above rsrp-ThresholdSSB or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS, the UE uses the latest unfiltered L1-RSRP measurement.
[TS 38.321, clause 5.1.3]
The MAC entity shall, for each Random Access Preamble:
1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if SSB or CSI-RS selected is not changed from the selection in the last Random Access Preamble transmission:
2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.
1> select the value of DELTA_PREAMBLE according to subclause 7.3;
1> set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
1> except for contention-free Random Access Preamble for beam failure recovery request, compute the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the Random Access Preamble using the selected PRACH occasion, corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.
The RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted, is computed as:
RA-RNTI= 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id
where s_id is the index of the first OFDM symbol of the PRACH occasion (0 ≤ s_id < 14), t_id is the index of the first slot of the PRACH occasion in a system frame (0 ≤ t_id < 80), f_id is the index of the PRACH occasion in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Random Access Preamble transmission (0 for NUL carrier, and 1 for SUL carrier).
[TS 38.321, clause 5.1.4]
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall:
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> start the ra-ResponseWindow configured in BeamFailureRecoveryConfig at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor for a PDCCH transmission on the search space indicated by recoverySearchSpaceId of the SpCell identified by the C-RNTI while ra-ResponseWindow is running.
1> else:
2> start the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission on the search space indicated by recoverySearchSpaceId is received from lower layers on the Serving Cell where the preamble was transmitted; and
1> if PDCCH transmission is addressed to the C-RNTI; and
1> if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> consider the Random Access procedure successfully completed.
1> else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2> if the Random Access Response contains a MAC subPDU with Backoff Indicator:
3> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
2> else:
3> set the PREAMBLE_BACKOFF to 0 ms.
2> if the Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see subclause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3> if the Random Access Response includes a MAC subPDU with RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see subclause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
5> if the Serving Cell for the Random Access procedure is SRS-only SCell:
6> ignore the received UL grant.
5> else:
6> process the received UL grant value and indicate it to the lower layers.
4> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
4> else:
5> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
5> if this is the first successfully received Random Access Response within this Random Access procedure:
6> if the transmission is not being made for the CCCH logical channel:
7> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
6> obtain the MAC PDU to transmit from the Multiplexing and assembly entity and store it in the Msg3 buffer.
NOTE: If within a Random Access procedure, an uplink grant provided in the Random Access Response for the same group of contention-based Random Access Preambles has a different size than the first uplink grant allocated during that Random Access procedure, the UE behavior is not defined.
1> if ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if a PDCCH transmission on the search space indicated by recoverySearchSpaceId addressed to the C-RNTI has not been received on the Serving Cell where the preamble was transmitted; or
> if ra-ResponseWindow configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX has not been received1:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers;
4> if this Random Access procedure was triggered for SI request:
5> consider the Random Access procedure unsuccessfully completed.
3> else if the Random Access Preamble is transmitted on a SCell:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2);
3> else:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2) after the backoff time.
The MAC entity may stop ra-ResponseWindow (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE_INDEX.
HARQ operation is not applicable to the Random Access Response reception.
[TS 38.321, clause 5.1.5]
Once Msg3 is transmitted, the MAC entity shall:
1> start the ra-ContentionResolutionTimer and restart the ra-ContentionResolutionTimer at each HARQ retransmission in the first symbol after the end of the Msg3 transmission;
1> monitor the PDCCH while the ra-ContentionResolutionTimer is running regardless of the possible occurrence of a measurement gap;
1> if notification of a reception of a PDCCH transmission of the SpCell is received from lower layers:
2> if the C-RNTI MAC CE was included in Msg3:
3> if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17) and the PDCCH transmission is addressed to the C-RNTI; or
3> if the Random Access procedure was initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission; or
3> if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is addressed to the C-RNT:I
> if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17) and the PDCCH transmission is addressed to the C-RNTI:
4> consider this Contention Resolution successful;
4> stop ra-ContentionResolutionTimer;
4> discard the TEMPORARY_C-RNTI;
4> consider this Random Access procedure successfully completed.
2> else if the CCCH SDU was included in Msg3 and the PDCCH transmission is addressed to its TEMPORARY_C-RNTI:
3> if the MAC PDU is successfully decoded:
4> stop ra-ContentionResolutionTimer;
4> if the MAC PDU contains a UE Contention Resolution Identity MAC CE; and
4> if the UE Contention Resolution Identity in the MAC CE matches the CCCH SDU transmitted in Msg3:
5> consider this Contention Resolution successful and finish the disassembly and demultiplexing of the MAC PDU;
5> if this Random Access procedure was initiated for SI request:
6> indicate the reception of an acknowledgement for SI request to upper layers.
5> else:
6> set the C-RNTI to the value of the TEMPORARY_C-RNTI;
5> discard the TEMPORARY_C-RNTI;
5> consider this Random Access procedure successfully completed.
4> else:
5> discard the TEMPORARY_C-RNTI;
5> consider this Contention Resolution not successful and discard the successfully decoded MAC PDU.
1> if ra-ContentionResolutionTimer expires:
2> discard the TEMPORARY_C-RNTI;
2> consider the Contention Resolution not successful.
1> if the Contention Resolution is considered not successful:
2> flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> indicate a Random Access problem to upper layers.
3> if this Random Access procedure was triggered for SI request:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
3> perform the Random Access Resource selection procedure (see subclause 5.1.2).
3> else:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2) after the backoff time.
[TS 38.321, clause 5.2]
RRC configures the following parameters for the maintenance of UL time alignment:
– timeAlignmentTimer (per TAG) which controls how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned.
The MAC entity shall:
1> when a Timing Advance Command MAC CE is received, and if an NTA (as defined in TS 38.211 [8]) has been maintained with the indicated TAG:
2> apply the Timing Advance Command for the indicated TAG;
2> start or restart the timeAlignmentTimer associated with the indicated TAG.
1> when a Timing Advance Command is received in a Random Access Response message for a Serving Cell belonging to a TAG:
2> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble:
3> apply the Timing Advance Command for this TAG;
3> start or restart the timeAlignmentTimer associated with this TAG.
2> else if the timeAlignmentTimer associated with this TAG is not running:
3> apply the Timing Advance Command for this TAG;
3> start the timeAlignmentTimer associated with this TAG;
3> when the Contention Resolution is considered not successful as described in subclause 5.1.5; or
3> when the Contention Resolution is considered successful for SI request as described in subclause 5.1.5, after transmitting HARQ feedback for MAC PDU including UE Contention Resolution Identity MAC CE:
4> stop timeAlignmentTimer associated with this TAG.
2> else:
3> ignore the received Timing Advance Command.
1> when a timeAlignmentTimer expires:
2> if the timeAlignmentTimer is associated with the PTAG:
3> flush all HARQ buffers for all Serving Cells;
3> notify RRC to release PUCCH for all Serving Cells, if configured;
3> notify RRC to release SRS for all Serving Cells, if configured;
3> clear any configured downlink assignments and configured uplink grants;
3> clear any PUSCH resource for semi-persistent CSI reporting;
3> consider all running timeAlignmentTimers as expired;
3> maintain NTA (defined in TS 38.211 [8]) of all TAGs.
2> else if the timeAlignmentTimer is associated with an STAG, then for all Serving Cells belonging to this TAG:
3> flush all HARQ buffers;
3> notify RRC to release PUCCH, if configured;
3> notify RRC to release SRS, if configured;
3> clear any configured downlink assignments and configured uplink grants;
3> clear any PUSCH resource for semi-persistent CSI reporting;
3> maintain NTA (defined in TS 38.211 [8]) of this TAG.
When the MAC entity stops uplink transmissions for an SCell due to the fact that the maximum uplink transmission timing difference between TAGs of the MAC entity or the maximum uplink transmission timing difference between TAGs of any MAC entity of the UE is exceeded, the MAC entity considers the timeAlignmentTimer associated with the SCell as expired.
The MAC entity shall not perform any uplink transmission on a Serving Cell except the Random Access Preamble transmission when the timeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running. Furthermore, when the timeAlignmentTimer associated with the PTAG is not running, the MAC entity shall not perform any uplink transmission on any Serving Cell except the Random Access Preamble transmission on the SpCell.
[TS 38.321, clause 6.1.3.2]
The C-RNTI MAC CE is identified by MAC PDU subheader with LCID as specified in Table 6.2.1-2.
It has a fixed size and consists of a single field defined as follows (Figure 6.1.3.2-1):
– C-RNTI: This field contains the C-RNTI of the MAC entity. The length of the field is 16 bits.
Figure 6.1.3.2-1: C-RNTI MAC CE
[TS 38.321, clause 6.1.5]
A MAC PDU consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:
– a MAC subheader with Backoff Indicator only;
– a MAC subheader with RAPID only (i.e. acknowledgment for SI request);
– a MAC subheader with RAPID and MAC RAR.
A MAC subheader with Backoff Indicator consists of five header fields E/T/R/R/BI as described in Figure 6.1.5-1. A MAC subPDU with Backoff Indicator only is placed at the beginning of the MAC PDU, if included. ‘MAC subPDU(s) with RAPID only’ and ‘MAC subPDU(s) with RAPID and MAC RAR’ can be placed anywhere between MAC subPDU with Backoff Indicator only (if any) and padding (if any).
A MAC subheader with RAPID consists of three header fields E/T/RAPID as described in Figure 6.1.5-2.
Padding is placed at the end of the MAC PDU if present. Presence and length of padding is implicit based on TB size, size of MAC subPDU(s).
Figure 6.1.5-1: E/T/R/R/BI MAC subheader
Figure 6.1.5-2: E/T/RAPID MAC subheader
Figure 6.1.5-3: Example of MAC PDU consisting of MAC RARs
[TS 38.321, clause 6.2.3]
The MAC RAR is of fixed size as depicted in Figure 6.2.3-1, and consists of the following fields:
– R: Reserved bit, set to "0";
– Timing Advance Command: The Timing Advance Command field indicates the index value TA used to control the amount of timing adjustment that the MAC entity has to apply in TS 38.213 [6]. The size of the Timing Advance Command field is 12 bits;
– UL Grant: The Uplink Grant field indicates the resources to be used on the uplink in TS 38.213 [6]. The size of the UL Grant field is 27 bits;
– Temporary C-RNTI: The Temporary C-RNTI field indicates the temporary identity that is used by the MAC entity during Random Access. The size of the Temporary C-RNTI field is 16 bits.
The MAC RAR is octet aligned.
Figure 6.2.3-1: MAC RAR
7.1.1.1.6.3 Test description
7.1.1.1.6.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Test loop function(Off).7.1.1.1.6.3.2 Test procedure sequence
Table 7.1.1.1.6.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits a Paging message including a matched UE identity. |
<– |
Paging |
– |
– |
2 |
Check: Does the UE transmit preamble on PRACH using a preamble in group A defined in servingCellConfigCommon in SIB1 (totalNumberOfRA-Preambles, ssb-perRACH-OccasionAndCB-PreamblesPerSSB and numberOfRA-PreamblesGroupA)? |
–> |
PRACH Preamble |
1 |
P |
3 |
The SS transmits Random Access Response with RAPID corresponding to the transmitted Preamble in step 2, including TC-RNTI and not including Back off Indicator subheader. |
<– |
Random Access Response |
– |
– |
4 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. (Note 1) |
–> |
MAC PDU (RRCSetupRequest) |
– |
– |
5 |
Before the contention resolution timer expires, the SS does not schedule any PDCCH. |
||||
6 |
Check: Does the UE re-transmit a preamble on PRACH using a preamble in the same group A? |
–> |
PRACH Preamble |
3 |
P |
7 |
The SS transmits Random Access Response with RAPID corresponding to the transmitted Preamble in step 6, including TC-RNTI and not including Back off Indicator subheader. |
<– |
Random Access Response |
– |
– |
8 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. (Note 1) |
–> |
MAC PDU (RRCSetupRequest) |
– |
– |
9 |
The SS schedules PDCCH transmission addressed to TC-RNTI to transmit a valid MAC PDU containing an RRCSetup message, but not including a matching ‘UE Contention Resolution Identity’ MAC control element. |
<– |
MAC PDU (RRCSetup) |
– |
– |
– |
EXCEPTION: In parallel with step 10, the parallel behaviour in table 7.1.1.1.6.3.2-2 is running. |
– |
– |
– |
– |
10 |
Check: Does the UE re-transmit a preamble on PRACH using a preamble in the same group A? |
–> |
PRACH Preamble |
2 |
P |
11 |
The SS transmits Random Access Response with RAPID corresponding to the transmitted Preamble in step 10, including TC-RNTI and not including Back off Indicator subheader. |
<– |
Random Access Response |
– |
|
12 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. (Note 1) |
–> |
MAC PDU (RRCSetupRequest) |
– |
– |
13 |
The SS schedules PDCCH transmission addressed to TC-RNTI to transmit a valid MAC PDU containing an RRCSetup message and ‘UE Contention Resolution Identity’ MAC control element with matched ‘Contention Resolution Identity’. |
<– |
MAC PDU (RRCSetup and UE Contention Resolution Identity MAC CE) |
– |
– |
14 |
Check: Does UE transmit a MAC PDU containing an RRCSetupComplete message indicating acceptance of RRCSetup message? |
–> |
MAC PDU (RRCSetupComplete) |
4 |
P |
Note 1: Size of RRCSetupRequest message is 45 bits, octet aligned = 48 bits. With 16 bits of MAC Header the minimum size of MAC PDU carrying RRCSetupRequest is 64 bits. |
Table 7.1.1.1.6.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: UE transmits a MAC PDU containing an RRCSetupComplete message indicating acceptance of RRCSetup message? |
–> |
MAC PDU (RRCSetupComplete) |
2 |
F |
7.1.1.1.6.3.3 Specific message contents
Table 7.1.1.1.6.3.3-1: SIB1 (Preamble, Table 7.1.1.1.6.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
servingCellConfigCommon SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.6.3.3-2: BWP-UplinkCommon (Table 7.1.1.1.6.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.6.3.3-3: RACH-ConfigCommon (Table 7.1.1.1.6.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
totalNumberOfRA-Preambles |
42 |
||
ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE { |
|||
One |
n32 |
||
} |
|||
groupBconfigured SEQUENCE { |
|||
ra-Msg3SizeGroupA |
b208 |
||
messagePowerOffsetGroupB |
minusinfinity |
||
numberOfRA-PreamblesGroupA |
28 |
||
} |
|||
ra-ContentionResolutionTimer |
sf48 |
||
} |
7.1.1.1.7 Random access procedure / Successful/ Temporary C-RNTI Based / Preamble selected by MAC itself
7.1.1.1.7.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected and NR SpCell TimeAlignmentTimer expired, and has UL Data to send }
ensure that {
when { the BWP selected for Random Access procedure is configured with both 2-step and 4-step RA type Random Access Resources and the RSRP of the downlink pathloss reference is above msgA-RSRP-Threshold }
then { UE SET RA_TYPE to 2-step AND sends a MSGA on the NR SpCell }
}
(2)
with { UE in RRC_Connected NR SpCell TimeAlignmentTimer expired, and has UL Data to send }
ensure that {
when { BWP selected for Random Access procedure is only configured with 2-step RA type Random Access resources }
then { UE SET RA_TYPE to 2-step AND sends a MSGA on the NR SpCell }
}
7.1.1.1.7.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321, clause 5.1.1, 5.1.2a and 5.1.3a. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.1.1]
1> if the Random Access procedure was initiated for SpCell beam failure recovery (as specified in clause 5.17) and if the contention-free Random Access Resources for beam failure recovery request for 4-step RA type have been explicitly provided by RRC for the BWP selected for Random Access procedure; or
1> if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 4-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure:
2> set the RA_TYPE to 4-stepRA.
1> else if the BWP selected for Random Access procedure is configured with both 2-step and 4-step RA type Random Access Resources and the RSRP of the downlink pathloss reference is above msgA-RSRP-Threshold; or
1> if the BWP selected for Random Access procedure is only configured with 2-step RA type Random Access resources (i.e. no 4-step RACH RA type resources configured); or
1> if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure:
2> set the RA_TYPE to 2-stepRA.
1> else:
2> set the RA_TYPE to 4-stepRA.
1> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
1> if RA_TYPE is set to 2-stepRA:
2> perform the Random Access Resource selection procedure for 2-step RA type (see clause 5.1.2a).
1> else:
2> perform the Random Access Resource selection procedure (see clause 5.1.2).
[TS 38.321, clause 5.1.2a]
If the selected RA_TYPE is set to 2-stepRA, the MAC entity shall:
1> if the contention-free 2-step RA type Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above msgA-RSRP-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
1> else (i.e. for the contention-based Random Access Preamble selection):
2> if at least one of the SSBs with SS-RSRP above msgA-RSRP-ThresholdSSB is available:
3> select an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB.
2> else:
3> select any SSB.
2> if contention-free Random Access Resources for 2-step RA type have not been configured and if Random Access Preambles group has not yet been selected during the current Random Access procedure:
3> if Random Access Preambles group B for 2-step RA type is configured:
4> if the potential MSGA payload size (UL data available for transmission plus MAC subheader and, where required, MAC CEs) is greater than the ra-MsgA-SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) – msgA-PreambleReceivedTargetPower – msgA-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-MsgA-SizeGroupA:
5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else if contention-free Random Access Resources for 2-step RA type have been configured and if Random Access Preambles group has not yet been selected during the current Random Access procedure:
3> if Random Access Preambles group B for 2-step RA type is configured; and
3> if the transport block size of the MSGA payload configured in the rach-ConfigDedicated corresponds to the transport block size of the MSGA payload associated with Random Access Preambles group B:
4> select the Random Access Preambles group B.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Random Access preambles group has been selected during the current Random Access procedure):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the earlier transmission of MSGA.
2> select a Random Access Preamble randomly with equal probability from the 2-step RA type Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group;
2> set the PREAMBLE_INDEX to the selected Random Access Preamble.
1> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the msgA-SSB-SharedRO-MaskIndex if configured and ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability among the consecutive PRACH occasions allocated for 2-step RA type according to clause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB);
1> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
2> select a PUSCH occasion from the PUSCH occasions configured in msgA-CFRA-PUSCH corresponding to the PRACH slot of the selected PRACH occasion, according to msgA-PUSCH-resource-Index corresponding to the selected SSB;
2> determine the UL grant and the associated HARQ information for the MSGA payload in the selected PUSCH occasion;
2> deliver the UL grant and the associated HARQ information to the HARQ entity.
1> else:
2> select a PUSCH occasion corresponding to the selected preamble and PRACH occasion according to clause 8.1A of TS 38.213 [6];
2> determine the UL grant for the MSGA payload according to the PUSCH configuration associated with the selected Random Access Preambles group and determine the associated HARQ information;
2> if the selected preamble and PRACH occasion is mapped to a valid PUSCH occasion as specified in clause 8.1A of TS 38.213 [6]:
3> deliver the UL grant and the associated HARQ information to the HARQ entity.
1> perform the MSGA transmission procedure (see clause 5.1.3a).
NOTE: To determine if there is an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB, the UE uses the latest unfiltered L1-RSRP measurement.
[TS 38.321, clause 5.1.3a]
The MAC entity shall, for each MSGA:
1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if LBT failure indication was not received from lower layers for the last MSGA Random Access Preamble transmission; and
1> if SSB selected is not changed from the selection in the last Random Access Preamble transmission:
2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.
1> select the value of DELTA_PREAMBLE according to clause 7.3;
1> set PREAMBLE_RECEIVED_TARGET_POWER to msgA-PreambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
1> if this is the first MSGA transmission within this Random Access procedure:
2> if the transmission is not being made for the CCCH logical channel:
3> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
2> if the Random Access procedure was initiated for SpCell beam failure recovery and spCell-BFR-CBRA with value true is configured:
3> indicate to the Multiplexing and assembly entity to include a BFR MAC CE or a Truncated BFR MAC CE in the subsequent uplink transmission.
2> obtain the MAC PDU to transmit from the Multiplexing and assembly entity according to the HARQ information determined for the MSGA payload (see clause 5.1.2a) and store it in the MSGA buffer.
1> compute the MSGB-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the MSGA using the selected PRACH occasion and the associated PUSCH resource of MSGA (if the selected preamble and PRACH occasion is mapped to a valid PUSCH occasion), using the corresponding RA-RNTI, MSGB-RNTI, PREAMBLE_INDEX, PREAMBLE_RECEIVED_TARGET_POWER, msgA-PreambleReceivedTargetPower, and the amount of power ramping applied to the latest MSGA preamble transmission (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
7.1.1.1.7.3 Test description
7.1.1.1.7.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.1.7.3.2 Test procedure sequence
Table 7.1.1.1.7.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0A |
SS transmits an RRCReconfiguration message to configure both 2-Step and 4-Step RA type Random Access Resources. Note 1 |
<– |
RRCReconfiguration |
– |
– |
0B |
The UE transmits RRCReconfigurationComplete message. Note 2 |
–> |
RRCReconfigurationComplete |
– |
– |
1 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T1 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC Control Element) |
– |
– |
2 |
40 to 50 TTI before Timer_T1 expires the SS transmits a MAC PDU containing a PDCP SDU |
<– |
MAC PDU |
– |
– |
3 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
4 |
Check: Does the UE MSGA using the selected PRACH occasion and the associated PUSCH resource of MSGA |
–> |
MAC PDU (including C-RNTI MAC CE) |
1 |
P |
5 |
SS schedules PDCCH transmission for UE C_RNTI and DL MAC PDU containing Absolute Timing Advance Command MAC CE. |
<– |
MAC PDU(Absolute Timing Advance Command MAC Control Element) |
– |
– |
6 |
SS transmits an RRCReconfiguration message to configure only 2-Step RA type Random Access Resources. Note 1 |
<– |
RRCReconfiguration |
– |
– |
7 |
The UE transmits RRCReconfigurationComplete message. Note 2 |
–> |
RRCReconfigurationComplete |
– |
– |
8 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T1 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC Control Element) |
– |
– |
9 |
40 to 50 TTI before Timer_T1 expires the SS transmits a MAC PDU containing a PDCP SDU |
<– |
MAC PDU |
– |
– |
10 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
11 |
Check: Does the UE MSGA using the selected PRACH occasion and the associated PUSCH resource of MSGA |
–> |
MAC PDU (including C-RNTI MAC CE) |
2 |
P |
12 |
SS schedules PDCCH transmission for UE C_RNTI and DL MAC PDU containing Absolute Timing Advance Command MAC CE. |
<– |
MAC PDU(Absolute Timing Advance Command MAC Control Element) |
– |
– |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.1.7.3.3 Specific message contents
Table 7.1.1.1.7.3.3-1: RRCReconfiguration for EN-DC (steps 0A and 6, Table 7.1.1.1.7.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 with condition EN-DC_HO. |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.7.3.3-1A: RRCReconfiguration for NR/5GC (steps 0A and 6, Table 7.1.1.1.7.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
radioBearerConfig |
RadioBearerConfig as per TS 38.508-1[4] Table 4.6.3-132 with conditions DRBn and Recover_PDCP |
n set to the default DRB of the first PDU session |
NR |
rrcReconfiguration ::= SEQUENCE { |
|||
nonCriticalExtension SEQUENCE { |
|||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.7.3.3-2: CellGroupConfig for EN-DC (Table 7.1.1.1.7.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PSCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
reconfigurationWithSync SEQUENCE { |
|||
rach-ConfigDedicated CHOICE { |
|||
uplink |
Not present |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.7.3.3-2A: CellGroupConfig for NR/5GC (Table 7.1.1.1.7.3.3-1A)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
rach-ConfigDedicated CHOICE { |
|||
uplink |
Not present |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.7.3.3-3: ServingCellConfigCommon (Table 7.1.1.1.7.3.3-2 and Table 7.1.1.1.7.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.1.7.3.3-4: BWP-UplinkCommon (Table 7.1.1.1.7.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
Step 0A |
|
Not present |
Step 6 |
||
} |
|||
msgA-ConfigCommon-r16 CHOICE { |
|||
setup |
MsgA-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.7.3.3-5: RACH-ConfigCommon (Table 7.1.1.1.7.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
ssb_perRACH_OccasionAndCB_PreamblesPerSSB CHOICE { |
|||
one |
n36 |
||
} |
|||
prach-RootSequenceIndex CHOICE { |
|||
l139 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
||
l839 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
PRACH Preamble format 0 used |
FR1, |
} |
|||
} |
Table 7.1.1.1.7.3.3-6: MsgA-ConfigCommon (Table 7.1.1.1.7.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81A |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-ConfigCommonL-r16 ::= SEQUENCE { |
|||
rach-ConfigCommonTwoStepRA-r16 |
RACH-ConfigCommonTwoStepRA |
||
msgA-PUSCH-Config-r16 |
MsgA-PUSCH-Config |
||
} |
Table 7.1.1.1.7.3.3-7: TDD-UL-DL-ConfigCommon (Table 7.1.1.1.7.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 SCS 30 |
|
ms5 |
FR1 SCS 15 |
||
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 SCS 30 |
|
1 |
FR1 SCS 15 |
||
3 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 SCS 30 |
|
10 |
FR1 SCS 15 |
||
10 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 SCS 30 |
|
1 |
FR1 SCS 15 |
||
1 |
FR2 |
||
nrofUplinkSymbols |
4 |
FR1 SCS 30 |
|
2 |
FR1 SCS 15 |
||
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 SCS 30 or FR1 SCS 15 |
|
} |
|||
pattern2 |
Not present |
||
pattern2 SEQUENCE { |
FR1 SCS 30 or FR1 SCS 15 |
||
dl-UL-TransmissionPeriodicity |
ms2 |
||
nrofDownlinkSlots |
4 |
FR1 SCS 30 |
|
2 |
FR1 SCS 15 |
||
nrofDownlinkSymbols |
0 |
||
nrofUplinkSlots |
0 |
||
nrofUplinkSymbols |
0 |
||
} |
|||
} |
Table 7.1.1.1.7.3.3-8: RACH-ConfigCommonTwoStepRA (Table 7.1.1.1.7.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommonTwoStepRA-r16 ::= SEQUENCE { |
|||
msgA-RSRP-Threshold-r16 |
57 |
-100 dBm |
Table 7.1.1.1.7.3.3-9: MsgA-PUSCH-Config (Table 7.1.1.1.7.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81B |
7.1.1.1.8 Correct selection of RACH parameters / 2-step RACH/MSGA and PRACH resource explicitly signalled to the UE by RRC / contention free random access procedure
7.1.1.1.8.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected }
ensure that {
when { SS sends an RRCReconfiguration message including RACH-ConfigDedicated information element and the contention-free Random Access Resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated }
then { UE SET RA_TYPE to 2-step AND sends a MSGA on the NR PSCell }
}
(2)
with { UE in RRC_Connected state after transmission of a MSGA on NR SpCell received in RACH-ConfigDedicated on the target cell }
ensure that {
when { UE does not receive a matching MSGB in msgB-ResponseWindow and PREAMBLE_TRANSMISSION_COUNTER is less than msgA-TransMax + 1 }
then { UE retransmits a MSGA in RACH-ConfigDedicated on the target cell }
}
7.1.1.1.8.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321, clause 5.1.1, 5.1.2a, 5.1.3a and 5.1.4a. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.1.1]
1> if the Random Access procedure was initiated for SpCell beam failure recovery (as specified in clause 5.17) and if the contention-free Random Access Resources for beam failure recovery request for 4-step RA type have been explicitly provided by RRC for the BWP selected for Random Access procedure; or
1> if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 4-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure:
2> set the RA_TYPE to 4-stepRA.
1> else if the BWP selected for Random Access procedure is configured with both 2-step and 4-step RA type Random Access Resources and the RSRP of the downlink pathloss reference is above msgA-RSRP-Threshold; or
1> if the BWP selected for Random Access procedure is only configured with 2-step RA type Random Access resources (i.e. no 4-step RACH RA type resources configured); or
1> if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure:
2> set the RA_TYPE to 2-stepRA.
1> else:
2> set the RA_TYPE to 4-stepRA.
1> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
1> if RA_TYPE is set to 2-stepRA:
2> perform the Random Access Resource selection procedure for 2-step RA type (see clause 5.1.2a).
1> else:
2> perform the Random Access Resource selection procedure (see clause 5.1.2).
[TS 38.321, clause 5.1.2a]
If the selected RA_TYPE is set to 2-stepRA, the MAC entity shall:
1> if the contention-free 2-step RA type Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above msgA-RSRP-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
1> else (i.e. for the contention-based Random Access Preamble selection):
2> if at least one of the SSBs with SS-RSRP above msgA-RSRP-ThresholdSSB is available:
3> select an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB.
2> else:
3> select any SSB.
2> if contention-free Random Access Resources for 2-step RA type have not been configured and if Random Access Preambles group has not yet been selected during the current Random Access procedure:
3> if Random Access Preambles group B for 2-step RA type is configured:
4> if the potential MSGA payload size (UL data available for transmission plus MAC subheader and, where required, MAC CEs) is greater than the ra-MsgA-SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) – msgA-PreambleReceivedTargetPower – msgA-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-MsgA-SizeGroupA:
5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else if contention-free Random Access Resources for 2-step RA type have been configured and if Random Access Preambles group has not yet been selected during the current Random Access procedure:
3> if Random Access Preambles group B for 2-step RA type is configured; and
3> if the transport block size of the MSGA payload configured in the rach-ConfigDedicated corresponds to the transport block size of the MSGA payload associated with Random Access Preambles group B:
4> select the Random Access Preambles group B.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Random Access preambles group has been selected during the current Random Access procedure):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the earlier transmission of MSGA.
2> select a Random Access Preamble randomly with equal probability from the 2-step RA type Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group;
2> set the PREAMBLE_INDEX to the selected Random Access Preamble.
1> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the msgA-SSB-SharedRO-MaskIndex if configured and ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability among the consecutive PRACH occasions allocated for 2-step RA type according to clause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB);
1> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
2> select a PUSCH occasion from the PUSCH occasions configured in msgA-CFRA-PUSCH corresponding to the PRACH slot of the selected PRACH occasion, according to msgA-PUSCH-resource-Index corresponding to the selected SSB;
2> determine the UL grant and the associated HARQ information for the MSGA payload in the selected PUSCH occasion;
2> deliver the UL grant and the associated HARQ information to the HARQ entity.
1> else:
2> select a PUSCH occasion corresponding to the selected preamble and PRACH occasion according to clause 8.1A of TS 38.213 [6];
2> determine the UL grant for the MSGA payload according to the PUSCH configuration associated with the selected Random Access Preambles group and determine the associated HARQ information;
2> if the selected preamble and PRACH occasion is mapped to a valid PUSCH occasion as specified in clause 8.1A of TS 38.213 [6]:
3> deliver the UL grant and the associated HARQ information to the HARQ entity.
1> perform the MSGA transmission procedure (see clause 5.1.3a).
NOTE: To determine if there is an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB, the UE uses the latest unfiltered L1-RSRP measurement.
[TS 38.321, clause 5.1.3a]
The MAC entity shall, for each MSGA:
1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if LBT failure indication was not received from lower layers for the last MSGA Random Access Preamble transmission; and
1> if SSB selected is not changed from the selection in the last Random Access Preamble transmission:
2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.
1> select the value of DELTA_PREAMBLE according to clause 7.3;
1> set PREAMBLE_RECEIVED_TARGET_POWER to msgA-PreambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
1> if this is the first MSGA transmission within this Random Access procedure:
2> if the transmission is not being made for the CCCH logical channel:
3> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
2> if the Random Access procedure was initiated for SpCell beam failure recovery and spCell-BFR-CBRA with value true is configured:
3> indicate to the Multiplexing and assembly entity to include a BFR MAC CE or a Truncated BFR MAC CE in the subsequent uplink transmission.
2> obtain the MAC PDU to transmit from the Multiplexing and assembly entity according to the HARQ information determined for the MSGA payload (see clause 5.1.2a) and store it in the MSGA buffer.
1> compute the MSGB-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the MSGA using the selected PRACH occasion and the associated PUSCH resource of MSGA (if the selected preamble and PRACH occasion is mapped to a valid PUSCH occasion), using the corresponding RA-RNTI, MSGB-RNTI, PREAMBLE_INDEX, PREAMBLE_RECEIVED_TARGET_POWER, msgA-PreambleReceivedTargetPower, and the amount of power ramping applied to the latest MSGA preamble transmission (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
[TS 38.321, clause 5.1.4a]
Once the MSGA preamble is transmitted, regardless of the possible occurrence of a measurement gap, the MAC entity shall:
1> start the msgB-ResponseWindow at the PDCCH occasion as specified in TS 38.213 [6], clause 8.2A;
1> monitor the PDCCH of the SpCell for a Random Access Response identified by MSGB-RNTI while the msgB-ResponseWindow is running;
1> if C-RNTI MAC CE was included in the MSGA:
2> monitor the PDCCH of the SpCell for Random Access Response identified by the C-RNTI while the msgB-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission of the SpCell is received from lower layers:
2> if the C-RNTI MAC CE was included in MSGA:
3> if the Random Access procedure was initiated for SpCell beam failure recovery (as specified in clause 5.17) and the PDCCH transmission is addressed to the C-RNTI:
4> consider this Random Access Response reception successful;
4> stop the msgB-ResponseWindow;
4> consider this Random Access procedure successfully completed.
3> else if the timeAlignmentTimer associated with the PTAG is running:
4> if the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission:
5> consider this Random Access Response reception successful;
5> stop the msgB-ResponseWindow;
5> consider this Random Access procedure successfully completed.
3> else:
4> if a downlink assignment has been received on the PDCCH for the C-RNTI and the received TB is successfully decoded:
5> if the MAC PDU contains the Absolute Timing Advance Command MAC CE:
6> process the received Timing Advance Command (see clause 5.2);
6> consider this Random Access Response reception successful;
6> stop the msgB-ResponseWindow;
6> consider this Random Access procedure successfully completed and finish the disassembly and demultiplexing of the MAC PDU.
2> if a valid (as specified in TS 38.213 [6]) downlink assignment has been received on the PDCCH for the MSGB-RNTI and the received TB is successfully decoded:
3> if the MSGB contains a MAC subPDU with Backoff Indicator:
4> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
3> else:
4> set the PREAMBLE_BACKOFF to 0 ms.
3> if the MSGB contains a fallbackRAR MAC subPDU; and
3> if the Random Access Preamble identifier in the MAC subPDU matches the transmitted PREAMBLE_INDEX (see clause 5.1.3a):
4> consider this Random Access Response reception successful;
4> apply the following actions for the SpCell:
5> process the received Timing Advance Command (see clause 5.2);
5> indicate the msgA-PreambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
5> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
6> consider the Random Access procedure successfully completed;
6> process the received UL grant value and indicate it to the lower layers.
5> else:
6> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
6> if the Msg3 buffer is empty:
7> obtain the MAC PDU to transmit from the MSGA buffer and store it in the Msg3 buffer;
6> process the received UL grant value and indicate it to the lower layers and proceed with Msg3 transmission.
NOTE: If within a 2-step RA type procedure, an uplink grant provided in the fallback RAR has a different size than the MSGA payload, the UE behaviour is not defined.
3> else if the MSGB contains a successRAR MAC subPDU; and
3> if the CCCH SDU was included in the MSGA and the UE Contention Resolution Identity in the MAC subPDU matches the CCCH SDU:
4> stop msgB-ResponseWindow;
4> if this Random Access procedure was initiated for SI request:
5> indicate the reception of an acknowledgement for SI request to upper layers.
4> else:
5> set the C-RNTI to the value received in the successRAR;
5> apply the following actions for the SpCell:
6> process the received Timing Advance Command (see clause 5.2);
6> indicate the msgA-PreambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP).
4> deliver the TPC, PUCCH resource Indicator, ChannelAccess-CPext (if indicated), and HARQ feedback Timing Indicator received in successRAR to lower layers.
4> consider this Random Access Response reception successful;
4> consider this Random Access procedure successfully completed;
4> finish the disassembly and demultiplexing of the MAC PDU.
1> if msgB-ResponseWindow expires, and the Random Access Response Reception has not been considered as successful based on descriptions above:
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> indicate a Random Access problem to upper layers;
3> if this Random Access procedure was triggered for SI request:
4> consider this Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> if msgA-TransMax is applied (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1:
4> set the RA_TYPE to 4-stepRA;
4> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
4> if the Msg3 buffer is empty:
5> obtain the MAC PDU to transmit from the MSGA buffer and store it in the Msg3 buffer;
4> flush HARQ buffer used for the transmission of MAC PDU in the MSGA buffer;
4> discard explicitly signalled contention-free 2-step RA type Random Access Resources, if any;
4> perform the Random Access Resource selection procedure as specified in clause 5.1.2.
3> else:
4> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
4> if the criteria (as defined in clause 5.1.2a) to select contention-free Random Access Resources is met during the backoff time:
5> perform the Random Access Resource selection procedure for 2-step RA type Random Access (see clause 5.1.2a).
4> else:
5> perform the Random Access Resource selection procedure for 2-step RA type Random Access (see clause 5.1.2a) after the backoff time.
Upon receiving a fallbackRAR, the MAC entity may stop msgB-ResponseWindow once the Random Access Response reception is considered as successful.
7.1.1.1.8.3 Test description
7.1.1.1.8.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Test loop function(Off).
7.1.1.1.8.3.2 Test procedure sequence
Table 7.1.1.1.8.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits an RRCReconfiguration message with reconfiguration with sync and contention-free Random Access Resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated. Note 1 |
<– |
RRCReconfiguration |
– |
– |
– |
Exception: Steps 2 to 3 are run msgA-TransMax times |
– |
– |
– |
– |
2 |
The UE transmits MSGA including RRCReconfigurationComplete message using the Random Access Resources for 2-step RA type explicitly provided. Note 2 |
–> |
MAC PDU (including C-RNTI MAC CE,RRCReconfigurationComplete) |
1,2 |
P |
3 |
SS does not schedulePDCCH transmission for UE C_RNTI until msgB-ResponseWindow expires |
– |
– |
– |
– |
4 |
The UE transmits MSGA including RRCReconfigurationComplete message using the Random Access Resources for 2-step RA type explicitly provided. Note 2 |
–> |
MAC PDU (including C-RNTI MAC CE,RRCReconfigurationComplete) |
2 |
P |
6 |
SS schedules PDCCH transmission for UE C_RNTI and DL MAC PDU containing Absolute Timing Advance Command MAC CE. |
<– |
MAC PDU(Absolute Timing Advance Command MAC Control Element) |
– |
– |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete and sent in E-UTRA cell. In NR Cell a MAC PDU containing C-RNTI MAC CE is sent. |
7.1.1.1.8.3.3 Specific message contents
Table 7.1.1.1.8.3.3-1: RRCReconfiguration for EN-DC (steps 1, Table 7.1.1.1.8.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 with condition EN-DC_HO. |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.8.3.3-1A: RRCReconfiguration for NR/5GC (steps 0A and 6, Table 7.1.1.1.8.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
radioBearerConfig |
RadioBearerConfig as per TS 38.508-1[4] Table 4.6.3-132 with conditions DRBn and Recover_PDCP |
n set to the default DRB of the first PDU session |
NR |
rrcReconfiguration ::= SEQUENCE { |
|||
nonCriticalExtension SEQUENCE { |
|||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.8.3.3-2: CellGroupConfig for EN-DC (Table 7.1.1.1.8.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PSCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
reconfigurationWithSync SEQUENCE { |
|||
rach-ConfigDedicated CHOICE { |
|||
uplink |
RACH-ConfigDedicated |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.8.3.3-2A: CellGroupConfig for NR/5GC (Table 7.1.1.1.8.3.3-1A)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
rach-ConfigDedicated CHOICE { |
|||
uplink |
RACH-ConfigDedicated |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.8.3.3-3: RACH-ConfigDedicated (Table 7.1.1.1.8.3.3-2 and Table 7.1.1.1.8.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-129 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
cfra-TwoStep-r16 SEQUENCE { |
|||
occasionsTwoStepRA-r16 SEQUENCE { |
|||
rach-ConfigGenericTwoStepRA-r16 |
RACH-ConfigGenericTwoStepRA |
||
ssb-PerRACH-OccasionTwoStepRA-r16 |
|||
} |
|||
msgA-CFRA-PUSCH-r16 |
MsgA-PUSCH-Resource |
||
msgA-TransMax-r16 |
N10 |
||
resourcesTwoStep-r16 SEQUENCE { |
|||
ssb-ResourceList SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource { |
|||
ssb |
0 |
||
ra-PreambleIndex |
52 |
Randomly selected |
|
msgA-PUSCH-Resource-Index-r16 |
Not present |
||
} |
|||
ra-ssb-OccasionMaskIndex |
0 |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.8.3.3-4: RACH-ConfigGeneric (Table 7.1.1.1.8.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-129 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
prach-ConfigurationIndex |
14 |
FR1 |
|
149 |
FR2 |
||
zeroCorrelationZoneConfig |
12 |
FR1 |
|
15 |
FR2 |
||
} |
Table 7.1.1.1.8.3.3-5: RACH-ConfigGenericTwoStepRA (Table 7.1.1.1.8.3.3-3 and Table 7.1.1.1.8.3.3-3A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
msgA-PRACH-ConfigurationIndex-r16 |
Not present |
||
msgA-RO-FDM-r16 |
Not present |
||
msgA-RO-FrequencyStart-r16 |
Not present |
||
msgA-ZeroCorrelationZoneConfig-r16 |
Not present |
||
msgA-PreamblePowerRampingStep-r16 |
Not present |
||
msgA-PreambleReceivedTargetPower-r16 |
Not present |
||
} |
Table 7.1.1.1.8.3.3-6: ServingCellConfigCommon (Table 7.1.1.1.8.3.3-2 and Table 7.1.1.1.8.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.1.8.3.3-7: BWP-UplinkCommon (Table 7.1.1.1.8.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
msgA-ConfigCommon-r16 CHOICE { |
|||
setup |
MsgA-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.8.3.3-8: RACH-ConfigCommon (Table 7.1.1.1.8.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
ssb_perRACH_OccasionAndCB_PreamblesPerSSB CHOICE { |
|||
one |
n36 |
||
} |
|||
prach-RootSequenceIndex CHOICE { |
|||
l139 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
||
l839 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
PRACH Preamble format 0 used |
FR1, |
} |
|||
} |
Table 7.1.1.1.8.3.3-9: MsgA-ConfigCommon (Table 7.1.1.1.8.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81A |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-ConfigCommonL-r16 ::= SEQUENCE { |
|||
rach-ConfigCommonTwoStepRA-r16 |
RACH-ConfigCommonTwoStepRA |
||
msgA-PUSCH-Config-r16 |
MsgA-PUSCH-Config |
||
} |
Table 7.1.1.1.8.3.3-10: TDD-UL-DL-ConfigCommon (Table 7.1.1.1.8.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 SCS 30 |
|
ms5 |
FR1 SCS 15 |
||
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 SCS 30 |
|
1 |
FR1 SCS 15 |
||
3 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 SCS 30 |
|
10 |
FR1 SCS 15 |
||
10 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 SCS 30 |
|
1 |
FR1 SCS 15 |
||
1 |
FR2 |
||
nrofUplinkSymbols |
4 |
FR1 SCS 30 |
|
2 |
FR1 SCS 15 |
||
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 SCS 30 or FR1 SCS 15 |
|
} |
|||
pattern2 |
Not present |
||
pattern2 SEQUENCE { |
FR1 SCS 30 or FR1 SCS 15 |
||
dl-UL-TransmissionPeriodicity |
ms2 |
||
nrofDownlinkSlots |
4 |
FR1 SCS 30 |
|
2 |
FR1 SCS 15 |
||
nrofDownlinkSymbols |
0 |
||
nrofUplinkSlots |
0 |
||
nrofUplinkSymbols |
0 |
||
} |
|||
} |
Table 7.1.1.1.8.3.3-11: RACH-ConfigCommonTwoStepRA (Table 7.1.1.1.8.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommonTwoStepRA-r16 ::= SEQUENCE { |
|||
msgA-RSRP-Threshold-r16 |
87 |
-70 dBm |
Table 7.1.1.1.8.3.3-12: MsgA-PUSCH-Config (Table 7.1.1.1.8.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81B |
7.1.1.1.9 Random access procedure / Successful / 2-step RACH/C-RNTI Based / Preamble selected by MAC itself
7.1.1.1.9.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state after NR SpCell TimeAlignmentTimer expired, and has UL Data to send }
ensure that {
when { the UL MAC PDU Size is less than ra-MsgA-SizeGroupA }
then { UE transmits a MSGA using a preamble in group A of random access preambles }
}
(2)
with { UE in RRC_Connected state after transmission of a MSGA on NR SpCell }
ensure that {
when { SS does not answer with a matching MSGB within msgB-ResponseWindow }
then { UE retransmits a MSGA using a preamble from same group }
}
(3)
with { UE in RRC_Connected state after transmission of a MSGA on NR SpCell }
ensure that {
when { SS sends a MSGB including a Backoff Indicator and the Random Access Preamble identifier is different from the value received from UE }
then { UE performs the Random Access Resource selection procedure for 2-step RA type Random Access after a random time between 0 and the indicated Backoff parameter from same group }
}
(4)
with { UE in RRC_Connected state after NR SpCell TimeAlignmentTimer expired, and has UL Data to send }
ensure that {
when { the UL MAC PDU Size is greater than messageSizeGroupA }
then { UE transmits a MSGA using a preamble in group B of random access preambles }
}
(5)
with { UE in RRC_Connected state and having initiated a 2-step RA type Random Access procedure in NR SpCell }
ensure that {
when { SS transmits a Timing Advance Command in a MSGB message }
then { UE applies the received Timing Advance value in the next transmitted MAC PDU }
}
7.1.1.1.9.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38,321, clause 5.1.2a, 5.1.3a, 5.1.4a, 5.1.5 and 5.2. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.1.2a]
If the selected RA_TYPE is set to 2-stepRA, the MAC entity shall:
1> if the contention-free 2-step RA type Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above msgA-RSRP-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE_INDEX to a ra-PreambleIndex corresponding to the selected SSB.
1> else (i.e. for the contention-based Random Access Preamble selection):
2> if at least one of the SSBs with SS-RSRP above msgA-RSRP-ThresholdSSB is available:
3> select an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB.
2> else:
3> select any SSB.
2> if contention-free Random Access Resources for 2-step RA type have not been configured and if Random Access Preambles group has not yet been selected during the current Random Access procedure:
3> if Random Access Preambles group B for 2-step RA type is configured:
4> if the potential MSGA payload size (UL data available for transmission plus MAC subheader and, where required, MAC CEs) is greater than the ra-MsgA-SizeGroupA and the pathloss is less than PCMAX (of the Serving Cell performing the Random Access Procedure) – msgA-PreambleReceivedTargetPower – msgA-DeltaPreamble – messagePowerOffsetGroupB; or
4> if the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC subheader is greater than ra-MsgA-SizeGroupA:
5> select the Random Access Preambles group B.
4> else:
5> select the Random Access Preambles group A.
3> else:
4> select the Random Access Preambles group A.
2> else if contention-free Random Access Resources for 2-step RA type have been configured and if Random Access Preambles group has not yet been selected during the current Random Access procedure:
3> if Random Access Preambles group B for 2-step RA type is configured; and
3> if the transport block size of the MSGA payload configured in the rach-ConfigDedicated corresponds to the transport block size of the MSGA payload associated with Random Access Preambles group B:
4> select the Random Access Preambles group B.
3> else:
4> select the Random Access Preambles group A.
2> else (i.e. Random Access preambles group has been selected during the current Random Access procedure):
3> select the same group of Random Access Preambles as was used for the Random Access Preamble transmission attempt corresponding to the earlier transmission of MSGA.
2> select a Random Access Preamble randomly with equal probability from the 2-step RA type Random Access Preambles associated with the selected SSB and the selected Random Access Preambles group;
2> set the PREAMBLE_INDEX to the selected Random Access Preamble.
1> determine the next available PRACH occasion from the PRACH occasions corresponding to the selected SSB permitted by the restrictions given by the msgA-SSB-SharedRO-MaskIndex if configured and ra-ssb-OccasionMaskIndex if configured (the MAC entity shall select a PRACH occasion randomly with equal probability among the consecutive PRACH occasions allocated for 2-step RA type according to clause 8.1 of TS 38.213 [6], corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH occasion corresponding to the selected SSB);
1> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
2> select a PUSCH occasion from the PUSCH occasions configured in msgA-CFRA-PUSCH corresponding to the PRACH slot of the selected PRACH occasion, according to msgA-PUSCH-resource-Index corresponding to the selected SSB;
2> determine the UL grant and the associated HARQ information for the MSGA payload in the selected PUSCH occasion;
2> deliver the UL grant and the associated HARQ information to the HARQ entity.
1> else:
2> select a PUSCH occasion corresponding to the selected preamble and PRACH occasion according to clause 8.1A of TS 38.213 [6];
2> determine the UL grant for the MSGA payload according to the PUSCH configuration associated with the selected Random Access Preambles group and determine the associated HARQ information;
2> if the selected preamble and PRACH occasion is mapped to a valid PUSCH occasion as specified in clause 8.1A of TS 38.213 [6]:
3> deliver the UL grant and the associated HARQ information to the HARQ entity.
1> perform the MSGA transmission procedure (see clause 5.1.3a).
NOTE: To determine if there is an SSB with SS-RSRP above msgA-RSRP-ThresholdSSB, the UE uses the latest unfiltered L1-RSRP measurement.
[TS 38.321, clause 5.1.3a]
The MAC entity shall, for each MSGA:
1> if PREAMBLE_TRANSMISSION_COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if LBT failure indication was not received from lower layers for the last MSGA Random Access Preamble transmission; and
1> if SSB selected is not changed from the selection in the last Random Access Preamble transmission:
2> increment PREAMBLE_POWER_RAMPING_COUNTER by 1.
1> select the value of DELTA_PREAMBLE according to clause 7.3;
1> set PREAMBLE_RECEIVED_TARGET_POWER to msgA-PreambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP;
1> if this is the first MSGA transmission within this Random Access procedure:
2> if the transmission is not being made for the CCCH logical channel:
3> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
2> if the Random Access procedure was initiated for SpCell beam failure recovery and spCell-BFR-CBRA with value true is configured:
3> indicate to the Multiplexing and assembly entity to include a BFR MAC CE or a Truncated BFR MAC CE in the subsequent uplink transmission.
2> obtain the MAC PDU to transmit from the Multiplexing and assembly entity according to the HARQ information determined for the MSGA payload (see clause 5.1.2a) and store it in the MSGA buffer.
1> compute the MSGB-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the MSGA using the selected PRACH occasion and the associated PUSCH resource of MSGA (if the selected preamble and PRACH occasion is mapped to a valid PUSCH occasion), using the corresponding RA-RNTI, MSGB-RNTI, PREAMBLE_INDEX, PREAMBLE_RECEIVED_TARGET_POWER, msgA-PreambleReceivedTargetPower, and the amount of power ramping applied to the latest MSGA preamble transmission (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
1> if LBT failure indication is received from lower layers for the transmission of this MSGA Random Access Preamble:
2> instruct the physical layer to cancel the transmission of the MSGA payload on the associated PUSCH resource;
2> if lbt-FailureRecoveryConfig is configured:
3> perform the Random Access Resource selection procedure for 2-step RA type (see clause 5.1.2a).
2> else:
3> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
3> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
4> indicate a Random Access problem to upper layers;
4> if this Random Access procedure was triggered for SI request:
5> consider this Random Access procedure unsuccessfully completed.
3> if the Random Access procedure is not completed:
4> if msgA-TransMax is applied (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1:
5> set the RA_TYPE to 4-stepRA;
5> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
5> if the Msg3 buffer is empty:
6> obtain the MAC PDU to transmit from the MSGA buffer and store it in the Msg3 buffer;
5> flush HARQ buffer used for the transmission of MAC PDU in the MSGA buffer;
5> discard explicitly signalled contention-free 2-step RA type Random Access Resources, if any;
5> perform the Random Access Resource selection procedure as specified in clause 5.1.2.
4> else:
5> perform the Random Access Resource selection procedure for 2-step RA type (see clause 5.1.2a).
NOTE: The MSGA transmission includes the transmission of the PRACH Preamble as well as the contents of the MSGA buffer in the PUSCH resource corresponding to the selected PRACH occasion and PREAMBLE_INDEX (see TS 38.213 [6])
The MSGB-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted, is computed as:
MSGB-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id + 14 × 80 × 8 × 2
where s_id is the index of the first OFDM symbol of the PRACH occasion (0 ≤ s_id < 14), t_id is the index of the first slot of the PRACH occasion in a system frame (0 ≤ t_id < 80), where the subcarrier spacing to determine t_id is based on the value of μ specified in clause 5.3.2 in TS 38.211 [8], f_id is the index of the PRACH occasion in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Random Access Preamble transmission (0 for NUL carrier, and 1 for SUL carrier). The RA-RNTI is calculated as specified in clause 5.1.3.
[TS 38.321, clause 5.1.4a]
Once the MSGA preamble is transmitted, regardless of the possible occurrence of a measurement gap, the MAC entity shall:
1> start the msgB-ResponseWindow at the PDCCH occasion as specified in TS 38.213 [6], clause 8.2A;
1> monitor the PDCCH of the SpCell for a Random Access Response identified by MSGB-RNTI while the msgB-ResponseWindow is running;
1> if C-RNTI MAC CE was included in the MSGA:
2> monitor the PDCCH of the SpCell for Random Access Response identified by the C-RNTI while the msgB-ResponseWindow is running.
1> if notification of a reception of a PDCCH transmission of the SpCell is received from lower layers:
2> if the C-RNTI MAC CE was included in MSGA:
3> if the Random Access procedure was initiated for SpCell beam failure recovery (as specified in clause 5.17) and the PDCCH transmission is addressed to the C-RNTI:
4> consider this Random Access Response reception successful;
4> stop the msgB-ResponseWindow;
4> consider this Random Access procedure successfully completed.
3> else if the timeAlignmentTimer associated with the PTAG is running:
4> if the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission:
5> consider this Random Access Response reception successful;
5> stop the msgB-ResponseWindow;
5> consider this Random Access procedure successfully completed.
3> else:
4> if a downlink assignment has been received on the PDCCH for the C-RNTI and the received TB is successfully decoded:
5> if the MAC PDU contains the Absolute Timing Advance Command MAC CE:
6> process the received Timing Advance Command (see clause 5.2);
6> consider this Random Access Response reception successful;
6> stop the msgB-ResponseWindow;
6> consider this Random Access procedure successfully completed and finish the disassembly and demultiplexing of the MAC PDU.
2> if a valid (as specified in TS 38.213 [6]) downlink assignment has been received on the PDCCH for the MSGB-RNTI and the received TB is successfully decoded:
3> if the MSGB contains a MAC subPDU with Backoff Indicator:
4> set the PREAMBLE_BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING_FACTOR_BI.
3> else:
4> set the PREAMBLE_BACKOFF to 0 ms.
3> if the MSGB contains a fallbackRAR MAC subPDU; and
3> if the Random Access Preamble identifier in the MAC subPDU matches the transmitted PREAMBLE_INDEX (see clause 5.1.3a):
4> consider this Random Access Response reception successful;
4> apply the following actions for the SpCell:
5> process the received Timing Advance Command (see clause 5.2);
5> indicate the msgA-PreambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP);
5> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
6> consider the Random Access procedure successfully completed;
6> process the received UL grant value and indicate it to the lower layers.
5> else:
6> set the TEMPORARY_C-RNTI to the value received in the Random Access Response;
6> if the Msg3 buffer is empty:
7> obtain the MAC PDU to transmit from the MSGA buffer and store it in the Msg3 buffer;
6> process the received UL grant value and indicate it to the lower layers and proceed with Msg3 transmission.
NOTE: If within a 2-step RA type procedure, an uplink grant provided in the fallback RAR has a different size than the MSGA payload, the UE behaviour is not defined.
3> else if the MSGB contains a successRAR MAC subPDU; and
3> if the CCCH SDU was included in the MSGA and the UE Contention Resolution Identity in the MAC subPDU matches the CCCH SDU:
4> stop msgB-ResponseWindow;
4> if this Random Access procedure was initiated for SI request:
5> indicate the reception of an acknowledgement for SI request to upper layers.
4> else:
5> set the C-RNTI to the value received in the successRAR;
5> apply the following actions for the SpCell:
6> process the received Timing Advance Command (see clause 5.2);
6> indicate the msgA-PreambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP).
4> deliver the TPC, PUCCH resource Indicator, ChannelAccess-CPext (if indicated), and HARQ feedback Timing Indicator received in successRAR to lower layers.
4> consider this Random Access Response reception successful;
4> consider this Random Access procedure successfully completed;
4> finish the disassembly and demultiplexing of the MAC PDU.
1> if msgB-ResponseWindow expires, and the Random Access Response Reception has not been considered as successful based on descriptions above:
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> indicate a Random Access problem to upper layers;
3> if this Random Access procedure was triggered for SI request:
4> consider this Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> if msgA-TransMax is applied (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1:
4> set the RA_TYPE to 4-stepRA;
4> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
4> if the Msg3 buffer is empty:
5> obtain the MAC PDU to transmit from the MSGA buffer and store it in the Msg3 buffer;
4> flush HARQ buffer used for the transmission of MAC PDU in the MSGA buffer;
4> discard explicitly signalled contention-free 2-step RA type Random Access Resources, if any;
4> perform the Random Access Resource selection procedure as specified in clause 5.1.2.
3> else:
4> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
4> if the criteria (as defined in clause 5.1.2a) to select contention-free Random Access Resources is met during the backoff time:
5> perform the Random Access Resource selection procedure for 2-step RA type Random Access (see clause 5.1.2a).
4> else:
5> perform the Random Access Resource selection procedure for 2-step RA type Random Access (see clause 5.1.2a) after the backoff time.
Upon receiving a fallbackRAR, the MAC entity may stop msgB-ResponseWindow once the Random Access Response reception is considered as successful.
[TS 38.321, clause 5.1.5]
Once Msg3 is transmitted the MAC entity shall:
1> start the ra-ContentionResolutionTimer and restart the ra-ContentionResolutionTimer at each HARQ retransmission in the first symbol after the end of the Msg3 transmission;
1> monitor the PDCCH while the ra-ContentionResolutionTimer is running regardless of the possible occurrence of a measurement gap;
1> if notification of a reception of a PDCCH transmission of the SpCell is received from lower layers:
2> if the C-RNTI MAC CE was included in Msg3:
3> if the Random Access procedure was initiated for SpCell beam failure recovery (as specified in clause 5.17) and the PDCCH transmission is addressed to the C-RNTI; or
3> if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is addressed to the C-RNTI; or
3> if the Random Access procedure was initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission:
4> consider this Contention Resolution successful;
4> stop ra-ContentionResolutionTimer;
4> discard the TEMPORARY_C-RNTI;
4> consider this Random Access procedure successfully completed.
2> else if the CCCH SDU was included in Msg3 and the PDCCH transmission is addressed to its TEMPORARY_C-RNTI:
3> if the MAC PDU is successfully decoded:
4> stop ra-ContentionResolutionTimer;
4> if the MAC PDU contains a UE Contention Resolution Identity MAC CE; and
4> if the UE Contention Resolution Identity in the MAC CE matches the CCCH SDU transmitted in Msg3:
5> consider this Contention Resolution successful and finish the disassembly and demultiplexing of the MAC PDU;
5> if this Random Access procedure was initiated for SI request:
6> indicate the reception of an acknowledgement for SI request to upper layers.
5> else:
6> set the C-RNTI to the value of the TEMPORARY_C-RNTI;
5> discard the TEMPORARY_C-RNTI;
5> consider this Random Access procedure successfully completed.
4> else:
5> discard the TEMPORARY_C-RNTI;
5> consider this Contention Resolution not successful and discard the successfully decoded MAC PDU.
1> if ra-ContentionResolutionTimer expires:
2> discard the TEMPORARY_C-RNTI;
2> consider the Contention Resolution not successful.
1> if the Contention Resolution is considered not successful:
2> flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer;
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> indicate a Random Access problem to upper layers.
3> if this Random Access procedure was triggered for SI request:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> if the RA_TYPE is set to 4-stepRA:
4> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
4> if the criteria (as defined in clause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
5> perform the Random Access Resource selection procedure (see clause 5.1.2);
4> else:
5> perform the Random Access Resource selection procedure (see clause 5.1.2) after the backoff time.
3> else (i.e. the RA_TYPE is set to 2-stepRA):
4> if msgA-TransMax is applied (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1:
5> set the RA_TYPE to 4-stepRA;
5> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
5> flush HARQ buffer used for the transmission of MAC PDU in the MSGA buffer;
5> discard explicitly signalled contention-free 2-step RA type Random Access Resources, if any;
5> perform the Random Access Resource selection as specified in clause 5.1.2.
4> else:
5> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
5> if the criteria (as defined in clause 5.1.2a) to select contention-free Random Access Resources is met during the backoff time:
6> perform the Random Access Resource selection procedure for 2-step RA type as specified in clause 5.1.2a.
5> else:
6> perform the Random Access Resource selection for 2-step RA type procedure (see clause 5.1.2a) after the backoff time.
[TS 38.321, clause 5.2]
RRC configures the following parameters for the maintenance of UL time alignment:
– timeAlignmentTimer (per TAG) which controls how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned.
The MAC entity shall:
1> when a Timing Advance Command MAC CE is received, and if an NTA (as defined in TS 38.211 [8]) has been maintained with the indicated TAG:
2> apply the Timing Advance Command for the indicated TAG;
2> start or restart the timeAlignmentTimer associated with the indicated TAG.
1> when a Timing Advance Command is received in a Random Access Response message for a Serving Cell belonging to a TAG or in a MSGB for an SpCell:
2> if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble:
3> apply the Timing Advance Command for this TAG;
3> start or restart the timeAlignmentTimer associated with this TAG.
2> else if the timeAlignmentTimer associated with this TAG is not running:
3> apply the Timing Advance Command for this TAG;
3> start the timeAlignmentTimer associated with this TAG;
3> when the Contention Resolution is considered not successful as described in clause 5.1.5; or
3> when the Contention Resolution is considered successful for SI request as described in clause 5.1.5, after transmitting HARQ feedback for MAC PDU including UE Contention Resolution Identity MAC CE:
4> stop timeAlignmentTimer associated with this TAG.
2> else:
3> ignore the received Timing Advance Command.
1> when an Absolute Timing Advance Command is received in response to a MSGA transmission including C-RNTI MAC CE as specified in clause 5.1.4a:
2> apply the Timing Advance Command for PTAG;
2> start or restart the timeAlignmentTimer associated with PTAG.
1> when a timeAlignmentTimer expires:
2> if the timeAlignmentTimer is associated with the PTAG:
3> flush all HARQ buffers for all Serving Cells;
3> notify RRC to release PUCCH for all Serving Cells, if configured;
3> notify RRC to release SRS for all Serving Cells, if configured;
3> clear any configured downlink assignments and configured uplink grants;
3> clear any PUSCH resource for semi-persistent CSI reporting;
3> consider all running timeAlignmentTimers as expired;
3> maintain NTA (defined in TS 38.211 [8]) of all TAGs.
2> else if the timeAlignmentTimer is associated with an STAG, then for all Serving Cells belonging to this TAG:
3> flush all HARQ buffers;
3> notify RRC to release PUCCH, if configured;
3> notify RRC to release SRS, if configured;
3> clear any configured downlink assignments and configured uplink grants;
3> clear any PUSCH resource for semi-persistent CSI reporting;
3> maintain NTA (defined in TS 38.211 [8]) of this TAG.
When the MAC entity stops uplink transmissions for an SCell due to the fact that the maximum uplink transmission timing difference between TAGs of the MAC entity or the maximum uplink transmission timing difference between TAGs of any MAC entity of the UE is exceeded, the MAC entity considers the timeAlignmentTimer associated with the SCell as expired.
The MAC entity shall not perform any uplink transmission on a Serving Cell except the Random Access Preamble and MSGA transmission when the timeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running. Furthermore, when the timeAlignmentTimer associated with the PTAG is not running, the MAC entity shall not perform any uplink transmission on any Serving Cell except the Random Access Preamble and MSGA transmission on the SpCell.
7.1.1.1.9.3 Test description
7.1.1.1.9.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.1.9.3.2 Test procedure sequence
Table 7.1.1.1.9.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1 is performed IF pc_NG_RAN_NR only. |
– |
– |
– |
– |
1 |
The SS transmits an updated system information as specified in Table 7.1.1.1.9.3.3-2. |
– |
– |
– |
– |
2 |
SS transmits an RRCReconfiguration message to configure 2-Step and RA type Random Access Resources. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
3 |
The UE transmits RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
4 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T1 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC CE) |
– |
– |
5 |
40 to 50 TTI before Timer_T1 expires the SS transmits a MAC PDU containing a PDCP SDU of size 56 bits, less than ra-MsgA-SizeGroupA (208 bits) on SpCell. (Note 3) |
<– |
MAC PDU |
– |
– |
6 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
7 |
Check: Does the UE transmit MSGA using preamble on PRACH in group A? |
–> |
MAC PDU (including C-RNTI MAC CE) |
1 |
P |
8 |
Check: Does the UE re-transmit MSGA using a preamble on PRACH in the same group A after expiry of msgB-ResponseWindow? |
–> |
MAC PDU (including C-RNTI MAC CE) |
2 |
P |
9 |
The SS transmits a MSGB with the Backoff parameter set to value Index field ’12’ and with the RAPID different from the value received from the UE. The SS sets Timer_T2 to the Backoff value ‘960’ associated with the Index value ‘12’ and starts Timer_T2. |
<– |
MAC PDU(BI, RAPID) |
– |
– |
10 |
Check: Does UE transmit MSGA using preamble on PRACH in group A while Timer_T2 is running? |
–> |
MAC PDU (including C-RNTI MAC CE) |
3 |
P |
11 |
The SS schedules PDCCH transmission for UE C_RNTI and DL MAC PDU containing Absolute Timing Advance Command MAC CE. |
<– |
MAC PDU(Absolute Timing Advance Command MAC CE) |
– |
– |
– |
EXCEPTION: Step 12 is performed IF pc_NG_RAN_NR only. |
– |
– |
– |
– |
12 |
The SS transmits an updated system information as specified in Table 7.1.1.1.9.3.3-2. |
– |
– |
– |
– |
13 |
SS transmits an RRCReconfiguration message to configure 2-Step RA type Random Access Resources. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
14 |
The UE transmits RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
15 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T3 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC CE) |
– |
– |
16 |
40 to 50 TTI before Timer_T3 expires the SS transmits a MAC PDU containing a PDCP SDU of size 256 bits, more than ra-MsgA-SizeGroupA (208 bits) on SpCell. (Note 4) |
<– |
MAC PDU |
– |
– |
17 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
18 |
Check: Does the UE transmit MSGA using preamble on PRACH in group B? |
–> |
MAC PDU (including C-RNTI MAC CE) |
4 |
P |
19 |
SS schedules PDCCH transmission for UE C_RNTI and DL MAC PDU containing Timing Advance Command MAC CE. |
<– |
MAC PDU(Timing Advance Command MAC CE) |
– |
– |
20 |
Check: Does the UE transmits a MAC PDU with C-RNTI containing looped back PDCP SDU using the new Timing Advance value? |
–> |
MAC PDU |
5 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: MAC PDU size of 56bits is selected to allow UE send status PDU and stays below the limit of ra-MsgA-SizeGroupA. Note 4: MAC PDU size of 256bits is selected to allow UE send status PDU and stays above the limit of ra-MsgA-SizeGroupA. |
7.1.1.1.9.3.3 Specific message contents
Table 7.1.1.1.9.3.3-1: MAC-CellGroupConfig (preamble)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-68 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
tag-Config SEQUENCE { |
|||
tag-ToAddModList SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG { |
1 entry |
||
TAG[1] SEQUENCE { |
entry 1 |
||
timeAlignmentTimer |
ms750 |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.9.3.3-2: SIB1S (steps 1 and 12, Table 7.1.1.1.9.3.2-1)
Derivation path: TS 38.508-1 [4] Table 4.6.1-28 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
servingCellConfigCommon |
ServingCellConfigCommon |
||
} |
Table 7.1.1.1.9.3.3-3: ServingCellConfigCommon (Table 7.1.1.1.9.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
} |
Table 7.1.1.1.9.3.3-4: BWP-UplinkCommon (Table 7.1.1.1.9.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-14 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
msgA-ConfigCommon-r16 CHOICE { |
|||
setup |
MsgA-ConfigCommon-r16 |
||
} |
|||
} |
Table 7.1.1.1.9.3.3-5: MsgA-ConfigCommon-r16 (Table 7.1.1.1.9.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81A |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-ConfigCommon-r16 :: = SEQUENCE { |
|||
rach-ConfigCommonTwoStepRA-r16 |
RACH-ConfigCommonTwoStepRA-r16 |
||
msgA-PUSCH-Config-r16 |
MsgA-PUSCH-Config-r16 |
||
} |
Table 7.1.1.1.9.3.3-6: RACH-ConfigCommonTwoStepRA-r16 (Table 7.1.1.1.9.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommonTwoStepRA-r16 ::= SEQUENCE { |
|||
rach-ConfigGenericTwoStepRA-r16 |
RACH-ConfigGenericTwoStepRA-r16 |
||
msgA-TotalNumberOfRA-Preambles-r16 |
8 |
||
msgA-SSB-PerRACH-OccasionAndCB-PreamblesPerSSB-r16 CHOICE { |
|||
two |
n4 |
||
} |
|||
groupB-ConfiguredTwoStepRA-r16 |
GroupB-ConfiguredTwoStepRA-r16 |
||
msgA-PRACH-RootSequenceIndex-r16 CHOICE { |
|||
l839 |
100 |
||
} |
|||
msgA-TransMax-r16 |
n4 |
||
msgA-RSRP-ThresholdSSB-r16 |
56 |
||
msgA-RestrictedSetConfig-r16 |
unrestrictedSet |
||
ra-PrioritizationForAccessIdentityTwoStep-r16 SEQUENCE { |
|||
ra-Prioritization-r16 |
RA-Prioritization |
TS 38.508-1 [4], Table 4.6.3-131 |
|
ra-PrioritizationForAI-r16 |
‘00’B |
||
} |
|||
ra-ContentionResolutionTimer-r16 |
sf32 |
||
} |
Table 7.1.1.1.9.3.3-7: RACH-ConfigGenericTwoStepRA-r16 (Table 7.1.1.1.9.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigGenericTwoStepRA-r16 ::= SEQUENCE { |
|||
msgA-PRACH-ConfigurationIndex-r16 |
0 |
||
msgA-RO-FDM-r16 |
one |
||
msgA-RO-FrequencyStart-r16 |
0 |
||
msgA-ZeroCorrelationZoneConfig-r16 |
0 |
||
msgA-PreamblePowerRampingStep-r16 |
dB2 |
||
msgA-PreambleReceivedTargetPower-r16 |
-200 |
||
msgB-ResponseWindow-r16 |
sl80 |
||
preambleTransMax-r16 |
n4 |
||
} |
Table 7.1.1.1.9.3.3-8: GroupB-ConfiguredTwoStepRA-r16 (Table 7.1.1.1.9.3.3-6)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
GroupB-ConfiguredTwoStepRA-r16 ::= SEQUENCE { |
|||
ra-MsgA-SizeGroupA |
b208 |
||
messagePowerOffsetGroupB |
minusinfinity |
||
numberOfRA-PreamblesGroupA |
8 |
||
} |
Table 7.1.1.1.9.3.3-9: MsgA-PUSCH-Config-r16 (Table 7.1.1.1.9.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81B |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-PUSCH-Config-r16 ::= SEQUENCE { |
|||
msgA-PUSCH-ResourceGroupA-r16 |
MsgA-PUSCH-Resource-r16 |
||
msgA-PUSCH-ResourceGroupB-r16 |
MsgA-PUSCH-Resource-r16 |
||
} |
Table 7.1.1.1.9.3.3-10: MsgA-PUSCH-Resource-r16 (Table 7.1.1.1.9.3.3-9)
Derivation Path: TS 38.331 [6] ,clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-PUSCH-Resource-r16 ::= SEQUENCE { |
|||
msgA-MCS-r16 |
0 |
||
nrofSlotsMsgA-PUSCH-r16 |
1 |
||
nrofMsgA-PO-PerSlot-r16 |
one |
||
msgA-PUSCH-TimeDomainOffset-r16 |
1 |
||
guardBandMsgA-PUSCH-r16 |
0 |
||
frequencyStartMsgA-PUSCH-r16 |
0 |
||
nrofPRBs-PerMsgA-PO-r16 |
24 |
||
nrofMsgA-PO-FDM-r16 |
one |
||
msgA-DMRS-Config-r16 |
MsgA-DMRS-Config-r16 |
||
nrofDMRS-Sequences-r16 |
1 |
||
} |
Table 7.1.1.1.9.3.3-11: MsgA-DMRS-Config-r16 (Table 7.1.1.1.9.3.3-10)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-DMRS-Config-r16 ::= SEQUENCE { |
|||
msgA-DMRS-AdditionalPosition-r16 |
pos0 |
||
msgA-MaxLength-r16 |
len2 |
||
} |
Table 7.1.1.1.9.3.3-12: RRCReconfiguration (steps 2 and 13, Table 7.1.1.1.9.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.1.9.3.3-13: CellGroupConfig (Table 7.1.1.1.9.3.3-12)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
Same contents as in Table 7.1.1.1.9.3.3-3 |
|
newUE-Identity |
RNTI-Value |
||
t304 |
ms2000 |
||
rach-ConfigDedicated |
Not present |
||
} |
7.1.1.1.10 Random access procedure / 2-step RACH/not complete/ RA_TYPE to 4-stepRA
7.1.1.1.10.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state after transmission of a MSGA on NR SpCell }
ensure that {
when { UE does not receive a matching MSGB in msgB-ResponseWindow and PREAMBLE_TRANSMISSION_COUNTER is equal to msgA-TransMax+1 }
then { UE triggers 4-step RACH procedure on NR SpCell }
}
7.1.1.1.10.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 38.321, clauses 5.1.1, and 5.1.4a.
[TS 38.321, clause5.1.1]
The Random Access procedure described in this clause is initiated by a PDCCH order, by the MAC entity itself, or by RRC for the events in accordance with TS 38.300 [2]. There is only one Random Access procedure ongoing at any point in time in a MAC entity. The Random Access procedure on an SCell shall only be initiated by a PDCCH order with ra-PreambleIndex different from 0b000000.
…
1> if the Random Access procedure is initiated by PDCCH order and if the ra-PreambleIndex explicitly provided by PDCCH is not 0b000000; or
1> if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]) and the Random Access Resources for SI request have been explicitly provided by RRC; or
1> if the Random Access procedure was initiated for SpCell beam failure recovery (as specified in clause 5.17) and if the contention-free Random Access Resources for beam failure recovery request for 4-step RA type have been explicitly provided by RRC for the BWP selected for Random Access procedure; or
1> if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 4-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure:
2> set the RA_TYPE to 4-stepRA.
1> else if the BWP selected for Random Access procedure is configured with both 2-step and 4-step RA type Random Access Resources and the RSRP of the downlink pathloss reference is above msgA-RSRP-Threshold; or
1> if the BWP selected for Random Access procedure is only configured with 2-step RA type Random Access resources (i.e. no 4-step RACH RA type resources configured); or
1> if the Random Access procedure was initiated for reconfiguration with sync and if the contention-free Random Access Resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for Random Access procedure:
2> set the RA_TYPE to 2-stepRA.
1> else:
2> set the RA_TYPE to 4-stepRA.
1> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
1> if RA_TYPE is set to 2-stepRA:
2> perform the Random Access Resource selection procedure for 2-step RA type (see clause 5.1.2a).
1> else:
2> perform the Random Access Resource selection procedure (see clause 5.1.2).
[TS 38.321, clause 5.1.4a]
Once the MSGA preamble is transmitted, regardless of the possible occurrence of a measurement gap, the MAC entity shall:
…
1> if msgB-ResponseWindow expires, and the Random Access Response Reception has not been considered as successful based on descriptions above:
2> increment PREAMBLE_TRANSMISSION_COUNTER by 1;
2> if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
3> indicate a Random Access problem to upper layers;
3> if this Random Access procedure was triggered for SI request:
4> consider this Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> if msgA-TransMax is applied (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax + 1:
4> set the RA_TYPE to 4-stepRA;
4> perform initialization of variables specific to Random Access type as specified in clause 5.1.1a;
4> if the Msg3 buffer is empty:
5> obtain the MAC PDU to transmit from the MSGA buffer and store it in the Msg3 buffer;
4> flush HARQ buffer used for the transmission of MAC PDU in the MSGA buffer;
4> discard explicitly signalled contention-free 2-step RA type Random Access Resources, if any;
4> perform the Random Access Resource selection procedure as specified in clause 5.1.2.
3> else:
4> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE_BACKOFF;
4> if the criteria (as defined in clause 5.1.2a) to select contention-free Random Access Resources is met during the backoff time:
5> perform the Random Access Resource selection procedure for 2-step RA type Random Access (see clause 5.1.2a).
4> else:
5> perform the Random Access Resource selection procedure for 2-step RA type Random Access (see clause 5.1.2a) after the backoff time.
Upon receiving a fallbackRAR, the MAC entity may stop msgB-ResponseWindow once the Random Access Response reception is considered as successful.
7.1.1.1.10.3 Test description
7.1.1.1.10.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.1.10.3.2 Test procedure sequence
Table 7.1.1.1.10.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits an RRCReconfiguration message to configure both 2-Step and 4-Step RA type Random Access Resources. Note 1 |
<– |
RRCReconfiguration |
– |
– |
2 |
The UE transmits RRCReconfigurationComplete message. Note 2 |
–> |
RRCReconfigurationComplete |
– |
– |
3 |
SS transmits Timing Advance command to SpCell. SS does not send any subsequent timing alignments. Start Timer_T1 = Time Alignment timer value on SS. |
<– |
MAC PDU (Timing Advance Command MAC Control Element) |
– |
– |
4 |
40 to 50 TTI before Timer_T1 expires the SS transmits a MAC PDU containing a PDCP SDU |
<– |
MAC PDU |
– |
– |
5 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
– |
Exception: Step 6 will be repeated preambleTransMax times and SS does not response the MSGA in STEP 6, to make PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax+1. |
– |
– |
– |
– |
6 |
The UE transmits MSGA using the selected PRACH occasion and the associated PUSCH resource of MSGA |
–> |
MAC PDU (including C-RNTI MAC CE) |
– |
– |
7 |
Check: Does the UE transmit preamble on PRACH? |
–> |
PRACH Preamble |
1 |
P |
8 |
The SS transmits Random Access Response and RAPID corresponding to the transmitted Preamble in step 7. |
<– |
Random Access Response |
– |
– |
9 |
UE sends a msg3 using the grant associated to the Random Access Response received in step 8 |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
– |
– |
10 |
SS schedules PDCCH transmission for UE C_RNTI and allocate uplink grant. |
<– |
Contention Resolution |
– |
– |
11 |
The UE transmits a MAC PDU with C-RNTI containing looped back PDCP SDU |
–> |
MAC PDU |
– |
– |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.1.10.3.3 Specific message contents
Table 7.1.1.1.10.3.3-1: RRCReconfiguration for EN-DC (step 1, Table 7.1.1.1.10.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 with condition EN-DC_HO. |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.10.3.3-1A: RRCReconfiguration for NR/5GC (step 1, Table 7.1.1.1.10.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
radioBearerConfig |
RadioBearerConfig as per TS 38.508-1[4] Table 4.6.3-132 with conditions DRBn and Recover_PDCP |
n set to the default DRB of the first PDU session |
NR |
rrcReconfiguration ::= SEQUENCE { |
|||
nonCriticalExtension SEQUENCE { |
|||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.1.10.3.3-2: CellGroupConfig for EN-DC (Table 7.1.1.1.10.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PSCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
reconfigurationWithSync SEQUENCE { |
|||
rach-ConfigDedicated CHOICE { |
|||
uplink |
RACH-ConfigDedicated |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.10.3.3-2A: CellGroupConfig for NR/5GC (Table 7.1.1.1.10.3.3-1A)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 with condition PCell_change |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
rach-ConfigDedicated CHOICE { |
|||
uplink |
RACH-ConfigDedicated |
||
} |
|||
newUE-Identity |
UE identity different from NR cell 1 UE identity |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.10.3.3-3: RACH-ConfigDedicated (Table 7.1.1.1.10.3.3-2 and Table 7.1.1.1.10.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-129 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
cfra-TwoStep-r16 SEQUENCE { |
|||
occasionsTwoStepRA-r16 SEQUENCE { |
|||
rach-ConfigGenericTwoStepRA-r16 |
RACH-ConfigGenericTwoStepRA |
||
ssb-PerRACH-OccasionTwoStepRA-r16 |
|||
} |
|||
msgA-CFRA-PUSCH-r16 |
MsgA-PUSCH-Resource |
||
msgA-TransMax-r16 |
N10 |
||
resourcesTwoStep-r16 SEQUENCE { |
|||
ssb-ResourceList SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource { |
|||
ssb |
0 |
||
ra-PreambleIndex |
52 |
Randomly selected |
|
msgA-PUSCH-Resource-Index-r16 |
Not present |
||
} |
|||
ra-ssb-OccasionMaskIndex |
0 |
||
} |
|||
} |
|||
} |
Table 7.1.1.1.10.3.3-4: Void
Table 7.1.1.1.10.3.3-5: RACH-ConfigGenericTwoStepRA (Table 7.1.1.1.10.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigDedicated::= SEQUENCE { |
|||
msgA-PRACH-ConfigurationIndex-r16 |
Not present |
||
msgA-RO-FDM-r16 |
Not present |
||
msgA-RO-FrequencyStart-r16 |
Not present |
||
msgA-ZeroCorrelationZoneConfig-r16 |
Not present |
||
msgA-PreamblePowerRampingStep-r16 |
Not present |
||
msgA-PreambleReceivedTargetPower-r16 |
Not present |
||
} |
Table 7.1.1.1.10.3.3-6: ServingCellConfigCommon (Table 7.1.1.1.10.3.3-2 and Table 7.1.1.1.10.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.1.10.3.3-7: BWP-UplinkCommon (Table 7.1.1.1.10.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
msgA-ConfigCommon-r16 CHOICE { |
|||
setup |
MsgA-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.1.10.3.3-8: RACH-ConfigCommon (Table 7.1.1.1.10.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
ssb_perRACH_OccasionAndCB_PreamblesPerSSB CHOICE { |
|||
one |
n36 |
||
} |
|||
prach-RootSequenceIndex CHOICE { |
|||
l139 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
||
l839 |
Set according to table 4.4.2-2 in TS 38.508-1 [4] for the NR Cell. |
PRACH Preamble format 0 used |
FR1, |
} |
|||
} |
Table 7.1.1.1.10.3.3-9: MsgA-ConfigCommon (Table 7.1.1.1.10.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81A |
|||
Information Element |
Value/remark |
Comment |
Condition |
MsgA-ConfigCommonL-r16 ::= SEQUENCE { |
|||
rach-ConfigCommonTwoStepRA-r16 |
RACH-ConfigCommonTwoStepRA |
||
msgA-PUSCH-Config-r16 |
MsgA-PUSCH-Config |
||
} |
Table 7.1.1.1.10.3.3-10: TDD-UL-DL-ConfigCommon (Table 7.1.1.1.10.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 SCS 30 |
|
ms5 |
FR1 SCS 15 |
||
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 SCS 30 |
|
1 |
FR1 SCS 15 |
||
3 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 SCS 30 |
|
10 |
FR1 SCS 15 |
||
10 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 SCS 30 |
|
1 |
FR1 SCS 15 |
||
1 |
FR2 |
||
nrofUplinkSymbols |
4 |
FR1 SCS 30 |
|
2 |
FR1 SCS 15 |
||
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 SCS 30 or FR1 SCS 15 |
|
} |
|||
pattern2 |
Not present |
||
pattern2 SEQUENCE { |
FR1 SCS 30 or FR1 SCS 15 |
||
dl-UL-TransmissionPeriodicity |
ms2 |
||
nrofDownlinkSlots |
4 |
FR1 SCS 30 |
|
2 |
FR1 SCS 15 |
||
nrofDownlinkSymbols |
0 |
||
nrofUplinkSlots |
0 |
||
nrofUplinkSymbols |
0 |
||
} |
|||
} |
Table 7.1.1.1.10.3.3-11: RACH-ConfigCommonTwoStepRA (Table 7.1.1.1.10.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128A |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommonTwoStepRA-r16 ::= SEQUENCE { |
|||
msgA-RSRP-Threshold-r16 |
57 |
-100 dBm |
Table 7.1.1.1.10.3.3-12: MsgA-PUSCH-Config (Table 7.1.1.1.10.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-81B |
7.1.1.1.11 to 7.1.1.1.15
7.1.1.1.16 Random access procedure / RedCap UE identification / Msg3-based / CCCH1
7.1.1.1.16.1 Test Purpose (TP)
(1)
with { UE supporting RedCap and in NR RRC_Inactive state }
ensure that {
when { UE starts Random Access procedure }
then { the UE uses the RedCap specific LCID in Msg3}
}
7.1.1.1.16.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clause 6.2.1 and TS38.331,clause 5.3.13.3. Unless otherwise stated these are Rel-17 requirements.
[TS 38.321, clause 6.2.1]
Table 6.2.1-2 Values of LCID for UL-SCH
Codepoint/Index |
LCID values |
|
0 |
CCCH of size 64 bits (referred to as "CCCH1" in TS 38.331 [5]), except for a RedCap UE |
|
1–32 |
Identity of the logical channel of DCCH and DTCH |
|
33 |
Extended logical channel ID field (two-octet eLCID field) |
|
34 |
Extended logical channel ID field (one-octet eLCID field) |
|
35 |
CCCH of size 48 bits (referred to as "CCCH" in TS 38.331 [5]) for a RedCap UE |
|
36 |
CCCH of size 64 bits (referred to as "CCCH1" in TS 38.331 [5]) for a RedCap UE |
|
37–42 |
Reserved |
|
43 |
Truncated Enhanced BFR (one octet Ci) |
|
44 |
Timing Advance Report |
|
45 |
Truncated Sidelink BSR |
|
46 |
Sidelink BSR |
|
47 |
Reserved |
|
48 |
LBT failure (four octets) |
|
49 |
LBT failure (one octet) |
|
50 |
BFR (one octet Ci) |
|
51 |
Truncated BFR (one octet Ci) |
|
52 |
CCCH of size 48 bits (referred to as "CCCH" in TS 38.331 [5]), except for a RedCap UE |
|
53 |
Recommended bit rate query |
|
54 |
Multiple Entry PHR (four octets Ci) |
|
55 |
Configured Grant Confirmation |
|
56 |
Multiple Entry PHR (one octet Ci) |
|
57 |
Single Entry PHR |
|
58 |
C-RNTI |
|
59 |
Short Truncated BSR |
|
60 |
Long Truncated BSR |
|
61 |
Short BSR |
|
62 |
Long BSR |
|
63 |
Padding |
[TS 38.331, clause 5.3.13.3]
The UE shall set the contents of RRCResumeRequest or RRCResumeRequest1 message as follows:
1> if field useFullResumeID is signalled in SIB1:
2> select RRCResumeRequest1 as the message to use;
2> set the resumeIdentity to the stored fullI-RNTI value;
7.1.1.1.16.3 Test description
7.1.1.1.16.3.1 Pre-test conditions
System Simulator:
– NR Cell 1.
UE:
– None
Preamble:
– The UE is in 2N-A state on NR Cell 1 using generic procedure parameter Connectivity (NR) and Test loop function(Off) according to TS 38.508-1 [4].
7.1.1.1.16.3.2 Test procedure sequence
Table 7.1.1.1.16.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS changes the SIB1 of NR Cell 1 to set the useFullResumeID to True. |
– |
– |
– |
– |
2 |
The SS transmits a Short message on PDCCH using P-RNTI indicating a systemInfoModification. |
<– |
PDCCH (DCI 1_0): Short Message |
– |
– |
3 |
Wait for 2.1* modification period second for the UE to receive new system information. (Note 1) |
– |
– |
– |
– |
4 |
The SS transmits a Paging message including a matched identity (correct fullI-RNTI). |
<– |
NR RRC: Paging |
– |
– |
5 |
Check: Does the UE transmit an RRCResumeRequest1 message by setting LCID to 36? |
–> |
NR RRC: RRCResumeRequest1 |
1 |
P |
6 |
The SS transmits an RRCResume message. |
<– |
NR RRC: RRCResume |
– |
– |
7 |
The UE transmits an RRCResumeComplete message. |
–> |
NR RRC: RRCResumeComplete |
– |
– |
Note 1: The modification period, expressed in number of radio frames = modificationPeriodCoeff * defaultPagingCycle. |
7.1.1.1.16.3.3 Specific message contents
Table 7.1.1.1.16.3.3-1: SIB1 (step 1, Table 7.1.1.1.16.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
useFullResumeID |
true |
||
} |
Table 7.1.1.1.16.3.3-2: Paging (step 4, Table 7.1.1.1.16.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-9 with condition NR_RRC_RESUME |
7.1.1.1.17 Random access procedure / RedCap UE identification / Msg1-based
7.1.1.1.17.1 Test Purpose (TP)
(1)
with { UE supporting RedCap and in NR RRC_IDLE state }
ensure that {
when { UE starts Random Access procedure }
then { the UE uses the RedCap specific random access resource in Msg1}
}
7.1.1.1.17.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clauses 5.1.1, 5.1.1b, 5.1.1c and 5.1.1d. Unless otherwise stated these are Rel-17 requirements.
[TS 38.321, clause 5.1.1]
…
When a Random Access procedure is initiated, UE selects a set of Random Access resources as specified in clause 5.1.1b and initialises the following parameters for the Random Access procedure according to the values configured by RRC for the selected set of Random Access resources:
…
– featurePriorities: priorities for features, such as REDCAP, Slice group(s), etc. (see clause 5.1.1d);
…
– startPreambleForThisPartition: the first preamble associated with the set of Random Access Resources applicable to the Random Access procedure;
…
– numberOfPreamblesForThisPartition: the number of consequtive preambles associated with the set of Random Access Resources applicable to the Random Access procedure;
…
When the Random Access procedure is initiated on a Serving Cell, the MAC entity shall:
…
1> perform the BWP operation as specified in clause 5.15;
1> select the set of Random Access resources applicable to the current Random Access procedure according to clause 5.1.1b;
…
[TS 38.321, clause 5.1.1b]
The MAC entity shall:
…
1> if contention-free Random Access Resources have not been provided for this Random Access procedure and one or more of the features including REDCAP and/or a specific slice group(s) and/or SDT and/or MSG3 repetition is applicable for this Random Access procedure:
Editor’s Note: FFS if some clarification is needed on how feature applicability is known (e.g. from RRC etc)
2> if none of the sets of Random Access resources are available for the current Random Access procedure (as specified in clause 5.1.1c):
3> select the set of Random Access resources that are not associated with any feature indication (as specified in clause 5.1.1c) for this Random Access procedure.
2> else if there are one or more set(s) of Random Access resources available (as specified in clause 5.1.1c) and one of these set(s) of Random Access resources can be used for indicating all features triggering this Random Access procedure:
3> select the available set of Random Access resources for this Random Access procedure.
…
[TS 38.321, clause 5.1.1c]
The MAC entity shall for each set of configured Random Access resources for 4-step RA type and for each set of configured Random Access resources for 2-step RA type:
1> if REDCAP indication is configured for a set of Random Access resources:
2> consider the set of Random Access resources as not available for a RACH procedure for which REDCAP indication is not applicable.
…
[TS 38.321, clause 5.1.1d]
The MAC entity shall:
1> among the available sets of Random Access resources, identify those configured with a feature which has the highest priority assigned in featurePriorities among all the features applicable to this Random Access procedure as specified in TS 38.331 [5].
1> if a single set of Random Access resources is identified:
2> select this set of Random Access resources.
…
7.1.1.1.17.3 Test description
7.1.1.1.17.3.1 Pre-test conditions
System Simulator:
– NR Cell 1.
UE:
– None
Preamble:
– The UE is in 1N-A state on NR Cell 1 using generic procedure parameter Connectivity (NR) and Test loop function(Off) according to TS 38.508-1 [4].
7.1.1.1.17.3.2 Test procedure sequence
Table 7.1.1.1.17.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS changes the SIB1 of NR Cell 1 to configure the specific PRACH resource for RedCap. |
– |
– |
– |
– |
2 |
The SS transmits a Short message on PDCCH using P-RNTI indicating a systemInfoModification. |
<– |
PDCCH (DCI 1_0): Short Message |
– |
– |
3 |
Wait for 2.1* modification period second for the UE to receive new system information. (Note 1) |
– |
– |
– |
– |
4 |
The SS transmits a Paging message including a matched identity. |
<– |
– |
– |
– |
5 |
Check: Does the UE transmits Preamble on PRACH with ra-PreambleIndex range from 8 to 11 on NR Cell 1? |
–> |
PRACH Preamble |
1 |
P |
6 |
The SS transmits Random Access Response with RAPID corresponding to the transmitted Preamble in step 5. |
<– |
Random Access Response |
– |
|
7 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. |
–> |
MAC PDU (RRCSetupRequest) |
– |
– |
8 |
The SS schedules PDCCH transmission addressed to TC-RNTI to transmit a valid MAC PDU containing an RRCSetup message and ‘UE Contention Resolution Identity’ MAC control element with matched ‘Contention Resolution Identity’. |
<– |
MAC PDU (RRCSetup and UE Contention Resolution Identity MAC CE) |
– |
– |
9 |
UE transmit a MAC PDU containing an RRCSetupComplete message indicating acceptance of RRCSetup message |
–> |
MAC PDU (RRCSetupComplete) |
– |
– |
Note 1: The modification period, expressed in number of radio frames = modificationPeriodCoeff * defaultPagingCycle. |
7.1.1.1.17.3.3 Specific message contents
Table 7.1.1.1.17.3.3-1: SIB1 (step 1, Table 7.1.1.1.17.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-28 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
SIB1 ::= SEQUENCE { |
||||
servingCellConfigCommon |
ServingCellConfigCommonSIB |
Table 7.1.1.1.17.3.3-2 |
||
nonCriticalExtension SEQUENCE { |
||||
nonCriticalExtension SEQUENCE { |
||||
nonCriticalExtension SEQUENCE { |
||||
featurePriorities-r17 SEQUENCE { |
||||
redCapPriority-r17 |
0 |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.1.17.3.3-2: ServingCellConfigCommonSIB (Table 7.1.1.1.17.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-169 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommonSIB ::= SEQUENCE { |
|||
uplinkConfigCommon |
UplinkConfigCommonSIB |
Table 7.1.1.1.17.3.3-3 |
|
} |
Table 7.1.1.1.17.3.3-3: UplinkConfigCommonSIB (Table 7.1.1.1.17.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-202 |
|||
Information Element |
Value/remark |
Comment |
Condition |
UplinkConfigCommonSIB ::= SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
Table 7.1.1.1.17.3.3-4 |
|
} |
Table 7.1.1.1.17.3.3-4: BWP-UplinkCommon (Table 7.1.1.1.17.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-14 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
additionalRACH-ConfigList-r17 CHOICE { |
|||
setup SEQUENCE (SIZE(1..maxAdditionalRACH-r17)) OF AdditionalRACH-ConfigCommon-r17 { |
1 entry |
||
AdditionalRACH-Config-r17[1] SEQUENCE { |
entry 1 |
||
rach-ConfigCommon-r17 |
RACH-ConfigCommon |
Table 7.1.1.1.17.3.3-5 |
|
} |
|||
} |
Table 7.1.1.1.17.3.3-5: RACH-ConfigCommon (Table 7.1.1.1.17.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon ::= SEQUENCE { |
|||
ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE { |
|||
one |
n16 |
||
} |
|||
featureCombinationPreamblesList-r17 SEQUENCE (SIZE(1..maxFeatureCombPreamblesPerRACHResource-r17)) OF FeatureCombinationPreambles-r17 { |
1 entry |
||
FeatureCombinationPreambles-r17[1] SEQUENCE { |
entry 1 |
||
featureCombination-r17 SEQUENCE { |
|||
redCap-r17 |
True |
||
} |
|||
startPreambleForThisPartition-r17 |
8 |
||
numberOfPreamblesPerSSB-ForThisPartition-r17 |
4 |
||
} |
|||
} |
|||
} |
7.1.1.1.18 Random access procedure / Msg3 repetition indication / Random access resources selection
Editor’s note: This clause is incomplete. The following aspects are either missing or not yet determined:
– Test description part is FFS
7.1.1.1.18.1 Test Purpose (TP)
(1)
with { UE in RRC_IDLE state and supporting MSG3 repetition }
ensure that {
when { UE is configured both set(s) of Random Access resources with and without MSG3 repetition indication AND the the RSRP of the downlink pathloss reference is less than the configured threshold }
then { UE requests MSG3 repetition via separate RACH resources }
}
(2)
with { UE in RRC_IDLE state and supporting MSG3 repetition }
ensure that {
when { UE is only configured Random Access resources with MSG3 repetition indication }
then { UE requests MSG3 repetition via separate RACH resources }
}
7.1.1.1.18.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.300, clause 19, and TS 38.321 clause 5.1.1b.
[TS 38.300, clause 19]
To improve NR uplink coverage for both FR1 and FR2, the following enhancements on PUSCH, PUCCH and MSG3 PUSCH are supported:
– …
– Aggregation of multiple slots with TB repetition for MSG3 transmission is supported on both NUL and SUL, applicable to CBRA with 4-step RA type. If configured, the UE requests MSG3 repetition via separate RACH resources when the RSRP of DL path-loss reference is lower than a configured threshold. BWP configured with RACH resources solely for MSG3 repetition is also supported without the need to consider the RSRP of DL path-loss reference by the UE.
[TS 38.321, clause 5.1.1b]
The MAC entity shall:
1> if the BWP selected for Random Access procedure is configured with both set(s) of Random Access resources with MSG3 repetition indication and set(s) of Random Access resources without MSG3 repetition indication and the RSRP of the downlink pathloss reference is less than rsrp-ThresholdMsg3; or
1> if the BWP selected for Random Access procedure is only configured with the set(s) of Random Access resources with MSG3 repetition indication;
2> assume MSG3 repetition is applicable for the current Random Access procedure.
1> else:
2> assume MSG3 repetition is not applicable for the current Random Access procedure.
NOTE 1: Void.
1> if contention-free Random Access Resources have not been provided for this Random Access procedure and one or more of the features including RedCap and/or a specific NSAG(s) and/or SDT and/or MSG3 repetition is applicable for this Random Access procedure:
NOTE 2: The applicability of SDT is determined by MAC entity according to clause 5.27. The applicability of specific slice group(s) is determined by upper layers when the Random Access procedure is initiated by the upper layers. The applicability of RedCap is also determined by upper layers when Random Access procedure is initiated and it is applicable to the Random Access procedures initiated by PDCCH orders and any Random Access procedure initiated by the MAC entity.
2> if none of the sets of Random Access resources are available for any feature applicable to the current Random Access procedure (as specified in clause 5.1.1c):
3> select the set(s) of Random Access resources that are not associated with any feature indication (as specified in clause 5.1.1c) for this Random Access procedure.
2> else if there is one set of Random Access resources available which can be used for indicating all features triggering this Random Access procedure:
3> select this set of Random Access resources for this Random Access procedure.
2> else (i.e. there are one or more sets of Random Access resources available that are configured with indication(s) for a subset of all features triggering this Random Access procedure):
3> select a set of Random Access resources from the available set(s) of Random Access resources based on the priority order indicated by upper layers as specified in clause 5.1.1d for this Random Access Procedure.
1> else if contention-free Random Access Resources have been provided for this Random Access procedure and RedCap is applicable for the current Random Access procedure and there is one set of Random Access resources available that is only configured with RedCap indication:
2> select this set of Random Access resources for this Random Access procedure.
1> else:
2> select the set of Random Access resources that are not associated with any feature indication (as specified in clause 5.1.1c) for the current Random Access procedure.
7.1.1.1.18.3 Test description
FFS
7.1.1.2 Downlink Data Transfer
7.1.1.2.1 Correct Handling of DL MAC PDU / Assignment / HARQ process
7.1.1.2.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives downlink assignment on the PDCCH for the UE’s C-RNTI and receives data in the associated Slot and UE performs HARQ operation }
then { UE sends a HARQ feedback on the HARQ process }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { SS transmits downlink assignment on the PDCCH with a C-RNTI unknown by the UE and data is available in the associated Slot }
then { UE does not send any HARQ feedback on the HARQ process }
}
(3)
with { UE in RRC_CONNECTED state }
ensure that {
when { the UE receives a MAC PDU addressed to its C-RNTI and decode fails in the associated Slot }
then { the UE transmits a NACK for the corresponding HARQ process }
}
(4)
with { UE in RRC_CONNECTED state }
ensure that {
when { the UE receives a MAC PDU retransmission addressed to its C-RNTI, and results in successful decode in the associated Slot}
then { the UE transmits an ACK for the corresponding HARQ process and forward to higher layer }
}
(5)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives a MAC PDU containing multiple MAC sub PDUs each containing a MAC SDU that is larger than 256 bytes (16 bits L field used) with padding MAC sub PDU at the end }
then { UE successfully decodes the MAC PDU and forward to higher layer }
}
(6)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives a MAC PDU containing multiple MAC sub PDUs each containing a MAC SDU that is smaller than 256 bytes (8 bits L field used) with padding MAC sub PDU at the end }
then { UE successfully decodes the MAC PDU and forward to higher layer }
}
(7)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives a MAC PDU containing MAC sub PDU containing a MAC SDU and no padding MAC sub PDU}
then { UE successfully decodes the MAC PDU and forward to higher layer }
}
(8)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives a MAC PDU containing MAC sub PDU containing a MAC SDU that is smaller than 256 bytes (8 bits L field used) plus MAC sub PDU containing a MAC SDU that is greater than 256 bytes (16 bits L field used)and no padding }
then { UE successfully decodes the MAC PDU and forwards the AMD PDUs to higher layer }
}
(9)
with { UE in RRC_CONNECTED state and configured with a specific TDD-UL-DL-ConfigCommon including configuration of pattern2}
ensure that {
when { UE receives downlink assignment on the PDCCH associated with pattern2 for the UE’s C-RNTI and receives data in the associated Slot and UE performs HARQ operation }
then { UE sends a HARQ feedback on the HARQ process }
}
7.1.1.2.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.3.1, 5.3.2.1, 5.3.2.2 and 6.1.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.3.1]
Downlink assignments received on the PDCCH both indicate that there is a transmission on a DL-SCH for a particular MAC entity and provide the relevant HARQ information.
When the MAC entity has a C-RNTI, Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion during which it monitors PDCCH and for each Serving Cell:
1> if a downlink assignment for this PDCCH occasion and this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI, or Temporary C‑RNTI:
2> if this is the first downlink assignment for this Temporary C-RNTI:
3> consider the NDI to have been toggled.
2> if the downlink assignment is for the MAC entity’s C-RNTI, and if the previous downlink assignment indicated to the HARQ entity of the same HARQ process was either a downlink assignment received for the MAC entity’s CS-RNTI or a configured downlink assignment:
3> consider the NDI to have been toggled regardless of the value of the NDI.
2> indicate the presence of a downlink assignment and deliver the associated HARQ information to the HARQ entity.
1> else if a downlink assignment for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> indicate the presence of a downlink assignment for this Serving Cell and deliver the associated HARQ information to the HARQ entity.
2> if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate SPS deactivation:
4> clear the configured downlink assignment for this Serving Cell (if any);
4> if the timeAlignmentTimer associated with the PTAG is running:
5> indicate a positive acknowledgement for the SPS deactivation to the physical layer.
3> else if PDCCH content indicates SPS activation:
4> store the downlink assignment for this Serving Cell and the associated HARQ information as configured downlink assignment;
4> initialise or re-initialise the configured downlink assignment for this Serving Cell to start in the associated PDSCH duration and to recur according to rules in subclause 5.8.1;
4> set the HARQ Process ID to the HARQ Process ID associated with this PDSCH duration;
4> consider the NDI bit for the corresponding HARQ process to have been toggled;
4> indicate the presence of a configured downlink assignment for this Serving Cell and deliver the stored HARQ information to the HARQ entity.
For each Serving Cell and each configured downlink assignment, if configured and activated, the MAC entity shall:
1> if the PDSCH duration of the configured downlink assignment does not overlap with the PDSCH duration of a downlink assignment received on the PDCCH for this Serving Cell:
2> instruct the physical layer to receive, in this PDSCH duration, transport block on the DL-SCH according to the configured downlink assignment and to deliver it to the HARQ entity;
2> set the HARQ Process ID to the HARQ Process ID associated with this PDSCH duration;
2> consider the NDI bit to have been toggled;
2> indicate the presence of a configured downlink assignment and deliver the stored HARQ information to the HARQ entity.
For configured downlink assignments, the HARQ Process ID associated with the slot where the DL transmission starts is derived from the following equation:
HARQ Process ID = [floor (CURRENT_slot × 10 / (numberOfSlotsPerFrame × semiPersistSchedIntervalDL))] modulo nrofHARQ-Processes
where CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + slot number in the frame] and numberOfSlotsPerFrame refers to the number of consecutive slots per frame as specified in TS 38.211 [8].
When the MAC entity needs to read BCCH, the MAC entity may, based on the scheduling information from RRC:
1> if a downlink assignment for this PDCCH occasion has been received on the PDCCH for the SI-RNTI;
2> indicate a downlink assignment and redundancy version for the dedicated broadcast HARQ process to the HARQ entity.
[TS 38.321, clause 5.3.2.2]
When a transmission takes place for the HARQ process, one or more (in case of downlink spatial multiplexing) TBs and the associated HARQ information are received from the HARQ entity.
For each received TB and associated HARQ information, the HARQ process shall:
1> if the NDI, when provided, has been toggled compared to the value of the previous received transmission corresponding to this TB; or
1> if the HARQ process is equal to the broadcast process, and this is the first received transmission for the TB according to the system information schedule indicated by RRC; or
1> if this is the very first received transmission for this TB (i.e. there is no previous NDI for this TB):
2> consider this transmission to be a new transmission.
1> else:
2> consider this transmission to be a retransmission.
The MAC entity then shall:
1> if this is a new transmission:
2> attempt to decode the received data.
1> else if this is a retransmission:
2> if the data for this TB has not yet been successfully decoded:
3> instruct the physical layer to combine the received data with the data currently in the soft buffer for this TB and attempt to decode the combined data.
1> if the data which the MAC entity attempted to decode was successfully decoded for this TB; or
1> if the data for this TB was successfully decoded before:
2> if the HARQ process is equal to the broadcast process:
3> deliver the decoded MAC PDU to upper layers.
2> else if this is the first successful decoding of the data for this TB:
3> deliver the decoded MAC PDU to the disassembly and demultiplexing entity.
1> else:
2> instruct the physical layer to replace the data in the soft buffer for this TB with the data which the MAC entity attempted to decode;
1> if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention Resolution is not yet successful (see subclause 5.1.5); or
1> if the HARQ process is equal to the broadcast process; or
1> if the timeAlignmentTimer, associated with the TAG containing the Serving Cell on which the HARQ feedback is to be transmitted, is stopped or expired:
2> not instruct the physical layer to generate acknowledgement(s) of the data in this TB.
1> else:
2> instruct the physical layer to generate acknowledgement(s) of the data in this TB.
The MAC entity shall ignore NDI received in all downlink assignments on PDCCH for its Temporary C-RNTI when determining if NDI on PDCCH for its C-RNTI has been toggled compared to the value in the previous transmission.
[TS 38.321, clause 6.1.2]
A MAC PDU consists of one or more MAC subPDUs. Each MAC subPDU consists of one of the following:
– A MAC subheader only (including padding);
– A MAC subheader and a MAC SDU;
– A MAC subheader and a MAC CE;
– A MAC subheader and padding.
The MAC SDUs are of variable sizes.
Each MAC subheader corresponds to either a MAC SDU, a MAC CE, or padding.
A MAC subheader except for fixed sized MAC CE and padding consists of the four header fields R/F/LCID/L. A MAC subheader for fixed sized MAC CE and padding consists of the two header fields R/LCID.
Figure 6.1.2-1: R/F/LCID/L MAC subheader with 8-bit L field
Figure 6.1.2-2: R/F/LCID/L MAC subheader with 16-bit L field
Figure 6.1.2-3: R/LCID MAC subheader
MAC CEs are placed together. DL MAC subPDU(s) with MAC CE(s) is placed before any MAC subPDU with MAC SDU and MAC subPDU with padding as depicted in Figure 6.1.2-4. UL MAC subPDU(s) with MAC CE(s) is placed after all the MAC subPDU(s) with MAC SDU and before the MAC subPDU with padding in the MAC PDU as depicted in Figure 6.1.2-5. The size of padding can be zero.
Figure 6.1.2-4: Example of a DL MAC PDU
Figure 6.1.2-5: Example of a UL MAC PDU
A maximum of one MAC PDU can be transmitted per TB per MAC entity.
7.1.1.2.1.3 Test description
7.1.1.2.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink and parameters as in Table 7.1.1.2.1.3.1-1.
Table 7.1.1.2.1.3.1-1: MAC Parameters
nrofHARQ-ProcessesForPDSCH |
n16 |
7.1.1.2.1.3.2 Test procedure sequence
Table 7.1.1.2.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits a downlink assignment addressed to the C-RNTI assigned to the UE |
<– |
(PDCCH (C-RNTI)) |
– |
– |
2 |
SS transmits in the indicated downlink assignment a MAC PDU including a RLC PDU with poll bit not set. |
<– |
MAC PDU |
– |
– |
3 |
Check: Does the UE transmit an HARQ ACK on PUCCH? |
–> |
HARQ ACK |
1 |
P |
4 |
SS transmits a downlink assignment to including a C-RNTI different from the assigned to the UE |
<– |
(PDCCH (unknown C-RNTI)) |
– |
– |
5 |
SS transmits in the indicated downlink assignment a RLC PDU in a MAC PDU including a RLC PDU with poll bit not set. |
<– |
MAC PDU |
– |
– |
6 |
Check: Does the UE send any HARQ ACK/NACK on PUCCH? |
–> |
HARQ ACK/NACK |
2 |
F |
– |
EXCEPTION: Steps 7 to 10 are run repeated using test parameter values as given for each iteration in table 7.1.1.2.1.3.2.-2. |
– |
– |
– |
– |
7 |
The SS indicates a new transmission on PDCCH and transmits a MAC PDU including a RLC PDU with poll bit not set, with content set so that UE could not successfully decode the data from its soft buffer. (Note 1) |
<– |
MAC PDU |
– |
– |
8 |
Check: Does the UE transmit a HARQ NACK? |
–> |
HARQ NACK |
3 |
P |
– |
EXCEPTION: Step 9 shall be repeated till HARQ ACK is received at step 10 or until HARQ retransmission count = 4 is reached for MAC PDU at step 9 (Note 2). |
– |
– |
– |
– |
9 |
The SS indicates a retransmission on PDCCH and transmits the same MAC PDU like step 7 (Note 1). |
<– |
MAC PDU |
– |
– |
– |
EXCEPTION: Up to [3] HARQ NACK from the UE should be allowed at step 10 (Note 2). |
– |
– |
– |
– |
10 |
Check: Does the UE send a HARQ ACK? |
–> |
HARQ ACK |
4 |
P |
11 |
The SS transmits a MAC PDU containing three MAC sub PDUs each containing a MAC SDU(RLC PDU) that is of 260 bytes (16 bits L field used) and a padding MAC sub PDU at the end. The third RLC PDU contained will have poll bit set. |
<– |
MAC PDU |
– |
– |
12 |
Check: Does the UE transmit a MAC PDU containing an RLC STATUS PDU acknowledging the reception of all the AMD PDUs in step 11? |
–> |
MAC PDU (RLC STATUS PDU ) |
5 |
P |
13 |
The SS transmits a MAC PDU containing three MAC sub PDUs each containing a MAC SDU(RLC PDU) that is of 128 bytes (8 bits L field used) and a padding MAC sub PDU at the end. The third RLC PDU contained will have poll bit set. |
<– |
MAC PDU |
– |
– |
14 |
Check: Does the UE transmit a MAC PDU containing an RLC STATUS PDU acknowledging the reception of all the AMD PDUs in step 13? |
–> |
MAC PDU (RLC STATUS PDU ) |
6 |
P |
15 |
The SS transmits a MAC PDU containing one MAC sub PDU containing a MAC SDU(RLC PDU) that is of [128] bytes (8 bits L field used) and no padding MAC sub PDU at the end. The RLC PDU contained will have poll bit set. |
<– |
MAC PDU |
– |
– |
16 |
Check: Does the UE transmit a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDU in step 15? |
–> |
MAC PDU (RLC STATUS PDU ) |
7 |
P |
17 |
The SS transmits a MAC PDU containing one MAC sub PDU containing a MAC SDU(RLC PDU) that is of [128] bytes (8 bits L field used), one MAC sub PDU containing a MAC SDU(RLC PDU) that is of [260] bytes (16 bits L field used) and no padding MAC sub PDU at the end. The second RLC PDU contained will have poll bit set. |
<– |
MAC PDU |
– |
– |
18 |
Check: Does the UE transmit a MAC PDU containing an RLC STATUS PDU acknowledging the reception of all the AMD PDUs in step 17? |
–> |
MAC PDU (RLC STATUS PDU ) |
8 |
P |
– |
EXCEPTION : Steps 19a0 to 19a5 are executed for operation on NR TDD band only |
– |
– |
– |
– |
19a0 |
The SS transmits an updated system information as specified in Table 7.1.1.3.1.3.3-14. (Note 5) |
– |
– |
– |
– |
19a1 |
The SS transmits NR RRCReconfiguration message including TDD-UL-DL-ConfigCommon with pattern1 and pattern2 specified in Table 7.1.1.2.1.3.3-5 (Note 3) |
<– |
RRCReconfiguration |
– |
– |
19a2 |
The UE transmits a NR RRCReconfigurationComplete message. (Note 4) |
–> |
RRCReconfigurationComplete |
– |
– |
19a3 |
SS transmits a downlink assignment addressed to the C-RNTI assigned to the UE indicating downlink reception in a symbol in a slot part of pattern2. |
<– |
(PDCCH (C-RNTI)) |
– |
– |
19a4 |
SS transmits in the indicated downlink assignment a MAC PDU including a RLC PDU with poll bit not set. |
<– |
MAC PDU |
– |
– |
19a5 |
Check: Does the UE transmit an HARQ ACK on PUCCH? |
–> |
HARQ ACK |
9 |
P |
Note 1: SS should transmit this PDU so as to ensure at least one NACK. Note 2: The value 4 for the maximum number of HARQ retransmissions has been chosen based on an assumption that, given the radio conditions used in this test case, a UE soft combiner implementation should have sufficient retransmissions to be able to successfully decode the data in its soft buffer. Note 3: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 4: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 5: if pc_NG_RAN_NR only |
Table 7.1.1.2.1.3.2-2: Test Parameters
Iteration |
DL HARQ process (X) |
K=1 to 16 |
X=K-1 |
7.1.1.2.1.3.3 Specific message contents
Table 7.1.1.2.1.3.3-1: Void
Table 7.1.1.2.1.3.3-2: RRCReconfiguration (step19a1, Table 7.1.1.2.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-131 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
|
} |
|||
RRCReconfiguration-v1530-IEs::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.2.1.3.3-3: CellGroupConfig (Table 7.1.1.2.1.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
} |
|||
spCellConfigDedicated |
ServingCellConfig |
||
} |
|||
} |
Table 7.1.1.2.1.3.3-4, 7.1.1.2.1.3.3-13: ServingCellConfigCommon (Table 7.1.1.2.1.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.2.1.3.3-5: TDD-UL-DL-ConfigCommon (Table 7.1.1.2.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 |
|
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 |
|
2 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 |
|
6 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 |
|
2 |
FR2 |
||
nrofUplinkSymbols |
4 |
FR1 |
|
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 |
|
} |
|||
pattern2 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms2 |
FR1 |
|
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
4 |
FR1 |
|
3 |
FR2 |
||
nrofDownlinkSymbols |
0 |
FR1 |
|
6 |
FR2 |
||
nrofUplinkSlots |
0 |
FR1 |
|
1 |
FR2 |
||
nrofUplinkSymbols |
0 |
FR1 |
|
2 |
FR2 |
||
} |
|||
} |
Table 7.1.1.2.1.3.3-6: BWP-UplinkCommon (Table 7.1.1.2.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-14 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.2.1.3.3-7: RACH-ConfigCommon (Table 7.1.1.2.1.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
} |
Table 7.1.1.2.1.3.3-8: RACH-ConfigGeneric (Table 7.1.1.2.1.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigGeneric ::= SEQUENCE { |
|||
prach-configurationIndex |
156 |
||
} |
Table 7.1.1.2.1.3.3-9: ServingCellConfig (Table 7.1.1.2.1.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.2.1.3.3-10: BWP-UplinkDedicated (Table 7.1.1.2.1.3.3-9)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup |
PUCCH-Config |
||
} |
|||
} |
Table 7.1.1.2.1.3.3-11: PUCCH-Config (Table 7.1.1.2.1.3.3-10)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-Config ::= SEQUENCE { |
|||
schedulingRequestResourceToAddModList SEQUENCE (SIZE (1..maxNrofSR-Resources)) OF SchedulingRequestResourceConfig { |
1 entry |
||
SchedulingRequestResourceConfig[1] |
SchedulingRequestResourceConfig |
entry 1 |
|
} |
|||
} |
Table 7.1.1.2.1.3.3-12: SchedulingRequestResourceConfig (Table 7.1.1.2.1.3.3-11)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequestResourceConfig ::= SEQUENCE { |
|||
periodicityAndOffset CHOICE { |
|||
sl10 |
5 |
With SCS = kHz15 results in repetition every 10 ms |
SCS_15kHz |
sl20 |
5 |
With SCS = kHz30 results in repetition every 10 ms |
SCS_30kHz |
sl80 |
5 |
With SCS = kHz120 results in repetition every 10 ms |
SCS_120kHz |
} |
|||
} |
Table 7.1.1.2.1.3.3-13: SystemInformationBlockType1 (step 19a0, Table 7.1.1.2.1.3.2-1)
Derivation path: 38.508-1 [4] table 4.6.1-28 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
servingCellConfigCommon |
ServingCellConfigCommon |
Same contents as in Table 7.1.1.2.1.3.3-5 |
|
} |
7.1.1.2.2 Correct Handling of DL HARQ process PDSCH Aggregation
7.1.1.2.2.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and pdsch-AggregationFactor > 1 }
ensure that {
when { UE receives downlink assignment on the PDCCH for the UE’s C-RNTI and receives data in the associated slot and successive pdsch-AggregationFactor – 1 HARQ retransmissions within a bundle and UE performs HARQ operation }
then { UE sends a HARQ feedback on the HARQ process }
}
7.1.1.2.2.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 38.321, clauses 5.3.1, 5.3.2.1 and 5.3.2.2, TS 38.214, clause 5.1.2.1.
[TS 38.321, clause 5.3.1]
Downlink assignments received on the PDCCH both indicate that there is a transmission on a DL-SCH for a particular MAC entity and provide the relevant HARQ information.
When the MAC entity has a C-RNTI, Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion during which it monitors PDCCH and for each Serving Cell:
1> if a downlink assignment for this PDCCH occasion and this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI, or Temporary C‑RNTI:
2> if this is the first downlink assignment for this Temporary C-RNTI:
3> consider the NDI to have been toggled.
2> if the downlink assignment is for the MAC entity’s C-RNTI, and if the previous downlink assignment indicated to the HARQ entity of the same HARQ process was either a downlink assignment received for the MAC entity’s CS-RNTI or a configured downlink assignment:
3> consider the NDI to have been toggled regardless of the value of the NDI.
2> indicate the presence of a downlink assignment and deliver the associated HARQ information to the HARQ entity.
1> else if a downlink assignment for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> indicate the presence of a downlink assignment for this Serving Cell and deliver the associated HARQ information to the HARQ entity.
2> if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate SPS deactivation:
4> clear the configured downlink assignment for this Serving Cell (if any);
4> if the timeAlignmentTimer associated with the PTAG is running:
5> indicate a positive acknowledgement for the SPS deactivation to the physical layer.
3> else if PDCCH content indicates SPS activation:
4> store the downlink assignment for this Serving Cell and the associated HARQ information as configured downlink assignment;
4> initialise or re-initialise the configured downlink assignment for this Serving Cell to start in the associated PDSCH duration and to recur according to rules in subclause 5.8.1;
4> set the HARQ Process ID to the HARQ Process ID associated with this PDSCH duration;
4> consider the NDI bit for the corresponding HARQ process to have been toggled;
4> indicate the presence of a configured downlink assignment for this Serving Cell and deliver the stored HARQ information to the HARQ entity.
For each Serving Cell and each configured downlink assignment, if configured and activated, the MAC entity shall:
1> if the PDSCH duration of the configured downlink assignment does not overlap with the PDSCH duration of a downlink assignment received on the PDCCH for this Serving Cell:
2> instruct the physical layer to receive, in this PDSCH duration, transport block on the DL-SCH according to the configured downlink assignment and to deliver it to the HARQ entity;
2> set the HARQ Process ID to the HARQ Process ID associated with this PDSCH duration;
2> consider the NDI bit to have been toggled;
2> indicate the presence of a configured downlink assignment and deliver the stored HARQ information to the HARQ entity.
For configured downlink assignments, the HARQ Process ID associated with the slot where the DL transmission starts is derived from the following equation:
HARQ Process ID = [floor (CURRENT_slot × 10 / (numberOfSlotsPerFrame × periodicity))] modulo nrofHARQ-Processes
where CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + slot number in the frame] and numberOfSlotsPerFrame refers to the number of consecutive slots per frame as specified in TS 38.211 [8].
When the MAC entity needs to read BCCH, the MAC entity may, based on the scheduling information from RRC:
1> if a downlink assignment for this PDCCH occasion has been received on the PDCCH for the SI-RNTI;
2> indicate a downlink assignment and redundancy version for the dedicated broadcast HARQ process to the HARQ entity.
[TS 38.321, clause 5.3.2.1]
The MAC entity includes a HARQ entity for each Serving Cell, which maintains a number of parallel HARQ processes. Each HARQ process is associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2).
The number of parallel DL HARQ processes per HARQ entity is specified in TS 38.214 [7]. The dedicated broadcast HARQ process is used for BCCH.
The HARQ process supports one TB when the physical layer is not configured for downlink spatial multiplexing. The HARQ process supports one or two TBs when the physical layer is configured for downlink spatial multiplexing.
When the MAC entity is configured with pdsch-AggregationFactor > 1, the parameter pdsch-AggregationFactor provides the number of transmissions of a TB within a bundle of the dynamic downlink assignment. Bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. After the initial transmission, pdsch-AggregationFactor – 1 HARQ retransmissions follow within a bundle.
The MAC entity shall:
1> if a downlink assignment has been indicated:
2> allocate the TB(s) received from the physical layer and the associated HARQ information to the HARQ process indicated by the associated HARQ information.
1> if a downlink assignment has been indicated for the broadcast HARQ process:
2> allocate the received TB to the broadcast HARQ process.
[TS 38.321, clause 5.3.2.2]
When a transmission takes place for the HARQ process, one or two (in case of downlink spatial multiplexing) TBs and the associated HARQ information are received from the HARQ entity.
For each received TB and associated HARQ information, the HARQ process shall:
1> if the NDI, when provided, has been toggled compared to the value of the previous received transmission corresponding to this TB; or
1> if the HARQ process is equal to the broadcast process, and this is the first received transmission for the TB according to the system information schedule indicated by RRC; or
1> if this is the very first received transmission for this TB (i.e. there is no previous NDI for this TB):
2> consider this transmission to be a new transmission.
1> else:
2> consider this transmission to be a retransmission.
The MAC entity then shall:
1> if this is a new transmission:
2> attempt to decode the received data.
1> else if this is a retransmission:
2> if the data for this TB has not yet been successfully decoded:
3> instruct the physical layer to combine the received data with the data currently in the soft buffer for this TB and attempt to decode the combined data.
1> if the data which the MAC entity attempted to decode was successfully decoded for this TB; or
1> if the data for this TB was successfully decoded before:
2> if the HARQ process is equal to the broadcast process:
3> deliver the decoded MAC PDU to upper layers.
2> else if this is the first successful decoding of the data for this TB:
3> deliver the decoded MAC PDU to the disassembly and demultiplexing entity.
1> else:
2> instruct the physical layer to replace the data in the soft buffer for this TB with the data which the MAC entity attempted to decode.
1> if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention Resolution is not yet successful (see subclause 5.1.5); or
1> if the HARQ process is equal to the broadcast process; or
1> if the timeAlignmentTimer, associated with the TAG containing the Serving Cell on which the HARQ feedback is to be transmitted, is stopped or expired:
2> not instruct the physical layer to generate acknowledgement(s) of the data in this TB.
1> else:
2> instruct the physical layer to generate acknowledgement(s) of the data in this TB.
The MAC entity shall ignore NDI received in all downlink assignments on PDCCH for its Temporary C-RNTI when determining if NDI on PDCCH for its C-RNTI has been toggled compared to the value in the previous transmission.
[TS 38.214, clause 5.1.2.1]
When the UE is scheduled to receive PDSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocation table. The determination of the used resource allocation table is defined in sub-clause 5.1.2.1.1. The indexed row defines the slot offset K0, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PDSCH mapping type to be assumed in the PDSCH reception.
Given the parameter values of the indexed row:
– The slot allocated for the PDSCH is , where n is the slot with the scheduling DCI, and K0 is based on the numerology of PDSCH, and and are the subcarrier spacing configurations for PDSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PDSCH are determined from the start and length indicator SLIV:
if then
else
where, and
– The PDSCH mapping type is set to Type A or Type B as defined in sub-clause 7.4.1.1.2 of [4, TS 38.211].
The UE shall consider the S and L combinations defined in table 5.1.2.1-1 as valid PDSCH allocations:
Table 5.1.2.1-1: Valid S and L combinations
PDSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
{0,1,2,3} (Note 1) |
{3,…,14} |
{3,…,14} |
{0,1,2,3} (Note 1) |
{3,…,12} |
{3,…,12} |
Type B |
{0,…,12} |
{2,4,7} |
{2,…,14} |
{0,…,10} |
{2,4,6} |
{2,…,12} |
Note 1: S = 3 is applicable only if dmrs-TypeA-Position = 3 |
When the UE is configured with aggregationFactorDL > 1, the same symbol allocation is applied across the aggregationFactorDL consecutive slots. The UE may expect that the TB is repeated within each symbol allocation among each of the aggregationFactorDL consecutive slots and the PDSCH is limited to a single transmission layer. The redundancy version to be applied on the nth transmission occasion of the TB is determined according to table 5.1.2.1-2.
Table 5.1.2.1-2: Applied redundancy version when aggregationFactorDL > 1
rvid indicated by the DCI scheduling the PDSCH |
rvid to be applied to nth transmission occasion |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
If the UE procedure for determining slot configuration as defined in Subclause 11.1 of [6, TS 38.213] determines symbol of a slot allocated for PDSCH as uplink symbols, the transmission on that slot is omitted for multi-slot PDSCH transmission.
The UE is not expected to receive a PDSCH with mapping type A in a slot, if the PDCCH scheduling the PDSCH was received in the same slot and was not contained within the first three symbols of the slot.
The UE is not expected to receive a PDSCH with mapping type B in a slot, if the first symbol of the PDCCH scheduling the PDSCH was received in a later symbol than the first symbol indicated in the PDSCH time domain resource allocation.
7.1.1.2.2.3 Test description
7.1.1.2.2.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink and parameters as in Table 7.1.1.2.2.3.1-1.
Table 7.1.1.2.2.3.1-1: Void
7.1.1.2.2.3.2 Test procedure sequence
Table 7.1.1.2.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits in the indicated downlink assignment an NR RRCReconfiguration. (Note 1) |
<– |
– |
– |
– |
2 |
UE transmits NR RRCReconfigurationComplete message to the SS. (Note 2) |
–> |
– |
– |
– |
3 |
The SS transmits a downlink assignment addressed to the C-RNTI assigned to the UE, the rv_idx is 0. |
<– |
– |
– |
– |
4 |
The SS transmits in the indicated downlink assignment a MAC PDU including a RLC PDU, The CRC is calculated in such a way, it will result in CRC error on UE side. |
<– |
MAC PDU |
– |
– |
5 |
In the following 3 consecutive slots, the SS transmits on the same downlink assignment a MAC PDU including a RLC PDU, The CRC is calculated in such a way, it will result in CRC error on UE side. (Note3) |
<– |
MAC PDU |
– |
– |
5A |
Void |
– |
– |
– |
– |
6 |
Check: Does the UE transmit a HARQ NACK on slot n3+k1? (Note 4) |
–> |
HARQ NACK |
1 |
P |
7 |
The SS transmits a downlink assignment addressed to the C-RNTI assigned to the UE, the rv_idx is 0. |
<– |
– |
– |
– |
8 |
The SS transmits in the indicated downlink assignment a MAC PDU including a RLC PDU, The CRC is calculated in such a way, it will result in CRC pass on UE side. |
<– |
MAC PDU |
– |
– |
9 |
In the following 3 consecutive slots, the SS transmits on the same downlink assignment a MAC PDU including a RLC PDU, The CRC is calculated in such a way, it will result in CRC pass on UE side. (Note3) |
<– |
MAC PDU |
– |
– |
10 |
Check: Does the UE transmit a HARQ ACK on slot n3+k1? (Note 4) |
–> |
HARQ ACK |
1 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: For aggregationFactorDL=4, the PDSCH will repeat in following 4-1=3 slots with same resource allocation but different redundancy version, if the slot can be used for downlink transmission. Note 4: n0 is the index of slot when 1st transmission of MAC PDU in step 4/8 happens, n1, n2, n3 are indices of slots when 2nd, 3rd, 4th transmission of MAC PDU in step 5/9 may happen, k1 is obtained from "PDSCH-to-HARQ_feedback timing indicator" of downlink assignment in step 3/7. |
7.1.1.2.2.3.3 Specific message contents
Table 7.1.1.2.2.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.2.2.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
} |
|||
RRCReconfiguration-v1530-IEs ::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.2.2.3.3-2: cellGroupConfig (Table 7.1.1.2.2.3.3-1: RRCReconfiguration)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig::= SEQUENCE { |
|||
cellGroupId |
0 |
||
1 |
EN-DC |
||
spCellConfig SEQUENCE { |
|||
spCellConfigDedicated SEQUENCE { |
|||
servingCellConfig SEQUENCE { |
|||
initialDownlinkBWP SEQUENCE { |
|||
pdsch-Config SEQUENCE { |
|||
pdsch-AggregationFactor |
n4 |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.2.2.3.3-3: Physical layer parameters for DCI format 1_1 (Steps 3, 7, Table 7.1.1.2.2.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.3.6.1.2.2-1 |
|||
Parameter |
Value |
Value in binary |
Condition |
PDSCH-to-HARQ_feedback timing indicator |
Corresponding to K1=5 slots as per dl-DataToUL-ACK in Table 4.6.3-112 TS 38.508-1 [4]. |
“011”B |
7.1.1.2.3 Correct HARQ process handling / CCCH
7.1.1.2.3.1 Test Purpose (TP)
(1)
with { UE in RRC_IDLE state with RRC connection establishment procedure initiated }
ensure that {
when { UE receives a MAC PDU addressed to RA-RNTI }
then { UE does not transmit the HARQ feedback for the corresponding HARQ process }
}
(2)
with { UE in RRC_IDLE state with RRC connection establishment procedure initiated }
ensure that {
when { UE receives a MAC PDU addressed to T-CRNTI without UE Contention Resolution Identity corresponding the transmitted RRCSetupRequest message }
then { UE does not transmit the HARQ feedback for the corresponding HARQ process }
}
(3)
with { UE in RRC_IDLE state with RRC connection establishment procedure initiated }
ensure that {
when { UE receives a MAC PDU addressed to T-CRNTI and cannot decode properly }
then { UE does not transmit the HARQ feedback for the corresponding HARQ process }
}
(4)
with { UE in RRC_IDLE state with RRC connection establishment procedure initiated }
ensure that {
when { UE receives a MAC PDU addressed to T-CRNTI with UE Contention Resolution Identity corresponding the transmitted RRCSetupRequest message }
then { UE transmits the HARQ ACK for the corresponding HARQ process }
}
7.1.1.2.3.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 38.321, clauses 5.3.2.1 and 5.3.2.2.
[TS 38.321, clause 5.3.2.1]
The MAC entity includes a HARQ entity for each Serving Cell, which maintains a number of parallel HARQ processes. Each HARQ process is associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2).
The number of parallel DL HARQ processes per HARQ entity is specified in TS 38.214 [7]. The dedicated broadcast HARQ process is used for BCCH.
The HARQ process supports one TB when the physical layer is not configured for downlink spatial multiplexing. The HARQ process supports one or two TBs when the physical layer is configured for downlink spatial multiplexing.
When the MAC entity is configured with pdsch-AggregationFactor > 1, the parameter pdsch-AggregationFactor provides the number of transmissions of a TB within a bundle of the dynamic downlink assignment. Bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. After the initial transmission, pdsch-AggregationFactor – 1 HARQ retransmissions follow within a bundle.
The MAC entity shall:
1> if a downlink assignment has been indicated:
2> allocate the TB(s) received from the physical layer and the associated HARQ information to the HARQ process indicated by the associated HARQ information.
1> if a downlink assignment has been indicated for the broadcast HARQ process:
2> allocate the received TB to the broadcast HARQ process.
[TS 38.321, clause 5.3.2.2]
When a transmission takes place for the HARQ process, one or two (in case of downlink spatial multiplexing) TBs and the associated HARQ information are received from the HARQ entity.
For each received TB and associated HARQ information, the HARQ process shall:
1> if the NDI, when provided, has been toggled compared to the value of the previous received transmission corresponding to this TB; or
1> if the HARQ process is equal to the broadcast process, and this is the first received transmission for the TB according to the system information schedule indicated by RRC; or
1> if this is the very first received transmission for this TB (i.e. there is no previous NDI for this TB):
2> consider this transmission to be a new transmission.
1> else:
2> consider this transmission to be a retransmission.
The MAC entity then shall:
1> if this is a new transmission:
2> attempt to decode the received data.
1> else if this is a retransmission:
2> if the data for this TB has not yet been successfully decoded:
3> instruct the physical layer to combine the received data with the data currently in the soft buffer for this TB and attempt to decode the combined data.
1> if the data which the MAC entity attempted to decode was successfully decoded for this TB; or
1> if the data for this TB was successfully decoded before:
2> if the HARQ process is equal to the broadcast process:
3> deliver the decoded MAC PDU to upper layers.
2> else if this is the first successful decoding of the data for this TB:
3> deliver the decoded MAC PDU to the disassembly and demultiplexing entity.
1> else:
2> instruct the physical layer to replace the data in the soft buffer for this TB with the data which the MAC entity attempted to decode.
1> if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention Resolution is not yet successful (see subclause 5.1.5); or
1> if the HARQ process is equal to the broadcast process; or
1> if the timeAlignmentTimer, associated with the TAG containing the Serving Cell on which the HARQ feedback is to be transmitted, is stopped or expired:
2> not instruct the physical layer to generate acknowledgement(s) of the data in this TB.
1> else:
2> instruct the physical layer to generate acknowledgement(s) of the data in this TB.
The MAC entity shall ignore NDI received in all downlink assignments on PDCCH for its Temporary C-RNTI when determining if NDI on PDCCH for its C-RNTI has been toggled compared to the value in the previous transmission.
NOTE: If the MAC entity receives a retransmission with a TB size different from the last TB size signalled for this TB, the UE behavior is left up to UE implementation.
7.1.1.2.3.3 Test description
7.1.1.2.3.3.1 Pre-test conditions
System Simulator:
– NR Cell 1.
UE:
– None
Preamble:
– The UE is in 1N-A state on NR Cell 1 using generic procedure parameter Connectivity (NR) according to TS 38.508-1 [4].
7.1.1.2.3.3.2 Test procedure sequence
Table 7.1.1.2.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits a Paging message including a matched identity. |
<– |
– |
– |
– |
2 |
The UE transmits Preamble on PRACH. |
–> |
PRACH Preamble |
– |
– |
3 |
The SS transmits Random Access Response with matching RA-RNTI and including Temporary C-RNTI. The CRC is calculated in such a way, it will result in CRC error on UE side. |
<– |
Random Access Response |
– |
– |
4 |
Check: does the UE transmit a HARQ ACK/NACK? |
–> |
HARQ ACK/NACK |
1 |
F |
5 |
The UE transmits Preamble on PRACH. |
–> |
PRACH Preamble |
– |
– |
6 |
The SS transmits Random Access Response with matching RA-RNTI and including Temporary C-RNTI. The CRC is calculated in such a way, it will result in CRC pass on UE side. |
<– |
Random Access Response |
– |
– |
7 |
Check: does the UE transmit a HARQ ACK/NACK? |
–> |
HARQ ACK/NACK |
1 |
F |
8 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. |
–> |
MAC PDU |
– |
– |
9 |
The SS transmits a valid MAC PDU containing RRCSetup, and including ‘UE Contention Resolution Identity’ MAC control element with not matching ‘Contention Resolution Identity’. |
<– |
MAC PDU |
– |
– |
10 |
Check: does the UE transmit a HARQ ACK/NACK? |
–> |
HARQ ACK/NACK |
2 |
F |
11 |
The UE transmits Preamble on PRACH. |
–> |
PRACH Preamble |
– |
– |
12 |
The SS transmits Random Access Response with matching RA-RNTI and including Temporary C-RNTI. |
<– |
Random Access Response |
– |
– |
13 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. |
–> |
MAC PDU |
– |
– |
14 |
The SS transmits a valid MAC PDU containing RRCSetup, and including ‘UE Contention Resolution Identity’ MAC control element with matching ‘Contention Resolution Identity’. The CRC is calculated in such a way that it will result in CRC error on UE side. |
<– |
MAC PDU |
– |
– |
15 |
Check: Does UE transmit a HARQ ACK/NACK? |
–> |
HARQ ACK/NACK |
3 |
F |
16 |
The UE transmits Preamble on PRACH. |
–> |
PRACH Preamble |
– |
– |
17 |
The SS transmits Random Access Response with matching RA-RNTI and including Temporary C-RNTI. |
<– |
Random Access Response |
– |
– |
18 |
The UE transmits a MAC PDU containing an RRCSetupRequest message. |
–> |
MAC PDU |
– |
– |
19 |
The SS transmits a valid MAC PDU containing RRCSetup, and including ‘UE Contention Resolution Identity’ MAC control element with matching ‘Contention Resolution Identity’. The CRC is calculated in such a way that it will result in CRC pass on UE side. |
<– |
MAC PDU |
– |
– |
20 |
Check: does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
4 |
P |
21 |
The UE transmits a MAC PDU containing an RRCSetupComplete message including SERVICE REQUEST message indicating acceptance of RRCSetup message |
–> |
MAC PDU |
– |
– |
22-25 |
Steps 5 to 8 of the generic radio bearer establishment procedure (TS 38.508 table 4.5.4.2-3) are executed to successfully complete the service request procedure. |
– |
– |
– |
– |
7.1.1.2.3.3.3 Specific message contents
None.
7.1.1.2.4 Correct HARQ process handling / BCCH
7.1.1.2.4.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives a MAC PDU addressed to SI-RNTI on the broadcast HARQ process }
then { UE does not transmit the HARQ feedback for the broadcast HARQ process }
}
7.1.1.2.4.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 38.321, clauses 5.3.2.1 and 5.3.2.2.
[TS 38.321, clause 5.3.2.1]
The MAC entity includes a HARQ entity for each Serving Cell, which maintains a number of parallel HARQ processes. Each HARQ process is associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2).
The number of parallel DL HARQ processes per HARQ entity is specified in TS 38.214 [7]. The dedicated broadcast HARQ process is used for BCCH.
The HARQ process supports one TB when the physical layer is not configured for downlink spatial multiplexing. The HARQ process supports one or two TBs when the physical layer is configured for downlink spatial multiplexing.
When the MAC entity is configured with pdsch-AggregationFactor > 1, the parameter pdsch-AggregationFactor provides the number of transmissions of a TB within a bundle of the dynamic downlink assignment. Bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. After the initial transmission, pdsch-AggregationFactor – 1 HARQ retransmissions follow within a bundle.
The MAC entity shall:
1> if a downlink assignment has been indicated:
2> allocate the TB(s) received from the physical layer and the associated HARQ information to the HARQ process indicated by the associated HARQ information.
1> if a downlink assignment has been indicated for the broadcast HARQ process:
2> allocate the received TB to the broadcast HARQ process.
[TS 38.321, clause 5.3.2.2]
When a transmission takes place for the HARQ process, one or two (in case of downlink spatial multiplexing) TBs and the associated HARQ information are received from the HARQ entity.
For each received TB and associated HARQ information, the HARQ process shall:
1> if the NDI, when provided, has been toggled compared to the value of the previous received transmission corresponding to this TB; or
1> if the HARQ process is equal to the broadcast process, and this is the first received transmission for the TB according to the system information schedule indicated by RRC; or
1> if this is the very first received transmission for this TB (i.e. there is no previous NDI for this TB):
2> consider this transmission to be a new transmission.
1> else:
2> consider this transmission to be a retransmission.
The MAC entity then shall:
1> if this is a new transmission:
2> attempt to decode the received data.
1> else if this is a retransmission:
2> if the data for this TB has not yet been successfully decoded:
3> instruct the physical layer to combine the received data with the data currently in the soft buffer for this TB and attempt to decode the combined data.
1> if the data which the MAC entity attempted to decode was successfully decoded for this TB; or
1> if the data for this TB was successfully decoded before:
2> if the HARQ process is equal to the broadcast process:
3> deliver the decoded MAC PDU to upper layers.
2> else if this is the first successful decoding of the data for this TB:
3> deliver the decoded MAC PDU to the disassembly and demultiplexing entity.
1> else:
2> instruct the physical layer to replace the data in the soft buffer for this TB with the data which the MAC entity attempted to decode.
1> if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention Resolution is not yet successful (see subclause 5.1.5); or
1> if the HARQ process is equal to the broadcast process; or
1> if the timeAlignmentTimer, associated with the TAG containing the Serving Cell on which the HARQ feedback is to be transmitted, is stopped or expired:
2> not instruct the physical layer to generate acknowledgement(s) of the data in this TB.
1> else:
2> instruct the physical layer to generate acknowledgement(s) of the data in this TB.
The MAC entity shall ignore NDI received in all downlink assignments on PDCCH for its Temporary C-RNTI when determining if NDI on PDCCH for its C-RNTI has been toggled compared to the value in the previous transmission.
NOTE: If the MAC entity receives a retransmission with a TB size different from the last TB size signalled for this TB, the UE behaviour is left up to UE implementation.
7.1.1.2.4.3 Test description
7.1.1.2.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Short_DCI condition is applied in NR Serving cell configuration.
7.1.1.2.4.3.2 Test procedure sequence
Table 7.1.1.2.4.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits a Short message on PDCCH using P-RNTI indicating a systemInfoModification. (Note 1) |
<– |
PDCCH (DCI 1_0): Short Message |
– |
– |
2 |
At the start of the modification period, the SS transmits an updated system information with SI-RNTI addressed in L1/L2 header. CRC is calculated in such a way, it will result in CRC fail on UE side. Dedicated HARQ process for broadcast is used. (Note 5) |
<– |
– |
– |
– |
3 |
Check: Does the UE transmit a HARQ ACK/NACK? (Note 2 and 3) |
–> |
HARQ ACK/NACK |
1 |
F |
4 |
After 400ms of step 2, the SS transmits an updated system information contents same as in step 2 with SI-RNTI addressed in L1/L2 header. CRC is calculated in such a way, it will result in CRC pass on UE side. Dedicated HARQ process for broadcast is used. |
<– |
– |
– |
– |
5 |
Check: Does the UE transmit a HARQ ACK/NACK? (Note 2 and 4) |
-> |
HARQ ACK/NACK |
1 |
F |
6 |
After 100 ms of Step 4, SS is configured to not allocate UL Grants on Scheduling Request. |
– |
– |
– |
– |
7 |
The SS transmits MAC PDU containing an RLC PDU. |
<– |
MAC PDU |
– |
– |
8 |
The UE transmits a HARQ ACK. |
–> |
HARQ ACK |
– |
– |
9 |
Check: Does the UE transmit PRACH Preamble, using PRACH resources as in new SI? |
–> |
PRACH Preamble |
1 |
P |
10 |
The SS transmits Random Access Response |
<– |
Random Access Response |
– |
– |
11 |
The UE transmits a MAC PDU with C-RNTI containing loop backed RLC PDU. |
–> |
MAC PDU |
– |
– |
12 |
SS sends PDCCH transmission for UE C-RNTI to complete contention resolution. |
<– |
– |
– |
– |
Note 1: The Short Message was transmitted in controlResourceSetZero as Configured in SIB1, need to guarantee that the UE will receive at least one Paging in the Modification Period preceding the SysInfo change, SS should send the Paging message in every eligible PO in this Modification Period. Note 2: When requested to check HARQ feedback for the dedicated broadcast HARQ process, the SS shall assume the same PUCCH reception requirement as specified in TS 38.213 section 9 for a normal HARQ process. Note 3: For duration of 400ms, the SS shall check HARQ ACK/NACK for all broadcast SIBs. This duration is sufficient to ensure that SS transmits few times SIBs with CRC corruption. Note 4: For duration of 100 ms, The SS shall check for HARQ ACK/NACK for all broadcast SIBs. This duration is sufficient to ensure that SS transmits few times SIBs after CRC corruption is removed. Note 5: The modification period boundaries are defined by SFN values for which SFN mod m = 0, where m is the number of radio frames comprising the modification period. Value of m is caluclated based on the parameters specified in TS 38.508-1 [4] i.e m = (modificationPeriodCoeff=4) * (defaultPagingCycle=128 |
7.1.1.2.4.3.3 Specific message contents
Table 7.1.1.2.4.3.3-1: SystemInformationBlockType1 (steps 2 and 4 of table 7.1.1.2.4.3.2-1)
Derivation path: 38.508-1 [4] table 4.6.1-28 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
servingCellConfigCommon SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP SEQUENCE { |
|||
rach-ConfigCommon SEQUENCE { |
|||
prach-RootSequenceIndex CHOICE { |
|||
l139 |
20 |
FDD |
|
l139 |
2 |
TDD |
|
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
7.1.1.2.5 Correct HARQ process handling / DL grant prioritization
Editor’s Note: Does the test coverage need to be provided for simultaneous 2 HARQ transmission or can be tested with 2 transmissions in two different time slots? The first option requires additional mechanism to make sure HARQ feedback is with right priority by enforcing different HARQ feedbacks for 2 PDSCH simultaneous transmissions. The test sequence currently is for second option.
7.1.1.2.5.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and is configured with two PUCCH-config each corresponds to a PHY priority}
ensure that {
when { UE receives DL MAC PDU’s with DL grant indicating different priorities }
then { UE transmit the HARQ feedback using correct PUCCH resource as per priority}
}
7.1.1.2.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.213 clause 9, 9.2.4. Unless otherwise stated these are Rel-16 requirements.
[TS 38.213, clause 9]
A PUSCH or a PUCCH transmission, including repetitions if any, can be of priority index 0 or of priority index 1. For a configured grant PUSCH transmission, a UE determines a priority index from phy-PriorityIndex, if provided. For a PUCCH transmission with HARQ-ACK information corresponding to a SPS PDSCH reception or a SPS PDSCH release, a UE determines a priority index from harq-CodebookID, if provided. For a PUCCH transmission with SR, a UE determines the corresponding priority as described in Clause 9.2.4. For a PUSCH transmission with semi-persistent CSI report, a UE determines a priority index from a priority indicator field, if provided, in a DCI format that activates the semi-persistent CSI report. If a priority index is not provided to a UE for a PUSCH or a PUCCH transmission, the priority index is 0.
[TS 38.213, clause 9.1]
If a UE is provided pdsch-HARQ-ACK-CodebookList, the UE can be indicated by pdsch-HARQ-ACK-CodebookList to generate one or two HARQ-ACK codebooks. If the UE is indicated to generate one HARQ-ACK codebook, the HARQ-ACK codebook is associated with a PUCCH of priority index 0. If a UE is provided pdsch-HARQ-ACK-CodebookList, the UE multiplexes in a same HARQ-ACK codebook only HARQ-ACK information associated with a same priority index. If the UE is indicated to generate two HARQ-ACK codebooks
– a first HARQ-ACK codebook is associated with a PUCCH of priority index 0 and a second HARQ-ACK codebook is associated with a PUCCH of priority index 1
[TS 38.213, clause 9.2.4]
A UE can be configured by SchedulingRequestResourceConfig a set of configurations for SR in a PUCCH transmission using either PUCCH format 0 or PUCCH format 1. A UE can be configured by schedulingRequestID-BFR-SCell a configuration for LRR in a PUCCH transmission using either PUCCH format 0 or PUCCH format 1. The UE can be provided, by phy-PriorityIndex in SchedulingRequestResourceConfig, a priority index 0 or a priority index 1 for the SR. If the UE is not provided a priority index for SR, the priority index is 0.
7.1.1.2.5.3 Test description
7.1.1.2.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink and parameters as in Table 7.1.1.2.5.3.1-1.
Table 7.1.1.2.5.3.1-1: MAC Parameters
Parameter |
Value |
Comment |
pdsch-HARQ-ACK-Codebook |
Not Present |
It is assumed this will force the UE to use pdsch-HARQ-ACK-CodebookList-r16 |
pdsch-HARQ-ACK-CodebookList-r16 |
dynamic, semiStatic |
2 entries |
7.1.1.2.5.3.2 Test procedure sequence
Table 7.1.1.2.5.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits a downlink assignment addressed to the C-RNTI assigned to the UE with priority indicator =0 |
<– |
(PDCCH (C-RNTI) priority Ind =0) (PDCCH (C-RNTI)) |
– |
– |
2 |
SS transmits in the indicated downlink assignment a MAC PDU including a RLC PDU with poll bit not set. |
<– |
MAC PDU |
– |
– |
3 |
Check: Does the UE transmit an HARQ ACK on PUCCH associated with priority indicator 0? |
–> |
HARQ ACK |
1 |
P |
4 |
SS transmits a downlink assignment addressed to the C-RNTI assigned to the UE with priority indicator =1 |
<– |
(PDCCH (C-RNTI) priority Ind =1) (PDCCH (C-RNTI)) |
– |
– |
5 |
SS transmits in the indicated downlink assignment a MAC PDU including a RLC PDU with poll bit not set. |
<– |
MAC PDU |
– |
– |
6 |
Check: Does the UE transmit an HARQ ACK on PUCCH associated with priority indicator 1? |
–> |
HARQ ACK |
1 |
P |
7.1.1.2.5.3.3 Specific message contents
None
7.1.1.3 Uplink Data Transfer
7.1.1.3.1 Correct Handling of UL MAC PDU / Assignment / HARQ process
7.1.1.3.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives for a Slot an uplink grant with valid C-RNTI }
then { UE transmits data and associated HARQ information to the HARQ entity for this Slot }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { SS transmits for a Slot an uplink grant with not allocated C-RNTI }
then { UE does not transmits data and associated HARQ information to the HARQ entity for this Slot }
}
(3)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives an UL Grant with toggled NDI and has data available for transmission }
then { UE transmits a new MAC PDU }
}
(4)
with { UE in RRC_CONNECTED state and having transmitted a MAC PDU on a HARQ process }
ensure that {
when { UE receives an uplink grant on PDCCH for the next Slot corresponding to the HARQ process with old NDI not toggled}
then { UE performs an adaptive retransmission of the MAC PDU with redundancy version as received on PDCCH }
}
(5)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an uplink grant on PDCCH for the next Slot corresponding to the HARQ process with toggled NDI, and data is not available for transmission }
then { UE transmits any MAC Padding PDU }
}
(6)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE has a MAC SDU to be transmitted that is smaller or equal to 256 bytes }
then { UE sets F field to 0 and includes 8 bit L field in the MAC sub PDU}
}
(7)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE has a MAC SDU to be transmitted that is larger than 256 bytes }
then { UE sets F field to 1 and includes 16 bit L field in the MAC sub PDU }
}
(8)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE has to insert padding in a MAC PDU }
then { UE inserts the last MAC sub PDU as a padding sub PDU }
}
(9)
with { UE in RRC_CONNECTED state and configured with a specific TDD-UL-DL-ConfigCommon including configuration of pattern2}
ensure that {
when { UE receives for a Slot an uplink grant associated with pattern2 with valid C-RNTI }
then { UE transmits data and associated HARQ information to the HARQ entity for this Slot }
}
7.1.1.3.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.4.1, 5.4.2.1, 5.4.2.2 and 6.1.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.1]
Uplink grant is either received dynamically on the PDCCH, in a Random Access Response, or configured semi-persistently by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To perform the requested transmissions, the MAC layer receives HARQ information from lower layers.
If the MAC entity has a C-RNTI, a Temporary C-RNTI or CS-RNTI, the MAC entity shall for each PDCCH occasion and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer and for each grant received for this PDCCH occasion:
1> if an uplink grant for this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or
1> if an uplink grant has been received in a Random Access Response:
2> if the uplink grant is for MAC entity’s C-RNTI and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was either an uplink grant received for the MAC entity’s CS-RNTI or a configured uplink grant:
3> consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.
2> deliver the uplink grant and the associated HARQ information to the HARQ entity.
1> else if an uplink grant for this PDCCH occasion has been received for this serving cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> stop the ConfiguredGrantTimer for the corresponding HARQ process, if running;
3> deliver the uplink grant and the associated HARQ information to the HARQ entity.
2> else if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate configured grant Type 2 deactivation:
4> trigger configured grant confirmation.
3> else if PDCCH contents indicate configured grant Type 2 activation:
4> trigger configured grant confirmation;
4> store the uplink grant for this serving cell and the associated HARQ information as configured uplink grant;
4> initialise or re-initialise the configured uplink grant for this serving cell to start in the associated PUSCH duration and to recur according to rules in subclause 5.8.2;
4> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
4> consider the NDI bit for the corresponding HARQ process to have been toggled;
4> stop the ConfiguredGrantTimer for the corresponding HARQ process, if running;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall:
1> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
1> if the ConfiguredGrantTimer for the corresponding HARQ process is not running:
2> consider the NDI bit for the corresponding HARQ process to have been toggled;
2> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
NOTE 1: For the same serving cell, an uplink grant addressed to C-RNTI shall override a configured uplink grant in case of overlap in time domain.
For configured uplink grants, the HARQ Process ID associated with this symbol is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo numberOfConfGrant-Processes
where CURRENT_symbol=(SFN * numberOfSlotsPerFrame * numberOfSymbolsPerSlot + slot number in the frame * numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS 38.211 [8].
NOTE 2: CURRENT_symbol refers to the symbol index of the first transmission of a repetition bundle that takes place. [TS 36.322, clause 5.4.2.1]
The MAC entity includes a HARQ entity for each Serving Cell with configured uplink (including the case when it is configured with supplementaryUplink),which maintains a number of parallel HARQ processes.
The number of parallel UL HARQ processes per HARQ entity is specified in TS 38.214 [7].
Each HARQ process supports one TB.
Each HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RA Response, HARQ process identifier 0 is used.
When repetition is configured with repK >1, the parameter repK provides the number of repetitions of a TB within a bundle. Repetition operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle HARQ retransmissions are non-adaptive and triggered without waiting for feedback from previous transmissions according to repK.
For each uplink grant, the HARQ entity shall:
1> identify the HARQ process(es) associated with this grant, and for each identified HARQ process:
2> if the received grant was not addressed to a Temporary C-RNTI on PDCCH, and the NDI provided in the associated HARQ information has been toggled compared to the value in the previous transmission of this TB of this HARQ process; or
2> if the uplink grant was received on PDCCH for the C-RNTI and the HARQ buffer of the identified process is empty; or
2> if the uplink grant was received in a Random Access Response:
3> if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a Random Access Response:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
3> else:
4> obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity, if any;
3> if a MAC PDU to transmit has been obtained:
4> deliver the MAC PDU and the uplink grant and the HARQ information of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a new transmission.
4> if the uplink grant is addressed to CS-RNTI or the uplink grant is a configured uplink grant:
5> start or restart the ConfiguredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed.
2> else:
3> if the uplink grant received on PDCCH was addressed to CS-RNTI and if the HARQ buffer of the identified process is empty:
4> ignore the uplink grant.
3> else:
4> deliver the uplink grant and the HARQ information (redundancy version) of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a retransmission;
4> if the uplink grant is addressed to CS-RNTI or the uplink grant is a configured uplink grant:
5> start or restart the ConfiguredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed.
When determining if NDI has been toggled compared to the value in the previous transmission the MAC entity shall ignore NDI received in all uplink grants on PDCCH for its Temporary C-RNTI.
[TS 38.321, clause 5.4.2.2]
Each HARQ process is associated with a HARQ buffer.
New transmissions are performed on the resource and with the MCS indicated on either PDCCH, Random Access Response, or RRC. Retransmissions are performed on the resource and, if provided, with the MCS indicated on PDCCH.
If the HARQ entity requests a new transmission for a TB, the HARQ process shall:
1> store the MAC PDU in the associated HARQ buffer;
1> store the uplink grant received from the HARQ entity;
1> generate a transmission as described below.
If the HARQ entity requests a retransmission for a TB, the HARQ process shall:
1> store the uplink grant received from the HARQ entity;
1> generate a transmission as described below.
To generate a transmission for a TB, the HARQ process shall:
1> if the MAC PDU was obtained from the Msg3 buffer; or
1> if there is no measurement gap at the time of the transmission and, in case of retransmission, the retransmission does not collide with a transmission for a MAC PDU obtained from the Msg3 buffer:
2> instruct the physical layer to generate a transmission according to the stored uplink grant.
[TS 38.321, clause 6.1.2]
A MAC PDU consists of one or more MAC subPDUs. Each MAC subPDU consists of one of the following:
– A MAC subheader only (including padding);
– A MAC subheader and a MAC SDU;
– A MAC subheader and a MAC CE;
– A MAC subheader and padding.
The MAC SDUs are of variable sizes.
Each MAC subheader corresponds to either a MAC SDU, a MAC CE, or padding.
A MAC subheader except for fixed sized MAC CE and padding consists of the four header fields R/F/LCID/L. A MAC subheader for fixed sized MAC CE and padding consists of the two header fields R/LCID.
Figure 6.1.2-1: R/F/LCID/L MAC subheader with 8-bit L field
Figure 6.1.2-2: R/F/LCID/L MAC subheader with 16-bit L field
Figure 6.1.2-3: R/LCID MAC subheader
MAC CEs are placed together. DL MAC subPDU(s) with MAC CE(s) is placed before any MAC subPDU with MAC SDU and MAC subPDU with padding as depicted in Figure 6.1.2-4. UL MAC subPDU(s) with MAC CE(s) is placed after all the MAC subPDU(s) with MAC SDU and before the MAC subPDU with padding in the MAC PDU as depicted in Figure 6.1.2-5. The size of padding can be zero.
Figure 6.1.2-4: Example of a DL MAC PDU
Figure 6.1.2-5: Example of a UL MAC PDU
A maximum of one MAC PDU can be transmitted per TB per MAC entity.
7.1.1.3.1.3 Test description
7.1.1.3.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.3.1.3.2 Test procedure sequence
Table 7.1.1.3.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
2 |
SS transmits a MAC PDU including a RLC SDU |
<– |
MAC PDU |
– |
– |
– |
EXCEPTION: Step 3 runs in parallel with behaviour in table 7.1.1.3.1.3.2-2 |
– |
– |
– |
– |
3 |
For 100 ms SS transmits an UL Grant every 10 ms , allowing the UE to return the RLC SDU as received in step 2, on PDCCH, but with the C-RNTI different from the C-RNTI assigned to the UE. |
<– |
(UL Grant (unknown C-RNTI)) |
– |
– |
4 |
Check: Does the UE transmit a MAC PDU corresponding to grant in step 3? |
–> |
MAC PDU |
2 |
F |
5 |
SS transmits an UL Grant, allowing the UE to return the RLC SDU as received in step 2, on PDCCH with the C-RNTI assigned to the UE. |
<– |
(UL Grant (C-RNTI)) |
– |
– |
6 |
Check: Does the UE transmit a MAC PDU corresponding to grant in step 6? |
–> |
MAC PDU |
1 |
P |
6A |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDUs in step 6. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
– |
7 |
The SS Transmits a valid MAC PDU containing RLC PDU |
<– |
MAC PDU |
– |
– |
8 |
The SS allocates an UL Grant for one HARQ process X, sufficient for one RLC SDU to be looped back in a Slot, and NDI indicates new transmission redundancy version to be used as 0 |
<– |
Uplink Grant |
– |
– |
9 |
Check: Does the UE transmit a MAC PDU including one RLC SDU, in HARQ process X? |
–> |
MAC PDU |
3 |
P |
10 |
The SS transmits an UL grant corresponding to slot for HARQ process X, with NDI not toggled and redundancy version to be used as 1 |
<– |
Uplink Grant |
– |
– |
11 |
Check: Does the UE retransmit the MAC PDU in for HARQ process X, using redundancy version1? |
–> |
MAC PDU |
4 |
P |
11A |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDUs in step 11. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
– |
12 |
The SS transmits an UL grant corresponding to SLOT for HARQ process X, with NDI toggled and redundancy version to be used as 0 |
<– |
Uplink Grant |
– |
– |
13 |
Check: Does the UE retransmit the MAC PDU containing padding for HARQ process X, using redundancy version 0? |
–> |
MAC PDU |
5 |
P |
14 |
SS transmits a MAC PDU including a RLC PDU of size 128 bytes |
<– |
MAC PDU |
– |
– |
15 |
The SS transmits an UL Grant, allowing the UE to return the RLC SDU as received in step 14 and padding. |
<– |
(UL Grant (C-RNTI)) |
– |
– |
16 |
Check: Does the UE transmit a MAC PDU corresponding to grant in step 14 with F field set to 0 and includes 8 bit L field in the MAC sub PDU and includes a padding sub PDU at end? |
–> |
MAC PDU |
6,8 |
P |
16A |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDUs in step 16. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
– |
17 |
SS transmits a MAC PDU including a RLC PDU of size 512 bytes |
<– |
MAC PDU |
– |
– |
18 |
The SS transmits an UL Grant, allowing the UE to return the RLC SDU as received in step 17 and padding. |
<– |
(UL Grant (C-RNTI)) |
– |
– |
19 |
Check: Does the UE transmit a MAC PDU corresponding to grant in step 17 with F field set to 1 and includes 16 bit L field in the MAC sub PDU and includes a padding sub PDU at end? |
–> |
MAC PDU |
7,8 |
P |
19A |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDUs in step 19. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
– |
– |
EXCEPTION : Steps 20a0 to 20a6 are executed for operation on NR TDD band only |
– |
– |
– |
– |
20a0 |
The SS transmits an updated system information as specified in Table 7.1.1.3.1.3.3-14. |
||||
20a1 |
The SS transmits a NR RRCReconfiguration message including TDD-UL-DL-ConfigCommon with pattern1 and pattern 2 specified in Table 7.1.1.3.1.3.3-5 (Note 1) |
<– |
RRCReconfiguration |
– |
– |
20a2 |
The UE transmit a NR RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
20a3 |
SS transmits a MAC PDU including a RLC SDU |
<– |
MAC PDU |
– |
– |
20a4 |
SS transmits an UL Grant, allowing the UE to return the RLC SDU as received in step 20a3, on PDCCH with the C-RNTI assigned to the UE. |
<– |
(UL Grant (C-RNTI)) |
– |
– |
20a5 |
Check: Does the UE transmit a MAC PDU corresponding to grant in step 20a4? |
–> |
MAC PDU |
9 |
P |
20a6 |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDUs in step 20a5. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
– |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
Table 7.1.1.3.1.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
UE transmits a Scheduling Request. |
–> |
(SR) |
– |
– |
7.1.1.3.1.3.3 Specific message contents
Table 7.1.1.3.1.3.3-1: Void
Table 7.1.1.3.1.3.3-2: Void
Table 7.1.1.3.1.3.3-3: RRCReconfiguration (step20a1, Table 7.1.1.3.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
|
} |
|||
RRCReconfiguration-v1530-IEs::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.3.1.3.3-4: CellGroupConfig (Table 7.1.1.3.1.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE { |
|||
reconfigurationWithSync SEQUENCE { |
|||
spCellConfigCommon |
ServingCellConfigCommon |
||
} |
|||
spCellConfigDedicated |
ServingCellConfig |
||
} |
|||
} |
Table 7.1.1.3.1.3.3-5: ServingCellConfigCommon (Table 7.1.1.3.1.3.3-4, Table 7.1.1.3.1.3.3-14)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
uplinkConfigCommon SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
|||
tdd-UL-DL-ConfigurationCommon |
TDD-UL-DL-ConfigCommon |
||
} |
Table 7.1.1.3.1.3.3-6: TDD-UL-DL-ConfigCommon (Table 7.1.1.3.1.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-192 |
|||
Information Element |
Value/remark |
Comment |
Condition |
TDD-UL-DL-ConfigCommon ::= SEQUENCE { |
|||
referenceSubcarrierSpacing |
SubcarrierSpacing |
||
pattern1 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms5 |
FR1 |
|
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
3 |
FR1 |
|
2 |
FR2 |
||
nrofDownlinkSymbols |
6 |
FR1 |
|
6 |
FR2 |
||
nrofUplinkSlots |
2 |
FR1 |
|
2 |
FR2 |
||
nrofUplinkSymbols |
4 |
FR1 |
|
2 |
FR2 |
||
dl-UL-TransmissionPeriodicity-v1530 |
ms3 |
FR1 |
|
} |
|||
pattern2 SEQUENCE { |
|||
dl-UL-TransmissionPeriodicity |
ms2 |
FR1 |
|
ms0p625 |
FR2 |
||
nrofDownlinkSlots |
4 |
FR1 |
|
3 |
FR2 |
||
nrofDownlinkSymbols |
0 |
FR1 |
|
6 |
FR2 |
||
nrofUplinkSlots |
0 |
FR1 |
|
1 |
FR2 |
||
nrofUplinkSymbols |
0 |
FR1 |
|
2 |
FR2 |
||
} |
|||
} |
Table 7.1.1.3.1.3.3-7: BWP-UplinkCommon (Table 7.1.1.3.1.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-14 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
rach-ConfigCommon CHOICE { |
|||
setup |
RACH-ConfigCommon |
||
} |
|||
} |
Table 7.1.1.3.1.3.3-8: RACH-ConfigCommon (Table 7.1.1.3.1.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-128 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigCommon::= SEQUENCE { |
|||
rach-ConfigGeneric |
RACH-ConfigGeneric |
||
} |
Table 7.1.1.3.1.3.3-9: RACH-ConfigGeneric (Table 7.1.1.3.1.3.3-8)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-130 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RACH-ConfigGeneric ::= SEQUENCE { |
|||
prach-configurationIndex |
156 |
||
} |
Table 7.1.1.3.1.3.3-10: ServingCellConfig (Table 7.1.1.3.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.3.1.3.3-11: BWP-UplinkDedicated (Table 7.1.1.3.1.3.3-10)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup |
PUCCH-Config |
||
} |
|||
} |
Table 7.1.1.3.1.3.3-12: PUCCH-Config (Table 7.1.1.3.1.3.3-11)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-Config ::= SEQUENCE { |
|||
schedulingRequestResourceToAddModList SEQUENCE (SIZE (1..maxNrofSR-Resources)) OF SchedulingRequestResourceConfig { |
1 entry |
||
SchedulingRequestResourceConfig[1] |
SchedulingRequestResourceConfig |
entry 1 |
|
} |
|||
} |
Table 7.1.1.3.1.3.3-13: SchedulingRequestResourceConfig (Table 7.1.1.3.1.3.3-12)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequestResourceConfig ::= SEQUENCE { |
|||
periodicityAndOffset CHOICE { |
|||
sl10 |
5 |
With SCS = kHz15 results in repetition every 10 ms |
SCS_15kHz |
sl20 |
5 |
With SCS = kHz30 results in repetition every 10 ms |
SCS_30kHz |
sl80 |
4 |
With SCS = kHz120 results in repetition every 10 ms |
SCS_120kHz |
} |
|||
} |
Table 7.1.1.3.1.3.3-14: SystemInformationBlockType1 (step 20a0, Table 7.1.1.3.1.3.2-1)
Derivation path: 38.508-1 [4] table 4.6.1-28 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
SIB1 ::= SEQUENCE { |
|||
servingCellConfigCommon |
ServingCellConfigCommon |
Same contents as in Table 7.1.1.3.1.3.3-5 |
|
} |
7.1.1.3.2 Logical channel prioritization handling
7.1.1.3.2.1 Test Purpose (TP)
(1)
with {UE in RRC_CONNECTED state}
ensure that {
when { UE is sending data on the uplink }
then { UE serves the logical channels according to their priority and configured PBR }
}
7.1.1.3.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.4.3.1.1, 5.4.3.1.2, 5.4.3.1.3. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.3.1.1]
The Logical Channel Prioritization procedure is applied whenever a new transmission is performed.
RRC controls the scheduling of uplink data by signalling for each logical channel per MAC entity:
– priority where an increasing priority value indicates a lower priority level;
– prioritisedBitRate which sets the Prioritized Bit Rate (PBR);
– bucketSizeDuration which sets the Bucket Size Duration (BSD).
RRC additionally controls the LCP procedure by configuring mapping restrictions for each logical channel:
– allowedSCS-List which sets the allowed Subcarrier Spacing(s) for transmission;
– maxPUSCH-Duration which sets the maximum PUSCH duration allowed for transmission;
– configuredGrantType1Allowed which sets whether a Configured Grant Type 1 can be used for transmission;
– allowedServingCells which sets the allowed cell(s) for transmission.
The following UE variable is used for the Logical channel prioritization procedure:
– Bj which is maintained for each logical channel j.
The MAC entity shall initialize Bj of the logical channel to zero when the logical channel is established.
For each logical channel j, the MAC entity shall:
1> increment Bj by the product PBR × T before every instance of the LCP procedure, where T is the time elapsed since Bj was last updated;
1> if the value of Bj is greater than the bucket size (i.e. PBR × BSD):
2> set Bj to the bucket size.
NOTE: The exact moment(s) when the UE updates Bj between LCP procedures is up to UE implementation, as long as Bj is up to date at the time when a grant is processed by LCP.
[TS 38.321, clause 5.4.3.1.2]
The MAC entity shall, when a new transmission is performed:
1> select the logical channels for each UL grant that satisfy all the following conditions:
2> the set of allowed Subcarrier Spacing index values in allowedSCS-List, if configured, includes the Subcarrier Spacing index associated to the UL grant; and
2> maxPUSCH-Duration, if configured, is larger than or equal to the PUSCH transmission duration associated to the UL grant; and
2> configuredGrantType1Allowed, if configured, is set to TRUE in case the UL grant is a Configured Grant Type 1; and
2> allowedServingCells, if configured, includes the Cell information associated to the UL grant.
NOTE: The Subcarrier Spacing index, PUSCH transmission duration and Cell information are included in Uplink transmission information received from lower layers for the corresponding scheduled uplink transmission.
[TS 38.321, clause 5.4.3.1.3]
The MAC entity shall, when a new transmission is performed:
1> allocate resources to the logical channels as follows:
2> logical channels selected in subclause 5.4.3.1.2 for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to "infinity", the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);
2> decrement Bj by the total size of MAC SDUs served to logical channel j above;
NOTE: The value of Bj can be negative.
2> if any resources remain, all the logical channels selected in subclause 5.4.3.1.2 are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.
The UE shall also follow the rules below during the scheduling procedures above:
– the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources of the associated MAC entity;
– if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant of the associated MAC entity as much as possible;
– the UE should maximise the transmission of data;
– if the MAC entity is given an UL grant size that is equal to or larger than 8 bytes while having data available for transmission, the MAC entity shall not transmit only padding BSR and/or padding.
The MAC entity shall not generate a MAC PDU for the HARQ entity if the following conditions are satisfied:
– the MAC entity is configured with skipUplinkTxDynamic and the grant indicated to the HARQ entity was addressed to a C-RNTI, or the grant indicated to the HARQ entity is a configured uplink grant; and
– the MAC PDU includes zero MAC SDUs; and
– the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR.
Logical channels shall be prioritised in accordance with the following order (highest priority listed first):
– MAC CE for C-RNTI or data from UL-CCCH;
– MAC CE for SPS confirmation;
– MAC CE for BSR, with exception of BSR included for padding;
– MAC CE for single entry PHR or multiple entry PHR;
– data from any Logical Channel, except data from UL-CCCH;
– MAC CE for BSR included for padding.
7.1.1.3.2.3 Test description
7.1.1.3.2.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 3 UM SN terminated SCG bearers configured according to Table 7.1.1.3.2.3.1-1.
Table 7.1.1.3.2.3.1-1: Priority, PBR and Bucket Delay settings
DRB |
priority |
prioritizedBitRate (kbytes/s) |
bucketSizeDuration (ms) |
DRB1 |
6 |
8 |
100 |
DRB2 |
7 |
16 |
100 |
DRB3 |
8 |
32 |
100 |
Table 7.1.1.3.2.3.1-2: PDCP Settings
Parameter |
Value |
Discard_Timer |
ms1500 |
7.1.1.3.2.3.2 Test procedure sequence
Table 7.1.1.3.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 3 are run 4 times using the parameters specified for each run in table 7.1.1.3.2.3.2-3. |
– |
– |
– |
– |
1 |
The SS transmits N1 320-octet RLC SDUs on DRB1, N2 320-octet RLC SDUs on DRB2, and N3 320-octet RLC SDUs on DRB3. |
<– |
(RLC SDUs) |
– |
– |
1A |
Start WatchDog_Timer set to 5 seconds |
– |
– |
– |
– |
– |
EXCEPTION: In parallel to the event described in step 2 the events specified in Table 7.1.1.3.2.3.2-2 shall take place. |
– |
– |
– |
– |
2 |
The SS is configured for Uplink Grant Allocation Type 2 as defined in TS 38.523-3 [3]. 150 ms after Step 1 (Note1), for a duration of T2, the SS transmits an UL grant of D octets every T1. |
<– |
(UL grants) |
– |
– |
3 |
Check: Are the total number of octets of the UL RLC SDUs received at the SS for each DRB as follows: – total number of octets received for DRB1 is D1 octets +/- 10% – total number of octets received for DRB2 is D2 octets +/- 10% – total number of octets received for DRB3 is D3 octets +/- 10% ? |
– |
– |
1 |
P |
4 |
Wait for WatchDog_Timer expiry(Note2) |
– |
– |
– |
– |
Note 1: This wait time will ensure that a) all octets have been completely received by the UE on all 3 DRBs before the first UL grant is received and b) the Bjs for each logical channel have reached their maximum value i.e. the bucket size of the corresponding logical channel before the first UL grant is received. Note 2: Several PDUs on DRB3 after second run and on DRB2 after third run and on DRB1 after fourth run would be awaiting on PDCP Tx Buffer. Timer 5 seconds ensures the PDCP Data PDUs are discarded after expiry of Discard_timer(1500ms). |
Table 7.1.1.3.2.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit the RLC SDUs back to the SS? |
–> |
– |
1 |
P |
Table 7.1.1.3.2.3.2-3: Test parameter values
Parameter |
First run |
Second run |
Third run |
Fourth run |
N1 (SDUs) |
13 |
13 |
7 |
104 |
N2 (SDUs) |
25 |
25 |
50 |
25 |
N3 (SDUs) |
50 |
50 |
50 |
50 |
D (octets) |
1153 |
576 |
1153 |
1153 |
T1 (ms) |
20 |
20 |
20 |
10 |
T2 (ms) |
500 |
700 |
500 |
500 |
D1 (octets) |
4160 |
4160 |
2240 |
33350 (Note 1) |
D2 (octets) |
8000 |
8000 |
10435 (Note 1) |
8000 |
D3 (octets) |
16000 |
7790 (Note 1) |
16000 |
16000 |
Note 1: Calculated using the following equation for the case of the least header size: |
NOTE: The Test parameter values above and the test procedure assume that the UE has a loopback buffer of at least 57280 octets.
7.1.1.3.2.3.3 Specific message contents
Table 7.1.1.3.2.3.3-1: SchedulingRequest-Config (Preamble)
Derivation Path: 38.508-1 [4], Table 4.6.3-155 |
|||
Information Element |
Value/remark |
Comment |
Condition |
sr-TransMax |
n64 |
7.1.1.3.2b Logical channel prioritization handling with Mapping restrictions
7.1.1.3.2b.1 Test Purpose (TP)
(1)
with {UE in RRC_CONNECTED state with allowedSCS-List configured }
ensure that {
when { UE is sending data on the uplink }
then { UE serves the logical channels according to their priority and configured PBR and respecting allowedSCS-List }
}
(2)
with {UE in RRC_CONNECTED state with maxPUSCH-Duration configured }
ensure that {
when { UE is sending data on the uplink }
then { UE serves the logical channels according to their priority and configured PBR and respecting maxPUSCH-Duration }
}
(3)
with { UE in RRC_CONNECTED state with configuredGrantType1Allowed configured and supporting Type 1 PUSCH transmissions with configured grant }
ensure that {
when { UE is sending data on the uplink }
then { UE serves the logical channels according to their priority and configured PBR and respecting configuredGrantType1Allowed }
}
7.1.1.3.2b.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.4.3.1.1, 5.4.3.1.2, 5.4.3.1.3. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.3.1.1]
The Logical Channel Prioritization (LCP) procedure is applied whenever a new transmission is performed.
RRC controls the scheduling of uplink data by signalling for each logical channel per MAC entity:
– priority where an increasing priority value indicates a lower priority level;
– prioritisedBitRate which sets the Prioritized Bit Rate (PBR);
– bucketSizeDuration which sets the Bucket Size Duration (BSD).
RRC additionally controls the LCP procedure by configuring mapping restrictions for each logical channel:
– allowedSCS-List which sets the allowed Subcarrier Spacing(s) for transmission;
– maxPUSCH-Duration which sets the maximum PUSCH duration allowed for transmission;
– configuredGrantType1Allowed which sets whether a configured grant Type 1 can be used for transmission;
– allowedServingCells which sets the allowed cell(s) for transmission.
The following UE variable is used for the Logical channel prioritization procedure:
– Bj which is maintained for each logical channel j.
The MAC entity shall initialize Bj of the logical channel to zero when the logical channel is established.
For each logical channel j, the MAC entity shall:
1> increment Bj by the product PBR × T before every instance of the LCP procedure, where T is the time elapsed since Bj was last incremented;
1> if the value of Bj is greater than the bucket size (i.e. PBR × BSD):
2> set Bj to the bucket size.
NOTE: The exact moment(s) when the UE updates Bj between LCP procedures is up to UE implementation, as long as Bj is up to date at the time when a grant is processed by LCP.
[TS 38.321, clause 5.4.3.1.2]
The MAC entity shall, when a new transmission is performed:
1> select the logical channels for each UL grant that satisfy all the following conditions:
2> the set of allowed Subcarrier Spacing index values in allowedSCS-List, if configured, includes the Subcarrier Spacing index associated to the UL grant; and
2> maxPUSCH-Duration, if configured, is larger than or equal to the PUSCH transmission duration associated to the UL grant; and
2> configuredGrantType1Allowed, if configured, is set to true in case the UL grant is a Configured Grant Type 1; and
2> allowedServingCells, if configured, includes the Cell information associated to the UL grant. Does not apply to logical channels associated with a DRB configured with PDCP duplication within the same MAC entity (i.e. CA duplication) for which PDCP duplication is deactivated.
NOTE: The Subcarrier Spacing index, PUSCH transmission duration and Cell information are included in Uplink transmission information received from lower layers for the corresponding scheduled uplink transmission.
[TS 38.321, clause 5.4.3.1.3]
The MAC entity shall, when a new transmission is performed:
1> allocate resources to the logical channels as follows:
2> logical channels selected in subclause 5.4.3.1.2 for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);
2> decrement Bj by the total size of MAC SDUs served to logical channel j above;
2> if any resources remain, all the logical channels selected in subclause 5.4.3.1.2 are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.
NOTE: The value of Bj can be negative.
If the MAC entity is requested to simultaneously transmit multiple MAC PDUs, or if the MAC entity receives the multiple UL grants within one or more coinciding PDCCH occasions (i.e. on different Serving Cells), it is up to UE implementation in which order the grants are processed.
The UE shall also follow the rules below during the scheduling procedures above:
– the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources of the associated MAC entity;
– if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant of the associated MAC entity as much as possible;
– the UE should maximise the transmission of data;
– if the MAC entity is given a UL grant size that is equal to or larger than 8 bytes while having data available and allowed (according to subclause 5.4.3.1) for transmission, the MAC entity shall not transmit only padding BSR and/or padding.
The MAC entity shall not generate a MAC PDU for the HARQ entity if the following conditions are satisfied:
– the MAC entity is configured with skipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or the grant indicated to the HARQ entity is a configured uplink grant; and
– there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
– the MAC PDU includes zero MAC SDUs; and
– the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR.
Logical channels shall be prioritised in accordance with the following order (highest priority listed first):
– C-RNTI MAC CE or data from UL-CCCH;
– Configured Grant Confirmation MAC CE;
– MAC CE for BSR, with exception of BSR included for padding;
– Single Entry PHR MAC CE or Multiple Entry PHR MAC CE;
– data from any Logical Channel, except data from UL-CCCH;
– MAC CE for Recommended bit rate query;
– MAC CE for BSR included for padding.
7.1.1.3.2b.3 Test description
7.1.1.3.2b.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 3 UM NR DRBs configured according to Table 7.1.1.3.2b.3.1-1.
Table 7.1.1.3.2b.3.1-1: Priority, PBR, Bucket Delay allowed-SCSList settings
DRB |
priority |
prioritizedBitRate (kbytes/s) |
bucketSizeDuration (ms) |
allowed-SCSList |
|
FR1 |
FR2 |
||||
DRB1 |
6 |
8 |
100 |
{15KHz, 30KHz} |
{60KHz, 120KHz} |
DRB2 |
7 |
16 |
100 |
{60KHz} |
{60KHz} |
DRB3 |
8 |
32 |
100 |
{15KHz, 30KHz,60KHz} |
{120KHz} |
Table 7.1.1.3.2b.3.1-2: allowed-SCSList and maxPUSCH-Duration settings
DRB |
allowed-SCSList |
maxPUSCH-Duration |
DRB1 |
Not Present |
ms0p02 |
DRB2 |
Not Present |
ms0p5 |
DRB3 |
Not Present |
ms0p5 |
Table 7.1.1.3.2b.3.1-2a: PUSCH-TimeDomainResourceAllocationList
Derivation Path: TS 38.508-1 [4], table 4.6.3-122 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-TimeDomainResourceAllocationList ::= SEQUENCE (SIZE(1..maxNrofUL-Allocations)) OF PUSCH-TimeDomainResourceAllocation { |
2 entry |
||
PUSCH-TimeDomainResourceAllocation[1] SEQUENCE { |
entry 1 |
||
k2 |
2 |
FR1 |
|
4 |
FR2 |
||
mappingType |
typeB |
||
startSymbolAndLength |
52 |
Start symbol(S)=10, Length(L)=4 |
FR1 |
startSymbolAndLength |
42 |
Start symbol(S)=0, Length(L)=4 |
FR2 |
} |
|||
PUSCH-TimeDomainResourceAllocation[2] SEQUENCE { |
entry 2 |
||
k2 |
2 |
FR1 |
|
4 |
FR2 |
||
mappingType |
typeB |
||
startSymbolAndLength |
27 |
Start symbol(S)=0, Length(L)=14 |
|
} |
|||
} |
Table 7.1.1.3.2b.3.1-3: maxPUSCH-Duration and configuredGrantType1Allowed settings
DRB |
maxPUSCH-Duration |
configuredGrantType1Allowed |
DRB1 |
Not Present |
true |
DRB2 |
Not Present |
false |
DRB3 |
Not Present |
true |
Table 7.1.1.3.2b.3.1-4: PDCP Settings
Parameter |
Value |
Discard_Timer |
ms1500 |
7.1.1.3.2b.3.2 Test procedure sequence
Table 7.1.1.3.2b.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 3 are run using the parameters specified for first run in table 7.1.1.3.2b.3.2-3. |
– |
– |
– |
– |
1 |
The SS transmits N1 320-octet RLC SDUs on DRB1, N2 320-octet RLC SDUs on DRB2, and N3 320-octet RLC SDUs on DRB3. |
<– |
(RLC SDUs) |
– |
– |
– |
EXCEPTION: In parallel to the event described in step 2 the events specified in Table 7.1.1.3.2b.3.2-2 shall take place. |
– |
– |
– |
– |
2 |
The SS is configured for Uplink Grant Allocation Type 2 as defined in TS 38.523-3 [3]. 150 ms after Step 1 (Note1), for a duration of T2, the SS transmits an UL grant of D octets every T1. |
<– |
(UL grants) |
– |
– |
3 |
Check: Are the total number of octets of the UL RLC SDUs received at the SS for each DRB as follows: – total number of octets received for DRB1 is D1 octets +/- 10% – total number of octets received for DRB2 is 0 – total number of octets received for DRB3 is D3 octets +/- 10% otherwise? |
– |
– |
1 |
P |
4 |
SS transmits NR RRCReconfiguration message to configure allowed-SCSList and maxPUSCH-Duration as per Table 7.1.1.3.2b.3.1-2. (Note 2) |
<– |
(NR RRC: RRCReconfiguration) |
– |
– |
– |
EXCEPTION: In parallel to the event described in step 5 the events specified in Table 7.1.1.3.2b.3.2-2a shall take place on DRB2 |
– |
– |
– |
– |
5 |
The UE transmits NR RRCReconfigurationComplete message. (Note 3) |
–> |
(NR RRC: RRCReconfigurationComplete) |
– |
– |
– |
EXCEPTION: Steps 6 to 8 are run using the parameters specified for second run in table 7.1.1.3.2b.3.1-2. |
– |
– |
– |
– |
6 |
The SS transmits N1 320-octet RLC SDUs on DRB1, N2 320-octet RLC SDUs on DRB2, and N3 320-octet RLC SDUs on DRB3. |
<– |
(RLC SDUs) |
– |
– |
– |
EXCEPTION: In parallel to the event described in step 7 the events specified in Table 7.1.1.3.2b.3.2-2 shall take place. |
– |
– |
– |
– |
7 |
The SS is configured for Uplink Grant Allocation Type 2 as defined in TS 38.523-3 [3]. 150 ms after Step 1 (Note1), for a duration of T2, the SS transmits an UL grant of D octets every T1. |
<– |
(UL grants) |
– |
– |
8 |
Check: Are the total number of octets of the UL RLC SDUs received at the SS for each DRB as follows: – total number of octets received for DRB1 are 0 – total number of octets received for DRB2 are D2 octets +/- 10% – total number of octets received for DRB3 are D3 octets +/- 10%? |
– |
– |
2 |
P |
– |
EXCEPTION: Steps 9 to 14 describe behaviour that depends on the UE capability. |
– |
– |
– |
– |
9 |
IF pc_configuredUL_GrantType1 the SS transmits NR RRCReconfiguration message to configure UL configured grant type 1 with UL grant configured 150 ms after Step 11 (Note1), for a duration of T2 and an UL grant of D octets every T1. It also configures maxPUSCH-Duration and configuredGrantType1Allowed as per Table 7.1.1.3.2b.3.1-3 (Note 2) |
<– |
(NR RRC: RRCReconfiguration) |
– |
– |
– |
EXCEPTION: In parallel to the event described in step 10 the events specified in Table 7.1.1.3.2b.3.2-2a shall take place on DRB1 |
– |
– |
– |
– |
10 |
The UE transmits NR RRCReconfigurationComplete message. (Note 3) |
–> |
(NR RRC: RRCReconfigurationComplete) |
– |
– |
– |
EXCEPTION: Steps 11 to 13 are run using the parameters specified for third run in table 7.1.1.3.2b.3.1-1. |
– |
– |
– |
– |
11 |
The SS transmits N1 320-octet RLC SDUs on DRB1, N2 320-octet RLC SDUs on DRB2, and N3 320-octet RLC SDUs on DRB3. |
<– |
(RLC SDUs) |
– |
– |
– |
EXCEPTION: In parallel to the event described in step 9 the events specified in Table 7.1.1.3.2b.3.2-2 shall take place. |
– |
– |
– |
– |
12 |
Check: Are the total number of octets of the UL RLC SDUs received at the SS for each DRB as follows: – total number of octets received for DRB1 are D1 octets +/- 10% – total number of octets received for DRB2 are 0 – total number of octets received for DRB3 are D3 octets +/- 10%? |
– |
– |
3 |
P |
13 |
The SS sends one Uplink Grant to send loop back PDU on DRB 2. |
<– |
(UL grants) |
– |
– |
14 |
The UE transmits the RLC SDU back to the SS. |
–> |
– |
– |
– |
Note 1: This wait time will ensure that a) all octets have been completely received by the UE on all 3 DRBs before the first UL grant is received and b) the Bjs for each logical channel have reached their maximum value i.e. the bucket size of the corresponding logical channel before the first UL grant is received. Note 2: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 3: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete |
Table 7.1.1.3.2b.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit the RLC SDUs back to the SS? |
–> |
– |
1,2,3 |
P |
Table 7.1.1.3.2b.3.2-2a: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE may transmit the RLC SDU back to the SS within one second. |
–> |
– |
– |
– |
Table 7.1.1.3.2b.3.2-3: Test parameter values
Parameter |
First run |
Second run |
Third run |
N1 (SDUs) |
13 |
1 |
13 |
N2 (SDUs) |
1 |
25 |
1 |
N3 (SDUs) |
50 |
50 |
50 |
D (octets) |
1153 |
576 |
1153 |
T1 (ms) |
20 |
20 |
20 |
T2 (ms) |
360 |
860 |
360 |
D1 (octets) |
4160 |
0 |
4160 |
D2 (octets) |
0 |
8000 |
0 |
D3 (octets) |
16000 |
16000 |
16000 |
Note 1: Calculated using the following equation for the case of the least header size:(D1 + D2 + D3) = (D – 6) * T2 / T1. |
7.1.1.3.2b.3.3 Specific message contents
Table 7.1.1.3.2b.3.3-1: SchedulingRequest-Config (Preamble)
Derivation Path: 36.508 [7], Table 4.6.3-20 |
|||
Information Element |
Value/remark |
Comment |
Condition |
sr-TransMax |
n64 |
Table 7.1.1.3.2b.3.3-2: RRCReconfiguration (step 9, Table 7.1.1.3.2b.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
||||||
Information Element |
Value/remark |
Comment |
Condition |
|||
RRCReconfiguration ::= SEQUENCE { |
||||||
criticalExtensions CHOICE { |
||||||
rrcReconfiguration SEQUENCE { |
||||||
radioBearerConfig |
Not present |
|||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
||||
nonCriticalExtension := SEQUENCE{ |
NR |
|||||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||||
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
|||||
} |
||||||
} |
||||||
} |
||||||
} |
Table 7.1.1.3.2b.3.3-3: CellGroupConfig (Table 7.1.1.3.2b.3.3-2: RRCReconfiguration)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
rlc-BearerToAddModList |
Not present |
||
mac-CellGroupConfig |
Not present |
||
physicalCellGroupConfig SEQUENCE { |
|||
cs-RNTI CHOICE { |
|||
setup SEQUENCE{ |
|||
RNTI-Value |
‘FFE0’H |
||
} |
|||
} |
|||
} |
|||
spCellConfig SEQUENCE{ |
|||
servCellIndex |
Not present |
NR |
|
1 |
EN-DC |
||
reconfigurationWithSync |
Not present |
||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
schedulingRequestResourceToAddModList { |
|||
schedulingRequestResourceId |
1 |
||
schedulingRequestID |
0 |
||
periodicityAndOffset CHOICE { |
|||
sl20 |
10 |
||
} |
|||
} |
|||
} |
|||
} |
|||
configuredGrantConfig CHOICE { |
|||
setup SEQUENCE { |
|||
cg-DMRS-Configuration |
DMRS-UplinkConfig |
Reference TS 38.508-1[4], Table 4.6.3-51 |
|
uci-OnPUSCH CHOICE { |
|||
setup SEQUENCE { |
|||
semiStatic SEQUENCE { |
BetaOffsets |
||
betaOffsetACK-Index1 |
9 |
||
betaOffsetACK-Index2 |
9 |
||
betaOffsetACK-Index3 |
9 |
||
betaOffsetCSI-Part1-Index1 |
6 |
||
betaOffsetCSI-Part1-Index2 |
6 |
||
betaOffsetCSI-Part2-Index1 |
6 |
||
betaOffsetCSI-Part2-Index2 |
6 |
||
} |
|||
} |
|||
} |
|||
resourceAllocation |
ResourceAllocationType1 |
||
powerControlLoopToUse |
n0 |
||
p0-PUSCH-Alpha |
1 |
||
nrofHARQ-Processes |
16 |
||
repK |
n1 |
||
periodicity |
Sym20x14 |
15kHz |
|
periodicity |
Sym40x14 |
30kHz |
|
periodicity |
Sym80x14 |
60kHz |
|
periodicity |
Sym160x14 |
120kHz |
|
rrc-ConfiguredUplinkGrant SEQUENCE{ |
|||
timeDomainOffset |
0 |
||
timeDomainAllocation |
0 |
Reference TS 38.508-1 [4], Table 4.6.3-122 |
|
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB = 23 PRB, RBstart = 0, NBWPsize is the size [PRBs] of the active carrier bandwidth part and ontained in TS.38.508-1 [4] clause 4.3.1.1. |
|
antennaPort |
0 |
||
precodingAndNumberOfLayers |
0 |
||
srs-ResourceIndicator |
Not present |
||
mcsAndTBS |
16 |
||
pathlossReferenceIndex |
0 |
||
} |
|||
} |
|||
} |
7.1.1.3.3 Correct handling of MAC control information / Scheduling requests
7.1.1.3.3.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state with SR resource on PUCCH is configured }
ensure that {
when { UE has UL data available for transmission and UE has no UL-SCH resources available and SR_COUNTER is less than sr-TransMax }
then { the UE transmits a SR on every available PUCCH until resources are granted }
}
(2)
with { UE in RRC_CONNECTED state with SR resource on PUCCH is configured }
ensure that {
when { UE receives an UL grant for a new transmission }
then { UE cancels all pending SR(s) }
}
(3)
with { UE in RRC_CONNECTED state with SR resource on PUCCH is configured }
ensure that {
when { UE has UL data available for transmission and UE has no UL-SCH resources available and SR_COUNTER becomes equal to sr-TransMax }
then { the UE transmits a PRACH Preamble to initiate a Random Access procedure }
}
(4)
with { UE in RRC_CONNECTED state with SR resource on PUCCH is configured and logicalChannelSR-DelayTimer is configured }
ensure that {
when { UE has UL data available for transmission on LCH for which logicalChannelSR-DelayTimer is configured and UE has no UL-SCH resources available and SR_COUNTER is less than sr-TransMax }
then { the UE delays transmission of SR until logicalChannelSR-DelayTimer expires }
}
(5)
with { UE in RRC_CONNECTED state with SR resource on PUCCH is configured }
ensure that {
when { UE has UL data available for transmission on LCH for which logicalChannelSR-DelayTimer is not configured and UE has no UL-SCH resources available and SR_COUNTER is less than sr-TransMax }
then { the UE transmits a SR on every available PUCCH until resources are granted }
}
7.1.1.3.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.4.4 and 5.4.5. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.4]
The Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission.
The MAC entity may be configured with zero, one, or more SR configurations. An SR configuration consists of a set of PUCCH resources for SR across different BWPs and cells. For a logical channel, at most one PUCCH resource for SR is configured per BWP.
Each SR configuration corresponds to one or more logical channels. Each logical channel may be mapped to zero or one SR configuration, which is configured by RRC. The SR configuration of the LCH that triggered the BSR (subclause 5.4.5) (if such a configuration exists) is considered as corresponding SR configuration for the triggered SR. For BSR triggered by retxBSR-Timer expiry, the corresponding SR configuration for the triggered SR is that of the highest priority LCH (if such a configuration exists) that has data available for transmission at the time the BSR is triggered.
RRC configures the following parameters for the scheduling request procedure:
– sr-ProhibitTimer (per SR configuration);
– sr-TransMax (per SR configuration);
– sr-ConfigIndex.
The following UE variables are used for the scheduling request procedure:
– SR_COUNTER (per SR configuration).
If an SR is triggered and there are no other SRs pending corresponding to the same SR configuration, the MAC entity shall set the SR_COUNTER of the corresponding SR configuration to 0.
When an SR is triggered, it shall be considered as pending until it is cancelled. All pending SR(s) shall be cancelled and each respective sr-ProhibitTimer shall be stopped when a MAC PDU is assembled and this PDU includes a BSR which contains buffer status up to (and including) the last event that triggered a BSR (see subclause 5.4.5), or when the UL grant(s) can accommodate all pending data available for transmission.
Only PUCCH resources on a BWP which is active at the time of SR transmission occasion are considered valid.
As long as at least one SR is pending, the MAC entity shall for each pending SR:
1> if the MAC entity has no valid PUCCH resource configured for the pending SR:
2> initiate a Random Access procedure (see subclause 5.1) on the SpCell and cancel the pending SR.
1> else, for the SR configuration corresponding to the pending SR:
2> when the MAC entity has an SR transmission occasion on the valid PUCCH resource for SR configured; and
2> if sr-ProhibitTimer is not running at the time of the SR transmission occasion; and
2> if the PUCCH resource for the SR transmission occasion does not overlap with a measurement gap; and
2> if the PUCCH resource for the SR transmission occasion does not overlap with a UL-SCH resource:
3> if SR_COUNTER < sr-TransMax:
4> increment SR_COUNTER by 1;
4> instruct the physical layer to signal the SR on one valid PUCCH resource for SR;
4> start the sr-ProhibitTimer.
3> else:
4> notify RRC to release PUCCH for all serving cells;
4> notify RRC to release SRS for all serving cells;
4> clear any configured downlink assignments and uplink grants;
4> initiate a Random Access procedure (see subclause 5.1) on the SpCell and cancel all pending SRs.
NOTE: The selection of which valid PUCCH resource for SR to signal SR on when the MAC entity has more than one overlapping valid PUCCH resource for the SR transmission occasion is left to UE implementation.
[TS 38.321, clause 5.4.5]
For Regular BSR, the MAC entity shall:
1> if the BSR is triggered for a logical channel for which logicalChannelSR-Delay is configured by upper layers:
2> start or restart the logicalChannelSR-DelayTimer.
1> else:
2> if running, stop the logicalChannelSR-DelayTimer.
…
The MAC entity shall:
1> if the Buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:
2> if UL-SCH resources are available for a new immediate transmission:
3> instruct the Multiplexing and Assembly procedure to generate the BSR MAC CE(s);
3> start or restart periodicBSR-Timer except when all the generated BSRs are long or short Truncated BSRs;
3> start or restart retxBSR-Timer.
2> else if a Regular BSR has been triggered and logicalChannelSR-DelayTimer is not running:
3> if an uplink grant is not a configured grant; or
3> if the Regular BSR was not triggered for a logical channel for which logical channel SR masking (logicalChannelSR-Mask) is setup by upper layers:
4> trigger a Scheduling Request.
7.1.1.3.3.3 Test description
7.1.1.3.3.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 2 AM DRBs configured according to Table 7.1.1.3.3.3.1-1 and Table 7.1.1.3.3.3.1-2 and with MAC-CellGroupConfig configured according to Table 7.1.1.3.3.3.1-3 and Short_DCI condition is applied in NR Serving cell configuration.
Table 7.1.1.3.3.3.1-1: Logical Channel Configuration Settings
Parameter |
DRB1 |
DRB2 |
LogicalChannelIdentity |
LCH4(DRB-Identity +3) |
LCH5(DRB-Identity +3) |
Priority |
7 |
6 |
prioritizedBitRate |
0kbs |
0kbs |
logicalChannelGroup |
2 (LCG ID#2) |
1 (LCG ID#1) |
logicalChannelSR-DelayTimerApplied |
False |
True |
logicalChannelSR-DelayTimer |
Not Present |
sf512 |
Table 7.1.1.3.3.3.1-2: RLC parameters
t-PollRetransmit |
ms80 |
Table 7.1.1.3.3.3.1-3: MAC-CellGroupConfig
Derivation Path: TS 38.308 [6], clause Table 4.6.3-49 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
bsr-Config SEQUENCE { |
|||
periodicBSR-Timer |
infinity |
||
retxBSR-Timer |
sf2560 |
||
} |
|||
phr-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
} |
7.1.1.3.3.3.2 Test procedure sequence
Table 7.1.1.3.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits a MAC PDU containing A MAC Sub PDU containing a RLC SDU on LCH 5 |
<– |
MAC PDU (containing 1 MAC sub PDU) |
– |
– |
2 |
Check: Does the UE transmit Scheduling Requests for logicalChannelSR-DelayTimer (sf512) from step 1? |
–> |
(SR) |
4 |
F |
3 |
Check: Does the UE transmit [x] Scheduling Requests separately on [x] consecutively available PUCCHs after logicalChannelSR-DelayTimer expiry? (Note 1) |
–> |
(SR) |
1,4 |
P |
4 |
The SS transmits an UL grant to allocate UL-SCH resources that are enough to transmit looped back PDU |
<– |
(UL Grant) |
– |
– |
5 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on LCH5? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
6 |
The SS transmits a MAC PDU containing A MAC Sub PDU containing a RLC SDU on LCH 4 |
<– |
MAC PDU (containing 1 MAC sub PDU) |
– |
– |
7 |
Check: Does the UE transmit Scheduling Requests separately on [x] consecutively available PUCCHs? (Note 1) |
–> |
(SR) |
1,5 |
P |
8 |
The SS transmits an UL grant to allocate UL-SCH resources that are enough to transmit looped back PDU |
<– |
(UL Grant ) |
– |
– |
9 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on LCH4? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
10 |
Check: For 1 second, does the UE transmit a Scheduling Request? |
–> |
(SR) |
1,2 |
F |
11 |
The SS transmits a MAC PDU containing a Timing Advance Command MAC Control Element, but does not send any subsequent alignments. |
<– |
MAC PDU (Timing Advance Command) |
– |
– |
12 |
The SS transmits a MAC PDU containing a MAC SDU on LCH 4 |
<– |
MAC PDU (MAC SDU) |
– |
– |
– |
EXCEPTION: Step 13 is repeated less than sr-TransMax times |
– |
– |
– |
– |
13 |
The UE may transmit Scheduling Requests before time alignment timer expires. The SS shall not respond to the Scheduling Requests in this step. (Note 2) |
–> |
(SR) |
– |
– |
14 |
Check: does the UE transmit a preamble on PRACH? |
–> |
(PRACH Preamble) |
3 |
P |
15 |
The SS transmits a Random Access Response including an UL grant to enable UE to transmit C-RNTI MAC Control Element and the MAC SDU as received in step 14. |
<– |
Random Access Response |
– |
– |
16 |
The UE transmit a MAC PDU including a C-RNTI MAC Control Element and a MAC SDU. (Note 3) |
–> |
MAC PDU (MAC Sub PDU containing C-RNTI control element, MAC sub PDU containing MAC SDU) |
– |
– |
17 |
The SS sends PDCCH transmission for UE C-RNTI |
<– |
– |
– |
– |
Note 1: The UE repeats the scheduling requests on every available PUCCH as long as SR_COUNTER < dsr-TransMax and there is UL data available for transmission and there are no resources available to transmit it. At the reception of first Scheduling Request from the UE, SS will be scheduled to transmit a grant after 100ms. Hence SS will receive 10 Scheduling Requests. Note 2: In step 8, SR repetition of [63] times (sr-TransMax (64)) will take at least [63*10 = 630] ms which is smaller than TA timer [infinity]. Note 3: The UE transmission of the MAC PDU ensures that the random access procedure was successful. |
7.1.1.3.3.3.3 Specific message contents
Table 7.1.1.3.3.3.3-1: SchedulingRequestConfig (Preamble)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-155 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequestConfig ::= SEQUENCE { schedulingRequestToAddModList (SIZE(1..maxNrofSR-ConfigPerCellGroup)) OF SSchedulingRequestToAddMod { |
1 entry |
||
SchedulingRequestToAddMod[1] SEQUENCE { |
entry 1 |
||
sr-TransMax |
n64 |
MAX Value |
|
} |
|||
} |
7.1.1.3.4 Correct handling of MAC control information / Buffer status / UL data arrive in the UE Tx buffer / Regular BSR
7.1.1.3.4.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UL data arrives in the UE transmission buffer and the data belongs to a logical channel with higher priority than those for which data is already available for transmission and the new logical channel and the existing logical channels belongs to the different LCG }
then { UE Reports a Long Buffer Status Reporting (BSR) }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { UL data arrives in the UE transmission buffer and there is no data available for transmission for any of the logical channels which belong to a LCG }
then { UE Reports a Short Buffer Status Reporting (BSR) }
}
(3)
with { UE in RRC_CONNECTED state }
ensure that {
when { UL data arrives in the UE transmission buffer and the data belongs to a logical channel with higher priority than those for which data is already available for transmission and the new logical channel and existing logical channels belong to the same LCG }
then { UE Reports a Short Buffer Status Reporting (BSR) }
}
(4)
with { UE in RRC_CONNECTED state }
ensure that {
when { retxBSR-Timer expires and only one LCG has data available for transmission }
then { UE triggers a regular BSR and Reports a Short Buffer Status Reporting (BSR) }
}
(5)
with { UE in RRC_CONNECTED state }
ensure that {
when { a Regular BSR has been triggered and UE has pending data for transmission and UE has only resources to send either BSR report or data }
then { UE transmits the BSR report }
}
(6)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE determines that a BSR has been triggered since the last transmission of a BSR and UE has no UL resources allocated for new transmission for this TTI }
then { UE transmits a scheduling request }
}
(7)
Void.
(8)
with { UE in RRC_CONNECTED state }
ensure that {
when { a Regular BSR has been triggered and UE has pending data on several logical channels for transmission and UE has UL resources to send all pending data including BSR }
then { UE transmits the UL data and reports buffer status reporting (BSR) that indicates there is no more data in the buffer }
}
7.1.1.3.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.4.5, 6.1.3.1, 6.2.1 and TS 38.323 clause 5.6. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.3.1.3]
Logical channels shall be prioritised in accordance with the following order (highest priority listed first):
– C-RNTI MAC CE or data from UL-CCCH;
– Configured Grant Confirmation MAC CE;
– MAC CE for BSR, with exception of BSR included for padding;
– Single Entry PHR MAC CE or Multiple Entry PHR MAC CE;
– data from any Logical Channel, except data from UL-CCCH;
– MAC CE for Recommended bit rate query;
– MAC CE for BSR included for padding.
[TS 38.321, clause 5.4.5]
The Buffer Status reporting (BSR) procedure is used to provide the serving gNB with information about UL data volume in the MAC entity.
RRC configures the following parameters to control the BSR:
– periodicBSR-Timer;
– retxBSR-Timer;
– logicalChannelSR-Delay;
– logicalChannelSR-DelayTimer;
– logicalChannelGroup.
Each logical channel may be allocated to an LCG using the logicalChannelGroup. The maximum number of LCGs is eight.
The MAC entity determines the amount of UL data available for a logical channel according to the data volume calculation procedure in TSs 38.322 and 38.323 [3] [4].
A BSR shall be triggered if any of the following events occur:
– the MAC entity has new UL data available for a logical channel which belongs to an LCG; and either
– the new UL data belongs to a logical channel with higher priority than the priority of any logical channel containing available UL data which belong to any LCG; or
– none of the logical channels which belong to an LCG contains any available UL data.
in which case the BSR is referred below to as ‘Regular BSR’;
– UL resources are allocated and number of padding bits is equal to or larger than the size of the Buffer Status Report MAC CE plus its subheader, in which case the BSR is referred below to as ‘Padding BSR’;
– retxBSR-Timer expires, and at least one of the logical channels which belong to an LCG contains UL data, in which case the BSR is referred below to as ‘Regular BSR’;
– periodicBSR-Timer expires, in which case the BSR is referred below to as ‘Periodic BSR’.
For Regular BSR, the MAC entity shall:
1> if the BSR is triggered for a logical channel for which logicalChannelSR-Delay is configured by upper layers:
2> start or restart the logicalChannelSR-DelayTimer.
1> else:
2> if running, stop the logicalChannelSR-DelayTimer.
For Regular and Periodic BSR, the MAC entity shall:
1> if more than one LCG has data available for transmission when the BSR is to be transmitted:
2> report Long BSR for all LCGs which have data available for transmission.
1> else:
2> report Short BSR.
For Padding BSR:
1> if the number of padding bits is equal to or larger than the size of the Short BSR plus its subheader but smaller than the size of the Long BSR plus its subheader:
2> if more than one LCG has data available for transmission when the BSR is to be transmitted:
3> if the number of padding bits is equal to the size of the Short BSR plus its subheader:
4> report Short Truncated BSR of the LCG with the highest priority logical channel with data available for transmission.
3> else:
4> report Long Truncated BSR of the LCG(s) with the logical channels having data available for transmission following a decreasing order of priority, and in case of equal priority, in increasing order of LCGID.
2> else:
3> report Short BSR;
1> else if the number of padding bits is equal to or larger than the size of the Long BSR plus its subheader:
2> report Long BSR for all LCGs which have data available for transmission.
The MAC entity shall:
1> if the Buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:
2> if UL-SCH resources are available for a new immediate transmission:
3> instruct the Multiplexing and Assembly procedure to generate the BSR MAC CE(s);
3> start or restart periodicBSR-Timer except when all the generated BSRs are long or short Truncated BSRs;
3> start or restart retxBSR-Timer.
2> else if a Regular BSR has been triggered and logicalChannelSR-DelayTimer is not running:
3> if an uplink grant is not a configured grant; or
3> if the Regular BSR was not triggered for a logical channel for which logical channel SR masking (logicalChannelSR-Mask) is setup by upper layers:
4> trigger a Scheduling Request.
A MAC PDU shall contain at most one BSR MAC CE, even when multiple events have triggered a BSR by the time. The Regular BSR and the Periodic BSR shall have precedence over the padding BSR.
The MAC entity shall restart retxBSR-Timer upon reception of a grant for transmission of new data on any UL-SCH.
All triggered BSRs may be cancelled when the UL grant(s) can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC control element plus its subheader. All triggered BSRs shall be cancelled when a BSR is included in a MAC PDU for transmission.
The MAC entity shall transmit at most one BSR in one MAC PDU. Padding BSR shall not be included when the MAC PDU contains a Regular or Periodic BSR.
[TS 38.321, clause 6.1.3.1]
Buffer Status Report (BSR) MAC CEs consist of either:
– Short BSR format (fixed size); or
– Long BSR format (variable size); or
– Short Truncated BSR format (fixed size); or
– Long Truncated BSR format (variable size).
The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in Table 6.2.1-2.
The fields in the BSR MAC CE are defined as follows:
– LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) whose buffer status is being reported. The length of the field is 3 bits;
– LCGi: For the Long BSR format, this field indicates the presence of the Buffer Size field for the logical channel group i. The LCGi field set to "1" indicates that the Buffer Size field for the logical channel group i is reported. The LCGi field set to "0" indicates that the Buffer Size field for the logical channel group i is not reported. For the Long Truncated BSR format, this field indicates whether logical channel group i has data available. The LCGi field set to "1" indicates that logical channel group i has data available. The LCGi field set to "0" indicates that logical channel group i does not have data available;
– Buffer Size: The Buffer Size field identifies the total amount of data available according to the data volume calculation procedure in TSs 38.322 and 38.323 [3] [4] across all logical channels of a logical channel group after the MAC PDU has been built (i.e. after the logical channel prioritization procedure, which may result the value of the Buffer Size field to zero). The amount of data is indicated in number of bytes. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field for the Short BSR format and the Short Truncated BSR format is 5 bits. The length of this field for the Long BSR format and the Long Truncated BSR format is 8 bits. The values for the 5-bit and 8-bit Buffer Size fields are shown in Tables 6.1.3.1-1 and 6.1.3.1-2, respectively. For the Long BSR format and the Long Truncated BSR format, the Buffer Size fields are included in ascending order based on the LCGi. For the Long Truncated BSR format the number of Buffer Size fields included is maximised, while not exceeding the number of padding bits.
NOTE: The number of the Buffer Size fields in the Long Truncated BSR format can be zero.
Figure 6.1.3.1-1: Short BSR and Short Truncated BSR MAC CE
Figure 6.1.3.1-2: Long BSR and Long Truncated BSR MAC CE
Table 6.1.3.1-1: Buffer size levels (in bytes) for 5-bit Buffer Size field
Index |
BS value |
Index |
BS value |
Index |
BS value |
Index |
BS value |
0 |
0 |
8 |
≤ 102 |
16 |
≤ 1446 |
24 |
≤ 20516 |
1 |
≤ 10 |
9 |
≤ 142 |
17 |
≤ 2014 |
25 |
≤ 28581 |
2 |
≤ 14 |
10 |
≤ 198 |
18 |
≤ 2806 |
26 |
≤ 39818 |
3 |
≤ 20 |
11 |
≤ 276 |
19 |
≤ 3909 |
27 |
≤ 55474 |
4 |
≤ 28 |
12 |
≤ 384 |
20 |
≤ 5446 |
28 |
≤ 77284 |
5 |
≤ 38 |
13 |
≤ 535 |
21 |
≤ 7587 |
29 |
≤ 107669 |
6 |
≤ 53 |
14 |
≤ 745 |
22 |
≤ 10570 |
30 |
≤ 150000 |
7 |
≤ 74 |
15 |
≤ 1038 |
23 |
≤ 14726 |
31 |
> 150000 |
Table 6.1.3.1-2: Buffer size levels (in bytes) for 8-bit Buffer Size field
Index |
BS value |
Index |
BS value |
Index |
BS value |
Index |
BS value |
0 |
0 |
64 |
≤ 560 |
128 |
≤ 31342 |
192 |
≤ 1754595 |
1 |
≤ 10 |
65 |
≤ 597 |
129 |
≤ 33376 |
193 |
≤ 1868488 |
2 |
≤ 11 |
66 |
≤ 635 |
130 |
≤ 35543 |
194 |
≤ 1989774 |
3 |
≤ 12 |
67 |
≤ 677 |
131 |
≤ 37850 |
195 |
≤ 2118933 |
4 |
≤ 13 |
68 |
≤ 720 |
132 |
≤ 40307 |
196 |
≤ 2256475 |
5 |
≤ 14 |
69 |
≤ 767 |
133 |
≤ 42923 |
197 |
≤ 2402946 |
6 |
≤ 15 |
70 |
≤ 817 |
134 |
≤ 45709 |
198 |
≤ 2558924 |
7 |
≤ 16 |
71 |
≤ 870 |
135 |
≤ 48676 |
199 |
≤ 2725027 |
8 |
≤ 17 |
72 |
≤ 926 |
136 |
≤ 51836 |
200 |
≤ 2901912 |
9 |
≤ 18 |
73 |
≤ 987 |
137 |
≤ 55200 |
201 |
≤ 3090279 |
10 |
≤ 19 |
74 |
≤ 1051 |
138 |
≤ 58784 |
202 |
≤ 3290873 |
11 |
≤ 20 |
75 |
≤ 1119 |
139 |
≤ 62599 |
203 |
≤ 3504487 |
12 |
≤ 22 |
76 |
≤ 1191 |
140 |
≤ 66663 |
204 |
≤ 3731968 |
13 |
≤ 23 |
77 |
≤ 1269 |
141 |
≤ 70990 |
205 |
≤ 3974215 |
14 |
≤ 25 |
78 |
≤ 1351 |
142 |
≤ 75598 |
206 |
≤ 4232186 |
15 |
≤ 26 |
79 |
≤ 1439 |
143 |
≤ 80505 |
207 |
≤ 4506902 |
16 |
≤ 28 |
80 |
≤ 1532 |
144 |
≤ 85730 |
208 |
≤ 4799451 |
17 |
≤ 30 |
81 |
≤ 1631 |
145 |
≤ 91295 |
209 |
≤ 5110989 |
18 |
≤ 32 |
82 |
≤ 1737 |
146 |
≤ 97221 |
210 |
≤ 5442750 |
19 |
≤ 34 |
83 |
≤ 1850 |
147 |
≤ 103532 |
211 |
≤ 5796046 |
20 |
≤ 36 |
84 |
≤ 1970 |
148 |
≤ 110252 |
212 |
≤ 6172275 |
21 |
≤ 38 |
85 |
≤ 2098 |
149 |
≤ 117409 |
213 |
≤ 6572925 |
22 |
≤ 40 |
86 |
≤ 2234 |
150 |
≤ 125030 |
214 |
≤ 6999582 |
23 |
≤ 43 |
87 |
≤ 2379 |
151 |
≤ 133146 |
215 |
≤ 7453933 |
24 |
≤ 46 |
88 |
≤ 2533 |
152 |
≤ 141789 |
216 |
≤ 7937777 |
25 |
≤ 49 |
89 |
≤ 2698 |
153 |
≤ 150992 |
217 |
≤ 8453028 |
26 |
≤ 52 |
90 |
≤ 2873 |
154 |
≤ 160793 |
218 |
≤ 9001725 |
27 |
≤ 55 |
91 |
≤ 3059 |
155 |
≤ 171231 |
219 |
≤ 9586039 |
28 |
≤ 59 |
92 |
≤ 3258 |
156 |
≤ 182345 |
220 |
≤ 10208280 |
29 |
≤ 62 |
93 |
≤ 3469 |
157 |
≤ 194182 |
221 |
≤ 10870913 |
30 |
≤ 66 |
94 |
≤ 3694 |
158 |
≤ 206786 |
222 |
≤ 11576557 |
31 |
≤ 71 |
95 |
≤ 3934 |
159 |
≤ 220209 |
223 |
≤ 12328006 |
32 |
≤ 75 |
96 |
≤ 4189 |
160 |
≤ 234503 |
224 |
≤ 13128233 |
33 |
≤ 80 |
97 |
≤ 4461 |
161 |
≤ 249725 |
225 |
≤ 13980403 |
34 |
≤ 85 |
98 |
≤ 4751 |
162 |
≤ 265935 |
226 |
≤ 14887889 |
35 |
≤ 91 |
99 |
≤ 5059 |
163 |
≤ 283197 |
227 |
≤ 15854280 |
36 |
≤ 97 |
100 |
≤ 5387 |
164 |
≤ 301579 |
228 |
≤ 16883401 |
37 |
≤ 103 |
101 |
≤ 5737 |
165 |
≤ 321155 |
229 |
≤ 17979324 |
38 |
≤ 110 |
102 |
≤ 6109 |
166 |
≤ 342002 |
230 |
≤ 19146385 |
39 |
≤ 117 |
103 |
≤ 6506 |
167 |
≤ 364202 |
231 |
≤ 20389201 |
40 |
≤ 124 |
104 |
≤ 6928 |
168 |
≤ 387842 |
232 |
≤ 21712690 |
41 |
≤ 132 |
105 |
≤ 7378 |
169 |
≤ 413018 |
233 |
≤ 23122088 |
42 |
≤ 141 |
106 |
≤ 7857 |
170 |
≤ 439827 |
234 |
≤ 24622972 |
43 |
≤ 150 |
107 |
≤ 8367 |
171 |
≤ 468377 |
235 |
≤ 26221280 |
44 |
≤ 160 |
108 |
≤ 8910 |
172 |
≤ 498780 |
236 |
≤ 27923336 |
45 |
≤ 170 |
109 |
≤ 9488 |
173 |
≤ 531156 |
237 |
≤ 29735875 |
46 |
≤ 181 |
110 |
≤ 10104 |
174 |
≤ 565634 |
238 |
≤ 31666069 |
47 |
≤ 193 |
111 |
≤ 10760 |
175 |
≤ 602350 |
239 |
≤ 33721553 |
48 |
≤ 205 |
112 |
≤ 11458 |
176 |
≤ 641449 |
240 |
≤ 35910462 |
49 |
≤ 218 |
113 |
≤ 12202 |
177 |
≤ 683087 |
241 |
≤ 38241455 |
50 |
≤ 233 |
114 |
≤ 12994 |
178 |
≤ 727427 |
242 |
≤ 40723756 |
51 |
≤ 248 |
115 |
≤ 13838 |
179 |
≤ 774645 |
243 |
≤ 43367187 |
52 |
≤ 264 |
116 |
≤ 14736 |
180 |
≤ 824928 |
244 |
≤ 46182206 |
53 |
≤ 281 |
117 |
≤ 15692 |
181 |
≤ 878475 |
245 |
≤ 49179951 |
54 |
≤ 299 |
118 |
≤ 16711 |
182 |
≤ 935498 |
246 |
≤ 52372284 |
55 |
≤ 318 |
119 |
≤ 17795 |
183 |
≤ 996222 |
247 |
≤ 55771835 |
56 |
≤ 339 |
120 |
≤ 18951 |
184 |
≤ 1060888 |
248 |
≤ 59392055 |
57 |
≤ 361 |
121 |
≤ 20181 |
185 |
≤ 1129752 |
249 |
≤ 63247269 |
58 |
≤ 384 |
122 |
≤ 21491 |
186 |
≤ 1203085 |
250 |
≤ 67352729 |
59 |
≤ 409 |
123 |
≤ 22885 |
187 |
≤ 1281179 |
251 |
≤ 71724679 |
60 |
≤ 436 |
124 |
≤ 24371 |
188 |
≤ 1364342 |
252 |
≤ 76380419 |
61 |
≤ 464 |
125 |
≤ 25953 |
189 |
≤ 1452903 |
253 |
≤ 81338368 |
62 |
≤ 494 |
126 |
≤ 27638 |
190 |
≤ 1547213 |
254 |
> 81338368 |
63 |
≤ 526 |
127 |
≤ 29431 |
191 |
≤ 1647644 |
255 |
Reserved |
[TS 38.321, clause 6.2.1]
Table 6.2.1-2 Values of LCID for UL-SCH
Index |
LCID values |
000000 |
CCCH |
000001–100000 |
Identity of the logical channel |
100001–110110 |
Reserved |
110111 |
Configured Grant Confirmation |
111000 |
Multiple Entry PHR |
111001 |
Single Entry PHR |
111010 |
C-RNTI |
111011 |
Short Truncated BSR |
111100 |
Long Truncated BSR |
111101 |
Short BSR |
111110 |
Long BSR |
111111 |
Padding |
[TS 38.323, clause 5.6]
For the purpose of MAC buffer status reporting, the transmitting PDCP entity shall consider the following as PDCP data volume:
– the PDCP SDUs for which no PDCP Data PDUs have been constructed;
– the PDCP Data PDUs that have not been submitted to lower layers;
– the PDCP Control PDUs;
– for AM DRBs, the PDCP SDUs to be retransmitted according to subclause 5.1.2;
– for AM DRBs, the PDCP Data PDUs to be retransmitted according to subclause 5.5.
[TS 38.322, clause 5.5]For the purpose of MAC buffer status reporting, the UE shall consider the following as RLC data volume:
– RLC SDUs and RLC SDU segments that have not yet been included in an RLC data PDU;
– RLC data PDUs that are pending for initial transmission;
– RLC data PDUs that are pending for retransmission (RLC AM).
In addition, if a STATUS PDU has been triggered and t-StatusProhibit is not running or has expired, the UE shall estimate the size of the STATUS PDU that will be transmitted in the next transmission opportunity, and consider this as part of RLC data volume.
7.1.1.3.4.3 Test description
7.1.1.3.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 3 AM DRBs on NR cell configured according to Table 7.1.1.3.4.3.1-1.
Table 7.1.1.3.4.3.1-1: Logical Channel Configuration Settings
Parameter |
Value DRB1 |
Value DRB2 |
Value DRB3 |
LogicalChannelIdentity |
LCH4((DRB-Identity +3) |
LCH5(DRB-Identity +3) |
LCH6(DRB-Identity +3) |
Priority |
8 |
7 |
6 |
prioritizedBitRate |
0 kB/s |
0 kB/s |
0 kB/s |
logicalChannelGroup |
2 (LCG ID#2) |
2 (LCG ID#2) |
1 (LCG ID#1) |
7.1.1.3.4.3.2 Test procedure sequence
Table 7.1.1.3.4.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
2 |
The SS transmits a MAC PDU containing two RLC SDUs of size 12 bytes on LCH4 |
<– |
MAC PDU (2 RLC SDUs on LCH4) |
– |
– |
3 |
SS allocates an UL Grant of 40 bits. (Note 1) |
<– |
(UL Grant, 40 bits) |
– |
– |
4 |
Check: Does the UE transmit a Short BSR with ‘LCG ID’ field set to ‘2’ and ‘Buffer size’ field set to value ‘4’ or bigger? (Note 2) |
–> |
MAC PDU (MAC Short BSR (LCG ID=‘2’, Buffer Size=’4’ or bigger)) |
2,5 |
P |
5 |
Wait for retxBSR-Timer expiry on UE side. |
– |
– |
– |
– |
6 |
Check: Does the UE transmit a scheduling request? |
–> |
(SR) |
6 |
P |
7 |
The SS responds to the scheduling request in step 6 by an UL Grant of 40 bits. (Note 1) |
<– |
(UL Grant, 40 bits) |
– |
– |
8 |
Check: Does the UE transmit a Short BSR with ‘LCG ID’ field set to ‘2’ and ‘Buffer size’ field set to value ‘4’ or bigger? (Note 2) |
–> |
MAC PDU (MAC Short BSR (LCG ID=‘2’, Buffer Size=’4’ or bigger)) |
4,5 |
P |
9 |
The SS transmits a MAC PDU containing one RLC SDU of size 12 bytes on LCH5 |
<– |
MAC PDU (1 RLC SDU on LCH5) |
– |
– |
10 |
Check: Does the UE transmit a scheduling request? |
–> |
(SR) |
6 |
P |
11 |
The SS respond to the scheduling request in step 10 by an UL Grant of 40 bits. (Note 1) |
<– |
(UL Grant, 40 bits) |
– |
– |
12 |
Check: Does the UE transmit a Short BSR with ‘LCG ID’ field set to ‘2’ and ‘Buffer size#1’ field set to value ‘5’ or bigger? (Note 2) |
–> |
MAC PDU (MAC Short BSR (LCG ID=‘2’, Buffer Size=’5’ or bigger)) |
3,5 |
P |
13 |
The SS transmits a MAC PDU containing two RLC SDUs of size 5 bytes on LCH6 |
<– |
MAC PDU (2 RLC SDUs on LCH6) |
– |
– |
14 |
Check: Does the UE transmit a scheduling request? |
–> |
(SR) |
6 |
P |
15 |
The SS responds to the scheduling request in step 14 by one UL Grant of 40 bits. (Note 1) |
<– |
(UL Grant, 40 bits) |
– |
– |
16 |
Check: Does the UE transmit a Long BSR with ‘Buffer size#1’ field set to value ‘1’, ‘Buffer size#2’ field set to value ‘20’ or bigger? (Note 3) |
–> |
MAC PDU (MAC Long BSR (Buffer size#1=’1’ or bigger, Buffer size#2=’20’ or bigger) |
1,5 |
P |
17 |
Wait for retxBSR-Timer expiry on the UE side. |
– |
– |
– |
|
18 |
Check: Does the UE transmit a scheduling request? |
–> |
(SR) |
6 |
P |
19 |
SS allocates an UL Grant of 608 bits. (Note 4) |
<– |
(UL Grant, 608 bits) |
– |
– |
20 |
Check: Does the UE transmit a MAC PDU including five RLC SDUs and BSR? (Note 5) |
–> |
MAC PDU (17-Byte 2 MAC sub PDUs from LCH4, 17-Byte 1 MAC sub PDU from LCH5 and 10-Byte 2 MAC Sub PDUs from LCH6) |
– |
– |
21 |
SS transmits an RLC STATUS PDU to acknowledge correctly received data(LCID=’000100’) |
<– |
RLC STATUS PDU (ACK_SN=2) |
– |
– |
22 |
SS transmits an RLC STATUS PDU to acknowledge correctly received data(LCID=’000101’) |
<– |
RLC STATUS PDU (ACK_SN=1) |
– |
– |
23 |
SS transmits an RLC STATUS PDU to acknowledge correctly received data(LCID=’000110’) |
<– |
RLC STATUS PDU (ACK_SN=2) |
– |
– |
24 |
The SS transmits a MAC PDU containing two MAC SDUs, the first containing a 8 byte RLC SDU with LCID set to LCH4 and the second containing a 7 byte RLC SDU with LCID set to LCH6. |
<– |
MAC PDU |
– |
– |
25 |
The UE sends Scheduling Request |
–> |
(SR) |
– |
– |
26 |
The SS transmits an uplink grant of size 256 bits. (Note 6) |
<– |
(UL grant, 256 bits) |
– |
– |
27 |
Check: Does the UE return a MAC PDU of length 256 bits including RLC SDUs, Padding and Short BSR or LongBSR with Buffer size(s) set to ‘0’? (Note 5) |
–> |
MAC PDU (13-Byte MAC Sub PDU from LC 4 and 12-Byte MAC Sub PDU from LCH6 and 5-Byte MAC Sub PDU containing Long BSR and 2-Byte MAC Sub PDU containing Padding) Or MAC PDU (13-Byte MAC Sub PDU from LCH4 and 12-Byte MAC Sub PDU from LCH6 and 2-Byte MAC Sub PDU containing short BSR and 5-Byte MAC Sub PDU containing Padding) |
8 |
P |
28 |
SS transmits an RLC STATUS PDU to acknowledge correctly received data(LCID=LCH4) |
<– |
RLC STATUS PDU (ACK_SN=3) |
– |
– |
29 |
SS transmits an RLC STATUS PDU to acknowledge correctly received data(LCID=LCH6) |
<– |
RLC STATUS PDU (ACK_SN=3) |
– |
– |
Note 1: 40 bits enables UE to transmit a MAC PDU with a 1 byte MAC BSR header and a Short BSR (1 byte) or a 2 bytes MAC BSR header and a Long BSR (3 bytes with 2 LCG configured). Note 2: UE triggers a Short BSR of type "Regular BSR" to report buffer status for one LCG for that TTI. The UE should not send any of the received RLC SDUs (segmented) due to Regular BSR has higher priority than U-plane logical channels. Note 3: UE triggers and transmit a Long BSR of type "Regular BSR". The UL grant would be enough for UE to transmit one RLC SDU as received in step 8, but Regular BSR has higher priority than U-plane logical channels. Note 4: The UE has 46 bytes of RLC SDU data (received in steps 2, 9 and 13) in the transmission buffer.608 bits enables UE to transmit user data in MAC PDU 2 RLC SDUs of 12 bytes on LCH4, each 3 Bytes RLC Header and 2 Bytes MAC Header resulting in 2 MAC Sub PDUs of 17 Bytes Each. Similarly one 17 Bytes MAC Sub PDU for 12 Bytes RLC SDU on LCH5. Two 5 Bytes RLC SDUs on LCH6 with 3 Bytes RLC header each and 2 Bytes MAC header each, will result in 2 MAC sub PDUs of 10 bytes each. Total comes to 17+17+17+10+10 +3 B LongBSR(2 Bytes LongBSR header + 1 Byte LongBSR) + 2 B padding =76 Bytes. Note 5: The MAC SDUs for the different logical channels may be in any order in the MAC PDU. Note 6: UL grant of 256 bits (LRBs & IMCS as per 38.523-3[3] annex B) is chosen to enable UE to transmit two MAC SDUs of size 11 and 10 bytes in a MAC PDU (8 bytes RLC SDU + 3 bytes AMD PDU header +2 Bytes MAC sub Header + 7 bytes RLC SDU+ 3 bytes AMD PDU header+2 Bytes MAC sub Header + 2 Bytes Long BSR MAC Sub Header + 3 Bytes Long BSR + 2 Bytes MAC Padding Sub PDU) or (8 bytes RLC SDU + 3 bytes AMD PDU header +2 Bytes MAC sub Header + 7 bytes RLC SDU+ 3 bytes AMD PDU header+2 Bytes MAC sub Header + 1 Byte Short BSR MAC Sub Header + 1 Byte Short BSR + 7 Bytes MAC Padding Sub PDU) = 32 Bytes |
7.1.1.3.4.3.3 Specific message contents
Table 7.1.1.3.4.3.3: MAC-CellGroupConfig (preamble)
Derivation Path: TS 38.508-1 [4], clause Table 4.6.3-68 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
bsr-Config SEQUENCE { |
|||
periodicBSR-Timer |
infinity |
||
retxBSR-Timer |
sf320 |
||
} |
|||
phr-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
} |
7.1.1.3.5 Correct handling of MAC control information / Buffer Status / UL resources are allocated / Padding BSR
7.1.1.3.5.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE transmits a MAC PDU and the number of padding bits is equal to the size of a Short BSR plus its subheader and the UE has available data for transmission from more than one LCG in the TTI where the BSR is transmitted }
then { UE reports a Truncated short BSR of the LCG with the highest priority logical channel with data available for transmission }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE transmits a MAC PDU and the number of padding bits is larger than the size of a Short BSR plus its subheader but smaller than the size of a Long BSR plus its subheader and the UE has available data for transmission from more than one LCG in the TTI where the BSR is transmitted }
then { UE reports a Truncated long BSR }
}
(3)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE transmits a MAC PDU and the number of padding bits is equal to or larger than the size of a Short BSR plus its subheader but smaller than the size of a Long BSR plus its subheader and the UE has available data for transmission from only one LCG in the TTI where the BSR is transmitted }
then { UE reports a Short BSR }
}
(4)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE transmits a MAC PDU and the number of padding bits is equal to or larger than the size of a Long BSR plus its subheader }
then { UE reports a long BSR }
}
7.1.1.3.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.4.5, 6.1.3.1 and 6.2.1. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.5]
The Buffer Status reporting (BSR) procedure is used to provide the serving gNB with information about UL data volume in the MAC entity.
RRC configures the following parameters to control the BSR:
– periodicBSR-Timer;
– retxBSR-Timer;
– logicalChannelSR-Delay;
– logicalChannelSR-DelayTimer;
– logicalChannelGroup.
Each logical channel may be allocated to an LCG using the logicalChannelGroup. The maximum number of LCGs is eight.
The MAC entity determines the amount of UL data available for a logical channel according to the data volume calculation procedure in TSs 38.322 and 38.323 [3] [4].
A BSR shall be triggered if any of the following events occur:
– the MAC entity has new UL data available for a logical channel which belongs to an LCG; and either
– the new UL data belongs to a logical channel with higher priority than the priority of any logical channel containing available UL data which belong to any LCG; or
– none of the logical channels which belong to an LCG contains any available UL data.
in which case the BSR is referred below to as ‘Regular BSR’;
– UL resources are allocated and number of padding bits is equal to or larger than the size of the Buffer Status Report MAC CE plus its subheader, in which case the BSR is referred below to as ‘Padding BSR’;
– retxBSR-Timer expires, and at least one of the logical channels which belong to an LCG contains UL data, in which case the BSR is referred below to as ‘Regular BSR’;
– periodicBSR-Timer expires, in which case the BSR is referred below to as ‘Periodic BSR’.
For Regular BSR, the MAC entity shall:
1> if the BSR is triggered for a logical channel for which logicalChannelSR-Delay is configured by upper layers:
2> start or restart the logicalChannelSR-DelayTimer.
1> else:
2> if running, stop the logicalChannelSR-DelayTimer.
For Regular and Periodic BSR, the MAC entity shall:
1> if more than one LCG has data available for transmission when the BSR is to be transmitted:
2> report Long BSR for all LCGs which have data available for transmission.
1> else:
2> report Short BSR.
For Padding BSR:
1> if the number of padding bits is equal to or larger than the size of the Short BSR plus its subheader but smaller than the size of the Long BSR plus its subheader:
2> if more than one LCG has data available for transmission when the BSR is to be transmitted:
3> if the number of padding bits is equal to the size of the Short BSR plus its subheader:
4> report Short Truncated BSR of the LCG with the highest priority logical channel with data available for transmission.
3> else:
4> report Long Truncated BSR of the LCG(s) with the logical channels having data available for transmission following a decreasing order of priority, and in case of equal priority, in increasing order of LCGID.
2> else:
3> report Short BSR;
1> else if the number of padding bits is equal to or larger than the size of the Long BSR plus its subheader:
2> report Long BSR for all LCGs which have data available for transmission.
The MAC entity shall:
1> if the Buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:
2> if UL-SCH resources are available for a new immediate transmission:
3> instruct the Multiplexing and Assembly procedure to generate the BSR MAC CE(s);
3> start or restart periodicBSR-Timer except when all the generated BSRs are long or short Truncated BSRs;
3> start or restart retxBSR-Timer.
2> else if a Regular BSR has been triggered and logicalChannelSR-DelayTimer is not running:
3> if an uplink grant is not a configured grant; or
3> if the Regular BSR was not triggered for a logical channel for which logical channel SR masking (logicalChannelSR-Mask) is setup by upper layers:
4> trigger a Scheduling Request.
A MAC PDU shall contain at most one BSR MAC CE, even when multiple events have triggered a BSR by the time. The Regular BSR and the Periodic BSR shall have precedence over the padding BSR.
The MAC entity shall restart retxBSR-Timer upon reception of a grant for transmission of new data on any UL-SCH.
All triggered BSRs may be cancelled when the UL grant(s) can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC control element plus its subheader. All triggered BSRs shall be cancelled when a BSR is included in a MAC PDU for transmission.
The MAC entity shall transmit at most one BSR in one MAC PDU. Padding BSR shall not be included when the MAC PDU contains a Regular or Periodic BSR.
[TS 38.321, clause 6.1.3.1]
Buffer Status Report (BSR) MAC CEs consist of either:
– Short BSR format (fixed size); or
– Long BSR format (variable size); or
– Short Truncated BSR format (fixed size); or
– Long Truncated BSR format (variable size).
The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in Table 6.2.1-2.
The fields in the BSR MAC CE are defined as follows:
– LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) whose buffer status is being reported. The length of the field is 3 bits;
– LCGi: For the Long BSR format, this field indicates the presence of the Buffer Size field for the logical channel group i. The LCGi field set to "1" indicates that the Buffer Size field for the logical channel group i is reported. The LCGi field set to "0" indicates that the Buffer Size field for the logical channel group i is not reported. For the Long Truncated BSR format, this field indicates whether logical channel group i has data available. The LCGi field set to "1" indicates that logical channel group i has data available. The LCGi field set to "0" indicates that logical channel group i does not have data available;
– Buffer Size: The Buffer Size field identifies the total amount of data available according to the data volume calculation procedure in TSs 38.322 and 38.323 [3] [4] across all logical channels of a logical channel group after the MAC PDU has been built (i.e. after the logical channel prioritization procedure, which may result the value of the Buffer Size field to zero). The amount of data is indicated in number of bytes. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field for the Short BSR format and the Short Truncated BSR format is 5 bits. The length of this field for the Long BSR format and the Long Truncated BSR format is 8 bits. The values for the 5-bit and 8-bit Buffer Size fields are shown in Tables 6.1.3.1-1 and 6.1.3.1-2, respectively. For the Long BSR format and the Long Truncated BSR format, the Buffer Size fields are included in ascending order based on the LCGi. For the Long Truncated BSR format the number of Buffer Size fields included is maximised, while not exceeding the number of padding bits.
NOTE: The number of the Buffer Size fields in the Long Truncated BSR format can be zero.
Figure 6.1.3.1-1: Short BSR and Short Truncated BSR MAC CE
Figure 6.1.3.1-2: Long BSR and Long Truncated BSR MAC CE
Table 6.1.3.1-1: Buffer size levels (in bytes) for 5-bit Buffer Size field
Index |
BS value |
Index |
BS value |
Index |
BS value |
Index |
BS value |
0 |
0 |
8 |
≤ 102 |
16 |
≤ 1446 |
24 |
≤ 20516 |
1 |
≤ 10 |
9 |
≤ 142 |
17 |
≤ 2014 |
25 |
≤ 28581 |
2 |
≤ 14 |
10 |
≤ 198 |
18 |
≤ 2806 |
26 |
≤ 39818 |
3 |
≤ 20 |
11 |
≤ 276 |
19 |
≤ 3909 |
27 |
≤ 55474 |
4 |
≤ 28 |
12 |
≤ 384 |
20 |
≤ 5446 |
28 |
≤ 77284 |
5 |
≤ 38 |
13 |
≤ 535 |
21 |
≤ 7587 |
29 |
≤ 107669 |
6 |
≤ 53 |
14 |
≤ 745 |
22 |
≤ 10570 |
30 |
≤ 150000 |
7 |
≤ 74 |
15 |
≤ 1038 |
23 |
≤ 14726 |
31 |
> 150000 |
Table 6.1.3.1-2: Buffer size levels (in bytes) for 8-bit Buffer Size field
Index |
BS value |
Index |
BS value |
Index |
BS value |
Index |
BS value |
0 |
0 |
64 |
≤ 560 |
128 |
≤ 31342 |
192 |
≤ 1754595 |
1 |
≤ 10 |
65 |
≤ 597 |
129 |
≤ 33376 |
193 |
≤ 1868488 |
2 |
≤ 11 |
66 |
≤ 635 |
130 |
≤ 35543 |
194 |
≤ 1989774 |
3 |
≤ 12 |
67 |
≤ 677 |
131 |
≤ 37850 |
195 |
≤ 2118933 |
4 |
≤ 13 |
68 |
≤ 720 |
132 |
≤ 40307 |
196 |
≤ 2256475 |
5 |
≤ 14 |
69 |
≤ 767 |
133 |
≤ 42923 |
197 |
≤ 2402946 |
6 |
≤ 15 |
70 |
≤ 817 |
134 |
≤ 45709 |
198 |
≤ 2558924 |
7 |
≤ 16 |
71 |
≤ 870 |
135 |
≤ 48676 |
199 |
≤ 2725027 |
8 |
≤ 17 |
72 |
≤ 926 |
136 |
≤ 51836 |
200 |
≤ 2901912 |
9 |
≤ 18 |
73 |
≤ 987 |
137 |
≤ 55200 |
201 |
≤ 3090279 |
10 |
≤ 19 |
74 |
≤ 1051 |
138 |
≤ 58784 |
202 |
≤ 3290873 |
11 |
≤ 20 |
75 |
≤ 1119 |
139 |
≤ 62599 |
203 |
≤ 3504487 |
12 |
≤ 22 |
76 |
≤ 1191 |
140 |
≤ 66663 |
204 |
≤ 3731968 |
13 |
≤ 23 |
77 |
≤ 1269 |
141 |
≤ 70990 |
205 |
≤ 3974215 |
14 |
≤ 25 |
78 |
≤ 1351 |
142 |
≤ 75598 |
206 |
≤ 4232186 |
15 |
≤ 26 |
79 |
≤ 1439 |
143 |
≤ 80505 |
207 |
≤ 4506902 |
16 |
≤ 28 |
80 |
≤ 1532 |
144 |
≤ 85730 |
208 |
≤ 4799451 |
17 |
≤ 30 |
81 |
≤ 1631 |
145 |
≤ 91295 |
209 |
≤ 5110989 |
18 |
≤ 32 |
82 |
≤ 1737 |
146 |
≤ 97221 |
210 |
≤ 5442750 |
19 |
≤ 34 |
83 |
≤ 1850 |
147 |
≤ 103532 |
211 |
≤ 5796046 |
20 |
≤ 36 |
84 |
≤ 1970 |
148 |
≤ 110252 |
212 |
≤ 6172275 |
21 |
≤ 38 |
85 |
≤ 2098 |
149 |
≤ 117409 |
213 |
≤ 6572925 |
22 |
≤ 40 |
86 |
≤ 2234 |
150 |
≤ 125030 |
214 |
≤ 6999582 |
23 |
≤ 43 |
87 |
≤ 2379 |
151 |
≤ 133146 |
215 |
≤ 7453933 |
24 |
≤ 46 |
88 |
≤ 2533 |
152 |
≤ 141789 |
216 |
≤ 7937777 |
25 |
≤ 49 |
89 |
≤ 2698 |
153 |
≤ 150992 |
217 |
≤ 8453028 |
26 |
≤ 52 |
90 |
≤ 2873 |
154 |
≤ 160793 |
218 |
≤ 9001725 |
27 |
≤ 55 |
91 |
≤ 3059 |
155 |
≤ 171231 |
219 |
≤ 9586039 |
28 |
≤ 59 |
92 |
≤ 3258 |
156 |
≤ 182345 |
220 |
≤ 10208280 |
29 |
≤ 62 |
93 |
≤ 3469 |
157 |
≤ 194182 |
221 |
≤ 10870913 |
30 |
≤ 66 |
94 |
≤ 3694 |
158 |
≤ 206786 |
222 |
≤ 11576557 |
31 |
≤ 71 |
95 |
≤ 3934 |
159 |
≤ 220209 |
223 |
≤ 12328006 |
32 |
≤ 75 |
96 |
≤ 4189 |
160 |
≤ 234503 |
224 |
≤ 13128233 |
33 |
≤ 80 |
97 |
≤ 4461 |
161 |
≤ 249725 |
225 |
≤ 13980403 |
34 |
≤ 85 |
98 |
≤ 4751 |
162 |
≤ 265935 |
226 |
≤ 14887889 |
35 |
≤ 91 |
99 |
≤ 5059 |
163 |
≤ 283197 |
227 |
≤ 15854280 |
36 |
≤ 97 |
100 |
≤ 5387 |
164 |
≤ 301579 |
228 |
≤ 16883401 |
37 |
≤ 103 |
101 |
≤ 5737 |
165 |
≤ 321155 |
229 |
≤ 17979324 |
38 |
≤ 110 |
102 |
≤ 6109 |
166 |
≤ 342002 |
230 |
≤ 19146385 |
39 |
≤ 117 |
103 |
≤ 6506 |
167 |
≤ 364202 |
231 |
≤ 20389201 |
40 |
≤ 124 |
104 |
≤ 6928 |
168 |
≤ 387842 |
232 |
≤ 21712690 |
41 |
≤ 132 |
105 |
≤ 7378 |
169 |
≤ 413018 |
233 |
≤ 23122088 |
42 |
≤ 141 |
106 |
≤ 7857 |
170 |
≤ 439827 |
234 |
≤ 24622972 |
43 |
≤ 150 |
107 |
≤ 8367 |
171 |
≤ 468377 |
235 |
≤ 26221280 |
44 |
≤ 160 |
108 |
≤ 8910 |
172 |
≤ 498780 |
236 |
≤ 27923336 |
45 |
≤ 170 |
109 |
≤ 9488 |
173 |
≤ 531156 |
237 |
≤ 29735875 |
46 |
≤ 181 |
110 |
≤ 10104 |
174 |
≤ 565634 |
238 |
≤ 31666069 |
47 |
≤ 193 |
111 |
≤ 10760 |
175 |
≤ 602350 |
239 |
≤ 33721553 |
48 |
≤ 205 |
112 |
≤ 11458 |
176 |
≤ 641449 |
240 |
≤ 35910462 |
49 |
≤ 218 |
113 |
≤ 12202 |
177 |
≤ 683087 |
241 |
≤ 38241455 |
50 |
≤ 233 |
114 |
≤ 12994 |
178 |
≤ 727427 |
242 |
≤ 40723756 |
51 |
≤ 248 |
115 |
≤ 13838 |
179 |
≤ 774645 |
243 |
≤ 43367187 |
52 |
≤ 264 |
116 |
≤ 14736 |
180 |
≤ 824928 |
244 |
≤ 46182206 |
53 |
≤ 281 |
117 |
≤ 15692 |
181 |
≤ 878475 |
245 |
≤ 49179951 |
54 |
≤ 299 |
118 |
≤ 16711 |
182 |
≤ 935498 |
246 |
≤ 52372284 |
55 |
≤ 318 |
119 |
≤ 17795 |
183 |
≤ 996222 |
247 |
≤ 55771835 |
56 |
≤ 339 |
120 |
≤ 18951 |
184 |
≤ 1060888 |
248 |
≤ 59392055 |
57 |
≤ 361 |
121 |
≤ 20181 |
185 |
≤ 1129752 |
249 |
≤ 63247269 |
58 |
≤ 384 |
122 |
≤ 21491 |
186 |
≤ 1203085 |
250 |
≤ 67352729 |
59 |
≤ 409 |
123 |
≤ 22885 |
187 |
≤ 1281179 |
251 |
≤ 71724679 |
60 |
≤ 436 |
124 |
≤ 24371 |
188 |
≤ 1364342 |
252 |
≤ 76380419 |
61 |
≤ 464 |
125 |
≤ 25953 |
189 |
≤ 1452903 |
253 |
≤ 81338368 |
62 |
≤ 494 |
126 |
≤ 27638 |
190 |
≤ 1547213 |
254 |
> 81338368 |
63 |
≤ 526 |
127 |
≤ 29431 |
191 |
≤ 1647644 |
255 |
Reserved |
[TS 38.321, clause 6.2.1]
Table 6.2.1-2: Values of LCID for UL-SCH
Index |
LCID values |
000000 |
CCCH |
000001–100000 |
Identity of the logical channel |
100001–110110 |
Reserved |
110111 |
Configured Grant Confirmation |
111000 |
Multiple Entry PHR |
111001 |
Single Entry PHR |
111010 |
C-RNTI |
111011 |
Short Truncated BSR |
111100 |
Long Truncated BSR |
111101 |
Short BSR |
111110 |
Long BSR |
111111 |
Padding |
7.1.1.3.5.3 Test description
7.1.1.3.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 2 AM DRBs on NR cell configured according to Table 7.1.1.3.5.3.1-1.
Table 7.1.1.3.5.3.1-1: Logical Channel Configuration Settings
Parameter |
DRB1 |
DRB2 |
LogicalChannelIdentity |
LCH4(DRB-Identity +3) |
LCH5(DRB-Identity +3) |
Priority |
7 |
6 |
prioritizedBitRate |
0kbs |
0kbs |
logicalChannelGroup |
2 (LCG ID#2) |
1 (LCG ID#1) |
7.1.1.3.5.3.2 Test procedure sequence
Table 7.1.1.3.5.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
– |
EXCEPTION: Step 2 shall be repeated for 3 times |
– |
– |
– |
– |
2 |
The SS transmits a MAC PDU including an RLC PDU of size 13 bytes on LCH5. |
<– |
MAC PDU (RLC SDU on LCH5) |
– |
– |
3 |
The SS transmits a MAC PDU including an RLC PDU of size 12 bytes on LCH4. |
<– |
MAC PDU (RLC SDU on LCH4) |
– |
– |
4 |
UE transmits a Scheduling Request on PUCCH. |
–> |
(SR) |
– |
– |
5 |
The SS sends an uplink grant of size 40 bits. (Note 1) |
<– |
(UL grant) |
– |
– |
6 |
The UE transmit a Long BSR report. |
–> |
MAC PDU (Long BSR header (LCID=’ 111110’), Long BSR) |
– |
– |
7 |
The SS sends an uplink grant of size 136 bits. (Note 2) |
<– |
(UL grant) |
– |
– |
8 |
Check: Does UE transmit a MAC PDU containing an RLC SDU and a short truncated BSR indicating pending data (‘Buffer size’ field > ‘0’) for logicalChannelGroup 1 (‘LCG ID’ field set to ‘01’)? |
–> |
MAC PDU (MAC sub PDU header for RLC PDU, RLC PDU, short truncated BSR header (LCID=’ 111011’), short truncatedBSR(LCG ID =’01’, Buffer size>’0’)) |
1 |
P |
9 |
The SS sends an uplink grant of size 152 bits. (Note 3) |
<– |
(UL grant) |
– |
– |
10 |
Check: Does UE transmit a MAC PDU containing an RLC SDU and a long truncated BSR indicating pending data available for LCG1 and LCG2 and ‘Buffer size’ field > ‘0’ for logicalChannelGroup 1? |
–> |
MAC PDU (MAC sub PDU header for RLC PDU, RLC PDU, long truncated BSR header (LCID=’ 111100’), long truncatedBSR( LCG1=1, LCG2=1, Buffer size1>’0’)) |
2 |
P |
11 |
The SS sends an uplink grant of size 136 bits. (Note 4) |
<– |
(UL grant) |
– |
– |
12 |
Check: Does UE transmit a MAC PDU containing an RLC SDU and with a Short BSR indicating pending data (‘Buffer size’ field > ‘0’) for logicalChannelGroup 2 (‘LCG ID’ field =’10’)? |
–> |
MAC PDU (MAC sub PDU header for RLC PDU, RLC PDU, Short BSR header(LCID=’11101’), Short BSR(LCG ID =’10’,Buffer size>’0’)) |
3 |
P |
12A |
SS transmits an RLC STATUS PDU to acknowledge correctly received data (LCID=LCH5) |
<– |
RLC STATUS PDU (ACK_SN=3) |
– |
– |
13 |
The SS sends an uplink grant of size 160 bits. (Note 5) |
<– |
(UL grant) |
– |
– |
14 |
Check: Does UE transmit a MAC PDU containing a RLC SDU and a Long BSR? |
–> |
MAC PDU (MAC sub PDU header for RLC PDU, RLC PDU, Long BSR header (LCID=’11110’), Long BSR)) |
4 |
P |
15 |
SS transmits an RLC STATUS PDU to acknowledge correctly received data (LCID=LCH4) |
<– |
RLC STATUS PDU (ACK_SN=1) |
– |
– |
Note 1: 40 bits (LRBs & IMCS as per 38.523-3[3] annex B) enables UE to transmit a MAC PDU with a MAC BSR header (1 byte) and a Short BSR (1 byte) or a MAC BSR header (2 bytes) a Long BSR (3 bytes when 2 LCG configured). Note 2: UE triggers a truncated Short BSR of type "Padding BSR" to report buffer status for one LCG for that TTI. (2 Bytes MAC Data sub PDU header + 13 Bytes MAC SDU + 1 Byte Short truncated BSR sub header + 1 Byte Short truncated BSR = 17 bytes) Note 3: UE triggers a truncated Long BSR of type "Padding BSR" to report buffer status for one LCG for that TTI. (2 Bytes MAC Data sub PDU header + 13 Bytes MAC SDU + 2 Bytes Long truncated BSR sub header + 2 Bytes Long truncated BSR = 19 bytes) Note 4: UE triggers a Short BSR of type "Padding BSR" to report buffer status for one LCG for that TTI. (2 Bytes MAC Data sub PDU header + 13 Bytes MAC SDU + 1 Byte Short BSR sub header + 1 Byte short BSR = 17 bytes) Note 5: UE triggers a long BSR of type "Padding BSR" to report buffer status for one LCG for that TTI. (2 Bytes MAC Data sub PDU header + 12 Bytes MAC SDU + 2 Bytes long BSR sub header + 1 Byte long BSR + 1 byte Padding sub header + 2 bytes Padding = 20 bytes) |
7.1.1.3.5.3.3 Specific message contents
None
7.1.1.3.6 Correct handling of MAC control information / Buffer status / Periodic BSR timer expires
7.1.1.3.6.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { periodicBSR-Timer expires and more than one LCG has buffered data }
then { UE triggers a Periodic BSR and reports Long BSR and restarts the periodicBSR-Timer }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { periodicBSR-Timer expires and one LCG has buffered data }
then { UE triggers a Periodic BSR and reports Short BSR and restarts the periodicBSR-Timer }
}
7.1.1.3.6.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.4.5, 6.1.3.1 and 6.2.1. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.5]
The Buffer Status reporting (BSR) procedure is used to provide the serving gNB with information about UL data volume in the MAC entity.
RRC configures the following parameters to control the BSR:
– periodicBSR-Timer;
– retxBSR-Timer;
– logicalChannelSR-Delay;
– logicalChannelSR-DelayTimer;
– logicalChannelGroup.
Each logical channel may be allocated to an LCG using the logicalChannelGroup. The maximum number of LCGs is eight.
The MAC entity determines the amount of UL data available for a logical channel according to the data volume calculation procedure in TSs 38.322 and 38.323 [3] [4].
A BSR shall be triggered if any of the following events occur:
– the MAC entity has new UL data available for a logical channel which belongs to an LCG; and either
– the new UL data belongs to a logical channel with higher priority than the priority of any logical channel containing available UL data which belong to any LCG; or
– none of the logical channels which belong to an LCG contains any available UL data.
in which case the BSR is referred below to as ‘Regular BSR’;
– UL resources are allocated and number of padding bits is equal to or larger than the size of the Buffer Status Report MAC CE plus its subheader, in which case the BSR is referred below to as ‘Padding BSR’;
– retxBSR-Timer expires, and at least one of the logical channels which belong to an LCG contains UL data, in which case the BSR is referred below to as ‘Regular BSR’;
– periodicBSR-Timer expires, in which case the BSR is referred below to as ‘Periodic BSR’.
For Regular BSR, the MAC entity shall:
1> if the BSR is triggered for a logical channel for which logicalChannelSR-Delay is configured by upper layers:
2> start or restart the logicalChannelSR-DelayTimer.
1> else:
2> if running, stop the logicalChannelSR-DelayTimer.
For Regular and Periodic BSR, the MAC entity shall:
1> if more than one LCG has data available for transmission when the BSR is to be transmitted:
2> report Long BSR for all LCGs which have data available for transmission.
1> else:
2> report Short BSR.
For Padding BSR:
1> if the number of padding bits is equal to or larger than the size of the Short BSR plus its subheader but smaller than the size of the Long BSR plus its subheader:
2> if more than one LCG has data available for transmission when the BSR is to be transmitted:
3> if the number of padding bits is equal to the size of the Short BSR plus its subheader:
4> report Short Truncated BSR of the LCG with the highest priority logical channel with data available for transmission.
3> else:
4> report Long Truncated BSR of the LCG(s) with the logical channels having data available for transmission following a decreasing order of priority, and in case of equal priority, in increasing order of LCGID.
2> else:
3> report Short BSR;
1> else if the number of padding bits is equal to or larger than the size of the Long BSR plus its subheader:
2> report Long BSR for all LCGs which have data available for transmission.
The MAC entity shall:
1> if the Buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:
2> if UL-SCH resources are available for a new immediate transmission:
3> instruct the Multiplexing and Assembly procedure to generate the BSR MAC CE(s);
3> start or restart periodicBSR-Timer except when all the generated BSRs are long or short Truncated BSRs;
3> start or restart retxBSR-Timer.
2> else if a Regular BSR has been triggered and logicalChannelSR-DelayTimer is not running:
3> if an uplink grant is not a configured grant; or
3> if the Regular BSR was not triggered for a logical channel for which logical channel SR masking (logicalChannelSR-Mask) is setup by upper layers:
4> trigger a Scheduling Request.
A MAC PDU shall contain at most one BSR MAC CE, even when multiple events have triggered a BSR by the time. The Regular BSR and the Periodic BSR shall have precedence over the padding BSR.
The MAC entity shall restart retxBSR-Timer upon reception of a grant for transmission of new data on any UL-SCH.
All triggered BSRs may be cancelled when the UL grant(s) can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC control element plus its subheader. All triggered BSRs shall be cancelled when a BSR is included in a MAC PDU for transmission.
The MAC entity shall transmit at most one BSR in one MAC PDU. Padding BSR shall not be included when the MAC PDU contains a Regular or Periodic BSR.
[TS 38.321, clause 6.1.3.1]
Buffer Status Report (BSR) MAC CEs consist of either:
– Short BSR format (fixed size); or
– Long BSR format (variable size); or
– Short Truncated BSR format (fixed size); or
– Long Truncated BSR format (variable size).
The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in Table 6.2.1-2.
The fields in the BSR MAC CE are defined as follows:
– LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) whose buffer status is being reported. The length of the field is 3 bits;
– LCGi: For the Long BSR format, this field indicates the presence of the Buffer Size field for the logical channel group i. The LCGi field set to "1" indicates that the Buffer Size field for the logical channel group i is reported. The LCGi field set to "0" indicates that the Buffer Size field for the logical channel group i is not reported. For the Long Truncated BSR format, this field indicates whether logical channel group i has data available. The LCGi field set to "1" indicates that logical channel group i has data available. The LCGi field set to "0" indicates that logical channel group i does not have data available;
– Buffer Size: The Buffer Size field identifies the total amount of data available according to the data volume calculation procedure in TSs 38.322 and 38.323 [3] [4] across all logical channels of a logical channel group after the MAC PDU has been built (i.e. after the logical channel prioritization procedure, which may result the value of the Buffer Size field to zero). The amount of data is indicated in number of bytes. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field for the Short BSR format and the Short Truncated BSR format is 5 bits. The length of this field for the Long BSR format and the Long Truncated BSR format is 8 bits. The values for the 5-bit and 8-bit Buffer Size fields are shown in Tables 6.1.3.1-1 and 6.1.3.1-2, respectively. For the Long BSR format and the Long Truncated BSR format, the Buffer Size fields are included in ascending order based on the LCGi. For the Long Truncated BSR format the number of Buffer Size fields included is maximised, while not exceeding the number of padding bits.
NOTE: The number of the Buffer Size fields in the Long Truncated BSR format can be zero.
Figure 6.1.3.1-1: Short BSR and Short Truncated BSR MAC CE
Figure 6.1.3.1-2: Long BSR and Long Truncated BSR MAC CE
Table 6.1.3.1-1: Buffer size levels (in bytes) for 5-bit Buffer Size field
Index |
BS value |
Index |
BS value |
Index |
BS value |
Index |
BS value |
0 |
0 |
8 |
≤ 102 |
16 |
≤ 1446 |
24 |
≤ 20516 |
1 |
≤ 10 |
9 |
≤ 142 |
17 |
≤ 2014 |
25 |
≤ 28581 |
2 |
≤ 14 |
10 |
≤ 198 |
18 |
≤ 2806 |
26 |
≤ 39818 |
3 |
≤ 20 |
11 |
≤ 276 |
19 |
≤ 3909 |
27 |
≤ 55474 |
4 |
≤ 28 |
12 |
≤ 384 |
20 |
≤ 5446 |
28 |
≤ 77284 |
5 |
≤ 38 |
13 |
≤ 535 |
21 |
≤ 7587 |
29 |
≤ 107669 |
6 |
≤ 53 |
14 |
≤ 745 |
22 |
≤ 10570 |
30 |
≤ 150000 |
7 |
≤ 74 |
15 |
≤ 1038 |
23 |
≤ 14726 |
31 |
> 150000 |
Table 6.1.3.1-2: Buffer size levels (in bytes) for 8-bit Buffer Size field
Index |
BS value |
Index |
BS value |
Index |
BS value |
Index |
BS value |
0 |
0 |
64 |
≤ 526 |
128 |
≤ 29431 |
192 |
≤ 1647644 |
1 |
≤ 10 |
65 |
≤ 560 |
129 |
≤ 31342 |
193 |
≤ 1754595 |
2 |
≤ 11 |
66 |
≤ 597 |
130 |
≤ 33376 |
194 |
≤ 1868488 |
3 |
≤ 12 |
67 |
≤ 635 |
131 |
≤ 35543 |
195 |
≤ 1989774 |
4 |
≤ 13 |
68 |
≤ 677 |
132 |
≤ 37850 |
196 |
≤ 2118933 |
5 |
≤ 13 |
69 |
≤ 720 |
133 |
≤ 40307 |
197 |
≤ 2256475 |
6 |
≤ 14 |
70 |
≤ 767 |
134 |
≤ 42923 |
198 |
≤ 2402946 |
7 |
≤ 15 |
71 |
≤ 817 |
135 |
≤ 45709 |
199 |
≤ 2558924 |
8 |
≤ 16 |
72 |
≤ 870 |
136 |
≤ 48676 |
200 |
≤ 2725027 |
9 |
≤ 17 |
73 |
≤ 926 |
137 |
≤ 51836 |
201 |
≤ 2901912 |
10 |
≤ 18 |
74 |
≤ 987 |
138 |
≤ 55200 |
202 |
≤ 3090279 |
11 |
≤ 19 |
75 |
≤ 1051 |
139 |
≤ 58784 |
203 |
≤ 3290873 |
12 |
≤ 20 |
76 |
≤ 1119 |
140 |
≤ 62599 |
204 |
≤ 3504487 |
13 |
≤ 22 |
77 |
≤ 1191 |
141 |
≤ 66663 |
205 |
≤ 3731968 |
14 |
≤ 23 |
78 |
≤ 1269 |
142 |
≤ 70990 |
206 |
≤ 3974215 |
15 |
≤ 25 |
79 |
≤ 1351 |
143 |
≤ 75598 |
207 |
≤ 4232186 |
16 |
≤ 26 |
80 |
≤ 1439 |
144 |
≤ 80505 |
208 |
≤ 4506902 |
17 |
≤ 28 |
81 |
≤ 1532 |
145 |
≤ 85730 |
209 |
≤ 4799451 |
18 |
≤ 30 |
82 |
≤ 1631 |
146 |
≤ 91295 |
210 |
≤ 5110989 |
19 |
≤ 32 |
83 |
≤ 1737 |
147 |
≤ 97221 |
211 |
≤ 5442750 |
20 |
≤ 34 |
84 |
≤ 1850 |
148 |
≤ 103532 |
212 |
≤ 5796046 |
21 |
≤ 36 |
85 |
≤ 1970 |
149 |
≤ 110252 |
213 |
≤ 6172275 |
22 |
≤ 38 |
86 |
≤ 2098 |
150 |
≤ 117409 |
214 |
≤ 6572925 |
23 |
≤ 40 |
87 |
≤ 2234 |
151 |
≤ 125030 |
215 |
≤ 6999582 |
24 |
≤ 43 |
88 |
≤ 2379 |
152 |
≤ 133146 |
216 |
≤ 7453933 |
25 |
≤ 46 |
89 |
≤ 2533 |
153 |
≤ 141789 |
217 |
≤ 7937777 |
26 |
≤ 49 |
90 |
≤ 2698 |
154 |
≤ 150992 |
218 |
≤ 8453028 |
27 |
≤ 52 |
91 |
≤ 2873 |
155 |
≤ 160793 |
219 |
≤ 9001725 |
28 |
≤ 55 |
92 |
≤ 3059 |
156 |
≤ 171231 |
220 |
≤ 9586039 |
29 |
≤ 59 |
93 |
≤ 3258 |
157 |
≤ 182345 |
221 |
≤ 10208280 |
30 |
≤ 62 |
94 |
≤ 3469 |
158 |
≤ 194182 |
222 |
≤ 10870913 |
31 |
≤ 66 |
95 |
≤ 3694 |
159 |
≤ 206786 |
223 |
≤ 11576557 |
32 |
≤ 71 |
96 |
≤ 3934 |
160 |
≤ 220209 |
224 |
≤ 12328006 |
33 |
≤ 75 |
97 |
≤ 4189 |
161 |
≤ 234503 |
225 |
≤ 13128233 |
34 |
≤ 80 |
98 |
≤ 4461 |
162 |
≤ 249725 |
226 |
≤ 13980403 |
35 |
≤ 85 |
99 |
≤ 4751 |
163 |
≤ 265935 |
227 |
≤ 14887889 |
36 |
≤ 91 |
100 |
≤ 5059 |
164 |
≤ 283197 |
228 |
≤ 15854280 |
37 |
≤ 97 |
101 |
≤ 5387 |
165 |
≤ 301579 |
229 |
≤ 16883401 |
38 |
≤ 103 |
102 |
≤ 5737 |
166 |
≤ 321155 |
230 |
≤ 17979324 |
39 |
≤ 110 |
103 |
≤ 6109 |
167 |
≤ 342002 |
231 |
≤ 19146385 |
40 |
≤ 117 |
104 |
≤ 6506 |
168 |
≤ 364202 |
232 |
≤ 20389201 |
41 |
≤ 124 |
105 |
≤ 6928 |
169 |
≤ 387842 |
233 |
≤ 21712690 |
42 |
≤ 132 |
106 |
≤ 7378 |
170 |
≤ 413018 |
234 |
≤ 23122088 |
43 |
≤ 141 |
107 |
≤ 7857 |
171 |
≤ 439827 |
235 |
≤ 24622972 |
44 |
≤ 150 |
108 |
≤ 8367 |
172 |
≤ 468377 |
236 |
≤ 26221280 |
45 |
≤ 160 |
109 |
≤ 8910 |
173 |
≤ 498780 |
237 |
≤ 27923336 |
46 |
≤ 170 |
110 |
≤ 9488 |
174 |
≤ 531156 |
238 |
≤ 29735875 |
47 |
≤ 181 |
111 |
≤ 10104 |
175 |
≤ 565634 |
239 |
≤ 31666069 |
48 |
≤ 193 |
112 |
≤ 10760 |
176 |
≤ 602350 |
240 |
≤ 33721553 |
49 |
≤ 205 |
113 |
≤ 11458 |
177 |
≤ 641449 |
241 |
≤ 35910462 |
50 |
≤ 218 |
114 |
≤ 12202 |
178 |
≤ 683087 |
242 |
≤ 38241455 |
51 |
≤ 233 |
115 |
≤ 12994 |
179 |
≤ 727427 |
243 |
≤ 40723756 |
52 |
≤ 248 |
116 |
≤ 13838 |
180 |
≤ 774645 |
244 |
≤ 43367187 |
53 |
≤ 264 |
117 |
≤ 14736 |
181 |
≤ 824928 |
245 |
≤ 46182206 |
54 |
≤ 281 |
118 |
≤ 15692 |
182 |
≤ 878475 |
246 |
≤ 49179951 |
55 |
≤ 299 |
119 |
≤ 16711 |
183 |
≤ 935498 |
247 |
≤ 52372284 |
56 |
≤ 318 |
120 |
≤ 17795 |
184 |
≤ 996222 |
248 |
≤ 55771835 |
57 |
≤ 339 |
121 |
≤ 18951 |
185 |
≤ 1060888 |
249 |
≤ 59392055 |
58 |
≤ 361 |
122 |
≤ 20181 |
186 |
≤ 1129752 |
250 |
≤ 63247269 |
59 |
≤ 384 |
123 |
≤ 21491 |
187 |
≤ 1203085 |
251 |
≤ 67352729 |
60 |
≤ 409 |
124 |
≤ 22885 |
188 |
≤ 1281179 |
252 |
≤ 71724679 |
61 |
≤ 436 |
125 |
≤ 24371 |
189 |
≤ 1364342 |
253 |
≤ 76380419 |
62 |
≤ 464 |
126 |
≤ 25953 |
190 |
≤ 1452903 |
254 |
≤ 81338368 |
63 |
≤ 494 |
127 |
≤ 27638 |
191 |
≤ 1547213 |
255 |
> 81338368 |
[TS 38.321, clause 6.2.1]
Table 6.2.1-2: Values of LCID for UL-SCH
Index |
LCID values |
000000 |
CCCH |
000001–100000 |
Identity of the logical channel |
100001–110110 |
Reserved |
110111 |
Configured Grant Confirmation |
111000 |
Multiple Entry PHR |
111001 |
Single Entry PHR |
111010 |
C-RNTI |
111011 |
Short Truncated BSR |
111100 |
Long Truncated BSR |
111101 |
Short BSR |
111110 |
Long BSR |
111111 |
Padding |
7.1.1.3.6.3 Test description
7.1.1.3.6.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 2 SN terminated SCG bearers configured according to Table 7.1.1.3.6.3.1-1.
Table 7.1.1.3.6.3.1-1: Logical Channel Configuration Settings
Parameter |
DRB1 |
DRB2 |
LogicalChannelIdentity |
LCH4(DRB-Identity +3) |
LCH5(DRB-Identity +3) |
Priority |
7 |
6 |
prioritizedBitRate |
0kbs |
0kbs |
logicalChannelGroup |
2 (LCG ID#2) |
1 (LCG ID#1) |
7.1.1.3.6.3.2 Test procedure sequence
Table 7.1.1.3.6.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
2 |
The SS transmits a MAC PDU containing an RLC PDU on LCH4 (LCG ID 2), which contains 1 RLC SDU of size 14 bytes. |
<– |
MAC PDU (RLC PDU) |
||
3 |
The SS sends an uplink grant of size 32 bits. (Note 1) |
<– |
(UL grant) |
– |
– |
4 |
The UE transmits a short BSR report and restarts periodicBSR-Timer |
–> |
MAC PDU ((LCID=’ 111101’, LCG ID=’10’, Buffer size index > 0) |
– |
– |
– |
EXCEPTION: Steps 5 to 7 shall be repeated two times (Note 2) |
– |
– |
– |
– |
5 |
Wait for periodicBSR-Timer expiry. |
– |
– |
– |
– |
6 |
The SS sends an uplink grant of size 32 bits |
– |
– |
– |
– |
7 |
Check: Does UE transmit a MAC PDU containing a Short BSR with ‘LCG ID’ field set to ‘10’ (logicalChannelGroup 2) and Buffer Size Index > 0? |
–> |
MAC PDU (LCID=’111101’, LCG ID=’10’, Buffer Size index > 0) |
2 |
P |
8 |
The SS transmits a MAC PDU containing an RLC PDU on LCH5 (LCG ID 1), which contains 1 RLC SDU of size 14 bytes. |
<– |
MAC PDU (RLC PDU) |
– |
– |
9 |
The SS sends an uplink grant of size 40 bits (Note 3) |
<– |
(UL grant) |
– |
– |
10 |
The UE transmits a long BSR report with ‘Buffer size#1’ (LCG ID=1) and ‘Buffer size#2’ (LCG ID=2) fields set to value > ‘0’ |
–> |
MAC PDU (( ‘Buffer size#1 index’ > 0, ‘Buffer size#2 index=’ >0’) |
– |
– |
– |
EXCEPTION: Step 11 to 13 shall be repeated twice. (Note 4) |
– |
– |
– |
– |
11 |
Wait for periodicBSR-Timer expiry. |
– |
– |
– |
– |
12 |
The SS sends an uplink grant of size 40 bits |
– |
– |
– |
– |
13 |
Check: Does UE transmit a MAC PDU containing a Long BSR with ‘Buffer size#1’ (LCG ID=1) and ‘Buffer size#2’ (LCG ID=2) fields set to value > ‘0’? |
–> |
MAC PDU |
1 |
P |
14 |
The SS transmits 1 UL grant of size 320 bits to enable the UE to loopback RLC SDU on LCH4 and LCH5. |
– |
– |
||
15 |
The UE transmits MAC PDU containing the remaining RLC SDUs as sent by the SS in steps 2 and 8. |
–> |
MAC PDU |
– |
– |
Note 1: SS transmits an UL grant of 32 bits(LRBs & IMCS as per 38.523-3[3] annex B) to allow UE to transmit a Regular BSR triggered by the new data received logicalChannelGroup 1 in step 2. Note 2: One short BSR due to first expiry of periodicBSR-Timer and one short BSR due to second expire of periodicBSR-Timer. Note 3: SS transmits an UL grant of 40 bits(LRBs & IMCS as per 38.523-3[3] annex B) to allow UE to transmit a Regular BSR triggered by the new data received on higher priority logicalChannelGroup 1 in step 8. Note 4: One long BSR due to expire of periodicBSR-Timer and one long BSR due to second expiry of periodicBSR-Timer. |
7.1.1.3.6.3.3 Specific message contents
Table 7.1.1.3.6.3.3: MAC-CellGroupConfig (preamble)
Derivation Path: TS 38.308 [6], clause Table 4.6.3-49 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
bsr-Config SEQUENCE { |
|||
periodicBSR-Timer |
sf160 |
||
retxBSR-Timer |
sf10240 |
||
} |
|||
phr-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
} |
7.1.1.3.7 UE power headroom reporting / Periodic reporting / DL pathloss change reporting
7.1.1.3.7.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { phr-PeriodicTimer is configured in UE }
then { UE transmits a MAC PDU containing Power Headroom MAC Control Element }
}
(2)
with { UE in RRC_CONNECTED state with periodic power headroom reporting configured }
ensure that {
when { phr-PeriodicTimer expires and UL resources allocated for new transmission }
then { UE transmits a MAC PDU containing Power Headroom MAC Control Element }
}
(3)
with { UE in RRC_CONNECTED state with periodic power headroom reporting configured }
ensure that {
when { power headroom reporting is disabled }
then { UE stops transmitting Power Headroom MAC Control Element }
}
(4)
with { UE in RRC_Connected state with Power headroom reporting for phr-Tx-PowerFactorChange configured }
ensure that {
when { the DL Pathloss has changed more than phr-Tx-PowerFactorChange dB and phr-ProhibitTimer is running }
then { UE does not transmit a MAC PDU containing Power Headroom MAC Control Element }
}
(5)
with { UE in RRC_Connected state with Power headroom reporting for phr-Tx-PowerFactorChange configured }
ensure that {
when { phr-ProhibitTimer expires and power headroom report is triggered due to DL Pathloss change }
then { UE transmits a MAC PDU containing Power Headroom MAC Control Element }
}
7.1.1.3.7.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 38.321 clause 5.4.6 and 6.1.3.8. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.6]
The Power Headroom reporting procedure is used to provide the serving gNB with the following information:
– Type 1 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH transmission per activated Serving Cell;
– Type 2 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH and PUCCH transmission on SpCell of the other MAC entity (i.e. E-UTRA MAC entity in EN-DC case only);
– Type 3 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for SRS transmission per activated Serving Cell.
RRC controls Power Headroom reporting by configuring the following parameters:
– phr-PeriodicTimer;
– phr-ProhibitTimer;
– phr-Tx-PowerFactorChange;
– phr-Type2PCell;
– phr-Type2OtherCell;
– phr-ModeOtherCG;
– multiplePHR.
A Power Headroom Report (PHR) shall be triggered if any of the following events occur:
– phr-ProhibitTimer expires or has expired and the path loss has changed more than phr-Tx-PowerFactorChange dB for at least one activated Serving Cell of any MAC entity which is used as a pathloss reference since the last transmission of a PHR in this MAC entity when the MAC entity has UL resources for new transmission;
NOTE 1: The path loss variation for one cell assessed above is between the pathloss measured at present time on the current pathloss reference and the pathloss measured at the transmission time of the last transmission of PHR on the pathloss reference in use at that time, irrespective of whether the pathloss reference has changed in between.
– phr-PeriodicTimer expires;
– upon configuration or reconfiguration of the power headroom reporting functionality by upper layers, which is not used to disable the function;
– activation of an SCell of any MAC entity with configured uplink;
– addition of the PSCell (i.e. PSCell is newly added or changed);
– phr-ProhibitTimer expires or has expired, when the MAC entity has UL resources for new transmission, and the following is true for any of the activated Serving Cells of any MAC entity with configured uplink:
– there are UL resources allocated for transmission or there is a PUCCH transmission on this cell, and the required power backoff due to power management (as allowed by P-MPRc as specified in TS 38.101-1 [14], TS 38.101-2 [15], and TS 38.101-3 [16]) for this cell has changed more than phr-Tx-PowerFactorChange dB since the last transmission of a PHR when the MAC entity had UL resources allocated for transmission or PUCCH transmission on this cell.
NOTE 2: The MAC entity should avoid triggering a PHR when the required power backoff due to power management decreases only temporarily (e.g. for up to a few tens of milliseconds) and it should avoid reflecting such temporary decrease in the values of PCMAX,f,c/PH when a PHR is triggered by other triggering conditions.
If the MAC entity has UL resources allocated for a new transmission the MAC entity shall:
1> if it is the first UL resource allocated for a new transmission since the last MAC reset:
2> start phr-PeriodicTimer;
1> if the Power Headroom reporting procedure determines that at least one PHR has been triggered and not cancelled; and
1> if the allocated UL resources can accommodate the MAC CE for PHR which the MAC entity is configured to transmit, plus its subheader, as a result of LCP as defined in subclause 5.4.3.1:
2> if multiplePHR is configured:
3> for each activated Serving Cell with configured uplink associated with any MAC entity:
4> obtain the value of the Type 1 or Type 3 power headroom for the corresponding uplink carrier as specified in subclause 7.7 of TS 38.213 [6];
4> if this MAC entity has UL resources allocated for transmission on this Serving Cell; or
4> if the other MAC entity, if configured, has UL resources allocated for transmission on this Serving Cell and phr-ModeOtherCG is set to real by upper layers:
5> obtain the value for the corresponding PCMAX,f,c field from the physical layer.
3> if phr-Type2OtherCell is configured:
4> if the other MAC entity is E-UTRA MAC entity:
5> obtain the value of the Type 2 power headroom for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity);
5> if phr-ModeOtherCG is set to real by upper layers:
6> obtain the value for the corresponding PCMAX,f,c field for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity) from the physical layer.
3> instruct the Multiplexing and Assembly procedure to generate and transmit the Multiple Entry PHR MAC CE as defined in subclause 6.1.3.9 based on the values reported by the physical layer.
2> else (i.e. Single Entry PHR format is used):
3> obtain the value of the Type 1 power headroom from the physical layer for the corresponding uplink carrier of the PCell;
3> obtain the value for the corresponding PCMAX,f,c field from the physical layer;
3> instruct the Multiplexing and Assembly procedure to generate and transmit the Single Entry PHR MAC CE as defined in subclause 6.1.3.8 based on the values reported by the physical layer.
2> start or restart phr-PeriodicTimer;
2> start or restart phr-ProhibitTimer;
2> cancel all triggered PHR(s).
[TS 38.321, clause 6.1.3.8]
The Single Entry PHR MAC CE is identified by a MAC PDU subheader with LCID as specified in Table 6.2.1-2.
It has a fixed size and consists of two octet defined as follows (figure 6.1.3.8-1):
– R: Reserved bit, set to "0";
– Power Headroom (PH): This field indicates the power headroom level. The length of the field is 6 bits. The reported PH and the corresponding power headroom levels are shown in Table 6.1.3.8-1 below (the corresponding measured values in dB are specified in TS 38.133 [11]);
– PCMAX,f,c: This field indicates the PCMAX,f,c (as specified in TS 38.213 [6]) used for calculation of the preceding PH field. The reported PCMAX,f,c and the corresponding nominal UE transmit power levels are shown in Table 6.1.3.8-2 (the corresponding measured values in dBm are specified in TS 38.133 [11]).
Figure 6.1.3.8-1: Single Entry PHR MAC CE
Table 6.1.3.8-1: Power Headroom levels for PHR
PH |
Power Headroom Level |
0 |
POWER_HEADROOM_0 |
1 |
POWER_HEADROOM_1 |
2 |
POWER_HEADROOM_2 |
3 |
POWER_HEADROOM_3 |
… |
… |
60 |
POWER_HEADROOM_60 |
61 |
POWER_HEADROOM_61 |
62 |
POWER_HEADROOM_62 |
63 |
POWER_HEADROOM_63 |
Table 6.1.3.8-2: Nominal UE transmit power level for PHR
PCMAXf,,c |
Nominal UE transmit power level |
0 |
PCMAX_C_00 |
1 |
PCMAX_C_01 |
2 |
PCMAX_C_02 |
… |
… |
61 |
PCMAX_C_61 |
62 |
PCMAX_C_62 |
63 |
PCMAX_C_63 |
7.1.1.3.7.3 Test description
7.1.1.3.7.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.3.7.3.2 Test procedure sequence
Table 7.1.1.3.7.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits UL grant to the UE at every 10ms in PDCCH occasion. |
<– |
– |
– |
– |
2 |
SS transmits NR RRCReconfigurationmessage to configure specific Power Headroom parameters for NR Cell(Note 1). |
<– |
(RRCReconfiguration) |
– |
– |
3 |
Check: does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 2, 5) |
–> |
MAC PDU |
1 |
P |
4 |
The UE transmits an NR RRCReconfigurationComplete message to confirm the setup of Power Headroom parameters. (Note 2,3) |
–> |
(RRCReconfigurationComplete) |
– |
– |
5 |
Check: does the UE transmit a MAC PDU containing Power Headroom MAC Control Element 500ms after step 3? (Note 5) |
–> |
MAC PDU |
2 |
P |
6 |
The SS transmits an NR RRCReconfiguration message to disable Power Headroom reporting.(Note 1) |
<– |
(RRCReconfiguration) |
– |
– |
7 |
The UE transmits an NR RRCReconfigurationComplete message to confirm the disabling of Power Headroom parameters.(Note 3) |
–> |
(RRCReconfigurationComplete) |
– |
– |
8 |
Check: for 2 seconds, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 5) |
–> |
MAC PDU |
3 |
F |
9 |
SS transmits NR RRCReconfigurationmessage to configure specific Power Headroom parameters for NR Cell.(Note 1) |
<– |
(RRCReconfiguration) |
– |
– |
10 |
Check: does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 4, 5) |
–> |
MAC PDU |
1 |
P |
11 |
The UE transmits an NR RRCReconfigurationComplete message to confirm the setup of Power Headroom parameters. (Note 3,4) |
–> |
(RRCReconfigurationComplete) |
– |
– |
12 |
Wait for T1= 20% of prohibitPHR-Timer. |
– |
– |
– |
– |
13 |
Reduce SS power level for NR Cell so as to cause a DL_Pathloss change at UE by 5dB. |
– |
– |
– |
– |
14 |
Check: for 80% of prohibitPHR-Timer since step 10, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 5) |
–> |
MAC PDU |
4 |
F |
15 |
Check: after prohibitPHR-Timer after step 10, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 5) |
–> |
MAC PDU |
5 |
P |
16 |
Increase SS power level for NR Cell so as to cause a DL_Pathloss change at UE by 5dB. |
– |
– |
– |
– |
17 |
Check: for 80% of prohibitPHR-Timer since step 15, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 5) |
–> |
MAC PDU |
4 |
F |
18 |
Check: after prohibitPHR-Timer after step 15, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element? (Note 5) |
–> |
MAC PDU |
5 |
P |
19 |
The SS transmits an NR RRCReconfiguration message to disable Power Headroom reporting.(Note 1) |
<– |
(RRCReconfiguration) |
– |
– |
20 |
The UE transmits an NR RRCReconfigurationComplete message to confirm the disabling of Power Headroom parameters.(Note 3) |
–> |
(RRCReconfigurationComplete) |
– |
– |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: Steps 3 and 4 can happen in any order. Note 3: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 4: Steps 10 and 11 can happen in any order. Note 5: For NR5GC the received MAC PDU will contain Single-entry PHR MAC CE. For EN-DC/NE-DC the received MAC PDU will contain Multiple-Entry PHR MAC CE. |
7.1.1.3.7.3.3 Specific message contents
Table 7.1.1.3.7.3.3-1: RRCReconfiguration (step 2 Table 7.1.1.3.7.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
nonCriticalExtension SEQUENCE { |
NR NE-DC |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.7.3.3-2: CellGroupConfig (Table 7.1.1.3.7.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
phr-Config CHOICE { |
|||
setup SEQUENCE { |
|||
phr-PeriodicTimer |
sf500 |
||
phr-ProhibitTimer |
sf1000 |
||
phr-Tx-PowerFactorChange |
infinity |
||
multiplePHR |
false |
||
multiplePHR |
true |
EN-DC NE-DC |
|
phr-Type2PCell |
false |
||
phr-Type2OtherCell |
false |
||
phr-ModeOtherCG |
real |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.7.3.3-3: RRCReconfiguration (step 6,19 Table 7.1.1.3.7.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
nonCriticalExtension SEQUENCE { |
NR NE-DC |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.7.3.3-4: CellGroupConfig (Table 7.1.1.3.7.3.3-3)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
cellGroupConfig::= SEQUENCE { |
||||
mac-CellGroupConfig SEQUENCE { |
||||
phr-Config CHOICE { |
||||
release |
NULL |
|||
} |
||||
} |
||||
} |
Table 7.1.1.3.7.3.3-5: RRCReconfiguration (step 9 Table 7.1.1.3.7.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
nonCriticalExtension SEQUENCE { |
NR NE-DC |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.7.3.3-6: CellGroupConfig (Table 7.1.1.3.7.3.3-5)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
cellGroupConfig::= SEQUENCE { |
||||
mac-CellGroupConfig SEQUENCE { |
||||
phr-Config CHOICE { |
||||
setup SEQUENCE { |
||||
phr-PeriodicTimer |
infinity |
|||
phr-ProhibitTimer |
sf1000 |
|||
phr-Tx-PowerFactorChange |
3dB |
|||
multiplePHR |
false |
|||
multiplePHR |
true |
EN-DC NE-DC |
||
phr-Type2PCell |
false |
|||
phr-Type2OtherCell |
false |
|||
phr-ModeOtherCG |
real |
|||
} |
||||
} |
||||
} |
||||
} |
7.1.1.3.8 UE power headroom reporting / SCell activation / DL pathloss change reporting
7.1.1.3.8.1 UE power headroom reporting / SCell activation / DL pathloss change reporting/ Intra-band Contiguous CA
7.1.1.3.8.1.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state with multiple Power headroom reporting and an SCell with uplink is configured }
ensure that {
when { UE receives an Activation MAC Control Element activating the SCell }
then { UE transmits a MAC PDU containing Power Headroom Report MAC Control Element including PH type1 for SpCell and Scell }
}
(2)
with { UE in RRC_Connected state with multiple Power headroom reporting for phr-dl-PathlossChange configured }
ensure that {
when { the DL Pathloss changes and phr-ProhibitTimer is running }
then { UE does not transmit a MAC PDU containing Power Headroom Report MAC Control Element including PH type1 for SpCell and Scell }
}
(3)
with { UE in RRC_Connected state with Power headroom reporting for phr-dl-PathlossChange configured }
ensure that {
when { phr-ProhibitTimer expires and power headroom report is triggered due to DL Pathloss change }
then { UE transmits a MAC PDU containing Power Headroom Report MAC Control Element including PH type1 for SpCell and Scell }
}
7.1.1.3.8.1.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 38.321 clause 5.4.6 and 6.1.3.8. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.6]
The Power Headroom reporting procedure is used to provide the serving gNB with the following information:
– Type 1 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH transmission per activated Serving Cell;
– Type 2 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH and PUCCH transmission on SpCell of the other MAC entity (i.e. E-UTRA MAC entity in EN-DC, NE-DC, and NGEN-DC cases);
– Type 3 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for SRS transmission per activated Serving Cell.
RRC controls Power Headroom reporting by configuring the following parameters:
– phr-PeriodicTimer;
– phr-ProhibitTimer;
– phr-Tx-PowerFactorChange;
– phr-Type2OtherCell;
– phr-ModeOtherCG;
– multiplePHR.
A Power Headroom Report (PHR) shall be triggered if any of the following events occur:
– phr-ProhibitTimer expires or has expired and the path loss has changed more than phr-Tx-PowerFactorChange dB for at least one activated Serving Cell of any MAC entity which is used as a pathloss reference since the last transmission of a PHR in this MAC entity when the MAC entity has UL resources for new transmission;
NOTE 1: The path loss variation for one cell assessed above is between the pathloss measured at present time on the current pathloss reference and the pathloss measured at the transmission time of the last transmission of PHR on the pathloss reference in use at that time, irrespective of whether the pathloss reference has changed in between.
– phr-PeriodicTimer expires;
– upon configuration or reconfiguration of the power headroom reporting functionality by upper layers, which is not used to disable the function;
– activation of an SCell of any MAC entity with configured uplink;
– addition of the PSCell (i.e. PSCell is newly added or changed);
– phr-ProhibitTimer expires or has expired, when the MAC entity has UL resources for new transmission, and the following is true for any of the activated Serving Cells of any MAC entity with configured uplink:
– there are UL resources allocated for transmission or there is a PUCCH transmission on this cell, and the required power backoff due to power management (as allowed by P-MPRc as specified in TS 38.101-1 [14], TS 38.101-2 [15], and TS 38.101-3 [16]) for this cell has changed more than phr-Tx-PowerFactorChange dB since the last transmission of a PHR when the MAC entity had UL resources allocated for transmission or PUCCH transmission on this cell.
NOTE 2: The MAC entity should avoid triggering a PHR when the required power backoff due to power management decreases only temporarily (e.g. for up to a few tens of milliseconds) and it should avoid reflecting such temporary decrease in the values of PCMAX,f,c/PH when a PHR is triggered by other triggering conditions.
If the MAC entity has UL resources allocated for a new transmission the MAC entity shall:
1> if it is the first UL resource allocated for a new transmission since the last MAC reset:
2> start phr-PeriodicTimer;
1> if the Power Headroom reporting procedure determines that at least one PHR has been triggered and not cancelled; and
1> if the allocated UL resources can accommodate the MAC CE for PHR which the MAC entity is configured to transmit, plus its subheader, as a result of LCP as defined in clause 5.4.3.1:
2> if multiplePHR with value true is configured:
3> for each activated Serving Cell with configured uplink associated with any MAC entity:
4> obtain the value of the Type 1 or Type 3 power headroom for the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 [6] for NR Serving Cell and clause 5.1.1.2 of TS 36.213 [17] for E-UTRA Serving Cell;
4> if this MAC entity has UL resources allocated for transmission on this Serving Cell; or
4> if the other MAC entity, if configured, has UL resources allocated for transmission on this Serving Cell and phr-ModeOtherCG is set to real by upper layers:
5> obtain the value for the corresponding PCMAX,f,c field from the physical layer.
3> if phr-Type2OtherCell with value true is configured:
4> if the other MAC entity is E-UTRA MAC entity:
5> obtain the value of the Type 2 power headroom for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity);
5> if phr-ModeOtherCG is set to real by upper layers:
6> obtain the value for the corresponding PCMAX,f,c field for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity) from the physical layer.
3> instruct the Multiplexing and Assembly procedure to generate and transmit the Multiple Entry PHR MAC CE as defined in clause 6.1.3.9 based on the values reported by the physical layer.
2> else (i.e. Single Entry PHR format is used):
3> obtain the value of the Type 1 power headroom from the physical layer for the corresponding uplink carrier of the PCell;
3> obtain the value for the corresponding PCMAX,f,c field from the physical layer;
3> instruct the Multiplexing and Assembly procedure to generate and transmit the Single Entry PHR MAC CE as defined in clause 6.1.3.8 based on the values reported by the physical layer.
2> start or restart phr-PeriodicTimer;
2> start or restart phr-ProhibitTimer;
2> cancel all triggered PHR(s).
[TS 38.321, clause 6.1.3.9]
The Multiple Entry PHR MAC CE is identified by a MAC subheader with LCID as specified in Table 6.2.1-2.
It has a variable size, and includes the bitmap, a Type 2 PH field and an octet containing the associated PCMAX,f,c field (if reported) for SpCell of the other MAC entity, a Type 1 PH field and an octet containing the associated PCMAX,f,c field (if reported) for the PCell. It further includes, in ascending order based on the ServCellIndex, one or multiple of Type X PH fields and octets containing the associated PCMAX,f,c fields (if reported) for Serving Cells other than PCell indicated in the bitmap. X is either 1 or 3 according to TS 38.213 [6] and TS 36.213 [17].
The presence of Type 2 PH field for SpCell of the other MAC entity is configured by phr-Type2OtherCell with value true.
A single octet bitmap is used for indicating the presence of PH per Serving Cell when the highest ServCellIndex of Serving Cell with configured uplink is less than 8, otherwise four octets are used.
The MAC entity determines whether PH value for an activated Serving Cell is based on real transmission or a reference format by considering the configured grant(s) and downlink control information which has been received until and including the PDCCH occasion in which the first UL grant for a new transmission that can accommodate the MAC CE for PHR as a result of LCP as defined in clause 5.4.3.1 is received since a PHR has been triggered if the PHR MAC CE is reported on an uplink grant received on the PDCCH or until the first uplink symbol of PUSCH transmission minus PUSCH preparation time as defined in clause 7.7 of TS 38.213 [6] if the PHR MAC CE is reported on a configured grant.
For a band combination in which the UE does not support dynamic power sharing, the UE may omit the octets containing Power Headroom field and PCMAX,f,c field for Serving Cells in the other MAC entity except for the PCell in the other MAC entity and the reported values of Power Headroom and PCMAX,f,c for the PCell are up to UE implementation.
The PHR MAC CEs are defined as follows:
– Ci: This field indicates the presence of a PH field for the Serving Cell with ServCellIndex i as specified in TS 38.331 [5]. The Ci field set to 1 indicates that a PH field for the Serving Cell with ServCellIndex i is reported. The Ci field set to 0 indicates that a PH field for the Serving Cell with ServCellIndex i is not reported;
– R: Reserved bit, set to 0;
– V: This field indicates if the PH value is based on a real transmission or a reference format. For Type 1 PH, the V field set to 0 indicates real transmission on PUSCH and the V field set to 1 indicates that a PUSCH reference format is used. For Type 2 PH, the V field set to 0 indicates real transmission on PUCCH and the V field set to 1 indicates that a PUCCH reference format is used. For Type 3 PH, the V field set to 0 indicates real transmission on SRS and the V field set to 1 indicates that an SRS reference format is used. Furthermore, for Type 1, Type 2, and Type 3 PH, the V field set to 0 indicates the presence of the octet containing the associated PCMAX,f,c field, and the V field set to 1 indicates that the octet containing the associated PCMAX,f,c field is omitted;
– Power Headroom (PH): This field indicates the power headroom level. The length of the field is 6 bits. The reported PH and the corresponding power headroom levels are shown in Table 6.1.3.8-1 (the corresponding measured values in dB for the NR Serving Cell are specified in TS 38.133 [11] while the corresponding measured values in dB for the E-UTRA Serving Cell are specified in TS 36.133 [12]);
– P: This field indicates whether the MAC entity applies power backoff due to power management (as allowed by P-MPRc as specified in TS 38.101-1 [14], TS 38.101-2 [15], and TS 38.101-3 [16]). The MAC entity shall set the P field to 1 if the corresponding PCMAX,f,c field would have had a different value if no power backoff due to power management had been applied;
– PCMAX,f,c: If present, this field indicates the PCMAX,f,c (as specified in TS 38.213 [6]) for the NR Serving Cell and the PCMAX,c or P̃CMAX,c (as specified in TS 36.213 [17]) for the E-UTRA Serving Cell used for calculation of the preceding PH field. The reported PCMAX,f,c and the corresponding nominal UE transmit power levels are shown in Table 6.1.3.8-2 (the corresponding measured values in dBm for the NR Serving Cell are specified in TS 38.133 [11] while the corresponding measured values in dBm for the E-UTRA Serving Cell are specified in TS 36.133 [12]).
Figure 6.1.3.9-1: Multiple Entry PHR MAC CE with the highest ServCellIndex of Serving Cell with configured uplink is less than 8
7.1.1.3.8.1.3 Test description
7.1.1.3.8.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Test loop function(Off) System information combination NR-4 and in addition NR Cell 3 is configured as NR Active Scell.
7.1.1.3.8.1.3.2 Test procedure sequence
Table 7.1.1.3.8.1.3.2-0: Cell configuration power level changes over time for conducted test environment
Parameter |
Unit |
NR Cell 1 |
NR Cell 3 |
Remarks |
|
T0 |
Cell-specific RS EPRE |
dBm/SCS |
-88 |
-88 |
|
T1 |
Cell-specific RS EPRE |
dBm/SCS |
-99 |
-88 |
|
T2 |
Cell-specific RS EPRE |
dBm/SCS |
-88 |
-88 |
|
T3 |
Cell-specific RS EPRE |
dBm/SCS |
-88 |
-99 |
|
T4 |
Cell-specific RS EPRE |
dBm/SCS |
-88 |
-88 |
Table 7.1.1.3.8.1.3.2-0A: Cell configuration power level changes over time for OTA test environment
Parameter |
Unit |
NR Cell 1 |
NR Cell 3 |
Remarks |
|
T0 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
|
T1 |
Cell-specific RS EPRE |
dBm/SCS |
-91 |
-82 |
|
T2 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
|
T3 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-91 |
|
T4 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
Table 7.1.1.3.8.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits an RRCReconfiguration message to configure SCell (NR Cell 3). Note 1 |
<– |
RRCReconfiguration |
– |
– |
2 |
The UE transmits RRCReconfigurationComplete message. Note 2 |
–> |
RRCReconfigurationComplete |
– |
– |
3 |
The SS is configured for Uplink Grant Allocation Type 2. SS is configured to transmit UL grant for UE at every 10 ms. |
– |
– |
– |
– |
4 |
SS transmits an RRCReconfiguration message to provide Power Headroom parameters. Note 1 |
<– |
RRCReconfiguration |
– |
– |
EXCEPTION: In parallel with step 5, UE executes parallel behaviour defined in Table 7.1.1.3.8.1.3.2-2 |
– |
– |
– |
– |
|
5 |
The UE transmits RRCReconfigurationComplete message to confirm the setup of Power Headroom parameters. Note 2 |
–> |
RRCReconfigurationComplete |
– |
– |
6 |
The SS transmits an Activation MAC control element to activate SCell. |
<– |
MAC PDU (SCell Activation/Deactivation MAC CE of one octet (C1=1)) |
– |
– |
7 |
Check: Does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE containing Type 1 PH of NR SpCell and Scell? Note 3 |
–> |
MAC PDU |
1 |
P |
8 |
Void |
– |
– |
– |
– |
9 |
SS adjusts cell levels according to row T1 of Table 7.1.1.3.8.3.1.2-0/0A. |
– |
– |
– |
– |
10 |
Check: For 80% of prohibitPHR-Timer since step 7, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE? |
–> |
MAC PDU |
2 |
F |
11 |
Check: After prohibitPHR-Timer after step 7, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE containing Type 1 PH of NR SpCell and Scell? Note 3 |
–> |
MAC PDU |
3 |
P |
12 |
SS adjusts cell levels according to row T2 of Table 7.1.1.3.8.1.3.2-0/0A. |
– |
– |
– |
– |
13 |
Check: For 80% of prohibitPHR-Timer since step 11, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE ? |
–> |
MAC PDU |
2 |
F |
14 |
Check: After prohibitPHR-Timer after step 11, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE containing Type 1PH of NR SpCell and Scell? Note 3 |
–> |
MAC PDU |
3 |
P |
15 |
SS adjusts cell levels according to row T3 of Table 7.1.1.3.8.1.3.2-0/0A. |
– |
– |
– |
– |
16 |
Check: For 80% of prohibitPHR-Timer since step 14, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE containing? |
–> |
MAC PDU |
2 |
F |
17 |
Check: After prohibitPHR-Timer after step 14, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE containing Type 1 PH of NR SpCell and Scell? Note 3 |
–> |
MAC PDU |
3 |
P |
18 |
SS adjusts cell levels according to row T4 of Table 7.1.1.3.8.1.3.2-0/0A. |
– |
– |
– |
– |
19 |
Check: For 80% of prohibitPHR-Timer since step 17, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE? |
–> |
MAC PDU |
2 |
F |
20 |
Check: After prohibitPHR-Timer after step 17, does the UE transmit a MAC PDU containing Multiple Entry PHR MAC CE containing Type 1 PH of NR SpCell and Scell? Note 3 |
–> |
MAC PDU |
3 |
P |
21 |
The SS transmits an NR RRCReconfiguration message to disable Power Headroom reporting.(Note 1) |
<– |
(RRCReconfiguration) |
– |
– |
22 |
The UE transmits an NR RRCReconfigurationComplete message to confirm the disabling of Power Headroom parameters.(Note 3) |
–> |
(RRCReconfigurationComplete) |
– |
– |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: For EN-DC the Type 1 PHR report for EUTRA Pcell is also included. |
Table 7.1.1.3.8.1.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The UE transmits a MAC PDU containing Multiple Entry PHR MAC CE containing Type 1 PH of NR SpCell. |
–> |
MAC PDU |
– |
– |
7.1.1.3.8.1.3.3 Specific message contents
Table 7.1.1.3.8.1.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.3.8.1.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-13. |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
c1 CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||
} |
||||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.3.8.1.3.3-2: CellGroupConfig (Table 7.1.1.3.8.1.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19. |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
CellGroupConfig ::= SEQUENCE { |
||||
sCellToAddModList SEQUENCE (SIZE (1..maxMeasId)) OF SCellConfig { |
1 entry |
|||
SCellConfig[1] SEQUENCE { |
entry 1 |
|||
sCellIndex |
SCellIndex as per TS 38.508-1 [4] table 4.6.3-154 |
|||
sCellConfigCommon |
ServingCellConfigCommon |
|||
sCellConfigDedicated |
ServingCellConfig |
|||
} |
||||
} |
Table 7.1.1.3.8.1.3.3-3: ServingCellConfigCommon (Table 7.1.1.3.8.1.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168. |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
physCellId |
Physical Cell Identity of NR Cell 3 |
||
} |
Table 7.1.1.3.8.1.3.3-3A: Void
Table 7.1.1.3.8.1.3.3-4: RRCReconfiguration ( Step 4, Table 7.1.1.3.8.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
nonCriticalExtension SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.8.1.3.3-5: CellGroupConfig (Table 7.1.1.3.8.1.3.3-4)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig::= SEQUENCE { |
|||
cellGroupId |
CellGroupId as per TS 38.508-1 [4] table 4.6.3-20 |
||
mac-CellGroupConfig SEQUENCE { |
|||
phr-Config CHOICE { |
|||
setup SEQUENCE { |
|||
phr-PeriodicTimer |
infinity |
||
phr-ProhibitTimer |
sf1000 |
||
phr-Tx-PowerFactorChange |
3db |
||
multiplePHR |
true |
||
dummy |
true |
||
phr-Type2OtherCell |
false |
||
phr-ModeOtherCG |
real |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.8.1.3.3-6: ServingCellConfig (Table 7.1.1.3.8.1.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167. |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.3.8.1.3.3-7: BWP-UplinkDedicated(Table 7.1.1.3.8.1.3.3-6)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config |
Not present |
||
} |
Table 7.1.1.3.8.1.3.3-8: ServingCellConfigCommon (Table 7.1.1.3.8.1.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168. |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
physCellId |
Physical Cell Identity of NR Cell 3 |
||
uplinkConfigCommon |
UplinkConfigCommon |
||
} |
Table 7.1.1.3.8.1.3.3-9: UplinkConfigCommon (Table 7.1.1.3.8.1.3.3-8)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
UplinkConfigCommon ::= SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkCommon |
||
} |
Table 7.1.1.3.8.1.3.3-10: BWP-UplinkCommon (Table 7.1.1.3.8.1.3.3-9)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
pucch-ConfigCommon |
Not present |
||
} |
7.1.1.3.8.2 UE power headroom reporting / SCell activation / DL pathloss change reporting / Inter-band CA
The scope and description of the present TC is the same as test case 7.1.1.3.8.1 with the following differences:
– CA configuration: Inter-band CA replaces Intra-band Contiguous CA
– Cells configuration: NR Cell 10 replaces NR Cell 3
7.1.1.3.8.3 UE power headroom reporting / SCell activation / DL pathloss change reporting / Intra-band non-Contiguous CA
The scope and description of the present TC is the same as test case 7.1.1.3.8.1 with the following differences:
– CA configuration: Intra-band non-Contiguous CA replaces Intra-band Contiguous CA.
7.1.1.3.9 Correct Handling of UL HARQ process / PUSCH Repetition Type A / PUSCH Aggregation
7.1.1.3.9.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and PUSCH Aggregation > 1 }
ensure that {
when { UE receives an UL Grant with toggled NDI and has data available for transmission }
then { UE transmits a new MAC PDU and repeats the MAC PDU pusch-AggregationFactor-1 times after first transmission and selects the redundancy version correctly }
}
7.1.1.3.9.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.214 clauses 6.1.2.1 and 6.1.4, TS 38.321 clauses 5.4.1, 5.4.2.1 and 5.4.2.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.214, clause 6.1.2.1]
When the UE is scheduled to transmit a transport block and no CSI report, or the UE is scheduled to transmit a transport block and a CSI report on PUSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the used resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission.
When the UE is scheduled to transmit a PUSCH with no transport block and with a CSI report by a CSI request field on a DCI, the Time-domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the applied resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission and K2 is determined based on the corresponding list entries of the higher layer parameter reportSlotConfig in CSI-ReportConfig for the triggered CSI Reporting Settings. The ith codepoint of K2 s determined as where is the ith codepoint of .
– The slot where the UE shall transmit the PUSCH is determined by K2 as where n is the slot with the scheduling DCI, K2 is based on the numerology of PUSCH, and and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– The PUSCH mapping type is set to Type A or Type B as defined in Subclause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} |
{0,…,12} |
{1,…,12} |
{1,…,12} |
When the UE is configured with aggregationFactorUL > 1, the same symbol allocation is applied across the aggregationFactorUL consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the aggregationFactorUL consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version when aggregationFactorUL > 1
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
If the UE procedure for determining slot configuration, as defined in subclause 11.1 of [6, TS 38.213], determines symbols of a slot allocated for PUSCH as downlink symbols, the transmission on that slot is omitted for multi-slot PUSCH transmission.
[TS 38.214, clause 6.1.4]
To determine the modulation order, target code rate, redundancy version and transport block size for the physical uplink shared channel, the UE shall first
– read the 5-bit modulation and coding scheme field in the DCI to determine the modulation order and target code rate (R) based on the procedure defined in Subclause 6.1.4.1
– read redundancy version field (rv) in the DCI to determine the redundancy version, and
– [check the "CSI request" bit field]
and second
– the UE shall use the number of layers , the total number of allocated PRBs to determine the transport block size based on the procedure defined in Subclause 6.1.4.2.
[TS 38.321, clause 5.4.1]
Uplink grant is either received dynamically on the PDCCH, in a Random Access Response, or configured semi-persistently by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To perform the requested transmissions, the MAC layer receives HARQ information from lower layers.
If the MAC entity has a C-RNTI, a Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer and for each grant received for this PDCCH occasion:
1> if an uplink grant for this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or
1> if an uplink grant has been received in a Random Access Response:
2> if the uplink grant is for MAC entity’s C-RNTI and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was either an uplink grant received for the MAC entity’s CS-RNTI or a configured uplink grant:
3> consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.
2> if the uplink grant is for MAC entity’s C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
3> start or restart the configuredGrantTimer for the correponding HARQ process, if configured.
2> deliver the uplink grant and the associated HARQ information to the HARQ entity.
1> else if an uplink grant for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured;
3> deliver the uplink grant and the associated HARQ information to the HARQ entity.
2> else if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate configured grant Type 2 deactivation:
4> trigger configured uplink grant confirmation.
3> else if PDCCH contents indicate configured grant Type 2 activation:
4> trigger configured uplink grant confirmation;
4> store the uplink grant for this Serving Cell and the associated HARQ information as configured uplink grant;
4> initialise or re-initialise the configured uplink grant for this Serving Cell to start in the associated PUSCH duration and to recur according to rules in subclause 5.8.2;
4> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
4> consider the NDI bit for the corresponding HARQ process to have been toggled;
4> stop the configuredGrantTimer for the corresponding HARQ process, if running;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall:
1> if the PUSCH duration of the configured uplink grant does not overlap with the PUSCH duration of an uplink grant received on the PDCCH for this Serving Cell:
2> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
2> if the configuredGrantTimer for the corresponding HARQ process is not running:
3> consider the NDI bit for the corresponding HARQ process to have been toggled;
3> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For configured uplink grants, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo nrofHARQ-Processes
where CURRENT_symbol=(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slot number in the frame × numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS 38.211 [8].
NOTE 1: CURRENT_symbol refers to the symbol index of the first transmission occasion of a repetition bundle that takes place.
NOTE 2: A HARQ process is configured for a configured uplink grant if the configured uplink grant is activated and the associated HARQ process ID is less than nrofHARQ-Processes.
[TS 38.321, clause 5.4.2.1]
The MAC entity includes a HARQ entity for each Serving Cell with configured uplink (including the case when it is configured with supplementaryUplink), which maintains a number of parallel HARQ processes.
The number of parallel UL HARQ processes per HARQ entity is specified in TS 38.214 [7].
Each HARQ process supports one TB.
Each HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RA Response, HARQ process identifier 0 is used.
When the MAC entity is configured with pusch-AggregationFactor > 1, the parameter pusch-AggregationFactor provides the number of transmissions of a TB within a bundle of the dynamic grant. After the initial transmission, pusch-AggregationFactor – 1 HARQ retransmissions follow within a bundle. When the MAC entity is configured with repK > 1, the parameter repK provides the number of transmissions of a TB within a bundle of the configured uplink grant. After the initial transmission, HARQ retransmissions follow within a bundle. For both dynamic grant and configured uplink grant, bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle, HARQ retransmissions are triggered without waiting for feedback from previous transmission according to pusch-AggregationFactor for a dynamic grant and repK for a configured uplink grant, respectively. Each transmission within a bundle is a separate uplink grant after the initial uplink grant within a bundle is delivered to the HARQ entity.
For each transmission within a bundle of the dynamic grant, the sequence of redundancy versions is determined according to subclause 6.1.4 of TS 38.214 [7]. For each transmission within a bundle of the configured uplink grant, the sequence of redundancy versions is determined according to subclause 6.1.2.3 of TS 38.214 [7].
For each uplink grant, the HARQ entity shall:
1> identify the HARQ process associated with this grant, and for each identified HARQ process:
2> if the received grant was not addressed to a Temporary C-RNTI on PDCCH, and the NDI provided in the associated HARQ information has been toggled compared to the value in the previous transmission of this TB of this HARQ process; or
2> if the uplink grant was received on PDCCH for the C-RNTI and the HARQ buffer of the identified process is empty; or
2> if the uplink grant was received in a Random Access Response; or
2> if the uplink grant is part of a bundle of the configured uplink grant, and may be used for initial transmission according to subclause 6.1.2.3 of TS 38.214 [7], and if no MAC PDU has been obtained for this bundle:
3> if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a Random Access Response:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
3> else:
4> obtain the MAC PDU to transmit from the Multiplexing and assembly entity, if any;
3> if a MAC PDU to transmit has been obtained:
4> deliver the MAC PDU and the uplink grant and the HARQ information of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a new transmission;
4> if the uplink grant is addressed to CS-RNTI; or
4> if the uplink grant is a configured uplink grant; or
4> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
5> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed.
3> else:
4> flush the HARQ buffer of the identified HARQ process.
2> else (i.e. retransmission):
3> if the uplink grant received on PDCCH was addressed to CS-RNTI and if the HARQ buffer of the identified process is empty; or
3> if the uplink grant is part of a bundle and if no MAC PDU has been obtained for this bundle; or
3> if the uplink grant is part of a bundle of the configured uplink grant, and the PUSCH of the uplink grant overlaps with a PUSCH of another uplink grant received on the PDCCH for this Serving Cell:
4> ignore the uplink grant.
3> else:
4> deliver the uplink grant and the HARQ information (redundancy version) of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a retransmission;
4> if the uplink grant is addressed to CS-RNTI; or
4> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
5> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed.
When determining if NDI has been toggled compared to the value in the previous transmission the MAC entity shall ignore NDI received in all uplink grants on PDCCH for its Temporary C-RNTI.
[TS 38.321, clause 5.4.2.2]
Each HARQ process is associated with a HARQ buffer.
New transmissions are performed on the resource and with the MCS indicated on either PDCCH, Random Access Response, or RRC. Retransmissions are performed on the resource and, if provided, with the MCS indicated on PDCCH, or on the same resource and with the same MCS as was used for last made transmission attempt within a bundle.
If the HARQ entity requests a new transmission for a TB, the HARQ process shall:
1> store the MAC PDU in the associated HARQ buffer;
1> store the uplink grant received from the HARQ entity;
1> generate a transmission as described below.
If the HARQ entity requests a retransmission for a TB, the HARQ process shall:
1> store the uplink grant received from the HARQ entity;
1> generate a transmission as described below.
To generate a transmission for a TB, the HARQ process shall:
1> if the MAC PDU was obtained from the Msg3 buffer; or
1> if there is no measurement gap at the time of the transmission and, in case of retransmission, the retransmission does not collide with a transmission for a MAC PDU obtained from the Msg3 buffer:
2> instruct the physical layer to generate a transmission according to the stored uplink grant.
7.1.1.3.9.3 Test description
7.1.1.3.9.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that DRB is configured in RLC AM mode according to Table 7.1.1.3.9.3.1-1.
Table 7.1.1.3.9.3.1-1: RLC parameters
t-PollRetransmit |
ms80 |
7.1.1.3.9.3.2 Test procedure sequence
Table 7.1.1.3.9.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0A |
SS transmits in the indicated downlink assignment an NR RRCReconfiguration. (Note 1) |
<— |
– |
– |
– |
0B |
UE transmits NR RRCReconfigurationComplete message to the SS. (Note 2) |
–> |
– |
– |
– |
1 |
The SS transmits a valid MAC PDU containing one RLC PDU. |
<— |
MAC PDU |
– |
– |
2 |
The UE transmits a Scheduling Request. |
–> |
(SR) |
– |
– |
3 |
The SS allocates an UL Grant for HARQ process 1, sufficient for one RLC SDU to be looped back in a slot n, and NDI indicates new transmission and DCI scheduling the PUSCH indicates rvID = 0. |
<– |
UL Grant |
– |
– |
4 |
Check: Does the UE transmit a MAC PDU including one RLC SDU, in HARQ process 1 and in slot n+4 and repeats in following pusch-AggregationFactor-1 slots with same resource allocation but different redundancy version (Note 3), if the slot can be used for uplink transmission (Note 4) |
–> |
MAC PDU |
1 |
P |
5 |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDU in step 4. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
|
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: The redundancy version for the first transmission and all possible repetitions are set in the following order {0, 2, 3, 1} according to TS 38.214 [15] Table 6.1.2.1-2, first row. Note 4: Usage of correct redundancy version is implicitely checked upon correct decoding by the SS of the UE UL repetitions. |
7.1.1.3.9.3.3 Specific message contents
Table 7.1.1.3.9.3.3-0A: RRCReconfiguration (step 0A, Table 7.1.1.3.9.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
} |
|||
RRCReconfiguration-v1530-IEs ::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.3.9.3.3-0B: CellGroupConfig (Table 7.1.1.3.9.3.3-0A: RRCReconfiguration)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig::= SEQUENCE { |
|||
cellGroupId |
0 |
||
1 |
EN-DC |
||
spCellConfig SEQUENCE { |
|||
spCellConfigDedicated SEQUENCE { |
|||
servingCellConfig |
ServingCellConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.3.9.3.3-1: ServingCellConfig (Table 7.1.1.3.9.3.3-0B: CellGroupConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.3.9.3.3-2: BWP-UplinkDedicated (Table 7.1.1.3.9.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-11 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pusch-Config CHOICE { |
Not present |
||
Setup |
PUSCH-Config |
||
} |
|||
} |
Table 7.1.1.3.9.3.3-3: PUSCH-Config (Table 7.1.1.3.9.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-118 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-Config ::= SEQUENCE { |
|||
pusch-AggregationFactor |
n4 |
||
n8 |
(TDD AND SCS15) OR FR2 |
||
} |
7.1.1.3.10 Correct Handling of HARQ process / Multiple CORESETPoolIndex
7.1.1.3.10.1. Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and is configured with PDCCH-Config that contains two different values of CORESETPoolIndex in ControlResourceSet }
ensure that {
when { UE receives PDCCHs that schedule two non-overlapping in time domain PUSCHs are associated to different ControlResourceSets having different values of CORESETPoolIndex }
then { UE sends PUSCHs following the scheduling information of PDCCHs }
}
(2)
with(UE in RRC_CONNECTED state and is configured with PDCCH-Config that contains two different values of CORESETPoolIndex in ControlResourceSet)
ensure that {
when{ UE receives PDCCHs that schedule two overlapping in time domain PDSCHs are associated to different ControlResourceSets having different values of CORESETPoolIndex }
then { UE Receives PDSCHs following the scheduling information of PDCCHs }
}
7.1.1.3.10.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.214, clauses 5.18.10 and 6.1.20. Unless otherwise stated these are Rel-16 requirements.
[TS 38.214, clause 5.11]
If a UE is configured by higher layer parameter PDCCH-Config that contains two different values of CORESETPoolIndex in ControlResourceSet, the UE may expect to receive multiple PDCCHs scheduling fully/partially/non-overlapped PDSCHs in time and frequency domain. The UE may expect the reception of full/partially-overlapped PDSCHs in time only when PDCCHs that schedule two PDSCHs are associated to different ControlResourceSets having different values of CORESETPoolIndex. For a ControlResourceSet without CORESETPoolIndex, the UE may assume that the ControlResourceSet is assigned with CORESETPoolIndex as 0. When the UE is scheduled with full/partially/non-overlapped PDSCHs in time and frequency domain, the full scheduling information for receiving a PDSCH is indicated and carried only by the corresponding PDCCH, the UE is expected to be scheduled with the same active BWP and the same SCS. When the UE is scheduled with full/partially-overlapped PDSCHs in time and frequency domain, the UE can be scheduled with at most two codewords simultaneously. When PDCCHs that schedule two PDSCHs are associated to different ControlResourceSets having different values of CORESETPoolIndex, the following operations are allowed:
– For any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start receiving a first PDSCH starting in symbol j by a PDCCH associated with a value of CORESETpoolIndex ending in symbol i, the UE can be scheduled to receive a PDSCH starting earlier than the end of the first PDSCH with a PDCCH associated with a different value of CORESETpoolIndex that ends later than symbol i.
– In a given scheduled cell, the UE can receive a first PDSCH in slot i, with the corresponding HARQ-ACK assigned to be transmitted in slot j, and a second PDSCH associated with a value of CORESETpoolindex different from that of the first PDSCH starting later than the first PDSCH with its corresponding HARQ-ACK assigned to be transmitted in a slot before slot j.
If PDCCHs that schedule corresponding PDSCHs are associated to the same or different ControlResourceSets having the same value of CORESETPoolIndex, the UE procedure for receiving the PDSCH upon detection of a PDCCH follows Clause 5.1.
[TS 38.214, clause 6.1]
If a UE is configured by higher layer parameter PDCCH-Config that contains two different values of CORESETPoolIndex in ControlResourceSet for the active BWP of a serving cell and PDCCHs that schedule two non-overlapping in time domain PUSCHs are associated to different ControlResourceSets having different values of CORESETPoolIndex, for any two HARQ process IDs in a given scheduled cell, if the UE is scheduled to start a first PUSCH transmission starting in symbol j by a PDCCH associated with a value of CORESETpoolIndex ending in symbol i, the UE can be scheduled to transmit a PUSCH starting earlier than the end of the first PUSCH by a PDCCH associated with a different value of CORESETpoolIndex that ends later than symbol i.
7.1.1.3.10.3 Test description
7.1.1.3.10.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.3.10.3.2 Test procedure sequence
Table 7.1.1.3.10.3.2-2: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration message to configure two different values of CORESETPoolIndex in ControlResourceSet, (Note1) |
<– |
– |
– |
– |
2 |
The UE transmitNR RRCReconfigurationComplete messages (Note 2) |
–> |
– |
– |
– |
3 |
The SS transmits 2 MAC PDU’s on overlapping PDSCH’s scheduled by two different values of CORESETPoolIndex in ControlResourceSet |
<– |
MAC PDU 1, MAC PDU 2 |
– |
– |
4 |
100 ms after step 4, the SS transmits a two UL grants scheduling two non-overlapping in time domain PUSCHs associated to different ControlResourceSets having different values of CORESETPoolIndex |
<– |
(UL Grant 1, UL Grant 2) |
– |
– |
5 |
Check: The UE transmits 2 MAC PDU’s loop backed PDU’s from step 4 |
–> |
MAC PDU 1, MAC PDU 2 |
1,2 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.3.10.3.3 Specific message contents
Table 7.1.1.3.10.3.3-1: PDCCH-Config (Preamble)
Derivation Path: TS 38.508-1 [4],Table 4.6.3-95 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDCCH-Config::= SEQUENCE { |
|||
controlResourceSetToAddModList SEQUENCE(SEQUENCE(SIZE (1..3)) OF ControlResourceSet { |
2 entries |
||
ControlResourceSet[1] |
ControlResourceSetid1 |
entry 1 |
|
ControlResourceSet[2] |
ControlResourceSetid2 |
entry 2 |
|
} |
|||
} |
Table 7.1.1.3.10.3.3-2: ControlResourceSetId1 (Table 7.1.1.3.10.3.3-1: PDCCH-Config)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ControlResourceSet ::= SEQUENCE { |
|||
controlResourceSetId |
1 |
||
coresetPoolIndex-r16 |
0 |
||
} |
Table 7.1.1.3.10.3.3-3: ControlResourceSetId2 (Table 7.1.1.3.10.3.3-1: PDCCH-Config)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ControlResourceSet ::= SEQUENCE { |
|||
controlResourceSetId |
2 |
||
coresetPoolIndex-r16 |
1 |
||
} |
7.1.1.3.11 Correct handling of UL grant prioritization
7.1.1.3.11.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED and configured with lch-basedPrioritization,and a resource conflict happened when the UE is sending data based on a UL grant which is addressed to CS-RNTI with NDI = 1 or C-RNTI }
ensure that {
when { the data causes the resource conflict is based on a configured UL grant whose priority is lower than or equal to the UL grant’s }
then { UE determines the UL grant to be prioritized and sends the corresponding MAC PDU.}
}
(2)
with { UE in RRC_CONNECTED and configured with lch-basedPrioritization,a resource conflict happened when the UE is sending data based on a UL grant which is addressed to CS-RNTI with NDI = 1 or C-RNTI, and UE determines the UL grant to be prioritized }
ensure that {
when { UE sends out the MAC PDU associated with the prioritized grant }
then { autonomously re-transmit the MAC PDU associated with the de-prioritized grant.}
}
7.1.1.3.11.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.4.1 and 5.4.2.1. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.4.1]
…
For the MAC entity configured with lch-basedPrioritization, priority of an uplink grant is determined by the highest priority among priorities of the logical channels with data available that are multiplexed or can be multiplexed in the MAC PDU, according to the mapping restrictions as described in clause 5.4.3.1.2. The priority of an uplink grant for which no data for logical channels is multiplexed or can be multiplexed in the MAC PDU is lower than either the priority of an uplink grant for which data for any logical channels is multiplexed or can be multiplexed in the MAC PDU or the priority of the logical channel triggering an SR.
If the corresponding PUSCH transmission of a configured uplink grant is cancelled by CI-RNTI as specified in clause 11.2A of TS 38.213 [6] or cancelled by a high PHY-priority PUCCH transmission as specified in clause 9 of TS 38.213 [6], this uplink grant is considered as a de-prioritized uplink grant.
When the MAC entity is configured with lch-basedPrioritization, for each uplink grant whose associated PUSCH can be transmitted by lower layers, the MAC entity shall:
1> if this uplink grant is addressed to CS-RNTI with NDI = 1 or C-RNTI:
2> if there is no overlapping PUSCH duration of a configured uplink grant which was not already de-prioritized, in the same BWP whose priority is higher than the priority of the uplink grant; and
2> if there is no overlapping PUCCH resource with an SR transmission which was not already de-prioritized and the priority of the logical channel that triggered the SR is higher than the priority of the uplink grant:
3> consider this uplink grant as a prioritized uplink grant;
3> consider the other overlapping uplink grant(s), if any, as a de-prioritized uplink grant(s);
3> consider the other overlapping SR transmission(s), if any, as a de-prioritized SR transmission(s).
1> else if this uplink grant is a configured uplink grant:
2> if there is no overlapping PUSCH duration of another configured uplink grant which was not already de-prioritized, in the same BWP, whose priority is higher than the priority of the uplink grant; and
2> if there is no overlapping PUSCH duration of an uplink grant addressed to CS-RNTI with NDI = 1 or C-RNTI which was not already de-prioritized, in the same BWP, whose priority is higher than or equal to the priority of the uplink grant; and
2> if there is no overlapping PUCCH resource with an SR transmission which was not already de-prioritized and the priority of the logical channel that triggered the SR is higher than the priority of the uplink grant:
3> consider this uplink grant as a prioritized uplink grant;
3> consider the other overlapping uplink grant(s), if any, as a de-prioritized uplink grant(s);
3> consider the other overlapping SR transmission(s), if any, as a de-prioritized SR transmission(s).
NOTE 6: If the MAC entity is configured with lch-basedPrioritization and if there is overlapping PUSCH duration of at least two configured uplink grants whose priorities are equal, the prioritized uplink grant is determined by UE implementation.
NOTE 7: If the MAC entity is not configured with lch-basedPrioritzation and if there is overlapping PUSCH duration of at least two configured uplink grants, it is up to UE implementation to choose one of the configured uplink grants.
[TS 38.321, clause 5.4.2.1]
The MAC entity includes a HARQ entity for each Serving Cell with configured uplink (including the case when it is configured with supplementaryUplink), which maintains a number of parallel HARQ processes.
The number of parallel UL HARQ processes per HARQ entity is specified in TS 38.214 [7].
Each HARQ process supports one TB.
Each HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RA Response or for UL transmission for MSGA payload, HARQ process identifier 0 is used.
NOTE: When a single DCI is used to schedule multiple PUSCH, the UE is allowed to map generated TB(s) internally to different HARQ processes in case of LBT failure(s), i.e. UE may transmit a new TB on any HARQ process in the grants that have the same TBS, the same RV and the NDIs indicate new transmission.
The number of transmissions of a TB within a bundle of the dynamic grant or configured grant is given by REPETITION_NUMBER as follows:
– For a dynamic grant, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.1 of TS 38.214 [7];
– For a configured grant, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.3 of TS 38.214 [7].
If REPETITION_NUMBER > 1, after the first transmission within a bundle, REPETITION_NUMBER – 1 HARQ retransmissions follow within the bundle. For both dynamic grant and configured uplink grant, bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle, HARQ retransmissions are triggered without waiting for feedback from previous transmission according to REPETITION_NUMBER for a dynamic grant or configured uplink grant. Each transmission within a bundle is a separate uplink grant delivered to the HARQ entity.
For each transmission within a bundle of the dynamic grant, the sequence of redundancy versions is determined according to clause 6.1.2.1 of TS 38.214 [7]. For each transmission within a bundle of the configured uplink grant, the sequence of redundancy versions is determined according to clause 6.1.2.3 of TS 38.214 [7].
For each uplink grant, the HARQ entity shall:
1> identify the HARQ process associated with this grant, and for each identified HARQ process:
2> if the received grant was not addressed to a Temporary C-RNTI on PDCCH, and the NDI provided in the associated HARQ information has been toggled compared to the value in the previous transmission of this TB of this HARQ process; or
2> if the uplink grant was received on PDCCH for the C-RNTI and the HARQ buffer of the identified process is empty; or
2> if the uplink grant was received in a Random Access Response (i.e. in a MAC RAR or a fallback RAR); or
2> if the uplink grant was determined as specified in clause 5.1.2a for the transmission of the MSGA payload; or
2> if the uplink grant was received on PDCCH for the C-RNTI in ra-ResponseWindow and this PDCCH successfully completed the Random Access procedure initiated for beam failure recovery; or
2> if the uplink grant is part of a bundle of the configured uplink grant, and may be used for initial transmission according to clause 6.1.2.3 of TS 38.214 [7], and if no MAC PDU has been obtained for this bundle:
3> if there is a MAC PDU in the MSGA buffer and the uplink grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload was selected; or
3> if there is a MAC PDU in the MSGA buffer and the uplink grant was received in a fallbackRAR and this fallbackRAR successfully completed the Random Access procedure:
4> obtain the MAC PDU to transmit from the MSGA buffer.
3> else if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a fallbackRAR:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
3> else if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a MAC RAR; or:
3> if there is a MAC PDU in the Msg3 buffer and the uplink grant was received on PDCCH for the C-RNTI in ra-ResponseWindow and this PDCCH successfully completed the Random Access procedure initiated for beam failure recovery:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
4> if the uplink grant size does not match with size of the obtained MAC PDU; and
4> if the Random Access procedure was successfully completed upon receiving the uplink grant:
5> indicate to the Multiplexing and assembly entity to include MAC subPDU(s) carrying MAC SDU from the obtained MAC PDU in the subsequent uplink transmission;
5> obtain the MAC PDU to transmit from the Multiplexing and assembly entity.
3> else if this uplink grant is a configured grant configured with autonomousTx; and
3> if the previous configured uplink grant, in the BWP, for this HARQ process was not prioritized; and
3> if a MAC PDU had already been obtained for this HARQ process; and
3> if the uplink grant size matches with size of the obtained MAC PDU; and
3> if a transmission of the obtained MAC PDU has not been performed:
4> consider the MAC PDU has been obtained.
3> else if the MAC entity is not configured with lch-basedPrioritization; or
3> if this uplink grant is a prioritized uplink grant:
4> obtain the MAC PDU to transmit from the Multiplexing and assembly entity, if any;
3> if a MAC PDU to transmit has been obtained:
4> if the uplink grant is not a configured grant configured with autonomousTx; or
4> if the uplink grant is a prioritized uplink grant:
5> deliver the MAC PDU and the uplink grant and the HARQ information of the TB to the identified HARQ process;
5> instruct the identified HARQ process to trigger a new transmission;
5> if the uplink grant is a configured uplink grant:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers;
6> start or restart the cg-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
5> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
5> if cg-RetransmissionTimer is configured for the identified HARQ process; and
5> if the transmission is performed and LBT failure indication is received from lower layers:
6> consider the identified HARQ process as pending.
3> else:
4> flush the HARQ buffer of the identified HARQ process.
2> else (i.e. retransmission):
3> if the uplink grant received on PDCCH was addressed to CS-RNTI and if the HARQ buffer of the identified process is empty; or
3> if the uplink grant is part of a bundle and if no MAC PDU has been obtained for this bundle; or
3> if the uplink grant is part of a bundle of the configured uplink grant, and the PUSCH duration of the uplink grant overlaps with a PUSCH duration of another uplink grant received on the PDCCH or an uplink grant received in a Random Access Response (i.e. MAC RAR or fallbackRAR) or an uplink grant determined as specified in clause 5.1.2a for MSGA payload for this Serving Cell; or:
3> if the MAC entity is configured with lch-basedPrioritization and this uplink grant is not a prioritized uplink grant:
4> ignore the uplink grant.
3> else:
4> deliver the uplink grant and the HARQ information (redundancy version) of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a retransmission;
4> if the uplink grant is addressed to CS-RNTI; or
4> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
5> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
4> if the uplink grant is a configured uplink grant:
5> if the identified HARQ process is pending:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers;
5> start or restart the cg-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
4> if the identified HARQ process is pending and the transmission is performed and LBT failure indication is not received from lower layers:
5> consider the identified HARQ process as not pending.
When determining if NDI has been toggled compared to the value in the previous transmission the MAC entity shall ignore NDI received in all uplink grants on PDCCH for its Temporary C-RNTI.
When configuredGrantTimer or cg-RetransmissionTimer is started or restarted by a PUSCH transmission, it shall be started at the beginning of the first symbol of the PUSCH transmission.
7.1.1.3.11.3 Test description
7.1.1.3.11.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that the UM DRB is configured and the logical channels are configured according to 7.1.1.3.11.3.1-1.
Table 7.1.1.3.11.3.1-2: Logical Channel Configuration Settings
Parameter |
DRB1 |
DRB2 |
LogicalChannelIdentity |
LCH4(DRB-Identity +3) |
LCH5(DRB-Identity +3) |
Priority |
6 |
7 |
logicalChannelGroup |
2 (LCG ID#2) |
1 (LCG ID#1) |
7.1.1.3.11.3.2 Test procedure sequence
Table 7.1.1.3.11.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration message to configure type 2 configured uplink grant. |
<– |
RRCReconfiguration |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete. |
–> |
RRCReconfigurationComplete |
– |
– |
3 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
4 |
SS transmits a MAC PDU including a RLC SDU-1 on LCH 4. |
<– |
MAC PDU (1 RLC SDU of 40 bytes on DRB) |
– |
– |
5 |
The SS allocates an UL Grant (with size 384 bits that only sufficient for one RLC SDU to be looped back in a Slot) for one HARQ process X and NDI indicates new transmission redundancy version to be used as 0. |
<– |
(UL Grant (C-RNTI)) |
– |
– |
6 |
The UE transmit a MAC PDU including the RLC SDU-1, in HARQ process X. |
–> |
MAC PDU |
– |
– |
7 |
SS transmits a MAC PDU including a RLC SDU-2 on LCH 5. |
<– |
MAC PDU (1 RLC SDU of 40 bytes on DRB) |
– |
– |
8 |
SS transmits a configured UL Grant (with size 384 bits that only sufficient for one RLC SDU to be looped back in a Slot), on PDCCH with the CS-RNTI assigned to the UE, allowing the UE to return the RLC SDU-2 (as received in step 5) in Slot P. |
<– |
(UL Grant (CS-RNTI)) |
– |
– |
9 |
The SS transmits an UL grant corresponding to slot for HARQ process X, with NDI not toggled and redundancy version to be used as 1. (Note 3) |
<– |
(UL Grant (C-RNTI)) |
– |
– |
10 |
Check: Does the UE retransmit the MAC PDU including RLC SDU-1 in slot P? |
–> |
MAC PDU |
1 |
P |
11 |
Check: Does the UE transmit the MAC PDU including RLC SDU-2 after slot P? |
–> |
MAC PDU |
2 |
P |
12 |
The SS transmits a PDCCH [for UL configured grant type 2 explicit release] using UE’s CS-RNTI in Symbol ‘S’ of slot ‘p’ with NDI=0. Where (z+5x< p <z+6x). |
<– |
PDCCH [for UL configured grant type 2 explicit release] |
– |
– |
Note 1: Void. Note 2: Void. Note 3: The UL grant slot is equal to the configured slot in step 8. |
7.1.1.3.11.3.3 Specific message contents
Table 7.1.1.3.11.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.3.11.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.11.3.3-2: CellGroupConfig (Table 7.1.1.3.11.3.3-1)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig |
MAC-CellGroupConfig |
Table 7.1.1.3.11.3.3-3 |
|
physicalCellGroupConfig |
PhysicalCellGroupConfig |
Table 7.1.1.3.11.3.3-4 |
|
spCellConfig SEQUENCE{ |
|||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
schedulingRequestResourceToAddModList { |
|||
schedulingRequestResourceId |
1 |
||
schedulingRequestID |
0 |
||
periodicityAndOffset CHOICE { |
|||
sl20 |
10 |
||
} |
|||
} |
|||
} |
|||
} |
|||
configuredGrantConfig CHOICE { |
|||
setup SEQUENCE { |
|||
cg-DMRS-Configuration |
DMRS-UplinkConfig |
Reference TS 38.508-1 [4], Table 4.6.3-51 |
|
uci-OnPUSCH CHOICE { |
|||
setup SEQUENCE { |
|||
semiStatic SEQUENCE { |
BetaOffsets |
||
betaOffsetACK-Index1 |
9 |
||
betaOffsetACK-Index2 |
9 |
||
betaOffsetACK-Index3 |
9 |
||
betaOffsetCSI-Part1-Index1 |
6 |
||
betaOffsetCSI-Part1-Index2 |
6 |
||
betaOffsetCSI-Part2-Index1 |
6 |
||
betaOffsetCSI-Part2-Index2 |
6 |
||
} |
|||
} |
|||
} |
|||
resourceAllocation |
ResourceAllocationType1 |
||
powerControlLoopToUse |
n0 |
||
p0-PUSCH-Alpha |
1 |
||
nrofHARQ-Processes |
16 |
||
repK |
n1 |
||
periodicity |
Sym80x14 |
15kHz |
|
periodicity |
Sym160x14 |
30kHz |
|
periodicity |
Sym320x14 |
60kHz |
|
periodicity |
Sym640x14 |
120kHz |
|
autonomousTx-r16 |
enabled |
||
} |
|||
} |
|||
pusch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
PUSCH-TimeDomainResourceAllocationList SEQUENCE { |
|||
k2 |
n8 |
FR1 and FR2 |
|
mappingType |
typeB |
||
startSymbolAndLength |
0011011 |
FR1 |
|
startSymbolAndLength |
0001110 |
FR2 |
|
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.3.11.3.3-3: MAC-CellGroupConfig (Table 7.1.1.3.11.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-68 |
|||
Information Element |
Value/remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
lch-BasedPrioritization-r16 |
enabled |
||
} |
Table 7.1.1.3.11.3.3-4: PhysicalCellGroupConfig (Table 7.1.1.3.11.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-106 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PhysicalCellGroupConfig ::= SEQUENCE { |
|||
cs-RNTI |
‘FFE0’H |
||
} |
7.1.1.3.12 Correct Handling of UL HARQ process / PUSCH Repetition Type B
7.1.1.3.12.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and is configured with PUSCH repetition type B}
ensure that {
when { UE receives an UL Grant with toggled NDI and has data available for transmission }
then { UE transmits a new MAC PDU and repeats the MAC PDU in proper actual transmission times after first transmission and selects the redundancy version correctly }
}
7.1.1.3.12.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.214 clauses 6.1.2.1 and 6.1.4, TS 38.321 clause 5.4.2.1. Unless otherwise stated these are Rel-16 requirements.
[TS 38.214, clause 6.1.2.1]
– for PUSCH scheduled by DCI format 0_1, if pusch-RepTypeIndicatorDCI-0-1 is set to ‘pusch-RepTypeB’, the UE applies PUSCH repetition Type B procedure when determining the time domain resource allocation. For PUSCH scheduled by DCI format 0_2, if pusch-RepTypeIndicatorDCI-0-2 is set to ‘pusch-RepTypeB’, the UE applies PUSCH repetition Type B procedure when determining the time domain resource allocation. Otherwise, the UE applies PUSCH repetition Type A procedure when determining the time domain resource allocation for PUSCH scheduled by PDCCH.
– For PUSCH repetition Type A, the starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– For PUSCH repetition Type B, the starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are provided by startSymbol and length of the indexed row of the resource allocation table, respectively.
– For PUSCH repetition Type A, the PUSCH mapping type is set to Type A or Type B as defined in Clause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
– For PUSCH repetition Type B, the PUSCH mapping type is set to Type B.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A (repetition Type A only) |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} for repetition Type A, {1,…,27} for repetition Type B |
{0,…, 11} |
{1,…,12} |
{1,…,12} for repetition Type A, {1,…,23} for repetition Type B |
For PUSCH repetition Type A, when transmitting PUSCH scheduled by DCI format 0_1 or 0_2 in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1, the number of repetitions K is determined as
– if numberOfRepetitions is present in the resource allocation table, the number of repetitions K is equal to numberOfRepetitions;
– elseif the UE is configured with pusch-AggregationFactor, the number of repetitions K is equal to pusch-AggregationFactor;
– otherwise K=1.
If a UE is configured with higher layer parameter pusch-TimeDomainAllocationListForMultiPUSCH, the UE does not expect to be configured with pusch-AggregationFactor.
For PUSCH repetition Type A, in case K>1, the same symbol allocation is applied across the K consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the K consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB, where n = 0, 1, … K-1, is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version for PUSCH transmission
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion (repetition Type A) or nth actual repetition (repetition Type B) |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
When transmitting MsgA PUSCH on a non-initial UL BWP, if the UE is configured with startSymbolAndLengthMsgA-PO, the UE shall determine the S and L from startSymbolAndLengthMsgA-PO.
When transmitting MsgA PUSCH, if the UE is not configured with startSymbolAndLengthMsgA-PO, and if the TDRA list PUSCH-TimeDomainResourceAllocationList is provided in PUSCH-ConfigCommon, the UE shall use msgA-PUSCH-TimeDomainAllocation to indicate which values are used in the list. If PUSCH-TimeDomainResourceAllocationList is not provided in PUSCH-ConfigCommon, the UE shall use parameters S and L from table 6.1.2.1.1-2 or table 6.1.2.1.1-3 where msgA-PUSCH-TimeDomainAllocation indicates which values are used in the list. The time offset for PUSCH transmission is described in [6, TS38.213].
For PUSCH repetition Type A, a PUSCH transmission in a slot of a multi-slot PUSCH transmission is omitted according to the conditions in Clause 9, Clause 11.1 and Clause 11.2A of [6, TS38.213].
For PUSCH repetition Type B, except for PUSCH transmitting CSI report(s) with no transport block, the number of nominal repetitions is given by numberOfRepetitions. For the n-th nominal repetition, n = 0, …, numberOfRepetitions – 1,
– The slot where the nominal repetition starts is given by , and the starting symbol relative to the start of the slot is given by .
– The slot where the nominal repetition ends is given by , and the ending symbol relative to the start of the slot is given by .
Here is the slot where the PUSCH transmission starts, and is the number of symbols per slot as defined in Clause 4.3.2 of [4, TS38.211].
For PUSCH repetition Type B, the UE determines invalid symbol(s) for PUSCH repetition Type B transmission as follows:
– A symbol that is indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated is considered as an invalid symbol for PUSCH repetition Type B transmission.
– For operation in unpaired spectrum, symbols indicated by ssb-PositionsInBurst in SIB1 or ssb-PositionsInBurst in ServingCellConfigCommon for reception of SS/PBCH blocks are considered as invalid symbols for PUSCH repetition Type B transmission.
– For operation in unpaired spectrum, symbol(s) indicated by pdcch-ConfigSIB1 in MIB for a CORESET for Type0-PDCCH CSS set are considered as invalid symbol(s) for PUSCH repetition Type B transmission.
– For operation in unpaired spectrum, if numberOfInvalidSymbolsForDL-UL-Switching is configured, numberOfInvalidSymbolsForDL-UL-Switching symbol(s) after the last symbol that is indicated as downlink in each consecutive set of all symbols that are indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated are considered as invalid symbol(s) for PUSCH repetition Type B transmission. The symbol(s) given by numberOfInvalidSymbolsForDL-UL-Switching are defined using the reference SCS configuration referenceSubcarrierSpacing provided in tdd-UL-DL-ConfigurationCommon.
– The UE may be configured with the higher layer parameter invalidSymbolPattern, which provides a symbol level bitmap spanning one or two slots (higher layer parameter symbols given by invalidSymbolPattern). A bit value equal to 1 in the symbol level bitmap symbols indicates that the corresponding symbol is an invalid symbol for PUSCH repetition Type B transmission. The UE may be additionally configured with a time-domain pattern (higher layer parameter periodicityAndPattern given by invalidSymbolPattern), where each bit of periodicityAndPattern corresponds to a unit equal to a duration of the symbol level bitmap symbols, and a bit value equal to 1 indicates that the symbol level bitmap symbols is present in the unit. The periodicityAndPattern can be {1, 2, 4, 5, 8, 10, 20 or 40} units long, but maximum of 40 msec. The first symbol of periodicityAndPattern every 40 msec/P periods is a first symbol in frame 𝑛𝑓 mod 4 = 0, where P is the duration of periodicityAndPattern-r16 in units of msec. When periodicityAndPattern is not configured, for a symbol level bitmap spanning two slots, the bits of the first and second slots correspond respectively to even and odd slots of a radio frame, and for a symbol level bitmap spanning one slot, the bits of the slot correspond to every slot of a radio frame. If invalidSymbolPattern is configured, when the UE applies the invalid symbol pattern is determined as follows:
– if the PUSCH is scheduled by DCI format 0_1, or corresponds to a Type 2 configured grant activated by DCI format 0_1, and if invalidSymbolPatternIndicatorDCI-0-1 is configured,
– if invalid symbol pattern indicator field is set 1, the UE applies the invalid symbol pattern;
– otherwise, the UE does not apply the invalid symbol pattern;
– if the PUSCH is scheduled by DCI format 0_2, or corresponds to a Type 2 configured grant activated by DCI format 0_2, and if invalidSymbolPatternIndicatorDCI-0-2 is configured,
– if invalid symbol pattern indicator field is set 1, the UE applies the invalid symbol pattern;
– otherwise, the UE does not apply the invalid symbol pattern;
– otherwise, the UE applies the invalid symbol pattern.
– If the UE
– is configured with multiple serving cells and is provided half-duplex-behavior = ‘enable’, and
– is not capable of simultaneous transmission and reception on any of the multiple serving cells, and
– indicates support of capability for half-duplex operation in CA with unpaired spectrum, and
– is not configured to monitor PDCCH for detection of DCI format 2-0 on any of the multiple serving cells,
– a symbol is considered as an invalid symbol in any of the multiple serving cells for PUSCH repetition Type B transmission if the symbol is indicated to the UE for reception of SS/PBCH blocks in any of the multiple serving cells by ssb-PositionsInBurst in SIB1 or ssb-PositionsInBurst in ServingCellConfigCommon, and
a symbol is considered as an invalid symbol in any of the multiple serving cells for PUSCH repetition Type B transmission with Type 1 or Type 2 configured grant except for the first Type 2 PUSCH transmission (including all repetitions) after activation if the symbol is indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated on the reference cell, or the UE is configured by higher layers to receive PDCCH, PDSCH, or CSI-RS on the reference cell in the symbol.
For PUSCH repetition Type B, after determining the invalid symbol(s) for PUSCH repetition type B transmission for each of the K nominal repetitions, the remaining symbols are considered as potentially valid symbols for PUSCH repetition Type B transmission. If the number of potentially valid symbols for PUSCH repetition type B transmission is greater than zero for a nominal repetition, the nominal repetition consists of one or more actual repetitions, where each actual repetition consists of a consecutive set of all potentially valid symbols that can be used for PUSCH repetition Type B transmission within a slot. An actual repetition with a single symbol is omitted except for the case of L=1. An actual repetition is omitted according to the conditions in Clause 9, Clause 11.1 and Clause 11.2A of [6, TS38.213]. The redundancy version to be applied on the nth actual repetition (with the counting including the actual repetitions that are omitted) is determined according to table 6.1.2.1-2.
For PUSCH repetition Type B, when a UE receives a DCI that schedules aperiodic CSI report(s) or activates semi-persistent CSI report(s) on PUSCH with no transport block by a ‘CSI request’ field on a DCI, the number of nominal repetitions is always assumed to be 1, regardless of the value of numberOfRepetitions. When the UE is scheduled to transmit a PUSCH repetition Type B with no transport block and with aperiodic or semi-persistent CSI report(s) by a ‘CSI request’ field on a DCI, the first nominal repetition is expected to be the same as the first actual repetition. For PUSCH repetition Type B carrying semi-persistent CSI report(s) without a corresponding PDCCH after being activated on PUSCH by a ‘CSI request’ field on a DCI, if the first nominal repetition is not the same as the first actual repetition, the first nominal repetition is omitted; otherwise, the first nominal repetition is omitted according to the conditions in Clause 9, Clause 11.1 and Clause 11.2A of [6, TS38.213].
For PUSCH repetition Type B, when a UE is scheduled to transmit a transport block and aperiodic CSI report(s) on PUSCH by a ‘CSI request’ field on a DCI, the CSI report(s) is multiplexed only on the first actual repetition. The UE does not expect that the first actual repetition has a single symbol duration.
[TS 38.214, clause 6.1.4]
To determine the modulation order, target code rate, redundancy version and transport block size for the physical uplink shared channel, the UE shall first
– read the 5-bit modulation and coding scheme field in the DCI scheduling PUSCH or provided in a DCI activating a configured grant Type 2 PUSCH, or as provided by mcsAndTBS as described in Clause 6.1.2.3 for a configured grant Type 1 PUSCH to determine the modulation order and target code rate (R) based on the procedure defined in Clause 6.1.4.1
– read redundancy version field (rv) in the DCI to determine the redundancy version for PUSCH scheduled by DCI, or determine the redundancy version according to Clause 6.1.2.3.1 for configured grant Type 1 and Type 2 PUSCH,
and second
– use the number of layers , the total number of allocated PRBs to determine the transport block size based on the procedure defined in Clause 6.1.4.2.
When the UE is scheduled with multiple PUSCHs by a DCI, as described in clause 6.1.2.1, the bits of rv field and NDI field, respectively, in the DCI are one to one mapped to the scheduled PUSCH(s) with the corresponding transport block(s) in the scheduled order where the LSB bits of the rv field and NDI field, respectively, correspond to the last scheduled PUSCH.
Within a cell group, a UE is not required to handle PUSCH(s) transmissions in slot sj in serving cell-j, and for j = 0,1,2.. J-1, slot sj overlapping with any given point in time, if the following condition is not satisfied at that point in time:
,
where
– J is the number of configured serving cells belong to a frequency range
– for the j-th serving cell,
– M is the number of TB(s) transmitted in slot-sj. For PUSCH repetition Type B, each actual repetition is counted separately.
– Tslotμ(j) =10-3/2μ(j), where μ(j) is the numerology for PUSCH(s) in slot sj of the j-th serving cell.
– for the m-th TB,
– A is the number of bits in the transport block as defined in Clause 6.2.1 [5, TS 38.212]
– C is the total number of code blocks for the transport block defined in Clause 5.2.2 [5, TS 38.212].
– is the number of scheduled code blocks for the transport block as defined in Clause 5.4.2.1 [5,38.212]
– [Mbps] is computed as the maximum data rate summed over all the carriers in the frequency range for any signalled band combination and feature set consistent with the configured servings cells, where the data rate value is given by the formula in Clause 4.1.2 in [13, TS 38.306], including the scaling factor f(i).
For a j-th serving cell, if higher layer parameter processingType2Enabled of PUSCH-ServingCellConfig is configured for the serving cell and set to ‘enable’, or if at least one IMCS > W for a PUSCH, where W = 28 for MCS tables 5.1.3.1-1 and 5.1.3.1-3, and W = 27 for MCS tables 5.1.3.1-2, 6.1.4.1-1, and 6.1.4.1-2, or if it is an actual repetition for PUSCH repetition Type B, the UE is not required to handle PUSCH transmissions, if the following condition is not satisfied:
where
– is the number of symbols assigned to the PUSCH
– M is the number of TB in the PUSCH
– where μ is the numerology of the PUSCH
– for the m-th TB,
– A is the number of bits in the transport block as defined in Clause 6.2.1 [5, TS 38.212]
– C is the total number of code blocks for the transport block defined in Clause 5.2.2 [5, TS 38.212]
– is the number of scheduled code blocks for the transport block as defined in Clause 5.4.2.1 [5, TS 38.212]
– [Mbps] is computed as the maximum data rate for a carrier in the frequency band of the serving cell for any signalled band combination and feature set consistent with the serving cell, where the data rate value is given by the formula in Clause 4.1.2 in [13, TS 38.306], including the scaling factor f(i)
– each actual repetition for PUSCH repetition type B is treated as one PUSCH.
[TS 38.321, clause 5.4.2.1]
The MAC entity includes a HARQ entity for each Serving Cell with configured uplink (including the case when it is configured with supplementaryUplink), which maintains a number of parallel HARQ processes.
The number of parallel UL HARQ processes per HARQ entity is specified in TS 38.214 [7].
Each HARQ process supports one TB.
Each HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RA Response or for UL transmission for MSGA payload, HARQ process identifier 0 is used.
NOTE: When a single DCI is used to schedule multiple PUSCH, the UE is allowed to map generated TB(s) internally to different HARQ processes in case of LBT failure(s), i.e. UE may transmit a new TB on any HARQ process in the grants that have the same TBS, the same RV and the NDIs indicate new transmission.
The maximum number of transmissions of a TB within a bundle of the dynamic grant or configured grant is given by REPETITION_NUMBER as follows:
– For a dynamic grant, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.1 of TS 38.214 [7];
– For a configured grant, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.3 of TS 38.214 [7].
If REPETITION_NUMBER > 1, after the first transmission within a bundle, at most REPETITION_NUMBER – 1 HARQ retransmissions follow within the bundle. For both dynamic grant and configured uplink grant, bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle, HARQ retransmissions are triggered without waiting for feedback from previous transmission according to REPETITION_NUMBER for a dynamic grant or configured uplink grant unless they are terminated as specified in clause 6.1 of TS 38.214 [7]. Each transmission within a bundle is a separate uplink grant delivered to the HARQ entity.
For each transmission within a bundle of the dynamic grant, the sequence of redundancy versions is determined according to clause 6.1.2.1 of TS 38.214 [7]. For each transmission within a bundle of the configured uplink grant, the sequence of redundancy versions is determined according to clause 6.1.2.3 of TS 38.214 [7].
For each uplink grant, the HARQ entity shall:
1> identify the HARQ process associated with this grant, and for each identified HARQ process:
2> if the received grant was not addressed to a Temporary C-RNTI on PDCCH, and the NDI provided in the associated HARQ information has been toggled compared to the value in the previous transmission of this TB of this HARQ process; or
2> if the uplink grant was received on PDCCH for the C-RNTI and the HARQ buffer of the identified process is empty; or
2> if the uplink grant was received in a Random Access Response (i.e. in a MAC RAR or a fallback RAR); or
2> if the uplink grant was determined as specified in clause 5.1.2a for the transmission of the MSGA payload; or
2> if the uplink grant was received on PDCCH for the C-RNTI in ra-ResponseWindow and this PDCCH successfully completed the Random Access procedure initiated for beam failure recovery; or
2> if the uplink grant is part of a bundle of the configured uplink grant, and may be used for initial transmission according to clause 6.1.2.3 of TS 38.214 [7], and if no MAC PDU has been obtained for this bundle:
3> if there is a MAC PDU in the MSGA buffer and the uplink grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload was selected; or
3> if there is a MAC PDU in the MSGA buffer and the uplink grant was received in a fallbackRAR and this fallbackRAR successfully completed the Random Access procedure:
4> obtain the MAC PDU to transmit from the MSGA buffer.
3> else if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a fallbackRAR:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
3> else if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a MAC RAR; or:
3> if there is a MAC PDU in the Msg3 buffer and the uplink grant was received on PDCCH for the C-RNTI in ra-ResponseWindow and this PDCCH successfully completed the Random Access procedure initiated for beam failure recovery:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
4> if the uplink grant size does not match with size of the obtained MAC PDU; and
4> if the Random Access procedure was successfully completed upon receiving the uplink grant:
5> indicate to the Multiplexing and assembly entity to include MAC subPDU(s) carrying MAC SDU from the obtained MAC PDU in the subsequent uplink transmission;
5> obtain the MAC PDU to transmit from the Multiplexing and assembly entity.
3> else if this uplink grant is a configured grant configured with autonomousTx; and
3> if the previous configured uplink grant, in the BWP, for this HARQ process was not prioritized; and
3> if a MAC PDU had already been obtained for this HARQ process; and
3> if the uplink grant size matches with size of the obtained MAC PDU; and
3> if none of PUSCH transmission(s) of the obtained MAC PDU has been completely performed:
4> consider the MAC PDU has been obtained.
3> else if the MAC entity is not configured with lch-basedPrioritization; or
3> if this uplink grant is a prioritized uplink grant:
4> obtain the MAC PDU to transmit from the Multiplexing and assembly entity, if any;
3> if a MAC PDU to transmit has been obtained:
4> if the uplink grant is not a configured grant configured with autonomousTx; or
4> if the uplink grant is a prioritized uplink grant:
5> deliver the MAC PDU and the uplink grant and the HARQ information of the TB to the identified HARQ process;
5> instruct the identified HARQ process to trigger a new transmission;
5> if the uplink grant is a configured uplink grant:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers;
6> start or restart the cg-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
5> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
5> if cg-RetransmissionTimer is configured for the identified HARQ process; and
5> if the transmission is performed and LBT failure indication is received from lower layers:
6> consider the identified HARQ process as pending.
3> else:
4> flush the HARQ buffer of the identified HARQ process.
2> else (i.e. retransmission):
3> if the uplink grant received on PDCCH was addressed to CS-RNTI and if the HARQ buffer of the identified process is empty; or
3> if the uplink grant is part of a bundle and if no MAC PDU has been obtained for this bundle; or
3> if the uplink grant is part of a bundle of the configured uplink grant, and the PUSCH duration of the uplink grant overlaps with a PUSCH duration of another uplink grant received on the PDCCH or an uplink grant received in a Random Access Response (i.e. MAC RAR or fallbackRAR) or an uplink grant determined as specified in clause 5.1.2a for MSGA payload for this Serving Cell; or:
3> if the MAC entity is configured with lch-basedPrioritization and this uplink grant is not a prioritized uplink grant:
4> ignore the uplink grant.
3> else:
4> deliver the uplink grant and the HARQ information (redundancy version) of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a retransmission;
4> if the uplink grant is addressed to CS-RNTI; or
4> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
5> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
4> if the uplink grant is a configured uplink grant:
5> if the identified HARQ process is pending:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers;
5> start or restart the cg-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
4> if the identified HARQ process is pending and the transmission is performed and LBT failure indication is not received from lower layers:
5> consider the identified HARQ process as not pending.
When determining if NDI has been toggled compared to the value in the previous transmission the MAC entity shall ignore NDI received in all uplink grants on PDCCH for its Temporary C-RNTI.
When configuredGrantTimer or cg-RetransmissionTimer is started or restarted by a PUSCH transmission, it shall be started at the beginning of the first symbol of the PUSCH transmission.
7.1.1.3.12.3 Test description
7.1.1.3.12.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.3.12.3.2 Test procedure sequence
Table 7.1.1.3.12.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0A |
SS transmits in the indicated downlink assignment an NR RRCReconfiguration. (Note 1) |
<— |
– |
– |
– |
0B |
UE transmits NR RRCReconfigurationComplete message to the SS. (Note 2) |
–> |
– |
– |
– |
1 |
The SS transmits a valid MAC PDU containing one RLC PDU. |
<— |
MAC PDU |
– |
– |
2 |
The UE transmits a Scheduling Request. |
–> |
(SR) |
– |
– |
3 |
The SS allocates an UL Grant for HARQ process 1, sufficient for one RLC SDU to be looped back in a slot n, NDI indicates new transmission, DCI scheduling the PUSCH indicates rvID = 0 and invalid symbol pattern indicator set to 1. The slot n is selected such that slot n+4 is the first UL slot in subframe m satisfying (m mod 20) = 9 for SCS=15kHz and SCS=120kHz and (m mod 20) = 8 for SCS=30kHz. (Note 5) |
<– |
UL Grant |
– |
– |
4 |
Check: Does the UE transmit a MAC PDU including one RLC SDU, in HARQ process 1 and in slot n+4 and repeats in actual repetitions according to Table 7.1.1.3.12.3.2-2 with same resource allocation but different redundancy version (Note 3), if the slot can be used for uplink transmission (Note 4) |
–> |
MAC PDU |
1 |
P |
5 |
SS transmits a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDU in step 4. |
<– |
MAC PDU (RLC STATUS PDU) |
– |
|
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: The redundancy version for the first transmission and all possible actual repetitions (including skipped ones) are set in the following order {0, 2, 3, 1} according to TS 38.214 [15] Table 6.1.2.1-2, first row. Note 4: Usage of correct redundancy version is implicitly checked upon correct decoding by the SS of the UE UL repetitions. Note 5: The UL grant is set to 384 bits: LRBs = 24 & IMCS = 2 (with PUSCH-duration=4 and PUSCH mapping Type B). |
Table 7.1.1.3.12.3.2-2: Transmitted actual repetition in each nominal repetition
Nominal repetition 0 (NOTE 1) |
Nominal repetition 1 (NOTE 1) |
Nominal repetition 2 (NOTE 2) |
Nominal repetition 3 (NOTE 3) |
|
FR1 TDD SCS=15kHz |
Actual repetition 0 |
Actual repetition 0 |
N/A (NOTE 4, 5) |
N/A (NOTE 6) |
FR1 FDD SCS=15kHz |
Actual repetition 0 |
Actual repetition 0 |
Actual repetition 1 (NOTE 4, 7) |
Actual repetition 0 |
FR1 TDD SCS=30kHz |
Actual repetition 0 |
Actual repetition 0 |
Actual repetition 1 (NOTE 4) |
Actual repetition 0 |
FR2 SCS=120kHz |
Actual repetition 0 |
Actual repetition 0 |
N/A (NOTE 4, 5) |
N/A (NOTE 6) |
NOTE 1: The nominal repetition is in slot n+4 and only one actual repetition expected. NOTE 2: The nominal repetition is split into two actual repetitions in slot n+4 and n+5 respectively. NOTE 3: The nominal repetition is in slot n+5 and only one actual repetition expected. NOTE 4: The actual repetition 0 is skipped due to only 1 valid symbol left according to invalidSymbolPattern-r16. NOTE 5: The actual repetition 1 is skipped due to being located in DL symbols NOTE 6: The actual repetition 0 is skipped due to being located in DL symbols NOTE 7: The SS may not be able to decode the MAC PDU and may only detect a CRC error as there are less symbols available for transmission of the TBS |
7.1.1.3.12.3.3 Specific message contents
Table 7.1.1.3.12.3.3-0A: RRCReconfiguration (step 0A, Table 7.1.1.3.12.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
} |
|||
RRCReconfiguration-v1530-IEs ::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.3.12.3.3-0B: CellGroupConfig (Table 7.1.1.3.12.3.3-0A: RRCReconfiguration)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig::= SEQUENCE { |
|||
cellGroupId |
0 |
||
1 |
EN-DC |
||
spCellConfig SEQUENCE { |
|||
spCellConfigDedicated SEQUENCE { |
|||
servingCellConfig |
ServingCellConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.3.12.3.3-1: ServingCellConfig (Table 7.1.1.3.12.3.3-0B: CellGroupConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
} |
Table 7.1.1.3.12.3.3-2: BWP-UplinkDedicated (Table 7.1.1.3.12.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-11 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pusch-Config CHOICE { |
|||
setup |
PUSCH-Config |
||
} |
|||
} |
Table 7.1.1.3.12.3.3-3: PUSCH-Config (Table 7.1.1.3.12.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-118 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-Config ::= SEQUENCE { |
|||
dmrs-UplinkForPUSCH-MappingTypeB CHOICE { |
|||
setup |
DMRS-UplinkConfig |
||
} |
|||
pusch-TimeDomainAllocationListDCI-0-1-r16 CHOICE { |
|||
setup SEQUENCE (SIZE(1..maxNrofUL-Allocations-r16)) OF SEQUENCE { |
1 entry |
||
k2-r16[1] |
4 |
||
puschAllocationList-r16[1] SEQUENCE (SIZE(1..maxNrofMultiplePUSCHs-r16)) OF SEQUENCE { |
1 entry |
||
mappingType-r16[1] |
Not present |
||
startSymbolAndLength-r16[1] |
Not present |
||
startSymbol-r16[1] |
4 |
||
length-r16[1] |
4 |
||
numberOfRepetitions-r16[1] |
n4 |
||
} |
|||
} |
|||
} |
|||
invalidSymbolPatternIndicatorDCI-0-1-r16 |
enabled |
||
pusch-RepTypeIndicatorDCI-0-1-r16 |
pusch-RepTypeB |
||
invalidSymbolPattern-r16 SEQUENCE { |
|||
symbols-r16 CHOICE { |
|||
oneSlot |
00000000000001 |
||
} |
|||
periodicityAndPattern-r16 |
Not present |
||
} |
|||
} |
Table 7.1.1.3.12.3.3-4: DMRS-UplinkConfig
Derivation Path: TS 38.508-1 [4], Table 4.6.3-51 |
7.1.1.3.13 Logical channel prioritization handling with Mapping restrictions / physical layer priority
7.1.1.3.13.1 Test Purpose (TP)
(1)
with {UE in RRC_CONNECTED state with allowedPHY-PriorityIndex configured}
ensure that {
when { UE is scheduled by DCI including priority indicator}
then { UE serves the logical channels according to their priority and configured PHY priority}
}
7.1.1.3.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.331, clause 6.3.2, TS 38.321, clause 5.4.3.1.2, 5.4.3.1.3, TS 38.213 clause 9, TS 38.212 clause 7.3.1.1.3. Unless otherwise stated these are Rel-16 requirements.
[TS 38.331, clause 6.3.2]
allowedPHY-PriorityIndex This restriction applies only when the UL grant is a dynamic grant. If the field is present and the dynamic grant has a PHY-priority index, UL MAC SDUs from this logical channel can only be mapped to the dynamic grants indicating PHY-priority index equal to the values configured by this field. If the field is present and the dynamic grant does not have a PHY-priority index, UL MAC SDUs from this logical channel can only be mapped to this dynamic grant if the value of the field is p0, see TS 38.213 [13], clause 9. If the field is not present, UL MAC SDUs from this logical channel can be mapped to any dynamic grants. Corresponds to "allowedPHY-PriorityIndex" as specified in TS 38.321 [3]. |
[TS 38.321, clause 5.4.3.1.2]
The MAC entity shall, when a new transmission is performed:
1> select the logical channels for each UL grant that satisfy all the following conditions:
2> the set of allowed Subcarrier Spacing index values in allowedSCS-List, if configured, includes the Subcarrier Spacing index associated to the UL grant; and
2> maxPUSCH-Duration, if configured, is larger than or equal to the PUSCH transmission duration associated to the UL grant; and
2> configuredGrantType1Allowed, if configured, is set to true in case the UL grant is a Configured Grant Type 1; and
2> allowedServingCells, if configured, includes the Cell information associated to the UL grant. Does not apply to logical channels associated with a DRB configured with PDCP duplication within the same MAC entity (i.e. CA duplication) when CA duplication is deactivated for this DRB in this MAC entity; and
2> allowedCG-List, if configured, includes the configured grant index associated to the UL grant; and
2> allowedPHY-PriorityIndex, if configured, includes the priority index (as specified in clause 9 of TS 38.213 [6]) associated to the dynamic UL grant.
NOTE: The Subcarrier Spacing index, PUSCH transmission duration, Cell information, and priority index are included in Uplink transmission information received from lower layers for the corresponding scheduled uplink transmission.
[TS 38.321, clause 5.4.3.1.3]
Before the successful completion of the Random Access procedure initiated for DAPS handover, the target MAC entity shall not select the logical channel(s) corresponding to non-DAPS DRB(s) for the uplink grant received in a Random Access Response or the uplink grant for the transmission of the MSGA payload.
The MAC entity shall, when a new transmission is performed:
1> allocate resources to the logical channels as follows:
2> logical channels selected in clause 5.4.3.1.2 for the UL grant with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to infinity, the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);
2> decrement Bj by the total size of MAC SDUs served to logical channel j above;
2> if any resources remain, all the logical channels selected in clause 5.4.3.1.2 are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.
NOTE 1: The value of Bj can be negative.
If the MAC entity is requested to simultaneously transmit multiple MAC PDUs, or if the MAC entity receives the multiple UL grants within one or more coinciding PDCCH occasions (i.e. on different Serving Cells), it is up to UE implementation in which order the grants are processed.
The UE shall also follow the rules below during the scheduling procedures above:
– the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources of the associated MAC entity;
– if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant of the associated MAC entity as much as possible;
– the UE should maximise the transmission of data;
– if the MAC entity is given a UL grant size that is equal to or larger than 8 bytes while having data available and allowed (according to clause 5.4.3.1) for transmission, the MAC entity shall not transmit only padding BSR and/or padding.
The MAC entity shall:
1> if the MAC entity is configured with enhancedSkipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or if the MAC entity is configured with enhancedSkipUplinkTxConfigured with value true and the grant indicated to the HARQ entity is a configured uplink grant; and
1> if the MAC entity is not configured with lch-basedPrioritization; and
1> if there is no UCI to be multiplexed on this PUSCH transmission as specified in TS 38.213 [6]; and
1> if there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
1> if the MAC PDU includes zero MAC SDUs; and
1> if the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR:
2> not generate a MAC PDU for the HARQ entity.
1> else if the MAC entity is configured with skipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or the grant indicated to the HARQ entity is a configured uplink grant; and
1> if there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
1> if the MAC PDU includes zero MAC SDUs; and
1> if the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR:
2> not generate a MAC PDU for the HARQ entity.
Logical channels shall be prioritised in accordance with the following order (highest priority listed first):
– C-RNTI MAC CE or data from UL-CCCH;
– Configured Grant Confirmation MAC CE or BFR MAC CE or Multiple Entry Configured Grant Confirmation MAC CE;
– Sidelink Configured Grant Confirmation MAC CE;
– LBT failure MAC CE;
– MAC CE for SL-BSR prioritized according to clause 5.22.1.6;
– MAC CE for BSR, with exception of BSR included for padding;
– Single Entry PHR MAC CE or Multiple Entry PHR MAC CE;
– MAC CE for the number of Desired Guard Symbols;
– MAC CE for Pre-emptive BSR;
– MAC CE for SL-BSR, with exception of SL-BSR prioritized according to clause 5.22.1.6 and SL-BSR included for padding;
– data from any Logical Channel, except data from UL-CCCH;
– MAC CE for Recommended bit rate query;
– MAC CE for BSR included for padding;
– MAC CE for SL-BSR included for padding.
NOTE 2: Prioritization among Configured Grant Confirmation MAC CE, Multiple Entry Configured Grant Confirmation MAC CE, and BFR MAC CE is up to UE implementation.
The MAC entity shall prioritize any MAC CE listed in a higher order than ‘data from any Logical Channel, except data from UL-CCCH’ over transmission of NR sidelink communication.
[TS 38.213, clause 9]
A PUSCH or a PUCCH transmission, including repetitions if any, can be of priority index 0 or of priority index 1. For a configured grant PUSCH transmission, a UE determines a priority index from phy-PriorityIndex, if provided. For a PUCCH transmission with HARQ-ACK information corresponding to a SPS PDSCH reception or a SPS PDSCH release, a UE determines a priority index from harq-CodebookID, if provided. For a PUCCH transmission with SR, a UE determines the corresponding priority as described in Clause 9.2.4. For a PUSCH transmission with semi-persistent CSI report, a UE determines a priority index from a priority indicator field, if provided, in a DCI format that activates the semi-persistent CSI report. If a priority index is not provided to a UE for a PUSCH or a PUCCH transmission, the priority index is 0.
7.1.1.3.13.3 Test description
7.1.1.3.13.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 with the exception of 3 UM bearers configured according to Table 7.1.1.3.13.3.1-1.
Table 7.1.1.3.13.3.1-1: Priority, PBR and Bucket Delay settings
DRB |
priority |
prioritisedBitRate (kbytes/s) |
bucketSizeDuration (ms) |
allowedPHY-PriorityIndex-r16 |
DRB1 |
6 |
infinity |
100 |
p0 |
DRB2 |
7 |
infinity |
100 |
p1 |
DRB3 |
8 |
infinity |
100 |
p1 |
7.1.1.3.13.3.2 Test procedure sequence
Table 7.1.1.3.13.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits 2 equal size RLC SDUs each on DRB1, DRB2, DRB3. |
<– |
(RLC SDUs) |
– |
– |
2 |
The SS is configured for Uplink Grant Allocation Type 2 as defined in TS 38.523-3 [3]. 100 ms after Step 1 (Note1), the SS transmits 4 UL grant of suitable size to receive one loop back RLC SDU on one logical channel every 20 ms with Priority indicator =1 |
<– |
(UL grants) |
– |
– |
3 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on DRB2? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
4 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on DRB2? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
5 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on DRB1? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
6 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on DRB1? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
7 |
The SS is configured for Uplink Grant Allocation Type 2 as defined in TS 38.523-3 [3]. 100 ms after Step 1 (Note1), the SS transmits 2 UL grant of suitable size to receive one loop back RLC SDU on one logical channel every 20 ms with Priority indicator=0 |
<– |
(UL grants) |
– |
– |
8 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on DRB1? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
9 |
Check: Does the UE transmit a MAC PDU containing MAC Sub PDU containing a RLC SDU on DRB1? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
Note 1: This wait time will ensure that a) all octets have been completely received by the UE on all 3 DRBs before the first UL grant is received and b) the Bjs for each logical channel have reached their maximum value i.e. the bucket size of the corresponding logical channel before the first UL grant is received. |
7.1.1.3.13.3.3 Specific message contents
Table 7.1.1.3.13.3.3-1: SchedulingRequest-Config (Preamble)
Derivation Path: 38.508-1 [4], Table 4.6.3-155 |
|||
Information Element |
Value/remark |
Comment |
Condition |
sr-TransMax |
n64 |
7.1.1.4 Transport Size Selection
7.1.1.4.1 DL-SCH Transport Block Size Selection
7.1.1.4.1.0 Common parameters for DL-SCH Transport Block Size Selection
Table 7.1.1.4.1.0-1: PDSCH-TimeDomainResourceAllocationList
Derivation Path: TS 38.508-1 [4], Table 4.6.3-103 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDSCH-TimeDomainResourceAllocationList ::= SEQUENCE(SIZE(1..maxNrofDL-Allocations)) OF SEQUENCE(SIZE(1..maxNrofDL-Allocations)) OF PDSCH-TimeDomainResourceAllocation { |
2 entries |
||
PDSCH-TimeDomainResourceAllocation[1] SEQUENCE { |
entry 1 |
||
k0 |
Not present |
||
mappingType |
typeA |
||
startSymbolAndLength |
53 |
S=2, L=12 |
|
} |
|||
PDSCH-TimeDomainResourceAllocation[2] SEQUENCE { |
entry 2 |
||
k0 |
Not present |
||
mappingType |
typeA |
||
startSymbolAndLength |
86 |
S=2, L=7 |
|
} |
|||
} |
7.1.1.4.1.1 DL-SCH Transport Block Size selection / DCI format 1_0
7.1.1.4.1.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE on PDCCH receives DCI format 1_0 indicating a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE decodes the received transport block of size correspondent as per Modulation Coding scheme, time domain resource allocation and PRB’s and forwards it to higher layers }
}
7.1.1.4.1.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.2.1, TS 38.214 clause 5.1.2.1, 5.1.2.2, 5.1.2.2.2, 5.1.3, 5.1.3.1 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.2.1]
DCI format 1_0 is used for the scheduling of PDSCH in one DL cell.
The following information is transmitted by means of the DCI format 1_0 with CRC scrambled by C-RNTI or CS-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bits
– The value of this bit field is always set to 1, indicating a DL DCI format
– Frequency domain resource assignment – bits
– is the size of the active DL bandwidth part in case DCI format 1_0 is monitored in the UE specific search space and satisfying
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
otherwise, is the size of the initial DL bandwidth part.
If the CRC of the DCI format 1_0 is scrambled by C-RNTI and the "Frequency domain resource assignment" field are of all ones, the DCI format 1_0 is for random access procedure initiated by a PDCCH order, with all remaining fields set as follows:
– Random Access Preamble index – 6 bits according to ra-PreambleIndex in Subclause 5.1.2 of [8, TS38.321]
– UL/SUL indicator – 1 bit. If the value of the “Random Access Preamble index” is not all zeros and if the UE is configured with SUL in the cell, this field indicates which UL carrier in the cell to transmit the PRACH according to Table 7.3.1.1.1-1; otherwise, this field is reserved
– SS/PBCH index – 6 bits. If the value of the “Random Access Preamble index” is not all zeros, this field indicates the SS/PBCH that shall be used to determine the RACH occasion for the PRACH transmission; otherwise, this field is reserved.
– PRACH Mask index – 4 bits. If the value of the “Random Access Preamble index” is not all zeros, this field indicates the RACH occasion associated with the SS/PBCH indicated by “SS/PBCH index” for the PRACH transmission, according to Subclause 5.1.1 of [8, TS38.321]; otherwise, this field is reserved
– Reserved bits – 10 bits
Otherwise, all remaining fields are set as follows:
– Time domain resource assignment – 4 bits as defined in Subclause 5.1.2.1 of [6, TS38.214]
– VRB-to-PRB mapping – 1 bit according to Table 7.3.1.1.2-33
– Modulation and coding scheme – 5 bits as defined in Subclause 5.1.3 of [6, TS38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits
– Downlink assignment index – 2 bits as defined in Subclause 9.1.3 of [5, TS38.213], as counter DAI
– TPC command for scheduled PUCCH – 2 bits as defined in Subclause 7.2.1 of [5, TS38.213]
– PUCCH resource indicator – 3 bits as defined in Subclause 9.2.3 of [5, TS38.213]
– PDSCH-to-HARQ_feedback timing indicator – 3 bits as defined in Subclause 9.2.3 of [5, TS38.213]
[TS 38.214, clause 5.1.2.1]
When the UE is scheduled to receive PDSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocation table. The determination of the used resource allocation table is defined in sub-clause 5.1.2.1.1. The indexed row defines the slot offset K0, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PDSCH mapping type to be assumed in the PDSCH reception.
Given the parameter values of the indexed row:
– The slot allocated for the PDSCH is , where n is the slot with the scheduling DCI, and K0 is based on the numerology of PDSCH, and and are the subcarrier spacing configurations for PDSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PDSCH are determined from the start and length indicator SLIV:
if then
else
where, and
– The PDSCH mapping type is set to Type A or Type B as defined in sub-clause 7.4.1.1.2 of [4, TS 38.211].
The UE shall consider the S and L combinations defined in table 5.1.2.1-1 as valid PDSCH allocations:
Table 5.1.2.1-1: Valid S and L combinations
PDSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
{0,1,2,3} (Note 1) |
{3,…,14} |
{3,…,14} |
{0,1,2,3} (Note 1) |
{3,…,12} |
{3,…,12} |
Type B |
{0,…,12} |
{2,4,7} |
{2,…,14} |
{0,…,10} |
{2,4,6} |
{2,…,12} |
[38.214 clause 5.1.2.2]
Two downlink resource allocation schemes, type 0 and type 1, are supported. The UE shall assume that when the scheduling grant is received with DCI format 1_0, then downlink resource allocation type 1 is used.
[38.214 clause 5.1.2.2.2]
In downlink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved or interleaved virtual resource blocks within the active bandwidth part of size PRBs except for the case when DCI format 1_0 is decoded in any common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
A downlink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed .
[TS 38.214, clause 5.1.3]
To determine the modulation order, target code rate, and transport block size(s) in the physical downlink shared channel, the UE shall first
– read the 5-bit modulation and coding scheme field (IMCS) in the DCI to determine the modulation order (Qm) and target code rate (R) based on the procedure defined in Subclause 5.1.3.1, and
– read redundancy version field (rv) in the DCI to determine the redundancy version.
and second
– the UE shall use the number of layers (ʋ), the total number of allocated PRBs before rate matching (nPRB) to determine to the transport block size based on the procedure defined in Subclause 5.1.3.2.
The UE may skip decoding a transport block in an initial transmission if the effective channel code rate is higher than 0.95, where the effective channel code rate is defined as the number of downlink information bits (including CRC bits) divided by the number of physical channel bits on PDSCH. If the UE skips decoding, the physical layer indicates to higher layer that the transport block is not successfully decoded.
[TS 38.214, clause 5.1.3.1]
For the PDSCH scheduled by a PDCCH with DCI format 1_0 or format 1_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, SI-RNTI, RA-RNTI, or P-RNTI,
if the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with a DCI format 1_1 and the CRC is scrambled by C-RNTI or CS-RNTI
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with new-RNTI, the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam64LowSE’, and the PDSCH is scheduled with C-RNTI, and the PDSCH is assigned by a PDCCH in a UE-specific search space
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is configured with new-RNTI, and the PDSCH is scheduled with new-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with the higher layer parameter mcs-Table given by SPS-config, the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, the PDSCH is scheduled with CS-RNTI, and the PDSCH is assigned by a PDCCH with DCI format 1_1
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is configured with the higher layer parameter mcs-Table given by SPS-config set to ‘qam64LowSE’, and the PDSCH is scheduled with CS-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
else
– the UE shall use IMCS and Table 5.1.3.1-1 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
End
The UE is not expected to decode a PDSCH scheduled with P-RNTI, RA-RNTI, SI-RNTI and Qm > 2
Table 5.1.3.1-1: MCS index table 1 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
120 |
0.2344 |
1 |
2 |
157 |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
4 |
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
438 |
2.5664 |
18 |
6 |
466 |
2.7305 |
19 |
6 |
517 |
3.0293 |
20 |
6 |
567 |
3.3223 |
21 |
6 |
616 |
3.6094 |
22 |
6 |
666 |
3.9023 |
23 |
6 |
719 |
4.2129 |
24 |
6 |
772 |
4.5234 |
25 |
6 |
822 |
4.8164 |
26 |
6 |
873 |
5.1152 |
27 |
6 |
910 |
5.3320 |
28 |
6 |
948 |
5.5547 |
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 5.1.3.2]
In case the higher layer parameter maxNrofCodeWordsScheduledByDCI indicates that two codeword transmission is enabled, then a transport block is disabled by DCI format 1_1 if IMCS = 26 and if rvid = 1 for the corresponding transport block, otherwise the transport block is enabled. If both transport blocks are enabled, transport block 1 and 2 are mapped to codeword 0 and 1 respectively. If only one transport block is enabled, then the enabled transport block is always mapped to the first codeword.
For the PDSCH assigned by a PDCCH with DCI format 1_0 or format 1_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SI-RNTI, if Table 5.1.3.1-2 is used and , or a table other than Table 5.1.3.1-2 is used and , the UE shall, except if the transport block is disabled in DCI format 1_1, first determine the TBS as specified below:
1) The UE shall first determine the number of REs (NRE) within the slot.
– A UE first determines the number of REs allocated for PDSCH within a PRB () by , where is the number of subcarriers in a physical resource block, is the number of symbols of the PDSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 1_1 or as described for format 1_0 in Subclause 5.1.6.2, and is the overhead configured by higher layer parameter xOverhead in PDSCH-ServingCellConfig. If the xOverhead in PDSCH-ServingCellconfig is not configured (a value from 0, 6, 12, or 18), the is set to 0. If the PDSCH is scheduled by PDCCH with a CRC scrambled by SI-RNTI, RA-RNTI or P-RNTI, is assumed to be 0.
– A UE determines the total number of REs allocated for PDSCH () by , where nPRB is the total number of allocated PRBs for the UE.
2) Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.1.1.3 Test description
7.1.1.4.1.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value) and Short_DCI condition is applied in NR Serving cell configuration.
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest mandatory UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.1.1.3.2 Test procedure sequence
Table 7.1.1.4.1.1.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.1.1.3.2-2: Number of downlink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
|||
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
|||
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
|||
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
|||
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
|||
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
|||
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
|||
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
|||
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
|||
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
|||
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
|||
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
|||
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
|||
144921 ≤ TBS ≤ 156992 |
13 |
8*FLOOR((TBS – 992)/104) |
|||
156993 ≤ TBS ≤ 169064 |
14 |
8*FLOOR((TBS – 1064)/112) |
|||
169065 ≤ TBS ≤ 181136 |
15 |
8*FLOOR((TBS – 1136)/120) |
|||
181137 ≤ TBS ≤ 193208 |
16 |
8*FLOOR((TBS – 1208)/128) |
|||
193209 ≤ TBS ≤ 205280 |
17 |
8*FLOOR((TBS – 1280)/136) |
|||
205281 ≤ TBS ≤ 217352 |
18 |
8*FLOOR((TBS – 1352)/144) |
|||
217353 ≤ TBS ≤ 229424 |
19 |
8*FLOOR((TBS – 1424)/152) |
|||
TBS> 229424 |
20 |
8*FLOOR((TBS –1496)/160) |
|||
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.1.1.3.2-3: Specific Parameters
Parameter |
Value |
Comment |
number of layers (ʋ) |
1 |
|
mcs-Table |
qam64 |
|
xoh-PDSCH |
Not Present |
Results in value 0(xoh0) |
Table 7.1.1.4.1.1.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of 1 to in BWP, time domain resource as per table 7.1.1.4.1.0-1 and from 0 to 28. NOTE: Skip the execution of steps for which the TBS size results in coding rate exceeding 0.95. |
– |
– |
– |
– |
1 |
The SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of DL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.1.1.3.2-1 and larger than or equal to 132 bits as specified in Table 7.1.1.4.1.1.3.2-2 |
– |
– |
– |
– |
2 |
The SS creates one or more PDCP SDUs, depending on TBS, in accordance with Table 7.1.1.4.1.1.3.2-2. |
– |
– |
– |
– |
3 |
The SS transmits the PDCP SDUs concatenated into a MAC PDU and indicates on PDCCH DCI Format 1_0 and values of S, L,and nPRB. |
<– |
MAC PDU (NxPDCP SDUs) DCI: (DCI Format 1_0, S, L,and nPRB.) |
– |
– |
4 |
At the reception of scheduling request the SS transmits UL Grant for transmitting loop back PDCP SDUs. |
<– |
(UL Grant) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3? |
–> |
(NxPDCP SDUs) |
1 |
P |
7.1.1.4.1.1.3.3 Specific message contents
None.
7.1.1.4.1.2 Void
7.1.1.4.1.3 DL-SCH transport block size selection / DCI format 1_1 / RA type 0/RA Type 1 / 2 Codewords enabled
7.1.1.4.1.3.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and maxNrofCodeWordsScheduledByDCI set to ‘n2’ }
ensure that {
when { UE on PDCCH receives DCI format 1_1 indicating resource allocation type 0 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE decodes the received transport block of size correspondent as per Modulation Coding scheme, time domain resource allocation and PRB’s and forwards it to higher layers }
}
(2)
with { UE in RRC_CONNECTED state and maxNrofCodeWordsScheduledByDCI set to ‘n2’ }
ensure that {
when { UE on PDCCH receives DCI format 1_1 indicating resource allocation type 1 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE decodes the received transport block of size correspondent as per Modulation Coding scheme, time domain resource allocation and PRB’s and forwards it to higher layers }
}
7.1.1.4.1.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.2.2, TS 38.214 clause 5.1.2.1, 5.1.2.2.1, 5.1.2.2.2, 5.1.3, 5.1.3.1 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.2.2]
DCI format 1_1 is used for the scheduling of PDSCH in one cell.
The following information is transmitted by means of the DCI format 1_1 with CRC scrambled by C-RNTI or CS-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bits
– The value of this bit field is always set to 1, indicating a DL DCI format
– Carrier indicator – 0 or 3 bits as defined in Subclause 10.1 of [5, TS38.213].
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of DL BWPs configured by higher layers, excluding the initial DL bandwidth part. The bit width for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
– Frequency domain resource assignment – number of bits determined by the following, where is the size of the active DL bandwidth part:
– bits if only resource allocation type 0 is configured, where is defined in Subclause 5.1.2.2.1 of [6, TS38.214],
– bits if only resource allocation type 1 is configured, or
– bits if both resource allocation type 0 and 1 are configured.
– If both resource allocation type 0 and 1 are configured, the MSB bit is used to indicate resource allocation type 0 or resource allocation type 1, where the bit value of 0 indicates resource allocation type 0 and the bit value of 1 indicates resource allocation type 1.
– For resource allocation type 0, the LSBs provide the resource allocation as defined in Subclause 5.1.2.2.1 of [6, TS38.214].
– For resource allocation type 1, the LSBs provide the resource allocation as defined in Subclause 5.1.2.2.2 of [6, TS38.214]
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and if both resource allocation type 0 and 1 are configured for the indicated bandwidth part, the UE assumes resource allocation type 0 for the indicated bandwidth part if the bit width of the “Frequency domain resource assignment” field of the active bandwidth part is smaller than the bit width of the “Frequency domain resource assignment” field of the indicated bandwidth part.
– Time domain resource assignment – 0, 1, 2, 3, or 4 bits as defined in Subclause 5.1.2.1 of [6, TS38.214]. The bit width for this field is determined as bits, where I is the number of entries in the higher layer parameter pusch-AllocationList.
– VRB-to-PRB mapping – 0 or 1 bit
– 0 bit if only resource allocation type 0 is configured;
– 1 bit according to Table 7.3.1.1.2-33 otherwise, only applicable to resource allocation type 1, as defined in Subclause 7.3.1.6 of [4, TS38.211].
– PRB bundling size indicator – 0 bit if the higher layer parameter prb-BundlingType is not configured or is set to ‘static’, or 1 bit if the higher layer parameter prb-BundlingType is set to ‘dynamic’, according to Subclause 5.1.2.3 of [6, TS38.214].
– Rate matching indicator – 0, 1, or 2 bits according to higher layer parameter rateMatchPattern.
– ZP CSI-RS trigger – 0, 1, or 2 bits as defined in Subclause 5.1.4.2 of [6, TS38.214]. The bit width for this field is determined as bits, where is the number of ZP CSI-RS resource sets in the higher layer parameterzp-CSI-RS-Resource.
For transport block 1:
– Modulation and coding scheme – 5 bits as defined in Subclause 5.1.3.1 of [6, TS38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
For transport block 2 (only present if maxNrofCodeWordsScheduledByDCI equals 2
– Modulation and coding scheme – 5 bits as defined in Subclause 5.1.3.1 of [6, TS38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and the value of maxNrofCodeWordsScheduledByDCI for the indicated bandwidth part equals 2 and the value of maxNrofCodeWordsScheduledByDCI for the active bandwidth part equals 1, the UE assumes zeros are padded when interpreting the “Modulation and coding scheme”, “New data indicator”, and “Redundancy version” fields of transport block 2 according to Subclause 12 of [5, TS38.213], and the UE ignores the “Modulation and coding scheme”, “New data indicator”, and “Redundancy version” fields of transport block 2 for the indicated bandwidth part.
– HARQ process number – 4 bits
– Downlink assignment index – number of bits as defined in the following
– 4 bits if more than one serving cell are configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, where the 2 MSB bits are the counter DAI and the 2 LSB bits are the total DAI;
– 2 bits if only one serving cell is configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, where the 2 bits are the counter DAI;
– 0 bits otherwise.
– TPC command for scheduled PUCCH – 2 bits as defined in Subclause 7.2.1 of [5, TS38.213]
– PUCCH resource indicator – 3 bits as defined in Subclause 9.2.3 of [5, TS38.213]
– PDSCH-to-HARQ_feedback timing indicator – 3 0, 1, 2, or bits as defined in Subclause 9.2.3 of [5, TS38.213]. The bit width for this field is determined as bits, where I is the number of entries in the higher layer parameter dl-DataToUL-ACK.
– Antenna port(s) – 4, 5, or 6 bits as defined by Tables 7.3.1.2.2-1/2/3/4, where the number of CDM groups without data of values 1, 2, and 3 refers to CDM groups {0}, {0,1}, and {0, 1,2} respectively. The antenna ports shall be determined according to the ordering of DMRS port(s) given by Tables 7.3.1.2.2-1/2/3/4.
If a UE is configured with both dmrs-DownlinkForPDSCH-MappingTypeA and dmrs-DownlinkForPDSCH-MappingTypeB, the bit width of this field equals , where is the “Antenna ports” bit width derived according to dmrs-DownlinkForPDSCH-MappingTypeA and is the “Antenna ports” bit width derived according to dmrs-DownlinkForPDSCH-MappingTypeB. A number of zeros are padded in the MSB of this field, if the mapping type of the PDSCH corresponds to the smaller value of and .
– Transmission configuration indication – 0 bit if higher layer parameter tci-PresentInDCI is not enabled; otherwise 3 bits as defined in Subclause 5.1.5 of [6, TS38.214].
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and the “Transmission configuration indication” field is not present in the DCI format 1_1, the UE assumes tci-PresentInDCI is not enabled for the indicated bandwidth part.
– SRS request – 2 bits as defined by Table 7.3.1.1.2-24 for UEs not configured with SUL in the cell; 3 bits for UEs configured SUL in the cell where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second and third bits are defined by Table 7.3.1.1.2-24. This bit field may also indicate the associated CSI-RS according to Subclause 6.1.1.2 of [6, TS 38.214].
– CBG transmission information (CBGTI) – 0, 2, 4, 6, or 8 bits as defined in Subclause 5.1.7 of [6, TS38.214], determined by the higher layer parameters maxCodeBlockGroupsPerTransportBlock and Number-MCS-HARQ-DL-DCI for the PDSCH.
– CBG flushing out information (CBGFI) – 0 or 1 bit as defined in Subclause 5.1.7 of [6, TS38.214], determined by higher layer parameter codeBlockGroupFlushIndicator.
– DMRS sequence initialization – 1 bit if both scramblingID0 and scramblingID1 are configured in DMRS-DownlinkConfig for selection defined in Subclause 7.4.1.1.1 of [4, TS38.211]; 0 bit otherwise.
[TS 38.214, clause 5.1.2.1]
When the UE is scheduled to receive PDSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocation table. The determination of the used resource allocation table is defined in sub-clause 5.1.2.1.1. The indexed row defines the slot offset K0, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PDSCH mapping type to be assumed in the PDSCH reception.
Given the parameter values of the indexed row:
– The slot allocated for the PDSCH is , where n is the slot with the scheduling DCI, and K0 is based on the numerology of PDSCH, and and are the subcarrier spacing configurations for PDSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PDSCH are determined from the start and length indicator SLIV:
if then
else
where, and
– The PDSCH mapping type is set to Type A or Type B as defined in sub-clause 7.4.1.1.2 of [4, TS 38.211].
The UE shall consider the S and L combinations defined in table 5.1.2.1-1 as valid PDSCH allocations:
Table 5.1.2.1-1: Valid S and L combinations
PDSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
{0,1,2,3} (Note 1) |
{3,…,14} |
{3,…,14} |
{0,1,2,3} (Note 1) |
{3,…,12} |
{3,…,12} |
Type B |
{0,…,12} |
{2,4,7} |
{2,…,14} |
{0,…,10} |
{2,4,6} |
{2,…,12} |
Note 1: S = 3 is applicable only if dmrs-TypeA-Posiition = 3 |
[TS 38.214, clause 5.1.2.2.1]
In downlink resource allocation of type 0, the resource block assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE where a RBG is a set of consecutive virtual resource blocks defined by higher layer parameter rbg-Size configured for PDSCH and the size of the carrier bandwidth part as defined in Table 5.1.2.2.1-1.
Table 5.1.2.2.1-1: Nominal RBG size P
Bandwidth Part Size |
Configuration 1 |
Configuration 2 |
1 – 36 |
2 |
4 |
37 – 72 |
4 |
8 |
73 – 144 |
8 |
16 |
145 – 275 |
16 |
16 |
The total number of RBGs () for a downlink carrier bandwidth part i of size PRBs is given by , where
– the size of the first RBG is ,
– the size of last RBG is if and P otherwise,
– the size of all other RBGs is P.
The bitmap is of size bits with one bitmap bit per RBG such that each RBG is addressable. The RBGs shall be indexed in the order of increasing frequency and starting at the lowest frequency of the carrier bandwidth part. The order of RBG bitmap is such that RBG 0 to RBG are mapped from MSB to LSB. The RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE otherwise.
[TS 38.214, clause 5.1.2.2.2]
In downlink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated localized or distributed virtual resource blocks within the active carrier bandwidth part of size PRBs except for the case when DCI format 1_0 is decoded in the common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
A downlink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed .
[TS 38.214, clause 5.1.3]
To determine the modulation order, target code rate, and transport block size(s) in the physical downlink shared channel, the UE shall first
– read the 5-bit modulation and coding scheme field (IMCS) in the DCI to determine the modulation order (Qm) and target code rate (R) based on the procedure defined in Subclause 5.1.3.1, and
– read redundancy version field (rv) in the DCI to determine the redundancy version.
and second
– the UE shall use the number of layers (ʋ), the total number of allocated PRBs before rate matching (nPRB) to determine to the transport block size based on the procedure defined in Subclause 5.1.3.2.
The UE may skip decoding a transport block in an initial transmission if the effective channel code rate is higher than 0.95, where the effective channel code rate is defined as the number of downlink information bits (including CRC bits) divided by the number of physical channel bits on PDSCH. If the UE skips decoding, the physical layer indicates to higher layer that the transport block is not successfully decoded.
[TS 38.214, clause 5.1.3.1]
For the PDSCH scheduled by a PDCCH with DCI format 1_0 or format 1_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, SI-RNTI, RA-RNTI, or P-RNTI,
if the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with a DCI format 1_1 and the CRC is scrambled by C-RNTI or CS-RNTI
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with new-RNTI, the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam64LowSE’, and the PDSCH is scheduled with C-RNTI, and the PDSCH is assigned by a PDCCH in a UE-specific search space
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is configured with new-RNTI, and the PDSCH is scheduled with new-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with the higher layer parameter mcs-Table given by SPS-config, the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, the PDSCH is scheduled with CS-RNTI, and the PDSCH is assigned by a PDCCH with DCI format 1_1
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is configured with the higher layer parameter mcs-Table given by SPS-config set to ‘qam64LowSE’, and the PDSCH is scheduled with CS-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
else
– the UE shall use IMCS and Table 5.1.3.1-1 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
End
The UE is not expected to decode a PDSCH scheduled with P-RNTI, RA-RNTI, SI-RNTI and Qm > 2
Table 5.1.3.1-1: MCS index table 1 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
120 |
0.2344 |
1 |
2 |
157 |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
4 |
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
438 |
2.5664 |
18 |
6 |
466 |
2.7305 |
19 |
6 |
517 |
3.0293 |
20 |
6 |
567 |
3.3223 |
21 |
6 |
616 |
3.6094 |
22 |
6 |
666 |
3.9023 |
23 |
6 |
719 |
4.2129 |
24 |
6 |
772 |
4.5234 |
25 |
6 |
822 |
4.8164 |
26 |
6 |
873 |
5.1152 |
27 |
6 |
910 |
5.3320 |
28 |
6 |
948 |
5.5547 |
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 5.1.3.2]
In case the higher layer parameter maxNrofCodeWordsScheduledByDCI indicates that two codeword transmission is enabled, then a transport block is disabled by DCI format 1_1 if IMCS = 26 and if rvid = 1 for the corresponding transport block, otherwise the transport block is enabled. If both transport blocks are enabled, transport block 1 and 2 are mapped to codeword 0 and 1 respectively. If only one transport block is enabled, then the enabled transport block is always mapped to the first codeword.
For the PDSCH assigned by a PDCCH with DCI format 1_0 or format 1_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SI-RNTI, if Table 5.1.3.1-2 is used and , or a table other than Table 5.1.3.1-2 is used and , the UE shall, except if the transport block is disabled in DCI format 1_1, first determine the TBS as specified below:
1) The UE shall first determine the number of REs (NRE) within the slot.
– A UE first determines the number of REs allocated for PDSCH within a PRB () by , where is the number of subcarriers in a physical resource block, is the number of symbols of the PDSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 1_1 or as described for format 1_0 in Subclause 5.1.6.2, and is the overhead configured by higher layer parameter xOverhead in PDSCH-ServingCellConfig. If the xOverhead in PDSCH-ServingCellconfig is not configured (a value from 0, 6, 12, or 18), the is set to 0. If the PDSCH is scheduled by PDCCH with a CRC scrambled by SI-RNTI, RA-RNTI or P-RNTI, is assumed to be 0.
– A UE determines the total number of REs allocated for PDSCH () by , where nPRB is the total number of allocated PRBs for the UE.
2) Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.1.3.3 Test description
7.1.1.4.1.3.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value).
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest mandatory UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.1.3.3.2 Test procedure sequence
Table 7.1.1.4.1.3.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.1.3.3.2-2: Number of downlink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
192 ≤ TBS ≤12184 note 2 |
1 |
8*FLOOR((TBS – 184)/8) |
12185≤ TBS ≤24256 |
2 |
8*FLOOR((TBS – 256)/16) |
24257≤ TBS ≤ 36328 |
3 |
8*FLOOR((TBS – 328)/24) |
36329 ≤ TBS ≤48400 |
4 |
8*FLOOR((TBS –400)/32) |
48401≤ TBS ≤60472 |
5 |
8*FLOOR((TBS – 472)/40) |
60473 ≤ TBS ≤ 72544 |
6 |
8*FLOOR((TBS – 544)/48) |
72545≤ TBS ≤84616 |
7 |
8*FLOOR((TBS – 616)/56) |
84617 ≤ TBS ≤96688 |
8 |
8*FLOOR((TBS – 688)/64) |
96689< TBS ≤108760 |
9 |
8*FLOOR((TBS – 760)/72) |
108761 ≤ TBS ≤120832 |
10 |
8*FLOOR((TBS –832)/80) |
120833≤ TBS ≤132904 |
11 |
8*FLOOR((TBS – 904)/88) |
132905 ≤ TBS ≤ 144976 |
12 |
8*FLOOR((TBS – 976)/96) |
TBS> 144976 |
13 |
8*FLOOR((TBS – 1048)/104) |
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU – 32 bit Additional RLC header with SO if one RLC SDU gets split in 2 TBS and 24 bit MAC header for this additional PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24– N*24 -112 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 192 bits. |
Table 7.1.1.4.1.3.3.2-2A: Bandwidth part Dependent Parameters for Resource allocation 0 with start of BWP assumed as 0
= |
Nominal RBG size P (Configuration1) |
Size of last RBG |
Allowed Values |
11 |
2 |
1 |
All 1…11 |
18 |
2 |
2 |
2,4,6,8,10,12,16,18 |
24 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24 |
25 |
2 |
1 |
All 1…25 |
31 |
2 |
1 |
All 1…31 |
32 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32 |
38 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38 |
51 |
4 |
3 |
3,4,7,8,11,12,15,16,19,20,23,24,27,28,31,32,35,36,39,40,43,44,47,48,51 |
52 |
4 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52 |
65 |
4 |
1 |
1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,41,44,45,48,49, 52,53,56,57,60,61,64,65 |
66 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52, 54,56,58,60,62,64,66 |
79 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79 |
106 |
8 |
2 |
2,8,10,16,18,24,26,32,34,40,42,48,50,56,58,64,66,72,74,80,82,88,90,96, 92,104,106 |
107 |
8 |
3 |
3,8,11,16,19,24,27,32,35,40,43,48,51,56,59,64,67,72,75,80,83,88,91,96, 99,104,107 |
132 |
8 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96, 100,104, 108,112,116,120,124,128,132 |
133 |
8 |
5 |
5,8,13,16,21,24,29,32,37,40,45,48,53,56,61,64,69,72,77,80,85,88,93,96, 101,104, 109,112,117,120,125,128,133 |
135 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79,80,87,88,95,96, 103,104, 111,112,119,120,127,128,135 |
160 |
16 |
16 |
16,32,48,64,80,96,112,128,144,160 |
216 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152,160, 168, 176,184,192,200,208,216 |
217 |
16 |
9 |
9,16,25,32,41,48,57,64,73,80,89,96,105,112,121,128,137,144,153,160, 169,176,185,192,201,208,217 |
264 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,160,168, 176,184,192,200,208,216,224,232,240,248,256,264 |
270 |
16 |
14 |
14,16,30,32,46,44,62,64,78,80,94,96,110,112, 126,128,142,144,158, 160,174, 176,190,192, 206,208,222,224,238,240, 254,256,270 |
273 |
16 |
1 |
1,16,17,32,33,48,49,64,65,80,81,96,97,112,113,128,129,144,145,160, 161,176,171, 192,193, 208,209, 224,225,240,241,256,257,272,273 |
Table 7.1.1.4.1.3.3.2-3: Specific Parameter
Parameter |
Value |
Comments |
Condition |
number of layers (ʋ) |
1 |
||
mcs-Table |
qam64 |
||
resourceAllocation |
dynamicSwitch |
pc_dynamicSwitchRA_Type0_1_PDSCH |
|
resourceAllocationType0 |
NOT pc_dynamicSwitchRA_Type0_1_PDSCH AND Steps 1-5 |
||
resourceAllocationType1 |
NOT pc_dynamicSwitchRA_Type0_1_PDSCH AND Steps 6-10 |
||
maxNrofCodeWordsScheduledByDCI |
n2 |
both codewords enabled |
|
NstartBWP |
0 |
Table 7.1.1.4.1.3.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of as per table 7.1.1.4.1.3.3.2-2A in BWP, time domain resource as per table 7.1.1.4.1.0-1 and from 0 to 28. NOTE: Skip the execution of steps for which the TBS size results in coding rate exceeding 0.95. |
– |
– |
– |
– |
1 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. The SS uses the same and TBS for both transport blocks: = = TBS 1= TBS 2= TBS |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS1 + TBS2 is less than or equal to UE capability "Maximum number of DL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.1.3.3.2-1 and larger than or equal to 192 bits as specified in Table 7.1.1.4.1.3.3.2-2. |
– |
– |
– |
– |
2 |
SS creates one or more PDCP SDUs for transport block 1 and 2 depending on TBS1, and TBS2 in accordance with Table 7.1.1.4.1.3.3.2-2. |
– |
– |
– |
– |
3 |
SS transmits the PDCP SDUs concatenated into a MAC PDU and indicates on PDCCH DCI Format 1_1 resource allocation 0 and values of S, L, , and nPRB. |
<– |
Transport block 1: MAC PDU Transport block 2: MAC PDU DCI: (DCI Format 1_1, S, L,, and nPRB.) |
– |
– |
4 |
At the reception of scheduling request the SS transmits UL Grant for transmitting loop back PDCP SDUs. |
<– |
(UL Grant) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3? |
–> |
(NxPDCP SDUs) |
1 |
P |
– |
EXCEPTION : Steps 5Aa1 to 5Aa2 are executed if NOT pc_dynamicSwitchRA_Type0_1_PDSCH |
– |
– |
– |
– |
5Aa1 |
The SS transmits a NR RRCReconfiguration message including PDSCH-Config with IE resourceAllocation set to resourceAllocationType1 (Note 1) |
<– |
RRCReconfiguration |
– |
– |
5Aa2 |
The UE transmit a NR RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
– |
EXCEPTION: Steps 6 to 10 are repeated for allowed values of 1 to in BWP, time domain resource as per table 7.1.1.4.1.0-1 and from 0 to 28. |
– |
– |
– |
– |
6 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. The SS uses the same and TBS for both transport blocks: = = TBS 1= TBS 2= TBS |
– |
– |
– |
– |
– |
EXCEPTION: Steps 7 to 10 are performed if TBS1 + TBS2 is less than or equal to UE capability "Maximum number of DL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.1.3.3.2-1 and larger than or equal to 192 bits as specified in Table 7.1.1.4.1.3.3.2-2. |
– |
– |
– |
– |
7 |
SS creates one or more PDCP SDUs for transport block 1 and 2 depending on TBS1, and TBS2 in accordance with Table 7.1.1.4.1.3.3.2-2. |
– |
– |
– |
– |
8 |
SS transmits the PDCP SDUs concatenated into a MAC PDU and indicates on PDCCH DCI Format 1_1 resource allocation 1 and values of S, L, , and nPRB. |
<– |
Transport block 1: MAC PDU Transport block 2: MAC PDU DCI: (DCI Format 1_1, S, L,, and nPRB.) |
– |
– |
9 |
At the reception of scheduling request the SS transmits UL Grant for transmitting loop back PDCP SDUs. |
<– |
(UL Grant) |
– |
– |
10 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3? |
–> |
(NxPDCP SDUs) |
2 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.4.1.3.3.3 Specific message contents
None.
7.1.1.4.1.4 DL-SCH transport block size selection / DCI format 1_1 / RA type 0/RA Type 1 / 2 Codewords enabled / 256QAM
7.1.1.4.1.4.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state, maxNrofCodeWordsScheduledByDCI set to ‘n2’ and mcs-Table is set as ‘qam256‘ }
ensure that {
when { UE on PDCCH receives DCI format 1_1 indicating resource allocation type 0 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE decodes the received transport block of size correspondent as per Modulation Coding scheme, time domain resource allocation and PRB’s and forwards it to higher layers }
}
(2)
with { UE in RRC_CONNECTED state, maxNrofCodeWordsScheduledByDCI set to ‘n2’ and mcs-Table is set as ‘qam256‘ }
ensure that {
when { UE on PDCCH receives DCI format 1_1 indicating resource allocation type 1 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE decodes the received transport block of size correspondent as per Modulation Coding scheme, time domain resource allocation and PRB’s and forwards it to higher layers }
}
7.1.1.4.1.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.2.2, TS 38.214 clauses 5.1.2.1, 5.1.2.2.1, 5.1.2.2.2, 5.1.3, 5.1.3.1 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.2.2]
DCI format 1_1 is used for the scheduling of PDSCH in one cell.
The following information is transmitted by means of the DCI format 1_1 with CRC scrambled by C-RNTI or CS-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bits
– The value of this bit field is always set to 1, indicating a DL DCI format
– Carrier indicator – 0 or 3 bits as defined in Subclause 10.1 of [5, TS38.213].
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of DL BWPs configured by higher layers, excluding the initial DL bandwidth part. The bit width for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
– Frequency domain resource assignment – number of bits determined by the following, where is the size of the active DL bandwidth part:
– bits if only resource allocation type 0 is configured, where is defined in Subclause 5.1.2.2.1 of [6, TS38.214],
– bits if only resource allocation type 1 is configured, or
– bits if both resource allocation type 0 and 1 are configured.
– If both resource allocation type 0 and 1 are configured, the MSB bit is used to indicate resource allocation type 0 or resource allocation type 1, where the bit value of 0 indicates resource allocation type 0 and the bit value of 1 indicates resource allocation type 1.
– For resource allocation type 0, the LSBs provide the resource allocation as defined in Subclause 5.1.2.2.1 of [6, TS38.214].
– For resource allocation type 1, the LSBs provide the resource allocation as defined in Subclause 5.1.2.2.2 of [6, TS38.214]
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and if both resource allocation type 0 and 1 are configured for the indicated bandwidth part, the UE assumes resource allocation type 0 for the indicated bandwidth part if the bit width of the “Frequency domain resource assignment” field of the active bandwidth part is smaller than the bit width of the “Frequency domain resource assignment” field of the indicated bandwidth part.
– Time domain resource assignment – 0, 1, 2, 3, or 4 bits as defined in Subclause 5.1.2.1 of [6, TS38.214]. The bit width for this field is determined as bits, where I is the number of entries in the higher layer parameter pusch-AllocationList.
– VRB-to-PRB mapping – 0 or 1 bit
– 0 bit if only resource allocation type 0 is configured;
– 1 bit according to Table 7.3.1.1.2-33 otherwise, only applicable to resource allocation type 1, as defined in Subclause 7.3.1.6 of [4, TS38.211].
– PRB bundling size indicator – 0 bit if the higher layer parameter prb-BundlingType is not configured or is set to ‘static’, or 1 bit if the higher layer parameter prb-BundlingType is set to ‘dynamic’, according to Subclause 5.1.2.3 of [6, TS38.214].
– Rate matching indicator – 0, 1, or 2 bits according to higher layer parameter rateMatchPattern.
– ZP CSI-RS trigger – 0, 1, or 2 bits as defined in Subclause 5.1.4.2 of [6, TS38.214]. The bit width for this field is determined as bits, where is the number of ZP CSI-RS resource sets in the higher layer parameterzp-CSI-RS-Resource.
For transport block 1:
– Modulation and coding scheme – 5 bits as defined in Subclause 5.1.3.1 of [6, TS38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
For transport block 2 (only present if maxNrofCodeWordsScheduledByDCI equals 2
– Modulation and coding scheme – 5 bits as defined in Subclause 5.1.3.1 of [6, TS38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and the value of maxNrofCodeWordsScheduledByDCI for the indicated bandwidth part equals 2 and the value of maxNrofCodeWordsScheduledByDCI for the active bandwidth part equals 1, the UE assumes zeros are padded when interpreting the “Modulation and coding scheme”, “New data indicator”, and “Redundancy version” fields of transport block 2 according to Subclause 12 of [5, TS38.213], and the UE ignores the “Modulation and coding scheme”, “New data indicator”, and “Redundancy version” fields of transport block 2 for the indicated bandwidth part.
– HARQ process number – 4 bits
– Downlink assignment index – number of bits as defined in the following
– 4 bits if more than one serving cell are configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, where the 2 MSB bits are the counter DAI and the 2 LSB bits are the total DAI;
– 2 bits if only one serving cell is configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, where the 2 bits are the counter DAI;
– 0 bits otherwise.
– TPC command for scheduled PUCCH – 2 bits as defined in Subclause 7.2.1 of [5, TS38.213]
– PUCCH resource indicator – 3 bits as defined in Subclause 9.2.3 of [5, TS38.213]
– PDSCH-to-HARQ_feedback timing indicator – 0, 1, 2, or 3 bits as defined in Subclause 9.2.3 of [5, TS38.213]. The bit width for this field is determined as bits, where I is the number of entries in the higher layer parameter dl-DataToUL-ACK.
– Antenna port(s) – 4, 5, or 6 bits as defined by Tables 7.3.1.2.2-1/2/3/4, where the number of CDM groups without data of values 1, 2, and 3 refers to CDM groups {0}, {0,1}, and {0, 1,2} respectively. The antenna ports shall be determined according to the ordering of DMRS port(s) given by Tables 7.3.1.2.2-1/2/3/4.
If a UE is configured with both dmrs-DownlinkForPDSCH-MappingTypeA and dmrs-DownlinkForPDSCH-MappingTypeB, the bit width of this field equals , where is the “Antenna ports” bit width derived according to dmrs-DownlinkForPDSCH-MappingTypeA and is the “Antenna ports” bit width derived according to dmrs-DownlinkForPDSCH-MappingTypeB. A number of zeros are padded in the MSB of this field, if the mapping type of the PDSCH corresponds to the smaller value of and .
– Transmission configuration indication – 0 bit if higher layer parameter tci-PresentInDCI is not enabled; otherwise 3 bits as defined in Subclause 5.1.5 of [6, TS38.214].
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and the “Transmission configuration indication” field is not present in the DCI format 1_1, the UE assumes tci-PresentInDCI is not enabled for the indicated bandwidth part.
– SRS request – 2 bits as defined by Table 7.3.1.1.2-24 for UEs not configured with SUL in the cell; 3 bits for UEs configured SUL in the cell where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second and third bits are defined by Table 7.3.1.1.2-24. This bit field may also indicate the associated CSI-RS according to Subclause 6.1.1.2 of [6, TS 38.214].
– CBG transmission information (CBGTI) – 0, 2, 4, 6, or 8 bits as defined in Subclause 5.1.7 of [6, TS38.214], determined by the higher layer parameters maxCodeBlockGroupsPerTransportBlock and Number-MCS-HARQ-DL-DCI for the PDSCH.
– CBG flushing out information (CBGFI) – 0 or 1 bit as defined in Subclause 5.1.7 of [6, TS38.214], determined by higher layer parameter codeBlockGroupFlushIndicator.
– DMRS sequence initialization – 1 bit if both scramblingID0 and scramblingID1 are configured in DMRS-DownlinkConfig for selection defined in Subclause 7.4.1.1.1 of [4, TS38.211]; 0 bit otherwise.
[TS 38.214, clause 5.1.2.1]
When the UE is scheduled to receive PDSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocation table. The determination of the used resource allocation table is defined in sub-clause 5.1.2.1.1. The indexed row defines the slot offset K0, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PDSCH mapping type to be assumed in the PDSCH reception.
Given the parameter values of the indexed row:
– The slot allocated for the PDSCH is , where n is the slot with the scheduling DCI, and K0 is based on the numerology of PDSCH, and and are the subcarrier spacing configurations for PDSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PDSCH are determined from the start and length indicator SLIV:
if then
else
where, and
– The PDSCH mapping type is set to Type A or Type B as defined in sub-clause 7.4.1.1.2 of [4, TS 38.211].
The UE shall consider the S and L combinations defined in table 5.1.2.1-1 as valid PDSCH allocations:
Table 5.1.2.1-1: Valid S and L combinations
PDSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
{0,1,2,3 (Note 1)} |
{3,…,14} |
{3,…,14} |
{0,1,2,3 (Note 1)} |
{3,…,12} |
{3,…,12} |
Type B |
{0,…,12} |
{2,4,7} |
{2,…,14} |
{0,…,10} |
{2,4,6} |
{2,…,12} |
Note 1: S = 3 is applicable only if dmrs-TypeA-Posiition = 3 |
[TS 38.214, clause 5.1.2.2.1]
In downlink resource allocation of type 0, the resource block assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE where a RBG is a set of consecutive virtual resource blocks defined by higher layer parameter rbg-Size configured for PDSCH and the size of the carrier bandwidth part as defined in Table 5.1.2.2.1-1.
Table 5.1.2.2.1-1: Nominal RBG size P
Bandwidth Part Size |
Configuration 1 |
Configuration 2 |
1 – 36 |
2 |
4 |
37 – 72 |
4 |
8 |
73 – 144 |
8 |
16 |
145 – 275 |
16 |
16 |
The total number of RBGs () for a downlink carrier bandwidth part i of size PRBs is given by , where
– the size of the first RBG is ,
– the size of last RBG is if and P otherwise,
– the size of all other RBGs is P.
The bitmap is of size bits with one bitmap bit per RBG such that each RBG is addressable. The RBGs shall be indexed in the order of increasing frequency and starting at the lowest frequency of the carrier bandwidth part. The order of RBG bitmap is such that RBG 0 to RBG are mapped from MSB to LSB. The RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE otherwise.
[TS 38.214, clause 5.1.2.2.2]
In downlink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated localized or distributed virtual resource blocks within the active carrier bandwidth part of size PRBs except for the case when DCI format 1_0 is decoded in the common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
A downlink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed .
[TS 38.214, clause 5.1.3]
To determine the modulation order, target code rate, and transport block size(s) in the physical downlink shared channel, the UE shall first
– read the 5-bit modulation and coding scheme field (IMCS) in the DCI to determine the modulation order (Qm) and target code rate (R) based on the procedure defined in Subclause 5.1.3.1, and
– read redundancy version field (rv) in the DCI to determine the redundancy version.
and second
– the UE shall use the number of layers (ʋ), the total number of allocated PRBs before rate matching (nPRB) to determine to the transport block size based on the procedure defined in Subclause 5.1.3.2.
The UE may skip decoding a transport block in an initial transmission if the effective channel code rate is higher than 0.95, where the effective channel code rate is defined as the number of downlink information bits (including CRC bits) divided by the number of physical channel bits on PDSCH. If the UE skips decoding, the physical layer indicates to higher layer that the transport block is not successfully decoded.
[TS 38.214, clause 5.1.3.1]
For the PDSCH scheduled by a PDCCH with DCI format 1_0 or format 1_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, SI-RNTI, RA-RNTI, or P-RNTI,
if the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with a DCI format 1_1 and the CRC is scrambled by C-RNTI or CS-RNTI
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with new-RNTI, the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam64LowSE’, and the PDSCH is scheduled with C-RNTI, and the PDSCH is assigned by a PDCCH in a UE-specific search space
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is configured with new-RNTI, and the PDSCH is scheduled with new-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with the higher layer parameter mcs-Table given by SPS-config, the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, the PDSCH is scheduled with CS-RNTI, and the PDSCH is assigned by a PDCCH with DCI format 1_1
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is configured with the higher layer parameter mcs-Table given by SPS-config set to ‘qam64LowSE’, and the PDSCH is scheduled with CS-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
else
– the UE shall use IMCS and Table 5.1.3.1-1 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
End
The UE is not expected to decode a PDSCH scheduled with P-RNTI, RA-RNTI, SI-RNTI and Qm > 2
…
Table 5.1.3.1-2: MCS index table 2 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
120 |
0.2344 |
1 |
2 |
193 |
0.3770 |
2 |
2 |
308 |
0.6016 |
3 |
2 |
449 |
0.8770 |
4 |
2 |
602 |
1.1758 |
5 |
4 |
378 |
1.4766 |
6 |
4 |
434 |
1.6953 |
7 |
4 |
490 |
1.9141 |
8 |
4 |
553 |
2.1602 |
9 |
4 |
616 |
2.4063 |
10 |
4 |
658 |
2.5703 |
11 |
6 |
466 |
2.7305 |
12 |
6 |
517 |
3.0293 |
13 |
6 |
567 |
3.3223 |
14 |
6 |
616 |
3.6094 |
15 |
6 |
666 |
3.9023 |
16 |
6 |
719 |
4.2129 |
17 |
6 |
772 |
4.5234 |
18 |
6 |
822 |
4.8164 |
19 |
6 |
873 |
5.1152 |
20 |
8 |
682.5 |
5.3320 |
21 |
8 |
711 |
5.5547 |
22 |
8 |
754 |
5.8906 |
23 |
8 |
797 |
6.2266 |
24 |
8 |
841 |
6.5703 |
25 |
8 |
885 |
6.9141 |
26 |
8 |
916.5 |
7.1602 |
27 |
8 |
948 |
7.4063 |
28 |
2 |
reserved |
|
29 |
4 |
reserved |
|
30 |
6 |
reserved |
|
31 |
8 |
reserved |
[TS 38.214, clause 5.1.3.2]
In case the higher layer parameter maxNrofCodeWordsScheduledByDCI indicates that two codeword transmission is enabled, then a transport block is disabled by DCI format 1_1 if IMCS = 26 and if rvid = 1 for the corresponding transport block, otherwise the transport block is enabled. If both transport blocks are enabled, transport block 1 and 2 are mapped to codeword 0 and 1 respectively. If only one transport block is enabled, then the enabled transport block is always mapped to the first codeword.
For the PDSCH assigned by a PDCCH with DCI format 1_0 or format 1_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SI-RNTI, if Table 5.1.3.1-2 is used and , or a table other than Table 5.1.3.1-2 is used and , the UE shall, except if the transport block is disabled in DCI format 1_1, first determine the TBS as specified below:
1) The UE shall first determine the number of REs (NRE) within the slot.
– A UE first determines the number of REs allocated for PDSCH within a PRB () by , where is the number of subcarriers in a physical resource block, is the number of symbols of the PDSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 1_1 or as described for format 1_0 in Subclause 5.1.6.2, and is the overhead configured by higher layer parameter xOverhead in PDSCH-ServingCellConfig. If the xOverhead in PDSCH-ServingCellconfig is not configured (a value from 0, 6, 12, or 18), the is set to 0. If the PDSCH is scheduled by PDCCH with a CRC scrambled by SI-RNTI, RA-RNTI or P-RNTI, is assumed to be 0.
– A UE determines the total number of REs allocated for PDSCH () by , where nPRB is the total number of allocated PRBs for the UE.
2) Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.1.4.3 Test description
7.1.1.4.1.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value).
Test frequency NRf1 is as specified in TS 38.508-1[4] clause 4.3.1 using the common highest UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1[4] clause 6.2.3.1.
7.1.1.4.1.4.3.2 Test procedure sequence
Table 7.1.1.4.1.4.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.1.4.3.2-2: Number of downlink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] |
192 ≤ TBS ≤12184 note 2 |
1 |
8*FLOOR((TBS – 184)/8) |
12185≤ TBS ≤24256 |
2 |
8*FLOOR((TBS – 256)/16) |
24257≤ TBS ≤ 36328 |
3 |
8*FLOOR((TBS – 328)/24) |
36329 ≤ TBS ≤48400 |
4 |
8*FLOOR((TBS –400)/32) |
48401≤ TBS ≤60472 |
5 |
8*FLOOR((TBS – 472)/40) |
60473 ≤ TBS ≤ 72544 |
6 |
8*FLOOR((TBS – 544)/48) |
72545≤ TBS ≤84616 |
7 |
8*FLOOR((TBS – 616)/56) |
84617 ≤ TBS ≤96688 |
8 |
8*FLOOR((TBS – 688)/64) |
96689< TBS ≤108760 |
9 |
8*FLOOR((TBS – 760)/72) |
108761 ≤ TBS ≤120832 |
10 |
8*FLOOR((TBS –832)/80) |
120833≤ TBS ≤132904 |
11 |
8*FLOOR((TBS – 904)/88) |
132905 ≤ TBS ≤ 144976 |
12 |
8*FLOOR((TBS – 976)/96) |
144785 ≤ TBS ≤ 157048 |
13 |
8*FLOOR((TBS – 1048)/104) |
157049 ≤ TBS ≤ 169120 |
14 |
8*FLOOR((TBS – 1120)/112) |
169121< TBS ≤ 181192 |
15 |
8*FLOOR((TBS – 1192)/120) |
181193 ≤ TBS ≤193264 |
16 |
8*FLOOR((TBS – 1264)/128) |
193337 ≤ TBS ≤ 205336 |
17 |
8*FLOOR((TBS – 1336)/136) |
205409 ≤ TBS ≤ 217408 |
18 |
8*FLOOR((TBS – 1408)/144) |
TBS> 217408 |
19 |
8*FLOOR((TBS – 1480)/152) |
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU – 32 bit Additional RLC header with SO if one RLC SDU gets split in 2 TBS and 24 bit MAC header for this additional PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24– N*24 -112 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 192 bits. |
Table 7.1.1.4.1.4.3.2-2A: Bandwidth part Dependent Parameters for Resource allocation 0 with start of BWP assumed as 0
= |
Nominal RBG size P (Configuration1) |
Size of last RBG |
Allowed Values |
11 |
2 |
1 |
All 1…11 |
18 |
2 |
2 |
2,4,6,8,10,12,16,18 |
24 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24 |
25 |
2 |
1 |
All 1…25 |
31 |
2 |
1 |
All 1…31 |
32 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32 |
38 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38 |
51 |
4 |
3 |
3,4,7,8,11,12,15,16,19,20,23,24,27,28,31,32,35,36,39,40,43,44,47,48,51 |
52 |
4 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52 |
65 |
4 |
1 |
1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,41,44,45,48,49, 52,53,56,57,60,61,64,65 |
66 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52, 54,56,58,60,62,64,66 |
79 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79 |
106 |
8 |
2 |
2,8,10,16,18,24,26,32,34,40,42,48,50,56,58,64,66,72,74,80,82,88,90,96, 92,104,106 |
107 |
8 |
3 |
3,8,11,16,19,24,27,32,35,40,43,48,51,56,59,64,67,72,75,80,83,88,91,96, 99,104,107 |
132 |
8 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96, 100,104, 108,112,116,120,124,128,132 |
133 |
8 |
5 |
5,8,13,16,21,24,29,32,37,40,45,48,53,56,61,64,69,72,77,80,85,88,93,96, 101,104, 109,112,117,120,125,128,133 |
135 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79,80,87,88,95,96, 103,104, 111,112,119,120,127,128,135 |
160 |
16 |
16 |
16,32,48,64,80,96,112,128,144,160 |
216 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152,160,168, 176,184,192,200,208,216 |
217 |
16 |
9 |
9,16,25,32,41,48,57,64,73,80,89,96,105,112,121,128,137,144,153,160,169, 176,185,192,201,208,217 |
264 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,160,168, 176,184,192,200,208,216,224,232,240,248,256,264 |
270 |
16 |
14 |
14,16,30,32,46,44,62,64,78,80,94,96,110,112, 126,128,142,144,158,160, 174, 176,190,192, 206,208,222,224,238,240, 254,256,270 |
273 |
16 |
1 |
1,16,17,32,33,48,49,64,65,80,81,96,97,112,113,128,129,144,145,160, 161,176,171, 192,193, 208,209, 224,225,240,241,256,257,272,273 |
Table 7.1.1.4.1.4.3.2-3: Specific Parameter
Parameter |
Value |
Comments |
Condition |
PDSCH mappingType |
typeA |
||
starting symbol S |
0 0r 3 to avoid clash with PDCCH symbols |
||
number of consecutive symbols L |
3..14-S |
||
k0 |
0 or 1 (if S=0) |
||
number of layers (ʋ) |
1 |
||
mcs-Table |
qam256 |
||
xoh-PDSCH |
Not present |
Results in value 0(xoh0) |
|
dmrs-AdditionalPosition |
pos0 |
Results in 1 DMRS symbol per two carrier ()for Duration in symbols >=3 (TS 38.211 [24], table 7.4.1.1.2-3) |
|
resourceAllocation |
dynamicSwitch |
pc_dynamicSwitchRA_Type0_1_PDSCH |
|
resourceAllocationType0 |
NOT pc_dynamicSwitchRA_Type0_1_PDSCH AND Steps 1-5 |
||
resourceAllocationType1 |
NOT pc_dynamicSwitchRA_Type0_1_PDSCH AND Steps 6-10 |
||
maxNrofCodeWordsScheduledByDCI |
n2 |
both codewords enabled |
|
rbg-Size |
Not present |
configuration 1 applicable |
|
NstartBWP |
0 |
Table 7.1.1.4.1.4.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of as per Table 7.1.1.4.1.4.3.2-2A in BWP, time domain resource as per table 7.1.1.4.1.0-1 and from 0 to 27. NOTE: Skip the execution of steps for which the TBS size results in coding rate exceeding 0.95. |
– |
– |
– |
– |
1 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. The SS uses the same and TBS for both transport blocks: = = TBS 1= TBS 2= TBS |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS1 + TBS2 is less than or equal to UE capability "Maximum number of DL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.1.4.3.2-1 and larger than or equal to 192 bits as specified in Table 7.1.1.4.1.4.3.2-2. |
– |
– |
– |
– |
2 |
SS creates one or more PDCP SDUs for transport block 1 and 2 depending on TBS1, and TBS2 in accordance with Table 7.1.1.4.1.4.3.2-2. |
– |
– |
– |
– |
3 |
SS transmits the PDCP SDUs concatenated into a MAC PDU and indicates on PDCCH DCI Format 1_1 resource allocation 0 and values of S, L, , and nPRB. |
<– |
Transport block 1: MAC PDU Transport block 2: MAC PDU DCI: (DCI Format 1_1, S, L,, and nPRB.) |
– |
– |
4 |
At the reception of scheduling request the SS transmits UL Grant for transmitting loop back PDCP SDUs. |
<– |
(UL Grant) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3? |
–> |
(NxPDCP SDUs) |
1 |
P |
– |
EXCEPTION : Steps 5Aa1 to 5Aa2 are executed if NOT pc_dynamicSwitchRA_Type0_1_PDSCH |
– |
– |
– |
– |
5Aa1 |
The SS transmits a NR RRCReconfiguration message including PDSCH-Config with IE resourceAllocation set to resourceAllocationType1 (Note 1) |
<– |
RRCReconfiguration |
– |
– |
5Aa2 |
The UE transmit a NR RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
– |
EXCEPTION: Steps 6 to 10 are repeated for allowed values of 1 to in BWP, time domain resource length L 3 to 14-S and from 0 to 27. |
– |
– |
– |
– |
6 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. The SS uses the same and TBS for both transport blocks: = = TBS 1= TBS 2= TBS |
– |
– |
– |
– |
– |
EXCEPTION: Steps 7 to 10 are performed if TBS1 + TBS2 is less than or equal to UE capability "Maximum number of DL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.1.4.3.2-1 and larger than or equal to 192 bits as specified in Table 7.1.1.4.1.4.3.2-2 |
– |
– |
– |
– |
7 |
SS creates one or more PDCP SDUs for transport block 1 and 2 depending on TBS1, and TBS2 in accordance with Table 7.1.1.4.1.4.3.2-2. |
– |
– |
– |
– |
8 |
SS transmits the PDCP SDUs concatenated into a MAC PDU and indicates on PDCCH DCI Format 1_1 resource allocation 1 and values of S, L, , and nPRB. |
<– |
Transport block 1: MAC PDU Transport block 2: MAC PDU DCI: (DCI Format 1_1, S, L,, and nPRB.) |
– |
– |
9 |
At the reception of scheduling request the SS transmits UL Grant for transmitting loop back PDCP SDUs. |
<– |
(UL Grant) |
– |
– |
10 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3? |
–> |
(NxPDCP SDUs) |
2 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.4.1.4.3.3 Specific message contents
None.
7.1.1.4.1.5 DL-SCH transport block size selection / DCI format 1_2
7.1.1.4.1.5.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE on PDCCH receives DCI format 1_2 indicating a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE decodes the received transport block of size correspondent as per Modulation Coding scheme, time domain resource allocation and PRB’s and forwards it to higher layers }
}
7.1.1.4.1.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.2.3, TS 38.214 clause 5.1.2.1, 5.1.2.2, 5.1.2.2.1, 5.1.2.2.2, 5.1.3, 5.1.3.1 and 5.1.3.2. Unless otherwise stated these are Rel-16 requirements.
[TS 38.212, clause 7.3.1.2.3]
DCI format 1_2 is used for the scheduling of PDSCH in one cell.
The following information is transmitted by means of the DCI format 1_2 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI:
– Identifier for DCI formats – 1 bits
– The value of this bit field is always set to 1, indicating a DL DCI format.
– Carrier indicator – 0, 1, 2 or 3 bits determined by higher layer parameter carrierIndicatorSizeDCI-1-2, as defined in Clause 10.1 of [5, TS38.213].
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of DL BWPs configured by higher layers, excluding the initial DL bandwidth part. The bitwidth for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the ascending order of the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
– Frequency domain resource assignment – number of bits determined by the following:
– bits if only resource allocation type 0 is configured, where is defined in Clause 5.1.2.2.1 of [6, TS 38.214];
– bits if only resource allocation type 1 is configured, or bits if resourceAllocationDCI-1-2-r16 is configured as ‘dynamicSwitch’, where , is the size of the active DL bandwidth part, is defined as in clause 4.4.4.4 of [4, TS 38.211] and is determined by higher layer parameter resourceAllocationType1GranularityDCI-1-2. If the higher layer parameter resourceAllocationType1GranularityDCI-1-2 is not configured, is equal to 1.
– If resourceAllocationDCI-1-2-r16 is configured as ‘dynamicSwitch’, the MSB bit is used to indicate resource allocation type 0 or resource allocation type 1, where the bit value of 0 indicates resource allocation type 0 and the bit value of 1 indicates resource allocation type 1.
– For resource allocation type 0, the LSBs provide the resource allocation as defined in Clause 5.1.2.2.1 of [6, TS 38.214].
– For resource allocation type 1, the LSBs provide the resource allocation as defined in Clause 5.1.2.2.2 of [6, TS 38.214]
If "Bandwidth part indicator" field indicates a bandwidth part other than the active bandwidth part and if resourceAllocationDCI-1-2-r16 is configured as ‘dynamicSwitch’ for the indicated bandwidth part, the UE assumes resource allocation type 0 for the indicated bandwidth part if the bitwidth of the "Frequency domain resource assignment" field of the active bandwidth part is smaller than the bitwidth of the "Frequency domain resource assignment" field of the indicated bandwidth part.
– Time domain resource assignment – 0, 1, 2, 3, or 4 bits as defined in Clause 5.1.2.1 of [6, TS 38.214]. The bitwidth for this field is determined as bits, where I is the number of entries in the higher layer parameter pdsch-TimeDomainAllocationListDCI-1-2 if the higher layer parameter is configured, or I is the number of entries in the higher layer parameter pdsch-TimeDomainAllocationList if the higher layer parameter pdsch-TimeDomainAllocationList is configured when the higher layer parameter pdsch-TimeDomainAllocationListDCI-1-2 is not configured; otherwise I is the number of entries in the default table.
– VRB-to-PRB mapping – 0 or 1 bit:
– 0 bit if the higher layer parameter vrb-ToPRB-InterleaverDCI-1-2 is not configured;
– 1 bit according to Table 7.3.1.2.2-5 otherwise, only applicable to resource allocation type 1, as defined in Clause 7.3.1.6 of [4, TS 38.211].
– PRB bundling size indicator – 0 bit if the higher layer parameter prb-BundlingTypeDCI-1-2 is not configured or is set to ‘static’, or 1 bit if the higher layer parameter prb-BundlingTypeDCI-1-2 is set to ‘dynamic’ according to Clause 5.1.2.3 of [6, TS 38.214].
– Rate matching indicator – 0, 1, or 2 bits according to higher layer parameters rateMatchPatternGroup1DCI-1-2 and rateMatchPatternGroup2DCI-1-2, where the MSB is used to indicate rateMatchPatternGroup1DCI-1-2 and the LSB is used to indicate rateMatchPatternGroup2DCI-1-2 when there are two groups.
– ZP CSI-RS trigger – 0, 1, or 2 bits as defined in Clause 5.1.4.2 of [6, TS 38.214]. The bitwidth for this field is determined as bits, where is the number of aperiodic ZP CSI-RS resource sets configured by higher layer parameter aperiodicZP-CSI-RS-ResourceSetsToAddModListDCI-1-2.
– Modulation and coding scheme – 5 bits as defined in Clause 5.1.3.1 of [6, TS 38.214]
– New data indicator – 1 bit
– Redundancy version – 0, 1 or 2 bits determined by higher layer parameter numberOfBitsForRV-DCI-1-2
– If 0 bit is configured, rvid to be applied is 0;
– 1 bit according to Table 7.3.1.2.3-1;
– 2 bits according to Table 7.3.1.1.1-2.
– HARQ process number – 0, 1, 2, 3 or 4 bits determined by higher layer parameter harq-ProcessNumberSizeDCI-1-2
– Downlink assignment index – 0, 1, 2 or 4 bits
– 0 bit if the higher layer parameter downlinkAssignmentIndexDCI-1-2 is not configured;
– 1, 2 or 4 bits determined by higher layer parameter downlinkAssignmentIndexDCI-1-2 otherwise,
– 4 bits if more than one serving cell are configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, where the 2 MSB bits are the counter DAI and the 2 LSB bits are the total DAI
– 4 bits if one serving cell are configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, and the UE is not provided coresetPoolIndex or is provided coresetPoolIndex with value 0 for one or more first CORESETs and is provided coresetPoolIndex with value 1 for one or more second CORESETs, and is provided ackNackFeedbackMode = joint, where the 2 MSB bits are the counter DAI and the 2 LSB bits are the total DAI.
– 1 or 2 bits if only one serving cell is configured in the DL and the higher layer parameter pdsch-HARQ-ACK-Codebook=dynamic, when the UE is not configured with coresetPoolIndex or the value of coresetPoolIndex is the same for all CORESETs if coresetPoolIndex is provided or the UE is not configured with ackNackFeedbackMode = joint, where the 1 bit or 2 bits are the counter DAI.
If higher layer parameter priorityIndicatorDCI-1-2 is configured, if the bit width of the Downlink assignment index in DCI format 1_2 for one HARQ-ACK codebook is not equal to that of the Downlink assignment index in DCI format 1_2 for the other HARQ-ACK codebook, a number of most significant bits with value set to ‘0’ are inserted to smaller Downlink assignment index until the bit width of the Downlink assignment index in DCI format 1_2 for the two HARQ-ACK codebooks are the same.
– TPC command for scheduled PUCCH – 2 bits as defined in Clause 7.2.1 of [5, TS 38.213]
– PUCCH resource indicator – 0 or 1 or 2 or 3 bits determined by higher layer parameter numberOfBitsForPUCCH-ResourceIndicatorDCI-1-2
– PDSCH-to-HARQ_feedback timing indicator – 0, 1, 2, or 3 bits as defined in Clause 9.2.3 of [5, TS 38.213]. The bitwidth for this field is determined as bits, where I is the number of entries in the higher layer parameter DL-DataToUL-ACK-DCI-1-2.
If higher layer parameter priorityIndicatorDCI-1-2 is configured, if the bit width of the PDSCH-to-HARQ_feedback timing indicator in DCI format 1_2 for one HARQ-ACK codebook is not equal to that of the PDSCH-to-HARQ_feedback timing indicator in DCI format 1_2 for the other HARQ-ACK codebook, a number of most significant bits with value set to ‘0’ are inserted to smaller PDSCH-to-HARQ_feedback timing indicator until the bit width of the PDSCH-to-HARQ_feedback timing indicator in DCI format 1_2 for the two HARQ-ACK codebooks are the same.
– Antenna port(s) – 0, 4, 5, or 6 bits
– 0 bit if higher layer parameter antennaPortsFieldPresenceDCI-1-2 is not configured;
– Otherwise 4, 5 or 6 bits as defined by Tables 7.3.1.2.2-1/2/3/4, where the number of CDM groups without data of values 1, 2, and 3 refers to CDM groups {0}, {0,1}, and {0, 1,2} respectively. The antenna ports shall be determined according to the ordering of DMRS port(s) given by Tables 7.3.1.2.2-1/2/3/4. If a UE is configured with both dmrs-DownlinkForPDSCH-MappingTypeA-DCI-1-2 and dmrs-DownlinkForPDSCH-MappingTypeB-DCI-1-2 and is configured with higher layer parameter antennaPortsFieldPresenceDCI-1-2, the bitwidth of this field equals, where is the "Antenna ports" bitwidth derived according to dmrs-DownlinkForPDSCH-MappingTypeA-DCI-1-2 and is the "Antenna ports" bitwidth derived according to dmrs-DownlinkForPDSCH-MappingTypeB-DCI-1-2. A number of zeros are padded in the MSB of this field, if the mapping type of the PDSCH corresponds to the smaller value of and .
If a UE is not configured with higher layer parameter antennaPortsFieldPresenceDCI-1-2, antenna port(s) are defined assuming bit field index value 0 in Tables 7.3.1.2.2-1/2/3/4.
– Transmission configuration indication – 0 bit if higher layer parameter tci-PresentDCI-1-2 is not configured; otherwise 1 or 2 or 3 bits determined by higher layer parameter tci-PresentDCI-1-2 as defined in Clause 5.1.5 of [6, TS38.214].
If "Bandwidth part indicator" field indicates a bandwidth part other than the active bandwidth part,
– if the higher layer parameter tci-PresentDCI-1-2 is not configured for the CORESET used for the PDCCH carrying the DCI format 1_2,
– the UE assumes tci-PresentDCI-1-2 is not configured for all CORESETs in the indicated bandwidth part;
– otherwise,
– the UE assumes tci-PresentDCI-1-2 is configured for all CORESETs in the indicated bandwidth part with the same value configured for the CORESET used for the PDCCH carrying the DCI format 1_2.
– SRS request – 0, 1, 2 or 3 bits
– 0 bit if the higher layer parameter srs-RequestDCI-1-2 is not configured;
– 1 bit as defined by Table 7.3.1.1.3-1 if the higher layer parameter srs-RequestDCI-1-2 = 1 and for UEs not configured with supplementaryUplink in ServingCellConfig in the cell;
– 2 bits if the higher layer parameter srs-RequestDCI-1-2 = 1 and for UEs configured with supplementaryUplink in ServingCellConfig in the cell, where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second bit is defined by Table 7.3.1.1.3-1;
– 2 bits as defined by Table 7.3.1.1.2-24 if the higher layer parameter srs-RequestDCI-1-2 = 2 and for UEs not configured with supplementaryUplink in ServingCellConfig in the cell;
– 3 bits if the higher layer parameter srs-RequestDCI-1-2 = 2 and for UEs configured with supplementaryUplink in ServingCellConfig in the cell, where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second and third bits are defined by Table 7.3.1.1.2-24;
– DMRS sequence initialization – 0 or 1 bit
– 0 bit if the higher layer parameter dmrs-SequenceInitializationDCI-1-2 is not configured;
– 1 bit otherwise.
– Priority indicator – 0 bit if higher layer parameter priorityIndicatorDCI-1-2 is not configured; otherwise 1 bit as defined in Clause 9 in [5, TS 38.213].
If DCI formats 1_2 are monitored in multiple search spaces associated with multiple CORESETs in a BWP for scheduling the same serving cell, zeros shall be appended until the payload size of the DCI formats 1_2 monitored in the multiple search spaces equal to the maximum payload size of the DCI format 1_2 monitored in the multiple search spaces.
Table 7.3.1.2.3-1: Redundancy version
Value of the Redundancy version field |
Value of to be applied |
0 |
0 |
1 |
3 |
[TS 38.214, clause 5.1.2.1]
When the UE is scheduled to receive PDSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocation table. The determination of the used resource allocation table is defined in Clause 5.1.2.1.1. The indexed row defines the slot offset K0, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PDSCH mapping type to be assumed in the PDSCH reception.
Given the parameter values of the indexed row:
– The slot allocated for the PDSCH is Ks, where , if UE is configured with ca-SlotOffset for at least one of the scheduled and scheduling cell, and Ks = , otherwise, and where n is the slot with the scheduling DCI, and K0 is based on the numerology of PDSCH, and and are the subcarrier spacing configurations for PDSCH and PDCCH, respectively, and
– and are the and the, respectively, which are determined by higher-layer configured ca-SlotOffset, for the cell receiving the PDCCH respectively, and are the and the, respectively, which are determined by higher-layer configured ca-SlotOffset for the cell receiving the PDSCH, as defined in clause 4.5 of [4, TS 38.211].
– The reference point S0 for starting symbol S is defined as:
– if configured with referenceOfSLIVDCI-1-2, and when receiving PDSCH scheduled by DCI format 1_2 with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI with K0=0, and PDSCH mapping Type B, the starting symbol S is relative to the starting symbol S0 of the PDCCH monitoring occasion where DCI format 1_2 is detected;
– otherwise, the starting symbol S is relative to the start of the slot using S0=0.
– The number of consecutive symbols L counting from the starting symbol S allocated for the PDSCH are determined from the start and length indicator SLIV:
if then
else
where, and
– the PDSCH mapping type is set to Type A or Type B as defined in Clause 7.4.1.1.2 of [4, TS 38.211].
The UE shall consider the S and L combinations defined in table 5.1.2.1-1 satisfying for normal cyclic prefix and for extended cyclic prefix as valid PDSCH allocations:
Table 5.1.2.1-1: Valid S and L combinations
PDSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
{0,1,2,3} (Note 1) |
{3,…,14} |
{3,…,14} |
{0,1,2,3} (Note 1) |
{3,…,12} |
{3,…,12} |
Type B |
{0,…,12} |
{2,…,13} |
{2,…,14} |
{0,…,10} |
{2,4,6} |
{2,…,12} |
Note 1: S = 3 is applicable only if dmrs-TypeA-Position = 3 |
[38.214 clause 5.1.2.2]
Two downlink resource allocation schemes, type 0 and type 1, are supported. The UE shall assume that when the scheduling grant is received with DCI format 1_0, then downlink resource allocation type 1 is used.
If the scheduling DCI is configured to indicate the downlink resource allocation type as part of the ‘Frequency domain resource assignment’ field by setting a higher layer parameter resourceAllocation in PDSCH-Config to ‘dynamicSwitch’, for DCI format 1_1 or setting a higher layer parameter resourceAllocationDCI-1-2 in PDSCH-Config to ‘dynamicSwitch’ for DCI format 1_2, the UE shall use downlink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the downlink frequency resource allocation type as defined by the higher layer parameter resourceAllocation for DCI format 1_1 or by the higher layer parameter resourceAllocationDCI-1-2 for DCI format 1_2.
[38.214 clause 5.1.2.2.1]
In downlink resource allocation of type 0, the resource block assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE where a RBG is a set of consecutive virtual resource blocks defined by higher layer parameter rbg-Size configured by PDSCH-Config and the size of the bandwidth part as defined in Table 5.1.2.2.1-1.
Table 5.1.2.2.1-1: Nominal RBG size P
Bandwidth Part Size |
Configuration 1 |
Configuration 2 |
1 – 36 |
2 |
4 |
37 – 72 |
4 |
8 |
73 – 144 |
8 |
16 |
145 – 275 |
16 |
16 |
[38.214 clause 5.1.2.2.2]
When the scheduling grant is received with DCI format 1_2, a downlink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting resource block group RBGstart=0, 1, …, NRBG-1 and a length in terms of virtually contiguously allocated resource block groups LRBGs=1, …, NRBG, where the resource block groups are defined as in 5.1.2.2.1 with P defined by resourceAllocationType1GranularityDCI-1-2 if the UE is configured with higher layer parameter resourceAllocationType1GranularityDCI-1-2, and P=1 otherwise. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed .
[TS 38.214, clause 5.1.3]
To determine the modulation order, target code rate, and transport block size(s) in the physical downlink shared channel, the UE shall first
– read the 5-bit modulation and coding scheme field (IMCS) in the DCI to determine the modulation order (Qm) and target code rate (R) based on the procedure defined in Subclause 5.1.3.1, and
– read redundancy version field (rv) in the DCI to determine the redundancy version.
and second
– the UE shall use the number of layers (ʋ), the total number of allocated PRBs before rate matching (nPRB) to determine to the transport block size based on the procedure defined in Subclause 5.1.3.2.
The UE may skip decoding a transport block in an initial transmission if the effective channel code rate is higher than 0.95, where the effective channel code rate is defined as the number of downlink information bits (including CRC bits) divided by the number of physical channel bits on PDSCH. If the UE skips decoding, the physical layer indicates to higher layer that the transport block is not successfully decoded.
[TS 38.214, clause 5.1.3.1]
For the PDSCH scheduled by a PDCCH with DCI format 1_0, format 1_1 or format 1_2 with CRC scrambled by C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI, SI-RNTI, RA-RNTI, MSGB-RNTI, or P-RNTI, or for the PDSCH scheduled without corresponding PDCCH transmissions using the higher-layer-provided PDSCH configuration SPS-Config,
if the higher layer parameter mcs-TableDCI-1-2 given by PDSCH-Config is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with DCI format 1_2 with CRC scrambled by C-RNTI
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the UE is not configured with MCS-C-RNTI, the higher layer parameter mcs-TableDCI-1-2 given by PDSCH-Config is set to ‘qam64LowSE’, and the PDSCH is scheduled by a PDCCH with DCI format 1_2 scrambled by C-RNTI
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
…
Table 5.1.3.1-3: MCS index table 3 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
30 |
0.0586 |
1 |
2 |
40 |
0.0781 |
2 |
2 |
50 |
0.0977 |
3 |
2 |
64 |
0.1250 |
4 |
2 |
78 |
0.1523 |
5 |
2 |
99 |
0.1934 |
6 |
2 |
120 |
0.2344 |
7 |
2 |
157 |
0.3066 |
8 |
2 |
193 |
0.3770 |
9 |
2 |
251 |
0.4902 |
10 |
2 |
308 |
0.6016 |
11 |
2 |
379 |
0.7402 |
12 |
2 |
449 |
0.8770 |
13 |
2 |
526 |
1.0273 |
14 |
2 |
602 |
1.1758 |
15 |
4 |
340 |
1.3281 |
16 |
4 |
378 |
1.4766 |
17 |
4 |
434 |
1.6953 |
18 |
4 |
490 |
1.9141 |
19 |
4 |
553 |
2.1602 |
20 |
4 |
616 |
2.4063 |
21 |
6 |
438 |
2.5664 |
22 |
6 |
466 |
2.7305 |
23 |
6 |
517 |
3.0293 |
24 |
6 |
567 |
3.3223 |
25 |
6 |
616 |
3.6094 |
26 |
6 |
666 |
3.9023 |
27 |
6 |
719 |
4.2129 |
28 |
6 |
772 |
4.5234 |
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 5.1.3.2]
In case the higher layer parameter maxNrofCodeWordsScheduledByDCI indicates that two codeword transmission is enabled, then one of the two transport blocks is disabled by DCI format 1_1 if IMCS = 26 and if rvid = 1 for the corresponding transport block. If both transport blocks are enabled, transport block 1 and 2 are mapped to codeword 0 and 1 respectively. If only one transport block is enabled, then the enabled transport block is always mapped to the first codeword.
For the PDSCH assigned by a PDCCH with DCI format 1_0, format 1_1 or format 1_2 with CRC scrambled by C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI, or SI-RNTI, if Table 5.1.3.1-2 is used and , or a table other than Table 5.1.3.1-2 is used and , the UE shall, except if the transport block is disabled in DCI format 1_1, first determine the TBS as specified below:
1) The UE shall first determine the number of REs (NRE) within the slot.
– A UE first determines the number of REs allocated for PDSCH within a PRB () by , where is the number of subcarriers in a physical resource block, is the number of symbols of the PDSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 1_1 or format 1_2 or as described for format 1_0 in Clause 5.1.6.2, and is the overhead configured by higher layer parameter xOverhead in PDSCH-ServingCellConfig. If the xOverhead in PDSCH-ServingCellconfig is not configured (a value from 6, 12, or 18), the is set to 0. If the PDSCH is scheduled by PDCCH with a CRC scrambled by SI-RNTI, RA-RNTI, MSGB-RNTI or P-RNTI, is assumed to be 0.
– A UE determines the total number of REs allocated for PDSCH () by , where nPRB is the total number of allocated PRBs for the UE.
2) Unquantized intermediate variable (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-1 find the closest TBS that is not less than .
Table 5.1.3.2-1: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.1.5.3 Test description
7.1.1.4.1.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value) is applied in NR Serving cell configuration.
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.1.5.3.2 Test procedure sequence
Table 7.1.1.4.1.5.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.1.5.3.2-2: Number of downlink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
TBS> 144920 |
13 |
8*FLOOR((TBS – 992)/104) |
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.1.5.3.2-2A: Void
Table 7.1.1.4.1.5.3.2-3: Specific Parameters
Parameter |
Value |
Comment |
resourceAllocationType1GranularityDCI-1-2-r16 |
Not Present |
granularity ‘P’ is 1 PRB |
mcs-TableDCI-1-2-r16 |
Not present |
qam64 per default |
Table 7.1.1.4.1.5.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: EXCEPTION: Steps 1 to 5 are repeated for allowed values of in BWP, time domain resource as per table 7.1.1.4.5.0-1 and from 0 to 28. NOTE: Skip the execution of steps for which the TBS size results in coding rate exceeding 0.95. |
– |
– |
– |
– |
1 |
The SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of DL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.1.5.3.2-1 and larger than or equal to 132 bits as specified in Table 7.1.1.4.1.5.3.2-2 |
– |
– |
– |
– |
2 |
The SS creates one or more PDCP SDUs, depending on TBS, in accordance with Table 7.1.1.4.1.5.3.2-2. |
– |
– |
– |
– |
3 |
The SS transmits the PDCP SDUs concatenated into a MAC PDU and indicates on PDCCH DCI Format 1_2 and values of S, L,and nPRB. |
<– |
MAC PDU (NxPDCP SDUs) DCI: (DCI Format 1_2, S, L,and nPRB.) |
– |
– |
4 |
At the reception of scheduling request the SS transmits UL Grant for transmitting loop back PDCP SDUs. |
<– |
(UL Grant) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3? |
–> |
(NxPDCP SDUs) |
1 |
P |
7.1.1.4.1.5.3.3 Specific message contents
Table 7.1.1.4.1.5.3.3-1: PDSCH-Config
Derivation Path: TS 38.508-1 [4], table 4.6.3-100 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDSCH-Config ::= SEQUENCE { |
|||
dmrs-DownlinkForPDSCH-MappingTypeA-DCI-1-2-r16 CHOICE { |
|||
setup |
DMRS-DownlinkConfig |
||
} |
|||
harq-ProcessNumberSizeDCI-1-2-r16 |
3 |
nrofHARQ-ProcessesForPDSCH is 8 |
|
numberOfBitsForRV-DCI-1-2-r16 |
2 |
||
prb-BundlingTypeDCI-1-2-r16 |
|||
staticBundling SEQUENCE { |
|||
bundleSize |
wideband |
||
} |
|||
} |
|||
resourceAllocationDCI-1-2-r16 |
resourceAllocationType1 |
||
} |
Table 7.1.1.4.1.5.3.3-2: PhysicalCellGroupConfig
Derivation Path: TS 38.508-1 [4], Table 4.6.3-106 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PhysicalCellGroupConfig ::= SEQUENCE { |
|||
downlinkAssignmentIndexDCI-1-2-r16 |
2 |
pdsch-HARQ-ACK-Codebook=dynamic ackNackFeedbackMode = Not present |
|
} |
Table 7.1.1.4.1.5.3.3-3: PUCCH-Config
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-Config ::= SEQUENCE { |
|||
numberOfBitsForPUCCH-ResourceIndicatorDCI-1-2-r16 |
3 |
||
} |
7.1.1.4.2 UL-SCH Transport Block Size Selection
7.1.1.4.2.0 Common parameters for UL-SCH Transport Block Size Selection
Table 7.1.1.4.2.0-1: PUSCH-TimeDomainResourceAllocationList
Derivation Path: TS 38.508-1 [4], table 4.6.3-122 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-TimeDomainResourceAllocationList ::= SEQUENCE (SIZE(1..maxNrofUL-Allocations)) OF PUSCH-TimeDomainResourceAllocation { |
2 entry |
||
PUSCH-TimeDomainResourceAllocation[1] SEQUENCE { |
entry 1 |
FR1 |
|
k2 |
2 |
FR1 |
|
4 |
FR2 |
||
mappingType |
typeB |
||
startSymbolAndLength |
52 |
Start symbol(S)=10, Length(L)=4 |
FR1 |
startSymbolAndLength |
42 |
Start symbol(S)=0, Length(L)=4 |
FR2 |
} |
|||
PUSCH-TimeDomainResourceAllocation[2] SEQUENCE { |
entry 2 |
FR1 |
|
k2 |
2 |
FR1 |
|
4 |
FR2 |
||
mappingType |
typeB |
||
startSymbolAndLength |
27 |
Start symbol(S)=0, Length(L)=14 |
|
} |
|||
} |
Table 7.1.1.4.2.0-2: PUSCH-Config
Derivation Path: TS 38.508-1 [4], Table 4.6.3-118 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-Config ::= SEQUENCE { |
|||
dmrs-UplinkForPUSCH-MappingTypeB CHOICE { |
|||
setup |
DMRS-UplinkConfig |
See Table 7.1.1.4.2.0-3 |
|
} |
|||
} |
Table 7.1.1.4.2.0-3: DMRS-UplinkConfig
Derivation Path: TS 38.508-1 [4], Table 4.6.3-51 |
Table 7.1.1.4.2.0-4: SchedulingRequestResourceConfig
Derivation Path: TS 38.508 [4], Table 4.6.3-157 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequestResourceConfig ::= SEQUENCE { |
|||
schedulingRequestResourceId |
SchedulingRequestResourceId |
||
schedulingRequestID |
SchedulingRequestId |
||
periodicityAndOffset CHOICE { |
|||
sl40 |
9 |
With SCS = kHz15 results in repetition every 40 ms |
SCS15 |
sl80 |
9 |
With SCS = kHz30 results in repetition every 40 ms |
SCS30 |
sl320 |
9 |
With SCS = kHz120 results in repetition every 40 ms |
SCS120 |
} |
|||
resource |
6 |
ID of the PUCCH resource as configured by PUCCH-Config (Table 4.6.3-84) |
|
} |
Table 7.1.1.4.2.0-5: PDSCH-TimeDomainResourceAllocationList
Derivation Path: TS 38.508-1 [4], Table 4.6.3-103 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDSCH-TimeDomainResourceAllocationList ::= SEQUENCE(SIZE(1..maxNrofDL-Allocations)) OF SEQUENCE(SIZE(1..maxNrofDL-Allocations)) OF PDSCH-TimeDomainResourceAllocation { |
2 entries |
||
PDSCH-TimeDomainResourceAllocation[1] SEQUENCE { |
entry 1 |
||
k0 |
Not present |
||
mappingType |
typeA |
||
startSymbolAndLength |
53 |
S=2, L=12 |
|
} |
|||
PDSCH-TimeDomainResourceAllocation[2] SEQUENCE { |
entry 2 |
||
k0 |
1 |
||
mappingType |
typeA |
||
startSymbolAndLength |
27 |
S=0, L=14 |
|
} |
|||
} |
7.1.1.4.2.1 UL-SCH Transport Block Size selection / DCI format 0_0 / Transform precoding disabled
7.1.1.4.2.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE has pending data for transmission and receives on PDCCH DCI format 0_0 indicating a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and modulation and coding }
then { UE transmits MAC PDU on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
7.1.1.4.2.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.1.1, TS 38.214 clause 6.1.2.1, 6.1.2.2, 6.1.2.2.2, 6.1.4.1, 5.1.3.1, 6.1.4.2 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.1.1]
DCI format 0_0 is used for the scheduling of PUSCH in one cell.
The following information is transmitted by means of the DCI format 0_0 with CRC scrambled by C-RNTI or CS-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Frequency domain resource assignment – bits where
– is the size of the active UL bandwidth part in case DCI format 0_0 is monitored in the UE specific search space and satisfying
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
– otherwise, is the size of the initial UL bandwidth part.
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Subclause 6.3 of [6, TS 38.214], where if the higher layer parameter frequencyHoppingOffsetLists contains two offset values and if the higher layer parameter frequencyHoppingOffsetLists contains four offset values
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– For non-PUSCH hopping with resource allocation type 1:
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– Time domain resource assignment – 4 bits as defined in Subclause 6.1.2.1 of [6, TS 38.214]
– Frequency hopping flag – 1 bit.
– Modulation and coding scheme – 5 bits as defined in Subclause 6.1.3 of [6, TS 38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits
– TPC command for scheduled PUSCH – 2 bits as defined in Subclause 7.1.1 of [5, TS 38.213]
– Padding bits, if required.
– UL/SUL indicator – 1 bit for UEs configured with SUL in the cell as defined in Table 7.3.1.1.1-1 and the number of bits for DCI format 1_0 before padding is larger than the number of bits for DCI format 0_0 before padding; 0 bit otherwise. The UL/SUL indicator, if present, locates in the last bit position of DCI format 0_0, after the padding bit(s).
– If the UL/SUL indicator is present in DCI format 0_0 and the higher layer parameter pusch-Config is not configured on both UL and SUL the UE ignores the UL/SUL indicator field in DCI format 0_0, and the corresponding PUSCH scheduled by the DCI format 0_0 is for the UL or SUL for which high layer parameter pucch-Config is configured;
– If the UL/SUL indicator is not present in DCI format 0_0, the corresponding PUSCH scheduled by the DCI format 0_0 is for the UL or SUL for which high layer parameter pucch-Config is configured.
The following information is transmitted by means of the DCI format 0_0 with CRC scrambled by TC-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Frequency domain resource assignment –bits where
– is the size of the initial UL bandwidth part.
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Subclause 6.3 of [6, TS 38.214], where if and otherwise
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– For non-PUSCH hopping with resource allocation type 1:
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– Time domain resource assignment – 4 bits as defined in Subclause 6.1.2.1 of [6, TS 38.214]
– Frequency hopping flag – 1 bit.
– Modulation and coding scheme – 5 bits as defined in Subclause 6.1.3 of [6, TS 38.214], using Table 5.1.3.1-1
– New data indicator – 1 bit, reserved
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits, reserved
– TPC command for scheduled PUSCH – 2 bits as defined in Subclause 7.1.1 of [5, TS 38.213]
– Padding bits, if required.
– UL/SUL indicator – 1 bit if the cell has two ULs and the number of bits for DCI format 1_0 before padding is larger than the number of bits for DCI format 0_0 before padding; 0 bit otherwise. The UL/SUL indicator, if present, locates in the last bit position of DCI format 0_0, after the padding bit(s).
– If 1 bit, reserved, and the corresponding PUSCH is always on the same UL carrier as the previous transmission of the same TB
If DCI format 0_0 is monitored in common search space and if the number of information bits in the DCI format 0_0 prior to padding is less than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, zeros shall be appended to the DCI format 0_0 until the payload size equals that of the DCI format 1_0.
If DCI format 0_0 is monitored in common search space and if the number of information bits in the DCI format 0_0 prior to padding is larger than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, the bit width of the frequency domain resource allocation field in the DCI format 0_0 is reduced by truncating the first few most significant bits such that the size of DCI format 0_0 equals to the size of the DCI format 1_0.
If DCI format 0_0 is monitored in UE specific search space but does not satisfy at least one of the following
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
and if the number of information bits in the DCI format 0_0 prior to padding is less than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, zeros shall be appended to the DCI format 0_0 until the payload size equals that of the DCI format 1_0.
If DCI format 0_0 is monitored in UE specific search space but does not satisfy at least one of the following
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
and if the number of information bits in the DCI format 0_0 prior to padding is larger than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, the bit width of the frequency domain resource allocation field in the DCI format 0_0 is reduced by truncating the first few most significant bits such that the size of DCI format 0_0 equals to the size of the DCI format 1_0.
If DCI format 0_0 is monitored in UE specific search space and satisfies both of the following
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
and if the number of information bits in the DCI format 0_0 prior to padding is less than the payload size of the DCI format 1_0 monitored in UE specific search space for scheduling the same serving cell, zeros shall be appended to the DCI format 0_0 until the payload size equals that of the DCI format 1_0.
[TS 38.214, clause 6.1.2.1]
When the UE is scheduled to transmit a transport block and no CSI report, or the UE is scheduled to transmit a transport block and a CSI report on PUSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the used resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission.
When the UE is scheduled to transmit a PUSCH with no transport block and with a CSI report by a CSI request field on a DCI, the Time-domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the applied resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission and K2 is determined based on the corresponding list entries of the higher layer parameter reportSlotConfig in CSI-ReportConfig for the triggered CSI Reporting Settings. The ith codepoint of K2 s determined as where is the ith codepoint of .
– The slot where the UE shall transmit the PUSCH is determined by K2 as where n is the slot with the scheduling DCI, K2 is based on the numerology of PUSCH, and and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– The PUSCH mapping type is set to Type A or Type B as defined in Subclause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} |
{0,…,12} |
{1,…,12} |
{1,…,12} |
When the UE is configured with aggregationFactorUL > 1, the same symbol allocation is applied across the aggregationFactorUL consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the aggregationFactorUL consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version when aggregationFactorUL > 1
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
If the UE procedure for determining slot configuration, as defined in subclause 11.1 of [6, TS 38.213], determines symbols of a slot allocated for PUSCH as downlink symbols, the transmission on that slot is omitted for multi-slot PUSCH transmission.
[38.214 clause 6.1.2.2]
The UE shall determine the resource block assignment in frequency domain using the resource allocation field in the detected PDCCH DCI. Two uplink resource allocation schemes type 0 and type 1 are supported. Uplink resource allocation scheme type 0 is supported for PUSCH only when transform precoding is disabled. Uplink resource allocation scheme type 1 is supported for PUSCH for both cases when transform precoding is enabled or disabled.
If the scheduling DCI is configured to indicate the uplink resource allocation type as part of the Frequency domain resource assignment field by setting a higher layer parameter resourceAllocation in pusch-Config to ‘dynamicswitch’, the UE shall use uplink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the uplink frequency resource allocation type as defined by the higher layer parameter resourceAllocation.
The UE shall assume that when the scheduling PDCCH is received with DCI format 0_0, then uplink resource allocation type 1 is used.
If a bandwidth part indicator field is not configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s active bandwidth part. If a bandwidth part indicator field is configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s bandwidth part indicated by bandwidth part indicator field value in the DCI, except for the case when DCI format 0_0 is decoded in any PDCCH common search space in CORESET 0 in which case the initial bandwidth part shall be used. The UE shall upon detection of PDCCH intended for the UE determine first the uplink bandwidth part and then the resource allocation within the bandwidth part.
[38.214 clause 6.1.2.2.2]
In uplink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved virtual resource blocks within the active carrier bandwidth part of size PRBs except for the case when DCI format 0_0 is decoded in the Type0-PDCCH common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
An uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed.
[TS 38.214, clause 6.1.4.1]
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, or SP-CSI-RNTI, the transform precoding is enabled if transformPrecoder in PUSCH-Config is set to ‘enabled’, or if transformPrecoder in PUSCH-Config is not configured and msg3-transformPrecoding in rach-ConfigCommon is set to ‘enabled’; otherwise the transform precoding is disabled.
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by CS-RNTI, or the PUSCH with configured grant using CS-RNTI, the transform precoding is enabled if transformPrecoder in ConfiguredGrantConfig is set to ‘enabled’; otherwise the transform precoding is disabled.
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, TC-RNTI, or CS-RNTI, or SP-CSI-RNTI, or for a PUSCH with configured grant using CS-RNTI,
if transformPrecoder is disabled for this PUSCH transmission
– if mcs-Table in PUSCH-Config is set to ‘qam256’, and PUSCH is scheduled with C-RNTI or SP-CSI-RNTI, and PUSCH is assigned by DCI format 0_1,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is not configured with new-RNTI, mcs-Table in PUSCH-Config is set to ‘qam64LowSE’, the PUSCH is scheduled with C-RNTI, or SP-CSI-RNTI, and the PUSCH is assigned by a PDCCH in a UE-specific search space,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is configured with new-RNTI, and the PUSCH is scheduled with new-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-Table in ConfiguredGrantConfig is set to ‘qam256’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-Table in ConfiguredGrantConfig is set to ‘qam64LowSE’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– else
– the UE shall use IMCS and Table 5.1.3.1-1 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
[TS 38.214, clause 5.1.3.1]
Table 5.1.3.1-1: MCS index table 1 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
120 |
0.2344 |
1 |
2 |
157 |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
4 |
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
438 |
2.5664 |
18 |
6 |
466 |
2.7305 |
19 |
6 |
517 |
3.0293 |
20 |
6 |
567 |
3.3223 |
21 |
6 |
616 |
3.6094 |
22 |
6 |
666 |
3.9023 |
23 |
6 |
719 |
4.2129 |
24 |
6 |
772 |
4.5234 |
25 |
6 |
822 |
4.8164 |
26 |
6 |
873 |
5.1152 |
27 |
6 |
910 |
5.3320 |
28 |
6 |
948 |
5.5547 |
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 6.1.4.2]
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SP-CSI-RNTI.
if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is disabled and a table other than Table 5.1.3.1-2 is used, or
– and transform precoding is enabled and , the UE shall first determine the TBS as specified below:
The UE shall first determine the number of REs (NRE) within the slot:
– A UE first determines the number of REs allocated for PUSCH within a PRB by
– , where is the number of subcarriers in the frequency domain in a physical resource block, is the number of symbols of the PUSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 0_1 or as described for DCI format 0_0 in Subclause 6.2.2, and is the overhead configured by higher layer parameter xOverhead in PUSCH-ServingCellConfig. If the is not configured (a value from 0, 6, 12, or 18), the is assumed to be 0. For MSG3 transmission the is always set to 0.
– A UE determines the total number of REs allocated for PUSCH by where is the total number of allocated PRBs for the UE.
– Next, proceed with steps 2-5 as defined in Subclause 5.1.3.2
else if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is enabled,
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
else
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
[TS 38.214, clause 5.1.3.2]
2 Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.2.1.3 Test description
7.1.1.4.2.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value) and Short_DCI condition is applied in NR Serving cell configuration.
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest mandatory UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.2.1.3.2 Test procedure sequence
Table 7.1.1.4.2.1.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.2.1.3.2-2: Number of uplink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
|||
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
|||
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
|||
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
|||
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
|||
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
|||
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
|||
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
|||
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
|||
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
|||
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
|||
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
|||
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
|||
144921 ≤ TBS ≤ 156992 |
13 |
8*FLOOR((TBS – 992)/104) |
|||
156993 ≤ TBS ≤ 169064 |
14 |
8*FLOOR((TBS – 1064)/112) |
|||
169065 ≤ TBS ≤ 181136 |
15 |
8*FLOOR((TBS – 1136)/120) |
|||
181137 ≤ TBS ≤ 193208 |
16 |
8*FLOOR((TBS – 1208)/128) |
|||
193209 ≤ TBS ≤ 205280 |
17 |
8*FLOOR((TBS – 1280)/136) |
|||
205281 ≤ TBS ≤ 217352 |
18 |
8*FLOOR((TBS – 1352)/144) |
|||
217353 ≤ TBS ≤ 229424 |
19 |
8*FLOOR((TBS – 1424)/152) |
|||
TBS> 229424 |
20 |
8*FLOOR((TBS – 1496)/160) |
|||
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.2.1.3.2-3: Specific Parameters
Parameter |
Value |
Comment |
number of layers (ʋ) |
1 |
|
mcs-Table |
qam64 |
Table 7.1.1.4.2.1.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of 1 to in BWP, time domain resource as per Table 7.1.1.4.2.0-1 and from 0 to 28. |
– |
– |
– |
– |
1 |
The SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.1.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.1.3.2-2. Skip the execution of steps 2 to 5 for which the TBS size equal to 3824 or 3840. (Note 2) Skip the execution of steps for > 27 and < 5. (Note 1) |
– |
– |
– |
– |
2 |
The SS creates one or more PDCP SDUs, depending on TBS, in accordance with Table 7.1.1.4.2.1.3.2-2. |
– |
– |
– |
– |
3 |
The SS transmits all PDCP SDUs (NSDUs) as created in step 2 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
4 |
After the reception of 2 Scheduling Request, , SS transmits UL Grant DCI 0_0, and values of S, L,and nPRB. |
<– |
(UL Grant) (DCI Format 0_0, S, L,and nPRB.) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 4? |
–> |
MAC PDU (N x PDCP SDU) |
1 |
P |
Note 1: For > 27 and < 5, the combination results in higher coding rate and therefore leading to CRC errors in decoding UL data. Note 2: There is ambiguity of TBS calculation when 3824.0 < Ninfo < 3825.0 in clause 5.1.3.2 of TS 38.214 [15]. |
7.1.1.4.2.1.3.3 Specific message contents
None.
7.1.1.4.2.2 Void
7.1.1.4.2.3 UL-SCH transport block size selection / DCI format 0_1 / RA type 0/RA Type 1 / Transform precoding disabled
7.1.1.4.2.3.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE has pending data for transmission and receives DCI format 0_1 indicating resource allocation type 0 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE transmits MAC PDU’s on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE has pending data for transmission and receives DCI format 0_1 indicating resource allocation type 1 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE transmits MAC PDU’s on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
7.1.1.4.2.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.1.1, TS 38.214 clause 6.1.2.1, 6.1.2.2, 6.1.2.2.1, 6.1.2.2.2, 6.1.4.1, 5.1.3.1, 6.1.4.2 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.1.2]
DCI format 0_1 is used for the scheduling of PUSCH in one cell.
The following information is transmitted by means of the DCI format 0_1 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Carrier indicator – 0 or 3 bits, as defined in Subclause 10.1 of [5, TS38.213].
– UL/SUL indicator – 0 bit for UEs not configured with SUL in the cell or UEs configured with SUL in the cell but only PUCCH carrier in the cell is configured for PUSCH transmission; 1 bit for UEs configured with SUL in the cell as defined in Table 7.3.1.1.1-1.
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of UL BWPs configured by higher layers, excluding the initial UL bandwidth part. The bit width for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
– Frequency domain resource assignment – number of bits determined by the following, where is the size of the active UL bandwidth part:
– bits if only resource allocation type 0 is configured, where is defined in Subclause 6.1.2.2.1 of [6, TS 38.214],
– bits if only resource allocation type 1 is configured, or bits if both resource allocation type 0 and 1 are configured.
– If both resource allocation type 0 and 1 are configured, the MSB bit is used to indicate resource allocation type 0 or resource allocation type 1, where the bit value of 0 indicates resource allocation type 0 and the bit value of 1 indicates resource allocation type 1.
– For resource allocation type 0, the LSBs provide the resource allocation as defined in Subclause 6.1.2.2.1 of [6, TS 38.214].
– For resource allocation type 1, the LSBs provide the resource allocation as follows:
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Subclause 6.3 of [6, TS 38.214], where if the higher layer parameter frequencyHoppingOffsetLists contains two offset values and if the higher layer parameter frequencyHoppingOffsetLists contains four offset values
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
If "Bandwidth part indicator" field indicates a bandwidth part other than the active bandwidth part and if both resource allocation type 0 and 1 are configured for the indicated bandwidth part, the UE assumes resource allocation type 0 for the indicated bandwidth part if the bit width of the "Frequency domain resource assignment" field of the active bandwidth part is smaller than the bit width of the "Frequency domain resource assignment" field of the indicated bandwidth part.
– For non-PUSCH hopping with resource allocation type 1:
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– Time domain resource assignment – 0, 1, 2, 3, or 4 bits as defined in Subclause 6.1.2.1 of [6, TS38.214]. The bit width for this field is determined as bits, where I the number of entries in the higher layer parameter pusch-AllocationList.
– Frequency hopping flag – 0 or 1 bit:
– 0 bit if only resource allocation type 0 is configured or if the higher layer parameter frequencyHopping is not configured;
– 1 bit according to Table 7.3.1.1.2-34 otherwise, only applicable to resource allocation type 1, as defined in Subclause 6.3 of [6, TS 38.214].
– Modulation and coding scheme – 5 bits as defined in Subclause 6.1.4.1 of [6, TS 38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits
– 1st downlink assignment index – 1 or 2 bits:
– 1 bit for semi-static HARQ-ACK codebook;
– 2 bits for dynamic HARQ-ACK codebook.
– 2nd downlink assignment index – 0 or 2 bits:
– 2 bits for dynamic HARQ-ACK codebook with two HARQ-ACK sub-codebooks;
– 0 bit otherwise.
– TPC command for scheduled PUSCH – 2 bits as defined in Subclause 7.1.1 of [5, TS38.213]
– SRS resource indicator – or bits, where is the number of configured SRS resources in the SRS resource set associated with the higher layer parameter usage of value ‘codeBook‘ or ‘nonCodeBook‘, and is the maximum number of supported layers for the PUSCH.
– bits according to Tables 7.3.1.1.2-28/29/30/31 if the higher layer parameter txConfig = nonCodebook, where is the number of configured SRS resources in the SRS resource set associated with the higher layer parameter usage of value ‘nonCodeBook‘;
– bits according to Tables 7.3.1.1.2-32 if the higher layer parameter txConfig = codebook, where is the number of configured SRS resources in the SRS resource set associated with the higher layer parameter usage of value ‘codeBook‘.
– Precoding information and number of layers – number of bits determined by the following:
– 0 bits if the higher layer parameter txConfig = nonCodeBook;
– 0 bits for 1 antenna port and if the higher layer parameter txConfig = codebook;
– 4, 5, or 6 bits according to Table 7.3.1.1.2-2 for 4 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters transformPrecoder, maxRank, and codebookSubset;
– 2, 4, or 5 bits according to Table 7.3.1.1.2-3 for 4 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters transformPrecoder, maxRank, and codebookSubset;
– 2 or 4 bits according to Table7.3.1.1.2-4 for 2 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters maxRank and codebookSubset;
– 1 or 3 bits according to Table7.3.1.1.2-5 for 2 antenna ports, if txConfig = codebookmaxRank and codebookSubset, and according to the values of higher layer parameters.
– Antenna ports – number of bits determined by the following
– 2 bits as defined by Tables 7.3.1.1.2-6, if transformPrecoder=enabled, dmrs-Type=1, and maxLength=1;
– 4 bits as defined by Tables 7.3.1.1.2-7, if transformPrecoder=enabled, dmrs-Type=1, and maxLength=2;
– 3 bits as defined by Tables 7.3.1.1.2-8/9/10/11, if transformPrecoder=disabled, dmrs-Type=1, and maxLength=1, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 4 bits as defined by Tables 7.3.1.1.2-12/13/14/15, if transformPrecoder=disabled, dmrs-Type=1, and maxLength=2, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 4 bits as defined by Tables 7.3.1.1.2-16/17/18/19, if transformPrecoder=disabled, dmrs-Type=2, and maxLength=1, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 5 bits as defined by Tables 7.3.1.1.2-20/21/22/23, if transformPrecoder=disabled, dmrs-Type=2, and maxLength=2, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook.
where the number of CDM groups without data of values 1, 2, and 3 in Tables 7.3.1.1.2-6 to 7.3.1.1.2-23 refers to CDM groups {0}, {0,1}, and {0, 1,2} respectively.
If a UE is configured with both dmrs-UplinkForPUSCH-MappingTypeA and dmrs-UplinkForPUSCH-MappingTypeB, the bit width of this field equals , where is the “Antenna ports” bit width derived according to dmrs-UplinkForPUSCH-MappingTypeA and is the “Antenna ports” bit width derived according to dmrs-UplinkForPUSCH-MappingTypeB. A number of zeros are padded in the MSB of this field, if the mapping type of the PUSCH corresponds to the smaller value of and .
– SRS request – 2 bits as defined by Table 7.3.1.1.2-24 for UEs not configured with SUL in the cell; 3 bits for UEs configured SUL in the cell where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second and third bits are defined by Table 7.3.1.1.2-24. This bit field may also indicate the associated CSI-RS according to Subclause 6.1.1.2 of [6, TS 38.214].
– CSI request – 0, 1, 2, 3, 4, 5, or 6 bits determined by higher layer parameter reportTriggerSize.
– CBG transmission information (CBGTI) – 0, 2, 4, 6, or 8 bits determined by higher layer parameter maxCodeBlockGroupsPerTransportBlock for PUSCH.
– PTRS-DMRS association – number of bits determined as follows
– 0 bit if PTRS-UplinkConfig is not configured and transformPrecoder=disabled, or if transformPrecoder=enabled, or if maxRank=1;
– 2 bits otherwise, where Table 7.3.1.1.2-25 and 7.3.1.1.2-26 are used to indicate the association between PTRS port(s) and DMRS port(s) for transmission of one PT-RS port and two PT-RS ports respectively, and the DMRS ports are indicated by the Antenna ports field.
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and the “PTRS-DMRS association” field is present for the indicated bandwidth part but not present for the active bandwidth part, the UE assumes the “PTRS-DMRS association” field is not present for the indicated bandwidth part.betaOffsets = semiStatic
– beta_offset indicator – 0 if the higher layer parameter ; otherwise 2 bits as defined by Table 9.3-3 in [5, TS 38.213].
– DMRS sequence initialization – 0 if the higher layer parameter transformPrecoder=enabled; 1 bit if the higher layer parameter transformPrecoder=disabled and both scramblingID0 and scramblingID1 are configured in DMRS-UplinkConfig, for selection defined in Subclause 6.4.1.1.1.1 of [4, TS 38.211].
– UL-SCH indicator – 1 bit. A value of “1” indicates UL-SCH shall be transmitted on the PUSCH and a value of “0” indicates UL-SCH shall not be transmitted on the PUSCH.
For a UE configured with SUL in a cell, if PUSCH is configured to be transmitted on both the SUL and the non-SUL of the cell and if the number of information bits in format 0_1 for the SUL is not equal to the number of information bits in format 0_1 for the non-SUL, zeros shall be appended to smaller format 0_1 until the payload size equals that of the larger format 0_1.
Table 7.3.1.1.2-1: Bandwidth part indicator
Value of BWP indicator field |
Bandwidth part |
2 bits |
|
00 |
First bandwidth part configured by higher layers |
01 |
Second bandwidth part configured by higher layers |
10 |
Third bandwidth part configured by higher layers |
11 |
Fourth bandwidth part configured by higher layers |
Table 7.3.1.1.2-2: Precoding information and number of layers, for 4 antenna ports, if transformPrecoder=disabled and maxRank = 2 or 3 or 4
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset = partialAndNonCoherent |
Bit field mapped to index |
codebookSubset= nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
… |
… |
… |
… |
… |
… |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
4 |
2 layers: TPMI=0 |
4 |
2 layers: TPMI=0 |
4 |
2 layers: TPMI=0 |
… |
… |
… |
… |
… |
… |
9 |
2 layers: TPMI=5 |
9 |
2 layers: TPMI=5 |
9 |
2 layers: TPMI=5 |
10 |
3 layers: TPMI=0 |
10 |
3 layers: TPMI=0 |
10 |
3 layers: TPMI=0 |
11 |
4 layers: TPMI=0 |
11 |
4 layers: TPMI=0 |
11 |
4 layers: TPMI=0 |
12 |
1 layer: TPMI=4 |
12 |
1 layer: TPMI=4 |
12-15 |
reserved |
… |
… |
… |
… |
||
19 |
1 layer: TPMI=11 |
19 |
1 layer: TPMI=11 |
||
20 |
2 layers: TPMI=6 |
20 |
2 layers: TPMI=6 |
||
… |
… |
… |
… |
||
27 |
2 layers: TPMI=13 |
27 |
2 layers: TPMI=13 |
||
28 |
3 layers: TPMI=1 |
28 |
3 layers: TPMI=1 |
||
29 |
3 layers: TPMI=2 |
29 |
3 layers: TPMI=2 |
||
30 |
4 layers: TPMI=1 |
30 |
4 layers: TPMI=1 |
||
31 |
4 layers: TPMI=2 |
31 |
4 layers: TPMI=2 |
||
32 |
1 layers: TPMI=12 |
||||
… |
… |
||||
47 |
1 layers: TPMI=27 |
||||
48 |
2 layers: TPMI=14 |
||||
… |
… |
||||
55 |
2 layers: TPMI=21 |
||||
56 |
3 layers: TPMI=3 |
||||
… |
… |
||||
59 |
3 layers: TPMI=6 |
||||
60 |
4 layers: TPMI=3 |
||||
61 |
4 layers: TPMI=4 |
||||
62-63 |
reserved |
Table 7.3.1.1.2-3: Precoding information and number of layers for 4 antenna ports, if transformPrecoder= enabled, or if transformPrecoder=disabled and maxRank = 1
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset= partialAndNonCoherent |
Bit field mapped to index |
codebookSubset= nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
… |
… |
… |
… |
… |
… |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
4 |
1 layer: TPMI=4 |
4 |
1 layer: TPMI=4 |
||
… |
… |
… |
… |
||
11 |
1 layer: TPMI=11 |
11 |
1 layer: TPMI=11 |
||
12 |
1 layers: TPMI=12 |
12-15 |
reserved |
||
… |
… |
||||
27 |
1 layers: TPMI=27 |
||||
28-31 |
reserved |
Table 7.3.1.1.2-4: Precoding information and number of layers, for 2 antenna ports, if transformPrecoder=disabled and maxRank = 2
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset = nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
2 |
2 layers: TPMI=0 |
2 |
2 layers: TPMI=0 |
3 |
1 layer: TPMI=2 |
3 |
reserved |
4 |
1 layer: TPMI=3 |
||
5 |
1 layer: TPMI=4 |
||
6 |
1 layer: TPMI=5 |
||
7 |
2 layers: TPMI=1 |
||
8 |
2 layers: TPMI=2 |
||
9-15 |
reserved |
Table 7.3.1.1.2-5: Precoding information and number of layers, for 2 antenna ports, if transformPrecoder= enabled, or if transformPrecoder= disabled and maxRank = 1
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset = nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
2 |
1 layer: TPMI=2 |
||
3 |
1 layer: TPMI=3 |
||
4 |
1 layer: TPMI=4 |
||
5 |
1 layer: TPMI=5 |
||
6-7 |
reserved |
…
Table 7.3.1.1.2-33: VRB-to-PRB mapping
Bit field mapped to index |
VRB-to-PRB mapping |
0 |
Non-interleaved |
1 |
Interleaved |
[TS 38.214, clause 6.1.2.1]
When the UE is scheduled to transmit a transport block and no CSI report, or the UE is scheduled to transmit a transport block and a CSI report on PUSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the used resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission.
When the UE is scheduled to transmit a PUSCH with no transport block and with a CSI report by a CSI request field on a DCI, the Time-domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the applied resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission and K2 is determined based on the corresponding list entries of the higher layer parameter reportSlotConfig in CSI-ReportConfig for the triggered CSI Reporting Settings. The ith codepoint of K2 s determined as where is the ith codepoint of .
– The slot where the UE shall transmit the PUSCH is determined by K2 as where n is the slot with the scheduling DCI, K2 is based on the numerology of PUSCH, and and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– The PUSCH mapping type is set to Type A or Type B as defined in Subclause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} |
{0,…,12} |
{1,…,12} |
{1,…,12} |
When the UE is configured with aggregationFactorUL > 1, the same symbol allocation is applied across the aggregationFactorUL consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the aggregationFactorUL consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version when aggregationFactorUL > 1
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
If the UE procedure for determining slot configuration, as defined in subclause 11.1 of [6, TS 38.213], determines symbols of a slot allocated for PUSCH as downlink symbols, the transmission on that slot is omitted for multi-slot PUSCH transmission.
[38.214 clause 6.1.2.2]
The UE shall determine the resource block assignment in frequency domain using the resource allocation field in the detected PDCCH DCI. Two uplink resource allocation schemes type 0 and type 1 are supported. Uplink resource allocation scheme type 0 is supported for PUSCH only when transform precoding is disabled. Uplink resource allocation scheme type 1 is supported for PUSCH for both cases when transform precoding is enabled or disabled.
If the scheduling DCI is configured to indicate the uplink resource allocation type as part of the Frequency domain resource assignment field by setting a higher layer parameter resourceAllocation in pusch-Config to ‘dynamicswitch’, the UE shall use uplink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the uplink frequency resource allocation type as defined by the higher layer parameter resourceAllocation.
The UE shall assume that when the scheduling PDCCH is received with DCI format 0_0, then uplink resource allocation type 1 is used.
If a bandwidth part indicator field is not configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s active bandwidth part. If a bandwidth part indicator field is configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s bandwidth part indicated by bandwidth part indicator field value in the DCI, except for the case when DCI format 0_0 is decoded in any PDCCH common search space in CORESET 0 in which case the initial bandwidth part shall be used. The UE shall upon detection of PDCCH intended for the UE determine first the uplink bandwidth part and then the resource allocation within the bandwidth part.
[38.214 clause 6.1.2.2.1]
In uplink resource allocation of type 0, the resource block assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE where a RBG is a set of consecutive virtual resource blocks defined by higher layer parameter rbg-Sizeconfigured for PUSCH and the size of the carrier bandwidth part as defined in Table 6.1.2.2.1-1.
Table 6.1.2.2.1-1: Nominal RBG size P
Carrier Bandwidth Part Size |
Configuration 1 |
Configuration 2 |
1 – 36 |
2 |
4 |
37 – 72 |
4 |
8 |
73 – 144 |
8 |
16 |
145 – 275 |
16 |
16 |
The total number of RBGs () for a uplink carrier bandwidth part i of sizePRBs is given by where
– the size of the first RBG is ,
– the size of the last RBG is if and P otherwise.
– the size of all other RBG is P.
The bitmap is of size bits with one bitmap bit per RBG such that each RBG is addressable. The RBGs shall be indexed in the order of increasing frequency of the carrier bandwidth part and starting at the lowest frequency. The order of RBG bitmap is such that RBG 0 to RBG are mapped from MSB to LSB of the bitmap. The RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE otherwise.
[38.214 clause 6.1.2.2.2]
In uplink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved virtual resource blocks within the active carrier bandwidth part of size PRBs except for the case when DCI format 0_0 is decoded in the Type0-PDCCH common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
An uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed.
[TS 38.214, clause 6.1.4.1]
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, or SP-CSI-RNTI, the transform precoding is enabled if transformPrecoder in PUSCH-Config is set to ‘enabled’, or if transformPrecoder in PUSCH-Config is not configured and msg3-transformPrecoding in rach-ConfigCommon is set to ‘enabled’; otherwise the transform precoding is disabled.
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by CS-RNTI, or the PUSCH with configured grant using CS-RNTI, the transform precoding is enabled if transformPrecoder in ConfiguredGrantConfig is set to ‘enabled’; otherwise the transform precoding is disabled.
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, TC-RNTI, or CS-RNTI, or SP-CSI-RNTI, or for a PUSCH with configured grant using CS-RNTI,
if transformPrecoder is disabled for this PUSCH transmission
– if mcs-Table in PUSCH-Config is set to ‘qam256’, and PUSCH is scheduled with C-RNTI or SP-CSI-RNTI, and PUSCH is assigned by DCI format 0_1,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is not configured with new-RNTI, mcs-Table in PUSCH-Config is set to ‘qam64LowSE’, the PUSCH is scheduled with C-RNTI, or SP-CSI-RNTI, and the PUSCH is assigned by a PDCCH in a UE-specific search space,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is configured with new-RNTI, and the PUSCH is scheduled with new-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-Table in ConfiguredGrantConfig is set to ‘qam256’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-Table in ConfiguredGrantConfig is set to ‘qam64LowSE’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– else
– the UE shall use IMCS and Table 5.1.3.1-1 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
[TS 38.214, clause 5.1.3.1]
Table 5.1.3.1-1: MCS index table 1 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
120 |
0.2344 |
1 |
2 |
157 |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
4 |
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
438 |
2.5664 |
18 |
6 |
466 |
2.7305 |
19 |
6 |
517 |
3.0293 |
20 |
6 |
567 |
3.3223 |
21 |
6 |
616 |
3.6094 |
22 |
6 |
666 |
3.9023 |
23 |
6 |
719 |
4.2129 |
24 |
6 |
772 |
4.5234 |
25 |
6 |
822 |
4.8164 |
26 |
6 |
873 |
5.1152 |
27 |
6 |
910 |
5.3320 |
28 |
6 |
948 |
5.5547 |
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 6.1.4.2]
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SP-CSI-RNTI.
if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is disabled and a table other than Table 5.1.3.1-2 is used, or
– and transform precoding is enabled, the UE shall first determine the TBS as specified below:
The UE shall first determine the number of REs (NRE) within the slot:
– A UE first determines the number of REs allocated for PUSCH within a PRB by
– , where is the number of subcarriers in the frequency domain in a physical resource block, is the number of symbols of the PUSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 0_1 or as described for DCI format 0_0 in Subclause 6.2.2, and is the overhead configured by higher layer parameter xOverhead in PUSCH-ServingCellConfig. If the is not configured (a value from 0, 6, 12, or 18), the is assumed to be 0. For MSG3 transmission the is always set to 0.
– A UE determines the total number of REs allocated for PUSCH by where is the total number of allocated PRBs for the UE.
– Next, proceed with steps 2-4 as defined in Subclause 5.1.3.2
else if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is enabled,
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
else
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
[TS 38.214, clause 5.1.3.2]
2) Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.2.3.3 Test description
7.1.1.4.2.3.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value).
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest mandatory UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.2.3.3.2 Test procedure sequence
Table 7.1.1.4.2.3.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.2.3.3.2-2: Number of downlink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
|||
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
|||
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
|||
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
|||
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
|||
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
|||
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
|||
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
|||
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
|||
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
|||
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
|||
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
|||
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
|||
144921 ≤ TBS ≤ 156992 |
13 |
8*FLOOR((TBS – 992)/104) |
|||
156993 ≤ TBS ≤ 169064 |
14 |
8*FLOOR((TBS – 1064)/112) |
|||
169065 ≤ TBS ≤ 181136 |
15 |
8*FLOOR((TBS – 1136)/120) |
|||
181137 ≤ TBS ≤ 193208 |
16 |
8*FLOOR((TBS – 1208)/128) |
|||
193209 ≤ TBS ≤ 205280 |
17 |
8*FLOOR((TBS – 1280)/136) |
|||
205281 ≤ TBS ≤ 217352 |
18 |
8*FLOOR((TBS – 1352)/144) |
|||
217353 ≤ TBS ≤ 229424 |
19 |
8*FLOOR((TBS – 1424)/152) |
|||
TBS> 229424 |
20 |
8*FLOOR((TBS – 1496)/160) |
|||
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.2.3.3.2-2A: Bandwidth part Dependent Parameters for Resource allocation 0 with start of BWP assumed as 0
= |
Nominal RBG size P (Configuration1) |
Size of last RBG |
Allowed Values |
11 |
2 |
1 |
All 1…11 |
18 |
2 |
2 |
2,4,6,8,10,12,16,18 |
24 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24 |
25 |
2 |
1 |
All 1…25 |
31 |
2 |
1 |
All 1…31 |
32 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32 |
38 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38 |
51 |
4 |
3 |
3,4,7,8,11,12,15,16,19,20,23,24,27,28,31,32,35,36,39,40,43,44,47,48,51 |
52 |
4 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52 |
65 |
4 |
1 |
1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,41,44,45,48,49, 52,53,56,57,60,61,64,65 |
66 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52, 54,56,58,60,62,64,66 |
79 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79 |
106 |
8 |
2 |
2,8,10,16,18,24,26,32,34,40,42,48,50,56,58,64,66,72,74,80,82,88,90,96, 92,104,106 |
107 |
8 |
3 |
3,8,11,16,19,24,27,32,35,40,43,48,51,56,59,64,67,72,75,80,83,88,91,96, 99,104,107 |
132 |
8 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96, 100,104, 108,112,116,120,124,128,132 |
133 |
8 |
5 |
5,8,13,16,21,24,29,32,37,40,45,48,53,56,61,64,69,72,77,80,85,88,93,96, 101,104, 109,112,117,120,125,128,133 |
135 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79,80,87,88,95,96, 103,104, 111,112,119,120,127,128,135 |
160 |
16 |
16 |
16,32,48,64,80,96,112,128,144,160 |
216 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152,160, 168, 176,184,192,200,208,216 |
217 |
16 |
9 |
9,16,25,32,41,48,57,64,73,80,89,96,105,112,121,128,137,144,153,160, 169,176,185,192,201,208,217 |
264 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,160,168, 176,184,192,200,208,216,224,232,240,248,256,264 |
270 |
16 |
14 |
14,16,30,32,46,44,62,64,78,80,94,96,110,112, 126,128,142,144,158, 160,174, 176,190,192, 206,208,222,224,238,240, 254,256,270 |
273 |
16 |
1 |
1,16,17,32,33,48,49,64,65,80,81,96,97,112,113,128,129,144,145,160, 161,176,171, 192,193, 208,209, 224,225,240,241,256,257,272,273 |
Table 7.1.1.4.2.3.3.2-3: Specific Parameter
Parameter |
Value |
Comment |
Condition |
mcs-Table |
qam64 |
||
resourceAllocation |
dynamicSwitch |
pc_dynamicSwitchRA_Type0_1_PUSCH |
|
resourceAllocationType1 |
NOT pc_dynamicSwitchRA_Type0_1_PUSCH AND Steps 1-5 |
||
resourceAllocationType0 |
NOT pc_dynamicSwitchRA_Type0_1_PUSCH AND pc_ra_Type0_PUSCH AND Steps 6-10 |
||
rbg-Size |
Not present |
configuration 1 applicable |
|
NstartBWP |
0 |
Table 7.1.1.4.2.3.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of 1 to in BWP, time domain resource as per Table 7.1.1.4.2.0-1 and from 0 to 28. |
– |
– |
– |
– |
1 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,andnPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.3.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.3.3.2-2. Skip the execution of steps 2 to 5 for which the value of satisfies the condition 3824 < < 3825.(Note 4) Skip the execution of steps 1 to 5 for > 27 and < 5. (Note3) |
– |
– |
– |
– |
2 |
SS creates one or more PDCP SDUs depending on TBS in accordance with Table 7.1.1.4.2.3.3.2-2. |
– |
– |
– |
– |
3 |
The SS transmits all PDCP SDUs (NSDUs) as created in step 2 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
4 |
After the reception of 2 Scheduling Request, SS transmits UL Grant DCI 0_1, and values of S, L,and nPRB |
<– |
(UL Grant) (DCI: (DCI Format 0_1, S, L,and nPRB.) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 4? |
–> |
(NxPDCP SDUs) |
2 |
P |
– |
EXCEPTION : Steps 5Aa1 to 10 are executed if pc_ra_Type0_PUSCH |
– |
– |
– |
– |
– |
EXCEPTION : Steps 5Aa1 to 5Aa2 are executed if NOT pc_dynamicSwitchRA_Type0_1_PUSCH |
– |
– |
– |
– |
5Aa1 |
The SS transmits a NR RRCReconfiguration message including PUSCH-Config with IE resourceAllocation set toresourceAllocationType0 (Note 1) |
<– |
RRCReconfiguration |
– |
– |
5Aa2 |
The UE transmit a NR RRCReconfigurationComplete message.(Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
– |
EXCEPTION: Steps 6 to 10 are repeated for allowed values of as per table 7.1.1.4.2.3.3.2-2A in BWP, time domain resource length L 3 to 14-S and from 0 to 28. |
– |
– |
– |
– |
6 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 7 to 10 are performed if TBS1 + TBS2 is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.3.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.3.3.2-2. Skip the execution of steps 7 to 10 for which the value of satisfies the condition 3824 < < 3825. (Note 4) Skip the execution of steps 6 to 10 for > 27 and < 5. (Note 3) |
– |
– |
– |
– |
7 |
SS creates one or more PDCP SDUs depending on TBS in accordance with Table 7.1.1.4.2.3.3.2-2. |
– |
– |
– |
– |
8 |
The SS transmits all PDCP SDUs (NSDUs) as created in step 7 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
9 |
After the reception of 2 Scheduling Request SS transmits UL Grant DCI 0_1, and values of S, L,and nPRB. |
<– |
(UL Grant) (DCI: (DCI Format 0_1, S, L,and nPRB.) |
– |
– |
10 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 8 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 9? |
–> |
(NxPDCP SDUs) |
1 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: For > 27 and < 5, the combination results in higher coding rate and therefore leading to CRC errors in decoding UL data. Note 4: Depending upon UE implementation of TBS determination as per clause 5.1.3.2 of TS 38.214 [15], 3824 < < 3825, different step may be used by UEs for TBS determintation. When Resource Allocation Type is RA Type 1, =5,=123 and Time Domain Allocation Symbols = 4, the resulting is 3824.05. |
7.1.1.4.2.3.3.3 Specific message contents
None.
7.1.1.4.2.4 UL-SCH transport block size selection / DCI format 0_1 / RA type 0/RA Type 1 / 256QAM / Transform precoding disabled
7.1.1.4.2.4.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and mcs-Table is set as ‘qam256‘ }
ensure that {
when { UE has pending data for transmission and receives DCI format 0_1 indicating resource allocation type 0 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE transmits MAC PDU’s on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
(2)
with { UE in RRC_CONNECTED state and mcs-Table is set as ‘qam256‘ }
ensure that {
when { UE has pending data for transmission and receives DCI format 0_1 indicating resource allocation type 1 a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and a modulation and coding }
then { UE transmits MAC PDU’s on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
7.1.1.4.2.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.1.1, TS 38.214 clause 6.1.2.1, 6.1.2.2, 6.1.2.2.1, 6.1.2.2.2, 6.1.4.1, 5.1.3.1, 6.1.4.2 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.1.2]
DCI format 0_1 is used for the scheduling of PUSCH in one cell.
The following information is transmitted by means of the DCI format 0_1 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Carrier indicator – 0 or 3 bits, as defined in Subclause 10.1 of [5, TS38.213].
– UL/SUL indicator – 0 bit for UEs not configured with SUL in the cell or UEs configured with SUL in the cell but only PUCCH carrier in the cell is configured for PUSCH transmission; 1 bit for UEs configured with SUL in the cell as defined in Table 7.3.1.1.1-1.
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of UL BWPs configured by higher layers, excluding the initial UL bandwidth part. The bit width for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
– Frequency domain resource assignment – number of bits determined by the following, where is the size of the active UL bandwidth part:
– bits if only resource allocation type 0 is configured, where is defined in Subclause 6.1.2.2.1 of [6, TS 38.214],
– bits if only resource allocation type 1 is configured, or bits if both resource allocation type 0 and 1 are configured.
– If both resource allocation type 0 and 1 are configured, the MSB bit is used to indicate resource allocation type 0 or resource allocation type 1, where the bit value of 0 indicates resource allocation type 0 and the bit value of 1 indicates resource allocation type 1.
– For resource allocation type 0, the LSBs provide the resource allocation as defined in Subclause 6.1.2.2.1 of [6, TS 38.214].
– For resource allocation type 1, the LSBs provide the resource allocation as follows:
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Subclause 6.3 of [6, TS 38.214], where if the higher layer parameter frequencyHoppingOffsetLists contains two offset values and if the higher layer parameter frequencyHoppingOffsetLists contains four offset values
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– For non-PUSCH hopping with resource allocation type 1:
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
If "Bandwidth part indicator" field indicates a bandwidth part other than the active bandwidth part and if both resource allocation type 0 and 1 are configured for the indicated bandwidth part, the UE assumes resource allocation type 0 for the indicated bandwidth part if the bit width of the "Frequency domain resource assignment" field of the active bandwidth part is smaller than the bit width of the "Frequency domain resource assignment" field of the indicated bandwidth part.
– Time domain resource assignment – 0, 1, 2, 3, or 4 bits as defined in Subclause 6.1.2.1 of [6, TS38.214]. The bit width for this field is determined as bits, where I the number of entries in the higher layer parameter pusch-AllocationList.
– Frequency hopping flag – 0 or 1 bit:
– 0 bit if only resource allocation type 0 is configured or if the higher layer parameter frequencyHopping is not configured;
– 1 bit according to Table 7.3.1.1.2-34 otherwise, only applicable to resource allocation type 1, as defined in Subclause 6.3 of [6, TS 38.214].
– Modulation and coding scheme – 5 bits as defined in Subclause 6.1.4.1 of [6, TS 38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits
– 1st downlink assignment index – 1 or 2 bits:
– 1 bit for semi-static HARQ-ACK codebook;
– 2 bits for dynamic HARQ-ACK codebook.
– 2nd downlink assignment index – 0 or 2 bits:
– 2 bits for dynamic HARQ-ACK codebook with two HARQ-ACK sub-codebooks;
– 0 bit otherwise.
– TPC command for scheduled PUSCH – 2 bits as defined in Subclause 7.1.1 of [5, TS38.213]
– SRS resource indicator – or bits, where is the number of configured SRS resources in the SRS resource set associated with the higher layer parameter usage of value ‘codeBook‘ or ‘nonCodeBook‘, and is the maximum number of supported layers for the PUSCH.
– bits according to Tables 7.3.1.1.2-28/29/30/31 if the higher layer parameter txConfig = nonCodebook, where is the number of configured SRS resources in the SRS resource set associated with the higher layer parameter usage of value ‘nonCodeBook‘;
– bits according to Tables 7.3.1.1.2-32 if the higher layer parameter txConfig = codebook, where is the number of configured SRS resources in the SRS resource set associated with the higher layer parameter usage of value ‘codeBook‘.
– Precoding information and number of layers – number of bits determined by the following:
– 0 bits if the higher layer parameter txConfig = nonCodeBook;
– 0 bits for 1 antenna port and if the higher layer parameter txConfig = codebook;
– 4, 5, or 6 bits according to Table 7.3.1.1.2-2 for 4 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters transformPrecoder, maxRank, and codebookSubset;
– 2, 4, or 5 bits according to Table 7.3.1.1.2-3 for 4 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters transformPrecoder, maxRank, and codebookSubset;
– 2 or 4 bits according to Table7.3.1.1.2-4 for 2 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters maxRank and codebookSubset;
– 1 or 3 bits according to Table7.3.1.1.2-5 for 2 antenna ports, if txConfig = codebook, and according to the values of higher layer parameters maxRank and codebookSubset.
– Antenna ports – number of bits determined by the following
– 2 bits as defined by Tables 7.3.1.1.2-6, if transformPrecoder=enabled, dmrs-Type=1, and maxLength=1;
– 4 bits as defined by Tables 7.3.1.1.2-7, if transformPrecoder=enabled, dmrs-Type=1, and maxLength=2;
– 3 bits as defined by Tables 7.3.1.1.2-8/9/10/11, if transformPrecoder=disabled, dmrs-Type=1, and maxLength=1, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 4 bits as defined by Tables 7.3.1.1.2-12/13/14/15, if transformPrecoder=disabled, dmrs-Type=1, and maxLength=2, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 4 bits as defined by Tables 7.3.1.1.2-16/17/18/19, if transformPrecoder=disabled, dmrs-Type=2, and maxLength=1, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 5 bits as defined by Tables 7.3.1.1.2-20/21/22/23, if transformPrecoder=disabled, dmrs-Type=2, and maxLength=2, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook.
where the number of CDM groups without data of values 1, 2, and 3 in Tables 7.3.1.1.2-6 to 7.3.1.1.2-23 refers to CDM groups {0}, {0,1}, and {0, 1,2} respectively.
If a UE is configured with both dmrs-UplinkForPUSCH-MappingTypeA and dmrs-UplinkForPUSCH-MappingTypeB, the bit width of this field equals , where is the “Antenna ports” bit width derived according to dmrs-UplinkForPUSCH-MappingTypeA and is the “Antenna ports” bit width derived according to dmrs-UplinkForPUSCH-MappingTypeB. A number of zeros are padded in the MSB of this field, if the mapping type of the PUSCH corresponds to the smaller value of and .
– SRS request – 2 bits as defined by Table 7.3.1.1.2-24 for UEs not configured with SUL in the cell; 3 bits for UEs configured SUL in the cell where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second and third bits are defined by Table 7.3.1.1.2-24. This bit field may also indicate the associated CSI-RS according to Subclause 6.1.1.2 of [6, TS 38.214].
– CSI request – 0, 1, 2, 3, 4, 5, or 6 bits determined by higher layer parameter reportTriggerSize.
– CBG transmission information (CBGTI) – 0, 2, 4, 6, or 8 bits determined by higher layer parameter maxCodeBlockGroupsPerTransportBlock for PUSCH.
– PTRS-DMRS association – number of bits determined as follows
– 0 bit if PTRS-UplinkConfig is not configured and transformPrecoder=disabled, or if transformPrecoder=enabled, or if maxRank=1;
– 2 bits otherwise, where Table 7.3.1.1.2-25 and 7.3.1.1.2-26 are used to indicate the association between PTRS port(s) and DMRS port(s) for transmission of one PT-RS port and two PT-RS ports respectively, and the DMRS ports are indicated by the Antenna ports field.
If “Bandwidth part indicator” field indicates a bandwidth part other than the active bandwidth part and the “PTRS-DMRS association” field is present for the indicated bandwidth part but not present for the active bandwidth part, the UE assumes the “PTRS-DMRS association” field is not present for the indicated bandwidth part.
– beta_offset indicator – 0 if the higher layer parameter betaOffsets = semiStatic; otherwise 2 bits as defined by Table 9.3-3 in [5, TS 38.213].
– DMRS sequence initialization – 0 if the higher layer parameter transformPrecoder=enabled; 1 bit if the higher layer parameter transformPrecoder=disabled and both scramblingID0 and scramblingID1 are configured in DMRS-UplinkConfig, for selection defined in Subclause 6.4.1.1.1.1 of [4, TS 38.211].
– UL-SCH indicator – 1 bit. A value of “1” indicates UL-SCH shall be transmitted on the PUSCH and a value of “0” indicates UL-SCH shall not be transmitted on the PUSCH.
For a UE configured with SUL in a cell, if PUSCH is configured to be transmitted on both the SUL and the non-SUL of the cell and if the number of information bits in format 0_1 for the SUL is not equal to the number of information bits in format 0_1 for the non-SUL, zeros shall be appended to smaller format 0_1 until the payload size equals that of the larger format 0_1.
Table 7.3.1.1.2-1: Bandwidth part indicator
Value of BWP indicator field |
Bandwidth part |
2 bits |
|
00 |
First bandwidth part configured by higher layers |
01 |
Second bandwidth part configured by higher layers |
10 |
Third bandwidth part configured by higher layers |
11 |
Fourth bandwidth part configured by higher layers |
Table 7.3.1.1.2-2: Precoding information and number of layers, for 4 antenna ports, if transformPrecoder=disabled and maxRank = 2 or 3 or 4
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset = partialAndNonCoherent |
Bit field mapped to index |
codebookSubset= nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
… |
… |
… |
… |
… |
… |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
4 |
2 layers: TPMI=0 |
4 |
2 layers: TPMI=0 |
4 |
2 layers: TPMI=0 |
… |
… |
… |
… |
… |
… |
9 |
2 layers: TPMI=5 |
9 |
2 layers: TPMI=5 |
9 |
2 layers: TPMI=5 |
10 |
3 layers: TPMI=0 |
10 |
3 layers: TPMI=0 |
10 |
3 layers: TPMI=0 |
11 |
4 layers: TPMI=0 |
11 |
4 layers: TPMI=0 |
11 |
4 layers: TPMI=0 |
12 |
1 layer: TPMI=4 |
12 |
1 layer: TPMI=4 |
12-15 |
reserved |
… |
… |
… |
… |
||
19 |
1 layer: TPMI=11 |
19 |
1 layer: TPMI=11 |
||
20 |
2 layers: TPMI=6 |
20 |
2 layers: TPMI=6 |
||
… |
… |
… |
… |
||
27 |
2 layers: TPMI=13 |
27 |
2 layers: TPMI=13 |
||
28 |
3 layers: TPMI=1 |
28 |
3 layers: TPMI=1 |
||
29 |
3 layers: TPMI=2 |
29 |
3 layers: TPMI=2 |
||
30 |
4 layers: TPMI=1 |
30 |
4 layers: TPMI=1 |
||
31 |
4 layers: TPMI=2 |
31 |
4 layers: TPMI=2 |
||
32 |
1 layers: TPMI=12 |
||||
… |
… |
||||
47 |
1 layers: TPMI=27 |
||||
48 |
2 layers: TPMI=14 |
||||
… |
… |
||||
55 |
2 layers: TPMI=21 |
||||
56 |
3 layers: TPMI=3 |
||||
… |
… |
||||
59 |
3 layers: TPMI=6 |
||||
60 |
4 layers: TPMI=3 |
||||
61 |
4 layers: TPMI=4 |
||||
62-63 |
reserved |
Table 7.3.1.1.2-3: Precoding information and number of layers for 4 antenna ports, if transformPrecoder= enabled, or if transformPrecoder=disabled and maxRank = 1
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset= partialAndNonCoherent |
Bit field mapped to index |
codebookSubset= nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
… |
… |
… |
… |
… |
… |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
3 |
1 layer: TPMI=3 |
4 |
1 layer: TPMI=4 |
4 |
1 layer: TPMI=4 |
||
… |
… |
… |
… |
||
11 |
1 layer: TPMI=11 |
11 |
1 layer: TPMI=11 |
||
12 |
1 layers: TPMI=12 |
12-15 |
reserved |
||
… |
… |
||||
27 |
1 layers: TPMI=27 |
||||
28-31 |
reserved |
Table 7.3.1.1.2-4: Precoding information and number of layers, for 2 antenna ports, if transformPrecoder=disabled and maxRank = 2
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset = nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
2 |
2 layers: TPMI=0 |
2 |
2 layers: TPMI=0 |
3 |
1 layer: TPMI=2 |
3 |
reserved |
4 |
1 layer: TPMI=3 |
||
5 |
1 layer: TPMI=4 |
||
6 |
1 layer: TPMI=5 |
||
7 |
2 layers: TPMI=1 |
||
8 |
2 layers: TPMI=2 |
||
9-15 |
reserved |
Table 7.3.1.1.2-5: Precoding information and number of layers, for 2 antenna ports, if transformPrecoder= enabled, or if transformPrecoder= disabled and maxRank = 1
Bit field mapped to index |
codebookSubset = fullyAndPartialAndNonCoherent |
Bit field mapped to index |
codebookSubset = nonCoherent |
0 |
1 layer: TPMI=0 |
0 |
1 layer: TPMI=0 |
1 |
1 layer: TPMI=1 |
1 |
1 layer: TPMI=1 |
2 |
1 layer: TPMI=2 |
||
3 |
1 layer: TPMI=3 |
||
4 |
1 layer: TPMI=4 |
||
5 |
1 layer: TPMI=5 |
||
6-7 |
reserved |
…
Table 7.3.1.1.2-33: VRB-to-PRB mapping
Bit field mapped to index |
VRB-to-PRB mapping |
0 |
Non-interleaved |
1 |
Interleaved |
[TS 38.214, clause 6.1.2.1]
When the UE is scheduled to transmit a transport block and no CSI report, or the UE is scheduled to transmit a transport block and a CSI report on PUSCH by a DCI, the Time domain resource assignment field value md of the DCI provides a row index m + 1 to an allocated table. The determination of the used resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission.
When the UE is scheduled to transmit a PUSCH with no transport block and with a CSI report by a CSI request field on a DCI, the Time-domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the applied resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission and K2 is determined based on the corresponding list entries of the higher layer parameter reportSlotConfig in CSI-ReportConfig for the triggered CSI Reporting Settings. The ith codepoint of K2 s determined as where is the ith codepoint of .
– The slot where the UE shall transmit the PUSCH is determined by K2 as where n is the slot with the scheduling DCI, K2 is based on the numerology of PUSCH, and and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– The PUSCH mapping type is set to Type A or Type B as defined in Subclause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} |
{0,…,12} |
{1,…,12} |
{1,…,12} |
When the UE is configured with aggregationFactorUL > 1, the same symbol allocation is applied across the aggregationFactorUL consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the aggregationFactorUL consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version when aggregationFactorUL > 1
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
If the UE procedure for determining slot configuration, as defined in subclause 11.1 of [6, TS 38.213], determines symbols of a slot allocated for PUSCH as downlink symbols, the transmission on that slot is omitted for multi-slot PUSCH transmission.
[38.214 clause 6.1.2.2]
The UE shall determine the resource block assignment in frequency domain using the resource allocation field in the detected PDCCH DCI. Two uplink resource allocation schemes type 0 and type 1 are supported. Uplink resource allocation scheme type 0 is supported for PUSCH only when transform precoding is disabled. Uplink resource allocation scheme type 1 is supported for PUSCH for both cases when transform precoding is enabled or disabled.
If the scheduling DCI is configured to indicate the uplink resource allocation type as part of the Frequency domain resource assignment field by setting a higher layer parameter resourceAllocation in pusch-Config to ‘dynamicswitch’, the UE shall use uplink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the uplink frequency resource allocation type as defined by the higher layer parameter resourceAllocation.
The UE shall assume that when the scheduling PDCCH is received with DCI format 0_0, then uplink resource allocation type 1 is used.
If a bandwidth part indicator field is not configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s active bandwidth part. If a bandwidth part indicator field is configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s bandwidth part indicated by bandwidth part indicator field value in the DCI, except for the case when DCI format 0_0 is decoded in any PDCCH common search space in CORESET 0 in which case the initial bandwidth part shall be used. The UE shall upon detection of PDCCH intended for the UE determine first the uplink bandwidth part and then the resource allocation within the bandwidth part.
[38.214 clause 6.1.2.2.1]
In uplink resource allocation of type 0, the resource block assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE where a RBG is a set of consecutive virtual resource blocks defined by higher layer parameter rbg-Sizeconfigured for PUSCH and the size of the carrier bandwidth part as defined in Table 6.1.2.2.1-1.
Table 6.1.2.2.1-1: Nominal RBG size P
Carrier Bandwidth Part Size |
Configuration 1 |
Configuration 2 |
1 – 36 |
2 |
4 |
37 – 72 |
4 |
8 |
73 – 144 |
8 |
16 |
145 – 275 |
16 |
16 |
The total number of RBGs () for a uplink carrier bandwidth part i of sizePRBs is given by where
– the size of the first RBG is ,
– the size of the last RBG is if and P otherwise.
– the size of all other RBG is P.
The bitmap is of size bits with one bitmap bit per RBG such that each RBG is addressable. The RBGs shall be indexed in the order of increasing frequency of the carrier bandwidth part and starting at the lowest frequency. The order of RBG bitmap is such that RBG 0 to RBG are mapped from MSB to LSB of the bitmap. The RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE otherwise.
[38.214 clause 6.1.2.2.2]
In uplink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved virtual resource blocks within the active carrier bandwidth part of size PRBs except for the case when DCI format 0_0 is decoded in the Type0-PDCCH common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
An uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed.
[TS 38.214, clause 6.1.4.1]
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, or SP-CSI-RNTI, the transform precoding is enabled if transformPrecoder in PUSCH-Config is set to ‘enabled’, or if transformPrecoder in PUSCH-Config is not configured and msg3-transformPrecoding in rach-ConfigCommon is set to ‘enabled’; otherwise the transform precoding is disabled.
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by CS-RNTI, or the PUSCH with configured grant using CS-RNTI, the transform precoding is enabled if transformPrecoder in ConfiguredGrantConfig is set to ‘enabled’; otherwise the transform precoding is disabled.
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, TC-RNTI, or CS-RNTI, or SP-CSI-RNTI, or for a PUSCH with configured grant using CS-RNTI,
if transformPrecoder is disabled for this PUSCH transmission
– if mcs-Table in PUSCH-Config is set to ‘qam256’, and PUSCH is scheduled with C-RNTI or SP-CSI-RNTI, and PUSCH is assigned by DCI format 0_1,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is not configured with new-RNTI, mcs-Table in PUSCH-Config is set to ‘qam64LowSE’, the PUSCH is scheduled with C-RNTI, or SP-CSI-RNTI, and the PUSCH is assigned by a PDCCH in a UE-specific search space,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is configured with new-RNTI, and the PUSCH is scheduled with new-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-Table in ConfiguredGrantConfig is set to ‘qam256’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-Table in ConfiguredGrantConfig is set to ‘qam64LowSE’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– else
– the UE shall use IMCS and Table 5.1.3.1-1 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
[TS 38.214, clause 5.1.3.1]
Table 5.1.3.1-2: MCS index table 2 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
120 |
0.2344 |
1 |
2 |
193 |
0.3770 |
2 |
2 |
308 |
0.6016 |
3 |
2 |
449 |
0.8770 |
4 |
2 |
602 |
1.1758 |
5 |
4 |
378 |
1.4766 |
6 |
4 |
434 |
1.6953 |
7 |
4 |
490 |
1.9141 |
8 |
4 |
553 |
2.1602 |
9 |
4 |
616 |
2.4063 |
10 |
4 |
658 |
2.5703 |
11 |
6 |
466 |
2.7305 |
12 |
6 |
517 |
3.0293 |
13 |
6 |
567 |
3.3223 |
14 |
6 |
616 |
3.6094 |
15 |
6 |
666 |
3.9023 |
16 |
6 |
719 |
4.2129 |
17 |
6 |
772 |
4.5234 |
18 |
6 |
822 |
4.8164 |
19 |
6 |
873 |
5.1152 |
20 |
8 |
682.5 |
5.3320 |
21 |
8 |
711 |
5.5547 |
22 |
8 |
754 |
5.8906 |
23 |
8 |
797 |
6.2266 |
24 |
8 |
841 |
6.5703 |
25 |
8 |
885 |
6.9141 |
26 |
8 |
916.5 |
7.1602 |
27 |
8 |
948 |
7.4063 |
28 |
2 |
reserved |
|
29 |
4 |
reserved |
|
30 |
6 |
reserved |
|
31 |
8 |
reserved |
[TS 38.214, clause 6.1.4.2]
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SP-CSI-RNTI.
if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is disabled and a table other than Table 5.1.3.1-2 is used, or
– and transform precoding is enabled, the UE shall first determine the TBS as specified below:
The UE shall first determine the number of REs (NRE) within the slot:
– A UE first determines the number of REs allocated for PUSCH within a PRB by
– , where is the number of subcarriers in the frequency domain in a physical resource block, is the number of symbols of the PUSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 0_1 or as described for DCI format 0_0 in Subclause 6.2.2, and is the overhead configured by higher layer parameter xOverhead in PUSCH-ServingCellConfig. If the is not configured (a value from 0, 6, 12, or 18), the is assumed to be 0. For MSG3 transmission the is always set to 0.
– A UE determines the total number of REs allocated for PUSCH by where is the total number of allocated PRBs for the UE.
– Next, proceed with steps 2-4 as defined in Subclause 5.1.3.2
else if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is enabled,
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
else
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
[TS 38.214, clause 5.1.3.2]
2) Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.2.4.3 Test description
7.1.1.4.2.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value).
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest mandatory UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.2.4.3.2 Test procedure sequence
Table 7.1.1.4.2.4.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.2.4.3.2-2: Number of downlink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
TBS> 144920 |
13 |
8*FLOOR((TBS – 992)/104) |
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.2.4.3.2-2A: Bandwidth part Dependent Parameters for Resource allocation 0 with start of BWP assumed as 0
= |
Nominal RBG size P (Configuration1) |
Size of last RBG |
Allowed Values |
11 |
2 |
1 |
All 1…11 |
18 |
2 |
2 |
2,4,6,8,10,12,16,18 |
24 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24 |
25 |
2 |
1 |
All 1…25 |
31 |
2 |
1 |
All 1…31 |
32 |
2 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32 |
38 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38 |
51 |
4 |
3 |
3,4,7,8,11,12,15,16,19,20,23,24,27,28,31,32,35,36,39,40,43,44,47,48,51 |
52 |
4 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52 |
65 |
4 |
1 |
1,4,5,8,9,12,13,16,17,20,21,24,25,28,29,32,33,36,37,40,41,44,45,48,49, 52,53,56,57,60,61,64,65 |
66 |
4 |
2 |
2,4,6,8,10,12,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52, 54,56,58,60,62,64,66 |
79 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79 |
106 |
8 |
2 |
2,8,10,16,18,24,26,32,34,40,42,48,50,56,58,64,66,72,74,80,82,88,90,96, 92,104,106 |
107 |
8 |
3 |
3,8,11,16,19,24,27,32,35,40,43,48,51,56,59,64,67,72,75,80,83,88,91,96, 99,104,107 |
132 |
8 |
4 |
4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96, 100,104, 108,112,116,120,124,128,132 |
133 |
8 |
5 |
5,8,13,16,21,24,29,32,37,40,45,48,53,56,61,64,69,72,77,80,85,88,93,96, 101,104, 109,112,117,120,125,128,133 |
135 |
8 |
7 |
7,8,15,16,23,24,31,32,39,40,47,48,55,56,63,64,71,72,79,80,87,88,95,96, 103,104, 111,112,119,120,127,128,135 |
160 |
16 |
16 |
16,32,48,64,80,96,112,128,144,160 |
216 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152,160,168, 176,184,192,200,208,216 |
217 |
16 |
9 |
9,16,25,32,41,48,57,64,73,80,89,96,105,112,121,128,137,144,153,160,169, 176,185,192,201,208,217 |
264 |
16 |
8 |
8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,160,168, 176,184,192,200,208,216,224,232,240,248,256,264 |
270 |
16 |
14 |
14,16,30,32,46,44,62,64,78,80,94,96,110,112, 126,128,142,144,158,160, 174, 176,190,192, 206,208,222,224,238,240, 254,256,270 |
273 |
16 |
1 |
1,16,17,32,33,48,49,64,65,80,81,96,97,112,113,128,129,144,145,160, 161,176,171, 192,193, 208,209, 224,225,240,241,256,257,272,273 |
Table 7.1.1.4.2.4.3.2-3: Specific Parameter
Parameter |
Value |
Comment |
Condition |
number of layers (ʋ) |
1 |
||
mcs-Table |
qam256 |
||
resourceAllocation |
dynamicSwitch |
pc_dynamicSwitchRA_Type0_1_PUSCH |
|
resourceAllocationType1 |
NOT pc_dynamicSwitchRA_Type0_1_PUSCH AND Steps 1-5 |
||
resourceAllocationType0 |
NOT pc_dynamicSwitchRA_Type0_1_PUSCH AND pc_ra_Type0_PUSCH AND Steps 6-10 |
||
rbg-Size |
Not present |
configuration 1 applicable |
|
NstartBWP |
0 |
Table 7.1.1.4.2.4.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of 1 to in BWP, time domain resource as per Table 7.1.1.4.2.0-1 and from 0 to 27. |
– |
– |
– |
– |
1 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.4.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.4.3.2-2. Skip the execution of steps 2 to 5 for which the TBS size equal to 3824 or 3840. (Note 3) |
– |
– |
– |
– |
2 |
SS creates one or more PDCP SDUs depending on TBS in accordance with Table 7.1.1.4.2.4.3.2-2. |
– |
– |
– |
– |
3 |
After 300ms, the SS transmits all PDCP SDUs (NSDUs) as created in step 2 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
4 |
After 60ms of step 3 SS transmits UL Grant DCI 0_1, and values of S, L,and nPRB. |
<– |
(UL Grant) (DCI: (DCI Format 0_1, S, L,and nPRB.) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 4? |
–> |
(NxPDCP SDUs) |
2 |
P |
– |
EXCEPTION : Steps 5Aa1 to 10 are executed if pc_ra_Type0_PUSCH |
– |
– |
– |
– |
– |
EXCEPTION : Steps 5Aa1 to 5Aa2 are executed if NOT pc_dynamicSwitchRA_Type0_1_PUSCH |
– |
– |
– |
– |
5Aa1 |
The SS transmits a NR RRCReconfiguration message including PUSCH-Config with IE resourceAllocation set to resourceAllocationType1 (Note 1) |
<– |
RRCReconfiguration |
– |
– |
5Aa2 |
The UE transmit a NR RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
– |
EXCEPTION: Steps 6 to 10 are repeated for allowed values of as per Table 7.1.1.4.2.4.3.2-2A in BWP, time domain resource length L 3 to 14-S and from 0 to 27. |
– |
– |
– |
– |
6 |
SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 7 to 10 are performed if TBS is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.4.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.4.3.2-2. Skip the execution of steps 7 to 10 for which the TBS size equal to 3824 or 3840. (Note 3) |
– |
– |
– |
– |
7 |
SS creates one or more PDCP SDUs depending on TBS in accordance with Table 7.1.1.4.2.4.3.2-2. |
– |
– |
– |
– |
8 |
After 300ms, the SS transmits all PDCP SDUs (NSDUs) as created in step 7 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
9 |
After 60ms of step 8 SS transmits UL Grant DCI 0_1, and values of S, L,and nPRB. |
<– |
(UL Grant) (DCI: (DCI Format 0_1, S, L,and nPRB.) |
– |
– |
10 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 8 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 4? |
–> |
(NxPDCP SDUs) |
1 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: There is ambiguity of TBS calculation when 3824.0 < Ninfo < 3825.0 in clause 5.1.3.2 of TS 38.214 [15]. |
7.1.1.4.2.4.3.3 Specific message contents
[None].
7.1.1.4.2.5 UL-SCH Transport Block Size selection / DCI format 0_0 / Transform precoding and 64QAM
7.1.1.4.2.5.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and transform precoding enabled}
ensure that {
when { UE has pending data for transmission and receives on PDCCH DCI format 0_0 indicating a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and modulation and coding }
then { UE transmits MAC PDU on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
7.1.1.4.2.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.1.1, TS 38.214 clause 6.1.2.1, 6.1.2.2, 6.1.2.2.2, 6.1.4.1, 5.1.3.1, 6.1.4.2 and 5.1.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.1.1]
DCI format 0_0 is used for the scheduling of PUSCH in one cell.
The following information is transmitted by means of the DCI format 0_0 with CRC scrambled by C-RNTI or CS-RNTI or new-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Frequency domain resource assignment – bits where
– is the size of the active UL bandwidth part in case DCI format 0_0 is monitored in the UE specific search space and satisfying
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
– otherwise, is the size of the initial UL bandwidth part.
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Subclause 6.3 of [6, TS 38.214], where if the higher layer parameter frequencyHoppingOffsetLists contains two offset values and if the higher layer parameter frequencyHoppingOffsetLists contains four offset values
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– For non-PUSCH hopping with resource allocation type 1:
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– Time domain resource assignment – 4 bits as defined in Subclause 6.1.2.1 of [6, TS 38.214]
– Frequency hopping flag – 1 bit.
– Modulation and coding scheme – 5 bits as defined in Subclause 6.1.3 of [6, TS 38.214]
– New data indicator – 1 bit
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits
– TPC command for scheduled PUSCH – 2 bits as defined in Subclause 7.1.1 of [5, TS 38.213]
– Padding bits, if required.
– UL/SUL indicator – 1 bit for UEs configured with SUL in the cell as defined in Table 7.3.1.1.1-1 and the number of bits for DCI format 1_0 before padding is larger than the number of bits for DCI format 0_0 before padding; 0 bit otherwise. The UL/SUL indicator, if present, locates in the last bit position of DCI format 0_0, after the padding bit(s).
– If the UL/SUL indicator is present in DCI format 0_0 and the higher layer parameter pusch-Config is not configured on both UL and SUL the UE ignores the UL/SUL indicator field in DCI format 0_0, and the corresponding PUSCH scheduled by the DCI format 0_0 is for the UL or SUL for which high layer parameter pucch-Config is configured;
– If the UL/SUL indicator is not present in DCI format 0_0, the corresponding PUSCH scheduled by the DCI format 0_0 is for the UL or SUL for which high layer parameter pucch-Config is configured.
The following information is transmitted by means of the DCI format 0_0 with CRC scrambled by TC-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Frequency domain resource assignment –bits where
– is the size of the initial UL bandwidth part.
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Subclause 6.3 of [6, TS 38.214], where if and otherwise
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– For non-PUSCH hopping with resource allocation type 1:
– bits provides the frequency domain resource allocation according to Subclause 6.1.2.2.2 of [6, TS 38.214]
– Time domain resource assignment – 4 bits as defined in Subclause 6.1.2.1 of [6, TS 38.214]
– Frequency hopping flag – 1 bit.
– Modulation and coding scheme – 5 bits as defined in Subclause 6.1.3 of [6, TS 38.214], using Table 5.1.3.1-1
– New data indicator – 1 bit, reserved
– Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2
– HARQ process number – 4 bits, reserved
– TPC command for scheduled PUSCH – 2 bits as defined in Subclause 7.1.1 of [5, TS 38.213]
– Padding bits, if required.
– UL/SUL indicator – 1 bit if the cell has two ULs and the number of bits for DCI format 1_0 before padding is larger than the number of bits for DCI format 0_0 before padding; 0 bit otherwise. The UL/SUL indicator, if present, locates in the last bit position of DCI format 0_0, after the padding bit(s).
– If 1 bit, reserved, and the corresponding PUSCH is always on the same UL carrier as the previous transmission of the same TB
If DCI format 0_0 is monitored in common search space and if the number of information bits in the DCI format 0_0 prior to padding is less than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, zeros shall be appended to the DCI format 0_0 until the payload size equals that of the DCI format 1_0.
If DCI format 0_0 is monitored in common search space and if the number of information bits in the DCI format 0_0 prior to padding is larger than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, the bit width of the frequency domain resource allocation field in the DCI format 0_0 is reduced by truncating the first few most significant bits such that the size of DCI format 0_0 equals to the size of the DCI format 1_0.
If DCI format 0_0 is monitored in UE specific search space but does not satisfy at least one of the following
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
and if the number of information bits in the DCI format 0_0 prior to padding is less than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, zeros shall be appended to the DCI format 0_0 until the payload size equals that of the DCI format 1_0.
If DCI format 0_0 is monitored in UE specific search space but does not satisfy at least one of the following
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
and if the number of information bits in the DCI format 0_0 prior to padding is larger than the payload size of the DCI format 1_0 monitored in common search space for scheduling the same serving cell, the bit width of the frequency domain resource allocation field in the DCI format 0_0 is reduced by truncating the first few most significant bits such that the size of DCI format 0_0 equals to the size of the DCI format 1_0.
If DCI format 0_0 is monitored in UE specific search space and satisfies both of the following
– the total number of different DCI sizes monitored per slot is no more than 4 for the cell, and
– the total number of different DCI sizes with C-RNTI monitored per slot is no more than 3 for the cell
and if the number of information bits in the DCI format 0_0 prior to padding is less than the payload size of the DCI format 1_0 monitored in UE specific search space for scheduling the same serving cell, zeros shall be appended to the DCI format 0_0 until the payload size equals that of the DCI format 1_0.
[TS 38.214, clause 6.1.2.1]
When the UE is scheduled to transmit a transport block and no CSI report, or the UE is scheduled to transmit a transport block and a CSI report on PUSCH by a DCI, the Time domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the used resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission.
When the UE is scheduled to transmit a PUSCH with no transport block and with a CSI report by a CSI request field on a DCI, the Time-domain resource assignment field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the applied resource allocation table is defined in sub-clause 6.1.2.1.1. The indexed row defines the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission and K2 is determined based on the corresponding list entries of the higher layer parameter reportSlotConfig in CSI-ReportConfig for the triggered CSI Reporting Settings. The ith codepoint of K2 s determined as where is the ith codepoint of .
– The slot where the UE shall transmit the PUSCH is determined by K2 as where n is the slot with the scheduling DCI, K2 is based on the numerology of PUSCH, and and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively, and
– The starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– The PUSCH mapping type is set to Type A or Type B as defined in Subclause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} |
{0,…,12} |
{1,…,12} |
{1,…,12} |
When the UE is configured with aggregationFactorUL > 1, the same symbol allocation is applied across the aggregationFactorUL consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the aggregationFactorUL consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version when aggregationFactorUL > 1
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
If the UE procedure for determining slot configuration, as defined in subclause 11.1 of [6, TS 38.213], determines symbols of a slot allocated for PUSCH as downlink symbols, the transmission on that slot is omitted for multi-slot PUSCH transmission.
[38.214 clause 6.1.2.2]
The UE shall determine the resource block assignment in frequency domain using the resource allocation field in the detected PDCCH DCI. Two uplink resource allocation schemes type 0 and type 1 are supported. Uplink resource allocation scheme type 0 is supported for PUSCH only when transform precoding is disabled. Uplink resource allocation scheme type 1 is supported for PUSCH for both cases when transform precoding is enabled or disabled.
If the scheduling DCI is configured to indicate the uplink resource allocation type as part of the Frequency domain resource assignment field by setting a higher layer parameter resourceAllocation in pusch-Config to ‘dynamicswitch’, the UE shall use uplink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the uplink frequency resource allocation type as defined by the higher layer parameter resourceAllocation.
The UE shall assume that when the scheduling PDCCH is received with DCI format 0_0, then uplink resource allocation type 1 is used.
If a bandwidth part indicator field is not configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s active bandwidth part. If a bandwidth part indicator field is configured in the scheduling DCI, the RB indexing for uplink type 0 and type 1 resource allocation is determined within the UE’s bandwidth part indicated by bandwidth part indicator field value in the DCI, except for the case when DCI format 0_0 is decoded in any PDCCH common search space in CORESET 0 in which case the initial bandwidth part shall be used. The UE shall upon detection of PDCCH intended for the UE determine first the uplink bandwidth part and then the resource allocation within the bandwidth part.
[38.214 clause 6.1.2.2.2]
n uplink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved virtual resource blocks within the active carrier bandwidth part of size PRBs except for the case when DCI format 0_0 is decoded in the Type0-PDCCH common search space in CORESET 0 in which case the initial bandwidth part of size shall be used.
An uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed.
[TS 38.214, clause 6.1.4.1]
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, or SP-CSI-RNTI, the transform precoding is enabled if transformPrecoder in PUSCH-Config is set to ‘enabled’, or if transformPrecoder in PUSCH-Config is not configured and msg3-transformPrecoding in rach-ConfigCommon is set to ‘enabled’; otherwise the transform precoding is disabled.
For the PUSCH assigned by a DCI format 0_0/0_1 with CRC scrambled by CS-RNTI, or the PUSCH with configured grant using CS-RNTI, the transform precoding is enabled if transformPrecoder in ConfiguredGrantConfig is set to ‘enabled’; otherwise the transform precoding is disabled.
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, TC-RNTI, or CS-RNTI, or SP-CSI-RNTI, or for a PUSCH with configured grant using CS-RNTI,
if transformPrecoder is disabled for this PUSCH transmission
…
else
– if mcs-TableTransformPrecoder in PUSCH-Config is set to ‘qam256’, and the PUSCH is scheduled with C-RNTI or SP-CSI-RNTI, and PUSCH is assigned by DCI format 0_1,
– the UE shall use IMCS and Table 5.1.3.1.-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is not configured with new-RNTI, mcs-TableTransformPrecoder in PUSCH-Config is set to ‘qam64LowSE’, and the PUSCH is scheduled with C-RNTI, or SP-CSI-RNTI, and the PUSCH is assigned by a PDCCH in a UE-specific search space,
– the UE shall use IMCS and Table 6.1.4.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif the UE is configured with new-RNTI, and the PUSCH is scheduled with new-RNTI,
– the UE shall use IMCS and Table 6.1.4.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-TableTransformPrecoder in ConfiguredGrantConfig is set to ‘qam256’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– elseif mcs-TableTransformPrecoder in ConfiguredGrantConfig is set to ‘qam64LowSE’, and PUSCH is scheduled with CS-RNTI,
– the UE shall use IMCS and Table 6.1.4.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
– else
– the UE shall use IMCS and Table 6.1.4.1-1to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
end
For Table 6.1.4.1-1 and Table 6.1.4.1-2, if higher layer parameter PUSCH-tp-pi2BPSK is configured, q = 1 otherwise q=2.
Table 6.1.4.1-1: MCS index table for PUSCH with transform precoding and 64QAM
MCS Index |
Modulation Order |
Target code Rate R x 1024 |
Spectral efficiency |
0 |
q |
240/ q |
0.2344 |
1 |
q |
314/ q |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
|
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
466 |
2.7305 |
18 |
6 |
517 |
3.0293 |
19 |
6 |
567 |
3.3223 |
20 |
6 |
616 |
3.6094 |
21 |
6 |
666 |
3.9023 |
22 |
6 |
719 |
4.2129 |
23 |
6 |
772 |
4.5234 |
24 |
6 |
822 |
4.8164 |
25 |
6 |
873 |
5.1152 |
26 |
6 |
910 |
5.3320 |
27 |
6 |
948 |
5.5547 |
28 |
q |
reserved |
|
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 6.1.4.2]
For a PUSCH scheduled by RAR UL grant or for a PUSCH scheduled by a DCI format 0_0/0_1 with CRC scrambled by C-RNTI, new-RNTI, TC-RNTI, CS-RNTI, or SP-CSI-RNTI.
if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is disabled and a table other than Table 5.1.3.1-2 is used, or
– and transform precoding is enabled, the UE shall first determine the TBS as specified below:
The UE shall first determine the number of REs (NRE) within the slot:
– A UE first determines the number of REs allocated for PUSCH within a PRB by
– , where is the number of subcarriers in the frequency domain in a physical resource block, is the number of symbols of the PUSCH allocation within the slot, is the number of REs for DM-RS per PRB in the scheduled duration including the overhead of the DM-RS CDM groups without data, as indicated by DCI format 0_1 or as described for DCI format 0_0 in Subclause 6.2.2, and is the overhead configured by higher layer parameter xOverhead in PUSCH-ServingCellConfig. If the is not configured (a value from 0, 6, 12, or 18), the is assumed to be 0. For MSG3 transmission the is always set to 0.
– A UE determines the total number of REs allocated for PUSCH by where is the total number of allocated PRBs for the UE.
– Next, proceed with steps 2-4 as defined in Subclause 5.1.3.2
else if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is enabled,
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
else
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant, the TBS shall be determined from the most recent configured scheduling PDCCH.
[TS 38.214, clause 5.1.3.2]
2) Intermediate number of information bits (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-2 find the closest TBS that is not less than .
Table 5.1.3.2-2: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.2.5.3 Test description
7.1.1.4.2.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value) and Short_DCI condition is applied in NR Serving cell configuration.
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest mandatory UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.2.5.3.2 Test procedure sequence
Table 7.1.1.4.2.5.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.2.5.3.2-2: Number of uplink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
|||
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
|||
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
|||
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
|||
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
|||
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
|||
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
|||
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
|||
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
|||
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
|||
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
|||
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
|||
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
|||
144921 ≤ TBS ≤ 156992 |
13 |
8*FLOOR((TBS – 992)/104) |
|||
156993 ≤ TBS ≤ 169064 |
14 |
8*FLOOR((TBS – 1064)/112) |
|||
169065 ≤ TBS ≤ 181136 |
15 |
8*FLOOR((TBS – 1136)/120) |
|||
181137 ≤ TBS ≤ 193208 |
16 |
8*FLOOR((TBS – 1208)/128) |
|||
193209 ≤ TBS ≤ 205280 |
17 |
8*FLOOR((TBS – 1280)/136) |
|||
205281 ≤ TBS ≤ 217352 |
18 |
8*FLOOR((TBS – 1352)/144) |
|||
217353 ≤ TBS ≤ 229424 |
19 |
8*FLOOR((TBS – 1424)/152) |
|||
TBS> 229424 |
20 |
8*FLOOR((TBS – 1496)/160) |
|||
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.2.5.3.2-3: Specific Parameters
Parameter |
Value |
Comment |
number of layers (ʋ) |
1 |
|
transformPrecoder |
enabled |
Table 7.1.1.4.2.5.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of 1 to in BWP, time domain resource as per Table 7.1.1.4.2.0-1 and from 0 to 27. |
– |
– |
– |
– |
1 |
The SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.5.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.5.3.2-2 Skip the execution of steps 2 to 5 for which the TBS size equal to 3824 or 3840. (Note 1) Skip the execution of steps 1 to 5 for > 27 and < 5. (Note2) |
– |
– |
– |
– |
2 |
The SS creates one or more PDCP SDUs, depending on TBS, in accordance with Table 7.1.1.4.2.5.3.2-2. |
– |
– |
– |
– |
3 |
The SS transmits all PDCP SDUs (NSDUs) as created in step 2 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
4 |
After the reception of 2 Scheduling Request , SS transmits UL Grant DCI 0_0, and values of S, L,and nPRB. |
<– |
(UL Grant) (DCI Format 0_0, S, L,and nPRB.) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 4? |
–> |
MAC PDU (N x PDCP SDU) |
1 |
P |
Note 1: There is ambiguity of TBS calculation when 3824.0 < Ninfo < 3825.0 in clause 5.1.3.2 of TS 38.214 [15]. Note 2: For > 27 and < 5, the resulting TBS is very small leading to CRC errors in decoding UL data. |
7.1.1.4.2.5.3.3 Specific message contents
None.
7.1.1.4.2.6 UL-SCH Transport Block Size selection / DCI format 0_2
7.1.1.4.2.6.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE has pending data for transmission and receives on PDCCH DCI format 0_2 indicating a resource block assignment correspondent to physical resource blocks , Time domain resource assignment and modulation and coding}
then { UE transmits MAC PDU on PUSCH as per Modulation Coding scheme, time domain resource allocation and PRB’s }
}
7.1.1.4.2.6.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212 clause 7.3.1.1.3, TS 38.214 clause 6.1.2.1, 6.1.2.2, 6.1.2.2.1, 6.1.2.2.2, 6.1.4.1, 5.1.3.1, 6.1.4.2 and 5.1.3.2. Unless otherwise stated these are Rel-16 requirements.
[TS 38.212, clause 7.3.1.1.3]
DCI format 0_2 is used for the scheduling of PUSCH in one cell.
The following information is transmitted by means of the DCI format 0_2 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Carrier indicator – 0, 1, 2 or 3 bits determined by higher layer parameter carrierIndicatorSizeDCI-0-2, as defined in Clause 10.1 of [5, TS38.213].
– UL/SUL indicator – 0 bit for UEs not configured with supplementaryUplink in ServingCellConfig in the cell or UEs configured with supplementaryUplink in ServingCellConfig in the cell but only one carrier in the cell is configured for PUSCH transmission; otherwise, 1 bit as defined in Table 7.3.1.1.1-1.
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of UL BWPs configured by higher layers, excluding the initial UL bandwidth part. The bitwidth for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the ascending order of the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
– Frequency domain resource assignment – number of bits determined by the following:
– bits if only resource allocation type 0 is configured, where is defined in Clause 6.1.2.2.1 of [6, TS 38.214]
– bits if only resource allocation type 1 is configured, or bits if resourceAllocationDCI-0-2-r16 is configured as ‘dynamicSwitch’, where is the size of the active UL bandwidth part, is defined as in clause 4.4.4.4 of [4, TS 38.211] and is given by higher layer parameter resourceAllocationType1GranularityDCI-0-2. If the higher layer parameter resourceAllocationType1GranularityDCI-0-2 is not configured, is equal to 1.
– If resourceAllocationDCI-0-2-r16 is configured as ‘dynamicSwitch’, the MSB bit is used to indicate resource allocation type 0 or resource allocation type 1, where the bit value of 0 indicates resource allocation type 0 and the bit value of 1 indicates resource allocation type 1.
– For resource allocation type 0, the LSBs provide the resource allocation as defined in Clause 6.1.2.2.1 of [6, TS 38.214].
– For resource allocation type 1, the LSBs provide the resource allocation as follows:
– For PUSCH hopping with resource allocation type 1:
– MSB bits are used to indicate the frequency offset according to Clause 6.3 of [6, TS 38.214], where if the higher layer parameter frequencyHoppingOffsetListsDCI-0-2 contains two offset values and if the higher layer parameter frequencyHoppingOffsetListsDCI-0-2 contains four offset values
– bits provide the frequency domain resource allocation according to Clause 6.1.2.2.2 of [6, TS 38.214]
– For non-PUSCH hopping with resource allocation type 1:
– bits provide the frequency domain resource allocation according to Clause 6.1.2.2.2 of [6, TS 38.214]
If "Bandwidth part indicator" field indicates a bandwidth part other than the active bandwidth part and if resourceAllocationDCI-0-2-r16 is configured as ‘dynamicSwitch’ for the indicated bandwidth part, the UE assumes resource allocation type 0 for the indicated bandwidth part if the bitwidth of the "Frequency domain resource assignment" field of the active bandwidth part is smaller than the bitwidth of the "Frequency domain resource assignment" field of the indicated bandwidth part.
– Time domain resource assignment – 0, 1, 2, 3, 4, 5 or 6 bits as defined in Clause 6.1.2.1 of [6, TS38.214]. The bitwidth for this field is determined as bits, where I is the number of entries in the higher layer parameter pusch-TimeDomainAllocationListDCI-0-2 if the higher layer parameter is configured, or I is the number of entries in the higher layer parameter PUSCH-TimeDomainResourceAllocationList if the higher layer parameter PUSCH-TimeDomainResourceAllocationList is configured and the higher layer parameter pusch-TimeDomainAllocationListDCI-0-2 is not configured; otherwise I is the number of entries in the default table.
– Frequency hopping flag – 0 or 1 bit:
– 0 bit if the higher layer parameter frequencyHoppingDCI-0-2 is not configured;
– 1 bit according to Table 7.3.1.1.1-3 otherwise, only applicable to resource allocation type 1, as defined in Clause 6.3 of [6, TS 38.214].
– Modulation and coding scheme –5 bits as defined in Clause 6.1.4.1 of [6, TS 38.214]
– New data indicator – 1 bit
– Redundancy version – 0, 1 or 2 bits determined by higher layer parameter numberOfBitsForRV-DCI-0-2
– If 0 bit is configured, rvid to be applied is 0;
– 1 bit according to Table 7.3.1.2.3-1;
– 2 bits according to Table 7.3.1.1.1-2.
– HARQ process number – 0, 1, 2, 3 or 4 bits determined by higher layer parameter harq-ProcessNumberSizeDCI-0-2
– Downlink assignment index – 0, 1, 2 or 4 bits
– 0 bit if the higher layer parameter downlinkAssignmentIndexDCI-0-2 is not configured;
– 1, 2 or 4 bits otherwise,
– 1st downlink assignment index – 1 or 2 bits:
– 1 bit for semi-static HARQ-ACK codebook;
– 2 bits for dynamic HARQ-ACK codebook.
– 2nd downlink assignment index – 0 or 2 bits
– 2 bits for dynamic HARQ-ACK codebook with two HARQ-ACK sub-codebooks;
– 0 bit otherwise.
When two HARQ-ACK codebooks are configured for the same serving cell and if higher layer parameter priorityIndicatorDCI-0-2 is configured, if the bit width of the Downlink assignment index in DCI format 0_2 for one HARQ-ACK codebook is not equal to that of the Downlink assignment index in DCI format 0_2 for the other HARQ-ACK codebook, a number of most significant bits with value set to ‘0’ are inserted to smaller Downlink assignment index until the bit width of the Downlink assignment index in DCI format 0_2 for the two HARQ-ACK codebooks are the same.
– TPC command for scheduled PUSCH – 2 bits as defined in Clause 7.1.1 of [5, TS38.213]
– SRS resource indicator – or bits, where is the number of configured SRS resources in the SRS resource set configured by higher layer parameter srs-ResourceSetToAddModListDCI-0-2, and associated with the higher layer parameter usage of value ‘codeBook‘ or ‘nonCodeBook‘,
– bits according to Tables 7.3.1.1.2-28/29/30/31 if the higher layer parameter txConfig = nonCodebook, where is the number of configured SRS resources in the SRS resource set configured by higher layer parameter srs-ResourceSetToAddModListDCI-0-2, and associated with the higher layer parameter usage of value ‘nonCodeBook‘ and
– if UE supports operation with maxMIMO-LayersDCI-0-2 and the higher layer parameter maxMIMO-LayersDCI-0-2 of PUSCH-ServingCellConfig of the serving cell is configured, Lmax is given by that parameter
– otherwise, Lmax is given by the maximum number of layers for PUSCH supported by the UE for the serving cell for non-codebook based operation.
– bits according to Tables 7.3.1.1.2-32 if the higher layer parameter txConfig = codebook, where is the number of configured SRS resources in the SRS resource set configured by higher layer parameter srs-ResourceSetToAddModListDCI-0-2, and associated with the higher layer parameter usage of value ‘codeBook‘.
– Precoding information and number of layers – number of bits determined by the following:
– 0 bits if the higher layer parameter txConfig = nonCodeBook;
– 0 bits for 1 antenna port and if the higher layer parameter txConfig = codebook;
– 4, 5, or 6 bits according to Table 7.3.1.1.2-2 for 4 antenna ports, if txConfig = codebook, ul-FullPowerTransmission is not configured or configured to fullpowerMode2 or configured to fullpower, and according to whether transform precoder is enabled or disabled, and the values of higher layer parameters maxRankDCI-0-2, and codebookSubsetDCI-0-2;
– 4 or 5 bits according to Table 7.3.1.1.2-2A for 4 antenna ports, if txConfig = codebook, ul-FullPowerTransmission =fullpowerMode1, the values of higher layer parameters maxRankDCI-0-2=2, transform precoder is disabled, and according to the value of higher layer parameter codebookSubsetDCI-0-2;
– 4 or 6 bits according to Table 7.3.1.1.2-2B for 4 antenna ports, if txConfig = codebook, ul-FullPowerTransmission =fullpowerMode1, the values of higher layer parameters maxRankDCI-0-2=3 or 4, transform precoder is disabled, and according to the value of higher layer parameter codebookSubsetDCI-0-2;
– 2, 4, or 5 bits according to Table 7.3.1.1.2-3 for 4 antenna ports, if txConfig = codebook, ul-FullPowerTransmission is not configured or configured to fullpowerMode2 or configured to fullpower, and according to whether transform precoder is enabled or disabled, and the values of higher layer parameters maxRankDCI-0-2 and codebookSubsetDCI-0-2;
– 3 or 4 bits according to Table 7.3.1.1.2-3A for 4 antenna ports, if txConfig = codebook, ul-FullPowerTransmission =fullpowerMode1, maxRankDCI-0-2=1, and according to whether transform precoder is enabled or disabled, and the value of higher layer parameter codebookSubsetDCI-0-2;
– 2 or 4 bits according to Table7.3.1.1.2-4 for 2 antenna ports, if txConfig = codebook, ul-FullPowerTransmission is not configured or configured to fullpowerMode2 or configured to fullpower, and according to whether transform precoder is enabled or disabled, and the values of higher layer parameters maxRankDCI-0-2 and codebookSubsetDCI-0-2;
– 2 bits according to Table 7.3.1.1.2-4A for 2 antenna ports, if txConfig = codebook, ul-FullPowerTransmission =fullpowerMode1, transform precoder is disabled, the maxRankDCI-0-2=2, and codebookSubsetDCI-0-2=nonCoherent;
– 1 or 3 bits according to Table7.3.1.1.2-5 for 2 antenna ports, if txConfig = codebook, ul-FullPowerTransmission is not configured or configured to fullpowerMode2 or configured to fullpower, and according to whether transform precoder is enabled or disabled, and the values of higher layer parameters maxRankDCI-0-2 and codebookSubsetDCI-0-2;
– 2 bits according to Table 7.3.1.1.2-5A for 2 antenna ports, if txConfig = codebook, ul-FullPowerTransmission =fullpowerMode1, maxRankDCI-0-2=1, and according to whether transform precoder is enabled or disabled, and the value of higher layer parameter codebookSubsetDCI-0-2.
For the higher layer parameter txConfig=codebook, if ul-FullPowerTransmission is configured to fullpowerMode2, the values of higher layer parameters maxRankDCI-0-2 is configured to be larger than 2, and at least one SRS resource with 4 antenna ports is configured in an SRS resource set with usage set to ‘codebook’ and an SRS resource with 2 antenna ports is indicated via SRI in the same SRS resource set, then Table 7.3.1.1.2-4 is used.
For the higher layer parameter txConfig = codebook, if different SRS resources with different number of antenna ports are configured, the bitwidth is determined according to the maximum number of ports in an SRS resource among the configured SRS resources in an SRS resource set with usage set to ‘codebook’. If the number of ports for a configured SRS resource in the set is less than the maximum number of ports in an SRS resource among the configured SRS resources, a number of most significant bits with value set to ‘0’ are inserted to the field.
– Antenna ports – number of bits determined by the following:
– 0 bit if higher layer parameter antennaPortsFieldPresenceDCI-0-2 is not configured;
– 2, 3, 4, or 5 bits otherwise,
– 2 bits as defined by Tables 7.3.1.1.2-6, if transform precoder is enabled, dmrs-Type=1, and maxLength=1, except that dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured and π/2 BPSK modulation is used;
– 2 bits as defined by 7.3.1.1.2-6A, if transform precoder is enabled, and dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured, π/2 BPSK modulation is used, dmrs-Type=1, and maxLength=1, where nSCID is the scrambling identity for antenna ports defined in Clause 6.4.1.1.1.2, in [4, TS38.211];
– 4 bits as defined by Tables 7.3.1.1.2-7, if transform precoder is enabled, dmrs-Type=1, and maxLength=2, except that dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured and π/2 BPSK modulation is used;
– 4 bits as defined by Tables 7.3.1.1.2-7A, if transform precoder is enabled, and dmrs-UplinkTransformPrecoding and tp-pi2BPSK are both configured, π/2 BPSK modulation is used, dmrs-Type=1, and maxLength=2, where nSCID is the scrambling identity for antenna ports defined in Clause 6.4.1.1.1.2, in [4, TS38.211];
– 3 bits as defined by Tables 7.3.1.1.2-8/9/10/11, if transform precoder is disabled, dmrs-Type=1, and maxLength=1, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 4 bits as defined by Tables 7.3.1.1.2-12/13/14/15, if transform precoder is disabled, dmrs-Type=1, and maxLength=2, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 4 bits as defined by Tables 7.3.1.1.2-16/17/18/19, if transform precoder is disabled, dmrs-Type=2, and maxLength=1, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook;
– 5 bits as defined by Tables 7.3.1.1.2-20/21/22/23, if transform precoder is disabled, dmrs-Type=2, and maxLength=2, and the value of rank is determined according to the SRS resource indicator field if the higher layer parameter txConfig = nonCodebook and according to the Precoding information and number of layers field if the higher layer parameter txConfig = codebook.
where the number of CDM groups without data of values 1, 2, and 3 in Tables 7.3.1.1.2-6 to 7.3.1.1.2-23 refers to CDM groups {0}, {0,1}, and {0, 1,2} respectively.
If a UE is configured with both dmrs-UplinkForPUSCH-MappingTypeA-DCI-0-2 and dmrs-UplinkForPUSCH-MappingTypeB-DCI-0-2 and is configured with antennaPortsFieldPresenceDCI-0-2, the bitwidth of this field equals , where is the "Antenna ports" bitwidth derived according to dmrs-UplinkForPUSCH-MappingTypeA-DCI-0-2 and is the "Antenna ports" bitwidth derived according to dmrs-UplinkForPUSCH-MappingTypeB-DCI-0-2. A number of zeros are padded in the MSB of this field, if the mapping type of the PUSCH corresponds to the smaller value of and .
If a UE is not configured with higher layer parameter antennaPortsFieldPresenceDCI-0-2, antenna port(s) are defined assuming bit field index value 0 in Tables 7.3.1.1.2-6 to 7.3.1.1.2-23.
– SRS request – 0, 1, 2 or 3 bits
– 0 bit if the higher layer parameter srs-RequestDCI-0-2 is not configured;
– 1 bit as defined by Table 7.3.1.1.3-1 if higher layer parameter srs-RequestDCI-0-2 = 1 and for UEs not configured with supplementaryUplink in ServingCellConfig in the cell;
– 2 bits if higher layer parameter srs-RequestDCI-0-2 = 1 and for UEs configured with supplementaryUplink in ServingCellConfig in the cell, where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second bit is defined by Table 7.3.1.1.3-1;
– 2 bits as defined by Table 7.3.1.1.2-24 if higher layer parameter srs-RequestDCI-0-2 = 2 and for UEs not configured with supplementaryUplink in ServingCellConfig in the cell;
– 3 bits if higher layer parameter srs-RequestDCI-0-2 = 2 and for UEs configured with supplementaryUplink in ServingCellConfig in the cell, where the first bit is the non-SUL/SUL indicator as defined in Table 7.3.1.1.1-1 and the second and third bits are defined by Table 7.3.1.1.2-24;
– CSI request – 0, 1, 2, 3, 4, 5, or 6 bits determined by higher layer parameter reportTriggerSizeDCI-0-2.
– PTRS-DMRS association – number of bits determined as follows
– 0 bit if PTRS-UplinkConfig is not configured in either dmrs-UplinkForPUSCH-MappingTypeA or dmrs-UplinkForPUSCH-MappingTypeB and transform precoder is disabled, or if transform precoder is enabled, or if maxRankDCI-0-2=1;
– 2 bits otherwise, where Table 7.3.1.1.2-25 and 7.3.1.1.2-26 are used to indicate the association between PTRS port(s) and DMRS port(s) when one PT-RS port and two PT-RS ports are configured by maxNrofPorts in PTRS-UplinkConfig respectively, and the DMRS ports are indicated by the Antenna ports field.
If "Bandwidth part indicator" field indicates a bandwidth part other than the active bandwidth part and the "PTRS-DMRS association" field is present for the indicated bandwidth part but not present for the active bandwidth part, the UE assumes the "PTRS-DMRS association" field is not present for the indicated bandwidth part.
– beta_offset indicator – 0 bit if the higher layer parameter betaOffsets = semiStatic; otherwise 1 bit if 2 offset indexes are configured by higher layer parameter dynamicDCI-0-2 as defined by Table 9.3-3A in [5, TS 38.213], and 2 bits if 4 offset indexes are configured by higher layer parameter dynamicDCI-0-2 as defined by Table 9.3-3 in [5, TS 38.213].
When two HARQ-ACK codebooks are configured for the same serving cell and if higher layer parameter priorityIndicatorDCI-0-2 is configured, if the bit width of the beta_offset indicator in DCI format 0_2 for one HARQ-ACK codebook is not equal to that of the beta_offset indicator in DCI format 0_2 for the other HARQ-ACK codebook, a number of most significant bits with value set to ‘0’ are inserted to smaller beta_offset indicator until the bit width of the beta_offset indicator in DCI format 0_2 for the two HARQ-ACK codebooks are the same.
– DMRS sequence initialization – 0 or 1 bit
– 0 bit if the higher layer parameter dmrs-SequenceInitializationDCI-0-2 is not configured or if transform precoder is enabled;
– 1 bit if transform precoder is disabled and the higher layer parameter dmrs-SequenceInitializationDCI-0-2 is configured.
– UL-SCH indicator – 1 bit. A value of "1" indicates UL-SCH shall be transmitted on the PUSCH and a value of "0" indicates UL-SCH shall not be transmitted on the PUSCH. Except for DCI format 0_2 with CRC scrambled by SP-CSI-RNTI, a UE is not expected to receive a DCI format 0_2 with UL-SCH indicator of "0" and CSI request of all zero(s).
– Open-loop power control parameter set indication – 0 or 1 or 2 bits.
– 0 bit if the higher layer parameter p0-PUSCH-SetList is not configured;
– 1 or 2 bits otherwise,
– 1 bit if SRS resource indicator is present in the DCI format 0_2;
– 1 or 2 bits as determined by higher layer parameter olpc-ParameterSetDCI-0-2 if SRS resource indicator is not present in the DCI format 0_2;
– Priority indicator – 0 bit if higher layer parameter priorityIndicatorDCI-0-2 is not configured; otherwise 1 bit as defined in Clause 9 in [5, TS 38.213].
– Invalid symbol pattern indicator – 0 bit if higher layer parameter invalidSymbolPatternIndicatorDCI-0-2 is not configured; otherwise 1 bit as defined in Clause 6.1.2.1 in [6, TS 38.214].
A UE does not expect that the bit width of a field in DCI format 0_2 with CRC scrambled by CS-RNTI is larger than corresponding bit width of same field in DCI format 0_2 with CRC scrambled by C-RNTI for the same serving cell. If the bit width of a field in the DCI format 0_2 with CRC scrambled by CS-RNTI is not equal to that of the corresponding field in the DCI format 0_2 with CRC scrambled by C-RNTI for the same serving cell, a number of most significant bits with value set to ‘0’ are inserted to the field in DCI format 0_2 with CRC scrambled by CS-RNTI until the bit width equals that of the corresponding field in the DCI format 0_2 with CRC scrambled by C-RNTI for the same serving cell.
Table 7.3.1.1.3-1: 1 bit SRS request in DCI format 0_2 and DCI format 1_2
Value of SRS request field |
Triggered aperiodic SRS resource set(s) for DCI format 0_2 and 1_2 |
0 |
No aperiodic SRS resource set triggered |
1 |
SRS resource set(s) configured with higher layer parameter aperiodicSRS-ResourceTrigger set to 1 or an entry in aperiodicSRS-ResourceTriggerList set to 1 |
[TS 38.214, clause 6.1.2.1]
When the UE is scheduled to transmit a transport block and no CSI report, or the UE is scheduled to transmit a transport block and a CSI report(s) on PUSCH by a DCI, the ‘Time domain resource assignment’ field value m of the DCI provides a row index m + 1 to an allocated table. The determination of the used resource allocation table is defined in Clause 6.1.2.1.1. The indexed row defines the slot offset K2, the start and length indicator SLIV, or directly the start symbol S and the allocation length L, the PUSCH mapping type, and the number of repetitions (if numberOfRepetitions is present in the resource allocation table) to be applied in the PUSCH transmission.
When the UE is scheduled to transmit a PUSCH with no transport block and with a CSI report(s) by a ‘CSI request’ field on a DCI, the ‘Time domain resource assignment’ field value m of the DCI provides a row index m + 1 to the allocated table as defined in Clause 6.1.2.1.1. The indexed row defines the start and length indicator SLIV, or directly the start symbol S and the allocation length L, and the PUSCH mapping type to be applied in the PUSCH transmission and the K2 value is determined as , where are the corresponding list entries of the higher layer parameter
– reportSlotOffsetListDCI-0-2, if PUSCH is scheduled by DCI format 0_2 and reportSlotOffsetListDCI-0-2 is configured;
– reportSlotOffsetListDCI-0-1, if PUSCH is scheduled by DCI format 0_1 and reportSlotOffsetListDCI-0-1 is configured;
– reportSlotOffsetList, otherwise;
in CSI-ReportConfig for the triggered CSI Reporting Settings and is the (m+1)th entry of .
– The slot Ks where the UE shall transmit the PUSCH is determined by K2 as Ks =, if UE is configured with ca-SlotOffset for at least one of the scheduled and scheduling cell, Ks =, otherwise, and where n is the slot with the scheduling DCI, K2 is based on the numerology of PUSCH, and and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively,
– and are the and the, respectively, which are determined by higher-layer configured ca-SlotOffset for the cell receiving the PDCCH, and are the and the,respectively, which are determined by higher-layer configured ca-SlotOffset for the cell transmitting the PUSCH, as defined in clause 4.5 of [4, TS 38.211], and
– for PUSCH scheduled by DCI format 0_1, if pusch-RepTypeIndicatorDCI-0-1 is set to ‘pusch-RepTypeB’, the UE applies PUSCH repetition Type B procedure when determining the time domain resource allocation. For PUSCH scheduled by DCI format 0_2, if pusch-RepTypeIndicatorDCI-0-2 is set to ‘pusch-RepTypeB’, the UE applies PUSCH repetition Type B procedure when determining the time domain resource allocation. Otherwise, the UE applies PUSCH repetition Type A procedure when determining the time domain resource allocation for PUSCH scheduled by PDCCH.
– For PUSCH repetition Type A, the starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are determined from the start and length indicator SLIV of the indexed row:
if then
else
where, and
– For PUSCH repetition Type B, the starting symbol S relative to the start of the slot, and the number of consecutive symbols L counting from the symbol S allocated for the PUSCH are provided by startSymbol and length of the indexed row of the resource allocation table, respectively.
– For PUSCH repetition Type A, the PUSCH mapping type is set to Type A or Type B as defined in Clause 6.4.1.1.3 of [4, TS 38.211] as given by the indexed row.
– For PUSCH repetition Type B, the PUSCH mapping type is set to Type B.
The UE shall consider the S and L combinations defined in table 6.1.2.1-1 as valid PUSCH allocations
Table 6.1.2.1-1: Valid S and L combinations
PUSCH mapping type |
Normal cyclic prefix |
Extended cyclic prefix |
||||
S |
L |
S+L |
S |
L |
S+L |
|
Type A (repetition Type A only) |
0 |
{4,…,14} |
{4,…,14} |
0 |
{4,…,12} |
{4,…,12} |
Type B |
{0,…,13} |
{1,…,14} |
{1,…,14} for repetition Type A, {1,…,27} for repetition Type B |
{0,…, 11} |
{1,…,12} |
{1,…,12} for repetition Type A, {1,…,23} for repetition Type B |
For PUSCH repetition Type A, when transmitting PUSCH scheduled by DCI format 0_1 or 0_2 in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1, the number of repetitions K is determined as
– if numberOfRepetitions is present in the resource allocation table, the number of repetitions K is equal to numberOfRepetitions;
– elseif the UE is configured with pusch-AggregationFactor, the number of repetitions K is equal to pusch-AggregationFactor;
– otherwise K=1.
If a UE is configured with higher layer parameter pusch-TimeDomainAllocationListForMultiPUSCH, the UE does not expect to be configured with pusch-AggregationFactor.
For PUSCH repetition Type A, in case K>1, the same symbol allocation is applied across the K consecutive slots and the PUSCH is limited to a single transmission layer. The UE shall repeat the TB across the K consecutive slots applying the same symbol allocation in each slot. The redundancy version to be applied on the nth transmission occasion of the TB, where n = 0, 1, … K-1, is determined according to table 6.1.2.1-2.
Table 6.1.2.1-2: Redundancy version for PUSCH transmission
rvid indicated by the DCI scheduling the PUSCH |
rvid to be applied to nth transmission occasion (repetition Type A) or nth actual repetition (repetition Type B) |
|||
n mod 4 = 0 |
n mod 4 = 1 |
n mod 4 = 2 |
n mod 4 = 3 |
|
0 |
0 |
2 |
3 |
1 |
2 |
2 |
3 |
1 |
0 |
3 |
3 |
1 |
0 |
2 |
1 |
1 |
0 |
2 |
3 |
[38.214 clause 6.1.2.2]
The UE shall determine the resource block assignment in frequency domain using the resource allocation field in the detected PDCCH DCI except for a PUSCH transmission scheduled by a RAR UL grant or fallbackRAR UL grant, in which case the frequency domain resource allocation is determined according to clause 8.3 of [6, 38.213] or a MsgA PUSCH transmission with frequency domain resource allocation determined according to clause 8.1A of [6, 38.213]. Three uplink resource allocation schemes type 0, type 1 and type 2 are supported. Uplink resource allocation scheme type 0 is supported for PUSCH only when transform precoding is disabled. Uplink resource allocation scheme type 1 and type 2 are supported for PUSCH for both cases when transform precoding is enabled or disabled.
If the scheduling DCI is configured to indicate the uplink resource allocation type as part of the ‘Frequency domain resource’ assignment field by setting a higher layer parameter resourceAllocation in pusch-Config to ‘dynamicSwitch’, for DCI format 0_1 or setting a higher layer parameter resourceAllocationDCI-0-2 in pusch-Config to ‘dynamicSwitch’ for DCI format 0_2, the UE shall use uplink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the uplink frequency resource allocation type as defined by the higher layer parameter resourceAllocation for DCI format 0_1 or the higher layer parameter resourceAllocationDCI-0-2 for DCI format 0_2. The UE shall assume that when the scheduling PDCCH is received with DCI format 0_1 and useInterlacePUCCH-PUSCH in BWP-UplinkDedicated is configured, uplink type 2 resource allocation is used.
The UE shall assume that when the scheduling PDCCH is received with DCI format 0_0, then uplink resource allocation type 1 is used, except when any of the higher layer parameters useInterlacePUCCH-PUSCH in BWP-UplinkCommon and useInterlacePUCCH-PUSCH in BWP-UplinkDedicated is configured in which case uplink resource allocation type 2 is used.
The UE expects that either none or both of useInterlacePUCCH-PUSCH in BWP-UplinkCommon and useInterlacePUCCH-PUSCH in BWP-UplinkDedicated is configured.
If a bandwidth part indicator field is not configured in the scheduling DCI or the UE does not support active bandwidth part change via DCI, the RB indexing for uplink type 0, type 1 and type 2 resource allocation is determined within the UE’s active bandwidth part. If a bandwidth part indicator field is configured in the scheduling DCI and the UE supports active bandwidth part change via DCI, the RB indexing for uplink type 0, type 1, type 2 resource allocation is determined within the UE’s bandwidth part indicated by bandwidth part indicator field value in the DCI. The UE shall upon detection of PDCCH intended for the UE determine first the uplink bandwidth part and then the resource allocation within the bandwidth part. RB numbering starts from the lowest RB in the determined uplink bandwidth part.
[38.214 clause 6.1.2.2.1]
In uplink resource allocation of type 0, the resource block assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE where a RBG is a set of consecutive virtual resource blocks defined by higher layer parameter rbg-Size configured in pusch-Config and the size of the bandwidth part as defined in Table 6.1.2.2.1-1.
Table 6.1.2.2.1-1: Nominal RBG size P
Bandwidth Part Size |
Configuration 1 |
Configuration 2 |
1 – 36 |
2 |
4 |
37 – 72 |
4 |
8 |
73 – 144 |
8 |
16 |
145 – 275 |
16 |
16 |
[38.214 clause 6.1.2.2.2]
In uplink resource allocation of type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved virtual resource blocks within the active bandwidth part of size PRBs except for the case when DCI format 0_0 is decoded in any common search space in which case the size of the initial UL bandwidth part shall be used.
An uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block () and a length in terms of contiguously allocated resource blocks. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed.
When the DCI size for DCI format 0_0 in USS is derived from the initial UL BWP with size but applied to another active BWP with size of , an uplink type 1 resource block assignment field consists of a resource indication value (RIV) corresponding to a starting resource block and a length in terms of virtually contiguously allocated resource blocks .
The resource indication value is defined by
if then
else
where, and where shall not exceed .
If , K is the maximum value from set {1, 2, 4, 8} which satisfies ; otherwise K = 1.
When the scheduling grant is received with DCI format 0_2, an uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting resource block group RBGstart=0, 1, …, NRBG-1 and a length in terms of virtually contiguously allocated resource block groups LRBGs=1, …, NRBG, where the resource block groups are defined as in 6.1.2.2.1 with P defined by resourceAllocationType1GranularityDCI-0-2 if the UE is configured with higher layer parameter resourceAllocationType1GranularityDCI-0-2, and P=1 otherwise. The resource indication value is defined by
if then
else
where≥ 1 and shall not exceed .
[TS 38.214, clause 6.1.4.1]
For a PUSCH scheduled by RAR UL grant or
for a PUSCH scheduled by a fallbackRAR UL grant or
for a MsgA PUSCH transmission, or
for a PUSCH scheduled by a DCI format 0_0 with CRC scrambled by C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI, or
for a PUSCH scheduled by a DCI format 0_1 or DCI format 0_2 with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI, SP-CSI-RNTI, or
for a PUSCH with configured grant using CS-RNTI, and
if transform precoding is disabled for this PUSCH transmission according to Clause 6.1.3
– if mcs-TableDCI-0-2 in pusch-Config is set to ‘qam256’, and PUSCH is scheduled by a PDCCH with DCI format 0_2 with CRC scrambled by C-RNTI or SP-CSI-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel;
– elseif the UE is not configured with MCS-C-RNTI, mcs-TableDCI-0-2 in pusch-Config is set to ‘qam64LowSE’, and the PUSCH is scheduled by a PDCCH by a PDCCH with DCI format 0_2 with CRC scrambled by C-RNTI or SP-CSI-RNTI,
– the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical uplink shared channel.
[TS 38.214, clause 5.1.3.1]
Table 5.1.3.1-3: MCS index table 3 for PDSCH
MCS Index |
Modulation Order |
Target code Rate R x [1024] |
Spectral efficiency |
0 |
2 |
30 |
0.0586 |
1 |
2 |
40 |
0.0781 |
2 |
2 |
50 |
0.0977 |
3 |
2 |
64 |
0.1250 |
4 |
2 |
78 |
0.1523 |
5 |
2 |
99 |
0.1934 |
6 |
2 |
120 |
0.2344 |
7 |
2 |
157 |
0.3066 |
8 |
2 |
193 |
0.3770 |
9 |
2 |
251 |
0.4902 |
10 |
2 |
308 |
0.6016 |
11 |
2 |
379 |
0.7402 |
12 |
2 |
449 |
0.8770 |
13 |
2 |
526 |
1.0273 |
14 |
2 |
602 |
1.1758 |
15 |
4 |
340 |
1.3281 |
16 |
4 |
378 |
1.4766 |
17 |
4 |
434 |
1.6953 |
18 |
4 |
490 |
1.9141 |
19 |
4 |
553 |
2.1602 |
20 |
4 |
616 |
2.4063 |
21 |
6 |
438 |
2.5664 |
22 |
6 |
466 |
2.7305 |
23 |
6 |
517 |
3.0293 |
24 |
6 |
567 |
3.3223 |
25 |
6 |
616 |
3.6094 |
26 |
6 |
666 |
3.9023 |
27 |
6 |
719 |
4.2129 |
28 |
6 |
772 |
4.5234 |
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
[TS 38.214, clause 6.1.4.2]
For a PUSCH scheduled by RAR UL grant or
for a PUSCH scheduled by fallbackRAR UL grant or
for a PUSCH scheduled by a DCI format 0_0 with CRC scrambled by C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI, or
for a PUSCH scheduled by a DCI format 0_1 or DCI format 0_2 with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI, or
for a PUSCH transmission with configured grant, or
for a MsgA PUSCH transmission,
if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is disabled and a table other than Table 5.1.3.1-2 is used, or
– and transform precoding is enabled, the UE shall first determine the TBS as specified below:
The UE shall first determine the number of REs (NRE) within the slot:
– A UE first determines the number of REs allocated for PUSCH within a PRB by
– , where is the number of subcarriers in the frequency domain in a physical resource block, is the number of symbols L of the PUSCH allocation according to Clause 6.1.2.1 for scheduled PUSCH or Clause 6.1.2.3 for configured PUSCH, is the number of REs for DM-RS per PRB in the allocated duration including the overhead of the DM-RS CDM groups without data, as described for PUSCH with a configured grant in Clause 6.1.2.3 or as indicated by DCI format 0_1 or DCI format 0_2 or as described for DCI format 0_0 in Clause 6.2.2, and is the overhead configured by higher layer parameter xOverhead in PUSCH-ServingCellConfig. If the is not configured (a value from 6, 12, or 18), the is assumed to be 0. For Msg3 or MsgA PUSCH transmission the is always set to 0. In case of PUSCH repetition Type B, is determined assuming a nominal repetition with the duration of L symbols without segmentation.
– A UE determines the total number of REs allocated for PUSCH by where is the total number of allocated PRBs for the UE.
– Next, proceed with steps 2-4 as defined in Clause 5.1.3.2
– For a PUSCH scheduled by fallbackRAR UL grant, UE assumes the TB size determined by the UL grant in the fallbackRAR shall be the same as the TB size used in the corresponding MsgA PUSCH transmission.
else if
– and transform precoding is disabled and Table 5.1.3.1-2 is used, or
– and transform precoding is enabled,
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant,
– the TBS shall be determined from configuredGrantConfig for a configured grant Type 1 PUSCH.
– the TBS shall be determined from the most recent PDCCH scheduling a configured grant Type 2 PUSCH.
else
– the TBS is assumed to be as determined from the DCI transported in the latest PDCCH for the same transport block using . If there is no PDCCH for the same transport block using , and if the initial PUSCH for the same transport block is transmitted with configured grant,
– the TBS shall be determined from configuredGrantConfig for a configured grant Type 1 PUSCH.
– the TBS shall be determined from the most recent PDCCH scheduling a configured grant Type 2 PUSCH.
[TS 38.214, clause 5.1.3.2]
2) Unquantized intermediate variable (Ninfo) is obtained by .
If
Use step 3 as the next step of the TBS determination
else
Use step 4 as the next step of the TBS determination
end if
3) When , TBS is determined as follows
– quantized intermediate number of information bits , where .
– use Table 5.1.3.2-1 find the closest TBS that is not less than .
Table 5.1.3.2-1: TBS for
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
4) When , TBS is determined as follows.
– quantized intermediate number of information bits , where and ties in the round function are broken towards the next largest integer.
– if
, where
else
if
, where
else
end if
end if
7.1.1.4.2.6.3 Test description
7.1.1.4.2.6.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except set the NR Cell bandwidth and applicable BWP to maximum for the NR Band under test as specified in Table 5.3.5-1 in TS 38.101-1 [16] / TS 38.101-2 [17] (to enable testing of nPRB up to maximum value) and Short_DCI condition is applied in NR Serving cell configuration.
Test frequency NRf1 is as specified in TS 38.508-1 [4] clause 4.3.1 using the common highest UL and DL channel bandwidth and using the default subcarrier spacing specified in TS 38.508-1 [4] clause 6.2.3.1.
7.1.1.4.2.6.3.2 Test procedure sequence
Table 7.1.1.4.2.6.3.2-1: Maximum TBS for different UE categories
UE Category |
Maximum number of bits of a UL-SCH transport block received within a TTI |
TS 38.306 [23] clause 4.1.2 require UE without ue-CategoryDL and ue-CategoryUL, to support Max TBS achievable based on max bandwidth of the Band under test. |
Table 7.1.1.4.2.6.3.2-2: Number of uplink PDCP SDUs and PDCP SDU size used as test data
TBS [bits] |
Number of PDCP SDUs |
PDCP SDU size [bits] (Note 1) |
136 ≤ TBS ≤12128 note 2 |
1 |
8*FLOOR((TBS – 128)/8) |
12129 ≤ TBS ≤24200 |
2 |
8*FLOOR((TBS – 200)/16) |
24201 ≤ TBS ≤ 36272 |
3 |
8*FLOOR((TBS – 272)/24) |
36273 ≤ TBS ≤48344 |
4 |
8*FLOOR((TBS – 344)/32) |
48345≤ TBS ≤60416 |
5 |
8*FLOOR((TBS – 416)/40) |
60417 ≤ TBS ≤ 72488 |
6 |
8*FLOOR((TBS –488)/48) |
72489 ≤ TBS ≤84560 |
7 |
8*FLOOR((TBS – 560)/56) |
84561 ≤ TBS ≤96632 |
8 |
8*FLOOR((TBS –632)/64) |
96633< TBS ≤108704 |
9 |
8*FLOOR((TBS –704)/72) |
10705 ≤ TBS ≤120776 |
10 |
8*FLOOR((TBS – 776)/80) |
120777≤ TBS ≤132848 |
11 |
8*FLOOR((TBS –848)/88) |
132849 ≤ TBS ≤ 144920 |
12 |
8*FLOOR((TBS – 920)/96) |
TBS> 144920 |
13 |
8*FLOOR((TBS – 992)/104) |
Note 1: Each PDCP SDU is limited to 1500 octets (to keep below maximum SDU size of ESM as specified in TS 24.301 [21] clause 9.9.4.12). The PDCP SDU size of each PDCP SDU is PDCP SDU size = (TBS – N*PDCP header size – N*AMD PDU header size – N*MAC header size – Size of Timing Advance – RLC Status PDU size- MAC header for RLC Status PDU) / N, where PDCP header size is 24 bits for the RLC AM and 18-bit SN case; MAC header size for AMD PDU = 16 or 24 bits depending on L=8 or 16 bits. Worst case 24 is taken. Size of Timing Advance MAC CE with header is 16 bits (if no Timing Advance and/or RLC status needs to be sent, padding will occur instead). RLC Status PDU size = 24 bits with 1 ACK_SN, With a MAC header of 16 bits. This gives: PDCP SDU size = 8*FLOOR((TBS – N*24- N*24 – N*24 -56 )/(8*N)) bits. Note 2: According to the final PDCP SDU size formula in Note 1, the smallest TBS that can be tested is 136 bits. |
Table 7.1.1.4.2.6.3.2-2A: Void
Table 7.1.1.4.2.6.3.2-3: Specific Parameter
Parameter |
Value |
Comment |
Condition |
mcs-TableDCI-0-2-r16 |
Not Present |
qam64 per default |
|
rbg-Size |
Not present |
configuration 1 applicable |
|
NstartBWP |
0 |
Table 7.1.1.4.2.6.3.2-4: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 to 5 are repeated for allowed values of 1 to in BWP, time domain resource as per Table 7.1.1.4.2.0-1 and from 0 to 28. Skip the execution of steps for = 28 and < 4. (Note 1) |
– |
– |
– |
– |
1 |
The SS calculates or looks up TBS in TS 38.214 [15] based on the value of S, L,and nPRB. |
– |
– |
– |
– |
– |
EXCEPTION: Steps 2 to 5 are performed if TBS is less than or equal to UE capability "Maximum number of UL-SCH transport block bits received within a TTI" as specified in Table 7.1.1.4.2.6.3.2-1 and larger than or equal to 136 bits as specified in Table 7.1.1.4.2.6.3.2-2. Skip the execution of steps 2 to 5 for which the TBS size equal to 3824 or 3840. (Note 2) |
– |
– |
– |
– |
2 |
The SS creates one or more PDCP SDUs, depending on TBS, in accordance with Table 7.1.1.4.2.6.3.2-2. |
– |
– |
– |
– |
3 |
After 300ms, the SS transmits all PDCP SDUs (NSDUs) as created in step 2 in a MAC PDU. |
<– |
MAC PDU (NxPDCP SDUs) |
– |
– |
4 |
After 60ms of step 3, SS transmits UL Grant DCI 0_2, and values of S, L,and nPRB. |
<– |
(UL Grant) (DCI Format 0_2, S, L,and nPRB.) |
– |
– |
5 |
CHECK: Does UE return the same number of PDCP SDUs with same content as transmitted by the SS in step 3 using Time, frequency Resources and modulation and coding scheme as configured by the SS in step 4? |
–> |
MAC PDU (N x PDCP SDU) |
1 |
P |
Note 1: For = 28 and < 4, the resulting TBS is very small leading to CRC errors in decoding UL data. Note 2: There is ambiguity of TBS calculation when 3824.0 < Ninfo < 3825.0 in clause 5.1.3.2 of TS 38.214 [15]. |
7.1.1.4.2.6.3.3 Specific message contents
Table 7.1.1.4.2.6.3.3-1: PUSCH-Config
Derivation Path: TS 38.508-1 [4], table 4.6.3-118 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-Config ::= SEQUENCE { |
|||
dmrs-UplinkForPUSCH-MappingTypeA-DCI-0-2-r16CHOICE { |
|||
setup |
DMRS-UplinkConfig |
||
} |
|||
dmrs-UplinkForPUSCH-MappingTypeB-DCI-0-2-r16CHOICE { |
|||
setup |
DMRS-UplinkConfig |
||
} |
|||
harq-ProcessNumberSizeDCI-0-2-r16 |
4 |
nrofHARQ-ProcessesForPUSCH is 16 |
|
numberOfBitsForRV-DCI-0-2-r16 |
2 |
||
resourceAllocationDCI-0-2-r16 |
resourceAllocationType1 |
||
} |
7.1.1.5 Discontinuous reception
7.1.1.5.0 DRX Common Definitions
FirstSlot is the First DL Slot in the subframe, which is 0 for both FDD and TDD as per default configuration in 38.5081-1[4] TDD-UL-DL-Config Table 4.6.3-192
LastDLSlot is the Last DL Slot in a frame; for FDD numerology =0 it is slot 9, numerology=1 it is slot 19, numerology=2 it is slot 39. For TDD as per default configuration in 38.5081-1[4] TDD-UL-DL-Config Table 4.6.3-192, for numerology =0, it is slot 7, numerology=1 it is slot 16, numerology=3 it is slot 77
LastULSlot is the Last UL Slot in a frame; for FDD/TDD numerology =0 it is slot 9, numerology=1 it is slot 18(Second Last as 2 Consecutive UL Slots), numerology=3 it is slot 79; the PDCCH for UL grant is sent K2= 4 Slot earlier.
7.1.1.5.1 DRX operation / Short cycle not configured / Parameters configured by RRC
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { Long DRX cycle is configured and [(SFN * 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset }
then { UE starts the OnDurationTimer and monitors the PDCCH for OnDurationTimer PDCCH-Occasions}
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { Long DRX cycle is configured and a new DL transmission is indicated on the PDCCH during Active Time }
then { UE starts or restarts the Drx-InactivityTimer and monitors the PDCCH for Drx-InactivityTimer PDCCH occasions starting from the next PDCCH occasion of the PDCCH occasion where the DL new transmission was indicated }
}
(3)
with { UE in RRC_CONNECTED state }
ensure that {
when { Long DRX cycle is configured and if a HARQ RTT Timer expires in this PDCCH Occasion and the data in the soft buffer of the corresponding HARQ process was not successfully decoded }
then { UE starts the drx-RetransmissionTimer-DL for the corresponding HARQ process and monitors the PDCCH for drx-RetransmissionTimer consecutive PDCCH Occasion }
}
(4)
with { UE in RRC_CONNECTED state }
ensure that {
when { Long DRX cycle is configured and an uplink grant for a pending HARQ retransmission can occur in this PDCCH occasion}
then { UE monitors the PDCCH in this PDCCH occasion }
}
7.1.1.5.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.7. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.7]
The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other subclauses of this specification. When in RRC_CONNECTED, if DRX is configured, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this subclause; otherwise the MAC entity shall monitor the PDCCH continuously.
RRC controls DRX operation by configuring the following timers:
– drx-onDurationTimer: the duration at the beginning of a DRX Cycle;
– drx-SlotOffset: the delay before starting the drx-onDurationTimer;
– drx-InactivityTimer: the duration after the PDCCH occasion in which a PDCCH indicates an new UL or DL transmission for the MAC entity;
– drx-RetransmissionTimerDL (per DL HARQ process): the maximum duration until a DL retransmission is received;
– drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;
– drx-LongCycle StartOffset: the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;
– drx-ShortCycle (optional): the Short DRX cycle;
– drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;
– drx-HARQ-RTT-TimerDL (per DL HARQ process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;
– drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity.
When a DRX cycle is configured, the Active Time includes the time while:
– drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in subclause 5.1.5) is running; or
– a Scheduling Request is sent on PUCCH and is pending (as described in subclause 5.4.4); or
– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the random access preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in subclause 5.1.4).
When DRX is configured, the MAC entity shall:
1> if a MAC PDU is received in a configured downlink assignment:
2> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
2> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
1> if a MAC PDU is transmitted in a configured uplink grant:
2> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
2> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
1> if a drx-HARQ-RTT-TimerDL expires:
2> if the data of the corresponding HARQ process was not successfully decoded:
3> start the drx-RetransmissionTimerDL for the corresponding HARQ process.
1> if an drx-HARQ-RTT-TimerUL expires:
2> start the drx-RetransmissionTimerUL for the corresponding HARQ process.
1> if a DRX Command MAC CE or a Long DRX Command MAC CE is received:
2> stop drx-onDurationTimer;
2> stop drx-InactivityTimer.
1> if drx-InactivityTimer expires or a DRX Command MAC CE is received:
2> if the Short DRX cycle is configured:
3> start or restart drx-ShortCycleTimer in the first symbol after the expiry of drx-HARQ-RTT-TimerDL.;
3> use the Short DRX Cycle.
2> else:
3> use the Long DRX cycle.
1> if drx-ShortCycleTimer expires:
2> use the Long DRX cycle.
1> if a Long DRX Command MAC CE is received:
2> stop drx-ShortCycleTimer;
2> use the Long DRX cycle.
1> if the Short DRX Cycle is used, and [(SFN x 10) + subframe number] modulo (drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle); or
1> if the Long DRX Cycle is used, and [(SFN x 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset:
2> if drx-SlotOffset is configured:
3> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
2> else:
3> start drx-onDurationTimer.
1> if the MAC entity is in Active Time:
2> monitor the PDCCH;
2> if the PDCCH indicates a DL transmission or if a DL assignment has been configured:
3> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process immediately after the corresponding PUCCH transmission;
3> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
2> if the PDCCH indicates a UL transmission or if a UL grant has been configured:
3> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process immediately after the first repetition of the corresponding PUSCH transmission;
3> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
2> if the PDCCH indicates a new transmission (DL or UL):
3> start or restart drx-InactivityTimer.
1> else (i.e. not part of the Active Time):
2> not report CQI/PMI/RI on PUCCH.
7.1.1.5.1.3 Test description
7.1.1.5.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.5.1.3.2 Test procedure sequence
Table 7.1.1.5.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits RRCReconfiguration to configure specific DRX parameters. (Note 6) |
<– |
– |
– |
– |
2 |
The UE transmits RRCReconfigurationComplete. (Note 7) |
–> |
– |
– |
– |
3 |
In the first PDCCH occasion when the Drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
4 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 3? |
–> |
HARQ ACK |
1 |
P |
5 |
At least drx-InactivityTimer PDCCH occasions after the transmission of the MAC PDU in Step 3 has been indicated (This means the next DRX cycle or later after Step 2) in the last PDCCH occasion while the drx-onDurationTimer is still running, the SS indicates the transmission a DL MAC PDU on the PDDCH. (Note 4). |
<– |
MAC PDU |
– |
– |
6 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5? |
–> |
HARQ ACK |
1 |
P |
7 |
drx-InactivityTimer PDCCH-occasions after the transmission of the MAC PDU transmitted in step 5 was indicated on the PDCCH, the SS indicates the transmission of a DL MAC PDU on the PDCCH. (Note 4) |
<– |
MAC PDU |
– |
– |
8 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 7? |
–> |
HARQ ACK |
2 |
P |
9 |
At least drx-InactivityTimer PDCCH occasions after the transmission of the MAC PDU in Step 7 has been indicated (This means the next DRX cycle or later after Step 5) and in the last PDCCH occasion before the Drx-onDurationTimer expires, the SS indicates the transmission of a DL MAC PDU on the PDDCH. The DL MAC PDU transmitted is invalid. (Note 1, Note 4) |
<– |
Invalid MAC PDU |
– |
– |
10 |
Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 9? |
–> |
HARQ NACK |
1 |
P |
11 |
In the first PDCCH occasion when the Drx-RetransmissionTimerDL for the MAC PDU in Step 9 is started (i.e. after expiry of drx-HARQ-RTT-TimerDL after step 9), the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
12 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 11? |
–> |
HARQ ACK |
3 |
P |
13 |
At least drx-InactivityTimer PDCCH occasions after the transmission of the DL MAC PDU in Step 11 has been indicated (This means the next DRX cycle or later after Step 11) and last PDCCH occasion before the Drx-onDurationTimer expires, the SS indicates the transmission of DL MAC PDU on the PDCCH. The DL MAC PDU transmitted is invalid. (Note 1, Note 4) |
<– |
Invalid MAC PDU |
– |
– |
14 |
Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 13? |
–> |
HARQ NACK |
1 |
P |
15 |
In the last PDCCH occasion when the drx-RetransmissionTimerDL for MAC PDU in Step 13 is still running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
16 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 15? |
–> |
HARQ ACK |
3 |
P |
17 |
The SS is configured for Uplink Grant Allocation Type [0]. At least drx-InactivityTimer PDCCH subframes after the transmission of the DL MAC PDU in Step 15 has been indicated in the last PDCCH occasion when the onDuratiopnTimer is still running (This means the next DRX cycle or later after Step 9), the SS indicates an UL grant to the UE on the PDCCH. (Note 4) |
<– |
UL grant on PDCCH |
– |
– |
18 |
Check: Does the UE transmit a Buffer Status Report on the UL indicating an empty buffer? |
–> |
Buffer Status Report MAC control element |
1 |
P |
19 |
In the last PDCCH occasion when the drx-RetransmissionTimer-UL for MAC PDU from Step 17 is still running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
20 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 19? |
–> |
HARQ ACK |
4 |
P |
Note 1: Invalid MAC PDU is a MAC PDU that fails the CRC check. Note 2: All the DL MAC PDU are transmitted with the NDI set on the PDCCH. Note 3: Timer tolerances for the MAC DRX related timers measured in PDCCH occasions is 0. These timers are: drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-HARQ-RTT-TimerDL and drx-HARQ-RTT-TimerUL. Note 4: The drx-InactivityTimer is started in the next PDCCH occasion of the PDCCH occasion where DL new transmission is indicated. Note 5: The timer values expressed in number of slots. Note 6: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 7: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.5.1.3.3 Specific message contents
Table 7.1.1.5.1.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.5.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
radioBearerConfig |
RadioBearerConfig |
NR |
|
secondaryCellGroup |
CellGroupConfig |
EN-DC |
|
} |
|||
nonCriticalExtension::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.5.1.3.3-2: CellGroupConfig (Table 7.1.1.5.1.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer |
ms20 |
||
drx-InactivityTimer |
ms10 |
||
drx-HARQ-RTT-TimerDL |
56 |
Number of slots=4 due to number of symbol per slot=14 |
=0,1,2,3,4 ( 2 with normal CP) |
48 |
Number of slots=4 due to number of symbol per slot=12 |
= 2 with external CP |
|
drx-HARQ-RTT-TimerUL |
56 |
Number of slots=4 due to number of symbol per slot=14 |
=0,1,2,3,4 ( 2 with normal CP) |
48 |
Number of slots=4 due to number of symbol per slot=12 |
= 2 with external CP |
|
drx-RetransmissionTimerDL |
sl8 |
||
drx-RetransmissionTimerUL |
sl8 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms640 |
7 |
||
} |
|||
shortDRX |
Not present |
||
drx-SlotOffset |
ms0 |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.5.2 DRX operation / Short cycle not configured / Long DRX command MAC control element reception
7.1.1.5.2.1 Test Purpose (TP)
(1)
with { UE in CONNECTED mode }
ensure that {
when { long DRX cycle is configured and a DRX Command MAC control element is received }
then { UE successfully decodes the MAC control PDU }
}
(2)
with { UE in CONNECTED mode }
ensure that {
when { long DRX cycle is configured and the HARQ RTT Timer is running and a DRX Command MAC control element is received }
then { UE continues running the HARQ RTT timer }
}
(3)
with { UE in CONNECTED mode }
ensure that {
when { long DRX cycle is configured and the drx-RetransmissionTimer is running and a DRX Command MAC control element is received }
then { UE continues running the drx-RetransmissionTimer and monitors the PDCCH }
}
7.1.1.5.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.7. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.7]
The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring. Activity for the MAC entity’s C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other subclauses of this specification. When in RRC_CONNECTED, if DRX is configured, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this subclause; otherwise the MAC entity shall monitor the PDCCH continuously.
RRC controls DRX operation by configuring the following timers:
– drx-onDurationTimer: the duration at the beginning of a DRX Cycle;
– drx-SlotOffset: the delay before starting the drx-onDurationTimer;
– drx-InactivityTimer: the duration after the PDCCH occasion in which a PDCCH indicates a new UL or DL transmission for the MAC entity;
– drx-RetransmissionTimerDL (per DL HARQ process): the maximum duration until a DL retransmission is received;
– drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;
– drx-LongCycle StartOffset: the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;
– drx-ShortCycle (optional): the Short DRX cycle;
– drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;
– drx-HARQ-RTT-TimerDL (per DL HARQ process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;
– drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity.
When a DRX cycle is configured, the Active Time includes the time while:
– drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in subclause 5.1.5) is running; or
– a Scheduling Request is sent on PUCCH and is pending (as described in subclause 5.4.4); or
– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the random access preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in subclause 5.1.4).
When DRX is configured, the MAC entity shall:
1> if a MAC PDU is received in a configured downlink assignment:
2> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
2> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
1> if a MAC PDU is transmitted in a configured uplink grant:
2> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
2> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
1> if a drx-HARQ-RTT-TimerDL expires:
2> if the data of the corresponding HARQ process was not successfully decoded:
3> start the drx-RetransmissionTimerDL for the corresponding HARQ process.
1> if an drx-HARQ-RTT-TimerUL expires:
2> start the drx-RetransmissionTimerUL for the corresponding HARQ process.
1> if a DRX Command MAC CE or a Long DRX Command MAC CE is received:
2> stop drx-onDurationTimer;
2> stop drx-InactivityTimer.
1> if drx-InactivityTimer expires or a DRX Command MAC CE is received:
2> if the Short DRX cycle is configured:
3> start or restart drx-ShortCycleTimer in the first symbol after the expiry of drx-HARQ-RTT-TimerDL.;
3> use the Short DRX Cycle.
2> else:
3> use the Long DRX cycle.
1> if drx-ShortCycleTimer expires:
2> use the Long DRX cycle.
1> if a Long DRX Command MAC CE is received:
2> stop drx-ShortCycleTimer;
2> use the Long DRX cycle.
1> if the Short DRX Cycle is used, and [(SFN x 10) + subframe number] modulo (drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle); or
1> if the Long DRX Cycle is used, and [(SFN x 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset:
2> if drx-SlotOffset is configured:
3> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
2> else:
3> start drx-onDurationTimer.
1> if the MAC entity is in Active Time:
2> monitor the PDCCH;
2> if the PDCCH indicates a DL transmission or if a DL assignment has been configured:
3> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process immediately after the corresponding PUCCH transmission;
3> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
2> if the PDCCH indicates a UL transmission or if a UL grant has been configured:
3> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process immediately after the first repetition of the corresponding PUSCH transmission;
3> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
2> if the PDCCH indicates a new transmission (DL or UL):
3> start or restart drx-InactivityTimer.
1> else (i.e. not part of the Active Time):
2> not report CQI/PMI/RI on PUCCH.
7.1.1.5.2.3 Test description
7.1.1.5.2.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.5.2.3.2 Test procedure sequence
For FDD, NormalSLT(current SFN,current sub-frame, current slot,y)=y; For TDD, NormalSLT(current SFN, current slot,y) counts the minimum number of normal slots needed to cover y number of PDCCH-occasions(slots) until next PDCCH-occasion(slot) available, starting from current slot on current SFN.
Table 7.1.1.5.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits RRCReconfiguration to configure specific DRX parameters. (Note 5) |
<– |
– |
– |
– |
2 |
The UE transmits RRCReconfigurationComplete. (Note 6) |
–> |
– |
– |
– |
3 |
In a PDCCH occasion which is X PDCCH sub frames before the PDCCH occasion in which the onDurationTimer expires, with X < drx-onDurationTimer, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits an MAC PDU. |
<– |
MAC PDU |
– |
– |
4 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 3? |
–> |
HARQ ACK |
1 |
P |
5 |
In a PDCCH occasion before the drx-onDurationTimer expires, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU with DRX MAC Control element. UE successfully decodes the MAC PDU and starts the long DRX cycle. |
<– |
MAC PDU(DRX MAC Control element) |
– |
– |
6 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
6A |
In a PDCCH occasion before the Long DRX cycle ends, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU |
<– |
MAC PDU |
||
6B |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
F |
7 |
On the next or later DRX cycle than the one used for Step 3 and on a PDCCH occasion which is X PDCCH sub frames before the PDCCH occasion in which the onDurationTimer expires, with X < drx-onDurationTimer,the SS indicates the transmission of a DL MAC PDU. The SS transmits an invalid MAC PDU. (Note 1) |
<– |
MAC PDU |
– |
– |
8 |
Check: Does the UE transmit a HARQ NACK? |
–> |
HARQ NACK |
– |
P |
8A |
In a PDCCH occasion before the Drx-HARQ-RTT-TimerDL for the MAC PDU indicated in Step 7 expires, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU with DRX MAC Control element. |
<– |
MAC PDU(DRX MAC Control element) |
– |
– |
8B |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
2,3 |
P |
9 |
In a PDCCH occasion when the drx-RetransmissionTimer for the MAC PDU indicated in Step 7 is still running,, the SS indicates the transmission of a DL MAC PDU. The SS transmits a DL MAC PDU with DRX MAC Control element. |
<– |
MAC PDU(DRX MAC Control element) |
– |
– |
10 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
2,3 |
P |
11 |
In the last sub frame when the Drx-RetransmissionTimer for the DL MAC PDU indicated on the PDCCH in Step 7 is still running, the SS indicates the transmission of a DL MAC PDU. |
<– |
MAC PDU |
– |
– |
12 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
2,3 |
P |
Note 1: Invalid MAC PDU is a MAC PDU that fails the CRC check. Note 2: All DL MAC PDUs are transmitted with the NDI set on the PDCCH. Note 3: Timer tolerances for the MAC DRX related timers measured in PDCCH occasions(slots). These timers are: drx-InactivityTimer, drx-RetransmissionTimer, Drx-HARQ-RTT-TimerDL. Note 5: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 6: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete |
7.1.1.5.2.3.3 Specific message contents
Table 7.1.1.5.2.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.5.2.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
radioBearerConfig |
RadioBearerConfig |
NR |
|
secondaryCellGroup |
CellGroupConfig |
EN-DC |
|
} |
|||
nonCriticalExtension::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.5.2.3.3-2: CellGroupConfig (Table 7.1.1.5.2.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer |
ms40 |
||
drx-InactivityTimer |
ms10 |
||
drx-HARQ-RTT-TimerDL |
56 |
Number of slots=4 due to number of symbol per slot=14 |
=0,1,2,3,4 ( 2 with normal CP) |
48 |
Number of slots=4 due to number of symbol per slot=12 |
= 2 with external CP |
|
drx-HARQ-RTT-TimerUL |
56 |
Number of slots=4 due to number of symbol per slot=14 |
=0,1,2,3,4 ( 2 with normal CP) |
48 |
Number of slots=4 due to number of symbol per slot=12 |
= 2 with external CP |
|
drx-RetransmissionTimerDL |
sl80 |
||
drx-RetransmissionTimerUL |
sl80 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms640 |
7 |
||
} |
|||
shortDRX |
Not present |
||
drx-SlotOffset |
ms0 |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.5.3 DRX operation / Short cycle configured / Parameters configured by RRC
7.1.1.5.3.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { Short DRX cycle and drx-SlotOffset is configured and [(SFN * 10) + subframe number] modulo drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle) }
then { UE starts the OnDurationTimer after drx-SlotOffset and monitors the PDCCH for OnDurationTimer PDCCH-subframes }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { drxShortCycleTimer is expired and [(SFN * 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset: }
then { UE starts the OnDurationTimer after drx-SlotOffset and monitors the PDCCH for OnDurationTimer PDCCH-subframes }
}
7.1.1.5.3.2 Conformance requirements
Editor’s Note: The conformance requirements are based on running RAN2 CR
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clause 5.7. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.7]
The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other subclauses of this specification.When in RRC_CONNECTED, if DRX is configured, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this subclause; otherwise the MAC entity shall monitor the PDCCH continuously.
RRC controls DRX operation by configuring the following parameters:
– drx-onDurationTimer: the duration at the beginning of a DRX Cycle;
– drx-SlotOffset: the delay before starting the drx-onDurationTimer;
– drx-InactivityTimer: the duration after the PDCCH occasion in which a PDCCH indicates a new UL or DL transmission for the MAC entity;
– drx-RetransmissionTimerDL (per DL HARQ process): the maximum duration until a DL retransmission is received;
– drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;
– drx-LongCycleStartOffset: the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;
– drx-ShortCycle (optional): the Short DRX cycle;
– drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;
– drx-HARQ-RTT-TimerDL (per DL HARQ process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;
– drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity.
When a DRX cycle is configured, the Active Time includes the time while:
– drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in subclause 5.1.5) is running; or
– a Scheduling Request is sent on PUCCH and is pending (as described in subclause 5.4.4); or
– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the Random Access Preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in subclause 5.1.4).
…
1> if drx-InactivityTimer expires or a DRX Command MAC CE is received:
2> if the Short DRX cycle is configured:
3> start or restart drx-ShortCycleTimer in the first symbol after the expiry of drx-InactivityTimer or in the first symbol after the end of DRX Command MAC CE reception;
3> use the Short DRX Cycle.
2> else:
3> use the Long DRX cycle.
1> if drx-ShortCycleTimer expires:
2> use the Long DRX cycle.
1> if a Long DRX Command MAC CE is received:
2> stop drx-ShortCycleTimer;
2> use the Long DRX cycle.
1> if the Short DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle); or
1> if the Long DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset:
2> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
7.1.1.5.3.3 Test description
7.1.1.5.3.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.5.3.3.2 Test procedure sequence
For FDD, NormalSLT (current SFN, current sub-frame, current slot, y) = y; For TDD, NormalSLT (current SFN, current slot, y) counts the minimum number of normal slots needed to cover y number of PDCCH-occasions(slots) until next PDCCH-occasion(slot) available, starting from current slot on current Subframe.
Table 7.1.1.5.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration message to configure specific DRX parameters for SpCell (Note1) |
<– |
– |
– |
– |
2 |
The UE transmitNR RRCReconfigurationComplete messages (Note 2) |
–> |
– |
– |
– |
3 |
In the first PDCCH occasion, after the drx-SlotOffset when the drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. (Note 3)(Note 4)(Note 5) |
<– |
MAC PDU |
– |
– |
4 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 3? |
–> |
HARQ ACK |
– |
– |
5 |
At least drx-InactivityTimer after the transmission of the MAC PDU in Step 3 has been indicated (This means the next DRX cycle or later after Step 1) in the last PDCCH occasion while the drx-onDurationTimer is still running according to [(SFN * 10) + subframe number] modulo drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle)), the SS indicates the transmission a DL MAC PDU on the PDDCH. |
<– |
MAC PDU |
– |
– |
6 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5? |
–> |
HARQ ACK |
1 |
P |
7 |
SS waits for drx-ShortCycleTimer to expire. |
– |
– |
– |
– |
8 |
In the first PDCCH occasion after the drx-SlotOffset when the drx-onDurationTimer of drx-LongCycle is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
9 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 8? |
–> |
HARQ ACK |
2 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: The drx-InactivityTimer is started in the first symbol after the end of the PDCCH reception where DL new transmission is indicated. Note 4: When the drx-InactivityTimer expires, UE starts drx-ShortCycleTimer in the first symbol after the expiry of drx-InactivityTimer. Note 5: The SS assumes that the UE starts in long DRX after configuration. |
7.1.1.5.3.3.3 Specific message contents
Table 7.1.1.5.3.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.5.3.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
radioBearerConfig |
RadioBearerConfig |
NR |
|
secondaryCellGroup |
CellGroupConfig |
EN-DC |
|
} |
|||
nonCriticalExtension::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig |
||
} |
|||
} |
|||
} |
Table 7.1.1.5.3.3.3-2: CellGroupConfig (Table 7.1.1.5.3.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer |
ms20 |
||
drx-InactivityTimer |
Ms10 |
||
drx-HARQ-RTT-TimerDL |
56 |
||
drx-HARQ-RTT-TimerUL |
56 |
||
drx-RetransmissionTimerDL |
sl80 |
||
drx-RetransmissionTimerUL |
sl80 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms640 |
7 |
||
} |
|||
shortDRX SEQUENCE { |
|||
drx-ShortCycle |
Ms80 |
||
drx-ShortCycleTimer |
7 |
||
} |
|||
drx-SlotOffset |
ms0 |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.5.4 DRX operation / Short cycle configured / DRX command MAC control element reception
7.1.1.5.4.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { Short DRX cycle is configured and a DRX Command MAC control element is received }
then { UE successfully decodes the MAC control PDU }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { Short DRX cycle is configured and the HARQ RTT Timer is running and a DRX Command MAC control element is received }
then { UE continues running the HARQ RTT timer }
}
(3)
with { UE in RRC_CONNECTED state }
ensure that {
when { Short DRX cycle is configured and the drx-RetransmissionTimer-DL is running and a DRX Command MAC control element is received }
then { UE continues running the drx-RetransmissionTimer-DL and monitors the PDCCH }
}
7.1.1.5.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.7. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.7]
The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other subclauses of this specification. When in RRC_CONNECTED, if DRX is configured, for all the activated Serving Cells, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this subclause; otherwise the MAC entity shall monitor the PDCCH continuously.
RRC controls DRX operation by configuring the following parameters:
– drx-onDurationTimer: the duration at the beginning of a DRX Cycle;
– drx-SlotOffset: the delay before starting the drx-onDurationTimer;
– drx-InactivityTimer: the duration after the PDCCH occasion in which a PDCCH indicates a new UL or DL transmission for the MAC entity;
– drx-RetransmissionTimerDL (per DL HARQ process except for the broadcast process): the maximum duration until a DL retransmission is received;
– drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;
– drx-LongCycleStartOffset: the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;
– drx-ShortCycle (optional): the Short DRX cycle;
– drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;
– drx-HARQ-RTT-TimerDL (per DL HARQ process except for the broadcast process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;
– drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity.
When a DRX cycle is configured, the Active Time includes the time while:
– drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in subclause 5.1.5) is running; or
– a Scheduling Request is sent on PUCCH and is pending (as described in subclause 5.4.4); or
– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the Random Access Preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in subclause 5.1.4).
When DRX is configured, the MAC entity shall:
1> if a MAC PDU is received in a configured downlink assignment:
2> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
2> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
1> if a MAC PDU is transmitted in a configured uplink grant:
2> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
2> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
1> if a drx-HARQ-RTT-TimerDL expires:
2> if the data of the corresponding HARQ process was not successfully decoded:
3> start the drx-RetransmissionTimerDL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerDL.
1> if a drx-HARQ-RTT-TimerUL expires:
2> start the drx-RetransmissionTimerUL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerUL.
1> if a DRX Command MAC CE or a Long DRX Command MAC CE is received:
2> stop drx-onDurationTimer;
2> stop drx-InactivityTimer.
1> if drx-InactivityTimer expires or a DRX Command MAC CE is received:
2> if the Short DRX cycle is configured:
3> start or restart drx-ShortCycleTimer in the first symbol after the expiry of drx-InactivityTimer or in the first symbol after the end of DRX Command MAC CE reception;
3> use the Short DRX Cycle.
2> else:
3> use the Long DRX cycle.
1> if drx-ShortCycleTimer expires:
2> use the Long DRX cycle.
1> if a Long DRX Command MAC CE is received:
2> stop drx-ShortCycleTimer;
2> use the Long DRX cycle.
1> if the Short DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle); or
1> if the Long DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset:
2> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
1> if the MAC entity is in Active Time:
2> monitor the PDCCH;
2> if the PDCCH indicates a DL transmission:
3> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
3> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
2> if the PDCCH indicates a UL transmission:
3> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
3> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
2> if the PDCCH indicates a new transmission (DL or UL):
3> start or restart drx-InactivityTimer in the first symbol after the end of the PDCCH reception.
1> in current symbol n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this subclause:
2> not transmit periodic SRS and semi-persistent SRS defined in TS 38.214 [7].
1> if CSI masking (csi-Mask) is setup by upper layers:
2> in current symbol n, if onDurationTimer would not be running considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this subclause:
3> not report CSI on PUCCH.
1> else:
2> in current symbol n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this subclause:
3> not report CSI on PUCCH and semi-persistent CSI on PUSCH.
Regardless of whether the MAC entity is monitoring PDCCH or not, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS 38.214 [7] when such is expected.
The MAC entity needs not to monitor the PDCCH if it is not a complete PDCCH occasion (e.g. the Active Time starts or ends in the middle of a PDCCH occasion).
7.1.1.5.4.3 Test description
7.1.1.5.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.5.4.3.2 Test procedure sequence
For FDD, NormalSLT(current SFN, current subframe, current slot, y)=y; For TDD, NormalSLT(current SFN, current subframe, current slot, y) counts the minimum number of normal slots needed to cover y number of PDCCH-occasions (slots) until next PDCCH-occasion (slot) available, starting from current slot on current SFN.
Table 7.1.1.5.4.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfigurationmessage to configure specific DRX parameters for NR Cell. (Note 1) |
<– |
NR RRC: RRCReconfiguration |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete message. (Note 2) |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
3 |
In a PDCCH occasion which is X subframes before the PDCCH occasion in which the drx-onDurationTimer expires, |
<– |
MAC PDU |
– |
– |
4 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 3? |
–> |
HARQ ACK |
1 |
P |
5 |
In a PDCCH occasion before the drx-onDurationTimer expires, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU with DRX MAC Control element. UE successfully decodes the MAC PDU. |
<– |
MAC PDU (DRX MAC Control element) |
– |
– |
6 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5? |
–> |
HARQ ACK |
1 |
P |
6A |
In a PDCCH occasion before the short DRX cycle ends, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU |
<– |
MAC PDU |
||
6B |
Check: Does the UE transmit a HARQ ACK in step 6B? |
–> |
HARQ ACK |
1 |
F |
7 |
On the next or later DRX cycle than the one used for Step 3 and on a PDCCH occasion which is X PDCCH sub frames before the PDCCH occasion in which the onDurationTimer expires, with X < drx-onDurationTimer, the SS indicates the transmission of a DL MAC PDU. The SS transmits an invalid MAC PDU. (Note 3) |
<– |
MAC PDU |
– |
– |
8 |
Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 7? |
–> |
HARQ NACK |
2,3 |
P |
8A |
In a PDCCH occasion before the Drx-HARQ-RTT-TimerDL for the MAC PDU indicated in Step 7 expires, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU with DRX MAC Control element. |
<– |
MAC PDU(DRX MAC Control element) |
||
8B |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
2,3 |
P |
9 |
In a PDCCH occasion which is Z slots before the slot in which the drx-RetransmissionTimerDL for the DL MAC PDU in Step 7 expires, with 1 <Z< drx-RetransmissionTimerDL, the SS indicates the transmission of a DL MAC PDU. The SS transmits a DL MAC PDU with DRX MAC Control element. |
<– |
MAC PDU(DRX MAC Control element) |
– |
– |
10 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 9? |
–> |
HARQ ACK |
2,3,1 |
P |
11 |
In the last PDCCH occasion when the drx-RetransmissionTimerDL for the DL MAC PDU indicated on the PDCCH in Step 7 is still running, the SS indicates the transmission of a DL MAC PDU. |
<– |
MAC PDU |
– |
– |
12 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 11? |
–> |
HARQ ACK |
2,3 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: Invalid MAC PDU is a MAC PDU that fails the CRC check. Note 4: All DL MAC PDUs are transmitted with the NDI set on the PDCCH. Note 5: Timer tolerances for the MAC DRX related timers measured in PDCCH occasions (slots). These timers are: drx-InactivityTimer, drx-RetransmissionTimer, Drx-HARQ-RTT-TimerDL. Note 6: K is the time for given PDSCH to HARQ feedback of PUCCH and shall be shorter than drx-InactivityTimer. In this TC, the DCI format should be configured to not include the PDSCH-to-HARQ-timing-indicator field. When the UE schedules a PDSCH reception over a number of symbols where the last symbol is within slot n-k, the UE shall provide corresponding HARQ-ACK information in a PUCCH transmission within slot n-k+4 according to TS 38.321 clause 9.2.3. Thus, the maximum value of K is 4 slots in this test case. Note 7: The SS assumes that the UE starts in long DRX after configuration. |
7.1.1.5.4.3.3 Specific message contents
Table 7.1.1.5.4.3.3-1: RRCReconfiguration (Step 1, Table 7.1.1.5.4.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||||||
Information Element |
Value/remark |
Comment |
Condition |
||||
RRCReconfiguration ::= SEQUENCE { |
|||||||
criticalExtensions CHOICE { |
|||||||
rrcReconfiguration SEQUENCE { |
|||||||
radioBearerConfig |
Not present |
||||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
||||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
|||||
nonCriticalExtension := SEQUENCE{ |
NR |
||||||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|||||
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
||||||
} |
|||||||
} |
|||||||
} |
|||||||
} |
Table 7.1.1.5.4.3.3-2: CellGroupConfig (Table 7.1.1.5.4.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-n |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer |
ms40 |
||
drx-InactivityTimer |
Ms10 |
||
drx-HARQ-RTT-TimerDL |
56 |
||
drx-HARQ-RTT-TimerUL |
56 |
||
drx-RetransmissionTimerDL |
Sl80 |
||
drx-RetransmissionTimerUL |
Sl80 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms640 |
7 |
||
} |
|||
shortDRX SEQUENCE { |
|||
drx-ShortCycle |
ms80 |
||
drx-ShortCycleTimer |
7 |
||
} |
|||
drx-SlotOffset |
ms0 |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.5.5 DRX operation / Short cycle configured / Long DRX command MAC control element reception
7.1.1.5.5.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { short DRX cycle is configured and a long DRX Command MAC control element is received }
then { UE successfully decodes the MAC control PDU }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { Long DRX cycle and drx-SlotOffset is configured and [(SFN * 10) + subframe number] modulo drx-LongCycle} = drxStartOffset }
then { UE starts the OnDurationTimer after drx-SlotOffset and monitors PDCCH for OnDurationTimer PDCCH-subframes }
}
7.1.1.5.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.7. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.7]
The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and TPC-SRS-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. When in RRC_CONNECTED, if DRX is configured, for all the activated Serving Cells, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity shall monitor the PDCCH as specified in TS 38.213 [6].
RRC controls DRX operation by configuring the following parameters:
– drx-onDurationTimer: the duration at the beginning of a DRX Cycle;
– drx-SlotOffset: the delay before starting the drx-onDurationTimer;
– drx-InactivityTimer: the duration after the PDCCH occasion in which a PDCCH indicates a new UL or DL transmission for the MAC entity;
– drx-RetransmissionTimerDL (per DL HARQ process except for the broadcast process): the maximum duration until a DL retransmission is received;
– drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;
– drx-LongCycleStartOffset: the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;
– drx-ShortCycle (optional): the Short DRX cycle;
– drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;
– drx-HARQ-RTT-TimerDL (per DL HARQ process except for the broadcast process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;
– drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity.
When a DRX cycle is configured, the Active Time includes the time while:
– drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in clause 5.1.5) is running; or
– a Scheduling Request is sent on PUCCH and is pending (as described in clause 5.4.4); or
– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the Random Access Preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in clause 5.1.4).
When DRX is configured, the MAC entity shall:
1> if a MAC PDU is received in a configured downlink assignment:
2> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
2> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
1> if a MAC PDU is transmitted in a configured uplink grant:
2> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
2> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
1> if a drx-HARQ-RTT-TimerDL expires:
2> if the data of the corresponding HARQ process was not successfully decoded:
3> start the drx-RetransmissionTimerDL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerDL.
1> if a drx-HARQ-RTT-TimerUL expires:
2> start the drx-RetransmissionTimerUL for the corresponding HARQ process in the first symbol after the expiry of drx-HARQ-RTT-TimerUL.
1> if a DRX Command MAC CE or a Long DRX Command MAC CE is received:
2> stop drx-onDurationTimer;
2> stop drx-InactivityTimer.
1> if drx-InactivityTimer expires or a DRX Command MAC CE is received:
2> if the Short DRX cycle is configured:
3> start or restart drx-ShortCycleTimer in the first symbol after the expiry of drx-InactivityTimer or in the first symbol after the end of DRX Command MAC CE reception;
3> use the Short DRX Cycle.
2> else:
3> use the Long DRX cycle.
1> if drx-ShortCycleTimer expires:
2> use the Long DRX cycle.
1> if a Long DRX Command MAC CE is received:
2> stop drx-ShortCycleTimer;
2> use the Long DRX cycle.
1> if the Short DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-ShortCycle) = (drx-StartOffset) modulo (drx-ShortCycle); or
1> if the Long DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset:
2> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
1> if the MAC entity is in Active Time:
2> monitor the PDCCH as specified in TS 38.213 [6];
2> if the PDCCH indicates a DL transmission:
3> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
3> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
2> if the PDCCH indicates a UL transmission:
3> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
3> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
2> if the PDCCH indicates a new transmission (DL or UL):
3> start or restart drx-InactivityTimer in the first symbol after the end of the PDCCH reception.
1> in current symbol n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause:
2> not transmit periodic SRS and semi-persistent SRS defined in TS 38.214 [7];
2> not report CSI on PUCCH and semi-persistent CSI configured on PUSCH.
1> if CSI masking (csi-Mask) is setup by upper layers:
2> in current symbol n, if drx-onDurationTimer would not be running considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause:
3> not report CSI on PUCCH.
NOTE: If a UE multiplexes a CSI configured on PUCCH with other overlapping UCI(s) according to the procedure specified in TS 38.213 [6] subclause 9.2.5 and this CSI multiplexed with other UCI(s) would be reported on a PUCCH resource outside DRX Active Time, it is up to UE implementation whether to report this CSI multiplexed with other UCI(s).
Regardless of whether the MAC entity is monitoring PDCCH or not, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS 38.214 [7] when such is expected.
The MAC entity needs not to monitor the PDCCH if it is not a complete PDCCH occasion (e.g. the Active Time starts or ends in the middle of a PDCCH occasion).
7.1.1.5.5.3 Test Description
7.1.1.5.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.5.5.3.2 Test procedure sequence
For FDD, NormalSLT=(current SFN, current sub-frame, current slot, y)=y; For TDD, NormalSLT(current SFN, current slot, y) counts the minimum number of normal slots needed to cover y number of PDCCH-occasions (slots) until next PDCCH-occasion(slot) available, starting from current slot on current SFN.
Table 7.1.1.5.5.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration message to configure specific DRX parameters for NR Cell. (Note 1) |
<– |
NR RRC: RRCReconfiguration |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete message. (Note 2) |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
3 |
In a PDCCH occasion when the drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits an valid MAC PDU. (Note 3) |
<– |
MAC PDU |
– |
– |
4 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 3? |
–> |
HARQ ACK |
1 |
P |
4A |
Wait for the expiry of drx-InactivityTimer to ensure that UE starts the Short DRX Cycle. |
– |
– |
– |
– |
5 |
In a PDCCH occasion before the drx-onDurationTimer expires, the SS indicates the transmission of a DL MAC PDU on the PDCCH. The SS transmits a DL MAC PDU with Long DRX MAC Control element. UE successfully decodes the MAC PDU. |
<– |
MAC PDU (Long DRX MAC Control element) |
– |
– |
6 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5? |
–> |
HARQ ACK |
1 |
P |
7 |
In the first PDCCH occasion, after the drx-SlotOffset when the drx-onDurationTimer is running according to [(SFN * 10) + subframe number] modulo drx-LongCycle) = (drx-StartOffset) modulo (drx-LongCycle)), the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
8 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 7? |
–> |
HARQ ACK |
2 |
P |
9 |
At least drx-InactivityTimer PDCCH occasions after the transmission of the MAC PDU in Step 7 has been indicated (This means the next DRX cycle or later after Step 7) in the last PDCCH occasion while the drx-onDurationTimer is still running, the SS indicates the transmission a DL MAC PDU on the PDDCH. (Note 7) |
<– |
MAC PDU |
– |
– |
10 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 9? |
–> |
HARQ ACK |
2 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: The SS assumes that the UE starts in long DRX after configuration. Note 4: All DL MAC PDUs are transmitted with the NDI set on the PDCCH. Note 5: Timer tolerances for the MAC DRX related timers measured in PDCCH occasions (slots). These timers are: drx-InactivityTimer, drx-RetransmissionTimer, Drx-HARQ-RTT-TimerDL. Note 6: Void Note 7: The drx-InactivityTimer is started in the next PDCCH occasion of the PDCCH occasion where DL new transmission is indicated. |
7.1.1.5.5.3.3 Specific message contents
Table 7.1.1.5.5.3.3-1: RRCReconfiguration (Step 1, Table 7.1.1.5.5.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
radioBearerConfig |
RadioBearerConfig with conditions SRB2 and DRB1 |
NR |
|
secondaryCellGroup |
CellGroupConfig |
EN-DC |
|
} |
|||
nonCriticalExtension::= SEQUENCE { |
NR |
||
masterCellGroup |
CellGroupConfig with condition SRB2_DRB1 |
NR |
|
} |
|||
} |
|||
} |
Table 7.1.1.5.5.3.3-2: CellGroupConfig (Table 7.1.1.5.5.3.3-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer |
ms40 |
||
drx-InactivityTimer |
ms10 |
||
drx-HARQ-RTT-TimerDL |
56 |
||
drx-HARQ-RTT-TimerUL |
56 |
||
drx-RetransmissionTimerDL |
sl80 |
||
drx-RetransmissionTimerUL |
sl80 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms640 |
7 |
||
} |
|||
shortDRX SEQUENCE { |
|||
drx-ShortCycle |
ms80 |
||
drx-ShortCycleTimer |
7 |
||
} |
|||
drx-SlotOffset |
ms0 |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.6 Semi-Persistent Scheduling
7.1.1.6.1 Correct handling of DL assignment / Semi-persistent case
7.1.1.6.1.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state with DRB established and sps-Configuration in DL is enabled }
ensure that {
when { UE receives a DL assignment addressed to its stored CS-RNTI in slot y and with NDI set as 0 and PDCCH content indicates activation }
then {UE starts receiving DL MAC PDU in slots y+n*[semiPersistSchedIntervalDL] where ‘n’ is positive integer starting at zero }
}
(2)
with { UE in RRC_Connected state with DRB established and stored DL SPS assignment to receive MAC PDU in slot y+n*[semiPersistSchedIntervalDL] }
ensure that {
when { UE receives a DL assignment addressed to its CS-RNTI in slot p and with NDI set as 0, where p!= y+n*[semiPersistSchedIntervalDL] }
then { UE starts receiving DL MAC PDU in slots p+n*[semiPersistSchedIntervalDL] and stops receiving DL MAC PDU at slots y+n*[semiPersistSchedIntervalDL]where ‘n’ is positive integer starting at zero }
}
(3)
with { UE in RRC_Connected state with DRB established and stored DL SPS assignment to receive MAC PDU at slot p+n*[semiPersistSchedIntervalDL] }
ensure that {
when { UE receives a DL assignment [for retransmission] addressed to its CS-RNTI in Slot z and with NDI set as 1, where z!= p+n*[semiPersistSchedIntervalDL] }
then { UE receives MAC PDU as per the retransmission grant for CS-RNTI }
}
(4)
with { UE in RRC_Connected state with DRB established and stored DL SPS assignment to receive MAC PDU at slot y+n*[semiPersistSchedIntervalDL] }
ensure that {
when { UE receives a DL assignment addressed to its C-RNTI in Slot p, such that p= y+n*[semiPersistSchedIntervalDL] }
then { UE receives MAC PDU as per assignment addressed to its C-RNTI }
}
(5)
with { UE in RRC_Connected state with DRB established and stored DL SPS grant to receive MAC PDU at slot z+n*[semiPersistSchedIntervalDL] }
ensure that {
when { UE receives a RRC Message including sps-Configuration with sps-ConfigurationDL set as ‘disable’ and hence resulting in DL SPS grant deactivation }
then { UE deletes the stored sps-Configuration DL parameters and stops receiving DL MAC PDU’s as per stored SPS assignment in slot z+n*[semiPersistSchedIntervalDL] }
}
(6)
with { UE in RRC_Connected state with DRB established and sps-Configuration in DL is enabled }
ensure that {
when { UE receives a DL assignment addressed to its stored CS-RNTI in slot p and with NDI set as 0 and PDCCH content indicates deactivation }
then {UE stops receiving DL MAC PDU’s as per stored SPS assignment }
}
7.1.1.6.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in TS 38.321, clause 5.3.1, 5.8.1 TS 38.300, clause 10.2 and TS 38.213 clause 102. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.3.1]
Downlink assignments received on the PDCCH both indicate that there is a transmission on a DL-SCH for a particular MAC entity and provide the relevant HARQ information.
When the MAC entity has a C-RNTI, Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion during which it monitors PDCCH and for each Serving Cell:
1> if a downlink assignment for this PDCCH occasion and this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI, or Temporary C‑RNTI:
2> if this is the first downlink assignment for this Temporary C-RNTI:
3> consider the NDI to have been toggled.
2> if the downlink assignment is for the MAC entity’s C-RNTI, and if the previous downlink assignment indicated to the HARQ entity of the same HARQ process was either a downlink assignment received for the MAC entity’s CS-RNTI or a configured downlink assignment:
3> consider the NDI to have been toggled regardless of the value of the NDI.
2> indicate the presence of a downlink assignment and deliver the associated HARQ information to the HARQ entity.
1> else if a downlink assignment for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> indicate the presence of a downlink assignment for this Serving Cell and deliver the associated HARQ information to the HARQ entity.
2> if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate SPS deactivation:
4> clear the configured downlink assignment for this Serving Cell (if any);
4> if the timeAlignmentTimer, associated with the TAG containing the Serving Cell on which the HARQ feedback is to be transmitted,is running:
5> indicate a positive acknowledgement for the SPS deactivation to the physical layer.
3> else if PDCCH content indicates SPS activation:
4> store the downlink assignment for this Serving Cell and the associated HARQ information as configured downlink assignment;
4> initialise or re-initialise the configured downlink assignment for this Serving Cell to start in the associated PDSCH duration and to recur according to rules in subclause 5.8.1;
For each Serving Cell and each configured downlink assignment, if configured and activated, the MAC entity shall:
1> if the PDSCH duration of the configured downlink assignment does not overlap with the PDSCH duration of a downlink assignment received on the PDCCH for this Serving Cell:
2> instruct the physical layer to receive, in this PDSCH duration, transport block on the DL-SCH according to the configured downlink assignment and to deliver it to the HARQ entity;
2> set the HARQ Process ID to the HARQ Process ID associated with this PDSCH duration;
2> consider the NDI bit for the corresponding HARQ process to have been toggled;
2> indicate the presence of a configured downlink assignment and deliver the stored HARQ information to the HARQ entity.
For configured downlink assignments, the HARQ Process ID associated with the slot where the DL transmission starts is derived from the following equation:
HARQ Process ID = [floor (CURRENT_slot × 10 / (numberOfSlotsPerFrame ×periodicity ))] modulo nrofHARQ-Processes
where CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + slot number in the frame] and numberOfSlotsPerFrame refers to the number of consecutive slots per frame as specified in TS 38.211 [8].
When the MAC entity needs to read BCCH, the MAC entity may, based on the scheduling information from RRC:
1> if a downlink assignment for this PDCCH occasion has been received on the PDCCH for the SI-RNTI;
2> indicate a downlink assignment and redundancy version for the dedicated broadcast HARQ process to the HARQ entity.
[TS 38.321, clause 5.8.1]
Semi-Persistent Scheduling (SPS) is configured by RRC per Serving Cell and per BWP. Activation and deactivation of the DL SPS are independent among the Serving Cells.
For the DL SPS, a DL assignment is provided by PDCCH, and stored or cleared based on L1 signalling indicating SPS activation or deactivation.
RRC configures the following parameters when SPS is configured:
– cs-RNTI: CS-RNTI for activation, deactivation, and retransmission;
– nrofHARQ-Processes: the number of configured HARQ processes for SPS;
– periodicity: periodicity of configured downlink assignment for SPS.
When SPS is released by upper layers, all the corresponding configurations shall be released.
After a downlink assignment is configured for SPS, the MAC entity shall consider sequentially that the Nth downlink assignment occurs in the slot for which:
(numberOfSlotsPerFrame × SFN + slot number in the frame) =
[(numberOfSlotsPerFrame × SFNstart time + slotstart time) + N × periodicity × numberOfSlotsPerFrame / 10] modulo (1024 × numberOfSlotsPerFrame)
where SFNstart time and slotstart time are the SFN and slot, respectively, of the first transmission of PDSCH where the configured downlink assignment was (re-)initialised.
[TS 38.300, clause 10.2]
In the downlink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible assignments when its downlink reception is enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI applies to all serving cells.
The gNB may pre-empt an ongoing PDSCH transmission to one UE with a latency-critical transmission to another UE. The gNB can configure UEs to monitor interrupted transmission indications using INT-RNTI on a PDCCH. If a UE receives the interrupted transmission indication, the UE may assume that no useful information to that UE was carried by the resource elements included in the indication, even if some of those resource elements were already scheduled to this UE.
In addition, with Semi-Persistent Scheduling (SPS), the gNB can allocate downlink resources for the initial HARQ transmissions to UEs: RRC defines the periodicity of the configured downlink assignments while PDCCH addressed to CS-RNTI can either signal and activate the configured downlink assignment, or deactivate it; i.e. a PDCCH addressed to CS-RNTI indicates that the downlink assignment can be implicitly reused according to the periodicity defined by RRC, until deactivated.
NOTE: when required, retransmissions are explicitly scheduled on PDCCH(s).
The dynamically allocated downlink reception overrides the configured downlink assignment in the same serving cell, if they overlap in time. Otherwise a downlink reception according to the configured downlink assignment is assumed, if activated.
When CA is configured, at most one configured downlink assignment can be signalled per serving cell. When BA is configured, at most one configured downlink assignment can be signalled per BWP. On each serving cell, there can be only one configured downlink assignment active at a time, and multiple configured downlink assignment can be simultaneously active on different serving cells only. Activation and deactivation of configured downlink assignments are independent among the serving cells.
[TS 38.213, clause 10.2]
A UE validates, for scheduling activation or scheduling release, a DL SPS assignment PDCCH or configured UL grant Type 2 PDCCH if
– the CRC of a corresponding DCI format is scrambled with a CS-RNTI provided by cs-RNTI, and
– the new data indicator field for the enabled transport block is set to ‘0’.
Validation of the DCI format is achieved if all fields for the DCI format are set according to Table 10.2-1 or Table 10.2-2.
If validation is achieved, the UE considers the information in the DCI format as a valid activation or valid release of DL SPS or configured UL grant Type 2. If validation is not achieved, the UE discards all the information in the DCI format.
Table 10.2-1: Special fields for DL SPS and UL grant Type 2 scheduling activation PDCCH validation
DCI format 0_0/0_1 |
DCI format 1_0 |
DCI format 1_1 |
|
HARQ process number |
set to all ‘0’s |
set to all ‘0’s |
set to all ‘0’s |
Redundancy version |
set to ’00’ |
set to ’00’ |
For the enabled transport block: set to ’00’ |
Table 10.2-2: Special fields for DL SPS and UL grant Type 2 scheduling release PDCCH validation
DCI format 0_0 |
DCI format 1_0 |
|
HARQ process number |
set to all ‘0’s |
set to all ‘0’s |
Redundancy version |
set to ’00’ |
set to ’00’ |
Modulation and coding scheme |
set to all ‘1’s |
set to all ‘1’s |
Frequency domain resource assignment |
set to all ‘1’s |
set to all ‘1’s |
A UE is expected to provide HARQ-ACK information in response to a SPS PDSCH release after {} symbols from the last symbol of a PDCCH providing the SPS PDSCH release. If processingType2Enabled of PDSCH-ServingCellConfig is set to enable for the serving cell with the PDCCH providing the SPS PDSCH release, for , for , and for , otherwise, for , for , for , and for , wherein corresponds to the smallest SCS configuration between the SCS configuration of the PDCCH providing the SPS PDSCH release and the SCS configuration of a PUCCH carrying the HARQ-ACK information in response to a SPS PDSCH release.
7.1.1.6.1.3 Test description
7.1.1.6.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.6.1.3.2 Test procedure sequence
Table 7.1.1.6.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits a DL assignment using UE’s CS-RNTI in Slot ‘Y’, NDI=0. |
<– |
(DL SPS Grant) |
– |
– |
2 |
The SS transmits in Slot ‘Y’, a DL MAC PDU containing a RLC PDU (DL-SQN=0) on UM DRB. |
<– |
MAC PDU |
– |
– |
3 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
4 |
The SS transmits in Slot ‘Y+X’, a DL MAC PDU containing a RLC PDU (DL-SQN=1) on DRB. (Note 1) |
<– |
MAC PDU |
– |
– |
5 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
6 |
The SS transmits a DL assignment using UE’s CS-RNTI in Slot ‘P’, NDI=0; (Where Y+X<P<Y+2X) |
<– |
(DL SPS Grant) |
– |
– |
7 |
The SS transmits in Slot ‘P’, a DL MAC PDU containing a RLC PDU (DL-SQN=2) on UM DRB. |
<– |
MAC PDU |
– |
– |
8 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
2 |
P |
9 |
The SS transmits in Slot ‘Y+2X’, a DL MAC PDU containing a RLC PDU (DL-SQN=3) on UM DRB. |
<– |
MAC PDU |
– |
– |
10 |
Check: Does the UE transmit a HARQ Feedback? |
–> |
HARQ ACK/NACK |
2 |
F |
11 |
The SS transmits a DL assignment using UE’s C-RNTI in Slot ‘P+X’, NDI=0. |
<– |
(DL Grant) |
– |
– |
12 |
The SS transmits in Slot ‘P+X’, a DL MAC PDU containing a RLC PDU (DL-SQN=3)on UM DRB.(Note2) |
<– |
MAC PDU |
– |
– |
13 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
4 |
P |
14 |
The SS transmits in Slot ‘P+2X’, a DL MAC PDU containing a RLC PDU (DL-SQN=4) on UM DRB. |
<– |
MAC PDU |
– |
– |
15 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
16 |
The SS transmits a DL assignment using UE’s CS-RNTI in Slot ‘P+3X’, NDI=0. |
<– |
(DL SPS Grant) |
– |
– |
17 |
The SS transmits in Slot ‘P+3X’, a DL MAC PDU containing 1 RLC PDU’s (DL-SQN=5) on UM DRB; CRC is calculated in such a way will result in CRC error in UE. |
<– |
MAC PDU |
– |
– |
18 |
Check: Does the UE transmit a HARQ NACK? |
–> |
HARQ NACK |
– |
– |
– |
EXCEPTION: Step 19 and 20 shall be repeated until HARQ retransmission count = 3 is reached for MAC PDU at step 17.(Note 3) |
– |
– |
– |
– |
19 |
The SS transmits a DL assignment using UE’s CS-RNTI in Slot ‘Z’, NDI=1; Where (P+3X < Z <P+4X); The DL HARQ process is same as in step 18. |
<– |
(DL SPS Grant) |
– |
– |
20 |
The SS re-transmits in Slot ‘Z’, a DL MAC PDU containing a RLC PDU (DL-SQN=5) on UM DRB. |
<– |
MAC PDU |
– |
– |
– |
EXCEPTION: Up to 3 HARQ NACK from the UE should be allowed at step 21(Note 3). |
– |
– |
– |
– |
21 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
3 |
P |
22 |
The SS Transmits a PDCCH [for DL SPS deactivation] using UE’s CS-RNTI in slot ‘Q’, NDI=0; Where (P+3X< Q <P+4X). |
<– |
PDCCH [for DL SPS explicit release] |
– |
– |
23 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
6 |
P |
24 |
The SS transmits in Slot ‘P+5X’, a DL MAC PDU containing 1 RLC PDU’s (DL-SQN=6)on UM DRB; |
<– |
MAC PDU |
– |
– |
25 |
Check: Does the UE transmit a HARQ Feedback? |
–> |
HARQ ACK/NACK |
6 |
F |
26 |
The SS Transmits a DL assignment using UE’s CS-RNTI in SF-Num ‘P+6X’, NDI=0 |
<– |
(DL SPS Grant) |
– |
– |
27 |
The SS transmits in SF-Num ‘P+6X’, a DL MAC PDU containing a RLC PDU (DL-SQN=6)on UM DRB |
<– |
MAC PDU |
– |
– |
28 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
29 |
SS transmits NR RRCReconfiguration to disable SPS-ConfigurationDL.(Note 4) |
<– |
RRCReconfiguration |
– |
– |
30 |
The UE transmits NR RRCReconfigurationComplete.(Note5) |
–> |
RRCReconfigurationComplete |
– |
– |
31 |
The SS transmits in Slot ‘P+5X’, a DL MAC PDU containing 1 RLC PDU’s (DL-SQN=7) on UM DRB; |
<– |
MAC PDU |
– |
– |
32 |
Check: Does the UE transmit a HARQ Feedback? |
–> |
HARQ ACK/NACK |
5 |
F |
Note 1: X is equal to semiPersistSchedIntervalDL in this document. Note 2: The DL assignment for C-RNTI and hence the size of MAC PDU is different in size than stored CS-RNTI DL assignment in step 6. This assures UE is receiving DSCH data as per DL assignment for C-RNTI and not as per stored grant for CS-RNTI. Note 3: The value 4 for the maximum number of HARQ retransmissions has been chosen based on an assumption that, given the radio conditions used in this test case, a UE soft combiner implementation should have sufficient retransmissions to be able to successfully decode the data in its soft buffer. Note 4: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 5: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 6: As per TS 38.508-1[4], the default value for PDSCH slot offset (K0) is 0, hence the DL MAC PDU’s associated with DL SPS grant in Slot X are sent in same slot X. |
7.1.1.6.1.3.3 Specific message contents
Table 7.1.1.6.1.3.3-1: RRCReconfiguration (Preamble)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
Not present |
NR |
||
nonCriticalExtension := SEQUENCE{} |
Not present |
EN-DC |
|
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.1.3.3-2: CellGroupConfig (Table 7.1.1.6.1.3.3-2)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
CellGroupConfig ::= SEQUENCE { |
||||
spCellConfig SEQUENCE { |
||||
servCellIndex |
1 |
|||
Not present |
NR |
|||
spCellConfigDedicated SEQUENCE { |
||||
initialDownlinkBWP SEQUENCE { |
||||
sps-Config CHOICE { |
||||
setup SEQUENCE { |
||||
periodicity |
ms40 |
|||
nrofHARQ-Processes |
8 |
|||
n1PUCCH-AN SEQUENCE{ |
||||
pucch-ResourceId |
0 |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
physicalCellGroupConfig SEQUENCE { |
||||
cs-RNTI CHOICE { |
||||
setup SEQUENCE{ |
||||
RNTI-Value |
‘FFE0’H |
|||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.6.1.3.3-3: RRCReconfiguration (step 29 of Table 7.1.1.6.1.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
Not present |
NR |
||
nonCriticalExtension := SEQUENCE{} |
Not present |
EN-DC |
|
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.1.3.3-4: CellGroupConfig (Table 7.1.1.6.1.3.3-3)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
CellGroupConfig ::= SEQUENCE { |
||||
spCellConfig SEQUENCE { |
||||
servCellIndex |
1 |
|||
Not present |
NR |
|||
spCellConfigDedicated SEQUENCE { |
||||
initialDownlinkBWP SEQUENCE { |
||||
sps-Config CHOICE { |
||||
release |
Null |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
7.1.1.6.2 Correct handling of UL grant / configured grant Type 1
7.1.1.6.2.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state with DRB established and sps-Configuration in UL is enabled with Configured grant type 1 }
ensure that {
when { The symbol in which equation [(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
(timeDomainOffset × numberOfSymbolsPerSlot + S + N × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot)is satisfied }
then { UE starts transmitting UL MAC PDU periodically in the symbol associated with the new re-configured grant }
}
(2)
with { UE in RRC_Connected state with DRB established and configured UL grant type 1 }
ensure that {
when { UE receives a new UL grant type 1 in an RRC message }
then { UE starts transmitting UL MAC PDU periodically in the symbol associated with the new re-configured grant }
}
(3)
with { UE in RRC_Connected state with DRB established and configured UL grant type 1 }
ensure that {
when { UE receives a RRC message including sps-Configuration with rrcConfiguredUplinkGrant set as ‘release’ }
then { UE deletes the stored configured UL Grant type 1 parameters and stops transmitting UL MAC PDU’s as per configured UL grant type 1 }
}
(4)
with { UE in RRC_Connected state with DRB established and configured UL grant type 1 }
ensure that {
when { UE receives a UL grant addressed to its CS-RNTI with NDI set as 1 for retransmission }
then { UE re-transmits MAC PDU as per the new grant }
}
(5)
with { UE in RRC_Connected state with DRB established and configured UL grant type 1 }
ensure that {
when { UE receives a UL grant addressed to its C-RNTI resulting in UL transmission overlap in time domain as configured grante type 1 }
then { UE transmits MAC PDU as per grant addressed to its C-RNTI }
}7.1.1.6.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321 clauses 5.4.1 and 5.8.2, 3GPP TS 38.300 clause 10.3. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.1]
Uplink grant is either received dynamically on the PDCCH, in a Random Access Response, or configured semi-persistently by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To perform the requested transmissions, the MAC layer receives HARQ information from lower layers.
If the MAC entity has a C-RNTI, a Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer and for each grant received for this PDCCH occasion:
1> if an uplink grant for this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or
1> if an uplink grant has been received in a Random Access Response:
2> if the uplink grant is for MAC entity’s C-RNTI and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was either an uplink grant received for the MAC entity’s CS-RNTI or a configured uplink grant:
3> consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.
2> if the uplink grant is for MAC entity’s C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured.
2> deliver the uplink grant and the associated HARQ information to the HARQ entity.
1> else if an uplink grant for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured;
3> deliver the uplink grant and the associated HARQ information to the HARQ entity.
2> else if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate configured grant Type 2 deactivation:
4> trigger configured uplink grant confirmation.
3> else if PDCCH contents indicate configured grant Type 2 activation:
4> trigger configured uplink grant confirmation;
4> store the uplink grant for this Serving Cell and the associated HARQ information as configured uplink grant;
4> initialise or re-initialise the configured uplink grant for this Serving Cell to start in the associated PUSCH duration and to recur according to rules in subclause 5.8.2;
4> stop the configuredGrantTimer for the corresponding HARQ process, if running;
For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall:
1> if the PUSCH duration of the configured uplink grant does not overlap with the PUSCH duration of an uplink grant received on the PDCCH or in a Random Access Response for this Serving Cell:
2> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
2> if the configuredGrantTimer for the corresponding HARQ process is not running:
3> consider the NDI bit for the corresponding HARQ process to have been toggled;
3> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For configured uplink grants, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo nrofHARQ-Processes
where CURRENT_symbol=(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slot number in the frame × numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS 38.211 [8].
NOTE 1: CURRENT_symbol refers to the symbol index of the first transmission occasion of a repetition bundle that takes place.
NOTE 2: A HARQ process is configured for a configured uplink grant if the configured uplink grant is activated and the associated HARQ process ID is less than nrofHARQ-Processes.
NOTE 3: If the MAC entity receives both a grant in a Random Access Response and an overlapping grant for its C-RNTI or CS-RNTI, requiring concurrent transmissions on the SpCell, the MAC entity may choose to continue with either the grant for its RA-RNTI or the grant for its C-RNTI or CS-RNTI.
[TS 38.321, clause 5.8.2]
There are two types of transmission without dynamic grant:
– configured grant Type 1 where an uplink grant is provided by RRC, and stored as configured uplink grant;
– configured grant Type 2 where an uplink grant is provided by PDCCH, and stored or cleared as configured uplink grant based on L1 signalling indicating configured uplink grant activation or deactivation.
Type 1 and Type 2 are configured by RRC per Serving Cell and per BWP. Multiple configurations can be active simultaneously only on different Serving Cells. For Type 2, activation and deactivation are independent among the Serving Cells. For the same Serving Cell, the MAC entity is configured with either Type 1 or Type 2.
RRC configures the following parameters when the configured grant Type 1 is configured:
– cs-RNTI: CS-RNTI for retransmission;
– periodicity: periodicity of the configured grant Type 1;
– timeDomainOffset: Offset of a resource with respect to SFN=0 in time domain;
– timeDomainAllocation: Allocation of configured uplink grant in time domain which contains startSymbolAndLength (i.e. SLIV in TS 38.214 [7]);
– nrofHARQ-Processes: the number of HARQ processes for configured grant.
RRC configures the following parameters when the configured grant Type 2 is configured:
– cs-RNTI: CS-RNTI for activation, deactivation, and retransmission;
– periodicity: periodicity of the configured grant Type 2;
– nrofHARQ-Processes: the number of HARQ processes for configured grant.
Upon configuration of a configured grant Type 1 for a Serving Cell by upper layers, the MAC entity shall:
1> store the uplink grant provided by upper layers as a configured uplink grant for the indicated Serving Cell;
1> initialise or re-initialise the configured uplink grant to start in the symbol according to timeDomainOffset and S (derived from SLIV as specified in TS 38.214 [7]), and to reoccur with periodicity.
After an uplink grant is configured for a configured grant Type 1, the MAC entity shall consider that the uplink grant recurs associated with each symbol for which:
[(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
(timeDomainOffset × numberOfSymbolsPerSlot + S + N × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot), for all N >= 0.
After an uplink grant is configured for a configured grant Type 2, the MAC entity shall consider that the uplink grant recurs associated with each symbol for which:
[(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
[(SFNstart time × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slotstart time × numberOfSymbolsPerSlot + symbolstart time) + N × periodicity] modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot), for all N >= 0.
where SFNstart time, slotstart time, and symbolstart time are the SFN, slot, and symbol, respectively, of the first transmission opportunity of PUSCH where the configured uplink grant was (re-)initialised.
When a configured uplink grant is released by upper layers, all the corresponding configurations shall be released and all corresponding uplink grants shall be cleared.
The MAC entity shall:
1> if the configured uplink grant confirmation has been triggered and not cancelled; and
1> if the MAC entity has UL resources allocated for new transmission:
2> instruct the Multiplexing and Assembly procedure to generate an Configured Grant Confirmation MAC CE as defined in subclause 6.1.3.7;
2> cancel the triggered configured uplink grant confirmation.
For a configured grant Type 2, the MAC entity shall clear the configured uplink grant immediately after first transmission of Configured Grant Confirmation MAC CE triggered by the configured uplink grant deactivation.
Retransmissions except for repetition of configured uplink grants use uplink grants addressed to CS-RNTI.
[TS 38.300, clause 10.3]
In the uplink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible grants for uplink transmission when its downlink reception is enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI applies to all serving cells.
In addition, with Configured Grants, the gNB can allocate uplink resources for the initial HARQ transmissions to UEs. Two types of configured uplink grants are defined:
– With Type 1, RRC directly provides the configured uplink grant (including the periodicity).
– With Type 2, RRC defines the periodicity of the configured uplink grant while PDCCH addressed to CS-RNTI can either signal and activate the configured uplink grant, or deactivate it; i.e. a PDCCH addressed to CS-RNTI indicates that the uplink grant can be implicitly reused according to the periodicity defined by RRC, until deactivated.
The dynamically allocated uplink transmission overrides the configured uplink grant in the same serving cell, if they overlap in time. Otherwise an uplink transmission according to the configured uplink grant is assumed, if activated.
Retransmissions other than repetitions are explicitly allocated via PDCCH(s).
When CA is configured, at most one configured uplink grant can be signalled per serving cell. When BA is configured, at most one configured uplink grant can be signalled per BWP. On each serving cell, there can be only one configured uplink grant active at a time. A configured uplink grant for one serving cell can either be of Type 1 or Type 2. For Type 2, activation and deactivation of configured uplink grants are independent among the serving cells. When SUL is configured, a configured uplink grant can only be signalled for one of the 2 ULs of the cell.
7.1.1.6.2.3 Test description
7.1.1.6.2.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 and UM DRB should be established on NR Cell 1.
7.1.1.6.2.3.2 Test procedure sequence
Table 7.1.1.6.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration messageto configure UL configured grant type 1 in SFN 900, timeDomainOffset is set to 5. (Note 1) |
<– |
(NR RRC: RRCReconfiguration) |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete message. (Note 2) |
–> |
(NR RRC: RRCReconfigurationComplete) |
– |
– |
3 |
SS transmits a DL MAC PDU containing 4 RLC SDUs of size 96 bytes in SFN 1022 on UM DRB. (Note 3) |
<– |
MAC PDU (nine RLC SDUs) |
– |
– |
4 |
Check: Does the UE transmit a MAC PDU containing first RLC SDU in Symbol ‘x0’, Slot y0’, SFN ‘z0’ after the SFN in step 3 wraps around? Where [(z0 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y0 × numberOfSymbolsPerSlot) + x0] = (5 × numberOfSymbolsPerSlot + S + 0 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). (Note 4) |
–> |
MAC PDU (one RLC SDU) |
1 |
P |
5 |
Check: Does the UE transmit a MAC PDU containing second RLC SDU in Symbol ‘x1’, Slot y1’, SFN ‘z1’? Where [(z1 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y1 × numberOfSymbolsPerSlot) + x1] = (5 × numberOfSymbolsPerSlot + S + 1 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
1 |
P |
6 |
SS transmits NR RRCReconfiguration message to configure UL configured grant type 1 in SFN ‘z1 + 1’, timeDomainOffset is set to 35. |
<– |
(NR RRC: RRCReconfiguration) |
– |
– |
7 |
The UE transmits NR RRCReconfigurationComplete. message |
–> |
(NR RRC: RRCReconfigurationComplete) |
– |
– |
8 |
Check: Does the UE transmit a MAC PDU containing third RLC SDU received in step 4 in Symbol ‘x2’, Slot y2’, SFN ‘z2’? Where [(z2 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y2 × numberOfSymbolsPerSlot) + x2] = (5 × numberOfSymbolsPerSlot + S + N × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot), N >= 2. |
–> |
MAC PDU (one RLC SDU) |
2 |
F |
9 |
Check: Does the UE transmit a MAC PDU containing fourth RLC SDU in Symbol ‘x3’, Slot y3’, SFN ‘z3’ after the SFN in step 8 wraps around? Where [(z3 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y3 × numberOfSymbolsPerSlot) + x3] = (35 × numberOfSymbolsPerSlot + S + 0 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
2 |
P |
10 |
Check: Does the UE transmit a MAC PDU containing fifth RLC SDU in Symbol ‘x4’, Slot y4’, SFN ‘z4’? Where [(z4 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y4 × numberOfSymbolsPerSlot) + x4] = (35 × numberOfSymbolsPerSlot + S + 1 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
2 |
P |
11 |
SS transmits a UL grant addressed to UE’s stored CS-RNTI with NDI set as 1 in Slot ‘p0’of PDCCH (p0 = floor ((y4 +2) * (PDCCHSCS / PUSCHSCS))), allowing the UE to retransmit one loop back SDU. |
<– |
(UL Grant) |
– |
– |
12 |
Check: Does the UE retransmit the MAC PDU containing the same fifth RLC SDU as in step 10 in Symbol ‘S’ of Slot ‘q’ of PUSCH? i.e., in the PUSCH slot q = floor (p0 * (PUSCHSCS / PDCCHSCS)) + K2. (Note 5) |
–> |
MAC PDU (one RLC SDU) |
4 |
P |
13 |
Check: Does the UE transmit a MAC PDU containing sixth RLC SDU in Symbol ‘x5’, Slot y5’, SFN ‘z5’? Where [(z5 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y5 × numberOfSymbolsPerSlot) + x5] = (35 × numberOfSymbolsPerSlot + S + 2 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
1 |
P |
14 |
SS transmits a UL Grant using UE’s C-RNTI in in Slot ‘p1’ of PDCCH allowing UE to transmit a MAC PDU containing two RLC SDU, where p1 = floor ((z6 × numberOfSlotsPerFrame – K2) * (PDCCHSCS / PUSCHSCS)). (Note 6) Where [(z6 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y6 × numberOfSymbolsPerSlot) + x6] = (35 × numberOfSymbolsPerSlot + S + 3 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
<– |
(UL Grant) |
– |
– |
15 |
Check: Does the UE transmit a MAC PDU containing seventh and eight RLC SDU’s in Symbol ‘x6’, Slot y6’, SFN ‘z6’? |
–> |
MAC PDU (two RLC SDU’s) |
5 |
P |
16 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘x7’, Slot y7’, SFN ‘z7’? Where [(z7 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y7 × numberOfSymbolsPerSlot) + x7] = (35 × numberOfSymbolsPerSlot + S + 4 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
1 |
P |
17 |
After step 16, SS transmits NR RRCReconfiguration message to release UL configured grant type 1 in SFN ‘z4 + 1’. |
<– |
(NR RRC: RRCReconfiguration |
– |
– |
18 |
The UE transmits NR RRCReconfigurationComplete message. |
–> |
(NR RRC: RRCReconfigurationComplete |
– |
– |
19 |
SS transmits a DL MAC PDU containing one RLC SDU of size 96 bytes in SFN ‘z7 + 10’. |
<– |
MAC PDU (one RLC SDU) |
||
20 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘x8’, Slot y8’, SFN ‘z8’? Where [(z8 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y8 × numberOfSymbolsPerSlot) + x8] = (35 × numberOfSymbolsPerSlot + S + 8 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
3 |
F |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: According to the setting parameters in Table 7.1.1.6.2.3.3-2, TB size for configured grant type 1 is 808 bits, which is enough to allow the UE to transmit one PDU at a time (96 bytes RLC SDU + 1 byte UM RLC Header + 2 bytes MAC Sub PDU header + 2 bytes for short BSR or padding). Note 4: S is the starting symbol relative to the slot of the first PUSCH transmission for new configured grant type 1. The value of S can be obtained from TS 38.508-1 [4], Table 4.6.3-122. Note 5: q is the slot where the UE shall transmit the PUSCH and is determined by as where is the slot with the scheduling DCI, is based on the numerology of PUSCH. S is the starting symbol relatived to the start of the slot q according to TS 38.214 clause 6.1.2.1. Note 6: The UL grant addressed to C-RNTI should result in UL transmission overlap in time domain as configured grant type 1. |
7.1.1.6.2.3.3 Specific message contents
Table 7.1.1.6.2.3.3-1: RRCReconfiguration (step 1 and step 6, Table 7.1.1.6.2.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
||||||
Information Element |
Value/remark |
Comment |
Condition |
|||
RRCReconfiguration ::= SEQUENCE { |
||||||
criticalExtensions CHOICE { |
||||||
rrcReconfiguration SEQUENCE { |
||||||
radioBearerConfig |
Not present |
|||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|||
Not Present |
NR |
|||||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
||||
nonCriticalExtension := SEQUENCE{ |
NR |
|||||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||||
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
|||||
} |
||||||
} |
||||||
} |
||||||
} |
Table 7.1.1.6.2.3.3-2: CellGroupConfig (Table 7.1.1.6.2.3.3-2: RRCReconfiguration)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
rlc-BearerToAddModList |
Not present |
||
mac-CellGroupConfig |
Not present |
||
physicalCellGroupConfig SEQUENCE { |
|||
cs-RNTI CHOICE { |
|||
setup SEQUENCE{ |
|||
RNTI-Value |
‘FFE0’H |
||
} |
|||
} |
|||
} |
|||
spCellConfig SEQUENCE{ |
|||
servCellIndex |
Not present |
NR |
|
1 |
EN-DC |
||
reconfigurationWithSync |
Not present |
||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplink SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
schedulingRequestResourceToAddModList { |
|||
schedulingRequestResourceId |
1 |
||
schedulingRequestID |
0 |
||
periodicityAndOffset CHOICE { |
|||
sl20 |
10 |
||
} |
|||
} |
|||
} |
|||
} |
|||
configuredGrantConfig CHOICE { |
|||
setup SEQUENCE { |
|||
cg-DMRS-Configuration |
DMRS-UplinkConfig |
Reference TS 38.508-1[4], Table 4.6.3-51 |
|
uci-OnPUSCH CHOICE { |
|||
setup SEQUENCE { |
|||
semiStatic SEQUENCE { |
BetaOffsets |
||
betaOffsetACK-Index1 |
9 |
||
betaOffsetACK-Index2 |
9 |
||
betaOffsetACK-Index3 |
9 |
||
betaOffsetCSI-Part1-Index1 |
6 |
||
betaOffsetCSI-Part1-Index2 |
6 |
||
betaOffsetCSI-Part2-Index1 |
6 |
||
betaOffsetCSI-Part2-Index2 |
6 |
||
} |
|||
} |
|||
} |
|||
resourceAllocation |
ResourceAllocationType1 |
||
powerControlLoopToUse |
n0 |
||
p0-PUSCH-Alpha |
1 |
||
nrofHARQ-Processes |
16 |
||
repK |
n1 |
||
periodicity |
Sym40x14 |
15kHz |
|
periodicity |
Sym80x14 |
30kHz |
|
periodicity |
Sym160x14 |
60kHz |
|
periodicity |
Sym320x14 |
120kHz |
|
rrc-ConfiguredUplinkGrant SEQUENCE{ |
|||
timeDomainOffset |
5 |
For Step 1 |
|
35 |
For Step 6 |
||
timeDomainAllocation |
0 |
Reference TS 38.508-1 [4], Table 4.6.3-122 |
|
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB = 2 PRB, RBstart = 0, NBWPsize is the size [PRBs] of the active carrier bandwidth part and ontained in TS.38.508-1 [4] clause 4.3.1.1. |
FR1_FDD, FR1_TDD |
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB=9 PRB, RBstart = 0and NBWPsize is the size [PRBs] of the active carrier bandwidth part and ontained in TS.38.508-1 [4] clause 4.3.1.2. |
FR2_TDD |
antennaPort |
0 |
||
precodingAndNumberOfLayers |
0 |
||
srs-ResourceIndicator |
Not present |
||
mcsAndTBS |
18 |
FR1_FDD, FR1_TDD |
|
25 |
FR2_TDD |
||
pathlossReferenceIndex |
0 |
||
} |
|||
} |
|||
} |
|||
pusch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
PUSCH-TimeDomainResourceAllocationList SEQUENCE { |
|||
k2 |
n8 |
FR1 and FR2 |
|
mappingType |
typeB |
||
startSymbolAndLength |
0011011 |
Start symbol(S)=0, Length(L)=14 |
FR1 |
startSymbolAndLength |
0001110 |
S=0, L=2 |
FR2 |
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.2.3.3-3: RRCReconfiguration (step 11, Table 7.1.1.6.2.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
||||||
Information Element |
Value/remark |
Comment |
Condition |
|||
RRCReconfiguration ::= SEQUENCE { |
||||||
criticalExtensions CHOICE { |
||||||
rrcReconfiguration SEQUENCE { |
||||||
radioBearerConfig |
Not present |
|||||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
|||
Not present |
NR |
|||||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
||||
nonCriticalExtension := SEQUENCE{ |
NR |
|||||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||||
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
|||||
} |
||||||
} |
||||||
} |
||||||
} |
Table 7.1.1.6.2.3.3-4: CellGroupConfig (Table 7.1.1.6.2.3.3-3: RRCReconfiguration)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
spCellConfig SEQUENCE{ |
|||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplink SEQUENCE { |
|||
configuredGrantConfig CHOICE { |
|||
release |
Null |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
7.1.1.6.3 Correct handling of UL grant / configured grant Type 2
7.1.1.6.3.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state with DRB established and sps-Configuration in UL is enabled }
ensure that {
when { UE receives an UL configured grant type 2 addressed to its stored CS-RNTI with NDI set as 0 and PDCCH content indicates SPS activation }
then { UE starts transmitting UL MAC PDU periodically in the symbol associated with the configured grant }
}
(2)
with { UE in RRC_Connected state with DRB established and configured UL grant type 2 }
ensure that {
when {UE receives a UL grant addressed to its CS-RNTI with NDI set as 0 }
then { UE starts transmitting UL MAC PDU periodically in the symbol associated with the new re-configured grant }
}
(3)
with { UE in RRC_Connected state with DRB established and configured UL grant type 2 }
ensure that {
when { UE receives a UL grant addressed to its CS-RNTI with NDI set as 1 for retransmission }
then { UE re-transmits MAC PDU as per the new grant }
}
(4)
with{ UE in RRC_Connected state with DRB established and configured UL grant type 2 }
ensure that {
when { UE receives a UL grant addressed to its C-RNTI resulting in UL transmission overlap in time domain as configured grante type 2 }
then { UE transmits MAC PDU as per grant addressed to its C-RNTI }
}
(5)
with { UE in RRC_Connected state with DRB established and configured UL grant type 2 }
ensure that {
when {UE receives a RRC message including sps-Configuration with sps-ConfigurationUL set as ‘disable’ and hence resulting in UL SPS grant deactivation }
then { UE deletes the stored sps-Configuration UL parameters and stops transmitting UL MAC PDU’s as per configured UL grant type 2 }
}
(6)
with{ UE in RRC_Connected state with DRB established and configured UL grant type 2 }
ensure that {
when{ If in the symbol in which UL Configured Grant type 2 is available but the HARQ buffer is empty (no data for transmission) }
then{ UE ignores the UL configured grant type 2 and does not send any MAC PDU }
}
(7)
with { UE in RRC_Connected state with DRB established and sps-Configuration in UL is enabled }
ensure that {
when { UE receives UL configured grant type 2 addressed to its stored CS-RNTI in slot p and with NDI set as 0 and PDCCH content indicates SPS deactivation }
then { UE transmits configured Grant Confirmation MAC CE confirming the deactivation and stops transmitting UL MAC PDU’s as per configured UL grant type 2}
}
7.1.1.6.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321 clauses 5.4.1 and 5.8.2, 3GPP TS 38.300 clauses 10.3 and TS 38.213 clause 102. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.4.1]
Uplink grant is either received dynamically on the PDCCH, in a Random Access Response, or configured semi-persistently by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To perform the requested transmissions, the MAC layer receives HARQ information from lower layers.
If the MAC entity has a C-RNTI, a Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer and for each grant received for this PDCCH occasion:
1> if an uplink grant for this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or
1> if an uplink grant has been received in a Random Access Response:
2> if the uplink grant is for MAC entity’s C-RNTI and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was either an uplink grant received for the MAC entity’s CS-RNTI or a configured uplink grant:
3> consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.
2> if the uplink grant is for MAC entity’s C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
3> start or restart the configuredGrantTimer for the correponding HARQ process, if configured.
2> deliver the uplink grant and the associated HARQ information to the HARQ entity.
1> else if an uplink grant for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured;
3> deliver the uplink grant and the associated HARQ information to the HARQ entity.
2> else if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate configured grant Type 2 deactivation:
4> trigger configured uplink grant confirmation.
3> else if PDCCH contents indicate configured grant Type 2 activation:
4> trigger configured uplink grant confirmation;
4> store the uplink grant for this Serving Cell and the associated HARQ information as configured uplink grant;
4> initialise or re-initialise the configured uplink grant for this Serving Cell to start in the associated PUSCH duration and to recur according to rules in subclause 5.8.2;
4> stop the configuredGrantTimer for the corresponding HARQ process, if running;
For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall:
1> if the PUSCH duration of the configured uplink grant does not overlap with the PUSCH duration of an uplink grant received on the PDCCH or in a Random Access Response for this Serving Cell:
2> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
2> if the configuredGrantTimer for the corresponding HARQ process is not running:
3> consider the NDI bit for the corresponding HARQ process to have been toggled;
3> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For configured uplink grants, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo nrofHARQ-Processes
where CURRENT_symbol=(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slot number in the frame × numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS 38.211 [8].
NOTE 1: CURRENT_symbol refers to the symbol index of the first transmission occasion of a repetition bundle that takes place.
NOTE 2: A HARQ process is configured for a configured uplink grant if the configured uplink grant is activated and the associated HARQ process ID is less than nrofHARQ-Processes.
NOTE 3: If the MAC entity receives both a grant in a Random Access Response and an overlapping grant for its C-RNTI or CS-RNTI, requiring concurrent transmissions on the SpCell, the MAC entity may choose to continue with either the grant for its RA-RNTI or the grant for its C-RNTI or CS-RNTI.
[TS 38.321, clause 5.8.2]
There are two types of transmission without dynamic grant:
– configured grant Type 1 where an uplink grant is provided by RRC, and stored as configured uplink grant;
– configured grant Type 2 where an uplink grant is provided by PDCCH, and stored or cleared as configured uplink grant based on L1 signalling indicating configured uplink grant activation or deactivation.
Type 1 and Type 2 are configured by RRC per Serving Cell and per BWP. Multiple configurations can be active simultaneously only on different Serving Cells. For Type 2, activation and deactivation are independent among the Serving Cells. For the same Serving Cell, the MAC entity is configured with either Type 1 or Type 2.
RRC configures the following parameters when the configured grant Type 1 is configured:
– cs-RNTI: CS-RNTI for retransmission;
– periodicity: periodicity of the configured grant Type 1;
– timeDomainOffset: Offset of a resource with respect to SFN=0 in time domain;
– timeDomainAllocation: Allocation of configured uplink grant in time domain which contains startSymbolAndLength (i.e. SLIV in TS 38.214 [7]);
– nrofHARQ-Processes: the number of HARQ processes for configured grant.
RRC configures the following parameters when the configured grant Type 2 is configured:
– cs-RNTI: CS-RNTI for activation, deactivation, and retransmission;
– periodicity: periodicity of the configured grant Type 2;
– nrofHARQ-Processes: the number of HARQ processes for configured grant.
Upon configuration of a configured grant Type 1 for a Serving Cell by upper layers, the MAC entity shall:
1> store the uplink grant provided by upper layers as a configured uplink grant for the indicated Serving Cell;
1> initialise or re-initialise the configured uplink grant to start in the symbol according to timeDomainOffset and S (derived from SLIV as specified in TS 38.214 [7]), and to reoccur with periodicity.
After an uplink grant is configured for a configured grant Type 1, the MAC entity shall consider that the uplink grant recurs associated with each symbol for which:
[(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
(timeDomainOffset × numberOfSymbolsPerSlot + S + N × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot), for all N >= 0.
After an uplink grant is configured for a configured grant Type 2, the MAC entity shall consider that the uplink grant recurs associated with each symbol for which:
[(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
[(SFNstart time × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slotstart time × numberOfSymbolsPerSlot + symbolstart time) + N × periodicity] modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot), for all N >= 0.
where SFNstart time, slotstart time, and symbolstart time are the SFN, slot, and symbol, respectively, of the first transmission opportunity of PUSCH where the configured uplink grant was (re-)initialised.
When a configured uplink grant is released by upper layers, all the corresponding configurations shall be released and all corresponding uplink grants shall be cleared.
The MAC entity shall:
1> if the configured uplink grant confirmation has been triggered and not cancelled; and
1> if the MAC entity has UL resources allocated for new transmission:
2> instruct the Multiplexing and Assembly procedure to generate an Configured Grant Confirmation MAC CE as defined in subclause 6.1.3.7;
2> cancel the triggered configured uplink grant confirmation.
For a configured grant Type 2, the MAC entity shall clear the configured uplink grant immediately after first transmission of Configured Grant Confirmation MAC CE triggered by the configured uplink grant deactivation.
Retransmissions except for repetition of configured uplink grants use uplink grants addressed to CS-RNTI.
[TS 38.300, clause 10.3]
In the uplink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible grants for uplink transmission when its downlink reception is enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI applies to all serving cells.
In addition, with Configured Grants, the gNB can allocate uplink resources for the initial HARQ transmissions to UEs. Two types of configured uplink grants are defined:
– With Type 1, RRC directly provides the configured uplink grant (including the periodicity).
– With Type 2, RRC defines the periodicity of the configured uplink grant while PDCCH addressed to CS-RNTI can either signal and activate the configured uplink grant, or deactivate it; i.e. a PDCCH addressed to CS-RNTI indicates that the uplink grant can be implicitly reused according to the periodicity defined by RRC, until deactivated.
The dynamically allocated uplink transmission overrides the configured uplink grant in the same serving cell, if they overlap in time. Otherwise an uplink transmission according to the configured uplink grant is assumed, if activated.
Retransmissions other than repetitions are explicitly allocated via PDCCH(s).
When CA is configured, at most one configured uplink grant can be signalled per serving cell. When BA is configured, at most one configured uplink grant can be signalled per BWP. On each serving cell, there can be only one configured uplink grant active at a time. A configured uplink grant for one serving cell can either be of Type 1 or Type 2. For Type 2, activation and deactivation of configured uplink grants are independent among the serving cells. When SUL is configured, a configured uplink grant can only be signalled for one of the 2 ULs of the cell.
[TS 38.213, clause 10.2]
A UE validates, for scheduling activation or scheduling release, a DL SPS assignment PDCCH or configured UL grant Type 2 PDCCH if
– the CRC of a corresponding DCI format is scrambled with a CS-RNTI provided by cs-RNTI, and
– the new data indicator field for the enabled transport block is set to ‘0’.
Validation of the DCI format is achieved if all fields for the DCI format are set according to Table 10.2-1 or Table 10.2-2.
If validation is achieved, the UE considers the information in the DCI format as a valid activation or valid release of DL SPS or configured UL grant Type 2. If validation is not achieved, the UE discards all the information in the DCI format.
Table 10.2-1: Special fields for DL SPS and UL grant Type 2 scheduling activation PDCCH validation
DCI format 0_0/0_1 |
DCI format 1_0 |
DCI format 1_1 |
|
HARQ process number |
set to all ‘0’s |
set to all ‘0’s |
set to all ‘0’s |
Redundancy version |
set to ’00’ |
set to ’00’ |
For the enabled transport block: set to ’00’ |
Table 10.2-2: Special fields for DL SPS and UL grant Type 2 scheduling release PDCCH validation
DCI format 0_0 |
DCI format 1_0 |
|
HARQ process number |
set to all ‘0’s |
set to all ‘0’s |
Redundancy version |
set to ’00’ |
set to ’00’ |
Modulation and coding scheme |
set to all ‘1’s |
set to all ‘1’s |
Frequency domain resource assignment |
set to all ‘1’s |
set to all ‘1’s |
A UE is expected to provide HARQ-ACK information in response to a SPS PDSCH release after symbols from the last symbol of a PDCCH providing the SPS PDSCH release. If processingType2Enabled of PDSCH-ServingCellConfig is set to enable for the serving cell with the PDCCH providing the SPS PDSCH release, for , for , and for , otherwise, for , for , for , and for , wherein corresponds to the smallest SCS configuration between the SCS configuration of the PDCCH providing the SPS PDSCH release and the SCS configuration of a PUCCH carrying the HARQ-ACK information in response to a SPS PDSCH release.
7.1.1.6.3.3 Test description
7.1.1.6.3.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 and UM DRB should be established on NR Cell 1.The loop back size is set to accommodate one RLC SDU in UL of same size as one RLC SDU in DL and 1 byte MAC subheader for Configured Grant Confirmation MAC CE.
7.1.1.6.3.3.2 Test procedure sequence
Table 7.1.1.6.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration message to configure UL configured grant type 2. (Note 1) |
<– |
(NR RRC: RRCReconfiguration |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete message. (Note 2) |
–> |
(NR RRC: RRCReconfigurationComplete |
– |
– |
3 |
SS transmits a DL MAC PDU containing 6 RLC SDUs on UM DRB. |
<– |
MAC PDU |
– |
– |
4 |
The UE transmits a Scheduling Request, indicating that loop back SDUs are ready for transmission in UL RLC. |
–> |
(SR) |
– |
– |
5 |
SS transmits a UL configured grant type 2 addressed to UE’s stored CS-RNTI in Slot ‘n’ of PDCCH, NDI=0, allowing the UE to transmit one loop back SDU and 1 byte MAC subheader for Configured Grant Confirmation MAC CE. |
<– |
(UL configured Grant type 2) |
– |
– |
6 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU and a Configured Grant Confirmation MAC CE in Symbol ‘S’ of Slot ‘y’ of PUSCH as per grant in step 5? i.e., in the PUSCH slot y=floor (n * (PUSCHSCS / PDCCHSCS)) + K2. (Note 3) |
–> |
MAC PDU |
1 |
P |
7 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘S’ of Slot ‘y + x’ of PUSCH as per grant in step 5? (Note 4) |
–> |
MAC PDU |
1 |
P |
8 |
SS transmits a UL configured grant type 2 addressed to UE’s stored CS-RNTI in Slot ‘p’ of PDCCH (p = floor (p0 * (PDCCHSCS / PUSCHSCS))), NDI = 0, allowing the UE to transmit one loop back SDU and 1 byte MAC subheader for Configured Grant Confirmation MAC CE, Where p0 is the slot of PUSCH with y + x < p0 < y + 2x – K2. |
<– |
(UL configured Grant type 2) |
– |
– |
9 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU and 1 byte MAC subheader for Configured Grant Confirmation MAC CE in Symbol ‘S’ of Slot ‘z’ of PUSCH as per grant in step 8? i.e., in the PUSCH slot z = floor (p * (PUSCHSCS/ PDCCHSCS)) + K2. (Note 3) |
–> |
MAC PDU |
2 |
P |
10 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘S’ of Slot ‘y + 2x’ as per grant in step 5? |
–> |
MAC PDU |
2 |
F |
11 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘S’ of Slot ‘z + x’ of PUSCH as per grant in step 8? |
–> |
MAC PDU |
2 |
P |
12 |
SS transmits a UL configured grant type 2 addressed to UE’s stored CS-RNTI in Slot ‘q’ of PDCCH (q = floor (q0 * (PDCCHSCS / PUSCHSCS))), NDI = 1; allowing the UE to transmit one loop back SDU. The UL HARQ process is the same as in step 11, Where q0 is the slot of PUSCH with z + x < q0 < z + 2x – K2. |
<– |
(UL configured Grant type 2) |
– |
– |
13 |
Check: Does the UE transmit a MAC PDU containing the same RLC SDU as in step 11 in Symbol ‘S’ of Slot ‘w’ of PUSCH? i.e., in the PUSCH slot w = floor (q * (PUSCHSCS / PDCCHSCS)) + K2. (Note 3) |
–> |
MAC PDU |
3 |
P |
14 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘S’ of Slot ‘z + 2x’ of PUSCH as per grant in step 8? |
–> |
MAC PDU |
1 |
P |
15 |
SS transmits a UL Grant using UE’s C-RNTI in in Slot ‘r’ of PDCCH allowing UE to transmit a MAC PDU containing one RLC SDU, where r = floor ((z + 3x – K2) * (PDCCHSCS / PUSCHSCS)). |
<– |
(UL Grant) |
– |
– |
16 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘S’ of Slot ‘z + 3x’ of PUSCH as per grant in step 8? |
–> |
MAC PDU |
4 |
P |
17 |
Check: Does the UE transmit a MAC PDU in Slot ‘z + 4x’ as per grant in containing zero MAC SDU? (Note 5) |
–> |
MAC PDU |
6 |
F |
18 |
SS transmits a DL MAC PDU containing 3 RLC SDUs on UM DRB after step 17. |
<– |
MAC PDU |
||
19 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in Symbol ‘S’ of Slot ‘z + 5x’ of PUSCH as per grant in step 8? |
–> |
MAC PDU |
1 |
P |
20 |
The SS transmits a PDCCH [for UL configured grant type 2 explicit release] using UE’s CS-RNTI in Symbol ‘S’ of slot ‘p’ with NDI=0. Where (z+5x< p <z+6x). |
<– |
PDCCH [for UL configured grant type 2 explicit release] |
– |
– |
21 |
Check: Does the UE transmit a MAC PDU containing a Configured Grant Confirmation MAC CE and one RLC SDU in ‘S’ of Slot ‘z + 6x’ of PUSCH as per grant in step 8? |
–> |
MAC PDU |
7 |
P |
21A |
Check: Does the UE transmit a MAC PDU containing one RLC SDU in ‘S’ of Slot ‘z + 7x’ of PUSCH as per grant in step 8? |
–> |
MAC PDU |
7 |
F |
22 |
SS transmits a UL configured grant type 2 addressed to UE’s stored CS-RNTI in Slot ‘j’ of PDCCH, NDI=0, allowing the UE to transmit one loop back SDU and 1 byte MAC subheader for Configured Grant Confirmation MAC CE. |
<– |
(UL configured grant type 2) |
– |
– |
23 |
Check: Does the UE transmit a MAC PDU containing one RLC SDU and a Configured Grant Confirmation MAC CE in Symbol ‘S’ of Slot ‘y’ of PUSCH as per grant in step 22? i.e., in the PUSCH slot y=floor (n * (PUSCHSCS / PDCCHSCS)) + K2. (Note 3) |
–> |
MAC PDU |
1 |
P |
24 |
SS transmits RRCReconfiguration to disable UL configured grant type 2. |
<– |
NR RRC: RRCReconfiguration |
– |
– |
25 |
The UE transmits RRCReconfigurationComplete. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
26 |
SS transmits a DL MAC PDU containing 1 RLC SDU. |
<– |
MAC PDU |
– |
– |
27 |
Check: Does the UE transmit a MAC PDU in Symbol ‘S’ of Slot ‘y + 10x’ of PUSCH as per grant in step 22. |
–> |
MAC PDU |
5 |
F |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: y is the slot where the UE shall transmit the PUSCH and is determined by as where n is the slot with the scheduling DCI, is based on the numerology of PUSCH. S is the starting symbol relatived to the start of the slot y according to TS 38.214 clause 6.1.2.1. Note 4: x is equal to periodicity / 14 in this test case. Note 5: If the MAC entity does not generate a MAC PDU, one of the conditions which shall be satisfied is that there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.321 clause 5.4.3.1.3. |
7.1.1.6.3.3.3 Specific message contents
Table 7.1.1.6.3.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.6.3.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
radioBearerConfig |
Not present |
||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
Not present |
NR |
||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
|
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.3.3.3-2: CellGroupConfig (Table 7.1.1.6.3.3.3-1: RRCReconfiguration)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
rlc-BearerToAddModList |
Not present |
||
mac-CellGroupConfig |
Not present |
||
physicalCellGroupConfig SEQUENCE { |
|||
cs-RNTI CHOICE { |
|||
setup SEQUENCE{ |
|||
RNTI-Value |
‘FFE0’H |
||
} |
|||
} |
|||
} |
|||
spCellConfig SEQUENCE{ |
|||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
schedulingRequestResourceToAddModList { |
|||
schedulingRequestResourceId |
1 |
||
schedulingRequestID |
0 |
||
periodicityAndOffset CHOICE { |
|||
sl20 |
9 |
||
} |
|||
} |
|||
} |
|||
} |
|||
configuredGrantConfig CHOICE { |
|||
setup SEQUENCE { |
|||
cg-DMRS-Configuration |
DMRS-UplinkConfig |
Reference TS 38.508-1 [4], Table 4.6.3-51 |
|
uci-OnPUSCH CHOICE { |
|||
setup SEQUENCE { |
|||
semiStatic SEQUENCE { |
BetaOffsets |
||
betaOffsetACK-Index1 |
9 |
||
betaOffsetACK-Index2 |
9 |
||
betaOffsetACK-Index3 |
9 |
||
betaOffsetCSI-Part1-Index1 |
6 |
||
betaOffsetCSI-Part1-Index2 |
6 |
||
betaOffsetCSI-Part2-Index1 |
6 |
||
betaOffsetCSI-Part2-Index2 |
6 |
||
} |
|||
} |
|||
} |
|||
resourceAllocation |
ResourceAllocationType1 |
||
powerControlLoopToUse |
n0 |
||
p0-PUSCH-Alpha |
0 |
||
nrofHARQ-Processes |
16 |
||
repK |
n1 |
||
periodicity |
Sym40x14 |
15kHz |
|
periodicity |
Sym80x14 |
30kHz |
|
periodicity |
Sym160x14 |
60kHz |
|
periodicity |
Sym320x14 |
120kHz |
|
} |
|||
} |
|||
pusch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
PUSCH-TimeDomainResourceAllocationList SEQUENCE { |
|||
k2 |
4 |
FR1 |
|
8 |
FR2 |
||
mappingType |
typeB |
||
startSymbolAndLength |
0011011 |
FR1 |
|
startSymbolAndLength |
0001110 |
FR2 |
|
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.3.3.3-3: RRCReconfiguration (step 24 of Table 7.1.1.6.3.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
radioBearerConfig |
Not present |
||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
Not present |
NR |
||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
|
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.3.3.3-4: CellGroupConfig (Table 7.1.1.6.3.3.3-3: RRCReconfiguration)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
cellGroupId |
1 |
||
spCellConfig SEQUENCE{ |
|||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplink SEQUENCE { |
|||
configuredGrantConfig CHOICE { |
|||
release |
Null |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
7.1.1.6.4 Correct handling of DL assignment / Multi Semi-persistent configuration
7.1.1.6.4.1 Test Purpose (TP)
(1)
with { UE in RRC_Connected state with DRB established and sps-Configuration in DL is enabled }
ensure that {
when { UE receives a DL assignment addressed to its stored CS-RNTI in slot y and with NDI set as 0 with sps-ConfigIndex=0}
then {UE starts receiving DL MAC PDU in slots y+n*[semiPersistSchedIntervalDL] where ‘n’ is positive integer starting at zero }
}
(2)
with { UE in RRC_Connected state with DRB established and stored DL SPS assignment to receive MAC PDU in slot y+n*[semiPersistSchedIntervalDL] }
ensure that {
when { UE receives another DL assignment addressed to its CS-RNTI in slot p and with NDI set as 0 associated with sps-ConfigIndex=1, where p!= y+n*[semiPersistSchedIntervalDL] }
then { UE starts receiving DL MAC PDU in slots p+n*[semiPersistSchedIntervalDL] and continue receiving DL MAC PDU at slots y+n*[semiPersistSchedIntervalDL]where ‘n’ is positive integer starting at zero }
}
7.1.1.6.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in TS 38.321, clause 5.3.1, 5.8.1 TS 38.300, clause 10.2, and TS 38.213, clause 10.2. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.3.1]
Downlink assignments received on the PDCCH both indicate that there is a transmission on a DL-SCH for a particular MAC entity and provide the relevant HARQ information.
When the MAC entity has a C-RNTI, Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion during which it monitors PDCCH and for each Serving Cell:
1> if a downlink assignment for this PDCCH occasion and this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI, or Temporary C‑RNTI:
2> if this is the first downlink assignment for this Temporary C-RNTI:
3> consider the NDI to have been toggled.
2> if the downlink assignment is for the MAC entity’s C-RNTI, and if the previous downlink assignment indicated to the HARQ entity of the same HARQ process was either a downlink assignment received for the MAC entity’s CS-RNTI or a configured downlink assignment:
3> consider the NDI to have been toggled regardless of the value of the NDI.
2> indicate the presence of a downlink assignment and deliver the associated HARQ information to the HARQ entity.
1> else if a downlink assignment for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> indicate the presence of a downlink assignment for this Serving Cell and deliver the associated HARQ information to the HARQ entity.
2> if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate SPS deactivation:
4> clear the configured downlink assignment for this Serving Cell (if any);
4> if the timeAlignmentTimer, associated with the TAG containing the Serving Cell on which the HARQ feedback is to be transmitted, is running:
5> indicate a positive acknowledgement for the SPS deactivation to the physical layer.
3> else if PDCCH content indicates SPS activation:
4> store the downlink assignment for this Serving Cell and the associated HARQ information as configured downlink assignment;
4> initialise or re-initialise the configured downlink assignment for this Serving Cell to start in the associated PDSCH duration and to recur according to rules in clause 5.8.1;
For each Serving Cell and each configured downlink assignment, if configured and activated, the MAC entity shall:
1> if the PDSCH duration of the configured downlink assignment does not overlap with the PDSCH duration of a downlink assignment received on the PDCCH for this Serving Cell:
2> instruct the physical layer to receive, in this PDSCH duration, transport block on the DL-SCH according to the configured downlink assignment and to deliver it to the HARQ entity;
2> set the HARQ Process ID to the HARQ Process ID associated with this PDSCH duration;
2> consider the NDI bit for the corresponding HARQ process to have been toggled;
2> indicate the presence of a configured downlink assignment and deliver the stored HARQ information to the HARQ entity.
For configured downlink assignments without harq-ProcID-Offset, the HARQ Process ID associated with the slot where the DL transmission starts is derived from the following equation:
HARQ Process ID = [floor (CURRENT_slot × 10 / (numberOfSlotsPerFrame × periodicity))] modulo nrofHARQ-Processes
where CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + slot number in the frame] and numberOfSlotsPerFrame refers to the number of consecutive slots per frame as specified in TS 38.211 [8].
NOTE 1: In case of unaligned SFN across carriers in a cell group, the SFN of the concerned Serving Cell is used to calculate the HARQ Process ID used for configured downlink assignments.
For configured downlink assignments with harq-ProcID-Offset, the HARQ Process ID associated with the slot where the DL transmission starts is derived from the following equation:
HARQ Process ID = [floor (CURRENT_slot × 10 / (numberOfSlotsPerFrame × periodicity))] modulo nrofHARQ-Processes + harq-ProcID-Offset
where CURRENT_slot = [(SFN × numberOfSlotsPerFrame) + slot number in the frame] and numberOfSlotsPerFrame refers to the number of consecutive slots per frame as specified in TS 38.211 [8].
NOTE 2: CURRENT_slot refers to the slot index of the first transmission occasion of a bundle of configured downlink assignment.
When the MAC entity needs to read BCCH, the MAC entity may, based on the scheduling information from RRC:
1> if a downlink assignment for this PDCCH occasion has been received on the PDCCH for the SI-RNTI;
2> indicate a downlink assignment and redundancy version for the dedicated broadcast HARQ process to the HARQ entity.
[TS 38.321, clause 5.8.1]
Semi-Persistent Scheduling (SPS) is configured by RRC per Serving Cell and per BWP. Multiple assignments can be active simultaneously in the same BWP. Activation and deactivation of the DL SPS are independent among the Serving Cells.
For the DL SPS, a DL assignment is provided by PDCCH, and stored or cleared based on L1 signalling indicating SPS activation or deactivation.
RRC configures the following parameters when the SPS is configured:
– cs-RNTI: CS-RNTI for activation, deactivation, and retransmission;
– nrofHARQ-Processes: the number of configured HARQ processes for SPS;
– harq-ProcID-Offset: Offset of HARQ process for SPS;
– periodicity: periodicity of configured downlink assignment for SPS.
When the SPS is released by upper layers, all the corresponding configurations shall be released.
After a downlink assignment is configured for SPS, the MAC entity shall consider sequentially that the Nth downlink assignment occurs in the slot for which:
(numberOfSlotsPerFrame × SFN + slot number in the frame) =
[(numberOfSlotsPerFrame × SFNstart time + slotstart time) + N × periodicity × numberOfSlotsPerFrame / 10] modulo (1024 × numberOfSlotsPerFrame)
where SFNstart time and slotstart time are the SFN and slot, respectively, of the first transmission of PDSCH where the configured downlink assignment was (re-)initialised.
NOTE: In case of unaligned SFN across carriers in a cell group, the SFN of the concerned Serving Cell is used to calculate the occurrences of configured downlink assignments.
[TS 38.300, clause 10.2]
In the downlink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible assignments when its downlink reception is enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI applies to all serving cells.
The gNB may pre-empt an ongoing PDSCH transmission to one UE with a latency-critical transmission to another UE. The gNB can configure UEs to monitor interrupted transmission indications using INT-RNTI on a PDCCH. If a UE receives the interrupted transmission indication, the UE may assume that no useful information to that UE was carried by the resource elements included in the indication, even if some of those resource elements were already scheduled to this UE.
In addition, with Semi-Persistent Scheduling (SPS), the gNB can allocate downlink resources for the initial HARQ transmissions to UEs: RRC defines the periodicity of the configured downlink assignments while PDCCH addressed to CS-RNTI can either signal and activate the configured downlink assignment, or deactivate it; i.e. a PDCCH addressed to CS-RNTI indicates that the downlink assignment can be implicitly reused according to the periodicity defined by RRC, until deactivated.
NOTE: When required, retransmissions are explicitly scheduled on PDCCH(s).
The dynamically allocated downlink reception overrides the configured downlink assignment in the same serving cell, if they overlap in time. Otherwise a downlink reception according to the configured downlink assignment is assumed, if activated.
The UE may be configured with up to 8 active configured downlink assignments for a given BWP of a serving cell. When more than one is configured:
– The network decides which of these configured downlink assignments are active at a time (including all of them); and
– Each configured downlink assignment is activated separately using a DCI command and deactivation of configured downlink assignments is done using a DCI command, which can either deactivate a single configured downlink assignment or multiple configured downlink assignments jointly.
[TS 38.213, clause 10.2]
A UE validates, for scheduling activation or scheduling release, a DL SPS assignment PDCCH or a configured UL grant Type 2 PDCCH if
– the CRC of a corresponding DCI format is scrambled with a CS-RNTI provided by cs-RNTI, and
– the new data indicator field in the DCI format for the enabled transport block is set to ‘0’, and
– the DFI flag field, if present, in the DCI format is set to ‘0’, and
– if validation is for scheduling activation and if the PDSCH-to-HARQ_feedback timing indicator field in the DCI format is present, the PDSCH-to-HARQ_feedback timing indicator field does not provide an inapplicable value from dl-DataToUL-ACK-r16.
If a UE is provided a single configuration for UL grant Type 2 PUSCH or for SPS PDSCH, validation of the DCI format is achieved if all fields for the DCI format are set according to Table 10.2-1 or Table 10.2-2.
If a UE is provided more than one configurations for UL grant Type 2 PUSCH or for SPS PDSCH, a value of the HARQ process number field in a DCI format indicates an activation for a corresponding UL grant Type 2 PUSCH or for a SPS PDSCH configuration with a same value as provided by ConfiguredGrantConfigIndex or by sps-ConfigIndex, respectively. Validation of the DCI format is achieved if the RV field for the DCI format is set as in Table 10.2-3.
If a UE is provided more than one configuration for UL grant Type 2 PUSCH or for SPS PDSCH
– if the UE is provided ConfiguredGrantConfigType2DeactivationStateList or sps-ConfigDeactivationStateList, a value of the HARQ process number field in a DCI format indicates a corresponding entry for scheduling release of one or more UL grant Type 2 PUSCH or SPS PDSCH configurations
– if the UE is not provided ConfiguredGrantConfigType2DeactivationStateList or sps-ConfigDeactivationStateList, a value of the HARQ process number field in a DCI format indicates a release for a corresponding UL grant Type 2 PUSCH or for a SPS PDSCH configuration with a same value as provided by ConfiguredGrantConfigIndex or by sps-ConfigIndex, respectively.
Validation of the DCI format is achieved if all fields for the DCI format are set according to Table 10.2-4.
If validation is achieved, the UE considers the information in the DCI format as a valid activation or valid release of DL SPS or configured UL grant Type 2. If validation is not achieved, the UE discards all the information in the DCI format.
Table 10.2-1: Special fields for single DL SPS or single UL grant Type 2 scheduling activation PDCCH validation when a UE is provided a single SPS PDSCH or UL grant Type 2 configuration in the active DL/UL BWP of the scheduled cell
DCI format 0_0/0_1/0_2 |
DCI format 1_0/1_2 |
DCI format 1_1 |
|
HARQ process number |
set to all ‘0’s |
set to all ‘0’s |
set to all ‘0’s |
Redundancy version |
set to all ‘0’s |
set to all ‘0’s |
For the enabled transport block: set to all ‘0’s |
Table 10.2-2: Special fields for single DL SPS or single UL grant Type 2 scheduling release PDCCH validation when a UE is provided a single SPS PDSCH or UL grant Type 2 configuration in the active DL/UL BWP of the scheduled cell
DCI format 0_0/0_1/0_2 |
DCI format 1_0/1_1/1_2 |
|
HARQ process number |
set to all ‘0’s |
set to all ‘0’s |
Redundancy version |
set to all ‘0’s |
set to all ‘0’s |
Modulation and coding scheme |
set to all ‘1’s |
set to all ‘1’s |
Frequency domain resource assignment |
set to all ‘0’s for FDRA Type 2 with set to all ‘1’s, otherwise |
set to all ‘0’s for FDRA Type 0 or for dynamicSwitch set to all ‘1’s for FDRA Type 1 |
Table 10.2-3: Special fields for a single DL SPS or single UL grant Type 2 scheduling activation PDCCH validation when a UE is provided multiple DL SPS or UL grant Type 2 configurations in the active DL/UL BWP of the scheduled cell
DCI format 0_0/0_1/0_2 |
DCI format 1_0/1_2 |
DCI format 1_1 |
|
Redundancy version |
set to all ‘0’s |
set to all ‘0’s |
For the enabled transport block: set to all ‘0’s |
Table 10.2-4: Special fields for a single or multiple DL SPS and UL grant Type 2 scheduling release PDCCH validation when a UE is provided multiple DL SPS or UL grant Type 2 configurations in the active DL/UL BWP of the scheduled cell
DCI format 0_0/0_1/0_2 |
DCI format 1_0/1_1/1_2 |
|
Redundancy version |
set to all ‘0’s |
set to all ‘0’s |
Modulation and coding scheme |
set to all ‘1’s |
set to all ‘1’s |
Frequency domain resource assignment |
set to all ‘0’s for FDRA Type 2 with set to all ‘1’s, otherwise |
set to all ‘0’s for FDRA Type 0 or for dynamicSwitch set to all ‘1’s for FDRA Type 1 |
A UE is expected to provide HARQ-ACK information in response to a SPS PDSCH release after symbols from the last symbol of a PDCCH providing the SPS PDSCH release. If processingType2Enabled of PDSCH-ServingCellConfig is set to enable for the serving cell with the PDCCH providing the SPS PDSCH release, for , for , and for , otherwise, for , for , for , and for , wherein corresponds to the smallest SCS configuration between the SCS configuration of the PDCCH providing the SPS PDSCH release and the SCS configuration of a PUCCH carrying the HARQ-ACK information in response to a SPS PDSCH release.
7.1.1.6.4.3 Test description
7.1.1.6.4.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink and that the UM DRB is configured according to Table 7.1.1.6.4.3.1-1.
Table 7.1.1.6.4.3.1-1: RLC parameters
Uplink UM RLC sn-FieldLength |
IF (pc_um_WithShortSN ) size6 ELSE size12 |
Downlink UM RLC sn-FieldLength |
F (pc_um_WithShortSN ) size6 ELSE size12 |
7.1.1.6.4.3.2 Test procedure sequence
Table 7.1.1.6.4.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration to config SPS-ConfigurationDL.(Note 2) |
<– |
RRCReconfiguration |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete.(Note 3) |
–> |
RRCReconfigurationComplete |
– |
– |
3 |
The SS transmits a DL assignment using UE’s CS-RNTI associated with sps-ConfigIndex=0 in Slot ‘Y’, NDI=0 |
<– |
(DL SPS Grant) |
– |
– |
4 |
The SS transmits in Slot ‘Y’, a DL MAC PDU containing a RLC PDU on UM DRB. |
<– |
MAC PDU |
– |
– |
5 |
Check: does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
6 |
The SS transmits in Slot ‘Y+X’, a DL MAC PDU containing a RLC PDU on DRB. (Note 1) |
<– |
MAC PDU |
– |
– |
7 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
1 |
P |
8 |
SS transmits NR RRCReconfiguration to add another SPS-ConfigurationDL.(Note 2) |
<– |
RRCReconfiguration |
– |
– |
9 |
The UE transmits NR RRCReconfigurationComplete.(Note 3) |
–> |
RRCReconfigurationComplete |
– |
– |
10 |
The SS transmits a DL assignment using UE’s CS-RNTI associated with sps-ConfigIndex=1 in Slot ‘P’, NDI=0; (Where Y+X<P<Y+2X) |
<– |
(DL SPS Grant) |
– |
– |
11 |
The SS transmits in Slot ‘P’, a DL MAC PDU containing a RLC PDU on UM DRB. |
<– |
MAC PDU |
– |
– |
12 |
Check: Does the UE transmit a HARQ ACK? |
–> |
HARQ ACK |
2 |
P |
13 |
The SS transmits in Slot ‘Y+2X’, a DL MAC PDU containing a RLC PDU on UM DRB. |
<– |
MAC PDU |
– |
– |
14 |
Check: Does the UE transmit a HARQ Feedback? |
–> |
HARQ ACK |
2 |
P |
15 |
The SS transmits in Slot ‘P+X’, a DL MAC PDU containing a RLC PDU (DL-SQN=1) on UM DRB. |
<– |
MAC PDU |
– |
– |
16 |
Check: Does the UE transmit a HARQ Feedback? |
–> |
HARQ ACK |
2 |
P |
17 |
SS transmits NR RRCReconfiguration to disable SPS-ConfigurationDL.(Note 2) |
<– |
RRCReconfiguration |
– |
– |
18 |
The UE transmits NR RRCReconfigurationComplete.(Note 3) |
–> |
RRCReconfigurationComplete |
– |
– |
Note 1: X is equal to semiPersistSchedIntervalDL in this document. Note 2: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 3: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 4: As per TS 38.508-1[4], the default value for PDSCH slot offset (K0) is 0, hence the DL MAC PDU’s associated with DL SPS grant in Slot X are sent in same slot X. |
7.1.1.6.4.3.3 Specific message contents
Table 7.1.1.6.4.3.3-1: RRCReconfiguration (step 1/8, Table 7.1.1.6.4.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
Not present |
NR |
||
nonCriticalExtension |
Not present |
EN-DC |
|
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.4.3.3-2: CellGroupConfig (in Table 7.1.1.6.4.3.3-1)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
physicalCellGroupConfig |
PhysicalCellGroupConfig |
Table 7.1.1.6.4.3.3-3 |
|
spCellConfig SEQUENCE { |
|||
servCellIndex |
1 |
EN-DC |
|
Not present |
NR |
||
spCellConfigDedicated SEQUENCE { |
|||
initialDownlinkBWP SEQUENCE { |
|||
sps-ConfigToAddModList-r16 ::= SEQUENCE (SIZE (1..maxNrofSPS-Config-r16)) OF SPS-Config { |
|||
SPS-Config ::= SEQUENCE [1] { |
The first SPS configuration entry |
STEP 1 |
|
setup SEQUENCE { |
|||
periodicity |
ms160 |
||
nrofHARQ-Processes |
8 |
||
sps-ConfigIndex-r16 |
0 |
||
harq-ProcID-Offset-r16 |
0 |
||
sps-ConfigIndex-r16 |
0 |
||
} |
|||
SPS-Config ::= SEQUENCE [2] { |
The second SPS configuration entry |
STEP 8 |
|
setup SEQUENCE { |
|||
periodicity |
ms160 |
||
nrofHARQ-Processes |
8 |
||
sps-ConfigIndex-r16 |
1 |
||
harq-ProcID-Offset-r16 |
8 |
||
sps-ConfigIndex-r16 |
1 |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.4.3.3-3: PhysicalCellGroupConfig (Table 7.1.1.6.4.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-106 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PhysicalCellGroupConfig ::= SEQUENCE { |
|||
cs-RNTI |
‘FFE0’H |
||
} |
Table 7.1.1.6.4.3.3-4: RRCReconfiguration (step 17 of Table 7.1.1.6.4.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
secondaryCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
EN-DC |
Not present |
NR |
||
nonCriticalExtension |
Not present |
EN-DC |
|
nonCriticalExtension := SEQUENCE{ |
NR |
||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.4.3.3-5: CellGroupConfig (Table 7.1.1.6.4.3.3-4)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
CellGroupConfig ::= SEQUENCE { |
||||
spCellConfig SEQUENCE { |
||||
servCellIndex |
1 |
|||
Not present |
NR |
|||
spCellConfigDedicated SEQUENCE { |
||||
initialDownlinkBWP SEQUENCE { |
||||
sps-ConfigToReleaseList-r16 SEQUENCE (SIZE (1..maxNrofSPS-Config-r16)) OF SPS-ConfigIndex-r16 { |
2 entries |
Release all the SPS entries configured previously |
||
SPS-ConfigIndex-r16[1] |
0 |
|||
SPS-ConfigIndex-r16[2] |
1 |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
7.1.1.6.5 Correct handling of UL grant / Multi configured uplink grants
7.1.1.6.5.1 Test Purpose (TP)(1)
with { UE in RRC_Connected state with DRB established and sps-Configuration in UL is enabled with Configured grant type 1 }
ensure that {
when { The symbol in which equation [(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
(timeDomainOffset × numberOfSymbolsPerSlot + S + N × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot)is satisfied }
then { UE starts transmitting UL MAC PDU periodically in the symbol associated with the new re-configured grant }
}
(2)
with { UE in RRC_Connected state with DRB established and configured UL grant type 1 }
ensure that {
when { UE receives another UL grant type 1 in an RRC message with timeDomainOffset 15}
then { UE starts transmitting UL MAC PDU in symbol with timeDomainOffset 15 and continue transmitting UL MAC PDU in symbol with timeDomainOffset 5}
}
7.1.1.6.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in TS 38.321, clause 5.4.1, 5.8.2 TS 38.300, clause 10.3. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.4.1]
Uplink grant is either received dynamically on the PDCCH, in a Random Access Response, configured semi-persistently by RRC or determined to be associated with the PUSCH resource of MSGA as specified in clause 5.1.2a. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To perform the requested transmissions, the MAC layer receives HARQ information from lower layers. An uplink grant addressed to CS-RNTI with NDI = 0 is considered as a configured uplink grant. An uplink grant addressed to CS-RNTI with NDI = 1 is considered as a dynamic uplink grant.
If the MAC entity has a C-RNTI, a Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer and for each grant received for this PDCCH occasion:
1> if an uplink grant for this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or
1> if an uplink grant has been received in a Random Access Response:
2> if the uplink grant is for MAC entity’s C-RNTI and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was either an uplink grant received for the MAC entity’s CS-RNTI or a configured uplink grant:
3> consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.
2> if the uplink grant is for MAC entity’s C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured.
3> stop the cg-RetransmissionTimer for the corresponding HARQ process, if running.
2> deliver the uplink grant and the associated HARQ information to the HARQ entity.
1> else if an uplink grant for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured;
3> stop the cg-RetransmissionTimer for the corresponding HARQ process, if running;
3> deliver the uplink grant and the associated HARQ information to the HARQ entity.
2> else if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate configured grant Type 2 deactivation:
4> trigger configured uplink grant confirmation.
3> else if PDCCH contents indicate configured grant Type 2 activation:
4> trigger configured uplink grant confirmation;
4> store the uplink grant for this Serving Cell and the associated HARQ information as configured uplink grant;
4> initialise or re-initialise the configured uplink grant for this Serving Cell to start in the associated PUSCH duration and to recur according to rules in clause 5.8.2;
4> stop the configuredGrantTimer for the corresponding HARQ process, if running;
4> stop the cg-RetransmissionTimer for the corresponding HARQ process, if running.
For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall:
1> if the MAC entity is configured with lch-basedPrioritization, and the PUSCH duration of the configured uplink grant does not overlap with the PUSCH duration of an uplink grant received in a Random Access Response or with the PUSCH duration of an uplink grant addressed to Temporary C-RNTI or the PUSCH duration of a MSGA payload for this Serving Cell; or
1> if the MAC entity is not configured with lch-basedPrioritization, and the PUSCH duration of the configured uplink grant does not overlap with the PUSCH duration of an uplink grant received on the PDCCH or in a Random Access Response or the PUSCH duration of a MSGA payload for this Serving Cell:
2> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
2> if, for the corresponding HARQ process, the configuredGrantTimer is not running and cg-RetransmissionTimer is not configured (i.e. new transmission):
3> consider the NDI bit for the corresponding HARQ process to have been toggled;
3> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
2> else if the cg-RetransmissionTimer for the corresponding HARQ process is configured and not running, then for the corresponding HARQ process:
3> if the configuredGrantTimer is not running, and the HARQ process is not pending (i.e. new transmission):
4> consider the NDI bit to have been toggled;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
3> else if the previous uplink grant delivered to the HARQ entity for the same HARQ process was a configured uplink grant (i.e. retransmission on configured grant):
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For configured uplink grants neither configured with harq-ProcID-Offset2 nor with cg-RetransmissionTimer, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo nrofHARQ-Processes
For configured uplink grants with harq-ProcID-Offset2, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol / periodicity)] modulo nrofHARQ-Processes + harq-ProcID-Offset2
where CURRENT_symbol = (SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slot number in the frame × numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS 38.211 [8].
[TS 38.321, clause 5.8.2]There are two types of transmission without dynamic grant:
– configured grant Type 1 where an uplink grant is provided by RRC, and stored as configured uplink grant;
– configured grant Type 2 where an uplink grant is provided by PDCCH, and stored or cleared as configured uplink grant based on L1 signalling indicating configured uplink grant activation or deactivation.
Type 1 and Type 2 are configured by RRC for a Serving Cell per BWP. Multiple configurations can be active simultaneously in the same BWP. For Type 2, activation and deactivation are independent among the Serving Cells. For the same BWP, the MAC entity can be configured with both Type 1 and Type 2.
RRC configures the following parameters when the configured grant Type 1 is configured:
– cs-RNTI: CS-RNTI for retransmission;
– periodicity: periodicity of the configured grant Type 1;
– timeDomainOffset: Offset of a resource with respect to SFN = timeReferenceSFN in time domain;
– timeDomainAllocation: Allocation of configured uplink grant in time domain which contains startSymbolAndLength (i.e. SLIV in TS 38.214 [7]) or startSymbol (i.e. S in TS 38.214 [7]);
– nrofHARQ-Processes: the number of HARQ processes for configured grant;
– harq-ProcID-Offset: offset of HARQ process for configured grant for operation with shared spectrum channel access;
– harq-ProcID-Offset2: offset of HARQ process for configured grant;
– timeReferenceSFN: SFN used for determination of the offset of a resource in time domain. The UE uses the closest SFN with the indicated number preceding the reception of the configured grant configuration.
RRC configures the following parameters when the configured grant Type 2 is configured:
– cs-RNTI: CS-RNTI for activation, deactivation, and retransmission;
– periodicity: periodicity of the configured grant Type 2;
– nrofHARQ-Processes: the number of HARQ processes for configured grant;
– harq-ProcID-Offset: offset of HARQ process for configured grant for operation with shared spectrum channel access;
– harq-ProcID-Offset2: offset of HARQ process for configured grant.
RRC configures the following parameters when retransmissions on configured uplink grant is configured:
– cg-RetransmissionTimer: the duration after a configured grant (re)transmission of a HARQ process when the UE shall not autonomously retransmit that HARQ process.
Upon configuration of a configured grant Type 1 for a BWP of a Serving Cell by upper layers, the MAC entity shall:
1> store the uplink grant provided by upper layers as a configured uplink grant for the indicated BWP of the Serving Cell;
1> initialise or re-initialise the configured uplink grant to start in the symbol according to timeDomainOffset, timeReferenceSFN, and S (derived from SLIV or provided by startSymbol as specified in TS 38.214 [7]), and to reoccur with periodicity.
After an uplink grant is configured for a configured grant Type 1, the MAC entity shall consider sequentially that the Nth (N >= 0) uplink grant occurs in the symbol for which:
[(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
(timeReferenceSFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + timeDomainOffset × numberOfSymbolsPerSlot + S + N × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot).
After an uplink grant is configured for a configured grant Type 2, the MAC entity shall consider sequentially that the Nth (N >= 0) uplink grant occurs in the symbol for which:
[(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame × numberOfSymbolsPerSlot) + symbol number in the slot] =
[(SFNstart time × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slotstart time × numberOfSymbolsPerSlot + symbolstart time) + N × periodicity] modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot).
where SFNstart time, slotstart time, and symbolstart time are the SFN, slot, and symbol, respectively, of the first transmission opportunity of PUSCH where the configured uplink grant was (re-)initialised.
If cg-nrofPUSCH-InSlot or cg-nrofSlots is configured for a configured grant Type 1 or Type 2, the MAC entity shall consider the uplink grants occur in those additional PUSCH allocations as specified in clause 6.1.2.3 of TS 38.214 [7].
NOTE: In case of unaligned SFN across carriers in a cell group, the SFN of the concerned Serving Cell is used to calculate the occurrences of configured uplink grants.
When the configured uplink grant is released by upper layers, all the corresponding configurations shall be released and all corresponding uplink grants shall be cleared.
The MAC entity shall:
1> if at least one configured uplink grant confirmation has been triggered and not cancelled; and
1> if the MAC entity has UL resources allocated for new transmission:
2> if, in this MAC entity, at least one configured uplink grant is configured by configuredGrantConfigToAddModList:
3> instruct the Multiplexing and Assembly procedure to generate a Multiple Entry Configured Grant Confirmation MAC CE as defined in clause 6.1.3.31.
2> else:
3> instruct the Multiplexing and Assembly procedure to generate a Configured Grant Confirmation MAC CE as defined in clause 6.1.3.7.
2> cancel all triggered configured uplink grant confirmation(s).
For a configured grant Type 2, the MAC entity shall clear the configured uplink grant(s) immediately after first transmission of Configured Grant Confirmation MAC CE or Multiple Entry Configured Grant Confirmation MAC CE which confirms the configured uplink grant deactivation.
Retransmissions use:
– repetition of configured uplink grants; or
– received uplink grants addressed to CS-RNTI; or
– configured uplink grants with cg-RetransmissionTimer configured.
[TS 38.300, clause 10.3]
In the uplink, the gNB can dynamically allocate resources to UEs via the C-RNTI on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible grants for uplink transmission when its downlink reception is enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI applies to all serving cells.
The gNB may cancel a PUSCH transmission, or a repetition of a PUSCH transmission, or an SRS transmission of a UE for another UE with a latency-critical transmission. The gNB can configure UEs to monitor cancelled transmission indications using CI-RNTI on a PDCCH. If a UE receives the cancelled transmission indication, the UE shall cancel the PUSCH transmission from the earliest symbol overlapped with the resource or the SRS transmission overlapped with the resource indicated by cancellation (see clause 11.2A of TS 38.213 [38]).
In addition, with Configured Grants, the gNB can allocate uplink resources for the initial HARQ transmissions and HARQ retransmissions to UEs. Two types of configured uplink grants are defined:
– With Type 1, RRC directly provides the configured uplink grant (including the periodicity).
– With Type 2, RRC defines the periodicity of the configured uplink grant while PDCCH addressed to CS-RNTI can either signal and activate the configured uplink grant, or deactivate it; i.e. a PDCCH addressed to CS-RNTI indicates that the uplink grant can be implicitly reused according to the periodicity defined by RRC, until deactivated.
If the UE is not configured with enhanced intra-UE overlapping resources prioritization, the dynamically allocated uplink transmission overrides the configured uplink grant in the same serving cell, if they overlap in time. Otherwise an uplink transmission according to the configured uplink grant is assumed, if activated.
If the UE is configured with enhanced intra-UE overlapping resources prioritization, in case a configured uplink grant transmission overlaps in time with dynamically allocated uplink transmission or with another configured uplink grant transmission in the same serving cell, the UE prioritizes the transmission based on the comparison between the highest priority of the logical channels that have data to be transmitted and which are multiplexed or can be multiplexed in MAC PDUs associated with the overlapping resources. Similarly, in case a configured uplink grant transmissions or a dynamically allocated uplink transmission overlaps in time with a scheduling request transmission, the UE prioritizes the transmission based on the comparison between the priority of the logical channel which triggered the scheduling request and the highest priority of the logical channels that have data to be transmitted and which are multiplexed or can be multiplexed in MAC PDU associated with the overlapping resource. In case the MAC PDU associated with a deprioritized transmission has already been generated, the UE keeps it stored to allow the gNB to schedule a retransmission. The UE may also be configured by the gNB to transmit the stored MAC PDU as a new transmission using a subsequent resource of the same configured uplink grant configuration when an explicit retransmission grant is not provided by the gNB.
Retransmissions other than repetitions are explicitly allocated via PDCCH(s) or via configuration of a retransmission timer.
The UE may be configured with up to 12 active configured uplink grants for a given BWP of a serving cell. When more than one is configured, the network decides which of these configured uplink grants are active at a time (including all of them). Each configured uplink grant can either be of Type 1 or Type 2. For Type 2, activation and deactivation of configured uplink grants are independent among the serving cells. When more than one Type 2 configured grant is configured, each configured grant is activated separately using a DCI command and deactivation of Type 2 configured grants is done using a DCI command, which can either deactivate a single configured grant configuration or multiple configured grant configurations jointly.
When SUL is configured, the network should ensure that an active configured uplink grant on SUL does not overlap in time with another active configured uplink grant on the other UL configuration.
For both dynamic grant and configured grant, for a transport block, two or more repetitions can be in one slot, or across slot boundary in consecutive available slots with each repetition in one slot. For both dynamic grant and configured grant Type 2, the number of repetitions can be also dynamically indicated in the L1 signalling. The dynamically indicated number of repetitions shall override the RRC configured number of repetitions, if both are present.
7.1.1.6.5.3 Test description
7.1.1.6.5.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 and UM DRB should be established on NR Cell 1.
7.1.1.6.5.3.2 Test procedure sequence
Table 7.1.1.6.5.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits NR RRCReconfiguration messageto configure UL configured grant type 1 in SFN 900, timeDomainOffset is set to 5. |
<– |
(NR RRC: RRCReconfiguration) |
– |
– |
2 |
The UE transmits NR RRCReconfigurationComplete message. |
–> |
(NR RRC: RRCReconfigurationComplete) |
– |
– |
3 |
SS transmits a DL MAC PDU containing 4 RLC SDUs of size 96 bytes in SFN 1022 on UM DRB. (Note 1) |
<– |
MAC PDU (nine RLC SDUs) |
– |
– |
4 |
Check: Does the UE transmit a MAC PDU containing first RLC SDU in Symbol ‘x0’, Slot y0’, SFN ‘z0’ after the SFN in step 3 wraps around? Where [(z0 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y0 × numberOfSymbolsPerSlot) + x0] = (5 × numberOfSymbolsPerSlot + S + 0 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). (Note 2) |
–> |
MAC PDU (one RLC SDU) |
1 |
P |
5 |
Check: Does the UE transmit a MAC PDU containing second RLC SDU in Symbol ‘x1’, Slot y1’, SFN ‘z1’? Where [(z1 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y1 × numberOfSymbolsPerSlot) + x1] = (5 × numberOfSymbolsPerSlot + S + 1 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
1 |
P |
6 |
SS transmits NR RRCReconfiguration message to add another configure UL configured grant type 1 in SFN ‘z1 + 1’, timeDomainOffset is set to 15. |
<– |
(NR RRC: RRCReconfiguration) |
– |
– |
7 |
The UE transmits NR RRCReconfigurationComplete message |
–> |
(NR RRC: RRCReconfigurationComplete) |
– |
– |
8 |
Check: Does the UE transmit a MAC PDU containing third RLC SDU in Symbol ‘x0’, Slot y0’, SFN ‘z2’ after the SFN in step 6 wraps around? Where [(z2 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y0 × numberOfSymbolsPerSlot) + x0] = (5 × numberOfSymbolsPerSlot + S + 0 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
2 |
P |
9 |
Check: Does the UE transmit a MAC PDU containing fourth RLC SDU in Symbol ‘x2’, Slot y2’, SFN ‘z2? Where [(z2 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y2 × numberOfSymbolsPerSlot) + x2] = (15 × numberOfSymbolsPerSlot + S + 0 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
2 |
P |
10 |
Check: Does the UE transmit a MAC PDU containing fifth RLC SDU in Symbol ‘x1’, Slot y1’, SFN ‘z3’ after the SFN in step 8 wraps around? Where [(z3 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y3 × numberOfSymbolsPerSlot) + x3] = (5 × numberOfSymbolsPerSlot + S + 1 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
2 |
P |
11 |
Check: Does the UE transmit a MAC PDU containing sixth RLC SDU in Symbol ‘x3’, Slot y3’, SFN ‘z3’? Where [(z3 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (y3 × numberOfSymbolsPerSlot) + x3] = (15 × numberOfSymbolsPerSlot + S + 1 × periodicity) modulo (1024 × numberOfSlotsPerFrame × numberOfSymbolsPerSlot). |
–> |
MAC PDU (one RLC SDU) |
2 |
P |
Note 1: According to the setting parameters in Table 7.1.1.6.2.3.3-2, TB size for configured grant type 1 is 808 bits, which is enough to allow the UE to transmit one PDU at a time (96 bytes RLC SDU + 1 byte UM RLC Header + 2 bytes MAC Sub PDU header + 2 bytes for short BSR or padding). Note 2: S is the starting symbol relative to the slot of the first PUSCH transmission for new configured grant type 1. The value of S can be obtained from TS 38.508-1 [4], Table 4.6.3-122. Note 3: q is the slot where the UE shall transmit the PUSCH and is determined by as where is the slot with the scheduling DCI, is based on the numerology of PUSCH. S is the starting symbol relative to the start of the slot q according to TS 38.214 clause 6.1.2.1. Note 4: The UL grant addressed to C-RNTI should result in UL transmission overlap in time domain as configured grant type 1. |
7.1.1.6.5.3.3 Specific message contents
Table 7.1.1.6.5.3.3-1: RRCReconfiguration (step 1 and step 6, Table 7.1.1.6.5.3.2-1)
Derivation path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration SEQUENCE { |
|||
radioBearerConfig |
Not present |
||
secondaryCellGroup |
Not Present |
||
nonCriticalExtension := SEQUENCE{ |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
|
dedicatedNAS-MessageList SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message {} |
Not present |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.6.5.3.3-2: CellGroupConfig (Table 7.1.1.6.5.3.3-1: RRCReconfiguration)
Derivation path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
rlc-BearerToAddModList |
Not present |
||
mac-CellGroupConfig |
Not present |
||
physicalCellGroupConfig SEQUENCE { |
|||
cs-RNTI CHOICE { |
|||
setup SEQUENCE{ |
|||
RNTI-Value |
‘FFE0’H |
||
} |
|||
} |
|||
} |
|||
spCellConfig SEQUENCE{ |
|||
servCellIndex |
Not present |
||
reconfigurationWithSync |
Not present |
||
spCellConfigDedicated SEQUENCE{ |
|||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
schedulingRequestResourceToAddModList { |
|||
schedulingRequestResourceId |
1 |
||
schedulingRequestID |
0 |
||
periodicityAndOffset CHOICE { |
|||
sl20 |
10 |
||
} |
|||
} |
|||
} |
|||
} |
|||
configuredGrantConfigToAddModList-r16 SEQUENCE (SIZE (1..maxNrofConfiguredGrantConfig-r16)) OF ConfiguredGrantConfig { |
2 entries |
||
configuredGrantConfig[1] SEQUENCE { |
The first UL Grant configuration entry |
Step1 |
|
cg-DMRS-Configuration |
DMRS-UplinkConfig |
Reference TS 38.508-1[4], Table 4.6.3-51 |
|
uci-OnPUSCH CHOICE { |
|||
setup SEQUENCE { |
|||
semiStatic SEQUENCE { |
BetaOffsets |
||
betaOffsetACK-Index1 |
9 |
||
betaOffsetACK-Index2 |
9 |
||
betaOffsetACK-Index3 |
9 |
||
betaOffsetCSI-Part1-Index1 |
6 |
||
betaOffsetCSI-Part1-Index2 |
6 |
||
betaOffsetCSI-Part2-Index1 |
6 |
||
betaOffsetCSI-Part2-Index2 |
6 |
||
} |
|||
} |
|||
} |
|||
resourceAllocation |
ResourceAllocationType1 |
||
powerControlLoopToUse |
n0 |
||
p0-PUSCH-Alpha |
1 |
||
nrofHARQ-Processes |
16 |
||
repK |
n1 |
||
periodicity |
Sym40x14 |
15kHz |
|
periodicity |
Sym80x14 |
30kHz |
|
periodicity |
Sym160x14 |
60kHz |
|
periodicity |
Sym320x14 |
120kHz |
|
rrc-ConfiguredUplinkGrant SEQUENCE{ |
|||
timeDomainOffset |
5 |
||
timeDomainAllocation |
0 |
Reference TS 38.508-1 [4], Table 4.6.3-122 |
|
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB = 2 PRB, RBstart = 0, NBWPsize is the size [PRBs] of the active carrier bandwidth part and contained in TS.38.508-1 [4] clause 4.3.1.1. |
FR1_FDD, FR1_TDD |
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB=9 PRB, RBstart = 0and NBWPsize is the size [PRBs] of the active carrier bandwidth part and contained in TS.38.508-1 [4] clause 4.3.1.2. |
FR2_TDD |
antennaPort |
0 |
||
precodingAndNumberOfLayers |
0 |
||
srs-ResourceIndicator |
Not present |
||
mcsAndTBS |
18 |
FR1_FDD, FR1_TDD |
|
25 |
FR2_TDD |
||
pathlossReferenceIndex |
0 |
||
} |
|||
} |
|||
configuredGrantConfig[2] SEQUENCE { |
The second UL Grant configuration entry |
Step6 |
|
cg-DMRS-Configuration |
DMRS-UplinkConfig |
Reference TS 38.508-1[4], Table 4.6.3-51 |
|
uci-OnPUSCH CHOICE { |
|||
setup SEQUENCE { |
|||
semiStatic SEQUENCE { |
BetaOffsets |
||
betaOffsetACK-Index1 |
9 |
||
betaOffsetACK-Index2 |
9 |
||
betaOffsetACK-Index3 |
9 |
||
betaOffsetCSI-Part1-Index1 |
6 |
||
betaOffsetCSI-Part1-Index2 |
6 |
||
betaOffsetCSI-Part2-Index1 |
6 |
||
betaOffsetCSI-Part2-Index2 |
6 |
||
} |
|||
} |
|||
} |
|||
resourceAllocation |
ResourceAllocationType1 |
||
powerControlLoopToUse |
n0 |
||
p0-PUSCH-Alpha |
1 |
||
nrofHARQ-Processes |
16 |
||
repK |
n1 |
||
periodicity |
Sym40x14 |
15kHz |
|
periodicity |
Sym80x14 |
30kHz |
|
periodicity |
Sym160x14 |
60kHz |
|
periodicity |
Sym320x14 |
120kHz |
|
rrc-ConfiguredUplinkGrant SEQUENCE{ |
|||
timeDomainOffset |
15 |
||
timeDomainAllocation |
0 |
Reference TS 38.508-1 [4], Table 4.6.3-122 |
|
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB = 2 PRB, RBstart = 0, NBWPsize is the size [PRBs] of the active carrier bandwidth part and contained in TS.38.508-1 [4] clause 4.3.1.1. |
FR1_FDD, FR1_TDD |
frequencyDomainAllocation |
BIT STRING (SIZE(18) |
BIT STRING (SIZE(18), Equal to NBWPsize * (LRB-1) + RBstart), where LRB=9 PRB, RBstart = 0and NBWPsize is the size [PRBs] of the active carrier bandwidth part and contained in TS.38.508-1 [4] clause 4.3.1.2. |
FR2_TDD |
antennaPort |
0 |
||
precodingAndNumberOfLayers |
0 |
||
srs-ResourceIndicator |
Not present |
||
mcsAndTBS |
18 |
FR1_FDD, FR1_TDD |
|
25 |
FR2_TDD |
||
pathlossReferenceIndex |
0 |
||
} |
|||
} |
|||
} |
|||
pusch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
PUSCH-TimeDomainResourceAllocationList SEQUENCE { |
|||
k2 |
n8 |
FR1 and FR2 |
|
mappingType |
typeB |
||
startSymbolAndLength |
0011011 |
Start symbol(S)=0, Length(L)=14 |
FR1 |
startSymbolAndLength |
0001110 |
S=0, L=2 |
FR2 |
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
7.1.1.7 Activation/Deactivation of SCells
7.1.1.7.1 Activation/Deactivation of SCells / Activation/Deactivation MAC control element reception / sCellDeactivationTimer
7.1.1.7.1.1 Activation/Deactivation of SCells / Activation/Deactivation MAC control element reception / sCellDeactivationTimer / Intra-band Contiguous CA
7.1.1.7.1.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state with SCell configured }
ensure that {
when { UE receives an SCell Activation/Deactivation MAC CE activating the Scell }
then { UE starts monitoring PDCCH on activated SCell }
}
(2)
with(UE in RRC_CONNECTED state with SCell activated )
ensure that {
when{ UE receives a DL assignment on SCell PDCCH }
then { UE restarts the sCellDeactivationTimer }
}
(3)
with ( UE in RRC_CONNECTED state with SCell activated )
ensure that {
when{ UE sCellDeactivationTimer expires }
then { UE deactivates the SCell and stops monitoring PDCCH on SCell }
}
(4)
with (UE in RRC_CONNECTED state with SCell activated )
ensure that {
when{ UE receives a SCell Activation/Deactivation MAC CE deactivating the SCell }
then { UE deactivates the SCell and stops monitoring PDCCH on SCell }
}
(5)
with( UE in RRC_CONNECTED state with SCell activated and UL CA is supported)
ensure that {
when{ UE receives a UL assignment on SCell and has data available for transmission }
then { UE transmits the UL MAC PDU }
}
7.1.1.7.1.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.9 and TS 38.331 clause 5.3.5.5.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.9]
If the MAC entity is configured with one or more SCells, the network may activate and deactivate the configured SCells. Upon configuration of an SCell, the SCell is deactivated.
The configured SCell(s) is activated and deactivated by:
– receiving the SCell Activation/Deactivation MAC CE described in subclause 6.1.3.10;
– configuring sCellDeactivationTimer timer per configured SCell (except the SCell configured with PUCCH, if any): the associated SCell is deactivated upon its expiry.
The MAC entity shall for each configured SCell:
1> if an SCell Activation/Deactivation MAC CE is received activating the SCell:
2> activate the SCell according to the timing defined in TS 38.213 [6]; i.e. apply normal SCell operation including:
3> SRS transmissions on the SCell;
3> CSI reporting for the SCell;
3> PDCCH monitoring on the SCell;
3> PDCCH monitoring for the SCell;
3> PUCCH transmissions on the SCell, if configured.
2> start or restart the sCellDeactivationTimer associated with the SCell in the slot when the SCell Activation/Deactivation MAC CE was received;
2> (re-)initialize any suspended configured uplink grants of configured grant Type 1 associated with this SCell according to the stored configuration, if any, and to start in the symbol according to rules in subclause 5.8.2;
2> trigger PHR according to subclause 5.4.6.
1> else if an SCell Activation/Deactivation MAC CE is received deactivating the SCell; or
1> if the sCellDeactivationTimer associated with the activated SCell expires:
2> deactivate the SCell according to the timing defined in TS 38.213 [6];
2> stop the sCellDeactivationTimer associated with the SCell;
2> stop the bwp-InactivityTimer associated with the SCell;
2> clear any configured downlink assignment and any configured uplink grant Type 2 associated with the SCell respectively;
2> suspend any configured uplink grant Type 1 associated with the SCell;
2> flush all HARQ buffers associated with the SCell.
1> if PDCCH on the activated SCell indicates an uplink grant or downlink assignment; or
1> if PDCCH on the Serving Cell scheduling the activated SCell indicates an uplink grant or a downlink assignment for the activated SCell; or
1> if a MAC PDU is transmitted in a configured uplink grant or received in a configured downlink assignment:
2> restart the sCellDeactivationTimer associated with the SCell.
1> if the SCell is deactivated:
2> not transmit SRS on the SCell;
2> not report CSI for the SCell;
2> not transmit on UL-SCH on the SCell;
2> not transmit on RACH on the SCell;
2> not monitor the PDCCH on the SCell;
2> not monitor the PDCCH for the SCell;
2> not transmit PUCCH on the SCell.
HARQ feedback for the MAC PDU containing SCell Activation/Deactivation MAC CE shall not be impacted by PCell, PSCell and PUCCH SCell interruptions due to SCell activation/deactivation in TS 38.133 [11].
When SCell is deactivated, the ongoing Random Access procedure on the SCell, if any, is aborted.
[TS 38.321, clause 6.1.3.10]
The SCell Activation/Deactivation MAC CE of one octet is identified by a MAC PDU subheader with LCID as specified in Table 6.2.1-1. It has a fixed size and consists of a single octet containing seven C-fields and one R-field. The SCell Activation/Deactivation MAC CE with one octet is defined as follows (Figure 6.1.3.10-1).
The SCell Activation/Deactivation MAC CE of four octets is identified by a MAC PDU subheader with LCID as specified in Table 6.2.1-1. It has a fixed size and consists of four octets containing 31 C-fields and one R-field. The SCell Activation/Deactivation MAC CE of four octets is defined as follows (Figure 6.1.3.10-2).
For the case with no Serving Cell with a ServCellIndex as specified in TS 38.331 [8] larger than 7, SCell Activation/Deactivation MAC CE of one octet is applied, otherwise SCell Activation/Deactivation MAC CE of four octets is applied.
– Ci: If there is an SCell configured for the MAC entity with SCellIndex i as specified in TS 38.331 [8], this field indicates the activation/deactivation status of the SCell with SCellIndex i, else the MAC entity shall ignore the Ci field. The Ci field is set to "1" to indicate that the SCell with SCellIndex i shall be activated. The Ci field is set to "0" to indicate that the SCell with SCellIndex i shall be deactivated;
– R: Reserved bit, set to "0".
Figure 6.1.3.10-1: SCell Activation/Deactivation MAC CE of one octet
Figure 6.1.3.10-2: SCell Activation/Deactivation MAC CE of four octets
7.1.1.7.1.1.3 Test description
7.1.1.7.1.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that DRB is configured in RLC AM mode according to Table 7.1.1. 7.1.1.3.1-1 and in additionNR Cell 3 is configured as NR Active SCell.
Table 7.1.1. 7.1.1.3.1-1: RLC parameters
t-PollRetransmit |
ms80 |
7.1.1.7.1.1.3.2 Test procedure sequence
Table 7.1.1.7.1.1.3.2-1: Time instances of cell power level and parameter changes
Parameter |
Unit |
NR Cell 1 |
NR Cell 3 |
|
T0 |
SS/PBCH SSS EPRE |
dBm/SCS |
-85 |
-85 |
Table 7.1.1.7.1.1.3.2-2: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits an RRCReconfiguration message to configure NR SCell(NR Cell 3). Note 1 |
<– |
(RRCReconfiguration) |
– |
– |
2 |
The UE transmits RRCReconfigurationComplete message. Note 2 |
–> |
(RRCReconfigurationComplete) |
– |
– |
3 |
The SS transmits Activation MAC control element to activate NR SCell on NR SpCell. |
<– |
MAC PDU (SCell Activation/Deactivation MAC CE of one octet (C1=1)) |
– |
– |
4 |
200 ms after step 3, the SS indicates a new transmission on PDCCH of SCell and transmits a MAC PDU (containing an RLC PDU) |
<– |
MAC PDU |
– |
– |
5 |
Check: Does the UE transmit a Scheduling Request on PUCCH? |
–> |
(SR) |
1 |
P |
6 |
The SS sends an UL grant suitable for transmitting loop back PDU on NR SpCell. |
<– |
(UL Grant) |
– |
– |
7 |
The UE transmits a MAC PDU containing the loop back PDU corresponding to step 4. |
–> |
MAC PDU |
– |
– |
8 |
The SS transmits a MAC PDU containing RLC status PDU acknowledging reception of RLC PDU in step 7 on NR SpCell |
<– |
MAC PDU |
– |
– |
9 |
400 ms(sCellDeactivationTimer = 320 ms) after step 4, the SS indicates a new transmission on PDCCH of NR SCell and transmits a MAC PDU (containing an RLC PDU) |
<– |
MAC PDU |
– |
– |
10 |
Check: Does the UE transmit a Scheduling Request on PUCCH in next 1 second? |
–> |
(SR) |
2 |
F |
11 |
The SS transmits Activation MAC control element to activate SCell on NR SpCell. |
<– |
MAC PDU ((SCell Activation/Deactivation MAC CE of one octet (C1=1)) |
– |
– |
12 |
200 ms after step 11 The SS indicates a new transmission on PDCCH of NR SCell and transmits a MAC PDU (containing just padding or RLC status PDU, but no RLC data PDU) |
<– |
MAC PDU |
– |
– |
13 |
400 ms after step 11 the SS indicates a new transmission on PDCCH of NR SCell and transmits a MAC PDU (containing an RLC PDU) |
<– |
MAC PDU |
– |
– |
14 |
Check: Does the UE transmit a Scheduling Request on PUCCH? |
–> |
(SR) |
1,3 |
P |
15 |
The SS sends an UL grant suitable for transmitting loop back PDU IF pc_UL_NR_CA_2CC on NR SCell ELSE on NR SpCell. |
<– |
(UL Grant) |
– |
– |
16 |
The UE transmits a MAC PDU containing the loop back PDU corresponding to step 14 |
–> |
MAC PDU |
5 |
P |
17 |
The SS transmits a MAC PDU containing RLC status PDU acknowledging reception of RLC PDU in step 16 |
<– |
MAC PDU |
– |
– |
18 |
The SS transmits Deactivation MAC control element to de-activate SCell on NR SpCell. |
<– |
MAC PDU (SCell Activation/Deactivation MAC CE of one octet (C1=0)) |
– |
– |
19 |
The SS indicates a new transmission on PDCCH of NR SCell and transmits a MAC PDU (containing an RLC PDU) |
<– |
MAC PDU |
– |
– |
20 |
Check: Does the UE transmit a Scheduling Request on PUCCH in the next 1 second? |
–> |
(SR) |
4 |
F |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.7.1.1.3.3 Specific message contents
Table 7.1.1.7.1.1.3.3-1: RRCReconfiguration (step 1, Table 7.1.1.7.1.1.3.2-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
c1 CHOICE { |
||||
rrcReconfiguration SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
||
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
OCTET STRING (CONTAINING CellGroupConfig) |
||
} |
||||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.7.1.1.3.3-2: CellGroupConfig (Table 7.1.1.7.1.1.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
CellGroupConfig ::= SEQUENCE { |
||||
sCellToAddModList SEQUENCE (SIZE (1..maxMeasId)) OF SCellConfig { |
1 entry |
|||
SCellConfig[1] SEQUENCE { |
entry 1 |
|||
sCellIndex |
SCellIndex as per TS 38.508-1 [4] table 4.6.3-154 |
|||
sCellConfigCommon |
ServingCellConfigCommon |
|||
sCellConfigDedicated |
ServingCellConfig |
|||
} |
||||
} |
||||
} |
Table 7.1.1.7.1.1.3.3-3: ServingCellConfigCommon (Table 7.1.1.7.1.1.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
physCellId |
Physical Cell Identity of NR Cell 3 |
||
uplinkConfigCommon |
Not present |
Not pc_UL_NR_CA_2CC |
|
} |
Table 7.1.1.7.1.1.3.3-4: ServingCellConfig (Table 7.1.1.7.1.1.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
uplinkConfig |
Not present |
Not pc_UL_NR_CA_2CC |
|
uplinkConfig SEQUENCE { |
pc_UL_NR_CA_2CC |
||
initialUplinkBWP |
BWP-UplinkDedicated |
||
} |
|||
sCellDeactivationTimer |
ms320 |
||
} |
Table 7.1.1.7.1.1.3.3-5: BWP-UplinkDedicated (Table 7.1.1.7.1.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-15 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkDedicated ::= SEQUENCE { |
|||
pucch-Config |
Not present |
||
} |
7.1.1.7.1.2 Activation/Deactivation of SCells / Activation/Deactivation MAC control element reception / sCellDeactivationTimer / Inter-Band CA
The scope and description of the present TC is the same as test case 7.1.1.7.1.1 with the following differences:
– CA configuration: Inter-band CA replaces Intra-band Contiguous CA
– Cells configuration: NR Cell 10 replaces NR Cell 3
7.1.1.7.1.3 Activation/Deactivation of SCells / Activation/Deactivation MAC control element reception / sCellDeactivationTimer / Intra-band non-Contiguous CA
The scope and description of the present TC is the same as test case 7.1.1.7.1.1 with the following differences:
– CA configuration: Intra-band non-Contiguous CA replaces Intra-band Contiguous CA
7.1.1.8 Bandwidth Part (BWP) operation
7.1.1.8.1 Bandwidth Part (BWP) operation UL/DL
7.1.1.8.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives BandwidthPart-Config IE included in RRC Message received on SpCell (i.e. PSCell in case of EN-DC or PCell in case of SA) }
then { UE starts normal MAC operation in the FirstActive UL and DL Bandwidth part }
}
(2)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE receives a DL DCI format 1_1 assigning a BWP different than the previously configured BWP }
then { UE starts normal MAC operation in the received new BWP }
}
(3)
with { UE in RRC_CONNECTED }
ensure that {
when { UE receives a UL DCI format 0_1 assigning a BWP different than the previously configured BWP }
then { UE starts normal MAC operation in the received new BWP }
}
(4)
with { UE in RRC_CONNECTED state }
ensure that {
when { UE determines that a RACH Procedure is triggered in SpCell (i.e. PSCell in case of EN-DC or PCell in case of SA) and PRACH occasions are not configured }
then { UE initiates the PRACH procedure in the initial BWP }
}
(5)
with { UE in RRC_Connected State with defaultDownlinkBWP configured }
ensure that {
when { UE bwp-InactivityTimer expires }
then { UE performs BWP switching to a BWP indicated by the defaultDownlinkBWP }
}
(6)
with { UE in RRC_Connected State with defaultDownlinkBWP configured and Active BWP is different than defaultDownlinkBWP and bwp-InactivityTimer is running }
ensure that {
when { UE receives UL assignment or DL grant addressed to its C-RNTI }
then { UE restarts the bwp-InactivityTimer }
}
7.1.1.8.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.211 clause 4.4.5, TS 38.212 clause 7.3.1.1.2 and 7.3.1.2.2, TS 38.321 clause 5.15 and TS 38.331 clause 5.3.5.3. Unless otherwise stated these are Rel-15 requirements.
[TS 38.211, clause 4.4.5]
A bandwidth part is a subset of contiguous common resource blocks defined in subclause 4.4.4.3 for a given numerology in bandwidth part on a given carrier. The starting position and the number of resource blocks in a bandwidth part shall fulfil and , respectively. Configuration of a bandwidth part is described in clause 12 of [5, TS 38.213].
A UE can be configured with up to four bandwidth parts in the downlink with a single downlink bandwidth part being active at a given time. The UE is not expected to receive PDSCH, PDCCH, or CSI-RS (except for RRM) outside an active bandwidth part.
A UE can be configured with up to four bandwidth parts in the uplink with a single uplink bandwidth part being active at a given time. If a UE is configured with a supplementary uplink, the UE can in addition be configured with up to four bandwidth parts in the supplementary uplink with a single supplementary uplink bandwidth part being active at a given time. The UE shall not transmit PUSCH or PUCCH outside an active bandwidth part. For an active cell, the UE shall not transmit SRS outside an active bandwidth part.
Unless otherwise noted, the description in this specification applies to each of the bandwidth parts. When there is no risk of confusion, the index may be dropped from , , , and .
[TS 38.212, clause 7.3.1.1.2]
DCI format 0_1 is used for the scheduling of PUSCH in one cell.
The following information is transmitted by means of the DCI format 0_1 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI:
– Identifier for DCI formats – 1 bit
– The value of this bit field is always set to 0, indicating an UL DCI format
– Carrier indicator – 0 or 3 bits, as defined in Subclause 10.1 of [5, TS 38.213].
– UL/SUL indicator – 0 bit for UEs not configured with SUL in the cell or UEs configured with SUL in the cell but only PUCCH carrier in the cell is configured for PUSCH transmission; 1 bit for UEs configured with SUL in the cell as defined in Table 7.3.1.1.1-1.
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of UL BWPs configured by higher layers, excluding the initial UL bandwidth part. The bitwidth for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the ascending order of the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
[TS 38.212, clause 7.3.1.2.2]
DCI format 1_1 is used for the scheduling of PDSCH in one cell.
The following information is transmitted by means of the DCI format 1_1 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI:
– Identifier for DCI formats – 1 bits
– The value of this bit field is always set to 1, indicating a DL DCI format
– Carrier indicator – 0 or 3 bits as defined in Subclause 10.1 of [5, TS 38.213].
– Bandwidth part indicator – 0, 1 or 2 bits as determined by the number of DL BWPs configured by higher layers, excluding the initial DL bandwidth part. The bitwidth for this field is determined as bits, where
– if , in which case the bandwidth part indicator is equivalent to the higher layer parameter BWP-Id;
– otherwise , in which case the bandwidth part indicator is defined in Table 7.3.1.1.2-1;
If a UE does not support active BWP change via DCI, the UE ignores this bit field.
[TS 38.321, clause 5.15]
In addition to clause 12 of TS 38.213 [6], this subclause specifies requirements on BWP operation.
A Serving Cell may be configured with one or multiple BWPs, and the maximum number of BWP per Serving Cell is specified in TS 38.213 [6].
The BWP switching for a Serving Cell is used to activate an inactive BWP and deactivate an active BWP at a time. The BWP switching is controlled by the PDCCH indicating a downlink assignment or an uplink grant, by the bwp-InactivityTimer, by RRC signalling, or by the MAC entity itself upon initiation of Random Access procedure. Upon RRC (re-)configuration of firstActiveDownlinkBWP-Id and/or firstActiveUplinkBWP-Id for SpCell or activation of an SCell, the DL BWP and/or UL BWP indicated by firstActiveDownlinkBWP-Id and/or firstActiveUplinkBWP-Id respectively (as specified in TS 38.331 [5]) is active without receiving PDCCH indicating a downlink assignment or an uplink grant. The active BWP for a Serving Cell is indicated by either RRC or PDCCH (as specified in TS 38.213 [6]). For unpaired spectrum, a DL BWP is paired with a UL BWP, and BWP switching is common for both UL and DL.
For each activated Serving Cell configured with a BWP, the MAC entity shall:
1> if a BWP is activated:
2> transmit on UL-SCH on the BWP;
2> transmit on RACH on the BWP, if PRACH occasions are configured;
2> monitor the PDCCH on the BWP;
2> transmit PUCCH on the BWP, if configured;
2> report CSI for the BWP;
2> transmit SRS on the BWP, if configured;
2> receive DL-SCH on the BWP;
2> (re-)initialize any suspended configured uplink grants of configured grant Type 1 on the active BWP according to the stored configuration, if any, and to start in the symbol according to rules in subclause 5.8.2.
1> if a BWP is deactivated:
2> not transmit on UL-SCH on the BWP;
2> not transmit on RACH on the BWP;
2> not monitor the PDCCH on the BWP;
2> not transmit PUCCH on the BWP;
2> not report CSI for the BWP;
2> not transmit SRS on the BWP;
2> not receive DL-SCH on the BWP;
2> clear any configured downlink assignment and configured uplink grant of configured grant Type 2 on the BWP;
2> suspend any configured uplink grant of configured grant Type 1 on the inactive BWP.
Upon initiation of the Random Access procedure on a Serving Cell, after the selection of carrier for performing Random Access procedure as specified in subclause 5.1.1, the MAC entity shall for the selected carrier of this Serving Cell:
1> if PRACH occasions are not configured for the active UL BWP:
2> switch the active UL BWP to BWP indicated by initialUplinkBWP;
2> if the Serving Cell is a SpCell:
3> switch the active DL BWP to BWP indicated by initialDownlinkBWP.
1> else:
2> if the Serving Cell is a SpCell:
3> if the active DL BWP does not have the same bwp-Id as the active UL BWP:
4> switch the active DL BWP to the DL BWP with the same bwp-Id as the active UL BWP.
1> stop the bwp-InactivityTimer associated with the active DL BWP of this Serving Cell, if running.
1> if the Serving Cell is SCell:
2> stop the bwp-InactivityTimer associated with the active DL BWP of SpCell, if running.
1> perform the Random Access procedure on the active DL BWP of SpCell and active UL BWP of this Serving Cell.
If the MAC entity receives a PDCCH for BWP switching of a Serving Cell, the MAC entity shall:
1> if there is no ongoing Random Access procedure associated with this Serving Cell; or
1> if the ongoing Random Access procedure associated with this Serving Cell is successfully completed upon reception of this PDCCH addressed to C-RNTI (as specified in subclauses 5.1.4 and 5.1.5):
2> perform BWP switching to a BWP indicated by the PDCCH.
If the MAC entity receives a PDCCH for BWP switching for a Serving Cell while a Random Access procedure associated with that Serving Cell is ongoing in the MAC entity, it is up to UE implementation whether to switch BWP or ignore the PDCCH for BWP switching, except for the PDCCH reception for BWP switching addressed to the C-RNTI for successful Random Access procedure completion (as specified in subclauses 5.1.4 and 5.1.5) in which case the UE shall perform BWP switching to a BWP indicated by the PDCCH. Upon reception of the PDCCH for BWP switching other than successful contention resolution, if the MAC entity decides to perform BWP switching, the MAC entity shall stop the ongoing Random Access procedure and initiate a Random Access procedure after performing the BWP switching; if the MAC decides to ignore the PDCCH for BWP switching, the MAC entity shall continue with the ongoing Random Access procedure on the Serving Cell.
Upon reception of RRC (re-)configuration for BWP switching for a Serving Cell while a Random Access procedure associated with that Serving Cell is ongoing in the MAC entity, the MAC entity shall stop the ongoing Random Access procedure and initiate a Random Access procedure after performing the BWP switching.
The MAC entity shall for each activated Serving Cell configured with bwp-InactivityTimer:
1> if the defaultDownlinkBWP-Id is configured, and the active DL BWP is not the BWP indicated by the defaultDownlinkBWP-Id; or
1> if the defaultDownlinkBWP-Id is not configured, and the active DL BWP is not the initialDownlinkBWP:
2> if a PDCCH addressed to C-RNTI or CS-RNTI indicating downlink assignment or uplink grant is received on the active BWP; or
2> if a PDCCH addressed to C-RNTI or CS-RNTI indicating downlink assignment or uplink grant is received for the active BWP; or
2> if a MAC PDU is transmitted in a configured uplink grant or received in a configured downlink assignment:
3> if there is no ongoing random access procedure associated with this Serving Cell; or
3> if the ongoing Random Access procedure associated with this Serving Cell is successfully completed upon reception of this PDCCH addressed to C-RNTI (as specified in subclauses 5.1.4 and 5.1.5):
4> start or restart the bwp-InactivityTimer associated with the active DL BWP.
2> if the bwp-InactivityTimer associated with the active DL BWP expires:
3> if the defaultDownlinkBWP-Id is configured:
4> perform BWP switching to a BWP indicated by the defaultDownlinkBWP-Id.
3> else:
4> perform BWP switching to the initialDownlinkBWP.
NOTE: If a Random Access procedure is initiated on an SCell, both this SCell and the SpCell are associated with this Random Access procedure.
1> if a PDCCH for BWP switching is received, and the MAC entity switches the active DL BWP:
2> if the defaultDownlinkBWP-Id is configured, and the MAC entity switches to the DL BWP which is not indicated by the defaultDownlinkBWP-Id; or
2> if the defaultDownlinkBWP-Id is not configured, and the MAC entity switches to the DL BWP which is not the initialDownlinkBWP:
3> start or restart the bwp-InactivityTimer associated with the active DL BWP.
[TS 38.331, clause 5.2.1]
System Information (SI) is divided into the MIB and a number of SIBs where:
– …
– For a UE in RRC_CONNECTED, the network can provide system information through dedicated signalling using the RRCReconfiguration message, e.g. if the UE has an active BWP with no common search space configured to monitor system information or paging.
– For PSCell and SCells, the network provides the required SI by dedicated signalling, i.e. within an RRCReconfiguration message. Nevertheless, the UE shall acquire MIB of the PSCell to get SFN timing of the SCG (which may be different from MCG). Upon change of relevant SI for SCell, RAN releases and adds the concerned SCell. For PSCell, SI can only be changed with Reconfiguration with Sync.
NOTE: The physical layer imposes a limit to the maximum size a SIB can take. The maximum SIB1 or SI message size is 2976 bits.
[TS 38.331, clause 5.3.5.3]
The UE shall perform the following actions upon reception of the RRCReconfiguration:
…
1> if the UE is configured with E-UTRA nr-SecondaryCellGroupConfig (MCG is E-UTRA):
2> if RRCReconfiguration was received via SRB1:
3> submit the RRCReconfigurationComplete via the EUTRA MCG embedded in E-UTRA RRC message RRCConnectionReconfigurationComplete as specified in TS 36.331 [10];
3> if reconfigurationWithSync was included in spCellConfig of an SCG:
4> initiate the random access procedure on the SpCell, as specified in TS 38.321 [3];
…
NOTE: For EN-DC, in the case RRCReconfiguration is received via SRB1, the random access is triggered by RRC layer itself as there is not necessarily other UL transmission. In the case RRCReconfiguration is received via SRB3, the random access is triggered by the MAC layer due to arrival of RRCReconfigurationComplete.
7.1.1.8.1.3 Test description
7.1.1.8.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
7.1.1.8.1.3.2 Test procedure sequence
Table 7.1.1.8.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0 |
The SS transmits RRCReconfiguration to configure the dedicated BWPs incl. the FirstActive BWP. (Note 1) (Note 4). |
<– |
(RRCReconfiguration) |
– |
– |
– |
EXCEPTION: Steps 0Aa1 to 0Ab2 describe behaviour which depends on procedure parameters; the "lower case letter" identifies a step sequence that take place if a procedure parameter has a particular value. |
– |
– |
– |
– |
0Aa1 |
IF Connectivity is EN-DC or NGEN-DC, the UE sends RRCReconfigurationComplete (Note 2). |
–> |
(RRCReconfigurationComplete) |
– |
– |
0Ab1 |
IF Connectivity is NR, the SS allocates (transmitted in FirstActiveDownlinkBWP) an UL Grant with DCI format 0_1 indicating FirstActiveUplinkBWP (BWP#1). |
<– |
UL Grant |
– |
– |
0Ab2 |
Check: Does the UE send RRCReconfigurationComplete in the FirstActive BWP configured? (Note 2) (Note 3) (Note 5) |
–> |
(RRCReconfigurationComplete) |
1 |
P |
1 |
The SS transmits a valid MAC PDU containing RLC PDU in the configured FirstActive Downlink BWP configured. |
<– |
MAC PDU |
– |
– |
2 |
After 100ms from step 1, the SS allocates (transmitted in FirstActiveDownlinkBWP) an UL Grant. |
<– |
UL Grant |
– |
– |
3 |
Check: Does the UE transmit a MAC PDU including one RLC SDU in the FirstActive BWP configured? (Note 5) |
–> |
MAC PDU |
1 |
P |
4 |
Void |
– |
– |
– |
– |
5 |
The SS indicates on PDCCH (transmitted in Downlink BWP#1) DL DCI format 1_1 with new BWP Id (= BWP #2) and transmits a MAC PDU containing RLC PDU on the newly configured BWP (i.e. Downlink BWP#2). |
<– |
MAC PDU |
– |
– |
6 |
After 100ms from step5, the SS allocates (transmitted in Downlink BWP#2) an UL Grant (with DCI indicating BWP#2), sufficient for loopback of the RLC SDU from step 5 in a Slot. (Note 3) |
<– |
UL Grant |
– |
– |
7 |
Check: Does the UE transmit a MAC PDU including one RLC SDU in the configured BWP (i.e. Uplink BWP#2)? (Note 5) |
–> |
MAC PDU |
2 |
P |
8 |
Void |
– |
– |
– |
– |
9 |
The SS transmits a valid MAC PDU containing RLC PDU in the configured BWP (i.e. Downlink BWP#2). |
<– |
MAC PDU |
– |
– |
10 |
After 100ms from step 9 the SS indicates on PDCCH (transmitted in Downlink BWP#2) UL DCI format 0_1 with new BWP Id (=IF pc_bwp_sameNumerology_upto4, THEN BWP #3 ELSE BWP #1) and allocates an UL Grant, sufficient for loopback of the RLC SDU from step 9 in a Slot. |
<– |
UL Grant |
– |
– |
11 |
Check: Does the UE transmit a MAC PDU including one RLC SDU in the configured BWP (i.e. (IF pc_bwp_sameNumerology_upto4, THEN BWP #3 ELSE BWP #1, for FDD and for TDD)? (Note 5) |
–> |
MAC PDU |
3 |
P |
11A |
The SS transmits a valid MAC PDU containing RLC PDU in the configured BWP (i.e. Downlink BWP#2 for FDD) or (IF pc_bwp_sameNumerology_upto4, THEN BWP #3 ELSE BWP #1 for TDD). |
<– |
MAC PDU |
– |
– |
12 |
After 100ms from step 11A the SS indicates PDCCH order on CSS for contention-based random access (transmitted in Downlink BWP#2 for FDD OR (IF pc_bwp_sameNumerology_upto4, THEN BWP #3 ELSE BWP #1 for TDD). |
<– |
PDCCH Order |
– |
– |
13 |
Check: Does the UE send PRACH Preamble in the initial BWP (UL BWP#0)? |
–> |
PRACH Preamble |
4 |
P |
13A |
The SS transmits (in Downlink BWP #0) a MAC PDU addressed to UE RA-RNTI, containing RAR with matching RAPID in MAC sub header. |
<– |
Random Access Response |
– |
– |
13B |
The UE sends (in UL BWP#0) a msg3 in the grant associated to the received Random Access Response. |
–> |
msg3 (C-RNTI MAC CONTROL ELEMENT) |
– |
– |
13C |
SS schedules (in Downlink BWP#0) PDCCH transmission for UE C-RNTI and allocates UL grant sufficient for the UE to loop back the data received at step 11a. |
<– |
Contention Resolution |
– |
– |
13D |
Check: Does the UE transmit a MAC PDU including one RLC SDU in the initial BWP (i.e. Uplink BWP#0)? (Note 5) |
–> |
MAC PDU |
4 |
P |
14-15 |
Void |
– |
– |
– |
– |
16 |
The SS indicates on PDCCH (transmitted in Downlink BWP#0) DL DCI format 1_1 with BWP Id (= BWP #1) and transmits a MAC PDU containing RLC PDU on the configured BWP (i.e. Downlink BWP#1). |
<– |
MAC PDU |
– |
– |
17 |
After 400 ms from step 16, the SS transmits another valid MAC PDU containing RLC PDU in the active BWP (i.e. Downlink BWP#1). |
<– |
MAC PDU |
– |
– |
18 |
After 400 ms from step 17, the SS allocates (transmitted in Downlink BWP#1) an UL Grant (with DCI indicating BWP#1), sufficient for loopback of a MAC PDU containing both RLC SDUs from steps 16 and 17 in a Slot. (Note 3) |
<– |
UL Grant |
– |
– |
19 |
Check: Does the UE transmit a MAC PDU containing both RLC SDUsin the active BWP (i.e. Uplink BWP#1)? (Note 5) |
–> |
MAC PDU |
5 |
P |
20 |
The SS waits 1000 ms from step 18 to ensure that the bwp-InactivityTimer expired and then transmits a valid MAC PDU containing RLC PDU in the BWP with defaultDownlinkBWP-Id (= Downlink BWP#2). |
<– |
MAC PDU |
– |
– |
21 |
The SS allocates (transmitted in the defaultDownlinkBWP, i.e. Downlink BWP#2) an UL Grant (with DCI indicating BWP#2), sufficient for loopback of the RLC SDU from step 20 in a Slot. (Note 3) |
<– |
UL Grant |
– |
– |
22 |
Check: Does the UE transmit a MAC PDU in Uplink BWP#2 (= BWP Id of the defaultDownlinkBWP)? (Note 5) |
–> |
MAC PDU |
6 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: In paired spectrum (= FDD), the switching of Downlink BWP and Uplink BWP can happen independently. Whereas in TDD, the switching of BWP for Downlink and Uplink is always at the same time instance. Currently, the scope of the Test Purposes (TP) is considered to not cover checking of a BWP deviation which results from non-synchronized Downlink and Uplink BWP switching in FDD. Note 4: After the preamble the UE is in RRC_CONNECTED, therefore SRBs and DRBs are already established. The RRCReconfiguration message in step 1 and step 14 shall not contain any elements like e.g. "rlc-BearerToAddModList" whose value(s) remain unchanged since the preamble. The sole purpose of the RRCReconfiguration message in step 1 and 14 is to configure BWPs and related fields for switching of BWPs. Note 5: When the UE does not use the expected BWP for the UL transmission the SS shall not receive the data what implicitly fails the test case. |
7.1.1.8.1.3.3 Specific message contents
Table 7.1.1.8.1.3.3-0: Conditions for specific message contents
Condition |
Explanation |
BWP#1 |
Bandwidth part 1 |
BWP#2 |
Bandwidth part 2 |
BWP#3 |
Bandwidth part 3 |
Table 7.1.1.8.1.3.3-1: RRCReconfiguration (step 0)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-13 (see also Note 4 in Table 7.1.1.8.1.3.2-1) |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
||
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
|||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.8.1.3.3-1A: CellGroupConfig (Table 7.1.1.8.1.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
mac-CellGroupConfig |
Not present |
||
physicalCellGroupConfig |
Not present |
||
spCellConfig SEQUENCE { |
|||
servCellIndex |
Not present |
||
ServCellIndex |
EN-DC |
||
spCellConfigCommon |
Not present |
||
rlf-TimersAndConstants |
Not present |
||
spCellConfigDedicated |
ServingCellConfig–Dedicated |
Table 7.1.1.8.1.3.3-2 |
|
} |
|||
reportUplinkTxDirectCurrent-v1530 |
true |
||
} |
Table 7.1.1.8.1.3.3-2: ServingCellConfig-Dedicated (Table 7.1.1.8.1.3.3-1A)
Derivation Path: TS 38.508-1 [4] Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
tdd-UL-DL-ConfigurationDedicated |
Not present |
||
TDD-UL-DL-ConfigDedicated |
TDD |
||
..initialDownlinkBWP ::= SEQUENCE { |
|||
pdcch-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
pdsch-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
} |
|||
downlinkBWP-ToAddModList SEQUENCE (SIZE (1..maxNrofBWPs)) BWP-Downlink { |
3 entries |
||
BWP-Downlink[1] |
BWP-Downlink-BWP-N with condition BWP#1 |
entry 1 |
|
BWP-Downlink[2] |
BWP-Downlink-BWP-N with condition BWP#2 |
entry 2 |
|
BWP-Downlink[3] |
BWP-Downlink-BWP-N with condition BWP#3 |
entry 3 |
pc_bwp_sameNumerology_upto4 |
} |
|||
firstActiveDownlinkBWP-Id |
1 |
||
bwp-InactivityTimer |
ms750 |
||
defaultDownlinkBWP-Id |
2 |
||
uplinkConfig SEQUENCE { |
|||
initialUplinkBWP ::= SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
pusch-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
srs-Config CHOICE { |
|||
release |
NULL |
||
} |
|||
} |
|||
uplinkBWP-ToReleaseList |
Not present |
||
uplinkBWP-ToAddModList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Uplink { |
3 entries |
||
BWP-Uplink[1] |
BWP-Uplink-BWP-N with condition BWP#1 |
entry 1 |
|
BWP-Uplink[2] |
BWP-Uplink-BWP-N with condition BWP#2 |
entry 2 |
|
BWP-Uplink[3] |
BWP-Uplink-BWP-N with condition BWP#3 |
entry 3 |
pc_bwp_sameNumerology_upto4 |
} |
|||
firstActiveUplinkBWP-Id |
1 |
||
pusch-ServingCellConfig |
Not present |
||
} |
|||
pdcch-ServingCellConfig |
Not present |
||
pdsch-ServingCellConfig |
Not present |
||
csi-MeasConfig |
CSI-MeasConfig for TRS |
pc_bwp-WithoutRestriction = True |
|
} |
Table 7.1.1.8.1.3.3-2A: BWP-Downlink-BWP-N (Table 7.1.1.8.1.3.3-2 and Table 7.1.1.8.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-9 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-Downlink ::= SEQUENCE { |
|||
bwp-Id |
1 |
BWP#1 |
|
2 |
BWP#2 |
||
3 |
BWP#3 |
||
bwp-Common SEQUENCE { |
|||
genericParameters SEQUENCE { |
|||
locationAndBandwidth |
1381 |
Note 1 |
BWP#1 and pc_bwp-WithoutRestriction = True |
1387 |
Note 1 |
BWP#2 and pc_bwp-WithoutRestriction = True |
|
1393 |
Note 1 |
BWP#3 and pc_bwp-WithoutRestriction = True |
|
6600 |
Note 2 |
BWP#1,2,3 and pc_bwp-WithoutRestriction = False and 5MHz |
|
7975 |
Note 3 |
BWP#1 and pc_bwp-WithoutRestriction = False |
|
9625 |
Note 3 |
BWP#2 and pc_bwp-WithoutRestriction = False |
|
11275 |
Note 3 |
BWP#3 and pc_bwp-WithoutRestriction = False |
|
12925 |
Note 4 |
BWP#1and pc_bwp-WithoutRestriction = False and 100MHz |
|
14575 |
Note 4 |
BWP#2and pc_bwp-WithoutRestriction = False and 100MHz |
|
16225 |
Note 4 |
BWP#3 and pc_bwp-WithoutRestriction = False and 100MHz |
|
} |
|||
pdcch-ConfigCommon |
Not present |
no cell specific configuration for dedicated BWP |
|
pdsch-ConfigCommon |
Not present |
no cell specific configuration for dedicated BWP |
|
} |
|||
bwp-Dedicated SEQUENCE { |
|||
pdcch-Config CHOICE { |
|||
setup |
PDCCH-Config-BWP-N |
||
} |
|||
pdsch-Config CHOICE { |
|||
setup |
PDSCH-Config-BWP-N |
||
} |
|||
} |
|||
} |
|||
Note 1: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=6 and RBStart=6,12,18 for BWP#1,2,3 Note 2: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=25 and RBStart=0 for BWP#1,2,3 Note 3: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=30,36,42 and RBStart=0 for BWP#1,2,3 Note 4: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=48,54,60 and RBStart=0 for BWP#1,2,3 |
Table 7.1.1.8.1.3.3-2B: PDCCH-Config-BWP-N (Table 7.1.1.8.1.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-95 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDCCH-Config::= SEQUENCE { |
|||
controlResourceSetToAddModList SEQUENCE (SIZE (1..3)) OF ControlResourceSet { |
2 entries |
||
ControlResourceSet[1] |
ControlResourceSet-BWP-N with condition BWP#N |
entry 1 |
|
} |
|||
searchSpacesToAddModList SEQUENCE (SIZE (1..10)) OF SearchSpace { |
1 entry |
||
SearchSpace[1] |
SearchSpace-BWP-N with condition BWP#N |
entry 1 |
|
SearchSpace[2] |
SearchSpace-CSS-BWP-N with condition BWP#N |
entry 2 |
|
} |
|||
} |
Table 7.1.1.8.1.3.3-2C: PDSCH-Config (Table 7.1.1.8.1.3.3-2A)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-100 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDSCH-Config ::= SEQUENCE { |
|||
tci-StatesToAddModList SEQUENCE(SIZE (1.. maxNrofTCI-States)) OF TCI-State { |
2 entries |
pc_bwp-WithoutRestriction = True |
|
TCI-State[1] SEQUENCE { |
entry 1 |
||
tci-StateId |
0 |
||
qcl-type1 SEQUENCE { |
|||
cell |
ServCellIndex |
As per 38.508-1 Table 4.6.3-166 |
|
bwp-id |
Not present |
||
referenceSignal CHOICE { |
|||
ssb |
1 |
||
} |
|||
qcl-Type |
type C |
||
} |
|||
qcl-type2 |
Not present |
||
qcl-type2 SEQUENCE { |
FR2 |
||
cell |
ServCellIndex |
As per 38.508-1 Table 4.6.3-166 |
|
bwp-id |
Not present |
BWP ID |
|
referenceSignal CHOICE { |
|||
ssb |
1 |
||
} |
|||
qcl-Type |
type D |
||
} |
|||
} |
|||
TCI-State[2] SEQUENCE { |
entry 2 |
||
tci-StateId |
1 |
||
qcl-type1 SEQUENCE { |
|||
cell |
ServCellIndex |
As per 38.508-1 Table 4.6.3-166 |
|
bwp-id |
1 |
BWP#1 |
|
2 |
BWP#2 |
||
3 |
BWP#3 |
||
referenceSignal CHOICE { |
|||
csi-rs |
1 |
||
} |
|||
qcl-Type |
type A |
||
} |
|||
qcl-type2 |
Not present |
||
qcl-type2 SEQUENCE { |
FR2 |
||
cell |
ServCellIndex |
As per 38.508-1 Table 4.6.3-166 |
|
bwp-id |
1 |
BWP#1 |
|
2 |
BWP#2 |
||
3 |
BWP#3 |
||
referenceSignal CHOICE { |
|||
csi-rs |
1 |
||
} |
|||
qcl-Type |
type D |
||
} |
|||
} |
|||
} |
|||
PDSCH-TimeDomainAllocationList::= SEQUENCE { |
PDSCH-TimeDomainResourceAllocationList |
||
} |
Table 7.1.1.8.1.3.3-2CA: PDSCH-TimeDomainResourceAllocationList (Table 7.1.1.8.1.3.3-2C)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDSCH-TimeDomainAllocationList::= SEQUENCE { |
|||
PDSCH-TimeDomainResourceAllocation[1] SEQUENCE { |
entry 1 |
||
k0 |
1 |
pc_bwp-SwitchingDelay_Type1 AND SCS_15KHz |
|
3 |
pc_bwp_SwitchingDelay_Type2 AND SCS_15KHz |
||
2 |
pc_bwp-SwitchingDelay_Type1 AND SCS_30KHz |
||
5 |
pc_bwp_SwitchingDelay_Type2 AND SCS_30KHz |
||
3 |
pc_bwp-SwitchingDelay_Type1 AND SCS_60KHz |
||
9 |
pc_bwp_SwitchingDelay_Type2 AND SCS_60KHz |
||
6 |
pc_bwp-SwitchingDelay_Type1 AND SCS_120KHz |
||
18 |
pc_bwp_SwitchingDelay_Type2 AND SCS_120KHz |
||
mappingType |
typeA |
||
startSymbolAndLength |
53 |
Start symbol(S)=2, Length(L)=12 |
|
} |
|||
} |
Table 7.1.1.8.1.3.3-2D: ControlResourceSet-BWP-N (Table 7.1.1.8.1.3.3-2B)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-28 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ControlResourceSet ::= SEQUENCE { |
|||
controlResourceSetId |
9 |
BWP#1 |
|
10 |
BWP#2 |
||
11 |
BWP#3 |
||
frequencyDomainResources |
10000000 00000000 00000000 00000000 00000000 00000 |
CORESET to use the least significant 6 RBs of each BWP |
|
duration |
2 |
SearchSpace duration of 2 symbols |
|
tci-StatesPDCCH-ToAddList SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId { |
1 entry |
pc_bwp-WithoutRestriction = True |
|
TCI-StateId[1] |
1 |
TRS |
|
} |
|||
} |
Table 7.1.1.8.1.3.3-2E: SearchSpace-BWP-N (Table 7.1.1.8.1.3.3-2B)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-162 with condition USS |
|||
Information Element |
Value/remark |
Comment |
Condition |
SearchSpace ::= SEQUENCE { |
|||
searchSpaceId |
37 |
BWP#1 |
|
38 |
BWP#2 |
||
39 |
BWP#3 |
||
controlResourceSetId |
9 |
BWP#1 |
|
10 |
BWP#2 |
||
11 |
BWP#3 |
||
nrofCandidates SEQUENCE { |
|||
aggregationLevel1 |
n0 |
||
aggregationLevel2 |
n1 |
||
aggregationLevel4 |
n0 |
||
aggregationLevel8 |
n0 |
||
aggregationLevel16 |
n0 |
||
} |
|||
} |
Table 7.1.1.8.1.3.3-2F: BWP-Uplink-BWP-N (Table 7.1.1.8.1.3.3-2 and Table 7.1.1.8.1.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-Uplink ::= SEQUENCE { |
|||
bwp-Id |
1 |
BWP#1 |
|
2 |
BWP#2 |
||
3 |
BWP#3 |
||
bwp-Common SEQUENCE { |
|||
genericParameters SEQUENCE { |
|||
locationAndBandwidth |
1381 |
Note 1 |
BWP#1 and pc_bwp-WithoutRestriction = True |
1387 |
Note 1 |
BWP#2 and pc_bwp-WithoutRestriction = True |
|
1393 |
Note 1 |
BWP#3 and pc_bwp-WithoutRestriction = True |
|
6600 |
Note 2 |
BWP#1,2,3 and pc_bwp-WithoutRestriction = False and 5MHz |
|
7975 |
Note 3 |
BWP#1 and pc_bwp-WithoutRestriction = False |
|
9625 |
Note 3 |
BWP#2and pc_bwp-WithoutRestriction = False |
|
11275 |
Note 3 |
BWP#3 and pc_bwp-WithoutRestriction = False |
|
12925 |
Note 4 |
BWP#1 and pc_bwp-WithoutRestriction = False and 100MHz |
|
14575 |
Note 4 |
BWP#2and pc_bwp-WithoutRestriction = False and 100MHz |
|
16225 |
Note 4 |
BWP#3 and pc_bwp-WithoutRestriction = False and 100MHz |
|
} |
|||
rach-ConfigCommon |
Not present |
No cell specific configuration for dedicated BWP |
|
pusch-ConfigCommon |
Not present |
no cell specific configuration for dedicated BWP |
|
pucch-ConfigCommon |
PUCCH-ConfigCommon-BWP-N |
||
} |
|||
bwp-Dedicated SEQUENCE { |
|||
pucch-Config CHOICE { |
|||
setup |
PUCCH-Config-BWP-N |
||
} |
|||
pusch-Config CHOICE { |
|||
setup |
PUSCH-Config-BWP-N |
||
} |
|||
} |
|||
} |
|||
Note 1:According to TS 38.214 [21] clause 6.1.2.2.2 with =275, LRBs=6 and RBStart=6,12,18 for BWP#1,2,3 Note 2: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=25 and RBStart=0 for BWP#1,2,3 Note 3: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=30,36,42 and RBStart=0 for BWP#1,2,3 Note 4: According to TS 38.214 [21] clause 5.1.2.2.2 with =275, LRBs=48,54,60 and RBStart=0 for BWP#1,2,3 |
Condition |
Explanation |
BWP#1 |
Bandwidth part 1 |
BWP#2 |
Bandwidth part 2 |
BWP#3 |
Bandwidth part 3 |
5MHz |
According to TS 38.508-1 [4] clause 6.2.3.1 with CBW=5Mhz |
100MHz |
According to TS 38.508-1 [4] clause 6.2.3.1 with CBW=100Mhz |
Table 7.1.1.8.1.3.3-2G: PUCCH-Config-BWP-N (Table 7.1.1.8.1.3.3-2F)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-112 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-Config::= SEQUENCE { |
|||
resourceSetToAddModList SEQUENCE (SIZE (1..4)) OF PUCCH-ResourceSet { |
1 entry |
||
PUCCH-ResourceSet[1] SEQUENCE { |
entry 1 |
||
pucch-ResourceSetId |
0 |
||
resourceList SEQUENCE (SIZE (1..32)) OF PUCCH-ResourceId { |
1 entry |
||
PUCCH-ResourceId[1] |
0 |
entry 1 |
|
} |
|||
maxPayloadSize |
256 |
||
} |
|||
} |
|||
resourceToAddModList SEQUENCE (SIZE (1..128)) OF PUCCH-Resource { |
1 entry |
||
PUCCH-Resource[1] SEQUENCE { |
entry 1 |
||
pucch-RessourceId |
0 |
||
startingPRB |
0 |
BWP#1 |
|
0 |
BWP#2 |
||
0 |
BWP#3 |
||
intraSlotFrequencyHopping |
disabled |
||
secondHopPRB |
Not Present |
||
format CHOICE { |
|||
format0 SEQUENCE { |
|||
initialCyclicShift |
0 |
||
nrofSymbols |
2 |
||
startingSymbolIndex |
0 |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Condition |
Explanation |
BWP#1 |
Bandwidth part 1 |
BWP#2 |
Bandwidth part 2 |
BWP#3 |
Bandwidth part 3 |
Table 7.1.1.8.1.3.3-2H: PUSCH-Config-BWP-N (Table 7.1.1.8.1.3.3-2F)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-118 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUSCH-Config ::= SEQUENCE { |
|||
pusch-TimeDomainAllocationList |
PUSCH-TimeDomainResourceAllocationList |
TS 38.508-1 [4] Table 4.6.3-122 |
|
} |
Table 7.1.1.8.1.3.3-3: PUCCH-ConfigCommon-BWP-N (Table 7.1.1.8.1.3.3-2F)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-113 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-ConfigCommon ::= SEQUENCE { |
|||
pucch-ResourceCommon |
Not Present |
||
pucch-GroupHopping |
enable |
||
hoppingId |
Not present |
||
p0-nominal |
Not Present |
||
} |
Table 7.1.1.8.1.3.3-4: SearchSpace-CSS-BWP-N (Table 7.1.1.8.1.3.3-2B)
Derivation Path: TS 38.508-1[4], Table 4.6.3-162 with condition CSS |
|||
Information Element |
Value/remark |
Comment |
Condition |
SearchSpace ::= SEQUENCE { |
|||
searchSpaceId |
30 |
BWP#1 |
|
31 |
BWP#2 |
||
32 |
BWP#3 |
||
controlResourceSetId |
9 |
BWP#1 |
|
10 |
BWP#2 |
||
11 |
BWP#3 |
||
nrofCandidates SEQUENCE { |
|||
aggregationLevel1 |
n0 |
||
aggregationLevel2 |
n1 |
||
aggregationLevel4 |
n0 |
||
aggregationLevel8 |
n0 |
||
aggregationLevel16 |
n0 |
||
} |
|||
} |
|||
} |
Table 7.1.1.8.1.3.3-5: CSI-MeasConfig for TRS (Table 7.1.1.8.1.3.3-2)
Derivation Path: TS 38.508-1[4] Table 4.6.3-38 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CSI-MeasConfig::= SEQUENCE { |
|||
nzp-CSI-RS-ResourceToAddModList SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-Resources)) OF NZP-CSI-RS-Resource { |
2 entries in case of FR2 4 entries in case of FR1 |
2 entries in case of FR2 4 entries in case of FR1 |
|
NZP-CSI-RS-Resource[1] |
NZP-CSI-RS-Resource for TRS (1) |
entry 1 CSI-RS resource 1 |
|
NZP-CSI-RS-Resource[2] |
NZP-CSI-RS-Resource for TRS (2) |
entry 2 CSI-RS resource 2 |
|
NZP-CSI-RS-Resource[3] |
NZP-CSI-RS-Resource for TRS (3) |
entry 3 CSI-RS resource 3 |
FR1 |
NZP-CSI-RS-Resource[4] |
NZP-CSI-RS-Resource for TRS (4) |
entry 4 CSI-RS resource 4 |
FR1 |
} |
|||
nzp-CSI-RS-ResourceSetToAddModList SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-ResourceSets)) OF NZP-CSI-RS-ResourceSet { |
1 entry |
||
NZP-CSI-RS-ResourceSet[1] |
NZP-CSI-RS-ResourceSet for TRS |
entry 1 |
|
} |
|||
csi-IM-ResourceToAddModList |
Not present |
||
csi-IM-ResourceSetToAddModList |
Not present |
||
csi-SSB-ResourceSetToAddModList |
Not present |
||
csi-ResourceConfigToAddModList SEQUENCE (SIZE (1..maxNrofCSI-ResourceConfigurations)) OF CSI-ResourceConfig { |
1 entry |
||
CSI-ResourceConfig[1] |
CSI-ResourceConfig for TRS |
entry 1 |
|
} |
|||
reportTriggerSize |
Not present |
||
aperiodicTriggerStateList SetupRelease |
Not present |
||
} |
Table 7.1.1.8.1.3.3-6: NZP-CSI-RS-ResourceSet for TRS (Table 7.1.1.8.1.3.3-5)
Derivation Path: TS 38.508-1[4] Table 4.6.3-87 |
|||
Information Element |
Value/remark |
Comment |
Condition |
NZP-CSI-RS-ResourceSet ::= SEQUENCE { |
|||
nzp_CSI_ResourceSetId |
0 |
||
nzp-CSI-RS-Resources SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-ResourcesPerSet)) OF NZP-CSI-RS-ResourceId { |
2 entries in case of FR2 4 entries in case of FR1 |
||
NZP-CSI-RS-ResourceId[1] |
0 |
entry 1 CSI-RS resource 1 |
|
NZP-CSI-RS-ResourceId[2] |
1 |
entry 2 CSI-RS resource 2 |
|
NZP-CSI-RS-ResourceId[3] |
2 |
entry 3 CSI-RS resource 3 |
FR1 |
NZP-CSI-RS-ResourceId[4] |
3 |
entry 4 CSI-RS resource 4 |
FR1 |
} |
|||
repetition |
off |
||
aperiodicTriggeringOffset |
Not present |
||
trs_Info |
true |
||
} |
Table 7.1.1.8.1.3.3-7: CSI-ResourceConfig for TRS (Table 7.1.1.8.1.3.3-5)
Derivation Path: TS 38.508-1[4] Table 4.6.3-41 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CSI-ResourceConfig ::= SEQUENCE { |
|||
csi-ResourceConfigId |
0 |
||
csi-RS-ResourceSetList CHOICE { |
|||
nzp-CSI-RS-SSB SEQUENCE { |
|||
nzp-CSI-RS-ResourceSetList SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-ResourceSetsPerConfig)) OF NZP-CSI-RS-ResourceSetId { |
1 entry |
||
NZP-CSI-RS-ResourceSetId[1] |
0 |
entry 1 |
|
} |
|||
csi-SSB-ResourceSetList |
Not present |
||
} |
|||
} |
|||
bwp-Id |
BWP-Id |
||
resourceType |
periodic |
||
} |
Table 7.1.1.8.1.3.3-8: NZP-CSI-RS-Resource for TRS (Table 7.1.1.8.1.3.3-5)
Derivation Path: TS 38.508-1[4] Table 4.6.3-85 |
|||
Information Element |
Value/remark |
Comment |
Condition |
NZP-CSI-RS-Resource ::= SEQUENCE { |
|||
nzp-CSI-RS-ResourceId |
0 |
CSI-RS resource 1 |
|
1 |
CSI-RS resource 2 |
||
2 |
CSI-RS resource 3 |
||
3 |
CSI-RS resource 4 |
||
resourceMapping |
CSI-RS-ResourceMapping for TRS |
||
powerControlOffset |
0 |
||
periodicityAndOffset |
CSI-ResourcePeriodicityAndOffset for TRS |
||
qcl-InfoPeriodicCSI-RS |
TCI-StateId 0 |
7.1.1.8.2
7.1.1.8.3 Separate BWP / IDLE / RedCap
7.1.1.8.3.1 Test Purpose (TP)
(1)
with { UE supporting RedCap and in NR RRC_IDLE state }
ensure that {
when { initialDownlinkBWP-RedCap is configured }
then { the UE shall monitor the PDCCH on the BWP configured by initialDownlinkBWP-RedCap }
}
(2)
with { UE supporting RedCap and in NR RRC_IDLE state }
ensure that {
when { initialUplinkBWP-RedCap is configured and the UE needs to perform the Random Access procedure }
then { the UE shall perform the Random Access procedure by using the BWP configured by initialUplinkBWP-RedCap }
}
7.1.1.8.3.2 Conformance requirements
References: The conformance requirements covered in the present test case are specified in: TS 38.321, clause 5.15.1. Unless otherwise stated these are Rel-17 requirements.
[TS 38.321, clause 5.15.1]
A RedCap UE may be configured with a RedCap-specific initial UL BWP in initialUplinkBWP-RedCap, as specified in TS 38.331 [5].
Upon initiation of the Random Access procedure on a Serving Cell, after the selection of carrier for performing Random Access procedure as specified in clause 5.1.1, the MAC entity shall for the selected carrier of this Serving Cell:
1> if PRACH occasions are not configured for the active UL BWP:
2> if the UE is a RedCap UE; and
2> if initialUplinkBWP-RedCap is configured:
3> switch the active UL BWP to BWP configured by initialUplinkBWP-RedCap.
2> else:
3> switch the active UL BWP to BWP indicated by initialUplinkBWP.
2> if the Serving Cell is an SpCell:
3> if the UE is a RedCap UE; and
3> if initialDownlinkBWP-RedCap is configured:
4> switch the active DL BWP to BWP configured by initialDownlinkBWP-RedCap.
3> else:
4> switch the active DL BWP to BWP indicated by initialDownlinkBWP.
1> else:
2> if the Serving Cell is an SpCell:
3> if the active DL BWP does not have the same bwp-Id as the active UL BWP:
4> switch the active DL BWP to the DL BWP with the same bwp-Id as the active UL BWP.
1> stop the bwp-InactivityTimer associated with the active DL BWP of this Serving Cell, if running.
1> if the Serving Cell is SCell:
2> stop the bwp-InactivityTimer associated with the active DL BWP of SpCell, if running.
1> perform the Random Access procedure on the active DL BWP of SpCell and active UL BWP of this Serving Cell.
If the MAC entity receives a PDCCH for BWP switching of a Serving Cell, the MAC entity shall:
1> if there is no ongoing Random Access procedure associated with this Serving Cell; or
1> if the ongoing Random Access procedure associated with this Serving Cell is successfully completed upon reception of this PDCCH addressed to C-RNTI (as specified in clauses 5.1.4, 5.1.4a, and 5.1.5):
2> cancel, if any, triggered consistent LBT failure for this Serving Cell;
2> perform BWP switching to a BWP indicated by the PDCCH.
…
Upon reception of RRC (re-)configuration for BWP switching for a Serving Cell, cancel any triggered LBT failure in this Serving Cell.
The MAC entity shall for each activated Serving Cell configured with bwp-InactivityTimer:
1> if the defaultDownlinkBWP-Id is configured, and the active DL BWP is not the BWP indicated by the defaultDownlinkBWP-Id, and the active DL BWP is not the BWP indicated by the dormantBWP-Id if configured; or
1> if the defaultDownlinkBWP-Id is not configured, and if the UE is not a RedCap UE, and the active DL BWP is not the initialDownlinkBWP, and the active DL BWP is not the BWP indicated by the dormantBWP-Id if configured; or
1> if the defaultDownlinkBWP-Id is not configured and if the UE is a RedCap UE, and initialDownlinkBWP-RedCap is not configured, and the active DL BWP is not the initialDownlinkBWP, and the active DL BWP is not the BWP indicated by the dormantBWP-Id if configured; or
1> if the defaultDownlinkBWP-Id is not configured and if the UE is a RedCap UE, and initialDownlinkBWP-RedCap is configured, the active DL BWP is not the initialDownlinkBWP-RedCap, and the active DL BWP is not the BWP indicated by the dormantBWP-Id if configured:
2> if a PDCCH addressed to C-RNTI or CS-RNTI indicating downlink assignment or uplink grant is received on the active BWP; or
2> if a PDCCH addressed to G-RNTI or G-CS-RNTI configured for multicast indicating downlink assignment is received on the active BWP; or
2> if a PDCCH addressed to C-RNTI or CS-RNTI indicating downlink assignment or uplink grant is received for the active BWP; or
2> if a MAC PDU is transmitted in a configured uplink grant and LBT failure indication is not received from lower layers; or
2> if a MAC PDU is received in a configured downlink assignment for unicast or MBS multicast:
3> if there is no ongoing Random Access procedure associated with this Serving Cell; or
3> if the ongoing Random Access procedure associated with this Serving Cell is successfully completed upon reception of this PDCCH addressed to C-RNTI (as specified in clauses 5.1.4, 5.1.4a and 5.1.5):
4> start or restart the bwp-InactivityTimer associated with the active DL BWP.
2> if the bwp-InactivityTimer associated with the active DL BWP expires:
3> if the defaultDownlinkBWP-Id is configured:
4> perform BWP switching to a BWP indicated by the defaultDownlinkBWP-Id.
3> else:
4> if the UE is a RedCap UE; and
4> if initialDownlinkBWP-RedCap is configured:
5> perform BWP switching to the initialDownlinkBWP-RedCap.
4> else:
5> perform BWP switching to the initialDownlinkBWP.
NOTE: If a Random Access procedure is initiated on an SCell, both this SCell and the SpCell are associated with this Random Access procedure.
1> if a PDCCH for BWP switching is received, and the MAC entity switches the active DL BWP:
2> if the defaultDownlinkBWP-Id is configured, and the MAC entity switches to the DL BWP which is not indicated by the defaultDownlinkBWP-Id and is not indicated by the dormantBWP-Id if configured; or
2> if the defaultDownlinkBWP-Id is not configured, and the MAC entity switches to the DL BWP which is not the initialDownlinkBWP and is not indicated by the dormantBWP-Id if configured:
3> start or restart the bwp-InactivityTimer associated with the active DL BWP.
Upon initiation of the Random Access procedure, after selection of the carrier for performing Random Access procedure as specified in clause 5.1.1, if the UE is a RedCap UE in RRC_IDLE or RRC_INACTIVE mode, the MAC entity shall:
1> if initialUplinkBWP-RedCap is configured:
2> perform the Random Access procedure as specified in clause 5.1 by using the BWP configured by initialUplinkBWP-RedCap.
1> else:
2> perform the Random Access procedure as specified in clause 5.1 by using the BWP configured by initialUplinkBWP.
1> if initialDownlinkBWP-RedCap is configured:
2> monitor the PDCCH on the BWP configured by initialDownlinkBWP-RedCap.
1> else:
2> monitor the PDCCH on the BWP configured by initialDownlinkBWP.
7.1.1.8.3.3 Test description
7.1.1.8.3.3.1 Pre-test conditions
System Simulator:
– NR Cell 2.
UE:
– None
Preamble:
– The UE is in NR RRC_Idle mode (state 1N-A) on NR Cell 1 according to 38.508-1 [4] Table 4.4A.2-1.
7.1.1.8.3.3.2 Test procedure sequence
Table 7.1.1.8.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS changes the SIB1 of NR Cell 1 to configure initialDownlinkBWP-RedCap and initialUplinkBWP-RedCap. |
– |
– |
– |
— |
2 |
The SS transmits a Short message on PDCCH using P-RNTI indicating a systemInfoModification. |
<– |
PDCCH (DCI 1_0): Short Message |
– |
– |
3 |
Wait for 2.1* modification period second for the UE to receive new system information. (Note 1) |
– |
– |
– |
– |
4 |
The SS transmits a Paging message within the BWP configured by initialDownlinkBWP-RedCap. |
<– |
NR RRC: Paging |
– |
– |
5 |
Check: Does the UE transmit an RRCSetupRequest message by setting LCID to 36? |
–> |
NR RRC: RRCSetupRequest |
1 |
P |
6 |
The SS transmits an RRCSetup message. |
<– |
NR RRC: RRCSetup |
– |
– |
7 |
Check: Does the UE transmit HARQ ACK for step 6 on PUCCH configured by initialUplinkBWP-RedCap? |
–> |
HARQ ACK |
2 |
P |
8-13a1 |
Steps 4-9a1 of Generic procedure as specified in TS 38.508-1 [4] Table 4.9.4.2.2-1 are performed. |
– |
– |
– |
– |
Note 1: The modification period, expressed in number of radio frames = modificationPeriodCoeff * defaultPagingCycle. |
7.1.1.8.3.3.3 Specific message contents
Table 7.1.1.8.3.3.3-1: SIB1 (step 1, Table 7.1.1.8.3.3.2-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.1-28 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
SIB1 ::= SEQUENCE { |
||||
servingCellConfigCommon |
ServingCellConfigCommonSIB |
Table 7.1.1.8.3.3.3-2 |
||
} |
Table 7.1.1.8.3.3.3-2: ServingCellConfigCommonSIB (Table 7.1.1.8.3.3.3-1)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-169 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommonSIB ::= SEQUENCE { |
|||
downlinkConfigCommon |
DownlinkConfigCommonSIB |
Table 7.1.1.8.3.3.3-3 |
|
uplinkConfigCommon |
UplinkConfigCommonSIB |
Table 7.1.1.8.3.3.3-7 |
|
} |
Table 7.1.1.8.3.3.3-3: DownlinkConfigCommonSIB (Table 7.1.1.8.3.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-53 |
|||
Information Element |
Value/remark |
Comment |
Condition |
DownlinkConfigCommonSIB ::= SEQUENCE { |
|||
pei-Config-r17 |
Not present |
||
initialDownlinkBWP-RedCap-r17 |
BWP-DownlinkCommon-RedCap |
Table 7.1.1.8.3.3.3-4 |
|
} |
Table 7.1.1.8.3.3.3-4: BWP-DownlinkCommon-RedCap (Table 7.1.1.8.3.3.3-3)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-10 with condition InitialBWP_SIB |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-DownlinkCommon ::= SEQUENCE { |
|||
pdcch-ConfigCommon CHOICE { |
|||
setup |
PDCCH-ConfigCommon |
Table 7.1.1.8.3.3.3-5 |
|
} |
|||
} |
Table 7.1.1.8.3.3.3-5: PDCCH-ConfigCommon (Table 7.1.1.8.3.3.3-4)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-96 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDCCH-ConfigCommon ::= SEQUENCE { |
|||
commonSearchSpaceList SEQUENCE (SIZE (1..4)) OF SearchSpace { |
3 entries |
||
SearchSpace[1] |
SearchSpace with condition CSS |
entry 1 |
|
SearchSpace[2] |
SearchSpace with condition SISS |
entry 2 |
|
SearchSpace[3] |
SearchSpace |
entry 3, Table 7.1.1.8.3.3.3-6 |
|
} |
|||
pagingSearchSpace |
4 |
||
} |
Table 7.1.1.8.3.3.3-6: SearchSpace (Table 7.1.1.8.3.3.3-5)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-162 with condition CSS |
|||
Information Element |
Value/remark |
Comment |
Condition |
SearchSpace ::= SEQUENCE { |
|||
searchSpaceId |
4 |
||
monitoringSlotPeriodicityAndOffset CHOICE { |
|||
sl10 |
2 |
||
} |
|||
} |
Table 7.1.1.8.3.3.3-7: UplinkConfigCommonSIB (Table 7.1.1.8.3.3.3-2)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-202 |
|||
Information Element |
Value/remark |
Comment |
Condition |
UplinkConfigCommonSIB ::= SEQUENCE { |
|||
UplinkConfigCommonSIB-v1700 ::= SEQUENCE { |
|||
initialUplinkBWP-RedCap-r17 |
BWP-UplinkCommon |
Table 7.1.1.8.3.3.3-8 |
|
} |
|||
} |
Table 7.1.1.8.3.3.3-8: BWP-UplinkCommon (Table 7.1.1.8.3.3.3-7)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-14 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-UplinkCommon ::= SEQUENCE { |
|||
pucch-ConfigCommon CHOICE { |
|||
setup |
PUCCH-ConfigCommon |
Table 7.1.1.8.3.3.3-9 |
|
} |
|||
} |
Table 7.1.1.8.3.3.3-9: PUCCH-ConfigCommon (Table 7.1.1.8.3.3.3-8)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-113 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PUCCH-ConfigCommon ::= SEQUENCE { |
|||
nrofPRBs |
Not present |
||
intra-SlotFH-r17 |
fromLowerEdge |
||
pucch-ResourceCommon-RedCap-r17 |
0 |
||
additionalPRBOffset-r17 |
n2 |
||
} |
7.1.1.9 MAC Reconfiguration and Reset
7.1.1.9.1 MAC Reset
7.1.1.9.1.1 Test Purpose (TP)
(1)
Void
(2)
with { UE in RRC_CONNECTED state )
ensure that {
when{ UE MAC is reset, due to reconfiguration with sync on same cell }
then { UE considers the next transmission for each DL HARQ process as very first }
}
(3)
Void
(4)
with ( UE in RRC_CONNECTED state )
ensure that {
when{ UE MAC is reset, due to reconfiguration with sync on same cell }
then { UE flushes UL HARQ buffer }
}
(5)
with (UE in RRC_CONNECTED state )
ensure that {
when{ UE MAC is reset, due to reconfiguration with sync on same cell }
then { UE Considers the next transmission for each UL HARQ process as very first }
}
7.1.1.9.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.12 and TS 38.331 clause 5.3.5.5.2. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.12]
If a reset of the MAC entity is requested by upper layers, the MAC entity shall:
1> initialize Bj for each logical channel to zero;
1> stop (if running) all timers;
1> consider all timeAlignmentTimers as expired and perform the corresponding actions in subclause 5.2;
1> set the NDIs for all uplink HARQ processes to the value 0;
1> stop, if any, ongoing Random Access procedure;
1> discard explicitly signalled contention-free Random Access Resources, if any;
1> flush Msg3 buffer;
1> cancel, if any, triggered Scheduling Request procedure;
1> cancel, if any, triggered Buffer Status Reporting procedure;
1> cancel, if any, triggered Recommended bit rate query procedure;
1> cancel, if any, triggered Configured uplink grant confirmation;
1> cancel, if any, triggered Power Headroom Reporting procedure;
1> flush the soft buffers for all DL HARQ processes;
1> for each DL HARQ process, consider the next received transmission for a TB as the very first transmission;
1> release, if any, Temporary C-RNTI;
1> reset BFI_COUNTER.
[TS 38.331, clause 5.3.5.5.2]
The UE shall perform the following actions to execute a reconfiguration with sync.
1> if the AS security is not activated, perform the actions upon going to RRC_IDLE as specified in 5.3.11 with the release cause ‘other‘ upon which the procedure ends;
1> stop timer T310 for the corresponding SpCell, if running;
1> start timer T304 for the corresponding SpCell with the timer value set to t304, as included in the reconfigurationWithSync;
1> if the frequencyInfoDL is included:
2> consider the target SpCell to be one on the SSB frequency indicated by the frequencyInfoDL with a physical cell identity indicated by the physCellId;
1> else:
2> consider the target SpCell to be one on the SSB frequency of the source SpCell with a physical cell identity indicated by the physCellId;
1> start synchronising to the DL of the target SpCell;
1> apply the specified BCCH configuration defined in 9.1.1.1;
1> acquire the MIB, which is scheduled as specified in TS 38.213 [13];
NOTE 1: The UE should perform the reconfiguration with sync as soon as possible following the reception of the RRC message triggering the reconfiguration with sync, which could be before confirming successful reception (HARQ and ARQ) of this message.
NOTE 2: The UE may omit reading the MIB if the UE already has the required timing information, or the timing information is not needed for random access.
1> reset the MAC entity of this cell group;
1> consider the SCell(s) of this cell group, if configured, to be in deactivated state;
1> apply the value of the newUE-Identity as the C-RNTI for this cell group;
1> configure lower layers in accordance with the received spCellConfigCommon;
1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received reconfigurationWithSync.
7.1.1.9.1.3 Test description
7.1.1.9.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0.
Table 7.1.1.9.1.3.1-1: Void
7.1.1.9.1.3.2 Test procedure sequence
Table 7.1.1.9.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0 |
The SS stops the default downlink retransmission. (Note 4) SS ignores scheduling requests and does not allocate any uplink grant until after step 3 |
– |
– |
– |
– |
1 |
The SS transmits a MAC PDU containing one RLC SDU with P field set 0 on DRB |
<– |
MAC PDU (1 RLC SDU of 40 bytes on DRB) |
– |
– |
2 |
Void |
– |
– |
– |
– |
3 |
The SS transmits NR RRCReconfiguration message with reconfigurationWithSync with the same SpCell. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
– |
EXCEPTION: Steps 4 and 4a can happen in any order |
– |
– |
– |
– |
4 |
The UE transmits an NR RRCReconfigurationComplete message. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
4a-5 |
Void |
– |
– |
– |
– |
5A |
The SS ignores scheduling requests and does not allocate any uplink grant. |
||||
6 |
The SS transmits a MAC PDU containing RLC SDU with P field set 0 on DRB. The HARQ Process and NDI on PDCCH is same as in step 1. The SS shall ensure that the HARQ process used at step 1 will not be used in between steps 3 and 5. |
<– |
MAC PDU (1 RLC SDU of 40 bytes on DRB) |
– |
– |
7 |
Check: Does the UE transmit a scheduling request? |
–> |
(SR) |
2 |
P |
– |
Exception: The SS ignores following scheduling requests before step 9. |
– |
– |
– |
– |
8 |
The SS allocates 1 UL Grant with size 384 bits and NDI indicates new transmission. (Note 5) |
<– |
Uplink Grant |
– |
– |
9 |
The UE transmits a MAC PDU including one RLC SDU with P field set 1. |
–> |
MAC PDU |
– |
– |
9A |
The SS transmits a STATUS PDU on a different HARQ process than used in step 6. |
<– |
STATUS PDU |
– |
– |
10-16 |
Void |
– |
– |
– |
– |
16A |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
17 |
The SS transmits a MAC PDU containing RLC SDU with P field set 0 on DRB. |
<– |
MAC PDU (1 RLC SDU of 40 bytes on DRB) |
– |
– |
18 |
The UE transmits a scheduling request |
–> |
(SR) |
– |
– |
Exception: The SS ignores following scheduling requests before step 20. |
– |
– |
– |
– |
|
19 |
The SS allocates an UL Grant with size 384 bits for one HARQ process X, and NDI indicates new transmission. (Note 5) |
<– |
Uplink Grant |
– |
– |
20 |
The UE transmit a MAC PDU including one RLC SDU with P field set 1. |
–> |
MAC PDU |
– |
– |
20A |
The SS transmits a STATUS PDU on a different HARQ process than used in step 17. |
<– |
STATUS PDU |
– |
– |
21 |
Void |
||||
22 |
The SS transmits NR RRCReconfiguration message with reconfigurationWithSync with the same SpCelll. Note 1 |
<– |
RRCReconfiguration |
– |
– |
23 |
The UE transmits an NR RRCReconfigurationComplete message. Note 2 |
RRCReconfigurationComplete |
– |
– |
|
24 |
Void |
||||
24A |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
25 |
The SS transmits a MAC PDU containing RLC SDU with P field set 0 on DRB. The HARQ Process and NDI on PDCCH is same as in step 17. The SS shall ensure that the HARQ process used at step 17 will not be used in between steps 22 and 23. |
<– |
MAC PDU (1 RLC SDU of 40 bytes on DRB) |
– |
– |
26 |
The UE transmits a scheduling request |
–> |
(SR) |
– |
– |
Exception: The SS ignores following scheduling requests before step 28. |
– |
– |
– |
– |
|
27 |
The SS allocates an UL Grant with with size 384 bits corresponding to HARQ process X, with NDI not toggled compared to step 19, and NDI indicates new transmission. (Note 5) |
<– |
Uplink Grant |
– |
– |
28 |
Check: Does UE transmit a MAC PDU including one RLC SDU of 40 bytes on DRB and P field is set 1? |
–> |
MAC PDU |
4,5 |
P |
29 |
The SS transmits a STATUS PDU on a different HARQ process than used in step 25 |
<– |
STATUS PDU |
– |
– |
Note 1: for EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration. Note 2: for EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: RLC re-establishment on DRB is used to make sure UE discard RLC PDU. Note 4: The SS stops the default downlink retransmission to avoid HARQ ACK for the retransmission of DRB data at step 1. Note 5: The UL grant of 384 bits (LRBs & IMCS as per 38.523-3[3] annex B) is chosen to allow the UE to transmit one PDU at a time (40 bytes RLC SDU + 3 bytes RLC Header + 2 bytes MAC Sub PDU header + 2 bytes for short BSR or padding). |
7.1.1.9.1.3.3 Specific message contents
Table 7.1.1.9.1.3.3-0: SchedulingRequest-Config (Preamble)
Derivation Path: 38.508-1 [4], Table 4.6.3-155 |
|||
Information Element |
Value/remark |
Comment |
Condition |
sr-TransMax |
n64 |
Table 7.1.1.9.1.3.3-1: RRCReconfiguration for NR (steps 3 and 22 of Table 7.1.1.9.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.1-13 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
rrcReconfiguration ::= SEQUENCE { |
|||
radioBearerConfig |
RadioBearerConfig according to TS 38.508-1 [4], table 4.6.3-132 with with condition DRBn |
n set to the default DRB of the first PDU session |
NR |
nonCriticalExtension SEQUENCE { |
|||
masterCellGroup |
CellGroupConfig according to TS 38.508-1 [4], table 4.6.3-19 with condition PCell_change |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.9.1.3.3-2: RRCConnectionReconfiguration for EN-DC (step 3 and 22 of Table 7.1.1.9.1.3.2-1)
Derivation Path: 36.508 Table 4.6.1-8 |
||||||
Information Element |
Value/remark |
Comment |
Condition |
|||
RRCConnectionReconfiguration ::= SEQUENCE { |
||||||
criticalExtensions CHOICE { |
||||||
c1 CHOICE{ |
||||||
rrcConnectionReconfiguration-r8 ::= SEQUENCE { |
||||||
nonCriticalExtension ::= SEQUENCE { |
||||||
nonCriticalExtension ::= SEQUENCE { |
||||||
nonCriticalExtension ::= SEQUENCE { |
||||||
nr-Config-r15 CHOICE { |
||||||
nr-SecondaryCellGroupConfig-r15 |
OCTET STRING including the RRCReconfiguration message and the IE secondaryCellGroup according TS 38.508-1 [67], table 4.6.1-13 with condition EN-DC_HO |
|||||
} |
||||||
} |
||||||
nr-RadioBearerConfig1-r15 |
OCTET STRING including RadioBearerConfig according TS 38.508-1 [67], table 4.6.3-132 with conditions EN-DC_DRB |
|||||
} |
||||||
} |
||||||
} |
||||||
} |
||||||
} |
||||||
} |
7.1.1.10 Other Procedures
7.1.1.10.1 DataInactivityTimer expiry
7.1.1.10.1.1 Test Purpose (TP)
(1)
with { UE in NR RRC_CONNECTED state and dataInactivityTimer configured and running }
ensure that {
when { UE receives or transmits MAC SDU from DRB }
then { UE restarts the dataInactivityTimer }
}
(2)
with { UE in NR RRC_CONNECTED state and dataInactivityTimer configured and running }
ensure that {
when { UE detecting data inactivity on expiry of DataInactivityTimer }
then { UE enters RRC_IDLE state }
}
7.1.1.10.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321 clause 5.19 and TS 38.331 clause 5.3.8.5.
[TS 38.321, clause 5.19]
The UE may be configured by RRC with a Data inactivity monitoring functionality, when in RRC_CONNECTED. RRC controls Data inactivity operation by configuring the timer dataInactivityTimer.
When dataInactivityTimer is configured, the UE shall:
1> if any MAC entity receives a MAC SDU for DTCH logical channel, DCCH logical channel, or CCCH logical channel; or
1> if any MAC entity transmits a MAC SDU for DTCH logical channel, or DCCH logical channel:
2> start or restart dataInactivityTimer.
1> if the dataInactivityTimer expires:
2> indicate the expiry of the dataInactivityTimer to upper layers.
[TS 38.331 clause 5.3.8.5]
Upon receiving the expiry of DataInactivityTimer from lower layers while in RRC_CONNECTED, the UE shall:
1> perform the actions upon going to RRC_IDLE as specified in 5.3.11, with release cause ‘RRC connection failure’.
7.1.1.10.1.3 Test description
7.1.1.10.1.3.1 Pre-test conditions
System Simulator:
– NR Cell 1.
UE:
– None.
Preamble:
– The UE is in state 3N-A and Test Mode Activated according to 38.508-1 [4] Table 4.4A.2-1 with UE test loop mode B is established IP PDU delay set to 6 seconds.
7.1.1.10.1.3.2 Test procedure sequence
Table 7.1.1.10.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS waits (dataInactivityTimer/2 + 1) seconds |
– |
– |
– |
– |
2 |
SS transmits a downlink assignment including the C-RNTI assigned to the UE |
<– |
(PDCCH (C-RNTI)) |
– |
– |
3 |
SS transmits in the indicated downlink assignment a RLC PDU in a MAC PDU. |
<– |
MAC PDU |
– |
– |
4 |
Void |
– |
– |
– |
– |
5 |
Void |
– |
– |
– |
– |
6 |
Check: Does the UE transmits a MAC PDU containing Loop backed PDU on expiry of IP PDU delay? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
7-11 |
Repeat steps 1-5 |
– |
– |
– |
– |
12 |
Check: Does the UE transmits a MAC PDU containing Loop backed PDU? |
–> |
MAC PDU (containing 1 MAC sub PDU containing RLC SDU) |
1 |
P |
13 |
SS waits dataInactivityTimer seconds for the UE to enter RRC_IDLE. |
– |
– |
– |
|
14 |
Check: Does the test result of generic test procedure in TS 38.508-1 [4] Table 4.9.5.2.2-1 indicate that the UE is in RRC_IDLE? |
– |
– |
2 |
– |
7.1.1.10.1.3.3 Specific Message Contents
Table 7.1.1.10.1.3.3-1: MAC-CellGroupConfig (preamble)
Derivation path: 38.508-1[4], table 4.6.3-68 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
MAC-CellGroupConfig ::= SEQUENCE { |
|||
dataInactivityTimer |
s10 |
||
} |
Table 7.1.1.10.1.3.3-2: CLOSE UE TEST LOOP (Preamble)
Derivation path: 36.508-1 [7] table 4.7A-3 condition UE test loop mode B |
||||
Information Element |
Value/Remark |
Comment |
Condition |
|
UE test loop mode B LB setup |
||||
IP PDU delay |
‘0000 0110’B |
6 seconds |
7.1.1.10.2 Recommended Bit Rate
7.1.1.10.2.1 Test Purpose (TP)
(1)
with { UE in RRC Connected state and MMTEL call established}
ensure that {
when { IF upper Layers requested to query the gNB for the recommended bit rate for a logical channel and for a direction and bitRateQueryProhibitTimer is not running }
then { UE transmits a Recommended Bit Rate Query MAC Control Element}
}
(2)
with(UE in RRC Connected state and MMTEL call established)
ensure that {
when{ IF upper Layers requested to query the gNB for the recommended bit rate for a logical channel and for a direction and bitRateQueryProhibitTimer is running}
then { UE does not transmits a Recommended Bit Rate Query MAC Control Element}
}
(3)
with ( UE in RRC Connected state and MMTEL call established)
ensure that {
when{ UE receives MAC PDU from the gNB for the recommended bit rate for a logical channel and for a direction }
then { UE sends an HARQ ACK }
}
7.1.1.10.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clauses 5.18.10 and 6.1.20. Unless otherwise stated these are Rel-15 requirements.
[TS 38.321, clause 5.18.10]
The recommended bit rate procedure is used to provide the MAC entity with information about the bit rate which the gNB recommends. The bit rate is the recommended bit rate of the physical layer. Averaging window of default value 2000 ms will apply as specified in TS 26.114 [13].
The gNB may transmit the Recommended bit rate MAC CE to the MAC entity to indicate the recommended bit rate for the UE for a specific logical channel and a specific direction (either uplink or downlink). Upon reception of a Recommended bit rate MAC CE the MAC entity shall:
– indicate to upper layers the recommended bit rate for the indicated logical channel and direction.
The MAC entity may request the gNB to indicate the recommended bit rate for a specific logical channel and a specific direction. If the MAC entity is requested by upper layers to query the gNB for the recommended bit rate for a logical channel and for a direction (i.e. for uplink or downlink), the MAC entity shall:
1> if a Recommended bit rate query for this logical channel and this direction has not been triggered:
2> trigger a Recommended bit rate query for this logical channel, direction, and desired bit rate.
If the MAC entity has UL resources allocated for new transmission the MAC entity shall:
1> for each Recommended bit rate query that the Recommended Bit Rate procedure determines has been triggered and not cancelled:
2> if bitRateQueryProhibitTimer for the logical channel and the direction of this Recommended bit rate query is configured, and it is not running; and
2> if the MAC entity has UL resources allocated for new transmission and the allocated UL resources can accommodate a Recommended bit rate MAC CE plus its subheader as a result of LCP as defined in clause 5.4.3.1:
3> instruct the Multiplexing and Assembly procedure to generate the Recommended bit rate MAC CE for the logical channel and the direction of this Recommended bit rate query;
3> start the bitRateQueryProhibitTimer for the logical channel and the direction of this Recommended bit rate query;
3> cancel this Recommended bit rate query.
[TS 38.321, clause 6.1.20]
The Recommended bit rate MAC CE is identified by a MAC subheader with LCID as specified in Tables 6.2.1-1 and 6.2.1-2 for bit rate recommendation message from the gNB to the UE and bit rate recommendation query message from the UE to the gNB, respectively. It has a fixed size and consists of two octets defined as follows (Figure 6.1.3.20-1):
– LCID: This field indicates the identity of the logical channel for which the recommended bit rate or the recommended bit rate query is applicable. The length of the field is 6 bits;
– Uplink/Downlink (UL/DL): This field indicates whether the recommended bit rate or the recommended bit rate query applies to uplink or downlink. The length of the field is 1 bit. The UL/DL field set to 0 indicates downlink. The UL/DL field set to 1 indicates uplink;
– Bit Rate: This field indicates an index to Table 6.1.3.20-1. The length of the field is 6 bits. For bit rate recommendation the value indicates the recommended bit rate. For bit rate recommendation query the value indicates the desired bit rate;
– R: reserved bit, set to 0.
Figure 6.1.3.20-1: Recommended bit rate MAC CE
Table 6.1.3.20-1: Values (kbit/s) for Bit Rate field
Index |
NR Recommended Bit Rate value [kbit/s] |
Index |
NR Recommended Bit Rate value [kbit/s] |
0 |
Note 1 |
32 |
700 |
1 |
0 |
33 |
800 |
2 |
9 |
34 |
900 |
3 |
11 |
35 |
1000 |
4 |
13 |
36 |
1100 |
5 |
17 |
37 |
1200 |
6 |
21 |
38 |
1300 |
7 |
25 |
39 |
1400 |
8 |
29 |
40 |
1500 |
9 |
32 |
41 |
1750 |
10 |
36 |
42 |
2000 |
11 |
40 |
43 |
2250 |
12 |
48 |
44 |
2500 |
13 |
56 |
45 |
2750 |
14 |
72 |
46 |
3000 |
15 |
88 |
47 |
3500 |
16 |
104 |
48 |
4000 |
17 |
120 |
49 |
4500 |
18 |
140 |
50 |
5000 |
19 |
160 |
51 |
5500 |
20 |
180 |
52 |
6000 |
21 |
200 |
53 |
6500 |
22 |
220 |
54 |
7000 |
23 |
240 |
55 |
7500 |
24 |
260 |
56 |
8000 |
25 |
280 |
57 |
Reserved |
26 |
300 |
58 |
Reserved |
27 |
350 |
59 |
Reserved |
28 |
400 |
60 |
Reserved |
29 |
450 |
61 |
Reserved |
30 |
500 |
62 |
Reserved |
31 |
600 |
63 |
Reserved |
Note 1: For bit rate recommendation message this index is used for indicating that no new recommendation on bit rate is given. |
7.1.1.10.2.3 Test description
7.1.1.10.2.3.1 Pre-test conditions
System Simulator:
– NR Cell 1
– System information combination NR-1 as defined in TS 38.508-1 [4] clause 4.4.3.1.3 is used in NR cell.
UE:
– None.
Preamble:
– The UE is in 5GS state 1N-A according to TS 38.508-1 [4], clause 4.4A.2 Table 4.4A.2-1.
7.1.1.10.2.3.2 Test procedure sequence
Table 7.1.1.10.2.3.2-2: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The procedure in table 4.9.15.2.2-1 in TS 38.508-1 [4] is performed. The bitRateQueryProhibitTimer for the Logical channel of MMTEL QoS Flow is configured as s3 (3 seconds). |
– |
– |
– |
– |
2 |
Trigger the UE to perform Recommended Bit Rate query for direction Downlink via AT (+CGBRRREQ) or MMI command. |
– |
– |
– |
– |
3 |
Check: Does the UE transmit a MAC PDU containing Recommended bit rate MAC CE with Uplink/Downlink (UL/DL) set as 0? |
-> |
MAC PDU |
1 |
P |
4 |
Trigger the UE to perform Recommended Bit Rate query for direction Uplink via AT (+CGBRRREQ) or MMI command. |
– |
– |
– |
– |
5 |
Check: Does the UE transmit a MAC PDU containing Recommended bit rate MAC CE with Uplink/Downlink (UL/DL) set as 1? |
-> |
MAC PDU |
1 |
P |
6 |
SS transmits a MAC PDU containing Recommended bit rate MAC CE with Uplink/Downlink (UL/DL) set as 0 and Bit Rate same as value received in step 5. |
<- |
MAC PDU |
– |
– |
7 |
Trigger the UE to perform Recommended Bit Rate query for direction Up Link via AT (+CGBRRREQ) or MMI command. |
– |
– |
– |
– |
8 |
Check: Does the UE transmit a MAC PDU containing Recommended bit rate MAC CE ? |
-> |
MAC PDU |
2 |
P |
9 |
While bitRateQueryProhibitTimer is running (3 seconds) in UE, trigger the UE to perform Recommended Bit Rate query for direction Up Link via AT (+CGBRRREQ) or MMI command. |
– |
– |
– |
– |
10 |
Check: While bitRateQueryProhibitTimer is running, does the UE transmit a MAC PDU containing Recommended bit rate MAC CE ? |
-> |
MAC PDU |
2 |
F |
11 |
Check: After bitRateQueryProhibitTimer expires, does the UE transmit a MAC PDU containing Recommended bit rate MAC CE with Uplink/Downlink (UL/DL) set as 1? |
-> |
MAC PDU |
2 |
P |
12 |
SS transmits a MAC PDU containing Recommended bit rate MAC CE with Uplink/Downlink (UL/DL) set as 1 and Bit Rate same as value received in step 11. |
<- |
MAC PDU |
– |
– |
13 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 12? |
–> |
HARQ ACK |
3 |
P |
Note: The bitRateQueryProhibitTimer is configured only for UL direction as per asn.1 definition. |
7.1.1.10.2.3.3 Specific message contents
None
7.1.1.11 NR Dual Connectivity
7.1.1.11.1 DC power headroom reporting / PSCell activation and DL pathloss change reporting
7.1.1.11.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state on Pcell and PSCell is added }
ensure that {
when { phr is configured }
then { UE transmits a Power Headroom Report for the PCell and PSCell }
}
(2)
with { UE in RRC_CONNECTED state with PSCell and with Power headroom reporting for phr-Tx-PowerFactorChange }
ensure that {
when { the DL Pathloss has changed more than phr-Tx-PowerFactorChange dB and phr-ProhibitTimer is running }
then { UE does not transmit a MAC PDU containing Power Headroom MAC Control Element }
}
(3)
with { UE in RRC_CONNECTED state with PSCell and with Power headroom reporting for phr-Tx-PowerFactorChange }
ensure that {
when { the phr-ProhibitTimer expires and power headroom report is triggered due to DL Pathloss change }
then { UE transmits a MAC PDU containing Power Headroom MAC Control Element for the Pcell and PSCell }
}
7.1.1.11.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 38.321 clause 5.4.6
[TS 38.321, clause 5.4.6]
A Power Headroom Report (PHR) shall be triggered if any of the following events occur:
– phr-ProhibitTimer expires or has expired and the path loss has changed more than phr-Tx-PowerFactorChange dB for at least one activated Serving Cell of any MAC entity which is used as a pathloss reference since the last transmission of a PHR in this MAC entity when the MAC entity has UL resources for new transmission;
NOTE 1: The path loss variation for one cell assessed above is between the pathloss measured at present time on the current pathloss reference and the pathloss measured at the transmission time of the last transmission of PHR on the pathloss reference in use at that time, irrespective of whether the pathloss reference has changed in between.
– phr-PeriodicTimer expires;
– upon configuration or reconfiguration of the power headroom reporting functionality by upper layers, which is not used to disable the function;
– activation of an SCell of any MAC entity with configured uplink;
– addition of the PSCell (i.e. PSCell is newly added or changed);
– phr-ProhibitTimer expires or has expired, when the MAC entity has UL resources for new transmission, and the following is true for any of the activated Serving Cells of any MAC entity with configured uplink:
– there are UL resources allocated for transmission or there is a PUCCH transmission on this cell, and the required power backoff due to power management (as allowed by P-MPRc as specified in TS 38.101-1 [14], TS 38.101-2 [15], and TS 38.101-3 [16]) for this cell has changed more than phr-Tx-PowerFactorChange dB since the last transmission of a PHR when the MAC entity had UL resources allocated for transmission or PUCCH transmission on this cell.
NOTE 2: The MAC entity should avoid triggering a PHR when the required power backoff due to power management decreases only temporarily (e.g. for up to a few tens of milliseconds) and it should avoid reflecting such temporary decrease in the values of PCMAX,f,c/PH when a PHR is triggered by other triggering conditions.
If the MAC entity has UL resources allocated for a new transmission the MAC entity shall:
1> if it is the first UL resource allocated for a new transmission since the last MAC reset:
2> start phr-PeriodicTimer;
1> if the Power Headroom reporting procedure determines that at least one PHR has been triggered and not cancelled; and
1> if the allocated UL resources can accommodate the MAC CE for PHR which the MAC entity is configured to transmit, plus its subheader, as a result of LCP as defined in clause 5.4.3.1:
2> if multiplePHR with value true is configured:
3> for each activated Serving Cell with configured uplink associated with any MAC entity:
4> obtain the value of the Type 1 or Type 3 power headroom for the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 [6] for NR Serving Cell and clause 5.1.1.2 of TS 36.213 [17] for E-UTRA Serving Cell;
4> if this MAC entity has UL resources allocated for transmission on this Serving Cell; or
4> if the other MAC entity, if configured, has UL resources allocated for transmission on this Serving Cell and phr-ModeOtherCG is set to real by upper layers:
5> obtain the value for the corresponding PCMAX,f,c field from the physical layer.
3> if phr-Type2OtherCell with value true is configured:
4> if the other MAC entity is E-UTRA MAC entity:
5> obtain the value of the Type 2 power headroom for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity);
5> if phr-ModeOtherCG is set to real by upper layers:
6> obtain the value for the corresponding PCMAX,f,c field for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity) from the physical layer.
3> instruct the Multiplexing and Assembly procedure to generate and transmit the Multiple Entry PHR MAC CE as defined in clause 6.1.3.9 based on the values reported by the physical layer.
2> else (i.e. Single Entry PHR format is used):
3> obtain the value of the Type 1 power headroom from the physical layer for the corresponding uplink carrier of the PCell;
3> obtain the value for the corresponding PCMAX,f,c field from the physical layer;
3> instruct the Multiplexing and Assembly procedure to generate and transmit the Single Entry PHR MAC CE as defined in clause 6.1.3.8 based on the values reported by the physical layer.
2> start or restart phr-PeriodicTimer;
2> start or restart phr-ProhibitTimer;
2> cancel all triggered PHR(s).
7.1.1.11.1.3 Test description
7.1.1.11.1.3.1 Pre-test conditions
System Simulator:
– NR Cell 1 is the PCell and NR Cell 10 is the PSCell.
– System information combination NR-4 as defined in TS 38.508-1 [4] clause 4.4.3.1.3 is used in all cells.
UE:
– None.
Preamble:
– The UE is in state NR RRC_CONNECTED using generic procedure parameter Connectivity (NR-DC), Test Mode (On) associated with UE test loop mode A configured on NR Cell 1 according to TS 38.508-1 [4], clause 4.5.4.
7.1.1.11.1.3.2 Test procedure sequence
Table 7.1.1.11.1.3.2-0: Cell configuration power level changes over time for Conducted test environment
Parameter |
Unit |
NR Cell 1 |
NR Cell 10 |
Remarks |
|
T0 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
|
T1 |
Cell-specific RS EPRE |
dBm/SCS |
-89 |
-82 |
|
T2 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
|
T3 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-89 |
|
T4 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
Table 7.1.1.11.1.3.2-0A: Cell configuration power level changes over time for OTA test environment
Parameter |
Unit |
NR Cell 1 |
NR Cell 10 |
Remarks |
|
T0 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
|
T1 |
Cell-specific RS EPRE |
dBm/SCS |
n/a |
n/a |
|
T2 |
Cell-specific RS EPRE |
dBm/SCS |
n/a |
n/a |
|
T3 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-91 |
|
T4 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
Table 7.1.1.11.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits UL grant on PCell and PSCell to the UE at every 10ms in PDCCH occasion. |
<– |
– |
– |
– |
2 |
SS transmits NR RRCReconfiguration message to configure to specific Power Headroom parameters for NR Cell |
<– |
RRCReconfiguration |
– |
– |
3 |
Check: Does the UE transmit a MAC PDU containing Multiple-Entry PHR MAC CE on PCell? (Note 1) |
–> |
MAC PDU |
1 |
P |
3A |
Check: Does the UE transmit a MAC PDU containing Multiple-Entry PHR MAC CE on PSCell? (Note 1) |
–> |
MAC PDU |
1 |
P |
4 |
The UE transmits an NR RRCReconfigurationComplete message including nr-SCG-Response (Note 1) |
–> |
RRCReconfigurationComplete |
– |
– |
5 |
Void |
– |
– |
– |
– |
– |
EXCEPTION : Steps 6 to 12 shall be executed depending on PSCell Configuration. (Note 3) |
– |
– |
– |
– |
6 |
IF PSCell is configured as FR1 THEN Reduce SS power level for NR PCell so as to cause a DL_Pathloss change at UE by 5dB, row T1 of Table 7.1.1.11.1.3.2-0. |
– |
– |
– |
– |
7 |
Check: For 80% of prohibitPHR-Timer since step 3, does the UE transmit a MAC PDU containing Multiple-Entry PHR MAC CE on PCell? |
–> |
MAC PDU |
2 |
F |
8 |
Check: After prohibitPHR-Timer after step 3, does the UE transmit a MAC PDU containing Multiple-Entry PHR MAC CE on PCell? |
–> |
MAC PDU |
3 |
P |
9 |
Increase SS power level for NR PCell so as to cause a DL_Pathloss change at UE by 5dB, row T2 of Table 7.1.1.11.1.3.2-0/0A. |
– |
– |
– |
– |
10 |
Check: For 80% of prohibitPHR-Timer since step 8, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element on PCell? |
–> |
MAC PDU |
2 |
F |
11 |
Check: After prohibitPHR-Timer after step 8, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element on PCell? |
–> |
MAC PDU |
3 |
P |
12 |
Void |
– |
– |
– |
– |
13 |
Reduce SS power level for NR PSCell so as to cause a DL_Pathloss change at UE by 5dB, row T3 of Table 7.1.1.11.1.3.2-0/0A. |
– |
– |
– |
– |
14 |
IF PSCell is configured as FR2 THEN Check: For 80% of prohibitPHR-Timer since step 3A, does the UE transmit a MAC PDU containing Multiple-Entry PHR MAC CE? |
–> |
MAC PDU |
2 |
F |
15 |
Check: Does the UE transmit a MAC PDU containing Multiple-Entry PHR MAC CE on PSCell? |
–> |
MAC PDU |
3 |
P |
16 |
Increase SS power level for NR PSCell so as to cause a DL_Pathloss change at UE by 5dB, row T4 of Table 7.1.1.11.1.3.2-0/0A. |
– |
– |
– |
– |
17 |
Check: For 80% of prohibitPHR-Timer since step 15, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element on PSCell? |
–> |
MAC PDU |
2 |
F |
18 |
Check: After prohibitPHR-Timer after step 15, does the UE transmit a MAC PDU containing Power Headroom MAC Control Element on PSCell? |
–> |
MAC PDU |
3 |
P |
19 |
The SS transmits an NR RRCReconfiguration message to disable Power Headroom reporting |
<– |
RRCReconfiguration |
– |
– |
20 |
The UE transmits an NR RRCReconfigurationComplete message to confirm the disabling of Power Headroom parameters |
–> |
RRCReconfigurationComplete |
– |
– |
Note 1: Steps 3 and 4 can happen in any order. Note 2: Void. Note 3: Steps 6 to 12 are excluded when executed with FR1+FR2 band combination due to limitation in FR1 OTA requirements specified in 38.508-1 [4] clause 6.2.2.2.3. phr-Tx-PowerFactorChange for PCell is not tested due to this limitation |
7.1.1.11.1.3.3 Specific Message Contents
Table 7.1.1.11.1.3.3-1: RRCReconfiguration (step 2, Table 7.1.1.11.1.3.2-1)
Derivation Path: TS 38.331 [6], clause 6.2.2 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
rrc-TransactionIdentifier |
RRC-TransactionIdentifier |
|||
criticalExtensions CHOICE { |
||||
rrcReconfiguration SEQUENCE { |
||||
radioBearerConfig |
Not present |
|||
nonCriticalExtension SEQUENCE { |
||||
masterCellGroup |
CellGroupConfig-phr |
|||
nonCriticalExtension SEQUENCE { |
||||
mrdc-SecondaryCellGroupConfig CHOICE { |
||||
setup SEQUENCE { |
||||
mrdc-ReleaseAndAdd |
Not present |
|||
mrdc-SecondaryCellGroup CHOICE { |
||||
nr-SCG |
RRCReconfiguration-SCG-phr |
OCTET STRING (CONTAINING RRCReconfiguration) |
||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.11.1.3.3-1A: RRCReconfiguration-SCG-phr (step 2, Table 7.1.1.11.1.3.2-1)
Derivation Path: TS 38.331 [6], clause 6.2.2 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
rrc-TransactionIdentifier |
RRC-TransactionIdentifier |
|||
criticalExtensions CHOICE { |
||||
rrcReconfiguration SEQUENCE { |
||||
radioBearerConfig |
Not present |
|||
secondaryCellGroup |
CellGroupConfig-phr |
|||
} |
||||
} |
||||
} |
Table 7.1.1.11.1.3.3-2: CellGroupConfig-phr (step 2, Table 7.1.1.11.1.3.2-1)
Derivation Path: 38.508-1 [4], Table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
cellGroupConfig::= SEQUENCE { |
|||
mac-CellGroupConfig SEQUENCE { |
|||
phr-Config CHOICE { |
|||
setup SEQUENCE { |
|||
phr-PeriodicTimer |
infinity |
||
phr-ProhibitTimer |
sf500 |
||
phr-Tx-PowerFactorChange |
dB3 |
||
multiplePHR |
true |
||
dummy |
false |
||
phr-Type2OtherCell |
false |
||
phr-ModeOtherCG |
real |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.12 UE power saving
7.1.1.12.1 Void
7.1.1.12.2 Void
7.1.1.12.3 DRX adaptation / UE wakeup indication
7.1.1.12.3.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state and long DRX is configured and [(SFN * 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset and DCP is configured }
ensure that {
when { a DCP indication with the value of wake-up indication 1 associated with the current DRX cycle has been received }
then { UE starts the drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe and monitors the PDCCH }
}
(2)
with { UE in RRC_CONNECTED state and long DRX is configured and [(SFN * 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset and DCP is configured and ps-wakeup is configured with value true }
ensure that {
when { DCP indication associated with this cycle has not been received }
then { UE starts the drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe and monitors the PDCCH for OnDurationTimer PDCCH-Occasions }
}
(3)
with { UE in RRC_CONNECTED state long DRX is configured and [(SFN * 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset and DCP is configured }
ensure that {
when { all DCP occasions in time domain occurred in DRX active time }
then { UE starts the drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe and monitors the PDCCH }
}
(4)
with { UE in RRC_CONNECTED state long DRX is configured and DCP is configured }
ensure that {
when { all DCP occasions in time domain occurred during measurement gap }
then { UE starts the drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe and monitors the PDCCH }
}
(5)
with { UE in RRC_CONNECTED state and long DRX is configured and [(SFN * 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset and DCP is configured }
ensure that {
when { a DCP indication with the value of wake-up indication 0 associated with the current DRX cycle has been received }
then { UE does not start the drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe and skips monitoring the PDCCH }
}
7.1.1.12.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.321, clause 5.7, TS 38.213, clause 10.3 and 7.3.1.3.7. Unless otherwise stated these are Rel-16 requirements.
[TS 38.321, clause 5.7]
The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, CI-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, TPC-SRS-RNTI, and AI-RNTI. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. When in RRC_CONNECTED, if DRX is configured, for all the activated Serving Cells, the MAC entity may monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity shall monitor the PDCCH as specified in TS 38.213 [6].
NOTE 1: If Sidelink resource allocation mode 1 is configured by RRC, a DRX functionality is not configured.
RRC controls DRX operation by configuring the following parameters:
– drx-onDurationTimer: the duration at the beginning of a DRX Cycle;
– drx-SlotOffset: the delay before starting the drx-onDurationTimer;
– drx-InactivityTimer: the duration after the PDCCH occasion in which a PDCCH indicates a new UL or DL transmission for the MAC entity;
– drx-RetransmissionTimerDL (per DL HARQ process except for the broadcast process): the maximum duration until a DL retransmission is received;
– drx-RetransmissionTimerUL (per UL HARQ process): the maximum duration until a grant for UL retransmission is received;
– drx-LongCycleStartOffset: the Long DRX cycle and drx-StartOffset which defines the subframe where the Long and Short DRX Cycle starts;
– drx-ShortCycle (optional): the Short DRX cycle;
– drx-ShortCycleTimer (optional): the duration the UE shall follow the Short DRX cycle;
– drx-HARQ-RTT-TimerDL (per DL HARQ process except for the broadcast process): the minimum duration before a DL assignment for HARQ retransmission is expected by the MAC entity;
– drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity;
– ps-Wakeup (optional): the configuration to start associated drx-onDurationTimer in case DCP is monitored but not detected;
– ps-TransmitOtherPeriodicCSI (optional): the configuration to report periodic CSI that is not L1-RSRP on PUCCH during the time duration indicated by drx-onDurationTimer in case DCP is configured but associated drx-onDurationTimer is not started;
– ps-TransmitPeriodicL1-RSRP (optional): the configuration to transmit periodic CSI that is L1-RSRP on PUCCH during the time duration indicated by drx-onDurationTimer in case DCP is configured but associated drx-onDurationTimer is not started.
Serving Cells may be configured by RRC in two groups. When RRC does not configure a secondary DRX group, there is only one DRX group. When two DRX groups are configured each group of Serving Cells, which is called a DRX group, is configured by RRC with its own set of parameters: drx-onDurationTimer, drx-InactivityTimer. When two DRX groups are configured, the two groups share the following parameter values: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (optional), drx-ShortCycleTimer (optional), drx-HARQ-RTT-TimerDL, and drx-HARQ-RTT-TimerUL.
When a DRX cycle is configured, the Active Time for Serving Cells in a DRX group includes the time while:
– drx-onDurationTimer or drx-InactivityTimer configured for the DRX group is running; or
– drx-RetransmissionTimerDL or drx-RetransmissionTimerUL is running on any Serving Cell in the DRX group; or
– ra-ContentionResolutionTimer (as described in clause 5.1.5) or msgB-ResponseWindow (as described in clause 5.1.4a) is running; or
– a Scheduling Request is sent on PUCCH and is pending (as described in clause 5.4.4); or
– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the Random Access Preamble not selected by the MAC entity among the contention-based Random Access Preamble (as described in clauses 5.1.4 and 5.1.4a).
When DRX is configured, the MAC entity shall:
1> if the Long DRX Cycle is used, and [(SFN × 10) + subframe number] modulo (drx-LongCycle) = drx-StartOffset:
2> if DCP monitoring is configured for the active DL BWP as specified in TS 38.213 [6], clause 10.3:
3> if DCP indication associated with the current DRX Cycle received from lower layer indicated to start drx-onDurationTimer, as specified in TS 38.213 [6]; or
3> if all DCP occasion(s) in time domain, as specified in TS 38.213 [6], associated with the current DRX Cycle occurred in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to start of the last DCP occasion, or within BWP switching interruption length, or during a measurement gap; or
3> if ps-Wakeup is configured with value true and DCP indication associated with the current DRX Cycle has not been received from lower layers:
4> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
2> else:
3> start drx-onDurationTimer after drx-SlotOffset from the beginning of the subframe.
NOTE 2: In case of unaligned SFN across carriers in a cell group, the SFN of the SpCell is used to calculate the DRX duration.
1> if the DRX group is in Active Time:
2> monitor the PDCCH on the Serving Cells in this DRX group as specified in TS 38.213 [6];
2> if the PDCCH indicates a DL transmission:
3> start the drx-HARQ-RTT-TimerDL for the corresponding HARQ process in the first symbol after the end of the corresponding transmission carrying the DL HARQ feedback;
NOTE 3: When HARQ feedback is postponed by PDSCH-to-HARQ_feedback timing indicating a non-numerical k1 value, as specified in TS 38.213 [6], the corresponding transmission opportunity to send the DL HARQ feedback is indicated in a later PDCCH requesting the HARQ-ACK feedback.
3> stop the drx-RetransmissionTimerDL for the corresponding HARQ process.
3> if the PDSCH-to-HARQ_feedback timing indicate a non-numerical k1 value as specified in TS 38.213 [6]:
4> start the drx-RetransmissionTimerDL in the first symbol after the PDSCH transmission for the corresponding HARQ process.
2> if the PDCCH indicates a UL transmission:
3> start the drx-HARQ-RTT-TimerUL for the corresponding HARQ process in the first symbol after the end of the first repetition of the corresponding PUSCH transmission;
3> stop the drx-RetransmissionTimerUL for the corresponding HARQ process.
2> if the PDCCH indicates a new transmission (DL or UL) on a Serving Cell in this DRX group:
3> start or restart drx-InactivityTimer for this DRX group in the first symbol after the end of the PDCCH reception.
1> if DCP monitoring is configured for the active DL BWP as specified in TS 38.213 [6], clause 10.3; and
1> if the current symbol n occurs within drx-onDurationTimer duration; and
1> if drx-onDurationTimer associated with the current DRX cycle is not started as specified in this clause:
2> if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause:
3> not transmit periodic SRS and semi-persistent SRS defined in TS 38.214 [7];
3> not report semi-persistent CSI configured on PUSCH;
3> if ps-TransmitPeriodicL1-RSRP is not configured with value true:
4> not report periodic CSI that is L1-RSRP on PUCCH.
3> if ps-TransmitOtherPeriodicCSI is not configured with value true:
4> not report periodic CSI that is not L1-RSRP on PUCCH.
1> else:
2> in current symbol n, if the DRX group would not be in Active Time considering grants/assignments scheduled on Serving Cell(s) in this DRX Group and DRX Command MAC CE/Long DRX Command MAC CE received and Scheduling Request sent until 4 ms prior to symbol n when evaluating all DRX Active Time conditions as specified in this clause:
3> not transmit periodic SRS and semi-persistent SRS defined in TS 38.214 [7] in this DRX group;
3> not report CSI on PUCCH and semi-persistent CSI configured on PUSCH in this DRX group.
…
Regardless of whether the MAC entity is monitoring PDCCH or not on the Serving Cells in this DRX group, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS defined in TS 38.214 [7] on the Serving Cells in this DRX group when such is expected.
The MAC entity needs not to monitor the PDCCH if it is not a complete PDCCH occasion (e.g. the Active Time starts or ends in the middle of a PDCCH occasion).
[TS 38.213, clause 10.3]
A UE configured with DRX mode operation [11, TS 38.321] can be provided the following for detection of a DCI format 2_6 in a PDCCH reception on the PCell or on the SpCell [12, TS 38.331]
– a PS-RNTI for DCI format 2_6 by ps-RNTI
– a number of search space sets, by dci-Format2-6, to monitor PDCCH for detection of DCI format 2_6 on the active DL BWP of the PCell or of the SpCell according to a common search space as described in clause 10.1
– a payload size for DCI format 2_6 by sizeDCI-2-6
– a location in DCI format 2_6 of a Wake-up indication bit by ps-PositionDCI-2-6
– a ‘0’ value for the Wake-up indication bit, when reported to higher layers, indicates to not start the drx-onDurationTimer for the next long DRX cycle [11, TS 38.321]
– a ‘1’ value for the Wake-up indication bit, when reported to higher layers, indicates to start the drx-onDurationTimer for the next long DRX cycle [11, TS 38.321]
– a bitmap, when the UE is provided a number of groups of configured SCells by dormancyGroupOutsideActiveTime, where
– the bitmap location is immediately after the Wake-up indication bit location
– the bitmap size is equal to the number of groups of configured SCells where each bit of the bitmap corresponds to a group of configured SCells from the number of groups of configured SCells
– a ‘0’ value for a bit of the bitmap indicates an active DL BWP, provided by dormantBWP-Id, for the UE [11, TS38.321] for each activated SCell in the corresponding group of configured SCells
– a ‘1’ value for a bit of the bitmap indicates
– an active DL BWP, provided by firstOutsideActiveTimeBWP-Id, for the UE for each activated SCell in the corresponding group of configured SCells, if a current active DL BWP is the dormant DL BWP
– a current active DL BWP, for the UE for each activated SCell in the corresponding group of configured SCells, if the current active DL BWP is not the dormant DL BWP
– the UE sets the active DL BWP to the indicated active DL BWP
– an offset by ps-Offset indicating a time, where the UE starts monitoring PDCCH for detection of DCI format 2_6 according to the number of search space sets, prior to a slot where the drx-onDurationTimer would start on the PCell or on the SpCell [11, TS 38.321]
– for each search space set, the PDCCH monitoring occasions are the ones in the first slots indicated by duration, or slot if duration is not provided, starting from the first slot of the first slots and ending prior to the start of drx-onDurationTimer.
On PDCCH monitoring occasions associated with a same long DRX Cycle, a UE does not expect to detect more than one DCI format 2_6 with different values of the Wake-up indication bit for the UE or with different values of the bitmap for the UE.
The UE does not monitor PDCCH for detecting DCI format 2_6 during Active Time [11, TS 38.321].
If a UE reports for an active DL BWP a MinTimeGap value that is X slots prior to the beginning of a slot where the UE would start the drx-onDurationTimer, the UE is not required to monitor PDCCH for detection of DCI format 2_6 during the X slots, where X corresponds to the MinTimeGap value of the SCS of the active DL BWP in Table 10.3-1.
Table 10.3-1: Minimum time gap value X
SCS (kHz) |
Minimum Time Gap X (slots) |
|
Value 1 |
Value 2 |
|
15 |
1 |
3 |
30 |
1 |
6 |
60 |
1 |
12 |
120 |
2 |
24 |
480 |
8 |
96 |
960 |
16 |
192 |
If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2_6 in the active DL BWP of the PCell or of the SpCell and the UE detects DCI format 2_6, the physical layer of a UE reports the value of the Wake-up indication bit for the UE to higher layers [11, TS 38.321] for the next long DRX cycle.
If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2_6 in the active DL BWP of the PCell or of the SpCell and the UE does not detect DCI format 2_6, the physical layer of the UE does not report a value of the Wake-up indication bit to higher layers for the next long DRX cycle.
If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2_6 in the active DL BWP of the PCell or of the SpCell and the UE
– is not required to monitor PDCCH for detection of DCI format 2_6, as described in clauses 10, 11.1, 12, and in clause 5.7 of [11, TS 38.321] for all corresponding PDCCH monitoring occasions outside Active Time prior to a next long DRX cycle, or
– does not have any PDCCH monitoring occasions for detection of DCI format 2_6 outside Active Time of a next long DRX cycle
the physical layer of the UE reports a value of 1 for the Wake-up indication bit to higher layers for the next long DRX cycle.
[TS 38.212, clause 7.3.1.3.7]
DCI format 2_6 is used for notifying the power saving information outside DRX Active Time for one or more UEs.
The following information is transmitted by means of the DCI format 2_6 with CRC scrambled by PS-RNTI:
– block number 1, block number 2,…, block number N
where the starting position of a block is determined by the parameter PSPositionDCI2-6 provided by higher layers for the UE configured with the block.
If the UE is configured with higher layer parameter PS-RNTI and dci-Format2-6, one block is configured for the UE by higher layers, with the following fields defined for the block:
– Wake-up indication – 1 bit
– SCell dormancy indication – 0 bit if higher layer parameter Scell-groups-for-dormancy-outside-active-time is not configured; otherwise 1, 2, 3, 4 or 5 bits bitmap determined according to higher layer parameter Scell-groups-for-dormancy-outside-active-time, where each bit corresponds to one of the SCell group(s) configured by higher layers parameter Scell-groups-for-dormancy-outside-active-time, with MSB to LSB of the bitmap corresponding to the first to last configured SCell group.
The size of DCI format 2_6 is indicated by the higher layer parameter SizeDCI_2-6, according to Clause 10.3 of [5, TS 38.213].
7.1.1.12.3.3 Test description
7.1.1.12.3.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that set to return no data in uplink.
7.1.1.12.3.3.2 Test procedure sequence
Table 7.1.1.12.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS transmits RRCReconfiguration to configure specific DCP parameters. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
2 |
The UE transmits RRCReconfigurationComplete. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
3 |
Wait 1280ms to ensure UE is out DRX active time. |
– |
– |
– |
– |
3A |
The SS transmits DCI 2-6 on the PDCCH within the PS-offset time before the start of next long DRX drx-onDurationTimer and the DCI 2-6 indicates not to start the next Drx-onDurationTimer. |
<– |
(PDCCH (DCI 2-6)) |
– |
– |
3B |
In a PDCCH occasion the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
3C |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 28? |
–> |
HARQ ACK |
5 |
F |
4 |
The SS transmits DCI 2-6 on the PDCCH within the PS-offset time before the start of next long DRX drx-onDurationTimer and the DCI 2-6 indicates to start the next Drx-onDurationTimer. |
<– |
(PDCCH (DCI 2-6)) |
– |
– |
5 |
In the first PDCCH occasion when the Drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
6 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5? |
–> |
HARQ ACK |
1 |
P |
7 |
SS transmits RRCReconfiguration to configure ps-wakeup with value true. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
8 |
The UE transmits RRCReconfigurationComplete. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
9 |
Wait 20ms to ensure UE is out DRX active time. |
– |
– |
– |
– |
10 |
In the first PDCCH occasion when the Drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
11 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 10? |
–> |
HARQ ACK |
2 |
P |
12 |
SS transmits RRCReconfiguration to configure specific DCP parameters. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
13 |
The UE transmits RRCReconfigurationComplete. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
14 |
Wait 1280ms to ensure UE is out DRX active time. |
– |
– |
– |
– |
15 |
The SS transmits DCI 2-6 on the PDCCH within the PS-offset time before the start of next long DRX drx-onDurationTimer and the DCI 2-6 indicates to start the next Drx-onDurationTimer. |
<– |
(PDCCH (DCI 2-6)) |
– |
– |
16 |
In the last PDCCH occasion when the Drx-onDurationTimer is running, the SS indicates the transmission of an invalid DL MAC PDU on the PDCCH. |
<– |
Invalid MAC PDU |
– |
– |
17 |
The UE transmit a HARQ NACK for the DL MAC PDU in Step 16. |
–> |
HARQ NACK |
– |
– |
17A |
The SS transmits DCI 2-6 on the PDCCH within the PS-offset time before the start of next long DRX drx-onDurationTimer and the DCI 2-6 indicates not to start the next Drx-onDurationTimer. |
<– |
(PDCCH (DCI 2-6)) |
– |
– |
18 |
In the PDCCH occasion when the next Drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
19 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 18? |
–> |
HARQ ACK |
3 |
P |
20 |
SS transmits RRCReconfiguration to configure specific measonfig parameters. (Note 1) |
<– |
RRCReconfiguration |
– |
– |
21 |
The UE transmits RRCReconfigurationComplete. (Note 2) |
–> |
RRCReconfigurationComplete |
– |
– |
22 |
Wait 10ms to ensure UE is out DRX active time. |
– |
– |
– |
– |
22A |
The SS transmits DCI 2-6 on the PDCCH within the PS-offset time before the start of next long DRX drx-onDurationTimer and the DCI 2-6 indicates not to start the next Drx-onDurationTimer. |
<– |
(PDCCH (DCI 2-6)) |
– |
– |
23 |
In the first PDCCH occasion when the Drx-onDurationTimer is running, the SS indicates the transmission of a DL MAC PDU on the PDCCH. |
<– |
MAC PDU |
– |
– |
24 |
Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 23? |
–> |
HARQ ACK |
4 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. |
7.1.1.12.3.3.3 Specific message contents
Table 7.1.1.12.3.3.3-1: RRCReconfiguration (step 1, 7 and 12)
Derivation Path: TS 38.508-1 [6] |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
||
nonCriticalExtension := SEQUENCE {} |
Not present |
EN-DC |
||
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
|||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.12.3.3.3-2: CellGroupConfig (Table 7.1.1.12.3.3.3-1: RRCReconfiguration)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
cellGroupId |
CellGroupId |
TS 38.508-1 default value |
|
mac-CellGroupConfig ::= SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup |
DRX-Config |
TS 38.508-1 default value |
|
} |
|||
} |
|||
physicalCellGroupConfig::= SEQUENCE { |
|||
dcp-Config-r16 CHOICE { |
|||
setup |
DCP-Config-r16 |
TS 38.508-1 default value |
|
} |
|||
} |
|||
spCellConfig SEQUENCE { |
|||
spCellConfigDedicated |
ServingCellConfig |
||
} |
|||
} |
Table 7.1.1.12.3.3.3-3: ServingCellConfig (Table 7.1.1.13.3.3.3-2: CellGroupConfig)
Derivation Path: TS 38.508-1 [4] Table 4.6.3-167 |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
initialDownlinkBWP ::= SEQUENCE { |
|||
pdcch-Config CHOICE { |
Step 1, Step 7, Step 12, Step 20 |
||
setup |
PDCCH-Config |
||
} |
|||
} |
|||
} |
Table 7.1.1.12.3.3.3-4: PDCCH-Config (Table 7.1.1.12.3.3.3-3: BWP-DownlinkDedicated)
Derivation Path: TS 38.508-1 [4],Table 4.6.3-95 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDCCH-Config::= SEQUENCE { |
|||
controlResourceSetToAddModList SEQUENCE(SEQUENCE(SIZE (1..3)) OF ControlResourceSet ::= SEQUENCE { |
|||
controlResourceSetId |
1 |
||
} |
|||
searchSpacesToAddModList SEQUENCE(SIZE (1..10)) OF SearchSpace { |
|||
searchSpace ::= SEQUENCE { |
|||
searchSpaceExt-r16 ::= SEQUENCE { |
|||
controlResourceSetId-r16 |
1 |
||
searchSpaceType-r16 SEQUENCE { |
|||
common SEQUENCE { |
|||
dci-Format2-6-r16 SEQUENCE { |
|||
} |
|||
} |
|||
} |
|||
searchSpaceGroupIdList-r16 |
Not present |
||
freqMonitorLocations-r16 |
Not present |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.12.3.3.3-5: CellGroupConfig (Table 7.1.1.13.3.3.3-1: RRCReconfiguration step 7)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
cellGroupId |
CellGroupId |
TS 38.508-1 default value |
|
mac-CellGroupConfig ::= SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup |
DRX-Config |
TS 38.508-1 default value |
|
} |
|||
} |
|||
physicalCellGroupConfig::= SEQUENCE { |
|||
dcp-Config-r16 CHOICE { |
|||
setup SEQUENCE { |
|||
ps-WakeUp-r16 |
true |
||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.12.3.3.3-6: CellGroupConfig (Table 7.1.1.13.3.3.3-1: RRCReconfiguration step 12)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
cellGroupId |
CellGroupId |
TS 38.508-1 default value |
|
mac-CellGroupConfig ::= SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer CHOICE { |
ms10 |
||
milliSeconds |
ms10 |
||
} |
|||
drx-InactivityTimer |
ms6 |
||
drx-HARQ-RTT-TimerDL |
56 |
||
drx-HARQ-RTT-TimerUL |
56 |
||
drx-RetransmissionTimerDL |
sl320 |
||
drx-RetransmissionTimerUL |
sl320 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms20 |
0 |
||
} |
|||
shortDRX |
Not present |
||
drx-SlotOffset |
ms0 |
||
} |
|||
physicalCellGroupConfig::= SEQUENCE { |
|||
dcp-Config-r16 CHOICE { |
|||
setup SEQUENCE { |
|||
ps-Offset-r16 |
40 |
||
} |
|||
} |
|||
} |
Table 7.1.1.12.3.3.3-7: RRCReconfiguration (step 20)
Derivation Path: TS 38.508-1 [6], Table 4.6.1-13 |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
||
measConfig ::= SEQUENCE { |
||||
measObjectToAddModList SEQUENCE (SIZE (1..maxNrofMeasId)) OF MeasObjectToAddMod { |
2 entries |
|||
MeasObjectToAddMod[1] SEQUENCE { |
entry 1 |
|||
measObjectId |
1 |
|||
measObject CHOICE { |
||||
measObjectNR SEQUENCE { |
||||
ssbFrequency |
ARFCN-ValueNR for SSB of NR Cell 1 |
|||
absThreshSS-BlocksConsolidation |
Not present |
|||
nrofSS-BlocksToAverage |
Not present |
|||
} |
||||
} |
||||
} |
||||
MeasObjectToAddMod[2] SEQUENCE { |
||||
measObjectId |
2 |
|||
measObject CHOICE { |
||||
measObjectNR SEQUENCE { |
||||
ssbFrequency |
ARFCN-ValueNR for SSB of NR Cell 3 |
|||
absThreshSS-BlocksConsolidation |
Not present |
|||
nrofSS-BlocksToAverage |
Not present |
|||
} |
||||
} |
||||
} |
||||
} |
||||
reportConfigToAddModList SEQUENCE(SIZE (1..maxReportConfigId)) OF ReportConfigToAddMod { |
1 entry |
|||
ReportConfigToAddMod[1] SEQUENCE { |
entry 1 |
|||
reportConfigId |
1 |
|||
reportConfig CHOICE { |
||||
reportConfigNR SEQUENCE { |
||||
reportType CHOICE { |
||||
eventTriggered SEQUENCE { |
||||
eventId CHOICE { |
||||
eventA3 SEQUENCE { |
||||
a3-Offset CHOICE { |
||||
rsrp |
2 |
1 dB (2*0.5 dB) |
||
} |
||||
} |
||||
} |
||||
reportAmount |
infinity |
|||
reportQuantityCell SEQUENCE { |
||||
rsrp |
true |
|||
rsrq |
false |
|||
sinr |
false |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
measIdToAddModList SEQUENCE (SIZE (1..maxNrofMeasId)) OF MeasIdToAddMod { |
1 entry |
|||
MeasIdToAddMod[1] SEQUENCE { |
entry 1 |
|||
measId |
1 |
|||
measObjectId |
2 |
|||
reportConfigId |
1 |
|||
} |
||||
} |
||||
measGapConfig ::= SEQUENCE { |
||||
gapUE CHOICE { |
||||
setup SEQUENCE { |
||||
gapOffset |
34 |
|||
mgl |
ms6 |
|||
mgrp |
ms40 |
|||
mgta |
ms0 |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
|||
} |
||||
} |
Table 7.1.1.12.3.3.3-8: CellGroupConfig (Table 7.1.1.12.3.3.3-7: RRCReconfiguration step 20)
Derivation Path: TS 38.331 [6], clause 6.3.2 |
|||
Information Element |
Value/remark |
Comment |
Condition |
CellGroupConfig ::= SEQUENCE { |
|||
cellGroupId |
CellGroupId |
TS 38.508-1 default value |
|
mac-CellGroupConfig ::= SEQUENCE { |
|||
drx-Config CHOICE { |
|||
setup SEQUENCE { |
|||
drx-onDurationTimer CHOICE { |
|||
milliSeconds |
ms10 |
||
} |
|||
drx-InactivityTimer |
ms5 |
||
drx-LongCycleStartOffset CHOICE { |
|||
ms40 |
39 |
||
} |
|||
shortDRX |
Not present |
||
drx-SlotOffset |
ms0 |
||
} |
|||
} |
|||
} |
|||
physicalCellGroupConfig::= SEQUENCE { |
|||
dcp-Config-r16 CHOICE { |
|||
setup SEQUENCE { |
|||
ps-Offset-r16 |
40 |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.12.4 DRX adaptation / SCell dormancy indication
7.1.1.12.4.1 DRX adaptation / SCell dormancy indication / Intra-band Contiguous CA
7.1.1.12.4.1.1 Test Purpose (TP)
(1)
with { UE in RRC_CONNECTED state with Scell configured and long DRX is configured and DCP is configured }
ensure that {
when { UE is outside DRX active time and receives the PDCCH indicating entering dormant BWP for SCell }
then { UE activates the BWP indicated by dormantBWP-Id and stops monitoring the PDCCH}
}
(2)
with { UE in RRC_CONNECTED state with Scell configured and long DRX is configured and DCP is configured }
ensure that {
when { UE is outside DRX active time and the active DL BWP is dormant BWP and receives the PDCCH indicating leaving dormant BWP from SCell }
then { UE activates the BWP indicated by firstOutsideActiveTimeBWP-Id and starts normal MAC operation on the new BWP }
}
7.1.1.12.4.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 38.212, clause 7.3.1.3.7, TS 38.213, clause 10.3, TS 38.321, clause 5.15.1 and 5.9. Unless otherwise stated these are Rel-15 requirements.
[TS 38.212, clause 7.3.1.3.7]
DCI format 2_6 is used for notifying the power saving information outside DRX Active Time for one or more UEs.
The following information is transmitted by means of the DCI format 2_6 with CRC scrambled by PS-RNTI:
– block number 1, block number 2,…, block number N
where the starting position of a block is determined by the parameter ps-PositionDCI-2-6 provided by higher layers for the UE configured with the block.
If the UE is configured with higher layer parameter ps-RNTI and dci-Format2-6, one block is configured for the UE by higher layers, with the following fields defined for the block:
– Wake-up indication – 1 bit
– SCell dormancy indication – 0 bit if higher layer parameter dormancyGroupOutsideActiveTime is not configured; otherwise 1, 2, 3, 4 or 5 bits bitmap determined according to higher layer parameter dormancyGroupOutsideActiveTime, where each bit corresponds to one of the SCell group(s) configured by higher layers parameter dormancyGroupOutsideActiveTime, with MSB to LSB of the bitmap corresponding to the first to last configured SCell group.
The size of DCI format 2_6 is indicated by the higher layer parameter sizeDCI-2-6, according to Clause 10.3 of [5, TS 38.213].
[TS 38.213, clause 10.3]
A UE configured with DRX mode operation [11, TS 38.321] can be provided the following for detection of a DCI format 2_6 in a PDCCH reception on the PCell or on the SpCell [12, TS 38.331]
– a PS-RNTI for DCI format 2_6 by ps-RNTI
– a number of search space sets, by dci-Format2-6, to monitor PDCCH for detection of DCI format 2_6 on the active DL BWP of the PCell or of the SpCell according to a common search space as described in Clause 10.1
– a payload size for DCI format 2_6 by sizeDCI_2-6
– a location in DCI format 2_6 of a Wake-up indication bit by psPositionDCI-2-6
– a ‘0’ value for the Wake-up indication bit, when reported to higher layers, indicates to not start the drx-onDurationTimer for the next long DRX cycle [11, TS 38.321]
– a ‘1’ value for the Wake-up indication bit, when reported to higher layers, indicates to start the drx-onDurationTimer for the next long DRX cycle [11, TS 38.321]
– a bitmap, when the UE is provided a number of groups of configured SCells by dormancyGroupOutsideActiveTime, where
– the bitmap location is immediately after the Wake-up indication bit location
– the bitmap size is equal to the number of groups of configured SCells where each bit of the bitmap corresponds to a group of configured SCells from the number of groups of configured SCells
– a ‘0’ value for a bit of the bitmap indicates an active DL BWP, provided by dormantBWP-Id, for the UE [11, TS38.321] for each activated SCell in the corresponding group of configured SCells
– a ‘1’ value for a bit of the bitmap indicates
– an active DL BWP, provided by firstOutsideActiveTimeBWP-Id, for the UE for each activated SCell in the corresponding group of configured SCells, if a current active DL BWP is the dormant DL BWP
– a current active DL BWP, for the UE for each activated SCell in the corresponding group of configured SCells, if the current active DL BWP is not the dormant DL BWP
– an offset by ps-Offset indicating a time, where the UE starts monitoring PDCCH for detection of DCI format 2_6 according to the number of search space sets, prior to a slot where the drx-onDuarationTimer would start on the PCell or on the SpCell [11, TS 38.321]
– for each search space set, the PDCCH monitoring occasions are the ones in the first slots indicated by duration, or slot if duration is not provided, starting from the first slot of the first slots and ending prior to the start of drx-onDurationTimer.
On PDCCH monitoring occasions associated with a same long DRX Cycle, a UE does not expect to detect more than one DCI format 2_6 with different values of the Wake-up indication bit for the UE or with different values of the bitmap for the UE.
The UE does not monitor PDCCH for detecting DCI format 2_6 during Active Time [11, TS 38.321].
If a UE reports for an active DL BWP a requirement of X slots prior to the beginning of a slot where the UE would start the drx-onDurationTimer, the UE is not required to monitor PDCCH for detection of DCI format 2_6 during the X slots, where X corresponds to the requirement of the SCS of the active DL BWP in Table 10.3-1.
Table 10.3-1: Minimum time gap value X
SCS (kHz) |
Minimum Time Gap X (slots) |
|
Value 1 |
Value 2 |
|
15 |
1 |
3 |
30 |
1 |
6 |
60 |
1 |
12 |
120 |
2 |
24 |
If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2_6 in the active DL BWP of the PCell or of the SpCell and the UE detects DCI format 2_6, the physical layer of a UE reports the value of the Wake-up indication bit for the UE to higher layers [11, TS 38.321] for the next long DRX cycle.
If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2_6 in the active DL BWP of the PCell or of the SpCell and the UE does not detect DCI format 2_6, the physical layer of the UE does not report a value of the Wake-up indication bit to higher layers for the next long DRX cycle.
If a UE is provided search space sets to monitor PDCCH for detection of DCI format 2_6 in the active DL BWP of the PCell or of the SpCell and the UE
– is not required to monitor PDCCH for detection of DCI format 2_6, as described in Clauses 10, 11.1, 12, and in Clause 5.7 of [11, TS 38.321] for all corresponding PDCCH monitoring occasions outside Active Time prior to a next long DRX cycle, or
– does not have any PDCCH monitoring occasions for detection of DCI format 2_6 outside Active Time of a next long DRX cycle
the physical layer of the UE reports a value of 1 for the Wake-up indication bit to higher layers for the next long DRX cycle.
…
If an active DL BWP provided by dormantBWP-Id for a UE on an activated SCell is not a default DL BWP for the UE on the activated SCell, as described in Clause 12, the BWP inactivity timer is not used for transitioning from the active DL BWP provided by dormantBWP-Id to the default DL BWP on the activated SCell.
[TS 38.321, clause 5.15.1]
In addition to clause 12 of TS 38.213 [6], this clause specifies requirements on BWP operation.
A Serving Cell may be configured with one or multiple BWPs, and the maximum number of BWP per Serving Cell is specified in TS 38.213 [6].
The BWP switching for a Serving Cell is used to activate an inactive BWP and deactivate an active BWP at a time. The BWP switching is controlled by the PDCCH indicating a downlink assignment or an uplink grant, by the bwp-InactivityTimer, by RRC signalling, or by the MAC entity itself upon initiation of Random Access procedure or upon detection of consistent LBT failure on SpCell. Upon RRC (re-)configuration of firstActiveDownlinkBWP-Id and/or firstActiveUplinkBWP-Id for SpCell or activation of an SCell, the DL BWP and/or UL BWP indicated by firstActiveDownlinkBWP-Id and/or firstActiveUplinkBWP-Id respectively (as specified in TS 38.331 [5]) is active without receiving PDCCH indicating a downlink assignment or an uplink grant. The active BWP for a Serving Cell is indicated by either RRC or PDCCH (as specified in TS 38.213 [6]). For unpaired spectrum, a DL BWP is paired with a UL BWP, and BWP switching is common for both UL and DL.
For each SCell a dormant BWP may be configured with dormantBWP-Id by RRC signalling as described in TS 38.331 [5]. Entering or leaving dormant BWP for SCells is done by BWP switching per SCell or per dormancy SCell group based on instruction from PDCCH (as specified in TS 38.213 [6]). The dormancy SCell group configurations are configured by RRC signalling as described in TS 38.331 [5]. Upon reception of the PDCCH indicating leaving dormant BWP, the DL BWP indicated by firstOutsideActiveTimeBWP-Id or by firstWithinActiveTimeBWP-Id (as specified in TS 38.331 [5] and TS 38.213 [6]) is activated. Upon reception of the PDCCH indicating entering dormant BWP, the DL BWP indicated by dormantBWP-Id (as specified in TS 38.331 [5]) is activated. The dormant BWP configuration for SpCell or PUCCH SCell is not supported.
For each activated Serving Cell configured with a BWP, the MAC entity shall:
1> if a BWP is activated and the active DL BWP for the Serving Cell is not the dormant BWP:
2> transmit on UL-SCH on the BWP;
2> transmit on RACH on the BWP, if PRACH occasions are configured;
2> monitor the PDCCH on the BWP;
2> transmit PUCCH on the BWP, if configured;
2> report CSI for the BWP;
2> transmit SRS on the BWP, if configured;
2> receive DL-SCH on the BWP;
2> (re-)initialize any suspended configured uplink grants of configured grant Type 1 on the active BWP according to the stored configuration, if any, and to start in the symbol according to rules in clause 5.8.2;
2> if lbt-FailureRecoveryConfig is configured:
3> stop the lbt-FailureDetectionTimer, if running;
3> set LBT_COUNTER to 0;
3> monitor LBT failure indications from lower layers as specified in clause 5.21.2.
1> if a BWP is activated and the active DL BWP for the Serving Cell is dormant BWP:
2> stop the bwp-InactivityTimer of this Serving Cell, if running.
2> not monitor the PDCCH on the BWP;
2> not monitor the PDCCH for the BWP;
2> not receive DL-SCH on the BWP;
2> not report CSI on the BWP, report CSI except aperiodic CSI for the BWP;
2> not transmit SRS on the BWP;
2> not transmit on UL-SCH on the BWP;
2> not transmit on RACH on the BWP;
2> not transmit PUCCH on the BWP.
2> clear any configured downlink assignment and any configured uplink grant Type 2 associated with the SCell respectively;
2> suspend any configured uplink grant Type 1 associated with the SCell;
2> if configured, perform beam failure detection and beam failure recovery for the SCell if beam failure is detected.
1> if a BWP is deactivated:
2> not transmit on UL-SCH on the BWP;
2> not transmit on RACH on the BWP;
2> not monitor the PDCCH on the BWP;
2> not transmit PUCCH on the BWP;
2> not report CSI for the BWP;
2> not transmit SRS on the BWP;
2> not receive DL-SCH on the BWP;
2> clear any configured downlink assignment and configured uplink grant of configured grant Type 2 on the BWP;
2> suspend any configured uplink grant of configured grant Type 1 on the inactive BWP.
Upon initiation of the Random Access procedure on a Serving Cell, after the selection of carrier for performing Random Access procedure as specified in clause 5.1.1, the MAC entity shall for the selected carrier of this Serving Cell:
1> if PRACH occasions are not configured for the active UL BWP:
2> switch the active UL BWP to BWP indicated by initialUplinkBWP;
2> if the Serving Cell is an SpCell:
3> switch the active DL BWP to BWP indicated by initialDownlinkBWP.
1> else:
2> if the Serving Cell is an SpCell:
3> if the active DL BWP does not have the same bwp-Id as the active UL BWP:
4> switch the active DL BWP to the DL BWP with the same bwp-Id as the active UL BWP.
1> stop the bwp-InactivityTimer associated with the active DL BWP of this Serving Cell, if running.
1> if the Serving Cell is SCell:
2> stop the bwp-InactivityTimer associated with the active DL BWP of SpCell, if running.
1> perform the Random Access procedure on the active DL BWP of SpCell and active UL BWP of this Serving Cell.
If the MAC entity receives a PDCCH for BWP switching of a Serving Cell, the MAC entity shall:
1> if there is no ongoing Random Access procedure associated with this Serving Cell; or
1> if the ongoing Random Access procedure associated with this Serving Cell is successfully completed upon reception of this PDCCH addressed to C-RNTI (as specified in clauses 5.1.4, 5.1.4a, and 5.1.5):
2> cancel, if any, triggered consistent LBT failure for this Serving Cell;
2> perform BWP switching to a BWP indicated by the PDCCH.
If the MAC entity receives a PDCCH for BWP switching for a Serving Cell(s) or a dormancy SCell group(s) while a Random Access procedure associated with that Serving Cell is ongoing in the MAC entity, it is up to UE implementation whether to switch BWP or ignore the PDCCH for BWP switching, except for the PDCCH reception for BWP switching addressed to the C-RNTI for successful Random Access procedure completion (as specified in clauses 5.1.4, 5.1.4a, and 5.1.5) in which case the UE shall perform BWP switching to a BWP indicated by the PDCCH. Upon reception of the PDCCH for BWP switching other than successful contention resolution, if the MAC entity decides to perform BWP switching, the MAC entity shall stop the ongoing Random Access procedure and initiate a Random Access procedure after performing the BWP switching; if the MAC decides to ignore the PDCCH for BWP switching, the MAC entity shall continue with the ongoing Random Access procedure on the Serving Cell.
…
1> if a PDCCH for BWP switching is received, and the MAC entity switches the active DL BWP:
2> if the defaultDownlinkBWP-Id is configured, and the MAC entity switches to the DL BWP which is not indicated by the defaultDownlinkBWP-Id and is not indicated by the dormantBWP-Id if configured; or
2> if the defaultDownlinkBWP-Id is not configured, and the MAC entity switches to the DL BWP which is not the initialDownlinkBWP and is not indicated by the dormantBWP-Id if configured:
3> start or restart the bwp-InactivityTimer associated with the active DL BWP.
[TS 38.321, clause 5.9]
If the MAC entity is configured with one or more SCells, the network may activate and deactivate the configured SCells. Upon configuration of an SCell, the SCell is deactivated unless the parameter sCellState is set to activated for the SCell by upper layers.
The configured SCell(s) is activated and deactivated by:
– receiving the SCell Activation/Deactivation MAC CE described in clause 6.1.3.10;
– configuring sCellDeactivationTimer timer per configured SCell (except the SCell configured with PUCCH, if any): the associated SCell is deactivated upon its expiry;
– configuring sCellState per configured SCell: if configured, the associated SCell is activated upon SCell configuration.
The MAC entity shall for each configured SCell:
1> if an SCell is configured with sCellState set to activated upon SCell configuration, or an SCell Activation/Deactivation MAC CE is received activating the SCell:
2> if the SCell was deactivated prior to receiving this SCell Activation/Deactivation MAC CE; or
2> if the SCell is configured with sCellState set to activated upon SCell configuration:
3> if firstActiveDownlinkBWP-Id is not set to dormant BWP:
4> activate the SCell according to the timing defined in TS 38.213 [6]; i.e. apply normal SCell operation including:
5> SRS transmissions on the SCell;
5> CSI reporting for the SCell;
5> PDCCH monitoring on the SCell;
5> PDCCH monitoring for the SCell;
5> PUCCH transmissions on the SCell, if configured.
3> else (i.e. firstActiveDownlinkBWP-Id is set to dormant BWP):
4> stop the bwp-InactivityTimer of this Serving Cell, if running.
3> activate the DL BWP and UL BWP indicated by firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id respectively.
2> start or restart the sCellDeactivationTimer associated with the SCell according to the timing defined in TS 38.213 [6];
2> if the active DL BWP is not the dormant BWP:
3> (re-)initialize any suspended configured uplink grants of configured grant Type 1 associated with this SCell according to the stored configuration, if any, and to start in the symbol according to rules in clause 5.8.2.2;
3> trigger PHR according to clause 5.4.6.
1> else if an SCell Activation/Deactivation MAC CE is received deactivating the SCell; or
1> if the sCellDeactivationTimer associated with the activated SCell expires:
2> deactivate the SCell according to the timing defined in TS 38.213 [6];
2> stop the sCellDeactivationTimer associated with the SCell;
2> stop the bwp-InactivityTimer associated with the SCell;
2> deactivate any active BWP associated with the SCell;
2> clear any configured downlink assignment and any configured uplink grant Type 2 associated with the SCell respectively;
2> clear any PUSCH resource for semi-persistent CSI reporting associated with the SCell;
2> suspend any configured uplink grant Type 1 associated with the SCell;
2> flush all HARQ buffers associated with the SCell;
2> cancel, if any, triggered consistent LBT failure for the SCell.
1> if PDCCH on the activated SCell indicates an uplink grant or downlink assignment; or
1> if PDCCH on the Serving Cell scheduling the activated SCell indicates an uplink grant or a downlink assignment for the activated SCell; or
1> if a MAC PDU is transmitted in a configured uplink grant and LBT failure indication is not received from lower layers; or
1> if a MAC PDU is received in a configured downlink assignment:
2> restart the sCellDeactivationTimer associated with the SCell.
1> if the SCell is deactivated:
2> not transmit SRS on the SCell;
2> not report CSI for the SCell;
2> not transmit on UL-SCH on the SCell;
2> not transmit on RACH on the SCell;
2> not monitor the PDCCH on the SCell;
2> not monitor the PDCCH for the SCell;
2> not transmit PUCCH on the SCell.
HARQ feedback for the MAC PDU containing SCell Activation/Deactivation MAC CE shall not be impacted by PCell, PSCell and PUCCH SCell interruptions due to SCell activation/deactivation in TS 38.133 [11].
When SCell is deactivated, the ongoing Random Access procedure on the SCell, if any, is aborted.
7.1.1.12.4.1.3 Test description
7.1.1.12.4.1.3.1 Pre-test conditions
Same Pre-test conditions as in clause 7.1.1.0 except that Test loop function(Off) System information combination NR-4 and in addition NR Cell 3 is configured as NR Active Scell.
7.1.1.12.4.1.3.2 Test procedure sequence
Table 7.1.1.12.4.1.3.2-1: Cell configuration power level changes over time for FR1
Parameter |
Unit |
NR Cell 1 |
NR Cell 3 |
Remarks |
|
T0 |
Cell-specific RS EPRE |
dBm/SCS |
-88 |
off |
NR cell 1 is available and NR cell 3 is not available |
T1 |
Cell-specific RS EPRE |
dBm/SCS |
-88 |
-88 |
NR cell 1 and NR cell 3 are available |
Table 7.1.1.12.4.1.3.2-2: Cell configuration power level changes over time for FR2
Parameter |
Unit |
NR Cell 1 |
NR Cell 3 |
Remarks |
|
T0 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
off |
NR cell 1 is available and NR cell 3 is not available |
T1 |
Cell-specific RS EPRE |
dBm/SCS |
-82 |
-82 |
NR cell 1 and NR cell 3 are available |
Table 7.1.1.12.4.1.3.2-3: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0 |
Set the power levels according to “T1” as per Table 7.1.1.12.4.1.3.2-1/2. |
||||
1 |
SS transmits an RRCReconfiguration message. (Note 1) |
<– |
|||
2 |
The UE transmits RRCReconfigurationComplete message. (Note 2) |
–> |
|||
3 |
The SS transmits a SCell Activation MAC-CE to activate SCell (NR Cell 3). |
<– |
MAC PDU (SCell Activation/Deactivation MAC CE of one octet (C1=1)) |
||
4 |
The SS transmits DCI 2-6 within ps-Offset time before the start of next long DRX drx-onDurationTimer on NR Cell 1. (Note 3) |
<– |
(PDCCH (DCI 2-6)) |
||
5 |
The SS indicates a new transmission on PDCCH of SCell and transmits a MAC PDU on the initial BWP (BWP#0) when the Drx-onDurationTimer is running. |
<– |
MAC PDU |
||
6 |
Check: Does the UE transmit a HARQ ACK on the SCell for the DL MAC PDU in Step 5 within 5 seconds? |
–> |
1 |
F |
|
7 |
The SS transmits DCI 2-6 within the ps-offset time before the start of next long DRX drx-onDurationTimer on NR Cell 1. (Note 4) |
<– |
(PDCCH (DCI 2-6)) |
||
8 |
The SS indicates a new transmission on PDCCH of SCell and transmits a MAC PDU on the active BWP (BWP#0) when the Drx-onDurationTimer is running. |
<– |
MAC PDU |
||
9 |
Check: Does the UE transmit a HARQ ACK on the SCell for the DL MAC PDU in Step 8? |
–> |
HARQ ACK |
2 |
P |
Note 1: For EN-DC the NR RRCReconfiguration message is contained in RRCConnectionReconfiguration 36.508 [7], Table 4.6.1-8 using condition EN-DC_EmbedNR_RRCRecon. Note 2: For EN-DC the NR RRCReconfigurationComplete message is contained in RRCConnectionReconfigurationComplete. Note 3: The Wake-up indication is value 1 and the SCell dormancy indication is value 0 in the DCI 2-6. Note 4: The Wake-up indication is value 1 and the SCell dormancy indication is value 1 in the DCI 2-6. |
7.1.1.12.4.1.3.3 Specific message contents
Table 7.1.1.12.4.1.3.3-1: RRCReconfiguration (step 1)
Derivation Path: TS 38.508-1 [6] |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
RRCReconfiguration ::= SEQUENCE { |
||||
criticalExtensions CHOICE { |
||||
rrcReconfiguration ::= SEQUENCE { |
||||
secondaryCellGroup |
CellGroupConfig |
EN-DC |
||
nonCriticalExtension SEQUENCE { |
NR |
|||
masterCellGroup |
CellGroupConfig |
|||
} |
||||
} |
||||
} |
||||
} |
Table 7.1.1.12.4.1.3.3-2: CellGroupConfig (Table 7.1.1.12.4.3.3-1: RRCReconfiguration)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-19 with condition SCell_add |
||||
Information Element |
Value/remark |
Comment |
Condition |
|
CellGroupConfig ::= SEQUENCE { |
||||
cellGroupId |
CellGroupId |
TS 38.508-1 default value |
||
mac-CellGroupConfig ::= SEQUENCE { |
||||
drx-Config CHOICE { |
||||
setup |
DRX-Config |
TS 38.508-1 default value |
||
} |
||||
} |
||||
physicalCellGroupConfig::= SEQUENCE { |
||||
dcp-Config-r16 CHOICE { |
||||
setup |
DCP-Config-r16 |
TS 38.508-1 default value |
||
} |
||||
} |
||||
spCellConfig SEQUENCE { |
||||
spCellConfigDedicated SEQUENCE { |
||||
servingCellConfig SEQUENCE { |
||||
initialDownlinkBWP SEQUENCE { |
||||
pdcch-Config CHOICE { |
||||
setup |
PDCCH-Config |
|||
} |
||||
} |
||||
} |
||||
} |
||||
} |
||||
sCellToAddModList SEQUENCE (SIZE (1..maxMeasId)) OF SCellConfig { |
1 entry |
|||
SCellConfig[1] SEQUENCE { |
entry 1 |
|||
sCellIndex |
SCellIndex as per TS 38.508-1 [4] table 4.6.3-154 |
|||
sCellConfigCommon |
ServingCellConfigCommon |
|||
sCellConfigDedicated |
ServingCellConfig |
|||
} |
||||
} |
||||
} |
Table 7.1.1.12.4.1.3.3-3: PDCCH-Config (Table 7.1.1.12.4.3.3-2: CellGroupConfig)
Derivation Path: TS 38.508-1 [4],Table 4.6.3-95 |
|||
Information Element |
Value/remark |
Comment |
Condition |
PDCCH-Config::= SEQUENCE { |
|||
controlResourceSetToAddModList SEQUENCE(SEQUENCE(SIZE (1..3)) OF ControlResourceSet ::= SEQUENCE { |
1 entry |
||
ControlResourceSet[1] |
ControlResourceSet |
TS 38.508-1 default value |
|
} |
|||
searchSpacesToAddModListExt-r16 SEQUENCE(SIZE (1..10)) OF SearchSpace { |
|||
searchSpaceExt-r16 ::= SEQUENCE { |
|||
controlResourceSetId-r16 |
1 |
||
searchSpaceType-r16 SEQUENCE { |
|||
common SEQUENCE { |
|||
dci-Format2-6-r16 SEQUENCE { |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.1.1.12.4.1.3.3-4: ServingCellConfigCommon (Table 7.1.1.12.4.3.3-2: CellGroupConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-168 with condition SCell_add. |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfigCommon ::= SEQUENCE { |
|||
physCellId |
Physical Cell Identity of NR Cell 3 |
||
} |
Table 7.1.1.12.4.1.3.3-5: ServingCellConfig (Table 7.1.1.12.4.3.3-2: CellGroupConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-167 with condition SCell_add |
|||
Information Element |
Value/remark |
Comment |
Condition |
ServingCellConfig ::= SEQUENCE { |
|||
downlinkBWP-ToAddModList SEQUENCE (SIZE (1..maxNrofBWPs)) BWP-Downlink { |
|||
BWP-Downlink |
BWP-Downlink |
||
} |
|||
firstActiveDownlinkBWP-Id |
0 |
||
dormancyGroupID-r16 |
0 |
||
dormantBWP-Config-r16 ::= SEQUENCE { |
|||
dormantBWP-Id-r16 |
1 |
||
outsideActiveTimeConfig-r16 CHOICE { |
|||
setup SEQUENCE { |
|||
firstOutsideActiveTimeBWP-Id-r16 |
0 |
||
dormancyGroupOutsideActiveTime-r16 |
0 |
||
} |
|||
} |
|||
} |
|||
pdsch-ServingCellConfig CHOICE { |
|||
setup SEQUENCE { |
|||
pucch-Cell |
1 |
||
} |
|||
} |
|||
} |
Table 7.1.1.12.4.1.3.3-6: BWP-Downlink (Table 7.1.1.12.4.3.3-5: ServingCellConfig)
Derivation Path: TS 38.508-1 [4], Table 4.6.3-9 |
|||
Information Element |
Value/remark |
Comment |
Condition |
BWP-Downlink ::= SEQUENCE { |
|||
bwp-Dedicated SEQUENCE { |
|||
pdcch-Config CHOICE { |
|||
setup SEQUENCE { |
|||
controlResourceSetToAddModList SEQUENCE(SIZE (1..3)) OF ControlResourceSet { |
1 entry |
||
ControlResourceSet[1] |
ControlResourceSet |
TS 38.508-1 default value |
|
} |
|||
controlResourceSetToReleaseList |
Not present |
||
} |
|||
} |
|||
} |
|||
} |
7.1.1.12.4.2 DRX adaptation / SCell dormancy indication / Intra-band non Contiguous CA
The scope and description of the present TC is the same as test case 7.1.1.12.4.1 with the following differences:
– CA configuration: Intra-band non-Contiguous CA replaces Intra-band Contiguous CA
7.1.1.12.4.3 DRX adaptation / SCell dormancy indication / Inter-band CA
The scope and description of the present TC is the same as test case 7.1.1.12.4.1 with the following differences:
– CA configuration: Inter-band CA replaces Intra-band Contiguous CA
– Cells configuration: NR Cell 10 replaces NR Cell 3