1 / 3

Response to the IEEE Inquiry

Response to the IEEE Inquiry. Adrian Stevens – Mobilian Mitch Buchman – Department of Defense Harry Worstell – AT&T. Dear sir/madam,

duff
Download Presentation

Response to the IEEE Inquiry

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Response to the IEEE Inquiry Adrian Stevens – Mobilian Mitch Buchman – Department of Defense Harry Worstell – AT&T Adrian Stevens, Mitch Buchman

  2. Dear sir/madam, I have studied the IEEE 802.11 Standard (only the MAC, not Physical Layer) for a few months and I found a lot of errors or information that might be omitted. I think that I corrected some of these errors, but not all of them. For example, in Reception Block, in Rx_Coordination process, in No_BSS state when RxIndicate is received, frame type is verified. Thus, only Beacon and Probe Response frames are passed. In my opinion, this verification is not necessary because in Defragment process also made the same verification and if the station is not in any BSS the Defragment process will be in Defrag_Inactive state. In this state the received frame type is also verified, and frames other than Beacon and Probe Response are not passed, so the message RxIndicate will not appear.Another mistake is that in Rx_Coordination process the ATIM and Probe Response frames are passed to LLC, not for Management (using Msdu_Indicate(pdu), instead Mm_Indicate(pdu)). On the other hand, I don't understand why ATIM and Probe Response frames are verified by the group address. This case will never appear. According to this logic, Beacon frames must be verified to have a group address. Thank you for your patience and I'm waiting for your response. Radu Mihaescu Redline Communications Romania radu@redlinecommunications.ro Adrian Stevens, Mitch Buchman

  3. Response to the Inquiry • It is agreed that filtering of received MPDUs for Beacon and Probe responses when not in a BSS within Process Defragment and Process Rx-Coordination is redundant.  It does no harm, so it can be considered a benign error. Process Rx_Coordination has the following errors on page rx_coord_2b(4) of ANNEX C: 1. Group address filtering for ATIM MPDUs is incorrect.  ATIMs may validly be sent to a group address for the transmission of MSDUs to group addresses as a result of the IBSS power-saving protocol. • 2. Received beacons, probe requests, authentication, deauthentication, ATIM and probe response are wrongly sent to the RSDU gate (i.e. eventually to the LLC) using the MsduIndicate signal. They should instead be sent from this process to the MCTL gate using the MmIndicate signal. • Note that received MPDUs are validly filtered to exclude probe responses with group destination address because there is no use defined in the other clauses of the 802.11 standard for such a packet. Adrian Stevens, Mitch Buchman

More Related