Subscriber identity pattern

BACKGROUND

Machine Type Communications (MTC) enables machines to communicate directly with one another in a machine to machine (M2M) fashion. For example, MTC is a foundational technology for the Internet of Things (IoT), the network of physical objects embedded with electronics and connectivity.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example subscriber data server including a subscriber record database.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a subscriber data server including an authentication database and a subscriber trace.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example method of returning subscriber data using a subscriber identity pattern.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example method of managing connections of devices served by a common subscriber record.

<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example subscriber data server including computer executable instructions to provision a shared subscriber record.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example subscriber data server including computer executable instructions for managing connection status of groups of devices sharing subscriber records.

DETAILED DESCRIPTION OF SPECIFIC EXAMPLES

Cellular network communications are often used for MTC. Existing cellular networks, such as Global System for Mobile Communications (GSM) standard based networks, 3^rdGeneration Partnership Project (3GPP) standard based networks, or Long Term Evolution (LTE) standard based networks, are designed to provide human voice and data communications. Operational, sizing, provisioning, and billing models may be based on the assumption that devices connect to the network for a long duration, each device is associated with a unique subscription, and each subscription is associated with a fixed address. For example, a subscriber data server, such as a home location register (HLR) or home subscriber server (HSS), may store a separate record for each subscriber device, typically keyed by an International Mobile Subscriber Identity (IMSI) stored on a subscriber identity module (SIM).

Aspects of the disclosed technology may allow a single subscription record to control a group of devices. The devices may be configured to be normally disconnected from the network and to only connect for short intervals at random times. For example, the devices may use their connection times to upload data, download instructions, or perform other periodic communications as necessary for their specific applications. Accordingly, a single subscription may support a large group of M2M devices, such as IoT devices. In some cases, the disclosed technology may be implemented in existing networks, such as existing GSM, 3GPP, or LTE standards.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example subscriber data server <b>101</b> including a subscriber record database <b>103</b>. For example, the subscriber data server <b>101</b> may be an HSS, an HLR, or a combined HSS/HLR system. In some implementations, the server <b>101</b> may be distributed across one or more physical or virtual machines. For example, the control module <b>102</b> and the subscriber record database <b>103</b> may be distributed across a group of physical server machines. Additionally, the illustrated functional modules may be implemented as software stored on a non-transitory computer readable medium, as hardware, or as a combination thereof.

The example subscriber record database <b>103</b> may store a subscriber record <b>104</b>. The subscriber record <b>104</b> may include a primary subscriber identity <b>105</b>. For example, the primary subscriber identity <b>105</b> may be a primary IMSI used as a key for the subscriber record <b>104</b>. As other examples, the primary subscriber identity <b>105</b> may be an MSISDN associated with the subscriber record <b>104</b>, an IPv6 address for a device within a group of devices controlled by the record <b>104</b>, or any other unique key associated with the group of devices.

The subscriber record <b>104</b> may further include a subscriber identity pattern <b>106</b>. The subscriber identity pattern <b>106</b> may be an information element that encompasses a range of different subscriber identities. The size of the range may determine the maximum number of devices that may be covered by a single subscriber record <b>104</b>. In some implementations, the subscriber identity pattern <b>106</b> may be a wildcard element. For example, an IMSI wildcard such as 18121237??? would encompass IMSIs from 18121237000 to 18121237999. As another example, the subscriber identity pattern <b>106</b> may be a pair of elements that encompass a range of different subscriber identities. For example, the pattern <b>106</b> may be an IMSI along with a range size, such as (18121237000, 1000) would encompass IMSIs from 18121237000 to 18121237999. As a further example, the subscriber identity pattern <b>106</b> may be a range size associated with the primary subscriber identity <b>105</b> to encompass a range of different subscriber identities. For example, the pattern <b>106</b> may be a range such as 500. For a primary subscriber identity <b>105</b> of 18121237000, the pattern <b>106</b> of 500 would cover IMSIs from 18121237000 to 18121237499.

In some implementations, the size of the range covered by the subscriber identity pattern <b>106</b> may vary between different subscriber records <b>104</b>. For example, a single group of devices may share a single subscriber record <b>104</b> and the range size may be configured according to the group size. In other implementations, the range size may be the same for all records <b>104</b>. For example, each record may have a subscriber identity wildcard element with an equal number of wildcard characters.

The subscriber record <b>104</b> may further store a set of subscriber data <b>107</b> for the group of devices covered by the record <b>104</b>. In some implementations, the subscriber data <b>107</b> may be various subscriber profile data stored in an HLR or HSS to enable devices to connect to cellular networks. For example, the subscriber profile data may include allowed access types, barred or allowed services, or other service features. The subscriber data <b>107</b> may also include information to assist the server in managing group of devices. For example, the subscriber data <b>107</b> may include a timeout period which defines a minimum time for which a device of the group is allowed to connect to the network. For example, the timeout period may be provisioned based on the needs of the devices served by the record. For example, a timeout period of 30 seconds would allow a maximum of 2 devices per minute, or 1440 device connections in a 12 hour slot, which would allow a 1000 device group to connect twice a day. As another example, the subscriber data <b>107</b> may include transient information such as the identity of a currently connected device and a timer of how long that device has been connected.

The example subscriber data server <b>101</b> may further include a control module <b>102</b>. For example, the control module <b>102</b> may be implemented as software stored on a non-transitory computer readable medium and executed by a processor, as hardware, or as a combination thereof. For example, the control module <b>102</b> may implement the functionality of an HLR supporting a GSM or other cellular standard network, an HSS supporting an LTE or other network, or a combined HSS/HLR supporting multiple protocols on a network.

The control module <b>102</b> may receive an attach request for a device. For example, the attach request may be any message sent to the server <b>101</b> as part of a device attach or location update procedure. For example, the attach request may be an authentication message or location update request sent by a serving general packet radio service (GPRS) support node (SGSN), or a visitor location register/mobile service center (VLR/MSC) to an HLR. As another example, the attach request may be an authentication message or location update request sent by a mobile management entity (MME) to an HSS). The request may include a subscriber identity for the device, which may be different than the primary subscriber identity of a record <b>104</b> stored on the subscriber record database <b>103</b>.

The control module <b>102</b> may retrieve a subscriber record <b>104</b> for the device by matching the identity in the request to a subscriber identity pattern <b>106</b> of a subscriber record <b>104</b>. For example, the control module <b>102</b> may search the subscriber database <b>103</b> for a subscriber record <b>104</b> having a subscriber identity pattern <b>106</b> that encompasses the subscribed identity. The control module <b>102</b> may further determine a primary subscriber identity <b>105</b> that corresponds to the matched subscriber identity pattern <b>106</b>.

The control module <b>102</b> may retrieve the subscriber data <b>107</b> from the subscriber record <b>104</b> using the primary subscriber identity <b>105</b> as a key. Alternatively, the control module <b>102</b> may retrieve the subscriber data <b>107</b> from the subscriber record <b>104</b> using the pattern <b>106</b> as a key. The control module <b>102</b> may then return the subscriber profile data <b>107</b> from the subscriber data <b>107</b>. For example, the control module <b>102</b> may return the subscriber profile data <b>107</b> as an update location message.

The server <b>101</b> may receive a second attach request for a second device in the group of devices covered by the record <b>104</b>. For example, the server <b>101</b> may receive the second attach request while the first device is still attached to the network. The server <b>101</b> may reject the connection attempt unless the timeout period following the first device's connection time has elapsed. If the first device's connection has exceeded the timeout period, then the sever <b>101</b> may cancel the first connection and allow the second device to attach.

For example, the control module <b>102</b> may receive a second attach request for a second device, the second request including a second subscriber identity matching the subscriber identity pattern. If the first device has been connected for at least a timeout period, the control module <b>102</b> may disconnect the first device. For example, the control module <b>102</b> may disconnect the first device by transmitting a cancel location message to the SGSN or MME currently supporting the first device. Additionally, the control module may return the subscriber data from the subscriber record to allow the second device to connect. For example, the control module may return the subscriber data as part of an update location message for the second device. If the first device has been connected for less than the timeout period, the control module <b>102</b> may transmit a refusal to the attach request. The second device may then try to connect later. For example, the second device may wait for a random back off time and attempt to reconnect after the back off period.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a subscriber data server <b>201</b> including an authentication database <b>208</b> and a subscriber trace <b>209</b>. The server <b>201</b> may be an implementation of a server described with respect to <figref idref="DRAWINGS">FIG. 1</figref>. For example, the control module <b>202</b>, subscriber record database <b>203</b>, subscriber record <b>204</b>, primary identity <b>205</b>, subscriber identity pattern <b>206</b>, and subscriber data <b>207</b> may be as described with respect to control module <b>102</b>, subscriber record database <b>103</b>, subscriber record <b>104</b>, primary identity <b>105</b>, subscriber identity pattern <b>106</b>, and subscriber data <b>107</b> of <figref idref="DRAWINGS">FIG. 1</figref>, respectively.

In some implementations, the subscriber data server <b>201</b> may maintain a single authentication record for a plurality of subscriber identities matching the subscriber identity pattern. In this situation, the authentication information on the SIM cards of the devices served by a subscriber record <b>204</b> would be shared. For example, a SIM manufacturer may manufacture such custom SIM cards for a particular M2M deployment. In these implementations, the authentication record database <b>208</b> may store the single authentication record for the plurality of subscriber identities matching the subscriber identity pattern. For example, the authentication record may be keyed by the primary identity <b>205</b> or the subscriber identity pattern <b>206</b> of the corresponding subscriber record <b>204</b>. In these implementations, during authentication, the control module <b>202</b> may retrieve authentication information keyed to the primary subscriber identity <b>205</b> or the subscriber identity pattern <b>206</b>. The control module <b>202</b> may then return the retrieved information in an authentication response with the connecting device's identity.

In other implementations, the subscriber data server <b>201</b> may maintain separate authentication records for each subscriber identity served by a subscriber record <b>204</b>. For example, this may accommodate the situation where each SIM card contains unique authentication information. In these implementations, the server <b>201</b> may maintain each authentication record keyed to the individual device's identity, such as its IMSI. In these implementations, during authentication, the control module <b>202</b> may retrieve the authentication information keyed to the connecting device's identity and return it in a message containing the same identity.

In some implementations, the subscriber data server <b>201</b> may include a log, such as a subscriber trace log. Records within the log may be keyed by device subscriber identity and may include connection attempt times for a device, successful connection times and connection time lengths, disconnection times, corresponding primary subscriber identities, or other useful information for tracking the behavior of devices served by a subscriber record <b>204</b>.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example method of returning subscriber data using a subscriber identity pattern. In some implementations, the example method may be performed by an HLR or an HSS. For example, the method of <figref idref="DRAWINGS">FIG. 3</figref> may be implemented during operation of a subscriber data server such as the subscriber data server <b>101</b> of <figref idref="DRAWINGS">FIG. 1</figref> or the subscriber data server <b>201</b> of <figref idref="DRAWINGS">FIG. 2</figref>.

The example method may include block <b>301</b>. Block <b>301</b> may include receiving an attach request for a device, the request including a subscriber identity for the device. For example, the attach request may be any message sent to the server as part of a device attach or location update procedure. For example, the attach request may be an authentication message or location update request sent by a serving general packet radio service (GPRS) support node (SGSN), or a visitor location register/mobile service center (VLR/MSC) to an HLR. As another example, the attach request may be an authentication message or location update request sent by a mobile management entity (MME) to an HSS). The request may include a subscriber identity for the device, such as an IMSI or MSISDN of the device.

The example method may further include block <b>302</b>. Block <b>302</b> may include matching the subscriber identity to a subscriber identity pattern. For example, the subscriber identity pattern may be a wildcard field stored within a subscriber record of a subscriber profile database. Matching the subscriber identity may include matching a stored wildcard to the subscriber identity.

The example method may further include block <b>303</b>. Block <b>303</b> may include retrieving a subscriber record using the subscriber identity pattern. For example, block <b>303</b> may include using the subscriber identity pattern as a key to a subscriber record. As another example, block <b>303</b> may include using the subscriber identity pattern to determine a primary subscriber identity associated with the subscriber identity pattern and using the primary subscriber identity as a key to the subscriber record.

The example method may further include block <b>304</b>. Block <b>304</b> may include retrieving subscriber data from the subscriber record. For example, the subscriber data may include subscriber profile data that is shared by a group of devices having identities that match the subscriber identity pattern. For example, the subscriber profile data may include information provided by an HLR or HSS to an SGSN or MME during attach or update procedures.

The example method may further include block <b>305</b>. Block <b>305</b> may include returning the subscriber data. For example, block <b>305</b> may include returning the subscriber data as a response to the attach request received in block <b>301</b>. The response may include the device identity received in the attach request along with the subscriber data keyed to the primary subscriber identity.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example method of managing connections of devices served by a common subscriber record. In some implementations, the example method may be performed by an HLR or an HSS. For example, the method of <figref idref="DRAWINGS">FIG. 4</figref> may be implemented during operation of a subscriber data server such as the subscriber data server <b>101</b> of <figref idref="DRAWINGS">FIG. 1</figref> or the subscriber data server <b>201</b> of <figref idref="DRAWINGS">FIG. 2</figref>.

The example method may include block <b>401</b>. Block <b>401</b> may include receiving an authentication request. The authentication request may include a device identity, such as an IMSI, of a first device that is managed by a shared subscriber record. For example, the authentication request may be sent by an SGSN, or an MSC/VLR during an initial network attach or location update procedure.

The example method may also include block <b>402</b>. Block <b>402</b> may include obtaining the requested authentication information for the device from an authentication record database. Block <b>402</b> may further include returning the authentication information as a response to the authentication request received in block <b>401</b>.

In some implementations, block <b>402</b> may include matching the device identity from the authentication request to a subscriber identity pattern. In this example, block <b>402</b> may include retrieving authentication information based on the subscriber identity pattern. In this case, the authentication information may be shared between devices matching the subscriber identity pattern. As another example, block <b>402</b> may include using the subscriber identity pattern to retrieve a primary subscriber identity for a shared subscriber record, and using the primary subscriber identity as a key to the shared authentication information.

In other implementations, block <b>402</b> may include using the device identity from the authentication request as a key to the authentication information. In these implementations, the authentication information may be unique to the device.

The example method may further include block <b>403</b>. Block <b>403</b> may include receiving an attach request for the first device. For example, block <b>403</b> may be performed as described with respect to block <b>301</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

The example method may further include block <b>404</b>. Block <b>404</b> may include retrieving a subscriber record shared by the first device and other devices of a group of devices. For example, block <b>404</b> may be performed as described with respect to blocks <b>303</b> and <b>303</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

The example method may further include block <b>405</b>. Block <b>405</b> may include returning subscriber data retrieved from the subscriber record retrieved in block <b>404</b>. For example, block <b>405</b> may be performed as described with respect to block <b>304</b> of <figref idref="DRAWINGS">FIG. 3</figref>.

The example method may further include block <b>406</b>. Block <b>406</b> may include receiving a second attached request for a second device. The second request may include a second subscriber identity, such as a second IMSI, for the second device. The second device may be another device in a group of devices sharing the subscription record with the first device. In this case, the second subscriber identity will match the subscriber identity pattern of the subscriber record retrieved in block <b>404</b>.

The example method may further include block <b>407</b>. Block <b>407</b> may include determining if the first device has been connected for at least a timeout period. For example, the timeout period may be retrieved from the subscriber record retrieved in block <b>404</b>. Additionally, the time for which the first device has been connected may be stored as temporary data in the subscriber record.

If the first device has been connected for at least a timeout period, then blocks <b>408</b> and <b>409</b> may be performed. If the first device has been connected for less than the timeout period then block <b>410</b> may be performed.

Block <b>408</b> may include disconnecting the first device. For example, block <b>408</b> may include transmitting a cancel location message to the SGSN or MSC/VLR to which the first device is currently associated.

Block <b>409</b> may include granted the second attach request. for example, block <b>409</b> may include returning the subscriber data as a response to the second attach request <b>406</b> as described with respect to block <b>405</b>.

Block <b>410</b> may include refusing to grant the second attach request. For example, block <b>410</b> may include transmitting a refusal as a response to the second attach request received in block <b>406</b>.

<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example subscriber data server <b>501</b> including computer executable instructions to provision a shared subscriber record. For example, the data server <b>501</b> may be an HLR or HSS and may be an implementation of the servers described with respect to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>.

The server <b>501</b> may include a non-transitory computer readable medium <b>504</b>. For example, the medium <b>504</b> may include memory such as random access memory (RAM), storage such as hard disk, or solid state storage, or a combination thereof.

The medium <b>504</b> may store a first set of instructions <b>505</b> that are executable by a processor <b>503</b>. The first set of instructions <b>505</b> may be executed to obtain a subscriber identity pattern. For example, the subscriber pattern may be a wildcard field or other information element that covers a range of subscriber identities. For example, the subscriber identity pattern may be as described with respect to pattern <b>106</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In some cases, the instructions <b>505</b> may be executable to retrieve the subscriber pattern from a user through a provisioning user interface <b>502</b>. In other cases, the instructions <b>505</b> may be executable to generate the subscriber pattern from other information, such as a primary subscriber identity key received through the interface <b>502</b>.

The medium <b>504</b> may store a second set of instructions <b>506</b> that are executable by the processor <b>503</b>. The instructions <b>506</b> may be executable to obtain a primary subscriber identity corresponding to the subscriber identity pattern. For example, the primary subscriber identity may be as described with respect to identity <b>105</b> of <figref idref="DRAWINGS">FIG. 1</figref> and may serve as a key for the shared subscriber record. In some cases, the instructions <b>506</b> may be executable to generate the primary subscriber key from the subscriber identity pattern. In other cases, the instructions <b>506</b> may be executable to receive the primary subscriber key via the interface <b>502</b>.

The medium <b>504</b> may store a third set of instructions <b>507</b> that are executable by the processor <b>503</b>. The instructions <b>507</b> may be executable to obtain subscriber data for a set of devices having subscriber identities matching the subscriber identity pattern. For example, the subscriber data may be as described with respect to subscriber data <b>107</b> of <figref idref="DRAWINGS">FIG. 1</figref>. In some implementations, the data <b>107</b> may be received via the provisioning user interface <b>502</b>.

The medium <b>504</b> may store a fourth set of instructions <b>508</b> that are executable by the processor <b>503</b>. The instructions <b>508</b> may be executable to provision a subscriber record keyed to the primary subscriber identity and including the subscriber identity pattern and the subscriber data. For example, the instructions <b>508</b> may be executable to use the obtained information to create a subscriber record and store the subscriber record on a subscriber record database <b>510</b>. For example, the subscriber record may be as described with respect to subscriber record <b>104</b> of <figref idref="DRAWINGS">FIG. 1</figref> and the subscriber record database <b>501</b> may be as described with respect to database <b>103</b>.

The medium <b>506</b> may also store a fifth set of instructions <b>509</b>. The instructions <b>509</b> may be executable to provision authentication records for the subscribers in an authentication database <b>511</b>. For example, the authentication records and database <b>511</b> may be as described with respect to authentication records <b>208</b> of <figref idref="DRAWINGS">FIG. 2</figref>. In some cases, the instructions <b>509</b> may be executable to provision separate authentication records for a set of devices matching the primary subscriber identity.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example subscriber data server <b>601</b> including computer executable instructions for managing connection status of groups of devices sharing subscriber records. For example, the data server <b>601</b> may be an HLR or HSS and may be an implementation of the servers described with respect to <figref idref="DRAWINGS">FIGS. 1, 2, and 5</figref>.

The example server <b>601</b> may include a non-transitory computer readable medium <b>605</b>. For example, the medium <b>605</b> may include memory such as random access memory (RAM), storage such as hard disk, or solid state storage, or a combination thereof.

The medium <b>605</b> may store a first set of instructions <b>606</b>. Instructions <b>606</b> may be executable by a processor <b>604</b> to receive information for shared subscriber records and authentication records via a user interface <b>602</b>. Instructions <b>606</b> may be further executable by the processor <b>604</b> to provision the corresponding records in a subscriber record database <b>610</b> and an authentication database. For example, instruction set <b>606</b> may be as described with respect to instructions <b>505</b>-<b>509</b> of <figref idref="DRAWINGS">FIG. 5</figref>.

Medium <b>605</b> may further store instruction set <b>607</b>. Instruction set <b>607</b> may be executable by the processor <b>604</b> to receive an attach request via a network interface for a subscriber device. The attach request may be for a requesting device having a first subscriber identity matching a subscriber identity pattern of a subscriber record. In some cases, a currently attached subscriber device may be connected to the cellular network using the subscriber record. Accordingly, the currently attached subscriber device may have a second subscriber identity matching the subscriber identity pattern.

Medium <b>605</b> may store instruction set <b>608</b>. Instruction set <b>608</b> may be executable by the processor <b>604</b> to evaluate the connection time of the currently attached subscriber device. For example, instruction set <b>608</b> may be executable to retrieve a current connection length of the current device from the subscriber record and to compare that connection length to a timeout period. In some cases, the timeout period may be stored in the subscriber record.

Medium <b>605</b> may store instruction set <b>609</b>. Instruction set <b>609</b> may be executable to respond to the attach request according to the connection length of the currently attached device. For example, if the currently attached device has been attached for less than the timeout period, the instructions <b>609</b> may be executable to deny the attach request. If the currently attached device has been attached for more than the timeout period, the instructions <b>609</b> may be executable to disconnect the currently attached device and grant the attach request. For example, the instructions <b>609</b> may be executable to cause the server <b>601</b> to transmit a cancel location message for the first device and to transmit an update location message for the second device.

In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.