Sent: Monday, October 31, 2022 6:51 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
Dear all,if there are no more comments on the EMLMR definition, I'm happy to go with the suggestion from Massinissa (slightly modified):
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 frame exchanges on one link of the set, while having the ability to receive or transmit on the other links of the set, the number of chains involved per link being negotiated per frame exchange sequence.
I hope to present a resolution to about 5 CIDs based on this definition either during the Bangkok TGbe ad-hoc or the main meeting. Thanks.
Kind regards
Stephen
On Fri, 14 Oct 2022 at 10:17, Michail Koundourakis <m.koundou@xxxxxxxxxxxxxxxxxxx> wrote:
Hi Stephen,
I agree with Massinissa’s comment; the suggested EMLMR definition can be applicable to STR/NSTR link sets, so it is not unique to EMLMR.
The definition may need to say that EMLMR is an enhanced operation of STR/NSTR which allows the MLD devices to use additional chains on one of the links, compared to the STR/NSTR capabilities.
For clarity (when read in conjunction to EMLMR), I wonder if the EMLSR should specify that when EMLSR in disabled on the same link set, neither STR or NSTR is possible (as the STA has only 1 radio with full Tx/Rx capabilities).
I hope this helps.
Kind regards,
Michail
From: LALAM Massinissa <00001c2d776ab802-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: 14 October 2022 09:30
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] EMLSR and EMLMR definitions
Dear Stephen,
Thanks for the proposal. I’m fine with EMLSR definition.
However, I’m still unclear on how the proposed EMLMR definition is different from the STR (or NSTR) operation now. Devices operating on STR/NSTR mode can listen on a set of enabled links, perform a set of frame exchange on one link while still being able to receive of transmit on the other set (with more constraints on the NSTR case).
I do think that some precision should be added on how it is different than STR for instance. My impression was that EMLMR allowed some “transfer” of the transmit and receive capabilities from one link to the other for a given frame exchange. Maybe something among those lines
.
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 the ability to receive or transmit on the other links of the set, the number of chains involved per link being negotiated per set of frame exchange.
While not perfect, I think at least it conveys the idea that there is a negotiation
Regards,
Massinissa
De : Stephen McCann <mccann.stephen@xxxxxxxxx>
Envoyé : vendredi 14 octobre 2022 09:54
À : STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Objet : [STDS-802-11-TGBE] EMLSR and EMLMR definitions
[EXTERNAL]-Real sender is: owner-stds-802-11-tgbe@xxxxxxxxxxxxxxxxx
Dear all,
ok, time to revisit these definitions to see if I can complete my CID assignments ! Are there any further comments please? Thanks.
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.
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 the ability to receive or transmit on the other links of the set.
Kind regards
Stephen
On Thu, 15 Sept 2022 at 16:39, Eduard Garcia Villegas <eduardg@xxxxxxxxxxxxx> wrote:
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
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
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