Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] 562r2 - enhanced single radio/link MLD



Dear all,

I have revised the document to 11-20/562r2 (https://mentor.ieee.org/802.11/dcn/20/11-20-0562-02-00be-enhanced-multi-link-single-radio-operation.pptx).  I added appendix at the end to include all the Q/As we had over emails and offline discussions during last two weeks. I also updated SPs based on the feedbacks. Please let me know if you have any other questions. 

Thanks,
Minyoung

On Thu, May 28, 2020 at 8:30 PM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:
Hi Rojan,

Thanks for your question. Please see my response below.

Regards,
Minyoung

On Thu, May 28, 2020 at 7:05 PM <rojan.chitrakar@xxxxxxxxxxxxxxxx> wrote:

Dear Minyoung,

 

Thanks for compiling this Q&A, it’s very helpful to further understand the proposal. I have a question on the below:

 

[Q6] Is there any radio or digital RX chain switch/tune time that needs to be considered to be practical? And if so, how much it would cost bandwidth/latency?

[A] The time budget after the reception of the RTS frame until reception of the data frame following the CTS is around 100 microseconds so we don’t see any issue in terms of switching/tune time. In case there is a long link switch time due to a certain vendors implementation, link switch time could be added as a limitation of an MLD and indicate to the AP MLD and adjust its operation.

 

You mentioned that the time budget is around 100uS after reception of RTS frame until reception of Data frame. But what about the CTS frame? The non-AP MLD needs to transmit the CTS on the new channel within SIFS of the RTS right? Or, are you assuming that being capable of listening on 2 links at a time, the non-AP MLD is also capable of transmitting basic frames (e.g. CTS) on both links at the same time? If not, the switch time available would be less than SIFS right?

[MP] The 100 usec time budget is for switching 1x1 rx on Link1 (channel1) to Link2 (channel2) so that 2x2 Rx can be used on Link2. For this, there is channel switching so needs some link switch delay and we believe this can be done in 100 usec. For a CTS transmission, since a CTS is transmitted on the link that RTS was received and there is no channel switching happening, we don't see any delay for the operation (maybe rx/tx turnaround time). Whether non-AP MLD needs to have CTS transmission capability on both links would be implementation dependent. As I noted above, adding link switch delay to indicate such limitation could be an option. 

 

Regards,

Rojan

 

From: Minyoung Park <mpark.ieee@xxxxxxxxx>
Sent: Friday, May 29, 2020 8:55 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 562r1 - enhanced single radio/link MLD Q/As

 

Dear all,

 

I've compiled Q/As (with edits) on the enhanced single radio/link MLD operation that I had with some of the members who were waiting in the queue during the presentation. I thought sharing the Q/As on the reflector will help other members to have better understanding on the proposal and answer some of your questions. Please read through the Q/As and let me know if you have any question that is not covered.

 

[Q1] The enhanced single-radio MLD does not seem to be a "single-radio" to me.

[A] We called it single-radio since the MLD cannot operated on two links simultaneously as today’s single link operation for 11ax. For example, the MLD cannot receive two data frames simultaneously and cannot transmit simultaneously. We agree that the naming might cause confusion so changing the name to single-link MLD could better describe such operation and we are open to other suggestions.

 

[Q2] Can STA receive and transmit at any link any time?

[A] No. We assume the enhanced single-radio/link MLD listening to two links simultaneously but cannot Tx/Rx on any link at any time (e.g. no Tx/Tx, no Rx/Rx of any frames, no STR). The listening includes CCA and receiving only specific frames (e.g. control frame).

 

[Q3] Based on slide 4, it seems to be dual-radio for control frames (e.g., RTS) (to be received on two links) and single-radio for data frames. However, the definition means receiving and transmitting (any) frames on a single link at a time. You mean the single-link MLD is only for data transmission?

[A] We define a single radio MLD as an MLD that can transmit/receive frames on one link at a time. In our proposal, we are adding an extra capability to the single radio MLD that can perform CCA and receive limited type of packets (e.g. RTS in non-HT PPDU and low MCS) on two links simultaneously. This doesn’t mean the AP MLD can transmit two RTS frames destined for the non-AP MLD on two links simultaneously. The AP MLD will transmit one RTS on one link that is idle since the AP MLD knows that the non-AP MLD is a single-radio MLD that can process a frame exchange sequence that will follow after the RTS. Processing the RTS frame that is transmitted with limitations such as non-HT PPDU type and low MCS just needs a fraction of the full receiver capability for processing any frame types transmitted in non-HT/HT/VHT/HE/EHT PPDU types, higher MCSs, and multiple spatial streams. Therefore we expect the enhanced single-radio MLD will have similar complexity as today’s 11ax STA implementation but still benefit from multi-link operation.

 

[Q4] Your proposal is assuming an enhanced "single" radio with enhanced capability. My understanding is that it's more like two full front-end radios but an additional simplified digital backend (PHY and MAC) as minimum requirement.

[A] We are assuming many single radio MLDs will be equipped with at least 2x2 MIMO capability and the idea is to reuse most of hardware that already exist in the single radio MLD for the proposed method but add extra capability to listen to two channels simultaneously.

 

[Q5] You were assuming this minimum requirement only support some basic rate (like legacy OFDM rate, up to 24Mbps), and simple MAC format like RTS/CTS. My concern on this aspect is: how about trigger frame? they can be fairly complicated in terms of frame structure, and also processing delay for parsing etc. How about a few MCS rates since trigger frame and in particular MU-RTS as replacement of RTS for protection purpose for MU, can be transmitted by VHT or HE (supposed EHT as well) rate?

[A] The first frame of a frame exchange sequence is limited to a control frame such as RTS/MU-RTS to address such complications or long processing delay. The first frame of a frame exchange sequence is also limited to use non-HT PPDU data rate up to 24 Mbps to manage the complexity. Other data rates/MCSs used in different PPDU types should be avoided to manage implementation complexity.

 

[Q6] Is there any radio or digital RX chain switch/tune time that needs to be considered to be practical? And if so, how much it would cost bandwidth/latency?

[A] The time budget after the reception of the RTS frame until reception of the data frame following the CTS is around 100 microseconds so we don’t see any issue in terms of switching/tune time. In case there is a long link switch time due to a certain vendors implementation, link switch time could be added as a limitation of an MLD and indicate to the AP MLD and adjust its operation.

 

[Q7] As this hopping of channel among multi-link is initiated by the AP en-powered by its assumed capability, AP is choosing channel according to its local CCA. But we know it's possible and non-trivial scenario where one channel/link is busy per the non-AP STA but not AP. The proposed mechanism would fail to handle this and the benefit diminishes (yet paid the cost of dual radio front-end.) Have you weighed in the cons or pros?

[A] A data frame is transmitted on a link where RTS/CTS exchange between an AP MLD and a non-AP MLD was successful, which is same as how today’s frame delivery is handled. If the RTS/CTS exchange is not successful due to channel busy on the non-AP STA side, the data frame is not transmitted. We are assuming at least 2x2 MIMO configuration for a single radio MLD and reusing the front-end hardware so there is no extra cost on the front-end side.

 

[Q8] If one channel is clean, what do we really gain from MLO/single radio (or even multiple radios)?

[A] If one channel is clean and the other is busy then MLO in general doesn’t help much since most of throughput will come from the clean channel.

 

[Q9] Does this limit to 20MHz only packets?

[A] No, it is not limited to 20MHz. The supported bandwidth will depend on the non-AP MLD’s capability as same as today’s single link operation. For example, to reserve medium for 40MHz channel, RTS should be transmitted in 40MHz.

 

[Q10] The minimum required RX capability is 20MHz?

[A] Yes, since the frame exchange sequence should start with an RTS in non-HT PPDU (simplest form).

 

[Q11] This single radio actually is a single PHY, right? Assuming this single radio has multi-link RF chains, i.e. tx/rx and antenna. How does this single radio perform CCA when receiving multiple signals from different RF chains as those signals are mixed up in the PHY?

[A] We define a single radio MLD as an MLD that can transmit/receive frame on one link at a time. In our proposal, we are adding an extra capability to the single radio MLD that can perform CCA and receive limited type of packets on two links simultaneously. Each RF chain will be connected to a separate PHY for independent signal processing (depends on implementation) but can just process limited type of packets.

 

[Q12] Can the enhanced single radio MLD device receive a 1x1 data frame on one link without RTS/CTS? (assuming no collision)

[A] No. This is because we assume the additional capability that the single radio MLD has is limited. In this mode of operation, we assume the single radio MLD can listen (CCA) and only process limited PPDU type/frame type on both links but cannot process data frame if received on the link that can just listen and process limited frames.

 

[Q13] Regarding the constraint of the enhanced single radio MLD that is not able to receive/transmit on both links. Are you assuming this constraint is dependent on the channel separation, BW and related parameters? Or, more of a RF path limitation of the “enhanced single radio” which will exist independent of BSS operation parameters?

[A] The single radio constraint is independent of the BSS operation parameters. This can be viewed as the single-radio MLD similar to today’s 11ax STA except it can utilize multiple links in a TDMA fashion. We are adding the extra capability on the single-radio MLD.

 

Thanks,

Minyoung     

 

 

On Sun, May 24, 2020 at 8:02 PM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:

Hi Ross,

 

The gaps could be as follows:

1. PPDU type: non-HT PPDU type versus non-HT/HT/VHT/HE/EHT PPDU types

2. frame type:  RTS frame versus all control/data/management frames

3. data rate:     6 Mbps of non-HT PPDU versus all MCSs of non-HT/HT/VHT/HE/EHT PPDUs

 

Thanks,

Minyoung

 

 

 

On Sun, May 24, 2020 at 7:15 PM Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx> wrote:

Hi Minyoung,

 

Thanks for the quick reply, especially during your weekend.

 

Per your minimizing the complexity, what is the gap between receiving all packets and receiving limited types of frames? What’s the additional complexity? It will decide if there is a need to define a limited capability.

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2020525 10:09
收件人: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 562r1

 

Hi Ross,

 

The way you described could be another way to look at it but our goal is to enhance the performance of  a single radio MLD which typically has at least 2x2 MIMO configuration that can transmit and receive a packet on one link at a time. Our approach was to add an extra capability to the single radio MLD so that the MLD can listen to both links simultaneously so that the AP MLD can pick any available link and start a frame exchange sequence.

 

Your question is exactly why we are calling it as enhanced single radio instead of multi-radio with limitations. We are adding an extra capability that just needs to listen to two links simultaneously and process a limited type of packets to enhance the performance of the single radio MLD instead of receiving any packets on two links like multi-radio MLD. Limiting the type of packets can minimize the complexity.

 

Thanks,

Minyoung

 

     

 

On Sun, May 24, 2020 at 5:51 PM Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx> wrote:

Hi all,

 

If the device can perform CCA and receive limited type of packets on two links simultaneously (in 1x1+1x1 mode), then it is not a single radio device to me. It is a multi-radio devices with limited capability.

 

One question here, why the device can only receive limited type of packets but not all types of packets, what’s the gap here?

 

regards

于健 Ross Yu

Huawei Technologies

 

发件人: Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2020523 0:06
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 562r1

 

Hi Ming, Laurent,

 

Thanks for the discussion. Just adding to what Laurent described below, I want to share the response I was giving to other people who had similar questions. We define a single radio MLD as an MLD that can transmit/receive frame on one link at a time. On top of that, we are adding an extra capability to the single radio MLD that can perform CCA and receive limited type of packets on two links simultaneously.  

 

Regards,

Minyoung 

 

On Fri, May 22, 2020 at 7:39 AM Cariou, Laurent <laurent.cariou@xxxxxxxxx> wrote:

Hi Ming,

Just to add that we classified such implementation in the single radio category to clarify that during data transmission phase only one radio is used (another classification could also be fine of course), but you have to make slight modifications/enhancements to a regular/current single radio implementation. 2 LOs instead of 1 for instance. But those changes come with very small complexity, compared to moving to complete dual radio.

Thanks,

Laurent

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Friday, May 22, 2020 7:08 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 562r1

 

Hello Minyoung,

 

Really thanks for your response. I am not sure two LOs inside one single radio STA is a typical case, I will check it with our implementation guys internally. Does this faster switch time (tens of microseconds) come from two LOs?  

 

Best wishes

Ming Gan

 

 

发件人: Park, Minyoung [mailto:minyoung.park@xxxxxxxxx]
发送时间: 2020521 1:47
收件人: Ganming (Ming) <
ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] 562r1

 

Hello Ming,

 

Thanks for your questions. Please see inline below.

 

Regards,

Minyoung

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, May 20, 2020 9:43 AM
To: Park, Minyoung <minyoung.park@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 562r1

 

Hello Minyoung

 

Thank you for presenting contribution 562r1. Because of very limited Q&A time now (most of Q in the queue can not be answered), I just have a few questions.

 

Regarding the right figure in slide 4, I understand single radio STA can not receive the frames on more than one link. But you mentioned this single radio STA can switch the link in a few microseconds.

[MP] In the call, I mentioned tens of microseconds, not a few microseconds. Considering the RTS/CTS exchange before data frame reception, the time budget before data frame reception is around 100 usec so we didn’t see any issue for the channel switch.

 

Then how many LOs inside it?

[MP] Since we assume monitoring two channels, I assume two LOs but this will be more implementation dependent.

 

Generally speaking, there is just one. I do not how do you make its frequency stable in a few microseconds.

[MP] Please see the answer to the first question.

 

If it can work, why do you just limit it to one antenna per link while monitoring the channel?

[MP] A client device equipped with 2x2 MIMO configuration can only use one antenna for each channel so transmitting the first packet of a frame exchange sequence in 1SS can cover 2x2 or higher MIMO configurations.

 

If there is only one antenna for single radio, does it still work

[MP] Probably not. We were assuming at least 2x2 MIMO configuration or additional 1x1 radio as described in slide4.

 

For dynamic SM power save, what is the motivation for additional constraints  for the first frame of a frame exchange sequence?

[MP] The additional constraints is for low complexity receiving block implementation on each channel (since this is additional capability that needs to be added to the single radio MLD) to look for the first frame of a frame exchange sequence. Also better power efficiency.

 

If they are needed for EHT, does HE need them?

[MP] This is for EHT. Not for HE.

 

Is dynamic SM power save link specific or other?

[MP] We were assuming link specific in the proposal.

 

What do you mean by the following sentence, can single radio STA be awake on more than one link

“To enable the MLSR operation, the non-AP MLD indicates two or more enabled links are in the awake state”

[MP] The procedure in slide 10 was an attempt to enable the proposed MLSR with minimal changes to the spec development. Since the non-AP MLD indicated to the AP MLD that it is a single-radio MLD, the AP MLD knows that the non-AP MLD can only receive frame on one link at a time. Now if the non-AP MLD indicates that it is available on two links then the AP MLD can pick either link that is available for transmission and transmit a packet that starts a frame exchange sequence.

 

Best wishes,

Ming Gan

 


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1