TDD beamforming configuration
Date: 2019-09-18
Payam Torab, Facebook
Slide1
September 2019
TDD beamforming operations other than Initial Beamforming* are referred to as Beam Measurement in the standardBefore Draft 4.0, these operations were exclusively initiated by (and results reported to) SMERequiring connection to (proprietary) network controllerFor client devices (non-AP STAs) connection to (proprietary) controller is undesirableProprietary connection (software) impedes commercializationWe review some TDD beam measurements operations for some gaps
TDD beamformingBackground
Payam Torab, Facebook
2
September 2019
TDD beamformingBackground
Payam Torab, Facebook
3
August 2019
ProprietaryNetwork Controller
802.11ad PHY
802.11ad|ay MAC
Proprietary Management
802.11ad PHY
802.11ad|ay MAC
Proprietary Management
Standard
Standard
Proprietary
Proprietarymanagement port
Proprietarymanagement port
DN (AP)
CN (non-AP)
ProprietaryNetwork Controller
802.11ad PHY
802.11ad|ay MAC
802.11 Management
802.11ad PHY
802.11ad|ay MAC
802.11 Management
Standard
Standard
Standard
Proprietarymanagement port
DN (AP)
CN (non-AP)
Before Draft 4.0Standard 802.11ay MAC plus some proprietary functionsDNs and CNs requiring proprietary softwareImprovementStandard 802.11ay MAC including standard management functionsDNs requiring proprietary softwareCNs 60 GHz operation entirely specified by 802.11 (no need for proprietary software)
CN with standardized data planeandmanagement plane
TDD Sector Config
Example -- Periodic beamforming (PBF)
Example implementationInitiator transmitting on different Tx beams during beamforming slot every 400 µs, cycling through all Tx beams(Note 1)Transmission pattern repeated 31 times, with responder measuring on a different receive beam during each transmit cycleResponder reporting the result through the controllerNotesEquivalent to an 802.11ad I-TXSS (directional receive)Some or all of Tx beams can be the same, e.g., for averagingKnowing the TDD SSW multiplicity can help with averaging decisionsSet of Rx beams can be null to leave the Rx selection to responder
GeneralizedInitiator trying Ntx transmit beams against Nrx responder’s receive beams, during periodicor irregular (but scheduled)beamforming slots (Nrx = 1 for current implementation)Initiator trying a generally different Tx Beam at every new Beamforming slot (taking Ntx slots for Tx sweep)(Note 2)Responder receiving on each Rx beam Ntx times, so it can try them against all different Tx beamsStart time pointing to start of the first beamforming slot used for operation; schedule assumed consistent with beamforming pattern and durationAllow TDD SSW Feedback and TDD SSW Ack, with option to skipResponder sends SNR report to initiator through TDD Route IE (TDD Sector Feedback subelement)Initiator does not send a SNR report
Payam Torab, Facebook
4
Initiator MLME (and TDD Sector Config fields)Start timePeriod P or schedule (already provided)TDD SSW multiplicity(Note 3)Set of Rx beams(Note 4)Non-AP (CN) can also be the initiatorCan be locally decided by non-AP, or administered through the AP/controllerDecided by non-AP: Send up the request (same arguments minus the schedule), get acknowledgement, schedule, start time (exchange of TDD Sector Config subelement)Decided by AP: Same as runtime Rx calibration, except Tx beam selection is left to non-AP (see the runtime Rx calibration slide)
September 2019
Example – Transmit beam calibration
Example implementationInitiator transmitting on generally different Tx beams during beamforming slot every 400 µs(Note 1, 2)Responder measuring signal in corresponding beamforming slots using the current Rx beamResponder reporting the result through the controllerNotesEquivalent to an 802.11ad I-TXSS (directional receive)Some or all of Tx beams can be the same, e.g., for averagingKnowing the TDD SSW multiplicity can help with averaging decisionsSet of Rx beams can be null to leave the Rx selection to responder
GeneralizedInitiator trying Ntx transmit beams against Nrx responder’s receive beams, during periodicor irregular (but scheduled)beamforming slots (Nrx = 1 for current implementation)Initiator trying a generally different Tx Beam at every new Beamforming slot (taking Ntx slots for Tx sweep)(Note 2)Responder receiving on each Rx beam Ntx times, so it can try them against all different Tx beamsStart time pointing to start of the first beamforming slot used for operation; schedule assumed consistent with beamforming pattern and durationAllow TDD SSW Feedback and TDD SSW Ack, with option to skipResponder sends SNR report to initiator through TDD Route IE (TDD Sector Feedback subelement)Initiator does not send a SNR report
Payam Torab, Facebook
5
Initiator MLME (and TDD Sector Config fields)Start timePeriod P or schedule (already provided)TDD SSW multiplicity(Note 3)Set of Rx beams(Note 4)Non-AP (CN) can also be the initiatorCan be locally decided by non-AP, or administered through the AP/controllerDecided by non-AP: Send up the request (same arguments minus the schedule), get acknowledgement, schedule, start time (exchange of TDD Sector Config subelement)Decided by AP: Same as runtime Rx calibration, except Tx beam selection is left to non-AP (see the runtime Rx calibration slide)
September 2019
Example – Rx Beam calibration
Example implementationInitiator trying generally different Rx beams during each beamforming slot every 400 µs(Note 1, 2)Responder transmitting TDD SSW frames in corresponding beamforming slots on the current Tx beamInitiator reporting the result through the controllerNotesEquivalent to an 802.11ad I-RXSSSome or all of Rx beams can be the same, e.g., for averagingInitiator specifying the TDD SSW multiplicity to control averaging decisionsSet of Rx beams can be null to leave the Rx selection to responder
GeneralizedInitiator trying Nrx receive beams against Ntx responder’s transmit beams, during periodicor irregular (but scheduled)beamforming slots (Ntx = 1 for current implementation)Initiator trying a generally different Rx Beam at every new Beamforming slot (taking Nrx slots for Rx sweep)(Note 2)Responder transmitting on each Tx beam Nrx times, so initiator can try them against all different Rx beamsStart time pointing to start of the first beamforming slot used for operation; schedule assumed consistent with beamforming pattern and durationAllow TDD SSW Feedback and TDD SSW Ack, with option to skipNo SNR report exchanged
Payam Torab, Facebook
6
Initiator MLME (and TDD Sector Config fields)Start timePeriod P or schedule (already provided)TDD SSW multiplicity(Note 3)Set of Tx beams(Note 4)Non-AP (CN) can also be the initiatorCan be locally decided by non-AP, or administered through the AP/controllerDecided by non-AP: Send up the request (same arguments minus the schedule), get acknowledgement, schedule, start time (exchange of TDD Sector Config subelement)Decided by AP: Same as runtime Tx calibration, except Rx beam selection is left to non-AP (see the runtime Tx calibration slide)
September 2019
Example – Interference measurement
Example implementationInitiator transmitting on generally different Tx beams during beamforming slot every 400 µs(Note 1, 2)Broadcast RA for TDD SSW framesMultiple responders measuring signal in corresponding beamforming slots using their current Rx beamsWith invert scan polarity measurement slots are sometimes scheduled in the Tx subframe (i.e., where the device is normally expected to transmit) (supported by Slot Schedule IE general format, no standard change needed)Responders reporting the result through the controllerAny device can be the initiator (DN or CN)No notion of BSS association for different responders (network-level operation)NotesSweep can be repeated (is ended administratively)Some or all of Tx beams can be the same, e.g., for averagingResponder knowing the TDD SSW multiplicity can help with averaging decisionsSet of Rx beams can be null to leave the Rx selection to responderTDD Sector Config exchange for another TA not in BSS
GeneralizedNumber of beamforming slots in the schedule given to initiator does not have to be a multiple of number of scanned Tx beamsFor example, 100 slots may be allocated for interference scan using 31 Tx beamsDifferent responders schedules (and obviously Rx beams)(this is more generalizing the procedure than generalizing any protocol)For example, one responder scanning during a portion of the 100 slots in the above example, while another responder scanning during the entire 100 slots
Payam Torab, Facebook
7
Initiatoror APMLME (and TDD Sector Config fields)Start timePeriod P or schedule (already provided)TDD SSW multiplicity(Note 3)Set of respondersSet of Rx beams(Note 4)TA address (Note 5)Non-AP (CN) can also be the initiatorCan be locally decided by non-AP, or administered through the AP/controllerDecided by non-AP: Send up the request (same arguments minus the schedule,plus list of responders(e.g., some of RAs that have been received), get acknowledgement, schedule, start time (exchange of TDD Sector Config subelement)Decided by AP or another STA outside BSS (request coming to AP through the controller): MLME/AP config parameters above
September 2019
Coordinated beamforming – Transmit training
Example implementationNetwork level interference nulling operation involving an aggressor link and multiple victim links: Finding the Tx beam with least interference to multiple victimsInitiator (on aggressor link) transmitting on generally different Tx beams during beamforming slot every 400 µs(Note 1, 2)Multiple responders (on multiple victim links) receiving on a given Rx beam during beamforming slots allocated to them (with invert scan polarity sometimes this may happen in the opposite subframe)Responders reporting the result through the controllerAny device can be the initiator (DN or CN)No notion of BSS association for different responders (network-level operation)
Payam Torab, Facebook
8
Aggressor link
ATX (initiator)
ARX
Victim link 1
VTX1
VRX1
Victim link 2
VTX2
VRX2
Initiatoror APMLME (and TDD Sector Config fields)Start timePeriod P or schedule (already provided)TDD SSW multiplicity(Note 3)Set of respondersSet of Rx beams(Note 4)TA address (Note 5)Non-AP (CN) can also be the initiatorProbably can be administered through the AP/controller only (under study)
GeneralizedNumber of beamforming slots in the schedule given to initiator does not have to be a multiple of number of scanned beamsFor example, 100 slots may be allocated to scan 31 Tx beamsDifferent receive schedules (and Rx beams) for each victim link (this is more generalizing the procedure than generalizing the protocol)For example, one responder receiving during a portion of the 100 slots in the above example, while another responder receiving during the entire 100 slots
NotesSweep can be repeated (is ended administratively)Some or all of Rx beams can be the same, e.g., for averagingKnowing the TDD SSW multiplicity can help with averaging decisionsSet of Rx beams can be null to leave the Rx selection to responderTDD Sector Config exchange for another TA not in BSSOperation is runtime Tx calibration on aggressor (responders receiving on constant receive beams) + TA filtering
September 2019
VRX(initiator)
Coordinated beamforming – Rx training (Rx CBF)
Example implementationNetwork level interference nulling operation involving multiple aggressor links and a victim link: Finding the Rx beam with least interference from multiple aggressorsInitiator (on victim link) receiving on generally different Rx beams during beamforming slot every 400 µs(Note 1, 2)Multiple responders (on multiple aggressor links) transmitting on a given Tx beam during beamforming slots allocated to them (with invert scan polarity sometimes this may happen in the opposite subframe)Initiator reporting the result through the controllerAny device can be the initiator (DN or CN)No notion of BSS association for different responders (network-level operation)
Payam Torab, Facebook
9
Victim link
VTX
Aggressor link 1
ATX1
ARX1
Aggressor link 2
ATX2
VRX2
Initiatoror APMLME (and TDD Sector Config fields)Start timePeriod P or schedule (already provided)TDD SSW multiplicity(Note 3)Set of respondersSet of Rx beams(Note 4)TA addresses (Note 5)Non-AP (CN) can also be the initiatorProbably can be administered through the AP/controller only (under study)
GeneralizedNumber of beamforming slots in the schedule given to initiator does not have to be a multiple of number of scanned beamsFor example, 100 slots may be allocated to scan 31 Rx beamsDifferent transmit schedules (and Tx beams) for each aggressor link (this is more generalizing the procedure than generalizing the protocol)(Note 7)For example, one responder transmitting during a portion of the 100 slots in the above example, while another responder transmitting during the entire 100 slots
NotesSweep can be repeated (is ended administratively)Some or all of Rx beams can be the same, e.g., for averagingKnowing the TDD SSW multiplicity can help with averaging decisionsSet of Rx beams can be null to leave the Rx selection to responderTDD Sector Config exchangefor other TAsnot in BSSOperation is runtime Rx calibration on victim (responders transmitting on constant transmit beams) + TA filteringInterference measurement with simultaneous transmission is problematic – 802.11ad/ay directional channel measurement (ANIP and RSNI) with TDD extensions may be applicable
September 2019
Add more information aboutSweeping pattern/scheduleInformation from outside the BSSFor example, list of aggressor TA addresses during Rx CBF
Next stepEnhancing the TDD Sector Config subelement
Payam Torab, Facebook
10
September 2019
0
Embed
Upload