Split Deployment Model for Telecommunication Service Access Gateway

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current telecommunications gateway systems lack modularity, scalability, and ease of management, making it difficult to independently upgrade or scale services without impacting others, and require improved security and integration with third-party applications.

Innovation Solution

A split deployment model for telecommunications gateways, where core services and exposure services are segregated into separate archive files, allowing independent upgrading, patching, and scaling of services, with exposure services deployed in separate files to reduce impact on other components and enable flexible resource allocation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If gateway services are deployed as a monolithic system, then system integration and management are simplified, but the ability to independently upgrade or scale individual services is lost

Engineering Contradiction:
ImproveIndependent service upgrade capabilityVSAvoidGateway deployment structure
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The gateway system is segmented into distinct service components (e.g., SMS service, MMS service, email service) that can be independently deployed, upgraded, and scaled. Each service is packaged as a separate module that can be managed independently while still functioning as part of the overall gateway system.

Inventive Principle:
Principle #1Segmentation

2Productivity

If all gateway services are deployed together in a single package, then deployment management is easier, but scaling individual services requires redeploying the entire system

Engineering Contradiction:
ImproveService scaling efficiencyVSAvoidTime for system redeployment
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

Services are divided into independent deployable units that can be scaled individually. When scaling is needed, only the specific service module requires additional resources or replication, not the entire gateway system.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The gateway platform provides universal deployment mechanisms that can handle multiple service types through a common framework. This allows individual services to be scaled independently while utilizing shared infrastructure and management capabilities.

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

3Reliability

If gateway services are tightly coupled, then system integration is simpler, but a failure or update in one service impacts all other services

Engineering Contradiction:
ImproveService isolation and fault containmentVSAvoidService deployment architecture
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

Services are segmented into isolated modules with defined interfaces. This segmentation ensures that failures, updates, or changes in one service module do not propagate to other modules, containing issues within their respective boundaries while maintaining overall system reliability.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS8296464B2System and method for providing a split deployment model for a telecommunication service access gateway
Publication Date: 2012.10.23 ORACLE INT CORP
  • US8296464B2 patent drawing
  • US8296464B2 patent drawing
  • US8296464B2 patent drawing

AI summary

A split deployment model is enabled for a telecommunication service access gateway. The services of the gateway are segregated into a set of core services that provide container-based functionality and a set of exposure services that enable network integration and translation of protocols. The core services are executed as part of the application server, while the exposure services are deployed in separate archive files. This isolation of services allows single or groups of services to be independently upgraded, patched or removed and reduces the impact of one service on others. Furthermore, the services can scale independently, allowing additional hardware resources to be added to a particular service. Multiple versions of a single service can also be deployed in a single cluster or server.