(57)【要約】【課題】バッファを最小にし、かつ、バッファ内でのオーバー・ランによるパケット損失による再送を防ぐことにより、必要以上の負荷をネットワークに掛けることなく、伝送効率を低下させない受信端末装置を提供する。【解決手段】受信端末装置（２６５）において、前記データ（Ｐ）のペイロード長（ＰＬＤ＿ＬＥＮ）が検出され、予め指示された最大ウィンドウ・サイズ（Ｗｉｎ＿ＳＺ（ｍａｘ））を保持され、最大ウィンドウ・サイズ（Ｗｉｎ＿ＳＺ（ｍａｘ））とペイロード長と外部より与えられるフロー制御指示（Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔ）に基づいてウィンドウ・サイズ（Ｘ）を算出される。【選択図】図１
2009071766.tif 000002
【特許請求の範囲】
【請求項１】
受信可能なデータサイズを表すウィンドウ・サイズを通知して、送信端末装置に対するデータ送信のフロー制御を行う通信プロトコルを使用するデータ伝送に用いられる受信端末装置であって、
前記データのペイロード長を検出するペイロード長検出手段と、
予め指示された最大ウィンドウ・サイズを保持する最大ウィンドウ・サイズ保持手段と、
前記最大ウィンドウ・サイズと前記ペイロード長と外部より与えられるフロー制御指示に基づいて前記ウィンドウ・サイズを算出するウィンドウ・サイズ算出手段とを備える受信端末装置。
【請求項２】
前記通信プロトコルはＴＣＰプロトコルであることを特徴とする請求項１に記載の受信端末装置。
【請求項３】
前記ウィンドウ・サイズ算出手段は、前記フロー制御指示の開始時点から前記ペイロード長を減算した値を前記ウィンドウ・サイズとして算出することを特徴とする請求項１に記載の受信端末装置。
【請求項４】
前記ウィンドウ・サイズ算出手段は、前記フロー制御指示が与えられない場合は、前記最大ウィンドウ・サイズを前記ウィンドウ・サイズとして算出することを特徴とする請求項３に記載の受信端末装置。
【請求項５】
前記最大ウィンドウ・サイズの値は、外部のアプリケーション処理部において受信可能なデータバッファ容量が６４ＫＢ−１以上であれば、６４ＫＢ−１の値が設定されることを特徴とする請求項１に記載の受信端末装置。
【請求項６】
前記最大ウィンドウ・サイズの値は、外部のアプリケーション処理部において受信可能なデータバッファ容量が６４ＫＢ−１未満であれば、外部のアプリケーション処理部の受信可能なデータバッファ容量を設定することを特徴とする請求項１に記載の受信端末装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の通信プロトコルに従ってデータを受信する端末装置に関し、詳述すればＴＣＰプロトコルに従って受信するＴＣＰ受信端末装置に関する。
【背景技術】
【０００２】
図４に、従来より動画や音楽などのストリーミング配信に利用されているネットワークの一例を示す。ストリーミング配信ネットワークでは、ストリーミング配信サービスを行うサーバ１００が、インターネット１０００およびルータ１００４を介して、配信サービスを受けるユーザの宅内に構成された宅内ネットワーク２０００に接続されている。なお、宅内ネットワーク２０００には、サーバ１００から提供された配信サービスを利用するＡＶ機器２００が接続されている。図４において、点線Ｌｄはサーバ１００からＡＶ機器２００へのデータ伝送を表している。一点鎖線Ｌｉは宅内ネットワーク２０００内でのデータ転送を表している。
【０００３】
サーバ１００は、それぞれ異なるストリーミング配信サービスを行うサーバ１００＿１、１００＿２、および１００＿３が含まれる。本例においては、サーバ１００＿１は動画を配信し、サーバ１００＿２は音楽を配信し、サーバ１００＿３はその他を配信する。
【０００４】
ＡＶ機器２００には、サーバ１００＿１、１００＿２、および１００＿３のそれぞれから配信されるデータストリームの内容に応じて、デジタルＴＶ２００＿１、デジタル・ビデオ録画機２００＿２、オーディオ機器２００＿３、およびパーソナルコンピュータ（以降、「ＰＣ」）２００＿４が接続されて機器連携が行われている。
【０００５】
このようなストリーミング配信ネットワークにおける通信サービスには、通信品質の確保の観点からＴＣＰ通信プロトコルがよく利用される。また、インターネット等のネットワークの高速化が進み、従来、ソフト処理してきたＴＣＰ通信プロトコルの一部、あるいは、全てをハードウェアにて処理するＴＣＰ  Ｏｆｆｌｏａｄ  Ｅｎｇｉｎｅ（以下、「ＴＯＥ」）と呼ばれる装置も普及しつつある。
【０００６】
ＴＣＰ通信プロトコルを利用する場合の利点として、ネットワークとの高親和性、高通信品質、および送信側のフロー制御可能の３つを挙げることができる。具体的には、ＴＣＰ通信プロトコルはインターネットにて普及しているので、ネットワーク特にインターネットとの親和性が高い。伝送パケットに対する受信側からの確認応答、および、再送メカニズムを実装してあることから、通信品質が高い。受信側よりウィンドウ・サイズを使用して送信側のフロー制御が可能である。
【０００７】
次に、図５を参照して、ＴＣＰ通信プロトコルを用いた場合のフロー制御について説明する。なお、図５は、サーバ１００におけるＴＣＰ送信端末装置２６０と、ＡＶ機器２００におけるＴＣＰ受信端末装置２６５間のデータ伝送シーケンスを表している。ＴＣＰ通信プロトコルにおいては、まずＴＣＰ受信端末装置２６５側のバッファで処理できるデータ量を表すウインドウ・サイズＸ１が決定される。そして、ウィンドウ・サイズＸ１が反映されたパケットＰ２００（図においては、Ｐ２００（Ｘ１）と表示）が生成されて、ＴＣＰ送信端末装置２６０に送信される。
【０００８】
インターネットを利用した配信サービスでは、サーバ１００＿１、１００＿２、および１００＿３は、図５のＴＣＰ送信端末装置２６０に相当する機能を有している。同様に、デジタルＴＶ２００＿１、デジタル・ビデオ録画機２００＿２、オーディオ機器２００＿３、およびＰＣ２００＿４はＴＣＰ受信端末装置２６５の機能を有している。なお、宅内では、デジタル・ビデオ録画機２００＿２、オーディオ機器２００＿３、およびＰＣ２００＿４は、ＴＣＰ送信端末装置２６０およびＴＣＰ受信端末装置２６５の両方に相当する機能を有し、デジタルＴＶ２００＿１はＴＣＰ受信端末装置２６５に相当する機能を有する。
【０００９】
パケットＰ２００に応答して、ＴＣＰ送信端末装置２６０からＴＣＰ受信端末装置２６５に対して、パケットＰ２１０、２１１および２１２が順次送信される。ＴＣＰ受信端末装置２６５は、パケットＰ２１２の受信後に、再度バッファで処理できるデータ量を表すウインドウ・サイズＸ２を決定し、同ウインドウ・サイズＸ２が反映された確認応答ＡＣＫ２５０（図では、ＡＣＫ２５０（Ｘ２）と表示）を生成する。そして、ＴＣＰ受信端末装置２６５は確認応答ＡＣＫ２５０をＴＣＰ送信端末装置２６０に対して送信する。
【００１０】
ＴＣＰ送信端末装置２６０は、確認応答ＡＣＫ２５０に応答して、パケットＰ２１３およびＰ２１４を送信する。ＴＣＰ受信端末装置２６５は、パケットＰ２１３および２１４の受信後に、また、バッファで処理できるデータ量を表すウインドウ・サイズＸ３を決定し、同ウィンドウ・サイズＸ３が反映された確認応答ＡＣＫ２５１（図では、ＡＣＫ２５１（Ｘ３）と表示）を生成する。確認応答ＡＣＫ２５１はＴＣＰ受信端末装置２６５からＴＣＰ送信端末装置２６０に送信されて、以降同様の処理が続く。なお、ウィンドウ・サイズＸ１、Ｘ２、Ｘ３、・・・をウィンドウ・サイズＸと総称する。
【００１１】
図６に、ＴＣＰ通信プロトコルで用いられるＴＣＰパケットヘッダＨｐの構成例を示す。ＴＣＰパケットヘッダＨｐは、送信元ＴＣＰポート、宛先ＴＣＰポート、ＴＣＰシーケンス番号、ＴＣＰアクノーリッジ番号、およびウインドウ・サイズ等の情報が書き込まれる領域を有している。なお、本明細書においては、それぞれの領域は、書き込まれる情報名（例えば、ウインドウ・サイズ領域）で呼称されるものとする。なお、ＴＣＰパケットヘッダＨｐに書き込まれるウィンドウ・サイズＸは１６ビットであり、最大６４Ｋ−１バイトの値をとることができる。
【００１２】
図７に、従来のＴＣＰ受信端末装置２６５の一例（以降、「従来例１」）の構成を示す。本例にかかるＴＣＰ受信端末装置２６５ａは、アプリケーション部３００と共に、ＡＶ機器２００の一部を構成している。つまり、ＴＣＰ受信端末装置２６５ａ（ＴＣＰ受信端末装置２６５）は、ＡＶ機器２００がインターネット１０００および宅内ネットワーク２０００を介してサーバ１００から伝送されてくるストリーミングデータを受信する機能を有している。
【００１３】
アプリケーション部３００は、受信したストリーミングデータに含まれるペイロードを処理して、ユーザにコンテンツとして提示できるようにする機能を有している。つまり、アプリケーション部３００の機能によって、ＡＶ機器２００がデジタルＴＶ２００＿１、デジタル・ビデオ録画機２００＿２、オーディオ機器２００＿３、或いはＰＣ２００＿４等として働く。
【００１４】
ＴＣＰ受信端末装置２６５ａは、送受信部１、ＩＰ制御部２、ＴＣＰ制御部３ａ、およびペイロード出力部４を含む。ＴＣＰ制御部３ａは、ＴＣＰ受信バッファ３０およびウインドウ・サイズ算出部３１を含む。
【００１５】
送受信部１は、経路Ｃ２０１によって、宅内ネットワーク２０００と相互に接続されている。送受信部１とＩＰ制御部２とは、経路Ｃ２０２によって、相互に接続されている。
ＩＰ制御部２は、経路Ｃ２０８によって、ウインドウ・サイズ算出部３１に接続されている。ＴＣＰ受信バッファ３０は、経路Ｃ２０３によって、ＩＰ制御部２に接続されている。ウインドウ・サイズ算出部３１は、経路Ｃ２０６によって、ＴＣＰ受信バッファ３０に接続されている。
【００１６】
ペイロード出力部４は、経路Ｃ２０４および経路Ｃ３０１によって、ＴＣＰ受信バッファ３０およびＡｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２のそれぞれに接続されている。アプリケーション部３００において、アプリケーション・バッファ１０１は経路Ｃ２０５によって、ペイロード出力部４に接続されている。Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２は、経路Ｃ３００によって、アプリケーション・バッファ１０１に接続されている。
【００１７】
以下に、図５および図７を参照しながら、ＡＶ機器２００ａにおけるフロー制御について具体的に説明する。ＴＣＰ受信端末装置２６５ａにおいては、宅内ネットワーク２０００から配信されるデータストリームの受信を開始する前に、ＴＣＰ制御手段３内のウィンドウ・サイズ算出部３１が、経路Ｃ２０６を介してＴＣＰ受信バッファ３０の空き容量値Ｖｆ３０監視して、ウィンドウ・サイズＸ１（図５）を算出する。ウィンドウ・サイズ算出部３１は、算出したウィンドウ・サイズＸ１をＴＣＰヘッダのウィンドウ・サイズ領域に反映して、パケットＰ２００を生成する。生成されたパケットＰ２００は、経路Ｃ２０８を介してＩＰ制御部２に渡される。
【００１８】
ＩＰ制御部２では、ＩＰプロトコルに従いパケットＰ２００に対して送信処理を行った後に、経路Ｃ２０２を介して送受信部１に渡す。送受信部１は、渡されたパケットＰ２００を宅内ネットワーク２０００に送信する。
【００１９】
ＴＣＰ送信端末装置２６０（図５）は、宅内ネットワーク２０００よりパケットＰ２００を受け取る。ＴＣＰ送信端末装置２６０は、Ｐ２００のＴＣＰパケットヘッダＨｐに書き込まれているウィンドウ・サイズＸ１に基づいて送信データのバイト数を決定する。そして、ＴＣＰ送信端末装置２６０は、配信するデータストリームを１つのあるいは複数パケット分割して、パケットＰ２１０、Ｐ２１１，Ｐ２１２として順次送信する。
【００２０】
ＴＣＰ送信端末装置２６０から順次送信されたパケットＰ２１０、Ｐ２１１、およびＰ２１２は、インターネット１０００、宅内ネットワーク２０００、および経路Ｃ２０１を介して、送受信部１によって受信される。受信されたパケットＰ２１０、Ｐ２１１、およびＰ２１２は、経路Ｃ２０２を介して、ＩＰ制御部２に渡される。
【００２１】
ＩＰ制御部２は、パケットＰ２１０、Ｐ２１１、およびＰ２１２に対してＩＰプロトコルに従った受信処理を施した後に、経路Ｃ２０３を介してＴＣＰ制御部３ａのＴＣＰ受信バッファ３０に渡す。
【００２２】
ＴＣＰ制御部３ａでは、ＴＣＰの受信処理に従った処理が行われ、ＴＣＰパケットヘッダーＨｐ（図５）に記載されているＴＣＰシーケンス番号、およびＴＣＰチェックサムに基づいて、受信パケット（Ｐ２１０、Ｐ２１１、およびＰ２１２）の正当性が判断される。そして、正当と判断された受信パケット（Ｐ２１０、Ｐ２１１、およびＰ２１２）からペイロード・データＤｐのみが抽出されて、経路Ｃ２０４を介してペイロード出力部４に渡される。さらに、ペイロード・データＤｐは、経路Ｃ２０５を介してペイロード出力部４からアプリケーション部１００のアプリケーション・バッファ１０１に渡される。
【００２３】
また、ＴＣＰ制御部３ａにおいて、ウィンドウ・サイズ算出部３１は、経路Ｃ２０６を介してＴＣＰ受信バッファ３０の空き容量値Ｖｆ３０を監視して、ウィンドウ・サイズＸ２を算出する。ウィンドウ・サイズ算出部３１において、算出されたウィンドウ・サイズＸ２は送信元に返信される確認応答ＡＣＫ２５０に参照される。ＡＣＫ２５０は経路Ｃ２０８を介してＩＰ制御部２に渡される。
【００２４】
ＩＰ制御部２では、ＩＰプロトコルに従い確認応答ＡＣＫ２５０に対して送信処理を施した後に、経路Ｃ２０２を介して送受信部１に渡す。送受信部１は、確認応答ＡＣＫ２５０を経路Ｃ２０１を介して宅内ネットワーク２０００に送信する。以降同様に、ＴＣＰ送信端末装置２６０からＴＣＰ受信端末装置２６５に対してパケットＰ２１３およびＰ２１４が送信される。
【００２５】
そして、ウィンドウ・サイズＸ３が算出され、確認応答ＡＣＫ２５１がＴＣＰ送信端末装置２６０に対して送信される。なお、紙面の都合上、図７には、確認応答ＡＣＫ２５０およびＡＣＫ２５１と、パケットＰ２１３およびＰ２１４は表示されていない。
【００２６】
図８に、従来のＴＣＰ受信端末装置２６５の更なる例として、特開２００６−２１１０１５号公報（特許文献１）に提案されている無線通信端末装置（以降、「従来例２）の構成を、上述のＴＣＰ受信端末装置２６５ａと対比して示す。本例におけるＴＣＰ受信端末装置２６５ｂも、アプリケーション部３００と共に、ＡＶ機器２００の一部を構成している。
【００２７】
ＴＣＰ受信端末装置２６５ｂは、ＴＣＰ受信端末装置２６５ａにおいて、送受信部１およびＴＣＰ制御部３ａがそれぞれ送受信部１ｂおよびＴＣＰ制御部３ｂに置き換えられている。さらに、ＴＣＰ制御部３ｂと送受信部１ｂの間に、バッファ量推定部４０１およびＲＷＩＮ制御部４０２が追加されている。なお、バッファ量推定部４０１は、経路Ｃ４５１および経路Ｃ４５２によって、それぞれ送受信部１およびＲＷＩＮ制御部４０２と双方向に接続されている。ＲＷＩＮ制御部４０２は、経路Ｃ４５３によって、ＴＣＰ制御部３ｂと双方向に接続されている。
【００２８】
送受信部１ｂは、送受信部１と異なり、受信バッファ１０を内蔵している。一方、ＴＣＰ制御部３ｂは、ＴＣＰ制御部３ａと異なり、ＴＣＰ受信バッファ３０およびウインドウ・サイズ算出部３１を内蔵していない。
【００２９】
受信を開始する前に、バッファ量推定部４０１は、経路Ｃ４５１を介して送受信部１ｂ内の受信バッファ１０の空き容量値Ｖｆ１０を推定し、経路Ｃ４５２を介してＲＷＩＮ制御部４０２に空容量値Ｖｆ１０を通知する。ＲＷＩＮ制御部４０２は、経路Ｃ４５２より通知された空容量値Ｖｆ１０に基づいて、受信可能なバイト数のウィンドウ・サイズＸ１を決定して、経路Ｃ４５３を介してＴＣＰ制御部４００に決定されたウィンドウ・サイズＸ１を通知する。
【００３０】
以降、上述のＡＶ機器２００ａにおけるのと同様の処理の結果、ＴＣＰ送信端末装置２６０からＴＣＰ受信端末装置２６５ｂに対してＰパケット２１０〜Ｐ２１２が順次送信され、Ｐパケット２１０〜Ｐ２１２からペイロード・データＤｐが抽出されて、アプリケーション・バッファ１０１に渡される。
【００３１】
なお、バッファ量推定部４０１は、定期的に受信バッファ１０の空き容量値Ｖｆ１０を推定して、ＲＷＩＮ制御部４０２に通知する。ＲＷＩＮ制御部４０２は、空き容量値Ｖｆ１０に基づいて、受信可能なバイト数を表すウィンドウ・サイズＸ２を決定してＴＣＰ制御部３ｂに通知する。以降の処理は、上述のＡＶ機器２００ａにおけるのと同様であるので、説明を省く。
【００３２】
上述のように、ＴＣＰ通信プロトコルでは、受信側（ＴＣＰ受信端末装置２６５）からＴＣＰ送信端末装置２６０に対して、ウィンドウ・サイズを制御することにより、受信するデータ量を調整するフロー制御が行われる。つまり、ＴＣＰ通信プロトコルでは送信側（ＴＣＰ送信端末装置２６０）は、受信側（ＴＣＰ受信端末装置２６５）で受信可能なバイト数以上のパケットを送信することはないため、受信側（ＴＣＰ受信端末装置２６５）で送信されたパケットを取りこぼすことはない。
【００３３】
次に、図９を参照して、ＴＣＰ通信プロトコルのデータ伝送性能について説明する。図９において、ウィンドウ・サイズＸ１とパケット２１０、Ｐ２１１、およびＰ２１２との関係、確認応答ＡＣＫ２５０（ウィンドウ・サイズＸ２）とパケットＰ２１３およびＰ２１４の関係が示されている。なお、ＲＴＴは、データ転送の開始から、次のデータ転送が開始するまでのラウンド・トリップ・タイムを表している。本例においては、パケットＰ２００（ウィンドウ・サイズＸ１）に応答してパケットＰ２１０の送信が開始されてから、確認応答ＡＣＫ２５０（ウインドウ・サイズＸ２）に応答してパケットＰ２１３の送信が開始されるまでの時間である。
【００３４】
ラウンド・トリップ・タイムＲＴＴとウィンドウ・サイズＸ（バイト）により、伝送性能は次式（１）によって表現できる。
伝送性能  ＝  Ｘ／  ＲＴＴ  ・・・・式（１）
【００３５】
上式（１）より、例えば、ラウンド・トリップ・タイムＲＴＴは同程度の値であり、ウィンドウ・サイズＸが異なる２つの受信端末装置の間には、ウィンドウ・サイズＸに起因して伝送性能に差が生じることが分かる。つまり、ＴＯＥとして１チップに実現されたＴＣＰ受信端末装置２６５では、装置内のバッファの空き容量値Ｖｆがウィンドウ・サイズＸとして送信元に通知されるため、ウィンドウ・サイズＸの最大値は搭載したバッファの容量となる。それゆえに、伝送性能を上げるためには、大容量のバッファを持つ必要があり、コスト高を招く。
【００３６】
また、伝送性能を上げる別の方法として、ＴＣＰ制御部内のバッファのサイズ以上のウィンドウ・サイズＸを通知することも可能である。しかし、アプリケーション部１００においてアプリケーション・バッファ１０１の枯渇が近いことが経路Ｃ３０１を介してＴＣＰ受信端末装置２６５に通知された場合には、ペイロード抽出部４によるバッファからのペイロード抽出が停止する。この場合、ＴＣＰ受信端末装置内のバッファは、受信可能以上のパケットを受信することになる。結果、受信パケットのオーバー・ランが発生して、パケット損失が生じる。そして、損失したパケットの再送が頻発し、ネットワーク負荷の増大と伝送効率が低下する。
【特許文献１】特開２００６−２１１０１５号公報
【発明の開示】
【発明が解決しようとする課題】
【００３７】
本発明は、上記の問題点に鑑みて、バッファを最小にし、かつ、バッファ内でのオーバー・ランによるパケット損失による再送を防ぐことにより、必要以上の負荷をネットワークに掛けることなく、伝送効率を低下させない受信端末装置を提供することを目的とする。
【課題を解決するための手段】
【００３８】
上記目的を達成するために、本発明にかかる受信端末装置は、
受信可能なデータサイズを表すウィンドウ・サイズを通知して、送信端末装置に対するデータ送信のフロー制御を行う通信プロトコルを使用するデータ伝送に用いられる受信端末装置であって、
前記データのペイロード長を検出するペイロード長検出手段と、
予め指示された最大ウィンドウ・サイズを保持する最大ウィンドウ・サイズ保持手段と、
前記最大ウィンドウ・サイズと前記ペイロード長と外部より与えられるフロー制御指示に基づいて前記ウィンドウ・サイズを算出するウィンドウ・サイズ算出手段とを備えている。
【００３９】
ここで、前記通信プロトコルはＴＣＰプロトコルであることが好ましい。また前記ウィンドウ・サイズ算出手段は、前記フロー制御指示の開始時点から前記ペイロード長を減算した値を前記ウィンドウ・サイズとして算出することが好ましい。もしくは前記ウィンドウ・サイズ算出手段は、前記フロー制御指示が与えられない場合は、前記最大ウィンドウ・サイズを前記ウィンドウ・サイズとして算出することが好ましい。
【００４０】
前記最大ウィンドウ・サイズの値は、外部のアプリケーション処理部において受信可能なデータバッファ容量が６４ＫＢ−１以上であれば、６４ＫＢ−１の値が設定される。これに対し、前記最大ウィンドウ・サイズの値は、外部のアプリケーション処理部において受信可能なデータバッファ容量が６４ＫＢ−１未満であれば、外部のアプリケーション処理部の受信可能なデータバッファ容量が設定される。
【発明の効果】
【００４１】
本発明においては、ペイロードを蓄積するバッファの容量に基づいて受信可能なウィンドウ・サイズを決定できる。
【発明を実施するための最良の形態】
【００４２】
（第１の実施の形態）
以下に、図１、および図２を参照して、本発明の第１の実施の形態にかかるＴＣＰ受信端末装置について説明する。図１に示すように、ＴＣＰ受信端末装置２６５＿１は、アプリケーション部３００およびＣＰＵ７１０ａと共にＡＶ機器２００の一部を構成している。ＴＣＰ受信端末装置２６５＿１は、ＴＣＰ受信端末装置２６５ａ（図７）において、ＴＣＰ制御部３ａがＴＣＰ制御部３に交換されると共に、最大ウインドウ・サイズ保持部７００およびウインドウサイズ算出部７０１が新たに追加されている。
【００４３】
最大ウインドウ・サイズ保持部７００は経路Ｃ７６０によって、ＣＰＵ７１０ａに接続されている。ＣＰＵ７１０ａは経路Ｃ７６１によってアプリケーション部３００のＡｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２と双方向に接続されている。ウインドウ・サイズ算出部７０１は、経路Ｃ７５２および経路Ｃ３０１によって、最大ウインドウ・サイズ保持部７００およびＡｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２にそれぞれ接続されている。
【００４４】
ウインドウ・サイズ算出部７０１はさらに、経路Ｃ７５１によってＴＣＰ制御部３と双方向に接続されている。ＴＣＰ制御部３は、基本的に上述のＴＣＰ制御部３ａ（図７）からＴＣＰ受信バッファ３０およびウインドウ・サイズ算出部３１が除かれて構成されていると共に、ＴＣＰ制御部３ａが有していない機能（後述）を有している。
【００４５】
Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２は、経路３００を介して、アプリケーション・バッファ１０１がバッファリングしたデータ量がＡｌｍｏｓｔ＿Ｆｕｌｌの閾値Ｔｈに達しているか否かを監視している。つまり、Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２は、
アプリケーション・バッファ１０１の使用量Ｖｂに基づいて、バファリングデータ量が閾値Ｔｈに達しているか否かの状態を表す信号 (以降、「Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔ」)をフロー制御指示として、経路３０１を介して、ウィンドウ・サイズ算出手段７０１に通知する。
【００４６】
ＣＰＵ７１０ａは、Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２によるＡｌｍｏｓｔ＿Ｆｕｌｌ検出用閾値Ｔｈに基づいて、アプリケーション部３００にて受信可能なデータサイズを求める。求められたデータサイズに基づいて、ＣＰＵ７１０ａは最大ウィンドウ・サイズＷｉｎ＿ＳＺ（ｍａｘ）を決定する。ＣＰＵ７１０ａは経路Ｃ７６０を介して最大ウインドウ・サイズ保持部７００に最大ウィンドウ・サイズＷｉｎ＿ＳＺ（ｍａｘ）を設定する。
【００４７】
最大ウィンドウ・サイズ保持部６は、ウィンドウ・サイズ算出部７０１に常時、経路Ｃ７５２を介して設定された最大ウィンドウ・サイズＷｉｎ＿ＳＺ（ｍａｘ）を通知する。ウインドウ・サイズ算出部７０１は、通知されたＷｉｎ＿ＳＺ（ｍａｘ）に基づいて、ウインドウ・サイズＸを算出する。
【００４８】
最大ウィンドウ・サイズＷｉｎ＿ＳＺ（ｍａｘ）、つまりアプリケーション・バッファ１０１にて受信可能なデータバッファ容量が６４ＫＢ−１以上であれば、ウィンドウ・サイズＸとして６４ＫＢ−１の値が設定される。また、最大ウィンドウ・サイズＷｉｎ＿ＳＺ（ｍａｘ）が６４ＫＢ未満であれば、アプリケーション・バッファ１０１のデータバッファ容量がウィンドウ・サイズＸとして設定される。
【００４９】
次に、ＡＶ機器２００におけるＴＣＰパケット受信について説明する。ＴＣＰパケットの受信開始前に、ウィンドウ・サイズ算出部７０１は、経路Ｃ３０１を介して入力されるＡｌｍｏｓｔ＿Ｆｕｌｌ＿Ｓｔを参照して、ウィンドウ・サイズＸ１を決定する。決定されたウィンドウ・サイズＸ１は、経路Ｃ７５１を介してＴＣＰ制御部３に通知される。
【００５０】
ＴＣＰ制御部３は、ウィンドウ・サイズＸ１をＴＣＰパケットヘッダＨｐのウィンドウ・サイズ領域に反映させて、パケットＰ２００を生成する。パケットＰ２００は、経路Ｃ７５０を介してＩＰ制御部２に渡される。上述のごとく、パケットＰ２００は、ＩＰ制御部２によってＩＰプロトコルに従う送信処理が施された後に、経路Ｃ２０２、送受信部１、および経路Ｃ２０１を介して宅内ネットワーク２０００に送信される。
【００５１】
以降、ＴＣＰ送信端末装置２６０が宅内ネットワーク２０００を介してパケットＰ２００を受け取ってから、パケットＰ２１０，２１１，２１２がＴＣＰ制御部３に渡され、ＴＣＰ制御部３からペイロード・データＤｐがアプリケーション・バッファ１０１に渡されるまでの処理は上述の通りである。なお、ＴＣＰ制御部３は、さらに、正当と判断されたパケットのペイロード・データ長を算出する。そしてＴＣＰ制御部３は、算出されたペイロード・データ長ＰＬＤ＿ＬＥＮを経路Ｃ７５１を介して、ウィンドウ・サイズ算出部７０１に渡す。
【００５２】
アプリケーション部３００において、アプリケーション・バッファ１０１は経路Ｃ２０５より受け取ったペイロード・データＤｐをバッファリングする。Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２は、経路Ｃ３００を介して、アプリケーション・バッファ１０１がバッファリングしているデータ量（使用量Ｖｂ）に基づいて、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔを生成して、ウィンドウ・サイズ算出部７０１にフロー制御指示として通知することは上述の通りである。
【００５３】
ウィンドウ・サイズ算出部７０１では、フロー制御指示（Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔ）を参照して、受信可能である適切なウィンドウ・サイズＸを決定する。そして、決定されたウィンドウ・サイズＸが上述のウィンドウ・サイズＸ１、Ｘ２、およびＸ３として、パケットの送信元であるＴＣＰ送信端末装置２６０に通知されることにより、ＴＣＰパケット伝送のフロー制御が行われる。
【００５４】
以下に、ウインドウ・サイズ算出部７０１によるウィンドウ・サイズＸの算出方法について説明する。ＴＣＰ制御部３よりＰＬＤ＿ＬＥＮを受け取ると、ウインドウ・サイズ算出部７０１は最大ウィンドウ・サイズ保持部７００より通知されたＷｉｎ＿ＳＺ（ｍａｘ）とアプリケーション部３００より通知されたＡｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔとを参照し、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの状態に応じて、以下に述べるルールに従ってウィンドウ・サイズＣｕｒ＿Ｗｉｎ＿ＳＺを算出する。
【００５５】
＜ルール１＞
Ａｌｍｏｓｔ＿Ｆｕｌｌ＿Ｓｔが０、つまりアプリケーション部３００の使用量Ｖｂは閾値Ｔｈ未満である場合、アプリケーション部３００（アプリケーション・バッファ１０１）では、最大ウィンドウ・サイズＷｉｎ＿Ｓｚ（Ｍａｘ）以上にペイロード・データＤｐを受入可能である。この場合、ウィンドウ・サイズＣｕｒ＿Ｗｉｎ＿ＳＺは次式（２）で表すように設定される。
Ｃｕｒ＿Ｗｉｎ＿ＳＺ  ＝  Ｗｉｎ＿ＳＺ（ｍａｘ）・・・・（２）
【００５６】
＜ルール２＞
Ａｌｍｏｓｔ＿Ｆｕｌｌ＿Ｓｔが１、つまりアプリケーション部３００の使用量Ｖｂが閾値Ｔｈ以上である場合、アプリケーション部３００（アプリケーション・バッファ１０１）では、最大ウィンドウ・サイズＷｉｎ＿Ｓｚ（Ｍａｘ）を上限としてペイロード・データＤｐを受入可能である。ただし、ペイロード・データＤｐを受け取る度に、アプリケーション部３００が受け入れることができるペイロード・データＤｐの数は小さくなる。この場合、ウィンドウ・サイズＣｕｒ＿Ｗｉｎ＿ＳＺは次式（３）で表すように設定される。
Ｃｕｒ＿Ｗｉｎ＿ＳＺ  ＝  Ｗｉｎ＿ＳＺ（ｍａｘ）−ＰＬＤ＿ＬＥＮ（ｓｕｍ）
・・・・  （３）
なお、ＰＬＤ＿ＬＥＮ（ｓｕｍ）は、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿Ｓｔにより、アプリケーション・バッファ１０１の使用量Ｖｂが閾値Ｔｈ以上である場合のＰＬＤ＿ＬＥＮを累計した値である。
【００５７】
あるいは、次式（４）で表すように設定される。
Ｃｕｒ＿Ｗｉｎ＿ＳＺ  ＝Ｏｌｄ＿Ｗｉｎ＿ＳＺ−ＰＬＤ＿ＬＥＮ
・・・・  （４）
なお、Ｏｌｄ＿Ｗｉｎ＿ＳＺは、前の回設定されたＣｕｒ＿Ｗｉｎ＿ＳＺの値である。
【００５８】
このようにして、ウインドウ・サイズ算出部７０１によって求められたＣｕｒ＿Ｗｉｎ＿ＳＺは、ＴＣＰ制御部３によってウィンドウ・サイズＸ２として参照されて、確認応答ＡＣＫ２５０が生成される。以降、同様にして、確認応答ＡＣＫ２５１が生成されてデータの送受信処理が行われる。
【００５９】
次に、図２を参照して、ウィンドウ・サイズ算出部７０１による、ウィンドウ・サイズの算出方法について説明する。図２において、横軸は時刻ｔを示し、各実線は、上段からアプリケーション・バッファ１０１の使用量Ｖｂ、Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２のＡｌｍｏｓｔ＿ｆｕｌｌ＿ｓｔ、およびウインドウ・サイズ算出部７０１が設定するウィンドウ・サイズＸの時刻ｔに対する遷移状態を表している。なお、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値が０の場合はアプリケーション・バッファ１０１の使用量Ｖｂは閾値Ｔｈ未満であり、１である場合はアプリケーション・バッファ１０１の使用量Ｖｂは閾値Ｔｈ以上である。
【００６０】
Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値は、時刻ｔ０から０を維持して、時刻ｔ１において１になる。時刻ｔ０から時刻ｔ１迄のＡｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値が０である期間をＦ１とする。時刻ｔ１以降は、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値は１を維持して、時刻ｔ３で再び０になる。このＡｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値が１である期間のうち時刻ｔ１からアプリケーション・バッファ１０１の使用量Ｖｂが最大になる時刻ｔ２までの期間をＦ２、時刻ｔ２からＡｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値が再び０になる時刻ｔ３までの期間をＦ３とする。
【００６１】
Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔが０となる期間Ｆ１においては、アプリケーション・バッファ１０１の使用量Ｖｂは増加傾向にあるが閾値Ｔｈに達していない。よって、ウィンドウ・サイズＸは最大ウィンドウ・サイズＷｉｎ＿Ｓｚ（Ｍａｘ）である。
【００６２】
期間Ｆ２においては、アプリケーション・バッファ１０１の使用量Ｖｂは閾値Ｔｈを超えることから、のＡｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔの値は１となり、ウィンドウ・サイズＸは減少する。アプリケーション・バッファ１０１の使用量Ｖｂが増加すれば、ウィンドウ・サイズＸは最終的に、時刻ｔ２に０になる。この時点でアプリケーション・バッファ１０１の使用量Ｖｂは減少に転じる。
【００６３】
期間Ｆ３においては、アプリケーション・バッファ１０１には新たなデータが蓄積されることなく、アプリケーション・バッファ１０１からは既に蓄積されているデータが読み出されて処理されていくだけである。よって、のアプリケーション・バッファの使用量Ｖｂは時刻ｔ２より減少していき、時刻ｔ３に閾値Ｔｈに達する。それに伴い、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔが０になり、ウィンドウ・サイズＸは最大ウィンドウ・サイズＷｉｎ＿Ｓｚ（Ｍａｘ）に設定される。
【００６４】
そして、時刻ｔ３に設定されたウィンドウ・サイズＸ（Ｗｉｎ＿Ｓｚ（ｍａｘ））に応答して、アプリケーション・バッファ１０１のバファリングが再開して、使用量Ｖｂが再び閾値Ｔｈを超える。そして、Ａｌｍｏｓｔ＿ｆｕｌｌ＿ｓｔも１に設定される。結果、期間Ｆ２におけるのと同様に、ウィンドウ・サイズＸは減少していく。
【００６５】
上述のように、アプリケーション・バッファ１０１の使用量Ｖｂに基づいて、送信元のサーバ１００に返信する確認応答ＡＣＫのウィンドウ・サイズＸが制御されて、送信元のサーバ１００に対するフロー制御が行われる。結果、ＴＣＰ受信端末２６５でのバッファのオーバー・ランが防止されて、効率の良いデータ伝送が可能となる。
【００６６】
さらに、従来のＴＣＰ受信端末装置においては、ウィンドウ・サイズＸはパケット単位でバッファリングする受信バッファのサイズに基づいて決定されている。そのために、ウィンドウ・サイズＸを大きくするためには、用いる受信バッファの容量も大きくする必要がある。しかしながら、本発明においては、ウィンドウ・サイズＸはペイロード・データ単位でバッファリングするアプリケーション・バッファのサイズに基づいて決定される。つまり、ウィンドウ・サイズＸによるフロー制御のために必要とされて受信バッファは不要である。また、アプリケーション・バッファに要求される容量は、受信バッファに要求される容量よりも小さくので、ＴＣＰ受信端末装置におけるバッファ容量を最小にすることができる。
【００６７】
（第２の実施の形態）
図３を参照して、本発明の第２の実施の形態にかかるＴＣＰ受信端末装置について説明する。本例におけるＴＣＰ受信端末装置２６５＿２は、図１に示したＴＣＰ受信端末装置２６５＿１において、ＣＰＵ７１０ａがＣＰＵ７１０ｂに交換されている。それに伴い、ウインドウ・サイズ算出部７０１をＡｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２に接続していた経路Ｃ３０１が取り除かれて、ウインドウ・サイズ算出部７０１をＣＰＵ７１０ｂに接続する経路Ｃ７６２が設けられている。
【００６８】
結果、Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部１０２で生成されたＡｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔは経路Ｃ７６１を介して、ウインドウ・サイズ算出部７０１ではなく、ＣＰＵ７１０ｂに渡される。ＣＰＵ７１０ｂは、Ａｌｍｏｓｔ＿Ｆｕｌｌ＿ｓｔに基づいて、ＴＣＰ送信端末装置２６０に対するフロー制御信号Ｓｃを生成する。フロー制御信号Ｓｃは、経路Ｃ７６２を介して、ウインドウ・サイズ算出部７０１に渡される。このように構成することによって、本実施の形態においては、アプリケーション・バッファ１０１の使用量Ｖｂに応じてダイレクトに変化するＡｌｍｏｓｔ＿Ｆｕｌｌ＿Ｓｔに対して処理を加えることにより、さらに細やかなフロー制御が可能である。
【００６９】
つまり、本発明によれば、ＴＣＰ受信端末装置内に大容量のＴＣＰバッファを必要とせず、バッファを最小容量にでき、コストを安くできる。さらに、ウィンドウ・サイズをシステム要件、ネットワーク環境に合わせ、柔軟対応可能となり、かつ、ＴＣＰ受信端末装置内のバッファにてパケットの損失は発生せず、ネットワーク負荷をかけずに効率よく伝送できる。
【００７０】
以上、ＴＣＰ通信プロトコルを用いるＴＣＰ受信端末装置を例に、本発明にかかる実施の形態について具体的に説明した。しかしながらこれらの記述は本発明の適用の範囲を限定するものでは無く、その他フロー制御を行う同様のプロトコルにおいても適用可能である。
【産業上の利用可能性】
【００７１】
本発明は、ＴＣＰ通信プロトコルおよびＴＣＰ通信プロトコルと同様のフロー制御をおこなう通信プロトコルを使用するネットワーク伝送に柔軟に対応できる。具体的には、そのようなネットワークに接続される家電製品やモバイル端末等の用途に有用である。
【図面の簡単な説明】
【００７２】
【図１】本発明の第１の実施の形態にかかるＴＣＰ受信端末装置の構成を表すブロック図
【図２】図１に示すウィンドウ・サイズ算出部による、ウィンドウ・サイズの算出方法の説明図
【図３】本発明の第２の実施の形態にかかるＴＣＰ受信端末装置の構成を表すブロック図
【図４】ストリーミング配信ネットワークの構成図
【図５】ＴＣＰ通信プロトコルによるデータ伝送シーケンス図
【図６】ＴＣＰ通信プロトコルに用いられるパケットヘッダの説明図
【図７】従来のＴＣＰ受信端末装置の構成の一例を示すブロック図
【図８】従来のＴＣＰ受信端末装置の構成の更なる例を示すブロック図
【図９】ＴＣＰ通信プロトコルによるデータ伝送の伝送性能の説明図
【符号の説明】
【００７３】
ＮＷ    ストリーミング配信ネットワーク
１００、１００＿１、１００＿２、１００＿３  サーバ
１０００    インターネット
１００４    ルータ
２０００    宅内ネットワーク
２００    ＡＶ機器
２００＿１    デジタルＴＶ
２００＿２    デジタル・ビデオ録画機
２００＿３    オーディオ機器
２００＿４    ＰＣ
２６０    ＴＣＰ送信端末装置
２６５ａ、２６５ｂ、２６５＿１、２６５＿２    ＴＣＰ受信端末装置
３００    アプリケーション部
１    送受信部
２    ＩＰ制御部
３、３ａ、３ｂ    ＴＣＰ制御部
４    ペイロード出力部
３０    ＴＣＰ受信バッファ
３１    ウィンドウ・サイズ算出部
１０１    アプリケーション・バッファ
１０２    Ａｌｍｏｓｔ＿Ｆｕｌｌ検出部
４０１    バッファ量推定部
４０２    ＲＷＩＮ制御部
７００    最大ウィンドウ・サイズ保持部
７０１    ウィンドウ・サイズ算出部
【図１】
2009071766.tif 000003
【図２】
2009071766.tif 000004
【図３】
2009071766.tif 000005
【図５】
2009071766.tif 000006
【図６】
2009071766.tif 000007
【図７】
2009071766.tif 000008
【図８】
2009071766.tif 000009
【図９】
2009071766.tif 000010
【図４】
2009071766.tif 000011