| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Gramham ,
Thanks for your kindly suggestion. But I feel your proposed text doesn't follow the writing style in 802.11 draft.
If we look at other instance in 802.11be draft, e.g. "dot11MSDTXOPMax" MIB attribute, which is similar to our case.
In subclause 9:
The Medium Synchronization Maximum Number Of TXOPs subfield contains the maximum number of TXOPs (dot11MSDTXOPMax) that a STA is allowed to attempt to initiate while the MediumSyncDelay timer is running at the STA minus 1, except that the value 15 indicates any number of TXOPs as long as the MediumSyncDelay timer is nonzero.
In subclause 35.3.16.8.2
—Shall not attempt to initiate a TXOP more than dot11MSDTXOPMax times since the start of the timer.
Each non-AP STA affiliated with a non-AP MLD shall set dot11MSDTXOPMax and dot11MSDOFDMEDthreshold to the most recent values carried in the Medium Synchronization Maximum Number Of TXOPs subfield and Medium Synchronization OFDM ED Threshold subfield , respectively, if they are present in the Common Info field of the Basic Multi-Link element received by any non-AP STA affiliated with the same non-AP MLD from its associated AP affiliated with the AP MLD with which the non-AP MLD has performed ML setup.
Annex C
dot11MSDTXOPMax OBJECT-TYPE
SYNTAX Unsigned32 (1..16)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or by the MAC of a non-AP EHT STA upon receiving a Basic Multi-Link element containing a Medium Synchronization
Maximum Number Of TXOPs field value from the EHT AP with which it is associated. Changes take effect as soon as practical in the implementation.
This attribute indicates the maximum number of TXOPs a STA is allowed to initiate when the MediumSyncDelay timer of the MAC has nonzero value except that the value 16 indicates the STA can initiate any number of TXOPs ."
DEFVAL { 1 }
::= { dot11EHTStationConfigEntry 5 }
Based on that, I propose the following change:
in subclause 9
The Device ID field contains a device ID or an opaque identifier (see Annex AD.1) from dot11DeviceID .”
in subclause 12.2.11.1
A non-AP STA that is associating or using PASN with any AP in an ESS , when Device ID is active for both the non-AP STA and the AP， and the non-AP STA has a saved device ID in dot11DeviceID for the ESS , shall send the most recently received dot11DeviceID value for that ESS in the frame containing device ID. "
Regarding the array discussion, suppose dot11DeviceID is already in the array of dot11StationConfigEntry according the the Annex C text as bellow.
Insert the following entries to the end of the "dot11StationConfigEntry” of the
“dot11StationConfig TABLE” as follows:
…,
dot11DeviceIDActivated TruthValue ,
dot11DeviceID OCTET_STRING,
dot11IRMActivated TruthValue
}
Please correct me if I make any mistake.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Hi Jay,
May I suggest that at P30.54, you insert a new sentence, something like:
“The non-AP STA should store the newly provided Device ID in the dot11DeviceID MIB attribute as an identifier for use with that AP/ESS .”
Then leave it at that?
Furthermore, Mark is correct that it is an array, but not sure what to do about that. Should the MIB change?
Graham
From: Jay Yang <yang.zhijie@ZTE .COM.CN>
Sent: Tuesday, October 10, 2023 2:14 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2
Hi Mark, Graham,
Thanks for your response.
Based on Mark's comment, I think we can only have the following change to incroprate MIB attribute dot11DeviceID
in subclause 12.2.11.1. "
A non-AP STA that is associating or using PASN with any AP in an ESS , when Device ID is active for both the non-AP STA and the AP， and the non-AP STA has a saved device ID in dot11DeviceID for the ESS , shall send the most recently received dot11DeviceID value for that ESS in the frame containing device ID. "
Any further thought on this?
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original
From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>
Date: 2023年10月10日 04:31
Subject: Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2
All,
(Sorry, I’m traveling today/at the moment, so I can’t be very complete – I’ll work on this a bit tonight.)
My thoughts:
I agree with Graham, keep it simple. I would just mention somewhere in clause 12 that when a non-AP STA receives a device ID (during any of the frame exchanges we are adding) then it shall save it in the dot11DeviceID MIB attribute. And, when a non-AP STA is connecting to a network for which it has a stored device ID, then it provides the dot11DeviceID value in the appropriate frame. (I think this mostly what Jay suggested with a couple of his sentences below, but I think the wording Jay has suggested is a little odd.)
I don’t we say anything about the AP side. That is, in particular, I don’t think the AP has a dot11DeviceID MIB attribute at all, and we should state that clearly. Note that otherwise, the AP’s MIB would need to store every still valid device ID that it had ever allocated, along with some sort of connection to the “local state” that goes with it – and I really don’t want to try to explain within the MIB what that latter part would look like.
A question to the group, though (did we discuss this already?): Should the non-AP STA have an array of stored device IDs, mapped to the SSID of the network that provided each? That is, in the MIB , dot11DeviceID should be an array, and our description above about non-AP STA behavior is all with reference to the particular entry that corresponds to the SSID of the network being connected to?
Mark
From: Kurt Lumbatis <kurt.lumbatis@xxxxxxxxxxxxxx>
Sent: Monday, October 9, 2023 10:18 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] defered CID159 and CID 276 in 1369r2
I think that changing to dot11DeviceID makes sense, and I would support it.
Fix typo
|
Kurt
On Sun, Oct 8, 2023 at 6:32 AM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:
Hi all,
CID 159 and CID276 in 1369r2 are defered from last call. Let's have some discussion in this mail loop and make the decision to address them.
CID276:
As the commenter said, we define dot11DeviceID in Annex C but never use it in the normative text.
To address the commenter 's concern,one approach is to remove the defination of dot11DeviceID from Annex C.
Another approach is to have some text change in subclause 9 and And in subclause 12.2.11.1(in red font) as bellow, I would like to know our group's preference.
" The Device ID field contains a device ID dot11DeviceID or an opaque identifier (see Annex AD.1)."
"Assign a new device ID value dot11DeviceID in Device ID field, and set Device ID Status field of Device ID KDE or Device ID element to 0 to indicate that AP recognizes the non-AP STA in the appropriate frame."
"When an AP with dot11DeviceIDActivated equal to true receives a first PASN frame containing a device ID which is recognized,the AP shall assign a new device ID value dot11DeviceID to the non-AP STA,via setting a new device ID in Device ID field with the Device ID Status field of Device ID element set to 0 to indicate that the AP recognizes the non-AP STA in the second PASN frame."
276
27/61
dot11DeviceID is not referenced in body text
Either add that the Device ID field contains the ID from dot11DeviceID here and add behavioral text (probably in clause 12) that sets the attribute when a Device ID is received at a non-AP STA, or remove the MIB attribute from Annex C.
Revised--
CID 159:
Based on the commenter 's suggestion, I think we need change to description in the note as bellow(in red font):
9.3.3.5 Association Request frame format/9.3.3.6 Association Response frame format/9.3.3.7 Reassociation Request frame format/9.3.3.8 Reassociation Response frame format
Order
Information
Notes
Device ID
If dot11DeviceIDctivated is true and dot11FILSActivated is true,the Device ID element is optionally present when using FILS
authentication; otherwise, it is not present.
63
IRM
If dot11IRMActivated is true and dot11FILSActivated is true, the IRM element is optionally present when using FILS authentication;
otherwise, it is not present.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1