LTE Mobile Device Emergency Call Domain Switching

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In LTE wireless communication systems, emergency calls often experience delays due to network capacity limitations and inability to handle simultaneous calls, especially during disasters, as UEs determine call types before requesting the network, leading to automatic RRC connection releases and failure to find suitable cells supporting IMS emergency calls.

Innovation Solution

A method where mobile devices in LTE systems determine the service domain after acquiring network capability, allowing for seamless switching to alternative domains like CS fallback to legacy networks if IMS is not supported, thereby avoiding RRC connection releases and enabling efficient emergency call origination without user intervention, and load balancing by distributing calls across IMS and CS domains.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If the UE determines the call type before sending a request to the network, then the UE can select the appropriate service domain, but the network may reject the request if it does not support the determined call type, causing call delays

Engineering Contradiction:
ImproveUE call type determinationVSAvoidemergency call delay
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

Instead of the UE determining the call type before requesting service (forward approach), the invention inverts the approach by having the network indicate the supported service domain first, and then the UE determines the call type based on this indication. This resolves the contradiction by eliminating the rejection risk while maintaining efficient call type selection.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The network performs a preliminary action by indicating the supported service domain (IMS or CS) before the UE attempts to establish a call. This advance information allows the UE to properly determine the call type without risking rejection, thereby preventing call delays while maintaining operational efficiency.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If the UE autonomously releases the RRC connection to find a new cell supporting IMS emergency calls, then the UE can attempt to connect to a supporting cell, but this process delays the emergency call origination

Engineering Contradiction:
ImproveIMS emergency call connectionVSAvoidcall origination delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The network performs a preliminary indication of IMS emergency call support status before the UE attempts connection. This allows the UE to avoid unnecessary RRC connection releases and cell searches when the current cell already supports IMS emergency calls, thereby maintaining reliable connectivity while eliminating unnecessary delays.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The network provides feedback information (indication) to the UE about whether it supports IMS emergency calls. This feedback mechanism allows the UE to make informed decisions about whether to maintain the current connection or search for alternative cells, optimizing both connection reliability and response time.

Inventive Principle:
Principle #23Feedback

3Reliability

If the UE performs a Tracking Area Update procedure to notify the core network of geographical location change, then the UE can register with the new cell, but this procedure delays the IMS emergency call origination

Engineering Contradiction:
Improvenetwork registrationVSAvoidemergency call delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The network provides preliminary indication information about IMS emergency call support status that remains valid across tracking areas. This allows the UE to determine call type without performing a full Tracking Area Update procedure when moving between cells, maintaining reliable network registration while significantly reducing the time required for emergency call origination.

Inventive Principle:
Principle #10Preliminary action

4Reliability

If the UE disables capability of the serving RAT and limits to exclusive way for originating emergency call, then the UE can ensure emergency call origination, but this turns down all possibilities of emergency call originations

Engineering Contradiction:
Improveemergency call originationVSAvoidemergency call methods
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The invention makes the emergency call origination method dynamic by allowing the UE to adapt between IMS-based and CS-based emergency calls based on the network's indicated capability. Instead of disabling RAT capability or limiting to one method, the system dynamically selects the appropriate service domain, ensuring reliable emergency call origination while maintaining versatility and adaptability to different network conditions.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP2498473B1Method of handling call orgination and related communication device
Publication Date: 2015.09.09 HTC CORP
  • EP2498473B1 patent drawingFigure 1
  • EP2498473B1 patent drawingFigure 2
  • EP2498473B1 patent drawingFigure 3

AI summary

A communication device (20) for handling call origination in a wireless communication system (10) is disclosed. The communication device (20) camping on a first cell and comprising: means for originating a service; means for establishing a radio resource control, hereinafter called RRC, connection corresponding to the service; means for receiving a message from a first network via the RRC connection; means for determining whether the first network supports the service of a first service domain, according to the message; and means for performing the service in a second service domain when the first network does not support the service of the first service domain, whereby the RRC connection is not released by the communication device (20).