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

Re: [STDS-802-11-TGBC] [EXTERNAL] Re: [STDS-802-11-TGBC] CID 4032 - Discussion



Hi John,

Even IoT devices need to be provisioned with information to connect to an AP. For EPCS, I view the information that is provisioned on the device would include the value for xx-yy-zz in the MAC address. 

In Wi-Fi Easy Connect, for example, you could create a profile that would allow provisioning of EPCS information for client devices, which would include IoT devices..

Cheers,

Mike

On Tue, Aug 30, 2022 at 2:39 PM Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> wrote:
Mike,
   I can see how that type of operation can work for SSID - a device simply needs to wait for the next beacon(s) to determine the SSIDs that are active in an area.  That could even be manual - the administrator might scan for active networks before deploying a new AP.  But IOT sensors will not be sending beacons and may only send information infrequently, so such scanning might easily miss a device in the area that is already configured to use a particular xx-yy-zz pattern.  And multiple EBCS devices might be positioned in the same area by separate administrators (e.g., smart-home IoT devices in different apartments in the same building), who would not know to coordinate with each other.
   We can certainly leave it as a provisioning issue, but it seems to be a very problematic one.
John


From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, August 30, 2022 12:15 PM
To: Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx>
Subject: Re: [EXTERNAL] Re: [STDS-802-11-TGBC] CID 4032 - Discussion
 
Hi John,

In any deployment, the EPCS stream information for the non-AP STAs need to be provisioned somehow on the non-AP STAs. For example, IoT sensors typically have a provisioning mode where you can configure information WLAN network. For EPCS, my understanding would be that the provisioning would include setting the "xx-yy-zz" for the EPCS address.

Cheers,

Mike

On Tue, Aug 30, 2022 at 11:57 AM Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> wrote:
Mike,
   The idea that xx-yy should be assigned in a manner similar to SSIDs makes sense.  The first sentence in the note sort of says that: "...are expected to be set...".  But I'm still stuck on the UL case, where you indicate that "There are multiple ways beyond the scope of the standard to assign xx-yy-zz so that they are unique to the deployment."  Can you provide an example?  For UL traffic, those values are assigned by EPCS non-AP STAs and I don't see how independent STAs coordinate to ensure uniqueness.  Given the need to support unassociated STAs, I don't see any means for a network operator to manage the situation either.
Thanks,
John


From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, August 30, 2022 11:34 AM
To: Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [STDS-802-11-TGBC] CID 4032 - Discussion
 
Hi John,

Thanks for your comment. In my view, the assignment of xx-yy needs to be decided depending on the deployment and needs to be managed. This is no different than the assignment of SSID. 

The assignment really depends on the EBCS content and the characteristics of the deployment. 

The standard can recommend that the assignment be unique. There are multiple ways beyond the scope of the standard to assign xx-yy-zz so that they are unique to the deployment.

Does that make sense?

Cheers,

Mike

On Tue, Aug 30, 2022 at 11:03 AM Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> wrote:
Folks,
   I wanted to initiate an offline discussion on this CID to seek your help in determining a path forward.  This CID relates to the following text in Clause 11.55.2:

NOTE—Although the octets xx and yy for EBCS DL traffic areexpected to be set to a combination of values that are
unique to the coverage area where the content is being broadcast, the uniqueness of the octets xx and yy is not
guaranteed. The octets xx, yy, and zz for EBCS UL traffic must be set to values that are unique to the UL traffic stream.
EBCS UL and EBCS Data frames can be differentiated because the EBCS UL frame is a management frame while the
EBCS Data frame is a Data frame.

The CID specifically addresses the second sentence, in bold, which says that the combination of xx, yy, and xx must be unique for each UL traffic stream.  The concern is that these values are "configured by the EBCS non-AP STA".  What is not clear to me is how independent EBCS non-AP STAs will ensure this uniqueness.  Given that UL traffic can be generated by unassociated STAs, I don't see a clear path to coordinating the values.  I can imagine ways that an EBCS non-AP STA could attempt to generate a unique value (e.g., listen for UL traffic before initial transmission, populate based on values extracted from the on-board clock) but these would not guarantee uniqueness.  
   We don't necessarily need to define a solution in the document, but I think it would help if we gave some indication of the expectation on the EBCA non-AP STA. So I am asking for your thoughts on how this uniqueness would/could/should be accomplished. 

John

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


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