Re: [Coma] Constrained Device Classes 0, 1 and 2 and their need for Management

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jun 06, 2012 at 10:42:13AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Hi All,
> 
> following is an attempt to define the device classes in constrained
> networks a bit more in detail. The text below follows the definition of
> the three device classes provided by Carsten.
> 
> Class-0 (C0) devices are very constrained sensor-like motes. They will
> most likely not have the possibility to have a direct communications
> with the Internet in a secure manner. These class-0 devices will
> participate in Internet communications with the help of larger devices
> acting as proxy or gateways. 
> 
> Class-1 (C1) devices are assumed to have about 10 Kbytes of RAM and
> roughly 100 Kbytes of code space (e.g. Flash). For example, this could
> be an AVR Raven mote (http://www.atmel.com/tools/AVRRAVEN.aspx). Class-1
> devices can't easily talk to other Internet nodes with a full protocol
> stack using HTTP, TLS and related security protocols, and XML-based data
> representations. However, they have enough power to use a reduced or
> lightweight protocol stack (e.g. with CoAP and UDP) and participate in
> meaningful conversations without the help of a gateway node. So they can
> be integrated into the IoT network in one way or the other but need to
> spare with memory for the protocol and application usage.
> 
> Class-2 (C2) devices are embedded devices with around 50 Kbytes of RAM
> and maybe 250 Kbytes of code space and can support mostly the same
> protocol stack as used on notebooks or servers. However, even these
> devices can benefit from lightweight and energy-efficient protocols and
> producing less bandwidth on air. Furthermore, using less network
> resources would leave more resources available to applications. As such
> using the same protocol stack on Class 1 and 2 devices might be
> beneficial.
> 
> I assume we cannot do much for the management on C0 devices. They will
> be most likely preconfigured and if ever will be reconfigured seldomly
> with a very small data set.
> 
> For C1 devices it is indeed subject for discussion and to understand
> what type of applications they could run and which management mechanisms
> would be most suitable.
> Even though they have some more functionality available we need to
> assess C2 devices for the type of applications they will be running and
> the management they would need. To be able to derive the requirements we
> need to discuss the uses cases and how the devices are involved in the
> management scenario. The use cases where C1 or C2 devices build a
> cluster or are part of a hierarchy as well as the assumed degree of
> automation might be essentially important.
> 
> Comments are welcome.

This classification is very rough since devices differ in their
architecture. For example, some devices can run their software right
out of flash memory and hence their RAM is really only used for the
storage of variables and the stack. Other devices have to copy the
machine code from flash to RAM before they can execute it. Such
devices have relatively large amounts of RAM but most of it is used to
store machine code.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>