Model-Driven Service Rollback for Network Data Integrity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current data integrity management in telco networks is inefficient and time-consuming, requiring manual inspection of each network node and extensive custom code development, especially during service anomalies, which hampers automated model-driven provisioning and rollback processes.

Innovation Solution

A system and method for model-based provisioning of network devices that includes a processor to manage data templates, transmit configuration messages, and execute rollback procedures automatically, allowing for dynamic rollback of network configurations to a pre-request state without the need for manual intervention or agent-based solutions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual inspection of each network node is performed to confirm data integrity, then data accuracy can be verified, but the process becomes time-consuming and inefficient

Engineering Contradiction:
Improvedata accuracyVSAvoidinspection time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by capturing pre-service configuration data before any service changes are applied to network devices. This baseline data is stored and used for later comparison to automatically detect configuration drift and confirm data integrity without requiring manual inspection after service execution.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements automated feedback mechanisms by continuously monitoring network device configurations against the captured baseline. When service anomalies occur, the system automatically compares current configurations with pre-service states, provides feedback on data integrity status, and triggers rollback procedures if discrepancies are detected, eliminating the need for manual node-by-node inspection.

Inventive Principle:
Principle #23Feedback

2Adaptability or versatility

If custom code development is performed in the OSS/BSS system to integrate device updates, then integration capability is improved, but the system complexity and cost increase significantly

Engineering Contradiction:
Improveintegration capabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal service model framework that can handle multiple network device types and service scenarios through a single standardized interface. The model-driven architecture provides multi-functional capabilities for service deployment, monitoring, and rollback across diverse network elements without requiring custom code development for each specific integration scenario.

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

Solution Approach 2:

The system introduces an intermediary service model layer between the OSS/BSS system and network devices. This model-driven intermediary translates high-level service requirements into device-specific configurations automatically, eliminating the need for custom integration code in the OSS/BSS system while maintaining adaptability to various device types through standardized model definitions.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Measurement precision

If manual inspection procedures are used for data integrity confirmation, then detailed verification is possible, but the ease of operation is reduced

Engineering Contradiction:
Improveverification detailVSAvoidoperational simplicity
Core Design Contradiction:
Measurement precisionVSEase of operation

Solution Approach 1:

The system implements self-service capabilities by enabling network devices to automatically report their configuration states to the management system. The baseline comparison mechanism automatically detects configuration drift and identifies anomalies without requiring manual inspection, allowing detailed verification to occur autonomously while maintaining operational simplicity through automated workflows.

Inventive Principle:
Principle #25Self-service

4Ease of operation

If agentless approaches are used for network management, then the ease of operation is improved, but the ability to perform automated rollback is reduced

Engineering Contradiction:
Improvemanagement simplicityVSAvoidrollback automation
Core Design Contradiction:
Ease of operationVSExtent of automation

Solution Approach 1:

The system performs preliminary actions by capturing and storing complete pre-service configuration states of network devices before any service changes are applied. These baseline configurations are preserved in a standardized format that enables automated comparison and rollback operations without requiring agent software on the network devices, maintaining agentless management while enabling full automation.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements automated feedback loops that monitor service execution outcomes and automatically trigger rollback procedures when anomalies are detected. By comparing real-time configuration states against pre-service baselines, the system provides continuous feedback on service health and autonomously initiates rollback operations without manual intervention, achieving full automation while maintaining ease of operation through standardized interfaces.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3921979B1Model-driven service rollback mechanism for data integrity
Publication Date: 2023.11.22 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP3921979B1 patent drawingFigure 1
  • EP3921979B1 patent drawingFigure 2
  • EP3921979B1 patent drawingFigure 3

AI summary

Systems and methods for rollback of model-based provisioned network device configuration including a memory capable of storing a model-based provisioned data template that includes a data template sequence. Data associated with a request to transmit a target object request message are received and transmitted following a retrieval message that determines pre- configuration data of the target device. The pre-configuration data is stored and the target object request message is sent specifying CRUD semantics. A notification is received indicating an outcome of the execution and, if the execution outcome is unsuccessful, a rollback stack is retrieved that specifies CRUD semantics and the pre-configuration parameters are retrieved to restore the target device to a pre-request state. If the execution outcome is successful, a second target object request message is retrieved from a list of target devices.