1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Scheme for VLC dimming using Layer Management and Out-of-band Idle Patterns Date Submitted: October 2008 Source: Rick Roberts [Intel] Address E-Mail: richard.d.roberts@intel.com Re: Abstract: Purpose: 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. Rick Roberts (Intel)

2. A number of contributions have discussed the issue of dimming. Amongst these are: 1) Document 15-09-0204-00-0007-a-standardized-led-infrastructure-lighting-interface.ppt asked the question “do we need to standardize the LED infrastructure lighting interface”, or is such an interface out-of-scope of the standard. 2) Document 15-09-0369-00-0007-dimming_considerations_for_vlc pointed out that there are a number of different techniques for dimming an LED source so the problem can be complex. 3) Document 15-09-0557-01-0007-vlc-coexistence-with-lighting-control.ppt introduced the concept of the “light abstraction layer” (LAL) which is not a part of VLC but rather a stand-alone (sub)system that has been previously deployed. 4) Document 15-09-0641-00-0007-vlc-dimming-proposal.pdf suggested using a “filler sequence” that is statistically adjusted to meet the required dimming. 5) 15-09-0712-00-0007-vlc-considerations-for-band-plan-and-dimming.pdf cautioned that the “dimming function should be carefully added to communication function without sacrificing illumination function”. 6) 15-09-0713-00-0007-suggested-dimming-scope-for-tg7-standardization.pdf suggested using visibility patterns that are dependent upon required dimming levels. 7) 15-09-0636-02-0007-roberts-phy-mac-proposal-to-ieee802-15-7.ppt also suggested using sequences for dimming but that the spectral characteristics of the dimming sequences be such that these sequences did not interfere with actual data traffic. In this contribution we show how the Layer Management Entity can be used to specify a mechanism for implementing the dimming function while still accommodating a wide variety of dimming schemes and raising the possibility of a companion organization writing the equivalent of a “Light Abstraction Layer” specification for dimming. Rick Roberts (Intel)

3. To understand the Intel dimming concept, one has to understand the layer management entity concept of IEEE802, specifically the MLME and PLME. The following is from 802.15.3-2003, except for the red blocks which have been added. User Dimmer Control Dimmer Termination & Interface In the above figure only the shaded area is within scope of the standard, the rest are out of scope of the standard. Again you will notice that we’ve added the dimmer function in red. Rick Roberts (Intel)

4. The user dimmer function is terminated at a dimmer interface that is dimming scheme specific; that is, suitable for whatever is the nature of how the dimmer is functioning (i.e. pulse width modulation, or variable conduction angle, etc). • The dimmer interface connects to the DME and passes on information as to the requested amount of light intensity. • The DME calculates the required parameters needed to meet the dimming requirement and sends these to the MLME and/or PLME. How this is calculated is out-of-scope of IEEE802.15.7. • The MAC and PHY then obtain this information via the MLE and in response make the required adjustments in the duty cycles and frame dead time so as to meet the dimming requirements. This is summarized on the next page. • Note: the dimming function is translated from whatever is the native functionality of the user dimmer control, to a form that the VLC PHY understands and can efficiently implement. We do NOT attempt to preserve the native functionality of the user dimmer equipment. For example, we do not need to continue using PWM for dimming just because the user equipment natively uses PWM. Rick Roberts (Intel)

5. Rick Roberts (Intel)

6. Generated by the MAC and passed to the PHY via the PHY SAP. Dimmer info via the MLME. Generated locally by the PHY (no MAC involvement) using dimmer info obtained via the PLME. Rick Roberts (Intel)

7. Frame Flicker Compensation It is believed that only amplitude modulated sources need to do frame flicker compensation. We believe that constant envelope modulation (i.e. any version of color shift keying) does not have to compensate. Our text makes frame flicker compensation a PHY layer issue by indicating that when a PHY is not sending data packets it must send an idle sequence that has the required duty cycle necessary to meet the dimming requirement. Note: the distribution of 1’s and 0’s is changed to meet the required dimming. This info comes via the PLME. Rick Roberts (Intel)

8. It should be pointed out that if the idle pattern contains no useful information then it would be best to send it “out-of-band”, referenced to the modulation domain, so as to avoid interference to on-going “in-band” data traffic. This is illustrated below. demod RX band pass filtering Rick Roberts (Intel)

9. Frame Flicker Compensation (cont.) Rick Roberts (Intel)

10. THE END Rick Roberts (Intel)