Hi,
First, there are quite a bit of overlap between my doc 1651 which is resolving the TBDs in D0.1 and your doc who focuses on the design of partial feedback.
Let’s discuss so that we resolve these overlaps. Maybe one way is to separate the scope of the 2 docs and that yours really only focuses on the partial feedback.
On the decisions we have to make:
- We first need to decide what is the container to specify the links for which the feedback is provided. I cover the 2 options I hears so far in my doc: using ML IE or defining a new IE. We can start with making that decision. If you don’t mind, I can handle that when we review my doc.
- Once that is defined, we can then enter the discussion about signaling for partial information in your doc and the different options (new signaling, reusing request element, …). But maybe before that it could be helpful to see what are the real use case for partial feedback so that we design the mechanism the right way. We can be tempted, as Abhi is suggesting, to be completely flexible and be able to request any partial request for any link differently, or we can limit the scope to what we think would be useful without complexifying the whole mechanism. Maybe we could have a few SPs to sense the group on the scope of how we’ll use this partial request, so that we design cleverly for it, as so far, the motion that we passed is very vague on that.
Thanks,
Laurent
Hi, Abhishek.
Thanks for your comments.
I am aware of the issue you concerned about and I agree that it is a good direction to define as the STA requests different information per link for flexibility.
I provided a new format simply to reduce default field overhead (e.g. element ID, subelement ID, length, etc.) in the initial version, but I think we can extend it by considering per link different information.
I’d like to know your opinion for defining the new MLD request element if the issue of different information per link can be resolved.
In addition, using ML IE can be also taken into account so I am working on various options that consider several scenarios, including the one you mentioned, and I plan to update the document.
I would like to make a flexible and optimized design for information request. Hope to keep discussion to find a good solution.
Best,
Namyeong
Hi Namyeong,
Thank you for preparing the PDT on this topic.
The (new) MLD Request element, that you proposed, would make the design inflexible – i.e., the information requested will be the same for all the requested links.
For example, what if the non-AP MLD desires to request complete information for link x and partial for link y. The proposed IE will force the AP MLD to provide complete information for all links.
Further when requesting partial information for link x and link y, there can be scenarios where you want certain elements p, q, & r for link x and a different set (e.g., a, b, & c) of IEs for link y.
I propose using ML IE. It already provides the necessary structure (in terms of signaling link ID, number of links requested etc).
In addition, baseline spec has defined Request element and Extended Request element. We can reuse these along with the ML IE to request specific information for a certain link.
For the examples above, if non-AP MLD wishes to have complete information for link x (link ID=1) and partial for link y (link id =2), then the per-STA profile of ML IE will carry two subelements.
Subelement corresponding to Link ID=1 without Request element or Extended Request element. The Per-STA Control field can have a bit to indicate the non-AP MLD is requesting complete profile for this link.
Another subelement corresponding to Link ID=2 will carry Request element and/or Extended Request element carrying a list of requested element IDs.
Regards,
Abhi
CAUTION: This email originated from outside of the organization.
Dear, all TTT members for ML Discovery – Information request
I uploaded an initial version of proposed text for ML Discovery – Information request on server.
This proposal includes a spec text to define a request of information for MLD probing.
Please let me know if you have any comments or questions.
Thanks.
Best,
Namyeong.
김나명 | Namyeong Kim
Research Engineer | IoT Connectivity Standard Task | C&M Standard Lab. of CTO Future Technology Center | LG Electronics
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1