TDRA List Selection for NR Multicast Broadcast Scheduling

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current NR MBS technologies face challenges in determining appropriate time domain resource allocation (TDRA) lists for multicast and broadcast traffic, particularly for terminal devices in idle or inactive states without an active RRC connection, leading to misinterpretation of TDRA fields in DCI.

Innovation Solution

A mechanism for determining TDRA lists based on an identifier for scrambling DCI, the RRC state, and the type of traffic configured for the terminal device, ensuring consistent interpretation of TDRA fields for multicast, unicast, and broadcast traffic.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If DCI formats 1_0 and 1_1 are used as baseline for scheduling multicast traffic, then common data channel resources can be utilized, but terminal devices in idle or inactive states cannot accurately determine the applicable TDRA list

Engineering Contradiction:
Improvemulticast traffic scheduling capabilityVSAvoidTDRA field interpretation accuracy
Core Design Contradiction:
Adaptability or versatilityVSMeasurement precision

Solution Approach 1:

The patent applies local quality by providing different TDRA list determination mechanisms for different terminal states. For idle/inactive terminals, the determination is based on pre-configured associations between identifier and TDRA lists. For connected terminals, the determination can utilize RRC state and traffic type. This localized adaptation resolves the contradiction by optimizing the TDRA list selection process for each specific terminal state.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements preliminary action by pre-configuring TDRA lists and their associations with identifiers before the terminal needs to interpret DCI. The network configures multiple TDRA lists and establishes mapping relationships in advance, so that when a terminal receives DCI, it can quickly determine the appropriate TDRA list without complex real-time analysis, thereby ensuring accurate interpretation for idle/inactive terminals.

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If multiple TDRA lists are configured for different terminal states, then accurate interpretation is enabled, but device complexity increases

Engineering Contradiction:
ImproveTDRA field interpretation accuracyVSAvoidTDRA list determination complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent applies parameter changes by introducing an identifier parameter that changes based on terminal state and traffic type. The terminal determines the TDRA list by selecting from multiple configured lists based on the value of this identifier, which is derived from RRC state, traffic type, and pre-configured associations. This parameter-based selection mechanism maintains interpretation accuracy while managing complexity through structured parameter management.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent implements universality by creating a multi-functional TDRA list determination mechanism that serves both idle/inactive terminals and connected terminals through a unified framework. The same DCI formats and TDRA list structures are used across different terminal states, with the identifier serving as a universal key to select the appropriate list, thereby reducing overall system complexity despite supporting multiple scenarios.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If TDRA list determination is based on RRC state and traffic type, then scheduling flexibility is improved, but processing complexity at terminal increases

Engineering Contradiction:
Improvescheduling flexibilityVSAvoidterminal processing complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by having the network pre-configure TDRA lists and establish their associations with identifiers before terminal operation. The terminal receives and stores these configurations in advance, so that during actual scheduling, it only needs to match the received identifier against the pre-stored associations rather than performing complex analysis, thereby maintaining scheduling flexibility while reducing real-time processing complexity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements self-service by enabling the terminal to autonomously determine the appropriate TDRA list using the received identifier and pre-configured associations. The terminal independently performs the matching process without requiring additional network assistance or complex coordination, thereby achieving scheduling flexibility through self-contained terminal processing while keeping the determination logic manageable through pre-configuration.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP4178300B1Time domain resource allocation for multicast broadcast service
Publication Date: 2026.04.01 NOKIA TECHNOLOGIES OY
  • EP4178300B1 patent drawingFigure 1
  • EP4178300B1 patent drawingFigure 2
  • EP4178300B1 patent drawingFigure 3A

AI summary

Embodiments of the present disclosure relate to time domain resource allocation for multicast broadcast service. A first device receives, from a second device, DCI comprising a TDRA field, and determines, based on at least one of an identifier for scrambling the DCI, a RRC state of the first device or a type of traffic configured for the first device, a TDRA list from a set of configurations for TDRA Then the first device applies, based on the TDRA list, the TDRA field for reception of the traffic from the second device. In this way, a TDRA list to be used may be determined in an optimal manner, with all terminal devices receiving multicast and broadcast traffic determining common values for time domain resources where data traffic would be scheduled.