1. Field of the Invention
This invention relates generally to the field of wireless network systems. More particularly, the invention relates to an improved architecture and method for connecting, configuring and testing wireless devices including Machine-to-Machine (“M2M”) devices and applications.
2. Description of the Related Art
Unlike mobile phones, the primary purpose of a connected “Machine-to-Machine” (hereinafter “M2M”) device is not wireless communications per se. Rather, wireless communication enhances the M2M devices. For example, connected navigation devices are firstly navigation devices, but are enhanced by being connected; a security system is not designed primarily for wireless communications, but is greatly enhanced by wireless connectivity, etc. This means that, unlike wireless phones, a developer of a M2M connected device may not be principally a communications expert, rather he or she may be an expert of the M2M device application. However, M2M device application software needs to drive the wireless communications as well. In essence, the M2M device developer needs wireless communications expertise.
Many M2M connected devices tend to be specialized for a particular application. At first glance, this may appear to simplify the wireless communications requirements. For example, some M2M connected devices may not need to support voice. However, the opposite is often true, M2M connected devices have more complex communications requirements. Unlike wireless phones, most emerging M2M connected devices do not have a human in charge of communication i.e., deciding when and how to connect, which operator to use, how to handle problems such as poor coverage, etc. Instead, the wireless communications of M2M connected devices must happen automatically, reliably and economically despite network issues or coverage issue. In the absence of direct human control, these communications requirements must be met by the M2M device communications software.
Virtually all wireless carriers today offer both voice and data services. FIG. 10 illustrates a high level architecture of a wireless service provider 110 communicating with one wireless device 101 using both voice and data channels and communicating with a second wireless device 103 using only a data channel. By way of example, many wireless carriers employ the Global System for Mobile Communications (“GSM”) standard to support voice traffic and the General Packet Radio Service (“GPRS”) standard to support data traffic over the same wireless network. In such a configuration, voice logic and circuitry 112 shown in FIG. 10 processes the GSM voice traffic and separate data logic and circuitry 111 processes the GPRS data traffic. While some of the embodiments of the invention described below implement the GPRS standard for data services and GSM for voice services, it should be noted that the underlying principles of the present invention are not limited to any particular wireless network protocol.
Using the data channel, wireless devices 101, 103 communicate with external servers 131 such as Web servers, instant messaging servers and email servers via the Internet 120 (or other packet-based data network). One particular type of wireless device 103 configured for data traffic is the M2M device. M2M devices are deployed in application-specific telemetry systems to collect data using sensors and transmit the data to a destination such as a server accessible over the Internet (or other data network). In the past, telemetry systems were the exclusive domain of very large well financed organizations. For example, large oil and gas companies and electric utilities, through the use of custom-built, proprietary data networks, were some of the first private organizations to use telemetry. In recent years, however, the cost of access to public wireless data networks has dropped, opening the door for new, cost effective M2M applications including, for example, fleet management, point-of-sale transactions, consumer electronics, healthcare monitoring, security, and surveillance, to name a few.
Even with the decreased cost for wireless data communication, however, the process of M2M application development and onboarding remains complex, time-consuming and inefficient, requiring a significant amount of manual effort on the part of a prospective M2M application developer.
In order to develop such applications, the prospective M2M application developer may engage with the members of the sales team at the wireless service provider (typically cellular carriers or their resellers) and provide detailed plans, business projections, and technical details just to get started. Once the process is initiated, each step along the way may take a lengthy amount of time and manual effort on the part of multiple individuals inside the service provider organization. For example, it may require a significant amount of time to simply receive usable Subscriber Identity Modules (“SIMs”) for testing purposes. Even after receiving usable SIMs from the service provider, the prospective M2M application developer still has the daunting task of designing the final product, and very little help is provided to iron out various defects/bugs introduced at this early stage.
Moreover, the sales team at the wireless service provider has very little, if any, visibility into how the prospective M2M application developer is progressing, often resulting in time wasted chasing poor-quality prospective M2M application developers. This process can take many months (typically between 6-18 months) and during this time, both the prospective M2M application developer and the service provider waste a lot of time and effort in these discussions.
Many wireless devices are built upon a communications module, or chipset and stack. The module is effectively a wireless modem that allows a device application to communicate over a wireless network through GPRS/EDGE/UMTS data, voice, circuit switched data, SMS, etc. The device application itself uses the module whenever it wishes to send or receive data through any of the bearers supported by the module. Most modules are controlled from the device application directly by AT commands (Hayes command set), with many standardized commands specified in 3GPP standards.
For example, there are commands to configure the module itself, commands to control which network to select, commands for configuring, setting up and tearing down data sessions, commands for short message handling, etc. In addition, most module vendors have proprietary AT commands. Moreover, each command has a set of possible errors that must be handled, plus there may be unsolicited notifications from the module to the software. Not only must the application developer be aware of the various commands and notifications, the application developer must have the expertise to apply the commands correctly and handle the notifications correctly. This may require the application developer to be skilled in wireless communications.
To make matters manageable, some module vendors implement a development environment and interface that shields the developer from the details of the wireless communications. This has the advantage that the application developer need not manage the various AT commands. However, it has the disadvantage that the module vendor needs to independently handle all the interactions with the wireless network. Unless the module vendor is also in control of the wireless service subscription and network, it is not feasible for the module to know how to handle the various real-world scenarios. For example, the module does not know which operators are the service provider's preferred roaming partners; the module does not know what the service provider requires for re-tries when communications do not work, the module does not know how to report network diagnostics to the network operator, etc.
Consequently, what is needed is a more efficient system and method which addresses the current inefficiencies associated with integrating wireless networks, M2M developers, wireless device developers, and wireless data applications. A solution may be to deploy a device middleware layer that works in concert with the network service provider, provides a simple interface to the application developer and manages the module or chipset/stack on behalf of the device application.