| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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> 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>
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:
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 |