| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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:
Thanks, Laurent
From: Namyeong Kim <namyeong.kim@xxxxxxx>
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
From: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
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,
From: Namyeong Kim <namyeong.kim@xxxxxxx>
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 E-mail: namyeong.kim@lge.com
| Mobile: +82-10-7377-3624 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 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 |