[Fiware-iot] IoT Chapter streamlined architecture

[Jan Höller]

Hello,

First of all, I think this is a good and appropriate step forward.

Some comments related to the gateway part.

 1.  It would be good to add devices below the gw and connected to the different circles. Devices are more or less out of the scope, but they should be there.
 2.  I think there should be a direct line between the Backend and a device – not all devices will connect via a gw.
 3.  You have arrows between RD and RM in gw, but no other lines inside the core GE. Either you indicate lines between all boxes, or you remove all lines inside a GE.
 4.  I do not see why there is a line between Interface and southbound ETSI M2M circle.
 5.  I propose to move Security GE to the left or right of the core GE and not below.
 6.  I suggest to add a line between Protocol Adapter and Plugin Architecture that contains a circle (i.e. an "open" API). This API is needed for integration of third party protocol adapters. Perhaps PA should be in plural, i.e. "Protocol AdapterS"?
 7.  I suggest to add a northbound Protocol Adapter in the gateway outside the Core GE but within the gateway. This PA should have a circled line to the backend perhaps stating ETSI M2M (we have no such assets as we are all painfully aware of unless somebody has some news). This PA should also have a line to the Core GE containing a circle for the same reason as in 6 above.
 8.  There needs to be a gateway external interface towards DH GE, at least for setting filters etc in CEP. This should be a line with a circle interface. I guess the interface will be proprietary.
 9.  It can be discussed whether there needs to be an open interface towards Local Storage and whether LS should be in DH GE or in Core GE. Disc Conn in the Core GE has to have means for handling off-line devices which implies various types of storage. This storage is perhaps more of a system internal cache than an appropriate open data base requiring an open interface.
 10. What Advanced Connectivity will be in the first release?
 11. How do we view Remote Device Management? Via ETSI M2M or via a separate interface? The architectural principle of "Separation of Concerns" would make me argue that it should not be part of ETSI M2M, but a separate interface. Following this, as RDM is not specific to IoT, I would also argue that it is not part of the IoT chapter. It should be part of I2ND, but I haven't checked if that is the case.

How come there is not CEP or Storage in the Backend?

Jan

From: "Bisztray, Denes (NSN - HU/Budapest)" <denes.bisztray at nsn.com<mailto:denes.bisztray at nsn.com>>
Date: Mon, 23 Apr 2012 09:56:04 +0200
To: "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>>
Cc: Jan Höller <jan.holler at ericsson.com<mailto:jan.holler at ericsson.com>>, Jakob Saros <jakob.saros at ericsson.com<mailto:jakob.saros at ericsson.com>>, "thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com>" <thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com>>, Ernoe Kovacs <Ernoe.Kovacs at neclab.eu<mailto:Ernoe.Kovacs at neclab.eu>>, Stephan Haller <stephan.haller at sap.com<mailto:stephan.haller at sap.com>>, "Farkas, Lorant (NSN - HU/Budapest)" <lorant.farkas at nsn.com<mailto:lorant.farkas at nsn.com>>, "jhierro at tid.es<mailto:jhierro at tid.es>" <jhierro at tid.es<mailto:jhierro at tid.es>>, Fici Gian Piero <gianpiero.fici at telecomitalia.it<mailto:gianpiero.fici at telecomitalia.it>>, Guerra Sabrina <sabrina.guerra at telecomitalia.it<mailto:sabrina.guerra at telecomitalia.it>>
Subject: IoT Chapter streamlined architecture

Dear all,

As mentioned in the previouw weekly meeting, the architecture is getting incomprehensible. This is painful for two reasons.

1.       We have to give educational sessions to the UC projects. If we ourselves don’t completely understand the architecture, we can’t give a proper presentation about it.

2.       The open specifications are coming closer. We have way too many GEs compared to other projects, and there are way too many interfaces between these GEs. We supposed to give a fully specified description for every single circle on the FMC diagram.

As Gian Piero felt right, the architecture does indeed needs rationalisation.
The current GEs are just modules and are not functional outside their context. Thus I created a proposal for a more streamlined architecture.
I uploaded to the project svn: https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/FMC/IoT-Streamlined.graphml
Also attached to this message.

A short presentation on the fundamental changes. We need to discuss this on the Wednesday session, thus I sent it ASAP for you to be able to have a detailed look at it.

The asset selection does not change, as you will see, they will seem more natural.

We have only 5 GE:

1.       Core Functionalities

2.       Things Management

3.       Advanced Communications

4.       Security

5.       Protocol Adapter

Core Functionalities GE
As its name suggests this contains the core functionality of the Backend or Gateway. It includes device-level resource management. The implementation of the northbound and southbound device-level interfaces. Core communication functionality with discontinuous connectivity features as well as a plugin architecture that allows developers to further extensions. Important that this is the basic building block of our system, this is a mandatory component. However if we have this component, the system is already functional.
On the gateway this is basically “the gateway”, i.e. the Ericsson and TI Gateway. On the Backend this WAS the TID asset, however now I have no idea who will do this.

Things Management GE
This deals with everything Things-level. We have the IoT Broker, Configuration Management, Configuration Repository and Inference Engine within this GE. It uses the information of the Core Functionalities GE to optain information on the resources.
Interfaces: only the things-level extension interface that works on the top of the Core’s Resource Management. As a vision this interface should be generic enough to use the Things Management GE on the top of other entities that can be uplifted to a things-level functionality.
This supposed to be the NEC and University of Surrey asset.


Advanced Communications GE
This GE gives advanced communications capabilities, that are not part of the Core functionalities. Mobility Management, Session Management, Traffic Flow management, Quality of Service. This works as an “official” plugin for the Core’s communication plugin architecture.
This has no current asset selected, as there was no asset for this before.

Security GE:
PEP, and everything security. Since this has one interface, it can use standards for the security interface. Need to be checked with the Security WP.

Protocol Adapter
Same as before. It translates the various device-level protocols to the official FIWARE IoT device-level protocol, which is ETSI M2M at the moment.

I understand the implications of changing the architecture today. But we need something that we can work with as soon as possible, otherwise we will not able to deliver anything at all.

Best,
Dénes