[Fiware-iot] gateway architecture

[Jan Höller]

Hello Ricardo,

2) We cannot only view a gateway as a protocol translator. Gateways are generally deployed for several reasons. If considering legacy protocols (e.g. ZigBee HA), this is a complete protocol stack including the application layer. A gateway can handle this in two basic ways, either the gateway terminates up to the networking layer and ships the payload (app level stuff) transparently to the backend for further processing (e.g. the HA app level profile in the case of ZigBee), or you terminate the entire stack in the gateway and provides the necessary app level "interworking" inside the gateway. Another reason for deploying gateways is to shield sensor/actuator devices that operate under constraints, e.g. battery powered. Asynchronous communication with the devices are then provided  by the gateway which necessarily means that sensor data is cached locally in the gateway, and potentially also providing more metadata or contextual data to the actual sensor reading. Furthermore, in certain deployment scenarios, a gateway is even more of a local "semi-autonomous" application server that can execute localized services e.g. data aggregation, local sensor-actuator control loops etc. A typical example is building automation where services execute locally and not always means that every event needs to be sent to the backend for consultation. So, I see that there are a number of reasons why a gateway generally speaking is more than just providing protocol interworking on the communications layer.

When it comes to protocol translation/adaptation, this too is needed on different places in the topology. Gateways are traditionally the term used for doing this in localized environments, and from an IoT perspective typically operating out of WSAN environments running on top of 802.15.4. In these gateways, protocol adaptation is needed. Furthermore, protocol adaptation can also be taking place in the backend/cloud environment. Now, do we use the same assets depending on where in the topology we look at this functionality to take place? In FI-ware IoT, I have not seen this being discussed. Secondly, will the IoT backend in Fi-ware do any more termination than the ETSI M2M mId southbound  (on the "lower" level)?

Best regards,  Jan

From: Ricardo de las Heras <rheras at tid.es<mailto:rheras at tid.es>>
Date: Mon, 12 Dec 2011 12:20:59 +0100
To: "Bisztray, Denes (NSN - HU/Budapest)" <denes.bisztray at nsn.com<mailto:denes.bisztray at nsn.com>>
Cc: "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: Re: [Fiware-iot] gateway architecture

HI Dénes,

2) I don't understand why we assume to have an application layer within the gateway, of course it is feasible if you increase the complexity of it, for us in Telefónica it is out of the scope of our platform IDAS and so far we don't have any type of requirement that implies these type of decisions, so that's the main reason. And in this way you know our platform is for example included at this time in several important projects like SmartSantander<http://www.smartsantander.eu>.
You referenced too in the last call the possibility of providing direct communication at the Gateway level between resources. From my point of view this is the same thing, you can even include a more complex HUB (device's concentrator, as previous step to the gateway) and to manage everything there. But for example maybe you should have to manage different protocols, different standards, security issues, etc. that obviously increase the complexity and costs of those elements.

1) We support any type of sensor measurement technology and underlying communication protocols, but obviously we unify them to a common language at the gateway level, and this is the well known OGC, currently well supported by the IoT community.

3) Basically as I have already explained: a data format adaptation: to translate device specific Messages into SensorML-based Messages and vice versa. This provides an abstraction level to the platform making it suitable for integrating different sensor technologies. So, an especific adaptor module is needed for including new protocols.
And second: Also it allows sending commands to Actuators.

Finally, answering you to another email, YES, IoT-A is responsible for the Discovery and Resolution of Things.

Anyway, if you have any other question or additional clarification please let me know,
thanks,

best,
RHer at s.

Bisztray, Denes (NSN - HU/Budapest) wrote:
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<mailto:fiware-iot at lists.fi-ware.eu>; gianpiero.fici at telecomitalia.it<mailto:gianpiero.fici at telecomitalia.it>; sabrina.guerra at telecomitalia.it<mailto:sabrina.guerra at telecomitalia.it>; thierry.nagellen at orange.com<mailto: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<mailto: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

--
-------------------------------------
Ricardo de las Heras
M2M Research Technological Specialist
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
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