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

Re: [STDS-802-11-TGBC] FW: Recap, for comments, on TGbc architecture

Hi Mark,

 

Thanks for the email of summary and questions. I have included my thoughts inline below in blue.

 

To align everyone’s understanding of EBCS related topics, my understanding is that 11bc is targeting a situation where there are many more potential EBCS traffic streams that are advertised by an AP, than the number of EBCS traffic streams that are actually broadcast by the AP. Therefore in order for the APs to know which EBCS streams to transmit, some degrees of control by requesting STAs need to be provided (Provided that these EBCS traffic streams are clearly advertised by the AP). Therefore, there needs to be different classes of requesting STAs (unassociated or associated and associated STAs with privileges).

 

Best regards,

 

Xiaofei Clement Wang

Principal Engineer | InterDigital

T: (631) 622.4028

E:  Xiaofei.wang@xxxxxxxxxxxxxxxx

 

From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of Mark Hamilton
Sent: Tuesday, June 1, 2021 13:38
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] FW: Recap, for comments, on TGbc architecture

 

I should have copied the ARC reflector on this, too.  (Sorry for the duplication, those of you on the TGbc reflector!)

 

Mark

 

From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, June 1, 2021 11:24 AM
To: stds-802-11-tgbc@xxxxxxxxxxxxxxxxx
Subject: Recap, for comments, on TGbc architecture

 

All,

 

To try to recap what I think were comments from today’s TGbc call, and to get discussion/feedback going, here is what I had in mind.  Comments/flames/etc. are encouraged!

 

  1. Broadcast/Multicast streams that require association (for security reasons, or ???)
    1. Can anyone list other reasons for these streams, for the “???” above?
    2. Is there any reason these are not handled by existing 802.11, 802.1Q and IGMP features?  (This includes security requirements, discovery requirements, power saving requirements, etc.)
    3. If this is handled by legacy standards already in existence, does some prior agreement in TGbc need to be revisited, to stop talking about this?  Alternatively, if something is not handled by legacy standards already in existence, can we be more specific about what new feature/behavior TGbc is adding, so we talk about it specifically?

As we discussed during yesterday’s teleconferences, there seems to be three types of EBCS traffic streams:

        1. EBCS traffic that can be requested and consumed by any STA (think of train schedules at a train STAs, gate change information at an airport, etc.) regardless of their association status
        2. EBCS traffic that can only be requested by associated (hence authorized) STAs, but can be consumed by any STA (the example given during the yesterday’s teleconference, a teacher authorized to start a broadcast service for slides for all students). I understand that for this category, there may be some disagreement.
        3. EBCS traffic that can only be requested by associated (hence authorized) STAs, and may require association to consume (such as two level of broadcast at emergence response events, one level of public broadcast for general public, and one level stream for law enforcement which may require association for the STAs to consume)

In my mind, to provide EBCS services, it is not just about transmitting the data. There are additional steps such as advertising the EBCS services, as well as controlling the EBCS service (request/response to start or stop the EBCS service being broadcasted at the local AP.

 

I believe that data transmission of all EBCS DL traffic, independent of category, can use legacy AP architecture to transmit. But there is an additional filter there somewhere to turn on/off streams.

 

For the EBCS traffic of category 3, the advertisement and controlling of the EBCS services are missing from the legacy spec and therefore these are defined in 11bc D1.0. Hence, advertisement by the AP and the ability for an associated STA to control which multicast/broadcast are broadcast are within scope of TGbc. So the statement “In my understanding, the association required multicast/broadcast is out of scope of TGbc.” seems incorrect. Actually, the TGbc scope should include advertisement and controlling mechanisms for all categories of EBCS traffic.

 

I am a little pressed to understand why the current architecture cannot support all these EBCS services, which may need an additional filtering functionality .

 

  1. Discovery for eBCS-capable STAs
    1. An eBCS-capable/enabled “AP” (I’ll call this an eBCS AP from now on, but we might want a different term) sends Beacons (but not necessarily 802.11 Beacons!) indicating its capability, and (optionally?) particular broadcast services that are available.  (Assuming this looks generally like an 802.11 Beacon, it should probably include a BSS Membership Selector for eBCS, to prevent Legacy STAs from becoming confused.)
    2. An eBCS STA can request (with a public action frame) to “enable” a broadcast service that is known (believed?) to be available at the eBCS AP, and is not currently being broadcast.
    3. An eBCS STA can be co-located with a Legacy 802.11 STA.  The 802.11 STA can be associated or unassociated, without any effect on eBCS behavior.
    4. Note that “associated” or “unassociated” is not a concept in the context of eBCS.

As the current spec text in 11bc, “associated” or “unassociated” is a concept in the context of EBCS. Certain EBCS streams broadcast by an AP can be started by unassociated STAs, while other EBCS streams broadcast by an AP can only be started by associated STAs, this is to provide for support for security, or features, e.g., premium level streaming, authorized users (such as a teacher), etc.

 

EBCS AP has limited indication in its beacons and a public action frame “EBCS Info frame” is used to advertise the services and provide origin authentication. One of the indication in the advertised EBCS services is that whether a STA needs to be associated to request that EBCS service.

 

  1. What is an eBCS “AP”?
    1. An eBCS “AP” might be, or might not be, co-located with a Legacy 802.11 AP
    2. An eBCS AP Beacons information useful/necessary for eBCS operation (only?  How far do we go in the 802.11bc spec to describe what is/isn’t in an eBCS Beacon?)  If the eBCS AP happens to be co-located with a Legacy 802.11 AP, do we somehow “merge” the Beacons (Multiple BSSID, or something similar?) on the assumption that any eBCS STA will be able to understand any new construction we create?
    3. There is no DS.  (Without association or any concept of “location” there is no purpose for the DS.)  eBCS APs are directly bridged to a non-802.11 network (optionally, of course, but they would be of limited value if no non-802.11 network is present, so it is almost always a good assumption). 
    4. Mapping of IP-layer information (src IP, dst IP, [port], etc.) is a higher-layer function.  This higher layer’s configuration is where streams are classified as “requires association” or not.  Routing/bridging to Legacy AP or eBCS AP happens at this layer (much like VLANs).  I think this is the eBCS Proxy we mentioned (?) – and it is a function we can require in 802.11bc, but would be implemented in a higher layer (that understands IP frames).  At the 802.11 SAP for the TGbc case, it would specified that the SAP assumes all MA-UNITDATA.request primitives would already be “filtered” and only MSDUs appropriate for eBCS transmission would be delivered to that primitive.  (Note, a similar concept applies on the non-AP STA, as well.)

We need a DS because we need to have association STAs for controlling some of the EBCS streams, and the content is provided by servers outside of the portal and needs to be distributed to the EBCS APs.

 

While the content is provided by the higher layers, the choice of which EBCS streams are broadcast by the AP is controlled by the AP and the STAs served by the AP (associated or unassociated).

 

  1. Stream start/stop
    1. When a broadcast stream is started (or defined/identified – which might be ahead of time and more-or-less permanent, or it might be dynamic and ad hoc), the eBCS APs that will support that stream are managed “via an external management entity” to enable that stream. 
    2. Alternatively, eBCS APs can be enabled to handle any/all streams, without further external control.
    3. I suspect this stuff makes the most sense to be in the MIB, as part of a eBCS AP “configuration”.
    4. Actual start/stop of stream traffic is beyond the scope of 802.11, as the stream can come from anywhere.

I agree. I believe that the current version of 11bc, we are only dealing with enabling the AP to start/stop broadcasting EBCS traffic at its local level, not the start of stop of the traffic stream that may be coming from a server.

Comments?  Arguments?  What did I forget to include (as well as what do you think I got wrong)?

 

Mark

 

 

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