Hi Thomas,
Thank you very much for your valuable comments. I will consider regarding your comments and reflect on my following contribution. The following are
my quick responses in line.
-
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)?
My intention is (b). I intended for the ANT(Access Network Type) value to indicate the purpose of use for the network. In other words, if the BSS
indicates a "Latency-sensitive network" by the ANT, the BSS should be used for STAs that utilize latency-sensitive service(s) mainly. Of course, it may give them some latency-sensitive access features. Note that indicating "Latency-sensitive network" does
not mean the network is not always optimized for latency-sensitive service(s). Then, not (a).
-
If (b), then does it imply the latency-sensitive service cannot be accessed on other networks?
There is room for discussion on whether latency-sensitive services should not be allowed to use other networks except latency-sensitive networks.
In like manner, it should be discussed further that non-latency-sensitive services should not be allowed to use the latency-sensitive network.
I think the indication should not be compelling but guidance. Then, the usage of the ANT value should be left for implementation or as a preferable
option. However, I understand it should have corresponding benefits when selecting a latency- or non-latency-sensitive network.
-
Suggest to clarify how a STA might be expected to use the advertised information - presumably as part of network (or possibly BSS/MLD) selection
Thank you for the comment. As you mentioned, I think it can be used for network selection. I will consider and clarify the usage of the information
in the following contribution and after that.
-
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?
As I mentioned above, I think this indication should be guidance, and STA might still choose to use another network.
-
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
Thank you for your suggestion. I will investigate and consider using Service Hint and Service Hash in addition to 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.
I assume these two types of APs (target BSS and OBSS) are not always in the same network or management domain. I agree that other elements can help
decide whether the OBSS AP takes channel selection or another function I proposed. Therefore, I think this indication should not be forcing actions but recommendations. However, I understand that this feature should provide a particular motivation to use.
I will consider and clarify. Thank you.
Best regards,
Akira
From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: Tuesday, July 2, 2024 5:13 AM
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)
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.
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
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
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.
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
|