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: ,
Re:
Abstract:
Purpose:
Notice: This document has been prepared to assist the IEEE P 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 P

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. ~100 Kbps packet body burst rate
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)
Manchester Coding is very similar to BPSK modulation +1 +1
Data
Data -1 -1 +1 +1
Clock LO -1 -1
Manchester Encoding
BPSK

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.
Inteference modulation domain spectrum
Demodulator bandpass filtering
VLC modulated light spectrum
Fclock
Manchester Code Spectrum (main lobe) plus inteference at the output of the photodetector 1
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. Modulation Domain Frequency Plan
Co-existence between Low Rate PHY and High Rate PHY
Modulation Domain Frequency Plan
Low Rate PHY
Modulation Spectrum
~250 KHz
High Rate PHY
~TBD
guard
band
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. Preamble & Training Sequence
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
FEC
Encoder
(TBD)
Channel
Encoding
(i.e. Manchester)
Symbol
Mapper
+1+V
-10
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
VLC Data Frame
Idle Pattern
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)
Bit
Source
Frame
Formatter
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
VLC Data Frame
Idle Pattern
over the duration of the frame, the dead time results in a reduced duty cycle
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
IB Mode
VLAN Mode
P2P Mode
Connected VLC node
Source
VLC node 1
VLC node 2
Sink
Node … …
Sink
Sink
Node
Node
Unidirectional broadcast of information
Bidirectional star topology
Bidirectional unicast

20. - Supported topologies - Frame formats - MAC commands
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 MAC and IEEE 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 1arrives
at MAC A
for transmission
Packet 3 arrives
at MAC A
for transmission
Node A
Packet 1Transmission
Packet 3Transmission
Collision at
the receiver
No ACK returned
Random silence period
before transmission
Random silence period
before transmission
Random silence period
increased for the following
transmission attempts
Packet 2 arrives
at MAC B
for transmission
Node B
Packet 2 Transmission
Random silence period
before transmission

23. MAC Functional Description
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. Ex: Beacon, Data
Unicast transmission function: Supports bidirectional data transmission between 2 nodes. Ex: Data, ACK
Medium access mechanism for both packet transmission functions is random access.
Specific rules vary based on transmission function (next 2 slides)
Beaconing Period
Random Access Period
time
beacons

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
RSP1
RSP2
RSP3
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 RTR or ACK received.
When packets with duration fields set are received, RSP is frozen for the duration
RTS
Transmission Period
Node A
CTS
ACK
RSP
time
Transmission Period
Node B
CTS
ACK+RTS

26. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
MAC modes and transmission functions
VLC Node 1
VLC Node 2
Discovery Phase
Association Phase
Data Exchange Phase
VLAN mode/P2P mode
Discovery Phase broadcast
Association Phase unicast exchange
Data Exchange Phase unicast/multicast/broadcast
IB mode
Data broadcast phase broadcast
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.
VLC Node1
VLC Node2
Data broadcast …
<author>, <company>

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

28. MAC Summary Three MAC modes Single medium access scheme for all 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
Random Time #1A
TXA Attempt #1
Random Time #2A
TXA Attempt #2
Random Time #3A
TXA Attempt #3
collision
collision
Message B
Random Time #1B
TXB Attempt #1
Random Time #2B
TXB Attempt #2
Random Time #3B
TXB Attempt #3
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.