idnits 2.17.1 draft-chkim-vlc-iot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2018) is 2010 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT' -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-SN' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Cheol M. Kim 2 Document: draft-chkim-vlc-iot-00.txt Kyungpook National University 3 Seok J. Koh 4 Expires: April 2019 Kyungpook National University 5 October 18, 2018 7 Framework of Visible Light Communications in IoT Networks 8 draft-chkim-vlc-iot-00.txt 10 Abstract 12 The LED-based Visible Light Communication (VLC) has been proposed as 13 the IEEE 802.15.7-2011 standard and regarded as a new wireless access 14 medium in IoT environment. With this trend, many works have so far 15 been made to improve the performance of VLC. However, how to 16 effectively integrate VLC services into IoT networks has not been 17 studied enough. In this document, we propose a scheme for device 18 management and data transport in IoT networks using VLC. 19 Specifically, we discuss how to manage VLC transmitters and 20 receivers, and to support VLC data transmission in IoT networks. The 21 proposed scheme considers uni-directional VLC transmissions from 22 transmitter to receivers for delivery of location-based VLC data. The 23 backward transmission from VLC receivers will be made by using 24 platform server and aggregation agents in the network. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 18, 2009. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. 60 Table of Contents 62 1. Introduction ................................................ 4 63 2. Proposed VLC-Based IoT Scheme ............................... 5 64 2.1. Network Reference Model ................................ 5 65 2.1.1. Platform Server (PS) .............................. 6 66 2.1.2. Aggregation Agent (AA) ............................ 6 67 2.1.3. VLC Transmitter (VT) .............................. 6 68 2.1.4. VLC Receiver (VR) ................................. 6 69 2.2. Protocol Stacks based on Uni-Directional VLC ........... 7 70 2.3. Device Management and Data Transport Operation ......... 9 71 2.3.1. Device Initialization ............................. 9 72 2.3.2. Device Monitoring ................................ 13 73 2.3.3. VLC Data Transport ............................... 14 74 2.3.4. VR Handover ...................................... 15 75 3. Security Considerations .................................... 16 76 4. IANA Considerations ........................................ 17 77 5. References ................................................. 17 78 5.1. Normative References .................................. 17 79 5.2. Informative References ................................ 17 81 1. Introduction 83 Recently, IoT services have widely been used to improve our daily 84 life. For example, with the help of IoT services, people can order 85 what they need by pushing a button, or find the location where a fire 86 has occurred by aggregating the measured values from sensors through 87 the Internet. 89 For realizing the IoT, there has been lots of work undertaken on 90 wireless communication technologies such as BLE and ZigBee, as well 91 as the protocols to support packet delivery, such as CoAP [RFC7252], 92 MQTT [MQTT], MQTT-SN [MQTT-SN], and so on. Moreover, there are also 93 lots of standards and software to help develop IoT products, as shown 94 by the Open Connectivity Foundation (OCF), IoTivity, and oneM2M. 96 In the meantime, some industry areas may be subject to location- 97 critical jobs and/or limited RF communication environments, such as 98 huge factories, airplanes, underground facilities, and so on. Such 99 environments need a specialized communication technology. Visible 100 Light Communication (VLC), which is defined in the IEEE 802.15.7-2011 101 [IEEE_802.15.7-2011], is one of the communication solutions for 102 meeting these characteristics. VLC communication is carried out 103 between transmitter and receivers using visible light. Based on this 104 characteristic, VLC offers no interference to existing RF-based 105 communications. Also, it does not require a license to use the 106 spectrum of visible light. Moreover, VLC provides accurate location- 107 based communication, in contrast to existing low-power communication, 108 such as BLE and NFC. 110 Nowadays, LED lights are widely spread in our daily life. A great 111 deal of work has been done on how to improve the performance of LED- 112 based VLC in the physical and MAC layers. The IEEE 802.15.7 group has 113 recently standardized Optical Wireless Communications (OWC). However, 114 how to effectively integrate VLC services into the IoT network has 115 not yet been studied enough. In this paper, we propose a scheme for 116 device management and data transport in IoT networks using VLC. 117 Specifically, we discuss how to manage VLC devices (VLC transmitters 118 and receivers) and support the VLC data transmission in the IoT 119 networks based on the oneM2M standard. In the proposed VLC-based IoT 120 scheme, we consider the uni-directional VLC transmissions from VLC 121 transmitter to VLC receivers for location-based VLC data service. The 122 backward transmission from VLC receivers to VLC transmitter will be 123 made using the IoT platform server and aggregation agents in the IoT 124 network. By implementation and testbed experimentation, we will also 125 perform the validation and performance analysis for the proposed 126 scheme. 128 This paper is organized as follows. In Section 2, we propose the 129 reference network model for the VLC-based IoT scheme and the device 130 management and VLC data transport operations in the IoT networks. 132 2. Proposed VLC-Based IoT Scheme 134 2.1. Network Reference Model 136 For VLC-based IoT networks, we consider the following four types of 137 network nodes: Platform Server (PS), Aggregation Agent (AA), VLC 138 Transmitter (VT), and VLC Receiver (VR). Figure 1 shows uni- 139 directional VLC from VT to VR, in which only downlink VLC 140 transmission is allowed from VT to VR, and the uplink or backward 141 transmission will be made between VR and AA by using another network 142 link, such as WLAN or WPAN. 144 +----+ Ethernet +----+ WLAN/WPAN +-----------+ 145 | PS |<========>| AA |<=========>| VT | 146 +----+ +----+ |(LED Light)| 147 ## +-----------+ 148 ## WLAN/WPAN * * 149 ## * VLC * 150 ## * * 151 +------------+ | 152 | VR | VLC | 153 |(IoT Device)|<----- 154 +------------+ 156 Figure 1 VLC Communication scenario 158 It is noted that most real-world VLC deployments follow the uni- 159 directional model displayed in Figure 1, even though the IEEE 160 802.15.7-2011 specification defines both bi-directional and uni- 161 directional models. This is because the implementation of bi- 162 directional VLC requires multiple light sources or more complex MAC 163 algorithms. Based on this observation, this paper proposes the VLC- 164 based IoT scheme based on the uni-directional VLC model. The bi- 165 directional VLC model will be considered for further study. 167 Figure 2 shows the network reference model for the VLC-based IoT 168 scheme, in which the network entities are classified as Platform 169 Server (PS), Aggregation Agent (AA), VLC Transmitter (VT), and VLC 170 Receiver (VR). Each network entity provides the following 171 functionality: 173 2.1.1. Platform Server (PS) 175 PS performs overall management for all devices, including AAs, VTs, 176 and VRs, in the VLC-based IoT network through the operations of 177 device initialization, monitoring, and VR handover. PS also controls 178 location-specific VLC data (from VT to VR) and service-specific data 179 (between AA and VR) by using the data transport operation. PS is 180 connected to the Internet. 182 2.1.2. Aggregation Agent (AA) 184 AA manages VT and VR devices locally. It keeps and updates the VT-VR 185 mapping information for its attached VT through the device 186 initialization, monitoring, and VR handover operations. That is, AA 187 can realize the list of VRs that is connected to a specific VT. AA 188 also supports the VR service channel with VR, in which AA exchanges 189 service data with VR. AA is also used to relay location-specific VLC 190 data between PS and VT, and service-specific data between VR and PS. 192 2.1.3. VLC Transmitter (VT) 194 VT controls the LED light. When VT is connected and registered to AA, 195 it transmits location-specific data with VLC frames toward VRs. 197 2.1.4. VLC Receiver (VR) 199 VR is a user or sensor device which acts as a VLC receiver. When VR 200 receives VLC frames with the location-specific data from VT, it will 201 begin the registration with AA. If VR is connected to AA, it may 202 request service data from AA, based on the context of the location- 203 specific data. 205 In Figure 2, there are four types of network links. The link with 206 double dash (=) between AA and PS could possibly be Ethernet. The 207 link with single dash (-) between AA and PS could be Ethernet or 208 WLAN. The link with star (*) illustrates the VLC frames transmitted 209 by LED light. The link with at mark (@) indicates the service channel 210 between AA and VR. This service channel could be WLAN or WPAN, such 211 as ZigBee, BLE, Z-Wave, etc. It is noted in the proposed scheme that 212 this service channel is employed to provide the uplink or backward 213 communication from VR to AA or PS, as discussed with respect to 214 Figure 1. 216 ###### 217 # # 218 #Internet# 219 # # 220 Ethernet/WLAN/WPAN ###### 221 |----------------------------------| | 222 | | | | 223 +-----------+ +-----------+ +--------+ +--------+ 224 | VT | | VT | | AA | Ethernet | PS | 225 |(LED Light)| |(LED Light)| | |<========>| | 226 +-----------+ +-----------+ +--------+ +--------+ 227 * * * * @ 228 * VLC * * VLC * @ 229 * * * * @ 230 +------------+ @ WLAN/WPAN 231 | VR | @ 232 |(IoT Device)|@@@ 233 +------------+ 235 Figure 2 Network Reference model for VLC-based IoT 237 2.2. Protocol Stacks based on Uni-Directional VLC 239 Figure 3 shows the protocol stack used by each network entity in the 240 proposed VLC-based IoT scheme, which is based on IPv6 networks. 242 +----+ +----+ +----+ +----+ 243 | PS | | AA | | VT | | VR | 244 +----+ +----+ +----+ +----+ 246 +--------+ +------------------+ +---------+ +---------+ 247 | CoAP | | CoAP | | COAP | | CoAP | 248 +--------+ +------------------+ +---------+ +---------+ 249 | UDP | | UDP | | UDP | | UDP | 250 +--------+ +------------------+ +---------+ +---------+ 251 | | | IPv6 | | IPv6 | | IPv6 | 252 | IPv6 | | +---------+ +---------+ +---------+ 253 | | | | 6LoWPAN | | 6LoWPAN | | 6LoWPAN | 254 +--------+ +--------+---------+ +---------+-----+ +-----+---------+ 255 |Ethernet| |Ethernet|WLAN/WPAN| |WLAN/WPAN| VLC | | VLC |WLAN/WPAN| 256 | MAC | | MAC | MAC | | MAC | MAC | | MAC | MAC | 257 +--------+ +--------+---------+ +---------+-----+ +-----+---------+ 258 |Ethernet| |Ethernet|WLAN/WPAN| |WLAN/WPAN| VLC | | VLC |WLAN/WPAN| 259 | PHY | | PHY | PHY | | MAC | PHY | | PHY | PHY | 260 +--------+ +--------+---------+ +---------+-----+ +-----+---------+ 262 Figure 3 Protocol Stack 264 In the figure, PS and AA are connected through Ethernet. Connections 265 between AA and VT can be established through Ethernet, WLAN, or WPAN. 266 6LoWPAN may be used between AA and VT, depending on the underlying 267 link, such as BLE or ZigBee. Each VT is connected to an AA. PS can 268 send location-specific VLC data to each VT via AA. 270 In the meantime, VR receives the VLC data frames from VT. This VLC 271 data frame can contain location-specific data given by PS. Based on 272 this location-specific VLC data, VR establishes the VR service 273 channel with AA by using WPAN or WLAN. To further discuss the use of 274 location-specific VLC data and the VR service channel, let us take an 275 example of the museum service, which consists of a single PS (acting 276 as a museum administrator) and many AAs (an AA may be established at 277 each floor in the museum). It is assumed that each AA is responsible 278 for many VTs, and each VT supports a particular item in the museum 279 (e.g., a famous picture). A visitor (user) is equipped with a VR 280 device and moves across VTs to see different items. In this example, 281 PS can provide each VT with location-specific data (an item 282 identifier), and when VR visits the VT, that location-specific 283 information (item identifier) is delivered from VT to VR via the VLC 284 transmission. Based on the item identifier, VR will establish the 285 service channel with AA and download the item (picture) file from the 286 AA. In this way, the location-specific VLC data (possibly initiated 287 by PS and/or AA) is delivered from VT to VR via the uni-directional 288 VLC transmission, and the VR service channel is used between VR and 289 AA for uplink or backward data delivery. This is an example for VLC- 290 based IoT service, and its extension could be possible, depending on 291 the status of VLC deployment and the features of target VLC services. 293 2.3. Device Management and Data Transport Operation 295 In this section, we describe the VLC-based IoT operations, which are 296 divided into device initialization and monitoring, VLC data 297 transport, and VR handover operations. 299 2.3.1. Device Initialization 301 During device initialization, all devices (AA, VT, and VR) are 302 registered with PS. Figure 4 shows the overall steps for device 303 initialization. 305 +----+ +----+ +----+ +----+ 306 | PS | | AA | | VT | | VR | 307 +----+ +----+ +----+ +----+ 308 . . . . 309 .--Power on . . . 310 . . . . 311 . Power on--. . . 312 .------------------. . . 313 . 1. AA . . . 314 . Initialization . . . 315 .------------------. Power on--. . 316 . . . . 317 . .-------------------. . 318 . . 2. VT . . 319 . . Initialization . . 320 . .-------------------. Power on--. 321 . . . . 322 . . .--------------------. 323 . . . 3. VR . 324 . . . Initialization . 325 . . .--------------------. 326 . . . . 328 Figure 4 Overview of device initialization 330 Figure 5 shows the AA initialization process between PS and AA, which 331 is divided into the IP connection establishment and the AA 332 registration to PS. When an AA turns on, it finds the PS by sending a 333 Router Solicitation message, as done in a typical IP network. Then, 334 PS responds to AA with a Router Advertisement. The Router 335 Advertisement message contains the IP address of PS, including 336 information related to the Domain Name System (DNS) server and the 337 Dynamic Host Configuration Protocol (DHCP) server, if available. In 338 certain cases, PS may send the Router Advertisement messages 339 periodically. AA configures an IPv6 address after receiving the 340 Router Advertisement message. When the address configuration is 341 completed, AA sends the AA Registration message to PS. After the 342 processing of appropriate operations based on the AA Registration, PS 343 will reply with the AA Registration ACK message. If necessary, PS may 344 send the AA Network Configuration commands to the AA so as to provide 345 the information required for configuration of VR Service Channel at 346 AA. Processes 3 to 6 are accomplished at the application level. 348 +----+ +----+ +----+ +----+ 349 | PS | | AA | | VT | | VR | 350 +----+ +----+ +----+ +----+ 351 . . . . 352 . 1. Router Solicitation . . . 353 .<-------------------------. . . 354 . 2. Router Advertisement . . . 355 .------------------------->. . . 356 . 3. AA Registration . . . 357 .<-------------------------. . . 358 . 4. AA Registration ACK . . . 359 .------------------------->. . . 360 . 5. AA Network . . . 361 . Configuration Command . 6. VR Service . . 362 .------------------------->. Channel . . 363 . .-> Configuration . . 365 Figure 5 AA Initialization 367 Figure 6 shows the VT initialization process, which is divided into 368 IP connection establishment and VT registration to AA. Because VT is 369 a lighting device with VLC functionality, when VT is powered on, it 370 operates as a normal light bulb. It is noted that our scheme could 371 also be used for control of a light bulb, such as switching the light 372 on or off or changing dimming rates. After being powered on, VT is 373 connected to an AA by sending a Router Solicitation message and 374 receiving a Router Advertisement message from AA. When VT receives a 375 Router Advertisement message, it configures an IPv6 address to 376 communicate with AA. After that, VT sends the VT Registration message 377 to AA, which may contain the VT identifier and status information on 378 the attached LED light. For VLC device management, AA needs to manage 379 the mapping information on its downstream VTs and VRs. For this 380 purpose, AA creates and maintains a AA-VT-VR mapping table , and it 381 will report this mapping information to PS. Now, AA responds to VT 382 with the VT Registration ACK message. If necessary, AA sends the VLC 383 Configuration message to the registered VT, which contains the 384 parameters required for VLC configuration. Then, the VT configures 385 its VLC function and starts to transmit VLC beacons toward the 386 promising VRs. It is noted that processes 3 to 8 are done at the 387 application level. 389 +----+ +----+ +----+ +----+ 390 | PS | | AA | | VT | | VR | 391 +----+ +----+ +----+ +----+ 392 . . . . 393 . . 1. Router . . 394 . . Solicitation . . 395 . .<------------------. . 396 . . 2. Router . . 397 . . Advertisement . . 398 . .------------------>. . 399 . . 3. VT Registration. . 400 . 4. Create .<------------------. . 401 . AA-VT-VR <--. 5. VT . . 402 . Mapping Table . Registration ACK . . 403 . .------------------>. . 404 . 6. Report . . . 405 . AA-VT-VR . . . 406 . Mapping Table . 7. VLC . . 407 .<-----------------. Configuration . 8. Configure VLC . 408 . .------------------>. and start . 409 . . .----> VLC Beacon . 411 Figure 6 VT Initialization 413 Figure 7 shows the VR initialization process. When VR is turned on, 414 it waits to receive any VLC frames. Once a VLC Frame is received, VR 415 decodes the VLC frame and tries to establish the VR Service Channel 416 with the associated AA. After associating VR Service Channel, VR 417 configures an IPv6 address to communicate with AA, exchanging Router 418 Solicitation and Router Advertisement messages. When an IPv6 address 419 is configured, VR tries to register with AA by sending VR 420 Registration message. AA updates the AA-VT-VR mapping table created 421 before and replies to VR with a VR Registration ACK message. After VR 422 registration is completed, AA reports the new VR to PS by sending the 423 mapping table. Steps 3 to 8 are done at the application level. Figure 424 8 gives an example of the VLC format and how fields in the VLC frame 425 are used for the VR initialization operation. The VLC frame contains 426 the start and end preamble for distinguishing VLC frames. AA ID and 427 VT ID will be used for VR registration, device monitoring, and VLC 428 data transport. In addition, the information on VR Service Channel 429 can be defined. For example, when WLAN is used between VR and AA, the 430 Basic Service Set Identifier (BSSID) of Access Point (AP) for AA may 431 be included as the information of VR Service Channel. The 432 authorization of VR Service Channel may be added when access control 433 from unauthorized requests is needed. Both fields are related to 434 associating VR Service Channel with AA. A checksum field may be 435 included for checking the validity of the received VLC frame. 437 +----+ +----+ +----+ +----+ 438 | PS | | AA | | VT | | VR | 439 +----+ +----+ +----+ +----+ 440 . . . . 441 . . .1. Receive VLC Frame. 442 . . .------------------->. 443 . . . 2. Process <---. 444 . . . VLC Frame . 445 . . . . 446 . . . 3. Probe VR <---. 447 . . . Service Channel . 448 . . . . 449 . . 4. VR Service Channel Assoc. Request . 450 . .<---------------------------------------. 451 . . 5. VR Service Channel Assoc. Response . 452 . .--------------------------------------->. 453 . . 6. Router Solicitation . 454 . .<---------------------------------------. 455 . . 7. Router Advertisement . 456 . .--------------------------------------->. 457 . . 8. VR Registration . 458 . .<---------------------------------------. 459 . 9. Update <--. . . 460 . AA-VT-VR Mapping . 10. VR Registration ACK . 461 . Information .--------------------------------------->. 462 . . . . 463 . 11. Report <--. . . 464 . the mapping . . . 465 . information . . . 467 Figure 7 VR Initialization 469 +----------+----+----+--------------------+ 470 | Start | AA | VT | Information of VR | 471 | Preamble | ID | ID | Service Channel | 472 +----------+----+----+--------------------+ 473 +---------------------+----------+--------+ 474 | Authorization of VR | Checksum | End | 475 | Service Channel | |Preamble| 476 +---------------------+----------+--------+ 478 Figure 8 VLC Frame Format 480 2.3.2. Device Monitoring 482 Device monitoring is used for PS to keep track of the status of the 483 AA, VT, and VR devices in the network. Figure 9 shows the device 484 monitoring operations, in which the VT and VR devices periodically 485 report the status to AA, and AA sends aggregate status information to 486 PS. 488 +----+ +----+ +----+ +----+ 489 | PS | | AA | | VT | | VR | 490 +----+ +----+ +----+ +----+ 491 . . . . 492 . . 1. VT Live Report . . 493 . . (Every 10 Sec.) . . 494 . .<------------------. . 495 . .--> 2. Update . . 496 . . AA-VT-VR Mapping . 3. Receive . 497 . . Table . VLC Frame . 498 . . .------------------->. 499 . . . 4. Process <--. 500 . . . VLC Frame . 501 . . 5. VR Live report . 502 . 7. Report . (Every 10 Sec.) . 503 . AA-VT-VR .<---------------------------------------. 504 . Mapping Status .--> 6. Update . . 505 . (Every 30 Sec.) . AA-VT-VR Mapping . . 506 .<-----------------. Table . . 508 Figure 9 Device Monitoring 510 As shown in the figure, AA always keep the AA-VT-VR mapping table for 511 device monitoring. VT and VR may use a timer for periodic reporting 512 (e.g., every 10 s). Such a report message contains the identifiers of 513 the concerned VT and VR. On reception of the reports from VT and VR, 514 AA will update its AA-VT-VR mapping table. Then, AA also reports the 515 aggregate status information to PS periodically (e.g., every 30 s). 516 It is noted that an appropriate timer value may be configured, 517 depending on the network deployment and the service features to be 518 considered. 520 2.3.3. VLC Data Transport 522 In the proposed scheme, the VR data is classified into the following 523 two types. One is location-specific data, which is contained in the 524 VLC frames that VT transmits to VRs. The other one is service data, 525 which is delivered through the VR service channel between AA and VR. 527 Figure 10 shows the data transport operations, in which VR receives 528 location-specific data from VT and service-specific data is exchanged 529 between AA and VR. For the example of the museum service, the VR 530 device may be used to give detailed information on the concerned 531 exhibition item (e.g., description on the item) to the visiting user. 532 In this case, the location-specific data contains the IDs of AA and 533 VT, the channel number of the target item, etc. Please note that such 534 information is specific to a particular VT or item. The VR device 535 might be a smartphone with a mobile guide application for the museum, 536 or a dedicated device that is given by the museum. Based on the 537 location-specific data, VR will try to get more detailed and 538 additional information on the target item from AA, which is served by 539 the service data of VR Service Channel. 541 +----+ +----+ +----+ +----+ 542 | PS | | AA | | VT | | VR | 543 +----+ +----+ +----+ +----+ 544 . . . . 545 . 1. Location- . 2. VLC Frame . . 546 . Specific Data . Configuration . . 547 .----------------->. Command . . 548 . . (From Location- .3. Receive VLC Frame. 549 . . Specific Data) . (Location-Specific. 550 . .------------------>. Data) . 551 . . .------------------->. 552 . . . 4. Process <--. 553 . 6. Service Data . . VLC Frame . 554 . Request . 5. Service Data Req. (VR Service CH.) . 555 . (Forwarding) .<---------------------------------------. 556 .<-----------------. . . 557 . 7. Service Data . . . 558 .----------------->. 8. Service Data (FWD., VR Service CH.) . 559 . .--------------------------------------->. 561 Figure 10 VLC Data Transport 563 2.3.4. VR Handover 565 If VR is a mobile device, it may move around and across different VTs 566 in the network. When a VR moves to another VT, VR performs the 567 handover operation, as described in Figure 11. VR will detect a 568 handover event if it receives a new VLC frame from a different VT. 569 When the handover event is detected, VR sends a VR Handover Report 570 message to AA. The message contains the identifiers of old and new 571 VTs. If AA receives the handover report, it will update the AA-VT-VR 572 mapping table, and send a report to PS. After that, AA responds to VR 573 with a VR Handover ACK message through the VR Service Channel. 575 +----+ +----+ +--------+ +--------+ +----+ 576 | PS | | AA | | VT:OLD | | VT:NEW | | VR | 577 +----+ +----+ +--------+ +--------+ +----+ 578 . . . . 579 . . 1. Receive VLC Frame . 580 . . (Location-Specific Data) . 581 . .--------------------------------->. 582 . . 2. Move to Another VT <----. 583 . . . . 584 . . . 3. Receive . 585 . . . VLC Frame . 586 . . . (Location-Specific . 587 . . . Data) . 588 . . .------------------->. 589 . . . 4. Receive . 590 . . . VLC Frame . 591 . . . (Location-Specific . 592 . . . Data) . 593 . . .------------------->. 594 . 4. VR Handover Report (VR Service CH.) . 595 .<---------------------------------------------. 596 .----> 5. Update AA-VT-VR Mapping Table . 597 6.<--. . . . 598 . 7. VR Handover ACK . 599 .--------------------------------------------->. 601 +----+ +----+ +----+ +----+ 602 | PS | | AA | | VT | | VR | 603 +----+ +----+ +----+ +----+ 604 . . 605 . .---> 5. 606 . 6. Report updated AA-VT-VR Mapping Table . 607 .<-----------------------------------------. 608 . .---> 7. 610 Figure 11 VR Handover Across VTs 612 3. Security Considerations 614 The VLC Frame contains the information related to VR Service Channel 615 and which is not encrypted. An unknown VR can receive and process the 616 VLC Frame knows how to access the Service Channel. This may lead 617 information leak. This issue can be resolved by encrypting VLC Frame 618 or access control from the AA. 620 4. IANA Considerations 622 5. References 624 5.1. Normative References 626 [RFC7252] Shelby, Z., "The Constrained Application Protocol (CoAP)", 627 RFC 7252, June 2014. 629 [MQTT] OASIS Standard, "MQTT Protocol Specifications version 630 v3.1.1", October 2014. 631 634 [MQTT-SN] Stanford-Clark, A. "MQTT For Sensor Networks (MQTT-SN) 635 Protocol Specification version 1.2", November 2014. 636 639 [IEEE_802.15.7-2011] 640 IEEE Standards, IEEE 802.15.7-2011, "IEEE Standard for 641 Local and Metropolitan Area Networks-Part 15.7: Short-Range 642 Wireless Optical Communication Using Visible Light", 643 September 2011. 644 646 [IEEE_802.11-2016] 647 IEEE Standards, IEEE 802.11-2016, "IEEE Standard for 648 Information Technology-Telecommunications and information 649 exchange between systems Local and metropolitan area 650 networks-Specific requirements - Part 11: Wireless LAN 651 Medium Access Control (MAC) and Physical Layer (PHY) 652 Specifications", December 2016. 653 655 5.2. Informative References 656 Authors' Addresses 658 Cheol-Min Kim 659 Kyungpook National University 660 Daehakro 80, Bukgu, Daegu, South Korea 41566 662 Email: cheolminkim@vanilet.pe.kr 664 Seok-Joo Koh 665 Kyungpook National University 666 Daehakro 80, Bukgu, Daegu, South Korea 41566 668 Phone: +82 53 950 7356 669 Email: sjkoh@knu.ac.kr