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

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答���: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

Hello Matt

 

I am not sure what is profile you mentioned? Is that per STA profile? If it is, actually, it will not be carried in Beacon frame such that to avoid bloating issue in typical case (does not touch exception). That is to say, only common field of ML IE is carried in Beacon frame.

 

Best wishes

Ming Gan

 

发件人: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2021年4月1日 2:38
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

 

In the Beacon, the AP include the ML IE plus the RNR.

So, in the Beacon, the ML IE contains only one profile and the RNR has the others.

Then, in the ASSOC REP, the AP transmits multiple profiles in the ML IE and does not include an RNR.

 

Correct?

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office

 

 

On Wed, Mar 31, 2021 at 11:35 AM Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:

Hi Matt,

 

Why do you say AP will have only one per-STA profile?

 

Say for example, non-AP MLD were to request 3 links for ML setup, then the assco req will include Basic variant ML IE containing complete profile for 2 STAs. The transmitting STA’s info is in the core frame and the per-STA profile of basic variant ML IE carries the info of each of the other 2 STAs of the non-AP MLD.

 

AP MLD accepts all 3 links. The AP’s assoc resp frame include Basic variant ML IE containing complete profile for 2 APs. The transmitting AP’s info is in the core frame and the per-STA profile of Basic variant ML IE carries the info of each of the other 2 APs of the AP MLD.

 

Some of this is already covered in clause 35.3.5 (D0.4).

There are CR docs in the queue (from Po-Kai, Insun, myself) which will provide further clarification.


Regards,
Abhi

 

 

From: Matthew Fischer <matthew.fischer@xxxxxxxxxxxx>
Sent: Wednesday, March 31, 2021 11:28 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 


Abhi,

 

Hmmm.

This is where I started: I had thought that this was the answer for the AP.

So there is an asymmetry, in that for the AP, there is only one per-STA profile but for the non-AP STA, there are n.

 

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office

 

 

On Wed, Mar 31, 2021 at 11:21 AM Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:

 

Hi Matt,

 

Good question. That portion is getting clarified in my doc 11-21/254.

The (Re-)Assoc Req frame will carry the MAC address of the corresponding STA that is capable of operating on that link.

 

Regards,

Abhi

 

 

From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 31, 2021 11:12 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 


Ming,

 

Ok.

What about the other direction?

Can the AP determine, during an ML setup operation, what the per link non-AP STA MLD MAC addresses are?

And can it determine which link ID they correspond to?

If the per link addresses are found in the RNR, then certainly, there is no RNR being transmitted by a non-AP MLD.

So how are these addresses and their relationships to the links provided to the AP during the setup operation?

 

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office

 

 

On Tue, Mar 30, 2021 at 7:04 PM Ganming(Ming Gan) <ming.gan@xxxxxxxxxx> wrote:

Thanks, I was aware you guys’ response just now. The below answer is right.

 

发件人: Cariou, Laurent [mailto:laurent.cariou@xxxxxxxxx]
发送时间: 2021年3月31日 3:21
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Matt,

Check 35.3.4.1 for the rules for inclusion in RNR.

Best

Laurent

 

From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 30, 2021 9:06 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Matt,


The Beacon and Probe Response frame transmitted by an AP affiliated with an AP MLD includes Reduced Neighbor Report (RNR) IE [9.4.2.170.2] which carries the BSSID, Op class, Op channel for each reported AP that is affiliated with the same AP MLD. The RNR also carries Link ID and CSN for each of the reported AP that is affiliated with that AP MLD.

 

Ming’s document provides Link ID and CSN for the reporting (i.e., transmitting) AP.

 

Hope this helps!

 

Regards,
Abhi

 

From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 30, 2021 9:12 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 


Ming

 

I realize that 397 was just approved, but let me be certain that I understand what was approved:

 

It looks like, if I am a non-AP STA, then I need to receive a separate ML element on each of the links of an AP MLD in order to establish the AP link address, link ID and channel values for each link.

 

I.e. based on the approved text changes, I cannot see a method that allows an AP to include the following information in a single MPDU that could be received on a single link:

 

1) the AP link address for every link of the AP MLD

2) the link ID values every link of the AP MLD (and of course, the correspondence with each AP link address)

3) the channel/operating class/freq information for every link

 

Each of these pieces of information must be received one at a time on the associated link.

 

Is that correct?

 

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office

 

 

On Fri, Mar 19, 2021 at 6:40 AM Ganming(Ming Gan) <ming.gan@xxxxxxxxxx> wrote:

Hi Gaurang

 

You miss my response in previous attached file- update it in the later version. Please see the attached new version. Meanwhile please see my response inline

 

The ML ID is just for discussion in the attached file

 

For discussion:

The MLD ID for any reported AP should be unique and not changed sent by a reporting AP according to the approved document

The usage of MLD ID in RNR element:

MLD ID could be used to solicit the info of specific AP MLD which is advertised by the reporting AP, such as AP MLD which contains nontransmitted BSSID in the same MLD as the reporting AP

Link ID is used to solicit the info of the transmitting AP, same as other link ID in the STA profile.

 

发件人: Gaurang Naik [mailto:gnaik@xxxxxxxxxxxxxxxx]
发送时间: 2021年3月18日 22:51
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Ming,

 

Thank you very much for responding to my comments.

 

I looked at the responses in both versions of the document and found that a few of my questions/comments were not addressed. I have reinserted a few comments in the latest version (r2).

 

Also, the approved SP text (copied below) relates to Link ID and CSN, both of which apply to an AP MLD. The motion doesn't talk about MLD ID. Could you kindly explain why the probe request variant of ML IE needs to carry MLD ID and Link ID?

The CSN and Link ID fields are reserved when transmitted by a STA of a non-AP MLD transmits ML IE and therefore, this change must be captured in clause 9 not clause 35. This is the normal practice in baseline spec.

[Ming] Since it clause 9, it already mentions

The condition for the presence of the MLD MAC Address subfield, the Transmitting AP Link ID subfield and the Transmitting AP Change Sequence subfield in the Common Info field is defined in 35.3.5.4 (Usage and rules of Multi-link element in the context of multi-link setup) and 35.3.4.3 (Multi-link element usage rules in the context of discovery).

So it is not needed in clause 9

 

 

In addition, I also noticed that the changes in clause 35 are not with respect to approved text (for example, clause 35.3.4.4 was updated by a few docs). The numbering of the subclauses is also incorrect. I’m afraid this can create a conflict when the editor tries to incorporate your changes. Resulting in some of the changes from your doc being missing in the next draft. I suggest that you base your changes with respect to the latest approved text.

[Ming] It is updated, please refer to the attached file. Thanks

 

Thanks,

Gaurang

 

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, March 17, 2021 9:16 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Ming,

 

I have similar questions as Gaurang. It is not clear to me why the MLD ID and Transmitting AP link id is included in the Probe Request variant MLE. Moreover, the PDT does not contain any normative text that explains what these fields are for. My impression of the Motion covered in the PDT was that it only targets the Basic variant MLE; I believe SP2 about ML probe request has not been run yet. Shouldn’t we run the SP first?

 

Regards,

Rojan

 

From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Thursday, March 18, 2021 9:46 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hello Gaurang

 

Thanks for your comments, please see that attached response.

 

Best wishes

Ming

 

 

发件人: Gaurang Naik [mailto:gnaik@xxxxxxxxxxxxxxxx]
发送时间: 2021年3月18日 4:07
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Ming,

 

I noticed that a newer version of the document was posted on mentor. I have one additional comment that I have inserted in the attached file. Could you kindly take a look?

 

Thanks,

Gaurang

 

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, March 17, 2021 9:47 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Ming,

 

I have a few comments that I have inserted in the attached document. One of them aligns with what Rojan described below. Could you kindly review my comments?

 

Thanks,

Gaurang

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 9, 2021 7:51 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Ming,

 

I meant that transmitting AP information is not relevant for Probe Request variant ML element, so I did not understand why the common info has to be the same. I am working on the CRs for CIDs related to 9.4.2.247b.3 (Probe Request variant Multi-Link element) and think this discussion may be more relevant in that document and would appreciate if you can take this clause out from your CR document. I will share my CR document soon.

 

Regards,

Rojan

 

From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Tuesday, March 9, 2021 4:44 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Thanks Rojan, so you are saying common part of ML element is not needed?

 

actually there is still difference between basic variant and Probe request variant. That is Per STA profile, the Probe Request variant only has Per-STA Control field.

 

Best wishes

Ming Gan

 

发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
发送时间: 2021年3月8日 11:16
收件人: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Ming,

 

Thanks for the PDT. Regarding the below changes:

9.4.2.247b.3    Probe Request variant Multi-Link element

…

The presence and format of the Common Info field in the Probe Request variant Multi-Link element are TBD.

The format of the Common Info field in the Probe Request variant Multi-Link element is as same as Basic variant Multi-Link element as defined in Figure 9-xxxx - Link Info field of the Basic variant Multi-Link element.

 

The Motion is not relevant to the probe request variant ML element since the transmitting AP’s information will never be carried in it. There is no meaning of having a separate variant of ML element Type for Probe Request if the format is the same as the Basic variant. Also, I am making changes to this sub-clause as part of the D0.3 CRs. Would you be ok to take this out from your PDT and we can discuss this during my CRs if needed?

 

Thanks.

 

Regards,

Rojan

 

From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Monday, March 8, 2021 9:23 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hello Alfred

 

Could you add the following PDT document into the queue? Thanks.

 

11-21-0397-00-00be-PDT ML element for transmitting AP

https://mentor.ieee.org/802.11/dcn/21/11-21-0397-00-00be-pdt-ml-element-for-transmitting-ap.docx

 

best wishes

Ming Gan

发件人: Huang, Po-kai [mailto:po-kai.huang@xxxxxxxxx]
发送时间: 2021年3月7日 1:53
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Alfred,

 

              I have a CR document for clause 35.3.11. Can you add it to the MAC queue?

 

              https://mentor.ieee.org/802.11/dcn/21/11-21-0320-00-00be-cr-for-35-3-11.docx

 

Best,

Po-Kai

 

From: Huang, Po-kai
Sent: Friday, March 05, 2021 8:46 AM
To: 'asterjadhi@xxxxxxxxx' <asterjadhi@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hi Alfred,

             

              I have a CR document for clause 12.4. Can you add it to the MAC queue?

 

              https://mentor.ieee.org/802.11/dcn/21/11-21-0260-01-00be-cr-for-12-4.docx

 

Best,

Po-Kai

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Friday, February 26, 2021 9:28 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] TGbe Teleconferences [03/01/2021 and 03/03/2021]: Agendas Posted

 

Hello all,

 

I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Monday, March 01 (MAC/PHY), 19:00-22:00 ET and Wednesday, March 03 (JOINT), 10:00-12:00 ET.

 

The agendas can be found here:

https://mentor.ieee.org/802.11/dcn/20/11-20-1917-30-00be-jan-mar-tgbe-teleconference-agendas.docx

 

DIAL IN DETAILS FOR MONDAY:

Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m7ff091053a52e440f4d2a5484310a902
Meeting number: 179 294 5804
Meeting password: wireless (94735377 from phones and video systems)   

 

Meeting number: 179 600 1391
Meeting password: wireless (94735377 from phones and video systems)

 

DIAL IN DETAILS FOR WEDNESDAY:

Join the JOINT meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m1d1c71d54a60bd6b9c5fafd719c959d9

Meeting number: 179 925 7715
Meeting password: wireless (94735377 from phones and video systems)

 

Notice: Please note that by now all authors of the submissions for PDTs and CRs (especially MAC) should have sent requests for feedback to the IEEE TGbe reflector. Members are invited to provide feedback for these contributions prior to the conference call via e-mail so that the time in the conf calls is used efficiently. 

 

Best Regards,

 

Alfred

 

 

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302

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

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


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

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


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.


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

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