[Fiware-iot] Discontinuous connectivity

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

Dear All, 

Reviewing the architecture, I found a little inconsistency with the management of disconnected device. There are two points that needs further refinement.

1.	Workflow of commands from the northbound

Currently there are two versions in this topic.

Telecom Italia version:
-	The device command from the exposure GE is forwarded to the discontinuous connectivity management GE, if the device is online then the discontinuous connectivity GE forwards it to the abstract protocol layer on the southbound.

NSN and NEC version
-	The exposure GE probes the discontinuous connectivity GE if the device is online or not. If it is, then it sends the command directly to the abstract protocol layer. In case the device is offline, then goes to the discontinuous connectivity GE, which stores it in the connectivity cache.

I would be good we could resolve this issue as soon as possible. In the TI version the discontinuous connectivity GE suffers from a higher load as all commands goes through it, also the checkConnection function becomes reasonably unnecessary as all commands directly goes to the discontinuous connectivity management GE which does an internal check.

2.	Device goes offline or becomes online again.

Although it is not explicitely stated, I assume it is the abstract protocol layer is responsible for noticing that a device disappeared or reapperad again. In the simple setup, I assume it notifies the discontinuous connectivity management GE that a device is appeared again. However this is not written down anywhere. In fact the whole device-level resource management GE is missing on the gateway.

I understand that currently the mobility management component is not implemented, and since we don't have thing-level management, this is not an extremely important component. Still, it would be nice to take a note about the component.

Best,
Dénes


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120220/1ff396aa/attachment.html>