[Fiware-iot] gateway architecture

[P.Barnaghi at surrey.ac.uk]

Thanks Ricardo. As I mentioned I am still not sure if a new parser will solve the issues;

- Payam

________________________________
From: Ricardo de las Heras [mailto:rheras at tid.es]
Sent: 12 December 2011 12:59
To: Barnaghi P Dr (Electronic Eng)
Cc: denes.bisztray at nsn.com; fiware-iot at lists.fi-ware.eu
Subject: Re: [Fiware-iot] gateway architecture

OK Payam,
thanks for your clarifications, we had already discussed it in a previous threads of emails,
the option of a new parser sounds good but we have to go more in deep with it, clarifying the different options we have.

br,
Ricardo.

P.Barnaghi at surrey.ac.uk<mailto:P.Barnaghi at surrey.ac.uk> wrote:

Hi all,



My reply is only related to the last part of Ricardo's email: Discovery and Resolution of Things from IOT-A. We are involved in this task in IoT-A and I would like to add some clarifications to this:



Discovery and Resolution of Things in IoT-A is planned based on the proposed information model for entities and resources in IoT-A. The entity and resource descriptions are in RDF format and are represented according to the IoT-A model. A software agent parses these descriptions and extracts the information for indexing. A machine learning method then applies probabilistic machine learning based on LDA approach to create a low-dimensional specification of data that is transformed in vector-space model and similarities are measured based on a vector similarity measure between query vector (again encoded using a similar method) and transformed descriptions.



However, if the resources are stored and/or represented differently with different format and different set of attributes, the parser won't be able to extract the required information and I am also not sure even adapting a new parser could still help extracting the required features. The repository and description format will also affect this.

Again, this is related to the work that we do in IoT-A discovery and perhaps other IoT-A partners can provide more information.



Thanks,

Payam







________________________________________

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 Ricardo de las Heras

Sent: 12 December 2011 11:21

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

Cc: 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20111212/cb3e142a/attachment.html>