Subject: [core] Sleepy devices + observer model

From: "Berta Carballido" <[email-masked]>
Date: Mon, 2 Apr 2012 12:49:15 +0100

Hello all,

Just to add some more information on my comment last Friday where I
mentioned that observe model works for sleepy sensors (as requested by
Mr. Bormann).

1.       First of all, remind that the MAC layer or radio can store
packets waiting to be sent. Some radios for instance can store ten
packets, others one, etc. MAC layer buffer size depends on
implementation.  

Since internet stack is memory consuming I would expect to have type 1
type 2 device with enough memory to store several packets (but at least
there will be always space for one).  Also take into account the
tradeoff cost of proxy device vs. cost of radio with large buffer. 

2.       Second of all, there are some MAC protocols that synchronize in
time (TDMA based) and some others that can be asynchronous (i.e. CSMA
based). In any case, they will always figure out when they must transmit
to reach a neighbour.

Thus, if a device "a" wants to subscribe (observe) to a device "b" that
is sleeping. The device "a" APP layer will generate a request packet
that will go down the stack till the buffer. Then the "a" MAC will wait
until "b" radio wakes up and then deliver the packet to "b". "b" will
read the packet, process the request and act accordingly. Thus the
observe model works for sleeping devices even if a request has to go
through several intermediary sleeping nodes.

One could wonder how to establish the timeout value in such cases where
sleeping devices have to be traversed.  One way of doing it can be using
cross-layer info, a possible example using a CSMA like MAC could be
(note that I just invented this example, it may be missing something):
Timeout= 2 * RPL_hop_count_metric  * IEEE802.15.4_duty_cycle *
Probability_rtx * Mean_time_gain_access [note that it is a common
practise in the WSN domain to use cross-layer info to optimise
protocol/algorithm performance].

Moreover, if a proxy is required in the vicinity of every sleeping
device (and think here about proxy monetary costs as well), only star
like topologies make sense (with a proxy backbone possibly using a
different phy layer).  For instance, in the scheme below the sleepy
device "a" is connected in a star like fashion to the proxy "pa" (same
for "b" and "pb").  And the proxies communicate directly (or multihop)
to each other and to the border router ("br") .

a -- pa -- br -- pb -- b

If this scheme of sleepy star-leafs plus proxy backbone is not used,
whenever a node wants to perform a request, it will have to traverse
sleeping devices to reach a proxy, where delays will be introduced. For
instance, in the diagram below "a" would have to traverse the sleeping
device "s" to reach the proxy "pb" of "b". Thus, if proxies are used to
facilitate fast access to information, multihop topologies of sleeping
devices with proxies in between do not make sense. 

a -- s -- pb -- b 

However, one of the advantages of battery powered sensors is their
freedom of placement! Imagine a vineyard where you want to monitor the
soil humidity, would it make sense to have a line powered proxy every
"x" meters, or would it make more sense to have a multihop topology of
sleeping devices?

Thus my conclusions are:

a)      Server and observer models are appropriate for sleeping devices 

b)      A proxy may be useful for some applications (for instance when
the sleeping device wants to remain always sleeping unless some event
that needs to be reported happens)

c)       Proxies make sense only for star-like/star backbone topologies

Regards,

Berta.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 4 Apr 2012 09:15:12 +0200

Using only L2 techniques, with a multihop network, what is the minumum
duty cycle you can achieve? 1%? 0.1%?

I think that the focus here is about duty cycling <<0.1%, these
optimization will be for sure paired with L2 RDC techniques as well.

I share your opinion of avoiding proxies, as much as possible, for
this reason our take on the topic is by using an Alive message between
the endpoints.

You can find it here:
http://tools.ietf.org/html/draft-castellani-core-alive

Best,
Angelo

On Mon, Apr 2, 2012 at 13:49, Berta Carballido <[email-masked]> wrote:
> mentioned that observe model works for sleepy sensors (as requested by Mr.
> Bormann).
>
> 1.       First of all, remind that the MAC layer or radio can store packets
> waiting to be sent. Some radios for instance can store ten packets, others
> one, etc. MAC layer buffer size depends on implementation.
>
> Since internet stack is memory consuming I would expect to have type 1 type
> 2 device with enough memory to store several packets (but at least there
> will be always space for one).  Also take into account the tradeoff cost of
> proxy device vs. cost of radio with large buffer.
>
> based). In any case, they will always figure out when they must transmit to
> reach a neighbour.
>
> Thus, if a device “a” wants to subscribe (observe) to a device “b” that is
> sleeping. The device “a” APP layer will generate a request packet that will
> go down the stack till the buffer. Then the “a” MAC will wait until “b”
> radio wakes up and then deliver the packet to “b”. “b” will read the packet,
> process the request and act accordingly. Thus the observe model works for
> sleeping devices even if a request has to go through several intermediary
> sleeping nodes.
>
> cross-layer info, a possible example using a CSMA like MAC could be (note
> that I just invented this example, it may be missing something): Timeout= 2
> * RPL_hop_count_metric  * IEEE802.15.4_duty_cycle * Probability_rtx *
> Mean_time_gain_access [note that it is a common practise in the WSN domain
> to use cross-layer info to optimise protocol/algorithm performance].
>
> Moreover, if a proxy is required in the vicinity of every sleeping device
> (and think here about proxy monetary costs as well), only star like
> topologies make sense (with a proxy backbone possibly using a different phy
> layer).  For instance, in the scheme below the sleepy device “a” is
> connected in a star like fashion to the proxy “pa” (same for “b” and “pb”).
> And the proxies communicate directly (or multihop) to each other and to the
> border router (“br”) .
>
> a -- pa -- br -- pb -- b
>
> instance, in the diagram below “a” would have to traverse the sleeping
> device “s” to reach the proxy “pb” of “b”. Thus, if proxies are used to
> However, one of the advantages of battery powered sensors is their freedom
> of placement! Imagine a vineyard where you want to monitor the soil
> humidity, would it make sense to have a line powered proxy every “x” meters,
> or would it make more sense to have a multihop topology of sleeping devices?
>
> Thus my conclusions are:
>
> b)      A proxy may be useful for some applications (for instance when the
> sleeping device wants to remain always sleeping unless some event that needs
> to be reported happens)
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: [email-masked]
Date: Wed, 4 Apr 2012 10:20:36 +0200

Hi Angelo,

Few comments inline.

>optimization will be for sure paired with L2 RDC techniques as well.

Agreed

>this reason our take on the topic is by using an Alive message between

Without a cache intermediary you will probably suffer from high latency.

> http://tools.ietf.org/html/draft-castellani-core-alive

Why do you need something at the message layer when Carsten's proposition 
can trigger an "I'm alive" indication with a simple POST request?

Best regards,
Matthieu

---

From: "Berta Carballido" <[email-masked]>
Date: Wed, 4 Apr 2012 09:21:21 +0100

Dear Angelo,

There is no limit per se on the duty cycle. This can depend for instance on your offered load (i.e. if many events need to be reported the radio needs to be awake for longer and vice versa). [Also, as a remark with regards to hardware & small duty cycles, some existing implementations of IEEE 802.15.4 experience loss of synchronisation due to clock drifts when having small duty cycles (see 3.2.2. in http://www2.tkn.tu-berlin.de/publications/papers/TKN154.pdf)]

Regards,
Berta.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Angelo P. Castellani
Sent: 04 April 2012 08:15
To: Berta Carballido
Cc: [email-masked]
Subject: Re: [core] Sleepy devices + observer model

Using only L2 techniques, with a multihop network, what is the minumum duty cycle you can achieve? 1%? 0.1%?

I think that the focus here is about duty cycling <<0.1%, these optimization will be for sure paired with L2 RDC techniques as well.

I share your opinion of avoiding proxies, as much as possible, for this reason our take on the topic is by using an Alive message between the endpoints.

You can find it here:

Best,
Angelo

On Mon, Apr 2, 2012 at 13:49, Berta Carballido <[email-masked]> wrote:
> packets, others one, etc. MAC layer buffer size depends on implementation.
>
> type
> 2 device with enough memory to store several packets (but at least 
> 2.       Second of all, there are some MAC protocols that synchronize 
> in time (TDMA based) and some others that can be asynchronous (i.e. 
> CSMA based). In any case, they will always figure out when they must 
> transmit to reach a neighbour.
>
> Thus, if a device “a” wants to subscribe (observe) to a device “b” 
> that is sleeping. The device “a” APP layer will generate a request 
> packet that will go down the stack till the buffer. Then the “a” MAC will wait until “b”
> radio wakes up and then deliver the packet to “b”. “b” will read the 
> packet, process the request and act accordingly. Thus the observe 
> model works for sleeping devices even if a request has to go through 
> several intermediary sleeping nodes.
>
> One could wonder how to establish the timeout value in such cases 
> where sleeping devices have to be traversed.  One way of doing it can 
> be using cross-layer info, a possible example using a CSMA like MAC 
> could be (note that I just invented this example, it may be missing 
> something): Timeout= 2
> Mean_time_gain_access [note that it is a common practise in the WSN 
> domain to use cross-layer info to optimise protocol/algorithm performance].
>
> device “a” is connected in a star like fashion to the proxy “pa” (same for “b” and “pb”).
> And the proxies communicate directly (or multihop) to each other and 
> to the border router (“br”) .
>
> a -- pa -- br -- pb -- b
>
> sleeping devices to reach a proxy, where delays will be introduced. 
> For instance, in the diagram below “a” would have to traverse the 
> sleeping device “s” to reach the proxy “pb” of “b”. Thus, if proxies 
> are used to facilitate fast access to information, multihop topologies 
> of sleeping devices with proxies in between do not make sense.
>
> a -- s -- pb -- b
>
> “x” meters, or would it make more sense to have a multihop topology of sleeping devices?
>
> Thus my conclusions are:
>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 4 Apr 2012 10:27:02 +0200

Yes but both CSMA and TDMA have real limitations when your duty
cycling goes lower some threshold.

Imagine some CSMA based technique where the node is awake 20ms every
5-15 minutes. Do you think that this can work?

I think that the whole thing is not usable at application layer, even
in single-hop topology... Multihop would be even harder.

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 4 Apr 2012 10:35:45 +0200

> Without a cache intermediary you will probably suffer from high latency.

The requirement for an intermediary to enable sleepy sensors to work
it is quite tight I think.

The proxy is not a simple entity, it requires at least a class-2
device but probably something more. Don't you think?

Do we want to enable sleepy sensors only when that intermediary is available?

> can trigger an "I'm alive" indication with a simple POST request?

Of course at application layer you can get this done with some ad-hoc
application pattern, but I think that for the sake of interperability
this should be done in a standard way.

Moreover in Carsten's example, you need 1 mid-sized by the sleepy node
and 1 tiny message from each interested listener, then 1 message for
each interested listener (imagine problems when multicast is
involved).

Using CoAP Alive, the ALV message is a very tiny one, and thanks to
its special, standard semantics it is an useful and optimizated for
the common case of a node that wakes up. You need only the ALV
message, the "magic" that Carsten was thinking about in its slides is
worked out by the alive message. :)

Best,
Angelo

---

From: "Berta Carballido" <[email-masked]>
Date: Wed, 4 Apr 2012 09:55:17 +0100

Hello,

"Yes but both CSMA and TDMA have real limitations when your duty cycling goes lower some threshold."

When the sleep time goes above some threshold there can be problems with the hardware yes, it is not a problem of the MAC protocol (note that you can have a small duty cycle even if you do not sleep long)

"Imagine some CSMA based technique where the node is awake 20ms every
5-15 minutes. Do you think that this can work?

I think that the whole thing is not usable at application layer, even in single-hop topology... Multihop would be even harder."

Sorry if this was mentioned before, I cannot find this information ... What kind of applications are being considered? Why are you considering an artificial limit of <<0.1%? Is this the requirement of some specific application or the requirement of the installer? Because some may say that a duty cycle of <<0.1% is required to expand lifetime of devices, but then an application may need to transmit packets more often that what is established by that limit...

Regards,
Berta.

On Wed, Apr 4, 2012 at 10:21, Berta Carballido <[email-masked]> wrote:
> Dear Angelo,
>
> There is no limit per se on the duty cycle. This can depend for 
> instance on your offered load (i.e. if many events need to be reported 
> the radio needs to be awake for longer and vice versa). [Also, as a 
> remark with regards to hardware & small duty cycles, some existing 
> implementations of IEEE 802.15.4 experience loss of synchronisation 
> due to clock drifts when having small duty cycles (see 3.2.2. in 
> http://www2.tkn.tu-berlin.de/publications/papers/TKN154.pdf)]
>
> Regards,
> Berta.
>
>> are used to facilitate fast access to information, multihop 
>> topologies of sleeping devices with proxies in between do not make sense.
>>
>> a -- s -- pb -- b
>>
>> freedom of placement! Imagine a vineyard where you want to monitor 
>> the soil humidity, would it make sense to have a line powered proxy 
>> every “x” meters, or would it make more sense to have a multihop topology of sleeping devices?
>>
>> Thus my conclusions are:
>>
>> b)      A proxy may be useful for some applications (for instance 
>> when the sleeping device wants to remain always sleeping unless some 
>> event that needs to be reported happens)
>>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 4 Apr 2012 11:05:28 +0200

> Sorry if this was mentioned before, I cannot find this information ... What kind of applications are being considered? Why are you considering an artificial limit of <<0.1%? Is this the requirement…

For example, enviromental monitoring traffic may live well with those
duty cycles.

Best,
Angelo

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 4 Apr 2012 13:28:23 +0200

> For example, enviromental monitoring traffic may live well with those

Another example: something which is wirelessly controlled by a self-powered switch.

This kind of switches generate their own operational energy by means of harvesting – e.g. electro-mechanically through the user action of pressing or releasing the button. 

Hence they can access the radio link only for a very short time span, with *non predictable* timing.  Hence the Publish option :-)

---

From: Mirko Rossini <[email-masked]>
Date: Wed, 4 Apr 2012 15:11:39 +0200

2012/4/4 Thomas Fossati <[email-masked]>

> >> Sorry if this was mentioned before, I cannot find this information ...
> What kind of applications are being considered?
> This kind of switches generate their own operational energy by means of
> harvesting – e.g. electro-mechanically through the user action of pressing
> or releasing the button.
>
> Hence they can access the radio link only for a very short time span, with
> *non predictable* timing.  Hence the Publish option :-)
>

This is also the case of M2M only interactions, e.g. a sensor that
activates its radio only when it changes state and/or reaches a trigger
value.

---

From: [email-masked]
Date: Wed, 4 Apr 2012 17:14:49 +0200

Angelo,

see my comments

>this should be done in a standard way.

IMO it's easier to standardize a Function Set in a profile than a 
low-level message type in an already full header field.

>each interested listener (imagine problems when multicast is

For me the number of messages is the same. 

C1  C2  C3    S
   |   |   |     . server is sleeping
   |   |   |     .
   |   |   |     .
   |   |   |     .
   |   |   |     . server wakes up
   |   |   |     . NON
   |<--|<--|<----| POST coap://[ff02::1]/alive
   |   |   |     |
   |   |   |     | CON MID=0x1234
   |------------>| GET /a
   |   |   |     |
   |   |   |     | ACK MID=0x1234
   |<------------| 2.05 "A"
   |   |   |     .
   |   |   |     . server goes sleeping again
   |   |   |     .
   |   |   |     .
   |   |   |     .

>the common case of a node that wakes up.

Does this working group really want to override the NON message type 
semantics when we can do the same with a simple CoAP request?
I'm personally not in favor of adding new message types.

>You need only the ALV

The magic is about reusing the token from the POST in the observe 
relationship, thus avoiding the initial GET request to create the 
subscription.
We just need a short explanatory text, nothing more.
In your draft, the example is still using an explicit observe subscription 
so no magic here.

Best regards,
Matthieu

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 4 Apr 2012 17:32:38 +0200

>   |<--|<--|<----| POST coap://[ff02::1]/alive

Do you want to reserve the "alive" URI-Path Option value to provide
this semantics?

> semantics when we can do the same with a simple CoAP request?

You don't override the NON message type, an empty NON simply does not
exist. (you can find it by looking at the coap-09 spec, in the section
where NON is specified).

> In your draft, the example is still using an explicit observe subscription

It's not explanatory text, the ALV message solicits the message-layer
to send messages to a particular peer which is currently available.

This feature belongs to the message-layer itself, that could queue
messages for a sleeping peer as long as an ALV is received.

If you want to recreate this function by reserving a special resource
name, you have two problems:
1. the request to the "alive" resource is bigger, as it needs the
URI-Path option.
2. the request to the "alive" resource needs to go up to this resource
(if available), and this resource will do a cross-layer solicit to
messages queued for that destination (the message-layer itself does
not have access to the request/response layer). this is not efficient,
neither quick...

An empty NON message should be already ignored by every
implementation, so if you don't support this feature you don't need
any exception to handle ignoring messages to the "alive" resource.

Moreover I don't think that reserving namespace for low-level
communication features is a clean design, anyway I don't know whether
this resides in design practice or design taste.

Best,
Angelo

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 4 Apr 2012 18:56:40 +0200

On 4/2/12 1:49 PM, Berta Carballido wrote:
> a)Server and observer models are appropriate for sleeping devices
>
> b)A proxy may be useful for some applications (for instance when the 
> sleeping device wants to remain always sleeping unless some event that 
> needs to be reported happens)
>
> c)Proxies make sense only for star-like/star backbone topologies
>

Hi Berta,

while I agree with you that a proxy solution make sense only for some 
applications/scenarios
I fully disagree that the Observer models, at least as it is specified 
at moment with all its limitations, is appropriate for sleeping devices.

I like you precise analysis, however you have forgotten that in CoAP we 
are in a Restful architecture
where the Name, Name authority and Name Integrity etc etc. is the core.

So how would you respect the name integrity (of a resource) in your 
scenario (and especially in a multihop scenario
where only adjacent nodes can talk each other) ?

cheers
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Robert Cragie <[email-masked]>
Date: Wed, 04 Apr 2012 18:40:23 +0100

+1

I am really not in favour of adding more message types to assist 
esoteric transaction patterns. As Matthieu demonstrates, these can 
easily be handled by alternative means.

Robert

---

From: Zach Shelby <[email-masked]>
Date: Wed, 4 Apr 2012 22:00:15 +0300

On Apr 4, 2012, at 8:40 PM, Robert Cragie wrote:

> +1
> 
> I am really not in favour of adding more message types to assist esoteric transaction patterns. As Matthieu demonstrates, these can easily be handled by alternative means.

+1 

I am also not convinced of a need for new CoAP level mechanisms for sleepy (the non-reachable sort) end-points. There are surely many ways we can leverage the notification capability that Observe provides, and for extreme cases you can always use a client mode where there are many possible models, the one Matthieu is proposing with a Mirror Server being just one of them. We really need to explore the low-hanging fruit before designing new mechanisms into CoAP which is a big step (and the bar should be high).

This whole sleepy node conversation is totally unfocused as well. It seems like each person is talking about different requirements, goals and architecture. I do agree that the case of a totally non-reachable end-point (sleepy of for whatever other reason) would be useful to solve, I think the people who are interested in this work need to get together and:

1. Nail down the problem you are trying to solve, keep it simple to start with
2. First explore how you can use Observe or a client mode and REST to solve it 
3. Get some practical experience with those solutions, iterate
4. If all else fails, then start talking about new options etc. 

Please also keep in mind that we are operating at the application layer, but enabling battery powered wireless nodes in real systems is a complex system issue. As we already saw from this discussion there are issues at almost every layer, from MAC timing, to routing and ND as well as the system architecture and data flows. Whatever we do here needs to work in a pretty wide range of such systems, but don't expect to solve the whole problem in CoRE. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Antonio Jara <[email-masked]>
Date: Wed, 4 Apr 2012 21:11:36 +0200

Dear Zach, Berta, Salvatore, and all,

+1

It is clear that a multi-hop architecture with multiple several
sleeping nodes for this kind of active protocols require a high
synchronization or some active router nodes in order to make this
multi-hop more reachable.

I prefer always to consider from the 6LoWPAN (network layer) and CoAP
(application layer) point of view a star topology, where the
coordinator is integrated in the Border Router and several end-node
(which are able to sleep) are connected directly to this one.

Such as aforementioned, it cannot be so restricted star, we could
consider some multi-hop but the intermediary nodes should be router
with no-sleep mode enabled or a duty cycle higher (i.e. a full one),
or in a most common case, just assume that RPL is able to manage it in
the link layer in order to make it transparent for us in the network
layer.

Anyway, regarding solutions, we are considering to include in the next
draft of conditional observe "draft-li-core-conditional-observe-01"
some additional attributes and types of conditions for the sleeping
node, where it is considered the following options:

1- Indication in the replies of an attribute to inform about the "duty
cycle" from a sleep nodes, in order to inform to the client about the
maximum delay to discover changes, or rate for a periodic observer.

2- In the queries send to sensors connected to sleeping nodes, if can
be considered the indication of a flag in order to allow cacheable
values replies, i.e. a Live flag in order to distinguish between "live
or cacheable value".

Thereby, proxies or mirrors are able to know if they should reply with
a cached value in a non-authority way or they should wait to the
reception of a new reply (fresh value) from the sensor.

3- Finally, regarding to the maximum wait for this answer, it can be
also considered in the replies from the proxy on.behalf of the end
node in a non-authority way, also to indicate in this live flag as a
freshness indicator, which is activate when the maximum TTL for the
request in a "periodic observation" or with maximum time between
replies has been expired.

In definitive, we would like to get some feedback about the opinion of
these new options for the sleeping node type for the next draft of the
conditional observe.

In summary, which options you consider more relevant:

1- be more explicit about the duty cycle in the replies for the
registration/observation over a sleeping nodes-

2- be more explicit about the requirement of live values for periodic
observations in the queries from the clients.

3- use this live flag  in order to be managed for these mirrors /
proxies, maybe too much processing for these mirrors?

4- Indicate with a freshness attribute that the reply is
non-authoritative from a proxy/mirror in case that this detects that
the maximum period between observations parameter has expired and not
reply has been carried from the sleeping node due to its low duty
cycle etc...

Best regards and thanks,
Antonio J. Jara

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 5 Apr 2012 10:07:36 +0000

Dear working group,

I am in favor of the star topology as suggested below.
Although I like the vineyard example, I know of my friends in the potato fields that they use 868MHz with a much larger range than 2.4 GHz.
They also use star topology without using IP.

The multi-hop protocol may well be a completely different protocol from the protocols and use cases that most people think of in connection to sleep(y)(ing) nodes.
The multi-hop may need clock synchronization and a completely different infrastructure than we consider here.

Concerning the options.
I think the suggestions are valid, but I prefer not to include them in the protocol.
Another approach is to use resources with predefined names informing the client after discovery of the protocol attributes.
Using resources makes the protocol less sensitive to additional wishes in the future.
During initialization an entry can be stored in "for example" the managing star where all resource values are available for use by destinations (observers of the sleeping node).

Greetings,

Peter van der Stok

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Antonio Jara
Sent: Wednesday 4 April 2012 21:12
To: Zach Shelby
Cc: [email-masked]
Subject: Re: [core] Sleepy devices + observer model

+1

Best regards and thanks,
Antonio J. Jara

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: [email-masked]
Date: Thu, 5 Apr 2012 14:50:09 +0200

Hi all,

>4. If all else fails, then start talking about new options etc. 

Seems reasonable to me. Do we agree on that?

Besst regards,
Matthieu

---

From: Robert Cragie <[email-masked]>
Date: Fri, 06 Apr 2012 19:39:43 +0100

Sounds good to me. I think one approach is to consider appropriate 
design patterns for these. Also, with regard to REST, the assumption 
seems to be this is one resource. I would say it is a collaboration of 
distinct resources with some functional logic binding them.

For example, consider the sleepy sensor which sends a value 
periodically. One way to look at this is the sleepy device contains a 
resource which is updated internally every time the device wakes. This 
update causes a POST to be sent to another server (the mirror server). 
This POST creates a new instance of a reading in the mirror server. 
However, the subsequent processing could take many forms. For example, 
it could:

1. Overwrite the current value and send a notify to an observing client
2. Overwrite the current value. The client can use etags to determine if 
it has been updated
3. Add to a FIFO queue (a la AtomPub) and send a notify to an observing 
client
4. Add to a FIFO queue. A client will do a subsequent fetch

...and so on.

In essence, I believe these design pattern need to be developed 
independently of the CoAP protocol. Many examples of such design 
patterns exist in the HTTP world, e.g. AtomPub, ZeroMQ, RestMS etc.

Robert

---

From: [email-masked]
Date: Tue, 10 Apr 2012 10:09:33 +0200

Hi Robert,

>patterns exist in the HTTP world, e.g. AtomPub, ZeroMQ, RestMS etc.

So in your opinion the mirror server specification should leave more 
flexibility on how to handle data updates.
In other words there can't be a generic mirror server function.
We can specify registration,update,removal interfaces for a mirror entry 
and mirrored resources but that's all.
The way the mirror server handle a POST request on a mirrored resources is 
left to the mirror server implementation.

For a given deployment we probably need homogeneity in mirror server 
implementations so this behavior could be part of some profile 
specification.
You ask for flexibility between the mirror server and the client but we 
may also want more flexibility between the sleepy and the mirror server.
For example CoAP doesn't provide a way to act upon multiple resources in a 
single request. However we can do this with the core batch interface. But 
it requires the mirror server to understand SenML and the batch interface. 
It's probably better to require core interfaces support in an application 
profile than in the base mirror server spec. An environment sensor (temp, 
hum, co2, light) can make huge benefit of core batch and resource 
multiplexing for energy efficiency.

Matthieu

---

From: "Stok, Peter van der" <[email-masked]>
Date: Tue, 10 Apr 2012 09:05:39 +0000

Hi Matthieu,

I agree with the suggestion by Robert to leave the design patterns outside coap protocol.
I don't know about generic mirror servers, but I could imagine that you define the interfaces between sleepy and mirror and between client and mirror.
The conversions between input and output values are left open and a basic copy/overwrite function is specified as example and minimum implementation.
Your text below remains a bit ambiguous to me
>"For example CoAP doesn't provide a way to act upon multiple resources in a
>multiplexing for energy efficiency."

What is the suggestion? To declare batch as part of coap and specify it for the mirror, or to leave batch outside coap.
I would suggest to delegate the use of batch to the profile specification of the profile standard.

Greetings,

peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday 10 April 2012 10:10
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [core] Sleepy devices + observer model

Hi Robert,

Matthieu

---

From: [email-masked]
Date: Tue, 10 Apr 2012 11:33:06 +0200

Hi Peter

> What is the suggestion? To declare batch as part of coap and specify it 
for the mirror, or to leave batch outside coap.

core-interfaces will never be included in the base CoAP spec but might be 
a CoRE working group just like mirror server or any other mirroring 
propositions. These drafts would be just tools that can be combined to 
build a constrained RESTful environment. The question is do we want to 
have core-interfaces support mandatory for a mirror server implementation 
or do we want to leave this decision to a profile. The same question 
applies for all the messaging/queuing patterns we can imagine between a 
mirror server and clients.

>I would suggest to delegate the use of batch to the profile specification 
of the profile standard.

I agree core-interfaces is just an optional tool.

Matthieu

---

From: Robert Cragie <[email-masked]>
Date: Tue, 10 Apr 2012 12:38:32 +0100

Hi Matthieu,

Comments inline. The main point I wanted to make earlier in this thread 
was that the basic CoAP protocol need not be extended and that it can be 
used to represent common function sets as is and I think we are in 
agreement there.

Robert

> left to the mirror server implementation.
<RCC>I think there are a number of applicable design patterns, which 
having things in common and things which are different, i.e. classical 
object-oriented design.</RCC>
> implementations so this behavior could be part of some profile
<RCC>I agree and I think profile specifications are the best place to 
put it. It strikes me doing this through layers of abstraction of 
profiles could simplify the development of specific application 
profiles.</RCC>
> may also want more flexibility between the sleepy and the mirror server.
<RCC>Absolutely; I was only using the client/mirror server interaction 
as an example of where there is variation.</RCC>
> multiplexing for energy efficiency.
<RCC>I think the interfaces document and the concept of function sets 
and profiles as defined is a good start to embody the concept of "design 
pattern". However, the interfaces document represents interfaces to one 
or more resources in a certain way. It does not seem to describe how 
resources may need to internally collaborate to provide a specific 
useful function. The idea of using design patterns in this context is to 
generalize patterns which represent collaborating resources in a 
homogeneous way; a kind of "middleware" which can be used across 
different applications. So whilst they could be developed solely within 
an application profile, it is likely that repetition will occur across 
application profiles where functions are almost the same but developed 
slightly differently. Hence suggesting using layers of abstraction.</RCC>

---

From: [email-masked]
Date: Tue, 10 Apr 2012 15:09:35 +0200

Robert,

>the basic CoAP protocol need not be extended and that it can be 
>agreement there

Yes we are.

>The idea of using design patterns in this context is to 
>slightly differently. Hence suggesting using layers of abstraction.

If I understand you right, you want to define an abstract relation between 
2 resources to create an interaction between those resources.
The relation could be named "binding" for example.
Then the binding relation could be implemented using Observe or any other 
relevant messaging pattern.
This is definitively something that should be worked out in 
core-interfaces.

Matthieu