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

[thierry.nagellen at orange-ftgroup.com]

Dear Ricardo

 

Maybe I missed a point or there is a misunderstanding. We have to deal here with communication protocols as NFC which could use different frequencies, 6LowPan or Zigbee, Bluetooth, etc... and NGSI try to formalize a standard to exchange context information with applications.

 

In the case of the "component connection Protocol Adapter" the main issue is that lots of communication protocols are used by different devices and if we do not have this component we will not provide a common access to different types of devices, which deal with one or more IoT resources.

 

As I understand NGSI, but I'm not an expert, it provides a common model with dedicated functionalities to define a context element. This is quite relevant for DCM to manage context but less useful for events description for example. But maybe my understanding of NGSI is too limited.

 

Best regards

 

Thierry

 

De : Ricardo de las Heras [mailto:rheras at tid.es] 
Envoyé : mardi 6 septembre 2011 12:52
À : NAGELLEN Thierry RD-BIZZ-SOP; sabrina.guerra at telecomitalia.it
Cc : fiware-iot at lists.fi-ware.eu; fabioluigi.bellifemine at telecomitalia.it; claudio.borean at telecomitalia.it
Objet : Re: [Fiware-iot] First initial analysis of the IoT Assets mapping for the task 5.1 IoT Communications

 

Dear Sabrina, Thierry,

regarding your first point:
"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."

I'm not an expert on these type of protocols, but as far as I know within the WP6 (Contextual) they are going to use an the OMA standard TS-NGSI for the Context_Management.
(http://www.openmobilealliance.org/technical/release_program/ose_archive.aspx)
You can find attached a pdf with the NGSI specification.

Indeed TI and NEC were very active on the definition of this standard, so it would be fine if we define it as the common language within WP5, maybe mapping the protocols used in the assets to NGSI, having clear advantages in order to communicate us with the rest of WPs, mainly with WP6.

Furthermore, the WAC initiative (http://en.wikipedia.org/wiki/Wholesale_Applications_Community) fully support NGSI as well, so it is again a new point for reinforce this decision, with clear advantages for Fiware using this important OMA standard.

I don't know what's your point of view, maybe Thierry you can discuss it with Juanjo Hierro,
thanks,

regards,
Ricardo.

-- 
-------------------------------------
Ricardo de las Heras
M2M Research Project Manager
E-mail: <mailto:rheras at tid.es>  rheras at tid.es
Phone1: (+34) 983 367625
Phone2 OCS: (+34) 91 31 29511
Phone3 Skype: (+34) 91 1878107 + Ext: 327
Telefónica I+D <http://www.tid.es> 
-------------------------------------


thierry.nagellen at orange-ftgroup.com wrote: 

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. 

 

 

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110906/ec40a356/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/20110906/ec40a356/attachment.gif>