Dear all, Regarding the IoT architecture presented recently by TID, I would like to add some more general considerations for the discussion. I would characterize the proposal as - logically centralized, i.e. all information flows through the system as events, which are stored in the events repository - push-based, i.e., it is assumed that events are automatically published and pushed through the system, at least towards the central repository from which they may be further distributed - completely de-coupled, i.e., applications can subscribe or query the system, but the answer depends on what is provided by the repositories / pub-/sub-broker - a request cannot directly result in a call to the gateway or device to trigger a measurement or an actuation, the complete decoupling prevents that In the following I discuss a number of issues I see with this proposal. IoT Ecosystem The logically centralized approach could be suitable for a single domain / single provider approach. For this information all information can be handled centrally and the operator can be considered trusted. It is difficult to see how this approach would work in a multi-domain, multi-operator scenario with potentially different roles forming an IoT ecosystem. In such an ecosystem there could be different providers of information, who may want to be found, but still completely control the access to their information, which may be their asset, i.e., they may want to check who accesses what information and also charge for that. Having to automatically publish information into the system and having to completely trust a platform operator may not be in their interest. Also, storing history of past information etc. could in principle be handled by a separate role, whereas in the presented approach there does not seem to be room for such a role. The SENSEI architecture has a strong focus on supporting an IoT ecosystem with multiple roles. Noisy system and missing adaptation to application requirements Due to the decoupling, all information has to be communicated towards the core of the platform, whether anybody is interested or not. This creates a lot of "noise". The goal of the SENSEI platform was to only communicate (or even capture) information when there was some interest for this information. Depending on whether you can dimension your system as needed or not, you may have to restrict, e.g., the frequency of publication, the size of data to publish etc. For example, it may be okay if a certain value is published every couple of minutes in normal circumstances, but in a special situation, an application may want the value every few milliseconds. With a complete decoupling, this either cannot be realized or you have to always publish every few milliseconds (which may, e.g., also deplete the batteries of a sensing device). The SENSEI system could support such requests, but of course it could still restrict application access, i.e., the provider may not want to allow an update every few milliseconds, but then this is a policy and not a limitation of the system. Actuation and expensive operations For actuation or some expensive operations it is necessary that a request directly triggers an operation on an IoT device. An expensive operation may be a Bluetooth scan, which may take 25s and is very expensive in terms of battery, so it should only be done as a result of a request (with the system potentially limiting the frequency of request), but it should not happen automatically. For actuation operations a command may have to be sent (e.g. based on a change of an attribute of a Thing). Currently there does not seem to be a way to support this as the system is completely decoupled. I hope these issues can be discussed either tomorrow during the phone conference or at the face-to-face meeting in Madrid. Best regards, Martin ------------------------------------------ Dr. Martin Bauer Senior Researcher NEC Europe Ltd. NEC Laboratories Europe Software & Services Research Division Kurfürsten-Anlage 36 D-69115 Heidelberg Tel: +49/ (0)6221/4342-168 Fax: +49/ (0)6221/4342-155 E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu> http://www.nw.neclab.eu<http://www.nw.neclab.eu/> ************************************************************* NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120117/a40e2a22/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy