Patent Application
20070058634
1. Field of the Invention
This invention relates to wireless sensor devices and more specifically to communication with wireless sensor devices.
2. Description of the Related Art
In recent years, a single development—the introduction of network-enabled cell phones was responsible for doubling, between 2001 and 2003, the number of devices connected to the WorldWide Web. As impressive as this trend has been to date, industry watchers predict an even more dramatic increase in the next few years. Today more than 3 billion devices have Web access, and that number is expected to grow to 14 billion within five years, driven primarily by the proliferation of tiny, battery-powered, wireless sensor devices capable of monitoring temperature, vibration, light intensity, moisture, vital signs, etc. Industrial, agricultural, health care, environmental, security, and military users, among others, are beginning to recognize how wireless sensors can revolutionize their operations. As these devices become available at commodity prices, staggering numbers of them will start turning up everywhere imaginable.
These devices typically lack a display or input mechanism for direct interaction with users and those users are often unskilled in managing and administering computer systems. Thus, interaction with these devices can be challenging. As the number of potential applications for tiny, battery-powered, “mote”-like, wireless sensor devices grows, so does the need to simplify and secure interactions with these devices.
Accordingly, it would be desirable to provide improved interaction capability with such devices. One aspect of improved interaction capability is to provide a user-friendly mechanism for discovering available wireless sensor devices and for monitoring and configuring them. A small web server can be utilized on the highly constrained sensor devices that supports both HTTP and HTTPS and runs efficiently within the tight computing, networking and memory constraints of mote-like sensor devices. By integrating a secure web server into a sensor device, one can interact with the wireless sensor devices simply and easily using a web browser. Besides the advantage of a familiar user interface and platform independence, this approach also offers well established and familiar communication security in the form of SSL, a protocol supported by virtually every browser. With the addition of an application-level, duty-cycle based approach to low-power listening for incoming service requests to the web server on the highly constrained device, significant improvements can be made power conservation while preserving the ability to interact conveniently, while providing a convenient discovery mechanism.
In one embodiment a method provides a dynamic web page in a web server of a gateway that is accessible by a client node communicatively coupled to the gateway node by a first network. The dynamic web page lists one or more constrained devices communicatively coupled to the gateway node over a second network, the second network being wireless. A URL associated with each device in the list of devices is used by the client node as an entry point to communicate with a web server on one of the constrained devices. In an embodiment, the gateway node discovers a constrained device that is newly present on the wireless network absent a request from the client node; and lists the newly present constrained device on the list. In an embodiment the gateway node is configured to automatically discover a constrained device that is newly present on the wireless network utilizing a periodically sent message as an indicator of the presence of a constrained device and to populate the list of the one or more constrained devices with the newly present constrained device.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The use of the same reference symbols in different drawings indicates similar or identical items.
Referring to
Referring to
Exemplary wireless sensor devices typically range in size from a large coin to a matchbox and are equipped with inexpensive 8- or 16-bit processors and a small amount of memory, e.g., 4KB to 10KB of RAM. Exemplary wireless sensor devices include a family of sensor platforms such as Telos, called “motes” running an operating system call TinyOS. Another example of a wireless sensor device is a WINS node, which is a StrongARM based wireless sensor developed at Rockwell Scientific. Such wireless sensor platforms typically include an ultra-low-power microcontroller. An embodiment of the invention may utilize the Telos (Rev B) “mote” as the wireless sensor device, which has a 16-bit CPU and an IEEE 802.15.4 radio. The Telos mote is powered by two AA batteries and application-specific sensors can be attached to digital and analog input pins or to an I2C bus interface. The Telos motes are the successors to the Mica family of motes (Mica2dot, Mica2 and MicaZ) and offer greater computing power and higher radio bandwidth (compared to the Mica2dot and Mica2). They are equipped with 16-bit CPU, rated for 8 MHz, and an IEEE 802.15.4 compatible radio, and an onboard USB connector to download applications.
As described above, the client node 103 may communicate with the wireless sensor devices via a standard web browser. A simplified view of the World Wide Web consists of servers, called web servers that respond to requests from clients, called web browsers, for specially formatted data called a web page. Web pages are typically written in HTML and transported over a protocol called HTTP or its cryptographically secure variant called HTTPS. Web pages can display text in different styles and formats (lists, tables, etc.), can embed images and also include links to other pages that may be followed by simply clicking on the associated key word or phrase.
Manufacturers of networked devices like broadband/DSL routers, firewalls, WiFi bridges, and network printers have been embedding small web servers allowing these devices (many of which do not have any direct means of user interaction) to be monitored and controlled via a browser. Information such as device description and operating instructions is included in the form of static web pages. The embedded web server can also generate pages dynamically containing real-time information about the device, e.g. the filtering rules configured in a firewall or the status of a printer's queue. Furthermore, the use of HTML forms allows a user to change settings and configure these devices via a browser.
One can create a tiny web server (capable of both HTTP and HTTPS communication) that can fit within the tight computational, networking and storage constraints of wireless sensor devices. In one embodiment, the tiny web server implements a number of optimizations for reducing resource usage while maintaining compatibility with standard SSL. It supports 1024-bit RSA and 160-bit ECC (which provides equivalent security) as well as SHA1, MD5 and RC4. These cryptographic algorithms are written in C except for the most time critical portions (e.g., big integer operations) which are written in assembly language. An exemplary web server suitable for use on the wireless sensors described herein is described in “Sizzle: A Standards-based End-to-end Security Architecture for the Embedded Internet,” Third IEEE International Conference on Pervasive computing and Communications (PerCom), March 2005, Kauai, Hi.” and in the patent application entitled “Method and Apparatus for Reducing Bandwidth Usage in Secure Transactions,” application Ser. No. 11/072,061, filed Mar. 4, 2005, naming Vipul Gupta et al. as inventors, which application is incorporated herein by reference. Having such a web server enables devices like home appliances, personal medical devices, industrial sensors, utility meters, etc. to be monitored and controlled across the Internet. In addition, the use of HTTPS provides strong cryptographic security, including confidentiality, data integrity, authentication and access control, where needed. The web servers 145 on the wireless sensor devices connect to the Internet through the gateway.
Before a user can interact with the web server embedded within a device, the user needs to first determine the IP address or URL where the server is located. Consider a scenario, where a homeowner brings home a newly purchased network-capable device, such as a thermostat or other wireless sensor type device. It would be desirable to simplify the task of finding the embedded web server on the wireless sensor device.
The web server at the gateway creates a dynamic web page listing devices currently on the wireless network, e.g., currently active devices. Each entry includes a URL that acts as an entry point for interacting with the web server embedded inside that device. Referring to
In an embodiment, the gateway device has functionality so that it can discover new devices as they are introduced and update the dynamic web page that lists the known devices. The specific details of discovery protocols are known in the art, for example, one could reuse an existing discovery protocol like Universal Plug and Play (UPnP), Service Location Protocol (SLP), Bonjour or another variant. Using a discovery mechanism to create a dynamic page listing a universal resource locator (URL) that acts as an entry point into the newly discovered device simplifies user interaction with the device.
Assuming a user has just installed a new device, after turning on the device, the user directs a web browser to a fixed URL on the gateway where all known devices are listed. After the device is discovered, it automatically appears in the list of known devices with a link to its embedded web server. Clicking the link brings up the starting web page for the device with overview information and additional links for monitoring and/or configuring the device. The URL information associated with the newly discovered device can either be registered explicitly by the sensor device as part of the discovery protocol or known directly to the gateway either because it assigns the IP address to the sensor device (the gateway may also act as a DHCP server) or maps the sensor device web server to an available TCP port number at its own IP address. With this new functionality, the overall user experience in integrating a newly purchased device is greatly simplified. The “device listing” web page on the gateway may use the refresh meta tag causing the browser to periodically reload this page thereby eliminating the need for any explicit user action for discovering a newly introduced device.
The web server implementation may be individually tailored for each device. For example, the web server inside a thermostat may have a page with the current temperature and buttons to choose between off/cold/heat settings, while a web server inside a GPS-enabled bracelet may have a page detailing recent movements of the wearer. Depending on the particular application, a web page may need to be sent securely and only to appropriately authenticated users.
In an embodiment, a sensor device can initiate communication (in contrast, a server simply responds to requests for information). This functionality is useful in sending out urgent notifications. For example, a chemical plant operator may find it more useful to have an industrial sensor send out a notification upon detecting a measurement outside of the normal range compared to sitting in front of a browser periodically monitoring that sensor. Notifications may be communicated in any number of ways, e.g., as an email or SMS message and may be secured (when needed) through one of several possible mechanisms including S/MIME (which provides message level security) or SSL (which secures the message only when it traverses the protected channel). The device may initiate data transfers on its own instead of polling for incoming requests to save energy associated with idle listening. In such an embodiment, the device accumulates sensor readings in a buffer and transmits them whenever that buffer is full. Embodiments may utilize a combination of idle listening and initiation of communication by the sensor device according to system requirements.
Many of the wireless sensor devices are powered by batteries and maximizing battery lifetime can be crucial to keep maintenance costs low. In an embodiment reducing the energy spent by the sensor device while in idle listening for incoming service requests can also be used to provide for discovery capability as described further herein. However, other sensor devices may have a power source available. For example, a sensor device may be embedded in an appliance and have power available but the sensor device still may be resource constrained and lack network capability other than through an RF link. Thus, to refer to devices generically, the term “constrained device” is used herein. Constrained device refers a device, typically a remote sensing device that is constrained in terms of various factors such as a user's ability to interact with it and has a wireless link with which to communicate. In typical situations, the constrained device is sensitive to power consumption, and has limited processing power and memory as is true of many embedded devices. The device may be constrained in terms of one or more constraints such as, available memory, processing power, available energy, user interaction capability, network bandwidth, network stability.
Radio communication is significant contributor to the total energy consumption in a wireless sensor system. Low-power, wireless networking standards, such as IEEE 802.15.4, have a goal to minimize active listening, i.e., the time a radio spends in receive mode to detect network traffic, by employing duty-cycle based schemes. This may be done by synchronizing the communicating parties to use only certain time slots, or with the help of special hardware functionality which allows a radio to detect traffic while staying in a low power mode most of the time.
Unfortunately, some implementation of IEEE 802.15.4 may not offer hardware support for low power listening. An alternative approach, described herein, conserves energy at the application level. That results in a scheme that is simple, portable across different radio platforms, and customizable for specific applications.
In an embodiment, a special reliable data transfer protocol is used between the gateway and sensor devices. This protocol runs directly on top of the operating system radio stack and ensures loss-less, in-order delivery of messages whose size is limited only by available buffer space. A long message may be split into multiple, fixed-size packets and the receiver explicitly acknowledges the first and the last packets. Remaining packets are transmitted using a NACK scheme to avoid the overhead of acknowledging every single packet.
In order to minimize the overhead of sending multiple short messages, the gateway may buffer TCP segments until a complete SSL record (or plain HTTP request) has been assembled before forwarding it. The sensor device processes the data received and either sends additional data in response (e.g., when responding to the ClientHello with a combined ServerHello, Certificate and ServerHelloDone message or when responding to an HTTP request with an HTTP response) or transmits a “ready” control message to indicate its readiness to process the next chunk of data (e.g., when waiting for the ChangeCipherSpec message after processing the ClientKeyExchange). In the former situation, data transmission from the sensor is an implicit signal to the gateway that the sensor is ready to receive the next chunk of information.
The SSL protocol offers encryption, authentication and integrity protection on top of a streaming data-transport mechanism like TCP. It allows communicating parties to choose a set of cryptographic algorithms, called a cipher suite, which determines the method of key exchange, signature verification, encryption and keyed hashing (to detect data tampering). Cipher suites that use ECC-based key exchange have been defined for SSL. While ECC support is currently not included in binary distributions, it can be enabled in the source code of the Mozilla/Firefox browsers as well as the Apache web server.
The two main components of the SSL protocol are the Handshake protocol and the Record Layer protocol. In the handshake, both parties agree on a cipher suite, authenticate each other and establish a shared secret using public-key cryptography (see
Power consumption may be a critical component of battery powered remote sensing devices. Table 1 shows measured current draw (in mA) for common operating modes of an exemplary wireless sensor device (Telos mote) at different supply voltages with the CPU operating at 8 MHz. As can be seen in Table 1, in the overall system, the radio consumes considerably more energy than the CPU, and the receive mode draws more current that the transmit mode. Since the radio must be in receive mode to listen for packets, special care should be taken to minimize idle listening in energy constrained applications.
Given that the radio consumes energy at a much higher rate than the microcontroller, it is desirable to turn off the radio whenever possible. Normal web servers are always on and ready to receive incoming TCP connection requests. If such a web server were to use a duty cycle based approach—sleeping most of the time and waking up only periodically—TCP packets delivered to the web server when it is asleep would not be acknowledged. The TCP stack on the client would incorrectly interpret packet loss as a sign of network congestion and unnecessarily throttle back its transmission rate.
The exemplary architecture shown in
In an embodiment, the wireless protocol includes a “ready-sleep” message used across the wireless link 107 in
The fact that each device periodically transmits “ready-sleep” messages, can be used by the gateway to discover the presence of active sensors in its neighborhood. Thus, after detecting a ready-sleep message from a newly installed device, the web server at the gateway updates its dynamic web page listing of currently active devices. The rate at which the web server in the wireless sensor device polls the gateway for pending service requests can be lengthened to lower average energy consumption at the expense of increasing response latency and vice versa. In an embodiment, since each poll consumes roughly 1.5 mJ of energy, 10% of the available battery capacity (typical capacity of a pair of Alkaline batteries used in one embodiment is 2.6 Ah) can power nearly one million polls. For a desired battery lifetime of 500 days, this translates to 2,000 polls per day or one poll every 45 seconds.
The embodiments described above are presented as examples and are subject to other variations in structure and implementation within the capabilities of one reasonably skilled in the art. The details provided above should be interpreted as illustrative and not as limiting. Variations and modifications of the embodiments disclosed herein, may be made based on the description set forth herein, without departing from the scope of the invention as set forth in the following claims.
This application claims the benefit of provisional application 60/715,438, filed Sep. 9, 2005, entitled “Energy Cost of SSL on Wireless Sensors”, naming Michael Wurm and Vipul Gupta as inventors, which application is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60715438 | Sep 2005 | US |
