Patent Application
20180160305
Data networks typically have regional coverage. Data network modules are normally configured for a particular region. Modules can roam between data networks and between regions. Agreements between the data networks allow for such roaming. The region in which a module will operate is normally known when the module is manufactured or shipped. This knowledge allows modules to comply with regional regulations and for the modules to register with data networks.
The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and are, therefore, not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings.
In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims are not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented here. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, and designed in a wide variety of different configurations, all of which are explicitly contemplated and made part of this disclosure.
A global data network allows a module to access the data network across many regions. Rather than a single network operator, a global data network can be achieved using a number of different network operators. These network operators can be spread across a region, a country, and/or across the globe. Such a data network allows a module to access the data network in any region covered by the data network, regardless of the network operator of any particular data network. There are a number of technical challenges to allow this access.
Currently, modules that access a data network are configured for a particular region. Certain regions have various regulatory constraints. When modules are manufactured or shipped, the module can be configured to comply with any regulatory constraints. For example, the maximum transmit power of a module is a common regulatory constraint. Modules can be configured never to transmit with a power greater than the regulatory constraint. A module for a global data network, however, may first access the data network from one of many different regions. These regions may have separate and distinct constraints compared to other regions. The modules, therefore, need a way to comply with various different regulatory constraints without relying on those constraints being configured when the module is shipped.
Modules also need a way to register with the data network regardless of the network operator used to access the data network. A common registration database can be used to verify a module and provision the module for a particular data network operator. The data network operator can then provision the module for secure communication on the global data network via the data network operator. The common registration database allows modules to be initially provisioned without having to know the network operator that will be used to access the data network. Thus, configuring of the module, managing inventory, and shipping of the modules can be simplified.
Using the common registration database allows the module to be provisioned using any network operator. Security, therefore, can be an issue if data to/from the module is secured the same way across all data network operators. As the global network is comprised of many different network operators, in various implementations the communications between a module and a specific data network are secured from other data network operators. This data isolation ensures that one network operator is unable to determine the data being sent on a different data network. To be multi-regional, a module can roam between different data networks. Security of the module's communications can be achieved with a process similar to provisioning the module.
Various different types of networks can be used in the multi-regional network. For example, in at least one implementation, the modules and network use random phase multiple access (RPMA) to communicate.
During factory provisioning, the communication modules 102a and 102b are built. Building the communication modules 102a and 102b includes loading and configuring software into each module. Generally, the network and/or region that the communication module will function in is known at build time. The module, therefore, can be configured for a network or region during factory provisioning. In the various implementations discussed herein, the regions and network that the communication modules 102a and 102b will function in is not known. Accordingly, the communication modules 102a and 102b cannot be configured for a particular network or a particular region.
Even without the network and region configuration, the communication modules 102a and 102b are able to operate properly on any of the networks that make up a global network. To achieve this operability, a provisioning server 104 can be used during the building of the communication modules 102a and 102b. The provisioning server 104 provides a node ID to both a communication module 102a and also to a key storage server 106. The node ID identifies a particular communication module 102a from other communication modules. In addition, the provisioning server 104 maps the node ID to an access code. The access code is also provided to the key storage server 106 that also connects the node ID with the access code.
In various implementations, each communication module 102a stores its node ID in memory within the communication module. In these implementations, the access code is provided along with the communication module but is not stored within any memory within the communication module. In other implementations, both the node ID and the access code are stored within one or more memories of the communication module. In addition, a global network key can also be stored in the communication module. This global network key can be provided by the provisioning server 104.
The global network key can be used by the communication module when accessing a network where the communication module is not yet provisioned/configured for a specific network. When a communication module is not configured on a network, the communication module can send a request to the network to join the network. This request can be encrypted using the global network key. The receiving network can either know the global network key or request the global network key from the key storage server 106. This capability allows the network and the communication module to communicate securely before the communication module is configured on the network.
As part of the join request, the communication module can provide both its node ID and access code to the network 110. In other implementation, the communication module can provide its node ID, with the network 110 previously being provided the node ID and access code mapping. The network 110 can send the node ID and access code to the key storage server 106 for validation. The key storage server 106 can verify that the provided access code matches the provided node ID. This information is not directly available to the network 110, which provides a barrier of security by not allowing networks to know valid node ID and access code pairs until that information is provided to the network. The key storage server 106 provides an indication as to whether the node ID and access code pair is valid. If the pair is valid, the network 110 can reprovision the communication module 102a specifically for that network 110.
Communication modules and networks could continue to use the known global key, but at the cost of security. Anyone with the global key would be able to receive and decrypt communications between communication modules 102a and 102b and any network. To create secure communications, each communication module will use a key unique to a particular network after the communication module is provisioned on that network. After the network 110 verifies the node ID and access code pair, the network can create its own set of keys that the communication module 102a will use to secure communications with the network 110. The keys for the network 110 can be stored in a key management system 112 that is controlled by the network 110. This ensures that other networks would not have access to the keys of the network 110 without the approval of the network 110.
In other implementations, each network can use a separate key that is derived from the global key. For example, a network can broadcast a network identifier that uniquely identifies the network. This network identifier can be used in combination with the global key to derive a new key specific for that network. This requires that both the communication module and the network understand how the key was derived.
As described in relation to
In other implementations, the network 208 can receive valid pairs of access codes and node IDs. For example, the application developer 204 can provide valid pairs of access codes and node IDs to the network operator 208. The network operator 208 can then verify the data using the key storage server 202 or wait until a mobile joins. Then, the module 206 can provide the node ID, the access code, or both to the network operator. The network operator can then verify that the module is valid.
When the module is first put into use, the module scans for a network to access. Once a network has been found, the module determines that the module has not previously joined the found network. Using either a global key or a key derived from a global key and some network provided information, the module requests to join the network. In one implementation, the module provides its node ID to the network. The network, having already received the access code mapped to the node ID from the provisioning server or another server, validates that the provided node ID is both known and valid. In another implementation, the module provides both its node ID and its access code. The network validates that the provided node ID is a valid node ID and access code pair by providing both to the global key storage. In other implementations, the global key storage is not globally accessible. Rather, the node ID and access code pair are provided to a server that can access the global key storage. The server or the global key storage verifies that the data is valid and provides an indication of validation back to the network. If the module is not validated, the network can prohibit the module from accessing the network.
When the module is validated, the network can provide new keys to the module. This functionality allows each network to use keys that are different than the keys used on other networks. This capability ensures that communication on one network can be secured from other networks. In one implementation, the network can generate a set of keys without using the node ID, access code, or previously used key. In other implementations, the network can use the information associated with a module to generate a key specific to the module and the network. The new keys are provided to the module. The module and the network can then use the new keys to secure data communication between them.
In various implementations, a multi-regional network includes multiple independent network operators that work together to provide seamless data capabilities to modules. As described above, each network can secure data with a module using a set of keys specific to that network and/or network and module. Accordingly, when a module accesses a network, the module and network must use the same set of keys to communicate securely.
The module 402 can later attempt to access a second network, network Y 406. For example, the module 402 can move geographic locations such that network Y 406 provides service coverage compared to network X 404. The module 402 recognizes that the module 402 is not provisioned on network Y. For example, the module 402 can use the network identifier of network Y 406 to determine that the module does not have a key to use with network Y. The module 402 can then request to join network Y 406 by providing the module's node ID and access code. Network Y can then verify the node ID and access using the global key storage 408 in a similar way as described above. Once verified, a new key, specific to network Y, is created and stored both in the module 402 and network Y's key management server 412. The module 402 can store keys to one or more different networks. When accessing a network for the first time, the module 402 can determine if a key for that network is stored on the module 402 and use that key. If there is no key, the module 402 can request to join the network as described above.
In various implementations, network X 404 and network Y 406 can communicate with one another. For example, once the module 402 registers on network X 404, network X 404 can provide the node ID and provisioned key to network Y 406. Then when module 402 access network Y 406 using the provisioned key, network Y 406 can verify the module 402 is a valid module 402 without having to access the global key storage 408. In other implementations, network Y 406 can verify the module using the global key storage 408, as described above. Network X 404 can include a list of other networks to provide the module's information. When a module access the network X 404 for the first time, network X 404 can provide the relevant information to each of the networks in the list of networks.
While a multi-regional network allows a module to roam between networks, some communication or management between networks is needed for purposes such as billing.
Network X 604 and network Y 608 communicate with one another to determine what services the module 602 can access and also how much data/time the module 602 used on network Y. This allows network X to bill a module properly and enforce service agreements. In addition, the communication module 602 is able to reach an application server 606 regardless of the network. This ensures that the communication module 602 is able to access one or more applications as the communication module roams across different networks. The application server 606 provides one or more specific services for the communication module. For example, the application 606 can track the location of the module 602. The module 602 can send its location to the application server 606 that can store the module's location.
In another example, a common platform can manage a module's use of different networks. Rather than having networks communication with one another, the networks can communication with a common platform to access applications.
The communication module 702 can access both network X 704 and then at a later time roam onto network Y 708. Both network X 704 and network Y 708 communicate with the common platform 712 to provide the communication module 702 with access to the application server 706. As described above, the communication module 702 can request to join each network and be provided with keys to secure communication between the module and the network. The common platform can use keys to secure communication between the common platform and any network. For example, the common platform can provide one or more of the networks with a key to use or provide a specific key to each network. In one implementations, the common platform 712 can request that a network provide a specific key to be used to secure traffic between the network and the common platform.
As modules may operate in numerous different networks, each module must be able to conform to various requirements of each network. For example, the maximum transmit power of module can vary across different networks. Maximum transmit power must be determined to prevent the module from transmitting on a network with a power greater than the maximum transmit power across all networks. Accordingly, the module is able to transmit at the region's maximum transmit power without exceeding the maximum transmit power. This also avoids the module having to determine all possible transmit powers and selecting the minimum of these values to ensure the transmit power is less than the maximum transmit power over all of the regions.
Prior to transmitting on a network, a module will receive certain information, such as the network identifier, from the network. In various implementations, the network identifier can be specified via a broadcast channel. When a module first accesses a network, the module can listen on the broadcast channel for a broadcast message. As described above, the network identifier can be used to determine which keys the module uses to secure data transmissions. In addition to the network identifier, the broadcast channel can include one or more messages that provide regulatory information.
In one implementation, the regulatory information provides both a constraint type and a constraint limit value. The constraint type indicates a specific type of maximum transmission constraint. The constraint limit value provides one or more values that are network configurable and are used to calculate the maximum transmission value. In addition to the regulatory information, the module can include data that is also used in calculating the maximum transmission power. For example, one or both of antenna gain and cable loss can be used to calculate the module's maximum transmission power. These values can be provided to the module during manufacturing or changed by one or more networks, such as the module's home network.
In one implementation, there can be up to six different constraint types. Each constraint type has a different formula to calculate the module's maximum transmission power. As modules can operate on networks that can require any of these constraint types, each module is able to calculate the maximum transmission value for each of the available constraint types. In addition, there are various places/ways that the module's transmit power can be calculated. For example, the equivalent isotropically radiated power (EIRP) can be used. EIRP can be thought of as the output power+cable loss between the power amplifier and the antenna plus the antenna gain. Another example is conductive power which is a measurement of how much power was received by the antenna. The conductive power can be considered the output power plus the cable loss of the cable between the power amplifier and the antenna. Output power is another example that is the power that the power amplifier is providing. In some devices, the power amplifier can radiate out of band with overdriven. Thus, limiting output power can be used to ensure that a module's power amplifier is not overdrive and/or not transmitting out of band.
One constraint type calculates the maximum transmission value as the constraint limit minus the module's antenna gain plus the module's cable loss. Other maximum transmission values can be calculated using one of the following output power limit; conducted power; and/or equivalent isotropically radiated power (EIRP).
In the above examples, the output power limit, conducted power, and constraint limit value can be provided as part of the constraint limit values. In another example, the maximum transmission power is based upon the received power at the module's antenna. In this example, the maximum transmission power is calculated as either a first maximum transmission power as a first constraint limit value−the antenna gain+cable loss or a second maximum transmission power of second constrains limit value−the antenna gain+cable loss. The maximum transmission power is determined based upon the received power. If the received power is greater than the first constraint limit value−the antenna gain+cable loss, then the first transmission power used. Otherwise, the second transmission power is used.
Regardless of how the maximum transmission value is calculated, modules can limit the maximum transmission power based upon a configuration parameter of the module. After calculating the maximum transmission power, the calculated value can be compared with a stored maximum value. The maximum transmission power can then be set to be the minimum of these two values or set to a third value that is less than the store maximum transmission power value.
The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected,” or “operably coupled,” to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being “operably couplable,” to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.
With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.
It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.).
It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to inventions containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations).
Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.” Further, unless otherwise noted, the use of the words “approximate,” “about,” “around,” “substantially,” etc., mean plus or minus ten percent.
The foregoing description of illustrative embodiments has been presented for purposes of illustration and of description. It is not intended to be exhaustive or limiting with respect to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosed embodiments. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.
This application is a continuation of U.S. patent application Ser. No. 15/369,936, filed Dec. 6, 2016, the entire disclosures of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15369936 | Dec 2016 | US |
| Child | 15490510 | US |
