<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE article  PUBLIC "-//NLM//DTD Journal Publishing DTD v3.0 20080202//EN" "http://dtd.nlm.nih.gov/publishing/3.0/journalpublishing3.dtd"><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" dtd-version="3.0" xml:lang="en" article-type="research article"><front><journal-meta><journal-id journal-id-type="publisher-id">IJCNS</journal-id><journal-title-group><journal-title>International Journal of Communications, Network and System Sciences</journal-title></journal-title-group><issn pub-type="epub">1913-3715</issn><publisher><publisher-name>Scientific Research Publishing</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="doi">10.4236/ijcns.2017.105B005</article-id><article-id pub-id-type="publisher-id">IJCNS-76532</article-id><article-categories><subj-group subj-group-type="heading"><subject>Articles</subject></subj-group><subj-group subj-group-type="Discipline-v2"><subject>Computer Science&amp;Communications</subject></subj-group></article-categories><title-group><article-title>
 
 
  MAC Frame Resolution and PHY Protocol Type Detection of IEEE 802.11
 
</article-title></title-group><contrib-group><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Ling</surname><given-names>Li</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Shi</surname><given-names>Peng</given-names></name><xref ref-type="aff" rid="aff1"><sup>1</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>June</surname><given-names>Li</given-names></name><xref ref-type="aff" rid="aff2"><sup>2</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Kai</surname><given-names>Yuan</given-names></name><xref ref-type="aff" rid="aff3"><sup>3</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Zhihao</surname><given-names>Wang</given-names></name><xref ref-type="aff" rid="aff3"><sup>3</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Yinbin</surname><given-names>Liu</given-names></name><xref ref-type="aff" rid="aff3"><sup>3</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Ping</surname><given-names>Chen</given-names></name><xref ref-type="aff" rid="aff3"><sup>3</sup></xref></contrib><contrib contrib-type="author" xlink:type="simple"><name name-style="western"><surname>Xianbing</surname><given-names>Wang</given-names></name><xref ref-type="aff" rid="aff3"><sup>3</sup></xref></contrib></contrib-group><aff id="aff1"><addr-line>China Electric Power Research Institute, Beijing, China</addr-line></aff><aff id="aff3"><addr-line>Wuhan University, Wuhan, China</addr-line></aff><aff id="aff2"><addr-line>Key Laboratory of Aerospace Information Security and Trusted Computing of Ministry of Education, Wuhan, China</addr-line></aff><pub-date pub-type="epub"><day>26</day><month>05</month><year>2017</year></pub-date><volume>10</volume><issue>05</issue><fpage>43</fpage><lpage>53</lpage><history><date date-type="received"><day>March</day>	<month>6,</month>	<year>2017</year></date><date date-type="rev-recd"><day>Accepted:</day>	<month>May</month>	<year>23,</year>	</date><date date-type="accepted"><day>May</day>	<month>26,</month>	<year>2017</year></date></history><permissions><copyright-statement>&#169; Copyright  2014 by authors and Scientific Research Publishing Inc. </copyright-statement><copyright-year>2014</copyright-year><license><license-p>This work is licensed under the Creative Commons Attribution International License (CC BY). http://creativecommons.org/licenses/by/4.0/</license-p></license></permissions><abstract><p>
 
 
   
   Frame resolution and physical layer (PHY) protocol type detection are the basis of research and development of intrusion prevention systems for IEEE 802.11 wireless network. Aiming at the problems which cannot be solved by the specifications export, this paper proposed a MAC frame analytical method and a PHY protocol type detection algorithm based on parsing the IEEE 802.11packets captured by the library Libpcap. The packet structure and the length of the frame preamble (18 or 26 bytes) are presented. Then the methods of transforming byte-order and resolving sub-fields are given. A detection algorithm of PHY protocol type is proposed based on the experiments and examples are given to verify these methods. This work can be a reference for the R &amp; D related to link layer frame analysis. 
  
 
</p></abstract><kwd-group><kwd>IEEE 802.11</kwd><kwd> MAC Frame</kwd><kwd> Resolution</kwd><kwd> PHY Protocols</kwd><kwd> Detection</kwd></kwd-group></article-meta></front><body><sec id="s1"><title>1. Introduction</title><p>IEEE 802.11 Wireless LAN (WLAN) plays an important role in personal Internet access as well as industrial applications [<xref ref-type="bibr" rid="scirp.76532-ref1">1</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref2">2</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref3">3</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref4">4</xref>], because of its convenient deployment, lower cost and mobility. Compared to the wired network, WLAN is more vulnerable [<xref ref-type="bibr" rid="scirp.76532-ref5">5</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref6">6</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref7">7</xref>]. It is very easy to capture and analyze the transmitting message, because the medium of WLAN is shared. Therefore, it is particularly important to research the security technologies for WLAN.</p><p>The research on the technology for WLAN security mostly focused on intrusion detection systems [<xref ref-type="bibr" rid="scirp.76532-ref6">6</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref7">7</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref8">8</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref9">9</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref10">10</xref>] in the past, but is still at an initial stage. Mature commercial products are also inadequate.</p><p>Real-time monitoring and analysis of the WLAN environment is an effective way to find potential risks, such as vulnerabilities, suspicious devices or behavior. At a WLAN-forbidden location, unauthorized APs and STAs can be detected by the real-time monitoring system to avoid an exposure of the private network.</p><p>Capturing and resolving the MAC frames are the technical basis of a real-time monitoring and analysis system, vulnerability scanning system and intrusion detection system for WLAN [<xref ref-type="bibr" rid="scirp.76532-ref6">6</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref7">7</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref8">8</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref9">9</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref10">10</xref>]. IEEE 802.11 MAC frames are categorized into three types: control frames, management frames, and data frames. Control frames and management frames contain a lot of useful information and are transmitted in plain text. Although the body of data frame is encrypted when a security measure is enabled, the frame header is still in plaintext. Therefore, we can parse the captured MAC frames to get the information and use the appropriate detection algorithm to identify the potential risks in a WLAN.</p><p>However, there are some practical problems, for which no literature presents solutions about frame capture and analysis. For example, the length of frame preamble is not the same when different STAs capture MAC frames from a same AP or STA. There are bytes and bits order converting problems when analyzing the captured data. The research of packet capture and analysis focused on the PDU (protocol data unit) encapsulated in TCP or UDP rather than that in link layer frame in the past.</p><p>Detection of PHY protocol types is basic content of the WLAN environment analysis and further development. Network managers can analyze the behaviors of APs or STAs on the basis of their real-time PHY protocol type and other information to identify suspicious devices in a WLAN.</p><p>However, the specification of some information elements in the standard is not detailed enough, so the detection algorithm of PHY protocol types cannot be designed based on the standard. And, no literature proposes the detection algorithm.</p><p>Aiming at the problems above, this paper proposes a MAC frame resolution method and a PHY protocol type detection algorithm of IEEE 802.11, on the basis of a large number of experiments for frame capturing and analyzing. The packet capturing is based on the library of Linux Libpcap.</p></sec><sec id="s2"><title>2. Method of MAC Frame Resolution</title><sec id="s2_1"><title>2.1. Structure of Captured Data and Length of Frame Preamble</title><p>The length of frame preamble is not the same when different STAs capture MAC frames from a same AP or STA. The captured data are represented by the structure shown in <xref ref-type="fig" rid="fig1">Figure 1</xref>. The MAC frame consists of a header, a body and the FCS. The frame preamble is related to network interface card.</p><p>There are two kinds of length of the frame preamble. One is 26 bytes and the other is 18 bytes. The length can be calculated from the value of third byte of the captured data. An example of the captured binary data of a beacon frame is shown in <xref ref-type="fig" rid="fig2">Figure 2</xref>. The third byte of the example shown in <xref ref-type="fig" rid="fig2">Figure 2</xref> is 0x1A, which indicates that the frame preamble is 26 bytes. If the third byte of the captured data is 0 &#215; 12, it represents that the frame preamble is 18 bytes (shown in Figures 9-13).</p></sec><sec id="s2_2"><title>2.2. Method of Frame Resolution</title><p>To analyze the information contained in the frame, we need to identify the value</p><fig id="fig1"  position="float"><label><xref ref-type="fig" rid="fig1">Figure 1</xref></label><caption><title> Structure of the captured data</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x2.png"/></fig><fig id="fig2"  position="float"><label><xref ref-type="fig" rid="fig2">Figure 2</xref></label><caption><title> A captured beacon frame data</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x3.png"/></fig><fig id="fig3"  position="float"><label><xref ref-type="fig" rid="fig3">Figure 3</xref></label><caption><title> Management frame format</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x4.png"/></fig><fig id="fig4"  position="float"><label><xref ref-type="fig" rid="fig4">Figure 4</xref></label><caption><title> Frame Control field</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x5.png"/></fig><fig id="fig5"  position="float"><label><xref ref-type="fig" rid="fig5">Figure 5</xref></label><caption><title> Sequence Control field</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x6.png"/></fig><fig id="fig6"  position="float"><label><xref ref-type="fig" rid="fig6">Figure 6</xref></label><caption><title> Beacon frame body</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x7.png"/></fig><fig id="fig7"  position="float"><label><xref ref-type="fig" rid="fig7">Figure 7</xref></label><caption><title> Common general format of information element</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x8.png"/></fig><fig id="fig8"  position="float"><label><xref ref-type="fig" rid="fig8">Figure 8</xref></label><caption><title> Algorithm flowchart of PHY protocol type’s detection</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x9.png"/></fig><fig id="fig9"  position="float"><label><xref ref-type="fig" rid="fig9">Figure 9</xref></label><caption><title> The captured data of a beacon frame from an AP set into IEEE 802.11b</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x10.png"/></fig><p>in each field. The frame resolution must be corresponding to the frame format. The information for security detection comes mainly from management frames. This section will illustrate an analytical method of IEEE 802.11 MAC Frame in three examples, which are adopting this method in analyzing1) a management frame’s header, 2) Control Frame field of the management frame and 3) Control Sequence field of the management frame. Their structures are shown in Figures 3-5 respectively [<xref ref-type="bibr" rid="scirp.76532-ref11">11</xref>]. The information contained in these fields is the most basic information for analyzing 802.11 wireless network environment. This informa-</p><fig id="fig10"  position="float"><label><xref ref-type="fig" rid="fig1">Figure 1</xref>0</label><caption><title> The captured data of a beacon frame from an AP set into IEEE 802.11a</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x11.png"/></fig><fig id="fig11"  position="float"><label><xref ref-type="fig" rid="fig1">Figure 1</xref>1</label><caption><title> The captured data of a beacon frame from an AP set into IEEE 802.11b/g</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x12.png"/></fig><fig id="fig12"  position="float"><label><xref ref-type="fig" rid="fig1">Figure 1</xref>2</label><caption><title> The captured data of a beacon frame from an AP set into IEEE802.11a/n</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x13.png"/></fig><p>tion is also essential for following frame body analyzing. Notice that the management frame header of IEEE Std 802.11-2012 [<xref ref-type="bibr" rid="scirp.76532-ref12">12</xref>] has an extra HT Control field compared to IEEE Std 802.11-2007 [<xref ref-type="bibr" rid="scirp.76532-ref11">11</xref>]. However, the existing data captured from experiment all conform to IEEE Std 802.11-2007. So only the frame format of IEEE Std 802.11-2007 will be examined in this paper.</p><fig id="fig13"  position="float"><label><xref ref-type="fig" rid="fig1">Figure 1</xref>3</label><caption><title> The captured data of a beacon frame from an AP set into IEEE 802.11b/g/n</title></caption><graphic mimetype="image"   position="float"  xlink:type="simple"  xlink:href="http://html.scirp.org/file/76532x14.png"/></fig><p>A multi byte numeric field needs to be converted from the network order to host order when parsing a captured packet. The sub-fields of a numeric field need to be reversely picked up from the binary value after the order converting, i.e. the last sub-field is picked up at first from the highest bit of the binary value. A non-numeric field, such as address, and its sub-fields, if existing, can be sequentially obtained from the captured data. This solution is illustrated with the data shown in <xref ref-type="fig" rid="fig2">Figure 2</xref>.</p><p>The 24-byte data, which starts from 27th byte of the data shown in <xref ref-type="fig" rid="fig2">Figure 2</xref>, is the header of the beacon frame. Value of the fields in the beacon frame header after parsing the captured data is shown in <xref ref-type="table" rid="table1">Table 1</xref>. The host byte order of a multi byte numeric field is different from its network byte order in Linux, so that the byte order of Frame Control, Duration and Sequence Control is reversed if compared to that of captured data.</p><p>The value of Frame Control filed in above example is 0x0080, which is 0000000010000000 in binary. According to resolving method for sub-field in the Frame Control shown in <xref ref-type="fig" rid="fig4">Figure 4</xref>, the results are drawn in <xref ref-type="table" rid="table2">Table 2</xref>.</p><p>According to the standard [<xref ref-type="bibr" rid="scirp.76532-ref11">11</xref>], this is a management frame (Type = 00), of which the body is a beacon frame body (Subtype = 1000).</p><p>Applying the same method, we can get two subfields’ value for Sequence Control shown in <xref ref-type="table" rid="table3">Table 3</xref>.</p></sec></sec><sec id="s3"><title>3. Detection Method of PHY Protocol Type</title><sec id="s3_1"><title>3.1. The Information Elements and Detection Algorithm for PHY Protocols</title><p>The commonly used WLAN PHY protocols are IEEE 802.11a, b, g and n. In order to analyze the type of protocol from the captured data, the information ele-</p><table-wrap id="table1" ><label><xref ref-type="table" rid="table1">Table 1</xref></label><caption><title> Value of each field in beacon frame header</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >Field Name</th><th align="center" valign="middle" >Length (in bytes)</th><th align="center" valign="middle" >Value (in hexadecimal)</th><th align="center" valign="middle" >Remarks</th></tr></thead><tr><td align="center" valign="middle" >Frame Ctrl</td><td align="center" valign="middle" >2</td><td align="center" valign="middle" >0080</td><td align="center" valign="middle" >Bytes in reverse order</td></tr><tr><td align="center" valign="middle" >Duration</td><td align="center" valign="middle" >2</td><td align="center" valign="middle" >0000</td><td align="center" valign="middle" >Bytes in reverse order</td></tr><tr><td align="center" valign="middle" >DA</td><td align="center" valign="middle" >6</td><td align="center" valign="middle" >FFFFFFFFFFFF</td><td align="center" valign="middle" >Sequential order</td></tr><tr><td align="center" valign="middle" >SA</td><td align="center" valign="middle" >6</td><td align="center" valign="middle" >6CE8739EE536</td><td align="center" valign="middle" >Sequential order</td></tr><tr><td align="center" valign="middle" >BSSID</td><td align="center" valign="middle" >6</td><td align="center" valign="middle" >6CE8739EE536</td><td align="center" valign="middle" >Sequential order</td></tr><tr><td align="center" valign="middle" >Sequence Ctrl</td><td align="center" valign="middle" >2</td><td align="center" valign="middle" >6240</td><td align="center" valign="middle" >Bytes in reverse order</td></tr></tbody></table></table-wrap><table-wrap id="table2" ><label><xref ref-type="table" rid="table2">Table 2</xref></label><caption><title> Value of each subfield in Frame Control</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >Subfield Name</th><th align="center" valign="middle" >Length (in bits)</th><th align="center" valign="middle" >Value (in binary)</th></tr></thead><tr><td align="center" valign="middle" >Protocol Version</td><td align="center" valign="middle" >2</td><td align="center" valign="middle" >00</td></tr><tr><td align="center" valign="middle" >Type</td><td align="center" valign="middle" >2</td><td align="center" valign="middle" >00</td></tr><tr><td align="center" valign="middle" >Subtype</td><td align="center" valign="middle" >4</td><td align="center" valign="middle" >1000</td></tr><tr><td align="center" valign="middle" >To DS</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >From DS</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >More Fragments</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >Retry</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >Power Management</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >More Data</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >Protected Frame</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >Order</td><td align="center" valign="middle" >1</td><td align="center" valign="middle" >0</td></tr></tbody></table></table-wrap><table-wrap id="table3" ><label><xref ref-type="table" rid="table3">Table 3</xref></label><caption><title> Value of each subfield in Sequence Control</title></caption><table><tbody><thead><tr><th align="center" valign="middle" >Subfield Name</th><th align="center" valign="middle" >Length (in bits)</th><th align="center" valign="middle" >Value (in hexadecimal)</th></tr></thead><tr><td align="center" valign="middle" >Fragment Number</td><td align="center" valign="middle" >4</td><td align="center" valign="middle" >0</td></tr><tr><td align="center" valign="middle" >Sequence Number</td><td align="center" valign="middle" >12</td><td align="center" valign="middle" >624</td></tr></tbody></table></table-wrap><p>ments in the frame body need to be analyzed after parsing the content of beacon frame as described in previous sections.</p><p>The format of beacon frame body is shown in <xref ref-type="fig" rid="fig6">Figure 6</xref> [<xref ref-type="bibr" rid="scirp.76532-ref13">13</xref>]. There are two types of components in management frame body: 1) Fixed-length field, such as Timestamp; 2) Variable-length field, called Information Element (IE), such as SSID. The common general format of an information element is shown in <xref ref-type="fig" rid="fig7">Figure 7</xref> [<xref ref-type="bibr" rid="scirp.76532-ref11">11</xref>]. Each element is assigned to a unique Element ID as defined in IEEE 802.11 standard to indicate its function. The Length field specifies the number of octets in the Information field. The Information field is variable-length and element-specific [<xref ref-type="bibr" rid="scirp.76532-ref11">11</xref>] [<xref ref-type="bibr" rid="scirp.76532-ref12">12</xref>].</p><p>The information elements used by the PHY protocol type have not been explicitly defined in the standard. This can lead to confusion when designing a detecting algorithm. So first list several possible information elements, such as ERP element and HT Capability element, based on the standard. Then during the experiments, use the aforementioned analytical method to analyse the captured beacon frame.</p><p>The results of information elements contained in the beacon frame body received from different PHY protocol APs are shown in <xref ref-type="table" rid="table4">Table 4</xref>. Notice that the structure of the captured frame header is consistent with the format defined in IEEE Std802.11-2007. Information element of HT Capabilities is fully defined in IEEE Std802.11-2012 while its element ID is reserved in IEEE Std802.11-2007.</p><p>According to <xref ref-type="table" rid="table4">Table 4</xref>, the detection algorithm of the PHY protocol types is shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>.</p></sec><sec id="s3_2"><title>3.2. NIC Working Frequency Acquisition Method</title><p>The algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref> needs to obtain working frequency of NIC (Network Interface Card). During the experiment, we find that if the length of frame preamble in captured data is 26 bytes, the frequency value of NIC is located in 19th and 20th byte of data. If the length of frame preamble in captured data is 18bytes, the frequency value of NIC is located in 11th and 12th byte of data. Using the analytical method in Section 2.2, we can get the working frequency of NIC. The specific examples are shown in Section 4.</p></sec></sec><sec id="s4"><title>4. Case Study</title><p>The effectiveness of the proposed methods can be verified through the following examples. Testing environment consists of a dual-band supported AP and a STA which are installed with the frame capturing program. The operating system of STA is Linux. The experiment AP is set to different PHY protocols. Launch the frame capturing program on STA and let it last for 5 minutes to get a certain number of frames. When obtaining a sufficient number of frames, stop the frame capturing program. Analyze the captured beacon frames according to the analysis method in section 2.2 and algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>.</p><sec id="s4_1"><title>4.1. IEEE 802.11b</title><p>Set the PHY protocol of AP to IEEE 802.11b. The captured data of a beacon frame are shown in <xref ref-type="fig" rid="fig9">Figure 9</xref>. We find that HT Capabilities information element and ERP information element do not exist. The octets containing the working frequency are 6C 09. Shaded area in the figure shows the location of the working frequency octets. According to the previous frame resolution method, the frequency value is 0x096C, which is 2412 MHz in decimal, that is, the working frequency of AP is on the 2.4 GHz band. According to the algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>, the PHY protocol of the AP is IEEE 802.11b, consistent with the preset.</p></sec><sec id="s4_2"><title>4.2. IEEE 802.11a</title><p>Set the PHY protocol of AP to IEEE 802.11a. The captured data of a beacon frame are shown in <xref ref-type="fig" rid="fig1">Figure 1</xref>0. We find that HT Capabilities information element and ERP information element do not exist. The octets containing the working frequency are 71 16. Shaded area in the figure shows the location of the working frequency octets. According to the previous frame resolution method, the frequency value is 0x1671, which is 5745 MHz in decimal, that is, the working frequency of AP is on the 5 GHz band. According to the algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>, the PHY protocol of AP is IEEE 802.11a, consistent with the preset.</p></sec><sec id="s4_3"><title>4.3. IEEE 802.11b/g</title><p>Set the PHY protocol of AP to IEEE 802.11b/g mixed mode. The captured data of a beacon frame are shown in <xref ref-type="fig" rid="fig1">Figure 1</xref>1. The ERP information element is 2A 01 04 (the second shaded area in the figure). The HT Capabilities information element does not exist. According to the algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>, the PHY protocol of AP is IEEE 802.11 g, consistent with the preset. The working frequency octets are 6C 09 (first shaded part in the figure). According to the previous frame resolution method, the frequency is 2412 MHz, proving that the working frequency of AP is on the 2.4 GHz band.</p><p>The algorithm under the condition of IEEE 802.11 g single mode is the same as that of IEEE 802.11b/g.</p></sec><sec id="s4_4"><title>4.4. IEEE 802.11a/n</title><p>Set the PHY protocol of AP to IEEE 802.11a/n. The captured data of a beacon frame are shown in <xref ref-type="fig" rid="fig1">Figure 1</xref>2. There is no ERP information element. The HT Capabilities information element exists (the second shaded area in the figure). According to the algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>, the PHY protocol of AP is IEEE 802.11a/n, consistent with the preset. The working frequency octets are 71 16 (first shaded part in the figure). According to the previous frame resolution method, the frequency is 5745 MHz, proving that the working frequency of AP is on the 5 GHz band.</p><p>The algorithm under the condition of IEEE 802.11n (5G) single mode is the same as that of IEEE 802.11a/n.</p></sec><sec id="s4_5"><title>4.5. IEEE 802.11b/g/n</title><p>Set the PHY protocol of AP to IEEE 802.11b/g/n mixed mode. The captured data of a beacon frame are shown in <xref ref-type="fig" rid="fig1">Figure 1</xref>3. Both HT Capabilities information element (the third shaded part in the figure) and ERP information element (the second shaded part in the figure) are existed. According to the algorithm shown in <xref ref-type="fig" rid="fig8">Figure 8</xref>, the PHY protocol of AP is IEEE 802.11b/g/n, consistent with the preset. The working frequency octets are 94 09 (first shaded part in the figure). According to the previous frame resolution method, the frequency is 2452 MHz, proving that the working frequency of AP is on the 2.4 GHz band.</p><p>The algorithm under the condition of IEEE 802.11n (2.4 G) single mode is the same as that of IEEE 802.11 b/g/n.</p></sec></sec><sec id="s5"><title>5. Conclusions</title><p>Capturing and resolving the MAC frames are the technical basis of kinds of security systems for IEEE 802.11 wireless network. Real-time detection of PHY protocol types of APs or STAs can help network manager to analyse the WLAN environment to identify suspicious devices. However, their solutions cannot be exported by the specifications due to different implementations and specifications not detailed enough. Also, no literature presents the related solutions, which might be due the research of packet capture and analysis focused on the PDU encapsulated in TCP or UDP rather than that in link layer frame in the past.</p><p>This paper proposed an analytical method for IEEE 802.11MAC frame and an algorithm for detecting PHY protocol types. The proposed method is based on analysing a large amount of captured MAC frames, and proved in an intrusion prevention system for WLAN. The detection algorithm of PHY protocols is easy to implement. The proposed ideas can not only be a reference for the research and development based on IEEE 802.11 Link Layer frame analysis, but also for capture and analysis of industrial protocol frames which are directly encapsulated in link layer frames, such as SV or GOOSE message in Smart Substation communications according to IEC 61850. That is, this work is also helpful for the research and development of testing and analysis systems for industrial devices, of which application PDUs are encapsulated in link layer frames.</p><p>We will research the relationship between the length of frame preamble and NIC. The data structure of frame preamble could also be further analysed. The detection method of the newest PHY standard IEEE 802.11ac, single mode and mixed mode of PHY protocol could be further explored etc.</p></sec><sec id="s6"><title>Acknowledgements</title><p>We thank National Natural Science Foundation of China for funding (51377122).</p></sec><sec id="s7"><title>Cite this paper</title><p>Li, L., Peng, S., Li, J., Yuan, K., Wang, Z.H., Liu, Y.B., Chen, P. and Wang, X.B. (2017) MAC Frame Resolution and PHY Protocol Type Detection of IEEE 802.11. Int. J. Communications, Network and System Sciences, 10, 43-53. https://doi.org/10.4236/ijcns.2017.105B005</p></sec></body><back><ref-list><title>References</title><ref id="scirp.76532-ref1"><label>1</label><mixed-citation publication-type="journal" xlink:type="simple"><name name-style="western"><surname>Gan</surname><given-names> Y. </given-names></name>,<etal>et al</etal>. (<year>2012</year>)<article-title>Analysis on Military Application Pro- spects and Development of WLAN</article-title><source> Communications Technology</source><volume> 45</volume>,<fpage> 1</fpage>-<lpage>9</lpage>.<pub-id pub-id-type="doi"></pub-id></mixed-citation></ref><ref id="scirp.76532-ref2"><label>2</label><mixed-citation publication-type="other" xlink:type="simple">You, T. and Liu, J. (2010) Research on Application of Wireless Local Area Network in Smart Power Grid. Jilin Electric Power, 38, 20-23.</mixed-citation></ref><ref id="scirp.76532-ref3"><label>3</label><mixed-citation publication-type="other" xlink:type="simple">Lai, Y., Wang, C., Tong, W. and Wang, X. (2014) Research on the Key Technology and Main Issues of Power Wireless Communication Network. Electric Power Information and Communication Technology, 12, 10-14.</mixed-citation></ref><ref id="scirp.76532-ref4"><label>4</label><mixed-citation publication-type="other" xlink:type="simple">Cai, Z. (2012) Discussion on the Application of Wireless Network Technology in Substation. China New Technologies and Products, 4, 144.</mixed-citation></ref><ref id="scirp.76532-ref5"><label>5</label><mixed-citation publication-type="other" xlink:type="simple">Boland, H. and Mousavi, H. (2004) Security Issues of the IEEE 802.11b Wireless LAN. Electrical and Computer Engi-neering, 1, 333-336. 
https://doi.org/10.1109/ccece.2004.1345023</mixed-citation></ref><ref id="scirp.76532-ref6"><label>6</label><mixed-citation publication-type="other" xlink:type="simple">Feng, P. (2012) Wireless LAN Security Issues and Solutions. The Proceedings of IEEE Symposium on Robotics and Applications (ISRA), Kuala Lumpur, 921-924. 
https://doi.org/10.1109/isra.2012.6219343</mixed-citation></ref><ref id="scirp.76532-ref7"><label>7</label><mixed-citation publication-type="other" xlink:type="simple">Singh, P., Mishra, M. and Barwal, P.N. (2014) Analysis of Security Issues and Their Solutions in Wireless LAN. Information Communication and Embedded Systems (ICICES), Chennai, 1-6. https://doi.org/10.1109/icices.2014.7033871</mixed-citation></ref><ref id="scirp.76532-ref8"><label>8</label><mixed-citation publication-type="other" xlink:type="simple">Arockiam, L. and Vani, B. (2010) A Survey of Denial of Service Attacks and It’s Countermeasures on Wireless Network. International Journal on Computer Science and Engineering, 2, 1563-1571.</mixed-citation></ref><ref id="scirp.76532-ref9"><label>9</label><mixed-citation publication-type="other" xlink:type="simple">Wu, K., Zhang, W. and Zhu, W. (2011) A Study on the Application of Intrusion Detection Technology to WLAN. Communication Software and Networks (ICCSN), Xi’an, 344-346.</mixed-citation></ref><ref id="scirp.76532-ref10"><label>10</label><mixed-citation publication-type="other" xlink:type="simple">Overlay vs. Integrated Wireless Security—The Pros and Cons of Different Approaches to Wireless Intrusion Prevention. http://www.flukenetworks.com</mixed-citation></ref><ref id="scirp.76532-ref11"><label>11</label><mixed-citation publication-type="other" xlink:type="simple">IEEE Std 802.11-2007 (2007) IEEE Standard for Information Technology—Tele- communications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.</mixed-citation></ref><ref id="scirp.76532-ref12"><label>12</label><mixed-citation publication-type="other" xlink:type="simple">IEEE Std 802.11-2012 (2012) IEEE Standard for Information Technology—Tele- communications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.</mixed-citation></ref><ref id="scirp.76532-ref13"><label>13</label><mixed-citation publication-type="other" xlink:type="simple">Gast, M.S. (2005) 802.11 Wireless Networks: The Definitive Guide. O’Reilly Media.</mixed-citation></ref></ref-list></back></article>