Hello Tobias,
After going through the deliverable and familiarizing with the components of the GE, I would like to explain further the possible role for our (UoS) asset in the Things Management GE, i.e. what is currently termed the "inference engine", as it seems to look quite lonely in the architecture diagram.
The purpose of the asset is to provide assistance for discovery of relevant things/resources when explicit querying does not provide any results. This could happen when values for attributes used for querying are not recognized by the repository platform, i.e. the configuration management component. In this case the IoT broker can make use of the "inference engine" for retrieving the closest results by using the attribute values as keywords and matching them to indexed entries for resources gathered at the time of publication.
Technical details can be provided, but it would be good to understand the use of our asset in the first place. I've tried to illustrate this in the diagram attached.
The term "inference engine" is somewhat generic and ambiguous. We suggest it be called either "discovery engine", or "discovery assistant engine" so as not to clash with the role of the IoT broker.
I am noticing in the deliverable that it is being named "interference engine", but I hope it will not cause any interference with the other components in the GE. :)
Any comments are welcome.
Best regards,
Tarek
Tarek Elsaleh
Research Assistant
Centre for Commuication Systems Research (CCSR)
Department of Electronic Engineering
University of Surrey
Guildford, GU2 7XH
Tel: 01483 689485
From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs
Sent: 27 April 2012 13:54
To: Farkas, Lorant (NSN - HU/Budapest); fiware-iot at lists.fi-ware.eu
Subject: Re: [Fiware-iot] IoT Chapter streamlined architecture
Dear Lorant, all,
I can put parts of a description of the Things&Resource Management GE into the wiki.
However I do not know what the interface to the Backend Core is - so I do not really feel able to describe that API. Also I could have difficulties describing the aspects coming from Interference Engine - but maybe there are things I can copy and paste from the old descriptions.
Best
Tobias
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] On Behalf Of Farkas, Lorant (NSN - HU/Budapest)
Sent: Freitag, 27. April 2012 14:24
To: fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Subject: Re: [Fiware-iot] IoT Chapter streamlined architecture
Dear All,
I would add that both me and Dénes are away during Monday and Tuesday (official holiday in Hungary). We would like to avoid wasting valuable time that you could contribute to implementing these changes because of lack of information/coordination. We are in a kind of hurry because the deadline of delivering M12 deliverables (Open Specs, Exploitation plans among them) is Monday. So if any of the partners have time/are not on holiday between now and the next weekly meeting, I would kindly ask to please contribute to the:
1. architecture/open specs deliverable: please don't hesitate to edit the new private wiki page (D2.3 streamlined, under the link by Dénes). The process could be the following:
-put in the text from the old private wiki page D2.3 and correct in the text things that were updated in the architecture
-put in the new graphml (the png generated from it) - we were discussing that we could keep just one diagram instead of the currently shown two and the internal details (connections between functional components inside the GE-s) would be shown only in the GE sub-wiki pages
-start editing the GE-s themselves
-Ericsson colleagues could start the gateway part, in particular the Gateway/Device Management part, Usurrey/Telecom Italia could also contribute there
-NEC could work on the backend in the Things Management GE
-Orange could contribute to the Data Handling GE part of the gateway
2. Exploitation deliverable: I created the placeholder for the sections per new GE under https://forge.fi-ware.eu/plugins/mediawiki/wiki/exploitation/index.php/Business_description_GE_Internet_of_Things (you can access this once you are logged in to the exploitation project in forge), the suggestion would be for the partners to take in hands the same GE-s as suggested in the previous point
Thanks & Br,
Lorant
From: Bisztray, Denes (NSN - HU/Budapest)
Sent: Friday, April 27, 2012 2:03 PM
To: thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com>; Farkas, Lorant (NSN - HU/Budapest); ext Juanjo Hierro; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>
Cc: ext Tobias Jacobs
Subject: IoT Chapter streamlined architecture
Dear All,
We discussed the architecture with Juanjo and came to the conclusion with the attached result.
The most important point was not to change agreements that were already discussed. Thus the following changes and observations have been made:
- The Data Handling GE exposes an NGSI-10 interface as it did in the previous architecture as well. It is important not to lose such details with the streamlining. This NGSI-10 interface is connected to the Things Management GE making it possible for the things management to get direct NGSI event updates from the gateway. The functionality of the IoT Agent proposed by NEC on the backend seems to be delivered by the Data Handling GE.
- The Device Data API will be a translation of ETSI M2M that makes the device data and device updates more useful for the Things Management GE.
- All the components in the Things Management GE is untouched. They are simply in one GE. Hence, the previously external interfaces are internal parts from now on. (and thus not part of the Open Specification)
- The two Core GEs are renamed to Gateway/Backend Device Management GE. Core GE would suggest that this GE is not replaceable. This is not true however. Official FIWARE does provide these elements, but the point of a GE is to be replacable by specific enablers. In case a UC project wants to replace them with solutions that uses EPC-Global, OGC SWE, etc, they can do it with connecting to the Things Management GE via the Device Data API.
- We are not officially support IETF Core. We completely understand that currently the gateway does expose IETF Core and it needs to be translated, however, currently that is an implementation detail, and thus should not be part of the functional architecture.
- The Pub/Sub broker from WP6 was missing from the architecture (as also raised by NEC) we added it without any change from the previous architecture.
We will start a new branch on the private wiki with the new architecture. It is opened here:
https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FiwareDeliverableStreamlinedD2.3IoT
When the description is complete, we will switch.
Best,
Dénes
From: ext Juanjo Hierro [mailto:jhierro at tid.es]
Sent: Friday, April 27, 2012 1:32 PM
To: Bisztray, Denes (NSN - HU/Budapest)
Cc: Farkas, Lorant (NSN - HU/Budapest); Thierry.nagellen at orange-ftgroup.com<mailto:Thierry.nagellen at orange-ftgroup.com>; jhierro >> "Juan J. Hierro"
Subject: Re: PLEASE READ Re: IoT Chapter streamlined architecture
Gentlemen,
Thank you for the VERY constructive discussion we have had.
It would be great if you can circulate some sort of minutes of the discussion together with an updated version of the Architecture picture asap. It would be rather helpful in order to share with the rest of the IoT team and provide an starting for the necessary update of the Architecture description on the public wiki.
Best regards,
-- Juanjo
-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro
FI-WARE (European Future Internet Core Platform) Chief Architect
You can follow FI-WARE at:
website: http://www.fi-ware.eu
facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
twitter: http://twitter.com/FIware
linkedIn: http://www.linkedin.com/groups/FIWARE-4239932
On 27/04/12 11:41, Bisztray, Denes (NSN - HU/Budapest) wrote:
We are available from 12:15. Thierry is on holiday so he will not join.
Conference details:
NSN Voice Conference information
58465 / 1628
Making a conference call
France +33 17 061 7813 (PRIMARY) or +33 14 915 1553
Germany +49 89 5159 43800
Spain +349 1187 5929
Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299
Switzerland +41 44 279 7943
Webex details:
Topic: Streamlined Architecture discussion
Date: Friday, April 27, 2012
Time: 12:15 pm, Europe Summer Time (Berlin, GMT+02:00)
Meeting Number: 709 636 546
Meeting Password: cool
-------------------------------------------------------
To start the online meeting
-------------------------------------------------------
1. Go to https://nsn.webex.com/nsn/j.php?ED=210017087&UID=503765542&PW=NZTU4OTFlYWE5&RT=MiMyNQ%3D%3D
2. Log in to your account.
3. Click "Start Now".
4. Follow the instructions that appear on your screen.
From: ext Juanjo Hierro [mailto:jhierro at tid.es]
Sent: Friday, April 27, 2012 11:34 AM
To: Bisztray, Denes (NSN - HU/Budapest)
Cc: Farkas, Lorant (NSN - HU/Budapest); Thierry.nagellen at orange-ftgroup.com<mailto:Thierry.nagellen at orange-ftgroup.com>
Subject: Re: PLEASE READ Re: IoT Chapter streamlined architecture
Let's have the confcall at 12:00 and try to solve this out. Please circulate the bridge details.
Best regards,
-- Juanjo
-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro
FI-WARE (European Future Internet Core Platform) Chief Architect
You can follow FI-WARE at:
website: http://www.fi-ware.eu
facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
twitter: http://twitter.com/FIware
linkedIn: http://www.linkedin.com/groups/FIWARE-4239932
On 27/04/12 09:47, Bisztray, Denes (NSN - HU/Budapest) wrote:
Dear Juanjo,
Thanks for your long email and also your time for looking at the architecture properly. The topic is complex, if you don't mind I start in medias res. I noted you specific requests on changing names and connections, however these can be implemented only if we come to an agreement on the greater picture.
As far as I understand your point (just to make sure we on the same line), you can imagine a backend without IoT resource-level functionality (since you don't think it is core functionality). This would work in such a way, that the gateway is working as a kind of cache, that collects data from the devices and then it publishes it towards the backend via NGSI. Then the backend Thing-level GE processes it.
Unfortunately for me this model is not working for two reasons:
1. This possibly works only when there is one gateway and all the sensors of the world is connected to it. When you have multiple gateways, you need operation and management functionality towards the gateway which cannot be done via NGSI. In my opinion core functionality is such functionality that is extremely essential to the system. The scenario of having one gateway proves that the system may work without a resource-level component on the backend, but this extreme case is a bad example. In my opinion this is not what the gateway is designed for.
2. We discussed several times and agreed, and I'm unhappy that this topic comes up again, that the gateway is not a cache. Neither Ericsson, NSN or Orange agrees with this. If you have only NGSI functionality you not only cannot manage the gateways, but also you cannot perform FCAPS functionality on the devices themselves. NGSI cannot do this.
- That extension interface is basically used for the Things Management GE to obtain direct resource-level information from the Core GE. Then the Things Management GE processes it. This is result of the original two-level exposure model.
- I do not assume the Things Management GE to contain the resource-level resource-management functionality. That would make that GE a big monolith which we could may well call as IoT chapter GE.
Also it is problematic that this OGC-gateway topic comes up again. We agreed that the gateway and backend communication should be standardized, and should not have a protocol adapter. We had an agreement for long time, I have no idea why you bring this topic up.
We can have a confcall at 12:00, if you agree I send the conference details.
Best,
Dénes
________________________________
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
________________________________
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
________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1913 / Virus Database: 2411/4959 - Release Date: 04/25/12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120501/65e870dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unis-proposal-TM-GE-querying.png
Type: image/png
Size: 42185 bytes
Desc: unis-proposal-TM-GE-querying.png
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120501/65e870dd/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy