<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="edc38b22b49c7a38" weblate-flags="read-only">
        <source>802.11 wireless networks</source>
        <target state="translated">802.11 wireless networks</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">5</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c11148b9ac6c3fd2" weblate-flags="read-only">
        <source>The radio spectrum is a limited resource that must be shared by everyone. During most of the twentieth century, governments and international organizations have regulated most of the radio spectrum. This regulation controls the utilization of the radio spectrum, in order to prevent interference among different users. A company that wants to use a frequency range in a given region must apply for a license from the regulator. Most regulators charge a fee for the utilization of the radio spectrum and some governments have encouraged competition among companies bidding for the same frequency to increase the license fees.</source>
        <target state="translated">The radio spectrum is a limited resource that must be shared by everyone. During most of the twentieth century, governments and international organizations have regulated most of the radio spectrum. This regulation controls the utilization of the radio spectrum, in order to prevent interference among different users. A company that wants to use a frequency range in a given region must apply for a license from the regulator. Most regulators charge a fee for the utilization of the radio spectrum and some governments have encouraged competition among companies bidding for the same frequency to increase the license fees.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="79958703d11b21e7" weblate-flags="read-only">
        <source>In the 1970s, after the first experiments with ALOHANet, interest in wireless networks grew. Many experiments were done on and outside the ARPANet. One of these experiments was the `first mobile phone &lt;http://news.bbc.co.uk/2/hi/programmes/click_online/8639590.stm&gt;`_ , which was developed and tested in 1973. This experimental mobile phone was the starting point for the first generation analog mobile phones. Given the growing demand for mobile phones, it was clear that the analog mobile phone technology was not sufficient to support a large number of users.  To support more users and new services, researchers in several countries worked on the development of digital mobile telephones. In 1987, several European countries decided to develop the standards for a common cellular telephone system across Europe : the `Global System for Mobile Communications` (GSM). Since then, the standards have evolved and more than three billion users are connected to GSM networks today.</source>
        <target state="translated">In the 1970s, after the first experiments with ALOHANet, interest in wireless networks grew. Many experiments were done on and outside the ARPANet. One of these experiments was the `first mobile phone &lt;http://news.bbc.co.uk/2/hi/programmes/click_online/8639590.stm&gt;`_ , which was developed and tested in 1973. This experimental mobile phone was the starting point for the first generation analog mobile phones. Given the growing demand for mobile phones, it was clear that the analog mobile phone technology was not sufficient to support a large number of users.  To support more users and new services, researchers in several countries worked on the development of digital mobile telephones. In 1987, several European countries decided to develop the standards for a common cellular telephone system across Europe : the `Global System for Mobile Communications` (GSM). Since then, the standards have evolved and more than three billion users are connected to GSM networks today.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="01e6020acbb38760" weblate-flags="read-only">
        <source>While most of the frequency ranges of the radio spectrum are reserved for specific applications and require a special license, there are a few exceptions. These exceptions are known as the `Industrial, Scientific and Medical &lt;http://en.wikipedia.org/wiki/ISM_band&gt;`_ (ISM) radio bands. These bands can be used for industrial, scientific and medical applications without requiring a license from the regulator. For example, some radio-controlled models use the 27 MHz ISM band and some cordless telephones operate in the 915 MHz ISM. In 1985, the 2.400-2.500 GHz band was added to the list of ISM bands. This frequency range corresponds to the frequencies that are emitted by microwave ovens. Sharing this band with licensed applications would have likely caused interference, given the large number of microwave ovens that are used. Despite the risk of interference with microwave ovens, the opening of the 2.400-2.500 GHz allowed the networking industry to develop several wireless network techniques to allow computers to exchange data without using cables. In this section, we discuss in more detail the most popular one, i.e. the WiFi [IEEE802.11]_ family of wireless networks. Other wireless networking techniques such as `BlueTooth &lt;http://en.wikipedia.org/wiki/BlueTooth&gt;`_ or `HiperLAN &lt;http://en.wikipedia.org/wiki/HiperLAN&gt;`_ use the same frequency range.</source>
        <target state="translated">While most of the frequency ranges of the radio spectrum are reserved for specific applications and require a special license, there are a few exceptions. These exceptions are known as the `Industrial, Scientific and Medical &lt;http://en.wikipedia.org/wiki/ISM_band&gt;`_ (ISM) radio bands. These bands can be used for industrial, scientific and medical applications without requiring a license from the regulator. For example, some radio-controlled models use the 27 MHz ISM band and some cordless telephones operate in the 915 MHz ISM. In 1985, the 2.400-2.500 GHz band was added to the list of ISM bands. This frequency range corresponds to the frequencies that are emitted by microwave ovens. Sharing this band with licensed applications would have likely caused interference, given the large number of microwave ovens that are used. Despite the risk of interference with microwave ovens, the opening of the 2.400-2.500 GHz allowed the networking industry to develop several wireless network techniques to allow computers to exchange data without using cables. In this section, we discuss in more detail the most popular one, i.e. the WiFi [IEEE802.11]_ family of wireless networks. Other wireless networking techniques such as `BlueTooth &lt;http://en.wikipedia.org/wiki/BlueTooth&gt;`_ or `HiperLAN &lt;http://en.wikipedia.org/wiki/HiperLAN&gt;`_ use the same frequency range.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">13</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1ef15722fb89f189" weblate-flags="read-only">
        <source>Today, WiFi is a very popular wireless networking technology. There are more than several hundreds of millions of WiFi devices. The development of this technology started in the late 1980s with the `WaveLAN &lt;http://en.wikipedia.org/wiki/WaveLAN&gt;`_ proprietary wireless network. WaveLAN operated at 2 Mbps and used different frequency bands in different regions of the world. In the early 1990s, the IEEE_ created the `802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ to standardize a family of wireless network technologies. This working group was very prolific and produced several wireless networking standards that use different frequency ranges and different physical layers. The table below provides a summary of the main 802.11 standards.</source>
        <target state="translated">Today, WiFi is a very popular wireless networking technology. There are more than several hundreds of millions of WiFi devices. The development of this technology started in the late 1980s with the `WaveLAN &lt;http://en.wikipedia.org/wiki/WaveLAN&gt;`_ proprietary wireless network. WaveLAN operated at 2 Mbps and used different frequency bands in different regions of the world. In the early 1990s, the IEEE_ created the `802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ to standardize a family of wireless network technologies. This working group was very prolific and produced several wireless networking standards that use different frequency ranges and different physical layers. The table below provides a summary of the main 802.11 standards.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">15</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="097dd7c16ffba21b" weblate-flags="read-only">
        <source>Standard</source>
        <target state="translated">Standard</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="610c8557e506f9d8" weblate-flags="read-only">
        <source>Frequency</source>
        <target state="translated">Frequency</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2b831cf2c124f324" weblate-flags="read-only">
        <source>Typical throughput</source>
        <target state="translated">Typical throughput</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d170ad6869d7f6e" weblate-flags="read-only">
        <source>Max bandwidth</source>
        <target state="translated">Max bandwidth</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb7927d2deefe588" weblate-flags="read-only">
        <source>Range (m) indoor/outdoor</source>
        <target state="translated">Range (m) indoor/outdoor</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b08a897a279d5e06" weblate-flags="read-only">
        <source>802.11</source>
        <target state="translated">802.11</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="59803a7076969e61" weblate-flags="read-only">
        <source>2.4 GHz</source>
        <target state="translated">2.4 GHz</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96383daac82f34c0" weblate-flags="read-only">
        <source>0.9 Mbps</source>
        <target state="translated">0.9 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3fd79cab698256ac" weblate-flags="read-only">
        <source>2 Mbps</source>
        <target state="translated">2 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2be6fd16aa8d8c0f" weblate-flags="read-only">
        <source>20/100</source>
        <target state="translated">20/100</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f413b4ba04847763" weblate-flags="read-only">
        <source>802.11a</source>
        <target state="translated">802.11a</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="969371b605af5b61" weblate-flags="read-only">
        <source>5 GHz</source>
        <target state="translated">5 GHz</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9908266c0143528b" weblate-flags="read-only">
        <source>23 Mbps</source>
        <target state="translated">23 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b13896cc2c7bbce1" weblate-flags="read-only">
        <source>54 Mbps</source>
        <target state="translated">54 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="87fbc90f2fc4a3f9" weblate-flags="read-only">
        <source>35/120</source>
        <target state="translated">35/120</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="91668756ae3a809d" weblate-flags="read-only">
        <source>802.11b</source>
        <target state="translated">802.11b</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9aa990a4287eff1f" weblate-flags="read-only">
        <source>4.3 Mbps</source>
        <target state="translated">4.3 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0f54a8c240e99c58" weblate-flags="read-only">
        <source>11 Mbps</source>
        <target state="translated">11 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a913287004edd91" weblate-flags="read-only">
        <source>38/140</source>
        <target state="translated">38/140</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b15c56f499d66fbb" weblate-flags="read-only">
        <source>802.11g</source>
        <target state="translated">802.11g</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3b8004e6ff36d651" weblate-flags="read-only">
        <source>19 Mbps</source>
        <target state="translated">19 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b0507c9ebc1583bc" weblate-flags="read-only">
        <source>802.11n</source>
        <target state="translated">802.11n</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5d1377d5cf392ab8" weblate-flags="read-only">
        <source>2.4/5 GHz</source>
        <target state="translated">2.4/5 GHz</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a1685b2ed2d0e375" weblate-flags="read-only">
        <source>74 Mbps</source>
        <target state="translated">74 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="795eadc99f536919" weblate-flags="read-only">
        <source>150 Mbps</source>
        <target state="translated">150 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="69f2a8f44169206c" weblate-flags="read-only">
        <source>70/250</source>
        <target state="translated">70/250</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8763d857e3da8d29" weblate-flags="read-only">
        <source>When developing its family of standards, the `IEEE 802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ took a similar approach as the `IEEE 802.3 working group &lt;http://www.ieee802.org/3/&gt;`_ that developed various types of physical layers for Ethernet networks. 802.11 networks use the CSMA/CA Medium Access Control technique described earlier and they all assume the same architecture and use the same frame format.</source>
        <target state="translated">When developing its family of standards, the `IEEE 802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ took a similar approach as the `IEEE 802.3 working group &lt;http://www.ieee802.org/3/&gt;`_ that developed various types of physical layers for Ethernet networks. 802.11 networks use the CSMA/CA Medium Access Control technique described earlier and they all assume the same architecture and use the same frame format.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">29</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="556ad1bfc7b3daa6" weblate-flags="read-only">
        <source>The architecture of WiFi networks is slightly different from the Local Area Networks that we have discussed until now. There are, in practice, two main types of WiFi networks : `independent` or `adhoc` networks  and `infrastructure` networks [#fBSS]_. An `independent` or `adhoc` network is composed of a set of devices that communicate with each other. These devices play the same role and the `adhoc` network is usually not connected to the global Internet. `Adhoc` networks are used when for example a few laptops need to exchange information or to connect a computer with a WiFi printer.</source>
        <target state="translated">The architecture of WiFi networks is slightly different from the Local Area Networks that we have discussed until now. There are, in practice, two main types of WiFi networks : `independent` or `adhoc` networks  and `infrastructure` networks [#fBSS]_. An `independent` or `adhoc` network is composed of a set of devices that communicate with each other. These devices play the same role and the `adhoc` network is usually not connected to the global Internet. `Adhoc` networks are used when for example a few laptops need to exchange information or to connect a computer with a WiFi printer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="71c7a5613ee629b2" weblate-flags="read-only">
        <source>An 802.11 independent or adhoc network</source>
        <target state="translated">An 802.11 independent or adhoc network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="553862831de38553" weblate-flags="read-only">
        <source>Most WiFi networks are `infrastructure` networks. An `infrastructure` network contains one or more `access points` that are attached to a fixed Local Area Network (usually an Ethernet network) that is connected to other networks such as the Internet. The figure below shows such a network with two access points and four WiFi devices. Each WiFi device is associated to one access point and uses this access point as a relay to exchange frames with the devices that are associated to another access point or reachable through the LAN.</source>
        <target state="translated">Most WiFi networks are `infrastructure` networks. An `infrastructure` network contains one or more `access points` that are attached to a fixed Local Area Network (usually an Ethernet network) that is connected to other networks such as the Internet. The figure below shows such a network with two access points and four WiFi devices. Each WiFi device is associated to one access point and uses this access point as a relay to exchange frames with the devices that are associated to another access point or reachable through the LAN.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">47</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0434020b8d52774a" weblate-flags="read-only">
        <source>An 802.11 infrastructure network</source>
        <target state="translated">An 802.11 infrastructure network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">54</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="451da06d64fedbf1" weblate-flags="read-only">
        <source>An 802.11 access point is a relay that operates in the datalink layer like switches. The figure below represents the layers of the reference model that are involved when a WiFi host communicates with a host attached to an Ethernet network through an access point.</source>
        <target state="translated">An 802.11 access point is a relay that operates in the datalink layer like switches. The figure below represents the layers of the reference model that are involved when a WiFi host communicates with a host attached to an Ethernet network through an access point.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">56</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6a3877642c45e520" weblate-flags="read-only">
        <source>802.11 devices exchange variable length frames, which have a slightly different structure than the simple frame format used in Ethernet LANs. We review the key parts of the 802.11 frames. Additional details may be found in [IEEE802.11]_ and [Gast2002]_ . An 802.11 frame contains a fixed length header, a variable length payload that may contain up 2324 bytes of user data and a 32 bits CRC. Although the payload can contain up to 2324 bytes, most 802.11 deployments use a maximum payload size of 1500 bytes as they are used in `infrastructure` networks attached to Ethernet LANs. An 802.11 data frame is shown below.</source>
        <target state="translated">802.11 devices exchange variable length frames, which have a slightly different structure than the simple frame format used in Ethernet LANs. We review the key parts of the 802.11 frames. Additional details may be found in [IEEE802.11]_ and [Gast2002]_ . An 802.11 frame contains a fixed length header, a variable length payload that may contain up 2324 bytes of user data and a 32 bits CRC. Although the payload can contain up to 2324 bytes, most 802.11 deployments use a maximum payload size of 1500 bytes as they are used in `infrastructure` networks attached to Ethernet LANs. An 802.11 data frame is shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">93</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="97bcaaf9cb86f373" weblate-flags="read-only">
        <source>802.11 data frame format</source>
        <target state="translated">802.11 data frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">99</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4264b3e0fd401f52" weblate-flags="read-only">
        <source>The first part of the 802.11 header is the 16 bit `Frame Control` field. This field contains flags that indicate the type of frame (data frame, RTS/CTS, acknowledgment, management frames, etc), whether the frame is sent to or from a fixed LAN, etc [IEEE802.11]_. The `Duration` is a 16 bit field that is used to reserve the transmission channel. In data frames, the `Duration` field is usually set to the time required to transmit one acknowledgment frame after a SIFS delay. Note that the `Duration` field must be set to zero in multicast and broadcast frames. As these frames are not acknowledged, there is no need to reserve the transmission channel after their transmission. The `Sequence control` field contains a 12 bits sequence number that is incremented for each data frame and a 4 bits fragment number.</source>
        <target state="translated">The first part of the 802.11 header is the 16 bit `Frame Control` field. This field contains flags that indicate the type of frame (data frame, RTS/CTS, acknowledgment, management frames, etc), whether the frame is sent to or from a fixed LAN, etc [IEEE802.11]_. The `Duration` is a 16 bit field that is used to reserve the transmission channel. In data frames, the `Duration` field is usually set to the time required to transmit one acknowledgment frame after a SIFS delay. Note that the `Duration` field must be set to zero in multicast and broadcast frames. As these frames are not acknowledged, there is no need to reserve the transmission channel after their transmission. The `Sequence control` field contains a 12 bits sequence number that is incremented for each data frame and a 4 bits fragment number.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">102</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="05f56cddfb693c59" weblate-flags="read-only">
        <source>The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field.</source>
        <target state="translated">The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">105</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9d4b979ee34f58b6" weblate-flags="read-only">
        <source>When a frame is sent from a WiFi device to a server attached to the same LAN as the access point, the first address of the frame is set to the MAC address of the access point, the second address is set to the MAC address of the source WiFi device and the third address is the address of the final destination on the LAN. When the server replies, it sends an Ethernet frame whose source address is its MAC address and the destination address is the MAC address of the WiFi device. This frame is captured by the access point that converts the Ethernet header into an 802.11 frame header. The 802.11 frame sent by the access point contains three addresses : the first address is the MAC address of the destination WiFi device, the second address is the MAC address of the access point and the third address the MAC address of the server that sent the frame.</source>
        <target state="translated">When a frame is sent from a WiFi device to a server attached to the same LAN as the access point, the first address of the frame is set to the MAC address of the access point, the second address is set to the MAC address of the source WiFi device and the third address is the address of the final destination on the LAN. When the server replies, it sends an Ethernet frame whose source address is its MAC address and the destination address is the MAC address of the WiFi device. This frame is captured by the access point that converts the Ethernet header into an 802.11 frame header. The 802.11 frame sent by the access point contains three addresses : the first address is the MAC address of the destination WiFi device, the second address is the MAC address of the access point and the third address the MAC address of the server that sent the frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">107</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5cb8f9ad576f00e0" weblate-flags="read-only">
        <source>802.11 control frames are simpler than data frames. They contain a `Frame Control`, a `Duration` field and one or two addresses. The acknowledgment frames are very small. They only contain the address of the destination of the acknowledgment. There is no source address and no `Sequence Control` field in the acknowledgment frames. This is because the acknowledgment frame can easily be associated to the previous frame that it acknowledges. Indeed, each unicast data frame contains a `Duration` field that is used to reserve the transmission channel to ensure that no collision will affect the acknowledgment frame. The `Sequence Control` field is mainly used by the receiver to remove duplicate frames. Duplicate frames are detected as follows. Each data frame contains a 12 bits sequence number in the `Sequence Control` field and the `Frame Control` field contains the `Retry` bit flag that is set when a frame is transmitted.  Each 802.11 receiver stores the most recent sequence number received from each source address in frames whose `Retry` bit is reset. Upon reception of a frame with the `Retry` bit set, the receiver verifies its sequence number to determine whether it is a duplicated frame or not.</source>
        <target state="translated">802.11 control frames are simpler than data frames. They contain a `Frame Control`, a `Duration` field and one or two addresses. The acknowledgment frames are very small. They only contain the address of the destination of the acknowledgment. There is no source address and no `Sequence Control` field in the acknowledgment frames. This is because the acknowledgment frame can easily be associated to the previous frame that it acknowledges. Indeed, each unicast data frame contains a `Duration` field that is used to reserve the transmission channel to ensure that no collision will affect the acknowledgment frame. The `Sequence Control` field is mainly used by the receiver to remove duplicate frames. Duplicate frames are detected as follows. Each data frame contains a 12 bits sequence number in the `Sequence Control` field and the `Frame Control` field contains the `Retry` bit flag that is set when a frame is transmitted.  Each 802.11 receiver stores the most recent sequence number received from each source address in frames whose `Retry` bit is reset. Upon reception of a frame with the `Retry` bit set, the receiver verifies its sequence number to determine whether it is a duplicated frame or not.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bc86baac36ac3c21" weblate-flags="read-only">
        <source>IEEE 802.11 ACK and CTS frames</source>
        <target state="translated">IEEE 802.11 ACK and CTS frames</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">115</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7c1d5c258be6c7b8" weblate-flags="read-only">
        <source>802.11 RTS/CTS frames are used to reserve the transmission channel, in order to transmit one data frame and its acknowledgment. The RTS frames contain a `Duration` and the transmitter and receiver addresses. The `Duration` field of the RTS frame indicates the duration of the entire reservation (i.e. the time required to transmit the CTS, the data frame, the acknowledgments and the required SIFS delays). The CTS frame has the same format as the acknowledgment frame.</source>
        <target state="translated">802.11 RTS/CTS frames are used to reserve the transmission channel, in order to transmit one data frame and its acknowledgment. The RTS frames contain a `Duration` and the transmitter and receiver addresses. The `Duration` field of the RTS frame indicates the duration of the entire reservation (i.e. the time required to transmit the CTS, the data frame, the acknowledgments and the required SIFS delays). The CTS frame has the same format as the acknowledgment frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">120</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="087c2244277739a6" weblate-flags="read-only">
        <source>IEEE 802.11 RTS frame format</source>
        <target state="translated">IEEE 802.11 RTS frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">126</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="700965a93261cfd7" weblate-flags="read-only">
        <source>The 802.11 service</source>
        <target state="translated">The 802.11 service</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">129</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e7fccebd69001960" weblate-flags="read-only">
        <source>Despite the utilization of acknowledgments, the 802.11 layer only provides an unreliable connectionless service like Ethernet networks that do not use acknowledgments. The 802.11 acknowledgments are used to minimize the probability of frame duplication. They do not guarantee that all frames will be correctly received by their recipients. Like Ethernet, 802.11 networks provide a high probability of successful delivery of the frames, not a guarantee. Furthermore, it should be noted that 802.11 networks do not use acknowledgments for multicast and broadcast frames. This implies that in practice such frames are more likely to suffer from transmission errors than unicast frames.</source>
        <target state="translated">Despite the utilization of acknowledgments, the 802.11 layer only provides an unreliable connectionless service like Ethernet networks that do not use acknowledgments. The 802.11 acknowledgments are used to minimize the probability of frame duplication. They do not guarantee that all frames will be correctly received by their recipients. Like Ethernet, 802.11 networks provide a high probability of successful delivery of the frames, not a guarantee. Furthermore, it should be noted that 802.11 networks do not use acknowledgments for multicast and broadcast frames. This implies that in practice such frames are more likely to suffer from transmission errors than unicast frames.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">131</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66600e4bc34d65b0" weblate-flags="read-only">
        <source>In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_.</source>
        <target state="translated">In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">135</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="62e57f96ad618e24" weblate-flags="read-only">
        <source>A first type of management frames are the `beacon` frames. These frames are broadcasted regularly by access points. Each `beacon frame` contains information about the capabilities of the access point (e.g. the supported 802.11 transmission rates) and a `Service Set Identity` (SSID). The SSID is a null-terminated ASCII string that can contain up to 32 characters. An access point may support several SSIDs and announce them in beacon frames. An access point may also choose to remain silent and not advertise beacon frames. In this case, WiFi stations may send `Probe request` frames to force the available access points to return a `Probe response` frame.</source>
        <target state="translated">A first type of management frames are the `beacon` frames. These frames are broadcasted regularly by access points. Each `beacon frame` contains information about the capabilities of the access point (e.g. the supported 802.11 transmission rates) and a `Service Set Identity` (SSID). The SSID is a null-terminated ASCII string that can contain up to 32 characters. An access point may support several SSIDs and announce them in beacon frames. An access point may also choose to remain silent and not advertise beacon frames. In this case, WiFi stations may send `Probe request` frames to force the available access points to return a `Probe response` frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">141</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="507a4bccda13c035" weblate-flags="read-only">
        <source>IP over 802.11</source>
        <target state="translated">IP over 802.11</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">144</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="088c65d87a75549c" weblate-flags="read-only">
        <source>Two types of encapsulation schemes were defined to support IP in Ethernet networks : the original encapsulation scheme, built above the Ethernet DIX format is defined in :rfc:`894` and a second encapsulation :rfc:`1042` scheme, built above the LLC/SNAP protocol [IEEE802.2]_. In 802.11 networks, the situation is simpler and only the :rfc:`1042` encapsulation is used. In practice, this encapsulation adds 6 bytes to the 802.11 header. The first four bytes correspond to the LLC/SNAP header. They are followed by the two bytes Ethernet Type field (`0x800` for IP and `0x806` for ARP). The figure below shows an IP packet encapsulated in an 802.11 frame.</source>
        <target state="translated">Two types of encapsulation schemes were defined to support IP in Ethernet networks : the original encapsulation scheme, built above the Ethernet DIX format is defined in :rfc:`894` and a second encapsulation :rfc:`1042` scheme, built above the LLC/SNAP protocol [IEEE802.2]_. In 802.11 networks, the situation is simpler and only the :rfc:`1042` encapsulation is used. In practice, this encapsulation adds 6 bytes to the 802.11 header. The first four bytes correspond to the LLC/SNAP header. They are followed by the two bytes Ethernet Type field (`0x800` for IP and `0x806` for ARP). The figure below shows an IP packet encapsulated in an 802.11 frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">146</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="86c02611ce64fde5" weblate-flags="read-only">
        <source>IP over IEEE 802.11</source>
        <target state="translated">IP over IEEE 802.11</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">152</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="35ccfa1b86d85a90" weblate-flags="read-only">
        <source>The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station.</source>
        <target state="translated">The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">154</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">157</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d4febaf642f12973" weblate-flags="read-only">
        <source>The 802.11 working group defined the `basic service set (BSS)` as a group of devices that communicate with each other. We continue to use `network` when referring to a set of devices that communicate.</source>
        <target state="translated">The 802.11 working group defined the `basic service set (BSS)` as a group of devices that communicate with each other. We continue to use `network` when referring to a set of devices that communicate.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">158</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c3507618f1b9ef0d" weblate-flags="read-only">
        <source>In fact, the [IEEE802.11]_ frame format contains a fourth optional address field. This fourth address is only used when an 802.11 wireless network is used to interconnect bridges attached to two classical LAN networks.</source>
        <target state="translated">In fact, the [IEEE802.11]_ frame format contains a fourth optional address field. This fourth address is only used when an 802.11 wireless network is used to interconnect bridges attached to two classical LAN networks.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">160</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
