Cross-domain orchestrator decomposes service requests
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The complexity of integrating multiple controllers from different vendors across various technology domains makes it challenging to automate cross-domain end-to-end services, leading to increased costs and extended implementation timelines.
Innovation Solution
A cross-domain orchestrator decomposes service requests into domain-level intents, communicates boundary conditions between domains, and delegates local optimization to domain orchestrators, enabling automated and optimized provisioning of end-to-end services across multiple domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple controllers from different vendors are integrated across technology domains to fulfill customer requirements, then service functionality and adaptability are improved, but integration complexity and implementation costs increase
Solution Approach 1:
The patent segments the monolithic service orchestration into domain-specific orchestrators (DC domain orchestrator, IP transport domain orchestrator, 5G-core domain orchestrator, 5G-RAN domain orchestrator, Optical domain orchestrator, IP routing domain orchestrator) that operate independently within their respective domains. Each orchestrator manages only the controllers and resources within its domain, eliminating the need for a single complex integration point and reducing overall system complexity while maintaining multi-vendor functionality.
Solution Approach 2:
The patent introduces a service model as an intermediary layer that defines the desired end-to-end service characteristics and constraints. This service model acts as a mediator between customer requirements and domain-specific implementations, allowing different vendor controllers to be integrated through a standardized interface without direct complex interconnections.
2Manufacturing precision
If customized development effort is performed to engineer integration between domains for each deployment, then integration precision and service optimization are improved, but implementation time and costs increase
Solution Approach 1:
The patent performs preliminary action by pre-defining service models that capture domain constraints, resource capabilities, and integration requirements before actual service deployment. The service models are created in advance and can be reused across multiple deployments, eliminating the need for repeated customized development while maintaining integration precision through the structured service model framework.
Solution Approach 2:
The patent creates universal service models that can be applied across multiple domains and deployments. The service model framework provides a multi-functional template that handles various service types (bandwidth allocation, latency constraints, quality of service requirements) in a unified manner, reducing the need for customized development for each new deployment while maintaining precise integration control.
3Reliability
If domain constraints and boundary conditions are explicitly defined and exchanged between domains, then service reliability and constraint satisfaction are improved, but communication overhead and system complexity increase
Solution Approach 1:
The patent applies local quality by having each domain orchestrator define and enforce its own domain-specific constraints and boundary conditions locally. Each orchestrator maintains knowledge of its domain's specific requirements (e.g., DC domain resource constraints, IP transport QoS parameters, 5G-RAN radio conditions) and communicates only the necessary boundary conditions to adjacent domains, reducing unnecessary communication overhead while ensuring reliable constraint satisfaction within each domain.
Data Source
AI summary
Presented herein are techniques to automatically provision cross-domain end-to-end services. A method includes receiving, at a cross-domain orchestrator, a request for a service, decomposing the request for the service into a first provisioning command and into a second provisioning command, sending the first and second provisioning commands to the first and second domains, respectively, receiving, from the first domain, in response to the first provisioning command, a first constraint associated with the first resource of the first domain, receiving, from the second domain, in response to the second provisioning command, a second constraint associated with the second resource of the second domain, distributing the first constraint to the second domain, and the second constraint to the first domain; and initiating, based on the first and second constraints, the service using the first resource of the first domain and the second resource of the second domain.