5G NR Implied Association between SSB

Index and RACH Occasion

Andrew Kolomatski

4G/5G RAN Solution Architect

There are multitude of resources online that explain and visualize the time and frequency domain
allocation and mapping of NR PRACH resources based on just two configuration parameters:

 ssb-perRACH-OccasionAndCB-PreamblesPerSSB
 msg1-FDM

rach-ConfigCommon
               SetupRelease : setup
               Setup
                 rach-ConfigGeneric
                   prach-ConfigurationIndex : 158
                   msg1-FDM : one
                   msg1-FrequencyStart : 0
                   zeroCorrelationZoneConfig : 14
                   preambleReceivedTargetPower : -104
                   preambleTransMax : n10
                   powerRampingStep : dB2
                   ra-ResponseWindow : sl20
                 totalNumberOfRA-Preambles : 24
                 ssb-perRACH-OccasionAndCB-PreamblesPerSSB : one
                 one : n24
                 ra-ContentionResolutionTimer : sf64
                 rsrp-ThresholdSSB : 19
                 prach-RootSequenceIndex : l139
                 l139 : 110
                 msg1-SubcarrierSpacing : kHz30

                 restrictedSetConfig : unrestrictedSet

The same multitude of resources describe the rules of SSB mapping to RACH Occasion and the
indexing order of such mapping. This article will not repeat this information and will point out
something new.

As of today, practically all 5G NR mid-band networks are configured with PRACH resources in
every frame, i.e. every 10ms in time domain. Let’s stick to this assumption for simplicity and
consider a couple of general cases below. Moreover, let’s include two more assumption to
simplify the efforts to make a point – let’s assume that we are working only with such PRACH
Configuration Indexes which imply:

 A single Subframe with PRACH resources per frame

In case of a single SSB per cell networks it is straightforward that RACH Occasion associated
with this single SSB is present in every frame and technically it may be configured that there
would be several PRACH Occasions for the same SSB per frame, for example by means of
setting msg1-FDM to two, four, or eight instead of one.

In case of multiple SSB’s per cell networks (up to 8 for mid-band) it is not that straightforward
and two subcases are possible:

1. When number of available RACH Occasions within one frame is sufficient to get them
mapped to all SSB’s of the cell, for example there are 6 SSB’s in the cell and 8 possible
RACH Occasions thanks to msg1-FDM : eight. Such sub-case is still straightforward.
2. When number of available RACH Occasions within one frame is not sufficient to get
them mapped to all SSB’s of the cell, for example there are 6 SSB’s in the cell and one
possible RACH Occasion thanks to msg1-FDM : one and ssb-perRACH-
OccasionAndCB-PreamblesPerSSB: one. Such sub-case is ambiguous and deserves
deeper insight.

And here’s finally the point. In the second ambiguous sub-case, we may rightfully guess that a
single RACH Occasion per frame is associated with one and only one SSB Index - one out of six
in our example. By the way the example with 6 SSB beams has been selected not randomly, but
because this is a very typical commercial network case nowadays.

But how can the NR UE know the mapping between SSB Index and RACH Occasion in this or
that specific frame? If the UE finds the strongest SSB beam, should it try performing random
access procedure in the very soonest RACH Occasion (i.e. frame in our example) or should it
hold out for a certain frame to do it because the very soonest frame is associated not with the
SSB Index the UE is trying to access but with another SSB Index?

The answers to these questions are not on the surface and not obvious because such association is
not explicitly configured with any parameter in the rach-ConfigCommon information element
from 3gpp 38.331. Though the association is IMPLIED and the UE is aware of the implication as
described in 8.1 Random Access Preamble of 3gpp 38.213:

An association period, starting from frame 0, for mapping SS/PBCH blocks to PRACH
occasions is the smallest value in the set determined by the PRACH configuration
period according Table 8.1-1 such that the index of SS/PBCH blocks are mapped at
least once to the PRACH occasions within the association period, where a UE obtains
the index of SS/PBCH blocks from the value of higher layer parameter ssb-
PositionsInBurst in SystemInformationBlockType1 and/or in
ServingCellConfigCommon. If after an integer number of SS/PBCH blocks to PRACH
occasions mapping cycles within the association period there is a set of PRACH
occasions that are not mapped to SS/PBCH blocks, no SS/PBCH blocks are mapped to
the set of PRACH occasions. An association pattern period includes one or more
association periods and is determined so that a pattern between PRACH occasions and
SS/PBCH blocks repeats at most every 160 msec. PRACH occasions not associated
with SS/PBCH blocks after an integer number of association periods, if any, are not
used for PRACH transmissions.

In our example where there are 6 SSB beams and the PRACH configuration period is 10msec
(based on our assumptions for simplification purposes, though both assumptions reflect a typical
commercial network configuration nowadays), the smallest necessary and sufficient association
period is 8 from the Table 8.1.-1. Based on that table, without explicit configuration, the UE
implies the following raster for PRACH resources:

There are two interesting observation in our example case:

1. If the UE is currently “located” in the system frame number (SFN), for example, 425 and
it suddenly wants to access the beam number 0 (SSB#0), it will have to hold off until
SFN 432 to do it. Yes, it will have to delay its random access attempt by 70msec! This is
a worst case example, though good for demonstration purpose.
 2. Even though the assumed PRACH Configuration allows for RACH Occasion each and
every frame, in fact in our example one quarter of the frames do not have RACH
Occasions because only 6 out of 8 PRACH configuration periods are in use from the
association period. By the way, the gNb can allocate PUSCH to those PRB’s generally
implied but actually not used in a specific network by PRACH, but this is beside the
point.

To shore up the point let’s consider another example, again, pretty much from the real
commercial world. Let’s change only one assumption – this time around the number of time-
domain PRACH occasions within a PRACH slot is 3 instead of 1. Technically it can be done by
using prach-ConfigurationIndex : 97 instead of prach-ConfigurationIndex : 158, for
example.

In this way every frame there are 3 RACH Occasions and there would be needed 2 consecutive
frames to accommodate RACH Occasions associated with all 6 SSB beams of our cell. And that
is a good news to the effect that there exists 3gpp valid association period 2 (see Table 8.1-1 of
38.213) resulting in all frames without exception being used for PRACH resource allocation.
And in the worst case scenario the UE will have to hold off until just a next frame to transmit its
preamble intended for the strongest beam. For example, if the UE is currently “located” in the
system frame number (SFN), 893 and it suddenly wants to access the beam number 0 (SSB#0), it
will have to hold off until as soon as SFN 894 to do it. Yes, it will have to delay its random
access attempt by just 10msec!

It is crucial to notice that there is no fixed universal predefined mapping between the SSB index
number and associated PRACH occasion. It is numerical order, or sequential number of the
present SSB beam that counts. For example, the hi-band cell contains 12 SSB wide beams out of
64 theoretically possible, and their indexes are not 0..11, but arbitrary positions like in the
example below, where index numbers are 4, 5, 10, 11, 12, 13, 20, 21, 26, 27, 28 and 29.

ssb-PositionsInBurst
longBitmap : '0000110000111100000011000011110000000000000000000000000000000000'B

For the purpose of PRACH occasion association, their indexes are compacted or sort of
compressed to be of numerical ascending order 0..11, so that all consecutive PRACH occasions
could be utilized without being skipped. This doesn't cause any ambiguity because both UE and
gNB know exactly how to interpret this concept because they both know that there are 12 beams
only and both know their exact indexes in ascending order. Yet the skipping of possible PRACH
occasions is possible (and very common in practice) in the cases where the number of beams is
fewer than the number of PRACH occasions within the assiciation period. Remember the
statement in 3gpp - PRACH occasions not associated with SS/PBCH blocks after an
integer number of association periods, if any, are not used for PRACH
transmissions. The system doesn't waste the UL resources where PRACH occasion is possible,
but not necessary due to lack of SSB beams, it just uses it for conventional PUSCH purpose.