Network Slice API Operations for Efficient Service Exposure

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Creating APIs and related resources (e.g., URIs) and data models for network slicing presents challenges in wireless communications systems, hindering efficient network slice configuration and service exposure.

Innovation Solution

A framework is provided for defining API-related services, including service operations, methods, and associated resources (URIs) to enable more efficient wireless network slicing and robust exposure of network slice-related services, utilizing network slice capability exposure servers and vertical application layer servers for configuration, update, and invocation of slice APIs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If traditional methods are used to create APIs and related resources for network slicing, then basic functionality is achieved, but efficiency and robustness of service exposure are insufficient

Engineering Contradiction:
Improveefficiency of network slice configurationVSAvoidrobustness of service exposure
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent segments the network slice management functionality into distinct API operations (create, read, update, delete) and separates the service exposure function into a dedicated Network Slice Capability Exposure Server. This segmentation allows each component to be optimized independently, improving overall efficiency while maintaining reliability through specialized handling of each operation type.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a Network Slice Capability Exposure Server as an intermediary component that sits between the network slice management system and external applications. This mediator handles all API interactions, providing a standardized interface that improves service exposure robustness while maintaining configuration efficiency through automated processing.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If comprehensive API functionality is implemented for network slicing, then service exposure capability is improved, but system complexity increases

Engineering Contradiction:
Improveservice exposure capabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal API framework that handles multiple network slice operations (configuration, management, exposure) through a common set of standardized endpoints and protocols. This universal interface provides comprehensive service exposure capability while reducing system complexity by eliminating the need for separate specialized interfaces for each function.

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

Solution Approach 2:

The patent uses parameter-based configuration where complex network slice settings are managed through structured data parameters in API requests and responses. This approach enables comprehensive functionality to be exposed through simple parameter modifications rather than complex structural changes, maintaining low system complexity while achieving high adaptability.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS20250260734A1SERVICE OPERATIONS FOR APPLICATION PROGRAMMING INTERFACES (APIs)
Publication Date: 2025.08.14 LENOVO (SINGAPORE) PTE LTD
  • US20250260734A1 patent drawing
  • US20250260734A1 patent drawing
  • US20250260734A1 patent drawing

AI summary

Various aspects of the present disclosure relate to service operations for Application Programming Interfaces (APIs). A first network equipment (NE) transmits, to a second NE, a request message for a service operation, the request message including a resource Uniform Resource Identifier (URI) for a Hypertext Transfer Protocol (HTTP) POST method, and the service operation includes one or more of an initial Application Programming Interface (API) configuration, an API configuration update, or an API invocation associated with an API provider. The first NE receives, from the second NE, a response message including a result of the service operation.