(57)【特許請求の範囲】
【請求項１】
受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる通信方法に従う受信局であって、
ノーマルＡＣＫ方式を要求するデータフレームを受信したかどうかに関わらず、所定の期間内に、ブロックＡＣＫ方式を要求するデータフレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する受信局。
【請求項２】
受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる通信方法であって、
受信局において、ノーマルＡＣＫ方式を要求するデータフレームを受信したかどうかに関わらず、所定の期間内に、ブロックＡＣＫ方式を要求するデータフレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する通信方法。
【請求項３】
受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる通信方法に従う受信局であって、
データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する受信局。
【請求項４】
受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる通信方法であって、
受信局において、データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する通信方法。
【請求項５】
受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる通信方法に従う受信局であって、
データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ方式を要求するデータフレーム、または、ブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する受信局。
【請求項６】
受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる通信方法であって、
受信局において、データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ方式を要求するデータフレーム、または、ブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する通信方法。
【請求項７】
ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．    ８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，  Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、
あるＴＩＤのストリームについて、受信局において、Ａｃｋ  ＰｏｌｉｃｙフィールドにＮｏｒｍａｌ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信したかどうかに関わらず、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される期間内にＡｃｋ  ＰｏｌｉｃｙフィールドにＢｌｏｃｋ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信できなかった場合は、Ｂｌｏｃｋ  Ａｃｋの伝送のために使用していたリソースを開放する通信方法。
【請求項８】
ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．    ８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，  Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、
あるＴＩＤのストリームについて、受信局において、ＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信したかどうかに関わらず、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される期間内に、Ｂｌｏｃｋ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  Ｒｅｑｕｅｓｔ  Ｆｒａｍｅを受信できなかった場合は、Ｂｌｏｃｋ  Ａｃｋの伝送のために使用していたリソースを開放する通信方法。
【請求項９】
ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．    ８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，  Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、
あるＴＩＤのストリームについて、受信局において、Ａｃｋ  ＰｏｌｉｃｙフィールドにＮｏｒｍａｌ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信したかどうかに関わらず、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される期間内にＡｃｋ  ＰｏｌｉｃｙフィールドにＢｌｏｃｋ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅ、または、Ｂｌｏｃｋ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  Ｒｅｑｕｅｓｔ  Ｆｒａｍｅを受信できなかった場合は、Ｂｌｏｃｋ  Ａｃｋの伝送のために使用していたリソースを開放する通信方法。
【請求項１０】
受信したデータフレームに対するＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式とを切り替えて使用することができる受信局であって、
タイマと、
所定の期間内にブロックＡＣＫ方式を要求するデータフレーム、および、ブロックＡＣＫ送信要求フレームのうち少なくとも一方の受信時に前記タイマをリセットするタイマ制御手段と、
前記タイマが所定時間経過した場合に、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放するリソース制御手段とを備える受信局。
【請求項１１】
コンピュータに請求項１または請求項３または請求項５または請求項１０の受信局として動作させるための手順を記述した通信プログラム。
【請求項１２】
請求項１１に記載の通信プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、１つのフレームに対する送達確認を１つのフレームで返送するノーマルＡＣＫ方式と、複数のフレームに対する送達確認をまとめて１つのフレームで返送するブロックＡＣＫ方式の両方を同時に使用しうる通信方法に関するものである。
【背景技術】
【０００２】  従来、無線通信のような通信路におけるエラー発生率が高いネットワークにおいて、データ送達の正確性を高めるために、データ送信に失敗したデータフレームの再送処理を行うプロトコルが実施されている。フレームの受信局は、あるフレームについて、受信に成功したかどうかの送達確認情報を送信局に返送する。送信局は受信局から返送された送達確認情報に基づいて受信に失敗したフレームを検出し、そのフレームを受信局に再送する。【０００３】  送信局が、受信局側から送達確認情報を得るための方法として以下に示す２種類の手法が一般に知られている。【０００４】  最初の手法は１つのフレームに対する送達確認を１つのフレームで返送する方式であり、一般的にはこの方法が使用される。【０００５】  もう一つの手法は複数のフレームに対する送達確認をまとめて１つのフレームで返送する方式である。【０００６】  前者をノーマルＡＣＫ（ＮｏｒｍａｌＡｃｋ）方式、後者をブロックＡＣＫ方式と呼ぶ。ブロックＡＣＫの手法では送達確認情報の通知に必要なフレームの数が少なくて済むため、ノーマルＡｃｋの手法を用いる場合と比較して帯域効率が良くなるが、平均伝送遅延時間が大きくなるというトレードオフがある。【０００７】  無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）におけるＭＡＣ層（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌａｙｅｒ）の規格として広く知られているＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）に対して、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）を実現するための追加仕様として、ＩＥＥＥ８０２．１１ｅ標準の策定が現在進められている。【０００８】  ＩＥＥＥ８０２．１１委員会によって発行された該標準のドラフト（Ｄｒａｆｔ  Ａｍｅｎｄｍｅｎｔ  ｔｏ  ＳＴＡＮＤＡＲＤ［ｆｏｒ］Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｘｃｈａｎｇｅ  Ｂｅｔｗｅｅｎ  Ｓｙｓｔｅｍｓ−ＬＡＮ／ＭＡＮ  Ｓｐｅｃｉｆｉｃ  Ｒｅｑｕｉｒｅｍｅｎｔｓ−Ｐａｒｔ１１：Ｗｉｒｅｌｅｓｓ  Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）ａｎｄ  Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ（ＰＨＹ）ｓｐｅｃｉｆｉｃａｔｉｏｎｓ：Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ）Ｅｎｈａｎｃｅｍｅｎｔｓ，ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，Ｎｏｖｅｍｂｅｒ  ２００３、以後「現ドラフト」と呼ぶ）においては、ノーマルＡＣＫ方式としてはＮｏｒｍａｌ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ方式（以後、ＮｏｒｍａｌＡｃｋ方式と呼ぶ）、ブロックＡＣＫ方式としては、Ｂｌｏｃｋ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ方式（以後、ＢｌｏｃｋＡｃｋ方式と呼ぶ）が定義されている。【０００９】  （ＴＩＤとＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒについて）
ＩＥＥＥ８０２．１１ｅにおいては、一連のデータ系列はＴＩＤ（ｔｒａｆｆｉｃ  ｉｄｅｎｔｉｆｉｅｒ）と呼ばれる番号で識別される。【００１０】  各ＴＩＤに属するデータフレームには、送信局が１つのフレームを送信する度に１ずつ加算される順序番号（ＩＥＥＥ８０２．１１においてはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと呼ぶ）が付与される。したがって送受信局においては、ＴＩＤとＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの組によりフレームを一意に識別できる。実際のフレームにおいてはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを格納するフィールドが有限長なので、フレームを送信し続けると番号が枯渇し、再度０から付番されることになるが、本発明では考察の簡単化のためにそのようなことは起こらないものと仮定する。【００１１】  （ＮｏｒｍａｌＡｃｋ方式）
現ドラフトで規定されているＮｏｒｍａｌＡｃｋ方式について説明する。【００１２】  ＮｏｒｍａｌＡｃｋ方式は送信局が１つのフレームを送信したら、それに対する送達確認情報を１つのフレームとして受信局から返送してもらう方式である。ＮｏｒｍａｌＡｃｋ方式では各データフレームはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの小さなものから順番に送信される。【００１３】  ＮｏｒｍａｌＡｃｋ方式におけるデータフレーム送信処理のルールは以下の通りである。【００１４】  ＜ステップ１＞
送信局はデータフレームを１つ送信する。【００１５】  ＜ステップ２＞
受信局はデータフレームの受信に成功したらＮｏｒｍａｌＡｃｋフレームを送信局宛に返送する。【００１６】  ＜ステップ３Ａ＞
送信局が受信局からＮｏｒｍａｌＡｃｋフレームを受信したら送信成功となる。【００１７】  ＜ステップ３Ｂ＞
送信局がステップ１においてデータフレームを送信してから一定期間（ＩＥＥＥ８０２．１１においてはＡｃｋ  Ｔｉｍｅｏｕｔと呼ぶ）の間にＮｏｒｍａｌＡｃｋフレームを受信できなかった場合は、同じデータフレームを再送する（同じＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒで送信する。）。【００１８】  ＜ステップ３Ｃ＞
送信局は特定のデータフレームに対して一定回数（ＩＥＥＥ８０２．１１においてはＲｅｔｒｙ  Ｌｉｍｉｔと呼ぶ）だけ再送に失敗したか、あるいはデータフレームの送信を開始してから一定時間（ＩＥＥＥ８０２．１１ｅにおいてはＤｅｌａｙ  ＢｏｕｎｄもしくはＬｉｆｅｔｉｍｅなどと呼ぶ）が経過した場合には再送の有効期限が切れたとみなされ、送信失敗となる。このような場合にはそのデータフレームはその後二度と再送されないことになる。【００１９】  ＮｏｒｍａｌＡｃｋ方式では各データフレームがＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの小さなものから順番に送信される。そのため、再送の有効期限が切れていないデータフレームに対する送達確認情報が入手できていない段階で、それよりも大きなＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームが先に送信されるというようなことはない。【００２０】  （ＮｏｒｍａｌＡｃｋ方式の具体例）
送信局がデータフレームを送信または再送して、それに対するＮｏｒｍａｌＡｃｋフレームを受信局が送信するまでの処理を１つのフェイズと呼ぶ。【００２１】  Ｎｏｒｍａｌ  Ａｃｋ方式を使用した具体的な通信について図６を参照しながら説明する。【００２２】  図の左側は通信路でのフレームの送信状態、図の右側は受信局でのバッファとフレームの上位層への通知の状態を示している。図において、ＮＡはＮｏｒｍａｌＡｃｋフレーム、ＤｎまたはｄｎはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎ番のデータフレームを示す（Ｄｎは新規送信されたデータフレームを示し、ｄｎは再送されたデータフレームを示す）。また、データフレームの下部に「○」が記載されている場合は受信局に正しく受信されたフレーム、「×」が記載されている場合は受信局に正しく受信されなかったフレームを示している。破線の四角は受信局の受信バッファを示している。Ｎｏｒｍａｌ  Ａｃｋ方式においては受信バッファは１つだけである。破線の四角内にＤｎが入っている場合は、受信したデータフレームが受信バッファ内に格納されていることを示し、破線の四角内が空の場合は受信バッファが空になっていることを示す。さらに、破線の四角において上方向に矢印が記載されている場合は、受信局においてそのバッファに格納されていたデータフレームが上位層に通知されたことを示す。データフレームが上位層に通知された場合は、そのデータフレームの内容はバッファから消去されるので、バッファを再利用することができる。【００２３】  ＜フェイズ１＞
送信局はデータフレームＤ１を送信しているが、受信局はそのデータフレームの受信に失敗しており、この場合受信局はＮｏｒｍａｌＡｃｋフレームを返送できず、バッファにも何も格納されない。【００２４】  ＜フェイズ２＞
送信局はフェイズ１においてデータフレームＤ１を送信してから、Ａｃｋ  Ｔｉｍｅｏｕｔが経過してもＮｏｒｍａｌＡｃｋフレームを受信できなかったため、Ｄ１を再送している。なお、再送フレームなので図ではｄ１と表示されている。受信局は、このデータフレームの受信に成功しているので、それをバッファに格納したらすぐに上位層に通知し、Ｎｏｒｍａｌ  Ａｃｋフレームを返信している。しかし送信局はＮｏｒｍａｌ  Ａｃｋフレームの受信に失敗している。【００２５】  ＜フェイズ３＞
送信局はフェイズ２においてデータフレームＤ１を再送してから、Ａｃｋ  Ｔｉｍｅｏｕｔが経過してもＮｏｒｍａｌＡｃｋフレームを受信できなかったため、ふたたびＤ１を再送している。受信局ではフェイズ２においてデータフレームＤ１を既に受信し上位層に通知しているので、ここで受信したデータフレームＤ１については再度バッファに格納したり、上位層に通知したりすることなしに破棄しながら、Ｎｏｒｍａｌ  Ａｃｋフレームを返信する。送信局は今回はＮｏｒｍａｌＡｃｋフレームの受信に成功している。【００２６】  ＜フェイズ４＞
送信局はフェイズ３においてＤ１のＮｏｒｍａｌ  Ａｃｋフレームの受信に成功したので、次のデータフレームＤ２を送信している。【００２７】  （ＢｌｏｃｋＡｃｋ方式）
ＢｌｏｃｋＡｃｋ方式を用いたデータ送信では、受信局における送達確認情報をまとめて返送してもらう方式であるため、受信局においてデータフレームを受信する順序が必ずしもＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの順序と同じにならない。しかし上位層に対してデータを通知する際には元の順序に並び戻す必要があり、受信局はこのためのバッファを持つ必要がある。ＮｏｒｍａｌＡｃｋ方式と比較してＢｌｏｃｋＡｃｋ方式を用いた通信ではこのバッファリソースを余計に必要とするため、ＩＥＥＥ８０２．１１ｅにおいてＢｌｏｃｋＡｃｋ方式を用いた通信はオプション仕様とされており、受信局で持つべきバッファの量も実装依存とされている。これらの理由によりＢｌｏｃｋＡｃｋ方式を用いた通信では送信に先立って送受信局の間でＢｌｏｃｋＡｃｋのセットアップを行い、お互いの能力の情報交換などを行う必要がある。ＢｌｏｃｋＡｃｋ方式を用いた通信手順の概要について、図５を参照しながら説明する。【００２８】  （１）送信局５０１は受信局５０２との間でＢｌｏｃｋＡｃｋ開始手続き（ＩＥＥＥ８０２．１１ｅにおいてはＡＤＤＢＡ処理と呼ぶ）を行う。このとき、送信局と受信局の間で予めＢｌｏｃｋＡｃｋを用いることの合意をとる。また、ＢｌｏｃｋＡｃｋ方式を用いるためには、受信局５０２から送信局５０１に予め受信バッファの大きさを通知しておく必要があるが、この受信バッファの大きさは受信可能なフレーム数（ＩＥＥＥ８０２．１１ｅにおいてはＢｕｆｆｅｒ  Ｓｉｚｅ（バッファサイズ）と呼ぶ）という形でＡＤＤＢＡ処理中に相互に通知される。【００２９】  （２）ＢｌｏｃｋＡｃｋ準備処理が完了したら送信局５０１は受信局５０２に対してデータフレームを送信する。いくつかのデータフレームを送信した後で必要に応じて複数のデータフレームに対する送達確認状況を問い合わせるためにブロックＡＣＫ送信要求フレーム（ＩＥＥＥ８０２．１１ｅにおいてはＢｌｏｃｋＡｃｋＲｅｑフレームと呼ぶ。）を送信する。【００３０】  （３）ブロックＡＣＫ送信要求フレームを受信した受信局５０２は送信局５０１に対して複数のデータフレームに対する送達確認状況を含むＢｌｏｃｋＡｃｋフレームを返送する。【００３１】  （４）上記（２）（３）の手順を繰り返すことによりデータフレーム送信が行われた後、どちらかの局がＢｌｏｃｋＡｃｋによるデータ通信を終了したい場合には、その局からＢｌｏｃｋＡｃｋ終了手続きが行われる。例えば送信局５０１がＢｌｏｃｋＡｃｋ方式によるデータ通信を終了する場合には送信局５０１から受信局５０２に対して「ＢｌｏｃｋＡｃｋ方式を終了する」というメッセージが通知される。ＢｌｏｃｋＡｃｋ方式によるデータ通信が終了した後は、両局間の通信には通常のＮｏｒｍａｌＡｃｋ方式が用いられる。【００３２】  以下にＢｌｏｃｋＡｃｋ方式の詳細な動作手順について説明する。【００３３】  ＜ステップ１＞
送信局の上位層から入力されたデータは、必要に応じて分割された後にデータフレームとして送信される。ＮｏｒｍａｌＡｃｋ方式のようにデータフレーム送信ごとにＡｃｋフレームが返送されることなく、いくつかのデータフレームが連続して送信される。【００３４】  ＜ステップ２＞
送信局は、連続して送信を行ったデータフレームに対する受信局における受信状況を知りたい場合には、受信局に対して適宜ＢｌｏｃｋＡｃｋＲｅｑフレームを送信する。このフレームには送信局が受信局での受信状況を教えてもらいたい最初のフレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（ＩＥＥＥ８０２．１１ｅにおいてはＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと呼ぶ）が含まれている。【００３５】  ＜ステップ３＞
受信局は、ＢｌｏｃｋＡｃｋＲｅｑフレームを受信したらＢｌｏｃｋＡｃｋフレームを返送する。このフレームにはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒごとにフレームの受信に成功したかどうかの情報が含まれている。現在までに受信が完了しているデータフレームの内でＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ以降のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームに関して受信に成功したかどうかの情報を含める。【００３６】  ＜ステップ４＞
送信局は、ＢｌｏｃｋＡｃｋフレームを受信したら、そこで受信失敗が示されているデータフレームの再送および新たなデータフレームの送信を行う。ＮｏｒｍａｌＡｃｋ方式では必ずＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの小さなデータフレームから順番に送信される必要があったが、ＢｌｏｃｋＡｃｋ方式では再送の有効期限が切れていないデータフレームの送信の順序に関しては大きな自由度が与えられている。つまり、再送の有効期限が切れていないデータフレームに対する送達確認情報が入手できていない段階で、それよりも大きなＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームを先に送信して構わない。また、送信局に与えられた送信可能な残り時間と各データフレームを送信するために必要な時間の相互関係などの理由によりデータフレームの送信順序は送信局側で故意に並び替えられる可能性もある。【００３７】  ただし、このとき送信局は受信局がバッファに格納不可能な個数のデータフレームを送信してはならないという規則がある。なお、受信局のバッファサイズはＢｌｏｃｋＡｃｋ開始手続きの際に知ることができる。より具体的には、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎである有効な（再送期限の切れていない）データフレームのＡｃｋを受信していない状況において、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎ＋Ｂｕｆｆｅｒ  Ｓｉｚｅ以上のデータフレームを送信してはならないということである。【００３８】  なお、このとき送信局はあるデータフレームについて再送回数がＲｅｔｒｙ  Ｌｉｍｉｔに到達したり、Ｄｅｌａｙ  Ｂｏｕｎｄが経過したりした場合は、そのデータフレームの再送をあきらめて、次以降のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒのデータフレームを送信する。【００３９】  ＮｏｒｍａｌＡｃｋ方式では、図６のフェイズ２に示すようにＮｏｒｍａｌＡｃｋフレームが送信局に正常に受信されなかった場合、受信局が既に受信したフレームを送信局が再び送信するというケースがしばしば発生する。しかしながら、ＢｌｏｃｋＡｃｋ方式ではそのようなことは滅多に発生しない。なぜなら、送信局は、ＢｌｏｃｋＡｃｋＲｅｑフレームを送信した後にＢｌｏｃｋＡｃｋフレームを受信できなかった場合、通常ＢｌｏｃｋＡｃｋフレームを受信できるまでＢｌｏｃｋＡｃｋＲｅｑフレームを再送するからである。【００４０】  現ドラフトにおいては、受信局がＢｌｏｃｋＡｃｋフレームを返送するタイミングについて、ｉｍｍｅｄｉａｔｅ  Ｂｌｏｃｋ  Ａｃｋ  ｐｏｌｉｃｙとｄｅｌａｙｅｄ  Ｂｌｏｃｋ  Ａｃｋ  ｐｏｌｉｃｙの２種類が規定されている。ｉｍｍｅｄｉａｔｅ  Ｂｌｏｃｋ  Ａｃｋ  ｐｏｌｉｃｙはＢｌｏｃｋＡｃｋＲｅｑフレームを受信したらすぐにＢｌｏｃｋＡｃｋフレームを返送する方法である。ｄｅｌａｙｅｄ  Ｂｌｏｃｋ  Ａｃｋ  ｐｏｌｉｃｙはＢｌｏｃｋＡｃｋＲｅｑフレームを受信したら、一旦Ｎｏｒｍａｌ  Ａｃｋフレームを返送し、その後受信局が送信権を得た際にＢｌｏｃｋＡｃｋフレームを返送する方法である。これらのどちらの方式を用いるかは、本発明の内容とは直接関係無いため、これらの差異の詳細については省略する。また、これらのどちらの方式を用いても本発明は適用可能であるが、以下ではｉｍｍｅｄｉａｔｅ  Ｂｌｏｃ��  Ａｃｋ  ｐｏｌｉｃｙを用いるものとして説明する。【００４１】  前述の通りＢｌｏｃｋＡｃｋ方式ではＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの順番どおりにデータフレームを受信するとは限らないので、受信局においてフレームの順序を並べなおす必要がある。すなわち受信局は未受信のデータフレームＸがある場合にはそれよりも大きなＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームについては一旦受信バッファに蓄えておき、データフレームＸを受信した後に、Ｘ以降のデータフレームをＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの順序で上位層に通知しなければならない。しかし各データフレームには再送の期限があるためデータフレームＸをいつか必ず受信できるという保障は無い。しかしデータフレームＸの再送期限が切れて送信局がこのデータフレームの再送をあきらめたという事実を受信局が知らなければ、受信局はいつまでもＸ以降のデータフレームを上位層に通知できない。そこでＢｌｏｃｋＡｃｋ方式では有効なデータフレームを通知するためにＢｌｏｃｋＡｃｋＲｅｑフレームのＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが用いられる。これについては、以下のルールがある。【００４２】  ＜ルール１＞
Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒは送信局が受信局に対して送達確認情報を教えて欲しいデータフレームの先頭のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒの値を示す。したがってＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも小さいＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒのデータフレームは、再送の期限が切れたため送信局が再送をあきらめたデータフレームであることを意味している。受信局はＢｌｏｃｋＡｃｋＲｅｑフレームを受信した際、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも小さなデータフレームの内、受信に成功しているものは全て上位層に通知することができる。【００４３】  （Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔ）
以上の説明から明らかなように、ＢｌｏｃｋＡｃｋ方式では、データフレームの順序を並べ戻すためのバッファリソースが必要となる。ＢｌｏｃｋＡｃｋ方式を終了する場合には、通常は送信局と受信局の間で明示的なＢｌｏｃｋＡｃｋ終了手続きがおこなわれるので、受信局においてＢｌｏｃｋＡｃｋ方式のために確保されていたバッファリソースを開放することができる。しかし、送信局が予期せず消失してしまったような場合は、受信局においてＢｌｏｃｋＡｃｋ方式のために確保されていたリソースが開放されず、他の処理のために流用することができないことになる。【００４４】  これを回避するために、ＩＥＥＥ８０２．１１ｅにおいてはＢｌｏｃｋＡｃｋコネクションのタイムアウトに関する規則が定められている。受信局は、ＢｌｏｃｋＡｃｋ方式の使用中に、ＢｌｏｃｋＡｃｋを使用するＴＩＤに属するデータフレームやＢｌｏｃｋＡｃｋＲｅｑフレームを一定期間（Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔと呼ぶ）受信できなかった場合、ＢｌｏｃｋＡｃｋ方式のコネクションが切断されたとみなし、ＢｌｏｃｋＡｃｋ方式のために確保されていたリソースを開放しても良いことになっている。【００４５】  （ＢｌｏｃｋＡｃｋ方式の具体例１）
ＢｌｏｃｋＡｃｋ方式における再送処理の具体例を、図７を参照しながら説明する。【００４６】  ＢｌｏｃｋＡｃｋ方式においては、送信局が複数のデータフレームを送信または再送した後でＢｌｏｃｋＡｃｋＲｅｑフレームを送信し、それに対するＢｌｏｃｋＡｃｋフレームを受信局が送信するまでの処理を１つのフェイズとする。【００４７】  図７において、ＢＡはＢｌｏｃｋＡｃｋフレーム、ＢＡ  ｒｅｑはＢｌｏｃｋＡｃｋＲｅｑフレームを示す。ＢｌｏｃｋＡｃｋ方式においては、受信バッファは複数のデータフレームを格納できるようになっている。Ａｍは受信バッファのアドレスを示している。Ａｍの枠にＤｎが入っている場合は、アドレスＡｍのバッファに受信フレームが格納されていることを示し、Ａｍの四角が空の場合はアドレスＡｍのバッファは空になっていることを示す。さらに、Ａｍにおいて上方向に矢印が記載されている場合は、受信局においてそのバッファに格納されていたデータフレームがＭＡＣ層から上位層に通知されたことを示す。その他の記述方法については、ＮｏｒｍａｌＡｃｋ方式における図６と同様なので省略する。【００４８】  事前の処理により、受信局のバッファサイズが８であることが送信局に通知されているものとする。【００４９】  ＜フェイズ１＞
フェイズ１において、送信局はＤ１〜Ｄ５のデータフレームとＢｌｏｃｋＡｃｋＲｅｑフレームとを送信している。受信局は、受信に成功したＤ１、Ｄ３、Ｄ４、Ｄ５をバッファに格納し、その中でＤ１だけを上位層に通知し、バッファＡ１を空き領域とする。なお、Ｄ２の受信に失敗しているのでＤ３以降は上位層に通知できずバッファに残されることになる。受信局より返送されたＢｌｏｃｋＡｃｋフレームにより、送信局は、Ｄ２の受信に失敗した事を知ることができる。【００５０】  ＜フェイズ２＞
受信局のＢｌｏｃｋＡｃｋフレームの報告を受けた送信局はフェイズ２においてＤ２を再送している。さらに、前のフェイズではＤ５までを送信していたので、その次のＤ６以降を送信している。受信局は、Ｄ２の受信に成功しているので、前のフェイズでの抜けが埋まり、Ｄ５までを上位層に通知することができる。そのため、バッファＡ２〜Ａ５は空きとなる。しかし、Ｄ６の受信に失敗しているので、それ以降は上位層に通知しない。なお、前のフェイズでＤ１を受信した後すぐに上位層に通知されたのでバッファＡ１は空きとなっており、Ｄ９の格納のために再利用されている。受信局より返送されたＢｌｏｃｋＡｃｋフレームにおいて、Ｄ６とＤ８の受信に失敗した事が送信局に対して通知される。【００５１】  ＜フェイズ３＞
受信局のＢｌｏｃｋＡｃｋフレームの報告を受けた送信局は、フェイズ３においてＤ６とＤ８とを再送している。さらに、前のフェイズではＤ９までを送信していたので、その次のＤ１０以降を送信している。受信局は、Ｄ６の受信に成功し、Ｄ８の受信に失敗しているので、Ｄ６〜Ｄ７を上位層に通知することができる。そのため、バッファＡ６〜Ａ７は空きとなる。受信局より返送されたＢｌｏｃｋＡｃｋフレームにおいて、Ｄ８の受信に失敗した事が送信局に対して通知される。【００５２】  ＜フェイズ４＞
受信局のＢｌｏｃｋＡｃｋフレームの報告を受けた送信局は、フェイズ４においてＤ８を再送している。さらに、前のフェイズではＤ１２までを送信していたので、その次のＤ１３以降を送信している。この段階で送信局は、有効なデータフレームＤ８の送達確認情報をまだ入手できておらず、受信局のバッファサイズが８であることを事前に通知されているので、Ｄ１６を送信すると受信局でバッファが不足することがわかる。そのため、新たなデータフレームの送信はＤ１５までにしてＢｌｏｃｋＡｃｋＲｅｑフレームを送信している。受信局は、Ｄ８の受信に成功し、Ｄ１４の受信に失敗しているので、Ｄ８〜Ｄ１３を上位層に通知することができる。そのため、バッファＡ７以外は空きとなる。【００５３】  （ＢｌｏｃｋＡｃｋ方式の具体例２）
ＢｌｏｃｋＡｃｋ方式における通信において、データフレームの送信が成功する前に送信局が再送をあきらめる場合の具体例を図８に示す。データフレームの再送有効期限を表す情報としてＢｌｏｃｋＡｃｋＲｅｑフレームのＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが用いられる。図にはこの情報をＳＳＮと省略して書き入れてある。その他の記述方法については、（ＢｌｏｃｋＡｃｋ方式の具体例１）と同様であるので省略する。
なお以降の考察では簡単化のために、ＢｌｏｃｋＡｃｋＲｅｑフレームとＢｌｏｃｋＡｃｋフレームについては常に受信に成功すると仮定している。
また、事前の処理により、受信局のバッファサイズが８であることが送信局に通知されているものとする。【００５４】  ＜フェイズ１＞
フェイズ１では、送信局はＤ１〜Ｄ５のデータフレームとＢｌｏｃｋＡｃｋＲｅｑフレームとを送信している。受信局は、受信に成功したＤ１、Ｄ３、Ｄ４、Ｄ５をバッファに格納し、Ｄ１だけを上位層に通知する。そのため、バッファＡ１は空きとなる。受信局より返送されたＢｌｏｃｋＡｃｋフレームにより、Ｄ２の受信に失敗した事が送信局に対して通知される。【００５５】  ＜フェイズ２＞
受信局のＢｌｏｃｋＡｃｋフレームの報告を受けた送信局は、フェイズ２においてＤ２を再送している。さらに、送信局は、Ｄ６以降を送信している。このとき送信局はＤ２に対する送達確認情報をまだ入手しておらず、かつＤ２の再送期限がまだ切れていないためＢｌｏｃｋＡｃｋＲｅｑフレームのＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを２に設定する。ここでＤ２を受信するためのＡ２以外の全バッファは使用済みである。つまり、Ｄ３以降のデータフレームは受信に成功しているが、上位層に通知できない状態となっている。受信局より返送されたＢｌｏｃｋＡｃｋフレームにより、Ｄ２の受信に再び失敗した事が送信局に対して通知される。【００５６】  ＜フェイズ３＞
受信局のＢｌｏｃｋＡｃｋフレームの報告を受けた送信局は、フェイズ３においてＤ２を再送している。ただし、送信局は、有効なデータフレームＤ２の送達確認情報をまだ入手できておらず、受信局のバッファサイズが８であることから、Ｄ１０を送信すると受信局でバッファが不足することが算出できるので、それ以降のデータフレームは送信しない。【００５７】  フェイズ３では、受信局より返送されたＢｌｏｃｋＡｃｋフレームにより、Ｄ２の受信に再び失敗した事が通知される。ここで、Ｄ２の再送期限が切れ、送信局はＤ２の再送をあきらめたものとする。【００５８】  ＜フェイズ４＞
送信局は、前のフェイズまでにＢｌｏｃｋＡｃｋフレームを通じて受信局がＤ３からＤ９のデータフレームを受信できたことを知っている。そのため、送信局は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを１０にしたＢｌｏｃｋＡｃｋＲｅｑフレームを送信し、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが９以下のデータフレームについては再送を行わないということを受信局に対して通知する。これにより受信局は、前のフェイズまでに受信したＤ３からＤ９を上位層に通知し、全てのバッファを空き状態に戻すことができる。この場合送信局は次のフェイズではＤ１０からＤ１７までのデータフレームを送信できるようになる。【００５９】  （ＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式への切り替え）
通常ＢｌｏｃｋＡｃｋ方式の方がＮｏｒｍａｌＡｃｋ方式よりも帯域効率が良いが、ＢｌｏｃｋＡｃｋＲｅｑフレームで問い合わせたいデータフレームの数が少ない場合にはＮｏｒｍａｌＡｃｋ方式を用いる方がＢｌｏｃｋＡｃｋ方式よりも効率が良い。このため、ＡＤＤＢＡ処理によってＢｌｏｃｋＡｃｋ方式を用いるという設定が行われたＴＩＤに属するデータの通信においても、帯域効率を向上させるために一時的にＮｏｒｍａｌＡｃｋ方式を用いても良いことになっている。【００６０】  各データフレームには、そのデータフレームがＮｏｒｍａｌＡｃｋ方式とＢｌｏｃｋＡｃｋ方式のどちらの方式として送信されているかを示すためのフィールド（Ａｃｋ  Ｐｏｌｉｃｙフィールドと呼ぶ）がある。ＢｌｏｃｋＡｃｋを用いる設定を行ったＴＩＤに属するデータ送信に対しても各データフレームのＡｃｋ  ＰｏｌｉｃｙフィールドでＮｏｒｍａｌＡｃｋ方式を指定することでＮｏｒｍａｌＡｃｋ方式を使用することができる。【００６１】  例えば図８のフェイズ３ではＤ２以外のデータフレームを送信できない状態になっており、このような場合には、「ｄ２−ＢｌｏｃｋＡｃｋＲｅｑフレーム−ＢｌｏｃｋＡｃｋフレーム」というシーケンスよりも、「ｄ２−ＮｏｒｍａｌＡｃｋフレーム」というシーケンスを用いる方がより短時間でＤ２の送達確認状況を知ることができる。【００６２】  例えばこのような場合に、送信局は図８のフェイズ３におけるＤ２のＡＣＫ  ＰｏｌｉｃｙフィールドにＮｏｒｍａｌＡｃｋ方式を示す情報含めて送信して構わない。それにより、受信局もＤ２がＮｏｒｍａｌＡｃｋ方式に従うことを知る。この様子を図９に示す。【００６３】  図９では、フェイズ３で受信局がＤ２の受信に成功したと仮定している。フェイズ３において、受信局は、Ｄ２〜Ｄ９を上位層に通知することができ、全てのバッファを空き状態にすることができる。【００６４】  図９のフェイズ４以降では、複数のデータフレームに対する送達確認情報を得ることができるので、各データフレームのＡＣＫ  ＰｏｌｉｃｙフィールドにＢｌｏｃｋＡｃｋ方式を示す情報を含めて送信している。【００６５】  なお、どのような条件でＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に移行するかという判定基準は規定されていない。【００６６】  （第１の課題）
これまでに説明したとおり、送信局は、ＢｌｏｃｋＡｃｋ方式を用いるという設定を行ったＴＩＤのデータ系列に対して、帯域効率を向上させるという目的でＮｏｒｍａｌＡｃｋ  ｐｏｌｉｃｙを用いたデータフレーム送信を混用することが可能である。しかし現在の仕様書では、上記のＮｏｒｍａｌＡｃｋ  ｐｏｌｉｃｙの送信を用いてどのような順序でデータフレームを送信して良いかに関する記述が見当たらない。この時に用いられるＮｏｒｍａｌＡｃｋ方式で送信されるデータフレームは、本来ならばＢｌｏｃｋＡｃｋ方式を用いて送信されるべきデータフレームの時間短縮のために代用されるものである。このことを考えると、送受信局とも下記のＢｌｏｃｋＡｃｋ方式のルールに従って挙動すると考えられる。【００６７】  ＜送信局のルール＞
再送の有効期限が切れていないデータフレームに対する送達確認情報が入手できていない段階で、それよりも大きなＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームを先に送信しても構わない。送信局に与えられた送信可能な残り時間と各データフレームを送信するために必要な時間の相互関係などの理由によりデータフレームの送信順序は送信局側で故意に並び替えられる可能性もある。ただしＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎである有効な（再送期限の切れていない）データフレームのＡｃｋを受信していない状況において、Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎ＋Ｂｕｆｆｅｒ  Ｓｉｚｅ以上のデータフレームを送信してはならない。【００６８】  ＜受信局のルール＞
受信に成功していないデータフレームＸ（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ＝ｘ）が存在する場合には、ｘよりも大きいＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームを上位層に対して通知してはいけない。Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ＝ｙ（＞ｘ）を持つＢｌｏｃｋＡｃｋＲｅｑフレームを受信することでｘとｙの間のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つ受信データを上位層に対して通知することが可能となる。【００６９】  しかし送信局がＮｏｒｍａｌＡｃｋを使用している間は上記のＢｌｏｃｋＡｃｋＲｅｑフレームが送信されないので送信局が特定のフレームの再送をあきらめたという事実を受信局は知ることができないという課題があった。【００７０】  第１の課題が発生した場合の例について図１０を参照しながら説明する。【００７１】  図１０は、ＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替わり、かつ、送信するべきデータフレームが２つある場合の処理手順である。【００７２】  図１０に示されるように、送信局は、フェイズ１および２において、ＢｌｏｃｋＡｃｋ方式でデータフレームを送信している。そして、受信局は、フェイズ１および２において、Ｄ２およびＤ５のデータフレームの受信に失敗したことをＢｌｏｃｋＡｃｋフレームにより送信局に通知している。【００７３】  送信局は、フェイズ１および２の両方でＤ２およびＤ５のデータフレームの受信に失敗したことを受けて、フェイズ３でＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替えている。そして、送信局は、フェイズ３からフェイズｎにおいて、Ｄ２のデータフレームをＮｏｒｍａｌＡｃｋ方式で送信するが、受信局は、いずれのフェイズにおいても、Ｄ２のデータフレームの受信に失敗している。【００７４】  ここで、フェイズｎが終了した時点で、送信局は、Ｄ２の再送期限が切れたことを認識し、Ｄ２の再送をあきらめる。そのため、送信局は、次のフェイズｎ＋１において、フェイズ１および２で受信に失敗していた残りのＤ５のデータフレームをＮｏｒｍａｌＡｃｋ方式で送信する。一方、受信局は、フェイズｎ＋１において、Ｄ５のデータフレームの受信に成功するが、送信局がＤ２のデータフレームの再送をあきらめたという事実を認識していいないため、Ｄ２以降のデータフレームを上位層に通知することができないという第１の課題が生じる。【００７５】  また送信局が一時的なＮｏｒｍａｌＡｃｋ方式からＢｌｏｃｋＡｃｋ方式に復帰するまでの時間に関する規定が無い。そのため、これが長引いた場合には未受信データフレームが無効になったという事実を受信局が知るまでの遅延が大きくなり、したがってそれに続いて正常に受信したデータフレームを受信局が上位層に通知できるまでの遅延が大きくなるという課題があった。【００７６】  通常であれば、送信局がＢｌｏｃｋＡｃｋ方式によるデータ通信を終了し、ＮｏｒｍａｌＡｃｋ方式に移行する場合には、送信局から受信局に対して「ＢｌｏｃｋＡｃｋ方式を終了する」というメッセージが別途通知される。しかしながら、この通知メッセージ自体にも再送の期限が存在するので、受信局が再送の期限内に上記通知メッセージを受信できなかった場合には、送信局がＮｏｒｍａｌ���ｃｋ方式に完全に移行したという事実は受信局に対して明示的には伝わらない場合がある。この際にも上記の「一時的なＮｏｒｍａｌＡｃｋ方式」が長引いた場合と同じ問題が発生するという課題があった。【００７７】  （第２の課題）
上記のように送信局がＢｌｏｃｋＡｃｋ方式によるデータ送信を終了し、ＮｏｒｍａｌＡｃｋ方式に完全に移行したにもかかわらず、受信局に対してその事実が明示的には伝わらない場合には、受信局は送信局からＮｏｒｍａｌＡｃｋ方式としてデータフレームを受信し続けることになる。【００７８】  現ドラフトにおいてはＢｌｏｃｋＡｃｋのコネクションのタイムアウト判定を行う際に、Ａｃｋ  Ｐｏｌｉｃｙには関わらずそのＢｌｏｃｋＡｃｋを設定したＴＩＤに属するデータを受信したかどうかによって判定を行う規定になっている。そのため、上記状況ではタイムアウトは検出されず、受信局は上記状況においていつまで経ってもＢｌｏｃｋＡｃｋ用に確保したリソースを開放できないという課題があった。【００７９】  第２の課題が発生した場合の例について図１１を参照しながら説明する。【００８０】  図１１では、受信局におけるフレームの受信と送信状態及び、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔ検出のためのタイマの状態を示している。タイマによって、ＢｌｏｃｋＡｃｋＲｅｑフレームで示されたＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔが経過したことを検出したらＢｌｏｃｋＡｃｋ方式が終了したと判定するものとする。Ｔｎはこのタイマを初期値に戻すタイミングを示している。【００８１】  ＤｎはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎのデータフレーム、ｄｎはＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがｎのデータフレームの再送、ＢＡｒｅｑはＢｌｏｃｋＡｃｋＲｅｑフレーム、ＢＡはＢｌｏｃｋＡｃｋフレームを示している。また、Ｄｎ及びｄｎが一重線で囲んであるデータフレームはＡｃｋ  ＰｏｌｉｃｙがＢｌｏｃｋＡｃｋ方式として送信されたことを示し、二重線で囲んであるデータフレームはＡｃｋ  ＰｏｌｉｃｙがＮｏｒｍａｌＡｃｋ方式として送信されたことを示している。【００８２】  なお、本来はＡＤＤＢＡ処理が完了した時点でタイマが開始されるべきであるが、ここでは省略する。【００８３】  図１１ではＢｌｏｃｋＡｃｋ方式を使用してフレームを送信している時に、途中でＮｏｒｍａｌＡｃｋ方式に切り替えている。このとき送信局から受信局に対して「ＢｌｏｃｋＡｃｋ方式を終了する」というメッセージが送信されるが、そのメッセージの再送期限内に受信局がそのメッセージゐ正しく受信できなかったと想定している。現ドラフトに従うとＡｃｋ  Ｐｏｌｉｃｙの指定に関わらずデータフレームを受信したときにはいつでもタイマをリセットするので、送信局がＢｌｏｃｋＡｃｋ方式の使用を終了してＮｏｒｍａｌＡｃｋ方式に切り替えたにも関わらず受信局では、ＢｌｏｃｋＡｃｋ方式の終了を検出できなくなっている。図１１においてはＴ４〜Ｔ１０のタイミングでタイマがリセットされるため、タイマがＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔに達せず受信局はＢｌｏｃｋＡｃｋ方式のためのリソースを開放することができない。
【発明の開示】
【００８４】［第１の課題を解決するための手段］
上記の第１の課題を解決するため、本発明に係る通信方法では以下の２つのルール両方を追加する。
【００８５】  ＜追加ルール１＞
ＢｌｏｃｋＡｃｋ方式を用いて通信を行っている場合に、送信局がｘのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームをＮｏｒｍａｌＡｃｋ方式で送信した場合は、ｘ以前のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームについては、再送の有効期限が切れていることを意味するものとする。したがって、送信局はｘのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームをＮｏｒｍａｌＡｃｋ方式で送信した後でｙ（ｙはｘより小さい番号）のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームを送信してはならないものとする。
【００８６】  ＜追加ルール２＞
ＢｌｏｃｋＡｃｋ方式を用いて通信を行っている場合に、受信局がＡｃｋ  ＰｏｌｉｃｙフィールドにおいてＮｏｒｍａｌＡｃｋ方式が指定されているデータフレームを受信したら、そのデータフレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも小さなＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームの内、受信に成功しているものは全て上位層に通知しても良いものとする。
【００８７】［第２の課題を解決するための手段］
上記の第２の課題を解決するため、本発明に係る通信方法ではＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔの検出方法を以下の何れかのルールに変更する。
【００８８】  ＜変更ルール１＞
受信局では、ＢｌｏｃｋＡｃｋ方式の使用中に、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される時間内にＡｃｋ  ＰｏｌｉｃｙがＢｌｏｃｋＡｃｋ方式を示しているデータフレームを受信できなかった場合は、ＢｌｏｃｋＡｃｋ方式の使用が終了したとみなし、ＢｌｏｃｋＡｃｋ方式のために確保されていたリソースを開放しても良い。
【００８９】  ＜変更ルール２＞
受信局では、ＢｌｏｃｋＡｃｋ方式の使用中に、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される時間内にＢｌｏｃｋＡｃｋＲｅｑフレームを受信できなかった場合は、ＢｌｏｃｋＡｃｋ方式の使用が終了したとみなし、ＢｌｏｃｋＡｃｋ方式のために確保されていたリソースを開放しても良い。
【００９０】  ＜変更ルール３＞
受信局では、ＢｌｏｃｋＡｃｋ方式の使用中に、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される時間内にＡｃｋ  ＰｏｌｉｃｙがＢｌｏｃｋＡｃｋ方式を示しているデータフレーム、または、ＢｌｏｃｋＡｃｋＲｅｑフレームを受信できなかった場合は、ＢｌｏｃｋＡｃｋ方式の使用が終了したとみなし、ＢｌｏｃｋＡｃｋ方式のために確保されていたリソースを開放しても良い。
【００９１】［第１の課題を解決するための手段の詳細］
本発明に係る送信局は、データフレームに所定の順序番号が付番されて送信され、前記データフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法に従う送信局であって、ある順序番号のデータフレームをノーマルＡＣＫ方式で送信した場合は、前記順序番号よりも古い順序番号のデータフレームを送信しない送信局である。
【００９２】  また、本発明に係る受信局は、データフレームに所定の順序番号が付番されて送信され、前記データフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法に従う受信局であって、ノーマルＡＣＫ方式を要求するデータフレームを受信した際に、その時点で受信済みだが上位層に通知していないデータフレームの内、前記ノーマルＡＣＫ方式を要求するデータフレームの順序番号よりも古い順序番号を持つデータフレームを上位層に通知する受信局である。
【００９３】  また、本発明に係る通信方法は、データフレームに所定の順序番号が付番されて送信され、前記データフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法であって、送信局において、ある順序番号のデータフレームをノーマルＡＣＫ方式で送信した場合は、前記順序番号よりも古い順序番号のデータフレームを送信せず、受信局において、ノーマルＡＣＫ方式を要求するデータフレームを受信した際に、その時点で受信済みだが上位層に通知していないデータフレームの内、前記ノーマルＡＣＫ方式を要求するデータフレームの順序番号よりも古い順序番号を持つデータフレームを上位層に通知する通信方法である。
【００９４】  また、本発明に係る通信方法は、ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、あるＴＩＤのストリームについて、ストリームの送信局において、あるＳｅｑｕｅｎｃｅ  ＮｕｍｂｅｒのＱｏＳ  Ｄａｔａ  ＦｒａｍｅをＡｃｋ  ＰｏｌｉｃｙフィールドにＮｏｒｍａｌ  Ａｃｋを示す情報を含めて送信した場合は、前記Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも小さな値を持つＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを行わず、あるＴＩＤのストリームについて、ストリームの受信局において、Ａｃｋ  Ｐｏｌｉｃｙ  ｆｉｅｌｄにＮｏｒｍａｌ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信した場合は、その時点で受信済みだが上位層に通知していないＱｏＳ  Ｄａｔａ  Ｆｒａｍｅの内、前記受信したＱｏＳ  Ｄａｔａ  Ｆｒａｍｅに含まれているＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも小さなＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを上位層に通知する通信方法である。
【００９５】  これらの方法を用いる事により、送信局がＢｌｏｃｋＡｃｋ方式の使用中に一時的に使用したＮｏｒｍａｌＡｃｋ方式からＢｌｏｃｋＡｃｋ方式に復帰するまでの時間が長引いた際に、未受信データフレームは無効になったという事実を受信局が知るまでの遅延が大きくなり、したがってそれに続く正常受信データフレームを受信局が上位層に通知できるまでの遅延が大きくなる、という課題を解決できる。
【００９６】［第２の課題を解決するための手段の詳細］
本発明に係る受信局は、受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法に従う受信局であって、ノーマルＡＣＫ方式を要求するデータフレームを受信したかどうかに関わらず、所定の期間内に、ブロックＡＣＫ方式を要求するデータフレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する受信局である。
【００９７】  また、本発明に係る通信方法は、受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法であって、受信局において、ノーマルＡＣＫ方式を要求するデータフレームを受信したかどうかに関わらず、所定の期間内に、ブロックＡＣＫ方式を要求するデータフレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する通信方法である。
【００９８】  また、本発明に係る受信局は、受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法に従う受信局であって、データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する受信局である。
【００９９】  また、本発明に係る通信方法は、受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法であって、受信局において、データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する通信方法である。
【０１００】  また、本発明に係る受信局は、受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法に従う受信局であって、データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ方式を要求するデータフレーム、または、ブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する受信局である。
【０１０１】  また、本発明に係る通信方法は、受信したデータフレームに対する受信局からのＡＣＫとしてノーマルＡＣＫ方式とブロックＡＣＫ方式の両方が同時に使用される通信方法であって、受信局において、データフレームを受信したかどうかに関わらず、所定の期間内にブロックＡＣＫ方式を要求するデータフレーム、または、ブロックＡＣＫ送信要求フレームを受信できなかった場合には、ブロックＡＣＫ方式の使用が終了したとみなし、ブロックＡＣＫ方式のために使用していたリソースを開放する通信方法である。
【０１０２】  また、本発明に係る通信方法は、ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、あるＴＩＤのストリームについて、受信局において、Ａｃｋ  ＰｏｌｉｃｙフィールドにＮｏｒｍａｌ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信したかどうかに関わらず、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される期間内にＡｃｋ  ＰｏｌｉｃｙフィールドにＢｌｏｃｋ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信できなかった場合は、Ｂｌｏｃｋ  Ａｃｋの伝送のために使用していたリソースを開放する通信方法である。
【０１０３】  また、本発明に係る通信方法は、ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、あるＴＩＤのストリームについて、受信局において、ＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信したかどうかに関わらず、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される期間内に、Ｂｌｏｃｋ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  Ｒｅｑｕｅｓｔ  Ｆｒａｍｅを受信できなかった場合は、Ｂｌｏｃｋ  Ａｃｋの伝送のために使用していたリソースを開放する通信方法である。
【０１０４】  また、本発明に係る通信方法は、ＩＥＥＥ８０２．１１標準（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ．８０２．１１，１９９９  Ｅｄｉｔｉｏｎ）及びＩＥＥＥ８０２．１１ｅ標準のドラフト（ＩＥＥＥ  Ｐ８０２．１１ｅ／Ｄ６．０，Ｎｏｖｅｍｂｅｒ  ２００３）に準拠する通信方法であって、あるＴＩＤのストリームについて、受信局において、Ａｃｋ  ＰｏｌｉｃｙフィールドにＮｏｒｍａｌ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅを受信したかどうかに関わらず、Ｂｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔで示される期間内にＡｃｋ  ＰｏｌｉｃｙフィールドにＢｌｏｃｋ  Ａｃｋを示す情報が含まれているＱｏＳ  Ｄａｔａ  Ｆｒａｍｅ、または、Ｂｌｏｃｋ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  Ｒｅｑｕｅｓｔ  Ｆｒａｍｅを受信できなかった場合は、Ｂｌｏｃｋ  Ａｃｋの伝送のために使用していたリソースを開放する通信方法である。
【０１０５】  これらの方法を用いる事により、送信局がＢｌｏｃｋＡｃｋ方式によるデータ通信を終了し、ＮｏｒｍａｌＡｃｋ方式に移行する場合に、送信局から受信局に対して送信される「ＢｌｏｃｋＡｃｋ方式を終了する」というメッセージを受信局がそのメッセージの再送期限内に正しく受信できなかった状況において、受信局においてタイムアウトが検出されず、受信局はいつまで経ってもＢｌｏｃｋＡｃｋ用に確保したリソースを開放できないという課題を解決できる。
【０１０６】  また、本発明に係る通信プログラムは、コンピュータに上記の方法における送信局として動作させるための手順を記述した通信プログラムである。
【０１０７】  また、本発明に係る通信プログラムは、コンピュータに上記の方法における受信局として動作させるための手順を記述した通信プログラムである。
【０１０８】  また、本発明に係るプログラムを格納したコンピュータ読み取り可能な記録媒体は、上記の通信プログラムを格納している。
【図面の簡単な説明】
【０１０９】
【図１】本発明の第１の実施の形態における処理手順である。
【図２】本発明の第２の実施の形態における、受信局でのＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔの検出方法のタイミング図である。
【図３】本発明の第３の実施の形態における、受信局でのＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔの検出方法のタイミング図である。
【図４】本発明の第４の実施の形態における、受信局でのＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔの検出方法のタイミング図である。
【図５】従来及び本発明の通信方法において、ＢｌｏｃｋＡｃｋ方式を用いた通信手順の概要である。
【図６】従来の通信方法におけるＮｏｒｍａｌＡｃｋ方式の処理手順の具体例である（ＮｏｒｍａｌＡｃｋフレームの受信に失敗した場合）。
【図７】従来の通信方法におけるＢｌｏｃｋＡｃｋ方式の処理手順の第１の具体例である。（再送が完了した場合）
【図８】従来の通信方法におけるＢｌｏｃｋＡｃｋ方式の処理手順の第２の具体例である。（ｄ２の再送をあきらめた場合）
【図９】従来の通信方法においてＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替わった時の処理手順である。（送信するべきデータフレームが１つの場合）
【図１０】従来の通信方法においてＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替わった時の処理手順である。（送信するべきデータフレームが２つの場合）
【図１１】従来の受信局でのＢｌｏｃｋ  Ａｃｋ  Ｔｉｍｅｏｕｔの検出方法のタイミング図である。
【図１２】本発明の第１の実施の形態における送信局の構成を示すブロック図である。
【図１３】本発明の第１の実施の形態における受信局の構成を示すブロック図である。
【図１４】本発明の第２の実施の形態における受信局の構成を示すブロック図である。
【発明を実施するための最良の形態】
【０１１０】  以下、実施例および比較例により、本発明をさらに詳細に説明するが、本発明はこれらにより何ら限定されるものではない。【０１１１】  以下の実施の形態におけるＢｌｏｃｋＡｃｋ方式のセットアップ手順は従来と同様であり図５に示すようなものである。【０１１２】  なお、ここではＩＥＥＥ８０２．１１標準及び、ＩＥＥＥ８０２．１１ｅの現ドラフトに従う通信方法において本発明を適用した例について述べているが、別の通信方法においても本発明は適用可能である。【０１１３】  （第１の実施の形態）
本発明の第１の実施の形態について、図１，図１２および図１３を参照しながら説明する。第１の実施の形態は前記の第１の課題が解決された例である。【０１１４】  図１２は、本実施形態に係る送信局１の構成を示すブロック図である。送信局１は、ストリームデータ等を複数のデータフレームに分割し、分割したデータフレームを受信局に送信するものである。【０１１５】  図１２に示されるように、送信局１は、送信部１１、受信部１２、Ａｃｋ要求フレーム生成部１３、データフレーム生成部１４、エラーフレーム処理部１６、未送信最小フレーム番号記憶部１７、受信局バッファサイズ記憶部１８、Ａｃｋ方式切替部１９、およびエラーフレーム番号記憶部２０を備えている。【０１１６】  送信部１１は、受信局に対して、各種フレームを送信するものである。例えば、送信部１１は、データフレーム生成部１４が生成したデータフレームおよびＡｃｋ要求フレーム生成部１３が生成したＢｌｏｃｋＡｃｋＲｅｑフレームを受信局に送信する。【０１１７】  受信部１２は、受信局からの各種フレームを受信するものである。例えば、受信部１２は、受信局からＢｌｏｃｋＡｃｋフレームおよびＮｏｒｍａｌＡｃｋフレームを受信する。そして、受信部１２は、受信したＢｌｏｃｋＡｃｋフレームおよびＮｏｒｍａｌＡｃｋフレームをエラーフレーム処理部１６に送る。【０１１８】  受信局バッファサイズ記憶部１８は、受信局においてＢｌｏｃｋＡｃｋ方式を用いる際のバッファサイズを記憶するものである。送信局１と受信局との間で行われる上述したＢｌｏｃｋＡｃｋ開始手続き（ＡＤＤＢＡ処理）において受信局から通知されたバッファサイズは、図示しない受信局バッファサイズ書き込み部により、受信局バッファサイズ記憶部１８に書き込まれる。【０１１９】  未送信最小フレーム番号記憶部１７は、送信していないデータフレームの中で最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒである未送信最小フレーム番号を記憶するものである。未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号は、データフレーム生成部１４により更新される。【０１２０】  エラーフレーム番号記憶部２０は、受信局において受信に失敗したフレーム（エラーフレーム）が持つＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒであるエラーフレーム番号を記憶するものである。エラーフレーム番号記憶部２０が記憶するエラーフレーム番号は、エラーフレーム処理部１６により更新される。【０１２１】  Ａｃｋ方式切替部１９は、フレームの送受信方式を、ＢｌｏｃｋＡｃｋ方式とＮｏｒｍａｌＡｃｋ方式とに切り替えるものである。Ａｃｋ方式切替部１９は、切り替えたＡｃｋ方式の種類を示す情報、つまり、ＢｌｏｃｋＡｃｋ方式またはＮｏｒｍａｌＡｃｋ方式を示す情報をデータフレーム生成部１４に出力する。【０１２２】  Ａｃｋ方式切替部１９におけるＡｃｋ方式の切り替え基準は特に限定されない。本実施形態では、例えば、Ａｃｋ方式切替部１９は、初期設定としてＢｌｏｃｋＡｃｋ方式を選択する。そして、Ａｃｋ方式切替部１９は、ＢｌｏｃｋＡｃｋ方式でデータ通信を行っている際、次回のデータフレーム送信において、未送信のデータフレームを送信できない場合に、ＢｌｏｃｋＡｃｋ方式から��ｏｒｍａｌＡｃｋ方式に切り替えるものとする。【０１２３】  なお、Ａｃｋ方式切替部１９は、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号、受信局バッファサイズ記憶部１８が記憶するバッファサイズ、および、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号を基にして、次回のフレーム送信において、未送信のデータフレームを送信できないことを判断することができる。上述したように、ＢｌｏｃｋＡｃｋ方式においては、エラーフレーム番号のうち最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（ｎ）＋バッファサイズ（例えば、８）以上のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに対応するデータフレームを送信できない。なぜなら、受信局において、該データフレームを格納するための受信バッファの空き容量がないからである。そのため、Ａｃｋ方式切替部１９は、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号のうち最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと受信局バッファサイズ記憶部１８が記憶するバッファサイズとを加えた値が、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号と同じである場合、次回のフレーム送信において、未送信のデータフレームを送信できないと判断し、ＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替える。【０１２４】  データフレーム生成部１４は、受信局へ送信するデータフレームを生成するものである。データフレーム生成部１４は、ＢｌｏｃｋＡｃｋ方式でデータフレームを生成するＢｌｏｃｋＡｃｋ方式生成部１４ａと、ＮｏｒｍａｌＡｃｋ方式でデータフレームを生成するＮｏｒｍａｌＡｃｋ方式生成部１４ｂとを備えている。【０１２５】  ＢｌｏｃｋＡｃｋ方式生成部１４ａは、Ａｃｋ方式切替部１９からＢｌｏｃｋＡｃｋ方式である旨のＡｃｋ方式種別情報を受けた場合に機能する構成部である。ＢｌｏｃｋＡｃｋ方式生成部１４ａは、Ａｃｋ  ＰｏｌｉｃｙフィールドをＢｌｏｃｋＡｃｋ方式としてデータフレームを生成する。ＢｌｏｃｋＡｃｋ方式生成部１４ａは、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号、受信局バッファ容量記憶部１８が記憶するバッファサイズ、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号を基に、１つのフェイズにおいて送信するデータフレームを生成する。なお、上述したように、ＢｌｏｃｋＡｃｋ方式においては、送信局１が複数のデータフレームを送信または再送した後でＢｌｏｃｋＡｃｋＲｅｑフレームを送信し、それに対するＢｌｏｃｋＡｃｋフレームを受信局が送信するまでの処理を１つのフェイズとする。【０１２６】  ＢｌｏｃｋＡｃｋ方式生成部１４ａは、生成したデータフレームを送信部１１に送る。これにより、送信部１１は、１つのフェイズにおいて送信すべきデータフレームを連続して送信する。【０１２７】  また、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、送信部１１がデータフレームを送信した後、１つのフェイズで送信したデータフレームの中で最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒである送信最小フレーム番号をＡｃｋ要求フレーム生成部１３に出力する。【０１２８】  さらに、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、未送信であったデータフレームを送信した場合���は、未送信最小フレーム番号記憶部１７の未送信最小フレーム番号を更新する。【０１２９】  例えば、未送信最小フレーム番号が「６」であり、バッファサイズが「８」であり、エラーフレーム番号が「２，５」である場合を仮定する。このとき、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、データフレームＤ２およびＤ５、ならびに、エラーフレーム番号の最小値「２」とバッファサイズ「８」との加算値「１０」未満の未送信のデータフレームＤ６・Ｄ７・Ｄ８・Ｄ９を、１つのフェイズで送信するデータフレームとして生成し、送信部１１に送る。さらに、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、送信したデータフレームの中の最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒである送信最小フレーム番号「２」をＡｃｋ要求フレーム生成部１３に出力する。【０１３０】  ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、Ａｃｋ方式切替部１９からＮｏｒｍａｌＡｃｋ方式である旨のＡｃｋ方式種別情報を受けた場合に機能するブロックである。ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、Ａｃｋ  ＰｏｌｉｃｙフィールドをＮｏｒｍａｌＡｃｋ方式としてデータフレームを生成する。【０１３１】  ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、エラーフレーム番号記憶部２０がエラーフレーム番号を記憶している場合、該エラーフレーム番号に対応する一つのデータフレームを生成する。なお、エラーフレーム番号記憶部２０が複数のエラーフレーム番号を記憶している場合、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、該複数のエラーフレーム番号の中で最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに対応する一つのデータフレームを生成する。【０１３２】  一方、エラーフレーム番号記憶部２０がエラーフレーム番号を記憶していない場合、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号に対応する一つのデータフレームを生成する。なお、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、上記ＢｌｏｃｋＡｃｋ方式生成部１４ａと同様に、未送信であったデータフレームを送信した場合、未送信最小フレーム番号記憶部１７の未送信最小フレーム番号を更新する。【０１３３】  ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、生成した一つのデータフレームを送信部１１に送る。これにより、送信部１１は、１つのフェイズにおいて１つのデータフレームを送信する。【０１３４】  このように、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号および未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号の中で、最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに対応するデータフレームを生成する。そのため、ＢｌｏｃｋＡｃｋ方式生成部１４ａおよびＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂがあるＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒのデータフレームを送信部１１を介して送信した後、該Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも小さいＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒのデータフレームを送信することがない。【０１３５】  エラーフレーム処理部１６は、受信部１２が受信したＢｌｏｃｋＡｃｋフレームまたはＮｏｒｍａｌＡｃｋフレームを基に、受信局で受信に失敗したデータフレームに対応するエラーフレーム番号をエラーフレーム番号記憶部２０に書き込む。また、エラーフレーム処理部１６は、受信局で受信に成功したデータフレームに対応するフレーム番号がエラーフレーム番号記憶部２０に記憶されている場合、該フレーム番号をエラーフレーム番号記憶部２０から消去する。【０１３６】  さらに、エラーフレーム処理部１６は、一定回数（ｍ回）だけ再送に失敗したデータフレーム、および、送信を開始してから一定時間経過したデータフレームに対応するフレーム番号をエラーフレーム番号記憶部２０から消去する。これにより、有効期限が切れたデータフレームは、二度と再送されることがない。【０１３７】  エラーフレーム処理部１６は、Ａｃｋ方式切替部１９がＢｌｏｃｋＡｃｋ方式を選択しており、かつ、有効期限が切れた受信失敗のデータフレームが発生した場合、Ａｃｋ要求フレーム生成指示信号をＡｃｋ要求フレーム生成部１３に出力する。【０１３８】  Ａｃｋ要求フレーム生成部１３は、Ａｃｋ方式切替部１９がＢｌｏｃｋＡｃｋ方式を選択している場合に、ＢｌｏｃｋＡｃｋＲｅｑフレームを生成し、生成したＢｌｏｃｋＡｃｋＲｅｑフレームを送信部１１に送るものである。Ａｃｋ要求フレーム生成部１３は、ＢｌｏｃｋＡｃｋ方式生成部１４ａより送信最小フレーム番号を、エラーフレーム処理部１６よりＡｃｋ要求フレーム生成指示信号を受ける。【０１３９】  Ａｃｋ要求フレーム生成部１３は、ＢｌｏｃｋＡｃｋ方式生成部１４ａより送信最小フレーム番号を受けた場合、受けた送信最小フレーム番号をＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに設定したＢｌｏｃｋＡｃｋＲｅｑフレームを生成する。【０１４０】  一方、Ａｃｋ要求フレーム生成部１３は、エラーフレーム処理部１６よりＡｃｋ要求フレーム生成指示信号を受けた場合、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号をＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに設定したＢｌｏｃｋＡｃｋＲｅｑフレームを生成する。これにより、図８で示したように、受信局は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ未満のデータフレームについて、再送されないことを認識することができる。【０１４１】  次に、本実施形態に係る受信局５の構成について説明する。図１３は、受信局５の構成を示すブロック図である。【０１４２】  図１３に示されるように、受信局５は、受信部５１、送信部５２、データフレーム処理部５３、ＢｌｏｃｋＡｃｋフレーム生成部５４、ＮｏｒｍａｌＡｃｋフレーム生成部５５、バッファ制御部（バッファ制御手段）５６、バッファ５７、およびエラーフレーム番号記憶部５８を備えている。【０１４３】  受信部５１は、送信局１からの各種フレームを受信するものである。例えば、受信部５１は、ＢｌｏｃｋＡｃｋ方式またはＮｏｒｍａｌＡｃｋ方式のデータフレームやＢｌｏｃｋＡｃｋＲｅｑフレームを受信する。受信部５１は、ＢｌｏｃｋＡｃｋ方式またはＮｏｒｍａｌＡｃｋ方式のデータフレームを受信すると、受信したデータフレームをデータフレーム処理部５３に出力する。また、受信部５１は、ＢｌｏｃｋＡｃｋＲｅｑフレームを受信すると、該ＢｌｏｃｋＡｃｋＲｅｑフレームをバッファ制御部��６およびＢｌｏｃｋＡｃｋフレーム生成部５４に出力する。【０１４４】  データフレーム処理部５３は、Ａｃｋ方式判定部５３ａと受信成功判定部５３ｂとを備えている。【０１４５】  Ａｃｋ方式判定部５３ａは、受信したデータフレームのＡｃｋ方式を判定するものである。Ａｃｋ方式判定部５３ａは、データフレームに含まれるＡｃｋ  Ｐｏｌｉｃｙフィールドを基に、データフレームがＢｌｏｃｋＡｃｋ方式であるかＮｏｒｍａｌＡｃｋ方式であるかを判定する。Ａｃｋ方式判定部５３ａは、受信したデータフレームがＮｏｒｍａｌＡｃｋ方式であると判定した場合、該データフレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒをバッファ制御部５６に出力する。【０１４６】  受信成功判定部５３ｂは、受信したデータフレームに含まれる誤り検出符号等を基に、該データフレームの受信が成功したか否かを判定するものである。受信成功判定部５３ｂは、受信に成功したデータフレームをバッファ５７に格納する。【０１４７】  また、受信したデータフレームがＡｃｋ方式判定部５３ａによりＢｌｏｃｋＡｃｋ方式であると判定された場合、受信成功判定部５３ｂは、一つのフェイズの中で受信に失敗したデータフレームに対応するＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを、エラーフレーム番号としてエラーフレーム番号記憶部５８に格納する。【０１４８】  一方、受信したデータフレームがＡｃｋ方式判定部５３ａによりＮｏｒｍａｌＡｃｋ方式であると判定された場合、受信成功判定部５３ｂは、該データフレームの受信に成功したか否かを示す受信状況情報をＮｏｒｍａｌＡｃｋフレーム生成部５５に出力する。【０１４９】  ＢｌｏｃｋＡｃｋフレーム生成部５４は、受信部５１からＢｌｏｃｋＡｃｋＲｅｑフレームを受けて、ＢｌｏｃｋＡｃｋフレームを生成し、生成したＢｌｏｃｋＡｃｋフレームを送信部５２に出力するものである。【０１５０】  ＢｌｏｃｋＡｃｋフレーム生成部５４は、ＢｌｏｃｋＡｃｋＲｅｑフレームに含まれるＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと、バッファ５７に格納されているデータフレームのうち最大のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒとを比較する。【０１５１】  ＢｌｏｃｋＡｃｋフレーム生成部５４は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがバッファ５７に格納されているデータフレームの最大のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ以下である場合、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ以上のエラーフレーム番号をエラーフレーム番号記憶部５８から読み出す。そして、ＢｌｏｃｋＡｃｋフレーム生成部５４は、読み出したエラーフレーム番号のデータフレームの受信に失敗した旨を示すＢｌｏｃｋＡｃｋフレームを生成する。また、このとき、ＢｌｏｃｋＡｃｋフレーム生成部５４は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ未満のエラーフレーム番号をエラーフレーム番号記憶部５８から消去する。【０１５２】  一方、ＢｌｏｃｋＡｃｋフレーム生成部５４は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがバッファ５７に格納されているデータフレームの最大のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも大きい場合、該Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに対応するデータフレームが未受信で��る旨を示すＢｌｏｃｋＡｃｋフレームを生成する。また、このとき、ＢｌｏｃｋＡｃｋフレーム生成部５４は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ未満のエラーフレーム番号をエラーフレーム番号記憶部５８から消去する。【０１５３】  ＮｏｒｍａｌＡｃｋフレーム生成部５５は、受信成功判定部５３ｂからデータフレームの受信に成功したか否かを示す受信状況情報を受け、該受信状況情報が受信に成功した旨を示していた場合は、ＮｏｒｍａｌＡｃｋフレームを生成し、生成したＮｏｒｍａｌＡｃｋフレームを送信部５２に出力するものである。該受信状況情報が受信に失敗した旨を示していた場合は何も生成しない。【０１５４】  バッファ５７は、受信部５１が正常に受信したデータフレームを一時的に格納するためのものである。【０１５５】  バッファ制御部５６は、バッファ５７に格納されたデータフレームの中から上位層に通知すべきデータフレームを読み出すものである。そして、バッファ制御部５６は、読み出したデータフレームを上位層に通知する。なお、バッファ制御部５６は、バッファ５７から読み出したデータフレームについて、バッファ５７から消去する。【０１５６】  上述したように、バッファ制御部５６は、受信部５１よりＢｌｏｃｋＡｃｋＲｅｑフレームを、Ａｃｋ方式判定部５３ａよりＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを受ける。【０１５７】  受信部５１よりＢｌｏｃｋＡｃｋＲｅｑフレームを受けた場合、バッファ制御部５６は、ＢｌｏｃｋＡｃｋＲｅｑフレームに含まれるＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと、バッファ５７に格納されているデータフレームのうち最大のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒとを比較する。【０１５８】  バッファ制御部５６は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがバッファ５７に格納されているデータフレームのうちの最大のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ以下である場合、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ未満のデータフレーム、および、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒに対応するデータフレームから連続して受信に成功したデータフレームまでをバッファ５７から読み出し、上位層に通知する。【０１５９】  一方、バッファ制御部５６は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒがバッファ５７に格納されているデータフレームのうちの最大のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒより大きい場合、バッファ５７に格納されている全てのデータフレームを読み出し、上位層に通知する。【０１６０】  また、Ａｃｋ方式判定部５３ａよりＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを受けた場合、バッファ制御部５６は、受けたＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ未満のデータフレーム、および、受けたＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒのデータフレームから連続して受信に成功したデータフレームまでをバッファ５７から読み出し、上位層に通知する。すなわち、バッファ制御部５６は、ノーマルＡＣＫ方式を要求するデータフレームを受信した際に、該ノーマルＡＣＫ方式を要求するデータフレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒよりも古いＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つデータフレームをバッファ５７から読み出して上位層に通知するとともに、���み出したデータフレームをバッファ５７から削除する。【０１６１】  次に、図１を参照しながら、本実施形態における送信局１および受信局５におけるデータ通信処理をフェイズごとに説明する。【０１６２】  なお、事前の処理により、受信局５のバッファサイズ（Ｂｕｆｆｅｒ  Ｓｉｚｅ）は８であることが送信局に通知されているものとする。すなわち、送信局１の受信局バッファサイズ記憶部１８は、バッファサイズ「８」を記憶しているものとする。また、送信局１のエラーフレーム処理部１６は、各データフレームの再送回数を監視しており、ｍ回だけ再送に失敗したデータフレームに対応するＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒをエラーフレーム番号記憶部２０から消去するものとする。【０１６３】  ＜フェイズ１＞
フェイズ１の送信局１において、Ａｃｋ方式切替部１９は、初期設定であるＢｌｏｃｋＡｃｋ方式を選択する。また、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、初期設定として５つのデータフレーム、つまり、データフレームＤ１〜Ｄ５を生成する。このとき、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、未送信最小フレーム番号「６」を未送信最小フレーム番号記憶部１７に格納する。そして、送信部１１は、該データフレームＤ〜Ｄ５を受信局５に送信する。【０１６４】  さらに、Ａｃｋ要求フレーム生成部１３は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが「１」のＢｌｏｃｋＡｃｋＲｅｑフレームを生成し、送信部１１は、該ＢｌｏｃｋＡｃｋＲｅｑフレームを受信局５に送信する。【０１６５】  一方、フェイズ１の受信局５において、データフレーム処理部５３の受信成功判定部５３ｂは、データフレームＤ２およびＤ５のみ受信に失敗したと判定し、バッファ５７にデータフレームＤ１・Ｄ３・Ｄ４を格納するとともに、エラーフレーム番号記憶部５８にエラーフレーム番号「２」「５」を格納する。【０１６６】  また、上記ＢｌｏｃｋＡｃｋＲｅｑフレームを受けたバッファ制御部５６は、データフレームＤ２が受信失敗しているため、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと同じＳｅｑｕｅｎｃｅ  ＮｕｍｂｅｒのデータフレームＤ１のみをバッファ５７から読み出し、上位層へ通知する。このとき、バッファ制御部５６は、読み出したデータフレームＤ１をバッファ５７から消去する。【０１６７】  さらに、上記ＢｌｏｃｋＡｃｋＲｅｑフレームを受けたＢｌｏｃｋＡｃｋフレーム生成部５４は、エラーフレーム番号記憶部５８からエラーフレーム番号「２」「５」を読み出し、データフレームＤ２およびＤ５の受信に失敗した旨を示すＢｌｏｃｋＡｃｋフレームを生成する。そして、送信部５２は、該ＢｌｏｃｋＡｃｋフレームを送信する。【０１６８】  そして、上記ＢｌｏｃｋＡｃｋフレームを受けた送信局１において、エラーフレーム処理部１６は、エラーフレーム番号「２」「５」をエラーフレーム番号記憶部２０に格納する。【０１６９】  ＜フェイズ２＞
次に、フェイズ２の送信局１において、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号「２」「５」を基に、該エラーフレーム番号に対応するデータフレームＤ２およびＤ５を生成する。【０１７０】  さらに、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号「６」から、エラーフレーム番号「２」と受信局バッファサイズ記憶部１８が記憶するバッファサイズ「８」との加算値「１０」未満のデータフレームＤ６〜Ｄ９を生成する。このとき、ＢｌｏｃｋＡｃｋ方式生成部１４ａは、未送信最小フレーム番号「１０」として未送信最小フレーム番号記憶部１７を更新する。【０１７１】  そして、送信部１１は、データフレームＤ２，Ｄ５〜Ｄ９を受信局５に送信する。【０１７２】  さらに、Ａｃｋ要求フレーム生成部１３は、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒが「２」のＢｌｏｃｋＡｃｋＲｅｑフレームを生成し、送信部１１は、該ＢｌｏｃｋＡｃｋＲｅｑフレームを受信局５に送信する。【０１７３】  一方、フェイズ２の受信局５において、データフレーム処理部５３の受信成功判定部５３ｂは、データフレームＤ２およびＤ５のみ受信に失敗したと判定し、バッファ５７にデータフレームＤ６〜Ｄ９を格納するとともに、エラーフレーム番号「２」「５」としてエラーフレーム番号記憶部５８を更新する。【０１７４】  また、上記ＢｌｏｃｋＡｃｋＲｅｑフレームを受けたバッファ制御部５６は、データフレームＤ２が受信失敗しているため、Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒと同じＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「２」のデータフレームＤ２をバッファ５７から読み出すことができない。つまり、バッファ制御部５６は、どのデータフレームもバッファ５７から読み出さない。【０１７５】  さらに、上記ＢｌｏｃｋＡｃｋＲｅｑフレームを受けたＢｌｏｃｋＡｃｋフレーム生成部５４は、エラーフレーム番号記憶部５８からエラーフレーム番号「２」「５」を読み出し、読み出したエラーフレーム番号に対応するデータフレームＤ２およびＤ５の受信に失敗した旨を示すＢｌｏｃｋＡｃｋフレームを生成する。そして、送信部５２は、該ＢｌｏｃｋＡｃｋフレームを送信する。【０１７６】  そして、該ＢｌｏｃｋＡｃｋフレームを受けた送信局１において、エラーフレーム処理部１６は、エラーフレーム番号「２」「５」としてエラーフレーム番号記憶部２０を更新する。【０１７７】  以上のように、フェイズ１とフェイズ２では、ＢｌｏｃｋＡｃｋ方式を用いており、ここでＤ２とＤ５の受信に失敗していたとする。【０１７８】  ＜フェイズ３＞
次に、フェイズ３の送信局１において、Ａｃｋ方式切替部１９は、エラーフレーム番号記憶部２０が記憶する最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「２」と受信局バッファサイズ記憶部１８が記憶するバッファサイズ「８」とを加えた値が、未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号「１０」と同じであることを確認し、ＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替える。【０１７９】  Ａｃｋ方式切替部１９がＮｏｒｍａｌＡｃｋ方式に切り替えたことにより、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、Ａｃｋ  Ｐｏｌｉｃｙフィールドを「ＮｏｒｍａｌＡｃｋ方式」としたデータフレームを生成する。なお、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号および未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号のうち最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（ここでは、「２」である）に対応するデータフレームＤ２を生成する。【０１８０】  そして、送信部１１は、Ａｃｋ  Ｐｏｌｉｃｙフィールドで「ＮｏｒｍａｌＡｃｋ方式」である、データフレームＤ２を受信局５に送信する。【０１８１】  一方、フェイズ３の受信局５において、データフレーム処理部５３のＡｃｋ方式判定部５３ａは、データフレームがＮｏｒｍａｌＡｃｋ方式であると判定するとともに、データフレーム処理部５３の受信成功判定部５３ｂは、データフレームＤ２の受信に失敗したと判定する。【０１８２】  また、Ａｃｋ方式判定部５３ａは、受信したＮｏｒｍａｌＡｃｋ方式のデータフレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「２」をバッファ制御部５６に出力する。これにより、バッファ制御部５６は、受けたＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「２」以下のデータフレームをバッファ５７から読み出し、上位層に通知する。この場合、バッファ５７がＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「２」以下のデータフレームを記憶していないため、バッファ制御部５６は、バッファ５７からデータフレームを読み出さない。【０１８３】  そして、データフレーム処理部５３は、データフレームＤ２の受信に失敗した旨を示す受信状況情報をＮｏｒｍａｌＡｃｋフレーム生成部５５に出力する。その結果、ＮｏｒｍａｌＡｃｋフレームが受信局５から送信されない。【０１８４】  送信局１においては、ＮｏｒｍａｌＡｃｋフレームが受信されないので、エラーフレーム番号記憶部２０は更新されない。【０１８５】  ＜フェイズ４〜ｎ＞
以降、受信局５がつねにデータフレームＤ２の受信に失敗するとする。そして、フェイズｎにおいて、データフレームＤ２に対するＮｏｒｍａｌＡｃｋフレームを受信しないことにより、送信局１のエラーフレーム処理部１６は、ｍ回再送に失敗したことを検知して、エラーフレーム番号「２」をエラーフレーム番号記憶部２０から消去する。【０１８６】  以上のように、フェイズ３では、ＢｌｏｃｋＡｃｋフレームにおいてｄ２とｄ５の受信に失敗したことが通知される。Ｄ２の受信が成功しておらず、受信局のＢｕｆｆｅｒ  Ｓｉｚｅが８であることから、Ｄ１０を送信すると受信局５でバッファが不足することを送信局１は算出できるので、それ以降のデータフレームは送信できないことがわかる。よって、送信局１は送達確認処理の効率を考慮してＢｌｏｃｋＡｃｋ方式からＮｏｒｍａｌＡｃｋ方式に切り替える。ここで送信局１はｄ２とｄ５のどちらを先に送信するべきかを決定しなければならないが、このときにＩＥＥＥ８０２．１１ｅ標準においては送信順序を決定するルールが規定されていないのに対して、本発明では＜追加ルール１＞が規定されている。これにより、送信局１は、ｄ５をＮｏｒｍａｌＡｃｋ方式送信するとその後ｄ２をＮｏｒｍａｌＡｃｋ方式で送信することができないため、ｄ２を先に送信すると決定する。その後、送信局１はｄ２をＮｏｒｍａｌＡｃｋ方式でフェイズｎまで再送し続けている。【０１８７】  ＜フェイズｎ＋１＞
次に、フェイズｎ＋１の送信局１において、ＮｏｒｍａｌＡｃｋ方式生成部１４ｂは、エラーフレーム番号記憶部２０が記憶するエラーフレーム番号および未送信最小フレーム番号記憶部１７が記憶する未送信最小フレーム番号のうち最小のＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（ここでは、「５」である）に対応するデータフレームＤ５を生成する。【０１８８】  そして、送信部１１は、Ａｃｋ  Ｐｏｌｉｃｙフィールドで「ＮｏｒｍａｌＡｃｋ方式」を示す、データフレームＤ５を受信局５に送信する。【０１８９】  一方、受信局５において、データフレーム処理部５３のＡｃｋ方式判定部５３ａは、データフレームがＮｏｒｍａｌＡｃｋ方式であると判定する。また、データフレーム処理部５３の受信成功判定部５３ｂは、データフレームＤ５の受信に成功したと判定し、該データフレームＤ５をバッファ５７に格納するものとする。【０１９０】  また、Ａｃｋ方式判定部５３ａは、受信したＮｏｒｍａｌＡｃｋ方式のデータフレームのＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「５」をバッファ制御部５６に出力する。これにより、バッファ制御部５６は、受けたＳｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ「５」未満のデータフレーム（つまり、データフレームＤ３およびＤ４）、および、データフレームＤ５から連続して受信に成功したデータフレーム（つまり、データフレームＤ５〜Ｄ９）をバッファ５７から読み出し、上位層に通知する。【０１９１】  以上のように、ＲｅｔｒｙＬｉｍｉｔが所定の回数に到達したり、ｄ２のＤｅｌａｙＢｏｕｎｄが経過したりした等の理由でフェイズｎにおいて、送信局がｄ２の再送をあきらめたとすると、フェイズｎ＋１において、ｄ５のＮｏｒｍａｌＡｃｋ方式での再送を開始する。【０１９２】  ここで、ｄ５の受信に成功したとすると、受信局はどのデータフレームを上位層に通知するかを決定する。受信局はＤ２をまだ受信できておらず、３以上のＳｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒを持つＢｌｏｃｋＡｃｋＲｅｑフレームも受信していないため、このＮｏｒｍａｌＡｃｋがＢｌｏｃｋＡｃｋの代用であると認識した場合にはまだどのフレームも上位層に通知できないのに対して、本発明では＜追加ルール２＞が規定されているので、送信局がｄ２の再送をあきらめたことがわかる。よって、ｄ２の受信を待つことなく、Ｄ３とＤ４を上位層に通知することができる。また、Ｄ５〜Ｄ９についても受信データフレームに抜けが無いので上位層に通知することができる。【０１９３】  本発明を適用することにより、前記第１の課題として述べた２つの課題、すなわち、送信局がＮｏｒｍａｌＡｃｋ方式からＢｌｏｃｋＡｃｋ方式に復帰するまでの時間に関する規定が無いため、これが長引いた場合には未受信データフレームが無効になったという事実を受信局が知るまでの遅延が大きくなり、したがってそれに続いて正常に受信したデータフレームを受信局が上位層に通知できるまでの遅延が大きくなるという課題を解決できる。【０１９４】  （第２の実施の形態）
本発明の第２の実施の形態は前記の第２の課題が＜変更ルール１＞で示したルールの変更を適用することによって解決された例である。第２の実施の形態について、図２および図１４を参照しながら説明する。図２の記述方法については（第２の課題）として述べた図１１と同様である。また、説明の便宜上、前記実施形態１にて説明した図面と同じ機能を有する部材については、同じ符号を付記し、その説明を省略する。【０１９５】  図１４は、本実施形態の受信局１０５の構成を示すブロック図である。図１４に示されるように、受信局１０５は、受信部５１、送信部５２、データフレーム処理部５３、ＢｌｏｃｋＡｃｋフレーム生成部５４、ＮｏｒｍａｌＡｃｋフレーム生成部５５、バッファ制御部（リソース制御手段）５９、タイマ６０、タイマ制御部（タイマ制御手段）６１、バッファ５７、およびエラーフレーム番号記憶部５８を備えている。【０１９６】  タイマ制御部６１は、タイマ６０のリセットを制御するものである。タイマ制御部６１は、Ａｃｋ方式判定部５３ａよりデータフレームで指定されたＡｃｋ方式の種別を取得する。タイマ制御部６１は、取得したＡｃｋ方式がＢｌｏｃｋＡｃｋ方式である場合に、タイマ６０をリセットする。すなわち、タイマ制御部６１は、ＢｌｏｃｋＡｃｋ方式を要求するデータフレームを受信したときに、タイマ６０をリセットする。【０１９７】  バッファ制御部５９は、上記バッファ制御部５６の機能に加えて、タイマ６０がＢｌｏｃｋＡｃｋ  Ｔｉｍｅｏｕｔで示される所定の時間に到達した場合に、ＢｌｏｃｋＡｃｋ方式の使用が終了したとみなし、バッファ５７におけるＢｌｏｃｋＡｃｋ方式のためのリソースを開放する機能を有している。【０１９８】  図２はＢｌｏｃｋＡｃｋ方式を使用してフレームを送信している時に、途中でＮｏｒｍａｌＡｃｋ方式に切り替えた場合の例を示している。【０１９９】  従来はＡｃｋ  Ｐｏｌｉｃｙの指定に関わらずデータフレームを受信したときにはいつでもタイマをリセットしていたが、本実施の形態では、＜変更ルール１＞で示したルールの変更を適用しているので、ＡｃｋＰｏｌｉｃｙとしてＢｌｏｃｋＡｃｋ方式の指定されているデータフレームを受信した時にだけタイマ６０がリセットされることになる。よって、受信局１０５が最後にＡｃｋＰｏｌｉｃｙとしてＢｌｏｃｋＡｃｋ方式が指定されたデータフレームを受信した時点（Ｔ３）以降は、タイマ６０がリセットされなくなっている。その後、タイマ６０がＢｌｏｃｋＡｃｋ  Ｔｉｍｅｏｕｔで示される時間に到達し、受信局はＢｌｏｃｋＡｃｋ方式の使用が終了したことを検出し、リソースを開放することができる。【０２００】  （第３の実施の形態）
本発明の第３の実施の形態は前記の第２の課題が＜変更ルール２＞で示したルールの変更を適用することによって解決された例である。【０２０１】  本実施形態の受信局の構成は、上記第２の実施の形態と比較して、タイマ制御部６１における機能のみが異なる。すなわち、本実施形態のタイマ制御部６１は、受信部５１がＢｌｏｃｋＡｃｋＲｅｑフレームを受信した場合にのみ、タイマ６０をリセットする。【０２０２】  第３の実施の形態について、図３を参照しながら説明する。図の記述方法については（第２の課題）として述べた図１１と同様である。【０２０３】  図３はＢｌｏｃｋＡｃｋ方式を使用してフレームを送信している時に、途中でＮｏｒｍａｌＡｃｋ方式に切り替えた場合の例を示している。【０２０４】  従来はＡｃｋ  Ｐｏｌｉｃｙの指定に関わらずデータフレームを受信したときにはいつでもタイマをリセットしていたが、本実施の形態では、＜変更ルール２＞で示したルールの変更を適用しているので、ＢｌｏｃｋＡｃｋＲｅｑフレームを受信した時にだけタイマがリセットされることになる。よって、受信局が最後にＢｌｏｃｋＡｃｋＲｅｑフレームを受信した時点（Ｔ１）以降は、タイマがリセットされなくなっている。その後、タイマがＢｌｏｃｋＡｃｋ  Ｔｉｍｅｏｕｔで示される時間に到達し、受信局はＢｌｏｃｋＡｃｋ方式の使用が終了したことを検出し、リソースを開放することができる。【０２０５】  （第４の実施の形態）
本発明の第４の実施の形態は前記の第２の課題が＜変更ルール３＞で示したルールの変更を適用することによって解決された例である。【０２０６】  本実施形態の受信局の構成は、上記第２および第３の実施の形態と比較して、タイマ制御部６１における機能のみが異なる。すなわち、本実施形態のタイマ制御部６１は、受信部５１がＮｏｒｍａｌＡｃｋ方式を要求するデータフレームを受信したとき、および、受信部５１がＢｌｏｃｋＡｃｋＲｅｑフレームを受信したときに、タイマ６０をリセットする。【０２０７】  第４の実施の形態について、図４を参照しながら説明する。図の記述方法については（第２の課題）として述べた図１１と同様である。【０２０８】  図４はＢｌｏｃｋＡｃｋ方式を使用してフレームを送信している途中でＮｏｒｍａｌＡｃｋ方式に切り替えた場合の例を示している。【０２０９】  従来はＡｃｋ  Ｐｏｌｉｃｙの指定に関わらずデータフレームを受信したときにはいつでもタイマをリセットしていたが、本実施の形態では、＜変更ルール３＞で示したルールの変更を適用しているので、ＡｃｋＰｏｌｉｃｙとしてＢｌｏｃｋＡｃｋ方式の指定されているデータフレームかＢｌｏｃｋＡｃｋＲｅｑフレームを受信した時にだけタイマがリセットされることになる。よって、受信局が最後にＢｌｏｃｋＡｃｋＲｅｑフレームを受信した時点（Ｔ４）以降は、タイマがリセットされなくなっている。その後で、タイマがＢｌｏｃｋＡｃｋ  Ｔｉｍｅｏｕｔで示される時間に到達し、受信局はＢｌｏｃｋＡｃｋ方式の使用が終了したことを検出し、リソースを開放することができる。【０２１０】  このように、本発明を適用することにより、前記第２の課題として述べた、送信局がＢｌｏｃｋＡｃｋ方式によるデータ通信を終了し、ＮｏｒｍａｌＡｃｋ方式に移行する場合に、送信局から受信局に対して送信される「ＢｌｏｃｋＡｃｋ方式を終了する」というメッセージを受信局がそのメッセージの再送期限内に正しく受信できなかった状況において、受信局においてタイムアウトが検出されず、受信局はいつまで経ってもＢｌｏｃｋＡｃｋ用に確保したリソースを開放できないという課題を解決できる。【０２１１】  なお、上記各実施の形態の送信局１および受信局５・１０５の各部や各処理ステップは、ＣＰＵなどの演算手段が、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やＲＡＭなどの記憶手段に記憶されたプログラムを実行し、キーボードなどの入力手段、ディスプレイなどの出力手段、あるいは、インターフェース回路などの通信手段を制御することにより実現することができる。したがって、これらの手段を有するコンピュータが、上記プログラムを記録した記録媒体を読み取り、当該プログラムを実行するだけで、上記各実施の形態の送信局１および受信局５・１０５の各種機能および各種処理を実現することができる。また、上記プログラムをリムーバブルな記録媒体に記録することにより、任意のコンピュータ上で上記の各種機能および各種処理を実現することができる。【０２１２】  この記録媒体としては、マイクロコンピュータで処理を行うために図示しないメモリ、例えばＲＯＭのようなものがプログラムメディアであっても良いし、また、図示していないが外部記憶��置としてプログラム読取り装置が設けられ、そこに記録媒体を挿入することにより読取り可能なプログラムメディアであっても良い。【０２１３】  また、何れの場合でも、格納されているプログラムは、マイクロプロセッサがアクセスして実行される構成であることが好ましい。さらに、プログラムを読み出し、読み出されたプログラムは、マイクロコンピュータのプログラム記憶エリアにダウンロードされて、そのプログラムが実行される方式であることが好ましい。なお、このダウンロード用のプログラムは予め本体装置に格納されているものとする。【０２１４】  また、上記プログラムメディアとしては、本体と分離可能に構成される記録媒体であり、磁気テープやカセットテープ等のテープ系、フレキシブルディスクやハードディスク等の磁気ディスクやＣＤ／ＭＯ／ＭＤ／ＤＶＤ等のディスクのディスク系、ＩＣカード（メモリカードを含む）等のカード系、あるいはマスクＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、フラッシュＲＯＭ等による半導体メモリを含めた固定的にプログラムを担持する記録媒体等がある。【０２１５】  また、インターネットを含む通信ネットワークを接続可能なシステム構成であれば、通信ネットワークからプログラムをダウンロードするように流動的にプログラムを担持する記録媒体であることが好ましい。【０２１６】  さらに、このように通信ネットワークからプログラムをダウンロードする場合には、そのダウンロード用のプログラムは予め本体装置に格納しておくか、あるいは別な記録媒体からインストールされるものであることが好ましい。【０２１７】  尚、発明を実施するための最良の形態の項においてなした具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求の範囲内で、いろいろと変更して実施することができるものである。
【産業上の利用可能性】
【０２１８】  本発明は、１つのフレームに対する送達確認を１つのフレームで返送するノーマルＡＣＫ方式と、複数のフレームに対する送達確認をまとめて１つのフレームで返送するブロックＡＣＫ方式の両方を同時に使用しうる通信方法、該通信方法に従う送信局および受信局に適用することができる。
【図１】
0004223513.tif 000002
【図２】
0004223513.tif 000003
【図３】
0004223513.tif 000004
【図４】
0004223513.tif 000005
【図５】
0004223513.tif 000006
【図６】
0004223513.tif 000007
【図７】
0004223513.tif 000008
【図８】
0004223513.tif 000009
【図９】
0004223513.tif 000010
【図１０】
0004223513.tif 000011
【図１１】
0004223513.tif 000012
【図１２】
0004223513.tif 000013
【図１３】
0004223513.tif 000014
【図１４】
0004223513.tif 000015