MCX Pre-Established Session Reason Signaling for Authentication Failures
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing MCX networks lack a mechanism to convey precise reason causes for failures during pre-established sessions, such as call terminations or authentication issues, preventing UEs from taking appropriate corrective actions.
Innovation Solution
Introduce a reason cause field in MCPC acknowledgement and disconnect messages to provide detailed reasons for call rejections or disconnections, enhancing the existing reason code field to include specific failure causes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If existing SIP failure reporting mechanisms are used with response codes and reason code headers, then basic failure notification is provided, but precise reason causes for failures during pre-established sessions cannot be conveyed to UEs
Solution Approach 1:
The patent embeds a reason cause information element within existing SIP message structures (ACK, BYE, CANCEL messages). The reason cause is nested inside a Reason header field, which itself is part of the SIP message framework. This nested structure allows conveying detailed failure reasons without creating entirely new message types, thus reducing complexity while improving information completeness.
Solution Approach 2:
The patent introduces an intermediary Reason header field that mediates between the failure occurrence and the UE needing information. This intermediary structure standardizes how reason causes are conveyed, allowing diverse failure reasons to be communicated through a统一 mechanism without requiring direct complex message exchanges between all parties.
2Reliability
If detailed reason cause information is added to MCPC messages, then UEs can take appropriate corrective actions, but message complexity and processing overhead increase
Solution Approach 1:
The patent applies local quality by adding reason cause information selectively to specific SIP messages (ACK, BYE, CANCEL) only when failure information is relevant. Not all messages require detailed reason causes, and the implementation can choose to include reason cause elements only where needed, thus improving reliability without uniformly increasing complexity across all message types.
Solution Approach 2:
The patent changes the parameter structure of existing SIP messages by adding a Reason header field with specific parameters (reason phrase, cause code). This parameter extension allows rich failure information to be conveyed using standardized parameter formats that existing SIP stacks can parse with minimal modification, balancing detail with processing simplicity.
3Loss of information
If reason cause fields are included in all MCPC acknowledgement and disconnect messages, then complete failure information is provided, but message size and transmission overhead increase
Solution Approach 1:
The patent implements partial action by including reason cause fields selectively rather than in all messages. The reason cause information is added to messages where failure notification is actually needed (ACK messages when authentication fails, BYE/CANCEL messages when calls are terminated). This selective approach provides complete information where necessary while avoiding unnecessary data overhead in successful communications.
Solution Approach 2:
The patent extracts only the essential failure reason information into a standardized Reason header field, separating the critical reason cause data from the full message body. This extraction approach conveys the necessary failure information concisely without transmitting redundant data, reducing message overhead while maintaining information completeness.
Data Source
AI summary
A method for sharing a reason cause for a mission critical communication (MCX) communication over pre-established session in an MCC network is provided. The method includes transmitting, to the server, a call initiation request to initiate a call, wherein the call initiation request includes first information on a session type and second information on a resource list, receiving, from the server, a mission critical pre-established session control (MCPC) connect message including a security message, determining whether an authentication for the security message is successful, and transmitting, to the server, a first MCPC acknowledgement message including a reason cause field to inform a reason for terminating the call in response to determining that the authentication for the security message is not successful.