Comment Resolutions on IEEE 802.15.7a PAR and CSD
Submission by Yeong Min Jang addressing comments and queries on IEEE 802.15.7a PAR and CSD, including clarifications on definitions, compatibility with network standards, and implementation details for devices like cameras in wireless personal area networks.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
May 2020 DCN 15-19-0136-04-0vat Project: IEEE P802.15 Interest Group for Wireless Personal Area Networks (WPANs) Submission Title: Comment Resolutions on IEEE 802.15.7a PAR and CSD Date Submitted: May 18, 2020 Source: Yeong Min Jang [Kookmin University]. Contact: +82-2-910-5068 Re: Comment Resolutions on IEEE 802.15.7a PAR and CSD E-Mail: yjang@kookmin.ac.kr Abstract: Purpose: Comment Resolutions on IEEE 802.15.7a PAR and CSD Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Slide 1 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Comment resolutions on IEEE 802.15.7a PAR and CSD From 802.1 Slide 2 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat PAR document Question: 2.1 Title: Change defining in the title to : Response: Accept Question: Definitions have a specific clause in the amendment. This amendment specifies a standard not defines it. Change defines in first sentence to specifies . Response: Accept Question: The acronym RF is used without definition until section 5.4. Spell out on first usage. Response: Accept Question: The acronyms MIMO and MIMO-OFDM are used without definition. Spell out on first usage or add 8.1 Explanatory notes Response: Accept Question: The acronyms ADAS and V2X are used without definition. Spell out on first usage or add to 8.1 Explanatory notes. Response: Accept Slide 3 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat CSD document Question: It is not clear to 802.1 how this amendment is compatible with 802.1Q. How is it envisaged that cameras can be deployed in a network where backhaul of the video signal to a control center will be over 802.3? Please clarify how this amendment will interwork with an 802.3 and 802.1 TSN network. Response: - To implement OCC, we don t need to add any new hardware or software in the camera. The existing cameras are used. However, we need to install new software in the processing unit. - For example, in terms of CCTV, the camera and the processing unit are in particular two separate parts that can be connected via 802.3. Additionally, the processing unit can use the 802.1Q or the 802.1 TSN to connect with the server. - Furthermore, the OCC technology can be implemented with full-duplex or Simplex communication mode. In recapitulation, the amendment is compatible with 802.1, 802.1Q, and 802.3. Slide 4 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Comment Resolutions on IEEE 802.15.7a PAR and CSD From 802.3 Slide 5 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 1 Question 1: General There is a recurring assertion that this project will be applicable to billions of existing devices (PAR 5.5 Need, CSD 1.2.1,a, 1.2.5,b). Yet there is no hint as to how that is done. Substantiation that there are billions of existing presumably camera equipped, presumably firmware upgradable devices that can presumably be economically upgraded to implement the capabilities promised with this project is needed. While there are lists of possible devices and applications, there are not large numbers of some devices (e.g., autonomous vehicles), nor is it clear that all devices will be able to take advantage of the capabilities because of qualification challenges (ADAS, petrochemical, nuclear, medical). Please enhance justification for the project in these areas, and more clearly separate existing and future devices. A start would be to add to PAR, 5.5 after billions of existing devices (e.g., camera equipped programmable or firmware upgradable devices) . Slide 6 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 1 Response: - The billions of existing devices where the OCC system can be implemented include Smartphone, CCTV, and other autonomous cars. Most of the smartphone cameras support new programmable applications and their firmware is upgradable. The camera2 application programming interfaces (APIs) (greater than android version 4.4) has additional features, such as manually-controlled exposure, focus, raw capture, etc. And nowadays almost (more than 87% in 2018) every smartphone camera is built with camera2 API. These features help to build an OCC application on a smartphone. Also, cameras should open on a secondary handler thread and the camera2 API makes thread management easier. It can be needed to collaborate with the manufacture companies to integrate the OCC protocol to the smartphones. Otherwise, we can develop OCC applications and users just need to install these applications to use OCC. - OCC is incredibly potential in the intelligent transport services. Different types of communications using camera are possible in vehicular environments, e.g., vehicle-to-vehicle, vehicle-to-infrastructure, and vehicle-to-pedestrian and vice versa. Different applications, for example vehicle localization, can be implemented using OCC which will be a great addition to the ADAS. Here, the OCC protocol is needed to be installed in the transmitter and receiver. It is also possible to design the autonomous cars and other infrastructures with the integration of OCC protocol by proper collaboration with them. - The hardware and software of the future cameras will be upgraded to increase the quality of images. Also, the image sensor, GPU, and CPU will be upgraded and new AI algorithms will be utilized. Consequently, it will be more convenient to implement the OCC system in the future cameras. Therefore, OCC is not compatible only with the existing cameras, but also with the future cameras. - In particular, a switching device and a Micro-controller Unit (MCU) in the transmitter is used to implement the OCC system. Here, in the case of a low-speed OCC system, an Arduino Uno (that uses an ATmega328 microcontroller capable of running up to 20 MHz) and a general MOSFET (with 2.47 microseconds as max switching time) can be used. However, a semiconductor device that has a very high switching speed (more than 100 GHz) is required to implement the high-speed OCC system. Slide 7 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 1 Response (continue): Using the existing LEDs, we can achieve a data rate up to 3 Mbps with a specific modulation scheme and a camera with a high frame rate. - For example, using the existing C-OOK scheme for an existing LED and camera, the data rates we can achieve: Modulation scheme Frame rate Data rate C-OOK 60 fps 2 kbps C-OOK 960 fps 32kbps C-OOK 10 kfps 0.3 Mbps C-OOK 100 kfps 3 Mbps Currently, existing smart cameras such as Galaxy S20 has a frame rate of 960fps. So, we can achieve a date rate up to 32kbps. We also have 100kfps camera in real market. In this case, we can increase the data rate up to 3Mbps. Slide 8 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 1 Response (continue): Furthermore, with an LED-array case (e.g., an array of 10x10 or 100x100 LEDs) in backlight LED (100 LEDs) and digital signage (10000 LEDs) with existing cameras, we can achieve the following data rates: - Modulation scheme Frame rate Data rate C-OOK 60 fps 200 kbps or 20 Mbps C-OOK 960fps 3.2Mbps or 320Mbp C-OOK 10 kfps 30 Mbps or 3 Gbps C-OOK 100 kfps 300 Mbps or 30 Gbps - In recapitulation, OCC can support a data rate more than 1Mbps for Full Duplex operation using an LED array (in other words, using MIMO) in the transmitter side and existing cameras in the receiver side. Furthermore, we can achieve data rate up to 3.2Mbps using MIMO functionality in smart phone camera. Slide 9 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 2 Question 1: General NesCom conventions require expansion of acronyms. There are multiple unexpanded acronyms, some acronyms not expanded on first use (but expanded later). Acronyms should be properly expanded to avoid NesCom rejection. Response: Accept Question 2: 1.2.1.a-The response has unexpanded acronyms: MIMO, OCC (only expanded in title but convention typically is to also expand on first text usage), please expand. Response: Accept Slide10 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 2 Question 3: 1.2.1.a While the promise of OCC is easier to see for future systems, perhaps using existing optical components, it is unsubstantiated for many existing devices. Recommend specific examples be added where OCC has been added and used. Response: Currently, almost all types of smartphones have built-in cameras. OCC programmable applications can be installed in the smartphones to use it as a receiver. Also, the LED flash light can transmit visible light or near infrared (NIR). OCC data can be integrated in them for the prospective uplink communication. CCTV cameras can be used as receivers. Here, the OCC data processing can be done in the processing unit (e.g., computer, tablet, etc) only without adding new hardware and software in the CCTV. Only the OCC-based software is needed to be installed in the processing unit. The LED headlights or taillights can be used as transmitters. Also, the camera installed in the car can be used as receivers. Here, only few hardware modifications are needed to install OCC. ISO TC 204 Plenty Meeting approved OCC as one of International Standards in V2X applications in April, 2020. Similarly, OCC can be applied in tablet, mobile robot and other devices by adding few updates in the hardware and software regarding the transmitter, and few software in the device where the received signal will be processed. Slide 11 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 2 Question 3: 1.2.1,b While the response lists numerous physically possible potential users, it appears absent of any justification of multiple vendors (e.g., how many participants from how many affiliations have participated). Response: We are expecting more than 20 participations from more than 10 affiliations, which can collaborate to complete this standard. LinkRay, developed by Panasonic, delivers mobile contents by enabling smartphones to read IDs sent from LED transmitters. These transmitters include displays, signboards, and spotlights. Associated mobile contents will be connected as well. LinkRay delivers excellent end user experiences intuitively and securely. Picalico is an indoor positioning system that uses Casio's unique camera designed for visible light communications. The LED that represents the information in the color-change pattern is used as the transmitter. On the other hand, the camera is used as the receiver to collect the ID and position information. Slide12 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 2 Question 3: 1.2.5.c - It is not likely that many devices can be upgraded to use an optical transmitter and receiver with only firmware upgrade. At a minimum, the device needs the hardware for an optical transmitter and receiver. If this is only true in many cases for simplex communication, that needs to be stated. Many of the devices cited in 1.2.1,b would be subject to extensive qualification of the new optical interface (e.g., automotive, biomedical, process control, etc.) This has significant potential impact to the economic feasibility of the retrofit market. Some of the devices cited in 1.2.1,b may not be upgradable, for example low cost drones likely do not have replaceable modules for the communication interface and may not be firmware upgradable. Device physical design may also not support the differences in radio propagation from an antenna versus optical transmission from the optical transmitter (e.g., the device itself may provide minimal attenuation to a radio signal because of its materials but totally block optical transmission in certain directions, significantly changing the operational profile for the device. Slide13 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 2 Response: As discussed in the response of CSD 1.2.1a, only a few modifications in the hardware and software are required to install OCC transmitter. Most of the existing devices have LED integrated into them. For example, car headlights and taillights, traffic lights, road lights, smartphone LED lights, etc. The newly added hardware will contain only a few Arduino boards, and switching circuits. Therefore, it will be easy to add these modifications in the transmitters. On the other hand, smartphones have built in cameras, therefore, a few software installations are enough to implement OCC. For other devices, a processing unit is needed (e.g., computer, tablet, ARM processor, etc) to analyze and decode the OCC data. Most of the companies are now integrating cameras in the autonomous cars with processing unit. We just need to install OCC software there, which will be economic and efficient. On the other hand, most of the drones also have their own processing unit and are firmware upgradable. OCC system can be installed there without any hardware modifications. The main limitation of OCC is that it is a strictly directional technology. However, it can show better performance than RF if the signal-blockage problem is mitigated. It is worth noting here that OCC should be implemented to the devices where only directional communication is required. The existing OCC technologies use the simplex-communication mode. If it is needed to implement the full duplex mode, it will be proposed for vehicular-communication systems. Slide14 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 2 Question 4: 1.2.5.b-The first sentence has little relevance to known cost factors , delete it. This item should though address the known cost factors of qualifying new firmware for many of the cited application. For example, where extensive testing is required for a firmware upgrade. Many cited application areas are secure, safety-related, e.g., process control in petrochemical and nuclear. Response: The cost factors are well known. The software that is to be installed for OCC is relatively small in size. Therefore, the prospective installations and testing will be cost-effective. Slide15 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Reviewer 3 Question: Mr. Grow had one comment on 6.1.b. Because this is RAC related and previous ad hocs have suggested such comments be directly submitted as the RAC Chair was already done in February. This comment slide is simply a reminder of that comment from the RAC Chair. The RAC has the option to review any project and doesn t need the box checked to give them permission in case they may want to review a draft. The answer and explanation are not consistent with the PAR form instructions (quoted below) in that the explanation does not indicate a new registry or new use of an existing registry expected to be included in the project. Either the explanation needs to be improved (see the P802.1ASdm draft PAR also submitted for March 802 consideration as an example), or the answer should be No . Response: We didn t create any new registry regarding the RAC, therefore, the answer is No . Slide16 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat Comment resolutions on IEEE 802.15.7a PAR and CSD From 802.11 Slide17 Yeong Min Jang Submission
May 2020 DCN 15-19-0136-04-0vat PAR and CSD documents Question: 2.1 Title: change : Amendment defining High Data Rate Optical Camera Communications (OCC) to Amendment: Definitions for High Data Rate Optical Camera Communications (OCC) Response: Accept Question: 6.1.b: Suggest change The RAC has requested routine review of PHY oriented projects, although no special registration activity is expected Response: Accept Question: 1.2.3 spell out first use of OWC. Also 802 OWC vs. 802.15 OWC? Response: Accept Slide18 Yeong Min Jang Submission
