On-Demand Multicast Control Channel Message Delivery

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In wireless communication systems, the periodic transmission of multicast control channel (MCCH) messages leads to delays and increased latency for user equipment (UE) in receiving multicast traffic, as UEs must monitor the physical downlink control channel for extended periods.

Innovation Solution

Implementing on-demand MCCH message transmission, where UEs request and receive MCCH messages based on system information, allowing them to receive multicast traffic according to a multicast service radio bearer configuration without continuous monitoring, using random access preambles or radio resource control messages.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If periodic transmission of MCCH messages is used, then all UEs can receive multicast control information reliably, but UEs experience increased latency and must monitor the control channel for extended periods

Engineering Contradiction:
Improvereliability of MCCH message deliveryVSAvoidlatency in receiving MCCH messages
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements dynamic MCCH message transmission where the base station responds to UE requests rather than transmitting periodically. When a UE needs multicast control information, it sends a request and the base station transmits the MCCH message on-demand, converting the static periodic transmission model into a dynamic request-response model that adapts to actual UE needs.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent enables UEs to autonomously determine when they need MCCH messages and initiate requests themselves. The UE monitors for multicast traffic indications, determines when configuration information is needed, and actively requests the MCCH message from the base station, making the system self-service oriented rather than relying on periodic broadcasts.

Inventive Principle:
Principle #25Self-service

2Reliability

If periodic transmission of MCCH messages is used, then multicast control information is always available, but UEs spend excessive time monitoring the control channel

Engineering Contradiction:
Improveavailability of multicast control informationVSAvoidcommunication efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent replaces continuous periodic monitoring with periodic on-demand requests. Instead of UEs continuously monitoring the control channel for periodic MCCH transmissions, the system uses triggered periodic actions where UEs request MCCH messages only when specific conditions are met (e.g., when multicast traffic is indicated), reducing monitoring overhead while maintaining information availability.

Inventive Principle:
Principle #19Periodic action

Solution Approach 2:

The patent extracts the essential MCCH message content and delivers it selectively to only those UEs that need it, rather than broadcasting to all UEs periodically. By taking out the necessary control information and delivering it on-demand to requesting UEs, the system eliminates unnecessary monitoring and transmission overhead for UEs that do not require multicast services at that moment.

Inventive Principle:
Principle #2Taking out (Extraction)

3Loss of time

If on-demand MCCH message transmission is implemented, then latency is reduced and communication efficiency improves, but the system complexity increases due to request-response mechanisms

Engineering Contradiction:
Improvelatency in receiving MCCH messagesVSAvoidcomplexity of control channel management
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The patent leverages existing universal communication protocols and message formats for the request-response mechanism. The UE requests and base station responses use standardized RRC messaging formats that are already part of the wireless communication protocol stack, allowing the on-demand mechanism to be implemented without adding significant system complexity by reusing existing multi-functional communication primitives.

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

4Speed

If UEs monitor the control channel continuously for MCCH messages, then they can receive multicast traffic immediately when available, but power consumption and processing overhead increase

Engineering Contradiction:
Improvespeed of receiving multicast trafficVSAvoidpower consumption for control channel monitoring
Core Design Contradiction:
SpeedVSUse of energy by moving object

Solution Approach 1:

The patent implements preliminary action by having UEs monitor for multicast traffic indications first, then request MCCH messages only when needed. Instead of continuously monitoring for MCCH messages, UEs perform preliminary monitoring for traffic indications and only initiate MCCH requests when multicast traffic is anticipated, reducing unnecessary monitoring and power consumption while maintaining readiness to receive traffic when available.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11711826B2On-demand multicast control channel messages
Publication Date: 2023.07.25 QUALCOMM INC
  • US11711826B2 patent drawing
  • US11711826B2 patent drawing
  • US11711826B2 patent drawing

AI summary

Methods, systems, and devices for on-demand multicast control channel (MCCH) messages are described. A user equipment (UE) may receive, from a base station, system information indicating an MCCH message configuration. Based on receiving the MCCH message configuration, the UE may transmit a request for an MCCH message. For example, the UE may transmit the request for the MCCH message by a random access preamble or a radio resource control (RRC) message. After transmitting the request, the UE may receive the MCCH message in accordance with the MCCH message configuration. That is, the base station may receive the request and transmit the MCCH message in response to the request. The MCCH message may indicate a multicast service radio bearer (MRB) configuration for receiving multicast traffic. Thus, the UE may receive multicast traffic from the base station in accordance with the MRB configuration.