JP4130648B2 - 通信装置および通信方法 - Google Patents

通信装置および通信方法 Download PDF

Info

Publication number
JP4130648B2
JP4130648B2 JP2004304475A JP2004304475A JP4130648B2 JP 4130648 B2 JP4130648 B2 JP 4130648B2 JP 2004304475 A JP2004304475 A JP 2004304475A JP 2004304475 A JP2004304475 A JP 2004304475A JP 4130648 B2 JP4130648 B2 JP 4130648B2
Authority
JP
Japan
Prior art keywords
frame
block ack
delivery confirmation
mac
physical
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.)
Active
Application number
JP2004304475A
Other languages
English (en)
Other versions
JP2006121199A (ja
JP2006121199A5 (ja
Inventor
泰如 西林
雅裕 高木
朋子 足立
智哉 旦代
徹 中島
依子 宇都宮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004304475A priority Critical patent/JP4130648B2/ja
Priority to US11/201,198 priority patent/US7746861B2/en
Priority to CN2005101076140A priority patent/CN1764157B/zh
Priority to CNA2009100017162A priority patent/CN101453755A/zh
Publication of JP2006121199A publication Critical patent/JP2006121199A/ja
Publication of JP2006121199A5 publication Critical patent/JP2006121199A5/ja
Application granted granted Critical
Publication of JP4130648B2 publication Critical patent/JP4130648B2/ja
Priority to US12/558,085 priority patent/US7848330B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9084—Reactions to storage capacity overflow
    • H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
    • H04L49/9094—Arrangements for simultaneous transmit and receive, e.g. simultaneous reading/writing from/to the storage element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H04B7/2643—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile using time-division multiple access [TDMA]
    • H04B7/2656—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile using time-division multiple access [TDMA] for structure of frame, burst
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols

Description

本発明は、物理層のキャリアセンス情報とＭＡＣ層のキャリアセンス情報に基づいて媒体アクセス制御を行なう通信装置および通信方法に関する。
同一の媒体を共有して通信を行なう複数の通信装置がどのように媒体を利用して通信データを送信するかを決めるのが、媒体アクセス制御(ＭＡＣ: Media Access Control)である。媒体アクセス制御は、同時に２つ以上の通信装置が同一の媒体を利用して通信データの送信を行なった結果、受信側の通信装置が通信データを分離できなくなる事象（衝突）がなるべく少なくなり、一方、送信要求を持つ通信装置が存在するにもかかわらず媒体がいずれの通信装置によっても利用されない事象がなるべく少なくなるように、通信装置から媒体へのアクセスを制御するための技術である。
しかし、特に無線通信においては、通信装置がデータを送信しながら同時に送信データをモニタすることは困難であることから、衝突検出を前提としない媒体アクセス制御（ＭＡＣ）が必要である。無線ＬＡＮの代表的な技術標準であるIEEE802.11はＣＳＭＡ／ＣＡ(Carrier Sense Multiple Access with Collision Avoidance)を採用している。IEEE802.11のＣＳＭＡ／ＣＡでは、ＭＡＣフレームのヘッダーに、該フレームに続く１つ以上のフレーム交換からなる一連のシーケンスが終了するまでの期間(Duration)が設定される。この期間において、該シーケンスに関係がなく送信権を持たない通信装置は、媒体の仮想的な占有状態を判断することにより、送信を待機する。したがって、衝突の発生が回避される。一方、該シーケンスで送信権を持つ通信装置は、実際に物理媒体が占有されている期間を除き、媒体は使用されていないものと認識する。IEEE802.11では、このようなＭＡＣ層の仮想キャリアセンスと、物理層の物理キャリアセンスとの組み合わせによって媒体の状態を判定し、媒体アクセスを制御する旨が規定されている。
ＣＳＭＡ／ＣＡを採用しているIEEE802.11は、これまで主として物理層プロトコルを変更することによって通信速度の高速化を図ってきた。２．４ＧＨｚ帯についてはIEEE802.11（１９９７年、２Ｍｂｐｓ）からIEEE802.11b（１９９９年、１１Ｍｂｐｓ）へ、そしてIEEE802.11g（２００３年、５４Ｍｂｐｓ）へと変遷している。５ＧＨｚ帯については、今のところIEEE802.11a（１９９９年、５４Ｍｂｐｓ）のみが標準として存在する。そして、２．４ＧＨｚ帯および５ＧＨｚ帯の両方で更なる高速化を目指す標準規格を策定するためにIEEE802.11 TGn(Task Group n)が既に設立されている。
さらに、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するＱｏＳとして、従来のポーリング手順を拡張したＨＣＣＡ（HCF Controlled Access；ＨＣＦコントロールド・アクセス）がある。ＨＣＣＡでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。特許文献２は、IEEE802.11e規格のＱｏＳについて言及しており、無線ネットワークにおける通信装置間の通信に優先順位を付与する方法を開示する。
米国特許第５３２９５３１号明細書 特開２００２−３１４５４６公報
通信速度の高速化の実現において既存の規格と同一の周波数帯を用いるのであれば、新たに提供される通信装置は、既存の規格に従う通信装置との共存が可能であって、後方互換性も維持されることが好ましい。したがって、ＭＡＣ層のプロトコルは基本的には既存の規格と整合するＣＳＭＡ／ＣＡに従うのが良いと考えられる。この場合、ＣＳＭＡ／ＣＡに係わる時間的なパラメータ、例えばフレーム間の時間間隔(IFS: Interframe Space)やバックオフ期間を既存の規格と揃える必要がある。
ここで、物理層に関して通信速度の高速化を図れたとしても、通信の実質的なスループットを向上できないという問題点がある。すなわち、物理層の高速化が実現された場合、ＰＨＹフレームのフォーマットはもはや効率的ではなくなり、このことに起因するオーバヘッドがスループットの向上を阻害すると考えられる。ＰＨＹフレームにおいて、ＣＳＭＡ／ＣＡに係わる時間的なパラメータはＭＡＣフレームに固定的に付随している。また、ＰＨＹフレームヘッダーは各ＭＡＣフレーム毎にそれぞれ必要である。
オーバヘッドを削減してスループットを向上させる方法の一つとして、最近のdraft IEEE802.11e draft 5.0 (IEEE802.11のQoS強化) で導入されたBlock ACKがある。これを用いれば、バックオフ無しで複数のMACフレームを連続的に送信できるため、バックオフの量は削減できるが、物理層のヘッダーは削減されない。また、初期のdraft IEEE802.11eで導入されたアグリゲーションによれば、バックオフ量と物理層ヘッダーのいずれも削減可能だが、従来の物理層の制約によりMACフレームが含まれる物理層のフレームの長さを約4k byte以上にはできないため、効率の向上には大きな制約がある。仮に物理層のフレームを長くできたとしても、エラー耐性が低下するという問題が生じる。
本発明はかかる問題を解決すべくなされたものであり、既存の装置との共存が可能であって、しかもフレームフォーマットの効率化により複数のフレームを送信することに伴うオーバヘッドを解消して通信の実質的なスループットを向上できる通信装置および通信方法を提供することを目的とする。
本発明の一観点に係る通信装置は、各々がシーケンス番号を有する複数のＭＡＣフレームがアグリゲートされた物理フレームを受信する受信手段と、前記受信手段により受信された物理フレームのＭＡＣフレームを記憶する受信バッファと、前記受信手段により受信された物理フレーム内の先頭のＭＡＣフレームが正常に受信されたか否かを判定する判定手段と、前記先頭のＭＡＣフレームが正常に受信されたならば、該先頭のＭＡＣフレームのシーケンス番号に基づいて上位層に渡すべきＭＡＣフレームを判定し、該ＭＡＣフレームを前記受信バッファから取り出す受信バッファ管理手段とを具備する通信装置である。
本発明によれば、フレームフォーマットの効率化により複数のフレームを送信することに伴うオーバヘッドを解消して通信の実質的なスループットを向上できる通信装置および通信方法を提供できる。
図１は本発明の第一の実施形態に係る通信装置の構成を示すブロック図である。この通信装置１００は無線リンクを介して他の通信装置と通信する装置であり、物理層、ＭＡＣ層、およびリンク層のそれぞれに相当する処理ユニット１０１、１０２、１０３を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはＬＳＩに組み込まれたＣＰＵにより実行されるファームウェア等として実現される。物理層の処理ユニット（以下、「処理ユニット」の表記を省略）１０１にはアンテナ１０４が接続されている。ＭＡＣ層１０２はＭＡＣフレームのアグリゲーション（集約）処理部１０５を有する。このアグリゲーション処理部１０５は、キャリアセンス制御部１０６と、再送制御部１０７とを備え、後に詳しく説明するブロックACK（複数のＭＡＣフレームに対する送達確認）フレームの送受信及びブロックACKフレームに基づく再送制御等を行う。
物理層１０１は、二種類の物理層プロトコルに対応可能に構成される。それぞれのプロトコル処理のために、物理層１０１は第一種の物理層プロトコル処理部１０９および第二種の物理層プロトコル処理部１１０を有する。なお、実装では第一種の物理層プロトコル処理部１０９と第二種の物理層プロトコル処理部１１０との間で回路の共用などがしばしば行なわれるため、これらは必ずしも独立して存在するわけではない。
本発明の実施形態では、第一種の物理層プロトコルはIEEE802.11aに規定されるプロトコルとし、第二種の物理層プロトコルは送信側と受信側とでそれぞれ複数のアンテナを用いる、いわゆるＭＩＭＯ(Multiple Input Multiple Output)によるプロトコルと仮定する。周波数帯域を同一に保ってもアンテナの数にほぼ比例した伝送容量の増加が見込めることから、ＭＩＭＯはIEEE802.11の更なる高スループット化を目指すために利用可能な技術の一つである。リンク層１０３に関しては、IEEE802で規定される通常のリンク層機能を有するものとする。伝送レートを向上するために採用する技術はMIMOに限定されない。例えば、周波数占有帯域を増やすような方法、およびそれとMIMOの組み合わせでも構わない。
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)として応答する。
本発明の実施形態の詳細を説明する前に、ブロックACK及びブロックACKの受信側端末におけるバッファ管理の既存技術について説明する。IEEE802.11e Draft 10.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)として応答する。
図２は、HCCA(Hybrid coordination function Controlled Channel Access)における即時型ブロックACKのシーケンス例を示している。HCCAはコンテンションフリーのQoS制御方式であって、HC(Hybrid Coordinator)と呼ばれるQoS-AP(QoS Access Point)がポーリングの主体となる。図２に示されるHCはQoS CF-Poll(Contention Free Poll)フレーム２０をQSTA(QoS Station)1に対して送信し、チャネルの使用許可をTXOP期間1として与える。QSTA1はTXOP期間1の間、QoSデータ２１をSIFS間隔でバースト的に送信したのち、ブロックACK要求２２を送信する。ブロックACK要求２２にはブロックACK始点シーケンス制御(Block ACK Starting Sequence Control)と呼ばれる2オクテットのフィールドが存在し、そこにはフラグメント番号と始点シーケンス番号(StartingSeq)が記載される。データ受信側のQSTA2は、フラグメント番号と始点シーケンス番号を起点とする過去の受信履歴をビットマップ形式にしてブロックACK２３を生成し、データ送信側のQSTA1に対して通知することになる。
より具体的には、図２に示すようにQSTA1がシーケンス番号「1」、「2」、「3」のQoSデータ２１をSIFS間隔でQSTA2に対してバースト的に送信したのち、Block ACK Starting Sequence Controlの値を「1」としてブロックACK要求２２を送信している。QSTA2はブロックACK要求２２を受信し、該ブロックACK要求２２のBlock ACK Starting Sequence Controlの値が「1」であるため、シーケンス番号「1」からの相対的な受信履歴をBlock ACK Bitmapに記載してブロックACK２３をQSTA1に対して送信する。
図２の例では、FCS(Frame Check Sequence)の計算の結果、シーケンス番号「1」のデータに誤りが生じている。ブロックACK２３のBlock ACK Starting Sequence Controlは「1」であるが、Block ACK Bitmapは、シーケンス番号「2」と「3」のデータのみが正常に受信できたことを、該当部分のビットを用いて示す。一般に、ブロックACKによれば、フラグメント化をした場合を含め最大64MSDU(MAC Size Data Unit)分の受信履歴（送達確認）を通知することが可能である。IEEE802.11の規定によれば、1MSDUは最大で16個のMPDU(MAC Protocol Data Unit)にフラグメント化されるため、ブロックACKに含まれるブロックACKビットマップ(Block ACK Bitmap)フィールドは1024ビットの大きさになる。IEEE802.11の規定によれば、送信するデータフレームには再送の上限回数(Retry Limit)や生存期間(Life Time)が定められている。再送の上限回数や生存期間を超過したフレームは送信側で破棄される。また、IEEE802.11eの規定によれば、トラフィックの性質に応じて、フレームの遅延許容時間(Delay Bound)が定められている。例えば音声データのようにリアルタイム性が求められるトラフィックには、遅延許容時間はより短く設定される。遅延許容時間を経過した場合についても、該当するフレームはやはり送信側において破棄される。図２の例では、シーケンス番号「1」のQoSデータフレームは再送の必要があるが、再送回数の上限などを超過したために送信側が再送を諦めた場合に該当する。
TXOP期間1の満了から一定時間が経過した後、HCがQSTA1に対してQoS CF-Pollフレーム２４を送信することでチャネル使用を許可するためのTXOP期間2を再び付与すると、QSTA1はシーケンス番号「1」の再送を諦めており、今度はシーケンス番号「4」のデータ２５を新規に送信している。その後、Block ACK Starting Sequence Controlの値を「4」としてブロックACK要求２６を送信し、QSTA2は「4」を正常に受信したことを示すブロックACK２７を返信する。尚、図２の例では、優先度が全て同じフレームの場合である。IEEE802.11eの規定によれば、送信するデータフレームはトラフィックの種類に応じて、クラス分けされ、TID(Traffic Identifier)と呼ばれる識別子を付与される。シーケンス番号もTID毎に割り振られるため、ブロックACK要求やブロックACKもTID毎に必要となる。
図３は、図２の内容を踏まえ、IEEE802.11eのブロックACKによるデータ伝送を行なう際に受信側で行われるバッファ管理の様子を示している。当初、受信側のバッファ３０は空であったとする。送信端末がシーケンス番号「1」、「2」、「3」のデータをバースト的に送信し、図３に示すように例えばシーケンス番号「2」と「3」だけが正常に受信されたとする。受信側では、シーケンス番号「1」のフレームをまだ受信していないので、シーケンス番号「2」と「3」のフレームをMAC層の受信バッファ３０に格納したままにする。
ここで、シーケンス番号「1」のフレームがリトライリミットに達すると、送信端末は新しくシーケンス番号「4」のフレームを送信し、その後、Block ACK Starting Sequence Controlの値を「4」に設定したブロックACK要求を送信する。このとき、受信側のバッファ３０には、シーケンス番号「2」、「3」、「4」のフレームが格納されている。また、ブロックACK要求を受信した際のBlock ACK Starting Sequence Controlは「4」である。IEEE802.11e Draft 10.0の規定によれば、Block ACK Starting Sequence Controlよりも前のシーケンス番号のフレームは全て上位層（上位レイヤ）に渡す必要がある。よって、シーケンス番号「2」、「3」といったBlock ACK Starting Sequence Control「4」よりも前の番号のフレームは全てバッファ３０から開放され、上位層に渡される。さらに、「2」、「3」からシーケンス番号が連続している「4」もバッファ３０から開放し、上位層に渡す。以上のような受信側のバッファ管理はコンテンションベースのQoS制御方式であるEDCA(Enhanced Distributed Channel Access)でも同様の動作となる。
（第一の実施形態）
本発明の第一の実施形態は、単一PSDU(PHY Service Data Unit)に複数のMPDU(MAC Protocol Data Unitがアグリゲートされ、かつブロックACK要求を含まないPPDU(PHY Protocol Data Unit)を送信する通信装置において、先頭のMPDUが正常に受信できていれば、該先頭のMPDUのシーケンス番号を元に受信バッファ管理を行うようにした通信装置に関する。なお、PPDUはPHYフレーム及びPSDUを内部に含んだ物理フレームに相当する。また、MPDUはMACヘッダー及びMSDU(MAC Service Data Unit)を内部に含んだMACフレームに相当する。
無線LANでハイスループットを達成するには、フレーム間隔やバックオフ期間といったMAC層のオーバヘッド、及び物理層のオーバヘッドを削減する必要があるが、図４及び図５に示すように、複数のMPDUを1つのPSDUにアグリゲートして送信することにより、これらのオーバヘッドを削減することが可能である。図４の例では、複数のMPDUがアグリゲートされたPSDU４０の先頭部分に、MACヘッダーからFCSまでを含むMPDUの長さをオクテット単位で示すヘッダー４１が存在する。以後、このヘッダー４１をMACスーパーフレームヘッダーと呼ぶ。MACスーパーフレームヘッダー４１には、ヘッダー４１自体の誤りを検出するためのCRC(Cyclic Redundancy Check)が付加される。MPDUが存在しない部分のMPDU長フィールドには0が記載される。また、MACスーパーフレームヘッダー４１が誤っていれば、全てのMPDUの受信に失敗したとみなす。一方、図５の例では、アグリゲートされた各MPDUの前方に、後続するMPDUの長さを示す情報が存在する。更に、MPDU長情報の誤りを検出するためのCRCが付加され、MPDU長情報及びCRCを併せてMPDUセパレーション５０と呼ぶ。図５の構成の物理フレーム(PPDU)を受信した端末は、まず先頭のMPDUセパレーション５０のCRCを検査する。先頭のMPDUセパレーション５０を正常に受信していれば、後続するMPDU1を切り出してFCSの計算を行なう。FCSの結果が正常であれば、該MPDU1を正常に受信したと判断する。FCSの結果が異常であれば、該MPDU1の受信に失敗したとみなし、MPDU長の示す分だけスキップし、次のMPDUセパレーション５１のCRCを検査する。MPDUセパレーション５１が誤っていたならば、連続的にオクテット単位でCRC検査を行い、その結果が正常であれば、後続するMPDUに対するFCSを計算し、正常に受信できたかどうかの判断をする。
本発明の実施形態に係る以下の説明において、PSDUに複数のMPDUがアグリゲートされた物理フレーム(PPDU)に対する部分応答には、例えばIEEE802.11eのブロックACKを拡張したものを利用することとする。図６に、拡張されたブロックACKのフレーム構成を示す。IEEE802.11e Draft 10.0によれば、ブロックACKフレームは、フラグメント化を考慮して、1024ビットの固定長のビットマップ(Block ACK Bitmap)を持つ。フラグメントは一般にオーバヘッドが大きいことから、ハイスループットを達成するにはMSDUをフラグメント化しないことが望ましい。そこで、拡張されたブロックACKフレームは、フラグメント化を行なわないことを前提とし、図６に示すように高々64MSDU分のBlock ACK Bitmap６０を具備する。これにより、従来のブロックACKフレームに比べ、16分の1のサイズに圧縮することが可能である。以後、Block ACK Bitmapが圧縮されたブロックACKフレームのことを圧縮ブロックACKと呼ぶことにする。尚、圧縮ブロックACKのBlock ACK Bitmapは、１つのPSDUにアグリゲートされたMPDUの数に応じて可変長としても良い。
図７および図８を参照しながら、単一のPSDUに複数のMPDUがアグリゲートされた物理フレームを送信する一例を示す。図７に示すように、送信端末により、シーケンス番号「1」〜「8」のMPDUがアグリゲートされている場合を考える。IEEE802.11e Draft 10.0の規定によれば、ブロックACKを返信するためにブロックACK要求が必要であるが、第一の実施形態においては、複数のMPDUがアグリゲートされた物理フレームを受信した際、ブロックACK要求がその中に含まれていなくても即座に圧縮ブロックACKで応答することを前提とする。圧縮ブロックACKは、受信されたPSDU内の各MPDUの受信ステータスをそのままBlock ACK Bitmapに変換したものに相当する。圧縮ブロックACKは、ブロックACK要求が示すBlock ACK Starting Sequence Controlを元に過去の受信履歴を遡って検索し、作成する必要がない点でIEEE802.11eのブロックACKとは異なる。
図７に示すように、受信端末が受信した物理フレームのPSDUにアグリゲートされている複数のMPDUのうち、シーケンス番号「2」、「5」、「7」のMPDUがFCS計算の結果、誤っていたとする。ここで、先頭のMPDUは正常に受信されていることから、この先頭のMPDUのシーケンス番号の値をそのままブロックACK要求のBlock ACK Starting Sequence Controlの値とすることができる。よって、受信端末はBlock ACK Starting Sequence Controlを「1」とし、Block ACK Bitmap７０を10110101…のように記載した圧縮ブロックACKを応答する。この圧縮ブロックACKを受信したデータ送信端末は、Block ACK Bitmap７０の値から、シーケンス番号「1」、「3」、「4」、「6」、「8」のMPDUが送信に成功したことを知り、それ以外のシーケンス番号「2」、「5」、「7」のMPDUは再送が必要であると判断する。
そして図８に示すように、送信端末は再送分のMPDU８０と共に新しいシーケンス番号のMPDU８１が同一のPSDUにアグリゲートされた物理フレームを構築して送信する。なお、新規送信分のMPDU８１を当該PSDUにいくつアグリゲートするかについては、受信側のバッファサイズに依存する。また第一の実施形態において、シーケンス番号はIEEE802.11規格と同様に12ビットのフィールドサイズを前提としており、これにより0〜4095の番号を表現できる。シーケンス番号は、0を始点に1ずつ増えていき、4095の次は再び0に戻る。図８に示すように、受信端末はシーケンス番号「1」〜「8」のMPDUを受信する以前に、既にシーケンス番号「0」のMPDUを受信バッファ８０に格納していたとする。また、このシーケンス番号「0」のMPDUは、シーケンス番号「4095」のMPDUを受信するまで、受信バッファ８０から開放することが出来ない状況となっている。
そして本発明の第一の実施形態に従う場合、受信端末は次のように受信バッファ８０を管理する。すなわち、複数のMPDUがPSDUにアグリゲートされた物理フレームを受信した際に、FCS検査の結果、該PSDU内の先頭のMPDUが正常に受信されていれば、該MPDUのシーケンス番号情報を用いて受信バッファ８０を管理する。ここで、受信バッファ８０を管理することは、受信バッファ８０に既に格納されているMPDUのうち、解放可能なMPDUを決定して同受信バッファ８０から取り出すことを含む。
例えば図８のように、シーケンス番号「1」〜「8」のMPDUがアグリゲートされた物理フレームを当該受信端末が受信すると、まず先頭のMPDU（ここではシーケンス番号「1」のMPDUが該当）のFCSが正常であるか否かを判断する。先頭のMPDUのFCSが正常であるならば、当該受信端末は、該MPDUのシーケンス番号をBlock ACK Starting Sequence Controlの値とする。そして、当該受信端末は、受信バッファ８０に格納されているMPDUのうち、シーケンス番号「1」よりも番号が古いMPDUは該受信バッファ８０から解放可能であると判定し、これを該受信バッファ８０から取り出して上位層に渡す。ここで上位層とは、図１に示したMAC層１０２に対して上位のプロトコル階層をいう。本例では、シーケンス番号「0」と「1」のMPDU８２をリンク層１０３（より具体的にはLLC(Logical Link Control)）に渡す。かかる第一の実施形態によれば、上述したシーケンス番号「4095」のMPDUの受信を待つことなくシーケンス番号「0」のMPDUが受信バッファ８０から取り出されることから、受信バッファ効率、ひいてはMAC効率を向上できる。図８においては、Block ACK Starting Sequence Controlの値を「1」と認識していることから、受信バッファ８０内で「1」よりも前のシーケンス番号「0」のフレームをバッファから開放して、上位層に渡す。また、バッファの中身を全て開放した後、シーケンス番号「1」のフレームも、連続的に受信しているとみなして、受信バッファ８０から開放する。
図９および図１０は、受信バッファ管理の別の例を示している。図９に示すように、シーケンス番号「1」〜「8」のMPDUがPSDUにアグリゲートされた物理フレームを受信した端末は、FCS計算の結果、シーケンス番号「3」、「4」、「6」、「8」のMPDUを正常に受信できたと判断している。また、受信バッファ８０には、既にシーケンス番号「0」のMPDUがシーケンス番号「4095」のMPDUを待って格納されているとする。ここで、アグリゲートされた先頭のMPDUが誤っているため、受信端末内で連続してどこまで正常に受信できたかの情報は更新しない。このため、受信バッファ８０に格納されたMPDUをこの時点で上位層に渡すことはできない。
本発明の第一の実施形態に従う場合、圧縮ブロックACK９０のBlock ACK Starting Sequence Control９１には、複数MPDUがアグリゲートされたPSDU内で正常に受信された最初のMPDUのシーケンス番号の値を記載する。図９の例では、シーケンス番号「3」が最初に正常に受信されたMPDUである。Block ACK Bitmap９２は、シーケンス番号「3」を起点として作成する。また、図９の例では、アグリゲートされた先頭のMPDUが誤っていることから、圧縮ブロックACK９０を返信しても、受信バッファ８０からMPDUを開放しない。
圧縮ブロックACK９０を受信したデータ送信端末は、図１０に示すようにBlock ACK Starting Sequence Control９１の値よりも前のシーケンス番号のMPDUを全て再送対象とみなす。つまり、図９および図１０の例では、シーケンス番号「1」と「2」は送信に失敗したMPDUである。データ送信端末は、さらにBlock ACK Bitmap９２からシーケンス番号「5」と「7」も再送の必要があるとして、合計4個のMPDUをアグリゲートして送信する。この時、各MPDUのMACヘッダーの再送識別子(Retry Bit)には1がセットされる。
そして受信端末において、FCS計算の結果、受信した物理フレームのPSDUにアグリゲートされている先頭のMPDUが正常に受信出来ていると判定したならば、上述と同様にバッファ管理を実行し、バッファ管理用の情報を更新する。すなわち、Block ACK Starting Sequence Controlの値である「1」よりも前のシーケンス番号である「0」は、たとえ受信バッファ８０中で不連続に受信されている状況であっても、無条件で上位層に渡す。また、図１０に示すように、シーケンス番号「1」、「2」、「5」のMPDUも正常に受信されているため、シーケンス番号「1」〜「6」の連続するMPDUも全て受信バッファ８０から開放して上位層に渡すことができる。つまり、シーケンス番号「0」〜「6」の連続する７つのMPDU１１０が受信バッファ８０から開放され、上位層に渡される。ところで、図10の例のように、データ送信側が、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値から、送信に失敗したMPDUを判断して、再送用のデータをアグリゲートして送信する方法もあるが、宛先端末に対し、ブロックACK要求のみを送信し、正しいBlock ACK Starting Sequence Controlを通知する方法も適用可能である。この場合、図９、図１０の例では、Block ACK Starting Sequence Controlを「1」に指定したブロックACK要求を送信し、データ受信端末は、シーケンス番号「1」を始点とする圧縮ブロックACKを応答することになる。
更に、図７及び図８の例において、データ受信端末が送信した圧縮ブロックACKが、誤りによってデータ送信側に正常に通知されなかった場合を考える。図８の場合では、Block ACK Starting Sequence Controlが「1」の圧縮ブロックACKを送信しているが、この圧縮ブロックACKがもし誤れば、送信側は、一定時間後にタイムアウトを起こし、Block ACK Starting Sequence Controlが「1」のブロックACK要求を送信する。受信側は、ブロックACK要求のBlock ACK Starting Sequence Controlに基づいた圧縮ブロックACKを応答する。この時、データ受信側は再送されたブロックACK要求を受信しなくても、受信バッファ８０からフレームを開放し、上位層に渡すことができる。なぜなら、複数MPDUがアグリゲートされたPSDUを受信した際、その先頭MPDUに対するFCSが正常であれば、そのシーケンス番号をBlock ACK Starting Sequence Controlとみなして、受信バッファ管理を行なうことが可能だからである。ブロックACK要求がBlock ACK Starting Sequence Control「1」として再送された場合、図８の受信バッファ８０に格納されているシーケンス番号「3」、「4」のフレームは、Block ACK Starting Sequence Controlよりも新しいシーケンス番号であるため、バッファから開放せず、そのままにしておく。
また、図７の例で、もしアグリゲートされた全てのMPDUが誤っていたならば、データ受信側は、圧縮ブロックACKの返信はおろか、Block ACK Starting Sequence Controlの更新も出来ない。そのため、受信バッファ８０に既に格納されているシーケンス番号「0」のフレームもバッファから開放しない。一定時間後、データ送信側はタイムアウトを検出し、ブロックACK要求をBlock ACK Starting Sequence Controlとして送信する。データ受信側は、シーケンス番号「1」以降のMPDUをまだ1つも受信していないため、Block ACK Bitmapを全て0にした圧縮ブロックをBlock ACK Starting Sequence Control「1」として返信する。この時、受信バッファ８０に格納されているシーケンス番号「0」のフレームは、Block ACK Starting Sequence Controlの値よりも前の番号であるため、バッファから開放し、上位層に渡す。
ここで図１１を参照し、受信側のウィンドウサイズを考慮したバッファ管理手法について説明する。ウィンドウサイズとは、受信側で蓄積可能なMPDU数の最大値を意味している。図１１の例では、最大で8個のMPDUを格納保存としているため、ウィンドウサイズも8となる。図１１に示すように、受信バッファ８０において既にシーケンス番号「4095」と「0」のMPDU１１１が格納されていたとする。送信端末が再送を諦めてシーケンス番号「1」〜「8」の新しいMPDUをアグリゲートして送信し、かつこれらのMPDUが全て正常に受信されると、受信バッファ８０は溢れてしまう。
そこで、本発明の第一の実施形態に従う場合、受信バッファ８０が溢れないように、正常に受信された最後尾のMPDUのシーケンス番号とウィンドウサイズの値とに基づき、受信バッファ８０内で滞留が許容されないMPDUを判定し、これらを全て受信バッファ８０から取り出して上位層に渡す。具体的には、例えば最後尾のMPDUからウィンドウサイズだけ遡った時点よりも前のシーケンス番号を持つフレームを全て受信バッファ８０から取り出して上位層に渡す。図１１の例では、シーケンス番号「8」が正常に受信した最後尾のMPDUであるため、シーケンス番号「4095」と「0」のMPDU１１１に関しては、受信バッファ８０から無条件で開放する。従って、受信バッファ８０には、シーケンス番号「3」、「4」、「6」、「8」のMPDUのみが格納された状態になる。
ところで、図４のように、PSDUの先頭にアグリゲートした複数MPDUの長さ情報が記載されたフォーマットを用いて、複数宛先に対するMPDUをまとめて送信する場合、各受信端末が自身を宛先とするMPDUがどの部分から始まっているか認識可能な状況で、それぞれの先頭MPDUのシーケンス番号をBlock ACK Starting Sequence Controlとみなすことも出来る。すなわち、本発明の第一の実施形態は、単一宛先のみでなく、複数宛先に対するデータ送信時にも適用可能である。
以上説明したように、本発明の第一の実施形態によれば、PSDUにアグリゲートされた先頭のMPDUの正常受信を契機に、上述のように受信バッファ８０を管理することができる。これにより、受信バッファ８０においてMPDUが不所望に滞留することが防止され、受信バッファ効率、ひいてはMAC効率を向上できる。
（第二の実施形態）
本発明の第二の実施形態は、QoSデータフレームやポールフレームの送信スケジュール間隔が比較的長いと送信端末が判断した場合に、ブロックACK要求のみを送信することにより、受信端末に対して受信バッファをクリアさせるようにした通信装置に関する。
HCCAは従来のPCF(Point Coordination Function)の拡張に係わり、HCがポーリング(スケジューリング)の主体となる。通信を開始するにあたって、QSTAは、HCとTS(Traffic Stream)をセットアップする。TSとは、その端末がどういった種類のトラフィック (Voice over IPやFTP)を使用し、どれぐらいの帯域を必要としているかを示すデータの通り道のようなもので、TSPEC(Traffic Specification)によって一意に仕様が決まる。TSのセットアップ開始時には、QSTAからのTSPECが通知される。TSPECには、TSID(Traffic Stream Identifier)や、MAC-SAPで最低限保障したいスループットといった情報を含んでいる。TSは複数本張ることが可能で、HCはそれぞれのTSの要求を満たすようなスケジューリングを行う必要がある。具体的にHCがスケジューリングを行なう際は、Service Intervalと呼ばれるサービス間隔情報に基づいて、ある宛先に対するデータやポールの送信周期を決定する。QSTAは、HCから与えられたポーリングにより、TXOP期間を得、その間フレーム送信が可能になる。
ここで、図１２及び図１３を参照して、本発明の第二の実施形態を説明する。まず、図１２において、コンテンションフリーのHCCA期間内に、HC(Hybrid Coordinator)からQSTAに対するTXOP(チャネル使用期間)をTXOP期間Aとし、HCから他のQSTAに対するTXOP期間をTXOP期間B〜TXOP期間Zまで定める。HCCA期間の最後には、コンテンション期間の開始を示すCF-End(Contention Free End)フレーム３００をブロードキャストしている。図１２において、HCがシーケンス番号「1」〜「４」の連続した複数のMPDUをアグリゲートして送信し、シーケンス番号「1」のMPDUがFCS計算の結果、誤っていたとする。また、図１２及び図１３におけるQSTAの受信バッファ３０１は、最大5つのMPDUまで格納可能なサイズとしており、QSTAの受信バッファ３０１に既にシーケンス番号「0」のフレームが格納された状況とする。ここで、他のQSTAに対するTXOP期間が長くなると、MACフレームの生存可能時間を超過してしまうこともありうる。IEEE802.11e Draft 10.0の規定によれば、トラフィックの優先度に応じて、Delay Bound(遅延許容時間)が定められている。Delay Boundを超過したMACフレームは、再送が必要であったとしても、送信を諦めて廃棄される。図１２において、他のQSTAに対するTXOP期間が長くなり、再送の必要なシーケンス番号「1」のMPDUを廃棄した場合、QSTAの受信バッファ３０１に格納されているシーケンス番号「0」、「2」、「3」、「4」のMPDUはバッファから開放して上位層に渡すことが出来ない。この場合、受信バッファ３０１に格納された状態で「0」、「2」、「3」、「4」のフレームがDelay Boundを超過してしまう問題が発生しうる。また、データ送信側がDelay Boundを超過したシーケンス番号「1」のMPDUの再送を諦めて、シーケンス番号「5」〜「8」のMPDUを送信し、かつ本発明第１の実施形態で示したような複数のMPDUをアグリゲートしたPSDU内の先頭のMPDUのシーケンス番号をBlock ACK Starting Sequence Controlとみなすような方法を取らなければ、QSTAの受信バッファ３０１は開放されることなく溢れてしまい、受信バッファ３０１に格納する前に、「5」〜「8」のMPDUを廃棄しなくてはならないという問題も発生しうる。そこで、図１３に示すように、本発明の第二の実施形態においては、ブロックACKによるバースト的なフレーム送信の間隔が一定期間空いているならば、受信端末のバッファ３０１をクリアする目的で、ブロックACK要求を送信する。図１３では、シーケンス番号「4」までのフレームを受信バッファ３０１から開放するために、Block ACK Starting Sequence Controlを「5」としたブロックACK要求３０２を、2回目のTXOP期間A(QSTAへのデータ送信用TXOP)の最初に送信する。IEEE802.11e Draft 10.0の規定によれば、Block ACK Starting Sequence Controlよりも古いシーケンス番号を持つMACフレームは、全て受信バッファから開放して上位層に渡す必要があるため、シーケンス番号「0」、「2」、「3」、「4」のフレームを受信バッファ３０１から開放する。その後、シーケンス番号「5」〜「8」のMPDUが送信されたとしても、バッファが溢れる心配はない。
図１４乃至図１６を参照して本発明の第二の実施形態の別の例を説明する。まず図１４に示すように、HCがTXOP期間Aの間に、シーケンス番号「1」〜「4」のMPDUとBlock ACK Starting Sequence Controlが「1」のブロックACK要求をアグリゲートして送信したとする。アグリゲートの方法は、上述した第一の実施形態において図４及び図５に示したいずれかの方法によるものとする。ここで、シーケンス番号「1」のMPDUのFCSが異常であった場合、シーケンス番号「2」〜「4」のMPDUは受信側のバッファ内に格納される。QSTA1にデータを送信する周期は、QSTA1のサービスインターバル(Service Interval)に基づいているが、QSTA2に対するサービス開始時期が近づいてくると、QSTA1への送信をしばらく中断し、QSTA2に向けてデータ送信を開始する必要がある。このままでは、QSTA2の受信バッファに格納されているシーケンス番号「2」〜「4」のMPDUが無駄になってしまう。
そこで本発明の第二の実施形態では、残されたTXOP期間（チャネル使用許可期間）が少なく、誤ったMPDUを再送するための余裕が無い場合に、宛先端末の受信バッファを開放（クリア）し、全てのMPDUを上位層に渡すよう指令する目的でブロックACK要求のみを宛先端末に対して送信する。
図１４の例において、TXOP期間Aの終了間際に送信するブロックACK要求１２０のBlock ACK Starting Sequence Controlは「5」であり、このようなブロックACK要求１２０をHCが送信することによって、TXOP期間Aが与えられた宛先端末であるQSTA1は、シーケンス番号「2」〜「4」の全てのMPDUを上位層に渡すことになる。
TXOP期間Aに続くTXOP期間Bにおいても同様の例を示す。TXOP期間Bにおいて、HCはシーケンス番号「1001」〜「1003」のMPDUとBlock ACK Starting Sequence Controlが「1001」のブロックACK要求をアグリゲートしてQSTA2に送信する。QSTA2はQSTA1とは異なる別の宛先端末である。FCS計算の結果、シーケンス番号「1001」のMPDUが誤っていたとすると、QSTA2においてはシーケンス番号「1002」、「1003」のMPDUが受信バッファに格納され、上位層に渡すことは出来ない。ここで、ブロックACK１２１がHCに返信されると、HCはシーケンス番号「1001」のMPDUの再送が必要であると判断するが、予め決められたコンテンションフリーのHCCA期間が残り少なく、コンテンションが行われるEDCA期間の開始が近づいているため、再送処理を行う余裕がない。
一般に、HCCA期間ではスケジューリングの必要な高い優先度のトラフィックを送信し、EDCA期間（コンテンション期間）では比較的優先度が低いベストエフォート型のトラフィックを送信する。そのため、EDCA期間に切り替わると、HCはQSTA2とは異なる宛先、異なる優先度のデータをアグリゲートして送信する場合もあり得る。
そこで第二の実施形態では、EDCA期間が開始すると、HCは、QSTA2に対し受信バッファをクリアさせるためのブロックACK要求１２２を最も高い優先度で送信する。EDCAでは、優先度毎に複数のAC(Access Category)を設け、それらが並列してキャリアセンス・バックオフ制御を行う。ACはそれぞれ独自のIFS(AIFS)期間を持ち、高優先度のACになるほど短い時間のキャリアセンスでフレームの送信開始を可能とする。MAC内部で複数のAC間の送信処理が同時に起こった場合は、優先度の高いACのフレームを送信し、低優先度のACはCW(コンテンションウィンドウ)を増やした後、再度ランダムなバックオフ待ち時間に入る。図１４の例では、EDCA期間の開始直後に、QSTA2に対し受信バッファをクリアさせるためのブロックACK要求１２２を、最も高い優先度のACの送信キューの先頭に入れる。その結果、HCがEDCA期間でデータを他の端末に向けて送信する前に、QSTA2へのブロックACK要求１２２を送信することが可能である。したがって、QSTA2の受信バッファに格納された、シーケンス番号「1002」、「1003」のMPDUは「1001」が来るのを待たずに、上位層に渡される。ここで、受信バッファをクリアさせるためのブロックACK要求１２２のBlock ACK Starting Sequence Controlの値は、送信側で適切な値を指定することが好ましい。例えば、受信側のバッファに格納されているMPDUの生存時間を超過しそうであると判断した場合、シーケンス番号が不連続な状態であってもこれらが上位層に渡されるようにする。
図１５は、ブロックACK要求を含まない状態で、複数のMPDUをアグリゲートして送信する場合への適用例を示している。QSTA1に対し受信バッファをクリアさせるよう、HCは明示的なブロックACK要求１３０を送信している。同様に、QSTA2に対しては明示的なブロックACK要求１３１を送信している。一方、図１６は、IEEE802.11eのブロックACKへの適用例を示している。QSTA1に対し受信バッファをクリアさせるよう、HCはブロックACK要求１４０を送信している。同様に、QSTA2に対しては明示的なブロックACK要求１４１を送信している。
以上説明した本発明の第二の実施形態によれば、HCCA期間が残り少なく、EDCA期間の開始が近づいているために再送処理を行う余裕がない場合に、受信バッファクリアのためのブロックACK要求がHCから送信されることから、受信バッファにおいてMPDUが不所望に滞留することが防止され、受信バッファ効率、ひいてはMAC効率を向上できる。なお、第二の実施形態に係る発明は、HCからQSTAへのダウンリンクの送信だけでなく、QSTAからHCへのアップリンク伝送にも適用可能であることは言うまでもない。
また、第二の実施形態に係る発明は、コンテンションベースのQoSアクセス制御方式であるEDCA期間中におけるデータ送信にも適用可能である。EDCAを使用した場合、HCCAのように厳密なスケジュール管理を行なうことは出来ない。そのため、データを送信する端末は、AC毎の送信用キューの中身を確認し、現在の宛先に対するデータを送信する機会がしばらくないと判断した場合、該TXOP期間の最後に受信バッファを開放するためのブロックACK要求を送信することでバッファ管理を適切に行なうことが出来る。送信用キューからは、FIFO(First In First Out)のいわゆる先入れ先出しの原理でMACフレームを取り出して送信対象とするため、キューの先頭から検索して、該宛先に対するフレームが後方に格納されている程、送信する時期も後ろということになる。あるいは、新たなEDCA期間が開始された時点で、前のEDCA期間終了から一定時間経過していれば、TXOP期間の初めに、受信バッファを開放するためのブロックACK要求を送信する方法でも良い。ところで、IEEE802.11 - Standard 1999の規定によれば、パワーセーブを目的として、データやマネージメントフレームに付加されるMACヘッダ内のFrame Control(フレーム制御)フィールド内に、1ビットのMore Dataフラグが存在する。アクセスポイントから見て、該端末（ステーション）に対する後続のデータやマネージメントフレームが存在する場合、このフラグに1をセットする。後続のフレームが存在しない場合、0をセットする。フレームを受信した端末は、More Dataフラグが0にセットされていれば、パワーセーブ状態に移行する。このMore Dataフラグを使用して、データフレーム受信端末は、値が1になっている間、受信バッファをIEEE802.11e Draft 10.0のブロックACKの手続きに従って管理し、フラグが0になった時、しばらく自身宛のデータが送信されて来ないと判断して受信バッファからフレームを開放して上位層に渡す方法も、EDCA期間、及びHCCA期間双方におけるデータ送信に適用可能である。本発明の第二の実施形態によれば、受信バッファにおいてMPDUが不所望に滞留することが防止され、受信バッファ効率、ひいてはMAC効率を向上できる。
（第三の実施形態）
本発明の第三の実施形態は、ブロックACKに含まれるBlock ACK Bitmapの作成方法に関する。第一の実施形態で説明した圧縮ブロックACKのBlock ACK Bitmapは、その最大長が64ビットであるが、Block ACK Bitmapを受信バッファのサイズに一致させることにより、圧縮ブロックACKのサイズを更に縮小することができる。例えば、受信バッファのサイズを8MPDU分に定めた場合を想定する。この場合において、送信端末が送信する物理フレームにおいて単一のPSDUにアグリゲート可能な最大MPDU数は8個であり、Block ACK Bitmapのサイズは8ビットである。
例えば図１７に示すように、送信端末が、連続したシーケンス番号「1」〜「8」のMPDUをアグリゲートして送信し、受信側のFCS検査によってシーケンス番号「1」、「2」、「5」、「7」のMPDUの誤りが検出されたとする。ここで、受信端末が圧縮ブロックACKのためにBlock ACK Bitmap１５０を作成する場合、Block ACK Starting Sequence Control「3」を起点にして、このBlock ACK Bitmap１５０は「11010100」のように表される。前述したように、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値は、複数MPDUがアグリゲートされたPSDUの中で、正常に受信された最初のMPDUのシーケンス番号に等しい。Block ACK Bitmap１５０を有する圧縮ブロックACKを受信した送信端末は、送信に失敗したシーケンス番号「1」、「2」、「5」、「7」のMPDUが単一PSDU内にアグリゲートされた物理フレームを送信（再送）する。この場合、PSDU内にアグリゲートされたMPDUのシーケンス番号は不連続となっている。この再送によっても、同図に示すようにやはり受信端末側ではシーケンス番号「7」のMPDUが誤っており、Block ACK BitmapをMPDUの相対位置関係から作成する場合、ブロックACKのBlock ACK Starting Sequence Control１５１は「1」、Block ACK Bitmap１５２は「11100000」のように前から詰める形で作成する。
Block ACK BitmapをMPDUの相対位置関係から作成する場合の、フレーム交換の様子を図１８に示す。データ送信側では、複数のMPDUが1つのPSDUにアグリゲートされた物理フレーム１６０を送信する。この時、該物理フレーム１６０にはブロックACK要求は含まれないものとする。ここで、受信側端末におけるFCS計算の結果、シーケンス番号「1」、「3」が誤っていたとする。受信端末は、正常に受信できた最初のMPDUのシーケンス番号が「2」であることから、Block ACK Starting Sequence Controlの値を「2」に設定し、「2」を起点とするMPDUの相対的な位置関係からBlock ACK Bitmapを作成して圧縮ブロックACK１６１を送信する。すなわち、図１８の例では、Block ACK Bitmapは「10100000」のように設定される。データ送信端末は、圧縮ブロックACK１６１を受信した後、キャリアセンスとバックオフを行なってから、再送の必要なシーケンス番号「1」と「3」をアグリゲートして物理フレーム１６２を送信する。尚、図１８の例ではコンテンションベースのアクセス制御方式を想定しているが、コンテンションフリーのアクセス制御方式にも本発明を適用して実施可能であることは言うまでも無い。その後、受信側でシーケンス番号「1」のMPDUが誤っている場合、Block ACK Starting Sequence Controlを「3」に、Block ACK Bitmapを「10000000」のように設定して圧縮ブロックACK１６３を送信する。ここで、圧縮ブロックACK１６３が伝播路上で誤った場合、データ送信側では、キャリアセンスとバックオフを行なった後、Block ACK Starting Sequence Controlを「1」にしてブロックACK要求１６４を送信する。受信端末は、Block ACK Starting Sequence Controlが、自身が受信した中で最も新しいシーケンス番号、つまり図１８の例では「4」よりも小さいことから、前回送信した圧縮ブロックACKの内容をそのまま鸚鵡返し的に返信する（圧縮ブロックACK１６５）。圧縮ブロックACK１６５のBlock ACK Starting Sequence Controlは「3」、Block ACK Bitmapは「10000000」である。その後、データ送信端末は、シーケンス番号「1」のMPDUが誤っていると判断し、該MPDUを含む物理フレーム１６６を再送した後、圧縮ブロックACK１６７を受信している。圧縮ブロックACKを返信する際は、IEEE802.11eのブロックACKのように過去の受信履歴を検索することはせず、過去最大1回分のPSDU受信のステータスを反射的に応答する。送信側では、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値を元に、再送すべきMPDUを決定する。
図１９は、Block ACK BitmapをMPDUの相対位置関係から作成するもう1つの例である。図１８の例と同様に、データ送信端末はシーケンス番号「1」〜「4」のMPDUがアグリゲートされた物理フレーム１７０を送信し、圧縮ブロックACK１７１を受信し、シーケンス番号「1」、「3」のMPDUがアグリゲートされた物理フレーム１７２を再送する。ここで、シーケンス番号「1」と「3」のMPDUをアグリゲートした物理フレーム１７２が衝突などの原因で壊れてしまった場合、受信端末は1つもMPDUを受信していないことから、Block ACK Bitmapを新たに作成できない。したがって、送信端末において圧縮ブロックACKを待ち受ける期間のタイムアウトが発生し、該送信端末はBlock ACK Starting Sequence Controlが「1」に設定されたブロックACK要求１７３を送信することになる。このブロックACK要求１７３を受信した受信端末は、そのBlock ACK Starting Sequence Controlが自身の受信した最新のシーケンス番号よりも前の番号であるため、前回送信した圧縮ブロックACKの内容を、そのまま反射的に送り返す。この例では、Block ACK Starting Sequence Controlが「2」であって、「2」を起点とするMPDUの相対的な位置関係からBlock ACK Bitmapが「10100000」のように設定された圧縮ブロックACK１７４を送信する。
ここで、送信端末は、受信した圧縮ブロックACK１７４のBlock ACK Starting Sequence Controlよりも前のシーケンス番号のMPDUは全て送信に失敗したとみなすため、シーケンス番号「1」のMPDUは再送対象であると判断できる。しかし、Block ACK Bitmapは、MPDUの相対位置関係から作成されているため、Block ACK Starting Sequence Control と比べて等しい、あるいは大きいシーケンス番号「3」のMPDUは、Block ACK Bitmapの「10100000」という情報から、正常に送信されたものと送信端末により誤って解釈されてしまう。結果として、次の送信タイミングでシーケンス番号「1」のMPDUは再送されるものの、シーケンス番号「3」のMPDUは含まれない（物理フレーム１７５）。
本発明の第三の実施形態は、このように本来は再送されるべきMPDUが不適切に再送対象から除外されてしまうという問題に、以下に説明する３種類の方法のいずれかによって対処する。
図２０を参照しながら、まずは第１の方法について説明する。複数のMPDUをアグリゲートして送信した端末は、シーケンス番号を情報として記憶しておく。
最初に、連続したシーケンス番号「1」〜「4」のMPDUがアグリゲートされた物理フレーム１８０を送信し、送信端末はこれら「1」、「2」、「3」、「4」のシーケンス番号をすべて記憶しておく。その後、Block ACK Starting Sequence Controlの値（始点シーケンス制御値）が「2」である圧縮ブロックACK１８１を受け取る。ここで送信端末は、該Block ACK Starting Sequence Controlの値について、この値に基づいて再送すべきフレームを決定してよいか否かを判断する。ここでは、受信した圧縮ブロックACK１８１のBlock ACK Starting Sequence Controlの値「2」は、記憶しているシーケンス番号「2」と一致するので、この値を採用する。言い替えれば、圧縮ブロックACK１８１に基づいて再送すべきフレームを決定する。これにより送信端末は、シーケンス番号「1」、「3」のMPDUを再送対象としてアグリゲートして送信する。また、送信端末はシーケンス番号の記憶情報を「1」、「3」のように更新する。これらMPDUがアグリゲートされた物理フレーム１８２の全体が誤った場合、ブロックACK要求１８３の送信の後、送信端末はBlock ACK Starting Sequence Controlが「2」である圧縮ブロックACK１８４を受信する。ここで、シーケンス番号「2」はデータ送信端末がアグリゲートした「1」、「3」のシーケンス番号のいずれとも一致しない。このため送信端末は、圧縮ブロックACK１８４について、これは過去に受信した圧縮ブロックACK１８１と同一である、すなわち圧縮ブロックACK１８１の再送であると判断し、送信端末が送信した全てのMPDU（ここではシーケンス番号「1」、「3」のMPDU）に誤りが生じたものと判断する。つまり、先の例とは異なり、圧縮ブロックACK１８１に基づいて再送すべきフレームを決定しない。その代わりに、送信端末は、これらシーケンス番号「1」、「3」を再びアグリゲートして送信し、シーケンス番号の情報として「1」、「3」を記憶する。ここで、Block ACK Starting Sequence Controlが「1」の圧縮ブロックACK１８６を受信すれば、その情報は正しいと認識し、送信端末は送信に成功したことを知る。
次に、第２の方法は、圧縮ブロックACKに通し番号を割り当てることで、過去のブロックACKフレームの情報を間違って取り扱わないようにするというものである。IEEE802.11e Draft 10.0によると、ブロックACK要求フレーム及びブロックACKフレームには、Block ACK Controlと呼ばれる16ビットのフィールドが存在する。この中で優先度を指定するためのTIDフィールドが4ビット分存在し、残りは予約されている部分である。そこで、図２１（ａ）に示すように、4ビットのBlock ACK ID（送達確認識別子）フィールド１９０を新たに定義する。
図２１（ｂ）に示すように、複数MPDUがアグリゲートされた物理フレームを受信し、Block ACK Bitmapを新しく作成する度に、Block ACK IDフィールド１９０の値を更新する。尚、Block ACK IDフィールド１９０のサイズは4ビットとしているが、このサイズに限定しなくても良いことは言うまでもない。
図２２に、Block ACK IDフィールドを適用した場合のフレーム交換例を示す。まず受信端末は、シーケンス番号「1」〜「4」のMPDUがアグリゲートされた物理フレーム２００を受信し、圧縮ブロックACK２０１を返信する際に、Block ACK IDを0にセットしたとする。データ送信側は、圧縮ブロックACK２０１を受信し、該圧縮ブロックACK２０１内のBlock ACK IDの値を保存する。その後、シーケンス番号「1」、「3」のMPDUを再送としてアグリゲートするが、ここで、物理フレーム２０２全体が壊れたとする。データ送信端末はブロックACK要求２０３を送信した後、Block ACK IDが0の圧縮ブロックACK２０４を受信すると、該圧縮ブロックACK２０４のフレームは過去に受信した内容と同一であると認識することができ、全てのMPDU（すなわち物理フレーム２０２にアグリゲートされた全てのMPDU）は送信に失敗したとみなす。
その後、シーケンス番号「1」と「3」を再送する（物理フレーム２０５）。受信側端末は圧縮ブロックACK２０６を新たに作成する際、Block ACK IDの値を1に更新する。データ送信端末は、Block ACK IDが更新されていることから、この圧縮ブロックACK２０６の情報は正しいと判断する。尚、Block ACK IDは図２１（ａ）の例の場合、4ビットであるため、7の次は0に戻る（但し、4ビットのうち、1ビットはリザーブ）。
そして第３の方法は、データ送信端末が圧縮ブロックACKを受信した際、その情報の全て、あるいはフレームそのもののコピーを保存しておくというものである。この第３の方法の適用は、前述の第１の方法と概念的には同一であり、圧縮ブロックACKのビット列を照らし合わせることで、過去に受信したものかどうかの判断を行なう。
ところで、Block ACK BitmapをMPDUの相対位置関係から作成する方法の他に、シーケンス番号の位置と対応させる方法もある。図２３を参照してこの方法を説明する。同図に示すように、データ送信端末がシーケンス番号「1」〜「8」のMPDUをアグリゲートして送信したとする。受信端末によるFCS計算の結果、シーケンス番号「1」、「2」、「5」、「7」が誤っていた場合、Block ACK Starting Sequence Control２１０を「3」に設定し、Block ACK Bitmap２１１を「11010100000…」のように設定する。ここで、Block ACK Bitmap２１１は、64ビットの固定長にしている。IEEE802.11e Draft 10.0によれば、ブロックACKによる伝送で連続的に送信可能な最大のMSDU数は64となっており、フラグメント化をしない前提で、上述した第一の実施形態のように64ビットまで圧縮することが可能である。その後、データ送信端末が、圧縮ブロックACKの内容を元に、シーケンス番号「1」、「2」、「5」、「7」のMPDUをアグリゲートして送信する。
そして受信側では、シーケンス番号「7」のMPDUが誤っていたとする。Block ACK Starting Sequence Control２１２の値は、アグリゲートされた先頭のMPDUのシーケンス番号すなわち「1」であり、「1」を始点として、各MPDUの受信ステータスをビットマップに変換していく。すなわち、シーケンス番号「1」、「2」、「5」を正常に受信しているため、Block ACK Bitmap２１３は「11001000…」のように表現される。この時点で受信端末が受け取った物理フレームの中には、「3」や「4」のシーケンス番号のMPDUが含まれておらず、Block ACK Bitmap２１３において対応する部分のビットは、0のままにしておく。また、シーケンス番号「7」のMPDUも受信に失敗したため、該当部分のビットは0のままである。尚、ビット構成は、送受信端末間で相互に認識されている場合、正論理の代わりに負論理を用いても良い。
図２４に、Block ACK Bitmapをシーケンス番号位置と対応させて作成する場合のフレーム交換例を示す。データ送信端末は、シーケンス番号「1」〜「4」のMPDUをアグリゲートして物理フレーム２２０を送信する。受信側では、例えばシーケンス番号「2」と「4」を正常に受信しており、Block ACK Starting Sequence Controlを「2」に、Block ACK Bitmapを「10100000…」に設定して、圧縮ブロックACK２２１を返信する。データ送信端末は、シーケンス番号「1」、「3」のMPDUが誤っているため、これらの再送に係るMPDUがアグリゲートされた物理フレーム２２２を送信する。例えば衝突などが原因で物理フレーム２２２の全体が壊れており、Block ACK Starting Sequence Controlが「1」のブロックACK要求２２３が送信される。受信側は、前回返信した内容と同じ状態で圧縮ブロックACK２２４を返信する。送信端末は、圧縮ブロックACK２２４のBlock ACK Starting Sequence Control「2」よりも前の「1」のMPDUは送信に失敗したとみなす。ここまでは、MPDUの相対位置関係からBlock ACK Bitmapを作成する場合と同様である。しかし、Block ACK Starting Sequence Controlが「1」で、Block ACK Bitmapが「10100000…」のようになっている場合、この情報はシーケンス番号の位置を元に作成されているため、シーケンス番号「3」に対応する部分のビット情報は0であり、送信に失敗したと判断できる。よって、再送に係るシーケンス番号「1」、「3」のMPDUをアグリゲートして物理フレーム２２５を送信する。
以上のように、圧縮ブロックACKにおけるBlock ACK Bitmapの作成は、大きく分けて2つの方法で実現することが可能である。Block ACK Bitmapがどちらの形式で作成されているかは、送受信端末間がネゴシエーションを通じて予め認識する他、図２１に示したBlock ACK Controlフィールド１９０のReservedフィールドを1ビット分使用して、識別させることで適宜対応することも可能である。
以上説明した本発明の実施形態によれば、PSDUにアグリゲートされた先頭のMPDUの正常受信を契機に、受信端末内の受信バッファを管理することができる。これにより、受信バッファにおいてMPDUが不所望に滞留することが防止され、受信バッファ効率、ひいてはMAC効率を向上できる。また、HCCA期間が残り少なく、EDCA期間の開始が近づいているために再送処理を行う余裕がない場合に、受信バッファクリアのためのブロックACK要求がHCから送信されることから、受信バッファにおいてMPDUが不所望に滞留することが防止され、同様の効果が得られる。さらに、部分送達確認ビットマップの長さをアグリゲートされたMACフレームの数に併せて可変長にする場合、再送が発生して、送信端末側で、過去の部分送達確認フレームを間違って解釈する問題を解決することも可能である。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の実施形態に係る通信装置の構成を示すブロック図 HCCA(Hybrid coordination function Controlled Channel Access)における即時型ブロックACKのシーケンス例を示す図 IEEE802.11eのブロックACKによるデータ伝送を行なう際に受信側で行われるバッファ管理を説明するための図 複数のMPDUが1つのPSDUにアグリゲートされた物理フレームのフォーマットの一例を示す図 複数のMPDUが1つのPSDUにアグリゲートされた物理フレームのフォーマットの別の例を示す図 圧縮ブロックACKのフォーマットを示す図 単一のPSDUに複数のMPDUがアグリゲートされ、かつブロックACK要求を含まない物理フレームの送信例を示す図 本発明の第一の実施形態に係る受信バッファ管理を説明するための図 受信バッファ管理の別の例を示す図 受信バッファ管理の別の例を示す図 受信側のウィンドウサイズを考慮したバッファ管理手法を説明するための図 本発明の第二の実施形態に係る受信バッファクリアの例を説明するための図 本発明の第二の実施形態に係る受信バッファクリアの一例を示す図 本発明の第二の実施形態に係る受信バッファクリアの別の例を示す図 本発明の第二の実施形態に係る受信バッファクリアのさらに別の例を示す図 本発明の第二の実施形態に係る受信バッファクリアのさらに別の例を示す図 ブロックACKビットマップの作成例を示す図 ブロックACKビットマップに基づく再送手順を示す図 再送フレームの誤りを示す図 本発明の第三の実施形態に係るブロックACK制御例を示す図 本発明の第三の実施形態に係るブロックACK制御フィールドを示す図 本発明の第三の実施形態に係るブロックACK制御の別の例を示す図 シーケンス番号位置に対応させてブロックACKビットマップを作成する場合を示す図 シーケンス番号位置に対応するよう作成されたブロックACKビットマップに基づく再送手順を示す図
符号の説明
１００…通信装置；
１０１…物理層(PHY)；
１０２…ＭＡＣ（媒体アクセス制御）層；
１０３…リンク層；
１０４…アンテナ；
１０５…アグリゲーション処理部；
１０６…キャリアセンス制御部；
１０７…再送制御部；
１０９…第一種の物理層プロトコル処理部；
１１０…第二種の物理層プロトコル処理部

Claims (7)

  1. チャネル使用許可期間を獲得し、該チャネル使用許可期間において宛先の通信装置に対し物理フレームを送信する物理フレーム送信手段と、
    前記チャネル使用許可期間の終了間際に、前記宛先の通信装置の受信バッファに既に記憶されているＭＡＣフレームを上位層に渡すよう指令する目的で送達確認要求フレームを該宛先の通信装置に対し送信する送達確認要求フレーム送信手段とを具備する通信装置。
  2. 前記送達確認要求フレーム送信手段は、前記物理フレーム送信手段による物理フレームの送信間隔に基づいて、前記送達確認要求フレームを送信すべきか否かを判定する請求項１に記載の通信装置。
  3. 前記送達確認要求フレーム送信手段は、コンテンションフリー期間に続くコンテンション期間の開始直後に最も高い優先度で前記送達確認要求フレームを送信する請求項１に記載の通信装置。
  4. 前記物理フレームには、各々がシーケンス番号を有する複数のＭＡＣフレームがアグリゲートされており、
    送信された物理フレームにアグリゲートされている複数のＭＡＣフレームのシーケンス番号を記憶する記憶手段と、
    送信された物理フレームに応答し、始点シーケンス制御値を有する送達確認フレームを受信する受信手段と、
    受信された送達確認フレームの前記始点シーケンス制御値が、前記記憶手段に記憶されたシーケンス番号のいずれかに一致するか否かを判定する判定手段と、
    前記判定手段による判定結果に基づいて再送すべきＭＡＣフレームを決定し、該ＭＡＣフレームがアグリゲートされた物理フレームを再送する再送手段とを具備する請求項１に記載の通信装置。
  5. 前記物理フレームには、複数のＭＡＣフレームがアグリゲートされており、
    送信された物理フレームに応答し、送達確認識別子を有する送達確認フレームを受信する受信手段と、
    受信された送達確認フレームの送達確認識別子を記憶する記憶手段と、
    前記受信手段により第１の送達確認フレームを受信したならば、該第１の送達確認フレームの送達確認識別子が、前記記受信手段により既に受信され、かつ前記記憶手段に記憶されている第２の送達確認フレームの送達確認識別子に一致するか否かを判定する判定手段と、
    前記判定手段による判定結果に基づいて再送すべきＭＡＣフレームを決定し、該ＭＡＣフレームがアグリゲートされた物理フレームを再送する再送手段とを具備する請求項１に記載の通信装置。
  6. 前記物理フレームには、複数のＭＡＣフレームがアグリゲートされており、
    送信された物理フレームに応答し、送達確認ビットマップを有する送達確認フレームを受信する受信手段と、
    受信された送達確認フレームの送達確認ビットマップを記憶する記憶手段と、
    前記受信手段により第１の送達確認フレームを受信したならば、該第１の送達確認フレームの送達確認ビットマップが、前記記受信手段により既に受信され、かつ前記記憶手段に記憶されている第２の送達確認フレームの送達確認ビットマップに一致するか否かを判定する判定手段と、
    前記判定手段による判定結果に基づいて再送すべきＭＡＣフレームを決定し、該ＭＡＣフレームがアグリゲートされた物理フレームを再送する再送手段とを具備する請求項１に記載の通信装置。
  7. チャネル使用許可期間を獲得し、該チャネル使用許可期間において宛先の通信装置に対し物理フレームを送信する物理フレーム送信ステップと、
    前記チャネル使用許可期間の終了間際に、前記宛先の通信装置の受信バッファに既に記憶されているＭＡＣフレームを上位層に渡すよう指令する目的で送達確認要求フレームを該宛先の通信装置に対し送信する送達確認要求フレーム送信ステップとを含む通信方法。
JP2004304475A 2004-10-19 2004-10-19 通信装置および通信方法 Active JP4130648B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2004304475A JP4130648B2 (ja) 2004-10-19 2004-10-19 通信装置および通信方法
US11/201,198 US7746861B2 (en) 2004-10-19 2005-08-11 Communication apparatus and method
CN2005101076140A CN1764157B (zh) 2004-10-19 2005-09-29 通信设备和方法
CNA2009100017162A CN101453755A (zh) 2004-10-19 2005-09-29 通信设备和方法
US12/558,085 US7848330B2 (en) 2004-10-19 2009-09-11 Communication apparatus and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004304475A JP4130648B2 (ja) 2004-10-19 2004-10-19 通信装置および通信方法

Publications (3)

Publication Number Publication Date
JP2006121199A JP2006121199A (ja) 2006-05-11
JP2006121199A5 JP2006121199A5 (ja) 2006-10-26
JP4130648B2 true JP4130648B2 (ja) 2008-08-06

Family

ID=36180684

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004304475A Active JP4130648B2 (ja) 2004-10-19 2004-10-19 通信装置および通信方法

Country Status (3)

Country Link
US (2) US7746861B2 (ja)
JP (1) JP4130648B2 (ja)
CN (2) CN1764157B (ja)

Families Citing this family (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4012172B2 (ja) * 2004-05-28 2007-11-21 株式会社東芝 無線通信装置及び無線通信方法
JP4440037B2 (ja) * 2004-08-11 2010-03-24 株式会社東芝 通信装置及び通信方法
JP4331088B2 (ja) 2004-11-01 2009-09-16 株式会社東芝 通信装置および通信方法
US8830846B2 (en) * 2005-04-04 2014-09-09 Interdigital Technology Corporation Method and system for improving responsiveness in exchanging frames in a wireless local area network
US8050179B2 (en) * 2005-09-22 2011-11-01 Freescale Semiconductor, Inc. Method and system for acknowledging frames in a communication network
US7729236B2 (en) * 2005-11-10 2010-06-01 Nokia Corporation Use of timing information for handling aggregated frames in a wireless network
US7706397B2 (en) * 2006-03-31 2010-04-27 Intel Corporation Apparatus and method of controlling transmission in reverse direction
EP2008391B1 (en) * 2006-04-19 2014-01-15 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for improved data communication in cellular access systems
WO2007131347A1 (en) * 2006-05-11 2007-11-22 Nortel Networks Limited Media access control protocol for multi-hop network systems and method therefore
US8879448B2 (en) * 2006-12-22 2014-11-04 Samsung Electronics Co., Ltd. Apparatus for controlling power of WiMedia media access control device and method using the same
JP4284353B2 (ja) * 2006-12-26 2009-06-24 株式会社東芝 無線通信装置
EP2127258A1 (en) * 2007-01-22 2009-12-02 Koninklijke Philips Electronics N.V. Recalculating airtime quota in wlan to use up bandwidth
JP4882856B2 (ja) * 2007-05-07 2012-02-22 沖電気工業株式会社 通信システム、通信装置、通信方法及び通信プログラム
JP2009049461A (ja) * 2007-08-13 2009-03-05 Toshiba Corp 無線通信装置
US7574539B2 (en) * 2007-08-30 2009-08-11 Intel Corporation Dynamic A-MSDU enabling
JP2009088915A (ja) * 2007-09-28 2009-04-23 Sony Corp 無線送信装置、無線送信方法、無線通信システム及びプログラム
TWI408935B (zh) * 2007-12-21 2013-09-11 Inst Information Industry 封包傳送排程系統、方法與記錄媒體
US8484269B2 (en) 2008-01-02 2013-07-09 At&T Intellectual Property I, L.P. Computing time-decayed aggregates under smooth decay functions
US8391164B2 (en) 2008-01-02 2013-03-05 At&T Intellectual Property I, L.P. Computing time-decayed aggregates in data streams
US8416803B1 (en) 2008-02-14 2013-04-09 Wilocity, Ltd. Low latency interconnect bus protocol
WO2009136724A2 (en) * 2008-05-09 2009-11-12 Lg Electronics Inc. Device and method for multicast in wireless local access network
US9179473B2 (en) * 2008-05-27 2015-11-03 Fujitsu Semiconductor Limited Receiving and processing protocol data units
US8706878B1 (en) 2008-08-21 2014-04-22 United Services Automobile Association Preferential loading in data centers
US9477615B1 (en) * 2008-08-26 2016-10-25 Qualcomm Incorporated Bi-directional low latency bus mode
US8386667B2 (en) * 2008-08-26 2013-02-26 Sun Management, Llc Techniques for managing the transmission and reception of data fragments
TWI383607B (zh) * 2008-12-10 2013-01-21 Inst Information Industry 用於一無線通訊裝置之資料排程模組、方法及其電腦程式產品
US8553547B2 (en) * 2009-03-30 2013-10-08 Broadcom Corporation Systems and methods for retransmitting packets over a network of communication channels
US8289895B2 (en) 2009-04-24 2012-10-16 Research In Motion Limited Relay link HARQ operation
CN103916178A (zh) * 2009-09-29 2014-07-09 北京新岸线移动多媒体技术有限公司 数据发送和数据接收方法
CN103916386B (zh) * 2009-09-29 2017-02-22 北京新岸线移动多媒体技术有限公司 数据发送和数据接收方法
CN101714896B (zh) * 2009-09-29 2016-11-02 北京新岸线移动多媒体技术有限公司 通信方法
JP5735550B2 (ja) 2010-03-09 2015-06-17 サムスン エレクトロニクス カンパニー リミテッド 端末及びアクセスポイント、その通信方法、並びにコンピュータで読み取り可能な記録媒体
KR101778958B1 (ko) * 2010-03-09 2017-09-18 삼성전자주식회사 멀티 유저의 전력 절감을 위한 단말 및 액세스 포인트의 통신 방법
US9668283B2 (en) 2010-05-05 2017-05-30 Qualcomm Incorporated Collision detection and backoff window adaptation for multiuser MIMO transmission
US9232543B2 (en) * 2010-07-07 2016-01-05 Samsung Electronics Co., Ltd. Method and system for communication in multi-user multiple-input-multiple-output wireless networks
CN102547864A (zh) * 2010-12-27 2012-07-04 北京中电华大电子设计有限责任公司 一种串口802.11n无线网卡芯片接收数据的方法
CN102547847B (zh) * 2010-12-29 2015-06-03 迈普通信技术股份有限公司 一种无线聚合帧的接收处理方法及接收装置
US20140056286A1 (en) * 2011-02-11 2014-02-27 Panasonic Corporation Wireless communication system and wireless slave and master units used therein
US20120320772A1 (en) * 2011-06-14 2012-12-20 Qualcomm Incorporated Communication devices for transmitting data based on available resources
US8755403B2 (en) * 2011-11-09 2014-06-17 Hitachi, Ltd. Block acknowledgement for wireless communication methods, apparatuses and systems
US9363707B2 (en) 2011-12-29 2016-06-07 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
US8948089B2 (en) * 2012-01-11 2015-02-03 Intel Corporation Device, system and method of communicating aggregate data units
US9253290B2 (en) * 2012-02-29 2016-02-02 Qualcomm Incorporated Apparatus and methods for block acknowledgment compression
US20130223338A1 (en) * 2012-02-29 2013-08-29 Qualcomm Incorporated Apparatus and methods for block acknowledgment compression
US20130301625A1 (en) * 2012-05-11 2013-11-14 Cambridge Silicon Radio Limited Aggregation of information units in a wireless network
CN104756584A (zh) 2012-10-29 2015-07-01 高通股份有限公司 时分多址网络中的设备注册和探测
US9781627B2 (en) 2013-04-08 2017-10-03 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
JP5634572B2 (ja) * 2013-07-23 2014-12-03 株式会社東芝 無線通信端末
KR102091138B1 (ko) * 2013-09-12 2020-03-19 삼성전자주식회사 무선 네트워크 환경에서 데이터를 전송하는 방법 및 데이터 전송 장치
US9565594B2 (en) * 2014-03-28 2017-02-07 Qualcomm Incorporated Link aggregation in wireless local area networks
US9575064B2 (en) 2014-09-02 2017-02-21 Perkinelmer Health Sciences, Inc. Methods relating to testing for lysosomal storage disorders
US20160080115A1 (en) * 2014-09-12 2016-03-17 Samsung Electronics Co., Ltd. Methods for efficient acknowledgement in wireless systems
CN104407626B (zh) * 2014-10-16 2017-09-22 中国科学院深圳先进技术研究院 一种相控阵天线的控制方法、装置、系统及频谱检测设备
KR102009848B1 (ko) 2014-12-01 2019-08-12 엘지전자 주식회사 무선랜에서 데이터 프레임의 재전송 없이 에러를 회복하는 방법 및 장치
CN111885738B (zh) 2014-12-18 2022-09-02 华为技术有限公司 一种获取站点设备请求的方法、接入点设备及站点设备
EP3340719B1 (en) * 2015-08-21 2020-03-04 Nippon Telegraph And Telephone Corporation Wireless communication system and wireless communication method
CN108029039B (zh) * 2015-09-11 2022-05-13 索尼公司 信息处理设备、通信系统和信息处理方法
US10142253B2 (en) * 2015-11-06 2018-11-27 Hfi Innovation Inc. Method for efficient reliable transmission
US20170149674A1 (en) * 2015-11-23 2017-05-25 Qualcomm Incorporated Setting a lifetime limit of a data packet to minimize congestion and contention
WO2017094331A1 (ja) 2015-11-30 2017-06-08 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
US9998949B2 (en) * 2015-12-31 2018-06-12 Facebook, Inc. Switched diversity in data link layers of directional networks
US10707986B2 (en) * 2016-01-08 2020-07-07 Qualcomm Incorporated Systems and methods for variable length block acknowledgment
CN105790896B (zh) * 2016-05-04 2019-03-29 珠海市魅族科技有限公司 无线局域网的通信方法、通信装置、接入点和站点
US10849168B2 (en) * 2016-05-10 2020-11-24 Apple Inc. Single user multi-TID TXOP with QoS prioritization
KR102407203B1 (ko) 2017-01-09 2022-06-13 주식회사 윌러스표준기술연구소 Txop를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
JP2019153864A (ja) * 2018-03-01 2019-09-12 Ｎｅｃプラットフォームズ株式会社 通信装置及び通信システム
US10925065B2 (en) * 2018-06-15 2021-02-16 Intel Corporation Extreme high throughput physical layer data rate
US11057157B2 (en) * 2018-06-29 2021-07-06 Hewlett Packard Enterprise Development Lp Transmission frame counter
SG10201912856TA (en) * 2019-12-20 2021-07-29 Panasonic Ip Corp America Communication device and communication method for multi-link block acknowledgement
CN111835822B (zh) * 2020-05-26 2024-03-19 视联动力信息技术股份有限公司 一种业务处理方法、系统、域名服务器、电子设备及介质
CN117294332A (zh) * 2023-03-06 2023-12-26 重庆物奇科技有限公司 一种mpdu重传方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9304636D0 (en) 1993-03-06 1993-04-21 Ncr Int Inc A method of accessing a communication system
JP3248348B2 (ja) * 1994-03-15 2002-01-21 松下電器産業株式会社 通信方法及び通信装置
JP2705686B2 (ja) * 1996-01-26 1998-01-28 日本電気株式会社 無線データ通信方式
US6934752B1 (en) * 2000-03-23 2005-08-23 Sharewave, Inc. Quality of service extensions for multimedia applications in wireless computer networks
US6574770B1 (en) * 2000-06-29 2003-06-03 Lucent Technologies Inc. Error-correcting communication method for transmitting data packets in a network communication system
US20020159418A1 (en) * 2000-11-02 2002-10-31 Sharp Laboratories Of America, Inc. Quality of service using wireless lan
US7161978B2 (en) * 2001-08-29 2007-01-09 Texas Instruments Incorporated Transmit and receive window synchronization
US20030076826A1 (en) * 2001-10-23 2003-04-24 International Business Machine Corporation Reliably transmitting a frame to multiple destinations by embedding sequence numbers in the frame
KR20030097559A (ko) * 2002-06-22 2003-12-31 엘지전자 주식회사 무선이동통신 시스템의 멀티미디어 서비스 방법
JP2004260658A (ja) * 2003-02-27 2004-09-16 Matsushita Electric Ind Co Ltd 無線ｌａｎ装置
US8483105B2 (en) * 2003-10-15 2013-07-09 Qualcomm Incorporated High speed media access control
US20050094632A1 (en) * 2003-10-30 2005-05-05 Anders Hebsgaard DOCSIS MAC layer-based ARQ for fixed wireless
JP4005974B2 (ja) 2004-01-09 2007-11-14 株式会社東芝 通信装置、通信方法、および通信システム
US7225278B1 (en) * 2004-04-15 2007-05-29 Xilinx, Inc. Method and apparatus for controlling direct access to memory circuitry
JP4012172B2 (ja) * 2004-05-28 2007-11-21 株式会社東芝 無線通信装置及び無線通信方法
JP4440037B2 (ja) * 2004-08-11 2010-03-24 株式会社東芝 通信装置及び通信方法
US7328026B2 (en) * 2004-08-11 2008-02-05 Mitsubishi Electric Research Laboratories, Inc. Signaling in a wireless network with sequential coordinated channel access
JP4331088B2 (ja) * 2004-11-01 2009-09-16 株式会社東芝 通信装置および通信方法
JP4284353B2 (ja) * 2006-12-26 2009-06-24 株式会社東芝 無線通信装置

Also Published As

Publication number Publication date
US20100002646A1 (en) 2010-01-07
JP2006121199A (ja) 2006-05-11
US20060083233A1 (en) 2006-04-20
CN1764157A (zh) 2006-04-26
US7848330B2 (en) 2010-12-07
US7746861B2 (en) 2010-06-29
CN101453755A (zh) 2009-06-10
CN1764157B (zh) 2010-06-02

Similar Documents

Publication Publication Date Title
JP4130648B2 (ja) 通信装置および通信方法
JP4440037B2 (ja) 通信装置及び通信方法
JP4331088B2 (ja) 通信装置および通信方法
US7990995B2 (en) Wireless communication apparatus and wireless communication method
JP4047836B2 (ja) 通信装置、通信システム、通信方法、および通信制御プログラム
US7924805B2 (en) Communication apparatus, communication system, and communication control program
JP4374001B2 (ja) 通信装置、通信方法、および通信システム
EP2923514B1 (en) Method and system for improving wireless link efficiency
JP4444237B2 (ja) 無線通信装置
JP2005252897A (ja) 通信装置、通信方法、および通信システム
JP2006352896A (ja) 無線通信装置
JP4314294B2 (ja) 通信装置、通信システム、通信方法、および通信制御プログラム
JP4543049B2 (ja) 通信装置および通信装置の通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060131

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060908

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080508

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: 20080520

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: 20080522

R151 Written notification of patent or utility model registration

Ref document number: 4130648

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: 20110530

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110530

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120530

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120530

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130530

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130530

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140530

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250