Re: [STDS-802-11-TGBN] Regarding the SP in 24/0837 (Indication of Use Case in 11bn)

[Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>]

Hi Kishida-san

Thanks for your work on this. A couple of comments which perhaps you may take into account in your follow-up contribution:

• Suggest to clarify between a latency-sensitive network vs service. Specifically, is the ANT value intended to signify (a) the network is somehow optimized for latency-sensitive traffic, or (b) the network provides access to some latency-sensitive service(s)?
• If (a), then is it possible to define what makes this network different from some other network that does not advertise this ANT value (e.g. what the optimizations are)?
• If (b), then does it imply the latency-sensitive service cannot be accessed on other networks?

• Suggest to clarify how a STA might be expected to use the advertised information - presumably as part of network (or possibly BSS/MLD) selection
• If (a), then when the STA is trying to access some latency-sensitive service, presumably it might prefer accessing it using a network that advertises this ANT value, vs another network that does not advertise this ANT value... but that might also depend on other link quality metrics (e.g. RSSI, BSS Load), and other factors (e.g. charging, user preference) the STA is aware of
• If (b), then if this is the only network the service is available from, then the STA may have no choice but to use that network?

• If (a), then is it expected APs in the same network might dynamically change this ANT value based on whether the network has sufficient capacity/resources (fronthaul and backhaul) to handle latency-sensitive traffic, or is this expected to be a semi-static indication?

• If (b). i.e. the intention is to advertise specific services that are available on the network (which might happen to be latency-sensitive), and there may be various such services that need separate indications, then the Service Hint and Service Hash (PAD) might be more appropriate than ANT

• Regarding your channel selection scenario (where one potential OBSS AP decides to use a different channel to avoid interfering with an AP advertising this ANT value), are you assuming those two APs are part of the same network or management domain? If not, it may be necessary to consider whether sufficient motivation exists for the OBSS AP to take this action, particularly based on an unauthenticated indication. Also there are other features such as Channel Usage element which seem somewhat related to that use case.

Thanks

Thomas

On Jun 25, 2024 at 5:35:21 PM, Akira Kishida <0000225315dd7287-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hello all,

The SP of my contribution (24/0837) was cast and discussed in the last TGbn JOINT session.

https://mentor.ieee.org/802.11/dcn/24/11-24-0837-03-00bn-indication-of-use-case-in-11bn.pptx

 

As a result of the SP, I understood that more information was needed to get my proposal. Then, I will provide more detailed explanations in the next follow-up contribution, and I would like to continue the discussion on this topic.  

In this thread, I respond to the comments I received in the chat prior to the following contribution.

 

Is it not “reserved bits” but “reserved value” in the SP text?

Yes. Access Network Type in the Access Network Options field in the Interworking element has 4 bits to indicate the access network type. Values 6 to 13 are reserved for future use in the access network type. I intended to use these values for the UHR. Then, the _expression_ of “values” is correct.

How many UHR use cases do we have?

Though this is a further discussion, we should have the access network type of “Latency sensitive network” at least.

Some specific examples of this feature adding to 11bn may be helpful.

The Access Network Type and Description are indicated in Table 9-236 in IEEE 802.11-2020. Values 6 to 13 of the Access network type are reserved for future use. I intend to use these values. For instance, we can define value 6 as a “Latency sensitive network.” Then, STAs can know that the BSS, which broadcasts this Interworking element, operates latency sensitive services or applications before being associated with it. The STA can use another BSS if the STA is a typical smartphone and mainly uses internet traffic. The STA can also associate with the BSS, which is indicated as a “Latency sensitive network,” if the STA is AGV or AMR used in industrial automation.

I will bring another follow-up contribution regarding this topic and the detailed operation that I intended.

Propose to change the SP text "to use reserved bits " to "use one or more reserved..." so it does not mean we are deciding to use all the values.

I agree with the commenter. The number of values used for the UHR is a further discussion item and should be a minimum set. I will change the SP text when I cast the SP in the next chance.

What fields have been changed in this proposal, and how many are they?

As I described above, I don’t intend adding new fields to the Interworking element but using reserved values in the Access Network Type field in the Access Network Options field in the element so far.

Any comments and discussions are welcome.

Thanks, and kind regards,

Akira

 

 

From: Akira Kishida（岸田朗） <akira.kishida@xxxxxxx>
Sent: Thursday, June 20, 2024 4:56 PM
To: Stephen McCann <mccann.stephen@xxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Akira Kishida（岸田朗） <akira.kishida@xxxxxxx>
Subject: RE: [STDS-802-11-TGBN] Regarding the SP in 24/0837 (Indication of Use Case in 11bn)

 

Hi Stephen,

 

Thank you very much for your feedback. I appreciate your valuable comments. Following are my responses in line.

 

1) I do not think the term "use case" is suitable for 11bn. It is a very generic term and I am concerned that it will be misunderstood. I think a simple extension to the existing Access Network Options field (see slide 10) is the easiest way forward for your work. Use some of the reserved values (6-13) in Table 9-236 and I think that is all you have to do.

 

I agree with your comments and thoughts. The term "Use Case" I intended was explained in my previous mail, but the generic term may be misunderstood, as you mentioned. Moreover, Extending the existing Access Network Options field is the best way for my intention.

 

2) A better straw poll would be:

"Do you agree to extending the Access Network Options field in 11bn?"

 

Thank you for your suggestion. I modified the SP text to follow the discussions.

 

"Do you agree to extending the Access Network Options field in 11bn?

Note: This intends to use reserved bits (6-13) in the Access Network Options to indicate the UHR use cases (TBD)."

https://mentor.ieee.org/802.11/dcn/24/11-24-0837-01-00bn-indication-of-use-case-in-11bn.pptx

 

3) The original intention of the Interworking element is to provide an indication to the non-AP STA about the type of network to which the AP is attached. It is only to be treated as best effort information and cannot be relied upon. If a more reliable indication is required, the non-AP STA needs to associate to an AP and then determine the true characteristics of the network.

 

Thank you for your comment. The indication of the 11bn use case that I intended initially is similar to the Interworking element. I would like to notify network types that will be important for the UHR, such as "Latency Sensitive Network." This will be some "guidance," but not for any "trigger" to force some features because this will be best-effort information, as you mentioned.

 

Best regards,

Akira

 

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Wednesday, June 19, 2024 5:36 PM
To: Akira Kishida（岸田朗） <akira.kishida@xxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Regarding the SP in 24/0837 (Indication of Use Case in 11bn)

 

Akira,

          I like your concept and thank you for creating the submission.

 

I have some feedback for you:

1) I do not think the term "use case" is suitable for 11bn. It is a very generic term and I am concerned that it will be misunderstood. I think a simple extension to the existing Access Network Options field (see slide 10) is the easiest way forward for your work. Use some of the reserved values (6-13) in Table 9-236 and I think that is all you have to do.

 

2) A better straw poll would be:

"Do you agree to extending the Access Network Options field in 11bn?"

 

3) The original intention of the Interworking element is to provide an indication to the non-AP STA about the type of network to which the AP is attached. It is only to be treated as best effort information and cannot be relied upon. If a more reliable indication is required, the non-AP STA needs to associate to an AP and then determine the true characteristics of the network.

 

Kind regards

 

Stephen

 

On Wed, 19 Jun 2024 at 03:49, Akira Kishida <0000225315dd7287-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hello all,

 

My SP (24/0837) will run this Thursday's TGbn Joint call (June 20). Before casting the SP, I would like to answer members' questions. Thanks, Necati, Gaius, and Rakesh, for your comments!

 

The SP text is;

Do you agree that indicating the use case is beneficial in 11bn?

-Yes/No/Abs

https://mentor.ieee.org/802.11/dcn/24/11-24-0837-00-00bn-indication-of-use-case-in-11bn.pptx

 

1)What is the "Use Case" indicated in this contribution?

I intend the term "Use Case" to stand for the characteristics of the network to which the AP that indicates this information belongs. For example, the type of access network, such as private or public networks, or the venue information defined in the Access Network Options field and Venue Info field in the Interworking element are suitable for "Use Case" information. Please see the APPENDIX in my contribution.

Moreover, I think we can newly define and indicate the network type of "Latency Sensitive Network" or applications such as "XR/VR" or "assembly line in IIoT" as for "Use Case."

 

2)Is any normative behavior with the use case indication expected?

I haven't expected any normative behavior so far because I think using this information will be left to implementation or vendor-specific (it may not be defined in 11bn). However, this information will be helpful for Wi-Fi reliability. For instance, if the BSS's use case is a latency-sensitive network, the other BSSs can avoid using the channels or links that the BSS utilizes. 

 

3) What kind of indication and granularity is expected?

Those are future discussion items, but I expect that we can indicate the kind of information shown in the Access Network Options field and Venue Info field in the Interworking element defined in 11u. This element's granularity of information may be reasonable. However, the information defined in 11u was outdated, and we could update or redefine it for the UHR.

 

4)Will there be a dictionary of use cases and their index?

If we reuse the Interworking element, there are a lot of Venue type and their index (please see Table 9-66 in P802.11-2020), and we can reuse it. There are still a lot of non-defined indexes.

 

Any comments are welcome.

 

Best regards,

Akira

 

 

==========================================

Akira KISHIDA, Ph.D.

NIPPON TELEGRAPH AND TELEPHONE CORPORATION (NTT)

NTT Access Network Service Systems Laboratories

Tel: +81-46-859-2093 Fax :+81-46-859-3145

E-mail: akira.kishida@xxxxxxx

(Changed from akira.kishida.fs@xxxxxxxxxxxxx)

 

 

---

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

---

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

---

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature