|
Hi Bo,
Can you please queue the following SPs on AMP frame formats? I am putting this request on behalf of Alfred.
These SPs are intended for SFD motion.
SP1: Do you support that the AMP frame consists of the following basic components:
|
MAC Header
|
Frame Body
|
FCS
|
-
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 TBD16-bit MIC
-
Whether FCS is always present or not for backscatter PPDUs is TBD
With the length of the AMP frame being expressed in octets
Note: TBDs being fixed by subsequent SPs
SP1a: 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 RFID AMP frames backscatter PPDU.
-
AMP frames for AMP-enabled STA and Active TX UL use cases
-
Referring to these as AMP frames non-backscatter PPDU.
-
The indication is TBD.
SP2: Do you support that the MAC Header of the AMP frame comprises Frame Control, ID, and Type Dependent Control fields?
|
|
Frame Control
|
ID
|
Type Dependent
Control
|
|
Bits
|
X
|
Y
|
Z
|
-
Frame Control contains a Type field that indicates the type of AMP frame, and other fields that are TBD.
-
Note: For WUR frame types the Frame Control field inherits from 11ba
-
ID contains an identifier for the AMP frame
-
Whether the ID field is always present or not 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 is TBD
SP2a: Do you support that the MAC Header of the non-backscatter AMP frames comprises Frame Control, ID, and Type Dependent Control fields:
|
|
Frame Control
|
ID
|
Type Dependent
Control
|
|
Bits
|
8
|
12
|
12
|
-
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
SP2b: Do you support that the MAC Header of the backscatter AMP frame comprises Frame Control, ID, and Type Dependent Control fields
|
|
Frame Control
|
ID
|
Type Dependent
Control
|
|
Bits
|
8
|
16
|
16 or 8
|
-
Frame Control contains a Type field that indicates the type of backscatter AMP frame, and other fields that are TBD.
-
One value of the Type field is assigned to backscatter AMP Trigger frame
-
Another value of the Type field is assigned to the backscatter Ack frame and to the backscatter Data frame
-
TBD if same or different values
-
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 new types is TBD
SP3: Do you support that the Frame Control field of the AMP frame is 8 bits?
-
Type field uses the first 3 bits of the Frame Control
SP4: Do you support that the ID field is:
-
based on the frame type/use case
SP5: Do you support that the Type Dependent Control field is
-
12 bits (for non-backscatter use cases)
-
8 or 16 bits (for backscatter use cases)
-
Other options?
SP6: Which option do you support for the maximum length of the Frame Body field:
SP7: Do you support that the length of the Frame Body field is indicated in the MAC header of the RFID AMP frame
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.
SP8: 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.
SP9: 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
SP10: Do you support that the CRC of AMP frames shall use the TBD-bit CRC engine from IEEE 802.11
Best,
Sanket
From: Hui Luo <Hui.Luo@xxxxxxxxxxxx>
Sent: Wednesday, July 30, 2025 5:18 AM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBP] TGbp SP request
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do
not enable macros.
Hi Bo,
Please find the following SP I would like to run tomorrow. This is intended as an SFD motion.
SP1: Do you support to specify a low-complexity secure method to generate and update a PMK for secure AMP communication between
an AMP AP and an AMP non-AP STA?
- Note:
- The secure AMP communication method is defined in Motion 64, 65, 66.
- Whether to include backscatter non-AP STAs in this method is TBD.
- Reference: 11-25/1086, 11-25/0831
Thanks,
Hui
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
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
|