JP2006229973A - Bitmap manager, bitmap memory allocation method, method for generating confirmation between network components and network component for performing the same - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To disclose a bitmap manager, a method for allocating a bitmap memory, a method for generating confirmation between network components and the network components for realizing the method. <P>SOLUTION: The bitmap manager includes the bitmap memory for storing block confirmation of a frame received based on a bitmap, a bitmap operation information controller for storing a bitmap entry number and receiving bitmap operation information relevant to a physical address of the bitmap memory and a bitmap manager finite state machine BMFSM for receiving an update or extraction request to the received frame, handling the bitmap operation information and updating or extracting the bitmap memory. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a bitmap manager, a method for allocating bitmap memory, a method for generating a check between network components, and a network component for realizing the same.

  In a communication protocol, ARQ (automatic repeat request) is a conventional technique for detecting a frame error by a transmitter and requesting repeated transmission when there is an error in a frame. There are various ARQ techniques such as stop-and-wait ARQ, go-back-n ARQ, and selective iterative ARQ.

  The stop-and-wait protocol transmits information on the protocol data unit PDU and then waits for a response. The receiver receives each PDU, sends an acknowledgment (ACL) PDU if the data PDU is received correctly, and sends a negative acknowledgment (NACK) PDU if no data is received. In fact, the receiver may not be able to reliably confirm whether a PDU has been received, and the transmitter needs to run a timer to recover from a state where the receiver does not respond. Stop-and-wait transmission is the simplest technique and is insufficient for high bandwidth or high quality service communication protocols.

  The go-back-nARQ protocol transmits numbered protocol data unit information until the time of receiving a control PDU indicating a missing PDU. When the transmitter receives the control PDU, it starts all consecutive frames after the last frame successfully received. The go-back-nARQ protocol has a problem of requiring a large buffer and repeated transmission of the same frame when an error frame is received.

  In the selective ARQ protocol, the transmitter selectively retransmits only frames with errors in transmission. The selective ARQ protocol has features that apply to high bandwidth communications or high quality service communications. For example, wireless networks based on IEEE 802.11 are widely used at home and at work. New applications such as video and multimedia trimming bring new features of quality of service requirements for wireless networks.

  Increased demands on bandwidth or quality of service cause network congestion, and more users seek multimedia distribution that operates without outages or slowdowns. This requirement is the reason for developing a service quality improvement plan for 802.11 wireless LANs.

  Legacy 802.11 MAC always sends a confirmation ACK frame after each successfully received frame. A block ACK transmits several data frames before the ACK returns, but this increases efficiency because all frames have considerable overhead for radio synchronization. Block confirmation increases efficiency by combining ACKs for multiple received frames into a single response. The block ACK starts through a setup and negotiation process between QSTA (QoS station) and QAP (QoS access point). When the block ACK is established, a number of QoS data frames are transmitted in a contention free burst with a short inter frame space (SIFS) separation between the frames.

  There are two block ACK mechanisms defined in 802.11e: Immediate and Delayed. When using an immediate block ACK, the source originator) transmits a number of data frames separated by SIFS in a contention-free burst. The transmission source must comply with the restrictions of the transmission operation (TXOP) period in which the current operation is performed. At the end of the burst, the source transmits a block ACK request frame. The recipient should immediately respond to the block ACK frame that contains the confirmation status for the previous burst of data frames.

  The delayed policy ensures that the group confirmation is sent on the next TXOP that comes after the burst. The same order of contention free burst and block ACK requests is used as in the immediate mechanism. The recipient just sends a standard ACK indicating that the block ACK is delayed in response to the block ACK request. Delayed confirmation is provided to help achieve lower performance, increasing latency and not being able to immediately calculate ACK.

  It is an object of the present invention to provide a bitmap manager, a method for allocating bitmap memory, a method for generating verification between network components, and a network component that implements this.

  An object of the present invention is to provide a bitmap manager, a method for allocating bitmap memory, a method for generating a check between network components, and a network component for realizing the same, which realize an improved block ACK technique. It is.

  It is an object of the present invention to provide a more flexible and dynamic technique for operating and / or allocating bitmap memory.

  An exemplary embodiment of the present invention is an automatic repeat request finite that receives frames from other network components, decodes selective information from the received frames, and returns block confirmation or confirmation frames to other network components. A state machine ARQFSM, an ARQ comparator that determines a confirmation policy by comparing selective information of received frames with stored component information, and a bitmap that stores block confirmation bits and bitmap management information by the confirmation policy And a network component including a manager.

  In an exemplary embodiment, the ARQ information comparator includes a MAC address MA comparator, where the MAC address MA comparator is based on a key search engine (KSE) for secure wireless communication. .

  In an exemplary embodiment, the ARQ information comparator includes a MAC address (MA) comparator and traffic that searches for a MAC address component number MA_EN of a MAC address that is matched with the MAC address and MAC address component number of the received frame. It further includes a traffic ID (MA_EN / TID) comparator for searching for a bitmap component number BtM_EN of the bitmap management information BMI matched with the ID (TID).

  In the exemplary embodiment, the ARQ information comparator is based on KSE.

  In an exemplary embodiment, the bitmap management information includes a SWF (start waiting flag) and an SSN (start sequence number). In an exemplary embodiment, the bitmap management information controller sets the SWF at each start of the block confirmation BA process and removes the SWF at each end of the block confirmation BA process.

  In the exemplary embodiment, the bitmap FSM controls updating the components at the bitmap operation controller and controls updating or extracting the confirmation information from the bitmap memory for the received frame.

  In the exemplary embodiment, the bitmap management information controller calculates the actual address in the bitmap memory.

  In an exemplary embodiment, the bitmap management information controller defragments the bitmap memory by assigning the currently used bitmap portion to the unused bitmap portion of the bitmap memory.

  In an exemplary embodiment, the bitmap management information controller determines the currently used bitmap portion by changing the start memory address of each portion of bitmap memory assigned to the confirmation information for receiving the frame. Assign to unused bitmap parts.

  In the exemplary embodiment, bitmap FSM sets SWF at each start of block confirmation BA processing and removes SWF at each end of block confirmation BA processing.

  Exemplary embodiments of the present invention relate to block ACK (BA) support methods between a source and a recipient, each of which can also operate with immediate block ACK or delayed block ACL policies.

  An exemplary embodiment of the present invention relates to a method for allocating a bitmap memory of a first network component, wherein an arbitrary tangible block confirmation is negotiated with a second network element including immediate block confirmation or delayed block confirmation and transmitted. Negotiating the amount of data and changing the confirmation information of the bitmap entry or the first network component to the second network component based on the amount of data transmitted and the tangible nature of the block confirmation.

  In an exemplary embodiment, the first network component includes software, device drivers and hardware, the first network component is a source, the second network component is a recipient, and the first network component The device driver transmits a block confirmation request to the second network component, the first network component hardware receives an immediate block confirmation from the second network component, and the first network component is based on the immediate block confirmation. The first network component hardware receives the block confirmation and transmits it to the device driver and software, and the first network component device driver clears the block confirmation and issues a block confirmation request. delete.

  In an exemplary embodiment, the first network component includes software, device drivers and hardware, the first network component is a source, the second network component is a recipient, and the first network component The device driver transmits a block confirmation request to the second network component, the first network component hardware receives a delayed block confirmation from the second network component, and the first network component receives the delayed block. A timer is set based on the confirmation, the first network component hardware receives the block confirmation, transmits the block confirmation to the device driver and software, responds to the block confirmation, and the first network component Device driver erases block confirmation and requests block confirmation We want to delete.

  In an exemplary embodiment, the first network component includes software, device drivers and hardware, the first network component is a recipient, the second network component is a source, and the first network component The device driver adds block confirmation information to the bitmap memory, dynamically allocates a predetermined portion of the bitmap memory, the first network component transmits a block confirmation response to the second network component, and the first network component Hardware updates the predetermined portion of the bitmap memory, the first network component hardware extracts the relevant bit from the bitmap memory, generates a block confirmation and transmits the block confirmation to the second network component. The first network element receives the block confirmation request. Once the hardware of the first network element transmits a block check, and device drivers of the first network element off the block check, deletes the block confirmation request.

  In an exemplary embodiment, the first network component includes software, device drivers and hardware, the first network component is a recipient, the second network component is a source, and the first network component The device driver adds block confirmation information to the bitmap memory, dynamically allocates a predetermined portion of the bitmap memory, the first network component transmits a block confirmation response to the second network component, and the first network component The software extracts the relevant bits from the bitmap memory, generates a block confirmation and transmits the block confirmation to the second network component, and the hardware of the first network component sends a block confirmation request to the first network component. To the device driver and the first network configuration Hardware elements transmits a confirmation, device driver of the first network element sends to prepare the block check, and device drivers of the first network element off the block check, deletes the block confirmation request.

  Exemplary embodiments of the present invention allocate various tasks to hardware, device drivers, and software components to increase the flexibility of the resulting component or method.

  An exemplary embodiment of the present invention relates to a method for generating a confirmation between network components, retrieving stored selective information matched with selective information from received frames and generating a hit / miss signal. Determining the tangible nature of the block confirmation, updating the bitmap management information, and generating a block confirmation or confirmation frame from the bitmap memory according to the bitmap management information.

  Exemplary embodiments of the present invention relate to a bitmap manager, a method of operating a bitmap memory, and a network component that performs the method according to the IEEE 802.11e or 801.16d wireless network standard.

  According to the present invention, the hardware can support SIFS time limit when an immediate BA is negotiated. In an exemplary embodiment of the invention, a flexible bitmap memory has the advantage of a lower gate count. In the exemplary embodiment of the present invention, the total number of gates can be further reduced by using the existing KSE as the ARQFSM, as described above.

  The present invention can also be applied to the 802.11e convention or the 802.16d convention. In the 802.16d protocol, the selective ACK method is performed by adjusting the ARQ FSM with respect to the 802.16 Dd protocol, fixing NOF to '1', and using a concatenated ID (CID) instead of a MAC address. Can be

  FIG. 1 is a diagram illustrating an example of a timing request in a related art block ACK request according to an exemplary embodiment of the present invention. FIG. 1 shows the connection of points between the station STA and the access point AP. The STA and AP illustrated in FIG. 1 are QoS station QSTA QoS access points QAP that support the 802.11e standard. In particular, FIG. 1 illustrates a timing request for a block ACK request between an access point AP and a station STA for a transmission opportunity TXOP.

  As shown in FIG. 1, after QoS contention-free QCf polling, the STA receives a TXOP and starts data transmission in a short inter-frame space (SIFS). Block ACKBA processing begins with transmission of one or more MAC protocol data units MPDUs from the AP to the STA. Each MPDU is separated by SIFS. At the end of the MPDU string, the STA receives a block ACK request followed by another SIFS. As illustrated in FIG. 1, the STA responds to the BAR from the AP with a block ACKBA that is 128 bytes.

  According to the 802.11e standard, when a STA receives a block ACK request (BAR) frame, the STA completes the ARQ negotiation by providing either an immediate ACK or a delayed ACK within the SIFS time period. Should. The STA returns BA or one ACK according to the result of the confirmation policy negotiation.

  For frames received by the STA, the ARQ engine is used to store the state of ACK / NAKs in the bitmap memory. When a BA is requested, the STA's ARQ engine sends the BA after the SIFS period.

  The bitmap memory of the STA's ARQ engine stores the value of ACK / NAKs as “high” (ACK) and “low” (NACK). In an exemplary embodiment, an ARQ engine that employs such a bitmap memory is referred to as a bitmap-based ARQ engine and is described in more detail below.

  Elements for designing an ARQ engine based on a bitmap are: a number of station STAs communicating with the AP, a number of traffic IDs or TIDs (up to 16 are set in the 802.11e standard), a single BA frame A number of protocol data units PDUs (up to 64 are set in the 802.11e standard), and a number of fragments (up to 16 are set in the 802.11e standard).

  FIG. 2 is a block diagram of an ARQ engine based on a bitmap according to an exemplary embodiment of the present invention. As illustrated in FIG. 2, the bitmap-based ARQ engine 100 may include an ARQ finite state machine FSM 110, an ARQ information comparator AIC 120, and / or a bitmap manager BM.

  In an exemplary embodiment, the AIC 120 may include a MAC address MA comparator 122 and / or a MAC address entry number and traffic ID (MA_EN / TID) comparison period 24.

  In an exemplary embodiment, the bitmap manager 130 can include a bitmap manager finite state machine BMFSM 132, a bitmap management information controller 134, and a bitmap memory 136.

  In an exemplary embodiment, the ARQ FSM 110 can exchange selective information, eg, MAC address, TID, sequence number, fragment number, and BA / ACK frame with a MAC controller. The ARQ FSM 110 may control decoding of the received frame to retrieve, update, and / or extract confirmation information to return either one of BA or ACK.

  The AIC 120 receives a search request from the ARQ FSM 110, compares the MAC address (for example, the MAC address is 48 bits) and the traffic ID (TIDS), and generates a hit / miss signal and bitmap entry information. Is possible. The AIC block 120 can be implemented with the same hardware used to implement the key search engine KSE with the safety function block, thereby reducing the hardware.

  The bitmap manager BM 130 can update or extract bitmap management information from the ARQ FSM 110 under control. The bitmap manager 130 may include a bitmap manager finite state machine BMFSM 132, a bitmap management information controller 134 and / or a bitmap memory 136.

  When the ARQ FSM 110 sends an update or extract request to the bitmap manager finite state machine BMFSM 132, the confirmation information in the bitmap memory 136 can be updated, operated and / or extracted by the BMFSM 132. The operation of BM 130 is described in more detail below.

  FIG. 3 is a flowchart illustrating an operation of the ARQ FSM according to an embodiment of the present invention. The ARQ engine based on the bitmap is included in the QoS access point QAP and the QoS station QSTA. The operation of the flowchart between the source and the recipient can also be applied to the operation between QoS AP and QoS STA and between stations.

  As illustrated in FIG. 3, initially, the ARQ FSM 110 may determine a frame tangible at S202, eg, QoS data Qdata, a block ACK request BAR, or a block ACK (BA).

  If the frame is a Qdata frame, the ARQ FSM 110 can determine whether the ACK policy is a block ACK (BA) policy from the selective information in the frame field received in S204. If the ACK policy is a block ACK (BA) policy, the ARQ FSM 110 sends a search request (in S206) to the AIC 120 to determine whether the entry has a matching MAC address MA and traffic ID (TID) combination. If the received search request is hit in S208, the bitmap memory 136 is updated in S210 corresponding to the new entry displayed with the bitmap entry number BTM_EN, the sequence number SN, and the fragment number FN.

  As shown in FIG. 3, if the received frame has a block ACK policy in S204, the update operation checks the cyclic redundancy code CRC of the frame in S206 to determine a confirmation bit for the received frame. It can also be completed from. The new bitmap management information BMI can be generated if the recipient receives the setting frame before the QoS data frame (not shown in FIG. 3).

  If the frame is a BAR frame, the ARQ FSM 110 can send a search request to the AIC 120 in S220 to determine whether the entry has a matching MAC address MA and traffic ID (TID) combination. If the entry indicates hit in S222, the ARQ FSM 110 can extract the confirmation information from the desired position in S224, and the bitmap memory 136 having BtM_EN and the start sequence number SSN prepares the BA frame in S226 and immediately stores the BA in S228. A BA frame can also be sent.

  If the entry indicates miss in S222, the ARQ FSM 110 prepares an ACK frame for the BA delayed in S230, sends an ACK frame in S232, and does not take any action to create the BA frame. However, after sending an ACK frame by ARQ FSM 110, the recipient prepares the BA frame in software.

  If the frame is a block ACK frame in the frame tangible check step S202, the ARQ FSM 110 determines whether the ARQ FSM 110 is waiting for a block ACK in S240. If the ARQ FSM 110 is waiting for a block ACK, the ARQ FSM 110 confirms the ACK in S242. If ARQ FSM 110 is not waiting for a block ACK frame at S240, ARQ FSM 110 ignores the BA frame.

  As described above, depending on the search result, the ARQ FSM 110 performs an update or extraction operation. If the negotiation is delayed ACK, the ARQ FSM 110 transmits an ACK frame. The determination of immediate ACL or delayed ACK can be made by AIC or KSE according to the result of hit / miss information.

  If the received frame is a BAR, a search operation can be performed by the AIC 120 in S222 to determine hit or miss. If the search result is hit, immediate ACK is selected and the corresponding bitmap memory data is extracted. BA is prepared and sent by ARQFSM 110.

  If the search result is miss, delayed ACK is selected and the ARQ FSM 110 sends an ACK frame. After ARQ FSM 110 analyzes the BAR frame and prepares the BA, ARQ FSM 110 sends the BA.

.
In the AP of FIG. 1, if the AP sends a BAR and the received frame is BA, the AP confirms the ACK frame. However, if the AP does not send a BAR and the received frame is BA, the AP ignores the BA as illustrated in S240.

  4a and 4b are diagrams illustrating a block ACK (BA) support method according to an embodiment of the present invention. As shown, FIGS. 4a and 4b are each outlined by a source and a recipient that can operate with immediate block ACK or delayed block ACK policies, respectively. In an exemplary embodiment, the frame tangible exchanged between source and recipient may include an additional block ACK request ADD_BA_Req and an additional block aACK response ADD_BA_Res, Qdata, BAR, BA, and a delete block ACK request DELETE_BA_Req. it can. Each of these frame tangibles can be transmitted or received by the source or recipient depending on whether the source or recipient operates under an immediate block ACK policy or a delayed block ACK policy. Each sender or recipient can also have a hierarchy of hardware, device drivers, and software components, with the software components being the most flexible. The exemplary embodiment of the present invention that follows will assign various tasks to hardware, device drivers, and software components to increase the flexibility of the resulting component or method.

  In an exemplary embodiment, the device driver processes all verification information and the bitmap array and sends a BA based on the stored bitmap. However, when the negotiation for the received frame becomes an immediate BA, the BA is completed by the ARQ engine. When the negotiation for the received frame results in a delayed BA, the device driver creates a BA frame and sends it alone. Figures 4a and 4b illustrate the action by a source or recipient in an exemplary embodiment.

  FIGS. 4a and 4b show that the ADD_BA_Req frame and the ADD_BA_Res frame are used between the sender and the receiver in the setup phase prior to the QoS data frame transmission.

  As shown in FIGS. 4a and 4b, the originating device driver DD adds the BA entry and then sends ADD_BA_Req to the recipient. The block ACK policy can be separated and set according to each recipient's policy. The ADD_BA_Req frame may include a TID, a block ACK policy, a transmission buffer size, and / or a timeout value as configuration variables.

  4a and 4b, if the recipient of the ADD_BA_Req frame implements an immediate BA policy, the recipient's device driver can set the bitmap after adding the BA entry. If the recipient implements a delayed BA policy, the recipient's device driver can add a BA entry. The recipient then sends ADD_BA_Res to the source regardless of the block ACK policy.

  In response to ADD_BA_Res, when the transmission source realizes the immediate BA policy and the construction is completed, the immediate BA that is a variable for indicating the block ACK policy can be set. In contrast, the immediate BA is not set once the source implements the delayed BA policy and its construction is complete.

  The sender can transmit the ACK policy as a block ACK to the recipient. In response, if the recipient implements an immediate block ACKBA policy, the recipient's hardware can be used to update the corresponding bitmap memory bits. If the recipient implements the delayed block ACK policy, the recipient's software can be used to update the corresponding bitmap memory bits.

  If the sender implements the immediate block ACK policy for the block ACK request, the immediate BA is set, so the timer is set to the block ACK size. If the source implements the delayed block ACK policy, the timer is set to the ACK size.

  In response, if the recipient implements an immediate block ACK policy, the recipient hardware extracts the corresponding bitmap memory bits, prepares a block ACK, and sends a block ACK. If the recipient implements the delayed block ACK policy, the recipient hardware transmits a BAR to the device driver that sends the ACK.

  If the recipient implements an immediate block ACK policy, once SIBAR is received, the hardware transmits a block ACK after the SIFS on the recipient side. If the recipient implements the delayed block ACK policy, the device driver transmits the BA during preparation.

  In response, if the source implements an immediate block ACK policy, the hardware on the source side transmits a block ACK to an upper layer, eg, a device driver, and does not respond to the ACK. When the source realizes the delayed block ACK policy, the hardware on the source side transmits a block ACK to the upper layer and responds to the ACK.

  When the service is completed or the inactivity time has expired, the device driver deletes the corresponding BA entry on the sender side and sends DELETE_BA_Req to the recipient. In response, the device driver on the recipient side deletes the relevant BA entry and sends DELETE_BA_Req, thereby ending the block ACK support method.

  When the transmission source receives DELETE_BA_Req, the device driver deletes the corresponding BA entry on the transmission side. In response, if the recipient implements an immediate block ACK policy, the device driver on the recipient side deletes the relevant BA entry and invalidates the relevant hardware bitmap. If the recipient implements the delayed ACK policy, the device driver deletes the BA entry on the recipient side.

  FIG. 5 is a diagram illustrating an ARQ information comparator AIC according to an embodiment of the present invention. As illustrated in FIGS. 2 and 5, the AIC 120 may include a MAC address MA comparator 122 and / or a MAC address entry number and traffic ID (MA_EN / TID) comparator 124. In an exemplary embodiment, the MAC address MA comparator 122 may also be implemented as a conventional key search engine KSE that includes a key memory 126, as illustrated in FIG.

  The MAC address MA comparator 122 may have a corresponding ARQ valid bit according to each MAC address. The ARQ valid bit indicates whether the corresponding MAC address has been negotiated as a block ACK. FIG. 5 shows a MAC address comparator implemented by a valid bit, a MAC address 311 entry, and an XNOR logic circuit 315.

  The MAC address MA comparator 122 receives the 48-bit MAC address, and determines whether the 48-bit MAC address corresponds to one of the entries of the MAC address MA comparator 122 (for example, one of 64 entries). . As a result of the MAC address comparison, the MAC address MA comparator outputs a hit / miss signal and the MAC address entry number MA_EN to the MA_EN / TID comparator. When the MAC address corresponds to one of the entries, the MAC address MA comparator 122 outputs a hit signal, a corresponding MA_EN, and a TID signal to the MA_EN / TID comparator 124. When the MAC address comparator outputs a miss signal, the MA_EN / TID comparator ignores the MA_EN and TID inputs, and the MA_EN / TID comparator 124 entry sets the MA_EN input value and TID value to the MA_EN / TID value and beyond. Do not compare. FIG. 5 shows the MA_EN / TID comparator implemented by the MA_EN bit, the MAC address 351 entry, and the XNOR logic circuit 355.

The MAC address MA comparator 122 can output a hit / miss signal and an MA_EN signal, which is the entry number of the MAC address entry in the MA_EN / TID comparator 124. In the above example, the number of MAC address entries is 64 bits. MA_EN signals TID signal, for example, is connected with the 4-bit TID signal (which is set to the maximum ^{2 4} or 16 in 802.11e standard), it is supplied to MA_EN / TID comparator 124.

  MA_EN / TID comparator 124 may include 64 entries, each entry including 6-bit MA_EN and 4-bit TID. The MA_EN / TID signal supplied by the MA comparator 122 is matched with one of the entries of the MA_EN / TID comparator 124, and the hit and 6-bit bitmap entry number BtM_EN are output to the BM 130.

  As described above, for example, the KSE for safety provided by the 802.11i standard can be used as the AIC 120. Only valid ARQ and TID related information can be attached to the exemplary embodiment of the present invention. The MAC address MA comparator and the MA_EN / TID comparator of the AIC 120 are implemented so as to be sequentially comparators by using a single port SRAM instead of a CAM (Content Addressable Memory) for stored information. This makes it easier to implement, prove, and reduce area and / or cost, for example, prototype hardware with FPGAs.

  Conventional conventions for 802.11 wireless communications generally support 64 entries for the key search engine KSE. The exemplary embodiment of the present invention can support up to 64 stations for an immediate BA for an AIC, and AIC can support up to 16 TIDs for a single entry, and overall supports 64 TIDs. Therefore, the ARQ engine can be configured so that each of the 64 stations has one TID, or each of the 4 stations has 16 TID. That is, the ARQ engine of the present invention has the flexibility to change the configuration dynamically.

  FIG. 6 is a diagram illustrating a bitmap manager BM 130 according to an embodiment of the present invention. As shown in FIGS. 2 and 6, the BM 130 may include a bitmap manager finite state machine BMFSM 132, a bitmap management information controller 134, and a bitmap memory 136. The bitmap management information BMI controller 134 receives the 6-bit bitmap entry number BTM_EN and the hit / miss signal from the AIC 120.

  As illustrated in FIG. 6, the bitmap management information controller 134 may include a number of entries, eg, 64 entries. Each entry is represented by, for example, a start standby flag SWF represented by 1 bit, for example, a start order number SSN represented by 12 bits, for example, a PDU field number NOP represented by 6 bits, and 11 bits, for example. Start memory address field SMA. The bitmap management information controller 134 can also include, for example, a 4-bit fragment field number NOF. The start standby flag SWF is a flag bit indicating the start of a new BA process. Each entry can have SWF, SSN, NOP, and SMA, and can also be stored in the BMI controller 134. NOF is used to indicate the number of current fragments of the bitmap, for example, to indicate PDU usage in the current network. The NOF can be stored in the BMI controller 134 separately from the entry information SWF, SSN, NOP and SMA. NOP is used to indicate the maximum number of PDUs negotiated. SMA indicates the physical address of the bitmap, and is calculated by NOF and NOP by an adder (not shown in FIG. 6) by a BMI controller.

  In an exemplary embodiment, NOF, NOP, and SMA can be controlled by software, and SWF and SSN can be controlled by hardware.

  When the bitmap operation information BMI controller 134 receives a hit signal having a special bitmap entry number, the BMI controller 134 uses the bitmap operation information to indicate the actual address in the bitmap memory as shown in FIG. Calculate

  The BMFSM 132 may perform search, update and / or extraction operations based on the ARQ FSM 110 request. Bitmap memory 136 may also be used to store block ACK data information.

  As illustrated in FIG. 6, the bitmap management information controller 134 can flexibly operate the bitmap memory 136 by recording the start storage address SMA of the bitmap memory 136. In an exemplary embodiment, the software may also be used to record the fragment number NOF, the PDI maximum negotiation number NOP, and the actual start address SMA of the bitmap memory 136 using both NOF and NOP. it can.

  FIG. 7 illustrates the flexibility of a bitmap memory, eg, BM 130, according to an exemplary embodiment of the present invention, assuming NOF is 8.

  As shown in FIG. 7, the bitmap operation information controller 134 negotiates the first entry, 0x0, with a maximum of 4 PDUs, and the bitmap operation information controller 134 has the second entry, 0x1, with a maximum of 16 PDUs. Negotiated. At the BM 130, the hardware can calculate the exact bitmap memory address for the search, update and / or extraction operations using the SMA, NOF, NOP, SSN, and the received frame sequence number SN and fragment number FN.

  In the exemplary embodiment of the present invention, the bitmap management information controller 134 supports 64 entries equal to the number of STAs, but the size of the bitmap memory supports 16 entries as a pair of 16 fragments and 64 PDUs. There are 2048 bytes.

  In an exemplary embodiment of the present invention, a smaller bitmap memory, eg 2048 bytes, can be used, but can be extended up to 16 using fragment / PDU pairs.

  FIG. 8 is a state diagram illustrating a finite state machine FSM of the bitmap manager BM, eg, the BMFSM 132 of FIGS. 2 and 5, according to an embodiment of the present invention.

  In the exemplary embodiment, BM FSM 132 begins in idle state 802. When the BMFSM 132 receives the request (search_req), the BM FSM 132 transitions to state 804 (search_MA) and searches for a MAC address entry to find an entry that matches the MAC address of the received frame. When the BMFSM 132 receives the search_MAdone signal from the AIC 120, the BMFSM 132 transitions to state 805 (search_TID), searches through the TID, generates the svc_done signal, and returns to the idle state 802.

  When the BMFSM 132 receives the update request update_req and SWF = 1, the BMFSM 132 changes to the state 806 (Update StartSeq) and updates the StartSeq. SWF = 1 means that the ARQ engine is waiting for the first BA policy frame, and then the BM FSM has an order control field including the fragment number and the start order number at the BMI controller when the ARQ engine receives the first BA policy frame. Indicates to update. When the update is complete, the BMFSM 132 transitions to state 808 and removes the bitmap memory 136. For a new BA policy frame, the bitmap manager BM needs to make room for the new BA frame. Once the bitmap memory 136 is removed, the BM FSM 132 transitions to state 810, calculates the update position, transitions to state 812, and updates the bitmap memory 136. The BMFSM 132 then transitions to state 814, removes the SWF flag, and returns to the idle state 802. Since a new BA process began with a new BA policy frame, the SWF flag bit is removed, transitioning to the idle state, and receiving the next frame.

  When the BMFSM 132 receives the update request update_req and SWF = 0, the BMFSM 132 changes to state 816 and reads StartSeq. When the reading is complete, the BMFSM 132 transitions to state 810, calculates the update position, transitions to state 812, and updates the bitmap memory 136. BMFSM 132 then transitions to state 814, removes the SWF flag, and returns to idle state 802. When the ARQ engine 100 receives the next frame after the BA processing starts, the bitmap manager 130 reads the sequence number stored from the BMI controller 134 and calculates the location of the destination address in the bitmap memory. Update the bitmap memory with the received frame. When the SWF flag bit is 0 for BA processing, the BMI controller 134 skips the Clear SWF operation.

  When BMFSM 132 receives the extract request extract_req, BMFSM 132 transitions to state 820 and reads StartSeq. When reading is complete, the BMFSM 132 transitions to state 822, calculates the reading position and transitions to state 824, and reads information from the calculated position. The BMFSM 132 subsequently changes to the state 826, sets the SWF flag to indicate the completion of the current BA processing, and returns to the idle state 802.

  FIG. 9 illustrates memory packing, eg, in a bitmap memory, according to an illustrative embodiment of the invention. As illustrated in FIG. 9, a flexible memory device may have a memory fragmentation problem. Dynamic memory allocation allows memory fragments in the bitmap memory to transition to multiple BA processes. Even if the total size of the memory portion remaining in the bitmap memory 136 is larger than the next candidate bitmap size, it cannot be inserted into the bitmap memory 136. If the ARQ engine has more memory for this memory fragmentation problem, the cost will increase.

  As illustrated in FIG. 9, the BMI controller 134 resolves memory fragmentation in software. When the BA processing is completed, if the unused portion is larger than the portion used by the remaining BA processing, another BA can be changed by changing the SMA value of the remaining BA processing in the BMI controller 136. The written memory part moves to a lower address of the unused part. With this memory packing scheme, the ARQ engine can use smaller memory and reduce costs.

  The exemplary embodiment of the present invention provides an effective block ACK method for the ARQ engine 100 based on a bitmap. The ARQ engine 100 can also use a key search engine KSE that supports a safety protocol such as IEEE802.11i, a wireless LAN protocol, and processes a BA policy for a received frame and performs an immediate BA in a SIFS cycle. Or it can respond to the delay BA. The ARQ engine 130 can search for an entry of information having a MAC address and TID matched with the received frame and generate an entry number for the hit / miss signal and BA response.

  The ARQ engine 100 can search, update and / or extract to process bitmap management information, and can also have SMA to respond to BA requests and flexible management of bitmap memory.

  Although terms such as first, second, etc. have been used to describe various components, it is clear that this component should not be limited by this term. This term is used to distinguish a single component from other components. Accordingly, the first component mentioned below should be able to be called the second component without departing from the concept of the present invention.

  It will be apparent to those skilled in the art that other variations and modifications can be made to the exemplary embodiments described above without departing from the scope of the invention, and all matters contained in the foregoing description are: It should be construed as an exemplary meaning rather than limiting its meaning.

It is a figure explaining the example of a timing request | requirement in the block ACK request | requirement of related technology by the Example of this invention. 3 is a block diagram of an ARQ engine based on a bitmap according to an embodiment of the present invention. 3 is a flowchart illustrating an operation of an ARQFSM according to an embodiment of the present invention. 6 is a chart showing a block ACK (BA) support method according to an embodiment of the present invention. 6 is a chart showing a block ACK (BA) support method according to an embodiment of the present invention. FIG. 3 illustrates an ARQ information comparator (AIC) according to an embodiment of the present invention. FIG. 3 is a diagram illustrating a bitmap manager according to an embodiment of the present invention. FIG. 4 is a diagram illustrating the flexibility of a bitmap manager (BM) according to an embodiment of the present invention. FIG. 4 is a state diagram of a bitmap manager (BM) finite state machine FSM according to an embodiment of the present invention. FIG. 4 is a diagram illustrating memory packing according to an embodiment of the present invention.

Explanation of symbols

100 ARQ Engine 110 ARQ Finite State Machine 120 ARQ Information Comparator 122 MAC Address Comparator 124 MAC Address Entry Number and Traffic ID Comparator 130 Bitmap Manager 132 Bitmap Manager Finite State Machine 134 Bitmap Operation Up Controller 136 Bitmap Memory

Claims (23)

A bitmap memory for storing block confirmation of received frames based on the bitmap;
A bitmap management information controller for storing a bitmap entry number and receiving bitmap management information associated with a physical address of the bitmap memory;
A bitmap manager finite state machine (BM FSM) that receives an update or extraction request for the received frame, handles the bitmap management information, and updates or extracts the bitmap memory; Bitmap manager.   The bitmap operation information includes the number of protocol data units negotiated (NOP), the start address (SMA) of the bitmap memory, and the number of fragments (NOF) in each protocol data unit (PDU). The bitmap manager according to claim 1.   The bitmap management information controller calculates a start address (SMA) of the bitmap memory using the number of protocol data units negotiated (NOF) with the number of protocol data unit fragments (NOF). The bitmap manager according to claim 1.   The bitmap memory is free, having a lower address than the remaining block confirmation portion after transmitting a block confirmation frame or one ACK frame in response to a received block confirmation request (BAR) frame The bitmap manager according to claim 1, wherein the remaining block confirmation part is moved to a part.   5. The bitmap manager of claim 4, wherein software handles position changes for the remaining block confirmation portion.   5. The bit of claim 4, wherein the bitmap management information controller changes the start address in the bitmap memory associated with a change in the start address of the moved bitmap memory portion. Map manager.   The bitmap manager according to claim 1, wherein the update or extraction of the bitmap management information or the bitmap memory is executed in all block confirmation BA processes.   The bitmap manager according to claim 1, wherein the bitmap management information controller further includes a start standby flag (SWF) and a start sequence number (SSN).   The bitmap FSM sets the start wait flag (SWF) at the beginning of each block confirmation BA process, and removes the start wait flag (SWF) at the end of each block confirmation (BA) process. The bitmap manager according to claim 8.   The bitmap manager of claim 1, wherein the received frame has a block confirmation policy. As the step of negotiating the tangible nature of the block confirmation with the second network component, the second network element comprises an immediate block confirmation or a delayed block confirmation;
Negotiating the amount of data to be transmitted;
Changing the bitmap entry or confirmation information of the first network component for the second network component based on the amount of data transmitted and the tangible of block confirmation;
A method for allocating a bitmap memory of a first network component. The first network component includes software, device drivers and hardware, the first network component is an originator, and the second network component is a recipient;
The device driver of the first network component sends a block confirmation request to the second network component;
The hardware of the first network component receives an immediate block confirmation or a delayed block confirmation from the second network element;
The first network component sets a timer based on the block confirmation policy;
The hardware of the first network component receives a block confirmation and communicates the block confirmation to the device driver and the software;
The device driver of the first network component erases a block confirmation and deletes the block confirmation request;
The method of allocating a bitmap memory of a first network component according to claim 11. The first network component includes software, device drivers and hardware, the first network component is a recipient, and the second network component is a source;
The device driver of the first network component adds a block confirmation entry or the confirmation information and dynamically allocates a predetermined portion of the bitmap memory;
The first network component sends a block confirmation in response to the second network component;
The hardware of the first network component updates the portion of the bitmap memory;
When the first network component receives a block confirmation request, the hardware of the first network component extracts a corresponding bit from the bitmap memory, generates a block confirmation, and generates the block confirmation. To the second network component,
The device driver of the first network component deletes the block confirmation and deletes the block confirmation request;
The method of allocating a bitmap memory of a first network component according to claim 11. An automatic repeat request finite state machine (ARQFSM) that receives frames from other network components, decodes selective information from the received frames, and returns block confirmation or confirmation frames to other network components;
An ARQ information comparator that compares the selective information of the received frame with stored entry information to determine a confirmation policy;
A bitmap manager for storing block confirmation bits and bitmap operation information according to the confirmation policy;
A network component characterized by comprising:   The network component of claim 14, wherein the bitmap manager includes a memory for storing the block confirmation bits based on a bitmap.   The ARQ information comparator includes a MAC address (MA) comparator, and the MAC address (MA) comparator is based on a key search engine (KSE) for secure wireless communication. The network component described. The ARQ information comparator is
A MAC address (MA) comparator that retrieves a MAC address entry number (MA_EN) of a MAC address matched with the MAC address of the received frame;
The MAC address entry number and the traffic ID (search for the bitmap entry number (BtM_EN) of the bitmap management information (BMI) matched with the MAC address entry number (MA_EN) and the traffic ID (TID) from the MAC address comparator. MAC_EN / TID) comparator,
The network component according to claim 14, comprising:   The MAC address entry and traffic ID comparator searches the bitmap entry number (BtM_EN) in bitmap management information when the MAC address entry number (MA_EN) hits (hit). Network components described in. Retrieving stored selective information matched with selective information from the received frame, generating a hit / miss signal, and determining a tangible form of the block confirmation;
Updating the bitmap management information and the bitmap memory upon hitting the selective information;
Generating a block confirmation or confirmation frame from the bitmap memory according to the bitmap management information;
A method for generating a confirmation between network components, comprising:   20. The method for generating confirmation between network components according to claim 19, wherein the confirmation bits are stored based on a bitmap type indicating one confirmation bit per received frame.   20. A method for generating confirmation between network components according to claim 19, wherein the tangible form of confirmation for the received frame is determined by the key search engine (KSE) for security of wireless communication. . Determining the tangible form of the block confirmation comprises:
Searching for a MAC address entry number (MA_EN) matched with a MAC address (MA) of the received frame to generate a hit / miss signal for searching for the MAC address entry number (MA_EN);
When the MAC address entry number (MA_EN) hits (hit), the bitmap entry number (BtM_EN) matched with the MAC address entry and the number traffic ID (MA_EN / TID) is searched, and the bitmap entry number (BtM_EN) ) Generating a hit / miss signal for the search of
20. The method for generating a confirmation between network components according to claim 19, further comprising:   A step of generating a block confirmation frame at the time of searching for the bitmap entry number (BtM_EN) of the bitmap management information (BMI) matched with the MAC address entry number (MA_EN) and the traffic ID (TID) The method for generating a confirmation between network components according to claim 22, further comprising:

Images