[Fiware-iot] IoT Communication: new version of the architecturedescription

Farkas, Lorant (NSN - HU/Budapest) lorant.farkas at nsn.com
Wed Jun 8 19:55:36 CEST 2011


Hi Sabrina,
 
Thanks for the submission. The reason for the pending state was that you were not registered to the IoT project but only forge. Now I registered you to the project so whatever you submit will be visible.
I looked for Gian Piero as well, he seems not to be registered to forge, so Gian Piero please register there.
As for the content of the submission we will review this with Thierry soon and give feedback.
I would like to ask you to submit to forge the "master copy" of your architecture figure (the ppt) so that if we want to propose changes, we don't need to redraw it.
 
Thanks & Br,
 
Lorant

________________________________

From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Guerra Sabrina
Sent: Wednesday, June 08, 2011 6:18 PM
To: 'fiware-iot at lists.fi-ware.eu'
Subject: [Fiware-iot] IoT Communication: new version of the architecturedescription



Hi Thierry,

we just tried to submit on Fusion Forge a revised version of our contribution (IoT Communication-Architecture-Description-v0.2.doc) but I do not know if it is available (Fusion Forge says: pending state (need validation)).

 

We see you changed the architecture picture we sent you. Some changes are ok, but we have comments on other, so we modified the picture in the contribution, and we updated the description reflecting the new picture, and we will explain in this e-mail the differences between your picture and ours.

 

You put an arrow between Connectivity Management and IoT Resources Management and between Content Control and IoT Resources Management, in this way it seems a message coming from a Device or a Gateway can be passed from the Front-end either to the Connectivity Management block or to the Content Control block and from there can be passed to the IoT Resources Management, like if there are 2 different paths leading from IoT Communication to IoT Resoureces Management. While we think all the messages coming from a Device or a Gateway are received by the Front-end block and then passed from the Front-end to the IoT Resources Management GE. The other blocks (Connectivity Management and Content Control) group functionalities that are used by the Front-end on the traffic coming from, and/or going to, Devices and Gateways. For this reason we put a single arrow between the Front-End  and the Iot Resources Management deleting the other two between Connectivity Management and Content Control and IoT Resources Management (and also the arrow between Connectivity Management and Content Control, since there are no interactions between these 2 blocks).

We also deleted the interaction with the IoT Data Handling GE, since we believe the Data Handling will be used only by the IoT Resources Management. Well, at least we cannot think of a case where IoT Communication should access directly to the resources data.

Finally we changed the aspect of the arrow between Interfaces to the Networks and the Front-end and of the 2 blocks Access Policy Control and Quality of Service Control. The first one to show that the interaction between the Front-end and the Interfaces to the Network GE is not at run-time, ItoN will define the protocols that will be used in the communication between the platform and the Devices and Gateways, but these protocols will be implemented directly in the Connection Protocol Adapters. The second one to show that the 2 blocks Access Policy Control and Quality of Service Control can be implemented either in the IoT Communication or in the IoT Resources Management, if implemented in the IoT communication the controls will be applied in advance and not allowed messages will be rejected early, otherwise if implemented in the IoT Resources Management all the traffic will be passed to the IoT Resources Management that will provide to apply the controls. Of course if these controls (access rights and quality of services) have to be applied also on traffic coming from applications (besides traffic coming from devices and gateways) it is more convenient implement them in the IoT Resources Management.

 

We hope we have been clear in my explanation, in any case please feel free to ask for clarifications.

 

Bye,

Sabrina and Gian Piero

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

 Rispetta l'ambiente. Non stampare questa mail se non è necessario. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110608/294b5fb6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia.jpg
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110608/294b5fb6/attachment.jpg>


More information about the Old-Fiware-iot mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy