1. <author>, <company>
<month year>
September 2018
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: IEEE P – MAC layer support for multiple optical frontends
Date Submitted: 10 Sep. 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>
September 2018
IEEE P MAC Layer support for Multiple Optical Frontends
Date: Place: Waikoloa, Hawaii
Authors:
Kai Lennert Bober, HHI
<author>, <company>

3. September 2018
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
September 2018
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 network layer
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
September 2018
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. September 2018
Fronthaul Delay
Fronthaul virtually increases propagation delay. Order is up to ~100 µs.
Fronthaul delay tF must be known and approximately the same for all OFEs.
Remaining delay differences between air times at different OFEs must be very small, i.e. well below ½ cyclic prefix duration. tF
Downlink
transmission tP
Kai Lennert Bober, HHI

7. PHY Support of Multiple OFEs
September 2018
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).
RX configuration through PLME-SAP
Groups of OFEs in virtual cells for combining in uplink
PD-SAP PLME-SAP
PHY …
TRX
OFE- Ports
PHY with multiple TRX
chains and OFE-Ports
Kai Lennert Bober, HHI

8. September 2018
Superframe Structure for Spatial Reuse and Joint Transmission + Reception BP
CAP
CFP
Slotted uplink random access without carrier sensing in CAP. For association and reconnection only; collisions may occur.
GTS allocations per device for regular transmission and reception 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
Receive B
Receive C
Receive D
Superframe slots
GTS
Concept of superframe structure. Only receive
direction is considered for simplicity. A,B,C,D = devices.
Kai Lennert Bober, HHI

9. September 2018
Dynamic GTS
If the same superframe slots are “reused” in GTSs of different devices (spatial multiplex), mobility can lead to frame collisions when devices with those GTSs approach each other.
Hence, the GTS allocations must be rapidly adapted to mobility.
Keep existing semi-static GTS allocation mechanism via management frames ( and Appendix G in D3).
Proposal: So called dynamic GTSs can be assigned to devices by the coordinator via control frames, in addition to the semi-static GTS allocations.
Dynamic GTS are only valid for a specified number of superframes and shall not be used thereafter.
Semi-static GTSs are still valid unless deallocated via the mgmt. protocol.
Kai Lennert Bober, HHI

10. Dynamic GTS Descriptor
September 2018
Dynamic GTS Descriptor
Dynamic GTS descriptors are transmitted via control frames.
The dynamic GTS descriptor is similar to the semi-static GTS descriptor but has no device address and contains and Validity field.
Validity field in dynamic GTS descriptor may contain the number of subsequent superframes for which a dynamic GTS is assigned.
The other fields are the same as in subclause G.2.1.6
Bits: 0-15
16-19
20-23
Device Short Address
GTS Starting Slot
GTS
Length
Bits: 0-3
4-7
8-15
GTS Starting Slot
GTS
Length
Validity
Semi-static GTS descriptor
Dynamic GTS descriptor
Kai Lennert Bober, HHI

11. Association and Reconnection
September 2018
Association and Reconnection
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.
Proposal: CAP transmission: Slotted Aloha in macro slots which contain multiple superframe slots, which can hold a whole frame each.
Proposal: Estimated downlink CSI is included in random access frame.
channel est. BP
CAP
CFP CO
association /
reconnection
+ feedback
beacon:
multi cell pilots
DEV
macro slot
Multi-cell channel est.
control frame
Kai Lennert Bober, HHI

12. Channel Estimation, CSI Feedback and GTS Update
September 2018
Channel Estimation, CSI Feedback and GTS Update
Channel estimation is based on multi-cell pilots in the beacon. CSI feedback is transmitted regularly via control frames in GTSs.
The coordinator updates the GTS allocations dynamically based on CSI feedback.
Dynamic GTSs are updated via control frames and valid during next superframe, if validity=0, otherwise for multiple superframes. Previous dynamic GTS allocations lose validity. GTS update is acknowledged in next feedback frame.
channel est. BP
CAP
CFP CO
beacon:
multi cell pilots
feedback
GTS update
DEV
control frame
Multi-cell channel est.
channel est.
Kai Lennert Bober, HHI

13. September 2018
Backup slides
Kai Lennert Bober, HHI

14. Device Address Present
September 2018
GTS Descriptor List
Multiple GTS descriptors are contained by the GTS descriptor list field.
GTS Descriptor Count is the number of contained GTS descriptors
Validity Present indicates whether the GTS descriptors have validity fields, i.e. describe dynamic GTSs
Device Address Present indicates whether all descriptors have an Device Address field or the device address is deducted from the corresponding control frame destination address
GTS directions contains a bitmap that describes the corresponding GTSs direction (X = transmit, Y = receive)
GTS Descriptors contains the descriptors
Bits: 0-7 8 9
10-15
variable
GTS Descriptor
Count
Validity
Present
Device Address Present
reserved
GTS Directions
GTS
Descriptors
GTS descriptor list field
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

18. Affected MAC Frames Beacon frame CSI Feedback control frame
September 2018
Affected MAC Frames
Beacon frame
CSI Feedback control frame
Block Acknowledgment control frame
GTS Update control frame
Association request management frame
Kai Lennert Bober, HHI