Core Network Captivity State for Encrypted Traffic Notifications

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing methods for user notification in mobile networks, such as HTTP-based redirection, are ineffective for encrypted traffic like HTTPS/TLS and QUIC, and cannot handle applications that do not use HTTP, leading to unreliable notifications and hindered telecommunication services.

Innovation Solution

A computer-implemented method involving a first core network node that sets a captivity state for a device, indicating it needs to perform an action, and communicates through application programming interfaces with second and third nodes to manage a captive portal, allowing user notifications even with encrypted traffic by using the IETF CAPPORT framework.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If HTTP-based redirection is used for user notification, then the notification mechanism is simple to implement, but it becomes ineffective for encrypted traffic like HTTPS/TLS and QUIC

Engineering Contradiction:

Improveimplementation simplicityVSAvoidnotification effectiveness

Core Design Contradiction:

Ease of manufactureVSReliability

Solution Approach 1:

The patent introduces a captive portal as an intermediary mechanism between the network and the user device. Instead of relying on HTTP redirection of application traffic, the system uses the captive portal to deliver notifications through the operating system's browser, which acts as a mediator that can display notifications regardless of the underlying encrypted traffic protocols (HTTPS/TLS, QUIC). This resolves the contradiction by maintaining implementation simplicity while achieving reliable notification delivery across encrypted connections.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical HTTP redirection mechanism with a system-based notification mechanism. Rather than manipulating application-layer HTTP redirects, the system uses the operating system's captive portal framework to deliver notifications through the device's browser interface. This substitution allows notifications to work independently of traffic encryption mechanisms, resolving the reliability issue while maintaining ease of implementation through existing OS capabilities.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

2Adaptability or versatility

If HTTP-based redirection is used for user notification, then the notification mechanism works with standard HTTP traffic, but it cannot handle applications that do not use HTTP

Engineering Contradiction:

Improveprotocol compatibilityVSAvoidnotification delivery

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements universality by using the captive portal mechanism, which is integrated into the operating system's browser framework. This allows the notification system to work with any application protocol (HTTP, HTTPS/TLS, QUIC, or other encrypted protocols) because it leverages the OS-level browser rather than application-specific mechanisms. The captive portal serves as a universal notification delivery channel that is independent of the underlying transport protocol, thereby achieving both protocol compatibility and reliable notification delivery.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Device complexity

If existing notification methods are used, then the network infrastructure remains simple, but user notifications are unreliable and may be missed

Engineering Contradiction:

Improvenetwork infrastructure complexityVSAvoidnotification reliability

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The patent applies self-service by leveraging the operating system's built-in captive portal framework to deliver notifications. Instead of requiring complex custom network infrastructure, the system uses the device's own OS capabilities (browser-based captive portal) to reliably deliver notifications. This approach maintains network infrastructure simplicity while significantly improving notification reliability, as the OS-level mechanism ensures proper delivery and user awareness.

Inventive Principle:

Principle #25Self-service

Data Source

PatentUS20240314677A1First Core Network Node, Second Node and Third Node, Communications System and Methods Performed, Thereby for Handling Performance of an Action By a Device

Publication Date: 2024.09.19 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

AI summary

A computer-implemented method, performed by a first core network node (111), for handling performance of an action by a device (130). The device (130) operates in the communications system (100) via a connection through a data session. The first core network node (111) sets (406), based on a determination that the device (130) is to perform an action with the communications system (100), a captivity state of the device (130) to a captive state. The captive state indicates that the device (130) has not yet performed the action. The first core network node (111) also provides (407) an indication to a second node (112). The second node (112) manages, via a first application programming interface, a third node (113). The third node (113) manages a captivity portal accessible by the device (130) to perform the action. The indication indicates the state of the device (130) has been set to captive state for the action.