Re: [STDS-802-11-TGBE] [EXTERNAL] Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
Not sure why are any changes necessary to the original version... we went
long way to get to that. Original or I could be open to:
“enhanced multi-link single radio (EMLSR) operation: A mode of operation
that allows a non-access point (non-AP) multi-link device (MLD) with
multiple receive chains to listen on a set of enabled links, and to perform
frame exchanges on only one link of the set (after receiving a specific
control frame) at any time”
Best,
Vinko..
-----Original Message-----
From: Eduard Garcia Villegas <eduardg@xxxxxxxxxxxxx>
Sent: Wednesday, September 14, 2022 2:23 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXTERNAL] Re: [STDS-802-11-TGBE] EMLSR and
EMLMR definitions
I also like Matt's version, but there's one thing I suggest removing: the
"(after receiving a specific control frame)" parenthesis. Note that this
"specific control frame" is not needed prior to uplink transmissions (*).
(*) Note 3 (in 35.3.17): "A STA affiliated with a non-AP MLD operating in
the EMLSR mode does not need to transmit an initial Control frame to
initiate frame exchanges with the AP MLD and follow the rules..."
Eduard
On Wed, September 14, 2022 9:57 pm, Wullert, John R II (PERATON LABS) wrote:
> I like Matt's proposed addition, because it serves to differentiate
> the two definitions and to illustrate why "single radio" and "multiple
> radio"
> are included in the terms.
>
> John
> ________________________________
> From: Matthew Fischer <matthew.fischer@xxxxxxxxx>
> Sent: Wednesday, September 14, 2022 3:35 PM
> To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
> <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
> Subject: Re: [STDS-802-11-TGBE] [EXTERNAL] Re: [STDS-802-11-TGBE]
> EMLSR and EMLMR definitions
>
>
>
> enhanced multi-link single radio (EMLSR) operation: A mode of
> operation that allows a non-access point (non-AP) multi-link device
> (MLD) with multiple receive chains to listen on a set of enabled
> links, and to perform a set of frame exchanges on one link of the set
> (after receiving a specific control frame) while having no ability to
> receive or transmit on the other links of the set.
>
>
> enhanced multi-link multiple radio (EMLMR) operation: A mode of
> operation that allows a non-access point (non-AP) multi-link device
> (MLD) with multiple receive chains to listen on a set of enabled
> links, and to perform a set of frame exchanges on one link of the set
> (after receiving a specific control frame) while having limited
> ability to receive or transmit on the other links of the set.
>
>
>
>
> On Wed, Sep 14, 2022 at 12:23 PM LALAM Massinissa
> <00001c2d776ab802-dmarc-request@xxxxxxxxxxxxxxxxx<mailto:00001c2d776ab
> 802-dmarc-request@xxxxxxxxxxxxxxxxx>>
> wrote:
>
> Stephen,
>
> I’m even more confused now because only EMLMR could increase the
> number of spatial streams, not ELMSR in my understanding of the spec.
>
>
>
> After thinking, removing the control frame notion makes the “immediately”
> a bit strange because we don’t have any time notion anymore, so
> immediate after what?
>
>
>
> I would be more comfortable with something like that, where the
> subclause on the EMLSR will detail anyway which kind of control frame is
> considered.
> I put parenthesis because we could remove it as well if the group
> absolutely doesn’t want to have a reference to a control frame (both
> are fine with me)
>
>
>
> enhanced multi-link single radio (EMLSR) operation: A mode of
> operation that allows a non-access point (non-AP) multi-link device
> (MLD) with multiple receive chains to listen on a set of enabled
> links, and to perform the immediately set of frame exchanges on one
> link of the set (after receiving a specific control frame).
>
>
>
> Regards,
>
> Massinissa
>
>
>
> De : Stephen McCann
> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>>
> Envoyé : mardi 13 septembre 2022 21:57 À :
> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@xxxxxxxxxxx
> EE.ORG> Objet : Re: [STDS-802-11-TGBE] [EXTERNAL] Re:
> [STDS-802-11-TGBE] EMLSR and EMLMR definitions
>
>
>
> [EXTERNAL]-Real sender is:
> owner-stds-802-11-tgbe@xxxxxxxxxxxxxxxxx<mailto:owner-stds-802-11-tgbe
> @listserv.ieee.org>
>
> ________________________________
>
> Eduard,
>
> I've considered your comments and adapted the definition
> as
> follows:
>
>
>
> enhanced multi-link single radio (EMLSR) operation: A mode of
> operation that allows a non-access point (non-AP) multi-link device
> (MLD) with multiple receive chains to listen on a set of enabled
> links, to increase the number of spatial streams on one link within
> the set, for the immediately following set of frame exchanges.
>
> I hope this is ok with everyone.
>
>
>
> Kind regards
>
>
>
> Stephen
>
>
>
> On Tue, 13 Sept 2022 at 03:40, Eduard Garcia Villegas
> <eduardg@xxxxxxxxxxxxx<mailto:eduardg@xxxxxxxxxxxxx>> wrote:
>
> Dear all,
>
>> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>> operation that allows a non-access point (non-AP) multi-link device
>> (MLD) with multiple receive chains to listen on a set of enabled
>> links, then move to one link within the set, for the immediately
>> following set of frame exchanges.
>
> @Stephen, thanks for the edits, the last version of EMLSR addresses my
> initial concerns (not only "moves" rx, but also tx). However, the
> "...then move to one link within the set..." still feels too vague.
> What is being moved?
>
> Also considering Xiaofei's comment on moving spatial streams vs.
> moving rf chains, what about something like:
>
> "...**, and to re-configure one or more receiver and transmiter chains
> to transmit and receive** on one link within the set, for the
> immediately following set of frame exchanges."
>
> or just:
>
> "... **to increase the number of spatial streams** on one link within
> the set..."?
>
>
>
> Best regards,
>
>
> Eduard
>
>
>
>> Regarding your second point, I politely disagree. I think it's
>> essential to define these terms, as it's certainly not clear from
>> clause 35 what these EML modes of operation are. I appreciate that
>> this is difficult work, but I think it's worth persevering with.
>>
>> Kind regards
>>
>> Stephen
>>
>> On Mon, 12 Sept 2022 at 16:56, Minyoung Park
>> <mpark.ieee@xxxxxxxxx<mailto:mpark.ieee@xxxxxxxxx>> wrote:
>>
>>> Hi Stephen,
>>>
>>> The 'move to receive on one link within the set' is not correct. As
>>> I mentioned, a non-AP MLD in EMLSR mode doesn't move to receive
>>> before the immediately following frame exchanges.
>>>
>>> If we cannot have a correct definition in Clause 3, it is better not
>>> to have it in Clause 3. It is better to rely on the EMLSR subclause
>>> in Clause 35.3.17.
>>>
>>> Regards,
>>> Minyoung
>>>
>>> On Mon, Sep 12, 2022 at 7:45 PM Stephen McCann
>>> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>>
>>> wrote:
>>>
>>>> Massinissa, John,
>>>> Thanks for your comments.Perhaps this
>>>> would be suitable:
>>>>
>>>> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>> operation that allows a non-access point (non-AP) multi-link device
>>>> (MLD)
>>>> with multiple receive chains to listen on a set of enabled links,
>>>> then move to receive on one link within the set, for the
>>>> immediately following set of frame exchanges.
>>>>
>>>> I am trying to avoid re-introducing the term "Control frame", as I
>>>> really don't think this is appropriate for a definition.
>>>>
>>>> Kind regards
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On Mon, 12 Sept 2022 at 16:32, Wullert, John R II (PERATON LABS) <
>>>> jwullert@xxxxxxxxxxxxxxx<mailto:jwullert@xxxxxxxxxxxxxxx>> wrote:
>>>>
>>>>> Stephen,
>>>>> One concern I have with your proposed definition is that while
>>>>> the term contains the words "single radio" the definition says
>>>>> "one or more"
>>>>> which can lead to confusion. Perhaps we need to focus the
>>>>> definition not on how many radios the device *has *but on how many
>>>>> it *uses *in the context of the EMLSR operation. While the former
>>>>> may be one or more, I believe the latter must be one.
>>>>> John
>>>>> ------------------------------
>>>>> *From:* Stephen McCann
>>>>> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>>
>>>>> *Sent:* Monday, September 12, 2022 10:26 PM
>>>>> *To:*
>>>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@LISTSER
>>>>> V.IEEE.ORG>
>>>>> <
>>>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@LISTSER
>>>>> V.IEEE.ORG>>
>>>>> *Subject:* [EXTERNAL] Re: [STDS-802-11-TGBE] EMLSR and EMLMR
>>>>> definitions
>>>>>
>>>>> Rubayet,
>>>>> I don't think the EMLSR definition is ambiguous. The
>>>>> current definition that I propose supports the second of your
>>>>> options.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Stephen
>>>>>
>>>>> On Mon, 12 Sept 2022 at 16:20, Rubayet Shafin
>>>>> <r.shafin@xxxxxxxxxxx<mailto:r.shafin@xxxxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>>
>>>>>
>>>>> Just for my understanding--why is it better to stay silent and
>>>>> keep things ambiguous?? We have had enough discussion in the group
>>>>> that is rooted from this ambiguity. I think it is time to clear that
>>>>> out.
>>>>>
>>>>>
>>>>>
>>>>> - If EMLSR is only for single radio devices, I think it has to be
>>>>> stated in the spec clearly
>>>>> - If EMLSR is for both single and multiple radios devices, I think
>>>>> it also has to be stated in the spec clearly.
>>>>>
>>>>>
>>>>>
>>>>> Best
>>>>>
>>>>> Rubayet
>>>>>
>>>>>
>>>>>
>>>>> *From:* Stephen McCann
>>>>> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>>
>>>>> *Sent:* Monday, September 12, 2022 10:14 PM
>>>>> *To:* Rubayet Shafin
>>>>> <r.shafin@xxxxxxxxxxx<mailto:r.shafin@xxxxxxxxxxx>>
>>>>> *Cc:*
>>>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@listser
>>>>> v.ieee.org>
>>>>> *Subject:* Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
>>>>>
>>>>>
>>>>>
>>>>> Dear all,
>>>>>
>>>>> the current definition of EMLSR that I mentioned
>>>>> earlier, is silent about how many radios are present in the MLD. I
>>>>> think it's best left that way.
>>>>>
>>>>>
>>>>>
>>>>> Kind regards
>>>>>
>>>>>
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 12 Sept 2022 at 16:11, Rubayet Shafin
>>>>> <r.shafin@xxxxxxxxxxx<mailto:r.shafin@xxxxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>> Hi Minyoung,
>>>>>
>>>>>
>>>>>
>>>>> Do you intend to mean that a device that supports EMLSR can only
>>>>> have one radio? If you don’t intend to mean that, I think it
>>>>> would be better to clarify this rather than keeping the definition
>>>>> ambiguous on that aspect.
>>>>>
>>>>>
>>>>>
>>>>> Best
>>>>>
>>>>> Rubayet
>>>>>
>>>>>
>>>>>
>>>>> *From:* Minyoung Park
>>>>> <mpark.ieee@xxxxxxxxx<mailto:mpark.ieee@xxxxxxxxx>>
>>>>> *Sent:* Monday, September 12, 2022 9:21 PM
>>>>> *To:*
>>>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@LISTSER
>>>>> V.IEEE.ORG>
>>>>> *Subject:* Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
>>>>>
>>>>>
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>>
>>>>>
>>>>> The EMLSR definitions is still not accurate.
>>>>>
>>>>>
>>>>>
>>>>> A non-AP MLD doesn't move to receive on one available link but the
>>>>> listening operation includes the receiving function of the initial
>>>>> control frame on the set of enabled links. A non-AP MLD moves to
>>>>> one available link on which the initial control frame was received
>>>>> and exchange frames.
>>>>>
>>>>>
>>>>>
>>>>> Also deleting 'one or more radio(s)' would be better to avoid
>>>>> controversial discussions. (this wasn't in the original definition
>>>>> as
>>>>> well)
>>>>>
>>>>>
>>>>>
>>>>> The following is my suggestion:
>>>>>
>>>>> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> operation that allows a non-access point (non-AP) multi-link
>>>>> device
>>>>> (MLD)
>>>>> with multiple receive chains and with one or more radio(s), to
>>>>> listen on a set of enabled links, then move to receive on one
>>>>> available link within the set *on which the initial Control frame
>>>>> was received*, for the immediately following set of frame exchanges.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Minyoung
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 12, 2022 at 5:57 PM Stephen McCann
>>>>> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>> Eduard,
>>>>>
>>>>> I agree with the other comments that resources are not
>>>>> moved in an EMLSR mode, so I prefer my earlier definitions. This
>>>>> is what I propose to move forward with:
>>>>>
>>>>>
>>>>>
>>>>> *enhanced multi-link multiple radio (EMLMR) operation*: A mode of
>>>>> operation that allows any of the stations (STAs) affiliated with a
>>>>> non-access point (AP) multi-link device (MLD) on a set of enabled
>>>>> links, to move receive and transmit spatial streams to one link
>>>>> within the set, to increase resources on that link, for the
>>>>> immediately following set of frame exchanges. (#10935, #11820,
>>>>> #12035, #12706)
>>>>>
>>>>>
>>>>>
>>>>> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> operation that allows a non-access point (non-AP) multi-link device
>>>>> (MLD)
>>>>> with multiple receive chains and with one or more radio(s), to listen
>>>>> on a
>>>>> set of enabled links, then move to receive on one available link
>>>>> within the
>>>>> set, for the immediately following set of frame exchanges.
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> Kind regards
>>>>>
>>>>>
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 12 Sept 2022 at 14:46, Rubayet Shafin
>>>>> <r.shafin@xxxxxxxxxxx<mailto:r.shafin@xxxxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>>
>>>>>
>>>>> I also disagree with Eduard in the sense that the EMLSR is “applied
>>>>> to a
>>>>> single-radio non-AP MLD†. EMLSR is a mode of operation, not a
>>>>> device-level
>>>>> capability. EMLSR can be applied to both single radio and multi-radio
>>>>> devices. In other word, a device with multiple radios may elect to
>>>>> operate
>>>>> on EMLSR mode on a subset of enabled links (EMLSR Links), while other
>>>>> radios can operate on non-EMLSR links.
>>>>>
>>>>>
>>>>>
>>>>> I prefer your previous definition in this aspect.
>>>>>
>>>>>
>>>>>
>>>>> Best
>>>>>
>>>>> Rubayet
>>>>>
>>>>> *From:* Minyoung Park
>>>>> <mpark.ieee@xxxxxxxxx<mailto:mpark.ieee@xxxxxxxxx>>
>>>>> *Sent:* Monday, September 12, 2022 2:37 PM
>>>>> *To:*
>>>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
>>>>> *Subject:* Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
>>>>>
>>>>>
>>>>>
>>>>> *Caution:* This email originated from outside of the organization. Do
>>>>> not click links or open attachments unless you recognize the sender
>>>>> and
>>>>> know the content is safe.
>>>>>
>>>>>
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>>
>>>>>
>>>>> I disagree with the statement from Eduard. The EMLSR doesn't move
>>>>> around
>>>>> resources between different links. Each STA's capability is announced
>>>>> during the association process and that capability is used in the
>>>>> EMLSR
>>>>> mode.
>>>>>
>>>>>
>>>>>
>>>>> As I commented in the call last week, it would be better to focus on
>>>>> the
>>>>> EMLMR definition, which is what the commenter is asking for.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Minyoung
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 12, 2022 at 5:25 PM Stephen McCann
>>>>> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>>
>>>>> wrote:
>>>>>
>>>>> Eduard,
>>>>>
>>>>> yes, I think that is reasonable.
>>>>>
>>>>>
>>>>>
>>>>> Kind regards
>>>>>
>>>>>
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 11 Sept 2022 at 23:43, Eduard Garcia Villegas <
>>>>> eduardg@xxxxxxxxxxxxx<mailto:eduardg@xxxxxxxxxxxxx>> wrote:
>>>>>
>>>>> Dear Stephen,
>>>>>
>>>>> As far as I understood, EMLSR is the same as EMLMR, but applied to a
>>>>> single-radio non-AP MLD. Therefore, I'd use the same phrasing in both
>>>>> definitions, based on the EMLMR definition you proposed (which I find
>>>>> more
>>>>> accurate). Something like:
>>>>>
>>>>> "*enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> operation
>>>>> that allows a single-radio non-access point (non-AP) multi-link
>>>>> device
>>>>> (MLD) with multiple receive chains, to listen on a set of enabled
>>>>> links,
>>>>> then move receive and transmit spatial streams to one link within the
>>>>> set,
>>>>> to increase resources on that link, for the immediately following set
>>>>> of
>>>>> frame exchanges.
>>>>> "
>>>>>
>>>>> Note that, in the uplink, the non-AP MLD can choose to use its tx
>>>>> chain(s)
>>>>> on a different link each time (i.e. not only moves rx chains).
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>> Eduard
>>>>>
>>>>> On Mon, September 12, 2022 12:03 am, Stephen McCann wrote:
>>>>> > Dear all,
>>>>> > thanks for all the further comments on this topic.
>>>>> These
>>>>> are
>>>>> > the some updated definitions that I have produced based on the
>>>>> comments:
>>>>> >
>>>>> > *enhanced multi-link multiple radio (EMLMR) operation*: A mode of
>>>>> > operation
>>>>> > that allows any of the stations (STAs) affiliated with a non-access
>>>>> point
>>>>> > (AP) multi-link device (MLD) on a set of enabled links, to move
>>>>> receive
>>>>> > and
>>>>> > transmit spatial streams to one link within the set, to increase
>>>>> resources
>>>>> > on that link, for the immediately following set of frame exchanges.
>>>>> > (#10935, #11820, #12035, #12706)
>>>>> >
>>>>> >
>>>>> >
>>>>> > *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> operation
>>>>> > that allows a non-access point (non-AP) multi-link device (MLD)
>>>>> with
>>>>> > multiple receive chains and with one or more radio(s), to listen on
>>>>> a
>>>>> set
>>>>> > of enabled links, then move to receive on one available link within
>>>>> the
>>>>> > set, for the immediately following set of frame exchanges.
>>>>> >
>>>>> > Kind regards
>>>>> >
>>>>> > Stephen
>>>>> >
>>>>> > On Sat, 10 Sept 2022 at 11:39, Mark Rison
>>>>> <m.rison@xxxxxxxxxxx<mailto:m.rison@xxxxxxxxxxx>>
>>>>> wrote:
>>>>> >
>>>>> >> > And for "all of the following frame exchanges" seems eternal in
>>>>> scope.
>>>>> >> If this definition is intended to be read by someone lacking
>>>>> extensive
>>>>> >> 802.11 knowledge then it could say, for "the immediately following
>>>>> set
>>>>> >> of
>>>>> >> frame exchanges"
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Or just leave the ending of the condition unstated:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> >> operation
>>>>> >> that allows a non-access point (non-AP) multi-link device (MLD)
>>>>> with
>>>>> >> multiple receive chains to listen on a set of enabled links, then
>>>>> switch
>>>>> >> to
>>>>> >> one available link within the set.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> > I think that at least for emlsr, instead of switch it might say
>>>>> >> something like "receive"
>>>>> >>
>>>>> >> > It turns out that listening on the link on which receive is not
>>>>> >> occurring is still possible during the receive
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> You mean
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> >> operation
>>>>> >> that allows a non-access point (non-AP) multi-link device (MLD)
>>>>> with
>>>>> >> multiple receive chains to listen on a set of enabled links, then
>>>>> >> receive
>>>>> >> to [on?] one available link within the set.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> ? That's not worse, but still doesn't explain the key point,
>>>>> which
>>>>> is
>>>>> >> that the receive chains are reallocated to be used on the same
>>>>> channel.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> My suggestion would be:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> >> operation
>>>>> >> that allows a non-access point (non-AP) multi-link device (MLD) to
>>>>> >> listen
>>>>> >> on a set of enabled links using one radio frequency (RF) chain on
>>>>> each,
>>>>> >> and
>>>>> >> then switch all the RF chains to one of the links for subsequent
>>>>> >> single-user multiple input, multiple output (SU-MIMO) operation on
>>>>> that
>>>>> >> link.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Also, maybe it's because I wasn't there, but I find this
>>>>> definition
>>>>> >> rather
>>>>> >> confusing:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *enhanced multi-link multiple radio (EMLMR) operation*: A mode of
>>>>> >> operation that allows any of the stations (STAs) affiliated with a
>>>>> >> non-access point (non-AP) multi-link device (MLD) on a set of
>>>>> enabled
>>>>> >> links, to switch receive and transmit spatial streams of one
>>>>> available
>>>>> >> link
>>>>> >> within the set, to increase resources on that link, for all of the
>>>>> >> following frame exchanges.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> I initially read "switch tx and rx" as being that tx becomes rx
>>>>> and
>>>>> rx
>>>>> >> becomes tx.
>>>>> >>
>>>>> >> Even if it means "transfer both of them to another link" (i.e. you
>>>>> need
>>>>> >> to
>>>>> >> have
>>>>> >>
>>>>> >> a "to X" after the "switch"), isn't this a definition of EMLSR?
>>>>> What
>>>>> >> does EMLMR
>>>>> >>
>>>>> >> do that EMLSR doesn't do?
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Thanks,
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Mark
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >>
>>>>> >> Mark RISON, Standards Architect, WLAN
>>>>> English/Esperanto/Français
>>>>> >>
>>>>> >> Samsung Cambridge Solution Centre Tel: +44 1223 434600
>>>>> >>
>>>>> >> Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
>>>>> >>
>>>>> >> ROYAUME UNI WWW:
>>>>> http://www.samsung.com/uk<https://urldefense.com/v3/__http:/www.samsung.com/uk__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYn5FLtc5Y$>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *From:* Matthew Fischer
>>>>> <matthew.fischer@xxxxxxxxx<mailto:matthew.fischer@xxxxxxxxx>>
>>>>> >> *Sent:* Friday, 9 September 2022 14:44
>>>>> >> *To:*
>>>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
>>>>> >> *Subject:* Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> I think that at least for emlsr, instead of switch it might say
>>>>> >> something
>>>>> >> like "receive"
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> It turns out that listening on the link on which receive is not
>>>>> >> occurring
>>>>> >> is still possible during the receive
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> And for "all of the following frame exchanges" seems eternal in
>>>>> scope.
>>>>> >> If
>>>>> >> this definition is intended to be read by someone lacking
>>>>> extensive
>>>>> >> 802.11
>>>>> >> knowledge then it could say, for "the immediately following set of
>>>>> frame
>>>>> >> exchanges"
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Fri, Sep 9, 2022, 2:19 PM Stephen McCann
>>>>> <mccann.stephen@xxxxxxxxx<mailto:mccann.stephen@xxxxxxxxx>
>>>>> >
>>>>> >> wrote:
>>>>> >>
>>>>> >> Dear all,
>>>>> >>
>>>>> >> thanks for your comments following my presentation of
>>>>> >> 11-22-1196r3.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Here are the revised definitions that I presented:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *enhanced multi-link multiple radio (EMLMR) operation*: A mode of
>>>>> >> operation that allows any of the stations (STAs) affiliated with a
>>>>> >> non-access point (non-AP) multi-link device (MLD) on a set of
>>>>> enabled
>>>>> >> links, to switch receive and transmit spatial streams of one
>>>>> available
>>>>> >> link
>>>>> >> within the set, to increase resources on that link, for all of the
>>>>> >> following frame exchanges.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> *enhanced multi-link single radio (EMLSR) operation:* A mode of
>>>>> >> operation
>>>>> >> that allows a non-access point (non-AP) multi-link device (MLD)
>>>>> with
>>>>> >> multiple receive chains to listen on a set of enabled links, then
>>>>> switch
>>>>> >> to
>>>>> >> one available link within the set, for all of the following frame
>>>>> >> exchanges.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Please let me know if you have any further suggestions. If we can
>>>>> >> converge
>>>>> >> on suitable text, then I can represent an updated submission next
>>>>> week.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Kind regards
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Stephen
>>>>> >> ------------------------------
>>>>> >>
>>>>> >> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>> >>
>>>>> >> ------------------------------
>>>>> >>
>>>>> >> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>> >> ------------------------------
>>>>> >>
>>>>> >> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>> >>
>>>>> >
>>>>> >
>>>>> ________________________________________________________________________
>>>>> > 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>> >
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>> ------------------------------
>>>>>
>>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>>
>>>> ------------------------------
>>>>
>>>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>>>
>>>
>>
>> ________________________________________________________________________
>> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>>
>
> ________________________________________________________________________
> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>
> ________________________________
>
> 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<https://urldefense.com/v3/__https:/listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1__;!!MNCx95vGHQ!T2rcy7x5NjLKeSTivjthW2Vdup0Np6vybskJN1xfSlgo2VeT3a9wX-XBxQq38qKld_3Y788VnSN5_flD7QSR5bYnLncyJ7E$>
>
> ________________________________
> Ce courriel et les documents qui lui sont joints sont, sauf mention
> contraire, présumés de nature confidentielle et destinées à l'usage
> exclusif du ou des destinataire(s) mentionné(s). Si vous n'êtes pas le ou
> les destinataire(s), vous êtes informé(e) que toute divulgation,
> reproduction, distribution, toute autre diffusion ou utilisation de cette
> communication ou de tout ou partie de ces informations est strictement
> interdite, sauf accord préalable de l’expéditeur. Si ce message vous a été
> transmis par erreur, merci d’immédiatement en informer l'expéditeur et
> supprimer de votre système informatique ce courriel ainsi que tous les
> documents qui y sont attachés. En vous remerciant de votre coopération.
>
> This email and any attached documents are, unless otherwise stated,
> presumed to be confidential and intended for the exclusive use of the
> recipient(s) mentioned. If you are not the recipient(s), you are informed
> that any disclosure, reproduction, distribution, any other dissemination
> or use of this communication or all or part of this information is
> strictly prohibited, unless agreed beforehand by the sender. If you have
> received this e-mail in error, please immediately advise the sender and
> delete this e-mail and all the attached documents from your computer
> system. Thanking you for your cooperation.
> ________________________________
>
> 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
>
>
> --
> Matthew Fischer
> ________________________________
>
> 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
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
________________________________________________________________________
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