Introduction
In the fast-evolving landscape of 5G technology, the procedures involving the Physical Random Access Channel (PRACH) and Medium Access Control (MAC) layers play a vital role in ensuring seamless communication between devices and the network. This article delves into critical updates to the 5G Physical and MAC Layer Procedures, highlighting advancements made in 2024. We will cover key aspects such as PRACH occasions, Random Access (RA) procedures, power control mechanisms, and the intricacies of contention resolution.
Understanding PRACH Occasions and Their Validity In 5G
Some PRACH occasions may not be valid if they collide with SS/PBCH Blocks or other downlink transmissions. This can cause the Association Period to change over time, and to consequently generate a pattern of Association Periods. 3GPP TS 38.413 specifies that a pattern of Association Periods must repeat with a maximum period of 160 ms. This repetition period is known as an Association Pattern Period.
Figure below illustrates an example of a 160 ms Association Pattern Period. In this example, the PRACH Configuration Period is 10 ms and the SS/PBCH Block transmission period is 80 ms. It is assumed that there are no valid Random Access occasions during radio frames that include SS/PBCH Block transmissions. It is also assumed that the uplink/downlink transmission pattern leads to even numbered radio frames having 8 Random Access occasions, and odd numbered radio frames having 6 Random Access occasions.
Adaptive Association Periods
It is further assumed that there are 8 SS/PBCH beams and that the number of SS/PBCH beams per Random Access occasion is 1. This means that each Association period requires a minimum of 8 Random Access occasions. The first Association Period is 40 ms and includes 20 Random Access Occasions. There are sufficient Random Access occasions to serve all SS/PBCH beams after 30 ms but previous study indicates that the Association Period must be 1, 2, 4, 8 or 16 PRACH Configuration Periods. The Association Period of 40 ms allows each SS/PBCH beam to be served twice, with 4 unused Random Access occasions at the end of the period.
In 5G The next Association Period is only 10 ms because the next PRACH Configuration Period includes 8 Random Access occasions which are sufficient to serve all SS/PBCH beams. The Association Periods continue to vary throughout the 160 ms time window. At the end of the 160 ms time window, there is a single PRACH Configuration Period with 6 Random Access occasions. These arc insufficient to serve all 8 SS/PBCH beams so they are left unused. The Association Pattern then repeats during the next 160 ms.
PRACH Preamble Power Control In 5G MAC Layer
A UE determines the PRACH preamble transmit power using an open loop power control calculation based upon a downlink path loss measurement. The MAC layer completes the first part of the calculation using the following expression.
Key Parameters in Power Control in 5G
preambleReceivedTargetPower is provided to the UE within the RACH-ConfigCommon parameter structure. Its minimum value of - 202 dBm is significantly lower than a normal received power level. This extremely low value has been specified to cater for Supplemental Uplink scenarios which involve the UE measuring the downlink path loss in one band and transmitting the uplink PRACH in another band. For example, a UE could measure the downlink path loss at 70 GHz while configured to transmit the PRACH using a Supplemental Uplink at 700 MHz. In this case, the downlink path loss measured at 70 GHz is significantly greater than the uplink path loss at 700 MHz. The combination of air-interface propagation loss and building penetration loss could be more than 70 dB higher at 70 GHz when compared to 700 MHz. Configuring a very low value for the preamble received target power helps to ensure that the UE transmits at a power level which is appropriate for the lower operating band. The Base Station will then receive a 'normal' uplink power because the very low target power has compensated for the path loss difference.
DELTA_PREAMBLE represents a power offset which adjusts the P'RACH Preamble received power requirement according to the PRACH sequence duration. Its value is extracted from a look-up table standardised by 3GPP within TS 38.321. This look-up table is shown in Table below. Preamble Format 0 has a sequence which spans 800 μs and is used as the baseline. The sequences belonging to Preamble Format 1 span 1600 μs so the received target power is reduced by 3 dB. Similarly, the sequences belonging to Preamble Formats 2 and 3 span 3200 μs and 800 μs so power offsets of 6 dB and 0 dB are applied.
The same principle is applied for the short PRACH Preamble Formats. For example, the sequence belonging to PRACH Preamble Format A 1 occupies 2 x 2048 x T = 133.33 μs when using the 15 kHz subcarrier spacing. Comparing this result to the duration of Preamble Format 0 generates a ratio of  10 x LOG(800 / 133.33) = 8 dB. An additional 3 dB is added each time the subcarrier spacing doubles due to the time duration halving.
PRACH Counters and Logic In 5GÂ
A UE maintains two counters when transmitting a series of PRACH preambles : PREAMBLE_TRANSMISSION_COUNTER and PREAMBLE_POWER_RAMPING_COUNTER. The former is used to limit the total number of PRACH preamble transmissions within a single Random Access procedure, whereas the latter is used to control the ramping of the PRACH Preamble transmit power (visible within the equation shown above). Figure below illustrates the logic applied to maintain these counters. Both counters are initialised with a value of I at the start of the random access procedure.
PREAMBLE_POWER_RAMPING_COUNTER is incremented prior to calculating the PRACH Preamble transmit power if three conditions are satisfied. The first condition verifies that a PRACH preamble has already been transmitted at least once, i.e. a counter value of 1 is used for the first transmission. The second condition checks whether or not the Physical layer has provided an instruction to suspend power ramping. The Physical layer In 5G suspends power ramping if the UE changes its uplink transmit beam. The Physical layer In 5G can also suspend power ramping if the uplink transmit power is restricted by other transmissions, e.g. due to uplink power being allocated to LTE when using the Non-Standalone Base Station architecture. The third condition checks whether or not the UE has selected another Base Station beam, i.e. the UE has selected another SS/PBCH Block.
PREAMBLE TRANSMISSION_COUNTER is incremented if a Random Access Response has not been received within the time window defined by ra-Response Window, i.e. it is assumed that the Base Station has not received the PRACH Preamble so another attempt is required if the maximum number of permitted attempts has not been reached. PREAMBLE_TRANSMISSION_COUNTER is also incremented if the Contention Resolution phase of the Random Access procedure fails.
Returning to the calculation for PREAMBLE_RECETVED_TARGET _POWER, preamblePowerRampingStep can be configured with either a 'normal' value or a 'high priority' value. The 'normal' value is provided to the UE within the RACH-ConfigCommon parameter structure shown in Table below (powerRampingStep parameter). The 'high priority' value can be used to override the 'normal' value when it is necessary to minimise latency, i.e. the 'high priority' step size can be configured with a higher value to allow more rapid power ramping.
The 'high priority' value is provided to the UE using the RA-Prioritization parameter structure shown in Table below, i.e. powerRampingStepHighPriority. This parameter structure can be used when configuring the UE for Beam Failure Recovery or when providing the UE with Contention Free Random Access resources.
Random Access Procedure: PRACH Preamble Transmission
Once, the MAC layer has calculated PREAMBLE RECEIVED TARGET POWER, the result is passed to the Physical layer which then calculates the PRACH preamble Transmit power for transmission occasion 'i' using uplink bandwidth part 'b', carrier 'f and serving cell 'c', according to:
PcMAX,f,c is the configured maximum UE transmission power. The UE calculates Path_lossb,f,c as referenceSignalPower RSRP, where referenceSignalPower is provided by the Base Station, e.g. using ss-PBCH-BlockPower within SIB 1 when using an SS/PBCH Block as a reference signal. Layer 3 filtering is applied to the RSRP measurement before calculating the path loss.
The UE also calculates an RA-RNTI which is subsequently used to address the UE on the PDCCH when allocating the PDSCH resources for the Random Access Response. The RA-RNTI is calculated according to the following expression:
RA-RNTI Calculation In 5GÂ
The RA-RNTI is calculated based upon time domain and frequency domain indices associated with the PRACH occasion. It is not dependent upon the selected PRACH Preamble. This means that all UE using the same PRACH occasion will calculate the same RAÂ RNTI, i.e. they all decode the same PDCCH and the same corresponding PDSCH. The equation shown above generates an RA-RNTI within the range from 1 to 1792
MAC Layer Operations In 5G: Random Access Response
The UE then proceeds to transmit the PRACH Preamble using the selected PRACH occasion and the calculated transmit power. The Random Access Response window (defined by ra-ResponseWindow) starts from the first Random Access Response CORESET that follows the end of the PRACH Preamble transmission by at least one symbol. The Random Access Response CORESET is identified using the Type 1 Common Search Space (CSS) configuration (defined by ra-SearchSpace). The UE monitors this CORESET for a DCI Format 1_0 which has its CRC bits scrambled by the RA-RNTI
If the Random Access Response window expires before the UE receives a DCI Format 1_0, the UE transmits another preamble using the logic.
If the UE receives a DCI Format 1_0 which has its CRC bits scrambled by the RA-RNTI, the UE proceeds to decode the Transport Block (MAC PDU) within the corresponding PDSCH resource allocation. The MAC PDU can include up to three different types of MAC sub-PDU. The first is used to specify a Back-Off Indicator, the second is used to acknowledge a request for On-demand System Information, and the third is used to provide a Random Access Response. The structure of these MAC sub-PDU within a MAC PDU is illustrated in Figure below.
At this point, the UE is addressed by its Random Access Preamble Identity (RAPID). The RAPID field occupies 6 bits which provide range from 0 to 63, i.e. corresponding to the set of 64 PRACH Preambles within the PRACH occasion identified by the RA-RNTI If a contention has occurred and multiple UE have selected the same PRACH Preamble, then multiple UE will have the same RAPID value.
Figure below illustrates the structure of each MAC subheader and the Random Access Response.The Back-Off Indicator subheader is not addressed to a specific RAPID. All UE store the value of the Back-Off indicator if it is included within the MAC PDU. This does not mean that all UE will use the Back-Off Indicator- only those UE which do not receive a MAC subheader with a matching RAPID will be required to apply the Back-Off Indicator before transmitting another PRACH Preamble. The Back-Off Indicator is used to help manage congestion during periods of high load. Table below presents the set of Back-Offvalues standardised by 3GPP.
The 'Extension' (E) field is used to indicate that the MAC PDU includes another MAC sub-PDU. The 'Type' (T) field is used to differentiate between MAC subheaders which include the Back-Off Indicator and MAC subheaders which include the RAPID field.
The MAC sub PDU which includes a RAPID field but does not include a Random Access Response(RAR) is used to acknowledge a Physical layer request for On-demand System Information (in contrast to an RRCSystemlnfoRequest at Layer 3). In this case, the UE knows that it should not expect a Random Access Response to follow the MAC sub header.
The MAC sub-PDU which includes a Random Access Response provides the UE with a Timing Advance Command, an Uplink Grant and a Temporary C-RNTI (TC-RNTI). The Timing Advance Command is used to synchronise the uplink transmission timing of the UE at the Base Station receiver, i.e. to compensate for propagation delays which depend upon the UE location within the cell. Utilisation of the 12 bit Timing Advance Command is described.
The Temporary C-RNTI (16 bits) is used to address the UE on the PDCCH when subsequently allocating the PDSCH resources for MSG4, i.e. during Contention Resolution
The Uplink Grant uses a total of 23 bits to provide an uplink resource allocation on the PUSCH for the transmission of MSG3.This avoids the requirement to allocate uplink resources using the PDCCH. The 'Frequency Hopping' flag indicates whether or not the UE should apply Frequency Hopping. When the flag indicates that Frequency Hopping is to be used, 1 or 2 bits from the 'Frequency Resource Allocation' field are used to specify the frequency offset for the 2nd hop. 1 bit is used if there are less than 50 Resource Blocks within the Bandwidth Part. Otherwise, 2 bits are used.
The 'Frequency Resource Allocation' uses Uplink Resource Allocation Type 1. The Random Access Response allocates 14 bits to the 'Frequency Resource Allocation' whereas the number of bits required by Uplink Resource Allocation Type 1 is: [LOG2 (N%fP x (NffP + 1) / 21 bits. This means that one or more bits can be ignored when the Bandwidth Part size is less than 180 Resource Blocks, i.e. if LOG2 (180 x (181) / 21 = 14 bits. In contrast, padding bits are added when the Bandwidth Part size is greater than 180 Resource Blocks.
The 'Time Resource Allocation' uses a set of 4 bits to specify a pointer towards a row within a look-up table. The look-up table can be a table configured by the Base Station, or a table standardised by 3GPP. The Base Station can configure a table using the pusch TimeDomainAllocationlist parameter structure within pusch-ConfigCommon. This table is applied if it has been configured. Otherwise, the 'Default A' table standardised by 3GPP is applied.
The 'MCS' field is limited to 4 bits so MSG3 is restricted to being allocated an MCS from the first 16 rows of the relevant MC Stable. MSG3 is able to use either the '64 QAM' MCS table or the '64QAM with Transform Precoding' MCS table. The value of msg 1 transform Pre coder within RACH-ConfigCommon determines which MCS table is applied.
The 'Transmit Power Control (TPC) Command' specifies a pointer to a row within the look-up table presented in Figure below. ThisTPC Command is used when calculating the PUSCH transmit power for MSG3.
The 'Channel State Information(CSI) Request' field is reserved when using the Contention Based Random Access procedure.This field can be used to request an aperiodic CSI report when using the Contention Free Random Access procedure.
The UE then proceeds to transmit MSG3 on the PUSCH using the allocated resources and at the calculated transmit power. If contention has occurred and multiple UE have decoded the same uplink resource allocation then all of those UE will transmit their MSG3 using the same PUSCH resources.
Figure below illustrates the structure of MSG3 when transferring a CCCH message. This is applicable to UE making the transition from RRC Idle or RRC Inactive to RRC Connected, i.e. the CCCH message can be an RRCSetupRequest or RRCResumeRequest. It is also applicable to UE re-establishing an RRC Connection and UE requesting On-demand System Information. In general, these messages have a size of 6 bytes but the RRCResumeRequest 1 message includes the full 1-RNTI and has a size of 8 bytes. The header field does not include an explicit length indicator but the Logical Channel Identity (LCID) is used to indicate both the payload type and payload length. A value of '0' indicates a CCCH message with a length of 64 bits, whereas a value of '52' indicates a CCCH message with a length of 48 bits.
Figure. below illustrates the structure of MSG3 when transferring a DCCH or DTCH message. This could be applicable to a UE completing a handover procedure, i.e. the DCCH message could be an RRCRconfigurationComplete used to indicate completion of the handover (although handovers typically use the Contention Free Random Access procedure). MSG3 could include DTCH content if the Random Access procedure has been triggered by uplink data arrival while the UE is out-of-sync
MSG3 includes a C-RNTI MAC Control Element when used to transfer a DCCH or DTCH message. This MAC Control Element is placed at the end of the MAC PDU. In this case, Contention Resolution is based upon the C-RNTI provided by the UE within MSG3, rather than the Temporary C-RNTI provided by the Base Station within MSG2. The Logical Channel Identity (LCID) value of 58 indicates that the subsequent 2 bytes arc the C-RNTI.
The first MAC sub header illustrated in Figure below identifies the DCCH or DTCH logical channel. 3GPPTS38.33I specifies default logical channel identities of 1, 2 and 3 for SRB 1, 2 and 3. Higher values can be allocated to DTCH logical channels. DCCH and DTCH payloads have variable length so the MAC sub header includes a length field which can have a length of I or 2 bytes (Figure below illustrates an example based upon 1 byte). The 'Format' (F) flag is used to indicate whether the Length field is 1 or 2 bytes.
The UE starts its Contention Resolution timer after the transmission of MSG3. This timer is configured within RACH-ConfigCommon using the ra-ContentionResolutionTimer parameter. It can be configured with values between 8 and 64 subframes, i.e. 8 and 64 ms. The Contention Resolution timer is maintained at the MAC layer. The RRC layer may also start a supervision timer depending upon the content of MSG3. For example, if MSG3 contained an RRCSetupRequesl message then the RRC layer starts T300. Alternatively, if MSG3 contained an RRCReestablishmentRequest then the RRC layer starts T301. If MSG3 contained an RRCResumeRequest or RRCResumeRequest 1 then the RRC layer starts T319.
The UE monitors the CORESET belonging to the Type 1 Common Search Space (defined by ra-SearchSpace) while the Contention Resolution timer is running. If the UE used MSG3 to transfer a CCCH message, then the UE attempts to decode a PDCCH transmission which has its CRC bits scrambled by the allocated Temporary C-RNTI (TC-RNTI). The UE may receive a PDCCH with a DCI Format 0 which allocates PUSCH resources for a re-transmission of MSG3, or the UE may decode a DCI Format 10 which allocates PDSCH resources for MSG4. Figure below illustrates the reception of DCI Format 1_0 allocating the PDSCH resources for MSG4.
MSG 4 includes the 'UE Contention Resolution Identity' MAC Control Element illustrated in Figure below.This MAC Control Element includes the first 48 bits belonging to the uplink CCCH SDU within MSG3. The UE uses this MAC Control Element to detennine whether or not the Random Access procedure has been successful. The procedure has been successful if the content of the MAC Control Element matches the content of the CCCH SDU transmitted by the UE. If the content docs not match then it means that contention has occurred and the MAC Control Element is intended for a different UE. In this case, the UE returns to the transmission of PRACH Preambles (assuming the maximum number of PRACH preamble transmissions has not been reached).
If contention resolution is successful, the Temporary C-RNTI becomes the allocated C-RNTI. In addition, the UE uses the PUCCH to transmit a HARQ acknowledgement for MSG4. At this stage, the UE does not have dedicated PUCCH resources, so the UE relies upon a set of common resources defined by PUCCH-Config Common provided within either SIBI or dedicated signalling.
If the UE used MSG3 to transfer a DCCH or DTCH message, them the UE attempts to decode a PDCCH transmission which has its CRC bits scrambled by the C-RNTI which was included in MSG3. This scenario is illustrated in Figure below. In this case, contention resolution is successful if the UE receives a PDCCH transmission which has its CRC bits scrambled by the C-RNTI.
Figure below illustrates an example 5G random access procedure which includes are-transmission of MSG3. The Base Station triggers the re-transmission using DCI Format 0_0 to provide an uplink resource allocation on the PUSCH. The CRC bits belonging to the DCI are scrambled using the Temporary C-RNTI. The Contention Resolution timer is re-started after re-transmitting MSG3, whereas the RRC supervision timer is not re-started.
3GPP references: TS 38.321, TS 38.331, TS 38.213, TS 38.214, TS 38.212
Conclusion
The updates made to the 5G Physical and MAC Layer procedures in 2024 enhance the flexibility and efficiency of the Random Access Procedure, addressing key challenges such as power control in multi-band scenarios, contention management, and adaptive association patterns. These advancements, standardized in 3GPP TS 38.321, TS 38.331, and related specifications, ensure that 5G networks can meet the high demands of modern communication systems, improving reliability and reducing latency in critical applications.
Â
References
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Comments