Mobile-Terminated Call Handling for Latency-Sensitive Services
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Mobile devices with latency-sensitive services face disruptions when receiving mobile terminated calls due to latency-prone service commands that compromise the ongoing service, leading to unnecessary interruptions or missed calls.
Innovation Solution
A processor-based system in user equipment determines the radio access technology used for latency-sensitive services and handles mobile terminated calls by rejecting or allowing alerts based on the presence of latency-prone service commands, ensuring the service is not compromised, and allowing alerts if the service command is not latency-prone.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If mobile terminated call alerting is allowed during latency-sensitive service, then user can be notified of incoming calls, but the latency-sensitive service may be compromised
Solution Approach 1:
The patent implements dynamic call handling behavior that adapts based on the active service type. When a latency-sensitive service is detected, the system automatically switches to allowing MT call alerting without compromising the service, whereas traditional static settings force auto-rejection. This dynamic adaptation resolves the contradiction by making the call alerting behavior flexible rather than fixed.
Solution Approach 2:
The system changes the operational parameter of MT call handling from a static auto-reject setting to a dynamic state that allows alerting when LSS is active. This parameter change enables the system to maintain service continuity while allowing call notifications, resolving the contradiction between ease of operation and service reliability.
2Reliability
If static user settings auto-reject all MT calls to protect LSS, then service continuity is maintained, but legitimate calls may be missed
Solution Approach 1:
The patent replaces static auto-reject settings with dynamic call handling that responds to the active service state. When no latency-sensitive service is active, the system allows MT call alerting normally, preventing missed calls. When LSS becomes active, it dynamically adjusts to allow alerting without compromise. This dynamic behavior eliminates the information loss of missed calls while maintaining service continuity.
Solution Approach 2:
The system implements feedback mechanisms that monitor the state of latency-sensitive services and automatically adjust MT call handling behavior accordingly. This feedback loop ensures that call alerting is permitted when appropriate, preventing missed calls while protecting service continuity when needed.
3Ease of operation
If radio access technology changes are made to handle MT calls, then call connectivity is improved, but latency-sensitive service performance deteriorates
Solution Approach 1:
The patent implements dynamic control over RAT changes based on active service detection. When a latency-sensitive service is active, the system dynamically prevents RAT changes that would compromise service performance, while still allowing MT call alerting. This dynamic approach maintains call connectivity capability without incurring the time loss that would result from forced RAT transitions.
Solution Approach 2:
The system takes preliminary anti-action by detecting active latency-sensitive services and preemptively preventing RAT changes that would deteriorate service performance. This preliminary measure blocks potential harmful actions (RAT changes) before they can occur, maintaining service latency performance while preserving call connectivity through alerting.
Data Source
AI summary
Various embodiments include methods and user equipment (UE) for mobile-terminated call handling when a latency-sensitive service (LSS) is active on the UE. Embodiments may include determining a radio access technology (RAT) used for a latency-sensitive service (LSS) currently active on the UE in response to receiving an MT call invitation and determining whether a latency-prone service command is received that includes service commands configured to change the determined RAT used for the LSS to another RAT likely to compromise the LSS. In response to determining that a latency-prone service command is received the MT call invitation may be rejected, but in response to determining that a latency-prone service command is not received, MT call alerting may be allowed.