JP2004007336A - 通信管理方法、通信管理プログラム、通信管理プログラムを記録した記録媒体、ならびに通信局 - Google Patents

Abstract

【課題】複数の通信局が通信ネットワークを介して接続されているネットワークシステムにおいて、送信局と受信局との間での送達確認要求・返信処理を行うタイミングを、例えばリアルタイム性の高いストリーミングデータの送信を行っても支障を来さないように設定する通信管理方法を提供する。
【解決手段】送信局は、送信権を管理する制御局から送信権を付与することを示すＣＦ−ＰＯＬＬを受信すると、その直後にＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局に送信する。そして、送信局は、受信局からＢｕｒｓｔ　Ａｃｋを受信した直後からＴＸＯＰが終了するまでの間でデータパケットの送信を行う。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の通信装置が１つのネットワーク経路を時分割で共用するネットワークにおける通信管理方法に関するものであり、特にＩＥＥＥ８０２．１１無線通信方式に関するものである。
【０００２】
【従来の技術】
従来、コンピュータネットワークなどにおいては、パケット通信方式と呼ばれる通信方式によってパケットの送受信が行われている。昨今では、例えば家庭内ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）などにおいて、無線を利用したネットワークを構築する需要が高まっている。このような無線ＬＡＮは、有線のＬＡＮと比較して、ケーブルなどの配線を設置する必要がなく、また、ＬＡＮに接続される端末の移動の自由度が増大するという利点を有している。
【０００３】
無線ＬＡＮの標準規格としては、ＩＥＥＥ８０２．１１無線通信方式（ＡＮＳＩ／ＩＥＥＥ　Ｓｔｄ　８０２．１１，１９９９　Ｅｄｉｔｉｏｎに準拠する方式）が存在している。このＩＥＥＥ８０２．１１の中でも、使用する周波数帯域や通信速度などに応じて、さらに細かく規格が区分されている。例えば、現在、２．４ＧＨｚ帯を用いて１１Ｍｂｐｓの通信速度を実現するＩＥＥＥ８０２．１１ｂが、パーソナルコンピュータなどの通信ネットワークにおける無線ＬＡＮの仕様として広く用いられている。
【０００４】
無線ＬＡＮなどのネットワークにおいては、ネットワークに接続される複数の通信装置は、パケットの送受信に関して、１つのネットワーク経路を時分割で共用していることになる。このようなシステムでは、送信権の管理方法によって、帯域利用の効率が大きく変化することになる。
【０００５】
例えば映像などの動画データを、無線ＬＡＮを介してストリーミングで送受信するような場合、送信権の管理を的確に行わないと、受信側において映像のコマ落ちや映像の乱れ、音声の途切れなどが生じることが考えられる。そこで、ＱｏＳ（Ｑｕａｌｉｔｙ　Ｏｆ　Ｓｅｒｖｉｃｅ）を考慮した規格として、ＩＥＥＥ　８０２．　１１のＴＧｅ（Ｔａｓｋ　Ｇｒｏｕｐ　Ｅ）で策定している規格が提案されている。
【０００６】
ＴＧｅで策定されている規格では、特定の通信ネットワーク内に、送信権の管理を行う制御局を設けることが規定されている。制御局は、通信ネットワーク内において、データの送信を行おうとしている複数の送信局からの送信要求を考慮して、各送信局に送信権を与えるためのスケジューリングを行う。そして、制御局は、このスケジューリングに基づいて、送信権を付与することを示すＣＦ−ＰＯＬＬと呼ばれるパケットを各送信局に対して送信する。送信局は、制御局からＣＦ−ＰＯＬＬを与えられた時にのみデータの送信が許され、また、データの送信は、ＣＦ−ＰＯＬＬで示されたＴＸＯＰと呼ばれる期間内に限定されることになる。
【０００７】
以上のように、ＴＧｅで策定されている規格によれば、制御局のスケジューリングにしたがって各送信局に対して送信権の付与が行われるので、各送信局におけるデータ送信の緊急度などに応じて、より的確に通信帯域を利用することが可能となる。
【０００８】
【発明が解決しようとする課題】
上記のような通信ネットワークにおいて、送信局から受信局に向けてデータが送信される際には、何らかの事情によって送信データが的確に受信局に受信されないこともありうる。特に、このような問題は、無線を利用した通信形態においては顕著となる。したがって、送信局から受信局に向けてデータが送信され、これが受信局に的確に受信されると、受信局が送信局に対して送達確認情報を送信するようになっている。送信局が送達確認情報を受信すると、その内容から送信に失敗したデータパケットを特定し、そのデータパケットを再送する処理を行う。これにより、全てのデータパケットがほぼ確実に受信局に送達されることになる。
【０００９】
ここで、ＩＥＥＥ　８０２．１１のＴＧｅ（Ｔａｓｋ　Ｇｒｏｕｐ　Ｅ）で策定されたＩＥＥＥ　Ｓｔｄ　８０２．１１ｅ／Ｄ３．０，Ｍａｙ　２００２のドキュメントでは、送達確認情報の送受信に関して、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋ（以降、ＢＡＲ／ＢＡと称する）のシーケンスを行うことが提案されている。このＢＡＲ／ＢＡのシーケンスでは、送信局から送信されたＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔと呼ばれるパケットが受信局に受信されると、受信局は、それまでに送信局から受信した所定個数分のデータパケットに関する送達確認を示すビットマップを含んだ、Ｂｕｒｓｔ　Ａｃｋと呼ばれるパケットを送信局に対して送信する処理を行う。そして、送信局は、Ｂｕｒｓｔ　Ａｃｋで示された送達確認情報に基づいてデータパケットの再送処理を行うことになる。
【００１０】
図１５は、ある送信局におけるＴＸＯＰ期間中での送信シーケンスの一例を示す図である。同図に示す例では、ＣＦ−ＰＯＬＬが与えられてから、データパケット１〜５が送信され、その後Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信されている。ここで、受信局において、データパケット３および５の受信が失敗していた場合（図中では×印で示す）、その旨を示すＢｕｒｓｔ　Ａｃｋが送信局に送信される。
【００１１】
送信局は、データパケット３および５の受信が失敗していたことを示すＢｕｒｓｔ　Ａｃｋを受信すると、データパケット３および５の再送を行い、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信を行う。そして、受信局からＢｕｒｓｔ　Ａｃｋを受信してデータパケット５が再び送信失敗していたことを確認し、このデータパケット５および次のデータパケット６〜８を送信する。データパケット８の送信が完了した時点で、このＴＸＯＰ期間で予定していた送信データの送信が完了し、ＱｏＳ　Ｎｕｌｌを制御局に向けて送信する。なお、ＱｏＳ　Ｎｕｌｌとは、その時点での送信局におけるバッファ状況を示す情報または送信権を付与して欲しい期間の情報を含んだパケットであり、制御局は、各送信局から送られてきたＱｏＳ　Ｎｕｌｌに基づいてスケジューリングを行う。なお、図中において、各パケット間に示しているＳという文字は、ＩＥＥＥ８０２．１１で規定されているＳＩＦＳ（Ｓｈｏｒｔ　Ｉｎｔｅｒ　Ｆｒａｍｅ　Ｓｐａｃｅ）期間を示している。
【００１２】
しかしながら、ＩＥＥＥ　８０２．１１のＴＧｅ（Ｔａｓｋ　Ｇｒｏｕｐ　Ｅ）で策定されたＩＥＥＥ　Ｓｔｄ　８０２．１１ｅ／Ｄ３．０，Ｍａｙ　２００２のドキュメントでは、ＢＡＲ／ＢＡのシーケンスを行うタイミングについて明示されていない。したがって、実装時には、設計段階でＢＡＲ／ＢＡのシーケンスを行う所定のタイミングを設定することになるが、このタイミングの設定によっては、データパケットの再送処理が行われる時期が遅くなる場合も考えられ、リアルタイム性の高いストリーミングデータの送信などに支障を来す可能性などが生じることになる。よって、ＢＡＲ／ＢＡのシーケンスを行うタイミングの最適化を図る必要がある。
【００１３】
本発明は上記の問題点を解決するためになされたもので、その目的は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムにおいて、送信局と受信局との間での送達確認要求・返信処理を行うタイミングを、例えばリアルタイム性の高いストリーミングデータの送信を行っても支障を来さないように設定する通信管理方法を提供することにある。
【００１４】
【課題を解決するための手段】
上記の課題を解決するために、本発明に係る通信管理方法は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が、上記第１の通信局に送信権が付与された直後に行われるものとすることを特徴としている。
【００１５】
上記の方法では、通信局は、送信権を付与された期間においてデータの送信を行うようになっている。そして、データの送信を行う第１の通信局は、データの送信先である第２の通信局に対して、送信した複数のデータパケットに対する送達確認を要求する。第２の通信局は、受信しているデータの送信元である第１の通信局から送達確認要求を受けた際に、それまでに受信した複数のデータパケットに対する送達確認情報を返信する。
【００１６】
そして、上記の方法によれば、この第１の通信局と第２の通信局との間で行われる送達確認要求・返信処理が、第１の通信局に送信権が付与された直後に行われることになる。したがって、第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができる。これにより、パケットを正常に送受信するために伝送レートを下げる、パケット長を短くするなどの手段を早めに講じることができ、例えば動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【００１７】
また、第１の通信局に送信権が付与された直後に送達確認要求・返信処理が行われるので、例えばこの送達確認要求・返信処理の送受信に失敗した場合でも、送信するための時間が十分残っているため、連続してリトライを行うことができるので、ほぼ確実に同じ送信権付与期間内で送達確認要求・返信処理を完了することができる。これに対して、例えば送達確認要求・返信処理が送信権付与期間の残り時間が少ない時点で行われるような場合には、リトライを行った場合に、その送信権付与期間内で送達確認要求・返信処理を完了することができない場合も考えられる。この場合、送達確認要求・返信処理は、次に第１の通信局に送信権が付与されるまで行えないことになり、再送処理が遅れることによって、再送処理をすべきデータパケットの有効期限が過ぎてしまうことも考えられる。
【００１８】
すなわち、上記の方法のように、第１の通信局に送信権が付与された直後に送達確認要求・返信処理が行われることによって、たとえ送達確認要求・返信処理の送受信の失敗を数回繰り返したとしても、ほぼ確実に同じ送信権付与期間内で送達確認要求・返信処理を完了することが可能となり、再送処理も迅速に行うことが可能となる。
【００１９】
また、本発明に係る通信管理方法は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間の最後に行われるものとすることを特徴としている。
【００２０】
上記の方法によれば、第１の通信局と第２の通信局との間で行われる送達確認要求・返信処理が、第１の通信局に送信権が付与された期間の最後に行われることになる。したがって、第１の通信局が送達確認情報を受信すると、送信権の付与期間が終了することになるので、この送達確認情報に基づく再送処理は、次の送信権の付与期間において行われることになる。すなわち、送達確認情報の受信から、これに基づく再送処理を行うまでの時間は比較的長いものとなる。したがって、第１の通信局において、送達確認情報を受信してからこれを解析して送信すべきデータパケットを特定するまでの処理を、比較的長い時間をかけて行ってもよいことになる。
【００２１】
これに対して、例えば送達確認情報を受信した直後から再送処理を行わなければならない場合には、送達確認情報を受信してからこれを解析して送信すべきデータパケットを特定するまでの処理を短い期間で行わなければならないことになり、極めて高速な処理を行うことが要求されることになる。
【００２２】
すなわち、上記の方法のように、送信権の付与期間の最後に送達確認要求・返信処理を行うことによって、第１の通信局における送達確認情報の解析および再送処理を行うブロックを、高速な処理を行うことが可能な回路で構成する必要がなくなる。よって、コストの高い高速な演算装置などを実装する必要がなくなり、装置コストの低減を図ることができる。
【００２３】
また、本発明に係る通信管理方法は、上記の方法において、上記ネットワークシステムに、該ネットワークシステムにおける送信権の付与に関するスケジューリングを行う制御局が設けられているとともに、上記送達確認要求・返信処理の後に、上記第１の通信局が、その時点での第１の通信局におけるバッファ状況を示す情報または送信権を付与して欲しい期間の情報を上記制御局に対して送信するものとする方法としてもよい。
【００２４】
上記の方法によれば、第１の通信局におけるバッファ状況を示す情報または送信権を付与して欲しい期間の情報を制御局に対して送信する直前で送達確認要求・返信処理を行うことになるので、制御局に対しては、最新の送達確認要求・返信処理の結果を反映したバッファ状況に関する情報または送信権を付与して欲しい期間の情報を送信することが可能となる。したがって、よりアップデートなバッファ状況または送信権を付与して欲しい期間の情報を制御局に送信することができるので、制御局による、より最適なスケジューリングを期待することができる。
【００２５】
また、本発明に係る通信管理方法は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴としている。
【００２６】
上記の方法によれば、第１の通信局と第２の通信局との間で行われる送達確認要求・返信処理が、第１の通信局から第２の通信局に向けてのデータパケットの送信が所定回数行われるごとに行われることになる。したがって、例えば受信局としての第２の通信局における受信バッファのサイズや、制御局から与えられる送信権の付与期間の長さなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。これにより、例えば動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【００２７】
また、本発明に係る通信管理方法は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局に対して送信しようとしているデータパケットから所定個数前に送信したデータパケットが、第２の通信局において正常に受信されたことが未確認である場合に、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴としている。
【００２８】
上記の方法によれば、第１の通信局と第２の通信局との間で行われる送達確認要求・返信処理が、第２の通信局において正常受信が未確認となっているデータパケットの送信から所定回数のデータパケットの送信が行われた際に行われることになる。したがって、例えば受信局としての第２の通信局における受信バッファのサイズや、制御局から与えられる送信権の付与期間の長さなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。これにより、例えば動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【００２９】
また、本発明に係る通信管理方法は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点、および、上記第１の通信局に送信権が付与された直後の時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴としている。
【００３０】
上記の方法によれば、第１の通信局と第２の通信局との間で行われる送達確認要求・返信処理が、第１の通信局から第２の通信局に向けてのデータパケットの送信が所定回数行われた時点と、第１の通信局に送信権が付与された直後の時点とに行われることになる。したがって、例えば受信局としての第２の通信局における受信バッファのサイズや、制御局から与えられる送信権の付与期間の長さなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。また、第１の通信局に送信権が付与された直後にも送達確認要求・返信処理が行われることになるので、第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができる。これにより、パケットを正常に送受信するために伝送レートを下げる、パケット長を短くするなどの手段を早めに講じることができ、例えば動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【００３１】
また、本発明に係る通信管理方法は、複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点、および、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に、該送信権を付与された直後の時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴としている。
【００３２】
上記の方法によれば、第１の通信局と第２の通信局との間で行われる送達確認要求・返信処理が、第１の通信局から第２の通信局に向けてのデータパケットの送信が所定回数行われた時点と、第１の通信局に送信権が付与された期間が閾値以上であった場合に送信権が付与された直後の時点とに行われることになる。したがって、例えば受信局としての第２の通信局における受信バッファのサイズなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。また、第１の通信局に送信権が付与された期間が閾値以上である場合には送信権を付与された直後にも送達確認要求・返信処理が行われ、閾値以下である場合には送達確認要求・返信処理が行われないことになるので、送信権を付与された期間に余裕がある場合には第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができる。これにより、パケットを正常に送受信するために伝送レートを下げる、パケット長を短くするなどの手段を早めに講じることができ、例えば動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【００３３】
また、第１の通信局に送信権が付与された期間が閾値より短い、すなわち時間的な余裕がない場合には、第１の通信局に送信権が付与された期間の最初には送達確認要求・返信処理が行われないことになる。よって、送達確認要求・返信処理に必要とされる期間をデータパケットの送信に割り当てることが可能となるので、第１の通信局に送信権が付与された期間が短い場合におけるデータパケットの伝送効率を向上させることができる。
【００３４】
また、本発明に係る通信管理方法は、上記の方法において、上記第１の通信局が、有効期限が残っているデータパケットに関する送達確認情報を上記第２の通信局に要求する方法としてもよい。
【００３５】
上記の方法によれば、第２の通信局は、有効期限が残っているデータパケットに関する送達確認情報を送信することになる。また、送達確認要求・返信処理は、第１の通信局に送信権が付与された直後に行われ、その直後に行われる再送処理は、第２の通信局から送られてきた送達確認情報に基づいて行われるようになっている。よって、第１の通信局は、再送処理を行う際に、再送を行おうとしているデータパケットが、受信側での有効期限に間に合うかを判定することなく、直前に受信した送達確認情報に示されている再送要求データパケットを再送すればよいことになる。
【００３６】
これに対して、例えば再送処理が、その時点での送信権付与期間以前の送信権付与期間において受信した送達確認情報に基づいて行われる場合には、送達確認情報の受信からある程度時間が経過していることになる。よって、送達確認情報に示されている再送要求データパケットであっても、受信側での有効期限に間に合うものであるかはわからないので、第１の通信局側でこれを判定する必要が生じることになる。
【００３７】
すなわち、上記の方法のように、送信権を付与された直後に送達確認要求・返信処理を行い、その直後から再送処理を行うことによって、第１の通信局における再送処理の手間、すなわち、再送を行おうとしているデータパケットが、受信側での再生時刻に間に合うかを判定する手間を削減することが可能となる。
【００３８】
また、本発明に係る通信管理方法は、上記の方法において、上記第１の通信局から上記第２の通信局に向けてデータの送信を新たに開始する際に、最初に第１の通信局に送信権が付与された直後には、送達確認要求・返信処理が行われずに、次回以降に第１の通信局に送信権が付与された直後から送達確認要求・返信処理が行われるものとする方法としてもよい。
【００３９】
第１の通信局から第２の通信局に向けてデータの送信を新たに開始する際には、それ以前には両者の間でデータの送受信は行われていないことになるので、送達確認要求・返信処理を行う必要はないことになる。よって、上記の方法のように、最初に第１の通信局に送信権が付与された直後には、送達確認要求・返信処理を行わないようにすることによって、この送信権付与期間において、送達確認要求・返信処理に要する時間を、通常のデータパケットの通信に使用することが可能となる。
【００４０】
また、本発明に係る通信管理方法は、上記の方法において、上記第１の通信局に送信権が付与された直後に行われる上記送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に行われるものとすることを特徴としている。
【００４１】
上記の方法によれば、第１の通信局に送信権が付与された期間が閾値より短い、すなわち時間的な余裕がない場合には、第１の通信局に送信権が付与された期間の最初には送達確認要求・返信処理が行われないことになる。よって、送達確認要求・返信処理に必要とされる期間をデータパケットの送信に割り当てることが可能となるので、第１の通信局に送信権が付与された期間が短い場合におけるデータパケットの伝送効率を向上させることができる。
【００４２】
また、本発明に係る通信管理方法は、上記の方法において、上記第１の通信局に送信権が付与された期間の最後に行われる上記送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に行われるものとすることを特徴としている。
【００４３】
上記の方法によれば、第１の通信局に送信権が付与された期間が閾値より短い、すなわち時間的な余裕がない場合には、第１の通信局に送信権が付与された期間の最後には送達確認要求・返信処理が行われないことになる。よって、送達確認要求・返信処理に必要とされる期間をデータパケットの送信に割り当てることが可能となるので、第１の通信局に送信権が付与された期間が短い場合におけるデータパケットの伝送効率を向上させることができる。
【００４４】
また、本発明に係る通信管理方法は、上記の方法において、上記送達確認要求・返信処理が、ＩＥＥＥ　８０２．１１のＴＧｅ（Ｔａｓｋ　Ｇｒｏｕｐ　Ｅ）で策定されたＩＥＥＥ　Ｓｔｄ　８０２．１１ｅ／Ｄ３．０，Ｍａｙ　２００２のドキュメントにおけるＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋのシーケンスである方法としてもよい。
【００４５】
上記の方法によれば、ＴＧｅで策定されている規格に準拠する通信管理方法において、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋのシーケンスを的確なタイミングで行うことが可能となり、例えば動画などのストリームデータの送受信を最適な状態で行うことが可能となる。
【００４６】
また、本発明に係る通信管理プログラムは、上記の通信管理方法をコンピュータに実行させることを特徴としている。
【００４７】
上記プログラムをコンピュータシステムにロードすることによって、上記通信管理方法をユーザに提供することが可能となる。
【００４８】
また、本発明に係る通信管理プログラムを記録した記録媒体は、上記の通信管理方法をコンピュータに実行させる通信管理プログラムを記録していることを特徴としている。
【００４９】
上記記録媒体に記録されたプログラムをコンピュータシステムにロードすることによって、上記通信管理方法をユーザに提供することが可能となる。
【００５０】
また、本発明に係る通信局は、通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみと設定されているネットワークシステムに含まれる通信局であって、上記通信ネットワークを介して他の通信局に対してデータの送信を行う送信部と、上記本発明に係る通信管理方法を用いて上記送信部によるデータの送信を管理する送信データ管理部とを備えていることを特徴としている。
【００５１】
上記の構成によれば、上記本発明に係る通信管理方法に基づいて動作を行う通信局を提供することができる。
【００５２】
【発明の実施の形態】
本発明の実施の一形態について図面に基づいて説明すれば、以下のとおりである。
【００５３】
図２は、本実施形態に係るネットワークシステムにおけるシグナルフローを示す説明図である。同図に示すように、ネットワークシステムは、制御局１、データの送信側の通信局としての送信局２、およびデータの受信側の通信局としての受信局３を備えた構成となっている。なお、同図においては、説明の簡単のために、ネットワークシステムに１つの送信局と１つの受信局とが備えられた例を示しているが、実際には、ネットワークシステムには、複数の送信局および受信局が設けられていることになる。また、送信局と受信局とを区別して示しているが、送信局が受信局となり、受信局が送信局となる場合も考えられる。また、制御局１、送信局２、および受信局３は、それぞれ互いに無線による通信が可能なように接続されており、同一の通信ネットワークに属しているものとする。
【００５４】
なお、本実施形態に示すネットワークシステムは、様々な通信ネットワークシステムで適用可能なものであるが、一例としては、家庭用電化製品に無線通信機能が内蔵され、これらを家庭内ＬＡＮとして相互に接続するようなネットワークシステムなどに好適に用いることができるものである。この例でいえば、制御局１を、家庭内の全ての無線通信機器の管理を行うためのセットトップボックスに対応させ、送信局２を、例えば動画再生装置としてのＤＶＤプレイヤーや、ＢＳ／ＣＳチューナーなどに対応させ、受信局３を例えば表示装置としてのテレビジョンに対応させ、ＤＶＤプレイヤーあるいはＢＳ／ＣＳチューナーがテレビジョンに対して動画像を送信していて、セットトップボックスがその通信を管理しているという具体的な実施例が想定される。
【００５５】
このネットワークシステムでは、制御局１が、通信ネットワークにおいて、複数の送信局２からの送信要求を考慮して、各送信局２に送信権を与えるためのスケジューリングを行っている。そして、制御局１は、このスケジューリングに基づいて、送信権を付与することを示すＣＦ−ＰＯＬＬと呼ばれるパケットを各送信局２に対して送信する。ＣＦ−ＰＯＬＬには、ＴＸＯＰ　ＬＩＭＩＴと呼ばれる、送信権が付与される期間（ＴＸＯＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｏｐｐｏｒｔｕｎｉｔｙ））の情報が含まれており、ＣＦ−ＰＯＬＬの宛先となっている送信局２は、このＴＸＯＰ期間でデータの送信が許される。
【００５６】
送信局２は、ＴＸＯＰ期間においてデータの送信を行うとともに、所定のタイミングにおいてＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信する。そして、受信局３は、送信局２からＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信すると、これに対する返答としてＢｕｒｓｔ　Ａｃｋを送信局２に対して送信する。Ｂｕｒｓｔ　Ａｃｋには、送信局２から受信した所定個数分のデータパケットに関する送達確認を示すビットマップが含まれており、送信局２は、ＢｕｒｓｔＡｃｋで示された送達確認情報に基づいてデータパケットの再送処理を行うことになる。
【００５７】
また、送信局２は、ＴＸＯＰ期間において予定していたデータ送信が終了した時点で、ＱｏＳ　Ｎｕｌｌと呼ばれるパケットを制御局１に送信する。ＱｏＳ　Ｎｕｌｌには、送信局２における送信バッファに残っている未送信のデータ量に関する情報、あるいは、この未送信のデータを送信するのに必要とされる時間などの情報が含まれている。制御局１は、このＱｏＳ　Ｎｕｌｌを各送信局２から受信することによって、各送信局２における送信状況を把握し、これに基づいて上記したスケジューリングを行うことになる。
【００５８】
次に、送信局２および受信局３の構成について説明する。図４は、送信局２の概略構成を示すブロック図である。同図に示すように、送信局２は、ＢｕｒｓｔＡｃｋ解析部４、受信部５、送信部６、送信データ管理部７、送信制御部８、および送信バッファ９を備えた構成となっている。
【００５９】
送信部６は、受信局３に対して、ストリームデータなどの送信すべきデータやＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔなどの送信を行うとともに、制御局１に対してＱｏＳ　Ｎｕｌｌなどの送信を行うブロックである。受信部５は、受信局３からＢｕｒｓｔ　Ａｃｋの受信を行うとともに、制御局１からＣＦ−ＰＯＬＬの受信を行うブロックである。
【００６０】
Ｂｕｒｓｔ　Ａｃｋ解析部４は、受信局３から受信したＢｕｒｓｔ　Ａｃｋに基づいて、どのデータパケットを再送しなければいけないのかを検索し、これを送信データ管理部７に通知するとともに、ＱｏＳ　Ｎｕｌｌで報告する内容を更新する処理を行うブロックである。
【００６１】
送信制御部８は、送信データ管理部７から渡されたデータに対して誤り訂正などの符号化を施した上でフレームを作成し、これを送信部６に送る処理を行うブロックである。
【００６２】
送信データ管理部７は、制御局１から受信したＣＦ−ＰＯＬＬに基づいてＴＸＯＰ期間の管理を行い、残り時間に応じて再送処理、新規ストリームデータ送信処理、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ送信処理、ＱｏＳ　Ｎｕｌｌ送信処理のいずれかを選択して、該当するデータを送信バッファ９にリクエストし、取り出したデータを送信制御部８に送る処理を行うブロックである。
【００６３】
送信バッファ９は、送信すべきデータを一時的に格納するバッファとして機能するブロックである。
【００６４】
図５は、受信局３の概略構成を示すブロック図である。同図に示すように、受信局３は、受信制御部１０、受信部１１、送信部１２、受信データ管理部１３、Ｂｕｒｓｔ　Ａｃｋ送信制御部１４、および受信バッファ１５を備えた構成となっている。
【００６５】
送信部１２は、送信局２に対してＢｕｒｓｔ　Ａｃｋの送信を行うブロックである。受信部１１は、送信局２からストリームデータなどの受信データや、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの受信を行うブロックである。
【００６６】
受信制御部１０は、受信部１１において受信されたストリームデータなどの受信データに対して誤り訂正復号を行い、復号したデータを受信データ管理部１３に送る処理を行うブロックである。
【００６７】
受信データ管理部１３は、受信制御部１０から渡されたデータを受信バッファ１５に格納し、再生時刻に合わせて受信バッファ１５から読み出して外部に出力する処理、および、送信局２から受信したＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの要求に基づいて送達確認を行ってＢｕｒｓｔ　Ａｃｋの情報を生成し、これをＢｕｒｓｔ　Ａｃｋ送信制御部１４に対して送る処理を行うブロックである。
【００６８】
Ｂｕｒｓｔ　Ａｃｋ送信制御部１４は、受信データ管理部１３から送られたＢｕｒｓｔ　Ａｃｋの情報に基づいてＢｕｒｓｔ　Ａｃｋのフレームを作成し、これを送信部１２に送る処理を行うブロックである。
【００６９】
受信バッファ１５は、受信データ管理部１３から入力されたストリームデータを一時的に格納するバッファとして機能するブロックである。
【００７０】
次に、Ｂｕｒｓｔ　Ａｃｋ　ＲｅｑｕｅｓｔおよびＢｕｒｓｔ　Ａｃｋのデータ構成について説明する。図３（ａ）は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔのデータ構成、図３（ｂ）は、Ｂｕｒｓｔ　Ａｃｋのデータ構成をそれぞれ示している。
【００７１】
Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔは、図３（ａ）に示すように、Ｆｒａｍｅ　Ｃｏｎｔｒｏｌ、Ｄｕｒａｔｉｏｎ／ＩＤ、ＲＡ、ＴＡ、ＢＡＲ　Ｃｏｎｔｒｏｌ、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌ、およびＦＣＳというデータを含んだ構成となっている。
【００７２】
Ｆｒａｍｅ　Ｃｏｎｔｒｏｌは、Ｐｒｏｔｏｃｏｌ・Ｖｅｒｓｉｏｎ・ＷＥＰの有無などを示す情報であり、２ｂｙｔｅのデータからなる。Ｄｕｒａｔｉｏｎ／ＩＤは、フレーム長を示す情報であり、２ｂｙｔｅのデータからなる。ＲＡ（Ｒｅｃｅｉｖｅｒ　ＡＤＤＲＥＳＳ）は、送信先のＭＡＣ　Ａｄｄｒｅｓｓを示す情報であり、６ｂｙｔｅのデータからなる。ＴＡ（Ｔｒａｎｓｍｉｔｔｅｒ　ＡＤＲＥＳＳ）は、送信元のＭＡＣ　Ａｄｄｒｅｓｓを示す情報であり、６ｂｙｔｅのデータからなる。ＦＣＳは、受信側で伝送誤りを検出できるようにするためのビット列である。一般にＣＲＣ（巡回冗長検査）を用いて誤りが検出される。
【００７３】
ＢＡＲ　Ｃｏｎｔｒｏｌは、Ｓｅｎｄ　Ｃｏｕｎｔ、ｒｅｓｅｒｖｅｄ、およびＴＩＤというデータからなるものであり、２ｂｙｔｅのデータからなる。Ｓｅｎｄ　Ｃｏｕｎｔは、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌから何個パケットを送信したかを示す情報であり、ＢＡＲ　ＣｏｎｔｒｏｌにおけるＢｉｔ０−１０が割り当てられる。ｒｅｓｅｒｖｅｄは予備のビットであり、ＢＡＲ　ＣｏｎｔｒｏｌにおけるＢｉｔ１１が割り当てられる。ＴＩＤ（Ｔｒａｆｆｉｃ　ＩＤ）は、ストリームのＩＤを示しており、ＴＣＩＤおよびＴＳＩＤに分かれている。このＴＩＤは、ＢＡＲ　ＣｏｎｔｒｏｌにおけるＢｉｔ１２−１５が割り当てられる。
【００７４】
Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌは、受信局３において正常受信されたことが送信局２において未確認となっている最も古いパケットのシーケンスナンバーを示す情報であり、２ｂｙｔｅのデータからなる。受信局３は、このシーケンスナンバーに該当するパケット以降のパケットに関する送達確認情報を送信局２に送信することになる。
【００７５】
詳しく説明すると、図示はしないが、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌは、Ｂｉｔ０−３からなるＦｒａｇｍｅｎｔ　Ｎｕｍｂｅｒと、Ｂｉｔ４−１５からなるＳｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒとから構成されている。データパケットは、複数のフラグメントから構成されており、Ｆｒａｇｍｅｎｔ　Ｎｕｍｂｅｒは、１つのデータパケットにおける何番目のフラグメントであるかを示す情報であり、Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒは、何番目のデータパケットであるかを示す情報である。すなわち、Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒによってデータパケットが特定され、Ｆｒａｇｍｅｎｔ　Ｎｕｍｂｅｒによってそのデータパケットにおけるフラグメントが特定されることになる。
【００７６】
なお、受信局３において正常受信されたことが送信局２において未確認であっても、受信局３側において最早必要とされていないデータパケットに関しては、たとえ正常受信されていなくても、再送を行う必要はないことになる。よって、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌでは、受信局３において再送を行う必要性のあるデータパケットの中で、受信局３において正常受信されたことが送信局２において未確認となっている最も古いパケットのシーケンスナンバーが示されるようにすればよい。ここで、受信局３側において最早必要とされていないデータパケットとしては、例えば動画のストリーミングデータの送受信が行われている場合に、受信局３側での再生に間に合わなくなったデータパケットなどが挙げられる。
【００７７】
Ｂｕｒｓｔ　Ａｃｋは、図３（ｂ）に示すように、Ｆｒａｍｅ　Ｃｏｎｔｒｏｌ、Ｄｕｒａｔｉｏｎ／ＩＤ、ＲＡ、ＴＡ、ＢＡＲ　Ｃｏｎｔｒｏｌ、ＢＡ　Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌ、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐ、およびＦＣＳというデータを含んだ構成となっている。この中で、Ｆｒａｍｅ　Ｃｏｎｔｒｏｌ、Ｄｕｒａｔｉｏｎ／ＩＤ、ＲＡ、ＴＡ、およびＦＣＳは、上記した内容と同じものであるので、ここではその説明を省略する。
【００７８】
ＢＡＲ　Ｃｏｎｔｒｏｌは、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ、ｒｅｓｅｒｖｅｄ、およびＴＩＤというデータからなるものであり、２ｂｙｔｅのデータからなる。Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅは、受信局３の受信バッファにおいて、データパケットを何個格納することができるかを示す
しており、ＢＡＲ　ＣｏｎｔｒｏｌにおけるＢｉｔ０−７が割り当てられる。なお、ＩＥＥＥ８０２．１１において規定されている１パケット当りの最大データ長は２３０４ｂｙｔｅであるので、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅは、受信バッファに２３０４ｂｙｔｅ以下のデータを何個格納することができるかを示していることになる。ｒｅｓｅｒｖｅｄは予備のビットであり、ＢＡＲ　ＣｏｎｔｒｏｌにおけるＢｉｔ８−１１が割り当てられる。ＴＩＤは、ストリームのＩＤを示しており、ＴＣＩＤおよびＴＳＩＤに分かれている。このＴＩＤは、ＢＡＲ　ＣｏｎｔｒｏｌにおけるＢｉｔ１２−１５が割り当てられる。
【００７９】
ＢＡ　Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌは、ＢｕｒｓｔＡｃｋ　Ｂｉｔｍａｐの最初のＳｅｑｕｅｎｃｅ　ＮｕｍｂｅｒおよびＦｒａｇｍｅｎｔ　Ｎｕｍｂｅｒを示しており、２ｂｙｔｅのデータからなる。通常は、Ｂｕｒｓｔ　Ａｃｋ　ＲｅｑｕｅｓｔのＳｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ
Ｃｏｎｔｒｏｌと同じものとなる。
【００８０】
Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐは、受信局３において受信されたデータの送達確認を示す情報からなるビットマップであり、１２８ｂｙｔｅのデータからなる。送達確認は、各フラグメントごとに行われ、正常に受信された場合に１、受信が未確認の場合に０を示すビットが生成される。すなわち、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐの各ビットは、各フラグメントに対する送達確認情報を示していることになる。そして、フラグメントの数は、１つのデータパケットにおいて最大１６個となっているので、２ｂｙｔｅで１つのデータパケットの送達確認状況を把握することができる。すなわち、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐは１２８ｂｙｔｅのデータからなるので、１つのＢｕｒｓｔ　Ａｃｋによって６４個分のデータパケットに関する送達確認状況を示すことが可能となっている。
【００８１】
受信局３は、上記のようなＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信すると、ＴＡ（Ｔｒａｎｓｍｉｔｔｅｒ　ＡＤＤＲＥＳＳ）によって送信元の送信局２を認識し、ＲＡ（Ｒｅｃｅｉｖｅｒ　ＡＤＤＲＥＳＳ）によって送信先が自局であることを認識する。そして、受信局３は、Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌによって、どのパケットからの送達確認情報を送信すべきなのかを認識し、これに基づいてＢｕｒｓｔ
Ａｃｋを生成し、送信局２に対して送信する。
【００８２】
送信局２は、上記のようなＢｕｒｓｔ　Ａｃｋを受信すると、ＢＡ　Ｓｔａｒｔｉｎｇ　Ｓｅｑｕｅｎｃｅ　Ｃｏｎｔｒｏｌによって、どのパケットからの送達確認情報が送られてきたのかを認識し、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐによって、再送すべきデータパケットを認識し、再送処理を行うことになる。
【００８３】
以上のように、本実施形態に係るネットワークシステムでは、送信局２と受信局３との間でデータの送受信が行われる際には、所定のタイミングでＢｕｒｓｔＡｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋ（ＢＡＲ／ＢＡ）のシーケンスが行われ、これによって必要時にはデータの再送処理が行われる。
【００８４】
本発明では、このＢＡＲ／ＢＡのシーケンスを行うタイミングを規定することを特徴としており、以下に本実施形態におけるタイミング設定例として５つの例について説明する。なお、本実施形態におけるタイミング設定例を説明する前に、比較例について説明しておき、この比較例における問題を明確にしておく。
【００８５】
（比較例）
この比較例では、送信局２がＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを行うタイミングとして、送信局２が特定の受信局３にデータの送信を開始してから、あるいは、ＢＡＲ／ＢＡのシーケンスが行われた直後から、送信局２が特定の受信局３に送信したデータの量が、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ、すなわち、受信局３における受信バッファ１５のバッファサイズ以上となった時点が設定されるようになっている。
【００８６】
図１６は、この比較例におけるデータ送信のシーケンスの一例を示している。この例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを８としている。まず、送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ１期間において、データパケット１〜６が受信局３に送信される。ここで、このＣＦ−ＰＯＬＬが与えられた時点で、送信局２が受信局３に対して送信したデータ量は０であるとする。また、各データパケットの大きさは、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅの単位データサイズである２３０４ｂｙｔｅ（最大データ長）であるものとする。そして、データパケット６の送信が完了した時点で、ＴＸＯＰ１期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ１が終了する。
【００８７】
その後、再び送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ２期間において、まずデータパケット７・８が送信される。データパケット８が送信された時点で、送信局２から受信局３に対して送信したデータ量は８となり、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅと等しくなる。このことが送信データ管理部７において検出されると、送信局２からＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔが受信局３に向けて送信される。
【００８８】
ここで、受信局３において、データパケット３、５、７の受信が失敗していた場合（図中では×印で示す）、その旨を示すＢｕｒｓｔ　Ａｃｋが送信局２に送信される。送信局２は、データパケット３、５、７の受信が失敗していたことを示すＢｕｒｓｔ　Ａｃｋを受信すると、これら送信に失敗したデータパケットの再送を行う。その後、ＴＸＯＰ２期間において、次のデータパケットの送信を行う時間がないことが認識されると、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に向けて送信する。
【００８９】
次に、この比較例において、送信局２における処理の流れについて図１７に示すフローチャートを参照しながら以下に説明する。ＣＦ−ＰＯＬＬを受信することによってＴＸＯＰが開始されると、ステップ１０１（以降Ｓ１０１のように称する）において、その時点までに送信局２が受信局３に対して送信したデータ量がＲｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ（ＲＯＢＳｉｚｅ）以上となっているか否かが判定される。
【００９０】
Ｓ１０１においてＹＥＳ、すなわち、送信したデータ量がＲＯＢＳｉｚｅ以上となっている場合、残りのＴＸＯＰ期間が十分にあるか否かが判定された上（Ｓ１０２）で、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される（Ｓ１０３）。そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、ＢｕｒｓｔＡｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ１０４）。
【００９１】
一方、Ｓ１０１においてＮＯ、すなわち、送信したデータ量がＲＯＢＳｉｚｅ未満である場合、あるいは、Ｓ１０４のステップが行われた後に、Ｓ１０５において、送信すべきパケットがあるか否かが判定される。送信すべきパケットがないと判定された場合（Ｓ１０５においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【００９２】
一方、Ｓ１０５においてＹＥＳ、すなわち、送信すべきパケットがあると判定された場合、Ｓ１０６において、送信すべきパケットが、受信局３における再生に間に合うか否かが判定される。ここで再生に間に合わない（Ｓ１０６においてＮＯ）と判定されたパケットは廃棄され（Ｓ１０７）、Ｓ１０５からのステップに戻ることになる。
【００９３】
一方、Ｓ１０６においてＹＥＳ、すなわち、送信すべきパケットがまだ有効である場合には、Ｓ１０８において残りのＴＸＯＰ期間が十分であるかを確認した上で、そのパケットの送信が行われる（Ｓ１０９）。その後、Ｓ１０１からのステップに戻って、上記の処理がＴＸＯＰが終了するまで繰り返される。一方、ＴＸＯＰの残りが十分にない場合（Ｓ１０２あるいはＳ１０８においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【００９４】
以上のように、この比較例では、送信局２が特定の受信局３に送信したデータの量が、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ、すなわち、受信局３における受信バッファ１５のバッファサイズ以上となった時点でＢＡＲ／ＢＡのシーケンスが行われるようになっている。よって、受信バッファ１５にバッファされているデータの範囲で再送処理が行われることになるので、バッファから上位の層に送られる前に、再送処理を行うことが可能となる。
【００９５】
しかしながら、この比較例の場合、ＢＡＲ／ＢＡのシーケンスを行うタイミングは、受信局３における受信バッファ１５のバッファサイズに依存することになる。例えば、図１６に示す例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを８としているが、この数字は説明の便宜上用いたものであり、実際に受信局３に実装される受信バッファ１５のバッファサイズは、６４程度が考えられる。この場合、ＢＡＲ／ＢＡのシーケンスのタイミングは、比較的長い周期で行われることになり、この周期の間は再送処理が行われないことになる。よって、動画などのストリームデータを送受信している場合、ＢＡＲ／ＢＡのシーケンスがなかなか行われないことによって、再送すべきデータの再送処理が行われずに、再生時刻に間に合わなくなる場合が生じることになる。このような場合、再生側の映像の乱れや音声の途切れなどが生じるという問題が起こることになる。
【００９６】
（タイミング設定例１）
次に、本実施形態におけるタイミング設定例の第１の実施例について説明する。本実施例では、送信局２がＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを行うタイミングとして、送信局２が制御局１からＴＸＯＰを与えられた時に、そのＴＸＯＰの最初の時点が設定されるようになっている。
【００９７】
図１は、タイミング設定例１におけるデータ送信のシーケンスの一例を示している。この例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを６４としている。まず、送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ１期間の最初に、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、データパケット１〜５が受信局３に送信される。そして、データパケット５の送信が完了した時点で、ＴＸＯＰ１期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ１が終了する。
【００９８】
その後、再び送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ２期間の最初に、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、データパケット３および５の受信が失敗していることを認識し、このデータパケット３および５の再送が行われる。その後、データパケット６〜８が受信局３に送信される。データパケット８の送信が完了した時点で、ＴＸＯＰ２期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ２が終了する。
【００９９】
次に、このタイミング設定例１において、送信局２における処理の流れについて図６に示すフローチャートを参照しながら以下に説明する。ＣＦ−ＰＯＬＬを受信することによってＴＸＯＰが開始されると、Ｓ１において、まずＢｕｒｓｔＡｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される。そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ２）。
【０１００】
ここで、Ｓ３において、その時点までに送信局２が受信局３に対して送信したデータ量がＲｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ（ＲＯＢＳｉｚｅ）以上となっているか否かが判定される。この判定は、上記の比較例における判定基準に則ったものとなっている。すなわち、本タイミング設定例１は、比較例におけるＢＡＲ／ＢＡのシーケンスの設定タイミングを含んだものとなっている。このＳ３においてＹＥＳ、すなわち送信したデータ量がＲＯＢＳｉｚｅ以上となっている場合には、Ｓ１のステップに戻り、ＢＡＲ／ＢＡのシーケンスが行われることになる。
【０１０１】
なお、実際には、上記したように、ＲＯＢＳｉｚｅは比較的大きい値となっており、１回のＴＸＯＰの期間で送信可能なデータ量よりも大きい場合がほとんどであると考えられる。よって、上記Ｓ３においてＹＥＳと判定される可能性はきわめて低いと予想される。すなわち、このＳ３における判定は、何らかの事情によって送信したデータ量が大きくなってしまった場合のｆａｉｌ−ｓａｆｅとして機能するものとして考えればよい。
【０１０２】
Ｓ３においてＮＯと判定されると、Ｓ４において、送信すべきパケットがあるか否かが判定される。送信すべきパケットがないと判定された場合（Ｓ４においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１０３】
一方、Ｓ４においてＹＥＳ、すなわち、送信すべきパケットがあると判定された場合、Ｓ５において、残りのＴＸＯＰ期間が十分であるかを確認した上で、そのパケットの送信が行われる（Ｓ６）。その後、Ｓ３からのステップに戻って、上記の処理がＴＸＯＰが終了するまで繰り返される。一方、ＴＸＯＰの残りが十分にない場合（Ｓ５においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１０４】
以上のように、このタイミング設定例１では、ＴＸＯＰの最初の時点、すなわちＴＸＯＰが開始された直後の時点で、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信が行われ、ＢＡＲ／ＢＡのシーケンスが実行されるようになっている。したがって、送信局３は、受信局との間の通信路状況をいち早く知ることが可能となるので、動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【０１０５】
また、ＢＡＲ／ＢＡのシーケンスはＴＸＯＰの最初に行われ、その直後に行われる再送処理は、受信局３から送られてきたＢｕｒｓｔ　Ａｃｋに基づいて行われるようになっている。ここで、受信局３は、受信に失敗したデータパケットの中で、再生時刻に間に合うものに関してのみ再送依頼をするようにＢｕｒｓｔ　Ａｃｋを生成する。よって、送信局２は、再送処理を行う際に、再送を行おうとしているデータパケットが、受信側での再生時刻に間に合うかを判定することなく、直前に受信したＢｕｒｓｔ　Ａｃｋに示されている再送要求データパケットを再送すればよいことになる。
【０１０６】
これに対して、例えば再送処理が、その時点でのＴＸＯＰの前のＴＸＯＰにおいて受信したＢｕｒｓｔ　Ａｃｋに基づいて行われる場合には、Ｂｕｒｓｔ　Ａｃｋの受信からある程度時間が経過していることになる。よって、Ｂｕｒｓｔ　Ａｃｋに示されている再送要求データパケットであっても、受信側での再生時刻に間にあうものであるかはわからないので、送信局２側でこれを判定する必要が生じることになる。
【０１０７】
すなわち、このタイミング設定例１のように、ＴＸＯＰの最初にＢＡＲ／ＢＡのシーケンスを行い、その直後から再送処理を行うことによって、送信局２における再送処理の手間、すなわち、再送を行おうとしているデータパケットが、受信側での再生時刻に間に合うかを判定する手間を削減することが可能となる。
【０１０８】
また、ＴＸＯＰの最初にＢＡＲ／ＢＡのシーケンスを行っているので、例えばこのＢＡＲ／ＢＡのシーケンスに失敗した場合、連続してリトライを行っても、ほぼ確実に同じＴＸＯＰ期間内でＢＡＲ／ＢＡのシーケンスを完了することができる。
【０１０９】
ここで、ＢＡＲ／ＢＡのシーケンスのリトライ動作について、図１８を参照しながら説明しておく。図１８に示す例では、データパケット５が送信された後に、送信局２からＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔが受信局３に送信され、受信局３から送信局２に対してＢｕｒｓｔ　Ａｃｋが送信されている。ここで、送信局２がＢｕｒｓｔ　Ａｃｋの受信に失敗した場合に、送信局２は再びＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に向けて送信する。これがリトライ動作の第１の例である。
【０１１０】
また、図１８に示す例では、データパケット７が送信された後に、送信局２からＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔが受信局３に送信されている。受信局３が、このＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの受信に失敗した場合、Ｂｕｒｓｔ　Ａｃｋの返信を行うことはできないことになる。この場合、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信完了からＰＩＦＳ期間の後に、再びＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信を行うことになる。これがリトライ動作の第２の例である。
【０１１１】
以上のようなリトライ動作が行われる場合、例えばＢＡＲ／ＢＡのシーケンスがＴＸＯＰの残り時間が少ない時点で行われると、そのＴＸＯＰ期間内でＢＡＲ／ＢＡのシーケンスを完了することができない場合も考えられる。
【０１１２】
すなわち、このタイミング設定例１のように、ＴＸＯＰの最初にＢＡＲ／ＢＡのシーケンスを行うことによって、たとえＢＡＲ／ＢＡのシーケンスの失敗を数回繰り返したとしても、ほぼ確実に同じＴＸＯＰ期間内でＢＡＲ／ＢＡのシーケンスを完了することが可能となる。
【０１１３】
なお、送信局２から受信局３に向けてデータの送信を新たに開始する際の最初のＴＸＯＰにおいては、このＴＸＯＰの最初にＢＡＲ／ＢＡのシーケンスを行っても、再送すべきデータパケットは存在しないはずである。よって、この最初のＴＸＯＰでは、ＢＡＲ／ＢＡのシーケンスを行わないように設定してもよい。
【０１１４】
（タイミング設定例２）
次に、本実施形態におけるタイミング設定例の第２の実施例について説明する。本実施例では、送信局２がＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを行うタイミングとして、送信局２が制御局１からＴＸＯＰを与えられた時に、そのＴＸＯＰの最後の時点が設定されるようになっている。
【０１１５】
図７は、タイミング設定例２におけるデータ送信のシーケンスの一例を示している。この例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを６４としている。まず、送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ１期間において、データパケット１〜５が受信局３に送信される。そして、データパケット５の送信が完了した時点で、ＴＸＯＰ１期間の残りが所定の時間以内になったことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信され、これによりＴＸＯＰ１が終了する。
【０１１６】
その後、再び送信局２にＣＦ−ＰＯＬＬが与えられ、ＴＸＯＰ２が開始すると、ＴＸＯＰ１において受信したＢｕｒｓｔ　Ａｃｋに基づいて、受信局３において受信が失敗しているデータパケット３および５の再送が行われる。その後、データパケット６〜８が受信局３に送信される。データパケット８の送信が完了した時点で、ＴＸＯＰ２期間の残りが所定の時間以内になったことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信され、これによりＴＸＯＰ２が終了する。
【０１１７】
次に、このタイミング設定例２において、送信局２における処理の流れについて図８に示すフローチャートを参照しながら以下に説明する。ＣＦ−ＰＯＬＬを受信することによってＴＸＯＰが開始されると、Ｓ１１において、送信データ管理部７によって実パケット送信期間の算出が行われる。この実パケット送信期間は、ＴＸＯＰ期間から、ＢＡＲ／ＢＡのシーケンスに必要とされる期間を差し引くことによって求められる。すなわち、図７においては、ＣＦ−ＰＯＬＬの受信からＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信が行われるまでの期間が実パケット送信期間に相当することになる。
【０１１８】
次に、Ｓ１２において、その時点までに送信局２が受信局３に対して送信したデータ量がＲｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ（ＲＯＢＳｉｚｅ）以上となっているか否かが判定される。この判定は、上記の比較例における判定基準に則ったものとなっている。すなわち、本タイミング設定例２は、タイミング設定例１と同様に、比較例におけるＢＡＲ／ＢＡのシーケンスの設定タイミングを含んだものとなっている。このＳ１２においてＹＥＳ、すなわち送信したデータ量がＲＯＢＳｉｚｅ以上となっている場合には、Ｓ１８のステップに移行し、ＢＡＲ／ＢＡのシーケンスが行われた後に、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１１９】
なお、実際には、上記したように、ＲＯＢＳｉｚｅは比較的大きい値となっており、１回のＴＸＯＰの期間で送信可能なデータ量よりも大きい場合がほとんどであると考えられる。よって、上記Ｓ１２においてＹＥＳと判定される可能性はきわめて低いと予想される。すなわち、このＳ１２における判定は、何らかの事情によって送信したデータ量が大きくなってしまった場合のｆａｉｌ−ｓａｆｅとして機能するものとして考えればよい。
【０１２０】
Ｓ１２においてＮＯと判定されると、Ｓ１３において、送信すべきパケットがあるか否かが判定される。送信すべきパケットがないと判定された場合（Ｓ１３においてＮＯ）には、Ｓ１８のステップに移行し、ＢＡＲ／ＢＡのシーケンスが行われた後に、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１２１】
一方、Ｓ１３においてＹＥＳ、すなわち、送信すべきパケットがあると判定された場合、Ｓ１４において、送信すべきパケットが、受信局３における再生に間に合うか否かが判定される。ここで再生に間に合わない（Ｓ１４においてＮＯ）と判定されたパケットは廃棄され（Ｓ１５）、Ｓ１３からのステップに戻ることになる。
【０１２２】
一方、Ｓ１４においてＹＥＳ、すなわち、送信すべきパケットがまだ有効である場合には、Ｓ１６において残りの実パケット送信期間が十分であるかを確認した上で、そのパケットの送信が行われる（Ｓ１７）。その後、Ｓ１３からのステップに戻って、上記の処理がＴＸＯＰが終了するまで繰り返される。一方、実パケット送信期間の残りが十分にない場合（Ｓ１６においてＮＯ）には、Ｓ１８のステップに移行し、ＢＡＲ／ＢＡのシーケンスが行われた後に、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１２３】
以上のように、このタイミング設定例２では、ＴＸＯＰの最後の時点、すなわち、ＱｏＳ　Ｎｕｌｌの送信の直前において、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信が行われ、ＢＡＲ／ＢＡのシーケンスが実行されるようになっている。したがって、送信局２がＢｕｒｓｔ　Ａｃｋを受信すると、ＴＸＯＰが終了することになるので、このＢｕｒｓｔ　Ａｃｋに基づく再送処理は、次のＴＸＯＰにおいて行われることになる。すなわち、Ｂｕｒｓｔ　Ａｃｋの受信から、これに基づく再送処理を行うまでの時間は比較的長いものとなる。したがって、Ｂｕｒｓｔ　Ａｃｋ解析部４は、Ｂｕｒｓｔ　Ａｃｋを受信してからこれを解析して送信すべきデータパケットを特定するまでの処理を、比較的長い時間をかけて行ってもよいことになる。
【０１２４】
これに対して、例えばＢｕｒｓｔ　Ａｃｋを受信した直後から再送処理を行わなければならない場合には、Ｂｕｒｓｔ　Ａｃｋ解析部４による処理は、ＳＩＦＳの期間内に行わなければならないことになり、極めて高速な処理を行うことが要求されることになる。
【０１２５】
すなわち、このタイミング設定例２のように、ＴＸＯＰの最後にＢＡＲ／ＢＡのシーケンスを行うことによって、Ｂｕｒｓｔ　Ａｃｋ解析部４を、高速な処理を行うことが可能な回路で構成する必要がなくなる。よって、コストの高い高速な演算装置などを実装する必要がなくなり、装置コストの低減を図ることができる。
【０１２６】
また、ＱｏＳ　Ｎｕｌｌの送信の直前でＢＡＲ／ＢＡのシーケンスを行うことになるので、ＱｏＳ　Ｎｕｌｌには、最新のＢＡＲ／ＢＡのシーケンスの結果を反映したバッファ状況に関する情報または送信権を付与して欲しい期間の情報を含めることが可能となる。したがって、よりアップデートなバッファ状況または送信権を付与して欲しい期間の情報を制御局１に送信することができるので、制御局１による、より最適なスケジューリングを期待することができる。
【０１２７】
（タイミング設定例３）
次に、本実施形態におけるタイミング設定例の第３の実施例について説明する。本実施例では、送信局２がＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを行うタイミングとして、データパケットの送信を所定の回数行ったごとに行われるようになっている。
【０１２８】
図９は、タイミング設定例３におけるデータ送信のシーケンスの一例を示している。この例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを６４としている。まず、送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ１期間において、データパケット１〜３が受信局３に送信される。そして、データパケットの送信が３回行われたことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４によってデータパケット３が受信失敗されていることが認識され、データパケット３の再送が行われる。
【０１２９】
その後、データパケット４の送信が行われた時点で、ＴＸＯＰ１期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ１が終了する。
【０１３０】
その後、再び送信局２にＣＦ−ＰＯＬＬが与えられると、データパケット５の送信が行われる。そして、前回ＢＡＲ／ＢＡのシーケンスが行われてからデータパケットの送信が３回行われたことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４によってデータパケット５が受信失敗されていることが認識され、データパケット５の再送が行われる。
【０１３１】
その後、データパケット６および７の送信が行われる。そして、データパケット７の送信が行われた時点で、前回ＢＡＲ／ＢＡのシーケンスが行われてからデータパケットの送信が３回行われたことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信され、Ｂｕｒｓｔ　Ａｃｋが受信される。この時点で、ＴＸＯＰ２期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳＮｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ２が終了する。
【０１３２】
次に、このタイミング設定例３において、送信局２における処理の流れについて図１０に示すフローチャートを参照しながら以下に説明する。ＣＦ−ＰＯＬＬを受信することによってＴＸＯＰが開始されると、Ｓ２１において、その時点までに送信局２が受信局３に対して送信したデータ量がＲｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ（ＲＯＢＳｉｚｅ）以上となっているか否かが判定される。この判定は、上記の比較例における判定基準に則ったものとなっている。すなわち、本タイミング設定例３は、タイミング設定例１および２と同様に、比較例におけるＢＡＲ／ＢＡのシーケンスの設定タイミングを含んだものとなっている。このＳ２１においてＹＥＳ、すなわち送信したデータ量がＲＯＢＳｉｚｅ以上となっている場合には、Ｓ２３のステップに移行し、ＴＸＯＰの残り時間が確認された上でＢＡＲ／ＢＡのシーケンスが行われる。
【０１３３】
なお、実際には、上記したように、ＲＯＢＳｉｚｅは比較的大きい値となっており、１回のＴＸＯＰの期間で送信可能なデータ量よりも大きい場合がほとんどであると考えられる。よって、上記Ｓ２１においてＹＥＳと判定される可能性はきわめて低いと予想される。すなわち、このＳ２１における判定は、何らかの事情によって送信したデータ量が大きくなってしまった場合のｆａｉｌ−ｓａｆｅとして機能するものとして考えればよい。
【０１３４】
Ｓ２１においてＮＯと判定されると、Ｓ２２において、データパケットの送信が所定回数行われたか否かが判定される。詳しく説明すると、送信局２が特定の受信局３にデータの送信を開始してから、あるいは、ＢＡＲ／ＢＡのシーケンスが行われた直後から、送信局２から特定の受信局３に向けてのデータパケットの送信回数が、所定回数となったか否かが判定される。このＳ２２においてＮＯ、すなわち、データパケットの送信が所定回数行われていないと判定された場合には、Ｓ２６からの処理に移行する。
【０１３５】
一方、Ｓ２２においてＹＥＳ、すなわち、データパケットの送信が所定回数行われたと判定された場合には、ＴＸＯＰ期間の残りが十分にあるかが確認された上で（Ｓ２３）、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される（Ｓ２４）。そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ２５）。
【０１３６】
その後、Ｓ２６において、送信すべきパケットがあるか否かが判定される。送信すべきパケットがないと判定された場合（Ｓ２６においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１３７】
一方、Ｓ２６においてＹＥＳ、すなわち、送信すべきパケットがあると判定された場合、Ｓ２７において、送信すべきパケットが、受信局３における再生に間に合うか否かが判定される。ここで再生に間に合わない（Ｓ２７においてＮＯ）と判定されたパケットは廃棄され（Ｓ２８）、Ｓ２６からのステップに戻ることになる。
【０１３８】
一方、Ｓ２７においてＹＥＳ、すなわち、送信すべきパケットがまだ有効である場合には、Ｓ２９において残りのＴＸＯＰ期間が十分であるかを確認した上で、そのパケットの送信が行われる（Ｓ３０）。その後、Ｓ２１からのステップに戻って、上記の処理がＴＸＯＰが終了するまで繰り返される。一方、ＴＸＯＰ期間の残りが十分にない場合（Ｓ２３あるいはＳ２９においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１３９】
以上のように、このタイミング設定例３では、データパケットの送信を所定の回数行ったごとにＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信が行われ、ＢＡＲ／ＢＡのシーケンスが実行されるようになっている。したがって、受信局３における受信バッファ１５のサイズ、および、制御局１から与えられるＴＸＯＰの長さに依存することなく、定期的にＢＡＲ／ＢＡのシーケンスを実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。これにより、動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【０１４０】
なお、上記のタイミング設定例３では、ＢＡＲ／ＢＡのシーケンスが行われるタイミングとして、データパケットの送信が所定回数行われるごととしているが、次のようなタイミングに設定してもよい。すなわち、ある時点において、送信局２が送信しようとしているデータパケットから所定個数前に送信したデータパケットが、受信局３において正常に受信されたことが未確認である場合に、ＢＡＲ／ＢＡのシーケンスを行うようにしてもよい。つまり、この変形実施例と、上記のタイミング設定例３との相違点としては、上記のタイミング設定例３では、データパケットの送信が所定回数行われるごとに必ずＢＡＲ／ＢＡのシーケンスが行われるようになっているのに対して、上記の変形実施例では、正常受信が未確認となっているデータパケットの送信から所定回数のデータパケットの送信が行われた際にＢＡＲ／ＢＡのシーケンスが行われるようになっている点である。
【０１４１】
（タイミング設定例４）
次に、本実施形態におけるタイミング設定例の第４の実施例について説明する。本実施例では、送信局２がＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを行うタイミングとして、ＢＡＲ／ＢＡのシーケンスが行われた直後から、送信局２から受信局３に向けてのデータパケットの送信回数が所定回数となった時点、および、送信局２が制御局１からＴＸＯＰを与えられた時に、そのＴＸＯＰの最初の時点が設定されるようになっている。
【０１４２】
図１１は、タイミング設定例４におけるデータ送信のシーケンスの一例を示している。この例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを６４としている。まず、送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ１期間の最初に、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、データパケット１〜３が受信局３に送信される。そして、前回ＢＡＲ／ＢＡのシーケンスが行われてからデータパケットの送信が３回行われたことが送信データ管理部７によって認識され、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４によってデータパケット２が受信失敗されていることが認識され、データパケット２の再送が行われる。
【０１４３】
その後、ＴＸＯＰ１期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ１が終了する。
【０１４４】
その後、再び送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ２期間の最初に、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、データパケット４〜６が受信局３に送信される。そして、前回ＢＡＲ／ＢＡのシーケンスが行われてからデータパケットの送信が３回行われたことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４によって再送すべきデータがないことが認識され、データパケット７の送信が行われる。そしてこの時点で、ＴＸＯＰ２期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ２が終了する。
【０１４５】
次に、このタイミング設定例４において、送信局２における処理の流れについて図１２に示すフローチャートを参照しながら以下に説明する。ＣＦ−ＰＯＬＬを受信することによってＴＸＯＰが開始されると、Ｓ３３のステップに移行し、ＴＸＯＰ期間の残りが十分にあるかが確認された上で（Ｓ３３）、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される（Ｓ３４）。
【０１４６】
そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ３５）。
【０１４７】
その後、Ｓ３６において、送信すべきパケットがあるか否かが判定される。送信すべきパケットがないと判定された場合（Ｓ３６においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１４８】
一方、Ｓ３６においてＹＥＳ、すなわち、送信すべきパケットがあると判定された場合、Ｓ３７において、送信すべきパケットが、受信局３における再生に間に合うか否かが判定される。ここで再生に間に合わない（Ｓ３７においてＮＯ）と判定されたパケットは廃棄され（Ｓ３８）、Ｓ３６からのステップに戻ることになる。
【０１４９】
一方、Ｓ３７においてＹＥＳ、すなわち、送信すべきパケットがまだ有効である場合には、Ｓ３９において残りのＴＸＯＰ期間が十分であるかを確認した上で、そのパケットの送信が行われる（Ｓ４０）。その後、Ｓ３１からのステップに戻って、その時点までに送信局２が受信局３に対して送信したデータ量がＲｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ（ＲＯＢＳｉｚｅ）以上となっているか否かが判定される。この判定は、上記の比較例における判定基準に則ったものとなっている。すなわち、本タイミング設定例４は、タイミング設定例１ないし３と同様に、比較例におけるＢＡＲ／ＢＡのシーケンスの設定タイミングを含んだものとなっている。このＳ３１においてＹＥＳ、すなわち送信したデータ量がＲＯＢＳｉｚｅ以上となっている場合には、Ｓ３３のステップに移行し、ＴＸＯＰの残り時間が確認された上でＢＡＲ／ＢＡのシーケンスが行われる。
【０１５０】
なお、実際には、上記したように、ＲＯＢＳｉｚｅは比較的大きい値となっており、１回のＴＸＯＰの期間で送信可能なデータ量よりも大きい場合がほとんどであると考えられる。よって、上記Ｓ３１においてＹＥＳと判定される可能性はきわめて低いと予想される。すなわち、このＳ３１における判定は、何らかの事情によって送信したデータ量が大きくなってしまった場合のｆａｉｌ−ｓａｆｅとして機能するものとして考えればよい。
【０１５１】
Ｓ３１においてＮＯと判定されると、Ｓ３２において、データパケットの送信が所定回数行われたか否かが判定される。詳しく説明すると、送信局２が特定の受信局３にデータの送信を開始してから、あるいは、ＢＡＲ／ＢＡのシーケンスが行われた直後から、送信局２から特定の受信局３に向けてのデータパケットの送信回数が、所定回数となったか否かが判定される。このＳ３２においてＮＯ、すなわち、データパケットの送信が所定回数行われていないと判定された場合には、Ｓ３６からの処理に移行する。
【０１５２】
一方、Ｓ３２においてＹＥＳ、すなわち、データパケットの送信が所定回数行われたと判定された場合には、ＴＸＯＰ期間の残りが十分にあるかが確認された上で（Ｓ３３）、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される（Ｓ３４）。そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ３５）。
上記の処理がＴＸＯＰが終了するまで繰り返される。一方、ＴＸＯＰ期間の残りが十分にない場合（Ｓ３３あるいはＳ３９においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する
以上のように、このタイミング設定例４では、データパケットの送信を所定の回数行ったときと送信局２が制御局１からＴＸＯＰを与えられた時に、そのＴＸＯＰの最初の時点に、ＢＡＲ／ＢＡのシーケンスが実行されるようになっている。したがって、受信局３における受信バッファ１５のサイズ、および、制御局１から与えられるＴＸＯＰの長さに依存することなく、定期的にＢＡＲ／ＢＡのシーケンスを実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。また、第一の通信局に送信権が付与された直後にも送達確認要求・返信処理が行われることになるので、第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができる。これにより、動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【０１５３】
（タイミング設定例５）
次に、本実施形態におけるタイミング設定例の第５の実施例について説明する。本実施例では、送信局２がＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを行うタイミングとして、ＢＡＲ／ＢＡのシーケンスが行われた直後から、送信局２から受信局３に向けてのデータパケットの送信回数が所定回数となった時点、および、送信局２が制御局１から所定の閾値以上の期間のＴＸＯＰを与えられた時に、そのＴＸＯＰの最初の時点が設定されるようになっている。
【０１５４】
図１３は、タイミング設定例４におけるデータ送信のシーケンスの一例を示している。この例では、Ｒｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅを６４としている。まず、送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ１の長さが閾値以上であると判断され、ＴＸＯＰ１期間の最初に、Ｂｕｒｓｔ　ＡｃｋＲｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、データパケット１〜３が受信局３に送信される。そして、前回ＢＡＲ／ＢＡのシーケンスが行われてからデータパケットの送信が３回行われたことが送信データ管理部７によって認識され、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４によってデータパケット２と３が受信失敗されていることが認識され、データパケット２と３の再送が行われる。
【０１５５】
その後、ＴＸＯＰ１期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ１が終了する。
【０１５６】
その後、再び送信局２にＣＦ−ＰＯＬＬが与えられると、ＴＸＯＰ２の長さが閾値以上ではないと判断され、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）の送信は行わずに、データパケット４が受信局３に送信される。そして、前回ＢＡＲ／ＢＡのシーケンスが行われてからデータパケットの送信が３回行われたことが送信データ管理部７によって認識され、この時点でＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ（Ｒｅｑ）が送信局２から受信局３に送信される。その後、送信局２が受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４によって再送すべきデータがないことが認識され、データパケット５と６の送信が行われる。そしてこの時点で、ＴＸＯＰ２期間の残りが少なくなったことが送信データ管理部７によって認識され、ＱｏＳ　Ｎｕｌｌが制御局１に向けて送信される。これによりＴＸＯＰ２が終了する。
【０１５７】
次に、このタイミング設定例５において、送信局２における処理の流れについて図１４に示すフローチャートを参照しながら以下に説明する。ＣＦ−ＰＯＬＬを受信することによってＴＸＯＰが開始されると、Ｓ４１においてＴＸＯＰの長さが閾値以上であるか否かが判断される。このＳ４１においてＹＥＳ、すなわちＴＸＯＰの長さが閾値を以上である場合には、ＴＸＯＰ期間の残りが十分にあるかが確認された上で（Ｓ４４）、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される（Ｓ４５）。そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ４６）。
【０１５８】
一方、Ｓ４１においてＮＯと判定されるとＳ４２へと進み、Ｓ４２において、その時点までに送信局２が受信局３に対して送信したデータ量がＲｅ−Ｏｒｄｅｒｉｎｇ　Ｂｕｆｆｅｒ　Ｓｉｚｅ（ＲＯＢＳｉｚｅ）以上となっているか否かが判定される。この判定は、上記の比較例における判定基準に則ったものとなっている。すなわち、本タイミング設定例５は、タイミング設定例１ないし４と同様に、比較例におけるＢＡＲ／ＢＡのシーケンスの設定タイミングを含んだものとなっている。このＳ４２においてＹＥＳ、すなわち送信したデータ量がＲＯＢＳｉｚｅ以上となっている場合には、Ｓ４４のステップに移行し、ＴＸＯＰの残り時間が確認された上でＢＡＲ／ＢＡのシーケンスが行われる。
【０１５９】
なお、実際には、上記したように、ＲＯＢＳｉｚｅは比較的大きい値となっており、１回のＴＸＯＰの期間で送信可能なデータ量よりも大きい場合がほとんどであると考えられる。よって、上記Ｓ４２においてＹＥＳと判定される可能性はきわめて低いと予想される。すなわち、このＳ４２における判定は、何らかの事情によって送信したデータ量が大きくなってしまった場合のｆａｉｌ−ｓａｆｅとして機能するものとして考えればよい。
【０１６０】
Ｓ４２においてＮＯと判定されると、Ｓ４３において、データパケットの送信が所定回数行われたか否かが判定される。詳しく説明すると、送信局２が特定の受信局３にデータの送信を開始してから、あるいは、ＢＡＲ／ＢＡのシーケンスが行われた直後から、送信局２から特定の受信局３に向けてのデータパケットの送信回数が、所定回数となったか否かが判定される。このＳ４３においてＮＯ、すなわち、データパケットの送信が所定回数行われていないと判定された場合には、Ｓ４７からの処理に移行する。
【０１６１】
一方、Ｓ４３においてＹＥＳ、すなわち、データパケットの送信が所定回数行われたと判定された場合には、ＴＸＯＰ期間の残りが十分にあるかが確認された上で（Ｓ４４）、送信局２は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔを受信局３に送信することによって、ＢＡＲ／ＢＡのシーケンスが実行される（Ｓ４５）。そして、送信局２は、受信局３からＢｕｒｓｔ　Ａｃｋを受信すると、Ｂｕｒｓｔ　Ａｃｋ解析部４が、Ｂｕｒｓｔ　Ａｃｋ　Ｂｉｔｍａｐを解析することによって、再送すべきパケットを検索する（Ｓ４６）。
【０１６２】
その後、Ｓ４７において、送信すべきパケットがあるか否かが判定される。送信すべきパケットがないと判定された場合（Ｓ４７においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１６３】
一方、Ｓ４７においてＹＥＳ、すなわち、送信すべきパケットがあると判定された場合、Ｓ４８において、送信すべきパケットが、受信局３における再生に間に合うか否かが判定される。ここで再生に間に合わない（Ｓ４８においてＮＯ）と判定されたパケットは廃棄され（Ｓ４９）、Ｓ４７からのステップに戻ることになる。
【０１６４】
一方、Ｓ４８においてＹＥＳ、すなわち、送信すべきパケットがまだ有効である場合には、Ｓ５０において残りのＴＸＯＰ期間が十分であるかを確認した上で、そのパケットの送信が行われる（Ｓ５１）。その後、Ｓ４２からのステップに戻って、上記の処理がＴＸＯＰが終了するまで繰り返される。一方、ＴＸＯＰ期間の残りが十分にない場合（Ｓ４４あるいはＳ５０においてＮＯ）には、送信局２はＱｏＳ　Ｎｕｌｌを制御局１に送信することによって、ＴＸＯＰを終了する。
【０１６５】
以上のように、このタイミング設定例５では、データパケットの送信が所定の回数行われた時点、および、ＴＸＯＰの長さが閾値以上であった場合にＴＸＯＰを付与された直後の時点で、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔの送信が行われ、ＢＡＲ／ＢＡのシーケンスが実行されるようになっている。したがって、受信局３における受信バッファ１５のサイズに依存することなく、定期的にＢＡＲ／ＢＡのシーケンスを実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となる。また、ＴＸＯＰに余裕があるときには、ＴＸＯＰの最初にＢＡＲ／ＢＡのシーケンスが行われることによって、送信局２は受信局３との通信状況をいち早く知ることが可能となる。これにより、動画などのストリームデータを送受信している場合に、再生側の映像の乱れや音声の途切れなどが生じることなく、良好な再生動作を行わせることが可能となる。
【０１６６】
また、ＴＸＯＰの長さが所定の閾値より短い、すなわちＴＸＯＰに余裕がない場合には、ＴＸＯＰの最初にはＢＡＲ／ＢＡのシーケンスが行われないことになる。よって、ＢＡＲ／ＢＡのシーケンスに必要とされる期間をデータパケットの送信に割り当てることが可能となるので、ＴＸＯＰの最初に必ずＢＡＲ／ＢＡのシーケンスを行う場合と比較して、長さが短いＴＸＯＰにおけるデータパケットの伝送効率を向上させることができる。
【０１６７】
【発明の効果】
以上のように、本発明に係る通信管理方法は、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が、上記第１の通信局に送信権が付与された直後に行われるものとする方法である。
【０１６８】
これにより、第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となるという効果を奏する。
【０１６９】
また、たとえ送達確認要求・返信処理の送受信の失敗を数回繰り返したとしても、ほぼ確実に同じ送信権付与期間内で送達確認要求・返信処理を完了することが可能となり、再送処理も迅速に行うことが可能となるという効果を奏する。
【０１７０】
また、本発明に係る通信管理方法は、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間の最後に行われるものとする方法である。
【０１７１】
これにより、第１の通信局における送達確認情報の解析および再送処理を行うブロックを、高速な処理を行うことが可能な回路で構成する必要がなくなる。よって、コストの高い高速な演算装置などを実装する必要がなくなり、装置コストの低減を図ることができるという効果を奏する。
【０１７２】
また、本発明に係る通信管理方法は、上記ネットワークシステムに、該ネットワークシステムにおける送信権の付与に関するスケジューリングを行う制御局が設けられているとともに、上記送達確認要求・返信処理の後に、上記第１の通信局が、その時点での第１の通信局におけるバッファ状況を示す情報または送信権を付与して欲しい期間の情報を上記制御局に対して送信するものとする方法としてもよい。
【０１７３】
これにより、上記の方法による効果に加えて、制御局に対しては、最新の送達確認要求・返信処理の結果を反映したバッファ状況に関する情報を送信することが可能となる。したがって、よりアップデートなバッファ状況または送信権を付与して欲しい期間の情報を制御局に送信することができるので、制御局による、より最適なスケジューリングを期待することができるという効果を奏する。
【０１７４】
また、本発明に係る通信管理方法は、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとする方法である。
【０１７５】
これにより、例えば受信局としての第２の通信局における受信バッファのサイズや、制御局から与えられる送信権の付与期間の長さなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となるという効果を奏する。
【０１７６】
また、本発明に係る通信管理方法は、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局に対して送信しようとしているデータパケットから所定個数前に送信したデータパケットが、第２の通信局において正常に受信されたことが未確認である場合に、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとする方法である。
【０１７７】
これにより、例えば受信局としての第２の通信局における受信バッファのサイズや、制御局から与えられる送信権の付与期間の長さなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となるという効果を奏する。
【０１７８】
また、本発明に係る通信管理方法は、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点、および、上記第１の通信局に送信権が付与された直後の時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとする方法である。
【０１７９】
これにより、例えば受信局としての第２の通信局における受信バッファのサイズや、制御局から与えられる送信権の付与期間の長さなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となるという効果を奏する。また、第１の通信局に送信権が付与された直後にも送達確認要求・返信処理が行われることになるので、第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができるという効果を奏する。
【０１８０】
また、本発明に係る通信管理方法は、上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点、および、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に、該送信権を付与された直後の時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとする方法である。
【０１８１】
これにより、例えば受信局としての第２の通信局における受信バッファのサイズなどに依存することなく、定期的に送達確認要求・返信処理を実行することが可能となるので、再送処理が必要以上に遅れることなく、適切なタイミングで行うことが可能となるという効果を奏する。また、第１の通信局に送信権が付与された期間が閾値以上である場合には送信権を付与された直後にも送達確認要求・返信処理が行われ、閾値以下である場合には送達確認要求・返信処理が行われないことになるので、送信権を付与された期間に余裕がある場合には第１の通信局は第２の通信局との間の通信路状況をいち早く知ることができるという効果を奏する。
【０１８２】
また、送達確認要求・返信処理に必要とされる期間をデータパケットの送信に割り当てることが可能となるので、第１の通信局に送信権が付与された期間が短い場合におけるデータパケットの伝送効率を向上させることができるという効果を奏する。
【０１８３】
また、本発明に係る通信管理方法は、上記第１の通信局が、有効期限が残っているデータパケットに関する送達確認情報を上記第２の通信局に要求する方法としてもよい。
【０１８４】
これにより、上記の方法による効果に加えて、第１の通信局における再送処理の手間、すなわち、再送を行おうとしているデータパケットが、受信側での再生時刻に間に合うかを判定する手間を削減することが可能となるという効果を奏する。
【０１８５】
また、本発明に係る通信管理方法は、上記第１の通信局から上記第２の通信局に向けてデータの送信を新たに開始する際に、最初に第１の通信局に送信権が付与された直後には、送達確認要求・返信処理が行われずに、次回以降に第１の通信局に送信権が付与された直後から送達確認要求・返信処理が行われるものとする方法としてもよい。
【０１８６】
これにより、上記の方法による効果に加えて、最初に第１の通信局に送信権が付与された直後には、送達確認要求・返信処理を行わないようにすることによって、この送信権付与期間において、送達確認要求・返信処理に要する時間を、通常のデータパケットの通信に使用することが可能となるという効果を奏する。
【０１８７】
また、本発明に係る通信管理方法は、上記第１の通信局に送信権が付与された直後に行われる上記送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に行われるものとする方法としてもよい。
【０１８８】
これにより、上記の方法による効果に加えて、送達確認要求・返信処理に必要とされる期間をデータパケットの送信に割り当てることが可能となるので、第１の通信局に送信権が付与された期間が短い場合におけるデータパケットの伝送効率を向上させることができるという効果を奏する。
【０１８９】
また、本発明に係る通信管理方法は、上記第１の通信局に送信権が付与された期間の最後に行われる上記送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に行われるものとする方法としてもよい。
【０１９０】
これにより、上記の方法による効果に加えて、送達確認要求・返信処理に必要とされる期間をデータパケットの送信に割り当てることが可能となるので、第１の通信局に送信権が付与された期間が短い場合におけるデータパケットの伝送効率を向上させることができるという効果を奏する。
【０１９１】
また、本発明に係る通信管理方法は、上記送達確認要求・返信処理が、ＩＥＥＥ　８０２．１１のＴＧｅ（Ｔａｓｋ　Ｇｒｏｕｐ　Ｅ）で策定されたＩＥＥＥＳｔｄ　８０２．１１ｅ／Ｄ３．０，Ｍａｙ　２００２のドキュメントにおけるＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋのシーケンスである方法としてもよい。
【０１９２】
これにより、上記の方法による効果に加えて、ＴＧｅで策定されている規格に準拠する通信管理方法において、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋのシーケンスを的確なタイミングで行うことが可能となり、例えば動画などのストリームデータの送受信を最適な状態で行うことが可能となるという効果を奏する。
【０１９３】
また、本発明に係る通信管理プログラムは、上記の通信管理方法をコンピュータに実行させるものである。
【０１９４】
これにより、上記プログラムをコンピュータシステムにロードすることによって、上記通信管理方法をユーザに提供することが可能となるという効果を奏する。
【０１９５】
また、本発明に係る通信管理プログラムを記録した記録媒体は、上記の通信管理方法をコンピュータに実行させる通信管理プログラムを記録している構成である。
【０１９６】
これにより、上記記録媒体に記録されたプログラムをコンピュータシステムにロードすることによって、上記通信管理方法をユーザに提供することが可能となるという効果を奏する。
【０１９７】
また、本発明に係る通信局は、上記通信ネットワークを介して他の通信局に対してデータの送信を行う送信部と、上記本発明に係る通信管理方法を用いて上記送信部によるデータの送信を管理する送信データ管理部とを備えている構成である。
【０１９８】
これにより、上記本発明に係る通信管理方法に基づいて動作を行う通信局を提供することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るネットワークシステムにおいて、タイミング設定例１におけるデータ送信のシーケンスの一例を示す図である。
【図２】上記ネットワークシステムにおけるシグナルフローを示す説明図である。
【図３】同図（ａ）は、Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔのデータ構成、同図（ｂ）は、Ｂｕｒｓｔ　Ａｃｋのデータ構成をそれぞれ示す図である。
【図４】送信局の概略構成を示すブロック図である。
【図５】受信局の概略構成を示すブロック図である。
【図６】タイミング設定例１において、送信局における処理の流れを示すフローチャートである。
【図７】タイミング設定例２におけるデータ送信のシーケンスの一例を示す図である。
【図８】タイミング設定例２において、送信局における処理の流れを示すフローチャートである。
【図９】タイミング設定例３におけるデータ送信のシーケンスの一例を示す図である。
【図１０】タイミング設定例３において、送信局における処理の流れを示すフローチャートである。
【図１１】タイミング設定例４におけるデータ送信のシーケンスの一例を示す図である。
【図１２】タイミング設定例４において、送信局における処理の流れを示すフローチャートである。
【図１３】タイミング設定例５におけるデータ送信のシーケンスの一例を示す図である。
【図１４】タイミング設定例５において、送信局における処理の流れを示すフローチャートである。
【図１５】ある送信局におけるＴＸＯＰ期間中での送信シーケンスの一例を示す図である。
【図１６】比較例におけるデータ送信のシーケンスの一例を示す図である。
【図１７】比較例において、送信局における処理の流れを示すフローチャートである。
【図１８】Ｂｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋのシーケンスのリトライ動作の一例を示す図である。
【符号の説明】
１　　制御局
２　　送信局（通信局）
３　　受信局（通信局）
４　　Ｂｕｒｓｔ　Ａｃｋ解析部
７　　送信データ管理部
９　　送信バッファ
１０　　受信制御部
１３　　受信データ管理部
１４　　Ｂｕｒｓｔ　Ａｃｋ送信制御部
１５　　受信バッファ

Claims (15)

1. 複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、
   上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、
   第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、
   上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が、上記第１の通信局に送信権が付与された直後に行われるものとすることを特徴とする通信管理方法。
2. 複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、
   上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、
   第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、
   上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間の最後に行われるものとすることを特徴とする通信管理方法。
3. 上記ネットワークシステムに、該ネットワークシステムにおける送信権の付与に関するスケジューリングを行う制御局が設けられているとともに、
   上記送達確認要求・返信処理の後に、上記第１の通信局が、その時点での第１の通信局におけるバッファ状況または送信権を付与して欲しい期間の情報を示す情報を上記制御局に対して送信するものとすることを特徴とする請求項２記載の通信管理方法。
4. 複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、
   上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、
   第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、
   上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴とする通信管理方法。
5. 複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、
   上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、
   第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、
   上記第１の通信局が上記第２の通信局に対して送信しようとしているデータパケットから所定個数前に送信したデータパケットが、第２の通信局において正常に受信されたことが未確認である場合に、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴とする通信管理方法。
6. 複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、
   上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、
   第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、
   上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点、および、上記第１の通信局に送信権が付与された直後の時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴とする通信管理方法。
7. 複数の通信局が通信ネットワークを介して接続されているネットワークシステムで用いられる通信管理方法であって、
   上記通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみとし、
   第１の通信局が、第２の通信局に対してデータパケットの送信を行っている場合、上記第２の通信局が、上記第１の通信局からの要求に応じて、受信した複数のデータパケットに対する送達確認情報を返信し、上記第１の通信局が、送達確認情報に基づいてデータパケットの再送処理を行うものとし、
   上記第１の通信局が上記第２の通信局にデータの送信を開始してから、あるいは、送達確認要求・返信処理が行われた直後から、上記第１の通信局から上記第２の通信局に向けてのデータパケットの送信回数が所定回数となった時点、および、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に、該送信権を付与された直後の時点で、上記第１の通信局と上記第２の通信局との間での送達確認要求・返信処理が行われるものとすることを特徴とする通信管理方法。
8. 上記第１の通信局が、有効期限が残っているデータパケットに関する送達確認情報を上記第２の通信局に要求することを特徴とする請求項１、６または７記載の通信管理方法。
9. 上記第１の通信局から上記第２の通信局に向けてデータの送信を新たに開始する際に、最初に第１の通信局に送信権が付与された直後には、送達確認要求・返信処理が行われずに、次回以降に第１の通信局に送信権が付与された直後から送達確認要求・返信処理が行われるものとすることを特徴とする請求項１、６、７、または８記載の通信管理方法。
10. 上記第１の通信局に送信権が付与された直後に行われる上記送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に行われるものとすることを特徴とする請求項１記載の通信管理方法。
11. 上記第１の通信局に送信権が付与された期間の最後に行われる上記送達確認要求・返信処理が、上記第１の通信局に送信権が付与された期間が閾値以上となる場合に行われるものとすることを特徴とする請求項２記載の通信管理方法。
12. 上記送達確認要求・返信処理が、ＩＥＥＥ　８０２．１１のＴＧｅ（ＴａｓｋＧｒｏｕｐ　Ｅ）で策定されたＩＥＥＥ　Ｓｔｄ　８０２．１１ｅ／Ｄ３．０，Ｍａｙ　２００２のドキュメントにおけるＢｕｒｓｔ　Ａｃｋ　Ｒｅｑｕｅｓｔ／Ｂｕｒｓｔ　Ａｃｋのシーケンスであることを特徴とする請求項１ないし１１のいずれか一項に記載の通信管理方法。
13. 請求項１ないし１２のいずれか一項に記載の通信管理方法をコンピュータに実行させる通信管理プログラム。
14. 請求項１ないし１２のいずれか一項に記載の通信管理方法をコンピュータに実行させる通信管理プログラムを記録した記録媒体。
15. 通信ネットワークを介してデータの送信ができる通信局は、その時点で送信権を有している通信局のみと設定されているネットワークシステムに含まれる通信局であって、
    上記通信ネットワークを介して他の通信局に対してデータの送信を行う送信部と、
    請求項１ないし１２のいずれか一項に記載の通信管理方法を用いて上記送信部によるデータの送信を管理する送信データ管理部とを備えていることを特徴とする通信局。

Images