Hi @Vaibhav , I would suggest that there is an arguable industry preference for the device<->cloud communication to be MQTT based, if you look at the IoT offerings from major providers. These all expect MQTT (if not using HTTP, which is often a no-go for very constrained devices):
Its a different story when talking about device-to-device communications, probably because of the lack of a reliable broker (and the complexity of configuring/guaranteeing one). IoTivity and the Open Connectivity Foundation standards (what the Nexus Channel Core app layer is built upon) uses CoAP for device to device communication.
I’m assuming both are easily implemented in the embedded space?
CoAP enables use on more constrained devices than MQTT (CoAP is connectionless for starters, but MQTT using TCP also increases resource needs beyond what constrained MCUs can typically support). So I can definitely see the case for making a more powerful gateway device able to speak MQTT to the cloud (to maximize compatibility with many different providers), while using a CoAP based protocol to handle local data transfer to constrained devices. So I’d suggest that MQTT might not be as easily implemented (or practical) in deeply embedded devices with <= 32kB RAM or <= 64-128kB Flash, for instance.