(57)【要約】【課題】  クライエントのセッションと関係するパケットを正しく識別できるようにすることを目的とする。【解決手段】  クライエントから第１ネットワークへのセッションへＱｏＳを提供する方法であって、クライエントから第１ネットワークへのセッションで伝達されるクライエントからのデータパケットを提供するステップと、それぞれのデータパケットを封入パケットに挿入し、第２ネットワークを介して封入パケットを第１ネットワークへ伝達するステップと、第２ネットワークを介してトンネルを形成するステップとを含んでいる。本方法は、第１ネットワークの終了デバイスにて封入パケットを受領するステップを含んでいる。終了デバイスはデータパケットを回復させるために封入ヘッダを取り除く。本方法は、データパケットのパケットヘッダと封入ヘッダとの間の関係を決定するステップと、ＱｏＳを必要とするデータパケットを識別するステップと、ＱｏＳを必要とするデータパケットに対応する封入パケットを識別するためにその関係を使用するステップとを含んでいる。本方法は、トンネルを介して伝達されているＱｏＳを必要とするデータパケットのセッションに対応してＱｏＳを封入パケットに適用するステップを含んでいる。【選択図】    図１
2009544227.tif 000002
【特許請求の範囲】
【請求項１】
クライエントから第１ネットワークへのセッションへＱｏＳを提供する方法であって、前記セッションは前記クライエントと前記第１ネットワークの間で第２ネットワークを通過するものであり、本方法は、
前記クライエントから前記第１ネットワークへの前記セッションで伝達され、パケットを経路化するためのパケットヘッダを含んだデータパケットを提供するステップと、
それぞれの前記データパケットを封入ヘッダを有する封入パケットに挿入するステップと、
前記第２ネットワークを介して前記封入パケットを前記第１ネットワークへ伝達し、前記第２ネットワークを介してトンネルを形成するステップと、
前記第１ネットワークに存在し、前記データパケットを回復させるために前記封入ヘッダを取り除く終了デバイスにて前記封入パケットを受領するステップと、
前記回復データパケットの前記パケットヘッダと前記トンネルを介して前記データパケットを運搬するのに使用される前記封入ヘッダとの間の関係を決定するステップと、
ＱｏＳを必要とするデータパケットのセッションを識別し、ＱｏＳを必要とする前記データパケットのセッションに対応する封入パケットを識別するために前記関係を使用するステップと、
前記トンネルを介して伝達されているＱｏＳを必要とする前記データパケットのセッションに対応してＱｏＳを前記封入パケットに適用するステップと、
を含んでいることを特徴とする方法。
【請求項２】
回復データパケットのパケットヘッダとトンネルを介してデータパケットを運搬するのに使用される封入ヘッダとの間の関係を保存するステップをさらに含んでいることを特徴とする請求項１記載の方法。
【請求項３】
第１ネットワークのＱｏＳを必要とするデータパケットのセッションを識別し、その識別に対応して第２ネットワークに対して、封入パケットにＱｏＳを適用する必要性を伝達するステップをさらに含んでいることを特徴とする請求項１記載の方法。
【請求項４】
ピアポリシーサーバはＱｏＳを封入パケットに適用する必要性を伝達することを特徴とする請求項３記載の方法。
【請求項５】
データパケットのセッションがＱｏＳを必要としなくなったとき封入パケットからＱｏＳを引き出すステップをさらに含んでいることを特徴とする請求項１記載の方法。
【請求項６】
終了デバイスがパケットヘッダのアドレストランスレーションをさらに提供することを特徴とする請求項１記載の方法。
【請求項７】
クライエントから第１ネットワークへのセッションへＱｏＳを提供する方法であって、前記セッションは前記クライエントと前記第１ネットワークとの間で第２ネットワークを通過するものであり、本方法は、
前記第２ネットワークを通過してトンネルを形成するステップを含んでおり、前記トンネルを通過する前記セッションのデータパケットは封入パケットを形成するために封入され、本方法は、
前記セッションがＱｏＳを必要とするときのみ前記トンネルへＱｏＳを適用するステップをさらに含んでいることを特徴とする方法。
【請求項８】
第１ネットワークに存在し、データパケットを回復するために封入パケットのヘッダを取り除く終了デバイスにて封入パケットを受領するステップと、
前記回復データパケットのパケットヘッダとトンネルを介して前記データパケットを運搬するのに使用される封入ヘッダとの間の関係を決定するステップと、
ＱｏＳを必要とするデータパケットの特定セッションを識別し、ＱｏＳを必要とする前記データパケットのセッションに対応する封入パケットを識別するために前記関係を使用するステップと、
前記トンネルを通して運搬されているＱｏＳを必要とする前記データパケットのセッションに対応する前記封入パケットにＱｏＳを適用するステップと、
をさらに含んでいることを特徴とする請求項７記載の方法。
【請求項９】
封入パケットにＱｏＳを適用する必要性を通信するためにピアポリシーサーバを提供するステップをさらに含んでいることを特徴とする請求項８記載の方法。
【請求項１０】
データパケットのセッションがＱｏＳを必要としなくなったときに封入パケットからＱｏＳを引き出すステップをさらに含んでいることを特徴とする請求項７記載の方法。
【請求項１１】
クライエントから第１ネットワークへのセッションにＱｏＳを提供する方法であって、前記セッションは前記クライエントと前記第１ネットワークとの間で第２ネットワークを通過するものであり、本方法は、
前記セッションを伝達するために前記第２ネットワークを通過させてトンネルを形成するステップを含んでおり、前記トンネル内の前記セッションのパケットは封入パケットを形成するために封入され、本方法は、
ＱｏＳを前記トンネル内の前記封入パケットに適用するステップをさらに含んでいることを特徴とする方法。
【請求項１２】
第２ネットワークのトンネルのターミナルエンドで封入パケットを受領するステップと、
前記封入パケットからセッションのパケットを抽出するステップと、
前記セッションからの前記パケットがＱｏＳを必要とすることを決定するステップと、
前記トンネルを維持する任務を担う前記第２ネットワーク内のネットワークコンポーネントを識別するステップと、
前記トンネルへＱｏＳを適用する必要性を前記ネットワークコンポーネントに伝達するステップと、
をさらに含んでいることを特徴とする請求項１１記載の方法。
【請求項１３】
セッションのパケットを含む封入パケットに関して前記セッションのパケットのヘッダをマップ処理するステップと、該マップ処理をトンネルを維持する任務を担う第２ネットワーク内のネットワークコンポーネントに伝達するステップとをさらに含んでいることを特徴とする請求項１２記載の方法。
【請求項１４】
クライエントから第１ネットワークへのセッションへＱｏＳを提供するシステムであって、前記セッションは前記クライエントと前記第１ネットワークとの間で第２ネットワークを通過するものであり、本システムは、
クライエントデバイスから前記第１ネットワークへの前記セッションに伝達されるデータパケットを提供するクライエントデバイスであって、該データパケットは該パケットを経路化するパケットヘッダを含んでいることを特徴とするクライエントデバイスと、
それぞれの前記データパケットを封入ヘッダを有した封入パケットに挿入し、前記封入パケットを前記第２ネットワークを介して前記第１ネットワークに伝達し、前記第２ネットワークを通過するトンネルを形成するための封入モデュールと、
前記封入パケットを受領し、前記データパケットを回復するために前記封入ヘッダを取り除き、前記回復データパケットの前記パケットヘッダと前記トンネルを通過して前記データパケットを伝達するのに使用される前記封入ヘッダとの間の関係を決定するための前記第１ネットワーク内の終了デバイスと、
ＱｏＳを必要とするデータパケットのセッションを識別し、ＱｏＳを必要とする前記データパケットのセッションに対応する封入パケットを識別するために前記関係を使用し、前記トンネルを通過して伝達されるＱｏＳを必要とする前記データパケットのセッションに対応してＱｏＳを前記封入パケットに適用するためのポリシーサーバと、を含んでいることを特徴とするシステム。
【請求項１５】
回復データパケットのパケットヘッダと封入ヘッダとの間の関係はメモリデバイスに保存されることを特徴とする請求項１４記載のシステム。
【請求項１６】
トンネルにＱｏＳを適用するのに要求される機能を実行するために第２ネットワークにピアポリシーサーバを含んでいることを特徴とする請求項１４記載のシステム。
【請求項１７】
第１ネットワークは無線サービスプロバイダネットワークであり、第２ネットワークはケーブルＭＳＯネットワークであることを特徴とする請求項１４記載のシステム。
【請求項１８】
終了デバイスはホームエージェントサーバであることを特徴とする請求項１４記載のシステム。
【請求項１９】
パケットヘッダと封入ヘッダはＩＰヘッダであることを特徴とする請求項１４記載のシステム。
【請求項２０】
マルチモードデバイスはトンネルのクライエントエンドでトンネル形成および終了機能を実行し、ホームエージェントサーバはトンネルの第１ネットワークエンドでトンネル形成および終了機能を実行することを特徴とする請求項１４記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデジタルコンテンツを配分する通信システムおよびサービスに関する。特に本発明は複数の代替ネットワークを介して（それら代替ネットワークを介した適切な“サービス品質”（ＱｏＳ）を維持しつつ）希望ネットワークにアクセスする技術に関する。
【背景技術】
【０００２】
現行の通信システムにおいては加入者（サブスクライバ）はケーブルまたはＤＳＬオペレータによって提供されるアクセスを介してインターネットにアクセスできる。同様にモバイルカスタマ（移動顧客）はモバイルサービス（例：セルラフォン（携帯電話）サービス）をセルラプロバイダにより提供されるセルラネットワークを介して享受できる。モバイルカスタマはボイスコールするために例えばセルラネットワークのＴＤＭ（時間分割マルチプレックス）回路を使用することができる。
【０００３】
さらに多くのサービスがＩＰ利用可となるに連れてサービスプロバイダまたはオペレータはこれらサービスを提供する革新的な方法を有するようになる。そのようなＩＰ利用可サービスの１例はＶｏＩＰ（ＩＰ利用ボイス）であり、ボイス情報はデジタル化されてＩＰパケットに変換され、インターネットを介して受領“フォン”に送られる。そのような革新的な技術は多くのサービスに利用可能になってきている。別の重要な例はビデオ関連サービスである。
【０００４】
プロバイダによってはモバイルサービスのものを擬似するサービス提供のために自身のＩＰネットワークのレバレッジを試みている。例えば最近に利用が可能になったフォン（電話）は“マルチモード”機能で利用ができる。マルチモードとはそれらモバイルデバイスが全く異なる技術を利用して異なるネットワークに“アタッチ”できることである。マルチモードデバイス（ここでの“コンボフォン”）の１例はＷｉＦｉ基準（ＩＥＥＥ８０２．１１）および３Ｇ（ＣＤＭＡとＧＳＭを利用した３ＧＰＰ２/３ＧＰＰ基準）と伝統的なＴＤＭプロトコルに基づいた無線ローカルエリアネットワーク（ＷＬＡＮ）を介して通信できるデバイスである。マルチモードデバイスによってこれら全ての機能はＷｉＦｉネットワークまたは３Ｇモバイルデータネットワークあるいは伝統的なＴＤＭ回路利用のモバイルネットワークにアタッチ可能な１体のモバイルユニットに内蔵される。このようなマルチモード特性の理由は、ネットワーク信号の強度（サービス品質に直接的に影響）、そのようなネットワークのオペレーションコストまたは他のオペレーション関連事情によって、デバイスが１つの特定サービスを提供するために別ネットワークに加えて１つの特定ネットワークを利用することに利点が存在するためである。
【０００５】
ユーザのホームでは弱いセルラシグナルとなるので、電話をかけるためにはマルチモードモバイルユニットは標準的なＴＤＭ利用セルラネットワークを使用する代わりにＷｉＦｉネットワークにアタッチでき、そのＷｉＦｉネットワークを介してＶｏＩＰセッションをイニシエートさせることができる。このＷｉＦｉネットワークは典型的にはホームＷｉＦｉデバイス/ゲートウェイによって提供される。これはＷｉＦｉリンクのターミナルエンドで高速データネットワーク（例：ケーブルブロードバンド、ｘＤＳＬまたはファイバ）にアタッチされる。このＶｏＩＰトラフィックはＩＰトンネル（典型的にはこのトンネルはＩＰＳＥＣで利用される）で封入されることが多い。このＶｏＩＰトラフィックはアクセスネットワークプロバイダ（例：ケーブルまたはｘＤＳＬまたはファイバオペレータ）のネットワークを介して“トンネル”処理され、モバイルサービスプロバイダのＩＰ利用ネットワークに戻される。ＶｏＩＰトラフィックがモバイルサービスプロバイダのネットワークに到達するとＩＰトンネルは“終了”し、トンネルを介して運搬されたＶｏＩＰトラフィックは抽出され、モバイルプロバイダのネットワークで通信される。究極的にはこのＶｏＩＰトラフィックはボイスゲートウェイで終了し、ＴＤＭトラフィックに変換されて戻される。
【０００６】
本例では加入者の“ホームネットワーク”はモバイルプロバイダのネットワークである。なぜなら加入者にサービス提供する任務を担うアプリケーションインフラストラクチャはモバイルネットワークに内在するからである。このデバイスがそこを通過してトンネル処理するケーブルまたはｘＤＳＬネットワークは来訪ネットワークであると考えられる。
【０００７】
図１は上述のトンネルを構築するのに使用される一般的なパケットフォーマットを図示する。封入パケット１０はＩＰヘッダ１２、ＵＤＰヘッダ１４およびＭＩＰコントロールデータ１６を含む。ＩＰトンネルを構築するにはオリジナルパケット１０がＥＳＰヘッダ２２、ＥＳＰトレーラ２４、ＮＡＴ−Ｔ  ＵＤＰヘッダ２６およびＩＰＳＥＣ  ＩＰヘッダ２８（これらはまとめて一般的に“封入ヘッダ”または“トンネルヘッダ”と呼称）を加えることで封入パケット２０に内蔵される。一般的にトンネルを提供するネットワークコンポーネントはＩＰヘッダ１２とＵＤＰヘッダ１４とを無視し、ＮＡＴ−Ｔ  ＵＤＰヘッダとＩＰＳＥＣ  ＩＰヘッダ２８のエバリュエーションのみを実行する。
【０００８】
前述のようにトンネルを通じて情報を送るとトンネル処理されたコンテンツの適したＱｏＳの提供を複雑化する。マルチシステムオペレータ（ＭＳＯ、例：ケーブル）ネットワークが図の下方部に図示されており、無線サービスプロバイダネットワーク（本例ではスプリント）が図の上方部に図示されている図２で示すネットワーク構造を考察する。図２はＭＳＯネットワークを通ってデュアルモードフォン３０からスプリントネットワークまでのセッションのためのＱｏＳをリクエストするのに必要なステップを図示する。
【０００９】
第１ステップ［１］ではクライエントは自身を証明するためにそのアドレスＩＰｍｐを使用してＳＩＰエッジプロキシ３２にシグナルする。
【００１０】
第２ステップ［２］ではＳＩＰエッジプロキシ３２は加入者フォン３０の識別子としてＩＰｍｐを利用してモバイルネットワークのＰＳ３４にシグナルする。
【００１１】
第３ステップ［３］ではＰＳ３４はＭＳＯネットワークのどこにピアＰＳ３６が存在するかを（アドレスＩＰｍｐを利用して）調べる。この機能を実行する最も簡単な方法は特定ピア処理ＰＳに関連するサブネットのリストにそのアドレスをマップ処理することである。この情報はそのＰＳで形成され、あるいはネットワークから学習することができる。モバイルネットワークのＰＳ３４はクライエントを識別するためにＩＰｍｐを使用してＭＳＯネットワークの正しいＰＳ３６にＱｏＳポリシーリクエストをシグナルする。
【００１２】
第４ステップ［４］ではケーブルネットワークのＰＳ３６はＣＭＴＳ３８へのメッセージをコントロール（加入者/クライエントがその背後に位置するデバイス）および発給するために正しいケーブルモデムターミネーションシステム（ＣＭＴＳ）３８（またはエッジデバイス）を識別する。
【００１３】
第５ステップ［５］ではＣＭＴＳ３８（またはエッジデバイス）はアクセスネットワーク（本例ではＤＯＣＳＩＳネットワーク）によりメディアトラフィックのためのＱｏＳに影響を及ぼすためにＷｉＦｉアクセスポイント４０でホームのケーブルモデムにより適した信号を発信する。
【００１４】
第６ステップ［６］ではデュアルモードフォン３０のためのメディアストリームは来訪アクセスネットワーク（すなわちＭＳＯネットワーク）をＱｏＳによりトラバースする。このメディアストリームはＩＰｍｐアドレスを使用してＣＭＴＳ３８により識別される（メディアストリームと関連するパケットがパケットのＩＰヘッダのソースＩＰアドレスとしてＩＰｍｐを有するであろう）。
【００１５】
上述の例はスプリントネットワーク（デュアルモードフォンのホームネットワーク）にトンネル処理を利用することなく来訪ＭＳＯネットワークを介してアクセスする。これら２つのネットワークをトラバースするパケットは、どのネットワークをそれらが通過するかには関係なく同一ヘッダ情報（すなわちクライエントＩＰヘッダ）を使用し、スプリントネットワークのＳＩＰプロキシ３２は、パケットのクライエントＩＰヘッダを単純に識別することで来訪ネットワークを通じてどのパケットが増強ＱｏＳを提供されるかをピアポリシーサーバ３６に通知する。
【００１６】
来訪ネットワークを通じてパケットを伝達するためにトンネル処理を利用するネットワーク環境にＱｏＳを提供するとさらに複雑化する。なぜなら来訪ネットワークを通じてパケットを伝達するのに利用される封入ヘッダは典型的には図１に関して解説するようにパケットの根底クライエントＩＰヘッダではないからである。ＳＩＰプロキシ３２がパケットを受領したとき、封入ヘッダはパケットから既に剥ぎ取られている。一方、ピアポリシーサーバ３６と根底ケーブルＭＳＯ訪問/サービスネットワークはそのセッションと関係するパケットを封入/トンネルヘッダと同一視する。来訪ネットワークは典型的にはパケット内部のヘッダを認識しておらず、トンネルヘッダに基づいてセッションで作動するだけである。ＳＩＰプロキシ３２は根底クライエントＩＰヘッダのアドレスを使用してスプリントネットワークのポリシーサーバ３４にシグナルする（トンネルアドレスを有していないため）。スプリントポリシーサーバはクライエントのアドレスをケーブルＭＳＯポリシーサーバ３６にシグナルする。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
しかしこのアドレスはトンネルＩＰアドレスとは異なり、そのセッションのためにＱｏＳを増強する任務を担う正しいエッジデバイス/ＣＭＴＳをポリシーサーバ３６に識別させる正しい情報を提供せず、エッジデバイスもクライエントのセッションと関係するパケットを正しく識別できない。
【課題を解決するための手段】
【００１８】
本願は２００６年７月１７日出願の米国仮特許願６０/８０７５３５の優先権を主張する。
【００１９】
解説した実施例はＩＰトンネルに封入されているＩＰ利用メディアセッションのためにＱｏＳの搬送を可能にする。トンネルを提供するネットワークのポリシーサーバはパケットのペイロードの内部アドレスと、トンネルと関係する外部ＩＰアドレスとの間で適切なマップ処理を実行する。解説された実施例はトンネルに封入されているセッションのためにＱｏＳを適用する。これら実施例はクライエントの内部アドレスをマップ処理することで外部トンネルアドレス（来訪ネットワークで経路化可能なアドレス）にＱｏＳを適用するための正しいポリシーサーバおよび正しいＣＭＴＳ/エッジデバイスを来訪ネットワーク内で発見する。
【００２０】
解説された実施例は電話がかけられたときのみアドレストランスレーションを提供してＱｏＳポリシーを適用し、ＶｏＩＰまたは類似したセッションが非作動状態であるときにトンネルで無駄になるＱｏＳリソースの必要性を軽減する。
【００２１】
トンネルは長時間確立可能であるがＱｏＳポリシーはボイスコールが作動中のときのみ作動する。これはコールセットアップ中にＳＩＰシグナルがイニシエートされたときにＱｏＳポリシーがトリガーされるからである。コールが終了するとクライエントはコールが終了したことをシグナルするためにＳＩＰエッジプロキシでＳＩＰシグナルを実行する。このシナリオではＳＩＰエッジプロキシはポリシーサーバで分解メッセージを発行し、ＶｏＩＰコールのためにリソースリザベーションの分解をトリガーする。分解が完了するとＱｏＳリザベーションは破棄され、トンネルはＱｏＳイネーブル状態を終了する。
【００２２】
特徴では本発明はクライエントから第１ネットワークへのセッションへＱｏＳを提供する方法を含む。このセッションはクライエントと第１ネットワークの間で第２ネットワークを通過する。この方法はクライエントから第１ネットワークへのセッションで伝達されるデータパケットの提供を含む。このデータパケットはパケットを経路化するためにパケットヘッダを含む。この方法はさらにそれぞれのデータパケットを封入ヘッダを有する封入パケットに挿入し、第２ネットワークを介してその封入パケットを第１ネットワークへ伝達し、第２ネットワークを介してトンネルを形成する。この方法はまた第１ネットワークの終了デバイスにて封入パケットを受領する。この終了デバイスはデータパケットを回復するために封入ヘッダを取り除く。この方法はさらに回復データパケットのパケットヘッダとトンネルを介してデータパケットを運搬するのに使用される封入ヘッダとの間の関係を決定し、ＱｏＳを必要とするデータパケットのセッションを識別し、ＱｏＳを必要とするデータパケットのセッションに対応する封入パケットを識別するためにその関係を使用する。この方法はさらにトンネルを介して伝達されているＱｏＳを必要とするデータパケットのセッションに対応してＱｏＳを封入パケットに適用する。
【００２３】
１実施例ではさらに回復データパケットのパケットヘッダとトンネルを介してデータパケットを運搬するのに使用される封入ヘッダとの間の関係を保存する。
【００２４】
別実施例ではさらに第１ネットワークのＱｏＳを必要とするデータパケットのセッションを識別し、その識別に対応して第２ネットワークに対して封入パケットにＱｏＳを適用する必要性を伝達する。
【００２５】
１実施例ではピアポリシーサーバはＱｏＳを封入パケットに適用するその必要性を伝達する。
【００２６】
別実施例ではさらにデータパケットのセッションがＱｏＳを必要としなくなったとき封入パケットからＱｏＳを引き出す。
【００２７】
１実施例ではさらに終了デバイスがパケットヘッダのアドレストランスレーションを提供する。
【００２８】
別の特徴では本発明はクライエントから第１ネットワークへのセッションへＱｏＳを提供する方法を含む。このセッションはクライエントと第１ネットワークとの間で第２ネットワークを通過する。この方法は第２ネットワークを通過してトンネルを形成する。このトンネルを通過するセッションのデータパケットは封入パケットを形成するために封入される。この方法はまたセッションがＱｏＳを必要とするときのみトンネルへＱｏＳを適用する。
【００２９】
１実施例ではさらに第１ネットワークの終了デバイスにて封入パケットを受領する。この終了デバイスはデータパケットを回復するために封入パケットのヘッダを取り除く。この方法はさらに回復データパケットのパケットヘッダとトンネルを介してデータパケットを運搬するのに使用される封入ヘッダとの間の関係を決定し、ＱｏＳを必要とするデータパケットの特定セッションを識別し、ＱｏＳを必要とするデータパケットのセッションに対応する封入パケットを識別するためにその関係を使用する。この方法はさらにトンネルを通して運搬されているＱｏＳを必要とするデータパケットのセッションに対応する封入パケットにＱｏＳを適用する。
【００３０】
１実施例ではさらに封入パケットにＱｏＳを適用する必要性を通信するためにピアポリシーサーバを提供する。
【００３１】
別実施例ではさらにデータパケットのセッションがＱｏＳを必要としなくなったときに封入パケットからＱｏＳを引き出す。
【００３２】
別の特徴によれば本発明はさらにクライエントから第１ネットワークへのセッションにＱｏＳを提供する方法を含む。このセッションはクライエントと第１ネットワークとの間で第２ネットワークを通過する。この方法はこのセッションを伝達するために第２ネットワークを通過させてトンネルを形成する。このトンネル内のセッションのパケットは封入パケットを形成するために封入される。この方法はさらにＱｏＳをトンネル内の封入パケットに適用する。
【００３３】
１実施例ではさらに第２ネットワークのトンネルのターミナルエンドで封入パケットを受領し、封入パケットからセッションのパケットを抽出し、セッションからのパケットがＱｏＳを必要とすることを決定し、トンネルを維持する任務を担う第２ネットワーク内のネットワークコンポーネントを識別し、トンネルへＱｏＳを適用する必要性をネットワークコンポーネントに伝達する。
【００３４】
別実施例ではさらにセッションのパケットを含む封入パケットに関してセッションのパケットのヘッダをマップ処理し、そのマップ処理をトンネルを維持する任務を担う第２ネットワークのネットワークコンポーネントに伝達する。
【００３５】
別な特徴によれば本発明はクライエントから第１ネットワークへのセッションへＱｏＳを提供するシステムを含む。このセッションはクライエントと第１ネットワークとの間で第２ネットワークを通過する。このシステムはクライエントデバイスから第１ネットワークへセッションに伝達されるデータパケットを提供するクライエントデバイスを含む。このデータパケットはパケットを経路化するパケットヘッダを含む。このシステムはそれぞれのデータパケットを封入ヘッダを有した封入パケットに挿入し、封入パケットを第２ネットワークを介して第１ネットワークに伝達し、第２ネットワークを介してトンネルを形成するための封入モデュールをさらに含む。このシステムはさらに封入パケットを受領するため第１ネットワーク内に終了デバイスを含み（この終了デバイスはデータパケットを回復するために封入ヘッダを取り除く）、回復データパケットのパケットヘッダとトンネルを通過してデータパケットを伝達するのに使用される封入ヘッダとの間の関係を決定する。このシステムは、（ｉ）ＱｏＳを必要とするデータパケットのセッションを識別し、ＱｏＳを必要とするデータパケットのセッションに対応する封入パケットを識別するためにその関係を使用し、（ｉｉ）トンネルを通過して伝達されるＱｏＳを必要とするデータパケットのセッションに対応してＱｏＳを封入パケットに適用するためのポリシーサーバをさらに含む。
【００３６】
１実施例では回復データパケットのパケットヘッダと封入ヘッダとの間の関係はメモリデバイスに保存される。
【００３７】
１実施例ではさらにトンネルにＱｏＳを適用するのに要求される機能を実行するために第２ネットワークにピアポリシーサーバを含む。
【００３８】
別実施例では第１ネットワークは無線サービスプロバイダネットワークであり、第２ネットワークはケーブルＭＳＯネットワークである。
【００３９】
別実施例では終了デバイスはホームエージェントサーバである。
【００４０】
別実施例ではパケットヘッダと封入ヘッダはＩＰヘッダである。
【００４１】
さらに別実施例では例えばコンボフォンであるマルチモードデバイスはトンネルのクライエントエンドでトンネル形成および終了機能を実行し、ホームエージェントサーバはトンネルの第１ネットワークエンドでトンネル形成および終了機能を実行する。
【図面の簡単な説明】
【００４２】
本発明の前述および他の目的、様々な特徴、並びに本発明自体を添付の図面を利用して以下にて詳細に解説する。
【図１】図１は解説されている態様に従ってトンネルを形成するのに使用される一般的なパケットフォーマットを図示する。
【図２】図２はトンネル処理なしでデュアルモードのフォンからセッションのためのＱｏＳをリクエストするのに必要なステップを図示する。
【図３】図３は本発明の１実施例に従って来訪ネットワークを介したトンネル用ＱｏＳを提供するための例示的ネットワーク構造を図示する。
【図４】図４は図３で図示するトンネルでＱｏＳを取り除くのに必要な分解手法を図示する。
【発明を実施するための形態】
【００４３】
図３は本発明の１実施例による来訪ネットワークを介したトンネル用ＱｏＳの提供のための例示的ネットワーク構造を図示する。
【００４４】
ホームネットワーク３４のピアポリシーサーバにＱｏＳポリシーを来訪ネットワーク内で効果的に適用させるため、ホームネットワーク３４のポリシーサーバが、ＳＩＰエッジプロキシ３２からの信号リクエストで受領したクライエントのＩＰアドレスに参照された（封入ヘッダからの）トンネルのＩＰアドレスを決定する。このためにピアポリシーサーバ３４はトンネルのターミナルエンドのトンネル終了デバイス（図３のホームエージェントサーバＨＡ４２）と通信する。これは、ａ）トンネルパケットから外部封入ヘッダを取り除き、“ネイティブ”パケットを、モバイルクライエントから提供され、モバイルネットワークのためのパケットのモバイルネットワーク内の目的地に逆方向に送り（すなわちトンネル終了機能）、ｂ）モバイルネットワークからのＩＰパケットを、来訪ネットワークを通じてモバイルネットワークからクライエントへトラバースするパケットのトンネルヘッダで封入する（すなわちトンネル形成機能）。
【００４５】
モバイルクライエント３０はトンネルの他端であってもよい（ここでモバイルクライエントが同様の機能を実行し、モバイルネットワークからクライエントのパケットのために、クライエントが、パケットにクライエントのアプリケーションへの正確なアドレス（ＩＰｍｐ）を提示する前にトンネルヘッダをパケットから剥ぎ取る）。逆方向にトラバースするパケットに対しては、来訪ネットワークを通過するとき、クライエントはパケットに、そして最終的にホームネットワークのトンネル終了デバイスまで封入ヘッダを追加する任務を担う。あるいはホームネットワーク内の外部デバイス（例：ＷｉＦｉゲートウェイ）もまたトンネル封入/脱封入機能を実行できるであろう。
【００４６】
図３はＭＳＯネットワークを介してデュアルモードフォン３０からスプリントネットワークまでのセッションのためのＱｏＳをリクエストするのに必要なステップを図示する。図３のステップは、図３ではＭＳＯネットワークを介してトンネルを提供する点を除いて図２のステップと類似している。
【００４７】
図３の第１ステップ［１］ではリンクのクライエントサイド（デュアルモードフォン３０のサイド）はトンネル終了ポイント（本例ではＨＡ４２）でトンネルを確立する。デュアルモードフォン３０からスプリントネットワークへの全てのトラフィックはトンネル内に封入される。トンネル終了デバイス４２はトラフィックの方向に応じて“パケットのための封入ヘッダの“剥ぎ取り”または挿入の任務を担う。
【００４８】
第２ステップ［２］ではトンネル終了デバイス（または本例ではＨＡ４２）は、モバイルネットワーク内のスプリントポリシーサーバ３４に、トンネルエンドポイントのＩＰアドレス（本例ではＩＰｎａｔ、ＩＰｈａ）へのデュアルモードフォンのＩＰアドレス（本例ではＩＰｍｐ）のマップ処理について通知する任務を担う。このマップ処理情報は決定され、外部ヘッダ（封入ヘッダ）がトンネルのターミナルエンドで取り除かれるときにメモリデバイスに保存される。
【００４９】
第３ステップ［３］では、クライエント（デュアルモードフォン３０）はＳＩＰエッジプロキシ３２に必要なＱｏＳに関してシグナルする。パケットはトンネルを通過し、トンネルを（スプリントネットワークのＨＡ４２を介して）出て、スプリントネットワークのＳＩＰプロキシ３２に到達する。ＳＩＰエッジプリキシ３２はその後にスプリントポリシーサーバ（ＰＳ）３４にシグナルする。ＳＩＰエッジプロキシ３２がクライエントから信号メッセージを受領するとき、封入ヘッダはＨＡ４２から既に取り除かれているため、ＳＩＰエッジプロキシ３２はトンネルのアドレスについての情報を有していない。封入ヘッダが取り除かれると、ＳＩＰエッジプロキシ３２はクライエントのアドレス‐ＩＰｍｐのみを有している。ＳＩＰエッジプロキシ３２は、クライエントを識別するためＩＰｍｐを用いてスプリントＰＳ３４にＱｏＳに関してシグナルする。
【００５０】
第４ステップ［４］ではスプリントＰＳ３４はＳＩＰエッジプロキシ３２からＱｏＳリクエストシグナルを受領する。スプリントＰＳ３４はＩＰｍｐを対応するトンネルアドレスへマップ処理する。ステップ２においてスプリントＰＳ３４がＨＡ４２から受領した、封入ヘッダをクライエントヘッダに関連付ける情報（すなわち前述した保存されたマップ処理情報）を利用して、スプリントＰＳ３４はＩＰｍｐの検索を実行して関連するＩＰｎａｔ、ＩＰｈａ情報を発見する。この情報を利用してスプリントＰＳ３４は対応するケーブルＰＳ３６（すなわちＰＣＭＭポリシーサーバ）を発見し、ＱｏＳを必要とするセッションを識別するためにアドレスＩＰｎａｔ、ＩＰｈａを利用してケーブルＰＳ３６をシグナルする。
【００５１】
］第５ステップ［５］では、スプリントＰＳ３４はＱｏＳを必要とするセッションを識別するためにＩＰｎａｔとＩＰｈａを利用してケーブルＰＳ３６にシグナルする。ケーブルＰＳ３６はその背後に加入者が配置されている正確なＣＭＴＳ/エッジデバイス３８を識別し、ＣＭＴＳ３８にシグナルする。
【００５２】
第６ステップ［６］では、ケーブルＰＳ３６は必要なＱｏＳに関するＣＴＭＳ３８（またはエッジデバイス）へメッセージを発信する。
【００５３】
第７ステップ［７］では、ＣＭＴＳ３８（またはエッジデバイス）はアクセスネットワーク（すなわちＭＳＯネットワーク）でトンネルのための必要なＱｏＳに影響を及ぼすためにホーム内のケーブルモデムに適切な信号を発信する。デュアルモードフォンクライエント３０のための実際のトラフィックはトンネル内で伝達されているため、その実際のトラフィックは本質的にトンネルに適用されている特別な処置を受ける。
【００５４】
第８ステップではメディアは現在ＱｏＳイネーブル状態のトンネルを通過する。
【００５５】
図３に示す前述の実施例に関するコールフロー情報の詳細について以下に説明する。
【００５６】
１．ＩＰｓｅｃトンネルを創出するため、ＭＰがＨＡでＩＫＥを開始する。
・ＩＫＳとＳＩＰストリームがＣＴＭＳとＭＴＡ（ＮＡＴルーター＋ＷｉＦｉＡＰ）との間でデフォルトＳＦｓを介して運搬される。
・ＮＡＴルーターがＭＰのＩＰｓｅｃトンネルＩＰアドレスとＵＤＰポートを（ＩＰｎａｔ、ＩＰｈａ）にトランスレートする。
【００５７】
２．ＨＡがＩＰｓｅｃトンネル情報をＩＰｍｐのスプリントＰＳに送る。
・ＩＰｍｐ：（ＩＰｎａｔ、ＩＰｈａ、Ｐｎａｔ、Ｐｈａ）
【００５８】
３．ＭＰがトンネル＆ＳＢＣを介してＳＩＰセッションをエッジプロキシで開始する。
【００５９】
４．ＩＰｍｐとＩＰｍｇとの間のＲＴＰメディアストリームのためにＳＩＰコールセットアップが開始する。
・ＳＢＣがＭＰのためにＲＴＰメディアＱｏＳリクエストをスプリントＰＳへＴＯＳとＢＷ要求：ＩＰｍｐ：（ＴＯＳ、ＢＷ）と共にＩＰｍｐに送る。
【００６０】
５．スプリントＰＳが加入者ＩＰｎａｔのためにクリエイトＱｏＳリクエスト（ＣＯＰＳメッセージ）をＭＳＯ’ｓ  ＰＣＭＭ  ＰＳに送る。
・ＩＰｎａｔ：（ＩＰｈａ、ＴＯＳ、Ｐｎａｔ、Ｐｈａ、ＢＷｕｓ、ＢＷｄｓ）
【００６１】
６．ＰＣＭＭ  ＰＳが加入者ＩＰｎａｔのために２ＣＯＰＳ  ＧＡＴＥ  ＳＥＴリクエストをＣＭＴＳに送る。
・ＩＰｎａｔのためのＵＳゲート：クラシファイア（ＩＰｈａ、ＩＰｎａｔ、ＴＯＳ、Ｐｈａ、Ｐｎａｔ）、フロースペック（ＢＷｕｓ）
・ＩＰｎａｔのためのＤＳゲート：クラシファイア（ＩＰｎａｔ、ＩＰｈａ、ＴＯＳ、Ｐｎａｔ、Ｐｈａ）、フロースペック  ＢＷｄｓ）
【００６２】
７．ＣＭＴＳが加入者ＩＰｎａｔのためにＤＯＣＳＩＳ  ２．０ダイナミックサービスアッド（ＤＳＡ）リクエストをホストＭＴＡに送る。
・ＵＳダイナミックＳＦ：クラシファイア（ＩＰｈａ、ＩＰｎａｔ、ＴＯＳ、Ｐｈａ、Ｐｎａｔ）、ＱｏＳ  パラム（フロースペック（ＢＷｕｓ））
・ＤＳダイナミックＳＦ：クラシファイア（ＩＰｎａｔ、ＩＰｈａ、ＴＯＳ、Ｐｎａｔ、Ｐｈａ）、ＱｏＳ  パラム（フロースペック（ＢＷｕｓ））
・ＲＴＰメディアストリームＳＦｓはＣＴＭＳとＭＴＡとの間で現在作動中である‐ＳＩＰストリームはデフォルトＳＦｓに残る。
【００６３】
８．ＲＴＰメディアストリームがＩＰｓｅｃトンネルとＳＢＣとを介し、ＣＭＴＳとＭＴＡとの間のダイナミックＳＦｓを利用して、ＭＰとＭＧとの間で開始する。
【００６４】
図４は、図３で示すようにセットアップされたトンネルのＱｏＳを取り除くのに必要な分解手法を図示する。
【００６５】
（前述のセットアップ手法の第８ステップに引き続く）第９ステップ［９］では、ＳＩＰコール分解がＲＴＰメディアストリームのためにＩＰｍｐとＩＰｍｇとの間で開始する。
【００６６】
［００６１］第１０ステップ［１０］では、ＳＢＣエッジプロキシ４４はＴＯＳとＢＷ要求と共にＲＴＰメディアＱｏＳ分解リクエストをＩＰｍｐのＭＰのためのスプリントＰＳ３４へ送る：ＩＰｍｐ：ＩＰｍｐ：（ＴＯＳ、ＢＷ）。
【００６７】
第１１ステップ［１１］では、スプリントＰＳ３４はディリートＱｏＳリクエスト（ＣＯＰＳメッセージ）を、加入者ＩＰｎａｔ［ＩＰｎａｔ：（ＩＰｈａ、ＴＯＳ、Ｐｎａｔ、Ｐｈａ、ＢＷｕｓ、ＢＷｄｓ）］のためにＭＳＯネットワークのＰＣＭＭ  ＰＳ  ３６へ送る。
【００６８】
第１２ステップ［１２］では、ＰＣＭＭ  ＰＳ  ３６は２つのＣＯＰＳ  ＧＡＴＥ  ＤＥＬリクエストを、加入者ＩＰｎａｔのためにＣＭＴＳ３８に送る。（ＩＰｎａｔのＵＳゲート：クラシファイア（ＩＰｈａ、ＩＰｎａｔ、ＴＯＳ、Ｐｈａ、Ｐｎａｔ）、フロースペック（ＢＷｕｓ）；ＩＰｎａｔのＤＳゲート：クラシファイア（ＩＰｎａｔ、ＩＰｈａ、ＴＯＳ、Ｐｎａｔ、Ｐｈａ）、フロースペック  ＢＷｕｓ））
【００６９】
第１３ステップ［１３］では、ＣＴＭＳ３８は２つのＤＯＣＳＩＳ２．０ダイナミックサービスディリート（ＤＳＤ）リクエストを加入者ＩＰｎａｔ（ＵＳダイナミックＳＦ：クラシファイア（ＩＰｈａ、ＩＰｎａｔ、ＴＯＳ、Ｐｈａ、Ｐｎａｔ）、ＱｏＳパラム（フロースペック（ＢＷｕｓ））；ＤＳダイナミックＳＦ：クラシファイア（ＩＰｎａｔ、ＩＰｈａ、ＴＯＳ、Ｐｎａｔ、Ｐｈａ）、ＱｏＳパラム（フロースペック（ＢＷｄｓ）））のためにホストＭＴＡに送る。ＲＴＰメディアストリームＳＦｓはＣＭＴＳ３８とＭＴＡとの間で終了する。ＳＩＰストリームとＲＴＰメディアストリームのクリーンアップはデフォルトＳＦｓに残る。
【００７０】
最終的に第１４ステップで、ＲＴＰメディアストリームはＭＰ３０とＭＧとの間で取り除かれる。
【００７１】
本発明をその精神または本質的特徴から逸脱することなく、その他の特定形態で実施することもできる。したがって説明した実施例は例示的なもので本発明を制限することなく、本発明の範囲は前述の説明よりもむしろ「請求の範囲」によって定義され、「請求の範囲」内の全ての変更は本発明の範囲に含まれる。
【図１】
2009544227.tif 000003
【図２】
2009544227.tif 000004
【図３】
2009544227.tif 000005
【図４】
2009544227.tif 000006
【国際調査報告】
2009544227.tif 000007