External Task Orchestration for M2M Device Resource Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Management and control of Machine-2-Machine (M2M) devices in wireless communication networks are complex due to the need for code storage, execution, and monitoring on the devices, which consumes memory, computational resources, and power, and requires frequent updates and testing, impacting Service Level Agreements (SLA) and maintenance costs.

Innovation Solution

A Task Orchestration Module (TOM) external to the M2M device manages task execution using Finite State Machine (FSM) specifications, eliminating the need for code on the device and utilizing a device management protocol server/client system to communicate and execute tasks, with actions mapped to existing library functions, reducing resource consumption and enabling remote management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If code is stored and executed on M2M devices to perform tasks, then task execution capability is achieved, but memory space and battery power are consumed

Engineering Contradiction:
Improvetask execution capabilityVSAvoidbattery power consumption
Core Design Contradiction:
Extent of automationVSUse of energy by moving object

Solution Approach 1:

The patent extracts the task execution logic from the M2M device and places it in a cloud-based Task Orchestration Module. The device only retains minimal client functionality to receive and execute simple commands, while the complex FSM-based task management, monitoring, and coordination occur remotely in the cloud, significantly reducing on-device memory and power consumption.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent introduces a cloud-based Task Orchestration Module as an intermediary between the M2M device and the task management system. This intermediary handles all complex task orchestration, state machine transitions, and coordination logic remotely, allowing the device to perform tasks without maintaining complex code and monitoring mechanisms locally.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Extent of automation

If code is stored and executed on M2M devices to perform tasks, then task execution capability is achieved, but memory space is consumed

Engineering Contradiction:
Improvetask execution capabilityVSAvoidmemory space
Core Design Contradiction:
Extent of automationVSQuantity of substance

Solution Approach 1:

The patent extracts the task execution logic from the M2M device and places it in a cloud-based Task Orchestration Module. The device only retains minimal client functionality to receive and execute simple commands, while the complex FSM-based task management, monitoring, and coordination occur remotely in the cloud, significantly reducing on-device memory and power consumption.

Inventive Principle:
Principle #2Taking out (Extraction)

3Adaptability or versatility

If code updates are performed on M2M devices, then task functionality is improved, but device downtime increases due to reflashing and testing

Engineering Contradiction:
Improvetask functionalityVSAvoiddevice downtime
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent extracts the task execution logic from the M2M device and places it in a cloud-based Task Orchestration Module. Updates to task functionality are performed remotely in the cloud by modifying the FSM specifications and task definitions, eliminating the need for device reflashing and reducing downtime to minimal levels.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements preliminary action by pre-defining task specifications, state machines, and transition logic in the cloud before execution. This allows for flexible updates and modifications to be prepared and deployed remotely without requiring physical access to devices or interruption of ongoing operations.

Inventive Principle:
Principle #10Preliminary action

4Reliability

If task monitoring and error handling are implemented on devices, then task reliability is improved, but computational resources and power consumption increase

Engineering Contradiction:
Improvetask execution reliabilityVSAvoidcomputational resources
Core Design Contradiction:
ReliabilityVSPower

Solution Approach 1:

The patent extracts the task monitoring and error handling logic from the M2M device and implements it in the cloud-based Task Orchestration Module. The device simply executes commands and reports status, while the complex monitoring, state machine transitions, and error handling occur remotely, reducing on-device computational resources and power consumption.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS12190153B2System and method for efficient execution and monitoring of machine-to-machine device management tasks
Publication Date: 2025.01.07 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • US12190153B2 patent drawing
  • US12190153B2 patent drawing
  • US12190153B2 patent drawing

AI summary

In a M2M device management system, a Task Orchestration Module, TOM (32) external to the M2M device (20) manages the execution of tasks wholly or partly on the M2M device (20). This alleviates the M2M device (20) of the need to store code, execute tasks, monitor task execution, and the like. The tasks are specified using Finite State Machine, FSM, syntax. A task URL, tURL (34) resource on the M2M device (20) provides a tURL (34) to a resource hosting (36) a service (38) mapping task-IDs to FSM specifications. Communications between the TOM (32) and M2M device (20) is compactly and efficiently achieved using a device management protocol server/client system (16, 18), such as LightWeightM2M (LWM2M). A predetermined mapping (40) at the M2M device (20) maps action labels to library functions (22) of the M2M device (20), obviating the need for code in the M2M device (20) to interpret and execute actions. An event trigger decision module (42) at the TOM (32) interprets events and conditions reported by the device management protocol client (18), and determines when state transition events have occurred.