IMS HTTP Message Routing via Segmented Proxy Functions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The IP Multimedia Subsystem (IMS) currently lacks the ability to handle protocols other than SIP, limiting its functionality in providing services that require multiple protocols, such as the HTTP protocol used in services like Push-to-talk Over Cellular (PoC).
Innovation Solution
An extended IMS architecture is introduced, incorporating a first and second proxy function and server function for handling SIP and non-SIP messages respectively, with a new HTTP controller function connected to the Home Subscriber Server via a modified Cx interface, allowing seamless integration and processing of HTTP messages without affecting existing IMS standard procedures.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If IMS uses only SIP protocol for message handling, then the system architecture remains simple and standard-compliant, but the system cannot handle services requiring other protocols like HTTP
Solution Approach 1:
The patent segments the IMS architecture by introducing separate proxy functions (SIP proxy and HTTP proxy) and server functions for different protocols. Each protocol has its own dedicated processing path, allowing the system to handle multiple protocols without creating a monolithic complex structure. The subscriber profile is also segmented to include protocol-specific handling instructions.
Solution Approach 2:
The patent implements multi-functionality by enabling a single IMS core to handle both SIP and HTTP protocols through shared infrastructure elements. The subscriber profile serves as a universal data structure that can be interpreted by different protocol handlers, and the proxy functions coordinate between protocols using common routing and authentication mechanisms.
2Adaptability or versatility
If IMS integrates multiple protocol handlers, then the system can handle diverse services like PoC with HTTP, but the processing complexity and message routing difficulty increase
Solution Approach 1:
The patent applies preliminary action by pre-configuring the subscriber profile with protocol-specific handling instructions and filter criteria before message processing occurs. The profile includes pre-defined routing rules, authentication parameters, and service activation conditions that guide the message routing decision-making process in advance.
Solution Approach 2:
The patent introduces intermediary elements including protocol-specific proxy functions and a unified subscriber profile as a mediator between incoming messages and the core network. These intermediaries translate and route messages to appropriate handlers, simplifying the overall routing complexity by creating clear separation of concerns.
3Adaptability or versatility
If the IMS extends the subscriber profile for non-SIP protocols, then protocol-specific services can be supported, but the existing standard procedures may be affected
Solution Approach 1:
The patent applies local quality by making the subscriber profile extensible with protocol-specific attributes while maintaining backward compatibility. The profile structure includes optional fields and protocol-specific sections that are only activated when needed, allowing new protocols to be added without modifying existing standard processing logic for SIP services.
Solution Approach 2:
The patent implements dynamics by creating a flexible subscriber profile that can adapt its structure based on the detected message type and service requirements. The profile loading and processing mechanism dynamically activates only the necessary protocol handlers and routing rules, ensuring that standard procedures remain unchanged while enabling protocol extensions when required.
Data Source
AI summary
An IP Multimedia Subsystem, IMS, for providing a service via a network to at least one subscriber, the system comprising: at least a first proxy function and a first server function for handling messages with a first protocol, a subscriber database connected via a first interface to the server function, at least a second proxy function and a second server function for handling messages with a second protocol, the second server functionally is connected via a second interface to the database.