JP2004528764A - Ｉｐネットワークへの複数パスアクセス内の通信パスを同時に使用する方法 - Google Patents

Abstract

ＩＰを基盤とする通信ネットワークを経由して通信セッションを実行する際に、複数のベアラ（１１，１３，１５）を経由して通信ネットワークへのアクセスが達成されており、通信アプリケーション（４７）と関連づけられた複数のパケットフローは、当該複数のベアラのそれぞれを介し、同時並行してルーティングされる。

Description

【技術分野】
【０００１】
本発明は、一般にデジタル通信に係り、とりわけＩＰを基盤とする通信に関連する。
【背景技術】
【０００２】
インターネットプロトコルを利用するネットワークへの接続が広く利用可能となったため、そのような接続の機会が増加するとともに、とりわけ無線アクセス技術の導入がさらに増加し続けている。通信端末装置のユーザは、例えばＵＭＴＳ、ワイヤレスＬＡＮ（ＷＬＡＮ）、ブルートース、赤外線のＩｒＤＡ、あるいは固定されたイーサネット（登録商標）など、種々の方法を使用してＩＰネットワークにいつでもアクセスすることができる。
【０００３】
もしユーザの通信端末装置が固定されていれば、利用可能なアクセス方法の数は一定であるが、一方で、通信端末装置がある位置から他の位置へと物理的に移動可能な場合は、移動するにしたがって利用可能なアクセス方法の数が変化することになろう。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述した例のようなアクセス方法は、例えば、帯域幅、待ち時間、信頼性、電力消費量、カバー範囲、パケット損失、及び使用料金など様々な観点で異なる可能性がある。図１Ａに示されているように、ＩＰ通信では、２つのアプリケーションが通信用の下位レイヤーのトランスポートレイヤーを使用し、いわゆる『ソケット』を経由してアクセスされる。あるアプリケーションから他のアプリケーションへのトランスポートについての要求（リクエスト）は、例えば、ユーザの期待、トランスポート対象データのサイズ、トランスポート対象データのフォーマットやその他などに依存して顕著に変化するであろう。
【０００５】
ソケットを経由して利用可能なトランスポートサービスが頻繁に変化する上述したような状況を考察すると、利用可能なトランスポートサービスにおける変化の管理だけでなく、下位レイヤーサービス上へのアプリケーションフローのマッピングも重要になりうることがわかる。
【０００６】
それゆえ、２つのＩＰエンドポイント間での通信をサポートするために利用可能なトランスポート（特にアクセス）サービスを慎重に利用することが望ましい。
【課題を解決するための手段】
【０００７】
本発明は、例えば移動したことが原因で利用できるトランスポートサービスの変更の管理などを含む、一以上の通信アプリケーションの各パケットフロー用に複数のアクセス方法を同時並行的に使用してＩＰを基盤とする通信を通信端末に提供するものである。例示的な実施形態において、本発明は：フローの要求とトンネルの能力及び特性とを考慮して、上りリンク及び下りリンクにおける情報フローを一以上のトンネルに対し同時並行的にマッピングすること（各トンネルはリンクインタフェース又はリンクインタフェース上のベアラに関連付けられていてもよい）；通信端末装置の移動（本発明はこれに限定されることはない）などを原因としたリンク変更の管理（管理メカニズムによって、上りリンク及び下りリンクにおける他のトンネル（インタフェース若しくはトランスポートチャネル）上へのフローの再マッピングをサポートすること、並びに上位レイヤー及びユーザの少なくとも一方に変更の情報を供給すること）；リンク変更によるフローの再マッピングに関連して必要となりうる情報フローの適合化のためのフレームワーク；異なる複数のトンネルを介した分離を可能とすべく、最適なアクセスの活用と情報フロー構造に関する可能な再構成を黙示的に決定するための情報フローの分析；ユーザと、トランスポート対象の情報を生成するアプリケーションと、設定ファイル、ポリシー及びリアルタイムでの相互動作のためのＡＰＩにおけるメソッドコール（本発明はこれらに限定されることはない）を含む上述のメカニズムとの間の相互動作；情報フローのマッピングを再構成するためのニーズを検出するための下位レイヤーとの相互動作；及びサードパーティにより、ポリシーを経由した情報フローのマッピング（配置及び移動）に影響を及ぼすことを可能ならしめる。
【発明を実施するための最良の形態】
【０００８】
本発明は、アクセス方法の選択において二者択一を必要とするものではない。むしろ、ユーザが同時並行的に多重アクセス技術を利用できれば、本発明は有利に働こう。本発明に係るいくつかの実施形態において、この多重アクセスの管理は、それぞれ異なるアクセス方法を使用した種々のパケットフローを同一のセッション内で実現できるほどに十分な柔軟性を有している。例えば、音声メディアのフローと、それに関連するシグナリング（信号伝達）のフローとが、セッションの間中、ＵＭＴＳのトランスポートサービスを利用可能である一方、ビデオメディアのフローがブルートゥースを利用可能なときは当該ブルートゥースへと切り替えが可能であろう。なぜなら、例えば、ＵＭＴＳのアクセス技術によってより良いカバレッジエリア提供されているからである。概して、本発明によれば、トランスポートサービス上での異なる特性及びそれによる異なる要求とを伴うパケットフローは、利用可能なアクセス技術の特性及び個々のパケットフローの行動条件に依存した適切なアクセス技術を利用することが可能となる。
【０００９】
本発明の例示的な実施形態によれば、空間上の任意の地点において、ＩＰを基盤とするアプリケーションは、あるホップについて複数のトランスポートの候補を利用できるため利点がある。いくつかの実施形態においてホップとは第１のリンクのことであり、ＩＰホストから見てわかるように別名「アクセス」のことである。本発明によれば、任意のアプリケーションから複数のパケットフロー及び当該アプリケーションへの複数のパケットフローが同時に多重アクセスを利用することを可能にする。この概念は同様に、同時並列多重アクセス（Ｓｉｍｕｌｔａｎｅｏｕｓ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）又はＳＩＭＡＣと呼ばれる。このようにＳＩＭＡＣは、ユーザの通信端末装置がそれを通して複数のパケットフローのそれぞれを送受信可能な複数の異なるアクセスインターフェイスを同時使用する技術に関連している。本発明のいくつかの実施形態によれば、それぞれ複数のアクセスインターフェイスや関連するベアラを利用する複数のパケットフローは、そのすべてが他のエンドシステムに対しトランスペアレントな単一の通信アプリケーションと関連していてもよい。
【００１０】
ＳＩＭＡＣ機能は、いくつかのトランスポート（アクセス）技術を橋渡しする『仮想的な』ＩＰベアラを作成する機能と呼ぶこともできよう。ＳＩＭＡＣは、アプリケーションレイヤーとリンクレイヤー（加えて、トランスポートレイヤーとネットワークレイヤー）間の相互動作を含めることができ、それゆえ、利用可能なトランスポート能力の変更を伝えるために設計されたアプリケーションの開発がより一層容易となる。
【００１１】
いくつかの実施形態で、ＳＩＭＡＣは一つのセッションを基礎として呼び出し可能であり、また、ユーザの端末装置又はユーザのアプリケーションが任意の瞬間に一つだけのアクセスを利用する状況をもサポートすることができる。各々のアプリケーションごとにプロファイルを作成することができる。プロファイルは、利用可能なアクセスをどのように使用すべきかを示すもので、別名で嗜好情報（プリファレンス）ともいう。ユーザや、サービスプロバイダのような外的な団体が、アクセスの嗜好情報とともにプロファイルを設定することができる。嗜好情報は、特定のアプリケーション及びＳＩＭＡＣ機能自体の少なくとも一つに関連している。
【００１２】
いくつかの実施形態では、例えば、メディア符号変換機能などの他のサポート機能とＳＩＭＡＣ機能とを組み合わせることもできる。メディア符号変換機能は、アプリケーションフローにとってトランスペアレントではない利用可能なトランスポートの能力が変更された場合に、当該変更に当該アプリケーションフローを適合させるためのものである。例えば、Ｅｔｈｅｒｎｅｔ（登録商標）（イーサネット（登録商標））の如くからＵＭＴＳリンク上の特定のベアラへと転送するときなどに利用できる。
【００１３】
図１は、音声、画像、画像操作及び制御信号などが含まれる会話的なマルチメディアアプリケーション用のユーザ端末から又は当該ユーザ端末への例示的なアプリケーションパケットフローを示している。図１が示しているように、アプリケーションの各部は、一以上のパケットフローを生成する。各パケットフローはベアラ（トランスポート）の特性に関連した自身の要求条件を備えている。
【００１４】
図１Ｂは、Ｅｔｈｅｒｎｅｔ（登録商標）インタフェース又はＵＭＴＳインタフェースに対し、サービス・アクセス・ポイント（ＳＡＰ）を経由してアプリケーションフローがどのようにマッピングされるかを示している。なお、ＵＭＴＳインタフェースには１以上の『ベアラ』が存在し、各ベアラ１３及び１５によって提供されるサービス品質ＱｏＳはそれぞれ異なる場合がある。その結果、アプリケーションパケットフローのマッピングを決定するときに、インタフェースを選択したのでは不十分である。また、パケットフローのマッピングを作成するための適当なプロセスにおいて、個々のベアラが考慮されなければならない。まとめると、いくつかのアクセス技術がそれぞれサービス品質が異なるレベルでもって、いくつかのベアラ（トランスポート）サービスをサポートしているが、他のアクセス技術はただ一つのベアラサービスをサポートしている。よって、一般的な解決手法は、ベアラを考慮することが必要である。一方で、例えば、図１Ｂに示したＥｔｈｅｒｎｅｔ（登録商標）のベアラ１１のようなベアラの数とインタフェースとの間に一対一の関係がある状況は特別の場合である。
【００１５】
上述したように、アクセステクノロジーが異なれば利点も異なる。典型的な利点のトレードオフの状況は、ＷＬＡＮのような高いスループット技術とセルラーアクセスのようなより低いスループット技術における広域カバレッジとによって例証することができる。
【００１６】
アプリケーションフローごとを基礎として、ＳＩＭＡＣは、任意の時間においてアクセスベアラが適用可能であれば、利用可能なトランスポートやアクセス上に、上りリンクのフローと下りリンクのフローとをマッピングする。例えば、アプリケーションフローをアクセスベアラ上にマッピングする方法を変更したり、ベアラの設定を変更したりすることによって、ＳＩＭＡＣは、動的に（アクセス）トランスポート能力における変更に適応させることができる。
【００１７】
いくつかの実施形態では、ＳＩＭＡＣがアプリケーションの適合処理をサポートすることができる。これは、第１にアプリケーションに対して、例えば次回又は既に実装されているものなど、提供されているトランスポートサービスの変更を通知すること、あるいは符号変換器のようなメディア最適化機能を自動的に呼び出すことによってサポートされる。
【００１８】
いくつかの実施形態では、利用可能なベアラをどのように利用しどのように設定するか、及びアプリケーションからのフローをどのように設定するかを考慮してアプリケーションの要求を黙示的に導出するためのサポートが含まれている。これは、多重アクセスの状況によって与えられた能力をさらに効果的に利用できるようにするためである。そのような解決手法は、例えば、アプリケーションが明示的な相互動作をせず、かつＳＩＭＡＣ機能を有していない場合に適用可能である。ユーザが設定データを通じて自己の嗜好を提示してもよいという可能性はまだ存在する。
【００１９】
様々なＳＩＭＡＣの実施形態では以下の例示的な機能が含まれうる：ユーザ情報に利用可能な（アクセス）トランスポート能力についての情報収集（これには将来状況の予測が含まれてもよい）；アプリケーション要求についての情報収集（これにはサービスプロバイダにより設定されたユーザの嗜好情報やポリシー（料金など）が含まれてもよい）；ベアラ上へのトラヒックフローの好ましいマッピングの選択と、任意の時間において利用可能な能力によって定まる好ましい動作条件を満たすトランスポートベアラの設定の選択（好ましい設定を選択する際にはいくつかの実施形態において最適化機能が考慮される）；上りリンクと下りリンクにおけるユーザプレーンのルーティングメカニズムの設定；ベアラ構成；最適化機能；いくつかケースでは、上りリンクと下りリンク用のＩＰトンネルにおけるトラヒックフローのカプセル化。
【００２０】
いくつかのＩＰトンネリングの実施形態では、ＩＰアドレスが各々のアクセスタイプに関係しており、またいくつかのケースでは、ＩＰアドレスが、例えばＵＭＴＳなど、アクセスタイプ内の各ベアラに関係している。トンネル技術を使用することで、通信相手のアプリケーション、ピア及びサーバからアプリケーションを隠すことができる。例えば、モバイルＩＰなど利用可能な技術においてトンネル化による解決手法が使用される。ＳＩＭＡＣによる解決手法の説明では、トンネルがインタフェースだけに関係付けられているというよりは、むしろインタフェース（アクセス）上の個々のベアラに関係付けられているといえる。ＳＩＭＡＣの説明でも、トンネルはＩＰタイプだけではなく、他のタイプであってもよい。
【００２１】
解決すべき基本的な問題の一つは、２つのユーザ端末間に存在するホップを横切る少なくとも２つの選択肢（パス）存在することである。見込みがありそうなシナリオは、ホップが、例えばユーザ端末装置から第１のルーターへの第１のアクセスリンクである場合である。いずれかの実施形態において、選択候補となる各パス上の異なる複数のベアラ上へのフローのマッピングを管理する機能が、マルチパスリンクの両サイドに存在しなければならない。この機能をここでは転送エンジンと呼ぶことにする。さらに、（ホップあるいはリンクの両サイドにそれぞれ一つづつ存在する）２つの転送エンジンを管理するための制御装置が必要となる。転送エンジン及びその関連制御ロジックについては、いくつかの実施形態の候補が存在する。
【００２２】
いくつかの例示的なＳＩＭＡＣの実施形態は、２つのユーザプレーンの転送機能を実装しており、これによりＩＰパケットを異なるベアラにマッピングすることができる。転送機能は、（複数の代替的なパスが存在する）リンクの両サイドに提供される。転送機能の実現方法については、いくつかの利用可能な選択肢が存在する。いくつかの実施形態では、例えばユーザ通信端末装置などのアプリケーションのホストとして動作するエンドシステム内に転送機能が統合されてもよいし、あるいはこれらを複数のエンドシステム間において提供される複数のスタンドアローンのエンティティに分割して実装してもよい。図３は複合的な例を示しており、転送エンジンの１つがユーザ通信端末３１に統合されており、一方で他の転送エンジンはスタンドアローンのエンティティ（この説明ではＳＩＭＡＣプロキシー３２）の中に存在している。
【００２３】
制御ロジックには、中央知能部（ここではリンクマネージャーと呼ぶ）が含まれている。例示的なリンクマネージャー機能は、パケットを異なるベアラ上で転送する転送エンジンにしたがってテーブルを構築する。例えば、特定のアプリケーションフローをどのようにしてベアラ上にマッピングするかについての情報が転送エンジンに提供される。ここでは、『ルーティングテーブル』又は『転送テーブル』と呼ばれるテーブルにこの情報が記憶されるものとする。リンクマネージャーは、異なるアプリケーションフローをどのようにしてベアラ上にマッピングするかの情報と、どのようにしてベアラを設定するかの情報と、ベアラ上の負荷についての情報とを保持する。前述の情報はリンクマネージャーによってフローマッピングテーブルの中へと収集される。また、リンクマネージャーは、アプリケーションへと提供可能なサービスの変更についてどのようにしてアプリケーションに通知すべきかおよび変更が通知されるべきか否かのデータトラックを保持する。これらの変更は、例えば、リンクのロスや、あるリンク上の特定のベアラにおいて発生したサービスの劣化によるものである。フローマッピングテーブルの構築において、リンクマネージャーは例えば次の情報を使用できる。
ａ） リンクの利用可能性、リンク上でのベアラの利用可能性、リンク上でのベアラの能力及びリンク上でのベアラの特性；
ｂ） ＳＩＭＡＣ機能がどのように動作すべきかに関してのユーザあるいはサービスプロバイダのような外部団体の嗜好；
ｃ） アプリケーションの要求事項とＳＩＭＡＣ動作に関するアプリケーションの特定の嗜好。嗜好はデリミタとデフォルト設定とみなすことができる。これらはアプリケーション初期化処理の際に提供されたものであってもよい。嗜好によって提供された情報を補って完全にするかあるいは当該情報を無効し、アプリケーションがＳＩＭＡＣサービスについて即席の要求事項を提供してもよい。
【００２４】
リンクマネージャーに関する他の例示的な機能はリンクレイヤー機能及びＩＰレイヤー機能の設定を管理することである。
【００２５】
いくつかの実施形態では、転送機能（例えば転送エンジンなど）は、スタンドアローンプロキシーやＳＩＭＡＣプロキシー（制御プロトコルを経由してリンクマネージャーによって構成される）で実行される。転送エンジンを伴うそのようなスタンドアローンプロキシーは、（マルチパスホップの両サイドであれば）ネットワークの所望の位置に配置することができる。
【００２６】
図２は、本発明の例示的な実施形態を示している。いくつかの実施形態では、２つのスタンドアローンの転送プロキシー２１及び２２が含まれており、これは１組のエンドシステム間にあるマルチパスリンクのいずれかのサイドに位置する。例えば、第１及び第２のユーザの通信端末装置は、図１で例示されたタイプの対話的なマルチメディア通信に従事している。他の実施形態において、転送プロキシー２１は、アプリケーションを実行するユーザ装置に接続されたり（すなわち図２のエンドシステム）、ユーザ装置内に統合されたり、あるいはユーザとユーザ装置とによって実行されるもう１つの物理デバイスに提供したりすることができる。
【００２７】
図３は、本発明の例示的な実施形態であって、転送プロキシーの１つであるスタンドアローン型のプロキシー３２がネットワーク内のＳＩＭＡＣプロキシーとして提供され、他の転送機能はユーザ装置デバイス３１内のリンクマネージャーに統合されていることを示している。プロキシー３２は、ユーザ装置３１から受信した情報に基づいて、下りリンクのトラヒックをユーザ装置へとルーティングする。一つの転送プロキシーがユーザ装置に接続又は統合されている実施形態におけるＳＩＭＡＣ機能の管理は、双方の転送プロキシーが固定されたスタンドアローン型のネットワークプロキシーである実施形態よりも複雑なものになる可能性がある。なぜなら、接続又は統合されたユーザアプリケーションから利用可能なトランスポート能力は、ユーザ装置が移動するときなどに変化してしまうからである。一方、ネットワークにおいて固定されたプロキシー内に双方の転送機能が提供されているときは、利用可能なトランスポート能力は本質的に変化しない。したがって、固定されているプロキシーに関連したＳＩＭＡＣの管理処理又は選択処理は、前述の接続／統合の実施形態と関連したＳＩＭＡＣのサブセットを代表するものであると理解できよう。
【００２８】
図３の例示的な通信端末３１には、ＵＭＴＳインタフェースとブルートースインターフェイスとが含まれている。通信端末３１は、同時並行的に両方のインタフェースを使用でき、例えば、セッションごとを基礎として、プロキシー３２を介してピアとなるデバイス３３及びコンテンツサーバ３４と通信する。通信端末（ユーザ装置）３１の例としては、携帯電話のような移動通信端末が含まれる。
【００２９】
図４は、図３の通信端末３１に関する例示的な実施形態の中心部を示している。アプリケーションを実行しているユーザ装置に接続又は統合されているＳＩＭＡＣに関連する機能は、ＳＩＭＡＣモジュール４１として示されている。制御信号のシグナリング（信号伝達）のためにＳＩＭＡＣモジュール４１は複数のアプリケーションモジュールと接続されており、同様に制御信号のシグナリングのために複数のネットワークインタフェース４２、４３及び４４と接続されている。また、ＳＩＭＡＣモジュールは、ネットワークインタフェースを経由してトランスポートレイヤー上の機能及びネットワークレイヤー上の機能に接続されている。また、ＳＩＭＡＣモジュール４１は、アプリケーションとネットワークインタフェース４２−４４間のデータ通信パス構造４５（別名「ユーザプレーン」）に含まれている。
【００３０】
図５は、図４のＳＩＭＡＣモジュールについての例示的な実施形態を示している。図５で、ＳＩＭＡＣモジュールには、リンクマネージャー５２、リンクアダプタ５３及び第４レイヤー（Ｌ４）転送エンジン５４が含まれている。リンクマネージャー５２には、設定部５１、制御部５６及びＳＩＭＡＣプロキシー制御部５８が含まれている。いくつかの例示的な実施形態では、ＳＩＭＡＣモジュールは、アプリケーション相互動作部５５（これはリンクマネージャー５２の一部として記載されている）、すなわちソケット上でアプリケーションを分割したり多重化したりなど、再構成によるアプリケーションフロー構造の最適化などの少なくとも一つの機能をさらに含んでいてもよい。リンクマネージャー５２はアプリケーションプロキシー５７を制御する。
【００３１】
上りリンクで通信中のとき、転送エンジン５４は（ＩＰスタックの協力により）カーネル内の出力対象ＩＰパケットを捕捉し、転送ルールを使用して、パケットフローを適切なネットワークインタフェースや、図５に示した関連ＳＡＰを経由して適切なネットワークインタフェースのベアラ上にマッピングする。
【００３２】
とりわけ、各パケットフローはトランスポートチャネル上にマッピングされる。このトランスポートチャネルは、特定のネットワークインタフェース（リンク）上の特定のベアラを介した特定のパスを抽象化したものである。トランスポートチャネルは異なるタイプであってもよく、ソケットからのＩＣパケットが、関連するベアラ上で内容を変更されることなく送信されるケース「未加工（ｒａｗ）」、あるいは、ＩＰｉｎＵＰやＩＰｉｎＵＤＰの如く、ソケットからのＩＰパケットが状況に応じて適切なＩＰのトランスポートプロトコル内にカプセル化される「トンネル化」などであってもよい。トランスポートチャネル上へのフローのマッピングや、ベアラへのトランスポートチャネルの関連付けはリンクマネージャーによって管理される。
【００３３】
転送エンジン５４は、例えば、ルーティングテーブルにしたがってパケットを適切なトランスポートチャネルへと転送する。ルーティングテーブルの内容は、リンクマネージャー５２によって定義されそして提供される。転送処理は、ＩＰ（トランスポートレイヤー及びネットワークレイヤー）のヘッダ内の情報に基づいて実行できる。例えば、フローＩＤ、ＩＰの宛先アドレス及び送信元アドレス、ＩＰＳｅｃ、ＳＰＩなどである。このプロセスはしばしば『フロー分類処理』と呼ばれる。いくつかの実施形態で、上りリンクにおいてＩＰトンネル化ヘッダを付加して、トランスポートチャネルにトンネルを作成するためのＩＰトンネル化技術を転送エンジンが実装している（対称的に、マルチパスリンクのリモート側の転送エンジンは、下りリンクにおいてトランスポートチャネルをトンネル化するために同様の処理を実行する。）ＩＰトンネリングを実施している下りリンクにおいて、転送エンジン５４は、ＳＩＭＡＣプロキシーによって付加されたトンネル化のためのＩＰヘッダを除去する（図３参照のこと）。
【００３４】
リンクマネージャー５２はフローマッピングの決定を実行する。すなわち、特定のアプリケーションフローのために、どのトランスポートチャネル及び関連（アクセス）ベアラを使用するかを決定する。リンクマネージャーは、例えばリンクアダプタ５３からの受信された情報や、アクセス技術において期待されている動作についての本質的な情報知識に基づいてフローマッピングの決定を実行する。リンクアダプタ５３は、異なる複数のリンクレイヤーデバイスに向けた一般のインタフェースである、例えば、ネットワークインタフェースを提供する。また、様々なアクセス（例えばＵＭＴＳやブルートースなど）上のベアラの利用可能性や能力についての情報をリンクマネージャーに提供するための実際のインタフェースを抽出する。リンクマネージャー５２は、一時的に利用可能なアクセス、関連ベアラのトランスポート能力、及び特性の設定情報の情報知識を保持する。すなわち、どのアクセスとどのベアラが任意のすべての瞬間において利用可能かの情報である。また、リンクマネージャーは、上りリンクのトラヒック及び下りリンクトラヒックの少なくとも一方において、利用可能なアクセスベアラがどのように使用されるべきかを決定する。また、リンクマネージャーは、どのようなタイプのトランスポートチャネルが特定のベアラに使用可能かを決定する。トランスポートチャネル上にアプリケーションフローをどのようにマッピングするか、またベアラ上にトランスポートチャネルをどのようにマッピングするかを決定する処理において、リンクマネージャー５２は、リンクアダプタ５３を経由して、ネットワークインタフェースの適切な構成を起動できる。もしアクセス技術に適用可能であるならば、これはネットワークインタフェースの「インタフェースコントローラ（ＩＣ）」ＡＰＩと相互動作を行なう。リンクマネージャー５２は、トランスポート機能とネットワーク機能の設定処理を開始し、もし適用対象であるなら、例えば、モバイルＩＰのシグナリング処理、図５のＳＩＭＡＣプロキシー制御部５８を使用した図３のＳＩＭＡＣプロキシー３２の設定処理を実行する。
【００３５】
いくつかの実施形態で、リンクマネージャー５２が三角（非対称）型ルーティングを使用することを決定してもよい。これは、同一のアプリケーションフローからの上りリンクパケットと下りリンクパケット（同一のフロー識別情報を有する）が、異なるトランスポートチャネルを通じて転送されることを意味する。またいくつかの実施形態で、少なくとも一部で、例えば、コストの最小化やセキュアなアクセスなど、ユーザや外部団体の嗜好を示す情報を基礎として、リンクマネージャー５２のルーティング・マッピングの決定を実行してもよい。そのような嗜好の情報は、図５の設定部５１における設定情報を経由して供給することができる。また設定部５１は、設定ファイルを記憶する記憶装置を備えることができる。この設定ファイルには、ユーザの嗜好若しくはポリシー、及び外部団体の嗜好若しくはポリシーの少なくとも一方を示す情報が含まれている。
【００３６】
いくつかの実施形態で、リンクマネージャー５２は、暗黙のうちにフロー要求を導出するロジックと、トランスポートチャネル、トランスポートチャネルのタイプ、適切な（アクセス）ベアラ、及びベアラ設定にフローを適切にマッピングするロジックを備えてもよい。いくつかの実施形態で、リンクマネージャー５２は、アプリケーションフローの構造の再設定が有益であるかを決定してもよい。また、図５のアプリケーションプロキシー５７と協働してそのような動作を実行することが有益であるかどうかを決定してもよい。他の実施形態で、リンクマネージャー５２は、トランスポート（アクセス）能力及び特性の少なくとも一方の変化を予測するロジック、及びそのようなイベントを用意するロジックを備えてもよい。リンクマネージャー５２は、例えば、ユーザ装置が広域無線トランスポート技術（例：ＨｉｐｅｒＬＡＮ２）のセル境界に近づきつつあるという情報を、ネットワークインタフェース及びリンクアダプタの少なくとも一方から取得して使用してもよい。この情報は、例えば、当該アクセスが間もなく失われることを意味していたりする。リンクマネージャー５２は、結果的に、トラヒックを引き継ぐために、他のアクセステクノロジー、例えば、ＵＭＴＳアクセス上の適当なベアラなどを手配することができ、選択されたＵＭＴＳのベアラの設定とともにトランスポートチャネルと第４レイヤー転送エンジン５４のルーティングテーブルを適宜に修正することができる。
【００３７】
いくつかの例示的な実施形態には、リンクマネージャー５２の一部である前述のアプリケーション相互動作部５５が含まれ、これにより多重アクセス環境に適合したアプリケーションとの事細かな相互動作のための機能が提供される。アプリケーション相互動作部５５は、この相互動作のためのＡＰＩをサポートする。例えば、リンクのロスなどの結果として生じる提供されたトランスポートサービスの変化についてのフィードバックをアプリケーションに対して提供することができ、これによりアプリケーションを状況に適合させることができる。また、アプリケーション相互動作部５５のＡＰＩは、トランスポートのための要求、利用可能な（アクセス）ベアラのトランスポート能力及び特性の少なくとも一方についての情報の要求、プロキシー最適化処理の呼び出し、ユーザ嗜好の提示をサポートすることができる。アプリケーションは、アプリケーション相互動作部５５から、要求に対する結果の情報や、利用可能な（アクセス）ベアラのトランスポート能力及び特性などの変化のような情報を取得する。
【００３８】
リンクマネージャー５２と相互動作するためにアプリケーションによって実行されるＡＰＩは、様々な手法で実装することができる。図５に示されたいくつかの実施形態で、（５０の）標準となっているソケットメソッドのいくつかを再利用する。それと並行して（５９の）別々のインタフェースを使用してＡＰＩを部分的に実装する。５０において使用されるソケットは、例えば、ＩＮＥＴタイプであってもよいし、あるいはＷＩＮＳＯＣＫ２標準に準拠したものでもよい。
【００３９】
図６は、図３のＳＩＭＡＣプロキシーについての例示的な実施形態を示している。図６で、ＳＩＭＡＣプロキシーには、図５の第４レイヤー転送エンジン５４と一般的に類似した第４レイヤー転送エンジン６１が含まれている。転送エンジン６１は、例えば図５のリンクマネージャー５２によって定義された転送テーブルに従って、適切なトランスポートチャネルに、上りリンクトラヒック及び下りリンクトラヒックをマッピングする。ＳＩＭＡＣ動作は図３のピアデバイス３３（又はサーバ３４）に対してトランスペアレントになるように、転送エンジンが下りリンクフローをマッピングすることができる。また、ＳＩＭＡＣプロキシーは、プロキシー制御終端部６２を含み、例えば、これにより図５のＳＩＭＡＣプロキシー制御部５８を使用している図３の端末３１から制御情報を受信する。例えば、プロキシー制御終端部６２は、図５のＳＩＭＡＣプロキシー制御部５８から受信した情報に応じて、第４レイヤー転送エンジン６１の転送テーブルを適切に設定することができる。そのような変化は、例えば、特定のアプリケーションフローで使用されるトランスポートチャネルに関連していたり、トランスポートチャネルの設定や、トランスポートチャネルがどのベアラに関与しているかに関連していてもよい。プロキシー制御終端部６２は、いくつかの実施形態において、フィードバック情報を端末３１に提供することができる。
【００４０】
ＩＰトンネル化を利用する実施形態において、第４レイヤー転送エンジン６１は、端末３１の方への下りリンクにおいて適切なトンネル化ＩＰヘッダーを付加することができる。
【００４１】
図３のユーザ端末３１は、従来の方法を利用して、ネットワーク内で利用可能なＳＩＭＡＣプロキシーを識別することができる。従来の方法としては、例えば、設定ファイルから情報を読み出したり、サービス要求を放送してそれに対する応答の情報を受信したり、あるいは要求に対するそのような情報を提供するネットワーク内のエンティティに対して問い合わせたりなどがある。
【００４２】
図３のユーザ端末３１のリンクマネージャー５２は、図３の３６として図示されているリンクを介してプロキシー制御プロトコルを使用し、ＳＩＭＡＣプロキシー３２の転送エンジン６１を設定することができる。リンク３６は、例えば、セルラーリンクであってもよい。プロキシー制御プロトコルによって、リンクマネージャー５２は、第４レイヤー転送エンジン６１が所望のルーティング動作を実行するように設定することが可能となる。例えば、図５の転送エンジン５４と同様に、アプリケーションフローをトランスポートチャネルに対してどのようにマッピングするかを設定できる。これには、どのトランスポートチャネルをフロー用に採用するか、トランスポートチャネルのタイプ（ＩＰトンネル化するか又はしないか）、トランスポートチャネルとリンクレイヤーベアラとの関係を示しているデフォルトのルーティングテーブルの設定を含めることができる。また、リンクマネージャー５２は、リンク接続の失敗時にとるべき他の動作に関する指令をＳＩＭＡＣプロキシー３２に提供することができる。
【００４３】
トランスポート能力及び特性の少なくとも一方における変化は、常に、アプリケーションやそのユーザに隠すことができないし、また隠すべきではない。例えば、もしアプリケーションが、利用可能なトランスポートチャネルによりサポート可能な程度を超えた大きな帯域幅を消費するメディアストリーム（ビデオストリームなど）を有しているときは、アプリケーションはこのような状況を管理することを希望するかもしれない。例示的なアプローチとしては、他のアプリケーションフローを維持しつつ、アプリケーションのセッション全体をドロップさせたり、もしくはメディアストリームだけをドロップさせたり、あるいは「信号ロスト」などのエラーメッセージを表示させながら画像を制止させたりすることがあろう。他のアプローチとしては、セッションのフォーマットを変更することであり、例えば、ビデオサンプルの符号化を、利用可能なトランスポート（ベアラ）の特性又は能力に相応しい他のフォーマット（例えばより狭い帯域で済むフォーマット）へと変更してもよい。例えば、メディアを異なるトランスポート能力に適合させるための利用可能な方式はいくつかあり、「興味のあるスポット（Spot of Interest）」技術のようなＭＰＥＧ７技術や、圧縮の呼び出しや、ストリーミング映像の多層符号化などがある。これらの如くの機能はアプリケーションの中で実行できるが、例えば、ネットワーク内の符号変換プロキシーなど、ネットワークプロキシーのようなプロキシー内に配置してもよい。そのような性能拡張機能は、上りリンク及び下りリンクの双方に提供することができる。いくつかの実施形態において、そのような機能は、図５に示したユーザ装置内のアプリケーションプロキシー部５７内に配置してもよいし、図７に示したプロキシー部７１に配していもよい。最適化処理は必然的に対称的なわけではない。
【００４４】
いくつかの実施形態において上述したように、ＳＩＭＡＣモジュール４１は、トランスポート能力又は特性、相互動作ＡＰＩを経由してアプリケーションにより要求された情報をアプリケーションに対して通知することができる。ＳＩＭＡＣモジュールは、同様にリンク、ベアラ、及び利用についての自動的な再設定を実行していてもよい。そのような実施形態において、ＳＩＭＡＣモジュールはアプリケーションを新しい状況に適合させるために機能する。アプリケーションに利用可能ないくつかの例示的な代替案において、ピアとなるエンティティ（図３の３３及び３４を参照のこと）に対して変化についてのネゴシエーション処理、あるいは符号変換プロキシーや他の何れかの適切な性能拡張プロキシーの呼び出し処理が含まれる。
【００４５】
他の実施形態において、ＳＩＭＡＣモジュール４１は自分自身で、トランスポートベアラの特性及び能力の少なくとも一方、及びトランスポートベアラの利用方式における変更に基づいて、下りリンク及び上りリンクの最適化機能（すなわちプロキシー）の呼出処理を開始することができる。そのような実施形態において、図５の設定部５１には、与えられた条件下でどのプロキシー又はどのプロキシーサービスが呼び出されるべきかを示している情報が含まれてもよい。いくつかの実施形態において、当該情報は、設定ファイル又はアプリケーションの方へのＡＰＩを介して提供される。条件の一例としては、映像を搬送しているパケットアプリケーションフローが、ポリシーにしたがってＨｉｐｅｒＬＡＮ２のトランスポートからセルラーのベアラへと移動しているときであろう。そのような条件が満たされているときに、リンクマネージャー５２は、ＳＩＭＡＣプロキシーに通知するためにＳＩＭＡＣプロキシー制御部５８を使用することができ、それにより、影響を受けたネットワークの最適化（例えば圧縮もしくは符号変換）プロキシーに対して通知がなされる。並行して、リンクマネージャー５２は、図５のアプリケーション部５７内の最適化機能を呼び出すことができる。最適化機能プロキシーとしては、例えば符号変換などの最適化機能を適用することができ、それによって、ストリーミングされているビデオアプリケーションフローをセルラーベアラの能力及び特性へと適合させることができる。
【００４６】
図７は、本発明の例示的な実施形態であって、ユーザ端末のＳＩＭＡＣモジュールがＳＩＭＡＣプロキシー３２を経由してＳＩＭＡＣプロキシー制御部５８を使用し最適化機能プロキシー７１を呼び出すことができ、そしてアプリケーション７５に通知することを示している。図７Ａは、ＳＩＭＡＣモジュールが最適化機能を呼び出すために使用できる例示的な通信プロトコルを示している。
【００４７】
図７Ａに示された通信プロトコルによって、ＳＩＭＡＣプロキシー３２は、「イベント」をプロキシー７１に通知するためのメッセージをプロキシー７１へと送信する。ＳＩＭＡＣプロキシー３２からプロキシー７１へのメッセージは「ペイロード」に追加される。このペイロードには、通信アプリケーション７５からプロキシー７１への情報が含まれており、例えば、映像にどの符号化技術が適用されているかや、予め同意された特定のプロキシー設定についてのリファレンスや、又はプロキシー７１に特定の動作を実行させるような他の何れかの情報などがある。ＳＩＭＡＣプロキシー３２は、プロキシー７１へと転送されるペイロード情報について何も知る必要がない。いくつかかの実施形態において、ＳＩＭＡＣプロキシー３２からプロキシー７１への前述のメッセージは「イベント判定基準」が満たされたときに送信可能である。前述したように、１つの例示的なイベント判定基準は、ストリーミングメディアを搬送しているパケットアプリケーションフローがＨｉｐｅｒＬＡＮ２のトランスポートからセルラーのトランスポートに移動しているときであろう。図７の破線部はイベント情報のフローを表している。
【００４８】
さらに他の例示的な実施形態は、利用可能なアクセス又はトランスポートベアラ、とりわけ多重アクセス状況に対応して設計されていないアプリケーションの効率的な使用をもたらす他のタイプの「プロキシー」を使用するものである。効率的に利用するには、アプリケーションフローが識別可能であること、並びに適切なフローのマッピングと適切な最適化機能及びアクセス（トランスポート）ベアラの設定を実現するために必要となる情報をＳＩＭＡＣモジュールが有していることを必要とする。利用可能なトランスポートベアラを効率的に使用するためには、アプリケーション・メディアのストリーム（図１のメディア及び制御）がＩＰトランスポートと、（多重）アクセスを考慮したネットワークレベルのフローの観点から設定されるべきである。もしトランスポート能力と特性に関して様々な要件を伴うアプリケーションフローが同一のトランスポートでかつ同一ネットワークレベルのフローに配置された場合は、ＳＩＭＡＣはそれらを相互に分離することができないかもしれない。もし、例えばＩＰアドレスとポート（ペア）によって識別可能なＩＰトランスポート及びＩＰネットワークの観点から、アプリケーションが、同一のアプリケーションフロー内にストリーミングオーディオのサンプル及びストリーミング映像のサンプルを配置してしまっている場合は、ＳＩＭＡＣモジュールが２つのフロー成分を区別することはできないだろう。
【００４９】
そのような状況において理想的には、アプリケーションがＡＰＩを使用して２つのメディアストリーミング間の区別をＳＩＭＡＣモジュールに通知すべきであり、そしてこれらに２つの異なるＩＰトランスポート及びネットワークフローをマッピングすべきである。しかしながら、もしこれが発生しない場合、例えば、多重アクセス用に設計されていない従来アプリケーションの場合は暗黙の内に区別を認識できよう。アプリケーションプロキシーはこの目的のために提供される（図５の部５７を参照のこと）。アプリケーションプロキシーが、ＳＩＭＡＣモジュールと明示的に相互動作できないか又は相互動作しないアプリケーションからのアプリケーションデータを解析することができ、そしてＳＩＭＡＣモジュールから適切なサービスを要求することができる。アプリケーションプロキシーは、アプリケーションプロトコルを終端することができるか、または内容を把握することができ、これにより必要とされている区別の情報を取得できる。これによって、ＩＰトランスポートとネットワークフローの中にアプリケーションデータ（メディア及び制御）を再配置することが可能となるが、しかしながら区別情報を導出する目的が提供されてもよい。いくつかの実施形態では、導出プロシージャをサポートするために、嗜好を示すプロファイルがアプリケーションプロキシーに提供可能である。
【００５０】
図８は、アプリケーションプロキシーを利用する例示的な実施形態を示している。図８の例において、（多重アクセスに適合していない）従来のブラウザクライアントからの上りリンクのＨＴＴＰトラヒックは、ＨＴＴＰプロキシー８１を通過する。ＨＴＴＰプロキシー８１は、トラフィックを解析し、例えば、プロファイル情報を使用して区別のための情報を導出する。プロファイル情報は、どのようにしてＩＰトランスポートパスの中へとアプリケーショントラフィックをマッピングするかを示している。いくつかの実施形態において、プロキシー８１は圧縮処理のような最適化機能を備えてもよい。
【００５１】
ＳＩＭＡＣモジュールを使用する一例において、ＳＩＭＡＣが初めて始動されるときに、デフォルトのユーザーポリシーがロードされる。いくつかの実施形態において、当該ポリシーは、ユーザの嗜好、及びサービスプロバイダや行政体などの外部団体の嗜好を含んでいる。（ユーザの通信端末装置内の）ＳＩＭＡＣモジュールは、例えば、上述した従来の技術を使用してネットワークにおいて利用可能なＳＩＭＡＣプロキシーを探索する。リンクが入線したり出線したり、リンク上の各ベアラの能力及び特性の少なくとも一方が変化したりするにつれて、リンクマネージャーは利用可能なトランスポートベアラの能力と特性についての情報を更新し、トランスポートチャネル上へのアプリケーションフローのマッピング、トンネルの設定、ＩＰトランスポートレベルのベアラ（図１１及び図１２を参照のこと）、及びリンクレイヤーのベアラ（図１７を参照のこと）に適切な変更を加える。リンクマネージャーは同様に適切なルーティング規則を用いてユーザ端末内の第４レイヤー転送エンジンを更新する。また、リンクマネージャーは、例えば、到着するアプリケーションフローなどの到着トラヒックをどのようにして制御するかを表すルーティング規則などを用いてＳＩＭＡＣプロキシー内の第４レイヤーの転送エンジンを更新する。例えば、５０６０番のポートを使用しているユーザ端末に対してアドレス付けされた全てのＳＩＰパケットフローは、ＵＭＴＳインターフェイスベアラと関係付けられたトランスポートチャネル上にマッピングすることができる。また、リンクマネージャーはＳＩＭＡＣプロキシー内の第４レイヤー転送エンジンに対し、キューイング（パケットのスケジューリング）に関する指令を供給することができる。このキューイングは、いくつかのアプリケーションフローが同一のトランスポートチャネル上にマッピングされているような状態において使用できるもので、それによりいくつかのアプリケーションフローはより高い優先順位を得ることになるだろう。
【００５２】
ユーザはパケットアプリケーションフローのトランスポートベアラ上への再マッピングについての実際の処理に参加しなくてもよい。この処理は、自動的にＳＩＭＡＣモジュール機能（図４のＳＩＭＡＣモジュール４１及び図３のＳＩＭＡＣプロキシー３２）によって実行可能である。この処理には、利用可能なＩＰレイヤーのベアラ及びリンクレイヤーのベアラにおける必要な変化の管理処理も含まれている。
【００５３】
いくつかの実施形態において、利用可能なアクセスを示す情報とともに、ＳＩＭＡＣが動作中であることを示しているアイコンをＧＵＩ上に表示可能である。例えば、ＬＥＤの列を用いて示すことができる。ユーザは、例えば、（アプリケーションごとの）好ましいアクセス、料金及びアプリケーションのパフォーマンス間でどちらをどのように優先させるかの如くの嗜好を用いて、ＳＩＭＡＣモジュールを設定してもよい。
【００５４】
ユーザの通信端末装置がユーザとともに移動するにつれて、利用可能な（アクセス）トランスポートのベアラ能力及び特性の少なくとも一方が変化するかもしれない（もちろんそのような変化には図２３に示されるように他の理由が存在する）。いくつかの実施形態において、そのような変化についての情報（もし適用可能であれば、例えばリンクやトランスポートベアラにおける可能な再構成など）は、ＧＵＩを通してユーザに表示することができる。
【００５５】
図９は、アプリケーションからのトランスポートが従来のＩＰを基盤とするシステムにおいてどのように実行されるかを例示している。アプリケーションは送信対象のデータを保持しており、この送信のためにポートによって識別可能なソケットを生成する。ソケットは、ストリーム（ＴＣＰ）又はデータグラム（ＵＤＰ）のような異なるタイプのものとすることができる。ソケットは、特定の送信元ＩＰアドレスと関係付けられており、また、いわゆるデバイスドライバを経由して物理リンクインタフェースへと関係付けられている。アプリケーションはトランスポート（すなわち、送信先のＩＰアドレスを示しているアプリケーションデータの送信）を要求する。アプリケーションデータは、ソケットタイプに関係した（ＴＣＰのような）トランスポートレベルでのメカニズムによって処理される。データはＩＰモジュールに転送される。ＩＰモジュールは基本的にルーティングテーブルを使用する。ルーティングテーブルは、問題のパケットを送信する際にどの出力リンクインタフェースを使用すべきかを示している（パケット単位を基礎として却下するデフォルト設定が存在する）。実際の送信は（物理インタフェースの論理的な表現とみなすことのできる）デバイスドライバによって実行される。
【００５６】
インタフェース又はインタフェース上のベアラを選択する際に区別を必要としない場合では、歴史的に多くのリンクレイヤー技術は１種類のベアラだけを有していた。しかしながら、他のリンクレイヤー技術では１つのインタフェースにつき、いわゆるサービス・アクセス・ポイント（ＳＡＰ）を経由してアクセスされるいくつかのベアラを有している。例えば、ＵＭＴＳのアクセスは、１以上のベアラを提供することができる。これらのベアラは能力及び特性の少なくとも一つの観点において異なっており、それゆえ要求条件の任意の組を用い、これらの要求条件に沿う適切なベアラにアプリケーションフローをマッピングすることが望ましい。
【００５７】
特定のベアラにアプリケーションフローパケットを割り当てるための機能は、様々な個所に配置させることができる。例えば、ＩＰモジュールがインタフェース上の異なるベアラを識別してもよいし、例えばデバイスドライバ内に、それぞれリンクレイヤーのＳＡＰに関連した２つの異なるキューを提供してもよい。そのような１つのキューが図９に例示されている。他の例は、ＩＰモジュールがリンクインタフェース上のベアラのコンセプトを識別できず、デバイスドライバが各パケットフローとリンクレイヤーの各ベアラとについて情報を有している場合である。
【００５８】
本発明は、ＩＰスタック又はドライバーに関連して実現することができる。ＩＰモジュールは、第１の例で概説したように動作し、すなわち、図１８の例示的なＬ４ＦＥの実施形態の如く、同一のリンクレイヤーインタフェース上にある個々のベアラにフローをマッピングすることができる。図１８は、ＩＰモジュールとデバイスドライバがリンクインタフェース上の個々のベアラにパケットを転送することができると仮定した例示的な実施形態を示している。出力されたパケットはＩＰモジュールからＬ４ＦＥ（第４レイヤー転送エンジン）へと転送されるが、ここではパケットがどのフローに属しているかをフロー分類によって識別する。フローを把握するために、トンネルタイプ、インタフェース及びインターフェイスベアラを含め、Ｌ４ＦＥはどのトランスポートチャネルを使用するかを発見する。図１０−１２及び１９は、前述の処理過程で使用される情報を含む例示的なテーブルを示している。いくつかのケースで、オリジナルのＩＰパケットはトンネル化されるが、その際には適切な動作を実行するためにトンネルシンセサイザーが呼び出される。最終的にＬＦ４Ｅは、適切なベアラを使用してＩＰパケットを送信するようＩＰモジュールに要求する。Ｌ４ＦＥのスケジューリングは、例えば、偶然にも同一のトランスポートチャネルにマッピングされた２以上のアプリケーションフロー間について前述の優先順位付けを実行することができる。
【００５９】
もしＩＰモジュールがリンクインタフェース上のベアラを識別しなければ、Ｌ４ＦＥは直接的にデバイスドライバと相互接続しなければならないだろう。さらにもしドライバーが個々のベアラを管理する能力を備えていなければ、図５のリンクアダプタ５３が、同様の機能を含むことができよう。
【００６０】
例えばＩＰモジュールがどのくらい進化しているかに依存して、ＳＩＭＡＣモジュールがユーザプレーンの機能を無効にすることを、上述の例示的な実施形態から読み取れるだろう。
【００６１】
上述したように、図１０−１２及び１９は、本発明に係る第４レイヤー転送エンジン５４（図５参照）及び６１（図６参照）によって使用できる例示的なテーブルを示している。先に検討したように、リンクマネージャー５２は、第４レイヤー転送エンジン５４及び６１内のルーティングテーブルの内容を設定したりメンテナンス（すなわち更新）したりすることができる。図１０に示されているように、テーブルを使用することで異なるパケットフロー内の各パケットを識別することができる。図１０に示されているように、例えば、従来のＩＰネットワークやトランスポートヘッダーにおいて見受けられるような情報の好ましい組み合わせを使用することで、様々なアプリケーションフローの識別情報を決定することができる。
【００６２】
例えば図１０のテーブルを使用して、任意のパケットフローその対応するアプリケーションフローに属することを識別されているときは、図１１のテーブルに関連して使用可能なパケットフロー識別情報を使用して、当該パケットを転送するためのトランスポートチャネルを決定できる。図１１に示したように、任意のパケットは１以上のトランスポートチャネルに関係付けることができる。もし任意のパケットフローが１以上のトランスポートチャネルに関係付けられているとすれば、これらのトランスポートチャネルは望ましい順番で優先順位付けすることができる。例えば、図１１は第１番目に優先される下りリンクトランスポートチャネルと、第２番目に優先される下りリンクトランスポートチャネルを示している。例えば、優先されているトランスポートチャネルのセットにおいて、例えば、チャネルのオーバーロードなどが原因でより高い優先順位のトランスポートチャネルが利用できない場合は、それより低い優先順位のトランスポートチャネルを使用できる。リンクレイヤーのトランスポートベアラが、例えば、オーバーロードのときに、後者のような結果となりうる。トランスポートチャネルは、例えばその中で「未加工（ｒａｗ）」のＩＰベアラ又はトンネルとすることができ、例えば、ユーザアプリケーションのＩＰ ＳＤＵがカプセル化される。例えば、ＩＰ ｉｎ ＩＰやＩＰ ｉｎ ＵＤＰなど、いくつかの例示的なカプセル化技術が利用可能であるが、これに限定されることはない。いつかの実施形態において、トンネルカプセル化処理には、カプセル化ヘッダの圧縮処理及び暗号化処理の少なくとも一方が含まれてもよい。任意のトランスポートチャネルについての上述の例示的な特徴は、図１２の例示的なテーブルとして示されている。
【００６３】
前述したように、アプリケーションフローはトランスポートチャネルに関係付けられており、そしてこれは異なるタイプであってもよい。トランスポートチャネルは、リンクインタフェース内のＳＡＰを経由してアクセスされるリンクレイヤーのトランスポートサービス、ベアラに関係付けられている。いくつかの実施形態では、リンクレイヤーのベアラに関連したデバイスドライバ内の特定のキューを経由して利用可能なものであろう。図１９は、インタフェース及び黙示的にはドライバー内の特定のキューを経由するベアラにトランスポートチャネルを関連付ける例示的なテーブルを示している。
【００６４】
図１０−１２を考慮すると、図１０のテーブルを使用して入力パケットがパケットアプリケーションフローに関係付けられている。パケットフローの識別情報は、図１１のテーブル内で使用され、パケットを転送する際にどのトランスポートチャネルを使用するかを決定できる。選択されたトランスポートチャネルは図１２のテーブルによって特定される。トランスポートチャネルは図１９のテーブルによって例示されるように個々のベアラに関係する。
【００６５】
図１３は、図６の第４レイヤー転送エンジン６１についての例示的な実施形態における適切な部分を示している。図１３において、入力通信リンク１３１から入力してくる入力パケットフロー部１３２に入力される。部分１３２には、（図１０−１２に例示したような）ルーティングテーブルと、入力されてきたパケットが関係しているパケットフローを識別するためのロジック（図１０）と、パケットフロー識別情報を使用して当該パケットに使用するためのトランスポートチャネルを識別するためのロジック（図１１）と、選択されたトランスポートチャネルと関連する適切なリンク１３５へと当該パケットをルーティングするためのロジック（図１２）とが含まれる。トンネル化技術を利用するいくつかの実施形態では、いくつかのトランスポートチャネルがトンネル化機能を指定することができる。そのような実施形態では、トンネルシンセサイザー１３６を提供でき、部分１３２は、トンネルシンセサイザーに対して、関連するトランスポートチャネルがトンネル化機能を指定しているこれらのパケットフローのパケットを転送することができる。そのような実施形態において、トンネル化が適用されているような各パケットがトンネルシンセサイザー１３６から、選択されたトランスポートチャネルに関連したリンク１３５へと導かれ、トンネル化が適用されていないパケットは部分１３２から直接的に適切なリンク１３５へと転送される。リンク１３５の一例としては、ＵＭＴＳ、ブルートース、ＬＡＮ、ＷＬＡＮ、ＧＰＲＳ及びＥｔｈｅｒｎｅｔ（登録商標）がある。
【００６６】
さらに図１３を参照すると、ピアエンティティ（図１３の３３を参照のこと）向けの通信について、第４レイヤー転送エンジン６１は、図１３に関して上述した例示的なルーティング動作を反対の動作を実行する。
【００６７】
（例えば、図４のユーザ端末装置に搭載されているか又は図２に示したようなユーザ端末装置から分離されたＳＩＭＡＣプロキシー内に提供されている図５の第４レイヤー転送エンジン５４などの）ＳＩＭＡＣのルーティング機能は、一般に、図１３に示したような同一の例示的なルーティング動作を実行できる。もちろん、第４レイヤー転送エンジンがユーザ装置に配置されている実施形態においては、入力リンクインタフェースから出力インタフェースへではなく、リンクインタフェースとユーザアプリケーションとの間で通信データがルーティングされる。
例えば、各ユーザ装置がＳＩＭＡＣモジュールを備えているときは、プロキシーを備えていない実施形態が代替的な実施形態となる。同様に、図３のＳＩＭＡＣプロキシー３２は、例えばＵＭＴＳのノードであるＳＧＳＮ及びＧＧＳＮ又は、ルーターによって例示されるようなネットワークレイヤーのエンティティ内で実現されるが、本発明はこれらに限定されることはない。
【００６８】
これまでに言及してきたように、図５のリンクマネージャー５２が第４レイヤー転送エンジンを制御する。リンクマネージャーは、デバイスドライバを経由してパケットをトンネル又は直接的にトランスポートベアラへと転送するために利用される情報を第４レイヤー転送エンジンのルーティングテーブルに供給する。いくつかの例示的な実施形態において、リンクマネージャーは図１７に例示されるように、図５のリンクアダプタ５３を介してリンクレイヤー機能を設定する。いくつかの実施形態において、リンクマネージャーは、図１４の部分１４３及び１４１として例示されたＡＰＩ及び設定データの少なくとも一方を介してアプリケーションと相互に動作する。リンクマネージャーは、リンクアダプタ５３を介してリンクと相互動作し、Ｌ４ＦＥは図１８のＩＰモジュール及びデバイスドライバの少なくとも一方を介してリンクと相互動作することができる。いくつかの例示的な実施形態において、リンクマネージャーは、黙示的にインタフェースや、関連がある場合ではベアラの利用可能性、能力及び特性の少なくとも一つを導出することができる。その結果（必要ならば）、リンクマネージャーは、フローマッピングその他を適合させるためのプロシージャを起動することができる。リンクマネージャーについてのいくつの実施形態には、ＲＳＶＰやモバイルＩＰ（これに限定されることはない）のような、ＩＰトランスポートとネットワークレベルの機能の設定処理が含まれてもよい。これを実行する際には、いくつかの実施形態において図１０−１２及び１９の情報が使用される。また、リンクマネージャーはある種のイベントをアプリケーションに対して通知する責任を負っており、例えば、これにはインタフェースの利用可能性の変化や、ＵＭＴＳベアラなどのトランスポートベアラの能力又は特性における変化などがある。
【００６９】
いくつかの実施形態において、リンクマネージャーはリンクと相互に動作して、リンクや当該リンクの各ベアラを設定する。ある実施形態においては、この相互動作はリンクアダプタを介して実行できるが、他の実施形態においては、リンクマネージャーはリンクインタフェースと直接的に相互動作することができる。リンク又はリンク上のベアラを設定する際には、リンクマネージャーがリンクサービスを取得するために必要となる情報を供給する。リンクレイヤー技術の種類に依存して、必要とされる情報や、相互動作の方法は変わる。ある実施形態では、リンクマネージャーは、例えば、必要とされている帯域幅（図１７を参照のこと）、最小遅延、圧縮がされているか否か、及びその他について情報を供給する。
【００７０】
図２０−２３は、リンクマネージャー５２の例示的な動作について説明したフローチャートであり、図２０ではＳＩＭＡＣの初期化処理が、図２１にはＳＩＭＡＣサービスを用いてアプリケーションの登録処理が、図２２には、アプリケーションサービスの要求処理が、そして図２３には、フローの再マッピング処理がそれぞれ示されている。
【００７１】
図１４は、本発明によるリンクマネージャーの例示的な実施形態に係る適切な部を示している。図１４の配置では、出力インタフェース（もし適用可能ならリンク上の適切なベアラ）に各アプリケーションフロー（例えば、図１３のリンク１３１において受信された入力パケットや図１８のＩＰモジュールからの入力パケットなど）を割り当てることで制御プレーンのプロセスを実行したり、上述したトンネル化処理及びその他の機能を実行したりするために動作する。
【００７２】
ある実施形態では、各アプリケーション（図１４のプロファイル１４３を参照のこと）及びＳＩＭＡＣの機能（図１４のプロファイル１４１を参照のこと）の少なくとも一つがどのように動作すべきかについての嗜好情報をユーザが設定してもよい。各々プロファイル１４１及び１４３について、ある実施形態では、外部団体（ここではサードパーティと呼ぶ）が存在してもよく、これが前記機能の動作のデリミタである「ルール」を設定する。当該プロファイルは、中央制御部５６（図１４及び図５を参照のこと）内にあるポリシーロジックによって処理され、図１４のポリシーデータタベース１４２内に記憶されるポリシーファイルを生成する。
【００７３】
図１６は、本発明による例示的なポリシーファイルを示している。これには、優先順位に従って４つのポリシーがあり、最も高い優先順位のポリシー１６１から順番に、その次に優先順位の高いポリシー１６２、その次に高い優先順位のポリシー１６３及び最も低い優先順位のポリシー１６４と並んでおり、この例ではポリシー１６４がデフォルトポリシーとなっている。図５及び図１４に示した制御部５６のフローマッピング機能は、新しいアプリケーションフローのためにＳＩＭＡＣ機能を設定する際に、このポリシーファイルを使用することができる。特に最も高い優先順位のポリシー１６１を参照すると、アドレス及びプロトコルパラメータがアプリケーションフロー内の対応するパラメータと整合しており、利用可能なアクセスについての情報が許可であれば、インタフェースＩＮＴ１が使用される。すなわちリンクマネージャーの制御部５６内のフローマッピング機能がトランスポートチャネルを選択し、第４レイヤー転送エンジン５４内のルーティングテーブルを更新する。なお、この場合、ＩＮＴ１は１つのベアラだけを用いるタイプのインタフェースであるが、これはインタフェースが利用可能なのかどうかチェックするために十分だからというのがその理由である。いくつかベアラを使用するリンクレイヤー技術の場合には、ポリシーはインタフェースの能力だけでなく、各ベアラ（の能力及び特性のステータスの少なくとも一方を考慮する処理も含む）に関連している。もしＩＮＴ１が利用可能でなければ、その次に高い優先順位のポリシーであるポリシー１６２が検査される。なお、ポリシー１６１内の厳格性のパラメータは、ポリシーファイル中の他のポリシーが検査可能かどうかを決定するために利用される。厳格性のパラメータの値が「ヒント」になっているので、次に高い優先順位のポリシーの検査が許可される。しかし、もし厳格性のパラメータが「強制」に設定されている場合、この例では他のインタフェースがアプリケーションフローのために許可されていないので、ＩＮＴ１以外のインタフェースを検査しなくてもよいことを意味する。そのようなケースでは、リンクマネージャーが適切な障害コードを用いてアプリケーションサービスの要求を却下することができる。
【００７４】
ポリシー１６２を参照すると、もしアプリケーションフロー内のフロー識別情報のパラメータが、当該パケットが１０００−２０００の範囲の番号を有するポートへと向けられていることを示していれば、インタフェースＩＮＴ２は利用可能性について検査可能である。インタフェースＩＮＴ２が利用可能でなく、ＩＮＴ１について利用可能性が検査される。１つの例では、インタフェースＩＮＴ２が全てのＷＬＡＮインタフェースを代表しており、もしアプリケーションフローが１０００−２０００の範囲内のポート番号となっているフロー識別パラメータを有していれば、全てのＷＬＡＮインタフェースが検査される。しかしながら、利用可能なＷＬＡＮインタフェースが一つもない場合は、インタフェースＩＮＴ１の利用可能性が検査される。もしインタフェースのどれもがポリシー１６２内で利用可能と定義されていなければ、サービス要求障害が発生する。なぜなら、ポリシー１６２内の厳格性のパラメータが「強制」となっているため、他のいずれのインタフェースもアプリケーションフローのために許可されないことになるからである。リンクマネージャーは『サービス障害』の表示を用いて要求に対し応答することができる。
【００７５】
説明の便宜上、ポリシー１６２内の厳格性パラメータが「ヒント」であることを前提とし、さらにポリシー１６２内でいずれのインタフェースも利用可能として定義されていないことを前提とすると、ポリシー１６３が検査可能となる。もしパケットの単位時間あたりの料金パラメータが０．０１ユーロ毎秒であれば、インタフェースＩＮＴ３（例えばＵＭＴＳ）が利用可能性について検査される。もしＩＮＴ３が利用可能ならば、この例示的なポリシーは、より高い優先順位の「ａｂｃ」からより低い優先順位の「ｚｚｚ」まで優先順位付けされた２つの異なるサービスプロバイダの検査を要求する。より高い優先順位のサービスプロバイダ（この例での「ａｂｃ」）が利用可能であれば、この例示的なポリシーは、より高い優先順位のものからより低い優先順位のものへと優先順位に従って配置された２つの異なるベアラを検査する。もしより高い優先順位のベアラ（この例の「ｇｏｌｄ」）が利用可能ならば、リンクマネージャーの制御部５６内のフローマッピング機能によってそれが利用され、トランスポートチャネルが選択される。もしより高い優先順位のベアラが利用可能でなければ、より低い優先順位のベアラ（この例の「ｓｉｌｖｅｒ」）が利用可能性を検査される。もしポリシー１６３においてリストアップされているサービスプロバイダやベアラの中に利用可能なものが存在しなければ、「強制」に設定された厳格性パラメータは、次の優先順位のポリシー１６４が検査不要であることを示している。もし厳格性パラメータが「ヒント」に設定されていれば、他の利用可能なサービスプロバイダあるいはベアラが使用可能である。例示的なポリシー１６３には、それぞれ２つの関連ベアラを備える２つのサービスプロバイダだけが含まれているが、本発明のポリシーにおいては、サービスプロバイダの数や関連ベアラの数はどのような数に指定されてもよい。
【００７６】
他の例示的なポリシーファイルでは、サービスプロバイダが指定されていなくてもよい。その代わりに、インタフェースが直接的に１以上のベアラに関係付けられていてもよい。いくつかの例示的なポリシーファイルでは、インタフェースが指定されているだけで、サービスプロバイダやベアラは全く指定されていなくてもよい。
【００７７】
インタフェースＩＮＴ３が（ポリシー１６３によって指定されるように）利用可能でなければ、デフォルトポリシー１６４が検査され、最初にＩＮＴ１が利用可能であるかどうかを判定し、もし利用可能でなければ、順番に従ってＩＮＴ３又はＩＮＴ４が利用可能かどうかを判定する。図１６の各ポリシー内のインタフェースが左から右にかけて、最高の優先順位のものから最低の優先順位のものへと順番に優先付けされていることは明らかであろう。
【００７８】
他の例示的な実施形態において、ポリシー１６３を設計可能である。単位時間あたりのパケット料金関するパラメータが、ポリシー１６３で示されている値以下であれば、制御部５６内のポリシーロジックが、個々のデータ構造を参照する。このデータ構造は、例えばリンクマネージャー５２から提供されたもので、様々なインタフェースと関連したベアラの料金（費用）リストの更新をメンテナンスしたりする。当該料金は、例えば、ＧＧＳＮなどＵＭＴＳ用のリンクレイヤーのエンティティや、関連アクセスルーターによって、リンクマネージャー５２へと供給することができる。料金リストから、リンクマネージャー５２内の制御部５６のポリシーロジックは、例えば現在のところ最も安い費用にてパケットトランスポートサービスを提供しているインタフェース又はベアラを検査の対象として選択することができる。もし最も低い費用によるパケットトランスポートサービスを提供しているインタフェースが利用可能でなければ、その次に低い費用でパケットトランスポートサービスを提供しているインタフェースが利用可能性と適用可能性とが検査されるが、これは利用可能なインタフェース及び適用可能なベアラが見つかるか、あるいはトランスポートサービス要求障害が発生するまで実行される。
【００７９】
一例としてのインタフェースであるＩＮＴ１、ＩＮＴ２、ＩＮＴ３及びＩＮＴ４には、ＵＭＴＳ、ブルートース、ＬＡＮ、ＷＬＡＮ、ＧＰＲＳ及びＥｔｈｅｒｎｅｔ（登録商標）などが含まれる。
【００８０】
図１５は、異なるインタフェースとベアラへのフローについてルーティングの適合性を検査する本発明によるフローを示している。図１５のフローは、新しいトラフィックフローについて開始することができるが、あるいは、例えば、インタフェースあるいはトランスポートの特性が変化したとき（例えば価格変更など）、利用可能なインタフェースあるいはベアラが利用不可能になったとき、新しいインタフェースあるいはベアラが利用可能になったとき、またはユーザ若しくはサードパーティの嗜好に変更が生じたときに開始してもよい。図１５に示された例示的な動作は既に説明してきたが、リンクマネージャー５２の制御部５６内のポリシーロジックによって実行することも可能である。
【００８１】
本発明によってサポートされる動作についての特定の例として、関連するシグナリングフローとともに、オーディオ会話フロー及び静止画像フローなど２つのメディアフローを含む対話的なアプリケーションをユーザが開始するものとする。ユーザがＢｌｕｅｔｏｏｔｈ２ＬＡＮインタフェース、ＨｉｐｅｒＬａｎ２（Ｈ２）インタフェース及びＵＭＴＳインタフェースを具備する移動体通信端末を所有しているものとする。２つのアプリケーションとしては、例えばウェブブラウザとピアツーピア通信用の対話通信マネージャーが起動しているものとする。
【００８２】
もしユーザが偶然のオフィス（Ｂｌｕｅｔｏｏｔｈ２Ｌａｎ、Ｈ２及びＵＭＴＳネットワークへのアクセスが利用可能）の中にいる場合は、ＳＩＭＡＣモジュールは以下のように設定できよう。すべてのＨＴＴＰトラヒックはＢｌｕｅｔｏｏｔｈ２ＬＡＮのアクセス上に割り当てる。ＳＩＰ／ＳＤＰをＵＭＴＳアクセス上に割り当てる。そして他の全てのトラヒック（すなわちデフォルト）をＢｌｕｅｔｏｏｔｈ２ＬＡＮのアクセス上に割り当てる。ユーザは、ＩＦＴＦプロトコルであるＳＩＰとＳＤＰとを使用して第２のユーザとオーディオセッションを開始する。ユーザ装置間におけるＳＩＰ／ＳＤＰの交換処理は、ＵＭＴＳアクセス上で実行される。ユーザは同様に、ＲＴＰパケットで搬送されている音声メディアフローをＵＭＴＳベアラ上にマッピングすることを決定する。前述ＵＭＴＳ上へマッピングする理由の一つは、ユーザが移動する際に、セッションシグナリングと関連音声メディアフローが中断されてしまうことを望まない可能性があるからである。ＵＭＴＳのようなセルラーアクセスはそのような目的のために設計されている。
【００８３】
通信中の間、もし通信を開始した第１のユーザが画像のセットを第２のユーザと分かち合いたいと希望する場合、第１のユーザはウェブブラウザを使用してネットワークのサーバからの画像にアクセスすることができる。これらの画像は、第１のユーザの通信端末から取ってこられるが、その際には、ＳＩＭＡＣモジュールの設定部内のルーティングプロファイルに従ったＢｌｕｅｔｏｏｔｈ２ＬＡＮのアクセスが使用される。
【００８４】
取得された画像の１つについてのＨＴＴＰ ＵＲＬはＢｌｕｅｔｏｏｔｈ２ＬＡＮのアクセスを介して第２のユーザへと信号伝達されるが、この際には、（１）セッションに画像メディアフローを追加するための要求と、（２）２つのユーザ間における画像操作プロトコルを確立するための要求も一緒に信号により伝達される。第２のユーザがこの要求を受け入れると、当該第２のユーザはサーバにアクセスして画像を取得する。その結果、２人のユーザともそれぞれ操作用の画像を保持することになる。２人が画像を操作するにつれて、この操作に関する情報が２つの端末間で送受信される。ＳＩＭＡＣモジュールの設定部内にあるルーティングプロファイルにしたがって、ＵＭＴＳのアクセスはこの画像操作についての信号伝達のために使用される。このように、（例えば端末３１とプロキシー３２用の）現在のセッションの状態は以下の通りである。画像ダウンロードのトラヒックを含む全てのＨＴＴＰは、Ｂｌｕｅｔｏｏｔｈ２ＬＡＮのアクセス上へとルーティングされる。画像操作及びＳＩＰ／ＳＤＰは、ＵＭＴＳのアクセス上へとルーティングされる。オーディオデータとそれに関連する信号伝達のフローは、ＵＭＴＳのアクセス上へとルーティングされる。そして他の全てのフローは、Ｂｌｕｅｔｏｏｔｈ２ＬＡＮ（デフォルト）のアクセス上へとルーティングされる。
【００８５】
もし第１のユーザが、自分のオフィスから外出し、ブルートースの圏外に出てしまったとすると、ＳＩＭＡＣモジュールは以下のルーティングプロファイルを実行することができる。Ｈ２アクセス上への画像ダウンロードトラヒックを含む全てのＨＴＴＰ。ＵＭＴＳアクセス上への画像操作及びＳＩＰ／ＳＤＰ。ＵＭＴＳアクセス上へのオーディオデータとそれに関連する信号伝達フロー。そして、Ｈ２アクセス（現在のデフォルトアクセス）上への他の全てのフロー。このようにして、ＳＩＭＡＣモジュールは、Ｈ２アクセス上への移動中画像フローのマッピングと、利用可能なベアラの変更に関する通知情報をユーザに供給（オプションとして、アプリケーションにも供給してもよい）する。ＵＭＴＳアクセスは引き続き利用可能となるため、オーディオメディアのフローと、それに関連する信号伝達（例えば、ＲＴＣＰ）とが影響を受けないようになる。
【００８６】
もし第１のユーザが他の画像を見たいと希望する場合は、Ｈ２アクセスを使用して、その画像を第１のユーザの通信端末装置へとダウンロードすることができる。同様に、もし第１のユーザがＨ２アクセスの圏外へと移動すると、ＳＩＭＡＣモジュール（及び／またはユーザ）は、同様にＨＴＴＰトラフィック用としてＵＭＴＳを使用することを選択できる。
【００８７】
当業者であれば、例えば従来の通信端末装置及びプロキシー装置内のソフトウェア、ハードウエア、あるいはソフトウェアとハードウエアの組み合わせを適宜修正することで、上述した実施形態をすぐに実現できることは明白であろう。
【００８８】
本発明の例示的な実施形態を詳細に説明してきたが、これは本発明の技術的範囲を制限するものではない。本発明は、多種多様な態様で実現可能である。
【図面の簡単な説明】
【００８９】
【図１】図１は、対話的なマルチメディアアプリケーション用のユーザ通信端末装置から又はそれへの例示的なアプリケーションパケットフローを示す図である。
【図１Ａ】図１Ａは、複数のアプリケーション間におけるＩＰ通信を例示する図である。
【図１Ｂ】図１Ｂは、サービス・アクセス・ポイントを経由したインタフェース上にアプリケーションフローをマッピングする例を示す図である。
【図２】図２は、本発明の例示的な実施形態に関係する機能アーキテクチャを例示する図である。
【図３】図３は、図１に例示された通信をサポートする本発明の他の例示的な実施形態であって、図２の経路制御機能の１つが、あるユーザの通信端末装置に配置されていることを示した図である。
【図４】図４は、図３の通信端末装置についての一つの例示的な実施形態の中心部を例示した図である。
【図５】図５は、図４のＳＩＭＡＣモジュールについての例示的な実施形態を示した図である。
【図６】図６は、図３のＳＩＭＡＣプロキシーの例示的な実施形態を示す図である。
【図７】、
【図７Ａ】図７及び図７Ａは、最適化機能プロキシーを含む本発明の例示的な実施形態を示す図である。
【図８】図８は、アプリケーションプロキシーを含む本発明のさらに他の例示的な実施形態を示す図である。
【図９】図９は、ＩＰを基盤とするシステムにおけるアプリケーションからのトランスポートに関する従来例を示す図である。
【図１０】、
【図１１】、
【図１２】図１０−１２は、図５及び図６の第４レイヤー転送エンジンによって使用可能な例示的なテーブルを示した図である。
【図１３】図１３は、図６のより詳細な一部を示す図である。
【図１４】図１４は、図５のリンクマネージャーについての例示的な実施形態の中心部を示した図である。
【図１５】図１５は、図１４の実施形態によって実行可能な例示的な動作を示した図である。
【図１６】図１６は、図１４の実施形態によって使用可能な例示的なポリシーを示す図である。
【図１７】図１７は、図５のリンクマネージャーによって使用可能な例示的なリンクレイヤーベアラ設定テーブルを示す図である。
【図１８】図１８は、本発明に係る第４レイヤー転送エンジンと、図９の従来型ＩＰ機能部との間での例示的な相互の動作関係を示した図である。
【図１９】図１９は、図５及び図６の第４レイヤー転送エンジンによって使用される、リンクベアラとトランスポートチャネルとを関係付けるための例示的なテーブルを示す図である。
【図２０】図２０は、本発明に係る例示的なＳＩＭＡＣ初期化動作を示す図である。
【図２１】図２１は、本発明に係るＳＩＭＡＣサービスでアプリケーションを登録するための例示的な動作を示す図である。
【図２２】図２２は、本発明に係るアプリケーションサービス要求に関係した例示的な動作を示した図である。
【図２３】図２３は、本発明に係るフローの再マッピングを達成するための例示的な動作を示した図である。

Claims (68)

1. ＩＰ基盤の通信ネットワークを経由して通信を実行する方法であって、
   複数のベアラを経由して通信ネットワークへのアクセスを取得するステップと、
   前記ベアラの一つに対応した通信アプリケーション動作に関連する複数のパケットフローをルーティングするステップと
   を含む方法。
2. 前記パケットフローの一つに係るパケットをカプセル化して、関連するベアラ上でトンネル化するステップをさらに含む請求項１に記載の方法。
3. 前記ベアラはそれぞれネットワーク・リンク・インタフェースによって提供されている、請求項１に記載の方法。
4. 前記ベアラのうち少なくとも２つは、単一のネットワーク・リンク・インタフェースによって提供されている、請求項１に記載の方法。
5. ベアラの利用可能性を示すリンクレイヤー情報に基づいて前記ベアラを選択するステップをさらに含む請求項１に記載の方法。
6. リンク情報に基づいて、現在のベアラから異なるベアラへと前記パケットフローの一つのルーティングを変更するステップをさらに含む請求項１に記載の方法。
7. 前記リンクレイヤー情報は、あるパケットフローをルーティングしている現在のベアラが利用不可能になることを示すものであり、前記ベアラが利用不可能となるのは、前記通信アプリケーションが動作している通信端末が移動するためである、請求項６に記載の方法。
8. ユーザ、サードパーティ及び通信アプリケーションの少なくとも一つに対して前記ルーティングの変更を通知するステップをさらに含む請求項６に記載の方法。
9. パケットフローのルーティングに関連する前記ユーザの嗜好情報、前記通信アプリケーションの要求条件及びサードパーティ嗜好情報の少なくとも一つに基づいて前記ベアラの一つを選択するステップをさらに含む請求項１に記載の方法。
10. 前記関連するパケットフローの特性及び前記ベアラの動作特性に基づいて、前記ベアラの一つを選択するステップをさらに含む請求項１に記載の方法。
11. 前記パケットフローの特性には、帯域幅の要求条件及び前記パケットフロー内のパケットに含まれる情報の内容の一つが含まれている請求項１０に記載の方法。
12. 前記パケットフローの特性には、サービス品質の要求条件及び前記パケットフロー内のパケットに含まれる情報の内容の一つが含まれている請求項１０に記載の方法。
13. 前記動作特性には、スループット及び動作費用の一つが含まれている請求項１０に記載の方法。
14. 前記動作特性には、サービス品質に関するパラメータが含まれている請求項１０に記載の方法。
15. 前記あるパケットフローの特性に基づいて該パケットフローに性能の拡張機能を適用するステップをさらに含む請求項１に記載の方法。
16. 前記パケットフローの特性は帯域幅の要求条件である請求項１５に記載の方法。
17. 前記適用のステップには、前記ネットワーク内にプロキシーが前記性能の拡張機能を適用するステップが含まれる請求項１５に記載の方法。
18. 前記適用のステップには符号変換機能を適用するステップが含まれる請求項１５に記載の方法。
19. 前記通信アプリケーションが、パケットにより第１の種類の伝達信号を搬送する第１の構成のパケットフローと、パケットにより第１の種類とは異なる第２の種類の伝達信号を搬送する第２の構成のパケットフローとを単一のデータパス内に供給するステップと、
    前記第１の構成のパケットフローと前記第２の構成のパケットフローとを区別するステップと、
    前記第１及び第２の構成のパケットフローをそれぞれ第１及び第２のベアラにルーティングするステップと
    をさらに含む請求項１に記載の方法。
20. 前記区別のステップには、アプリケーションプロキシーが前記第１の構成のパケットフローと前記第２の構成のパケットフローとを区別するステップが含まれる請求項１９に記載の方法。
21. 前記アクセスを取得するステップには、ブルートゥースインタフェース、ＬＡＮインタフェース、ＷＬＡＮインタフェース、ＵＭＴＳインタフェース、ＧＰＲＳインタフェース、イーサネット（登録商標）インタフェース及びＨｙｐｅｒＬＡＮ２インタフェースの１つと関連するベアラへのアクセスを取得するステップが含まれる請求項１に記載の方法。
22. 前記パケットフローは上りリンクのパケットフローである請求項１に記載の方法。
23. 前記パケットフローは下りリンクのパケットフローである請求項１に記載の方法。
24. ＩＰを基盤とする通信ネットワークを経由して通信セッションを実行する際に使用される装置であって、
    前記通信ネットワークへのアクセスを供給することで複数のベアラへのアクセスを供給するネットワークインタフェース構造と、
    通信アプリケーションの動作に関連する複数のパケットフローを搬送する通信パスと、
    前記ネットワーク・リンク・インタフェース構造と前記通信パスに接続し、前記複数のパケットをそれぞれ同時に前記ベアラの一つにルーティングするルーティング装置と
    を含む装置。
25. 前記ルーティング装置には、一つの前記パケットフローのパケットを、前記関連するベアラ上にトンネル化するためにカプセル化するトンネルシンセサイザーが含まれる請求項２４に記載の装置。
26. 前記ベアラは、前記ネットワーク・リンク・インタフェース構造に含まれている単一のネットワークインタフェースによって供給される請求項２４に記載の装置。
27. 少なくとも２つの前記ベアラは、前記ネットワーク・リンク・インタフェース構造に含まれている単一のネットワークインタフェースによって供給される請求項２４に記載の装置。
28. 前記ネットワーク・リンク・インタフェース構造には、ブルートゥースインタフェース、ＬＡＮインタフェース、ＷＬＡＮインタフェース、ＵＭＴＳインタフェース、ＧＰＲＳインタフェース、イーサネット（登録商標）インタフェース及びＨｙｐｅｒＬＡＮ２インタフェースの一つが含まれている請求項２４に記載の装置。
29. 請求項２４に記載の装置はユーザの通信端末内に提供される装置。
30. 前記通信端末は無線電話端末である請求項２９に記載の装置。
31. 請求項２４に記載の装置は前記ネットワーク内にプロキシーとして提供される装置。
32. 前記パケットフローは、上りリンクのパケットフローである請求項２４に記載の装置。
33. 前記パケットフローは、下りリンクのパケットフローである請求項２４に記載の装置。
34. 前記前記ルーティング装置に接続し、前記ベアラ上において前記パケットフローをどのようにルーティングすべきかを決定するとともに、決定されたルーティングを示す情報を前記ルーティング装置に対して供給するリンクマネージャーをさらに含む請求項２４に記載の装置。
35. 前記リンクマネージャーは、前記ルーティング装置から離れて配置される請求項３４に記載の装置。
36. 前記リンクマネージャーは、前記ルーティング装置内に搭載されている請求項３４に記載の装置。
37. 前記リンクマネージャーに接続し、ユーザ、前記通信アプリケーション及びサードパーティの一つが前記リンクマネージャーに対し、前記パケットフローについて所望のルーティングを示している情報を入力可能ならしめるインタフェースをさらに含み、前記リンクマネージャー前記所望のルーティングの情報に応答して前記パケットフローのルーティングを決定する請求項３４に記載の装置。
38. 前記関連するパケットフロー特性に基づいて前記ベアラの一つを設定するステップをさらに含む請求項１に記載の方法。
39. 前記パケットフローの１つと関連している第１の接続情報が第１のネットワーク・リンク・インタフェース関連する第２の接続情報と整合しているかどうかを判定するステップをさらに含む請求項３に記載の方法。
40. 前記第１の接続情報が前記第２の接続情報と整合している場合に、前記第１のネットワーク・リンク・インタフェースを前記パケットフローのルーティングのために利用可能であるかどうかを判定するステップを含み、もし利用可能であれば、前記ルーティングのステップは前記第１のネットワーク・リンク・インタフェース上で前記パケットをルーティングするステップを含む、請求項３９に記載の方法。
41. 前記第１のネットワーク・リンク・インタフェースが利用可能でない場合に、前記第２の接続情報に関連した第２のネットワーク・リンク・インタフェースが、前記パケットフローをルーティングするために利用可能かどうかを判定するステップをさらに含み、もし利用可能であれば、前記ルーティングのステップは、前記第２のネットワーク・リンク・インタフェース上で前記パケットフローをルーティングするステップをさらに含む請求項４０に記載の方法。
42. 前記第２のネットワーク・リンク・インタフェースが利用可能でない場合に、前記第１の接続情報が、第３のネットワーク・リンク・インタフェースと関連した第３の接続情報と一致するかどうかを判定するステップをさらに含む請求項４１に記載の方法。
43. 前記第１の接続情報が前記第３の接続情報と整合している場合に、前記第３のネットワーク・リンク・インタフェースを前記パケットフローのルーティングのために利用可能であるかどうかを判定するステップを含み、もし利用可能であれば、前記ルーティングのステップは、前記第３のネットワーク・リンク・インタフェース上で前記パケットをルーティングするステップを含む、請求項４２に記載の方法。
44. 前記第１及び第２のネットワーク・リンク・インタフェースは、お互いに異なっている、請求項４３に記載の方法。
45. 前記第２のネットワーク・リンク・インタフェースは、前記第１及び第２のネットワーク・リンク・インタフェースの双方と異なっている、請求項４４に記載の方法。
46. 前記第３のネットワーク・リンク・インタフェースは、前記第１及び第２のネットワーク・リンク・インタフェースの１つと同一のものである、請求項４４に記載の方法。
47. 前記第３の接続情報は、前記第１の接続情報が該第３の接続情報と整合するように定義されている、請求項４２に記載の方法。
48. 前記第１の接続情報が前記第２の接続情報と整合していない場合に、前記第１の接続情報が、前記第２のネットワーク・リンク・インタフェースに関連する第３の接続情報と整合するかを判定するステップをさらに含む請求項３９に記載の方法。
49. 前記第１の接続情報が前記第３の接続情報と整合している場合に、前記第３の接続情報に関連した第３のネットワーク・リンク・インタフェースが、前記パケットフローをルーティングするために利用可能であるかどうか判定するステップをさらに含み、もし利用可能であれば、前記ルーティングのステップは、前記第３のネットワーク・リンク・インタフェース上で前記第３のパケットフローをルーティングするステップをさらに含む、請求項４８に記載の方法。
50. 前記第２のネットワーク・リンク・インタフェースが利用可能でない場合に、前記第３の接続情報と関連した第３のネットワーク・リンク・インタフェースが前記パケットフローをルーティングするために利用可能かどうかを判定するステップをさらに含み、もし利用可能であれば、前記ルーティングのステップは、前記第３のネットワーク・リンク・インタフェース上で前記パケットフローをルーティングするステップを含む、請求項４９に記載の方法。
51. 前記第１の接続情報は、ＩＰｖ４／ｖ６アドレス、ポート番号、通信プロトコル識別情報、ホスト識別タグ、及びローカルな範囲の識別情報の一つを含む、請求項３９に記載の方法。
52. 前記第２の接続情報は、ＩＰｖ４／ｖ６アドレス、ポート番号、通信プロトコル識別情報、ホスト識別タグ、及びローカルな範囲の識別情報の一つを含む、請求項３９に記載の方法。
53. 前記第１の接続情報は、前記パケットフローのヘッダの中に搭載されている、請求項３９に記載の方法。
54. 前記第２の接続情報は、前記第１の接続情報内に搭載された接続パラメータの範囲を特定するものであり、前記判定のステップは、前記第１の接続情報の接続パラメータが前記第２の接続情報により特定された範囲内にあるかどうかを判定するステップを含む、請求項３９に記載の方法。
55. 前記接続パラメータは、ポート番号である、請求項５４に記載の方法。
56. 前記判定のステップは、前記第１の接続情報が前記第２の接続情報を含んでいるかどうかを決定するステップを有している、請求項３９に記載の方法。
57. 前記第２の接続情報はIPアドレスと通信プロトコルの識別情報である、請求項５６に記載の方法。
58. 前記第２の接続情報は、前記ネットワーク・リンク・インタフェースのグループに関連しており、
    もし前記第１の接続情報が前記第２の接続情報と整合する場合には、前記パケットフローをルーティングするために前記グループのそれぞれのベアラを使用する際の相対的な費用に基づいて、前記ベアラのグループの一つで前記パケットフローをルーティングすることを選択するステップをさらに含む、請求項３９に記載の方法。
59. 前記ベアラの一つは最低の費用である請求項５８に記載の方法。
60. 前記ベアラは、前記ネットワーク・リンク・インタフェース構造に含まれているそれぞれのネットワーク・リンク・インタフェースによって提供される、請求項３４に記載の装置。
61. 前記リンクマネージャーは、前記パケットフローの一つに関連した第１の接続情報を受信するための第１の入力部と、前記第２の接続情報と、前記第２の接続情報に関連した第１のネットワーク・リンク・インタフェースを示すネットワーク・リンク・インタフェースの情報を受信するための第２の入力部とを備えたロジックを含み、前記ロジックは、前記第１の接続情報が前記第２の接続情報と整合するかどうかを判定するために動作可能である、請求項６０に記載の装置。
62. 前記ロジックは、前記ネットワーク・リンク・インタフェースの利用可能性を示す情報を受信する第３の入力部を含み、前記ロジックは、前記第１の接続情報が前記第２の接続情報と整合するとの判定に応答して、前記パケットフローをルーティングするために前記第１のネットワーク・リンク・インタフェースが利用可能かどうかを、前記ネットワーク・リンク・インタフェースの利用可能性の情報から判定し、前記ルーティング装置は、前記第１のネットワーク・リンク・インタフェースが利用可能であるとの判定に応答して、前記第１のネットワーク・リンク・インタフェース上で前記第１のパケットフローをルーティンするために動作可能である、請求項６１に記載の装置。
63. 前記ネットワーク・リンク・インタフェースの情報は、前記第２の接続情報に関連した第２のネットワーク・リンク・インタフェースを示す情報を含んでおり、前記ロジックは、前記第１のネットワーク・リンク・インタフェースが利用可能ではないとの判定に応答して、前記第２のネットワーク・リンク・インタフェースが利用可能かどうかを決定し、前記ルーティング装置は、前記第２のネットワーク・リンク・インタフェースが利用可能であるとの判定に応答して、前記第２のネットワーク・リンク・インタフェース上で前記パケットフローをルーティンするために動作可能である、請求項６２に記載の装置。
64. 前記第２の入力部は、さらに、第３の接続情報と、前記第３の接続情報に関連した第３のネットワーク・リンク・インタフェースを示すさらなるネットワーク・リンク・インタフェースの情報とを受信し、前記ロジックは、前記第２のネットワーク・リンク・インタフェースが利用可能でないとの判定に応答して、前記第１の接続情報が前記第３の接続情報と整合するかどうかを判定するために動作可能である、請求項６３に記載の装置。
65. 前記ロジックは、前記第１の接続情報が前記第３の接続情報と整合するとの判定に応答して、前記パケットフローをルーティングするために前記第３のネットワーク・リンク・インタフェースを利用可能かどうかを判定し、前記ルーティング装置は、前記第３のネットワーク・リンク・インタフェースが利用可能であるとの判定に応じて、前記第３のネットワーク・リンク・インタフェース上で前記パケットフローをルーティングするために動作可能である、請求項６４に記載の装置。
66. 前記第２の入力部は、さらに、第３の接続情報と、前記第３の接続情報に関連した第２のネットワーク・リンク・インタフェースを示すさらなるネットワーク・リンク・インタフェースの情報とを受信し、前記ロジックは、前記第１の接続情報が前記第２の接続情報と整合しないとの判定に応じて、前記第１の接続情報が前記第３の接続情報と整合するかどうかを判定するために動作可能である、請求項６１に記載の装置。
67. 前記ロジックは、前記第１の接続情報が前記第３の接続情報と整合するとの判定に応答して、前記パケットフローをルーティングするために前記第２のネットワーク・リンク・インタフェースを利用可能かどうかを判定し、前記ルーティング装置は、前記第２のネットワーク・リンク・インタフェースが利用可能であるとの判定に応じて、前記第２のネットワーク・リンク・インタフェース上で前記パケットフローをルーティングするために動作可能である、請求項６６に記載の装置。
68. 前記ネットワーク・リンク・インタフェース情報は、さらに前記第３の接続情報に関連した第３のネットワーク・リンク・インタフェースを示す情報を含んでおり、前記ロジックは、前記第２のネットワーク・リンク・インタフェースが利用可能ではないとの判定に応じて、前記パケットフローをルーティングするために動作可能であり、前記ルーティング装置は、前記第３のネットワーク・リンク・インタフェースが利用可能であるとの判定に応じて前記第３のネットワーク・リンク・インタフェース上で前記パケットフローをルーティングするために動作可能である、請求項６７に記載の装置。

Images