Flexible Service Layer Registration for Selective Access

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional service layer registration in oneM2M architecture is inflexible, allowing a registree to register with only one registrar, lacking the capability for a registree to selectively request services during registration and for a registrar to grant partial access to its services, and does not account for dynamic management of local and granted services.

Innovation Solution

A flexible service layer registration system that enables a registree to register with multiple registrar entities, allowing proactive requests for specific services and enabling registrars to grant partial access to services based on capacity, priority, and other factors, with features like granted, rejected, and pending service lists for dynamic management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a registree is allowed to register with only one registrar in conventional service layer registration, then the registration process is simple and straightforward, but the system lacks flexibility and cannot support selective service requests or partial access grants

Engineering Contradiction:
Improveservice selection flexibilityVSAvoidregistration management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the service access rights by introducing separate lists (granted service list, rejected service list, pending service list) that divide services into distinct categories. This allows a registree to selectively access specific services from a registrar rather than requiring all-or-nothing access, thereby improving service selection flexibility while managing complexity through structured organization

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic service list management where the granted, rejected, and pending service lists can be updated during runtime. This dynamic approach allows the system to adapt service access rights based on changing conditions, capacity, and priority without requiring re-registration, thus enhancing versatility while maintaining manageable complexity through automated updates

Inventive Principle:
Principle #15Dynamics

2Productivity

If a registrar grants full access to all services for a registered registree, then service access is simplified, but resource allocation becomes inefficient and cannot account for capacity constraints or priority differences

Engineering Contradiction:
Improveresource allocation efficiencyVSAvoidservice access management
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The patent applies local quality by granting different access rights to different services within the same registration relationship. Instead of uniform full access or complete denial, the system selectively grants access to specific services based on local conditions such as service priority, registrar capacity, and registree needs. This is implemented through the granted service list that specifies which particular services are accessible, thereby improving resource allocation efficiency while maintaining ease of operation through automated list management

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent changes the access rights parameter from a binary state (full access or no access) to a multi-state system using the granted, rejected, and pending service lists. This parameter transformation allows nuanced control over service access, enabling the system to optimize resource allocation by granting access only to appropriate services while simplifying operation through automated parameter management based on capacity and priority criteria

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If the service lists (granted, rejected, pending) are continuously updated during runtime, then service access can adapt to changing conditions, but the complexity of managing and synchronizing these lists increases

Engineering Contradiction:
Improvedynamic service managementVSAvoidservice list management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements self-service by enabling the service lists to automatically update based on predefined criteria and conditions. The system autonomously manages the granted, rejected, and pending service lists by evaluating capacity constraints, priority levels, and registration requirements without requiring manual intervention. This self-managing approach reduces operational complexity while maintaining high adaptability to changing conditions

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent incorporates feedback mechanisms where the service lists continuously monitor and respond to changing system conditions such as registrar capacity, service demand, and priority changes. This feedback-driven update process allows the system to dynamically adjust service access rights based on real-time information, achieving adaptability while managing complexity through automated feedback loops rather than manual control

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3913889B1Service layer registration
Publication Date: 2024.08.14 CONVIDA WIRELESS LLC
  • EP3913889B1 patent drawingFigure 1
  • EP3913889B1 patent drawingFigure 2
  • EP3913889B1 patent drawingFigure 3

AI summary

A service layer entity (e.g., application entity, common service entity in oneM2M, also referred to as registree entity) may register to another service layer entity (e.g., common service entity in oneM2M, also referred to as a registrar entity) and proactively request to gain access to the local services hosted by the registrar entity. A registrar entity may accept a registree entity's registration request but only grant access of its partial services to the registree entity. If a registree entity does not need to proactively request the services within its registration request message, the registrar entity decides what services may be needed by the registree entity and grants access of those services to the registree entity.