1. <author>, <company>
<month year>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: IEEE P – MAC layer support for multiple optical frontends
Date Submitted: 13. November 2018
Source: Kai Lennert Bober, Volker Jungnickel [Fraunhofer HHI]
Address: Einsteinufer 37, Berlin, Germany
Voice:[ ],
Voice:[ ],
Re:
Abstract:
Purpose: Contribution to IEEE
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
Kai Lennert Bober, HHI
<author>, <company>

2. IEEE P802.15.13 MAC Layer support for Multiple Optical Frontends
<month year>
IEEE P MAC Layer support for Multiple Optical Frontends
Date: Place: Bangkok, Thailand
Authors:
Kai Lennert Bober, HHI
<author>, <company>

3. Content
This doc. contains a proposal for protocol procedures and frame types, necessary to support distributed optical frontends and MIMO techniques in the star topology.
Kai Lennert Bober, HHI

4. Targets of the Distributed Optical Frontend (OFE) Approach
Introduction of spatial diversity on the signal level
Enable spatial reuse with smooth handover performance and high QoS
Low level “soft handover”: OFE form virtual cells following the device’s movement, fully transparent to the management protocol
Coordinator
Fronthaul
Optical Frontend
Device
OWC signal
Fig 1: Coordinator in star topology with distributed OFEs serving two devices simultaneously
Kai Lennert Bober, HHI

5. Fronthaul Technologies and Functional Split
The coordinator’s PHY is connected with the its OFEs via fronthaul
The implementation of the fronthaul is out of scope.
Analog fronthaul could be plain coax cable, or fiber transport of analog signals
Digital fronthaul could be transport of digitized waveform samples (CPRI)
A splitting of signal chain functionality, as also discussed as “new functional splits” in mobile networks can be facilitated
Digital fronthaul transport technologies are currently being investigated in the context of mobile networks and requirements are being defined in different standardization activities:
eCPRI
IEEE 802.1CM …
Kai Lennert Bober, HHI

6. Fronthaul Delay
Fronthaul virtually increases propagation delay. Order is up to ~100 µs.
Different fronthaul delays tF must be approximately compensated for all OFEs  remaining delay differences between air times at different OFEs must be very small.
In addition, different propagation delays must be handled.
Total reception time differences from different OFEs must be well below ½ cyclic prefix duration. tF
Downlink
transmission tP
Kai Lennert Bober, HHI

7. PHY Support of Multiple OFEs
PHY of the coordinator has multiple transmit- and receive chains (TRX chains) and multiple ports for OFEs (OFE-Ports).
Fronthaul is transparently included in logical PHY by the implementer
TX for each PSDU via PD-SAP
On which OFEs to transmit
Delay difference compensation per OFE (in opt. clock cycles. Optionally: decimal places of optical clock cycles).
RX configuration through PLME-SAP
Groups of OFEs in virtual cells for combining in uplink.
TRX-chains of cells interoperate.
PD-SAP PLME-SAP
PHY …
TRX
OFE Ports
PHY with multiple TRX
chains and OFE-Ports
Kai Lennert Bober, HHI

8. Superframe Structure for Spatial Reuse and Joint Transmission + Reception
Beacon
CAP
CFP
Slotted uplink random access without carrier sensing (ALOHA) in CAP. For association and reconnection only; collisions may occur.
GTS allocations per device for regular collision-free transmission and in the CFP.
Different GTS allocated in same superframe slot but different OFE slots (SDMA).
GTS spans over multiple OFE slots, implying a “virtual cell” for joint transmission / reception.
Receive A
“OFE slots“ =
SPACE
Receive B
Receive C
Receive D
“Superframe slots” = TIME
GTS = TIME + SPACE reservation
Concept of superframe structure. Only receive (downlink)
direction is considered for simplicity. A,B,C,D = devices.
Kai Lennert Bober, HHI

9. Channel Estimation, CSI Feedback and GTS Update
Multicell channel estimation is based on multi-cell pilots in the beacon. For individual virtual cell transmissions, additional desired BAT or MCS feedback can be generated.
The coordinator schedules GTS based on feedback (channel, queues) and selects adaptive transmission.
Dynamic GTSs are updated via control frames and valid for one or multiple superframes. GTS update is acknowledged in next feedback frame.
scheduling
channel est. BP
CAP
CFP
Coordinator
beacon
feedback
dynamic GTS
Device
control frame
Multi-cell channel est.
channel est.
Kai Lennert Bober, HHI

10. Multi-cell channel estimation feedback
TAP format for the setting of variable resolutions for the taps
Symbol (1-7) + division (1-32) for pilot / OFE identification.
Strength for first tap is SNR [dB].
For other TAPs it is the ratio [dB] between first and current TAP
First OFE / TAP is the one with lowest delay.
Bits: 0-3
4-7
Variable
Number of OFEs
TAP format
OFE
descriptor 1 …
Bits: 0-2
3-7
8-15
Variable
Symbol
Division
Number of TAPs
TAP descriptor 1 …
Bits: 0-7 ?
8-15 ?
16-23 ?
Strength
Integer delay
Decimal delay
Kai Lennert Bober, HHI

11. Adaptive modulation and coding feedback
Desired MCS requests transmitter to use a specific MCS.
When transmitter does not apply a correct MCS, control frame is repeated.
Bits: 0-7
Requested MCS
Kai Lennert Bober, HHI

12. Dynamic GTS descriptor
GTS allocations via the GTS update frame or via the beacon frame as already present in the standard
Validity field specifies number of superframes the GTS is valid in ?
0/8
GTS Start Slot
GTS
Length
Validity
GTS descriptor
Bits: 0-7 8
9-15
variable
GTS Descriptor
Count
Validity
Present
reserved
GTS
Descriptors
GTS descriptor list
Kai Lennert Bober, HHI

13. Typical superframe
New devices or devices that lost the connection and do not have GTSs allocated can transmit association requests and reconnection feedback frames in the CAP.
All other control- management- and data transmissions are performed in GTS in the CFP
channel est. BP
CAP
CFP CO
beacon
IDLE
IDLE
IDLE
DEV
macro slot
Multi-cell channel est.
control frame
management frame
data frame
Kai Lennert Bober, HHI

14. September 2018
Backup slides
Kai Lennert Bober, HHI

15. Data and Management Transmission
September 2018
Data and Management Transmission
Data and management frames are transmitted in the corresponding GTSs.
Due to the separation of uplink and downlink, as well as the potentially large delay introduced by the fronthaul, delayed- or block acknowledgment is used.
Acknowledgment information is transmitted in control frames. BP
CAP
CFP CU
data +
management
data +
management MU
Kai Lennert Bober, HHI

16. Transmission by Devices
September 2018
Transmission by Devices
Devices are only allowed to transmit if they received the beacon frame in the corresponding superframe (as currently in the draft).
Non-synchronous „blind“ transmission is thereby ruled out.
Upon recovered beacon reception after beacon tracking loss, feedback is transmitted again in known GTSs or in the CAP if no GTS allocation is present.
Kai Lennert Bober, HHI

17. Scheduling of (Dynamic) GTS
September 2018
Scheduling of (Dynamic) GTS
The details of GTS allocation are left to the implementer‘s discretion.
Implementers can differentiate themselves through proprietary scheduling algorithms.
For regular control exchange, each device must have at least a single GTS allocated periodically.
TDD operation:
The coordinator/scheduler can separate uplink and downlink network-wide through corresponding clever allocation of the uplink- and downlink GTSs.
Support of low delays and cycle times for industrial traffic:
If every device can have at most a single GTS allocated in each superframe, packets to be transmitted can experience a long queueing delay if the superframe is long and the GTS is valid only in a small portion of the superframe.
To prevent large queueing delays it should be possible to allocate multiple GTSs per device for each downlink and uplink respectively in each superframe.
Kai Lennert Bober, HHI