JP4374001B2 - COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM - Google Patents
COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM Download PDFInfo
- Publication number
- JP4374001B2 JP4374001B2 JP2006188619A JP2006188619A JP4374001B2 JP 4374001 B2 JP4374001 B2 JP 4374001B2 JP 2006188619 A JP2006188619 A JP 2006188619A JP 2006188619 A JP2006188619 A JP 2006188619A JP 4374001 B2 JP4374001 B2 JP 4374001B2
- Authority
- JP
- Japan
- Prior art keywords
- data frame
- frame
- error
- block ack
- information
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Description
本発明は、物理層のキャリアセンス情報とMAC層のキャリアセンス情報に基づいて媒体アクセス制御を行なう通信装置、通信方法、および通信システムに関する。 The present invention relates to a communication apparatus, a communication method, and a communication system that perform medium access control based on carrier sense information of a physical layer and carrier sense information of a MAC layer.
同一の媒体を共有して通信を行なう複数の通信装置がどのように媒体を利用して通信データを送信するかを決めるのが、媒体アクセス制御(MAC: Media Access Control)である。媒体アクセス制御は、同時に2つ以上の通信装置が同一の媒体を利用して通信データの送信を行なった結果、受信側の通信装置が通信データを分離できなくなる事象(衝突)がなるべく少なくなり、一方、送信要求を持つ通信装置が存在するにもかかわらず媒体がいずれの通信装置によっても利用されない事象がなるべく少なくなるように、通信装置から媒体へのアクセスを制御するための技術である。 Media access control (MAC) determines how a plurality of communication apparatuses that communicate by sharing the same medium use the medium to transmit communication data. In the medium access control, as a result of two or more communication devices transmitting communication data using the same medium at the same time, the number of events (collisions) in which the communication device on the receiving side cannot separate the communication data is reduced as much as possible. On the other hand, this is a technique for controlling access from a communication device to a medium so that the number of events in which the medium is not used by any communication device despite the presence of a communication device having a transmission request is minimized.
しかし、特に無線通信においては、通信装置がデータを送信しながら同時に送信データをモニタすることは困難であることから、衝突検出を前提としない媒体アクセス制御(MAC)が必要である。無線LANの代表的な技術標準であるIEEE802.11はCSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)を採用している。IEEE802.11のCSMA/CAでは、MACフレームのヘッダーに、該フレームに続く1つ以上のフレーム交換からなる一連のシーケンスが終了するまでの期間(Duration)が設定される。この期間において、該シーケンスに関係がなく送信権を持たない通信装置は、媒体の仮想的な占有状態を判断することにより、送信を待機する。したがって、衝突の発生が回避される。一方、該シーケンスで送信権を持つ通信装置は、実際に物理媒体が占有されている期間を除き、媒体は使用されていないものと認識する。IEEE802.11では、このようなMAC層の仮想キャリアセンスと、物理層の物理キャリアセンスとの組み合わせによって媒体の状態を判定し、媒体アクセスを制御する旨が規定されている。 However, particularly in wireless communication, since it is difficult for a communication apparatus to monitor transmission data while transmitting data, medium access control (MAC) that does not assume collision detection is required. IEEE802.11, which is a typical technical standard for wireless LAN, employs CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance). In CSMA / CA of IEEE802.11, a period (Duration) until a sequence of one or more frame exchanges following the frame ends is set in the header of the MAC frame. During this period, a communication apparatus that is not related to the sequence and has no transmission right waits for transmission by determining the virtual occupation state of the medium. Therefore, the occurrence of a collision is avoided. On the other hand, the communication apparatus having the transmission right in the sequence recognizes that the medium is not used except for the period when the physical medium is actually occupied. IEEE802.11 stipulates that the state of the medium is determined based on the combination of the virtual carrier sense of the MAC layer and the physical carrier sense of the physical layer to control the medium access.
CSMA/CAを採用しているIEEE802.11は、これまで主として物理層プロトコルを変更することによって通信速度の高速化を図ってきた。2.4GHz帯についてはIEEE802.11(1997年、2Mbps)からIEEE802.11b(1999年、11Mbps)へ、そしてIEEE802.11g(2003年、54Mbps)へと変遷している。5GHz帯については、今のところIEEE802.11a(1999年、54Mbps)のみが標準として存在する。そして、2.4GHz帯および5GHz帯の両方で更なる高速化を目指す標準規格を策定するためにIEEE802.11 TGn(Task Group n)が既に設立されている。 IEEE802.11, which employs CSMA / CA, has so far attempted to increase the communication speed mainly by changing the physical layer protocol. The 2.4 GHz band is changing from IEEE802.11 (1997, 2 Mbps) to IEEE802.11b (1999, 11 Mbps) and to IEEE802.11g (2003, 54 Mbps). For the 5 GHz band, only IEEE 802.11a (1999, 54 Mbps) exists as a standard so far. And IEEE802.11 TGn (Task Group n) has already been established in order to formulate a standard aiming at further speeding up in both 2.4 GHz band and 5 GHz band.
さらに、サービス品質(QoS:Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するQoSとして、従来のポーリング手順を拡張したHCCA(HCF Controlled Access;HCFコントロールド・アクセス)がある。HCCAでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。特許文献2は、IEEE802.11e規格のQoSについて言及しており、無線ネットワークにおける通信装置間の通信に優先順位を付与する方法を開示する。
通信速度の高速化の実現において既存の規格と同一の周波数帯を用いるのであれば、新たに提供される通信装置は、既存の規格に従う通信装置との共存が可能であって、後方互換性も維持されることが好ましい。したがって、MAC層のプロトコルは基本的には既存の規格と整合するCSMA/CAに従うのが良いと考えられる。この場合、CSMA/CAに係わる時間的なパラメータ、例えばフレーム間の時間間隔(IFS: Interframe Space)やバックオフ期間を既存の規格と揃える必要がある。 If the same frequency band as the existing standard is used to realize higher communication speed, the newly provided communication device can coexist with the communication device that conforms to the existing standard, and the backward compatibility is also achieved. Preferably it is maintained. Therefore, it is considered that the MAC layer protocol should basically conform to CSMA / CA consistent with existing standards. In this case, it is necessary to align time parameters related to CSMA / CA such as a time interval (IFS: Interframe Space) between frames and a back-off period with the existing standards.
ここで、物理層に関して通信速度の高速化を図れたとしても、通信の実質的なスループットを向上できないという問題点がある。すなわち、物理層の高速化が実現された場合、PHYフレームのフォーマットはもはや効率的ではなくなり、このことに起因するオーバヘッドがスループットの向上を阻害すると考えられる。PHYフレームにおいて、CSMA/CAに係わる時間的なパラメータはMACフレームに固定的に付随している。また、PHYフレームヘッダは各MACフレーム毎にそれぞれ必要である。 Here, even if the communication speed can be increased with respect to the physical layer, there is a problem that the substantial throughput of communication cannot be improved. That is, when the physical layer is speeded up, the PHY frame format is no longer efficient, and the overhead caused by this is considered to hinder the improvement of the throughput. In the PHY frame, temporal parameters related to CSMA / CA are fixedly attached to the MAC frame. A PHY frame header is required for each MAC frame.
オーバヘッドを削減してスループットを向上させる方法の一つとして、最近のdraft IEEE802.11e draft 5.0 (IEEE802.11のQoS強化) で導入されたBlock ACKがある。これを用いれば、バックオフ無しで複数のMACフレームを連続的に送信できるため、バックオフの量は削減できるが、物理層のヘッダは削減されない。また、初期のdraft IEEE802.11eで導入されたアグリゲーションによれば、バックオフ量と物理層ヘッダのいずれも削減可能だが、従来の物理層の制約によりMACフレームが含まれる物理層のフレームの長さを約4k byte以上にはできないため、効率の向上には大きな制約がある。仮に物理層のフレームを長くできたとしても、エラー耐性が低下するという問題が生じる。 One method for reducing overhead and improving throughput is Block ACK introduced in the recent draft IEEE802.11e draft 5.0 (IEEE802.11 QoS enhancement). If this is used, a plurality of MAC frames can be continuously transmitted without backoff, so the amount of backoff can be reduced, but the header of the physical layer is not reduced. In addition, according to the aggregation introduced in the early draft IEEE802.11e, both the backoff amount and the physical layer header can be reduced, but the length of the physical layer frame that includes the MAC frame due to the limitations of the conventional physical layer Since it cannot be about 4k bytes or more, there are significant restrictions on improving efficiency. Even if the frame of the physical layer can be lengthened, there arises a problem that error tolerance is lowered.
本発明はかかる問題を解決すべくなされたものであり、既存の装置との共存が可能であって、しかもフレームフォーマットの効率化により複数のフレームを送信することに伴うオーバヘッドを解消して通信の実質的なスループットを向上できる通信装置、通信方法、および通信システムを提供することを目的とする。 The present invention has been made to solve such a problem, and can coexist with an existing apparatus, and further eliminates the overhead associated with transmitting a plurality of frames by improving the efficiency of the frame format. It is an object of the present invention to provide a communication device, a communication method, and a communication system that can improve substantial throughput.
本発明の一観点に係る通信装置は、複数のMACフレームがアグリゲートされた1つの物理フレームを作成する物理フレーム作成手段と、
前記物理フレームを送信する送信手段と、前記物理フレームの終了に暗黙の送達確認要求として応答された送達確認フレームを受信する受信手段とを具備する通信装置である。
A communication apparatus according to an aspect of the present invention includes a physical frame creation unit that creates one physical frame in which a plurality of MAC frames are aggregated;
It is a communication apparatus comprising: a transmission unit that transmits the physical frame; and a reception unit that receives a delivery confirmation frame responded as an implicit delivery confirmation request to the end of the physical frame.
本発明のさらに別の観点に係る通信装置は、複数のMACフレームがアグリゲートされた1つの物理フレームを受信する受信手段と、前記受信手段が受信した物理フレームの終了に暗黙の送達確認要求として応答し、該物理フレーム内の複数のMACフレームについての受信状況を送達確認ビットマップとして含み、該物理フレームにおいて正常に受信できた先頭のMACフレームのシーケンス番号が送達確認始点シーケンス番号に設定された送達確認フレームを作成する作成手段と、前記送達確認フレームを送信する送信手段とを具備する通信装置である。 A communication apparatus according to still another aspect of the present invention includes a receiving unit that receives one physical frame in which a plurality of MAC frames are aggregated, and an implicit delivery confirmation request at the end of the physical frame received by the receiving unit. In response, the reception status for a plurality of MAC frames in the physical frame is included as a delivery confirmation bitmap, and the sequence number of the first MAC frame that was successfully received in the physical frame is set as the delivery confirmation start sequence number It is a communication apparatus comprising a creation means for creating a delivery confirmation frame and a transmission means for transmitting the delivery confirmation frame.
本発明によれば、フレームフォーマットの効率化により複数のフレームを送信することに伴うオーバーヘッドを解消して通信の実質的なスループットを向上できる通信装置、通信方法、および通信システムを提供できる。 According to the present invention, it is possible to provide a communication device, a communication method, and a communication system that can eliminate overhead associated with transmitting a plurality of frames by improving the efficiency of the frame format and improve the substantial throughput of communication.
(第一の実施形態)
図1は本発明の第一の実施形態に係る通信装置の構成を示すブロック図である。この通信装置100は無線リンクを介して他の通信装置と通信する装置であり、物理層、MAC層、およびリンク層のそれぞれに相当する処理ユニット101、102、103を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはLSIに組み込まれたCPUにより実行されるファームウェア等として実現される。物理層の処理ユニット(以下、「処理ユニット」の表記を省略)101にはアンテナ104が接続されている。MAC層102はMACフレームのアグリゲーション(集約)処理部105を有する。このアグリゲーション処理部105は、キャリアセンス制御部106と、再送制御部107とを備え、後に詳しく説明するブロックACK(複数のMACフレームに対する送達確認)フレームの送受信及びブロックACKフレームに基づく再送制御等を行う。
(First embodiment)
FIG. 1 is a block diagram showing a configuration of a communication apparatus according to the first embodiment of the present invention. The
物理層101は、二種類の物理層プロトコルに対応可能に構成される。それぞれのプロトコル処理のために、物理層101は第一種の物理層プロトコル処理部109および第二種の物理層プロトコル処理部110を有する。なお、実装では第一種の物理層プロトコル処理部109と第二種の物理層プロトコル処理部110との間で回路の共用などがしばしば行なわれるため、これらは必ずしも独立して存在するわけではない。
The
本発明の実施形態では、第一種の物理層プロトコルはIEEE802.11aに規定されるプロトコルとし、第二種の物理層プロトコルは送信側と受信側とでそれぞれ複数のアンテナを用いる、いわゆるMIMO(Multiple Input Multiple Output)によるプロトコルと仮定する。周波数帯域を同一に保ってもアンテナの数にほぼ比例した伝送容量の増加が見込めることから、MIMOはIEEE802.11の更なる高スループット化を目指すために利用可能な技術の一つである。リンク層103に関しては、IEEE802で規定される通常のリンク層機能を有するものとする。伝送レートを向上するために採用する技術はMIMOに限定されない。例えば、周波数占有帯域を増やすような方法、およびそれとMIMOの組み合わせでも構わない。
In the embodiment of the present invention, the first type physical layer protocol is a protocol defined in IEEE802.11a, and the second type physical layer protocol uses a plurality of antennas on the transmitting side and the receiving side. It is assumed that the protocol is based on (Multiple Input Multiple Output). Even if the frequency band is kept the same, the transmission capacity can be expected to increase almost in proportion to the number of antennas. Therefore, MIMO is one of the technologies that can be used to achieve higher throughput of IEEE802.11. The
IEEE802.11e Draft 8.0によれば、MAC(媒体アクセス制御;Media Access Control)層の伝送効率を改善するための技術として、ブロックACK(Block ACK)が提案されている。ブロックACKでは、端末が、あるチャネル使用期間(TXOP: Transmission Opportunity)の間、QoS(Quality of Service)データをSIFS(Short Inter Frame Space)とよばれる最小フレーム間隔で送信し、その後、受信端末に対し、過去の受信履歴状況を要求するためにブロックACK要求(Block ACK Request)を任意のタイミングで送信する。受信側では、ブロックACK要求の定める始点シーケンス番号を元に、過去の受信ステータス状況をビットマップ形式に変換し、ブロックACK(Block ACK)として応答する。 According to IEEE 802.11e Draft 8.0, Block ACK (Block ACK) is proposed as a technique for improving transmission efficiency of a MAC (Media Access Control) layer. In block ACK, a terminal transmits QoS (Quality of Service) data at a minimum frame interval called SIFS (Short Inter Frame Space) during a certain channel usage period (TXOP: Transmission Opportunity), and then to the receiving terminal. On the other hand, a block ACK request (Block ACK Request) is transmitted at an arbitrary timing in order to request a past reception history situation. On the reception side, based on the start sequence number determined by the block ACK request, the past reception status is converted into a bitmap format and responded as a block ACK (Block ACK).
図2及び図3は、IEEE802.11e Draft 8.0で規定されているブロックACK要求のフレームフォーマット、及びブロックACKのフレームフォーマットをそれぞれ示したものである。図2及び図3におけるFrame Control(フレーム制御)フィールド、Duration(期間)フィールド、Receiver Address(宛先アドレス)、Transmitter Address(送信元アドレス)は、IEEE802.11で規定されているMACヘッダーである。BAR Control(Block ACK Request Control)フィールドには、4ビットのTID(Traffic Identifier: 優先度識別子)が存在する。QoSデータは優先度(TID)毎に存在し、それぞれ独立的にシーケンス番号、及びフラグメント番号が割り当てられることから、ブロックACKにおける受信ステータスも、優先度毎に用意する必要がある。ブロックACK要求のBAR ControlのTIDフィールドは、この優先度を指定するために用いられる。図2のブロックACK要求のBlock ACK Starting Sequence Control(始点シーケンス制御)は、4ビットのフラグメント番号フィールド、及び12ビットのStarting Sequence Number(始点シーケンス番号)フィールドから構成されている。Starting Sequence Numberは、受信端末が過去の受信履歴を遡り、Starting Sequence Numberに対応するシーケンス番号からの相対的な受信ステータスを元にブロックACKを作成するために用いられる。図3のブロックACKのBA Controlは、図2のBAR Controlと同様に、4ビットのTIDフィールドを含む。Block ACK Starting Sequence Control(始点シーケンス制御)は、該ブロックACK中のBlock ACK Bitmap30の示す受信ステータスの始点シーケンス番号を示す。IEEE802.11e Draft 8.0によれば、Block ACK Bitmap30のサイズは1024ビットの固定長であり、これにより最大64MSDU(MAC Service Data Unit)のデータに対する受信履歴を通知することが可能である。1MSDUは、最大で16個のフラグメント(分割)化されたMPDU(MAC Protocol Data Unit)を含むことができる。尚、図2及び図3のそれぞれのMACフレームには、誤り検査のためのFCS(Frame Check Sequence)が付加される。従って、最大1024MPDUに対する受信履歴の通知を行なうために、Block ACK Bitmap30のサイズは1024となる。
2 and 3 show the frame format of the block ACK request and the frame format of the block ACK specified by IEEE802.11e Draft 8.0, respectively. The Frame Control field, Duration field, Receiver Address (destination address), and Transmitter Address (source address) in FIGS. 2 and 3 are MAC headers defined by IEEE 802.11. In the BAR Control (Block ACK Request Control) field, there is a 4-bit TID (Traffic Identifier). Since QoS data exists for each priority (TID) and a sequence number and a fragment number are independently assigned, it is necessary to prepare a reception status in block ACK for each priority. The TID field of BAR Control in the block ACK request is used to specify this priority. Block ACK Starting Sequence Control of the block ACK request in FIG. 2 includes a 4-bit fragment number field and a 12-bit Starting Sequence Number field. The Starting Sequence Number is used for the receiving terminal to go back in the past reception history and create a block ACK based on the relative reception status from the sequence number corresponding to the Starting Sequence Number. The BA Control of the block ACK in FIG. 3 includes a 4-bit TID field, similar to the BAR Control in FIG. Block ACK Starting Sequence Control indicates the start point sequence number of the reception status indicated by the
図4及び図5はHCCA(Hybrid coordination function Controlled Channel Access)におけるブロックACK伝送のシーケンス例を示している。同図に示すHC(Hybrid Coordinator)は、IEEE802.11e Draft 8.0におけるQoSアクセスポイント(QoS-AP)であり、スケジューリングの主体となって、QoS端末(QSTA: QoS Station)へのチャネル使用期間(TXOP)の付与、ダウンリンク(HCからQSTAへの下り方向)伝送を行う。QSTAへのTXOPの付与は、HCからのQoS CF-Pollフレーム(QoS Contention Free-Poll: HCがQSTAに送信を許可するために送信するQoS対応ポーリングフレーム)を元に行われる。図4において、まずHCがQSTA1に対し、QoS CF-Pollフレームを送信することでチャネル使用期間(TXOP1)を与える。QSTAはTXOPの間、任意のフレームを送信することが可能であるが、図4の例では、QSTA2にQoSデータをSIFS間隔で送信している。QSTA1のTXOP期間が終了すると、今度はHCがQSTA1に対しQoSデータをバースト的に送信している(TXOP2)。HCのチャネル期間が終了すると、HCはQSTA1に再びチャネル使用期間(TXOP3)を付与する。QSTA1は、QSTA2にブロックACK要求を送信することで、Block ACK Starting Sequence Controlで指定される相対的な受信ステータスを宛先に要求する。図4は、即時型ブロックACKの例であり、この場合、ブロックACK要求を受信した端末はSIFS期間後にブロックACKを応答しなくてはならない。具体的には、QSTA2はQSTA1からのブロックACK要求40に対しSIFS期間後にブロックACK41を応答しなければならない。また、TXOP4において、QSTA2はHCからのブロックACK要求42に対しSIFS期間後にブロックACK43を応答しなければならない。
4 and 5 show a sequence example of block ACK transmission in HCCA (Hybrid coordination function Controlled Channel Access). The HC (Hybrid Coordinator) shown in the figure is a QoS access point (QoS-AP) in IEEE802.11e Draft 8.0, which is the main subject of scheduling, and the channel usage period (TXOP) to the QoS terminal (QSTA) ) And downlink (downlink from HC to QSTA) transmission. The TXOP is assigned to the QSTA based on the QoS CF-Poll frame from the HC (QoS Contention Free-Poll: QoS-compliant polling frame transmitted by the HC to permit transmission to the QSTA). In FIG. 4, first, the HC gives a channel use period (TXOP1) by transmitting a QoS CF-Poll frame to QSTA1. QSTA can transmit an arbitrary frame during TXOP, but in the example of FIG. 4, QoS data is transmitted to QSTA2 at SIFS intervals. When the TXOP period of QSTA1 ends, HC is now sending QoS data to QSTA1 in bursts (TXOP2). When the HC channel period ends, the HC gives the channel use period (TXOP3) to QSTA1 again. QSTA1 sends a block ACK request to QSTA2, and requests the relative reception status specified by Block ACK Starting Sequence Control from the destination. FIG. 4 shows an example of an immediate block ACK. In this case, a terminal that has received a block ACK request must respond with a block ACK after the SIFS period. Specifically, QSTA2 must respond with a
一方、図5は遅延型ブロックACKの例を示しており、ブロックACK要求を受信した端末は、まずIEEE802.11のACKを返し、任意の期間後にブロックACKを送信する。具体的には、QSTA1からのブロックACK要求50を受信したQSTA2は、まずIEEE802.11のACK51を返し、任意の期間後にブロックACK52を返す。最後にブロックACKを受け取ったデータ送信端末が、ACKを返信することで遅延型ブロックACKの一連のシーケンスが完了する。尚、ブロックACK対象のQoSデータは、従来のMACヘッダーに対しIEEE802.11e Draft 8.0用に拡張されたQoS Control field中の、Ack Policyフィールドを用いて受信側に通知される。
On the other hand, FIG. 5 shows an example of a delayed block ACK. A terminal that receives a block ACK request first returns an IEEE 802.11 ACK and transmits a block ACK after an arbitrary period. Specifically, QSTA2 that received the
図6及び図7を参照してブロックACK作成に必要な処理手順を説明する。図6において、送信端末がQoSデータをバースト的に送信した後、任意のBlock ACK Starting Sequence Controlを指定(図6の例ではシーケンス番号「1」、フラグメント番号「0」)したブロックACK要求を送信する。受信端末では、送信元アドレス、優先度(TID)毎に受信履歴を記憶しており、Block ACK Starting Sequence Controlに該当するフレームまで遡って、そこからの相対的な受信ステータスを64MSDU分(1024ビット)のブロックACKビットマップ(Block ACK Bitmap)として作成する。図6及び図7の例では、送信側が、シーケンス番号「1」のMSDU(3分割にフラグメント)、シーケンス番号「2」のMSDU(フラグメント無)等を送信した場合を想定している。図6のビット番号60はブロックACKビットマップの先頭からの相対位置を示している。図6のブロックACKビットマップ61の例では、送信側が送ったQoSデータのうち、シーケンス番号「1」のMSDU(フラグメント番号63が「0」「1」「2」)は正常に受信しているが、シーケンス番号「2」のMSDU(フラグメント無)は誤り等により受信失敗したことを示している。ブロックACKのBlock ACK Starting Sequence Control62は、ブロックACK要求で指定された値をコピーして送信する。図7の送信端末は、ブロックACKのBlock ACK Starting Sequence Control、及びブロックACKビットマップの内容を元に、再送すべきフレームを決定する。図6及び図7の例では、シーケンス番号「2」(フラグメント無)が誤っていることから、ブロックACKビットマップ61の該当部分が"0"になっている。結果、送信端末はシーケンス番号「2」のMSDU(フラグメント無)を再送しなくてはならないことを判断する。
A processing procedure necessary for creating a block ACK will be described with reference to FIGS. In FIG. 6, after the transmission terminal transmits QoS data in bursts, a block ACK request is transmitted with any Block ACK Starting Sequence Control specified (sequence number “1”, fragment number “0” in the example of FIG. 6). To do. The receiving terminal stores the reception history for each source address and priority (TID), and goes back to the frame corresponding to Block ACK Starting Sequence Control, and the relative reception status from there is 64 MSDU (1024 bits). ) Block ACK bitmap (Block ACK Bitmap). In the example of FIGS. 6 and 7, it is assumed that the transmission side transmits an MSDU with a sequence number “1” (fragmented into three divisions), an MSDU with a sequence number “2” (no fragment), and the like. A
以上のように、IEEE802.11e Draft 8.0で定められているブロックACKは、QoSデータ受信側でするべき処理が多く、ブロックACK要求を受信してからSIFS期間後にブロックACKを応答する、即時型ブロックACKの実現が一般に難しいと考えられている。 As described above, block ACK specified in IEEE802.11e Draft 8.0 has many processes that should be performed on the QoS data reception side, and an immediate block that responds with a block ACK after the SIFS period after receiving the block ACK request. Realization of ACK is generally considered difficult.
そこで本発明の実施形態では、かかる問題を解決するための手法を提案する。本発明の第一の実施形態は、複数MPDUがアグリゲートされ、かつ該複数MPDUの末尾にブロックACK要求がアグリゲートされたPSDUを受信した場合、受信ステータスを反射的に即時型ブロックACKとして応答するというものである。 Therefore, the embodiment of the present invention proposes a method for solving such a problem. In the first embodiment of the present invention, when a PSDU in which a plurality of MPDUs are aggregated and a block ACK request is aggregated at the end of the plurality of MPDUs is received, the reception status is reflected back as an immediate block ACK. It is to do.
IEEE802.11の規定によれば、フレームのサイズが予め定められた閾値よりも大きい場合、フラグメント(分割)処理がなされる。フラグメント化したMPDUには、フラグメント番号が割り当てられる。MACヘッダー内のフラグメント番号はMSDU内での当該MPDUの相対位置を表す値で、通常は0から始まる連続値を取る。受信端末では、このフラグメント番号、及びシーケンス番号を元に、元のMSDUへと組み立てる。 According to the specification of IEEE802.11, when the frame size is larger than a predetermined threshold value, fragmentation (division) processing is performed. A fragment number is assigned to the fragmented MPDU. The fragment number in the MAC header is a value indicating the relative position of the MPDU in the MSDU, and usually takes a continuous value starting from 0. The receiving terminal assembles the original MSDU based on the fragment number and sequence number.
一般に、IEEE802.11及びIEEE802.11e Draft 8.0のMAC伝送手順では、フラグメント化したMPDUをSIFS間隔で送信することから、フレーム間隔(SIFS)分のオーバーヘッドが生じて伝送効率が低下する。したがって、ハイスループット化を実現するためには、フラグメント化をしないことが望ましい。フラグメントをしないことを前提とする本実施形態に従えば、図8に示すように、Block ACK Bitmap80のビット数を最大64MPDU分に圧縮することが可能である。つまり、block ACK Bitmap80のサイズは、1つのMSDUに対し1つのMPDUが対応する場合の、最大MSDU数に相当し、64ビット、つまり従来の16分の1に抑えられる。
Generally, in the MAC transmission procedure of IEEE802.11 and IEEE802.11e Draft 8.0, since fragmented MPDUs are transmitted at SIFS intervals, overhead corresponding to the frame interval (SIFS) occurs and transmission efficiency decreases. Therefore, in order to realize high throughput, it is desirable not to fragment. According to this embodiment on the assumption that no fragmentation is performed, the number of bits of the
以後、図8に示すようなブロックACKフレームを「圧縮ブロックACK(圧縮送達確認)」と呼ぶことにする。送受信端末間で圧縮ブロックACKを用いてブロックACK伝送を行う際には、予めネゴシエーションを行ってもよい。具体的なネゴシエーションの方法としては、例えばIEEE802.11e Draft 8.0に記述されるブロックACK設定の手順を拡張することが考えられる。つまり、ADDBA要求により圧縮ブロックACKを用いることを要求し、ADDBA応答により圧縮ブロックACKの使用許可、ないしは拒絶を行なうといったものである。この設定の対象となったデータ、ブロックACK要求、(圧縮)ブロックACKのフレーム交換に際し、全てが圧縮ブロックACKで応答しなければならないという制約を設けても良いし、通常のブロックACKと圧縮ブロックACKを取り混ぜて応答することを許容しても良い。また、ブロックACK要求に通常のブロックACKではなく、圧縮ブロックACKを要求または許容する情報を追加しても良い。ブロックACK要求で圧縮ブロックACKを要求または許容する方法は、事前のブロックACK設定手順がある場合にも、無い場合にも適用することが出来る。 Hereinafter, the block ACK frame as shown in FIG. 8 is referred to as “compressed block ACK (compression delivery confirmation)”. When performing block ACK transmission using the compressed block ACK between the transmitting and receiving terminals, negotiation may be performed in advance. As a specific negotiation method, for example, it is conceivable to extend the block ACK setting procedure described in IEEE802.11e Draft 8.0. That is, it is requested to use the compressed block ACK by the ADDBA request, and the use of the compressed block ACK is permitted or rejected by the ADDBA response. There may be a restriction that all data, block ACK requests, and (compressed) block ACK frames must be responded with a compressed block ACK, or a normal block ACK and a compressed block. It may be acceptable to mix ACKs and respond. Further, information that requests or allows a compressed block ACK instead of a normal block ACK may be added to the block ACK request. The method of requesting or allowing a compressed block ACK with a block ACK request can be applied with or without a prior block ACK setting procedure.
また、MACレベルでハイスループットを実現するために、個々のMPDUを1つのPSDUにアグリゲートし、一度に送信する方法が考えられる。図9及び図10に複数MPDUのアグリゲート例を示す。図9の例では、PSDU内の個々のMPDUの先頭に、MPDUの長さを示すフィールドと、MPDUの長さ情報に対するCRC(Cyclic Redundancy Check)が存在する。MPDUの長さ情報とCRCを併せて、以下、「MPDUセパレーションフィールド」と呼ぶことにする。なお、MPDUセパレーションフィールドには、他の付加的な情報、予約領域、バイトアラインメントを整えるための領域(例えば4バイトアラインメントに揃うようにする)などが含まれていても構わない。図9のようなPSDUを受信した端末は、先頭から順に、MPDUセパレーションフィールドが誤りでなければ、後続するMPDUを切り出し、MPDUのFCS(Frame Check Sequence)を計算する。MPDUセパレーションフィールドが誤りであった場合、続くMPDUの長さが分からないため、適切なバイト単位で連続的にMPDUセパレーションフィールドのCRCを計算(スキャン)していく。CRC計算の結果が正しいMPDUセパレーションに関しては、後続のMPDUに対するFCSを計算し、正常に受信できたかどうかの判断をする。 Also, in order to achieve high throughput at the MAC level, a method is conceivable in which individual MPDUs are aggregated into one PSDU and transmitted at a time. 9 and 10 show examples of aggregation of a plurality of MPDUs. In the example of FIG. 9, a field indicating the length of the MPDU and a CRC (Cyclic Redundancy Check) for the length information of the MPDU exist at the head of each MPDU in the PSDU. The MPDU length information and CRC will be collectively referred to as “MPDU separation field”. Note that the MPDU separation field may include other additional information, a reserved area, an area for adjusting byte alignment (for example, aligning with 4 byte alignment), and the like. If the MPDU separation field is not an error, the terminal that has received PSDU as shown in FIG. 9 cuts out the subsequent MPDU and calculates the FCS (Frame Check Sequence) of the MPDU. If the MPDU separation field is incorrect, the length of the subsequent MPDU is unknown, so the CRC of the MPDU separation field is continuously calculated (scanned) in appropriate bytes. For the MPDU separation with the correct CRC calculation result, the FCS for the subsequent MPDU is calculated to determine whether or not the reception was successful.
一方、図10のアグリゲート例では、PSDUの先頭に複数のMPDUに対する長さ情報がヘッダーとして存在し、複数の長さ情報に対するCRCが付加される。以後、このヘッダーを「MACスーパーフレームヘッダー」と呼ぶことにする。図10のPSDUを受信した端末は、MACスーパーフレームヘッダーのCRC計算を行い、誤りであれば、全てのMPDUが誤ったと判断する。MACスーパーフレームヘッダーが正常に受信できていれば、アグリゲートされた個々のMPDUに対してFCSの計算を行い、正常に受信できたかどうかの判断をする。 On the other hand, in the aggregate example of FIG. 10, length information for a plurality of MPDUs exists as a header at the beginning of the PSDU, and a CRC for the plurality of length information is added. Hereinafter, this header is referred to as a “MAC super frame header”. The terminal that receives the PSDU of FIG. 10 performs CRC calculation of the MAC super frame header, and if it is an error, determines that all MPDUs are incorrect. If the MAC super frame header is normally received, the FCS is calculated for each aggregated MPDU, and it is determined whether or not the MAC super frame header is normally received.
さらに、図9及び図10の例では、複数MPDUをアグリゲートしたPSDUの最後に、ブロックACK要求フレーム90,101をそれぞれアグリゲートしている。尚、図9及び図10の例では、アグリゲート可能なMPDUの最大数を8としているが、この数は8に制限されたものではなく、任意の数を取ってもよいことは言うまでもない。アグリゲート可能な最大数は、予め取り決めておくか、送受信端末間で何かしらのネゴシエーション等を行なう必要があるが、具体的な手続き方法に関しては、詳細には説明しない。 Further, in the examples of FIGS. 9 and 10, block ACK request frames 90 and 101 are aggregated at the end of the PSDU in which a plurality of MPDUs are aggregated. In the example of FIGS. 9 and 10, the maximum number of MPDUs that can be aggregated is 8. However, this number is not limited to 8, and it goes without saying that any number may be taken. The maximum number that can be aggregated must be determined in advance, or some kind of negotiation must be performed between the transmitting and receiving terminals, but a specific procedure method will not be described in detail.
図11乃至図13を参照して、本発明の実施形態に係る基本的な概念を説明する。ここで、送信端末は連続的に割り当てられたシーケンス番号「1」〜「7」のMPDUを送信するものとする。送信端末は、図9又は図10に示したいずれかの手法で複数のMPDU(QoSデータ)を1つのPSDUにアグリゲートし、その末尾に、複数MPDUに対するブロックACK要求111をアグリゲートする。ブロックACK要求111のBlock ACK Starting Sequence Controlの値は、PSDU内にアグリゲートした先頭のMPDUのMACヘッダーに記載されているシーケンス番号と同一にする。ここで送信端末は、様々な宛先、優先度のMACフレームを格納するメインのキューと、アグリゲートしたMPDUを再送するためのサブキューを持つ。図11の例では、シーケンス番号「1」〜「7」のMPDUのコピーを再送に備えてサブキュー内に保存しておく。複数MPDUがアグリゲートされたPSDUを受信した端末は、前記の方法によって複数MPDUの誤り計算を行なう。例えば、図11の例では、PSDU内のシーケンス番号「2」と「5」のMPDUがFCS計算の結果、誤りであった場合である。本発明の実施形態において、PSDU受信端末は、その時点での受信ステータスをBlock ACK Bitmap(ブロックACKビットマップ)112として作成する。すなわち、図11の例では、1が正常受信、0が受信失敗として、1011011のようなビットマップ構成で表される。ここで、正論理と負論理を入れ替えて使用しても良いことは言うまでもない。そして、PSDU内にアグリゲートされた最後のMPDUが正常に受信できていた場合、データ送信端末に対し、その時点で作成したBlock ACK Bitmap112を用いて、図12に示すような圧縮ブロックACK113を作成する。
With reference to FIG. 11 thru | or FIG. 13, the basic concept which concerns on embodiment of this invention is demonstrated. Here, it is assumed that the transmitting terminal transmits MPDUs having sequence numbers “1” to “7” assigned continuously. The transmitting terminal aggregates a plurality of MPDUs (QoS data) into one PSDU by one of the methods shown in FIG. 9 or FIG. 10, and aggregates a
1つのPSDU内にアグリゲート可能な最大数に対し、アグリゲートされていたMPDUの数が少ない場合、Block ACK Bitmap112には0を入れてパディングする。図11の例でアグリゲート可能な最大数を64MPDUとすると、10110110000...で示されるビットマップ構成となる。もしくは、受信端末側で、PSDU内にアグリゲートされていたMPDUの個数に応じて、Block ACK Bitmap112のビットマップ長を可変にしても良い。可変にした場合、図8のブロックACKのBAコントロールフィールドにビットマップ長を示す情報を追加しても良い。圧縮ブロックACK113のBlock ACK Starting Sequence Controlの値は、ブロックACK要求111の値をコピーする。図12において、ブロックACKを受信したデータ送信端末は、圧縮ブロックACK113のBlock ACK Starting Sequence Controlの示す値と、自身の送信したMPDUのシーケンス番号とを対比し、Block ACK Bitmap112の情報から、正常に送信できたMPDUを検出し、再送の必要のあるMPDUを決定する。図12の例では、シーケンス番号「2」と「5」の部分のBlock ACK Bitmap112が0になっているため、この2つのフレームが再送の必要なMPDUであると判断する。
When the number of aggregated MPDUs is smaller than the maximum number that can be aggregated in one PSDU, the
再送すべきMPDUを決定した後、受信端末側のバッファ容量の許す範囲内であれば、新規にMACフレーム120をメインキューから取り出し、シーケンス番号の割り当てとPSDUへのアグリゲーションを行なう。この時、サブキュー内のMPDUはキューの先頭から連続的に送信成功したものを削除することができる。新規に追加するMPDU120の個数等は、例えばスライディングウィンドウ制御と呼ばれる技術を用いて実現される。再送分121を含めた複数MPDUをアグリゲートしたPSDUの末尾には、それらに対するブロックACK要求122をアグリゲートする。
After determining the MPDU to be retransmitted, if it is within the range allowed by the buffer capacity on the receiving terminal side, a
図13は、以上の内容を踏まえた基本的なシーケンス例を示している。端末が与えられたTXOP期間内で、複数のQoSデータを1つの物理フレームにアグリゲートし、PSDUの末尾にブロックACK要求をアグリゲートすることで、受信側に対し、即時的なブロックACKの送信を促す。データ受信側では、PSDU内の複数MPDUの受信ステータスをブロックACK要求の部分を除いて計算し、その情報をそのままBlock ACK Bitmapに対応付けて圧縮ブロックACKを返信する。具体的には、例えばTXOP期間1において、QSTA1は複数のQoSデータを1つのPSDU130にアグリゲートし、該PSDU130の末尾にブロックACK要求131をアグリゲートすることで、受信側に対し、即時的なブロックACKの送信を促す。データ受信側のQSTA2は、PSDU130内の複数MPDUの受信ステータスをブロックACK要求131の部分を除いて計算し、その情報をそのままBlock ACK Bitmapに対応付けて圧縮ブロックACK132を返信する。
FIG. 13 shows a basic sequence example based on the above contents. Within a given TXOP period, multiple QoS data are aggregated into one physical frame, and a block ACK request is aggregated at the end of the PSDU. Prompt. On the data receiving side, the reception status of a plurality of MPDUs in the PSDU is calculated excluding the block ACK request portion, and the information is directly associated with the Block ACK Bitmap and a compressed block ACK is returned. Specifically, for example, in
従来方式とは異なり、過去の受信履歴をブロックACK要求のBlock ACK Starting Sequence Controlに基づいて検索するようなことはないため、比較的負荷の大きい検索処理を削減し、SIFSという限られた期間で部分応答を返すことがより容易となる。また、一般に検索時間と回路規模はトレードオフの関係にあるため、許容される最大処理遅延が同じ場合に、回路規模を削減することが出来るという言い方も出来る。 Unlike the conventional method, since the past reception history is not searched based on the Block ACK Starting Sequence Control of the block ACK request, the search processing with a relatively large load is reduced, and SIFS is limited in a limited period of time. It becomes easier to return partial responses. In general, since the search time and the circuit scale are in a trade-off relationship, it can be said that the circuit scale can be reduced when the allowable maximum processing delay is the same.
次に、受信に誤りが生じた際の再送制御例について説明する。 Next, an example of retransmission control when an error occurs in reception will be described.
まず、図14乃至図16を参照して、再送制御例1を説明する。本例では、データ送信端末がシーケンス番号「1」〜「7」のMPDUを1つのPSDUにアグリゲートし、PSDUの末尾にブロックACK要求をアグリゲートして送信した状況を想定する。図14の例のように、ブロックACK要求の部分140がFCS計算の結果誤りであると、受信端末は圧縮ブロックACKを返信することができない。そこで本発明の実施形態では、複数のMPDUがアグリゲートされたPSDUを受信した端末は、たとえ圧縮ブロックACKを返信できないとしても、その時点での複数MPDUの受信ステータスを1回分のBlock ACK Bitmapとして記憶しておくものとする。図14の例では、1011011というビットマップ情報141が受信側で記憶される。また受信側では、当該端末が最後に正常受信したMPDUのシーケンス番号を併せて記憶する。図14では、シーケンス番号「7」のMPDUがこれに該当する。1回分の圧縮ブロックACK用のビットマップ情報141と最後に受信したMPDUのシーケンス番号は、データ送信端末、優先度毎に記憶しておくことが望ましい。
First, retransmission control example 1 will be described with reference to FIGS. 14 to 16. In this example, it is assumed that the data transmission terminal aggregates MPDUs with sequence numbers “1” to “7” into one PSDU and aggregates and transmits a block ACK request at the end of the PSDU. As shown in the example of FIG. 14, if the block
複数MPDUをアグリゲートしたPSDUを送信した後、一定時間経過しても宛先からの圧縮ブロックACKが受信できなかった場合、送信端末は、アグリゲートした複数MPDUのうち、先頭のMPDUのシーケンス番号をBlock ACK Starting Sequence Controlの値として、ブロックACK要求を再送する。通常は直前のPSDUにアグリゲートしたブロックACK要求をそのまま再送すればよい。但し第二の実施形態のようにブロックACK要求を省略して直前のPSDUにアグリゲートしなかった場合には、このようにブロックACK要求を新たに構成する必要がある。図14の場合、Block ACK Starting Sequence Controlには、前回送信した「1」〜「7」のシーケンス番号を持つMPDUのうち、先頭のMPDUである「1」を記載する。また、このブロックACK要求142は、基本的に他のフレームとアグリゲートを行なわないものとする。他のMPDUがアグリゲートされていないブロックACK要求142を受信した端末は、ブロックACK要求142内のBlock ACK Starting Sequence Controlの値と当該端末が最後に正常受信したMPDUのシーケンス番号を比較する。Block ACK Starting Sequence Controlの値が、最後に受信したMPDUのシーケンス番号と同等であるか、それより古い(前の)番号であれば、1回分の圧縮ブロックACK送信用として保持しておいた、ビットマップ情報141をBlock ACK Bitmapの情報としてそのまま利用し、SIFS期間の後、図15に示すように圧縮ブロックACK150で反射的に応答する。図15の例では、前回受信したPSDU内の複数MPDUの受信ステータス1011011をそのままBlock ACK Bitmapとして、送信端末に圧縮ブロックACK150を返信する。圧縮ブロックACK150のBlock ACK Starting Sequence Controlの値は、ブロックACK要求142のBlock ACK Starting Sequence Controlの値をコピーする。
ビットマップ情報141を作成したときに前提としたBlock ACK Starting Sequence Controlと、ブロックACK要求142のBlock ACK Starting Sequnece Controlが異なる場合もある。これは、例えばアグリゲートされた先頭MPDUが壊れ、かつブロックACK要求も壊れており、受信側が正常に受信できた最初のMPDUのシーケンス番号を先頭と仮定して、ビットマップ情報141を作成したような場合に生じる。ビットマップ情報141の始点のシーケンス番号が後者と矛盾しなくなるようにビットマップ情報141を変換する。あるいは、ビットマップ情報141はそのままにして、応答するブロックACKのBlock ACK Starting Sequence Controlをビットマップ情報141を作成したときに前提とした値(つまりブロックACK要求とは異なる値)に設定する。なお、受信側はビットマップ情報141を生成した際に仮定した先頭のシーケンス番号を記憶しておいても良い。記憶していない場合でも、例えば最後に正常受信したMPDUのシーケンス番号とビットマップ情報141があれば、先頭のシーケンス番号は逆算できる。
If a compressed block ACK is not received from a destination after a PSDU that has aggregated multiple MPDUs and a certain period of time has passed, the transmitting terminal uses the sequence number of the first MPDU among the aggregated MPDUs. The block ACK request is retransmitted as the value of Block ACK Starting Sequence Control. Normally, the block ACK request aggregated to the immediately preceding PSDU may be retransmitted as it is. However, when the block ACK request is omitted and the previous PSDU is not aggregated as in the second embodiment, it is necessary to newly configure the block ACK request in this way. In the case of FIG. 14, Block ACK Starting Sequence Control describes “1” that is the first MPDU among the MPDUs having the sequence numbers “1” to “7” transmitted last time. This
There is a case where the Block ACK Starting Sequence Control assumed when the
図16は、以上の制御例に係り、ブロックACK要求を再送した際のシーケンス例を示している。HCがQSTA1にQoS CF-Pollを送信してTXOP期間1を与える。図16において、QSTA1は、TXOP期間の範囲内で、複数のQoSデータフレームと1つのブロックACK要求を1つの物理フレーム160にアグリゲートしてQSTA2に送信するが、ブロックACK要求部分161に誤りが生じ、圧縮ブロックACKが受信できないことが示されている。その後、QSTA2のTXOP期間2が終了して、HCが再びQSTA1にTXOP期間3を付与した際、QSTA1はブロックACK要求162を再送し、QSTA2からの圧縮ブロックACK163を受信することで一連のフレームシーケンスを終了する。
FIG. 16 shows a sequence example when a block ACK request is retransmitted in the above control example. HC sends QoS CF-Poll to QSTA1 and gives
次に、図17乃至図19を参照して再送制御例2を説明する。図17のように、送信端末が、シーケンス番号「1」〜「7」のMPDUと、ブロックACK要求を1つのPSDUにアグリゲートして送信したとする。受信側で、シーケンス番号「2」、「5」、ブロックACK要求の誤り検査の結果、これらを正常に受信できなかったことが判明した場合、その時点で受信したPSDU内の複数MPDUの受信ステータスをビットマップ情報として保持(図17の例で、ビットマップは1011011となる)し、併せて最後に受信したMPDUのシーケンス番号 (図17の例で、シーケンス番号「7」)を記憶する点は前述と同様である。
図17の例において、データ受信端末は圧縮ブロックACKを応答することはできない。そこで送信端末は、一定時間経過しても圧縮ブロックACKを受信できないならば、ブロックACK要求を再送する。前述のように、ブロックACK要求のBlock ACK Starting Sequence Controlの値は、アグリゲートした先頭のMPDUのシーケンス番号(図17の例では「1」)を記載する。ここで、ブロックACK要求を送信しても、圧縮ブロックACKが返答されてこない場合、当該データの再送を諦めることになる。IEEE802.11e Draft 8.0によれば、QoSデータには、優先度に応じて遅延限界(Delay Bound)が定められ、ネゴシエーションを通じて、この値を送受信端末間で相互に認識し合う。Delay Boundを超過したMACフレームはQoS品質を満たせなかったとして、送信端末(あるいは受信端末)で廃棄される。図17の例で、送信端末がアグリゲートして送信したシーケンス番号「1」〜「7」のMACフレームが全てDelay Boundを超過して廃棄されると、次の送信シーケンスとして、新しいフレームがアグリゲートされることになる。
図18の例では、新しいデータフレームとして、シーケンス番号「8」〜「14」のMPDU180とブロックACK要求181とを1つのPSDUにアグリゲートして送信している。PSDUの末尾にアグリゲートされたブロックACK要求181のBlock ACK Starting Sequence Controlの値は、先頭MPDUのシーケンス番号「8」を記載する。この複数MPDU(シーケンス番号「8」〜「14」)180とブロックACK要求181をアグリゲートしたPSDUが、衝突などの理由で全て誤りとなった場合、受信端末側では、受信ステータスの更新を一切行なっていない状態のままである。送信端末は、圧縮ブロックACKが一定時間経過しても受信できないと、Block ACK Starting Sequence Controlが「8」のブロックACK要求181を再送する。受信端末は、再送されたブロックACK要求181を受け取ると、該フレーム181のBlock ACK Starting Sequence Controlの値は「8」であり、自身が正常に受信した最後のMPDUのシーケンス番号「7」よりも大きい値であることが分かる。図18の例において、圧縮ブロックACK1回分のビットマップ情報は、シーケンス番号「1」〜「7」のMPDUに対するものであるため、Block ACK Starting Sequence Controlが示す先の受信ステータスは一切記録していない状況である。ここで、図19に示すように、それまで記憶しておいたシーケンス番号「1」〜「7」のMPDUの受信ステータス(図18の例では、1011011)を0でクリアし、Block ACK Bitmap190を全て0にした状態の圧縮ブロックACK190を送信する。つまり、Block ACK Bitmap190は、正常受信されたMACフレームが無いことを示す。
Next, retransmission control example 2 will be described with reference to FIGS. As shown in FIG. 17, it is assumed that the transmitting terminal aggregates and transmits MPDUs with sequence numbers “1” to “7” and a block ACK request to one PSDU. When the receiving side finds that the sequence number “2”, “5”, and block ACK request error check result indicate that these could not be received normally, the reception status of multiple MPDUs in the PSDU received at that time Is stored as bitmap information (in the example of FIG. 17, the bitmap is 1011011) and the sequence number of the last received MPDU (sequence number “7” in the example of FIG. 17) is also stored. Same as above.
In the example of FIG. 17, the data receiving terminal cannot respond with the compressed block ACK. Therefore, if the transmitting terminal cannot receive the compressed block ACK even after a predetermined time has elapsed, it retransmits the block ACK request. As described above, the Block ACK Starting Sequence Control value of the block ACK request describes the sequence number (“1” in the example of FIG. 17) of the head MPDU that has been aggregated. Here, even if the block ACK request is transmitted, if the compressed block ACK is not returned, the retransmission of the data is given up. According to IEEE802.11e Draft 8.0, a delay limit (Delay Bound) is defined in QoS data according to priority, and this value is mutually recognized between transmitting and receiving terminals through negotiation. A MAC frame exceeding the Delay Bound is discarded at the transmitting terminal (or receiving terminal), assuming that the QoS quality cannot be satisfied. In the example of FIG. 17, when all MAC frames with sequence numbers “1” to “7” that are aggregated and transmitted by the transmitting terminal exceed the Delay Bound and are discarded, a new frame is aggregated as the next transmission sequence. Will be gated.
In the example of FIG. 18,
シーケンス番号「8」〜「14」の複数MPDUをアグリゲートして送信した端末は、図19において、宛先端末からの圧縮ブロックACK191を受信し、かつそのBlock ACK Bitmap190が全て0の場合、シーケンス番号「8」〜「14」の全てのMPDU192を再送対象とする。図19の例では、シーケンス番号「8」〜「14」の再送対象のMPDU192とブロックACK要求(Block ACK Starting Sequence Controlは「8」)193を1つのPSDUにアグリゲートして送信する様子を示している。受信端末では、PSDU内に複数個アグリゲートされたMPDU192のうち、ブロックACK要求193を除いて、どれか1つでも正常に受信できれば、受信ステータスのビットマップと最後に正常受信したMPDUのシーケンス番号を更新する。
A terminal that has aggregated and transmitted a plurality of MPDUs having sequence numbers “8” to “14” receives the
以上説明した本発明の第一の実施形態によれば、MSDUのフラグメント化を行わない前提において、ブロックACKに含まれるビットマップ情報を削減し、MAC効率を向上することが出来る。この実施形態では、ブロックACK要求を受信してからSIFS期間後にブロックACKを応答する即時型ブロックACKを実現する例を示した具体的には、複数MPDUがアグリゲートされ、かつ該複数MPDUの末尾にブロックACK要求がアグリゲートされたPSDUを受信した場合、受信ステータスを反射的に即時型ブロックACKとして応答することができる。しかし、フラグメントが無い前提でビットマップ情報を圧縮することは、遅延型ブロックACKの場合にも同様に適用可能である。 According to the first embodiment of the present invention described above, it is possible to reduce the bitmap information included in the block ACK and improve the MAC efficiency on the assumption that the MSDU is not fragmented. In this embodiment, an example of realizing an immediate block ACK that responds with a block ACK after a SIFS period after receiving a block ACK request is shown. Specifically, a plurality of MPDUs are aggregated and the end of the plurality of MPDUs When a PSDU in which a block ACK request is aggregated is received, the reception status can be reflected back as an immediate block ACK. However, compressing the bitmap information on the assumption that there is no fragment can be similarly applied to the case of the delayed block ACK.
また、本実施形態では1つのPSDUに1つのブロックACK要求、1つのブロックACKが含まれる例を示したが、1つのPSDUに複数のブロックACK要求、複数のブロックACKを含むように拡張することも出来る。例えば同じ宛先だが、TIDの異なる複数のMPDUを1つのPSDUにアグリゲートする際に、そのPSDUに含まれるTIDそれぞれに対し、ブロックACK要求を対応付けても良い。一部のTIDが即時にACKを必要としない場合、あるいは全くACKを必要としない場合には、TIDの数はブロックACK要求の数よりも多くても良い。また、これに応答するブロックACKもブロックACK要求毎に生成され送信される。応答するブロックACKは1つのPSDUにアグリゲートするのが自然だが、個別のPSDUとして送信することも可能である。また、複数宛先のMPDUを1つのPSDUにアグリゲートする際に、そのPSDUに含まれる宛先それぞれに対し、ブロックACK要求を対応付けても良い。これに対する応答のブロックACKは、宛先に対応する各受信側装置から個別に送信される。各受信側装置が送信するブロックACKの応答は、互いにぶつからないようにスケジュールされるものとする。複数TIDと複数宛先を組み合わせることも可能である。 Also, in this embodiment, an example in which one block ACK request and one block ACK are included in one PSDU has been shown, but it is extended to include a plurality of block ACK requests and a plurality of block ACKs in one PSDU. You can also. For example, when a plurality of MPDUs having the same destination but different TIDs are aggregated into one PSDU, a block ACK request may be associated with each TID included in the PSDU. If some TIDs do not require an ACK immediately or no ACK at all, the number of TIDs may be greater than the number of block ACK requests. A block ACK in response to this is also generated and transmitted for each block ACK request. The responding block ACK is naturally aggregated into one PSDU, but can be transmitted as an individual PSDU. Further, when a plurality of destination MPDUs are aggregated to one PSDU, a block ACK request may be associated with each destination included in the PSDU. The response block ACK is individually transmitted from each receiving side apparatus corresponding to the destination. It is assumed that the response of the block ACK transmitted by each receiving side apparatus is scheduled so as not to collide with each other. It is also possible to combine multiple TIDs and multiple destinations.
また、HCによってスケジュール制御されない、通常のCSMA/CAの場合にも同様に適用される。 The same applies to normal CSMA / CA that is not scheduled by HC.
(第二の実施形態)
本発明の第一の実施形態においては、複数のMPDUを1つのPSDUにアグリゲートした際、PSDUの末尾にブロックACK要求を必ずアグリゲートしていた。この場合、該PSDUを受信した端末が、アグリゲートされた複数MPDUの誤り検査を行い、その中にブロックACK要求の存在を確認すれば、圧縮ブロックACKを反射的に返信する方法である。これに対し本発明の第二の実施形態は、複数のMPDUをアグリゲートした際、PSDU内の末尾にブロックACK要求をアグリゲートしない状態で物理フレームを送信するというものである。
図20及び図21に本発明の第二の実施形態における、複数MPDUをアグリゲートしたPSDUのフレーム構成例を示す。図20では、複数のMPDUの先頭に、MPDUの長さを示す情報(MPDU長)201、及び長さ情報に対するCRC202が付加される。MPDU長201とCRC202を併せて、第一の実施形態と同様に、「MPDUセパレーション」203と呼ぶ。図20から分かるように、第二の実施形態では、複数のMPDUがアグリゲートされたPSDUの末尾にブロックACK要求は存在しない。各MPDUは、MPDUセパレーション203のCRC計算が正しく、かつMPDU長201で示されるMPDUのFCSの計算結果が正常であれば、受信成功したとみなす。図21は、複数のMPDUの長さ情報をアグリゲートしたMPDU群の先頭にヘッダーとして付加するもので、このヘッダーを第一の実施形態と同様に「MACスーパーフレームヘッダー」210と呼ぶ。MACスーパーフレームヘッダー210には、ヘッダーのCRC211が付属する。MACスーパーフレームヘッダー210のCRC計算の結果が誤りであれば、全てのMPDUを誤りであるとみなす。尚、MPDU長情報は、MACヘッダーからFCSまでの長さをバイト単位で指定する。第二の実施形態では、図20及び図21のように、物理(PHY)ヘッダー(図20の200,図21の212)及び物理(PHY)トレーラ(図20の204,図21の213)に挟まれたPSDU内に複数のMPDUがアグリゲートされている物理フレームを受信した端末は、その時点での受信ステータスを圧縮ブロックACKとして反射的に応答する。
(Second embodiment)
In the first embodiment of the present invention, when a plurality of MPDUs are aggregated into one PSDU, the block ACK request is always aggregated at the end of the PSDU. In this case, when the terminal that has received the PSDU performs an error check on the aggregated MPDUs and confirms the presence of a block ACK request therein, the compressed block ACK is reflected back. In contrast, in the second embodiment of the present invention, when a plurality of MPDUs are aggregated, a physical frame is transmitted without a block ACK request being aggregated at the end of the PSDU.
FIG. 20 and FIG. 21 show PSDU frame configuration examples in which multiple MPDUs are aggregated in the second embodiment of the present invention. In FIG. 20, information (MPDU length) 201 indicating the length of the MPDU and a
図22乃至図24を参照して、本発明の第二の実施形態における基本的な送受信シーケンスを示す。図22において、送信端末は、連続的に割り当てられたシーケンス番号「1」〜「8」のMPDUを1つのPSDUにアグリゲートして送信する。上述した第一の実施形態と同様に、送信端末は再送用のサブキューを有し、図22のシーケンス番号「1」〜「8」のMPDUのコピーを該サブキュー内に格納する。図22の例において、複数MPDUがアグリゲートされたPSDUを受信した受信端末は、各MPDUの受信ステータスを計算してBlock ACK Bitmap220に変換し、圧縮ブロックACKを反射的に送信する。第一の実施形態とは異なり、ブロックACK要求はアグリゲートされていないため、PSDU内のMPDUをどれか1つでも正常に受信できれば、そのPSDUが終了した時点で圧縮ブロックACKを応答する。図22の例では、シーケンス番号「2」、「5」、「7」のMPDUがFCS計算の結果、誤りであった場合を示している。受信端末は、当該PSDU内で正常に受信できた先頭のMPDUのシーケンス番号を、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値とする。Block ACK Bitmap220は、最初に受信できたMPDUからの相対的な位置関係から作成される。図22において、受信ステータスのビットマップ構成は、10110101のように示すことができる。また圧縮ブロックACKのBlock ACK Starting Sequence Controlは「1」である。上述した第一の実施形態と同様に、1つのPSDU内にアグリゲート可能なMPDUの最大個数に満たない場合は、ビットマップフィールドの後半を0でパディング等を行なう。もしくは、受信端末側で、PSDU内にアグリゲートされていたMPDUの個数に応じて、Block ACK Bitmap220のビットマップ長を可変にしても良い。図23において、データ送信端末は、宛先からの圧縮ブロックACK230を受信した際、まず該フレーム230のBlock ACK Starting Sequence Controlを確認する。図23の例では、送信端末が送信した先頭のMPDUのシーケンス番号「1」と等しいため、圧縮ブロックACK230のBlock ACK Bitmap231から、当該端末が送信したMPDUの送信状況を判断する。図23のBlock ACK Bitmap231は、10110101に示される構成となっており、その結果、送信端末はシーケンス番号「2」、「5」、「7」のMPDUが正しく送信できなかったことを検出する。そこで、シーケンス番号「2」、「5」、「7」のMPDUは再送の対象とし、再送時に再びアグリゲートされ、本発明の第一の実施形態と同じように、受信側のバッファ容量が許す範囲内で、新しいフレーム232を一緒にアグリゲートして送信する。再送フレーム233を含めて、複数MPDUをアグリゲートしたPSDUを送信する際も、末尾にブロックACK要求をアグリゲートすることはしない。
図24に示すように、HCからTXOP期間1を与えられたQSTA1は、QSTA2に対し、複数のQoSデータがアグリゲートされた物理フレーム240を送信し、該フレーム240を受信したQSTA2は、SIFS期間の後、圧縮ブロックACK241を応答する。HCからQSTA1に対するダウンリンク伝送も同様の手続きで行なわれる。すなわち、HCのTXOP期間2において、QSTA1に対し複数のQoSデータがアグリゲートされた物理フレーム242を送信し、QSTA1から圧縮ブロックACK243を受信することで一連の送信シーケンスを完了する。
A basic transmission / reception sequence according to the second embodiment of the present invention will be described with reference to FIGS. In FIG. 22, the transmitting terminal aggregates and continuously transmits MPDUs having sequence numbers “1” to “8” assigned to one PSDU. Similar to the first embodiment described above, the transmitting terminal has a subqueue for retransmission, and stores copies of MPDUs with sequence numbers “1” to “8” in FIG. 22 in the subqueue. In the example of FIG. 22, the receiving terminal that has received the PSDU in which a plurality of MPDUs are aggregated calculates the reception status of each MPDU, converts it to Block
As shown in FIG. 24, QSTA1 given the
本発明の第二の実施形態によれば、ブロックACK要求はPSDU内にアグリゲートしないことから、MAC効率を向上できる。また、受信側でのブロックACK要求フレームを受信する処理負担の軽減を実現することも可能である。 According to the second embodiment of the present invention, since the block ACK request is not aggregated in the PSDU, the MAC efficiency can be improved. It is also possible to reduce the processing load of receiving a block ACK request frame on the receiving side.
次に、図25及び図26を参照して、複数MPDUをアグリゲートしたPSDUの先頭から連続的にフレーム誤りが生じた場合の再送制御例を説明する。図25のように、シーケンス番号「1」〜「8」のMPDUをアグリゲートして送信し、受信端末側でシーケンス番号「1」、「2」、「5」、「7」のMPDUがFCS計算の結果、誤りであったとする。第一の実施形態とは異なり、第二の実施形態ではブロックACK要求はPSDU内にアグリゲートされないため、PSDUの先頭がどのシーケンス番号であるかを判断することはできない。特に、図20のように、複数MPDUの先頭にMPDUセパレーションフィールドを付加している場合、当該PSDU内に幾つのMPDUがアグリゲートされているかも分からないため、Block ACK Starting Sequence Controlを推測することもできない。そこで、本発明の第二の実施形態において、複数のMPDUをアグリゲートしたPSDUを受信した端末は、該PSDUの中で、正常に受信した最初のMPDUのシーケンス番号を、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値とし、該MPDUからの相対的な位置関係から、受信ステータスのビットマップを構成する。すなわち、図25に示すように、データ受信端末側で正常に受信することのできた最初のMPDUは、シーケンス番号「3」のフレームであるため、圧縮ブロックACKのBlock ACK Starting Sequence Controlを「3」とする。さらに、PSDU内のシーケンス番号「3」のMPDUからの相対的な位置関係から、Block ACK Bitmap250を作成することになるが、図25の例では、110101のようなビットマップを作成する。既に論じてきたように、1つのPSDU内にアグリゲート可能なMPDUの最大数に満たない場合、ビットマップの後半部分251は0でパディングする。もしくは、受信端末側で、PSDU内にアグリゲートされていたMPDUの個数に応じて、Block ACK Bitmap250のビットマップ長を可変にしても良い。複数のMPDUをアグリゲートして送信した後、圧縮ブロックACK252を受信すれば、当該端末の送信したMPDUのシーケンス番号とBlock ACK Starting Sequence Controlを比較する。
図26の例のように、シーケンス番号「1」〜「8」のMPDUを送信しており、宛先端末からの圧縮ブロックACK252のBlock ACK Starting Sequence Controlの値が「3」である場合、Block ACK Starting Sequence Controlよりも前のシーケンス番号を持つMPDUは、全て誤りとみなす。すなわち、シーケンス番号「1」、「2」のMPDUは誤りだと判断する。またBlock ACK Starting Sequence Controlの値「3」を始点として、ビットマップの相対的な位置関係から、同じくシーケンス番号「5」、「7」のMPDUに誤りが生じていると判断する。送信端末は、このような圧縮ブロックACK252の受信によって、再送の必要が生じているMPDU260をアグリゲートし、もし受信側のバッファ容量に余裕があるならば、新たにフレームをアグリゲートして送信する。
Next, with reference to FIG. 25 and FIG. 26, a description will be given of an example of retransmission control in the case where frame errors continuously occur from the top of the PSDU in which multiple MPDUs are aggregated. As shown in FIG. 25, MPDUs with sequence numbers “1” to “8” are aggregated and transmitted, and MPDUs with sequence numbers “1”, “2”, “5”, and “7” are FCS on the receiving terminal side. Assume that the result of the calculation is an error. Unlike the first embodiment, since the block ACK request is not aggregated in the PSDU in the second embodiment, it is not possible to determine which sequence number is the head of the PSDU. In particular, as shown in FIG. 20, when an MPDU separation field is added to the head of a plurality of MPDUs, it is not known how many MPDUs are aggregated in the PSDU, and therefore Block ACK Starting Sequence Control is estimated. I can't. Therefore, in the second embodiment of the present invention, a terminal that has received a PSDU obtained by aggregating a plurality of MPDUs uses the block ACK of the compressed block ACK as the sequence number of the first MPDU that has been normally received in the PSDU. A reception status bitmap is constructed from the value of Starting Sequence Control and the relative positional relationship from the MPDU. That is, as shown in FIG. 25, since the first MPDU successfully received on the data receiving terminal side is a frame of sequence number “3”, Block ACK Starting Sequence Control of the compressed block ACK is set to “3”. And Furthermore, the
As in the example of FIG. 26, when MPDUs having sequence numbers “1” to “8” are transmitted and the value of Block ACK Starting Sequence Control of the
図27を参照し、送信端末がブロックACK要求を再送する場合を説明する。第一の実施形態でも述べたように、宛先からの圧縮ブロックACKが受信されない場合、送信端末はブロックACK要求を再送する。本発明の第二の実施形態において、QoSデータを1つの物理アグリゲートする場合は、末尾にブロックACK要求を含むことはないため、データ送信端末からブロックACK要求を送信するのは、圧縮ブロックACKが受信できなかった場合のみである。図27の例では、シーケンス番号「1」、「2」、「5」、「7」のMPDUを再送分260としてアグリゲートして送信する。この時、ブロックACK要求270のBlock ACK Starting Sequence Controlは、前回送信したPSDUの先頭MPDUのシーケンス番号の値をコピーする。図27において、ブロックACK要求270のBlock ACK Starting Sequence Controlは「1」である。ブロックACK要求270を受信した端末は、前回最後に受信したPSDU内の複数MPDUの受信ステータスを圧縮ブロックACKの1回分として記憶しており、該受信端末が最後に正常に受信したMPDUのシーケンス番号よりも、ブロックACK要求270のBlock ACK Starting Sequence Controlの値が小さいならば、記憶しておいたビットマップ情報をそのままBlock ACK Bitmapに変換し、反射的に圧縮ブロックACKを応答する。この時、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値は、ブロックACK要求からコピーするのではなく、前回受信したPSDUの中で、正常に受信できた先頭MPDUのシーケンス番号を記載する。なぜなら、ブロックACK要求の示すBlock ACK Starting Sequence Controlに対応するMPDUを必ずしも正常に受信しているわけではないためである。ないしは、ブロックACK要求からBlock ACK Starting Sequnce Controlをコピーし、記憶していたビットマップ情報の先頭のシーケンス番号より古い部分は正常に受信できなかったという内容にビットマップ情報を変換しても良い。
With reference to FIG. 27, a case where the transmitting terminal retransmits the block ACK request will be described. As described in the first embodiment, when the compressed block ACK from the destination is not received, the transmitting terminal retransmits the block ACK request. In the second embodiment of the present invention, when one piece of QoS data is aggregated, a block ACK request is not included at the end. This is only the case when the message cannot be received. In the example of FIG. 27, MPDUs with sequence numbers “1”, “2”, “5”, and “7” are aggregated as
図28に、本発明の第二の実施形態の再送処理を含めた基本的なフレーム交換シーケンスを示す。ここでデータ送信端末は、シーケンス番号「1」〜「8」のMPDUを1つのPSDU280にアグリゲートして送信する。受信側でPSDU280を受信した時、シーケンス番号「1」、「2」、「5」、「7」のMPDUが誤りであった場合、11010100のようなビットマップ構成で圧縮ブロックACK281を送信する。送信側では、圧縮ブロックACK281の内容から、シーケンス番号「1」、「2」、「5」、「7」のMPDUが正常に送信できなかったことを判断し、当該再送対象の複数のMPDUをアグリゲートしてPSDU282を再送する。この再送されたPSDU282が衝突などの理由により、受信側で全く受信できない場合、一定時間後に、送信端末はBlock ACK Starting Sequence Controlを「1」としてブロックACK要求283を再送する。ブロックACK要求283を受信した端末は、Block ACK Starting Sequence Controlの値が「1」であるが、該受信端末の前回受信したPSDU内の複数MPDUの中で、先頭のシーケンス番号は「3」であるため、圧縮ブロックACK284のBlock ACK Starting Sequence Controlの値を「3」として、記憶しておいた受信ステータスのビットマップをBlock ACK Bitmapとして応答する。送信端末が圧縮ブロックACK284を受け取ると、前回送信したMPDU282の中で、圧縮ブロックACK284のBlock ACK Starting Sequence Controlよりも前のシーケンス番号を持つMPDUを全て誤りだとみなし、かつビットマップの相対的な位置関係からも誤ったMPDUを検出する。すなわち、図28の例では、再送されたMPDU282が全て誤っているため、結果として、シーケンス番号「1」、「2」、「5」、「7」の全てのMPDUを再送対象とし、これらがアグリゲートされたMPDU285を再送する。その後、宛先から圧縮ブロックACK286を受信することで、一連のフレーム交換シーケンスを終了したとみなす。
FIG. 28 shows a basic frame exchange sequence including a retransmission process according to the second embodiment of the present invention. Here, the data transmission terminal aggregates and transmits MPDUs having sequence numbers “1” to “8” to one
図29は、再送を含めたデータ送信端末でのバッファ管理を示したものである。様々な宛先、優先度のMACフレームを含むメインキューからMACフレームを取り出し、「1」〜「8」の連続的なシーケンス番号を割り当てて、再送用のサブキュー290に格納する。そして、シーケンス番号「1」〜「8」のMPDUのコピーを取り出し、1つのPSDUにアグリゲートして送信した後、当該送信端末が送信したMPDUのシーケンス番号を記憶しておく。図29の例では、「1」、「2」、「3」、「4」、「5」、「6」、「7」、「8」という情報が送信側で記憶される。宛先端末から、Block ACK Starting Sequence Control「3」の圧縮ブロックACK291を受信した場合、それよりも前のシーケンス番号「1」、「2」のMPDUは双方とも誤りとみなす。併せて、Block ACK Bitmapの相対的な位置関係から、シーケンス番号「5」、「7」のMPDUも誤りとみなす。再送用のサブキュー290からは、その先頭から連続的に送信成功していれば、MPDUを前方から削除していくことができる。図29の例では、シーケンス番号「1」のMPDUが誤っていると判断されているため、サブキューからフレームを1つも削除することはできない。ここで、サブキュー290内の送信成功したMACフレームに対しては、送信成功したことを示す何かしらの識別情報を与えて、そのままサブキュー内に格納しておくことが望ましい。これは、次のシーケンスで、圧縮ブロックACKを受信した際、ビットマップの相対的な位置関係から、送信成功したMPDU、正常に送信できなかったMPDUを区別することが困難になること等が挙げられるからである。ここで送信に成功したMPDUの実体は必ずしも格納しておく必要は無い。シーケンス番号毎の状態が重要である。その後、送信端末がシーケンス番号「1」、「2」、「5」、「7」のMPDUを再送して、シーケンス番号「7」のMPDUを除いて、受信側で全て正常に受信できたとすると、Block ACK Starting Sequence Control「1」の圧縮ブロックACK292が応答される。送信端末はシーケンス番号「1」、「2」、「5」のMPDUを正常に送信したことを判断するため、サブキュー290の先頭から連続的に、シーケンス番号「6」のMPDUまで削除していく。結果、サブキュー290の先頭には、シーケンス番号「7」のMPDUが格納されていることになる。
FIG. 29 shows buffer management at a data transmission terminal including retransmission. A MAC frame is extracted from a main queue including MAC frames having various destinations and priorities, and consecutive sequence numbers “1” to “8” are assigned and stored in a sub-queue 290 for retransmission. Then, a copy of the MPDU with sequence numbers “1” to “8” is taken out, aggregated into one PSDU and transmitted, and then the sequence number of the MPDU transmitted by the transmitting terminal is stored. In the example of FIG. 29, information “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8” is stored on the transmission side. When a compressed block ACK 291 with Block ACK Starting Sequence Control “3” is received from the destination terminal, both MPDUs with sequence numbers “1” and “2” before that are regarded as errors. At the same time, MPDUs with sequence numbers “5” and “7” are also regarded as errors from the relative positional relationship of the Block ACK Bitmap. From the
以上説明した本発明の第二の実施形態によって、ブロックACK要求をPSDUから削除できるため、MAC効率が向上する。また、MSDUのフラグメント化を行わない前提において、ブロックACKに含まれるビットマップ情報を削減し、MAC効率を向上することが出来る。更に、ブロックACK要求を受信してからSIFS期間後にブロックACKを応答する即時型ブロックACKを実現できる。ブロックACK要求をPSDUから削除してMAC効率を向上する方法は、遅延型ブロックACKの場合にも適用できる。 Since the block ACK request can be deleted from the PSDU according to the second embodiment of the present invention described above, the MAC efficiency is improved. Also, on the premise that MSDU fragmentation is not performed, the bitmap information included in the block ACK can be reduced, and the MAC efficiency can be improved. Furthermore, an immediate block ACK that responds with a block ACK after the SIFS period after receiving the block ACK request can be realized. The method of improving the MAC efficiency by deleting the block ACK request from PSDU can also be applied to the case of delayed block ACK.
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。 Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements over different embodiments may be appropriately combined.
100…通信装置;
101…物理層(PHY);
102…MAC(媒体アクセス制御)層;
103…リンク層;
104…アンテナ;
105…アグリゲーション処理部;
106…キャリアセンス制御部;
107…再送制御部;
109…第一種の物理層プロトコル処理部;
110…第二種の物理層プロトコル処理部
100: Communication device;
101 ... Physical layer (PHY);
102 ... MAC (medium access control) layer;
103 ... link layer;
104: antenna;
105 ... aggregation processing unit;
106: Carrier sense control unit;
107 ... retransmission control unit;
109 ... The first type physical layer protocol processing unit;
110 ... Second-type physical layer protocol processing unit
Claims (10)
始点シーケンス番号と、前記第1のデータフレーム及び前記第2のデータフレームのうちの少なくとも一方の受信状態を示すビットマップとを含む第1送達確認フレームを作成する作成手段と、
前記受信手段で前記物理フレームを受信してから最小フレーム間隔経過した後に、前記物理フレームの送信元である通信装置に対して、前記第1送達確認フレームを送信する送信手段とを備え、
前記物理フレームは、
(a)前記第1のデータフレームと、前記第1のデータフレームの長さについての第1情報と、前記第1情報の誤りを検出するための第1誤り検出コードと、バイトアラインメントを行うための第1領域と、を有する第1フィールドと、
(b)前記第2のデータフレームと、前記第2のデータフレームの長さについての第2情報と、前記第2情報の誤りを検出するための第2誤り検出コードと、バイトアラインメントを行うための第2領域と、を有する第2フィールドとを有し、
前記作成手段は、前記第1誤り検出コードで前記第1情報に誤りが検出されず、かつ前記第1データフレームのFCSで誤りが検出されない場合に、前記第1のデータフレームを正しく受信したこととし、
前記第1誤り検出コードで前記第1情報に誤りが検出されたか、あるいは前記第1データフレームのFCSで誤りが検出された場合に、前記第1のデータフレームの受信に失敗したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されず、かつ前記第2データフレームのFCSで誤りが検出されない場合に、前記第2のデータフレームを正しく受信したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されたか、あるいは前記第2データフレームのFCSで誤りが検出された場合に、前記第2のデータフレームの受信に失敗したこととし、
前記受信手段は、前記第1のデータフレームに付加されたシーケンス番号及び前記第2のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第1のデータフレーム及び前記第2のデータフレームのうちの少なくとも一方を再度受信することを特徴とする通信装置。 Receiving means for receiving a physical frame having a first data frame and a second data frame each having a sequence number and an FCS (Frame Check Sequence) ;
Creating means for creating a first delivery confirmation frame including a start point sequence number and a bitmap indicating a reception state of at least one of the first data frame and the second data frame ;
Transmission means for transmitting the first delivery confirmation frame to a communication device that is a transmission source of the physical frame after a minimum frame interval has elapsed since the reception of the physical frame by the reception means;
The physical frame is
(A) To perform byte alignment, the first data frame, first information about the length of the first data frame, a first error detection code for detecting an error in the first information, and A first field having a first field of
(B) To perform byte alignment with the second data frame, second information about the length of the second data frame, a second error detection code for detecting an error in the second information, and A second field having a second field,
The creation means has correctly received the first data frame when no error is detected in the first information by the first error detection code and no error is detected by FCS of the first data frame. age,
When an error is detected in the first information by the first error detection code or when an error is detected by FCS of the first data frame, reception of the first data frame has failed,
When no error is detected in the second information by the second error detection code and no error is detected by FCS of the second data frame, the second data frame is correctly received;
When an error is detected in the second information by the second error detection code or when an error is detected by FCS of the second data frame, reception of the second data frame has failed,
The receiving means is configured to change the first number according to the sequence number added to the first data frame and the sequence number added to the second data frame, the start point sequence number, and the bitmap . communication apparatus characterized by receiving at least one again of the data frame and the second data frame.
始点シーケンス番号と、前記第1のデータフレーム及び前記第2のデータフレームの少なくとも一方の受信状態を示すビットマップとを含む第1送達確認フレームを作成する作成手段と、
前記受信手段で前記物理フレームを受信してからSIFS期間経過した後に、前記物理フレームの送信元である通信装置に対して、前記第1送達確認フレームを送信する送信手段とを備え、
前記物理フレームは、
(a)前記第1のデータフレームと、前記第1のデータフレームの長さについての第1情報と、前記第1情報の誤りを検出するための第1誤り検出コードと、バイトアラインメントを行うための第1領域と、を有する第1フィールドと、
(b)前記第2のデータフレームと、前記第2のデータフレームの長さについての第2情報と、前記第2情報の誤りを検出するための第2誤り検出コードと、バイトアラインメントを行うための第2領域と、を有する第2フィールドとを有し、
前記作成手段は、前記第1誤り検出コードで前記第1情報に誤りが検出されず、かつ前記第1データフレームのFCSで誤りが検出されない場合に、前記第1のデータフレームを正しく受信したこととし、
前記第1誤り検出コードで前記第1情報に誤りが検出されたか、あるいは前記第1データフレームのFCSで誤りが検出された場合に、前記第1のデータフレームの受信に失敗したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されず、かつ前記第2データフレームのFCSで誤りが検出されない場合に、前記第2のデータフレームを正しく受信したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されたか、あるいは前記第2データフレームのFCSで誤りが検出された場合に、前記第2のデータフレームの受信に失敗したこととし、
前記受信手段は、前記第1のデータフレームに付加されたシーケンス番号及び前記第2のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第1のデータフレーム及び前記第2のデータフレームの少なくとも1つを再度受信することを特徴とする通信装置。 Receiving means for receiving a physical frame having a first data frame and a second data frame each having a sequence number and an FCS (Frame Check Sequence) ;
Creating means for creating a first delivery confirmation frame including a start point sequence number and a bitmap indicating a reception state of at least one of the first data frame and the second data frame ;
A transmission unit that transmits the first delivery confirmation frame to a communication device that is a transmission source of the physical frame after a SIFS period has elapsed since the reception unit received the physical frame;
The physical frame is
(A) To perform byte alignment, the first data frame, first information about the length of the first data frame, a first error detection code for detecting an error in the first information, and A first field having a first field of
(B) To perform byte alignment with the second data frame, second information about the length of the second data frame, a second error detection code for detecting an error in the second information, and A second field having a second field,
The creation means has correctly received the first data frame when no error is detected in the first information by the first error detection code and no error is detected by FCS of the first data frame. age,
When an error is detected in the first information by the first error detection code or when an error is detected by FCS of the first data frame, reception of the first data frame has failed,
When no error is detected in the second information by the second error detection code and no error is detected by FCS of the second data frame, the second data frame is correctly received;
When an error is detected in the second information by the second error detection code or when an error is detected by FCS of the second data frame, reception of the second data frame has failed,
The receiving means is configured to change the first number according to the sequence number added to the first data frame and the sequence number added to the second data frame, the start point sequence number, and the bitmap . A communication apparatus, wherein at least one of a data frame and the second data frame is received again.
前記作成手段は、正しく受信したデータフレームに含まれる、シーケンス番号と、送信元アドレスと、宛先アドレスと、優先度識別子とを用いて、前記第1送達確認フレームを作成することを特徴とする請求項1又は請求項2に記載の通信装置。The creation unit creates the first delivery confirmation frame using a sequence number, a source address, a destination address, and a priority identifier included in a correctly received data frame. The communication device according to claim 1 or 2.
前記受信手段が送達確認要求フレームを受信した場合に、前記作成手段は、前記記憶手段に記憶されたビットマップによって第2送達確認フレームを作成し、
前記送信手段は、前記第2送達確認フレームを送信することを特徴とする請求項4に記載の通信装置。 Storage means for storing a bitmap included in the first delivery confirmation frame;
When the receiving means receives the delivery confirmation request frame, the creating means creates a second delivery confirmation frame by the bitmap stored in the storage means,
The communication apparatus according to claim 4 , wherein the transmission unit transmits the second delivery confirmation frame.
前記送信手段は、前記第3送達確認フレームを送信することを特徴とする請求項5に記載の通信装置。 When the start sequence number of the delivery confirmation request frame is larger than the sequence number of the data frame received before receiving the delivery confirmation request frame, the creation means indicates that there is no data frame successfully received. 3 Create a delivery confirmation frame,
The communication apparatus according to claim 5 , wherein the transmission unit transmits the third delivery confirmation frame.
前記送信手段は、前記第4送達確認フレームを送信することを特徴とする請求項5に記載の通信装置。 If the start sequence number of the delivery confirmation request frame is equal to or less than the sequence number corresponding to the last bit of the bitmap stored in the storage means, the creation means includes at least a part of the bitmap. 4 Create a delivery confirmation frame,
The communication device according to claim 5 , wherein the transmission unit transmits the fourth delivery confirmation frame.
前記受信手段は、前記アンテナを介して、前記物理フレームを受信し、The receiving means receives the physical frame via the antenna;
前記送信手段は、前記アンテナを介して、前記第1送達確認フレームを送信することを特徴とする請求項1乃至請求項7のいずれか1項に記載の通信装置。The communication apparatus according to claim 1, wherein the transmission unit transmits the first delivery confirmation frame via the antenna.
始点シーケンス番号と、前記第1のデータフレーム及び前記第2のデータフレームのうちの少なくとも一方の受信状態を示すビットマップとを含む第1送達確認フレームを作成し、
前記物理フレームを受信してから最小フレーム間隔経過した後に、前記物理フレームの送信元である通信装置に対して、前記第1送達確認フレームを送信し、
前記物理フレームは、
(a)前記第1のデータフレームと、前記第1のデータフレームの長さについての第1情報と、前記第1情報の誤りを検出するための第1誤り検出コードと、バイトアラインメントを行うための第1領域と、を有する第1フィールドと、
(b)前記第2のデータフレームと、前記第2のデータフレームの長さについての第2情報と、前記第2情報の誤りを検出するための第2誤り検出コードと、バイトアラインメントを行うための第2領域と、を有する第2フィールドとを有し、
前記第1送達確認フレームの作成においては、
前記第1誤り検出コードで前記第1情報に誤りが検出されず、かつ前記第1データフレームのFCSで誤りが検出されない場合に、前記第1のデータフレームを正しく受信したこととし、
前記第1誤り検出コードで前記第1情報に誤りが検出されたか、あるいは前記第1データフレームのFCSで誤りが検出された場合に、前記第1のデータフレームの受信に失敗したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されず、かつ前記第2データフレームのFCSで誤りが検出されない場合に、前記第2のデータフレームを正しく受信したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されたか、あるいは前記第2データフレームのFCSで誤りが検出された場合に、前記第2のデータフレームの受信に失敗したこととし、
前記第1のデータフレームに付加されたシーケンス番号及び前記第2のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第1のデータフレーム及び前記第2のデータフレームのうちの少なくとも一方を再度受信することを特徴とする通信方法。 Each receiving a physical frame having a first data frame and the second data frame with a sequence number and FCS (Frame Check Sequence),
Creating a first delivery confirmation frame including a start point sequence number and a bitmap indicating a reception state of at least one of the first data frame and the second data frame;
After a minimum frame interval has elapsed since receiving the physical frame, the first delivery confirmation frame is transmitted to the communication device that is the transmission source of the physical frame ,
The physical frame is
(A) To perform byte alignment, the first data frame, first information about the length of the first data frame, a first error detection code for detecting an error in the first information, and A first field having a first field of
(B) To perform byte alignment with the second data frame, second information about the length of the second data frame, a second error detection code for detecting an error in the second information, and A second field having a second field,
In creating the first delivery confirmation frame,
When no error is detected in the first information by the first error detection code and no error is detected by FCS of the first data frame, the first data frame is correctly received;
When an error is detected in the first information by the first error detection code or when an error is detected by FCS of the first data frame, reception of the first data frame has failed,
When no error is detected in the second information by the second error detection code and no error is detected by FCS of the second data frame, the second data frame is correctly received;
When an error is detected in the second information by the second error detection code or when an error is detected by FCS of the second data frame, reception of the second data frame has failed,
According to the sequence number added to the first data frame and the sequence number added to the second data frame, the starting sequence number, and the bitmap, the first data frame and the first data frame A communication method comprising receiving at least one of the two data frames again .
始点シーケンス番号と、前記第1のデータフレーム及び前記第2のデータフレームのうちの少なくとも一方の受信状態を示すビットマップとを含む第1送達確認フレームを作成し、
前記物理フレームを受信してからSIFS期間経過した後に、前記物理フレームの送信元である通信装置に対して、前記第1送達確認フレームを送信し、
前記物理フレームは、
(a)前記第1のデータフレームと、前記第1のデータフレームの長さについての第1情報と、前記第1情報の誤りを検出するための第1誤り検出コードと、バイトアラインメントを行うための第1領域と、を有する第1フィールドと、
(b)前記第2のデータフレームと、前記第2のデータフレームの長さについての第2情報と、前記第2情報の誤りを検出するための第2誤り検出コードと、バイトアラインメントを行うための第2領域と、を有する第2フィールドとを有し、
前記第1送達確認フレームの作成においては、
前記第1誤り検出コードで前記第1情報に誤りが検出されず、かつ前記第1データフレームのFCSで誤りが検出されない場合に、前記第1のデータフレームを正しく受信したこととし、
前記第1誤り検出コードで前記第1情報に誤りが検出されたか、あるいは前記第1データフレームのFCSで誤りが検出された場合に、前記第1のデータフレームの受信に失敗したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されず、かつ前記第2データフレームのFCSで誤りが検出されない場合に、前記第2のデータフレームを正しく受信したこととし、
前記第2誤り検出コードで前記第2情報に誤りが検出されたか、あるいは前記第2データフレームのFCSで誤りが検出された場合に、前記第2のデータフレームの受信に失敗したこととし、
前記第1のデータフレームに付加されたシーケンス番号及び前記第2のデータフレームに付加されたシーケンス番号と、前記始点シーケンス番号と、前記ビットマップとに応じて、前記第1のデータフレーム及び前記第2のデータフレームのうちの少なくとも一方を再度受信することを特徴とする通信方法。 Each receiving a physical frame having a first data frame and the second data frame with a sequence number and FCS (Frame Check Sequence),
Creating a first delivery confirmation frame including a start point sequence number and a bitmap indicating a reception state of at least one of the first data frame and the second data frame;
After the SIFS period has elapsed since the physical frame was received, the first delivery confirmation frame is transmitted to the communication device that is the transmission source of the physical frame ,
The physical frame is
(A) To perform byte alignment, the first data frame, first information about the length of the first data frame, a first error detection code for detecting an error in the first information, and A first field having a first field of
(B) To perform byte alignment with the second data frame, second information about the length of the second data frame, a second error detection code for detecting an error in the second information, and A second field having a second field,
In creating the first delivery confirmation frame,
When no error is detected in the first information by the first error detection code and no error is detected by FCS of the first data frame, the first data frame is correctly received;
When an error is detected in the first information by the first error detection code or when an error is detected by FCS of the first data frame, reception of the first data frame has failed,
When no error is detected in the second information by the second error detection code and no error is detected by FCS of the second data frame, the second data frame is correctly received;
When an error is detected in the second information by the second error detection code or when an error is detected by FCS of the second data frame, reception of the second data frame has failed,
According to the sequence number added to the first data frame and the sequence number added to the second data frame, the starting sequence number, and the bitmap, the first data frame and the first data frame A communication method comprising receiving at least one of the two data frames again .
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006188619A JP4374001B2 (en) | 2006-07-07 | 2006-07-07 | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006188619A JP4374001B2 (en) | 2006-07-07 | 2006-07-07 | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004234814A Division JP4440037B2 (en) | 2004-08-11 | 2004-08-11 | Communication apparatus and communication method |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2006352897A JP2006352897A (en) | 2006-12-28 |
JP2006352897A5 JP2006352897A5 (en) | 2009-05-14 |
JP4374001B2 true JP4374001B2 (en) | 2009-12-02 |
Family
ID=37648147
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006188619A Expired - Lifetime JP4374001B2 (en) | 2006-07-07 | 2006-07-07 | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4374001B2 (en) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101473159B1 (en) | 2006-09-29 | 2014-12-15 | 파나소닉 주식회사 | Communication apparatus and communication method |
JP4903736B2 (en) * | 2008-03-13 | 2012-03-28 | 三菱電機株式会社 | Data transmission / reception device and data transmission / reception system |
JP2010093694A (en) * | 2008-10-10 | 2010-04-22 | Hitachi Ltd | Radio communication method, radio communication program, and radio communication device |
JP2010135909A (en) * | 2008-12-02 | 2010-06-17 | Toshiba Corp | Radio communication apparatus, and radio communication method |
JP5279640B2 (en) * | 2009-07-09 | 2013-09-04 | 三菱電機株式会社 | Wireless communication system, wireless communication device, receiving device, and wireless communication method |
US9064186B2 (en) * | 2010-12-09 | 2015-06-23 | Nokia Technologies Oy | Limited-context-based identifying key frame from video sequence |
JP5329581B2 (en) | 2011-02-04 | 2013-10-30 | 株式会社東芝 | Wireless communication terminal and wireless communication method |
JP5814829B2 (en) | 2012-03-01 | 2015-11-17 | 株式会社東芝 | Wireless communication apparatus and method |
MY157062A (en) * | 2012-10-30 | 2016-04-29 | Univ Putra Malaysia | A method for adjusting aggregation size based on acknowledgement (ack) bitmap |
EP3422761B1 (en) * | 2016-02-22 | 2021-03-17 | Sony Corporation | Wireless communication device and wireless communication method |
WO2017145790A1 (en) * | 2016-02-26 | 2017-08-31 | ソニー株式会社 | Receiving device, sending device and data processing method |
EP4210410A1 (en) | 2018-08-21 | 2023-07-12 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Apparatus and method of wireless communication of same |
CN116318257B (en) * | 2023-03-06 | 2023-09-12 | 重庆物奇科技有限公司 | Data transmission method, system and storage medium based on power line carrier |
-
2006
- 2006-07-07 JP JP2006188619A patent/JP4374001B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2006352897A (en) | 2006-12-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4440037B2 (en) | Communication apparatus and communication method | |
JP4374001B2 (en) | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM | |
JP4331088B2 (en) | Communication apparatus and communication method | |
JP4130648B2 (en) | Communication apparatus and communication method | |
US7990995B2 (en) | Wireless communication apparatus and wireless communication method | |
CN1984145B (en) | communication device | |
JP4047836B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION CONTROL PROGRAM | |
US8228889B2 (en) | Communication apparatus, communication system and communication control program | |
EP2923514B1 (en) | Method and system for improving wireless link efficiency | |
JP4314294B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION CONTROL PROGRAM |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070723 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090327 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090421 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090617 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090811 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090904 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120911 Year of fee payment: 3 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 4374001 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120911 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120911 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130911 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term | ||
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |