From my perspective, an important technical challenge in coming years might be
a variation on delay-tolerant networking. We have done a fair bit of work in
this area, for some definition of "we" - SOAP, Saratoga, and the NASA/JPL
DTNrg work. As Dave Crocker likes to point out, we actually have a canonical
DTN application and specification we all use - SMTP.
In your blog, you mentioned emergency communications. Emergency communications
are all about ensuring the ability to deliver a message end to end at a time
when the intervening network is strenuously overloaded, chaotic, or randomly
connected. The canonical examples include events like the fall of the twin
towers, where half of the US undersea cable connectivity to Europe was cut by a
falling building, hurricanes like Katrina or Sandy, or massive cyber-attacks;
more run-of-the-mill models might come in the Smart Objects domain of telemetry.
One example of a delay-tolerant network was Tsinghua's experiment in measuring
Beijing pollution. They put sensors and GPS units on taxis; every time a taxi
stopped, it asked its GPS where it was and what time it was, asked its sensors
for their data, and packaged the lot together into a reading. I think they also
asked for time in queue - when did the taxi stop, and when did it subsequently
change its position significantly. Every time the taxi passed a bus, it
synchronized with a wifi SSID on the bus, and uploaded all of its data from the
past hour or two. Every time the bus went through a central station, it
synchronized with a central reader and uploaded its cached readings to
Tsinghua. Net result - Tsinghua got a whole lot of data on taxi routes,
congested intersections, and pollution data. Individual readings were delivered
tens to hundreds of times and sorted out by the analytic process. They
developed what they described to us as a fairly sophisticated model.
I'm obviously not thinking, in this, about VoIP or Video/IP, although I could
imagine the Internet of Stuff implementing those in some way such as carrying
attachments (think HeyTell). I'm thinking more in the direction of IM or email.
The key thing is a service for containerized freight, if you will. I can think
of military applications, and a variety of telemetry applications in the
Internet of Stuff, which could include anything from meter reading to
variations on middleware-controlled communications.
In any event, I could imagine future requirements that could build on such a
model, perhaps built in JSON or XML.