Multicast Data Security Using Tunnel Identity and Logical Channels

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

There is a lack of clarity in how radio access networks (RAN) apply security protection to multicast and broadcast service (MBS) data packets, particularly in scenarios involving multi-radio dual connectivity (MR-DC) and handover procedures, which can compromise the security of MBS data transmission.

Innovation Solution

The RAN and user equipment (UE) implement techniques for managing security checking and protection by determining the appropriate security check scheme and protection based on the identity of the downlink tunnel and logical channel configuration, applying either null or non-null security protection depending on the transmission mode (unicast or multicast) to ensure secure data transmission.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the RAN applies uniform security protection to all data packets, then security coverage is improved, but device complexity and processing overhead increase

Engineering Contradiction:
Improvesecurity coverageVSAvoidprocessing overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies different security protection strategies to different data packets based on their source and type. MBS data packets received from the core network via a common downlink tunnel are transmitted without security protection (null security), while other data packets maintain standard security protection. This local differentiation reduces processing overhead while maintaining appropriate security coverage.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent changes the security protection parameter dynamically based on the data packet characteristics. When the data packet is identified as MBS data from a common downlink tunnel, the security protection parameter is set to null; otherwise, standard security protection is applied. This parameter change approach optimizes the balance between security coverage and processing efficiency.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If the RAN applies security protection to MBS data packets, then data integrity is improved, but transmission efficiency deteriorates

Engineering Contradiction:
Improvedata integrityVSAvoidtransmission efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies security protection selectively rather than uniformly. MBS data packets transmitted to multiple UEs via multicast are sent without security protection to maintain high transmission efficiency, while unicast data packets continue to receive security protection. This local quality approach ensures data integrity where needed while preserving transmission efficiency for multicast services.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent applies partial security protection - only to specific data packets that require it (unicast traffic), rather than applying security protection to all data packets (excessive action). This partial action approach maintains data integrity for sensitive unicast traffic while avoiding the transmission efficiency penalty that would result from securing all traffic.

Inventive Principle:
Principle #16Partial or excessive action

3Reliability

If the RAN uses UE-specific security keys for MBS data, then security protection is improved, but device complexity increases

Engineering Contradiction:
Improvesecurity protectionVSAvoidkey management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts MBS data packets from the standard security processing flow by identifying them through their specific transmission characteristics (common downlink tunnel, multicast delivery). Once extracted, these packets are transmitted without applying UE-specific security keys, thereby reducing key management complexity while maintaining security protection for non-MBS data.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent segments the data traffic into MBS data packets and non-MBS data packets, applying different security strategies to each segment. MBS data packets use null security protection, while non-MBS packets use standard UE-specific security keys. This segmentation reduces the overall key management complexity by eliminating the need to manage keys for multicast traffic.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP4406196B1Managing multicast data communication
Publication Date: 2025.07.30 GOOGLE LLC
  • EP4406196B1 patent drawingFigure 1A
  • EP4406196B1 patent drawingFigure 1B~2A
  • EP4406196B1 patent drawingFigure 2B

AI summary

A radio access network (RAN) can perform a method for managing security protection for multicast and/or broadcast services (MBS). The method includes receiving (802), from a core network (CN) via a DL tunnel, a data packet associated with an MBS session; prior to transmitting the data packet to a plurality of UEs, determining (804) which security protection to apply to the data packet based on an identity of the DL tunnel; and transmitting (806) the data packet to the plurality of UEs using the determined security protection. A UE can receive (902), from a RAN, a configuration for establishing a logical channel with the RAN; receive (904), from the RAN via the logical channel, a data packet associated with an MBS session; determine (906) which security protection to apply to the data packet based on the configuration; and apply (908) the determined security protection to the data packet.