[STDS-802-11-TGBP] FW: [STDS-802-11-TGBP] reminder of SPs in coming TGbp

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

Forwarded from Solomon.

Thank you

Amichai

From: Solomon Trainin <solomon.trainin@xxxxxxxxxx>
Date: Tuesday, 26 August 2025 at 12:35
To: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>, STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Cc: Amichai Sanderovich <amichai.sanderovich@xxxxxxxxxx>, Alon Yehezkely <alon.yehezkely@xxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBP] reminder of SPs in coming TGbp TC on Aug 26

Please see our comments below

Best Regards

Solomon Trainin

From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Tuesday, 26 August 2025 at 8:26
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBP] reminder of SPs in coming TGbp TC on Aug 26

Hi Bo,

Can you please update Alfred's SPs as follows? These are not new SPs, but updated SPs as per offline discussions. The highlighted one is to be deferred.

SP1 (for SFD): Do you agree to add the following text into the 11bp SFD?

Do you support that the AMP frame consists of the following basic components:

A MAC header
A variable-length frame body, which if present, contains information specific to the frame type
An FCS, which contains either a TBD-bit CRC or a 16-bit MIC

Whether FCS is always present or not for backscatter PPDUs is TBD

Note: With the length of the AMP frame being expressed in octets

MAC Header

Frame Body

FCS

[Reference contribution: 11-25/776r2]

Note: In some cases, there may be good reasons not to use CRC and use only MIC, such as in broadcast frames where immediate acknowledgment is not expected. In other cases, the long calculation time of MIC may limit immediate response. Please clarify that replacing CRC with MIC is appropriate when immediate acknowledgment is not required.

SP1a (for SFD): Do you agree to add the following text into the 11bp SFD?

Do you support to have an indication within an AMP PPDU to differentiate between

AMP frames for monostatic and bistatic backscatter use cases

Referring to these as backscatter AMP frames.

AMP frames for AMP-enabled STA and Active TX UL use cases

Referring to these as non-backscatter AMP frames.

The indication is TBD.

[Reference contribution: 11-25/776r2]

Note: Please clarify does the indication belong to PHY level or MAC level?

SP2 (for SFD): Do you agree to add the following text into the 11bp SFD?

Do you support that the MAC Header of the AMP frame comprises Frame Control, ID, and Type Dependent Control fields?

Frame Control contains a Type field that indicates the type of AMP frame, and other fields that are TBD.
ID contains an identifier for the AMP frame

Whether the ID field is always present or not is TBD

Note Probably it is about Receiver ID. Is it ? Where is it the Transmitter ID?
Type Dependent Control contains control information that depends on the type of AMP frame

Whether Type Dependent Control field is always present or not is TBD

Whether there are other fields in the MAC header is TBD

[Reference contribution: 11-25/776r2]

SP2a (Defer): Do you agree to add the following text into the 11bp SFD?

Do you support that the MAC Header of the non-backscatter AMP frames comprises Frame Control, ID, and Type Dependent Control fields

Frame Control contains a Type field that indicates the type of AMP frame, and other fields that are TBD.

Values 0 to 4 of the Type field identify baseline WUR frame types
One value of the Type is assigned to AMP Trigger frame (e.g., value 5 of Type)
Another value of the Type is assigned to AMP Ack frame and AMP Data frame (e.g., value 6 of Type)

TBD if same or different values

Note: AMP Wake Up frame is expected to use the same format and Type value as WUR Wake-Up frame

ID contains an identifier for the AMP frame

Whether the ID field is always present or not for the new types is TBD

Type Dependent Control contains control information that depends on the type of AMP frame

Whether Type Dependent Control field is always present or not for the new types is TBD

Frame Control

Type Dependent

Control

Bits

[Reference contribution: 11-25/776r2]

SP2b (for SFD) Do you agree to add the following text into the 11bp SFD?

Do you support that the MAC Header of the backscatter AMP frame comprises Frame Control, ID, and Type Dependent Control fields

Frame Control contains a Type field that indicates the type of backscatter AMP frame, and other fields that are TBD.
ID contains an identifier for the backscatter AMP frame

Whether the ID field is always present or not is TBD, and has a length of 16 bits

Type Dependent Control contains control information that depends on the type of AMP frame

Whether Type Dependent Control field is always present or not for the backscatter AMP frame is TBD

Frame Control

Type Dependent

Control

Bits

[Reference contribution: 11-25/776r2]

SP3 (for SFD): Do you agree to add the following text into the 11bp SFD?

Do you support that the Frame Control field of the AMP frame is 8 bits?

Type field uses 3-4 bits of the Frame Control

Whether the Type field is the first field of the Frame Control field is TBD

[Reference contribution: 11-25/776r2]

SP4 (for SFD): Do you agree to add the following text into the 11bp SFD?

Do you support that the length of the ID field is based on the frame type/use case:

12 bits for AMP enabled non-AP STAs,
Either 12 or 16 bits for active TX non-AP AMP STAs,
16 bits for backscatter non-AP AMP STAs

[Reference contribution: 11-25/776r2]

Note: How the DL STA distinguishes the frame with different ID size?

We prefer unified size of 16 bits as Rojan suggests

SP5 (for SFD): Do you agree to add the following text into the 11bp SFD?

Do you support that the Type Dependent Control field is

12 bits for AMP enabled non-AP STAs
If present, either 8, 12, or 16 bits for active TX non-AP AMP STAs
If present, TBD (multiple of 8 bits) bits for backscatter non-AP AMP STAs

[Reference contribution: 11-25/776r2]

Note: How the DL STA distinguishes the frame with different Type dependent control size?

We prefer unified 12 bit

SP6 (for information purpose):

Which option do you support for the maximum length of the Frame Body field:

16 octets (obtained from WUR) for non-backscatter use cases.
Option 1: 64 octets (account for max RFID) for backscatter use cases

Citing from external sources: While the EPC length can range from 64 bits to 496 bits, the most common sizes are 96 bits and 128 bits. For some EPC types, 96 bits is the only available option

Option 2: 128 octets (account for max sizes for read and write) for backscatter use cases
Option 3: 256 octets for backscatter use cases

[Reference contribution: 11-25/776r2]

Note: We prefer to have max 128 octets for non-backscattering case

SP7 (for information purpose):

Do you support that the length of the Frame Body field is indicated in the MAC header of the backscatter AMP frame

Specific location, encoding and size is TBD.

For discussion purposes only:

Option 1: if max length is less than or equal to 64 then carry the length in the Frame Control (5 bits with 2 octet resolution)

Option 2: if max length is either 128 or 256 then carry the length in the TD Control field

Above options depend on outcome of SP6.

[Reference contribution: 11-25/776r2]

SP8 (for information purpose):

Which option do you support for the FCS length field for backscatter use cases:

Option 1: 8 bits
Option 2: 16 bits
Option 3: FCS length depends on AMP frame length
Threshold that is to be used for switching from one CRC length to another is TBD

· Note: for non-backscatter use cases, we can use baseline 16 bits CRCs/MICs.

Note: Please add reference

[Reference contribution: 11-25/776r2]

SP9 (for information purpose):

Do you support that the FCS field of all AMP frames has the same size?

This SP can be omitted if O3 of SP7 has more support.

[Reference contribution: 11-25/776r2]

SP10 (for information purpose): Do you support that the CRC of AMP frames shall use the TBD-bit CRC engine from IEEE 802.11?

[Reference contribution: 11-25/776r2]

Best,
Sanket

From: sun.bo1@xxxxxxxxxxxxxxxx <sun.bo1@xxxxxxxxxxxxxxxx>
Sent: Monday, August 25, 2025 1:40 AM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBP] reminder of SPs in coming TGbp TC on Aug 26

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hello, all,

This email serves as a reminder of coming TGbp TC on Aug 26, during which we will continue pending SPs listed in 11-25/0990r5.

https://mentor.ieee.org/802.11/dcn/25/11-25-1429-01-00bp-tg-bp-tc-agenda-till-sep-2025.pptx

https://mentor.ieee.org/802.11/dcn/25/11-25-0990-05-00bp-tg-bp-meeting-agenda-for-jul-plenary-2025.pptx

Each SP Set will have a short slot to recap the background. We will start from the SP11 in SP Set #9 (Rojan). If you have a deferred SP in Jul f2f meeting and want it back to the pending SP list, please re-announce your request to the reflector.

Best Regards,

To unsubscribe from the STDS-802-11-TGBP list, click the following link: https://protect.checkpoint.com/v2/r01/___https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBP&A=1___.YzJ1OndpbGlvdDI6YzpvOjQ4MWMxOGFiOGM3N2ZkN2I1NjA3OTIzMDE5NTc0MGU4Ojc6NTUzZjpjNWIyOTliMGMwNGEyZjJkYmNmMGE3YzNiZGNmNTM4ZGFiZjVhNTFlMWVkNWMyNzIyN2ZjMjMyNGZhNmVlMzdhOnQ6VDpG

To unsubscribe from the STDS-802-11-TGBP list, click the following link: https://protect.checkpoint.com/v2/r01/___https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBP&A=1___.YzJ1OndpbGlvdDI6YzpvOjQ4MWMxOGFiOGM3N2ZkN2I1NjA3OTIzMDE5NTc0MGU4Ojc6YzY1MzowMzdlNzBhMTVlNzA5NzJjYmY5YmEyYzgyZDUwOTVkNTE1ZDk3Y2E0NTM2MDVkZjE2NGMwY2YxM2VlMjYwOWY3OnQ6VDpG

To unsubscribe from the STDS-802-11-TGBP list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBP&A=1

[STDS-802-11-TGBP] FW: [STDS-802-11-TGBP] reminder of SPs in coming TGbp TC on Aug 26