Subject: [icnrg] Fwd: request for comments on Requirements and Challenges for IoT over ICN

From: Yuansong Qiao <[email-masked]>
Date: Thu, 10 Mar 2016 10:09:57 +0000

Dear Authors/All

Below are some comments from our side in relation to in-network computation
wrt to this draft.

====================
# Comments on Section 2 (IoT Architecture Requirements)
# The following comments could be in a separate section or fit into Section
2.10 (Self-Organization) or 2.12 (Open API)

Decoupling the Sensing Infrastructure from Applications:
In a unified IoT platform, various applications run on top of a vast number
of IoT devices. Upgrading the firmware of the IoT devices is a difficult
work. It is also not practical to reprogram the IoT devices to accommodate
every change of the applications. The infrastructure and the application
specific logics need to be decoupled. A common interface is required to
dynamically configure the interactions between the IoT devices and easily
modify the application logics on top of the sensing infrastructure [1] [2].

# Comments on Section 5 (ICN Challenges for IoT)
# Section 5.6 (In-network Computing)

Benefits:
As described in [2], in-network computing can help dynamically re-configure
the interactions between IoT devices to support different application
logics.

Challenges:
– Heterogeneous execution environment: IoT devices need to provide an
execution environment to run the functions obtained locally or from remote
devices. Platform independent programming languages are preferable to
implement the functions so that the applications can be decoupled from the
IoT infrastructure [2]. However, different IoT devices may offer different
execution environments, e.g. some support Python whereas some only support
native code. The programming model needs to support these heterogeneous
execution environment.

– Function naming: Functions, input parameters, and the output result could
be encapsulated in the packet header (e.g. NFN), the packet body, or
mixture of the two (e.g. [2]). If functions are encapsulated in packet
headers, the naming scheme affects how a computation task is routed in the
network (e.g. NFN), which IoT devices are involved in the computation task
(e.g. [3]), and how a name is decomposed into smaller computation tasks and
deployed in the network for a better performance.

– Routing: normal routing is for forwarding requests to the nearest source
or cache and return the data to the requester, whereas the routing for
in-network computation has a different purpose. If the computation task is
for aggregating sensed data, the routing strategy is to route the data to
achieve a better aggregation performance [4].

– Computation task deployment and scheduling: IoT devices have different
capabilities, the platform needs to assign computation tasks according to
the involved sensors and the available computation resources which may
change over time. An efficient computation resource discovery and
management protocol is required to facilitate this process. The trade-off
between information transmission and processing is another challenge.

– Time/Task synchronization: Some computation tasks may need
synchronizations between sub-tasks or IoT devices, e.g. a device may not
send data as soon as it is available because waiting for data from the
neighbours may lead to a better aggregation result; some devices may choose
to sleep to save energy while waiting for the results from the neighbours;
while aggregating the computation results along the path, the intermediate
IoT devices may need to choose the results generated within a certain time
window.

Reference:
[1] Alessandrelli, D., Petracca, M., and P. Pagano, "T-Res: enabling
reconfigurable in-network processing in IoT-based WSNs", IEEE International
Conference on Distributed Computing in Sensor Systems (DCOSS), 2013.

[2] Kovatsch, M., Mayer, S., and B. Ostermaier, “Moving application logic
from the firmware to the Cloud: towards the thin server architecture for
the internet of things", in Proc. 6th Int. Conf. on Innovative Mobile and
Internet Services in Ubiquitous Computing (IMIS), 2012.

[3] Drira, W., and F. Filali, "NDN-Q: An NDN Query Mechanism for Efficient
V2X Data Collection", Eleventh Annual IEEE International Conference on
Sensing, Communication, and Networking Workshops (SECON Workshops), 2014.

[4] Fasoloy, E., M. Rossiy, J. Widmer, and M. Zorziy, "In-network
Aggregation Techniques for Wireless Sensor Networks: A Survey", IEEE
Wireless Communications, 2007.
====================

Best Regards,
Yuansong
----------------------------------
Dr. Yuansong Qiao
PI - SFI SIRG
Software Research Institute
Athlone Institute of Technology
Athlone, Co. Westmeath, Ireland
Email: [email-masked]
Phone: +353 906471893
Web: http://sri.ait.ie
         http://comand.ie/

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 10 Mar 2016 18:25:17 +0000

Hi Yuansong

Thanks for the contribution and will take them appropriately into the revised draft. Will get back to you for more details, if necessary, after discussing with the other authors.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Yuansong Qiao
Sent: Thursday, March 10, 2016 2:10 AM
To: [email-masked]
Subject: [icnrg] Fwd: request for comments on Requirements and Challenges for IoT over ICN

Dear Authors/All

Below are some comments from our side in relation to in-network computation wrt to this draft.

====================
# Comments on Section 2 (IoT Architecture Requirements)
# The following comments could be in a separate section or fit into Section 2.10 (Self-Organization) or 2.12 (Open API)

Decoupling the Sensing Infrastructure from Applications:
In a unified IoT platform, various applications run on top of a vast number of IoT devices. Upgrading the firmware of the IoT devices is a difficult work. It is also not practical to reprogram the IoT devices to accommodate every change of the applications. The infrastructure and the application specific logics need to be decoupled. A common interface is required to dynamically configure the interactions between the IoT devices and easily modify the application logics on top of the sensing infrastructure [1] [2].

Benefits:
As described in [2], in-network computing can help dynamically re-configure the interactions between IoT devices to support different application logics.

Challenges:
– Heterogeneous execution environment: IoT devices need to provide an execution environment to run the functions obtained locally or from remote devices. Platform independent programming languages are preferable to implement the functions so that the applications can be decoupled from the IoT infrastructure [2]. However, different IoT devices may offer different execution environments, e.g. some support Python whereas some only support native code. The programming model needs to support these heterogeneous execution environment.

– Function naming: Functions, input parameters, and the output result could be encapsulated in the packet header (e.g. NFN), the packet body, or mixture of the two (e.g. [2]). If functions are encapsulated in packet headers, the naming scheme affects how a computation task is routed in the network (e.g. NFN), which IoT devices are involved in the computation task (e.g. [3]), and how a name is decomposed into smaller computation tasks and deployed in the network for a better performance.

– Routing: normal routing is for forwarding requests to the nearest source or cache and return the data to the requester, whereas the routing for in-network computation has a different purpose. If the computation task is for aggregating sensed data, the routing strategy is to route the data to achieve a better aggregation performance [4].

– Computation task deployment and scheduling: IoT devices have different capabilities, the platform needs to assign computation tasks according to the involved sensors and the available computation resources which may change over time. An efficient computation resource discovery and management protocol is required to facilitate this process. The trade-off between information transmission and processing is another challenge.

– Time/Task synchronization: Some computation tasks may need synchronizations between sub-tasks or IoT devices, e.g. a device may not send data as soon as it is available because waiting for data from the neighbours may lead to a better aggregation result; some devices may choose to sleep to save energy while waiting for the results from the neighbours; while aggregating the computation results along the path, the intermediate IoT devices may need to choose the results generated within a certain time window.

Reference:
[1] Alessandrelli, D., Petracca, M., and P. Pagano, "T-Res: enabling reconfigurable in-network processing in IoT-based WSNs", IEEE International Conference on Distributed Computing in Sensor Systems (DCOSS), 2013.

[2] Kovatsch, M., Mayer, S., and B. Ostermaier, “Moving application logic from the firmware to the Cloud: towards the thin server architecture for the internet of things", in Proc. 6th Int. Conf. on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2012.

[3] Drira, W., and F. Filali, "NDN-Q: An NDN Query Mechanism for Efficient V2X Data Collection", Eleventh Annual IEEE International Conference on Sensing, Communication, and Networking Workshops (SECON Workshops), 2014.

[4] Fasoloy, E., M. Rossiy, J. Widmer, and M. Zorziy, "In-network Aggregation Techniques for Wireless Sensor Networks: A Survey", IEEE Wireless Communications, 2007.
====================

Best Regards,
Yuansong
----------------------------------
Dr. Yuansong Qiao
PI - SFI SIRG
Software Research Institute
Athlone Institute of Technology
Athlone, Co. Westmeath, Ireland
Email: [email-masked]<mailto:[email-masked]>
Phone: +353 906471893<tel:%2B353%20906471893>
Web: http://sri.ait.ie
         http://comand.ie/