P2P, embedded sensors and deterministic wireless networks - Embedded.com

P2P, embedded sensors and deterministic wireless networks

You'd have to be blind and deaf not to have noticed the excitement overpeer-to-peer (P2P)networking, particularly at venues such as last week's SensorExpo. For a long time P2P was predominantly used for transferringand sharing music over the Internet in violation of licensing terms,but P2P file-sharing systems now generate a significant portion oflegitimate Internet traffic. 

Also, service providers are using P2P mobile ad hoc networks in 2.5/3Gmobile devices to allow subscribers a controlled and monitored way tocommunicate and share files device-to-device without the interventionof a server intermediary.

In embedded systems, P2P is getting a lot of attention as a means toallow servers, blade computers and telecom boards to share informationand resources. It is also being considered as a way for wirelesslyconnected MCUs and sensors to do the same. But for now, embedded P2Pusage is limited to applications where deterministic response is notimportant or where such responses can be carefully bounded andcalculated.

Soon, however, P2P connectivity will have a much greater impact onembedded computing, particularly resource-limited 8- and 16-bit devicesconnected to sensors. Direct peer-to-peer connectivity means that suchdevices will be able to talk to each other and share resources withoutthe negative impact on real-time performance and determinism that mostother server mediated and controller-area networking schemes impose.

At the recent Sensor Expo there were several presentations on usingP2P as a linking mechanism in wireless networks of sensors and MCUs.One approach described peer-to-peer clustering, which links serversaccording to their geographical or interest-based locality so thatrequests can be answered faster.

Another presentation described wireless networks of microcontrollersand sensors distributed throughout a military aircraft. These networksuse a technique reminiscent of how the Ethernet protocol was adapted tothe real-time needs of industrial networks. In this approach, thenumber of devices is limited to groups of closely linked nodes that areisolated from the broader network so response times, delivery times,noise and other issues can be carefully calculated and constrained.

Since the emergence of the IEEE1588 Precision Time Synchronization Protocol, this kind of bounded,isolated application of the Ethernet protocol is no longer necessary inthe wired industrial Ethernet market, since IEEE 1588 can be used tosynchronize clocks in networks running industrial Ethernet protocolssuch as Ethernet/IP and Ethernet Powerlink. 

As far as I know, no similar protocol has been considered forwireless control networks, and it is still uncertain whether IEEE 1588can be applied there widely. At the Sensor Expo I spotted only onepaper that described the use of 1588 in wireless control networks.Specifically, it described multiple wireless zones scattered throughouta large major aircraft using a wireless piconet developed by Boeing foruse in harsh airborne environments.

Until 1588 or some other real-time, deterministic mechanism isdeveloped, the key to peer-to-peer connectivity in embedded devices iswhat embedded developers come up with to make the ubiquitous TCP/IPprotocol do deterministic tricks.

The TransmissionControl Protocol (TCP) portion of TCP/IP provides for reliableend-to-end connectivity across one or more networks over the Internet.In order to provide reliable performance, TCP also includes otherservices such as flow control, sequencing, error checking,acknowledgements, retransmission and multiplexing.

In peer-to-peer networks on desktop and mobile devices, a serveracts as a mediator that allows one peer to access the files andresources of another. It seems to me that a true peer-to-peer (ordevice-to-device) architecture would be the key to makingconfederations of cooperating controllers and sensors a practicalreality.

If there were a way to pare down TCP/IP to its absolutely minimumfeatures, the result would be a true peer-to-peer architecture that isboth real-time and deterministic. There are a lot of proprietaryschemes that have focused on exactly that.

Most of these schemes assume that if the devices are operating in arelatively closed environment in a single network rather than acrossthe Internet, it's not necessary to use an IP scheme based on a 32-bitaddress space that permits about four billion unique addresses. Nor isit necessary to carry the overhead to ensure delivery of packets. Thuspared down, such a configuration would be appropriate for mostconfederations of microcontrollers as long as all they need is softreal-time response.

For more than that, it is often necessary to go even further andreplace the TCP half of the TCP/IP stack. TCP was designed to operatein an asynchronous environment. It ensures reliable connections byexchanging data in a time-consuming three-way handshake. Thus, itsability to operate deterministically is severely limited.

What about going to that often-ignored stack in the protocol suite,the userdatagram protocol (UDP)? It is connectionless, but was designed forenvironments where there are already reliable links or in closedenvironment where a reliable link is a given. Because it eliminates theentire asynchronous handshaking overhead, deterministic sharing betweendevices should be achievable.

The downside is that it eliminates one of the main advantages ofTCP/IP: a global peer-to-peer mechanism that is entirely independent ofthe underlying physical transport layer.

Perhaps the solution is to implement the entire IP Suite of servicesinto hardware. This would allow it to be implemented for deterministicpeer-to-peer operation among cooperating devices locally, but still beavailable to connection on a global basis. Similar TCP/IPOffload Engines (TOEs) are regularly used to reduce the mainnetwork processor load in routers and switches.

The key, however, will be cost. Can the entire TCP/IP stack beimplemented in silicon at a price (in terms of both currency and diearea) that would make it attractive in the 8-, 16- and 32-bitmicrocontroller world?

And if so, is it worth the effort it will take to get there? Givenwhat I have been reading about plans of the Department of Defense forextensive use of sensors in its Global InformationGrid (GIG)

Bernard Cole is the site editor for Embedded.com and site leaderat  iApplianceweb. He welcomes contact. You can reach himat or 602-288-7257.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.