Dear all, yesterday I promised some more information on the OMA NGSI APIs. You can now find here FI-Ware IoT -> Docs -> Uncategorized Submissions<https://forge.fi-ware.eu/docman/?group_id=11> https://forge.fi-ware.eu/docman/?group_id=11 (a) OMA NGSI Info - Document with links to the standard documents and related information There is a good OMA NGSI overview presentation referenced. I recommend to read this. (b) Paper and presentation at ICIN'2010 Gives more insights into the Ctx API which we think is relevant for IoT - Ernö From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Ernoe Kovacs Sent: Dienstag, 6. September 2011 16:03 To: Ricardo de las Heras; thierry.nagellen at orange-ftgroup.com Cc: fiware-iot at lists.fi-ware.eu; fabioluigi.bellifemine at telecomitalia.it; claudio.borean at telecomitalia.it Subject: Re: [Fiware-iot] First initial analysis of the IoT Assets mapping for the task 5.1 IoT Communications Hi all, fast reply here, I provide more background information to study later on. (a) Original discussion "Connection Protocol Adapter" or "component connection Protocol Adapter" I think we are all sharing the same idea here. We have very heterogeneous M2M area network protocols including very different data models. We need to map this into a common protocol model and common data model. Let me go one step deeper: Sensor support very different kind of interactions. Some are waiting to be queried. Some send their information periodically, some send the information when a substantial change has happened, some have a management interface to configure their behavior, etc. etc. Some needs sessions, some only have one shot queries that include authentication each time they are called. I fear you find anything that can be imagined on that level An abstraction layer needs to map all these protocols into a single one. This single one is the language to talk inside of the systems. The "Connection Protocol Adapter" are the software modules that - map between the real protocol on the M2M Area network and the high-level protocol. - fill the gap between what the sensor offers and what the high-level protocol requests. For example, if the high level protocol supports subscriptions and the lwo level one not, either the "connection protocol adapter" or the "Abstraction layer" need to provide the needed functionality... (b) OMA NGSI In the sense of the discussion under (a), OMA NGSI can be the higher level protocol that the abstraction layer supports. OMA NGSI supports updates, queries, subscriptions, and notifications. (c) OMA NGSI as Exposure API For interacting with external systems like WP6, OMA NGSI is a standardized API with comparable rich set of operation. So we can use it as an exposure API towards applications. It also has a data model based on entities, attributes and meta-data about them. Note: The exposure API can be used on the IoT Device, on the IoT Gateway or on the IoT Core. (d) OMA NGSI and IoT Gateways-2-IoT Core Communication Besides the data flow services (update, query, subscribe, notify), OMA NGSI has a small set of primitives that enables two systems to exchange meta-data about the contained objects. So a IoT gateway can register with the IoT Core and inform them that e.g it is currently managing 1 RFID readers, will sent information about "hasSeen RFID Tags" and has a GPS receiver. Yes, OMA NGSI can be used for that as well. I am expecting that we might extend the information exchanged between IoT GW and IoT Core, but OMA NGSI is a starting point. Our ISIS system implements large parts of the OMA NGSI features. @Thierry: You are right this is different to the NFC protocol , 6LowPAN, ZigBee. The Connection Protocol Adapter can handle this heterogenity. I am reasonable sure that FIWare will not try to overcome the heterogeneity on Layer 1 (Radio) or L2 (Data Link). IMHO, the approach cannot be to map either directly into each other (nightmare, n x m) or into a higher level protocol ( n x 1). The alter approach is what we are suggesting. In our ISIS system we have shown it can work... - Ernö From: fiware-iot-bounces at lists.fi-ware.eu<mailto:fiware-iot-bounces at lists.fi-ware.eu> [mailto:fiware-iot-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-iot-bounces at lists.fi-ware.eu]> On Behalf Of Ricardo de las Heras Sent: Dienstag, 6. September 2011 14:01 To: thierry.nagellen at orange-ftgroup.com<mailto:thierry.nagellen at orange-ftgroup.com> Cc: fabioluigi.bellifemine at telecomitalia.it<mailto:fabioluigi.bellifemine at telecomitalia.it>; claudio.borean at telecomitalia.it<mailto:claudio.borean at telecomitalia.it>; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu> Subject: Re: [Fiware-iot] First initial analysis of the IoT Assets mapping for the task 5.1 IoT Communications Dear Thierry, yes, you're right regarding the issue that we have to deal with a broad type of protocols in order to communicate sensors, actuators, devices with a gateway. But my question was beyond this step, when we have to specify a protocol for interchanging data between every gateway and the IoT platform (using SensorAPI for example in the case of IDAS asset). At this level and for interchanging data with context awareness system or other external applications, then is where I tried to explain that could be useful to include the protocol NGSI as a reference protocol of the IoT WP5. Maybe some of our colleagues from NEC or TI can provide us more background with it, but NGSI seems to be quite flexible and direct in order to allow us to map the existent protocols in every asset to the NGSI standard. Sorry if there is any mistake in the details of my explaination. ISIS asset (NEC) for example provides an API interface based on NGSI. So this could be a perfect example of it. cheers, Ricardo. thierry.nagellen at orange-ftgroup.com<mailto:thierry.nagellen at orange-ftgroup.com> wrote: 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<mailto:sabrina.guerra at telecomitalia.it> Cc : fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>; fabioluigi.bellifemine at telecomitalia.it<mailto:fabioluigi.bellifemine at telecomitalia.it>; claudio.borean at telecomitalia.it<mailto: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<mailto: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<mailto: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> [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<mailto: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]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 -- ------------------------------------- Ricardo de las Heras M2M Research Project Manager E-mail:<mailto:rheras at tid.es> rheras at tid.es<mailto: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> ------------------------------------- ________________________________ 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/20110908/33178fa5/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/20110908/33178fa5/attachment.gif>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy