| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Yongho,Thanks for your comment. If it works for you and others, I'll address 11071 separately to deal with 320 MHz channels and construct a resolution based on Po-Kai's proposed way forward.Cheers,MikeOn Fri, Oct 7, 2022 at 1:51 PM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:Hi Mike,Regarding CID 11071, this part is for 320 MHz OCI discussion different with the multi-link OCI.In 320 MHz BSS operation, the Operating Class field and the Primary Channel Number field in the OCI element can only support identifying the primary 160MHz channel.This is happened because 320 MHz follows overlapping channelization.Before 320 MHz, 80 MHz 160 MHz channelization followed non-overlapping channelization. So, the Operating Class field and the Primary Channel Number field were sufficient enough to identify the BSS operating channels. (Please remind that, to identify secondary 80 MHz in 80+80 MHz BSS, the OCI element has the Frequency Segment 1 Channel Number field which is set to the channel center frequency index of the secondary segment.In consequence, the missing part in 11be is how to identify the secondary 160 MHz channel in 320 MHz operating channel.So, I think that the following comment from Po-kai may work."Frequency Segment 1 Channel Number" to simply "Channel center frequeny of 320 MHz", which is set to channel center frequency of 320 MHz when 320 MHz is used and 0 otherwise.Thanks,Yongho2022년 10월 7일 (금) 오전 8:22, M Montemurro <montemurro.michael@xxxxxxxxx>님이 작성:Hello all,I took a second look at the following comments on OCVC, which were deferred (see bottom if email)The purpose of OCVC was to verify that an ongoing exchange was taking place on the channel that both parties believed to be the same. Given that for MLO, the exchanges take place on the same link, existing OCVC procedures will work as specified in the baseline. There is no need to include link ID information in the OCI KDE.Furthermore, the requested links provided in the reassociation request, and the links advertised links included beacons and probe responses are both validated as part of the 4-way handshake.I'm inclined to reject these CIDs unless somebody can provide some explanation on what the problem is and why providing operating channel information for links addresses the issue.Thanks,MikeComment
CID
Clause
Page
Line
Comment
Proposed Change
11071
12.7.6.1
355
45
The description implies that OCI KDE can be used for MLO. However, OCI KDE needs to be redesigned to include link ID and information for 320 MHz verification because 320 MHz may have 320 MHz-1 or 320 MHz-2.
Define MLO OCI KDE. Ideally, follow the format of OCI KDE to include link ID and change "Frequency Segment 1
Channel Number" to simply "Channel center frequeny of 320 MHz", which is set to channel center frequency of 320 MHz when 320 MHz is used and 0 otherwise.10678
12.7.6.3
358
46
For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg 2 for the AP MLD to verify the operating channels of the STAs corresponding to the requested links
As in the comment
10679
12.7.6.4
361
11
For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg 3 for the non-AP MLD to verify the operating channels of the APs corresponding to the requested links
As in the comment
14100
12.7.2
351
5
OCI KDE should have a corresponding MLO KDE defined because RNR in ML probe response is not protected
As in comment
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