Re: [core] WG interest in Sleepy Node topic

["weigengyu" <[e-mail]>]

Hi Pete, 

You are right. 
#3 in my email just considered the stationary case. 
Yours is general. 

regards,

Gengyu 
Network Technology Center 
School of Computer
Beijing University of Posts & Telecommunications

From: Pete St. Pierre 
Sent: Thursday, December 12, 2013 12:08 AM
To: weigengyu 
Cc: Carsten Bormann ; Core 
Subject: Re: [core] WG interest in Sleepy Node topic

I agree with your assessment of #1 & #2. However, I don't think it is fair to assume in scenario #3 that network parameters can be assumed to remain unchanged. I've worked with devices that were used as you describe case #3, but when nodes awoke, they were highly likely to be in a different place with a different network environment. In many cases, a complete change of network was required (ie WiFi to 3G or Satellite). 

Similarly, isn't a laptop a sleepy node? It sleeps when the lid is closed and doesn't reboot every time it is opened. However it frequently comes back on the network in a place where the network environment has changed. 

#3 may be true, but only if the node is 'sleepy' and stationary.
...Pete

On Dec 11, 2013, at 1:36 AM, weigengyu <[e-mail]> wrote:


  Hi Carsten and all,

  I think the Sleepy node problem is important, and CoAP mailing list seems to consider intermitent node currently.
  While, what is the sleepy node and what is the intermitent node?
  What network parameter are effected and what kind of networks needs concerning?

  I would like to give what intermitent node (or intermitent endpoint) I concern.
  I think the intermitent indicates the following situations of CoAP endpoint:
  1. the node will be power off and on, or reboot;
  2. the node will go out and into the signal coverage, so the wireless commnication could be able and inable intermitently;
  3. the node is into sleep mode in order to save power. Such a node might be the sleepy node you called.
    Due to its inability to reponse the request, the sleepy node may be like the intermitent node.
  In other words, the sleepy node is an intermitent node in nature in terms of communication ability intervals.

  The  bootup process is required in the above cases 1, but not in the cases of 2 and 3.
  The network parameters , such as IP address, re-allocation is determined by the networks that the node accesses.

  By Esko’ email, if the node is auto-configured by DHCP server, or the like,
  the node could get back network configured parameters whenever reboot.
  But this does not means that when rebooting the node saves the parameters itself enve though flash memory is embeded.
  The most typical network is WIFI.  When the mobile PC reboots,
  the DHCP server's parameters (option) determines whether to change the mobile PC's IP address.

  The very different network is mobile 3G/4G, the mobile node will get new IP address in the case of 1 and  probably 2.
  The node in sleepy mode closes the data sending port and/or receiving port.
  The smart phone usually close both ports. (As a result signalling storm is apppeared in the mobile networks)
  This is case 3, and the node holds its network parameters. The communication ability will be delayed until the sleepy interval is expired.

  Maybe the problem of configuration is out of CoAP scope,  and it is not clear what the CoAP endpoint enviroments have.
  Only the Resource Directory Server is depicted  and may function this in the given cases.

  There is not a systematic processes defined to tackle sleepy or intermitent node.

  So, the sleepy node I concerned is case 3; the intermitent node I concerned is case 1,2 and 3.

  Regards,

  Gengyu

  Network Technology Center
  School of Computer
  Beijing University of Posts & Telecommunications.


  -----原始邮件----- From: Carsten Bormann
  Sent: Saturday, November 09, 2013 9:25 AM
  To: Thomas Fossati
  Cc: Core
  Subject: Re: [core] WG interest in Sleepy Node topic

  On 08 Nov 2013, at 01:48, Thomas Fossati <[e-mail]> wrote:


    out of CoRE scope


  At this stage of the discussion, I would be less concerned with the WG scope than with finding out what the industry actually needs to be standardized to foster interoperability.  If there are items within this set that are outside CoRE scope, we can always try to find a home for them, either by rechartering or by finding another WG.  But it is important to have a clear understanding of the items that we think need to be speced.  At a level a bit more specific than we have been discussing so far.

  Grüße, Carsten

  _______________________________________________
  core mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/core 
  _______________________________________________
  core mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/core


--
Pete St. Pierre
[e-mail]
[phone]