[Fiware-iot] gateway architecture

[Bisztray, Denes (NSN - HU/Budapest)]

Hi Ricardo,

 

Sorry for mixing up the order, but it makes more sense this way:

 

2) We assume to have an application layer within the gateway as well as the device itself, not just at the backend-level. In order to have applications on the gateway, we need to have an interface for that. This is the functionality that IDAS seems to lack (at least as far as I understood). And OGC SWE altogether. 

 

1)This seems problematic. You support only OGC SWE functionality, i.e. sensor measurement gathering and sensor tasking. When asked on the weekly IoT meeting you said IDAS supports the buffering of sensorial data in an offline case. But if we look back at the previous point, this is far from satisfactory, an autonomous application layer on the gateway would be necessary.

 

3) What are these interface capable of? 

 

Best,

Dénes

 

From: ext Ricardo de las Heras [mailto:rheras at tid.es] 
Sent: Friday, December 09, 2011 5:03 PM
To: Bisztray, Denes (NSN - HU/Budapest)
Cc: fiware-iot at lists.fi-ware.eu; gianpiero.fici at telecomitalia.it; sabrina.guerra at telecomitalia.it; thierry.nagellen at orange.com
Subject: Re: gateway architecture

 

Dear Dénes,

interesting questions here, in our case from IDAS:

1) Tthe gateways provides translation capabilities from the broad range of protocols, unifying them to a SensorAPI (OGC SensorML + O&M).
I attach you a picture with this concept. So the gateway is out of the platform.

2) I don't understand your exposition, why you speak about an interface between the Gateway and the application layer? I don't agree this interface.

3) Yes, we have interfaces from IDAS to the botton layers (Gateway) and with the upper layers (applications). Interfaces are public of course.

4)  Good question, indeed I had already made this question. From my point of view that would be the T5.1 scope, isn't it? Are you asking about name of partners too:) ?

have a nice weekend,
RHer at s.


Bisztray, Denes (NSN - HU/Budapest) wrote: 

Dear all,
 
Although the asset selection is still questionably finished, it would good to clarify the architecture around the gateways as well as the internal APIs.
 
1. Where do we have the gateway functionality?  (i.e. microDB, instantaneous and real-time data, data aggregation filter, etc. )
        - every asset implements the gateway functionality on its own, and provides an API that the gateway-northbound interface and application implementation can harness.
 
        - the assets only do protocol adaptation, the gateway functionality comes from outside (possibly one of the assetes)
 
2. We need to provide two interfaces within a gateway. One is the ETSI M2M interface that communicates with the backend, and another interface for the application layer within the gateway. How will they communicate with the assets?
 
3. Backend API problems. The IDAS which seems to be selected for all GEs within resources management (is it?). It needs to have an internal interface for communicating with both the northbound and southbound interface. When will it be public? Or have a service bus? This one needs to be worked out.
 
4. Who implements the ETSI M2M interfaces? 
 
Best,
Dénes 

 

-- 
-------------------------------------
Ricardo de las Heras
M2M Research Technological Specialist
E-mail: <mailto:rheras at tid.es>  rheras at tid.es
Phone1: (+34) 983 367625
Phone2 OCS: (+34) 91 31 29511
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/20111212/9c223cf2/attachment.html>