Service Model Hub for OSS Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The integration of new services in telecommunication networks is delayed and costly due to the need for extensive updates and testing of Operations Support Systems (OSSs), especially when new functionality is provided by different vendors, requiring significant resource allocation for software changes and interface mappings.
Innovation Solution
A method using a Service Designer to create a meta-model-based service model, which allows for the definition and deployment of new services without altering underlying OSS software, by publishing views of the service model at a Service Hub for configuration and deployment across multiple OSSs, enabling seamless integration of new services from different vendors.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If new services are introduced into the network by adding new hardware and software to existing OSS components, then new functionality is achieved, but the definition, development, deployment and testing process becomes costly and time-intensive
Solution Approach 1:
The patent uses service templates as reusable models that define service behavior, interfaces, and configurations. Instead of creating new service implementations from scratch, the system copies and instantiates services from these templates, dramatically reducing development time and ensuring consistency across service deployments
Solution Approach 2:
Service templates are pre-configured with all necessary service definitions, interfaces, and behavioral specifications before actual service deployment. This preliminary preparation of service blueprints allows for rapid service instantiation without requiring extensive definition, development, or testing at deployment time
2Adaptability or versatility
If software code is added to existing OSSs to support new functionality and interfaces to new systems, then new service capabilities are enabled, but extensive testing is required to verify conformity to standard formats
Solution Approach 1:
The patent implements a universal service template framework that can define and instantiate multiple different services using a common structure and interface paradigm. This universal approach allows diverse services to be managed through consistent mechanisms, reducing the need for service-specific code additions and simplifying the overall OSS architecture
Solution Approach 2:
Service templates use parameterized definitions where service-specific behaviors and interfaces are defined through configurable parameters rather than hard-coded logic. This allows the same template structure to adapt to different services by changing parameters, reducing system complexity while maintaining service diversity
3Reliability
If extensive tests are performed to verify that data and functionality introduced for new service conform to standard formats, then service quality is ensured, but the process becomes costly and time-intensive
Solution Approach 1:
Service templates are pre-validated to ensure they conform to standard formats and specifications before being used for service instantiation. This preliminary validation of the template structure ensures that all services derived from these templates inherit correctness, eliminating the need for extensive testing of each individual service deployment
Solution Approach 2:
By copying proven, pre-validated service templates to create new services, the system inherits the correctness and conformity of the original templates. This copying mechanism ensures service quality without requiring redundant testing, as the template's pre-established validity is transferred to all its instantiations
Data Source
AI summary
A method and apparatus for implementing new services is disclosed whereby a model of the system implementing a new service is created by a function referred to herein as a Service Designer and then different views of the service from the perspective of individual OSS subsystems are published at a Service Hub for use in configuring new services. When a request for service arrives at a subsystem in the network, such as an ordering system, that subsystem will illustratively request a view of the service from the Service Hub. This view is representative of the interfaces and attributes common between the requesting subsystem and other network components, with interfaces to the requesting subsystem. The requesting subsystem then uses this view to transmit values of attributes that are defined to be communicated between the requesting subsystem and other network components.