IEEE 802.11-17/0130r1 Link Maintenance for Distribution Networks Overview

Slide Note
Embed
Share

Presented in January 2018, the document IEEE 802.11-17/0130r1 discusses functions for maintaining operational links in mmWave Distribution Networks, including link adaptation, bandwidth request, reservation, and time synchronization. It provides a comprehensive insight into the tools and protocols required to operate these networks efficiently, emphasizing parallels with existing mechanisms in 802.11. Sample packet definitions like Heartbeat and KeepAlive frames are also outlined in the document.


Uploaded on Nov 13, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. January 2018 doc.: IEEE 802.11-17/0130r1 Link Maintenance for Distribution Networks Name Affiliation Address Phone Email Djordje Tujkovic Facebook 1 Hacker Way Menlo Park, CA 94025 djordjet@fb.com Nabeel Ahmed nabeel@fb.com Praveen Gopala gopalap@fb.com Alireza Mehrabani tarighat@fb.com Payam Torab ptorab@fb.com Michael Grigat Deutsche Telekom Deutsche-Telekom-Allee 7, 64372 Darmstadt, Germany m.grigat@telekom.de Submission 1 Djordje Tujkovic et al.

  2. January 2018 doc.: IEEE 802.11-17/0130r1 Overview We present a set of functions to maintain operational links in mmWave Distribution Networks [1, 2], together with our example implementation Discussed functions 1) Link adaptation 2) Bandwidth request 3) Bandwidth reservation (TDD slot assignment) 4) Time synchronization For the first two we point to parallels with 802.11 existing mechanisms and highlight potential gaps The slides could be viewed as a set of requirements for tools (packets, protocols) needed to operate mmWave Distribution Networks Submission 2 Djordje Tujkovic et al.

  3. January 2018 doc.: IEEE 802.11-17/0130r1 Background Sample Packet definitions (1) Heartbeat, KeepAlive Action frames Heartbeat message (Action frame), transmitted from a a DN node to a CN node once every BWGD (~25 milliseconds) Keepalive message (Action frame) transmitted between two DNs once every BWGD (~25 milliseconds) typedef struct _fbKeepaliveElement { /* timestamp and swTimestamp are byte arrays to avoid unaligned accesses */ usint8 timestamp[8]; /* hardware timestamp */ usint8 swTimestamp[8]; /* sw timestamp offset from hw timestamp */ usint16 bwgdNumber; usint8 bfAssocIndication; usint8 finalRxSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; usint8 rsvdMgmtBitmap[TGF_CEIL(NSF, BITS_PER_BYTE)]; laFeedbackParams laFbParams; usint8 syncMode : 1; l2SchedulerStats l2SchedStats; } __attribute__((__packed__)) fbKeepaliveElement; typedef struct _fbHeartbeatElement { /* timestamp and swTimestamp are byte arrays to avoid unaligned accesses */ usint8 timestamp[8]; /* hardware timestamp */ usint8 swTimestamp[8]; /* sw timestamp offset from hw timestamp */ usint16 bwgdNumber; usint8 txSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; usint8 rxSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; laFeedbackParams laFbParams; usint8 syncMode : 1; } __attribute__((__packed__)) fbHeartbeatElement; Submission 3 Djordje Tujkovic et al.

  4. January 2018 doc.: IEEE 802.11-17/0130r1 Background Sample packet definitions (2) Uplink Bandwidth Request Action frame Uplink bandwidth request message (Action frame), transmitted from a a CN node to a DN node once every BWGD (~25 milliseconds) typedef struct _fbUplinkBwReqElement { l2SchedulerStats l2SchedStats; laFeedbackParams laFbParams; } _attribute__((__packed_)) fbUplinkBwReqElement; Submission 4 Djordje Tujkovic et al.

  5. January 2018 doc.: IEEE 802.11-17/0130r1 (1) Link adaptation Frames, Information Sample Distribution Network Frames o Heartbeat, Keepalive, Uplink Bandwidth Request o Association Request/Response/Ack (for future) Parameters typedef struct _laFeedbackParams { sint8 stfMgmtSnr; sint8 rssi; } __attribute__((__packed__)) laFeedbackParams; stfMgmtSnr and rssi can have the same definition as SNR and RSSI in beamforming text In addition, we have recently added the following statistics o Total LDPC codewords o Average LDPC iterations o Average LDPC syndromes o Max LDPC iteration per block within a PPDU Helpful in setting the link to tolerate sporadic SINR without explicitly measuring min(SINR) 802.11 Frames o o Information Elements / Fields o 9.4.2.17 TPC Report element Reports Transmit Power, Link Margin (dB, measured on the Link Measurement Request frame) o 9.4.2.142 DMG Link Margin element Reports Link Margin (dB, implementation specific, measured on plurality of data frames within a measurement period), SNR (dB, measurement methodology undefined) and measurement window information o 9.4.2.143 DMG Link Adaptation Acknowledgment element For TPC controlled by receiver (to acknowledge receiver s MCS/Tx power change request) 9.6.7.4 Link Measurement Request frame format 9.6.7.5 Link Measurement Report frame format Submission 5 Djordje Tujkovic et al.

  6. January 2018 doc.: IEEE 802.11-17/0130r1 Link adaptation LDPC Iteration Statistics (1/3) Average LDPC iteration can be used for accurately predicting PER/BLER. Typical on-chip SNR measurements can be several dB off from true SNR seen by the LDPC decoder. Such SNR measurements are further deviated from true SNR at high and low ends of SNR. Given the static nature of DN compared to SRD, a more accurate and immediate predication of link quality can be very beneficial. Submission 6 Djordje Tujkovic et al.

  7. January 2018 doc.: IEEE 802.11-17/0130r1 Link adaptation LDPC Iteration Statistics (2/3) LDPC iteration averaged over LDPC blocks within a single PPDU (~100 LDPC block), will have very small variance from one PPDU to the next. o Average iterations from a single PPDU can project the long-term PER/BLER within +/-0.2dB accuracy. o At low PER targets (e.g., 0.1%), average LDPC iterations from the first PPDU can accurately predict the lone-term PER over the next 1000s of PPDUs. Submission 7 Djordje Tujkovic et al.

  8. January 2018 doc.: IEEE 802.11-17/0130r1 Link adaptation LDPC Iteration Statistics (3/3) Consider the following simulation scenario: 1000 PPDUs, MCS=9, SNR for all PPDUs=8dB, number of LDPC blocks per PPDU = 100. Histograms of avg(Iterations), and corresponding projected SNR are plotted below. The narrow standard deviation confirms the reliability of link quality projection based on LDPC iterations. Using a single PPDU, BLER/SNR is projected within 0.2dB of the true 8dB value. 0.4 0.18 0.16 0.35 0.14 0.3 0.12 0.25 Probability Probablity 0.1 0.2 0.08 0.15 0.06 0.1 0.04 0.05 0.02 0 0 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 9 10 Average LDPC Iteration (per PPDU) SNR Calculated from Avg Iter (Per PPDU)# Submission 8 Djordje Tujkovic et al.

  9. January 2018 doc.: IEEE 802.11-17/0130r1 Link adaptation LDPC Iteration to Predict min(SINR) (1/2) In the presence of co-channel interference (CCI), direct calculation of min(SINR) becomes challenging and unreliable. o Given the static nature of CCI profile in distributed networks, Link adaptation should be set based on min(SINR) and not avg(SINR) within the PPDUs. While avg(Iterations) over DLPC blocks within a PPDU works well in the absence of interference, it fails to predict the link s PER in the presence of not-fully-aligned desired and interfering PPDUs. For a received PPDU, PHY would provide both the following values: average of LDPC iterations and max of LDPC iterations over the LDPC blocks within a PPDU. Furthermore, the difference between avg(Iterations) and max(Iterations) can be used to determine link s CCI profile/characteristics by calculating SNR, min(SINR), and proportion of target PPDU impacted by CCI. Submission 9 Djordje Tujkovic et al.

  10. January 2018 doc.: IEEE 802.11-17/0130r1 Link adaptation LDPC Iteration to Predict min(SINR) (2/2) Consider a desired PPDU with 100 LDPC blocks: MCS=9 Only the last 20% of PPDU duration is hit by co-channel interference avg(Iteration) over the PPDU = 0.8 to SINR=9dB o Too optimistic for link adaptation max(Iteration) over the PPDU = 4 to SINR=5.9dB o Suitable for link adaptation (0.6dB margin to actual SINR floor of 6.5dB) 4 3.5 LDPC Iteration per Block 3 2.5 2 1.5 maps 1 0.5 0 0 10 20 30 40 50 60 70 80 90 100 LDPC Block Number within PPDU# maps SNR=10dB, SIR=9dB, SINR=6.5dB Co-Channel Interference SNR=10dB, SINR=10dB LDPC #1 LDPC #2 LDPC #80 LDPC #81 LDPC #100 Target PPDU Submission 10 Djordje Tujkovic et al.

  11. January 2018 doc.: IEEE 802.11-17/0130r1 Link adaptation 802.11 functional gaps 1) SNR measurement method o Post equalization 2) SNR measurement period o Start and end time for measurement 3) RSSI 4) Short-term PER measurement (LDPC statistics) 5) Confidence interval (number of PPDUs used for measurement) Submission 11 Djordje Tujkovic et al.

  12. January 2018 doc.: IEEE 802.11-17/0130r1 (2) Bandwidth request Frames, information Sample Distribution Network Frames o Uplink Bandwidth Request (CN => DN) o Keepalive (DN < = > DN) Parameters (not all used at the same time) typedef struct _l2SchedulerStats { // Queue size (in 256-byte units) usint16 queueSize; // Arrival rate (in units of 128 Kbps or 16 bytes/ms) usint16 arrivalRate; // MCS value usint8 mcs; // Requested Tx percentage in unit of 0.01 percent (used only for DN-DN links) usint16 reqTxPercent; } __attribute__((__packed__)) l2SchedulerStats; 802.11 Frames o Information Elements / Fields o Queue Size (non-DMG) 8 bits, in units of 256 bytes (per TID) o TSPEC Some metrics (arrival rate, Tx air percentage) missing o DMG TSPEC Not a good fit (good for creating SP/CBAP allocations) QoS Data frames (non-DMG) Submission 12 Djordje Tujkovic et al.

  13. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth request 802.11 functional gaps Queue size (and with TID granularity) o Removed from DMG Derivative feedback (queue size change rate) o Start and end time for measurement Measurement period Submission 13 Djordje Tujkovic et al.

  14. January 2018 doc.: IEEE 802.11-17/0130r1 (3) Bandwidth reservation (slot allocation) Overview Network time divided into time periods over which slot allocation (map) is valid (called Bandwidth Grant Duration (BWGD = 25,600 s)) Slots are allocated through a 3-stage pipeline process o BWGD N+0 CNs communicate their bandwidth requirements to the parent DN (Uplink bandwidth request) Communicated information: Queue size (in units of 256 bytes), arrival rate (in units of 128 kbps) DNs communicate their bandwidth requirement to peer DNs (Keepalive message) Communicated information: Queue size, desired transmit airtime percentage to peer DN Using above pieces each DN assigns its own Rx slots (slots where other STAs will transmit to it) o BWGD N+1 DNs communicate their assigned Rx slot bitmap to each other (Keepalive message) With all DN-DN slots decided, each DN allocates remaining airtime (TX map) to its own CNs o BWGD N+2 Each DN communicates full Tx/Rx slot bitmap to CNs under its control o BWGD N+3 Slot map takes effect Submission 14 Djordje Tujkovic et al.

  15. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation flow 3-stage pipelining Keepalive message Uplink BW Request message Uplink BW Request message Keepalive message Heartbeat message Heartbeat message Submission 15 Djordje Tujkovic et al.

  16. January 2018 Bandwidth reservation flow 3-stage pipelining (another view) doc.: IEEE 802.11-17/0130r1 Submission 16 Djordje Tujkovic et al.

  17. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation example Submission 17 Djordje Tujkovic et al.

  18. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation example BWGD N + 0 Each DN sends/receives desired Tx slot bitmaps (or time %) and L2 scheduler statistics to/from all peer DNs through Keepalive messages Each DN receives bandwidth requirements from all its associated CNs through Uplink BW request messages typedef struct _fbKeepaliveElement { /* timestamp and swTimestamp are byte arrays to avoid unaligned accesses */ usint8 timestamp[8]; /* hardware timestamp */ usint8 swTimestamp[8]; /* sw timestamp offset from hw timestamp */ usint16 bwgdNumber; usint8 bfAssocIndication; usint8 finalRxSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; usint8 rsvdMgmtBitmap[TGF_CEIL(NSF, BITS_PER_BYTE)]; // constraints (do not ask me to transmit during these slots) laFeedbackParams laFbParams; usint8 syncMode : 1; l2SchedulerStats l2SchedStats; // entire structure is used } __attribute__((__packed__)) fbKeepaliveElement; typedef struct _fbUplinkBwReqElement { l2SchedulerStats l2SchedStats; // entire structure except requested Tx Percentage; wich is used only for DNs laFeedbackParams laFbParams; } _attribute__((__packed_)) fbUplinkBwReqElement; and other bandwidth information same as in CNs and other bandwidth information same as in CNs TX RX TX RX Submission 18 Djordje Tujkovic et al.

  19. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation example BWGD N + 1 Each DN generates its full Rx slot map with slots for all associated peers TX RX TX RX CN0 CN0 DN1DN1 DN1DN1 DN1DN1 DN0 DN0 CN1 CN1 DN0 DN0 CN2 CN2 Submission 19 Djordje Tujkovic et al.

  20. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation example BWGD N + 1 Each DN sends/receives the decided (final) Rx slot bitmaps to/from all peer DNs through KeepAlive messages typedef struct _fbKeepaliveElement { /* timestamp and swTimestamp are byte arrays to avoid unaligned accesses */ usint8 timestamp[8]; /* hardware timestamp */ usint8 swTimestamp[8]; /* sw timestamp offset from hw timestamp */ usint16 bwgdNumber; usint8 bfAssocIndication; usint8 finalRxSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; usint8 rsvdMgmtBitmap[TGF_CEIL(NSF, BITS_PER_BYTE)]; laFeedbackParams laFbParams; usint8 syncMode : 1; l2SchedulerStats l2SchedStats; } __attribute__((__packed__)) fbKeepaliveElement; TX RX TX RX DN1DN1 CN0 CN0 DN1DN1 DN1DN1 DN1DN1 DN0 DN0 CN1 CN1 DN0 DN0 CN2 CN2 DN0 DN0 DN0 DN0 DN0 DN0 DN1DN1 Submission 20 Djordje Tujkovic et al.

  21. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation example BWGD N + 2 Each DN allocates the remaining Tx slots to its associated CNs TX RX TX RX DN1DN1 CN0 CN0 DN1DN1 CN0 CN0 CN0 CN0 DN1DN1 DN1DN1 DN1DN1 CN1 CN2 DN0 DN0 DN0 DN0 DN0 DN0 DN0 DN0 CN1 CN1 DN0 DN0 CN2 CN2 Submission 21 Djordje Tujkovic et al.

  22. January 2018 doc.: IEEE 802.11-17/0130r1 Bandwidth reservation example BWGD N + 2 Each DN sends Tx/Rx slot bitmaps to all associated CNs through Heartbeat messages typedef struct _fbHeartbeatElement { /* timestamp and swTimestamp are byte arrays to avoid unaligned accesses */ usint8 timestamp[8]; /* hardware timestamp */ usint8 swTimestamp[8]; /* sw timestamp offset from hw timestamp */ usint16 bwgdNumber; usint8 txSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; usint8 rxSlotBitmap[TGF_CEIL(SLOTS_IN_BWGD, BITS_PER_BYTE)]; laFeedbackParams laFbParams; usint8 syncMode : 1; } __attribute__((__packed__)) fbHeartbeatElement; TX RX TX RX DN0DN0 DN1 DN0DN0 DN1DN1 DN0DN0 TX RX TX RX DN1DN1 CN0 CN0 DN1DN1 CN0 CN0 CN0 CN0 DN1DN1 DN1DN1 DN1DN1 CN1 CN2 DN0 DN0 DN0 DN0 DN0 DN0 DN0 DN0 CN1 CN1 DN0 DN0 CN2 CN2 TX RX DN1 DN1 DN1 Submission 22 Djordje Tujkovic et al.

  23. January 2018 doc.: IEEE 802.11-17/0130r1 (4) Time Synchronization Overview Network requires global time synchronization to drive transmission/ reception of frames using negotiated slot allocation (map). Otherwise, neighboring links potentially interfere, causing network self-interference. Network nodes are in one of these time synchronization states: o Global sync: Node is time sync ed to external PPS source. o RF sync: Node is sync ed over-the-air to Globally sync ed peer node. o No sync: Node is out of sync with network time. To avoid network self-interference, a link is maintained if at least one of the two nodes is in global sync mode. Time sync status of nodes is conveyed through syncMode field in HeartBeat/ KeepAlive frames. If a node enters RF sync, it derives time using timestamp and swTimestamp fields conveyed in HeartBeat/KeepAlive frames from peer node. Submission 23 Djordje Tujkovic et al.

  24. January 2018 doc.: IEEE 802.11-17/0130r1 Summary We described 4 aspects of link maintenance in mmWave Distribution Networks We encourage companies to define fields, IEs and messages with these requirements in mind, on top of developed constructs (e.g., Slot Structure and Slot Schedule IEs) in 11ay Draft 1.0 [3]. Submission 24 Djordje Tujkovic et al.

  25. January 2018 doc.: IEEE 802.11-17/0130r1 References [1] IEEE 802.11-17/1019r2 mmWave Mesh Network Usage Model [2] IEEE 802.11-17/1321r0 Features for mmW Distribution Network Use Case [3] IEEE 802.11ay Draft 1.0 Submission 25 Djordje Tujkovic et al.

Related


More Related Content