Are we really developing complex and expensive infrastructure for foodstuffs?

Alright, admittedly that would be IoTB. Sure, I could have used tomatoes, but let’s face it, bacon is a funny word and apparently has positive connotations, judging by the fact that the meat industry uses it to describe thin slices of reformed poultry meat that has a reputation for sticking to your frying pan. But enough of my breakfast tribulations. The fact that I can’t cook turkey bacon is of little concern to today’s great minds. The fact that I may run out of the stuff is, however, enough to send a shock wave across an entire industry, causing otherwise intelligent men and women to stand up in forums of their peers waving their arms excitedly at both the prospect of this catastrophe being averted with billions of dollars of complex infrastructure and the fear for humanity if it isn’t.

If you are not following me, I’m talking about the modern-day telecom pizza problem: the milk problem. That is the too-often-repeated view (or example) that the most pressing need for IoT infrastructure is to support smart refrigerators checking on and ordering my dairy products (or their soy or nut-based alternatives), I assume to save me -- and the aforementioned humanity -- from a dry cereal disaster.

Call me a cynic (you won’t be the first), but I don’t think it is. And as someone who is actually a believer in the power of billions of connected devices, I think it takes away from the real issue at hand: the genuine IoT applications. You see, I would argue that those home appliances are not IoT “things” at all. They will continue to sit like connected gods, pulling as much power as they wish while communicating on low-loss home Wi-Fi across practically limitless broadband. That sounds a little flippant, I know -- especially the power comment -- but let’s face it, it will take a small computer to manage the Amazon Ice Box to the degree advertised. That’ll take some serious juice. And not of the orange variety.

What about “things” like thermostats? Sure, those are undoubtedly a grey area. While the appliance argument applies and can be seen in today’s smart thermostats, what if your friendly power company offers rebates in return for the ability to tweak your otherwise “dumb” thermostat settings during power crises? A broad consumer service with limited control capabilities using public wireless networks and an inherent requirement to not make your electricity meter spin off the wall. IoT? Yes, I’ll give you that. Plus it’s the perfect pivot to what perhaps constitutes real IoT.

Take a typical midsize city: 50 square miles; 50,000 or so households. Undoubtedly monopolized, that’s 50,000 meters per utility, and 150,000 meters in total. While most are likely sitting comfortably next to the home, at least one -- the water -- is out on the street, along with other “things” that can benefit from connectivity. Intelligent traffic control systems can extend the current “metallic loop’” traffic light systems from the vicinity of the intersection to entire roadways, with synchronized lights dynamically giving a little extra time to roadways with heavier traffic, or simply warning of slowdowns, accidents and obstructions. I’ll even buy in to connected cars (not the self-driving varieties) alerting motorists to potential dangers. While this is already a reality on congested freeways, extending into city roadways could mean thousands of highly concentrated, connected sensors.

Then there’s environmental application. A grid of sensors laid out across an entire state can be used for early earthquake warnings, perhaps triggering those connected utility meters to quiesce service at the home until the seismic waves have subsided. These are genuinely control-centric applications, and the industry is still determining the best protocol adaption to employ. These variants are required to support the unique (i.e., non-home-refrigerator-esque) constrained environmental demands of interconnected things -- low power draw and lossy, low-power wireless connections.

While the wagons are apparently circling around the IETF CoRE working group’s CoAP, a constrained (read: lightweight) application protocol capable of mapping to HTTP, I recently ran across an interesting paper from researchers at the University of Parma in Italy. They have been working on an IoT implementation that employs a constrained version of the session initiation protocol (SIP) -- which is where this post (finally) ties IoT to Metaswitch. Like its CoAP counterpart can relate to HTTP, CoSIP can map to classic SIP messages, enabling users to easily interface and interwork with classic control infrastructures and heavyweight endpoints.

In an interesting twist that will have those familiar with the H.323 war waged in the early 2000s burying their heads in their hands, CoSIP is a binary protocol, rather than the human-readable ASCII protocol we all know and love. As the H.323 proponents of past noted, this makes it lightweight, leading it to consume less of the once-again valuable and limited bandwidth. This is especially important in constrained environments where retransmissions are likely rampant.

When the messages that comprise a complete session are taken into account, CoSIP, with a compression ratio of nearly 50 percent, represents a viable alternative to CoAP. Moreover, IoT scenarios can leverage the benefits of SIP, such as stateful sessions, capability discovery and subscribe / notify models, which are all highly valued attributes of today's multimedia communications architectures. In short, CoSIP can enable the infrastructure intelligence required to make IoT a true managed service offering.

Although the session-based nature of CoSIP results in an increase of traffic over CoAP during connection establishments, the nature of CoAP requires options to be transmitted with every message, which quickly adds up and ultimately exceeds CoSIP bandwidth utilization when sessions are maintained for more than a few minutes. The larger CoAP packets also increase the chance of fragmentation, a potential packet-handling catastrophe with low-powered endpoints and lossy network infrastructures. However, you can always cover all bases and mitigate risk by employing both CoAP and CoSIP by way of an IoT interworking gateway, enabling native clients and applications of both flavors.

Graph showing CoSIP vs. CoAP Bandwidth Utilization over Time (Courtesy Simone Cirani, Marco Picone and Luca Veltri)

Now, kidding aside, I know we are not going to hit the oft-mentioned 50 billion connected devices without the smart washer-dryer or oven signaling the availability of toasty-warm underwear or alerting me to a my slowly drying non-constituted holiday bird, but I think we can agree that it’s probably not a priority nor the best example of IoT in action. Plus, although we are apparently full-steam ahead with CoAP, it doesn’t hurt to take a step back and look at the alternatives. You can read the complete CoSIP report at http://www.scpe.org/index.php/scpe/article/viewFile/931/393.