The
following post discusses about Random Access procedure in 5G NR from the MAC
layer perspective.
Random Access Procedure - Introduction
As
in the case of LTE, the RA procedure can take two distinct forms: Contention-Based
Random Access (CBRA) and Contention-Free Random Access (CFRA) procedures as shown
below:
In CBRA, the UE randomly
selects an RA preamble from a pool of preambles shared with other UEs in the cell.
If multiple UEs select/transmit same preamble (Msg1), all those UEs decode same
Msg2 content and transmit Msg3 on the same UL time/frequency resources. In the
next step (Msg4), the network resolves the contention. Complete details are
discussed in the following sections.
In CFRA, the UE
uses a dedicated preamble provided by the network specifically to this UE via
RRC signaling or PDCCH order.
The RA procedure is initiated by a PDCCH order from the gNB, by the UE’s
MAC entity itself, or by RRC. The RA procedure is triggered by a number of
events:
-
Initial access from
RRC_IDLE (CBRA)
-
RRC Connection
Re-establishment procedure (CBRA)
-
DL data arrival during
RRC_CONNECTED when UL synchronisation status is "non-synchronised" i.e.,
Out-of-Sync (CBRA or CFRA)
-
UL data arrival during
RRC_CONNECTED when UL synchronisation status is "non-synchronised" i.e.,
Out-of-Sync (CBRA)
-
UL data arrival during
RRC_CONNECTED when there are no PUCCH resources for SR available (CBRA)
-
SR failure (CBRA)
-
Request by RRC upon
synchronous reconfiguration (e.g. handover) (CBRA or CFRA)
-
Transition from
RRC_INACTIVE (CBRA)
-
To establish time
alignment for a secondary TAG (CBRA or CFRA)
-
Request for On-demand
System Information (CBRA or CFRA)
-
Beam failure recovery (CBRA
or CFRA)
Notes:
Similar to LTE,
when CA is configured, the first three steps (1, 2, and 3) of CBRA always occur
on the PCell while contention resolution (step 4) can be cross-scheduled by the
PCell.
If the CFRA is
initiated on the PCell, then all three steps (0, 1, and 2) of a CFRA takes
place on the PCell itself.
CFRA on SCell
can only be initiated by the gNB to establish timing advance for a secondary
TAG: the procedure is initiated by the gNB with a PDCCH order (step 0) that is sent
on a scheduling cell of an activated SCell of the secondary TAG, preamble
transmission (step 1) takes place on the indicated SCell, and RAR (step 2)
takes place on PCell.
For random
access in a cell configured with Supplementary Uplink (SUL), the network can
explicitly signal which carrier to use (NUL or SUL). If not, the random access
is carried out on the SUL carrier if the RSRP is below a broadcasted threshold
(rsrp-ThresholdSSB-SUL).
-
Once started, all
uplink transmissions of the RA procedure remain on the selected carrier (NUL or
SUL).
Random Access Resource Selection
Random
access resource selection is mostly
similar to LTE except for beam failure recovery, On-demand System Information (SI
request) and other CFRA cases which are discussed in detail below.
RA resource selection for CBRA:
The UE first needs to select an SSB before selecting
RA preamble. If available, the UE selects an SSB with
SS-RSRP above rsrp-ThresholdSSB for PRACH transmission, otherwise, UE selects any SSB.
The UE then selects
an RA Preamble randomly with equal probability from the RA Preambles associated
with the selected SSB and the selected RA Preambles group.
RA resource selection for BFR:
Beam
Failure Recovery (BFR) will be discussed in a separate post in detail. For BFR,
CFRA is used if RRC provides BeamFailureRecoveryConfig
(shown in the picture below), otherwise,
CBRA is used.
If CFRA is used,
the UE may be configured with a set of a candidate beams via candidateBeamRSList
(SSB and/or CSI-RS) and their resources (Resource ID, Preamble ID, RACH occasion
etc…).
-
If at least one of the
candidate beam’s RSRP is above a configured threshold (rsrp-ThresholdSSB),
the UE selects an SSB or CSI-RS.
-
Once a downlink beam is
identified, the preamble would be transmitted on the associated uplink beam.
-
The UE uses ra-PreambleIndex
corresponding to the selected SSB or CSI-RS (if configured).
-
If CSI-RS resource is not
configured with ra-PreambleIndex, the UE uses ra-PreambleIndex corresponding
to the SSB in candidateBeamRSList which is quasi-colocated with the
selected CSI-RS.
By transmitting
a preamble on the dedicated RA resources corresponding to selected CSI-RS/SSB, the
UE not only informs the network that it has detected beam failure but also indicates
the identified beam.
RA resource selection for SI request (On-Demand SI):
For
UEs in RRC_IDLE and RRC_INACTIVE, a request for Other SI triggers
an RA procedure. If the
network configures the UE with PRACH resources for SI request, CFRA is used,
otherwise CBRA is used
The network may configure the UE with dedicated RACH resources for SI request
purpose within SI-RequestConfig which is transmitted in SI-SchedulingInfo IE (in SIB1). In this case
Msg1 is used to indicate the requested Other SI.
-
UE selects an RA Preamble
corresponding to the selected SSB, from the RA Preamble(s) determined according
to ra-PreambleStartIndex (from SI-RequestConfig)
-
When Msg1 is used, the
minimum granularity of the request is one SI message (i.e. a set of SIBs).
-
One RACH preamble and/or
PRACH resource can be used to request multiple SI messages
-
The gNB acknowledges
the request in Msg2.
SI-RequestConfig is shown below;
When CBRA is used for SI request via Msg3, the gNB acknowledges the
request in Msg4.
RA Resource Selection for Reconfiguration with Sync:
For reconfiguration with sync
(e.g. Handover) purpose, the RA configuration to be used is provided by the gNB
within RACH-ConfigDedicated
(shown below). cfra field
provides the required parameters for CFRA to a given target cell. If the field
is absent, the UE performs CBRA.
For CFRA, the UE
is configured with SSB or CSI-RS random access resources.
If the
configured CFRA resources are for SSB, the UE selects an SSB with SS-RSRP above
rsrp-ThresholdSSB amongst
the associated SSBs and then picks the corresponding RA resources.
Similarly, if the
configured CFRA resources are for CSI-RS, the UE selects a CSI-RS with CSI-RSRP
above rsrp-ThresholdCSI-RS
amongst the associated CSI-RSs and then picks the corresponding RA resources.
RA resource selection for PDCCH-Order:
DCI
format 1_0 addressed to C-RNTI with all fields of "Frequency domain
resource assignment" set to ones indicate that the received DCI is for RA
procedure initiated by a PDCCH order. This DCI contains the following;
-
RA Preamble Index – 6 bits
-
UL/SUL indicator – 1
bit. If the UE is configured with SUL in ServingCellConfig in the cell, this field
indicates which UL carrier in the cell to transmit the PRACH, otherwise, this
field is reserved
-
SS/PBCH index – 6 bits.
If the value of the "RA 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 "RA 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, otherwise, this field is
reserved
Similar to LTE, if RA preamble index provided by PDCCH order is not
equal to 0b000000, the UE performs CFRA on the SSB signalled by PDCCH order,
otherwise (RA preamble index = 0b000000), the UE performs CBRA.
Note: The RA procedure on an SCell shall only be initiated by a PDCCH
order (same as LTE) with ra-PreambleIndex different from 0b000000
Random Access Preamble Transmission
This procedure is almost same
as that of LTE. RA_RNTI calculation is a bit different. RA_RNTI is used to
address the UE on PDCCH which in turn used for decoding of PDSCH for Random
Access Response (RAR).
The MAC entity calculates RA_RNTI except for CFRA used for BFR request (in
this case, C-RNTI is used for RAR). RA_RNTI is calculation is given below:
RA-RNTI= 1 +
s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id
-
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)
-
ul_carrier_id is the UL
carrier used for Msg1 transmission (0 for NUL and 1 for SUL carrier)
MAC instructs
the physical layer to transmit PRACH using preamble index, PRACH occasion, and
RA-RNTI (if available)
Random Access Response Reception
Once the RA
preamble is transmitted, the UE waits for the acknowledgement from the gNB in the form of Random Access Response (RAR).
The UE monitors for RAR by attempting to detect a DCI format 1_0 with
CRC scrambled by RA-RNTI/C-RNTI within a window configured by ra-ResponseWindow.
Case1: RA preamble was transmitted for BFR (using
CFRA)
ra-ResponseWindow
is picked from BeamFailureRecoveryConfig
Within RAR window,
UE monitors for RAR (PDCCH addressed to C-RNTI) on the search space indicated
by recoverySearchSpaceId of the SpCell.
Within RAR
window, if UE receives PDDCH addressed to C-RNTI, the UE considers the RA procedure
as successfully completed.
Case2: All other cases
In all other cases (if RA procedure
was not triggered for BFR), ra-ResponseWindow is picked from RACH-ConfigCommon.
Within the RAR window, the UE monitors
for RAR (PDCCH addressed to RA-RNTI).
If RAR contains a MAC subPDU with RAPID
equal to the transmitted preamble ID, then the UE considers RAR reception is successful.
Except for the case where RA procedure
is not initiated for “SI request”, the MAC RAR is included in the MAC subPDU
and it contains Timing Advance Command, UL Grant, and Temporary_C-RNTI as
shown below.
-
RAPID: Random Access Preamble IDentifier
detected by the network
-
Timing Advance Command:
Timing advance calculated by the network based on the received timing of the RA
preamble.
-
UL Grant:
Grant required for the UE’s subsequent UL transmission (Msg3)
-
Temporary_C-RNTI:
Temporarily used for communication between UE and the gNB for the rest of the
RA procedure
RAR UL grant contents are shown in the figure below.
For CFRA procedure, the UE after receiving RA response, considers the RA procedure as successfully completed.
For CBRA procedure, the UE transmits
Msg3 over PUSCH using UL grant received in MAC RAR and proceeds to the next step
(Contention Resolution)
In both Case1 and Case2 above, if PDCCH
(addressed to RA-RNTI/C-RNTI) is not received within RAR-Window i.e., ra-ResponseWindow
has expired, the UE considers the RAR reception as not successful and goes back
to “RA Resource Selection procedure”, and a preamble retransmission
may occur with higher transmit power.
Msg3 Transmission
For CBRA
procedure, the UE transmits Msg3 over PUSCH using UL grant received in the MAC RAR.
The UE includes an identity in the Msg3 which is used later in the process of
contention resolution.
The UE uses Temporary_C-RNTI
for the transmission of Msg3.
The contents of Msg3 varies
depending on whether the UE already has a C-RNTI or not as discussed below.
Case1: UE already had a C-RNTI
The UE may already
have a C-RNTI (e.g. UE in RRC_CONNECTED) at the time of RA procedure initiation.
The applicable cases and the associated Msg3 contents are given below.
- RA procedure was initiated for BFR – UE sends
C-RNTI MAC CE in Msg3.
- RA procedure was initiated by a PDCCH order (this
case is CBRA if the network sets the preamble ID in PDCCH order to 0b000000) - UE
sends C-RNTI MAC CE in Msg3.
- RA procedure was initiated by the MAC
sublayer itself or by the RRC sublayer – UE sends C-RNTI MAC CE in Msg3, in addition,
the following is applicable;
· In case of CBRA during synchronous RRC reconfiguration
(e.g. handover) - UE transmits RRCReconfigurationComplete message in
Msg3
· When UE needs to transmit uplink data and if
SR is not configured or SR failure or uplink Out-of-Sync – In this case, the UE
may also include BSR MAC CE to indicate buffer status to get appropriate uplink
resources from the network
Case2: UE didn’t have a C-RNTI
The UE sends
CCCH SDU in Msg3 if it didn’t have a C-RNTI (e.g.
during initial access) at the time of initiation of RA procedure. The
applicable cases and the associated Msg3 contents are given below.
- UE is transitioning from RRC_IDLE to RRC_CONNECTED
– UE sends RRCSetupRequest (UL CCCH) message in Msg3
- UE is transitioning from RRC_INACTIVE to RRC_CONNECTED
– UE sends RRCResumeRequest or RRCResumeRequest1 (UL CCCH)
message in Msg3
- During RRC Connection
Re-establishment procedure – UE sends RRCReestablishmentRequest (UL CCCH) message in Msg3
- When using CBRA for On-demand SI – UE sends RRCSystemInfoRequest
message in Msg3
Contention Resolution
Once
Msg3 is transmitted, the UE starts or restarts (applicable for Msg3 retransmission)
the timer ra-ContentionResolutionTimer and
monitor for PDCCH. The contention resolution procedure handling varies depending
on whether or not UE had a C-RNTI at the time of initiation of RA procedure.
Case1: UE already had a C-RNTI
The UE may already
have a C-RNTI (e.g. UE in RRC_CONNECTED) at the time of RA procedure initiation.
If the C-RNTI MAC
CE is included in Msg3, the network resolves contention just by transmitting
PDCCH addressed to UE’s C-RNTI (uplink grant or downlink assignment). At this
point, the UE considers that the RA procedure is successfully completed and
discards Temporary_C-RNTI.
Note that there
is no need for the network to explicitly transmit contention resolution information
in the downlink.
The UE considers
the contention resolution as not successful if it doesn’t detect PDCCH
addressed to C-RNTI during ra-ContentionResolutionTimer.
Case2: UE didn’t have a C-RNTI
In this case, as
the UE doesn’t have a valid C-RNTI, the gNB transmits Msg4 (“UE Contention
Resolution Identity MAC CE”) using Temporary_C-RNTI.
“UE Contention
Resolution Identity” MAC CE is identified by MAC subheader with Logical Channel
ID:62, fixed 48-bit size and consists of single field “UE Contention Resolution
Identity”. In this MAC CE, the gNB replays first 48-bits of UL CCCH SDU received
in Msg3.
If the received
contention resolution identity matches with the transmitted identity, the UE declares
contention resolution and thereby RA procedure as successful.
If the RA
procedure was initiated for On-Demand SI (SI request - CBRA case), the MAC
layer indicates the reception of an acknowledgement of SI request to upper layers.
After contention
resolution is successful, except for SI request case, the UE promotes the Temporary_C-RNTI
to C-RNTI.
If
there is no contention resolution identity received during ra-ContentionResolutionTimer,
the UE considers that the contention resolution not successful.
Note:
In both Case1 and Case2 above, if the contention resolution is not successful,
the UE discards Temporary_C-RNTI and goes back to “Random Access Resource
selection procedure” and retry RA procedure.
Reference:
3GPP TS 38.300, 38.321, 38.212, 38.213 and 38.331
