Skip this Video
Download Presentation
Response to the IEEE Inquiry

Loading in 2 Seconds...

play fullscreen
1 / 3

Response to the IEEE Inquiry - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Response to the IEEE Inquiry' - duff

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Response to the IEEE Inquiry

Adrian Stevens – Mobilian

Mitch Buchman – Department of Defense

Harry Worstell – AT&T

Adrian Stevens, Mitch Buchman

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

[email protected]

Adrian Stevens, Mitch Buchman

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