BURLINGAME, Calif. Wireless sensor networks can usher in an era of ubiquitous computing if they embrace and tailor the latest Internet Protocol software stack for their ultra low power requirements, said a leading researcher in the field.
The vast majority of tomorrow's expanded Internet traffic could come from sensor nets if the devices can squeeze IP into their architectures. "We've been at this a decade, and we are about halfway there," said David Culler, a professor of computer science at UC Berkeley who helped develop TinyOS, software that helped pioneer the field.
But getting IP to work at this level is not easy because some wireless sensor nets have a budget of perhaps an hour of battery life a year, said Culler in a keynote speech at the IEEE Secon conference here Tuesday (June 17).
"You have to be asleep almost all the time, but IP networks are supposed to be always on," he said. "About 99.5 percent of the time you are off which means you have to work very, very well in the remaining half percent of time."
Engineers need to throw out ideas from wired IP nets such as making nodes remember complex routing tables and carefully acknowledging every transmission."If I have one node in a thousand-node network that comes on the net to say 'hello' and everyone acknowledges that, we are all dead," he quipped.
In the past decade researchers such as Culler experimented with new architectures such as TinyOS. They believed wired networking ideas such as having a layered software stack with an address for each node would not fit into the tiny processing and power budgets of wireless sensor nets.
"We were wrong," he said, showing a complete IPv6 stack suitable for existing sensor nodes. "It is doable with high reliability and low power," said Culler, who co-founded startup Arch Rock that is already delivering IP-based wireless sensor nets.
Culler is also co-chairman of a new effort in the Internet Engineering Task Force to define a software layer that brings IPv6 routing to sensor nets using IEEE 802.15.4 radios. The IETF effort is based on the group's existing 6LoWPAN work.
While the work on IP sensor nets goes on, many in the field are still divided over whether 802.15.4, WiFi or other networks are the best transport. They are also divided about the use of routing versus mesh networking.
"There's a huge debate in the industry on this question," said Culler, adding that new routing and mesh protocols are still emerging. "No one has figured out the right way to do meshing," he said.
Secon hosted a full-day workshop on mesh networking focused on WiFi. It included presentations from three companies shipping WiFi mesh products for a wide variety of applications from public safety to low-cost Web access.
Despite the activity, the IEEE 802.11s standard for WiFi mesh networking is far from complete after extended work. Jorjeta Jetcheva, a systems architect at mesh specialist FireTide (Los Gatos, Calif.) and a .11s participant gave several reasons for the delay including unsolved problems in wireless security and difficulty defining routing concepts in a group that is, according to its charter, prevented from discussions of that layer of the network.
An Intel researcher said WiFi meshes could open up new kinds of applications. For example, Time Warner is working with router maker FON Wireless Ltd. (Madrid) on ways to create neighborhood networks with WiFi meshes. Startups Mushroom Networks (San Diego) and WiBoost (Seattle) are also pursuing novel peer-to-peer apps using WiFi meshes.
Most of the Secon conference focused on software issues. Culler noted significant progress in flash, controllers, radios and silicon-based sensors. But he said the still-fluid nature of software for sensor nets is to some extent hampering further progress in the underlying chips.
For example, firmware abstractions RF chip vendors create to simplify programming can actually prevent programmers from optimizing acknowledgement schemes. In addition, popular TI Chipcon 2420 radios can lose their configuration data if shut off, forcing engineers to copy channel information back into the parts when they are turned back on.
"There's a lot that could be done at the lower levels, and things are not even necessarily going in the right direction today," Culler said. "The problem is the hardware designers still don't have a stable software layer as a reference to design against, and we software developers haven't helped them much," he added.