Behind the new SI scheduling enhancement: why it’s needed and how it works

In recent years, cell broadcasting (in simple terms, the broadcasting of information to all permitting mobile devices within range of a cellular radio) has become an important tool of public warning systems.

For example, those residing in South Korea, Greece, or the Netherlands, are likely to have already received many public warnings over the 5G system through the course of the pandemic. Likewise, if you happened to be in the UK on their first ever nationwide cell broadcast trial in late April of this year. Japan, another example, has been using cell broadcasting technologies for many years to warn of public safety threats, such as earthquakes, tsunamis, and even missile alerts.

This is one use case of cell broadcasting, but it’s not the only one. On the contrary, cell broadcasting is expected to play a key role in enabling advanced services such as cellular positioning, vehicle-to-anything (V2X) and Industrial IoT systems.

However, legacy system information (SI) scheduling solutions supporting the broadcasting are not flexible enough to support the increased frequency and range of transmissions. That’s because, as the amount of information that can be broadcast is limited, any increase in transmission frequency would mean a much bigger risk of signaling collision.

Below, we take a closer look at those challenges and explore how the new Ericsson-proposed 3GPP system information (SI) scheduling enhancement can offer the flexibility required to scale broadcast signaling use cases.

5G broadcasting vs unicasting: the basics

Before we get into the technical aspects, let’s cover the basics. One of the most fundamental aspects of the 5G New Radio (NR) standard is the provision of system information (SI) to mobile devices via broadcast signaling, as you can see in the figure below.

The system information is needed for mobile devices not only to perform essential tasks such as selecting a suitable cell, initiating a connection to the network but also to support value added services such as positioning, V2X, or Industrial IoT features.

Above: Network broadcasting of various system information (SI) messages

Broadcast is suitable when several users need the same information. Sending the same information individually to each device (known as unicasting) consumes significant network resources as it requires all devices to connect to the network, which can be saved by using broadcast. Another strong advantage of using broadcast communication is that it can save power in the device itself since broadcast information can be received while the device is idle or inactive mode of operation.

To find out more about the benefits of multicast-broadcast vs unicast communication, read this earlier Ericsson blog post on 5G multicast-broadcast for group communication.

Historical disadvantages of using broadcast services

So, there are clearly many benefits for using broadcasting communication services in some use case scenarios, but are there any downsides?

Probably the biggest disadvantage is that there is a limit to how much system information can be broadcast. For reasons that we will explain in the next section, this gives rise to two problems that will develop as the amount of system information grows as expected in coming years:

• Firstly, resources for different broadcast messages can collide, which means not all messages will be transmitted.
• Secondly, network resources are not fully utilized even when there are resources available for message transmission

This required the development of a solution that could mitigate these challenges. Of the many possible routes to solve the problem, it’s important that any eventual solution would be capable of delivering the least possible impact on device implementation to avoid excessive development and verification costs, as well as a long interoperability development testing (IODT) phase.

The solution we at Ericsson developed and proposed for standardization is an enhancement of the existing scheme that solves the problem in an efficient way with limited impact on implementation.

System information scheduling: how it works

Let’s get a little more technical and take a look at how the legacy scheduling solution has worked up until now.

The system information is held in system information blocks (SIBs), each SIB with specific content to support the mentioned functionality.

According to its original design, 5G NR provides the system information block to mobile devices based on the following logic:

4. SIBs are carried in SI messages that are transmitted to the mobile device via broadcast signaling. Each SI message has its own periodicity and is sent within its own SI window which has a certain length as shown in the figure below. Note that all SI-messages must have the same SI-Window length.
5. The network may map several SIBs into one SI message if they are to be sent out with the same periodicity and if the maximum SI messages size allows. The maximum size of an SI message is 2976 bits
6. The scheduling algorithm allocates a consecutive start position of each SI message in the scheduling list. The first SI message is sent in the first SI window, the second SI message in the second SI window, and so on.
7. To ensure that all the mobile devices in the cell coverage area are able to acquire and successfully decode each SI message and thus improve service reliability, each SI message can be repeated within the SI window.

A 5G network can transmit up to a maximum of 32 SI-messages, but in practice the number of schedulable messages is much lower as explained in the next section.

Above: SI Message Repetitions within SI-Window and Periodical Occurrence

Unpacking the problem: challenges presented by legacy system information scheduling

This is all straightforward and effective, however there are some challenges presented by this legacy solution.

When the network needs to transmit many SI messages, a bottleneck is observed in the scheduling algorithm. In practice the maximum number of SI messages that can be scheduled is limited to the following formula:

Number of SI = shortest SI Periodicty / SI window length

This means that, for example, if the case of a real deployment 5G NR configuration (mid-band) where the shortest SI periodicity is 160ms and SI window length is 20ms, only 8 SI messages can be scheduled in practice.

Below, we evaluate the legacy SI scheduling algorithm by taking below parameters and values into consideration:

• Total Number of SI-Messages = 9
• SI-WindowLength of 20ms
• SI-Periodicity of SI-Message 1 = 160ms
• SI-Periodicity of SI-Message 2,3 = 320ms
• SI-Periodicity of SI-Message 4, 5,6,7,8,9 = 512ms

When following the SI scheduling rules defined for 5G NR, as depicted in the figure in the previous section, there is a SI-collision as reflected in the figure below. SI-Message 1 should reoccur at position 9 and the SI-Message 9 start position is also at position 9. Hence there is a collision; i.e., if the network would try to schedule more SI messages, the repetition of some SI messages collides with the transmissions (start position) of another SI message.

Above: Consecutive SI scheduling scheme resulting in a collision between SI1 periodical occurrence and start position of SI9.

As we have highlighted in the figure below, there are resources available however with the current scheduling schemes these resources are unreachable owing to the configuration parameters of the scheduling mechanism.

Above: Consecutive SI scheduling scheme unable to reach resources which could be allocated to SI-message start occurrence.

The new 3GPP scheduling enhancement: Enhanced algorithm for acquisition of an SI message

There are many possible routes to take to consider optimizing the SI scheduling problems. For example, you could decrease the SI window length and/or increase the SI periodicity, however this will degrade the performance in terms of coverage or acquisition latency of the SI. This would also not be a long-term solution as the number of SIBs are still expected to increase with every NR release.

At Ericsson, we devised and developed a very effective solution that could allow the scheduling mechanism to use any previously unreachable slots for new SI messages.

The solution is a new scheduling algorithm, one that defines a network configured integer value which can control both the start occasion and the consecutive occurrences of the SI message and thus avoid any collision.

An integer index of the maximum value of 256 is defined, giving freedom to the network to create SI scheduling lists with 256 SI window positions. The network can specify where a certain SI message would start (appear) in the SI scheduling list explicitly without having to follow the consecutive order and hence avoid any collision.

This new solution has been considered for any SIBs (including positioning SIBs) that would be added from 3GPP Rel-17 so that legacy mobile devices implementation does not have to be changed while acquiring legacy (Rel-15 and Rel-16) SIBs. Hence, first we schedule the legacy SI messages and then we use the scheduling opportunities it has not made use of for the new SI messages using the new enhanced scheduling scheme for Rel-17 SIBs as highlighted in the figure below.

Above: Explicit indication of SI window position of the SI message to avoid collision

The figure above shows that to avoid collision, the network explicitly indicates an SI window position for SI9, SI10 and SI11. In the figure, as an example, it is shown that the SI window position of SI9, SI10, SI11 can be explicitly indicated by the network to positions such as 10,11, 12.

This solution has been considered for any SIBs that would be added from Rel-17 so that legacy mobile devices implementation does not have to be changed while acquiring legacy SIBs.

Learn more

Download the full 3GPP contribution R2-2203993 “Explicit Indication of SI Scheduling start position” Ericsson, Verizon, Softbank, Deutsche Telekom, vivo, Lenovo Rel-17 CR 38.331 v 16.7.0.

Learn more about Ericsson’s role in setting technology standards.

Read more 3GPP innovation stories on out 5G standardization page.

Read the blog post: 5G multicast-broadcast – why it matters and how it works