Hi Thiago, thanks for your feedback!
>> 2. can i use a constrained device that is actually an 6LoWPAN edge >> router as a bridge to an IOTivity cloud server (e.g. to forward requests >> to the cloud and vice versa) ? > To make sure we're using the same terms: by edge router, do you mean a border > router (6LBR)? If not, what do you mean? Sorry i used the wrong term here. I mean an 6LBR that is running as an IoTivity-constrained node besides its functionallity as a border router. Services in a cloud shall be able to use Ressources that are located in a 6LoWPAN network. The 6LBR could have a websocket or something like that in order to be reachable from the cloud, but the devices behind the 6LoWPAN should not. So the cloud can communicate directly to the 6LBR, but not to the devices behind it in the 6LoWPAN. So does IoTivity-contrained support kind of a forwarding mechanism for this? As i can see from the answer, this can be implemented on top of IoTivity-constrained, but there is no direct builtin support, right? >> 3. can a constrained node be used to manage service discovery for other >> constrained nodes? > Sure, but again, what's the point? A constrained node is called that because > it is constrained: little RAM, little ROM and/or little battery capacity. If > it is managing things for others, it's not really constrained. > > But IoTivity Constrained can be deployed on a non-constrained OS and device > (it runs on Linux). It's just not what it's designed for. I think i need something that is sitting in between. There are Cortex-M controllers with up to 512KB - 1MB flash and 128KB Ram. That is enaugh to implement a lot of functionallity, but is still very constrained in comparison to Linux enabled boards.
