US20140086147A1 - Enhanced registration messages in internet protocol multimedia subsystems - Google Patents
Enhanced registration messages in internet protocol multimedia subsystems Download PDFInfo
- Publication number
- US20140086147A1 US20140086147A1 US14/029,623 US201314029623A US2014086147A1 US 20140086147 A1 US20140086147 A1 US 20140086147A1 US 201314029623 A US201314029623 A US 201314029623A US 2014086147 A1 US2014086147 A1 US 2014086147A1
- Authority
- US
- United States
- Prior art keywords
- mobile device
- location
- requesting mobile
- imei
- requesting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1073—Registration or de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/025—Services making use of location information using location based information parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/029—Location-based management or tracking services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
- H04W64/003—Locating users or terminals or network equipment for network management purposes, e.g. mobility management locating network equipment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/08—Upper layer protocols
- H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/18—Service support devices; Network management devices
Definitions
- IMS Internet Protocol Multimedia Subsystems
- IP Internet Protocol
- IMS core An IMS core network (“IMS core”) permits wireless and wireline devices to access multimedia, messaging, and voice applications and services.
- IMS standards and specifications have been promulgated by the 3rd Generation Partnership Project (“3GPP”TM) To ease the integration of an IMS core with Internet resources, 3GPP specifications use Internet Engineering Task Force protocols within the IMS core, such as Session Initiation Protocol (“SIP”) and Diameter.
- SIP Session Initiation Protocol
- Diameter Diameter
- SIP is a signaling protocol used for creating, modifying and terminating two-party or multiparty sessions consisting of one or several media streams.
- a mobile device registers its IP address with a SIP registrar server within an IMS core by generating and sending a SIP request message with a “REGISTER” method token. Once registered, a mobile device may subsequently establish multimedia sessions via the IMS core.
- Standard IMS registration techniques may not permit an IMS core to ascertain the IMEI of a mobile device seeking registration.
- standard IMS registration techniques may not permit an IMS core to ascertain the hardware and software capabilities of a particular mobile device so that the IMS core may intelligently provision services to the mobile device.
- FIG. 1 is a diagram of a representative environment in which enhanced registration messages may be utilized.
- FIG. 2 illustrates an example of an enhanced SIP registration message having extended header information.
- FIG. 3 shows a table schema that conceptually illustrates how a capability database stores location determination capabilities of a mobile device in association with an IMEI that identifies the mobile device.
- FIG. 4 is a logical flow diagram of a process for utilizing a SIP registration message having extended header information in order to determine the registration status of a mobile device and determine the location of the mobile device.
- An enhanced Session Initiation Protocol (“SIP”) registration message having extended header information that is used by an Internet Protocol Multimedia Subsystem (“IMS”) core to determine the registration status of a mobile device and the physical location of the mobile device is disclosed.
- the extended header information includes hardware and subscriber identifiers, such as an International Mobile Equipment Identity (“IMEI”) and International Mobile Subscriber Identity (“IMSI”).
- IMEI International Mobile Equipment Identity
- IMSI International Mobile Subscriber Identity
- the IMS core queries an equipment identity register to validate IMEI/IMSI identifiers in the header to determine whether to deny registration to a mobile device.
- the IMS core also queries a capability database using an IMEI to determine which location determination techniques are supported by or suitable for the associated mobile device.
- FIG. 1 is a diagram of a representative environment 100 in which enhanced registration messages may be utilized.
- mobile devices 102 are configured to communicate with, or through, a trusted radio access network (“RAN”) 104 and/or an untrusted RAN 103 , in order to register with and utilize an IMS core 107 .
- RAN trusted radio access network
- Location-based services are services that use the actual or approximate location of a mobile device to provide, enhance, or supplement a service to the mobile device.
- Location-based services include, but are not limited to, services such as emergency services (e.g., E911), asset tracking or recovery services (e.g., the tracking of a stolen car), location-based alerts or advertising services (e.g., targeted advertisements that depend on the location of a mobile device user), social networking services (e.g., services that report the relative location of friends or family), and/or the like.
- emergency services e.g., E911
- asset tracking or recovery services e.g., the tracking of a stolen car
- location-based alerts or advertising services e.g., targeted advertisements that depend on the location of a mobile device user
- social networking services e.g., services that report the relative location of friends or family
- the device may establish multimedia sessions managed by the IMS core in order to access applications and services that facilitate communication, location-based services and/or other services.
- Mobile devices 102 may include virtually any devices for communicating over a wireless network. Such devices include mobile telephones, such as Global System for Mobile Communications (“GSM”) telephones, Time Division Multiple Access (“TDMA”) telephones, Universal Mobile Telecommunications System (“UMTS”) telephones, Evolution-Data Optimized (“EVDO”) telephones, Long Term Evolution (“LTE”) telephones, Generic Access Network (“GAN”) telephones, Unlicensed Mobile Access (“UMA”) telephones, and other mobile computers or devices, such as Voice over Internet Protocol (“VoIP”) devices, Secure User Plane Location (“SUPL”) Enabled Terminals (SETs), Personal Digital Assistants (“PDAs”), radio frequency devices, infrared devices, handheld computers, laptop computers, wearable computers, tablet computers, pagers, integrated devices combining one or more of the preceding devices, and/or the like.
- GSM Global System for Mobile Communications
- TDMA Time Division Multiple Access
- UMTS Universal Mobile Telecommunications System
- EVDO Evolution-Data Optimized
- LTE Long Term Evolution
- mobile devices 102 may range widely in terms of features and capabilities.
- mobile devices may have widely different hardware and software configurations that affect which location determination techniques may be utilized to locate the physical location of a mobile device (e.g., its latitude and longitude).
- the configuration of a mobile device may affect the performance (e.g., accuracy, precision, time to fix) of a location determination technique used to physically locate the device.
- the configuration of a mobile device may also affect its capability to utilize other types of applications or services besides location-based services. For example, the configuration of a mobile device may affect its capability to use multimedia gaming applications, instant messaging applications, etc.
- Mobile devices 102 typically include a processing unit, volatile memory and/or nonvolatile memory, a power supply, one or more network interfaces, an audio interface, a display, a keypad or keyboard and other input and/or output interfaces.
- the various components of a mobile device may be interconnected via a bus.
- the volatile and nonvolatile memories generally include storage media for storing information such as processor-readable instructions, data structures, program modules, or other data. Some examples of information that may be stored include basic input/output systems (BIOS), operating systems, and applications.
- BIOS basic input/output systems
- the stored information may include one or more SIP clients capable of generating, transmitting and interpreting syntactically correct SIP messages. SIP clients permit the mobile device to register with and communicate via the ISM core 107 .
- IMEI International Mobile Equipment Identity
- GRUU Globally Routable User Agent URI
- an S-CSCF within the IMS core may generate a pseudo-IMEI for a VOIP soft client, an iPAD®, or laptop computer. Such a pseudo-IMEI may then be utilized in the methods described herein.
- Some mobile devices may have one or more unique or semi-unique mobile device hardware identifiers that are comparable to an IMEI, such as a Mobile Equipment Identifier (“MEID”) or Electronic Serial Number (“ESN”).
- MEID Mobile Equipment Identifier
- ESN Electronic Serial Number
- a mobile device 102 may also be associated with an International Mobile Subscriber Identity (“IMSI”), which is an internationally unique number used to identify a mobile subscriber or user.
- IMSI International Mobile Subscriber Identity
- a subscriber's IMSI may be stored in a removable user identity card installed in a mobile device 102 , such as a subscriber identity module (“SIM”) card, Removable User Identity Module (“R-UIM”) card, CDMA Subscriber Identify Module (“CSIM”) card, or a Universal Integrated Circuit Card (“UICC”).
- SIM subscriber identity module
- R-UIM Removable User Identity Module
- CCM CDMA Subscriber Identify Module
- UICC Universal Integrated Circuit Card
- the removable nature of the user identity card allows a user to change mobile devices by simply removing the card from one mobile device and inserting the card into another. Thus, the association between a mobile device and an IMSI may change over time.
- a mobile device may either be permanently or temporarily without a user identity card and therefore not associated with an IMSI.
- Mobile devices 102 may connect to the IMS core 107 by a trusted RAN 104 or an untrusted RAN 103 . Both types of RANs provide a first physical wireless link between mobile devices 102 and the IMS core. A single mobile device may be capable of using one or both types of RANs.
- the RANs 103 , 104 may use any wireless communications and data protocol or standard, such as GSM, TDMA, UMTS, EVDO, LTE, GAN, UMA, Code Division Multiple Access (“CDMA”) protocols (including IS-95, IS-2000, and IS-856 protocols), Advanced LTE or LTE+, Orthogonal Frequency Division Multiple Access (“OFDM”), General Packet Radio Service (“GPRS”), Enhanced Data GSM Environment (“EDGE”), Advanced Mobile Phone System (“AMPS”), WiMAX protocols (including IEEE 802.16e-2005 and IEEE 802.16m protocols), Wireless Fidelity (“WiFi”), High Speed Packet Access (“HSPA”), (including High Speed Downlink Packet Access (“HSDPA”) and High Speed Uplink Packet Access (“HSUPA”)), Ultra Mobile Broadband (“UMB”), SUPL, and/or the like.
- GSM Global System for Mobile Communications
- TDMA Time Division Multiple Access
- UMTS High Speed Downlink Packet Access
- UMB Ultra
- the trusted RAN 104 is a RAN operated by the operator of the IMS core 107 or another trusted party that is associated with the IMS core operator (e.g., the operator's contractor, affiliate, or industry partner). In order to wirelessly communicate via the trusted RAN, a mobile device 102 may need to pass preliminary authentication/authorization checks implemented in part by the trusted RAN.
- the trusted RAN is connected to and communicates with the IMS core via a dedicated backhaul (e.g., a private network that is not open to the public) and intermediary components 106 .
- the intermediary components may include, for example, a Gateway GPRS Support Node (“GGSN”), Serving GPRS Support Node (“SGSN”) or similar components that facilitate mobility management, session management, and transport for IP packet services within the trusted RAN 104 .
- GGSN Gateway GPRS Support Node
- SGSN Serving GPRS Support Node
- the untrusted RAN 103 is a RAN that connects to the IMS core 107 over a public network such as the Internet.
- the untrusted RAN may not implement authentication/authorization tests sufficient to prevent security attacks upon the IMS core.
- a mobile device 102 uses a WiFi, GAN, or UMA protocol to connect to an untrusted RAN at a wireless access point.
- the intermediary components 106 and the untrusted RAN 103 are both connected to the IMS core 107 .
- the IMS core comprises various Call Session Control Functions (“CSCF”) and other components that, inter alia, provide SIP registrar and proxy functionality.
- the IMS core comprises a proxy CSCF (“P-CSCF”) 108 , an interrogating CSCF (“I-CSCF”) 112 , a serving CSCF (“S-CSCF”) 116 , a Security Gateway (“SEG”)/Session Border Controller (“SBC”) 110 , and a Home Subscriber Server (“HSS”) 114 .
- P-CSCF proxy CSCF
- I-CSCF interrogating CSCF
- S-CSCF serving CSCF
- SEG Security Gateway
- SBC Session Border Controller
- HSS Home Subscriber Server
- the intermediary components 106 connect the trusted RAN 104 to the IMS core 107 via the P-CSCF 108 .
- the untrusted network 103 connects to the P-CSCF 108 indirectly via the SEG/SBC 110 .
- the SEG/SBC may establish a secure IP tunnel between a mobile device 102 and the IMS core.
- a trusted network 104 may connect to the P-CSCF via the SEG/SBC.
- the untrusted network may directly connect to the P-CSCF via the Internet.
- a SIP client running on a mobile device 102 In order to register with the IMS core 107 , a SIP client running on a mobile device 102 generates and sends an initial SIP registration message to the IMS core via the trusted RAN 104 or untrusted RAN 103 .
- the initial registration message comprises a REGISTER method token and extended header information, including an IMEI and IMSI associated with the mobile device 102 , as described in greater detail herein.
- the P-CSCF 108 receives the initial SIP registration message and forwards the message to the I-CSCF 112 .
- the P-CSCF may also perform some or all of the functionality of the SEG/SBC 110 .
- the I-CSCF 112 and/or S-CSCF 116 may utilize the IMEI/IMSI identifiers in the received registration message to generate and send a user authorization request (“UAR”) to the HSS 114 via the Diameter protocol.
- UAR includes, inter alia, the IMEI and IMSI associated with the mobile device 102 .
- the I-CSCF utilizes the SIP registration message forwarded from the P-CSCF to generate and send the UAR to the HSS and the S-CSCF implements additional standard IMS registration methods.
- the I-CSCF does not generate and send the UAR, but instead queries the HSS to identify which S-CSCF to forward the registration message to.
- the I-CSCF then forwards the received SIP registration message to the identified S-CSCF.
- the S-CSCF then utilizes the SIP registration message to generate and send the UAR to the HSS.
- the S-CSCF also implements additional standard IMS registration methods (e.g., HTTP digest or Authentication and Key Agreement (“AKA”) authentication).
- AKA Authentication and Key Agreement
- the HSS 114 is a master user database that contains subscription-related information such as subscriber profiles.
- the HSS performs authentication and authorization of a mobile device 102 and provides information about a mobile device's IP address.
- the HSS may perform standard IMS registration processes as described by 3GPP specifications and standards.
- the HSS also validates the IMEI/IMSI identifiers in the UAR in order to determine whether to deny registration to a mobile device 102 .
- the HSS may also use a received IMEI to determine the capabilities of a mobile device.
- the HSS is configured to use a received UAR in order to query an equipment identity register (“EIR”) 120 .
- EIR equipment identity register
- the S-CSCF 116 couples to the EIR 120 directly.
- the S-CSCF may validate IMEI/IMSI identifiers in order to determine whether to deny registration to a mobile device 102 .
- the S-CSCF may also use a received IMEI to determine the capabilities of a mobile device.
- the S-CSCF may be configured to extract IMEI/IMSI information from a SIP registration message and to query the EIR using the extracted information.
- the EIR 120 is a database used to identify which mobile devices 102 are permitted to the use IMS core 107 .
- the EIR may also be utilized to identify which mobile devices are permitted to use the trusted network 104 .
- the EIR maintains a list of mobile devices (identified by their IMEI) which are to be banned from the network or monitored, for example because the devices have been reported stolen.
- an EIR associates an IMEI to a registration status or statuses.
- an EIR may correlate an IMEI (or a range or set of IMEIs) to one of three different registration statuses:
- the EIR 120 either comprises or is connected to a capability database (“DB”) 122 .
- the capability database associates an IMEI to one or more device capabilities.
- the capability database may permit the lookup, based on an IMEI, of which location determination techniques are supported by a particular mobile device's configuration.
- the capability database may permit the EIR to determine whether a mobile device 102 having a specific IMEI can be located with Global Positioning Systems (GPS) or assisted GPS (“A-GPS”) methods.
- GPS Global Positioning Systems
- A-GPS assisted GPS
- the capability database may be connected to, or accessible via, other components within the environment 100 .
- the EIR and/or capability database are configured to accept and respond to queries for the registration status and/or device capabilities of a device from components other than the HSS 114 and S-CSCF 116 , either during IMS registration or at other times.
- the capability database may be queried by a telephone application server, a mobile device 102 , and/or a third-party server, such as a server that implements a location-based service.
- the EIR and/or capability database may be queried, for example, via SIP request messages or Diameter messages.
- the IMS core 107 is connected directly or indirectly to location determination components that are configured to initiate, request or coordinate location determination processes in order to determine the physical location of a mobile device 102 (e.g., its latitude and longitude).
- the IMS core may be connected to a Gateway Mobile Location Center (“GMLC”), a SUPL Location Center (“SLC”) as described by the SUPL standards available from the Open Mobile Alliance (“OMA”), and/or an Emergency SMLC (“E-SMLC”) as described by the IMS specifications and technical reports of the 3GPP.
- GMLC Gateway Mobile Location Center
- SLC SUPL Location Center
- OMA Open Mobile Alliance
- E-SMLC Emergency SMLC
- these components may be configured to determine and provide the location of a mobile device to a requesting location-based service, such as an emergency service or commercial location-based service.
- a requesting location-based service such as an emergency service or commercial location-based service.
- the IMS core is directly or indirectly connected to location-based applications or services, which utilize the determined physical location of a mobile device to provide location-based services.
- the IMS core may facilitate communications between the location-based services, the mobile devices 102 , and location determination components.
- FIG. 2 illustrates an example of an enhanced SIP registration message 200 having extended header information.
- a SIP client running on a mobile device 102 generates and sends a registration message to the IMS core network 107 when seeking to register with the network.
- the registration message comprises a request line 205 , a header 215 , and a body 210 .
- the request line 205 specifies the type of request being issued (the method token “REGISTER”), a request URI (“telco.com”), and a SIP version (“SIP/2.0”).
- the header 215 comprises multiple header fields that provide additional information about the request or the SIP client. For example, as shown in FIG.
- the header may comprise the following header fields: Via header 220 , To header 225 , From header 230 , Contact header 235 , CSeq header 240 , Call-ID header 245 , and Authorization header 250 .
- the header may comprise fewer, different, or additional header fields than those depicted in FIG. 2 .
- the body 210 carries any data payload and may be omitted.
- a header field may be associated with one or more values. For example, as shown, the To header 225 may be associated with the value “sip:watson@telco.com.” A header field may also be associated with header field parameters, which may be defined by a value. For example, as shown, the Authorization header 250 may be associated with a “realm” parameter that is defined by the value “telco.com.”
- the header 215 is modified in a fashion that facilitates the determination of the registration status and the physical location of the mobile device.
- the Contact header 235 includes an IMEI 247 that is associated with the mobile device 102 that generated the registration message 200 .
- the Contact header may also include additional contact information 257 (e.g., “ ⁇ sip:+1-972-555-222@telco.com>”).
- a registration message may indicate a device's IMEI by concatenating the IMEI with another value in the Contact header, by associating the IMEI with another parameter associated with the Contact header, or by including the IMEI in another header field.
- the registration message may include a standardized “dummy” IMEI, or otherwise indicate via the registration message that the device does not have an IMEI. For example, if the mobile device is not associated with an IMEI, the registration message may use a dummy IMEI that comprises the device's IMSI plus a single check digit.
- the Authorization header 215 includes an IMSI 255 that is associated with the mobile device 102 that generated the registration message 200 .
- a registration message may indicate a device's IMSI by concatenating the IMSI with another value in the Authorization header, by associating the IMSI with another parameter associated with the Authorization header, or by including the IMSI in another header field.
- the message may include a “dummy” IMSI (e.g., a single repeating digit, a number selected from a particular range, all or part of the device's IMEI), or otherwise indicate via the message that the device does not have an IMSI.
- the flexible syntax of SIP messages allows the IMEI and IMSI to be inserted within the header 215 in a variety of formats.
- SIP clients running on the various mobile devices 102 are configured to observe a predetermined and standardized format for indicating the IMEI/IMSI within a SIP registration message 200 .
- the extended header may include a code or other identifier that indicates the selected format of the IMEI and/or IMSI information that is contained in the header.
- FIG. 3 shows a table 300 schema that conceptually illustrates how a capability database 122 may store location determination capabilities of mobile devices 102 in association with IMEIs that identify each mobile device.
- the table 300 includes a column 305 for an IMEI that uniquely identifies a mobile device 102 .
- Each row 325 , 330 , 335 in the table corresponds to a single IMEI or a set of IMEIs (e.g., a range of IMEIs).
- the table 300 also includes one or more location determination columns 315 , 320 , each of which corresponds to a different location determination technique or techniques.
- the table 300 may include an A-GPS column 315 that indicates whether the identified mobile device 102 is capable of being located using A-GPS techniques.
- the table may include a GPS 320 column that indicates whether the identified mobile device 102 is capable of being located using GPS techniques.
- FIG. 3 shows only two location determination columns 315 , 320 , the table may have any number of additional or different location determination columns that reflect whether a mobile device may be located using a particular location determination technique or techniques.
- TDOA Time Difference on Arrival
- U-TDOA Uplink-TDOA
- OTDOA Observed TDOA
- IP DL-OTDOA Ideal Period Downlink-OTDOA
- CI Cell Identification
- CI-TA CI plus Timing Advance
- AGNSS Assisted Global Navigation Satellite System
- RTT Round Trip Time
- E-OTD Enhanced Observed Time Difference
- WiFI Data Base location Customer provided address location
- IP Location triangulation.
- FIG. 3 shows only binary information (“Yes” or “No”), the table may alternatively or additionally include richer capability information.
- FIG. 3 may include an indication of the performance that may be achieved by using a certain location determination technique to locate a particular mobile device (e.g., a metric reflecting the accuracy, precision, or time to fix of the technique).
- the table 300 also includes one or more software capability columns 340 , 345 .
- the table 300 may include an operating system specification (“OS specs”) column 340 that indicates the operating system installed on the identified mobile device 102 .
- OS specs operating system specification
- the table 300 may include an installed applications (“Installed Apps”) column 345 that indicates the applications installed on the identified mobile device.
- Installed applications may include location-based applications (e.g., mapping applications, local search applications) and/or other types of applications.
- the information contained in the software capability columns may be utilized by location-based services or other types of services or applications.
- the capability database may also indicate other types of capabilities of a mobile device 102 that are related to other applications or services besides location-based services.
- the table 300 may have any number of additional or different capability columns (not shown) that reflect whether a mobile device may utilize a particular application or service.
- the table may include an additional column that reflects whether a mobile device has sufficient hardware/software capability to use a particular multimedia gaming application.
- the table 300 may also include a status column 310 that indicates the registration status of a mobile device.
- the registration status reflects whether the corresponding device is authorized to access the core network, and may take one or more states (e.g., “black” to indicate that the mobile device is not authorized to access the network, “white” to indicates that the mobile device is authorized to access the network, and “grey” to indicate that the device may access the network but have limited use of certain network features or services).
- states e.g., “black” to indicate that the mobile device is not authorized to access the network, “white” to indicates that the mobile device is authorized to access the network, and “grey” to indicate that the device may access the network but have limited use of certain network features or services.
- the table may associate that IMEI with a black status.
- the table may associate that range of IMEIs with a white status.
- the table may also include an IMSI column that defines valid IMSI/IMEI combinations. These combinations may indicate which group of IMSIs (if any) may be utilized in conjunction with a particular mobile device.
- FIG. 4 is a logical flow diagram of a process 400 for utilizing a SIP registration message 200 having extended header information in order to determine the registration status of a mobile device 102 and determine the location of the mobile device.
- the various blocks of process 400 may be performed by components within the IMS core 107 .
- the process 400 begins at block 405 , when the IMS core 107 receives a SIP registration message 200 that has extended header information, including IMEI and IMSI information, that was sent from the mobile device 102 associated with the IMEI and IMSI.
- the IMS core 107 receives the registration message at the P-CSCF 108 , which forwards the message to the I-CSCF 112 .
- a component of the IMS core 107 parses the extended header information to determine the IMEI and IMSI associated with the mobile device 102 that sent the registration message 200 .
- the IMS core will be able to extract the IMEI/IMSI information so long as the SIP client on the mobile device utilized a correct predetermined format for the SIP registration message or provided that the extended header information provides information about the formatting of the SIP registration message.
- the I-CSCF 112 parses the extended header information in the registration message.
- the I-CSCF extracts sufficient information from the message to query the HSS 114 for the identity of the S-CSCF 116 that is assigned to handle the registration message. The I-CSCF forwards the message to the identified S-CSCF, and the identified S-CSCF parses the extended header information in the registration message.
- the IMS core 107 looks up the device in the EIR 120 using the determined IMEI and IMSI in order to determine the status of the mobile device 102 and validate the IMSI/IMEI combination.
- a component of the IMS core (e.g., the I-CSCF 112 or S-CSCF 116 ) generates and sends a UAR comprising the IMEI and IMSI to the HSS 114 .
- the UAR may reflect the IMSI and IMEI information in a Session ID field and/or Username field.
- the HSS queries the EIR using the received IMEI and IMSI to determine the status of the mobile device.
- the EIR looks up the IMEI within the EIR database to determine if the IMEI is associated with a black status, grey status or white status.
- the EIR may also utilize the IMEI and IMSI to verify that the two values represent a valid combination.
- the EIR sends the status of the mobile device (e.g., black, grey, or white status; valid/invalid combination of subscriber and mobile device) to the HSS.
- the S-CSCF 116 may query the EIR directly in order to determine the status of the mobile device. In response, the EIR sends the status of the mobile device to the S-CSCF.
- the IMS core 107 determines whether to deny registration to the requesting mobile device 102 due to a determined status. If the IMS core determines that it should deny registration (e.g., due to a black status or invalid combination), at block 425 , the IMS core sends a response to the mobile device 102 regarding the registration failure. The process 400 then returns.
- the HSS 114 reports to the I-CSCF 112 or S-CSCF 116 via a user authorization answer message (“UAA”) that the mobile device cannot register with the IMS core.
- UAA user authorization answer message
- the I-CSCF or S-CSCF sends a SIP response message to the mobile device that indicates a client error status code (e.g., status code “403 Forbidden”).
- the P-CSCF 108 may forward the response message to the mobile device.
- the S-CSCF 116 directly interprets the response from the EIR to determine whether to deny registration.
- the S-CSCF then sends a SIP response message to the mobile device that indicates a client error status code (e.g., status code “403 Forbidden”).
- the P-CSCF 108 may forward the response message to the mobile device.
- the IMS core 107 determines that it should allow registration on the basis of the received IMEI/IMSI at decision block 420 , processing proceeds to block 422 .
- the IMS core implements standard IMS authentication and registration processes to continue registering the mobile device 102 with the IMS core. If a dummy IMSI was utilized in the registration message 200 or the registration message indicated that no IMSI is associated with the mobile device, device authentication may proceed according to HTTP digest authentication mechanisms. Otherwise, device authentication may proceed according to AKA authentication mechanisms.
- the HSS 112 sends a UAA to the I-CSCF 112 or S-CSCF 116 indicating that the IMSI and IMEI are valid.
- the S-CSCF may initiate standard processes directly after interpreting the response received from the EIR.
- the S-CSCF may send an authentication challenge to the mobile device with authentication vectors supplied by the HSS, and if the challenge is satisfied, complete the registration of the mobile device and notify the HSS so that it may bind the IP address of the mobile device.
- the IMS core 107 looks up the location determination capabilities of the requesting mobile device 102 using the determined IMEI.
- the HSS or S-CSCF may perform block 430 in conjunction with any other registration processes, for example, blocks 415 , 420 , and/or 422 .
- the HSS or S-CSCF may query the EIR 120 using the received IMEI.
- the EIR looks up the capabilities of the mobile device in the capability database 122 using the received IMEI, and returns a message to the HSS or S-CSCF indicating the location determination capabilities of the mobile device. For example, the EIR may return a message to the HSS or S-CSCF indicating that the mobile device can be located using GPS and A-GPS techniques.
- the HSS 112 , S-CSCF, or another component directly queries the capability DB without interaction by the EIR.
- a third-party server or telephone application server queries the EIR or capability DB for the location determination capabilities of the requesting mobile device using the device's IMEI or another identifier. Such a query may occur at any time, including times other than IMS registration.
- the IMS core 107 stores the location determination capabilities of the mobile device 102 .
- the HSS 114 may store the determined capabilities in association with the IP address of the mobile device or a user profile in the HSS.
- the HSS or another IMS core component may store the location determination capabilities in association with an ongoing session involving the mobile device in a session table.
- the HSS or another component may store the capabilities in conjunction with session information such as: the IMSI of the mobile device, the IP address of the mobile device, and/or a Media Access Control (“MAC”) address associated with an access point utilized by the mobile device.
- MAC Media Access Control
- the IMS core 107 requests and receives the physical location of the mobile device 102 .
- the request indicates one or more location determination techniques that fall within the capabilities of the mobile device that should be utilized to determine the device's physical location.
- the IMS core may query the HSS 114 or another system component that stored the location determination capabilities of the mobile device.
- another component that is associated with the trusted network 104 and/or the IMS core e.g., a GMLC, E-SMLC or SLC
- the other component may then request or otherwise determine the physical location of the mobile device using an indicated location determination technique.
- the IMS core 107 or another associated component provides the received physical location of the mobile device 102 to a location-based service that has requested the mobile device's location.
- a location-based service that has requested the mobile device's location.
- an E-CSCF may provide the received physical location to an emergency services network in order to route an emergency call originating from the mobile device.
- the S-CSCF 116 may provide the received physical location to a commercial location-based service such as a mapping service.
- the requesting location-based service uses the mobile device's location to provide services that are tailored to the physical location of the device.
- the IMS core 107 may also look up, store and utilize information relating to other capabilities of the mobile device 102 using the determined IMEI (or a portion thereof). For example, the IMS core may determine whether other types of applications or services (e.g., gaming, messaging) are supported by the configuration of the mobile device. The identified capabilities of the mobile device may be used to customize services for the particular mobile device.
- other types of applications or services e.g., gaming, messaging
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
- This application is a continuation application of U.S. patent application Ser. No. 12/856,519, filed on Aug. 13, 2010, and entitled “ENHANCED REGISTRATION MESSAGES IN INTERNET PROTOCOL MULTIMEDIA SUBSYSTEMS,” now U.S. Pat. No. 8,537,797, which is hereby incorporated herein in its entirety by reference.
- Internet Protocol Multimedia Subsystems (“IMS”) is an architecture framework for delivering Internet Protocol (“IP”) multimedia to mobile users, such as users of mobile devices. An IMS core network (“IMS core”) permits wireless and wireline devices to access multimedia, messaging, and voice applications and services. IMS standards and specifications have been promulgated by the 3rd Generation Partnership Project (“3GPP”™) To ease the integration of an IMS core with Internet resources, 3GPP specifications use Internet Engineering Task Force protocols within the IMS core, such as Session Initiation Protocol (“SIP”) and Diameter.
- SIP is a signaling protocol used for creating, modifying and terminating two-party or multiparty sessions consisting of one or several media streams. A mobile device registers its IP address with a SIP registrar server within an IMS core by generating and sending a SIP request message with a “REGISTER” method token. Once registered, a mobile device may subsequently establish multimedia sessions via the IMS core. Standard IMS registration techniques may not permit an IMS core to ascertain the IMEI of a mobile device seeking registration. Furthermore, standard IMS registration techniques may not permit an IMS core to ascertain the hardware and software capabilities of a particular mobile device so that the IMS core may intelligently provision services to the mobile device.
-
FIG. 1 is a diagram of a representative environment in which enhanced registration messages may be utilized. -
FIG. 2 illustrates an example of an enhanced SIP registration message having extended header information. -
FIG. 3 shows a table schema that conceptually illustrates how a capability database stores location determination capabilities of a mobile device in association with an IMEI that identifies the mobile device. -
FIG. 4 is a logical flow diagram of a process for utilizing a SIP registration message having extended header information in order to determine the registration status of a mobile device and determine the location of the mobile device. - An enhanced Session Initiation Protocol (“SIP”) registration message having extended header information that is used by an Internet Protocol Multimedia Subsystem (“IMS”) core to determine the registration status of a mobile device and the physical location of the mobile device is disclosed. The extended header information includes hardware and subscriber identifiers, such as an International Mobile Equipment Identity (“IMEI”) and International Mobile Subscriber Identity (“IMSI”). The IMS core queries an equipment identity register to validate IMEI/IMSI identifiers in the header to determine whether to deny registration to a mobile device. The IMS core also queries a capability database using an IMEI to determine which location determination techniques are supported by or suitable for the associated mobile device.
- Various embodiments of the invention will now be described. The following description provides specific details for a thorough understanding and an enabling description of these embodiments. One skilled in the art will understand, however, that the invention may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description of the various embodiments. The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the invention.
-
FIG. 1 is a diagram of arepresentative environment 100 in which enhanced registration messages may be utilized. In theenvironment 100,mobile devices 102 are configured to communicate with, or through, a trusted radio access network (“RAN”) 104 and/or anuntrusted RAN 103, in order to register with and utilize anIMS core 107. - Users may employ
mobile devices 102 to communicate with other users and devices. In addition, users may employmobile devices 102 to receive, provide, or otherwise interact with location-based services. Location-based services are services that use the actual or approximate location of a mobile device to provide, enhance, or supplement a service to the mobile device. Location-based services include, but are not limited to, services such as emergency services (e.g., E911), asset tracking or recovery services (e.g., the tracking of a stolen car), location-based alerts or advertising services (e.g., targeted advertisements that depend on the location of a mobile device user), social networking services (e.g., services that report the relative location of friends or family), and/or the like. Once amobile device 102 has successfully registered with theIMS core 107, the device may establish multimedia sessions managed by the IMS core in order to access applications and services that facilitate communication, location-based services and/or other services. -
Mobile devices 102 may include virtually any devices for communicating over a wireless network. Such devices include mobile telephones, such as Global System for Mobile Communications (“GSM”) telephones, Time Division Multiple Access (“TDMA”) telephones, Universal Mobile Telecommunications System (“UMTS”) telephones, Evolution-Data Optimized (“EVDO”) telephones, Long Term Evolution (“LTE”) telephones, Generic Access Network (“GAN”) telephones, Unlicensed Mobile Access (“UMA”) telephones, and other mobile computers or devices, such as Voice over Internet Protocol (“VoIP”) devices, Secure User Plane Location (“SUPL”) Enabled Terminals (SETs), Personal Digital Assistants (“PDAs”), radio frequency devices, infrared devices, handheld computers, laptop computers, wearable computers, tablet computers, pagers, integrated devices combining one or more of the preceding devices, and/or the like. - Given such variety,
mobile devices 102 may range widely in terms of features and capabilities. As one example, mobile devices may have widely different hardware and software configurations that affect which location determination techniques may be utilized to locate the physical location of a mobile device (e.g., its latitude and longitude). As another example, the configuration of a mobile device may affect the performance (e.g., accuracy, precision, time to fix) of a location determination technique used to physically locate the device. The configuration of a mobile device may also affect its capability to utilize other types of applications or services besides location-based services. For example, the configuration of a mobile device may affect its capability to use multimedia gaming applications, instant messaging applications, etc. -
Mobile devices 102 typically include a processing unit, volatile memory and/or nonvolatile memory, a power supply, one or more network interfaces, an audio interface, a display, a keypad or keyboard and other input and/or output interfaces. The various components of a mobile device may be interconnected via a bus. The volatile and nonvolatile memories generally include storage media for storing information such as processor-readable instructions, data structures, program modules, or other data. Some examples of information that may be stored include basic input/output systems (BIOS), operating systems, and applications. The stored information may include one or more SIP clients capable of generating, transmitting and interpreting syntactically correct SIP messages. SIP clients permit the mobile device to register with and communicate via theISM core 107. - Many
mobile devices 102 are associated with an International Mobile Equipment Identity or IMEI Software Version (herein both are referred to as “IMEI”). An IMEI is a unique or semi-unique hardware identifier that includes information on the origin, model, and serial number of a mobile device. Some mobile devices that try to register with theIMS core 107 may not have an IMEI. For example, a laptop that only connects to the IMS core via a VOIP software client may not have an IMEI. In some examples, the IMS core may generate a pseudo-IMEI for a mobile device based upon an International Mobile Subscriber Identity and/or Globally Routable User Agent URI (“GRUU”) associated with the mobile device. For example, an S-CSCF (described herein) within the IMS core may generate a pseudo-IMEI for a VOIP soft client, an iPAD®, or laptop computer. Such a pseudo-IMEI may then be utilized in the methods described herein. Some mobile devices may have one or more unique or semi-unique mobile device hardware identifiers that are comparable to an IMEI, such as a Mobile Equipment Identifier (“MEID”) or Electronic Serial Number (“ESN”). Although the term “IMEI” is used subsequently herein, one having skill in the art will appreciate that the disclosed methods may alternatively or additionally use other comparable mobile device hardware identifiers to determine the capabilities of a mobile device accessing the IMS core. - A
mobile device 102 may also be associated with an International Mobile Subscriber Identity (“IMSI”), which is an internationally unique number used to identify a mobile subscriber or user. A subscriber's IMSI may be stored in a removable user identity card installed in amobile device 102, such as a subscriber identity module (“SIM”) card, Removable User Identity Module (“R-UIM”) card, CDMA Subscriber Identify Module (“CSIM”) card, or a Universal Integrated Circuit Card (“UICC”). The removable nature of the user identity card allows a user to change mobile devices by simply removing the card from one mobile device and inserting the card into another. Thus, the association between a mobile device and an IMSI may change over time. Furthermore, a mobile device may either be permanently or temporarily without a user identity card and therefore not associated with an IMSI. -
Mobile devices 102 may connect to the IMScore 107 by a trusted RAN 104 or an untrusted RAN 103. Both types of RANs provide a first physical wireless link betweenmobile devices 102 and the IMS core. A single mobile device may be capable of using one or both types of RANs. TheRANs 103, 104 may use any wireless communications and data protocol or standard, such as GSM, TDMA, UMTS, EVDO, LTE, GAN, UMA, Code Division Multiple Access (“CDMA”) protocols (including IS-95, IS-2000, and IS-856 protocols), Advanced LTE or LTE+, Orthogonal Frequency Division Multiple Access (“OFDM”), General Packet Radio Service (“GPRS”), Enhanced Data GSM Environment (“EDGE”), Advanced Mobile Phone System (“AMPS”), WiMAX protocols (including IEEE 802.16e-2005 and IEEE 802.16m protocols), Wireless Fidelity (“WiFi”), High Speed Packet Access (“HSPA”), (including High Speed Downlink Packet Access (“HSDPA”) and High Speed Uplink Packet Access (“HSUPA”)), Ultra Mobile Broadband (“UMB”), SUPL, and/or the like. - The trusted RAN 104 is a RAN operated by the operator of the
IMS core 107 or another trusted party that is associated with the IMS core operator (e.g., the operator's contractor, affiliate, or industry partner). In order to wirelessly communicate via the trusted RAN, amobile device 102 may need to pass preliminary authentication/authorization checks implemented in part by the trusted RAN. The trusted RAN is connected to and communicates with the IMS core via a dedicated backhaul (e.g., a private network that is not open to the public) andintermediary components 106. The intermediary components may include, for example, a Gateway GPRS Support Node (“GGSN”), Serving GPRS Support Node (“SGSN”) or similar components that facilitate mobility management, session management, and transport for IP packet services within the trusted RAN 104. - The
untrusted RAN 103 is a RAN that connects to theIMS core 107 over a public network such as the Internet. The untrusted RAN may not implement authentication/authorization tests sufficient to prevent security attacks upon the IMS core. In some examples, amobile device 102 uses a WiFi, GAN, or UMA protocol to connect to an untrusted RAN at a wireless access point. - The
intermediary components 106 and theuntrusted RAN 103 are both connected to theIMS core 107. The IMS core comprises various Call Session Control Functions (“CSCF”) and other components that, inter alia, provide SIP registrar and proxy functionality. The IMS core comprises a proxy CSCF (“P-CSCF”) 108, an interrogating CSCF (“I-CSCF”) 112, a serving CSCF (“S-CSCF”) 116, a Security Gateway (“SEG”)/Session Border Controller (“SBC”) 110, and a Home Subscriber Server (“HSS”) 114. The basic functionalities of the IMS core components are described by standards promulgated by the 3GPP, including 3GPP TS 23.002, version 9.2.0 Release 9, which is hereby incorporated by reference herein in its entirety. - As shown in
FIG. 1 , theintermediary components 106 connect the trusted RAN 104 to theIMS core 107 via the P-CSCF 108. In contrast, theuntrusted network 103 connects to the P-CSCF 108 indirectly via the SEG/SBC 110. The SEG/SBC may establish a secure IP tunnel between amobile device 102 and the IMS core. In some examples, a trusted network 104 may connect to the P-CSCF via the SEG/SBC. In other examples, the untrusted network may directly connect to the P-CSCF via the Internet. - In order to register with the
IMS core 107, a SIP client running on amobile device 102 generates and sends an initial SIP registration message to the IMS core via the trusted RAN 104 oruntrusted RAN 103. The initial registration message comprises a REGISTER method token and extended header information, including an IMEI and IMSI associated with themobile device 102, as described in greater detail herein. The P-CSCF 108 receives the initial SIP registration message and forwards the message to the I-CSCF 112. One having skill in the art will appreciate that in some examples, the P-CSCF may also perform some or all of the functionality of the SEG/SBC 110. - The I-
CSCF 112 and/or S-CSCF 116 may utilize the IMEI/IMSI identifiers in the received registration message to generate and send a user authorization request (“UAR”) to theHSS 114 via the Diameter protocol. The UAR includes, inter alia, the IMEI and IMSI associated with themobile device 102. In some examples, the I-CSCF utilizes the SIP registration message forwarded from the P-CSCF to generate and send the UAR to the HSS and the S-CSCF implements additional standard IMS registration methods. In other examples, the I-CSCF does not generate and send the UAR, but instead queries the HSS to identify which S-CSCF to forward the registration message to. In such examples, the I-CSCF then forwards the received SIP registration message to the identified S-CSCF. As described in greater detail herein, the S-CSCF then utilizes the SIP registration message to generate and send the UAR to the HSS. The S-CSCF also implements additional standard IMS registration methods (e.g., HTTP digest or Authentication and Key Agreement (“AKA”) authentication). - The
HSS 114 is a master user database that contains subscription-related information such as subscriber profiles. The HSS performs authentication and authorization of amobile device 102 and provides information about a mobile device's IP address. The HSS may perform standard IMS registration processes as described by 3GPP specifications and standards. The HSS also validates the IMEI/IMSI identifiers in the UAR in order to determine whether to deny registration to amobile device 102. The HSS may also use a received IMEI to determine the capabilities of a mobile device. To authorize a device and determine device capabilities, the HSS is configured to use a received UAR in order to query an equipment identity register (“EIR”) 120. - In some examples, the S-
CSCF 116 couples to theEIR 120 directly. In such examples, the S-CSCF may validate IMEI/IMSI identifiers in order to determine whether to deny registration to amobile device 102. In such examples, the S-CSCF may also use a received IMEI to determine the capabilities of a mobile device. To authorize a device and/or determine device capabilities, the S-CSCF may be configured to extract IMEI/IMSI information from a SIP registration message and to query the EIR using the extracted information. - The
EIR 120 is a database used to identify whichmobile devices 102 are permitted to theuse IMS core 107. The EIR may also be utilized to identify which mobile devices are permitted to use the trusted network 104. Among other information, the EIR maintains a list of mobile devices (identified by their IMEI) which are to be banned from the network or monitored, for example because the devices have been reported stolen. Thus, as described in greater detail herein, an EIR associates an IMEI to a registration status or statuses. For example, an EIR may correlate an IMEI (or a range or set of IMEIs) to one of three different registration statuses: -
- black status, i.e., the device is not allowed to utilize the IMS core;
- gray status, i.e., the device is allowed to utilize the IMS core, but is monitored; or
- white status, i.e., the device is allowed to utilize the IMS core.
TheEIR 120 may also correlate an IMEI to one or more IMSIs in order to define valid IMEI/IMSI combinations that are permitted to use theIMS core 107.
- The
EIR 120 either comprises or is connected to a capability database (“DB”) 122. As described in greater detail herein, the capability database associates an IMEI to one or more device capabilities. For example, the capability database may permit the lookup, based on an IMEI, of which location determination techniques are supported by a particular mobile device's configuration. To illustrate, the capability database may permit the EIR to determine whether amobile device 102 having a specific IMEI can be located with Global Positioning Systems (GPS) or assisted GPS (“A-GPS”) methods. Rather than being coupled to the HSS via the EIR, the capability database may be connected to, or accessible via, other components within theenvironment 100. In some examples, the EIR and/or capability database are configured to accept and respond to queries for the registration status and/or device capabilities of a device from components other than theHSS 114 and S-CSCF 116, either during IMS registration or at other times. To illustrate, in some examples, the capability database may be queried by a telephone application server, amobile device 102, and/or a third-party server, such as a server that implements a location-based service. The EIR and/or capability database may be queried, for example, via SIP request messages or Diameter messages. - Although not shown in
FIG. 1 , theIMS core 107 is connected directly or indirectly to location determination components that are configured to initiate, request or coordinate location determination processes in order to determine the physical location of a mobile device 102 (e.g., its latitude and longitude). For example, the IMS core may be connected to a Gateway Mobile Location Center (“GMLC”), a SUPL Location Center (“SLC”) as described by the SUPL standards available from the Open Mobile Alliance (“OMA”), and/or an Emergency SMLC (“E-SMLC”) as described by the IMS specifications and technical reports of the 3GPP. These components may be configured to determine and provide the location of a mobile device to a requesting location-based service, such as an emergency service or commercial location-based service. Similarly, although not shown inFIG. 1 , the IMS core is directly or indirectly connected to location-based applications or services, which utilize the determined physical location of a mobile device to provide location-based services. The IMS core may facilitate communications between the location-based services, themobile devices 102, and location determination components. -
FIG. 2 illustrates an example of an enhancedSIP registration message 200 having extended header information. A SIP client running on amobile device 102 generates and sends a registration message to theIMS core network 107 when seeking to register with the network. As shown, the registration message comprises arequest line 205, aheader 215, and abody 210. Therequest line 205 specifies the type of request being issued (the method token “REGISTER”), a request URI (“telco.com”), and a SIP version (“SIP/2.0”). Theheader 215 comprises multiple header fields that provide additional information about the request or the SIP client. For example, as shown inFIG. 2 , the header may comprise the following header fields: Viaheader 220, Toheader 225, Fromheader 230,Contact header 235,CSeq header 240, Call-ID header 245, andAuthorization header 250. The header may comprise fewer, different, or additional header fields than those depicted inFIG. 2 . Thebody 210 carries any data payload and may be omitted. - A header field may be associated with one or more values. For example, as shown, the
To header 225 may be associated with the value “sip:watson@telco.com.” A header field may also be associated with header field parameters, which may be defined by a value. For example, as shown, theAuthorization header 250 may be associated with a “realm” parameter that is defined by the value “telco.com.” - The
header 215 is modified in a fashion that facilitates the determination of the registration status and the physical location of the mobile device. As shown inFIG. 2 , theContact header 235 includes anIMEI 247 that is associated with themobile device 102 that generated theregistration message 200. The registration message may indicate the IMEI by associating the IMEI value with an IMEI-specific parameter 249 in the Contact header (e.g., as shown, “Contact: +sip.instance=‘123456789101123’”). The Contact header may also include additional contact information 257 (e.g., “<sip:+1-972-555-222@telco.com>”). As another example, although not shown, a registration message may indicate a device's IMEI by concatenating the IMEI with another value in the Contact header, by associating the IMEI with another parameter associated with the Contact header, or by including the IMEI in another header field. In the event that the mobile device that generated the registration message is not associated with an IMEI, the registration message may include a standardized “dummy” IMEI, or otherwise indicate via the registration message that the device does not have an IMEI. For example, if the mobile device is not associated with an IMEI, the registration message may use a dummy IMEI that comprises the device's IMSI plus a single check digit. - As shown in
FIG. 2 , theAuthorization header 215 includes anIMSI 255 that is associated with themobile device 102 that generated theregistration message 200. The registration message may indicate the IMSI by associating the IMSI value with an IMSI-specific parameter 253 of the Authorization header (e.g., as shown, “Authorization: Digest imsi_id=‘897654123456789’”). The Authorization header may also include additional authorization information 251 (e.g., “username=‘Bob’, realm=‘telco.com’”). As another example, although not shown, a registration message may indicate a device's IMSI by concatenating the IMSI with another value in the Authorization header, by associating the IMSI with another parameter associated with the Authorization header, or by including the IMSI in another header field. In the event that the mobile device is not associated with an IMSI, the message may include a “dummy” IMSI (e.g., a single repeating digit, a number selected from a particular range, all or part of the device's IMEI), or otherwise indicate via the message that the device does not have an IMSI. - The flexible syntax of SIP messages allows the IMEI and IMSI to be inserted within the
header 215 in a variety of formats. However, since the components of theIMS core 107 must be able to reliably and repeatedly extract IMEI and IMSI information from all registration messages, SIP clients running on the variousmobile devices 102 are configured to observe a predetermined and standardized format for indicating the IMEI/IMSI within aSIP registration message 200. Alternatively, the extended header may include a code or other identifier that indicates the selected format of the IMEI and/or IMSI information that is contained in the header. -
FIG. 3 shows a table 300 schema that conceptually illustrates how acapability database 122 may store location determination capabilities ofmobile devices 102 in association with IMEIs that identify each mobile device. As shown inFIG. 3 , the table 300 includes acolumn 305 for an IMEI that uniquely identifies amobile device 102. Eachrow - The table 300 also includes one or more
location determination columns FIG. 3 , the table 300 may include anA-GPS column 315 that indicates whether the identifiedmobile device 102 is capable of being located using A-GPS techniques. As another example, the table may include aGPS 320 column that indicates whether the identifiedmobile device 102 is capable of being located using GPS techniques. AlthoughFIG. 3 shows only twolocation determination columns FIG. 3 shows only binary information (“Yes” or “No”), the table may alternatively or additionally include richer capability information. For example,FIG. 3 may include an indication of the performance that may be achieved by using a certain location determination technique to locate a particular mobile device (e.g., a metric reflecting the accuracy, precision, or time to fix of the technique). - The table 300 also includes one or more
software capability columns FIG. 3 , the table 300 may include an operating system specification (“OS specs”)column 340 that indicates the operating system installed on the identifiedmobile device 102. As another example, as shown inFIG. 3 , the table 300 may include an installed applications (“Installed Apps”)column 345 that indicates the applications installed on the identified mobile device. Installed applications may include location-based applications (e.g., mapping applications, local search applications) and/or other types of applications. The information contained in the software capability columns may be utilized by location-based services or other types of services or applications. - Although not shown in
FIG. 3 , the capability database may also indicate other types of capabilities of amobile device 102 that are related to other applications or services besides location-based services. Thus the table 300 may have any number of additional or different capability columns (not shown) that reflect whether a mobile device may utilize a particular application or service. For example, the table may include an additional column that reflects whether a mobile device has sufficient hardware/software capability to use a particular multimedia gaming application. - Since the
capability database 122 may be integrally formed within or otherwise associated with theEIR 120, the table 300 may also include astatus column 310 that indicates the registration status of a mobile device. The registration status reflects whether the corresponding device is authorized to access the core network, and may take one or more states (e.g., “black” to indicate that the mobile device is not authorized to access the network, “white” to indicates that the mobile device is authorized to access the network, and “grey” to indicate that the device may access the network but have limited use of certain network features or services). For example, as shown inrow 335, if amobile device 102 with the IMEI “678910111213131” has been reported stolen, the table may associate that IMEI with a black status. As another example, as shown inrow 325, if a group of IMEIs that begin with the sequence “1234” are known to interoperate with theIMS core 107, the table may associate that range of IMEIs with a white status. Although not shown, the table may also include an IMSI column that defines valid IMSI/IMEI combinations. These combinations may indicate which group of IMSIs (if any) may be utilized in conjunction with a particular mobile device. -
FIG. 4 is a logical flow diagram of aprocess 400 for utilizing aSIP registration message 200 having extended header information in order to determine the registration status of amobile device 102 and determine the location of the mobile device. As described in greater detail herein, the various blocks ofprocess 400 may be performed by components within theIMS core 107. - The
process 400 begins atblock 405, when theIMS core 107 receives aSIP registration message 200 that has extended header information, including IMEI and IMSI information, that was sent from themobile device 102 associated with the IMEI and IMSI. TheIMS core 107 receives the registration message at the P-CSCF 108, which forwards the message to the I-CSCF 112. - At
block 410, a component of theIMS core 107 parses the extended header information to determine the IMEI and IMSI associated with themobile device 102 that sent theregistration message 200. As described previously, the IMS core will be able to extract the IMEI/IMSI information so long as the SIP client on the mobile device utilized a correct predetermined format for the SIP registration message or provided that the extended header information provides information about the formatting of the SIP registration message. In some examples, the I-CSCF 112 parses the extended header information in the registration message. In other examples, the I-CSCF extracts sufficient information from the message to query theHSS 114 for the identity of the S-CSCF 116 that is assigned to handle the registration message. The I-CSCF forwards the message to the identified S-CSCF, and the identified S-CSCF parses the extended header information in the registration message. - At
block 415, theIMS core 107 looks up the device in theEIR 120 using the determined IMEI and IMSI in order to determine the status of themobile device 102 and validate the IMSI/IMEI combination. - To determine the status of the mobile device, a component of the IMS core (e.g., the I-
CSCF 112 or S-CSCF 116) generates and sends a UAR comprising the IMEI and IMSI to theHSS 114. In some examples, the UAR may reflect the IMSI and IMEI information in a Session ID field and/or Username field. When the HSS receives the UAR, the HSS queries the EIR using the received IMEI and IMSI to determine the status of the mobile device. In turn, the EIR looks up the IMEI within the EIR database to determine if the IMEI is associated with a black status, grey status or white status. The EIR may also utilize the IMEI and IMSI to verify that the two values represent a valid combination. The EIR sends the status of the mobile device (e.g., black, grey, or white status; valid/invalid combination of subscriber and mobile device) to the HSS. - Alternatively, rather than send a UAR comprising the IMEI and IMSI to the
HSS 114, the S-CSCF 116 may query the EIR directly in order to determine the status of the mobile device. In response, the EIR sends the status of the mobile device to the S-CSCF. - At
decision block 420, theIMS core 107 determines whether to deny registration to the requestingmobile device 102 due to a determined status. If the IMS core determines that it should deny registration (e.g., due to a black status or invalid combination), atblock 425, the IMS core sends a response to themobile device 102 regarding the registration failure. Theprocess 400 then returns. - To determine whether to deny registration to the requesting mobile device, the
HSS 114 reports to the I-CSCF 112 or S-CSCF 116 via a user authorization answer message (“UAA”) that the mobile device cannot register with the IMS core. The UAA may specify a failed attribute value pair. In turn, the I-CSCF or S-CSCF sends a SIP response message to the mobile device that indicates a client error status code (e.g., status code “403 Forbidden”). The P-CSCF 108 may forward the response message to the mobile device. Alternatively, the S-CSCF 116 directly interprets the response from the EIR to determine whether to deny registration. The S-CSCF then sends a SIP response message to the mobile device that indicates a client error status code (e.g., status code “403 Forbidden”). The P-CSCF 108 may forward the response message to the mobile device. - If the
IMS core 107 determines that it should allow registration on the basis of the received IMEI/IMSI atdecision block 420, processing proceeds to block 422. Atblock 422, the IMS core implements standard IMS authentication and registration processes to continue registering themobile device 102 with the IMS core. If a dummy IMSI was utilized in theregistration message 200 or the registration message indicated that no IMSI is associated with the mobile device, device authentication may proceed according to HTTP digest authentication mechanisms. Otherwise, device authentication may proceed according to AKA authentication mechanisms. To initiate standard processes, theHSS 112 sends a UAA to the I-CSCF 112 or S-CSCF 116 indicating that the IMSI and IMEI are valid. Alternatively, the S-CSCF may initiate standard processes directly after interpreting the response received from the EIR. To complete IMS core registration, for example, the S-CSCF may send an authentication challenge to the mobile device with authentication vectors supplied by the HSS, and if the challenge is satisfied, complete the registration of the mobile device and notify the HSS so that it may bind the IP address of the mobile device. - At
block 430, theIMS core 107 looks up the location determination capabilities of the requestingmobile device 102 using the determined IMEI. The HSS or S-CSCF may perform block 430 in conjunction with any other registration processes, for example, blocks 415, 420, and/or 422. To look up the location determination capabilities, the HSS or S-CSCF may query theEIR 120 using the received IMEI. The EIR looks up the capabilities of the mobile device in thecapability database 122 using the received IMEI, and returns a message to the HSS or S-CSCF indicating the location determination capabilities of the mobile device. For example, the EIR may return a message to the HSS or S-CSCF indicating that the mobile device can be located using GPS and A-GPS techniques. In some examples, theHSS 112, S-CSCF, or another component directly queries the capability DB without interaction by the EIR. In other examples, a third-party server or telephone application server queries the EIR or capability DB for the location determination capabilities of the requesting mobile device using the device's IMEI or another identifier. Such a query may occur at any time, including times other than IMS registration. - At
block 435, theIMS core 107 stores the location determination capabilities of themobile device 102. For example, theHSS 114 may store the determined capabilities in association with the IP address of the mobile device or a user profile in the HSS. As another example, the HSS or another IMS core component may store the location determination capabilities in association with an ongoing session involving the mobile device in a session table. For example, the HSS or another component may store the capabilities in conjunction with session information such as: the IMSI of the mobile device, the IP address of the mobile device, and/or a Media Access Control (“MAC”) address associated with an access point utilized by the mobile device. - At
block 440, theIMS core 107 requests and receives the physical location of themobile device 102. The request indicates one or more location determination techniques that fall within the capabilities of the mobile device that should be utilized to determine the device's physical location. To do so, the IMS core may query theHSS 114 or another system component that stored the location determination capabilities of the mobile device. Alternatively, or additionally, another component that is associated with the trusted network 104 and/or the IMS core (e.g., a GMLC, E-SMLC or SLC) may request that the IMS core provide an indication of location determination techniques that fall within the capabilities of the mobile device. The other component may then request or otherwise determine the physical location of the mobile device using an indicated location determination technique. - At
block 445, theIMS core 107 or another associated component (e.g., a GMLC, E-SMLC or SLC) provides the received physical location of themobile device 102 to a location-based service that has requested the mobile device's location. For example, an E-CSCF may provide the received physical location to an emergency services network in order to route an emergency call originating from the mobile device. As another example, the S-CSCF 116 may provide the received physical location to a commercial location-based service such as a mapping service. The requesting location-based service uses the mobile device's location to provide services that are tailored to the physical location of the device. - Although not shown, at blocks 430-445, the
IMS core 107 may also look up, store and utilize information relating to other capabilities of themobile device 102 using the determined IMEI (or a portion thereof). For example, the IMS core may determine whether other types of applications or services (e.g., gaming, messaging) are supported by the configuration of the mobile device. The identified capabilities of the mobile device may be used to customize services for the particular mobile device. - The above Detailed Description of embodiments of the system is not intended to be exhaustive or to limit the system to the precise form disclosed above. While specific embodiments of, and examples for, the system are described above for illustrative purposes, various equivalent modifications are possible within the scope of the system, as those skilled in the relevant art will recognize. For example, while processes or steps are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having steps, in a different order, and some processes or steps may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each of these processes or steps may be implemented in a variety of different ways. Also, while processes or steps are at times shown as being performed in series, these processes or steps may instead be performed in parallel, or may be performed at different times.
- While certain aspects of the invention are presented below in certain claim forms, the applicant contemplates the various aspects of the invention in any number of claim forms. Accordingly, the applicant reserves the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.
Claims (20)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/029,623 US9271251B2 (en) | 2010-08-13 | 2013-09-17 | Enhanced registration messages in internet protocol multimedia subsystems |
US15/050,378 US9820251B2 (en) | 2010-08-13 | 2016-02-22 | Enhanced registration messages in internet protocol multimedia subsystems |
US15/811,605 US10390322B2 (en) | 2010-08-13 | 2017-11-13 | Enhanced registration messages in internet protocol multimedia subsystems |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/856,519 US8537797B2 (en) | 2010-08-13 | 2010-08-13 | Enhanced registration messages in internet protocol multimedia subsystems |
US14/029,623 US9271251B2 (en) | 2010-08-13 | 2013-09-17 | Enhanced registration messages in internet protocol multimedia subsystems |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/856,519 Continuation US8537797B2 (en) | 2010-08-13 | 2010-08-13 | Enhanced registration messages in internet protocol multimedia subsystems |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/050,378 Continuation US9820251B2 (en) | 2010-08-13 | 2016-02-22 | Enhanced registration messages in internet protocol multimedia subsystems |
Publications (2)
Publication Number | Publication Date |
---|---|
US20140086147A1 true US20140086147A1 (en) | 2014-03-27 |
US9271251B2 US9271251B2 (en) | 2016-02-23 |
Family
ID=45564788
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/856,519 Active 2031-08-05 US8537797B2 (en) | 2010-08-13 | 2010-08-13 | Enhanced registration messages in internet protocol multimedia subsystems |
US14/029,623 Active 2030-12-27 US9271251B2 (en) | 2010-08-13 | 2013-09-17 | Enhanced registration messages in internet protocol multimedia subsystems |
US15/050,378 Active 2030-08-15 US9820251B2 (en) | 2010-08-13 | 2016-02-22 | Enhanced registration messages in internet protocol multimedia subsystems |
US15/811,605 Active US10390322B2 (en) | 2010-08-13 | 2017-11-13 | Enhanced registration messages in internet protocol multimedia subsystems |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/856,519 Active 2031-08-05 US8537797B2 (en) | 2010-08-13 | 2010-08-13 | Enhanced registration messages in internet protocol multimedia subsystems |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/050,378 Active 2030-08-15 US9820251B2 (en) | 2010-08-13 | 2016-02-22 | Enhanced registration messages in internet protocol multimedia subsystems |
US15/811,605 Active US10390322B2 (en) | 2010-08-13 | 2017-11-13 | Enhanced registration messages in internet protocol multimedia subsystems |
Country Status (4)
Country | Link |
---|---|
US (4) | US8537797B2 (en) |
EP (1) | EP2604051B1 (en) |
CN (1) | CN103155608B (en) |
WO (1) | WO2012021871A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140256282A1 (en) * | 2013-03-05 | 2014-09-11 | Qualcomm Incorporated | Localized Secure User Plane Location (SUPL) Emergency Session |
US20150350899A1 (en) * | 2014-05-28 | 2015-12-03 | National Taipei University Of Technology | AUTHENTICATION METHOD OF VoLTE |
US20180091970A1 (en) * | 2015-05-07 | 2018-03-29 | Huawei Technologies Co., Ltd. | Service processing method, and user equipment |
US10257702B2 (en) | 2017-09-08 | 2019-04-09 | At&T Intellectual Property I, L.P. | Validating international mobile equipment identity (IMEI) in mobile networks |
US10412537B2 (en) * | 2017-08-31 | 2019-09-10 | T-Mobile Usa, Inc. | SIP options based location determination |
Families Citing this family (54)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2489161B1 (en) | 2009-10-16 | 2019-06-12 | Tekelec, Inc. | Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring and/or firewall functionality |
US9313759B2 (en) * | 2009-10-16 | 2016-04-12 | Tekelec, Inc. | Methods, systems, and computer readable media for providing triggerless equipment identity register (EIR) service in a diameter network |
US8537797B2 (en) | 2010-08-13 | 2013-09-17 | T-Mobile Usa, Inc. | Enhanced registration messages in internet protocol multimedia subsystems |
US20130148550A1 (en) * | 2010-08-25 | 2013-06-13 | Nokia Siemens Networks Oy | Method and Apparatus for Registration of an Emergency Service in Packet Data Connections |
WO2012091642A1 (en) * | 2010-12-28 | 2012-07-05 | Telefonaktiebolaget L M Ericsson (Publ) | Methods for subscriber tracing based on error history information |
KR101800745B1 (en) * | 2011-05-04 | 2017-12-20 | 삼성전자주식회사 | Method and apparatus for connecting between devices |
US20120281594A1 (en) * | 2011-05-04 | 2012-11-08 | Motorola Mobility, Inc. | Method and apparatus for providing user equipment access to tv white space resources by a broadband cellular network |
US9392464B2 (en) | 2011-05-04 | 2016-07-12 | Google Technology Holdings LLC | Method and apparatus for providing user equipment access to TV white space resources by a broadband cellular network |
BR112013031001B1 (en) * | 2011-06-07 | 2021-11-16 | Nokia Technologies Oy | METHOD, MEDIA READIBLE BY COMPUTER AND DEVICE |
WO2013014731A1 (en) * | 2011-07-22 | 2013-01-31 | 富士通株式会社 | Server apparatus, communication control program, and method for controlling communication |
US9094829B2 (en) * | 2012-03-26 | 2015-07-28 | Verizon Patent And Licensing Inc. | Equipment identity registration |
US9088408B2 (en) * | 2012-06-28 | 2015-07-21 | Certicom Corp. | Key agreement using a key derivation key |
CN102984031B (en) * | 2012-12-12 | 2015-06-10 | 浙江宇视科技有限公司 | Method and device for allowing encoding equipment to be safely accessed to monitoring and control network |
US9143942B2 (en) | 2013-03-14 | 2015-09-22 | Tekelec Global, Inc. | Methods, systems, and computer readable media for providing a multi-network equipment identity register |
US9271135B2 (en) | 2013-03-15 | 2016-02-23 | T-Mobile Usa, Inc. | Local network alert system for mobile devices using an IMS session and Wi-Fi access point |
US9414225B2 (en) * | 2013-07-23 | 2016-08-09 | Broadcom Corporation | User equipment having web real time communication architecture |
KR20160013702A (en) * | 2014-07-28 | 2016-02-05 | 삼성전자주식회사 | Electronic apparatus and ims service providing method thereof |
US9826370B2 (en) * | 2014-10-10 | 2017-11-21 | T-Mobile Usa, Inc. | Location identifiers in mobile messaging |
EP3200415A4 (en) * | 2014-10-30 | 2017-08-23 | Huawei Technologies Co., Ltd. | Terminal, server and user identification system and method |
US9509853B2 (en) * | 2014-12-01 | 2016-11-29 | T-Mobile Usa, Inc. | SIP IMS call forking to multiple associated devices |
WO2016136648A1 (en) * | 2015-02-25 | 2016-09-01 | 京セラ株式会社 | Network device |
US9538378B2 (en) * | 2015-04-01 | 2017-01-03 | Verizon Patent And Licensing Inc. | Controlling access to a long term evolution network via a non-long term evolution access network |
US10075587B2 (en) * | 2015-05-18 | 2018-09-11 | Verizon Patent And Licensing Inc. | Selective delivery of messages to user devices that share a telephone number |
WO2017015790A1 (en) * | 2015-07-24 | 2017-02-02 | Apple Inc. | Packet switched voice service registration techniques with reduced overhead |
US10200339B2 (en) * | 2015-08-03 | 2019-02-05 | Verizon Patent And Licensing Inc. | Providing a service to a user device based on a capability of the user device when the user device shares an identifier |
GB2542770B (en) | 2015-09-25 | 2020-01-08 | Samsung Electronics Co Ltd | Mobile device capability identifier |
JP6973387B2 (en) * | 2015-10-28 | 2021-11-24 | 日本電気株式会社 | Communications system |
CN106937283B (en) * | 2015-12-29 | 2020-03-10 | 阿里巴巴集团控股有限公司 | Password-free authentication method and device for dual-card dual-standby terminal |
JP2019505132A (en) * | 2016-02-03 | 2019-02-21 | 華為技術有限公司Huawei Technologies Co.,Ltd. | Method and apparatus for obtaining user equipment identifier and method and apparatus for transmitting user equipment identifier |
US9819644B2 (en) * | 2016-02-04 | 2017-11-14 | Altiostar Networks, Inc. | Making international mobile subscriber identity available at base station |
US9769671B1 (en) | 2016-06-13 | 2017-09-19 | T-Mobile Usa, Inc. | Securing identities of chipsets of mobile devices |
US9838991B1 (en) | 2016-08-15 | 2017-12-05 | At&T Intellectual Property I, L.P. | Method and apparatus for managing mobile subscriber identification information according to registration requests |
US9967732B2 (en) | 2016-08-15 | 2018-05-08 | At&T Intellectual Property I, L.P. | Method and apparatus for managing mobile subscriber identification information according to registration errors |
US9794905B1 (en) | 2016-09-14 | 2017-10-17 | At&T Mobility Ii Llc | Method and apparatus for assigning mobile subscriber identification information to multiple devices according to location |
US10015764B2 (en) | 2016-09-14 | 2018-07-03 | At&T Intellectual Property I, L.P. | Method and apparatus for assigning mobile subscriber identification information to multiple devices |
US9924347B1 (en) | 2016-09-14 | 2018-03-20 | At&T Intellectual Property I, L.P. | Method and apparatus for reassigning mobile subscriber identification information |
US9843922B1 (en) * | 2016-09-14 | 2017-12-12 | At&T Intellectual Property I, L.P. | Method and apparatus for utilizing mobile subscriber identification information with multiple devices based on registration errors |
US9814010B1 (en) | 2016-09-14 | 2017-11-07 | At&T Intellectual Property I, L.P. | Method and apparatus for utilizing mobile subscriber identification information with multiple devices based on registration requests |
US9906943B1 (en) | 2016-09-29 | 2018-02-27 | At&T Intellectual Property I, L.P. | Method and apparatus for provisioning mobile subscriber identification information to multiple devices and provisioning network elements |
US9763168B1 (en) | 2016-09-30 | 2017-09-12 | T-Mobile Usa, Inc. | Blocked device checking in roaming scenarios |
US9918220B1 (en) | 2016-10-17 | 2018-03-13 | At&T Intellectual Property I, L.P. | Method and apparatus for managing and reusing mobile subscriber identification information to multiple devices |
US10070303B2 (en) | 2016-11-11 | 2018-09-04 | At&T Intellectual Property I, L.P. | Method and apparatus for provisioning of multiple devices with mobile subscriber identification information |
US10070407B2 (en) | 2016-12-01 | 2018-09-04 | At&T Intellectual Property I, L.P. | Method and apparatus for using active and inactive mobile subscriber identification information in a device to provide services for a limited time period |
US10341842B2 (en) | 2016-12-01 | 2019-07-02 | At&T Intellectual Property I, L.P. | Method and apparatus for using temporary mobile subscriber identification information in a device to provide services for a limited time period |
US10136305B2 (en) | 2016-12-01 | 2018-11-20 | At&T Intellectual Property I, L.P. | Method and apparatus for using mobile subscriber identification information for multiple device profiles for a device |
US10231204B2 (en) | 2016-12-05 | 2019-03-12 | At&T Intellectual Property I, L.P. | Methods, systems, and devices for registering a communication device utilizing a virtual network |
US10594756B2 (en) * | 2017-08-22 | 2020-03-17 | T-Mobile Usa, Inc. | Network configuration using dynamic voice codec and feature offering |
EP3477977B1 (en) * | 2017-10-26 | 2019-12-11 | Deutsche Telekom AG | Techniques for mobile pairing |
CN109962878B (en) * | 2017-12-14 | 2021-04-16 | 大唐移动通信设备有限公司 | Registration method and device of IMS (IP multimedia subsystem) user |
JP2021518711A (en) * | 2018-03-23 | 2021-08-02 | オパンガ ネットワークス,インコーポレイテッド | Coordinated data sharing in a virtualized network environment |
WO2020049210A1 (en) * | 2018-09-06 | 2020-03-12 | Nokia Solutions And Networks Oy | Method and apparatus for determining user equipment status for serving call state control function |
US11729599B2 (en) | 2018-10-08 | 2023-08-15 | Nokia Technologies Oy | Communication system |
CN115053504A (en) * | 2019-12-06 | 2022-09-13 | 瑞典爱立信有限公司 | Interworking independent non-public network-IMS |
CN113489712B (en) * | 2021-06-30 | 2023-06-20 | 展讯通信(天津)有限公司 | Call control method and device and computer readable storage medium |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080167035A1 (en) * | 2007-01-08 | 2008-07-10 | Research In Motion Limited | Apparatus, and associated method, for providing an instance indentifier to a network database node of a mobile network |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2794917B1 (en) * | 1999-06-10 | 2001-08-31 | Cit Alcatel | METHOD FOR AUTHORIZING ACCESS TO A CELLULAR RADIOCOMMUNICATION NETWORK FROM A SIMPLIFIED TELEPHONE, RADIOCOMMUNICATION SYSTEM AND SIMPLIFIED TELEPHONE THEREOF |
US6968195B2 (en) * | 2001-03-01 | 2005-11-22 | Openwave Systems Inc. | Enhanced PDE selection |
WO2006052083A1 (en) * | 2004-11-09 | 2006-05-18 | Samsung Electronics Co., Ltd. | Network interworking system and method for providing seamless voice service and short message service between wireless communication networks |
KR100871237B1 (en) | 2005-01-31 | 2008-11-28 | 삼성전자주식회사 | System and method for transmitting/receiving a alerting information of mobile terminal in wireless communication system |
KR100910801B1 (en) | 2005-05-02 | 2009-08-04 | 엘지전자 주식회사 | Method and device for sip session setup |
US8611946B2 (en) | 2007-01-25 | 2013-12-17 | Blackberry Limited | Methods and systems for configuring multi-mode mobile stations |
CN101641937B (en) * | 2007-03-30 | 2013-01-16 | 艾利森电话股份有限公司 | System and method for indicating circuit switched access at ims registration |
US20100037045A1 (en) * | 2008-08-07 | 2010-02-11 | Sean Kendall Schneyer | Method and apparatus for creating an instance id based on a unique device identifier |
EP2329632B1 (en) * | 2008-09-29 | 2018-10-24 | Nokia Technologies Oy | Hiding a device identity |
US8537797B2 (en) | 2010-08-13 | 2013-09-17 | T-Mobile Usa, Inc. | Enhanced registration messages in internet protocol multimedia subsystems |
-
2010
- 2010-08-13 US US12/856,519 patent/US8537797B2/en active Active
-
2011
- 2011-08-12 WO PCT/US2011/047685 patent/WO2012021871A1/en active Application Filing
- 2011-08-12 EP EP11817157.8A patent/EP2604051B1/en active Active
- 2011-08-12 CN CN201180049384.0A patent/CN103155608B/en active Active
-
2013
- 2013-09-17 US US14/029,623 patent/US9271251B2/en active Active
-
2016
- 2016-02-22 US US15/050,378 patent/US9820251B2/en active Active
-
2017
- 2017-11-13 US US15/811,605 patent/US10390322B2/en active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080167035A1 (en) * | 2007-01-08 | 2008-07-10 | Research In Motion Limited | Apparatus, and associated method, for providing an instance indentifier to a network database node of a mobile network |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140256282A1 (en) * | 2013-03-05 | 2014-09-11 | Qualcomm Incorporated | Localized Secure User Plane Location (SUPL) Emergency Session |
US9037158B2 (en) * | 2013-03-05 | 2015-05-19 | Qualcomm Incorporated | Localized secure user plane location (SUPL) emergency session |
US20150350899A1 (en) * | 2014-05-28 | 2015-12-03 | National Taipei University Of Technology | AUTHENTICATION METHOD OF VoLTE |
US20180091970A1 (en) * | 2015-05-07 | 2018-03-29 | Huawei Technologies Co., Ltd. | Service processing method, and user equipment |
US10448241B2 (en) * | 2015-05-07 | 2019-10-15 | Huawei Technologies Co., Ltd. | Service processing method, and user equipment |
US10412537B2 (en) * | 2017-08-31 | 2019-09-10 | T-Mobile Usa, Inc. | SIP options based location determination |
US10880674B2 (en) | 2017-08-31 | 2020-12-29 | T-Mobile Usa, Inc. | SIP options based location determination |
US10257702B2 (en) | 2017-09-08 | 2019-04-09 | At&T Intellectual Property I, L.P. | Validating international mobile equipment identity (IMEI) in mobile networks |
US10652744B2 (en) | 2017-09-08 | 2020-05-12 | At&T Intellectual Property I, L.P. | Validating international mobile equipment identity (IMEI) in mobile networks |
Also Published As
Publication number | Publication date |
---|---|
US20120039312A1 (en) | 2012-02-16 |
CN103155608A (en) | 2013-06-12 |
EP2604051B1 (en) | 2018-10-10 |
CN103155608B (en) | 2016-01-20 |
US8537797B2 (en) | 2013-09-17 |
EP2604051A1 (en) | 2013-06-19 |
US9820251B2 (en) | 2017-11-14 |
EP2604051A4 (en) | 2014-01-22 |
US20180070328A1 (en) | 2018-03-08 |
US10390322B2 (en) | 2019-08-20 |
US20160249313A1 (en) | 2016-08-25 |
WO2012021871A1 (en) | 2012-02-16 |
US9271251B2 (en) | 2016-02-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10390322B2 (en) | Enhanced registration messages in internet protocol multimedia subsystems | |
JP6374110B2 (en) | How to support location and emergency calls for over-the-top service providers | |
US8689277B2 (en) | Method and system for providing location of target device using stateless user information | |
US9088424B2 (en) | Mapping a mobile device location to billing regions in Internet Protocol Multimedia Subsystems | |
US9871828B2 (en) | Enhanced IMS services restriction and selection control for mobile devices roaming in foreign networks | |
JP4886037B2 (en) | Method and apparatus for parallel registration and call establishment | |
KR100834817B1 (en) | Method for providing location service on ims based network | |
US9232386B2 (en) | System and method for terminating communication sessions with roaming mobile devices | |
US8843595B2 (en) | Method and device for controlling communication in an internet protocol multimedia subsystem IMS | |
US10560570B2 (en) | Method, system and device for providing a setup of an enhanced call via a wireless local area network | |
WO2011060715A1 (en) | Method for implementing emergency call, system and device thereof | |
US20200146080A1 (en) | Method, System and Device for Providing a Setup of an Enhanced Call via a Wireless Local Area Network | |
US20150319588A1 (en) | Method and device for sms processing through ims network | |
US20230072838A1 (en) | Virtual line registration system | |
US10694332B2 (en) | Establishing the location of unmanaged network access points | |
US20110173230A1 (en) | Method and system for providing location information of target device | |
CN103685246A (en) | IMS faulty network element positioning method and device | |
KR20120097897A (en) | 3rd party registration method of wildcarded public service user agent in ims network and device of the same |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: T-MOBILE USA, INC., WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NARKAR, VISHAL;RANJAN, NILESH;REEL/FRAME:031571/0278 Effective date: 20100813 |
|
AS | Assignment |
Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS ADMINISTRATIVE AGENT, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNORS:T-MOBILE USA, INC.;METROPCS COMMUNICATIONS, INC.;T-MOBILE SUBSIDIARY IV CORPORATION;REEL/FRAME:037125/0885 Effective date: 20151109 Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS ADMINISTRATIV Free format text: SECURITY AGREEMENT;ASSIGNORS:T-MOBILE USA, INC.;METROPCS COMMUNICATIONS, INC.;T-MOBILE SUBSIDIARY IV CORPORATION;REEL/FRAME:037125/0885 Effective date: 20151109 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: DEUTSCHE TELEKOM AG, GERMANY Free format text: INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNOR:T-MOBILE USA, INC.;REEL/FRAME:041225/0910 Effective date: 20161229 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: METROPCS COMMUNICATIONS, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 Owner name: LAYER3 TV, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 Owner name: T-MOBILE USA, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE TELEKOM AG;REEL/FRAME:052969/0381 Effective date: 20200401 Owner name: T-MOBILE SUBSIDIARY IV CORPORATION, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 Owner name: IBSV LLC, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE TELEKOM AG;REEL/FRAME:052969/0381 Effective date: 20200401 Owner name: METROPCS WIRELESS, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 Owner name: PUSHSPRING, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 Owner name: T-MOBILE USA, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 Owner name: IBSV LLC, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH;REEL/FRAME:052969/0314 Effective date: 20200401 |
|
AS | Assignment |
Owner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNORS:T-MOBILE USA, INC.;ISBV LLC;T-MOBILE CENTRAL LLC;AND OTHERS;REEL/FRAME:053182/0001 Effective date: 20200401 |
|
AS | Assignment |
Owner name: SPRINT SPECTRUM LLC, KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: SPRINT INTERNATIONAL INCORPORATED, KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: SPRINT COMMUNICATIONS COMPANY L.P., KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: SPRINTCOM LLC, KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: CLEARWIRE IP HOLDINGS LLC, KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: CLEARWIRE COMMUNICATIONS LLC, KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: BOOST WORLDWIDE, LLC, KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: ASSURANCE WIRELESS USA, L.P., KANSAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: T-MOBILE USA, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: T-MOBILE CENTRAL LLC, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: PUSHSPRING, LLC, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: LAYER3 TV, LLC, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 Owner name: IBSV LLC, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001 Effective date: 20220822 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |