ネットワーク端末装置およびデータ伝送方法
【課題】ネットワークを介してデータ伝送を行うネットワーク端末装置およびそのデータ伝送方法において、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行えるようにすること。
【解決手段】このネットワーク端末装置は、無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部２１１と、データリンク層処理部２１１を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部２１３と、データリンク層処理部２１１のデータ伝送の状況を表わす第２層情報と、トランスポート層処理部２１３のデータ伝送の状況を表わす第４層情報と、に基づいてネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部Ｓ８０４と、判別された輻輳箇所に基づいてトランスポート層処理部の伝送レートを調整する伝送レート制御部２３３と、を具備する。
【解決手段】このネットワーク端末装置は、無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部２１１と、データリンク層処理部２１１を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部２１３と、データリンク層処理部２１１のデータ伝送の状況を表わす第２層情報と、トランスポート層処理部２１３のデータ伝送の状況を表わす第４層情報と、に基づいてネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部Ｓ８０４と、判別された輻輳箇所に基づいてトランスポート層処理部の伝送レートを調整する伝送レート制御部２３３と、を具備する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してデータ伝送を行うネットワーク端末装置およびそのデータ伝送方法に関する。
【背景技術】
【０００２】
近年、インターネットおよび宅内ネットワークを介して、送信側端末から受信側端末へＡＶ（Audio Visual）コンテンツデータを伝送するストリーミングサービスが、普及している。ストリーミングサービスにおいて、受信側端末は、ＡＶコンテンツデータを受信しながらこのＡＶコンテンツの再生を行う。
【０００３】
ここでは、このストリーミンクサービスが、次のネットワーク構成で提供される場合を検討する。次のネットワーク構成とは、受信側端末が無線を介して隣接する通信ノードと接続され、隣接する通信ノードと送信側端末とがコアネットワークを介して接続されている構成である。上記隣接する通信ノードは、例えば、アクセスポイント（ＡＰとも呼ぶ）である。上記コアネットワークは、インターネットなどを含む、主に有線のネットワークである。
【０００４】
ＡＶコンテンツデータは、このようなネットワーク構成で伝送される場合、有線区間の輻輳（混雑とも呼ぶ）により、その伝送レートが低下することがある。また、ＡＶコンテンツデータは、無線区間の一時的な障害により、その伝送レートが一時的に低下することがある。無線区間の一時的な障害には、アクセスの集中による輻輳の場合と、無線ノイズによる場合とがある。特に区別しない場合には、これらの場合をまとめて輻輳と呼ぶ。
【０００５】
有線区間と無線区間とでは、データ伝送に関する性質が、次のように異なる。有線区間では、個々の通信ノード間の伝送特性は安定しており、物理層およびＭＡＣ（Media Access Control）層での障害または伝送パケットの損失は生じにくい。また、有線区間では、ネットワークが輻輳（混雑とも呼ぶ）して、中継ノードで処理の限界を超えるトラフィックが生じた場合、中継ノードでバッファオーバーフローが生じて、伝送パケットの損失（パケットロスとも呼ぶ）が発生する。また、有線区間の輻輳は、一般に復帰に時間がかかる。
【０００６】
一方、無線区間では、ノイズまたは電波干渉等により伝送特性が一時的に不安定になることがあり、伝送パケットの損失および伝送エラーも頻繁に起きる。電波の干渉または衝突は、無線区間にある機器の無線メディアへのアクセスを遅延させ、送信側端末と受信側端末との間（端末間、或いは、エンド・ツー・エンド（Ｅ２Ｅ）とも呼ぶ）の伝送遅延を増大させる。
【０００７】
また、無線区間では、無線機器のデータリンク層（第２層、Ｌ２（レイヤー２）とも呼ぶ）の再送制御によって、伝送遅延が増大することがある。例えば、ＩＥＥＥ８０２．１１（非特許文献１０を参照）のような幾つかの無線アクセス技術は、再送制御をサポートする。このような無線アクセス技術を利用している環境において、データパケットが無線送信中に失われた場合に、中継ノード（アクセスポイントなど）は、データリンク層の処理で再送を数回試行する。この再送の試行の結果、エンド・ツー・エンドの伝送遅延は増加する場合がある。
【０００８】
また、無線区間の障害は、一時的なものであるか、あるいは短時間に変動することが多く、また、障害がなくなれば復帰は早い。
【０００９】
従来、送信側端末と受信側端末との間の伝送レートは、送信側端末および／または受信側端末のトランスポート層（第４層、Ｌ４（レイヤー４）とも呼ぶ）の制御によって、調整されるのが一般的であった。また、この伝送レートは、有線区間の輻輳に合わせて調整されるのが一般的であった。
【００１０】
具体的には、有線区間において輻輳が生じると、エンド・ツー・エンドのデータ伝送が失敗する。そのため、送信側端末および／または受信側端末は、端末間の伝送レートを低くして、データ伝送の失敗を回避する。このレート制御によりネットワークトラフィックが緩和されると、送信側端末および／または受信側端末は、端末間の伝送レートを緩やかに回復していく。非特許文献１〜４には、このような輻輳に対するレート制御の様々な手法が開示されている。
【００１１】
また、有線区間と無線区間とを有するネットワークにおいて、無線区間の障害を検出する技術については、従来から幾つかの手法が提案されている。
【００１２】
例えば、非特許文献５には、伝送エラーがあった場合に、有線区間のエラーか無線区間のエラーかを区別する技術が開示されている。具体的には、非特許文献５では、トランスポート層のフィードバック情報に含まれるＲＯＴＴ（Round-Trip Time：片方向データ到達時間）に基づいて、有線区間のエラーか無線区間のエラーかを区別している。また、非特許文献５に開示の送信端末は、ＲＯＴＴが大きくなっていれば有線区間の輻輳エラーであると判別し、ＲＯＴＴが小さくなっていれば無線区間のリンクエラーであると判別する。また、無線区間のリンクエラーであると判別された場合は、ＢＬＲ（Beacon Loss Rate：ビーコンロス率）を評価して、無線衝突（混雑）によるリンクエラーか無線ノイズによる伝送エラーかを判別することが開示されている。
【００１３】
また、非特許文献６には、無線アクセスポイントのデータリンク層処理部に、フィードバック情報を送信端末へ送信する機能を設けた構成が開示されている。非特許文献６には、この情報に基づいて、無線区間における伝送データの損失の発生理由を推定することが開示されている。具体的には、無線アクセスポイントのデータリンク層処理部は、ＳＮＲ（信号対雑音比）などのＭＡＣ層情報を送信端末へフィードバックする。送信端末は、この情報に基づいて、伝送データの損失が、無線区間における無線衝突（混雑）によるものか、無線ノイズによる伝送エラーかを判別する。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】M. Allman, V. Paxson, and E. Blanton, "TCP Congestion Control", IETF RFC 5681, September 2009, <http://tools.ietf.org/html/rfc5681>
【非特許文献２】Lawrence S. Brakmo, and Larry L. Peterson, "TCP Vegas: End to End Congestion Avoidance on a Global Internet", IEEE Journal on Selected Areas in Communications, vol. 13, No. 8, October 1995, pp. 1465-1480
【非特許文献３】Claudio Casetti, Mario Gerla, Saverio Mascolo, M. Yahya Sanadidi, and Ren Wang, "TCP Westwood: End-to-End Bandwidth Estimation for Enhanced Transport over Wireless Links", Wireless Networks Journal 8, 2002, pp. 467-479
【非特許文献４】Lisong Xu, Harfoush K., Injong Rhee, "Binary Increase Congestion Control (BIC) for fast long-distance networks", Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM 2004, vol. 4, November 2004, pp. 2514-2524
【非特許文献５】Sangheon Pack, Xuemin (Sherman) Shen, IEEE, Jon W. Mark, Life Fellow, and Lin Cai., "A Two-Phase Loss Differentiation Algorithm for Improving TFRC Performance in IEEE 802.11 WLANs", IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 6, NO. 11, NOVEMBER 2007, pp. 4164
【非特許文献６】Stephane Lohier, Yacine Ghamri Doudane and Guy Pujolle, "Cross-layer loss differentiation algorithms to improve TCP performance in WLANs", Telecommunication Systems Volume 36, Numbers 1-3, pp. 61-72
【非特許文献７】Jon Postel Ed.,"TRANSMISSION CONTROL PROTOCOL", RFC793, <http://www.ietf.org/rfc/rfc793.txt>
【非特許文献８】E. Kohler, M. Handley, S. Floyed, "Datagram Congestion Control Protocol (DCCP)", RFC4340, <http://www.rfc-editor.org/rfc/rfc4340.txt>
【非特許文献９】S. Stewart, et al. "Stream Control Transmission Protocol", RFC2960, <http://www.ietf.org/rfc/rfc2960.txt>
【非特許文献１０】IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, <http://standards.ieee.org/getieee802/download/802.11-2007.pdf>
【非特許文献１１】IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Enhancements for Higher Throughput, <http://standards.ieee.org/getieee802/download/802.11n-2009.pdf>
【発明の概要】
【発明が解決しようとする課題】
【００１５】
しかしながら、上記従来のレート制御では、次のような課題が生じる。すなわち、通常のレート制御（例えば非特許文献１〜４のレート制御）では、伝送パケットの損失または遅延が有線区間の輻輳によるものか無線区間の障害によるものか区別できない。つまり、無線区間の一時的な障害に対しても、有線区間の輻輳に対ししても、通常のレート制御では、同じレート制御のアルゴリズムが使用される。そのため、上記従来のレート制御では、パケットロス等が検知された場合に、伝送レートが不必要に低くされてしまうことがある。この場合には、ネットワークのスループットが不必要に低下して、エンド・ツー・エンドの通信品質が低下する。
【００１６】
また、通常のレート制御では、ネットワークの輻輳の悪化を防ぐために、輻輳が回復されてきた場合に、伝送レートは緩やかに上げられる。そのため、通常のレート制御では、無線区間の一時的な障害（例えば電子レンジの使用による無線ノイズの発生）により伝送パケットが一時的に損失した場合でも、この障害が取り除かれた後の伝送レートの回復が無駄に遅くなる。
【００１７】
さらに、通常のレート制御では、無線区間で小規模な障害が多発する場合に、上記のような伝送レートの調整が繰り返される。その結果、エンド・ツー・エンドの伝送レートは、実際にデータ伝送可能なレートよりもずっと低い伝送レートで滞ってしまうという課題が生じる。この場合、無線リソースは十分に利用されず、エンド・ツー・エンドのネットワーク帯域は、本来利用できる帯域よりもずっと狭いままとなる。
【００１８】
また、無線区間の障害を検知する非特許文献５，６の技術では、次のような課題がある。すなわち、非特許文献５の技術では、ＲＯＴＴの変化情報などのトランスポート層の情報のみで、伝送エラーの発生箇所が有線区間か無線区間かを判別している。そのため、この技術では、伝送エラーの発生箇所を正確に判別できないという課題がある。例えば、ＲＯＴＴは、無線区間のリアルタイムの伝送状況を正確に反映するほど詳細な情報でない。つまり、無線区間の伝送状況の変化に対して、ＲＯＴＴは、追従性よく変動しない。それゆえ、ＲＯＴＴの変化情報だけでは、無線区間の一時的な障害または短時間の変動を正確に判別できない。
【００１９】
また、非特許文献６の技術では、アクセスポイントから送信端末へフィードバック情報を送信する構成が必要となる。具体的には、非特許文献６の技術では、アクセスポイントおよび送信側端末のプロトコルに、ネットワーク階層をまたぐ（クロスレイヤとも呼ぶ）シグナリングプロトコル（帯域予約のための信号交換プロトコル）を、追加する必要が生じる。つまり、非特許文献６の技術では、送信側端末と受信側端末の改変だけではなく、アクセスポイントの改変が必要となる。したがって、この非特許文献６の技術では、例えば、公衆無線ＬＡＮ（ローカルエリアネットワーク）を利用したシステムなど、アクセスポイントがネットワークインフラの一部となっているシステムに対して適用困難であるという課題がある。
【００２０】
この発明の目的は、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行うようにすることである。
【課題を解決するための手段】
【００２１】
本発明の一態様に係るネットワーク端末装置は、ネットワークを介してデータ伝送を行うネットワーク端末装置であって、無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部と、前記データリンク層処理部を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部と、前記データリンク層処理部のデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理部のデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部と、判別された前記輻輳箇所に基づいて前記トランスポート層処理部の伝送レートを調整する伝送レート制御部と、を具備する構成を採る。
【００２２】
本発明の一態様に係るデータ伝送方法は、ネットワークを介してデータ伝送を行うデータ伝送方法であって、無線を介して接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理ステップと、前記データリンク層処理ステップを介して端末ノード間のデータ伝送処理を行うトランスポート層処理ステップと、前記データリンク層処理ステップでのデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理ステップでのデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別ステップと、判別された前記輻輳箇所に基づいて前記トランスポート層処理ステップでの伝送レートを調整する伝送レート制御ステップと、を含む構成を採る。
【発明の効果】
【００２３】
本発明によれば、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行うことができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施の形態１のネットワーク端末装置が加わるネットワーク構成の一例を示す図
【図２】本発明の実施の形態１のネットワーク端末装置である受信側端末の要部を示すブロック図
【図３】図１の各装置の論理的構成を示すブロック図
【図４】本発明の実施の形態１のレート制御の手順を示すフローチャート
【図５】実施の形態１におけるネットワーク輻輳位置の識別パターンと伝送方針の決定パターンとの一例を示す図表
【図６】実施の形態１におけるリカバリスケジュールの補償パターンの一例を示す図表
【図７】実施の形態１におけるデータリンク層のリトライ率の算出方法を説明する図
【図８】本発明の実施の形態２のネットワーク端末装置が加わるネットワーク構成の一例を示す図
【図９】本発明の実施の形態２のネットワーク端末装置である送信側端末の要部を示すブロック図
【図１０】図８の各装置の論理的構成を示すブロック図
【図１１】本発明の実施の形態２のレート制御の手順を示すフローチャート
【発明を実施するための形態】
【００２５】
以下、本発明の各実施の形態について図面を参照して詳細に説明する。
【００２６】
（実施の形態１）
図１は、本発明の実施の形態１のネットワーク端末装置が加わるネットワーク構成の一例を示す図である。
【００２７】
実施の形態１のネットワーク構成には、図１に示すように、送信側端末１０１と、エッジネットワーク１１１，１１３と、コアネットワーク１０２と、アクセスポイント１０５と、受信側端末１０３とが含まれる。
【００２８】
送信側端末１０１は、ネットワークを介してデータを送信する情報端末である。エッジネットワーク１１１は、送信側端末１０１が接続される有線区間のネットワークである。コアネットワーク１０２は、インターネットなどを含み、送信側端末１０１と受信側端末１０３との間に位置する主に有線のネットワークである。エッジネットワーク１１３は、アクセスポイント１０５と受信側端末１０３を接続する無線区間のネットワークである。アクセスポイント１０５は、エッジネットワーク（無線区間）１１３とコアネットワーク１０２の間に位置し、無線・有線のネットワークブリッジとして機能する。受信側端末１０３は、ネットワークを介して送信側端末１０１からデータを受信する情報端末である。
【００２９】
実施の形態１のネットワーク上で伝送されるデータには、データパケット１２１と、フィードバックパケット１２３とが含まれる。
【００３０】
データパケット１２１は、例えばＡＶストリーミングデータなどであり、送信側端末１０１から受信側端末１０３へ向けて送信される。フィードバックパケット１２３は、データパケット１２１の伝送に対する応答および伝送制御用のデータを含み、受信側端末１０３から送信側端末１０１へ送信される。
【００３１】
なお、図１では、ネットワークの詳細な構成要素が省略されているが、これらの構成要素が存在し得ることは当業者にとって明らかである。しかし、これらの構成要素は、本発明の概念に影響するものでない。
【００３２】
図２は、本発明に係るネットワーク端末装置の一実施の形態である受信側端末１０３の要部構成図である。
【００３３】
受信側端末１０３は、受信側データリンク層処理部２１１と、受信側トランスポート層処理部２１３と、輻輳箇所判別部２３５ａと、伝送レート制御部２３５ｂと、実効レート算出部２３３ａとを備える。
【００３４】
受信側データリンク層処理部２１１は、受信側端末１０３におけるネットワーク処理のうち、データリンク層の処理を行う。受信側トランスポート層処理部２１３は、受信側端末１０３のネットワーク処理のうち、トランスポート層の受信処理を行う。
【００３５】
実効レート算出部２３３ａは、受信側データリンク層処理部２１１の実効ビットレートを算出する。ここで、算出される実効ビットレートは、受信側データリンク層処理部２１１の再送制御に伴う伝送効率の低下を考慮した実効的な伝送レートである。算出された実効ビットレートの情報は、伝送レート制御部２３５ｂへ送られる。
【００３６】
輻輳箇所判別部２３５ａは、受信側データリンク層処理部２１１の伝送状況を表わすデータリンク層情報と、受信側トランスポート層処理部２１３の伝送状況を表わすトランスポート層情報とに基づいて、ネットワークの輻輳箇所を判別する。データリンク層情報は、本発明に係る第２層情報の一実施形態であり、トランスポート層情報は、本発明に係る第４層情報の一実施形態である。判別結果の情報は、伝送レート制御部２３５ｂへ送られる。
【００３７】
伝送レート制御部２３５ｂは、輻輳箇所の判別結果の情報と、実効ビットレートの情報とを受けて、これらの情報に基づき、トランスポート層の伝送レートを調整する制御を行う。
【００３８】
なお、続いて示される図３の具体的な構成例において、実効レート算出部２３３ａは、受信側データリンクレート制御部２３３に含まれている。しかし、実効レート算出部２３３ａは、受信側データリンクレート制御部２３３と別に設けられても良い。また、図３の具体的な構成例において、輻輳箇所判別部２３５ａと伝送レート制御部２３５ｂとは、図３の受信側トランスポートレート制御部２３５に含まれている。しかし、輻輳箇所判別部２３５ａと伝送レート制御部２３５ｂとは、受信側トランスポートレート制御部２３５と別に設けられても良い。
【００３９】
続く説明では、ネットワークの各ノードが、非特許文献７に示されるＴＣＰ（Transmission Control Protocol）を使用して、データ伝送を行う例を示している。しかし、データ伝送のためのプロトコルは、送信データのレート制御と受信側から送信側へのフィードバックが可能であれば、その他のプロトコルを適用可能である。このことは当業者にとって明らかであり、本発明の概念に影響するものでない。その他のプロトコルとしては、例えば、非特許文献８に示されるＤＣＣＰ（Datagram Congestion Control Protocol）が適用できる。または、その他のプロトコルとしては、非特許文献９に示されるＳＣＴＰ（Stream Control Transmission Protocol）が適用できる。
【００４０】
図３は、図１の各装置の論理的構成を示すブロック図である。
【００４１】
送信側端末１０１は、図３に示すように、送信側アプリケーション２４０と、送信側トランスポート層処理部２０１と、送信側トランスポートレート制御部２３１と、送信側データリンク層処理部２０３と、を備える。
【００４２】
送信側アプリケーション２４０は、データの送信要求と指示とを行う。送信側トランスポート層処理部２０１は、送信側端末１０１におけるネットワーク処理のうち、トランスポート層の伝送処理を行う。送信側トランスポートレート制御部２３１は、送信側端末１０１における送信側トランスポート層処理部２０１において、送信側のトランスポート層のレート制御と必要な情報取得処理とを行う。送信側データリンク層処理部２０３は、送信側端末１０１におけるネットワーク処理のうち、データリンク層の伝送処理を行う。
【００４３】
受信側端末１０３は、図３に示すように、受信側アプリケーション２４１と、受信側トランスポート層処理部２１３と、受信側トランスポートレート制御部２３５と、受信側データリンク層処理部２１１と、受信側データリンクレート制御部２３３と、を備える。
【００４４】
受信側アプリケーション２４１は、データの受信要求と指示とを行う。受信側トランスポート層処理部２１３は、図２にも示したが、受信側端末１０３のネットワーク処理のうち、トランスポート層の受信処理を行う。受信側トランスポートレート制御部２３５は、受信側端末１０３における受信側トランスポート層処理部２１３において、受信側のトランスポート層のレート制御と必要な情報取得処理とを行う。受信側データリンク層処理部２１１は、図２にも示したが、受信側端末１０３におけるネットワーク処理のうち、データリンク層の処理を行う。受信側データリンクレート制御部２３３は、受信側端末１０３の受信側データリンク層処理部２１１において、受信側データリンクのレート見積もりと必要な情報取得処理とを行う。これらの構成のうち、受信側トランスポートレート制御部２３５は、本発明に係る伝送レート制御部の一実施形態である。
【００４５】
アクセスポイント１０５は、図３に示すように、ブリッジ機構２０７と、無線リンク層処理部２０９と、有線リンク層処理部２０５と、を備える。
【００４６】
ブリッジ機構２０７は、無線ネットワークと有線ネットワークの間のネットワークブリッジ機能の処理を行う。無線リンク層処理部２０９は、ブリッジ機構２０７のうち無線ネットワークのデータリンク層の処理を行う。有線リンク層処理部２０５は、ブリッジ機構２０７のうち有線ネットワークのデータリンク層の処理を行う。
【００４７】
アクセスポイント１０５の無線リンク層処理部２０９には、伝送されるデータパケット（省略して「パケット」とも呼ぶ）１２１を一時的に保持するバッファが設けられている。アクセスポイント１０５は、一方から他方へデータパケットを転送する際、他方のネットワークに輻輳が生じてデータパケットを送出できない場合に、このデータパケットをバッファに一時的に蓄える。そして、アクセスポイント１０５は、他方のネットワークの輻輳が回復したら、バッファに蓄えたデータパケットを他方のネットワークを介して転送する。このバッファの作用により、アクセスポイント１０５は、ネットワークの一時的な輻輳に対して、データパケットの損失をある程度回避することができる。
【００４８】
次に、上記のネットワーク構成において、データの伝送処理の流れについて説明する。
【００４９】
送信側端末１０１は、送信側トランスポート層処理部２０１から送信側データリンク層処理部２０３を介して、アクセスポイント１０５へ向けてデータパケット１２１を送信する。アクセスポイント１０５の有線リンク層処理部２０５は、データパケット１２１を受信し、ブリッジ機構２０７を通じて、データを無線リンク層処理部２０９へ中継する。アクセスポイント１０５は、無線リンク層処理部２０９と受信側端末１０３の受信側データリンク層処理部２１１を介して、無線リンクを通じてデータパケット１２１を受信側端末１０３へ送信する。受信側データリンク層処理部２１１は、受信側端末１０３内の受信側トランスポート層処理部２１３へデータパケット１２１を転送する。
【００５０】
アクセスポイント１０５と受信側端末１０３とは、エッジネットワーク１１３で無線の輻輳または衝突により伝送エラーが生じると、データ再送を試行する。このデータ再送は、受信側データリンク層処理部２１１と無線リンク層処理部２０９とにより、データリンク層の伝送処理として実行される。
【００５１】
また、受信側トランスポート層処理部２１３と送信側トランスポート層処理部２０１とは、ネットワークの混雑状況に応じて、まとめて伝送するデータ量、すなわち、１回の確認応答を必要とする伝送データの量を変化させる。一般には、このデータ量の可変制御をウインドウ制御と呼び、ひとまとめのデータを受けるバッファのことをウインドウバッファと呼ぶ。また、このひとまとめのデータ量は、ウインドウサイズと呼ぶ。
【００５２】
上記のデータ伝送中、コアネットワーク１０２またはエッジネットワーク１１１，１１３に何らかの障害が起きて伝送エラーが生じると、送信側トランスポートレート制御部２３１は、伝送エラーが生じないレベルに伝送レートを低くする。
【００５３】
また、ネットワークの障害が取り除かれて伝送レートが回復可能になったときには、次に示すレート制御を行う。つまり、受信側トランスポートレート制御部２３５と送信側トランスポートレート制御部２３１とは、協働し、次に示すレート制御により伝送レートの回復を図る。
【００５４】
次に、実施の形態１におけるレート制御について、説明する。
【００５５】
図４は、実施の形態１の受信側端末１０３と送信側端末１０１とにより行われるレート制御の手順を示すフローチャートである。
【００５６】
図４のレート制御は、通常のデータ伝送の進行中に行われる。具体的には、図４のレート制御は、送信側端末１０１からＡＶストリーミングデータを受信する通信セッションの開始から終了までを通して、定期的に繰り返し実行される。或いは、図４のレート制御は、トランスポート層情報またはデータリンク層情報に基づきネットワーク状況に変化が検出された際に実行されるようにしてもよい。また、図４のレート制御は、データパケットの損失が生じた場合には、高い頻度で実行され、データパケットの損失がない場合には、低い頻度で実行されるようにしてもよい。
【００５７】
なお、図４のレート制御の処理のうちステップＳ８０７〜Ｓ８０９の処理は、ネットワーク状況が輻輳から回復する際に実行される処理である。ネットワーク状況が輻輳へ陥る際に実行されるレート制御の処理では、ステップＳ８０７は省略され、ステップＳ８０８，Ｓ８０９の「リカバリスケジュール」は、単に「伝送レートのスケジュール」に変更される。
【００５８】
ステップ８０１において、受信側データリンクレート制御部２３３は、可変ウインドウバッファを用いてデータリンク層のリトライ率を算出する。
【００５９】
ここで、リトライ率とは、アクセスポイント１０５と受信側端末１０３との間で行われるデータリンク層におけるデータ再送制御の試行率である。また、可変ウインドウバッファとは、上述したトランスポート層のウインドウ制御におけるウインドウサイズに対応させて、サイズが変化するリトライ率算出用のバッファである。リトライ率の算出方法の詳細は後述する。
【００６０】
次に、ステップＳ８０２において、受信側データリンクレート制御部２３３は、データリンク層のリトライ率を用いて、データリンク層の実効ビットレートを概算する。ここで、実効ビットレートとは、データリンク層における伝送レートを表わすもので、データリンク層からトランスポート層へ転送される有効なデータ（ペイロードデータなど）の伝送レートである。受信側データリンクレート制御部２３３は、トランスポート層のフィードバックパケット１２３のやり取り、および、データリンク層の再送制御に伴う無効なデータ送信などを反映させて、実効ビットレートを算出する。実効ビットレートの算出方法の詳細は後述する。
【００６１】
次に、ステップＳ８０３において、受信側データリンクレート制御部２３３は、受信側トランスポートレート制御部２３５へ、輻輳位置を識別するために必要なデータリンク層の情報を伝達する。データリンク層の情報には、例えば、無線ノイズの大小情報、電波強度の良否情報、データ再送の率および回数、パケット到着間隔、および、アクセスポイントのバッファ使用率（バッファ負荷とも呼ぶ）などが含まれる。
【００６２】
以下の説明では、このデータリンク層の情報を、ネットワーク階層をまたぐ情報であることからクロスレイヤ情報とも呼ぶ。
【００６３】
なお、受信側データリンク層処理部２１１は、この処理で必要となるため、アクセスポイント１０５のバッファの使用率の情報を取得する機能を備えている。
【００６４】
次に、ステップＳ８０４において、受信側トランスポートレート制御部２３５は、トランスポート層の情報と、受信側データリンクレート制御部２３３からのクロスレイヤ情報とを解析する。そして、この解析に基づいて、受信側トランスポートレート制御部２３５は、図５に示すように、現在のネットワーク状況（輻輳、回復、輻輳位置、輻輳の要因などを含む）を識別する。このトランスポート層の情報には、ＲＴＴ（Round-Trip Time）などが含まれる。
【００６５】
図５は、実施の形態１のネットワーク輻輳位置の識別パターンと伝送方針の決定パターンとの一例を示す図表である。本実施の形態では、図５において、トランスポート層の情報をＬ４情報、データリンク層の情報（クロスレイヤ情報）をＬ２情報と記している。
【００６６】
この識別処理により、受信側トランスポートレート制御部２３５は、図５の「ネットワーク状況推定」の列に示されるネットワーク状況の識別結果を得る。この識別結果としては、例えば、コアネットワーク（有線区間）１０２の輻輳、または、エッジネットワーク（無線区間）１１３の輻輳などが含まれる。また、この識別結果としては、エッジネットワーク（無線区間）１１３の輻輳からの回復、無線ノイズによるエッジネットワーク（無線区間）１１３の一時的な障害などが含まれる。
【００６７】
次に、ステップＳ８０５において、受信側トランスポートレート制御部２３５は、識別したネットワーク状況に基づいて、図５の「伝送方針」の列に示すように、現在のデータ伝送の方針を決定する。例えば、ネットワーク状況が有線区間の輻輳であると推定した場合、受信側トランスポートレート制御部２３５は、長い期間伝送レートを低くする方針（従前のレート制御の方針）とする。また、無線区間の輻輳と推定した場合、受信側トランスポートレート制御部２３５は、伝送レートを下げる方針とする。また、無線区間の輻輳からの回復状態と推定した場合、受信側トランスポートレート制御部２３５は、伝送レートを即座に回復する方針とする。また、無線区間の一時的な無線ノイズによる障害と推定した場合、受信側トランスポートレート制御部２３５は、伝送レートを変化させない、または、伝送レートを小さい幅で下げる方針とする。
【００６８】
次に、ステップＳ８０６において、受信側トランスポートレート制御部２３５は、受信側データリンクレート制御部２３３で算出した実効ビットレートから、トランスポート層で達成できるエンド・ツー・エンドのスループットを算出する。このスループットの算出方法の詳細は後述する。
【００６９】
次に、ステップＳ８０７において、受信側トランスポートレート制御部２３５は、Ｌ４情報とＬ２情報との履歴情報を用いて、必要があれば、トランスポート層の伝送レートを回復させる制御スケジュールの補償を行う。なお、制御スケジュールは、リカバリスケジュールと呼ぶものとする。
【００７０】
ここで、リカバリスケジュールとは、ステップＳ８０５，Ｓ８０６において決定された伝送方針および伝送レート（エンド・ツー・エンドのスループット）のうち、ネットワーク輻輳の回復時に適用するものである。ステップＳ８０５，Ｓ８０６で決定された伝送方針および伝送レートは、アクセスポイント１０５のバッファ使用状況が考慮されていないため、このステップＳ８０７で補償を行う。
【００７１】
受信側トランスポートレート制御部２３５は、この補償処理のために、必要な期間、Ｌ４情報とＬ２情報を履歴情報として保持および管理している。
【００７２】
受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率に基づき、図６に示すリカバリスケジュールの補償パターンに従って、リカバリスケジュールの補償を行う。具体的には、受信側トランスポートレート制御部２３５は、バッファ使用率が少なければ、伝送レートを速やかに上昇させるパターンを選択する。一方、受信側トランスポートレート制御部２３５は、バッファ使用率が多ければ、所定期間、伝送レートを次第に上昇させて補償パターンを選択する。このリカバリスケジュールの補償により、アクセスポイント１０５は所定期間のうちにバッファに溜まっている伝送データを転送させて、バッファをクリアすることができる。
【００７３】
図６は、実施の形態１のリカバリスケジュールの補償パターンの一例を示す図表である。なお、図６は、無線区間の障害から回復する際のリカバリスケジュールに対する補償パターンを示している。受信側トランスポートレート制御部２３５は、有線区間の輻輳から回復する際に、図６に示すリカバリスケジュールの補償は行わない。
【００７４】
なお、スループットを次第に上昇させる補償を行う際、受信側トランスポートレート制御部２３５は、現在の実効ビットレートおよびデータリンク層のリトライ率等の少なくとも一つの情報を利用して、補償量の最適化を図ってもよい。
【００７５】
また、受信側トランスポートレート制御部２３５は、バッファ使用率の情報が取得できない場合、代わりに、ＲＴＴの履歴情報を用いてバッファ使用率を推定し、同様の補償処理を行うことができる。この代替的な処理の詳細は後述する。
【００７６】
次に、ステップＳ８０８において、受信側トランスポートレート制御部２３５は、決定したリカバリスケジュールに基づいて、このスケジュールの実行に必要な情報をフィードバックパケット１２３に入れて送信側端末１０１へ送信する。
【００７７】
フィードバックパケット１２３には、変更後の送信レートの値、変更タイミング、変更にかけるタイムスパン、損失したデータパケットの識別情報、または、有線区間の輻輳に対応した従前のレート制御処理の起動指示などが含まれる。
【００７８】
次に、ステップＳ８０９において、送信側端末１０１の送信側トランスポートレート制御部２３１は、フィードバックパケット１２３に含まれるリカバリスケジュールに従って、伝送レートを実際に回復させるレート制御を行う。
【００７９】
具体的には、送信側トランスポートレート制御部２３１は、フィードバックパケット１２３の内容に基づいて、送信レートの変更、或いは、従前のレート制御処理の起動を行う。また、送信側トランスポートレート制御部２３１は、フィードバックパケット１２３の内容に基づいて、損失したデータパケットの速やかな再送を行う。この損失したデータパケットを速やかに再送する処理の詳細については後述する。
【００８０】
上記一連のレート制御によれば、例えば、コアネットワーク１０２の輻輳から回復する際には、輻輳を悪化させないように伝送レートを緩やかに上昇させる通常のレート制御が実現される。また、無線区間のエッジネットワーク１１３の一時的なノイズ障害または輻輳から回復する際には、無駄に低い伝送レートが続かないように、伝送レートを適宜速やかに上昇させるレート制御が実現される。
【００８１】
次に、上述したレート制御の幾つかのステップのより詳細な具体例を説明する。
【００８２】
［リトライ率の算出方法（Ｓ８０１）］
ステップＳ８０１のリトライ率の算出は、受信側端末１０３と送信側端末１０１の伝送経路に含まれる無線リンク伝送状況を把握し、実効ビットレートの推定を行うために、次のように行われる。
【００８３】
先ず、ステップＳ８０１の算出処理のために、受信側データリンクレート制御部２３３は、常時、無線区間の再送に伴うスループットの損失分を特定するための統計データを作成する。この統計データの作成には、ウインドウを基礎とした統計生成器が使用される。ウインドウとは、１回のリトライ率を算出するために統計データを取得する期間を表わし、また、リトライ率算出用の可変ウインドウバッファのサイズにも対応する。
【００８４】
図７は、リトライ率を算出するための可変ウインドウバッファ５００の構成例を示す。可変ウインドウバッファ５００は、ウインドウサイズのシフトレジスタにより構成される。可変ウインドウバッファ５００には、最新のリトライ履歴情報５０１が保存されるとともに、現時点のリトライ情報５０５が順次更新入力されることで、過去のリトライ履歴情報５０３が可変ウインドウバッファ５００上で順次シフトされる。ここで、リトライ情報およびリトライ履歴情報とは、対象の時点におけるデータ再送の有無を示す情報である。
【００８５】
可変ウインドウバッファ５００には、リトライ情報の履歴を保持するためにウインドウサイズに対応する長さのシフトレジスタが使用される。ここで言うウインドウサイズとは、前述したトランスポート層のウインドウ制御におけるウインドウサイズのことである。図７の例では、ウインドウサイズは１２８個のパケットである。このため、可変ウインドウバッファ５００には１２８ビットのシフトレジスタを使用している。トランスポート層のウインドウ制御におけるウインドウサイズが変化すれば、可変ウインドウバッファ５００もウインドウサイズにあわせてサイズを変化させる。
【００８６】
受信側データリンクレート制御部２３３は、データリンク層でパケットが受信される度に、シーケンス番号が順序通りであるかどうかチェックする。シーケンス番号が順序通りでない場合には、受信側データリンクレート制御部２３３は、無線区間でパケットロスがあると予測する。そして、受信側データリンクレート制御部２３３は、リトライ限界の回数まで再送が試行されたと推定し、可変ウインドウバッファ５００にリトライ限界の回数分「１」の値を書き込む。この書き込みにより、可変ウインドウバッファ５００には、リトライを表わす「１」の値が、リトライ限界回数分左にシフトされながら書き込まれる。
【００８７】
また、受信したパケットが順序通りのシーケンス番号をもつ場合、受信側データリンクレート制御部２３３は、再送インジケータが受信データパケット１２１に関連付けられているか否かをチェックする。再送インジケータが有効であれば、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータを左へＳ回ビットシフトし、最初からＳ−１回のビットシフトではリトライを表わす「１」の値を入力する。また、最後のビットシフトでは、受信側データリンクレート制御部２３３は、リトライ無しを表わす「０」の値を入力する。ここで、Ｓはリトライの失敗率であり、後述するようにノイズレベルと信号強度によって決定される。
【００８８】
一方、順序通りのシーケンス番号の付いたパケットが受信され、再送インジケータが何も設定されていない場合には、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータを左へ１回ビットシフトさせる。そして、受信側データリンクレート制御部２３３は、リトライ無しを表わす「０」の値を入力する。
【００８９】
リトライの計数値は、初期化時に”０”に設定される。受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータをビットシフトさせる度に、リトライの計数値を更新する。具体的には、ビットシフトの度に、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００から出ていくビット値（例えば１２８ビット番目の値）と、入力されるビット値（例えば１ビット番目の値）とを比較する。そして、これら二つが同じであれば、受信側データリンクレート制御部２３３は、リトライの計数値を変更しない。出ていくビット値が「１」であり、入力されるビット値が「０」であれば、受信側データリンクレート制御部２３３は、リトライの計数値をデクリメントする。但し、リトライの計数値が「０」である場合には、そのままとする。また、出ていくビット値が「０」であり、入力されるビット値が「１」であれば、受信側データリンクレート制御部２３３は、リトライの計数値をインクリメントする。
【００９０】
ウインドウ期間内のリトライ率”Retry_Rate”は、次の式により、リトライの計数値”Retry_Count”と、ウインドウサイズ”Window_Size”から算出可能である。
【数１】
図７の具体例では、Window_Sizeは「１２８」である。
【００９１】
前述したように、ウインドウサイズは、データ伝送の状況に依存して変化する。ウインドウサイズが変更されると、リトライの計数値は、「０」または新たにサイズ変更された可変ウインドウバッファ５００内で「１」の値を持つビットの個数に再設定される。例えば、ウインドウサイズが６４パケットに変更される場合には、旧可変ウインドウバッファ５００の１〜６４ビット番目のみの値が維持される。この場合、リトライの計数値は、１ビット番目から６４ビット番目までの中で「１」の値をとるビットの個数に設定される。
【００９２】
なお、上記の例では、リトライ率を算出するために導入されるウインドウの長さは、パケット単位で制御される構成とした。この制御は、リトライ率を推定する上で簡単で容易な方法である。しかし、長時間に渡りパケットが受信されないなどの深刻な障害の影響を避けるために、ウインドウは、時間を基礎として可変制御される構成としてもよい。この場合、パケットが受信されないまま、予め設定されたパケット送信タイマーの計時が終了する（タイムアウト）度に、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータを左へビットシフトする。そして、受信側データリンクレート制御部２３３は、リトライを表わす「１」の値を可変ウインドウバッファ５００に新たに入力する。この場合、リトライ計数値は、パケットの受信またはタイムアウトによって更新される。
【００９３】
また、上記の例では、可変ウインドウバッファ５００は、ウインドウサイズの変更に伴いそのサイズを変動させる構成とした。しかし、リトライ率を算出する構成は、ウインドウサイズ毎に用意された長さの異なる複数のシフトレジスタを使用する構成としてもよい。この場合でも、ウインドウサイズが変わる際に、受信側データリンクレート制御部２３３は、使用するシフトレジスタをウインドウサイズの対応するものに変更すればよい。
【００９４】
なお、受信データパケット１２１が再送データであるか否かは、受信データパケット１２１の無線リンク・ヘッダの再送マーキングの有無により判別できる。例えば、無線リンクがＩＥＥＥ８０２．１１（非特許文献１０を参照）の技術を使用している場合、ヘッダは、そのパケットが再送であるか否かのインジケータを持っている。
【００９５】
また、ＩＥＥＥ８０２．１１において、アクセスポイント１０５は、パケットを黙って廃棄するまでに４〜７回のパケットの再送が可能である。また、ＩＥＥＥ８０２．１１パケットでは、データリンク層のヘッダが、管理フレームとデータフレームの両方で共有されるシーケンス番号も提供する。したがって、受信側データリンク層処理部２１１は、シーケンス番号Ａのデータパケット１２１を受信すると、それ以前の最後に受信成功したパケットのシーケンス番号Ｂと、シーケンス番号を比較する。そして、受信側データリンク層処理部２１１は、新たに受信した管理フレームの数Ｃに基づく修正を行うことによって、何個のデータパケットを損失したかを推定できる。
【００９６】
また、リトライの失敗率Ｓの値は、例えば、ノイズレベルまたは信号強度レベルといった無線状況に基づいて決定され得る。Ｓの値は、１〜Ｔの範囲に入る。ここで、Ｔは、無線リンク層処理部２０９において、その回数以上のリトライがあった場合に、送信失敗処理へ遷移するリトライ限界数である。一般に、ノイズレベルがより高い場合、または信号強度がより低い場合、ＳはＴにより近い値になり、逆の場合には、Ｓは１に近くなる。Ｓの値は、例えば、次の無線パラメータ間の所定のマッピングに基づいて、決定することも可能である。無線パラメータとは、例えば、ノイズレベル、アップリンクの失敗率、低減化期間、物理層のキャリア検知統計値、アップリンク送信試行の衝突率、前に演算されたリトライ率Ｒ等である。この所定のマッピングを実現するデータは、広範な測定とシミュレーションにより作成され、受信側端末１０３の無線モジュール用のファームウェアの一部とし、受信側データリンクレート制御部２３３内に記憶されること可能である。この場合、ユーザは、ネットワークを介して更新データをダウンロードすることにより、マッピングのデータを更新することができる。
【００９７】
また、ウインドウサイズWindow_Sizeは、次のように動的に変化させてもよい。すなわち、受信側データリンクレート制御部２３３は、例えば、ノイズレベル、信号強度、及び前回算出されたリトライ率といった無線リンクのパラメータを利用して、使用すべき適切なウインドウの長さを決定してもよい。具体的には、ノイズレベルと信号強度が大きく変化せず、且つ、リトライ率が両方向に突然変化する、即ち、時折上昇し時折下降する場合、受信側データリンクレート制御部２３３は、ウインドウの長さを比較的大きな値に維持する。これにより、一時的な障害によるリトライ率の変化は、取り除かれる。しかし、演算されたリトライ率と共にノイズレベルと信号強度が変化している場合、受信側データリンクレート制御部２３３は、無線環境の変化を即座に反映できるように、ウインドウの長さをより小さく縮小する。例えば、ノイズレベルが高くなる場合および／または信号強度があるしきい値以下に低下し、且つ、演算されたリトライ率が上昇している場合には、ウインドウの長さはより短いものに縮小される。同様に、ノイズレベルが突然低くなった場合および／または信号強度がより高くなった場合、且つ、演算されたリトライ率が下降しているときには、ウインドウの長さはより短くされる。これにより、受信側データリンクレート制御部２３３は、無線環境の変化に十分速く対応できるリトライ率を算出できる。
【００９８】
［実効ビットレートの概算方法（ステップＳ８０２）］
一般に、無線リンクは、様々な状況に対応して使用される多様なリンクレートを持つ。例えば、ＩＥＥＥ８０２．１１（非特許文献１０）は、様々な符号化方式と変調方式に対応する様々なリンクレートを定義している。様々な無線状況に応じて、無線リンク層処理部２０９は、信頼性があり効果的な通信を成し遂げるために伝送レートを調整する。しかし、リンクレートの選択変更は、また、実際のトランスポート層のスループットに効果および影響がある。また、リンクレートの異なる複数種類の伝送処理には、それぞれ異なるオーバヘッドが含まれる。
【００９９】
例えば、選択したリンクレートが２４Ｍｂｐｓであるならば、無線リンクにおけるフィードバック制御の伝送には、そのレートの半分である１２Ｍｂｐｓしか使用できない。同時に、例えば、ビーコンフレームのように、全ての端末へブロードキャストされる管理フレームは、上記のレートよりもかなり低いレートで伝送される必要がある。
【０１００】
同様に、異なる無線技術は、オーバヘッドに大きな影響を与え得る。例えば、ＩＥＥＥ８０２．１１ｂモードが使用される場合には、共通管理フレーム用に使用されるレートはより低くされるため、管理フレームを送信するためのオーバヘッドはかなり高くなる。そして、ＩＥＥＥ８０２．１１ｎ（非特許文献１１）モードが、複数アンテナの同時利用（ＭＩＭＯ：Multiple Input Multiple Output）で使用される場合には、オーバヘッドは一様でないことがあり得る。これは、データリンク層のヘッダが数ストリームの一つでのみで伝送されるためである。
【０１０１】
したがって、トランスポート層での実効ビットレートを正確に推定するためには、受信側データリンクレート制御部２３３は、リアルタイムの物理層の情報を利用する。この情報は、受信データパケットに付属しており、妥当なパラメータを決定するために使われる。例えば、無線アクセス技術がＩＥＥＥ８０２．１１（非特許文献１０、非特許文献１１）である場合には、以下の情報が使用される。
【０１０２】
‐ オペレーションモード情報：例えば、ＩＥＥＥ８０２．１１ｂ／ｇ／ａ／ｎの各モードなど、該当するオペレーションモード
‐ 暗号化モード情報：暗号化が実施される場合、例えば、ＡＥＳ（Advanced Encryption Standard）−１２８、３ＤＥＳ（3 Data Encryption Standard）など、暗号化アルゴリズムの種別
‐ リンクレート：無線リンクの動作モード（オペレーションモードとも呼ばれる）に応じたリンクレート
リンクレートは、様々な形式で表現され得る。例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードの場合、リンクレートは、Ｍｂｐｓ単位で表現される。一方、動作モードがＩＥＥＥ８０２．１１ｎであれば、リンクレートは、ＭＣＳ（Modulation and Coding Scheme）インデックスの形で表現される。また、リンクレートは、ＭＣＳインデックスとキャリア帯域幅を組み合わせると、適切なリンクレートを導き出せる。
【０１０３】
‐ ビーコン間隔
‐ ショートガードインターバルの使用の有無
‐ ＰＬＣＰヘッダのオーバヘッド
ＰＬＣＰ（Physical Layer Convergence Protocol/Procedure）ヘッダ長は、変調及び符号化方式に基づいて導出可能である。そして、この変調及び符号化方式は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードではリンクレート値から導出可能である。また、ＩＥＥＥ８０２．１１ｎモードでは、ＭＣＳインデックスから導出可能である。
‐ ＩＥＥＥ８０２．１１ｎモード使用時の使用ストリーム数
ストリーム数に基づいて、リンク層ヘッダのオーバヘッドが算出可能である。
【０１０４】
なお、受信側データリンク層処理部２１１において、実効ビットレートの演算に使用可能な上記以外の他の情報があることは当業者にとって明らかである。何れの情報を使用するかは、本発明の概念に影響することではない。
【０１０５】
上記の情報を使用して、受信側データリンクレート制御部２３３は、次のようにして、無線リンク上でサポート可能なトランスポート層での実効ビットレートを推定する。先ず、受信側データリンクレート制御部２３３は、動作モードをチェックする。動作モードがＩＥＥＥ８０２．１１ａ／ｂ／ｇのうちのいずれか一つであるならば、受信側データリンクレート制御部２３３は、対応する一組の実効ビットレート演算式を使用する。
【０１０６】
まず、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードの無線リンクの実効ビットレート推定は、演算式（１）を用いて計算する。この演算式（１）では、次の各時間のオーバヘッドを反映させた実効ビットレートＥｂｔ（ｍｂｐｓ）の計算が行われる。
【数２】
【０１０７】
式（１）中の各パラメータは、次の通りである。
‐ Ｐｓｉｚｅ：トランスポート層のビット単位のペイロードサイズ
‐ Ｐｔ：データリンク層と物理層のオーバヘッドを含む実際のデータパケットを送信するのに要する時間
‐ Ｆｔ：対応する無線リンクのフィードバック制御用のデータ送信に要する時間
‐ [1-(Blength/Rbeacon)/Binterval]：ビーコンフレームを反映させた伝送効率
‐ (1-Retry_Rate)：データリンク層のリトライ率を反映させた伝送効率
【０１０８】
‐ Ｂｌｅｎｇｔｈ：ビーコンの長さ
‐ Ｂｉｎｔｅｒｖａｌ：ビーコンの間隔
‐ Ｒｂｅａｃｏｎ：ビーコン管理フレームを転送するためのレート
‐ Ｒｅｔｒｙ＿Ｒａｔｅ：ステップＳ８０１で算出されたリトライ率
【０１０９】
次に、データリンク層と物理層のオーバヘッドを含む実際のデータパケットを送信するのに要する時間Ｐｔは、次式（２）で求めることができる。
【数３】
【０１１０】
式（２）中の各パラメータは、以下の通りである。
‐ Ｐｓｉｚｅ：トランスポート層のビット単位のペイロードサイズ
‐ ＤａｔａＲａｔｅ：受信側データリンク層処理部２１１によって、受信したデータパケット１２１に含まれるＭｂｐｓ（Mega bits per second）単位の受信レート
‐ Ｃｐｒｏｂ：衝突の確率
衝突の確率の値は、受信側データリンク層処理部２１１によって検知されたノイズレベルの変化によって調整され得る。これは、受信側データリンク層処理部２１１内にマッピング・テーブルとして保存可能である。
‐ ａ：ＩＥＥＥ８０２．１１（非特許文献１０）に定義され、ＲＴＳ／ＣＴＳ（Request to Send / Clear to Send）機構が有効であるか否かに依存する値
「ａ」は、ＲＴＳ／ＣＴＳが無効である場合には「０」であり、有効であれば「１」である。
‐ ＳＩＦＳ：短いフレーム間の間隔
‐ Ｂａｃｋｏｆｆ：平均のデータリンク層の低減化ウインドウ（window）サイズ
このサイズは、無線環境情報に基づいて動的に補正可能でもある。例えば、データリンク層が同一のアクセスポイント１０５に結び付いた無線局の数が多いこと、またはチャネル利用率が高いことを検出した場合には、この値はより高い値に設定され得る。受信側端末１０３は、ＩＥＥＥ８０２．１１（非特許文献１０）に定義されているように、ビーコンフレーム中のＢＳＳ（Basic Service Set）のＬＯＡＤ（負荷情報）からこれらの情報を取得できる。
【０１１１】
‐ Ｔｓｌｏｔ：スロット時間
‐ (MAC、IP、Layer 4)Protocol_header：それぞれ、データリンク層、ネットワーク層、及びトランスポート層に対応するそれぞれの層で使用されるヘッダ
‐ Ｔａｉｌ：最後尾のビット
‐ Ｒｓｉｚｅ：ＲＴＳのサイズ
‐ Ｃｓｉｚｅ：ＣＴＳのサイズ
‐ Ｂ：ＣＴＳ‐ＲＴＳ（Clear to Send - Request to Send）方式が使用される場合に「１」、使用されない場合は「０」
‐ Ａｓｉｚｅ：ＩＥＥＥ８０２．１１ ＡＣＫのサイズ
‐ Ｒｃｔｌ：制御フレームの送信レート
‐ Ｐｒｅａｍｂ：プリアンブルの時間幅
‐ ＰＬＣＰ：物理層ヘッダの時間幅
‐ Ｓｉｇｅｘｔ：信号拡張部分の時間幅
【０１１２】
次に、対応する無線リンクのフィードバック制御用のデータ送信に要する時間Ｆｔは、次式（３）で求めることができる。
【数４】
【０１１３】
式（３）中のパラメータは、以下の通りである。
‐ Ｆｅｅｄｂａｃｋ＿ｓｉｚｅ：例えば、拡張オプションの付いたＴＣＰ ＡＣＫといったトランスポート層のフィードバックパケット１２３のサイズ
その他のパラメータは、式（２）で説明したものと同じである。
【０１１４】
なお、ＳＩＦＳ、Ｔｓｌｏｔ、Ｐｒｅａｍｂ、ＰＬＣＰ、Ｓｉｇｅｘｔ、ＭＡＣ、Ｔａｉｌ、Ｒｓｉｚｅ、Ｃｓｉｚｅ、Ｒｓｉｚｅ、Ｂｌｅｎｇｔｈ、Ｂｉｎｔｅｒｖａｌの各パラメータの値は、オペレーションモードとアクセスポイント１０５によって選択されたデータレートに依存する。受信側データリンク層処理部２１１は、受信したデータパケット１２１のデータレートをチェックすることによって、変調及び符号化方式を推定できる。この推定結果を用いて、受信側データリンク層処理部２１１は、ＩＥＥＥ８０２．１１（非特許文献１０）での定義に基づき、上記のパラメータの値を決定することができる。
【０１１５】
また、Ｒｃｔｒｌ及びＲｂｅａｃｏｎは、次の幾つかの設定に依存する。
設定１：データパケット送信のためにアクセスポイント１０５によって選択されたデータレート
設定２：例えば、ＩＥＥＥ８０２．１１ｇと８０２．１１ｂモード、またはＩＥＥＥ８０２．１１ｇモードのみというようなアクセスポイント１０５のオペレーションモード
【０１１６】
本実施の形態の実効ビットレートの演算式（１）では、無線リンクのフィードバック制御でのやり取り、データリンク層でのリトライ率および最大再送回数などが考慮される。具体的には、この演算式（１）では、無線メディアアクセスの衝突、および、それより前に推定されたリトライ率による潜在的なバックオフ等が考慮される。したがって、この演算式（１）により、受信側データリンクレート制御部２３３、受信側データリンク層処理部２１１の実効ビットレートをより厳密に算出することができる。
【０１１７】
なお、実効ビットレートの演算式（１）は、無線リンクでのデータ伝送において、暗号化通信が使用されないことを前提とした演算式である。なお、これ以外の種類の設定を反映するように、本演算式は、容易に変更可能であることは当業者にとって明らかである。例えば、暗号化が実施される場合、演算式中のＰｓｉｚｅは、暗号化前の実際のトランスポート層パケットのペイロードサイズに修正される。また、それ以外のＰｓｉｚｅ、ネットワーク層及びトランスポート層プロトコルヘッダは、すべて、暗号化後のサイズに修正される。これらの細かな変更は、本発明の概念に影響しないことは明白である。
【０１１８】
また、受信側データリンクレート制御部２３３は、特にトランスポート層プロトコルヘッダについて、すべての情報をもたない場合もある。したがって、一つの代替的な方法として、受信側データリンクレート制御部２３３は、受信側データリンク層処理部２１１に関する演算だけを実行する構成としてもよい。この場合、受信側データリンクレート制御部２３３は、途中までの演算結果を、クロスレイヤ情報と共に受信側トランスポート層処理部２１３内の受信側トランスポートレート制御部２３５まで送る。次に、受信側トランスポートレート制御部２３５は、受信側トランスポート層処理部２１３に知らされたトランスポート層の情報を付加して、実効ビットレートの演算を完了する。
【０１１９】
次には、無線リンクがＩＥＥＥ８０２．１１ｎモードで動作している場合の、別の実効ビットレートEbtの算出式（４）を示す。
【０１２０】
【数５】
【０１２１】
式（４）中の各パラメータは、次の通りである。
‐ Ｐｓｉｚｅ2：トランスポート層のビット単位のペイロードサイズ
‐ Ｐｈｙｔ：データパケットの送信に付随する物理層のオーバヘッドの処理時間
‐ Ｍａｃｔ：データパケットの送信に付随するデータリンク層のオーバヘッドの処理時間
‐ Ｔｒｐｔ：ペイロードを送信するのに要する時間
‐ Ｔｒｆｔ：トランスポート層のフィードバックパケット１２３を送信するのに要する時間
‐ [1-(Blength/Rbeacon)/Binterval]：ビーコンフレームを反映させた伝送効率
‐ (1-Retry_Rate)：データリンク層のリトライ率を反映させた伝送効率
【０１２２】
次に、トランスポート層のビット単位のペイロードサイズＰｓｉｚｅ２は、次式（５）で求めることができる。
【数６】
【０１２３】
式（５）中の各パラメータは、以下の通りである。
‐ Ｌ２＿ｆｒａｍｅ＿ｓｉｚｅ：Ａ−ＭＰＤＵ（Aggregated Mac Protocol Data Unit）の連結後に、伝送のために物理層に渡されるＰＤＵ（Protocol Data Unit）のサイズ
‐ Nmber_of_frames_in_A‐PMDU：Ａ−ＭＰＤＵフレームに含まれるフレームの数
このフレームの数は、受信側データリンク層処理部２１１内に設定しておくことができ、アクセスポイント１０５へ通知される。また、受信側データリンク層処理部２１１は、リアルタイムの受信データパケットからこの値を読み込むことができる。
‐ Ｈｅａｄｅｒ＿ｏｖｅｒｈｅａｄｓ：データリンク層、ネットワーク層、トランスポート層のヘッダのサイズ
‐ ＡＭＰＤＵ＿ｏｖｅｒｈｅａｄ：Ａ−ＭＰＤＵパケット構成中で使用される、Ａ−ＭＰＤＵ区切り文字、Ａ−ＭＰＤＵパディング、等のサイズ
【０１２４】
次に、データパケットの送信に付随する物理層のオーバヘッドの処理時間Phytは、次式（６）で求めることができる。
【数７】
【０１２５】
式（６）中の各パラメータは、以下の通りである。
‐ Ｎ＿ｔｘ：データの伝送に使用される空間的ストリームの数
この空間的ストリームの数は、データリンク層のパラメータから取得可能である。
‐ Ａ：ＣＴＳ（Clear to Send）‐ｔｏ‐ｓｅｌｆ方式が使用される場合に「１」、使用されない場合に「０」
‐ Ｂ：ＣＴＳ‐ＲＴＳ（Clear to Send - Request to Send）方式が使用される場合に「１」、使用されない場合は「０」
‐ Preamb(le)、SIFS、DIFS：ＩＥＥＥ８０２．１１ｎ（非特許文献１１）に定義されているデータリンク層で使用されるパラメータ
【０１２６】
次に、データパケットの送信に付随するデータリンク層のオーバヘッドの処理時間Ｍａｃｔは、次式（７）で求めることができる。
【数８】
式（７）中の各パラメータは、以下の通りである。
‐ Ａｓｉｚｅ：ＩＥＥＥ８０２．１１ ＡＣＫのサイズ
‐ Ｃｓｉｚｅ：ＣＴＳのサイズ
‐ Ｒｓｉｚｅ：ＲＴＳのサイズ
‐ Ｃｔｌ＿ｒａｔｅ：データリンク層で制御フレームを送信するために使用されるレート
その他のパラメータは、式（６）で説明したものと同じである。
【０１２７】
次に、ペイロードを送信するのに要する時間Ｔｒｐｔは、次式（８）で求めることができる。
【数９】
式（８）中の各パラメータは、以下の通りである。
‐ L2_frame_size：Ａ−ＭＰＤＵ（Aggregated Mac Protocol Data Unit）の連結後に、伝送のために物理層に渡されるＰＤＵ（Protocol Data Unit）のサイズ
‐ ＤａｔａＲａｔｅ：データパケットの送信レート
この送信レートは、ＭＣＳインデックスとチャネル帯域幅値から導出可能である。
【０１２８】
次に、トランスポート層のフィードバックパケット１２３を送信するのに要する時間Ｔｒｆｔは、次式（９）で求めることができる。
【数１０】
式（９）中の各パラメータは、以下の通りである。
‐ number_of_frames_in_AMPDU：Ａ−ＭＰＤＵフレームに含まれるフレームの数
このフレームの数は、受信側データリンク層処理部２１１内に設定しておくことができ、アクセスポイント１０５へ通知される。また、受信側データリンク層処理部２１１は、リアルタイムの受信データパケットからこの値を読み込むことができる。
‐ Ｆｅｅｄｂａｃｋ＿ｓｉｚｅ：例えば、拡張オプションの付いたＴＣＰ ＡＣＫといったトランスポート層のフィードバックパケット１２３のサイズ
その他のパラメータは、式（８）で説明したものと同じである。
【０１２９】
なお、上記のパラメータのいくつかは、データパケットの受信によって受信側データリンク層処理部２１１が入手可能なその他のパラメータから導出または推量される。例えば、number_of_frames_in_A‐PMDUは、ペイロードサイズＰｓｉｚｅを、次のデータサイズ１〜３の合計で除算することにより導出される。
データサイズ１：Ａ−ＭＰＤＵ中のサブフレームのフレームサイズ
データサイズ２：ＬＬＣ（Logical Link Control）ヘッダのサイズ
データサイズ３：ＩＥＥＥ８０２．１１ｎデータリンク層ヘッダのサイズ
【０１３０】
本実施の形態の実効ビットレートの演算式（４）では、無線送信に使用されるストリームの数、および、物理層におけるフレームの総数が考慮されている。言い換えれば、この演算式（４）は、複数の空間的及び時間的送信ストリーム（Ｎ＿ｔｘにより決定）のデータリンク層での総計（number_of_frames_in_A‐PMDUにより決定）を、考慮したものである。つまり、この演算式（４）は、ＩＥＥＥ８０２．１１ｎの特徴を反映させたものである。
【０１３１】
さらに、この演算式（４）では、物理層とＭＡＣ層のオーバヘッドの時間が十分に考慮される。例えば、受信側データリンク層処理部２１１がデータパケットの送信に使用される二つのストリームを検出した場合、物理層のオーバヘッドは、そのうちの一つのストリーム中にだけ存在することになる。したがって、上記の演算式（４）、（６）において、オーバヘッド時間４０３の値は、プリアンブル時間、ＰＬＣＰ時間、ＳＩＦＳ（Short Inter Frame Space）及びＤＩＦＳ（Distributed Coordination Function Inter Frame Space）時間の合計の２倍に修正されている。一方、アクセスポイント１０５がデータパケットの送信のために単一のストリームを使用する場合、オーバヘッド値は、プリアンブル時間、ＰＬＣＰ時間、ＳＩＦＳ及びＤＩＦＳ時間の合計の４倍に修正されている。
【０１３２】
さらに、この演算式（４）では、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードの場合と同様に、例えば、ビーコンの送信などの共通管理フレームの送信によるオーバヘッド、及びデータリンク層でのリトライ率についても考慮されている。
【０１３３】
したがって、この演算式（１）により、受信側データリンクレート制御部２３３は、ＩＥＥＥ８０２．１１ｎの無線リンクが選択されている場合に、受信側データリンク層処理部２１１の実効ビットレートをより厳密に算出することができる。
【０１３４】
［データリンク層情報の生成及び伝達処理（Ｓ８０３）］
図４のステップＳ８０３において、受信側データリンクレート制御部２３３は、データリンク層情報（クロスレイヤ情報とも呼ぶ）をデータパケットにタグ付けして、受信側トランスポートレート制御部２３５に送信する。
【０１３５】
このデータリンク層情報（クロスレイヤ情報）は、次の情報を含む。
【０１３６】
‐ 推定された実効ビットレート
‐ データリンク層のパケット損失インジケータ
これは、リンク層のシーケンス番号と管理フレームを追跡することによって、受信側データリンクレート制御部２３３が検出する。このインジケータにより、受信側トランスポートレート制御部２３５は、この成功したパケット送信の前に、パケット損失があったか否かを知ることができる。
‐ 受信したパケットの伝送に際して、データリンク層での再送が実施されたか否かを示す、リトライ指示
‐ データリンク層でのパケット到着間隔時間
‐ アクセスポイント１０５でバッファに格納されたデータを示す、アクセス・ポイントバッファ負荷
これは、受信側データリンクレート制御部２３３が、データパケットヘッダのＱｏＳ（Quality of Service）制御フィールドから取得可能である。
‐ データリンク層のリトライ限界値
‐ ノイズレベルと信号強度
【０１３７】
このデータリンク層情報（クロスレイヤ情報）の伝達は、ネットワーク階層をまたぐクロスレイヤでの情報受け渡しとなり、通常のプロトコル設計ではサポートされてない。このような情報伝送は、受信側データリンクレート制御部２３３がアクセスするネットワークデータバッファ構造を変更して実現できる。具体的には、上記の情報伝達は、上記のネットワークデータバッファのパケット保持用バッファ構造に追加のデータエントリを関連づける実装を行って、上記のデータリンク層情報を登録して伝送することで実現できる。例えば、Ｌｉｎｕｘカーネルでは、sk_buffと呼ばれるバッファに上記情報伝達用のフィールドを追加すればよい。また、FreeBSDカーネルでは、m_buffと呼ばれるバッファに上記情報伝達用のフィールドを追加すればよい。
【０１３８】
［ネットワーク輻輳位置の識別処理（Ｓ８０４）］
図５の表に示したように、受信側トランスポートレート制御部２３５は、データリンク層の情報（Ｌ２情報）と、トランスポート層の情報（Ｌ４情報）とに基づき、ネットワーク状況を推定し識別する。以下、図５の表に示されるネットワーク状況を推定できる理由については、ネットワークの背景動作とともに説明する。
【０１３９】
先ず、コアネットワーク１０２の輻輳によりパケット損失が生じる場合の背景動作について説明する。送信側端末１０１及びその他のノードからのトラフィックが、ネットワーク中に存在する全リンクの容量を超えた場合に、コアネットワーク１０２は、輻輳状態になる。輻輳状態になると、パケットは、ネットワーク中の中継ノードのパケットバッファに蓄積されてゆく。中継ノードのパケットバッファがあふれ出した場合は、パケット損失が発生する。
【０１４０】
このような背景動作から、受信側トランスポートレート制御部２３５は、次の条件１−４を満たした場合に、コアネットワーク１０２中で何らかの輻輳が発生したと推定することができる。
条件１：トランスポート層で観測された往復時間（ＲＴＴ）、またはクロスレイヤ情報に関連付けられたパケット到着間隔時間が、著しく増加した場合
条件２：アクセスポイント１０５のバッファ使用率が増加しないまたは減少した場合
条件３：無線ノイズのノイズレベルが低い場合
条件４：データリンク層の再送がない場合
【０１４１】
次に、受信側のエッジネットワーク（無線区間）１１３でパケット損失が生じる背景動作について説明する。受信側のエッジネットワーク（無線区間）１１３上では、パケット損失が異なる理由により発生する可能性がある。無線区間では、何らかの一時的な無線ノイズまたは電波の干渉が、エラーを伴うパケット受信を引き起こすことがある。エラーを伴うパケット受信は、データリンク層によって振るい落とされる。そのため、トランスポート層などの上位層の処理部は、パケットが損失したと見なす。
【０１４２】
例えば、ＩＥＥＥ８０２．１１などのある種の無線技術は、再送サービスを提供できる。データリンク層（例えば、アクセスポイント１０５の無線リンク層処理部２０９および受信側データリンク層処理部２１１）では、パケットが受信側のデータリンク層によって到着確認の応答がない場合、パケットの再送の試行を数回行なう。この再送サービスは、場合によって、パケットロスの状況をある程度緩和できる。しかし、無線ノイズが強固な場合には、パケットの再送も失敗する。そのため、再送サービスは、パケットロスの状況を緩和できない。
【０１４３】
一方、次の状況では、パケットロスがアクセスポイント１０５で発生する。例えば、ダウンリンクのトラフィック（ネットワークを流れる情報）がアクセスポイント１０５に到着した時、受信側のエッジネットワーク（無線区間）１１３では、電波干渉によって妨害を受けている場合を想定する。この場合は、アクセスポイント１０５から受信側端末１０３へのデータ送信が阻止される。そうなると、パケットは、全てアクセスポイント１０５のバッファに蓄積されるが、長い間干渉が起きていると、バッファがあふれてパケット損失が生じることになる。
【０１４４】
このような背景動作から、受信側トランスポートレート制御部２３５は、次の条件１−３を満たした場合に、受信側のエッジネットワーク（無線区間）１１３で輻輳（アクセス集中）が発生したと推定できる。
条件１：アクセスポイント１０５のバッファ使用率が著しく増加した場合
条件２：無線ノイズのノイズレベルが高い場合
条件３：データリンク層の再送有りが発生した場合
【０１４５】
また、受信側トランスポートレート制御部２３５は、次の条件１−４を満たした場合に、受信側のエッジネットワーク（無線区間）１１３が輻輳（アクセス集中）から回復していると推定できる。
条件１：ＲＴＴの値が高い場合
条件２：アクセスポイント１０５のバッファ使用率が大きい場合
条件３：無線ノイズのノイズレベルが低い場合
条件４：信号強度が高い場合
【０１４６】
また、受信側トランスポートレート制御部２３５は、次の条件１−４を満たした場合に、ＲＴＴの変動が主に無線の一時的障害に起因すると推定できる。
条件１：幾つかのパケットについてのＲＴＴの値が高い場合
条件２：様へアクセスポイント１０５のバッファ使用率が所定レベル未満で小さい場合
条件３：無線リンク品質（例えば、ノイズレベル、信号強度等）が良好な場合
条件４：データリンク層の再送ある場合
【０１４７】
このように、受信側トランスポートレート制御部２３５は、データリンク層の情報とトランスポート層の情報とに基づいて識別処理を行っているので、正確にネットワーク状況を推定し識別することができる。
【０１４８】
なお、図５では、トランスポート層の情報（Ｌ４情報）として、送信側端末１０１の送信側トランスポート層処理部２０１から情報であるＲＴＴを例にとって説明している。しかし、このトランスポート層の情報には、受信側端末１０３のトランスポート層の情報を含めてもよい。例えば、受信側端末１０３のトランスポート層の情報としては、例えば、トランスポート層におけるデータパケット損失に関する情報、または、ウインドウサイズの情報などが含まれてもよい。
【０１４９】
［伝送方針の決定処理（Ｓ８０５）］
ここでは、図５の表に示したように、受信側トランスポートレート制御部２３５が伝送方針を決定する理由について説明する。
【０１５０】
輻輳によるコアネットワーク１０２内でのパケットロスは、通常、深刻な状況であり、復旧するにはより長い時間を要する。このような場合、送信側端末１０１は、自己の送信レートを調整し、輻輳の悪化を防ぐ必要がある。したがって、受信側トランスポートレート制御部２３５は、コアネットワーク１０２の輻輳と推定した場合、さらなる輻輳の悪化を防ぐために、長い期間、伝送レートを低くする伝送方針を決定する。
【０１５１】
また、パケットロスが受信側のエッジネットワーク（無線区間）１１３上の一時的なノイズに起因するものであれば、送信側端末１０１は、送信レートを大幅に下げる必要はない。むしろ、送信側端末１０１は、できるだけ速やかに再送を実行すべきである。したがって、受信側トランスポートレート制御部２３５は、無線区間の一時的な無線ノイズによる障害と推定した場合、速やかな再送が実効されるように、伝送レートを変化なし、または、少しの幅で下げる伝送方針を決定する。
【０１５２】
また、パケットロスがアクセスポイント１０５で発生する場合には、事態はさらに複雑である。無線ノイズまたは電波干渉が持続的な場合、送信側端末１０１は、更なるパケットロスを避けるために送信レートを下げなくてはならない。したがって、受信側トランスポートレート制御部２３５は、無線区間の輻輳と推定した場合、パケットロスを避けるために、伝送レートを下げる伝送方針を決定する。
【０１５３】
一方、無線ノイズまたは電波干渉がもはや存在しない場合は、送信側端末１０１は、トランスポート層のウインドウ制御を用いて送信レートを即座に回復させなくてはならない。したがって、受信側トランスポートレート制御部２３５は、無線区間の輻輳が回復したと推定した場合、伝送レートを即座に回復させる伝送方針を決定する。ただし、無線ノイズまたは電波干渉は繰り返しまたは周期的に生じる可能性があり。そのため、送信側端末１０１は、無線状況を反映するために十分迅速に且つ正しい判断を行なうことが重要である。したがって、受信側トランスポートレート制御部２３５は、繰り返しまたは周期的な無線区間の障害も反映させて伝送方針を決定する構成としてもよい。
【０１５４】
［エンド・ツー・エンドのスループットの概算（Ｓ８０６）］
図４のステップＳ８０６において、受信側トランスポートレート制御部２３５は、前段で得られた無線区間の実効ビットレートを考慮して、最適なエンド・ツー・エンドのスループットを算出する。また、受信側トランスポートレート制御部２３５は、前段で識別されたネットワークの輻輳箇所および輻輳原因を考慮して、最適なエンド・ツー・エンドのスループットを算出する。
【０１５５】
先ず、受信側トランスポートレート制御部２３５は、ネットワーク輻輳がコアネットワーク１０２の輻輳によるものと識別した場合、非特許文献１〜４に示されるような従来のレート制御を起動および実行する。つまり、この場合、受信側トランスポートレート制御部２３５は、従来のレート制御に従ったエンド・ツー・エンドのスループットを算出する。ここで算出されるスループットの詳細については、従来のものと同様なので、説明を省略する。
【０１５６】
また、受信側トランスポートレート制御部２３５は、ネットワーク輻輳が受信側のエッジネットワーク（無線区間）１１３の輻輳によるものと識別した場合、この状況の悪化を避けるように処理を行う。すなわち、受信側トランスポートレート制御部２３５は、トランスポート層の伝送レートを制限すべく、エンド・ツー・エンドのスループットとして直近に得られた実効ビットレートにより達成可能なスループットを算出する。
【０１５７】
具体的には、受信側トランスポートレート制御部２３５は、実効ビットレートからトランスポート層で不要なデータリンク層の情報（Ｌ２情報）を除外して再計算すればよい。その結果、ほぼ伝送レートは変化無し、または、少しの幅で下がるのみである。
【０１５８】
また、受信側トランスポートレート制御部２３５は、ネットワークの状況がエッジネットワーク（無線区間）１１３の輻輳から回復していると識別した場合、送信レートを回復させるように処理を行う。すなわち、受信側トランスポートレート制御部２３５は、送信レートを回復すべく、エンド・ツー・エンドのスループットとして直近の回復時に得られた実効ビットレートによって達成可能なスループットを算出する。
【０１５９】
この場合の実効ビットレートからスループットを算出する具体例は、無線区間の輻輳のときと同一である。無線区間の輻輳のときと、輻輳の回復時とで、実効ビットレートの値が異なることで、算出されるスループットの値は変化する。
【０１６０】
また、受信側トランスポートレート制御部２３５は、ＲＴＴの変動が主に無線区間の一時的障害に起因して生じていると識別した場合、次の対応を行う。受信側トランスポートレート制御部２３５は、直近に算出された無線区間の実効ビットレートに近づけるように、達成可能なエンド・ツー・エンドのスループットの値を増加させていく。この制御は、無線区間の一時的障害に起因したエンド・ツー・エンドのスループットの大きな変動を防ぐ作用を及ぼす。
【０１６１】
具体的には、受信側トランスポートレート制御部２３５は、実効ビットレートからトランスポート層では不要なデータリンク層の情報（Ｌ２情報）を除外した値に一気に増加させるようにスループットを算出してもよい。また、受信側トランスポートレート制御部２３５は、上記の値に線形的に増加させて徐々に近づけるようにスループットを算出してもよい。
【０１６２】
このように算出されたスループットにより、本実施の形態の受信側トランスポートレート制御部２３５と送信側トランスポートレート制御部２３１とは、ネットワークの物理的な限界に近い伝送データのレート制御を実現する。
【０１６３】
［ＲＴＴに基づくリカバリスケジュールの補償（Ｓ８０７）］
ここでは、受信側トランスポートレート制御部２３５が、アクセスポイント１０５のバッファ使用率の情報を利用できず、ＲＴＴの情報からエンド・ツー・エンドのスループットのリカバリスケジュールを補償する場合について説明する。
【０１６４】
前述のように、受信側トランスポートレート制御部２３５は、ネットワーク輻輳の位置推定を実施するときに、ＲＴＴの変動とデータリンク層の状態とを参照する。このうち、ＲＴＴ（伝送データの往復時間）は、無線区間のリトライとメディアアクセス衝突が起きた場合に、無線区間で伝送遅延が生じて、増加することがあり得る。
【０１６５】
ＲＴＴが増加する第１の状況は、一時的な無線ノイズまたは一時的な電波干渉に起因する可能性が最も高い。データリンク層の再送制御には、再送回数の制限すなわちリトライ限界値がある。そのため、この状況に起因する伝送遅延には、通常、上限がある。また、データリンク層の伝送処理では、伝送レートが無線ノイズのレベルに応じて適応されている。したがって、つまり、受信側トランスポートレート制御部２３５は、リトライ限界値によって制限された上限内でＲＴＴが変化するならば、アクセスポイント１０５のバッファに余裕があると推定することができる。したがって、この場合、受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率が低い場合と同様に、リカバリスケジュールの補償を行わない。
【０１６６】
一方、ＲＴＴが増加する第２の状況としては、無線ノイズまたは電波干渉が強くなった場合がある。この場合、アクセスポイント１０５は、無線ノイズまたは電波干渉が強くなるほど無線メディアがビジー状態であると検出する。さらに、この場合、アクセスポイント１０５は、バックオフを行う必要があり、データパケットをバッファに格納する。この場合には、データリンク層の伝送レートを適応させる処理は機能しなくなる。そして、この状況が長く続くまたは周期的に起きる場合は、アクセスポイント１０５のバッファ使用率は増加し続け、ＲＴＴの値も増加する。遂には、アクセスポイント１０５のバッファが満杯になり、パケット損失が発生する。
【０１６７】
このＲＴＴの増加の監視を行うため、受信側トランスポートレート制御部２３５は、データ伝送により繰り返し得られるＲＴＴ（Round-Trip Time）の情報から、ＲＴＴ増減の比較基準となるベースＲＴＴを取得して保持する。ベースＲＴＴは、例えば、データ伝送のセッション継続時間中に検知した最小のＲＴＴとしてもよい。或いは、ベースＲＴＴは、アクセスポイント１０５のバッファ負荷が閾値未満と観測された時のＲＴＴとしてもよい。
【０１６８】
したがって、受信側トランスポートレート制御部２３５は、ＲＴＴがリトライ限界値によって制限された上限を超えて増加していれば、ネットワークが輻輳から回復した際に、アクセスポイント１０５のバッファ使用率が高いと推定できる。この場合、受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率が高い場合と同様に、リカバリスケジュールの補償を行う。
【０１６９】
このようにＲＴＴの履歴情報を用いることで、受信側トランスポートレート制御部２３５は、バッファ使用率に応じてリカバリスケジュールを補償する。つまり、受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率の情報を直接得ることができない場合でも、リカバリスケジュールを補償することができる。
【０１７０】
［損失したデータパケットの速やかな再送処理（Ｓ８０９）］
ここでは、ステップＳ８０９の処理のうち、送信側トランスポートレート制御部２３１が損失したデータパケットを速やかに再送する処理について詳細に説明する。
【０１７１】
前述した通り、受信側データリンクレート制御部２３３は、無線区間のパケットロス情報を受信側トランスポートレート制御部２３５へ提供する。このパケットロス情報は、受信側データリンクレート制御部２３３が、データリンク層のシーケンス番号と受信した管理フレームの数を追跡（トレース）することで作成される。そして、無線区間のパケットロス情報が作成されるときは、現在受信に成功したパケットの前に何個かのパケットの損失があることを意味する。したがって、受信側トランスポートレート制御部２３５は、クロスレイヤ情報に含まれる受信したパケットのシーケンス番号をチェックすることで、どのパケットが再送されるべきかを瞬時に決定する。
【０１７２】
例えば、受信側トランスポート層処理部２１３がＴＣＰのようなプロトコルを使用しているならば、順序を外れて受信されたパケットは、最初にバッファに保持される。したがって、受信側トランスポート層処理部２１３は、再送のために準備されるべき、今のパケットに先行した直前のパケットを識別できる。
【０１７３】
再送すべきパケットを識別したら、受信側トランスポート層処理部２１３は、送信側端末１０１へのフィードバックパケット１２３の中に、ＳＡＣＫ（Selective Acknowledgement：選択確認応答）オプションまたは重複したＡＣＫを含める。これにより、受信側トランスポート層処理部２１３は、再送すべきパケットを送信側トランスポート層処理部２０１へすばやく通知することができる。或いは、代替的に、トランスポート層のフィードバックパケット１２３が、損失した疑いがあるパケットを示す追加のオプション・フィールドを含む構成としてもよい。この構成により、受信側トランスポート層処理部２１３は、損失した疑いがあるパケットを送信側トランスポート層処理部２０１へすばやく通知することができる。そして、これらの通知により、送信側トランスポート層処理部２０１は、損失したパケットの再送を直ぐにスケジュールすることできる。
【０１７４】
一般に、ＴＣＰなどの通常のトランスポート・プロトコルにおいて、受信側端末１０３は、受信したパケットが順序通りでないときに、前のＡＣＫメッセージとまったく同じシーケンス番号を付けてＡＣＫメッセージを送信する。送信側端末１０１は、連続して重複したＡＣＫメッセージが所定数（例えば３個）受信したら、ＡＣＫが戻ってこなかったパケットの再送制御を起動させる。つまり、受信側トランスポート層処理部２１３と送信側トランスポート層処理部２０１とは、所定数の重複したＡＣＫの受信を、再送制御を起動させる指示として使用する。
【０１７５】
それに対して、本実施の形態では、受信側トランスポート層処理部２１３が、クロスリンク情報を持っていることで、再送の必要なパケットの情報を送信側トランスポート層処理部２０１へ直接的に通知できる。したがって、本実施の形態のトランスポート層の再送制御では、一般的な３個の重複したＡＣＫによる非到達パケットの検知方式を利用した制御に比べて、ずっと早く再送をスケジュールすることができる。それゆえ、本実施の形態では、トランスポート層の再送制御の性能の向上を促進できる。
【０１７６】
以上、本発明の実施の形態１について説明した。
【０１７７】
なお、実施の形態１では、受信側端末１０３が、レート制御のための伝送方針の決定、エンド・ツー・エンドのスループットの算出、および、リカバリスケジュールの補償を行う構成とした。しかしながら、本実施形態では、送信側端末１０１がこれらを行う構成とすることも可能であり、このことは当業者にとって明らかである。受信側データリンクレート制御部２３３と受信側トランスポートレート制御部２３５は、必要な情報を集め、集めた情報をトランスポート層のフィードバックパケット１２３として、送信側トランスポートレート制御部２３１へ渡せばよい。また、送信側トランスポートレート制御部２３１は、レート制御の内容を決定するために、上記受信した情報と、例えばＲＴＴ値およびバッファサイズなど、自ノードにある情報に基づいて、同様の演算処理を行えばよい。
【０１７８】
また、実施の形態１において、受信側データリンクレート制御部２３３は、無線リンク状況に関する所定の推定を行って、達成可能なエンド・ツー・エンドのスループットを算出する構成とした。しかし、受信側データリンクレート制御部２３３は、所定のパターン認識に基づいて無線環境の動向から達成可能なエンド・ツー・エンドのスループットを得る構成としてもよい。
【０１７９】
例えば、受信側データリンクレート制御部２３３は、無線リンクが短い一時的な干渉を受けた状況と、無線リンクが実効ビットレートの下降をより長い時間受ける状況とを、パターン認識に基づいて予測することができる。この場合、受信側データリンクレート制御部２３３は、ウインドウ期間におけるデータリンク層の再送試行の記録と、ノイズレベルに関する統計値とを対象に、パターン認識を行って上記の予測を行うことができる。このパターン認識に必要なパターンデータは、広範な測定とシミュレーションに基づいて予め作成可能であり、受信側データリンクレート制御部２３３内に記憶可能である。
【０１８０】
また、実施の形態１では、アクセスポイント１０５に一つの受信側端末１０３が無線接続されている構成の動作に主眼を置いて説明した。しかし、本発明は、アクセスポイント１０５に一つの受信側端末１０３と、他の１つ又は複数の無線局が接続されている構成に対しても有効に適用できる。例えば、アクセスポイント１０５は、ビーコン中にブロードキャストされるＢＳＳ（Basic Service Set）負荷エレメントの情報に、局数カウントの値とチャネル利用率に関する情報とを含めている。局数カウントは、アクセスポイント１０５に結び付いた無線局（ＳＴＡ：ステーション）の数を示し、チャネル利用率は、無線メディアがビジーであった時間を示す。これらの情報により、受信側データリンクレート制御部２３３は、適切な実効ビットレートが使用されるべき対象の無線局を推定できる。
【０１８１】
また、実施の形態１では、受信側トランスポートレート制御部２３５が、ネットワーク混雑位置の識別（Ｓ８０４）と、現在の状況に対する伝送方針の決定（Ｓ８０５）と、達成可能なスループットの見積り（Ｓ８０６）とを行う構成とした。しかし、受信側端末１０３は、別個複数のモジュールを備え、これら複数のモジュールがステップＳ８０４〜Ｓ８０６の処理をそれぞれ行う構成としてもよい。これらのモジュールは適宜、機能毎に分割または統合されていても構わない。例えば、受信側端末１０３は、ネットワーク混雑位置の識別機能と、現在の状況に対する伝送方針の決定機能を統合した伝送スケジューリングモジュールを備えてもよい。また、受信側端末１０３は、データリンク層の実効ビットレートの見積もり機能と、トランスポート層の達成可能エンド・ツー・エンドのスループット見積もり機能とを、統合したレート制御モジュールを備えてもよい。
【０１８２】
（実施の形態２）
図８は、本発明の実施の形態２のネットワーク伝送装置が加わるネットワーク構成の一例を示す図である。
【０１８３】
実施の形態２のネットワーク構成には、送信側端末６０１と、エッジネットワーク６１１，６１３と、アクセスポイント６０３と、コアネットワーク６０５と、受信側端末６０７とが含まれる。
【０１８４】
送信側端末６０１は、ネットワーク経由でＡＶストリーミングデータを送出する情報端末である。エッジネットワーク６１３は、送信側端末６０１が接続される送信側のネットワーク（無線区間）である。コアネットワーク６０５は、インターネットなどを含み、送信側端末６０１と受信側端末６０７との間に位置する主に有線のネットワークである。エッジネットワーク６１１は、受信側端末６０７とコアネットワーク６０５とを接続する受信側のネットワーク（有線区間）である。アクセスポイント６０３は、送信側エッジネットワーク（無線区間）６１３とコアネットワーク６０５の間に位置して、無線区間と有線区間のネットワークブリッジとして機能する。受信側端末６０７は、ネットワーク経由でＡＶストリーミングデータを受信する情報端末である。
【０１８５】
実施の形態２のネットワーク上で伝送されるデータには、データパケット６２１と、フィードバックパケット６２３とが含まれる。
【０１８６】
データパケット６２１は、例えばＡＶストリーミングデータなどであり、送信側端末６０１から受信側端末６０７へ向けて送信される。フィードバックパケット６２３は、データパケット６２１の伝送に対する応答および伝送制御用のデータを含み、受信側端末６０７から送信側端末６０１へ送信される。これらの構成のうち、送信側端末６０１が、本発明に係るネットワーク端末装置の一実施の形態である。
【０１８７】
図９は、本実施の形態２の送信側端末６０１の要部構成図である。
【０１８８】
送信側端末１０３は、送信側データリンク層処理部７０３と、送信側トランスポート層処理部７０１と、輻輳箇所判別部７３１ａと、伝送レート制御部７３１ｂと、実効レート算出部７３３ａと、を備える。
【０１８９】
送信側データリンク層処理部７０３は、送信側端末６０１におけるネットワーク処理のうち、データリンク層の処理を行う。送信側トランスポート層処理部７０１は、送信側端末６０１のネットワーク処理のうち、トランスポート層の送信処理を行う。
【０１９０】
実効レート算出部７３３ａは、送信側データリンク層処理部７０３の実効ビットレートを算出する。ここで、算出される実効ビットレートは、送信側データリンク層処理部７０３の再送制御に伴う伝送効率の低下を考慮した実効的な伝送レートである。算出された実効ビットレートの情報は、伝送レート制御部７３１ｂへ送られる。
【０１９１】
輻輳箇所判別部７３１ａは、送信側データリンク層処理部７０３の伝送状況を表わすデータリンク層情報と、送信側トランスポート層処理部２１３の伝送状況を表わすトランスポート層情報とに基づいて、ネットワークの輻輳箇所を判別する。データリンク層情報は、本発明に係る第２層情報の一実施形態である。トランスポート層情報は、本発明に係る第４層情報の一実施形態である。判別結果の情報は、伝送レート制御部７３１ｂへ送られる。
【０１９２】
伝送レート制御部７３１ｂは、輻輳箇所の判別結果の情報と、実効ビットレートの情報とを受けて、これらの情報に基づき、トランスポート層の伝送レートを決定する制御を行う。
【０１９３】
なお、後述する図１０の具体的な構成例において、実効レート算出部７３３ａは、送信側データリンクレート制御部７３３に含まれている。しかし、実効レート算出部７３３ａは、送信側データリンクレート制御部７３３と別に設けられても良い。また、後述する図１０の具体的な構成例において、輻輳箇所判別部７３１ａと伝送レート制御部７３１ｂとは、図１０の送信側トランスポートレート制御部７３１に含まれている。しかし、輻輳箇所判別部７３１ａと伝送レート制御部７３１ｂとは、送信側トランスポートレート制御部７３１と別に設けられても良い。
【０１９４】
続く説明では、ネットワークの各ノードが、非特許文献７に示されるＴＣＰ（Transmission Control Protocol）を使用して、データ伝送を行う例を示している。しかし、データ伝送のためのプロトコルは、送信データのレート制御と受信側から送信側へのフィードバックが可能であれば、その他のプロトコルを適用可能である。このことは当業者にとって明らかであり、本発明の概念に影響するものでない。その他のプロトコルとしては、例えば、非特許文献８に示されるＤＣＣＰ（Datagram Congestion Control Protocol）が適用できる。また、その他のプロトコルとしては、非特許文献９に示されるＳＣＴＰ（Stream Control Transmission Protocol）が適用できる。
【０１９５】
図１０は、図８の各装置の論理的構成を示すブロック図である。
【０１９６】
送信側端末６０１は、図１０に示すように、送信側アプリケーション７４０と、送信側トランスポート層処理部７０１と、送信側トランスポートレート制御部７３１と、送信側データリンク層処理部７０３と、送信側データリンクレート制御部７３３と、を備える。
【０１９７】
送信側アプリケーション７４０は、データの送信要求と指示とを行う。送信側トランスポート層処理部７０１は、図９にも示したように、送信側端末６０１におけるネットワーク処理のうち、トランスポート層の伝送処理を行う。送信側トランスポートレート制御部７３１は、送信側端末６０１における送信側トランスポート層処理部７０１において、送信側のトランスポート層のレート制御と必要な情報取得処理とを行う。送信側データリンク層処理部７０３は、図９にも示したように、送信側端末６０１におけるネットワーク処理のうち、データリンク層の伝送処理を行う。送信側データリンクレート制御部７３３は、送信側端末６０１における送信側トランスポート層処理部７０１において、送信側のデータリンク層のレート制御と必要な情報取得処理とを行う。
【０１９８】
受信側端末６０７は、図１０に示すように、受信側アプリケーション７４１と、受信側トランスポート層処理部７１３と、受信側トランスポートレート制御部７３５と、受信側データリンク層処理部７１１と、を備える。
【０１９９】
受信側アプリケーション７４１は、データの受信要求と指示とを行う。受信側トランスポート層処理部７１３は、受信側端末６０７におけるネットワーク処理のうち、トランスポート層の受信処理を行う。受信側トランスポートレート制御部７３５は、受信側端末６０７における受信側トランスポート層処理部７１３において、受信側のトランスポート層のレート制御と必要な情報取得処理とを行う。受信側データリンク層処理部７１１は、受信側端末６０７におけるネットワーク処理のうち、データリンク層の処理を行う。
【０２００】
アクセスポイント６０３は、図１０に示すように、ブリッジ機構７０５と、有線リンク層処理部７０９と、無線リンク層処理部７０７と、を備える。
【０２０１】
ブリッジ機構７０５は、アクセスポイント６０３において、無線ネットワークと有線ネットワークの間のネットワークブリッジ機能の処理を行う。有線リンク層処理部７０９は、ブリッジ機構７０５のうち、有線ネットワークのデータリンク層の処理を行う。無線リンク層処理部７０７は、ブリッジ機構７０５のうち、無線ネットワークのデータリンク層の処理を行う。
【０２０２】
次に、上記のネットワーク構成において、データの伝送処理の流れについて説明する。
【０２０３】
送信側端末６０１は、送信側トランスポート層処理部７０１から送信側データリンク層処理部７０３を介して、アクセスポイント６０３へ向けてデータパケット６２１を送信する。アクセスポイント６０３の無線リンク層処理部７０７は、データパケット６２１を受信し、ブリッジ機構７０５を通じて、データパケット６２１を有線リンク層処理部７０９へ中継する。アクセスポイント６０３は、有線リンク層処理部７０９、コアネットワーク６０５、および、受信側エッジネットワーク（有線区間）６１１を介して、データパケット６２１を受信側端末６０７へ送信する。受信側端末６０７は、受信側データリンク層処理部７１１を介して、データパケット６２１を受信する。受信側データリンク層処理部７１１は、受信側端末６０７内の受信側トランスポート層処理部７１３へデータパケット６２１を転送する。
【０２０４】
図１１は、実施の形態２の受信側端末６０７と送信側端末６０１とにより行われるレート制御の手順を示すフローチャートである。このレート制御は、通常のデータ伝送の進行中に行われる。
【０２０５】
ステップＳ９０１において、送信側データリンクレート制御部７３３は、受信側端末６０７と送信側端末６０１との伝送経路に含まれる無線区間の伝送状況を把握する。次に、送信側データリンクレート制御部７３３は、実効リンクレートの推定を行うために、データリンク層におけるリトライ率を算出する。
【０２０６】
送信側データリンク層処理部７０３よりアクセスポイント６０３に送出されたパケットは、エラーを生じずに伝達される場合も、エラーによって送信のリトライが行われる場合もある。このリトライは、無線リソースを必要とするので、無線区間で実際に達成可能なスループットに影響を及ぼす。無線区間におけるデータ再送は、データリンク層で実施され、この再送が失敗を繰り返してトランスポート層で再送制御を行う必要が生じない限り、トランスポート層は関知しない。したがって、送信側トランスポート層処理部７０１は、従前の構成のままでは、無線区間のデータ再送を加味した処理はできない。
【０２０７】
送信側データリンクレート制御部７３３は、無線区間の再送に伴うスループットの損失分を特定するための統計データを作成し、この統計データからリトライ率を算出する。統計データとは、所定期間内の各送信タイミングにおけるデータ再送の有無の履歴を表わすデータである。リトライ率の算出は、実施の形態１におけるステップＳ８０１の説明で述べた通り、ウインドウサイズに連動してサイズが変更される可変ウインドウバッファ（図７参照）を用いて行われる。
【０２０８】
次に、ステップＳ９０２において、送信側データリンクレート制御部７３３は、送信側データリンクレート制御部７３３が算出したデータリンク層のリトライ率を用いて、データリンク層の実効ビットレートを見積もる。この計算は、実施の形態１におけるステップＳ８０２の説明で述べた通り、使用される無線アクセスのオペレーションモード毎に異なる計算式、例えば、実施の形態１で示した実効ビットレートの演算式（１）、（４）を用いて実行される。
【０２０９】
次に、ステップＳ９０３において、送信側データリンクレート制御部７３３は、実効ビットレートの推定後、トランスポート層へのデータフィードバックに所定のクロスレイヤ情報をタグ付けする。次に、送信側データリンクレート制御部７３３は、それをタグ付けデータとして、送信側トランスポートレート制御部７３１に送る。受け渡すクロスレイヤ情報、および、ネットワーク階層をまたいだ情報の受け渡しを行うための実装例については、実施の形態１におけるステップＳ８０３の説明で述べた通りである。
【０２１０】
次に、ステップＳ９０４において、送信側トランスポートレート制御部７３１は、クロスレイヤ情報を用いて、現在のネットワークの輻輳位置の識別を行う。この識別処理は、実施の形態１のステップＳ８０４の説明で述べた通りである。
【０２１１】
次に、ステップＳ９０５において、送信側トランスポートレート制御部７３１は、識別したネットワーク輻輳位置に基づいて現在の状況に対する伝送方針を決定する。この処理は、実施の形態１のステップＳ８０５の説明で述べた通りである。
【０２１２】
次に、ステップ９０６において、送信側トランスポートレート制御部７３１は、送信側データリンクレート制御部７３３で見積もった実効ビットレートを用いて、トランスポート層での達成可能エンド・ツー・エンドのスループットを見積もる。この処理は、実施の形態１のステップＳ８０６の説明で述べた通りである。
【０２１３】
次に、ステップＳ９０７において、送信側トランスポートレート制御部７３１は、実際のデータ送信のスケジュールを算出する際に、履歴情報を用いてデータ送信スケジュールの補償を行う。この補償処理は、実施の形態１のステップＳ８０７の説明で述べた通りである。
【０２１４】
次に、ステップＳ９０８において、送信側トランスポートレート制御部７３１は、実際のデータ送信のリカバリスケジュールを実行する。
【０２１５】
上記一連のレート制御によって、受信側端末６０７と送信側端末６０１とは、ネットワークで伝送レートが低下したときでも、適切に輻輳またはパケットロスの位置を判定することができる。さらに、受信側端末６０７と送信側端末６０１とは、更なる輻輳またはパケットロスを防止しつつ利用可能なネットワークリソースを最大限に活用するような、伝送レートの回復に向けたレート制御を実現できる。
【０２１６】
以上、本発明の実施の形態２について説明した。
【０２１７】
なお、実施の形態２では、送信側トランスポートレート制御部７３１が、ネットワーク混雑位置の識別（Ｓ９０４）と、現在の状況に対する伝送方針の決定（Ｓ９０５）と、達成可能なスループットの見積り（Ｓ９０６）とを行う構成とした。しかし、送信側端末６０１は、別個複数のモジュールを備え、これら複数のモジュールがステップＳ９０４〜Ｓ９０６の処理をそれぞれ行う構成としてもよい。これらのモジュールは、適宜、機能毎に分割または統合されていても構わない。例えば、送信側端末６０１は、ネットワーク混雑位置の識別機能と、現在の状況に対する伝送方針の決定機能を統合した伝送スケジューリングモジュールを備えてもよい。また、送信側端末６０１は、データリンク層の実効ビットレートの見積もり機能と、トランスポート層の達成可能エンド・ツー・エンドのスループット見積もり機能とを、統合したレート制御モジュールを備えてもよい。
【０２１８】
上記の記述においては、具体的な実施の形態を詳細に説明し、添付の図面に図示したが、当業者は、これらの実施の形態の詳細部分の様々な修正または代替が本開示の全般的な教示内容を踏まえて可能であることを理解されるであろう。したがって、実施の形態に開示された構成は、本発明の範囲についての一例に過ぎず、本発明は実施の形態の構成に限定されるものではない。
【０２１９】
上記の実施形態の説明で使用された各機能部は、一般に集積回路として表現されるＬＳＩとして実現可能である。これらは、個々に一つのチップとして製造されても、一部または全部を含む一つのチップとして設計されてもよい。ここでＬＳＩと称するものは、集積の程度に応じて、ＩＣ、システムＩＣ，超ＬＳＩ、または極超ＬＳＩと呼ばれることもある。また、集積回路の技術は、ＬＳＩにだけ限定されず、集積回路は専用回路または汎用プロセッサとして実現可能である。本実施形態は、ＬＳＩの製造後にプログラム可能であるＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）、ＬＳＩ内の回路セルの接続、または、設定が再構成され得る再構成可能プロセッサも使用可能ある。さらに、本実施形態は、半導体技術またはそれから派生したその他の技術の進歩により、ＬＳＩに取って代わる回路集積化の技術が出現し得るときには、そのような技術を使用することによって機能部を集積してもよい。例えば、バイオテクノロジーの適応は、このような可能性の一つである。
【産業上の利用可能性】
【０２２０】
本発明は、ネットワークを介してデータ送信を行うサーバ装置、ネットワークを介してデータ受信を行う端末装置等に適用できる。
【符号の説明】
【０２２１】
１０１ 送信側端末
１０２ コアネットワーク
１０３ 受信側端末
１０５ アクセスポイント
１１１，１１３ エッジネットワーク
１２１ データパケット
１２３ フィードバックパケット
２０１ 送信側トランスポート層処理部
２０３ 送信側データリンク層処理部
２０５ 有線リンク層処理部
２０９ 無線リンク層処理部
２１１ 受信側データリンク層処理部
２１３ 受信側トランスポート層処理部
２３１ 送信側トランスポートレート制御部
２３３ 受信側データリンクレート制御部
２３５ 受信側トランスポートレート制御部
５００ 可変ウインドウバッファ
５０１，５０３ リトライ履歴情報
５０５ リトライ情報
６０１ 送信側端末
６０３ アクセスポイント
６０５ コアネットワーク
６０７ 受信側端末
６１１，６１３ エッジネットワーク
６２１ データパケット
６２３ フィードバックパケット
７０１ 送信側トランスポート層処理部
７０３ 送信側データリンク層処理部
７０７ 無線リンク層処理部
７０９ 有線リンク層処理部
７１１ 受信側データリンク層処理部
７１３ 受信側トランスポート層処理部
７３１ 送信側トランスポートレート制御部
７３３ 送信側データリンクレート制御部
７３５ 受信側トランスポートレート制御部
【技術分野】
【０００１】
本発明は、ネットワークを介してデータ伝送を行うネットワーク端末装置およびそのデータ伝送方法に関する。
【背景技術】
【０００２】
近年、インターネットおよび宅内ネットワークを介して、送信側端末から受信側端末へＡＶ（Audio Visual）コンテンツデータを伝送するストリーミングサービスが、普及している。ストリーミングサービスにおいて、受信側端末は、ＡＶコンテンツデータを受信しながらこのＡＶコンテンツの再生を行う。
【０００３】
ここでは、このストリーミンクサービスが、次のネットワーク構成で提供される場合を検討する。次のネットワーク構成とは、受信側端末が無線を介して隣接する通信ノードと接続され、隣接する通信ノードと送信側端末とがコアネットワークを介して接続されている構成である。上記隣接する通信ノードは、例えば、アクセスポイント（ＡＰとも呼ぶ）である。上記コアネットワークは、インターネットなどを含む、主に有線のネットワークである。
【０００４】
ＡＶコンテンツデータは、このようなネットワーク構成で伝送される場合、有線区間の輻輳（混雑とも呼ぶ）により、その伝送レートが低下することがある。また、ＡＶコンテンツデータは、無線区間の一時的な障害により、その伝送レートが一時的に低下することがある。無線区間の一時的な障害には、アクセスの集中による輻輳の場合と、無線ノイズによる場合とがある。特に区別しない場合には、これらの場合をまとめて輻輳と呼ぶ。
【０００５】
有線区間と無線区間とでは、データ伝送に関する性質が、次のように異なる。有線区間では、個々の通信ノード間の伝送特性は安定しており、物理層およびＭＡＣ（Media Access Control）層での障害または伝送パケットの損失は生じにくい。また、有線区間では、ネットワークが輻輳（混雑とも呼ぶ）して、中継ノードで処理の限界を超えるトラフィックが生じた場合、中継ノードでバッファオーバーフローが生じて、伝送パケットの損失（パケットロスとも呼ぶ）が発生する。また、有線区間の輻輳は、一般に復帰に時間がかかる。
【０００６】
一方、無線区間では、ノイズまたは電波干渉等により伝送特性が一時的に不安定になることがあり、伝送パケットの損失および伝送エラーも頻繁に起きる。電波の干渉または衝突は、無線区間にある機器の無線メディアへのアクセスを遅延させ、送信側端末と受信側端末との間（端末間、或いは、エンド・ツー・エンド（Ｅ２Ｅ）とも呼ぶ）の伝送遅延を増大させる。
【０００７】
また、無線区間では、無線機器のデータリンク層（第２層、Ｌ２（レイヤー２）とも呼ぶ）の再送制御によって、伝送遅延が増大することがある。例えば、ＩＥＥＥ８０２．１１（非特許文献１０を参照）のような幾つかの無線アクセス技術は、再送制御をサポートする。このような無線アクセス技術を利用している環境において、データパケットが無線送信中に失われた場合に、中継ノード（アクセスポイントなど）は、データリンク層の処理で再送を数回試行する。この再送の試行の結果、エンド・ツー・エンドの伝送遅延は増加する場合がある。
【０００８】
また、無線区間の障害は、一時的なものであるか、あるいは短時間に変動することが多く、また、障害がなくなれば復帰は早い。
【０００９】
従来、送信側端末と受信側端末との間の伝送レートは、送信側端末および／または受信側端末のトランスポート層（第４層、Ｌ４（レイヤー４）とも呼ぶ）の制御によって、調整されるのが一般的であった。また、この伝送レートは、有線区間の輻輳に合わせて調整されるのが一般的であった。
【００１０】
具体的には、有線区間において輻輳が生じると、エンド・ツー・エンドのデータ伝送が失敗する。そのため、送信側端末および／または受信側端末は、端末間の伝送レートを低くして、データ伝送の失敗を回避する。このレート制御によりネットワークトラフィックが緩和されると、送信側端末および／または受信側端末は、端末間の伝送レートを緩やかに回復していく。非特許文献１〜４には、このような輻輳に対するレート制御の様々な手法が開示されている。
【００１１】
また、有線区間と無線区間とを有するネットワークにおいて、無線区間の障害を検出する技術については、従来から幾つかの手法が提案されている。
【００１２】
例えば、非特許文献５には、伝送エラーがあった場合に、有線区間のエラーか無線区間のエラーかを区別する技術が開示されている。具体的には、非特許文献５では、トランスポート層のフィードバック情報に含まれるＲＯＴＴ（Round-Trip Time：片方向データ到達時間）に基づいて、有線区間のエラーか無線区間のエラーかを区別している。また、非特許文献５に開示の送信端末は、ＲＯＴＴが大きくなっていれば有線区間の輻輳エラーであると判別し、ＲＯＴＴが小さくなっていれば無線区間のリンクエラーであると判別する。また、無線区間のリンクエラーであると判別された場合は、ＢＬＲ（Beacon Loss Rate：ビーコンロス率）を評価して、無線衝突（混雑）によるリンクエラーか無線ノイズによる伝送エラーかを判別することが開示されている。
【００１３】
また、非特許文献６には、無線アクセスポイントのデータリンク層処理部に、フィードバック情報を送信端末へ送信する機能を設けた構成が開示されている。非特許文献６には、この情報に基づいて、無線区間における伝送データの損失の発生理由を推定することが開示されている。具体的には、無線アクセスポイントのデータリンク層処理部は、ＳＮＲ（信号対雑音比）などのＭＡＣ層情報を送信端末へフィードバックする。送信端末は、この情報に基づいて、伝送データの損失が、無線区間における無線衝突（混雑）によるものか、無線ノイズによる伝送エラーかを判別する。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】M. Allman, V. Paxson, and E. Blanton, "TCP Congestion Control", IETF RFC 5681, September 2009, <http://tools.ietf.org/html/rfc5681>
【非特許文献２】Lawrence S. Brakmo, and Larry L. Peterson, "TCP Vegas: End to End Congestion Avoidance on a Global Internet", IEEE Journal on Selected Areas in Communications, vol. 13, No. 8, October 1995, pp. 1465-1480
【非特許文献３】Claudio Casetti, Mario Gerla, Saverio Mascolo, M. Yahya Sanadidi, and Ren Wang, "TCP Westwood: End-to-End Bandwidth Estimation for Enhanced Transport over Wireless Links", Wireless Networks Journal 8, 2002, pp. 467-479
【非特許文献４】Lisong Xu, Harfoush K., Injong Rhee, "Binary Increase Congestion Control (BIC) for fast long-distance networks", Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM 2004, vol. 4, November 2004, pp. 2514-2524
【非特許文献５】Sangheon Pack, Xuemin (Sherman) Shen, IEEE, Jon W. Mark, Life Fellow, and Lin Cai., "A Two-Phase Loss Differentiation Algorithm for Improving TFRC Performance in IEEE 802.11 WLANs", IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 6, NO. 11, NOVEMBER 2007, pp. 4164
【非特許文献６】Stephane Lohier, Yacine Ghamri Doudane and Guy Pujolle, "Cross-layer loss differentiation algorithms to improve TCP performance in WLANs", Telecommunication Systems Volume 36, Numbers 1-3, pp. 61-72
【非特許文献７】Jon Postel Ed.,"TRANSMISSION CONTROL PROTOCOL", RFC793, <http://www.ietf.org/rfc/rfc793.txt>
【非特許文献８】E. Kohler, M. Handley, S. Floyed, "Datagram Congestion Control Protocol (DCCP)", RFC4340, <http://www.rfc-editor.org/rfc/rfc4340.txt>
【非特許文献９】S. Stewart, et al. "Stream Control Transmission Protocol", RFC2960, <http://www.ietf.org/rfc/rfc2960.txt>
【非特許文献１０】IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, <http://standards.ieee.org/getieee802/download/802.11-2007.pdf>
【非特許文献１１】IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Enhancements for Higher Throughput, <http://standards.ieee.org/getieee802/download/802.11n-2009.pdf>
【発明の概要】
【発明が解決しようとする課題】
【００１５】
しかしながら、上記従来のレート制御では、次のような課題が生じる。すなわち、通常のレート制御（例えば非特許文献１〜４のレート制御）では、伝送パケットの損失または遅延が有線区間の輻輳によるものか無線区間の障害によるものか区別できない。つまり、無線区間の一時的な障害に対しても、有線区間の輻輳に対ししても、通常のレート制御では、同じレート制御のアルゴリズムが使用される。そのため、上記従来のレート制御では、パケットロス等が検知された場合に、伝送レートが不必要に低くされてしまうことがある。この場合には、ネットワークのスループットが不必要に低下して、エンド・ツー・エンドの通信品質が低下する。
【００１６】
また、通常のレート制御では、ネットワークの輻輳の悪化を防ぐために、輻輳が回復されてきた場合に、伝送レートは緩やかに上げられる。そのため、通常のレート制御では、無線区間の一時的な障害（例えば電子レンジの使用による無線ノイズの発生）により伝送パケットが一時的に損失した場合でも、この障害が取り除かれた後の伝送レートの回復が無駄に遅くなる。
【００１７】
さらに、通常のレート制御では、無線区間で小規模な障害が多発する場合に、上記のような伝送レートの調整が繰り返される。その結果、エンド・ツー・エンドの伝送レートは、実際にデータ伝送可能なレートよりもずっと低い伝送レートで滞ってしまうという課題が生じる。この場合、無線リソースは十分に利用されず、エンド・ツー・エンドのネットワーク帯域は、本来利用できる帯域よりもずっと狭いままとなる。
【００１８】
また、無線区間の障害を検知する非特許文献５，６の技術では、次のような課題がある。すなわち、非特許文献５の技術では、ＲＯＴＴの変化情報などのトランスポート層の情報のみで、伝送エラーの発生箇所が有線区間か無線区間かを判別している。そのため、この技術では、伝送エラーの発生箇所を正確に判別できないという課題がある。例えば、ＲＯＴＴは、無線区間のリアルタイムの伝送状況を正確に反映するほど詳細な情報でない。つまり、無線区間の伝送状況の変化に対して、ＲＯＴＴは、追従性よく変動しない。それゆえ、ＲＯＴＴの変化情報だけでは、無線区間の一時的な障害または短時間の変動を正確に判別できない。
【００１９】
また、非特許文献６の技術では、アクセスポイントから送信端末へフィードバック情報を送信する構成が必要となる。具体的には、非特許文献６の技術では、アクセスポイントおよび送信側端末のプロトコルに、ネットワーク階層をまたぐ（クロスレイヤとも呼ぶ）シグナリングプロトコル（帯域予約のための信号交換プロトコル）を、追加する必要が生じる。つまり、非特許文献６の技術では、送信側端末と受信側端末の改変だけではなく、アクセスポイントの改変が必要となる。したがって、この非特許文献６の技術では、例えば、公衆無線ＬＡＮ（ローカルエリアネットワーク）を利用したシステムなど、アクセスポイントがネットワークインフラの一部となっているシステムに対して適用困難であるという課題がある。
【００２０】
この発明の目的は、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行うようにすることである。
【課題を解決するための手段】
【００２１】
本発明の一態様に係るネットワーク端末装置は、ネットワークを介してデータ伝送を行うネットワーク端末装置であって、無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部と、前記データリンク層処理部を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部と、前記データリンク層処理部のデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理部のデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部と、判別された前記輻輳箇所に基づいて前記トランスポート層処理部の伝送レートを調整する伝送レート制御部と、を具備する構成を採る。
【００２２】
本発明の一態様に係るデータ伝送方法は、ネットワークを介してデータ伝送を行うデータ伝送方法であって、無線を介して接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理ステップと、前記データリンク層処理ステップを介して端末ノード間のデータ伝送処理を行うトランスポート層処理ステップと、前記データリンク層処理ステップでのデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理ステップでのデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別ステップと、判別された前記輻輳箇所に基づいて前記トランスポート層処理ステップでの伝送レートを調整する伝送レート制御ステップと、を含む構成を採る。
【発明の効果】
【００２３】
本発明によれば、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行うことができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施の形態１のネットワーク端末装置が加わるネットワーク構成の一例を示す図
【図２】本発明の実施の形態１のネットワーク端末装置である受信側端末の要部を示すブロック図
【図３】図１の各装置の論理的構成を示すブロック図
【図４】本発明の実施の形態１のレート制御の手順を示すフローチャート
【図５】実施の形態１におけるネットワーク輻輳位置の識別パターンと伝送方針の決定パターンとの一例を示す図表
【図６】実施の形態１におけるリカバリスケジュールの補償パターンの一例を示す図表
【図７】実施の形態１におけるデータリンク層のリトライ率の算出方法を説明する図
【図８】本発明の実施の形態２のネットワーク端末装置が加わるネットワーク構成の一例を示す図
【図９】本発明の実施の形態２のネットワーク端末装置である送信側端末の要部を示すブロック図
【図１０】図８の各装置の論理的構成を示すブロック図
【図１１】本発明の実施の形態２のレート制御の手順を示すフローチャート
【発明を実施するための形態】
【００２５】
以下、本発明の各実施の形態について図面を参照して詳細に説明する。
【００２６】
（実施の形態１）
図１は、本発明の実施の形態１のネットワーク端末装置が加わるネットワーク構成の一例を示す図である。
【００２７】
実施の形態１のネットワーク構成には、図１に示すように、送信側端末１０１と、エッジネットワーク１１１，１１３と、コアネットワーク１０２と、アクセスポイント１０５と、受信側端末１０３とが含まれる。
【００２８】
送信側端末１０１は、ネットワークを介してデータを送信する情報端末である。エッジネットワーク１１１は、送信側端末１０１が接続される有線区間のネットワークである。コアネットワーク１０２は、インターネットなどを含み、送信側端末１０１と受信側端末１０３との間に位置する主に有線のネットワークである。エッジネットワーク１１３は、アクセスポイント１０５と受信側端末１０３を接続する無線区間のネットワークである。アクセスポイント１０５は、エッジネットワーク（無線区間）１１３とコアネットワーク１０２の間に位置し、無線・有線のネットワークブリッジとして機能する。受信側端末１０３は、ネットワークを介して送信側端末１０１からデータを受信する情報端末である。
【００２９】
実施の形態１のネットワーク上で伝送されるデータには、データパケット１２１と、フィードバックパケット１２３とが含まれる。
【００３０】
データパケット１２１は、例えばＡＶストリーミングデータなどであり、送信側端末１０１から受信側端末１０３へ向けて送信される。フィードバックパケット１２３は、データパケット１２１の伝送に対する応答および伝送制御用のデータを含み、受信側端末１０３から送信側端末１０１へ送信される。
【００３１】
なお、図１では、ネットワークの詳細な構成要素が省略されているが、これらの構成要素が存在し得ることは当業者にとって明らかである。しかし、これらの構成要素は、本発明の概念に影響するものでない。
【００３２】
図２は、本発明に係るネットワーク端末装置の一実施の形態である受信側端末１０３の要部構成図である。
【００３３】
受信側端末１０３は、受信側データリンク層処理部２１１と、受信側トランスポート層処理部２１３と、輻輳箇所判別部２３５ａと、伝送レート制御部２３５ｂと、実効レート算出部２３３ａとを備える。
【００３４】
受信側データリンク層処理部２１１は、受信側端末１０３におけるネットワーク処理のうち、データリンク層の処理を行う。受信側トランスポート層処理部２１３は、受信側端末１０３のネットワーク処理のうち、トランスポート層の受信処理を行う。
【００３５】
実効レート算出部２３３ａは、受信側データリンク層処理部２１１の実効ビットレートを算出する。ここで、算出される実効ビットレートは、受信側データリンク層処理部２１１の再送制御に伴う伝送効率の低下を考慮した実効的な伝送レートである。算出された実効ビットレートの情報は、伝送レート制御部２３５ｂへ送られる。
【００３６】
輻輳箇所判別部２３５ａは、受信側データリンク層処理部２１１の伝送状況を表わすデータリンク層情報と、受信側トランスポート層処理部２１３の伝送状況を表わすトランスポート層情報とに基づいて、ネットワークの輻輳箇所を判別する。データリンク層情報は、本発明に係る第２層情報の一実施形態であり、トランスポート層情報は、本発明に係る第４層情報の一実施形態である。判別結果の情報は、伝送レート制御部２３５ｂへ送られる。
【００３７】
伝送レート制御部２３５ｂは、輻輳箇所の判別結果の情報と、実効ビットレートの情報とを受けて、これらの情報に基づき、トランスポート層の伝送レートを調整する制御を行う。
【００３８】
なお、続いて示される図３の具体的な構成例において、実効レート算出部２３３ａは、受信側データリンクレート制御部２３３に含まれている。しかし、実効レート算出部２３３ａは、受信側データリンクレート制御部２３３と別に設けられても良い。また、図３の具体的な構成例において、輻輳箇所判別部２３５ａと伝送レート制御部２３５ｂとは、図３の受信側トランスポートレート制御部２３５に含まれている。しかし、輻輳箇所判別部２３５ａと伝送レート制御部２３５ｂとは、受信側トランスポートレート制御部２３５と別に設けられても良い。
【００３９】
続く説明では、ネットワークの各ノードが、非特許文献７に示されるＴＣＰ（Transmission Control Protocol）を使用して、データ伝送を行う例を示している。しかし、データ伝送のためのプロトコルは、送信データのレート制御と受信側から送信側へのフィードバックが可能であれば、その他のプロトコルを適用可能である。このことは当業者にとって明らかであり、本発明の概念に影響するものでない。その他のプロトコルとしては、例えば、非特許文献８に示されるＤＣＣＰ（Datagram Congestion Control Protocol）が適用できる。または、その他のプロトコルとしては、非特許文献９に示されるＳＣＴＰ（Stream Control Transmission Protocol）が適用できる。
【００４０】
図３は、図１の各装置の論理的構成を示すブロック図である。
【００４１】
送信側端末１０１は、図３に示すように、送信側アプリケーション２４０と、送信側トランスポート層処理部２０１と、送信側トランスポートレート制御部２３１と、送信側データリンク層処理部２０３と、を備える。
【００４２】
送信側アプリケーション２４０は、データの送信要求と指示とを行う。送信側トランスポート層処理部２０１は、送信側端末１０１におけるネットワーク処理のうち、トランスポート層の伝送処理を行う。送信側トランスポートレート制御部２３１は、送信側端末１０１における送信側トランスポート層処理部２０１において、送信側のトランスポート層のレート制御と必要な情報取得処理とを行う。送信側データリンク層処理部２０３は、送信側端末１０１におけるネットワーク処理のうち、データリンク層の伝送処理を行う。
【００４３】
受信側端末１０３は、図３に示すように、受信側アプリケーション２４１と、受信側トランスポート層処理部２１３と、受信側トランスポートレート制御部２３５と、受信側データリンク層処理部２１１と、受信側データリンクレート制御部２３３と、を備える。
【００４４】
受信側アプリケーション２４１は、データの受信要求と指示とを行う。受信側トランスポート層処理部２１３は、図２にも示したが、受信側端末１０３のネットワーク処理のうち、トランスポート層の受信処理を行う。受信側トランスポートレート制御部２３５は、受信側端末１０３における受信側トランスポート層処理部２１３において、受信側のトランスポート層のレート制御と必要な情報取得処理とを行う。受信側データリンク層処理部２１１は、図２にも示したが、受信側端末１０３におけるネットワーク処理のうち、データリンク層の処理を行う。受信側データリンクレート制御部２３３は、受信側端末１０３の受信側データリンク層処理部２１１において、受信側データリンクのレート見積もりと必要な情報取得処理とを行う。これらの構成のうち、受信側トランスポートレート制御部２３５は、本発明に係る伝送レート制御部の一実施形態である。
【００４５】
アクセスポイント１０５は、図３に示すように、ブリッジ機構２０７と、無線リンク層処理部２０９と、有線リンク層処理部２０５と、を備える。
【００４６】
ブリッジ機構２０７は、無線ネットワークと有線ネットワークの間のネットワークブリッジ機能の処理を行う。無線リンク層処理部２０９は、ブリッジ機構２０７のうち無線ネットワークのデータリンク層の処理を行う。有線リンク層処理部２０５は、ブリッジ機構２０７のうち有線ネットワークのデータリンク層の処理を行う。
【００４７】
アクセスポイント１０５の無線リンク層処理部２０９には、伝送されるデータパケット（省略して「パケット」とも呼ぶ）１２１を一時的に保持するバッファが設けられている。アクセスポイント１０５は、一方から他方へデータパケットを転送する際、他方のネットワークに輻輳が生じてデータパケットを送出できない場合に、このデータパケットをバッファに一時的に蓄える。そして、アクセスポイント１０５は、他方のネットワークの輻輳が回復したら、バッファに蓄えたデータパケットを他方のネットワークを介して転送する。このバッファの作用により、アクセスポイント１０５は、ネットワークの一時的な輻輳に対して、データパケットの損失をある程度回避することができる。
【００４８】
次に、上記のネットワーク構成において、データの伝送処理の流れについて説明する。
【００４９】
送信側端末１０１は、送信側トランスポート層処理部２０１から送信側データリンク層処理部２０３を介して、アクセスポイント１０５へ向けてデータパケット１２１を送信する。アクセスポイント１０５の有線リンク層処理部２０５は、データパケット１２１を受信し、ブリッジ機構２０７を通じて、データを無線リンク層処理部２０９へ中継する。アクセスポイント１０５は、無線リンク層処理部２０９と受信側端末１０３の受信側データリンク層処理部２１１を介して、無線リンクを通じてデータパケット１２１を受信側端末１０３へ送信する。受信側データリンク層処理部２１１は、受信側端末１０３内の受信側トランスポート層処理部２１３へデータパケット１２１を転送する。
【００５０】
アクセスポイント１０５と受信側端末１０３とは、エッジネットワーク１１３で無線の輻輳または衝突により伝送エラーが生じると、データ再送を試行する。このデータ再送は、受信側データリンク層処理部２１１と無線リンク層処理部２０９とにより、データリンク層の伝送処理として実行される。
【００５１】
また、受信側トランスポート層処理部２１３と送信側トランスポート層処理部２０１とは、ネットワークの混雑状況に応じて、まとめて伝送するデータ量、すなわち、１回の確認応答を必要とする伝送データの量を変化させる。一般には、このデータ量の可変制御をウインドウ制御と呼び、ひとまとめのデータを受けるバッファのことをウインドウバッファと呼ぶ。また、このひとまとめのデータ量は、ウインドウサイズと呼ぶ。
【００５２】
上記のデータ伝送中、コアネットワーク１０２またはエッジネットワーク１１１，１１３に何らかの障害が起きて伝送エラーが生じると、送信側トランスポートレート制御部２３１は、伝送エラーが生じないレベルに伝送レートを低くする。
【００５３】
また、ネットワークの障害が取り除かれて伝送レートが回復可能になったときには、次に示すレート制御を行う。つまり、受信側トランスポートレート制御部２３５と送信側トランスポートレート制御部２３１とは、協働し、次に示すレート制御により伝送レートの回復を図る。
【００５４】
次に、実施の形態１におけるレート制御について、説明する。
【００５５】
図４は、実施の形態１の受信側端末１０３と送信側端末１０１とにより行われるレート制御の手順を示すフローチャートである。
【００５６】
図４のレート制御は、通常のデータ伝送の進行中に行われる。具体的には、図４のレート制御は、送信側端末１０１からＡＶストリーミングデータを受信する通信セッションの開始から終了までを通して、定期的に繰り返し実行される。或いは、図４のレート制御は、トランスポート層情報またはデータリンク層情報に基づきネットワーク状況に変化が検出された際に実行されるようにしてもよい。また、図４のレート制御は、データパケットの損失が生じた場合には、高い頻度で実行され、データパケットの損失がない場合には、低い頻度で実行されるようにしてもよい。
【００５７】
なお、図４のレート制御の処理のうちステップＳ８０７〜Ｓ８０９の処理は、ネットワーク状況が輻輳から回復する際に実行される処理である。ネットワーク状況が輻輳へ陥る際に実行されるレート制御の処理では、ステップＳ８０７は省略され、ステップＳ８０８，Ｓ８０９の「リカバリスケジュール」は、単に「伝送レートのスケジュール」に変更される。
【００５８】
ステップ８０１において、受信側データリンクレート制御部２３３は、可変ウインドウバッファを用いてデータリンク層のリトライ率を算出する。
【００５９】
ここで、リトライ率とは、アクセスポイント１０５と受信側端末１０３との間で行われるデータリンク層におけるデータ再送制御の試行率である。また、可変ウインドウバッファとは、上述したトランスポート層のウインドウ制御におけるウインドウサイズに対応させて、サイズが変化するリトライ率算出用のバッファである。リトライ率の算出方法の詳細は後述する。
【００６０】
次に、ステップＳ８０２において、受信側データリンクレート制御部２３３は、データリンク層のリトライ率を用いて、データリンク層の実効ビットレートを概算する。ここで、実効ビットレートとは、データリンク層における伝送レートを表わすもので、データリンク層からトランスポート層へ転送される有効なデータ（ペイロードデータなど）の伝送レートである。受信側データリンクレート制御部２３３は、トランスポート層のフィードバックパケット１２３のやり取り、および、データリンク層の再送制御に伴う無効なデータ送信などを反映させて、実効ビットレートを算出する。実効ビットレートの算出方法の詳細は後述する。
【００６１】
次に、ステップＳ８０３において、受信側データリンクレート制御部２３３は、受信側トランスポートレート制御部２３５へ、輻輳位置を識別するために必要なデータリンク層の情報を伝達する。データリンク層の情報には、例えば、無線ノイズの大小情報、電波強度の良否情報、データ再送の率および回数、パケット到着間隔、および、アクセスポイントのバッファ使用率（バッファ負荷とも呼ぶ）などが含まれる。
【００６２】
以下の説明では、このデータリンク層の情報を、ネットワーク階層をまたぐ情報であることからクロスレイヤ情報とも呼ぶ。
【００６３】
なお、受信側データリンク層処理部２１１は、この処理で必要となるため、アクセスポイント１０５のバッファの使用率の情報を取得する機能を備えている。
【００６４】
次に、ステップＳ８０４において、受信側トランスポートレート制御部２３５は、トランスポート層の情報と、受信側データリンクレート制御部２３３からのクロスレイヤ情報とを解析する。そして、この解析に基づいて、受信側トランスポートレート制御部２３５は、図５に示すように、現在のネットワーク状況（輻輳、回復、輻輳位置、輻輳の要因などを含む）を識別する。このトランスポート層の情報には、ＲＴＴ（Round-Trip Time）などが含まれる。
【００６５】
図５は、実施の形態１のネットワーク輻輳位置の識別パターンと伝送方針の決定パターンとの一例を示す図表である。本実施の形態では、図５において、トランスポート層の情報をＬ４情報、データリンク層の情報（クロスレイヤ情報）をＬ２情報と記している。
【００６６】
この識別処理により、受信側トランスポートレート制御部２３５は、図５の「ネットワーク状況推定」の列に示されるネットワーク状況の識別結果を得る。この識別結果としては、例えば、コアネットワーク（有線区間）１０２の輻輳、または、エッジネットワーク（無線区間）１１３の輻輳などが含まれる。また、この識別結果としては、エッジネットワーク（無線区間）１１３の輻輳からの回復、無線ノイズによるエッジネットワーク（無線区間）１１３の一時的な障害などが含まれる。
【００６７】
次に、ステップＳ８０５において、受信側トランスポートレート制御部２３５は、識別したネットワーク状況に基づいて、図５の「伝送方針」の列に示すように、現在のデータ伝送の方針を決定する。例えば、ネットワーク状況が有線区間の輻輳であると推定した場合、受信側トランスポートレート制御部２３５は、長い期間伝送レートを低くする方針（従前のレート制御の方針）とする。また、無線区間の輻輳と推定した場合、受信側トランスポートレート制御部２３５は、伝送レートを下げる方針とする。また、無線区間の輻輳からの回復状態と推定した場合、受信側トランスポートレート制御部２３５は、伝送レートを即座に回復する方針とする。また、無線区間の一時的な無線ノイズによる障害と推定した場合、受信側トランスポートレート制御部２３５は、伝送レートを変化させない、または、伝送レートを小さい幅で下げる方針とする。
【００６８】
次に、ステップＳ８０６において、受信側トランスポートレート制御部２３５は、受信側データリンクレート制御部２３３で算出した実効ビットレートから、トランスポート層で達成できるエンド・ツー・エンドのスループットを算出する。このスループットの算出方法の詳細は後述する。
【００６９】
次に、ステップＳ８０７において、受信側トランスポートレート制御部２３５は、Ｌ４情報とＬ２情報との履歴情報を用いて、必要があれば、トランスポート層の伝送レートを回復させる制御スケジュールの補償を行う。なお、制御スケジュールは、リカバリスケジュールと呼ぶものとする。
【００７０】
ここで、リカバリスケジュールとは、ステップＳ８０５，Ｓ８０６において決定された伝送方針および伝送レート（エンド・ツー・エンドのスループット）のうち、ネットワーク輻輳の回復時に適用するものである。ステップＳ８０５，Ｓ８０６で決定された伝送方針および伝送レートは、アクセスポイント１０５のバッファ使用状況が考慮されていないため、このステップＳ８０７で補償を行う。
【００７１】
受信側トランスポートレート制御部２３５は、この補償処理のために、必要な期間、Ｌ４情報とＬ２情報を履歴情報として保持および管理している。
【００７２】
受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率に基づき、図６に示すリカバリスケジュールの補償パターンに従って、リカバリスケジュールの補償を行う。具体的には、受信側トランスポートレート制御部２３５は、バッファ使用率が少なければ、伝送レートを速やかに上昇させるパターンを選択する。一方、受信側トランスポートレート制御部２３５は、バッファ使用率が多ければ、所定期間、伝送レートを次第に上昇させて補償パターンを選択する。このリカバリスケジュールの補償により、アクセスポイント１０５は所定期間のうちにバッファに溜まっている伝送データを転送させて、バッファをクリアすることができる。
【００７３】
図６は、実施の形態１のリカバリスケジュールの補償パターンの一例を示す図表である。なお、図６は、無線区間の障害から回復する際のリカバリスケジュールに対する補償パターンを示している。受信側トランスポートレート制御部２３５は、有線区間の輻輳から回復する際に、図６に示すリカバリスケジュールの補償は行わない。
【００７４】
なお、スループットを次第に上昇させる補償を行う際、受信側トランスポートレート制御部２３５は、現在の実効ビットレートおよびデータリンク層のリトライ率等の少なくとも一つの情報を利用して、補償量の最適化を図ってもよい。
【００７５】
また、受信側トランスポートレート制御部２３５は、バッファ使用率の情報が取得できない場合、代わりに、ＲＴＴの履歴情報を用いてバッファ使用率を推定し、同様の補償処理を行うことができる。この代替的な処理の詳細は後述する。
【００７６】
次に、ステップＳ８０８において、受信側トランスポートレート制御部２３５は、決定したリカバリスケジュールに基づいて、このスケジュールの実行に必要な情報をフィードバックパケット１２３に入れて送信側端末１０１へ送信する。
【００７７】
フィードバックパケット１２３には、変更後の送信レートの値、変更タイミング、変更にかけるタイムスパン、損失したデータパケットの識別情報、または、有線区間の輻輳に対応した従前のレート制御処理の起動指示などが含まれる。
【００７８】
次に、ステップＳ８０９において、送信側端末１０１の送信側トランスポートレート制御部２３１は、フィードバックパケット１２３に含まれるリカバリスケジュールに従って、伝送レートを実際に回復させるレート制御を行う。
【００７９】
具体的には、送信側トランスポートレート制御部２３１は、フィードバックパケット１２３の内容に基づいて、送信レートの変更、或いは、従前のレート制御処理の起動を行う。また、送信側トランスポートレート制御部２３１は、フィードバックパケット１２３の内容に基づいて、損失したデータパケットの速やかな再送を行う。この損失したデータパケットを速やかに再送する処理の詳細については後述する。
【００８０】
上記一連のレート制御によれば、例えば、コアネットワーク１０２の輻輳から回復する際には、輻輳を悪化させないように伝送レートを緩やかに上昇させる通常のレート制御が実現される。また、無線区間のエッジネットワーク１１３の一時的なノイズ障害または輻輳から回復する際には、無駄に低い伝送レートが続かないように、伝送レートを適宜速やかに上昇させるレート制御が実現される。
【００８１】
次に、上述したレート制御の幾つかのステップのより詳細な具体例を説明する。
【００８２】
［リトライ率の算出方法（Ｓ８０１）］
ステップＳ８０１のリトライ率の算出は、受信側端末１０３と送信側端末１０１の伝送経路に含まれる無線リンク伝送状況を把握し、実効ビットレートの推定を行うために、次のように行われる。
【００８３】
先ず、ステップＳ８０１の算出処理のために、受信側データリンクレート制御部２３３は、常時、無線区間の再送に伴うスループットの損失分を特定するための統計データを作成する。この統計データの作成には、ウインドウを基礎とした統計生成器が使用される。ウインドウとは、１回のリトライ率を算出するために統計データを取得する期間を表わし、また、リトライ率算出用の可変ウインドウバッファのサイズにも対応する。
【００８４】
図７は、リトライ率を算出するための可変ウインドウバッファ５００の構成例を示す。可変ウインドウバッファ５００は、ウインドウサイズのシフトレジスタにより構成される。可変ウインドウバッファ５００には、最新のリトライ履歴情報５０１が保存されるとともに、現時点のリトライ情報５０５が順次更新入力されることで、過去のリトライ履歴情報５０３が可変ウインドウバッファ５００上で順次シフトされる。ここで、リトライ情報およびリトライ履歴情報とは、対象の時点におけるデータ再送の有無を示す情報である。
【００８５】
可変ウインドウバッファ５００には、リトライ情報の履歴を保持するためにウインドウサイズに対応する長さのシフトレジスタが使用される。ここで言うウインドウサイズとは、前述したトランスポート層のウインドウ制御におけるウインドウサイズのことである。図７の例では、ウインドウサイズは１２８個のパケットである。このため、可変ウインドウバッファ５００には１２８ビットのシフトレジスタを使用している。トランスポート層のウインドウ制御におけるウインドウサイズが変化すれば、可変ウインドウバッファ５００もウインドウサイズにあわせてサイズを変化させる。
【００８６】
受信側データリンクレート制御部２３３は、データリンク層でパケットが受信される度に、シーケンス番号が順序通りであるかどうかチェックする。シーケンス番号が順序通りでない場合には、受信側データリンクレート制御部２３３は、無線区間でパケットロスがあると予測する。そして、受信側データリンクレート制御部２３３は、リトライ限界の回数まで再送が試行されたと推定し、可変ウインドウバッファ５００にリトライ限界の回数分「１」の値を書き込む。この書き込みにより、可変ウインドウバッファ５００には、リトライを表わす「１」の値が、リトライ限界回数分左にシフトされながら書き込まれる。
【００８７】
また、受信したパケットが順序通りのシーケンス番号をもつ場合、受信側データリンクレート制御部２３３は、再送インジケータが受信データパケット１２１に関連付けられているか否かをチェックする。再送インジケータが有効であれば、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータを左へＳ回ビットシフトし、最初からＳ−１回のビットシフトではリトライを表わす「１」の値を入力する。また、最後のビットシフトでは、受信側データリンクレート制御部２３３は、リトライ無しを表わす「０」の値を入力する。ここで、Ｓはリトライの失敗率であり、後述するようにノイズレベルと信号強度によって決定される。
【００８８】
一方、順序通りのシーケンス番号の付いたパケットが受信され、再送インジケータが何も設定されていない場合には、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータを左へ１回ビットシフトさせる。そして、受信側データリンクレート制御部２３３は、リトライ無しを表わす「０」の値を入力する。
【００８９】
リトライの計数値は、初期化時に”０”に設定される。受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータをビットシフトさせる度に、リトライの計数値を更新する。具体的には、ビットシフトの度に、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００から出ていくビット値（例えば１２８ビット番目の値）と、入力されるビット値（例えば１ビット番目の値）とを比較する。そして、これら二つが同じであれば、受信側データリンクレート制御部２３３は、リトライの計数値を変更しない。出ていくビット値が「１」であり、入力されるビット値が「０」であれば、受信側データリンクレート制御部２３３は、リトライの計数値をデクリメントする。但し、リトライの計数値が「０」である場合には、そのままとする。また、出ていくビット値が「０」であり、入力されるビット値が「１」であれば、受信側データリンクレート制御部２３３は、リトライの計数値をインクリメントする。
【００９０】
ウインドウ期間内のリトライ率”Retry_Rate”は、次の式により、リトライの計数値”Retry_Count”と、ウインドウサイズ”Window_Size”から算出可能である。
【数１】
図７の具体例では、Window_Sizeは「１２８」である。
【００９１】
前述したように、ウインドウサイズは、データ伝送の状況に依存して変化する。ウインドウサイズが変更されると、リトライの計数値は、「０」または新たにサイズ変更された可変ウインドウバッファ５００内で「１」の値を持つビットの個数に再設定される。例えば、ウインドウサイズが６４パケットに変更される場合には、旧可変ウインドウバッファ５００の１〜６４ビット番目のみの値が維持される。この場合、リトライの計数値は、１ビット番目から６４ビット番目までの中で「１」の値をとるビットの個数に設定される。
【００９２】
なお、上記の例では、リトライ率を算出するために導入されるウインドウの長さは、パケット単位で制御される構成とした。この制御は、リトライ率を推定する上で簡単で容易な方法である。しかし、長時間に渡りパケットが受信されないなどの深刻な障害の影響を避けるために、ウインドウは、時間を基礎として可変制御される構成としてもよい。この場合、パケットが受信されないまま、予め設定されたパケット送信タイマーの計時が終了する（タイムアウト）度に、受信側データリンクレート制御部２３３は、可変ウインドウバッファ５００のデータを左へビットシフトする。そして、受信側データリンクレート制御部２３３は、リトライを表わす「１」の値を可変ウインドウバッファ５００に新たに入力する。この場合、リトライ計数値は、パケットの受信またはタイムアウトによって更新される。
【００９３】
また、上記の例では、可変ウインドウバッファ５００は、ウインドウサイズの変更に伴いそのサイズを変動させる構成とした。しかし、リトライ率を算出する構成は、ウインドウサイズ毎に用意された長さの異なる複数のシフトレジスタを使用する構成としてもよい。この場合でも、ウインドウサイズが変わる際に、受信側データリンクレート制御部２３３は、使用するシフトレジスタをウインドウサイズの対応するものに変更すればよい。
【００９４】
なお、受信データパケット１２１が再送データであるか否かは、受信データパケット１２１の無線リンク・ヘッダの再送マーキングの有無により判別できる。例えば、無線リンクがＩＥＥＥ８０２．１１（非特許文献１０を参照）の技術を使用している場合、ヘッダは、そのパケットが再送であるか否かのインジケータを持っている。
【００９５】
また、ＩＥＥＥ８０２．１１において、アクセスポイント１０５は、パケットを黙って廃棄するまでに４〜７回のパケットの再送が可能である。また、ＩＥＥＥ８０２．１１パケットでは、データリンク層のヘッダが、管理フレームとデータフレームの両方で共有されるシーケンス番号も提供する。したがって、受信側データリンク層処理部２１１は、シーケンス番号Ａのデータパケット１２１を受信すると、それ以前の最後に受信成功したパケットのシーケンス番号Ｂと、シーケンス番号を比較する。そして、受信側データリンク層処理部２１１は、新たに受信した管理フレームの数Ｃに基づく修正を行うことによって、何個のデータパケットを損失したかを推定できる。
【００９６】
また、リトライの失敗率Ｓの値は、例えば、ノイズレベルまたは信号強度レベルといった無線状況に基づいて決定され得る。Ｓの値は、１〜Ｔの範囲に入る。ここで、Ｔは、無線リンク層処理部２０９において、その回数以上のリトライがあった場合に、送信失敗処理へ遷移するリトライ限界数である。一般に、ノイズレベルがより高い場合、または信号強度がより低い場合、ＳはＴにより近い値になり、逆の場合には、Ｓは１に近くなる。Ｓの値は、例えば、次の無線パラメータ間の所定のマッピングに基づいて、決定することも可能である。無線パラメータとは、例えば、ノイズレベル、アップリンクの失敗率、低減化期間、物理層のキャリア検知統計値、アップリンク送信試行の衝突率、前に演算されたリトライ率Ｒ等である。この所定のマッピングを実現するデータは、広範な測定とシミュレーションにより作成され、受信側端末１０３の無線モジュール用のファームウェアの一部とし、受信側データリンクレート制御部２３３内に記憶されること可能である。この場合、ユーザは、ネットワークを介して更新データをダウンロードすることにより、マッピングのデータを更新することができる。
【００９７】
また、ウインドウサイズWindow_Sizeは、次のように動的に変化させてもよい。すなわち、受信側データリンクレート制御部２３３は、例えば、ノイズレベル、信号強度、及び前回算出されたリトライ率といった無線リンクのパラメータを利用して、使用すべき適切なウインドウの長さを決定してもよい。具体的には、ノイズレベルと信号強度が大きく変化せず、且つ、リトライ率が両方向に突然変化する、即ち、時折上昇し時折下降する場合、受信側データリンクレート制御部２３３は、ウインドウの長さを比較的大きな値に維持する。これにより、一時的な障害によるリトライ率の変化は、取り除かれる。しかし、演算されたリトライ率と共にノイズレベルと信号強度が変化している場合、受信側データリンクレート制御部２３３は、無線環境の変化を即座に反映できるように、ウインドウの長さをより小さく縮小する。例えば、ノイズレベルが高くなる場合および／または信号強度があるしきい値以下に低下し、且つ、演算されたリトライ率が上昇している場合には、ウインドウの長さはより短いものに縮小される。同様に、ノイズレベルが突然低くなった場合および／または信号強度がより高くなった場合、且つ、演算されたリトライ率が下降しているときには、ウインドウの長さはより短くされる。これにより、受信側データリンクレート制御部２３３は、無線環境の変化に十分速く対応できるリトライ率を算出できる。
【００９８】
［実効ビットレートの概算方法（ステップＳ８０２）］
一般に、無線リンクは、様々な状況に対応して使用される多様なリンクレートを持つ。例えば、ＩＥＥＥ８０２．１１（非特許文献１０）は、様々な符号化方式と変調方式に対応する様々なリンクレートを定義している。様々な無線状況に応じて、無線リンク層処理部２０９は、信頼性があり効果的な通信を成し遂げるために伝送レートを調整する。しかし、リンクレートの選択変更は、また、実際のトランスポート層のスループットに効果および影響がある。また、リンクレートの異なる複数種類の伝送処理には、それぞれ異なるオーバヘッドが含まれる。
【００９９】
例えば、選択したリンクレートが２４Ｍｂｐｓであるならば、無線リンクにおけるフィードバック制御の伝送には、そのレートの半分である１２Ｍｂｐｓしか使用できない。同時に、例えば、ビーコンフレームのように、全ての端末へブロードキャストされる管理フレームは、上記のレートよりもかなり低いレートで伝送される必要がある。
【０１００】
同様に、異なる無線技術は、オーバヘッドに大きな影響を与え得る。例えば、ＩＥＥＥ８０２．１１ｂモードが使用される場合には、共通管理フレーム用に使用されるレートはより低くされるため、管理フレームを送信するためのオーバヘッドはかなり高くなる。そして、ＩＥＥＥ８０２．１１ｎ（非特許文献１１）モードが、複数アンテナの同時利用（ＭＩＭＯ：Multiple Input Multiple Output）で使用される場合には、オーバヘッドは一様でないことがあり得る。これは、データリンク層のヘッダが数ストリームの一つでのみで伝送されるためである。
【０１０１】
したがって、トランスポート層での実効ビットレートを正確に推定するためには、受信側データリンクレート制御部２３３は、リアルタイムの物理層の情報を利用する。この情報は、受信データパケットに付属しており、妥当なパラメータを決定するために使われる。例えば、無線アクセス技術がＩＥＥＥ８０２．１１（非特許文献１０、非特許文献１１）である場合には、以下の情報が使用される。
【０１０２】
‐ オペレーションモード情報：例えば、ＩＥＥＥ８０２．１１ｂ／ｇ／ａ／ｎの各モードなど、該当するオペレーションモード
‐ 暗号化モード情報：暗号化が実施される場合、例えば、ＡＥＳ（Advanced Encryption Standard）−１２８、３ＤＥＳ（3 Data Encryption Standard）など、暗号化アルゴリズムの種別
‐ リンクレート：無線リンクの動作モード（オペレーションモードとも呼ばれる）に応じたリンクレート
リンクレートは、様々な形式で表現され得る。例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードの場合、リンクレートは、Ｍｂｐｓ単位で表現される。一方、動作モードがＩＥＥＥ８０２．１１ｎであれば、リンクレートは、ＭＣＳ（Modulation and Coding Scheme）インデックスの形で表現される。また、リンクレートは、ＭＣＳインデックスとキャリア帯域幅を組み合わせると、適切なリンクレートを導き出せる。
【０１０３】
‐ ビーコン間隔
‐ ショートガードインターバルの使用の有無
‐ ＰＬＣＰヘッダのオーバヘッド
ＰＬＣＰ（Physical Layer Convergence Protocol/Procedure）ヘッダ長は、変調及び符号化方式に基づいて導出可能である。そして、この変調及び符号化方式は、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードではリンクレート値から導出可能である。また、ＩＥＥＥ８０２．１１ｎモードでは、ＭＣＳインデックスから導出可能である。
‐ ＩＥＥＥ８０２．１１ｎモード使用時の使用ストリーム数
ストリーム数に基づいて、リンク層ヘッダのオーバヘッドが算出可能である。
【０１０４】
なお、受信側データリンク層処理部２１１において、実効ビットレートの演算に使用可能な上記以外の他の情報があることは当業者にとって明らかである。何れの情報を使用するかは、本発明の概念に影響することではない。
【０１０５】
上記の情報を使用して、受信側データリンクレート制御部２３３は、次のようにして、無線リンク上でサポート可能なトランスポート層での実効ビットレートを推定する。先ず、受信側データリンクレート制御部２３３は、動作モードをチェックする。動作モードがＩＥＥＥ８０２．１１ａ／ｂ／ｇのうちのいずれか一つであるならば、受信側データリンクレート制御部２３３は、対応する一組の実効ビットレート演算式を使用する。
【０１０６】
まず、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードの無線リンクの実効ビットレート推定は、演算式（１）を用いて計算する。この演算式（１）では、次の各時間のオーバヘッドを反映させた実効ビットレートＥｂｔ（ｍｂｐｓ）の計算が行われる。
【数２】
【０１０７】
式（１）中の各パラメータは、次の通りである。
‐ Ｐｓｉｚｅ：トランスポート層のビット単位のペイロードサイズ
‐ Ｐｔ：データリンク層と物理層のオーバヘッドを含む実際のデータパケットを送信するのに要する時間
‐ Ｆｔ：対応する無線リンクのフィードバック制御用のデータ送信に要する時間
‐ [1-(Blength/Rbeacon)/Binterval]：ビーコンフレームを反映させた伝送効率
‐ (1-Retry_Rate)：データリンク層のリトライ率を反映させた伝送効率
【０１０８】
‐ Ｂｌｅｎｇｔｈ：ビーコンの長さ
‐ Ｂｉｎｔｅｒｖａｌ：ビーコンの間隔
‐ Ｒｂｅａｃｏｎ：ビーコン管理フレームを転送するためのレート
‐ Ｒｅｔｒｙ＿Ｒａｔｅ：ステップＳ８０１で算出されたリトライ率
【０１０９】
次に、データリンク層と物理層のオーバヘッドを含む実際のデータパケットを送信するのに要する時間Ｐｔは、次式（２）で求めることができる。
【数３】
【０１１０】
式（２）中の各パラメータは、以下の通りである。
‐ Ｐｓｉｚｅ：トランスポート層のビット単位のペイロードサイズ
‐ ＤａｔａＲａｔｅ：受信側データリンク層処理部２１１によって、受信したデータパケット１２１に含まれるＭｂｐｓ（Mega bits per second）単位の受信レート
‐ Ｃｐｒｏｂ：衝突の確率
衝突の確率の値は、受信側データリンク層処理部２１１によって検知されたノイズレベルの変化によって調整され得る。これは、受信側データリンク層処理部２１１内にマッピング・テーブルとして保存可能である。
‐ ａ：ＩＥＥＥ８０２．１１（非特許文献１０）に定義され、ＲＴＳ／ＣＴＳ（Request to Send / Clear to Send）機構が有効であるか否かに依存する値
「ａ」は、ＲＴＳ／ＣＴＳが無効である場合には「０」であり、有効であれば「１」である。
‐ ＳＩＦＳ：短いフレーム間の間隔
‐ Ｂａｃｋｏｆｆ：平均のデータリンク層の低減化ウインドウ（window）サイズ
このサイズは、無線環境情報に基づいて動的に補正可能でもある。例えば、データリンク層が同一のアクセスポイント１０５に結び付いた無線局の数が多いこと、またはチャネル利用率が高いことを検出した場合には、この値はより高い値に設定され得る。受信側端末１０３は、ＩＥＥＥ８０２．１１（非特許文献１０）に定義されているように、ビーコンフレーム中のＢＳＳ（Basic Service Set）のＬＯＡＤ（負荷情報）からこれらの情報を取得できる。
【０１１１】
‐ Ｔｓｌｏｔ：スロット時間
‐ (MAC、IP、Layer 4)Protocol_header：それぞれ、データリンク層、ネットワーク層、及びトランスポート層に対応するそれぞれの層で使用されるヘッダ
‐ Ｔａｉｌ：最後尾のビット
‐ Ｒｓｉｚｅ：ＲＴＳのサイズ
‐ Ｃｓｉｚｅ：ＣＴＳのサイズ
‐ Ｂ：ＣＴＳ‐ＲＴＳ（Clear to Send - Request to Send）方式が使用される場合に「１」、使用されない場合は「０」
‐ Ａｓｉｚｅ：ＩＥＥＥ８０２．１１ ＡＣＫのサイズ
‐ Ｒｃｔｌ：制御フレームの送信レート
‐ Ｐｒｅａｍｂ：プリアンブルの時間幅
‐ ＰＬＣＰ：物理層ヘッダの時間幅
‐ Ｓｉｇｅｘｔ：信号拡張部分の時間幅
【０１１２】
次に、対応する無線リンクのフィードバック制御用のデータ送信に要する時間Ｆｔは、次式（３）で求めることができる。
【数４】
【０１１３】
式（３）中のパラメータは、以下の通りである。
‐ Ｆｅｅｄｂａｃｋ＿ｓｉｚｅ：例えば、拡張オプションの付いたＴＣＰ ＡＣＫといったトランスポート層のフィードバックパケット１２３のサイズ
その他のパラメータは、式（２）で説明したものと同じである。
【０１１４】
なお、ＳＩＦＳ、Ｔｓｌｏｔ、Ｐｒｅａｍｂ、ＰＬＣＰ、Ｓｉｇｅｘｔ、ＭＡＣ、Ｔａｉｌ、Ｒｓｉｚｅ、Ｃｓｉｚｅ、Ｒｓｉｚｅ、Ｂｌｅｎｇｔｈ、Ｂｉｎｔｅｒｖａｌの各パラメータの値は、オペレーションモードとアクセスポイント１０５によって選択されたデータレートに依存する。受信側データリンク層処理部２１１は、受信したデータパケット１２１のデータレートをチェックすることによって、変調及び符号化方式を推定できる。この推定結果を用いて、受信側データリンク層処理部２１１は、ＩＥＥＥ８０２．１１（非特許文献１０）での定義に基づき、上記のパラメータの値を決定することができる。
【０１１５】
また、Ｒｃｔｒｌ及びＲｂｅａｃｏｎは、次の幾つかの設定に依存する。
設定１：データパケット送信のためにアクセスポイント１０５によって選択されたデータレート
設定２：例えば、ＩＥＥＥ８０２．１１ｇと８０２．１１ｂモード、またはＩＥＥＥ８０２．１１ｇモードのみというようなアクセスポイント１０５のオペレーションモード
【０１１６】
本実施の形態の実効ビットレートの演算式（１）では、無線リンクのフィードバック制御でのやり取り、データリンク層でのリトライ率および最大再送回数などが考慮される。具体的には、この演算式（１）では、無線メディアアクセスの衝突、および、それより前に推定されたリトライ率による潜在的なバックオフ等が考慮される。したがって、この演算式（１）により、受信側データリンクレート制御部２３３、受信側データリンク層処理部２１１の実効ビットレートをより厳密に算出することができる。
【０１１７】
なお、実効ビットレートの演算式（１）は、無線リンクでのデータ伝送において、暗号化通信が使用されないことを前提とした演算式である。なお、これ以外の種類の設定を反映するように、本演算式は、容易に変更可能であることは当業者にとって明らかである。例えば、暗号化が実施される場合、演算式中のＰｓｉｚｅは、暗号化前の実際のトランスポート層パケットのペイロードサイズに修正される。また、それ以外のＰｓｉｚｅ、ネットワーク層及びトランスポート層プロトコルヘッダは、すべて、暗号化後のサイズに修正される。これらの細かな変更は、本発明の概念に影響しないことは明白である。
【０１１８】
また、受信側データリンクレート制御部２３３は、特にトランスポート層プロトコルヘッダについて、すべての情報をもたない場合もある。したがって、一つの代替的な方法として、受信側データリンクレート制御部２３３は、受信側データリンク層処理部２１１に関する演算だけを実行する構成としてもよい。この場合、受信側データリンクレート制御部２３３は、途中までの演算結果を、クロスレイヤ情報と共に受信側トランスポート層処理部２１３内の受信側トランスポートレート制御部２３５まで送る。次に、受信側トランスポートレート制御部２３５は、受信側トランスポート層処理部２１３に知らされたトランスポート層の情報を付加して、実効ビットレートの演算を完了する。
【０１１９】
次には、無線リンクがＩＥＥＥ８０２．１１ｎモードで動作している場合の、別の実効ビットレートEbtの算出式（４）を示す。
【０１２０】
【数５】
【０１２１】
式（４）中の各パラメータは、次の通りである。
‐ Ｐｓｉｚｅ2：トランスポート層のビット単位のペイロードサイズ
‐ Ｐｈｙｔ：データパケットの送信に付随する物理層のオーバヘッドの処理時間
‐ Ｍａｃｔ：データパケットの送信に付随するデータリンク層のオーバヘッドの処理時間
‐ Ｔｒｐｔ：ペイロードを送信するのに要する時間
‐ Ｔｒｆｔ：トランスポート層のフィードバックパケット１２３を送信するのに要する時間
‐ [1-(Blength/Rbeacon)/Binterval]：ビーコンフレームを反映させた伝送効率
‐ (1-Retry_Rate)：データリンク層のリトライ率を反映させた伝送効率
【０１２２】
次に、トランスポート層のビット単位のペイロードサイズＰｓｉｚｅ２は、次式（５）で求めることができる。
【数６】
【０１２３】
式（５）中の各パラメータは、以下の通りである。
‐ Ｌ２＿ｆｒａｍｅ＿ｓｉｚｅ：Ａ−ＭＰＤＵ（Aggregated Mac Protocol Data Unit）の連結後に、伝送のために物理層に渡されるＰＤＵ（Protocol Data Unit）のサイズ
‐ Nmber_of_frames_in_A‐PMDU：Ａ−ＭＰＤＵフレームに含まれるフレームの数
このフレームの数は、受信側データリンク層処理部２１１内に設定しておくことができ、アクセスポイント１０５へ通知される。また、受信側データリンク層処理部２１１は、リアルタイムの受信データパケットからこの値を読み込むことができる。
‐ Ｈｅａｄｅｒ＿ｏｖｅｒｈｅａｄｓ：データリンク層、ネットワーク層、トランスポート層のヘッダのサイズ
‐ ＡＭＰＤＵ＿ｏｖｅｒｈｅａｄ：Ａ−ＭＰＤＵパケット構成中で使用される、Ａ−ＭＰＤＵ区切り文字、Ａ−ＭＰＤＵパディング、等のサイズ
【０１２４】
次に、データパケットの送信に付随する物理層のオーバヘッドの処理時間Phytは、次式（６）で求めることができる。
【数７】
【０１２５】
式（６）中の各パラメータは、以下の通りである。
‐ Ｎ＿ｔｘ：データの伝送に使用される空間的ストリームの数
この空間的ストリームの数は、データリンク層のパラメータから取得可能である。
‐ Ａ：ＣＴＳ（Clear to Send）‐ｔｏ‐ｓｅｌｆ方式が使用される場合に「１」、使用されない場合に「０」
‐ Ｂ：ＣＴＳ‐ＲＴＳ（Clear to Send - Request to Send）方式が使用される場合に「１」、使用されない場合は「０」
‐ Preamb(le)、SIFS、DIFS：ＩＥＥＥ８０２．１１ｎ（非特許文献１１）に定義されているデータリンク層で使用されるパラメータ
【０１２６】
次に、データパケットの送信に付随するデータリンク層のオーバヘッドの処理時間Ｍａｃｔは、次式（７）で求めることができる。
【数８】
式（７）中の各パラメータは、以下の通りである。
‐ Ａｓｉｚｅ：ＩＥＥＥ８０２．１１ ＡＣＫのサイズ
‐ Ｃｓｉｚｅ：ＣＴＳのサイズ
‐ Ｒｓｉｚｅ：ＲＴＳのサイズ
‐ Ｃｔｌ＿ｒａｔｅ：データリンク層で制御フレームを送信するために使用されるレート
その他のパラメータは、式（６）で説明したものと同じである。
【０１２７】
次に、ペイロードを送信するのに要する時間Ｔｒｐｔは、次式（８）で求めることができる。
【数９】
式（８）中の各パラメータは、以下の通りである。
‐ L2_frame_size：Ａ−ＭＰＤＵ（Aggregated Mac Protocol Data Unit）の連結後に、伝送のために物理層に渡されるＰＤＵ（Protocol Data Unit）のサイズ
‐ ＤａｔａＲａｔｅ：データパケットの送信レート
この送信レートは、ＭＣＳインデックスとチャネル帯域幅値から導出可能である。
【０１２８】
次に、トランスポート層のフィードバックパケット１２３を送信するのに要する時間Ｔｒｆｔは、次式（９）で求めることができる。
【数１０】
式（９）中の各パラメータは、以下の通りである。
‐ number_of_frames_in_AMPDU：Ａ−ＭＰＤＵフレームに含まれるフレームの数
このフレームの数は、受信側データリンク層処理部２１１内に設定しておくことができ、アクセスポイント１０５へ通知される。また、受信側データリンク層処理部２１１は、リアルタイムの受信データパケットからこの値を読み込むことができる。
‐ Ｆｅｅｄｂａｃｋ＿ｓｉｚｅ：例えば、拡張オプションの付いたＴＣＰ ＡＣＫといったトランスポート層のフィードバックパケット１２３のサイズ
その他のパラメータは、式（８）で説明したものと同じである。
【０１２９】
なお、上記のパラメータのいくつかは、データパケットの受信によって受信側データリンク層処理部２１１が入手可能なその他のパラメータから導出または推量される。例えば、number_of_frames_in_A‐PMDUは、ペイロードサイズＰｓｉｚｅを、次のデータサイズ１〜３の合計で除算することにより導出される。
データサイズ１：Ａ−ＭＰＤＵ中のサブフレームのフレームサイズ
データサイズ２：ＬＬＣ（Logical Link Control）ヘッダのサイズ
データサイズ３：ＩＥＥＥ８０２．１１ｎデータリンク層ヘッダのサイズ
【０１３０】
本実施の形態の実効ビットレートの演算式（４）では、無線送信に使用されるストリームの数、および、物理層におけるフレームの総数が考慮されている。言い換えれば、この演算式（４）は、複数の空間的及び時間的送信ストリーム（Ｎ＿ｔｘにより決定）のデータリンク層での総計（number_of_frames_in_A‐PMDUにより決定）を、考慮したものである。つまり、この演算式（４）は、ＩＥＥＥ８０２．１１ｎの特徴を反映させたものである。
【０１３１】
さらに、この演算式（４）では、物理層とＭＡＣ層のオーバヘッドの時間が十分に考慮される。例えば、受信側データリンク層処理部２１１がデータパケットの送信に使用される二つのストリームを検出した場合、物理層のオーバヘッドは、そのうちの一つのストリーム中にだけ存在することになる。したがって、上記の演算式（４）、（６）において、オーバヘッド時間４０３の値は、プリアンブル時間、ＰＬＣＰ時間、ＳＩＦＳ（Short Inter Frame Space）及びＤＩＦＳ（Distributed Coordination Function Inter Frame Space）時間の合計の２倍に修正されている。一方、アクセスポイント１０５がデータパケットの送信のために単一のストリームを使用する場合、オーバヘッド値は、プリアンブル時間、ＰＬＣＰ時間、ＳＩＦＳ及びＤＩＦＳ時間の合計の４倍に修正されている。
【０１３２】
さらに、この演算式（４）では、ＩＥＥＥ８０２．１１ａ／ｂ／ｇモードの場合と同様に、例えば、ビーコンの送信などの共通管理フレームの送信によるオーバヘッド、及びデータリンク層でのリトライ率についても考慮されている。
【０１３３】
したがって、この演算式（１）により、受信側データリンクレート制御部２３３は、ＩＥＥＥ８０２．１１ｎの無線リンクが選択されている場合に、受信側データリンク層処理部２１１の実効ビットレートをより厳密に算出することができる。
【０１３４】
［データリンク層情報の生成及び伝達処理（Ｓ８０３）］
図４のステップＳ８０３において、受信側データリンクレート制御部２３３は、データリンク層情報（クロスレイヤ情報とも呼ぶ）をデータパケットにタグ付けして、受信側トランスポートレート制御部２３５に送信する。
【０１３５】
このデータリンク層情報（クロスレイヤ情報）は、次の情報を含む。
【０１３６】
‐ 推定された実効ビットレート
‐ データリンク層のパケット損失インジケータ
これは、リンク層のシーケンス番号と管理フレームを追跡することによって、受信側データリンクレート制御部２３３が検出する。このインジケータにより、受信側トランスポートレート制御部２３５は、この成功したパケット送信の前に、パケット損失があったか否かを知ることができる。
‐ 受信したパケットの伝送に際して、データリンク層での再送が実施されたか否かを示す、リトライ指示
‐ データリンク層でのパケット到着間隔時間
‐ アクセスポイント１０５でバッファに格納されたデータを示す、アクセス・ポイントバッファ負荷
これは、受信側データリンクレート制御部２３３が、データパケットヘッダのＱｏＳ（Quality of Service）制御フィールドから取得可能である。
‐ データリンク層のリトライ限界値
‐ ノイズレベルと信号強度
【０１３７】
このデータリンク層情報（クロスレイヤ情報）の伝達は、ネットワーク階層をまたぐクロスレイヤでの情報受け渡しとなり、通常のプロトコル設計ではサポートされてない。このような情報伝送は、受信側データリンクレート制御部２３３がアクセスするネットワークデータバッファ構造を変更して実現できる。具体的には、上記の情報伝達は、上記のネットワークデータバッファのパケット保持用バッファ構造に追加のデータエントリを関連づける実装を行って、上記のデータリンク層情報を登録して伝送することで実現できる。例えば、Ｌｉｎｕｘカーネルでは、sk_buffと呼ばれるバッファに上記情報伝達用のフィールドを追加すればよい。また、FreeBSDカーネルでは、m_buffと呼ばれるバッファに上記情報伝達用のフィールドを追加すればよい。
【０１３８】
［ネットワーク輻輳位置の識別処理（Ｓ８０４）］
図５の表に示したように、受信側トランスポートレート制御部２３５は、データリンク層の情報（Ｌ２情報）と、トランスポート層の情報（Ｌ４情報）とに基づき、ネットワーク状況を推定し識別する。以下、図５の表に示されるネットワーク状況を推定できる理由については、ネットワークの背景動作とともに説明する。
【０１３９】
先ず、コアネットワーク１０２の輻輳によりパケット損失が生じる場合の背景動作について説明する。送信側端末１０１及びその他のノードからのトラフィックが、ネットワーク中に存在する全リンクの容量を超えた場合に、コアネットワーク１０２は、輻輳状態になる。輻輳状態になると、パケットは、ネットワーク中の中継ノードのパケットバッファに蓄積されてゆく。中継ノードのパケットバッファがあふれ出した場合は、パケット損失が発生する。
【０１４０】
このような背景動作から、受信側トランスポートレート制御部２３５は、次の条件１−４を満たした場合に、コアネットワーク１０２中で何らかの輻輳が発生したと推定することができる。
条件１：トランスポート層で観測された往復時間（ＲＴＴ）、またはクロスレイヤ情報に関連付けられたパケット到着間隔時間が、著しく増加した場合
条件２：アクセスポイント１０５のバッファ使用率が増加しないまたは減少した場合
条件３：無線ノイズのノイズレベルが低い場合
条件４：データリンク層の再送がない場合
【０１４１】
次に、受信側のエッジネットワーク（無線区間）１１３でパケット損失が生じる背景動作について説明する。受信側のエッジネットワーク（無線区間）１１３上では、パケット損失が異なる理由により発生する可能性がある。無線区間では、何らかの一時的な無線ノイズまたは電波の干渉が、エラーを伴うパケット受信を引き起こすことがある。エラーを伴うパケット受信は、データリンク層によって振るい落とされる。そのため、トランスポート層などの上位層の処理部は、パケットが損失したと見なす。
【０１４２】
例えば、ＩＥＥＥ８０２．１１などのある種の無線技術は、再送サービスを提供できる。データリンク層（例えば、アクセスポイント１０５の無線リンク層処理部２０９および受信側データリンク層処理部２１１）では、パケットが受信側のデータリンク層によって到着確認の応答がない場合、パケットの再送の試行を数回行なう。この再送サービスは、場合によって、パケットロスの状況をある程度緩和できる。しかし、無線ノイズが強固な場合には、パケットの再送も失敗する。そのため、再送サービスは、パケットロスの状況を緩和できない。
【０１４３】
一方、次の状況では、パケットロスがアクセスポイント１０５で発生する。例えば、ダウンリンクのトラフィック（ネットワークを流れる情報）がアクセスポイント１０５に到着した時、受信側のエッジネットワーク（無線区間）１１３では、電波干渉によって妨害を受けている場合を想定する。この場合は、アクセスポイント１０５から受信側端末１０３へのデータ送信が阻止される。そうなると、パケットは、全てアクセスポイント１０５のバッファに蓄積されるが、長い間干渉が起きていると、バッファがあふれてパケット損失が生じることになる。
【０１４４】
このような背景動作から、受信側トランスポートレート制御部２３５は、次の条件１−３を満たした場合に、受信側のエッジネットワーク（無線区間）１１３で輻輳（アクセス集中）が発生したと推定できる。
条件１：アクセスポイント１０５のバッファ使用率が著しく増加した場合
条件２：無線ノイズのノイズレベルが高い場合
条件３：データリンク層の再送有りが発生した場合
【０１４５】
また、受信側トランスポートレート制御部２３５は、次の条件１−４を満たした場合に、受信側のエッジネットワーク（無線区間）１１３が輻輳（アクセス集中）から回復していると推定できる。
条件１：ＲＴＴの値が高い場合
条件２：アクセスポイント１０５のバッファ使用率が大きい場合
条件３：無線ノイズのノイズレベルが低い場合
条件４：信号強度が高い場合
【０１４６】
また、受信側トランスポートレート制御部２３５は、次の条件１−４を満たした場合に、ＲＴＴの変動が主に無線の一時的障害に起因すると推定できる。
条件１：幾つかのパケットについてのＲＴＴの値が高い場合
条件２：様へアクセスポイント１０５のバッファ使用率が所定レベル未満で小さい場合
条件３：無線リンク品質（例えば、ノイズレベル、信号強度等）が良好な場合
条件４：データリンク層の再送ある場合
【０１４７】
このように、受信側トランスポートレート制御部２３５は、データリンク層の情報とトランスポート層の情報とに基づいて識別処理を行っているので、正確にネットワーク状況を推定し識別することができる。
【０１４８】
なお、図５では、トランスポート層の情報（Ｌ４情報）として、送信側端末１０１の送信側トランスポート層処理部２０１から情報であるＲＴＴを例にとって説明している。しかし、このトランスポート層の情報には、受信側端末１０３のトランスポート層の情報を含めてもよい。例えば、受信側端末１０３のトランスポート層の情報としては、例えば、トランスポート層におけるデータパケット損失に関する情報、または、ウインドウサイズの情報などが含まれてもよい。
【０１４９】
［伝送方針の決定処理（Ｓ８０５）］
ここでは、図５の表に示したように、受信側トランスポートレート制御部２３５が伝送方針を決定する理由について説明する。
【０１５０】
輻輳によるコアネットワーク１０２内でのパケットロスは、通常、深刻な状況であり、復旧するにはより長い時間を要する。このような場合、送信側端末１０１は、自己の送信レートを調整し、輻輳の悪化を防ぐ必要がある。したがって、受信側トランスポートレート制御部２３５は、コアネットワーク１０２の輻輳と推定した場合、さらなる輻輳の悪化を防ぐために、長い期間、伝送レートを低くする伝送方針を決定する。
【０１５１】
また、パケットロスが受信側のエッジネットワーク（無線区間）１１３上の一時的なノイズに起因するものであれば、送信側端末１０１は、送信レートを大幅に下げる必要はない。むしろ、送信側端末１０１は、できるだけ速やかに再送を実行すべきである。したがって、受信側トランスポートレート制御部２３５は、無線区間の一時的な無線ノイズによる障害と推定した場合、速やかな再送が実効されるように、伝送レートを変化なし、または、少しの幅で下げる伝送方針を決定する。
【０１５２】
また、パケットロスがアクセスポイント１０５で発生する場合には、事態はさらに複雑である。無線ノイズまたは電波干渉が持続的な場合、送信側端末１０１は、更なるパケットロスを避けるために送信レートを下げなくてはならない。したがって、受信側トランスポートレート制御部２３５は、無線区間の輻輳と推定した場合、パケットロスを避けるために、伝送レートを下げる伝送方針を決定する。
【０１５３】
一方、無線ノイズまたは電波干渉がもはや存在しない場合は、送信側端末１０１は、トランスポート層のウインドウ制御を用いて送信レートを即座に回復させなくてはならない。したがって、受信側トランスポートレート制御部２３５は、無線区間の輻輳が回復したと推定した場合、伝送レートを即座に回復させる伝送方針を決定する。ただし、無線ノイズまたは電波干渉は繰り返しまたは周期的に生じる可能性があり。そのため、送信側端末１０１は、無線状況を反映するために十分迅速に且つ正しい判断を行なうことが重要である。したがって、受信側トランスポートレート制御部２３５は、繰り返しまたは周期的な無線区間の障害も反映させて伝送方針を決定する構成としてもよい。
【０１５４】
［エンド・ツー・エンドのスループットの概算（Ｓ８０６）］
図４のステップＳ８０６において、受信側トランスポートレート制御部２３５は、前段で得られた無線区間の実効ビットレートを考慮して、最適なエンド・ツー・エンドのスループットを算出する。また、受信側トランスポートレート制御部２３５は、前段で識別されたネットワークの輻輳箇所および輻輳原因を考慮して、最適なエンド・ツー・エンドのスループットを算出する。
【０１５５】
先ず、受信側トランスポートレート制御部２３５は、ネットワーク輻輳がコアネットワーク１０２の輻輳によるものと識別した場合、非特許文献１〜４に示されるような従来のレート制御を起動および実行する。つまり、この場合、受信側トランスポートレート制御部２３５は、従来のレート制御に従ったエンド・ツー・エンドのスループットを算出する。ここで算出されるスループットの詳細については、従来のものと同様なので、説明を省略する。
【０１５６】
また、受信側トランスポートレート制御部２３５は、ネットワーク輻輳が受信側のエッジネットワーク（無線区間）１１３の輻輳によるものと識別した場合、この状況の悪化を避けるように処理を行う。すなわち、受信側トランスポートレート制御部２３５は、トランスポート層の伝送レートを制限すべく、エンド・ツー・エンドのスループットとして直近に得られた実効ビットレートにより達成可能なスループットを算出する。
【０１５７】
具体的には、受信側トランスポートレート制御部２３５は、実効ビットレートからトランスポート層で不要なデータリンク層の情報（Ｌ２情報）を除外して再計算すればよい。その結果、ほぼ伝送レートは変化無し、または、少しの幅で下がるのみである。
【０１５８】
また、受信側トランスポートレート制御部２３５は、ネットワークの状況がエッジネットワーク（無線区間）１１３の輻輳から回復していると識別した場合、送信レートを回復させるように処理を行う。すなわち、受信側トランスポートレート制御部２３５は、送信レートを回復すべく、エンド・ツー・エンドのスループットとして直近の回復時に得られた実効ビットレートによって達成可能なスループットを算出する。
【０１５９】
この場合の実効ビットレートからスループットを算出する具体例は、無線区間の輻輳のときと同一である。無線区間の輻輳のときと、輻輳の回復時とで、実効ビットレートの値が異なることで、算出されるスループットの値は変化する。
【０１６０】
また、受信側トランスポートレート制御部２３５は、ＲＴＴの変動が主に無線区間の一時的障害に起因して生じていると識別した場合、次の対応を行う。受信側トランスポートレート制御部２３５は、直近に算出された無線区間の実効ビットレートに近づけるように、達成可能なエンド・ツー・エンドのスループットの値を増加させていく。この制御は、無線区間の一時的障害に起因したエンド・ツー・エンドのスループットの大きな変動を防ぐ作用を及ぼす。
【０１６１】
具体的には、受信側トランスポートレート制御部２３５は、実効ビットレートからトランスポート層では不要なデータリンク層の情報（Ｌ２情報）を除外した値に一気に増加させるようにスループットを算出してもよい。また、受信側トランスポートレート制御部２３５は、上記の値に線形的に増加させて徐々に近づけるようにスループットを算出してもよい。
【０１６２】
このように算出されたスループットにより、本実施の形態の受信側トランスポートレート制御部２３５と送信側トランスポートレート制御部２３１とは、ネットワークの物理的な限界に近い伝送データのレート制御を実現する。
【０１６３】
［ＲＴＴに基づくリカバリスケジュールの補償（Ｓ８０７）］
ここでは、受信側トランスポートレート制御部２３５が、アクセスポイント１０５のバッファ使用率の情報を利用できず、ＲＴＴの情報からエンド・ツー・エンドのスループットのリカバリスケジュールを補償する場合について説明する。
【０１６４】
前述のように、受信側トランスポートレート制御部２３５は、ネットワーク輻輳の位置推定を実施するときに、ＲＴＴの変動とデータリンク層の状態とを参照する。このうち、ＲＴＴ（伝送データの往復時間）は、無線区間のリトライとメディアアクセス衝突が起きた場合に、無線区間で伝送遅延が生じて、増加することがあり得る。
【０１６５】
ＲＴＴが増加する第１の状況は、一時的な無線ノイズまたは一時的な電波干渉に起因する可能性が最も高い。データリンク層の再送制御には、再送回数の制限すなわちリトライ限界値がある。そのため、この状況に起因する伝送遅延には、通常、上限がある。また、データリンク層の伝送処理では、伝送レートが無線ノイズのレベルに応じて適応されている。したがって、つまり、受信側トランスポートレート制御部２３５は、リトライ限界値によって制限された上限内でＲＴＴが変化するならば、アクセスポイント１０５のバッファに余裕があると推定することができる。したがって、この場合、受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率が低い場合と同様に、リカバリスケジュールの補償を行わない。
【０１６６】
一方、ＲＴＴが増加する第２の状況としては、無線ノイズまたは電波干渉が強くなった場合がある。この場合、アクセスポイント１０５は、無線ノイズまたは電波干渉が強くなるほど無線メディアがビジー状態であると検出する。さらに、この場合、アクセスポイント１０５は、バックオフを行う必要があり、データパケットをバッファに格納する。この場合には、データリンク層の伝送レートを適応させる処理は機能しなくなる。そして、この状況が長く続くまたは周期的に起きる場合は、アクセスポイント１０５のバッファ使用率は増加し続け、ＲＴＴの値も増加する。遂には、アクセスポイント１０５のバッファが満杯になり、パケット損失が発生する。
【０１６７】
このＲＴＴの増加の監視を行うため、受信側トランスポートレート制御部２３５は、データ伝送により繰り返し得られるＲＴＴ（Round-Trip Time）の情報から、ＲＴＴ増減の比較基準となるベースＲＴＴを取得して保持する。ベースＲＴＴは、例えば、データ伝送のセッション継続時間中に検知した最小のＲＴＴとしてもよい。或いは、ベースＲＴＴは、アクセスポイント１０５のバッファ負荷が閾値未満と観測された時のＲＴＴとしてもよい。
【０１６８】
したがって、受信側トランスポートレート制御部２３５は、ＲＴＴがリトライ限界値によって制限された上限を超えて増加していれば、ネットワークが輻輳から回復した際に、アクセスポイント１０５のバッファ使用率が高いと推定できる。この場合、受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率が高い場合と同様に、リカバリスケジュールの補償を行う。
【０１６９】
このようにＲＴＴの履歴情報を用いることで、受信側トランスポートレート制御部２３５は、バッファ使用率に応じてリカバリスケジュールを補償する。つまり、受信側トランスポートレート制御部２３５は、アクセスポイント１０５のバッファ使用率の情報を直接得ることができない場合でも、リカバリスケジュールを補償することができる。
【０１７０】
［損失したデータパケットの速やかな再送処理（Ｓ８０９）］
ここでは、ステップＳ８０９の処理のうち、送信側トランスポートレート制御部２３１が損失したデータパケットを速やかに再送する処理について詳細に説明する。
【０１７１】
前述した通り、受信側データリンクレート制御部２３３は、無線区間のパケットロス情報を受信側トランスポートレート制御部２３５へ提供する。このパケットロス情報は、受信側データリンクレート制御部２３３が、データリンク層のシーケンス番号と受信した管理フレームの数を追跡（トレース）することで作成される。そして、無線区間のパケットロス情報が作成されるときは、現在受信に成功したパケットの前に何個かのパケットの損失があることを意味する。したがって、受信側トランスポートレート制御部２３５は、クロスレイヤ情報に含まれる受信したパケットのシーケンス番号をチェックすることで、どのパケットが再送されるべきかを瞬時に決定する。
【０１７２】
例えば、受信側トランスポート層処理部２１３がＴＣＰのようなプロトコルを使用しているならば、順序を外れて受信されたパケットは、最初にバッファに保持される。したがって、受信側トランスポート層処理部２１３は、再送のために準備されるべき、今のパケットに先行した直前のパケットを識別できる。
【０１７３】
再送すべきパケットを識別したら、受信側トランスポート層処理部２１３は、送信側端末１０１へのフィードバックパケット１２３の中に、ＳＡＣＫ（Selective Acknowledgement：選択確認応答）オプションまたは重複したＡＣＫを含める。これにより、受信側トランスポート層処理部２１３は、再送すべきパケットを送信側トランスポート層処理部２０１へすばやく通知することができる。或いは、代替的に、トランスポート層のフィードバックパケット１２３が、損失した疑いがあるパケットを示す追加のオプション・フィールドを含む構成としてもよい。この構成により、受信側トランスポート層処理部２１３は、損失した疑いがあるパケットを送信側トランスポート層処理部２０１へすばやく通知することができる。そして、これらの通知により、送信側トランスポート層処理部２０１は、損失したパケットの再送を直ぐにスケジュールすることできる。
【０１７４】
一般に、ＴＣＰなどの通常のトランスポート・プロトコルにおいて、受信側端末１０３は、受信したパケットが順序通りでないときに、前のＡＣＫメッセージとまったく同じシーケンス番号を付けてＡＣＫメッセージを送信する。送信側端末１０１は、連続して重複したＡＣＫメッセージが所定数（例えば３個）受信したら、ＡＣＫが戻ってこなかったパケットの再送制御を起動させる。つまり、受信側トランスポート層処理部２１３と送信側トランスポート層処理部２０１とは、所定数の重複したＡＣＫの受信を、再送制御を起動させる指示として使用する。
【０１７５】
それに対して、本実施の形態では、受信側トランスポート層処理部２１３が、クロスリンク情報を持っていることで、再送の必要なパケットの情報を送信側トランスポート層処理部２０１へ直接的に通知できる。したがって、本実施の形態のトランスポート層の再送制御では、一般的な３個の重複したＡＣＫによる非到達パケットの検知方式を利用した制御に比べて、ずっと早く再送をスケジュールすることができる。それゆえ、本実施の形態では、トランスポート層の再送制御の性能の向上を促進できる。
【０１７６】
以上、本発明の実施の形態１について説明した。
【０１７７】
なお、実施の形態１では、受信側端末１０３が、レート制御のための伝送方針の決定、エンド・ツー・エンドのスループットの算出、および、リカバリスケジュールの補償を行う構成とした。しかしながら、本実施形態では、送信側端末１０１がこれらを行う構成とすることも可能であり、このことは当業者にとって明らかである。受信側データリンクレート制御部２３３と受信側トランスポートレート制御部２３５は、必要な情報を集め、集めた情報をトランスポート層のフィードバックパケット１２３として、送信側トランスポートレート制御部２３１へ渡せばよい。また、送信側トランスポートレート制御部２３１は、レート制御の内容を決定するために、上記受信した情報と、例えばＲＴＴ値およびバッファサイズなど、自ノードにある情報に基づいて、同様の演算処理を行えばよい。
【０１７８】
また、実施の形態１において、受信側データリンクレート制御部２３３は、無線リンク状況に関する所定の推定を行って、達成可能なエンド・ツー・エンドのスループットを算出する構成とした。しかし、受信側データリンクレート制御部２３３は、所定のパターン認識に基づいて無線環境の動向から達成可能なエンド・ツー・エンドのスループットを得る構成としてもよい。
【０１７９】
例えば、受信側データリンクレート制御部２３３は、無線リンクが短い一時的な干渉を受けた状況と、無線リンクが実効ビットレートの下降をより長い時間受ける状況とを、パターン認識に基づいて予測することができる。この場合、受信側データリンクレート制御部２３３は、ウインドウ期間におけるデータリンク層の再送試行の記録と、ノイズレベルに関する統計値とを対象に、パターン認識を行って上記の予測を行うことができる。このパターン認識に必要なパターンデータは、広範な測定とシミュレーションに基づいて予め作成可能であり、受信側データリンクレート制御部２３３内に記憶可能である。
【０１８０】
また、実施の形態１では、アクセスポイント１０５に一つの受信側端末１０３が無線接続されている構成の動作に主眼を置いて説明した。しかし、本発明は、アクセスポイント１０５に一つの受信側端末１０３と、他の１つ又は複数の無線局が接続されている構成に対しても有効に適用できる。例えば、アクセスポイント１０５は、ビーコン中にブロードキャストされるＢＳＳ（Basic Service Set）負荷エレメントの情報に、局数カウントの値とチャネル利用率に関する情報とを含めている。局数カウントは、アクセスポイント１０５に結び付いた無線局（ＳＴＡ：ステーション）の数を示し、チャネル利用率は、無線メディアがビジーであった時間を示す。これらの情報により、受信側データリンクレート制御部２３３は、適切な実効ビットレートが使用されるべき対象の無線局を推定できる。
【０１８１】
また、実施の形態１では、受信側トランスポートレート制御部２３５が、ネットワーク混雑位置の識別（Ｓ８０４）と、現在の状況に対する伝送方針の決定（Ｓ８０５）と、達成可能なスループットの見積り（Ｓ８０６）とを行う構成とした。しかし、受信側端末１０３は、別個複数のモジュールを備え、これら複数のモジュールがステップＳ８０４〜Ｓ８０６の処理をそれぞれ行う構成としてもよい。これらのモジュールは適宜、機能毎に分割または統合されていても構わない。例えば、受信側端末１０３は、ネットワーク混雑位置の識別機能と、現在の状況に対する伝送方針の決定機能を統合した伝送スケジューリングモジュールを備えてもよい。また、受信側端末１０３は、データリンク層の実効ビットレートの見積もり機能と、トランスポート層の達成可能エンド・ツー・エンドのスループット見積もり機能とを、統合したレート制御モジュールを備えてもよい。
【０１８２】
（実施の形態２）
図８は、本発明の実施の形態２のネットワーク伝送装置が加わるネットワーク構成の一例を示す図である。
【０１８３】
実施の形態２のネットワーク構成には、送信側端末６０１と、エッジネットワーク６１１，６１３と、アクセスポイント６０３と、コアネットワーク６０５と、受信側端末６０７とが含まれる。
【０１８４】
送信側端末６０１は、ネットワーク経由でＡＶストリーミングデータを送出する情報端末である。エッジネットワーク６１３は、送信側端末６０１が接続される送信側のネットワーク（無線区間）である。コアネットワーク６０５は、インターネットなどを含み、送信側端末６０１と受信側端末６０７との間に位置する主に有線のネットワークである。エッジネットワーク６１１は、受信側端末６０７とコアネットワーク６０５とを接続する受信側のネットワーク（有線区間）である。アクセスポイント６０３は、送信側エッジネットワーク（無線区間）６１３とコアネットワーク６０５の間に位置して、無線区間と有線区間のネットワークブリッジとして機能する。受信側端末６０７は、ネットワーク経由でＡＶストリーミングデータを受信する情報端末である。
【０１８５】
実施の形態２のネットワーク上で伝送されるデータには、データパケット６２１と、フィードバックパケット６２３とが含まれる。
【０１８６】
データパケット６２１は、例えばＡＶストリーミングデータなどであり、送信側端末６０１から受信側端末６０７へ向けて送信される。フィードバックパケット６２３は、データパケット６２１の伝送に対する応答および伝送制御用のデータを含み、受信側端末６０７から送信側端末６０１へ送信される。これらの構成のうち、送信側端末６０１が、本発明に係るネットワーク端末装置の一実施の形態である。
【０１８７】
図９は、本実施の形態２の送信側端末６０１の要部構成図である。
【０１８８】
送信側端末１０３は、送信側データリンク層処理部７０３と、送信側トランスポート層処理部７０１と、輻輳箇所判別部７３１ａと、伝送レート制御部７３１ｂと、実効レート算出部７３３ａと、を備える。
【０１８９】
送信側データリンク層処理部７０３は、送信側端末６０１におけるネットワーク処理のうち、データリンク層の処理を行う。送信側トランスポート層処理部７０１は、送信側端末６０１のネットワーク処理のうち、トランスポート層の送信処理を行う。
【０１９０】
実効レート算出部７３３ａは、送信側データリンク層処理部７０３の実効ビットレートを算出する。ここで、算出される実効ビットレートは、送信側データリンク層処理部７０３の再送制御に伴う伝送効率の低下を考慮した実効的な伝送レートである。算出された実効ビットレートの情報は、伝送レート制御部７３１ｂへ送られる。
【０１９１】
輻輳箇所判別部７３１ａは、送信側データリンク層処理部７０３の伝送状況を表わすデータリンク層情報と、送信側トランスポート層処理部２１３の伝送状況を表わすトランスポート層情報とに基づいて、ネットワークの輻輳箇所を判別する。データリンク層情報は、本発明に係る第２層情報の一実施形態である。トランスポート層情報は、本発明に係る第４層情報の一実施形態である。判別結果の情報は、伝送レート制御部７３１ｂへ送られる。
【０１９２】
伝送レート制御部７３１ｂは、輻輳箇所の判別結果の情報と、実効ビットレートの情報とを受けて、これらの情報に基づき、トランスポート層の伝送レートを決定する制御を行う。
【０１９３】
なお、後述する図１０の具体的な構成例において、実効レート算出部７３３ａは、送信側データリンクレート制御部７３３に含まれている。しかし、実効レート算出部７３３ａは、送信側データリンクレート制御部７３３と別に設けられても良い。また、後述する図１０の具体的な構成例において、輻輳箇所判別部７３１ａと伝送レート制御部７３１ｂとは、図１０の送信側トランスポートレート制御部７３１に含まれている。しかし、輻輳箇所判別部７３１ａと伝送レート制御部７３１ｂとは、送信側トランスポートレート制御部７３１と別に設けられても良い。
【０１９４】
続く説明では、ネットワークの各ノードが、非特許文献７に示されるＴＣＰ（Transmission Control Protocol）を使用して、データ伝送を行う例を示している。しかし、データ伝送のためのプロトコルは、送信データのレート制御と受信側から送信側へのフィードバックが可能であれば、その他のプロトコルを適用可能である。このことは当業者にとって明らかであり、本発明の概念に影響するものでない。その他のプロトコルとしては、例えば、非特許文献８に示されるＤＣＣＰ（Datagram Congestion Control Protocol）が適用できる。また、その他のプロトコルとしては、非特許文献９に示されるＳＣＴＰ（Stream Control Transmission Protocol）が適用できる。
【０１９５】
図１０は、図８の各装置の論理的構成を示すブロック図である。
【０１９６】
送信側端末６０１は、図１０に示すように、送信側アプリケーション７４０と、送信側トランスポート層処理部７０１と、送信側トランスポートレート制御部７３１と、送信側データリンク層処理部７０３と、送信側データリンクレート制御部７３３と、を備える。
【０１９７】
送信側アプリケーション７４０は、データの送信要求と指示とを行う。送信側トランスポート層処理部７０１は、図９にも示したように、送信側端末６０１におけるネットワーク処理のうち、トランスポート層の伝送処理を行う。送信側トランスポートレート制御部７３１は、送信側端末６０１における送信側トランスポート層処理部７０１において、送信側のトランスポート層のレート制御と必要な情報取得処理とを行う。送信側データリンク層処理部７０３は、図９にも示したように、送信側端末６０１におけるネットワーク処理のうち、データリンク層の伝送処理を行う。送信側データリンクレート制御部７３３は、送信側端末６０１における送信側トランスポート層処理部７０１において、送信側のデータリンク層のレート制御と必要な情報取得処理とを行う。
【０１９８】
受信側端末６０７は、図１０に示すように、受信側アプリケーション７４１と、受信側トランスポート層処理部７１３と、受信側トランスポートレート制御部７３５と、受信側データリンク層処理部７１１と、を備える。
【０１９９】
受信側アプリケーション７４１は、データの受信要求と指示とを行う。受信側トランスポート層処理部７１３は、受信側端末６０７におけるネットワーク処理のうち、トランスポート層の受信処理を行う。受信側トランスポートレート制御部７３５は、受信側端末６０７における受信側トランスポート層処理部７１３において、受信側のトランスポート層のレート制御と必要な情報取得処理とを行う。受信側データリンク層処理部７１１は、受信側端末６０７におけるネットワーク処理のうち、データリンク層の処理を行う。
【０２００】
アクセスポイント６０３は、図１０に示すように、ブリッジ機構７０５と、有線リンク層処理部７０９と、無線リンク層処理部７０７と、を備える。
【０２０１】
ブリッジ機構７０５は、アクセスポイント６０３において、無線ネットワークと有線ネットワークの間のネットワークブリッジ機能の処理を行う。有線リンク層処理部７０９は、ブリッジ機構７０５のうち、有線ネットワークのデータリンク層の処理を行う。無線リンク層処理部７０７は、ブリッジ機構７０５のうち、無線ネットワークのデータリンク層の処理を行う。
【０２０２】
次に、上記のネットワーク構成において、データの伝送処理の流れについて説明する。
【０２０３】
送信側端末６０１は、送信側トランスポート層処理部７０１から送信側データリンク層処理部７０３を介して、アクセスポイント６０３へ向けてデータパケット６２１を送信する。アクセスポイント６０３の無線リンク層処理部７０７は、データパケット６２１を受信し、ブリッジ機構７０５を通じて、データパケット６２１を有線リンク層処理部７０９へ中継する。アクセスポイント６０３は、有線リンク層処理部７０９、コアネットワーク６０５、および、受信側エッジネットワーク（有線区間）６１１を介して、データパケット６２１を受信側端末６０７へ送信する。受信側端末６０７は、受信側データリンク層処理部７１１を介して、データパケット６２１を受信する。受信側データリンク層処理部７１１は、受信側端末６０７内の受信側トランスポート層処理部７１３へデータパケット６２１を転送する。
【０２０４】
図１１は、実施の形態２の受信側端末６０７と送信側端末６０１とにより行われるレート制御の手順を示すフローチャートである。このレート制御は、通常のデータ伝送の進行中に行われる。
【０２０５】
ステップＳ９０１において、送信側データリンクレート制御部７３３は、受信側端末６０７と送信側端末６０１との伝送経路に含まれる無線区間の伝送状況を把握する。次に、送信側データリンクレート制御部７３３は、実効リンクレートの推定を行うために、データリンク層におけるリトライ率を算出する。
【０２０６】
送信側データリンク層処理部７０３よりアクセスポイント６０３に送出されたパケットは、エラーを生じずに伝達される場合も、エラーによって送信のリトライが行われる場合もある。このリトライは、無線リソースを必要とするので、無線区間で実際に達成可能なスループットに影響を及ぼす。無線区間におけるデータ再送は、データリンク層で実施され、この再送が失敗を繰り返してトランスポート層で再送制御を行う必要が生じない限り、トランスポート層は関知しない。したがって、送信側トランスポート層処理部７０１は、従前の構成のままでは、無線区間のデータ再送を加味した処理はできない。
【０２０７】
送信側データリンクレート制御部７３３は、無線区間の再送に伴うスループットの損失分を特定するための統計データを作成し、この統計データからリトライ率を算出する。統計データとは、所定期間内の各送信タイミングにおけるデータ再送の有無の履歴を表わすデータである。リトライ率の算出は、実施の形態１におけるステップＳ８０１の説明で述べた通り、ウインドウサイズに連動してサイズが変更される可変ウインドウバッファ（図７参照）を用いて行われる。
【０２０８】
次に、ステップＳ９０２において、送信側データリンクレート制御部７３３は、送信側データリンクレート制御部７３３が算出したデータリンク層のリトライ率を用いて、データリンク層の実効ビットレートを見積もる。この計算は、実施の形態１におけるステップＳ８０２の説明で述べた通り、使用される無線アクセスのオペレーションモード毎に異なる計算式、例えば、実施の形態１で示した実効ビットレートの演算式（１）、（４）を用いて実行される。
【０２０９】
次に、ステップＳ９０３において、送信側データリンクレート制御部７３３は、実効ビットレートの推定後、トランスポート層へのデータフィードバックに所定のクロスレイヤ情報をタグ付けする。次に、送信側データリンクレート制御部７３３は、それをタグ付けデータとして、送信側トランスポートレート制御部７３１に送る。受け渡すクロスレイヤ情報、および、ネットワーク階層をまたいだ情報の受け渡しを行うための実装例については、実施の形態１におけるステップＳ８０３の説明で述べた通りである。
【０２１０】
次に、ステップＳ９０４において、送信側トランスポートレート制御部７３１は、クロスレイヤ情報を用いて、現在のネットワークの輻輳位置の識別を行う。この識別処理は、実施の形態１のステップＳ８０４の説明で述べた通りである。
【０２１１】
次に、ステップＳ９０５において、送信側トランスポートレート制御部７３１は、識別したネットワーク輻輳位置に基づいて現在の状況に対する伝送方針を決定する。この処理は、実施の形態１のステップＳ８０５の説明で述べた通りである。
【０２１２】
次に、ステップ９０６において、送信側トランスポートレート制御部７３１は、送信側データリンクレート制御部７３３で見積もった実効ビットレートを用いて、トランスポート層での達成可能エンド・ツー・エンドのスループットを見積もる。この処理は、実施の形態１のステップＳ８０６の説明で述べた通りである。
【０２１３】
次に、ステップＳ９０７において、送信側トランスポートレート制御部７３１は、実際のデータ送信のスケジュールを算出する際に、履歴情報を用いてデータ送信スケジュールの補償を行う。この補償処理は、実施の形態１のステップＳ８０７の説明で述べた通りである。
【０２１４】
次に、ステップＳ９０８において、送信側トランスポートレート制御部７３１は、実際のデータ送信のリカバリスケジュールを実行する。
【０２１５】
上記一連のレート制御によって、受信側端末６０７と送信側端末６０１とは、ネットワークで伝送レートが低下したときでも、適切に輻輳またはパケットロスの位置を判定することができる。さらに、受信側端末６０７と送信側端末６０１とは、更なる輻輳またはパケットロスを防止しつつ利用可能なネットワークリソースを最大限に活用するような、伝送レートの回復に向けたレート制御を実現できる。
【０２１６】
以上、本発明の実施の形態２について説明した。
【０２１７】
なお、実施の形態２では、送信側トランスポートレート制御部７３１が、ネットワーク混雑位置の識別（Ｓ９０４）と、現在の状況に対する伝送方針の決定（Ｓ９０５）と、達成可能なスループットの見積り（Ｓ９０６）とを行う構成とした。しかし、送信側端末６０１は、別個複数のモジュールを備え、これら複数のモジュールがステップＳ９０４〜Ｓ９０６の処理をそれぞれ行う構成としてもよい。これらのモジュールは、適宜、機能毎に分割または統合されていても構わない。例えば、送信側端末６０１は、ネットワーク混雑位置の識別機能と、現在の状況に対する伝送方針の決定機能を統合した伝送スケジューリングモジュールを備えてもよい。また、送信側端末６０１は、データリンク層の実効ビットレートの見積もり機能と、トランスポート層の達成可能エンド・ツー・エンドのスループット見積もり機能とを、統合したレート制御モジュールを備えてもよい。
【０２１８】
上記の記述においては、具体的な実施の形態を詳細に説明し、添付の図面に図示したが、当業者は、これらの実施の形態の詳細部分の様々な修正または代替が本開示の全般的な教示内容を踏まえて可能であることを理解されるであろう。したがって、実施の形態に開示された構成は、本発明の範囲についての一例に過ぎず、本発明は実施の形態の構成に限定されるものではない。
【０２１９】
上記の実施形態の説明で使用された各機能部は、一般に集積回路として表現されるＬＳＩとして実現可能である。これらは、個々に一つのチップとして製造されても、一部または全部を含む一つのチップとして設計されてもよい。ここでＬＳＩと称するものは、集積の程度に応じて、ＩＣ、システムＩＣ，超ＬＳＩ、または極超ＬＳＩと呼ばれることもある。また、集積回路の技術は、ＬＳＩにだけ限定されず、集積回路は専用回路または汎用プロセッサとして実現可能である。本実施形態は、ＬＳＩの製造後にプログラム可能であるＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）、ＬＳＩ内の回路セルの接続、または、設定が再構成され得る再構成可能プロセッサも使用可能ある。さらに、本実施形態は、半導体技術またはそれから派生したその他の技術の進歩により、ＬＳＩに取って代わる回路集積化の技術が出現し得るときには、そのような技術を使用することによって機能部を集積してもよい。例えば、バイオテクノロジーの適応は、このような可能性の一つである。
【産業上の利用可能性】
【０２２０】
本発明は、ネットワークを介してデータ送信を行うサーバ装置、ネットワークを介してデータ受信を行う端末装置等に適用できる。
【符号の説明】
【０２２１】
１０１ 送信側端末
１０２ コアネットワーク
１０３ 受信側端末
１０５ アクセスポイント
１１１，１１３ エッジネットワーク
１２１ データパケット
１２３ フィードバックパケット
２０１ 送信側トランスポート層処理部
２０３ 送信側データリンク層処理部
２０５ 有線リンク層処理部
２０９ 無線リンク層処理部
２１１ 受信側データリンク層処理部
２１３ 受信側トランスポート層処理部
２３１ 送信側トランスポートレート制御部
２３３ 受信側データリンクレート制御部
２３５ 受信側トランスポートレート制御部
５００ 可変ウインドウバッファ
５０１，５０３ リトライ履歴情報
５０５ リトライ情報
６０１ 送信側端末
６０３ アクセスポイント
６０５ コアネットワーク
６０７ 受信側端末
６１１，６１３ エッジネットワーク
６２１ データパケット
６２３ フィードバックパケット
７０１ 送信側トランスポート層処理部
７０３ 送信側データリンク層処理部
７０７ 無線リンク層処理部
７０９ 有線リンク層処理部
７１１ 受信側データリンク層処理部
７１３ 受信側トランスポート層処理部
７３１ 送信側トランスポートレート制御部
７３３ 送信側データリンクレート制御部
７３５ 受信側トランスポートレート制御部
【特許請求の範囲】
【請求項１】
ネットワークを介してデータ伝送を行うネットワーク端末装置であって、
無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部と、
前記データリンク層処理部を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部と、
前記データリンク層処理部のデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理部のデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部と、
判別された前記輻輳箇所に基づいて前記トランスポート層処理部の伝送レートを調整する伝送レート制御部と、
を具備するネットワーク端末装置。
【請求項２】
少なくとも前記データリンク層処理部の再送制御に伴う伝送効率の低下を含めた前記データリンク層処理部の伝送レートを表わす実効レートを算出する実効レート算出部
をさらに具備し、
前記伝送レート制御部は、
判別された前記輻輳箇所と算出された前記実効レートとに基づいて、前記トランスポート層処理部の伝送レートを調整する
請求項１記載のネットワーク端末装置。
【請求項３】
前記実効レート算出部は、
前記トランスポート層処理部でひとまとめに処理される伝送データのサイズであるウインドウサイズに合わせてデータ再送の発生割合の算出期間長を変化させ、算出された前記データ再送の発生割合に基づいて前記実効レートを算出する
請求項２記載のネットワーク端末装置。
【請求項４】
前記伝送レート制御部は、
通信相手の端末ノードへ前記伝送レートを決定させるフィードバック情報を送ることで前記トランスポート層処理部の伝送レートを調整する
請求項１記載のネットワーク端末装置。
【請求項５】
前記フィードバック情報には、
前記データリンク層処理部における伝送データの損失情報が含まれる
請求項４記載のネットワーク端末装置。
【請求項６】
前記第２層情報は、
前記データリンク層処理部におけるデータ再送の発生割合情報、前記データリンク層処理部における伝送データの損失情報、または、無線ノイズの強度情報を含む
請求項１記載のネットワーク端末装置。
【請求項７】
前記データリンク層処理部は、
隣接する通信ノードの通信バッファの使用状況情報を取得する情報取得手段を有し、
前記第２層情報は、
前記通信バッファの使用状況情報を含む
請求項１記載のネットワーク端末装置。
【請求項８】
前記第４層情報は、
伝送データの伝送遅延時間の変化情報を含む
請求項１記載のネットワーク端末装置。
【請求項９】
前記輻輳箇所判別部は、
前記第４層情報に含まれる伝送データの伝送遅延時間の変化情報と、前記第２層情報に含まれる隣接する通信ノードの通信バッファの使用状況情報とに基づいて、前記輻輳箇所を判別する
請求項１記載のネットワーク端末装置。
【請求項１０】
前記輻輳箇所判別部は、
前記伝送データの輻輳箇所が、前記隣接する通信ノードとの間にあるか、前記隣接する通信ノードと通信相手の端末ノードとの間にあるかを判別する
請求項１記載のネットワーク端末装置。
【請求項１１】
前記伝送レート制御部は、
前記トランスポート層処理部の伝送レートを回復させる際、前記第２層情報および／または前記第４層情報の履歴に基づいて、前記伝送レートの回復速度を補償する
請求項１記載のネットワーク端末装置。
【請求項１２】
前記第２層情報と前記実効レートとを対応づけるマッピング情報を管理するマッピング情報管理部を備え、
前記実効レート算出部は、
前記マッピング情報に基づいて前記実効レートを算出可能である
請求項２記載のネットワーク端末装置。
【請求項１３】
前記データリンク層処理部は、複数の動作モードを備え、
前記実効レート算出部は、
前記データリンク層処理部の動作モードに応じて前記実効レートを算出するためのパラメータおよび算出式を切り替える
請求項２記載のネットワーク端末装置。
【請求項１４】
ネットワークを介してデータ伝送を行うデータ伝送方法であって、
無線を介して接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理ステップと、
前記データリンク層処理ステップを介して端末ノード間のデータ伝送処理を行うトランスポート層処理ステップと、
前記データリンク層処理ステップでのデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理ステップでのデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別ステップと、
判別された前記輻輳箇所に基づいて前記トランスポート層処理ステップでの伝送レートを調整する伝送レート制御ステップと、
を含むデータ伝送方法。
【請求項１５】
少なくとも前記データリンク層処理ステップでの再送制御に伴う伝送効率の低下を含めた前記データリンク層処理ステップでの伝送レートを表わす実効レートを算出する実効レート算出ステップ、
をさらに含み、
前記伝送レート制御ステップは、
判別された前記輻輳箇所と算出された前記実効レートとに基づいて、前記トランスポート層処理ステップでの伝送レートを調整する
請求項１４記載のデータ伝送方法。
【請求項１】
ネットワークを介してデータ伝送を行うネットワーク端末装置であって、
無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部と、
前記データリンク層処理部を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部と、
前記データリンク層処理部のデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理部のデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部と、
判別された前記輻輳箇所に基づいて前記トランスポート層処理部の伝送レートを調整する伝送レート制御部と、
を具備するネットワーク端末装置。
【請求項２】
少なくとも前記データリンク層処理部の再送制御に伴う伝送効率の低下を含めた前記データリンク層処理部の伝送レートを表わす実効レートを算出する実効レート算出部
をさらに具備し、
前記伝送レート制御部は、
判別された前記輻輳箇所と算出された前記実効レートとに基づいて、前記トランスポート層処理部の伝送レートを調整する
請求項１記載のネットワーク端末装置。
【請求項３】
前記実効レート算出部は、
前記トランスポート層処理部でひとまとめに処理される伝送データのサイズであるウインドウサイズに合わせてデータ再送の発生割合の算出期間長を変化させ、算出された前記データ再送の発生割合に基づいて前記実効レートを算出する
請求項２記載のネットワーク端末装置。
【請求項４】
前記伝送レート制御部は、
通信相手の端末ノードへ前記伝送レートを決定させるフィードバック情報を送ることで前記トランスポート層処理部の伝送レートを調整する
請求項１記載のネットワーク端末装置。
【請求項５】
前記フィードバック情報には、
前記データリンク層処理部における伝送データの損失情報が含まれる
請求項４記載のネットワーク端末装置。
【請求項６】
前記第２層情報は、
前記データリンク層処理部におけるデータ再送の発生割合情報、前記データリンク層処理部における伝送データの損失情報、または、無線ノイズの強度情報を含む
請求項１記載のネットワーク端末装置。
【請求項７】
前記データリンク層処理部は、
隣接する通信ノードの通信バッファの使用状況情報を取得する情報取得手段を有し、
前記第２層情報は、
前記通信バッファの使用状況情報を含む
請求項１記載のネットワーク端末装置。
【請求項８】
前記第４層情報は、
伝送データの伝送遅延時間の変化情報を含む
請求項１記載のネットワーク端末装置。
【請求項９】
前記輻輳箇所判別部は、
前記第４層情報に含まれる伝送データの伝送遅延時間の変化情報と、前記第２層情報に含まれる隣接する通信ノードの通信バッファの使用状況情報とに基づいて、前記輻輳箇所を判別する
請求項１記載のネットワーク端末装置。
【請求項１０】
前記輻輳箇所判別部は、
前記伝送データの輻輳箇所が、前記隣接する通信ノードとの間にあるか、前記隣接する通信ノードと通信相手の端末ノードとの間にあるかを判別する
請求項１記載のネットワーク端末装置。
【請求項１１】
前記伝送レート制御部は、
前記トランスポート層処理部の伝送レートを回復させる際、前記第２層情報および／または前記第４層情報の履歴に基づいて、前記伝送レートの回復速度を補償する
請求項１記載のネットワーク端末装置。
【請求項１２】
前記第２層情報と前記実効レートとを対応づけるマッピング情報を管理するマッピング情報管理部を備え、
前記実効レート算出部は、
前記マッピング情報に基づいて前記実効レートを算出可能である
請求項２記載のネットワーク端末装置。
【請求項１３】
前記データリンク層処理部は、複数の動作モードを備え、
前記実効レート算出部は、
前記データリンク層処理部の動作モードに応じて前記実効レートを算出するためのパラメータおよび算出式を切り替える
請求項２記載のネットワーク端末装置。
【請求項１４】
ネットワークを介してデータ伝送を行うデータ伝送方法であって、
無線を介して接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理ステップと、
前記データリンク層処理ステップを介して端末ノード間のデータ伝送処理を行うトランスポート層処理ステップと、
前記データリンク層処理ステップでのデータ伝送の状況を表わす第２層情報と、前記トランスポート層処理ステップでのデータ伝送の状況を表わす第４層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別ステップと、
判別された前記輻輳箇所に基づいて前記トランスポート層処理ステップでの伝送レートを調整する伝送レート制御ステップと、
を含むデータ伝送方法。
【請求項１５】
少なくとも前記データリンク層処理ステップでの再送制御に伴う伝送効率の低下を含めた前記データリンク層処理ステップでの伝送レートを表わす実効レートを算出する実効レート算出ステップ、
をさらに含み、
前記伝送レート制御ステップは、
判別された前記輻輳箇所と算出された前記実効レートとに基づいて、前記トランスポート層処理ステップでの伝送レートを調整する
請求項１４記載のデータ伝送方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１３−８５１３５（Ｐ２０１３−８５１３５Ａ）
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１１−２２３９６６（Ｐ２０１１−２２３９６６）
【出願日】平成２３年１０月１１日（２０１１．１０．１１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２３年１０月１１日（２０１１．１０．１１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]