|
I went over the addressing sections of the document again, and I think I am seeing the source of my confusion.
- In clause 4, the descriptions of UL traffic filtering based on destination of the frames refer to the URI.
- In contrast, Clause 11.55.4.2 indicates that the EBCS proxy can filter UL traffic based on the Address 3 value that "does not match the one or more EBCS content MAC
addresses that can be based on the relationship between the EBCS proxy and one or more destinations".
- Further, Clause 11.55.2 says that for UL frames, "octets xx, yy and zz are configured by the EBCS non-AP STA".
The first and the last bullet, taken together, seem to suggest that the xx, yy, zz combination is created by each EBCS non-AP STA. The middle bullet suggests that the xx, yy, zz combination is set to a value that corresponds to the destination.
The Note I quoted below, which says that xx, yy, zz combination must be unique for each traffic stream (which in UL I read as being equivalent to URI) is consistent with this latter interpretation. And I think the points Mike has been making are consistent
with that view as well.
From all this, I think the intention is that values of xx, yy and zz should reflect the traffic stream, which in the UL case corresponds to the URI. As Mike suggests, those values can be configured in a manner similar to the assignment of SSIDs. That would
make it the responsibility of the overall administrator to ensure that the non-AP MLDs are provided with unique values of xx, yy, and zz for each URI.
Does that make sense?
John
From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> on behalf of ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Wednesday, August 31, 2022 2:49 AM
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBC] [EXTERNAL] Re: [STDS-802-11-TGBC] CID 4032 - Discussion
Mike, sorry, by EPCS you mean EBCS right?
Another thing, would make sense to define xx-yy-zz based on the own MAC address of the device, just as an example, maybe a mix of bits of it (to avoid getting only bits belonging to the manufacturer part).
Br
Antonio
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
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
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
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
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
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
--
--
Antonio de la Oliva
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
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
|