Summary:
Since the emergence of numerous types of smart devices in the market, there is a growing demand for a flexible platform which can facilitate the process of discovering,assembling and connecting with heterogeneous devices in order to provide better user experience to the end users. Current technologies only provide these capabilities with the registered devices on servers specific to those technologies. In this study, a mobile application platform IoT-Map is provided which dynamically discover these devices at the run time providing better user experience. IoT-Map leverages the open source based name server called Oliot-ONS to perform ID resolution for these devices to check for the available services and then to download the drivers for these devices from online repository. Moreover IoT-Map provides libraries for the developers using which they can build IoT applications easily without consideration of underlying connectivity protocols with the smart devices.
The goal of this study is to address following issues prevailing in mobile applications:
1) Inability of current mobile applications to assemble surrounding heterogeneous devices dynamically.
2) Existing studies assumes the existence of a home server to manage all the devices
3) Using a server for name resolution designed only for registered devices.
The main contributions of this study are :
1) Iot-Map, a mobile application platform which can be used to dynamically discover, deploy and assemble devices.
2) Leveraging an international standard based ID resolution.
3) Libraries for developers to build applications easily.
4) A user interface for the end-users to provide greater flexibility to decide which devices to assemble.
Strengths:
1) Authors discuss the design considerations for the IoT-Map platform in great detail in Section II. One very nice principle used was to separate platform independent and domain specific modules to provide flexibility for developers and device manufactures. Moreover the study provides pre-defined interfaces to the developers used to access smart devices and these are explained clearly with examples.
2) One very strong point of this study is IoT-Map architecture. The architecture is designed in a way that both users and developers can utilize its flexibility. It provides uniform APIs for developers without underlying connection protocols and GUI tool for the users to assemble their own applications at run time.
3) The architecture supports discovery of the heterogeneous devices dynamically and then providing with the corresponding services to the user. Its applications can interact with multiple and varied devices at run time without a need to provide these services at the implementation time.
4) The name and ID resolution is done by querying an online ope source repository instead of having a dedicated server which can only fetch registered devices.
5) The study is supported by case studies and demo applications on multiple smart devices in addition to the evaluation performed on the overhead due to IoT-MAP platform. The analysis shows the usefulness of the platform compared to running applications as Android activity.
Weakness:
1) Case studies are conducted on the GUI and application APIs. However there is no quantitative analysis actually done on real users to justify the usefulness of the paper.
2) One of the important weakness of this study is lack of implementation details. There is only one very small section given on Implementation detail of the platform from which it is hard to justify the reproducibility of the paper.
3) The experimental section lacks comparisons with other approaches like Ambient Dynamix mentioned in the Related Work section. It is possible that even with Dynamix server may have a larger number of registered devices than the open ssource based server. The authors should provide a metric for such a case.
4) The analysis of overhead shows that Iot-Map does not have a significant advantage over others until the number of connected devices are large. This may not be applicable in real life where smart devices are restricted to 3-4 in number.
Discussions:
1) One of the motivations of the paper was to differentiate the task of application developers and device manufactures. Using this platform, developers dont have to worry about underlying connection and their implementations. However as authors pointed out, this task now has to be performed by device manufacturers. Can this trade-off be avoided?
2) Whether the existing interfaces are sufficient to handle a range of smart devices and is it even possible to design a generic API which can handle all the devices?
3) This study assumes that the external open source repository containing service bundles is well established and widely used. Is this really true?
Very nice description of strengths and weaknesses. Discussion point #2 is interesting -- can you give any counter examples?
ReplyDeleteWell I first thought of Google Home and Amazon Echo. I believe these smart devices have complex functionalities when compared to devices like Philips Hue. I believe these devices will be difficult to assemble in the proposed framework. Although this is just my intuition.
ReplyDeleteIs the problem of discovering devices on a network (specially wifi) solved? I know the paper discusses some details in section 4 but there are no exact confirmations in this regard. I know that 2-3 years back most available tools could not accurately identify even android devices on the network (they only came up as running the Linux os). This task required the intervention of every smart device manufacturer - is that feasible here?
ReplyDeleteI believe this study is more about scanning and discovering as opposed to automatic discovery. The task of discovery still remains the open problem
ReplyDelete