Internet Draft Cheol M. Kim Document: draft-chkim-vlc-iot-00.txt Kyungpook National University Seok J. Koh Expires: April 2019 Kyungpook National University October 18, 2018 Framework of Visible Light Communications in IoT Networks draft-chkim-vlc-iot-00.txt Abstract The LED-based Visible Light Communication (VLC) has been proposed as the IEEE 802.15.7-2011 standard and regarded as a new wireless access medium in IoT environment. With this trend, many works have so far been made to improve the performance of VLC. However, how to effectively integrate VLC services into IoT networks has not been studied enough. In this document, we propose a scheme for device management and data transport in IoT networks using VLC. Specifically, we discuss how to manage VLC transmitters and receivers, and to support VLC data transmission in IoT networks. The proposed scheme considers uni-directional VLC transmissions from transmitter to receivers for delivery of location-based VLC data. The backward transmission from VLC receivers will be made by using platform server and aggregation agents in the network. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Kim, et al. Expires April 18, 2019 [Page 1] Internet-Draft Framework of VLC in IoT Networks October 2018 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 18, 2009. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kim, et al. Expires April 18, 2019 [Page 2] Internet-Draft Framework of VLC in IoT Networks October 2018 Table of Contents 1. Introduction ................................................ 4 2. Proposed VLC-Based IoT Scheme ............................... 5 2.1. Network Reference Model ................................ 5 2.1.1. Platform Server (PS) .............................. 6 2.1.2. Aggregation Agent (AA) ............................ 6 2.1.3. VLC Transmitter (VT) .............................. 6 2.1.4. VLC Receiver (VR) ................................. 6 2.2. Protocol Stacks based on Uni-Directional VLC ........... 7 2.3. Device Management and Data Transport Operation ......... 9 2.3.1. Device Initialization ............................. 9 2.3.2. Device Monitoring ................................ 13 2.3.3. VLC Data Transport ............................... 14 2.3.4. VR Handover ...................................... 15 3. Security Considerations .................................... 16 4. IANA Considerations ........................................ 17 5. References ................................................. 17 5.1. Normative References .................................. 17 5.2. Informative References ................................ 17 Kim, et al. Expires April 18, 2019 [Page 3] Internet-Draft Framework of VLC in IoT Networks October 2018 1. Introduction Recently, IoT services have widely been used to improve our daily life. For example, with the help of IoT services, people can order what they need by pushing a button, or find the location where a fire has occurred by aggregating the measured values from sensors through the Internet. For realizing the IoT, there has been lots of work undertaken on wireless communication technologies such as BLE and ZigBee, as well as the protocols to support packet delivery, such as CoAP [RFC7252], MQTT [MQTT], MQTT-SN [MQTT-SN], and so on. Moreover, there are also lots of standards and software to help develop IoT products, as shown by the Open Connectivity Foundation (OCF), IoTivity, and oneM2M. In the meantime, some industry areas may be subject to location- critical jobs and/or limited RF communication environments, such as huge factories, airplanes, underground facilities, and so on. Such environments need a specialized communication technology. Visible Light Communication (VLC), which is defined in the IEEE 802.15.7-2011 [IEEE_802.15.7-2011], is one of the communication solutions for meeting these characteristics. VLC communication is carried out between transmitter and receivers using visible light. Based on this characteristic, VLC offers no interference to existing RF-based communications. Also, it does not require a license to use the spectrum of visible light. Moreover, VLC provides accurate location- based communication, in contrast to existing low-power communication, such as BLE and NFC. Nowadays, LED lights are widely spread in our daily life. A great deal of work has been done on how to improve the performance of LED- based VLC in the physical and MAC layers. The IEEE 802.15.7 group has recently standardized Optical Wireless Communications (OWC). However, how to effectively integrate VLC services into the IoT network has not yet been studied enough. In this paper, we propose a scheme for device management and data transport in IoT networks using VLC. Specifically, we discuss how to manage VLC devices (VLC transmitters and receivers) and support the VLC data transmission in the IoT networks based on the oneM2M standard. In the proposed VLC-based IoT scheme, we consider the uni-directional VLC transmissions from VLC transmitter to VLC receivers for location-based VLC data service. The backward transmission from VLC receivers to VLC transmitter will be made using the IoT platform server and aggregation agents in the IoT network. By implementation and testbed experimentation, we will also perform the validation and performance analysis for the proposed scheme. Kim, et al. Expires April 18, 2019 [Page 4] Internet-Draft Framework of VLC in IoT Networks October 2018 This paper is organized as follows. In Section 2, we propose the reference network model for the VLC-based IoT scheme and the device management and VLC data transport operations in the IoT networks. 2. Proposed VLC-Based IoT Scheme 2.1. Network Reference Model For VLC-based IoT networks, we consider the following four types of network nodes: Platform Server (PS), Aggregation Agent (AA), VLC Transmitter (VT), and VLC Receiver (VR). Figure 1 shows uni- directional VLC from VT to VR, in which only downlink VLC transmission is allowed from VT to VR, and the uplink or backward transmission will be made between VR and AA by using another network link, such as WLAN or WPAN. +----+ Ethernet +----+ WLAN/WPAN +-----------+ | PS |<========>| AA |<=========>| VT | +----+ +----+ |(LED Light)| ## +-----------+ ## WLAN/WPAN * * ## * VLC * ## * * +------------+ | | VR | VLC | |(IoT Device)|<----- +------------+ Figure 1 VLC Communication scenario It is noted that most real-world VLC deployments follow the uni- directional model displayed in Figure 1, even though the IEEE 802.15.7-2011 specification defines both bi-directional and uni- directional models. This is because the implementation of bi- directional VLC requires multiple light sources or more complex MAC algorithms. Based on this observation, this paper proposes the VLC- based IoT scheme based on the uni-directional VLC model. The bi- directional VLC model will be considered for further study. Figure 2 shows the network reference model for the VLC-based IoT scheme, in which the network entities are classified as Platform Server (PS), Aggregation Agent (AA), VLC Transmitter (VT), and VLC Receiver (VR). Each network entity provides the following functionality: Kim, et al. Expires April 18, 2019 [Page 5] Internet-Draft Framework of VLC in IoT Networks October 2018 2.1.1. Platform Server (PS) PS performs overall management for all devices, including AAs, VTs, and VRs, in the VLC-based IoT network through the operations of device initialization, monitoring, and VR handover. PS also controls location-specific VLC data (from VT to VR) and service-specific data (between AA and VR) by using the data transport operation. PS is connected to the Internet. 2.1.2. Aggregation Agent (AA) AA manages VT and VR devices locally. It keeps and updates the VT-VR mapping information for its attached VT through the device initialization, monitoring, and VR handover operations. That is, AA can realize the list of VRs that is connected to a specific VT. AA also supports the VR service channel with VR, in which AA exchanges service data with VR. AA is also used to relay location-specific VLC data between PS and VT, and service-specific data between VR and PS. 2.1.3. VLC Transmitter (VT) VT controls the LED light. When VT is connected and registered to AA, it transmits location-specific data with VLC frames toward VRs. 2.1.4. VLC Receiver (VR) VR is a user or sensor device which acts as a VLC receiver. When VR receives VLC frames with the location-specific data from VT, it will begin the registration with AA. If VR is connected to AA, it may request service data from AA, based on the context of the location- specific data. In Figure 2, there are four types of network links. The link with double dash (=) between AA and PS could possibly be Ethernet. The link with single dash (-) between AA and PS could be Ethernet or WLAN. The link with star (*) illustrates the VLC frames transmitted by LED light. The link with at mark (@) indicates the service channel between AA and VR. This service channel could be WLAN or WPAN, such as ZigBee, BLE, Z-Wave, etc. It is noted in the proposed scheme that this service channel is employed to provide the uplink or backward communication from VR to AA or PS, as discussed with respect to Figure 1. Kim, et al. Expires April 18, 2019 [Page 6] Internet-Draft Framework of VLC in IoT Networks October 2018 ###### # # #Internet# # # Ethernet/WLAN/WPAN ###### |----------------------------------| | | | | | +-----------+ +-----------+ +--------+ +--------+ | VT | | VT | | AA | Ethernet | PS | |(LED Light)| |(LED Light)| | |<========>| | +-----------+ +-----------+ +--------+ +--------+ * * * * @ * VLC * * VLC * @ * * * * @ +------------+ @ WLAN/WPAN | VR | @ |(IoT Device)|@@@ +------------+ Figure 2 Network Reference model for VLC-based IoT 2.2. Protocol Stacks based on Uni-Directional VLC Figure 3 shows the protocol stack used by each network entity in the proposed VLC-based IoT scheme, which is based on IPv6 networks. Kim, et al. Expires April 18, 2019 [Page 7] Internet-Draft Framework of VLC in IoT Networks October 2018 +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ +--------+ +------------------+ +---------+ +---------+ | CoAP | | CoAP | | COAP | | CoAP | +--------+ +------------------+ +---------+ +---------+ | UDP | | UDP | | UDP | | UDP | +--------+ +------------------+ +---------+ +---------+ | | | IPv6 | | IPv6 | | IPv6 | | IPv6 | | +---------+ +---------+ +---------+ | | | | 6LoWPAN | | 6LoWPAN | | 6LoWPAN | +--------+ +--------+---------+ +---------+-----+ +-----+---------+ |Ethernet| |Ethernet|WLAN/WPAN| |WLAN/WPAN| VLC | | VLC |WLAN/WPAN| | MAC | | MAC | MAC | | MAC | MAC | | MAC | MAC | +--------+ +--------+---------+ +---------+-----+ +-----+---------+ |Ethernet| |Ethernet|WLAN/WPAN| |WLAN/WPAN| VLC | | VLC |WLAN/WPAN| | PHY | | PHY | PHY | | MAC | PHY | | PHY | PHY | +--------+ +--------+---------+ +---------+-----+ +-----+---------+ Figure 3 Protocol Stack In the figure, PS and AA are connected through Ethernet. Connections between AA and VT can be established through Ethernet, WLAN, or WPAN. 6LoWPAN may be used between AA and VT, depending on the underlying link, such as BLE or ZigBee. Each VT is connected to an AA. PS can send location-specific VLC data to each VT via AA. In the meantime, VR receives the VLC data frames from VT. This VLC data frame can contain location-specific data given by PS. Based on this location-specific VLC data, VR establishes the VR service channel with AA by using WPAN or WLAN. To further discuss the use of location-specific VLC data and the VR service channel, let us take an example of the museum service, which consists of a single PS (acting as a museum administrator) and many AAs (an AA may be established at each floor in the museum). It is assumed that each AA is responsible for many VTs, and each VT supports a particular item in the museum (e.g., a famous picture). A visitor (user) is equipped with a VR device and moves across VTs to see different items. In this example, PS can provide each VT with location-specific data (an item identifier), and when VR visits the VT, that location-specific information (item identifier) is delivered from VT to VR via the VLC transmission. Based on the item identifier, VR will establish the service channel with AA and download the item (picture) file from the AA. In this way, the location-specific VLC data (possibly initiated by PS and/or AA) is delivered from VT to VR via the uni-directional Kim, et al. Expires April 18, 2019 [Page 8] Internet-Draft Framework of VLC in IoT Networks October 2018 VLC transmission, and the VR service channel is used between VR and AA for uplink or backward data delivery. This is an example for VLC- based IoT service, and its extension could be possible, depending on the status of VLC deployment and the features of target VLC services. 2.3. Device Management and Data Transport Operation In this section, we describe the VLC-based IoT operations, which are divided into device initialization and monitoring, VLC data transport, and VR handover operations. 2.3.1. Device Initialization During device initialization, all devices (AA, VT, and VR) are registered with PS. Figure 4 shows the overall steps for device initialization. +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . . .--Power on . . . . . . . . Power on--. . . .------------------. . . . 1. AA . . . . Initialization . . . .------------------. Power on--. . . . . . . .-------------------. . . . 2. VT . . . . Initialization . . . .-------------------. Power on--. . . . . . . .--------------------. . . . 3. VR . . . . Initialization . . . .--------------------. . . . . Figure 4 Overview of device initialization Figure 5 shows the AA initialization process between PS and AA, which is divided into the IP connection establishment and the AA registration to PS. When an AA turns on, it finds the PS by sending a Router Solicitation message, as done in a typical IP network. Then, Kim, et al. Expires April 18, 2019 [Page 9] Internet-Draft Framework of VLC in IoT Networks October 2018 PS responds to AA with a Router Advertisement. The Router Advertisement message contains the IP address of PS, including information related to the Domain Name System (DNS) server and the Dynamic Host Configuration Protocol (DHCP) server, if available. In certain cases, PS may send the Router Advertisement messages periodically. AA configures an IPv6 address after receiving the Router Advertisement message. When the address configuration is completed, AA sends the AA Registration message to PS. After the processing of appropriate operations based on the AA Registration, PS will reply with the AA Registration ACK message. If necessary, PS may send the AA Network Configuration commands to the AA so as to provide the information required for configuration of VR Service Channel at AA. Processes 3 to 6 are accomplished at the application level. +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . . . 1. Router Solicitation . . . .<-------------------------. . . . 2. Router Advertisement . . . .------------------------->. . . . 3. AA Registration . . . .<-------------------------. . . . 4. AA Registration ACK . . . .------------------------->. . . . 5. AA Network . . . . Configuration Command . 6. VR Service . . .------------------------->. Channel . . . .-> Configuration . . Figure 5 AA Initialization Figure 6 shows the VT initialization process, which is divided into IP connection establishment and VT registration to AA. Because VT is a lighting device with VLC functionality, when VT is powered on, it operates as a normal light bulb. It is noted that our scheme could also be used for control of a light bulb, such as switching the light on or off or changing dimming rates. After being powered on, VT is connected to an AA by sending a Router Solicitation message and receiving a Router Advertisement message from AA. When VT receives a Router Advertisement message, it configures an IPv6 address to communicate with AA. After that, VT sends the VT Registration message to AA, which may contain the VT identifier and status information on the attached LED light. For VLC device management, AA needs to manage the mapping information on its downstream VTs and VRs. For this Kim, et al. Expires April 18, 2019 [Page 10] Internet-Draft Framework of VLC in IoT Networks October 2018 purpose, AA creates and maintains a AA-VT-VR mapping table , and it will report this mapping information to PS. Now, AA responds to VT with the VT Registration ACK message. If necessary, AA sends the VLC Configuration message to the registered VT, which contains the parameters required for VLC configuration. Then, the VT configures its VLC function and starts to transmit VLC beacons toward the promising VRs. It is noted that processes 3 to 8 are done at the application level. +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . . . . 1. Router . . . . Solicitation . . . .<------------------. . . . 2. Router . . . . Advertisement . . . .------------------>. . . . 3. VT Registration. . . 4. Create .<------------------. . . AA-VT-VR <--. 5. VT . . . Mapping Table . Registration ACK . . . .------------------>. . . 6. Report . . . . AA-VT-VR . . . . Mapping Table . 7. VLC . . .<-----------------. Configuration . 8. Configure VLC . . .------------------>. and start . . . .----> VLC Beacon . Figure 6 VT Initialization Figure 7 shows the VR initialization process. When VR is turned on, it waits to receive any VLC frames. Once a VLC Frame is received, VR decodes the VLC frame and tries to establish the VR Service Channel with the associated AA. After associating VR Service Channel, VR configures an IPv6 address to communicate with AA, exchanging Router Solicitation and Router Advertisement messages. When an IPv6 address is configured, VR tries to register with AA by sending VR Registration message. AA updates the AA-VT-VR mapping table created before and replies to VR with a VR Registration ACK message. After VR registration is completed, AA reports the new VR to PS by sending the mapping table. Steps 3 to 8 are done at the application level. Figure 8 gives an example of the VLC format and how fields in the VLC frame are used for the VR initialization operation. The VLC frame contains Kim, et al. Expires April 18, 2019 [Page 11] Internet-Draft Framework of VLC in IoT Networks October 2018 the start and end preamble for distinguishing VLC frames. AA ID and VT ID will be used for VR registration, device monitoring, and VLC data transport. In addition, the information on VR Service Channel can be defined. For example, when WLAN is used between VR and AA, the Basic Service Set Identifier (BSSID) of Access Point (AP) for AA may be included as the information of VR Service Channel. The authorization of VR Service Channel may be added when access control from unauthorized requests is needed. Both fields are related to associating VR Service Channel with AA. A checksum field may be included for checking the validity of the received VLC frame. +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . . . . .1. Receive VLC Frame. . . .------------------->. . . . 2. Process <---. . . . VLC Frame . . . . . . . . 3. Probe VR <---. . . . Service Channel . . . . . . . 4. VR Service Channel Assoc. Request . . .<---------------------------------------. . . 5. VR Service Channel Assoc. Response . . .--------------------------------------->. . . 6. Router Solicitation . . .<---------------------------------------. . . 7. Router Advertisement . . .--------------------------------------->. . . 8. VR Registration . . .<---------------------------------------. . 9. Update <--. . . . AA-VT-VR Mapping . 10. VR Registration ACK . . Information .--------------------------------------->. . . . . . 11. Report <--. . . . the mapping . . . . information . . . Figure 7 VR Initialization Kim, et al. Expires April 18, 2019 [Page 12] Internet-Draft Framework of VLC in IoT Networks October 2018 +----------+----+----+--------------------+ | Start | AA | VT | Information of VR | | Preamble | ID | ID | Service Channel | +----------+----+----+--------------------+ +---------------------+----------+--------+ | Authorization of VR | Checksum | End | | Service Channel | |Preamble| +---------------------+----------+--------+ Figure 8 VLC Frame Format 2.3.2. Device Monitoring Device monitoring is used for PS to keep track of the status of the AA, VT, and VR devices in the network. Figure 9 shows the device monitoring operations, in which the VT and VR devices periodically report the status to AA, and AA sends aggregate status information to PS. +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . . . . 1. VT Live Report . . . . (Every 10 Sec.) . . . .<------------------. . . .--> 2. Update . . . . AA-VT-VR Mapping . 3. Receive . . . Table . VLC Frame . . . .------------------->. . . . 4. Process <--. . . . VLC Frame . . . 5. VR Live report . . 7. Report . (Every 10 Sec.) . . AA-VT-VR .<---------------------------------------. . Mapping Status .--> 6. Update . . . (Every 30 Sec.) . AA-VT-VR Mapping . . .<-----------------. Table . . Figure 9 Device Monitoring As shown in the figure, AA always keep the AA-VT-VR mapping table for device monitoring. VT and VR may use a timer for periodic reporting (e.g., every 10 s). Such a report message contains the identifiers of the concerned VT and VR. On reception of the reports from VT and VR, Kim, et al. Expires April 18, 2019 [Page 13] Internet-Draft Framework of VLC in IoT Networks October 2018 AA will update its AA-VT-VR mapping table. Then, AA also reports the aggregate status information to PS periodically (e.g., every 30 s). It is noted that an appropriate timer value may be configured, depending on the network deployment and the service features to be considered. 2.3.3. VLC Data Transport In the proposed scheme, the VR data is classified into the following two types. One is location-specific data, which is contained in the VLC frames that VT transmits to VRs. The other one is service data, which is delivered through the VR service channel between AA and VR. Figure 10 shows the data transport operations, in which VR receives location-specific data from VT and service-specific data is exchanged between AA and VR. For the example of the museum service, the VR device may be used to give detailed information on the concerned exhibition item (e.g., description on the item) to the visiting user. In this case, the location-specific data contains the IDs of AA and VT, the channel number of the target item, etc. Please note that such information is specific to a particular VT or item. The VR device might be a smartphone with a mobile guide application for the museum, or a dedicated device that is given by the museum. Based on the location-specific data, VR will try to get more detailed and additional information on the target item from AA, which is served by the service data of VR Service Channel. Kim, et al. Expires April 18, 2019 [Page 14] Internet-Draft Framework of VLC in IoT Networks October 2018 +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . . . 1. Location- . 2. VLC Frame . . . Specific Data . Configuration . . .----------------->. Command . . . . (From Location- .3. Receive VLC Frame. . . Specific Data) . (Location-Specific. . .------------------>. Data) . . . .------------------->. . . . 4. Process <--. . 6. Service Data . . VLC Frame . . Request . 5. Service Data Req. (VR Service CH.) . . (Forwarding) .<---------------------------------------. .<-----------------. . . . 7. Service Data . . . .----------------->. 8. Service Data (FWD., VR Service CH.) . . .--------------------------------------->. Figure 10 VLC Data Transport 2.3.4. VR Handover If VR is a mobile device, it may move around and across different VTs in the network. When a VR moves to another VT, VR performs the handover operation, as described in Figure 11. VR will detect a handover event if it receives a new VLC frame from a different VT. When the handover event is detected, VR sends a VR Handover Report message to AA. The message contains the identifiers of old and new VTs. If AA receives the handover report, it will update the AA-VT-VR mapping table, and send a report to PS. After that, AA responds to VR with a VR Handover ACK message through the VR Service Channel. Kim, et al. Expires April 18, 2019 [Page 15] Internet-Draft Framework of VLC in IoT Networks October 2018 +----+ +----+ +--------+ +--------+ +----+ | PS | | AA | | VT:OLD | | VT:NEW | | VR | +----+ +----+ +--------+ +--------+ +----+ . . . . . . 1. Receive VLC Frame . . . (Location-Specific Data) . . .--------------------------------->. . . 2. Move to Another VT <----. . . . . . . . 3. Receive . . . . VLC Frame . . . . (Location-Specific . . . . Data) . . . .------------------->. . . . 4. Receive . . . . VLC Frame . . . . (Location-Specific . . . . Data) . . . .------------------->. . 4. VR Handover Report (VR Service CH.) . .<---------------------------------------------. .----> 5. Update AA-VT-VR Mapping Table . 6.<--. . . . . 7. VR Handover ACK . .--------------------------------------------->. +----+ +----+ +----+ +----+ | PS | | AA | | VT | | VR | +----+ +----+ +----+ +----+ . . . .---> 5. . 6. Report updated AA-VT-VR Mapping Table . .<-----------------------------------------. . .---> 7. Figure 11 VR Handover Across VTs 3. Security Considerations The VLC Frame contains the information related to VR Service Channel and which is not encrypted. An unknown VR can receive and process the VLC Frame knows how to access the Service Channel. This may lead information leak. This issue can be resolved by encrypting VLC Frame or access control from the AA. Kim, et al. Expires April 18, 2019 [Page 16] Internet-Draft Framework of VLC in IoT Networks October 2018 4. IANA Considerations 5. References 5.1. Normative References [RFC7252] Shelby, Z., "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [MQTT] OASIS Standard, "MQTT Protocol Specifications version v3.1.1", October 2014. [MQTT-SN] Stanford-Clark, A. "MQTT For Sensor Networks (MQTT-SN) Protocol Specification version 1.2", November 2014. [IEEE_802.15.7-2011] IEEE Standards, IEEE 802.15.7-2011, "IEEE Standard for Local and Metropolitan Area Networks-Part 15.7: Short-Range Wireless Optical Communication Using Visible Light", September 2011. [IEEE_802.11-2016] IEEE Standards, IEEE 802.11-2016, "IEEE Standard for Information Technology-Telecommunications and information exchange between systems Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", December 2016. 5.2. Informative References Kim, et al. Expires April 18, 2019 [Page 17] Internet-Draft Framework of VLC in IoT Networks October 2018 Authors' Addresses Cheol-Min Kim Kyungpook National University Daehakro 80, Bukgu, Daegu, South Korea 41566 Email: cheolminkim@vanilet.pe.kr Seok-Joo Koh Kyungpook National University Daehakro 80, Bukgu, Daegu, South Korea 41566 Phone: +82 53 950 7356 Email: sjkoh@knu.ac.kr Kim, et al. Expires April 18, 2019 [Page 18]