JP7405551B2 - 通信システム及び通信制御方法 - Google Patents

Description

本発明は、複数の無線サブシステムを利用する通信システム及び通信方法に関し、特に、送受信されるアプリケーションデータのデータフロー制御に関する。

無線通信システムの普及に伴い、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）というキーワードに代表されるように、様々な特徴を有する無線通信システムを適切に利用して、アプリケーションデータを無線通信で伝送するサービスが拡大している。

無線通信システムの分類方法はいくつか考えられる。その内の一つが、端末の認証を通せば誰でも接続可能な公衆網と、特定の端末のみ接続を許可するプライベート網である。

公衆網の代表として、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）や５Ｇなどのセルラ移動体通信システムがあり、プライベート網の代表としてＷｉＦｉがある。近年は公衆網のシステムをプライベート網に活用する動きも活発になりつつある。また、センサ情報の収集を主目的とした省電力かつ遠距離通信が可能なＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ）、機器間の近距離通信に特化したＢｌｕｅｔｏｏｔｈ（登録商標、以下同じ）、自動車交通管制に利用するＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔａｔｉｏｎ Ｓｙｓｔｅｍ）など、用途によっても分類できる。

セルラ移動体通信システム向けの端末であるスマートフォンの普及により動画視聴ユーザが増加し、結果としてネットワーク負荷が増大する。このため、セルラ移動体通信システムでは、課金方法や通信速度制限などを工夫して、主に動画トラフィックのＷｉＦｉへ誘導する、オフロードを実施している。

スマートフォンは、セルラ移動体通信システムにおける通信機能だけでなく、オフロードのためのＷｉＦｉや、機器間接続のためのＢｌｕｅｔｏｏｔｈなど、複数の無線システムで通信可能である。例えば、スマートフォンを持つユーザが屋外から屋内へ移動したときに、ユーザが伝送する情報をセルラ移動体通信システムからＷｉＦｉに切り替えて、データ伝送を継続できる。

このように、ユーザが送信しようとするデータを、複数の無線通信システムのいずれかを選択して、そのシステムを用いて伝送する技術は既に確立されており、例えば、特許文献１や特許文献２で開示されている。

特開２００８－０４２９３８号公報 国際公開１２／１０１６８２号

アプリケーションとして安全設計が必要となる保安系ユースケースの場合、データパケット誤り率や遅延ジッタなど、アプリケーション観点で、無線レイヤにおいて達成すべき性能要件がある。一方、前述した特許文献には、状況に応じて無線通信システムを切り替える技術が開示されているが、無線通信システム間で無線レイヤにて提供できる性能の実力値が異なるため、アプリケーション観点の性能要求と無線レイヤの実力性能とが相違する場合、特に無線レイヤの実力性能がアプリケーション観点の性能要求と比較して低い場合に、アプリケーションの安全設計基準を満たせなくなる問題がある。

そこで、本発明は、安全設計基準を満たし続けるために、無線通信システムを切り替える通信システムの提供を目的とする。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の通信サブシステムを経由して少なくとも一つのアプリケーションが通信しながら動作するプラットフォームを提供する通信システムであって、前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されたポリシー記憶部と、前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと通信サブシステムの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御する制御装置を備え、前記通信品質要求はジッタであって、前記制御装置は、データを送受信するウィンドウサイズによってジッタを制御することを特徴とする。

本発明の一態様によれば、無線サブシステムを切り替えてもアプリケーションの通信品質要求を満たすことができる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

本発明の実施例の通信システムの構成例を示す図である。 本実施例のデータフロー制御ポリシー管理テーブルの例を示す図である。 本実施例のＩＰパケットベースのデータフォーマットの例を示す図である。 本実施例のデータフロー識別子辞書の例を示す。 本実施例の送信データフロー制御部の構成例を示す図である。 本実施例の受信データフロー制御部の構成例を示す図である。 本実施例の無線サブシステム側送信処理部の構成例を示す図である。 本実施例の無線サブシステム側受信処理部の構成例を示す図である。 本実施例の送信データフロー処理部で実行される処理を説明するためのタイミング図である。 本実施例の受信データフロー処理部で実行される処理を説明するためのタイミング図である。 本実施例の無線サブシステム監視部の構成例を示す図である。

図１は、本発明の実施例の通信システムの構成例を示す図である。

本発明は様々なアプリケーションに活用可能であるが、具体例として無線通信を介して現場の映像及び音声をリアルタイム再生しながら、遠隔で自動車を操作するアプリケーションのためのプラットフォームを想定して、実施例を説明する。

アプリケーション側には、移動体操作装置１１及び現場再生装置１２が設けられている。移動体操作装置１１は、アクセルによる加速、ブレーキによる減速、及びハンドルによる操舵の操作を実施して自動車を制御するための装置である。現場再生装置１２は、映像を表示するためのディスプレイと、音声を再生するスピーカを有する。移動体操作装置１１及び現場再生装置１２は、統合された一体型の装置として、すなわちドライビングシミュレータのような形態の装置でもよい。

操作者による加速、減速、操舵の操作はアナログ信号として生成され、移動体操作装置１１内のアナログデジタル変換器によりデジタル信号に変換され、アプリケーション側に出力される。

映像や音声の信号は、アプリケーション側からデジタル信号として入力され、デジタル信号のまま、又はデジタルアナログ変換器を介してアナログ信号に変換されて、ディスプレイ及びスピーカに入力される。

仮に無線を介さないで通信する場合、移動体操作装置１１は移動体制御装置６１に直接接続され、現場再生装置１２はセンサ装置６２に直接接続される。自動車の例では、加速操作がエンジンの回転数、減速操作がディスクブレーキのブレーキパッドの圧力、操舵操作がタイヤの向きの制御に相当し、移動体制御装置６１はこれらの全ての制御を実施する制御装置である。センサ装置６２は、自動車の遠隔操作の例では、映像を取得するカメラと音声を取得するマイクであり、これらが統合された装置である。

本発明では、移動体操作装置１１と移動体制御装置６１の間、及び、センサ装置６２と現場再生装置１２の間を無線通信で伝送するため、以下では、その仕組みを説明する。

アプリケーションプログラム実行装置２１は、アプリケーション側の移動体操作装置１１及び現場再生装置１２との間ではデジタル信号を、データフロー制御装置３１との間ではＩＰパケットを伝送する。アプリケーションプログラム実行装置２１はデータフロー制御装置３１と一体化して、それぞれ別々のプロセスとして動作させてもよい。

アプリケーションプログラム実行装置２１で実行されるプログラムは、最低限デジタル信号とＩＰパケットとの相互変換処理を行う。その他に、例えば映像の解像度やフレームレート、すなわちアプリケーションの品質を調整する機能を、アプリケーションの必要に応じて実装してもよい。アプリケーションの品質は、データフロー制御装置３１から入力される通信品質の段階変更通知に従って制御される。その他、例えば映像伝送であれば圧縮のためのエンコーダ及びデコーダのような、アプリケーション特有のデータ処理を含んでもよい。

データフロー制御装置３１は、送信データフロー制御部４０１、受信データフロー制御部４０２、無線サブシステム側送信処理部４０７、無線サブシステム側受信処理部４０８、送信データフロー処理部４０４、受信データフロー処理部４０６及び無線サブシステム監視部４０５を有し、アプリケーションプログラム実行装置２１と無線サブシステムネットワーク４１との間で伝送されるＩＰパケットのフローを制御する。各部の動作の詳細は別の図にて後述する。

データフロー制御ポリシー記憶装置３２は、データフロー制御装置３１がデータフロー制御を実施する際に参照される。データフロー制御ポリシー管理テーブル（図２参照）を格納する。詳細はデータフロー制御装置３１とデータフロー制御ポリシー記憶装置３２については、別図面にて後述するが、概要としては、データフロー制御装置３１が、データフロー制御ポリシー記憶装置３２に記憶されているポリシーに基づいて、データ伝送の優先順位の制御、データを一時的にバッファリングして等間隔にパケットを出力する制御、同一パケットをレプリケーション送信して受信側で重複排除する制御、ＩＰパケット毎にデータ出力先を変えるルーティング制御などを実施する。優先順位の制御は優先送信制御部４１３が実施し、等間隔パケット出力制御は送信データフロー処理部４０４及び受信データフロー処理部４０６が実施し、レプリケーション及び重複排除制御は送信データフロー処理部４０４及び受信データフロー処理部４０６が実施し、ルーティング制御は送信データフロー制御部４０１内のデータフロー名寄せ部４０３が、複数設けられる送信データフロー処理部４０４への転送制御として実施する。

無線サブシステムネットワーク４１は、無線端末と通信する無線機、及び端末位置管理や端末位置に基づくデータのルーティング制御を行う制御装置がネットワーク化されて構成されている。ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）のシステムにおいては、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）とｅＮＢ（ｅｎｈａｎｃｅｄ Ｎｏｄｅ Ｂ）で実現される。無線サブシステムネットワーク４１は、データフロー制御装置３１との間でＩＰパケットを送受信し、ＩＰパケットの送信先又は送信元となる無線サブシステム移動体端末５１との間で無線信号を伝送する。ＩＰパケットと無線信号との間の相互変換は無線サブシステムネットワーク４１内部の無線機で実施する。

無線サブシステム移動体端末５１は、無線信号とＩＰパケットを相互に変換し、無線サブシステムネットワーク４１内の無線機と無線信号を伝送し、データフロー制御装置３１との間でＩＰパケットを伝送する。ＬＴＥのシステムにおいてはＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）で実現される。

無線サブシステム移動体端末５１側に設けられるデータフロー制御装置３１及びアプリケーションプログラム実行装置２１は、無線サブシステムネットワーク４１側に設けられるものと、具体的なプログラム内容は異なってもよいが、デジタル信号とＩＰパケットの相互変換機能及びデータフロー制御機能を有する点で同等である。

図２は、本実施例のデータフロー制御ポリシー管理テーブルの例を示す図である。

データフロー制御ポリシー管理テーブルは、データフロー制御ポリシー記憶装置３２に記憶されている。データフロー制御ポリシー管理テーブルの内容は、工場出荷時に設定してもよく、又は、無線サブシステムネットワーク４１側のデータフロー制御装置３１と無線サブシステム移動体端末５１側のデータフロー制御装置３１との間の通信路の開通時に、両データフロー制御装置３１間で初期設定のためのシーケンスを定義して、同シーケンスに従い設定してもよく、又は、システム利用者からのコマンドラインインターフェース又はグラフィカルインターフェースを活用して設定してもよい。なお、これらの組み合わせによってデータフロー制御ポリシー管理テーブルの内容を設定し、データフロー制御ポリシー記憶装置３２に書き込んでもよい。

データフロー制御ポリシー管理テーブルは、データフロー識別子１０１、アプリケーションプログラムの名称１０２、データフローの名称１０３、データフロー制御ポリシー識別子１０４、無線サブシステムの名称１０５、優先度１０６、送信ウィンドウサイズ１０７、リピティション回数１０８、受信ウィンドウサイズ１０９、出力パケット処理ポリシー１１０、及び無線性能要求１１１を含む。なお、データフロー制御ポリシー管理テーブルには、一部の項目が定義されていなくても、アプリケーションが要求する性能に応じた項目のみが定義されていればよい。

アプリケーションプログラムの名称１０２は、データフロー制御装置３１がアプリケーション側の伝送相手、すなわちアプリケーションプログラムを特定するための情報である。

データフローの名称１０３は、アプリケーションプログラム内に１又は複数定義される。本実施例では、アプリケーション側から自動車を制御するための制御情報を伝送するデータフローと、現場から映像と音声のデータを伝送するデータフローの二つのデータフローが定義されている。映像と音声は別のデータフローとしてもよい。本実施例ではデータフロー名称毎にデータフロー制御ポリシーを定義するが、音声と映像で制御ポリシーが同一の場合は一つのデータフローとして定義し、制御ポリシーが異なる場合は複数のデータフローとして定義する。あくまで、アプリケーションを利用するシステム利用者の考え方に基づいて、データフローが定義される。

データフロー識別子１０１は、データフローの名称１０３と１対１で対応付ける。

データフロー制御ポリシー識別子１０４は、データフローの名称１０３で定義されるデータフロー毎に複数の識別子が割り当てられる。例えば、データフロー制御ポリシー識別子１０４はハイフンで区切られ、左側が通し番号、右側がＰｒｉｍａｒｙ（Ｐ）及びＳｅｃｏｎｄａｒｙ（Ｓ）の区別を示す。Ｓｅｃｏｎｄａｒｙとして定義されるデータフロー制御ポリシーは、Ｐｒｉｍａｒｙとして定義される全てのデータフローが通信断などの要因で使用不能となった場合に参照される。逆に、Ｐｒｉｍａｒｙとして定義されているデータフローの何れかが使用可能である場合、又は使用可能状態に変化した場合、Ｓｅｃｏｎｄａｒｙとして定義されているデータフローは使用されず、Ｐｒｉｍａｒｙとして定義されるデータフロー制御ポリシーが参照される。

無線サブシステムの名称１０５は、データフロー制御装置３１が無線サブシステム側の伝送相手を特定するための情報である。本実施例では、プライベート網の５Ｇ、公衆網のＬＴＥ、ＷｉＦｉを使用する例を示している。なお、Ｎ／Ａは当該データ制御ポリシーを定義しないことを示す。図２に示すデータフロー識別子が２の例では、Ｐｒｉｍａｒｙの無線サブシステムとしてプライベート網の５Ｇを使用するが、プライベート網の５Ｇが通信不可になったとしても、Ｓｅｃｏｎｄａｒｙの無線サブシステムを定義していないため、プライベート網の５Ｇが通信可能となるまでデータ伝送が一時的に不可能となることを許容するポリシー設定である。

優先度１０６は、無線サブシステム内で参照される優先度のインジケータである。複数のデータフローが同一の無線サブシステムを使用する場合に、優先度１０６の設定に従って優先度が制御される。無線サブシステムをまたがって優先度１０６を比較参照しないので、優先度１０６は無線サブシステムにて識別可能な定義でよい。たとえば、ＬＴＥならばＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｎｄｉｃａｔｏｒ）の値をそのまま用いてもよい。

送信ウィンドウサイズ１０７は、アプリケーションプログラム実行装置２１から入力されるパケットをバッファリングする時間、すなわち、パケットの送信間隔を定義する。アプリケーションプログラム実行装置２１から入力されるパケットは、送信ウィンドウサイズ分だけバッファリングされ、送信ウィンドウが終了する時点でパケットを出力される。送信ウィンドウサイズ１０７は、遅延ジッタを抑制するための制御パラメータである。送信ウィンドウサイズ１０７は、Ｎ／Ａ（ＦＩＦＯ）と定義されているデータフローでは、送信パケットをバッファリングせず、入力されたパケットをそのまま無線サブシステムへ転送する。

リピティション回数１０８は、データフロー制御装置３１から無線サブシステム側にパケットを出力する毎に、送信ウィンドウ内において同一パケットを複製して出力する複製回数である。リピティション回数１０８は、データ到達の信頼度、すなわちパケットロス率を低減するための制御パラメータである。リピティション回数１０８が１と定義されたデータフローでは、同一パケットは複製されない。

受信ウィンドウサイズ１０９は、アプリケーションプログラム実行装置２１へ入力されるパケットをバッファリングする時間、すなわち、パケットの受信間隔を定義する。アプリケーションプログラム実行装置２１に出力されるパケットは、一旦バッファリングされ、受信ウィンドウサイズが示す等間隔で出力され、ジッタが抑制される。受信ウィンドウサイズ１０９がＮ／Ａ（ＦＩＦＯ）と定義されているデータフローでは、受信パケットをバッファリングせず、入力されたパケットをそのままアプリケーションプログラム実行装置２１へ転送する。

出力パケット処理ポリシー１１０は、入力されたパケットを出力する方法を定義する。例えば、出力パケット処理ポリシー１１０がＬａｔｅｓｔ Ｐａｃｋｅｔ Ｏｎｌｙと定義されている場合、送信ウィンドウ又は受信ウィンドウの範囲でバッファリングしたデータのうち、最新の入力パケットのみを出力する。出力パケット処理ポリシー１１０がＡｌｌ Ｐａｃｋｅｔｓ ｅｘｃｌｕｄｉｎｇ ｄｕｐｌｉｃａｔｅｄと定義されている場合、入力されたパケットを原則としてそのまま出力するが、既に入力済みのパケットと同一のパケットが再度入力された場合には、後着パケットを破棄する。

無線性能要求１１１は、当該データフローで達成すべき伝送性能（例えば、スループット、パケットロス率、遅延ジッタ）の許容最大値を定義する。無線性能要求１１１は、データフロー毎の必要に応じて複数段階で設定してもよい。また、Ｌｅｖｅｌ毎に図２の表を定義してもよい。例えば、あるデータフローのデータ伝送開始時点で、初期値としてＬｅｖｅｌ１の無線性能要求をターゲット性能としてデータフロー制御を実施している場合、データ伝送途中で当該ターゲット性能の達成が困難であると判定されると、Ｌｅｖｅｌを１から２に変更してデータフロー通信を継続する。Ｌｅｖｅｌ２がＮ／Ａの場合、Ｌｅｖｅｌ１の性能が未達であっても、Ｌｅｖｅｌ１水準の無線性能要求を目標としてデータフロー制御を継続する。逆に、Ｌｅｖｅｌ２を目標にデータフロー制御を実施している場合、Ｌｅｖｅｌ１の無線性能要求を達成可能とデータフロー制御装置３１が判定されると、Ｌｅｖｅｌを１から２に変更して（Ｌｅｖｅｌ１を目標性能として）データフロー通信を継続する。なお、データフロー制御装置３１が無線性能要求のＬｅｖｅｌを変更した場合、変更後のＬｅｖｅｌをアプリケーションプログラム実行装置２１に通知してもよい。

図３は、本実施例のデータフロー制御装置３１内で取り扱われるＩＰパケットベースのデータフォーマットの例を示す図である。

アプリケーションプログラム実行装置２１、無線サブシステムネットワーク４１及び無線サブシステム移動体端末５１の各装置と、データフロー制御装置３１との間で伝送されるデータはＩＰパケットであり、ＩＰヘッダ２０２、ＴＣＰヘッダ又はＵＤＰヘッダ２０３、及びペイロード２０４を含む。

データフロー制御装置３１内では、ＩＰパケットの先頭に付与、又はＩＰパケット各々と１対１の対応関係が管理できる形式で、データフロー識別子２０１を付与する。データフロー識別子２０１は、データフロー制御ポリシー管理テーブル（図２）のデータフロー識別子１０１と等価である。

図４は、本実施例において、データフロー識別子とＩＰヘッダ情報とを関連付けるデータフロー識別子辞書の例を示す。

データフロー識別子辞書は、データフロー識別子３０１、サーバＩＰアドレス３０２、サーバポート番号３０３、クライアントＩＰアドレス３０４、クライアントポート番号３０５、及びプロトコル番号３０６を含む。

データフロー識別子３０１は、データフロー制御ポリシー管理テーブル（図２）のデータフロー識別子１０１と等価である。

サーバＩＰアドレス３０２は、サーバ側の装置を一意に識別するためのアドレスである。サーバの定義には様々な方法が採用し得るが、本実施例では無線サブシステムネットワーク４１側のアプリケーションプログラム実行装置２１のＩＰアドレスと定義する。

サーバポート番号３０３は、ＴＣＰ又はＵＤＰのヘッダの中に含まれるサーバ側のポート番号である。

クライアントＩＰアドレス３０４は、クライアント側の装置を一意に識別するためのアドレスである。サーバの定義には様々な方法が採用し得るが、本実施例では無線サブシステム移動体端末５１側のアプリケーションプログラム実行装置２１のＩＰアドレスと定義する。

クライアントポート番号３０５は、ＴＣＰ又はＵＤＰのヘッダの中に含まれるクライアント側のポート番号である。

プロトコル番号３０６は、ＩＰヘッダに含まれる情報である。

ＩＰパケットがデータフロー制御装置３１に入力される際は、サーバＩＰアドレス３０２、サーバポート番号３０３、クライアントＩＰアドレス３０４、及びプロトコル番号３０６をインデックスとして、データフロー識別子３０１を辞書引きする。なお、サーバＩＰアドレス３０２からプロトコル番号３０６の数字全体を多バイトのインデックスとして辞書引きする形式でもよいが、辞書サイズが巨大になるため、サーバＩＰアドレス３０２からプロトコル番号３０６の数字全体をハッシュ処理した値をインデックスとして辞書引きしてもよい。

データフロー制御装置３１からＩＰパケットが出力される際は、データフロー識別子３０１をインデックスとして、サーバＩＰアドレス３０２、サーバポート番号３０３、クライアントＩＰアドレス３０４、及びプロトコル番号３０６を辞書引きする。該当するＩＰパケットから、直接、サーバＩＰアドレス３０２、サーバポート番号３０３、クライアントＩＰアドレス３０４、及びプロトコル番号３０６の情報を読み出してもよい。この情報は、ＩＰパケットの転送先を示す情報として活用される。

また、データフロー制御ポリシー管理テーブル（図２）に記憶される特定のデータフローＩＤを予約番号としてもよい。例えば、データフローＩＤ＝０をデータフロー制御ポリシー記憶装置３２への設定用の予約番号としてもよい。

図５は、本実施例のデータフロー制御装置３１内の送信データフロー制御部４０１の構成例を示す図である。

データフロー制御ポリシー管理テーブル（図２）は、送信データフロー制御部４０１の全ての要素から参照可能である。

データフロー名寄せ部４０３は、アプリケーションプログラム実行装置２１から入力されるＩＰパケットに、データフロー識別子辞書（図４）を参照し、データフロー識別子を関連付け、データフロー識別子に関連付けられた送信データフロー処理部４０４へ転送する。当該データフロー識別子に関連付けられた送信データフロー処理部４０４が複数ある場合、当該複数の送信データフロー処理部４０４の全てに同一内容を転送する。なお、送信データフロー制御部４０１は、複数アプリケーションプログラムからの入力を受け付けることが可能である。

送信データフロー処理部４０４は、データフロー制御ポリシー管理テーブル（図２）のデータフロー制御ポリシー識別子１０４毎に相互に独立のプログラムプロセスとして設けられる。つまり、各送信データフロー処理部４０４に対して、データフロー識別子やデータフロー制御ポリシー識別子などの制御パラメータが、データフロー制御ポリシー管理テーブル（図２）に基づいて関連付けられている。送信データフロー処理部４０４の詳細は後述する。

送信データフロー処理部４０４の出力は、データフロー制御装置３１内の無線サブシステム側送信処理部４０７へ入力される。無線サブシステム側送信処理部４０７は無線サブシステム単位で定義されるため、データフロー制御ポリシー管理テーブル（図２）において、ある一つの無線サブシステムに対して複数の送信データフロー処理部４０４が関連付けられている場合は、当該無線サブシステム側送信処理部４０７には、複数の送信データフロー処理部４０４のプログラムプロセスからＩＰパケットが転送される。図５の例であれば、送信データフロー処理部４０４－２及び４０４－４の出力は、一つの無線サブシステム側送信処理部４０７－２に入力される。

無線サブシステム監視部４０５は、各無線サブシステムの通信性能を予測する機能、及びＰｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙいずれかの利用をデータフロー識別子毎に判定する機能を有する。予測及び判定結果は全ての送信データフロー処理部４０４へ入力される。

送信データフロー処理部４０４は、無線サブシステム監視部４０５によるＰｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙ判定結果に基づいて、ＩＰパケットを出力するか、出力を抑止するかを判定する。Ｐｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙの判定はデータフロー識別子１０１単位で実施する。

例えば、データフロー制御ポリシー識別子にＰが付与されている送信データフロー処理部４０４は、無線サブシステム監視部４０５から当該データフロー識別子に関してＰｒｉｍａｒｙを使用するという判定結果を受けた場合は、データフロー制御結果を出力するが、無線サブシステム監視部４０５からＳｅｃｏｎｄａｒｙを使用するという判定結果を受けた場合は、データフロー制御結果の出力を抑止する。

また、無線サブシステム監視部４０５は、データフロー制御ポリシー管理テーブル（図２）の無線性能要求１１１で示す無線性能要求の各段階を、データフロー識別子１０１毎に達成できる見込みか否かを判定し、データフロー識別子毎に無線性能要求の目標水準（Ｌｅｖｅｌ）を決定する。目標水準が変化した場合は、目標水準が変化したことと、変化後の目標水準を通知する。データフロー名寄せ部４０３の動作の詳細は後述する。

図６は、本実施例のデータフロー制御装置内の受信データフロー制御部４０２の構成例を示す図である。

データフロー制御ポリシー管理テーブル（図２）は、受信データフロー制御部４０２の全ての要素から参照可能である。

データフロー名寄せ部４０３は、無線サブシステム側受信処理部４０８から入力されるＩＰパケットに、データフロー識別子辞書（図４）を参照し、データフロー識別子を関連付け、データフロー識別子に関連付けられた受信データフロー処理部４０６へ転送する。無線サブシステム側受信処理部４０８は無線サブシステムごとに設けられ、データフロー名寄せ部４０３は１又は複数の無線サブシステム側受信処理部４０８からＩＰパケットが入力される。

受信データフロー処理部４０６は、データフロー制御ポリシー管理テーブル（図２）のデータフロー識別子１０１毎に相互に独立のプログラムプロセスとして設けられる。つまり、各受信データフロー処理部４０６に対して、データフロー識別子などの制御パラメータが、データフロー制御ポリシー管理テーブル（図２）に基づいて関連付けられている。ただし、受信データフロー処理部４０６は、送信データフロー処理部４０４と異なり、データフロー制御ポリシー識別子１０４に関連付けられる無線サブシステムの名称１０５、優先度１０６、及びリピティション回数１０８は受信データフロー処理部４０６に関連付けられない。同一のデータフロー制御識別子の異なるデータフロー制御ポリシー識別子にて送信されたデータの内容は同一であり、受信側では複数のデータフロー制御ポリシー識別子にて送信されたデータを一つのプロセスで受信する。受信データフロー処理部４０６の詳細は後述する。

図７は、本実施例のデータフロー制御装置３１内の無線サブシステム側送信処理部４０７の構成例を示す図である。

データフロー制御ポリシー管理テーブル（図２）は、無線サブシステム側送信処理部４０７の全ての要素から参照可能である。

無線サブシステム側送信処理部４０７は、無線サブシステムごとに、例えばＬＴＥ用、ＷｉＦｉ用に、異なるプロセスのものが設けられる。

各無線サブシステム側送信処理部４０７は、対応する無線サブシステムを使用する全ての送信データフロー処理部４０４からデータが入力される。バッファ振分部４１１が送信データフロー処理部４０４に関連付けられる優先度１０６に応じて設けられる送信待ちバッファ４１２に入力データを格納する。どの優先度１０６のデータをどの送信待ちバッファ４１２に格納するか、及び送信待ちバッファ４１２の数はシステムへの実装によって異なる。いずれにしても、優先度が異なるデータは、異なる送信待ちバッファ４１２に格納される。

優先送信制御部４１３は、複数ある送信待ちバッファ４１２のうち優先度が高い方からから順にデータを読み出して出力する。例えば、１番目に優先度の高い送信待ちバッファ４１２が空になった後に、２番目に優先度の高い送信待ちバッファ４１２からデータを読み出す。

伝送フォーマット変換部４１４は、ＩＰパケットから無線サブシステムが利用可能な形式にフォーマット変換する機能を有する。無線サブシステムがＩＰパケットを入力するシステムであれば、本機能ブロックは不要である。フォーマット変換が必要な場合、ＩＰパケットのうちペイロード以外の部分を、無線サブシステム内でパケットルーティングするために必要な情報に書き換える、又はＩＰパケット全体をペイロードとして無線サブシステム内で参照するヘッダを付与するなどの処理を行う。変換処理としては、ＩＰヘッダの一部又は全部をインデックスとして辞書引きする、ＩＰヘッダの一部又は全部を引数とした換算式を用いて変換する方法など、何れの方法でもよい。

無線サブシステム側送信処理部４０７の出力は、該当する無線サブシステムの無線サブシステムネットワーク４１又は無線サブシステム移動体端末５１に転送される。

図８は、本実施例のデータフロー制御装置３１内の無線サブシステム側受信処理部４０８の構成例を示す図である。

無線サブシステム側受信処理部４０８は、無線サブシステム側送信処理部４０７とセットになるように無線サブシステム毎に定義される。

伝送フォーマット逆変換部４１５は、無線サブシステムネットワーク４１又は無線サブシステム移動体端末５１から入力されるデータパケットを、伝送フォーマット変換部４１４の逆変換処理となるようにＩＰパケットに変換する。ＩＰパケットが入力される場合、本処理は省略してもよい。出力されるＩＰパケットは、受信データフロー制御部４０２へ転送される。

図９は、本実施例の送信データフロー処理部４０４で実行される処理を説明するためのタイミング図である。

以後の説明にあたり、データフロー制御ポリシー管理テーブル（図２）の送信ウィンドウサイズ１０７が１０ミリ秒、リピティション回数１０８が５のデータフロー制御ポリシーを想定する。

送信データフロー処理部４０４に入力されるＩＰパケットは一時的にバッファリングされる。バッファリングする期間は、送信ウィンドウサイズ１０７で定められた期間（例えば１０ミリ秒）である。

バッファリングの期間が終了すると、バッファの中身を無線サブシステム側送信処理部４０７へ出力する。その際、バッファ内のＩＰパケットを複数回（例えば５回）複製して出力する。出力方法として、図９に示すように複製パケットを連続して出力してもよいし、５個の複製ＩＰパケットを１０ミリ秒間に等間隔（つまり２ミリ秒間隔）で出力してもよい。

当該送信データフロー処理部４０４に関連付けられた送信ウィンドウサイズ１０７がＮ／Ａである場合、入力されたＩＰパケットはバッファリング及び複製されずに、そのまま出力される。

バッファリング期間に複数のＩＰパケットが入力された場合、出力パケット処理ポリシー１１０で定められたポリシーに従って出力を制御する。例えば、出力パケット処理ポリシー１１０がＬａｔｅｓｔ Ｐａｃｋｅｔ Ｏｎｌｙである場合は、バッファリング期間の間に入力された最後のＩＰパケットのみを複製及び出力対象とし、それ以外のＩＰパケットを破棄する。

一方、出力パケット処理ポリシー１１０がＡｌｌ Ｐａｃｋｅｔｓ ｅｘｃｌｕｄｉｎｇ ｄｕｐｌｉｃａｔｅｄである場合は、入力されたＩＰパケット全てが複製及び出力対象となる。ただし、バッファリング期間内でＩＰパケットが重複する場合は、後着のＩＰパケットを破棄する。このため、バッファリング期間中は入力されるＩＰパケットと、バッファの中に一時記憶されているＩＰパケットとを照合し、条件付きの重複排除を実施する。また、照合の際にＩＰパケット全体の全文一致ではなく、ＴＣＰヘッダのシーケンス番号を用いて重複排除する方が全文照合よりも照合効率が向上する。なお、ＴＣＰヘッダのシーケンス番号ではなく、ペイロードの一部にアプリケーションレベルで予め定義及び割り当てられたシーケンス番号を用いて重複排除してもよい。

以上で述べた通り、送信データフロー処理部４０４は、データフロー制御ポリシー管理テーブル（図２）に設定されたパラメータに応じたパケット複製処理、及び出力タイミング調整処理を実行する。

図１０は、本実施例の受信データフロー処理部４０６で実行される処理を説明するためのタイミング図である。以後の説明にあたり、データフロー制御ポリシー管理テーブル（図２）の受信ウィンドウサイズ１０９が１０ミリ秒のデータフロー制御ポリシーを想定する。

受信データフロー処理部４０６に入力されたＩＰパケットは一時的にバッファリングされる。バッファリングする期間は、受信ウィンドウサイズ１０９で定められた期間（例えば１０ミリ秒）である。

バッファリングの期間において、無線区間においてロストしたＩＰパケット５０２があっても、送信側で複製された同一のＩＰパケット５０１を複数回受信した場合は、図９の制御例で述べたように、条件付きの重複排除を実施する。つまり、新たに入力されたＩＰパケットとバッファ内部に蓄積されたＩＰパケットを、ＴＣＰヘッダのシーケンス番号などを用いて照合し、蓄積済みのＩＰパケットと同一であると判定された場合に、後着のＩＰパケットを破棄する。

バッファリング期間が終了し出力期間となると、バッファリングされたＩＰパケットが順次出力される。

図９の制御例と同様に、出力パケット処理ポリシー１１０の内容によってバッファリング期間の最新パケットのみを出力するか、重複していない全てのパケットを出力するかを制御する。

受信ウィンドウサイズ１０９がＮ／Ａの場合は、入力されたＩＰパケットはバッファリングされずに、そのまま出力される。

以上で述べた通り、受信データフロー処理部４０６は、データフロー制御ポリシー管理テーブル（図２）に設定されたパラメータに応じた重複排除処理、及び出力タイミング調整処理を実行する。

図１１は、本実施例の無線サブシステム監視部４０５の構成例を示す図である。データフロー制御ポリシー管理テーブル（図２）は、無線サブシステム側送信処理部４０７の全ての要素から参照可能である。

ポーリング監視部６０１は、各無線サブシステムとの間で、定期的にＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）又は無線サブシステムにて固有に定義されているＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）又はメッセージを活用し、無線サブシステムの情報、例えば固定無線機（すなわち基地局）ごとの無線リソース使用率、端末毎のスループットの情報を収集する。収集した無線サブシステムの情報は無線サブシステム管理テーブル６０２に格納される。

無線性能診断部６０３は、データフロー制御識別子毎のＰｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙを判定し、及びデータフロー制御識別子毎の無線性能要求１１１のＬｅｖｅｌを決定する。

Ｐｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙの判定は、データフロー識別子ごとに、端末スループットに基づいて、少なくとも一つのＰｒｉｍａｒｙ無線サブシステムが使用可能と判定できればＰｒｉｍａｒｙを使用し、全てのＰｒｉｍａｒｙ無線サブシステムが使用不可能と判定されればＳｅｃｏｎｄａｒｙ無線サブシステムを使用する。

この判定は、無線サブシステム管理テーブル６０２で収集可能な情報量にも依存するが、移動体端末レベルで収集可能であれば、移動体端末ごとの結果を出してもよく、全ての移動体端末の間で最低のスループット値を参照して、Ｐｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙを判定して、全移動体端末に一斉に適用してもよい。

移動体端末ごとにＰｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙが判定できる場合、移動体端末ごとの判定結果を送信データフロー処理部４０４に通知して、送信データフロー処理部４０４にてＩＰパケットのヘッダを参照して移動体端末を特定し、無線性能診断部６０３からのＰｒｉｍａｒｙ／Ｓｅｃｏｎｄａｒｙ通知に基づいて出力処理又は出力抑止処理を実行する。

Ｌｅｖｅｌの決定は、現状データフロー識別子に適用されている無線性能要求Ｌｅｖｅｌを無線性能診断部６０３の中に保持し、当該Ｌｅｖｅｌに対応する要求スループットをデータフロー制御ポリシー管理テーブル（図２）から参照する。単純に制御するのであれば、無線サブシステム管理テーブル６０２に記録されている端末スループットが要求スループットを下回る場合はＬｅｖｅｌを要求品質が低い方へシフトし、端末スループットが要求スループットを超える場合はＬｅｖｅｌを要求品質の高い方へシフトする。

端末ごとのスループット情報が取得できない場合や、アプリケーションプログラムが端末ごとのアプリケーション品質を取り扱えない場合は、前者の判定と同様、判定に用いるスループットを全端末を代表する統計値（例えば、最小値、平均値）とするとよい。

いずれにしてもＬｅｖｅｌが変更された場合に、アプリケーションプログラム実行装置２１に対してＬｅｖｅｌが変更された旨と、変更後のＬｅｖｅｌを通知するとよい。

通常、Ｌｅｖｅｌ変更は、無線サブシステムネットワーク４１側、又は無線サブシステム移動体端末５１側のいずれかで先行すると考えられる。つまり、一時的に無線サブシステムネットワーク４１側のアプリケーションの品質水準と、無線サブシステム移動体端末５１側のアプリケーションの品質水準とが不整合となる場合がある。

このような不整合を回避するため、アプリケーションから出力されるＩＰパケット内ペイロードの先頭又は特定の位置に、どのＬｅｖｅｌで伝送しているデータかを示すインジケータを追加して、前述のような不整合が一時的に発生している状況でも、少なくとも送信側のアプリケーションと受信側のアプリケーションとの間でアプリケーションデータの伝送に支障が生じないようにするとよい。

図１１では無線サブシステム監視部４０５が、無線サブシステムの性能（例えば、スループット）に応じて、Ｌｅｖｅｌを動的に変更したが、リピティション回数を動的に変更してもよい。

以上に説明したように、本発明の実施例の通信システムは、アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されたポリシー記憶部（データフロー制御ポリシー記憶装置３２）と、各通信サブシステムにて実現可能な通信品質に基づいて、アプリケーションと通信サブシステムの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御するデータフロー制御装置３１とを備えるので、無線サブシステムの性能と当該アプリケーションの通信品質要求との差異を小さくするデータフロー制御を実施でき、アプリケーションデータを伝送する無線サブシステムを切り替えもアプリケーション毎の通信品質要求を満たすことができる。

また、データフロー制御装置３１は、データの再送回数、及びデータを送受信するウィンドウサイズの少なくとも一つを制御するので、アプリケーションの通信品質として要求されるエラー率、ジッタを適確に制御できる。

また、データフロー制御装置３１は、アプリケーションが使用する通信サブシステムの通信品質推定値が、現在目標としている通信品質要求を満たせないと判定した場合、より低い段階の通信品質要求に変更し、当該変更をアプリケーションに通知するので、無線サブシステムの通信性能の実力が低下している状況でも、安全設計の観点で許される範囲であるアプリケーションの伝送データ量を減らして、他のアプリケーションが使用可能な通信リソースを確保し、システム全体としては通信品質要求を満たすことができる。また、伝送データ量の減少を無線レイヤからアプリケーションに通知することで、アプリケーション側が高品質を期待している状況でも、無線レイヤの品質の低下による、アプリケーション側の誤動作を抑制できる。

また、データフロー制御装置３１は、アプリケーションが使用する通信サブシステムの通信品質推定値が、現在目標としている通信品質要求より高い段階の通信品質要求を満たせると判定した場合、より高い段階の通信品質要求に変更し、当該変更をアプリケーションに通知するので、無線サブシステムの通信性能の実力が上昇している状況では、アプリケーションが伝送可能なデータ量を増やすことができる。例えば、映像伝送アプリケーションにて、画素数やフレームレートを倍にすることで、映像を観測するユーザが映像によって非安全な事象を発見する機会を増加できる。また、伝送データ量の増加を無線レイヤからアプリケーションに通知することで、アプリケーション側が低品質を期待している状況でも、無線レイヤの品質の向上による、アプリケーション側の誤動作を抑制できる。

また、データフロー制御装置３１は、第１順位（Ｐｒｉｍａｒｙ）の通信サブシステムが使用可能と判定した場合、第１順位の通信サブシステムを使用し、第１順位の通信サブシステムが使用不可能と判定した場合、第２順位（Ｓｅｃｏｎｄａｒｙ）の通信サブシステムを使用してデータフローを制御し、第２順位の通信サブシステムを使用中に、第１順位の通信サブシステムが使用可能と判定した場合、第２順位の通信サブシステムの使用を中止し、第１順位の通信サブシステムを使用してデータフローを制御するので、あるアプリケーションが使用している無線サブシステムが動作しなくなっても、他の無線サブシステムで動作を継続できる。また、本来無線サブシステムが動作するようになると、他の無線サブシステムから本来の無線サブシステムに切り替えて動作を継続できる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウエアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウエアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１１…移動体操作装置
１２…現場再生装置
２１…アプリケーションプログラム実行装置
３１…データフロー制御装置
３２…データフロー制御ポリシー記憶装置
４１…無線サブシステムネットワーク
５１…無線サブシステム移動体端末
６１…移動体制御装置
６２…センサ装置
１０１…データフロー識別子
１０２…アプリケーションの名称
１０３…データフローの名称
１０４…データフロー制御ポリシー識別子
１０５…無線サブシステムの名称
１０６…優先度
１０７…送信ウィンドウサイズ
１０８…リピティション回数
１０９…受信ウィンドウサイズ
１１０…出力パケット処理ポリシー
１１１…無線性能要求
２０１…データフロー識別子
２０２…ＩＰヘッダ
２０３…ＴＣＰヘッダ又はＵＤＰヘッダ
２０４…ペイロード
３０１…データフロー識別子
３０２…サーバＩＰアドレス
３０３…サーバポート番号
３０４…クライアントＩＰアドレス
３０５…クライアントポート番号
３０６…プロトコル番号
４０１…送信データフロー制御部
４０２…受信データフロー制御部
４０３…データフロー名寄せ部
４０４…送信データフロー処理部
４０５…無線サブシステム監視部
４０６…受信データフロー処理部
４０７…無線サブシステム側送信処理部
４０８…無線サブシステム側受信処理部
４１１…バッファ振分部
４１２…送信待ちバッファ
４１３…優先送信制御部
４１４…伝送フォーマット変換部
４１５…伝送フォーマット逆変換部
５０１…ＩＰパケット
５０２…無線区間でロストしたＩＰパケット
６０１…ポーリング監視部
６０２…無線サブシステム管理テーブル
６０３…無線性能診断部

Claims (14)

1. 複数の通信サブシステムを経由して少なくとも一つのアプリケーションが通信しながら動作するプラットフォームを提供する通信システムであって、
   前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されたポリシー記憶部と、
   前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと前記通信サブシステムとの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御する制御装置とを備え、
   前記通信品質要求はジッタであって、
   前記制御装置は、データを送受信するウィンドウサイズによってジッタを制御することを特徴とする通信システム。
2. 複数の通信サブシステムを経由して少なくとも一つのアプリケーションが通信しながら動作するプラットフォームを提供する通信システムであって、
   前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されたポリシー記憶部と、
   前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと前記通信サブシステムとの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御する制御装置とを備え、
   前記アプリケーションには複数段階の通信品質要求が設定されており、
   前記制御装置は、前記アプリケーションが使用する通信サブシステムの通信品質推定値が、現在目標としている通信品質要求を満たせないと判定した場合、より低い段階の通信品質要求に変更し、当該変更を前記アプリケーションに通知することを特徴とする通信システム。
3. 複数の通信サブシステムを経由して少なくとも一つのアプリケーションが通信しながら動作するプラットフォームを提供する通信システムであって、
   前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されたポリシー記憶部と、
   前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと前記通信サブシステムとの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御する制御装置とを備え、
   前記ポリシー記憶部には、前記アプリケーション毎に使用する複数の通信サブシステムについて、優先度が第１順位の通信サブシステムと優先度が第２順位の通信サブシステムが定義されており、
   前記制御装置は、前記第１順位の通信サブシステムが使用可能と判定した場合、前記第１順位の通信サブシステムを使用し、前記第１順位の通信サブシステムが使用不可能と判定した場合、前記第２順位の通信サブシステムを使用してデータフローを制御することを特徴とする通信システム。
4. 請求項１から３のいずれか一つに記載の通信システムであって、
   前記制御装置は、
   データフロー毎に、前記アプリケーションから入力されるデータを一時的に格納し、必要に応じて複製して出力する送信データフロー制御部と、
   前記送信データフロー制御部から出力されたデータを前記通信サブシステムに出力する送信処理部と、
   前記通信サブシステムで伝送されるデータを、必要に応じてフォーマット変換する受信処理部と、
   データフロー毎に、前記受信処理部から入力されるデータを一時的に格納し、必要に応じて重複排除した後に出力する受信データフロー制御部とを有することを特徴とする通信システム。
5. 請求項２又は３に記載の通信システムであって、
   前記通信品質要求はエラー率であって、
   前記制御装置は、データの再送回数によってエラー率を制御することを特徴とする通信システム。
6. 請求項２に記載の通信システムであって、
   前記制御装置は、前記アプリケーションが使用する通信サブシステムの通信品質推定値が、現在目標としている通信品質要求より高い段階の通信品質要求を満たせると判定した場合、より高い段階の通信品質要求に変更し、当該変更を前記アプリケーションに通知することを特徴とする通信システム。
7. 請求項３に記載の通信システムであって、
   前記制御装置は、前記第２順位の通信サブシステムを使用中に、前記第１順位の通信サブシステムが使用可能と判定した場合、前記第２順位の通信サブシステムの使用を中止し、前記第１順位の通信サブシステムを使用してデータフローを制御することを特徴とする通信システム。
8. 複数の通信サブシステムを経由して通信しながら動作する少なくとも一つのアプリケーションのデータフローを制御する通信制御方法であって、
   前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されており、
   前記通信制御方法は、前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと前記通信サブシステムとの組み合わせ毎に、当該アプリケーションにおける通信品質要求であるジッタを満たすようにデータフローを制御し、
   データを送受信するウィンドウサイズによってジッタを制御することを特徴とする通信制御方法。
9. 複数の通信サブシステムを経由して通信しながら動作する少なくとも一つのアプリケーションのデータフローを制御する通信制御方法であって、
   前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されており、
   前記アプリケーションには複数段階の通信品質要求が設定されており、
   前記通信制御方法は、
   前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと前記通信サブシステムとの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御し、
   前記アプリケーションが使用する通信サブシステムの通信品質推定値が、現在目標としている通信品質要求を満たせないと判定した場合、より低い段階の通信品質要求に変更し、当該変更を前記アプリケーションに通知することを特徴とする通信制御方法。
10. 複数の通信サブシステムを経由して通信しながら動作する少なくとも一つのアプリケーションのデータフローを制御する通信制御方法であって、
    前記アプリケーションにおける通信品質要求と、当該アプリケーションの通信に使用する少なくとも一つの前記通信サブシステムが、該アプリケーションが通信を開始する前に予め定義されており、
    前記アプリケーション毎に使用する複数の通信サブシステムについて、優先度が第１順位の通信サブシステムと優先度が第２順位の通信サブシステムが定義されており、
    前記通信制御方法は、
    前記各通信サブシステムにて実現可能な通信品質に基づいて、前記アプリケーションと前記通信サブシステムとの組み合わせ毎に、当該アプリケーションにおける通信品質要求を満たすようにデータフローを制御し、
    前記第１順位の通信サブシステムが使用可能と判定した場合、前記第１順位の通信サブシステムを使用し、前記第１順位の通信サブシステムが使用不可能と判定した場合、前記第２順位の通信サブシステムを使用してデータフローを制御することを特徴とする通信制御方法。
11. 請求項８から１０のいずれか一つに記載の通信制御方法であって、
    データフロー毎に、前記アプリケーションから入力されるデータを一時的に格納し、必要に応じて複製して出力し、
    前記出力されたデータを前記通信サブシステムに出力して、前記通信サブシステムを介して伝送し、
    前記通信サブシステムで伝送されるデータを、必要に応じてフォーマット変換し、
    データフロー毎に、前記入力されるデータを一時的に格納し、必要に応じて重複排除した後に出力することを特徴とする通信制御方法。
12. 請求項９又は１０に記載の通信制御方法であって、
    前記通信品質要求はエラー率であって、
    データの再送回数によってエラー率を制御することを特徴とする通信制御方法。
13. 請求項９に記載の通信制御方法であって、
    前記アプリケーションが使用する通信サブシステムの通信品質推定値が、現在目標としている通信品質要求より高い段階の通信品質要求を満たせると判定した場合、より高い段階の通信品質要求に変更し、当該変更を前記アプリケーションに通知することを特徴とする通信制御方法。
14. 請求項１０に記載の通信制御方法であって、
    前記第２順位の通信サブシステムを使用中に、前記第１順位の通信サブシステムが使用可能と判定した場合、前記第２順位の通信サブシステムの使用を中止し、前記第１順位の通信サブシステムを使用してデータフローを制御することを特徴とする通信制御方法。

Images