Hi,

Thanks for the review and comments.

On 7/29/12 12:12 AM, Zhen Cao wrote:
[...]
I like the style of section 3, the analysis of the link layer
implications for energy-efficient application development. Some
questions and comments are listed separately as below.
- Public network. Is it just used as the adverse of “private network”?

Yes, but especially a network that is not built just for the purpose of a particular application.

- Point to point link. As analyzed in the draft, this is a normal case
for cellular connection, no way and no need to consider third party
devices. As to achieve energy efficient is always contradictory of
handling multicast/broadcast packets, it is relatively easier to be
efficient with PPP link. Or shall we make such recommendations?

Makes sense to mention this.

- Radio technology. Radio proved to be the most energy consuming part,
and L2 mechanisms are most efficient in the optimization space. I
turned to believe that there is no need to optimize the upper layers
before I encounter the idea of message coordination. That is to reduce
the frequency of trigger link up by coordinating the send/recv
behavior of different protocols. For example, 6LOWPAN-ND advertises
sometime and wake the radio, and then radio/MAC layer optimization
turns it off before COAP protocol triggers a groupcomm afterwards. If
these send/recv of different protocols can be coordinated, I guess the
situation will be much better.

Yes, the message coordination and model can have a big impact on the energy consumption; we briefly discuss the topic in this draft, but there's more about it in draft-arkko-core-sleepy-sensors. Maybe some more cellular specific text could be added to this draft too.

Section 7 on the “Real-time reachable device”.  For cellular devices,
there is one characterize to utilize: they are always reachable from
the circuit-switch side.  Take the CoAP protocol as an example, if it
is difficult to reach the device (as a CoAP server, or to initiate the
observe mode) from the packet side, we can trigger it via a SMS
message and let it behave as a client.  This is a rather special case
for cellular devices that developers can take advantage of.  I heard
of some usage in this regards.

With GSM, SMS can indeed be useful for triggering, but if you don't have CS side, the situation gets a bit different.

Again, I believe the description and analysis in this document is
useful for the cellular M2M devices. Guidelines for CoAP and other
IETF protocols can be derived from it.

Thanks!


Cheers,
Ari

Best regards,
CZ

On Mon, Jul 9, 2012 at 4:43 AM, Jari Arkko<[email protected]>  wrote:
Hi,

We have written a draft that talks about how to apply CoAP in smart objects
attached to the Internet via the cellular networks.

Comments appreciated.

Jari

On 09.07.2012 14:37, [email protected] wrote:

A new version of I-D, draft-arkko-core-cellular-00.txt
has been successfully submitted by Jari Arkko and posted to the
IETF repository.

Filename:        draft-arkko-core-cellular
Revision:        00
Title:           Building Power-Efficient CoAP Devices for Cellular
Networks
Creation date:   2012-07-09
WG ID:           Individual Submission
Number of pages: 17
URL:
http://www.ietf.org/internet-drafts/draft-arkko-core-cellular-00.txt
Status:          http://datatracker.ietf.org/doc/draft-arkko-core-cellular
Htmlized:        http://tools.ietf.org/html/draft-arkko-core-cellular-00


Abstract:
     This memo discusses the use of the Constrained Application Protocol
     (CoAP) protocol in building sensors and other devices that employ
     cellular networks as a communications medium.  Building communicating
     devices that employ these networks is obviously well known, but this
     memo focuses specifically on techniques necessary to minimize power
     consumption.



The IETF Secretariat



_______________________________________________
core mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip

Reply via email to