As more smart objects, such as sensors and actuators, are connected to the Internet, the devices—which have less energy, memory, and bandwidth capacity than typical hosts—will require a new approach to protocol development and Internet architecture design.
This was the topic of the Internet Architecture Board’s (IAB’s) technical plenary session, entitled “Interconnecting Smart Objects with the Internet,” held in Taipei, Taiwan, on 14 November 2011.
Smart objects are very small devices being deployed in very large numbers on the Internet, explained Hannes Tschofenig, a standards specialist with Nokia Seimens Networks, who kicked off the discussion.
“From a network aspect, these devices typically have constraints in terms of energy consumption, a small amount of bandwidth, and a limited amount of memory,” Tschofenig said.
Jari Arkko, an IETF Internet area director and a network engineer with Ericsson, gave an overview of the IAB’s Smart Objects Workshop, which was held in Prague in March 2011. The workshop, which attracted around 100 participants, covered a variety of applications of smart objects, such as networks in buildings, fountains, and theaters.
One key difference in these applications is that smart objects are sleeping nodes, rather than always-on devices. Smart objects also require deployable security and benefit from routed-over instead of mesh-under networking, Arkko said.
Several IETF working groups (WGs)—Routing Over Low Power and Lossy Networks (ROLL), IPv6 over Low Power WPAN (6LoWPAN), and Constrained Restful Environments (CORE)—are addressing the networking needs of smart objects. In addition, the IETF has formed the Light-Weight Implementation Guidance (LWIG) WG and is tackling related problems in Home Networking (HOMENET). According to Arkko, additional work is needed in such areas as architectural guidelines, cryptography and data models for smart objects.
“It’s clear there are many challenges here,” Arkko said. “One that we care quite a bit about is using IP to begin with versus legacy protocols. The answer for everyone in this room is a no-brainer and should be for others on the planet.”
Arkko said that despite the goal of “One Internet For All,” smart objects create many complications such as the need for dedicated networks, special link layers, protocol stack profiles, and security concerns. He said it is unclear whether smart objects can use IP as it is, or if IP will need to be modified.
“Workshop participants came to the conclusion that we should build for the case where everything is on one network, and allow people to deploy differently than we do today,” Arkko said. “The IETF also should build middleware and work to create application standards.”
Arkko said the biggest challenge of smart objects is that they are sleeping nodes, and many IETF protocols were not designed for this scenario. One IETF protocol that might work for smart objects is Constrained Application Protocol (CoAP), which is a light-weight version of HTTP. However, Arkko said even CoAP needs some adjustments for smart objects, as do crypto protocols.
“We don’t need to wait for the future Internet to do the Internet of Things because the Internet of Things is already here,” Arkko said. “A lot of technology—IP itself, IPv6—is usable today.”
Carsten Bormann, cochair of 6LoWPAN and CORE, said today’s Internet protocols use too much energy, spectrum, and memory to be applicable to smart objects. He pointed out that energy-constrained nodes are not only in sleeping mode but also have little ROM (random operating memory) space for code and little RAM (read-only memory) space for memory. Additionally, smart objects are typically linked via power-constrained networks with higher loss rates and less reliability than Ethernet.
“This is a set of problems that requires new engineering,” Bormann said, warning that Moore’s law of how chip performance doubles every two years will not fix these problems. “Moore’s law doesn’t give you much benefit in constrained nodes and networks.”
Bormann identified two issues with today’s Internet protocols that make it difficult for them to be used with smart objects. The first he dubbed garrulity, which refers to the talkative nature of these protocols. The other he called fluff, which refers to the inclusion of unnecessary features. He urged IETF participants to create less complex protocols that would be more suitable to energy-constrained devices.
“Please recalibrate your complexity meters,” Bormann urged, pointing out that constrained devices have as little as 100 kilobytes for all of their code, including security, networking configuration, and application code. He said smart objects have so little power that they can’t send excess packets, nor can they be turned on for listening mode.
Bormann said some IETF protocols can be streamlined for use with smart objects, which is the goal of 6LoWPAN. Another possibility is for the IETF to streamline Multicast and the Datagram Transport Layer Security (DTLS) protocol while continuing to develop CoAP.
“The protocols you design today, you may want to think about using those protocols in more constrained environments,” Bormann said. “They may not just run on big iron, laptops or phones. Think about what you can do to make the protocol talk less and require listening less and get rid of fluff that you don’t really need.”
Fred Baker, a former IETF chair and Cisco fellow, gave an overview of RFC 6272, which he wrote to identify Internet protocols that can be used in smart grid applications for the electricity industry. Baker said the automotive industry has similar requirements for vehicle-based communications systems and the health care industry for biological sensors. The smart objects in these applications will run on private IP-based networks rather than the public Internet, he explained.
“They do not intend to use the Internet as we understand it,” Baker said. “But they do plan to use IP and some of the related protocols.”
Robert Assimiti, director of Technology and Standards at Nivis, said the process-automation industry needs interoperable and secure connectivity among smart objects in a manner that is agnostic to the application and link layer. He said that industrial users are interested in IPv6 because of its vast address space and standards compliance.
Assimiti pointed out that there are many challenges in industrial process-automation networks, including the need for centralised design, connectivity to hundreds of devices, and extremely high reliability. Those networks also have strict guaranteed latencies, use the push-model for data collection, and have devices with long battery life.
Assimiti said three competing standards have emerged for smart objects in process automation, but only one—the International Society of Automation (ISA) 100.11a—uses IETF protocols, including IPv6, UDP, and 6LoWPAN.
“All of the other standards have tailored technology to meet their particular requirements,” Assimiti said. “The biggest threat is us ending up with completely disparate networks that do not interoperate at any level…What is the holy grail is that we require no translation gateways and no middleboxes, and that networking and security are interoperable and independent of the application and link layer.”
The final speaker at the IAB technical plenary was Zach Shelby, an active participant in 6LoWPAN and CORE and an engineer with Sensinode, who discussed the challenges of integrating smart objects with Web services. This integration would allow machine-to-machine applications such as security monitoring, energy management, facility management, and asset management.
Shelby said the IETF should enable the “Web of Things” by creating protocols that serve as building blocks for application developers. In particular, he mentioned Sensor Markup Language (SenML) as a generic data format and the Web Linking framework. He said the IETF needs to do a better job of creating an optimised security toolbox.
“We need to work on identity, discovery, directories, and search,” Shelby said. “I think Web Linking is a good start, but there is a lot more work that needs to be done.”
Other remaining challenges to creating the “Web of Things” include the use of DNS (domain name system) versus search for resource lookup as well as the issue of whether those systems should be centralized or distributed. “The IETF needs to give better advice and sound building blocks to software developers,” Shelby concluded.