As in legacy LTE, LTE-BL/CE UE also start with RACH process to get the initial access to a network. There are commonality and differences in this process between legacy LTE and LTE-BL/CE.
- What are same ?
- What are the differences ?
- SIB Parameters for RACH
- RACH Sequence for Initial Access
- Step A : SIB2
- Step B : Msg1 Preamble Transmission
- Step C : MPDCCH for RACH Response
- Step D : RACH Response
- Step E : Msg 3
- Step F : MDPDCCH for Msg 4
- Step G : Msg 4
- Timing gaps and repetition counts
- What changed after Release 13
- Reference
What are same ?
It is worth settling what does not change before looking at what does, because the list is short and it is the part a reader of the legacy RACH pages already knows. The four points below hold for a BL/CE UE exactly as they hold for an ordinary one.
In short, Legacy LTE RACH and LTE BL/CE RACH are same in terms of general big picture and overal protocol sequence as follows :
- The main purpose of RACH process is to achieve Uplink synchronization and obtain the grant for initial attach
- Overall protocol sequence of the process is made up of four messages, i.e Msg 1, Msg2, Msg3 and Msg 4
- Basic information about the RACH procedure is informed to UE via SIB2
- prach-ConfigIndex, prach-FreqOffset, rootSequenceIndex are common for legacy LTE and MTC (Ref [8]). But some more parameters are used in MTC to configure further details.
The preamble itself is the strongest of those similarities, because it is generated exactly as it always was. The root comes from rootSequenceIndex, the cyclic shift from zeroCorrelationZoneConfig, the shift restriction from highSpeedFlag, and the subframes carrying the resource from prach-ConfigIndex. A BL/CE preamble is a legacy preamble, sent more than once.
The answer keeps its legacy shape too. The MAC random access response carries a random access preamble identifier, a timing advance command, an uplink grant and a temporary C-RNTI, in that order. 36.321 Figure 6.1.5-3 is the same figure a legacy reader knows. Only the twenty bits inside the grant are laid out differently.
What happens at the end of the exchange is unchanged as well. Contention is resolved either by a PDCCH addressed to the C-RNTI the UE already had, or by a UE contention resolution identity in Msg4 that echoes the first bytes of Msg3. A UE that loses that comparison backs off for a random time drawn against the backoff parameter and starts again.
The preamble is unmodified : same sequence family, same root, same cyclic shift, same configuration index. Repetition is applied on top of it rather than changing it.The four message exchange is unmodified : Msg1 to Msg4 in the same order, carrying the same things, ending in the same two ways.The power ramping parameters are unmodified : powerRampingStep and preambleInitialReceivedTargetPower sit in the legacy PowerRampingParameters and have no coverage enhanced twin.SIB2 is still where it all arrives : the new fields are extension groups inside the same information elements rather than a new system information block.
What are the differences ?
The differences all follow from one decision. A BL/CE UE may sit far below the coverage an ordinary UE needs. Every message in the exchange can therefore be sent many times over, and how many times depends on how deep the UE is. Repetition is the change, and everything below is a consequence of it.
In short, everything out side of the big picture differs. The most important differences are
- RACH Preamble (Msg1) and MPDCCH for RAR(Msg2) may be transmitted in repetition
- These repetition pattern gets different depending of CE Level
These differences are described in 3GPP specification as follows. However, I found it very difficult to figure out real / detailed meaning of these differences just from the specification. I think I need to go through many TDocs to find out the practical meaning of these differences and further details of BL/CE RACH procedure. I will keep updating this page as I read through those TDocs.
Based on 36.321 5.1.1, RACH Process for LTE-M1 device is modified from legacy LTE process as follows.
- The available set of PRACH resources is associated with each enhanced coverage level
- The preambles that are contained in Random Access Preambles groups for each enhanced coverage level are calculated from the parameters firstPreamble and lastPreamble of preambleMappingInfo IE of SIB2
In 36.321 5.1.2, it is stated as follows
- For NB-IoT UEs, BL UEs or UEs in enhanced coverage, select the ra-ResponseWindowSize and mac-ContentionResolutionTimer corresponding to the selected enhanced coverage level and PRACH
In 36.321 5.1.3, it is stated as follows
- if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:
instruct the physical layer to transmit a preamble with the number of repetitions required for preamble transmission corresponding to the selected preamble group (i.e., numRepetitionPerPreambleAttempt in SIB2) using the selected PRACH corresponding to the selected enhanced coverage level, corresponding RA-RNTI, preamble index or for NB-IoT subcarrier index, and PREAMBLE_RECEIVED_TARGET_POWER.
Those clauses all turn on one phrase, the selected enhanced coverage level, and 36.321 clause 5.1.1 is where the UE selects it. The UE measures RSRP and compares it against the thresholds in rsrp-ThresholdsPrachInfoList, working downward from level 3. It stops at the first level whose threshold the measurement falls below and which both the cell and the UE support. A UE in good coverage ends at level 0 and behaves almost like a legacy one.
Failure moves the UE down rather than simply repeating the attempt. Two counters run at once. PREAMBLE_TRANSMISSION_COUNTER counts attempts across the whole procedure and gives up at preambleTransMax-CE, while PREAMBLE_TRANSMISSION_COUNTER_CE counts attempts at the current level and reaches maxNumPreambleAttemptCE for that level. When the second one fills, it resets and the UE moves to the next level if that level is supported. An escalation through the four levels is therefore built into the procedure.
One consequence reaches further than it looks. The RA-RNTI formula is not the legacy one. 36.321 gives a BL/CE UE RA-RNTI = 1 + t_id + 10 × f_id + 60 × (SFN_id mod (Wmax / 10)), with Wmax set to 400. The extra term is there because the response window can span forty radio frames. Without it two preambles sent at the same subframe index in different frames would collide on the same RA-RNTI inside one window.
Repetition also buys power back. 36.321 lowers the preamble target power by ten times the logarithm of numRepetitionPerPreambleAttempt. A preamble repeated sixteen times is therefore sent about twelve decibels weaker per subframe than a single one. The energy the receiver accumulates is what matters, and the UE is free to spread it over time instead of concentrating it.
The coverage enhancement level is chosen by the UE : from its own RSRP against up to three broadcast thresholds, before any message has been exchanged.Almost every RACH parameter becomes a list : PRACH resource, preamble block, repetition count, response window and contention resolution timer are all per level rather than per cell.Failure escalates rather than repeating : maxNumPreambleAttemptCE bounds the attempts at one level, and the UE moves to the next level when that bound is reached.The RA-RNTI formula gained a frame term : a response window of up to 400 subframes would otherwise let two preambles share one RA-RNTI.
SIB Parameters for RACH
Everything a BL/CE UE needs before it can send a preamble arrives in SIB2, and the listings below trace the path from that message down to the fields that make the procedure a coverage enhanced one. The path splits in two. One branch configures the preambles and the waiting, and the other configures the PRACH resource itself.
The first tile is the route rather than the destination. SystemInformationBlockType2 is trimmed to the one field that leads onward. The two RadioResourceConfigCommon variants are shown in full, because the extension groups at their feet are where every release since Release 13 attached its additions.
Following is based on
SystemInformationBlockType2 ::= SEQUENCE {
...
radioResourceConfigCommon RadioResourceConfigCommonSIB,
...
}
RadioResourceConfigCommonSIB ::= SEQUENCE {
rach-ConfigCommon RACH-ConfigCommon,
bcch-Config BCCH-Config,
pcch-Config PCCH-Config,
prach-Config PRACH-ConfigSIB,
pdsch-ConfigCommon PDSCH-ConfigCommon,
pusch-ConfigCommon PUSCH-ConfigCommon,
pucch-ConfigCommon PUCCH-ConfigCommon,
soundingRS-UL-ConfigCommon SoundingRS-UL-ConfigCommon,
uplinkPowerControlCommon UplinkPowerControlCommon,
ul-CyclicPrefixLength UL-CyclicPrefixLength,
...,
[[ uplinkPowerControlCommon-v1020 UplinkPowerControlCommon-v1020 OPTIONAL -- Need OR
]],
[[ rach-ConfigCommon-v1250 RACH-ConfigCommon-v1250 OPTIONAL -- Need OR
]],
[[ pusch-ConfigCommon-v1270 PUSCH-ConfigCommon-v1270 OPTIONAL -- Need OR
]],
[[ bcch-Config-v1310 BCCH-Config-v1310 OPTIONAL, -- Need OR
pcch-Config-v1310 PCCH-Config-v1310 OPTIONAL, -- Need OR
freqHoppingParameters-r13 FreqHoppingParameters-r13 OPTIONAL, -- Need OR
pdsch-ConfigCommon-v1310 PDSCH-ConfigCommon-v1310 OPTIONAL, -- Need OR
pusch-ConfigCommon-v1310 PUSCH-ConfigCommon-v1310 OPTIONAL, -- Need OR
prach-ConfigCommon-v1310 PRACH-ConfigSIB-v1310 OPTIONAL, -- Need OR
pucch-ConfigCommon-v1310 PUCCH-ConfigCommon-v1310 OPTIONAL -- Need OR
]],
[[ highSpeedConfig-r14 HighSpeedConfig-r14 OPTIONAL, -- Need OR
prach-Config-v1430 PRACH-Config-v1430 OPTIONAL, -- Need OR
pucch-ConfigCommon-v1430 PUCCH-ConfigCommon-v1430 OPTIONAL -- Need OR
]],
[[ prach-Config-v1530 PRACH-ConfigSIB-v1530 OPTIONAL, -- Cond EDT
ce-RSS-Config-r15 RSS-Config-r15 OPTIONAL, -- Need OR
wus-Config-r15 WUS-Config-r15 OPTIONAL, -- Need OR
highSpeedConfig-v1530 HighSpeedConfig-v1530 OPTIONAL -- Need OR
]],
[[ uplinkPowerControlCommon-v1540 UplinkPowerControlCommon-v1530 OPTIONAL -- Need OR
]],
[[ wus-Config-v1560 WUS-Config-v1560 OPTIONAL -- Need OR
]],
[[ wus-Config-v1610 WUS-Config-v1610 OPTIONAL, -- Need OR
highSpeedConfig-v1610 HighSpeedConfig-v1610 OPTIONAL, -- Need OR
crs-ChEstMPDCCH-ConfigCommon-r16 CRS-ChEstMPDCCH-ConfigCommon-r16 OPTIONAL, -- Need OR
gwus-Config-r16 GWUS-Config-r16 OPTIONAL, -- Need OR
uplinkPowerControlCommon-v1610 UplinkPowerControlCommon-v1610 OPTIONAL, -- Need OR
rss-MeasConfig-r16 ENUMERATED {enabled} OPTIONAL, -- Need OR
rss-MeasNonNCL-r16 ENUMERATED {enabled} OPTIONAL, -- Need OR
puncturedSubcarriersDL-r16 BIT STRING (SIZE (2)) OPTIONAL, -- Need OR
highSpeedInterRAT-NR-r16 BOOLEAN OPTIONAL -- Need OR
]],
[[ pcch-Config-v1700 PCCH-Config-v1700 OPTIONAL, -- Need OR
ntn-ConfigCommon-r17 SEQUENCE {
ta-Report-r17 ENUMERATED {enabled} OPTIONAL, -- Need OR
t318-r17 ENUMERATED {
ms0, ms50, ms100, ms200,
ms500, ms1000, ms2000, ms4000},
prach-TxDuration-r17 PRACH-TxDuration-r17 OPTIONAL, -- Need OR
pucch-TxDuration-r17 PUCCH-TxDuration-r17 OPTIONAL, -- Need OR
pusch-TxDuration-r17 PUSCH-TxDuration-r17 OPTIONAL -- Need OR
} OPTIONAL -- Cond NTN
]],
[[ cb-Msg3-ConfigSIB-r19 CB-Msg3-ConfigSIB-r19 OPTIONAL -- Need OR
]]
}
RadioResourceConfigCommon ::= SEQUENCE {
rach-ConfigCommon RACH-ConfigCommon OPTIONAL, -- Need ON
prach-Config PRACH-Config,
pdsch-ConfigCommon PDSCH-ConfigCommon OPTIONAL, -- Need ON
pusch-ConfigCommon PUSCH-ConfigCommon,
phich-Config PHICH-Config OPTIONAL, -- Need ON
pucch-ConfigCommon PUCCH-ConfigCommon OPTIONAL, -- Need ON
soundingRS-UL-ConfigCommon SoundingRS-UL-ConfigCommon OPTIONAL, -- Need ON
uplinkPowerControlCommon UplinkPowerControlCommon OPTIONAL, -- Need ON
antennaInfoCommon AntennaInfoCommon OPTIONAL, -- Need ON
p-Max P-Max OPTIONAL, -- Need OP
tdd-Config TDD-Config OPTIONAL, -- Cond TDD
ul-CyclicPrefixLength UL-CyclicPrefixLength,
...,
[[ uplinkPowerControlCommon-v1020 UplinkPowerControlCommon-v1020 OPTIONAL -- Need ON
]],
[[ tdd-Config-v1130 TDD-Config-v1130 OPTIONAL -- Cond TDD3
]],
[[ pusch-ConfigCommon-v1270 PUSCH-ConfigCommon-v1270 OPTIONAL -- Need OR
]],
[[ prach-Config-v1310 PRACH-Config-v1310 OPTIONAL, -- Need ON
freqHoppingParameters-r13 FreqHoppingParameters-r13 OPTIONAL, -- Need ON
pdsch-ConfigCommon-v1310 PDSCH-ConfigCommon-v1310 OPTIONAL, -- Need ON
pucch-ConfigCommon-v1310 PUCCH-ConfigCommon-v1310 OPTIONAL, -- Need ON
pusch-ConfigCommon-v1310 PUSCH-ConfigCommon-v1310 OPTIONAL, -- Need ON
uplinkPowerControlCommon-v1310 UplinkPowerControlCommon-v1310 OPTIONAL -- Need ON
]],
[[ highSpeedConfig-r14 HighSpeedConfig-r14 OPTIONAL, -- Need OR
prach-Config-v1430 PRACH-Config-v1430 OPTIONAL, -- Need OR
pucch-ConfigCommon-v1430 PUCCH-ConfigCommon-v1430 OPTIONAL, -- Need OR
tdd-Config-v1430 TDD-Config-v1430 OPTIONAL -- Cond TDD3
]],
[[ tdd-Config-v1450 TDD-Config-v1450 OPTIONAL -- Cond TDD3
]],
[[ uplinkPowerControlCommon-v1530 UplinkPowerControlCommon-v1530 OPTIONAL, -- Need ON
highSpeedConfig-v1530 HighSpeedConfig-v1530 OPTIONAL -- Need OR
]],
[[ highSpeedConfig-v1610 HighSpeedConfig-v1610 OPTIONAL, -- Need OR
uplinkPowerControlCommon-v1610 UplinkPowerControlCommon-v1610 OPTIONAL, -- Need OR
highSpeedInterRAT-NR-r16 BOOLEAN OPTIONAL -- Need ON
]],
[[ ntn-ConfigCommon-r17 SEQUENCE {
ta-Report-r17 ENUMERATED {enabled} OPTIONAL, -- Need OR
t318-r17 ENUMERATED {
ms0, ms50, ms100, ms200, ms500,
ms1000, ms2000, ms4000, ms6000},
prach-TxDuration-r17 PRACH-TxDuration-r17 OPTIONAL, -- Need OR
pucch-TxDuration-r17 PUCCH-TxDuration-r17 OPTIONAL, -- Need OR
pusch-TxDuration-r17 PUSCH-TxDuration-r17 OPTIONAL -- Need OR
} OPTIONAL -- Cond NTN
]]
}
Two names are worth separating before reading on. RadioResourceConfigCommonSIB is the broadcast form and it is what a UE reads in SIB2, while RadioResourceConfigCommon is the dedicated form carried in an RRC Connection Setup. The RACH fields appear in both, so a cell can broadcast one configuration and hand a connected UE another.
The RACH branch comes next. It holds the parameters that govern preambles, power ramping and how long the UE waits for an answer. The legacy fields sit at the top, and the Release 13 extension group at the foot of RACH-ConfigCommon adds the two that make the procedure coverage aware.
Following is based on
RACH-ConfigCommon ::= SEQUENCE {
preambleInfo SEQUENCE {
numberOfRA-Preambles ENUMERATED {
n4, n8, n12, n16, n20, n24, n28,
n32, n36, n40, n44, n48, n52, n56,
n60, n64},
preamblesGroupAConfig SEQUENCE {
sizeOfRA-PreamblesGroupA ENUMERATED {
n4, n8, n12, n16, n20, n24, n28,
n32, n36, n40, n44, n48, n52, n56,
n60},
messageSizeGroupA ENUMERATED {b56, b144, b208, b256},
messagePowerOffsetGroupB ENUMERATED {
minusinfinity, dB0, dB5, dB8, dB10, dB12,
dB15, dB18},
...
} OPTIONAL -- Need OP
},
powerRampingParameters PowerRampingParameters,
ra-SupervisionInfo SEQUENCE {
preambleTransMax PreambleTransMax,
ra-ResponseWindowSize ENUMERATED {
sf2, sf3, sf4, sf5, sf6, sf7,
sf8, sf10},
mac-ContentionResolutionTimer ENUMERATED {
sf8, sf16, sf24, sf32, sf40, sf48,
sf56, sf64}
},
maxHARQ-Msg3Tx INTEGER (1..8),
...,
[[ preambleTransMax-CE-r13 PreambleTransMax OPTIONAL, -- Need OR
rach-CE-LevelInfoList-r13 RACH-CE-LevelInfoList-r13 OPTIONAL -- Need OR
]],
[[ edt-SmallTBS-Subset-r15 ENUMERATED {true} OPTIONAL -- Cond EDT-OR
]]
}
RACH-ConfigCommon-v1250 ::= SEQUENCE {
txFailParams-r12 SEQUENCE {
connEstFailCount-r12 ENUMERATED {n1, n2, n3, n4},
connEstFailOffsetValidity-r12 ENUMERATED {s30, s60, s120, s240,
s300, s420, s600, s900},
connEstFailOffset-r12 INTEGER (0..15) OPTIONAL -- Need OP
}
}
RACH-ConfigCommonSCell-r11 ::= SEQUENCE {
powerRampingParameters-r11 PowerRampingParameters,
ra-SupervisionInfo-r11 SEQUENCE {
preambleTransMax-r11 PreambleTransMax
},
...
}
RACH-CE-LevelInfoList-r13 ::= SEQUENCE (SIZE (1..maxCE-Level-r13)) OF RACH-CE-LevelInfo-r13
RACH-CE-LevelInfo-r13 ::= SEQUENCE {
preambleMappingInfo-r13 SEQUENCE {
firstPreamble-r13 INTEGER(0..63),
lastPreamble-r13 INTEGER(0..63)
},
ra-ResponseWindowSize-r13 ENUMERATED {sf20, sf50, sf80, sf120, sf180,
sf240, sf320, sf400},
mac-ContentionResolutionTimer-r13 ENUMERATED {sf80, sf100, sf120,
sf160, sf200, sf240, sf480, sf960},
rar-HoppingConfig-r13 ENUMERATED {on,off},
...,
[[ edt-Parameters-r15 SEQUENCE {
edt-LastPreamble-r15 INTEGER(0..63),
edt-SmallTBS-Enabled-r15 BOOLEAN,
edt-TBS-r15 ENUMERATED {b328, b408, b504, b600, b712,
b808, b936, b1000or456},
mac-ContentionResolutionTimer-r15 ENUMERATED {sf240, sf480, sf960,
sf1920, sf3840, sf5760, sf7680, sf10240}
OPTIONAL -- Need OP
} OPTIONAL -- Cond EDT
]]
}
PowerRampingParameters ::= SEQUENCE {
powerRampingStep ENUMERATED {dB0, dB2,dB4, dB6},
preambleInitialReceivedTargetPower ENUMERATED {
dBm-120, dBm-118, dBm-116, dBm-114, dBm-112,
dBm-110, dBm-108, dBm-106, dBm-104, dBm-102,
dBm-100, dBm-98, dBm-96, dBm-94,
dBm-92, dBm-90}
}
PreambleTransMax ::= ENUMERATED {
n3, n4, n5, n6, n7, n8, n10, n20, n50,
n100, n200}
The two Release 13 fields at the foot of RACH-ConfigCommon carry most of the difference this page is about.
preambleTransMax-CE-r13 : how many preamble attempts a BL/CE UE makes before the procedure fails, replacing the legacy preambleTransMax for that UE. Both draw on the same PreambleTransMax type, which reaches n200.rach-CE-LevelInfoList-r13 : one RACH-CE-LevelInfo-r13 entry per coverage enhancement level, up to maxCE-Level-r13. Every field inside it is therefore per level rather than per cell.preambleMappingInfo-r13 : firstPreamble-r13 and lastPreamble-r13 divide the 64 preamble indices into one block per level. That is how the eNB reads the level off the preamble alone, before any message has been exchanged.ra-ResponseWindowSize-r13 : sf20 to sf400, against sf2 to sf10 in the legacy field above it. A deep coverage UE needs a window forty times longer, because the RAR itself arrives repeated.mac-ContentionResolutionTimer-r13 : sf80 to sf960, against sf8 to sf64 in the legacy field. The reasoning is the same one.rar-HoppingConfig-r13 : whether the PDSCH carrying the RAR hops in frequency, on or off, and it is set per level like the rest.
The PRACH branch is the last of the three. It decides when the preamble may be sent, on which resource blocks, and how many times it is repeated.
Following is based on
PRACH-ConfigSIB ::= SEQUENCE {
rootSequenceIndex INTEGER (0..837),
prach-ConfigInfo PRACH-ConfigInfo
}
PRACH-ConfigSIB-v1310 ::= SEQUENCE {
rsrp-ThresholdsPrachInfoList-r13 RSRP-ThresholdsPrachInfoList-r13,
mpdcch-startSF-CSS-RA-r13 CHOICE {
fdd-r13 ENUMERATED {v1, v1dot5, v2, v2dot5, v4, v5, v8,
v10},
tdd-r13 ENUMERATED {v1, v2, v4, v5, v8, v10, v20, spare}
} OPTIONAL, -- Cond MP
prach-HoppingOffset-r13 INTEGER (0..94) OPTIONAL, -- Need OR
prach-ParametersListCE-r13 PRACH-ParametersListCE-r13
}
PRACH-Config ::= SEQUENCE {
rootSequenceIndex INTEGER (0..837),
prach-ConfigInfo PRACH-ConfigInfo OPTIONAL -- Need ON
}
PRACH-Config-v1310 ::= SEQUENCE {
rsrp-ThresholdsPrachInfoList-r13 RSRP-ThresholdsPrachInfoList-r13 OPTIONAL, -- Cond MP
mpdcch-startSF-CSS-RA-r13 CHOICE {
fdd-r13 ENUMERATED {v1, v1dot5, v2, v2dot5, v4, v5, v8,
v10},
tdd-r13 ENUMERATED {v1, v2, v4, v5, v8, v10, v20, spare}
} OPTIONAL, -- Cond MP
prach-HoppingOffset-r13 INTEGER (0..94) OPTIONAL, -- Need OR
prach-ParametersListCE-r13 PRACH-ParametersListCE-r13 OPTIONAL, -- Cond MP
initial-CE-level-r13 INTEGER (0..3) OPTIONAL -- Need OR
}
PRACH-ConfigSCell-r10 ::= SEQUENCE {
prach-ConfigIndex-r10 INTEGER (0..63)
}
PRACH-ConfigInfo ::= SEQUENCE {
prach-ConfigIndex INTEGER (0..63),
highSpeedFlag BOOLEAN,
zeroCorrelationZoneConfig INTEGER (0..15),
prach-FreqOffset INTEGER (0..94)
}
PRACH-ParametersListCE-r13 ::= SEQUENCE (SIZE(1..maxCE-Level-r13)) OF PRACH-ParametersCE-r13
PRACH-ParametersCE-r13 ::= SEQUENCE {
prach-ConfigIndex-r13 INTEGER (0..63),
prach-FreqOffset-r13 INTEGER (0..94),
prach-StartingSubframe-r13 ENUMERATED {sf2, sf4, sf8, sf16, sf32, sf64, sf128,
sf256} OPTIONAL, -- Need OP
maxNumPreambleAttemptCE-r13
ENUMERATED {n3, n4, n5, n6, n7, n8, n10}
OPTIONAL, -- Need OP
numRepetitionPerPreambleAttempt-r13 ENUMERATED {n1,n2,n4,n8,n16,n32,n64,n128},
mpdcch-NarrowbandsToMonitor-r13 SEQUENCE (SIZE(1..2)) OF
INTEGER (1..maxAvailNarrowBands-r13),
mpdcch-NumRepetition-RA-r13 ENUMERATED {r1, r2, r4, r8, r16,
r32, r64, r128, r256},
prach-HoppingConfig-r13 ENUMERATED {on,off}
}
RSRP-ThresholdsPrachInfoList-r13 ::= SEQUENCE (SIZE(1..3)) OF RSRP-Range
PRACH-ParametersCE-r13 is the list that matters here, and like the RACH list above it there is one entry per coverage enhancement level.
prach-ConfigIndex-r13 and prach-FreqOffset-r13 : the PRACH configuration index and the first resource block of the preamble, per level. Both have the same meaning as the legacy fields of the same name in PRACH-ConfigInfo, and both are repeated here so that each level can use a different resource.prach-StartingSubframe-r13 : the periodicity of the subframes in which a repeated preamble may start, sf2 to sf256. A preamble that occupies many subframes cannot begin anywhere.maxNumPreambleAttemptCE-r13 : how many attempts are made at this level before the UE moves to the next one, n3 to n10.numRepetitionPerPreambleAttempt-r13 : how many times one preamble attempt is repeated, n1 to n128. This is the N the diagram further down marks beside Msg1.mpdcch-NarrowbandsToMonitor-r13 : one or two narrowbands for the MPDCCH that schedules the RAR. Where two are configured, 36.213 Table 6.2-E picks between them on the parity of the preamble index.mpdcch-NumRepetition-RA-r13 : the repetition ceiling for that MPDCCH, r1 to r256.prach-HoppingConfig-r13 : whether the preamble hops, with the distance given once per cell by prach-HoppingOffset-r13 rather than per level.
Two fields outside the list decide which entry of it the UE uses. The first is rsrp-ThresholdsPrachInfoList-r13, which carries up to three RSRP thresholds. Three thresholds divide the range into the four levels that maxCE-Level-r13 allows. The second is initial-CE-level-r13, which appears only in the dedicated PRACH-Config-v1310 and tells a connected UE where to start rather than making it measure.
One field is easy to misread. The name mpdcch-startSF-CSS-RA-r13 ends in a subframe rather than a symbol, and that is exactly what it sets. It gives the starting subframe configuration of the MPDCCH common search space, which is how often that search space begins. 36.331 names RAR, Msg3 retransmission, contention resolution and the CCCH PDSCH as what it covers. The starting OFDM symbol is a different field, startSymbolBR in PDSCH-ConfigCommon-v1310.
Details on Information Elements
The two decodes below come from live networks rather than from the specification, and they are the shortest way to see which of the fields above a real cell actually sends. Read them against the listings, because most of what the ASN.1 offers is absent in both.
Captured from a live network, not quoted from a specification. The field names follow
< Example 1 >
+-sib2 ::= SEQUENCE [00] +-ac-BarringInfo ::= SEQUENCE OPTIONAL:Omit +-radioResourceConfigCommon ::= SEQUENCE | +-rach-ConfigCommon ::= SEQUENCE | | +-preambleInfo ::= SEQUENCE [0] | | | +-numberOfRA-Preambles ::= ENUMERATED [n64] | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit | | +-powerRampingParameters ::= SEQUENCE | | | +-powerRampingStep ::= ENUMERATED [dB2] | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-90] | | +-ra-SupervisionInfo ::= SEQUENCE | | | +-preambleTransMax ::= ENUMERATED [n5] | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10] | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf64] | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4] | | +-EXTENSION ::= SEQUENCE [1] | | +-VERSION-BRACKETS1 ::= SEQUENCE [11] OPTIONAL:Exist | | +-preambleTransMax-CE-r13 ::= ENUMERATED [n5] OPTIONAL:Exist | | +-rach-CE-LevelInfoList-r13 ::= SEQUENCE OF SIZE(1..maxCE-Level-r13[4]) [1] | | +-RACH-CE-LevelInfo-r13 ::= SEQUENCE | | +-preambleMappingInfo-r13 ::= SEQUENCE | | | +-firstPreamble-r13 ::= INTEGER (0..63) [0] | | | +-lastPreamble-r13 ::= INTEGER (0..63) [63] | | +-ra-ResponseWindowSize-r13 ::= ENUMERATED [sf80] | | +-mac-ContentionResolutionTimer-r13 ::= ENUMERATED [sf200] | | +-rar-HoppingConfig-r13 ::= ENUMERATED [off] | | +-EXTENSION ::= SEQUENCE | +-bcch-Config ::= SEQUENCE | +-pcch-Config ::= SEQUENCE | +-prach-Config ::= SEQUENCE | | +-rootSequenceIndex ::= INTEGER (0..837) [0] | | +-prach-ConfigInfo ::= SEQUENCE | | +-prach-ConfigIndex ::= INTEGER (0..63) [3] | | +-highSpeedFlag ::= BOOLEAN [FALSE] | | +-zeroCorrelationZoneConfig ::= INTEGER (0..15) [0] | | +-prach-FreqOffset ::= INTEGER (0..94) [1] | +-pdsch-ConfigCommon ::= SEQUENCE | +-pusch-ConfigCommon ::= SEQUENCE | +-pucch-ConfigCommon ::= SEQUENCE | +-soundingRS-UL-ConfigCommon ::= CHOICE [release] | | +-release ::= NULL | +-uplinkPowerControlCommon ::= SEQUENCE | | +-p0-NominalPUSCH ::= INTEGER (-126..24) [-108] | | +-alpha ::= ENUMERATED [al09] | | +-p0-NominalPUCCH ::= INTEGER (-127..-96) [-96] | | +-deltaFList-PUCCH ::= SEQUENCE | | +-deltaPreambleMsg3 ::= INTEGER (-1..6) [3] | +-ul-CyclicPrefixLength ::= ENUMERATED [len1] | +-EXTENSION ::= SEQUENCE [0001] | +-VERSION-BRACKETS1 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS2 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS3 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS4 ::= SEQUENCE [1010011] OPTIONAL:Exist | +-bcch-Config-v1310 ::= SEQUENCE OPTIONAL:Exist | +-pcch-Config-v1310 ::= SEQUENCE OPTIONAL:Omit | +-freqHoppingParameters-r13 ::= SEQUENCE [000000] OPTIONAL:Exist | | +-mpdcch-pdsch-HoppingNB-r13 ::= ENUMERATED OPTIONAL:Omit | | +-interval-DLHoppingConfigCommonModeA-r13 ::= CHOICE OPTIONAL:Omit | | +-interval-DLHoppingConfigCommonModeB-r13 ::= CHOICE OPTIONAL:Omit | | +-interval-ULHoppingConfigCommonModeA-r13 ::= CHOICE OPTIONAL:Omit | | +-interval-ULHoppingConfigCommonModeB-r13 ::= CHOICE OPTIONAL:Omit | | +-mpdcch-pdsch-HoppingOffset-r13 ::= INTEGER OPTIONAL:Omit | +-pdsch-ConfigCommon-v1310 ::= SEQUENCE OPTIONAL:Omit | +-pusch-ConfigCommon-v1310 ::= SEQUENCE OPTIONAL:Omit | +-prach-ConfigCommon-v1310 ::= SEQUENCE [10] OPTIONAL:Exist | | +-rsrp-ThresholdsPrachInfoList-r13 ::= SEQUENCE OF SIZE(1..3) [1] | | | +-RSRP-Range ::= INTEGER (0..97) [60] | | +-mpdcch-startSF-CSS-RA-r13 ::= CHOICE [fdd-r13] OPTIONAL:Exist | | | +-fdd-r13 ::= ENUMERATED [v5] | | +-prach-HoppingOffset-r13 ::= INTEGER OPTIONAL:Omit | | +-prach-ParametersListCE-r13 ::= SEQUENCE OF SIZE(1..maxCE-Level-r13[4]) [1] | | +-PRACH-ParametersCE-r13 ::= SEQUENCE [11] | | +-prach-ConfigIndex-r13 ::= INTEGER (0..63) [3] | | +-prach-FreqOffset-r13 ::= INTEGER (0..94) [1] | | +-prach-StartingSubframe-r13 ::= ENUMERATED [sf2] OPTIONAL:Exist | | +-maxNumPreambleAttemptCE-r13 ::= ENUMERATED [n3] OPTIONAL:Exist | | +-numRepetitionPerPreambleAttempt-r13 ::= ENUMERATED [n1] | | +-mpdcch-NarrowbandsToMonitor-r13 ::= SEQUENCE OF SIZE(1..2) [1] | | | +- ::= INTEGER (1..maxAvailNarrowBands-r13[16]) [2] | | +-mpdcch-NumRepetition-RA-r13 ::= ENUMERATED [r1] | | +-prach-HoppingConfig-r13 ::= ENUMERATED [off] | +-pucch-ConfigCommon-v1310 ::= SEQUENCE [10000] OPTIONAL:Exist +-ue-TimersAndConstants ::= SEQUENCE +-freqInfo ::= SEQUENCE [00] +-mbsfn-SubframeConfigList ::= SEQUENCE OF OPTIONAL:Omit +-timeAlignmentTimerCommon ::= ENUMERATED [infinity] +-EXTENSION ::= SEQUENCE [0000000] HEX : 00 00 6F 7C BF 60 20 99 00 3F 52 02 C0 00 C0 05 E2 00 00 04 26 00 01 2D F2 02 01 88 65 30 21 E2 98 60 40 01 0C 10 00 00 83 CD C3 01 C0
Captured from a live network, not quoted from a specification. The field names follow
< Example 2 >
+-sib2 ::= SEQUENCE [00] +-ac-BarringInfo ::= SEQUENCE OPTIONAL:Omit +-radioResourceConfigCommon ::= SEQUENCE | +-rach-ConfigCommon ::= SEQUENCE | | +-preambleInfo ::= SEQUENCE [0] | | | +-numberOfRA-Preambles ::= ENUMERATED [n64] | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit | | +-powerRampingParameters ::= SEQUENCE | | | +-powerRampingStep ::= ENUMERATED [dB2] | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-90] | | +-ra-SupervisionInfo ::= SEQUENCE | | | +-preambleTransMax ::= ENUMERATED [n5] | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10] | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf64] | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4] | | +-EXTENSION ::= SEQUENCE [1] | | +-VERSION-BRACKETS1 ::= SEQUENCE [11] OPTIONAL:Exist | | +-preambleTransMax-CE-r13 ::= ENUMERATED [n5] OPTIONAL:Exist | | +-rach-CE-LevelInfoList-r13 ::= SEQUENCE OF SIZE(1..maxCE-Level-r13[4]) [1] | | +-RACH-CE-LevelInfo-r13 ::= SEQUENCE | | +-preambleMappingInfo-r13 ::= SEQUENCE | | | +-firstPreamble-r13 ::= INTEGER (0..63) [0] | | | +-lastPreamble-r13 ::= INTEGER (0..63) [63] | | +-ra-ResponseWindowSize-r13 ::= ENUMERATED [sf80] | | +-mac-ContentionResolutionTimer-r13 ::= ENUMERATED [sf200] | | +-rar-HoppingConfig-r13 ::= ENUMERATED [off] | | +-EXTENSION ::= SEQUENCE | +-bcch-Config ::= SEQUENCE | +-pcch-Config ::= SEQUENCE | +-prach-Config ::= SEQUENCE | | +-rootSequenceIndex ::= INTEGER (0..837) [0] | | +-prach-ConfigInfo ::= SEQUENCE | | +-prach-ConfigIndex ::= INTEGER (0..63) [3] | | +-highSpeedFlag ::= BOOLEAN [FALSE] | | +-zeroCorrelationZoneConfig ::= INTEGER (0..15) [0] | | +-prach-FreqOffset ::= INTEGER (0..94) [1] | +-pdsch-ConfigCommon ::= SEQUENCE | +-pusch-ConfigCommon ::= SEQUENCE | +-pucch-ConfigCommon ::= SEQUENCE | +-soundingRS-UL-ConfigCommon ::= CHOICE [release] | +-uplinkPowerControlCommon ::= SEQUENCE | | +-deltaPreambleMsg3 ::= INTEGER (-1..6) [3] | +-ul-CyclicPrefixLength ::= ENUMERATED [len1] | +-EXTENSION ::= SEQUENCE [0001] | +-VERSION-BRACKETS1 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS2 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS3 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS4 ::= SEQUENCE [1010011] OPTIONAL:Exist | +-bcch-Config-v1310 ::= SEQUENCE OPTIONAL:Exist | | +-modificationPeriodCoeff-v1310 ::= ENUMERATED [n64] | +-pcch-Config-v1310 ::= SEQUENCE OPTIONAL:Omit | +-freqHoppingParameters-r13 ::= SEQUENCE [111111] OPTIONAL:Exist | | +-mpdcch-pdsch-HoppingNB-r13 ::= ENUMERATED [nb2] OPTIONAL:Exist | | +-interval-DLHoppingConfigCommonModeA-r13 ::= CHOICE [interval-FDD-r13] OPTIONAL:Exist | | | +-interval-FDD-r13 ::= ENUMERATED [int1] | | +-interval-DLHoppingConfigCommonModeB-r13 ::= CHOICE [interval-FDD-r13] OPTIONAL:Exist | | | +-interval-FDD-r13 ::= ENUMERATED [int2] | | +-interval-ULHoppingConfigCommonModeA-r13 ::= CHOICE [interval-FDD-r13] OPTIONAL:Exist | | | +-interval-FDD-r13 ::= ENUMERATED [int1] | | +-interval-ULHoppingConfigCommonModeB-r13 ::= CHOICE [interval-FDD-r13] OPTIONAL:Exist | | | +-interval-FDD-r13 ::= ENUMERATED [int2] | | +-mpdcch-pdsch-HoppingOffset-r13 ::= INTEGER (1..maxAvailNarrowBands-r13[16]) [1] | +-pdsch-ConfigCommon-v1310 ::= SEQUENCE OPTIONAL:Omit | +-pusch-ConfigCommon-v1310 ::= SEQUENCE OPTIONAL:Omit | +-prach-ConfigCommon-v1310 ::= SEQUENCE [10] OPTIONAL:Exist | | +-rsrp-ThresholdsPrachInfoList-r13 ::= SEQUENCE OF SIZE(1..3) [1] | | | +-RSRP-Range ::= INTEGER (0..97) [60] | | +-mpdcch-startSF-CSS-RA-r13 ::= CHOICE [fdd-r13] OPTIONAL:Exist | | | +-fdd-r13 ::= ENUMERATED [v5] | | +-prach-HoppingOffset-r13 ::= INTEGER [0] | | +-prach-ParametersListCE-r13 ::= SEQUENCE OF SIZE(1..maxCE-Level-r13[4]) [1] | | +-PRACH-ParametersCE-r13 ::= SEQUENCE [11] | | +-prach-ConfigIndex-r13 ::= INTEGER (0..63) [3] | | +-prach-FreqOffset-r13 ::= INTEGER (0..94) [1] | | +-prach-StartingSubframe-r13 ::= ENUMERATED [sf2] OPTIONAL:Exist | | +-maxNumPreambleAttemptCE-r13 ::= ENUMERATED [n3] OPTIONAL:Exist | | +-numRepetitionPerPreambleAttempt-r13 ::= ENUMERATED [n1] | | +-mpdcch-NarrowbandsToMonitor-r13 ::= SEQUENCE OF SIZE(1..2) [1] | | | +- ::= INTEGER (1..maxAvailNarrowBands-r13[16]) [2] | | +-mpdcch-NumRepetition-RA-r13 ::= ENUMERATED [r1] | | +-prach-HoppingConfig-r13 ::= ENUMERATED [off] | +-pucch-ConfigCommon-v1310 ::= SEQUENCE [11111] OPTIONAL:Exist | +-n1PUCCH-AN-InfoList-r13 ::= SEQUENCE OF SIZE(1..maxCE-Level-r13[4]) [2] OPTIONAL:Exist | | +- ::= INTEGER (0..2047) [0] | | +- ::= INTEGER (0..2047) [2] | +-pucch-NumRepetitionCE-Msg4-Level0-r13 ::= ENUMERATED [n1] OPTIONAL:Exist | +-pucch-NumRepetitionCE-Msg4-Level1-r13 ::= ENUMERATED [n1] OPTIONAL:Exist | +-pucch-NumRepetitionCE-Msg4-Level2-r13 ::= ENUMERATED [n4] OPTIONAL:Exist | +-pucch-NumRepetitionCE-Msg4-Level3-r13 ::= ENUMERATED [n4] OPTIONAL:Exist +-ue-TimersAndConstants ::= SEQUENCE +-freqInfo ::= SEQUENCE [00] +-mbsfn-SubframeConfigList ::= SEQUENCE OF OPTIONAL:Omit +-timeAlignmentTimerCommon ::= ENUMERATED [infinity] +-EXTENSION ::= SEQUENCE [0000000] HEX : 00 00 6F 7C BF 60 20 99 00 3F 52 02 C0 00 C0 05 E2 00 00 04 26 00 01 2D F2 02 01 88 7D 3F C0 00 10 F1 4C 30 20 00 87 E8 00 00 40 03 CD C3 01 C0
RACH Sequence for Initial Access
Following is the overal protocol sequence of MTC(BL/CE) RACH process for Initial Access (Initial Registration). If you see the big picture, it would look very similar to RACH Process in Legacy LTE. The only outstanding difference would be you see a whole lots more arrows in MTC RACH process comparing to the process in legacy LTE.
Actually the 'lots of arrows' is very important characteristics in MTC RACH and it is the most important differences between legacy LTE RACH and MTC RACH in detailed pictures. As you can easily guess, the multiple arrows at each step indicates the repetative transmission.
When you trying to understand the details of MTC RACH process, you need to be able to answer to following questions. In other words, if you can answer to the following questions, you may say you have pretty good understandings on MTC RACH process. You need to ask following questions for each and every steps (except the step (A))
i) Does this step require the repetative transmission ?
ii) If it requires the repetition, how many times it has to repeat ?
iii) How UE/eNB can figure out whether it should be repeated or not and how many times ?
iv) Through which narrowband (Narrowband Index) this message should be transmitted ?
v) How UE/eNB can figure out which Narrowband should be used ?
vi) Does this message should be transmitted in a fixed frequency ? or in hopping frequency ?
vii) How UE/eNB can figure out whether it should be transmitted in a fixed frequency ? or in hopping frequency ?
viii) What should be the timing gap between each steps ?
The whole exchange on one timeline. Every message that repeats carries a bracket on the left, and every gap that has to be worked out carries an arrow on the right.
The circled letters run from A to K : the sections below cover A to G, which is the random access procedure proper. H to K are what follows it, namely the HARQ ACK for Msg4, a scheduling request, the MPDCCH for RRC Connection Complete and the message itself.The brackets N1 to N5 mark the five things that repeat : the preamble, the MPDCCH for the RAR, Msg3, the MPDCCH for Msg4 and Msg4. The RAR itself is drawn once, because it is one PDSCH.The arrows G1 to G4 mark the four gaps : preamble to RAR window, RAR to Msg3, Msg3 to the MPDCCH for Msg4, and that MPDCCH to Msg4.The red bar on the right is the RAR window : it opens where G1 ends, and its length is the ra-ResponseWindowSize of the level the UE chose.Orange arrows point upward and green arrows downward : orange is the uplink and green the downlink, so the colours alone separate what the UE sends from what it receives.
Two of the questions above are answered by the diagram and the rest are not. Which steps repeat is visible at a glance, and so is where each gap sits. How long each gap runs and how many repetitions each bracket stands for come from the tables further down.
Step A : SIB2
Nothing in the exchange can start until the UE has read SIB2, because the PRACH resources, the preamble blocks, the repetition counts and the two timers are all broadcast there. The listings in the section above are that message. This step is the one place where the UE only listens.
- Parameters required for basic configurations for RACH is transmitted by SIB2
NOTE : If you are working on verification or protocol stack implementation, you have to make it sure that Network populate valid (consistant among multiple parameters) the PRACH parameters SIB2 and UE (DUT) has successfully decoded SIB2 and has no complain about the parameter settings in SIB2. Even when UE successfully decoded SIB2, there is some possibility where UE does not like some of the parameter setting and print error. In this case, UE would not send PRACH preamble.
Step B : Msg1 Preamble Transmission
Before UE send Msg1 (RACH Preamble), it has to determine what kind of RACH resource (time, frequency and preamble ID). Most of these resource information is notified to UE via SIB2 and some of the information (e.g, CE Level) is determined by UE based on cell power(RSRP) measurement. Followings are the list of information that UE figure out from higher layer signaling message (SIB2).
- PRACH configuration is signaled based on Table 5.7.1.2~5.7.1.4 in TS 36.211. The signaling parameters for PRACH configuration are as follows (Refer to 36.211-5.7.1). All of them are in SIB2.
- prach-ConfigurationIndex
- prach-FrequencyOffset
- numRepetitionPerPreambleAttempt
- prach-StartingSubframe
- The starting frequency location of the preamble is signaled(prach-FreqOffset). The unit of the frequency location is indicated in the unit of PRB. (Ref [8])
- PRACH can be transmitted in frequency hopping mode if following parameters are configured.(Refer to 36.211-5.7.1). All of them are in SIB2.
- prach-HoppingConfig
- prach-HoppingOffset
NOTE : If UE log says it has sent PRACH Preamble and eNB log says that it has not received PRACH, you have to check all the detailed lower layer configuration both in UE and eNB. If you are at this stage, you might have already checked SIB2 and there wouldn't be any issues in SIB2 parameter itself. However, there might be problems of interpreting SIB2 parameters to lower layer configuration on UE or on eNB. For this kind of troubleshooting, you should have access to very detailed low layer logging tool for both UE and eNB, and you have knowledge to interpret those log. There are many cases where higher layer signaling parameter (SIB2 in this case) is not directly mapped to lower layer configuration and many cases higher layer specification and lower layer specification uses different terminology. So it would be very difficult (almost impossible) for a single person to understand everything. So you should have good contact to various engineers specialized in each separate layers.
Step C : MPDCCH for RACH Response
A certain period (3 subframs) after PRACH premable has tranmitted, UE start trying to decode MPDCCH carrying DCI that is required to decode RAR message. It means .. once eNB received RACH Preamble, the eNB would send MPDCCH carrying DCI for PDSCH carrying RAR. Regarding this MPDCCH, you would have a couple of questions listed below.
- In which narrowband the RAR will be transmitted ?
- Does MPDCCH for RAR be transmitted in repetition ? or transmitted only once ?
- How many times ?
- How the repetition is configured ?
- When the first MPDCCH should be transmitted and how it is configured ?
The answer to these questions are
- The narrowband for RAR MPDCCH (i.e, MPDCCH to decode the PDSCH carrying RAR) is determined by SIB2 parameter mpdcch-NarrowbandsToMonitor.
- This MPDCCH is being transmitted in repetition.
- The number of repetition is configured by mpdcch-NumRepetition-RA-r13 in SIB2.
NOTE : The SIB2 parameter for this MPDCCH is simple. It is defined by mpdcch-NumRepetition-RA-r13, but this single parameter is related to a few other lower layer parameters and in terms of 3GPP specification, a pretty complicated procedure and hidden tables are involved. You need to understand every details of 36.213-9.1.5 MPDCCH assignment procedure. Without complete understanding of this process, it would be difficult to troubleshoot for this step.
Step D : RACH Response
The RAR is the densest message in the exchange. Twenty bits in CE mode A and twelve in CE mode B have to carry a complete uplink grant. 36.213 recovers the missing width by making several fields into table indices rather than values. The pictures below are those tables.
As in legacy LTE, RAR carries two critical information as follows.
- Response to PRACH Preamble (It says 'Yes, I got the PRACH Preamble withi this ID (RAPID)')
- Resource Allocation Information for Msg3.
The second part (i.e, Resource Allocation Information for Msg3) is made up of following information. As you see, depending on CE mode the bit field structure varies.
The same 20 bit and 12 bit grants seen twice. On the left as they sit inside the MAC RAR of 36.321, and on the right broken into the fields 36.213 Table 6-2 defines.
The left column is the MAC layer view : 36.321 Figure 6.1.5-3 is the CE mode A layout, where the UL Grant runs across three octets. Figure 6.1.5-3a is the CE mode B one, where it is shorter.The right column is the physical layer view : 36.213 Table 6-2 splits the same bits into ten fields and gives each a width per CE mode.The two totals are 20 bits and 12 bits : the CE mode B grant is eight bits shorter. It recovers those bits by setting MCS, TPC, CSI request and UL delay to zero width.Two entries are expressions rather than numbers : the Msg3 PUSCH narrowband index for CE mode A and the zero padding beside it both depend on the system bandwidth, through the two formulas at the top.
The two formulas are worth reading slowly. NNB is the number of narrowbands in the uplink bandwidth, which is the uplink resource block count divided by six and rounded down. NNBindex is the number of bits that count needs. A CE mode A grant therefore changes shape with the cell bandwidth while a CE mode B grant does not. The zero padding row absorbs the difference, so the total stays at 20.
Checked against 36.213 v19.4.0, Table 6-2 is unchanged from this screenshot, field for field.
Most of the field in this structure is pretty straight forward but there some field that are a little challenging to understand mainly due to the nature of repetition and you would need some other tables as follows.
The narrowband index for Msg PUSCH in CEmodeA is directly defined by the field 'Msg3 PUSCH narrowband index', but the meaning of 'Msg3 PUSCH narrowband index' in CE mode B is determined by another table a shown below (This table defines the Msg3 PUSCH narrowband index for the first transmission. The narrowband index for the retransmitted Msg may change by some other factors) .
Why CE mode B needs only two bits for a narrowband. It does not name one, it names an offset from the narrowband the RAR arrived on.
The starting point is NBRAR : the narrowband the MPDCCH for the RAR used, which came from mpdcch-NarrowbandsToMonitor-r13 in SIB2.The four rows add 0, 1, 2 or 3 to it : the sum is then taken modulo NNB, so it wraps rather than pointing past the last narrowband.Two bits therefore reach four narrowbands, not all of them : that is the whole saving. It is also why the CE mode A column of Table 6-2 holds an expression where this one holds a fixed 2.
NOTE : NB_RAR in this table is determined by higher layer signaling parameter mpdcch-NarrowbandsToMonitor-r13 in SIB2.
The repetition number field in the random access response grant configured by higher layers indicates the repetition level for Msg3 PUSCH as given in Table 6.2-C for CEmodeA and Table 6.2-D for CEmodeB, where Y_A is determined by higher layer parameter pusch-maxNumRepetitionCEmodeA-r13, and Y_B is determined by higher layer parameter pusch-maxNumRepetitionCEmodeB-r13
Following is the interpretation of 'Number of Reptition for Msg3 PUSCH' for CEmodeA
The CE mode A repetition set. Two bits select an eighth, a quarter, a half or the whole of the ceiling the network configured.
YA is pusch-maxNumRepetitionCEmodeA-r13 : the note at the top says so, and it says that YA is 8 when SIB2 does not carry the field.The four rows are YA over 8, 4, 2 and 1 : the top row of the table is the smallest repetition level and the bottom row is the configured maximum.The default of 8 is where the value r8 earns its place : 36.213 Table 8-2b, which governs an ordinary CE mode A PUSCH, has no row for 8 at all.
Following is the interpretation of 'Number of Reptition for Msg3 PUSCH' for CEmodeB
The CE mode B set, eight values rather than four, with a default ceiling of 512 instead of 8.
YB is pusch-maxNumRepetitionCEmodeB-r13 : and it is 512 when SIB2 does not carry the field, which is sixty four times the CE mode A default.The eight rows run from YB over 128 up to YB : each step doubles, so three bits cover a range of 128 to 1.The red box in the lower picture sits one row above the field the arrow describes : Table 6.2-D interprets the repetition number field, not the Msg3 PUSCH resource allocation field. Both are three bits wide in CE mode B, which is what makes the slip easy to miss.
With this, do you think you can interpret all of the field in RAR(36.213-Table 6-2) ? Unfortunately, No. You need another table to interpret the field Msg3/4 MPDCCH narrowband index. The interpretation of this field comes from following table.
The same trick as the Msg3 table, applied to the downlink. Note the denominator, which counts downlink narrowbands rather than uplink ones.
The offsets are the same 0 to 3 : and the base is again NBRAR, so both directions are measured from the narrowband the RAR arrived on.The modulus is NNB2 rather than NNB : it is built from the downlink resource block count, and in an asymmetric carrier the two counts differ.This field is two bits in both CE modes : the red band across the lower table covers both columns, which none of the other rows does.
You see a parameter NB_RAR in Table 6.2-A and 6.2-B. That parameter is defined by another table shown below. As you see here, NB_RAR is determined by mpdcch-NarrowbandsToMonitor-r13 and whether Preamble Index is even or odd.
< 36.213 - Table 6.2-E: Narrowband ( NB_RAR ) for MPDCCH RAR >
The last piece. NB RAR is not signalled anywhere, it is derived from the preamble the UE happened to choose.
An even mapped preamble index takes the first narrowband : and an odd one takes the second, both from mpdcch-NarrowbandsToMonitor-r13.The table only applies when two narrowbands are configured : with one, 36.213 says NBRAR is that one and the parity never comes into it.This is why the preamble index reaches so far : it already picked the CE level through preambleMappingInfo-r13, and here it also picks which narrowband the answer comes back on.
Checked against 36.213 v19.4.0, Tables 6.2-A, 6.2-B and 6.2-E are unchanged from these screenshots.
Yes , I know... it would be so confusing to follow through all of these tables and get some clear meaning out of the RAR message.
Step E : Msg 3
Once UE completed the Step (D), that is, decoding the contents of RAR, UE send Msg3 (RRC Connection Request). Before UE send this message and Network trying to receive this message, they both should know of the following information.
- In which narrowband the message will be transmitted ?
- Will it be transmitted in repetition ? How many times ?
- Which MCS, TBS is used for this message ?
The answer is simple as follows.
- The answers to all of the questions listed above lies in the contents of RAR
Step F : MDPDCCH for Msg 4
As soon as UE transmit the Msg3(RRC Connection Request), UE start monitoring (trying to detect) the MPDCCH that is needed to receive Msg4 PDSCH (i.e, the PDSCH carrying Msg4). For UE to properly decode this channel, it has to know of following params.
- Which Narrowband is used to carry the MPDCCH ?
- From which OFDMA symbol is the MPDCCH allocated (assinged) ?
- How many PRB pairs are used to carry this MPDCCH ?
The answer to these questions comes from RAR and SIB2 as follows.
- Which Narrowband is used to carry the MPDCCH ? ==> This comes from the item Msg3/4 MPDCCH narrowband index in RAR
- From which OFDMA symbol is the MPDCCH allocated (assinged) ? ==> This comes from startSymbolBR in pdsch-ConfigCommon-v1310. The field prach-ConfigCommon-v1310.mpdcch-startSF-CSS-RA-r13.fdd-r13 answers a different question, namely how often the common search space starts
- How many PRB pairs are used to carry this MPDCCH ? ==> Six of them, as the 2 plus 4 set. 36.213 9.1.5 fixes the MPDCCH-PRB-set of every common search space at 2+4 PRB pairs, so nothing is signalled for it
Step G : Msg 4
Once UE has decoded MPDCCH for Msg4 decoding, it decode Msg4 (MAC CE for Contention Resolution) and it completes RACH process if there is no problem with CR. Usually this CR and RRC Connection Setup message is carried in the same MAC PDU.
Timing gaps and repetition counts
The diagram in the section above raises eight questions and settles two of them. Which steps repeat is drawn, and so is where each gap sits. How long a gap runs and how many repetitions a bracket stands for are not drawn, and this section supplies them, each from the clause or the field that fixes it.
Start with the gaps, because three of the four are measured from a point that does not exist in legacy LTE. A legacy message occupies one subframe, so there is no question of which subframe to count from. A repeated message occupies many, and 36.321 and 36.213 both count from the last one rather than the first.
Gap | Measured from | To | What fixes it |
G1 | The subframe holding the last preamble repetition | The first subframe of the RA response window | Three subframes, by 36.321 clause 5.1.4. The window is then open for ra-ResponseWindowSize-r13 subframes of the selected CE level, which is the red bar in the drawing |
G2 | The subframe in which the RAR reception ends | The first Msg3 subframe | 36.213 clause 6.1.1. Msg3 goes in the first available BL/CE uplink subframe at or after n plus k1 plus Koffset, and the UL delay bit in the grant moves it on to the next available one |
G3 | The subframe holding the last Msg3 repetition | The start of the contention resolution timer | 36.321 clause 5.1.5. The timer then runs for mac-ContentionResolutionTimer-r13 subframes of the selected CE level, and the UE monitors the MPDCCH throughout |
G4 | The last subframe of the MPDCCH carrying the Msg4 grant | The first Msg4 PDSCH subframe | 36.213 clause 7.1.11. The PDSCH starts in the second BL/CE downlink subframe after n, which is the same delay any CE mode scheduling uses |
The four gaps of the drawing, against 36.213 v19.4.0 and 36.321 v19.3.0. K offset is zero outside a non-terrestrial deployment.
One detail in G2 is worth stating plainly. The reference point is the end of the PDSCH carrying the RAR, not the end of the MPDCCH that scheduled it. That is the opposite of the rule everywhere else in CE mode. Every other uplink transmission on this page is counted from the last MPDCCH subframe.
The repetition counts come from three different places, and that is the part worth carrying away. Two of them are broadcast, two are read out of the grant that schedules the message, and one of the broadcast ones is used twice.
Mark | What repeats | Where the count comes from | Range |
N1 | Msg1, the preamble | numRepetitionPerPreambleAttempt-r13 in SIB2, one value per CE level | n1 to n128 |
N2 | The MPDCCH carrying the RAR grant | mpdcch-NumRepetition-RA-r13 in SIB2, one value per CE level. It is the ceiling of the Type2 common search space rather than a fixed count | r1 to r256 |
N3 | Msg3, the PUSCH | The repetition number field of the RAR grant, read through 36.213 Table 6.2-C in CE mode A or Table 6.2-D in CE mode B | Up to pusch-maxNumRepetitionCEmodeA-r13, default 8, or pusch-maxNumRepetitionCEmodeB-r13, default 512 |
N4 | The MPDCCH carrying the Msg4 grant | mpdcch-NumRepetition-RA-r13 again. The UE has only a Temporary C-RNTI at this point, so 36.213 Table 7.1-8 keeps it in the same Type2 common search space | r1 to r256 |
N5 | Msg4, the PDSCH | The repetition number field of DCI format 6-1A or 6-1B, read through 36.213 Table 7.1.11-1 or Table 7.1.11-2 | Up to pdsch-maxNumRepetitionCEmodeA-r13 or pdsch-maxNumRepetitionCEmodeB-r13 |
The five repetition brackets of the drawing, against 36.213 v19.4.0 and 36.331 v19.3.0.
Which of the two CE modes applies is not configured for a UE that is still in random access, and it does not have to be. 36.213 clause 6.2 reads it off the coverage enhancement level the UE used for the PRACH. Levels 0 and 1 are interpreted as CE mode A and levels 2 and 3 as CE mode B. The preamble the UE picked has therefore already settled which column of every table above applies.
Three of the four gaps count from a last repetition : the response window, the contention resolution timer and the Msg4 delay all start after the repeated message has finished.One field sets two of the five repetition counts : mpdcch-NumRepetition-RA-r13 governs the MPDCCH for the RAR and the one for Msg4 alike, because both use the Type2 common search space.The two timers are per CE level, not per cell : ra-ResponseWindowSize-r13 and mac-ContentionResolutionTimer-r13 both live inside RACH-CE-LevelInfo-r13, so a deep UE waits longer than a near one in the same cell.The preamble index decides more than which preamble was sent : it fixes the CE level through preambleMappingInfo-r13, the CE mode through that level, and the RAR narrowband through its parity.
What changed after Release 13
The references at the foot of this page are Release 13 documents, and the sequence they describe is still the one a Release 13 UE follows. Nothing above has been overtaken. What has happened since is that three more ways through the same four messages were added beside it, and each one appears in the listings as another extension group.
The largest of them is Early Data Transmission, which arrived in Release 15. A UE with a small amount of data to send puts it in Msg3 and never leaves the random access procedure. The exchange can then finish at Msg4 rather than continuing into an RRC connection. Paying for that costs a second set of PRACH resources, a separate preamble block, a larger Msg3 transport block and a much longer contention resolution timer.
EDT also changes the RAR grant this page draws. 36.213 replaces Table 6-2 with Table 6.2-F when higher layers indicate EDT, and the substitution is not a small one. The MCS and TBS rows disappear altogether. The Msg3 PUSCH resource allocation widens from four bits to five in CE mode A, and both narrowband index fields widen from two bits to three in CE mode B. The totals stay at 20 bits and 12 bits, because the zero padding row absorbs the difference.
Release | What the random access procedure gained | Field |
Rel-13 | The procedure on this page. Per level PRACH resources, per level preamble blocks, and per level response and contention resolution timers | rach-CE-LevelInfoList-r13, prach-ParametersListCE-r13 |
Rel-14 | A second PRACH configuration for a high speed cell, used in place of the ordinary one when the UE is told to | highSpeedConfig-r14, prach-Config-v1430 |
Rel-15 | Early Data Transmission. Its own PRACH resource list, its own preamble block on top of the Release 13 one, a largest Msg3 transport block per level, and a contention resolution timer reaching sf10240 | prach-Config-v1530, edt-Parameters-r15, edt-SmallTBS-Subset-r15 |
Rel-16 | A group wake-up signal and a CRS based channel estimation configuration, both broadcast beside the RACH parameters rather than inside them | gwus-Config-r16, crs-ChEstMPDCCH-ConfigCommon-r16 |
Rel-17 | Non-terrestrial operation. The response window and the contention resolution timer both gain the UE to eNB round trip time, and a new timer supervises the connection | ntn-ConfigCommon-r17, ta-Report-r17, t318-r17 |
Rel-19 | A contention based form of Msg3 EDT, with its own RSRP thresholds, its own per level configuration list and its own power ramping | cb-Msg3-ConfigSIB-r19 |
Compared against 36.331 v19.3.0 and 36.213 v19.4.0, with each release dated by the suffix of the field that configures it in 36.331.
The Release 17 entry is the one that touches the drawing directly. Both G1 and G3 gain a round trip time term when the preamble was sent on a non-terrestrial network, so the response window opens later and the contention resolution timer starts later. On a terrestrial cell the term is absent and the timing is unchanged.
The Release 13 procedure is untouched : every later release adds a path beside it rather than altering it, so the sequence drawn above still holds.EDT rewrites the RAR grant rather than extending it : 36.213 Table 6.2-F replaces Table 6-2 whole, and the fields that survive change width.The preamble space is where EDT is signalled : edt-LastPreamble-r15 extends each level's block, so the eNB learns from the preamble alone that the UE intends EDT.Non-terrestrial operation stretches the two waits : the response window and the contention resolution timer both absorb the propagation delay, and nothing else in the exchange moves.
Reference
[1] 3GPP TS 36.321 V13.2.0 (2016-06)
[2] 3GPP R1-156420 : TSG RAN WG1 Meeting #83 - Random access for MTC
[3] 3GPP R1-156446 : TSG RAN WG1 Meeting #83 - On PRACH resource indication and level determination during random access
[4] 3GPP R1-156447 : TSG RAN WG1 Meeting #83 - New DCI format to support efficient RAR transmission for MTC UEs
[5] 3GPP R1-156565 : TSG RAN WG1 Meeting #83 - Remaining issues on random access for Rel-13 MTC
[6] 3GPP R1-156651 : TSG RAN WG1 Meeting #83 - Random Access for MTC
[7] 3GPP R1-156685 : TSG RAN WG1 Meeting #83 - RAR transmission for Rel-13 MTC
[8] 3GPP R1-156847 : TSG RAN WG1 Meeting #83 - Details on RACH procedure for MTC UE
[9] 3GPP R2-153717 : TSG RAN WG2 Meeting #91 - Random access for Rel-13 low complexity and enhanced coverage UEs // Strongly Recommended
[10] 3GPP TS 36.211 v19.3.0 - clause 5.7 Physical random access channel
[11] 3GPP TS 36.213 v19.4.0 - clause 6.1.1 Timing, clause 6.2 Random Access Response Grant with Tables 6-2 and 6.2-A to 6.2-F, clause 7.1.11 and clause 9.1.5 MPDCCH assignment procedure
[12] 3GPP TS 36.321 v19.3.0 - clause 5.1 Random Access procedure, in particular 5.1.4 Random Access Response reception and 5.1.5 Contention Resolution
[13] 3GPP TS 36.331 v19.3.0 - the RACH-ConfigCommon, RACH-CE-LevelInfo-r13, PRACH-ConfigSIB-v1310 and PRACH-ParametersCE-r13 information elements