Network Slice Security Contexts for Service-Specific Privacy Isolation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing 5G networks lack the ability to enforce slice-specific security requirements, leading to breaches in data privacy between operator and third-party services due to the use of a common security context, which fails to meet the varying privacy needs of different network slices.

Innovation Solution

Implement a common network function, such as a Common Security Anchor Function (CSEAF), to determine and enforce slice-specific security requirements, controlling key generation and provisioning to ensure isolation and privacy between different slices and security domains.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a common security context is used for all network slices, then device complexity is reduced and ease of operation is improved, but data privacy and security isolation between operator and third-party services deteriorate

Engineering Contradiction:
Improvesecurity management simplicityVSAvoiddata privacy breach
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent segments the common security context into slice-specific security contexts. The network function determines whether a network slice requires slice-specific security and generates appropriate security requirement information. This segmentation allows different security treatments for different slices while maintaining manageable complexity through automated determination and enforcement mechanisms.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies local quality by providing differentiated security contexts tailored to specific network slice requirements. Operator slices receive one type of security context while third-party slices receive another type, with the specific security characteristics determined locally based on slice identification and security requirement evaluation, rather than applying a uniform security approach globally.

Inventive Principle:
Principle #3Local quality

2Object-affected harmful factors

If slice-specific security requirements are enforced, then data privacy and security isolation between slices are improved, but device complexity and security management overhead increase

Engineering Contradiction:
Improvedata privacy protectionVSAvoidsecurity management complexity
Core Design Contradiction:
Object-affected harmful factorsVSDevice complexity

Solution Approach 1:

The patent implements preliminary action by determining slice-specific security requirements in advance during the initial authentication and slice selection phases. The network function determines whether slice-specific security is required and generates the appropriate security requirement information before actual data transmission begins, allowing security contexts to be pre-established and avoiding complex real-time security decisions during data flow.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces a network function as an intermediary between the authentication system and the network slices. This intermediary determines slice-specific security requirements, generates corresponding security information, and enforces the appropriate security contexts. This mediator simplifies the overall system by centralizing security determination logic and preventing the need for complex security management at multiple distributed points.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Ease of manufacture

If a common security context is used, then ease of manufacture and deployment are improved, but adaptability to different service provider privacy needs deteriorates

Engineering Contradiction:
Improvenetwork deployment simplicityVSAvoidservice-specific security adaptability
Core Design Contradiction:
Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamics by making the security context adaptable based on network slice characteristics. The system dynamically determines whether slice-specific security is required and adjusts the security context accordingly. This allows the security mechanism to be flexible and adaptive to different service provider needs while maintaining a relatively simple base deployment structure that can automatically adjust to various requirements.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS20260032435A1Slice-specific security requirement information
Publication Date: 2026.01.29 LENOVO (SINGAPORE) PTE LTD
  • US20260032435A1 patent drawing
  • US20260032435A1 patent drawing
  • US20260032435A1 patent drawing

AI summary

Apparatuses, methods, and systems are disclosed for determining and enforcing service specific network slice security. One apparatus includes a processor coupled with the memory and configured to cause an access and mobility management function (AMF) to: perform primary authentication with a user equipment (UE); transmit, to a unified data management function (UDM), a subscription data request message comprising a subscription identifier associated with the UE and slice selection information; receive, from the UDM, a subscription data response message comprising slice-specific security requirement information (SSI) for a set of network slices; and enforce slice security for control plane (CP) and user plane (UP) traffic related to a network slice according to a security requirement type indicated in the SSI.