Internet DRAFT - draft-chkim-vlc-iot
draft-chkim-vlc-iot
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.
<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-
v3.1.1-os.html>
[MQTT-SN] Stanford-Clark, A. "MQTT For Sensor Networks (MQTT-SN)
Protocol Specification version 1.2", November 2014.
<https://mqtt.org/new/wp-content/uploads/2009/06/MQTT-
SN_spec_v1.2.pdf>
[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.
<https://standards.ieee.org/standard/802_15_7-2011.html>
[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.
<https://standards.ieee.org/standard/802_11-2016.html>
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]
