(57)【要約】【課題】十分な伝送スループットを得ることができないという問題を解決する通信装置を提供する。【解決手段】バッファ１２は、送信データユニットおよび受信データユニットを一時的に記憶する。測定部１６は、バッファ１２の送信データユニットによる使用率である送信バッファ使用率と、バッファ１２の受信データユニットによる使用率である受信バッファ使用率とを測定する。調整部１７は、その送信バッファ使用率および受信バッファ使用率に基づいて、対向する通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、対向する通信装置の送信ウィンドウサイズ分の受信データユニットおよび対向する通信装置の受信ウィンドウサイズ分の送信データユニットを記憶することが可能なバッファサイズが、対向する通信装置に予め定められたバッファサイズを超えない範囲で調整する。【選択図】図１
2009224834.tif 000002
【特許請求の範囲】
【請求項１】
通信相手となる通信装置とウィンドウ制御で伝送可能な通信装置であって、
前記通信相手となる通信装置に送信する送信データユニットと、前記通信相手となる通信装置から受信した受信データユニットと、を一時的に記憶する記憶手段と、
前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定する測定手段と、
前記測定手段にて測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットの量との合計が予め定められたデータ量を超えない範囲で調整する調整手段と、を含む通信装置。
【請求項２】
請求項１に記載の通信装置において、
前記調整手段は、前記送信使用率および前記受信使用率の差分値を算出し、該差分値に基づいて、前記送信ウィンドウサイズおよび前記受信ウィンドウサイズを調整する、通信装置。
【請求項３】
請求項２に記載の通信装置において、
前記調整手段は、前記送信使用率から前記受信使用率を引いた値を差分値として算出し、前記差分値が予め定められた所定値以上か否かを判断し、前記差分値が前記所定値以上であると、前記送信ウィンドウサイズを上げ、かつ、前記受信ウィンドウサイズを下げる、通信装置。
【請求項４】
請求項２または３に記載の通信装置において、
前記調整手段は、前記送信使用率が予め定められた基準値以上か否かを判断し、前記送信使用率が前記基準値以上であると、前記差分値を算出する、通信装置。
【請求項５】
ウィンドウ制御で伝送可能な複数の通信装置を含む通信システムであって、
各通信装置は、
通信相手となる通信装置に送信する送信データユニットと、前記通信相手となる通信装置から受信した受信データユニットと、を一時的に記憶する記憶手段と、
前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定する測定手段と、
前記測定手段にて測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットと、前記受信ウィンドウサイズ分の前記送信データユニットとの合計が予め定められたデータ量を超えない範囲で調整する調整手段と、を含む、通信システム。
【請求項６】
請求項５に記載の通信システムにおいて、
前記調整手段は、前記送信使用率および前記受信使用率の差分値を算出し、該差分値に基づいて、前記送信ウィンドウサイズおよび前記受信ウィンドウサイズを調整する、通信システム。
【請求項７】
請求項６に記載の通信システムにおいて、
前記調整手段は、前記送信使用率から前記受信使用率を引いた値を差分値として算出し、前記差分値が予め定められた所定値以上か否かを判断し、前記差分値が前記所定値以上であると、前記送信ウィンドウサイズを上げ、かつ、前記受信ウィンドウサイズを下げる、通信システム。
【請求項８】
請求項６または７に記載の通信システムにおいて、
前記調整手段は、前記送信使用率が予め定められた基準値以上か否かを判断し、前記送信使用率が前記基準値以上であると、前記差分値を算出する、通信システム。
【請求項９】
通信相手となる通信装置に送信する送信データユニットと前記通信相手となる通信装置から受信した受信データユニットとを一時的に記憶する記憶手段を含み、前記通信相手となる通信装置とウィンドウ制御で伝送可能な通信装置によるウィンドウサイズ調整方法であって、
前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定し、
前記測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットの量との合計が予め定められたデータ量を超えない範囲で調整する、ウィンドウサイズ調整方法。
【請求項１０】
請求項９に記載のウィンドウサイズ調整方法において、
前記送信使用率および前記受信使用率の差分値を算出し、該差分値に基づいて、前記送信ウィンドウサイズおよび前記受信ウィンドウサイズを調整する、ウィンドウサイズ調整方法。
【請求項１１】
請求項１０に記載のウィンドウサイズ調整方法において、
前記送信使用率から前記受信使用率を引いた値を差分値として算出し、前記差分値が予め定められた所定値以上か否かを判断し、
前記差分値が前記所定値以上であると、前記送信ウィンドウサイズを上げ、かつ、前記受信ウィンドウサイズを下げる、ウィンドウサイズ調整方法。
【請求項１２】
請求項１０または１１に記載のウィンドウサイズ調整方法において、
前記送信使用率が予め定められた基準値以上か否かを判断し、
前記送信使用率が前記基準値以上であると、前記差分値を算出する、ウィンドウサイズ調整方法。
【請求項１３】
互いにウィンドウ制御で伝送可能な複数の通信装置を含み、各通信装置が通信相手となる通信装置に送信する送信データユニットと前記通信相手となる通信装置から受信した受信データユニットとを一時的に記憶する記憶手段を含む、通信システムによるウィンドウサイズ調整方法であって、
各通信装置が、前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定し、
各通信装置が、前記測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットの量との合計が予め定められたデータ量を超えない範囲で調整する、ウィンドウサイズ調整方法。
【請求項１４】
請求項１３に記載のウィンドウサイズ調整方法において、
各通信装置が、前記送信使用率および前記受信使用率の差分値を算出し、該差分値に基づいて、前記送信ウィンドウサイズおよび前記受信ウィンドウサイズを調整する、ウィンドウサイズ調整方法。
【請求項１５】
請求項１４に記載のウィンドウサイズ調整方法において、
各通信装置が、前記送信使用率から前記受信使用率を引いた値を差分値として算出し、前記差分値が予め定められた所定値以上か否かを判断し、
前記差分値が前記所定値以上であると、前記送信ウィンドウサイズを上げ、かつ、前記受信ウィンドウサイズを下げる、ウィンドウサイズ調整方法。
【請求項１６】
請求項１４または１５に記載のウィンドウサイズ調整方法において、
前記送信使用率が予め定められた基準値以上か否かを判断し、
前記送信使用率が前記基準値以上であると、前記差分値を算出する、ウィンドウサイズ調整方法。
【請求項１７】
通信装置と、前記通信装置に送信する送信データユニットと前記通信装置から受信した受信データユニットとを一時的に記憶する記憶手段と、に接続されたコンピュータに、
前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定する手順と、
前記測定された送信使用率および受信使用率に基づいて、前記通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットとの量の合計が予め定められたデータ量を超えない範囲で調整する手順と、を実行させるプログラム。
【請求項１８】
請求項１７に記載のプログラムにおいて、
前記調整する手順は、前記送信使用率および前記受信使用率の差分値を算出し、該差分値に基づいて、前記送信ウィンドウサイズおよび前記受信ウィンドウサイズを調整する手順を含む、プログラム。
【請求項１９】
請求項１８に記載のプログラムにおいて、
前記調整する手順は、
前記送信使用率から前記受信使用率を引いた値を差分値として算出し、前記差分値が予め定められた所定値以上か否かを判断する手順と、
前記差分値が前記所定値以上であると、前記送信ウィンドウサイズを上げ、かつ、前記受信ウィンドウサイズを下げる手順と、を含む、プログラム。
【請求項２０】
請求項１８または１９に記載のプログラムにおいて、
前記調整する手順は、
前記送信使用率が予め定められた基準値以上か否かを判断する手順と、
前記送信使用率が前記基準値以上であると、前記差分値を算出する手順と、を含む、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウィンドウ制御により伝送を行う通信装置、通信システム、ウィンドウサイズ調整方法およびプログラムに関する。
【背景技術】
【０００２】
Ｗ‐ＣＤＭＡ（Wideband Code Division Multiple Access：広帯域符号分割多重接続）などを用いた第３世代移動通信システムでは、ＵＥ（User Equipment：移動端末）およびＲＮＣ（Radio Network Controller：無線制御装置）は、互いにＣ‐Ｐｌａｎｅ信号（制御信号）を送受信するＣ‐Ｐｌａｎｅ伝送と、音声およびパケットなどのＵ‐Ｐｌａｎｅ信号（ユーザデータ）を送受信するＵ‐Ｐｌａｎｅ伝送とを行う。なお、ＵＥおよびＲＮＣ間の伝送は、ＮｏｄｅＢ（基地局装置）を経由して行われる。
【０００３】
図５は、ＵＥ、ＮｏｄｅＢおよびＲＮＣが構成するＵＴＲＡＮ（Universal Terrestrial Radio Access Network：無線アクセス網）の無線プロトコルの構成を示した概略図である。図５では、ＵＥ１０１の無線プロトコルの構成と、ＮｏｄｅＢおよびＲＮＣからなるＲＡＮ（Radio Access Network）１０２の無線プロトコルの構成とが示されている。
【０００４】
ＵＥ１０１およびＲＡＮ１０２のそれぞれは、ＰＨＹ（Physical）エンティティ、ＭＡＣ（Medium Access Control）エンティティ、ＲＬＣ（Radio Link Control）エンティティ、ＲＲＣ（Radio Resource Control）エンティティおよびＰＤＣＰ（Packet Data Convergence Protocol）エンティティを含む。
【０００５】
なお、ＲＬＣエンティティは、図５では、ＵＥ１０１およびＲＡＮ１０２のそれぞれにひとつだけ含まれているが、実際には、複数ある。複数のＲＬＣエンティティには、制御用のＲａｄｉｏ‐Ｂｅａｒｅｒ（無線ベアラ）や一つまたは複数のパケット通信用のＲａｄｉｏ‐Ｂｅａｒｅｒのそれぞれが割り当てられている。
【０００６】
ＵＥおよびＲＮＣにおいて、ＲＬＣエンティティ間の伝送は、以下のように行われる。
【０００７】
先ず、送信側のＲＬＣエンティティは、送信側のＲＲＣエンティティからのＣ‐Ｐｌａｎｅ信号と、送信側のＰＤＣＰエンティティからのＵ‐Ｐｌａｎｅ信号のそれぞれをＲＬＣ‐ＰＤＵ（Protocol Data Unit：制御用プロトコルデータユニット）に分割する。そして、送信側のＲＬＣエンティティは、その分割したＲＬＣ‐ＰＤＵのそれぞれを、対向ＲＬＣエンティティ（受信側のＲＬＣエンティティ）に送信する。
【０００８】
なお、ＲＬＣ‐ＰＤＵのサイズは、伝送方向ごとに異なっていてもよい。つまり、ＵＬ(Uplink：アップリンク)方向に伝送されるＲＬＣ‐ＰＤＵのサイズ（ＵＬ‐ＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ）と、ＤＬ(Downlink：ダウンリンク)方向に伝送されるＲＬＣ‐ＰＤＵのサイズ（ＤＬ‐ＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ）とは、互いに異なっていてもよい。また、ＲＬＣ‐ＰＤＵの送受信は、ＭＡＣエンティティおよびＰＨＹエンティティを経由して行われる。
【０００９】
ＲＬＣエンティティの動作モードには、順序制御および再送制御を行うことで、ＵＥおよびＲＮＣ間の伝送の信頼性を保障するＡＭモード（Acknowledgment Mode）がある。ＡＭモードは、ＲＬＣエンティティごとに個別に設定することが可能である。
【００１０】
ＡＭモードが設定されたＲＬＣエンティティは、ＲＬＣ‐ＡＭエンティティまたは単にＡＭエンティティと呼ばれる。また、ＲＬＣ‐ＡＭエンティティで伝送されるＲＬＣ‐ＰＤＵは、特にＡＭＤ（AM Data）‐ＰＤＵとも呼ばれる。
【００１１】
ＲＬＣ‐ＡＭエンティティは、Ｃ‐Ｐｌａｎｅ信号やパケットをＡＭＤ‐ＰＤＵに分割すると、そのＡＭＤ‐ＰＤＵのそれぞれに送信順にＳＮ（Sequence Number：シーケンス番号)を付加する。ＲＬＣ‐ＡＭエンティティは、ＳＮ順にＡＭＤ‐ＰＤＵを対向ＲＬＣ‐ＡＭエンティティに送信する。
【００１２】
ＲＬＣ‐ＡＭエンティティは、そのＡＭＤ‐ＰＤＵに対する確認応答を受信すると、そのＡＭＤ‐ＰＤＵが正常に対向ＲＬＣ‐ＡＭエンティティに到達したと判断して、次のＳＮが付加されたＡＭＤ‐ＰＤＵを対向ＲＬＣ‐ＡＭエンティティに送信する。また、ＲＬＣ‐ＡＭエンティティは、その所定時間内にＡＭＤ‐ＰＤＵに対する確認応答を受信できなかった場合、そのＡＭＤ‐ＰＤＵが対向ＲＬＣ‐ＡＭエンティティに到達していないと判断して、先に送信したＡＭＤ‐ＰＤＵを対向ＲＬＣ‐ＡＭエンティティに再送する。
【００１３】
なお、ＲＬＣ‐ＡＭエンティティは、対向ＲＬＣ‐ＡＭエンティティから、確認応答を含むＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵ(状態報告のProtocol Data Unit)メッセージを受信することで、確認応答を受信している。
【００１４】
これにより、ＵＥおよびＲＮＣ間の伝送の信頼性が保障される。しかしながら、ＲＬＣ‐ＡＭエンティティは、ＡＭＤ‐ＰＤＵを送信するたびに確認応答を受信しなければならないので、伝送スループット（単位時間当たりの伝送量）が低下する。
【００１５】
ＡＭＤ‐ＰＤＵのサイズを大きくすれば、一度に送信可能な伝送量が増えるので、伝送スループットが向上する。しかしながら、特に輻輳などにより回線状態が悪い場合などでは、ＡＭＤ‐ＰＤＵのサイズが大きいと、ＡＭＤ‐ＰＤＵが正常に対向ＲＬＣ‐ＡＭエンティティに到達する割合が低下するため、ＡＭＤ‐ＰＤＵの再送回数の増加を招き、かえって、伝送スループットが低下することがある。
【００１６】
特許文献１に記載の移動電話システムでは、ＡＭＤ‐ＰＤＵの誤り率を反映するサービス品質（Ｑｏｓ）に応じて、ＡＭＤ‐ＰＤＵのサイズを適切な値に選択している。
【００１７】
具体的には、ＡＭＤ‐ＰＤＵのサイズと、送信時間内にＲＬＣ‐ＰＤＵを送信することが可能な送信可能数との組み合わせが記憶され、その組み合わせの中から、サービス品質が維持されるような組み合わせが選択される。そして、その選択された組み合わせのＡＭＤ‐ＰＤＵのサイズと送信可能数で、ＲＬＣ‐ＡＭエンティティ間の伝送が行われる。
【００１８】
これにより、サービス品質が維持されるので、ＡＭＤ‐ＰＤＵが正常に対向ＲＬＣ‐ＡＭエンティティに到達する割合の低下を抑制することが可能になる。したがって、伝送スループットを向上させることが可能になる。
【００１９】
しかしながら、特許文献１に記載の移動電話システムのように、ＡＭＤ‐ＰＤＵのサイズを変更する方法では、ＡＭＤ‐ＰＤＵを送信するたびに確認応答を受信しなければならないという問題の解決には至らない。
【００２０】
ＡＭＤ‐ＰＤＵを送信するたびに確認応答を受信しなくてもよい技術としては、ＴＣＰエンティティが行うようなウィンドウ制御がある。
【００２１】
ウィンドウ制御では、所定数のＡＭＤ‐ＰＤＵが確認応答の受信なしで連続して送信され、その所定数のＡＭＤ‐ＰＤＵのうち、正常に対向ＲＬＣ‐ＡＭエンティティに到達したＡＭＤ‐ＰＤＵに対する確認応答を含むＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージが受信される。このため、ＡＭＤ‐ＰＤＵを送信するたびに確認応答を受信しなくてもよくなるため、伝送スループットが向上する。
【００２２】
ここで、ＲＬＣ‐ＡＭエンティティにおいて、確認応答の受信なしで連続して送信することが可能なＡＭＤ‐ＰＤＵの数（所定数）は、送信ウィンドウサイズと呼ばれる。また、対向ＲＬＣ‐ＡＭエンティティにおいて、確認応答の送信なしで連続して受信することが可能なＡＭＤ‐ＰＤＵの数は、受信ウィンドウサイズと呼ばれる。さらに、送信ウィンドウサイズおよび受信ウィンドウサイズを、ウィンドウサイズと総称されることもある。
【００２３】
なお、対向ＲＬＣ‐ＡＭエンティティでは、受信ウィンドウサイズ分のＡＭＤ‐ＰＤＵが受信されなくても、所定のタイミングごとに確認応答が送信される。
【００２４】
ウィンドウ制御を行うためには、送信側のＲＬＣ‐ＡＭエンティティは、状態変数ＶＴ（Ａ）、ＶＴ（ＭＳ）、ＶＴ（ＷＳ）およびＣｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを保持し、受信側のＲＬＣ‐ＡＭエンティティは、状態変数ＶＲ（Ｒ）、ＶＲ（ＭＲ）およびＣｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅを保持する必要がある。
【００２５】
状態変数ＶＴ（Ａ）は、順番どおりに確認応答を受信した最後のＡＭＤ‐ＰＤＵのＳＮの次のＳＮを表す。なお、状態変数ＶＴ（Ａ）の初期値は、ＳＮの初期値と同じ値である。状態変数ＶＴ（ＭＳ）は、受信側のＲＬＣ‐ＡＭエンティティで受信拒否されるＡＭＤ‐ＰＤＵの最小のＳＮを表す。状態変数ＶＴ（ＷＳ）は、送信ウィンドウサイズを表す。状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、送信ウィンドウサイズの初期値を表す。
【００２６】
なお、状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、上位エンティティからＲＬＣ‐ＡＭエンティティに通知される。そして、ＲＬＣ‐ＡＭエンティティは、状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅの値に状態変数ＶＴ（ＷＳ）を初期化する。その後、ＲＬＣ‐ＡＭエンティティは、ＷＮＳ‐ＳＵＦＩ（Window Size Super Field）信号を受信した場合、そのＷＮＳ‐ＳＵＦＩ信号の値に状態変数ＶＴ（ＷＳ）を更新する。
【００２７】
ここで、以下の式（１）が成り立つ。
ＶＴ（ＭＳ）＝ＶＴ（Ａ）＋ＶＴ（ＷＳ）・・・（１）
また、状態変数ＶＲ（Ｒ）は、順序通りに確認応答を送信した最後のＡＭＤ‐ＰＤＵのＳＮの次のＳＮを表す。なお、状態変数ＶＲ（Ｒ）の初期値は、ＳＮの初期値と同じ値である。状態変数ＶＲ（ＭＲ）は、ＲＬＣ‐ＡＭエンティティが受信拒否するＡＭＤ‐ＰＤＵの最小のＳＮを表す。状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、受信ウィンドウサイズを表す。なお、状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、上位エンティティからＲＬＣ‐ＡＭエンティティに通知される。
【００２８】
ここで、以下の式が成り立つ。
ＶＲ（ＭＲ）＝ＶＲ（Ｒ）＋Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ・・・（２）
送信側のＲＬＣ‐ＡＭエンティティは、ＶＴ（Ａ）≦ｘ＜ＶＴ（ＭＳ）を満たす整数ｘで表されるＳＮのそれぞれが付加されたＡＭＤ‐ＰＤＵを連続して送信する。また、受信側のＲＬＣ‐ＡＭエンティティは、ＶＲ（Ｒ）≦ｘ＜ＶＲ（ＭＲ）を満たす整数ｘで表されるＳＮのそれぞれが付加されたＡＭＤ‐ＰＤＵを受信する。
【００２９】
図６は、ウィンドウ制御の一例を示した説明図である。図６では、状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿ＳｉｚｅおよびＣｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅが共に５であるとする。また、状態変数ＶＴ（ＷＳ）の更新はないものとする。つまり、状態変数ＶＴ（ＷＳ）も５になる。また、ＳＮの初期値は、０であるとする。したがって、状態変数ＶＴ（Ａ）およびＶＲ（Ｒ）の初期値も０である。
【００３０】
先ず、送信側のＲＬＣ‐ＡＭエンティティは、値が０から４までのＳＮのそれぞれが付加されたＡＭＤ‐ＰＤＵを連続して送信する。
【００３１】
そして、受信側のＲＬＣ‐ＡＭエンティティは、ＡＭＤ‐ＰＤＵを受信すると、そのＡＭＤ‐ＰＤＵに付加されたＳＮに基づいて、状態変数ＶＲ（Ｒ）およびＶＲ（ＭＲ）を更新する。
【００３２】
今、受信側のＲＬＣ‐ＡＭエンティティは、ＳＮが３のＡＭＤ‐ＰＤＵを正常に受信することができかなったとする。
【００３３】
この場合、受信側のＲＬＣ‐ＡＭエンティティは、ＳＮが２までのＡＭＮ‐ＰＤＵを順序通りに受信したので、状態変数ＶＲ（Ｒ）を３にする。また、受信側のＲＬＣ‐ＡＭエンティティは、状態変数Ｖ（Ｒ）が３であり、状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅが５であるので、状態変数ＶＲ（ＭＲ）は、式（２）より８とする。
【００３４】
その後、受信側のＲＬＣ‐ＡＭエンティティは、確認応答を含むＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージを用いて、ＳＮが３のＡＭＤ‐ＰＤＵを正常に受信できなかった旨を送信側のＲＬＣ‐ＡＭエンティティに通知する。
【００３５】
送信側のＲＬＣ‐ＡＭエンティティは、その旨に基づいて、状態変数ＶＴ（Ａ）およびＶＴ（ＭＳ）を更新する。
【００３６】
今、送信側のＲＬＣ‐ＡＭエンティティは、ＳＮが２までのＡＭＤ‐ＰＤＵに対する確認応答を受信したので、状態変数ＶＴ（Ａ）を３にする。また、送信側のＲＬＣ‐ＡＭエンティティは、状態変数ＶＴ（Ａ）が３であり、状態変数ＶＴ（ＷＳ）が５であるので、状態変数ＶＴ（ＭＳ）は、式（１）より８となる。
【００３７】
そして、送信側のＲＬＣ‐ＡＭエンティティは、ＳＮが３から７までのＡＭＤ‐ＰＤＵを連続して送信する。
【００３８】
各ＲＬＣ‐ＡＭエンティティが上記のような動作を繰り返すことで、全てのＡＭＤ‐ＰＤＵが送信される。
【００３９】
また、ウィンドウ制御を行うためには、ＵＥおよびＲＮＣのそれぞれにおいて、送信ウィンドウサイズ分のＡＭＤ‐ＰＤＵと、受信ウィンドウサイズ分のＡＭＤ‐ＰＤＵとを一時的に記憶することが可能なＲＬＣ‐ＡＭ‐Ｂｕｆｆｅｒが必要となる。
【００４０】
次に、ウィンドウサイズの初期値の設定方法ついて説明する。
【００４１】
ＲＮＣは、ＵＥから、ＲＬＣ‐ＡＭエンティティ間の伝送で使用されるＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ（ＰＤＵサイズ）やＲＲＣ‐Ｃｏｎｎｅｃｔｉｏｎ‐Ｓｅｔｕｐ‐Ｃｏｍｐｌｅｔｅ（接続完了通知）メッセージなどが通知される。ＲＮＣは、その通知された情報に含まれるＴｏｔａｌ‐ＲＬＣ‐ＡＭ‐Ｂｕｆｆｅｒ‐Ｓｉｚｅ（全バッファサイズ）やＭａｘｉｍｕｍ‐ＲＬＣ‐ＡＭ‐Ｗｉｎｄｏｗ‐Ｓｉｚｅ（最大ウィンドウサイズ）に基づいて、ＲＬＣ‐ＡＭエンティティごとに、ＲＮＣの送信ウィンドウサイズおよび受信ウィンドウサイズの初期値を決定する。
【００４２】
ＲＮＣは、その決定した送信ウィンドウサイズの初期値を状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅとして保持し、その決定した受信ウィンドウサイズの初期値を状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅとして保持する。
【００４３】
また、ＲＮＣは、その送信ウィンドウサイズおよび受信ウィンドウサイズの初期値を、ＲＲＣ‐Ｒａｄｉｏ‐Ｂｅａｒｅｒ‐Ｓｅｔｕｐ（ＲＲＣ無線ベアラ設定要求完了）情報、ＲＲＣ‐Ｒａｄｉｏ‐Ｂｅａｒｅｒ‐Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＲＲＣ無線ベアラ再設定要求）情報やＣｅｌｌ‐Ｕｐｄａｔｅ‐Ｃｏｎｆｉｒｍ（セル位置の更新確認）メッセージなどを用いてＵＥに通知する。
【００４４】
ＵＥは、その通知されたＲＮＣの送信ウィンドウサイズの初期値を、ＵＥの受信ウィンドウサイズの初期値を表す状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅとして保持し、その通知されたＲＮＣの受信ウィンドウサイズの初期値を、ＵＥの送信ウィンドウサイズの初期値を表す状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅとして保持する。
【００４５】
このため、ＵＥの送信ウィンドウサイズとＲＮＣの受信ウィンドウサイズが同じ値になり、同様にＵＥの受信ウィンドウサイズとＲＮＣの送信ウィンドウサイズが同じ値になる。
【００４６】
ＲＬＣ‐ＡＭエンティティ間でのウィンドウサイズの更新方法は、非特許文献１に記載されている。
【００４７】
具体的には、受信側のＲＬＣ‐ＡＭエンティティが、ＷＮＳ‐ＳＵＦＩ信号を含むＳＴＡＴＵＳ‐ＰＤＵを送信側のＲＬＣ‐ＡＭエンティティに送信し、送信側のＲＬＣ‐ＡＭエンティティは、送信ウィンドウサイズを示す状態変数ＶＴ（ＭＳ）を、そのＷＮＳ‐ＳＵＦＩ信号の値に更新する。そして、送信側のＲＬＣ‐ＡＭエンティティは、その更新した状態変数ＶＴ（ＭＳ）の値を受信側のＲＬＣ‐ＡＭエンティティに通知する。
【００４８】
つまり、ＲＬＣ‐ＡＭエンティティ間では、ＷＮＳ‐ＳＵＦＩ信号の値を調整することで、送信ウィンドウサイズを調整することが可能になる。
【００４９】
なお、ＲＬＣ‐ＡＭエンティティ間で、受信側の受信ウィンドウサイズを調整する方法については、定義されていない。
【００５０】
特許文献２に記載のパケット通信装置では、無線回線の回線状態に応じてＷＮＳ‐ＳＵＦＩ信号の値を調整することで、ＡＭＤ‐ＰＤＵの送信元の送信ウィンドウサイズを調整している。
【００５１】
通常、送信ウィンドウサイズを大きくすれば、応答確認の受信なしで連続して送信可能なＡＭＤ‐ＰＤＵの数が増えるので、伝送スループットが向上する。
【００５２】
しかしながら、送信ウィンドウサイズが大きいと、特に回線状態が悪い場合では、ＡＭＤ‐ＰＤＵがバッファに記憶されている時間が長くなる。
【００５３】
ＡＭＤ‐ＰＤＵの再送は、送信ウィンドウサイズ分のＡＭＤ‐ＰＤＵの送信が終了した後で行われるため、ＡＭＤ‐ＰＤＵがバッファに記憶されている時間が長くなると、ＡＭＤ‐ＰＤＵを送信してからそのＡＭＤ‐ＰＤＵを再送するまでの時間が長くなる。
【００５４】
ＡＭＤ‐ＰＤＵを再送するまでの時間が長くなると、受信側のＲＬＣ‐ＡＭエンティティが所定のタイミングごとに確認応答を送信するので、そのＡＭＤ‐ＰＤＵが正常に到達していない旨を何度も送信側に送信して再送が増えることがある。再送が増えると、通常、単位時間当たりに送信されるデータ量が少なくなるように制御され、伝送スループットが低下する。したがって、送信ウィンドウサイズが大きいと、かえって、伝送スループットが低下することがある。
【００５５】
特許文献２に記載のパケット通信装置では、回線状態が良くなると、送信元の送信ウィンドウサイズを大きくし、回線状態が悪くなると、送信元の送信ウィンドウサイズを小さくしている。このため、ＡＭＤ‐ＰＤＵの再送を軽減することが可能になり、伝送スループットを向上させることが可能になる。
【特許文献１】特開２００２‐２６９９１号公報
【特許文献２】特許２００５‐４５６４２号公報
【非特許文献１】３ＧＰＰ ＴＳ２５．３２２（ＲＬＣ）
【発明の開示】
【発明が解決しようとする課題】
【００５６】
上述のように、ウィンドウ制御を行うためには、ＲＬＣ‐ＡＭ‐Ｂｕｆｆｅｒが必要となる。ここで、複数のＲＬＣ‐ＡＭエンティティが、同一のＲＬＣ‐ＡＭ‐Ｂｕｆｆｅｒを使用する。さらに、ＨＳＤＰＡ(High Speed Downlink Packet Access)にて使用されるＭＡＣ‐ｈｓ‐Ｒｅｏｒｄｅｒｉｎｇ‐Ｂｕｆｆｅｒは、ＲＬＣ‐ＡＭ‐Ｂｕｆｆｅｒと兼用される。
【００５７】
このため、あるＲＬＣ‐ＡＭエンティティがＲＬＣ‐ＡＭ‐Ｂｕｆｆｅｒ（以下、バッファと称する）の領域を全て専用すると、他のＲＬＣ‐ＡＭエンティティなどが伝送できなくなる。これを防止するために、各ＲＬＣ‐ＡＭエンティティが使用可能なバッファサイズ（Ｂｕｆｆｅｒ‐Ｓｉｚｅ）は、予め割り当てられている。以下、この割り当てられたバッファサイズを個別ＲＬＣ‐ＡＭバッファサイズと称する。
【００５８】
また、ＲＬＣ‐ＡＭエンティティは、ウィンドウ制御を行うためには、送信ウィンドウサイズ分のＡＭＤ‐ＰＤＵと、受信ウィンドウサイズ分のＡＭＤ‐ＰＤＵとを記憶することが可能な必要バッファサイズ以上のバッファサイズが必要となる。
【００５９】
ＵＥのＲＬＣ‐ＡＭエンティティに対する必要バッファサイズは、式（３）で表すことができ、ＲＮＣのＲＬＣ‐ＡＭエンティティのあるＡＭエンティティに対する必要バッファサイズは、式（４）で表すことができる。
ＵＥのＲＬＣ‐ＡＭエンティティの必要バッファサイズ＝（ＵＬ‐ＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ×ＵＥの送信ウィンドウサイズ）＋（ＤＬ‐ＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ×ＵＥの受信ウィンドウサイズ）・・・（３）
ＲＮＣのＲＬＣ‐ＡＭエンティティの必要バッファサイズ＝（ＤＬ‐ＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ×ＲＮＣの送信ウィンドウサイズ）＋（ＵＬ‐ＲＬＣ‐ＰＤＵ‐Ｓｉｚｅ×ＲＮＣの受信ウィンドウサイズ）・・・（４）
したがって、個別ＲＬＣ‐ＡＭバッファサイズは、式（３）および式（４）において、受信ウィンドウサイズおよび送信ウィンドウサイズを共に初期値としたときの必要バッファサイズ以上でなければならない。
【００６０】
また、個別ＲＬＣ‐ＡＭバッファサイズが割り当てられた後で送信ウィンドウサイズが調整される場合、送信ウィンドウサイズは、必要バッファサイズが個別ＲＬＣ‐ＡＭバッファサイズを超えない範囲で調整される必要がある。
【００６１】
式（３）および（４）から分かるように、受信ウィンドウサイズが大きいほど、送信ウィンドウサイズの最大値は小さくなる。したがって、受信ウィンドウサイズが大きいと、送信ウィンドウサイズを最大値にしても、十分な伝送スループットを得ることができない場合があるという問題がある。
【００６２】
特に、伝送方向ごとの伝送トラフィックに大きな差が生じている場合、送信されるＡＭＤ‐ＰＤＵによるバッファの使用率と、受信したＡＭＤ‐ＰＤＵによるバッファの使用率とに大きな差が生じる。このとき、送信されるＡＭＤ‐ＰＤＵによるバッファの使用率が大きく、受信したＡＭＤ‐ＰＤＵによるバッファの使用率が小さい場合、受信ウィンドウサイズが大きいと、伝送トラフィックが大きい方向に対して十分な伝送スループットを得ることができない。
【００６３】
非特許文献１に記載の更新方法および特許文献２に記載のパケット通信装置では、送信側の送信ウィンドウサイズは調整されているが、送信側の受信ウィンドウサイズは調整されていないので、この問題を解決することができない。
【００６４】
本発明の目的は、上記の課題である、十分な伝送スループットを得ることができないという問題を解決する通信装置、通信システム、ウィンドウサイズ調整方法およびプログラムを提供することである。
【課題を解決するための手段】
【００６５】
本発明による通信装置は、通信相手となる通信装置とウィンドウ制御で伝送可能な通信装置であって、前記通信相手となる通信装置に送信する送信データユニットと、前記通信相手となる通信装置から受信した受信データユニットと、を一時的に記憶する記憶手段と、前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定する測定手段と、前記測定手段にて測定された送信使用率および受信使用率に基づいて、前記通信装置となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットの量との合計が予め定められたデータ量を超えない範囲で調整する調整手段と、を含む。
【００６６】
本発明による通信システムは、ウィンドウ制御で伝送可能な複数の通信装置を含む通信システムであって、各通信装置は、通信相手となる通信装置に送信する送信データユニットと、前記通信相手となる通信装置から受信した受信データユニットと、を一時的に記憶する記憶手段と、前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定する測定手段と、前記測定手段にて測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットと、前記受信ウィンドウサイズ分の前記送信データユニットとの合計が予め定められたデータ量を超えない範囲で調整する調整手段と、を含む。
【００６７】
本発明による第一のウィンドウサイズ調整方法は、通信相手となる通信装置に送信する送信データユニットと前記通信相手となる通信装置から受信した受信データユニットとを一時的に記憶する記憶手段を含み、前記通信相手となる通信装置とウィンドウ制御で伝送可能な通信装置によるウィンドウサイズ調整方法であって、前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定し、前記測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットの量との合計が予め定められたデータ量を超えない範囲で調整する。
【００６８】
本発明による第二のウィンドウサイズ調整方法は、互いにウィンドウ制御で伝送可能な複数の通信装置を含み、各通信装置が通信相手となる通信装置に送信する送信データユニットと前記通信相手となる通信装置から受信した受信データユニットとを一時的に記憶する記憶手段を含む、通信システムによるウィンドウサイズ調整方法であって、各通信装置が、前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定し、各通信装置が、前記測定された送信使用率および受信使用率に基づいて、前記通信相手となる通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットの量との合計が予め定められたデータ量を超えない範囲で調整する。
【００６９】
本発明によるプログラムは、通信装置と、前記通信装置に送信する送信データユニットと前記通信装置から受信した受信データユニットとを一時的に記憶する記憶手段と、に接続されたコンピュータに、前記記憶手段の前記送信データユニットによる送信使用率と、前記記憶手段の前記受信データユニットによる受信使用率とを測定する手順と、前記測定された送信使用率および受信使用率に基づいて、前記通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを、前記送信ウィンドウサイズ分の前記受信データユニットの量と、前記受信ウィンドウサイズ分の前記送信データユニットとの量の合計が予め定められたデータ量を超えない範囲で調整する手順と、を実行させる。
【発明の効果】
【００７０】
本発明によれば、十分な伝送スループットを得ることが可能になる。
【発明を実施するための最良の形態】
【００７１】
以下、本発明の実施形態について図面を参照して説明する。
【００７２】
図１は、本発明の一実施形態の無線通信システムを示したブロック図である。図１において、無線通信システムは、ＵＥ１と、ＲＡＮ２とを含む。ＲＡＮ２は、ＮｏｄｅＢとＲＮＣとが一体になっているものでもよいし、ＮｏｄｅＢとＲＮＣが別体になっているものでもよい。
【００７３】
ＵＥ１は、ＲＡＮ２の通信相手となる通信装置であり、ＲＡＮ２は、ＵＥ１の通信相手となる通信装置である。また、ＵＥ１およびＲＡＮ２のそれぞれは、互いにウィンドウ制御で伝送可能である。
【００７４】
ＵＥ１は、通信部１１と、バッファ１２と、複数のＲＬＣ部１３とを含む。また、ＲＬＣ部１３のそれぞれは、保持部１４と、通信制御部１５と、測定部１６と、調整部１７とを含む。なお、同一のＲＬＣ部１３に含まれる保持部１４、通信制御部１５、測定部１６および調整部１７のそれぞれは、互いに対応付けられている。
【００７５】
また、ＲＡＮ２は、通信部２１と、バッファ２２と、複数のＲＬＣ部２３とを含む。ＲＬＣ部のそれぞれ２３は、保持部２４と、測定部２６と、調整部２７とを含む。
【００７６】
通信部１１は、ＰＨＹエンティティおよびＭＡＣエンティティで構成される。
【００７７】
バッファ１２は、記憶手段の一例である。バッファ１２は、ＵＥ１がＲＡＮ２に送信する送信データユニット（Protocol Data Unit）と、ＵＥ１がＲＡＮ２から受信した受信データユニットとを一時的に記憶する。以下、送信データユニットおよび受信データユニットをデータユニットと総称することもある。
【００７８】
ＲＬＣ部１３のそれぞれは、ＲＬＣエンティティで構成され、ＡＭモードで動作する。また、ＲＬＣ部１３のそれぞれには、無線ベアラが割り当てられている。
【００７９】
また、ＵＥ１のＲＬＣ部１３のそれぞれは、ＲＡＮ２のＲＬＣ部２３のいずれか一つと対向し、ウィンドウ制御でその対向するＲＬＣ部（以下、対向ＲＬＣ部と称する）と、その割り当てられた無線ベアラのデータユニットの伝送を行う。
【００８０】
また、ＲＬＣ部１３のそれぞれには、そのＲＬＣ部１３が伝送を行うデータユニットを記憶するためのバッファ１２のサイズとして、個別ＲＬＣ‐ＡＭバッファサイズが割り当てられている。
【００８１】
ここで、個別ＲＬＣ‐ＡＭバッファサイズは、（バッファ１２に記憶される送信データユニットのサイズ×ＵＥ１の送信ウィンドウサイズの初期値）＋（バッファ１２に記憶される受信データユニットのサイズ×ＵＥ１の受信ウィンドウサイズの初期値）で表される初期必要バッファサイズ以上であればよい。なお、初期必要バッファサイズは、（バッファ２２に記憶される送信データユニットのサイズ×ＲＡＮ２の送信ウィンドウサイズの初期値）＋（バッファ２２に記憶される受信データユニットのサイズ×ＲＡＮ２の受信ウィンドウサイズの初期値）とも表すことができる。
【００８２】
以下では、個別ＲＬＣ‐ＡＭバッファサイズは、その初期必要バファサイズと同じであるとする。また、送信データユニットおよび受信データユニットのサイズは、互いに等しいとする。
【００８３】
保持部１４は、ウィンドウ制御を行うため状態変数ＶＴ（Ａ）、ＶＴ（ＭＳ）、ＶＴ（ＷＳ）、Ｖ（Ｒ）、ＶＲ（ＭＲ）およびＶＲ（ＷＳ）を保持する。
【００８４】
状態変数ＶＴ（Ａ）は、順番どおりに確認応答を受信した最後の送信データユニットのＳＮ（シーケンス番号）の次のＳＮを表す。状態変数ＶＴ（ＭＳ）は、ＲＡＮ２で受信拒否される送信データユニットの最小のＳＮを表す。状態変数ＶＴ（ＷＳ）は、送信ウィンドウサイズを表す。
【００８５】
また、状態変数ＶＲ（Ｒ）は、順序通りに確認応答を送信した最後の受信データユニットのＳＮの次のＳＮを表す。状態変数ＶＲ（ＭＲ）は、受信拒否する受信データユニットの最小のＳＮを表す。状態変数ＶＲ（ＷＳ）は、受信ウィンドウサイズを表す。
【００８６】
なお、状態変数ＶＲ（ＷＳ）は、上位エンティティ（図示せず）から通知される状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｔｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅで初期化され、状態変数ＶＴ（ＷＳ）は、上位エンティティから通知される状態変数Ｃｏｎｆｉｇｕｒｅｄ＿Ｒｘ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅで初期化される。
【００８７】
通信制御部１５は、保持部１４に保持されている状態変数を用いて、ウィンドウ制御でＲＡＮ２とデータユニットの伝送を行う。なお、通信制御部１５が行う処理は、当業者にとっては自明であるため、詳細な説明は省略する。
【００８８】
測定部１６は、自己（測定部１６）に対応する通信制御部１５が伝送する送信データユニットによるバッファ１２の使用率と、その通信制御部１５が伝送する受信データユニットによるバッファ１２の使用率とを測定する。
【００８９】
以下、送信データユニットによるバッファ１２の使用率を、送信バッファ使用率と称し、
受信データユニットによるバッファ１２の使用率を、受信バッファ使用率と称する。なお、送信バッファ使用率は、送信使用率の一例であり、受信バッファ使用率は、受信使用率の一例である。
【００９０】
調整部１７は、測定部１６が測定した送信バッファ使用率および受信バッファ使用率に基づいて、ＲＡＮ２（具体的には、自身（調整部１７）を含むＲＬＣ部１３の対向ＲＬＣ部）の送信ウィンドウサイズおよび受信ウィンドウサイズを調整する。
【００９１】
このとき、調整部１７は、そのＲＡＮ２の送信ウィンドウサイズ分の受信データユニット（ＤＬ方向に伝送されるデータユニット）の量と、ＲＡＮ２の受信ウィンドウサイズ分の送信データユニット（ＵＬ方向に伝送されるデータユニットのサイズ）の量との合計が予め定められた上限データ量を超えない範囲で、ＲＡＮ２の送信ウィンドウサイズおよび受信ウィンドウサイズを調整する。
【００９２】
ここで、上限データ量は、個別ＲＬＣ‐ＡＭバッファサイズに記憶することが可能な最大のデータ量として定められているものとする。そして、調整部１７は、ＲＡＮ２の送信ウィンドウサイズおよび受信ウィンドウサイズを、ＲＡＮ２の送信ウィンドウサイズ分の受信データユニットと、ＲＡＮ２の受信ウィンドウサイズ分の送信データユニットと、を記憶することが可能な必要バッファサイズが、個別ＲＬＣ‐ＡＭバッファサイズを超えない範囲で調整することで、ＲＡＮ２の送信ウィンドウサイズおよび受信ウィンドウサイズを、その合計が上限データ量を超えない範囲で調整している。
【００９３】
ここで、必要バッファサイズは、（バッファ１２に記憶されている受信データユニットのサイズ×ＲＡＮ２の送信ウィンドウサイズ）＋（バッファ１２に記憶されている送信データユニットのサイズ×ＲＡＮ２の受信ウィンドウサイズ）で表される。なお、バッファ１２に記憶されている受信データユニットのサイズは、バッファ２２に記憶されている送信データユニットのサイズと同じであり、バッファ１２に記憶されている送信データユニットのサイズは、バッファ２２に記憶されている受信データユニットのサイズと同じである。
【００９４】
具体的には、調整部１７は、以下のようにウィンドウサイズを調整する。
【００９５】
先ず、調整部１７は、送信バッファ使用率が予め定められた基準値以上か否かを判断する。
【００９６】
そして、送信バッファ使用率が基準値以上であると、調整部１７は、送信バッファ使用率および受信バッファ使用率の差分値を算出し、その差分値に基づいて、送信ウィンドウサイズおよび受信ウィンドウサイズを調整する。
【００９７】
さらに具体的には、送信バッファ使用率が基準値以上であると、調整部１７は、送信バッファ使用率から受信バッファ使用率を引いた値を差分値として算出し、その算出した差分値が予め定められた所定値以上か否かを判断する。調整部１７は、差分値が所定値以上であると、ＲＡＮ２の受信ウィンドウサイズを上げ、かつ、ＲＡＮ２の送信ウィンドウサイズを下げる。
【００９８】
また、調整部１７は、ＲＡＮ２の受信ウィンドウサイズおよび送信ウィンドウサイズの調整には、ＷＮＳ‐ＳＵＦＩ信号を含むＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージをＲＡＮ２に通知することで行う。
【００９９】
さらに、調整部１７は、ＲＡＮ２の受信ウィンドウサイズおよび送信ウィンドウサイズを調整すると、その調整結果に応じて、保持部１４が保持している、ＵＥ１の受信ウィンドウサイズである状態変数ＶＲ（ＷＳ）と、ＵＥ１の送信ウィンドウサイズである状態変数ＶＴ（ＷＳ）を調整する。
【０１００】
具体的には、調整部１７は、ＲＡＮ２の受信ウィンドウサイズを上げ、かつ、ＲＡＮ２の送信ウィンドウサイズを下げると、ＵＥ１の受信ウィンドウサイズである状態変数ＶＲ（ＷＳ）を下げ、ＵＥ１の送信ウィンドウサイズである状態変数ＶＴ（ＷＳ）を上げる。
【０１０１】
ここで、ＲＡＮ２の通信部２１、バッファ２２、ＲＡＮ部２３、保持部２４、測定部２６および調整部２７のそれぞれの機能は、ＵＥ１の通信部１１、バッファ１２、ＲＡＮ部１３、保持部１４、測定部１６および調整部１７のそれぞれの機能において、ＵＥ１とＲＡＮ２を交換し、ＵＬ方向とＤＬ方向を交換すれば良いため、詳細な説明は省略する。
【０１０２】
次に、動作を説明する。
【０１０３】
以下では、ＵＥ１がウィンドウサイズを調整するときの動作について説明する。図２は、このときのＵＥ１の動作を説明するためのフローチャートであり、図３は、このときのＲＡＮ２の動作を説明するためのフローチャートである。図４は、バッファサイズの変移を示した説明図である。
【０１０４】
ＵＥ１の保持部１４は、状態変数ＶＲ（ＷＳ）として、値がａの状態変数ＶＲ（ＷＳ）１２０を保持し、状態変数ＶＴ（ＷＳ）として、値がｂの状態変数ＶＴ（ＷＳ）１１０を保持する。また、ＲＡＮ２の保持部２４は、状態変数ＶＲ（ＷＳ）として、値がｂの状態変数ＶＲ（ＷＳ）１４０を保持し、状態変数ＶＴ（ＷＳ）として、値がａの状態変数ＶＴ（ＷＳ）１３０を保持するものとする。
【０１０５】
図２のステップＳ２１では、測定部１６は、定期的にバッファ１２にアクセスして、バッファ１２の送信バッファ使用率および受信バッファ使用率を測定する。
【０１０６】
例えば、測定部１６は、バッファ１２に記憶されている、自身（測定部１６）を含むＲＬＣ部１３が再送制御および順序制御を行う送信データユニットおよび受信データユニットのそれぞれが使用しているバッファサイズのそれぞれを測定する。測定部１６は、各バッファサイズをそのＲＬＣ部１３に割り当てられた個別ＲＬＣ‐ＡＭバッファサイズで除算して、送信バッファ使用率および受信バッファ使用率を測定する。なお、測定部１６は、自身（測定部１６）を含むＲＬＣ部１３に割り当てられた個別ＲＬＣ‐ＡＭバッファサイズを予め保持している。
【０１０７】
測定部１６は、送信バッファ使用率および受信バッファ使用率を測定すると、その送信バッファ使用率および受信バッファ使用率を調整部１７に送信する。
【０１０８】
調整部１７は、送信バッファ使用率および受信バッファ使用率を受信すると、その送信バッファ使用率が基準値以上か否かを判断する。調整部１７は、送信バッファ使用率が基準値以上であると、ステップＳ２２を実行し、送信バッファ使用率が基準値未満であると、ステップＳ２１を実行する。
【０１０９】
ステップＳ２２では、調整部１７は、送信バッファ使用率から受信バッファ使用率を比いて差分値を求め、その差分値が所定値以上か否かを判断する。調整部１７は、差分値が所定値以上であると、ステップＳ２３を実行し、差分値が所定値未満であると、ステップＳ２１を実行する。
【０１１０】
ステップＳ２３では、調整部１７は、保持部１４から、受信ウィンドウサイズである状態変数ＶＲ（ＷＳ）１２０を取得する。調整部１７は、その状態変数ＶＲ（ＷＳ）１２０の値「ａ」の次に小さい整数値「ｃ」を求め、その整数値「ｃ」を示すＷＮＳ‐ＳＵＦＩ信号を生成する。調整部１７は、そのＷＮＳ‐ＳＵＦＩ信号を含むＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１５０を生成し、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１５０を、通信部１１を経由してＲＡＮ２の通信部２１に送信する。その後、図３のステップＳ３１が実行される。
【０１１１】
ステップＳ３１では、通信部２１は、ステップＳ２３で送信されたＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１５０を受信すると、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１５０を調整部２７に送信する。調整部２７は、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１５０を受信すると、ステップＳ３２を実行する。
【０１１２】
ステップＳ３２では、調整部２７は、保持部２４が保持しているＲＡＮ２の送信ウィンドウサイズである状態変数ＶＴ（ＷＳ）１３０の値「ａ」を、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージに１５０含まれるＷＮＳ‐ＳＵＦＩ信号が示す値「ｃ」に更新する。調整部２７は、ステップＳ３２を終了すると、ステップＳ３３を実行する。
【０１１３】
ステップＳ３３では、調整部２７は、必要バッファサイズが個別ＲＬＣ‐ＡＭバッファサイズを超えない範囲で最大となるときの、状態変数ＶＲ（ＷＳ）１４０の値「ｄ」を決定する。なお、値「ｄ」は、整数値である。
【０１１４】
例えば、調整部２７は、式（５）で計算される値を超えない最大の整数値を、整数値「ｄ」として決定する。なお、調整部２７は、式（５）を計算するために必要な（個別ＲＬＣ‐ＡＭバッファサイズ）、（ＤＬ方向に伝送されるデータユニットのサイズ）および（ＤＬ方向に伝送されるデータユニットのサイズ）を予め保持しているものとする。
｛（個別ＲＬＣ‐ＡＭバッファサイズ）‐（ＤＬ方向に伝送されるデータユニットのサイズ）×状態変数ＶＴ（ＷＳ）｝／（ＤＬ方向に伝送されるデータユニットのサイズ）・・・（５）
調整部２７は、状態変数ＶＲ（ＷＳ）１４０の値「ｄ」を決定すると、保持部２４が保持しているＲＡＮ２の受信ウィンドウサイズである状態変数ＶＲ（ＷＳ）１４０の値「ｂ」を、その決定した値「ｄ」に更新する。調整部２７は、ステップＳ３３を終了すると、ステップＳ３４を実行する。
【０１１５】
ステップＳ３４では、調整部２７は、その決定した値「ｄ」を示すＷＮＳ‐ＳＵＦＩ信号を生成する。調整部２７は、そのＷＮＳ‐ＳＵＦＩ信号を含むＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１６０を生成し、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１６０を、通信部２１を経由してＵＥ１の通信部１１に送信する。その後、図２のステップＳ２４が実行される。
【０１１６】
ステップＳ２４では、通信部１１は、ステップＳ３４で送信されたＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１６０を受信すると、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１６０を調整部１７に送信する。調整部１７は、ＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１６０を受信すると、ステップＳ２５を実行する。
【０１１７】
ステップＳ２５では、調整部１７は、保持部１４が保持しているＵＥ１の受信ウィンドウサイズである状態変数ＶＲ（ＷＳ）１２０の値「ａ」を、ステップＳ２３で送信したＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１５０に含まれるＷＮＳ‐ＳＵＦＩ信号が示す値「ｃ」に更新する。調整部１７は、ステップＳ２５を終了すると、ステップＳ２６を実行する。
【０１１８】
ステップＳ２６では、調整部１７は、保持部１４が保持しているＵＥ１の送信ウィンドウサイズである状態変数ＶＴ（ＷＳ）１１０の値「ｂ」を、ステップＳ２４で受信したＲＬＣ‐ＳＴＡＴＵＳ‐ＰＤＵメッセージ１６０に含まれるＷＮＳ‐ＳＵＦＩ信号が示す整数「ｄ」に更新する。調整部１７は、ステップＳ２６を終了すると、ステップＳ２１を実行する。
【０１１９】
以上の動作が繰り返されることで、ＵＥ１の送信ウィンドウサイズが増加していく。
【０１２０】
なお、ＲＡＮ２がウィンドウサイズを調整するときの動作は、ＵＥ１がウィンドウサイズを調整するときの動作において、ＵＥ１およびＲＡＮ２を交換し、ＵＬ方向およびＤＬ方向を交換すれば良いため、詳細な説明は省略する。
【０１２１】
次に効果を説明する。
【０１２２】
本実施形態では、測定部１６は、送信データユニットによるバッファ１２の使用率である送信バッファ使用率と、受信データユニットによるバッファ１２の使用率である受信バッファ使用率とを測定する。調整部１７は、その送信バッファ使用率および受信バッファ使用率に基づいて、ＲＡＮ２の送信ウィンドウサイズおよび受信ウィンドウサイズを、ＲＡＮ１の送信ウィンドウサイズ分の受信データユニットの量と、ＲＡＮ２の受信ウィンドウサイズ分の送信データユニットの量の合計と、予め定められた上限データ量を超えない範囲で調整する。また、その受信データユニットの量と送信データユニットの量との合計は、ＲＡＮ２の送信ウィンドウサイズ分の受信データユニットおよびＲＡＮ２の受信ウィンドウサイズ分の送信データユニットを記憶することが可能な必要バッファサイズを表し、上限データ量は、個別ＲＬＣ‐ＡＭバッファサイズを表す。
【０１２３】
この場合、対向する通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズが、必要バッファサイズが個別ＲＬＣ‐ＡＭバッファサイズを超えない範囲で、送信バッファ使用率および受信バッファ使用率に基づいて調整される。
【０１２４】
よって、送信ウィンドウサイズだけでなく、受信ウィンドウサイズも調整されるので、個別ＲＬＣ‐ＡＭバッファサイズを超えない範囲で送信ウィンドウサイズの最大値をより大きくすることが可能になる。したがって、十分な伝送スループットを得ることが可能になる。
【０１２５】
また、本実施形態では、調整部１７は、送信バッファ使用率および受信バッファ使用率の差分値を算出し、その差分値に基づいて対向する通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズを調整する。また、差分値は、伝送方向ごとの伝送トラフィックの差を反映する。
【０１２６】
この場合、対向する通信装置の送信ウィンドウサイズおよび受信ウィンドウサイズが、伝送方向ごとに伝送トラフィックの差に基づいて調整される。したがって、伝送トラフィックが大きい方向に対して十分な伝送スループットを得ることが可能になる。
【０１２７】
また、本実施形態では、調整部１７は、送信バッファ使用率から受信バッファ使用率を引いた差分値が所定値以上か否かを判断する。また、調整部１７は、その差分値が所定値以上であると、対向する通信装置の送信ウィンドウサイズを上げ、かつ、対向する通信装置の受信ウィンドウサイズを下げる。
【０１２８】
この場合、伝送トラフィックが大きい伝送方向に伝送されるデータユニットの送信ウィンドウサイズを大きくすることが可能になるので、システム全体の伝送スループットを向上させることが可能になる。
【０１２９】
また、本実施形態では、調整部１７は、送信バッファ使用率が基準値以上か否かを判断する。調整部１７は、送信バッファ使用率が基準値以上であると、差分値が所定値以上か否かを判断する。また、送信バッファ使用率は、送信方向の通信トラフィックを反映する。
【０１３０】
この場合、通信トラフィックが少なく、ウィンドウサイズを調整しなくても、十分な伝送スループットが得られる場合にウィンドウサイズを変更しなくてもよくなるため、過度なウィンドウサイズの調整を抑制することが可能になる。
【０１３１】
なお、以上説明したＵＥ１およびＲＡＮ２のそれぞれ機能は、その機能を実現するためのプログラムを、コンピュータにて読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行するものであってもよい。コンピュータにて読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ‐ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記録装置を指す。さらに、コンピュータにて読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間、動的にプログラムを保持するもの（伝送媒体または伝送波）、その場合のサーバとなるコンピュータ内の揮発性メモリのように、一定期間プログラムを保持しているものを含む。
【０１３２】
以上説明した実施形態において、図示した構成は単なる一例であって、本発明はその構成に限定されるものではない。
【図面の簡単な説明】
【０１３３】
【図１】本発明の第一の実施形態の無線通信システムを示したブロック図である。
【図２】ＵＥの動作例を説明するためのフローチャート
【図３】ＲＮＣの動作例を説明するためのフローチャートである。
【図４】バッファサイズの変移を示した説明図である。
【図５】ＵＴＲＡＮの無線プロトコルの構成を示した概略図である。
【図６】ウィンドウ制御の一例を示した説明図である。
【符号の説明】
【０１３４】
１          ＵＥ
２          ＲＡＮ
１１、２１  通信部
１２、２２  バッファ
１３、２３  ＲＬＣ部
１４、２４  保持部
１５、２５  通信制御部
１６、２６  測定部
１７、２７  調整部
【図１】
2009224834.tif 000003
【図２】
2009224834.tif 000004
【図３】
2009224834.tif 000005
【図４】
2009224834.tif 000006
【図５】
2009224834.tif 000007
【図６】
2009224834.tif 000008