Loop Avoidance in Middle-Node-to-Middle-Node M2M Registration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current M2M network architectures restrict multiple uni-directional registrations between Middle Nodes (MN-CSEs), leading to limitations in registration loops, where a node cannot register with another if it would create a loop, hindering flexible service provisioning.

Innovation Solution

Implement loop-avoidance procedures where a Middle Node (MN) checks the registration status of potential registration targets by obtaining lists of identifiers or profile information to prevent loop creation, allowing registrations beyond single-node support and setting a maximum depth limit for concatenated registrations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If loop-avoidance procedures are implemented to prevent registration loops, then registration flexibility is improved, but system complexity increases due to additional checks and procedures

Engineering Contradiction:
Improveregistration flexibilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by performing loop detection checks before completing the registration process. The source node queries the registration status and concatenated registration list of the target node beforehand, allowing the system to prevent loop formation proactively rather than detecting and correcting it afterward. This maintains registration flexibility while managing complexity through preventive measures.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If multiple uni-directional registrations are allowed between Middle Nodes, then service provisioning capability is enhanced, but the risk of registration loops increases

Engineering Contradiction:
Improveservice provisioning capabilityVSAvoidregistration loop risk
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements feedback by having the target node return its concatenated registration list to the source node during the registration process. This feedback mechanism allows the source node to assess whether establishing a new registration would create a loop, enabling multiple registrations to coexist safely while maintaining system reliability through informed decision-making.

Inventive Principle:
Principle #23Feedback

3Measurement precision

If loop detection checks are performed before registration, then registration accuracy is improved, but processing time increases

Engineering Contradiction:
Improveregistration accuracyVSAvoidprocessing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent applies partial action by implementing a depth limit parameter that restricts the maximum number of concatenated registrations to be checked. Instead of performing exhaustive loop detection across the entire network, the system checks only up to a predefined depth, maintaining registration accuracy for common scenarios while reducing processing time and avoiding unnecessary checks in large-scale networks.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS9986368B2Loop avoidance in middle-node-to-middle-node registration in M2M networks
Publication Date: 2018.05.29 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • US9986368B2 patent drawing
  • US9986368B2 patent drawing
  • US9986368B2 patent drawing

AI summary

A first machine-to-machine, M2M, node registering with a second M2M node avoids registration loops using a method that begins with obtaining (710) identifiers for each M2M node with which the second M2M node is registered. The first M2M node refrains (735) from registering with the second M2M node if an identifier for the first M2M node is among the identifiers, registers (725) with the second M2M if the second M2M node is not registered with other M2M nodes, and otherwise: (a) retrieves (740) identifiers for each M2M node with which any M2M on the obtained list is registered, (b) registers (755) with the second M2M node in the event that no identifiers are retrieved, and, (c) if the identifier for the first M2M node is retrieved, refrains (765) from registering with the second M2M node. Steps (a), (b), and (c) may be repeated for identifiers retrieved in step (a).