communication equipment

Abstract

To provide a technique to achieve efficient acknowledgement control in communication using a plurality of links.SOLUTION: A communication device conforms to the IEEE802.11 standard series, and the communication device transmits a plurality of data frames to a communication partner device by using a plurality of links, transmits, to the communication partner device, a request frame for requesting an acknowledgement (Ack) frame for the plurality of transmitted data frames, and in response to the transmission of the request frame, receives the Ack frame from the communication partner device. The request frame includes sequence information on the sequence numbers of the plurality of data frames transmitted with each link of the plurality of links. The sequence information includes specification information for specifying one or more data frame groups obtained by classifying the plurality of data frames transmitted with each link into every series of data frames having consecutive sequence numbers.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to wireless communication technology. [Background technology]

[0002] The IEEE802.11 series is known as a wireless LAN (Local Area Network) communication standard established by the IEEE (Institute of Electrical and Electronics Engineers). The IEEE802.11 series standards include the IEEE802.11a / b / g / n / ac / ax standards (Patent Document 1).

[0003] The IEEE802.11ax standard discloses an extended specification for the BlockAck frame, which enables the transmission of acknowledgements (ACKs) in a single frame for the reception of multiple wireless packets. The IEEE802.11ax standard discloses a specification that expands the number of MPDUs (Media Access Control (MAC) Protocol Data Units) that can be expressed in the BlockAck Bitmap in the BlockAck frame from 64 (up to IEEE802.11ac) to 256. Increasing the number of MPDUs that can be acknowledged at one time improves throughput. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2018-50133 Summary of the Invention [Problem to be solved by the invention]

[0005] To further improve throughput and frequency utilization efficiency, the IEEE is considering the formulation of the IEEE802.11be standard as a new standard in the IEEE802.11 series. The IEEE802.11be standard proposes expanding the number of MPDUs that can be acknowledged at one time to 512 or 1024. The IEEE802.11be standard also considers methods such as Multi-Link communication, which uses multiple wireless links between wireless devices, and Multi-AP communication, which connects multiple wireless access points to a single wireless terminal for communication, and is also considering methods for acknowledging communications across multiple links.

[0006] When wireless devices communicate using multiple links, it is assumed that the transmitting device will transmit data frames with different sequence numbers on each link. In this case, the receiving device may receive data frames with missing sequence numbers on each link. Conventionally, no efficient acknowledgment method has been proposed for such a case.

[0007] In view of the above-mentioned problems, an object of the present invention is to provide a technique for realizing efficient acknowledgement control in communications using multiple links. [Means for solving the problem]

[0008] In order to achieve the above object, a wireless communication device according to one aspect of the present invention has the following configuration: That is, the wireless communication device is compliant with the IEEE 802.11 standard series, A first plurality of data frames on a first link and a second plurality of data frames on a second link. The communication partner Looking ahead a first transmitting means for transmitting the First plurality of for a data frame 1st Request an Acknowledgment (Ack) frame 1st Request Frame and a second request frame requesting a second Ack frame for the transmitted second plurality of data frames. The communication partner Looking ahead a second transmitting means for transmitting the First and second In response to transmitting a request frame, the communication partner destination From the above First and second receiving means for receiving an Ack frame, First and second Request Frame Each of is the above First and second including sequence information regarding sequence numbers of a plurality of data frames transmitted on each link of the link; Included in each of the first and second request frames The sequence information includes identification information for identifying one or more data frame groups distinguished by a series of data frames having consecutive sequence numbers among the plurality of data frames transmitted on each link. The specific information includes information on the start sequence number and the end sequence number of a series of data frames in each data frame group transmitted on each link. . [Effects of the Invention]

[0009] According to the present invention, efficient acknowledgement control is realized in communications using multiple links. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example of a network configuration. [Figure 2] An example of the hardware configuration of a communication device (STA, AP) is shown below. [Figure 3] 1 shows an example of the functional configuration of a communication device (STA, AP). [Figure 4] 1 shows a communication sequence diagram for data communication between an AP and a STA. [Figure 5] The structures of the BlockAck Request frame and the BlockAck frame are shown below. [Figure 6] Configuration examples 1 to 3 of the ACK Info subfield are shown below. [Figure 7] Configuration examples 4 to 6 of the ACK Info subfield are shown below. [Figure 8] 10 is a flowchart of a frame transmission process by a data frame transmitting side. [Figure 9] 10 is a flowchart of a data frame generation and transmission process. [Figure 10] 10 is a flowchart of a BAR frame generation and transmission process. [Figure 11] 10 is a flowchart of a frame reception process by a data frame transmitting side. [Figure 12] 10 is a flowchart of a BA frame reception process. [Figure 13] 10 is a flowchart of a frame reception process by a data frame receiving side. [Figure 14] 10 is a flowchart of a sequence number confirmation process. [Figure 15] 10 is a flowchart of a BA frame generation and transmission process. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention claimed. Although multiple features are described in the embodiments, not all of these multiple features are necessarily essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same reference numerals are used to designate the same or similar components, and redundant explanations will be omitted.

[0012] (Network configuration) Fig. 1 shows an example of a network configuration according to this embodiment. Fig. 1 shows a configuration including one AP (Access Point) (AP 102) and one STA (Station / Terminal Device) (STA 103) as communication devices (wireless communication devices). Note that the description of this embodiment is applicable to both the AP and the STA, and is not limited to either one. As shown in Fig. 1, the network formed by AP 102 is indicated by a circle 101.

[0013] In this embodiment, the STA 103 is assumed to be able to transmit and receive frames to and from the AP 102 via wireless links 104 and 105. The wireless links 104 and 105 can use channels in the 2.4 GHz, 5 GHz, and 6 GHz frequency bands, but the frequency bands used are not limited to these and other frequency bands, such as the 60 GHz band, may also be used. Depending on the capability information of the multi-link communication between the STA 103 and the AP 102, the wireless links 104 and 105 may use a combination of channels in the 2.4 GHz band and the 5 GHz band, or may select and combine multiple channels from the 6 GHz band. This embodiment can also be applied to multi-AP communication, which handles communication between multiple APs and one STA. This embodiment will be described using two wireless links, the wireless links 104 and 105, but this is not limited to this and the embodiment can also be applied to cases where three or more links are used.

[0014] The network configuration shown in FIG. 1 is an example, and the following discussion can be applied to a network including many communication devices in a wider area, and to the positional relationships of various communication devices.

[0015] (Configuration of communication device) Next, the configuration of a communication device (AP, STA) according to this embodiment will be described. Fig. 2 shows an example of the hardware configuration of an AP according to this embodiment. As an example of its hardware configuration, the AP has a storage unit 201, a control unit 202, a function unit 203, an input unit 204, an output unit 205, one or more communication units 206, and one or more antennas 207. Note that a STA also has a hardware configuration similar to that of an AP, and the following description can be applied to the STA.

[0016] The storage unit 201 is configured with either or both of a ROM (Read Only Memory) and a RAM (Random Access Memory), and stores various information such as programs for performing various operations described below and communication parameters for wireless communication. Note that, in addition to memories such as ROM and RAM, the storage unit 201 may also use storage media such as a flexible disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a non-volatile memory card, or a DVD.

[0017] The control unit 202 is configured by, for example, a processor such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), etc. The control unit 202 controls the entire AP by executing a program stored in the storage unit 201. Note that the control unit 202 may also control the entire AP in cooperation with the program stored in the storage unit 201 and an OS (Operating System).

[0018] The control unit 202 controls the functional unit 203 to perform predetermined processing such as capturing images, printing, and projection. The functional unit 203 is hardware that enables the AP to perform predetermined processing. For example, if the AP is a camera, the functional unit 203 is an imaging unit that performs imaging processing. Also, for example, if the AP is a printer, the functional unit 203 is a printing unit that performs printing processing. Also, for example, if the AP is a projector, the functional unit 203 is a projection unit that performs projection processing. The data processed by the functional unit 203 may be data stored in the storage unit 201, or may be data communicated with another communication device via the communication unit 206, which will be described later.

[0019] The input unit 204 receives various operations from the user. The output unit 205 outputs various types of information to the user. Here, the output by the output unit 205 includes at least one of display on a screen, audio output by a speaker, vibration output, etc. Note that both the input unit 204 and the output unit 205 may be implemented by a single module, such as a touch panel.

[0020] The communication unit 206 controls wireless communication compliant with the IEEE 802.11 standard series and IP communication. In this embodiment, the communication unit 206 can execute processing compliant with at least the IEEE 802.11ax standard. The communication unit 206 also controls the antenna 207 to transmit and receive wireless signals for wireless communication. The AP communicates content such as image data, document data, and video data with other communication devices via the communication unit 206.

[0021] The wireless antenna 207 is an antenna capable of receiving any of the sub-GHz band, 2.4 GHz band, 5 GHz band, and 6 GHz band, and may be physically configured with one or more antennas to realize MIMO (Multi-Input Multi-Output) transmission and reception.

[0022] When an AP communicates using multiple links, it may be provided with multiple communication units 206 and multiple antennas 207 as shown in Fig. 2 (as an example, Fig. 2 shows two communication units 206 and two antennas 207). In this case, one communication unit 206 and one antenna 207 may be assigned to each wireless link, or one communication unit 206 and one antenna 207 may be shared by multiple links.

[0023] 3 shows an example of the functional configuration of an AP according to this embodiment. As an example of its functional configuration, the AP has a frame analysis unit 301, a frame generation unit 302, a connection management unit 303, and a frame transmission / reception unit 304. Note that a STA also has a functional configuration similar to that of an AP, and the following description can be applied to the STA.

[0024] The frame analysis unit 301 analyzes frames received from a communication partner device (opposing communication device). The frame generation unit 302 generates frames (wireless frames) to be transmitted to the communication partner device. The connection management unit 303 manages connections with the communication partner device. For example, the connection management unit 303 manages the BlockAck (BA) agreement and data sequence number during the connection for each communication partner device. The BlockAck Agreement and Sequence Number are managed for each TID (Traffic Identifier (identifier indicating the type of traffic (data))) within the connection. The frame transmission / reception unit 304 transmits and receives frames to and from the communication partner device via the communication unit 206 and antenna 207 (FIG. 2).

[0025] (Communication sequence between AP and STA) 4 shows a communication sequence diagram for data communication between AP 102 and STA 103. The processing of this sequence can be started in response to the power being turned on for AP 102 and STA 103. Alternatively, the processing of this sequence can be started in response to an instruction from a user or application to at least one of AP 102 and STA 103 to start wireless communication. Here, the description will be given assuming that two wireless links 104 and 105 are configured between AP 102 and STA 103 as shown in FIG. 1.

[0026] First, in F401, the AP 102 and the STA 103 establish a wireless connection by performing a secondary connection process according to the IEEE 802.11 standard. This embodiment is applicable to both unencrypted and encrypted communications. Furthermore, this embodiment is also applicable to encrypted communications using encryption methods (security methods) such as Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA) 1, WPA2, WPA3, Wi-Fi Protected Setup (WPS), or other methods. The connection may be established only through one representative link (e.g., link 104), with the other link also established as a secondary connection, or each link may establish a connection independently.

[0027] This example shows data transmission from AP 102 to STA 103. After connection is established in F401, AP 102 transmits an ADDBA Request frame to STA 103 in F402 and receives an ACK frame as an acknowledgment in F403. Next, STA 103 transmits an ADDBA Response frame to AP 102 in F404 and receives an ACK frame as an acknowledgment in F405. When the exchange of ADDBA Request and ADDBA Response (processing in F402 to F405) is complete, a BlockAck Agreement is established between AP 102 and STA 103 regarding data transmission from AP 102 to STA 103. The establishment of a BlockAck Agreement may be performed independently for each link, or may be performed only on one representative link (e.g., link 104) and then secondary established on the other link.

[0028] Here, we will explain BlockAck Agreement. The ADDBA Request frame and ADDBA Response frame contain a BlockAckPolicy parameter, and a communication device that receives the frame transmits an ACK frame if it agrees with the parameter. The BlockAckPolicy parameter is set to Immediate (Immediate BlockAck) or Delay (Delayed BlockAck). The example in Figure 4 shows the case where the Immediate setting is used, in which the AP 102 transmits a BlockAck Request (BAR) frame as a request frame, and the STA 103, upon receiving the frame, replies with a BlockAck frame. On the other hand, if the BlockAckPolicy is set to Delayed (not shown), the STA 103 replies with an ACK frame (instead of replying with a BlockAck frame in F408). The STA 103 then transmits a BlockAck frame during the TXOP (Transmission Opportunity) period that it acquires.

[0029] The ADDBA Request frame also contains various parameters (e.g., Starting Sequence Number) for information (Starting Sequence Control) about the starting number of data to be transmitted in one BA session. The initial value of the Starting Sequence Number can be determined through the ADDBA Request / Response exchange. Subsequent updates of the Starting Sequence Number can follow the method specified in the IEEE 802.11 standard.

[0030] The ADDBA Request / Response frame may also include the BA Type / BAR Type supported by the device itself. For example, the frame may include information on whether or not the device supports New BA / New BAR, which will be described later with reference to Figures 5 to 7 (it may also include information on whether or not the device supports one or more of Configuration Examples 1 to 7, which will be described later). The communication device that receives the frame records and manages the BA Type / BAR Type supported by the communication partner device.

[0031] In this embodiment, the connection management unit 303 of each of the AP 102 and the STA 103 records and manages the above-mentioned various parameters and information for the TID in the storage unit 201 when establishing a BlockAck Agreement.

[0032] After the BlockAck Agreement is established, the AP 102 can transmit multiple data frames before receiving an ACK frame from the STA 103, which is the communication partner device (opposing communication device). For example, the AP 102 transmits multiple MPDUs (data frames) in F406 (data transmission process), and the STA 103 transmits a BlockAck frame in F408 as an acknowledgment of the multiple MPDUs. As described above, the example in FIG. 4 is a case where the BlockAckPolicy parameter is set to Immediate. After the AP 102 transmits a BlockAck Request frame (F407) (in response to the transmission), the STA 103 replies with a BlockAck frame (F408).

[0033] The transmission of the BlockAck Request frame (F407) and the reply of the BlockAck frame (F408) may be performed independently for each link, or may be performed only on one representative link (e.g., link 104). In this case, the information carried on the representative link may include information for the other link.

[0034] In the example of FIG. 4, the AP 102 transmits a BlockAck Request frame to the STA 103 in F407. Alternatively, the AP 102 may set the Ack Policy subfield included in the QoS Control field in at least one of the MPDUs in F406 to Implicit BlockAck Request. That is, the AP 102 may include an Implicit BlockAck Request (request information) in at least one of the MPDUs, requesting a BlockAck frame from the STA 103. This allows the AP 102 to request a BlockAck frame from the STA 103 without transmitting a BlockAck Request frame (F407). In this case, the transmission of the Implicit BlockAck Request and the return of the BlockAck frame may be performed independently for each link, or may be performed only via one representative link (e.g., link 104). In this case, information for the other link may be included in the information carried via the representative link.

[0035] The BlockAck frame returned in F408 contains information set based on the sequence number of the data frame transmitted in F406. In the conventional 802.11 specification, the sequence numbers returned in the BlockAck frame were assumed to be consecutive. For example, the BlockAck Bitmap was used to indicate whether or not a data frame (packet) with a number of bits that can be represented by the BlockAck Bitmap, starting from the Starting Sequence Number, was received. This poses a problem when data is transmitted over multiple links, as in the sequence shown in Figure 4. For example, consider a case where a data transmitting device transmits data with sequence numbers 1 and 3 over link 104 and data with sequence numbers 2 and 4 over link 105. In this case, the data receiving device cannot receive data with sequence numbers 2 and 4 over link 104, nor data with sequence numbers 1 and 3 over link 105. Therefore, the receiving device will represent these sequence numbers as lost frames in the BlockAck Bitmap. In each link, data with a sequence number represented as a lost frame is expected to be retransmitted by the transmitting device even though it has been transmitted on another link, resulting in unnecessary bandwidth consumption due to retransmissions.

[0036] In this embodiment, the data transmitting device is configured to operate so that at least one data frame set in a BlockAck Request frame or an Implicit BlockAck Request includes information on the sequence numbers of data that has been transmitted / not transmitted on each link. Note that the following description will be given using a BlockAck Request frame as an example, but the same description can also be applied to an Implicit BlockAck Request. Furthermore, the data receiving device is configured to operate so that at least one data frame set in a BlockAck Request frame includes information on the sequence numbers of data that has been received / not received on each link.

[0037] (Structure of BlockAck Request frame and BlockAck frame) Next, the configurations of the BlockAck Request frame and the BlockAck frame will be explained. Note that while an example of data transmission from the AP 102 to the STA 103 is shown in Fig. 4, the following explanation is similarly applicable to data transmission from the STA 103 to the AP 102.

[0038] Figures 5(a) to 5(c) show the configuration of BlockAck Request frames and BlockAck frames in the 802.11ax standard. Figures 5(a) to 5(c) share the following in common: Octets and Bits indicate the size of each field. Fields marked "variable" mean that they are variable length. The (R) in the figures indicates that the field is valid for BlockAck Request frames and invalid for BlockAck frames. Fields without reference symbols will not be explained.

[0039] 5(a) shows the overall structure of a BlockAck Request frame and a BlockAck frame, which are made up of a MAC header field 501, a BA(R) Control field 502, a BA Information field 503, and an FCS field.

[0040] 5(b) shows the configuration of the BA(R) Control field 502. The BA(R) Control field 502 is composed of a BA(R) Ack Policy subfield, a BA(R) Type subfield 504, a Reserved subfield 505, and a TID_INFO subfield. The format of the BA(R) Information field 503 is defined according to the information set in the BA(R) Type subfield 504. In the IEEE802.11ax standard, BA(R) Types 0, 4 to 5, 7 to 9, and 11 to 15 are designated as Reserved areas, and in this embodiment, at least one of these Reserved areas is used to define a new BA(R) Type. The new BA(R) Type proposed in this embodiment is referred to as New BA(R).

[0041] 5(c) shows the configuration of the BA(R) Information field 503 defined in New BA(R). The BA(R) Information field 503 is composed of a BA(R) Subtype subfield 507 and an ACK Info subfield 506. The BA(R) Subtype subfield 507 may be set to 0, as described in Bits. In this case, information corresponding to the BA(R) Subtype may be expressed using a Reserved area in the BA(R) Type subfield 504 or a Reserved area in the Reserved subfield 505. Note that the names of BA(R) Subtype and ACK Info presented here are merely examples and are not limiting.

[0042] (ACK Info subfield configuration) Some configuration examples of the ACK Info subfield 506 (sequence information) in Fig. 5(c) in this embodiment will be described using Fig. 6 and Fig. 7. Note that the names, sizes, and storage order of each part described below are merely examples, and are not limited to these as long as they perform similar functions. The following description will be given using the BlockAck Request frame transmitted by AP 102 (data transmitting device) as an example.

[0043] <<Configuration of the ACK Info subfield indicating the transmitted MPDU (Configuration Examples 1 to 3)>> 6(a) to 6(c) show configuration examples 1 to 3 of the ACK Info subfield 506. The ACK Info subfield 506 shown in configuration examples 1 to 3 is stored in a BlockAck Request frame. Configuration examples 1 to 3 are configuration examples when transmitting information related to an MPDU (data frame) transmitted by the AP 102. As a configuration common to configuration examples 1 to 3, the ACK Info subfield 506 is composed of an ACK Info header section (corresponding to ACK Info header sections 601, 607, and 614) containing meta information of the entire ACK Info, and an ACK Info data section containing specific information (corresponding to frame groups 602, 603, 609, 610, 615, and 616) that identifies the transmitted frame group (data frame group). Note that the names ACK Info header and ACK Info data shown here are merely examples and are not limited to these.

[0044] The AP 102 classifies the data transmitted to the STA 103 for each link into a series of data chunks with consecutive sequence numbers as frame groups. In other words, if a gap occurs in the sequence number of the transmitted data, the frame group is separated at that point. By including information about all transmitted frame groups in the ACK Info subfield 506, it is possible to provide information about frames for which an acknowledgment is requested to the STA 103. The STA 103 only needs to transmit an acknowledgment for the requested frame. The data length included in the ACK Info header section may or may not include the data length of the ACK Info header section.

[0045] <Configuration example 1> 6(a) shows a first configuration example of the ACK Info subfield 506. The ACK Info header section 601 in the first configuration example includes information indicating the data length included in the ACK Info data section (the data length of the information specifying all subsequent frame groups). This information may be information indicating the end of a data frame group. As a method for indicating the data length, the data length of the subsequent ACK Info section may be stored in units of bits, bytes, or the number of frame groups (in this example, one frame group has a 24-bit configuration). However, this method is not limited to this, as long as the data length can be indicated.

[0046] In IEEE802.11, a sequence number is represented by 12 bits and is expressed as a value from 0 to 4095. In configuration example 1, a start sequence number (Start SN) 604 and an end sequence number (End SN) 605 for each frame group are used to represent frame groups 602 and 603. The start sequence number 604 and the end sequence number 605 can each be represented by 12 bits. The start sequence number 604 indicates the sequence number of the MPDU corresponding to the start of each transmission frame group. The end sequence number 605 indicates the sequence number of the MPDU corresponding to the end of each transmission frame group.

[0047] <Configuration example 2> 6(b) shows a second configuration example of the ACK Info subfield 506. The ACK Info header section 607 in the second configuration example includes information indicating the data length included in the ACK Info data section, as in the first configuration example. The data length can be indicated by storing the data length of the subsequent ACK Info section in units of bits, bytes, or the number of frame groups (in this example, a configuration of 12 + the number of bits indicated by the Count Size section 608 per frame group). However, this method is not limited as long as the data length can be indicated. In the second configuration example, the ACK Info header section 607 further includes a Count Size section 608. The Count Size section 608 indicates the size of the Count section (corresponding to the Count section 612) of the frame groups 609 and 610.

[0048] In configuration example 2, frame groups 609 and 610 are represented using a start sequence number (Start SN) 611 and a Count field 612 for each frame group. As in configuration example 1, the start sequence number 611 indicates the sequence number of the MPDU corresponding to the beginning of each transmission frame group. The Count field 612 holds information indicating the number of MPDUs with consecutive sequence numbers starting from the start sequence number 611 that have been transmitted. If the size of the Count field specified in the Count Size field 608 is small, the maximum number of MPDUs that can be represented as a frame group is small, but the data length required to represent one frame group can be reduced. On the other hand, if the size of the Count field specified in the Count Size field 608 is large, the maximum number of MPDUs that can be represented as a frame group is large, but the data length required to represent one frame group is large. The use of a Count Size is not limited in this example. The start sequence number can be represented using 12 bits.

[0049] In this configuration example, the upper limit of the number of MPDUs that can be represented in one frame group is defined by the Count Size section 608, so even MPDUs with consecutive sequence numbers may be represented as separate frame groups.

[0050] <Configuration example 3> FIG. 6(c) shows a third configuration example of the ACK Info subfield 506. Similar to the first configuration example, the ACK Info header section 614 in the third configuration example includes information indicating the data length included in the ACK Info data section. The data length can be indicated by storing the data length of the following ACK Info section in units of bits, bytes, or the number of frame groups (in this example, 16 per frame group + the number of bits indicated by the Count Size section of each frame). Note that this method is not limited to this, as long as the data length can be indicated. In the third configuration example, the frame groups 615 and 616 are represented using a start sequence number (Start SN) 617, a Count Size section 618, and a Count section 619. The Count Size section 608 stored in the ACK Info header section 607 in the second configuration example is stored in each frame group as the Count Size section 618. This makes it possible to set an appropriate Count Size for each frame group without fixing the Count Size in the header section. An appropriate Count Size can be set by setting a large Count Size if the number of frames to be represented in the frame group is large, and by setting a small Count Size if the number of frames to be represented is small.

[0051] <<Configuration of ACK Info subfield indicating unsent MPDU (Configuration Examples 4 to 6)>> 7(a) to 7(c) show configuration examples 4 to 6 of the ACK Info subfield 506. The ACK Info subfield 506 shown in configuration examples 4 to 6 is stored in a BlockAck Request frame transmitted from the data frame transmitter. Configuration examples 4 to 6 are configuration examples when transmitting information about an MPDU that the AP 102 has not transmitted. As a common configuration to configuration examples 4 to 6, the ACK Info subfield 506 is composed of an ACK Info header section (corresponding to the ACK Info header sections 721, 724, and 727) that includes meta information about the entire ACK Info, and an ACK Info data section that includes specific information that identifies the transmitted frame group (data frame group) (corresponding to frame groups 702, 703, 709, 710, 715, and 716). Note that the names ACK Info header and ACK Info data shown here are merely examples and are not limited to these.

[0052] For each link, the AP 102 classifies data that has not been transmitted to the STA 103 into a series of data chunks with consecutive sequence numbers as a frame group. In other words, if a gap occurs in the sequence number of data that has not been transmitted, the frame group is separated at that point. By including information about all frame groups that have not been transmitted in the ACK Info subfield 506, it is possible to provide the STA 103 with information about frames for which an acknowledgment response is requested. The STA 103 simply transmits an acknowledgment response for the requested frames.

[0053] Configuration examples 4 to 6 differ from configuration examples 1 to 3 in that the ACK Info header section includes information indicating the start sequence number and end sequence number of a newly transmitted frame group. This is because in configuration examples 4 to 6, the ACK Info data section includes information about MPDUs that have not been transmitted, and it is not possible to identify the start and end sequence numbers of the transmitted sequence numbers based on this information alone. By combining the information indicating the start sequence number and end sequence number of a frame group expressed by the ACK Info subfield 506 as a whole with the sequence number of an MPDU that has not been transmitted, it is possible to identify the sequence number of a transmitted MPDU. The data length included in the ACK Info header section may or may not include the data length of the ACK Info header section.

[0054] <Configuration Example 4> 7(a) shows a fourth configuration example of the ACK Info subfield 506. The ACK Info header section 721 in the fourth configuration example includes information 701 indicating the data length included in the ACK Info data section. This information may be information indicating the end of a data frame group. As a method for indicating the data length, the data length of the subsequent ACK Info section can be stored in units of bits, bytes, or the number of frame groups (in this example, one frame group has a 24-bit configuration). However, this method is not limited to this, as long as the data length can be indicated.

[0055] In IEEE802.11, a sequence number is represented by 12 bits and is expressed as a value from 0 to 4095. In configuration example 4, a start sequence number (Start SN) 704 and an end sequence number (End SN) 705 for each frame group are used to represent frame groups 702 and 703. The start sequence number 704 and the end sequence number 705 can each be represented by 12 bits. The start sequence number 704 indicates the sequence number of the MPDU corresponding to the start of each untransmitted frame group. The end sequence number 705 indicates the sequence number of the MPDU corresponding to the end of the untransmitted frame group. In configuration example 4, the ACK Info header section 721 includes a start sequence number 722 and an end sequence number 723 for the transmitted frame group.

[0056] <Configuration example 5> 7(b) shows a fifth configuration example of the ACK Info subfield 506. The ACK Info header section 607 in the fifth configuration example includes information indicating the data length included in the ACK Info data section, as in the fourth configuration example. The data length can be indicated by storing the data length of the following ACK Info section in units of bits, bytes, or the number of frame groups (in this example, 12 per frame group + the number of bits indicated by the Count Size section 708). Note that this method is not limiting as long as the data length can be indicated. In the fifth configuration example, the ACK Info header section 724 further includes a Count Size section 708. The Count Size section 708 indicates the size of the Count section (corresponding to the Count section 712) of the frame groups 709 and 710, as well as the size of the Count section 726 included in the ACK Info header section 724.

[0057] In configuration example 5, frame groups 709 and 710 are represented using a start sequence number (Start SN) 711 and a Count field 712 for each frame group. As in configuration example 4, the start sequence number 711 indicates the sequence number of the MPDU corresponding to the beginning of the frame group that has not been transmitted. The Count field 712 holds information indicating the number of consecutive sequence numbers, starting from the start sequence number 711, that have not been transmitted. If the size of the Count field specified in the Count Size field 708 is small, the maximum number of MPDUs that can be represented as a frame group is small, but the data length required to represent one frame group can be reduced. On the other hand, if the size of the Count field specified in the Count Size field 708 is large, the maximum number of MPDUs that can be represented as a frame group is large, but the data length required to represent one frame group is large. The Count Size to be used is not limited in this example. The start sequence number can be represented using 12 bits.

[0058] In this configuration example, the upper limit of the number of MPDUs that can be represented in one frame group is defined by the Count Size section 708, so even MPDUs with consecutive sequence numbers may be represented as separate frame groups.

[0059] In this configuration example, the ACK Info header portion 724 includes a start sequence number 725 of the transmitted frame group and a Count portion 726 indicating the total number (quantity) from that start sequence number to the end sequence number. The size of the Count portion 726 in the ACK Info header portion 724 is not specified by the Count Size portion 708, but may be fixed to 12 bits, or a Count Size portion indicating information about the Count portion 726 may be stored separately in the ACK Info header portion.

[0060] <Configuration Example 6> FIG. 7(c) shows a sixth configuration example of the ACK Info subfield 506. Similar to the fourth configuration example, the ACK Info header section 727 in the sixth configuration example includes information indicating the data length included in the ACK Info data section. The data length can be indicated by storing the data length of the following ACK Info section in units of bits, bytes, or the number of frame groups (in this example, 16 per frame group + the number of bits indicated by the Count Size section of each frame). Note that this method is not limited to this, as long as the data length can be indicated. In the sixth configuration example, the frame groups 715 and 716 are represented using a start sequence number (Start SN) 717, a Count Size section 718, and a Count section 719 in each frame group. The Count Size section 708 stored in the ACK Info header section 607 in the fifth configuration example is stored in each frame group. This allows an appropriate Count Size to be set for each frame group without fixing the Count Size in the header section. An appropriate Count Size can be set by setting the Count Size to a large value when the number of frames to be represented in the frame group is large, or to a small value when the number of frames is small.

[0061] In this configuration example, the ACK Info header portion 727 includes a start sequence number 728 of the transmitted frame group, a Count portion 730 indicating the total number from that number to the end sequence number, and a CountSize portion 729 indicating size information of the Count portion 730.

[0062] [Configuration Example 7] Configuration Example 7 uses the format of the Compressed Block Ack Variant used in BA Type: Compressed, as defined in the 802.11 standard. In this configuration, the ACK Info subfield 506 (sequence information) stores the Fragment Number (4 bits), Starting Sequence Number (12 bits), and Block Ack Bitmap (8 or 32 bytes). The size of the Block Ack Bitmap and the maximum number of MSDUs / A-MSDUs that can be represented at one time are determined according to the Fragment Number value and conform to the 802.11ax standard. The Starting Sequence Number is set to a value indicating the starting sequence number of the transmitted data frame (MPDU). Starting from this starting sequence number, subsequent data frames are associated with each bit of the Block Ack Bitmap to indicate whether they have been transmitted. A frame with a bit set to 1 can be determined to have been transmitted, and a frame with a bit set to 0 can be determined to have not been transmitted. The meanings of 0 and 1 can be reversed.

[0063] Although the above description of Configuration Examples 1 to 7 has been given using the BlockAck Request frame transmitted by the AP 102 (data transmitting device) as an example, the above-described configurations can also be applied to a BlockAck frame transmitted by the STA 103 (data receiving device). For example, in Configuration Examples 1 to 3, the "transmitted frame(s)" in the above description of Configuration Examples 1 to 3 can be read as the "received frame(s)" in the ACK Info subfield indicating the received MPDU. In addition, in Configuration Examples 4 to 6, the "not transmitted frame(s)" in the above description of Configuration Examples 4 to 6 can be read as the "unreceived frame(s)" and the "transmitted frame(s)" in the ACK Info subfield indicating the unreceived MPDU. In addition, in Configuration Example 7, the Starting Sequence Number can be set to a value indicating the starting sequence number of the received data frame (MPDU). In addition, each bit of the Block Ack Bitmap can be set to the reception result for the data frame transmitted by the data transmitting device. An example of processing related to the BA frame when configuration example 7 is used will be described later.

[0064] Furthermore, the configurations based on the above configuration examples 1 to 6 can also be applied to a data frame set in an Implicit BlockAck Request. For example, the configurations of the above configuration examples 1 to 6 can be similarly applied to the BAR Control field and BAR Information field in the data frame.

[0065] (Notification method of ACK Info subfield configuration) The transmitting side of the BlockAck Request frame can specify (designate) in the frame which of the configuration examples 1 to 7 the ACK Info subfield 506 will be configured with, and notify the receiving side. For example, it can specify which of the configuration examples 1 to 7 to use by using at least one of the BAR Type subfield 504, the Reserved subfield 505, and the BAR Subtype subfield 507.

[0066] For example, BAR Type 0, which means Reserved in BAR Type subfield 504, may be defined as a BAR Type that means that one of configuration examples 1 to 7 is used. Furthermore, which of configuration examples 1 to 7 is to be used may be specified by using at least three bits of another reserved area in BAR Type subfield 504, Reserved subfield 505, and BAR Subtype subfield 507. Specifically, when BAR Subtype subfield 507 is used, it may be defined that configuration example 1 is used when bits 0000 are specified in BAR Subtype subfield 507, and configuration example 2 is used when bits 0001 are specified.

[0067] Furthermore, the existing BAR Type subfield 504 may be combined with a predetermined (sub)field to specify the use of one of the configuration examples 1 to 7. For example, consider a case where the BAR Type subfield 504 is set to Multi-TID or Multi-STA. When the BAR Type subfield 504 is set to Multi-TID, the area of ​​the Reserved subfield 505 may be used to specify the use of one of the configuration examples 1 to 7.

[0068] Note that the standard may stipulate that whether the communication partner device supports the New BAR according to this embodiment (i.e., the configuration of the ACK Info subfield 506 in Configuration Examples 1 to 7) (whether it has capability information for the New BAR Type) is mandatory. Alternatively, in the example of FIG. 4, capability information may be exchanged between the AP 102 and the STA 103 through the exchange of ADDBA Request / Response frames (when a BlockAck Agreement is established). Alternatively, capabilities may be negotiated through the exchange of other management frames. More specifically, when a BlockAck Agreement is established (see FIG. 4), negotiation can be performed using, for example, a Reserved bit in the ADDBA Capabilities Field in the ADDBA Extension Element. Note that the negotiation is not limited to this method. Whether or not the New BAR is supported, as determined by negotiation, may be recorded in the connection management unit 303 as an attribute of the BlockAck Agreement.

[0069] Although the above describes a method for notifying the configuration of the ACK Info subfield by the transmitter of a BlockAck Request frame, the same explanation can be applied to a method for notifying the configuration of the ACK Info subfield by the transmitter of a BlockAck frame. In this case, simply read "BAR" as "BA" in the above explanation. Also, when using a data frame set as an Implicit BlockAck Request, the configuration of the ACK Info subfield can be notified by using the BAR Control field and BAR Information field in the data frame.

[0070] <Data frame sending side processing> Next, the processing on the data frame transmission side will be described with reference to Figures 8 to 12. Here, the case where the device on the data frame transmission side is AP 102 as shown in Figure 4 will be described as an example, but this description can also be applied to the case where STA 103 is the main operator.

[0071] (Frame transmission process) The frame transmission process by the data frame transmitting side in this embodiment will be described with reference to Fig. 8. Fig. 8 is a flowchart of the frame transmission process by the data frame transmitting side. This process can be started after AP 102 establishes a wireless connection with a communication partner device (STA 103 in the example of Fig. 4) and completes the exchange of ADDBA Request / Response frames.

[0072] As described above, it is assumed that the connection management unit 303 of each of the AP 102 and the STA 103 records and manages various parameters such as the Starting Sequence Number in the BA session in the storage unit 201 when establishing a BlockAck Agreement (F402 to F405 in FIG. 4). Furthermore, it is assumed that the connection management unit 303 of each of the AP 102 and the STA 103 records and manages information on the BA Type supported by the communication partner device (which may include the new BA(R) Type according to the New BA(R) of this embodiment) in the storage unit 201.

[0073] When the frame generation unit 302 of the AP 102 generates a frame to be sent to the communication partner device (STA 103), the frame transmission / reception unit 304 starts the frame transmission process. As part of the frame transmission process, the frame transmission / reception unit 304 first determines whether the frame to be transmitted is a data frame (S801). This can be determined, for example, by checking whether the Type field in the Frame Control Field included in the MAC header in the MAC frame format defined by the IEEE 802.11 standard is "10." If the value is "10," it is determined to be a data frame; otherwise, it is determined not to be a data frame.

[0074] If it is determined that the frame to be transmitted is a data frame (Yes in S801), the frame transmitting / receiving unit 304 executes data frame generation and transmission processing (S802). Details of the processing of S802 will be described later using FIG. 9. After the processing of S802, the frame generating unit 302 determines whether to generate and transmit a BlockAck Request (BAR) frame (S803). This determination may be made, for example, based on the cumulative number of transmitted data frames (MPDUs) since the frame transmitting / receiving unit 304 last received a BlockAck frame, or may be made according to some other rule.

[0075] If it is determined that a BAR frame should be generated and transmitted (Yes in S803), the frame generation unit 302 transmits the BAR frame, and the frame transmission / reception unit 304 executes BAR frame generation and transmission processing (S804), and then ends. Details of the processing of S804 will be described later with reference to FIG. 10. If it is determined that a BAR frame should not be generated (No in S803), the AP 102 ends the frame transmission processing.

[0076] If it is determined in S801 that the frame to be transmitted is not a data frame (No in S801), the AP 102 executes processing corresponding to various frames conforming to the IEEE 802.11 standard (S805) and ends the processing. The processing of S805 is not relevant to this embodiment, so a description thereof will be omitted.

[0077] (Data frame generation and transmission processing) Next, an example of the data frame generation and transmission process of S802 will be described with reference to Fig. 9. Fig. 9 is a flowchart of the data frame generation and transmission process. The sequence number of the data frame (MPDU) is indicated by the Sequence Number in the Sequence Control field included in the MAC header in the MAC frame format defined by the IEEE802.11 standard, and has a value in the range of 0 to 4095.

[0078] The connection management unit 303 of the AP 102 records and manages the sequence number of a data frame scheduled to be transmitted by the frame transmission / reception unit 304 as a transmitted frame (as a transmitted sequence number) in the storage unit 201 (S901). The connection management unit 303 can use the number information to determine whether data with a given sequence number has already been transmitted. The connection management unit 303 starts managing the transmission sequence numbers for a connection when a wireless connection is established (F401 in the example of FIG. 4). At the start of management, all sequence numbers 0 to 4095 are recorded in the storage unit 201 as untransmitted sequence numbers. Note that the sequence number of the first frame to be transmitted may start from 0, but is not limited to this. When the sequence number reaches 4095, the sequence number of the next frame returns to 0.

[0079] Next, the frame generation unit 302 sets an Ack Policy (sets the Ack Policy subfield in the QoS Control field) (S902). For example, support for New BAR can be indicated by using Bit 5 and Bit 6 of the QoS Control field. For example, if it is confirmed that AP 102 and STA 103 support New BAR when establishing a BlockAck Agreement, the frame generation unit 302 can set Bit 5:1 and Bit 6:0 in the QoS Control field. Furthermore, indicating support for New BAR can indicate that an Implicit BlockAck Request is set in the data frame.

[0080] After setting the Ack Policy, information is added to the Frame Body according to the BAR Type supported by the AP 102 and the STA 103 (S903). For example, if Bit 5:1 and Bit 6:0 are set in the QoS Control field as described above, the frame generation unit 302 can include information specifying the transmitted / untransmitted sequence number in the Frame Body, as described with reference to FIGS. 6 and 7. In this case, the receiving STA 103 can analyze the Frame Body and extract information about the sequence number of the data transmitted by the AP 102. When the STA 103 receives a data frame including such an Ack Policy, it can return a BlockAck frame without receiving a BlockAck Request frame. Next, the frame generation unit 302 generates the remaining frame portion to complete the data frame (S904). Finally, the frame transmission / reception unit 304 transmits the data frame generated by the frame generation unit 302 to the remote communication device (STA 103) (S905).

[0081] (BAR frame generation and transmission processing) Next, the BAR frame generation and transmission process of S804 will be described with reference to Fig. 10. Fig. 10 is a flowchart of the BAR frame generation and transmission process. As described above, the connection management unit 303 of each of the STA 103 and AP 102 records and manages information such as the BAR Type (which may include the New BAR Type according to this embodiment) supported by the communication partner device in the storage unit 201. Furthermore, Fig. 5 will be referred to for frame generation.

[0082] The connection management unit 303 of the AP 102 checks the BAR type supported by the connection (supported by the AP itself and the STA 103) (S1001). Here, it is assumed that the AP 102 and the STA 103 support New BAR; otherwise, processing in accordance with the IEEE 802.11 standard may be performed. Next, the connection management unit 303 checks the transmitted sequence number (S1002).

[0083] The frame generation unit 302 generates a BAR frame using the information confirmed in S1001 and S1002. First, the frame generation unit 302 determines the configuration of the ACK Info subfield 506 in the BAR Information field 503 (S1003). Here, the frame generation unit 302 can determine the configuration of the ACK Info subfield 506 based on the supported BAR Type confirmed in S1001. If the confirmed supported BA Type indicates that one of the above configuration examples 1 to 7 is supported, the frame generation unit 302 can determine to use one of the above configuration examples 1 to 7 as the configuration of the ACK Info subfield 506. Note that the use of one of the above configuration examples 1 to 7 may be fixedly set in the AP 102 in advance, or may be set (determined) by a user's input operation via the input unit 204.

[0084] Next, frame generation unit 302 generates BA Control field 502 and BAR Information field 503 in accordance with the configuration of ACK Info subfield 506 determined in S1003 and so as to specify (designate) this configuration (S1004). As described above, the use of any of configuration examples 1 to 7 for ACK Info subfield 506 can be designated by various subfields in BAR Control field 502 / BAR Information field 503. Furthermore, frame generation unit 302 generates BAR Information field 503 based on the transmitted sequence number confirmed in S1002. The specific contents of the BAR Information field express the sequence number confirmed in S1002 in any of the formats described in configuration examples 1 to 7.

[0085] Next, the frame generation unit 302 generates the remaining frame portions to complete the BAR frame (S1005). Finally, the frame transmission / reception unit 304 transmits the BAR frame generated by the frame generation unit 302 to the communication partner device (STA 103).

[0086] (Frame reception processing) Next, frame reception processing by the data frame transmitting side in this embodiment will be described with reference to Fig. 11. Fig. 11 is a flowchart of the frame reception processing. When the frame transmitting / receiving unit 304 of the AP 102 receives a wireless frame from the communication partner device (STA 103), the frame analysis unit 301 starts analysis processing of the received frame. Note that if the frame is not addressed to the AP 102 itself or if the frame is corrupted (for example, the FCS value is invalid), the frame may be discarded without starting this processing.

[0087] As part of the frame analysis process, the frame analysis unit 301 first determines whether the received frame is a BA (BlockAck) frame (S1101). This can be determined, for example, by checking whether the Type field in the Frame Control Field included in the MAC header in the MAC frame format defined by the IEEE 802.11 standard is "01" and the Subtype field is "1001." If the Type field is "01" and the Subtype field is "1001," it can be determined to be a BlockAck frame; otherwise, it can be determined to be a non-BA frame.

[0088] If it is determined that the received frame is a BA frame (Yes in S1101), the AP 102 executes BA frame processing (S1102). The BA frame reception processing in S1102 will be described later with reference to Fig. 12. If it is determined that the received frame is not a BA frame (No in S1101), the AP 102 executes processing corresponding to various frames conforming to the IEEE 802.11 standard (S1103), and ends the processing. The processing in S1103 is not closely related to this embodiment, so a description thereof will be omitted.

[0089] (BA frame reception processing) Next, the BA frame reception process of S1102 will be described with reference to Fig. 12. Fig. 12 is a flowchart of the BA frame reception process. As described above, the connection management units 303 of the STA 103 and AP 102 respectively record and manage information such as the BA Type (which may include the New BA Type according to this embodiment) supported by the communication partner device in the storage unit 201. Also, with regard to frame generation, Fig. 5 will be referred to.

[0090] The connection management unit 303 of the AP 102 checks the BA type supported by the connection (supported by the AP itself and the STA 103) (S1201). This information has been checked and recorded by the connection management unit 303 when the Block Ack Agreement was established. The AP 102 can switch the subsequent processing depending on the BA type checked here.

[0091] Next, the connection management unit 303 of the AP 102 checks the BA Information field 503 included in the received BA frame (S1202). The format of the BA Information field 503 can vary depending on the BA Type, but the connection management unit 303 extracts the sequence number (received sequence number) recorded by the STA 103 as having been received from the information included in this field (S1203). For example, if the BA Type is Compressed, the BA Information field 503 can include a Block Ack Starting Sequence Control and a Block Ack Bitmap. The sequence number recorded as having been received can be calculated from the starting point of the received sequence number and the bitmap indicating whether each sequence number from that point was received or not.

[0092] Next, the connection management unit 303 updates the transmitted sequence numbers that it manages (S1204). Since there is no need for the AP 102 to retransmit frames that have been confirmed as having been received by the STA 103 in S1203, there is no need for the AP 102 to manage the transmitted frames. Therefore, the connection management unit 303 cancels the record of the transmitted frames. Next, the connection management unit 303 may delete the frames whose transmitted record has been canceled in S1204 from the transmission buffer (S1205).

[0093] <Data frame receiving side processing> Next, processing on the data frame receiving side will be described with reference to Figures 13 to 15. Here, the case where the device on the data frame receiving side is STA 103 as shown in Figure 4 will be described as an example, but this description is also applicable to the case where AP 102 is the main operator. As mentioned above, the description of BAR Control field 502 and BAR Information field 503 for the BAR frame is applicable to BA Control field 502 and BA Information field 503, respectively, and detailed description will be omitted.

[0094] (Frame reception processing) The frame reception process by the data frame receiving side in this embodiment will be described with reference to Fig. 13. Fig. 13 is a flowchart of the frame reception process by the data frame receiving side. This process can be started after the STA 103 establishes a wireless connection with the communication partner device (AP 102 in the example of Fig. 4) and completes the exchange of ADDBA Request / Response frames.

[0095] As described above, it is assumed that the connection management units 303 of the STA 103 and the AP 102 record and manage various parameters such as the Starting Sequence Number in the BA session in the storage unit 201 when establishing a BlockAck Agreement (F402 to F405 in FIG. 4). Furthermore, it is assumed that the connection management units 303 of the STA 103 and the AP 102 record and manage information on the BA Type (which may include the New Type according to this embodiment) supported by the communication partner device in the storage unit 201.

[0096] When the frame transmitting / receiving unit 304 of the STA 103 receives a wireless frame from the communication partner device (AP 102), the frame analyzing unit 301 starts analyzing the received frame. Note that if the frame is not addressed to the STA 103 itself or if the frame is corrupted (for example, if the FCS value is invalid), the STA 103 may discard the frame without starting this processing.

[0097] As part of the frame analysis process, the frame analysis unit 301 first determines whether the received frame is a data frame (S1301). This can be determined, for example, by checking whether the Type field in the Frame Control Field included in the MAC header in the MAC frame format defined by the IEEE 802.11 standard is "10." If the value is "10," it is determined to be a data frame; otherwise, it is determined not to be a data frame.

[0098] If it is determined that the received frame is a data frame (Yes in S1301), the connection management unit 303 executes processing to check the sequence number of the data frame (S1302). Details of the processing of S1302 will be described later with reference to FIG. 14. After the processing of S1302, the frame analysis unit 301 determines whether the received frame is a data frame that requests a BlockAck frame (S1303). This can be determined, for example, by checking whether the Ack Policy subfield included in the QoS Control field of at least one MPDU among the MPDUs included in the data frame is set to Implicit BlockAck Request (“00”). If it is set to “00,” the frame analysis unit 301 determines that the received frame is a data frame that requests a BlockAck frame (Yes in S1303), and the processing proceeds to S1304. If it is not set to “00,” the frame analysis unit 301 determines that the received frame is not a data frame that requests a BlockAck frame, and ends the frame reception processing. In S1304, the AP 102 performs a BlockAck (BA) frame generation and transmission process. Details of the process in S1304 will be described later with reference to FIG.

[0099] If it is determined in S1301 that the received frame is not a data frame (No in S1301), the frame analysis unit 301 determines whether the received frame is a BAR (BlockAck Request) frame (S1305). For example, if the aforementioned Type field in the data frame is “01” and the Subtype field in the Frame Control Field in the MAC header is “1000,” the frame can be identified as a BAR frame. If the frame analysis unit 301 determines that the received frame is a BAR frame (Yes in S1305), the process proceeds to S1304, and the STA 103 executes BA frame generation and transmission processing. The BAR frame may include information about the start number of the data. If it is determined in S1305 that the received frame is not a BAR frame (No in S1305), the STA 103 executes processing corresponding to various frames compliant with the IEEE 802.11 standard (S1306), and ends the process. The processing of S1306 is not relevant to this embodiment, so a description thereof will be omitted.

[0100] (Data frame sequence number verification process) Next, the process of checking the sequence number of a data frame in S1302 will be described with reference to Fig. 14. Fig. 14 is a flowchart of the process of checking the sequence number of a data frame. The sequence number of a data frame (MPDU) is indicated by the Sequence Number in the Sequence Control field included in the MAC header in the MAC frame format defined by the IEEE 802.11 standard, and has a value ranging from 0 to 4095. When a wireless connection is established (F401 in the example of Fig. 4), the connection management unit 303 starts managing the receive sequence numbers (sequence numbers of data frames that have already been received) related to the connection. At the start of management, all sequence numbers 0 to 4095 are recorded in the storage unit 201 as unreceived sequence numbers (sequence numbers of data frames that have not been recorded as having been received).

[0101] The connection management unit 303 of the STA 103 checks whether the sequence number of the data frame (MPDU) is an unreceived sequence number (S1401). That is, the connection management unit 303 compares the information of the received data frame sequence number with the received sequence number recorded in the storage unit 201, and determines whether the sequence number of the received data frame is an unreceived sequence number.

[0102] If the sequence number of the received data frame is an unreceived sequence number (Yes in S1401), the connection management unit 303 newly records the sequence number in the storage unit 201 as a received sequence number (S1402) and ends the process. On the other hand, if the sequence number of the received data frame is a received sequence number (No in S1401), the received data frame has already been received and is considered to be a duplicate frame, so the connection management unit 303 discards the data frame (S1403) and ends the process.

[0103] (BA frame generation and transmission processing) Next, the BlockAck (BA) frame generation and transmission process of S1304 will be described with reference to Fig. 15. Fig. 15 is a flowchart of the BA frame generation and transmission process. As described above, the connection management unit 303 of each of the STA 103 and AP 102 records and manages information such as the BA Type (which may include the New BA Type according to this embodiment) supported by the communication partner device and the Starting Sequence Number in the BA session in the storage unit 201. Furthermore, Fig. 5 will be referred to for frame generation.

[0104] The connection management unit 303 of the STA 103 checks the BA Type supported by the connection (supported by its own device and the AP 102) (S1501). Depending on the support status of the BA Type checked here, the frame generation unit 302 can determine the contents of the BlockAck frame to be generated in S1504 and S1505. Next, the connection management unit 303 of the STA 103 checks the Starting Sequence Number in the BA session (S1502). As mentioned above, the initial value of the Starting Sequence Number is determined when the BlockAck Agreement is established, and can be updated thereafter in accordance with the method specified in the IEEE 802.11 standard. Next, the connection management unit 303 checks the received sequence number (the sequence number recorded as having been received) (S1503).

[0105] The frame generation unit 302 generates a Block Ack frame using the information confirmed in S1001 to S1003. First, the frame generation unit 302 determines the configuration of the ACK Info subfield 506 in the BA Information field 503 (S1504). Here, the frame generation unit 302 can determine the configuration of the ACK Info subfield 506 based on the supported BA Type confirmed in S1501. If the confirmed supported BA Type indicates that one of the above configuration examples 1 to 6 is supported, the frame generation unit 302 can determine to use one of the above configuration examples 1 to 7 as the configuration of the ACK Info subfield 506. Note that the use of one of the above configuration examples 1 to 7 may be fixedly set in the STA 103 in advance, or may be set (determined) by a user's input operation via the input unit 204. Furthermore, the frame generation unit 302 determines the configuration of the ACK Info subfield 506 based on the supported BA Type confirmed in S1003. It may be decided to use any of the configuration examples 1 to 7 to configure the ACK Info subfield 506 with the smallest data size.

[0106] Next, the frame generation unit 302 generates the BA Control field 502 and the BA Information field 503 in accordance with the configuration of the ACK Info subfield 506 determined in S1504 and so as to identify (specify) this configuration (S1505). As described above, the use of any of configuration examples 1 to 7 for the ACK Info subfield 506 can be specified by various subfields in the BA Control field 502 / BA Information field 503.

[0107] 5(a) to complete the MAC frame, and also generates a PHY section to complete the BlockAck frame (S1506). Finally, the frame transmitting / receiving section 304 transmits the BlockAck frame generated by the frame generating section 302 to the communication partner device (AP102) (S1507).

[0108] Acknowledgments for transmitted frames and retransmissions when no acknowledgement is received for a certain period of time are performed in accordance with the IEEE 802.11 standard. When the STA 103 correctly transmits a BlockAck frame and receives an acknowledgement from the AP 102, it resets the record of received frames. For example, the connection management unit 303 of the STA 103 resets the record of received frames for the sequence numbers it manages that have been notified in the BlockAck frame. This makes it possible to manage sequence numbers when they have gone through a cycle.

[0109] (BA frame using configuration example 7) An example of a BA frame according to configuration example 7 and an example of processing using this frame will be described. Note that, although the description will be made taking as an example a case where the device on the data frame transmission side is AP 102 as shown in Fig. 4, this description can also be applied to a case where STA 103 is the main operator. Also, Fig. 5 will be referred to for frame generation.

[0110] The STA 103 can obtain the sequence number of the data frame transmitted from the AP 102 from the BAR Information (information set in the BAR Information field 503) in the BAR frame. The STA 103 can use the sequence number of the transmitted data frame to associate each bit expressed in the BlockAckBitmap in the ACK Info subfield 506 with the sequence number, thereby efficiently using the bits of the Bitmap.

[0111] As described above in relation to configuration example 7, the BA information (information set in the BA information field 503) stores a fragment number (4 bits), a starting sequence number (12 bits), and a block acknowledgment bitmap (8 or 32 bytes). The size of the block acknowledgment bitmap and the maximum number of MSDUs / A-MSDUs that can be represented at one time are determined according to the value of the fragment number and conform to the 802.11ax standard. The starting sequence number is set to a value that indicates the starting sequence number of the frame transmitted by the AP (communication destination device) presented in the BAR information. For subsequent frames, only the sequence numbers that the AP 102 presented as having been transmitted in the BAR information are associated with each bit in the block acknowledgment bitmap to indicate whether or not they have been transmitted. It can be determined that a frame with a bit set to 1 has been transmitted, and a frame with a bit set to 0 has not been transmitted. The meanings of 0 and 1 may be reversed.

[0112] As a specific example, assume that AP 102 indicates in its BAR information that it has transmitted sequence numbers 1, 3, and 5, but STA 103 has only failed to receive sequence number 3. In this case, STA 103 sets the StartingSequenceNumber to 1 and the FragmentNumber to 0 in the BA Information included in the BlockAck frame, and sets the BlockAck Bitmap length to a minimum of 8 bytes. In the BlockAck Bitmap, the first bit corresponds to sequence number 1, the second bit corresponds to sequence number 3, and the third bit corresponds to sequence number 5. Subsequent bits are not used, but may be set to 0 to indicate unreceived bits. In this example, sequence numbers 1 and 5 indicate successful reception, and 3 indicates unsuccessful reception, so a BlockAck frame containing a BlockAck Bitmap value of "101" is transmitted from STA 103 to AP 102. AP 102 receives the BlockAck frame and compares it with the BAR Information it transmitted, thereby identifying the frame to which each bit corresponds. In this example, sequence number 3 is considered a transmission failure and is retransmitted.

[0113] Acknowledgments for transmitted frames and retransmissions when no acknowledgement is received for a certain period of time are performed in accordance with the IEEE 802.11 standard. When the STA 103 correctly transmits a BlockAck frame and receives an acknowledgement from the AP 102, it resets the record of received frames. For example, the connection management unit 303 of the STA 103 resets the record of received frames for the sequence numbers it manages that have been notified in the BlockAck frame. This makes it possible to manage sequence numbers when they have gone through a cycle.

[0114] The process flows shown in Figures 8 to 15 are examples of how this proposal can be implemented, and the order of each process is not limited as long as it achieves the same function. Furthermore, processes not described in these process flows follow the process specified in the IEEE 802.11 standard.

[0115] The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the computer of the system or device read and execute the program. It can also be realized by a circuit (e.g., ASIC) that realizes one or more functions.

[0116] The invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the spirit and scope of the invention. Accordingly, the following claims are appended to apprise the public of the scope of the invention. [Explanation of symbols]

[0117] 101 network, 102 AP (access point), 103 STA (station), 104; 105 link

Claims

1. A communication device conforming to the IEEE 802.11 standard series, a first transmitting means for transmitting a first plurality of data frames in the first link and a second plurality of data frames in the second link to a communication destination; a second transmitting means for transmitting, to the communication partner, a first request frame requesting a first acknowledgement (Ack) frame for the first plurality of transmitted data frames and a second request frame requesting a second Ack frame for the second plurality of transmitted data frames; receiving means for receiving the first and second Ack frames from the communication destination in response to transmitting the first and second request frames; each of the first and second request frames includes sequence information regarding sequence numbers of a plurality of data frames transmitted on each of the first and second links; the sequence information included in each of the first and second request frames includes identification information for identifying one or more data frame groups distinguished by a series of data frames having consecutive sequence numbers among the plurality of data frames transmitted on each of the links, The communication device, wherein the specific information includes information on a start sequence number and an end sequence number of a series of data frames in each data frame group transmitted over each link.

2. 2. The communication device according to claim 1, wherein the specific information includes information on a starting sequence number of a series of data frames in each data frame group transmitted on each link, and information on the number of consecutive sequence numbers starting from the starting sequence number to an ending sequence number of the series of data frames.

3. 2. The communication device according to claim 1, wherein the specific information includes information on a starting sequence number of a series of data frames in each data frame group transmitted on each link, information on the number of consecutive sequence numbers starting from the starting sequence number to the ending sequence number of the series of data frames, and information indicating a size of the number information.

4. 4. The communication device according to claim 1, wherein the sequence information includes information indicating the end of the one or more data frame groups transmitted through each of the links.

5. 5. The communication device according to claim 4, wherein the information indicating the end of the one or more data frame groups is indicated in units of bits, bytes, or the number of the one or more data frame groups.

6. A communication device conforming to the IEEE 802.11 standard series, a first transmitting means for transmitting a first plurality of data frames in the first link and a second plurality of data frames in the second link to a communication destination; a second transmitting means for transmitting, to the communication partner, a first request frame requesting a first acknowledgement (Ack) frame for the first plurality of transmitted data frames and a second request frame requesting a second Ack frame for the second plurality of transmitted data frames; receiving means for receiving the first and second Ack frames from the communication destination in response to transmitting the first and second request frames; the first and second request frames include sequence information regarding sequence numbers of a plurality of data frames not yet transmitted on each of the first and second links; the sequence information included in each of the first and second request frames includes information on a plurality of data frames transmitted over each of the links, and identification information for identifying one or more data frame groups, each group being distinguished by a series of data frames having consecutive sequence numbers among a plurality of data frames not transmitted over each of the links; The communication device according to claim 1, wherein the specific information includes information on the start sequence number and the end sequence number of a series of data frames in each data frame group that has not been transmitted on each link.

7. 7. The communication device according to claim 6, wherein the sequence information includes, as information on the plurality of data frames transmitted on each of the links, information on start sequence numbers and end sequence numbers of the plurality of transmitted data frames.

8. 7. The communication device according to claim 6, wherein the sequence information includes, as information about the multiple data frames transmitted over each of the links, information about the starting sequence numbers of the multiple transmitted data frames and information about the number of consecutive sequence numbers starting from the starting sequence number to the ending sequence number of the multiple data frames, and the specific information includes information about the starting sequence numbers of a series of data frames in each group of data frames not transmitted over each of the links and information about the number of consecutive sequence numbers starting from the starting sequence number to the ending sequence number of the series of data frames.

9. 7. The communication device according to claim 6, wherein the sequence information includes, as information about the multiple data frames transmitted over each of the links, information about the starting sequence numbers of the multiple transmitted data frames and information about the number of consecutive sequence numbers starting from the starting sequence number to the ending sequence number of the multiple data frames, and the specific information includes information about the starting sequence numbers of a series of data frames in each group of data frames not transmitted over each of the links, information about the number of consecutive sequence numbers starting from the starting sequence number to the ending sequence number of the series of data frames, and information indicating a size of the number information.

10. 10. The communication device according to claim 6, wherein the sequence information includes information indicating the end of the one or more data frame groups that have not been transmitted on each of the links.

11. 11. The communication device according to claim 10, wherein the information indicating the end of the one or more data frame groups is indicated in units of bits, bytes, or the number of the one or more data frame groups.

12. A communication device conforming to the IEEE 802.11 series of standards, a first transmitting means for transmitting a first plurality of data frames in the first link and a second plurality of data frames in the second link to a communication destination; a second transmitting means for transmitting, to the communication partner, a first request frame requesting a first acknowledgement (Ack) frame for the first plurality of transmitted data frames and a second request frame requesting a second Ack frame for the second plurality of transmitted data frames; receiving means for receiving the first and second Ack frames from the communication destination in response to transmitting the first and second request frames; the first and second request frames each include sequence information regarding sequence numbers of a plurality of data frames transmitted on each of the first and second links; the sequence information included in the first request frame includes a first starting sequence number and a first bitmap field as first identification information for identifying one or more data frame groups transmitted over the first link among the plurality of data frames transmitted over each of the links, and in the first bitmap field, 1 is stored in bits corresponding to frames transmitted over the first link and 0 is stored in bits corresponding to frames not transmitted over the first link, based on the first starting sequence number; a second bitmap field as second identification information that identifies one or more data frames transmitted on the second link among the data frames transmitted on each of the links, and a 1 in the second bitmap field is stored in a bit corresponding to a frame transmitted on the second link, and a 0 in a bit corresponding to a frame not transmitted on the second link, based on the second starting sequence number.

Images