802.11 protocol Intensive Reading 9: Primary discussion on energy saving mode (PS mode) and caching mechanism

Source: Internet
Author: User

Preface

Because of the 802.11 protocol working mechanism, if it is in a working state, then the power consumption is relatively large, especially the mobile device power is limited, so in the early 802.11 protocol design the corresponding energy management mechanism, that is, the introduction of energy-saving mode. In this paper, we mainly discuss some basic ideas and corresponding components of the energy-saving mode. For the specific MAC layer work mechanism, we are in the next article in the unfolding.

Note: The initial intent of this article is to describe the specific MAC layer operating mechanism in the energy-saving mode, but later in the write cache structure, found that the content is more organized, so the split. Therefore, in this paper, we mainly describe the 802.11 protocol, the basic idea of energy saving, and some of the components added, the specific MAC protocol and then supplemented.

energy consumption in the 802.11 protocol

In order to understand the 802.11 energy saving mechanism, we first need to comb some of the energy consumption in the WiFi. Typically, 802.11 devices will have a total of 4 working states:

    • Sleep (sleep mode): The node shuts down the send and receive modules for hibernation, thus minimizing energy consumption.
    • Rx Idle (Receiving idle state): The node listens to the channel but does not actually receive the data frame.
    • Rx (Receive status): The node hears the data frame and receives it.
    • Tx (send status): The node sends a data frame.

The relationship between RX Idle state, RX Status and TX status needs to be understood from the Send/Receive process we described earlier. 1) The node needs to perform CCA first to listen for any data frames in the channel (mainly Ed and CS two processes), the process is the RX idle state. The RX idle state can be transferred to the RX State or to the TX state. 2) If the node in the monitoring channel process, the discovery of 802.11 of the data frame, then it is transferred to the RX state to receive. 3) If the node itself has data to be sent, and in the process of continuously listening to the channel (that is, during the Backoff process), the Discovery Channel is idle, then it is transferred to the TX state to send.

In the above process, only the RX and TX states are really useful. However, in practice, in order to ensure that there is no conflict between acceptance and delivery, the node takes a long time to be in the RX idle state, which consumes a lot of energy. In general, the RX idle state is approximate to the RX state, just a few upper-level logic-processing work, while the larger-power RF modules, LNA,AGC, are all equally needed to work. Therefore, in the 802.11 protocol design, sleep hibernation should be introduced to replace the RX idle state to achieve the purpose of energy saving, and then expand into the working mechanism in sleep mode.

The power consumption of these four modes is given in the general WiFi chip (refer to the 10.1.5 Power consumption section of ar5213_data_sheet_0704)


The diagram describes the work in 802.11g mode, in order to better describe the theme, we have some of the original image of the crop, the rest of the operating mode of power consumption also please check the original. The AR5213 chip is listed separately, which corresponds to different power consumption in 1.8V power supply mode and 3.3V power supply mode. It can be seen clearly that the sleep state and several other states of the power consumption is still very large gap, so that the energy-saving mode if set well, then can achieve a good energy-saving effect.

At the same time, just give a standard TX power size, in 802.11 there is also the transmit power levels parameter, generally there are 8 levels, you can adjust the specific TX power. Also in Beacon frames, the power Constraint element and power Capability element parameters may be added to constrain node power within the region. These all affect the specific TX power size, but since these mechanisms are mainly used for the TPC (transmit power Control) mechanism, this discussion is mainly about energy-saving mechanisms, so it does not unfold.

basic idea of energy-saving mode

As we have previously described, the most power dissipation in 802.11 is in the RX idle state. If you can reduce the duration of the RX idle state, the node will be able to save energy. In this section of the discussion, because the specific MAC mechanism is not discussed, we simply assume that a topology that contains only one AP and one node. The uplink of the node is sent to the AP, and the downstream is the AP to the node. So from the point of view of the node, there are two possibilities to perform RX idle:

    • If the node is to send data, then RX Idle is used to listen to the channel, so if there is no data sent, then do not listen, so you can reduce the duration of RX idle, this is still easy to do.
    • If the node is to receive data, then RX idle must be persistent for a long time. Because as a receiver, the node can not know when the AP sent to its own downstream data, so to constantly listen to the channel, to maintain the RX idle state, for each packet can not be missed. Because the node cannot control the AP, this piece is more difficult to do.

Therefore, in 802.11, a passive request mechanism is provided, which mainly provides a mechanism for the node to control the AP so that it can send the corresponding downlink frame to itself. Therefore, in the energy-saving mode, the 802.11 protocol introduces two mechanisms:
    • Caching mechanism: The main cache here is the data that the AP sends to the node. When the AP receives data to be forwarded to the node from the extranet, it is cached in the form of MSDU (that is, the data frame of the MAC layer), which is only cached for node data that is working in power-saving mode, and is not sent directly to the node.

    • Ps-poll mechanism: If the node wants to get downstream data, then the node needs to actively request data with the AP, the request frame is the ps-poll frame. When the AP receives the frame, it checks to see if the buffer has a cache of the nodes that should be, and if it does, it pulls the cached data from the cache to the node and sends it back, if not, and feedback a null frame (empty data). In some books, this request mechanism is also described as "Bing pong" mechanism.

Let's describe the interaction mechanism here:


    1. Because the AP is known to work in power-saving mode, it first caches the data that is sent to the node.
    2. When working in the energy-saving mode of the node wake-up, after completing the competition, it first sends the PS-POLL frame to the AP to request the downstream data frame.
    3. The AP will then find the cached data for that node in its own cache. When the corresponding data frame is found, feedback through frame, here you can see the description of a ieee80211_fctl_moredata, which actually corresponds to the more data field in the wireless packet, if the AP.
    4. If the node recognizes that the more data field is 1, knowing that the AP has its own cache data, the Ps-poll frame is sent again for the request.
    5. Until the more data field in the AP feedback frame is 0, the node will not continue to feed back the ps-poll frame. The data request for the round ended, thus continuing sleep for power saving.

PS: Simply describes the basic working principle of the energy-saving mode, in which we omit the ACK process and the specific working mechanism in the multi-node case, and then we add it. If there is any mistake in the above statement, please forgive me.


Caching mechanism

Here we roughly talk about the next AP for downlink data caching mechanism, first of all, the author of this piece is not completely straightened out, especially the Protocol and kernel Implementation mechanism this piece, seemingly not exactly in accordance with the definition of the agreement to achieve, so here is just a few simple enumeration. If there are any errors please also point out, in order to make this piece more smooth.

    • Description of the caching mechanism in the Protocol (refer to version 802.11 of protocol 07/12)

In the protocol, the description of the buffer is still more complex. To express the cache, we first describe how a frame is defined in the 802.11 protocol. In the 802.11 protocol, the data frame is stored through the FRAGSDU structure. (see version 07 for details 第805-806 page)


In this section, we describe them in the order in which they are labeled.

    • The red section of 1, this section describes the function of this entire module, is used to describe a segmented support class. Then under this class, 3 sub-modules are defined (only 2 in the figure, and one is related to the energy-saving mode, so it is described later).
    • The red part of the 2, note indicates that an array is defined here to hold the specific data frame.
    • The blue part is 1, and the identifying part is the specific definition of the Fragarray array.
    • The red part of the 3, commented on the function of the FRAGSDU, in fact, the entire send cache, whether or not there are fragment are stored according to FRAGSDU, the FRAGSDU in the implementation of the concrete is a structure. Although the name is used to define the SDU of the Shard, it is also stated in the "each SDU, even if not fragmented, was held in a instance of this structure awaiting its (re) tran Smission attempt (s). ", so even if the packet does not have shards, it should be in accordance with FRAGSDU this form of uniform storage.
    • The blue part of the 2, in the FRAGSDU structure, mainly stored in this specific data packet corresponding to a lot of parameters. These parameters contain specific control fields in the data frame, and we describe them in the notation of the purple squares. In this line of purple squares, purple 1 labels The variable named PSM, purple 2 The variable type is a Boolean type, and the field marked in purple 3 is a comment that describes whether the packet is destined for the node in power-saving mode. In this line of representation, if the variable is 1, then it identifies the receiving node that the packet corresponds to is working in the power-saving mode, and vice versa. The Fragarray array, previously defined in red Section 2, is also stored in the FRAGSDU structure by the PDUs parameter defined by the last line.

PS: Because this article is to describe the caching mechanism in the energy-saving mode, so there is no expansion of the frame reorganization part, if it is the case of frame reorganization, then the main function is the Fragnum type of 3 parameters and Seqnum type of 1 parameters.

Each frame is stored through FRAGSDU, and for multiple frames, in the 802.11 protocol, the queue is actually stored in a queue, which is sduqueue. In the 802.11 protocol, both the send cache and the send cache used in power-saving mode are the structure of a queue. In the 802.11 protocol description, it is a class that first defines a queue, and then inherits the Sduqueue in the segmented support class. First we look at the initial definition of the next queue class, as follows:


In the queue class, it defines two methods, Qfirst (Queue,item) and Qlast (Queue,item). Where the Qfirst (Queue,item) Sub-function is responsible for inserting the data frame into the queue header, Qlast (Queue,item) is responsible for inserting the data frame into the tail of the queue, in some materials, here also described the First_and_tail method is defined, But I did not find it directly in the agreement. In the Fragment support class, the queue is inherited, as follows:


That is to add a method Qsearch (QUEUE,ADDR), in the energy-saving mode, when the node sends Ps-poll, the AP needs to find the data frame of the node in the buffer, and then carry out the corresponding transmission. In this section of the description, the FRAGSDU description is for the Power save buffers use, but a lot of materials, the entire transmission cache is stored in accordance with the form of Sduqueue, where the author has not been strictly textual research, and finally we use a picture to describe the entire structure.



    • Description of the cache mechanism and energy-saving mode in the kernel (refer to section 12th of Linux Kernel Networking and OpenWrt source code)

In the kernel, the cache is defined in the OpenWrt source \net\mac80211\sta_info.h, as


Wherein Ps_tx_buf is used in the energy-saving mode, the storage node of the buffer, wherein the IEEE80211_NUM_ACS parameter is generally set to 4, which corresponds to the existence of 802.11e in the 4 different priority queue, Sk_buffer_head is a structure, The meaning is a chain-head, generally this structure is used to assist the SK_BUFF structure to quickly find the node of the linked list. In the implementation, we should use the linked list structure to implement a queue, or a FIFO.

At the same time, the definition of a number of buffer length limitations, the author is currently finishing a total of three restrictions.


    • Sta_max_tx_buffer: The parameter size is 64 (as described in the book is 128), is used to limit the ps_tx_buf, the position in the \net\mac80211\sta_info.h. This parameter means that a maximum of 64 packets per node can be stored.


    • Ap_max_bc_buffer: The parameter size is 128 and is used to limit the size of bc_buf, where the position is in \net\mac80211\ieee80211_i.h. This buffer is designed to hold multicast/broadcast frames with only 1 queues.

    • Total_max_tx_buffer: The parameter size is 512, according to the description, is used to limit the total BUFFER size, the position is in the \net\mac80211\ieee80211_i.h.

PS: The above is mainly concerned about the next, the AP in the energy-saving mode set cache structure, the specific energy-saving implementation mechanism and MAC layer protocol, here we have not unfolded, please forgive me.

802.11 protocol Intensive Reading 9: Primary discussion on energy saving mode (PS mode) and caching mechanism

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.