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

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

Info

Publication number
JP4543049B2
JP4543049B2 JP2007025917A JP2007025917A JP4543049B2 JP 4543049 B2 JP4543049 B2 JP 4543049B2 JP 2007025917 A JP2007025917 A JP 2007025917A JP 2007025917 A JP2007025917 A JP 2007025917A JP 4543049 B2 JP4543049 B2 JP 4543049B2
Authority
JP
Japan
Prior art keywords
frame
data frames
data
bitmap
ack
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
Application number
JP2007025917A
Other languages
English (en)
Other versions
JP2007151171A (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 JP2007025917A priority Critical patent/JP4543049B2/ja
Publication of JP2007151171A publication Critical patent/JP2007151171A/ja
Application granted granted Critical
Publication of JP4543049B2 publication Critical patent/JP4543049B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は媒体アクセス制御を行なう通信装置、通信方法、および通信システムに関し、特に、サービス品質(QoS:Quality of Service)向上のためのアクセス制御に関する。
同一の媒体を共有して通信を行なう複数の通信装置がどのように媒体を利用して通信データを送信するかを決めるのが、媒体アクセス制御(MAC: Media Access Control)である。媒体アクセス制御は、同時に二つ以上の通信装置が同一の媒体を利用して通信データの送信を行なった結果、受信側の通信装置が通信データを分離できなくなる事象(衝突)がなるべく少なくなり、一方、送信要求を持つ通信装置が存在するにもかかわらず媒体がいずれの通信装置によっても利用されない事象がなるべく少なくなるように、通信装置から媒体へのアクセスを制御するための技術である。
さらに、サービス品質(QoS:Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するQoSとして、従来のポーリング手順を拡張したHCCA(HCF Controlled Access;HCFコントロールド・アクセス)がある。HCCAでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。
また、特許文献1は、IEEE802.11e規格のQoSについて言及しており、無線ネットワーク局間の通信に優先順位を付与する方法を開示する。
特開2002−314546公報
従来のHCCAによれば、トラフィックストリーム毎に品質を保証することができ、優先度に応じたデータ伝送を実現できる。このようなQoSはスループットを更に向上した新たな通信方式においても利用することが好ましい。例えば、1つのPHY(物理)フレームに複数のMACフレームを含めて送信することにより伝送効率を向上するフレームアグリゲーションにおいてもQoSを利用することが好ましい。しかしながら、HCCAのようなQoSに従来のフレームアグリゲーションをそのまま適用すると、次のような問題点が生じる。
すなわち、従来のフレームアグリゲーションではフレームの優先度を考慮していないために、送信キュー(TxQ)内の一連のフレームをアグリゲーション対象フレームとするとき、比較的低優先度のFTP(File Transfer Protocol)フレームが高優先度のVoIP(Voice over IP)フレームに先行して取り出され、送信用のアグリゲーションフレームにアグリゲートされ得る。このことは、フレームの優先度を考慮したQoSの維持および向上の妨げとなり得る。
また、従来のフレームアグリゲーションにおいて、受信エラーが生じた一部のフレームを指定して再送を要求するパーシャルACKフレームの手順についても、QoSに固有のACK手順(例えば無応答(No_ACK)手順)との複合利用を図るべき問題もある。
本発明はかかる事情を考慮してなされたものであり、通信のサービス品質(QoS)を維持しつつも通信フレームのアグリゲーションによりスループットを向上できる通信装置、通信方法ならびに通信システムを提供することを目的とする。
本発明の一観点に係る通信装置は、基地局によって予約された第1帯域予約期間内に、
第1のトラフィック識別子に対応する複数の第1データフレームと、第2のトラフィック
識別子に対応する複数の第2データフレームとを送信する第1送信手段と、前記基地局に
よって予約された第2帯域予約期間内に、前記複数の第1データフレームと前記複数の第
2データフレームとのそれぞれの送達確認情報を要求する単一の送達確認応答要求フレー
ムを送信する第2送信手段と、前記基地局によって予約された第3帯域予約期間内に、前
記複数の第1データフレームと前記複数の第2データフレームとの個々の送達確認情報を
含む単一の送達確認応答フレームを受信する受信手段とを具備し、前記送達確認応答フレ
ームは、前記第1のトラフィック識別子と、前記複数の第1のデータフレームの受信ステ
ータスを表す第1ビットマップと、前記第1ビットマップの開始シーケンス番号を示すフ
ィールドを含む第1送達確認情報のセットと、前記第2のトラフィック識別子と、前記複
数の第2のデータフレームの受信ステータスを表す第2ビットマップと、前記第2ビット
マップの開始シーケンス番号を示すフィールドを含む第2送達確認情報のセットと、前記
送達確認応答フレームに含まれる送達確認情報のセットの数を示す情報とを有し、前記複
数の第1データフレームと、前記複数の第2データフレームとは、トラフィック識別子ご
とに、それぞれ独自のシーケンス番号が付与され、前記第1送信手段が送信する単一の物
理フレームには、前記複数の第1データフレームの少なくとも1つと、前記複数の第2デ
ータフレームの少なくとも1つとが含まれ、前記複数の第1データフレームのうち前記第
1ビットマップで受信失敗とされたデータフレームは、データフレームごとの生存時間と
、前記第1のトラフィック識別子に対応する第1遅延許容時間とに応じて再送され、前記
複数の第2データフレームのうち前記第2ビットマップで受信失敗とされたデータフレー
ムは、データフレームごとの生存時間と、前記第2のトラフィック識別子に対応する第2
遅延許容時間とに応じて再送されることを特徴とする
本発明によれば、通信のサービス品質(QoS)を維持しつつも通信フレームのアグリゲーションによりスループットを向上できる通信装置、通信方法ならびに通信システムを提供できる。
以下、図面を参照しながら本発明の実施の形態を説明する。
図1は本発明の実施形態に係る通信装置の構成を示すブロック図である。この通信装置100は無線リンクを介して他の通信装置と通信する装置であり、物理層、MAC層、およびリンク層のそれぞれに相当する処理ユニット101、102、103を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはLSIに組み込まれたCPUにより実行されるファームウェア等として実現される。物理層の処理ユニット(以下、「処理ユニット」の表記を省略)101にはアンテナ104が接続されている。MAC層102は本発明に係わるアグリゲーション(集約)処理部105を有する。このアグリゲーション処理部105はキャリアセンス制御部106と再送制御部107を備える。
図2は本発明の実施形態に係る通信装置が用いるフレームフォーマットの一例を示す図である。フレームフォーマット200は物理層およびMAC層に係わるフレーム構造を概略的に示しており、具体的にはIEEE802.11またはその拡張に従うものを想定する。図2に示すように、このフレームフォーマット200はPHYヘッダ201と、MACスーパフレームヘッダ202およびMACスーパフレームペイロード203と、PHYトレーラ204とから構成されている。MACスーパフレームヘッダ202およびMACスーパフレームペイロード203は後述するPHYペイロードに相当する。PHYヘッダ201は受信側通信装置の物理層101により処理される。すなわち物理層101は受信したPHYヘッダ201に基づいて、フレーム先頭の検出、キャリアセンス、タイミング同期確立、増幅器の増幅度制御(AGC: Automatic Gain Control)、送信側キャリア周波数への追随(Automatic Frequency Control)、伝送路推定などを行う。また物理層101はPHYヘッダ201に続くPHYペイロードの変調方式や符号化率、ならびに伝送レートおよびデータ長の検出も行う。
そして、図2のように1つのPHYフレーム200に複数のMACフレームを含めるようにして転送効率を向上するような通信方式のことを本明細書では「フレームアグリゲーション」という。フレームアグリゲーションは現在策定中の次世代超高速無線LAN通信(IEEE802.11n規格)に好適である。
以下に説明する本発明の第1乃至第3の実施形態はフレームアグリゲーションを実施する場合のQoSに関する。実施形態において説明するQoSとしては、トラフィックストリーム毎の品質を保証するHCCAを想定する。
第1の実施形態では、通信品質に係わるフレームの再送制御と、再送制御に不可欠な各種応答(ACK)フレームの通信手順について説明する。
従来、フレームアグリゲーション方式では、宛先に向けてのフロー(アプリケーション)毎の優先度処理が何ら行われていない。例えば、図3に示すように送信キュー(TxQ)300内の一連のフレーム301をアグリゲーション対象フレームとするとき、比較的低優先度のFTP(File Transfer Protocol)フレームが高優先度のVoIP(Voice over IP)フレームを押しのけてアグリゲートされることがある。第2の実施形態では、フレームアグリゲーションを実施したことが原因で高優先度のフレームに先行して低優先度のフレームが送信されることを回避すべく、アグリゲーションするフレームを格納するフレーム位置を優先度に応じて区分する。第3の実施形態では受信エラーが生じたフレームを再送する際に好適なスライディング・ウィンドウ制御をHCCA方式のQoSにおいて実施する場合を説明する。そして第4の実施形態は、QoSに係わるブロックACKフレーム(制御フレーム)のアグリゲーションに焦点を当てる。
図4はIEEE802.11e規格におけるQoSの種類を示す図である。IEEE802.11e規格におけるQoSには、DCF(Distributed Coordination Function)400、PCF(Point Coordination Function)401、EDCA(HCF Contention Access)402、およびHCCA(HCF Controlled Access)403が存在する。DCF400において、送信を行うSTAは、他のSTAが送信しているかを判断するために無線チャネルをセンスし、無線チャネルの使用状況に応じてフレームを送信するか否かを決定する。ここでのキャリアセンス時間はIFS(Inter Frame Space)時間とバックオフ時間との和である。PCF401においては、AP(Access Point;アクセスポイント)がポーリングを行う基地局になり、無線端末を集中制御する。APはポーリングリストに基づき、端末を順番にポーリングする。STAはポーリングで自局が指定されたときフレームを送信する機会を得る。EDCA402はコンテンションベースのQoS方式であり、優先度毎に複数のAC(Access Category)が設けられ、並列的なキャリアセンス・バックオフ制御を行うものである。HCCA403はAPからのポーリング制御を行う従来のPCFの拡張方式である。
図5はIEEE802.11e規格におけるHCCAを説明するための図である。HCCAでは、HC(Hybrid Coordinator;ハイブリッドコーディネータ)と呼ばれるQoSアクセスポイント(QoS-AP)109がポーリング(スケジューリング)の主体となる。
通信を開始するにあたり、HCCAでは先ずQoS-nonAP-STA(アクセスポイントでないQoS端末、以下「QSTA」と記す)100とHC109との間でTS(Traffic Stream;トラフィックストリーム)がセットアップ(Uplink、Downlink、Bidirectional)される。TSのセットアップは、必ずQSTA側が主体となって開始される。TSとは、その端末がどのような種類のトラフィック(VoIPやFTP)を使用し、どの程度の帯域を必要としているかを示す、データの通り道であり、TSPEC(Traffic Specification;トラフィック仕様)によって一意に仕様が決まる。TSPECには、フローの最大許容遅延間隔(Maximum Service Interval)や、トラフィックストリームを識別するためのTSID(Traffic Stream ID)といった情報が格納される。ここで、最も重要なパラメータはMAC-SAPでのスループットを規定する平均データレート(Mean Data Rate)である。
QSTA100からHC109にQoS制御用のパラメータとして通知されたTSPECはHC109において実行されるスケジューリングに利用される。なお、TSは使用するアプリケーション毎に複数、設定することが可能である。次に、HC109はTSに応じてQSTA100を対象にしてポーリング手順を実行する。ポーリング手順におけるスケジューリングの具体的なアルゴリズムは、IEEE802.11eでは規定されておらず、実装依存である。そして、QSTA100はHC109からのポーリングによりTXOP(Transmission Opportunity;送信可能時間)が与えられると、フレームを送信する。
HCCA方式では、QSTAとの通信において各MACフレームがTID(Traffic ID;トラフィックID)を持つことにより、複数のトラフィックをアグリゲートすることが可能である。
図6はアグリゲートされる各MACフレームのフォーマットを示す図である。HCCAと共にフレームアグリゲーションを実施する場合、各MACフレーム600は独自のMACヘッダ601を持ち、MACヘッダ601内のTIDにより、TSを一意に特定できることから、HCCAとフレームアグリゲーションとの適合性に問題はない。TIDはIEEE802.11e用に拡張されたQoS制御フィールド(QoS Control)602に記載され、トラフィックを識別する。TIDは4ビットのフィールド長(0〜15番)を持ち、その中でTSIDは8〜15番を使用する。
以下、第1乃至第4の実施形態のそれぞれを詳細に説明する。
(第1の実施形態)
本発明の第1の実施形態は、通信品質に係わるフレームの再送制御と、再送制御に不可欠な各種応答(ACK)フレームの通信手順に関する。具体的には、第1の実施形態の通信装置は1つのPHYフレームにIEEE802.11eのNo_ACKのACKポリシーと、フレームアグリゲーションのパーシャルACKのACKポリシーとを複合して転送する通信装置である。上述したように、QoSとしては、トラフィックストリーム毎の品質を保証するHCCAを想定する。
図7はTSセットアップのシーケンスを示す図である。QSTA(通信装置)100は各トラフィックストリーム(TS)の開始時に、ADDTS Requestメッセージ中にTSPECを埋め込んでHC109に送信する。この時、どのようなTSPECを選択するかについてはIEEE802.11eでは規定されておらず、実装依存である。ADDTS RequestメッセージがHC(正確にはHCのSME(Station Management Entity))109に受理されると、該HC109からADDTS Responseが返答され、TSが正式に設定される。以後、HC109は設定されたTSのTSPEC情報に基づいて、ポーリング等のスケジューリングを行う。
図8はTSPECのフォーマットを示す図である。フロー毎にTSを設定する場合、そのQoSデータが必要とする帯域(MAC-SAP)をTSPEC800のMean Data Rate(平均データレート)フィールドに設定する。
TSPEC800のTS Infoフィールド801には、該当するTIDに属するMPDU(MAC Protocol Date Unit)がどのような方式で送信されるべきかを示すACKポリシーフィールド802が存在する。
図9はACKポリシーフィールドの内容を示す図である。本発明の第1の実施形態では、従来ではリザーブ(Reserved)に相当する値902を、フレームアグリゲーションのパーシャルACK(Partial_ACK)とする。MACスーパーフレームを送信する端末のMAC層は、上位層から下りてくるデータフレームに対し、ACKポリシーをそれぞれ決定していく。この場合、ACKポリシーをパーシャルACKに指定することは、「そのデータフレームをフレームアグリゲーションの対象にし、かつ受信側からのACK応答を必要としている」ことを意味している。そして、図8のTSInfoのACKポリシーフィールド802に、「Partial_ACK」(図9の902)、「No_ACK」(図9の901)が指定されているTSに関しては、MACスーパフレームによる、フレームアグリゲーションの転送をサポートする(TSはそれぞれ別個のADDTSで複数追加する)。
従来、TSInfoのACKポリシーフィールド802は、どのようなACKメカニズムを用いてフレームを転送するか示すものであり、「Normal_Ack(ノーマルACK)」,「No_ACK(無応答)」,「Block_ACK(ブロックACK)」の3種類がIEEE802.11eで既に規定されている。
「Normal_Ack」は、IEEE802.11でサポートされている通常のデータ送信方法であり、1つのユニキャストデータフレームを送信した後、宛先端末からのACKフレームを受信するまで一定時間待機する。タイムアウトが起これば、再度バックオフを行ってデータフレームを再送する。「Normal_Ack」に指定されたデータフレームは、フレームアグリゲーションの対象にせず、既存のIEEE802.11規格の手順で送信を行う。
「No_ACK」は、伝送路が比較的安定している場合に用いられるデータ送信方法であり、相手端末からのACKフレームの受信を待たずに、新しいユニキャストデータフレームを送信する。
「Block_ACK」は、ユニキャストデータフレームをSIFS(Short Inter Frame Space)間隔でバースト的に連続送信するデータ送信方法であり、ブロックACKフレームにより選択的再送(Selective Repeat転送)を実現するものである。同一のTIDに属している複数のデータフレームのACKは1つのブロックACKフレームに結合される。すなわち、TS毎に複数のブロックACKフレームが必要となる。「Block_ACK」に指定されたデータフレームは、フレームアグリゲーションの対象にせず、既存のIEEE802.11e規格のBlockAck送信手順を行う。
図10はTSとTSPECの設定例を示す図である。TID毎に独立したACKポリシーを持つTSが複数設定される。そして、FTPについてはPartical_ACK、VideoについてはNo_ACK、VoIPについてはBlock_ACKといったように、それぞれTSPECが異なる複数のTSが設定される。
図11はSTAキューと優先度サブキューの例を示す図である。第1の実施形態に係る通信方式では、HCは、TSを設定している宛先QSTA毎に、送信キュー(宛先キュー)1100,1102を設ける。さらに宛先キュー1100,1102内には、優先度毎のサブキュー1102,1103,1104が用意される。但し、これらサブキューは、TSPECのACKポリシーが「No_ACK」と「Partial_ACK」に指定されたデータフレームのみを対象として作成する。宛先端末毎のキュー、優先度毎のサブキュー作成は、QSTAでも同様に行うが、この場合、TSを設定する対象ではない他QSTAの宛先キューもさらに追加する必要がある。宛先キュー内の優先度毎のサブキューに入らないフレーム(「Normal_ACK」「Block_Ack」のデータフレームや、マネージメントフレーム)は、通常の送信用キュー(TxQあるいは、ビーコン用のビーコンキュー(BcQ)など)に格納していく。つまりフレームアグリゲーションの対象にはならない。
本発明の第1の実施形態では、フレームアグリゲーションによるデータ送信を行う際は、「No_ACK」と「Partial_ACK」の双方のACKポリシーのデータフレームを1つのPHYフレームに詰め込むことを可能とする。このことは、同時に、全てのデータフレームが、No_ACKポリシーで送信されることも、Partial_ACKポリシーで送信されることも可能であることを意味する。前述したように、この場合のPartial_ACKポリシーとは、フレームアグリゲーションの対象となり、かつACK応答を必要としているMACフレームに適用されたACKポリシーを意味している。
図12は、ACKポリシービットマップ(ACK Policy Bitmap)の拡張を示す図である。ここでは最大アグリゲートフレーム数を8個としているが、この最大数は実装依存である。フレームアグリゲーションでは、MACスーパフレームの先頭に、MACスーパフレームヘッダ1200が付加される。このヘッダの中身は、MACスーパフレームのヘッダCRC(16ビット)1201と、アグリゲートされた各MPDUの長さ(12ビット)を示すフィールドである。
そして本実施形態では、図12に示すように新たにACKポリシービットマップ(ACK Policy Bitmap)フィールド1202が追加される。これは、MACスーパフレーム中にアグリゲートされた各MPDUが、ACK(ここではPartial_ACK)を必要としているか否かを示すビットマップである。例えば、MACスーパーフレーム内のMPDUが、「ACK不要- ACK不要- ACK不要- ACK不要- ACK必要- ACK必要- ACK必要- ACK必要」であった場合、ACKポリシービットマップは「00001111」となる(後半4ビットがパーシャルACKのビットマップを必要としている部分である)。
MACスーパフレームを送信した端末は、基本的にACKポリシービットマップの情報をキャッシュしておく。送信したデータフレームはパーシャルACKが受信されるまで、再送に備えて、そのコピーをバッファリングしておく。「ACK不要」を指定したデータフレームに関しては、パーシャルACKのタイムアウトに伴う再送を行わないから送信後にフレームのコピーを保存しておく必要はないが、「ACK必要」が指定されたデータフレームに関しては、再送に備えてフレームを必ずバッファリングする。ただし、「ACK不要(No_ACK)」のフレームのコピーを保存しておかない場合、MACスーパーフレーム受信端末から返されるパーシャルACKのビットマップと照らし合わせる際、送信側でコピーを保存した「ACK必要」のデータフレームと「ACK不要」のデータフレーム(コピーは取っていない)との相対位置情報のキャッシュを持っておくことが好ましい(相対位置情報を持たない実施方法については後述)。
MACスーパフレームを受信した端末は、まず自分宛のアドレスであるかどうか判断し、各MPDUのCRC(cyclic redundancy check;巡回冗長検査)計算を行う。その後、MACスーパフレームヘッダ内のACKポリシービットマップフィールド1202をチェックし、パーシャルACKを必要とする「1」のフラグが立っていれば、パーシャルACKフレームの該当するビットマップに「1」または「0」の値を設定する(CRCを計算して正しく受信できていれば「1」、誤っていれば「0」とする)。また、ACKポリシービットマップが「0」であるMPDUは、「No_ACK」による転送を希望しているので、CRCの計算結果に関わらず、「0」の値を設定する。
MACスーパフレームを送信して一定時間経過しても、宛先端末からのパーシャルACKを受信できない場合、送信時にPartial_ACKポリシーを指定してバッファリングしておいたデータフレームを再度、MACスーパフレームにアグリゲートし、さらに新しいNo_ACKポリシーのデータフレームをアグリゲートすることも可能とする。この時、再送されるデータフレームは、TSPECのディレイバウンド(Delay Bound)に応じて、一定時間経過した時点で再送を諦める。
MACスーパフレームを送信した端末が、宛先端末からのパーシャルACKを受信した場合、自分のキャッシュしているACKポリシービットマップ情報とパーシャルACKビットマップ(Partial ACK Bitmap)とを照らし合わせる。ACKを必要としているにもかかわらず、パーシャルACKビットマップのビット情報が「0」になっていれば、該当するデータフレームを再送する。
TSはHCCAベースのアクセス方式で使用されるため、各端末はTXOPで定められた期間の間、SIFS間隔でMACスーパフレーム、パーシャルACKフレームの送受信を行う。また、MACスーパフレームにアグリゲートしたフレームが、全て「No_ACK」で指定されたもの(すなわちACKポリシービットマップのフィールドが全て0)ならば、パーシャルACKを待たずに、SIFS後に新しいMACスーパフレームの作成、送信を行う。
ここで、No_ACKポリシーとPartial_ACKポリシーとの共存について、2つの再送制御例をもとに詳細に説明する。
再送制御例(A)は、送信側がACKポリシーの相対位置情報をキャッシュしておくというものである。図13に示すように、送信端末100がMACスーパフレーム300を送信する際に、アグリゲートされたどのMPDUがACKを必要としているか(受信側でPartial_ACKへの対応必要)、ACKが不要であるか(No_ACKポリシー)の相対位置を示すビットマップ情報3002をキャッシュしておく。ACKポリシービットマップ3001に示すように、MACスーパフレーム300における前半のフレーム「1」〜「4」はNo_ACK、すなわちACKを必要としないTSIDに対応するものであり、後半のフレーム「1」〜「4」はPartial_ACK、すなわちACKを必要とするTSIDに対応するものである。
MACスーパフレームの受信端末110は、受信したフレーム400のMACスーパフレームヘッダ中のACKポリシービットマップを参照する。これにより判断されるACKが必要なフレーム部分に関し、CRC計算の結果、正しく受信が行えたならば、その情報をパーシャルACK401に書き込み、送信側に返す(図14中の例ではパーシャルACKビットマップ4010に「1」を立てている)。
送信端末100は、受信端末110からのパーシャルACKビットマップ4010と、送信端末100でキャッシュしておいたACKポリシーの相対位置情報3002とを元に、ACKポリシーが「No_ACK」でないMPDUが正常に送信できていなかったと判断した場合(すなわちACK必要部分)、該当するMPDUを再送の対象として、再度MACスーパフレーム301にアグリゲートして送信する。ACKポリシーが「No_ACK」の部分に関しては、再送の必要がないので、再送用バッファからリリース(「No_ACK」のフレームのコピーをバッファリングしていた場合)して、新しいフレームを詰めても良い。図14の例では、受信側からのACKを必要としているMPDU「1」「2」をMACスーパフレーム301に詰める際に、No_ACKポリシーの新しいシーケンス番号のMPDU「5」〜「8」が同時にアグリゲートされている。
以上説明した再送制御例(A)の特徴は、パーシャルACKビットマップで送信側に送られる情報は、「正しく受信されたMPDUを示すためのビットマップ(いわゆるACK)」に相当する点である。
次に、再送制御例(B)は、受信側からのパーシャルACKビットマップによって、送信端末が再送するMPDUを決定する、というものである。上記再送制御例(A)では、送信側がNo_ACKポリシーの部分とパーシャルACKを必要とする部分の相対的な位置情報3002をキャッシュしていた。これに対し再送制御例(B)では、パーシャルACK中のビットマップの意味を変え、「正しく受信できたMPDUに対するビットマップ」ではなく、「再送すべきMPDUへのビットマップ」を受信側から要求する(いわゆるNACK)。この再送制御例(B)の場合、送信端末100は再送用のMPDUのバッファ以外に、特別な情報をキャッシュしておく必要はない。
図15に示すように、MACスーパフレーム400を受信した端末110は、再送制御例(A)と同じように、MACスーパフレームヘッダ中のACKポリシービットマップ3001を見て、ACKを必要としているMPDUを知る。ACKポリシービットマップ3001のビットが立っていて、かつそのMPDUのCRC計算の結果が誤り(エラー)であった場合は、再送要求を示すビットを立てて、送信端末100にパーシャルACK402を返す。
送信端末100は図16のように、受信端末110からのパーシャルACK402におけるパーシャルACKビットマップ4020を見て、再送すべき部分のビットが立っている(図16の場合は「1」)場合、そのMPDUを再送すべきであると判断する。以後の処理は再送制御例(A)の場合と同様である。
以上説明したように、本発明の第1の実施形態によれば、MACスーパフレームヘッダに拡張フィールドを付加することにより、「No_ACK」と「Partial_ACK」の双方のACKポリシーを複合して用いることが可能な通信装置を実現できる。
(第2の実施形態)
本発明の第2の実施形態は、異なる優先度のMACフレームを伝送する際に、MACスーパフレームにおけるMACスーパフレームペイロードを優先度毎に区分してフレームアグリゲーションを行う通信装置に関する。
従来のフレームアグリゲーションをそのまま用い、複数の優先度のユニキャストデータフレームをアグリゲートした場合、[低][高][中][高][低][高][中][中]というようにMACスーパフレーム中においてばらばらの順番でフレームが詰められる可能性がある。無線伝播路の特性上、PHYフレーム長が増加すると、フレームの末端方向に向かって誤りが生じやすくなり、伝送効率の低下を招く。
そこで本発明の第2の実施形態では、フレームアグリゲーションを実施する際に、[高][高][高][中][中][中][低][低]というようにフレームの優先度毎にペイロードを区切ってアグリゲートする。
例えばNo_ACKポリシーを利用しているトラフィックストリームのフレームが前方に配置され、比較的低優先度のトラフィックストリームのフレームが後方に配置されるようにすれば、効率の良い転送を実現できる。これは、低優先度のフレームの受信エラーによる再送は、高優先度のフレームの再送よりも相対的には許容できるからである。
図17は優先度毎のフレームアグリゲート例1,2をそれぞれ示す図である。優先度毎にペイロードを区切ってアグリゲートする方法は、STA毎の優先度サブキューを利用することで、より容易に実現可能である。各優先度毎のMPDU数は、例えばTSPECが示すMean Data Rateに応じて決定する。優先度の異なるMPDUがキュー内に存在しないときは、アグリゲート例2のように1種類のTSのMPDUを可能な限り詰め込む。
例えば図18に示すように、メインキュー(TxQ)210からSTA毎にフレームを取り出してSTA毎の優先度サブキュー2100〜2103(ここではSTA1〜STA4を想定している)に格納する。まずSTA1のサブキュー2100においては、VoIP用のサブキューから4個のフレームを抜き出し、続いてVideo用のサブキューから3個のフレームを取り出してVoIPフレーム群の後方に配置し、さらにFTP用のサブキューから1個のフレームを取り出してVideoフレーム群の後方に配置することで1つのMACスーパフレーム211を構築する。次に、STA2のサブキュー2101においては、Video用のサブキューから4個のフレームを抜き出し、続いてFTP用のサブキューから2個のフレームを取り出してVideoフレーム群の後方に配置することで1つのMACスーパフレーム212を構築する。次にSTA3のサブキュー2102のサブキューは空であるから送信をパスする。そして、STA4のサブキュー2103においては、FTP用のサブキューから5個のフレームを取り出して1つのMACスーパフレーム213を構築する。
優先度の定義についてより詳しく説明する。
(1)TCLAS(Traffic Classification;トラフィック分類)
TCLASは、全てのQoS端末(QoS−AP,non−AP−QoSSTA)において、上位レイヤからのMSDUを一意に識別し、TS(Traffic Stream;トラフィックストリーム)にマッピングするための要素である。図19,図20はTCLAS要素のフォーマットを示す図である。MAC-SAP上のClassifier(クラス分類プロセス)は、上位レイヤからのMSDUを自分がセットアップしたTS毎に振り分けていく。図20(b)に示すように、例えばIPv4が上位層プロトコルとして存在する場合、IPアドレス、ポート番号、DSCP(Diffserve Code Point: IPレイヤ上で実現されるQoSサービスDiffserve(Differentiated Services)で使用されるIPパケットの識別情報)を用いて、ClassifierプロセスはどのTSにマッピングするか判断していく。
(2)TSPEC(Traffic Specification;トラフィック仕様)
TSPECはQSTAのデータフローのQoS特性パラメータであり、トラフィックの特質とTSのQoS要求を表現する。TSPECの主要な目的は、HC内のリソースを確保すること、ならびにHCのスケジューリングの振る舞いを変更させることである。TSPECは当該TSを流れるデータフレーム(TSIDで識別)のACKポリシーも規定する。TSPECはアプリケーションからの要求に応じてMAC内部のSME(Station Management Entity)で作成される。
TSは1つないし、(TSを設定するQSTAの判断で)それ以上のTCLASを持つ。そしてTCLASはTSにマッピングされる。TSPECとTCLASの情報は、QSTAからのADDTSによってHCに通知される。図21(a)にADDTS Request(要求)の内容を示し、図21(b)にADDTS Response(応答)の内容を示す。
TSのネゴシエーションが正しく行われると、QSTAではTSID,ディレクション(Uplink、Downlink、Bi-directional)の情報に基づき、HCではTSID,ディレクション,QSTAのアドレスの情報に基づいてTSが区別される。
なお、TSのディレクション(Direction)がHCからQSTAへの下りリンク(Downlink)の場合であっても、TSセットアップのイニシエータとなるのはQSTAである。
以上を纏めると、あるアプリケーションデータ(例えばVoIP)が上位層からMAC層に降りてくると、TCLASの情報(IPアドレス、ポート番号、DSCP等)に応じて、該アプリケーションデータに関連付けられたTSにマッピングされる。各データフレームは、MACヘッダ内部にTID識別情報(この場合、VoIPのTSID)を持っており、これが送受信のスケジューリングに利用されることになる。尚、HCCAにおいて、設定されたTSのTSIDに該当するもの以外のフレームは送信されない。これを送信するためには新たに別のTSを設定する必要がある。
OFDMにおけるチャネル推定(伝送路での位相と振幅の歪みをサブキャリア毎に推定すること)では、受信端末が記憶している既知のプリアンブル信号(IEEE802.11aではロングシンボル)を用いて行われる。パケットモードでの通信であって、かつパケット(フレーム)内での伝送路の時間変動が少ない無線LANでは、パケット毎に独立してプリアンブル信号の先頭でチャネル推定を行う手法が一般的である。
しかし、MACスーパフレームのようにフレーム長が大きくなると、伝送路が時間的に変動することから、フレームの後半部分になるほどプリアンブル受信時に計算された推定結果が正確に反映されない場合がある。第2の実施形態のように高い優先度のMPDUをMACスーパフレームの前方部分に詰めることで、高優先度データのエラー耐性を高めるという作用効果が得られる。
図22は、チャネル推定精度とフレームアグリゲーションのフォーマット上の時間的な位置との関係を示すグラフである。縦軸はチャネル推定精度を表し、横軸は時間軸を表す。このグラフからも容易に理解されるように、高優先度のMPDUを時間軸の前方にアグリゲートすることで、エラー耐性を高めることができる。
(第3の実施形態)
本発明の第3の実施形態は、フレームアグリゲーションにおけるスライディング・ウィンドウ制御をHCCA方式のQoSにおいて実施するものに関する。第3の実施形態の通信装置は、1つのPHYフレームの中で優先度毎に区切られたMACフレームに対し、それぞれの優先度毎にスライディング・ウィンドウ制御を適用する。
ここで、スライディング・ウィンドウ制御とは、通信の公平性(Fairness)やQoS(Quality Of Service)の観点から、同一端末あての再送を適切に制御するための技術のことである。この制御に用いられるスライディング・ウインドウ(Sliding Window)は再送を含む送信と受信の履歴を表す送信管理テーブルにより表現される。
ある送信側通信装置が同一の受信側通信装置に対して、他のフレームの通信に優先して連続的にMACフレーム(MPDU)を送信する状況を考える。特定の通信装置に偏って送信および受信の権利が割り当てられることを避けるために、連続的に送信できるMACフレームの数を送信管理テーブルに基づいて制限する。この制限は、送信側通信装置と受信側通信装置のいずれかが変更されるまで有効とする。スライディング・ウィンドウ制御によれば、過剰な再送による受信端末側のバッファ溢れを防ぐことができる。
従来、例えばMACスーパフレームの中の先頭のMACフレームに誤りが生じた場合、たとえ他のMACフレームが正しく受信できていたとしても、これを受信側で上位レイヤに上げず、後ろのMACフレームをバッファに格納しておく。(先頭フレーム再送に伴う順序逆転を防ぐため)送信側では返されたパーシャルACKフレームを見て、先頭のMACフレームが誤りであれば、そのMACフレームのみを再送し、新規にフレームを追加することはしない。このような従来の方法を複数の優先度のフレームを包含するMACスーパフレームに対してそのまま適用すると問題が生じる。
例えば、それぞれが異なる優先度を有するフレームが[高][高][中][中][中][低][低][低]というようにアグリゲートされて送信され、その受信状態が「01111110」(ただし、「1」ならCRC検査の結果正常、「0」なら誤り)であったとする。
TID毎のMACフレームにはそれぞれ独自のシーケンス番号が振られており(シーケンス番号が重なってもTIDが異なればMACフレームを一意に識別可能)、受信端末からしてみれば、中優先度のフレーム群はそのまま独立して上位レイヤに上げることが可能である。しかし、フレームアグリゲーションのスライディング・ウィンドウ制御をそのまま適用すれば、MACスーパフレーム内の先頭のMACフレームが誤っているため、他の全てのMACフレームが上位レイヤに上がることはできない。
この問題を解決するため、本発明の第3の実施形態では、各優先度毎に独立したスライディングウィンドウ制御を実行する。上記の例では、高優先度のカテゴリでは先頭のMACフレームが誤っているため、他のフレームがバッファリングされるが、中優先度のカテゴリでは、全てのフレームを正常に受信できたとして、上位レイヤに上げることができる。低優先度のカテゴリでは、先頭のMACフレームを上位レイヤに上げた後、次のMACフレームの再送を待つ。第1の実施形態のように、1つのMACスーパフレーム中に「No_ACK」と「Partial_ACK」の2つのACKポリシーを持つMACスーパフレームを受信した場合は、No_ACKポリシーのデータフレームを、無条件に上位レイヤに上げてやればよい。
TSPEC内のディレイバウンド情報に基づいて、各TSにおける再送回数の上限は決定される。送信端末は、各MACフレームの生存期間(Lifetime)を元に、そのフレームを再送するか、あるいは廃棄するかを決定する。また、スライディング・ウィンドウのウィンドウサイズを無制限にしておくと、MACスーパフレームのフレーム長が不必要に大きくなってしまうので、TSPECのMean Data Rate情報を元に、それぞれのTS毎の最大ウィンドウサイズを決定しておくことが好ましい。
以下、優先度毎の再送制御について詳細に説明する。まずIEEE802.11のレガシー規格とは異なり、IEEE802.11e規格ではTID毎(HCCAの場合はTSID毎)に独立してシーケンス番号が振られる。例えば、TSID(VoIP)には「0 1 2 3 4 5...」、TSID(Video)には「0 1 2 3 4 5...」、TSID(FTP)には「0 1 2 3 4 5...」というように、各TSID内で連続したシーケンス番号が存在する。QoSデータの受信側では、TSID毎にフレームが連続していれば、受信バッファからフレームを開放して、上位層に渡すことが可能である。
図23は優先度毎の再送制御例を示す図である。複数の優先度のMPDUをMACスーパフレームにアグリゲートする際、送信端末はMACスーパフレーム中の各優先度の相対的な位置関係を記憶しておく。これは、パーシャルACKの受信時に、優先度毎のスライディングウィンドウ制御を行う際に必要となる。尚、スライディング・ウィンドウのウィンドウサイズは優先度毎に決定され可変長とする。
図23において、170は高優先TSID(VoIP)のフレームシーケンス、171は中優先TSID(Video)のフレームシーケンス、172は低優先TSID(FTP)のフレームシーケンスである。同図に示すようにそれぞれのフレームシーケンスには始点を有するスライディング・ウインドウ1700、1710、1720が設定されている。これらスライディング・ウインドウ1700、1710、1720のそれぞれに対応するフレームがアグリゲートされ、送信端末100においてMACスーパフレーム173が構築される。
受信端末110において、図24に示すように、CRC計算の結果、高優先度MPDUの「1」と低優先度MPDUの「2」が誤り(エラー)であったとする(1800)。1801は受信側バッファを示す。このとき、高優先度MPDU部分の受信側バッファ状態は、MPDU「1」を待つため、MPDU「2」「3」が待機する状態となる。中優先度部分に対応するフレームは存在しない。また、低優先度部分については、実際はMPDU「2」待ちだが、それ以前のシーケンス番号のMPDUは正しく受信に成功しているので、バッファ1801にはフレーム存在無しとなる。
MACスーパフレームの受信端末110側では、アグリゲートされたTSID毎に、先頭から連続しているMPDUに関しては受信バッファ1801から開放し、上位層に渡す。連続して受信できていない部分に関しては、バッファ1801に残し、送信側からの再送を待つようにする。
図25に示すように、受信側では、フレームアグリゲーションと同じように、MACスーパフレーム中の各MPDUの受信ステータスをビットマップにし、パーシャルACK190を送信側に返す。パーシャルACK190が送信端末100に返されると、MACスーパフレーム送信時にキャッシュしておいた、優先度MPDUの相対位置情報191を元に、スライディング・ウィンドウ制御を行う。例えば、返信されたパーシャルACKビットマップ192を見て、各優先度の始点を図25のようにずらす。MACスーパフレーム再送時には、それぞれの始点に応じて新しいフレームをアグリゲートして再送用のMACスーパフレーム174を構築する。
また前述のように、TS毎に最大のウィンドウサイズが決められているが、MACスーパーフレームへMACフレームをアグリゲートしていく際、高い優先度のフレームを優先的に詰めていく。そしてアグリゲートした数が、MACスーパーフレームが定める最大アグリゲート数(これは端末毎に決定される)に達した時、低い優先度のMACフレームを詰めこむための空きがなければ、その時点でMACスーパーフレームにアグリゲートするのを諦める。(低い優先度のフレームよりも高い優先度のフレームを優先的にアグリゲートしていく。)
(第4の実施形態)
本発明の第4の実施形態は、IEEE802.11eで規定されたブロックACK制御フレーム(TS毎のBlockAckReq/BlockAck)を1つのPHYフレームの中に多数含ませて送信する通信装置に関する。IEEE802.11eにはデータフレームをSIFS間隔でバースト的に送信するブロックACKが規定されている。ブロックACKによる通信手順はこれまでに述べたフレームアグリゲーションを行わない場合にも実施可能である。
図26はブロックACKのシーケンス例を示す図である。QoSデータ260をバースト的に送信した後、本来ならばTS毎にブロックACK要求(Block Ack Request)261を送り、受信端末から受信ステータスを示すブロックACK(Block ACK)262を受信することになる。すなわちTSの数だけ、ブロックACK要求260とブロックACK262を繰り返すことになる。
これに対し第4の実施形態では、フレームアグリゲーションのように、1つのPHYフレームの中に、TS毎のブロックACK要求(もしくはブロックACK)をアグリゲートすることによって、余分なオーバーヘッドを削減することを可能にするものである。
ブロックACK要求のフォーマットでは、先頭のMACヘッダ(IEEE802.11規格)の後ろに、BAR制御(BAR Control)フィールドとブロックACK開始シーケンス制御(Block ACK Starting Sequence Control)フィールドが続く。BAR制御フィールドには、TSを識別するためのTIDと予約ビットが存在する。ブロックACK開始シーケンス制御フィールドは、そのTSにおける先頭のMACフレームのシーケンス番号を示す。よって、BAR制御とブロックACK開始シーケンス制御フィールドは、TS毎に必要な情報と言える。
ブロックACKのフレームフォーマットは、一見してブロックACK要求と似ているが、受信端末側の受信ステータス(MACフレーム毎にCRCの計算を行い、正常に受信できたかどうか)のビットマップを含むブロックACKビットマップ(Block ACK Bitmap)フィールドを持っている点でブロックACK要求フレームとは異なる。TS毎に必要な情報としては、BAR制御とブロックACK開始シーケンス制御,ブロックACKビットマップフィールドである。
図27に示すように、1つのPHYフレームにTS毎のブロックACK要求をアグリゲートする本実施形態の場合、このアグリゲーションフレーム270は、MACヘッダを先頭に、以下のようなフォーマットを有する。すなわち、[MACヘッダ] - [”BAR Control_1”、”Block ACK Starting Sequence Control_1”] [”BAR Control_2”、”Block ACK Starting Sequence Control_2”] [”BAR Control_3”、”Block ACK Starting Sequence Control_3”]…. - [FCS]となる。上記フレームフォーマットにおいては、TS毎のブロックACK要求情報に加え、MACヘッダとFCSが付随している。
一方、1つのPHYフレームにTS毎のブロックACKをアグリゲートする場合、アグリゲートしたブロックACK要求と同様に、MACヘッダとFCSを1つずつ付け、TS毎のBAR制御、ブロックACK開始シーケンス制御、ブロックACKビットマップを用意する。図28に示すように、このアグリゲーションフレーム271は、[MACヘッダ] - [”BAR Control_1”、”Block ACK Starting Sequence Control_1”、Block ACK Bitmap_1]
[”BAR Control_2”、”Block ACK Starting Sequence Control_2”、Block ACK Bitmap_2]
[”BAR Control_3”、”Block ACK Starting Sequence Control_3”、Block ACK Bitmap_3]…. - [FCS]となる。
以上のように、1つのPHYフレームにブロックACK要求(もしくはブロックACK)をアグリゲートした後は、通常のIEEE802.11eと同じようにブロックACKのシーケンス制御を行う。即時型ブロックACKなら、アグリゲートしたブロックACK要求を出した後、アグリゲートされたブロックACKの受信を待つ。アグリゲートされたブロックACKの受信後は、それぞれのブロックACKビットマップに従って、QoSデータの再送を行う。遅延型ブロックACKの場合は、アグリゲートされたブロックACK要求の送信後、ブロックACK要求へのACKを受信端末が送信し、一定時間後にアグリゲートしたブロックACKを送信する。送信端末は受信側からのブロックACKフレームに対するACKを送信した後、再送処理に入る。
図29は即時型ブロックACKのフレームシーケンス例を示している。即時型ブロックACKは送信側がブロックACK要求を送信してから、受信側が直ちに応答(ブロックACK)を返すというシーケンスであり、ポーリング時に複数のTSID毎(厳密にはTID毎)のBlockAckReq、BlockAckがそれぞれ束ねられ、アグリゲートブロックACK要求290、アグリゲートブロックACK291が用いられる。なお、図29において、TXOPは、端末に許可されたチャネル使用期間を意味する。また、QoS CF-Poll(Contention Free-Poll)は、HC109がQSTA100に送信を許可するために送信するQoS対応ポーリングフレームのことである。なお、HC109からのダウンリンク送信時には、QoS CF-Pollフレームは不要である。
一方、図30に示す遅延型ブロックACKは、送信側がブロックACK要求を送信し、受信側がしばらくしてから応答(ブロックACK)を返す遅延型である。遅延型ブロックACKでは、BlockAckReq、BlockAckのそれぞれに対するACK601等が必要となる。図30に示すように、遅延型ブロックACKではアグリゲートブロックACK要求600、アグリゲートブロックACK602が用いられる。
第4の実施形態によれば、TID毎に規定されているブロックACKの要求または応答メッセージを1つのPHYフレームで送信(ブロックACKメッセージのアグリゲート)する通信装置を提供できる。
以上説明した本発明の実施形態によれば、遅延に敏感なアプリケーションの品質を保証し例えばジッタを均等に保つことができることや、1つの宛先に対する複数のフローをアグリゲートすることで効率の良い転送を実現(低優先度フローの帯域も保障)できるといった作用効果を奏する。また、各宛先STA(ユーザ)毎に重み付けをすることで、課金制によるサービス品質のクラス分けも容易に実現できるようになる。これにより、例えば高い金額を払っているユーザ端末にはWRRで優先的にAPからフレームを伝送できるようになる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の実施形態に係る通信装置の構成を示すブロック図 本発明の実施形態に係る通信装置が用いるフレームフォーマットの一例を示す図 優先度を考慮しないフレームのアグリゲーションを説明するための図 IEEE802.11e規格におけるQoSの種類を示す図 IEEE802.11e規格におけるHCCAを説明するための図 アグリゲートされる各MACフレームのフォーマットを示す図 TSセットアップのシーケンスを示す図 TSPECのフォーマットを示す図 ACKポリシーフィールドの内容を示す図 TSとTSPECの設定例を示す図 STAキューと優先度サブキューを示す図 ACKポリシービットマップ(ACK Policy Bitmap)の拡張を示す図 再送制御例(A)を説明するための図 再送制御例(A)を説明するための別の図 再送制御例(B)を説明するための図 再送制御例(B)を説明するための別の図 優先度毎のフレームアグリゲート例1,2をそれぞれ示す図 優先度毎のフレームアグリゲーションを説明するための図 TCLAS要素のフォーマットを示す図 TCLAS要素のフォーマットを示す別の図 ADDTS Request(要求)およびADDTS Response(応答)を示す図 チャネル推定精度とフレームアグリゲーションのフォーマット上の時間的な位置との関係を示すグラフ 優先度毎の再送におけるスライディング・ウインドウ制御例を説明するための図 優先度毎の再送におけるスライディング・ウインドウ制御例を説明するための別の図 優先度毎の再送におけるスライディング・ウインドウ制御例を説明するためのさらに別の図 ブロックACKのシーケンス例を示す図 1つのPHYフレームにTS毎のブロックACK要求をアグリゲートする場合のフォーマットを示す図 1つのPHYフレームにTS毎のブロックACKをアグリゲートする場合のフォーマットを示す図 即時型ブロックACKのフレームシーケンス例を示す図 遅延型ブロックACKのフレームシーケンス例を示す図
符号の説明
100…通信装置、101…物理層、102…MAC層、103…リンク層、104…アンテナ、105…アグリゲーション処理部、106…キャリアセンス制御部、107…再送制御部。

Claims (4)

  1. 基地局によって予約された第1帯域予約期間内に、第1のトラフィック識別子に対応す
    る複数の第1データフレームと、第2のトラフィック識別子に対応する複数の第2データ
    フレームとを送信する第1送信手段と、
    前記基地局によって予約された第2帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとのそれぞれの送達確認情報を要求する単一の送達確認
    応答要求フレームを送信する第2送信手段と、
    前記基地局によって予約された第3帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとの個々の送達確認情報を含む単一の送達確認応答フレ
    ームを受信する受信手段とを具備し、
    前記送達確認応答フレームは、
    前記第1のトラフィック識別子と、前記複数の第1のデータフレームの受信ステータス
    を表す第1ビットマップと、前記第1ビットマップの開始シーケンス番号を示すフィール
    ドを含む第1送達確認情報のセットと、
    前記第2のトラフィック識別子と、前記複数の第2のデータフレームの受信ステータス
    を表す第2ビットマップと、前記第2ビットマップの開始シーケンス番号を示すフィール
    ドを含む第2送達確認情報のセットと、
    前記送達確認応答フレームに含まれる送達確認情報のセットの数を示す情報とを有し、
    前記複数の第1データフレームと、前記複数の第2データフレームとは、トラフィック
    識別子ごとに、それぞれ独自のシーケンス番号が付与され、
    前記第1送信手段が送信する単一の物理フレームには、前記複数の第1データフレーム
    の少なくとも1つと、前記複数の第2データフレームの少なくとも1つとが含まれ、
    前記複数の第1データフレームのうち前記第1ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第1のトラフィック識別子に対応す
    る第1遅延許容時間とに応じて再送され、
    前記複数の第2データフレームのうち前記第2ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第2のトラフィック識別子に対応す
    る第2遅延許容時間とに応じて再送されることを特徴とする通信装置。
  2. 基地局によって予約された第1帯域予約期間内に、第1のトラフィック識別子に対応す
    る複数の第1データフレームと、第2のトラフィック識別子に対応する複数の第2データ
    フレームとを受信する第1受信手段と、
    前記基地局によって予約された第2帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとのそれぞれの送達確認情報を要求する単一の送達確認
    応答要求フレームを受信する第2受信手段と、
    前記基地局によって予約された第3帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとの個々の送達確認情報を含む単一の送達確認応答フレ
    ームを送信する送信手段とを具備し、
    前記送達確認応答フレームは、
    前記第1のトラフィック識別子と、前記複数の第1のデータフレームの受信ステータス
    を表す第1ビットマップと、前記第1ビットマップの開始シーケンス番号を示すフィール
    ドを含む第1送達確認情報のセットと、
    前記第2のトラフィック識別子と、前記複数の第2のデータフレームの受信ステータス
    を表す第2ビットマップと、前記第2ビットマップの開始シーケンス番号を示すフィール
    ドを含む第2送達確認情報のセットと、
    前記送達確認応答フレームに含まれる送達確認情報のセットの数を示す情報とを有し、
    前記複数の第1データフレームと、前記複数の第2データフレームとは、トラフィック
    識別子ごとに、それぞれ独自のシーケンス番号が付与され、
    前記第1受信手段が受信する単一の物理フレームには、前記複数の第1データフレーム
    の少なくとも1つと、前記複数の第2データフレームの少なくとも1つとが含まれ、
    前記複数の第1データフレームのうち前記第1ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第1のトラフィック識別子に対応す
    る第1遅延許容時間とに応じて再送され、
    前記複数の第2データフレームのうち前記第2ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第2のトラフィック識別子に対応す
    る第2遅延許容時間とに応じて再送されることを特徴とする通信装置。
  3. 基地局によって予約された第1帯域予約期間内に、第1のトラフィック識別子に対応す
    る複数の第1データフレームと、第2のトラフィック識別子に対応する複数の第2データ
    フレームとを送信し、
    前記基地局によって予約された第2帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとのそれぞれの送達確認情報を要求する単一の送達確認
    応答要求フレームを送信し、
    前記基地局によって予約された第3帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとの個々の送達確認情報を含む単一の送達確認応答フレ
    ームを受信し、
    前記送達確認応答フレームは、
    前記第1のトラフィック識別子と、前記複数の第1のデータフレームの受信ステータス
    を表す第1ビットマップと、前記第1ビットマップの開始シーケンス番号を示すフィール
    ドを含む第1送達確認情報のセットと、
    前記第2のトラフィック識別子と、前記複数の第2のデータフレームの受信ステータス
    を表す第2ビットマップと、前記第2ビットマップの開始シーケンス番号を示すフィール
    ドを含む第2送達確認情報のセットと、
    前記送達確認応答フレームに含まれる送達確認情報のセットの数を示す情報とを有し、
    前記複数の第1データフレームと、前記複数の第2データフレームとは、トラフィック
    識別子ごとに、それぞれ独自のシーケンス番号が付与され、
    送信する単一の物理フレームには、前記複数の第1データフレームの少なくとも1つと
    、前記複数の第2データフレームの少なくとも1つとが含まれ、
    前記複数の第1データフレームのうち前記第1ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第1のトラフィック識別子に対応す
    る第1遅延許容時間とに応じて再送され、
    前記複数の第2データフレームのうち前記第2ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第2のトラフィック識別子に対応す
    る第2遅延許容時間とに応じて再送されることを特徴とする通信装置の通信方法。
  4. 基地局によって予約された第1帯域予約期間内に、第1のトラフィック識別子に対応す
    る複数の第1データフレームと、第2のトラフィック識別子に対応する複数の第2データ
    フレームとを受信し、
    前記基地局によって予約された第2帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとのそれぞれの送達確認情報を要求する単一の送達確認
    応答要求フレームを受信し、
    前記基地局によって予約された第3帯域予約期間内に、前記複数の第1データフレーム
    と前記複数の第2データフレームとの個々の送達確認情報を含む単一の送達確認応答フレ
    ームを送信し、
    前記送達確認応答フレームは、
    前記第1のトラフィック識別子と、前記複数の第1のデータフレームの受信ステータス
    を表す第1ビットマップと、前記第1ビットマップの開始シーケンス番号を示すフィール
    ドを含む第1送達確認情報のセットと、
    前記第2のトラフィック識別子と、前記複数の第2のデータフレームの受信ステータス
    を表す第2ビットマップと、前記第2ビットマップの開始シーケンス番号を示すフィール
    ドを含む第2送達確認情報のセットと、
    前記送達確認応答フレームに含まれる送達確認情報のセットの数を示す情報とを有し、
    前記複数の第1データフレームと、前記複数の第2データフレームとは、トラフィック
    識別子ごとに、それぞれ独自のシーケンス番号が付与され、
    受信する単一の物理フレームには、前記複数の第1データフレームの少なくとも1つと
    、前記複数の第2データフレームの少なくとも1つとが含まれ、
    前記複数の第1データフレームのうち前記第1ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第1のトラフィック識別子に対応す
    る第1遅延許容時間とに応じて再送され、
    前記複数の第2データフレームのうち前記第2ビットマップで受信失敗とされたデータ
    フレームは、データフレームごとの生存時間と、前記第2のトラフィック識別子に対応す
    る第2遅延許容時間とに応じて再送されることを特徴とする通信装置 の通信方法。
JP2007025917A 2007-02-05 2007-02-05 通信装置および通信装置の通信方法 Expired - Lifetime JP4543049B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007025917A JP4543049B2 (ja) 2007-02-05 2007-02-05 通信装置および通信装置の通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007025917A JP4543049B2 (ja) 2007-02-05 2007-02-05 通信装置および通信装置の通信方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2004063237A Division JP4528541B2 (ja) 2004-03-05 2004-03-05 通信装置、通信方法、および通信システム

Publications (2)

Publication Number Publication Date
JP2007151171A JP2007151171A (ja) 2007-06-14
JP4543049B2 true JP4543049B2 (ja) 2010-09-15

Family

ID=38211926

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007025917A Expired - Lifetime JP4543049B2 (ja) 2007-02-05 2007-02-05 通信装置および通信装置の通信方法

Country Status (1)

Country Link
JP (1) JP4543049B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101854747B (zh) * 2009-04-01 2013-09-11 中兴通讯股份有限公司 Hrpd系统中非3gpp2消息传输的方法和系统
WO2011072164A2 (en) * 2009-12-09 2011-06-16 Marvell World Trade Ltd. Frame padding for wireless communications
US9438384B2 (en) * 2011-03-08 2016-09-06 Qualcomm Incorporated Providing multiple retransmission policies for a single data stream by mapping differentiated services code point (DSCP) bit fields to media access control protocol data unit (MPDU) bit fields
JP7318033B2 (ja) * 2017-08-23 2023-07-31 株式会社東芝 無線通信装置および無線通信方法
JP2019041182A (ja) * 2017-08-23 2019-03-14 株式会社東芝 無線通信装置および無線通信方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07288497A (ja) * 1994-04-20 1995-10-31 N T T Data Tsushin Kk 衛星通信方法及び衛星通信システム
JP2002237794A (ja) * 2001-02-09 2002-08-23 Fujitsu Ltd 通信装置
WO2002103943A1 (en) * 2001-06-18 2002-12-27 Itran Communications Ltd. Channel access method for powerline carrier based media access control protocol
WO2003039074A1 (fr) * 2001-10-29 2003-05-08 Sharp Kabushiki Kaisha Procede de gestion de communication, programme de gestion de communication, support d'enregistrement a programme de gestion de communication enregistre, appareil de communication, gestionnaire central et systeme de reseau
WO2003043266A1 (en) * 2001-11-13 2003-05-22 Koninklijke Philips Electronics N.V. Apparatus and method for providing quality of service signaling for ieee 802.11e mac
JP2003324442A (ja) * 2002-04-26 2003-11-14 Matsushita Electric Ind Co Ltd 無線ネットワークで効率的なバッファ機構を用いることにより媒体アクセスを高速化する方法
JP2004007336A (ja) * 2002-04-17 2004-01-08 Sharp Corp 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、ならびに通信局

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6219713B1 (en) * 1998-07-07 2001-04-17 Nokia Telecommunications, Oy Method and apparatus for adjustment of TCP sliding window with information about network conditions

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07288497A (ja) * 1994-04-20 1995-10-31 N T T Data Tsushin Kk 衛星通信方法及び衛星通信システム
JP2002237794A (ja) * 2001-02-09 2002-08-23 Fujitsu Ltd 通信装置
WO2002103943A1 (en) * 2001-06-18 2002-12-27 Itran Communications Ltd. Channel access method for powerline carrier based media access control protocol
WO2003039074A1 (fr) * 2001-10-29 2003-05-08 Sharp Kabushiki Kaisha Procede de gestion de communication, programme de gestion de communication, support d'enregistrement a programme de gestion de communication enregistre, appareil de communication, gestionnaire central et systeme de reseau
WO2003043266A1 (en) * 2001-11-13 2003-05-22 Koninklijke Philips Electronics N.V. Apparatus and method for providing quality of service signaling for ieee 802.11e mac
JP2004007336A (ja) * 2002-04-17 2004-01-08 Sharp Corp 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、ならびに通信局
JP2003324442A (ja) * 2002-04-26 2003-11-14 Matsushita Electric Ind Co Ltd 無線ネットワークで効率的なバッファ機構を用いることにより媒体アクセスを高速化する方法

Also Published As

Publication number Publication date
JP2007151171A (ja) 2007-06-14

Similar Documents

Publication Publication Date Title
JP4528541B2 (ja) 通信装置、通信方法、および通信システム
JP4012172B2 (ja) 無線通信装置及び無線通信方法
JP4331088B2 (ja) 通信装置および通信方法
JP4047836B2 (ja) 通信装置、通信システム、通信方法、および通信制御プログラム
JP4086304B2 (ja) 通信装置、通信システム、および通信制御プログラム
JP4130648B2 (ja) 通信装置および通信方法
JP4440037B2 (ja) 通信装置及び通信方法
US20060268886A1 (en) Wireless communication method and system for enhancing the capability of WLAN control frames
WO2015186887A1 (ko) 프레임을 수신하는 방법 및 장치
JP4444237B2 (ja) 無線通信装置
JP4374001B2 (ja) 通信装置、通信方法、および通信システム
JP2006352896A (ja) 無線通信装置
WO2012130094A1 (zh) 一种用于帧确认的方法和装置
JP4314294B2 (ja) 通信装置、通信システム、通信方法、および通信制御プログラム
WO2008134984A1 (fr) Procédé, système et dispositif d'interrogation
JP4543049B2 (ja) 通信装置および通信装置の通信方法
WO2012051962A1 (zh) 终端上报调度信息的方法及终端
CN103548316A (zh) 一种用于帧确认的方法和装置
WO2012130092A1 (zh) 一种用于帧确认的方法和装置

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090206

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090224

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091225

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100427

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20100510

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

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

R151 Written notification of patent or utility model registration

Ref document number: 4543049

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

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250