Introduction To 5G Radio Network Planning
In the fast-paced world of 5G, effective 5G RADIO NETWORK PLANNING is crucial, especially when dealing with high-speed mobility scenarios. This article, part 7 in our series, explores the intricacies of high-speed flag configurations in PRACH (Physical Random Access Channel) and the challenges of Root Sequence Index planning. Understanding these aspects is key to optimizing network performance, particularly in environments where mobility and frequency offsets pose significant challenges.Â
High Speed Flag
In 5G Radio Network Planning The high speed flag is only applicable to the long PRACH Formats, i.e. it cannot be applied when using Frequency Range 2. It is configured using the restrictedSetConfig information element presented in Table below. Configuring a value of 'unrestrictedSet' indicates support for low to medium mobility scenarios, while configuring values of 'restrictedSetTypeA' or 'restrictedSetTypeB' indicates support for high and very high mobility scenarios respectively.
Impact of Frequency Offsets on PRACH Performance
3GPP has introduced the concept of "Restricted Sets' to mitigate the impact of the Doppler frequency offsets which can be experienced when travelling at high speed. Frequency offsets have a negative impact upon PRACH performance by generating additional peaks in the auto-correlation function. The use ofRestricted Sets reduces the number of cyclic shifts which can be applied to each Root Sequence to ensure that there is no ambiguity between the wanted auto-correlation peaks and the unwanted auto-correlation peaks.
The Unrestricted Sets are intended for use with frequency offsets which do not exceed half of the subcarrier spacing.' TypeA' Restricted Sets arc intended for use with frequency offsets which do not exceed the subcarrier spacing, whereas 'Type B' Restricted Sets are intended for use with frequency offsets which do not exceed twice the subcarrier spacing.
Restricting the set of cyclic shifts to mitigate the impact of a frequency offset. Different Root Sequences exhibit different patterns of unwanted auto-correlation peaks. This leads to different Root Sequences supporting different numbers of permitted cyclic shifts.
When using the Unrestricted set of cyclic shifts, the number of preamble sequences generated from each Root Sequence is constant. This makes it relatively easy to group the Root Sequences when allocating them to individual cells. When using a Restricted set of cyclic shifts, the number of preamble sequences generated from each Root Sequence is no longer constant and this complicates the allocation of Root Sequences. In addition, the use of Restricted cyclic shifts reduces the number of preamble sequences which can be generated from each Root Sequences. This reduces the Root Sequence re-use pattern size and increases the potential for Root Sequence collisions.
Root Sequence Index
Root Sequences are used to generate the set of 64 PRACH preambles belonging to each PRACH occasion. The number of preambles which can be generated from each Root Sequence depends upon the Zero Correlation Zone. Figure below illustrates an example based upon cells which require 10 Root Sequences to generate their 64 PRACH preambles. The means that each cell is allocated 10 Root Sequences.
The RRC signalling protocol is used to specify the first Root Sequence belonging to each cell.This is done using the PRACHÂ Root Sequence index within the RACH-Config Common parameter structure. Which can be broadcast within SBI 1 or provided to the UE using dedicated signalling. The UE and Base Station use consecutive additional Root Sequence Indices to generate the complete set of 64 PRACH preambles.
The allocated Root Sequence Index and the consecutive additional Root Sequence Indices refer to 'logical' Root Sequence Indices. 3GPP TS 38.211 provides a look-up table to map logical Root Sequence Indices onto physical Root Sequence Indices. This mapping means that the actual physical Root Sequences arc not consecutive. However, from the perspective of Radio Network Planning and UE signalling it is only necessary to consider the logical values.
Root Sequence Indices should be allocated to cells with a re-use distance which ensures that a specific cell never receives PRACH transmissions from a UE which is using the same Root Sequence within another cell. Root Sequence Index collisions generate unnecessary PRACH load and poor PRACH performance. If multiple cells using the same Root Sequence receive a PRACH preamble from a UE, then both cells will respond with a MSG2 transmission. The UE will respond to one of those cells with MSG3, while the other cell will record a failure between MSG 1 and MGS3. This increased PRACH load and poor PRACH performance may not impact the end-user experience but nevertheless this scenario should be minimised in live network deployments.
Challenges in Root Sequence Planning
Figure below illustrates the criteria used to allocate the set ofRoot Sequence Indices. The PRACH Preamble Format should be considered as the first criteria because it determines the total number ofRoot Sequences available for planning. Long PRACH Formats support 838 Root Sequences. whereas short PRACH Formats support only 138 Root Sequences.
Generating a Root Sequence Index plan is relatively challenging when only 138 Root Sequences are available (after accounting for the fact that each cell will normally require multiple Root Sequences). In the case of Frequency Range 2, the higher air-interface attenuation helps to avoid Root Sequence Index collisions. In the case of Frequency Range 1, the deployment of small cells with restricted coverage areas can help to avoid Root Sequence Index collisions. Otherwise, the deployment of macrocells in Frequency Range I will be simplified if long PRACH Formats are configured to allow the use of 838 Root Sequences.
The Root Sequence Index Planning strategy determines the solution for multiplexing PRACH resources across a group of cells.Two example strategies are illustrated in Figure below. The first strategy allocates the same Root Sequence Index to all cells belonging to the same Base Station. Those cells are then isolated in the time and frequency domains by configuring different combinations of prach Configuration Index and msg1-FrequencyStart. This strategy increases the Root Sequence re-use distance and reduces the potential for Root Sequence collisions. A potential drawback associated with this strategy is the introduction of PUSCH to PRACH inter-cell interference, i.e. relatively high power PUSCH transmissions in 01e cell can generate interference towards PRACH transmissions in a neighbouring cell.
This first strategy could be extended by allocating the same Root Sequence to a cluster of Base Stations, assuming that all cells within that cluster are allocated different combinations of prach-ConfigurationIndex and msg1-FrequencyStart.
The second strategy illustrated in Figure below allocates a different Root Sequence Index to each cell within the re-use distance. This allows each cell to be configured with the same PRACH time and frequency resources, i.e. cells are multiplexed in the code domain rather than the time and frequency domains. This approach has the potential benefit of maintaining only PRACH to PRACH inter-cell interference.
This second example highlights the potential challenge associated with Root Sequence Index planning when only 138 Root Sequences arc available, i.e. a cluster of only four 3-sector Base Stations have already consumed 120 Root Sequences. A fifth Base Station would have to start re-using some of the already allocated Root Sequences and there would be a risk of inadequate isolation between cells using the same Root Sequence
If Root Sequence planning becomes challenging due to a small re-use distance, it is possible to increase the re-use distance by restricting the number of PRACH preambles belonging to each PRACH occasion. For example, the number of Root Sequences required per cell can be reduced by a factor of 2 if the number of preambles per PRACH occasion is restricted to 32 rather than 64. This solution reduces PRACII capacity but allows easier Root Sequence planning.
The UE mobility requirement can have a significant impact upon Root Sequence Index planning. If the mobility requirement forces the use of a 'Restricted' set of cyclic shifts then Root Sequence planning becomes more challenging in terms of:
The number of PRACH preamble sequences which can be generated from each Root Sequence is reduced so the Root Sequence re use distance becomes smaller and there is increased potential for collisions.
The number of PRACH preamble sequences generated from each Root Sequence is no longer constant. This means that instead of allocating evenly spaced Root Sequences, e.g. 0, 10, 20, 30,... etc, it will be necessary to allocate unevenly spaced Root Sequences, e.g. 0, 10. 26, 38, etc.
PRACH Frequency Offset
The PRACH frequency offset determines the position of the PRACH occasions in the frequency domain. A cell can be configured to use a single PRACH occasion in the frequency domain, or can be configured to use up to 8 frequency multiplexed PRACH occasions. Frequency multiplexed PRACH occasions occupy a contiguous set of Resource Blocks.
The RRC signalling protocol is used to specify the frequency domain position of the first Resource Block belonging to the first PRACH occasion. This is done using the msg1-FrequencyStart information element. The number of frequency multiplexed PRACH occasions is specified using the msg1-FDM information element. Both of these information elements are presented in Table below. They can be provided to the UE in SIB 1 or can be provided using dedicated signalling.
Figure below illustrates the principle of frequency multiplexing PRACH occasions. msg1-FrequencyStart specifies a Resource Block within the active uplink Bandwidth Part. The number of Resource Blocks occupied by each PRACH occasion depends upon the subcarrier spacings of both the PRACH and the PUSCH. The PRACH occupies 6 Resource Blocks when using the 1.25 kHz subcarrier spacing if the PUSCH uses the 15 kHz subcarrier spacing.
In all cases, the PRACH docs not fully occupy the set of allocated Resources Blocks, i.e. there is a guard band either side of the PRACH transmission. The bandwidth occupied by a PR/I.CH transmission when using a long PRACH Format. Similarly, the bandwidth occupied by a PRACH transmission when using a short PRACH Format.
The main objective when configuring the PRACH frequency offset (msg1-FDM) is to avoid fragmentation of the Resource Blocks available to the PUSCH, i.e. the PRACH should be positioned to one side of the Bandwidth Part. The Packet Scheduler is permitted to allocate non-contiguous Resource Blocks for the PUSCH but with certain restrictions. These restrictions mean that it remains preferable to avoid fragmentation of the Resource Blocks available to the PUSCH:
When using Frequency Range 2, it is mandatory to allocate contiguous Resource Blocks for the PUSCH.
When using Frequency Range I, it is mandatory to allocate contiguous Resource Blocks for the PUSCH when Transform Proceeding is enabled (the DFT-S-OFDM waveform is used).
When using Frequency Range I, it is permitted to allocate non-contiguous Resource Blocks for the PUSCH when Transform Precoding is disabled (the CP-OFDM waveform is used). However, the non-contiguous Resource Blocks must satisfy the conditions for being categorised as 'almost contiguous'.
Â
Neighbour Planning
Cell specific neighbour definitions are not required for cell re selection unless it is necessary to either blacklist a specific cell or apply a measurement power offset to a specific cell. Measurement power offsets can be used to make individual cells appear either more or less attractive for cell re selection.
SIB3, SIB4 and SIB5 can be used to broadcast cell specific information for intra-frequency, inter-frequency and inter-system cell re selection. SIB4 and SIB5 also broadcast the carriers available for inter-frequency and inter-system cell re selection. The release 15 version of the JGPP specifications allows inter-system re selection towards LTE but not towards UMTS. CDMA2000 nor GSM
Within the LTE system, SIB24 is used to broadcast carrier information for cell re selection towards NR
Cell specific neighbour definitions are required when completing intra-frequency, inter-frequency and inter-system handovers.They are also required when adding a Secondary Cell Group serving celI, or when completing serving cell change procedures, e.g. changing the primary SCG cell for an EN-DC Non-Standalone Base Station connection. Similar to cell re selection, the release 15 version of the 3GPP specifications provides support for inter-system handovers towards LTE, but not towards UMTS, CDMA2000 nor GSM.
Table below summarises the requirement for neighbour relations as a function of the Base Station architecture.The EN-DC configuration is assumed for the Non-Standalone Base Station architecture.
In the case of an EN-DC Non-Standalone Base Station:
An LTE Base Station to NR Base Station neighbour relation is required to allow the setup of an X2 connection between the two Base Stations. This neighbour relation links a pair of Base Stations rather than a pair of cells. If each NR Base Station is co-sited with an LTE Base Stations then a neighbour relation should be configured from the LTE Base Station towards the co-sited NR Base Station. In an ideal RF environment, this single neighbour relation would be sufficient because the co-sited NR cells would always be dominant. In reality, the RF environment may lead to neighbouring NR Base Stations providing dominance. In this case, neighbour relations should also be configured rrom the LTE Base Station towards neighbouring NR Base Stations.
An LTE cell to NR cell neighbour relation is required to add the primary Secondary Cell Group (SCG) cell, i.e. when a UE is connected to a specific LTE cell, there is a requirement to add a specific NR cell for the EN-DC connection. IfNR Base Stations are co-sited with LTE Base Stations then the minimum requirement would be to configure a neighbour relation with the co-sector NR cell. It would also be recommended to configure neighbour relations with NR cells belonging to the adjacent sectors. This would allow EN-DC connections to operate across sectors in case the LTE and NR antenna have different azimuths. If X2 connections have been setup with neighbouring NR Base Stations then LTE cell to NR cell neighbour relations should also be configured towards those neighbouring NR Base Stations.
NR to LTE neighbour relations are not necessary for EN-DC connections, based upon the assumption that the Master Node (the LTE Base Station) is responsible for initiating the setup of the X2 connections between the NR and LTE Base Stations. The LTE Base Station is required to add NR cells for the EN-DC connection but the NR Base Station is not required to add LTE cells.
NR cell to NR cell neighbour relations can be used to change the primary SCG cell. This cell change could be either intra-BTS or inter-BTS. As a minimum, neighbour relations should be defined towards the adjacent NR sectors. It may be beneficial to also define neighbour relations towards the NR cells belonging to neighbouring Base Stations.
LTE to LTE neighbour relations are required for the EN-DC Base Station configuration to allow handovers between primary serving cells. However, it is not necessary to configure new neighbour relations for this purpose if the LTE network already has a set of neighbours configured.
PCI checks should be completed during the neighbour addition process to ensure that the PCI plan does not generate PCI collisions nor PCI confusion.
It is possible to configure neighbour relations using Self OrganisingNetwork(SON) functionality, i.e, UE based Automatic Neighbour Relations (ANR) function can be used to populate a set of neighbour relations without the requirement for any manual planning. UE based ANR generates neighbour lists based upon measurement reports from the UE. Otherwise, neighbours must be defined by the planner, or generated by a planning tool. lJE based ANR may not be possible for the Non-Standalone Base Station architecture. For example, in the case of EN-DC. If the NR Base Station docs not broadcast SIB 1 then the UE will be unable to report a Cell Global Identity. In addition, if the NR Base Station is not connected to the MME then the MME will be unable to retrieve the transport layer address for X2 setup between the LTE and NR Base Stations.
Conclusion
Effective 5G RADIO NETWORK PLANNING is critical to ensuring optimal network performance, particularly in high-speed and high-mobility scenarios. Understanding the complexities of high-speed flag configurations, Root Sequence Index planning, and neighbour planning is essential for optimizing PRACH performance and minimizing the impact of frequency offsets. As 5G technology continues to evolve, staying informed about these aspects will be crucial for network planners and engineers alike.
Â
References
Â
Â
Â
Â
Â
Â
Â
Â
Â
Comments