Chargeable Party APIs for Ethernet PDU Session QoS

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current 5G network architectures, specifically in new radio (NR) systems, lack the ability to support Ethernet PDU Sessions effectively, particularly in setting up chargeable parties and ensuring required quality of service (QoS) during session management.

Innovation Solution

The proposed solution extends the ChargeableParty API and AsSessionWithQoS API to include specific attributes for Ethernet User Equipment (UE), allowing for the management of Ethernet flows and QoS settings within the NR system.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the 5G NR system uses traditional IP-based session management architecture, then existing session management functions can be utilized, but Ethernet PDU Sessions cannot be effectively supported

Engineering Contradiction:
ImproveEthernet PDU Session supportVSAvoidSession management architecture
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extends the existing ChargeableParty API and AsSessionWithQoS API to support both traditional IP-based PDU sessions and Ethernet PDU sessions. By adding Ethernet-specific attributes (MAC address, Ethernet flow information) to the existing API frameworks, the system achieves multi-functionality where a single session management architecture handles both IP and Ethernet session types, eliminating the need for separate Ethernet-specific management systems

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

Solution Approach 2:

The patent introduces new parameters and attributes to the existing session management framework: MAC address fields, Ethernet flow information parameters, and Ethernet-specific QoS attributes. These parameter extensions allow the existing IP-based session management architecture to accommodate Ethernet PDU sessions by simply adding new parameter fields rather than redesigning the entire system

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If the system extends ChargeableParty API and AsSessionWithQoS API to include Ethernet-specific attributes, then Ethernet UE session management is enabled, but API complexity increases

Engineering Contradiction:
ImproveEthernet UE supportVSAvoidAPI structure
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the session management attributes into common fields (applicable to both IP and Ethernet sessions) and Ethernet-specific fields. The create request message is divided into standard parameters (session ID, QoS parameters) and Ethernet extension parameters (MAC address, Ethernet flow information). This segmentation allows the API to handle Ethernet sessions by simply activating the appropriate parameter fields without restructuring the entire API framework

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent adds an Ethernet dimension to the existing IP-based session management API. By introducing MAC address fields and Ethernet flow information parameters as additional dimensions to the traditional IP address and packet filter parameters, the system accommodates Ethernet sessions without fundamentally changing the existing API structure. The extension operates as an additional layer rather than a replacement of the original framework

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentUS12348667B2Method and apparatus for granting or not granting a chargeable party at a session management with required quality of service utilizing a MAC address
Publication Date: 2025.07.01 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • US12348667B2 patent drawing
  • US12348667B2 patent drawing
  • US12348667B2 patent drawing

AI summary

Methods and apparatuses for data transmission. A method implemented at a first network function may comprise obtaining information related to network slice selection; and sending a reroute message to an access network node, wherein the reroute message including a container comprising at least one information element of the information related to network slicing selection.