CPE Native Service Management for Multi-Provider Configuration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for configuring Device Dependent Services in mass home network deployments are limited by the need for single-point management by a Customer Premises Equipment (CPE) Auto-Configuration Server, leading to backward compatibility issues and lack of confidentiality when multiple Service Providers are involved.

Innovation Solution

The management of device dependent parameters is linked to a specific bundle's service interface on the service platform, allowing only designated Service Providers to access and configure their respective parameters through a Native Services Management system, which splits and routes device dependent service information to appropriate Device Independent Service bundles, enabling management by multiple Auto-Configuration Servers without altering the TR-069 protocol.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a single Auto-Configuration Server manages all device dependent parameters, then the system is simple and backward compatible, but multiple Service Providers cannot independently configure their own parameters

Engineering Contradiction:
Improvemulti-service provider managementVSAvoidconfiguration management structure
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments device dependent parameters into service-specific groups, where each Service Provider can access and configure only their own parameters through dedicated configuration interfaces. This segmentation enables multiple Service Providers to independently manage their parameters without interfering with each other, resolving the contradiction between multi-provider adaptability and system simplicity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary configuration management layer that sits between multiple Auto-Configuration Servers and the device dependent parameters. This intermediary selectively routes configuration requests to the appropriate parameter groups based on service provider identity, enabling multi-provider management while maintaining a unified configuration interface that preserves backward compatibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If a master ACS proxies configuration requests for slave ACS, then multi-service provider management is enabled, but confidentiality is compromised as providers become aware of each other's services

Engineering Contradiction:
Improvemulti-service provider configurationVSAvoidservice provider confidentiality
Core Design Contradiction:
Adaptability or versatilityVSLoss of information

Solution Approach 1:

The patent extracts the confidential service provider identity and parameter access rights from the configuration request flow. By embedding service-specific access control information directly in the configuration interface definitions, the system enables multi-provider management without requiring one provider to proxy requests through another, thus preventing unauthorized providers from learning about services they should not know.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent applies local quality by making configuration interfaces service-provider-specific. Each Auto-Configuration Server is configured with knowledge of only its own service parameters and has direct access to its designated parameter groups, while remaining unaware of other providers' services. This localized knowledge approach enables independent multi-provider configuration while preserving confidentiality.

Inventive Principle:
Principle #3Local quality

3Adaptability or versatility

If the TR-069 protocol is modified to support multiple ACS, then multi-service provider management is enabled, but backward compatibility with existing deployments is lost

Engineering Contradiction:
Improvemulti-auto-configuration server supportVSAvoidprotocol backward compatibility
Core Design Contradiction:
Adaptability or versatilityVSStability of the object's composition

Solution Approach 1:

The patent introduces dynamic service-specific configuration interfaces that are activated based on the service provider's identity and the device's service configuration state. The configuration management system dynamically determines which parameters are accessible to which Auto-Configuration Servers, allowing existing single-provider deployments to continue using the standard TR-069 protocol while enabling multi-provider functionality when multiple providers are detected, thus maintaining backward compatibility.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent creates a universal configuration management framework that can operate in both single-provider and multi-provider modes. The same configuration interface structure serves both traditional single-ACS deployments and new multi-ACS scenarios, with the system automatically adapting its behavior based on the number and identity of connected Auto-Configuration Servers, thereby maintaining protocol backward compatibility while enabling extended functionality.

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

Data Source

PatentUS8880655B2Configuration of device at a customer premises equipment and related method
Publication Date: 2014.11.04 ALCATEL-LUCENT USA LNC
  • US8880655B2 patent drawing
  • US8880655B2 patent drawing

AI summary

A device at a Customer Premises Equipment that comprising Device Dependent Services that are to be configured by a remote Auto-Configuration Server is claimed. The device comprises also Device Independent Services on top of a Service Platform (SPLF). The device is hereby adapted to be configured by a plurality of Auto-Configuration Servers and comprises therefore a Native Service Management being one of the Device Independent Services. This Native Service Management comprises furthermore a receiver part to receive device dependent service information of the Device Dependent Services and a splitter part to split the device dependent service information into different parts, and to transmit each part to a distinct Device Independent Service. Each distinct Device Independent Services being coupled via a common Management Agent being one of the Device Independent Services, to one of the plurality of Auto-Configuration Servers, whereby only the respective part of the Device Dependent Services that is associated to the device dependent service information that is forwarded to the associated Device Independent Service is configured by the associated Auto-configuration Server (FIGURE).