According to an earlier EE Times article by Clive Maxfield, 7/7/11, the example stated for IPv6 addresses comes to mind:
"Well, as one simple example, according to calculations and estimations performed by the folks at the University of Hawaii (who obviously have far too much time on their hands), if we account for all of the beaches around the world, together they contain around 7.5 x 1018 grains of sand. Thus, the addressing space of IPv6 is sufficient to give each grain of sand its own unique IP address – and to do this for approximately 5 x 1019 Earthlike worlds – so I don’t think we’re going to run out of IPv6 addresses in the foreseeable future."
The practical data for M2M system may be much less: I did a sewage signal system last year and the real practical data is discharge volume at 12:00 am every day, and accident report, which seldom happen.
However the system send status report to the sewage treatment plan every 20-30 sec. Those data carry a lot of information about the system. i.e. the pump on vs. flow rate will be an indication of the worn and tear of the pumps, while changes of pump on time vs. discharge volume will be an indication of the pipe resistance change.
Transmitting exception data or changes has the potential to substantially reduce data transmissions as well as the need for storage at the receiving end. It also makes a lot of sense. At most, a brief signal could be sent indicating "monitoring successfully" to rule out the possibility that the sensor is off-line or failed. We've all been deluged at one time or another with floods of unnecessary data that essentially told us "no problem".
Interesting data point @ssoelberg, 1Mb is shocking low (I suspect it was low as per my post earlier but not that low)...BTW, would you be interested in presenting those findings at emerging technologies conference in Vancouver I am chairing? (www.cmoset.com), email@example.com
Colin, I’m glad to see you dig into the link between the Internet-of-Things and Big Data. However, candidly at KORE Telematics we have a slightly different take on it. It is easy to assume that trillions of sensors monitoring the status of everything will result in exabytes of data to process, but there’s actually a touch of fallacy in that assumption, in my opinion. We’ve done some fairly extensive analysis of the applications running on our dedicated M2M network and found that about 90 percent of cellular-connected M2M applications in the world today probably move less than one MB of data, collectively, in a month. Why? Because majority of actionable information to be garnered from the Internet-of-Things is “exception based” The last thing we need is to have our systems bombarded with information telling us everything is fine. When you discount for that data, the equation becomes drastically altered. We blog about it here: http://blog.koretelematics.com/2012/01/more-m2m-devices-obviously-means-more-data-to-process-right-not-so-fast.html
In existing networks a number like 12 is a practical network. Maybe they are referencing the newer 2.0 stuff that is not out yet.
The issue is routing, a device has to know about all other devices on the network. That is in conflict with Zigbee being a protocol for small, memory constrained devices.
Theory is great, but real world can be different.
@R_Colin_Johnson: the selective storage & use of data depends on the application. Elsewhere on EETimes I gave the example of Brazil Tags which monitors cars moving thru toll gates (electronic license plates, hard to follow for thieves if there is no license plate number in the car!!). It is supposed to be collecting several gigabytes of data in a day from one city alone. This can add up to terabytes in a few months and with all cities reporting, may reach many hellabytes in a couple of years!
The maximum number of nodes depends on the number of layers, children and routers in you application. The formula by which you can calculate the maximum is given in the following article, whcih gives examples iwth 861 and 55,000 nodes. The 10,000 number was just a ballpark. To calculate the maximum number in your application, see this article:
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...