Hello Denes As discussed in the telco, please find the proposed update of the FMC diagram wrt the gateway. The rationale behind the change is the following. I have moved the device interfaces/circles to be outside of the gateway since they do not represent (software) APIs but interfaces specified by a protocol (stack). I make a distinction between a software architecture or sw component oriented view and a functional view of a gateway. A software view points towards an implementation. I think the FMC diagram should capture the functional view rather than the implementation view. The only thing that is dictating the implementation is the interfaces and APIs we have. These represent "fix points" that we need to have for various reasons (openness towards systems integration being one). So that is the reason for having a protocol adapter in the gateway towards the backend as well. This is a mapping of the internal API (denoted IETF CoRE) towards the ETSI M2M interface, as well as the protocol itself. This is a comment towards point 4 in the previous mail below. The interface as such (ETSI M2M) is not part of the Gateway Core GE in our opinion. We need to make a clear separation of protocol logic from application logic. The Core GE contains application logic that can be bound to different protocols (or binding components). Hence the representation of the actual interface instance should be kept separate. Furthermore, by having also the gateway internal APIs as "circles" we ensure that we have published APIs that can be used for any partner to do a proper systems integration activity of a specific protocol. Especially since we do not have ETSI today, this API is important. And it allows us to bind the gateway to any other protocol if so desired at a later stage. Regarding comment below, a circled API also ensures a systems integration point towards legacy or any other protocol (and also a separation of the binding component from application logic southbound). Also, the capabilities exposed by the gateway towards the backend is "richer" than the capabilities exposed by an individual IoT device towards the gateway. This is because the gateway typically host own IoT resources as well (storage, processing, CEP etc are all representing different resources than those by the devices themselves). So, an ETSI M2M interface between the device and the gateway is different from an ETSI M2M interface between the gateway and the backend. Your proposal of an interface with lines going both towards the gateway AND the devices is misleading and also wrong from a functional perspective, I would argue. Lastly, on the device management topic, I am not familiar enough with M2M ETSI capabilities on "device commands" as you call them, but I doubt that ETSI M2M provides the same capabilities as e.g. TR069. Hence, for any deployable "complete" gateway, there will be one IoT interface and one DM interface, e.g. ETSI M2M and TR069. Now, considering legacy devices, as some of these legacy protocols contain bundled capabilities for handling both device level issues (DM) and sensor/atuator capabilities (IoT), I feel that we might need some more discussion on the relation to I2ND wrt Device Management. I don't know if this has been discussed with the I2ND chapter in the past, or if there is an agreement in place. I hope I managed to explain my thinking on this topic. Please provide your comments in return. Best regards, Jan On 25042012 9:45 AM, "Bisztray, Denes (NSN - HU/Budapest)" <denes.bisztray at nsn.com> wrote: >Hi Jan, > >Thanks for your detailed reply, my comments are inline: > > 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. > >BD: Agree, Done. > > 2. I think there should be a direct line between the Backend and a >device - not all devices will connect via a gw. > >BD: Agree, will do ASAP. Needs major rearrange. > > 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. > >BD: Agree as well, removed the lines. > > 4. I do not see why there is a line between Interface and southbound >ETSI M2M circle. > >BD: The interface supposed to mean the implementation of the interface. >The circle is "the" interface connection between the elements. The >implementation of south and northbound ETSI M2M is possibly the same >modul. > > 5. I propose to move Security GE to the left or right of the core GE >and not below. > >BD: Agree, Done. > > 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"? > >BD: I assumed here that there is an official protocol on the southbound >of the gateway. This is ETSI M2M currently, but may be turn out to be >IETF Core. The protocol adapters will use this protocol to translate to, >and no to another protocol that is not the official, but used within the >system. > > 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. > >BD: I believe that is not really an adapter. That is the interface module >within the Core GE. >Apparently, we are close to finishing an ETSI M2M device with important >core functionalities as well as protocol implementation on the >centralized backend/gateway. > > 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. > >BD: Agree completely. Added. > > 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. > >BD: The gateway is based on your, TI and Orange assets. Obviously the >principle is not to tailor the architecture to a specific asset, but >still real-world solution helps to understand the architecture better. I >would like to assume more of a coordinator role in such low-level >discussions, feel free to propose changes and discuss it with TI and >Orange. > > 10. What Advanced Connectivity will be in the first release? > >BD: Nothing :). It is the union of those Service Control GE and >Connectivity Management GE capabilities that I thought not to be core >functionality. It was not assumed to be delivered 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. > >BD: ETSI M2M does provide device commands. I assumed we use it. Feel free >to propose different solution. > >How come there is not CEP or Storage in the Backend? > >BD: that is the task of the Data and Context Management chapter. > >Best, > >Dénes > > >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-Streamli >ned.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 -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-Streamlined.graphml Type: application/octet-stream Size: 85355 bytes Desc: IoT-Streamlined.graphml URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20120426/70c9b049/attachment.obj>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy