SCell Key Configuration in Cross-eNB Carrier Aggregation Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional methods for key configuration and transmission in Carrier Aggregation (CA) technology are inadequate for scenarios involving multiple cells, particularly in cross-eNB CA, where the encryption of data by Secondary Cells (SCells) is not defined, leading to potential data decryption by unauthorized users.
Innovation Solution
A method and base station are provided to configure and transmit a Key for SCells (KeNB) by the Primary Cell (PCell) or Mobile Management Entity (MME), ensuring data encryption for SCells, with various methods to generate and manage KeNBs independently or collectively across eNBs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Conventional key configuration methods are used in cross-eNB CA, then the system maintains simplicity in key management, but data security in SCells is compromised and unauthorized decryption becomes possible
Solution Approach 1:
The patent segments the key management by introducing separate KeNB configurations for PCell and SCell. The PCell uses a first KeNB while the SCell uses a second KeNB, allowing independent security management for each cell type in cross-eNB CA scenarios.
Solution Approach 2:
The patent applies local quality by configuring different key parameters specifically for the SCell based on its unique characteristics. The second KeNB for SCell is configured using SCell-specific parameters including downlink frequency and physical cell identity, ensuring localized security appropriate to each cell's context.
2Ease of operation
If a single KeNB is used for both PCell and SCell, then key management is simplified, but the vulnerability to unauthorized decryption increases in cross-eNB CA scenarios
Solution Approach 1:
The patent divides the encryption key management into separate segments: a first KeNB for PCell and a second KeNB for SCell. This segmentation ensures that compromise of one key does not affect the other, maintaining encryption security while managing multiple keys through structured procedures.
Solution Approach 2:
The patent changes the parameters used in key configuration by introducing SCell-specific parameters (downlink frequency, physical cell identity) into the second KeNB configuration, differentiating it from the PCell's first KeNB and enhancing security through parameter diversity.
3Adaptability or versatility
If conventional key generation methods are applied to SCell, then the system maintains consistency with existing protocols, but it fails to prevent data decryption by unauthorized users in cross-eNB CA
Solution Approach 1:
The patent applies local quality by configuring the second KeNB for SCell with SCell-specific local parameters including downlink frequency and physical cell identity. This localized configuration enhances data protection for SCell while maintaining compatibility with existing 3GPP protocol frameworks.
Solution Approach 2:
The patent modifies the key configuration parameters by incorporating SCell-specific characteristics (frequency, cell identity) into the second KeNB, adapting the conventional key generation method to provide enhanced protection for SCell data in cross-eNB CA scenarios.
Data Source
Figure 1
Figure 2~3
Figure 4
AI summary
The present application discloses a method for configuring and transmitting a key, which includes that: a) a serving cell (PCell) of UE determines a key (KeNB) used by a SCell and transmits the KeNB to the SCell; and b) the PCell transmits configuration information for configuring the SCell to the UE after receiving a response message from the SCell, and receives a response message from the UE. Or, the method includes that: a SCell of UE transmits a cell key request to a MME and receives key information from the MME; and the SCell transmits the key information received from the MME to the UE, and receives a response message from the UE. By the present application, data of the SCell is transmitted after being encrypted, so as to avoid a case that the data is decoded by other users, and further guarantee the security of the data.