WO2022123967A1 - 通信装置、通信装置の制御方法、およびプログラム - Google Patents

通信装置、通信装置の制御方法、およびプログラム Download PDF

Info

Publication number
WO2022123967A1
WO2022123967A1 PCT/JP2021/040508 JP2021040508W WO2022123967A1 WO 2022123967 A1 WO2022123967 A1 WO 2022123967A1 JP 2021040508 W JP2021040508 W JP 2021040508W WO 2022123967 A1 WO2022123967 A1 WO 2022123967A1
Authority
WO
WIPO (PCT)
Prior art keywords
data frames
frame
information
transmitted
sequence
Prior art date
Application number
PCT/JP2021/040508
Other languages
English (en)
French (fr)
Inventor
祐樹 藤森
Original Assignee
キヤノン株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by キヤノン株式会社 filed Critical キヤノン株式会社
Priority to CN202180082391.4A priority Critical patent/CN116602031A/zh
Priority to EP21903071.5A priority patent/EP4262299A1/en
Publication of WO2022123967A1 publication Critical patent/WO2022123967A1/ja
Priority to US18/331,080 priority patent/US20230318790A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1614—Details of the supervisory signal using bitmaps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1621—Group acknowledgement, i.e. the acknowledgement message defining a range of identifiers, e.g. of sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1635—Cumulative acknowledgement, i.e. the acknowledgement message applying to all previous messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the present invention relates to a wireless communication technique.
  • the IEEE802.11 series is known as a wireless LAN (Local Area Network) communication standard established by the Institute of Electrical and Electronics Engineers (Institute of Electrical and Electronics Engineers).
  • IEEE802.11 series standard there are standards such as the IEEE802.11a / b / g / n / ac / ax standard (Patent Document 1).
  • the IEEE802.11ax standard discloses an extended specification of a BlockAck frame that can transmit an acknowledgment (ACK) in one frame for receiving a plurality of wireless packets.
  • the IEEE802.11ax standard discloses a specification for expanding the number of MPDUs (MAC (Media Access Control) Protocol Data Units) that can be expressed by the BlockAck Bitmap in the BlockAck frame from 64 to 256 up to IEEE802.11ac. By increasing the number of MPDUs that can be acknowledged at one time, the throughput is improved.
  • MPDUs Media Access Control Protocol Data Units
  • the establishment of the IEEE802.11be standard is being considered as a new standard of the IEEE802.11 series in order to further improve the throughput and the frequency utilization efficiency.
  • the IEEE802.11be standard proposes to further increase the number of MPDUs that can be acknowledged at one time to 512 and 1024.
  • a method of Multi-Link communication in which wireless devices communicate with each other using a plurality of wireless links and a method of Multi-AP communication in which a plurality of wireless access points connect to one wireless terminal and communicate with each other are studied.
  • a method of acknowledgment that spans multiple links is also under consideration.
  • the transmitting device transmits a data frame with a different block sequence number for each link.
  • the receiving device may receive a data frame having a sequence number partially missing at each link.
  • an efficient acknowledgment method has not been proposed for such a case.
  • the wireless communication device has the following configuration. That is, it is a communication device conforming to the IEEE802.11 standard series, and is a first transmission means for transmitting a plurality of data frames to a communication partner device using a plurality of links, and an acknowledgment for the plurality of transmitted data frames.
  • a second transmission means for transmitting a request frame requesting a frame to the communication partner device, a receiving means for receiving the Ac frame from the communication partner device in response to transmitting the request frame, and a receiving means.
  • the request frame includes sequence information regarding sequence numbers of a plurality of data frames transmitted on each link of the plurality of links, and the sequence information is a sequence among a plurality of data frames transmitted on the respective links. Includes specific information that identifies one or more data frame groups that are distinguished for each series of data frames whose numbers are serial numbers.
  • efficient confirmation response control is realized in communication using a plurality of links.
  • FIG. 1 shows the example of a network configuration.
  • a hardware configuration example of a communication device (STA, AP) is shown.
  • An example of a functional configuration of a communication device (STA, AP) is shown.
  • the communication sequence diagram for the data communication between AP and STA is shown.
  • the configuration of the BlockAck Request frame and the BlockAck frame is shown.
  • the configuration of the BlockAck Request frame and the BlockAck frame is shown.
  • the configuration of the BlockAck Request frame and the BlockAck frame is shown.
  • the configuration of the BlockAck Request frame and the BlockAck frame is shown.
  • the configuration example 1 of the ACK Info subfield is shown.
  • the configuration example 2 of the ACK Info subfield is shown.
  • the configuration example 3 of the ACK Info subfield is shown.
  • the configuration example 4 of the ACK Info subfield is shown.
  • 5 is a configuration example 5 of the ACK Info subfield.
  • FIG. 6 shows a configuration example 6 of the ACK Info subfield. It is a flowchart of a frame transmission process by a data frame transmission side. It is a flowchart of a data frame generation / transmission process. It is a flowchart of BAR frame generation / transmission processing. It is a flowchart of a frame reception process by a data frame transmission side. It is a flowchart of BA frame reception processing. It is a flowchart of a frame reception process by a data frame receiving side. It is a flowchart of a sequence number confirmation process. It is a flowchart of BA frame generation / transmission processing.
  • FIG. 1 shows an example of a network configuration according to this embodiment.
  • FIG. 1 shows a configuration including one AP (access point) (AP102) and one STA (station / terminal device) (STA103) as a communication device (wireless communication device).
  • AP102 access point
  • STA103 station / terminal device
  • the description of this embodiment is applicable to both AP and STA, and is not limited to either.
  • the network formed by AP102 is represented by a circle 101.
  • the STA 103 can send and receive frames to and from the AP 102 via the wireless links 104 and 105.
  • the radio links 104 and 105 can use channels in the frequency band of 2.4 GHz, 5 GHz, and 6 GHz, but the frequency band used is not limited to this, and another frequency band such as the 60 GHz band can be used. May be used.
  • the 2.4 GHz band and 5 GHz band channels may be used in combination as the wireless links 104 and 105, or a plurality of channels from the 6 GHz band may be used. It may be selected and used in combination.
  • the present embodiment can be similarly applied in the case of Multi-AP communication that handles communication between a plurality of APs and one STA.
  • Multi-AP communication that handles communication between a plurality of APs and one STA.
  • two wireless links of wireless links 104 and 105 will be described, but the present embodiment is not limited to this, and the present embodiment may be applied even when three or more links are used. can.
  • the network configuration shown in FIG. 1 is an example, and the following discussion can be applied to, for example, a network including a large number of communication devices in a wider area and the positional relationship of various communication devices. be.
  • FIG. 2 shows an example of the hardware configuration of the AP according to the present embodiment.
  • 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.
  • the STA also has the same hardware configuration as the AP, and the following description can be applied to the STA.
  • the storage unit 201 is composed of ROM (ReadOnlyMemory), RAM (RandomAccessMemory), or one of them, and includes programs for performing various operations described later, communication parameters for wireless communication, and the like. Memorize various information. As the storage unit 201, in addition to memories such as ROM and RAM, storage media such as flexible disks, hard disks, optical disks, magneto-optical disks, CD-ROMs, CD-Rs, magnetic tapes, non-volatile memory cards, and DVDs. May be used.
  • the control unit 202 is composed of, for example, a processor such as a CPU (Central Processing Unit) or MPU (Micro Processing Unit), an ASIC (integrated circuit for a specific application), a DSP (digital signal processor), an FPGA (Field Programmable Gate Array), or the like. Will be done.
  • the control unit 202 controls the entire AP by executing the program stored in the storage unit 201.
  • the control unit 202 may control the entire AP in cooperation with the program stored in the storage unit 201 and the OS (Operating System).
  • the control unit 202 controls the function unit 203 to execute predetermined processing such as imaging, printing, and projection.
  • the functional unit 203 is hardware for the AP to execute a predetermined process. For example, when the AP is a camera, the functional unit 203 is an imaging unit and performs an imaging process. Further, for example, when the AP is a printer, the functional unit 203 is a printing unit and performs printing processing. Further, for example, when the AP is a projector, the functional unit 203 is a projection unit and 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 described later.
  • the input unit 204 accepts various operations from the user.
  • the output unit 205 outputs various outputs to the user.
  • the output by the output unit 205 includes at least one such as a display on the screen, an audio output by the speaker, and a vibration output. It should be noted that both the input unit 204 and the output unit 205 may be realized by one module as in the touch panel.
  • the communication unit 206 controls wireless communication and IP communication in accordance with the 802.11 standard series.
  • the communication unit 206 can execute processing conforming to at least the IEEE802.11ax standard.
  • the communication unit 206 controls the antenna 207 to transmit and receive wireless signals for wireless communication.
  • the AP communicates contents such as image data, document data, and video data with other communication devices via the communication unit 206.
  • 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, respectively.
  • the wireless antenna 207 may be physically composed of one or more antennas in order to realize MIMO (Multi-Input Multi-Output) transmission / reception.
  • MIMO Multi-Input Multi-Output
  • the AP may include a plurality of communication units 206 and antennas 207, respectively (as in FIG. 2, the communication unit 206 and the antenna 207 are 2 each, as shown in FIG. 2). One). In this case, one communication unit 206 and antenna 207 may be assigned to each wireless link, or one communication unit 206 and antenna 207 may be shared by a plurality of links.
  • FIG. 3 shows an example of the functional configuration of the AP according to the present embodiment.
  • 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 as an example of its functional configuration.
  • the STA also has the same functional configuration as the AP, and the following description can be applied to the STA.
  • the frame analysis unit 301 analyzes the frame received from the communication partner device (opposite communication device).
  • the frame generation unit 302 generates a frame (wireless frame) to be transmitted to the communication partner device.
  • the connection management unit 303 manages the connection with the communication partner device. For example, the connection management unit 303 manages the BlackAck (BA) agreement / agreement (BlockAcgreement) and the data sequence number (Sequence Number) being connected to each communication partner device. BlockAckAgreement and SequenceNumber are managed for each TID (Traffic Identifier (identifier representing the type of traffic (data))) in the connection.
  • the frame transmission / reception unit 304 transmits / receives a frame to / from the communication partner device via the communication unit 206 and the antenna 207 (FIG. 2).
  • FIG. 4 shows a communication sequence diagram for data communication between AP102 and STA103.
  • the processing of this sequence can be started in response to the respective power-on of AP102 and STA103.
  • the processing of this sequence may be started in response to at least one of AP102 and STA103 instructed by the user or application to start wireless communication.
  • two wireless links 104 and 105 are configured between AP 102 and STA 103 as shown in FIG.
  • AP102 and STA103 establish a wireless connection by performing connection processing according to the IEEE802.11 standard.
  • This embodiment is applicable to both the case where the communication is not encrypted and the case where the communication is encrypted.
  • the encryption method (security method) with encryption is WEP (Wired Equivalent Privacy), WPA (Wi-Fi Protected Access) 1, WPA2, WPA3, WPS (Wi-Fi Protected Setup), and others.
  • WEP Wi-Fi Protected Access
  • WPA2 Wi-Fi Protected Access
  • WPA3, WPS Wi-Fi Protected Setup
  • This embodiment can be applied even if it is a method.
  • the connection may be established only on one representative link (for example, link 104), and the other link may be connected as a secondary link, or the connection may be established independently on each link. good.
  • AP102 transmits ADDBA Request frame to STA103 in F402, and receives ACK frame as an acknowledgment in F403.
  • STA 103 transmits an ADDBA Response frame to the AP102 at F404, and receives an ACK frame as an acknowledgment at F405.
  • a BlockAcgreement is constructed between AP102 and STA103 regarding data transmission from AP102 to STA103.
  • the BlockAcgreement may be constructed independently for each link, or may be performed only on one representative link (for example, link 104), and may be secondarily constructed on the other link.
  • the ADDBA Request frame and the ADDBA Response frame include a BlockAckPolicy parameter, and the communication device that receives the frame transmits an ACK frame when the parameter is agreed.
  • the BlockAckPolicy parameter is set to Medium (Immeditate BlockAck) or Delay (Delayed BlockAck).
  • BAR BlockAck Request
  • Delay Delay
  • FIG. 4 is the case of the Immuno setting, the AP102 transmits a BlockAck Request (BAR) frame as a request frame, and the STA 103 returns the BlockAck frame in response to receiving the frame.
  • BAR BlockAck Request
  • STA103 returns an ACK frame (instead of replying to the BlockAck frame of F408). Then, the STA 103 transmits the BlockAck frame in the TXOP (Transmission Opportunity) period acquired thereafter.
  • TXOP Transmission Opportunity
  • the ADDBA Request frame includes various parameters (Starting Sequence Number, etc.) of information regarding the start number of the data to be transmitted in one BA session (Starting Sequence Control).
  • Start Sequence Number can be determined by the exchange of ADDBA Request / Response. Subsequent updates of the Starting Sequence Number may follow the methods specified in the IEEE 802.11 standard.
  • the ADDBA Request / Response frame may include a BA Type / BAR Type supported by the own device.
  • the frame may include information on whether or not to support New BA / New BAR described later using FIGS. 5A to 7C (supports any one or more of the configuration examples 1 to 7 described later). Information on whether to do it may also be included).
  • the communication device that has received the frame records and manages the BA Type / BAR Type supported by the communication partner device.
  • connection management unit 303 of each of AP102 and STA103 records and manages the above-mentioned various parameters and information for TID in the storage unit 201 at the time of constructing the BlockAcgreement.
  • the AP102 can transmit a plurality of data frames before receiving the ACK frame from the STA103 which is the communication partner device (opposite communication device). For example, the AP 102 transmits a plurality of MPDUs (data frames) in the F406 (data transmission process), and the STA 103 transmits a Block Acck frame in the F408 as an acknowledgment of the plurality of MPDUs. As described above, the example of FIG. 4 is a case where Immeditate is set in the BlockAckPolicy parameter. After AP102 transmits (F407) a BlockAck Request frame (in response to the transmission), STA103 returns a BlockAck frame (F408).
  • the BlockAck Request frame transmission (F407) and the BlockAck frame reply (F408) may be executed independently for each link, or may be performed only on one representative link (for example, link 104).
  • the information carried by the representative link may include information for the other link.
  • AP102 transmits a BlockAckRequest frame to STA103 by F407.
  • the AP102 may set the Ack Policy subfield included in the QoS Control field in at least one MPDU in the MPDU group of F406 to Impact BlockAcque Request. That is, the AP 102 may include an Implicit BlockAck Request (request information) that requests a BlockAck frame from the STA 103 in at least one of the MPDU groups. As a result, the AP102 can request the BlockAck frame from the STA103 without transmitting the BlockAckRequest frame (F407).
  • Implicit BlockAck Request request information
  • the transmission of the Impact Block Request and the reply of the Block Ac frame may be executed independently for each link, or may be performed only by one representative link (for example, the link 104).
  • the information carried by the representative link may include information for the other link.
  • the BlockAck frame returned by F408 includes information set based on the sequence number of the data frame transmitted in the data transmission of F406.
  • the sequence numbers returned in the BlockAck frame are continuous.
  • the specifications are such that whether or not a data frame (packet) for the number of bits that can be expressed by the BlockAck Bitmap starting from the Starting Sequence Number can be received is indicated by the BlockAck Bitmap.
  • the data receiving device cannot receive the data of the sequence numbers 2 and 4 at the link 104 and the data of the sequence numbers 1 and 3 at the link 105, respectively. Therefore, the receiving side device expresses these sequence numbers as loss frames on the BlockAck Bitmap. In each link, the data of the sequence number expressed as a loss frame is expected to enter the retransmission process by the transmitting side device even though it is transmitted by another link, which causes bandwidth consumption due to unnecessary retransmission. Will end up.
  • the data transmitting side device transmits the data including the sequence number information of the data transmitted / not transmitted in each link in at least one data frame set in the BlockAck Request frame or the Implicit BlockAck Request. It is configured to be operable.
  • the BlockAck Request frame will be described as an example, but the same description can be applied to the Impact Block Request Request.
  • the data receiving side device is configured to be operable so as to include the information of the sequence number of the data received / not received at each link in the BlockAck frame.
  • FIG. 4 shows an example of data transmission from AP102 to STA103, the following description can be similarly applied to data transmission from STA103 to AP102.
  • FIGS. 5A to 5C show the configurations of the BlockAck Request frame and the BlockAck frame in the 802.11ax standard.
  • Octests and Bits indicate the size of each field.
  • the field labeled variable means variable length.
  • the part indicated by (R) in the figure means that it is valid in the case of the BlockAckRequest frame and is invalid in the case of the BlockAcck frame.
  • the explanation of the field without a reference sign is omitted.
  • FIG. 5A shows the configuration of the BlockAck Request frame and the entire BlockAck frame.
  • the BlockAckRequest frame and the BlockAck frame are composed of a MAC header field 501, a BA (R) Control field 502, a BA Information field 503, and an FCS field.
  • FIG. 5B shows the configuration of the BA (R) Control field 502.
  • the BA (R) Control field 502 is composed of a BA (R) Ack Polycy 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.
  • BA (R) Type 0, 4 to 5, 7 to 9, 11 to 15 are designated as the Reserved area, and in this embodiment, at least one of the Reserved areas is used. Therefore, a new BA (R) Type is specified.
  • the new BA (R) Type proposed in the present embodiment is referred to as New BA (R).
  • FIG. 5C shows the configuration of the BA (R) Information field 503 defined by New BA (R).
  • the BA (R) Information field 503 is composed of a BA (R) Subtype subfield 507 and an ACK Info subfield 506.
  • BA (R) Subtype subfield 507 may be set to 0 as described in Bits.
  • the information corresponding to the BA (R) Subtype may be expressed by using the Reserved area in the BA (R) Type subfield 504 or the Reserved area in the Reserved subfield 505.
  • the names of BA (R) Subtype and ACK Info presented here are examples, and are not limited thereto.
  • Configuration of ACK Info subfield indicating 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 the configuration examples 1 to 3 is stored in the BlockAck Request frame.
  • Configuration examples 1 to 3 are configuration examples in which information regarding the MPDU (data frame) transmitted by the AP 102 is transmitted.
  • the ACK Info subfield 506 includes an ACK Info header section (corresponding to the ACK Info header sections 601, 607, 614) including meta information of the entire ACK Info, and a transmitted frame group (data).
  • ACK Info data unit including specific information (corresponding to frame groups 602, 603, 609, 610, 615, 616) that specifies (frame group).
  • specific information corresponding to frame groups 602, 603, 609, 610, 615, 616) that specifies (frame group).
  • the names of the ACK Info header and the ACK Info data shown here are examples, and are not limited to these.
  • the AP 102 distinguishes the data transmitted to the STA 103 for each link as a frame group for each block of data whose sequence number is a serial number. That is, if the sequence number of the transmitted data is omitted, the frame group is separated there.
  • the STA 103 may send 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.
  • FIG. 6A shows a configuration example 1 of the ACK Info subfield 506.
  • the ACK Info header unit 601 in the configuration example 1 includes information indicating the data length (data length of information that specifies all subsequent frame groups) included in the ACK Info data unit.
  • the information may be information indicating the end of the data frame group.
  • the data length of the subsequent ACK Info unit can be stored in bit units, byte units, and the number of frame groups (in this example, a configuration of 24 bits per frame group). It should be noted that the method is not limited to this method as long as the data length can be shown.
  • the Sequence Number (sequence number) is represented by 12 bits and is represented by a value of 0 to 4095.
  • the start sequence number (Start SN) 604 and the end sequence number (End SN) 605 in each frame group are used as the expression method of the 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 beginning 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.
  • FIG. 6B shows a configuration example 2 of the ACK Info subfield 506.
  • the ACK Info header unit 607 in the configuration example 2 includes information indicating the data length included in the ACK Info data unit, as in the configuration example 1.
  • the data length of the subsequent ACK Info unit is stored in bit units, byte units, and the number of frame groups (in this example, 12 per frame group + the configuration of the number of bits indicated by the Count Size unit 608). Can be done. It should be noted that the method is not limited to this method as long as the data length can be shown.
  • the ACK Info header section 607 further includes a Count Size section 608.
  • the Count Size unit 608 indicates the size of the Count unit (corresponding to the Count unit 612) of the frame groups 609 and 610.
  • the start sequence number (Start SN) 611 and the Count unit 612 in each frame group are used as the expression method of the frame groups 609 and 610.
  • the start sequence number 611 indicates the sequence number of the MPDU corresponding to the head of each transmission frame group, as in the configuration example 1.
  • the Count unit 612 starts from the start sequence number 611 and holds information indicating the number of MPDUs having the number of consecutive sequence numbers transmitted. If the size of the Count unit specified by the Count Size unit 608 is small, the maximum number of MPDUs that can be expressed as a frame group is small, but the data length required to express one frame group can be reduced.
  • the size of the Count unit specified by the Count Size unit 608 is large, the maximum number of MPDUs that can be expressed as a frame group becomes large, but the data length required to express one frame group becomes large.
  • Which Count Size is used is not limited in this example.
  • the start sequence number can be represented by 12 bits.
  • FIG. 6C shows a configuration example 3 of the ACK Info subfield 506.
  • the ACK Info header unit 614 in the configuration example 3 includes information indicating the data length included in the ACK Info data unit, as in the configuration example 1.
  • the data length of the subsequent ACK Info section is set in bit units, byte units, and the number of frame groups (in this example, 16 per frame group + the configuration of the number of bits shown in the Count Size part of each frame). Can be stored. It should be noted that the method is not limited to this method as long as the data length can be shown.
  • the start sequence number (Start SN) 617, the Count Size unit 618, and the Count unit 619 in each frame group are used.
  • the Count Size unit 608 stored in the ACK Info header unit 607 in Configuration Example 2 is stored in each frame group as the Count Size unit 618. This makes it possible to set an appropriate Count Size in each frame group without fixing the Count Size in the header portion. If the number of frames to be expressed in the frame group is large, the Count Size can be set large, and if the number of frames is small, the Count Size can be set small.
  • Configuration of ACK Info subfield indicating MPDU not transmitted (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 the configuration examples 4 to 6 is stored in the BlockAck Request frame transmitted from the transmitting side of the data frame.
  • Configuration examples 4 to 6 are configuration examples in which information regarding the MPDU that the AP102 has not transmitted is transmitted.
  • the ACK Info subfield 506 includes an ACK Info header section (corresponding to the ACK Info header sections 721, 724, 727) including meta information of the entire ACK Info, and a transmitted frame group (data).
  • ACK Info data unit including specific information (corresponding to frame groups 702, 703, 709, 710, 715, 716) that specifies (frame group).
  • specific information corresponding to frame groups 702, 703, 709, 710, 715, 716) that specifies (frame group).
  • the names of the ACK Info header and the ACK Info data shown here are examples, and are not limited to these.
  • AP102 distinguishes the data that has not been transmitted to STA103 for each link as a frame group for each block of data whose sequence number is serial. That is, if there is an omission in the sequence number of the data that has not been transmitted, the frame group is separated there.
  • the ACK Info subfield 506 By including the information about all the frames that have not been transmitted in the ACK Info subfield 506, it is possible to provide the information about the frame for which the STA 103 is requested to acknowledge.
  • the STA 103 may send an acknowledgment for the requested frame.
  • the ACK Info header section includes information indicating the start sequence number and the end sequence number of the newly transmitted frame group. This is because the configurations 4 to 6 include information about the MPDU that has not been transmitted to the ACK Info data unit, and therefore it is not possible to specify from where to where the sequence number was transmitted by itself.
  • the sequence number of the transmitted MPDU can be specified by combining the information indicating the start sequence number and the end sequence number of the frame group expressed as the entire ACK Info subfield 506 with the sequence number of the MPDU that has not been transmitted.
  • the data length included in the ACK Info header part may or may not include the data length of the ACK Info header part.
  • FIG. 7A shows a configuration example 4 of the ACK Info subfield 506.
  • the ACK Info header unit 721 in the configuration example 4 includes information 701 indicating the data length included in the ACK Info data unit.
  • the information may be information indicating the end of the data frame group.
  • the data length of the subsequent ACK Info unit can be stored in bit units, byte units, and the number of frame groups (in this example, a configuration of 24 bits per frame group). It should be noted that the method is not limited to this method as long as the data length can be shown.
  • the Sequence Number (sequence number) is represented by 12 bits and is represented by a value of 0 to 4095.
  • the start sequence number (Start SN) 704 and the end sequence number (End SN) 705 in each frame group are used as the expression method of the 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 beginning of each non-transmitted frame group.
  • the end sequence number 705 indicates the sequence number of the MPDU corresponding to the end of the frame group not transmitted.
  • the start sequence number 722 and the end sequence number 723 of the frame group transmitted in the ACK Info header unit 721 are included.
  • FIG. 7B shows a configuration example 5 of the ACK Info subfield 506.
  • the ACK Info header unit 607 in the configuration example 5 includes information indicating the data length included in the ACK Info data unit, as in the configuration example 4.
  • the data length of the subsequent ACK Info unit is stored in bit units, byte units, and the number of frame groups (in this example, 12 per frame group + the configuration of the number of bits indicated by the Count Size unit 708). Can be done. It should be noted that the method is not limited to this method as long as the data length can be shown.
  • the ACK Info header section 724 further includes a Count Size section 708.
  • the Count Size section 708 also 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.
  • the start sequence number (Start SN) 711 and the Count unit 712 in each frame group are used as the expression method of the frame groups 709 and 710.
  • 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, as in the configuration example 4.
  • the Count unit 712 starts from the start sequence number 711 and holds information indicating the number of MPDUs having consecutive sequence numbers that are not transmitted. If the size of the Count unit specified by the Count Size unit 708 is small, the maximum number of MPDUs that can be expressed as a frame group is small, but the data length required to express one frame group can be reduced.
  • the size of the Count unit specified by the Count Size unit 708 is large, the maximum number of MPDUs that can be expressed as a frame group becomes large, but the data length required to express one frame group becomes large.
  • Which Count Size is used is not limited in this example.
  • the start sequence number can be represented by 12 bits.
  • the ACK Info header unit 724 includes a count unit 726 which means the start sequence number 725 of the transmitted frame group and the total number (number) from the start sequence number to the end sequence number.
  • the size of the Count section 726 in the ACK Info header section 724 is not specified by the Count Size section 708 and is fixed to 12 bits, or even if the Count Size section showing the information of the Count section 726 is separately held in the ACK Info header section. good.
  • FIG. 7C shows a configuration example 6 of the ACK Info subfield 506.
  • the ACK Info header unit 727 in the configuration example 6 includes information indicating the data length included in the ACK Info data unit, as in the configuration example 4.
  • the data length of the subsequent ACK Info section is set in bit units, byte units, and the number of frame groups (in this example, 16 per frame group + the configuration of the number of bits shown in the Count Size part of each frame). Can be stored. It should be noted that the method is not limited to this method as long as the data length can be shown.
  • the start sequence number (Start SN) 717, the Count Size unit 718, and the Count unit 719 in each frame group are used.
  • the Count Size unit 708 stored in the ACK Info header unit 607 in the configuration example 5 is stored in each frame group. This makes it possible to set an appropriate Count Size in each frame group without fixing the Count Size in the header portion. If the number of frames to be expressed in the frame group is large, the Count Size can be set large, and if the number of frames is small, the Count Size can be set small.
  • the ACK Info header section 727 is a Count section 730 which means the total number of the transmitted frame group from the start sequence number 728 to the end sequence number, and the Count Size section 729 which shows the size information of the Count section 730. including.
  • Configuration example 7 is a configuration diverted from the format of Compressed BlockAck Variant used in BA Type: Compressed specified in the 802.11 standard.
  • Fragment Number (4 bits), Starting Sequence Number (12 bits), and Block Acck Bitmap (8 or 32 bytes) are stored in the ACK Info subfield 506 (sequence information).
  • the size of Block Acack Bitmap and the maximum number of MSDU / A-MSDU that can be expressed at one time are determined according to the value of Fragment Number and conform to the 802.11ax standard.
  • a value indicating the start sequence number of the transmitted data frame is set, and each bit of the Block Acck Bitmap is associated and transmitted for the data frames after the start sequence number as the start point.
  • MPDU transmitted data frame
  • the configuration examples 1 to 7 have been described by taking the BlockAckRequest frame transmitted by AP102 (data transmitting side device) as an example, but the BlockAck frame transmitted by STA103 (data receiving side device) also has a configuration based on the above configuration. Applicable. For example, with respect to the configuration examples 1 to 3, as the configuration of the ACK Info subfield indicating the received MPDU, the “transmitted frame (group)” in the above description of the configuration examples 1 to 3 is “received frame (group)”. Should be read as.
  • the “non-transmitted frame (group)” in the above description of the configuration examples 4 to 6 cannot be received.
  • the "sent frame (group)” may be read as the “received frame (group)” in the "frame (group)".
  • a value indicating the start sequence number of the received data frame (MPDU) may be set in the Starting Sequence Number.
  • the reception result for the data frame transmitted by the data transmitting side device may be set in each bit of Block Acack Bitmap. A processing example relating to the BA frame when the configuration example 7 is used will be described later.
  • configuration based on the above configuration examples 1 to 6 can also be applied to the data frame set in the Impact Block Ask Request.
  • the configurations of the above configuration examples 1 to 6 may be similarly applied to the BAR Control field and the BAR Information field in the data frame.
  • the transmitting side of the BlockAck Request frame can specify (specify) in the frame whether the ACK Info subfield 506 is configured in any of the configuration examples 1 to 7, and notify the receiving side.
  • which of the configurations 1 to 7 is used can be specified by using at least one of the BAR Type subfield 504, the Reserved subfield 505, and the BAR Subtype subfield 507.
  • BAR Type 0, which means Reserved in the BAR Type subfield 504
  • BAR Type which means that any one of Configuration Examples 1 to 7 is used.
  • which of the configuration examples 1 to 7 is used is specified by using at least 3 bits of the other Reserved area of the BAR Type subfield 504, the Reserved subfield 505, and the BAR Subtype subfield 507. May be.
  • the configuration example 1 is used when the bit 0000 is specified in the BAR Subtype subfield 507
  • the configuration example 2 is used when the bit 0001 is specified. It may be defined as such.
  • any one of the configuration examples 1 to 7 is used by combining the existing BAR Type subfield 504 and the predetermined (sub) field.
  • the BAR Type subfield 504 is set to Multi-TID or Multi-STA.
  • the BAR Type subfield 504 is set to Multi-TID, it may be specified that any of the configuration examples 1 to 7 is used by using the area of the Reserved subfield 505.
  • the communication partner device supports New BAR (that is, the configuration of the ACK Info subfield 506 of Configuration Examples 1 to 7) according to the present embodiment (whether or not the communication partner device has capability information for New BAR Type) is based on the standard. It may be stipulated that the response is mandatory. Alternatively, in the case of the example of FIG. 4, the ability information may be exchanged via the exchange of the ADDBA Request / Response frame between AP102 and STA103 (during the construction of BlockAccrement). Alternatively, the ability may be negotiated through the exchange of other management frames.
  • FIG. 8 is a flowchart of a frame transmission process by the data frame transmission side. The process may be started after the AP 102 establishes a wireless connection with the communication partner device (STA103 in the example of FIG. 4) and finishes exchanging the ADDBA Request / Response frame.
  • STA103 the communication partner device
  • connection management unit 303 of each of the AP 102 and the STA 103 records various parameters such as the Starting Sequence Number in the BA session in the storage unit 201 at the time of constructing the BlockAcgreement (F402 to F405 in FIG. 4). It shall be managed. Further, the connection management unit 303 of each of AP102 and STA103 stores information of BA Type (which may include a new BA (R) Type by New BA (R) of the present embodiment) supported by the communication partner device in the storage unit 201. It shall be recorded and managed.
  • BA Type which may include a new BA (R) Type by New BA (R) of the present embodiment
  • the frame transmission / reception unit 304 starts the frame transmission process.
  • the frame transmission / reception unit 304 first determines whether the frame to be transmitted is a data frame as a frame transmission process (S801). This can be determined, for example, by confirming whether or not 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 it is "10", it can be determined that it is not a data frame, and if it is not, it can be determined that it is not a data frame.
  • the frame transmission / reception unit 304 executes the data frame generation / transmission process (S802). Details of the processing of S802 will be described later with reference to FIG.
  • the frame generation unit 302 determines whether to generate and transmit a BlockAck Request (BAR) frame (S803). This may be determined according to, for example, the cumulative number of data frames (MPDU) transmitted since the frame transmission / reception unit 304 finally received the BlockAck frame, or may be determined according to other rules.
  • BAR BlockAck Request
  • the frame generation unit 302 transmits the BAR frame
  • the frame transmission / reception unit 304 executes the BAR frame generation / transmission process (S804), and then ends. .. Details of the processing of S804 will be described later with reference to FIG.
  • AP102 ends the frame transmission process.
  • AP102 executes a process corresponding to various frames conforming to the 802.11 standard (S805), and ends the process. Since the processing of S805 has little relation to the present embodiment, the description thereof will be omitted.
  • FIG. 9 is a flowchart of a data frame generation / transmission process.
  • the sequence number of the data frame 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. ..
  • the connection management unit 303 of the AP 102 records and manages the sequence number of the data frame to be transmitted by the frame transmission / reception unit 304 in the storage unit 201 as transmitted (as the transmitted sequence number) (S901).
  • the connection management unit 303 can determine whether or not the data of an arbitrary sequence number has been transmitted by using the information of the number.
  • the management of the transmission sequence number related to the connection is started at the stage when the 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.
  • the sequence number of the frame to be transmitted first 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.
  • the frame generation unit 302 sets the Ac Poly (sets the Ac Poly subfield in the QoS Control field) (S902). For example, it can be shown that New BAR is supported by using Bit5 and Bit6 of the QoS Control field. For example, when it is confirmed that AP102 and STA103 support New BAR at the time of BlockAckAgreement construction, the frame generation unit 302 can be set to Bit5: 1 and Bit6: 0 in the QoS Control field. In addition, by showing that New BAR is supported, it can be shown that Impact BlockAck Request is set in the data frame.
  • the frame generator 302 After setting the Ac Policy, information is added to the Frame Body according to the BAR Type supported by AP102 and STA103 (S903). For example, when Bit5: 1 and Bit6: 0 are set in the QoS Control field as described above, the frame generator 302 specifies the transmitted / not transmitted sequence number described in FIGS. 6 and 7. Information can be included in the FrameBody. In this case, the receiving side STA103 can analyze the FrameBody and extract the information of the sequence number of the data transmitted by the AP102. When the STA 103 receives a data frame containing such an Ac Policy, it can return a Block Acck frame without receiving the Block Ac Request frame. Subsequently, the frame generation unit 302 generates the remaining frame unit 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 communication partner device (STA103) (S905).
  • the frame transmission / reception unit 304 transmits the data frame generated by the
  • FIG. 10 is a flowchart of the BAR frame generation / transmission process.
  • the connection management unit 303 of each of the STA 103 and the AP 102 records and manages information such as the BAR Type (which may also include the New BAR Type according to the present embodiment) supported by the communication partner device in the storage unit 201. It is assumed that you are doing. Also, with respect to frame generation, reference is made to FIGS. 5A-5C.
  • connection management unit 303 of the AP102 confirms the BAR type (supported by the own device and the STA103) that the connection is supported (S1001).
  • BAR type supported by the own device and the STA103
  • S1002 the connection management unit 303 confirms the transmitted sequence number (S1002).
  • the frame generation unit 302 generates a BAR frame using the information confirmed in S1001 and S1002.
  • the frame generation unit 302 determines the configuration of the ACK Info subfield 506 in the BAR Information field 503 (S1003).
  • the frame generation unit 302 can determine the configuration of the ACK Info subfield 506 based on the support BAR Type confirmed in S1001.
  • the frame generator 302 is any of the configuration examples 1 to 7 as the configuration of the ACK Info subfield 506. Can be decided to use. It should be noted that the use of any of the configurations of the above configuration examples 1 to 7 may be fixedly set in the AP 102 in advance, or set (determined) by an input operation by the user via the input unit 204. May be done.
  • the frame generation unit 302 generates the BA Control field 502 and the BAR Information field 503 according to the configuration of the ACK Info subfield 506 determined in S1003 and so as to specify (designate) the configuration (S1004). .. As described above, it is possible to specify that any of the configuration examples 1 to 7 is used for the ACK Info subfield 506 in various subfields in the BAR Control field 502 / BAR Information field 503. Further, the frame generation unit 302 generates the BAR Information field 503 based on the transmitted sequence number confirmed in S1002. Regarding the specific contents of the BAR Information field, the sequence number confirmed in S1002 is expressed in any of the formats described in the configuration examples 1 to 7.
  • the frame generation unit 302 generates the remaining frame unit to complete the BAR frame (S1005).
  • the frame transmission / reception unit 304 transmits the BAR frame generated by the frame generation unit 302 to the communication partner device (STA103).
  • FIG. 11 is a frame reception processing flowchart.
  • the frame transmission / reception unit 304 of the AP 102 receives a wireless frame from the communication partner device (STA103)
  • the frame analysis unit 301 starts the analysis processing of the received frame. If the frame is not addressed to itself, or if the frame is broken (for example, the FCS value is invalid), the frame may be discarded without starting this process.
  • the frame analysis unit 301 first determines whether the received frame is a BA (BlockAck) frame (S1101). This is to confirm, for example, whether the Type field in the Frame Control Field included in the MAC header in the MAC frame format specified by the IEEE802.11 standard is "01" and the Subtype field is "1001". Can be determined by When the Type field is "01" and the Subtyping field is "1001", it can be determined that it is not a BlockAck frame, and in other cases, it is not a BA frame.
  • BA BlockAck
  • the AP102 executes BA frame processing (S1102).
  • the BA frame reception process of S1102 will be described later with reference to FIG.
  • AP102 executes a process corresponding to various frames conforming to the 802.11 standard (S1103), and ends the process. Since the processing of S1103 has little relation to the present embodiment, the description thereof will be omitted.
  • FIG. 12 is a flowchart of BA frame reception processing.
  • the connection management unit 303 of each of the STA 103 and the AP 102 records and manages information such as the BA Type (which may also include the New BA Type according to the present embodiment) supported by the communication partner device in the storage unit 201. It is assumed that you are doing. Also, with respect to frame generation, reference is made to FIGS. 5A-5C.
  • connection management unit 303 of the AP102 confirms the BA Type (supported by the own device and the STA103) that the connection is supported (S1201). This information has been confirmed and recorded by the connection management unit 303 at the time of constructing the Block Ac Agreement. The AP102 can switch the subsequent processing according to the BA Type confirmed here.
  • the connection management unit 303 of the AP 102 confirms the BA Information field 503 included in the received BA frame (S1202).
  • the format of the BA Information field 503 may change according to the BA Type, but the connection management unit 303 extracts the sequence number (received sequence number) recorded as received by the STA 103 from the information contained in the field (received sequence number). S1203).
  • the BA Information field 503 may include a BlockAck Starting Sequence Control and a BlockAck Bitmap. The sequence number recorded as received can be calculated from the start point of the received sequence number and the bitmap indicating whether or not each sequence number is received from there.
  • connection management unit 303 updates the managed transmitted sequence number (S1204). Since the AP102 does not need to retransmit the frame confirmed to have been received by the STA 103 in S1203, it is not necessary to manage that the frame has been transmitted. Therefore, the connection management unit 303 cancels the recording that the transmission has been completed. Subsequently, the connection management unit 303 may delete the frame whose recording has been canceled in S1204 from the transmission buffer (S1205).
  • FIG. 13 is a flowchart of a frame reception process by the data frame receiving side. The process may be started after the STA 103 establishes a wireless connection with the communication partner device (AP102 in the example of FIG. 4) and finishes the exchange of the ADDBA Request / Response frame.
  • the communication partner device AP102 in the example of FIG. 4
  • connection management unit 303 of each of the STA 103 and the AP 102 records various parameters such as the Starting Sequence Number in the BA session in the storage unit 201 at the time of constructing the BlockAcgreement (F402 to F405 in FIG. 4). It shall be managed. Further, it is assumed that the connection management unit 303 of each of the STA 103 and the AP 102 records and manages the information of the BA Type (which may also include the New Type according to the present embodiment) supported by the communication partner device in the storage unit 201.
  • the BA Type which may also include the New Type according to the present embodiment
  • the frame analysis unit 301 starts the analysis processing of the received frame. If the frame is not addressed to itself, or if the frame is broken (for example, the FCS value is invalid), the STA 103 may discard the frame without starting this 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 or not 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 it is "10", it can be determined that it is not a data frame, and if it is not, it can be determined that it is not a data frame.
  • the connection management unit 303 executes the confirmation processing of the sequence number of the data frame (S1302). Details of the processing of S1302 will be described later with reference to FIG.
  • the frame analysis unit 301 determines whether the received frame is a data frame requesting a BlockAck frame (S1303). This is, for example, to confirm whether or not the Ac Precision subfield included in the QoS Control field in at least one MPDU among the MPDUs included in the data frame is set to Impact BlockAck Request (“00”).
  • the frame analysis unit 301 determines that the received frame is a data frame requesting a BlockAck frame (Yes in S1303), and the process 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 requesting a BlockAck frame, and ends the frame reception process. In S1304, AP102 performs BlockAck (BA) frame generation / transmission processing. Details of the processing of S1304 will be described later with reference to FIG.
  • BA BlockAck
  • the frame analysis unit 301 determines whether the received frame is a BAR (BlockAck Request) frame (S1305). For example, when the above-mentioned Type field in the data frame is "01" and the Subtype field in the Frame Control Field in the MAC header is "1000", it can be specified 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 the BA frame generation / transmission process.
  • the BAR frame may contain information about the start number of the data.
  • the STA 103 executes a process corresponding to various 802.11 standard-compliant frames (S1306) and ends the process. Since the treatment of S1306 has little relation to the present embodiment, the description thereof will be omitted.
  • FIG. 14 is a flowchart of the data frame sequence number confirmation 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. ..
  • the connection management unit 303 starts managing the reception sequence number (sequence number of the received data frame) related to the connection at the stage when the 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 unreceived sequence numbers (sequence numbers of data frames that are not recorded as received).
  • connection management unit 303 of the STA 103 confirms whether the sequence number of the data frame (MPDU) is an unreceived sequence number (S1401). That is, the connection management unit 303 collates the received data frame sequence number information with the received sequence number recorded in the storage unit 201, and determines whether or not the received data frame sequence number is an unreceived sequence number. ..
  • the connection management unit 303 When 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 as a reception sequence number in the storage unit 201 (S1402), and ends. On the other hand, when the sequence number of the received data frame is the received sequence number (No in S1401), the received data frame has already been received, it is regarded as a duplicate frame, the data frame is discarded (S1403), and the process ends. do.
  • FIG. 15 is a flowchart of BA frame generation / transmission processing.
  • the connection management unit 303 of each of the STA 103 and the AP 102 receives information such as the BA Type (which may also include the New BA Type according to the present embodiment) supported by the communication partner device, the Starting Sequence Number in the BA session, and the like. It is assumed that it is recorded and managed in the storage unit 201. Also, with respect to frame generation, reference is made to FIGS. 5A-5C.
  • the connection management unit 303 of the STA 103 confirms the BA Type supported by the connection (supported by the own device and the AP102) (S1501). Depending on the support status of BA Type confirmed here, the frame generation unit 302 can determine the content of the BlockAck frame generated in S1504 and S1505. Next, the connection management unit 303 of the STA 103 confirms the Starting Sequence Number in the BA session (S1502). As described above, the initial value of the Starting Sequence Number is determined at the time of constructing the BlockAccrement, and can be subsequently updated according to the method specified in the IEEE802.11 standard. Subsequently, the connection management unit 303 confirms the reception sequence number (sequence number recorded as received) (S1503).
  • the frame generation unit 302 generates a Block Ac frame using the information confirmed in S1001 to S1003.
  • the frame generation unit 302 determines the configuration of the ACK Info subfield 506 in the BA Information field 503 (S1504).
  • the frame generation unit 302 can determine the configuration of the ACK Info subfield 506 based on the support BA Type confirmed in S1501.
  • the frame generator 302 is any of the configuration examples 1 to 7 as the configuration of the ACK Info subfield 506. Can be decided to use.
  • any of the configurations of the above configuration examples 1 to 7 may be fixedly set in the STA 103 in advance, or set (determined) by an input operation by the user via the input unit 204. May be done. Further, the frame generation unit 302 responds to the reception status of the sequence number confirmed in S1003. You may decide to use any of Configuration Examples 1-7 to configure the ACK Info subfield 506 with the smallest data size.
  • the frame generation unit 302 generates the BA Control field 502 and the BA Information field 503 according to the configuration of the ACK Info subfield 506 determined in S1504 and so as to specify (designate) the configuration (S1505). .. As described above, it is possible to specify that any of the configuration examples 1 to 7 is used for the ACK Info subfield 506 in various subfields in the BA Control field 502 / BA Information field 503.
  • the frame generation unit 302 generates the MAC header field 501 and the FSC field shown in FIG. 5A to complete the MAC frame, and also generates the PHY unit to complete the BlockAck frame (S1506).
  • the frame transmission / reception unit 304 transmits the BlockAck frame generated by the frame generation unit 302 to the communication partner device (AP102) (S1507).
  • the confirmation response of the transmitted frame and the retransmission process when the confirmation response is not received for a certain period of time are executed in accordance with the provisions of the 802.11 standard.
  • STA103 is.
  • the received record is reset.
  • the connection management unit 303 of the STA 103 is notified in the BlockAck frame among the received sequence numbers managed.
  • For completed sequence numbers reset the received records. This makes it possible to manage the sequence number when the sequence number goes around.
  • BA frame according to configuration example 7 An example of a BA frame according to the configuration example 7 and a processing example using the frame will be described. Although the case where the device on the data frame transmission side is AP102 as shown in FIG. 4 will be described as an example, this description can be similarly applied to the case where the STA 103 is the main operating body. Also, with respect to frame generation, reference is made to FIGS. 5A-5C.
  • the STA 103 can acquire the sequence number of the data frame transmitted from the AP 102 by the BAR Information (information set in the BAR Information field 503) in the BAR frame.
  • the STA 103 efficiently uses the Bitmap bits by using the sequence number of the transmitted data frame in the ACK Info subfield 506 to associate each bit represented by the BlockAckBitmap with the sequence number. Can be done.
  • BA Information (information set in BA Information field 503) stores Fragment Number (4 bits), Starting Sequence Number (12 bits), and Block Acck Bitmap (8 or 32 bytes) as described above with respect to Configuration Example 7. do.
  • the size of Block Ac Bitmap and the maximum number of MSDU / A-MSDU that can be expressed at one time are determined according to the value of Fragment Number and conform to the 802.11ax standard.
  • the Starting Sequence Number a value indicating the start sequence number of the frame transmitted by the AP (communication partner device) presented during the BAR Information is set.
  • For the subsequent frames only the sequence number presented by AP102 as transmitted by BAR Information is used to indicate whether or not each bit of Block Acack Bitmap has been associated and transmitted. It can be determined that the frame in which the bit is set to 1 has been transmitted, and the frame in which the bit is set to 0 has not been transmitted. The meaning of 0 and 1 may be reversed.
  • BlockAck Bitmap the first bit corresponds to the sequence number 1, the second bit corresponds to the sequence number 3, and the third bit corresponds to the sequence number 5. Subsequent bits are not used, but can be set to 0 as unreceived.
  • a BlockAck frame containing the content of "101" as a BlockAck Bitmap is transmitted from the STA 103 to the AP 102.
  • the AP102 receives the BlockAck frame and compares it with the BAR Information transmitted by itself, so that the frame to which each bit corresponds can be specified.
  • the sequence number 3 is regarded as a transmission failure and is retransmitted.
  • the confirmation response of the transmitted frame and the retransmission process when the confirmation response is not received for a certain period of time are executed in accordance with the provisions of the 802.11 standard.
  • STA103 is.
  • the received record is reset.
  • the connection management unit 303 of the STA 103 is notified in the BlockAck frame among the received sequence numbers managed.
  • For completed sequence numbers reset the received records. This makes it possible to manage the sequence number when the sequence number goes around.
  • the processing flow shown in FIGS. 8 to 15 is an example of realizing the present proposal, and the order of each processing is not limited as long as it fulfills the same function. Further, for the processing not described in this processing flow, the processing specified in the 802.11 standard is followed.
  • the present invention supplies a program that realizes one or more functions of the above-described embodiment to a system or device via a network or storage medium, and one or more processors in the computer of the system or device reads and executes the program. It can also be realized by the processing to be performed. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置は、複数のリンクを用いて複数のデータフレームを通信相手装置へ送信し、該送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを該信相手装置に送信し、該要求フレームを送信することに応答して該通信相手装置から該Ａｃｋフレームを受信する。該要求フレームは、該複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、該シーケンス情報は、該各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含む。

Description

通信装置、通信装置の制御方法、およびプログラム
　本発明は、無線通信技術に関するものである。
　ＩＥＥＥ（Institute of Electrical and Electronics Engineers、米国電気電子技術者協会）が策定している無線ＬＡＮ（Local Area Network）通信規格として、ＩＥＥＥ８０２．１１シリーズが知られている。ＩＥＥＥ８０２．１１シリーズ規格としては、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ規格などの規格がある（特許文献１）。
　ＩＥＥＥ８０２．１１ａｘ規格では、複数の無線パケットの受信について、一つのフレームで確認応答（Acknowledgement（ＡＣＫ））を送信できるＢｌｏｃｋＡｃｋフレームの拡張仕様が開示されている。ＩＥＥＥ８０２．１１ａｘ規格では、ＢｌｏｃｋＡｃｋフレーム中のＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐで表現できるＭＰＤＵ（MAC（Media Access Control） Protocol Data Unit）の数を、ＩＥＥＥ８０２．１１ａｃまでの６４から２５６に拡張する仕様が開示されている。一度に確認応答が行えるＭＰＤＵ数が増えることで、スループットの向上を実現している。
特開２０１８－５０１３３号公報
　ＩＥＥＥでは、さらなるスループットの向上や周波数利用効率の改善のため、ＩＥＥＥ８０２．１１シリーズの新たな規格として、ＩＥＥＥ８０２．１１ｂｅ規格の策定が検討されている。ＩＥＥＥ８０２．１１ｂｅ規格では、一度に確認応答が行えるＭＰＤＵの数をさらに５１２や１０２４へ拡張することが提案されている。また、ＩＥＥＥ８０２．１１ｂｅ規格では、無線装置間で複数の無線リンクを用いて通信するＭｕｌｔｉ－Ｌｉｎｋ通信や複数の無線アクセスポイントが一つの無線端末と接続し通信するＭｕｌｔｉ－ＡＰ通信の方式が検討され、複数リンク間にまたがった確認応答の方式についても検討が進められている。
　無線装置間で複数のリンクを使用して通信を行う場合、送信側装置は、各リンクで異なる塊のシーケンス番号のデータフレームを送信することが想定される。このとき、受信側装置は、各リンクで一部分が歯抜けのシーケンス番号のデータフレームが受信し得る。従来では、このような場合に対して効率的な確認応答の方式が提案されていなかった。
　上記課題を鑑み、本発明は、複数リンクを用いた通信において効率的な確認応答制御を実現するための技術を提供することを目的とする。
　上記目的を達成するため、本発明の一態様に係る無線通信装置は、以下の構成を有する。すなわち、ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含む。
　本発明によれば、複数リンクを用いた通信において効率的な確認応答制御が実現される。
　本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。
　添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
ネットワーク構成例を示す図である。 通信装置（ＳＴＡ、ＡＰ）のハードウェア構成例を示す。 通信装置（ＳＴＡ、ＡＰ）の機能構成例を示す。 ＡＰとＳＴＡ間におけるデータ通信のための通信シーケンス図を示す。 ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成を示す。 ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成を示す。 ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成を示す。 ＡＣＫ　Ｉｎｆｏサブフィールドの構成例１を示す。 ＡＣＫ　Ｉｎｆｏサブフィールドの構成例２を示す。 ＡＣＫ　Ｉｎｆｏサブフィールドの構成例３を示す。 ＡＣＫ　Ｉｎｆｏサブフィールドの構成例４を示す。 ＡＣＫ　Ｉｎｆｏサブフィールドの構成例５を示す。 ＡＣＫ　Ｉｎｆｏサブフィールドの構成例６を示す。 データフレーム送信側によるフレーム送信処理のフローチャートである。 データフレーム生成・送信処理のフローチャートである。 ＢＡＲフレーム生成・送信処理のフローチャートである。 データフレーム送信側によるフレーム受信処理のフローチャートである。 ＢＡフレーム受信処理のフローチャートである。 データフレーム受信側によるフレーム受信処理のフローチャートである。 シーケンス番号確認処理のフローチャートである。 ＢＡフレーム生成・送信処理のフローチャートである。
　以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。
　（ネットワークの構成）
　図１に、本実施形態によるネットワークの構成例を示す。図１は、通信装置（無線通信装置）として、１つのＡＰ（アクセスポイント）（ＡＰ１０２）と１つのＳＴＡ（ステーション／端末装置）（ＳＴＡ１０３）を含んだ構成を示している。なお、本実施形態の説明は、ＡＰとＳＴＡどちらにも適用可能であり、どちらかに限定されない。図１に示すように、ＡＰ１０２が形成するネットワークは円１０１で示される。
　本実施形態では、ＳＴＡ１０３は、ＡＰ１０２と無線リンク１０４および１０５を介してフレームを送受信できるものとする。無線リンク１０４、１０５は２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚ帯の周波数バンドのチャネルを使用することができるが、使用する周波数バンドはこれに限定されるものではなく、６０ＧＨｚ帯のように別の周波数バンドを使用しても良い。ＳＴＡ１０３とＡＰ１０２のＭｕｌｔｉ－Ｌｉｎｋ通信のＣａｐａｂｉｌｉｔｙ情報に応じて、無線リンク１０４、１０５として、２．４ＧＨｚ帯と５ＧＨｚ帯のチャネルを組み合わせて使用しても良いし、６ＧＨｚ帯の中から複数のチャネルを選択して組み合わせて使用しても良い。また、複数のＡＰと一つのＳＴＡ間の通信を扱うＭｕｌｔｉ－ＡＰ通信の場合も同様に、本実施形態を適用することができる。本実施形態においては、無線リンク１０４、１０５の二本の無線リンクを対象に説明するが、これに限定されず、三本以上のリンクを使用する場合にも、本実施形態を適用することができる。
　なお、図１に示すネットワーク構成は一例であり、例えばさらに広範な領域に多数の通信装置を含むネットワークに対して、また、様々な通信装置の位置関係に対して、以下の議論を適用可能である。
　（通信装置の構成）
　次に、本実施形態による通信装置（ＡＰ、ＳＴＡ）の構成について説明する。図２に、本実施形態に係るＡＰのハードウェア構成例を示す。ＡＰは、そのハードウェア構成の一例として、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、１つ以上の通信部２０６及び１つ以上のアンテナ２０７を有する。なお、ＳＴＡもＡＰと同様のハードウェア構成を有し、以下の説明をＳＴＡに適用可能である。
　記憶部２０１は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）の両方、または、いずれか一方により構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部２０１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。
　制御部２０２は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等のプロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサ）、ＦＰＧＡ（Field Programmable Gate Array）等により構成される。制御部２０２は、記憶部２０１に記憶されたプログラムを実行することによりＡＰ全体を制御する。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Operating System）との協働によりＡＰ全体を制御するようにしてもよい。
　制御部２０２は、機能部２０３を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部２０３は、ＡＰが所定の処理を実行するためのハードウェアである。例えば、ＡＰがカメラである場合、機能部２０３は撮像部であり、撮像処理を行う。また、例えば、ＡＰがプリンタである場合、機能部２０３は印刷部であり、印刷処理を行う。また、例えば、ＡＰがプロジェクタである場合、機能部２０３は投影部であり、投影処理を行う。機能部２０３が処理するデータは、記憶部２０１に記憶されているデータであってもよいし、後述する通信部２０６を介して他の通信装置と通信したデータであってもよい。
　入力部２０４は、ユーザからの各種操作の受付を行う。出力部２０５は、ユーザに対して各種出力を行う。ここで、出力部２０５による出力とは、画面上への表示や、スピーカーによる音声出力、振動出力等の少なくとも１つを含む。なお、タッチパネルのように入力部２０４と出力部２０５の両方を１つのモジュールで実現するようにしてもよい。
　通信部２０６は、ＩＥＥＥ８０２．１１規格シリーズに準拠した無線通信の制御や、ＩＰ通信の制御を行う。本実施形態では、通信部２０６は、少なくともＩＥＥＥ８０２．１１ａｘ規格に準拠した処理を実行することができる。また、通信部２０６はアンテナ２０７を制御して、無線通信のための無線信号の送受信を行う。ＡＰは通信部２０６を介して、画像データや文書データ、映像データ等のコンテンツを他の通信装置と通信する。
　無線アンテナ２０７は、それぞれサブＧＨｚ帯、２．４ＧＨｚ帯、５ＧＨｚ帯、及び６ＧＨｚ帯のいずれかが受信可能なアンテナである。無線アンテナ２０７はＭＩＭＯ（Multi-Input Multi-Output）送受信を実現するために、物理的に一本以上のアンテナで構成されても良い。
　ＡＰは、複数のリンクを使用して通信を行う場合、図２に示すように、通信部２０６とアンテナ２０７をそれぞれ複数備えてもよい（図２は一例として通信部２０６とアンテナ２０７はそれぞれ２つ）。この場合、無線リンクごとに一つの通信部２０６、アンテナ２０７を割り当ててもよいし、複数のリンクで一つの通信部２０６、アンテナ２０７を共用しても良い。
　図３に、本実施形態によるＡＰの機能構成例を示す。ＡＰは、その機能構成の一例として、フレーム解析部３０１、フレーム生成部３０２、接続管理部３０３、フレーム送受信部３０４を有する。なお、ＳＴＡもＡＰと同様の機能構成を有し、以下の説明をＳＴＡに適用可能である。
　フレーム解析部３０１は、通信相手装置（対向の通信装置）から受信したフレームを解析する。フレーム生成部３０２は、通信相手装置へ送信するフレーム（無線フレーム）を生成する。接続管理部３０３は、通信相手装置との間の接続を管理する。例えば、接続管理部３０３は、各通信相手装置に対して、接続中のＢｌｏｃｋＡｃｋ（ＢＡ）の取り決め・合意（ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ）や、データのシーケンス番号（Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ）の管理を行う。ＢｌｏｃｋＡｃｋ　ＡｇｒｅｅｍｅｎｔやＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒは、接続内のＴＩＤ（Traffic Identifier（トラフィック（データ）の種別を表す識別子））ごとに管理される。フレーム送受信部３０４は、通信相手装置との間で、通信部２０６とアンテナ２０７（図２）を介してフレームを送受信する。
　（ＡＰとＳＴＡ間の通信シーケンス）
　図４に、ＡＰ１０２とＳＴＡ１０３間におけるデータ通信のための通信シーケンス図を示す。本シーケンスの処理は、ＡＰ１０２およびＳＴＡ１０３のそれぞれの電源が投入されたことに応じて開始されうる。あるいは、本シーケンスの処理は、ＡＰ１０２およびＳＴＡ１０３の少なくとも一方が、ユーザまたはアプリケーションから無線通信の開始を指示されたことに応じて開始されてもよい。ここでは、図１のようにＡＰ１０２とＳＴＡ１０３間で二つの無線リンク１０４、１０５が構成されているものとして説明する。
　初めに、Ｆ４０１にて、ＡＰ１０２とＳＴＡ１０３は、ＩＥＥＥ８０２．１１規格に従接続処理を行うことにより、無線接続を確立する。本実施形態は、通信の暗号化なしの場合および暗号化ありの場合のいずれにも適用可能である。また、暗号化ありの場合の暗号化方式（セキュリティ方式）が、ＷＥＰ（Wired Equivalent Privacy）、ＷＰＡ（Wi-Fi Protected Access）１、ＷＰＡ２、ＷＰＡ３、ＷＰＳ（Wi-Fi Protected Setup）や、他の方式であっても、本実施形態を適用可能である。接続確立は、一つの代表するリンク（例えばリンク１０４）でのみ行い、副次的にもう一方のリンクの接続も行うようにしても良いし、それぞれのリンクで独立して接続が確立されても良い。
　本例では、ＡＰ１０２からＳＴＡ１０３へデータ送信をする例を示す。Ｆ４０１にて接続確立後、Ｆ４０２においてＡＰ１０２は、ＡＤＤＢＡ　ＲｅｑｕｅｓｔフレームをＳＴＡ１０３へ送信し、Ｆ４０３でその確認応答としてＡＣＫフレームを受信する。次にＳＴＡ１０３は、Ｆ４０４にてＡＤＤＢＡ　ＲｅｓｐｏｎｓｅフレームをＡＰ１０２へ送信し、Ｆ４０５でその確認応答としてＡＣＫフレームを受信する。本ＡＤＤＢＡ　ＲｅｑｕｅｓｔとＡＤＤＢＡ　Ｒｅｓｐｏｎｓｅのやりとり（Ｆ４０２～Ｆ４０５の処理）が完了すると、ＡＰ１０２とＳＴＡ１０３の間で、ＡＰ１０２⇒ＳＴＡ１０３へのデータ送信に関して、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔが構築される。ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔの構築は，リンクごとに独立して実行しても良いし、一つの代表リンク（例えばリンク１０４）でのみ行い、副次的にもう一方のリンクでも構築されるようにしても良い。
　ここで、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔについて説明する。ＡＤＤＢＡ　ＲｅｑｕｅｓｔフレームとＡＤＤＢＡ　Ｒｅｓｐｏｎｓｅフレームには、ＢｌｏｃｋＡｃｋＰｏｌｉｃｙパラメータが含まれ、当該フレームを受信した通信装置は、当該パラメータに合意する場合にＡＣＫフレームを送信する。ＢｌｏｃｋＡｃｋＰｏｌｉｃｙパラメータは、Ｉｍｍｅｄｉａｔｅ（Ｉｍｍｅｄｉａｔｅ　ＢｌｏｃｋＡｃｋ）またはＤｅｌａｙ（Ｄｅｌａｙｅｄ　ＢｌｏｃｋＡｃｋ）に設定される。図４の例はＩｍｍｅｄｉａｔｅ設定の場合であり、ＡＰ１０２は要求フレームとしてＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔ（ＢＡＲ）フレームを送信し、ＳＴＡ１０３は当該フレームを受信したことを受けて、ＢｌｏｃｋＡｃｋフレームを返信する。一方、ＢｌｏｃｋＡｃｋＰｏｌｉｃｙがＤｅｌａｙｅｄ設定の場合（不図示）、ＳＴＡ１０３は（Ｆ４０８のＢｌｏｃｋＡｃｋフレームの返信の代わりに）ＡＣＫフレームを返信する。そしてＳＴＡ１０３は、その後に取得したＴＸＯＰ（Transmission Opportunity）期間でＢｌｏｃｋＡｃｋフレームを送信することになる。
　また、ＡＤＤＢＡ　Ｒｅｑｕｅｓｔフレームには、１つのＢＡセッションにおいて送信するデータの開始番号に関する情報（Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌ）の各種パラメータ（Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ（開始シーケンス番号）等）が含まれる。Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒの初期値は、ＡＤＤＢＡ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅのやりとりによって決定されうる。その後のＳｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒの更新はＩＥＥＥ８０２．１１規格規定の方法に従いうる。
　また、ＡＤＤＢＡ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームには、自装置がサポートするＢＡ　Ｔｙｐｅ／ＢＡＲ　Ｔｙｐｅが含まれ得る。例えば、当該フレームには、図５Ａ～図７Ｃを用いて後述するＮｅｗ　ＢＡ／Ｎｅｗ　ＢＡＲをサポートするか否かの情報が含まれ得る（後述する構成例１～７のいずれか１つ以上をサポートするかの情報も含まれ得る）。当該フレームを受信した通信装置は、通信相手装置のサポートするＢＡ　Ｔｙｐｅ／ＢＡＲ　Ｔｙｐｅを記録・管理する。
　本実施形態では、ＡＰ１０２とＳＴＡ１０３それぞれの接続管理部３０３が、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時に、ＴＩＤに対する上記の各種パラメータや情報を記憶部２０１に記録し、管理する。
　ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔが構築された後、ＡＰ１０２は、通信相手装置（対向の通信装置）であるＳＴＡ１０３からのＡＣＫフレームの受信前に、複数のデータフレームを送信することが可能になる。例えば、ＡＰ１０２は、Ｆ４０６（データ送信処理）において複数のＭＰＤＵ（データフレーム）を送信し、ＳＴＡ１０３は複数のＭＰＤＵの確認応答としてＦ４０８においてＢｌｏｃｋ　Ａｃｋフレームを送信する。上記のように、図４の例は、ＢｌｏｃｋＡｃｋＰｏｌｉｃｙパラメータにＩｍｍｅｄｉａｔｅが設定されている場合である。ＡＰ１０２がＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームを送信（Ｆ４０７）した後に（送信したことに応答して）、ＳＴＡ１０３はＢｌｏｃｋＡｃｋフレームを返信（Ｆ４０８）する。
　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームの送信（Ｆ４０７）やＢｌｏｃｋＡｃｋフレームの返信（Ｆ４０８）は、リンクごとに独立して実行しても良いし、一つの代表リンク（例えばリンク１０４）でのみ行ってもよい。この場合、当該代表リンクで搬送される情報の中に、もう一方のリンク向けの情報を含むようにしても良い。
　図４の例では、ＡＰ１０２はＦ４０７でＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームをＳＴＡ１０３へ送信している。これに代えて、ＡＰ１０２は、Ｆ４０６のＭＰＤＵ群の内の少なくとも一つのＭＰＤＵ内のＱｏＳ　Ｃｏｎｔｒｏｌフィールドに含まれるＡｃｋ　ＰｏｌｉｃｙサブフィールドをＩｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔに設定してもよい。すなわち、ＡＰ１０２は、ＭＰＤＵ群の内の少なくとも一つにおいて、ＳＴＡ１０３に対してＢｌｏｃｋＡｃｋフレームを要求するＩｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔ（要求情報）を含めてもよい。これにより、ＡＰ１０２は、ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレーム（Ｆ４０７）を送信せずに、ＳＴＡ１０３へＢｌｏｃｋＡｃｋフレームを要求することができる。このとき、Ｉｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔの送信、ＢｌｏｃｋＡｃｋフレームの返信はリンクごとに独立して実行しても良いし、一つの代表リンク（例えばリンク１０４）でのみ行ってもよい。この場合、当該代表リンクで搬送される情報の中に、もう一方のリンク向けの情報を含むようにしても良い。
　Ｆ４０８で返信されるＢｌｏｃｋＡｃｋフレームには、Ｆ４０６のデータ送信において送信されたデータフレームのシーケンス番号に基づいて設定された情報が含まれる。従来の８０２．１１仕様においては、ＢｌｏｃｋＡｃｋフレームで返すシーケンス番号は連続していることが前提となっていた。例えば、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒを開始点とするＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐで表現できるビット数分のデータフレーム（パケット）について、受信できたか否かをＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐで示す仕様になっていた。この場合、図４のシーケンスのようにデータを複数のリンクでそれぞれ送信する場合に問題となる。例えば、データの送信側装置が、リンク１０４でシーケンス番号１、３のデータを、リンク１０５でシーケンス番号２、４のデータを送信する場合を考える。この場合、データの受信側装置は、リンク１０４ではシーケンス番号２、４のデータ、リンク１０５ではシーケンス番号１、３のデータをそれぞれ受信できない。そのため、当該受信側装置は、これらのシーケンス番号を、ロスフレームとしてＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐ上で表現してしまう。各リンクにおいて、ロスフレームとして表現されたシーケンス番号のデータは、別リンクで送信されているにも関わらず、送信側装置による再送処理に入ることが想定され、不必要な再送による帯域消費を生じてしまう。
　本実施形態では、データ送信側装置は、ＢｌｏｃｋＡｃｋ　ＲｅｑｕｅｓｔフレームもしくはＩｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔに設定されるすくなくとも一つのデータフレームにおいて、各リンクで送信した／送信していないデータのシーケンス番号の情報を含めて送信するように動作可能に構成される。なお、以下ではＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームを例に説明するが、同様の説明をＩｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔにも適用可能である。また、データ受信側装置は、ＢｌｏｃｋＡｃｋフレームにおいて、各リンクで受信した／受信しなかったデータのシーケンス番号の情報を含めて送信するように動作可能に構成される。
　（ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成）
　続いて、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成について説明する。なお、図４ではＡＰ１０２⇒ＳＴＡ１０３へのデータ送信の例を示したが、以下の説明は、ＳＴＡ１０３⇒ＡＰ１０２へのデータ送信にも同様に適用可能である。
　図５Ａ～５Ｃに、８０２．１１ａｘ規格におけるＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成を示す。図５Ａ～５Ｃ共通の説明として、Ｏｃｔｅｓｔｓ、Ｂｉｔｓはそれぞれのフィールドのサイズを示す。ｖａｒｉａｂｌｅと示されているフィールドは可変長であることを意味する。図中（Ｒ）と示している箇所は、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームの場合に有効になり、ＢｌｏｃｋＡｃｋフレームの場合は無効になることを意味する。また、参照符号の付いていないフィールドの説明は割愛する。
　図５Ａに、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレーム全体の構成を示す。ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームは、ＭＡＣ　ｈｅａｄｅｒフィールド５０１、ＢＡ（Ｒ）　Ｃｏｎｔｒｏｌフィールド５０２、ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３とＦＣＳフィールドから構成される。
　図５Ｂに、ＢＡ（Ｒ）　Ｃｏｎｔｒｏｌフィールド５０２の構成を示す。ＢＡ（Ｒ）　Ｃｏｎｔｒｏｌフィールド５０２は、ＢＡ（Ｒ）　Ａｃｋ　Ｐｏｌｉｃｙサブフィールド、ＢＡ（Ｒ）　Ｔｙｐｅサブフィールド５０４、Ｒｅｓｅｒｖｅｄサブフィールド５０５、ＴＩＤ＿ＩＮＦＯサブフィールドから構成される。ＢＡ（Ｒ）　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３は、ＢＡ（Ｒ）　Ｔｙｐｅサブフィールド５０４に設定される情報に応じてそのフォーマットが規定される。ＩＥＥＥ８０２．１１ａｘ規格においては、ＢＡ（Ｒ）　Ｔｙｐｅ０、４～５、７～９、１１～１５がＲｅｓｅｒｖｅｄ領域に指定されており、本実施形態では、このＲｅｓｅｒｖｅｄ領域の内の少なくとも一つを使用して、新たなＢＡ（Ｒ）　Ｔｙｐｅを規定する。なお、本実施形態において提案する新規のＢＡ（Ｒ）　Ｔｙｐｅを、Ｎｅｗ　ＢＡ（Ｒ）と称する。
　図５Ｃに、Ｎｅｗ　ＢＡ（Ｒ）で規定されるＢＡ（Ｒ）　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３の構成を示す。ＢＡ（Ｒ）　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３は、ＢＡ（Ｒ）　Ｓｕｂｔｙｐｅサブフィールド５０７、ＡＣＫ　Ｉｎｆｏサブフィールド５０６から構成される。ＢＡ（Ｒ）　Ｓｕｂｔｙｐｅサブフィールド５０７は、Ｂｉｔｓに記載の通り０が設定されてもよい。この場合、ＢＡ（Ｒ）　Ｓｕｂｔｙｐｅに相当する情報をＢＡ（Ｒ）　Ｔｙｐｅサブフィールド５０４内のＲｅｓｅｒｖｅｄ領域、もしくはＲｅｓｅｒｖｅｄサブフィールド５０５のＲｅｓｅｒｖｅｄ領域を用いて表現しても良い。なお、ここで提示したＢＡ（Ｒ）　Ｓｕｂｔｙｐｅ、ＡＣＫ　Ｉｎｆｏの名称は一例であり、これに限定されない。
　（ＡＣＫ　Ｉｎｆｏサブフィールドの構成）
　本実施形態における、図５ＣにおけるＡＣＫ　Ｉｎｆｏサブフィールド５０６（シーケンス情報）のいくつかの構成例について、図６と図７を用いて説明する。なお、以下に記載する各部の名称、サイズ、格納する順番については一例であり、同様な機能を果たすものであればこれに限定されない。以下では、ＡＰ１０２（データ送信側装置）が送信するＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームを例に説明する。
　≪送信したＭＰＤＵを示すＡＣＫ　Ｉｎｆｏサブフィールドの構成（構成例１～３）≫
　図６（ａ）～（ｃ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例１～３を示す。構成例１～３に示すＡＣＫ　Ｉｎｆｏサブフィールド５０６は、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームに格納される。構成例１～３は、ＡＰ１０２が送信したＭＰＤＵ（データフレーム）に関する情報を送信する場合の構成例である。構成例１～３共通の構成として、ＡＣＫ　Ｉｎｆｏサブフィールド５０６は、ＡＣＫ　Ｉｎｆｏ全体のメタ情報を含むＡＣＫ　Ｉｎｆｏヘッダ部（ＡＣＫ　Ｉｎｆｏヘッダ部６０１、６０７、６１４に対応）と、送信したフレーム群（データフレーム群）を特定する特定情報（フレーム群６０２、６０３、６０９、６１０、６１５、６１６に対応）を含むＡＣＫ　Ｉｎｆｏデータ部で構成される。なお、ここで示したＡＣＫ　Ｉｎｆｏヘッダ、ＡＣＫ　Ｉｎｆｏデータという名称は一例であり、これに限定されない。
　ＡＰ１０２は、リンクごとにＳＴＡ１０３へ送信したデータを、シーケンス番号が連番である一連のデータの塊ごとに、フレーム群として区別する。つまり、送信したデータのシーケンス番号に抜けが発生した場合、そこでフレーム群としては区切られることになる。送信したすべてのフレーム群についての情報をＡＣＫ　Ｉｎｆｏサブフィールド５０６に含めることによって、ＳＴＡ１０３へ確認応答を依頼するフレームについての情報を提供することができる。ＳＴＡ１０３は依頼されたフレームについて、確認応答を送信すれば良い。ＡＣＫ　Ｉｎｆｏヘッダ部に含まれるデータ長はＡＣＫ　Ｉｎｆｏヘッダ部のデータ長分を含んでもよいし、含まなくてもよい。
　＜構成例１＞
　図６（ａ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例１を示す。構成例１におけるＡＣＫ　Ｉｎｆｏヘッダ部６０１は、ＡＣＫ　Ｉｎｆｏデータ部に含まれるデータ長（後続の全てのフレーム群を指定する情報のデータ長）を示す情報を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のＡＣＫ　Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり２４ビットの構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。
　ＩＥＥＥ８０２．１１においてＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ（シーケンス番号）は１２ビットで表現され、０～４０９５の値で表現される。構成例１では、フレーム群６０２、６０３の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ　ＳＮ）６０４と終了シーケンス番号（Ｅｎｄ　ＳＮ）６０５を用いる。開始シーケンス番号６０４と終了シーケンス番号６０５はそれぞれ１２ビットで表現可能である。開始シーケンス番号６０４は、各送信フレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。終了シーケンス番号６０５は、各送信フレーム群の終了に相当するＭＰＤＵのシーケンス番号を示す。
　＜構成例２＞
　図６（ｂ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例２を示す。構成例２におけるＡＣＫ　Ｉｎｆｏヘッダ部６０７は、構成例１と同様に、ＡＣＫ　Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ　Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１２＋Ｃｏｕｎｔ　Ｓｉｚｅ部６０８で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例２では、ＡＣＫ　Ｉｎｆｏヘッダ部６０７は、さらにＣｏｕｎｔ　Ｓｉｚｅ部６０８を含む。Ｃｏｕｎｔ　Ｓｉｚｅ部６０８は、フレーム群６０９、６１０のＣｏｕｎｔ部（Ｃｏｕｎｔ部６１２に対応）のサイズを示す。
　構成例２では、フレーム群６０９、６１０の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ　ＳＮ）６１１とＣｏｕｎｔ部６１２を用いる。開始シーケンス番号６１１は、構成例１と同様に、各送信フレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。Ｃｏｕｎｔ部６１２は、開始シーケンス番号６１１から開始し、何個分の連続するシーケンス番号を持つＭＰＤＵを送信したかの個数を示す情報を保持する。Ｃｏｕｎｔ　Ｓｉｚｅ部６０８で指定するＣｏｕｎｔ部のサイズが小さいと、フレーム群として表現できる最大ＭＰＤＵ数が小さくなるが、ひとつのフレーム群を表現するために必要なデータ長を小さくすることができる。一方、Ｃｏｕｎｔ　Ｓｉｚｅ部６０８で指定するＣｏｕｎｔ部のサイズが大きいと、フレーム群として表現できる最大ＭＰＤＵ数が大きくなるが、ひとつのフレーム群を表現するために必要なデータ長が大きくなってしまう。どのＣｏｕｎｔ　Ｓｉｚｅを使用するかは本例においては限定しない。開始シーケンス番号は、１２ビットで表現可能である。
　本構成例では、一つのフレーム群内で表現できるＭＰＤＵ数の上限がＣｏｕｎｔ　Ｓｉｚｅ部６０８によって規定されるため、連続するシーケンス番号を持つＭＰＤＵであっても別のフレーム群として表現される場合がある。
　＜構成例３＞
　図６（ｃ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例３を示す。構成例３におけるＡＣＫ　Ｉｎｆｏヘッダ部６１４は、構成例１と同様に、ＡＣＫ　Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ　Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１６＋各フレームのＣｏｕｎｔ　Ｓｉｚｅ部で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例３では、フレーム群６１５、６１６の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ　ＳＮ）６１７とＣｏｕｎｔ　Ｓｉｚｅ部６１８とＣｏｕｎｔ部６１９を用いる。構成例２でＡＣＫ　Ｉｎｆｏヘッダ部６０７に格納したＣｏｕｎｔ　Ｓｉｚｅ部６０８を、Ｃｏｕｎｔ　Ｓｉｚｅ部６１８としてそれぞれのフレーム群内に格納する。これにより、ヘッダ部でＣｏｕｎｔ　Ｓｉｚｅを固定せずに、各フレーム群で適切なＣｏｕｎｔ　Ｓｉｚｅを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はＣｏｕｎｔ　Ｓｉｚｅを大きく設定し、少ない場合は小さく設定することで、適切なＣｏｕｎｔ　Ｓｉｚｅが設定できる。
　≪送信していないＭＰＤＵを示すＡＣＫ　Ｉｎｆｏサブフィールドの構成（構成例４～６）≫
　図７（ａ）～（ｃ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例４～６を示す。構成例４～６に示すＡＣＫ　Ｉｎｆｏサブフィールド５０６は、データフレームの送信側から送信されるＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームに格納される。構成例４～６は、ＡＰ１０２が送信していないＭＰＤＵに関する情報を送信する場合の構成例である。構成例４～６共通の構成として、ＡＣＫ　Ｉｎｆｏサブフィールド５０６は、ＡＣＫ　Ｉｎｆｏ全体のメタ情報を含むＡＣＫ　Ｉｎｆｏヘッダ部（ＡＣＫ　Ｉｎｆｏヘッダ部７２１、７２４、７２７に対応）と、送信したフレーム群（データフレーム群）を特定する特定情報（フレーム群７０２、７０３、７０９、７１０、７１５、７１６に対応）を含むＡＣＫ　Ｉｎｆｏデータ部で構成される。なお、ここで示したＡＣＫ　Ｉｎｆｏヘッダ、ＡＣＫ　Ｉｎｆｏデータという名称は一例であり、これに限定されない。
　ＡＰ１０２はリンクごとにＳＴＡ１０３へ送信していないデータをシーケンス番号が連番である一連のデータの塊ごとに、フレーム群として区別する。つまり、送信していないデータのシーケンス番号に抜けが発生した場合、そこでフレーム群としては区切られることになる。送信していないすべてのフレーム群についての情報をＡＣＫ　Ｉｎｆｏサブフィールド５０６に含めることによって、ＳＴＡ１０３へ確認応答を依頼するフレームについての情報を提供することができる。ＳＴＡ１０３は依頼されたフレームについて、確認応答を送信すれば良い。
　構成例４～６が構成例１～３と異なる点は、ＡＣＫ　Ｉｎｆｏヘッダ部に新しく送信したフレーム群の開始シーケンス番号と終了シーケンス番号を示す情報を含むことである。これは、構成例４～６においては、ＡＣＫ　Ｉｎｆｏデータ部に送信していないＭＰＤＵに関する情報を含むため、それのみではどこからどこまでのシーケンス番号を送信したか、特定することができないためである。ＡＣＫ　Ｉｎｆｏサブフィールド５０６全体として表現するフレーム群の開始シーケンス番号と終了シーケンス番号を示す情報と、送信していないＭＰＤＵのシーケンス番号を組み合わせることで、送信したＭＰＤＵのシーケンス番号を特定することができる。ＡＣＫ　Ｉｎｆｏヘッダ部に含まれるデータ長はＡＣＫ　Ｉｎｆｏヘッダ部のデータ長分を含んでもよいし、含まなくてもよい。
　＜構成例４＞
　図７（ａ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例４を示す。構成例４におけるＡＣＫ　Ｉｎｆｏヘッダ部７２１は、ＡＣＫ　Ｉｎｆｏデータ部に含まれるデータ長を示す情報７０１を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のＡＣＫ　Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり２４ビットの構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。
　ＩＥＥＥ８０２．１１においてＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ（シーケンス番号）は１２ビットで表現され、０～４０９５の値で表現される。構成例４では、フレーム群７０２、７０３の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ　ＳＮ）７０４と終了シーケンス番号（Ｅｎｄ　ＳＮ）７０５を用いる。開始シーケンス番号７０４と終了シーケンス番号７０５はそれぞれ１２ビットで表現可能である。開始シーケンス番号７０４は、各送信していないフレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。終了シーケンス番号７０５は、送信していないフレーム群の終了に相当するＭＰＤＵのシーケンス番号を示す。構成例４ではＡＣＫ　Ｉｎｆｏヘッダ部７２１内に送信したフレーム群の開始シーケンス番号７２２と終了シーケンス番号７２３を含む。
　＜構成例５＞
　図７（ｂ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例５を示す。構成例５におけるＡＣＫ　Ｉｎｆｏヘッダ部６０７は、構成例４と同様に、ＡＣＫ　Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ　Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１２＋Ｃｏｕｎｔ　Ｓｉｚｅ部７０８で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例５では、ＡＣＫ　Ｉｎｆｏヘッダ部７２４は、さらにＣｏｕｎｔ　Ｓｉｚｅ部７０８を含む。Ｃｏｕｎｔ　Ｓｉｚｅ部７０８は、フレーム群７０９、７１０のＣｏｕｎｔ部（Ｃｏｕｎｔ部７１２に対応）のサイズ、さらにＡＣＫ　Ｉｎｆｏヘッダ部７２４に含まれるＣｏｕｎｔ部７２６のサイズも示す。
　構成例５では、フレーム群７０９、７１０の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ　ＳＮ）７１１とＣｏｕｎｔ部７１２を用いる。開始シーケンス番号７１１は、構成例４と同様に、送信していないフレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。Ｃｏｕｎｔ部７１２は、開始シーケンス番号７１１から開始し、何個分の連続するシーケンス番号を持つＭＰＤＵを送信していないかの個数を示す情報を保持する。Ｃｏｕｎｔ　Ｓｉｚｅ部７０８で指定するＣｏｕｎｔ部のサイズが小さいと、フレーム群として表現できる最大ＭＰＤＵ数が小さくなるが、ひとつのフレーム群を表現するために必要なデータ長を小さくすることができる。一方、Ｃｏｕｎｔ　Ｓｉｚｅ部７０８で指定するＣｏｕｎｔ部のサイズが大きいと、フレーム群として表現できる最大ＭＰＤＵ数が大きくなるが、ひとつのフレーム群を表現するために必要なデータ長が大きくなってしまう。どのＣｏｕｎｔ　Ｓｉｚｅを使用するかは本例においては限定しない。開始シーケンス番号は１２ビットで表現可能である。
　本構成例では、一つのフレーム群内で表現できるＭＰＤＵ数の上限がＣｏｕｎｔ　Ｓｉｚｅ部７０８によって規定されるため、連続するシーケンス番号を持つＭＰＤＵであっても別のフレーム群として表現される場合がある。
　また、本構成例では、ＡＣＫ　Ｉｎｆｏヘッダ部７２４は、送信したフレーム群の開始シーケンス番号７２５とそこから終了シーケンス番号までの総数（個数）を意味するＣｏｕｎｔ部７２６を含む。ＡＣＫ　Ｉｎｆｏヘッダ部７２４内のＣｏｕｎｔ部７２６のサイズはＣｏｕｎｔ　Ｓｉｚｅ部７０８で規定せず、１２ビットに固定する、もしくはＣｏｕｎｔ部７２６の情報を示すＣｏｕｎｔ　Ｓｉｚｅ部を別途ＡＣＫ　Ｉｎｆｏヘッダ部に保持しても良い。
　＜構成例６＞
　図７（ｃ）に、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成例６を示す。構成例６におけるＡＣＫ　Ｉｎｆｏヘッダ部７２７は、構成例４と同様に、ＡＣＫ　Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ　Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１６＋各フレームのＣｏｕｎｔ　Ｓｉｚｅ部で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例６では、フレーム群７１５、７１６の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ　ＳＮ）７１７とＣｏｕｎｔ　Ｓｉｚｅ部７１８とＣｏｕｎｔ部７１９を用いる。構成例５でＡＣＫ　Ｉｎｆｏヘッダ部６０７に格納したＣｏｕｎｔ　Ｓｉｚｅ部７０８をそれぞれのフレーム群内に格納する。これにより、ヘッダ部でＣｏｕｎｔ　Ｓｉｚｅを固定せずに、各フレーム群で適切なＣｏｕｎｔ　Ｓｉｚｅを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はＣｏｕｎｔ　Ｓｉｚｅを大きく設定し、少ない場合は小さく設定することで、適切なＣｏｕｎｔ　Ｓｉｚｅが設定できる。
　また、本構成例では、ＡＣＫ　Ｉｎｆｏヘッダ部７２７は、送信したフレーム群の開始シーケンス番号７２８とそこから終了シーケンス番号までの総数を意味するＣｏｕｎｔ部７３０、Ｃｏｕｎｔ部７３０のサイズ情報を示すＣｏｕｎｔＳｉｚｅ部７２９を含む。
　［構成例７］
　構成例７は、８０２．１１規格に規定されているＢＡ　Ｔｙｐｅ：Ｃｏｍｐｒｅｓｓｅｄで使用されるＣｏｍｐｒｅｓｓｅｄ　ＢｌｏｃｋＡｃｋ　Ｖａｒｉａｎｔの書式を流用した構成である。この構成では、ＡＣＫ　Ｉｎｆｏサブフィールド５０６（シーケンス情報）の中にＦｒａｇｍｅｎｔ　Ｎｕｍｂｅｒ（４ビット）、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ（１２ビット）、Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐ（８もしくは３２バイト）を格納する。Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐのサイズ、一度に表現できるＭＳＤＵ／Ａ－ＭＳＤＵの最大数は、Ｆｒａｇｍｅｎｔ　Ｎｕｍｂｅｒの値に応じて定められ、８０２．１１ａｘ規格に準ずる。Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒは、送信したデータフレーム（ＭＰＤＵ）の開始シーケンス番号を示す値が設定され、当該開始シーケンス番号を開始点としてそれ以降のデータフレームについて、Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐの各ビットを対応付けて送信済みか否かを表現する。ビットが１に設定されているフレームは送信済み、ビットが０に設定されているフレームは送信していないと判定することができる。０、１の意味合いは逆でも良い。
　以上、構成例１～７について、ＡＰ１０２（データ送信側装置）が送信するＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームを例に説明したが、ＳＴＡ１０３（データ受信側装置）が送信するＢｌｏｃｋＡｃｋフレームにも上記の構成に基づく構成を適用できる。例えば、構成例１～３については、受信したＭＰＤＵを示すＡＣＫ　Ｉｎｆｏサブフィールドの構成として、上記の構成例１～３の説明における「送信したフレーム（群）」を「受信したフレーム（群）」に読み替えればよい。また、構成例４～６については、受信していないＭＰＤＵを示すＡＣＫ　Ｉｎｆｏサブフィールドの構成として、上記の構成例４～６の説明における「送信していないフレーム（群）」を「受信できなかったフレーム（群）」に、「送信したフレーム（群）」を「受信したフレーム（群）」に読み替えればよい。また、構成例７については、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒに、受信したデータフレーム（ＭＰＤＵ）の開始シーケンス番号を示す値を設定すればよい。また、Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐの各ビットに、データ送信側装置により送信されたデータフレームに対する受信結果を設定すればよい。構成例７を用いる場合のＢＡフレームに関する処理例については後述する。
　また、Ｉｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔに設定されたデータフレームにも、上記の構成例１～６に基づく構成を適用できる。例えば、当該データフレームにおけるＢＡＲ　ＣｏｎｔｒｏｌフィールドとＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールドに、上記の構成例１～６の構成を同様に適用すればよい。
　（ＡＣＫ　Ｉｎｆｏサブフィールドの構成の通知方法）
　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームの送信側は、構成例１～７のいずれかでＡＣＫ　Ｉｎｆｏサブフィールド５０６を構成するかを該フレームにおいて特定（指定）し、受信側に通知することができる。例えば、構成例１～７のいずれを用いるかを、ＢＡＲ　Ｔｙｐｅサブフィールド５０４、Ｒｅｓｅｒｖｅｄサブフィールド５０５、ＢＡＲ　Ｓｕｂｔｙｐｅサブフィールド５０７の少なくともいずれかを用いて、特定することができる。
　例えば、ＢＡＲ　Ｔｙｐｅサブフィールド５０４のＲｅｓｅｒｖｅｄを意味するＢＡＲ　Ｔｙｐｅ０を、構成例１～７のいずれかを用いることを意味するＢＡＲ　Ｔｙｐｅと規定しても良い。さらに、構成例１～７の中のいずれを使うかを、ＢＡＲ　Ｔｙｐｅサブフィールド５０４の他のＲｅｓｅｒｖｅｄ領域、Ｒｅｓｅｒｖｅｄサブフィールド５０５、ＢＡＲ　Ｓｕｂｔｙｐｅサブフィールド５０７の内の少なくとも３ビットを使用することで特定しても良い。具体的には、ＢＡＲ　Ｓｕｂｔｙｐｅサブフィールド５０７を使用する場合、ＢＡＲ　Ｓｕｂｔｙｐｅサブフィールド５０７に００００というビットを指定した場合は構成例１を使用し、０００１というビットを指定した場合は構成例２を使用するといったように定義してもよい。
　また、既存のＢＡＲ　Ｔｙｐｅサブフィールド５０４と所定の（サブ）フィールドとを組み合わせて、構成例１～７のいずれかを用いることを特定してもよい。例えば、ＢＡＲ　Ｔｙｐｅサブフィールド５０４をＭｕｌｔｉ－ＴＩＤやＭｕｌｔｉ－ＳＴＡに設定する場合を想定する。ＢＡＲ　Ｔｙｐｅサブフィールド５０４をＭｕｌｔｉ－ＴＩＤに設定する場合、Ｒｅｓｅｒｖｅｄサブフィールド５０５の領域を使って構成例１～７のいずれかを用いることを特定してもよい。
　なお、通信相手装置が、本実施形態によるＮｅｗ　ＢＡＲ（すなわち構成例１～７のＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成）をサポートしているかどうか（Ｎｅｗ　ＢＡＲ　Ｔｙｐｅに対する能力情報を有するか）は、規格上対応必須と定めてもよい。あるいは、図４の例の場合、ＡＰ１０２とＳＴＡ１０３間でのＡＤＤＢＡ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームのやりとりを介して（ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時に）、能力情報を交換してもよい。あるいは、他のマネージメントフレームのやり取りを介して、能力をネゴシエートしても良い。より具体的には、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時に（図４参照）、例えばＡＤＤＢＡ　Ｅｘｔｅｎｔｉｏｎ　Ｅｌｅｍｅｎｔ内のＡＤＤＢＡ　Ｃａｐａｂｉｌｉｔｉｅｓ　Ｆｉｅｌｄ内のＲｅｓｅｒｖｅｄビットを使用してネゴシエーションすることができる。なお、ネゴシエーションはこの方法に限定されない。ネゴシエーションによって決定されたＮｅｗ　ＢＡＲのサポートの可否は、接続管理部３０３にＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔの属性として記録されうる。
　なお、上記では、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームの送信側によるＡＣＫ　Ｉｎｆｏサブフィールドの構成の通知方法について説明したが、同様の説明をＢｌｏｃｋＡｃｋフレームの送信側のＡＣＫ　Ｉｎｆｏサブフィールドの構成の通知方法に適用できる。この場合、上記説明において、「ＢＡＲ」を「ＢＡ」に読み替えればよい。また、Ｉｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔに設定されたデータフレームを用いる場合も、当該データフレームにおけるＢＡＲ　ＣｏｎｔｒｏｌフィールドやＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールドを用いることにより、ＡＣＫ　Ｉｎｆｏサブフィールドの構成を通知可能である。
　＜データフレーム送信側の処理＞
　次に、図８～図１２を用いて、データフレーム送信側の処理について説明する。ここでは、図４のようにデータフレーム送信側の装置がＡＰ１０２である場合を例に説明するが、本説明は、ＳＴＡ１０３が動作主体である場合にも同様に適用可能である。
　（フレーム送信処理）
　図８を用いて、本実施形態における、データフレーム送信側によるフレーム送信処理について説明する。図８は、データフレーム送信側によるフレーム送信処理のフローチャートである。当該処理は、ＡＰ１０２が通信相手装置（図４の例ではＳＴＡ１０３）と無線接続を確立し、ＡＤＤＢＡ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームのやりとりを終えた後に開始されうる。
　なお、上述のように、ＡＰ１０２とＳＴＡ１０３それぞれの接続管理部３０３は、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時（図４のＦ４０２～Ｆ４０５）に、ＢＡセッションにおけるＳｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ等の各種パラメータを記憶部２０１に記録し、管理しているものとする。さらに、ＡＰ１０２とＳＴＡ１０３それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ　Ｔｙｐｅ（本実施形態のＮｅｗ　ＢＡ（Ｒ）による新たなＢＡ（Ｒ）　Ｔｙｐｅも含みうる）の情報を記憶部２０１に記録し、管理しているものとする。
　ＡＰ１０２のフレーム生成部３０２が、通信相手装置（ＳＴＡ１０３）へのフレームを生成すると、フレーム送受信部３０４は、当該フレーム送信処理を開始する。フレーム送受信部３０４は、フレーム送信処理として初めに、送信するフレームがデータフレームかの判定を行う（Ｓ８０１）。これは、例えば、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＦｒａｍｅ　Ｃｏｎｔｒｏｌ　Ｆｉｅｌｄ中のＴｙｐｅフィールドが、“１０”であるかどうかを確認することにより、判定可能である。“１０”の場合データフレーム、それ以外の場合はデータフレームでないと判定できる。
　送信するフレームがデータフレームであると判定した場合（Ｓ８０１でＹｅｓ）、フレーム送受信部３０４は、データフレーム生成・送信処理を実行する（Ｓ８０２）。Ｓ８０２の処理の詳細は、図９を用いて後述する。Ｓ８０２の処理の後、フレーム生成部３０２は、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔ（ＢＡＲ）フレームを生成して送信するかの判定を行う（Ｓ８０３）。これは、例えば、フレーム送受信部３０４が最後にＢｌｏｃｋＡｃｋフレームを受信して以降の累計のデータフレーム（ＭＰＤＵ）の送信数に応じて判定してもよいし、その他の規則に従って判定してもよい。
　ＢＡＲフレームを生成して送信すると判定した場合（Ｓ８０３でＹｅｓ）、フレーム生成部３０２はＢＡＲフレームを送信し、フレーム送受信部３０４は、ＢＡＲフレーム生成・送信処理を実行し（Ｓ８０４）、その後終了する。Ｓ８０４の処理の詳細は、図１０を用いて後述する。ＢＡＲフレームを生成しないと判定した場合（Ｓ８０３でＮｏ）、ＡＰ１０２はフレーム送信処理を終了する。
　Ｓ８０１で、送信するフレームがデータフレームでないと判定した場合（Ｓ８０１でＮｏ）、ＡＰ１０２は、ＩＥＥＥ８０２．１１規格準拠の各種フレームに対応する処理を実行し（Ｓ８０５）、処理を終了する。Ｓ８０５の処理については、本実施形態との関連が低いため、説明を割愛する。
　（データフレーム生成・送信処理）
　次に、図９を用いてＳ８０２のデータフレーム生成・送信処理の一例について説明する。図９は、データフレーム生成・送信処理のフローチャートである。なお、データフレーム（ＭＰＤＵ）のシーケンス番号は、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＳｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌフィールド内のＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒによって示され、０～４０９５の範囲の値を持つ。
　ＡＰ１０２の接続管理部３０３は、フレーム送受信部３０４により送信予定のデータフレームのシーケンス番号を送信済みとして（送信済みシーケンス番号として）記憶部２０１に記録し、管理する（Ｓ９０１）。接続管理部３０３は、当該番号の情報を用いて、任意のシーケンス番号のデータが送信済みかどうかを判定することができる。接続管理部３０３で管理するシーケンス番号は、無線接続が確立した段階（図４の例ではＦ４０１）で、当該接続に関する送信シーケンス番号の管理を開始する。管理の開始時点では、すべてのシーケンス番号０～４０９５が未送信シーケンス番号とし　て、記憶部２０１に記録される。なお、最初に送信するフレームのシーケンス番号は０から開始しても良いが、これに限定されない。４０９５にシーケンス番号が達した場合、次のフレームのシーケンス番号は０に戻る。
　次に、フレーム生成部３０２は、Ａｃｋ　Ｐｏｌｉｃｙを設定する（ＱｏＳ　ＣｏｎｔｒｏｌフィールドにおけるＡｃｋ　Ｐｏｌｉｃｙサブフィールドを設定する）（Ｓ９０２）。例えばＮｅｗ　ＢＡＲをサポートすることを、ＱｏＳ　ＣｏｎｔｒｏｌフィールドのＢｉｔ５、Ｂｉｔ６を使って示すことができる。例えば、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時に、ＡＰ１０２とＳＴＡ１０３がＮｅｗ　ＢＡＲをサポートすると確認された場合に、フレーム生成部３０２は、ＱｏＳ　ＣｏｎｔｒｏｌフィールドでＢｉｔ５：１、Ｂｉｔ６：０に設定することができる。また、Ｎｅｗ　ＢＡＲをサポートすることを示すことで、当該データフレームにおいてＩｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔが設定されていることを示すことができる。
　Ａｃｋ　Ｐｏｌｉｃｙの設定後、ＡＰ１０２とＳＴＡ１０３がサポートするＢＡＲ　Ｔｙｐｅに応じて、Ｆｒａｍｅ　Ｂｏｄｙに情報を追加する（Ｓ９０３）。例えば、上記のようにＱｏＳ　ＣｏｎｔｒｏｌフィールドにおいてＢｉｔ５：１、Ｂｉｔ６：０が設定された場合、フレーム生成部３０２は、図６と図７で説明した、送信した／送信していないシーケンス番号を特定する情報をＦｒａｍｅＢｏｄｙに含めることができる。この場合、受信側であるＳＴＡ１０３は、当該ＦｒａｍｅＢｏｄｙを解析し、ＡＰ１０２により送信されたデータのシーケンス番号の情報を抽出することができる。ＳＴＡ１０３がこのようなＡｃｋ　Ｐｏｌｉｃｙを含むデータフレームを受信した場合は、ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔフレームの受信なしにＢｌｏｃｋＡｃｋフレームを返すことができる。続いて、フレーム生成部３０２は、残りのフレーム部を生成して、データフレームを完成させる（Ｓ９０４）。最後に、フレーム送受信部３０４は、フレーム生成部３０２により生成されたデータフレームを通信相手装置（ＳＴＡ１０３）に送信する（Ｓ９０５）。
　（ＢＡＲフレーム生成・送信処理）
　次に、図１０を用いてＳ８０４のＢＡＲフレーム生成・送信処理について説明する。図１０は、ＢＡＲフレーム生成・送信処理のフローチャートである。なお、上述したように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡＲ　Ｔｙｐｅ（本実施形態によるＮｅｗ　ＢＡＲ　Ｔｙｐｅも含みうる）等の情報を記憶部２０１に記録し、管理しているものとする。また、フレームの生成に関し、図５Ａ～５Ｃを参照する。
　ＡＰ１０２の接続管理部３０３は、接続のサポートする（自装置とＳＴＡ１０３のサポートする）ＢＡＲ　Ｔｙｐｅを確認する（Ｓ１００１）。ここでは、ＡＰ１０２とＳＴＡ１０３はＮｅｗ　ＢＡＲをサポートしているものとし、それ以外の場合は、ＩＥＥＥ８０２．１１規格に従った処理が行われ得る。続いて、接続管理部３０３は、送信済みシーケンス番号の確認を行う（Ｓ１００２）。
　フレーム生成部３０２は、Ｓ１００１とＳ１００２で確認された情報を用いて、ＢＡＲフレームの生成を行う。まず、フレーム生成部３０２は、ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３におけるＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成を決定する（Ｓ１００３）。ここで、フレーム生成部３０２は、Ｓ１００１で確認されたサポートＢＡＲ　Ｔｙｐｅに基づいて、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成を決定することができる。確認されたサポートＢＡ　Ｔｙｐｅが、上記の構成例１～７のいずれかの構成をサポートすることを示す場合、フレーム生成部３０２は、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成として当該構成例１～７のいずれかを使用することを決定することができる。なお、上記の構成例１～７のいずれかの構成を使用することは、予めＡＰ１０２に固定的に設定されていてもよいし、入力部２０４を介したユーザによる入力操作により、設定（決定）されてもよい。
　次に、フレーム生成部３０２は、Ｓ１００３で決定したＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成に従って、また、当該構成を特定（指定）するように、ＢＡ　Ｃｏｎｔｒｏｌフィールド５０２とＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を生成する（Ｓ１００４）。前述したように、ＡＣＫ　Ｉｎｆｏサブフィールド５０６に構成例１～７のいずれかを使用することを、ＢＡＲ　Ｃｏｎｔｒｏｌフィールド５０２／ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３における各種サブフィールドで指定することができる。また、フレーム生成部３０２は、Ｓ１００２で確認した送信済みシーケンス番号に基づいて、ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を生成する。ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールドの具体的な内容については、構成例１～７にて説明したいずれかの書式で、Ｓ１００２で確認したシーケンス番号を表現する。
　次に、フレーム生成部３０２は、残りのフレーム部を生成して、ＢＡＲフレームを完成させる（Ｓ１００５）。最後に、フレーム送受信部３０４は、フレーム生成部３０２により生成されたＢＡＲフレームを通信相手装置（ＳＴＡ１０３）に送信する。
　（フレーム受信処理）
　次に図１１を用いて、本実施形態における、データフレーム送信側によるフレーム受信処理について説明する。図１１は、フレーム受信処理フローチャートである。ＡＰ１０２のフレーム送受信部３０４が、通信相手装置（ＳＴＡ１０３）から無線フレームを受信すると、フレーム解析部３０１は、受信したフレームの解析処理を開始する。なお、自身宛にフレームでない場合や、フレームが壊れている（例えばＦＣＳ値が不正）場合はこの処理を開始せずにフレームを破棄してもよい。
　フレーム解析処理として、初めにフレーム解析部３０１は、受信したフレームがＢＡ（ＢｌｏｃｋＡｃｋ）フレームかの判定を行う（Ｓ１１０１）。これは、例えば、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＦｒａｍｅ　Ｃｏｎｔｒｏｌ　Ｆｉｅｌｄ中のＴｙｐｅフィールドが“０１”かつ、Ｓｕｂｔｙｐｅフィールドが“１００１”であるかどうかを確認することにより、判定可能である。Ｔｙｐｅフィールドが“０１”かつ、Ｓｕｂｔｙｐｅフィールドが“１００１”の場合ＢｌｏｃｋＡｃｋフレーム、それ以外の場合はＢＡフレームでないと判定できる。
　受信したフレームがＢＡフレームであると判定した場合（Ｓ１１０１でＹｅｓ）、ＡＰ１０２はＢＡフレーム処理を実行する（Ｓ１１０２）。Ｓ１１０２のＢＡフレーム受信処理につては、図１２を用いて後述する。受信したフレームがＢＡフレームでないと判定した場合（Ｓ１０１１でＮｏ）、ＡＰ１０２は、ＩＥＥＥ８０２．１１規格準拠の各種フレームに対応する処理を実行し（Ｓ１１０３）、処理を終了する。Ｓ１１０３の処理については、本実施形態との関連が低いため、説明を割愛する。
　（ＢＡフレーム受信処理）
　次に、図１２を用いてＳ１１０２のＢＡフレーム受信処理について説明する。図１２は、ＢＡフレーム受信処理のフローチャートである。なお、上述したように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ　Ｔｙｐｅ（本実施形態によるＮｅｗ　ＢＡ　Ｔｙｐｅも含みうる）等の情報を記憶部２０１に記録し、管理しているものとする。また、フレームの生成に関し、図５Ａ～５Ｃを参照する。
　ＡＰ１０２の接続管理部３０３は、接続のサポートする（自装置とＳＴＡ１０３のサポートする）ＢＡ　Ｔｙｐｅを確認する（Ｓ１２０１）。この情報は、Ｂｌｏｃｋ　Ａｃｋ　Ａｇｒｅｅｍｅｎｔ構築時に接続管理部３０３が確認し、記録済である。ＡＰ１０２は、ここで確認したＢＡ　Ｔｙｐｅに応じて、以降の処理を切り替えることができる。
　次に、ＡＰ１０２の接続管理部３０３は、受信したＢＡフレームに含まれるＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を確認する（Ｓ１２０２）。ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３の書式はＢＡ　Ｔｙｐｅに応じて変わりうるが、接続管理部３０３は、当該フィールドに含まれる情報から、ＳＴＡ１０３により受信済みとして記録されたシーケンス番号（受信済みシーケンス番号）を抽出する（Ｓ１２０３）。例えばＢＡ　ＴｙｐｅがＣｏｍｐｒｅｓｓｅｄの場合は、ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３にＢｌｏｃｋＡｃｋ　Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　ＣｏｎｔｒｏｌとＢｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐが含まれ得る。受信シーケンス番号の開始点と、そこからの各シーケンス番号の受信是非を表すＢｉｔｍａｐから、受信済みとして記録されたシーケンス番号を算出することができる。
　次に、接続管理部３０３は、管理している送信済みシーケンス番号の更新を行う（Ｓ１２０４）。ＡＰ１０２は、Ｓ１２０３においてＳＴＡ１０３により受信済みと確認されたフレームについては、再送をする必要がなくなるため、送信済みという管理を行う必要がなくなる。よって、接続管理部３０３は、送信済みという記録を解除する。続いて、接続管理部３０３は、Ｓ１２０４で送信済みの記録を解除したフレームを送信バッファから削除しても良い（Ｓ１２０５）。
　＜データフレームの受信側の処理＞
　次に、図１３～図１５を用いて、データフレーム受信側の処理について説明する。ここでは、図４のようにデータフレーム受信側の装置がＳＴＡ１０３である場合を例に説明するが、本説明は、ＡＰ１０２が動作主体である場合にも同様に適用可能である。上述のように、ＢＡＲフレームに対するＢＡＲ　Ｃｏｎｔｒｏｌフィールド５０２、ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に関する説明は、ＢＡ　Ｃｏｎｔｒｏｌフィールド５０２、ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に対してそれぞれ適用可能であり、詳細な説明は割愛する。
　（フレーム受信処理）
　図１３を用いて、本実施形態における、データフレーム受信側によるフレーム受信処理について説明する。図１３は、データフレーム受信側によるフレーム受信処理のフローチャートである。当該処理は、ＳＴＡ１０３が通信相手装置（図４の例ではＡＰ１０２）と無線接続を確立し、ＡＤＤＢＡ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームのやりとりを終えた後に開始されうる。
　なお、上述のように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、ＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時（図４のＦ４０２～Ｆ４０５）に、ＢＡセッションにおけるＳｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ等の各種パラメータを記憶部２０１に記録し、管理しているものとする。さらに、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ　Ｔｙｐｅ（本実施形態によるＮｅｗ　Ｔｙｐｅも含みうる）の情報を記憶部２０１に記録し、管理しているものとする。
　ＳＴＡ１０３のフレーム送受信部３０４が、通信相手装置（ＡＰ１０２）からの無線フレームを受信すると、フレーム解析部３０１は、受信したフレームの解析処理を開始する。なお、自身宛にフレームでない場合や、フレームが壊れている（例えばＦＣＳ値が不正）場合は、ＳＴＡ１０３は、この処理を開始せずにフレームを破棄してもよい。
　フレームの解析処理として、初めにフレーム解析部３０１は、受信したフレームがデータフレームかの判定を行う（Ｓ１３０１）。これは、例えば、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＦｒａｍｅ　Ｃｏｎｔｒｏｌ　Ｆｉｅｌｄ中のＴｙｐｅフィールドが“１０”であるかどうかを確認することにより、判定可能である。“１０”の場合はデータフレーム、それ以外の場合はデータフレームでないと判定できる。
　受信したフレームがデータフレームであると判定した場合（Ｓ１３０１でＹｅｓ）、接続管理部３０３は、データフレームのシーケンス番号の確認処理を実行する（Ｓ１３０２）。Ｓ１３０２の処理の詳細は、図１４を用いて後述する。Ｓ１３０２の処理の後、フレーム解析部３０１は、受信したフレームがＢｌｏｃｋＡｃｋフレームを要求するデータフレームかを判定する（Ｓ１３０３）。これは、例えば、データフレームが含むＭＰＤＵの内、少なくとも１つ以上のＭＰＤＵ内のＱｏＳ　Ｃｏｎｔｒｏｌフィールドに含まれるＡｃｋ　ＰｏｌｉｃｙサブフィールドがＩｍｐｌｉｃｉｔ　ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔ（“００”）に設定されているかどうかを確認することにより、判定可能である。“００”に設定されている場合、フレーム解析部３０１は、受信したフレームはＢｌｏｃｋＡｃｋフレームを要求するデータフレームと判定し（Ｓ１３０３でＹｅｓ）、処理はＳ１３０４へ進む。“００”に設定されてない場合、フレーム解析部３０１は、受信したフレームはＢｌｏｃｋＡｃｋフレームを要求するデータフレームでないと判定し、フレーム受信処理を終了する。Ｓ１３０４では、ＡＰ１０２はＢｌｏｃｋＡｃｋ（ＢＡ）フレーム生成・送信処理を行う。Ｓ１３０４の処理の詳細は、図１５を用いて後述する。
　Ｓ１３０１で、受信したフレームがデータフレームでないと判定した場合（Ｓ１３０１でＮｏ）、フレーム解析部３０１は、受信したフレームがＢＡＲ（ＢｌｏｃｋＡｃｋ　Ｒｅｑｕｅｓｔ）フレームかどうかを判定する（Ｓ１３０５）。例えば、データフレームにおける、前述のＴｙｐｅフィールドが“０１”であり、かつ、ＭＡＣヘッダ内のＦｒａｍｅ　Ｃｏｎｔｒｏｌ　Ｆｉｅｌｄ中のＳｕｂｔｙｐｅフィールドが“１０００”である場合に、ＢＡＲフレームと特定できる。フレーム解析部３０１は、受信したフレームがＢＡＲフレームと判定した場合は（Ｓ１３０５でＹｅｓ）、処理はＳ１３０４へ進み、ＳＴＡ１０３は、ＢＡフレーム生成・送信処理を実行する。ＢＡＲフレームには、データの開始番号に関する情報が含まれ得る。Ｓ１３０５で、受信したフレームがＢＡＲフレームでないと判定した場合は（Ｓ１３０５でＮｏ）、ＳＴＡ１０３は、ＩＥＥＥ８０２．１１規格準拠の各種フレームに対応する処理を実行し（Ｓ１３０６）、処理を終了する。Ｓ１３０６の処理については、本実施形態との関連が低いため、説明を割愛する。
　（データフレームのシーケンス番号確認処理）
　次に、図１４を用いてＳ１３０２のデータフレームのシーケンス番号の確認処理について説明する。図１４はデータフレームのシーケンス番号確認処理のフローチャートである。なお、データフレーム（ＭＰＤＵ）のシーケンス番号は、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＳｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌフィールド内のＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒによって示され、０～４０９５の範囲の値を持つ。接続管理部３０３は、無線接続が確立した段階（図４の例ではＦ４０１）で、当該接続に関する受信シーケンス番号（受信済みのデータフレームのシーケンス番号）の管理を開始する。管理の開始時点では、すべてのシーケンス番号０～４０９５が未受信シーケンス番号（受信済みとして記録されていないデータフレームのシーケンス番号）として、記憶部２０１に記録される。
　ＳＴＡ１０３の接続管理部３０３は、データフレーム（ＭＰＤＵ）のシーケンス番号が未受信シーケンス番号かを確認する（Ｓ１４０１）。すなわち、接続管理部３０３は、受信したデータフレームシーケンス番号の情報を、記憶部２０１に記録されている受信シーケンス番号と照合し、受信したデータフレームのシーケンス番号が未受信シーケンス番号かどうかを判定する。
　受信したデータフレームのシーケンス番号が未受信シーケンス番号である場合（Ｓ１４０１でＹｅｓ）、接続管理部３０３は、当該シーケンス番号を受信シーケンス番号として新たに記憶部２０１に記録し（Ｓ１４０２）、終了する。一方、受信したデータフレームのシーケンス番号が受信シーケンス番号である場合（Ｓ１４０１でＮｏ）、受信したデータフレームは既に受信済みであり、重複フレームとみなして、当該データフレームを破棄し（Ｓ１４０３）、終了する。
　（ＢＡフレーム生成・送信処理）
　次に、図１５を用いてＳ１３０４のＢｌｏｃｋＡｃｋ（ＢＡ）フレーム生成・送信処理について説明する。図１５は、ＢＡフレーム生成・送信処理のフローチャートである。なお、上述したように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ　Ｔｙｐｅ（本実施形態によるＮｅｗ　ＢＡ　Ｔｙｐｅも含みうる）や、ＢＡセッションにおけるＳｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ等の情報を記憶部２０１に記録し、管理しているものとする。また、フレームの生成に関し、図５Ａ～５Ｃを参照する。
　ＳＴＡ１０３の接続管理部３０３は、接続のサポートする（自装置とＡＰ１０２のサポートする）ＢＡ　Ｔｙｐｅを確認する（Ｓ１５０１）。ここで確認したＢＡ　Ｔｙｐｅのサポート状況に応じて、フレーム生成部３０２は、Ｓ１５０４、Ｓ１５０５で生成するＢｌｏｃｋＡｃｋフレームの内容を決定することができる。次に、ＳＴＡ１０３の接続管理部３０３は、ＢＡセッションにおけるＳｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒを確認する（Ｓ１５０２）。前述したように、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　ＮｕｍｂｅｒはＢｌｏｃｋＡｃｋ　Ａｇｒｅｅｍｅｎｔ構築時に初期値が決定され、ＩＥＥＥ８０２．１１規格規定の方法に従ってその後更新されうる。続いて、接続管理部３０３は、受信シーケンス番号（受信済みとして記録されたシーケンス番号）の確認を行う（Ｓ１５０３）。
　フレーム生成部３０２は、Ｓ１００１～Ｓ１００３で確認された情報を用いて、Ｂｌｏｃｋ　Ａｃｋフレームの生成を行う。まず、フレーム生成部３０２は、ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３におけるＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成を決定する（Ｓ１５０４）。ここで、フレーム生成部３０２は、Ｓ１５０１で確認されたサポートＢＡ　Ｔｙｐｅに基づいて、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成を決定することができる。確認されたサポートＢＡ　Ｔｙｐｅが、上記の構成例１～６のいずれかの構成をサポートすることを示す場合、フレーム生成部３０２は、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成として当該構成例１～７のいずれかを使用することを決定することができる。なお、上記の構成例１～７のいずれかの構成を使用することは、予めＳＴＡ１０３に固定的に設定されていてもよいし、入力部２０４を介したユーザによる入力操作により、設定（決定）されてもよい。また、フレーム生成部３０２は、Ｓ１００３で確認されたシーケンス番号の受信状況に応じて。最も小さなデータサイズでＡＣＫ　Ｉｎｆｏサブフィールド５０６を構成するように構成例１～７のいずれかを使用することを決定してもよい。
　次に、フレーム生成部３０２は、Ｓ１５０４で決定したＡＣＫ　Ｉｎｆｏサブフィールド５０６の構成に従って、また、当該構成を特定（指定）するように、ＢＡ　Ｃｏｎｔｒｏｌフィールド５０２とＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を生成する（Ｓ１５０５）。前述したように、ＡＣＫ　Ｉｎｆｏサブフィールド５０６に構成例１～７のいずれかを使用することを、ＢＡ　Ｃｏｎｔｒｏｌフィールド５０２／ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３における各種サブフィールドで指定することができる。
　続いてフレーム生成部３０２は、図５Ａ記載のＭＡＣ　ｈｅａｄｅｒフィールド５０１、ＦＳＣフィールドを生成しＭＡＣフレームとして完成させ、ＰＨＹ部も生成してＢｌｏｃｋＡｃｋフレームを完成させる（Ｓ１５０６）。最後に、フレーム送受信部３０４は、フレーム生成部３０２により生成されたＢｌｏｃｋＡｃｋフレームを通信相手装置（ＡＰ１０２）へ送信する（Ｓ１５０７）。
　送信したフレームの確認応答や、確認応答を一定時間受信しなかった際の再送処理は、ＩＥＥＥ８０２．１１規格の規定に従って実行される。ＳＴＡ１０３は。ＢｌｏｃｋＡｃｋフレームを正しく送信し、ＡＰ１０２から確認応答を受信した場合、受信済みの記録をリセットする、例えば、ＳＴＡ１０３の接続管理部３０３は、管理している受信シーケンス番号のうち、当該ＢｌｏｃｋＡｃｋフレームで通知が完了したシーケンス番号については、受信済みの記録をリセットする。これにより、シーケンス番号が一周した際にシーケンス番号の管理が可能となる。
　（構成例７によるＢＡフレーム）
　構成例７によるＢＡフレームの例と該フレームを用いた処理例について説明する。なお、図４のようにデータフレーム送信側の装置がＡＰ１０２である場合を例に説明するが、本説明は、ＳＴＡ１０３が動作主体である場合にも同様に適用可能である。また、フレームの生成に関し、図５Ａ～５Ｃを参照する。
　ＳＴＡ１０３は、ＡＰ１０２から送信されたデータフレームのシーケンス番号をＢＡＲフレームにおけるＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎ（ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に設定される情報）によって取得することができる。ＳＴＡ１０３は、当該送信されたデータフレームのシーケンス番号を、ＡＣＫ　Ｉｎｆｏサブフィールド５０６の中にＢｌｏｃｋＡｃｋＢｉｔｍａｐで表現する各ビットとシーケンス番号の対応付けに利用することで、Ｂｉｔｍａｐのビットを効率的に使用することができる。
　ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎ（ＢＡ　Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に設定される情報）は、構成例７に関して上述したように、Ｆｒａｇｍｅｎｔ　Ｎｕｍｂｅｒ（４ビット）、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ（１２ビット）、Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐ（８もしくは３２バイト）を格納する。Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐのサイズ、一度に表現できるＭＳＤＵ／Ａ－ＭＳＤＵの最大数は、Ｆｒａｇｍｅｎｔ　Ｎｕｍｂｅｒの値に応じて定められ、８０２．１１ａｘ規格に準ずる。Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒは、ＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎ中に提示された、ＡＰ（通信相手装置）が送信したフレームの開始シーケンス番号を示す値が設定される。以降のフレームについては、ＡＰ１０２がＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎによって送信済みと提示したシーケンス番号のみついて、Ｂｌｏｃｋ　Ａｃｋ　Ｂｉｔｍａｐの各ビットを対応付けて送信済みか否かを表現する。ビットが１に設定されているフレームは送信済み、ビットが０に設定されているフレームは送信していないと判定することができる。０、１の意味合いは逆でも良い。
　具体例として、例えばＡＰ１０２がシーケンス番号１、３、５を送信したとＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎによって提示し、ＳＴＡ１０３はシーケンス番号３番のみ受信できていない例を想定する。この場合、ＳＴＡ０３がＢｌｏｃｋＡｃｋフレームに含めるＢＡ　Ｉｎｆｏｒｍａｔｉｏｎにおいて、ＳｔａｒｔｉｎｇＳｅｑｕｅｎｃｅＮｕｍｂｅｒを１、ＦｒａｇｍｅｎｔＮｕｍｂｅｒを０に設定し、ＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐ長を最小の８バイトに設定する。ＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐでは、１ビット目がシーケンス番号１、２ビット目がシーケンス番号３、３ビット目がシーケンス番号５に対応する。それ以降のビットは使用されないが、未受信として０が設定され得る。本例では、シーケンス番号１、５が受信成功、３が受信失敗なので、ＢｌｏｃｋＡｃｋ　Ｂｉｔｍａｐとして“１０１”の内容を含むＢｌｏｃｋＡｃｋフレームがＳＴＡ１０３からＡＰ１０２へ送信される。ＡＰ１０２は当該ＢｌｏｃｋＡｃｋフレームを受信し、自身が送信したＢＡＲ　Ｉｎｆｏｒｍａｔｉｏｎと照らし合わせることで、各ビットが対応づくフレームを特定できる。この例の場合、シーケンス番号３は送信失敗とみなし、再送処理される。
　送信したフレームの確認応答や、確認応答を一定時間受信しなかった際の再送処理は、ＩＥＥＥ８０２．１１規格の規定に従って実行される。ＳＴＡ１０３は。ＢｌｏｃｋＡｃｋフレームを正しく送信し、ＡＰ１０２から確認応答を受信した場合、受信済みの記録をリセットする、例えば、ＳＴＡ１０３の接続管理部３０３は、管理している受信シーケンス番号のうち、当該ＢｌｏｃｋＡｃｋフレームで通知が完了したシーケンス番号については、受信済みの記録をリセットする。これにより、シーケンス番号が一周した際にシーケンス番号の管理が可能となる。
　図８～図１５に示す処理のフローは本提案を実現する一例であり、同じ機能を果たすものであれば各処理の順番は限定されない。また、この処理フローに記載されていない処理についてはＩＥＥＥ８０２．１１規格規定の処理に従う。
　本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
　発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。
　本願は、２０２０年１２月８日提出の日本国特許出願特願２０２０－２０３６５６を基礎として優先権を主張するものであり、その記載内容の全てを、ここに援用する。

Claims (37)

  1. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、
    　前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、
    　前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    　前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
  2. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信手段であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信手段と、
    　前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    　前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
  3. 　前記特定情報は、前記各リンクで送信した各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報を含むことを特徴とする請求項１または２に記載の通信装置。
  4. 　前記特定情報は、前記各リンクで送信した各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項１または２に記載の通信装置。
  5. 　前記特定情報は、前記各リンクで送信した各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報とを含むことを特徴とする請求項１または２に記載の通信装置。
  6. 　前記シーケンス情報は、前記各リンクで送信した前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
  7. 　前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項６に記載の通信装置。
  8. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、
    　前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、
    　前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    　前記要求フレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
  9. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信手段であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信手段と、
    　前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    　前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
  10. 　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号と終了シーケンス番号の情報を含め、前記特定情報は、前記各リンクで送信していない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを含めることを特徴とする請求項８または９に記載の通信装置。
  11. 　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信していない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項８または９に記載の通信装置。
  12. 　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信していない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報を含むことを特徴とする請求項８または９に記載の通信装置。
  13. 　前記シーケンス情報は、前記各リンクで送信していない前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項８から１２のいずれか１項に記載の通信装置。
  14. 　前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項１３に記載の通信装置。
  15. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、
    　前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、
    　前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    　前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信したデータフレームのシーケンス番号を識別する情報とを含むことを特徴とする通信装置。
  16. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信手段と、
    　前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信手段と、
    　前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信手段と、を有し、
    　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    　前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレーム群に含まれるデータフレームに対する受信結果を含む、通信装置。
  17. 　前記特定情報は、前記各リンクで送信された各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報を含むことを特徴とする請求項１６に記載の通信装置。
  18. 　前記特定情報は、前記各リンクで送信された各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項１６に記載の通信装置。
  19. 　前記特定情報は、前記各リンクで送信された各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報とを含むことを特徴とする請求項１６に記載の通信装置。
  20. 　前記シーケンス情報は、前記各リンクで送信した前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項１６から１９のいずれか１項に記載の通信装置。
  21. 　前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項２０に記載の通信装置。
  22. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信手段と、
    　前記通信相手装置から、前記複数のリンクの各リンクで送信されていない複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信手段と、
    　前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信手段と、を有し、
    　前記シーケンス情報は、前記各リンクで送信されていない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    　前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、通信装置。
  23. 　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号と終了シーケンス番号の情報を含み、前記特定情報は、前記各リンクで送信されていない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを含めることを特徴とする請求項２２に記載の通信装置。
  24. 　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信されていない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項２２に記載の通信装置。
  25. 　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信されていない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報を含むことを特徴とする請求項２２に記載の通信装置。
  26. 　前記シーケンス情報は、前記各リンクで送信されていない前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項２２から２５のいずれか１項に記載の通信装置。
  27. 　前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項２６に記載の通信装置。
  28. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    　通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信手段と、
    　前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信手段と、
    　前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信手段と、を有し、
    　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信されたデータフレームのシーケンス番号を識別する情報とを含み、
    　前記Ａｃｋフレームは、前記シーケンス情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、通信装置。
  29. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信工程と、
    　前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信工程と、
    　前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    　前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
  30. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信手段であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信手段と、
    　前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    　前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
  31. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信工程と、
    　前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信工程と、
    　前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    　前記要求フレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
  32. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信工程であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信工程と、
    　前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    　前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
  33. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信工程と、
    　前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信工程と、
    　前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    　前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    　　前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信したデータフレームのシーケンス番号を識別する情報とを含むことを特徴とする制御方法。
  34. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信工程と、
    　前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信工程と、
    　前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信工程と、を有し、
    　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    　前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレーム群に含まれるデータフレームに対する受信結果を含む、制御方法。
  35. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信工程と、
    　前記通信相手装置から、前記複数のリンクの各リンクで送信されていない複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信工程と、
    　前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信工程と、を有し、
    　前記シーケンス情報は、前記各リンクで送信されていない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    　前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、制御方法。
  36. 　ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    　通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信工程と、
    　前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信工程と、
    　前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信工程と、を有し、
    　前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信されたデータフレームのシーケンス番号を識別する情報とを含み、
    　前記Ａｃｋフレームは、前記シーケンス情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、制御方法。
  37. 　コンピュータを、請求項１から２８のいずれか１項に記載の通信装置として機能させるためのプログラム。
PCT/JP2021/040508 2020-12-08 2021-11-04 通信装置、通信装置の制御方法、およびプログラム WO2022123967A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180082391.4A CN116602031A (zh) 2020-12-08 2021-11-04 通信装置、通信装置的控制方法和程序
EP21903071.5A EP4262299A1 (en) 2020-12-08 2021-11-04 Communication apparatus, communication apparatus control method, and program
US18/331,080 US20230318790A1 (en) 2020-12-08 2023-06-07 Communication apparatus and control method of communication apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-203656 2020-12-08
JP2020203656A JP2022091003A (ja) 2020-12-08 2020-12-08 通信装置、通信装置の制御方法、およびプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/331,080 Continuation US20230318790A1 (en) 2020-12-08 2023-06-07 Communication apparatus and control method of communication apparatus

Publications (1)

Publication Number Publication Date
WO2022123967A1 true WO2022123967A1 (ja) 2022-06-16

Family

ID=81973643

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/040508 WO2022123967A1 (ja) 2020-12-08 2021-11-04 通信装置、通信装置の制御方法、およびプログラム

Country Status (5)

Country Link
US (1) US20230318790A1 (ja)
EP (1) EP4262299A1 (ja)
JP (1) JP2022091003A (ja)
CN (1) CN116602031A (ja)
WO (1) WO2022123967A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017536004A (ja) * 2014-10-01 2017-11-30 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおけるデータ送信方法及びこのための装置
JP2018050133A (ja) 2016-09-20 2018-03-29 キヤノン株式会社 通信装置、制御方法、及びプログラム
WO2020218016A1 (ja) * 2019-04-22 2020-10-29 ソニー株式会社 無線通信装置および方法
JP2020203656A (ja) 2019-06-19 2020-12-24 ダイムラー・アクチェンゲゼルシャフトＤａｉｍｌｅｒ ＡＧ 駆動ユニット支持装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017536004A (ja) * 2014-10-01 2017-11-30 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおけるデータ送信方法及びこのための装置
JP2018050133A (ja) 2016-09-20 2018-03-29 キヤノン株式会社 通信装置、制御方法、及びプログラム
WO2020218016A1 (ja) * 2019-04-22 2020-10-29 ソニー株式会社 無線通信装置および方法
JP2020203656A (ja) 2019-06-19 2020-12-24 ダイムラー・アクチェンゲゼルシャフトＤａｉｍｌｅｒ ＡＧ 駆動ユニット支持装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROJAN CHITRAKAR (PANASONIC): "Multi-link block ack architecture", IEEE DRAFT; 11-20-0055-02-00BE-MULTI-LINK-BLOCK-ACK-ARCHITECTURE, IEEE-SA MENTOR, PISCATAWAY, NJ USA, vol. 802.11 EHT; 802.11be, no. 2, 23 April 2020 (2020-04-23), Piscataway, NJ USA , pages 1 - 10, XP068167606 *

Also Published As

Publication number Publication date
US20230318790A1 (en) 2023-10-05
JP2022091003A (ja) 2022-06-20
EP4262299A1 (en) 2023-10-18
CN116602031A (zh) 2023-08-15

Similar Documents

Publication Publication Date Title
CN107950071B (zh) 用于lte-wlan聚合的动态pdcp状态报告轮询的方法
US9094832B2 (en) Method of selectively applying a PDCP function in wireless communication system
JP4536976B2 (ja) 移動通信システムにおいて高信頼リンクを提供する技術
WO2018127238A1 (zh) 信息处理方法及装置
EP2493239B1 (en) Method for acquiring packet data convergence protocol (pdcp) status report and pdcp entity
JP3712977B2 (ja) パケット交換データ伝送におけるデータパケット番号付け
JP3811068B2 (ja) トランスペアレントｒｌｃを通じた固定サイズｐｄｕの送信
TWI427951B (zh) 在行動電信系統中執行無線電協定之方法以及行動電信之傳輸器
JP5053440B2 (ja) 無線メッシュネットワークにおけるデータ送信方法及びａ−ｍｓｄｕフォーマット
JP4906844B2 (ja) 無線移動通信システムで下位階層データブロックを生成する方法
KR101879969B1 (ko) 데이터 전송 방법 및 디바이스
KR101005371B1 (ko) 무선 대역 할당 방법 및 무선 기지국
JP2008509622A (ja) Ａｃｋフレーム伝送方法及び装置
EP3353930A1 (en) Enhancement of pdcp status report
JP2007527179A (ja) 無線通信システムの分離型媒体アクセス制御プロトコル構造と、これを用いたデータ送受信方法並びにハンドオーバー方法及びそのシステム
WO2010121416A1 (zh) 中继链路中处理数据的方法、中继节点和系统
WO2014000682A1 (zh) 一种进行切换的方法、系统和设备
EP3836626B1 (en) Handover method and base station
EP1601144A1 (en) Method for communication between coordinator-based wireless networks
CN112399476B (zh) 一种数据包传输方法、终端设备及网络设备
CN115804146A (zh) 多链路装置之间的低时延数据的无线通信的方法和设备
WO2022123967A1 (ja) 通信装置、通信装置の制御方法、およびプログラム
TWI797414B (zh) 用於行動性增強之方法及其使用者設備
WO2017133595A1 (zh) 数据处理的方法及装置
CN111106908B (zh) 一种数据传输方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21903071

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180082391.4

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021903071

Country of ref document: EP

Effective date: 20230710