<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-family: Calibri, sans-serif;">
<div style="font-size: 14px;">Hi Sabet,</div>
<div><br>
</div>
<div>> What about the caching? In some star-like topologies most(if not all) of the sensors are not intermediate, and don't need content store, thus there is no need to check it, right? So why bother?<br>
</div>
<div><br>
</div>
<div>When you say "no need to check it" I assume you mean "no need to check if the cache already has a data packet for the interest." In your topoplogy, there would be a more powerful node that can run a forwarder with a cache. This should actually help the
 low-power sensors since they only have to answer the interest once since the returned data packet is cached in a forwarder. Future interests for the same sensor data would be answered from the cache in the forwarder, saving the low-power sensor from doing
 it.  (I hope I understood your question correctly.)  </div>
<div><br>
</div>
<div>- Jeff T</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Muhammad Hosain Abdollahi Sabet <<a href="mailto:M.AbdollahiSabet@Mail.sbu.ac.ir">M.AbdollahiSabet@Mail.sbu.ac.ir</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, March 3, 2015 at 11:44<br>
<span style="font-weight:bold">To: </span>Anil Jangam <<a href="mailto:anilj.mailing@gmail.com">anilj.mailing@gmail.com</a>>, Jeff Thompson <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>RE: [Ndn-interest] NDN architecture in wireless sensor networks?<br>
</div>
<div style="font-size: 14px;"><br>
</div>
<div style="font-size: 14px;">
<meta name="Generator" content="MS Exchange Server version 6.5.7652.24">
<title>RE: [Ndn-interest] NDN architecture in wireless sensor networks?</title>
<div><!-- Converted from text/plain format -->
<p><font size="2">Jeff,<br>
Thanks for the reply. Actually we haven't experienced anything yet, not that I know of. I'm just the ndn-guy of the team, who is encouraging his colleagues to consider NDN for implementing their WSN scenario(I guess the reason why I'm here, is clear now:).
 My teammate will show up soon. She probably knows about the micro-controller specs. But in my humble assumption, it should be a kind of Arduino-based ones.<br>
The sensors which are used in Anil's suggested paper are ATxmega128A1 microcontrollers.<br>
<br>
What about the caching? In some star-like topologies most(if not all) of the sensors are not intermediate, and don't need content store, thus there is no need to check it, right? So why bother?<br>
<br>
Anil,<br>
Thank you so much. I will take a full look at that. Maybe we should consider some CCN-NDN differences then.<br>
<br>
Thanks,<br>
Sabet<br>
<br>
-----Original Message-----<br>
From: Anil Jangam [<a href="mailto:anilj.mailing@gmail.com">mailto:anilj.mailing@gmail.com</a>]<br>
Sent: Tue 3/3/2015 8:03 PM<br>
To: Thompson, Jeff<br>
Cc: <a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>; Muhammad Hosain Abdollahi Sabet<br>
Subject: Re: [Ndn-interest] NDN architecture in wireless sensor networks?<br>
<br>
Sabet,<br>
<br>
You may want to take a look at this optimized ccn stack for WSN. I don't<br>
know however what footprint it works on.<br>
<br>
<a href="http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6529776&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6529776">http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6529776&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6529776</a><br>
<br>
/anil.<br>
On Mar 3, 2015 8:17 AM, "Thompson, Jeff" <<a href="mailto:jefft0@remap.ucla.edu">jefft0@remap.ucla.edu</a>> wrote:<br>
<br>
>  Hello Sabet,<br>
><br>
>  A sensor can certainly receive an NDN interest and return a data packet<br>
> using a client library. If the sensor's microcontroller is too small to<br>
> sign the data packet with public key cryptography, it can use symmetric<br>
> authentication, for example as described in section IV - D of "Securing<br>
> Building Management Systems Using Named Data Networking".<br>
> <a href="http://named-data.net/publications/securing_building_management_ndn/">
http://named-data.net/publications/securing_building_management_ndn/</a><br>
><br>
>  Is it enough for your sensors to receive an interest and respond with a<br>
> data packet?  May I ask what is the memory and program storage size of your<br>
> target microcontroller? (We have some experience with Arduino-based<br>
> microcontrollers.)<br>
><br>
>  Thanks,<br>
> - Jeff T<br>
><br>
>   From: Muhammad Hosain Abdollahi Sabet <<a href="mailto:M.AbdollahiSabet@mail.sbu.ac.ir">M.AbdollahiSabet@mail.sbu.ac.ir</a>><br>
> Date: Tuesday, March 3, 2015 at 7:33<br>
> To: "<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>" <<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>><br>
> Subject: [Ndn-interest] NDN architecture in wireless sensor networks?<br>
><br>
>   Considering the fact that caching is an architectural attribute in NDN<br>
> and again considering NDN trust model features, like cryptographic policies<br>
> in command interest(public key-private key), is it ok for NDN to work in<br>
> WSN scenarios? The need for designing a forwarding strategy seems clear.<br>
> But having in mind that we have serious challenges for energy management in<br>
> wireless sensors, couldn't we just ignore CS and PIT table for some<br>
> applications, and have a simpler NFD?<br>
> I've already seen the paper about securing the campus BMS on the website.<br>
> It has said:<br>
><br>
> "Our initial deployment collects sensing data from existing<br>
> industry-standard sensors and<br>
> gateways that employ legacy BMS protocols. Consequently, our design<br>
> includes gateway devices that read data (through an internal IP network)<br>
> from sensor devices running legacy<br>
> BMS protocols and publish the resulting data in an NDN network."<br>
><br>
> Well, I don't mean like that. I want to read data from sensors which<br>
> running NDN protocols.<br>
><br>
> I will be glad to read your ideas.<br>
><br>
> Thanks<br>
> Sabet<br>
><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
><br>
><br>
<br>
</font></p>
</div>
</div>
</span>
</body>
</html>