JPWO2008032750A1 - 通信装置 - Google Patents

Abstract

ネットワーク環境に依存することなく、通信品質と省電力効果のさらなる向上を両立して図った通信装置を提供する。通信装置たる携帯型端末（２１１）は、ＴＣＰなどのフロー制御付きの通信プロトコル上で送信側装置（２０３）に対してデータの送受信を行う通信Ｉ／Ｆ部（１０８）と、通信Ｉ／Ｆ部（１０８）への電源の投入と切断とを切り換える電源制御部（１０６）と、通信アプリケーションプログラムの必要とする通信品質に応じて、サイクル間隔ＴｃとサイクルデータサイズＤｃとを決定し、上述のフロー制御の仕組みを利用して、サイクル間隔Ｔｃごとに、サイクルデータサイズＤｃ分のデータをバースト的に送信させるとともに送信側装置（２０３）からのデータ送信を抑制させ、データの送信が抑制された期間（時刻Ｔ２〜Ｔ３）に、電源制御部（１０６）に対して、通信Ｉ／Ｆ部（１０８）の電源を切断せる抑制再開制御部（１０４）とを備える。

Description

本発明は、通信装置に関し、特に、省電力を目的とした通信装置および通信システム、ならびに省電力方法に関する。

近年、インターネットを中心としたＩＰ（Internet Protocol）ネットワークが急速に拡大している。つまり、ＰＣ（Personal Computer）だけでなく、テレビやＤＶＤ（Digital Versatile Disk）プレーヤーなどの据え置き型の家電機器におけるＩＰネットワークの利用が普及し始めるとともに、携帯電話やＰＤＡ（Personal Digital Assistants）、デジタルカメラなどの携帯型端末におけるＩＰネットワークの利用も普及し始めている。このようにインターネットなどのネットワークに接続可能な機器を通信装置と呼ぶ。

ＩＰネットワークを利用したサービスでは、音楽データや動画データのダウンロードやアップロード、さらには音声などのストリーミングデータの送受信などが行われ、長時間の通信を行うことがある。そのため、ＩＰネットワークを利用するための消費電力を軽視することができない状況となっている。通信装置を構成するデバイスの中でも、ＩＰネットワークを利用するためのネットワーク接続デバイスが特に多くの電力を必要としている。

ネットワーク接続デバイスには、有線によりＩＰネットワークを利用するデバイスと、無線によりＩＰネットワークを利用するデバイスとが存在する。消費電力を低減させるための省電力技術は、上述のような無線や有線を問わず、さまざまな機器に対して検討されている。その中でも携帯型端末では、内蔵のバッテリーのみで長時間使用するような使い方が想定されるため、省電力技術を特に必要としている。したがって、以下では、携帯型端末における省電力技術の例を説明する。

携帯型端末のネットワーク接続デバイスとしては、無線ＬＡＮ（Local Area Network）デバイスの利用が注目されている。無線ＬＡＮデバイスは比較的大きな電力を消費するので、その省電力化は重要な検討課題であり、多くの省電力化の手法が提案されている。

無線ＬＡＮの標準規格であるＩＥＥＥ８０２．１１では、無線端末の省電力化の方法として、パワーマネージメントのモード（パワーセーブモード）が規定されている。この方法では、無線端末は、パワーセーブモードで動作している場合、無線基地局（アクセスポイント）からビーコンが送信されるタイミングに合わせて受信動作を行ない、それ以外の間は受信動作を行なわない状態（ドーズモード）に入る。無線端末は、ドーズモードにおいて、その無線端末に備えられた無線ＬＡＮデバイスの電力供給を停止することにより、無線端末の消費電力を低減することができる。

図１は、パワーセーブモードでの無線端末の動作を説明するための説明図である。

無線端末は、送信側装置から送信されたデータを、アクセスポイント（ＡＰ）を介して受信する。このとき、無線端末は、アクセスポイントからビーコン（図１中の「Ｂ」のタイミングで送信される信号）が送信されるたびに、または複数のビーコンの送信に１回のタイミングで、受信状態（電源が投入された状態）に入り、そのビーコンを受信する。ここでは、この無線端末がビーコンを受信する一定の間隔を、「スリープ間隔」と呼ぶ。スリープ間隔は、無線端末とアクセスポイントの間の接続シーケンスなどによって、無線端末から設定または変更される。

また、図１に示すように、ドーズモードの期間中に無線端末宛に送信されたパケットは、一旦アクセスポイントでバッファリングされる。無線端末が次にビーコンを受信したときには、無線端末は、自分宛のパケットが届いていることが通知されるので、アクセスポイントに対してＰＳ−Ｐｏｌｌ（Ｐｏｗｅｒ Ｓａｖｅ Ｐｏｌｌ）パケットを送信する。ＰＳ−Ｐｏｌｌパケットを受信したアクセスポイントは、その無線端末宛のパケットをまとめて送信するので、ドーズモードの期間に送信されたパケットは正しく無線端末に受信される。

しかしながら、この方法では、省電力効果と通信品質（遅延時間や帯域）を両立させるのが難しいという問題がある。例えば、図１に示すように、送信側装置のデータ送信間隔に対して、スリープ間隔が長く設定されていると、大きな通信遅延が発生してしまう。この場合には、最大、スリープ間隔に相当する時間分だけの通信遅延が発生する可能性がある。一方、必要以上にスリープ間隔を短く設定すると、無駄なポーリングが発生し、省電力効果が小さくなってしまう。また、本来、ネットワークの通信状況や通信アプリケーションプログラムの要件（例えば、遅延時間や帯域の制限など）によって、適切なスリープ間隔は異なる。しかしながら、この方法ではスリープ間隔が固定のため、状況に応じた適切な省電力効果と通信品質が得られない。

上記の問題を解決するため、従来、通信アプリケーションプログラムが使用する通信データ帯域に応じてスリープ間隔を設定および変化させることで、通信品質と省電力効果とを両立させる方法が提案されている（例えば、特許文献１参照）。

図２は、上記特許文献１の無線端末の動作を説明するための説明図である。

特許文献１における無線端末は、図２に示す省電力設定リストを記憶しており、その省電力設定リストにはスリープ間隔（省電力設定）が設定されている。

具体的には、省電力設定リストには、無線端末で実行される各通信アプリケーションプログラムと、その通信アプリケーションプログラムが要求するデータ速度に対応する０〜１０までの省電力レベルと、その省電力レベルに対応するスリープ間隔（省電力設定）とが登録されている。

例えば、比較的速いデータ速度が要求される音声ストリーミングの通信アプリケーションプログラムには、省電力設定「ビーコンを毎回受信」および省電力レベル「１」が登録され、それよりもやや遅いデータ速度が要求されるウェブブラウザの通信アプリケーションプログラムには、省電力設定「ビーコンを２回に１回受信」および省電力レベル「２」が登録されている。また速いデータ速度が要求されない電子メールの通信アプリケーションプログラム（メールソフト）には、省電力設定「ビーコンを１０回に１回受信」および省電力レベル「１０」が登録され、極めて速いデータ速度が要求される動画ストリーミングの通信アプリケーションプログラムには、省電力設定「省電力制御を行なわない（ドーズモードに入らない）」および省電力レベル「０」が登録されている。

無線端末は、通信アプリケーションプログラムの起動または終了時に、省電力設定リストを元に、実行中の通信アプリケーションプログラムの中で最も省電力レベルが低いものを検索する。そして、無線端末は、その検索結果の省電力レベルに応じて省電力設定（スリープ間隔）を変更し、アクセスポイントにも省電力設定変更通知を送信する。

このように、特許文献１の無線端末（通信装置）は、通信アプリケーションプログラムの性質に応じて、ビーコンを受信する間隔（スリープ間隔）を変化させることで、適切な遅延時間や帯域で通信を行ないながら、消費電力を削減することもできる。
特開２００４−１８７００２号公報

しかしながら、上記特許文献１の通信装置であっても、通信品質と省電力効果とを十分に両立させることができないという問題がある。

つまり、従来の特許文献１に示す方式は、無線ＬＡＮの省電力方式の上で動作する方式であるため、無線ＬＡＮ特有の課題が発生する。具体的には、適用可能なネットワークが制限されるという第１の課題と、省電力制御とリアルタイム通信が両立できないという第２の課題と、アクセスポイントでデータの取りこぼしが発生してしまうという第３の課題とが発生する。

まず、第１の課題について説明する。特許文献１に記載の通信装置は、ＩＥＥＥ８０２．１１規定の省電力機能を有するアクセスポイントと連動して動作する。しかしながら、アクセスポイントによっては、ＩＥＥＥ８０２．１１規定の省電力機能をサポートしていないものや、機能を持っていてもデフォルトでＯＦＦになっているものがある。そのような環境では、たとえ携帯型端末側（通信装置側）で特許文献１に記載の省電力機能を搭載していたとしても、携帯型端末の省電力化が行なえない。また、同様の理由のため、携帯型端末（通信装置）がＩＥＥＥ８０２．１１以外のネットワークデバイスを使って通信（例えば、有線通信やＩＥＥＥ８０２．１１以外の無線通信）する際には、特許文献１記載の省電力方法を適用できない。このように、従来の特許文献１に示す方式は、適用可能なネットワークの条件が制限されており、ネットワークデバイスの種類や他の通信機器の実装状況によって、省電力化が行なえない場合が発生する。

次に、第２の課題について説明する。特許文献１の通信装置は、スリープ間隔を変化させるが、単にスリープ間隔のビーコン送信間隔に対する倍率を変化させるだけであるため、ビーコン送信間隔自体を自由に変更させることはできない。そのため、特許文献１の通信装置によるデータ受信は、ＩＥＥＥ８０２．１１の省電力方式と同じくビーコンの送信に連動したタイミングで行なわれる。その結果、特許文献１の通信装置では、リアルタイム通信に必要な遅延時間や帯域の要件を十分に満たすことができない。

以下、第２の課題を、遅延時間が長くなってしまうという問題と、通信帯域が低く抑えられるという問題とに分けて説明する。

まず、第２の課題における遅延時間が長くなってしまうという問題について説明する。特許文献１におけるスリープ間隔は、ビーコン送信間隔より短く設定できない。従って、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などの短時間おきにデータを送受信する通信アプリケーションプログラムでは、省電力制御を行なうと、遅延時間が長くなってしまう場合がある。特に、アクセスポイントのビーコン送信間隔が長く設定されていた場合には、遅延時間の増大により、音声品質が低下してしまう。

また、ビーコン送信間隔が短くても、１つのアクセスポイントに複数の無線端末（通信装置）が接続されている場合には、遅延時間が増大してしまうことがある。具体的には、リアルタイム性の要求される通信アプリケーションプログラムが複数の無線端末（通信装置）で動作している場合、ビーコン送信毎に同時に複数の無線端末からＰＳ−Ｐｏｌｌ（無線端末へのデータ送信を要求するパケット）が送信される。その場合、ＩＥＥＥ８０２．１１で規定されている、送信時のバックオフアルゴリズム（無線端末が送信可能状態になった後に実際にデータを送信できるまでに、あるランダム時間だけ待ってからデータを送信するアルゴリズム）に基づくと、特定の無線端末以外の１つ以上の無線端末が先に送信してしまう場合がある。このとき、先に送信を開始した無線端末からのデータ送信が完了するまで、その特定の無線端末はデータ送信を待たされてしまうため、待ち時間が増加する可能性が高くなってしまう。その結果、ＶｏＩＰなどの遅延時間に制限のある通信アプリケーションプログラムでは、遅延時間の増大が問題になる。さらに、無線端末側では、ビーコンを受信して実際にデータを受信し終わるまでドーズ状態に戻れないため、実際にデータの送受信を行なわない待ち時間も、無駄に電源を投入し続けることになり、省電力効果が小さくなる。

次に、第２の課題における通信帯域が低く抑えられるという問題について説明する。ビーコン送信間隔が長い条件で特許文献１の省電力化を行なうと、ＴＣＰ（Transmission Control Protocol）での通信帯域が低く抑えられてしまう。これは、後述するＴＣＰのフロー制御の仕組みにより、一度に受信できるデータサイズが、受信（無線端末）側のＴＣＰの受信バッファのサイズに制限されてしまうためである。高帯域でデータ受信を行なうには、大きな受信バッファを用意して一度に受信するデータを大きくするか、データ受信の間隔（＝スリープ間隔）を短く設定するか、のどちらかが必要となる。

ビーコン送信間隔が長い場合、スリープ間隔もビーコン送信間隔より短く設定できないので、高帯域の通信を行なうには膨大な受信バッファを搭載する必要がある。例えば、無線端末がＴＣＰの受信バッファを６４［ＫＢｙｔｅ］搭載していたとしても、ビーコン送信間隔が２００［ｍｓｅｃ］の場合、最大のスループットは、２．６［Ｍｂｐｓ］程度に抑えられてしまう。

このように、特許文献１の省電力制御および通信装置では、データ受信をビーコン送信のタイミングに連動させる必要があるため、遅延時間増大や帯域低下の課題が発生する場合がある。従って、遅延時間や帯域を確保するためには、ドーズモードに入らない（省電力制御を行なわない）という省電力設定を選択するしかなく、リアルタイム通信と省電力制御を両立することが十分にできない。

最後に、第３の課題について説明する。

特許文献１に記載の方式では、ＩＥＥＥ８０２．１１の省電力方式と同じく、アクセスポイントがドーズモード中の無線端末（通信装置）宛のパケットをバッファリングしている。しかしながら、送信側装置と携帯型端末（通信装置）間のデータ送受信は、常に一定レートではなく、通信装置内での処理の遅れやネットワーク内でのジッタなどにより、アクセスポイントにバッファリングされるデータ量は変化する。従って、想定以上のデータ量がバースト的に到着すると、アクセスポイントがバッファリングしきれずにデータを取りこぼしてしまう可能性がある。

そこで、本発明は、かかる問題に鑑みてなされたものであって、通信品質と省電力効果のさらなる向上を両立して図った通信装置を提供することを目的とする。

上記目的を達成するために、本発明に係る通信装置は、通信相手側装置と通信する通信装置であって、前記通信相手側装置に対してデータの送受信を行う通信手段と、前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態と、前記送受信に必要な電力が供給されていない非給電状態とに切り換える電源切換手段と、前記通信相手側装置に対してデータ（例えばＡＣＫパケットやＴＣＰのデータパケットなど）の送信を抑制させる抑制手段と、前記抑制手段によってデータの送信が抑制されていないときには、前記電源切換手段に対して、前記電力の状態を前記給電状態に切り換えさせ、前記抑制手段によってデータの送信が抑制されているときには、前記電源切換手段に対して、前記電力の状態を前記非給電状態に切り換えさせる切換制御手段とを備えることを特徴とする。例えば、前記通信装置は、さらに、データサイズである受信ウィンドウを含む送信要求データを前記通信手段から送信させることにより、前記通信相手側装置から前記受信ウィンドウ以下のデータを送信させて前記通信手段に受信させることを繰り返す通信制御手段を備え、前記抑制手段は、０より大きな値を示す受信ウィンドウを含む前記送信要求データを正送信要求データとし、当該正送信要求データの前記通信手段からの送信を停止することにより、前記通信相手側装置に対してデータの送信を抑制させる。また、前記抑制手段は、さらに、前記正送信要求データの送信の停止を解除することで、前記通信相手側装置からのデータの送信を再開させる。

これにより、抑制手段による任意のタイミングで、通信相手側装置からのデータの送信が抑制されて、そのときに通信手段に供給される電力が削減されるため、通信装置は、通信相手側装置に関わらず、つまり適用可能なネットワークの条件に制限されず、通信品質に支障が生じない適切なタイミングで、積極的にデータの送信を抑制させて省電力化を図ることができる。その結果、通信品質と省電力効果のさらなる向上を両立して図ることができる。

即ち、本発明の通信装置は、ＩＥＥＥ８０２．１１規定の無線ＬＡＮに依存しない方法で省電力化の制御を行うため、アクセスポイントとの連携を必要とせず、無線ＬＡＮのネットワーク環境に依存しない。また、このため、有線通信やＩＥＥＥ８０２．１１以外の無線通信時にも省電力制御が行なえる。

また、ＩＥＥＥ８０２．１１規定の無線ＬＡＮ環境を想定した場合にも、本発明は従来の特許文献１の技術と比べて以下の２つの利点がある。

まず第１に、本発明では、データ受信がアクセスポイントのビーコン送信のタイミングに連動せず、通信アプリケーションプログラムの要求する遅延時間や帯域に合わせたタイミングでデータ受信を行なうことができる。そのため、リアルタイム通信を行ないながら、つまり、リアルタイム通信に必要な遅延時間や帯域の要件を満たしながら、同時に省電力制御も両立することができる。

また第２に、本発明によれば、従来方法のようにドーズモードで受信したデータをアクセスポイントでバッファリングするのではなく、通信装置の電源を切断している間には、そもそも送信側装置（通信相手側装置）からのデータ送信がない状態にされている。そのため、送信側装置の処理またはネットワーク上でなんらかのジッタが発生したとしても、アクセスポイントでデータ溢れがおきるような課題も発生しなくなる。

また、前記通信制御手段は、前記通信手段でデータが受信されると、前記データを受信したことを通知する肯定応答パケットを前記送信要求データとして前記通信手段から送信させ、前記抑制手段は、前記通信手段でデータが受信されたときに前記正送信要求データとして送信されるべき、０より大きな値を示す受信ウィンドウを含む前記肯定応答パケットの、前記通信手段からの送信を停止することにより、前記通信相手側装置に対してデータの送信を抑制させ、０より大きな値を示す受信ウィンドウを含む前記肯定応答パケットを前記通信制御手段に生成させて送信させることにより、前記通信相手側装置からのデータの送信を再開させることを特徴としてもよい。例えば、前記通信制御手段は、ＴＣＰ（Transmission Control Protocol）に従って、前記肯定応答パケットを前記通信手段から送信させるとともに、前記肯定応答パケットに対して前記通信相手側装置から送信されたデータを前記通信手段に受信させる。

これにより、フロー制御の仕組みを使うＴＣＰに従った通信において、通信品質と省電力効果のさらなる向上を両立して図ることができる。

また、前記抑制手段は、さらに、前記通信相手側装置のデータの送信が抑制されているときに、受信ウィンドウとして０を示す送信要求データを前記通信手段から送信させることを特徴としてもよい。

例えば、通信相手側装置は、一定期間のうちに、受信ウィンドウとして０を示す送信要求データを受信できないときには、先に送信したデータが通信装置に受信されていないと判断して、そのデータを再送し、その後、送信要求データに対して送信可能なデータのサイズを減少させてしまうことがある。このような場合でも、本発明では、受信ウィンドウとして０を示す送信要求データが通信相手側装置に送信されるため、通信相手側装置からデータが送信されるのを抑えた状態で、通信相手側装置において送信可能なデータのサイズの減少を防ぐことができる。

また、前記通信装置は、さらに、サイクル時間およびサイクルデータサイズを決定する決定手段を備え、前記通信制御手段は、前記決定手段で決定されたサイクルデータサイズを前記受信ウィンドウとし、前記サイクルデータサイズを示す送信要求データを前記通信手段から送信させ、前記送信要求データを送信したタイミングをサイクル開始時点とし、前記抑制手段は、前記通信手段から前記送信要求データが送信されてから、前記決定手段で決定された前記サイクル時間が経過する時点をサイクル終了時点とし、前記サイクルデータサイズのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止し、前記サイクル終了時点を次のサイクルの前記サイクル開始時点として、前記サイクル開始時点から前記サイクル終了時点までの処理を前記サイクル時間ごとに繰り返させることを特徴としてもよい。例えば、前記決定手段は、前記通信装置と前記通信相手側装置との間で要求される通信の性能に基づいて、前記サイクル時間およびサイクルデータサイズを決定する。

これにより、サイクル時間（サイクル間隔）内において、送信要求データの送信と、その送信要求データに対するサイクルデータサイズ分のデータの受信と、送信要求データの送信の停止処理とを含む１つのサイクルを行い、さらに、そのサイクルを繰り返すことで、間欠的なデータの送受信を行うことができる。また、例えば、通信装置で実行される通信アプリケーションプログラムによって要求される通信帯域や遅延時間などの条件（性能）が満たされた状態で、その間欠的なデータの送受信を行うことができる。その結果、サイクル終了時点まで次の送信要求データの送信を停止していても、上述の通信帯域や遅延時間の要求を満足することができる。

また、前記切換制御手段は、前記通信相手側装置から前記サイクルデータサイズのデータが送信されて前記通信手段に受信された後、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記サイクル終了時点までに、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。

これにより、間欠的なデータ送受信の１サイクルにおいて、通信手段での消費電力を確実に減少させることができる。

また、前記通信相手側装置は、当該通信相手側装置から送信されたデータが消失して前記通信手段に受信されなかったことを検知すると、前記送信要求データに対して送信可能なデータのサイズである送信ウィンドウを減少させ、前記抑制手段は、前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいか否かを判別し、小さいと判別したときには、前記受信ウィンドウが前記送信ウィンドウ以下となるようなウィンドウ制御を行うことを特徴としてもよい。例えば、前記抑制手段は、前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に順次受信された各データの識別番号が連続であるか不連続であるかを判別し、不連続であると判別したときに、前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいと判別する。または、前記抑制手段は、前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に順次受信された各データの合計サイズが、予め定められた期間内で、前記送信要求データの示すサイクルデータサイズに達するか否かを判別し、達しないと判別したときに、前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいと判別する。

通信相手側装置が、データが消失して通信手段に受信されなかったことを検知すると、即ちパケットロスを検知すると、送信ウィンドウ（輻輳ウィンドウ）が減少するため、受信された送信要求データの示す受信ウィンドウ（サイクルデータサイズ）が送信ウィンドウよりも大きくなる場合がある。このような場合には、通信装置の通信手段は、送信要求データを送信しても、その送信要求データの示す受信ウィンドウ（サイクルデータサイズ）のデータを受信することができず、送信ウィンドウだけのデータを受信する。仮にこのような状態が継続されれば、通信装置の切換制御手段は、通信手段に供給される電力の状態を非給電状態に切り換えることができず、省電力化を行うことができない。

そこで、本発明では、通信手段に受信されたデータのサイズがサイクルデータサイズよりも小さい場合には、例えば、受信ウィンドウを低下させたり、送信ウィンドウをサイクルサイズ以上に回復させたりするように、前記受信ウィンドウが前記送信ウィンドウ以下となるようなウィンドウ制御を行うため、パケットロスが発生しても受信ウィンドウ≦送信ウィンドウの関係を維持して、上述のような間欠的なデータの送受信を行うとともに省電力化を図ることができる。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記サイクルデータサイズよりも小さいと判別したときには、前記ウィンドウ制御として、後に前記通信手段から送信される送信要求データの示す受信ウィンドウを前記サイクルデータサイズよりも小さくさせることを特徴としてもよい。

これにより、パケットロスが発生しても受信ウィンドウ≦送信ウィンドウの関係を確実に維持して、間欠的なデータの送受信を行うとともに省電力化を図ることができる。

また、前記通信相手側装置は、前記通信手段から送信要求データを受信して、前記送信要求データに対するデータを前記通信手段に送信することを繰り返すことによって、減少された前記送信ウィンドウを増加させ、前記抑制手段は、前記送信ウィンドウの増加に伴って、前記通信手段から送信される送信要求データの示す受信ウィンドウを増加させることを特徴としてもよい。

これにより、パケットロスなどによって、送信ウィンドウおよび受信ウィンドウが減少されても、それぞれ増加されるため、それぞれを元の値にして、通信状態を、パケットロスが発生する前の状態に回復させることができる。

また、前記抑制手段は、前記サイクルデータサイズよりも小さい受信ウィンドウを示す送信要求データが前記通信手段から繰り返し送信されている間、前記決定手段で決定されたサイクル時間を短くし、前記通信手段から前記送信要求データが送信されてから、短くされた前記サイクル時間が経過する時点をサイクル終了時点とし、前記受信ウィンドウのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止することを特徴としてもよい。

これにより、受信ウィンドウがサイクルデータサイズよりも小さくなっても、サイクル時間が短くされるため、単位時間当りに通信相手側装置から送信されて通信手段で受信されるデータの量を一定に、つまりスループットを一定に保つことができる。

また、前記通信相手側装置は、前記通信手段から送信要求データを受信して、前記送信要求データに対するデータを前記通信手段に送信することを繰り返すことによって、減少された前記送信ウィンドウを増加させ、前記抑制手段は、前記送信ウィンドウが前記サイクルデータサイズよりも小さくなってから前記サイクルデータサイズ以上になるまでのウィンドウ回復期間、前記ウィンドウ制御として、前記正送信要求データの送信の停止を解除することを特徴としてもよい。

これにより、パケットロスなどによって減少された送信ウィンドウを元の値に回復させることができる。

また、前記通信制御手段は、前記通信手段でデータが受信されると、次に受信すべきデータの識別番号を通知することで、前記通信手段でデータが受信されたことを、前記通信相手側装置に通知する肯定応答パケットを、前記送信要求データとして前記通信手段から送信させ、前記ウィンドウ回復期間では、前記肯定応答パケットを、互いに異なる前記識別番号を有する複数の肯定応答パケットに分けて前記通信手段から送信させることを特徴としてもよい。

これにより、通信装置が肯定応答パケットを通信相手側装置に送信し、その肯定応答パケットに対して通信相手側装置が通信装置にデータを送信するという、データ送受信の回数を、分割された肯定応答パケットの数だけ増加させることができる。その結果、通信相手側装置の減少された送信ウィンドウを早急に元の値に回復させることができる。

また、前記切換制御手段は、前記通信手段から前記送信要求データが送信された後に、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記送信要求データに対するデータが前記通信手段に受信される前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。例えば、前記切換制御手段は、前記通信手段から前記送信要求データが送信されてから所定時間が経過した後に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせる。または、前記通信装置は、さらに、前記通信手段から前記送信要求データが送信されてから、前記送信要求データに対するデータが前記通信相手側装置から送信されて前記通信手段に受信されるまでの応答時間を推定する推定手段を備え、前記切換制御手段は、前記通信装置から前記送信要求データが送信されてから前記応答時間が経過する前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせる。

これにより、通信装置は、送信要求データを送信してデータを受信するまでの間にも、通信手段の消費電力を削減することができ、通信品質を損なうことなく省電力化のさらなる向上を図ることができる。

また、前記通信手段は、前記通信相手側装置と通信端末との間における通信を中継することを特徴としてもよい。

これにより、例えば、従来の通信端末と通信相手側装置との間で行われるＴＣＰに従ったデータ通信を中継する場合にも、通信手段の消費電力を抑えることができ、通信品質と省電力効果のさらなる向上を両立して図ることができる。

また、前記通信装置は、さらに、送信データを前記通信手段から送信させることにより、前記通信相手側装置から肯定応答パケットを送信させて前記通信手段に受信させることを繰り返す通信制御手段を備え、前記抑制手段は、前記送信データの前記通信手段からの送信を停止することにより、前記通信相手側装置に対して肯定応答パケットの送信を抑制させることを特徴としてもよい。ここで、前記抑制手段は、さらに、前記送信データの送信の停止を解除することで、前記通信相手側装置からの肯定応答パケットの送信を再開させる。

これにより、本発明の通信装置が通信相手側装置に対して送信データを送る場合でも、抑制手段による任意のタイミングで、通信相手側装置からの肯定応答パケットの送信が抑制されて、そのときに通信手段に供給される電力が削減されるため、通信装置は、通信相手側装置に関わらず、つまり適用可能なネットワークの条件に制限されず、通信品質に支障が生じない適切なタイミングで、積極的にデータの送信を抑制させて省電力化を図ることができる。その結果、通信品質と省電力効果のさらなる向上を両立して図ることができる。

また、前記通信装置は、さらに、サイクル時間およびサイクルデータサイズを決定する決定手段を備え、前記通信制御手段は、前記決定手段で決定されたサイクルデータサイズ分の送信データを前記通信手段から送信させ、前記送信データを送信したタイミングをサイクル開始時点とし、前記抑制手段は、前記通信手段から前記送信データが送信されてから、前記決定手段で決定された前記サイクル時間が経過する時点をサイクル終了時点とし、前記送信データに対する肯定応答パケットが前記通信手段に受信されてから前記サイクル終了時点まで、前記送信データの前記通信手段からの送信を停止し、前記サイクル終了時点を次のサイクルの前記サイクル開始時点として、前記サイクル開始時点から前記サイクル終了時点までの処理を前記サイクル時間ごとに繰り返させることを特徴としてもよい。

これにより、サイクル時間（サイクル間隔）内において、送信データの送信と、その送信データに対する肯定応答パケットの受信と、送信データの送信の停止処理とを含む１つのサイクルを行い、さらに、そのサイクルを繰り返すことで、間欠的なデータの送受信を行うことができる。また、例えば、通信装置で実行される通信アプリケーションプログラムによって要求される通信帯域や遅延時間などの条件（性能）が満たされた状態で、その間欠的なデータの送受信を行うことができる。その結果、サイクル終了時点まで次の送信データの送信を停止していても、上述の通信帯域や遅延時間の要求を満足することができる。

また、前記通信手段は、前記通信相手側装置および他の通信相手側装置との間でデータの送受信を並列に行い、前記決定手段は、前記通信手段が前記他の通信相手側装置との間で一定時間ごとに送受信を繰り返す場合、前記他の通信相手側装置との間の送受信と、前記通信相手側装置からのデータの受信とが同期するように、前記一定時間に基づいて前記サイクル時間を決定することを特徴としてもよい。例えば、前記決定装置は、前記通信手段が前記他の通信相手側装置から一定時間ごとに固定レートでデータを受信することを繰り返す場合に、前記一定時間を基準とし、前記一定時間に基づいて前記サイクル時間を決定することを特徴としてもよい。

これにより、例えばサイクル時間を上述の一定時間に等しくすれば、抑制手段が通信相手側装置に対してデータの送信を抑制させている期間を、他の通信相手側装置からデータが受信されていない期間に合わせることができる。つまり、通信装置は通信相手側装置および他の通信相手側装置との間の通信を同期させることができ、上述の期間において通信手段に供給される電力を切断することで、通信装置は通信相手側装置および他の通信相手側装置との間で通信を行いながら省電力効果を向上することができる。

また、前記通信手段は、前記通信相手側装置および他の通信相手側装置との間でデータの送受信を並列に行い、前記抑制手段は、前記通信手段が前記他の通信相手側装置から一定時間ごとに固定レートでデータを受信することを繰り返す場合、前記他の通信相手側装置からのデータが前記通信手段に受信されるタイミングと、前記通信相手側装置からのデータが前記通信手段に受信されるタイミングとが一致するように、前記通信手段からの前記正送信要求データの送信の停止および解除を行うことを特徴としてもよい。

これにより、上述のようにサイクル時間を上記一定時間に等しくしなくても、他の通信相手側装置からのデータが通信手段に受信されるタイミングと、通信相手側装置からのデータが通信手段に受信されるタイミングとが一致するため、抑制手段が通信相手側装置に対してデータの送信を抑制させている期間を、他の通信相手側装置からデータが受信されていない期間に合わせることができる。その結果、その期間において通信手段に供給される電力を切断することで、通信装置は通信相手側装置および他の通信相手側装置との間で通信を行いながら省電力効果を向上することができる。

また、前記抑制手段は、上述のようなデータの送信を抑制させる制御を行うことを、前記通信制御手段に通知する間欠受信実施通知手段を備え、前記通信制御手段は、前記間欠受信実施通知手段からの通知を受け付けたときには、前記通信手段から送信されるパケットに、前記通知の内容を示す情報を設定することを特徴としてもよい。

また、前記通信制御手段は、ＴＣＰ（Transmission Control Protocol）に従って、前記送信データを前記通信手段から送信させるとともに、前記送信データに対して前記通信相手側装置から送信された前記肯定応答パケットを前記通信手段に受信させることを特徴としてもよい。

また、前記切換制御手段は、前記通信相手側装置から前記肯定応答パケットが送信されて前記通信手段に受信された後、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記サイクル終了時点までに、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。

また、前記切換制御手段は、前記通信手段から前記送信データが送信された後に、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記送信データに対する少なくとも一つの肯定応答パケットが前記通信手段に受信される前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。

また、前記通信制御手段は、送信データを一時的に保持するデータ保持手段を備え、送信データが送信されてから一定時間内に前記肯定応答パケットが前記通信手段に受信されなかった場合、前記データ保持手段に保持されている送信済みの送信データを、次のサイクルの最初の送信データとして前記通信手段に再送させることを特徴としてもよい。

また、前記抑制手段が、前記サイクルデータサイズの送信データが送信された後、前記肯定応答パケットが前記通信手段に到達しないと判断した場合、前記通信制御手段は、前記肯定応答パケットが到達するまで、前記通信手段に送信済みの前記送信データを再送させることを特徴としてもよい。

また、前記抑制手段は、前記肯定応答パケットを受信するのに必要となる前記送信データのパケット数である遅延応答回避パケット数に基づき、前記サイクルデータサイズ分の送信データを前記遅延応答回避パケット数の整数倍に分割することを前記通信制御手段に対して要求し、前記通信制御手段は、前記要求に従い、前記サイクルデータサイズ分のデータを前記遅延応答回避パケット数の整数倍に分割して前記通信手段から送信させることを特徴としてもよい。

また、前記通信装置は、さらに、一定時間ごとに処理の開始および停止を繰り返す間欠処理手段を備え、前記間欠処理手段は、前記間欠処理手段による処理の開始および停止の時間間隔を、前記サイクル時間に合わせることを特徴としてもよい。

また、前記通信装置は、さらに、一定時間ごとに処理の開始および停止を繰り返す間欠処理手段を備え、前記間欠処理手段は、前記間欠処理手段による処理の開始時点を、前記サイクル開始時点に合わせることを特徴としてもよい。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記期待値よりも小さいと判別したときには、前記正送信要求データの送信の停止を解除することを特徴としてもよい。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記期待値よりも小さいと判別したときには、後に前記通信手段から送信される送信要求データの前記受信ウィンドウを前記サイクルデータサイズよりも小さい値にして、さらに後に前記通信手段から送信される送信要求データの前記受信ウィンドウを前記値よりも大きくすることを特徴としてもよい。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記期待値よりも小さいと判別したときには、前記決定手段で決定されたサイクル時間を短くし、前記通信手段から前記送信要求データが送信されてから、短くされた前記サイクル時間が経過する時点をサイクル終了時点とし、前記受信ウィンドウのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止することを特徴としてもよい。

なお、本発明は、このような通信装置として実現することができるだけでなく、その通信装置を含んで構成される通信システムや、その通信装置が通信する通信方法や、その通信装置の消費電力を削減する省電力方法や、その通信装置を動かすためのプログラムや、そのプログラムを格納する記憶媒体や、集積回路としても実現することができる。

本発明の通信装置は、通信品質と省電力効果のさらなる向上を両立して図ることができるという作用効果を奏する。また、本発明の通信装置は、フロー制御の仕組みを利用した省電力制御を有し、持ち運び可能な通信装置（一般的には、無線端末）が、リアルタイム通信をしながら電力消費も抑えたいような使い方（例えば、他の通信装置からネットワーク経由で長時間にわたってデータを受信するような場合）に有用である。さらに、無線ＬＡＮに限らず、有線通信や他の無線デバイスを使った通信など、様々なネットワーク環境の通信装置にも適用可能である。また、従来の無線ＬＡＮの省電力方法にあった、アクセスポイントのバッファ容量溢れによるデータロスの課題も防ぐことができる。

図１は、従来の通信装置の動作を説明するための説明図である。 図２は、従来の他の通信装置の動作を説明するための説明図である。 図３は、本発明の実施の形態１における通信装置を有する通信システムの一例を示す構成図である。 図４は、同上の受信側装置である携帯型端末と送信側装置との基本的な処理の一例を示すシーケンス図である。 図５は、同上の携帯型端末の具体的な構成を示す構成図である。 図６Ａは、同上のアプリ要求取得部が管理する性能パラメータ管理テーブルを示す図である。 図６Ｂは、同上のアプリ要求取得部が管理する他の性能パラメータ管理テーブルを示す図である。 図６Ｃは、同上のアプリ要求取得部が管理するさらに他の性能パラメータ管理テーブルを示す図である。 図７は、同上の間欠受信パラメータの決定ルールを示す図である。 図８は、同上のパラメータ決定部によって生成された間欠受信パラメータ管理テーブルの一例を示す図である。 図９は、同上の携帯型端末と送信側装置の定常状態での動作を示すシーケンス図である。 図１０は、同上の携帯型端末の動作を示すフローチャートである。 図１１は、同上の受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットが送信される動作を示すシーケンス図である。 図１２は、本発明の実施の形態２における携帯型端末の具体的な構成を示す構成図である。 図１３は、同上の携帯型端末と送信側装置の省電力方法を示すシーケンス図である。 図１４は、本発明の実施の形態３における携帯型端末の具体的な構成を示す構成図である。 図１５は、同上の携帯型端末の動作を示すフローチャートである。 図１６は、同上のパケットロス検知処理の詳細を説明するための説明図である。 図１７は、同上の再送誘発処理の詳細を説明するための説明図である。 図１８は、同上のＣＷＩＮ推定処理の詳細を説明するための説明図である。 図１９は、同上のＣＷＩＮ低下期間中の処理の詳細を示すフローチャートである。 図２０は、同上のＣＷＩＮ低下期間中において行われる間欠受信の１サイクルを示す図である。 図２１は、本発明の実施の形態４における通信装置を有する通信システムの一例を示す構成図である。 図２２は、同上の携帯型端末の具体的な構成を示す構成図である。 図２３は、同上の受信側装置と携帯型端末と送信側装置の定常状態での動さを示すシーケンス図である。 図２４は、本発明の実施の形態５における通信装置を有する通信システムの一例を示す構成図である。 図２５は、同上の送信側装置である携帯型端末の具体的な構成を示す構成図である。 図２６は、同上の携帯型端末と受信側装置の定常状態での動作を示すシーケンス図である。 図２７は、同上の携帯型端末の動作を示すフローチャートである。 図２８は、同上の携帯型端末と受信側装置の定常状態で、ＲＴＴ間も電源切断を行う場合の動作を示すシーケンス図である。 図２９は、本発明の実施の形態６における通信装置を有する通信システムの一例を示す構成図である。 図３０は、同上の携帯型端末の具体的な構成を示す構成図である。 図３１Ａは、同上のアプリ要求取得部が管理するＵＤＰに関する性能パラメータ管理テーブルを示す図である。 図３１Ｂは、同上のアプリ要求取得部が管理するＵＤＰに関する他の性能パラメータ管理テーブルを示す図である。 図３２Ａは、同上のアプリ要求取得部が管理するＴＣＰに関する性能パラメータ管理テーブルを示す図である。 図３２Ｂは、同上のアプリ要求取得部が管理するＴＣＰに関する他の性能パラメータ管理テーブルを示す図である。 図３３は、同上の携帯型端末と、ＵＤＰを用いた通信を行う送信側装置と、ＴＣＰを用いた通信を行う送信側装置との通信において、送信間隔とサイクル間隔が同期する場合における、定常状態での動作を示すシーケンス図である。 図３４は、サイクル間隔と送信間隔とが異なる場合に抑制再開制御部がデータの送受信のタイミングの同期を取るための動作を示すフローチャートである。 図３５は、同上の携帯型端末と、ＵＤＰを用いた通信を行う送信側装置と、ＴＣＰを用いた通信を行う送信側装置との通信において、送信間隔とサイクル間隔が同期しない場合における、定常状態での動作を示すシーケンス図である。 図３６は、同上の携帯型端末と、ＴＣＰを用いた通信を行う受信側装置と、ＴＣＰを用いた通信を行う送信側装置との通信において、定常状態での動作を示すシーケンス図である。 図３７は、本発明の実施の形態７における通信装置を有する通信システムの一例を示す構成図である。 図３８は、同上の携帯型無線装置の具体的な構成を示す構成図である。 図３９は、同上の携帯型無線装置と携帯型端末の定常状態での動作を示すシーケンス図である。

符号の説明

１０１ 通信アプリケーション部
１０２ アプリ要求取得部
１０３ パラメータ決定部
１０４ 抑制再開制御部
１０６ 電源制御部
１０７ 通信制御部
１０８ 通信Ｉ／Ｆ部
２０２ 無線基地局
２０３ 送信側装置
２０４ インターネット（ＷＡＮ）
２１１、２１２ 携帯型端末（通信装置）

（実施の形態１）
以下、本発明の第１の実施の形態における通信装置について図面を参照しながら説明する。

図３は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型端末２１１，２１２と、無線基地局２０２と、インターネット２０４と、送信側装置２０３とを備えている。

携帯型端末２１１，２１２は、通信品質と省電力効果のさらなる向上を両立して図った通信装置であって、無線通信デバイスを搭載した無線端末として構成されている。携帯型端末２１１，２１２は、無線基地局２０２を介してインターネット２０４に接続する。

送信側装置２０３は、インターネット２０４上に接続されている通信装置である。送信側装置２０３は、他の機器からの接続を受け付けて、相手にコンテンツデータなどを送信する機能を持つ。

このような通信システムでは、携帯型端末２１１，２１２は、インターネット２０４を介して送信側装置２０３と接続し、送信側装置２０３からのデータを受信する。携帯型端末２１１と送信側装置２０３の間のデータ送受信には、ＴＣＰ（Transmission Control Protocol）のようなフロー制御付きプロトコルが使われる。

なお、図３に示す携帯型端末２１１，２１２は、それぞれ同等の構成を備え、同等の動作を行なう装置であるため、以下の説明では、簡略化のため、携帯型端末２１１について詳細に説明する。また、携帯型端末２１１を受信側装置として以下説明する。

本実施の形態における携帯型端末２１１は、フロー制御を利用する。フロー制御とは、受信側装置のデータ受信処理が追いつかなくなる事態を防ぐために、受信側装置が送信側装置にデータ送信の停止および再開を指示する制御である。この制御は、受信側装置でのデータあふれを防ぐための制御として、各種の通信プロトコルで行なわれている。

以下、ＴＣＰにおけるフロー制御の仕組みを説明する。ＴＣＰレベルのフロー制御は、受信ウィンドウ（一般的に、受信側装置のＴＣＰ受信バッファの空き容量に相当）を送信側装置に伝えることで、それ以上のデータが受信側装置に送られないように調整している。具体的には、受信ウィンドウは、ＴＣＰヘッダの「ウィンドウサイズ」のフィールドに格納され、受信側装置から送信側装置へのＡＣＫパケット（肯定応答パケット）を使って通知される。送信側装置では、ＡＣＫパケットを監視し、送信済みのデータサイズとＡＣＫパケットで通知された受信ウィンドウとの関係から、送信可能なデータサイズの上限を知り、その上限を超えて送信しないようにする。なお、ＴＣＰヘッダには、さらにシーケンス番号（送信するデータのストリーム全体の位置を示す番号）とＡＣＫ番号（次に受信するデータのシーケンス番号）のフィールドがあり、受信側装置はＡＣＫパケットのＡＣＫ番号を使って、どこまでのデータを受信したのかを送信側装置に通知する。

一方、受信側装置の処理が滞った場合のように、受信側装置が受信ウィンドウを更新しない（ＡＣＫパケットを返せない）状況が続くと、送信側装置の送信可能なデータサイズが減少する。最終的に送信可能なデータサイズが０になると、送信側装置からそれ以上のデータの送信ができなくなる。すなわち、この状態では、新たなデータ受信を示すＡＣＫパケットを受け取るか、より大きな受信ウィンドウを通知されるまでは、送信側装置は送信を行えなくなる。その後、受信側装置がデータ受信可能な状態になったら、改めてＡＣＫパケットを送信側装置に送って、新たな受信ウィンドウを通知すれば、送信側装置からのデータ送信が再開する。

本発明では、このようなフロー制御の仕組みを、（受信側装置の停滞などによる）データあふれ回避の目的ではなく、受信側装置が送信側装置からの間欠的なデータ送信を能動的に実行させる目的で利用する。

図４は、受信側装置である携帯型端末２１１と送信側装置２０３との基本的な処理の一例を示すシーケンス図である。

携帯型端末２１１（上述の受信側装置に相当する）と送信側装置２０３とは、ＴＣＰを使ったデータ送受信を行なう。

まず、携帯型端末２１１は、送信側装置２０３がバースト的に送信するデータサイズの上限を決め、それを受信ウィンドウとして送信側装置２０３へ通知する（ステップＳ７０１）。例えば、送信側装置２０３が１パケットで送信するデータサイズがＤｓｅｇ［バイト］である場合、携帯型端末２１１は、送信側装置２０３の送信するデータのサイズの上限を、４パケット分（＝４×Ｄｓｅｇ［バイト］）に決定する。そして、携帯型端末２１１は、受信ウィンドウ（以後、ＲＷＩＮと呼ぶ）を「４×Ｄｓｅｇ」に設定したＡＣＫパケットを、送信側装置２０３に送信する。

送信側装置２０３は、ＲＷＩＮ＝４×Ｄｓｅｇ［バイト］のＡＣＫパケットを受信することにより、送信可能なデータサイズ（以下、ｕｗｎｄという）が４×Ｄｓｅｇ［バイト］であることを把握し、データ送信を再開できるようになる。なお、送信側装置２０３は、そのＡＣＫパケットの受信前には、送信可能なデータサイズをｕｗｎｄ＝０として把握しており、データ送信を停止している。

次に、送信側装置２０３は、Ｄｓｅｇ［バイト］のパケットを４回だけ送信し、１回送信するごとにｕｗｎｄをＤｓｅｇ［バイト］分だけデクリメントする（ステップＳ７０２〜Ｓ７０５）。

一方、携帯型端末２１１は、ステップＳ７０２〜Ｓ７０５で送信側装置２０３から送信されたデータ（パケット）を受信するが、ＡＣＫパケットを返さない制御を行なう。その結果、送信側装置２０３は、４回目のパケットを送信した時点（ステップＳ７０５）でｕｗｎｄが０になるため、データ送信を停止する。このようにして、携帯型端末２１１は「送信側装置がデータを送信できない期間」を作ることができる。以後、送信側装置がデータを送信できない期間のことを、送信抑制期間と呼ぶ。その後、携帯型端末２１１は、所望のタイミングで「ＲＷＩＮ＝４×Ｄｓｅｇ」のＡＣＫパケットを送信することで、送信側装置２０３にデータ送信の再開を指示する（ステップＳ７０６）。

携帯型端末２１１は、フロー制御の仕組みを使って上記のようなデータ送信の抑制と再開の指示を繰り返すことで、携帯型端末２１１の所望する間隔での間欠的なデータ受信（間欠受信）を行う。そして、携帯型端末２１１は、受信の合間の送信抑制期間に、携帯型端末２１１の備える通信Ｉ／Ｆ部の電源を切断し、実際にデータやＡＣＫパケットの送受信を行なう期間だけ通信Ｉ／Ｆ部の電源を投入することで、携帯型端末２１１の省電力化を行なう。

なお、本実施の形態では、間欠的に通信Ｉ／Ｆ部の電源を切断または投入することにより省電力制御を行うが、必ずしも完全に電源を切断する必要はなく、通信Ｉ／Ｆ部に電力を供給した状態でその電力を調整してもよい。つまり、携帯型端末２１１は、通信Ｉ／Ｆ部によるデータの送受信の必要がない期間には、通信Ｉ／Ｆ部に供給される電力を、通信Ｉ／Ｆ部の送受信機能を正常に動作させるために必要な電力（以下、通常電力という）よりも抑え、データの送受信の必要がある期間には、通信Ｉ／Ｆ部に供給される電力を通常電力に戻す。即ち、本発明における省電力制御では、通信Ｉ／Ｆ部の消費電力を、通常電力よりも低い状態に変化させる制御であればよい。例えば、携帯型端末２１１に低消費電力モードが定義されている場合は、携帯型端末２１１は、通信Ｉ／Ｆ部の電源を切断する代わりに低消費電力モードに移行する。または、携帯型端末２１１は、通信Ｉ／Ｆ部への電源（電流）の供給を停止したり、クロックの供給を停止したりする。そして、携帯型端末２１１は、消費電力を通常電力に復帰させるときには、電源を投入したり、供給電力を増加させたり、クロックの提供を開始したりするなど、上記それぞれと逆の操作を行う。

このように、本発明では、フロー制御の仕組みを使って、携帯型端末（受信側装置）２１１がデータ受信の無い期間を能動的に作り、その期間に電源をＯＦＦにすることで省電力化を図る。従って、省電力化の制御は、受信側装置のみで行なわれ、無線ＬＡＮの省電力方式のように、アクセスポイントとの連携を必要としない。そのため、ネットワーク環境に依存せずに省電力制御が行なえる。

また、本発明では、データ受信のタイミングは、アクセスポイントのビーコン送信のタイミングに連動せず、受信側装置で自由に制御できる。従って、通信アプリケーションプログラムの必要とする遅延時間と帯域を確保できるように、データ受信の間隔およびデータサイズを調整すれば、所望の通信を継続しながら、同時に省電力化も両立して行うことができる。

さらに、本発明では、アクセスポイントでデータをバッファリングせず、受信側装置の受信可能なタイミングおよびデータサイズで送信側装置がデータを送信するので、アクセスポイントでのデータ溢れの発生を防ぐこともできる。

ここで、本実施の形態における携帯型端末２１１について詳細に説明する。

図５は、携帯型端末２１１の具体的な構成を示す構成図である。

携帯型端末２１１は、通信アプリケーション部１０１と、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部１０４と、電源制御部１０６と、通信制御部１０７と、上述の通信Ｉ／Ｆ部１０８とを備える。

なお、本実施の形態では、通信Ｉ／Ｆ部１０８が通信手段として構成され、電源制御部１０６が電源切換手段として構成され、抑制再開制御部１０４が抑制手段および切換制御手段として構成されている。

通信アプリケーション部１０１は、通信アプリケーションプログラムを実行する。通信アプリケーション部１０１は、通信アプリケーションプログラムの起動時に、アプリ要求取得部１０２に起動通知を発行し、送信側装置２０３との間でデータ送受信を行なう。また、通信アプリケーション部１０１は、通信アプリケーションプログラムの終了時に、アプリ要求取得部１０２に終了通知を発行する。なお、本実施の形態では、説明の単純化のため、携帯型端末２１１上で同時に動作する通信アプリケーションプログラムが１つに限定されているものとする。

アプリ要求取得部１０２は、通信アプリケーション部１０１と送信側装置２０３との間でのデータ通信の「性能パラメータ」を入手する。ここで、「性能パラメータ」とは、通信アプリケーションプログラムによって独自に決められた帯域や遅延時間、一度に送信するパケットのサイズなどの条件（性能要件）を示すパラメータである。アプリ要求取得部１０２は、通信アプリケーション部１０１から起動通知または終了通知を受けると、同時に性能パラメータを通信アプリケーション部１０１から入手し、パラメータ決定部１０３に対して、性能パラメータ登録通知または性能パラメータ削除通知を発行する。

パラメータ決定部１０３は、間欠的にデータを受信するためのパラメータを決定する。間欠的にデータを受信するためのパラメータは、間欠受信の１サイクル分の時間間隔、および１サイクルの間に受信するデータサイズの２つから成る。以後、前者のパラメータを「サイクル間隔」と呼び、後者のパラメータを「サイクルデータサイズ」と呼ぶ。また、これらの２つのパラメータを総称して「間欠受信パラメータ」と呼ぶ。パラメータ決定部１０３は、アプリ要求取得部１０２から性能パラメータ登録通知または性能パラメータ削除通知を受けつけたとき、アプリ要求取得部１０２からの性能パラメータを元に間欠受信パラメータを決定し、抑制再開制御部１０４に間欠受信パラメータ登録通知または間欠受信パラメータ削除通知を送信する。

抑制再開制御部１０４は、送信側装置２０３からのデータ送信が間欠的に行なわれるように、ＴＣＰのフロー制御の仕組みを使って通信制御部１０７を制御する。さらに、抑制再開制御部１０４は、このＴＣＰのフロー制御によって得られた送信抑制期間（送信側装置２０３からのデータ送信が無い期間）に通信Ｉ／Ｆ部１０８の電源が切断されるように、電源制御部１０６へ指示を出す。

具体的には、抑制再開制御部１０４は、間欠受信パラメータ登録通知によって受け取った間欠受信パラメータに応じて、送信側装置２０３からのデータ送信を抑制または再開させるタイミングを決定する。また、抑制再開制御部１０４は、決定したタイミングに、送信側装置２０３からのデータ送信を抑制または再開させるため、通信制御部１０７に対してＡＣＫパケットに関係する３つの要求（後述）を発行する。また、抑制再開制御部１０４は、送信抑制期間に連動して、電源制御部１０６に対して投入または切断の要求を送信する。さらに、抑制再開制御部１０４は、通信制御部１０７で送受信するＴＣＰパケットをモニタリングし、そのモニタリングの結果を上述のタイミングの決定に利用する。

電源制御部１０６は、抑制再開制御部１０４からの投入または切断の要求に従って、通信Ｉ／Ｆ部１０８の電源を投入または切断する。

通信制御部１０７は、通信アプリケーション部１０１からのデータを、通信Ｉ／Ｆ部１０８より送信するための制御を行なうとともに、通信Ｉ／Ｆ部１０８で受信したデータを通信アプリケーション部１０１に渡すための制御を行なう。この制御には、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）などのプロトコル処理や、無線基地局２０２との間のネゴシエーション処理などが含まれる。通信制御部１０７で送受信するＴＣＰパケットは、抑制再開制御部１０４からモニタリングされる。さらに、通信制御部１０７は、通常のＴＣＰ処理に加えて、抑制再開制御部１０４からの要求を受けて、ＡＣＫパケットの送信タイミングやパケット内容を変更する。具体的には、通信制御部１０７は、抑制再開制御部１０４から、ＡＣＫ通常送信抑制要求、ＡＣＫ通常送信再開要求、およびＡＣＫ単発送信要求を受けて、それらの要求に対応する。

ＡＣＫ通常送信抑制要求は、通常のＡＣＫパケット送信を抑制させる要求である。通信制御部１０７は、この要求を受けると、以後、ＴＣＰのデータ受信に連動してＡＣＫパケットを送信しなくなる。

ＡＣＫ通常送信再開要求は、ＡＣＫ通常送信抑制要求を解除させる要求である。通信制御部１０７は、この要求を受けると、通常のＴＣＰ処理（ＴＣＰのデータ受信に連動したＡＣＫパケットの送信）を再開する。

ＡＣＫ単発送信要求は、抑制再開制御部１０４から指定されたタイミングで、抑制再開制御部１０４から指定された内容のＡＣＫパケットを送信させる要求である。通信制御部１０７は、この要求を受けると、ＴＣＰのデータ受信タイミングに関係なく、指定された内容のＡＣＫパケットを指定されたタイミングで送信する。なお、この要求は、ＡＣＫ通常送信抑制要求を受けている状態でも有効である（送信可能である）。

通信Ｉ／Ｆ部１０８は、通信制御部１０７より受け取ったデータを無線で送信する処理を行なう。また、無線基地局２０２から受信したデータを通信制御部１０７へ渡す処理を行なう。通信Ｉ／Ｆ部１０８は、電源制御部１０６により電源の投入および切断が行なわれる。

このような携帯型端末２１１が初期状態から通信を開始して終了するまでの各構成要素の動作について、以下、説明する。

初期状態では、携帯型端末２１１の通信Ｉ／Ｆ部１０８の電源は切断されており、通信アプリケーション部１０１は、通信アプリケーションプログラムを実行していない。

通信アプリケーション部１０１は、通信アプリケーションプログラムを起動すると、アプリ要求取得部１０２に対して起動通知を発行する。この起動通知の発行によって、通信アプリケーション部１０１は、通信アプリケーションプログラムの複数の性能パラメータをアプリ要求取得部１０２に引き渡す。アプリ要求取得部１０２は、それらの複数の性能パラメータを受け取ると、それらを性能パラメータ管理テーブルに纏めて保存する。

図６Ａ、図６Ｂおよび図６Ｃは、アプリ要求取得部１０２が管理する性能パラメータ管理テーブルを示す図である。

例えば、アプリ要求取得部１０２は、図６Ａ、図６Ｂおよび図６Ｃに示す３つの性能パラメータ管理テーブル１０２ａ，１０２ｂ，１０２ｃのうち何れか１つを管理する。

性能パラメータ管理テーブル１０２ａ，１０２ｂ，１０２ｃはそれぞれ、起動済みの通信アプリケーションプログラムに対する複数の性能パラメータを有する。その複数の性能パラメータとしては、ストリームタイプ、帯域、および遅延時間のパラメータがある。ここで、ストリームタイプには、帯域重視型、遅延時間重視型、およびベストエフォート型の３つのタイプがある。

大容量のファイルを長時間に一定レートでダウンロードしようとする通信アプリケーションプログラムを実行する通信アプリケーション部１０１は、ストリームタイプ「帯域重視型」を含む複数の性能パラメータをアプリ要求取得部１０２に引き渡す。その結果、アプリ要求取得部１０２は、図６Ａに示すストリームタイプ「帯域重視型」の性能パラメータ管理テーブル１０２ａを保持して管理する。

例えば、この性能パラメータ管理テーブル１０２ａは、図６Ａに示すように、ストリームタイプ「帯域重視型」と、帯域「ＢＷ＝ＢＷｓ［Byte/sec］」とを含む。

また、ＶｏＩＰなどデータの遅延時間の要求の厳しい通信アプリケーションプログラムを実行する通信アプリケーション部１０１は、ストリームタイプ「遅延時間重視型」を含む複数の性能パラメータをアプリ要求取得部１０２に引き渡す。その結果、アプリ要求取得部１０２は、図６Ｂに示すストリームタイプ「遅延時間重視型」の性能パラメータ管理テーブル１０２ｂを保持して管理する。

例えば、この性能パラメータ管理テーブル１０２ｂは、図６Ｂに示すように、ストリームタイプ「遅延時間重視型」と、帯域「ＢＷ＝ＢＷｂ［Byte/sec］」と、遅延時間「ＤＴ＝ＤＴｂ［sec］」とを含む。

また、遅延時間や帯域に対する明確な要求をせずに大容量のファイルをできるだけ早くダウンロードしようとする通信アプリケーションプログラムを実行する通信アプリケーション部１０１は、ストリームタイプ「ベストエフォート型」を示す性能パラメータをアプリ要求取得部１０２に引き渡す。その結果、アプリ要求取得部１０２は、図６Ｃに示すストリームタイプ「ベストエフォート型」の性能パラメータ管理テーブル１０２ｃを保持して管理する。

例えば、この性能パラメータ管理テーブル１０２ｃは、図６Ｃに示すように、ストリームタイプ「ベストエフォート型」のみを性能パラメータとして含む。

アプリ要求取得部１０２は、通信アプリケーション部１０１から起動通知を受けたときには、その起動通知に含まれる性能パラメータの情報をもとに、性能パラメータ管理テーブル１０２ａ，１０２ｂ，１０２ｃの何れか１つを作成する。さらに、アプリ要求取得部１０２は、パラメータ決定部１０３に対して、その性能パラメータ管理テーブルを含む性能パラメータ登録通知を発行する。なお、アプリ要求取得部１０２は、通信アプリケーション部１０１から終了通知を受けたときには、作成された性能パラメータ管理テーブルを削除する。

パラメータ決定部１０３は、性能パラメータ登録通知を受けると、性能パラメータ管理テーブルの内容を読み出し、その内容を元に、間欠受信パラメータを決定する。

パラメータ決定部１０３は、間欠受信パラメータであるサイクル間隔ＴｃとサイクルデータサイズＤｃとを、基本的に、Ｄｃ／Ｔｃ＝ＢＷ（性能パラメータの帯域）を満たすような条件で決定する。なお、サイクルデータサイズＤｃの適切なサイズは、携帯型端末２１１のＴＣＰの条件（ＴＣＰ受信バッファサイズやＭＳＳ（Maximum Segment Size））や通信アプリケーションプログラムの条件（データ送信の単位）などによって変わる。したがって、パラメータ決定部１０３は、これらの条件も加味して間欠受信パラメータを決定する。なお、本実施の形態では、説明を簡単にするため、これらの条件が常に変化しない環境を想定し、パラメータ決定部１０３はこれらの条件に影響されることなく間欠受信パラメータを決定する。

具体的に、パラメータ決定部１０３は、間欠パラメータを決定するためのルールを予め記憶している。

図７は、間欠受信パラメータの決定ルールを示す図である。

パラメータ決定部１０３は、ストリームタイプ「帯域重視型」の性能パラメータ管理テーブルを読み出すと、その性能パラメータ管理テーブルに示される性能パラメータである帯域「ＢＷ＝ＢＷｓ［Byte/sec］」を、間欠受信パラメータを決定するための条件として用いる。つまり、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクルデータサイズＤｃ＝Ｃ１（Ｃ１は定数）に従い、サイクルデータサイズＤｃとしてＣ１［Byte/sec］を決定する。そして、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクル間隔Ｔｃ＝Ｄｃ／ＢＷに従い、サイクル間隔ＴｃとしてＣ１／ＢＷｓ［sec］を決定する。そして、パラメータ決定部１０３は、その決定されたサイクル間隔ＴｃおよびサイクルデータサイズＤｃを示す間欠受信パラメータ管理テーブルを生成する。

つまり、パラメータ決定部１０３は、ストリームタイプ「帯域重視型」の性能パラメータ管理テーブルを読み出すと、最初にサイクルデータサイズＤｃを決定した後、それに合わせてサイクル間隔Ｔｃを決定する。

一方、パラメータ決定部１０３は、ストリームタイプ「遅延時間重視型」の性能パラメータ管理テーブルを読み出すと、その性能パラメータ管理テーブルに示される性能パラメータである帯域「ＢＷ＝ＢＷｂ［Byte/sec］」と遅延時間「ＤＴ＝ＤＴｂ［sec］」とを、間欠受信パラメータを決定するための条件として用いる。つまり、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクル間隔Ｔｃ＝ＤＴ／Ｃ２（Ｃ２は１より大きい定数）に従い、サイクル間隔ＴｃとしてＤＴｂ／Ｃ２［sec］を決定する。なお、Ｃ２が小さいほど、サイクル間隔Ｔｃが長くなり、省電力効果が高まる。そして、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクルデータサイズＤｃ＝ＢＷ×Ｔｃに従い、サイクルデータサイズＤｃとしてＢＷｂ×ＤＴｂ／Ｃ２［Byte］を決定する。そして、パラメータ決定部１０３は、その決定されたサイクル間隔ＴｃおよびサイクルデータサイズＤｃを示す間欠受信パラメータ管理テーブルを生成する。

つまり、パラメータ決定部１０３は、ストリームタイプ「遅延時間重視型」の性能パラメータ管理テーブルを読み出すと、ストリームタイプ「帯域重視型」の場合とは逆に、遅延時間の要件が厳しいので、サイクル間隔Ｔｃを先に決めて、サイクルデータサイズＤｃをそれに合わせて決める。このように、ＶｏＩＰなどの遅延時間重視型の通信アプリケーションプログラムに基づく性能パラメータ管理テーブルの場合には、パラメータ決定部１０３は、性能パラメータの遅延時間ＤＴを使って、「Ｔｃ＜ＤＴ」という条件、即ち、サイクル間隔Ｔｃ＝ＤＴ／Ｃ２を、サイクル間隔Ｔｃの決定ルールとして追加している。

また、パラメータ決定部１０３は、ストリームタイプ「ベストエフォート型」の性能パラメータ管理テーブルを読み出すと、間欠受信パラメータの決定ルールに従い、サイクル間隔ＴｃおよびサイクルデータサイズＤｃを決定しない。つまり、ベストエフォート型については、帯域重視型や遅延時間重視型のような明確な性能要件がないため、パラメータ決定部１０３は、基本的には複雑な間欠受信制御を行わずに通信Ｉ／Ｆ部１０８の電源をＯＮにしたまま一気にデータ転送を完了させるような制御を行う。ただし、ベストエフォート型に対しても間欠受信を行うことは可能である。

図８は、パラメータ決定部１０３によって生成された間欠受信パラメータ管理テーブルの一例を示す図である。

パラメータ決定部１０３は、ストリームタイプ「帯域重視型」の性能パラメータ管理テーブルを読み出すと、例えば、間欠受信パラメータであるサイクル間隔ＴｃとしてＣ１／ＢＷｓ［sec］と、間欠受信パラメータであるサイクルデータサイズとしてＣ１［Byte］とを示す間欠受信パラメータ管理テーブルを生成する。

パラメータ決定部１０３は、性能パラメータ登録通知を受けるごとに、上記の手順で間欠受信パラメータ管理テーブルを生成する。そして、パラメータ決定部１０３は、生成後、抑制再開制御部１０４に対して間欠受信パラメータ登録通知を発行する。

抑制再開制御部１０４は、間欠受信パラメータ登録通知を受けると、間欠受信パラメータ管理テーブルの内容を読み出して、その内容に基づき、電源制御部１０６への投入要求の発行と、通信制御部１０７で送受信されるＴＣＰパケットのモニタリングの開始と、通信制御部１０７に対するＡＣＫ通常送信再開要求の発行とを行ない、間欠受信の準備状態に入る。この処理に連動して、電源制御部１０６は通信Ｉ／Ｆ部１０８に電源の投入を指示する。その結果、通信Ｉ／Ｆ部１０８の電源が投入される。

以下、本実施の形態における間欠受信の準備状態の処理について説明する。

通信アプリケーション部１０１は、通信アプリケーションプログラム起動時の処理を行なった後、送信側装置２０３との接続を確立し、送信側装置２０３からのデータ受信を開始する。

通信制御部１０７では、通信アプリケーション部１０１からの接続要求を受けて、無線基地局２０２との間のネゴシエーション処理、および、送信側装置２０３とのＴＣＰコネクションの確立などの処理を行なう。ＴＣＰコネクションの確立後、携帯型端末２１１と送信側装置２０３の間のデータは、無線基地局２０２および通信Ｉ／Ｆ部１０８を介して送受信され、ＴＣＰパケットの送受信処理は、通信制御部１０７で行なわれる。

抑制再開制御部１０４は、通信制御部１０７で受信されるＴＣＰパケットをモニタリングし、受信データの帯域（受信帯域）が、間欠受信パラメータ管理テーブルに設定されている帯域（設定帯域ＢＷ＝Ｄｃ／Ｔｃ）に到達するのを待つ。例えば、抑制再開制御部１０４は、サイクル間隔Ｔｃの経過ごとに、そのサイクル間隔Ｔｃの間に受信したＴＣＰパケットのデータサイズを合計することで、合計データサイズＴｌＤを算出する。そして、抑制再開制御部１０４は、「ＴｌＤ／Ｔｃ≧ＢＷ」の条件を満たす回数が所定回数以上だけ続いたときに、受信帯域が設定帯域ＢＷに到達したと見なす。

抑制再開制御部１０４は、受信帯域が設定帯域ＢＷに到達すると、送信側装置２０３からの送信を抑制するために、通信制御部１０７に対してＡＣＫ通常送信抑制要求を発行する。なお、この発行は、間欠受信の１回目の処理に相当する。このとき、抑制再開制御部１０４は、通信制御部１０７からそれまでに送信した最後のＡＣＫパケットの情報、すなわち、ＡＣＫ番号（ＬＡＳＴ＿ＡＣＫＮＯ）と受信ウィンドウ（ＬＡＳＴ＿ＲＷＩＮ）とを保持しておく。通信制御部１０７は、抑制再開制御部１０４からＡＣＫ通常送信抑制要求を受けると、以後、ＴＣＰのデータ受信は続けるものの、受信時にＡＣＫパケットを送信しないようにする。

一方、送信側装置２０３は、携帯型端末２１１からＡＣＫパケットが送られてこなくなっても、自身の管理する送信可能なデータサイズ（ｕｗｎｄ）が０になるまで、データ送信を続け、ｕｗｎｄが０になった時点で、データ送信を終了する。その結果、送信側装置２０３は送信抑制期間に入る。

抑制再開制御部１０４は、ＡＣＫ通常送信抑制要求の発行後もＴＣＰパケットをモニタリングし、送信側装置２０３での送信可能なデータサイズ（ｕｗｎｄ）が０になるのを待つ。具体的には、抑制再開制御部１０４は、受信したＴＣＰパケットのシーケンス番号とデータサイズを参照し、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）に達するのを待つ。

抑制再開制御部１０４は、ｕｗｎｄが０になったと判断したら、電源制御部１０６へ切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

抑制再開制御部１０４は、電源制御部１０６へ切断要求を発行した後、所定時間の満了を待つ。この所定時間は、サイクル間隔Ｔｃと一致していてもよいし、異なる時間であっても良い。送信側装置２０３は、既に送信抑制期間に入っているので、通信Ｉ／Ｆ部１０８の電源が切断されている間、データ送信を行なわない。

所定時間が満了したとき、抑制再開制御部１０４は、電源制御部１０６へ投入要求を発行する。さらに、抑制再開制御部１０４は、間欠受信の準備状態が満了したと見なし、定常状態に遷移する。電源制御部１０６は投入要求を受けると、通信Ｉ／Ｆ部１０８の電源を投入する。

以下、本実施の形態における定常状態の処理について説明する。

図９は、本実施の形態における携帯型端末２１１と送信側装置２０３の定常状態での動作を示すシーケンス図である。

定常状態での１サイクル分の動作は、送信再開処理と、送信抑制期間の開始処理と、送信抑制期間の終了処理との３つのステップに分けられる。

送信再開処理（ステップ１）では、抑制再開制御部１０４は、送信側装置２０３からのデータ送信を再開させるため、通信制御部１０７に対してＡＣＫ単発送信要求を発行する。このとき、抑制再開制御部１０４は、ＡＣＫパケットの受信ウィンドウ（ＲＷＩＮ）として、間欠受信パラメータ管理テーブルに格納されたサイクルデータサイズＤｃを指定する。通信制御部１０７は、時刻Ｔ１に、ＡＣＫ単発送信要求を受け取ると、ＲＷＩＮ＝ＤｃのＡＣＫパケットＰ１を通信Ｉ／Ｆ部１０８を介して送信する。また、抑制再開制御部１０４は、送信したＡＣＫパケットＰ１のＡＣＫ番号を保持しておく。

一方、送信側装置２０３は、携帯型端末２１１からのＡＣＫパケットＰ１（ＲＷＩＮ＝Ｄｃ）を受信すると、間欠受信の準備状態、または、送信抑制期間が終了し、データ送信が可能な状態になる。その結果、送信側装置２０３は、携帯型端末２１１あてのＴＣＰパケット（データＰ２）の送信を再開する。

携帯型端末２１１の抑制再開制御部１０４は、間欠受信の準備状態でＡＣＫ通常送信抑制要求を発行しているので、通常のＡＣＫパケットの送信、つまりデータ受信に連動したＡＣＫパケットの送信は既に抑制されている。すなわち、通信制御部１０７は、送信側装置２０３からのデータＰ２を受信して、そのデータを通信アプリケーション部１０１に引渡しても、送信側装置２０３に対してＡＣＫパケットを送信しない。そのため、間欠受信の１サイクル（サイクル間隔Ｔｃ）において、送信側装置２０３から受信されるデータＰ２のサイズは、サイクルデータサイズＤｃに制限される。

送信抑制期間の開始処理（ステップ２）では、抑制再開制御部１０４は、時刻Ｔ１以降、通信制御部１０７で受信されるＴＣＰパケットをモニタリングする。そして、抑制再開制御部１０４は、時刻Ｔ１以降で受信されたデータサイズがサイクルデータサイズＤｃに到達したかどうか、すなわち、送信側装置２０３の送信可能なデータサイズ（ｕｗｎｄ）が０になったかどうかを確認し続ける。このとき抑制再開制御部１０４は、間欠受信の準備状態での確認処理と同じく、最後に送信したＡＣＫパケットのＡＣＫ番号と受信ウィンドウ（ＲＷＩＮ＝Ｄｃ）を使って上述の確認を行う。時刻Ｔ１以降で受信したデータサイズがサイクルデータサイズＤｃに到達したとき、即ち時刻Ｔ２で、抑制再開制御部１０４は、送信抑制期間が開始したとみなし、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

送信抑制期間の終了処理（ステップ３）では、本発明の実施の形態における携帯型端末２１１は、時刻Ｔ１を起点として、サイクル間隔Ｔｃの時間経過後の時刻Ｔ３を、送信抑制期間の終了点と見なす。つまり、抑制再開制御部１０４は、タイマにより時刻Ｔ３を検出し、電源制御部１０６に投入要求を発行する。その投入要求により、電源制御部１０６は時刻Ｔ３に通信Ｉ／Ｆ部１０８の電源を投入する。

携帯型端末２１１は、定常状態では、上記３つのステップを１サイクルとして、繰り返し実行する。

通信アプリケーション部１０１は、通信アプリケーションプログラムを終了するときには、通信制御部１０７に対して送信側装置２０３とのコネクションの切断を要求し、アプリ要求取得部１０２に対して終了通知を発行する。

通信制御部１０７は、通信アプリケーション部１０１によるコネクション切断の要求により、ＴＣＰのコネクションを切断する。

アプリ要求取得部１０２は、終了通知を受け付けると、性能パラメータ管理テーブルの内容をクリアし、パラメータ決定部１０３に対して性能パラメータ削除通知を発行する。

パラメータ決定部１０３では、性能パラメータ削除通知を受けると、間欠パラメータ管理テーブルの内容をクリアし、抑制再開制御部１０４に対して間欠受信パラメータ削除通知を発行する。

抑制再開制御部１０４は、間欠受信パラメータ削除通知を受けると、通信制御部１０７で送受信されるＴＣＰパケットのモニタリングを停止し、さらに、電源制御部１０６への切断要求の発行を行なう。

電源制御部１０６は、抑制再開制御部１０４の処理（切断要求の発行）に連動して、通信Ｉ／Ｆ部１０８の電源を切断する。

以上の処理により、携帯型端末２１１の状態は初期状態に戻る。

図１０は、本実施の形態おける携帯型端末２１１の動作を示すフローチャートである。

まず、本実施の形態の携帯型端末２１１は、送信側装置２０３に対してＲＷＩＮ＝ＤｃのＡＣＫパケットを送信する（ステップＳ１０）。このとき、携帯型端末２１１の抑制再開制御部１０４は、通信Ｉ／Ｆ部１０８への電源投入のタイミングを特定するために、タイマによる計時を開始する。

そして、携帯型端末２１１は、そのＡＣＫパケットに対して送信側装置２０３から送信されたサイクルデータサイズＤｃ分のデータ（ＴＣＰパケット）を受信する（ステップＳ１２）。このとき、本実施の形態の携帯型端末２１１は、受信したデータに対して通常行われるＡＣＫパケットの送信を停止することで、送信側装置２０３からのデータの送信を抑制している。

そして、携帯型端末２１１は、ステップＳ１２でサイクルデータサイズＤｃ分の全てのデータを受信すると、通信Ｉ／Ｆ部１０８の電源を切断する（ステップＳ１４）。

携帯型端末２１１は、通信Ｉ／Ｆ部１０８の電源を切断すると、上述のタイマに基づいて、ステップＳ１０でのＡＣＫパケットの送信時からサイクル間隔Ｔｃが経過したか否かを判別する（ステップＳ１６）。

ここで、携帯型端末２１１は、サイクル間隔Ｔｃが経過していないと判別したときには（ステップＳ１６のＮｏ）、ステップＳ１４からの処理を繰り返し、サイクル間隔Ｔｃが経過したと判別したときには（ステップＳ１６のＹｅｓ）、通信Ｉ／Ｆ部１０８の電源を投入する（ステップＳ１８）。

そして、携帯型端末２１１は、送信側装置２０３との通信を終了すべきか否かを判別し（ステップＳ２０）、終了すべきと判別したときには（ステップＳ２０のＹｅｓ）、全ての処理を終了する。また、携帯型端末２１１は、終了すべきでないと判別したときには（ステップＳ２０のＮｏ）、ステップＳ１０からの処理を繰り返し実行する。このようなステップＳ１０〜Ｓ２０の処理によって、間欠受信の１サイクルが実行さる。

以上のように、本実施の形態に係る携帯型端末２１１は、無線ＬＡＮの省電力方法に依存せず、例えばＴＣＰなどのフロー制御機構を持つプロトコルを使って、送信側装置２０３との間で通信を行いながら省電力化を行なう。そのため、本実施の形態では、アクセスポイントでの省電力機能のサポート状況やネットワークデバイスの種類にも関係なく、携帯型端末２１１の省電力化を図ることができる。

また、本実施の形態では、無線ＬＡＮの省電力方法に依存しないので、携帯型端末２１１のデータの受信タイミングをビーコン送信タイミングに連動させる必要がない。そのため、遅延時間と帯域を確保した通信を続けながら、同時に省電力能力を向上することができる。

さらに、本実施の形態では、送信側装置２０３からのデータ到着が無い期間を積極的に作ったうえで、携帯型端末２１１の電源を切断するので、ジッタが発生しても送信側装置２０３と携帯型端末２１１との間のデータ溢れの発生を防ぐことができる。

なお、本実施の形態では、携帯型端末２１１はＴＣＰのプロトコルに従って動作したが、そのプロトコルはＴＣＰ以外のプロトコルであっても、フロー制御機構を持つプロトコルであればよく、既存のフロー制御付きプロトコルであってもよい。すなわち、本実施の形態を実現するために、送信側装置と携帯型端末の両方で新たなプロトコルを追加する必要はなく、携帯型端末に本発明の省電力方法に対応する処理部を追加するだけで実現できる。

ここで、本発明について実施の形態１を用いて説明したが、実施の形態１を変形しても本発明を実施することができる。

例えば、実施の形態１では、送信側装置２０３からのデータ送信の抑制方法として、「携帯型端末２１１からＡＣＫパケットを送信しない」という方法を説明したが、データ送信の抑制方法はこれに限定されるものではない。例えば、携帯型端末２１１は、受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットを送信側装置２０３に送ることで、明示的に送信側装置２０３からのデータ送信を抑制してもよい。

図１１は、受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットが送信される動作を示すシーケンス図である。

例えば、携帯型端末２１１の通信制御部１０７は、図１１に示すように、送信側装置２０３からのデータＰ２を受信して、そのデータを通信アプリケーション部１０１に引渡すと、時刻Ｔ２に、送信側装置２０３に対して受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットＰ３を送信する。このようなＡＣＫパケットＰ３を送信した場合にも、送信側装置２０３から受信するデータＰ２のサイズをサイクルデータサイズＤｃに制限して、送信側装置２０３からのデータ送信を抑制することができる。

このように受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットを送信するような抑制方法の場合には、ＴＣＰの制御方法に従って動作する送信側装置２０３での再送処理を予防することができる。つまり、図９に示す、ＡＣＫパケットを送信しないような抑制方法の場合には、送信側装置２０３にはＡＣＫパケットが全く届かないので、送信側装置２０３は、ＴＣＰの制御方法に従って、タイムアウトによりパケットロスが発生したと判断してデータを再送してしまうケースがある。このとき、送信側装置２０３の送信可能データ（輻輳ウィンドウと呼ばれる）が１パケット分（上述のＭＳＳ）低下するという弊害もある。ところが、図１１に示すように、ＲＷＩＮ＝０のＡＣＫパケットを送信するような抑制方法では、送信側装置２０３は、ＡＣＫパケットを受け取るため、タイムアウトを止めることができる。なお、携帯型端末２１１は、ＲＷＩＮ＝０のＡＣＫパケットを、ｕｗｎｄ＝０となる時刻Ｔ２に送っても良いし、時刻Ｔ２以降で且つ送信側装置２０３でタイムアウトが発生する前であれば任意のタイミングで送っても良い。また、携帯型端末２１１は、ＲＷＩＮ＝０のＡＣＫパケットを、定常状態だけでなく、間欠受信の準備状態に送っても良い。

また、携帯型端末２１１は、送信側装置２０３からのデータ送信を抑制するため、ＲＷＩＮ＝０以外のＡＣＫパケットを送ってもよい。つまり、送信側装置２０３から送信されるデータのサイズがサイクルデータサイズＤｃ（送信再開を指示するＡＣＫパケットのＲＷＩＮで指定されたサイズ）以下になるのであれば、携帯型端末２１１はどのようなＡＣＫパケットを送信してもよい。したがって、携帯型端末２１１は、「Ｄｃ−（時刻Ｔ１以降で受信したデータのサイズ）」を越えない値をＲＷＩＮに設定して、ＡＣＫパケットを送信してもよい。

また、本発明における携帯型端末２１１が搭載する無線通信デバイスは、無線ＬＡＮ（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ）のデバイスの他、任意の無線通信デバイスであってもよい。

さらに、実施の形態１では、携帯型端末２１１が通信Ｉ／Ｆ部１０８として無線通信デバイスを搭載したネットワーク構成を想定していたが、本発明の携帯型端末は通信Ｉ／Ｆの種類に限定されるものではない。例えば、無線ＬＡＮ以外の無線Ｉ／Ｆや有線の通信Ｉ／Ｆを使ってもよい。なお、有線の通信Ｉ／Ｆを使う場合は、ネットワーク構成として無線基地局２０２が不要になり、代わりに有線のルータなどの装置が必要となる。また、実施の形態１では、アクセスポイント（無線基地局２０２）の存在する無線ＬＡＮのネットワーク構成を想定していたが、アクセスポイントの無いアドホックモードでの環境を想定してもよい。その場合、送信側装置２０３と携帯型端末２１１はインターネット２０４を経由せず、無線ＬＡＮで直接接続される。

また、フロー制御付きのプロトコルとしてＴＣＰを中心に説明したが、本発明に使用されるプロトコルはＴＣＰに限定されるわけではない。本発明に使用されるプロトコルは、フロー制御の機能を持っていれば他のプロトコルでもよく、例えば、アプリケーション層でフロー制御を実現して、そのフロー制御でＴＣＰと同様の送信抑制および送信再開の制御を行なうことで省電力制御を行なってもよい。また、携帯型端末が送信側装置と直接接続される場合は、送信側装置と携帯型端末との間のデータリンク層でのフロー制御を使って省電力制御を行なってもよい。また、フロー制御は、携帯型端末２１１と送信側装置２０３の間に限定されるわけではない。例えば、中継装置と携帯型端末の間でフロー制御を行なうプロトコルがあれば、そのフロー制御を同様に利用して省電力制御を行なってもよい。

また、本発明では、送信抑制期間に通信Ｉ／Ｆ部１０８の電源を切断または投入する方法は、どのような方法であってもよい。例えば、本発明を無線ＬＡＮのパワーセーブモードの処理と連動させて、本発明での電源切断のタイミングでパワーセーブモードたるドーズモードへの移行を行なっても良い。また、電源切断のタイミングは、送信抑制期間の間であれば任意のタイミングでよい。

また、実施の形態１では、単純化のため、通信アプリケーション部１０１で同時動作する通信アプリケーションプログラムを１つに限定したが、本発明の省電力方法は通信アプリケーションプログラムの数に依存しない。複数の通信アプリケーションプログラムが同時に動作する環境でも、例えば、複数の通信アプリケーションプログラムの間欠受信のタイミングを統合して、同様のフロー制御に基づく電力制御を行なっても良い。

また、アプリ要求取得部１０２における性能パラメータの取得方法は、本発明の本質ではない。したがって、アプリ要求取得部１０２は、なんらかの方法で性能パラメータを取得できればよく、その取得方法は実施の形態１の手順に限定されるものではない。例えば、実施の形態１では、アプリ要求取得部１０２は、通信アプリケーション部１０１から性能パラメータを直接取得したが、自立的に性能パラメータを取得してもよい。つまり、アプリ要求取得部１０２は、データ送受信のパケットを解析したり、ＯＳ（Operating System）上で通信アプリケーションプログラムの起動および終了のタイミングを監視したりすることで、性能パラメータを取得する。

例えば、省電力の制御を行なっていないとき、つまり通信Ｉ／Ｆ部１０８の電源が常に投入されているときにおける、携帯型端末２１１と送信側装置２０３とのデータ送受信の帯域および遅延時間の少なくとも一方が、通信アプリケーションプログラムとしての性能要件に一致している。このような場合には、アプリ要求取得部１０２は、省電力制御が行われていない状態で、通信制御部１０７のデータ送受信のパケットをモニタリングして帯域および遅延時間の少なくとも一方を推定し、その推定値を性能パラメータとして使う。これにより、アプリ要求取得部１０２はパケット解析により自立的に性能パラメータを取得する。

また、実施の形態１では、通信アプリケーションプログラムの起動および終了のタイミングを取得して、通信アプリケーションの起動中は性能パラメータを常に固定値として扱ったが、性能パラメータを動的に変化させてもよい。

また、実施の形態１では、図７に示す決定ルールに基づいて間欠受信パラメータを決定したが、他のルールに基づいて間欠受信パラメータ（サイクル間隔およびサイクルデータサイズ）を決めてもよい。また、間欠受信パラメータを固定させておく必要はなく、動的に変化させてもよい。即ち、サイクル間隔ＴｃやサイクルデータサイズＤｃの値を一定期間ごとに変化させてもよいし、毎回異なる値に変化させてもよい。また、性能パラメータに関しても同様であって、実施の形態１では、図６Ａ、図６Ｂおよび図６Ｃに示す性能パラメータを用いたが、これらの性能パラメータ以外のパラメータを用いてもよい。例えば、実施の形態１では、ストリームタイプを３種類に分類しているが、２種類や４種類以上に分類してもよく、他の種別のストリームタイプに分類してもよい。さらに、実施の形態１では、これらのストリームタイプに応じて、間欠受信パラメータの決定ルールを異ならせたが、これらのストリームタイプに関わらず、常に一定のルールに基づいて間欠受信パラメータを決定してもよい。

また、実施の形態１では、通信開始から測定した帯域が設定帯域ＢＷに到達するまでの間は「間欠受信の準備状態」として電源を常にＯＮにしていたが、この期間においても間欠受信による省電力制御を行ってもよい。ただし、この期間では送信側装置２０３においてはＴＣＰのスロースタート制御が行われるため、ウィンドウサイズがＲＴＴ（Round Trip Time）の経過毎に１ＭＳＳ，２ＭＳＳ，４ＭＳＳというように増加していく。なお、ＲＴＴは、ＡＣＫパケットが送信されてからそれに対応するデータが受信されるまでの時間であり、ＭＳＳは、１パケットに含まれるＴＣＰデータの最大サイズである。このため、抑制再開制御部１０４は、これに合わせて制御を行う必要がある。具体的には、抑制再開制御部１０４は、最初のデータパケットが受信されると、通信Ｉ／Ｆ部１０８の電源を切断させる。一定期間後、抑制再開制御部１０４は、通信Ｉ／Ｆ部１０８の電源を再投入させ、ＡＣＫパケット（ＲＷＩＮ＝２×ＭＳＳ）を送信させ、２つのデータパケットが受信された時点で通信Ｉ／Ｆ部１０８の電源を切断させる。さらに、抑制再開制御部１０４は、一定期間後、通信Ｉ／Ｆ部１０８の電源を再投入させ、ＡＣＫパケット（ＲＷＩＮ＝４×ＭＳＳ）を送信させ、４つのデータパケットが受信された時点で通信Ｉ／Ｆ部１０８の電源を切断させる。なお、上述のデータパケットは、送信側装置から受信側装置にＴＣＰにより送信されるパケットであって、このデータパケットとＡＣＫパケットとを総称してＴＣＰパケットという。

このように、抑制再開制御部１０４は、間欠受信サイクルごとに、通知する受信ウィンドウ（ＲＷＩＮ）のサイズを倍々にしていく。ただし、送信側装置２０３ではあるタイミングでスロースタート制御が終了し、それ以降はＡＣＫパケット受信によるウィンドウサイズの上昇が小さくなる。抑制再開制御部１０４はこれをタイムアウトなどにより検知し、それ以降はＡＣＫパケットにより通知する受信ウィンドウを少しずつ上昇させる制御に移行する。このような制御により、通知する受信ウィンドウがサイクルデータサイズＤｃに達した時点で、抑制再開制御部１０４は前述の定常状態の処理を開始する。

（実施の形態２）
本発明の実施の形態２に係る通信装置について説明する。実施の形態１では、送信側装置２０３からのデータ送信が無い送信抑制期間にのみ、通信Ｉ／Ｆ部１０８の電源を切断したが、本実施の形態では、別の期間にも通信Ｉ／Ｆ部１０８の電源を切断して、省電力効果をさらに向上する。具体的には、携帯型端末が送信再開の指示を出してから、実際に送信側装置２０３からのデータが到着するまでの期間も、通信Ｉ／Ｆ部１０８の電源が切断される。

なお、本実施の形態において、実施の形態１と同様の機器および構成については、同一の参照符号を付して説明を省略する。本実施の形態に係る通信システムのネットワーク構成は、実施の形態１の図３に示す通信システムのネットワーク構成と同じであるため、説明を省略する。

図１２は、本実施の形態における携帯型端末の具体的な構成を示す構成図である。

本実施の形態における携帯型端末２１１ａは、通信アプリケーション部１０１と、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部８０４と、電源制御部１０６と、通信制御部１０７と、通信Ｉ／Ｆ部１０８と、ＲＴＴ推定部８０９とを備える。つまり、本実施の形態における携帯型端末２１１ａは、実施の形態１の携帯型端末２１１の抑制再開制御部１０４の代わりに、抑制再開制御部８０４を備えるとともに、実施の形態１の携帯型端末２１１にはないＲＴＴ推定部８０９を備えている。

ＲＴＴ推定部８０９は、フロー制御付きプロトコル上でのＲＴＴを推定する。なお、ＲＴＴは、携帯型端末２１１ａと送信側装置２０３の間のパケットの往復時間に相当する。ＲＴＴ推定部８０９は、通信制御部１０７における送受信パケットをモニタリングして、ＲＴＴの最短値を推定し、その結果を抑制再開制御部８０４に送る。例えば、ＲＴＴ推定部８０９は、通信制御部１０７のモニタリングにより、携帯型端末２１１ａと送信側装置２０３との間で往復するパケットの組の往復時間を、その組ごとに所定回数だけ測定し、その中で最短の往復時間をＲＴＴの最短値とする。

ここで、携帯型端末２１１ａと送信側装置２０３との間で往復するパケットの組とは、携帯型端末２１１ａから送信されるパケットと、その送信に対して送信側装置２０３が応答して送信するパケットとの組であれば、どのようなパケットの組でも良い。例えば、図９に示すように、時刻Ｔ１で携帯型端末２１１ａが送信するＡＣＫパケットＰ１（受信ウィンドウ＞０）と、それに対して送信側装置２０３から送信される最初のデータパケットＰ２との組であってもよい。なお、ＲＴＴの最短値の推定方法は、本発明の省電力方法の本質に関わるものではないので、上述の方法に限定されるものではなく、他の方法であってもよい。

抑制再開制御部８０４は、実施の形態１の抑制再開制御部１０４の機能を有するとともに、ＲＷＩＮ＞０のＡＣＫパケットが送信されてから、ＲＴＴ推定部８０９で推定されたＲＴＴ（以下、ＲＴＴ推定値という）が経過するまでの期間にも、通信Ｉ／Ｆ部１０８の電源を切断するように指示する。具体的には、抑制再開制御部８０４は、ＲＴＴ推定部８０９からＲＴＴ推定値を取得する。さらに、抑制再開制御部８０４は、ＡＣＫパケット（ＲＷＩＮ＞０）の送信後のタイミングに、電源制御部１０６に対して切断要求を発行し、ＡＣＫパケット（ＲＷＩＮ＞０）の送信直後からＲＴＴ推定値が経過するタイミングに、電源制御部１０６に対して投入要求を発行する。

また、抑制再開制御部８０４は、抑制再開制御部１０４と同様の処理を行なうことで、送信抑制期間にも、通信Ｉ／Ｆ部１０８の電源のＯＮ／ＯＦＦを行なう。

図１３は、本実施の形態に係る携帯型端末２１１ａと送信側装置２０３の省電力方法を示すシーケンス図である。

図１３において、携帯型端末２１１ａが送信再開の指示を出してから、実際に送信側装置２０３からのデータが到着するまでの期間は、時刻Ｔ１１から時刻Ｔ１２の期間に対応する。この期間では、実施の形態１で説明した送信抑制期間と同様、送信側装置２０３からのデータ送信が無い期間なので、通信Ｉ／Ｆ部１０８の電源を切断しても問題ないはずである。

そこで、本実施の形態に係る省電力方法を適用する携帯型端末２１１ａは、ＡＣＫパケットＰ１（ＲＷＩＮ＝Ｄｃ）を送信する間、つまり時刻Ｔ１０〜時刻Ｔ１１の期間だけ通信Ｉ／Ｆ部１０８の電源を投入し、その後、時刻Ｔ１２まで通信Ｉ／Ｆ部１０８の電源を切断する。時刻Ｔ１１〜時刻Ｔ１２の時間は、上述のようにＲＴＴ推定部８０９によって推定されたＲＴＴ推定値に相当する。携帯型端末２１１ａは、送信側装置２０３からのデータを受信している期間、つまり時刻Ｔ１２〜時刻Ｔ１３の期間には、電源を再投入し、その後の時刻Ｔ１３〜時刻Ｔ２０の送信抑制期間には、実施の形態１と同様、電源を切断する。

なお、抑制再開制御部８０４は、ＡＣＫパケット（ＲＷＩＮ＞０）の送信後に、電源制御部１０６に対して切断要求を発行するが、その送信の時刻Ｔ１１以降のタイミングであれば任意のタイミングで発行してもよい。また、抑制再開制御部８０４は、ＡＣＫパケット（ＲＷＩＮ＞０）の送信直後からＲＴＴ推定値が経過するタイミングに、電源制御部１０６に対して投入要求を発行するが、時刻Ｔ１２以前であれば任意のタイミングで発行してもよい。特に、投入要求のタイミングに関してはＲＴＴ推定値が実際の最小ＲＴＴ値より短い場合も考慮し、一定時間だけ早めに投入要求を発行すること、もしくは、測定したＲＴＴ値の平均や、分散、サンプル数などの統計値に基づいて計算された値分だけ早めに投入要求を発行することも有効である。

また、本実施の形態では、ベストエフォート型であっても、ＡＣＫパケット（ＲＷＩＮ＞０）が送信されてからＲＴＴが経過するまでの間に電源をＯＦＦすることで省電力化を図ることができる。

ここで、ベストエフォート型の通信では間欠受信は行われない。これは、ベストエフォート型の通信アプリケーションプログラムでは、途切れなくデータ転送を行うことを前提としているからである。即ち、送信側装置２０３は、リアルタイムに送信データを生成しないため保持しているデータを連続的に送信でき、受信側装置は全てのデータを保存するメモリを保持するためデータを連続的に受信できる。したがって、ベストエフォート型の通信では、送信抑制期間がないため、途切れなくデータ転送が行われ、その分データ全体の受信完了までの期間が短くなる。ところが、実施の形態１では、送信抑制期間をなくすと、電源をＯＦＦにすることができないため、消費電力を削減することができない。また、この場合、一定のサイズのデータを転送するのに必要な消費電力は総転送データ量で決まってしまう。

しかし、本実施の形態では、携帯型端末２１１ａが送信再開の指示を出してから、実際に送信側装置２０３からのデータが到着するまでの期間に、携帯型端末２１１ａは通信Ｉ／Ｆ部１０８の電源を切断するため、ベストエフォート型の通信においても、データ転送レートを落とさずに省電力化を図ることができる。なお、この場合、間欠受信パラメータであるサイクルデータサイズＤｃを、パケットロスの発生しないできるだけ大きな値とすることが望ましい。また、携帯型端末２１１ａは、間欠受信パラメータであるサイクル間隔Ｔｃを規定せずに、送信側装置２０３からサイクルデータサイズＤｃ分のパケットを受け取ると、即座に次のサイクルでのＡＣＫパケット（ＲＷＩＮ＝Ｄｃ）を送信すればよい。

このように、本実施の形態では、実施の形態１での省電力方法に対して、通信Ｉ／Ｆ部１０８の電源を切断する期間を追加することで、さらに省電力効果を向上させることができる。

（実施の形態３）
次に、本発明の実施の形態３に係る通信装置について説明する。本実施の形態に係る通信装置は、パケットロスが発生したときにも、通信品質と省電力効果の向上を両立して行うことができる。

実施の形態１では、抑制再開制御部１０４は、受信したＴＣＰパケットのシーケンス番号とデータサイズを参照し、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）に到達したことによって、送信側装置２０３が送信抑制期間に入ったことを検知し、通信Ｉ／Ｆ部１０８の電源を切断させていた。

しかし、このような制御は、以下の２つの条件が成り立っている状況においてのみ正しく行われる。

第１の条件は、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）となるまでパケットを受信側装置が受信できることである。

第２の条件は、受信側装置が通知した受信ウィンドウ（ＲＷＩＮ）分だけ送信側装置２０３が送信可能であることである。

実際、第１の条件は、パケットロスが発生した場合には保証されない。パケットロスは様々な原因により発生する。例えば、電波状況が悪い無線区間にパケットロスが発生する。または、中継ルータや無線アクセスポイントなどの中継装置において他のフローと競合することによる中継装置内のバッファ溢れによってパケットロスが発生する。または、受信側装置で処理可能レートを越えるトラフィックを受信した場合の受信装置内のバッファ溢れによってパケットロスが発生する。

また、第２の条件も、パケットロスが発生した場合には保証されないことがある。パケットロスが発生すると、ＴＣＰに従って処理を行なう送信側装置２０３はパケットロスをネットワークの輻輳を示す情報と解釈し、輻輳制御を目的として管理している輻輳ウィンドウ（以下、ＣＷＩＮと呼ぶ）を小さくする。実際の送信側装置２０３からのデータの送信量は、通知されたＲＷＩＮとＣＷＩＮの小さい方を上限として制限される。したがって、受信側装置から通知されたＲＷＩＮよりもＣＷＩＮが小さくなる状況がパケットロスにより引き起こされると、送信側装置２０３はＲＷＩＮ分のパケットを送信できなくなる。

なお、ＴＣＰに従って処理を行なう送信側装置２０３は、通常、以下の２つの方法によってパケットロスを検知する。

第１のロス検知方法では、送信側装置２０３は、送信したパケットに対するＡＣＫパケットが一定時間（再送タイムアウト時間と呼ばれる）経過後も受信されなかった場合に、パケットロスを検知する。この場合、送信側装置２０３は、ＣＷＩＮを１まで減少させ、その後、ロスされたパケットを再送パケットとして送信する。

第２のロス検知方法では、送信側装置２０３は、同一のＡＣＫ番号を持つ複数（通常４つ）のＡＣＫパケットを受信した場合に、パケットロスを検知する。この場合、送信側装置２０３は、即座に再送パケットを送信し、再送パケットに対するＡＣＫパケットを受信した後は、ＣＷＩＮをパケットロス検知前のＣＷＩＮの半分にする。

図１４は、本実施の形態における携帯型端末の具体的な構成を示す構成図である。

本実施の形態の携帯型端末２１１ｂは、通信アプリケーション部１０１と、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部９０４と、電源制御部１０６と、通信制御部１０７と、通信Ｉ／Ｆ部１０８とを備える。つまり、本実施の形態における携帯型端末２１１ｂは、実施の形態１の携帯型端末２１１の抑制再開制御部１０４の代わりに、抑制再開制御部９０４を備える。なお、本実施の形態において実施の形態１と同様の機器および構成については、同一の参照符号を付して説明を省略する。

抑制再開制御部９０４は、実施の形態１の抑制再開制御部１０４と同様の機能を有するとともに、パケットロスを検知して、そのロスしたパケットが再送パケットとして再送されるように通信制御部１０７を制御する。さらに、抑制再開制御部９０４は、パケットロスが発生した後の送信側装置２０３のＣＷＩＮを推定して、その推定されたＣＷＩＮにおいても実施の形態１と同様の間欠受信と省電力制御とを行なえるように通信制御部１０７を制御する。

以下、パケットロスが発生した時の本実施の形態の動作について詳細に説明する。なお、パケットロスが発生していない状況での動作については実施の形態１と同様となるため、ここでは説明を省略する。

図１５は、本実施の形態における携帯型端末２１１ｂの動作を示すフローチャートである。

まず、携帯型端末２１１ｂは、実施の形態１の図９に示す処理動作と同様の定常状態の処理、即ち１サイクルごとにサイクルデータサイズＤｃのデータを転送しつつ電源のＯＮ／ＯＦＦ制御（省電力制御）を行う（ステップＳ３０１）。さらに、携帯型端末２１１ｂは、パケットロスの検知処理を行う（ステップＳ３０２）。ここで、携帯型端末２１１ｂは、その検知処理の結果に基づいてパケットロスがあったか否かを判別する（ステップＳ３０３）。

携帯型端末２１１ｂは、パケットロスがなかったと判別したときには（ステップＳ３０３のＮｏ）、例えば、定常状態処理を終了すべきか否かをさらに判別する（ステップＳ３０８）。そして、携帯型端末２１１ｂは、終了すべきと判別したときには（ステップＳ３０８のＹｅｓ）、定常状態処理を終了し、終了すべきでないと判別したときには（ステップＳ３０８のＮｏ）、ステップＳ３０１からの処理を繰り返す。

一方、携帯型端末２１１ｂは、パケットロスがあったと判別したときには（ステップＳ３０３のＹｅｓ）、まず、送信側装置２０３にロスしたパケットを再送させるための再送誘発処理を実施する（ステップＳ３０４）。

このとき、携帯型端末２１１ｂは、この再送誘発処理によって再送されたパケットを受信し、そのパケットを受信したことをＡＣＫパケットにより送信側装置２０３に通知する。送信側装置２０３は、そのＡＣＫパケットによる通知を受けると、ＴＣＰにおける輻輳制御によりＣＷＩＮを低下させる。その結果、上述の第２の条件であるＣＷＩＮ≧ＲＷＩＮを前提とする、ステップＳ３０１の定常状態処理における間欠受信のサイクルを実行できなくなる可能性がある。

このため、携帯型端末２１１ｂは、まず送信側装置２０３のパラメータであるＣＷＩＮを推定する（ステップＳ３０５）。そして、携帯型端末２１１ｂは、ステップＳ３０５で推定された推定値Ｄｃ’が、ＲＷＩＮとして設定されているサイクルデータサイズＤｃよりも小さいか否かを判定する（ステップＳ３０６）。携帯型端末２１１ｂは、推定値Ｄｃ’が小さい（Ｄｃ’＜Ｄｃ）と判定したときには（ステップＳ３０６のＹｅｓ）、ＣＷＩＮをサイクルデータサイズＤｃまで増加させるための処理（ＣＷＩＮ低下期間中の処理）を実行する（ステップＳ３０７）。一方、携帯型端末２１１ｂは、推定値Ｄｃ’がサイクルデータサイズＤｃ以上である（Ｄｃ’≧Ｄｃ）であると判定したときには（ステップＳ３０６のＮｏ）、ステップＳ３０１からの処理を繰り返す。

以下、ステップＳ３０２のパケットロス検知処理、ステップＳ３０４の再送誘発処理、ステップＳ３０５のＣＷＩＮ推定処理、および、ステップＳ３０７のＣＷＩＮの低下期間中の処理について、詳細に説明する。

図１６は、図１５のステップＳ３０２におけるパケットロス検知処理の詳細を説明するための説明図である。

例えば、時刻Ｔ３１に送信されたＡＣＫパケット（ＲＷＩＮ＝Ｄｃ）に対して送信側装置２０３から送信されたサイクルデータサイズＤｃ分のデータのうち、例えば４個のデータ（ＤＡＴＡ１〜４）のうち、ＤＡＴＡ３がロスする。

抑制再開制御部９０４は、パケットロスをタイムアウトにより検出する。具体的には、抑制再開制御部９０４は、送信側装置２０３に送信再開を促すＡＣＫパケットＰ１１を送信した時刻Ｔ３１から一定時間Ｔｏ１経過後の時刻Ｔ３２までに、通知したサイクルデータサイズＤｃ分の全てのデータを受信し切れなかった場合に、タイムアウトを検出し、パケットロスが発生したものとみなす。したがって、上述のようにＤＡＴＡ３がロスすると、抑制再開制御部９０４は、一定時間Ｔｏ１内にサイクルデータサイズＤｃ分の全てのデータを受信し切れないため、パケットロスの発生を検知する。なお、一定時間Ｔｏ１をタイムアウト値という。

例えば、抑制再開制御部９０４は、それまでのサイクルにおいて、送信側装置２０３に送信再開を促すＡＣＫパケットが送信された時刻から、通知したサイクルデータサイズＤｃ分の全てのデータを受信し切るまでの時間を計測する。そして、抑制再開制御部９０４は、その計測した時間のうち最大の時間を、上述のタイムアウト値Ｔｏ１に用いる。

また、抑制再開制御部９０４は、タイムアウト値Ｔｏ１の決定においては、送信再開を促すＡＣＫパケットが送信されてから、それに対する最初のデータを受信するまでの間隔であるＲＴＴや、連続したデータの受信間隔Ｒｔなどの情報を取得しておき、その情報からタイムアウト値Ｔｏ１を決定してもよい。即ち、抑制再開制御部９０４は、「ＲＴＴの最大値＋（Ｄｃ／ＭＳＳ−１）×Ｒｔの最大値＝Ｔｏ１」のように計算してもよい。また、抑制再開制御部９０４は、最大値ではなく、平均値や分散値などの各種統計値を用いることにより、より適切なタイムアウト値Ｔｏ１を設定してもよい。

また、タイムアウト値の計測の開始時点を、送信再開を促すＡＣＫパケットを送信した時刻Ｔ３１ではなく、通知したサイクルデータサイズＤｃ分のデータのうち最初に到着したパケットの到着時刻としてもよい。

また、抑制再開制御部９０４は、タイムアウトを用いずに、受信済みのデータのシーケンス番号を監視して、そのシーケンス番号が不連続であれば、パケットロスが発生したと検知してもよい。即ち、抑制再開制御部９０４は、図１６に示すように、ＤＡＴＡ３を受信せずにＤＡＴＡ４を受信したことによりパケットロスの発生を検知する。ここで、パケットロスが発生していなくても、ネットワーク上でのパケットの順序入れ替えの発生により、シーケンス番号が不連続となる場合がある。このような場合には、上述のようにシーケンス番号が不連続であることによってパケットロスの発生を検知すると、パケットロスが発生していなくてもパケットロスとみなしてしまう可能性がある。そこで、抑制再開制御部９０４は、不連続なシーケンス番号を持つデータを含むパケットを複数個受信したときまでに、または、不連続なシーケンス番号を持つデータを受信してから一定時間経過したときまでに、抜けていたデータを受信しなかった場合に、パケットロスの発生を検知してもよい。

図１７は、図１５のステップＳ３０４の再送誘発処理の詳細を説明するための説明図である。

パケットロスが発生した場合に受信側装置（携帯型端末）から何も送信されなければ、送信側装置２０３は、前述の第１のロス検知方法によりタイムアウトを発生させＣＷＩＮを１にしてから再送を行う。その結果、効率的に転送を行うことができなくなり、通信アプリケーションプログラムの性能要件を満たせなくなる可能性がある。

そこで、本実施の形態における受信側装置（携帯型端末）２１１ｂは、送信側装置２０３に対して、第２のロス検知方法による高速な再送を行わせ、ＣＷＩＮの減少を半分にとどめさせる。その結果、できるだけ効率的に送信側装置２０３にデータの転送を行わせる。

つまり、携帯型端末２１１ｂの抑制再開制御部９０４は、再送誘発処理では、送信側装置２０３に第２のロス検知方法を行わせるために、同一のＡＣＫパケットを４つ連続して送信するように通信制御部１０７に指示する。その結果、携帯型端末２１１ｂは、その４つのＡＣＫパケットＰ２１を送信側装置２０３に送信する。なお、これらの全てのＡＣＫパケットＰ２１に含まれる受信ウィンドウ（ＲＷＩＮ）は、サイクルデータサイズＤｃであって、全てのＡＣＫパケットＰ２１に含まれるＡＣＫ番号は、ロスしたパケットであるＤＡＴＡ３の送信を要求する値（例えば、３）となる。

このような４つのＡＣＫパケットＰ２１を受け取った送信側装置２０３は、ロスしたパケットであるＤＡＴＡ３を再送する。なお、送信側装置２０３は、パケットロス検知処理時のサイクルで送信されたサイクルデータサイズＤｃ分のデータ内でのロスしたパケットの位置や、送信側装置２０３のＴＣＰのバージョンや実装によって、ＤＡＴＡ４以降のパケットも送信することがある。例えば、送信側装置２０３は、ＤＡＴＡ３を再送するとともにＤＡＴＡ５およびＤＡＴＡ６を送信する。携帯型端末２１１ｂの抑制再開制御部９０４は、これらの全てのデータを受信するために、４番目のＡＣＫパケットＰ２１の送信時刻Ｔ４１から一定時間Ｔｏ２経過後の時刻Ｔ４２まで、データが届くのを待つ。なお、送信側装置２０３は、ＤＡＴＡ３の再送時には、ＤＡＴＡ４は既に送信されているため、そのＤＡＴＡ４を送信しない。しかし、ＤＡＴＡ４もロスした可能性を考慮して、送信側装置２０３は、ＤＡＴＡ４を再送してもよい。

また、抑制再開制御部９０４は、タイムアウト値Ｔｏ１の決定方法と同様に、ＲＴＴや連続したデータの受信間隔Ｒｔの統計情報などをもとに、一定時間Ｔｏ２を決定してもよい。即ち、抑制再開制御部９０４は、「ＲＴＴの最大値＋（Ｄｃ／ＭＳＳ−１）×Ｒｔの最大値＝Ｔｏ２」のように一定時間Ｔｏ２を決定する。また、抑制再開制御部９０４は、最大値ではなく、平均値や分散値などの各種統計値を用いることにより、より適切な一定時間Ｔｏ２を設定してもよい。

また、一定時間Ｔｏ２の計測の開始時点を、再送を促すＡＣＫパケットＰ２１を送信した時刻Ｔ４１ではなく、再送パケットの到着時刻としてもよい。

また、抑制再開制御部９０４は、再送を促すために同一のＡＣＫパケットＰ２１を４個だけ送信したが、このＡＣＫパケットＰ２１がロスする可能性を考慮して、さらに余分に同一のＡＣＫパケットを送信してもよい。

なお、パケットロス検知処理のサイクルにおいて１つのパケットのみがロスしていた場合には、上述の再送誘発処理により、ロスしたパケットが再送される。しかし、２つ以上のパケットがロスしていた場合には、２番目以降にロスしているパケットも再送させることが望ましい。このために、携帯型端末２１１ｂの抑制再開制御部９０４は、１番目にロスしたパケットに対する再送パケットが受信されると、２番目にロスしたパケットを再送させるための同一のＡＣＫパケットを４つ送信するように通信制御部１０７に指示する。ただし、この送信に対して送信側装置２０３が２番目にロスしたパケットを再送するかどうかは、送信側装置２０３のＴＣＰのバージョンや実装によって異なる。したがって、場合によっては、送信側装置２０３において第１のロス検知方法によるロス検知が行われ、ＣＷＩＮが１になる可能性もある。送信側装置２０３のＴＣＰが、２番目にロスしたパケットを再送するように実装されている場合には、携帯型端末２１１ｂの抑制再開制御部９０４は、１番目にロスしたパケットに対する処理と同様の処理を、全てのロスしたパケットに対して繰り返すことで、再送誘発処理を完了する。

なお、送信側装置２０３の状態がどうなっているか、即ち、第１のロス検知方法によりＣＷＩＮが１となっているのか、第２のロス検知方法の繰り返しの適用によりＣＷＩＮが１より大きな値となっているかは、この再送誘発処理の完了時にロスした全てのパケットの再送パケットを携帯型端末２１１ｂが受信しているかどうかにより判別可能である。

図１８は、図１５のステップＳ３０５のＣＷＩＮ推定処理の詳細を説明するための説明図である。

パケットロスが発生した場合、図１７に示す再送誘発処理の完了後には送信側装置２０３において輻輳ウィンドウ（ＣＷＩＮ）が小さくなっている。しかしながら、定常状態での省電力制御を行うためには、上述の第２の条件であるＣＷＩＮ≧ＲＷＩＮ（Ｄｃ）が満たされている必要がある。

そこで、抑制再開制御部９０４は、このＣＷＩＮの値がサイクルデータサイズＤｃ（期待値）を下回っていないかを知っておく必要があるため、ＣＷＩＮ推定処理では、送信側装置２０３のＣＷＩＮの値を推定する。

まず、抑制再開制御部９０４は、送信側装置２０３からのデータ送信を促すため、ＡＣＫパケットを送信するように指示する。その結果、携帯型端末２１１ｂは、そのＡＣＫパケットＰ３１を送信側装置２０３に送信する。このＡＣＫパケットＰ３１は受信ウィンドウ（ＲＷＩＮ）をサイクルデータサイズＤｃとして通知する。また、そのＡＣＫパケットＰ３１に設定されるＡＣＫ番号は、通常のＴＣＰどおり、ステップＳ３０４の再送誘発処理までに抜けなく受信できているデータのシーケンス番号の最大値＋１（例えば、Ｎ）である。

送信側装置２０３は、このＡＣＫパケットＰ３１を受信すると、Ｍｉｎ（Ｄｃ，ＣＷＩＮ）分のパケット、つまり、サイクルデータサイズＤｃとＣＷＩＮとのうち小さい方のサイズ分のパケットを送信する。

抑制再開制御部９０４は、この後、サイクルデータサイズＤｃ分のデータを受信できた場合には、ＣＷＩＮがサイクルデータサイズＤｃ以上であること、つまり上述の第２の条件が満たされていることを検知できる。また、抑制再開制御部９０４は、サイクルデータサイズＤｃ分のデータを受信できない場合には、ＡＣＫパケットＰ３１が送信された時刻Ｔ５１から一定時間Ｔｏ３経過後の時刻Ｔ５２までに受信されたデータの量（パケットの個数）を、ＣＷＩＮの推定値Ｄｃ’とする。

なお、抑制再開制御部９０４は、サイクルデータサイズＤｃ分のデータを受信できたか否かの判断には、パケットロスの検知やタイムアウトを利用する。つまり、抑制再開制御部９０４は、通信Ｉ／Ｆ部１０８から送信されたＡＣＫパケットに対して、送信側装置２０３から送信されて通信Ｉ／Ｆ部１０８に順次受信された各データのシーケンス番号が連続であるか不連続であるかを判別する。そして、抑制再開制御部９０４は、不連続であると判別したとき、つまりパケットロスがあったと判別したときに、サイクルデータサイズＤｃ分のデータを受信できなかったと判断する。また、抑制再開制御部９０４は、通信Ｉ／Ｆ部１０８から送信されたＡＣＫパケットに対して、送信側装置２０３から送信されて通信Ｉ／Ｆ部１０８に順次受信された各データの合計サイズが、予め定められた期間内で、そのＡＣＫパケットの示すサイクルデータサイズＤｃに達するか否かを判別する。そして、そして、抑制再開制御部９０４は、サイクルデータサイズＤｃに達しないと判別したとき、つまりタイムアウトがあったと判別したときに、サイクルデータサイズＤｃ分のデータを受信できなかったと判断する。

図１９は、ステップＳ３０７のＣＷＩＮ低下期間中の処理の詳細を示すフローチャートである。

ＣＷＩＮ低下期間中はＣＷＩＮ＜Ｄｃとなっている。したがって、携帯型端末が、受信ウィンドウをサイクルデータサイズＤｃとして送信側装置２０３に通知しても、送信側装置２０３はＣＷＩＮ分しかデータを送らない。その結果、携帯型端末は、いつまでたっても通信Ｉ／Ｆ部１０８の電源を切断できなくなり、省電力制御を行えないという問題が発生する。

このため、携帯型端末２１１ｂの抑制再開制御部９０４は、ＣＷＩＮ低下期間の最初では、まず受信ウィンドウをＣＷＩＮの推定値Ｄｃ’として通知するように通信制御部１０７に指示する。こうすれば、携帯型端末（受信側装置）２１１ｂは、通知した受信ウィンドウ分のデータ、つまり推定値Ｄｃ’分のデータを受信することができ、通信Ｉ／Ｆ部１０８の電源を切断することができる。また、送信側装置２０３は、ＴＣＰの輻輳制御手順により、「ＣＷＩＮ／ＭＳＳ個のＡＣＫパケットを受信するとＣＷＩＮをＭＳＳ分大きくする」という制御を行う。したがって、携帯型端末２１１ｂの抑制再開制御部９０４は、このＣＷＩＮの増加に合わせて、通知する受信ウィンドウのサイズを大きくする。その結果、抑制再開制御部９０４は、最終的には受信ウィンドウのサイズを元のサイクルデータサイズＤｃとして通知することができ、定常状態で省電力制御を継続することが可能となる。

抑制再開制御部９０４は、実際の処理として、まず、ＣＷＩＮ低下期間中のサイクルデータサイズＤｃＸの初期値を推定値Ｄｃ’とするとともに、ＣＷＩＮ低下期間中のサイクル間隔ＴｃＸの初期値をＤｃ’／ＢＷとする（ステップＳ４０１）。なお、ＴｃＸ＝ＤｃＸ／ＢＷとすることで、ＣＷＩＮ低下期間中もＢＷ[Ｂｙｔｅ／ｓｅｃ]のレートを確保することができる。これは、サイクルデータサイズがＤｃからＤｃ'に低下したのに比例してサイクル間隔Ｔｃも短くすることに相当する。

次に、抑制再開制御部９０４は、上記サイクルデータサイズＤｃＸおよびサイクル間隔ＴｃＸに基づく間欠受信サイクルをＤｃＸ／ＭＳＳ回繰り返す（ステップＳ４０２）。つまり、携帯型端末２１１ｂは、ＲＷＩＮ＝ＤｃＸのＡＣＫパケットを送信して、サイクルデータサイズＤｃＸ分のデータを受信し、そのＡＣＫパケットの送信からサイクル間隔ＴｃＸが経過するまで次のＡＣＫパケットの送信を停止しておくという間欠受信を（ＤｃＸ／ＭＳＳ）サイクルだけ繰り返す。このような間欠受信を繰り返すことによっても、携帯型端末２１１ｂは、サイクルデータサイズＤｃＸ分のデータを受信してから、次のＡＣＫパケットを送信するまで、通信Ｉ／Ｆ部１０８の電源をＯＦＦにすることができ、省電力制御を行なうことができる。また、このような間欠受信の繰り返しによって、送信側装置２０３は、ＤｃＸ／ＭＳＳ個のＡＣＫを受信することになり、その結果、ＣＷＩＮをＭＳＳ分だけ増加させる。

したがって、間欠受信サイクルがＤｃＸ／ＭＳＳ回繰り返されると、次のサイクルからは、それまでよりサイクルデータサイズＤｃＸをＭＳＳ分大きくしても省電力制御を行うことができる。

このため、抑制再開制御部９０４は、サイクルデータサイズＤｃＸをＭＳＳ大きくし、それに合わせてサイクル間隔ＴｃＸも更新する（ステップＳ４０３）。そして、抑制再開制御部９０４は、ステップＳ４０３でサイクルデータサイズＤｃＸが大きくなることで、そのサイクルデータサイズＤｃＸが、パケットロス発生前の元のサイクルデータサイズＤｃ以上になったか否かを判別する（ステップＳ４０４）。

ここで、抑制再開制御部９０４は、サイクルデータサイズＤｃ以上になったと判別したときには（ステップＳ４０４のＹｅｓ）、ＣＷＩＮ低下期間中の処理を完了し、図１５に示すステップＳ３０１の定常状態処理を実行する。一方、抑制再開制御部９０４は、サイクルデータサイズＤｃＸがまだ元のサイクルデータサイズＤｃに満たないと判別したときには（ステップＳ４０４のＮｏ）、更新されたサイクルデータサイズＤｃＸおよびサイクル間隔ＴｃＸを用いて、ステップＳ４０２からの処理、つまり間欠受信をＤｃＸ／ＭＳＳ回繰り返す処理を行う。

図２０は、ステップＳ３０７のＣＷＩＮ低下期間中において行われる間欠受信の１サイクルを示す図である。

ＣＷＩＮ低下期間中では、携帯型端末２１１ｂは、例えば時刻Ｔ６１に、（ＲＷＩＮ＝ＤｃＸ）のＡＣＫパケットＰ４１を送信する。その結果、携帯型端末２１１ｂは、時刻Ｔ６２に、ＣＷＩＮ低下期間中のサイクルデータサイズＤｃＸ分のデータを送信側装置２０３から受信する。そして、携帯型端末２１１ｂは、そのＡＣＫパケットＰ４１を送信してから、ＣＷＩＮ低下期間中のサイクル間隔ＴｃＸが経過するまで、つまり時刻Ｔ６３まで次のＡＣＫパケットの送信を停止する。さらに、携帯型端末２１１ｂは、時刻Ｔ６１〜Ｔ６２までは通信Ｉ／Ｆ部１０８の電源をＯＮにして、時刻Ｔ６２〜Ｔ６３まではその電源をＯＦＦにするような省電力制御を行なう。携帯型端末２１１ｂは、このような時刻Ｔ６１〜Ｔ６３までの処理を間欠受信の１サイクルとして実行する。

なお、抑制再開制御部９０４は、ステップＳ３０７におけるＣＷＩＮ低下期間中の処理中に、パケットロスを検知した場合も、図１５に示すステップＳ３０１〜Ｓ３０８の処理を行なえばよい。

また、抑制再開制御部９０４は、図２０に示すように、１サイクルにＡＣＫパケットを一つだけ送信するが、複数のＡＣＫパケットを送信してもよい。つまり、送信されるＡＣＫパケットが１つの場合には、ＣＷＩＮを増加させるために、間欠受信のサイクルをＤｃＸ／ＭＳＳ回繰り返す必要がある。しかし、１サイクルにＡＣＫ番号の異なる複数個（例えばＮ個）のＡＣＫパケットを送信すれば、間欠受信のサイクルの繰り返し回数をＤｃＸ／（ＭＳＳ×Ｎ）回に抑えることができる。さらに、Ｎ＝ＤｃＸ／ＭＳＳとすれば、間欠受信のサイクルの繰り返し回数を１サイクルにすることができる。

また、上記処理を行っただけでは、通信アプリケーションプログラムの要求である帯域ＢＷを十分確保したとはいえない場合がある。即ち、ステップＳ３０７のＣＷＩＮ低下期間中の処理、およびステップＳ３０１の定常状態処理の期間においては、帯域ＢＷは確保されている。しかし、ステップ３０２のパケットロス検知処理、ステップＳ３０４の再送誘発処理、ステップＳ３０５のＣＷＩＮ推定処理を行っている期間においては、タイムアウト待ちを行っていることにより、帯域ＢＷは確保されていない。

通信アプリケーションプログラムが帯域ＢＷを要求しているということは、ＴＣＰコネクション開始時から帯域ＢＷで通信し続けただけのデータを受信している必要があるが、上記処理ではこれが満たされてないことになる。この問題は、「ＴＣＰコネクション開始時から受信したデータの総量＝通信開始時からの経過時間×ＢＷ」の条件が成り立つまで、例えば以下の３つの制御方法を実行することにより回避可能である。第１の制御方法では、ステップＳ３０７のＣＷＩＮ低下期間中の処理において、サイクル間隔ＴｃＸの値を上記処理よりも短く設定することにより、一時的に帯域ＢＷ以上の帯域を確保する。また、第２の制御方法では、ＣＷＩＮ低下期間終了後のステップＳ３０１の定常状態処理において、サイクル間隔Ｔｃを短くする、もしくはサイクルデータサイズＤｃを大きくすることにより、一時的にＢＷ以上の帯域を確保する。上述の条件が成り立った後は、サイクル間隔ＴｃおよびサイクルデータサイズＤｃをパケットロス発生前の元の値に戻せばよい。第３の制御方法では、送信抑制制御（間欠受信）を一時的に中断する。例えば、抑制再開制御部９０４は、ＣＷＩＮがサイクルデータサイズＤｃよりも小さくなってからサイクルデータサイズＤｃ以上になるまでのウィンドウ回復期間、ＡＣＫパケットの通常の送信の抑制（停止）を解除し、通信Ｉ／Ｆ部１０８でデータが受信されるごとに、ＡＣＫパケットを通信Ｉ／Ｆ部１０８から送信させる。また、このとき、上述と同様に、１つのＡＣＫパケットを、ＡＣＫ番号の異なる複数個（例えばＮ個）のＡＣＫパケットに分けて送信することによって、ＣＷＩＮをサイクルデータサイズＤｃ以上に早急に回復させることができる。

また、上記処理では、定常状態では間欠受信サイクルが成功することを前提としている。しかし、上記処理では、送信側装置２０３はサイクルデータサイズＤｃ分だけのデータをバースト的に送信することになるため、例えば中継装置が転送パケットを格納するために保持しているバッファのサイズがサイクルデータサイズＤｃよりも小さい場合などは、必ずパケットロスが発生し定常状態処理を行えない可能性がある。このため、定常状態での処理が成功しない状況においては、サイクルデータサイズをＤｃよりも小さな値Ｄ”とし、サイクル間隔もＴｃより小さい値Ｄ”／ＢＷとした定常状態処理を行なうなどの必要がある。なお、ネットワークの状況などは動的に変化するため、パケットロスの発生に応じてサイクル間隔およびサイクルデータサイズを動的に変化させることにより、より最適な（通信アプリケーションプログラムの要求を満たしつつ、できるだけ省電力効果の高い）パラメータを探索するように動作してもよい。また、動的にパラメータを変更しつつ、最適なパラメータ値を探索するアルゴリズムは、一般に用いられている探索アルゴリズムなどを流用すればよく、本発明の本質ではないためここでは詳細なアルゴリズムについては説明を省略する。

また、上記では、図１５に示すように、ステップＳ３０７でＣＷＩＮ低下期間中の処理を行うかどうかを判定したり、ＣＷＩＮ低下期間中のサイクルデータサイズの初期値Ｄｃ’を決定したりするために、ステップＳ３０５のＣＷＩＮ推定処理を行った。しかし、ＣＷＩＮ推定処理は、より効率的に、即ち必要以上に転送レートを低下させないために行う処理であり、必ずしも本発明に必須の処理ではない。例えば、パケットロスが１回しか発生していない場合などは、ＣＷＩＮは最低でもパケットロス発生前の１／２以上であると言えるため、サイクルデータサイズの初期値をサイクルデータサイズＤｃの１／２として、必ずＣＷＩＮの低下期間中の処理を行ってもよい。

上記のような処理を行うことにより、パケットロスが発生した場合でも、通信帯域を維持しつつ間欠受信による省電力制御を継続することができる。

（実施の形態４）
次に、本発明の実施の形態４に係る通信装置について説明する。実施の形態１〜３の通信装置は、フロー制御を終端するが、本実施の形態における通信装置はフロー制御を行う通信を中継する。つまり、本実施の形態における通信装置は、中継通信装置として構成され、実施の形態１の携帯型端末２１１自体のＴＣＰ通信に対して行っていた制御を、中継しているＴＣＰ通信に対して行う。したがって、本実施の形態における間欠受信および省電力制御の本質は、実施の形態１と共通するため、以下では、本実施の形態における実施の形態１との差分を中心に説明する。

図２１は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。なお、本実施の形態に含まれる構成要素中、実施の形態１と同一の機能および構成を有する構成要素に対しては、実施の形態１の構成要素と同一の符号を付して示し、詳細な説明は省略する。

本実施の形態に係る通信システムは、携帯型端末２１２と、携帯型端末５０１と、受信側装置５０２と、無線基地局２０２と、インターネット２０４と、送信側装置２０３とを備えている。

本実施の形態における携帯型端末５０１と受信側装置５０２は、それぞれが組み合わされた状態で、インターネット２０４および無線基地局２０２を介して送信側装置２０３に対して、実施の形態１の携帯型端末２１１と同様の処理動作を行う。

また、携帯型端末５０１は、送信側装置２０３と受信側装置５０２との間の通信を中継する。

つまり、本実施の形態の通信システムと、実施の形態１の図３に示す通信システムとの違いは、実施の形態１では本発明の通信装置たる携帯型端末２１２が受信側装置として動作していたのに対し、本実施の形態では本発明の通信装置たる携帯型端末５０１が中継装置として動作し、その携帯型端末５０１に別の受信側装置５０２が接続されている点である。

図２２は、本実施の形態における携帯型端末５０１の具体的な構成を示す構成図である。

携帯型端末５０１は、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部５０４と、電源制御部１０６と、通信制御部１０７と、通信Ｉ／Ｆ部１０８と、サブ通信Ｉ／Ｆ部１０９とを備える。

つまり、本実施の形態における携帯型端末５０１は、実施の形態１の携帯型端末２１１にないサブ通信Ｉ／Ｆ部１０９を備えるとともに、携帯型端末２１１にある通信アプリケーション部１０１を備えていない。また、本実施の形態における携帯型端末５０１は、実施の形態１の携帯型端末２１１における抑制再開制御部１０４の代わりに、抑制再開制御部５０４を備える。

サブ通信Ｉ／Ｆ部１０９は、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮや、無線ＬＡＮ、ＵＳＢ（Universal Sirial Bus）などで受信側装置５０２と通信する。なお、サブ通信Ｉ／Ｆ部１０９の通信方式は、これら以外の任意の通信方式であってもよい。

抑制再開制御部５０４は、実施の形態１の抑制再開制御部１０４と同様、間欠受信パラメータ登録通知によって受け取った間欠受信パラメータに応じて、送信側装置２０３からのデータ送信を抑制または再開させるタイミングを決定する。また、抑制再開制御部５０４は、決定したタイミングに、送信側装置２０３からのデータ送信を抑制または再開させるため、通信制御部１０７に対してＡＣＫパケットの転送に関係する３つの要求（後述）を発行する。

実施の形態１では、通信制御部１０７がＴＣＰの処理を行っていたため、抑制再開制御部１０４は、その通信制御部１０７に対して、ＡＣＫパケットの送信の可否を要求したり、ＡＣＫパケットの内容を所定の内容にするように要求したり、ＡＣＫパケットの送信のタイミングを要求した。本実施の形態では、通信制御部１０７が送信側装置２０３および受信側装置５０２の送信するパケットの転送を行うため、抑制再開制御部５０４は、通信制御部１０７に対して、受信側装置５０２の送信したＡＣＫパケットの転送の可否を要求したり、受信側装置５０２のＩＰアドレスが送信元アドレスとなるように、ＡＣＫパケットの内容を所定の内容にするように要求したり、ＡＣＫパケットの転送のタイミングを要求する。

具体的に、通信制御部１０７は、抑制再開制御部５０４から、ＡＣＫ通常転送抑制要求、ＡＣＫ通常転送再開要求、およびＡＣＫ単発送信要求を受けて、それらの要求に対応する。

ＡＣＫ通常転送抑制要求は、通常のＡＣＫパケット転送を抑制させるための要求である。通信制御部１０７は、この要求を受けると、以後、受信側装置５０２から送信されたＡＣＫパケットの転送を行わなくなる。

ＡＣＫ通常転送再開要求は、ＡＣＫ通常転送抑制要求を解除させる要求である。通信制御部１０７は、この要求を受けると、通常の処理（受信側装置５０２から送信されたＡＣＫパケットの転送）を再開する。

ＡＣＫ単発送信要求は、抑制再開制御部５０４から指定されたタイミングで、抑制再開制御部５０４から指定された内容のＡＣＫパケットを送信させる要求である。通信制御部１０７は、この要求を受けると、受信側装置５０２がＡＣＫパケットを送信するタイミングに関係なく、指定された内容のＡＣＫパケットを指定されたタイミングで送信する。なお、この要求は、ＡＣＫ通常転送抑制要求を受けている状態でも有効である（送信可能である）。また、抑制再開制御部５０４は、このＡＣＫパケットの送信元ＩＰアドレスには受信側装置５０２のＩＰアドレスを用いるように通信制御部１０７に指示する。

次に、本実施の形態における、間欠受信の準備状態に入るまでの処理について説明する。本実施の形態における上記処理では、実施の形態１の処理と比べて、間欠受信パラメータに関する処理のみが異なる。そこで、間欠受信パラメータに関する処理について説明する。

実施の形態１では、アプリ要求取得部１０２は、通信アプリケーションプログラムから性能に関する要求（性能パラメータ）を受信し、これを性能パラメータ管理テーブルで管理していた。しかし、本実施の形態においては、通信を行う通信アプリケーションプログラムは、受信側装置５０２にあるため、この要求性能に関する情報（性能パラメータ）も受信側装置５０２が保持している。このため、本実施の形態のアプリ要求取得部１０２は、以下の処理を行うことにより性能パラメータを取得する。

例えば、アプリ要求取得部１０２は、受信側装置５０２からサブ通信Ｉ／Ｆ部１０９を経由して通信アプリケーションプログラムに関する情報（性能パラメータ）を取得する。このとき、アプリ要求取得部１０２は、その後に開始されるＴＣＰ通信を識別するための情報を合わせて取得する。例えば、アプリ要求取得部１０２は、送信側装置２０３のＩＰアドレス情報や、通信アプリケーションプログラムが使用するポート番号の情報、もしくはＴＣＰ通信を識別するためのＩＤ情報を取得する。ＩＤ情報を取得する場合は、その後開始されるＴＣＰ通信において、例えばＩＰヘッダオプションフィールドやＴＣＰヘッダオプションフィールドなどにこのＩＤ情報を含めることで携帯型端末５０１がＴＣＰコネクションを認識できるようにすればよい。

また、アプリ要求取得部１０２は、受信側装置５０２から性能パラメータを取得できない場合は、既定のパラメータを性能パラメータに適用する。なお、既定のパラメータでは、通信アプリケーションプログラムの性能要件を満たせなかったり、必要以上に通信Ｉ／Ｆ部１０８の電力を消費したりする可能性があるため、携帯型端末５０１のＵＩ（User Interface）などからこの既定のパラメータを変更できるようにしてもよい。

次に、本実施の形態における間欠受信の準備状態の処理について説明する。まず、受信側装置５０２と送信側装置２０３の間でＴＣＰコネクションが確立される。携帯型端末５０１の通信制御部１０７は、コネクション開始時のＴＣＰパケット（ＳＹＮパケット等）を転送する際に、制御対象であるＴＣＰコネクションが開始されたことを検知する。ＴＣＰコネクションの確立後、受信側装置５０２と送信側装置２０３の間のＴＣＰパケットは、携帯型端末５０１の通信Ｉ／Ｆ部１０８、通信制御部１０７、およびサブ通信Ｉ／Ｆ部１０９を介して送受信される。

その後、抑制再開制御部５０４は、通信制御部１０７で転送されるＴＣＰパケットをモニタリングし、転送データの帯域（転送帯域）が、間欠受信パラメータ管理テーブルに設定されている帯域（設定帯域ＢＷ＝Ｄｃ／Ｔｃ）に到達するのを待つ。例えば、抑制再開制御部５０４は、実施の形態１の抑制再開制御部１０４と同様、サイクル間隔Ｔｃの経過ごとに、そのサイクル間隔Ｔｃの間に受信したＴＣＰパケットのデータサイズを合計することで、合計データサイズＴｌＤを算出する。そして、抑制再開制御部５０４は、「ＴｌＤ／Ｔｃ≧ＢＷ」の条件を満たす回数が所定回数以上だけ続いたときに、転送帯域が設定帯域ＢＷに到達したと見なす。

抑制再開制御部５０４は、転送帯域が設定帯域ＢＷに到達すると、送信側装置２０３からのデータ送信を抑制するために、通信制御部１０７に対してＡＣＫ通常転送抑制要求を発行する。なお、この発行は、間欠受信の１回目の処理に相当する。このとき、抑制再開制御部５０４は、通信制御部１０７からそれまでに送信した最後のＡＣＫパケットの情報、すなわち、ＡＣＫ番号（ＬＡＳＴ＿ＡＣＫＮＯ）と受信ウィンドウ（ＬＡＳＴ＿ＲＷＩＮ）とを保持しておく。通信制御部１０７は、抑制再開制御部５０４からＡＣＫ通常転送抑制要求を受けると、以後、受信側装置５０２から送信されたＡＣＫパケットを転送しないようにする。

一方、送信側装置２０３は、受信側装置５０２からＡＣＫパケットが送られてこなくなっても、自身の管理する送信可能なデータサイズ（ｕｗｎｄ）が０になるまで、データ送信を続け、ｕｗｎｄが０になった時点で、データ送信を終了する。その結果、送信側装置２０３は送信抑制期間に入る。

抑制再開制御部５０４は、ＡＣＫ通常転送抑制要求の発行後もＴＣＰパケットをモニタリングし、送信側装置２０３での送信可能なデータサイズ（ｕｗｎｄ）が０になるのを待つ。具体的には、抑制再開制御部５０４は、受信したＴＣＰパケットのシーケンス番号とデータサイズを参照し、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）に到達するのを待つ。

抑制再開制御部５０４は、ｕｗｎｄが０になったと判断したら、電源制御部１０６へ切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

抑制再開制御部５０４は、電源制御部１０６へ切断要求を発行した後、所定時間の満了を待つ。この所定時間は、サイクル間隔Ｔｃと一致していてもよいし、異なる時間であっても良い。送信側装置２０３は、既に送信抑制期間に入っているので、通信Ｉ／Ｆ部１０８の電源が切断されている間、データ送信を行なわない。

所定時間が満了したとき、抑制再開制御部５０４は、電源制御部１０６へ投入要求を発行する。さらに、抑制再開制御部５０４は、間欠受信の準備状態が満了したと見なし、定常状態に遷移する。電源制御部１０６は投入要求を受けると、通信Ｉ／Ｆ部１０８の電源を投入する。

以下、本実施の形態における定常状態の処理について説明する。

図２３は、本実施の形態における受信側装置５０２と携帯型端末５０１と送信側装置２０３の定常状態での動さを示すシーケンス図である。

定常状態での１サイクル分の動作は、送信再開処理と、送信抑制期間の開始処理と、送信抑制期間の終了処理との３つのステップに分けられる。

送信再開処理（ステップ１）では、抑制再開制御部５０４は、送信側装置２０３からのデータ送信を再開させるため、通信制御部１０７に対してＡＣＫ単発送信要求を発行する。このとき、抑制再開制御部５０４は、ＡＣＫパケットの受信ウィンドウ（ＲＷＩＮ）として、間欠受信パラメータ管理テーブルに格納されたサイクルデータサイズＤｃを指定する。通信制御部１０７は、時刻Ｔ７１に、ＡＣＫ単発送信要求を受け取ると、ＲＷＩＮ＝ＤｃのＡＣＫパケットＰ５１を通信Ｉ／Ｆ部１０８を介して送信する。このとき、抑制再開制御部５０４は、受信側装置５０２から受信して転送していないＡＣＫパケットのＡＣＫ番号のうち最大のものを記憶しているため、その記憶しているＡＣＫ番号を、ＡＣＫパケットＰ５１のＡＣＫ番号にする。なお、送信側装置２０３がこのＡＣＫパケットＰ５１を正当なパケットとして受信できるように、そのＡＣＫパケット５１では、送信元ＩＰアドレスは受信側装置５０２のＩＰアドレスとされ、ポート番号は当該ＴＣＰコネクションのポート番号とされる。

一方、送信側装置２０３は、携帯型端末５０１が送信したＡＣＫパケット（ＲＷＩＮ＝Ｄｃ）を受信すると、間欠受信の準備状態、または、送信抑制期間が終了し、データ送信が可能な状態になる。その結果、送信側装置２０３は、受信側装置５０２あてのＴＣＰパケット（データＰ５２）の送信を再開する。

携帯型端末５０１の抑制再開制御部５０４は、間欠受信の準備状態でＡＣＫ通常転送抑制要求を発行しているので、受信側装置５０２が送信したＡＣＫパケットの転送は既に抑制されている。すなわち、サブ通信Ｉ／Ｆ部１０９が受信側装置５０２からのＡＣＫパケットを受信して、そのＡＣＫパケットを通信制御部１０７に引渡しても、通信制御部１０７はそのＡＣＫパケットを通信Ｉ／Ｆ部１０８を通して送信側装置２０３に対して送信しない。そのため、送信側装置２０３が一度に送信できるデータＰ５２のサイズは、サイクルデータサイズＤｃに制限される。

送信抑制期間の開始処理（ステップ２）では、抑制再開制御部５０４は、時刻Ｔ７１以降、通信制御部１０７で転送されるＴＣＰパケットをモニタリングする。そして、抑制再開制御部５０４は、時刻Ｔ７１以降で転送したデータサイズがサイクルデータサイズＤｃに到達したかどうか、すなわち、送信側装置２０３の送信可能なデータサイズ（ｕｗｎｄ）が０になったかどうかを確認し続ける。このとき抑制再開制御部５０４は、間欠受信の準備状態での確認処理と同じく、最後に送信したＡＣＫパケットのＡＣＫ番号と受信ウィンドウ（ＲＷＩＮ＝Ｄｃ）を使って上述の確認を行う。Ｔ７１以降で転送したデータサイズがＤｃに到達したとき、即ち時刻Ｔ７２で、抑制再開制御部５０４は、送信抑制期間が開始したとみなし、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

送信抑制期間の終了処理（ステップ３）では、本発明の実施の形態における携帯型端末５０１では、Ｔ７１時点を起点として、サイクル間隔Ｔｃの時間経過後の時刻Ｔ７３を、送信抑制期間の終了点と見なす。つまり、抑制再開制御部５０４は、タイマにより時刻Ｔ７３のタイミングを検出し、電源制御部１０６に投入要求を発行する。その結果、投入要求により、電源制御部１０６は時刻Ｔ７３に通信Ｉ／Ｆ部１０８の電源を投入する。

携帯型端末５０１は、定常状態では、上記３つのステップを１サイクルとして、繰り返し実行する。

このように、本実施の形態では、実施の形態１での省電力方法と同様の間欠受信制御を、ＴＣＰ通信を中継する通信装置に対しても適用することができ、実施の形態１と同様の省電力効果を得ることができる。また、ここでは説明を省略するが、実施の形態２による省電力効果の向上や、実施の形態３によるパケットロス時の動作などもＴＣＰ通信を中継する通信装置に対して適用することも可能である。

（実施の形態５）
以下、本発明の第５の実施の形態における通信装置について図面を参照しながら説明する。実施の形態１から４では、本発明に係る通信装置を受信側装置に対して適用したが、本実施の形態では、本発明に係る通信装置を送信側装置に適用し、送信側装置の省電力効果を向上させる。また、本実施の形態における送信側装置は、受信側装置に対して、間欠送信処理を行うことを通知することで、より確実に省電力効果を高める。

図２４は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型端末６１１，６１２と、無線基地局２０２と、インターネット２０４と、受信側装置６０３とを備えている。

携帯型端末６１１，６１２は、通信品質と省電力効果のさらなる向上を両立して図った送信側装置であって、無線基地局２０２およびインターネット２０４を介して、受信側装置６０３にデータを送信する。受信側装置６０３は、インターネット２０４および無線基地局２０２を介して、携帯型端末６１１，６１２から送信されたデータを受信する。

ここで、本実施の形態における携帯型端末６１１について詳細に説明する。

図２５は、本実施の形態における携帯型端末６１１の一例を示す構成図である。

携帯型端末６１１は、通信アプリケーション部６２１と、アプリ要求取得部６２２と、パラメータ決定部６２３と、抑制再開制御部６２４と、電源制御部１０６と、通信制御部６２７と、通信Ｉ／Ｆ部１０８とを備える。この携帯型端末６１１は、受信側装置６０３からＡＣＫパケットを受信しても、直ちにそのＡＣＫパケットに応じたデータパケット（送信データ）を送信することなく、所定期間（上述の送信抑制期間）だけデータパケットの送信を停止して、その所定期間経過後にデータパケットを送信する。言い換えれば、携帯型端末６１１は、フロー制御の仕組みを使ってデータ送信の抑制と再開を繰り返すことで、携帯型端末６１１の所望する間隔での間欠的なデータ送信（間欠送信）を行う。これにより、携帯型端末６１１は、その所定期間だけ通信Ｉ／Ｆ部１０８に供給される電力を抑えることができ省電力効果の向上を図ることができる。

また、本実施の形態における携帯型端末６１１が備えている上記各構成要素は、基本的に、実施の形態１の携帯型端末２１１が備えている各構成要素のデータ受信用の機能に対応した、データ送信用の機能を有する。したがって、本実施の形態における携帯型端末６１１が備えている上記各構成要素の機能のうち、実施の形態１の携帯型端末２１１が備えている各構成要素の機能に対応しているものについては、以下、簡単に説明し、単純に対応していない機能についてのみ詳細に説明する。

なお、本実施の形態では、抑制再開制御部６２４が抑制手段および切換制御手段として構成されている。

通信アプリケーション部６２１は、通信アプリケーションプログラムを実行する。通信アプリケーション部６２１は、通信アプリケーションプログラムの起動時に、アプリ要求取得部６２２に起動通知を発行し、受信側装置６０３との間でデータ送受信を行なう。また、通信アプリケーション部６２１は、通信アプリケーションプログラムの終了時に、アプリ要求取得部６２２に終了通知を発行する。なお、本実施の形態では、説明の単純化のため、携帯型端末６１１上で同時に動作する通信アプリケーションプログラムが１つに限定されているものとする。

アプリ要求取得部６２２は、通信アプリケーション部６２１と受信側装置６０３との間でのデータ通信の「性能パラメータ」を入手する。アプリ要求取得部６２２は、通信アプリケーション部６２１から起動通知または終了通知を受けると、同時にその性能パラメータを通信アプリケーション部６２１から入手し、パラメータ決定部６２３に対して、性能パラメータ登録通知または性能パラメータ削除通知を発行する。

なお、アプリ要求取得部６２２は、送信されるデータのタイプ（アプリケーションタイプ）や、ファイルサイズ、バッファサイズなどに基づいて、性能パラメータである帯域ＢＷおよび遅延時間ＤＴなどを決定してもよい。たとえば、アプリケーションタイプがＭＰＥＧであれば、アプリ要求取得部６２２は、画像が乱れない程度の必要な帯域を性能パラメータとして決定する。

パラメータ決定部６２３は、間欠的にデータを送信するためのパラメータを決定する。間欠的にデータを送信するためのパラメータは、実施の形態１の間欠受信時と同様に、間欠送信のサイクル間隔およびサイクルデータサイズからなる。また、これらの２つのパラメータを総称して「間欠送信パラメータ」と呼ぶ。パラメータ決定部６２３は、アプリ要求取得部６２２から性能パラメータ登録通知または性能パラメータ削除通知を受けつけたとき、アプリ要求取得部６２２からの性能パラメータを元に間欠送信パラメータを決定し、抑制再開制御部６２４に間欠送信パラメータ登録通知または間欠送信パラメータ削除通知を送信する。

抑制再開制御部６２４は、受信側装置６０３へのデータ送信が間欠的に行なわれるように、通信制御部６２７を制御する。抑制再開制御部６２４は、送信したデータに対するＡＣＫパケットを受信した後、受信側装置６０３へのデータ送信を行わない期間を作る。この期間のことを送信抑制期間と呼ぶ。さらに、抑制再開制御部６２４は、この制御によって得られた送信抑制期間に通信Ｉ／Ｆ部１０８の電源が切断されるように、電源制御部１０６へ指示を出す。

具体的には、抑制再開制御部６２４は、間欠送信パラメータ登録通知によって受け取った間欠送信パラメータに応じて、受信側装置６０３へのデータ送信を抑制または再開するタイミングを決定する。また、抑制再開制御部６２４は、送信抑制期間に連動して、電源制御部１０６に対して投入または切断の要求を送信する。さらに、抑制再開制御部６２４は、通信制御部６２７で送受信するＴＣＰパケットをモニタリングし、そのモニタリングの結果を上述のタイミングの決定に利用する。

電源制御部１０６は、抑制再開制御部６２４からの投入または切断の要求に従って、通信Ｉ／Ｆ部１０８の電源を投入または切断する。

通信制御部６２７は、通常のＴＣＰ処理に加えて、抑制再開制御部６２４からの要求を受けて、データパケットの送信タイミングやパケット内容を変更する。具体的には、通信制御部６２７は、抑制再開制御部６２４から、データパケット通常送信抑制要求、データパケット通常送信再開要求、指定サイズデータ送信要求を受けて、それらの要求に対応する。

データパケット通常送信抑制要求は、通常のデータパケット送信を抑制させる要求である。通信制御部６２７は、この要求を受けると、以後、指定サイズデータ送信要求、もしくは、データパケット通常送信再開要求を受けない限り、データパケットを送信しない。

データパケット通常送信再開要求は、データパケット通常送信抑制要求によって停止していたデータパケットの送信抑制を解除し、通常のＴＣＰにしたがって、データパケットを送信させる要求である。

指定サイズデータ送信要求は、データパケット通常送信抑制要求を受けた状態において有効であり、指定されたサイズのデータをＴＣＰにしたがって送信させる要求である。通信制御部６２７は、通信Ｉ／Ｆ部１０８を介して、指定されたサイズのデータパケットを送信し、送信したデータパケットに対応するＡＣＫパケットを受信したと判断した時点で、データパケットの送信を停止する。

このような携帯型端末６１１が初期状態から通信を開始して終了するまでの携帯型端末６１１の動作について、以下、説明する。

初期状態では、実施の形態１の間欠受信パラメータの登録と同様に、携帯型端末６１１は、性能パラメータに基づいて間欠送信パラメータ管理テーブルを登録し、通常のＴＣＰにしたがった処理を開始する。

次に、携帯型端末６１１は、間欠送信の準備状態の処理を行う。この準備状態においては、携帯型端末６１１は、まず、間欠送信を行うことを受信側装置６０３に通知する。すなわち、携帯型端末６１１は、ＴＣＰの通信を開設する際に、間欠送信処理を行う旨を受信側装置６０３に通知するために、ＴＣＰヘッダのオプションフィールドにおいて間欠送受信有効フラグを有効にし、３ＷＡＹハンドシェイクを行う。これにより、受信側装置６０３の間欠受信処理を抑えることができ、より確実に省電力効果を高めることができる。つまり、受信側装置６０３が実施の形態１の携帯型端末２１１のように間欠受信を行うことが可能な通信装置である場合に、受信側装置６０３による間欠受信と、携帯型端末６１１による間欠送信とが同時に行われると、携帯型端末６１１と受信側装置６０３との間での通信（間欠送信および間欠受信）が正常に行われないことがある。しかしながら、上述のように、本実施の形態では、携帯型端末６１１が間欠送信を行うことを受信側装置６０３に通知して、受信側装置６０３による間欠受信を停止させることにより、携帯型端末６１１による受信側装置６０３に対する間欠送信を正常に行うことができる。このような間欠送信の通知の他、携帯型端末６１１は、実施の形態１と同様に、データパケット（送信データ）の帯域（送信帯域）が間欠送信パラメータ管理テーブルに設定されている帯域ＢＷまで達し、その帯域でのデータパケットの送信が所定の回数以上継続されるように、データパケットの送信を繰り返し行う。その後、携帯型端末６１１の抑制再開制御部６２４は、データパケット通常送信抑制要求を通信制御部６２７に送信する。その結果、通信制御部６２７は、抑制再開制御部６２４からデータパケット通常送信抑制要求を受けると、以後、ＡＣＫパケットの受信を続けるものの、その受信時にデータパケットを送信しないようにする。

次に、本実施の形態における定常状態の処理について説明する。

図２６は、本実施の形態における携帯型端末６１１と受信側装置６０３の定常状態での動作を示すシーケンス図である。

定常状態での１サイクル分の動作は、送信再開処理と、送信抑制期間の開始処理と、送信抑制期間の終了処理との３つのステップに分けられる。

送信再開処理（ステップ１）では、抑制再開制御部６２４は、受信側装置６０３への指定サイズのデータ送信を行うために、通信制御部６２７に対して指定サイズデータ送信要求を発行する。このとき、抑制再開制御部６２４は、間欠送信パラメータ管理テーブルに格納されたサイクルデータサイズＤｃを、サイクル間隔Ｔｃの間に送信すべきデータサイズ（指定サイズ）とし、そのサイクルデータサイズＤｃ分のデータを送信するように通信制御部６２７に要求する。通信制御部６２７は、時刻Ｔ８１に、指定サイズデータ送信要求を受け取ると、サイクルデータサイズＤｃ分のデータパケットＰ１を通信Ｉ／Ｆ部１０８を介して送信する。

送信抑制期間の開始処理（ステップ２）では、抑制再開制御部６２４は、時刻Ｔ８１以降、通信制御部６２７で受信されるＴＣＰパケットをモニタリングしながら、通信制御部６２７からそれまでに送信された最後のデータパケットの情報、すなわち、シーケンス番号（ＬＡＳＴ＿ＳＥＱ）と送信したデータサイズ（ＬＡＳＴ＿ＳＩＺＥ）とを保持しておく。

そして、抑制再開制御部６２４は、時刻Ｔ８１以降で送信したデータサイズがサイクルデータサイズＤｃに到達し、最後のデータパケットに対するＡＣＫパケットを受信したかどうか、を確認し続ける。具体的には、抑制再開制御部６２４は、ＡＣＫパケットＰ２が受信されるごとに、その受信されたＡＣＫパケットＰ２のＡＣＫ番号を参照し、そのＡＣＫ番号が（ＬＡＳＴ＿ＳＥＱ＋ＬＡＳＴ＿ＳＩＺＥ）であるか否かを確認する。

このとき、送信されたデータパケットに対するＡＣＫパケットが全て携帯型端末６１１に到達しない場合がある。具体的には、次の原因が考えられる。

（１）受信側装置６０３がＤＥＬＡＹＥＤ ＡＣＫアルゴリズムを実装している場合、受信側装置６０３はデータパケット１つに対して１つのＡＣＫパケットを送信するのではなく、複数個のデータパケットに対し、１つのＡＣＫパケットを送信する。

（２）伝送路上や、受信側端末６０３上、携帯型端末６１１上で、パケットロスが発生する。

そこで、携帯型端末６１１は、ＲＴＴを推定するＲＴＴ推定部を備え、送信したデータパケットに対する全てのＡＣＫパケットを受信しない場合、最後のデータパケットを送信した後からＲＴＴ間だけＡＣＫパケットを待ち受けてもよい。携帯型端末６１１は、このＲＴＴ間に全てのＡＣＫパケットを受信しなければ、ＡＣＫパケットの待ち受けを終了し、受信していないＡＣＫパケットに対応するデータパケットを、次のサイクルにおけるデータ送信の最初に再送する。

また、携帯型端末６１１は、ＲＴＴ間だけＡＣＫパケットを待ち受け、全てのＡＣＫパケットを受信しない場合は、パケットロスが発生している可能性もあるため、受信していないＡＣＫパケットに対応するデータパケット、もしくは、最後に送信したデータパケットを再送信し、再度ＡＣＫパケットを待ってもよい。

また、受信側装置６０３のＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲを解除するパケット数が既知であれば、携帯型端末６１１は、データパケットの数がＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲ解除のパケット数の整数倍となるように、データパケットの分割を行ってもよい。一方、ＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲを解除するパケット数が既知でなければ、携帯型端末６１１は、あらかじめ、通信中にＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲ解除のパケット数をＡＣＫパケットの受信タイミングから推定しておいてもよい。

時刻Ｔ８１以降で送信したデータパケットに対する全てのＡＣＫパケットが到達したとき、もしくは、これ以上到達しないと判断したときである時刻Ｔ８２で、抑制再開制御部６２４は、送信抑制期間が開始したとみなし、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

送信抑制期間の終了処理（ステップ３）では、本発明の実施形態における携帯型端末６１１は、時刻Ｔ８１を起点として、サイクル間隔Ｔｃの時間経過後の時刻Ｔ８３を、送信抑制期間の終了点と見なす。つまり、抑制再開制御部６２４は、タイマにより時刻Ｔ８３を検出し、電源制御部１０６に投入要求を発行する。その投入要求により、電源制御部１０６は時刻Ｔ８３に通信Ｉ／Ｆ部１０８の電源を投入する。

携帯型端末６１１は、定常状態では、上記３つのステップを１サイクルとして、繰り返し実行する。

通信アプリケーションプログラムを終了する場合の処理では、携帯型端末６１１は、実施の形態１と同様に、受信側装置６０３とのＴＣＰのコネクションを切断する。さらに、携帯型端末６１１のアプリ要求取得部６２２およびパラメータ決定部６２３はそれぞれ、性能パラメータ管理テーブルの内容と、間欠送信パラメータ管理テーブルの内容とをクリアする。さらに、抑制再開制御部６２４は、通信制御部６２７で送受信されるＴＣＰパケットのモニタリングを停止し、電源制御部１０６に対して通信Ｉ／Ｆ部１０８の電源を切断させる。

以上の処理により、携帯型端末６１１の状態は初期状態に戻る。

次に、上記の間欠送信処理のための、携帯型端末６１１内の処理について、フローチャートを用いて説明する。

図２７は、本実施の形態における携帯型端末６１１の定常状態の動作を示すフローチャートである。

まず、本実施の形態の携帯型端末６１１は、前のサイクルにおいて、受信していないＡＣＫパケットに対応するデータパケットが通信制御部６２７に保持されていたら、サイクルデータサイズＤｃ分のデータパケットの送信に先立ち、その保持されているデータパケットを既存のＴＣＰプロトコルに従って送信する（ステップＳ５０１）。このとき、携帯型端末６１１の抑制再開制御部６２４は、通信Ｉ／Ｆ部１０８への電源投入のタイミングを特定するため、タイマによる計時を開始する。

次に、携帯型端末６１１は、今回のサイクルで送信すべきサイクルデータサイズＤｃ分のデータパケットを送信する（ステップＳ５０２）。このとき、上述の送信抑制期間の開始処理（ステップ２）で説明したように、携帯型端末６１１は、最後のデータパケットを送信後、送信したデータパケットに対応する全てのＡＣＫパケットをＲＴＴ間だけ待ち受ける。このＲＴＴ間に全てのＡＣＫパケットを受信しなければ、携帯型端末６１１は、その全てのＡＣＫパケットを受信しないまま、データパケットの送信を完了する。なお、ＴＣＰなので、最後のデータパケットは通信制御部１０７に保持されており、次回のサイクルの最初（ステップＳ５０１）で送信される。

携帯型端末６１１は、サイクルデータサイズＤｃ分のデータパケットの送信が完了した後、通信Ｉ／Ｆ部１０８の電源を切断する（ステップＳ５０３）。携帯型端末６１１は、通信Ｉ／Ｆ部１０８の電源を切断すると、上述のタイマに基づいて、ステップＳ５０２でのデータパケットの送信開始時からサイクル間隔Ｔｃが経過したか否かを判別する（ステップＳ５０４）。ここで、携帯型端末６１１は、サイクル間隔Ｔｃが経過していないと判別したときには（ステップＳ５０４のＮｏ）、ステップＳ５０３からの処理を繰り返し、サイクル間隔Ｔｃが経過したと判別したときには（ステップＳ５０４のＹｅｓ）、通信Ｉ／Ｆ部１０８の電源を投入する（ステップＳ５０５）。

なお、本実施の形態では、ステップＳ５０３およびＳ５０４において、定期的にサイクル間隔Ｔｃの経過を確認しているが、定期的な確認を行わず、サイクル間隔Ｔｃが経過したときに、割り込みを発生させて、サイクル間隔Ｔｃの経過を検知してもよい。

最後に、携帯型端末６１１は、送信すべきアプリケーションデータ（データパケット）の送信を完了し、受信側装置６０３との通信を終了すべきか否かを判別し（ステップＳ５０６）、終了すべきと判別したときには（ステップＳ５０６のＹｅｓ）、全ての処理を終了する。また、携帯型端末６１１は、終了すべきでなく、まだ送信すべきデータが存在すると判別したときには（ステップＳ５０６のＮｏ）、ステップＳ５０１からの処理を繰り返し実行する。このようなステップＳ５０１〜Ｓ５０６の処理によって、間欠送信を行いながら通信が実行される。

以上のように、本実施の形態に係る携帯型端末６１１は、無線ＬＡＮの省電力方法に依存せず、例えばＴＣＰなどのフロー制御機構を持つプロトコルを使って、受信側装置６０３との間で通信を行いながら省電力化を行なう。そのため、本実施の形態では、アクセスポイントでの省電力機能のサポート状況やネットワークデバイスの種類にも関係なく、携帯型端末６１１の省電力化を図ることができる。また、携帯型端末６１１（送信側装置）から間欠送信を行うことが受信側装置６０３に通知されることにより、受信側装置６０３の間欠受信処理を抑えることができ、より確実に省電力化を図ることができる。

なお、本実施の形態では、送信抑制期間においてのみ、電源を切断したが、省電力効果をさらに向上するために、１サイクル内のデータパケットの送信後からＡＣＫパケットの受信までの期間も電源を切断してもよい。

図２８は、本実施の形態に係る携帯型端末６１１と受信側装置６０３の他の省電力方法を示すシーケンス図である。

携帯型端末６１１は、実施の形態２の携帯型端末２１１ａと同様に、サイクルの最初のデータパケット送信後、そのデータパケットに対応するＡＣＫパケットを受信するまでのＲＴＴ間のうち、一部の期間において通信Ｉ／Ｆ部１０８の電源を切断する。

具体的には、携帯型端末６１１は、サイクル間隔Ｔｃの間にサイクルデータサイズ分のデータパケットを送信しなければならないので、１サイクルの全てのデータパケットを送信した直後（図２８の時刻Ｔ９２）から、最初のＡＣＫパケットが到達する直前（図２８の時刻Ｔ９３）までの期間において通信Ｉ／Ｆ部１０８の電源を切断する。ただし、受信側装置６０３から受信しているＲＷＩＮがサイクルデータサイズＤｃよりも小さい場合は、携帯型端末６１１は、受信したＲＷＩＮに応じたデータサイズ分のデータパケットを送信した後に電源を切断する。

また、本実施の形態では、サイクルデータサイズＤｃおよびサイクル間隔Ｔｃを固定させたが、送信するデータサイズに応じて動的に変更してもよい。また、本実施の形態では、各サイクルの間隔をあけずに、各サイクルを連続させたが、各サイクルの間を空けてもよい。例えば、携帯型端末６１１は、サイクルデータサイズＤｃ分のデータの送信準備がサイクル開始時点でできていない場合などでは、サイクルデータサイズＤｃ分の送信すべきデータが準備されるまで、次のサイクルを開始せず、電源切断を行ってもよい。これにより、まとめてデータを送信することにより、ＴＣＰの往復回数を減らすことで、より省電力効果を得ることができる。

また、本実施の形態では、携帯型端末６１１（送信側装置）が、間欠送信を通知したが、必ずしも通知する必要はない。また、携帯型端末６１１（送信側装置）が、間欠送信を通知することなく、逆に、受信側装置６０３が、間欠受信を携帯型端末６１１に通知してもよい。また、携帯型端末６１１（送信側装置）と受信側装置６０３との間でネゴシエーションを実施することにより、間欠受信および間欠送信のうち何れを実行するかを決定してもよい。この場合、両装置が間欠送受信有効フラグに省電力効果に関する情報を含めることで、間欠受信および間欠送信のうち、省電力効果の高い方が実施される。また、本実施の形態では、間欠送信の実施を通知するタイミングを、３ＷＡＹハンドシェイクとしたが、そのタイミングは、間欠送信の準備状態などのように、間欠送信を実施する前であれば何れのタイミングであってもよい。

（実施の形態６）
本発明の実施の形態６に係る通信装置について説明する。実施の形態１から実施の形態５では、携帯型端末において動作する通信アプリケーションプログラムは１つだけであったが、本実施の形態では、複数の通信アプリケーションプログラムが同時に動作する。複数の通信アプリケーションプログラムが同時に動作した場合でも、複数の通信アプリケーションプログラムの送信処理および受信処理を同期することにより、送信抑制期間を発生させ、省電力効果を得ることができる。本実施の形態では、簡単のために２つの通信アプリケーションプログラムが同時に動作した場合について説明を行う。

図２９は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型端末１００１，１００２と、ＵＤＰ（User Datagram Protocol）などのようにフロー制御を行わない通信を行う送信側装置２０３ａと、フロー制御付の通信を行う機能を持つ送信側装置２０３と、受信側装置６０３とを備える。

なお、本実施の形態において、実施の形態１〜５と同様の機器および構成については、同一の参照符号を付して説明を省略する。

本実施の形態における携帯型端末１００１は、実施の形態２の携帯型端末２１１ａの受信側装置としての機能と、実施の形態５の携帯型端末６１１の送信側装置としての機能とを兼ね備え、２つの通信アプリケーションプログラムを同時に実行する。つまり、本実施の形態における携帯型端末１００１は、送信側装置２０３，２０３ａから送信されるデータパケットを同時に受信したり、送信側装置２０３から送信されるデータパケットの受信と、受信側装置６０３へのデータパケットの送信とを同時に実行したりする。

また、本実施の形態における携帯型端末１００１は、実施の形態１〜５と同様にＴＣＰに従った通信を行うとともに、ＵＤＰに従った通信を行う。したがって、携帯型端末１００１は、送信側装置２０３または受信側装置６０３と通信するときには、ＴＣＰに従ったデータの受信または送信を行い、送信側装置２０３ａと通信するときには、ＵＤＰに従い、送信側装置２０３ａから一定間隔ごとに送信されるデータを受信する。

なお、本実施の形態では、携帯型端末１００１により実行される間欠受信および間欠送信を総称して、間欠送受信と呼び、携帯型端末１００１により扱われる間欠受信パラメータおよび間欠送信パラメータを総称して、間欠送受信パラメータと呼ぶ。また、携帯型端末１００１，１００２はそれぞれ同一の機能と構成を有するため、携帯型端末１００１のみについて以下に説明する。

図３０は、本実施の形態における携帯型端末１００１の具体的な構成を示す構成図である。

本実施の形態における携帯型端末１００１は、通信アプリケーション部１０１１と、アプリ要求取得部１０１２と、パラメータ決定部１０１３と、抑制再開制御部１０１４と、電源制御部１０６と、通信制御部１０２７と、通信Ｉ／Ｆ部１０８と、ＲＴＴ推定部１０１９とを備える。

通信アプリケーション部１０１１は、実施の形態２の通信アプリケーション部１０１の機能と、実施の形態５の通信アプリケーション部６２１の機能とを兼ね備え、データを送信するための通信アプリケーションプログラムと、データを受信するための通信アプリケーションプログラムとを同時に実行したり、データを送信または受信するための２つの通信アプリケーションプログラムを同時に実行したりする。つまり、通信アプリケーション部１０１１は、アプリ要求取得部１０１２に起動通知を発行して、送信側装置２０３ａ、送信側装置２０３および受信側装置６０３ａのうち何れか２つの装置との間でデータの送受信を行う。

アプリ要求取得部１０１２は、実施の形態２のアプリ要求取得部１０２の機能と、実施の形態５のアプリ要求取得部６２２の機能とを兼ね備え、通信アプリケーション部１０１１から、性能パラメータを入手し、パラメータ決定部１０１３に対して、性能パラメータ登録通知または性能パラメータ削除通知を発行する。また、アプリ要求取得部１０１２によって入手される性能パラメータには、後述する「プロトコル」や「省電力優先度」が示されている。

抑制再開制御部１０１４は、実施の形態２の抑制再開制御部８０４の機能と、実施の形態５の抑制再開制御部６２４の機能とを兼ね備える。さらに、抑制再開制御部１０１４は、複数の通信アプリケーションプログラムの間欠送受信パラメータに従って、各通信アプリケーションプログラムによる間欠送受信の同期をとる。つまり、抑制再開制御部１０１４は、各通信アプリケーションプログラムにおける通信の抑制および再開を同時に行い、抑制時には、電源制御部１０６に対して通信Ｉ／Ｆ部１０８の電源を切断させる。通信の抑制および再開のタイミングについては後述する。さらに、本実施の形態の携帯型端末１００１は、ＵＤＰを用いてデータの受信を行う場合は、ＵＤＰパケットの受信間隔を特定し、その受信間隔に基づいて、ＵＤＰパケットの受信予想時刻を推定する。

ＲＴＴ推定部１０１９は、実施の形態２のＲＴＴ推定部８０９と同様に、各通信アプリケーションプログラムのＲＴＴを推定し、推定したＲＴＴをパラメータ決定部１０１３、抑制再開制御部１０１４および通信制御部１０２７に通知する。

パラメータ決定部１０１３は、実施の形態２のパラメータ決定部１０３の機能と、実施の形態５のパラメータ決定部６２３の機能とを兼ね備え、上述の間欠送受信パラメータを決定し、抑制再開制御部１０１４に間欠送受信パラメータ登録通知（間欠受信パラメータ登録通知または間欠送信パラメータ登録通知）または間欠送受信パラメータ削除通知（間欠受信パラメータ削除通知または間欠送信パラメータ削除通知）を送信する。

通信制御部１０２７は、実施の形態２の通信制御部１０７の機能と、実施の形態５の通信制御部６２７の機能とを兼ね備えるとともに、通信Ｉ／Ｆ部１０８を介して、送信側装置２０３ａからＵＤＰに従ったデータパケットの受信を行う。

図３１Ａおよび図３１Ｂは、アプリ要求取得部１０１２が管理するＵＤＰに関する性能パラメータ管理テーブルを示す図である。

性能パラメータ管理テーブル１０１２ａ，１０１２ｂはそれぞれ、ＵＤＰにより通信を行う起動済みの通信アプリケーションプログラムに対する性能パラメータを有する。その性能パラメータとしてはプロトコルや送信間隔がある。

プロトコルは、例えば「ＵＤＰ固定レート受信」や「ＵＤＰ可変レート送信」などのように、ＵＤＰ固定レートまたはＵＤＰ可変レートと、送信または受信との組み合わせにより規定されるパラメータである。送信間隔ＤＴは、ＵＤＰにより断続的に送信されるデータパケットの時間間隔を示すパラメータであり、プロトコルがＵＤＰ固定レートを示す場合に、性能パラメータ管理テーブルに設定され、プロトコルがＵＤＰ可変レートを示す場合には設定されない。

図３２Ａおよび図３２Ｂは、アプリ要求取得部１０１２が管理するＴＣＰに関する性能パラメータ管理テーブルを示す図である。

性能パラメータ管理テーブル１０１２ｃ，１０１２ｄはそれぞれ、ＴＣＰにより通信を行う起動済みの通信アプリケーションプログラムに対する性能パラメータを有する。その性能パラメータとしては、プロトコルや、省電力優先度、ストリームタイプ、帯域、遅延時間がある。なお、ストリームタイプ、帯域および遅延時間のパラメータは、図６Ａ、図６Ｂおよび図６Ｃに示すパラメータと同じである。

プロトコルは、例えば「ＴＣＰ送信」や「ＴＣＰ受信」などを示すパラメータである。省電力優先度は、間欠送受信のサイクルの基準となる通信アプリケーションプログラムを決定するためのパラメータである。

携帯型端末１００１のパラメータ決定部１０１３は、起動済みの２つの通信アプリケーションプログラムのそれぞれの性能パラメータ管理テーブルにより示されるプロトコルや省電力優先度などに基づいて、その２つの通信アプリケーションプログラムのうち、何れか一方をサイクル基準アプリケーションに決定する。つまり、パラメータ決定部１０１３は、そのサイクル基準アプリケーションによる間欠送受信のサイクルを基準（基準サイクル）とし、他方の通信アプリケーションプログラムによる間欠送受信のサイクルがその基準サイクルに同期するように、その他方の間欠送受信パラメータを決定する。

例えば、ＴＣＰにより通信を行う起動済みの２つの通信アプリケーションプログラムが起動している場合には、パラメータ決定部１０１３は、その２つの通信アプリケーションプログラムの性能パラメータ管理テーブルに示される省電力優先度を比較する。そして、パラメータ決定部１０１３は、省電力優先度の高い通信アプリケーションプログラムをサイクル基準アプリケーションに決定する。

また、パラメータ決定部１０１３は、起動済みの２つの通信アプリケーションプログラムの性能パラメータ管理テーブルに示されるプロトコルを比較し、一方のプロトコルがＴＣＰを示し他方のプロトコルがＵＤＰを示す場合には、ＵＤＰの通信アプリケーションプログラムをサイクル基準アプリケーションに決定する。プロトコルがＵＤＰの通信アプリケーションプログラムは再送制御を実施しないことから、間欠送受信の非給電状態でのパケットロスを極力避けなければならない。したがって、パラメータ決定部１０１３は、ＵＤＰの通信アプリケーションプログラムを優先的にサイクル基準アプリケーションに決定する。

なお、性能パラメータ管理テーブルに省電力優先度が設定されていない場合や、互いの性能パラメータ管理テーブルに示される省電力優先度が同じレベルである場合には、パラメータ決定部１０１３は、ＲＴＴ推定部１０１９から通知されたＲＴＴや、通信アプリケーションプログラムもしくはユーザによる指定に応じてサイクル基準アプリケーションを決定してもよい。

また、サイクル基準アプリケーションとならなかった通信アプリケーションプログラムは、サイクル基準アプリケーションと連動して動作することになる。そのため、パラメータ決定部１０１３は、サイクル基準アプリケーションとならなかった通信アプリケーションプログラムの間欠送受信パラメータを決定するときには、サイクルデータサイズＤｃｔを増やすなどして間欠送受信パラメータを調整し、通信アプリケーションプログラムからの要求が満たされるような間欠送受信パラメータを決定する。

パラメータ決定部１０１３は、ＴＣＰにより通信を行うサイクル基準アプリケーションの間欠受信パラメータを決定するときには、実施の形態１と同様に、間欠受信パラメータであるサイクル間隔ＴｃｔとサイクルデータサイズＤｃｔを決定する。また、パラメータ決定部１０１３は、ＵＤＰにより通信を行うサイクル基準アプリケーションの性能パラメータ管理テーブルに示される送信間隔ＤＴを、ＵＤＰにより送信されたパケットを受信する受信間隔や、ＵＤＰによりパケットを送信する送信間隔として用いる。

ここで、間欠送受信パラメータの決定方法について、以下詳細に説明する。

まず、通信アプリケーション部１０１１が２つの通信アプリケーションプログラムを起動し、一方の通信アプリケーションプログラムがＵＤＰの送受信を行い、もう一方の通信アプリケーションプログラムがＴＣＰの送受信を行う場合について説明する。

ＵＤＰの通信では、プロトコルによる再送制御が実施されないため、電源切断中にパケットを受信し、ロスすることは避けるべきである。また、ＶｏＩＰなどの送信では、パケット送信遅延により音声が乱れるなどの現象が発生するため、パケット送信遅延に対する制約が厳しい。そこでまず、携帯型端末１００１は、ＵＤＰとＴＣＰの通信の両方を行う場合、ＵＤＰの送受信を実行しようとする通信アプリケーションプログラムをサイクル基準アプリケーションとし、ＵＤＰパケットの送信間隔を守ることにより、パケットの送受信遅延に関する制約を守る。

パラメータ決定部１０１３は、ＵＤＰにより通信を行う通信アプリケーションプログラムをサイクル基準アプリケーションに決定し、そのサイクル基準アプリケーションの性能パラメータ管理テーブルに示される送信間隔ＤＴ＝ＤＴｕを特定する。そして、パラメータ決定部１０１３は、その送信間隔に基づいて、ＴＣＰにより通信を行う通信アプリケーションプログラムのサイクル間隔Ｔｃｔを決定する。

次に、パラメータ決定部１０１３は、ＴＣＰにより通信を行う通信アプリケーションプログラムのサイクルデータサイズを、その通信アプリケーションプログラムの性能パラメータ管理テーブルに示される帯域ＢＷに基づいて決定する。このとき、パラメータ決定部１０１３は、サイクル基準アプリケーションによるＵＤＰ通信の送信間隔ＤＴｕに、ＴＣＰの通信のサイクル間隔Ｔｃｔ（サイクル間隔Ｔｃｔの整数倍）を合わせて両通信の同期が取られている状態において、必要とされるサイクルデータサイズを決定する。

具体的に、ＴＣＰの性能パラメータ管理テーブルに示されるストリームタイプが帯域重視型である場合は、両通信の同期を取るために、パラメータ決定部１０１３は、ＴＣＰの通信のサイクル間隔ＴｃｔをＴｃｔ＝ＤＴｕに決定する。次に、実施の形態１と同様に、パラメータ決定部１０１３は、Ｄｃｔ＝Ｔｃｔ×ＢＷに従い、１回のサイクルにおいて送受信するデータサイズである、サイクルデータサイズＤｃｔを決定し、要求された帯域ＢＷを確保する。

一方、ＴＣＰの性能パラメータ管理テーブルに示されるストリームタイプが遅延時間重視型である場合は、まず、パラメータ決定部１０１３は、ＵＤＰの送信間隔ＤＴｕとＴＣＰの遅延時間ＤＴｔを比較する。ＵＤＰの送信間隔ＤＴｕよりも、ＴＣＰの遅延時間ＤＴｔのほうが長ければ、パラメータ決定部１０１３は、サイクル間隔ＴｃｔをＴｃｔ＝ＤＴｕに決定し、サイクルデータサイズＤｃｔをＤｃｔ＝Ｔｃｔ×ＢＷに決定する。逆に、ＴＣＰの遅延時間ＤＴｔの方が短ければ、ＤＴｕ＞Ｃ３×ＤＴｔとなるような整数Ｃ３を決定する。この場合、パラメータ決定部１０１３は、サイクル間隔ＴｃｔをＴｃｔ＝ＤＴｕ／Ｃ３に決定することで、ＵＤＰの送信間隔内に、ＴＣＰの送受信をＣ３回実行し、要求された遅延時間ＤＴｔを守る。そして、パラメータ決定部１０１３は、帯域重視型と同様に、Ｄｃｔ＝Ｔｃｔ×ＢＷにより、サイクルデータサイズＤｃｔを決定する。

なお、ＴＣＰの性能パラメータ管理テーブルに示されるストリームタイプがベストエフォート型の場合は、パラメータ決定部１０１３は、実施の形態１と同様に、間欠送受信パラメータを決定せず、携帯型端末１００１は間欠送受信を行わない。

次に、通信アプリケーション部１０１１が２つの通信アプリケーションプログラムを起動し、両方の通信アプリケーションプログラムがＴＣＰの送受信を行う場合について説明する。２つのＴＣＰの通信を動作させる場合は、パラメータ決定部１０１３は、各通信のためのサイクル間隔ＴｃｔとサイクルデータサイズＤｃｔを決定しなければならない。

ここでは、サイクル基準アプリケーションによる通信のサイクル間隔ＴｃｔをＴｃ１とし、その通信のサイクルデータサイズＤｃｔをＤｃ１とする。また、もう一方の通信アプリケーションプログラムによる通信のサイクル間隔ＴｃｔをＴｃ２とし、その通信のサイクルデータサイズＤｃｔをＤｃ２とする。

両方の通信がＴＣＰの送受信の場合、まず、パラメータ決定部１０１３は、各通信アプリケーションプログラムの性能パラメータ管理テーブルに示される省電力優先度を確認し、優先度の高い通信アプリケーションプログラムをサイクル基準アプリケーションに決定する。そして、パラメータ決定部１０１３は、サイクル基準アプリケーションのサイクル間隔Ｔｃ１とサイクルデータサイズＤｃ１とを、実施の形態１または実施の形態５と同様の方法で決定する。

次に、パラメータ決定部１０１３は、もう一方の通信アプリケーションプログラムについて、サイクルデータサイズＤｃ２とサイクル間隔Ｔｃ２とを決定する。この決定方法では、パラメータ決定部１０１３は、上述のＵＤＰの通信とＴＣＰの通信を同時に行う場合における決定方法において、ＵＤＰの送信間隔ＤＴｕをサイクル基準アプリケーションのサイクル間隔Ｔｃ１に置き換えて計算することより、サイクル間隔Ｔｃ２とサイクルデータサイズＤｃ２とを決定する。

図３３は、本実施の形態に係る携帯型端末１００１と送信側装置２０３ａおよび送信側装置２０３との省電力方法を示すシーケンス図である。

例えば、携帯型端末１００１は、図３１Ａに示す性能パラメータ管理テーブル１０１２ａに対応する通信アプリケーションプログラムにより、ＵＤＰに従って送信側装置２０３ａからデータを受信しながら、図３２Ｂに示す性能パラメータ管理テーブル１０１２ｄに対応する通信アプリケーションプログラムにより、ＴＣＰに従って送信側装置２０３からデータを受信する。なお、送信側装置２０３ａがＵＤＰパケットを送信する送信間隔をＤＴｕとし、送信側装置２０３ｂとの通信におけるサイクル間隔をＴｃｔとし、サイクルデータサイズをＤｃｔとし、ＲＴＴをＲＴＴｔとする。また、送信側装置２０３ａとの通信は、ＵＤＰを用いて行うので、上述の通り、ＵＤＰを用いた通信アプリケーションプログラムをサイクル基準アプリケーションとし、ＵＤＰの送信間隔ＤＴｕはＤＴｕ＝サイクル間隔Ｔｃｔとなる。そして、携帯型端末１００１は、送信間隔ＤＴｕの間隔でＵＤＰパケットを受信すること、つまりＵＤＰパケットを受信する時刻（受信予測時刻）を予測する。

本シーケンスでは、最初に、携帯型端末１００１は、間欠受信の初期状態において、送信側装置２０３ａおよび送信側装置２０３と通信するために、パラメータ決定部１０１３により、上記で説明した方法で間欠受信パラメータを決定する。

次に、携帯型端末１００１は、間欠受信の準備状態の処理を行う。このとき、携帯型端末１００１は、ＴＣＰを用いて送信側装置２０３と通信するために、実施の形態１と同様の方法により準備状態の処理を実施する。それに加えて、携帯型端末１００１のＲＴＴ推定部１０１９は、ＴＣＰの通信のＲＴＴであるＲＴＴｔを推定しておく。なお、携帯型端末１００１は、ＵＤＰを用いて送信側装置２０３ａと通信するときには、固定レートでパケット送受信を行うため、そのＵＤＰの通信のための準備状態の処理を行わない。

また、携帯型端末１００１の抑制再開制御部１０１４は、準備状態の処理が完了すると、サイクル基準アプリケーションによるＵＤＰパケットの受信のタイミングに同期してＴＣＰの通信アプリケーションプログラムによる通信が開始できるように、通信制御部１０２７によるＡＣＫパケットの送信を停止させて、送信側装置２０３ａとの通信を抑制しておく。

その後の定常状態では、抑制再開制御部１０１４は、時刻Ｔ１０１にサイクル間隔Ｔｃｔのタイマによる計時を開始し、送信側装置２０３からのデータ送信を再開させるため、通信制御部１０２７に対してＡＣＫ単発送信要求を発行する。したがって、携帯型端末１００１は、送信側装置２０３にＡＣＫパケットＰａ１を送信することで、間欠受信を開始する。ここで、開始するタイミング、つまりＡＣＫパケットＰａ１を送信するタイミング（時刻Ｔ１０１）は、送信側装置２０３ａからのＵＤＰパケットＰｕ１の受信予測時刻と、送信側装置２０３からのＴＣＰパケットＰｄ１の受信予測時刻とがちょうど一致するように調整されている。なお、ＴＣＰパケットＰｄ１は、送信側装置２０３から送信されるサイクルデータサイズＤｃｔ分のパケット全てを含む。

つまり、抑制再開制御部１０１４は、送信側装置２０３ａからのＵＤＰパケットＰｕ１の受信予測時刻を予測し、その受信予測時刻からＲＴＴｔ分さかのぼったタイミング（時刻Ｔ１０１）で、ＡＣＫ単発送信要求を発行して、ＡＣＫパケットＰａ１を送信させる。抑制再開制御部１０１４は、ＡＣＫパケットＰａ１の送信が完了した時刻Ｔ１０２に、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。そして、ＡＣＫパケットＰａ１送信完了後の時刻Ｔ１０２からＲＴＴｔ経過する時刻Ｔ１０３まで、送信側装置２０３ａおよび送信側装置２０３のいずれからもパケットを受信することがないため、抑制再開制御部１０１４は、通信Ｉ／Ｆ部１０８の電源を切断させておく。

次に、抑制再開制御部１０１４は、時刻Ｔ１０２からＲＴＴｔ経過したときの時刻Ｔ１０３に、送信側装置２０３ａおよび送信側装置２０３からパケットが到達するため、電源制御部１０６に対して投入要求を発行する。その投入要求により、電源制御部１０６は時刻Ｔ１０３に通信Ｉ／Ｆ部１０８の電源を投入する。そして、受信すべき全てのパケットを受信した後の時刻Ｔ１０４と、サイクルの開始時刻Ｔ１０１からサイクル間隔Ｔｃｔ経過した時刻Ｔ１０５との間にはパケットを送受信しないため、抑制再開制御部１０１４は、電源制御部１０６を制御することにより、その時刻Ｔ１０４から時刻Ｔ１０５まで、通信Ｉ／Ｆ部１０８の電源を切断させる。そして、携帯型端末１００１は、タイマによる計時の開始時刻Ｔ１０１からサイクル間隔Ｔｃｔが経過した時刻Ｔ１０５に、再度新しいサイクルを開始する。このように、送信側装置２０３ａのＵＤＰパケットの送信間隔ＤＴｕと、送信側装置２０３の通信のサイクル間隔Ｔｃｔとが同じであるため、この後も同期して間欠受信をすることが可能である。

このように本実施の形態における携帯型端末１００１では、複数の通信を並列に実行する場合にも、それらのタイミングを同期させることで、データを送受信しない期間を作り、その期間に通信Ｉ／Ｆ部１０８の電源を切断して、省電力効果の向上を図ることができる。

なお、サイクルデータサイズＤｃｔ分のＴＣＰパケットがサイクル間隔Ｔｃｔに受信されなかった場合には、携帯型端末１００１は、間欠受信を実施せず、ＴＣＰパケットを受信すると直ちにＡＣＫパケットを送信し、次のデータ（ＴＣＰパケット）を受信してもよい。この場合、サイクルデータサイズＤｃｔ分のＴＣＰパケットを受信できなかったサイクルの次のサイクルでは、携帯型端末１００１は、サイクルデータサイズＤｃｔに、前回のサイクルで受信できなかったデータのサイズを加算したサイズを、次のサイクルで必要となるサイクルデータサイズＤｃｔとし、次のサイクルを実行する。

また、図３３では、ＵＤＰを用いた受信とＴＣＰを用いた受信とを用いて、本実施の形態における携帯型端末１００１の省電力効果を説明したが、ＵＤＰを用いた受信とＴＣＰを用いた送信とを携帯型端末１００１が実行する場合でも、本実施の形態における携帯型端末１００１では、間欠送受信処理により省電力効果を向上させることが可能である。具体的には、本実施の形態で説明した例と同様に、携帯型端末１００１は、ＵＤＰを用いた受信に合わせて、データパケット（ＴＣＰパケット）の送信、もしくはデータパケット（ＴＣＰパケット）に対応するＡＣＫパケットの受信を実施する。例えば、ＵＤＰパケットの受信と、データパケットに対するＡＣＫパケットの受信とのタイミングを合わせる場合は、携帯型端末１００１は、図３３の時刻Ｔ１０１で、ＡＣＫパケットの送信の代わりに、サイクルデータサイズＤｃ分のデータパケットの送信を実施する。

また、図３３では、携帯型端末１００１は、送信側装置２０３との通信におけるサイクル間隔Ｔｃｔを送信間隔ＤＴｕと同じとすることで、両通信の同期をとっていたが、サイクル間隔Ｔｃｔを送信間隔ＤＴｕに等しくしなくても同期を取ることができる。この場合には、携帯型端末１００１は、ＵＤＰパケットの送信間隔ＤＴｕとは無関係にサイクル間隔Ｔｃｔを決定し、ＵＤＰパケットの受信予測時刻を推定し、各サイクル中の適切なタイミングにおいてＡＣＫ単発送信要求に基づくＡＣＫパケットを送信する。つまり、ＡＣＫパケットの送信時刻はサイクルの開始に依存せず、ＵＤＰパケットの受信予測時刻、ＲＴＴｔおよびサイクル間隔Ｔｃｔを用いることで、データの送受信のタイミングの同期を取ることができる。

図３４は、サイクル間隔Ｔｃｔと送信間隔ＤＴｕとが異なる場合に抑制再開制御部１０１４がデータの送受信のタイミングの同期を取るための動作を示すフローチャートである。

最初に、抑制再開制御部１０１４は、サイクルの開始時刻において、そのサイクルのサイクル間隔Ｔｃｔ内にＵＤＰパケットを受信するか否か、つまりＵＤＰパケットの受信予測時刻（以下、ＵＤＰ受信予測時刻という）が存在するか否かを判定する（ステップＳ６０１）。具体的には、抑制再開制御部１０１４は、（ＵＤＰ受信予測時刻−サイクルの開始時刻）がサイクル間隔Ｔｃｔよりも小さいか否かを判定する。

ここで、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻がサイクル間隔Ｔｃｔ内に存在しない（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞サイクル間隔Ｔｃｔ）と判定すると（ステップＳ６０１のＮｏ）、同期処理を行うことなく、サイクルの開始時刻にＡＣＫパケットを送信させる（ステップＳ６０５）。つまり、抑制再開制御部１０１４は、サイクルを開始すると同時に、実施の形態１と同様の方法により間欠受信制御を行う。

一方、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻がサイクル間隔Ｔｃｔ内に存在する（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＜サイクル間隔Ｔｃｔ）と判定すると（ステップＳ６０１のＹｅｓ）、さらに、ＵＤＰ受信予測時刻にＴＣＰパケット（データパケット）を受信できるか否かを判定する（ステップＳ６０２）。つまり、抑制再開制御部１０１４は、ＵＤＰパケットの受信と、ＡＣＫパケットの送信もしくはＴＣＰパケットの受信との同期を取るために、（ＵＤＰ受信予測時刻−サイクルの開始時刻）とＲＴＴｔとを比較する。抑制再開制御部１０１４は、（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞ＲＴＴｔであれば、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できると判定し、（ＵＤＰ受信予測時刻−サイクルの開始時刻）＜ＲＴＴｔであれば、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できないと判定する。

ここで、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できる（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞ＲＴＴｔ）と判定すると（ステップＳ６０２のＹｅｓ）、ＵＤＰパケットの受信とＴＣＰパケットの受信とを同期させる（ステップＳ６０３）。つまり、抑制再開制御部１０１４は、サイクルの開始時刻から｛（ＵＤＰ受信予測時刻−サイクルの開始時刻）−ＲＴＴｔ｝経過したタイミングで、ＡＣＫパケットを送信させる。

一方、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できない（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＜ＲＴＴｔ）と判定すると（ステップＳ６０２のＮｏ）、ＵＤＰパケットの受信とＡＣＫパケットの送信とを同期させる（ステップＳ６０４）。つまり、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻にＡＣＫパケットを送信させる。

そして、抑制再開制御部１０１４は、次のサイクルがあるか否かを判別し（ステップＳ６０６）、次のサイクルがないと判別したときには（ステップＳ６０６のＹｅｓ）、全ての処理を終了し、次のサイクルがあると判別したときには（ステップＳ６０６のＮｏ）、ステップＳ６０１からの処理を繰り返し実行する。

このようなサイクル間隔Ｔｃｔと送信間隔ＤＴｕとが異なるときの省電力方法について、図３５を用いてさらに詳細に説明する。

図３５は、本実施の形態に係る携帯型端末１００１と送信側装置２０３ａおよび送信側装置２０３との他の省電力方法を示すシーケンス図である。

携帯型端末１００１は、送信側装置２０３とのＴＣＰを用いた通信におけるサイクル間隔Ｔｃｔを決定するときには、送信側装置２０３ａとのＵＤＰを用いた通信における送信間隔ＤＴｕと異なるサイクル間隔Ｔｃｔを決定する。なお、図３５では、説明を簡単にするため、携帯型端末１００１がＡＣＫパケットの送信後ＲＴＴｔ経過まで電源を切断しないことを前提とする。

まず、携帯型端末１００１は、時刻Ｔ１１１に定常状態に達すると、上述したサイクル間隔Ｔｃｔと送信間隔ＤＴｕとが異なる場合の間欠受信制御に基づいて、ＡＣＫパケットの送信タイミングを決定する。携帯型端末１００１は、時刻Ｔ１１１から開始されるこのサイクルでは、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できる、つまり（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞ＲＴＴｔが成り立つと判定する。その結果、携帯型端末１００１は、時刻Ｔ１１１にサイクルを開始し、その時刻から（ＵＤＰパケットＰｕ１の受信予測時刻−サイクルの開始時刻Ｔ１１１−ＲＴＴｔ）が経過するタイミングになるまで、通信Ｉ／Ｆ部１０８の電源を切断しておく。次に、時刻Ｔ１１２に（ＵＤＰパケットＰｕ１の受信予測時刻−サイクルの開始時刻Ｔ１１１−ＲＴＴｔ）のタイミングとなると、携帯型端末１００１は、ＡＣＫ単発送信要求に基づくＡＣＫパケットＰａ１を送信側装置２０３に送信する。そしてＲＴＴｔ経過後、携帯型端末１００１は、送信側装置２０３ａからＵＤＰパケットを受信し、送信側装置２０３からＴＣＰパケットを受信する。携帯型端末１００１は、時刻Ｔ１１３で、受信すべき全てのデータを受信すると、通信Ｉ／Ｆ部１０８の電源を切断し、サイクルの開始時刻Ｔ１１１からサイクル間隔Ｔｃｔ経過後の時刻Ｔ１１４まで、その電源を切断しておく。

次に、携帯型端末１００１は、次のサイクルを開始する時刻Ｔ１１４に、次のＵＤＰパケットＰｕ２の受信予測時刻がそのサイクル中に発生するか否かを判断する。発生しないと判断すると、携帯型端末１００１は、そのサイクルの開始時刻Ｔ１１４に、ＡＣＫパケットＰａ２を送信する。携帯型端末１００１は、時刻Ｔ１１５に、そのＡＣＫパケットＰａ２に対応する全てのＴＣＰパケットＰｄ２を受信すると、その後、サイクルの終了時刻Ｔ１１６まで通信Ｉ／Ｆ部１０８の電源を切断する。

さらに、携帯型端末１００１は、次のサイクルの開始時刻Ｔ１１６に、そのサイクルでは、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できない、つまり（ＵＤＰ受信予測時刻−サイクルの開始時刻Ｔ１１６）＜ＲＴＴｔが成り立つと判定する。その結果、携帯型端末１００１はＵＤＰパケットＰｕ２を受信する時刻Ｔ１１７に、ＡＣＫパケットＰａ３を送信する。したがって、携帯型端末１００１は、時刻Ｔ１１６から時刻Ｔ１１７まで通信Ｉ／Ｆ部１０８の電源を切断しておく。

このように、サイクル間隔Ｔｃｔと送信間隔ＤＴｕが異なる場合も、ＵＤＰ受信予測時刻とサイクル間隔ＴｃｔとＲＴＴｔとを用いることで２つの通信の同期をとることができ、省電力効果を向上させることができる。

図３６は、本実施の形態に係る携帯型端末１００１と受信側装置６０３および送信側装置２０３との省電力方法を示すシーケンス図である。

携帯型端末１００１は、ＴＣＰを用いて受信側装置６０３にデータを送信しながら、ＴＣＰを用いて送信側装置２０３からデータを受信する。ここで、受信側装置６０３との通信におけるサイクル間隔をＴｃとし、サイクルデータサイズをＤｃａとし、ＲＴＴをＲＴＴａとする。また、送信側装置２０３との通信におけるサイクル間隔をＴｃとし、サイクルデータサイズをＤｃｂとし、ＲＴＴをＲＴＴｂとする。上記の説明の通り、サイクル間隔Ｔｃは、受信側装置６０３の通信と送信側装置２０３の通信とで、同一である。

また、携帯型端末１００１は、図３３の場合と同様に、サイクル基準アプリケーションのサイクルに合わせて、もう一方の通信のサイクル間隔ＴｃおよびサイクルデータサイズＤｃを決定することにより、サイクル間隔Ｔｃの同期をとり、送信抑制期間で通信Ｉ／Ｆ部１０８の電源を切断する。

最初に、携帯型端末１００１は、図３３と同様に初期状態において、受信側装置６０３および送信側装置２０３に対する間欠送受信パラメータを決定し、実施の形態２および実施の形態５と同様の準備状態の処理を実施し、間欠送受信可能な状態で各装置との通信を抑制しておく。ここで、本実施の形態では、受信側装置６０３との通信の省電力優先度が「高」であるものとする。よって、サイクル基準アプリケーションは、受信側装置６０３に対してＴＣＰを用いた送信処理を行う通信アプリケーションプログラムとなる。したがって、携帯型端末１００１は、送信側装置２０３に対する準備状態が完了すると、サイクル基準アプリケーションによる受信側装置６０３との通信と同期をとるため、送信側装置２０３の通信を抑制しておく。

そして、携帯型端末１００１は、受信側装置６０３および送信側装置２０３に対する準備状態の処理が完了すると、定常状態の処理を開始する。すなわち、携帯型端末１００１は、両通信のサイクル間隔Ｔｃの間にサイクルデータサイズ分のデータの送受信が完了すると、各装置に対する通信を抑制し、その通信が抑制された期間、通信Ｉ／Ｆ部１０８の電源を切断する。

具体的には、定常状態では、まず、携帯型端末１００１は、サイクル間隔Ｔｃの開始時刻Ｔ１２１に、受信側装置６０３に対してデータパケットＰｄａを送信すると同時に、送信側装置２０３にＡＣＫ単発送信要求に基づくＡＣＫパケットＰａｂを送信する。次に、携帯型端末１００１は、受信側装置６０３と送信側装置２０３とからパケットを受信するまで、それぞれＲＴＴだけ時間がかかるため、通信Ｉ／Ｆ部１０８の電源を切断する。具体的には、携帯型端末１００１は、受信側装置６０３に対してサイクル中に送信すべきデータパケットＰｄａが全て送信された時刻Ｔ１２２から、最初にデータパケットが到達する時刻Ｔ１２３まで、通信Ｉ／Ｆ部１０８の電源を切断する。なお、送信側装置２０３のＲＴＴｂの方が受信側装置６０３のＲＴＴａよりも短いため、最初に到達するデータパケットは、送信側装置２０３から送信されたデータパケットＰｄｂである。つまり、携帯型端末１００１は、受信側装置６０３のＲＴＴａの期間と、送信側装置２０３のＲＴＴｂの期間とが重なる期間（時刻Ｔ１２２〜時刻Ｔ１２３）に通信Ｉ／Ｆ部１０８の電源を切断する。

その後、携帯型端末１００１は、時刻Ｔ１２３に再度電源を投入し、送信したデータに対応するＡＣＫパケットＰａａを受信側装置６０３から受信するとともに、サイクルデータサイズＤｃｂ分のデータパケットＰｄｂを送信側装置２０３から受信する。その結果、時刻Ｔ１２５に、このサイクル間隔Ｔｃで受信側装置６０３および送信側装置２０３との間で行われるべき通信が全て完了するので、携帯型端末１００１は、時刻Ｔ１２５からサイクル間隔Ｔｃの終了点である時刻Ｔ１２６までを送信抑制期間とし、その期間において通信Ｉ／Ｆ部１０８の電源を切断する。

ここまでで、ＴＣＰを用いた送信とＴＣＰを用いた受信とを同時に動作させる場合の、１サイクルが完了する。携帯型端末１００１は、時刻Ｔ１２６以降も次のサイクルにおいて上述と同様の処理を実行することで、省電力効果を向上させることができる。

なお、図３６では、携帯型端末１００１の省電力方法について、携帯型端末１００１がＴＣＰを用いた送信とＴＣＰを用いた受信とを実行する場合を例に挙げて説明した。しかし、サイクル基準アプリケーションがどちらの通信アプリケーションプログラムになるかにかかわらず、ａ）ＴＣＰを用いた２つの送信処理を並列に実行する場合、ｂ）ＴＣＰを用いた２つの受信処理を並列に実行する場合でも、本実施の形態における携帯型端末１００１は間欠送受信処理により省電力効果を向上させることができる。以下に上記ａ）、ｂ）について具体的に説明する。

ａ）携帯型端末１００１がＴＣＰを用いた２つの送信処理を並列に実行する場合は、携帯型端末１００１は、サイクル間隔Ｔｃを開始する時点で、２つの受信側装置に対してデータパケットを送信し、対応するＡＣＫパケットを受信する。

ｂ）携帯型端末１００１がＴＣＰを用いた２つの受信処理を並列に実行する場合は、携帯型端末１００１は、サイクル間隔Ｔｃを開始する時点で、２つの送信側装置に対してＡＣＫ単発送信要求に基づくＡＣＫパケットを送信し、サイクルデータサイズＤｃ分のデータパケットを受信する。

このように、本実施の形態では、複数の通信アプリケーションプログラムが動作している携帯型端末においても、通信アプリケーションプログラムの同期をとりながら間欠送受信を行い、通信Ｉ／Ｆ部１０８の電源を切断する期間を定期的に設けることで、省電力効果を向上させることができる。

（実施の形態７）
本発明の実施の形態７に係る通信装置について説明する。本実施の形態では、間欠送受信処理に伴い通信Ｉ／Ｆ部１０８への電力供給を切り換えるだけでなく、他の構成要素の動作も切り換えることにより、省電力効果をさらに高める。

図３７は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型無線装置１１０２と、携帯型端末１１０１とを備え、携帯型端末１１０１と携帯型無線装置１１０２は基地局を経由することなく無線で直接通信する。

携帯型無線装置１１０２は、通信品質と省電力効果のさらなる向上を両立して図った通信装置であって、無線通信デバイスを搭載した無線端末として構成されている。また、この携帯型無線装置１１０２は、実施の形態６の携帯型端末１００１と同様にフロー制御付の通信を用いて、携帯型端末１１０１と通信する。本実施の形態では、この携帯型無線装置１１０２は、通信相手となる携帯型端末１１０１からのデータ取得の要求に対し、携帯型無線装置１１０２が記憶しているデータを送信する。なお、携帯型端末１１０１と携帯型無線装置１１０２との間の通信において、上位プロトコルでフロー制御付の通信を行っていれば、無線接続の方式は、Ｂｌｕｅｔｏｏｔｈ（登録商標）や、無線ＬＡＮのインフラストラクチャーモード、アドホックモードなどであってもよく、通信方式を限定しない。

図３８は、本実施の形態における携帯型無線装置１１０２の具体的な構成を示す構成図である。

本実施の形態における携帯型無線装置１１０２は、通信アプリケーション部１０１１と、アプリ要求取得部１０１２と、パラメータ決定部１０１３と、抑制再開制御部１１１４と、電源制御部１０６と、通信制御部１１１７と、通信Ｉ／Ｆ部１０８と、ＲＴＴ推定部１０１９と、記憶部１０１７とを備える。なお、本実施の形態において、実施の形態１〜６と同様の構成要素については、同一の参照符号を付して説明を省略する。つまり、本実施の形態における携帯型無線装置１１０２は、実施の形態６の抑制再開制御部１０１４の代わりに抑制再開制御部１１１４を備え、通信制御部１０２７の代わりに通信制御部１１１７を備え、さらに新規に記憶部１０１７を備えている。

記憶部１０１７は、通信アプリケーション部１０１１で利用するデータを記憶している。また、記憶部１０１７は、ハードディスクとキャッシュとモータとを備え、ハードディスクから読み出したデータをキャッシュに保存する。ハードディスクに記憶されているデータは、プラッタと呼ばれるディスク上に保存され、プラッタは、セクタとよばれる単位に分割されている。データの読み出しの際は、プラッタをモータで回転させてセクタの整数倍単位でデータの読み出しを行う。一方、キャッシュは、ディスクとは異なり、半導体メモリなどで構成され、モータを使用しない方式でデータを保存する。なお、記憶部１０１７は、抑制再開制御部１０１４からのデータ取得要求によりモータを起動して、ハードディスクからデータを読み出し、キャッシュに記憶すると同時に、キャッシュに記憶された必要分のデータのみを通信アプリケーション部１０１１に渡す。

抑制再開制御部１１１４は、間欠送受信処理を開始する際、携帯型無線装置１１０２が間欠送受信処理を行うことを通知する機能をさらに備える。間欠送受信処理は、通信相手が間欠送受信処理を行わない場合に省電力効果を高めることができる。そのため、携帯型無線装置１１０２は、間欠送受信処理を行う前に通信相手となる携帯型端末１１０１に対し、間欠送受信処理を行うことを通知し、その携帯型端末１１０１による間欠送受信処理を停止させる。

具体的には、抑制再開制御部１１１４は、通信制御部１１１７に、間欠送受信処理を行う旨を通知する。さらに、抑制再開制御部１１１４は、記憶部１０１７に対してデータ取得要求を行い、モータ起動のタイミングと間欠送受信処理のタイミングとを連動させる。

通信制御部１１１７は、抑制再開制御部１１１４から間欠送受信処理を行う旨を通知されると、ＴＣＰパケットに間欠送受信処理を行う設定を行う。具体的には、通信制御部１１１７は、携帯型端末１１０１との通信開始時のＴＣＰの３ＷＡＹハンドシェイクの際に、ＴＣＰヘッダのオプションフィールドに新たに間欠送受信有効フラグを追加する。間欠送受信有効フラグが有効であるＴＣＰパケットを受信した通信相手である携帯型端末１１０１は、間欠送受信処理を実施しない。

図３９は、本実施の形態における携帯型無線装置１１０２と携帯型端末１１０１の定常状態での動作を示すシーケンス図である。なお、本実施の形態における初期状態および準備状態の処理は、実施の形態５と同様のため、説明を省略する。

抑制再開制御部１１１４は、定常状態では、サイクルが開始される時刻Ｔ１３１に、最初のデータパケットＰ１を送信し、さらにそのタイミングで記憶部１０１７に対してデータ取得要求を行う。これにより、記憶部１０１７は、キャッシュにサイクルデータサイズ分のデータを保持している場合には、そのデータを通信アプリケーション部１０１１に渡す。また、記憶部１０１７は、キャッシュにサイクルデータサイズ分のデータを保持していなければ、ハードディスクのモータを起動し、サイクルデータサイズの整数倍のデータをキャッシュにコピーすると同時に、サイクルデータサイズ分のデータを通信アプリケーション部１０１１に渡す。これにより、ハードディスクのモータの起動回数を減らして、モータ起動時の電力を抑制することができる。

携帯型無線装置１１０２は、このような処理を繰り返すことにより、通信アプリケーションプログラムが必要とする全てのデータを送信する。

このように、本実施の形態では、データを送信する所定のタイミングのみで、記憶部１０１７のモータを起動することにより、携帯型無線装置１１０２の省電力効果を高めることができる。また、間欠送受信処理を行う前に、間欠送受信処理を行う旨を通知することで、確実に省電力効果を高めることができる。

なお、携帯型無線装置１１０２は、携帯型のハードディスクや、携帯型の音楽記録再生機、携帯型の動画記録再生機などの、無線通信により記憶しているデータを送信する装置であってもよい。

また、本実施の形態では、データ送信のタイミングに常にモータを起動してもよく、一度のモータの起動で、複数回分のデータをキャッシュに記憶させ、モータの起動および停止回数を削減してもよい。

また、本実施の形態では、記憶部１０１７のモータと同期させて、間欠送受信処理を行ったが、セルラー系の通信手段を持つ携帯型端末の場合、その通信の送受信タイミングと同期させて、間欠送受信処理を実施してもよい。

また、本実施の形態では、間欠送受信のタイミングに記憶部１０１７におけるモータの処理を同期させたが、他の処理を同期させてもよく、ＣＰＵ稼動時間が小さくなるように制御してもよい。

以上、本発明に係る通信装置について、実施の形態１〜７を用いて説明したが、本発明は、これらに限定されるものではない。

例えば、図５、図１２、図１４、図２２、図２５、図３０、および図３８に示す通信装置をそれぞれＬＳＩ（Large Scale Integration）などの半導体集積回路で構成してもよい。

また、実施の形態１〜７のそれぞれの特徴を組み合わせても本発明を実現することができる。

本発明の通信装置は、通信品質と省電力効果のさらなる向上を両立して図ることができるという効果を奏し、例えば、テレビやＤＶＤ（Digital Versatile Disk）プレーヤーなどの据え置き型の家電機器、携帯電話やＰＤＡ（Personal Digital Assistants）などの携帯機器、並びにパーソナルコンピュータなどに適用することができる。

本発明は、通信装置に関し、特に、省電力を目的とした通信装置および通信システム、ならびに省電力方法に関する。

近年、インターネットを中心としたＩＰ（Internet Protocol）ネットワークが急速に拡大している。つまり、ＰＣ（Personal Computer）だけでなく、テレビやＤＶＤ（Digital Versatile Disk）プレーヤーなどの据え置き型の家電機器におけるＩＰネットワークの利用が普及し始めるとともに、携帯電話やＰＤＡ（Personal Digital Assistants）、デジタルカメラなどの携帯型端末におけるＩＰネットワークの利用も普及し始めている。このようにインターネットなどのネットワークに接続可能な機器を通信装置と呼ぶ。

ＩＰネットワークを利用したサービスでは、音楽データや動画データのダウンロードやアップロード、さらには音声などのストリーミングデータの送受信などが行われ、長時間の通信を行うことがある。そのため、ＩＰネットワークを利用するための消費電力を軽視することができない状況となっている。通信装置を構成するデバイスの中でも、ＩＰネットワークを利用するためのネットワーク接続デバイスが特に多くの電力を必要としている。

ネットワーク接続デバイスには、有線によりＩＰネットワークを利用するデバイスと、無線によりＩＰネットワークを利用するデバイスとが存在する。消費電力を低減させるための省電力技術は、上述のような無線や有線を問わず、さまざまな機器に対して検討されている。その中でも携帯型端末では、内蔵のバッテリーのみで長時間使用するような使い方が想定されるため、省電力技術を特に必要としている。したがって、以下では、携帯型端末における省電力技術の例を説明する。

携帯型端末のネットワーク接続デバイスとしては、無線ＬＡＮ（Local Area Network）デバイスの利用が注目されている。無線ＬＡＮデバイスは比較的大きな電力を消費するので、その省電力化は重要な検討課題であり、多くの省電力化の手法が提案されている。

無線ＬＡＮの標準規格であるＩＥＥＥ８０２．１１では、無線端末の省電力化の方法として、パワーマネージメントのモード（パワーセーブモード）が規定されている。この方法では、無線端末は、パワーセーブモードで動作している場合、無線基地局（アクセスポイント）からビーコンが送信されるタイミングに合わせて受信動作を行ない、それ以外の間は受信動作を行なわない状態（ドーズモード）に入る。無線端末は、ドーズモードにおいて、その無線端末に備えられた無線ＬＡＮデバイスの電力供給を停止することにより、無線端末の消費電力を低減することができる。

図１は、パワーセーブモードでの無線端末の動作を説明するための説明図である。

無線端末は、送信側装置から送信されたデータを、アクセスポイント（ＡＰ）を介して受信する。このとき、無線端末は、アクセスポイントからビーコン（図１中の「Ｂ」のタイミングで送信される信号）が送信されるたびに、または複数のビーコンの送信に１回のタイミングで、受信状態（電源が投入された状態）に入り、そのビーコンを受信する。ここでは、この無線端末がビーコンを受信する一定の間隔を、「スリープ間隔」と呼ぶ。スリープ間隔は、無線端末とアクセスポイントの間の接続シーケンスなどによって、無線端末から設定または変更される。

また、図１に示すように、ドーズモードの期間中に無線端末宛に送信されたパケットは、一旦アクセスポイントでバッファリングされる。無線端末が次にビーコンを受信したときには、無線端末は、自分宛のパケットが届いていることが通知されるので、アクセスポイントに対してＰＳ−Ｐｏｌｌ（Ｐｏｗｅｒ Ｓａｖｅ Ｐｏｌｌ）パケットを送信する。ＰＳ−Ｐｏｌｌパケットを受信したアクセスポイントは、その無線端末宛のパケットをまとめて送信するので、ドーズモードの期間に送信されたパケットは正しく無線端末に受信される。

しかしながら、この方法では、省電力効果と通信品質（遅延時間や帯域）を両立させるのが難しいという問題がある。例えば、図１に示すように、送信側装置のデータ送信間隔に対して、スリープ間隔が長く設定されていると、大きな通信遅延が発生してしまう。この場合には、最大、スリープ間隔に相当する時間分だけの通信遅延が発生する可能性がある。一方、必要以上にスリープ間隔を短く設定すると、無駄なポーリングが発生し、省電力効果が小さくなってしまう。また、本来、ネットワークの通信状況や通信アプリケーションプログラムの要件（例えば、遅延時間や帯域の制限など）によって、適切なスリープ間隔は異なる。しかしながら、この方法ではスリープ間隔が固定のため、状況に応じた適切な省電力効果と通信品質が得られない。

上記の問題を解決するため、従来、通信アプリケーションプログラムが使用する通信データ帯域に応じてスリープ間隔を設定および変化させることで、通信品質と省電力効果とを両立させる方法が提案されている（例えば、特許文献１参照）。

図２は、上記特許文献１の無線端末の動作を説明するための説明図である。

特許文献１における無線端末は、図２に示す省電力設定リストを記憶しており、その省電力設定リストにはスリープ間隔（省電力設定）が設定されている。

具体的には、省電力設定リストには、無線端末で実行される各通信アプリケーションプログラムと、その通信アプリケーションプログラムが要求するデータ速度に対応する０〜１０までの省電力レベルと、その省電力レベルに対応するスリープ間隔（省電力設定）とが登録されている。

例えば、比較的速いデータ速度が要求される音声ストリーミングの通信アプリケーションプログラムには、省電力設定「ビーコンを毎回受信」および省電力レベル「１」が登録され、それよりもやや遅いデータ速度が要求されるウェブブラウザの通信アプリケーションプログラムには、省電力設定「ビーコンを２回に１回受信」および省電力レベル「２」が登録されている。また速いデータ速度が要求されない電子メールの通信アプリケーションプログラム（メールソフト）には、省電力設定「ビーコンを１０回に１回受信」および省電力レベル「１０」が登録され、極めて速いデータ速度が要求される動画ストリーミングの通信アプリケーションプログラムには、省電力設定「省電力制御を行なわない（ドーズモードに入らない）」および省電力レベル「０」が登録されている。

無線端末は、通信アプリケーションプログラムの起動または終了時に、省電力設定リストを元に、実行中の通信アプリケーションプログラムの中で最も省電力レベルが低いものを検索する。そして、無線端末は、その検索結果の省電力レベルに応じて省電力設定（スリープ間隔）を変更し、アクセスポイントにも省電力設定変更通知を送信する。

このように、特許文献１の無線端末（通信装置）は、通信アプリケーションプログラムの性質に応じて、ビーコンを受信する間隔（スリープ間隔）を変化させることで、適切な遅延時間や帯域で通信を行ないながら、消費電力を削減することもできる。
特開２００４−１８７００２号公報

しかしながら、上記特許文献１の通信装置であっても、通信品質と省電力効果とを十分に両立させることができないという問題がある。

つまり、従来の特許文献１に示す方式は、無線ＬＡＮの省電力方式の上で動作する方式であるため、無線ＬＡＮ特有の課題が発生する。具体的には、適用可能なネットワークが制限されるという第１の課題と、省電力制御とリアルタイム通信が両立できないという第２の課題と、アクセスポイントでデータの取りこぼしが発生してしまうという第３の課題とが発生する。

まず、第１の課題について説明する。特許文献１に記載の通信装置は、ＩＥＥＥ８０２．１１規定の省電力機能を有するアクセスポイントと連動して動作する。しかしながら、アクセスポイントによっては、ＩＥＥＥ８０２．１１規定の省電力機能をサポートしていないものや、機能を持っていてもデフォルトでＯＦＦになっているものがある。そのような環境では、たとえ携帯型端末側（通信装置側）で特許文献１に記載の省電力機能を搭載していたとしても、携帯型端末の省電力化が行なえない。また、同様の理由のため、携帯型端末（通信装置）がＩＥＥＥ８０２．１１以外のネットワークデバイスを使って通信（例えば、有線通信やＩＥＥＥ８０２．１１以外の無線通信）する際には、特許文献１記載の省電力方法を適用できない。このように、従来の特許文献１に示す方式は、適用可能なネットワークの条件が制限されており、ネットワークデバイスの種類や他の通信機器の実装状況によって、省電力化が行なえない場合が発生する。

次に、第２の課題について説明する。特許文献１の通信装置は、スリープ間隔を変化させるが、単にスリープ間隔のビーコン送信間隔に対する倍率を変化させるだけであるため、ビーコン送信間隔自体を自由に変更させることはできない。そのため、特許文献１の通信装置によるデータ受信は、ＩＥＥＥ８０２．１１の省電力方式と同じくビーコンの送信に連動したタイミングで行なわれる。その結果、特許文献１の通信装置では、リアルタイム通信に必要な遅延時間や帯域の要件を十分に満たすことができない。

以下、第２の課題を、遅延時間が長くなってしまうという問題と、通信帯域が低く抑えられるという問題とに分けて説明する。

まず、第２の課題における遅延時間が長くなってしまうという問題について説明する。特許文献１におけるスリープ間隔は、ビーコン送信間隔より短く設定できない。従って、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などの短時間おきにデータを送受信する通信アプリケーションプログラムでは、省電力制御を行なうと、遅延時間が長くなってしまう場合がある。特に、アクセスポイントのビーコン送信間隔が長く設定されていた場合には、遅延時間の増大により、音声品質が低下してしまう。

また、ビーコン送信間隔が短くても、１つのアクセスポイントに複数の無線端末（通信装置）が接続されている場合には、遅延時間が増大してしまうことがある。具体的には、リアルタイム性の要求される通信アプリケーションプログラムが複数の無線端末（通信装置）で動作している場合、ビーコン送信毎に同時に複数の無線端末からＰＳ−Ｐｏｌｌ（無線端末へのデータ送信を要求するパケット）が送信される。その場合、ＩＥＥＥ８０２．１１で規定されている、送信時のバックオフアルゴリズム（無線端末が送信可能状態になった後に実際にデータを送信できるまでに、あるランダム時間だけ待ってからデータを送信するアルゴリズム）に基づくと、特定の無線端末以外の１つ以上の無線端末が先に送信してしまう場合がある。このとき、先に送信を開始した無線端末からのデータ送信が完了するまで、その特定の無線端末はデータ送信を待たされてしまうため、待ち時間が増加する可能性が高くなってしまう。その結果、ＶｏＩＰなどの遅延時間に制限のある通信アプリケーションプログラムでは、遅延時間の増大が問題になる。さらに、無線端末側では、ビーコンを受信して実際にデータを受信し終わるまでドーズ状態に戻れないため、実際にデータの送受信を行なわない待ち時間も、無駄に電源を投入し続けることになり、省電力効果が小さくなる。

次に、第２の課題における通信帯域が低く抑えられるという問題について説明する。ビーコン送信間隔が長い条件で特許文献１の省電力化を行なうと、ＴＣＰ（Transmission Control Protocol）での通信帯域が低く抑えられてしまう。これは、後述するＴＣＰのフロー制御の仕組みにより、一度に受信できるデータサイズが、受信（無線端末）側のＴＣＰの受信バッファのサイズに制限されてしまうためである。高帯域でデータ受信を行なうには、大きな受信バッファを用意して一度に受信するデータを大きくするか、データ受信の間隔（＝スリープ間隔）を短く設定するか、のどちらかが必要となる。

ビーコン送信間隔が長い場合、スリープ間隔もビーコン送信間隔より短く設定できないので、高帯域の通信を行なうには膨大な受信バッファを搭載する必要がある。例えば、無線端末がＴＣＰの受信バッファを６４［ＫＢｙｔｅ］搭載していたとしても、ビーコン送信間隔が２００［ｍｓｅｃ］の場合、最大のスループットは、２．６［Ｍｂｐｓ］程度に抑えられてしまう。

このように、特許文献１の省電力制御および通信装置では、データ受信をビーコン送信のタイミングに連動させる必要があるため、遅延時間増大や帯域低下の課題が発生する場合がある。従って、遅延時間や帯域を確保するためには、ドーズモードに入らない（省電力制御を行なわない）という省電力設定を選択するしかなく、リアルタイム通信と省電力制御を両立することが十分にできない。

最後に、第３の課題について説明する。

特許文献１に記載の方式では、ＩＥＥＥ８０２．１１の省電力方式と同じく、アクセスポイントがドーズモード中の無線端末（通信装置）宛のパケットをバッファリングしている。しかしながら、送信側装置と携帯型端末（通信装置）間のデータ送受信は、常に一定レートではなく、通信装置内での処理の遅れやネットワーク内でのジッタなどにより、アクセスポイントにバッファリングされるデータ量は変化する。従って、想定以上のデータ量がバースト的に到着すると、アクセスポイントがバッファリングしきれずにデータを取りこぼしてしまう可能性がある。

そこで、本発明は、かかる問題に鑑みてなされたものであって、通信品質と省電力効果のさらなる向上を両立して図った通信装置を提供することを目的とする。

上記目的を達成するために、本発明に係る通信装置は、通信相手側装置と通信する通信装置であって、前記通信相手側装置に対してデータの送受信を行う通信手段と、前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態と、前記送受信に必要な電力が供給されていない非給電状態とに切り換える電源切換手段と、前記通信相手側装置に対してデータ（例えばＡＣＫパケットやＴＣＰのデータパケットなど）の送信を抑制させる抑制手段と、前記抑制手段によってデータの送信が抑制されていないときには、前記電源切換手段に対して、前記電力の状態を前記給電状態に切り換えさせ、前記抑制手段によってデータの送信が抑制されているときには、前記電源切換手段に対して、前記電力の状態を前記非給電状態に切り換えさせる切換制御手段とを備えることを特徴とする。例えば、前記通信装置は、さらに、データサイズである受信ウィンドウを含む送信要求データを前記通信手段から送信させることにより、前記通信相手側装置から前記受信ウィンドウ以下のデータを送信させて前記通信手段に受信させることを繰り返す通信制御手段を備え、前記抑制手段は、０より大きな値を示す受信ウィンドウを含む前記送信要求データを正送信要求データとし、当該正送信要求データの前記通信手段からの送信を停止することにより、前記通信相手側装置に対してデータの送信を抑制させる。また、前記抑制手段は、さらに、前記正送信要求データの送信の停止を解除することで、前記通信相手側装置からのデータの送信を再開させる。

これにより、抑制手段による任意のタイミングで、通信相手側装置からのデータの送信が抑制されて、そのときに通信手段に供給される電力が削減されるため、通信装置は、通信相手側装置に関わらず、つまり適用可能なネットワークの条件に制限されず、通信品質に支障が生じない適切なタイミングで、積極的にデータの送信を抑制させて省電力化を図ることができる。その結果、通信品質と省電力効果のさらなる向上を両立して図ることができる。

即ち、本発明の通信装置は、ＩＥＥＥ８０２．１１規定の無線ＬＡＮに依存しない方法で省電力化の制御を行うため、アクセスポイントとの連携を必要とせず、無線ＬＡＮのネットワーク環境に依存しない。また、このため、有線通信やＩＥＥＥ８０２．１１以外の無線通信時にも省電力制御が行なえる。

また、ＩＥＥＥ８０２．１１規定の無線ＬＡＮ環境を想定した場合にも、本発明は従来の特許文献１の技術と比べて以下の２つの利点がある。

まず第１に、本発明では、データ受信がアクセスポイントのビーコン送信のタイミングに連動せず、通信アプリケーションプログラムの要求する遅延時間や帯域に合わせたタイミングでデータ受信を行なうことができる。そのため、リアルタイム通信を行ないながら、つまり、リアルタイム通信に必要な遅延時間や帯域の要件を満たしながら、同時に省電力制御も両立することができる。

また第２に、本発明によれば、従来方法のようにドーズモードで受信したデータをアクセスポイントでバッファリングするのではなく、通信装置の電源を切断している間には、そもそも送信側装置（通信相手側装置）からのデータ送信がない状態にされている。そのため、送信側装置の処理またはネットワーク上でなんらかのジッタが発生したとしても、アクセスポイントでデータ溢れがおきるような課題も発生しなくなる。

また、前記通信制御手段は、前記通信手段でデータが受信されると、前記データを受信したことを通知する肯定応答パケットを前記送信要求データとして前記通信手段から送信させ、前記抑制手段は、前記通信手段でデータが受信されたときに前記正送信要求データとして送信されるべき、０より大きな値を示す受信ウィンドウを含む前記肯定応答パケットの、前記通信手段からの送信を停止することにより、前記通信相手側装置に対してデータの送信を抑制させ、０より大きな値を示す受信ウィンドウを含む前記肯定応答パケットを前記通信制御手段に生成させて送信させることにより、前記通信相手側装置からのデータの送信を再開させることを特徴としてもよい。例えば、前記通信制御手段は、ＴＣＰ（Transmission Control Protocol）に従って、前記肯定応答パケットを前記通信手段から送信させるとともに、前記肯定応答パケットに対して前記通信相手側装置から送信されたデータを前記通信手段に受信させる。

これにより、フロー制御の仕組みを使うＴＣＰに従った通信において、通信品質と省電力効果のさらなる向上を両立して図ることができる。

また、前記抑制手段は、さらに、前記通信相手側装置のデータの送信が抑制されているときに、受信ウィンドウとして０を示す送信要求データを前記通信手段から送信させることを特徴としてもよい。

例えば、通信相手側装置は、一定期間のうちに、受信ウィンドウとして０を示す送信要求データを受信できないときには、先に送信したデータが通信装置に受信されていないと判断して、そのデータを再送し、その後、送信要求データに対して送信可能なデータのサイズを減少させてしまうことがある。このような場合でも、本発明では、受信ウィンドウとして０を示す送信要求データが通信相手側装置に送信されるため、通信相手側装置からデータが送信されるのを抑えた状態で、通信相手側装置において送信可能なデータのサイズの減少を防ぐことができる。

また、前記通信装置は、さらに、サイクル時間およびサイクルデータサイズを決定する決定手段を備え、前記通信制御手段は、前記決定手段で決定されたサイクルデータサイズを前記受信ウィンドウとし、前記サイクルデータサイズを示す送信要求データを前記通信手段から送信させ、前記送信要求データを送信したタイミングをサイクル開始時点とし、前記抑制手段は、前記通信手段から前記送信要求データが送信されてから、前記決定手段で決定された前記サイクル時間が経過する時点をサイクル終了時点とし、前記サイクルデータサイズのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止し、前記サイクル終了時点を次のサイクルの前記サイクル開始時点として、前記サイクル開始時点から前記サイクル終了時点までの処理を前記サイクル時間ごとに繰り返させることを特徴としてもよい。例えば、前記決定手段は、前記通信装置と前記通信相手側装置との間で要求される通信の性能に基づいて、前記サイクル時間およびサイクルデータサイズを決定する。

これにより、サイクル時間（サイクル間隔）内において、送信要求データの送信と、その送信要求データに対するサイクルデータサイズ分のデータの受信と、送信要求データの送信の停止処理とを含む１つのサイクルを行い、さらに、そのサイクルを繰り返すことで、間欠的なデータの送受信を行うことができる。また、例えば、通信装置で実行される通信アプリケーションプログラムによって要求される通信帯域や遅延時間などの条件（性能）が満たされた状態で、その間欠的なデータの送受信を行うことができる。その結果、サイクル終了時点まで次の送信要求データの送信を停止していても、上述の通信帯域や遅延時間の要求を満足することができる。

また、前記切換制御手段は、前記通信相手側装置から前記サイクルデータサイズのデータが送信されて前記通信手段に受信された後、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記サイクル終了時点までに、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。

これにより、間欠的なデータ送受信の１サイクルにおいて、通信手段での消費電力を確実に減少させることができる。

また、前記通信相手側装置は、当該通信相手側装置から送信されたデータが消失して前記通信手段に受信されなかったことを検知すると、前記送信要求データに対して送信可能なデータのサイズである送信ウィンドウを減少させ、前記抑制手段は、前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいか否かを判別し、小さいと判別したときには、前記受信ウィンドウが前記送信ウィンドウ以下となるようなウィンドウ制御を行うことを特徴としてもよい。例えば、前記抑制手段は、前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に順次受信された各データの識別番号が連続であるか不連続であるかを判別し、不連続であると判別したときに、前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいと判別する。または、前記抑制手段は、前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に順次受信された各データの合計サイズが、予め定められた期間内で、前記送信要求データの示すサイクルデータサイズに達するか否かを判別し、達しないと判別したときに、前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいと判別する。

通信相手側装置が、データが消失して通信手段に受信されなかったことを検知すると、即ちパケットロスを検知すると、送信ウィンドウ（輻輳ウィンドウ）が減少するため、受信された送信要求データの示す受信ウィンドウ（サイクルデータサイズ）が送信ウィンドウよりも大きくなる場合がある。このような場合には、通信装置の通信手段は、送信要求データを送信しても、その送信要求データの示す受信ウィンドウ（サイクルデータサイズ）のデータを受信することができず、送信ウィンドウだけのデータを受信する。仮にこのような状態が継続されれば、通信装置の切換制御手段は、通信手段に供給される電力の状態を非給電状態に切り換えることができず、省電力化を行うことができない。

そこで、本発明では、通信手段に受信されたデータのサイズがサイクルデータサイズよりも小さい場合には、例えば、受信ウィンドウを低下させたり、送信ウィンドウをサイクルサイズ以上に回復させたりするように、前記受信ウィンドウが前記送信ウィンドウ以下となるようなウィンドウ制御を行うため、パケットロスが発生しても受信ウィンドウ≦送信ウィンドウの関係を維持して、上述のような間欠的なデータの送受信を行うとともに省電力化を図ることができる。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記サイクルデータサイズよりも小さいと判別したときには、前記ウィンドウ制御として、後に前記通信手段から送信される送信要求データの示す受信ウィンドウを前記サイクルデータサイズよりも小さくさせることを特徴としてもよい。

これにより、パケットロスが発生しても受信ウィンドウ≦送信ウィンドウの関係を確実に維持して、間欠的なデータの送受信を行うとともに省電力化を図ることができる。

また、前記通信相手側装置は、前記通信手段から送信要求データを受信して、前記送信要求データに対するデータを前記通信手段に送信することを繰り返すことによって、減少された前記送信ウィンドウを増加させ、前記抑制手段は、前記送信ウィンドウの増加に伴って、前記通信手段から送信される送信要求データの示す受信ウィンドウを増加させることを特徴としてもよい。

これにより、パケットロスなどによって、送信ウィンドウおよび受信ウィンドウが減少されても、それぞれ増加されるため、それぞれを元の値にして、通信状態を、パケットロスが発生する前の状態に回復させることができる。

また、前記抑制手段は、前記サイクルデータサイズよりも小さい受信ウィンドウを示す送信要求データが前記通信手段から繰り返し送信されている間、前記決定手段で決定されたサイクル時間を短くし、前記通信手段から前記送信要求データが送信されてから、短くされた前記サイクル時間が経過する時点をサイクル終了時点とし、前記受信ウィンドウのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止することを特徴としてもよい。

これにより、受信ウィンドウがサイクルデータサイズよりも小さくなっても、サイクル時間が短くされるため、単位時間当りに通信相手側装置から送信されて通信手段で受信されるデータの量を一定に、つまりスループットを一定に保つことができる。

また、前記通信相手側装置は、前記通信手段から送信要求データを受信して、前記送信要求データに対するデータを前記通信手段に送信することを繰り返すことによって、減少された前記送信ウィンドウを増加させ、前記抑制手段は、前記送信ウィンドウが前記サイクルデータサイズよりも小さくなってから前記サイクルデータサイズ以上になるまでのウィンドウ回復期間、前記ウィンドウ制御として、前記正送信要求データの送信の停止を解除することを特徴としてもよい。

これにより、パケットロスなどによって減少された送信ウィンドウを元の値に回復させることができる。

また、前記通信制御手段は、前記通信手段でデータが受信されると、次に受信すべきデータの識別番号を通知することで、前記通信手段でデータが受信されたことを、前記通信相手側装置に通知する肯定応答パケットを、前記送信要求データとして前記通信手段から送信させ、前記ウィンドウ回復期間では、前記肯定応答パケットを、互いに異なる前記識別番号を有する複数の肯定応答パケットに分けて前記通信手段から送信させることを特徴としてもよい。

これにより、通信装置が肯定応答パケットを通信相手側装置に送信し、その肯定応答パケットに対して通信相手側装置が通信装置にデータを送信するという、データ送受信の回数を、分割された肯定応答パケットの数だけ増加させることができる。その結果、通信相手側装置の減少された送信ウィンドウを早急に元の値に回復させることができる。

また、前記切換制御手段は、前記通信手段から前記送信要求データが送信された後に、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記送信要求データに対するデータが前記通信手段に受信される前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。例えば、前記切換制御手段は、前記通信手段から前記送信要求データが送信されてから所定時間が経過した後に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせる。または、前記通信装置は、さらに、前記通信手段から前記送信要求データが送信されてから、前記送信要求データに対するデータが前記通信相手側装置から送信されて前記通信手段に受信されるまでの応答時間を推定する推定手段を備え、前記切換制御手段は、前記通信装置から前記送信要求データが送信されてから前記応答時間が経過する前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせる。

これにより、通信装置は、送信要求データを送信してデータを受信するまでの間にも、通信手段の消費電力を削減することができ、通信品質を損なうことなく省電力化のさらなる向上を図ることができる。

また、前記通信手段は、前記通信相手側装置と通信端末との間における通信を中継することを特徴としてもよい。

これにより、例えば、従来の通信端末と通信相手側装置との間で行われるＴＣＰに従ったデータ通信を中継する場合にも、通信手段の消費電力を抑えることができ、通信品質と省電力効果のさらなる向上を両立して図ることができる。

また、前記通信装置は、さらに、送信データを前記通信手段から送信させることにより、前記通信相手側装置から肯定応答パケットを送信させて前記通信手段に受信させることを繰り返す通信制御手段を備え、前記抑制手段は、前記送信データの前記通信手段からの送信を停止することにより、前記通信相手側装置に対して肯定応答パケットの送信を抑制させることを特徴としてもよい。ここで、前記抑制手段は、さらに、前記送信データの送信の停止を解除することで、前記通信相手側装置からの肯定応答パケットの送信を再開させる。

これにより、本発明の通信装置が通信相手側装置に対して送信データを送る場合でも、抑制手段による任意のタイミングで、通信相手側装置からの肯定応答パケットの送信が抑制されて、そのときに通信手段に供給される電力が削減されるため、通信装置は、通信相手側装置に関わらず、つまり適用可能なネットワークの条件に制限されず、通信品質に支障が生じない適切なタイミングで、積極的にデータの送信を抑制させて省電力化を図ることができる。その結果、通信品質と省電力効果のさらなる向上を両立して図ることができる。

また、前記通信装置は、さらに、サイクル時間およびサイクルデータサイズを決定する決定手段を備え、前記通信制御手段は、前記決定手段で決定されたサイクルデータサイズ分の送信データを前記通信手段から送信させ、前記送信データを送信したタイミングをサイクル開始時点とし、前記抑制手段は、前記通信手段から前記送信データが送信されてから、前記決定手段で決定された前記サイクル時間が経過する時点をサイクル終了時点とし、前記送信データに対する肯定応答パケットが前記通信手段に受信されてから前記サイクル終了時点まで、前記送信データの前記通信手段からの送信を停止し、前記サイクル終了時点を次のサイクルの前記サイクル開始時点として、前記サイクル開始時点から前記サイクル終了時点までの処理を前記サイクル時間ごとに繰り返させることを特徴としてもよい。

これにより、サイクル時間（サイクル間隔）内において、送信データの送信と、その送信データに対する肯定応答パケットの受信と、送信データの送信の停止処理とを含む１つのサイクルを行い、さらに、そのサイクルを繰り返すことで、間欠的なデータの送受信を行うことができる。また、例えば、通信装置で実行される通信アプリケーションプログラムによって要求される通信帯域や遅延時間などの条件（性能）が満たされた状態で、その間欠的なデータの送受信を行うことができる。その結果、サイクル終了時点まで次の送信データの送信を停止していても、上述の通信帯域や遅延時間の要求を満足することができる。

また、前記通信手段は、前記通信相手側装置および他の通信相手側装置との間でデータの送受信を並列に行い、前記決定手段は、前記通信手段が前記他の通信相手側装置との間で一定時間ごとに送受信を繰り返す場合、前記他の通信相手側装置との間の送受信と、前記通信相手側装置からのデータの受信とが同期するように、前記一定時間に基づいて前記サイクル時間を決定することを特徴としてもよい。例えば、前記決定装置は、前記通信手段が前記他の通信相手側装置から一定時間ごとに固定レートでデータを受信することを繰り返す場合に、前記一定時間を基準とし、前記一定時間に基づいて前記サイクル時間を決定することを特徴としてもよい。

これにより、例えばサイクル時間を上述の一定時間に等しくすれば、抑制手段が通信相手側装置に対してデータの送信を抑制させている期間を、他の通信相手側装置からデータが受信されていない期間に合わせることができる。つまり、通信装置は通信相手側装置および他の通信相手側装置との間の通信を同期させることができ、上述の期間において通信手段に供給される電力を切断することで、通信装置は通信相手側装置および他の通信相手側装置との間で通信を行いながら省電力効果を向上することができる。

また、前記通信手段は、前記通信相手側装置および他の通信相手側装置との間でデータの送受信を並列に行い、前記抑制手段は、前記通信手段が前記他の通信相手側装置から一定時間ごとに固定レートでデータを受信することを繰り返す場合、前記他の通信相手側装置からのデータが前記通信手段に受信されるタイミングと、前記通信相手側装置からのデータが前記通信手段に受信されるタイミングとが一致するように、前記通信手段からの前記正送信要求データの送信の停止および解除を行うことを特徴としてもよい。

これにより、上述のようにサイクル時間を上記一定時間に等しくしなくても、他の通信相手側装置からのデータが通信手段に受信されるタイミングと、通信相手側装置からのデータが通信手段に受信されるタイミングとが一致するため、抑制手段が通信相手側装置に対してデータの送信を抑制させている期間を、他の通信相手側装置からデータが受信されていない期間に合わせることができる。その結果、その期間において通信手段に供給される電力を切断することで、通信装置は通信相手側装置および他の通信相手側装置との間で通信を行いながら省電力効果を向上することができる。

また、前記抑制手段は、上述のようなデータの送信を抑制させる制御を行うことを、前記通信制御手段に通知する間欠受信実施通知手段を備え、前記通信制御手段は、前記間欠受信実施通知手段からの通知を受け付けたときには、前記通信手段から送信されるパケットに、前記通知の内容を示す情報を設定することを特徴としてもよい。

また、前記通信制御手段は、ＴＣＰ（Transmission Control Protocol）に従って、前記送信データを前記通信手段から送信させるとともに、前記送信データに対して前記通信相手側装置から送信された前記肯定応答パケットを前記通信手段に受信させることを特徴としてもよい。

また、前記切換制御手段は、前記通信相手側装置から前記肯定応答パケットが送信されて前記通信手段に受信された後、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記サイクル終了時点までに、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。

また、前記切換制御手段は、前記通信手段から前記送信データが送信された後に、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、前記送信データに対する少なくとも一つの肯定応答パケットが前記通信手段に受信される前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせることを特徴としてもよい。

また、前記通信制御手段は、送信データを一時的に保持するデータ保持手段を備え、送信データが送信されてから一定時間内に前記肯定応答パケットが前記通信手段に受信されなかった場合、前記データ保持手段に保持されている送信済みの送信データを、次のサイクルの最初の送信データとして前記通信手段に再送させることを特徴としてもよい。

また、前記抑制手段が、前記サイクルデータサイズの送信データが送信された後、前記肯定応答パケットが前記通信手段に到達しないと判断した場合、前記通信制御手段は、前記肯定応答パケットが到達するまで、前記通信手段に送信済みの前記送信データを再送させることを特徴としてもよい。

また、前記抑制手段は、前記肯定応答パケットを受信するのに必要となる前記送信データのパケット数である遅延応答回避パケット数に基づき、前記サイクルデータサイズ分の送信データを前記遅延応答回避パケット数の整数倍に分割することを前記通信制御手段に対して要求し、前記通信制御手段は、前記要求に従い、前記サイクルデータサイズ分のデータを前記遅延応答回避パケット数の整数倍に分割して前記通信手段から送信させることを特徴としてもよい。

また、前記通信装置は、さらに、一定時間ごとに処理の開始および停止を繰り返す間欠処理手段を備え、前記間欠処理手段は、前記間欠処理手段による処理の開始および停止の時間間隔を、前記サイクル時間に合わせることを特徴としてもよい。

また、前記通信装置は、さらに、一定時間ごとに処理の開始および停止を繰り返す間欠処理手段を備え、前記間欠処理手段は、前記間欠処理手段による処理の開始時点を、前記サイクル開始時点に合わせることを特徴としてもよい。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記期待値よりも小さいと判別したときには、前記正送信要求データの送信の停止を解除することを特徴としてもよい。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記期待値よりも小さいと判別したときには、後に前記通信手段から送信される送信要求データの前記受信ウィンドウを前記サイクルデータサイズよりも小さい値にして、さらに後に前記通信手段から送信される送信要求データの前記受信ウィンドウを前記値よりも大きくすることを特徴としてもよい。

また、前記抑制手段は、前記通信手段に受信されたデータのサイズが前記期待値よりも小さいと判別したときには、前記決定手段で決定されたサイクル時間を短くし、前記通信手段から前記送信要求データが送信されてから、短くされた前記サイクル時間が経過する時点をサイクル終了時点とし、前記受信ウィンドウのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止することを特徴としてもよい。

なお、本発明は、このような通信装置として実現することができるだけでなく、その通信装置を含んで構成される通信システムや、その通信装置が通信する通信方法や、その通信装置の消費電力を削減する省電力方法や、その通信装置を動かすためのプログラムや、そのプログラムを格納する記憶媒体や、集積回路としても実現することができる。

本発明の通信装置は、通信品質と省電力効果のさらなる向上を両立して図ることができるという作用効果を奏する。また、本発明の通信装置は、フロー制御の仕組みを利用した省電力制御を有し、持ち運び可能な通信装置（一般的には、無線端末）が、リアルタイム通信をしながら電力消費も抑えたいような使い方（例えば、他の通信装置からネットワーク経由で長時間にわたってデータを受信するような場合）に有用である。さらに、無線ＬＡＮに限らず、有線通信や他の無線デバイスを使った通信など、様々なネットワーク環境の通信装置にも適用可能である。また、従来の無線ＬＡＮの省電力方法にあった、アクセスポイントのバッファ容量溢れによるデータロスの課題も防ぐことができる。

（実施の形態１）
以下、本発明の第１の実施の形態における通信装置について図面を参照しながら説明する。

図３は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型端末２１１，２１２と、無線基地局２０２と、インターネット２０４と、送信側装置２０３とを備えている。

携帯型端末２１１，２１２は、通信品質と省電力効果のさらなる向上を両立して図った通信装置であって、無線通信デバイスを搭載した無線端末として構成されている。携帯型端末２１１，２１２は、無線基地局２０２を介してインターネット２０４に接続する。

送信側装置２０３は、インターネット２０４上に接続されている通信装置である。送信側装置２０３は、他の機器からの接続を受け付けて、相手にコンテンツデータなどを送信する機能を持つ。

このような通信システムでは、携帯型端末２１１，２１２は、インターネット２０４を介して送信側装置２０３と接続し、送信側装置２０３からのデータを受信する。携帯型端末２１１と送信側装置２０３の間のデータ送受信には、ＴＣＰ（Transmission Control Protocol）のようなフロー制御付きプロトコルが使われる。

なお、図３に示す携帯型端末２１１，２１２は、それぞれ同等の構成を備え、同等の動作を行なう装置であるため、以下の説明では、簡略化のため、携帯型端末２１１について詳細に説明する。また、携帯型端末２１１を受信側装置として以下説明する。

本実施の形態における携帯型端末２１１は、フロー制御を利用する。フロー制御とは、受信側装置のデータ受信処理が追いつかなくなる事態を防ぐために、受信側装置が送信側装置にデータ送信の停止および再開を指示する制御である。この制御は、受信側装置でのデータあふれを防ぐための制御として、各種の通信プロトコルで行なわれている。

以下、ＴＣＰにおけるフロー制御の仕組みを説明する。ＴＣＰレベルのフロー制御は、受信ウィンドウ（一般的に、受信側装置のＴＣＰ受信バッファの空き容量に相当）を送信側装置に伝えることで、それ以上のデータが受信側装置に送られないように調整している。具体的には、受信ウィンドウは、ＴＣＰヘッダの「ウィンドウサイズ」のフィールドに格納され、受信側装置から送信側装置へのＡＣＫパケット（肯定応答パケット）を使って通知される。送信側装置では、ＡＣＫパケットを監視し、送信済みのデータサイズとＡＣＫパケットで通知された受信ウィンドウとの関係から、送信可能なデータサイズの上限を知り、その上限を超えて送信しないようにする。なお、ＴＣＰヘッダには、さらにシーケンス番号（送信するデータのストリーム全体の位置を示す番号）とＡＣＫ番号（次に受信するデータのシーケンス番号）のフィールドがあり、受信側装置はＡＣＫパケットのＡＣＫ番号を使って、どこまでのデータを受信したのかを送信側装置に通知する。

一方、受信側装置の処理が滞った場合のように、受信側装置が受信ウィンドウを更新しない（ＡＣＫパケットを返せない）状況が続くと、送信側装置の送信可能なデータサイズが減少する。最終的に送信可能なデータサイズが０になると、送信側装置からそれ以上のデータの送信ができなくなる。すなわち、この状態では、新たなデータ受信を示すＡＣＫパケットを受け取るか、より大きな受信ウィンドウを通知されるまでは、送信側装置は送信を行えなくなる。その後、受信側装置がデータ受信可能な状態になったら、改めてＡＣＫパケットを送信側装置に送って、新たな受信ウィンドウを通知すれば、送信側装置からのデータ送信が再開する。

本発明では、このようなフロー制御の仕組みを、（受信側装置の停滞などによる）データあふれ回避の目的ではなく、受信側装置が送信側装置からの間欠的なデータ送信を能動的に実行させる目的で利用する。

図４は、受信側装置である携帯型端末２１１と送信側装置２０３との基本的な処理の一例を示すシーケンス図である。

携帯型端末２１１（上述の受信側装置に相当する）と送信側装置２０３とは、ＴＣＰを使ったデータ送受信を行なう。

まず、携帯型端末２１１は、送信側装置２０３がバースト的に送信するデータサイズの上限を決め、それを受信ウィンドウとして送信側装置２０３へ通知する（ステップＳ７０１）。例えば、送信側装置２０３が１パケットで送信するデータサイズがＤｓｅｇ［バイト］である場合、携帯型端末２１１は、送信側装置２０３の送信するデータのサイズの上限を、４パケット分（＝４×Ｄｓｅｇ［バイト］）に決定する。そして、携帯型端末２１１は、受信ウィンドウ（以後、ＲＷＩＮと呼ぶ）を「４×Ｄｓｅｇ」に設定したＡＣＫパケットを、送信側装置２０３に送信する。

送信側装置２０３は、ＲＷＩＮ＝４×Ｄｓｅｇ［バイト］のＡＣＫパケットを受信することにより、送信可能なデータサイズ（以下、ｕｗｎｄという）が４×Ｄｓｅｇ［バイト］であることを把握し、データ送信を再開できるようになる。なお、送信側装置２０３は、そのＡＣＫパケットの受信前には、送信可能なデータサイズをｕｗｎｄ＝０として把握しており、データ送信を停止している。

次に、送信側装置２０３は、Ｄｓｅｇ［バイト］のパケットを４回だけ送信し、１回送信するごとにｕｗｎｄをＤｓｅｇ［バイト］分だけデクリメントする（ステップＳ７０２〜Ｓ７０５）。

一方、携帯型端末２１１は、ステップＳ７０２〜Ｓ７０５で送信側装置２０３から送信されたデータ（パケット）を受信するが、ＡＣＫパケットを返さない制御を行なう。その結果、送信側装置２０３は、４回目のパケットを送信した時点（ステップＳ７０５）でｕｗｎｄが０になるため、データ送信を停止する。このようにして、携帯型端末２１１は「送信側装置がデータを送信できない期間」を作ることができる。以後、送信側装置がデータを送信できない期間のことを、送信抑制期間と呼ぶ。その後、携帯型端末２１１は、所望のタイミングで「ＲＷＩＮ＝４×Ｄｓｅｇ」のＡＣＫパケットを送信することで、送信側装置２０３にデータ送信の再開を指示する（ステップＳ７０６）。

携帯型端末２１１は、フロー制御の仕組みを使って上記のようなデータ送信の抑制と再開の指示を繰り返すことで、携帯型端末２１１の所望する間隔での間欠的なデータ受信（間欠受信）を行う。そして、携帯型端末２１１は、受信の合間の送信抑制期間に、携帯型端末２１１の備える通信Ｉ／Ｆ部の電源を切断し、実際にデータやＡＣＫパケットの送受信を行なう期間だけ通信Ｉ／Ｆ部の電源を投入することで、携帯型端末２１１の省電力化を行なう。

なお、本実施の形態では、間欠的に通信Ｉ／Ｆ部の電源を切断または投入することにより省電力制御を行うが、必ずしも完全に電源を切断する必要はなく、通信Ｉ／Ｆ部に電力を供給した状態でその電力を調整してもよい。つまり、携帯型端末２１１は、通信Ｉ／Ｆ部によるデータの送受信の必要がない期間には、通信Ｉ／Ｆ部に供給される電力を、通信Ｉ／Ｆ部の送受信機能を正常に動作させるために必要な電力（以下、通常電力という）よりも抑え、データの送受信の必要がある期間には、通信Ｉ／Ｆ部に供給される電力を通常電力に戻す。即ち、本発明における省電力制御では、通信Ｉ／Ｆ部の消費電力を、通常電力よりも低い状態に変化させる制御であればよい。例えば、携帯型端末２１１に低消費電力モードが定義されている場合は、携帯型端末２１１は、通信Ｉ／Ｆ部の電源を切断する代わりに低消費電力モードに移行する。または、携帯型端末２１１は、通信Ｉ／Ｆ部への電源（電流）の供給を停止したり、クロックの供給を停止したりする。そして、携帯型端末２１１は、消費電力を通常電力に復帰させるときには、電源を投入したり、供給電力を増加させたり、クロックの提供を開始したりするなど、上記それぞれと逆の操作を行う。

このように、本発明では、フロー制御の仕組みを使って、携帯型端末（受信側装置）２１１がデータ受信の無い期間を能動的に作り、その期間に電源をＯＦＦにすることで省電力化を図る。従って、省電力化の制御は、受信側装置のみで行なわれ、無線ＬＡＮの省電力方式のように、アクセスポイントとの連携を必要としない。そのため、ネットワーク環境に依存せずに省電力制御が行なえる。

また、本発明では、データ受信のタイミングは、アクセスポイントのビーコン送信のタイミングに連動せず、受信側装置で自由に制御できる。従って、通信アプリケーションプログラムの必要とする遅延時間と帯域を確保できるように、データ受信の間隔およびデータサイズを調整すれば、所望の通信を継続しながら、同時に省電力化も両立して行うことができる。

さらに、本発明では、アクセスポイントでデータをバッファリングせず、受信側装置の受信可能なタイミングおよびデータサイズで送信側装置がデータを送信するので、アクセスポイントでのデータ溢れの発生を防ぐこともできる。

ここで、本実施の形態における携帯型端末２１１について詳細に説明する。

図５は、携帯型端末２１１の具体的な構成を示す構成図である。

携帯型端末２１１は、通信アプリケーション部１０１と、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部１０４と、電源制御部１０６と、通信制御部１０７と、上述の通信Ｉ／Ｆ部１０８とを備える。

なお、本実施の形態では、通信Ｉ／Ｆ部１０８が通信手段として構成され、電源制御部１０６が電源切換手段として構成され、抑制再開制御部１０４が抑制手段および切換制御手段として構成されている。

通信アプリケーション部１０１は、通信アプリケーションプログラムを実行する。通信アプリケーション部１０１は、通信アプリケーションプログラムの起動時に、アプリ要求取得部１０２に起動通知を発行し、送信側装置２０３との間でデータ送受信を行なう。また、通信アプリケーション部１０１は、通信アプリケーションプログラムの終了時に、アプリ要求取得部１０２に終了通知を発行する。なお、本実施の形態では、説明の単純化のため、携帯型端末２１１上で同時に動作する通信アプリケーションプログラムが１つに限定されているものとする。

アプリ要求取得部１０２は、通信アプリケーション部１０１と送信側装置２０３との間でのデータ通信の「性能パラメータ」を入手する。ここで、「性能パラメータ」とは、通信アプリケーションプログラムによって独自に決められた帯域や遅延時間、一度に送信するパケットのサイズなどの条件（性能要件）を示すパラメータである。アプリ要求取得部１０２は、通信アプリケーション部１０１から起動通知または終了通知を受けると、同時に性能パラメータを通信アプリケーション部１０１から入手し、パラメータ決定部１０３に対して、性能パラメータ登録通知または性能パラメータ削除通知を発行する。

パラメータ決定部１０３は、間欠的にデータを受信するためのパラメータを決定する。間欠的にデータを受信するためのパラメータは、間欠受信の１サイクル分の時間間隔、および１サイクルの間に受信するデータサイズの２つから成る。以後、前者のパラメータを「サイクル間隔」と呼び、後者のパラメータを「サイクルデータサイズ」と呼ぶ。また、これらの２つのパラメータを総称して「間欠受信パラメータ」と呼ぶ。パラメータ決定部１０３は、アプリ要求取得部１０２から性能パラメータ登録通知または性能パラメータ削除通知を受けつけたとき、アプリ要求取得部１０２からの性能パラメータを元に間欠受信パラメータを決定し、抑制再開制御部１０４に間欠受信パラメータ登録通知または間欠受信パラメータ削除通知を送信する。

抑制再開制御部１０４は、送信側装置２０３からのデータ送信が間欠的に行なわれるように、ＴＣＰのフロー制御の仕組みを使って通信制御部１０７を制御する。さらに、抑制再開制御部１０４は、このＴＣＰのフロー制御によって得られた送信抑制期間（送信側装置２０３からのデータ送信が無い期間）に通信Ｉ／Ｆ部１０８の電源が切断されるように、電源制御部１０６へ指示を出す。

具体的には、抑制再開制御部１０４は、間欠受信パラメータ登録通知によって受け取った間欠受信パラメータに応じて、送信側装置２０３からのデータ送信を抑制または再開させるタイミングを決定する。また、抑制再開制御部１０４は、決定したタイミングに、送信側装置２０３からのデータ送信を抑制または再開させるため、通信制御部１０７に対してＡＣＫパケットに関係する３つの要求（後述）を発行する。また、抑制再開制御部１０４は、送信抑制期間に連動して、電源制御部１０６に対して投入または切断の要求を送信する。さらに、抑制再開制御部１０４は、通信制御部１０７で送受信するＴＣＰパケットをモニタリングし、そのモニタリングの結果を上述のタイミングの決定に利用する。

電源制御部１０６は、抑制再開制御部１０４からの投入または切断の要求に従って、通信Ｉ／Ｆ部１０８の電源を投入または切断する。

通信制御部１０７は、通信アプリケーション部１０１からのデータを、通信Ｉ／Ｆ部１０８より送信するための制御を行なうとともに、通信Ｉ／Ｆ部１０８で受信したデータを通信アプリケーション部１０１に渡すための制御を行なう。この制御には、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）などのプロトコル処理や、無線基地局２０２との間のネゴシエーション処理などが含まれる。通信制御部１０７で送受信するＴＣＰパケットは、抑制再開制御部１０４からモニタリングされる。さらに、通信制御部１０７は、通常のＴＣＰ処理に加えて、抑制再開制御部１０４からの要求を受けて、ＡＣＫパケットの送信タイミングやパケット内容を変更する。具体的には、通信制御部１０７は、抑制再開制御部１０４から、ＡＣＫ通常送信抑制要求、ＡＣＫ通常送信再開要求、およびＡＣＫ単発送信要求を受けて、それらの要求に対応する。

ＡＣＫ通常送信抑制要求は、通常のＡＣＫパケット送信を抑制させる要求である。通信制御部１０７は、この要求を受けると、以後、ＴＣＰのデータ受信に連動してＡＣＫパケットを送信しなくなる。

ＡＣＫ通常送信再開要求は、ＡＣＫ通常送信抑制要求を解除させる要求である。通信制御部１０７は、この要求を受けると、通常のＴＣＰ処理（ＴＣＰのデータ受信に連動したＡＣＫパケットの送信）を再開する。

ＡＣＫ単発送信要求は、抑制再開制御部１０４から指定されたタイミングで、抑制再開制御部１０４から指定された内容のＡＣＫパケットを送信させる要求である。通信制御部１０７は、この要求を受けると、ＴＣＰのデータ受信タイミングに関係なく、指定された内容のＡＣＫパケットを指定されたタイミングで送信する。なお、この要求は、ＡＣＫ通常送信抑制要求を受けている状態でも有効である（送信可能である）。

通信Ｉ／Ｆ部１０８は、通信制御部１０７より受け取ったデータを無線で送信する処理を行なう。また、無線基地局２０２から受信したデータを通信制御部１０７へ渡す処理を行なう。通信Ｉ／Ｆ部１０８は、電源制御部１０６により電源の投入および切断が行なわれる。

このような携帯型端末２１１が初期状態から通信を開始して終了するまでの各構成要素の動作について、以下、説明する。

初期状態では、携帯型端末２１１の通信Ｉ／Ｆ部１０８の電源は切断されており、通信アプリケーション部１０１は、通信アプリケーションプログラムを実行していない。

通信アプリケーション部１０１は、通信アプリケーションプログラムを起動すると、アプリ要求取得部１０２に対して起動通知を発行する。この起動通知の発行によって、通信アプリケーション部１０１は、通信アプリケーションプログラムの複数の性能パラメータをアプリ要求取得部１０２に引き渡す。アプリ要求取得部１０２は、それらの複数の性能パラメータを受け取ると、それらを性能パラメータ管理テーブルに纏めて保存する。

図６Ａ、図６Ｂおよび図６Ｃは、アプリ要求取得部１０２が管理する性能パラメータ管理テーブルを示す図である。

例えば、アプリ要求取得部１０２は、図６Ａ、図６Ｂおよび図６Ｃに示す３つの性能パラメータ管理テーブル１０２ａ，１０２ｂ，１０２ｃのうち何れか１つを管理する。

性能パラメータ管理テーブル１０２ａ，１０２ｂ，１０２ｃはそれぞれ、起動済みの通信アプリケーションプログラムに対する複数の性能パラメータを有する。その複数の性能パラメータとしては、ストリームタイプ、帯域、および遅延時間のパラメータがある。ここで、ストリームタイプには、帯域重視型、遅延時間重視型、およびベストエフォート型の３つのタイプがある。

大容量のファイルを長時間に一定レートでダウンロードしようとする通信アプリケーションプログラムを実行する通信アプリケーション部１０１は、ストリームタイプ「帯域重視型」を含む複数の性能パラメータをアプリ要求取得部１０２に引き渡す。その結果、アプリ要求取得部１０２は、図６Ａに示すストリームタイプ「帯域重視型」の性能パラメータ管理テーブル１０２ａを保持して管理する。

例えば、この性能パラメータ管理テーブル１０２ａは、図６Ａに示すように、ストリームタイプ「帯域重視型」と、帯域「ＢＷ＝ＢＷｓ［Byte/sec］」とを含む。

また、ＶｏＩＰなどデータの遅延時間の要求の厳しい通信アプリケーションプログラムを実行する通信アプリケーション部１０１は、ストリームタイプ「遅延時間重視型」を含む複数の性能パラメータをアプリ要求取得部１０２に引き渡す。その結果、アプリ要求取得部１０２は、図６Ｂに示すストリームタイプ「遅延時間重視型」の性能パラメータ管理テーブル１０２ｂを保持して管理する。

例えば、この性能パラメータ管理テーブル１０２ｂは、図６Ｂに示すように、ストリームタイプ「遅延時間重視型」と、帯域「ＢＷ＝ＢＷｂ［Byte/sec］」と、遅延時間「ＤＴ＝ＤＴｂ［sec］」とを含む。

また、遅延時間や帯域に対する明確な要求をせずに大容量のファイルをできるだけ早くダウンロードしようとする通信アプリケーションプログラムを実行する通信アプリケーション部１０１は、ストリームタイプ「ベストエフォート型」を示す性能パラメータをアプリ要求取得部１０２に引き渡す。その結果、アプリ要求取得部１０２は、図６Ｃに示すストリームタイプ「ベストエフォート型」の性能パラメータ管理テーブル１０２ｃを保持して管理する。

例えば、この性能パラメータ管理テーブル１０２ｃは、図６Ｃに示すように、ストリームタイプ「ベストエフォート型」のみを性能パラメータとして含む。

アプリ要求取得部１０２は、通信アプリケーション部１０１から起動通知を受けたときには、その起動通知に含まれる性能パラメータの情報をもとに、性能パラメータ管理テーブル１０２ａ，１０２ｂ，１０２ｃの何れか１つを作成する。さらに、アプリ要求取得部１０２は、パラメータ決定部１０３に対して、その性能パラメータ管理テーブルを含む性能パラメータ登録通知を発行する。なお、アプリ要求取得部１０２は、通信アプリケーション部１０１から終了通知を受けたときには、作成された性能パラメータ管理テーブルを削除する。

パラメータ決定部１０３は、性能パラメータ登録通知を受けると、性能パラメータ管理テーブルの内容を読み出し、その内容を元に、間欠受信パラメータを決定する。

パラメータ決定部１０３は、間欠受信パラメータであるサイクル間隔ＴｃとサイクルデータサイズＤｃとを、基本的に、Ｄｃ／Ｔｃ＝ＢＷ（性能パラメータの帯域）を満たすような条件で決定する。なお、サイクルデータサイズＤｃの適切なサイズは、携帯型端末２１１のＴＣＰの条件（ＴＣＰ受信バッファサイズやＭＳＳ（Maximum Segment Size））や通信アプリケーションプログラムの条件（データ送信の単位）などによって変わる。したがって、パラメータ決定部１０３は、これらの条件も加味して間欠受信パラメータを決定する。なお、本実施の形態では、説明を簡単にするため、これらの条件が常に変化しない環境を想定し、パラメータ決定部１０３はこれらの条件に影響されることなく間欠受信パラメータを決定する。

具体的に、パラメータ決定部１０３は、間欠パラメータを決定するためのルールを予め記憶している。

図７は、間欠受信パラメータの決定ルールを示す図である。

パラメータ決定部１０３は、ストリームタイプ「帯域重視型」の性能パラメータ管理テーブルを読み出すと、その性能パラメータ管理テーブルに示される性能パラメータである帯域「ＢＷ＝ＢＷｓ［Byte/sec］」を、間欠受信パラメータを決定するための条件として用いる。つまり、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクルデータサイズＤｃ＝Ｃ１（Ｃ１は定数）に従い、サイクルデータサイズＤｃとしてＣ１［Byte/sec］を決定する。そして、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクル間隔Ｔｃ＝Ｄｃ／ＢＷに従い、サイクル間隔ＴｃとしてＣ１／ＢＷｓ［sec］を決定する。そして、パラメータ決定部１０３は、その決定されたサイクル間隔ＴｃおよびサイクルデータサイズＤｃを示す間欠受信パラメータ管理テーブルを生成する。

つまり、パラメータ決定部１０３は、ストリームタイプ「帯域重視型」の性能パラメータ管理テーブルを読み出すと、最初にサイクルデータサイズＤｃを決定した後、それに合わせてサイクル間隔Ｔｃを決定する。

一方、パラメータ決定部１０３は、ストリームタイプ「遅延時間重視型」の性能パラメータ管理テーブルを読み出すと、その性能パラメータ管理テーブルに示される性能パラメータである帯域「ＢＷ＝ＢＷｂ［Byte/sec］」と遅延時間「ＤＴ＝ＤＴｂ［sec］」とを、間欠受信パラメータを決定するための条件として用いる。つまり、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクル間隔Ｔｃ＝ＤＴ／Ｃ２（Ｃ２は１より大きい定数）に従い、サイクル間隔ＴｃとしてＤＴｂ／Ｃ２［sec］を決定する。なお、Ｃ２が小さいほど、サイクル間隔Ｔｃが長くなり、省電力効果が高まる。そして、パラメータ決定部１０３は、間欠受信パラメータの決定ルール、即ち、サイクルデータサイズＤｃ＝ＢＷ×Ｔｃに従い、サイクルデータサイズＤｃとしてＢＷｂ×ＤＴｂ／Ｃ２［Byte］を決定する。そして、パラメータ決定部１０３は、その決定されたサイクル間隔ＴｃおよびサイクルデータサイズＤｃを示す間欠受信パラメータ管理テーブルを生成する。

つまり、パラメータ決定部１０３は、ストリームタイプ「遅延時間重視型」の性能パラメータ管理テーブルを読み出すと、ストリームタイプ「帯域重視型」の場合とは逆に、遅延時間の要件が厳しいので、サイクル間隔Ｔｃを先に決めて、サイクルデータサイズＤｃをそれに合わせて決める。このように、ＶｏＩＰなどの遅延時間重視型の通信アプリケーションプログラムに基づく性能パラメータ管理テーブルの場合には、パラメータ決定部１０３は、性能パラメータの遅延時間ＤＴを使って、「Ｔｃ＜ＤＴ」という条件、即ち、サイクル間隔Ｔｃ＝ＤＴ／Ｃ２を、サイクル間隔Ｔｃの決定ルールとして追加している。

また、パラメータ決定部１０３は、ストリームタイプ「ベストエフォート型」の性能パラメータ管理テーブルを読み出すと、間欠受信パラメータの決定ルールに従い、サイクル間隔ＴｃおよびサイクルデータサイズＤｃを決定しない。つまり、ベストエフォート型については、帯域重視型や遅延時間重視型のような明確な性能要件がないため、パラメータ決定部１０３は、基本的には複雑な間欠受信制御を行わずに通信Ｉ／Ｆ部１０８の電源をＯＮにしたまま一気にデータ転送を完了させるような制御を行う。ただし、ベストエフォート型に対しても間欠受信を行うことは可能である。

図８は、パラメータ決定部１０３によって生成された間欠受信パラメータ管理テーブルの一例を示す図である。

パラメータ決定部１０３は、ストリームタイプ「帯域重視型」の性能パラメータ管理テーブルを読み出すと、例えば、間欠受信パラメータであるサイクル間隔ＴｃとしてＣ１／ＢＷｓ［sec］と、間欠受信パラメータであるサイクルデータサイズとしてＣ１［Byte］とを示す間欠受信パラメータ管理テーブルを生成する。

パラメータ決定部１０３は、性能パラメータ登録通知を受けるごとに、上記の手順で間欠受信パラメータ管理テーブルを生成する。そして、パラメータ決定部１０３は、生成後、抑制再開制御部１０４に対して間欠受信パラメータ登録通知を発行する。

抑制再開制御部１０４は、間欠受信パラメータ登録通知を受けると、間欠受信パラメータ管理テーブルの内容を読み出して、その内容に基づき、電源制御部１０６への投入要求の発行と、通信制御部１０７で送受信されるＴＣＰパケットのモニタリングの開始と、通信制御部１０７に対するＡＣＫ通常送信再開要求の発行とを行ない、間欠受信の準備状態に入る。この処理に連動して、電源制御部１０６は通信Ｉ／Ｆ部１０８に電源の投入を指示する。その結果、通信Ｉ／Ｆ部１０８の電源が投入される。

以下、本実施の形態における間欠受信の準備状態の処理について説明する。

通信アプリケーション部１０１は、通信アプリケーションプログラム起動時の処理を行なった後、送信側装置２０３との接続を確立し、送信側装置２０３からのデータ受信を開始する。

通信制御部１０７では、通信アプリケーション部１０１からの接続要求を受けて、無線基地局２０２との間のネゴシエーション処理、および、送信側装置２０３とのＴＣＰコネクションの確立などの処理を行なう。ＴＣＰコネクションの確立後、携帯型端末２１１と送信側装置２０３の間のデータは、無線基地局２０２および通信Ｉ／Ｆ部１０８を介して送受信され、ＴＣＰパケットの送受信処理は、通信制御部１０７で行なわれる。

抑制再開制御部１０４は、通信制御部１０７で受信されるＴＣＰパケットをモニタリングし、受信データの帯域（受信帯域）が、間欠受信パラメータ管理テーブルに設定されている帯域（設定帯域ＢＷ＝Ｄｃ／Ｔｃ）に到達するのを待つ。例えば、抑制再開制御部１０４は、サイクル間隔Ｔｃの経過ごとに、そのサイクル間隔Ｔｃの間に受信したＴＣＰパケットのデータサイズを合計することで、合計データサイズＴｌＤを算出する。そして、抑制再開制御部１０４は、「ＴｌＤ／Ｔｃ≧ＢＷ」の条件を満たす回数が所定回数以上だけ続いたときに、受信帯域が設定帯域ＢＷに到達したと見なす。

抑制再開制御部１０４は、受信帯域が設定帯域ＢＷに到達すると、送信側装置２０３からの送信を抑制するために、通信制御部１０７に対してＡＣＫ通常送信抑制要求を発行する。なお、この発行は、間欠受信の１回目の処理に相当する。このとき、抑制再開制御部１０４は、通信制御部１０７からそれまでに送信した最後のＡＣＫパケットの情報、すなわち、ＡＣＫ番号（ＬＡＳＴ＿ＡＣＫＮＯ）と受信ウィンドウ（ＬＡＳＴ＿ＲＷＩＮ）とを保持しておく。通信制御部１０７は、抑制再開制御部１０４からＡＣＫ通常送信抑制要求を受けると、以後、ＴＣＰのデータ受信は続けるものの、受信時にＡＣＫパケットを送信しないようにする。

一方、送信側装置２０３は、携帯型端末２１１からＡＣＫパケットが送られてこなくなっても、自身の管理する送信可能なデータサイズ（ｕｗｎｄ）が０になるまで、データ送信を続け、ｕｗｎｄが０になった時点で、データ送信を終了する。その結果、送信側装置２０３は送信抑制期間に入る。

抑制再開制御部１０４は、ＡＣＫ通常送信抑制要求の発行後もＴＣＰパケットをモニタリングし、送信側装置２０３での送信可能なデータサイズ（ｕｗｎｄ）が０になるのを待つ。具体的には、抑制再開制御部１０４は、受信したＴＣＰパケットのシーケンス番号とデータサイズを参照し、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）に達するのを待つ。

抑制再開制御部１０４は、ｕｗｎｄが０になったと判断したら、電源制御部１０６へ切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

抑制再開制御部１０４は、電源制御部１０６へ切断要求を発行した後、所定時間の満了を待つ。この所定時間は、サイクル間隔Ｔｃと一致していてもよいし、異なる時間であっても良い。送信側装置２０３は、既に送信抑制期間に入っているので、通信Ｉ／Ｆ部１０８の電源が切断されている間、データ送信を行なわない。

所定時間が満了したとき、抑制再開制御部１０４は、電源制御部１０６へ投入要求を発行する。さらに、抑制再開制御部１０４は、間欠受信の準備状態が満了したと見なし、定常状態に遷移する。電源制御部１０６は投入要求を受けると、通信Ｉ／Ｆ部１０８の電源を投入する。

以下、本実施の形態における定常状態の処理について説明する。

図９は、本実施の形態における携帯型端末２１１と送信側装置２０３の定常状態での動作を示すシーケンス図である。

定常状態での１サイクル分の動作は、送信再開処理と、送信抑制期間の開始処理と、送信抑制期間の終了処理との３つのステップに分けられる。

送信再開処理（ステップ１）では、抑制再開制御部１０４は、送信側装置２０３からのデータ送信を再開させるため、通信制御部１０７に対してＡＣＫ単発送信要求を発行する。このとき、抑制再開制御部１０４は、ＡＣＫパケットの受信ウィンドウ（ＲＷＩＮ）として、間欠受信パラメータ管理テーブルに格納されたサイクルデータサイズＤｃを指定する。通信制御部１０７は、時刻Ｔ１に、ＡＣＫ単発送信要求を受け取ると、ＲＷＩＮ＝ＤｃのＡＣＫパケットＰ１を通信Ｉ／Ｆ部１０８を介して送信する。また、抑制再開制御部１０４は、送信したＡＣＫパケットＰ１のＡＣＫ番号を保持しておく。

一方、送信側装置２０３は、携帯型端末２１１からのＡＣＫパケットＰ１（ＲＷＩＮ＝Ｄｃ）を受信すると、間欠受信の準備状態、または、送信抑制期間が終了し、データ送信が可能な状態になる。その結果、送信側装置２０３は、携帯型端末２１１あてのＴＣＰパケット（データＰ２）の送信を再開する。

携帯型端末２１１の抑制再開制御部１０４は、間欠受信の準備状態でＡＣＫ通常送信抑制要求を発行しているので、通常のＡＣＫパケットの送信、つまりデータ受信に連動したＡＣＫパケットの送信は既に抑制されている。すなわち、通信制御部１０７は、送信側装置２０３からのデータＰ２を受信して、そのデータを通信アプリケーション部１０１に引渡しても、送信側装置２０３に対してＡＣＫパケットを送信しない。そのため、間欠受信の１サイクル（サイクル間隔Ｔｃ）において、送信側装置２０３から受信されるデータＰ２のサイズは、サイクルデータサイズＤｃに制限される。

送信抑制期間の開始処理（ステップ２）では、抑制再開制御部１０４は、時刻Ｔ１以降、通信制御部１０７で受信されるＴＣＰパケットをモニタリングする。そして、抑制再開制御部１０４は、時刻Ｔ１以降で受信されたデータサイズがサイクルデータサイズＤｃに到達したかどうか、すなわち、送信側装置２０３の送信可能なデータサイズ（ｕｗｎｄ）が０になったかどうかを確認し続ける。このとき抑制再開制御部１０４は、間欠受信の準備状態での確認処理と同じく、最後に送信したＡＣＫパケットのＡＣＫ番号と受信ウィンドウ（ＲＷＩＮ＝Ｄｃ）を使って上述の確認を行う。時刻Ｔ１以降で受信したデータサイズがサイクルデータサイズＤｃに到達したとき、即ち時刻Ｔ２で、抑制再開制御部１０４は、送信抑制期間が開始したとみなし、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

送信抑制期間の終了処理（ステップ３）では、本発明の実施の形態における携帯型端末２１１は、時刻Ｔ１を起点として、サイクル間隔Ｔｃの時間経過後の時刻Ｔ３を、送信抑制期間の終了点と見なす。つまり、抑制再開制御部１０４は、タイマにより時刻Ｔ３を検出し、電源制御部１０６に投入要求を発行する。その投入要求により、電源制御部１０６は時刻Ｔ３に通信Ｉ／Ｆ部１０８の電源を投入する。

携帯型端末２１１は、定常状態では、上記３つのステップを１サイクルとして、繰り返し実行する。

通信アプリケーション部１０１は、通信アプリケーションプログラムを終了するときには、通信制御部１０７に対して送信側装置２０３とのコネクションの切断を要求し、アプリ要求取得部１０２に対して終了通知を発行する。

通信制御部１０７は、通信アプリケーション部１０１によるコネクション切断の要求により、ＴＣＰのコネクションを切断する。

アプリ要求取得部１０２は、終了通知を受け付けると、性能パラメータ管理テーブルの内容をクリアし、パラメータ決定部１０３に対して性能パラメータ削除通知を発行する。

パラメータ決定部１０３では、性能パラメータ削除通知を受けると、間欠パラメータ管理テーブルの内容をクリアし、抑制再開制御部１０４に対して間欠受信パラメータ削除通知を発行する。

抑制再開制御部１０４は、間欠受信パラメータ削除通知を受けると、通信制御部１０７で送受信されるＴＣＰパケットのモニタリングを停止し、さらに、電源制御部１０６への切断要求の発行を行なう。

電源制御部１０６は、抑制再開制御部１０４の処理（切断要求の発行）に連動して、通信Ｉ／Ｆ部１０８の電源を切断する。

以上の処理により、携帯型端末２１１の状態は初期状態に戻る。

図１０は、本実施の形態おける携帯型端末２１１の動作を示すフローチャートである。

まず、本実施の形態の携帯型端末２１１は、送信側装置２０３に対してＲＷＩＮ＝ＤｃのＡＣＫパケットを送信する（ステップＳ１０）。このとき、携帯型端末２１１の抑制再開制御部１０４は、通信Ｉ／Ｆ部１０８への電源投入のタイミングを特定するために、タイマによる計時を開始する。

そして、携帯型端末２１１は、そのＡＣＫパケットに対して送信側装置２０３から送信されたサイクルデータサイズＤｃ分のデータ（ＴＣＰパケット）を受信する（ステップＳ１２）。このとき、本実施の形態の携帯型端末２１１は、受信したデータに対して通常行われるＡＣＫパケットの送信を停止することで、送信側装置２０３からのデータの送信を抑制している。

そして、携帯型端末２１１は、ステップＳ１２でサイクルデータサイズＤｃ分の全てのデータを受信すると、通信Ｉ／Ｆ部１０８の電源を切断する（ステップＳ１４）。

携帯型端末２１１は、通信Ｉ／Ｆ部１０８の電源を切断すると、上述のタイマに基づいて、ステップＳ１０でのＡＣＫパケットの送信時からサイクル間隔Ｔｃが経過したか否かを判別する（ステップＳ１６）。

ここで、携帯型端末２１１は、サイクル間隔Ｔｃが経過していないと判別したときには（ステップＳ１６のＮｏ）、ステップＳ１４からの処理を繰り返し、サイクル間隔Ｔｃが経過したと判別したときには（ステップＳ１６のＹｅｓ）、通信Ｉ／Ｆ部１０８の電源を投入する（ステップＳ１８）。

そして、携帯型端末２１１は、送信側装置２０３との通信を終了すべきか否かを判別し（ステップＳ２０）、終了すべきと判別したときには（ステップＳ２０のＹｅｓ）、全ての処理を終了する。また、携帯型端末２１１は、終了すべきでないと判別したときには（ステップＳ２０のＮｏ）、ステップＳ１０からの処理を繰り返し実行する。このようなステップＳ１０〜Ｓ２０の処理によって、間欠受信の１サイクルが実行さる。

以上のように、本実施の形態に係る携帯型端末２１１は、無線ＬＡＮの省電力方法に依存せず、例えばＴＣＰなどのフロー制御機構を持つプロトコルを使って、送信側装置２０３との間で通信を行いながら省電力化を行なう。そのため、本実施の形態では、アクセスポイントでの省電力機能のサポート状況やネットワークデバイスの種類にも関係なく、携帯型端末２１１の省電力化を図ることができる。

また、本実施の形態では、無線ＬＡＮの省電力方法に依存しないので、携帯型端末２１１のデータの受信タイミングをビーコン送信タイミングに連動させる必要がない。そのため、遅延時間と帯域を確保した通信を続けながら、同時に省電力能力を向上することができる。

さらに、本実施の形態では、送信側装置２０３からのデータ到着が無い期間を積極的に作ったうえで、携帯型端末２１１の電源を切断するので、ジッタが発生しても送信側装置２０３と携帯型端末２１１との間のデータ溢れの発生を防ぐことができる。

なお、本実施の形態では、携帯型端末２１１はＴＣＰのプロトコルに従って動作したが、そのプロトコルはＴＣＰ以外のプロトコルであっても、フロー制御機構を持つプロトコルであればよく、既存のフロー制御付きプロトコルであってもよい。すなわち、本実施の形態を実現するために、送信側装置と携帯型端末の両方で新たなプロトコルを追加する必要はなく、携帯型端末に本発明の省電力方法に対応する処理部を追加するだけで実現できる。

ここで、本発明について実施の形態１を用いて説明したが、実施の形態１を変形しても本発明を実施することができる。

例えば、実施の形態１では、送信側装置２０３からのデータ送信の抑制方法として、「携帯型端末２１１からＡＣＫパケットを送信しない」という方法を説明したが、データ送信の抑制方法はこれに限定されるものではない。例えば、携帯型端末２１１は、受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットを送信側装置２０３に送ることで、明示的に送信側装置２０３からのデータ送信を抑制してもよい。

図１１は、受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットが送信される動作を示すシーケンス図である。

例えば、携帯型端末２１１の通信制御部１０７は、図１１に示すように、送信側装置２０３からのデータＰ２を受信して、そのデータを通信アプリケーション部１０１に引渡すと、時刻Ｔ２に、送信側装置２０３に対して受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットＰ３を送信する。このようなＡＣＫパケットＰ３を送信した場合にも、送信側装置２０３から受信するデータＰ２のサイズをサイクルデータサイズＤｃに制限して、送信側装置２０３からのデータ送信を抑制することができる。

このように受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットを送信するような抑制方法の場合には、ＴＣＰの制御方法に従って動作する送信側装置２０３での再送処理を予防することができる。つまり、図９に示す、ＡＣＫパケットを送信しないような抑制方法の場合には、送信側装置２０３にはＡＣＫパケットが全く届かないので、送信側装置２０３は、ＴＣＰの制御方法に従って、タイムアウトによりパケットロスが発生したと判断してデータを再送してしまうケースがある。このとき、送信側装置２０３の送信可能データ（輻輳ウィンドウと呼ばれる）が１パケット分（上述のＭＳＳ）低下するという弊害もある。ところが、図１１に示すように、ＲＷＩＮ＝０のＡＣＫパケットを送信するような抑制方法では、送信側装置２０３は、ＡＣＫパケットを受け取るため、タイムアウトを止めることができる。なお、携帯型端末２１１は、ＲＷＩＮ＝０のＡＣＫパケットを、ｕｗｎｄ＝０となる時刻Ｔ２に送っても良いし、時刻Ｔ２以降で且つ送信側装置２０３でタイムアウトが発生する前であれば任意のタイミングで送っても良い。また、携帯型端末２１１は、ＲＷＩＮ＝０のＡＣＫパケットを、定常状態だけでなく、間欠受信の準備状態に送っても良い。

また、携帯型端末２１１は、送信側装置２０３からのデータ送信を抑制するため、ＲＷＩＮ＝０以外のＡＣＫパケットを送ってもよい。つまり、送信側装置２０３から送信されるデータのサイズがサイクルデータサイズＤｃ（送信再開を指示するＡＣＫパケットのＲＷＩＮで指定されたサイズ）以下になるのであれば、携帯型端末２１１はどのようなＡＣＫパケットを送信してもよい。したがって、携帯型端末２１１は、「Ｄｃ−（時刻Ｔ１以降で受信したデータのサイズ）」を越えない値をＲＷＩＮに設定して、ＡＣＫパケットを送信してもよい。

また、本発明における携帯型端末２１１が搭載する無線通信デバイスは、無線ＬＡＮ（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ）のデバイスの他、任意の無線通信デバイスであってもよい。

さらに、実施の形態１では、携帯型端末２１１が通信Ｉ／Ｆ部１０８として無線通信デバイスを搭載したネットワーク構成を想定していたが、本発明の携帯型端末は通信Ｉ／Ｆの種類に限定されるものではない。例えば、無線ＬＡＮ以外の無線Ｉ／Ｆや有線の通信Ｉ／Ｆを使ってもよい。なお、有線の通信Ｉ／Ｆを使う場合は、ネットワーク構成として無線基地局２０２が不要になり、代わりに有線のルータなどの装置が必要となる。また、実施の形態１では、アクセスポイント（無線基地局２０２）の存在する無線ＬＡＮのネットワーク構成を想定していたが、アクセスポイントの無いアドホックモードでの環境を想定してもよい。その場合、送信側装置２０３と携帯型端末２１１はインターネット２０４を経由せず、無線ＬＡＮで直接接続される。

また、フロー制御付きのプロトコルとしてＴＣＰを中心に説明したが、本発明に使用されるプロトコルはＴＣＰに限定されるわけではない。本発明に使用されるプロトコルは、フロー制御の機能を持っていれば他のプロトコルでもよく、例えば、アプリケーション層でフロー制御を実現して、そのフロー制御でＴＣＰと同様の送信抑制および送信再開の制御を行なうことで省電力制御を行なってもよい。また、携帯型端末が送信側装置と直接接続される場合は、送信側装置と携帯型端末との間のデータリンク層でのフロー制御を使って省電力制御を行なってもよい。また、フロー制御は、携帯型端末２１１と送信側装置２０３の間に限定されるわけではない。例えば、中継装置と携帯型端末の間でフロー制御を行なうプロトコルがあれば、そのフロー制御を同様に利用して省電力制御を行なってもよい。

また、本発明では、送信抑制期間に通信Ｉ／Ｆ部１０８の電源を切断または投入する方法は、どのような方法であってもよい。例えば、本発明を無線ＬＡＮのパワーセーブモードの処理と連動させて、本発明での電源切断のタイミングでパワーセーブモードたるドーズモードへの移行を行なっても良い。また、電源切断のタイミングは、送信抑制期間の間であれば任意のタイミングでよい。

また、実施の形態１では、単純化のため、通信アプリケーション部１０１で同時動作する通信アプリケーションプログラムを１つに限定したが、本発明の省電力方法は通信アプリケーションプログラムの数に依存しない。複数の通信アプリケーションプログラムが同時に動作する環境でも、例えば、複数の通信アプリケーションプログラムの間欠受信のタイミングを統合して、同様のフロー制御に基づく電力制御を行なっても良い。

また、アプリ要求取得部１０２における性能パラメータの取得方法は、本発明の本質ではない。したがって、アプリ要求取得部１０２は、なんらかの方法で性能パラメータを取得できればよく、その取得方法は実施の形態１の手順に限定されるものではない。例えば、実施の形態１では、アプリ要求取得部１０２は、通信アプリケーション部１０１から性能パラメータを直接取得したが、自立的に性能パラメータを取得してもよい。つまり、アプリ要求取得部１０２は、データ送受信のパケットを解析したり、ＯＳ（Operating System）上で通信アプリケーションプログラムの起動および終了のタイミングを監視したりすることで、性能パラメータを取得する。

例えば、省電力の制御を行なっていないとき、つまり通信Ｉ／Ｆ部１０８の電源が常に投入されているときにおける、携帯型端末２１１と送信側装置２０３とのデータ送受信の帯域および遅延時間の少なくとも一方が、通信アプリケーションプログラムとしての性能要件に一致している。このような場合には、アプリ要求取得部１０２は、省電力制御が行われていない状態で、通信制御部１０７のデータ送受信のパケットをモニタリングして帯域および遅延時間の少なくとも一方を推定し、その推定値を性能パラメータとして使う。これにより、アプリ要求取得部１０２はパケット解析により自立的に性能パラメータを取得する。

また、実施の形態１では、通信アプリケーションプログラムの起動および終了のタイミングを取得して、通信アプリケーションの起動中は性能パラメータを常に固定値として扱ったが、性能パラメータを動的に変化させてもよい。

また、実施の形態１では、図７に示す決定ルールに基づいて間欠受信パラメータを決定したが、他のルールに基づいて間欠受信パラメータ（サイクル間隔およびサイクルデータサイズ）を決めてもよい。また、間欠受信パラメータを固定させておく必要はなく、動的に変化させてもよい。即ち、サイクル間隔ＴｃやサイクルデータサイズＤｃの値を一定期間ごとに変化させてもよいし、毎回異なる値に変化させてもよい。また、性能パラメータに関しても同様であって、実施の形態１では、図６Ａ、図６Ｂおよび図６Ｃに示す性能パラメータを用いたが、これらの性能パラメータ以外のパラメータを用いてもよい。例えば、実施の形態１では、ストリームタイプを３種類に分類しているが、２種類や４種類以上に分類してもよく、他の種別のストリームタイプに分類してもよい。さらに、実施の形態１では、これらのストリームタイプに応じて、間欠受信パラメータの決定ルールを異ならせたが、これらのストリームタイプに関わらず、常に一定のルールに基づいて間欠受信パラメータを決定してもよい。

また、実施の形態１では、通信開始から測定した帯域が設定帯域ＢＷに到達するまでの間は「間欠受信の準備状態」として電源を常にＯＮにしていたが、この期間においても間欠受信による省電力制御を行ってもよい。ただし、この期間では送信側装置２０３においてはＴＣＰのスロースタート制御が行われるため、ウィンドウサイズがＲＴＴ（Round Trip Time）の経過毎に１ＭＳＳ，２ＭＳＳ，４ＭＳＳというように増加していく。なお、ＲＴＴは、ＡＣＫパケットが送信されてからそれに対応するデータが受信されるまでの時間であり、ＭＳＳは、１パケットに含まれるＴＣＰデータの最大サイズである。このため、抑制再開制御部１０４は、これに合わせて制御を行う必要がある。具体的には、抑制再開制御部１０４は、最初のデータパケットが受信されると、通信Ｉ／Ｆ部１０８の電源を切断させる。一定期間後、抑制再開制御部１０４は、通信Ｉ／Ｆ部１０８の電源を再投入させ、ＡＣＫパケット（ＲＷＩＮ＝２×ＭＳＳ）を送信させ、２つのデータパケットが受信された時点で通信Ｉ／Ｆ部１０８の電源を切断させる。さらに、抑制再開制御部１０４は、一定期間後、通信Ｉ／Ｆ部１０８の電源を再投入させ、ＡＣＫパケット（ＲＷＩＮ＝４×ＭＳＳ）を送信させ、４つのデータパケットが受信された時点で通信Ｉ／Ｆ部１０８の電源を切断させる。なお、上述のデータパケットは、送信側装置から受信側装置にＴＣＰにより送信されるパケットであって、このデータパケットとＡＣＫパケットとを総称してＴＣＰパケットという。

このように、抑制再開制御部１０４は、間欠受信サイクルごとに、通知する受信ウィンドウ（ＲＷＩＮ）のサイズを倍々にしていく。ただし、送信側装置２０３ではあるタイミングでスロースタート制御が終了し、それ以降はＡＣＫパケット受信によるウィンドウサイズの上昇が小さくなる。抑制再開制御部１０４はこれをタイムアウトなどにより検知し、それ以降はＡＣＫパケットにより通知する受信ウィンドウを少しずつ上昇させる制御に移行する。このような制御により、通知する受信ウィンドウがサイクルデータサイズＤｃに達した時点で、抑制再開制御部１０４は前述の定常状態の処理を開始する。

（実施の形態２）
本発明の実施の形態２に係る通信装置について説明する。実施の形態１では、送信側装置２０３からのデータ送信が無い送信抑制期間にのみ、通信Ｉ／Ｆ部１０８の電源を切断したが、本実施の形態では、別の期間にも通信Ｉ／Ｆ部１０８の電源を切断して、省電力効果をさらに向上する。具体的には、携帯型端末が送信再開の指示を出してから、実際に送信側装置２０３からのデータが到着するまでの期間も、通信Ｉ／Ｆ部１０８の電源が切断される。

なお、本実施の形態において、実施の形態１と同様の機器および構成については、同一の参照符号を付して説明を省略する。本実施の形態に係る通信システムのネットワーク構成は、実施の形態１の図３に示す通信システムのネットワーク構成と同じであるため、説明を省略する。

図１２は、本実施の形態における携帯型端末の具体的な構成を示す構成図である。

本実施の形態における携帯型端末２１１ａは、通信アプリケーション部１０１と、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部８０４と、電源制御部１０６と、通信制御部１０７と、通信Ｉ／Ｆ部１０８と、ＲＴＴ推定部８０９とを備える。つまり、本実施の形態における携帯型端末２１１ａは、実施の形態１の携帯型端末２１１の抑制再開制御部１０４の代わりに、抑制再開制御部８０４を備えるとともに、実施の形態１の携帯型端末２１１にはないＲＴＴ推定部８０９を備えている。

ＲＴＴ推定部８０９は、フロー制御付きプロトコル上でのＲＴＴを推定する。なお、ＲＴＴは、携帯型端末２１１ａと送信側装置２０３の間のパケットの往復時間に相当する。ＲＴＴ推定部８０９は、通信制御部１０７における送受信パケットをモニタリングして、ＲＴＴの最短値を推定し、その結果を抑制再開制御部８０４に送る。例えば、ＲＴＴ推定部８０９は、通信制御部１０７のモニタリングにより、携帯型端末２１１ａと送信側装置２０３との間で往復するパケットの組の往復時間を、その組ごとに所定回数だけ測定し、その中で最短の往復時間をＲＴＴの最短値とする。

ここで、携帯型端末２１１ａと送信側装置２０３との間で往復するパケットの組とは、携帯型端末２１１ａから送信されるパケットと、その送信に対して送信側装置２０３が応答して送信するパケットとの組であれば、どのようなパケットの組でも良い。例えば、図９に示すように、時刻Ｔ１で携帯型端末２１１ａが送信するＡＣＫパケットＰ１（受信ウィンドウ＞０）と、それに対して送信側装置２０３から送信される最初のデータパケットＰ２との組であってもよい。なお、ＲＴＴの最短値の推定方法は、本発明の省電力方法の本質に関わるものではないので、上述の方法に限定されるものではなく、他の方法であってもよい。

抑制再開制御部８０４は、実施の形態１の抑制再開制御部１０４の機能を有するとともに、ＲＷＩＮ＞０のＡＣＫパケットが送信されてから、ＲＴＴ推定部８０９で推定されたＲＴＴ（以下、ＲＴＴ推定値という）が経過するまでの期間にも、通信Ｉ／Ｆ部１０８の電源を切断するように指示する。具体的には、抑制再開制御部８０４は、ＲＴＴ推定部８０９からＲＴＴ推定値を取得する。さらに、抑制再開制御部８０４は、ＡＣＫパケット（ＲＷＩＮ＞０）の送信後のタイミングに、電源制御部１０６に対して切断要求を発行し、ＡＣＫパケット（ＲＷＩＮ＞０）の送信直後からＲＴＴ推定値が経過するタイミングに、電源制御部１０６に対して投入要求を発行する。

また、抑制再開制御部８０４は、抑制再開制御部１０４と同様の処理を行なうことで、送信抑制期間にも、通信Ｉ／Ｆ部１０８の電源のＯＮ／ＯＦＦを行なう。

図１３は、本実施の形態に係る携帯型端末２１１ａと送信側装置２０３の省電力方法を示すシーケンス図である。

図１３において、携帯型端末２１１ａが送信再開の指示を出してから、実際に送信側装置２０３からのデータが到着するまでの期間は、時刻Ｔ１１から時刻Ｔ１２の期間に対応する。この期間では、実施の形態１で説明した送信抑制期間と同様、送信側装置２０３からのデータ送信が無い期間なので、通信Ｉ／Ｆ部１０８の電源を切断しても問題ないはずである。

そこで、本実施の形態に係る省電力方法を適用する携帯型端末２１１ａは、ＡＣＫパケットＰ１（ＲＷＩＮ＝Ｄｃ）を送信する間、つまり時刻Ｔ１０〜時刻Ｔ１１の期間だけ通信Ｉ／Ｆ部１０８の電源を投入し、その後、時刻Ｔ１２まで通信Ｉ／Ｆ部１０８の電源を切断する。時刻Ｔ１１〜時刻Ｔ１２の時間は、上述のようにＲＴＴ推定部８０９によって推定されたＲＴＴ推定値に相当する。携帯型端末２１１ａは、送信側装置２０３からのデータを受信している期間、つまり時刻Ｔ１２〜時刻Ｔ１３の期間には、電源を再投入し、その後の時刻Ｔ１３〜時刻Ｔ２０の送信抑制期間には、実施の形態１と同様、電源を切断する。

なお、抑制再開制御部８０４は、ＡＣＫパケット（ＲＷＩＮ＞０）の送信後に、電源制御部１０６に対して切断要求を発行するが、その送信の時刻Ｔ１１以降のタイミングであれば任意のタイミングで発行してもよい。また、抑制再開制御部８０４は、ＡＣＫパケット（ＲＷＩＮ＞０）の送信直後からＲＴＴ推定値が経過するタイミングに、電源制御部１０６に対して投入要求を発行するが、時刻Ｔ１２以前であれば任意のタイミングで発行してもよい。特に、投入要求のタイミングに関してはＲＴＴ推定値が実際の最小ＲＴＴ値より短い場合も考慮し、一定時間だけ早めに投入要求を発行すること、もしくは、測定したＲＴＴ値の平均や、分散、サンプル数などの統計値に基づいて計算された値分だけ早めに投入要求を発行することも有効である。

また、本実施の形態では、ベストエフォート型であっても、ＡＣＫパケット（ＲＷＩＮ＞０）が送信されてからＲＴＴが経過するまでの間に電源をＯＦＦすることで省電力化を図ることができる。

ここで、ベストエフォート型の通信では間欠受信は行われない。これは、ベストエフォート型の通信アプリケーションプログラムでは、途切れなくデータ転送を行うことを前提としているからである。即ち、送信側装置２０３は、リアルタイムに送信データを生成しないため保持しているデータを連続的に送信でき、受信側装置は全てのデータを保存するメモリを保持するためデータを連続的に受信できる。したがって、ベストエフォート型の通信では、送信抑制期間がないため、途切れなくデータ転送が行われ、その分データ全体の受信完了までの期間が短くなる。ところが、実施の形態１では、送信抑制期間をなくすと、電源をＯＦＦにすることができないため、消費電力を削減することができない。また、この場合、一定のサイズのデータを転送するのに必要な消費電力は総転送データ量で決まってしまう。

しかし、本実施の形態では、携帯型端末２１１ａが送信再開の指示を出してから、実際に送信側装置２０３からのデータが到着するまでの期間に、携帯型端末２１１ａは通信Ｉ／Ｆ部１０８の電源を切断するため、ベストエフォート型の通信においても、データ転送レートを落とさずに省電力化を図ることができる。なお、この場合、間欠受信パラメータであるサイクルデータサイズＤｃを、パケットロスの発生しないできるだけ大きな値とすることが望ましい。また、携帯型端末２１１ａは、間欠受信パラメータであるサイクル間隔Ｔｃを規定せずに、送信側装置２０３からサイクルデータサイズＤｃ分のパケットを受け取ると、即座に次のサイクルでのＡＣＫパケット（ＲＷＩＮ＝Ｄｃ）を送信すればよい。

このように、本実施の形態では、実施の形態１での省電力方法に対して、通信Ｉ／Ｆ部１０８の電源を切断する期間を追加することで、さらに省電力効果を向上させることができる。

（実施の形態３）
次に、本発明の実施の形態３に係る通信装置について説明する。本実施の形態に係る通信装置は、パケットロスが発生したときにも、通信品質と省電力効果の向上を両立して行うことができる。

実施の形態１では、抑制再開制御部１０４は、受信したＴＣＰパケットのシーケンス番号とデータサイズを参照し、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）に到達したことによって、送信側装置２０３が送信抑制期間に入ったことを検知し、通信Ｉ／Ｆ部１０８の電源を切断させていた。

しかし、このような制御は、以下の２つの条件が成り立っている状況においてのみ正しく行われる。

第１の条件は、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）となるまでパケットを受信側装置が受信できることである。

第２の条件は、受信側装置が通知した受信ウィンドウ（ＲＷＩＮ）分だけ送信側装置２０３が送信可能であることである。

実際、第１の条件は、パケットロスが発生した場合には保証されない。パケットロスは様々な原因により発生する。例えば、電波状況が悪い無線区間にパケットロスが発生する。または、中継ルータや無線アクセスポイントなどの中継装置において他のフローと競合することによる中継装置内のバッファ溢れによってパケットロスが発生する。または、受信側装置で処理可能レートを越えるトラフィックを受信した場合の受信装置内のバッファ溢れによってパケットロスが発生する。

また、第２の条件も、パケットロスが発生した場合には保証されないことがある。パケットロスが発生すると、ＴＣＰに従って処理を行なう送信側装置２０３はパケットロスをネットワークの輻輳を示す情報と解釈し、輻輳制御を目的として管理している輻輳ウィンドウ（以下、ＣＷＩＮと呼ぶ）を小さくする。実際の送信側装置２０３からのデータの送信量は、通知されたＲＷＩＮとＣＷＩＮの小さい方を上限として制限される。したがって、受信側装置から通知されたＲＷＩＮよりもＣＷＩＮが小さくなる状況がパケットロスにより引き起こされると、送信側装置２０３はＲＷＩＮ分のパケットを送信できなくなる。

なお、ＴＣＰに従って処理を行なう送信側装置２０３は、通常、以下の２つの方法によってパケットロスを検知する。

第１のロス検知方法では、送信側装置２０３は、送信したパケットに対するＡＣＫパケットが一定時間（再送タイムアウト時間と呼ばれる）経過後も受信されなかった場合に、パケットロスを検知する。この場合、送信側装置２０３は、ＣＷＩＮを１まで減少させ、その後、ロスされたパケットを再送パケットとして送信する。

第２のロス検知方法では、送信側装置２０３は、同一のＡＣＫ番号を持つ複数（通常４つ）のＡＣＫパケットを受信した場合に、パケットロスを検知する。この場合、送信側装置２０３は、即座に再送パケットを送信し、再送パケットに対するＡＣＫパケットを受信した後は、ＣＷＩＮをパケットロス検知前のＣＷＩＮの半分にする。

図１４は、本実施の形態における携帯型端末の具体的な構成を示す構成図である。

本実施の形態の携帯型端末２１１ｂは、通信アプリケーション部１０１と、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部９０４と、電源制御部１０６と、通信制御部１０７と、通信Ｉ／Ｆ部１０８とを備える。つまり、本実施の形態における携帯型端末２１１ｂは、実施の形態１の携帯型端末２１１の抑制再開制御部１０４の代わりに、抑制再開制御部９０４を備える。なお、本実施の形態において実施の形態１と同様の機器および構成については、同一の参照符号を付して説明を省略する。

抑制再開制御部９０４は、実施の形態１の抑制再開制御部１０４と同様の機能を有するとともに、パケットロスを検知して、そのロスしたパケットが再送パケットとして再送されるように通信制御部１０７を制御する。さらに、抑制再開制御部９０４は、パケットロスが発生した後の送信側装置２０３のＣＷＩＮを推定して、その推定されたＣＷＩＮにおいても実施の形態１と同様の間欠受信と省電力制御とを行なえるように通信制御部１０７を制御する。

以下、パケットロスが発生した時の本実施の形態の動作について詳細に説明する。なお、パケットロスが発生していない状況での動作については実施の形態１と同様となるため、ここでは説明を省略する。

図１５は、本実施の形態における携帯型端末２１１ｂの動作を示すフローチャートである。

まず、携帯型端末２１１ｂは、実施の形態１の図９に示す処理動作と同様の定常状態の処理、即ち１サイクルごとにサイクルデータサイズＤｃのデータを転送しつつ電源のＯＮ／ＯＦＦ制御（省電力制御）を行う（ステップＳ３０１）。さらに、携帯型端末２１１ｂは、パケットロスの検知処理を行う（ステップＳ３０２）。ここで、携帯型端末２１１ｂは、その検知処理の結果に基づいてパケットロスがあったか否かを判別する（ステップＳ３０３）。

携帯型端末２１１ｂは、パケットロスがなかったと判別したときには（ステップＳ３０３のＮｏ）、例えば、定常状態処理を終了すべきか否かをさらに判別する（ステップＳ３０８）。そして、携帯型端末２１１ｂは、終了すべきと判別したときには（ステップＳ３０８のＹｅｓ）、定常状態処理を終了し、終了すべきでないと判別したときには（ステップＳ３０８のＮｏ）、ステップＳ３０１からの処理を繰り返す。

一方、携帯型端末２１１ｂは、パケットロスがあったと判別したときには（ステップＳ３０３のＹｅｓ）、まず、送信側装置２０３にロスしたパケットを再送させるための再送誘発処理を実施する（ステップＳ３０４）。

このとき、携帯型端末２１１ｂは、この再送誘発処理によって再送されたパケットを受信し、そのパケットを受信したことをＡＣＫパケットにより送信側装置２０３に通知する。送信側装置２０３は、そのＡＣＫパケットによる通知を受けると、ＴＣＰにおける輻輳制御によりＣＷＩＮを低下させる。その結果、上述の第２の条件であるＣＷＩＮ≧ＲＷＩＮを前提とする、ステップＳ３０１の定常状態処理における間欠受信のサイクルを実行できなくなる可能性がある。

このため、携帯型端末２１１ｂは、まず送信側装置２０３のパラメータであるＣＷＩＮを推定する（ステップＳ３０５）。そして、携帯型端末２１１ｂは、ステップＳ３０５で推定された推定値Ｄｃ’が、ＲＷＩＮとして設定されているサイクルデータサイズＤｃよりも小さいか否かを判定する（ステップＳ３０６）。携帯型端末２１１ｂは、推定値Ｄｃ’が小さい（Ｄｃ’＜Ｄｃ）と判定したときには（ステップＳ３０６のＹｅｓ）、ＣＷＩＮをサイクルデータサイズＤｃまで増加させるための処理（ＣＷＩＮ低下期間中の処理）を実行する（ステップＳ３０７）。一方、携帯型端末２１１ｂは、推定値Ｄｃ’がサイクルデータサイズＤｃ以上である（Ｄｃ’≧Ｄｃ）であると判定したときには（ステップＳ３０６のＮｏ）、ステップＳ３０１からの処理を繰り返す。

以下、ステップＳ３０２のパケットロス検知処理、ステップＳ３０４の再送誘発処理、ステップＳ３０５のＣＷＩＮ推定処理、および、ステップＳ３０７のＣＷＩＮの低下期間中の処理について、詳細に説明する。

図１６は、図１５のステップＳ３０２におけるパケットロス検知処理の詳細を説明するための説明図である。

例えば、時刻Ｔ３１に送信されたＡＣＫパケット（ＲＷＩＮ＝Ｄｃ）に対して送信側装置２０３から送信されたサイクルデータサイズＤｃ分のデータのうち、例えば４個のデータ（ＤＡＴＡ１〜４）のうち、ＤＡＴＡ３がロスする。

抑制再開制御部９０４は、パケットロスをタイムアウトにより検出する。具体的には、抑制再開制御部９０４は、送信側装置２０３に送信再開を促すＡＣＫパケットＰ１１を送信した時刻Ｔ３１から一定時間Ｔｏ１経過後の時刻Ｔ３２までに、通知したサイクルデータサイズＤｃ分の全てのデータを受信し切れなかった場合に、タイムアウトを検出し、パケットロスが発生したものとみなす。したがって、上述のようにＤＡＴＡ３がロスすると、抑制再開制御部９０４は、一定時間Ｔｏ１内にサイクルデータサイズＤｃ分の全てのデータを受信し切れないため、パケットロスの発生を検知する。なお、一定時間Ｔｏ１をタイムアウト値という。

例えば、抑制再開制御部９０４は、それまでのサイクルにおいて、送信側装置２０３に送信再開を促すＡＣＫパケットが送信された時刻から、通知したサイクルデータサイズＤｃ分の全てのデータを受信し切るまでの時間を計測する。そして、抑制再開制御部９０４は、その計測した時間のうち最大の時間を、上述のタイムアウト値Ｔｏ１に用いる。

また、抑制再開制御部９０４は、タイムアウト値Ｔｏ１の決定においては、送信再開を促すＡＣＫパケットが送信されてから、それに対する最初のデータを受信するまでの間隔であるＲＴＴや、連続したデータの受信間隔Ｒｔなどの情報を取得しておき、その情報からタイムアウト値Ｔｏ１を決定してもよい。即ち、抑制再開制御部９０４は、「ＲＴＴの最大値＋（Ｄｃ／ＭＳＳ−１）×Ｒｔの最大値＝Ｔｏ１」のように計算してもよい。また、抑制再開制御部９０４は、最大値ではなく、平均値や分散値などの各種統計値を用いることにより、より適切なタイムアウト値Ｔｏ１を設定してもよい。

また、タイムアウト値の計測の開始時点を、送信再開を促すＡＣＫパケットを送信した時刻Ｔ３１ではなく、通知したサイクルデータサイズＤｃ分のデータのうち最初に到着したパケットの到着時刻としてもよい。

また、抑制再開制御部９０４は、タイムアウトを用いずに、受信済みのデータのシーケンス番号を監視して、そのシーケンス番号が不連続であれば、パケットロスが発生したと検知してもよい。即ち、抑制再開制御部９０４は、図１６に示すように、ＤＡＴＡ３を受信せずにＤＡＴＡ４を受信したことによりパケットロスの発生を検知する。ここで、パケットロスが発生していなくても、ネットワーク上でのパケットの順序入れ替えの発生により、シーケンス番号が不連続となる場合がある。このような場合には、上述のようにシーケンス番号が不連続であることによってパケットロスの発生を検知すると、パケットロスが発生していなくてもパケットロスとみなしてしまう可能性がある。そこで、抑制再開制御部９０４は、不連続なシーケンス番号を持つデータを含むパケットを複数個受信したときまでに、または、不連続なシーケンス番号を持つデータを受信してから一定時間経過したときまでに、抜けていたデータを受信しなかった場合に、パケットロスの発生を検知してもよい。

図１７は、図１５のステップＳ３０４の再送誘発処理の詳細を説明するための説明図である。

パケットロスが発生した場合に受信側装置（携帯型端末）から何も送信されなければ、送信側装置２０３は、前述の第１のロス検知方法によりタイムアウトを発生させＣＷＩＮを１にしてから再送を行う。その結果、効率的に転送を行うことができなくなり、通信アプリケーションプログラムの性能要件を満たせなくなる可能性がある。

そこで、本実施の形態における受信側装置（携帯型端末）２１１ｂは、送信側装置２０３に対して、第２のロス検知方法による高速な再送を行わせ、ＣＷＩＮの減少を半分にとどめさせる。その結果、できるだけ効率的に送信側装置２０３にデータの転送を行わせる。

つまり、携帯型端末２１１ｂの抑制再開制御部９０４は、再送誘発処理では、送信側装置２０３に第２のロス検知方法を行わせるために、同一のＡＣＫパケットを４つ連続して送信するように通信制御部１０７に指示する。その結果、携帯型端末２１１ｂは、その４つのＡＣＫパケットＰ２１を送信側装置２０３に送信する。なお、これらの全てのＡＣＫパケットＰ２１に含まれる受信ウィンドウ（ＲＷＩＮ）は、サイクルデータサイズＤｃであって、全てのＡＣＫパケットＰ２１に含まれるＡＣＫ番号は、ロスしたパケットであるＤＡＴＡ３の送信を要求する値（例えば、３）となる。

このような４つのＡＣＫパケットＰ２１を受け取った送信側装置２０３は、ロスしたパケットであるＤＡＴＡ３を再送する。なお、送信側装置２０３は、パケットロス検知処理時のサイクルで送信されたサイクルデータサイズＤｃ分のデータ内でのロスしたパケットの位置や、送信側装置２０３のＴＣＰのバージョンや実装によって、ＤＡＴＡ４以降のパケットも送信することがある。例えば、送信側装置２０３は、ＤＡＴＡ３を再送するとともにＤＡＴＡ５およびＤＡＴＡ６を送信する。携帯型端末２１１ｂの抑制再開制御部９０４は、これらの全てのデータを受信するために、４番目のＡＣＫパケットＰ２１の送信時刻Ｔ４１から一定時間Ｔｏ２経過後の時刻Ｔ４２まで、データが届くのを待つ。なお、送信側装置２０３は、ＤＡＴＡ３の再送時には、ＤＡＴＡ４は既に送信されているため、そのＤＡＴＡ４を送信しない。しかし、ＤＡＴＡ４もロスした可能性を考慮して、送信側装置２０３は、ＤＡＴＡ４を再送してもよい。

また、抑制再開制御部９０４は、タイムアウト値Ｔｏ１の決定方法と同様に、ＲＴＴや連続したデータの受信間隔Ｒｔの統計情報などをもとに、一定時間Ｔｏ２を決定してもよい。即ち、抑制再開制御部９０４は、「ＲＴＴの最大値＋（Ｄｃ／ＭＳＳ−１）×Ｒｔの最大値＝Ｔｏ２」のように一定時間Ｔｏ２を決定する。また、抑制再開制御部９０４は、最大値ではなく、平均値や分散値などの各種統計値を用いることにより、より適切な一定時間Ｔｏ２を設定してもよい。

また、一定時間Ｔｏ２の計測の開始時点を、再送を促すＡＣＫパケットＰ２１を送信した時刻Ｔ４１ではなく、再送パケットの到着時刻としてもよい。

また、抑制再開制御部９０４は、再送を促すために同一のＡＣＫパケットＰ２１を４個だけ送信したが、このＡＣＫパケットＰ２１がロスする可能性を考慮して、さらに余分に同一のＡＣＫパケットを送信してもよい。

なお、パケットロス検知処理のサイクルにおいて１つのパケットのみがロスしていた場合には、上述の再送誘発処理により、ロスしたパケットが再送される。しかし、２つ以上のパケットがロスしていた場合には、２番目以降にロスしているパケットも再送させることが望ましい。このために、携帯型端末２１１ｂの抑制再開制御部９０４は、１番目にロスしたパケットに対する再送パケットが受信されると、２番目にロスしたパケットを再送させるための同一のＡＣＫパケットを４つ送信するように通信制御部１０７に指示する。ただし、この送信に対して送信側装置２０３が２番目にロスしたパケットを再送するかどうかは、送信側装置２０３のＴＣＰのバージョンや実装によって異なる。したがって、場合によっては、送信側装置２０３において第１のロス検知方法によるロス検知が行われ、ＣＷＩＮが１になる可能性もある。送信側装置２０３のＴＣＰが、２番目にロスしたパケットを再送するように実装されている場合には、携帯型端末２１１ｂの抑制再開制御部９０４は、１番目にロスしたパケットに対する処理と同様の処理を、全てのロスしたパケットに対して繰り返すことで、再送誘発処理を完了する。

なお、送信側装置２０３の状態がどうなっているか、即ち、第１のロス検知方法によりＣＷＩＮが１となっているのか、第２のロス検知方法の繰り返しの適用によりＣＷＩＮが１より大きな値となっているかは、この再送誘発処理の完了時にロスした全てのパケットの再送パケットを携帯型端末２１１ｂが受信しているかどうかにより判別可能である。

図１８は、図１５のステップＳ３０５のＣＷＩＮ推定処理の詳細を説明するための説明図である。

パケットロスが発生した場合、図１７に示す再送誘発処理の完了後には送信側装置２０３において輻輳ウィンドウ（ＣＷＩＮ）が小さくなっている。しかしながら、定常状態での省電力制御を行うためには、上述の第２の条件であるＣＷＩＮ≧ＲＷＩＮ（Ｄｃ）が満たされている必要がある。

そこで、抑制再開制御部９０４は、このＣＷＩＮの値がサイクルデータサイズＤｃ（期待値）を下回っていないかを知っておく必要があるため、ＣＷＩＮ推定処理では、送信側装置２０３のＣＷＩＮの値を推定する。

まず、抑制再開制御部９０４は、送信側装置２０３からのデータ送信を促すため、ＡＣＫパケットを送信するように指示する。その結果、携帯型端末２１１ｂは、そのＡＣＫパケットＰ３１を送信側装置２０３に送信する。このＡＣＫパケットＰ３１は受信ウィンドウ（ＲＷＩＮ）をサイクルデータサイズＤｃとして通知する。また、そのＡＣＫパケットＰ３１に設定されるＡＣＫ番号は、通常のＴＣＰどおり、ステップＳ３０４の再送誘発処理までに抜けなく受信できているデータのシーケンス番号の最大値＋１（例えば、Ｎ）である。

送信側装置２０３は、このＡＣＫパケットＰ３１を受信すると、Ｍｉｎ（Ｄｃ，ＣＷＩＮ）分のパケット、つまり、サイクルデータサイズＤｃとＣＷＩＮとのうち小さい方のサイズ分のパケットを送信する。

抑制再開制御部９０４は、この後、サイクルデータサイズＤｃ分のデータを受信できた場合には、ＣＷＩＮがサイクルデータサイズＤｃ以上であること、つまり上述の第２の条件が満たされていることを検知できる。また、抑制再開制御部９０４は、サイクルデータサイズＤｃ分のデータを受信できない場合には、ＡＣＫパケットＰ３１が送信された時刻Ｔ５１から一定時間Ｔｏ３経過後の時刻Ｔ５２までに受信されたデータの量（パケットの個数）を、ＣＷＩＮの推定値Ｄｃ’とする。

なお、抑制再開制御部９０４は、サイクルデータサイズＤｃ分のデータを受信できたか否かの判断には、パケットロスの検知やタイムアウトを利用する。つまり、抑制再開制御部９０４は、通信Ｉ／Ｆ部１０８から送信されたＡＣＫパケットに対して、送信側装置２０３から送信されて通信Ｉ／Ｆ部１０８に順次受信された各データのシーケンス番号が連続であるか不連続であるかを判別する。そして、抑制再開制御部９０４は、不連続であると判別したとき、つまりパケットロスがあったと判別したときに、サイクルデータサイズＤｃ分のデータを受信できなかったと判断する。また、抑制再開制御部９０４は、通信Ｉ／Ｆ部１０８から送信されたＡＣＫパケットに対して、送信側装置２０３から送信されて通信Ｉ／Ｆ部１０８に順次受信された各データの合計サイズが、予め定められた期間内で、そのＡＣＫパケットの示すサイクルデータサイズＤｃに達するか否かを判別する。そして、そして、抑制再開制御部９０４は、サイクルデータサイズＤｃに達しないと判別したとき、つまりタイムアウトがあったと判別したときに、サイクルデータサイズＤｃ分のデータを受信できなかったと判断する。

図１９は、ステップＳ３０７のＣＷＩＮ低下期間中の処理の詳細を示すフローチャートである。

ＣＷＩＮ低下期間中はＣＷＩＮ＜Ｄｃとなっている。したがって、携帯型端末が、受信ウィンドウをサイクルデータサイズＤｃとして送信側装置２０３に通知しても、送信側装置２０３はＣＷＩＮ分しかデータを送らない。その結果、携帯型端末は、いつまでたっても通信Ｉ／Ｆ部１０８の電源を切断できなくなり、省電力制御を行えないという問題が発生する。

このため、携帯型端末２１１ｂの抑制再開制御部９０４は、ＣＷＩＮ低下期間の最初では、まず受信ウィンドウをＣＷＩＮの推定値Ｄｃ’として通知するように通信制御部１０７に指示する。こうすれば、携帯型端末（受信側装置）２１１ｂは、通知した受信ウィンドウ分のデータ、つまり推定値Ｄｃ’分のデータを受信することができ、通信Ｉ／Ｆ部１０８の電源を切断することができる。また、送信側装置２０３は、ＴＣＰの輻輳制御手順により、「ＣＷＩＮ／ＭＳＳ個のＡＣＫパケットを受信するとＣＷＩＮをＭＳＳ分大きくする」という制御を行う。したがって、携帯型端末２１１ｂの抑制再開制御部９０４は、このＣＷＩＮの増加に合わせて、通知する受信ウィンドウのサイズを大きくする。その結果、抑制再開制御部９０４は、最終的には受信ウィンドウのサイズを元のサイクルデータサイズＤｃとして通知することができ、定常状態で省電力制御を継続することが可能となる。

抑制再開制御部９０４は、実際の処理として、まず、ＣＷＩＮ低下期間中のサイクルデータサイズＤｃＸの初期値を推定値Ｄｃ’とするとともに、ＣＷＩＮ低下期間中のサイクル間隔ＴｃＸの初期値をＤｃ’／ＢＷとする（ステップＳ４０１）。なお、ＴｃＸ＝ＤｃＸ／ＢＷとすることで、ＣＷＩＮ低下期間中もＢＷ[Ｂｙｔｅ／ｓｅｃ]のレートを確保することができる。これは、サイクルデータサイズがＤｃからＤｃ’に低下したのに比例してサイクル間隔Ｔｃも短くすることに相当する。

次に、抑制再開制御部９０４は、上記サイクルデータサイズＤｃＸおよびサイクル間隔ＴｃＸに基づく間欠受信サイクルをＤｃＸ／ＭＳＳ回繰り返す（ステップＳ４０２）。つまり、携帯型端末２１１ｂは、ＲＷＩＮ＝ＤｃＸのＡＣＫパケットを送信して、サイクルデータサイズＤｃＸ分のデータを受信し、そのＡＣＫパケットの送信からサイクル間隔ＴｃＸが経過するまで次のＡＣＫパケットの送信を停止しておくという間欠受信を（ＤｃＸ／ＭＳＳ）サイクルだけ繰り返す。このような間欠受信を繰り返すことによっても、携帯型端末２１１ｂは、サイクルデータサイズＤｃＸ分のデータを受信してから、次のＡＣＫパケットを送信するまで、通信Ｉ／Ｆ部１０８の電源をＯＦＦにすることができ、省電力制御を行なうことができる。また、このような間欠受信の繰り返しによって、送信側装置２０３は、ＤｃＸ／ＭＳＳ個のＡＣＫを受信することになり、その結果、ＣＷＩＮをＭＳＳ分だけ増加させる。

したがって、間欠受信サイクルがＤｃＸ／ＭＳＳ回繰り返されると、次のサイクルからは、それまでよりサイクルデータサイズＤｃＸをＭＳＳ分大きくしても省電力制御を行うことができる。

このため、抑制再開制御部９０４は、サイクルデータサイズＤｃＸをＭＳＳ大きくし、それに合わせてサイクル間隔ＴｃＸも更新する（ステップＳ４０３）。そして、抑制再開制御部９０４は、ステップＳ４０３でサイクルデータサイズＤｃＸが大きくなることで、そのサイクルデータサイズＤｃＸが、パケットロス発生前の元のサイクルデータサイズＤｃ以上になったか否かを判別する（ステップＳ４０４）。

ここで、抑制再開制御部９０４は、サイクルデータサイズＤｃ以上になったと判別したときには（ステップＳ４０４のＹｅｓ）、ＣＷＩＮ低下期間中の処理を完了し、図１５に示すステップＳ３０１の定常状態処理を実行する。一方、抑制再開制御部９０４は、サイクルデータサイズＤｃＸがまだ元のサイクルデータサイズＤｃに満たないと判別したときには（ステップＳ４０４のＮｏ）、更新されたサイクルデータサイズＤｃＸおよびサイクル間隔ＴｃＸを用いて、ステップＳ４０２からの処理、つまり間欠受信をＤｃＸ／ＭＳＳ回繰り返す処理を行う。

図２０は、ステップＳ３０７のＣＷＩＮ低下期間中において行われる間欠受信の１サイクルを示す図である。

ＣＷＩＮ低下期間中では、携帯型端末２１１ｂは、例えば時刻Ｔ６１に、（ＲＷＩＮ＝ＤｃＸ）のＡＣＫパケットＰ４１を送信する。その結果、携帯型端末２１１ｂは、時刻Ｔ６２に、ＣＷＩＮ低下期間中のサイクルデータサイズＤｃＸ分のデータを送信側装置２０３から受信する。そして、携帯型端末２１１ｂは、そのＡＣＫパケットＰ４１を送信してから、ＣＷＩＮ低下期間中のサイクル間隔ＴｃＸが経過するまで、つまり時刻Ｔ６３まで次のＡＣＫパケットの送信を停止する。さらに、携帯型端末２１１ｂは、時刻Ｔ６１〜Ｔ６２までは通信Ｉ／Ｆ部１０８の電源をＯＮにして、時刻Ｔ６２〜Ｔ６３まではその電源をＯＦＦにするような省電力制御を行なう。携帯型端末２１１ｂは、このような時刻Ｔ６１〜Ｔ６３までの処理を間欠受信の１サイクルとして実行する。

なお、抑制再開制御部９０４は、ステップＳ３０７におけるＣＷＩＮ低下期間中の処理中に、パケットロスを検知した場合も、図１５に示すステップＳ３０１〜Ｓ３０８の処理を行なえばよい。

また、抑制再開制御部９０４は、図２０に示すように、１サイクルにＡＣＫパケットを一つだけ送信するが、複数のＡＣＫパケットを送信してもよい。つまり、送信されるＡＣＫパケットが１つの場合には、ＣＷＩＮを増加させるために、間欠受信のサイクルをＤｃＸ／ＭＳＳ回繰り返す必要がある。しかし、１サイクルにＡＣＫ番号の異なる複数個（例えばＮ個）のＡＣＫパケットを送信すれば、間欠受信のサイクルの繰り返し回数をＤｃＸ／（ＭＳＳ×Ｎ）回に抑えることができる。さらに、Ｎ＝ＤｃＸ／ＭＳＳとすれば、間欠受信のサイクルの繰り返し回数を１サイクルにすることができる。

また、上記処理を行っただけでは、通信アプリケーションプログラムの要求である帯域ＢＷを十分確保したとはいえない場合がある。即ち、ステップＳ３０７のＣＷＩＮ低下期間中の処理、およびステップＳ３０１の定常状態処理の期間においては、帯域ＢＷは確保されている。しかし、ステップ３０２のパケットロス検知処理、ステップＳ３０４の再送誘発処理、ステップＳ３０５のＣＷＩＮ推定処理を行っている期間においては、タイムアウト待ちを行っていることにより、帯域ＢＷは確保されていない。

通信アプリケーションプログラムが帯域ＢＷを要求しているということは、ＴＣＰコネクション開始時から帯域ＢＷで通信し続けただけのデータを受信している必要があるが、上記処理ではこれが満たされてないことになる。この問題は、「ＴＣＰコネクション開始時から受信したデータの総量＝通信開始時からの経過時間×ＢＷ」の条件が成り立つまで、例えば以下の３つの制御方法を実行することにより回避可能である。第１の制御方法では、ステップＳ３０７のＣＷＩＮ低下期間中の処理において、サイクル間隔ＴｃＸの値を上記処理よりも短く設定することにより、一時的に帯域ＢＷ以上の帯域を確保する。また、第２の制御方法では、ＣＷＩＮ低下期間終了後のステップＳ３０１の定常状態処理において、サイクル間隔Ｔｃを短くする、もしくはサイクルデータサイズＤｃを大きくすることにより、一時的にＢＷ以上の帯域を確保する。上述の条件が成り立った後は、サイクル間隔ＴｃおよびサイクルデータサイズＤｃをパケットロス発生前の元の値に戻せばよい。第３の制御方法では、送信抑制制御（間欠受信）を一時的に中断する。例えば、抑制再開制御部９０４は、ＣＷＩＮがサイクルデータサイズＤｃよりも小さくなってからサイクルデータサイズＤｃ以上になるまでのウィンドウ回復期間、ＡＣＫパケットの通常の送信の抑制（停止）を解除し、通信Ｉ／Ｆ部１０８でデータが受信されるごとに、ＡＣＫパケットを通信Ｉ／Ｆ部１０８から送信させる。また、このとき、上述と同様に、１つのＡＣＫパケットを、ＡＣＫ番号の異なる複数個（例えばＮ個）のＡＣＫパケットに分けて送信することによって、ＣＷＩＮをサイクルデータサイズＤｃ以上に早急に回復させることができる。

また、上記処理では、定常状態では間欠受信サイクルが成功することを前提としている。しかし、上記処理では、送信側装置２０３はサイクルデータサイズＤｃ分だけのデータをバースト的に送信することになるため、例えば中継装置が転送パケットを格納するために保持しているバッファのサイズがサイクルデータサイズＤｃよりも小さい場合などは、必ずパケットロスが発生し定常状態処理を行えない可能性がある。このため、定常状態での処理が成功しない状況においては、サイクルデータサイズをＤｃよりも小さな値Ｄ”とし、サイクル間隔もＴｃより小さい値Ｄ”／ＢＷとした定常状態処理を行なうなどの必要がある。なお、ネットワークの状況などは動的に変化するため、パケットロスの発生に応じてサイクル間隔およびサイクルデータサイズを動的に変化させることにより、より最適な（通信アプリケーションプログラムの要求を満たしつつ、できるだけ省電力効果の高い）パラメータを探索するように動作してもよい。また、動的にパラメータを変更しつつ、最適なパラメータ値を探索するアルゴリズムは、一般に用いられている探索アルゴリズムなどを流用すればよく、本発明の本質ではないためここでは詳細なアルゴリズムについては説明を省略する。

また、上記では、図１５に示すように、ステップＳ３０７でＣＷＩＮ低下期間中の処理を行うかどうかを判定したり、ＣＷＩＮ低下期間中のサイクルデータサイズの初期値Ｄｃ’を決定したりするために、ステップＳ３０５のＣＷＩＮ推定処理を行った。しかし、ＣＷＩＮ推定処理は、より効率的に、即ち必要以上に転送レートを低下させないために行う処理であり、必ずしも本発明に必須の処理ではない。例えば、パケットロスが１回しか発生していない場合などは、ＣＷＩＮは最低でもパケットロス発生前の１／２以上であると言えるため、サイクルデータサイズの初期値をサイクルデータサイズＤｃの１／２として、必ずＣＷＩＮの低下期間中の処理を行ってもよい。

上記のような処理を行うことにより、パケットロスが発生した場合でも、通信帯域を維持しつつ間欠受信による省電力制御を継続することができる。

（実施の形態４）
次に、本発明の実施の形態４に係る通信装置について説明する。実施の形態１〜３の通信装置は、フロー制御を終端するが、本実施の形態における通信装置はフロー制御を行う通信を中継する。つまり、本実施の形態における通信装置は、中継通信装置として構成され、実施の形態１の携帯型端末２１１自体のＴＣＰ通信に対して行っていた制御を、中継しているＴＣＰ通信に対して行う。したがって、本実施の形態における間欠受信および省電力制御の本質は、実施の形態１と共通するため、以下では、本実施の形態における実施の形態１との差分を中心に説明する。

図２１は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。なお、本実施の形態に含まれる構成要素中、実施の形態１と同一の機能および構成を有する構成要素に対しては、実施の形態１の構成要素と同一の符号を付して示し、詳細な説明は省略する。

本実施の形態に係る通信システムは、携帯型端末２１２と、携帯型端末５０１と、受信側装置５０２と、無線基地局２０２と、インターネット２０４と、送信側装置２０３とを備えている。

本実施の形態における携帯型端末５０１と受信側装置５０２は、それぞれが組み合わされた状態で、インターネット２０４および無線基地局２０２を介して送信側装置２０３に対して、実施の形態１の携帯型端末２１１と同様の処理動作を行う。

また、携帯型端末５０１は、送信側装置２０３と受信側装置５０２との間の通信を中継する。

つまり、本実施の形態の通信システムと、実施の形態１の図３に示す通信システムとの違いは、実施の形態１では本発明の通信装置たる携帯型端末２１２が受信側装置として動作していたのに対し、本実施の形態では本発明の通信装置たる携帯型端末５０１が中継装置として動作し、その携帯型端末５０１に別の受信側装置５０２が接続されている点である。

図２２は、本実施の形態における携帯型端末５０１の具体的な構成を示す構成図である。

携帯型端末５０１は、アプリ要求取得部１０２と、パラメータ決定部１０３と、抑制再開制御部５０４と、電源制御部１０６と、通信制御部１０７と、通信Ｉ／Ｆ部１０８と、サブ通信Ｉ／Ｆ部１０９とを備える。

つまり、本実施の形態における携帯型端末５０１は、実施の形態１の携帯型端末２１１にないサブ通信Ｉ／Ｆ部１０９を備えるとともに、携帯型端末２１１にある通信アプリケーション部１０１を備えていない。また、本実施の形態における携帯型端末５０１は、実施の形態１の携帯型端末２１１における抑制再開制御部１０４の代わりに、抑制再開制御部５０４を備える。

サブ通信Ｉ／Ｆ部１０９は、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）などの有線ＬＡＮや、無線ＬＡＮ、ＵＳＢ（Universal Sirial Bus）などで受信側装置５０２と通信する。なお、サブ通信Ｉ／Ｆ部１０９の通信方式は、これら以外の任意の通信方式であってもよい。

抑制再開制御部５０４は、実施の形態１の抑制再開制御部１０４と同様、間欠受信パラメータ登録通知によって受け取った間欠受信パラメータに応じて、送信側装置２０３からのデータ送信を抑制または再開させるタイミングを決定する。また、抑制再開制御部５０４は、決定したタイミングに、送信側装置２０３からのデータ送信を抑制または再開させるため、通信制御部１０７に対してＡＣＫパケットの転送に関係する３つの要求（後述）を発行する。

実施の形態１では、通信制御部１０７がＴＣＰの処理を行っていたため、抑制再開制御部１０４は、その通信制御部１０７に対して、ＡＣＫパケットの送信の可否を要求したり、ＡＣＫパケットの内容を所定の内容にするように要求したり、ＡＣＫパケットの送信のタイミングを要求した。本実施の形態では、通信制御部１０７が送信側装置２０３および受信側装置５０２の送信するパケットの転送を行うため、抑制再開制御部５０４は、通信制御部１０７に対して、受信側装置５０２の送信したＡＣＫパケットの転送の可否を要求したり、受信側装置５０２のＩＰアドレスが送信元アドレスとなるように、ＡＣＫパケットの内容を所定の内容にするように要求したり、ＡＣＫパケットの転送のタイミングを要求する。

具体的に、通信制御部１０７は、抑制再開制御部５０４から、ＡＣＫ通常転送抑制要求、ＡＣＫ通常転送再開要求、およびＡＣＫ単発送信要求を受けて、それらの要求に対応する。

ＡＣＫ通常転送抑制要求は、通常のＡＣＫパケット転送を抑制させるための要求である。通信制御部１０７は、この要求を受けると、以後、受信側装置５０２から送信されたＡＣＫパケットの転送を行わなくなる。

ＡＣＫ通常転送再開要求は、ＡＣＫ通常転送抑制要求を解除させる要求である。通信制御部１０７は、この要求を受けると、通常の処理（受信側装置５０２から送信されたＡＣＫパケットの転送）を再開する。

ＡＣＫ単発送信要求は、抑制再開制御部５０４から指定されたタイミングで、抑制再開制御部５０４から指定された内容のＡＣＫパケットを送信させる要求である。通信制御部１０７は、この要求を受けると、受信側装置５０２がＡＣＫパケットを送信するタイミングに関係なく、指定された内容のＡＣＫパケットを指定されたタイミングで送信する。なお、この要求は、ＡＣＫ通常転送抑制要求を受けている状態でも有効である（送信可能である）。また、抑制再開制御部５０４は、このＡＣＫパケットの送信元ＩＰアドレスには受信側装置５０２のＩＰアドレスを用いるように通信制御部１０７に指示する。

次に、本実施の形態における、間欠受信の準備状態に入るまでの処理について説明する。本実施の形態における上記処理では、実施の形態１の処理と比べて、間欠受信パラメータに関する処理のみが異なる。そこで、間欠受信パラメータに関する処理について説明する。

実施の形態１では、アプリ要求取得部１０２は、通信アプリケーションプログラムから性能に関する要求（性能パラメータ）を受信し、これを性能パラメータ管理テーブルで管理していた。しかし、本実施の形態においては、通信を行う通信アプリケーションプログラムは、受信側装置５０２にあるため、この要求性能に関する情報（性能パラメータ）も受信側装置５０２が保持している。このため、本実施の形態のアプリ要求取得部１０２は、以下の処理を行うことにより性能パラメータを取得する。

例えば、アプリ要求取得部１０２は、受信側装置５０２からサブ通信Ｉ／Ｆ部１０９を経由して通信アプリケーションプログラムに関する情報（性能パラメータ）を取得する。このとき、アプリ要求取得部１０２は、その後に開始されるＴＣＰ通信を識別するための情報を合わせて取得する。例えば、アプリ要求取得部１０２は、送信側装置２０３のＩＰアドレス情報や、通信アプリケーションプログラムが使用するポート番号の情報、もしくはＴＣＰ通信を識別するためのＩＤ情報を取得する。ＩＤ情報を取得する場合は、その後開始されるＴＣＰ通信において、例えばＩＰヘッダオプションフィールドやＴＣＰヘッダオプションフィールドなどにこのＩＤ情報を含めることで携帯型端末５０１がＴＣＰコネクションを認識できるようにすればよい。

また、アプリ要求取得部１０２は、受信側装置５０２から性能パラメータを取得できない場合は、既定のパラメータを性能パラメータに適用する。なお、既定のパラメータでは、通信アプリケーションプログラムの性能要件を満たせなかったり、必要以上に通信Ｉ／Ｆ部１０８の電力を消費したりする可能性があるため、携帯型端末５０１のＵＩ（User Interface）などからこの既定のパラメータを変更できるようにしてもよい。

次に、本実施の形態における間欠受信の準備状態の処理について説明する。まず、受信側装置５０２と送信側装置２０３の間でＴＣＰコネクションが確立される。携帯型端末５０１の通信制御部１０７は、コネクション開始時のＴＣＰパケット（ＳＹＮパケット等）を転送する際に、制御対象であるＴＣＰコネクションが開始されたことを検知する。ＴＣＰコネクションの確立後、受信側装置５０２と送信側装置２０３の間のＴＣＰパケットは、携帯型端末５０１の通信Ｉ／Ｆ部１０８、通信制御部１０７、およびサブ通信Ｉ／Ｆ部１０９を介して送受信される。

その後、抑制再開制御部５０４は、通信制御部１０７で転送されるＴＣＰパケットをモニタリングし、転送データの帯域（転送帯域）が、間欠受信パラメータ管理テーブルに設定されている帯域（設定帯域ＢＷ＝Ｄｃ／Ｔｃ）に到達するのを待つ。例えば、抑制再開制御部５０４は、実施の形態１の抑制再開制御部１０４と同様、サイクル間隔Ｔｃの経過ごとに、そのサイクル間隔Ｔｃの間に受信したＴＣＰパケットのデータサイズを合計することで、合計データサイズＴｌＤを算出する。そして、抑制再開制御部５０４は、「ＴｌＤ／Ｔｃ≧ＢＷ」の条件を満たす回数が所定回数以上だけ続いたときに、転送帯域が設定帯域ＢＷに到達したと見なす。

抑制再開制御部５０４は、転送帯域が設定帯域ＢＷに到達すると、送信側装置２０３からのデータ送信を抑制するために、通信制御部１０７に対してＡＣＫ通常転送抑制要求を発行する。なお、この発行は、間欠受信の１回目の処理に相当する。このとき、抑制再開制御部５０４は、通信制御部１０７からそれまでに送信した最後のＡＣＫパケットの情報、すなわち、ＡＣＫ番号（ＬＡＳＴ＿ＡＣＫＮＯ）と受信ウィンドウ（ＬＡＳＴ＿ＲＷＩＮ）とを保持しておく。通信制御部１０７は、抑制再開制御部５０４からＡＣＫ通常転送抑制要求を受けると、以後、受信側装置５０２から送信されたＡＣＫパケットを転送しないようにする。

一方、送信側装置２０３は、受信側装置５０２からＡＣＫパケットが送られてこなくなっても、自身の管理する送信可能なデータサイズ（ｕｗｎｄ）が０になるまで、データ送信を続け、ｕｗｎｄが０になった時点で、データ送信を終了する。その結果、送信側装置２０３は送信抑制期間に入る。

抑制再開制御部５０４は、ＡＣＫ通常転送抑制要求の発行後もＴＣＰパケットをモニタリングし、送信側装置２０３での送信可能なデータサイズ（ｕｗｎｄ）が０になるのを待つ。具体的には、抑制再開制御部５０４は、受信したＴＣＰパケットのシーケンス番号とデータサイズを参照し、（シーケンス番号＋データサイズ）が（ＬＡＳＴ＿ＡＣＫＮＯ＋ＬＡＳＴ＿ＲＷＩＮ）に到達するのを待つ。

抑制再開制御部５０４は、ｕｗｎｄが０になったと判断したら、電源制御部１０６へ切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

抑制再開制御部５０４は、電源制御部１０６へ切断要求を発行した後、所定時間の満了を待つ。この所定時間は、サイクル間隔Ｔｃと一致していてもよいし、異なる時間であっても良い。送信側装置２０３は、既に送信抑制期間に入っているので、通信Ｉ／Ｆ部１０８の電源が切断されている間、データ送信を行なわない。

所定時間が満了したとき、抑制再開制御部５０４は、電源制御部１０６へ投入要求を発行する。さらに、抑制再開制御部５０４は、間欠受信の準備状態が満了したと見なし、定常状態に遷移する。電源制御部１０６は投入要求を受けると、通信Ｉ／Ｆ部１０８の電源を投入する。

以下、本実施の形態における定常状態の処理について説明する。

図２３は、本実施の形態における受信側装置５０２と携帯型端末５０１と送信側装置２０３の定常状態での動さを示すシーケンス図である。

定常状態での１サイクル分の動作は、送信再開処理と、送信抑制期間の開始処理と、送信抑制期間の終了処理との３つのステップに分けられる。

送信再開処理（ステップ１）では、抑制再開制御部５０４は、送信側装置２０３からのデータ送信を再開させるため、通信制御部１０７に対してＡＣＫ単発送信要求を発行する。このとき、抑制再開制御部５０４は、ＡＣＫパケットの受信ウィンドウ（ＲＷＩＮ）として、間欠受信パラメータ管理テーブルに格納されたサイクルデータサイズＤｃを指定する。通信制御部１０７は、時刻Ｔ７１に、ＡＣＫ単発送信要求を受け取ると、ＲＷＩＮ＝ＤｃのＡＣＫパケットＰ５１を通信Ｉ／Ｆ部１０８を介して送信する。このとき、抑制再開制御部５０４は、受信側装置５０２から受信して転送していないＡＣＫパケットのＡＣＫ番号のうち最大のものを記憶しているため、その記憶しているＡＣＫ番号を、ＡＣＫパケットＰ５１のＡＣＫ番号にする。なお、送信側装置２０３がこのＡＣＫパケットＰ５１を正当なパケットとして受信できるように、そのＡＣＫパケット５１では、送信元ＩＰアドレスは受信側装置５０２のＩＰアドレスとされ、ポート番号は当該ＴＣＰコネクションのポート番号とされる。

一方、送信側装置２０３は、携帯型端末５０１が送信したＡＣＫパケット（ＲＷＩＮ＝Ｄｃ）を受信すると、間欠受信の準備状態、または、送信抑制期間が終了し、データ送信が可能な状態になる。その結果、送信側装置２０３は、受信側装置５０２あてのＴＣＰパケット（データＰ５２）の送信を再開する。

携帯型端末５０１の抑制再開制御部５０４は、間欠受信の準備状態でＡＣＫ通常転送抑制要求を発行しているので、受信側装置５０２が送信したＡＣＫパケットの転送は既に抑制されている。すなわち、サブ通信Ｉ／Ｆ部１０９が受信側装置５０２からのＡＣＫパケットを受信して、そのＡＣＫパケットを通信制御部１０７に引渡しても、通信制御部１０７はそのＡＣＫパケットを通信Ｉ／Ｆ部１０８を通して送信側装置２０３に対して送信しない。そのため、送信側装置２０３が一度に送信できるデータＰ５２のサイズは、サイクルデータサイズＤｃに制限される。

送信抑制期間の開始処理（ステップ２）では、抑制再開制御部５０４は、時刻Ｔ７１以降、通信制御部１０７で転送されるＴＣＰパケットをモニタリングする。そして、抑制再開制御部５０４は、時刻Ｔ７１以降で転送したデータサイズがサイクルデータサイズＤｃに到達したかどうか、すなわち、送信側装置２０３の送信可能なデータサイズ（ｕｗｎｄ）が０になったかどうかを確認し続ける。このとき抑制再開制御部５０４は、間欠受信の準備状態での確認処理と同じく、最後に送信したＡＣＫパケットのＡＣＫ番号と受信ウィンドウ（ＲＷＩＮ＝Ｄｃ）を使って上述の確認を行う。Ｔ７１以降で転送したデータサイズがＤｃに到達したとき、即ち時刻Ｔ７２で、抑制再開制御部５０４は、送信抑制期間が開始したとみなし、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

送信抑制期間の終了処理（ステップ３）では、本発明の実施の形態における携帯型端末５０１では、Ｔ７１時点を起点として、サイクル間隔Ｔｃの時間経過後の時刻Ｔ７３を、送信抑制期間の終了点と見なす。つまり、抑制再開制御部５０４は、タイマにより時刻Ｔ７３のタイミングを検出し、電源制御部１０６に投入要求を発行する。その結果、投入要求により、電源制御部１０６は時刻Ｔ７３に通信Ｉ／Ｆ部１０８の電源を投入する。

携帯型端末５０１は、定常状態では、上記３つのステップを１サイクルとして、繰り返し実行する。

このように、本実施の形態では、実施の形態１での省電力方法と同様の間欠受信制御を、ＴＣＰ通信を中継する通信装置に対しても適用することができ、実施の形態１と同様の省電力効果を得ることができる。また、ここでは説明を省略するが、実施の形態２による省電力効果の向上や、実施の形態３によるパケットロス時の動作などもＴＣＰ通信を中継する通信装置に対して適用することも可能である。

（実施の形態５）
以下、本発明の第５の実施の形態における通信装置について図面を参照しながら説明する。実施の形態１から４では、本発明に係る通信装置を受信側装置に対して適用したが、本実施の形態では、本発明に係る通信装置を送信側装置に適用し、送信側装置の省電力効果を向上させる。また、本実施の形態における送信側装置は、受信側装置に対して、間欠送信処理を行うことを通知することで、より確実に省電力効果を高める。

図２４は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型端末６１１，６１２と、無線基地局２０２と、インターネット２０４と、受信側装置６０３とを備えている。

携帯型端末６１１，６１２は、通信品質と省電力効果のさらなる向上を両立して図った送信側装置であって、無線基地局２０２およびインターネット２０４を介して、受信側装置６０３にデータを送信する。受信側装置６０３は、インターネット２０４および無線基地局２０２を介して、携帯型端末６１１，６１２から送信されたデータを受信する。

ここで、本実施の形態における携帯型端末６１１について詳細に説明する。

図２５は、本実施の形態における携帯型端末６１１の一例を示す構成図である。

携帯型端末６１１は、通信アプリケーション部６２１と、アプリ要求取得部６２２と、パラメータ決定部６２３と、抑制再開制御部６２４と、電源制御部１０６と、通信制御部６２７と、通信Ｉ／Ｆ部１０８とを備える。この携帯型端末６１１は、受信側装置６０３からＡＣＫパケットを受信しても、直ちにそのＡＣＫパケットに応じたデータパケット（送信データ）を送信することなく、所定期間（上述の送信抑制期間）だけデータパケットの送信を停止して、その所定期間経過後にデータパケットを送信する。言い換えれば、携帯型端末６１１は、フロー制御の仕組みを使ってデータ送信の抑制と再開を繰り返すことで、携帯型端末６１１の所望する間隔での間欠的なデータ送信（間欠送信）を行う。これにより、携帯型端末６１１は、その所定期間だけ通信Ｉ／Ｆ部１０８に供給される電力を抑えることができ省電力効果の向上を図ることができる。

また、本実施の形態における携帯型端末６１１が備えている上記各構成要素は、基本的に、実施の形態１の携帯型端末２１１が備えている各構成要素のデータ受信用の機能に対応した、データ送信用の機能を有する。したがって、本実施の形態における携帯型端末６１１が備えている上記各構成要素の機能のうち、実施の形態１の携帯型端末２１１が備えている各構成要素の機能に対応しているものについては、以下、簡単に説明し、単純に対応していない機能についてのみ詳細に説明する。

なお、本実施の形態では、抑制再開制御部６２４が抑制手段および切換制御手段として構成されている。

通信アプリケーション部６２１は、通信アプリケーションプログラムを実行する。通信アプリケーション部６２１は、通信アプリケーションプログラムの起動時に、アプリ要求取得部６２２に起動通知を発行し、受信側装置６０３との間でデータ送受信を行なう。また、通信アプリケーション部６２１は、通信アプリケーションプログラムの終了時に、アプリ要求取得部６２２に終了通知を発行する。なお、本実施の形態では、説明の単純化のため、携帯型端末６１１上で同時に動作する通信アプリケーションプログラムが１つに限定されているものとする。

アプリ要求取得部６２２は、通信アプリケーション部６２１と受信側装置６０３との間でのデータ通信の「性能パラメータ」を入手する。アプリ要求取得部６２２は、通信アプリケーション部６２１から起動通知または終了通知を受けると、同時にその性能パラメータを通信アプリケーション部６２１から入手し、パラメータ決定部６２３に対して、性能パラメータ登録通知または性能パラメータ削除通知を発行する。

なお、アプリ要求取得部６２２は、送信されるデータのタイプ（アプリケーションタイプ）や、ファイルサイズ、バッファサイズなどに基づいて、性能パラメータである帯域ＢＷおよび遅延時間ＤＴなどを決定してもよい。たとえば、アプリケーションタイプがＭＰＥＧであれば、アプリ要求取得部６２２は、画像が乱れない程度の必要な帯域を性能パラメータとして決定する。

パラメータ決定部６２３は、間欠的にデータを送信するためのパラメータを決定する。間欠的にデータを送信するためのパラメータは、実施の形態１の間欠受信時と同様に、間欠送信のサイクル間隔およびサイクルデータサイズからなる。また、これらの２つのパラメータを総称して「間欠送信パラメータ」と呼ぶ。パラメータ決定部６２３は、アプリ要求取得部６２２から性能パラメータ登録通知または性能パラメータ削除通知を受けつけたとき、アプリ要求取得部６２２からの性能パラメータを元に間欠送信パラメータを決定し、抑制再開制御部６２４に間欠送信パラメータ登録通知または間欠送信パラメータ削除通知を送信する。

抑制再開制御部６２４は、受信側装置６０３へのデータ送信が間欠的に行なわれるように、通信制御部６２７を制御する。抑制再開制御部６２４は、送信したデータに対するＡＣＫパケットを受信した後、受信側装置６０３へのデータ送信を行わない期間を作る。この期間のことを送信抑制期間と呼ぶ。さらに、抑制再開制御部６２４は、この制御によって得られた送信抑制期間に通信Ｉ／Ｆ部１０８の電源が切断されるように、電源制御部１０６へ指示を出す。

具体的には、抑制再開制御部６２４は、間欠送信パラメータ登録通知によって受け取った間欠送信パラメータに応じて、受信側装置６０３へのデータ送信を抑制または再開するタイミングを決定する。また、抑制再開制御部６２４は、送信抑制期間に連動して、電源制御部１０６に対して投入または切断の要求を送信する。さらに、抑制再開制御部６２４は、通信制御部６２７で送受信するＴＣＰパケットをモニタリングし、そのモニタリングの結果を上述のタイミングの決定に利用する。

電源制御部１０６は、抑制再開制御部６２４からの投入または切断の要求に従って、通信Ｉ／Ｆ部１０８の電源を投入または切断する。

通信制御部６２７は、通常のＴＣＰ処理に加えて、抑制再開制御部６２４からの要求を受けて、データパケットの送信タイミングやパケット内容を変更する。具体的には、通信制御部６２７は、抑制再開制御部６２４から、データパケット通常送信抑制要求、データパケット通常送信再開要求、指定サイズデータ送信要求を受けて、それらの要求に対応する。

データパケット通常送信抑制要求は、通常のデータパケット送信を抑制させる要求である。通信制御部６２７は、この要求を受けると、以後、指定サイズデータ送信要求、もしくは、データパケット通常送信再開要求を受けない限り、データパケットを送信しない。

データパケット通常送信再開要求は、データパケット通常送信抑制要求によって停止していたデータパケットの送信抑制を解除し、通常のＴＣＰにしたがって、データパケットを送信させる要求である。

指定サイズデータ送信要求は、データパケット通常送信抑制要求を受けた状態において有効であり、指定されたサイズのデータをＴＣＰにしたがって送信させる要求である。通信制御部６２７は、通信Ｉ／Ｆ部１０８を介して、指定されたサイズのデータパケットを送信し、送信したデータパケットに対応するＡＣＫパケットを受信したと判断した時点で、データパケットの送信を停止する。

このような携帯型端末６１１が初期状態から通信を開始して終了するまでの携帯型端末６１１の動作について、以下、説明する。

初期状態では、実施の形態１の間欠受信パラメータの登録と同様に、携帯型端末６１１は、性能パラメータに基づいて間欠送信パラメータ管理テーブルを登録し、通常のＴＣＰにしたがった処理を開始する。

次に、携帯型端末６１１は、間欠送信の準備状態の処理を行う。この準備状態においては、携帯型端末６１１は、まず、間欠送信を行うことを受信側装置６０３に通知する。すなわち、携帯型端末６１１は、ＴＣＰの通信を開設する際に、間欠送信処理を行う旨を受信側装置６０３に通知するために、ＴＣＰヘッダのオプションフィールドにおいて間欠送受信有効フラグを有効にし、３ＷＡＹハンドシェイクを行う。これにより、受信側装置６０３の間欠受信処理を抑えることができ、より確実に省電力効果を高めることができる。つまり、受信側装置６０３が実施の形態１の携帯型端末２１１のように間欠受信を行うことが可能な通信装置である場合に、受信側装置６０３による間欠受信と、携帯型端末６１１による間欠送信とが同時に行われると、携帯型端末６１１と受信側装置６０３との間での通信（間欠送信および間欠受信）が正常に行われないことがある。しかしながら、上述のように、本実施の形態では、携帯型端末６１１が間欠送信を行うことを受信側装置６０３に通知して、受信側装置６０３による間欠受信を停止させることにより、携帯型端末６１１による受信側装置６０３に対する間欠送信を正常に行うことができる。このような間欠送信の通知の他、携帯型端末６１１は、実施の形態１と同様に、データパケット（送信データ）の帯域（送信帯域）が間欠送信パラメータ管理テーブルに設定されている帯域ＢＷまで達し、その帯域でのデータパケットの送信が所定の回数以上継続されるように、データパケットの送信を繰り返し行う。その後、携帯型端末６１１の抑制再開制御部６２４は、データパケット通常送信抑制要求を通信制御部６２７に送信する。その結果、通信制御部６２７は、抑制再開制御部６２４からデータパケット通常送信抑制要求を受けると、以後、ＡＣＫパケットの受信を続けるものの、その受信時にデータパケットを送信しないようにする。

次に、本実施の形態における定常状態の処理について説明する。

図２６は、本実施の形態における携帯型端末６１１と受信側装置６０３の定常状態での動作を示すシーケンス図である。

定常状態での１サイクル分の動作は、送信再開処理と、送信抑制期間の開始処理と、送信抑制期間の終了処理との３つのステップに分けられる。

送信再開処理（ステップ１）では、抑制再開制御部６２４は、受信側装置６０３への指定サイズのデータ送信を行うために、通信制御部６２７に対して指定サイズデータ送信要求を発行する。このとき、抑制再開制御部６２４は、間欠送信パラメータ管理テーブルに格納されたサイクルデータサイズＤｃを、サイクル間隔Ｔｃの間に送信すべきデータサイズ（指定サイズ）とし、そのサイクルデータサイズＤｃ分のデータを送信するように通信制御部６２７に要求する。通信制御部６２７は、時刻Ｔ８１に、指定サイズデータ送信要求を受け取ると、サイクルデータサイズＤｃ分のデータパケットＰ１を通信Ｉ／Ｆ部１０８を介して送信する。

送信抑制期間の開始処理（ステップ２）では、抑制再開制御部６２４は、時刻Ｔ８１以降、通信制御部６２７で受信されるＴＣＰパケットをモニタリングしながら、通信制御部６２７からそれまでに送信された最後のデータパケットの情報、すなわち、シーケンス番号（ＬＡＳＴ＿ＳＥＱ）と送信したデータサイズ（ＬＡＳＴ＿ＳＩＺＥ）とを保持しておく。

そして、抑制再開制御部６２４は、時刻Ｔ８１以降で送信したデータサイズがサイクルデータサイズＤｃに到達し、最後のデータパケットに対するＡＣＫパケットを受信したかどうか、を確認し続ける。具体的には、抑制再開制御部６２４は、ＡＣＫパケットＰ２が受信されるごとに、その受信されたＡＣＫパケットＰ２のＡＣＫ番号を参照し、そのＡＣＫ番号が（ＬＡＳＴ＿ＳＥＱ＋ＬＡＳＴ＿ＳＩＺＥ）であるか否かを確認する。

このとき、送信されたデータパケットに対するＡＣＫパケットが全て携帯型端末６１１に到達しない場合がある。具体的には、次の原因が考えられる。

（１）受信側装置６０３がＤＥＬＡＹＥＤ ＡＣＫアルゴリズムを実装している場合、受信側装置６０３はデータパケット１つに対して１つのＡＣＫパケットを送信するのではなく、複数個のデータパケットに対し、１つのＡＣＫパケットを送信する。

（２）伝送路上や、受信側端末６０３上、携帯型端末６１１上で、パケットロスが発生する。

そこで、携帯型端末６１１は、ＲＴＴを推定するＲＴＴ推定部を備え、送信したデータパケットに対する全てのＡＣＫパケットを受信しない場合、最後のデータパケットを送信した後からＲＴＴ間だけＡＣＫパケットを待ち受けてもよい。携帯型端末６１１は、このＲＴＴ間に全てのＡＣＫパケットを受信しなければ、ＡＣＫパケットの待ち受けを終了し、受信していないＡＣＫパケットに対応するデータパケットを、次のサイクルにおけるデータ送信の最初に再送する。

また、携帯型端末６１１は、ＲＴＴ間だけＡＣＫパケットを待ち受け、全てのＡＣＫパケットを受信しない場合は、パケットロスが発生している可能性もあるため、受信していないＡＣＫパケットに対応するデータパケット、もしくは、最後に送信したデータパケットを再送信し、再度ＡＣＫパケットを待ってもよい。

また、受信側装置６０３のＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲを解除するパケット数が既知であれば、携帯型端末６１１は、データパケットの数がＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲ解除のパケット数の整数倍となるように、データパケットの分割を行ってもよい。一方、ＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲを解除するパケット数が既知でなければ、携帯型端末６１１は、あらかじめ、通信中にＤＥＬＡＹＥＤ ＡＣＫ ＴＩＭＥＲ解除のパケット数をＡＣＫパケットの受信タイミングから推定しておいてもよい。

時刻Ｔ８１以降で送信したデータパケットに対する全てのＡＣＫパケットが到達したとき、もしくは、これ以上到達しないと判断したときである時刻Ｔ８２で、抑制再開制御部６２４は、送信抑制期間が開始したとみなし、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。

送信抑制期間の終了処理（ステップ３）では、本発明の実施形態における携帯型端末６１１は、時刻Ｔ８１を起点として、サイクル間隔Ｔｃの時間経過後の時刻Ｔ８３を、送信抑制期間の終了点と見なす。つまり、抑制再開制御部６２４は、タイマにより時刻Ｔ８３を検出し、電源制御部１０６に投入要求を発行する。その投入要求により、電源制御部１０６は時刻Ｔ８３に通信Ｉ／Ｆ部１０８の電源を投入する。

携帯型端末６１１は、定常状態では、上記３つのステップを１サイクルとして、繰り返し実行する。

通信アプリケーションプログラムを終了する場合の処理では、携帯型端末６１１は、実施の形態１と同様に、受信側装置６０３とのＴＣＰのコネクションを切断する。さらに、携帯型端末６１１のアプリ要求取得部６２２およびパラメータ決定部６２３はそれぞれ、性能パラメータ管理テーブルの内容と、間欠送信パラメータ管理テーブルの内容とをクリアする。さらに、抑制再開制御部６２４は、通信制御部６２７で送受信されるＴＣＰパケットのモニタリングを停止し、電源制御部１０６に対して通信Ｉ／Ｆ部１０８の電源を切断させる。

以上の処理により、携帯型端末６１１の状態は初期状態に戻る。

次に、上記の間欠送信処理のための、携帯型端末６１１内の処理について、フローチャートを用いて説明する。

図２７は、本実施の形態における携帯型端末６１１の定常状態の動作を示すフローチャートである。

まず、本実施の形態の携帯型端末６１１は、前のサイクルにおいて、受信していないＡＣＫパケットに対応するデータパケットが通信制御部６２７に保持されていたら、サイクルデータサイズＤｃ分のデータパケットの送信に先立ち、その保持されているデータパケットを既存のＴＣＰプロトコルに従って送信する（ステップＳ５０１）。このとき、携帯型端末６１１の抑制再開制御部６２４は、通信Ｉ／Ｆ部１０８への電源投入のタイミングを特定するため、タイマによる計時を開始する。

次に、携帯型端末６１１は、今回のサイクルで送信すべきサイクルデータサイズＤｃ分のデータパケットを送信する（ステップＳ５０２）。このとき、上述の送信抑制期間の開始処理（ステップ２）で説明したように、携帯型端末６１１は、最後のデータパケットを送信後、送信したデータパケットに対応する全てのＡＣＫパケットをＲＴＴ間だけ待ち受ける。このＲＴＴ間に全てのＡＣＫパケットを受信しなければ、携帯型端末６１１は、その全てのＡＣＫパケットを受信しないまま、データパケットの送信を完了する。なお、ＴＣＰなので、最後のデータパケットは通信制御部１０７に保持されており、次回のサイクルの最初（ステップＳ５０１）で送信される。

携帯型端末６１１は、サイクルデータサイズＤｃ分のデータパケットの送信が完了した後、通信Ｉ／Ｆ部１０８の電源を切断する（ステップＳ５０３）。携帯型端末６１１は、通信Ｉ／Ｆ部１０８の電源を切断すると、上述のタイマに基づいて、ステップＳ５０２でのデータパケットの送信開始時からサイクル間隔Ｔｃが経過したか否かを判別する（ステップＳ５０４）。ここで、携帯型端末６１１は、サイクル間隔Ｔｃが経過していないと判別したときには（ステップＳ５０４のＮｏ）、ステップＳ５０３からの処理を繰り返し、サイクル間隔Ｔｃが経過したと判別したときには（ステップＳ５０４のＹｅｓ）、通信Ｉ／Ｆ部１０８の電源を投入する（ステップＳ５０５）。

なお、本実施の形態では、ステップＳ５０３およびＳ５０４において、定期的にサイクル間隔Ｔｃの経過を確認しているが、定期的な確認を行わず、サイクル間隔Ｔｃが経過したときに、割り込みを発生させて、サイクル間隔Ｔｃの経過を検知してもよい。

最後に、携帯型端末６１１は、送信すべきアプリケーションデータ（データパケット）の送信を完了し、受信側装置６０３との通信を終了すべきか否かを判別し（ステップＳ５０６）、終了すべきと判別したときには（ステップＳ５０６のＹｅｓ）、全ての処理を終了する。また、携帯型端末６１１は、終了すべきでなく、まだ送信すべきデータが存在すると判別したときには（ステップＳ５０６のＮｏ）、ステップＳ５０１からの処理を繰り返し実行する。このようなステップＳ５０１〜Ｓ５０６の処理によって、間欠送信を行いながら通信が実行される。

以上のように、本実施の形態に係る携帯型端末６１１は、無線ＬＡＮの省電力方法に依存せず、例えばＴＣＰなどのフロー制御機構を持つプロトコルを使って、受信側装置６０３との間で通信を行いながら省電力化を行なう。そのため、本実施の形態では、アクセスポイントでの省電力機能のサポート状況やネットワークデバイスの種類にも関係なく、携帯型端末６１１の省電力化を図ることができる。また、携帯型端末６１１（送信側装置）から間欠送信を行うことが受信側装置６０３に通知されることにより、受信側装置６０３の間欠受信処理を抑えることができ、より確実に省電力化を図ることができる。

なお、本実施の形態では、送信抑制期間においてのみ、電源を切断したが、省電力効果をさらに向上するために、１サイクル内のデータパケットの送信後からＡＣＫパケットの受信までの期間も電源を切断してもよい。

図２８は、本実施の形態に係る携帯型端末６１１と受信側装置６０３の他の省電力方法を示すシーケンス図である。

携帯型端末６１１は、実施の形態２の携帯型端末２１１ａと同様に、サイクルの最初のデータパケット送信後、そのデータパケットに対応するＡＣＫパケットを受信するまでのＲＴＴ間のうち、一部の期間において通信Ｉ／Ｆ部１０８の電源を切断する。

具体的には、携帯型端末６１１は、サイクル間隔Ｔｃの間にサイクルデータサイズ分のデータパケットを送信しなければならないので、１サイクルの全てのデータパケットを送信した直後（図２８の時刻Ｔ９２）から、最初のＡＣＫパケットが到達する直前（図２８の時刻Ｔ９３）までの期間において通信Ｉ／Ｆ部１０８の電源を切断する。ただし、受信側装置６０３から受信しているＲＷＩＮがサイクルデータサイズＤｃよりも小さい場合は、携帯型端末６１１は、受信したＲＷＩＮに応じたデータサイズ分のデータパケットを送信した後に電源を切断する。

また、本実施の形態では、サイクルデータサイズＤｃおよびサイクル間隔Ｔｃを固定させたが、送信するデータサイズに応じて動的に変更してもよい。また、本実施の形態では、各サイクルの間隔をあけずに、各サイクルを連続させたが、各サイクルの間を空けてもよい。例えば、携帯型端末６１１は、サイクルデータサイズＤｃ分のデータの送信準備がサイクル開始時点でできていない場合などでは、サイクルデータサイズＤｃ分の送信すべきデータが準備されるまで、次のサイクルを開始せず、電源切断を行ってもよい。これにより、まとめてデータを送信することにより、ＴＣＰの往復回数を減らすことで、より省電力効果を得ることができる。

また、本実施の形態では、携帯型端末６１１（送信側装置）が、間欠送信を通知したが、必ずしも通知する必要はない。また、携帯型端末６１１（送信側装置）が、間欠送信を通知することなく、逆に、受信側装置６０３が、間欠受信を携帯型端末６１１に通知してもよい。また、携帯型端末６１１（送信側装置）と受信側装置６０３との間でネゴシエーションを実施することにより、間欠受信および間欠送信のうち何れを実行するかを決定してもよい。この場合、両装置が間欠送受信有効フラグに省電力効果に関する情報を含めることで、間欠受信および間欠送信のうち、省電力効果の高い方が実施される。また、本実施の形態では、間欠送信の実施を通知するタイミングを、３ＷＡＹハンドシェイクとしたが、そのタイミングは、間欠送信の準備状態などのように、間欠送信を実施する前であれば何れのタイミングであってもよい。

（実施の形態６）
本発明の実施の形態６に係る通信装置について説明する。実施の形態１から実施の形態５では、携帯型端末において動作する通信アプリケーションプログラムは１つだけであったが、本実施の形態では、複数の通信アプリケーションプログラムが同時に動作する。複数の通信アプリケーションプログラムが同時に動作した場合でも、複数の通信アプリケーションプログラムの送信処理および受信処理を同期することにより、送信抑制期間を発生させ、省電力効果を得ることができる。本実施の形態では、簡単のために２つの通信アプリケーションプログラムが同時に動作した場合について説明を行う。

図２９は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型端末１００１，１００２と、ＵＤＰ（User Datagram Protocol）などのようにフロー制御を行わない通信を行う送信側装置２０３ａと、フロー制御付の通信を行う機能を持つ送信側装置２０３と、受信側装置６０３とを備える。

なお、本実施の形態において、実施の形態１〜５と同様の機器および構成については、同一の参照符号を付して説明を省略する。

本実施の形態における携帯型端末１００１は、実施の形態２の携帯型端末２１１ａの受信側装置としての機能と、実施の形態５の携帯型端末６１１の送信側装置としての機能とを兼ね備え、２つの通信アプリケーションプログラムを同時に実行する。つまり、本実施の形態における携帯型端末１００１は、送信側装置２０３，２０３ａから送信されるデータパケットを同時に受信したり、送信側装置２０３から送信されるデータパケットの受信と、受信側装置６０３へのデータパケットの送信とを同時に実行したりする。

また、本実施の形態における携帯型端末１００１は、実施の形態１〜５と同様にＴＣＰに従った通信を行うとともに、ＵＤＰに従った通信を行う。したがって、携帯型端末１００１は、送信側装置２０３または受信側装置６０３と通信するときには、ＴＣＰに従ったデータの受信または送信を行い、送信側装置２０３ａと通信するときには、ＵＤＰに従い、送信側装置２０３ａから一定間隔ごとに送信されるデータを受信する。

なお、本実施の形態では、携帯型端末１００１により実行される間欠受信および間欠送信を総称して、間欠送受信と呼び、携帯型端末１００１により扱われる間欠受信パラメータおよび間欠送信パラメータを総称して、間欠送受信パラメータと呼ぶ。また、携帯型端末１００１，１００２はそれぞれ同一の機能と構成を有するため、携帯型端末１００１のみについて以下に説明する。

図３０は、本実施の形態における携帯型端末１００１の具体的な構成を示す構成図である。

本実施の形態における携帯型端末１００１は、通信アプリケーション部１０１１と、アプリ要求取得部１０１２と、パラメータ決定部１０１３と、抑制再開制御部１０１４と、電源制御部１０６と、通信制御部１０２７と、通信Ｉ／Ｆ部１０８と、ＲＴＴ推定部１０１９とを備える。

通信アプリケーション部１０１１は、実施の形態２の通信アプリケーション部１０１の機能と、実施の形態５の通信アプリケーション部６２１の機能とを兼ね備え、データを送信するための通信アプリケーションプログラムと、データを受信するための通信アプリケーションプログラムとを同時に実行したり、データを送信または受信するための２つの通信アプリケーションプログラムを同時に実行したりする。つまり、通信アプリケーション部１０１１は、アプリ要求取得部１０１２に起動通知を発行して、送信側装置２０３ａ、送信側装置２０３および受信側装置６０３ａのうち何れか２つの装置との間でデータの送受信を行う。

アプリ要求取得部１０１２は、実施の形態２のアプリ要求取得部１０２の機能と、実施の形態５のアプリ要求取得部６２２の機能とを兼ね備え、通信アプリケーション部１０１１から、性能パラメータを入手し、パラメータ決定部１０１３に対して、性能パラメータ登録通知または性能パラメータ削除通知を発行する。また、アプリ要求取得部１０１２によって入手される性能パラメータには、後述する「プロトコル」や「省電力優先度」が示されている。

抑制再開制御部１０１４は、実施の形態２の抑制再開制御部８０４の機能と、実施の形態５の抑制再開制御部６２４の機能とを兼ね備える。さらに、抑制再開制御部１０１４は、複数の通信アプリケーションプログラムの間欠送受信パラメータに従って、各通信アプリケーションプログラムによる間欠送受信の同期をとる。つまり、抑制再開制御部１０１４は、各通信アプリケーションプログラムにおける通信の抑制および再開を同時に行い、抑制時には、電源制御部１０６に対して通信Ｉ／Ｆ部１０８の電源を切断させる。通信の抑制および再開のタイミングについては後述する。さらに、本実施の形態の携帯型端末１００１は、ＵＤＰを用いてデータの受信を行う場合は、ＵＤＰパケットの受信間隔を特定し、その受信間隔に基づいて、ＵＤＰパケットの受信予想時刻を推定する。

ＲＴＴ推定部１０１９は、実施の形態２のＲＴＴ推定部８０９と同様に、各通信アプリケーションプログラムのＲＴＴを推定し、推定したＲＴＴをパラメータ決定部１０１３、抑制再開制御部１０１４および通信制御部１０２７に通知する。

パラメータ決定部１０１３は、実施の形態２のパラメータ決定部１０３の機能と、実施の形態５のパラメータ決定部６２３の機能とを兼ね備え、上述の間欠送受信パラメータを決定し、抑制再開制御部１０１４に間欠送受信パラメータ登録通知（間欠受信パラメータ登録通知または間欠送信パラメータ登録通知）または間欠送受信パラメータ削除通知（間欠受信パラメータ削除通知または間欠送信パラメータ削除通知）を送信する。

通信制御部１０２７は、実施の形態２の通信制御部１０７の機能と、実施の形態５の通信制御部６２７の機能とを兼ね備えるとともに、通信Ｉ／Ｆ部１０８を介して、送信側装置２０３ａからＵＤＰに従ったデータパケットの受信を行う。

図３１Ａおよび図３１Ｂは、アプリ要求取得部１０１２が管理するＵＤＰに関する性能パラメータ管理テーブルを示す図である。

性能パラメータ管理テーブル１０１２ａ，１０１２ｂはそれぞれ、ＵＤＰにより通信を行う起動済みの通信アプリケーションプログラムに対する性能パラメータを有する。その性能パラメータとしてはプロトコルや送信間隔がある。

プロトコルは、例えば「ＵＤＰ固定レート受信」や「ＵＤＰ可変レート送信」などのように、ＵＤＰ固定レートまたはＵＤＰ可変レートと、送信または受信との組み合わせにより規定されるパラメータである。送信間隔ＤＴは、ＵＤＰにより断続的に送信されるデータパケットの時間間隔を示すパラメータであり、プロトコルがＵＤＰ固定レートを示す場合に、性能パラメータ管理テーブルに設定され、プロトコルがＵＤＰ可変レートを示す場合には設定されない。

図３２Ａおよび図３２Ｂは、アプリ要求取得部１０１２が管理するＴＣＰに関する性能パラメータ管理テーブルを示す図である。

性能パラメータ管理テーブル１０１２ｃ，１０１２ｄはそれぞれ、ＴＣＰにより通信を行う起動済みの通信アプリケーションプログラムに対する性能パラメータを有する。その性能パラメータとしては、プロトコルや、省電力優先度、ストリームタイプ、帯域、遅延時間がある。なお、ストリームタイプ、帯域および遅延時間のパラメータは、図６Ａ、図６Ｂおよび図６Ｃに示すパラメータと同じである。

プロトコルは、例えば「ＴＣＰ送信」や「ＴＣＰ受信」などを示すパラメータである。省電力優先度は、間欠送受信のサイクルの基準となる通信アプリケーションプログラムを決定するためのパラメータである。

携帯型端末１００１のパラメータ決定部１０１３は、起動済みの２つの通信アプリケーションプログラムのそれぞれの性能パラメータ管理テーブルにより示されるプロトコルや省電力優先度などに基づいて、その２つの通信アプリケーションプログラムのうち、何れか一方をサイクル基準アプリケーションに決定する。つまり、パラメータ決定部１０１３は、そのサイクル基準アプリケーションによる間欠送受信のサイクルを基準（基準サイクル）とし、他方の通信アプリケーションプログラムによる間欠送受信のサイクルがその基準サイクルに同期するように、その他方の間欠送受信パラメータを決定する。

例えば、ＴＣＰにより通信を行う起動済みの２つの通信アプリケーションプログラムが起動している場合には、パラメータ決定部１０１３は、その２つの通信アプリケーションプログラムの性能パラメータ管理テーブルに示される省電力優先度を比較する。そして、パラメータ決定部１０１３は、省電力優先度の高い通信アプリケーションプログラムをサイクル基準アプリケーションに決定する。

また、パラメータ決定部１０１３は、起動済みの２つの通信アプリケーションプログラムの性能パラメータ管理テーブルに示されるプロトコルを比較し、一方のプロトコルがＴＣＰを示し他方のプロトコルがＵＤＰを示す場合には、ＵＤＰの通信アプリケーションプログラムをサイクル基準アプリケーションに決定する。プロトコルがＵＤＰの通信アプリケーションプログラムは再送制御を実施しないことから、間欠送受信の非給電状態でのパケットロスを極力避けなければならない。したがって、パラメータ決定部１０１３は、ＵＤＰの通信アプリケーションプログラムを優先的にサイクル基準アプリケーションに決定する。

なお、性能パラメータ管理テーブルに省電力優先度が設定されていない場合や、互いの性能パラメータ管理テーブルに示される省電力優先度が同じレベルである場合には、パラメータ決定部１０１３は、ＲＴＴ推定部１０１９から通知されたＲＴＴや、通信アプリケーションプログラムもしくはユーザによる指定に応じてサイクル基準アプリケーションを決定してもよい。

また、サイクル基準アプリケーションとならなかった通信アプリケーションプログラムは、サイクル基準アプリケーションと連動して動作することになる。そのため、パラメータ決定部１０１３は、サイクル基準アプリケーションとならなかった通信アプリケーションプログラムの間欠送受信パラメータを決定するときには、サイクルデータサイズＤｃｔを増やすなどして間欠送受信パラメータを調整し、通信アプリケーションプログラムからの要求が満たされるような間欠送受信パラメータを決定する。

パラメータ決定部１０１３は、ＴＣＰにより通信を行うサイクル基準アプリケーションの間欠受信パラメータを決定するときには、実施の形態１と同様に、間欠受信パラメータであるサイクル間隔ＴｃｔとサイクルデータサイズＤｃｔを決定する。また、パラメータ決定部１０１３は、ＵＤＰにより通信を行うサイクル基準アプリケーションの性能パラメータ管理テーブルに示される送信間隔ＤＴを、ＵＤＰにより送信されたパケットを受信する受信間隔や、ＵＤＰによりパケットを送信する送信間隔として用いる。

ここで、間欠送受信パラメータの決定方法について、以下詳細に説明する。

まず、通信アプリケーション部１０１１が２つの通信アプリケーションプログラムを起動し、一方の通信アプリケーションプログラムがＵＤＰの送受信を行い、もう一方の通信アプリケーションプログラムがＴＣＰの送受信を行う場合について説明する。

ＵＤＰの通信では、プロトコルによる再送制御が実施されないため、電源切断中にパケットを受信し、ロスすることは避けるべきである。また、ＶｏＩＰなどの送信では、パケット送信遅延により音声が乱れるなどの現象が発生するため、パケット送信遅延に対する制約が厳しい。そこでまず、携帯型端末１００１は、ＵＤＰとＴＣＰの通信の両方を行う場合、ＵＤＰの送受信を実行しようとする通信アプリケーションプログラムをサイクル基準アプリケーションとし、ＵＤＰパケットの送信間隔を守ることにより、パケットの送受信遅延に関する制約を守る。

パラメータ決定部１０１３は、ＵＤＰにより通信を行う通信アプリケーションプログラムをサイクル基準アプリケーションに決定し、そのサイクル基準アプリケーションの性能パラメータ管理テーブルに示される送信間隔ＤＴ＝ＤＴｕを特定する。そして、パラメータ決定部１０１３は、その送信間隔に基づいて、ＴＣＰにより通信を行う通信アプリケーションプログラムのサイクル間隔Ｔｃｔを決定する。

次に、パラメータ決定部１０１３は、ＴＣＰにより通信を行う通信アプリケーションプログラムのサイクルデータサイズを、その通信アプリケーションプログラムの性能パラメータ管理テーブルに示される帯域ＢＷに基づいて決定する。このとき、パラメータ決定部１０１３は、サイクル基準アプリケーションによるＵＤＰ通信の送信間隔ＤＴｕに、ＴＣＰの通信のサイクル間隔Ｔｃｔ（サイクル間隔Ｔｃｔの整数倍）を合わせて両通信の同期が取られている状態において、必要とされるサイクルデータサイズを決定する。

具体的に、ＴＣＰの性能パラメータ管理テーブルに示されるストリームタイプが帯域重視型である場合は、両通信の同期を取るために、パラメータ決定部１０１３は、ＴＣＰの通信のサイクル間隔ＴｃｔをＴｃｔ＝ＤＴｕに決定する。次に、実施の形態１と同様に、パラメータ決定部１０１３は、Ｄｃｔ＝Ｔｃｔ×ＢＷに従い、１回のサイクルにおいて送受信するデータサイズである、サイクルデータサイズＤｃｔを決定し、要求された帯域ＢＷを確保する。

一方、ＴＣＰの性能パラメータ管理テーブルに示されるストリームタイプが遅延時間重視型である場合は、まず、パラメータ決定部１０１３は、ＵＤＰの送信間隔ＤＴｕとＴＣＰの遅延時間ＤＴｔを比較する。ＵＤＰの送信間隔ＤＴｕよりも、ＴＣＰの遅延時間ＤＴｔのほうが長ければ、パラメータ決定部１０１３は、サイクル間隔ＴｃｔをＴｃｔ＝ＤＴｕに決定し、サイクルデータサイズＤｃｔをＤｃｔ＝Ｔｃｔ×ＢＷに決定する。逆に、ＴＣＰの遅延時間ＤＴｔの方が短ければ、ＤＴｕ＞Ｃ３×ＤＴｔとなるような整数Ｃ３を決定する。この場合、パラメータ決定部１０１３は、サイクル間隔ＴｃｔをＴｃｔ＝ＤＴｕ／Ｃ３に決定することで、ＵＤＰの送信間隔内に、ＴＣＰの送受信をＣ３回実行し、要求された遅延時間ＤＴｔを守る。そして、パラメータ決定部１０１３は、帯域重視型と同様に、Ｄｃｔ＝Ｔｃｔ×ＢＷにより、サイクルデータサイズＤｃｔを決定する。

なお、ＴＣＰの性能パラメータ管理テーブルに示されるストリームタイプがベストエフォート型の場合は、パラメータ決定部１０１３は、実施の形態１と同様に、間欠送受信パラメータを決定せず、携帯型端末１００１は間欠送受信を行わない。

次に、通信アプリケーション部１０１１が２つの通信アプリケーションプログラムを起動し、両方の通信アプリケーションプログラムがＴＣＰの送受信を行う場合について説明する。２つのＴＣＰの通信を動作させる場合は、パラメータ決定部１０１３は、各通信のためのサイクル間隔ＴｃｔとサイクルデータサイズＤｃｔを決定しなければならない。

ここでは、サイクル基準アプリケーションによる通信のサイクル間隔ＴｃｔをＴｃ１とし、その通信のサイクルデータサイズＤｃｔをＤｃ１とする。また、もう一方の通信アプリケーションプログラムによる通信のサイクル間隔ＴｃｔをＴｃ２とし、その通信のサイクルデータサイズＤｃｔをＤｃ２とする。

両方の通信がＴＣＰの送受信の場合、まず、パラメータ決定部１０１３は、各通信アプリケーションプログラムの性能パラメータ管理テーブルに示される省電力優先度を確認し、優先度の高い通信アプリケーションプログラムをサイクル基準アプリケーションに決定する。そして、パラメータ決定部１０１３は、サイクル基準アプリケーションのサイクル間隔Ｔｃ１とサイクルデータサイズＤｃ１とを、実施の形態１または実施の形態５と同様の方法で決定する。

次に、パラメータ決定部１０１３は、もう一方の通信アプリケーションプログラムについて、サイクルデータサイズＤｃ２とサイクル間隔Ｔｃ２とを決定する。この決定方法では、パラメータ決定部１０１３は、上述のＵＤＰの通信とＴＣＰの通信を同時に行う場合における決定方法において、ＵＤＰの送信間隔ＤＴｕをサイクル基準アプリケーションのサイクル間隔Ｔｃ１に置き換えて計算することより、サイクル間隔Ｔｃ２とサイクルデータサイズＤｃ２とを決定する。

図３３は、本実施の形態に係る携帯型端末１００１と送信側装置２０３ａおよび送信側装置２０３との省電力方法を示すシーケンス図である。

例えば、携帯型端末１００１は、図３１Ａに示す性能パラメータ管理テーブル１０１２ａに対応する通信アプリケーションプログラムにより、ＵＤＰに従って送信側装置２０３ａからデータを受信しながら、図３２Ｂに示す性能パラメータ管理テーブル１０１２ｄに対応する通信アプリケーションプログラムにより、ＴＣＰに従って送信側装置２０３からデータを受信する。なお、送信側装置２０３ａがＵＤＰパケットを送信する送信間隔をＤＴｕとし、送信側装置２０３ｂとの通信におけるサイクル間隔をＴｃｔとし、サイクルデータサイズをＤｃｔとし、ＲＴＴをＲＴＴｔとする。また、送信側装置２０３ａとの通信は、ＵＤＰを用いて行うので、上述の通り、ＵＤＰを用いた通信アプリケーションプログラムをサイクル基準アプリケーションとし、ＵＤＰの送信間隔ＤＴｕはＤＴｕ＝サイクル間隔Ｔｃｔとなる。そして、携帯型端末１００１は、送信間隔ＤＴｕの間隔でＵＤＰパケットを受信すること、つまりＵＤＰパケットを受信する時刻（受信予測時刻）を予測する。

本シーケンスでは、最初に、携帯型端末１００１は、間欠受信の初期状態において、送信側装置２０３ａおよび送信側装置２０３と通信するために、パラメータ決定部１０１３により、上記で説明した方法で間欠受信パラメータを決定する。

次に、携帯型端末１００１は、間欠受信の準備状態の処理を行う。このとき、携帯型端末１００１は、ＴＣＰを用いて送信側装置２０３と通信するために、実施の形態１と同様の方法により準備状態の処理を実施する。それに加えて、携帯型端末１００１のＲＴＴ推定部１０１９は、ＴＣＰの通信のＲＴＴであるＲＴＴｔを推定しておく。なお、携帯型端末１００１は、ＵＤＰを用いて送信側装置２０３ａと通信するときには、固定レートでパケット送受信を行うため、そのＵＤＰの通信のための準備状態の処理を行わない。

また、携帯型端末１００１の抑制再開制御部１０１４は、準備状態の処理が完了すると、サイクル基準アプリケーションによるＵＤＰパケットの受信のタイミングに同期してＴＣＰの通信アプリケーションプログラムによる通信が開始できるように、通信制御部１０２７によるＡＣＫパケットの送信を停止させて、送信側装置２０３ａとの通信を抑制しておく。

その後の定常状態では、抑制再開制御部１０１４は、時刻Ｔ１０１にサイクル間隔Ｔｃｔのタイマによる計時を開始し、送信側装置２０３からのデータ送信を再開させるため、通信制御部１０２７に対してＡＣＫ単発送信要求を発行する。したがって、携帯型端末１００１は、送信側装置２０３にＡＣＫパケットＰａ１を送信することで、間欠受信を開始する。ここで、開始するタイミング、つまりＡＣＫパケットＰａ１を送信するタイミング（時刻Ｔ１０１）は、送信側装置２０３ａからのＵＤＰパケットＰｕ１の受信予測時刻と、送信側装置２０３からのＴＣＰパケットＰｄ１の受信予測時刻とがちょうど一致するように調整されている。なお、ＴＣＰパケットＰｄ１は、送信側装置２０３から送信されるサイクルデータサイズＤｃｔ分のパケット全てを含む。

つまり、抑制再開制御部１０１４は、送信側装置２０３ａからのＵＤＰパケットＰｕ１の受信予測時刻を予測し、その受信予測時刻からＲＴＴｔ分さかのぼったタイミング（時刻Ｔ１０１）で、ＡＣＫ単発送信要求を発行して、ＡＣＫパケットＰａ１を送信させる。抑制再開制御部１０１４は、ＡＣＫパケットＰａ１の送信が完了した時刻Ｔ１０２に、電源制御部１０６に対して切断要求を発行する。電源制御部１０６は切断要求を受けると、通信Ｉ／Ｆ部１０８の電源を切断する。そして、ＡＣＫパケットＰａ１送信完了後の時刻Ｔ１０２からＲＴＴｔ経過する時刻Ｔ１０３まで、送信側装置２０３ａおよび送信側装置２０３のいずれからもパケットを受信することがないため、抑制再開制御部１０１４は、通信Ｉ／Ｆ部１０８の電源を切断させておく。

次に、抑制再開制御部１０１４は、時刻Ｔ１０２からＲＴＴｔ経過したときの時刻Ｔ１０３に、送信側装置２０３ａおよび送信側装置２０３からパケットが到達するため、電源制御部１０６に対して投入要求を発行する。その投入要求により、電源制御部１０６は時刻Ｔ１０３に通信Ｉ／Ｆ部１０８の電源を投入する。そして、受信すべき全てのパケットを受信した後の時刻Ｔ１０４と、サイクルの開始時刻Ｔ１０１からサイクル間隔Ｔｃｔ経過した時刻Ｔ１０５との間にはパケットを送受信しないため、抑制再開制御部１０１４は、電源制御部１０６を制御することにより、その時刻Ｔ１０４から時刻Ｔ１０５まで、通信Ｉ／Ｆ部１０８の電源を切断させる。そして、携帯型端末１００１は、タイマによる計時の開始時刻Ｔ１０１からサイクル間隔Ｔｃｔが経過した時刻Ｔ１０５に、再度新しいサイクルを開始する。このように、送信側装置２０３ａのＵＤＰパケットの送信間隔ＤＴｕと、送信側装置２０３の通信のサイクル間隔Ｔｃｔとが同じであるため、この後も同期して間欠受信をすることが可能である。

このように本実施の形態における携帯型端末１００１では、複数の通信を並列に実行する場合にも、それらのタイミングを同期させることで、データを送受信しない期間を作り、その期間に通信Ｉ／Ｆ部１０８の電源を切断して、省電力効果の向上を図ることができる。

なお、サイクルデータサイズＤｃｔ分のＴＣＰパケットがサイクル間隔Ｔｃｔに受信されなかった場合には、携帯型端末１００１は、間欠受信を実施せず、ＴＣＰパケットを受信すると直ちにＡＣＫパケットを送信し、次のデータ（ＴＣＰパケット）を受信してもよい。この場合、サイクルデータサイズＤｃｔ分のＴＣＰパケットを受信できなかったサイクルの次のサイクルでは、携帯型端末１００１は、サイクルデータサイズＤｃｔに、前回のサイクルで受信できなかったデータのサイズを加算したサイズを、次のサイクルで必要となるサイクルデータサイズＤｃｔとし、次のサイクルを実行する。

また、図３３では、ＵＤＰを用いた受信とＴＣＰを用いた受信とを用いて、本実施の形態における携帯型端末１００１の省電力効果を説明したが、ＵＤＰを用いた受信とＴＣＰを用いた送信とを携帯型端末１００１が実行する場合でも、本実施の形態における携帯型端末１００１では、間欠送受信処理により省電力効果を向上させることが可能である。具体的には、本実施の形態で説明した例と同様に、携帯型端末１００１は、ＵＤＰを用いた受信に合わせて、データパケット（ＴＣＰパケット）の送信、もしくはデータパケット（ＴＣＰパケット）に対応するＡＣＫパケットの受信を実施する。例えば、ＵＤＰパケットの受信と、データパケットに対するＡＣＫパケットの受信とのタイミングを合わせる場合は、携帯型端末１００１は、図３３の時刻Ｔ１０１で、ＡＣＫパケットの送信の代わりに、サイクルデータサイズＤｃ分のデータパケットの送信を実施する。

また、図３３では、携帯型端末１００１は、送信側装置２０３との通信におけるサイクル間隔Ｔｃｔを送信間隔ＤＴｕと同じとすることで、両通信の同期をとっていたが、サイクル間隔Ｔｃｔを送信間隔ＤＴｕに等しくしなくても同期を取ることができる。この場合には、携帯型端末１００１は、ＵＤＰパケットの送信間隔ＤＴｕとは無関係にサイクル間隔Ｔｃｔを決定し、ＵＤＰパケットの受信予測時刻を推定し、各サイクル中の適切なタイミングにおいてＡＣＫ単発送信要求に基づくＡＣＫパケットを送信する。つまり、ＡＣＫパケットの送信時刻はサイクルの開始に依存せず、ＵＤＰパケットの受信予測時刻、ＲＴＴｔおよびサイクル間隔Ｔｃｔを用いることで、データの送受信のタイミングの同期を取ることができる。

図３４は、サイクル間隔Ｔｃｔと送信間隔ＤＴｕとが異なる場合に抑制再開制御部１０１４がデータの送受信のタイミングの同期を取るための動作を示すフローチャートである。

最初に、抑制再開制御部１０１４は、サイクルの開始時刻において、そのサイクルのサイクル間隔Ｔｃｔ内にＵＤＰパケットを受信するか否か、つまりＵＤＰパケットの受信予測時刻（以下、ＵＤＰ受信予測時刻という）が存在するか否かを判定する（ステップＳ６０１）。具体的には、抑制再開制御部１０１４は、（ＵＤＰ受信予測時刻−サイクルの開始時刻）がサイクル間隔Ｔｃｔよりも小さいか否かを判定する。

ここで、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻がサイクル間隔Ｔｃｔ内に存在しない（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞サイクル間隔Ｔｃｔ）と判定すると（ステップＳ６０１のＮｏ）、同期処理を行うことなく、サイクルの開始時刻にＡＣＫパケットを送信させる（ステップＳ６０５）。つまり、抑制再開制御部１０１４は、サイクルを開始すると同時に、実施の形態１と同様の方法により間欠受信制御を行う。

一方、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻がサイクル間隔Ｔｃｔ内に存在する（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＜サイクル間隔Ｔｃｔ）と判定すると（ステップＳ６０１のＹｅｓ）、さらに、ＵＤＰ受信予測時刻にＴＣＰパケット（データパケット）を受信できるか否かを判定する（ステップＳ６０２）。つまり、抑制再開制御部１０１４は、ＵＤＰパケットの受信と、ＡＣＫパケットの送信もしくはＴＣＰパケットの受信との同期を取るために、（ＵＤＰ受信予測時刻−サイクルの開始時刻）とＲＴＴｔとを比較する。抑制再開制御部１０１４は、（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞ＲＴＴｔであれば、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できると判定し、（ＵＤＰ受信予測時刻−サイクルの開始時刻）＜ＲＴＴｔであれば、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できないと判定する。

ここで、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できる（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞ＲＴＴｔ）と判定すると（ステップＳ６０２のＹｅｓ）、ＵＤＰパケットの受信とＴＣＰパケットの受信とを同期させる（ステップＳ６０３）。つまり、抑制再開制御部１０１４は、サイクルの開始時刻から｛（ＵＤＰ受信予測時刻−サイクルの開始時刻）−ＲＴＴｔ｝経過したタイミングで、ＡＣＫパケットを送信させる。

一方、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できない（（ＵＤＰ受信予測時刻−サイクルの開始時刻）＜ＲＴＴｔ）と判定すると（ステップＳ６０２のＮｏ）、ＵＤＰパケットの受信とＡＣＫパケットの送信とを同期させる（ステップＳ６０４）。つまり、抑制再開制御部１０１４は、ＵＤＰ受信予測時刻にＡＣＫパケットを送信させる。

そして、抑制再開制御部１０１４は、次のサイクルがあるか否かを判別し（ステップＳ６０６）、次のサイクルがないと判別したときには（ステップＳ６０６のＹｅｓ）、全ての処理を終了し、次のサイクルがあると判別したときには（ステップＳ６０６のＮｏ）、ステップＳ６０１からの処理を繰り返し実行する。

このようなサイクル間隔Ｔｃｔと送信間隔ＤＴｕとが異なるときの省電力方法について、図３５を用いてさらに詳細に説明する。

図３５は、本実施の形態に係る携帯型端末１００１と送信側装置２０３ａおよび送信側装置２０３との他の省電力方法を示すシーケンス図である。

携帯型端末１００１は、送信側装置２０３とのＴＣＰを用いた通信におけるサイクル間隔Ｔｃｔを決定するときには、送信側装置２０３ａとのＵＤＰを用いた通信における送信間隔ＤＴｕと異なるサイクル間隔Ｔｃｔを決定する。なお、図３５では、説明を簡単にするため、携帯型端末１００１がＡＣＫパケットの送信後ＲＴＴｔ経過まで電源を切断しないことを前提とする。

まず、携帯型端末１００１は、時刻Ｔ１１１に定常状態に達すると、上述したサイクル間隔Ｔｃｔと送信間隔ＤＴｕとが異なる場合の間欠受信制御に基づいて、ＡＣＫパケットの送信タイミングを決定する。携帯型端末１００１は、時刻Ｔ１１１から開始されるこのサイクルでは、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できる、つまり（ＵＤＰ受信予測時刻−サイクルの開始時刻）＞ＲＴＴｔが成り立つと判定する。その結果、携帯型端末１００１は、時刻Ｔ１１１にサイクルを開始し、その時刻から（ＵＤＰパケットＰｕ１の受信予測時刻−サイクルの開始時刻Ｔ１１１−ＲＴＴｔ）が経過するタイミングになるまで、通信Ｉ／Ｆ部１０８の電源を切断しておく。次に、時刻Ｔ１１２に（ＵＤＰパケットＰｕ１の受信予測時刻−サイクルの開始時刻Ｔ１１１−ＲＴＴｔ）のタイミングとなると、携帯型端末１００１は、ＡＣＫ単発送信要求に基づくＡＣＫパケットＰａ１を送信側装置２０３に送信する。そしてＲＴＴｔ経過後、携帯型端末１００１は、送信側装置２０３ａからＵＤＰパケットを受信し、送信側装置２０３からＴＣＰパケットを受信する。携帯型端末１００１は、時刻Ｔ１１３で、受信すべき全てのデータを受信すると、通信Ｉ／Ｆ部１０８の電源を切断し、サイクルの開始時刻Ｔ１１１からサイクル間隔Ｔｃｔ経過後の時刻Ｔ１１４まで、その電源を切断しておく。

次に、携帯型端末１００１は、次のサイクルを開始する時刻Ｔ１１４に、次のＵＤＰパケットＰｕ２の受信予測時刻がそのサイクル中に発生するか否かを判断する。発生しないと判断すると、携帯型端末１００１は、そのサイクルの開始時刻Ｔ１１４に、ＡＣＫパケットＰａ２を送信する。携帯型端末１００１は、時刻Ｔ１１５に、そのＡＣＫパケットＰａ２に対応する全てのＴＣＰパケットＰｄ２を受信すると、その後、サイクルの終了時刻Ｔ１１６まで通信Ｉ／Ｆ部１０８の電源を切断する。

さらに、携帯型端末１００１は、次のサイクルの開始時刻Ｔ１１６に、そのサイクルでは、ＵＤＰ受信予測時刻にＴＣＰパケットを受信できない、つまり（ＵＤＰ受信予測時刻−サイクルの開始時刻Ｔ１１６）＜ＲＴＴｔが成り立つと判定する。その結果、携帯型端末１００１はＵＤＰパケットＰｕ２を受信する時刻Ｔ１１７に、ＡＣＫパケットＰａ３を送信する。したがって、携帯型端末１００１は、時刻Ｔ１１６から時刻Ｔ１１７まで通信Ｉ／Ｆ部１０８の電源を切断しておく。

このように、サイクル間隔Ｔｃｔと送信間隔ＤＴｕが異なる場合も、ＵＤＰ受信予測時刻とサイクル間隔ＴｃｔとＲＴＴｔとを用いることで２つの通信の同期をとることができ、省電力効果を向上させることができる。

図３６は、本実施の形態に係る携帯型端末１００１と受信側装置６０３および送信側装置２０３との省電力方法を示すシーケンス図である。

携帯型端末１００１は、ＴＣＰを用いて受信側装置６０３にデータを送信しながら、ＴＣＰを用いて送信側装置２０３からデータを受信する。ここで、受信側装置６０３との通信におけるサイクル間隔をＴｃとし、サイクルデータサイズをＤｃａとし、ＲＴＴをＲＴＴａとする。また、送信側装置２０３との通信におけるサイクル間隔をＴｃとし、サイクルデータサイズをＤｃｂとし、ＲＴＴをＲＴＴｂとする。上記の説明の通り、サイクル間隔Ｔｃは、受信側装置６０３の通信と送信側装置２０３の通信とで、同一である。

また、携帯型端末１００１は、図３３の場合と同様に、サイクル基準アプリケーションのサイクルに合わせて、もう一方の通信のサイクル間隔ＴｃおよびサイクルデータサイズＤｃを決定することにより、サイクル間隔Ｔｃの同期をとり、送信抑制期間で通信Ｉ／Ｆ部１０８の電源を切断する。

最初に、携帯型端末１００１は、図３３と同様に初期状態において、受信側装置６０３および送信側装置２０３に対する間欠送受信パラメータを決定し、実施の形態２および実施の形態５と同様の準備状態の処理を実施し、間欠送受信可能な状態で各装置との通信を抑制しておく。ここで、本実施の形態では、受信側装置６０３との通信の省電力優先度が「高」であるものとする。よって、サイクル基準アプリケーションは、受信側装置６０３に対してＴＣＰを用いた送信処理を行う通信アプリケーションプログラムとなる。したがって、携帯型端末１００１は、送信側装置２０３に対する準備状態が完了すると、サイクル基準アプリケーションによる受信側装置６０３との通信と同期をとるため、送信側装置２０３の通信を抑制しておく。

そして、携帯型端末１００１は、受信側装置６０３および送信側装置２０３に対する準備状態の処理が完了すると、定常状態の処理を開始する。すなわち、携帯型端末１００１は、両通信のサイクル間隔Ｔｃの間にサイクルデータサイズ分のデータの送受信が完了すると、各装置に対する通信を抑制し、その通信が抑制された期間、通信Ｉ／Ｆ部１０８の電源を切断する。

具体的には、定常状態では、まず、携帯型端末１００１は、サイクル間隔Ｔｃの開始時刻Ｔ１２１に、受信側装置６０３に対してデータパケットＰｄａを送信すると同時に、送信側装置２０３にＡＣＫ単発送信要求に基づくＡＣＫパケットＰａｂを送信する。次に、携帯型端末１００１は、受信側装置６０３と送信側装置２０３とからパケットを受信するまで、それぞれＲＴＴだけ時間がかかるため、通信Ｉ／Ｆ部１０８の電源を切断する。具体的には、携帯型端末１００１は、受信側装置６０３に対してサイクル中に送信すべきデータパケットＰｄａが全て送信された時刻Ｔ１２２から、最初にデータパケットが到達する時刻Ｔ１２３まで、通信Ｉ／Ｆ部１０８の電源を切断する。なお、送信側装置２０３のＲＴＴｂの方が受信側装置６０３のＲＴＴａよりも短いため、最初に到達するデータパケットは、送信側装置２０３から送信されたデータパケットＰｄｂである。つまり、携帯型端末１００１は、受信側装置６０３のＲＴＴａの期間と、送信側装置２０３のＲＴＴｂの期間とが重なる期間（時刻Ｔ１２２〜時刻Ｔ１２３）に通信Ｉ／Ｆ部１０８の電源を切断する。

その後、携帯型端末１００１は、時刻Ｔ１２３に再度電源を投入し、送信したデータに対応するＡＣＫパケットＰａａを受信側装置６０３から受信するとともに、サイクルデータサイズＤｃｂ分のデータパケットＰｄｂを送信側装置２０３から受信する。その結果、時刻Ｔ１２５に、このサイクル間隔Ｔｃで受信側装置６０３および送信側装置２０３との間で行われるべき通信が全て完了するので、携帯型端末１００１は、時刻Ｔ１２５からサイクル間隔Ｔｃの終了点である時刻Ｔ１２６までを送信抑制期間とし、その期間において通信Ｉ／Ｆ部１０８の電源を切断する。

ここまでで、ＴＣＰを用いた送信とＴＣＰを用いた受信とを同時に動作させる場合の、１サイクルが完了する。携帯型端末１００１は、時刻Ｔ１２６以降も次のサイクルにおいて上述と同様の処理を実行することで、省電力効果を向上させることができる。

なお、図３６では、携帯型端末１００１の省電力方法について、携帯型端末１００１がＴＣＰを用いた送信とＴＣＰを用いた受信とを実行する場合を例に挙げて説明した。しかし、サイクル基準アプリケーションがどちらの通信アプリケーションプログラムになるかにかかわらず、ａ）ＴＣＰを用いた２つの送信処理を並列に実行する場合、ｂ）ＴＣＰを用いた２つの受信処理を並列に実行する場合でも、本実施の形態における携帯型端末１００１は間欠送受信処理により省電力効果を向上させることができる。以下に上記ａ）、ｂ）について具体的に説明する。

ａ）携帯型端末１００１がＴＣＰを用いた２つの送信処理を並列に実行する場合は、携帯型端末１００１は、サイクル間隔Ｔｃを開始する時点で、２つの受信側装置に対してデータパケットを送信し、対応するＡＣＫパケットを受信する。

ｂ）携帯型端末１００１がＴＣＰを用いた２つの受信処理を並列に実行する場合は、携帯型端末１００１は、サイクル間隔Ｔｃを開始する時点で、２つの送信側装置に対してＡＣＫ単発送信要求に基づくＡＣＫパケットを送信し、サイクルデータサイズＤｃ分のデータパケットを受信する。

このように、本実施の形態では、複数の通信アプリケーションプログラムが動作している携帯型端末においても、通信アプリケーションプログラムの同期をとりながら間欠送受信を行い、通信Ｉ／Ｆ部１０８の電源を切断する期間を定期的に設けることで、省電力効果を向上させることができる。

（実施の形態７）
本発明の実施の形態７に係る通信装置について説明する。本実施の形態では、間欠送受信処理に伴い通信Ｉ／Ｆ部１０８への電力供給を切り換えるだけでなく、他の構成要素の動作も切り換えることにより、省電力効果をさらに高める。

図３７は、本実施の形態における通信装置を有する通信システムの一例を示す構成図である。

本実施の形態に係る通信システムは、通信装置たる携帯型無線装置１１０２と、携帯型端末１１０１とを備え、携帯型端末１１０１と携帯型無線装置１１０２は基地局を経由することなく無線で直接通信する。

携帯型無線装置１１０２は、通信品質と省電力効果のさらなる向上を両立して図った通信装置であって、無線通信デバイスを搭載した無線端末として構成されている。また、この携帯型無線装置１１０２は、実施の形態６の携帯型端末１００１と同様にフロー制御付の通信を用いて、携帯型端末１１０１と通信する。本実施の形態では、この携帯型無線装置１１０２は、通信相手となる携帯型端末１１０１からのデータ取得の要求に対し、携帯型無線装置１１０２が記憶しているデータを送信する。なお、携帯型端末１１０１と携帯型無線装置１１０２との間の通信において、上位プロトコルでフロー制御付の通信を行っていれば、無線接続の方式は、Ｂｌｕｅｔｏｏｔｈ（登録商標）や、無線ＬＡＮのインフラストラクチャーモード、アドホックモードなどであってもよく、通信方式を限定しない。

図３８は、本実施の形態における携帯型無線装置１１０２の具体的な構成を示す構成図である。

本実施の形態における携帯型無線装置１１０２は、通信アプリケーション部１０１１と、アプリ要求取得部１０１２と、パラメータ決定部１０１３と、抑制再開制御部１１１４と、電源制御部１０６と、通信制御部１１１７と、通信Ｉ／Ｆ部１０８と、ＲＴＴ推定部１０１９と、記憶部１０１７とを備える。なお、本実施の形態において、実施の形態１〜６と同様の構成要素については、同一の参照符号を付して説明を省略する。つまり、本実施の形態における携帯型無線装置１１０２は、実施の形態６の抑制再開制御部１０１４の代わりに抑制再開制御部１１１４を備え、通信制御部１０２７の代わりに通信制御部１１１７を備え、さらに新規に記憶部１０１７を備えている。

記憶部１０１７は、通信アプリケーション部１０１１で利用するデータを記憶している。また、記憶部１０１７は、ハードディスクとキャッシュとモータとを備え、ハードディスクから読み出したデータをキャッシュに保存する。ハードディスクに記憶されているデータは、プラッタと呼ばれるディスク上に保存され、プラッタは、セクタとよばれる単位に分割されている。データの読み出しの際は、プラッタをモータで回転させてセクタの整数倍単位でデータの読み出しを行う。一方、キャッシュは、ディスクとは異なり、半導体メモリなどで構成され、モータを使用しない方式でデータを保存する。なお、記憶部１０１７は、抑制再開制御部１０１４からのデータ取得要求によりモータを起動して、ハードディスクからデータを読み出し、キャッシュに記憶すると同時に、キャッシュに記憶された必要分のデータのみを通信アプリケーション部１０１１に渡す。

抑制再開制御部１１１４は、間欠送受信処理を開始する際、携帯型無線装置１１０２が間欠送受信処理を行うことを通知する機能をさらに備える。間欠送受信処理は、通信相手が間欠送受信処理を行わない場合に省電力効果を高めることができる。そのため、携帯型無線装置１１０２は、間欠送受信処理を行う前に通信相手となる携帯型端末１１０１に対し、間欠送受信処理を行うことを通知し、その携帯型端末１１０１による間欠送受信処理を停止させる。

具体的には、抑制再開制御部１１１４は、通信制御部１１１７に、間欠送受信処理を行う旨を通知する。さらに、抑制再開制御部１１１４は、記憶部１０１７に対してデータ取得要求を行い、モータ起動のタイミングと間欠送受信処理のタイミングとを連動させる。

通信制御部１１１７は、抑制再開制御部１１１４から間欠送受信処理を行う旨を通知されると、ＴＣＰパケットに間欠送受信処理を行う設定を行う。具体的には、通信制御部１１１７は、携帯型端末１１０１との通信開始時のＴＣＰの３ＷＡＹハンドシェイクの際に、ＴＣＰヘッダのオプションフィールドに新たに間欠送受信有効フラグを追加する。間欠送受信有効フラグが有効であるＴＣＰパケットを受信した通信相手である携帯型端末１１０１は、間欠送受信処理を実施しない。

図３９は、本実施の形態における携帯型無線装置１１０２と携帯型端末１１０１の定常状態での動作を示すシーケンス図である。なお、本実施の形態における初期状態および準備状態の処理は、実施の形態５と同様のため、説明を省略する。

抑制再開制御部１１１４は、定常状態では、サイクルが開始される時刻Ｔ１３１に、最初のデータパケットＰ１を送信し、さらにそのタイミングで記憶部１０１７に対してデータ取得要求を行う。これにより、記憶部１０１７は、キャッシュにサイクルデータサイズ分のデータを保持している場合には、そのデータを通信アプリケーション部１０１１に渡す。また、記憶部１０１７は、キャッシュにサイクルデータサイズ分のデータを保持していなければ、ハードディスクのモータを起動し、サイクルデータサイズの整数倍のデータをキャッシュにコピーすると同時に、サイクルデータサイズ分のデータを通信アプリケーション部１０１１に渡す。これにより、ハードディスクのモータの起動回数を減らして、モータ起動時の電力を抑制することができる。

携帯型無線装置１１０２は、このような処理を繰り返すことにより、通信アプリケーションプログラムが必要とする全てのデータを送信する。

このように、本実施の形態では、データを送信する所定のタイミングのみで、記憶部１０１７のモータを起動することにより、携帯型無線装置１１０２の省電力効果を高めることができる。また、間欠送受信処理を行う前に、間欠送受信処理を行う旨を通知することで、確実に省電力効果を高めることができる。

なお、携帯型無線装置１１０２は、携帯型のハードディスクや、携帯型の音楽記録再生機、携帯型の動画記録再生機などの、無線通信により記憶しているデータを送信する装置であってもよい。

また、本実施の形態では、データ送信のタイミングに常にモータを起動してもよく、一度のモータの起動で、複数回分のデータをキャッシュに記憶させ、モータの起動および停止回数を削減してもよい。

また、本実施の形態では、記憶部１０１７のモータと同期させて、間欠送受信処理を行ったが、セルラー系の通信手段を持つ携帯型端末の場合、その通信の送受信タイミングと同期させて、間欠送受信処理を実施してもよい。

また、本実施の形態では、間欠送受信のタイミングに記憶部１０１７におけるモータの処理を同期させたが、他の処理を同期させてもよく、ＣＰＵ稼動時間が小さくなるように制御してもよい。

以上、本発明に係る通信装置について、実施の形態１〜７を用いて説明したが、本発明は、これらに限定されるものではない。

例えば、図５、図１２、図１４、図２２、図２５、図３０、および図３８に示す通信装置をそれぞれＬＳＩ（Large Scale Integration）などの半導体集積回路で構成してもよい。

また、実施の形態１〜７のそれぞれの特徴を組み合わせても本発明を実現することができる。

本発明の通信装置は、通信品質と省電力効果のさらなる向上を両立して図ることができるという効果を奏し、例えば、テレビやＤＶＤ（Digital Versatile Disk）プレーヤーなどの据え置き型の家電機器、携帯電話やＰＤＡ（Personal Digital Assistants）などの携帯機器、並びにパーソナルコンピュータなどに適用することができる。

図１は、従来の通信装置の動作を説明するための説明図である。 図２は、従来の他の通信装置の動作を説明するための説明図である。 図３は、本発明の実施の形態１における通信装置を有する通信システムの一例を示す構成図である。 図４は、同上の受信側装置である携帯型端末と送信側装置との基本的な処理の一例を示すシーケンス図である。 図５は、同上の携帯型端末の具体的な構成を示す構成図である。 図６Ａは、同上のアプリ要求取得部が管理する性能パラメータ管理テーブルを示す図である。 図６Ｂは、同上のアプリ要求取得部が管理する他の性能パラメータ管理テーブルを示す図である。 図６Ｃは、同上のアプリ要求取得部が管理するさらに他の性能パラメータ管理テーブルを示す図である。 図７は、同上の間欠受信パラメータの決定ルールを示す図である。 図８は、同上のパラメータ決定部によって生成された間欠受信パラメータ管理テーブルの一例を示す図である。 図９は、同上の携帯型端末と送信側装置の定常状態での動作を示すシーケンス図である。 図１０は、同上の携帯型端末の動作を示すフローチャートである。 図１１は、同上の受信ウィンドウ（ＲＷＩＮ）＝０のＡＣＫパケットが送信される動作を示すシーケンス図である。 図１２は、本発明の実施の形態２における携帯型端末の具体的な構成を示す構成図である。 図１３は、同上の携帯型端末と送信側装置の省電力方法を示すシーケンス図である。 図１４は、本発明の実施の形態３における携帯型端末の具体的な構成を示す構成図である。 図１５は、同上の携帯型端末の動作を示すフローチャートである。 図１６は、同上のパケットロス検知処理の詳細を説明するための説明図である。 図１７は、同上の再送誘発処理の詳細を説明するための説明図である。 図１８は、同上のＣＷＩＮ推定処理の詳細を説明するための説明図である。 図１９は、同上のＣＷＩＮ低下期間中の処理の詳細を示すフローチャートである。 図２０は、同上のＣＷＩＮ低下期間中において行われる間欠受信の１サイクルを示す図である。 図２１は、本発明の実施の形態４における通信装置を有する通信システムの一例を示す構成図である。 図２２は、同上の携帯型端末の具体的な構成を示す構成図である。 図２３は、同上の受信側装置と携帯型端末と送信側装置の定常状態での動さを示すシーケンス図である。 図２４は、本発明の実施の形態５における通信装置を有する通信システムの一例を示す構成図である。 図２５は、同上の送信側装置である携帯型端末の具体的な構成を示す構成図である。 図２６は、同上の携帯型端末と受信側装置の定常状態での動作を示すシーケンス図である。 図２７は、同上の携帯型端末の動作を示すフローチャートである。 図２８は、同上の携帯型端末と受信側装置の定常状態で、ＲＴＴ間も電源切断を行う場合の動作を示すシーケンス図である。 図２９は、本発明の実施の形態６における通信装置を有する通信システムの一例を示す構成図である。 図３０は、同上の携帯型端末の具体的な構成を示す構成図である。 図３１Ａは、同上のアプリ要求取得部が管理するＵＤＰに関する性能パラメータ管理テーブルを示す図である。 図３１Ｂは、同上のアプリ要求取得部が管理するＵＤＰに関する他の性能パラメータ管理テーブルを示す図である。 図３２Ａは、同上のアプリ要求取得部が管理するＴＣＰに関する性能パラメータ管理テーブルを示す図である。 図３２Ｂは、同上のアプリ要求取得部が管理するＴＣＰに関する他の性能パラメータ管理テーブルを示す図である。 図３３は、同上の携帯型端末と、ＵＤＰを用いた通信を行う送信側装置と、ＴＣＰを用いた通信を行う送信側装置との通信において、送信間隔とサイクル間隔が同期する場合における、定常状態での動作を示すシーケンス図である。 図３４は、サイクル間隔と送信間隔とが異なる場合に抑制再開制御部がデータの送受信のタイミングの同期を取るための動作を示すフローチャートである。 図３５は、同上の携帯型端末と、ＵＤＰを用いた通信を行う送信側装置と、ＴＣＰを用いた通信を行う送信側装置との通信において、送信間隔とサイクル間隔が同期しない場合における、定常状態での動作を示すシーケンス図である。 図３６は、同上の携帯型端末と、ＴＣＰを用いた通信を行う受信側装置と、ＴＣＰを用いた通信を行う送信側装置との通信において、定常状態での動作を示すシーケンス図である。 図３７は、本発明の実施の形態７における通信装置を有する通信システムの一例を示す構成図である。 図３８は、同上の携帯型無線装置の具体的な構成を示す構成図である。 図３９は、同上の携帯型無線装置と携帯型端末の定常状態での動作を示すシーケンス図である。

符号の説明

１０１ 通信アプリケーション部
１０２ アプリ要求取得部
１０３ パラメータ決定部
１０４ 抑制再開制御部
１０６ 電源制御部
１０７ 通信制御部
１０８ 通信Ｉ／Ｆ部
２０２ 無線基地局
２０３ 送信側装置
２０４ インターネット（ＷＡＮ）
２１１、２１２ 携帯型端末（通信装置）

Claims (25)

1. 通信相手側装置と通信する通信装置であって、
   前記通信相手側装置に対してデータの送受信を行う通信手段と、
   前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態と、前記送受信に必要な電力が供給されていない非給電状態とに切り換える電源切換手段と、
   前記通信相手側装置に対してデータの送信を抑制させる抑制手段と、
   前記抑制手段によってデータの送信が抑制されていないときには、前記電源切換手段に対して、前記電力の状態を前記給電状態に切り換えさせ、前記抑制手段によってデータの送信が抑制されているときには、前記電源切換手段に対して、前記電力の状態を前記非給電状態に切り換えさせる切換制御手段と
   を備えることを特徴とする通信装置。
2. 前記通信装置は、さらに、
   送信データを前記通信手段から送信させることにより、前記通信相手側装置から肯定応答パケットを送信させて前記通信手段に受信させることを繰り返す通信制御手段を備え、
   前記抑制手段は、前記送信データの前記通信手段からの送信を停止することにより、前記通信相手側装置に対して肯定応答パケットの送信を抑制させる
   ことを特徴とする請求項１記載に通信装置。
3. 前記抑制手段は、さらに、前記送信データの送信の停止を解除することで、前記通信相手側装置からの肯定応答パケットの送信を再開させる
   ことを特徴とする請求項２記載の通信装置。
4. 前記通信装置は、さらに、
   サイクル時間およびサイクルデータサイズを決定する決定手段を備え、
   前記通信制御手段は、前記決定手段で決定されたサイクルデータサイズ分の送信データを前記通信手段から送信させ、前記送信データを送信したタイミングをサイクル開始時点とし、
   前記抑制手段は、前記通信手段から前記送信データが送信されてから、前記決定手段で決定された前記サイクル時間が経過する時点をサイクル終了時点とし、
   前記送信データに対する肯定応答パケットが前記通信手段に受信されてから前記サイクル終了時点まで、前記送信データの前記通信手段からの送信を停止し、
   前記サイクル終了時点を次のサイクルの前記サイクル開始時点として、前記サイクル開始時点から前記サイクル終了時点までの処理を前記サイクル時間ごとに繰り返させる
   ことを特徴とする請求項３記載の通信装置。
5. 前記通信装置は、さらに、
   データサイズである受信ウィンドウを含む送信要求データを前記通信手段から送信させることにより、前記通信相手側装置から前記受信ウィンドウ以下のデータを送信させて前記通信手段に受信させることを繰り返す通信制御手段を備え、
   前記抑制手段は、０より大きな値を示す受信ウィンドウを含む前記送信要求データを正送信要求データとし、当該正送信要求データの前記通信手段からの送信を停止することにより、前記通信相手側装置に対してデータの送信を抑制させる
   ことを特徴とする請求項１記載の通信装置。
6. 前記抑制手段は、さらに、前記正送信要求データの送信の停止を解除することで、前記通信相手側装置からのデータの送信を再開させる
   ことを特徴とする請求項５記載の通信装置。
7. 前記通信制御手段は、前記通信手段でデータが受信されると、前記データを受信したことを通知する肯定応答パケットを前記送信要求データとして前記通信手段から送信させ、
   前記抑制手段は、前記通信手段でデータが受信されたときに前記正送信要求データとして送信されるべき、０より大きな値を示す受信ウィンドウを含む前記肯定応答パケットの、前記通信手段からの送信を停止することにより、前記通信相手側装置に対してデータの送信を抑制させ、０より大きな値を示す受信ウィンドウを含む前記肯定応答パケットを前記通信制御手段に生成させて送信させることにより、前記通信相手側装置からのデータの送信を再開させる
   ことを特徴とする請求項６記載の通信装置。
8. 前記抑制手段は、複数の送信要求データに対して前記通信相手側装置から前記通信手段に送信されるデータのサイズが予め定められたサイズとなるように、前記複数の送信要求データのそれぞれの前記受信ウィンドウを設定することにより、前記通信相手側装置に対してデータの送信を抑制させる
   ことを特徴とする請求項６記載の通信装置。
9. 前記抑制手段は、さらに、前記通信相手側装置のデータの送信が抑制されているときに、受信ウィンドウとして０を示す送信要求データを前記通信手段から送信させる
   ことを特徴とする請求項６記載の通信装置。
10. 前記通信装置は、さらに、
    サイクル時間およびサイクルデータサイズを決定する決定手段を備え、
    前記通信制御手段は、前記決定手段で決定されたサイクルデータサイズを前記受信ウィンドウとし、前記サイクルデータサイズを示す送信要求データを前記通信手段から送信させ、前記送信要求データを送信したタイミングをサイクル開始時点とし、
    前記抑制手段は、前記通信手段から前記送信要求データが送信されてから、前記決定手段で決定された前記サイクル時間が経過する時点をサイクル終了時点とし、
    前記サイクルデータサイズのデータが前記通信手段に受信されてから前記サイクル終了時点まで、前記正送信要求データの前記通信手段からの送信を停止し、
    前記サイクル終了時点を次のサイクルの前記サイクル開始時点として、前記サイクル開始時点から前記サイクル終了時点までの処理を前記サイクル時間ごとに繰り返させる
    ことを特徴とする請求項６記載の通信装置。
11. 前記通信手段は、前記通信相手側装置および他の通信相手側装置との間でデータの送受信を並列に行い、
    前記決定手段は、前記通信手段が前記他の通信相手側装置との間で一定時間ごとに送受信を繰り返す場合、前記他の通信相手側装置との間の送受信と、前記通信相手側装置からのデータの受信とが同期するように、前記一定時間に基づいて前記サイクル時間を決定する
    ことを特徴とする請求項１０記載の通信装置。
12. 前記決定装置は、前記通信手段が前記他の通信相手側装置から一定時間ごとに固定レートでデータを受信することを繰り返す場合に、前記一定時間を基準とし、前記一定時間に基づいて前記サイクル時間を決定する
    ことを特徴とする請求項１１記載の通信装置
13. 前記切換制御手段は、
    前記通信相手側装置から前記サイクルデータサイズのデータが送信されて前記通信手段に受信された後、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、
    前記サイクル終了時点までに、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせる
    ことを特徴とする請求項１０記載の通信装置。
14. 前記通信相手側装置は、当該通信相手側装置から送信されたデータが消失して前記通信手段に受信されなかったことを検知すると、前記送信要求データに対して送信可能なデータのサイズである送信ウィンドウを減少させ、
    前記抑制手段は、
    前記通信手段から送信された前記送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に受信されたデータのサイズが、前記送信要求データの示すサイクルデータサイズよりも小さいか否かを判別し、
    小さいと判別したときには、前記受信ウィンドウが前記送信ウィンドウ以下となるようなウィンドウ制御を行う
    ことを特徴とする請求項１３記載の通信装置。
15. 前記抑制手段は、
    前記通信手段に受信されたデータのサイズが前記サイクルデータサイズよりも小さいと判別したときには、前記ウィンドウ制御として、後に前記通信手段から送信される送信要求データの示す受信ウィンドウを前記サイクルデータサイズよりも小さくさせる
    ことを特徴とする請求項１４記載の通信装置。
16. 前記通信相手側装置は、前記通信手段から送信要求データを受信して、前記送信要求データに対するデータを前記通信手段に送信することを繰り返すことによって、減少された前記送信ウィンドウを増加させ、
    前記抑制手段は、前記送信ウィンドウが前記サイクルデータサイズよりも小さくなってから前記サイクルデータサイズ以上になるまでのウィンドウ回復期間、前記ウィンドウ制御として、前記正送信要求データの送信の停止を解除する
    ことを特徴とする請求項１４記載の通信装置。
17. 前記抑制手段は、
    前記通信手段から送信される送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に受信されるデータのサイズの期待値を計算し、
    前記通信手段から送信された送信要求データに対して、前記通信相手側装置から送信されて前記通信手段に受信されたデータのサイズが、前記期待値よりも小さいか否かを判別し、
    小さいと判別したときには、前記通信手段に受信されるデータのサイズが前記期待値に近づくように、後に前記通信手段から送信される送信要求データの送信形式を変更する
    ことを特徴とする請求項１３記載の通信装置。
18. 前記切換制御手段は、
    前記通信手段から前記送信要求データが送信された後に、前記電源切換手段に対して、前記電力の状態を前記給電状態から前記非給電状態に切り換えさせ、
    前記送信要求データに対するデータが前記通信手段に受信される前に、前記電源切換手段に対して、前記電力の状態を前記非給電状態から前記給電状態に切り換えさせる
    ことを特徴とする請求項１３記載の通信装置。
19. 前記決定手段は、前記通信装置と前記通信相手側装置との間で要求される通信の性能に基づいて、前記サイクル時間およびサイクルデータサイズを決定する
    ことを特徴とする請求項１０記載の通信装置。
20. 前記通信手段は、前記通信相手側装置および他の通信相手側装置との間でデータの送受信を並列に行い、
    前記抑制手段は、前記通信手段が前記他の通信相手側装置から一定時間ごとに固定レートでデータを受信することを繰り返す場合、前記他の通信相手側装置からのデータが前記通信手段に受信されるタイミングと、前記通信相手側装置からのデータが前記通信手段に受信されるタイミングとが一致するように、前記通信手段からの前記正送信要求データの送信の停止および解除を行う
    ことを特徴とする請求項６記載の通信装置。
21. 前記通信手段は、前記通信相手側装置と通信端末との間における通信を中継する
    ことを特徴とする請求項１記載の通信装置。
22. 通信相手側装置と、前記通信相手側装置と通信する通信装置とを備える通信システムであって、
    前記通信装置は、
    前記通信相手側装置に対してデータの送受信を行う通信手段と、
    前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態と、前記送受信に必要な電力が供給されていない非給電状態とに切り換える電源切換手段と、
    前記通信相手側装置に対してデータの送信を抑制させる抑制手段と、
    前記抑制手段によってデータの送信が抑制されていないときには、前記電源切換手段に対して、前記電力の状態を前記給電状態に切り換えさせ、前記抑制手段によってデータの送信が抑制されているときには、前記電源切換手段に対して、前記電力の状態を前記非給電状態に切り換えさせる切換制御手段と
    を備えることを特徴とする通信システム。
23. 通信相手側装置と通信する通信手段を用いた通信方法であって、
    前記通信手段が前記通信相手側装置に対してデータの送受信を行う通信ステップと、
    前記通信相手側装置に対してデータの送信を抑制させる抑制ステップと、
    前記抑制ステップによってデータの送信が抑制されていないときには、前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態に切り換える給電ステップと、
    前記抑制ステップによってデータの送信が抑制されているときには、前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されていない非給電状態に切り換える非給電ステップと
    を含むことを特徴とする通信方法。
24. 通信手段を用いて通信相手側装置と通信するためのプログラムであって、
    前記通信手段が前記通信相手側装置に対してデータの送受信を行う通信ステップと、
    前記通信相手側装置に対してデータの送信を抑制させる抑制ステップと、
    前記抑制ステップによってデータの送信が抑制されていないときには、前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態に切り換える給電ステップと、
    前記抑制ステップによってデータの送信が抑制されているときには、前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されていない非給電状態に切り換える非給電ステップと
    をコンピュータに実行させることを特徴とする通信方法。
25. 通信相手側装置と通信する集積回路であって、
    前記通信相手側装置に対してデータの送受信を行う通信手段と、
    前記通信手段に対して供給される電力の状態を、前記送受信に必要な電力が供給されている給電状態と、前記送受信に必要な電力が供給されていない非給電状態とに切り換える電源切換手段と、
    前記通信相手側装置に対してデータの送信を抑制させる抑制手段と、
    前記抑制手段によってデータの送信が抑制されていないときには、前記電源切換手段に対して、前記電力の状態を前記給電状態に切り換えさせ、前記抑制手段によってデータの送信が抑制されているときには、前記電源切換手段に対して、前記電力の状態を前記非給電状態に切り換えさせる切換制御手段と
    を備えることを特徴とする集積回路。

Images