Mobile Device Domain Switching via Rejection Messages
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing wireless communication systems do not effectively handle call failures by automatically reattempting calls in a different domain, such as switching from circuit switched to packet switched domains or vice versa, leading to dropped connections due to resource overload or channel unavailability.
Innovation Solution
A system and method for mobile devices to interpret rejection messages and reattempt calls in a different communication domain, such as from circuit switched to packet switched or vice versa, based on the rejection reason, allowing for network-initiated or user-initiated domain switching during call setup or handover.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a mobile device attempts a call in a specific domain (circuit switched or packet switched), then the call setup process is simplified, but the call may fail due to resource overload or channel unavailability in that domain
Solution Approach 1:
The system dynamically switches between circuit switched and packet switched domains based on real-time network conditions and rejection messages. The mobile device monitors the status of both domains and automatically transitions from a failed domain to an alternative domain, making the call setup process adaptive rather than static.
Solution Approach 2:
The invention changes the domain parameter (from circuit switched to packet switched or vice versa) when a call failure occurs. By modifying this critical parameter based on rejection messages and network conditions, the system enables successful call setup in domains that were previously unavailable.
2Reliability
If the mobile device automatically reattempts calls in alternative domains upon rejection, then call reliability is improved, but the device complexity increases due to additional domain switching logic
Solution Approach 1:
The system uses rejection messages from the network as feedback to trigger domain switching. When a call is rejected in one domain, the mobile device receives feedback information and automatically initiates a new call attempt in the alternative domain, creating a closed-loop feedback mechanism that improves reliability without requiring complex autonomous decision-making.
Solution Approach 2:
The network's rejection message serves as an intermediary that carries information about the failed call and prompts the mobile device to retry in another domain. This intermediary mechanism simplifies the device logic by using network-provided guidance rather than requiring the device to independently analyze network conditions and make switching decisions.
3Ease of operation
If the system allows manual domain selection for call reattempts, then user control is maintained, but call setup time increases due to additional user input requirements
Solution Approach 1:
The mobile device performs self-service by automatically interpreting rejection messages and initiating domain switching without requiring user intervention. The device monitors its own call status, receives rejection information, and autonomously retries in an alternative domain, eliminating the need for manual user input while maintaining simplicity.
Data Source
Figure 1a~1b
Figure 2
Figure 3
AI summary
A system 5 to promote communication in a second domain 30 responsive to a failure in a first domain 20. The system 5 includes a rejection message 50 and a mobile device 10. The rejection message 50 transmitted upon a failure of a call in the first domain 20. The mobile device 10 configured to communicate in both the first domain 20 and the second domain 30. The mobile device 10 configured to attempt the call in the second domain 30 responsive to receiving the rejection message 50 in the first domain 20.