(57)【要約】【課題】通信のサービス品質（ＱｏＳ）を維持しつつも通信フレームのアグリゲーションによりスループットを向上する。【解決手段】送信すべき複数のＭＡＣフレームのうち、受信元で受信されたことを示す送達確認が必要なＭＡＣフレームと、前記送達確認が不要なＭＡＣフレームと、前記ＭＡＣフレーム各々の送達確認の必要に応じて、該ＭＡＣフレームごとに送達確認の要不要を示す識別情報とが含まれる物理フレームを作成するフレーム作成手段と、前記フレーム作成手段が作成した物理フレームを送信する送信手段とを具備する。【選択図】      図１
2005252897.tif 000002
【特許請求の範囲】
【請求項１】
送信すべき複数のＭＡＣフレームのうち、
受信元で受信されたことを示す送達確認が必要なＭＡＣフレームと、
前記送達確認が不要なＭＡＣフレームと、
前記ＭＡＣフレーム各々の送達確認の必要に応じて、該ＭＡＣフレームごとに送達確認の要不要を示す識別情報と
が含まれる物理フレームを作成するフレーム作成手段と、
前記フレーム作成手段が作成した物理フレームを送信する送信手段とを
具備したことを特徴とする通信装置。
【請求項２】
前記制御情報を、ＰＣＦまたはＨＣＦコントロールアクセスに従い設定する設定手段をさらに具備することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記ＭＡＣフレームのヘッダ部に含まれる、該ＭＡＣフレームが前記ＰＣＦまたはＨＣＦコントロールドアクセスのいずれの優先度に基づく通信に従うかに基づいて、前記識別情報を設定する請求項２に記載の通信装置。
【請求項４】
前記送達確認が必要なＭＡＣフレームと該フレームに関する情報を記憶する第１の記憶手段と、
前記送達確認が不要なＭＡＣフレームの少なくとも該フレームに関する情報を記憶する第２の記憶手段と
をさらに具備することを特徴とする請求項１に記載の通信装置。
【請求項５】
前記物理フレームに含まれるＭＡＣフレームについての送達確認応答を受信する受信手段と、
該送達確認応答と前記記憶手段に記憶した情報とに基づいて、再送が必要なＭＡＣフレームを再送する再送手段とをさらに具備することを特徴とする請求項４に記載の通信装置。
【請求項６】
複数のＭＡＣフレームを含み、
前記ＭＡＣフレームごとに、該ＭＡＣフレームを受信したことを示す送達確認応答が必要か否かを示す識別情報をさらに含む物理フレームを受信する受信手段と、
前記物理フレームに含まれるＭＡＣフレームの各々についての前記受信手段による受信結果と該ＭＡＣフレームについて前記識別情報が示す情報に基づいて、該物理フレームに含まれる複数のＭＡＣフレームのそれぞれについて受信できたか否かを示す送達確認応答を作成する応答作成手段と、
前記応答作成手段が作成した送達確認応答を送信する応答送信手段と
を具備することを特徴とする通信装置。
【請求項７】
前記物理フレームに含まれるＭＡＣフレームのいずれかの受信に失敗したことを示す受信エラーを検出するエラー検出手段をさらに具備し、
前記応答作成手段は、受信エラーを検出したＭＡＣフレームが送達確認を必要とするか否かのいずれが指定されているかを前記識別情報に基づいて判定し、送達確認の応答が必要である旨が指定されているならば、該受信エラーを検出したＭＡＣフレームについて受信できなかった旨の情報を前記送達確認応答に指定することを特徴とする請求項６に記載の通信装置。
【請求項８】
送信すべき複数のＭＡＣフレームのうち、
受信元で受信されたことを示す送達確認が必要なＭＡＣフレームと、
前記送達確認が不要なＭＡＣフレームと、
前記ＭＡＣフレーム各々の送達確認の必要に応じて、該ＭＡＣフレームごとに送達確認の要不要を示す識別情報と
が含まれる物理フレームを作成するフレーム作成ステップと、
前記フレーム作成ステップにより作成された物理フレームを送信する送信ステップとを具備したことを特徴とする通信方法。
【請求項９】
前記制御情報を、ＰＣＦまたはＨＣＦコントロールアクセスに従い設定する設定ステップをさらに具備することを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記ＭＡＣフレームのヘッダ部に含まれる、該ＭＡＣフレームが前記ＰＣＦまたはＨＣＦコントロールドアクセスのいずれの優先度に基づく通信に従うかに基づいて、前記識別情報を設定する請求項９に記載の通信方法。
【請求項１１】
前記送達確認が必要なＭＡＣフレームと該フレームに関する情報を記憶する第１の記憶ステップと、
前記送達確認が不要なＭＡＣフレームの少なくとも該フレームに関する情報を記憶する第２の記憶ステップと
をさらに具備することを特徴とする請求項８に記載の通信方法。
【請求項１２】
前記物理フレームに含まれるＭＡＣフレームについての送達確認応答を受信する受信手段と、
該送達確認応答と前記記憶ステップにおいて記憶された情報とに基づいて、再送が必要なＭＡＣフレームを再送する再送ステップとをさらに具備することを特徴とする請求項１１に記載の通信方法。
【請求項１３】
複数のＭＡＣフレームを含み、
前記ＭＡＣフレームごとに、該ＭＡＣフレームを受信したことを示す送達確認応答が必要か否かを示す識別情報をさらに含む物理フレームを受信する受信ステップと、
前記物理フレームに含まれるＭＡＣフレームの各々についての前記受信ステップによる受信結果と該ＭＡＣフレームについて前記識別情報が示す情報に基づいて、該物理フレームに含まれる複数のＭＡＣフレームのそれぞれについて受信できたか否かを示す送達確認応答を作成する応答作成ステップと、
前記応答作成ステップにより作成された送達確認応答を送信する応答送信ステップと
を具備することを特徴とする通信方法。
【請求項１４】
前記物理フレームに含まれるＭＡＣフレームのいずれかの受信に失敗したことを示す受信エラーを検出するエラー検出ステップをさらに具備し、
前記応答作成ステップは、受信エラーを検出したＭＡＣフレームが送達確認を必要とするか否かのいずれが指定されているかを前記識別情報に基づいて判定し、送達確認の応答が必要である旨が指定されているならば、該受信エラーを検出したＭＡＣフレームについて受信できなかった旨の情報を前記送達確認応答に指定することを特徴とする請求項６に記載の通信方法。
【請求項１５】
送信すべき複数のＭＡＣフレームのうち、受信元で受信されたことを示す送達確認が必要なＭＡＣフレームと、前記送達確認が不必要なＭＡＣフレームと、前記ＭＡＣフレーム各々の送達確認の必要に応じて、該ＭＡＣフレームごとに送達確認の要不要を示す識別情報とが含まれる物理フレームを作成するフレーム作成手段と、前記フレーム作成手段が作成した物理フレームを送信する送信手段とを具備する送信端末と、
複数のＭＡＣフレームを含み、前記ＭＡＣフレームごとに、該ＭＡＣフレームを受信したことを示す送達確認応答が必要か否かを示す識別情報をさらに含む物理フレームを受信する受信手段と、前記物理フレームに含まれるＭＡＣフレームの各々についての前記受信手段による受信結果と該ＭＡＣフレームについて前記識別情報が示す情報に基づいて、該物理フレームに含まれる複数のＭＡＣフレームのそれぞれについて受信できたか否かを示す送達確認応答を作成する応答作成手段と、前記応答作成手段が作成した送達確認応答を送信する応答送信手段とを具備する受信端末とを具備することを特徴とする通信システム。
【請求項１６】
第１の優先度を有する少なくとも１つの第１のＭＡＣフレームを格納するための第１の区画と、第２の優先度を有する少なくとも１つの第２のＭＡＣフレームを格納するための第２の区画とに区分されたＭＡＣスーパフレームペイロードを有する物理フレームを送信する送信手段を具備することを特徴とする通信装置。
【請求項１７】
前記第１の区画はＭＡＣスーパフレームヘッダに続き、前記第２の区画は該第１の区画に続くように、前記第１および第２の区画が前記ＭＡＣスーパフレームペイロード内に配置されることを特徴とする請求項１６に記載の通信装置。
【請求項１８】
前記第１の優先度は前記第１のＭＡＣフレームの第１のトラフィック識別子に対応し、前記第２の優先度は前記第２のＭＡＣフレームの第２のトラフィック識別子に対応することを特徴とする請求項１６または１７に記載の通信装置。
【請求項１９】
前記第１および第２のトラフィック識別子は、第１および第２のトラフィック仕様に基づいて設定された第１および第２のトラフィックストリームに対応することを特徴とする請求項１８に記載の通信装置。
【請求項２０】
前記第１の区画はチャネル推定により推定された第１の伝送路状態に対応し、前記第２の区画はチャネル推定により推定された第２の伝送路状態に対応することを特徴とする請求項１６乃至１９のいずれかに記載の通信装置。
【請求項２１】
請求項１６乃至２０に記載の通信装置から送信された物理フレームを受信する受信手段を具備することを特徴とする通信装置。
【請求項２２】
第１の優先度を有する少なくとも１つの第１のＭＡＣフレームを格納するための第１の区画と、第２の優先度を有する少なくとも１つの第２のＭＡＣフレームを格納するための第２の区画とに区分されたＭＡＣスーパフレームペイロードを有する物理フレームを送信する送信手段と、
前記物理フレームの部分応答フレームを受信する受信手段と、
前記部分応答フレームに従って前記ＭＡＣスーパフレームペイロードに含まれるいずれかのＭＡＣフレームを再送する再送手段と、
前記第１の優先度に対応する第１のウインドウサイズにより前記再送手段による再送を制御し、前記第２の優先度に対応する第２のウインドウサイズにより前記再送手段による再送を制御する再送制御手段とを具備することを特徴とする通信装置。
【請求項２３】
前記再送手段による再送回数の上限をディレイバウンド情報に基づいて定めることを特徴とする請求項２２に記載の通信装置。
【請求項２４】
前記第１および第２のウインドウサイズを第１および第２のトラフィック仕様がそれぞれ表す第１および第２の平均データレートに基づいて定めることを特徴とする請求項２２または２１に記載の通信装置。
【請求項２５】
第１の優先度を有する少なくとも１つの第１のＭＡＣフレームを格納するための第１の区画と、第２の優先度を有する少なくとも１つの第２のＭＡＣフレームを格納するための第２の区画とに区分されたＭＡＣスーパフレームペイロードを有する物理フレームを送信する送信ステップと、
前記物理フレームの部分応答フレームを受信する受信ステップと、
前記部分応答フレームに従って前記ＭＡＣスーパフレームペイロードに含まれるいずれかのＭＡＣフレームを再送する再送ステップと、
前記第１の優先度に対応する第１のウインドウサイズにより前記再送ステップによる再送を制御し、前記第２の優先度に対応する第２のウインドウサイズにより前記再送ステップによる再送を制御する再送制御ステップとを具備することを特徴とする通信方法。
【請求項２６】
前記再送ステップによる再送回数の上限をディレイバウンド情報に基づいて定めることを特徴とする請求項２５に記載の通信方法。
【請求項２７】
前記第１および第２のウインドウサイズを第１および第２のトラフィック仕様がそれぞれ表す第１および第２の平均データレートに基づいて定めることを特徴とする請求項２５または２６に記載の通信方法。
【請求項２８】
複数のトラフィック識別子に対応する一連のＱｏＳデータを送信するデータ送信手段と、
前記複数のトラフィック識別子に対応する複数のブロックＡＣＫ要求を含む単一の制御フレームを送信する制御フレーム送信手段とを具備することを特徴とする通信装置。
【請求項２９】
前記ブロックＡＣＫ要求に対応するブロックＡＣＫをポーリングされたＴＸＯＰ期間内に受信する即時型応答シーケンスを実行することを特徴とする請求項２８に記載の通信装置。
【請求項３０】
前記ブロックＡＣＫ要求に対応するブロックＡＣＫをポーリングされたＴＸＯＰ期間から一定時間経過後に受信する遅延型応答シーケンスを実行することを特徴とする請求項２９に記載の通信装置。
【請求項３１】
複数のトラフィック識別子に対応する一連のＱｏＳデータを受信するデータ受信手段と、
前記複数のトラフィック識別子に対応する複数のブロックＡＣＫ要求を含む単一の制御フレームを受信する制御フレーム受信手段と、
前記制御フレームに応答して、前記複数のブロックＡＣＫ要求に対応する複数のブロックＡＣＫを含む単一の応答フレームを送信する応答送信手段とを具備することを特徴とする通信装置。
【請求項３２】
前記応答フレームをポーリングされたＴＸＯＰ期間内に送信する即時型応答シーケンスを実行することを特徴とする請求項３１に記載の通信装置。
【請求項３３】
前記応答フレームをポーリングされたＴＸＯＰ期間から一定時間経過後に受信する遅延型応答シーケンスを実行することを特徴とする請求項３２に記載の通信装置。
【請求項３４】
複数のトラフィック識別子に対応する一連のＱｏＳデータを送信するデータ送信ステップと、
前記複数のトラフィック識別子に対応する複数のブロックＡＣＫ要求を含む単一の制御フレームを送信する制御フレーム送信ステップとを具備することを特徴とする通信方法。
【請求項３５】
前記ブロックＡＣＫ要求に対応するブロックＡＣＫをポーリングされたＴＸＯＰ期間内に受信する即時型応答シーケンスを実行することを特徴とする請求項３４に記載の通信方法。
【請求項３６】
前記ブロックＡＣＫ要求に対応するブロックＡＣＫをポーリングされたＴＸＯＰ期間から一定時間経過後に受信する遅延型応答シーケンスを実行することを特徴とする請求項３４に記載の通信方法。
【請求項３７】
複数のトラフィック識別子に対応する一連のＱｏＳデータを受信するデータ受信ステップと、
前記複数のトラフィック識別子に対応する複数のブロックＡＣＫ要求を含む単一の制御フレームを受信する制御フレーム受信ステップと、
前記制御フレームに応答して、前記複数のブロックＡＣＫ要求に対応する複数のブロックＡＣＫを含む単一の応答フレームを送信する応答送信ステップとを具備することを特徴とする通信方法。
【請求項３８】
前記応答フレームをポーリングされたＴＸＯＰ期間内に送信する即時型応答シーケンスを実行することを特徴とする請求項３７に記載の通信方法。
【請求項３９】
前記応答フレームをポーリングされたＴＸＯＰ期間から一定時間経過後に受信する遅延型応答シーケンスを実行することを特徴とする請求項３７に記載の通信方法。
【請求項４０】
複数のトラフィック識別子に対応する一連のＱｏＳデータを送信するデータ送信手段と、前記複数のトラフィック識別子に対応する複数のブロックＡＣＫ要求を含む単一の制御フレームを送信する制御フレーム送信手段とを具備する第１の通信装置と、
前記複数のトラフィック識別子に対応する一連のＱｏＳデータを受信するデータ受信手段と、前記複数のトラフィック識別子に対応する複数のブロックＡＣＫ要求を含む単一の制御フレームを受信する制御フレーム受信手段と、前記制御フレームに応答して、前記複数のブロックＡＣＫ要求に対応する複数のブロックＡＣＫを含む単一の応答フレームを前記第１の通信装置に対して送信する応答送信手段とを具備する第２の通信装置とを具備することを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は媒体アクセス制御を行なう通信装置、通信方法、および通信システムに関し、特に、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御に関する。
【背景技術】
【０００２】
同一の媒体を共有して通信を行なう複数の通信装置がどのように媒体を利用して通信データを送信するかを決めるのが、媒体アクセス制御(ＭＡＣ: Media Access Control)である。媒体アクセス制御は、同時に二つ以上の通信装置が同一の媒体を利用して通信データの送信を行なった結果、受信側の通信装置が通信データを分離できなくなる事象（衝突）がなるべく少なくなり、一方、送信要求を持つ通信装置が存在するにもかかわらず媒体がいずれの通信装置によっても利用されない事象がなるべく少なくなるように、通信装置から媒体へのアクセスを制御するための技術である。
【０００３】
さらに、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するＱｏＳとして、従来のポーリング手順を拡張したＨＣＣＡ（HCF Controlled Access；ＨＣＦコントロールド・アクセス）がある。ＨＣＣＡでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。
【０００４】
また、特許文献１は、IEEE802.11e規格のＱｏＳについて言及しており、無線ネットワーク局間の通信に優先順位を付与する方法を開示する。
【特許文献１】特開２００２−３１４５４６公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のＨＣＣＡによれば、トラフィックストリーム毎に品質を保証することができ、優先度に応じたデータ伝送を実現できる。このようなＱｏＳはスループットを更に向上した新たな通信方式においても利用することが好ましい。例えば、１つのＰＨＹ（物理）フレームに複数のＭＡＣフレームを含めて送信することにより伝送効率を向上するフレームアグリゲーションにおいてもＱｏＳを利用することが好ましい。しかしながら、ＨＣＣＡのようなＱｏＳに従来のフレームアグリゲーションをそのまま適用すると、次のような問題点が生じる。
【０００６】
すなわち、従来のフレームアグリゲーションではフレームの優先度を考慮していないために、送信キュー（TxQ）内の一連のフレームをアグリゲーション対象フレームとするとき、比較的低優先度のＦＴＰ(File Transfer Protocol)フレームが高優先度のＶｏＩＰ(Voice over IP)フレームに先行して取り出され、送信用のアグリゲーションフレームにアグリゲートされ得る。このことは、フレームの優先度を考慮したＱｏＳの維持および向上の妨げとなり得る。
【０００７】
また、従来のフレームアグリゲーションにおいて、受信エラーが生じた一部のフレームを指定して再送を要求するパーシャルＡＣＫフレームの手順についても、ＱｏＳに固有のＡＣＫ手順（例えば無応答（No_ACK）手順）との複合利用を図るべき問題もある。
【０００８】
本発明はかかる事情を考慮してなされたものであり、通信のサービス品質（ＱｏＳ）を維持しつつも通信フレームのアグリゲーションによりスループットを向上できる通信装置、通信方法ならびに通信システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一観点に係る通信装置は、送信すべき複数のＭＡＣフレームのうち、受信元で受信されたことを示す送達確認が必要なＭＡＣフレームと、前記送達確認が不要なＭＡＣフレームと、前記ＭＡＣフレーム各々の送達確認の必要に応じて、該ＭＡＣフレームごとに送達確認の要不要を示す識別情報とが含まれる物理フレームを作成するフレーム作成手段と、前記フレーム作成手段が作成した物理フレームを送信する送信手段とを具備したことを特徴とする通信装置である。
【発明の効果】
【００１０】
本発明によれば、通信のサービス品質（ＱｏＳ）を維持しつつも通信フレームのアグリゲーションによりスループットを向上できる通信装置、通信方法ならびに通信システムを提供できる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照しながら本発明の実施の形態を説明する。
【００１２】
図１は本発明の実施形態に係る通信装置の構成を示すブロック図である。この通信装置１００は無線リンクを介して他の通信装置と通信する装置であり、物理層、ＭＡＣ層、およびリンク層のそれぞれに相当する処理ユニット１０１、１０２、１０３を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはＬＳＩに組み込まれたＣＰＵにより実行されるファームウェア等として実現される。物理層の処理ユニット（以下、「処理ユニット」の表記を省略）１０１にはアンテナ１０４が接続されている。ＭＡＣ層１０２は本発明に係わるアグリゲーション（集約）処理部１０５を有する。このアグリゲーション処理部１０５はキャリアセンス制御部１０６と再送制御部１０７を備える。
【００１３】
図２は本発明の実施形態に係る通信装置が用いるフレームフォーマットの一例を示す図である。フレームフォーマット２００は物理層およびＭＡＣ層に係わるフレーム構造を概略的に示しており、具体的にはIEEE802.11またはその拡張に従うものを想定する。図２に示すように、このフレームフォーマット２００はＰＨＹヘッダ２０１と、ＭＡＣスーパフレームヘッダ２０２およびＭＡＣスーパフレームペイロード２０３と、ＰＨＹトレーラ２０４とから構成されている。ＭＡＣスーパフレームヘッダ２０２およびＭＡＣスーパフレームペイロード２０３は後述するＰＨＹペイロードに相当する。ＰＨＹヘッダ２０１は受信側通信装置の物理層１０１により処理される。すなわち物理層１０１は受信したＰＨＹヘッダ２０１に基づいて、フレーム先頭の検出、キャリアセンス、タイミング同期確立、増幅器の増幅度制御(AGC: Automatic Gain Control)、送信側キャリア周波数への追随(Automatic Frequency Control)、伝送路推定などを行う。また物理層１０１はＰＨＹヘッダ２０１に続くＰＨＹペイロードの変調方式や符号化率、ならびに伝送レートおよびデータ長の検出も行う。
【００１４】
そして、図２のように１つのＰＨＹフレーム２００に複数のＭＡＣフレームを含めるようにして転送効率を向上するような通信方式のことを本明細書では「フレームアグリゲーション」という。フレームアグリゲーションは現在策定中の次世代超高速無線ＬＡＮ通信（IEEE802.11n規格）に好適である。
【００１５】
以下に説明する本発明の第１乃至第３の実施形態はフレームアグリゲーションを実施する場合のＱｏＳに関する。実施形態において説明するＱｏＳとしては、トラフィックストリーム毎の品質を保証するＨＣＣＡを想定する。
【００１６】
第１の実施形態では、通信品質に係わるフレームの再送制御と、再送制御に不可欠な各種応答（ＡＣＫ）フレームの通信手順について説明する。
【００１７】
従来、フレームアグリゲーション方式では、宛先に向けてのフロー(アプリケーション)毎の優先度処理が何ら行われていない。例えば、図３に示すように送信キュー（TxQ）３００内の一連のフレーム３０１をアグリゲーション対象フレームとするとき、比較的低優先度のＦＴＰ(File Transfer Protocol)フレームが高優先度のＶｏＩＰ(Voice over IP)フレームを押しのけてアグリゲートされることがある。第２の実施形態では、フレームアグリゲーションを実施したことが原因で高優先度のフレームに先行して低優先度のフレームが送信されることを回避すべく、アグリゲーションするフレームを格納するフレーム位置を優先度に応じて区分する。第３の実施形態では受信エラーが生じたフレームを再送する際に好適なスライディング・ウィンドウ制御をＨＣＣＡ方式のＱｏＳにおいて実施する場合を説明する。そして第４の実施形態は、ＱｏＳに係わるブロックＡＣＫフレーム（制御フレーム）のアグリゲーションに焦点を当てる。
【００１８】
図４はIEEE802.11e規格におけるＱｏＳの種類を示す図である。IEEE802.11e規格におけるＱｏＳには、ＤＣＦ(Distributed Coordination Function)４００、ＰＣＦ(Point Coordination Function)４０１、ＥＤＣＡ(HCF Contention Access)４０２、およびＨＣＣＡ(HCF Controlled Access)４０３が存在する。ＤＣＦ４００において、送信を行うＳＴＡは、他のＳＴＡが送信しているかを判断するために無線チャネルをセンスし、無線チャネルの使用状況に応じてフレームを送信するか否かを決定する。ここでのキャリアセンス時間はＩＦＳ(Inter Frame Space)時間とバックオフ時間との和である。ＰＣＦ４０１においては、ＡＰ（Access Point；アクセスポイント）がポーリングを行う基地局になり、無線端末を集中制御する。ＡＰはポーリングリストに基づき、端末を順番にポーリングする。ＳＴＡはポーリングで自局が指定されたときフレームを送信する機会を得る。ＥＤＣＡ４０２はコンテンションベースのＱｏＳ方式であり、優先度毎に複数のＡＣ(Access Category)が設けられ、並列的なキャリアセンス・バックオフ制御を行うものである。ＨＣＣＡ４０３はＡＰからのポーリング制御を行う従来のＰＣＦの拡張方式である。
【００１９】
図５はIEEE802.11e規格におけるＨＣＣＡを説明するための図である。ＨＣＣＡでは、ＨＣ(Hybrid Coordinator；ハイブリッドコーディネータ)と呼ばれるＱｏＳアクセスポイント（QoS-AP)１０９がポーリング(スケジューリング)の主体となる。
【００２０】
通信を開始するにあたり、ＨＣＣＡでは先ずQoS-nonAP-STA（アクセスポイントでないＱｏＳ端末、以下「ＱＳＴＡ」と記す)１００とＨＣ１０９との間でＴＳ(Traffic Stream；トラフィックストリーム)がセットアップ(Uplink、Downlink、Bidirectional)される。ＴＳのセットアップは、必ずＱＳＴＡ側が主体となって開始される。ＴＳとは、その端末がどのような種類のトラフィック(ＶｏＩＰやＦＴＰ)を使用し、どの程度の帯域を必要としているかを示す、データの通り道であり、ＴＳＰＥＣ(Traffic Specification；トラフィック仕様)によって一意に仕様が決まる。ＴＳＰＥＣには、フローの最大許容遅延間隔(Maximum Service Interval)や、トラフィックストリームを識別するためのＴＳＩＤ(Traffic Stream ID)といった情報が格納される。ここで、最も重要なパラメータはMAC-SAPでのスループットを規定する平均データレート(Mean Data Rate)である。
【００２１】
ＱＳＴＡ１００からＨＣ１０９にＱｏＳ制御用のパラメータとして通知されたＴＳＰＥＣはＨＣ１０９において実行されるスケジューリングに利用される。なお、ＴＳは使用するアプリケーション毎に複数、設定することが可能である。次に、ＨＣ１０９はＴＳに応じてＱＳＴＡ１００を対象にしてポーリング手順を実行する。ポーリング手順におけるスケジューリングの具体的なアルゴリズムは、IEEE802.11eでは規定されておらず、実装依存である。そして、ＱＳＴＡ１００はＨＣ１０９からのポーリングによりＴＸＯＰ(Transmission Opportunity；送信可能時間)が与えられると、フレームを送信する。
【００２２】
ＨＣＣＡ方式では、ＱＳＴＡとの通信において各ＭＡＣフレームがＴＩＤ(Traffic ID；トラフィックＩＤ)を持つことにより、複数のトラフィックをアグリゲートすることが可能である。
【００２３】
図６はアグリゲートされる各ＭＡＣフレームのフォーマットを示す図である。ＨＣＣＡと共にフレームアグリゲーションを実施する場合、各ＭＡＣフレーム６００は独自のＭＡＣヘッダ６０１を持ち、ＭＡＣヘッダ６０１内のＴＩＤにより、ＴＳを一意に特定できることから、ＨＣＣＡとフレームアグリゲーションとの適合性に問題はない。ＴＩＤはIEEE802.11e用に拡張されたＱｏＳ制御フィールド(QoS Control)６０２に記載され、トラフィックを識別する。ＴＩＤは４ビットのフィールド長（０〜１５番）を持ち、その中でＴＳＩＤは８〜１５番を使用する。
【００２４】
以下、第１乃至第４の実施形態のそれぞれを詳細に説明する。
【００２５】
（第１の実施形態）  
本発明の第１の実施形態は、通信品質に係わるフレームの再送制御と、再送制御に不可欠な各種応答（ＡＣＫ）フレームの通信手順に関する。具体的には、第１の実施形態の通信装置は１つのＰＨＹフレームにIEEE802.11eのNo_ACKのＡＣＫポリシーと、フレームアグリゲーションのパーシャルＡＣＫのＡＣＫポリシーとを複合して転送する通信装置である。上述したように、ＱｏＳとしては、トラフィックストリーム毎の品質を保証するＨＣＣＡを想定する。
【００２６】
図７はＴＳセットアップのシーケンスを示す図である。ＱＳＴＡ（通信装置）１００は各トラフィックストリーム(ＴＳ)の開始時に、ADDTS Requestメッセージ中にＴＳＰＥＣを埋め込んでＨＣ１０９に送信する。この時、どのようなＴＳＰＥＣを選択するかについてはIEEE802.11eでは規定されておらず、実装依存である。ADDTS RequestメッセージがＨＣ(正確にはＨＣのSME(Station Management Entity))１０９に受理されると、該ＨＣ１０９からADDTS Responseが返答され、ＴＳが正式に設定される。以後、ＨＣ１０９は設定されたＴＳのＴＳＰＥＣ情報に基づいて、ポーリング等のスケジューリングを行う。
【００２７】
図８はＴＳＰＥＣのフォーマットを示す図である。フロー毎にＴＳを設定する場合、そのＱｏＳデータが必要とする帯域(MAC-SAP)をＴＳＰＥＣ８００のMean Data Rate（平均データレート）フィールドに設定する。
【００２８】
ＴＳＰＥＣ８００のTS Infoフィールド８０１には、該当するＴＩＤに属するＭＰＤＵ(MAC Protocol Date Unit)がどのような方式で送信されるべきかを示すＡＣＫポリシーフィールド８０２が存在する。
【００２９】
図９はＡＣＫポリシーフィールドの内容を示す図である。本発明の第１の実施形態では、従来ではリザーブ(Reserved)に相当する値９０２を、フレームアグリゲーションのパーシャルＡＣＫ(Partial_ACK)とする。ＭＡＣスーパーフレームを送信する端末のＭＡＣ層は、上位層から下りてくるデータフレームに対し、ＡＣＫポリシーをそれぞれ決定していく。この場合、ＡＣＫポリシーをパーシャルＡＣＫに指定することは、「そのデータフレームをフレームアグリゲーションの対象にし、かつ受信側からのＡＣＫ応答を必要としている」ことを意味している。そして、図８のTSInfoのＡＣＫポリシーフィールド８０２に、「Partial_ACK」（図９の９０２）、「No_ACK」（図９の９０１）が指定されているＴＳに関しては、ＭＡＣスーパフレームによる、フレームアグリゲーションの転送をサポートする(ＴＳはそれぞれ別個のADDTSで複数追加する)。
【００３０】
従来、TSInfoのＡＣＫポリシーフィールド８０２は、どのようなＡＣＫメカニズムを用いてフレームを転送するか示すものであり、「Normal_Ack（ノーマルＡＣＫ）」，「No_ACK（無応答）」，「Block_ACK（ブロックＡＣＫ）」の３種類がIEEE802.11eで既に規定されている。
【００３１】
「Normal_Ack」は、IEEE802.11でサポートされている通常のデータ送信方法であり、１つのユニキャストデータフレームを送信した後、宛先端末からのＡＣＫフレームを受信するまで一定時間待機する。タイムアウトが起これば、再度バックオフを行ってデータフレームを再送する。「Normal_Ack」に指定されたデータフレームは、フレームアグリゲーションの対象にせず、既存のIEEE802.11規格の手順で送信を行う。
【００３２】
「No_ACK」は、伝送路が比較的安定している場合に用いられるデータ送信方法であり、相手端末からのＡＣＫフレームの受信を待たずに、新しいユニキャストデータフレームを送信する。
【００３３】
「Block_ACK」は、ユニキャストデータフレームをＳＩＦＳ(Short Inter Frame Space)間隔でバースト的に連続送信するデータ送信方法であり、ブロックＡＣＫフレームにより選択的再送（Selective Repeat転送）を実現するものである。同一のＴＩＤに属している複数のデータフレームのＡＣＫは１つのブロックＡＣＫフレームに結合される。すなわち、ＴＳ毎に複数のブロックＡＣＫフレームが必要となる。「Block_ACK」に指定されたデータフレームは、フレームアグリゲーションの対象にせず、既存のIEEE802.11e規格のBlockAck送信手順を行う。
【００３４】
図１０はＴＳとＴＳＰＥＣの設定例を示す図である。ＴＩＤ毎に独立したＡＣＫポリシーを持つＴＳが複数設定される。そして、ＦＴＰについてはPartical_ACK、ＶｉｄｅｏについてはNo_ACK、ＶｏＩＰについてはBlock_ACKといったように、それぞれＴＳＰＥＣが異なる複数のＴＳが設定される。
【００３５】
図１１はＳＴＡキューと優先度サブキューの例を示す図である。第１の実施形態に係る通信方式では、ＨＣは、ＴＳを設定している宛先ＱＳＴＡ毎に、送信キュー(宛先キュー)１１００，１１０２を設ける。さらに宛先キュー１１００，１１０２内には、優先度毎のサブキュー１１０２，１１０３，１１０４が用意される。但し、これらサブキューは、ＴＳＰＥＣのＡＣＫポリシーが「No_ACK」と「Partial_ACK」に指定されたデータフレームのみを対象として作成する。宛先端末毎のキュー、優先度毎のサブキュー作成は、ＱＳＴＡでも同様に行うが、この場合、ＴＳを設定する対象ではない他ＱＳＴＡの宛先キューもさらに追加する必要がある。宛先キュー内の優先度毎のサブキューに入らないフレーム（「Normal_ACK」「Block_Ack」のデータフレームや、マネージメントフレーム）は、通常の送信用キュー（ＴｘＱあるいは、ビーコン用のビーコンキュー（BcQ）など）に格納していく。つまりフレームアグリゲーションの対象にはならない。
【００３６】
本発明の第１の実施形態では、フレームアグリゲーションによるデータ送信を行う際は、「No_ACK」と「Partial_ACK」の双方のＡＣＫポリシーのデータフレームを１つのＰＨＹフレームに詰め込むことを可能とする。このことは、同時に、全てのデータフレームが、No_ACKポリシーで送信されることも、Partial_ACKポリシーで送信されることも可能であることを意味する。前述したように、この場合のPartial_ACKポリシーとは、フレームアグリゲーションの対象となり、かつＡＣＫ応答を必要としているＭＡＣフレームに適用されたＡＣＫポリシーを意味している。
【００３７】
図１２は、ＡＣＫポリシービットマップ(ACK Policy Bitmap)の拡張を示す図である。ここでは最大アグリゲートフレーム数を８個としているが、この最大数は実装依存である。フレームアグリゲーションでは、ＭＡＣスーパフレームの先頭に、ＭＡＣスーパフレームヘッダ１２００が付加される。このヘッダの中身は、ＭＡＣスーパフレームのヘッダＣＲＣ(16ビット)１２０１と、アグリゲートされた各ＭＰＤＵの長さ(12ビット)を示すフィールドである。
【００３８】
そして本実施形態では、図１２に示すように新たにＡＣＫポリシービットマップ(ACK Policy Bitmap)フィールド１２０２が追加される。これは、ＭＡＣスーパフレーム中にアグリゲートされた各ＭＰＤＵが、ＡＣＫ(ここではPartial_ACK)を必要としているか否かを示すビットマップである。例えば、ＭＡＣスーパーフレーム内のＭＰＤＵが、「ACK不要 −ACK不要−ACK不要−ACK不要−ACK必要−ACK必要−ACK必要−ACK必要」であった場合、ＡＣＫポリシービットマップは「00001111」となる（後半４ビットがパーシャルACKのビットマップを必要としている部分である）。
【００３９】
ＭＡＣスーパフレームを送信した端末は、基本的にＡＣＫポリシービットマップの情報をキャッシュしておく。送信したデータフレームはパーシャルACKが受信されるまで、再送に備えて、そのコピーをバッファリングしておく。「ACK不要」を指定したデータフレームに関しては、パーシャルＡＣＫのタイムアウトに伴う再送を行わないから送信後にフレームのコピーを保存しておく必要はないが、「ACK必要」が指定されたデータフレームに関しては、再送に備えてフレームを必ずバッファリングする。ただし、「ACK不要（No_ACK）」のフレームのコピーを保存しておかない場合、MACスーパーフレーム受信端末から返されるパーシャルＡＣＫのビットマップと照らし合わせる際、送信側でコピーを保存した「ACK必要」のデータフレームと「ACK不要」のデータフレーム（コピーは取っていない）との相対位置情報のキャッシュを持っておくことが好ましい（相対位置情報を持たない実施方法については後述）。
【００４０】
ＭＡＣスーパフレームを受信した端末は、まず自分宛のアドレスであるかどうか判断し、各ＭＰＤＵのＣＲＣ（cyclic redundancy check；巡回冗長検査）計算を行う。その後、ＭＡＣスーパフレームヘッダ内のＡＣＫポリシービットマップフィールド１２０２をチェックし、パーシャルＡＣＫを必要とする「1」のフラグが立っていれば、パーシャルＡＣＫフレームの該当するビットマップに「1」または「0」の値を設定する(ＣＲＣを計算して正しく受信できていれば「1」、誤っていれば「0」とする)。また、ＡＣＫポリシービットマップが「0」であるＭＰＤＵは、「No_ACK」による転送を希望しているので、ＣＲＣの計算結果に関わらず、「0」の値を設定する。
【００４１】
ＭＡＣスーパフレームを送信して一定時間経過しても、宛先端末からのパーシャルＡＣＫを受信できない場合、送信時にPartial_ACKポリシーを指定してバッファリングしておいたデータフレームを再度、ＭＡＣスーパフレームにアグリゲートし、さらに新しいNo_ACKポリシーのデータフレームをアグリゲートすることも可能とする。この時、再送されるデータフレームは、ＴＳＰＥＣのディレイバウンド(Delay Bound)に応じて、一定時間経過した時点で再送を諦める。
【００４２】
ＭＡＣスーパフレームを送信した端末が、宛先端末からのパーシャルＡＣＫを受信した場合、自分のキャッシュしているＡＣＫポリシービットマップ情報とパーシャルＡＣＫビットマップ(Partial ACK Bitmap)とを照らし合わせる。ＡＣＫを必要としているにもかかわらず、パーシャルＡＣＫビットマップのビット情報が「0」になっていれば、該当するデータフレームを再送する。
【００４３】
ＴＳはＨＣＣＡベースのアクセス方式で使用されるため、各端末はＴＸＯＰで定められた期間の間、ＳＩＦＳ間隔でＭＡＣスーパフレーム、パーシャルＡＣＫフレームの送受信を行う。また、ＭＡＣスーパフレームにアグリゲートしたフレームが、全て「No_ACK」で指定されたもの（すなわちＡＣＫポリシービットマップのフィールドが全て０）ならば、パーシャルＡＣＫを待たずに、ＳＩＦＳ後に新しいＭＡＣスーパフレームの作成、送信を行う。
【００４４】
ここで、No_ACKポリシーとPartial_ACKポリシーとの共存について、２つの再送制御例をもとに詳細に説明する。
【００４５】
再送制御例(A)は、送信側がＡＣＫポリシーの相対位置情報をキャッシュしておくというものである。図１３に示すように、送信端末１００がＭＡＣスーパフレーム３００を送信する際に、アグリゲートされたどのＭＰＤＵがＡＣＫを必要としているか（受信側でPartial_ACKへの対応必要）、ＡＣＫが不要であるか（No_ACKポリシー）の相対位置を示すビットマップ情報３００２をキャッシュしておく。ＡＣＫポリシービットマップ３００１に示すように、ＭＡＣスーパフレーム３００における前半のフレーム「1」〜「4」はNo_ACK、すなわちＡＣＫを必要としないＴＳＩＤに対応するものであり、後半のフレーム「1」〜「4」はPartial_ACK、すなわちＡＣＫを必要とするＴＳＩＤに対応するものである。
【００４６】
ＭＡＣスーパフレームの受信端末１１０は、受信したフレーム４００のＭＡＣスーパフレームヘッダ中のＡＣＫポリシービットマップを参照する。これにより判断されるＡＣＫが必要なフレーム部分に関し、ＣＲＣ計算の結果、正しく受信が行えたならば、その情報をパーシャルＡＣＫ４０１に書き込み、送信側に返す(図１４中の例ではパーシャルＡＣＫビットマップ４０１０に「1」を立てている)。
【００４７】
送信端末１００は、受信端末１１０からのパーシャルＡＣＫビットマップ４０１０と、送信端末１００でキャッシュしておいたＡＣＫポリシーの相対位置情報３００２とを元に、ＡＣＫポリシーが「No_ACK」でないＭＰＤＵが正常に送信できていなかったと判断した場合（すなわちACK必要部分）、該当するＭＰＤＵを再送の対象として、再度ＭＡＣスーパフレーム３０１にアグリゲートして送信する。ＡＣＫポリシーが「No_ACK」の部分に関しては、再送の必要がないので、再送用バッファからリリース(「No_ACK」のフレームのコピーをバッファリングしていた場合)して、新しいフレームを詰めても良い。図１４の例では、受信側からのＡＣＫを必要としているＭＰＤＵ「1」「2」をＭＡＣスーパフレーム３０１に詰める際に、No_ACKポリシーの新しいシーケンス番号のＭＰＤＵ「5」〜「8」が同時にアグリゲートされている。
【００４８】
以上説明した再送制御例(A)の特徴は、パーシャルＡＣＫビットマップで送信側に送られる情報は、「正しく受信されたＭＰＤＵを示すためのビットマップ（いわゆるACK）」に相当する点である。
【００４９】
次に、再送制御例(B)は、受信側からのパーシャルＡＣＫビットマップによって、送信端末が再送するＭＰＤＵを決定する、というものである。上記再送制御例(A)では、送信側がNo_ACKポリシーの部分とパーシャルＡＣＫを必要とする部分の相対的な位置情報３００２をキャッシュしていた。これに対し再送制御例(B)では、パーシャルＡＣＫ中のビットマップの意味を変え、「正しく受信できたＭＰＤＵに対するビットマップ」ではなく、「再送すべきＭＰＤＵへのビットマップ」を受信側から要求する（いわゆるNACK）。この再送制御例(B)の場合、送信端末１００は再送用のＭＰＤＵのバッファ以外に、特別な情報をキャッシュしておく必要はない。
【００５０】
図１５に示すように、ＭＡＣスーパフレーム４００を受信した端末１１０は、再送制御例(A)と同じように、ＭＡＣスーパフレームヘッダ中のＡＣＫポリシービットマップ３００１を見て、ＡＣＫを必要としているＭＰＤＵを知る。ＡＣＫポリシービットマップ３００１のビットが立っていて、かつそのＭＰＤＵのＣＲＣ計算の結果が誤り(エラー)であった場合は、再送要求を示すビットを立てて、送信端末１００にパーシャルＡＣＫ４０２を返す。
【００５１】
送信端末１００は図１６のように、受信端末１１０からのパーシャルＡＣＫ４０２におけるパーシャルＡＣＫビットマップ４０２０を見て、再送すべき部分のビットが立っている(図１６の場合は「1」)場合、そのＭＰＤＵを再送すべきであると判断する。以後の処理は再送制御例(A)の場合と同様である。
【００５２】
以上説明したように、本発明の第１の実施形態によれば、ＭＡＣスーパフレームヘッダに拡張フィールドを付加することにより、「No_ACK」と「Partial_ACK」の双方のＡＣＫポリシーを複合して用いることが可能な通信装置を実現できる。
【００５３】
（第２の実施形態）  
本発明の第２の実施形態は、異なる優先度のＭＡＣフレームを伝送する際に、ＭＡＣスーパフレームにおけるＭＡＣスーパフレームペイロードを優先度毎に区分してフレームアグリゲーションを行う通信装置に関する。
【００５４】
従来のフレームアグリゲーションをそのまま用い、複数の優先度のユニキャストデータフレームをアグリゲートした場合、［低］［高］［中］［高］［低］［高］［中］［中］というようにＭＡＣスーパフレーム中においてばらばらの順番でフレームが詰められる可能性がある。無線伝播路の特性上、ＰＨＹフレーム長が増加すると、フレームの末端方向に向かって誤りが生じやすくなり、伝送効率の低下を招く。
【００５５】
そこで本発明の第２の実施形態では、フレームアグリゲーションを実施する際に、［高］［高］［高］［中］［中］［中］［低］［低］というようにフレームの優先度毎にペイロードを区切ってアグリゲートする。
【００５６】
例えばNo_ACKポリシーを利用しているトラフィックストリームのフレームが前方に配置され、比較的低優先度のトラフィックストリームのフレームが後方に配置されるようにすれば、効率の良い転送を実現できる。これは、低優先度のフレームの受信エラーによる再送は、高優先度のフレームの再送よりも相対的には許容できるからである。
【００５７】
図１７は優先度毎のフレームアグリゲート例１，２をそれぞれ示す図である。優先度毎にペイロードを区切ってアグリゲートする方法は、ＳＴＡ毎の優先度サブキューを利用することで、より容易に実現可能である。各優先度毎のＭＰＤＵ数は、例えばＴＳＰＥＣが示すMean Data Rateに応じて決定する。優先度の異なるＭＰＤＵがキュー内に存在しないときは、アグリゲート例２のように１種類のＴＳのＭＰＤＵを可能な限り詰め込む。
【００５８】
例えば図１８に示すように、メインキュー（ＴｘＱ）２１０からＳＴＡ毎にフレームを取り出してＳＴＡ毎の優先度サブキュー２１００〜２１０３（ここではＳＴＡ１〜ＳＴＡ４を想定している）に格納する。まずＳＴＡ１のサブキュー２１００においては、ＶｏＩＰ用のサブキューから４個のフレームを抜き出し、続いてＶｉｄｅｏ用のサブキューから３個のフレームを取り出してＶｏＩＰフレーム群の後方に配置し、さらにＦＴＰ用のサブキューから１個のフレームを取り出してＶｉｄｅｏフレーム群の後方に配置することで１つのＭＡＣスーパフレーム２１１を構築する。次に、ＳＴＡ２のサブキュー２１０１においては、Ｖｉｄｅｏ用のサブキューから４個のフレームを抜き出し、続いてＦＴＰ用のサブキューから２個のフレームを取り出してＶｉｄｅｏフレーム群の後方に配置することで１つのＭＡＣスーパフレーム２１２を構築する。次にＳＴＡ３のサブキュー２１０２のサブキューは空であるから送信をパスする。そして、ＳＴＡ４のサブキュー２１０３においては、ＦＴＰ用のサブキューから５個のフレームを取り出して１つのＭＡＣスーパフレーム２１３を構築する。
【００５９】
優先度の定義についてより詳しく説明する。
【００６０】
（１）ＴＣＬＡＳ(Traffic Classification；トラフィック分類)
ＴＣＬＡＳは、全てのＱｏＳ端末(ＱｏＳ−ＡＰ，ｎｏｎ−ＡＰ−ＱｏＳＳＴＡ)において、上位レイヤからのＭＳＤＵを一意に識別し、ＴＳ(Traffic Stream；トラフィックストリーム)にマッピングするための要素である。図１９，図２０はＴＣＬＡＳ要素のフォーマットを示す図である。MAC-SAP上のClassifier(クラス分類プロセス)は、上位レイヤからのＭＳＤＵを自分がセットアップしたＴＳ毎に振り分けていく。図２０(b)に示すように、例えばIPv4が上位層プロトコルとして存在する場合、IPアドレス、ポート番号、ＤＳＣＰ(Diffserve Code Point: IPレイヤ上で実現されるＱｏＳサービスDiffserve(Differentiated Services)で使用されるIPパケットの識別情報)を用いて、ClassifierプロセスはどのＴＳにマッピングするか判断していく。
【００６１】
（２）ＴＳＰＥＣ(Traffic Specification；トラフィック仕様)  
ＴＳＰＥＣはＱＳＴＡのデータフローのＱｏＳ特性パラメータであり、トラフィックの特質とＴＳのＱｏＳ要求を表現する。ＴＳＰＥＣの主要な目的は、ＨＣ内のリソースを確保すること、ならびにＨＣのスケジューリングの振る舞いを変更させることである。ＴＳＰＥＣは当該ＴＳを流れるデータフレーム(ＴＳＩＤで識別)のＡＣＫポリシーも規定する。ＴＳＰＥＣはアプリケーションからの要求に応じてＭＡＣ内部のＳＭＥ(Station Management Entity)で作成される。
【００６２】
ＴＳは１つないし、(ＴＳを設定するＱＳＴＡの判断で)それ以上のＴＣＬＡＳを持つ。そしてＴＣＬＡＳはＴＳにマッピングされる。ＴＳＰＥＣとＴＣＬＡＳの情報は、ＱＳＴＡからのADDTSによってＨＣに通知される。図２１（ａ）にADDTS Request（要求）の内容を示し、図２１（ｂ）にADDTS Response（応答）の内容を示す。
【００６３】
ＴＳのネゴシエーションが正しく行われると、ＱＳＴＡではＴＳＩＤ，ディレクション(Uplink、Downlink、Bi-directional)の情報に基づき、ＨＣではＴＳＩＤ，ディレクション，ＱＳＴＡのアドレスの情報に基づいてＴＳが区別される。
【００６４】
なお、ＴＳのディレクション(Direction)がＨＣからＱＳＴＡへの下りリンク(Downlink)の場合であっても、ＴＳセットアップのイニシエータとなるのはＱＳＴＡである。
【００６５】
以上を纏めると、あるアプリケーションデータ(例えばＶｏＩＰ)が上位層からＭＡＣ層に降りてくると、ＴＣＬＡＳの情報(IPアドレス、ポート番号、ＤＳＣＰ等)に応じて、該アプリケーションデータに関連付けられたＴＳにマッピングされる。各データフレームは、ＭＡＣヘッダ内部にＴＩＤ識別情報(この場合、ＶｏＩＰのＴＳＩＤ)を持っており、これが送受信のスケジューリングに利用されることになる。尚、ＨＣＣＡにおいて、設定されたＴＳのＴＳＩＤに該当するもの以外のフレームは送信されない。これを送信するためには新たに別のＴＳを設定する必要がある。
【００６６】
ＯＦＤＭにおけるチャネル推定(伝送路での位相と振幅の歪みをサブキャリア毎に推定すること)では、受信端末が記憶している既知のプリアンブル信号(IEEE802.11aではロングシンボル)を用いて行われる。パケットモードでの通信であって、かつパケット(フレーム)内での伝送路の時間変動が少ない無線ＬＡＮでは、パケット毎に独立してプリアンブル信号の先頭でチャネル推定を行う手法が一般的である。
【００６７】
しかし、ＭＡＣスーパフレームのようにフレーム長が大きくなると、伝送路が時間的に変動することから、フレームの後半部分になるほどプリアンブル受信時に計算された推定結果が正確に反映されない場合がある。第２の実施形態のように高い優先度のＭＰＤＵをＭＡＣスーパフレームの前方部分に詰めることで、高優先度データのエラー耐性を高めるという作用効果が得られる。
【００６８】
図２２は、チャネル推定精度とフレームアグリゲーションのフォーマット上の時間的な位置との関係を示すグラフである。縦軸はチャネル推定精度を表し、横軸は時間軸を表す。このグラフからも容易に理解されるように、高優先度のＭＰＤＵを時間軸の前方にアグリゲートすることで、エラー耐性を高めることができる。
【００６９】
（第３の実施形態）  
本発明の第３の実施形態は、フレームアグリゲーションにおけるスライディング・ウィンドウ制御をＨＣＣＡ方式のＱｏＳにおいて実施するものに関する。第３の実施形態の通信装置は、１つのＰＨＹフレームの中で優先度毎に区切られたＭＡＣフレームに対し、それぞれの優先度毎にスライディング・ウィンドウ制御を適用する。
【００７０】
ここで、スライディング・ウィンドウ制御とは、通信の公平性(Fairness)やＱｏＳ(Quality Of Service)の観点から、同一端末あての再送を適切に制御するための技術のことである。この制御に用いられるスライディング・ウインドウ(Sliding Window)は再送を含む送信と受信の履歴を表す送信管理テーブルにより表現される。
【００７１】
ある送信側通信装置が同一の受信側通信装置に対して、他のフレームの通信に優先して連続的にＭＡＣフレーム（ＭＰＤＵ）を送信する状況を考える。特定の通信装置に偏って送信および受信の権利が割り当てられることを避けるために、連続的に送信できるＭＡＣフレームの数を送信管理テーブルに基づいて制限する。この制限は、送信側通信装置と受信側通信装置のいずれかが変更されるまで有効とする。スライディング・ウィンドウ制御によれば、過剰な再送による受信端末側のバッファ溢れを防ぐことができる。
【００７２】
従来、例えばＭＡＣスーパフレームの中の先頭のＭＡＣフレームに誤りが生じた場合、たとえ他のＭＡＣフレームが正しく受信できていたとしても、これを受信側で上位レイヤに上げず、後ろのＭＡＣフレームをバッファに格納しておく。（先頭フレーム再送に伴う順序逆転を防ぐため）送信側では返されたパーシャルＡＣＫフレームを見て、先頭のＭＡＣフレームが誤りであれば、そのＭＡＣフレームのみを再送し、新規にフレームを追加することはしない。このような従来の方法を複数の優先度のフレームを包含するＭＡＣスーパフレームに対してそのまま適用すると問題が生じる。
【００７３】
例えば、それぞれが異なる優先度を有するフレームが[高][高][中][中][中][低][低][低]というようにアグリゲートされて送信され、その受信状態が「01111110」（ただし、「1」ならCRC検査の結果正常、「0」なら誤り）であったとする。
【００７４】
ＴＩＤ毎のＭＡＣフレームにはそれぞれ独自のシーケンス番号が振られており(シーケンス番号が重なってもＴＩＤが異なればＭＡＣフレームを一意に識別可能)、受信端末からしてみれば、中優先度のフレーム群はそのまま独立して上位レイヤに上げることが可能である。しかし、フレームアグリゲーションのスライディング・ウィンドウ制御をそのまま適用すれば、ＭＡＣスーパフレーム内の先頭のＭＡＣフレームが誤っているため、他の全てのＭＡＣフレームが上位レイヤに上がることはできない。
【００７５】
この問題を解決するため、本発明の第３の実施形態では、各優先度毎に独立したスライディングウィンドウ制御を実行する。上記の例では、高優先度のカテゴリでは先頭のＭＡＣフレームが誤っているため、他のフレームがバッファリングされるが、中優先度のカテゴリでは、全てのフレームを正常に受信できたとして、上位レイヤに上げることができる。低優先度のカテゴリでは、先頭のＭＡＣフレームを上位レイヤに上げた後、次のＭＡＣフレームの再送を待つ。第１の実施形態のように、１つのＭＡＣスーパフレーム中に「No_ACK」と「Partial_ACK」の２つのＡＣＫポリシーを持つＭＡＣスーパフレームを受信した場合は、No_ACKポリシーのデータフレームを、無条件に上位レイヤに上げてやればよい。
【００７６】
ＴＳＰＥＣ内のディレイバウンド情報に基づいて、各ＴＳにおける再送回数の上限は決定される。送信端末は、各ＭＡＣフレームの生存期間(Lifetime)を元に、そのフレームを再送するか、あるいは廃棄するかを決定する。また、スライディング・ウィンドウのウィンドウサイズを無制限にしておくと、ＭＡＣスーパフレームのフレーム長が不必要に大きくなってしまうので、ＴＳＰＥＣのMean Data Rate情報を元に、それぞれのＴＳ毎の最大ウィンドウサイズを決定しておくことが好ましい。
【００７７】
以下、優先度毎の再送制御について詳細に説明する。まずIEEE802.11のレガシー規格とは異なり、IEEE802.11e規格ではＴＩＤ毎(ＨＣＣＡの場合はＴＳＩＤ毎）に独立してシーケンス番号が振られる。例えば、ＴＳＩＤ(VoIP)には「0 1 2 3 4 5...」、ＴＳＩＤ(Video)には「0 1 2 3 4 5...」、ＴＳＩＤ(FTP)には「0 1 2 3 4 5...」というように、各ＴＳＩＤ内で連続したシーケンス番号が存在する。ＱｏＳデータの受信側では、ＴＳＩＤ毎にフレームが連続していれば、受信バッファからフレームを開放して、上位層に渡すことが可能である。
【００７８】
図２３は優先度毎の再送制御例を示す図である。複数の優先度のＭＰＤＵをＭＡＣスーパフレームにアグリゲートする際、送信端末はＭＡＣスーパフレーム中の各優先度の相対的な位置関係を記憶しておく。これは、パーシャルＡＣＫの受信時に、優先度毎のスライディングウィンドウ制御を行う際に必要となる。尚、スライディング・ウィンドウのウィンドウサイズは優先度毎に決定され可変長とする。
【００７９】
図２３において、１７０は高優先ＴＳＩＤ（ＶｏＩＰ）のフレームシーケンス、１７１は中優先ＴＳＩＤ（Ｖｉｄｅｏ）のフレームシーケンス、１７２は低優先ＴＳＩＤ（ＦＴＰ）のフレームシーケンスである。同図に示すようにそれぞれのフレームシーケンスには始点を有するスライディング・ウインドウ１７００、１７１０、１７２０が設定されている。これらスライディング・ウインドウ１７００、１７１０、１７２０のそれぞれに対応するフレームがアグリゲートされ、送信端末１００においてＭＡＣスーパフレーム１７３が構築される。
【００８０】
受信端末１１０において、図２４に示すように、ＣＲＣ計算の結果、高優先度ＭＰＤＵの「１」と低優先度ＭＰＤＵの「２」が誤り(エラー)であったとする（１８００）。１８０１は受信側バッファを示す。このとき、高優先度ＭＰＤＵ部分の受信側バッファ状態は、ＭＰＤＵ「１」を待つため、ＭＰＤＵ「２」「３」が待機する状態となる。中優先度部分に対応するフレームは存在しない。また、低優先度部分については、実際はＭＰＤＵ「２」待ちだが、それ以前のシーケンス番号のＭＰＤＵは正しく受信に成功しているので、バッファ１８０１にはフレーム存在無しとなる。
【００８１】
ＭＡＣスーパフレームの受信端末１１０側では、アグリゲートされたＴＳＩＤ毎に、先頭から連続しているＭＰＤＵに関しては受信バッファ１８０１から開放し、上位層に渡す。連続して受信できていない部分に関しては、バッファ１８０１に残し、送信側からの再送を待つようにする。
【００８２】
図２５に示すように、受信側では、フレームアグリゲーションと同じように、ＭＡＣスーパフレーム中の各ＭＰＤＵの受信ステータスをビットマップにし、パーシャルＡＣＫ１９０を送信側に返す。パーシャルＡＣＫ１９０が送信端末１００に返されると、ＭＡＣスーパフレーム送信時にキャッシュしておいた、優先度ＭＰＤＵの相対位置情報１９１を元に、スライディング・ウィンドウ制御を行う。例えば、返信されたパーシャルＡＣＫビットマップ１９２を見て、各優先度の始点を図２５のようにずらす。ＭＡＣスーパフレーム再送時には、それぞれの始点に応じて新しいフレームをアグリゲートして再送用のＭＡＣスーパフレーム１７４を構築する。
【００８３】
また前述のように、ＴＳ毎に最大のウィンドウサイズが決められているが、ＭＡＣスーパーフレームへＭＡＣフレームをアグリゲートしていく際、高い優先度のフレームを優先的に詰めていく。そしてアグリゲートした数が、ＭＡＣスーパーフレームが定める最大アグリゲート数（これは端末毎に決定される）に達した時、低い優先度のＭＡＣフレームを詰めこむための空きがなければ、その時点でＭＡＣスーパーフレームにアグリゲートするのを諦める。（低い優先度のフレームよりも高い優先度のフレームを優先的にアグリゲートしていく。）
（第４の実施形態）  
本発明の第４の実施形態は、IEEE802.11eで規定されたブロックＡＣＫ制御フレーム(ＴＳ毎のBlockAckReq/BlockAck)を１つのＰＨＹフレームの中に多数含ませて送信する通信装置に関する。IEEE802.11eにはデータフレームをＳＩＦＳ間隔でバースト的に送信するブロックＡＣＫが規定されている。ブロックＡＣＫによる通信手順はこれまでに述べたフレームアグリゲーションを行わない場合にも実施可能である。
【００８４】
図２６はブロックＡＣＫのシーケンス例を示す図である。ＱｏＳデータ２６０をバースト的に送信した後、本来ならばＴＳ毎にブロックＡＣＫ要求(Block Ack Request)２６１を送り、受信端末から受信ステータスを示すブロックＡＣＫ(Block ACK)２６２を受信することになる。すなわちＴＳの数だけ、ブロックＡＣＫ要求２６０とブロックＡＣＫ２６２を繰り返すことになる。
【００８５】
これに対し第４の実施形態では、フレームアグリゲーションのように、１つのＰＨＹフレームの中に、ＴＳ毎のブロックＡＣＫ要求(もしくはブロックＡＣＫ)をアグリゲートすることによって、余分なオーバーヘッドを削減することを可能にするものである。
【００８６】
ブロックＡＣＫ要求のフォーマットでは、先頭のＭＡＣヘッダ(IEEE802.11規格)の後ろに、ＢＡＲ制御(BAR Control)フィールドとブロックＡＣＫ開始シーケンス制御(Block ACK Starting Sequence Control)フィールドが続く。ＢＡＲ制御フィールドには、ＴＳを識別するためのＴＩＤと予約ビットが存在する。ブロックＡＣＫ開始シーケンス制御フィールドは、そのＴＳにおける先頭のＭＡＣフレームのシーケンス番号を示す。よって、ＢＡＲ制御とブロックＡＣＫ開始シーケンス制御フィールドは、ＴＳ毎に必要な情報と言える。
【００８７】
ブロックＡＣＫのフレームフォーマットは、一見してブロックＡＣＫ要求と似ているが、受信端末側の受信ステータス(ＭＡＣフレーム毎にＣＲＣの計算を行い、正常に受信できたかどうか)のビットマップを含むブロックＡＣＫビットマップ(Block ACK Bitmap)フィールドを持っている点でブロックＡＣＫ要求フレームとは異なる。ＴＳ毎に必要な情報としては、ＢＡＲ制御とブロックＡＣＫ開始シーケンス制御，ブロックＡＣＫビットマップフィールドである。
【００８８】
図２７に示すように、１つのＰＨＹフレームにＴＳ毎のブロックＡＣＫ要求をアグリゲートする本実施形態の場合、このアグリゲーションフレーム２７０は、ＭＡＣヘッダを先頭に、以下のようなフォーマットを有する。すなわち、[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]となる。上記フレームフォーマットにおいては、ＴＳ毎のブロックＡＣＫ要求情報に加え、ＭＡＣヘッダとＦＣＳが付随している。
【００８９】
一方、１つのＰＨＹフレームにＴＳ毎のブロックＡＣＫをアグリゲートする場合、アグリゲートしたブロックＡＣＫ要求と同様に、ＭＡＣヘッダとＦＣＳを１つずつ付け、ＴＳ毎のＢＡＲ制御、ブロックＡＣＫ開始シーケンス制御、ブロックＡＣＫビットマップを用意する。図２８に示すように、このアグリゲーションフレーム２７１は、[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]となる。
【００９０】
以上のように、１つのＰＨＹフレームにブロックＡＣＫ要求(もしくはブロックＡＣＫ)をアグリゲートした後は、通常のIEEE802.11eと同じようにブロックＡＣＫのシーケンス制御を行う。即時型ブロックＡＣＫなら、アグリゲートしたブロックＡＣＫ要求を出した後、アグリゲートされたブロックＡＣＫの受信を待つ。アグリゲートされたブロックＡＣＫの受信後は、それぞれのブロックＡＣＫビットマップに従って、ＱｏＳデータの再送を行う。遅延型ブロックＡＣＫの場合は、アグリゲートされたブロックＡＣＫ要求の送信後、ブロックＡＣＫ要求へのＡＣＫを受信端末が送信し、一定時間後にアグリゲートしたブロックＡＣＫを送信する。送信端末は受信側からのブロックＡＣＫフレームに対するＡＣＫを送信した後、再送処理に入る。
【００９１】
図２９は即時型ブロックＡＣＫのフレームシーケンス例を示している。即時型ブロックＡＣＫは送信側がブロックＡＣＫ要求を送信してから、受信側が直ちに応答(ブロックＡＣＫ)を返すというシーケンスであり、ポーリング時に複数のＴＳＩＤ毎(厳密にはＴＩＤ毎)のBlockAckReq、BlockAckがそれぞれ束ねられ、アグリゲートブロックＡＣＫ要求２９０、アグリゲートブロックＡＣＫ２９１が用いられる。なお、図２９において、ＴＸＯＰは、端末に許可されたチャネル使用期間を意味する。また、QoS CF-Poll(Contention Free-Poll)は、ＨＣ１０９がＱＳＴＡ１００に送信を許可するために送信するＱｏＳ対応ポーリングフレームのことである。なお、ＨＣ１０９からのダウンリンク送信時には、QoS CF-Pollフレームは不要である。
【００９２】
一方、図３０に示す遅延型ブロックＡＣＫは、送信側がブロックＡＣＫ要求を送信し、受信側がしばらくしてから応答(ブロックＡＣＫ)を返す遅延型である。遅延型ブロックＡＣＫでは、BlockAckReq、BlockAckのそれぞれに対するＡＣＫ６０１等が必要となる。図３０に示すように、遅延型ブロックＡＣＫではアグリゲートブロックＡＣＫ要求６００、アグリゲートブロックＡＣＫ６０２が用いられる。
【００９３】
第４の実施形態によれば、ＴＩＤ毎に規定されているブロックＡＣＫの要求または応答メッセージを１つのＰＨＹフレームで送信（ブロックＡＣＫメッセージのアグリゲート）する通信装置を提供できる。
【００９４】
以上説明した本発明の実施形態によれば、遅延に敏感なアプリケーションの品質を保証し例えばジッタを均等に保つことができることや、１つの宛先に対する複数のフローをアグリゲートすることで効率の良い転送を実現(低優先度フローの帯域も保障)できるといった作用効果を奏する。また、各宛先ＳＴＡ（ユーザ）毎に重み付けをすることで、課金制によるサービス品質のクラス分けも容易に実現できるようになる。これにより、例えば高い金額を払っているユーザ端末にはＷＲＲで優先的にＡＰからフレームを伝送できるようになる。
【００９５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００９６】
【図１】本発明の実施形態に係る通信装置の構成を示すブロック図
【図２】本発明の実施形態に係る通信装置が用いるフレームフォーマットの一例を示す図
【図３】優先度を考慮しないフレームのアグリゲーションを説明するための図
【図４】IEEE802.11e規格におけるＱｏＳの種類を示す図
【図５】IEEE802.11e規格におけるＨＣＣＡを説明するための図
【図６】アグリゲートされる各ＭＡＣフレームのフォーマットを示す図
【図７】ＴＳセットアップのシーケンスを示す図
【図８】ＴＳＰＥＣのフォーマットを示す図
【図９】ＡＣＫポリシーフィールドの内容を示す図
【図１０】ＴＳとＴＳＰＥＣの設定例を示す図
【図１１】ＳＴＡキューと優先度サブキューを示す図
【図１２】ＡＣＫポリシービットマップ(ACK Policy Bitmap)の拡張を示す図
【図１３】再送制御例(A)を説明するための図
【図１４】再送制御例(A)を説明するための別の図
【図１５】再送制御例(B)を説明するための図
【図１６】再送制御例(B)を説明するための別の図
【図１７】優先度毎のフレームアグリゲート例１，２をそれぞれ示す図
【図１８】優先度毎のフレームアグリゲーションを説明するための図
【図１９】ＴＣＬＡＳ要素のフォーマットを示す図
【図２０】ＴＣＬＡＳ要素のフォーマットを示す別の図
【図２１】ADDTS Request（要求）およびADDTS Response（応答）を示す図
【図２２】チャネル推定精度とフレームアグリゲーションのフォーマット上の時間的な位置との関係を示すグラフ
【図２３】優先度毎の再送におけるスライディング・ウインドウ制御例を説明するための図
【図２４】優先度毎の再送におけるスライディング・ウインドウ制御例を説明するための別の図
【図２５】優先度毎の再送におけるスライディング・ウインドウ制御例を説明するためのさらに別の図
【図２６】ブロックＡＣＫのシーケンス例を示す図
【図２７】１つのＰＨＹフレームにＴＳ毎のブロックＡＣＫ要求をアグリゲートする場合のフォーマットを示す図
【図２８】１つのＰＨＹフレームにＴＳ毎のブロックＡＣＫをアグリゲートする場合のフォーマットを示す図
【図２９】即時型ブロックＡＣＫのフレームシーケンス例を示す図
【図３０】遅延型ブロックＡＣＫのフレームシーケンス例を示す図
【符号の説明】
【００９７】
１００…通信装置、１０１…物理層、１０２…ＭＡＣ層、１０３…リンク層、１０４…アンテナ、１０５…アグリゲーション処理部、１０６…キャリアセンス制御部、１０７…再送制御部。
【図１】
2005252897.tif 000003
【図２】
2005252897.tif 000004
【図３】
2005252897.tif 000005
【図４】
2005252897.tif 000006
【図５】
2005252897.tif 000007
【図６】
2005252897.tif 000008
【図７】
2005252897.tif 000009
【図８】
2005252897.tif 000010
【図９】
2005252897.tif 000011
【図１０】
2005252897.tif 000012
【図１１】
2005252897.tif 000013
【図１２】
2005252897.tif 000014
【図１３】
2005252897.tif 000015
【図１４】
2005252897.tif 000016
【図１５】
2005252897.tif 000017
【図１６】
2005252897.tif 000018
【図１７】
2005252897.tif 000019
【図１８】
2005252897.tif 000020
【図１９】
2005252897.tif 000021
【図２０】
2005252897.tif 000022
【図２１】
2005252897.tif 000023
【図２２】
2005252897.tif 000024
【図２３】
2005252897.tif 000025
【図２４】
2005252897.tif 000026
【図２５】
2005252897.tif 000027
【図２６】
2005252897.tif 000028
【図２７】
2005252897.tif 000029
【図２８】
2005252897.tif 000030
【図２９】
2005252897.tif 000031
【図３０】
2005252897.tif 000032