Patent Publication Number: US-10791443-B2

Title: System and method for enhanced messaging using external identifiers

Description:
BACKGROUND 
     Machine-type communication (MTC) allows systems to communicate with other devices without manual human interaction. MTC may include a wide range of applications for interaction between devices, such as Internet of Things (IoT) technology, monitoring and control for industrial automation, logistics, Smart Grid, Smart Cities, health, defense, etc. The data transferred during MTCs may include different types and sizes that may be associated with different applications. For example, MTC may include short messages, multimedia messages, etc. 
     Machine-type communications may be transmitted over high-speed data transmission networks, such as a Third Generation Partnership Project (3GPP) network. 3GPP provides system specifications that cover telecommunications network technologies, including radio access, the core transport network, and service capabilities (e.g., work on codecs, security, quality of service, etc.). 3GPP specifications also cover non-radio access to the core network, and interworking with Wi-Fi networks. 
     Since MTC technology has nearly limitless applications that can be leveraged to form new and useful services, interest among service providers and developers in MTC technology continues to increase. Supporting the growing number of connected devices, including those using MTC technology, presents a significant challenge for providers of network services. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an exemplary network in which systems and methods described herein may be implemented; 
         FIG. 2  is a block diagram showing exemplary communication interfaces in a portion of the network of  FIG. 1 ; 
         FIG. 3  is a block diagram illustrating components of a network device of  FIG. 1 ; 
         FIG. 4  is a diagram illustrating an example of a table including user identities available when using the Sh interface, according to an implementation described herein; 
         FIG. 5  is a diagram illustrating an example of a user data request (UDR) format, according to an implementation described herein; 
         FIG. 6  is a flow chart showing an exemplary process for using an External Identifier over an Sh interface, according to an implementation described herein; 
         FIG. 7  is a diagram illustrating exemplary communication flows for implementing an External Identifier over an Sh interface for a use case, according to an implementation described herein; and 
         FIG. 8  is a diagram illustrating exemplary communication flows for implementing an External Identifier over an Sh interface for another use case, according to another implementation described herein. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. The following detailed description does not limit the invention. 
     It is anticipated that the standard 15 digit number structure of the international public telecommunication numbering plan (International Telegraph Union Telecommunication Standardization Sector (ITU-T) recommendation E.164) will not be sufficient to support the vast number of MTC devices in the near future. Furthermore, for some IoT applications, a mobile directory number (MDN) as a subscriber identity is not needed. To address the growing number of MTC devices, some standards (e.g., 3GPP, section 19.7.2 of TS 23.003) have adopted an External Identifier (e.g., “&lt;Local Identifier&gt;@&lt;Domain Identifier&gt;” format) as an additional identifier for MTC devices to facilitate MTC device communication. Under the standards, user equipment (UE) with one International Mobile Subscriber Identity (IMSI) may have one or several globally unique External Identifiers. The External Identifiers may be stored in associated “user subscription” data within a Home Subscriber Server (HSS) of the user&#39;s home network. Each External identifier can be used to identify one of multiple MTC devices associated with the UE. However, use of External Identifiers is not restricted to MTC applications. 
     Currently, standards, such as 3GPP for example, do not support use of the External Identifier for the Sh interface between an HSS and an application server (AS). In many cases, the Sh interface is a versatile interface applicable to various purposes within a wireless network. For example, a Policy Charging Rules Function (PCRF) may want to store an MTC device&#39;s charging related data in an HSS. As another example, a voice control server for an MTC device may want to store an MTC UE&#39;s voice communication rule in the HSS. Without enhancement for the Sh interface to support External Identifiers, the usage of the External Identifier is limited in the wireless network, especially in terms of future support for an increasing variety of applications for MTC devices. For example, without an Sh interface supporting an External Identifier, if an AS only knows a UE&#39;s External Identifier (which may likely be the case for many future applications), the AS will not be able to retrieve a UE&#39;s HSS data for further processing to fulfill the objective of an application. An AS may want to send a short message service (SMS) message to the UE, while the network only handles SMS messages based on a user&#39;s private identifier (e.g., an IMSI, mobile station international subscriber directory number (MSISDN), or a mobile directory number (MDN)). Without retrieving the UE&#39;s private identifier the AS will not, be able to send the SMS message to the UE. Thus, enhancement of the Sh interface to support External Identifiers is needed to continue to promote and enhance usage of new MTC services. 
     According to an implementation described herein, a network device may obtain an External Identifier for a user device. The External Identifier includes a “&lt;Local Identifier&gt;@&lt;Domain Identifier&gt;” format. The network device may generate a message, the message including a user identity field for the user device. The user identity field includes the External Identifier. The network device may send, to another network device in a different network, the message via an Sh interface. 
       FIG. 1  is a block diagram of an exemplary network  100  in which systems and methods described herein may be implemented. Network  100  may include a service provider network  102 , an external network  104 , and a UE device  106 . 
     Service provider network  102  may include one or multiple networks of one or multiple types. For example, service provider network  102  may be implemented to include a terrestrial network, a satellite network, a wireless network, and/or a wired network. According to an exemplary implementation, service provider network  102  includes a radio access network (RAN). The RAN may be a Third Generation (3G) RAN, a Fourth Generation (4G) RAN, a 5G RAN, a future generation wireless network architecture, etc. By way of further example, access network  105  may include an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) of a Long Term Evolution (LTE) network or LTE-Advanced (LTE-A) network, a U-TRAN, Universal Mobile Telecommunications System (UMTS) RAN, a Global System for Mobile Communications (GSM) RAN, or the like. Service provider network  102  may provide access to external network  104  for wireless devices, such as LIE device  106 . Service provider network  102  may provide mobile telephone service and/or data services to UE device  106 . For example, service provider network  102  may establish a packet data network connection (e.g., an Internet Protocol (IP) connection) between UE device  106  and external network  104 . In some implementations, service provider network  102  may include a core transport network, such as a LTE access network (e.g., an evolved packet core (EPC) network) based on the LTE standard specified by the 3GPP. 
     Service provider network  102  may include one or more eNodeBs  110 , mobility management entity (MME) devices  120 , serving gateways (SGW)  130 , packet data network (PDN) gateways (PGW)  140 , home subscriber server (HSS)/home location register (HLR)/Authentication, Authorization, and Accounting (AAA) devices  150 , policy and charging rules function (PCRF) devices  160 , a call session control function (CSCF)  170 , and a mobile switching center (MSC)/SMS-Interworking Function (SMS-IWF)  190 . While service provider network  102  is shown in the context of a Long Term Evolution (LIE) network, it should be appreciated that embodiments presented herein may operate in any appropriate wireless network(s), such for example, Internet Protocol Multimedia Subsystem (IMS) networks, 3G networks, LTE/4G networks, or 5G networks. 
     External network  104  includes one or multiple networks of one or multiple types. For example, external network  104  may be implemented as an IMS network, a service or application-layer network, an IP network, the Internet, a proprietary network, a cloud network, a data network, etc. External network  104  may include application servers (AS)  180 , among other devices (not shown). 
     UE device  106  (also referred to herein as a “user device”) may include a handheld wireless communication device (e.g., a smart phone, etc.); a wearable computer device; a global positioning system (GPS) device; a laptop or tablet computer; a portable gaming system; a home appliance device; a home monitoring device; an MTC device; and/or any other type of computer device with wireless communication capabilities. In other implementations, UE device  106  may correspond to an embedded wireless device that communicates wirelessly with other devices over a machine-to-machine (M2M) interface using MTC and/or another type of M2M communication. 
     eNodeB  110  may use the Evolved Universal Terrestrial Radio Access (E-UTRA) air interface to wirelessly communicate with devices, such as UE device  106 . eNodeB  110  may include one or more devices (e.g., base stations) and other components and functionality that allow UE device  106  to wirelessly connect to service provider network  102 . 
     MME device  120  (also referred to herein simply as “MME  120 ”) may implement control plane processing for service provider network  102 . For example, MME  120  may implement tracking and paging procedures for UE device  106 , may activate and deactivate bearers for UE device  106 , may authenticate a user of UE device  106 , and may interface to non-LTE radio access networks. 
     SGW  130  may provide an access point to and from UE device  106 , may handle forwarding of data packets for UE device  106 , and may act as a local anchor point during handover procedures between eNodeBs  110 . 
     PGW  140  may function as a gateway to external network  104 . A particular UE device  106 , while connected to a single SGW  130 , may be connected to multiple PGWs  140 —one for each packet network with which UE device  106  communicates. PGW  114  may enforce policies from PCRF  116 , such as uplink and downlink data speeds, for individual sessions by UE device  106 . 
     HSS/HLR/AAA device  150  (also referred to herein simply as “HSS  150 ”) may store information associated with UE devices  106  and/or information associated with users of UE devices  106 . For example, HSS device  120  may stor user profiles, such as a Subscriber Profile Repository (SPR), that include authentication and access authorization information. The subscriber profile may also identify particular services, to which the user has subscribed, that are to be provided when an online charging action is to be performed. In one implementation, HSS  150  may be implemented as an HLR, which includes a central database containing details of subscriber devices that are authorized to access a wireless network. In other implementations, the HSS may be implemented as a User Profile Server Function (UPSF). As an AAA function, HSS  150  may verify a subscriber&#39;s identity, authenticate and/or authorize UE device  106  using a device identification number (e.g., by performing IMSI or MAC authentication), authorize a particular service, and/or track consumption of network resources for a user. 
     PCRF device  160  (also referred to herein simply as “PCRF  160 ”) provides policy control decision and flow-based charging control functionalities. PCRF  160  may include a network device, server device, or a distributed component. PCRF  160  may provide network control regarding service data flow detection, gating, quality of service (QoS) and flow-based charging, etc. PCRF  160  may determine how a certain service data flow shall be treated, and may ensure that traffic mapping and treatment is in accordance with a user&#39;s subscription profile. 
     CSCF  170  may handle signaling, controlling of media paths, and activation of applications in external network  104 . CSCF may include one or more Proxy Call Session Control Functions (P-CSCF), serving Call Session Control Functions (S-CSCF), and Interrogating Call Session Control Functions (I-CSCF). 
     AS  180  may implement particular services and interact directly or indirectly with devices in service provider network  102  (e.g., HSS  150 , CSCF  170 , etc.) to deliver the particular applications and/or services to UE device  106 . For example, AS  180  may be implemented to provide an M2M application or service, or other type of application and/or service (e.g., an end user application, an end user service, etc.). 
     MSC/SMS-IWF  190  may be responsible for managing communications between the UE device  106  and the other elements of external network  104 . As an MSC, MSC/SMS-IWF  190  may handle voice calls and messaging service message requests as well as other services (such as conference calls, FAX and circuit switched data, messaging service communications, Internet access, etc.). As an SMS-IWF, MSC/SMS-IWF  190  may function as an interface device between AS  180  and service provider network  102 . For example, MSC/MTC-IWF  190  may implement a control plane interface with elements of service provider network  102  and may generate a request message such as a request to authenticate UE device  106  and/or a request to wake up UE device  106 —to a particular element of service provider network  102  based on a request received from AS  180 . MSC/MTC-IWF  190  may receive an indication from service provider network  102  that UE device  106  has woken up and is ready for communicating with AS  180  and may inform AS  180  that UE device  106  has woken up and is ready for communication. 
     It is noted that  FIG. 1  depicts a representative network  100  with exemplary components and configuration shown for purposes of explanation. Other embodiments may include additional or different network entities in alternative configurations than those which are shown in  FIG. 1 . For example, one or more components of network  100  may perform multiple functions, including those described as being performed by one or more other components. Additionally, or alternatively, one or more network devices indicted as part of one network (e.g., service provider network  102 ) could be included in a different network (e.g., external network  104 ). 
       FIG. 2  is a diagram illustrating an example of communication interfaces in a portion  200  of network  100 . As shown in  FIG. 2 , network portion  200  may include MME  120 , HSS  150 , CSCF  170 , AS  180 - 1  through  180 -X (referred to herein generically as “AS  180 ”), and MSC/MTC-IWF  190 . 
     As shown in  FIG. 2 , each AS  180  may communicate with HSS  150  through an Sh interface  210 . CSCF  170  may communicate with HSS  150  through a Cx interface  220 . MME  120  may communicate with HSS  150  through an S6a interface  230 . Sh interface  210 , Cx interface  220 , and Sha interface  230  may be implemented, for example, using the Diameter protocol. 
     MSC/MTC-IWF  190  may communicate with HSS  150  through a Mobile Application Part (MAP) D interface  240 . MAP interface  240  may be implemented, for example, using the Signaling System No. 7 (SS7) protocol. 
     According to implementations described herein, Sh interface  210  provides an enhancement (i.e., over the prior standard Sh interface) to support an External Identifier. More particularly, a UE&#39;s (e.g., UE device  106 ) External Identifier will be allowed to be used over Sh interface  210  as a query identifier to enable querying of UE device&#39;s  106  data stored at HSS  150 , such as, for example: the UE&#39;s all identities data (IMSI, MSISDN, IMS private identity, IMS public identities, implicit identities, and registered identities), the UE&#39;s application repository data, the UE&#39;s circuit-switched (CS) location data, the UE&#39;s packet-switched (PS) location data, the UE&#39;s evolved packet system (EPS) location data, UE&#39;s CS user state, UE&#39;s PS user state, UE&#39;s EPS user state, UE&#39;s CSCF name, UE&#39;s charging info, UE&#39;s IMS initial filter criteria (IFC) data, etc. 
     Sh interface  210  also allows AS  180  to receive the UE&#39;s IMSI or private ID based on the UE&#39;s External Identifier. Such an exchange is important because some network elements in a wireless network only support using IMSI to identify a UE device. For example, an SMS Center (SMSC) may only support using IMSI network signaling communication. With the Sh enhancement described herein, a network element or application server that has only an External Identifier of UE device  106 , may use Sh interface  210  to retrieve (e.g., from HSS  150 ) an IMSI, a private ID, and other subscriber information for UE device  106 . 
     Although  FIG. 2  shows exemplary components of network portion  200 , in other implementations, network portion  200  may include fewer components, different components, additional components, or differently arranged components than depicted in  FIG. 2 . 
       FIG. 3  is a block diagram showing exemplary components of a network element  300 , according to an embodiment. One or more of eNodeB  110 , MME  120 , SGW  130 , PGW  140 , HSS/HLR/AAA  150 , PCRF  160 , CSCF  170 , AS  180 , MSC/SMS-IWF  190  may be implemented as a network element  300 . Network element  300  may include a bus  310 , a processor  320 , a memory  330 , mass storage  340 , an input device  350 , an output device  360 , and a communication interface  370 . 
     Bus  310  includes a path that permits communication among the components of network element  300 . Processor  320  may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor  320  may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic. For example, processor  320  may be an x86 based CPU, and may use any operating system, which may include varieties of the Windows, UNIX and/or Linux. Processor  320  may also use high-level analysis software packages and/or custom software written in any programming and/or scripting languages for interacting with other network entities that are communicatively coupled to network  100 . 
     Memory  330  may include any type of dynamic storage device that may store information and/or instructions, for execution by processor  320 , and/or any type of non-volatile storage device that may store information for use by processor  320 . For example, memory  330  may include a RAM or another type of dynamic storage device, a ROM device or another type of static storage device, and/or a removable form of memory, such as a flash memory. Mass storage device  340  may include any type of on-board device suitable for storing large amounts of data, and may include one or more hard drives, solid state drives, and/or various types of arrays. 
     Input device  350 , which may be optional, can allow an operator to input information into network element  300 , if required. Input device  350  may include, for example, a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, and/or another type of input device. In some embodiments, network element  300  may be managed remotely and may not include input device  350 . Output device  360  may output information to an operator of network element  300 . Output device  360  may include a display, a printer, a speaker, and/or another type of output device. In some embodiments, network element  300  may be managed remotely and may not include output device  360 . 
     Communication interface  370  may include a transceiver that enables network element  300  to communicate within network  100  with other devices and/or systems. The communication interface  370  may be configured for wireless communications radio-frequency, infrared, and/or visual optics, etc.), wired communications conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. Communication interface  370  may include a transmitter that converts baseband signals to RF signals and/or a receiver that converts RF signals to baseband signals. 
     As described below, network element  300  may perform certain operations relating to server and/or gateway operations. Network element  300  may perform these operations in response to processor  320  executing software instructions contained in a computer-readable medium, such as memory  330  and/or mass storage  340 . A computer-readable medium may be defined as a non-transitory memory device. A non-transitory memory device may include memory space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory  330  from another computer-readable medium or from another device. The software instructions contained in memory  330  may cause processor  320  to perform processes described herein, such as, for example, process  600  depicted in  FIG. 6 . Alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. 
     Although  FIG. 3  shows exemplary components of network element  300 , in other implementations, network element  300  may include fewer components, different components, additional components, or differently arranged components than depicted in  FIG. 3 . 
     As noted above, current specifications for the Sh interface, such as for example, the current 3GPP specification, support information elements for IMS Public User Identity/Public Service Identity and MSISDN.  FIG. 4  shows an example of a table  400  including user identities available when using the Sh interface according to an implementation described herein. Table  400  may correspond, for example, to how a table could be modified to include an additional information element (IE) for the External Identifier. As shown in  FIG. 4 , table  400  may include an information element name field  410 , a mapping to diameter attribute value pair (AVP) field  420 , a category field  430 , and a description field  440 . Entries  450  and  460  may correspond to information elements supported in the Sh interface. Particularly entry  450  may correspond to IMS Public User Identity/Public Service Identity and entry  460  may correspond to MSISDN. 
     Entry  470  may identify features of a new information element for an External Identifier. Thus, the name in information element name field  410  for entry  470  may be “External identifier.” The mapping to diameter AVP field  420  for entry  470  may be “External identifier” and may refer to another technical specification and section for HSS diameter interfaces that use the External Identifier. The category in category field  430  may be “C” (conditional), and the description field  440  may include a description of the External Identifier format (e.g., “&lt;Local Identifier&gt;@&lt;Domain Identifier&gt;”) and usage and applicability guidelines (e.g., the same usage and applicability as the MSISDN for the Sh interface). 
     In addition to changes to user identities, such as shown in table  400 , the enhancement of the Sh interface to support External Identifiers may also impact other messaging formats and/or practices. Particularly, External Identifiers may be added to the class of Public Identifiers available for use in the Sh interface (e.g., in addition to the classes IMSPublicIdentity or MSISDN). Additionally, message formats that include descriptions related to the Public User Identity may be updated, for example, as “Public User Identity or External ID.” As another example, the User-Identity AVP in Sh interface messages may be updated to include reference to the External Identifier (e.g., in addition to Public Identity and MSISDN). Furthermore, the Sh interface may also be added to an interface list that supports the External Identifier. These updates may be configured on various network devices, including HSS  150 , AS  180 , etc. 
     Thus, according to implementations described herein, when a network element, such as AS  180 , has only a UE&#39;s External identifier and would like to retrieve the UE&#39;s Sh-IMS-data (e.g., as indicated in section C.3 of TS 29.328), the network element ill be allowed to use the UE&#39;s External Identifier to query HSS  150 . Additionally, when a network element has only UE&#39;s External Identifier and would like to retrieve UE&#39;s other IDs (e.g., including the UE&#39;s MSISDN, IMSI, other External identifiers, IMS private ID, and IMS public IDs), the network element will be allowed to use the UE&#39;s External Identifier to query HSS  150 . 
     With the enhancement of the Sh interface to support External Identifiers, any Sh message that uses the User Identity AVP as a query key may be able to use an External Identifier to query the HSS data. For example, any of User Data Request (UDR), Profile Update Request (PUR), Subscribe Notifications Request (SNR), or Push Notification Request (PNR) over the Sh interface may use the External Identifier in the User Identity AVP of these requests. 
       FIG. 5  includes an example of a UDR format  500 , according to an implementation described herein. When the User Identity AVP field  510  contains an External Identifier (not illustrated) and the Data Reference AVP field  520  indicates “0 (repository data)” (not illustrated) in an Sh UDR message, the application server (e.g., AS  180 ) will be able to use the Sh UDR message to query the user&#39;s application-specific repository data based on the user&#39;s External Identifier. Similarly, by supporting use of the External Identifier in the User Identity AVP, the PUR and SNR Sh messages initiated by AS  180  can support requests to read user&#39;s HSS data or updating user&#39;s application repository data based on the user&#39;s External Identifier. Additionally, a PNR from HSS  150  to AS  180  with an External Identifier may be received and AS  180  may provide a push notification answer (PNA) based on the External Identifier in the PNR. 
       FIG. 6  provides a flow chart showing an exemplary process  600  for implementing an External identifier over an Sh interface, one implementation, process  600  may be performed by a network device, such as AS  180 . In another implementation, process  600  may be performed by AS  180  in conjunction with one or more other devices, such as HSS  150 . 
     Process  600  may include obtaining an External Identifier for a user device (block  605 ). For example, UE device  106  may send a service request to AS  180 . The service request may provide an External Identifier as the only unique identifier for UE device  106 . The service request may require AS  180  to request information from another network device (e.g., a network device in service provider network  102 , such as MME  120 , or a network device in another portion of external network  104 ) over an interface that does not support use of External Identifiers. 
     Process  600  may also include generating a message including the External Identifier for the user device in a user identity field (block  610 ) and sending the message via an Sh interface (block  615 ). For example, in response to receiving the service request from UE device  106 , AS  180  may generate a message, such as a read command (e.g., a UDR), an update command (e.g., a PUR), or a subscribe command (e.g., an SNR). The message may include the External Identifier for UE device  106 . In one implementation, the External identifier may be included in a user identity AVP of the message. AS  180  may send the message to HSS device  150  via a Diameter Sh interface. 
     Process  600  may further include receiving the message, via the Sh interface, at an HSS device (block  620 ); generating a response to the message (block  625 ); and sending, the response from the HSS device to the AS via the Sh interface (block  630 ). For example, HSS  150  may receive the message from AS  180  via the Sh interface. HSS  150  may generate a response, such as a read answer (e.g., a User Data Answer (UDA)), an update answer (e.g., a Profile Update Answer (PUA)), or a notification answer (e.g., a Subscribe Notifications Answer (SNA)). In one implementation, the response may include an identifier (e.g., an IMSI, an MSISDN, an MDN, etc.) for UE device  106  that corresponds or maps to the External Identifier. HSS device  150  may send the response to AS  180  via a Diameter Sh interface. 
     Process  600  may additionally include receiving the response via the Sh interface (block  635 ); extracting from the response another identifier for the user device (block  640 ); and generating a request using the other identifier (block  645 ). For example, AS  180  may receive a UDA or SNA and extract an IMSI, MSISDN, or a MDN for the user device that corresponds or maps to the External Identifier. AS  180  may use the IMSI, MSISDN, or MDN to generate and transmit a query, for example, over another interface that uses the IMSI, MSISDN, MDN, or other type of identifier, but does not support the External Identifier. 
       FIG. 7  illustrates communications for a use case for implementing an External Identifier over an Sh interface in a portion  700  of network  100 . More particularly, the communications of  FIG. 7  represent an application server querying an HSS for a UE&#39;s serving MME identifier using the UE&#39;s External Identifier. As shown in  FIG. 7 , at step S 701 , UE device  106  may send a request to AS  180 - 1  for an MME-related service. The request may include an External Identifier of UE device  106 , but not another UE identifier (such as an IMSI or MDN). At step S 702 , AS  180 - 1  may send a UDR to HSS  150  using an Sh interface (e.g., Sh interface  210 ). The UDR may include the External Identifier for UE device  106  and may request the name of the serving MME (e.g., MME  120 ) for UE device  106 . 
     HSS  150  may receive the UDR and, at step S 703 , may provide a UDA to HSS  150  via the Sh interface (e.g., Sh interface  210 ). The UDA may include the serving MME&#39;s identifier for UE device  106 . AS  180 - 1  may receive the UDA and may use the MME identifier, at step S 704 , to submit a service request to MME  120  via an S6a interface (e.g., S6a interface  230 ) in accordance with the original request (of step S 701 ) from UE device  106 . 
       FIG. 8  illustrates communications for another use case for implementing an External Identifier over an Sh interface in a portion  800  of network  100 . More particularly, the communications of  FIG. 8  represent an application server querying an HSS for a UE&#39;s IMSI for an SMS related service. As shown in  FIG. 8 , at step S 801 , UE device  106  may send a request to AS  180 - 2  for an SMS-related service that requires an IMSI for UE device  106 . The request may include an External Identifier for UE device  106 , but not the IMSI (or another UE identifier). At step S 802 , AS  180 - 2  may send a UDR to HSS  150  using an Sh interface (e.g., Sh interface  210 ). The UDR may include the External Identifier for UE device  106  and may request the IMSI for UE device  106 . 
     HSS  150  may receive the UDR and, at step S 803 , may provide a UDA to HSS  150  via the Sh interface (e.g., Sh interface  210 ). The UDA may include the IMSI for LIE device  106 . AS  180 - 2  may receive the UDA and may use the IMSI, at step S 804 , to submit a service request to MSC/SMS-IWF  190  via a MAP interface (e.g., MAP D interface  240 ) in accordance with the original request (of step S 801 ) from UE device  106 . In one implementation, AS  180 - 2  may temporarily store the IMSI (or another unique identifier corresponding to the External Identifier) for use in subsequent requests from UE device  106 . For example, AS  180 - 2  may store the IMSI during a current session with UE device  106  and subsequently purge the IMSI data when the session is ended. 
     The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. Also, while series of blocks have been described with regard to  FIG. 6  and signal flows with respect to  FIGS. 7 and 8 , the order of the blocks and/or signal flows may be modified in other embodiments. Further, non-dependent blocks may be performed in parallel. 
     Certain features described above may be implemented as “logic,” a “module,” or a “unit” that performs one or more functions. This logic, module, or unit may include hardware, such as one or more processors, microprocessors, application specific integrated circuits, or field programmable gate arrays, software, or a combination of hardware and software. 
     No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” and “one of” is intended to include one or more items. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. The term “exemplary,” as used herein means “serving as an example.” Any embodiment or implementation described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or implementations. 
     To the extent the aforementioned embodiments collect, store or employ personal information provided by individuals, it should be understood that such information shall be used in accordance with all applicable laws concerning protection of personal information. Additionally, the collection, storage and use of such information may be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as may be appropriate for the situation and the type of information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information. 
     In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.