# Device Management and Data Transport in IoT Networks Based on Visible Light Communication
## 2 Related Work on VLC and IoT  
The VLC standard was developed by IEEE 802.15 Task Group 7 in 2011 [9]. The VLC standard defines the PHY and MAC layers for short-range optical wireless communication using visible light. The specification classifies devices as infrastructure, mobile, and vehicle, and defines the MAC topologies: peer-to-peer, star, and broadcast. The infrastructure device is a fixed coordinator and is unconstrained, and has a sufficient power source. The mobile device is a constrained device which has a limited power supply, a weak light source, and a short visibility range. The vehicle device is an unconstrained device that has a moderate power supply, intense light source, and long visibility range. In the peer-to-peer and start topology, there is a coordinator device, which acts as controller. The controller is set by the administrator or association algorithms. Generally, the coordinator will be the powered devices. The IEEE 802.15.7 task group is now developing the revised version of the VLC standard, called IEEE 802.15.7r1. This standard includes support for infrared and near ultraviolet wavelengths as additional light sources. Also, it supports Optical Camera Communications (OCC) and LiFi. OCC can be used for devices with image sensors, such as cameras and smartphones, to act as VLC receivers. Currently, the IEEE 802.15.7 revision work is being progressed as IEEE 802.15.7m. This standard is the same as IEEE 802.15.7r1, except without support for LiFi [15; 16; 17; 18]. The IPv6 over Low-power Wireless Personal Area Networks (6 LoWPAN) was made to support IP-based communication over the IEEE 802.15.4 Wireless Personal Area Network (WPAN) in the Internet Engineering Task Force (IETF) [19; 20]. The packet size in IEEE 802.15.4 is 127 octets at maximum, whereas an IPv6 packet needs at least 1280 octets of Maximum Transmission Unit (MTU). Thus, the 6 LoWPAN defines a new adaptation layer to support IPv6 packets. This adaptation layer defines multiple frame formats with compressed IPv6 headers to support IPv6 communication in IEEE 802.15.4 networks [21]. This has now evolved to support BLE and NFC [22; 23]. The Constrained Application Protocol (CoAP) was developed for constrained or sensor nodes by the IETF Constrained RESTful Environments (CoRE) Working Group (WG) [3]. CoAP is derived from the HyperText Transfer Protocol (HTTP), including the server/client model and request/response operations. Constrained devices have difficulty using the original HTTP, because their physical and computing resources are limited. Therefore, CoAP was designed to have very low overhead by adopting the User Datagram Protocol (UDP) and a binary-based message format. The CoAP has two message types: confirmable (CON) and non-confirmable (NON). A CON message is used for providing reliable message transfer. Every CON message must be acknowledged by ACK message. The IETF CoRE WG is now developing group communication; block-wise transfers; CoAP over TCP, TLS, and WebSockets; and publish-subscribe broker and congestion control [24; 25; 26; 27; 28]. The MQ Telemetry Transport (MQTT) [4] is based on the TCP-based publisher/subscriber model using a messaging protocol. It is also designed to transport messages between constrained devices. MQTT operates with a topic. One device subscribes to the topic, and another device publishes data to the topic. When a publisher publishes messages to a topic, the server forwards the topic messages to the subscribers. Nowadays, a simpler MQTT protocol, called MQTT for Sensor Networks (MQTT-SN), is being developed to support more constrained devices, such as sensor devices [5]. The MQTT-SN is interoperable with the MQTT protocol though the MQTT-SN gateway. oneM2M is a global organization for standard development and efficient deployment of M2M communications systems [8]. Until now, oneM2M has released two versions of the M2M standard: releases 1 and 2.