Patent Description:
<CIT> relates to techniques for providing a fully automated satellite-based backhaul system. In particular, a system utilizes a satellite communication terminal to allow an Internet of Things (IoT) device to be deployed in any location which has a line of sight towards a communication satellite. The placement, orientation, and/or communication characteristics of the loT device and/or satellite communication terminal may be manipulated (e.g., manual adjustment based on calculated directions and/or completely autonomously) to ensure avoidance of interference in any other wireless communication network.

This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description.

The present teachings provide signaling and data transfer for Internet of Things (IoT) networks via a satellite link without a lengthy signaling procedure. Encryption keys for data and signaling traffic may be secured with a security and repository server. Data traffic is delivered to an application server.

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes an Internet of Things (IoT) system including a Security and Repository Server (SRS) to store UT parameters for each UT of a UT population, where the UT parameters comprise a UT identifier, a UT IP address, and an application server IP address; an Over-The-Air (OTA) link to communicate from the UT population using a one-shot transmission; and a gateway (GW) configured to receive the one-shot transmission from a sender UT of a UT population and to send an IP packet including a portion of the one-shot transmission to an application server. In the system, the one-shot transmission includes an unscheduled transmission between the GW and the sender UT, the one-shot transmission includes a sender UT identifier, and the UT identifier for each UT of the UT population is unique. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The system where the GW is further configured to retrieve sender UT parameters associated with the sender UT identifier, and generate the IP packet may include the UT IP address of the sender UT parameters as a sender and the application server IP address of the sender UT parameters as a destination. The one-shot transmission does not include an IP source address or an IP destination address. The UT IP address for each UT of the UT population is unique. For each UT of the UT population, the SRS authenticates the UT, distributes the UT parameters and refreshes the UT parameters. The UT parameters may include encryption/integrity keys, and the encryption/integrity keys may include an application key for communications between the UT population and the application server, an OTA key for communications between the UT population and the GW, and a signaling key for communications between the SRS and the UT population. The UT parameters may include application keys including a respective application key for each UT of the UT population, and communications between a respective UT of the UT population and the application server uses the respective application key. The UT parameters may include OTA keys including a respective OTA key for each UT of the UT population, and communications between a respective UT of the UT population and the GW uses the respective OTA key. The OTA link may include a satellite link. The system may include a first secure tunnel to communicate between the gateway and the application server, and a second secure tunnel to communicate between the gateway and the SRS. The GW may be configured to receive an application-server IP packet addressed to a receiver UT IP address from the application server, retrieve receiver UT parameters associated with the receiver UT IP address, generate a packet including a UT identifier of the receiver UT parameters and a payload of the application-server IP packet, and transmit the packet via the OTA link. Prior to the transmit, the GW may perform one or more of page the UT identifier of the receiver UT parameters, receive within an awake window the one-shot transmission from the UT identifier of the receiver UT parameters, or allocate bandwidth for the UT identifier of the receiver UT parameters. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

One general aspect includes a non-transient computer-readable storage medium having instructions embodied thereon for a computer implemented method. The method includes storing UT parameters for each UT of the UT population with a security and repository server (SRS), where the UT parameters include a UT identifier, a UT IP address, and an application server IP address; communicating from the UT population using a one-shot transmission via an over-the-air (OTA) link; receiving the one-shot transmission from a sender UT of a UT population; and sending an IP packet including a portion of the one-shot transmission to an application server. In the method, the one-shot transmission may include an unscheduled transmission between the GW and UT, the one-shot transmission includes a sender UT identifier, and the UT identifier for each UT of the UT population is unique. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The method may include: retrieving sender UT parameters associated with the sender UT identifier; and generating the IP packet may include the UT IP address of the sender UT parameters as a sender and the application server IP address of the sender UT parameters as a destination. The method may include: receiving an application-server IP packet addressed to a receiver UT IP address from the application server; retrieving receiver UT parameters associated with the receiver UT IP address; generating a packet may include a UT identifier of the receiver UT parameters and a payload of the application-server IP packet; and transmitting the packet via the OTA link. Prior to the transmitting, the method performs one or more of paging the UT identifier of the receiver UT parameter, receiving within an awake window the one-shot transmission from the UT identifier of the receiver UT parameters, or allocating bandwidth for the UT identifier of the receiver UT parameters. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

Additional features will be set forth in the description that follows, and in part will be apparent from the description, or may be learned by practice of what is described.

In order to describe the manner in which the above-recited and other advantages and features may be obtained, a more particular description is provided below and will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not, therefore, to be limiting of its scope, implementations will be described and explained with additional specificity and detail with the accompanying drawings.

The present teachings may be a system, a method, and/or a computer program product at any possible technical detail level of integration.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as SMALLTALK, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

Reference in the specification to "one embodiment" or "an embodiment" of the present invention, as well as other variations thereof, means that a feature, structure, characteristic, and so forth described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment", as well any other variations, appearing in various places throughout the specification are not necessarily all referring to the same embodiment.

<FIG> illustrates a satellite loT system according to various embodiments.

A satellite <NUM> based Internet of Things (IoT) network <NUM> that transmits unscheduled or without a lengthy signaling procedure for a User Terminal (UT) <NUM> to efficiently send or receive data is disclosed. In some embodiments, all signaling and data transfer are secure. The network <NUM> may include a Security and Repository Server (SRS) <NUM>, a satellite gateway <NUM>, an application server <NUM> and a billing server <NUM>.

An OTA message <NUM> between the UT <NUM> and the satellite gateway <NUM> traverse a satellite link <NUM> via the satellite <NUM>. The OTA message <NUM> over the satellite link <NUM> is not based on the Internet Protocol (IP). The OTA message <NUM> may be secure. The satellite gateway <NUM> may serve a plurality of user terminals. The OTA message <NUM> may use one data key for messaging to the plurality of user terminals. In some embodiments, the OTA message <NUM> may use a unique data key for one or some of the plurality of user terminals, for example, one to one, one to many, one to all correspondence between a data key and UT.

A signaling message <NUM> between the UT <NUM> and the SRS <NUM> traverses the satellite link <NUM> and a tunnel <NUM>. The tunnel <NUM> may be a secure tunnel. A user data message <NUM> between the UT <NUM> and the application server <NUM> traverses the satellite link <NUM> and a tunnel <NUM>. The tunnel <NUM> may be a secure tunnel. Communication between the satellite gateway <NUM> and the billing server <NUM> may traverse a tunnel <NUM>. The tunnel <NUM> may be a secure tunnel. Tunnels <NUM>, <NUM>, <NUM> may be secured using IPsec or similar methods. Each of the tunnels <NUM>, <NUM>, <NUM> may be separate tunnels that may traverse the internet <NUM>.

The SRS may store UT parameters, manage UT keys, authenticate the UT, generate encryption and/or integrity protection keys, and distribute the keys. Exemplary keys generated and distributed by the SRS include an application key to protect user data, an OTA key to protect an OTA message and signaling key to protect a signaling message between the SRS and the UT.

The SRS manages a UT ID that is unique for each UT. The UT ID is mapped by the SRS to the UT keys, a UT IP address and an associated Application Server IP address. The SRS forwards to the satellite gateway with the UT IP address and the associated Application server IP address. In some embodiments the SRS maps the UT ID to UT parameters, for example, a QoS, UT radio capability, UT transmission opportunity (wakeup time), UT operator, and the like. The SRS may forward the UT parameters to the satellite gateway.

For data received from a UT (Uplink or UL), a gateway may form a packet by joining UT data from a UT with a corresponding UT IP address as a source IP address and an application server IP Address as the destination IP address, and sends the packet to the Application Server. For data to be sent to a UT (downlink or DLL), the gateway deconstructs a packet from an application serve, maps the incoming source and destination IP addresses in the packet to a UT ID, and sends the data to the UT as non-IP data.

The gateway may send a Call Detail Record (CDR) for each UT to the Billing server. Each CDR may be identified by the UT ID. The billing server may receive CDR CDR for each UT and create billing based on the UT ID. The gateway decodes UT UL data using the OTA key and sends the UT data, which is encrypted by the application key, to the Application server. The gateway may encode the DL data from the Application Server with the OTA keys and sends the encoded data to the UT. The gateway may provide quality of service (QoS) treatment based on the UT parameters given by the SRS to the gateway. The gateway may page the UT. For a LEO/MEO satellite network, the gateway may estimate the covering beam based on the UT location.

The application server processes UT data. The applicant server may receives/sends data to the UT. The applicant server may send a command to the UT. The applicant server may manage different type of UTs.

Each UT may be deployed with an embedded Initial Key and UT ID. In some embodiments, UT data is non-IP data. UT uplink transmission mode is based on the one shot UT transmission. Each UT transmission (UL or DL) is encrypted and integrity protected using OTA keys. Each UT application data is encrypted and integrity protected using application teams. Each UT is tied to an Application server. UT might send data periodically or ascending may be trigger-based. UT communications with SRS may be encrypted using a signal key. For a vehicular UT, the UT may report its secure location based on pre-defined method, such as distance triggered report. For LEO and MEO satellite networks, the gateway may map a UT location to the beams. In such systems, the gateway may estimate the covering beams based on the known trajectory of the satellites.

<FIG> illustrates initial setup of a UT in a satellite loT system according to some embodiments.

A satellite IoT system <NUM> may include a UT <NUM>, a gateway <NUM>, an SRS <NUM>, an application server <NUM> and a billing server <NUM>. Each UT <NUM> may be configured or provisioned with an embedded UT ID and initial encryption key per operation <NUM>. The UT ID may be used to authenticate the UT <NUM>. In some embodiments the UT ID and/or initial encryption key may only be known by the UT <NUM> and the SRS <NUM>. The UT <NUM> may transmit an initial attach request <NUM> using for example a one-shot transmission to the gateway <NUM>. The initial attach request <NUM> may include the UT ID and data encrypted by the initial encryption keys. In some embodiments the UT ID may be in the clear. In some embodiments the initial attach request <NUM> may be acknowledged by the gateway <NUM>. In other embodiments the initial attach request <NUM> may not be acknowledged by the gateway <NUM>. The gateway <NUM> forwards the initial attach request <NUM> to the SRS <NUM> without decryption in request <NUM>. The gateway <NUM> may store the UT ID and may estimate a location of the UT. The SRS <NUM> authenticates the UT <NUM> per operation <NUM> by determining the initial encryption key based on the UT ID. At operation <NUM> the SRS <NUM> assigns/creates encryption keys for the UT ID, including the OTA Keys, AppKeys, SigKey. Additionally, during operation <NUM> the SRS <NUM> assigns the UT an IP address. The SRS <NUM> may send the UT ID, the application key and the UT IP address to the application server <NUM> in request <NUM>. The SRS <NUM> may send response <NUM> to the gateway <NUM>. Response <NUM> may include the OTA key, UT parameters, UT IP address, Application server IP address, an explicit UT location, or the like. The gateway <NUM> may store parameters provided by the response <NUM> per operation <NUM>. The gateway <NUM> may forward parameters private provided by the response <NUM> to UT <NUM>, for example, OTA Key, application key, signaling key to UT <NUM> in response <NUM>. The response <NUM> may be encrypted using the initial key. The UT <NUM> stores parameters received in response <NUM> per operation <NUM>. In some embodiments, the UT <NUM> may send an initial attachment acknowledgment response <NUM> to the gateway <NUM> that may be encrypted by the OTA key. Upon receiving the initial attachment acknowledgment response <NUM> the gateway <NUM> knows (<NUM>) that the UT <NUM> is connected.

<FIG> illustrates data transfer from a UT to an application server in a satellite loT system according to some embodiments.

A satellite IoT system <NUM> may include a UT <NUM>, a gateway <NUM>, an SRS <NUM> and an application server <NUM>. When the UT <NUM> has data to send, the data is encrypted using the Appkey per operation <NUM>. At operation <NUM>, a packet is formed by encrypting, using the OTA keys, at least the data supplemented with the UT ID. The packet is transmitted as a one-shot transmission <NUM>. Transmissions from various UTs in the system <NUM> may use the same channel and the one-shot transmission <NUM> is performed without scheduling or bandwidth allocation, either by the gateway or the UT.

In some embodiments, a one-shot transmission by a UT may include sending a RACH (radio access channel) request to synchronize the UT to the gateway, where the RACH request includes data (for example, IoT data) as a payload of the RACH message. The RACH request may not request any resources from the gateway, but may merely be a means to send data sent in a one-shot transmission. The payload of the RACH request may support such a one-shot transmission as the data from the UT to the gateway does not include an IP header. A feature of a RACH is that messages are unscheduled transmissions. There is no certainty that only a single device makes a connection attempt at one time, so collisions can result. In one-shot transmissions, transmissions from different UTs may overlap, may partially overlap or not overlap. The gateway <NUM> includes a receiver that separates the various transmissions when feasible. For some transmissions, the gateway receiver may fail to separate the various transmissions and the transmissions may be lost. In exemplary embodiment, one-shot transmissions from the UT <NUM> may be unscheduled transmissions by use of implicit dynamic bandwidth allocation. Exemplary methods of implicit dynamic bandwidth allocation include Scrambled Code Multiple Access (SCMA) or Asynchronous Scrambled Code Multiple Access (A-SCMA) coding.

At operation <NUM> the gateway <NUM> decrypts the packet using the packet OTA keys to extract the UT ID. At operation <NUM> gateway <NUM> may then map the UT ID to an IP address assigned to the UT <NUM> by the SRS <NUM> and the IP address of the application server <NUM> associated with the UT ID by the SRS <NUM>. During operation <NUM> the gateway <NUM> further creates an IP packet using the IP address of the application server <NUM>, the IP address of the UT <NUM> and the encrypted UT data as the IP packet payload and forwards the created IP packet <NUM> to the application server <NUM>. At operation <NUM> the gateway <NUM> sends a CDR to the billing server (not shown). The Application server <NUM> may optionally send an Application ACK. In some embodiments, an operation <NUM> may be used to the key refresh for the UT <NUM> by the SRS <NUM>.

<FIG> illustrates data transfer from an application server to a UT in a satellite loT system according to some embodiments.

A satellite loT system <NUM> may include a UT <NUM>, a gateway <NUM>, an SRS <NUM> and an application server <NUM>. When the application server <NUM> has data to send, the data may be sent as an IP packet <NUM> to an IP address assigned to UT <NUM>. The IP packet <NUM> may be sent securely using, for example, a tunnel. In the system <NUM>, IP routing for the UT's IP address is established such that the UT's IP address must be routed via the gateway <NUM>. The GW <NUM> maps the UT's IP address to a UT ID at operation <NUM>. The GW <NUM> may wait until a UT periodic wakeup or when UT send data at operation <NUM>. The GW <NUM> may then use the IP packet's payload as data to be sent to the UT. The IP's packet's payload maybe encrypted using an Application key assigned to the application server <NUM>. The encryption may be performed either by the application server <NUM> or the gateway <NUM>.

The GW <NUM> may then transmit the data to the UT ID via an OTA transmission <NUM>. In some embodiments, the GW <NUM> may buffer the data prior to the OTA transmission <NUM> to the UT <NUM>. For example, the GW <NUM> may buffer in order to wait until a periodic wakeup window for the UT <NUM> occurs. During the periodic wakeup window, the GW <NUM> may page and optionally wait for a page ACK from the UT <NUM> at operation <NUM>, prior to the OTA transmission <NUM>. In an exemplary embodiment, the GW <NUM> may buffer in order to send the OTA transmission <NUM> immediately after receiving a transmission from the UT <NUM>. The OTA transmission <NUM> may result in the UT <NUM> retrieving the data at operation <NUM>. The UT <NUM> may optionally acknowledge reception of the data at operation <NUM>. The optional acknowledgement may be decrypted using OTA keys at operation <NUM>. The GW <NUM> may add IP headers based on the UT ID to the optional acknowledgement at operation <NUM>. The optional acknowledgement may be sent to the application server <NUM> as an IP packet ACK <NUM> that uses the IP address of the UT <NUM> as the sender of the IP packet ACK <NUM>.

<FIG> illustrates a method for communicating with an Internet of Things (IoT) User Terminal (UT) population using a one-shot transmission according to various embodiments.

A method <NUM> for communicating with an Internet of Things (IoT) User Terminal (UT) population using a one-shot transmission may include operation <NUM> to store and distribute UT parameters for UT population. The method <NUM> may include operation <NUM> to generate/refresh Keys for UT the population. The method <NUM> may include operation <NUM> to communicate from the UT population using a one-shot transmission. The method <NUM> may include operation <NUM> to receive the one-shot transmission from a sender UT. The method <NUM> may include operation <NUM> to retrieve the sender UT parameters associated with the sender UT identifier. The method <NUM> may include operation <NUM> to generate the IP packet.

The method <NUM> may include operation <NUM> to receive an application-server IP packet addressed to a receiver UT IP address. The method <NUM> may include operation <NUM> to retrieve receiver UT parameters associated with receiver UT IP address. The method <NUM> may include operation <NUM> to generate a packet for the receiver UT. The method <NUM> may include operation <NUM> to transmit the packet to the receiver UT.

Claim 1:
An Internet of Things "loT" system (<NUM>) comprising:
a Security and Repository Server "SRS" (<NUM>) to store User Terminal "UT" parameters for each UT (<NUM>) of a UT population, wherein the UT parameters comprise a UT identifier, a UT IP address, and an application server IP address;
an Over-The-Air "OTA" link (<NUM>) to communicate from the UT population using a one-shot transmission; and
a gateway "GW" (<NUM>) configured to receive the one-shot transmission from a sender UT (<NUM>) of the UT population and to send an IP packet comprising a portion of the one-shot transmission to an application server (<NUM>),
wherein the one-shot transmission comprises an unscheduled transmission between the GW (<NUM>) and the sender UT (<NUM>),
the one-shot transmission comprises a sender UT identifier, and
a UT identifier for each UT (<NUM>) of the UT population is unique.