Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_DIALOG] Comments on other WG PARs ad hoc -- 11 May



Steve, George:

Thanks!  I guess we will have a little work to do on the CSD comments.  The should at least have put in a “(e.g., camera equipped programmable devices)” or something similar for folk like me that were just thinking about 802.15 devices.

—Bob

On May 7, 2020, at 7:20 AM, Steven B. Carlson <scarlson@xxxxxxxxxxxxx> wrote:

Bob,
 
I believe George is correct. I’ve spoken with Bob Heile about VLC,  and other involved in VLC. The idea is that a software upgrade to an existing camera-equipped device would enable a receive-only VLC operating mode. I believe that the project  documentation should make this point more clearly.
 
Steve
 
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> 
Sent: Wednesday, May 06, 2020 6:51 PM
To: STDS-802-3-DIALOG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_DIALOG] Comments on other WG PARs ad hoc -- 11 May
 
Bob – regarding 1.2.1,a – I believe they are referring to using existing camera interfaces as the receivers.  I’ve read a number of the contributions – not enough to be conclusive, but the general thesis is one of one-way communication, where the transmitter (light source) is often new, and the receiver is a camera already built into a device (e.g., a cell phone, a drone, or a vehicle).  I’ll make an inquiry to find out.
-george
 
From: ROBERT GROW <bobgrow@xxxxxxx> 
Sent: Wednesday, May 06, 2020 5:28 PM
To: STDS-802-3-DIALOG@xxxxxxxxxxxxxxxxx
Subject: [802.3_DIALOG] Comments on other WG PARs ad hoc -- 11 May
 

 

Colleagues:
 
This is a reminder of the 11 May 2020 802.3 ad hoc teleconference to review and comment as appropriate on PARs submitted by other WG.  Meeting information can be found on the IEEE 802.3 call and meeting calendar (http://www.ieee802.org/3/calendar.html).  The P802.1CQ PAR extension and P802.1Q revision PAR have already been approved by the LMSC, so we will not need to review.  That leaves two PARs from other WGs.  My proposed comments follow for your convenience.  I look forward to your participation on the call.
 
 
 
• 802.1ASdm Amendment: Hot Standby, PAR and CSD
No comment.
 
 
• 802.15.7a - Amendment - Defining High Data Rate Optical Camera Communications (OCC), PAR and CSD
 
PAR
I had one comment on 6.1.b.  Because this is RAC related and previous ad hocs have suggested I submit such comments directly as the RAC Chair, I have already submitted the following comment to the EC reflector.  Obviously, the WG could choose to make a similar comment if felt necessary.
 
802.15 colleagues:
I submit the following personal comment for consideration during the March Plenary session..  (Comment has not been review nor approved by the RAC.)
Item 6.1.b — 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”.

 

The IEEE Registration Authority Committee (RAC) is a mandatory coordination body.
If the proposed standard requires (or is expected to require) the unique identification of objects or numbers for use in industry, the project has registration activity. This does not cover things like code points defined within the standard.
A YES answer with brief explanation is appropriate if:
1. The proposed standard creates a new registry.
2. The proposed standard includes new use of an existing registry (whether IEEE RA or other registry authority).
Please visit the IEEE Registration Authority website (
http://standards.ieee.org/regauth/index.html) for additional information regarding existing registries.

 

 

CSD
1.2.1,a — The response has unexpanded acronyms (MIMO, OCC), please expand.

1.2.1,a — The assertion "extending to billions of existing devices to provide secure non RF based communications capability” is not credible.  Existing devices probably do not have optical communication interfaces.  While the promise is there for future devices, it isn’t there for many existing devices.  The ease of retrofitting existing devices is grossly oversimplified by this statement as well as other parts of the CSD.  Recommend replace “existing” with “future” and improve grammar: "extending to billions of future devices the option of using secure non RF based communications capability”.

1.2.1,b — The last sentence is more credible for “applications" than it is for “devices” (assuming “applications” refers to a type of usage of the standard rather than a specific installation of existing devices).  The sentence should be edited because it is unlikely that the retrofit market will significantly increase the number of vendors and users.  It is more likely that existing devices could be engineered at reasonable cost to alternately use optical communications than it is that “billions” of existing devices are likely to be upgradable to optical communication.  Recommend the last sentence be edited to read: "This translates to a large community of vendors and users.”

1.2.3 — Unexpanded acronym “OWC”.  Please expand.
 
1.2.5,c — It is not likely that a 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.  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.  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 because of it materials to a radio signal but totally block optical transmission in certain directions, significantly changing the operational profile for the device.
 
1.2.5,a — Again, "existing hardware" is not credible.  It needs to be rewritten to perhaps to “hardware designs” or something that does not imply existing installed hardware.
 
1.2.5,b — Again, “billions of existing devices” is not credible and is not supported in the CSD.  The first sentence has little relevance to “known cost factors”, delete it.
 
 
 
 
 
 
 
 
 

To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1

To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1

To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1



To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1