Sh Interface External Identifier Support for MTC
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current standards, such as 3GPP, do not support the use of External Identifiers for the Sh interface between a Home Subscriber Server (HSS) and an application server (AS) in wireless networks, limiting the functionality and future support for Machine-Type Communication (MTC) devices, particularly in handling increasing varieties of applications.
Innovation Solution
Enhancing the Sh interface to support External Identifiers, allowing network devices to generate messages with a user identity field containing the External Identifier in the '@' format, enabling communication and data retrieval between MTC devices and application servers, even when only the External Identifier is available.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If current 3GPP standards are used for the Sh interface, then existing communication functionality is maintained, but support for External Identifiers in MTC applications is limited
Solution Approach 1:
The Sh interface is enhanced to support multiple identifier types (IMSI, MSISDN, and External Identifiers) within the same communication framework. The user identity field is designed to accommodate different identifier formats universally, allowing the interface to function with both traditional and MTC-specific identifiers without requiring separate communication paths
Solution Approach 2:
The user identity field parameters in the Sh interface messages are modified to accept External Identifiers in addition to traditional identifiers. This parameter expansion allows the interface to handle MTC devices while maintaining compatibility with existing identifier-based communication protocols
2Adaptability or versatility
If the Sh interface is enhanced to support External Identifiers, then functionality for MTC devices is improved, but message format complexity increases
Solution Approach 1:
The user identity field is segmented to accommodate different identifier types. The message structure divides the identity representation into distinct formats (IMSI format, MSISDN format, and External Identifier format), allowing each type to be handled according to its specific requirements while maintaining a unified message structure
Solution Approach 2:
Instead of creating separate message formats for different identifier types, the approach inverts the problem by making the user identity field flexible to accept any identifier type. The enhancement allows External Identifiers to be treated similarly to traditional identifiers, reversing the conventional approach where new identifier types would require entirely new message structures
3Adaptability or versatility
If only IMSI is used for user identification, then existing network devices can communicate, but MTC applications requiring External Identifiers cannot function
Solution Approach 1:
The user identity field is designed to be universal, accepting IMSI, MSISDN, and External Identifiers interchangeably. This multi-functionality ensures that existing networks using IMSI continue to operate reliably while new MTC applications using External Identifiers can also function through the same reliable Sh interface communication path
Data Source
AI summary
A network device obtains an External Identifier for a user device. The External identifier includes a “<Local Identifier>@<Domain Identifier>” format. The network device generates a message, the message including a user identity field for the user device. The user identity field includes the External Identifier. The network device sends, to another network device, the message via an Sh interface.