MAC Layer Support for Multiple Optical Frontends

1. Kai Lennert Bober, HHI Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title:IEEE P802.15.13 – MAC layer support for multiple optical frontends Date Submitted: 13. November 2018 Source: Kai Lennert Bober, Volker Jungnickel [Fraunhofer HHI] Address: Einsteinufer 37, 10587 Berlin, Germany Voice:[+49-30-31002 302], E-Mail:[kai.lennert.bober@hhi.fraunhofer.de] Voice:[+49-30-31002 768], E-Mail:[volker.jungnickel@hhi.fraunhofer.de] Re: Abstract: Purpose:Contribution to IEEE 802.15.13 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. Kai Lennert Bober, HHI IEEE P802.15.13 MAC Layer support for Multiple Optical Frontends Date:2018-11-13 Place: Bangkok, Thailand Authors:

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 bewell 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 OFE Ports TRX TRX TRX TRX TRX TRX TRX TRX … 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 GTS = TIME + SPACE reservation “Superframe slots” = TIME 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 channel est. Multi-cell 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. 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. 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 GTS descriptor GTS descriptorlist 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 data frame management frame control frame Multi-cell channel est. Kai Lennert Bober, HHI

14. Backup slides Kai Lennert Bober, HHI

15. 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 • 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 • 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