Hi Rojan,
Thank you for your comment.
It seems my proposal is still unclear. I do not suggest defining the interface between the 802.11 protocol and non-802.11 protocols. I suggest enabling the inclusion of the Vendor Specific Element (9.4.2.24) in action frames for managing the AMP energizer and adding the VendorSpecificInfo parameter to the corresponding MLME primitives.
There are many examples in the 802.11 about the suggested formats. You can see the Vendor Specific element in the 9.6 Action frame format details and the VendorSpecificInfo in the 6.5 MLME SAP primitives. [IEEE P802.11-REVmf/D2.0, February 2026]
Best Regards,
Solomon Trainin
+972547885738
From: Rojan Chitrakar [mailto:00002005fb56ded7-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, March 31, 2026 12:21 PM
To: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBP] Response to comments on DCN 11-26-0303-01
Hi Solomin,
I have no issues with defining Vendor Specific element, if needed, since Vendor Specific element are meant to be carried in 802.11 frames. My concern is on defining MLME primitives to control vendor specific implementations. These can be done by implementation specific interfaces. I don’t understand why 11bp has to define interfaces between 802.11 protocol and non-802.11 protocols; if you are aware of such precedent in the 802.11 specifications, please enlighten me.
Best Regards,
Rojan Chitrakar
From: Solomon Trainin <solomon.trainin1@xxxxxxxxx>
Sent: Monday, March 30, 2026 4:32 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxx>
Cc: STDS-802-11-TGBP@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBP] Response to comments on DCN 11-26-0303-01
Hi Rojan,
I want to elaborate on your concerns:
1. Why the vendor-specific IE it needed?
2. What are existing examples for vendor-specific IE in the 802.11 standard, and how does it work to communicate with non-802.11-compatible devices?
Responses
1. We need it for several reasons, the first one being to control a non-collocated AMP Energizer via BLE or UART connections.
2. In relation to the 802.11 [IEEE P802.11-REVmf/D2.0, February 2026]: The Vendor Specific element is defined in 9.4.2.24
The Vendor Specific element is used to carry information not defined in this standard so that interoperability is achieved in the presence of nonstandard information.
The example below shows how this element is used in an IoT hub to communicate using 802.11 protocol on one side and non-802.11 protocols on the other side (UART, BLE, Zigbee, etc.).
The general flow is as follows:
802.11 Action Frame (Vendor IE)
↓
Wi-Fi chipset / firmware
↓
chipset-level signaling
↓
Host driver / gateway logic
↓
UART / Ethernet / BLE
↓
Non-Wi-Fi device
An IoT hub is a multi-protocol gateway that:
· Speaks Wi-Fi (802.11) on one side
· Speaks non-Wi-Fi protocols on the other (UART, BLE, Zigbee, etc.)
· Translates between them
· Runs logic (rules, provisioning, control)
In this case, the hub is the bridge that makes this work:
802.11 Action Frame (Vendor IE)
↓
Wi-Fi chipset / firmware
↓
driver / OS
↓
IoT Hub logic
↓
UART / BLE / Ethernet
↓
Non-Wi-Fi device
An example of the products where this approach can be deployed:
· Amazon Echo
· Samsung SmartThings Hub
· Home Assistant (running on a gateway device)
These are the kinds of payloads that make sense given:
· small size (~200 bytes practical)
· low latency
· control-plane nature (not bulk data)
Used for Parameter Updates / Tuning
What is delivered:
Operational parameters
Example payload
TYPE=CONFIG
ID=sensor_123
THRESHOLD=75
INTERVAL=10
Best Regards,
Solomon Trainin
+972547885738
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