Re: [STDS-802-11-TGBE] [EXTERNAL] Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
Hi Stephen,
I understand your decision, but I think the latest definition you provided
has a good chance of reaching a consensus, once the "after receiving a
specific control frame" is removed (that control frame is not needed in
the uplink, as per Note 3 in 35.3.17 of the spec):
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 at any time.
Cheers,
Eduard
On Thu, September 15, 2022 5:24 pm, Stephen McCann wrote:
> Dear all,
> thanks again for all your comments on this topic and I
> appreciate your help. I have decided not to update the EMLSR operation
> definition, as there is no consensus as to what it means. Therefore I
> shall
> present my updated submission with a new EMLMR operation definition today,
> which is based on the one that Matt Fischer essentially proposed a couple
> of days ago: <
> https://mentor.ieee.org/802.11/dcn/22/11-22-1196-04-00be-lb266-clause-3-2-comment-resolutions.doc
>>.
>
> Regarding EMLSR operation, I invite people to submit comments during the
> next letter ballot to see if it can be refined further. Thanks.
>
> Kind regards
>
> Stephen
>
> On Wed, 14 Sept 2022 at 17:49, Xiaofei Wang
> <Xiaofei.Wang@xxxxxxxxxxxxxxxx>
> wrote:
>
>> Hi Stephen,
>>
>>
>>
>> EMLSR definition seems good to me.
>>
>>
>>
>> EMLMR definition, to me, the â??limited capabilityâ?? part is not very
>> clear,
>> maybe we can clarify a bit which capabilities are limited? For example,
>> can
>> it be interpreted as â??can only receive, but not transmitâ??? Just too
>> many
>> possibilities.
>>
>>
>>
>> Similar thoughts for Mattâ??s version for EMLMR.
>>
>>
>>
>> Best regards,
>>
>> Xiaofei Clement Wang
>>
>> Principal Engineer | InterDigital
>>
>> T: (631) 622.4028
>>
>> E: Xiaofei.wang@xxxxxxxxxxxxxxxx
>>
>>
>>
>> *From:* Stephen McCann <mccann.stephen@xxxxxxxxx>
>> *Sent:* Wednesday, September 14, 2022 11:07 PM
>> *To:* STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
>> *Subject:* Re: [STDS-802-11-TGBE] [EXTERNAL] Re: [STDS-802-11-TGBE]
>> EMLSR
>> and EMLMR definitions
>>
>>
>>
>>
>>
>> Dear all,
>>
>> thanks for all the recent comments. Here are my latest
>> suggestions:
>>
>>
>>
>> *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, while having
>> limited ability to receive or transmit on the other links of the set.
>>
>>
>>
>> *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.
>>
>>
>>
>> Any more comments?
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Stephen
>>
>>
>>
>> On Wed, 14 Sept 2022 at 12:25, Minyoung Park <mpark.ieee@xxxxxxxxx>
>> wrote:
>>
>> For EMLMR definition, is "(after receiving a specific control frame)"
>> correct? see below:
>>
>> "NOTE 2â??The initial frame exchange can be any frame exchange with the
>> requirement the soliciting frame needs to
>>
>> satisfy the padding requirement, e.g., through Trigger frame padding if
>> the soliciting frame is Trigger frame, through
>> MPDU Delimiter padding if the soliciting frame is carried in A-MPDU."
>>
>>
>>
>> Behavior of the other link seems to be not clear in the spec as well
>> so I'm not sure what 'limited ability' means here.
>>
>>
>>
>> Regards,
>>
>> Minyoung
>>
>>
>>
>> On Wed, Sep 14, 2022 at 12:35 PM Matthew Fischer <
>> matthew.fischer@xxxxxxxxx> wrote:
>>
>>
>>
>>
>> * 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> 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>
>> *Envoyé :* mardi 13 septembre 2022 21:57
>> *Ã? :* STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
>> *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
>> ------------------------------
>>
>> 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> 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>
>> 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>
>> >> 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> 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>
>> >>>> *Sent:* Monday, September 12, 2022 10:26 PM
>> >>>> *To:* STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <
>> >>>> STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
>> >>>> *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>
>> >>>> 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>
>> >>>> *Sent:* Monday, September 12, 2022 10:14 PM
>> >>>> *To:* Rubayet Shafin <r.shafin@xxxxxxxxxxx>
>> >>>> *Cc:* STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
>> >>>> *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>
>> >>>> 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>
>> >>>> *Sent:* Monday, September 12, 2022 9:21 PM
>> >>>> *To:* STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
>> >>>> *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>
>> >>>> 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>
>> >>>> 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>
>> >>>> *Sent:* Monday, September 12, 2022 2:37 PM
>> >>>> *To:* 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>
>> >>>> wrote:
>> >>>>
>> >>>> Eduard,
>> >>>>
>> >>>> yes, I think that is reasonable.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Kind regards
>> >>>>
>> >>>>
>> >>>>
>> >>>> Stephen
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sun, 11 Sept 2022 at 23:43, Eduard Garcia Villegas <
>> >>>> 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>
>> >>>> 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>
>> >>>> >> *Sent:* Friday, 9 September 2022 14:44
>> >>>> >> *To:* 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
>> >>>> >
>> >>>> >> 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
>>
>
> ________________________________________________________________________
> 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