| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Joe, See below Laurent From: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx> Hi Laurent, Please see below. Joseph From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Hi Joe, See below Thanks Laurent From: Joseph Levy <Joseph.Levy@xxxxxxxxxxxxxxxx>
Hi Laurent, I have a few questions:
[LC] you need an initial power state to start with. Baseline defines it exactly this way:
We can signal it in the frame exchanges (setup, …), but it feels like a lot of burden and over-design for something that happens very infrequently. [JL] – I don’t see any burden or over-design related to using the existing PS bit to set the PS state using legacy procedures. What burden and over-design are you concerned about? [LC] burden is not that big, but how useful is that.
[LC] sorry I’m not sure I understand well the question here. The main mode of TID mapping we see is the default mode where all links are enabled (TIDs mapped to all links). In that situation, based on what we
agreed, the STA just has to wake up in a particular link to operate on that link. There is no need for specific signaling. That’s why the initial mode we talk about here will happen only once in this case (during multi-link setup) [JL} If all the links are enabled, doesn’t it mean that they are all active? I thought you were proposing that all links except for the link used to set-up MLD on would be in PS mode (doze), and the STA would need to either signal to
the AP that it was in active mode for the link or the AP would need to wait for a time period when the STA is scheduled to be in the active state, before the AP could use the link to send the STA PPDUs. While it is true that all the STA needs to do is send
a PPDU with the PS bit set to active state for the link to be active, this still requires a PPDU transmission by the STA before the AP can use the link for transmissions. Why not simply allow the link to default to the active state? As I stated above if
the AP and STA just went through an MLD setup exchange, wouldn’t the AP and STA both want to use the MLD links established? [LC] I think there is misunderstanding about enablement, and power states. We have defined the enablement/disablement as a management level change, unfrequent, which is just the result of the TID-link-mapping
function. Basically, if at least one TID is mapped to one link, then that link Is enabled, otherwise it is disabled. When a link is enabled, it simply means that it can be used, but power management still needs to be respected. So once a link is enabled, a STA can be in active mode, or power save mode in doze or awake state. So in the default mode, all links are enabled. But STA plays with its power states to use one link or the other or both… We just need a state to start with. We propose to fix it in the standard, similar to baseline.
For a single radio device, you can not start with active mode for multiple links as such devices can’t do that, so this option is not viable. A multi radio device could do it, but even there, these devices will
sometimes operate with 2 links in active mode, sometimes with all links in doze, sometimes with some links in doze some active... we are just talking about the start right after the setup. The debate is simply: either we have implicit initial power state with
only one link active as I suggest, or we have explicit signaling to indicate the states or both.
[LC] that question goes way beyond the debate on that presentation. Even for single radio devices, it is very advantageous to be able to setup multiple links, and move from one link to the other as smoothly as
possible and exploit load variations on all the links to improve throughput/latency. [JL] You seem to be using MLD to provide a means of providing fast (smooth) transition between links, how does this relate to the current fast transition capabilities in 802.11 – what are the advantages of using MLD to make these transitions
instead of using the legacy capability? [LC] again that’s really a question about multi-link operation, and not really for this debate here. There are many advantages of the multilink framework we define. Aggregation for throughput increase for devices
that can afford have multiple radios is one. But for devices that can not afford that and will have single radio (and a very large portion of devices will be like this), there are also many advantages compared to baseline, that are linked to the fact that
we make transition between links much smoother and fast, which allows to exploit dynamic load changes on links and get throughput/latency/QoS.
more efficient to only use multi-link connections when they are required/desired?
[LC] again your question here is not for the SP/presentation but for multilink in general. But even if you setup multiple links, you can decide to operate on one of them all the time, and only use other links
when required/desired.. [JL] True this question is beyond the SP/presentation and is addressing multilink in general – but in my opinion it is critical to have an answer to this question before I can decide if the proposed default state is appropriate. I don’t
want to make limiting decision now before I know how we will be using multi-link. Any thoughts on this general question would be very helpful to me in understanding the impact of my vote on this straw poll.
[LC] because of the overhead of updating a multi-link connection change, we feel that these changes will be done very unfrequently, basically only during setup/association. In that case, STA does setup to establish
multiple links at the beginning, and it has nothing to do after that, even if it does not use multiple links. We have designed it so that the STA can simply transition or use one or 2 links simply by changing the power states. Once setup, maintaining multiple links is not really burdensome. Regards, Joseph From: Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Hi all, Q/A were stopped at the end of last 11be MAC call, for the contribution on power save state after enablement. I can answer your questions here if there are still remaining ones. Thanks, Laurent 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 |