|
Hi Sam, Amichai,
The motion FM-29 talks about including frame body in UL response and not in an AMP Trigger frame. But it seems that the discussion below is about including a frame body in a Trigger frame. Am I missing something?
Best,
Sanket
From: Sam Shi <Sam.Shi@xxxxxxxxxxxxxxxx>
Sent: Wednesday, September 9, 2026 1:27 PM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBP] Agenda update for coming TGbp TC
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and
do not enable macros.
Hi Alfred,
It's FM-29 and I have to say it's a bit implicit, but the following wording was the best we could capture after a long discussion. Essentially, the use case is frame exchange (carrying application data) without association.
-
The Active Tx non-AP AMP STA may include a Frame Body field in its UL response during a random access session, if the inclusion of the Frame Body field is solicited by the AMP AP.
-
This UL response may be triggered without prior exchange of capabilities/identifiers.
-
Note: the frame type of the AMP frame, content and requirement of inclusion of the frame body are TBD.
-
Note: whether the indication of the soliciting is implicit or explicit is TBD.
The use case is:
-
1st (ever) msg: AP sends DL multi-slots random access trigger to STAs. This message acts as a UL trigger and is also for security purpose.
-
2nd msg: the STAs send UL data in the time slots. The same msg also completes the security.
-
The process is done.
Thanks,
Sam
From: Amichai Sanderovich <00003126a116a6ee-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 9, 2026 12:45 PM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBP] Agenda update for coming TGbp TC
Hello Alfred,
We could have been clearer (for sure it was if you were in the loop when we run the motion), but please see below:
In FM-29 and its supportive document, it clearly states that the active Tx STA frame body in the response is solicited by AMP-AP, without any prior exchange of information or identifiers (as Sam pointed out - no association).
This motion is the required addition for allowing the 1-step uplink access (as long as the frame body is not limited, the frame body is there).
By limiting the use of the frame body in the trigger frame as in the current suggested format, the agreed usage in
FM-29 is not possible.
Best Regards
Amichai
From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Date: Wednesday, 9 September 2026 at 21:48
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBP] Agenda update for coming TGbp TC
Can you point out which motion talks about these?
Regards,
Alfred
I concur with Amichai about the following case, which were discussed in the group. For inventory, this can be the case that AP and STAs are never associated. Then the frame body would carry upper layer data to allow the target STAs to respond.
Thanks,
Sam
Hello Alfred,
Just a follow-up on yesterday’s call, which I missed on my first pass on the document.
Our intention in the motion for including the frame body in the trigger frame is
only for application data (upper layer use).
Some examples for the usage:
-
Inventory Example: we would like to inventory only Coco cola and not Pepsa cola or chicken nuggets or barbie dolls. Thus we need application data in the trigger frame that will solicit just these. Otherwise we
need to trigger ALL the devices and get overwhelming number of non-needed responses.
-
Agriculture Example: we would like to water the arid ground and avoid watering where the ground is already humid. This is done by using a device next to each plant and water where it is too dry. Application will
want to solicit response only from sensors that sense low humidity. It can be 5 in a field of 2000. We do not want a response from all of them. Just from the sensors that passed a threshold.
Best Regards
Amichai
Hello Alfred,
See below my response
Best Regards
Amichai
Hi Amichai,
Thanks for reviewing. Please find some responses/thoughts below [AA]:
Few comments I have:
-
BSSID is not known to the non-AP STA, so perhaps it can be replaced by AP transmitter ID that can be selected randomly.
[AS] when unassociated, the only identity of TX known at the AMP non-AP STA is the short ID TX address. This is sufficient for communicating required AMP information. For example, the TF consists of an AMP-AP ID, which can then be used for the CRC calculation
of the SYNC, the receiver ID of the responses and also the ID used in any further communication (non-associated).
-
AMP-AP are not necessarily APs. They can be non-AP STA as well. So they won’t have a unique BSSID.
[AS] AMP-AP is more a reader than AP. It is not required to transmit beacons, receive prob requests or even associate any non-AP STAs. Thus it does not have to have a
BSSID - not sure whether we need to define such AMP-BSSID at all. AFAIK, standard MAC address of the AMP-AP should be
sufficient?
-
Slot duration: We prefer the slot duration to be signaled in units of bytes and not micro-seconds.
[AS] By defining the duration as length instead of time in us - we avoid many complexities like: clock drifts/mismatch issues, definitions brevity (will AP have enough time to send the ACK?, do we
need to mandate many behaviors of the AP to make sure both sides use the same calculation, etc.). Also it makes the STA MAC simpler since no devision calculation is needed. This is especially helpful when upper layer length calculations are also needed within
SIFS.
Regards,
Alfred
Regards,
Alfred
Hello Alfred,
Thank you for the PDT.
Few comments I have:
-
BSSID is not known to the non-AP STA, so perhaps it can be replaced by AP transmitter ID that can be selected randomly.
-
AMP-AP are not necessarily APs. They can be non-AP STA as well. So they won’t have a unique BSSID.
-
Slot duration: We prefer the slot duration to be signaled in units of bytes and not micro-seconds.
Best Regards,
Amichai
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___.YzJ1OndpbGlvdDI6YzpvOjE4YzkzNGRjNDhmYzJkNWE5NWZjYzVmNTBlMzUwMzQ5Ojc6MTBhYzplZmUzMDM0MDY1YjJlMjU0OWRhZWU3ZTZhMzQ0MzcxOGY3MzJmYTQ4NzFiZGVlZmUyZmM5ZmM2OTM3NmUzMWZiOnQ6VDpG
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
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___.YzJ1OndpbGlvdDI6YzpvOjE3NTkxMjcxNTBkYzFiYWQwYWMwMWE0ZWZlMDJhM2VmOjc6YTdjMzpjOTk3NjdjMzQ0NzhlNTUyN2Y0MDFjNThkNWRmOTUzMjcwNjg1NTIwMDJkYWM3MTU3ZjgyZGJjMDQzYjM4M2Q5OnQ6VDpG
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
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
|