For sensor to send packet to the "gateway", 6LoWPAN, i.e. iP over IEEE802.15.4, makes sense. It saves time on building interconnected infrastructure. Once the packet reaches gateway, the packet will then be decompressed. Ultimatedly, an uncompressed IP packet will be sent to the cloud in whatever mechanism that is defined. For delay tolerant application, I highly suspect the transport layer will stay with TCP. Higher layer can be REST API or SOAP.
Bert, I agree with you here with a caveat -perhaps Uncle Sam thinks that it can replicate the success it spawned with ARPANet project leading to the modern-day Internet. Such a premise in this context is largely misguided because IoT has progressed without any government initiatives.
IoT will proliferate because of necessity and not by the 'coolness' factor.
The optimization is actually in the packet size. It is IPv6, but the addressing is shorthanded through the use of a local address table. I believe they also do message compression. The idea is to get the full networking capability of IPv6 without the larger messaging overhead.
Larry, what is the advantage in using 6LOWPAN over plain TCP/IP? I am having hard time understanding why we need a different protocol stack for IoT. TCP/IP is like English lanuage for international talk, sure you can speak some other dialect but why? Kris
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.