<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Dear Faran, </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Experts may response in this regards, however, here is my answer:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In Vehicular NDN research, mostly authors assume that content routers are installed in each vehicle, especially, when we say that no infrastructure support is there such as RSU. So my point is that almost every node/vehicle is performing as a content router + provider + consumer role at different instances under the given circumstances. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Now, if we talk about "Push" based communications, then we might have a look at Pub/Sub mechanisms. If the vehicles in any area are subscribed to the specific type of data, then they don't need to send interest(s) every time. On the other hands, the producers start "pushing" the data into the network. However, in naive NDN, this approach may have its own consequences. Because, when you push, then it will cost extra cost in terms of overhead and additional copies of the packets and there might be a case, that all the neighboring nodes do not want to have that video content so why they pay the cost of channel utilization for receiving the data, they don't want or have any interest. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I am not sure, that did I give you the required answer. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Good Luck~~</div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div class="gmail_signature"><div dir="ltr"><span style="font-family:arial,helvetica,sans-serif;font-size:small"><br></span></div><div dir="ltr">Kind Regards,<br>~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br><b>Syed Hassan Ahmed</b><br>사예드 하산 아흐메드<br><br>PhD Research Scholar,<br><a href="http://monet.knu.ac.kr" target="_blank">MoNeT Wireless Lab,</a><br>Kyungpook National University,<br>Daegu City, Republic of Korea.<br>Cell: +82-10-9883-0786<br><a href="https://sites.google.com/site/shahmedknu/" target="_blank">https://sites.google.com/site/shahmedknu/</a> </div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Dec 5, 2015 at 3:55 PM, Muhammad Faran <span dir="ltr"><<a href="mailto:m.faran.majeed@gmail.com" target="_blank">m.faran.majeed@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi!<br><br></div>So far, I have been viewing NDN architecture working as pull-based mechanism. Is there any possibility to incorporate "Push" mechanism in it? Because for some environments, (vehicular/MANET), pull-based mechanism may not work properly.<br></div><div><br></div>Scenario: In a highly dynamic environment, the producer moving quickly among content routers, capturing and publishing video. So, producer can not wait for an interest and want to push the video content in-network before its local storage is full.<br><br><div><div><br clear="all"><div><div><div><div dir="ltr"><div><div dir="ltr">Kind regards,<br><br></div><div>Faran,<br></div><div>AIT, Thailand<br></div></div></div></div></div>
</div></div></div></div>
<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" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
<br></blockquote></div><br></div></div>