Dear Jan, I am sure we can discuss all these within the 1st agenda point in our meeting today. Br, Lorant -----Original Message----- From: ext Jan Höller [mailto:jan.holler at ericsson.com] Sent: Wednesday, May 02, 2012 9:46 AM To: Bisztray, Denes (NSN - HU/Budapest); thierry.nagellen at orange.com; Farkas, Lorant (NSN - HU/Budapest); ext Juanjo Hierro; fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] IoT Chapter streamlined architecture Dear Denes, A few questions and comments in return. * Does NEC provide the DH GE in the Gateway, and hence the NGSI interface? * Data Handling API comes from Gateway Device Mgmt GE (previously Core GE). What does it look like? Previously, Ericsson said to deliver a core Gw capability. Does this mean that the Gw DevMgmt GE can be omitted from Fiware and delivered by a use case project? Who will do this for the first integration, and what devices will be supported? * Who will deliver ETSI M2M compliant devices for the first release? * Who will deliver the ETSI M2M interface for the first release? * I also argue that having published interface to the "core" gateway GE is a good thing since it makes integration tasks with other assets easier, and that having that very simple is beneficial. Not relying on the fact that IETF CoRE exists and making good use of it is a bad decision. I note that our submission of a proposed modified FMC diagram on the Gateway part was not accepted, or did you not get it? I was in response to an action item from last week's meeting. I also think it is very unfortunate that you have separate meetings not involving those partners who are supposed to deliver assets. Jan From: "Bisztray, Denes (NSN - HU/Budapest)" <denes.bisztray at nsn.com<mailto:denes.bisztray at nsn.com>> Date: Friday, 27April, 2012 2:02 PM To: "thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com>" <thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com>>, "Farkas, Lorant (NSN - HU/Budapest)" <lorant.farkas at nsn.com<mailto:lorant.farkas at nsn.com>>, ext Juanjo Hierro <jhierro at tid.es<mailto:jhierro at tid.es>>, "fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>" <fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>> Subject: [Fiware-iot] 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
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy