| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Antonio,thanks for the explanation and apologies for my slow response.The draft currently states "The Enhanced Broadcast Service ANQP-element advertises available EBCSs from the STA transmitting this element". I think this is fine. The resolution you provide below for CID 1012, adapts this to say " The Enhanced Broadcast Service ANQP-element advertises available EBCSs from the AP transmitting this element or received EBCSs from the non-AP transmitting this element". However, I think this only works for the DL situation. For the UL situation, you would want the Enhanced Broadcast Service ANQP-element to do the reverse. However, for an AP with both UL and DL traffic this could be confusing.So, I think there are 2 ways forward:1) Separate the advertisement of transmit EBCSs and receive EBCSs into two separate ANQP-elements.2) Insert a flag (e.g. single bit) into a new Enhanced Broadcast Service Request ANQP-element to provide an indication of whether this is a uplink or downlink query.I prefer option 1), as it's a cleaner simpler solution. Introducing a flag into an ANQP-element request (option 2)) means the request is for different functionality.Regarding the optimisation of APs (in the same ESS?) transmitting the same EBCSs, I think that's ok.Kind regardsStephenOn Fri, 29 Jan 2021 at 16:01, ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx> wrote:Dear Stephen, thanks a lot for the resolutions, quite a lot of work!regarding CID 1013, which I copy hereComments on TGax D0.1When I introduced this element I was thinking on a multi-AP setup, where multiple APs are serving for example eBCS1 and eBCS2. Through the ANQP element, the APs can query the STAs to provide the list of services they are receiving and from which AP. In this case, a e.g., central controller, can optimise the broadcasting of services, maybe not transmitting one of them or aggregating the service in just one AP. Basically, it is opening the door to optimization procedures.
The intention of the 'Broadcaster MAC Address' field is not clear. When would the broadcast MAC address be different from that of a transmitting AP? Is it possible that a non-eBCS AP advertises the broadcast services provided by another (eBCS) AP in the neighborhood? Please clarify This CID is related to CID1012, which I have tried to address in my resolution, as reads:8 When an ANQP request containing the Enhanced Broadcast Service ANQP-element is received by an AP, the corresponding Enhanced Broadcast Service ANQP-element in the ANQP response contains the list of EBCS [streams] being transmitted by the AP. When an ANQP request containing the Enhanced Broadcast Service ANQP-element is received by a non-AP STA, the services included in the ANQP response contains the list of EBCS [streams] being received by the STA. [CID1012]Hope this helps triggering the discussion.BrAntonioEl vie, 29 ene 2021 a las 14:49, Stephen McCann (<mccann.stephen@xxxxxxxxx>) escribió:Dear all,I've proposed some comment resolutions for LB252 within this spreadsheet:<https://mentor.ieee.org/802.11/dcn/21/11-21-0085-03-00bc-comment-resolutions-for-lb252.xlsx>. This was originally a tab within Marc's master spreadsheet and so it should be easy to re-insert.I've also produced a corresponding word document with all the proposed changes from the spreadsheet:There are several comments which will require TGbc discussion.Kind regardsStephen
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