PDSCH dynamic repetition: Setting a new standard for supporting dynamic radio conditions and traffic profiles

RepetitionNumber-r16

This simple piece of downlink configuration code may not have the same awe factor as a flock of radio-operated delivery drones, nor a fleet of self-driving autonomous vehicles – but it is a critical part of the wider formula that will eventually make those stories happen. 

In July 2020, during the height of a pandemic that brought many industrial enterprises into a state of existential shock, 3GPP released arguably its most progressive standard yet for tomorrow’s innovative critical internet of things use cases.

Evolving the physical layer standard

While the earlier and first full set of NR standards, 3GPP Release 15, lay the foundational stone for 5G networks with the debut of higher carrier frequencies, wider transmission bandwidths, and improved network energy performance – with 3GPP Release 16 and Release 17, we took significant strides in building on that foundation through a series of physical layer enhancements, enabling entire new deployment scenarios in verticals such as factory automation, transport and other exciting use cases which demand enhanced ultra-reliable low-latency communication (URLLC).

The network’s physical layer – comprising frame structure, modulation schemes, waveform, reference signals, multi-antenna transmission and channel coding – forms a critical part of the radio access network’s (RAN) infrastructure and is key to defining the performance of connecting wireless applications.

Eruption of 5G NR traffic challenges

This technology area has evolved rapidly in recent years to accommodate the meteoric rise of new applications, devices and technologies which now connect to the network – all with varying and ever-tightening demands on user experience and quality of service.

As a result, today’s networks comprise a heterogenous labyrinth of traffic flows: from enhanced mobile broadband (eMBB) serving improved latency, coverage, data rate and user density; massive machine type communication (mMTC) service devices which are battery operated and massive in volume such as smart logistics, wearables and environmental monitoring; and high-availability URLLC such as public safety operations, industrial control, factory automation and other critical applications. If we compare with the early days of cellular networks, where traffic types were largely categorized into conversational, interactive (web browsing), streaming and background (low-priority traffic), we see that today’s networks make for a completely different beast with an acutely diverse set of traffic demands and challenges which are on track to intensify with forthcoming explorations into extreme reliability use cases.

It’s important to consider that, even amid the ongoing traffic eruption, spectral and radio resources remain finite. As such, it’s increasingly critical that networks have the continued ability to distribute spectral resources fairly, efficiently, and optimally to ensure the best possible quality of service (QoS) differentiation according to the delay sensitivity of each service.

This is where physical layer scheduling comes into play.

Physical layer traffic scheduling

Today’s packet-based networks contain schedulers within the base station that regulate the allocation of radio resources to applications and users connecting to the network.

This is an extremely complex process, traditionally managed via rule-based algorithms, whereby shared radio resources are optimally distributed every millisecond according to the throughput and latency requirements of each traffic type.

PDSCH and PUSCH – Physical shared channels for downlink and uplink traffic

Let’s put that into context. If we look at an automated factory setting, there may be several use cases happening at the same time all with varying requirements on the network.

Each IP-based heterogeneous traffic type within that use case is assigned its own logical channel, with its own unique configuration depending on the latency and reliability characteristics of the application. The data traffic to and from each application is communicated via so-called transport block (TB) packets over the respective channels – the physical downlink shared channel (PDSCH) for downlink traffic, and the physical uplink shared channel (PUSCH) for uplink traffic.

Depending on the latency tolerance and reliability requirements of each application, the transport blocks can be configured to be transmitted multiple times. In NR Release 15, repetition values of 2, 4 and 8 could be configured per device for example, to compensate for any potential coverage degradation between the device and base station.

Putting that into context, again, each application in our example will likely be served by the network with different types of traffic in parallel. This includes:

• eMBB data with high data throughput requirement, using a single PDSCH transmission
• Critical IoT data with medium reliability requirement, using a few PDSCH repetitions
• Critical IoT data with high reliability requirement, using many PDSCH repetitions
• Critical IoT data with low latency requirement, using only one or two PDSCH repetitions

PDSCH in NR Release 15: Challenges to the radio resource control (RRC) protocol

From an early stage, it became clear to us at Ericsson that the existing RRC protocol specification for PDSCH configuration in NR Release 15 networks did not offer the flexibility demanded by emerging traffic profiles of the 5G era – including primarily massive machine type communication (mMTC), URLLC and eventually extreme reliability.

As we saw it, there were two clear challenges to address. Firstly, the number of PDSCH repetitions was not flexible enough – meaning it is not possible to dynamically adapt the applied number of PDSCH repetitions for different types of data flows with different reliability requirements. And secondly, in TDD spectrum bands, collisions between the downlink PDSCH- and uplink (UL) resource allocations leads to lower reliability for downlink PDSCH transmission.

To understand this a little better, let’s look at our earlier command and control automated factory example. Here, the network node sends commands to each device in the factory space, which must then be received in a reliable and timely manner for the device to process and act on the command.

With a static RRC protocol, with limited repetition indication, we cannot offer the same reliability in TDD systems, which have different shared slot formats, compared to the frequency-division duplex (FDD) systems, which comprise two separate and simultaneous downlink and uplink channels. In a TDD scenario, as shown in Figure 1 for example, the wireless device will only receive two of the four PDSCH repetitions if the other two PDSCH repetitions collide with UL symbols. As a result, tomorrow’s TDD networks would not be able to offer the same possibilities when it comes to critical IoT and even eventually extreme reliability use cases.

Figure 1. Example where PDSCH repetitions are omitted due to their resource allocations colliding with UL symbols

PDSCH in NR Release 16: Dynamic repetition indication

With 3GPP NR Release 16, we had an opportunity to introduce a new dynamic and flexible approach to PDSCH traffic scheduling, one which would allow us to address new verticals that we previously could not address with the NR Release 15 RRC protocol.

At Ericsson, we proposed a solution which enables the scheduler to dynamically indicate the number of PDSCH repetitions depending on the type of traffic and the radio conditions – offering vastly improved scheduling versatility for the wide range of emerging 5G use cases with different reliability requirements.

As part of this, we proposed to increase the set of possible repetition values from 2, 4 and 8 – to 2, 3, 4, 5, 6, 7, 8 and 16. This would compensate for any potential loss of downlink PDSCH repetitions where there is conflict with UL symbols/slots in TDD systems.

Figure 2. Example where PDSCH dynamic repetition is configured to 5, compensating for the loss of one PDSCH repetition which collided with UL symbols.

Back to our factory setting, imagine that we now have a fleet of automated guided vehicles (AGVs) which connects to the base station. With this solution, if one of those AGVs were to move further away from the base station, or if weather conditions were to suddenly deteriorate in an outdoor setting, we are now better equipped to quickly compensate for that loss in coverage by quickly adapting the number of downlink transmission repetitions. Previously, this would not have been the case.

Of course, identifying and developing the solution was only one step in our challenge to make this a reality. The second challenge was to convince the industry that dynamic PDSCH repetition was both necessary and the best possible technical solution to take us forward.

This is not always as straightforward as it seems.

The road to the new standard

3GPP represents the very best of the telecom industry. In abstract terms, it epitomizes the innate human spirit to work together to find the best possible solution – to advance the collective and deliver the greatest possible benefit for all. It’s also an open institution, where shared, common standards – as opposed to proprietary solutions – prevail in the spirit of healthy competition.

The 3GPP journey to the new specification began in August 2019 at RAN1#98 in Prague where we first proposed and began to drive PDSCH dynamic repetition indication in the 3GPP arena. Based on superior technical arguments, from the view of communication service providers who must deal with multiple services with different reliability in parallel, we prevailed in convincing 3GPP stakeholders as to the technical superiority and need for PDSCH dynamic repetition indication in meeting emerging multiple parallel traffic requirements.

The specification was agreed two months later at the next RAN1#98bis meeting in Chongqing. As a result, we are in no doubt that the new PDSCH dynamic repetition specification will play a key role in enabling the evolution of new technologies and use cases across critical IoT and beyond.

Next steps

Today, 3GPP is currently studying the application of  extended reality (XR), with specification work due as part of release 18. This, of course, presents yet further technical challenges through the combination of bounded latency, high reliability, and high throughput. However, the possibilities which this can enable, for example through mission-critical remote command and control applications, could be beyond the imaginable. The flexible scheduling methods presented in this blog post provide a solid foundation for unlocking these applications.

Learn more

Read more about what to expect in the upcoming 3GPP releases 17 and 18.

Read more about standardization and the pathway to tomorrow’s technologies.

Read an overview of 3GPP releases 16 and 17.

Read more about the 5G NR physical layer.