Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Roberts PHY/MAC Proposal Date Submitted: September 2009 Source: Rick Roberts, Praveen Gopalakrishnan, Bahar Sadeghi, Mathys Walma [Intel Corporation] Address: Voice: 503-712-5012, 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.

2. PHY Layer

3. The problem of the lack of a credible link budget or empirical data to validate bit rates vs. range As of the date of this document, Intel does not have a credible link budget or exhaustive empirical data to validate any claims in regards to data rates vs. range. As mentioned in a companion contribution on the link budget, the current research activity is characterizing the noise sources that contribute to the noise density associated with the Eb/No calculations. No is a combination of transimpedance amplifier noise, photodetector noise, ambient light noise and photodetector nonlinearity cross modulation noise. Until the committee comes to agreement on some form of range vs. rate performance calculation, there will be an ambiguity on any data presented by any proposers.

4. Two PHY types • Low Rate PHY • ~100 Kbps packet body burst rate • Manchester Encoding, 200 Kchips/sec chipping rate (two chips per bit) • Additional lower data rates achieved by coding • High Rate PHY • ~10 Mbps packet body burst rate • Manchester Encoding, 20 Mchips/sec chipping rate (two chips per bit) • Additional lower data rates achieved by coding Manchester Coding is very similar to BPSK modulation +1 +1 Data Data -1 -1 +1 +1 Clock LO -1 -1 BPSK Manchester Encoding

5. Mapping of modulation logic level to light intensity … Logic +1  Light FULL ON Logic -1  Light much reduced level determined by desired extinction ratio {0 to 1} • While Intel is open to considering other spectral shifting coding schemes other than Manchester, we feel there are some important attributes of the spectral shifting code that need to be considered. • No DC component (balanced code) • Spectrally compact code … no long string of 1’s or 0’s • (Manchester code … no more than two consecutive logic levels in a row) • The code should be binary so OOK can be used with LEDs (no “half on” state) Manchester Code Spectrum at input to LED modulator Fclock

6. It is important that the spectrum of the modulation be shifted away from DC because at the output of the photodetector other “non-VLC modulated” interfering light sources have significant energy in the vicinity of DC. Demodulator bandpass filtering Inteference modulation domain spectrum VLC modulated light spectrum Fclock Manchester Code Spectrum (main lobe) plus inteference at the output of the photodetector 0 1 0 At this point the Manchester signal looks very much like BPSK +V -V photodetector Bandpass Filter Demodulator The bandpass filter “AC” coupling restores the bi-polar signal levels and also significantly filters out the interference energy.

7. Co-existence between Low Rate PHY and High Rate PHY Modulation Domain Frequency Plan Low Rate PHY Modulation Spectrum High Rate PHY Modulation Spectrum guard band ~TBD ~250 KHz The Low Rate PHY and the High Rate PHY co-exist by occupying different frequency bands in the modulation domain. They do not interoperate. Which PHY to build for a particular application is up to the implementer.

8. Spectrum Coexistence simulation for High Rate and Low Rate PHYs >35 dB High Rate Phy Roll Off

9. Separation of Low Rate Signal and High Rate Signal via Filtering 10 uS/div Note: the potential for the usual near/far problem still exists. 100 nS/div

11. Sources of Intersymbol Interference in VLC and the need for an RX equalizer The current Intel VLC demo (as of the date of this document) is running a chipping rate of 230 Kchips/sec. Even at this low rate we are seeing interchip interference caused by the low pass nature of the LED light panels. In the most severe case – that of the LED back lighting for an LCD HDTV display – the LED circuits frequency response was giving 2 chips of interference. A model of the circuit is shown below. VLC LED Light Panel Implicit Low Pass Filter Ideal LED Model VLC Modulator VLC TX Data Of the many possible solutions – including the complete redesign of the LCD TV’s LED back lighting circuits – one of the most practical is the use of an adaptive equalizer in the receiver to correct the intersymbol interference. Of course, the equalizer will need a training sequence … which could be implicit as part of the preamble or explicit as an optional sequence after the preamble.

12. Packet Structure (identical for both PHY types) Preamble & Training Sequence SFD PHY Header MAC Header CRC All field lengths and bit definitions are TBD We are currently advocating having a length field in the PHY header as opposed to an EOF (end of field) delimiter.

13. PHY Layer Signal Processing Symbol Mapper +1+V -10 FEC Encoder (TBD) Channel Encoding (i.e. Manchester) Bit Source Frame Formatter LED Driver LED Note: it is believed we should include FEC in the standard. But to properly select an FEC we need contributions on the nature of VLC errors; that is, for VLC do errors occur randomly or do the errors come in bursts?

14. Frame Flicker Compensation To prevent the LED from appearing “dimmer” during the packet frame transmission time, an idle pattern is sent between frames that has the same duty cycle as the modulated frame but the pulse repetition rate (exact repetition rate is TBD) is set much lower so as not to cause “in band” interference with any VLC modulation. Idle Pattern Idle Pattern VLC Data Frame Idle pattern between frames – 1010 pattern with a frequency of approximately 200 Hz idle pattern interference non-modulated light interference VLC data Fclock

15. Modulation Modification to Accommodate Light Dimming The information in regards to light dimming requirements is intercepted by the VLC modulator as shown below. Symbol Mapper +1+V -10 FEC Encoder (TBD) Channel Encoding (i.e. Manchester) Frame Formatter Bit Source LED Driver LED Light Dimmer Input OFF time is inserted into either the idle pattern or into the data frame, as shown below, to reduce the average intensity of the light. Idle Pattern Idle Pattern VLC Data Frame over the duration of the frame, the dead time results in a reduced duty cycle 001001001001001 i.e. duty cycle of ½  1/3 The impact on the data rate is the data rate decreases as the light gets dimmer.

16. On the subject of RANGE The reader will notice that there is a lack of discussion in our proposal on range (meters). This is because in theory an arbitrarily intense signal source can be used with arbitrarily powerful optics (aperture) at the receiver to achieve just about any reasonable range. The intensity of the light source and the strength of the optics is an implementation issue and is out of scope of the standard. Talking about range just confuses the discussion with issues that are out of scope of the standard. Modulator huge LED sign board photodetector Demodulator high power telescope

17. PHY Summary • Two PHY Types: Low Rate PHY (~100 kbps) and High Rate PHY (~10 Mbps) • Manchester Coding (mapping +1 is full intensity, -1 is much reduced intensity) • Packet Structure has a preamble/training sequence, SFD, PHY Header and Mac Header • FEC should be included in the standard but have no particular recommendation • Frame Flicker compensation is done by sending a low rate idle pattern between frames • Light Dimming is accommodated by inserting dead time into the VLC Data Frame and idle pattern (lowers Eb/No)

18. MAC Layer

19. Three MAC Modes • We believe the VLC MAC needs to support 3 modes based on applications/usages: • Information Broadcast (IB) mode • VLC Local Area Network (VLAN) mode • Peer-to-peer (P2P) mode VLAN Mode IB Mode P2P Mode Connected VLC node Source VLC node 2 VLC node 1 Sink Node … … Sink Sink Node Node Bidirectional unicast Bidirectional star topology Unidirectional broadcast of information

20. MAC design principles Efficient and simple to implement: Define a low-complexity low-overhead MAC protocol. Flexible: Define a single MAC protocol to support all three modes. Allows applications/usages to use any mode with minimal changes to MAC. Credible: Define a MAC protocol based on other well known industry standards with working products. Our MAC proposal is based on IEEE 802.15.4 MAC and IEEE 802.11 MAC with respect to - Supported topologies - Frame formats - MAC commands

21. MAC Design Considerations • VLC is directional and the receiver (photo detector) and transmitter (LED) are physically separate with different radiation patterns. • Due to directionality and the physical separation of transmitter and receiver on a VLC node, Carrier Sense is of little/no value. • Due to the proposed use cases, directionality and receiver capabilities, we expect abundant spatial re-use and hence low packet collision probability. • Random access is known to provide low-overhead and efficient performance for the applications and operational modes of interest, and with low implementation complexity. • An optional handshake mechanism before data transmission allows potential coordination/adjustments between/within sender and receiver nodes prior to data transmission.

22. MAC Overview • All VLC nodes use Random Access to access the channel • Transmission follows a random duration of silence • All packets contain duration field • Node receiving a packet with duration field freezes the random silence period counter till the duration is over -- duration field establishes reservation • Two nodes communicating with one another may use a handshake mechanism • For frames needing a response (such as ACK), the sender increases its random silence period if response is not received. Packet 3 arrives at MAC A for transmission Packet 1arrives at MAC A for transmission Packet 3Transmission Packet 1Transmission Node A Collision at the receiver No ACK returned Random silence period before transmission Random silence period increased for the following transmission attempts Random silence period before transmission Packet 2 arrives at MAC B for transmission Packet 2 Transmission Node B Random silence period before transmission

23. MAC Functional Description beacons • Super frame structure • Beacon (optional) • Random Access Period • All MAC packet types belong to one of two MAC packet transmission functions • Broadcast/Multicast transmission function: Supports unidirectional data transmission from one node to one/multiple nodes. • Unicast transmission function: Supports bidirectional data transmission between 2 nodes. • Medium access mechanism for both packet transmission functions is random access. • Specific rules vary based on transmission function (next 2 slides) Random Access Period time Beaconing Period

24. Broadcast/Multicast Function • Unidirectional data transmission from one source to multiple receivers • There is no acknowledgment • There is no carrier sense before transmission • There is a random interval, i.e., a duration of silence, between transmission periods • Transmission periods can include multiple MAC packet transmissions • When packets with duration fields set are received, RSP is frozen for the duration Transmission Period Transmission Period Transmission Period time RSP3 RSP2 RSP1 • Parameters to be defined: • Random Silence Period (RSP) (min , max) – used to differentiate service classes & avoid collisions • Data Transmission duration (max) Note 1: All WPAN/WLAN standards allow for not requiring MAC level acknowledgment Note 2: With multiple destination (broadcast/multicast) requiring ACK is not feasible Note 3: Either FCS or some type of CRC is used on all MAC frames

25. Unicast Function • Bidirectional data transmission between two nodes • Data transmission part of an optional four-way handshake mechanism • sender: RTS (request to send) (optional) • receiver: CTS (clear to send) • sender: data packets transmitted during transmission period • receiver: ACK (acknowledgement) • An ACK can be combined with an RTS to initiate transmission of data in the other direction • There is no carrier sense before transmission of RTS. RTS is optional. • There is a random interval, i.e., a duration of silence, between transmissions of RTSs. • RSP exponentially increases if no CTS or ACK received. • When packets with duration fields set are received, RSP is frozen for the duration Transmission Period CTS ACK RTS Node A RSP time Transmission Period ACK+RTS CTS Node B

26. MAC modes and transmission functions • VLAN mode/P2P mode • Discovery Phase broadcast • Association Phase unicast exchange • Data Exchange Phase unicast/multicast/broadcast • IB mode • Data broadcast phase broadcast VLC Node 2 VLC Node2 VLC Node 1 VLC Node1 Discovery Phase Note1: it is expected that the connected VLC node in VLAN will use beaconing mechanism for discovery Note2: VLAN and P2P modes can make use of packet duration feature to establish medium reservations for more efficient medium access. Association Phase Data Exchange Phase Data broadcast Data broadcast Data broadcast …

27. MAC frame formats Payload FCS Duration Frame Control Source Address Sequence Number VLN* Identifier Destination Address Frame Type Security Field Frame Pending Reserved Ack request Frame Control (~1Byte) Command Type Command Payload Payload for MAC Command Frame Types Command Types Discovery Request/Response Association Request/Response RTS/CTS Reserved Beacon Data Acknowledgement MAC command Reserved * VLN: VLC Network, i.e., a network consisting of VLC capable nodes.

28. MAC Summary • Three MAC modes • IB, VLAN, P2P • Single medium access scheme for all modes • Random access; considering low overhead/complexity • Two packet transmission functions • Broadcast/Multicast: single packet broadcast • Unicast: optional 4 way bi-directional messaging • Many packet types: Beacon, Data, ACK, Command.. • MAC modes can flexibly use packet transmission functions and packet types to suit their needs.

29. Backup Material

30. Image Array Processing and MAC access protocol

31. An image array offers the possibility of spatial separation using techniques that have been used in cameras for over 150 years … Detector Array Lens The ability of the image array to spatially resolve objects is dependent upon a number of parameters such as the pixel size, the lens focal length, the number of pixels, etc.; that is, a given image array will have an associated field of view (FOV) for each pixel. Within this FOV it is still possible for more than one VLC modulated light source to be present resulting in collisions; hence, even with an image array we believe we need a MAC access mechanism that can circumvent packet collisions.

32. Mechanism for compensating for collisions within the sensor FOV Within a given FOV there is a probability of collisions from multiple sources. For the broadcast mode, we propose a random access time function - along with repetitive broadcast of the information – to statistically ensure the message will eventually get through without a collision. The messages eventually get through Message A TXA Attempt #1 TXA Attempt #2 Random Time #1A Random Time #2A TXA Attempt #3 Random Time #3A collision collision Message B TXB Attempt #3 Random Time #3B TXB Attempt #2 Random Time #1B Random Time #2B TXB Attempt #1 The times a broadcast message is repeated is a variable parameter, along with the length of the random time delays. Note that as the FOV decreases the likelihood of a collision decreases. Thus, the FOV becomes an implementation parameter and the degenerate case of a single photodetector becomes just a “low performing subset” of the more general image array problem.

33. A Parameterized Random Access Mechanism • We believe that for information broadcasts a parameterized random access mechanism is needed to circumvent collisions. Some of the values that can be parameterized are: • Length of Broadcast Packet • Minimum/Maximum length of time delay • Number of Broadcast Tries • etc. • The value of these parameters are determined by either the application or are left up to the implementer. • As indicated on the previous page, the value of these parameters might be heavily influenced by the FOV of the optics.

34. An example of FOV for a given pixel Lens Image Array Distance D At distances associated with vehicular VLC, it is entirely possible that the FOV for a given pixel in an image array will ingest multiple VLC sources. The actual FOV is a design trade-off and is an implementation issue. Ingest area is proportional to the distance: the longer the distance the bigger the area.