[Fiware-iot] First initial analysis of the IoT Assets mapping for the task 5.1 IoT Communications

[thierry.nagellen at orange-ftgroup.com]

Hi Sabrina

 

Thanks for your first analysis.

 

We had slightly discussed the point of protocols IoT SE has to support to deal with different kind of things. I fully support your approach that the optimal way for us is to integrate the protocols through the assets we have because to implement all protocols will take lots of time and the main topic is how we can provide a common access. But in this case, partners would have to develop a dedicated interface to be integrated in the component "Connection Protocol Adapter". This should be a good point for the Open Specification and to target different Use Cases.

 

Regarding EPICs which are different from the description of HLD deliverable, feel free to add a new EPIC to be in line with the deliverable and we would be able to discuss which one is the more critical and how we can put some priorities. We can have "several" EPIC per component and we can discuss which are the most valuable and how we could implement them regarding the assets. So at this moment, this is really fully open to add details and to improve these descriptions.

 

Component Access Policy Control: I think the EPIC would not focus on payment matter but try to explain that as an owner of devices and IoT resources, I can define some criteria to give access right. In this case this could be a Social Network or Open Source Community approach to share devices and things with no commercial ASP, as you could provide access rights only for SMEs, or for eHealth applications despite your IoT Resources are not tagged as eHealth resources. Maybe you can refine this EPIC to describe that several criteria could be used to define access rights. This point should be discussed with the Security team during Turin meeting to check what kind of features they can provide.

 

Quality of service control: this feature is clearly not included in any assets. Based on some comments from UA projects this point should be fundamental (to Instant Mobility project, this quality of service is expected for emergency concerns in a city, or to Safecity project to reach in the proper time some video resources in the city). But as we do not have any asset we can put the priority on "Should" and manage this issue later on (2nd round of FI-Ware backlog, or through the open calls if we know some other partners who could have this kind of asset). We have also holes in Process Automation or Data Handling, so we will not do everything now and if all IoT partners agree, we can delay it. But I think that Thales could have an asset to fulfill this requirement. We would wait one more week for their contributions to decide it.

 

BR

 

Thierry

 

De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Guerra Sabrina
Envoyé : lundi 5 septembre 2011 13:21
À : 'fiware-iot at lists.fi-ware.eu'
Cc : Bellifemine Fabio Luigi; Borean Claudio
Objet : [Fiware-iot] First initial analysis of the IoT Assets mapping for the task 5.1 IoT Communications

 

Hi,

we've begun to analyze the list of assets related to the "IoT Communication" task submitted by the FI-WARE partners. 

Some initial considerations for the components are:

*	Component Connection Protocol Adapter - the better solution is that as many as possible protocols are supported by the IoT Services Enablement Platform, for this reason all the assets presented can be included into the  implementation of the IoT SE Platform, provided that it's possible to translate them in a common internal form through the component Communication Protocol Abstraction Definition. 
*	Component Communication Protocol Abstraction Definition - the epic for this component is different from the description included in the document "FI-WARE High-level Description". Our goal was to introduce a layer that allows an abstraction level for all Connection Protocol Adapters in order to communicate with the IoT SE Platform Core using a common internal language. The "templates", we are referring to in the document, are a kind of rules to translate any specific protocol into the common internal language and not a mechanism to generate Connection Protocol Adapters. This mechanism to automatically generate Connection Protocol Adapters is in any case very interesting and we could add it to the architecture document, if needed. 
*	Component Access Policy Control - The second point of the epic for this component treats the access as a matter of payment (e.g. access only free services), while we intend the access as a matter of permissions to access resources. In our opinion these are different levels and they don't belong to the same component. 
*	Component Quality of Service Control - From the grid it looks like that no asset has this functionality readily available, but since this component is not fundamental for a prototype of the IoT SE Platform, it can be left out or postponed in the future. 

For the other components we don't have specific considerations for the moment, but it looks like that Pangoo/M2MPlanet (by Orange) and Cumulocity (by NSN) are the assets that are more in line with our requirements. 

 

What do you think of this initial analysis of the assets? Are there any comments on these considerations? 

If you agree we could proceed with a more detailed analysis of the two proposed assets.

 

Best regards,

 

Sabrina Guerra
__________________________________
Telecom Italia S.p.a.

Strategia e Innovazione,
Research & Trends
           
Telefono   +39 011 228 8359       
Cellulare +39 331 600 1349

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

 Rispetta l'ambiente. Non stampare questa mail se non è necessario. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110905/c978aee5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 677 bytes
Desc: image001.gif
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110905/c978aee5/attachment.gif>