Methods and apparatus for machine-to-machine communications

Methods and apparatus for machine-to-machine communications are disclosed. A communications server provides a way for application servers on the Internet to communicate with a plurality of physically remote devices that do not have “traditional” Internet connections. Communications between an application server and its remote devices are normalized by the communications server so that the need for a variety of wired and wireless protocols remains transparent to the application server. In addition, the application server may initiate communications with remote devices using dynamic IP addresses, because the communications server discovers dynamic IP addresses using a non-IP based protocol.

TECHNICAL FIELD

The present disclosure relates in general to network communications and, in particular, to methods and apparatus for machine-to-machine communications.

BACKGROUND

Many machine monitoring and control systems include electrical communication between two machines. For example, a credit card reading machine at a grocery store communicates with a bank computer to verify a credit transaction. Often, engineers designing these machine-to-machine communication systems use data networks such as the Internet to facilitate communication between two machines or devices. For example, the Federal Aviation Administration (FAA) has a rule that transmission towers above a certain height must include a warning light for low flying aircraft. When the light burns out, the owner or operator of the tower must notify the FAA and must fix the light within a certain period of time. A notification system including a software application residing on a typical Internet server may be charged with notifying the FAA (and maintenance personnel) when a light on top of a tower goes out. However, there may be no readily convenient and cost effective way to hard-wire each of the light sensors on the hundreds or thousands of monitored towers. Instead, engineers use wireless communication to facilitate machine-to-machine communication between each of the towers and the notification system.

Wireless connections to the Internet have at least the following two problems. First, all of the physical areas that contain the remote devices may not be covered by the same wireless system. Some areas may be covered by Code Division Multiple Access (CDMA) cellular systems, but not by General Packet Radio Service (GPRS) or SMS. Other areas may be covered by GPRS, but not by CDMA. Some areas may have no wireless coverage at all. When no wireless service is available, the remote device may need to use the Plain Old Telephone System (POTS).

Simultaneously interfacing with multiple different protocols such as CDMA, GPRS, SMS, MMS, WiFi, WiMax, POTS, cable, DSL, satellite, etc is burdensome. An engineer designing the monitoring and control software must keep track of which devices use which protocols and adapt the software application accordingly. If one of the protocols (of which there are many) used by one of the devices (of which there may be thousands) changes, the engineer must adapt the software to accommodate this change. Therefore, a need exists for a system that enables engineers to design systems that can communicate with a wide variety of remote devices without or with little concern for what protocol(s) are required to communicate with each device.

The second problem is that wireless Internet devices are often assigned a “dynamic” Internet Protocol (IP) address. A dynamic IP address is a network address that changes. Originally, devices connected to the Internet each had a unique IP address that did not typically change (i.e., a static IP address). However, as the number of devices connected to the Internet have increased, the number of available IP addresses have started to become exhausted.

To conserve this limited number of IP addresses, wireless access providers assign IP addresses to a remote device dynamically on an as needed basis. More specifically, the wireless access providers keep a pool of IP addresses (e.g., 1,000) that is shared by a larger number of devices (e.g., 10,000). When a device is communicating, the wireless access provider assigns that device one of the available IP address. When a device is not communicating, that device does not have an assigned IP address. In this example, as long as no more than 1,000 of the possible 10,000 devices are communicating or are online simultaneously, the system works.

However, as a result of the dynamic allocation of IP addresses, a particular device may have one IP address at one time and another IP address at another time (or no IP address at all most of the time). This works fine for communications that are initiated by the remote device. However, when a machine such as the notification system needs to initiate a message to the remote device, the initiating device does not know what IP address to use for the remote device, because that address may have changed numerous times and/or the device may not even be currently assigned an IP address. Therefore, a need exists for a system that enables software running on application servers to initiate communication with remote devices without concern for the dynamic IP address associated with each remote device.

SUMMARY

The system described herein solves both of these problems using a communications server. The first problem is solved because the communications server normalizes data communications from different communications systems or protocols. More specifically, the communications server translates all of the communications between an application server and its associated remote stations, so that the application server need not determine what protocols are being used to communicate with the remote stations. Some remote stations may use one wireless protocol (e.g., CDMA), other remote stations may use another wireless protocol (e.g., GPRS), and still other remote stations may not use any wireless protocol (e.g., POTS). Regardless of what protocol a particular remote device is using, the communications server translates messages from the application server to the native language of the remote device. Similarly, the communications server translates messages from the remote device to the native language of the application server.

The second problem is solved because the communications server knows or discovers a remote station's dynamic IP address. Messages addressed to a particular remote device (e.g., using an internal static IP address) are first routed to the communications server. The communications server may already know the remote station's dynamic IP address via information sent from a wireless network associated with the remote station, and/or the remote station may send a data packet to the communications server each time the remote station receives a new IP address. Alternatively, the communications server may discover the remote station's dynamic IP address by sending the remote station a non-IP based message. For example, the communications server may send a remote station a Short Message Service (SMS) message to “wake-up” the remote station. SMS messages are based on a phone number, not an IP address. The communication server determines the remote station's non-IP address (e.g., phone number) by looking up the non-IP address based on the received station identifier (e.g., internal static IP address).

After the remote station receives the non-IP based message, the remote station acknowledges the communications server. In some instances, the remote station continues to communicate with the communications server via the non-IP based protocol (e.g., SMS). In other instances, the remote station establishes IP based communication with the communications server. This has the effect of obtaining an IP address from the wireless provider which is inherent in subsequent messages sent to the communications server. Regardless of what protocol a particular remote station “prefers” to use, the communications server keeps track of that protocol and adapts its communications with that device accordingly.

Therefore, the present system and method has the advantage of giving software designers transparent communication to a plurality of remote devices. The application designer need not be concerned with what protocol each remote device is using and what IP address (if any) is associated with each remote device. Instead, the application server simply identifies the remote device (e.g., by a permanent device number), and the communications server resolves all of the protocol and IP address issues.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

A high level block diagram of an exemplary network communications system100is illustrated inFIG. 1. The illustrated system100includes one or more remote stations102, one or more network access servers104(e.g., a wireless telephone company server such as Sprint PCS), one or more application servers106, one or more communications servers108, and one or more authentication, authorization, and accounting (AAA) servers112. Each of these devices may communicate with each other via a connection to one or more communications channels110such as the Internet or some other suitable network.

Each server104,106,108and112stores a plurality of files, programs, and/or web pages for use by the remote stations102. In particular, each application server106hosts one or more programs designed to monitor and/or control a plurality of remote stations102. For example, each remote station102may be associated with a tower that includes a light to make the tower visible to low flying aircraft. When the light burns out, the remote station102needs to report that information to the application server106so that the application server106can report the outage to the FAA and maintenance personnel. The AAA server112handles requests for access to computer resources and provides authentication, authorization, and accounting (AAA) services.

One server104,106,108and/or112may interact with a large number of remote stations102. Accordingly, each server104,106,108and112is typically a high end computer with a large storage capacity, one or more fast microprocessors, and one or more high speed network connections. Conversely, relative to a typical server104,106,108and112, each remote station102typically includes less storage capacity and a single microprocessor. However, as described in detail below, each remote station102preferably supports multiple network connections and/or protocols.

A more detailed block diagram of a remote station102is illustrated inFIG. 2. It will be appreciated that one or more components of a remote station102may be embedded into a product when the product is manufactured (e.g., an air compressor with an embedded wireless monitor), and/or one or more components of a remote station102may be added to a product after the product is manufactured (e.g., a cell tower light monitor).

The remote station102may include a controller or any other suitable device. The remote station102includes a main unit202which preferably includes one or more processors204electrically coupled by an address/data bus206to one or more memory devices208, other computer circuitry210, and one or more interface circuits212. The processor204may be any type of suitable processor. The memory208preferably includes volatile memory and non-volatile memory. Preferably, the memory208stores a software program that interacts with the other devices in the system100as described below. This program may be executed by the processor204in a conventional manner. The memory208may also store digital data indicative of device settings, files, programs, web pages, protocols, etc. retrieved from a server104,106, and/or108and/or loaded over the air or into the firmware at the factory. The interface circuit212may be implemented using any suitable type of interface standard, such as a serial interface.

One or more sensors216are also connected to the interface circuit212for gathering data associated with the purpose of the remote station102. For example, the sensor216may be a circuit to determine if a tower light is operating, a global positioning receiver, a temperature sensor, a water sensor, a smoke detector, a carbon-monoxide detector, and/or any other suitable sensor or combination of sensors.

One or more storage devices220may also be connected to the main unit202via the interface circuit212. Typically, a flash ROM device is used. However, any suitable memory such as a hard drive, CD drive, DVD drive, and/or other storage devices or combination of storage devices may be connected to the main unit202. The storage devices220may store any type of data used by the remote station102.

The remote station102may also exchange data with other network devices via a wireless communication interface222and an antenna224, which connects to a network access server104. Preferably, the remote station102includes multiple modes of communication. For example, the remote station102may be capable of communicating using CDMA, GPRS, SMS, MMS, WiFi, WiMax, POTS, cable, DSL, satellite, etc.

A more detailed block diagram of a communications server108is illustrated inFIG. 3. Like the remote station102, the main unit302in the communications server108preferably includes a processor304electrically coupled by an address/data bus306to a memory device308and a network interface circuit310. The network interface circuit310may be implemented using any suitable data transceiver, such as an Ethernet transceiver. The processor304may be any type of suitable processor, and the memory device308preferably includes volatile memory and non-volatile memory. Preferably, the memory device308stores a software program that implements all or part of the method described below.

In particular, the memory preferably stores a dynamic Internet Protocol (IP) resolution module312and a data normalization middleware module314. The dynamic Internet Protocol (IP) resolution module312determines the dynamic IP address associated with the remote stations102as described in detail below. The data normalization middleware module314translates communications between the applications servers106and the remote stations102as described in detail below. These software modules may be executed by the processor304in a conventional manner. However, some of the steps described in the method below may be performed manually or without the use of the communications server108. The memory device308and/or a separate database314also store files, programs, web pages, etc. for use by other servers104,106and/or remote stations102.

A message diagram showing communications400between an application server106and a remote station102via a communications server108is illustrated inFIG. 4. In this example, the application server106initiates the connection to the remote station102by sending a message402to the communications server108. The message402includes an identifier associated with the remote station102and a data payload for the remote station102. The remote station identifier may be any suitable identifier. For example, the remote station identifier may be a device ID number or a static IP address. By using a VPN and an internal static IP address, application servers106may operate as if remote devices102with dynamic IP address actually have static IP addresses. This enables legacy systems that expect static IP address to communicate with new remote devices102without any modification to the legacy systems.

Certain applications, such as those based on POTS, rely on static IP addresses. The system described herein provides a mechanism using private IP addresses, VPN client access to those addresses, and either a TCP or a UDP proxy server process to enable these applications to operate in a dynamic address environment (e.g., wireless) without extensive modifications. To establish communications to a remote device102the application server106communicates to either the TCP or the UDP proxy server via a private static IP address assigned to that particular remote device102. The proxy server (either UDP or TCP), then determines the current dynamic IP address of the remote device102and establishes communications directly with the remote device102. All messages that need to go to the remote device102from the application server106are sent through the appropriate proxy server.

In the example shown inFIG. 4, the communications server108is a separate device from the application server106. Accordingly, a standard network protocol, such as transport control protocol/Internet protocol (TCP/IP) is used. However, in some embodiments, the communications server108is implemented in the same device as the application server106. In such an instance, an internal communication scheme, not requiring the use of a network protocol, is preferably used to send messages from the application server106to the communications server108. For example, the message may be passed as an argument to a procedure call and/or stored in a shared memory.

After the communications server108receives the message402from the application server106, the communications server108determines if the message is larger than a predetermined threshold. If the message402from the application server106is smaller than the predetermined threshold, the communications server108may forward the message402to the remote station102using a non-IP based protocol. For example, messages smaller than 140 characters of data may be sent to the remote station102via an SMS message. Preferably, SMS messages may be sent in any suitable format because the communication server dynamically determines which application server the SMS message is associated with. If the message exceeds the threshold, the communications server108may need to forward the message to the remote station102using the IP address of the remote station102. However, the remote station may be using a dynamic IP address, and/or the remote station may be temporarily offline.

A dynamic IP address is a network address that changes. To conserve a limited number of IP addresses, the network access server104assigns an IP address to a remote station102on an as needed basis. Because remote stations102are typically communicating only a relatively small percentage of the time, the remote stations102can share a pool of IP addresses associated with the network access server104. When a remote station102needs to send a message, the remote station102requests an IP address from the network access server104. The assigned IP address is then reserved for that remote station102for a short period of time (e.g., one hour). After that period of time, the IP address is returned to the pool of IP addresses, and the remote station102is left with no IP address.

Dynamic assignment of IP addresses creates a problem when another device needs to initiate a message to the remote station102. The initiating device does not know where to send the message, because the remote station102may not have an IP address at the time the device wants to send the message to the remote stations102. The communications server108may know the dynamic IP address associated with the remote station102. For example, a network access server104associated with the remote station (e.g., a wireless telephone company server such as Sprint PCS) may keep the communications server108informed of the dynamic IP address associated with the remote station102. Alternatively, the remote station102may send a data packet to the communications server108each time the remote station102receives a new IP address.

If the communications server108does not know the dynamic IP address associated with the remote station102, the communications server108may discover the dynamic IP address by sending a different message404to the remote station102. This message404may not be suited for large amounts of data (e.g., the message402that the application server106is trying to send to the remote station102). However, this message404does not require the use of an IP address. For example, a Short Message Service (SMS) type message may be sent to the remote station102using a telephone number associated with the remote station102.

More specifically, SMS is a service of Global System for Mobile (GSM) communications that is capable of sending up to 140 characters of data. SMS is primarily intended for text messages to cellular telephone users. If an application server106is attempting to send a short “action” message to a remote station102(e.g., “turn on the light”), then the communications server108may simply translate the message to an SMS message and send it to the remote station102without the need to switch to an IP based protocol as described in detail below. However, in this instance, the SMS message404is an “establish communication” message indicating that a larger communication exchange needs to occur. This type of SMS message tells the remote station102to request an IP address from the network access server104. The assigned IP address is then sent from the remote station102to the communications server108in the form of an IP based message406, such as a General Packet Radio Service (GPRS) message. Unlike SMS, GPRS is a high speed continuous connection that can be used to move large amounts of data.

Although the SMS protocol and the GPRS protocol are used throughout this description, any suitable protocols may used. For example, any of the following protocols may be used: CDMA, GPRS, SMS, MMS, WiFi, WiMax, POTS, cable, DSL, satellite, etc. In one embodiment, a remote station102may not have access to an IP based protocol. In such an instance, the remote station102uses a non-IP based protocol (e.g., SMS) to communicate back to the communications server108, and the communications server108performs data normalization for the non-IP based messages before the messages are forwarded to the application server106.

If the communication system100is functioning properly, the remote station102responds to the communications server108via a non-IP acknowledgment406to the non-IP message404and/or with a IP-based response406to the non-IP message404. For example, the response406may be an SMS acknowledgement, an SMS message with the remote station's dynamic IP address, and/or a WiMax message with the remote station's dynamic IP address. If the communications server108fails to receive the response message406within some predetermined period of time, the communications server108preferably buffers the application message402for some predetermined period of time and/or until the communications server108is able to communicate with the remote station102. For example, if the communications server108fails to receive the response message406within ten seconds, the communications server108may try to establish communication with the remote station102every ten seconds for the next thirty minutes.

After the communications server108receives the message406with the dynamic IP address associated with the remote station102, the communications server108normalizes408the data sent by the application server106in the original message402. For example, the communications server108may reverse the byte order of the message402(e.g., big Endean to little Endean), and/or the communications server108may convert the format of the message402to another format (e.g., to make the message402compatible with GPRS and/or the remote station102). The data may be normalized by the communications server108at any time after receiving the data. For example, the communications server108need not wait until the dynamic IP address of the remote station102is known.

The communications server108then sends the normalized message410to the remote station102using the IP based protocol (e.g., TCP over GPRS). If the remote station102needs to reply to the message410, the remote station102preferably sends the replay412using the same protocol. However, any suitable protocol may be used for the reply message. For example, if the reply message is short and the remote station102has SMS coverage, the reply message may be an SMS message.

Before the communications server108can forward the message to the application server106, the communications server108normalizes the data414. This time, the normalization process typically reverses the operations previously performed. For example, the communications server108may reverse the byte order of the message (e.g., little Endean to big Endean) and/or convert the format of the message412to make the message412compatible with the application server106.

After the message412from the remote station102is normalized, the normalized message416is sent to the application server106using a protocol used by the application server (e.g., TCP/IP). If the communications server108is unable to communicate with the application server106, the communications server108preferably buffers the normalized remote station message416for some predetermined period of time and/or until the communications server108is able to communicate with the application server106. For example, if the communications server108may try to establish communication with the application server106periodically for some predetermined period of time.

If the application server106needs to send another message418to the remote station102while the remote station102still has the same IP address, the communications server108may simply normalize the data420and send the normalized message422to the remote station102without the need to send an SMS message to discover the dynamic IP address of the remote station102. The communications server108may determine that the remote station102still has the same IP address by checking if the connection (e.g., a GPRS connection) to the remote station102is still open and/or by testing the last know IP address of the remote station102with a test message. If the connection is closed and/or the test message fails, the communications server108preferably sends another SMS message to rediscover the dynamic IP address associated with the remote station102. It should be appreciated that protocols other than SMS may be used for this purpose.

In addition to the different uses of protocols described above, each remote station102is preferably capable of using “fallback” protocols, if one of the remote stations “primary” protocols fails. For example, some remote stations may be placed in areas where GPRS service is unavailable. As a back up, the remote station102may try one of the fallback protocols (e.g., SMS). In this manner, one remote station design may be deployed in a wide variety of geographical areas without reprogramming to accommodate different geographical areas that are covered by different protocols. In addition, this hierarchy of protocols enables remote stations102to use the most efficient protocol available to that remote station102. For example, to an application server106, three different remote devices102may appear to each have a static IP address. However, the first address may be associated with a CDMA based remote device102, the second address may be associated with a GSM/GPRS based device, and the third address may be associated with a POTS based device.

A flowchart of an example process500for machine-to-machine communications is illustrated inFIG. 5. Preferably, the process500is embodied in one or more software programs which is stored in one or more memories and executed by one or more processors. Although the process500is described with reference to the flowchart illustrated inFIG. 5, it should be appreciated that many other methods of performing the acts associated with process500may be used. For example, the order of many of the steps may be changed, and many of the steps described are optional.

Generally, the process500uses the communications server108to provide a way for an application server106to communicate with a plurality of remote stations102. Communications between an application server106and its remote stations102are normalized by the communications server108so that the need for a variety of wired and wireless protocols remains transparent to the application server106. In addition, the application server106may initiate communications with dynamically addressed remote stations102using static IP addresses (or other fixed identifiers), because the communications server108knows or discovers the dynamic IP addresses of the remote stations102.

The process500begins when an application server106determines that it needs to send a message to a remote station102as indicated in block502. For example, the application server106may have a large software patch that needs to be loaded into the remote station102. The application server106then sends the message intended for the remote station102to the communications server108as indicated in block504. This message is preferably sent to the communications server108over a standard Internet connection using a standard Internet protocol (e.g., TCP/IP). However, this message may also be encrypted using a Virtual Private Network (VPN) and/or any other suitable means of securing data.

The message from the application server106to the communications server108includes a remote station identifier other than an IP address. The remote station identifier may be a unique identifier assigned by the communications server108, an internal static IP address, a Media Access Control (MAC) address, a telephone number, and/or any other suitable device identifier. In some instances, the remote station102will actually have a static (non-dynamic) IP address. In such an instance the remote station identifier may be the fixed IP address associated with the remote station102, and no translation may be needed.

After the communications server108receives the message from the application server106, the communications server108determines if a connection to the identified remote station is currently open or if the IP address of the identified remote station102is known as indicated in block506. For example, the communications server108may send a test message to the last know IP address of the remote station102.

If the IP address of the remote station102is not known, the communications server108sends a non-IP based message to the remote station102indicating that the remote station102should initiate an IP based conversation as indicated in block508. For example, the communications server108may send an SMS message to the remote station102. The capacity of the SMS message may be too small and/or the data rate too low to carry the full message from the application server106. However, the SMS message does not require the communications server108to know the IP address of the remote station102. Instead, the SMS message uses a phone number associated with the remote station102. After the remote station102receives a dynamic IP address from a network access server104, the communications server108receives the dynamic IP address from the remote station102as indicated in block510.

The communications server108then converts the message from the application server106to a format expected by the remote station as indicated in block512. For example, the communications server108may reverse the byte order of the message (e.g., big Endean to little Endean), and/or the communications server108may convert the format of the message to another format (e.g., to make the message compatible with GPRS and/or the remote station102).

After the message from the application server106is normalized for the remote station102, the communications server108sends the normalized message to the remote station102using the IP based protocol as indicated in block514. For example, the communications server108may send the message to the remote station102using a GPRS based protocol. A non-IP based protocol may also be used.

Similarly, if the remote station102needs to reply to the application server106, the remote station102preferably sends the reply to the communications server108using the IP based protocol as indicated in block516. Again, before the communications server108can forward the message to the application server106, the communications server108normalizes the data to make the message compatible with the application server106as indicated in block518.

After the message from the remote station102is normalized, the normalized message416is sent to the application server106using a protocol used by the application server as indicated in block520. For example, the communications server108may send the message from the remote station102to the application server106using TCP/IP over a VPN. By using a VPN, the data is secure between the servers104,106, and108. Typically, wireless data (e.g., GPRS) is encrypted by the network access server104.

If the application server106needs to send another message to the remote station102while the remote station102still has the same IP address, the communications server108may simply normalize the data and send the normalized message to the remote station102without the need to send an SMS message to discover the dynamic IP address of the remote station102.

A series of block diagrams showing one example of a communication exchange between an application server and a remote station via the communications server is illustrated inFIGS. 6a-6f. In this example, in order to comply with an FAA rule, a tower light server106monitors a remote tower light client102to determine if a light on the tower is operational. In this example, the tower light server106would like to send a large software patch to the tower light client102. However, the tower light server106does not know the IP address of the tower light client102(if any), and the software patch is too large to send to the tower light client102via SMS messaging.

InFIG. 6a, the tower light server106sends the software patch to the communications server108with an identifier associated with the tower light client102. InFIG. 6b, the communications server108determines that this software patch is too large to send to the tower light client102via SMS messaging and that it does not know a valid IP address for the tower light client102. As a result, the communications server108sends a short message to the tower light client102via SMS requesting the tower light client102to communicate with the communications server108via GPRS.

InFIG. 6c, the tower light client102responds by obtaining a dynamic IP address (if it did not already have one) from the GPRS server104. The tower light client102then sends a message including the IP address to the communications server108. InFIG. 6c, the communications server108normalizes the software patch message sends it to the tower light client102via GPRS using the newly discovered IP address associated with the tower light client102. InFIG. 6e, the tower light client102acknowledges reception of the software patch to the communications server108, and inFIG. 6f, the communications server108sends a normalized version of the acknowledgement message to the tower light server106.

From the tower light server's perspective, the tower light server106merely sent the software patch to the communications server108with an identifier associated with the tower light client102and received the acknowledgement message. Details about the dynamic IP address of the tower light client102were hidden from the tower light server106.

In summary, it will be appreciated that methods and apparatus for machine-to-machine communications have been provided. The foregoing description has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the exemplary embodiments disclosed. Many modifications and variations are possible in light of the above teachings. It is intended that the scope of the invention be limited not by this detailed description of examples, but rather by the claims appended hereto.