(57)【要約】  通信ネットワークにおいてパケット・フローに動的な変化を与えるシステムおよび方法について記載する。動的な変化は、サービス品質（ＱｏＳ）の格上げおよび格下げ、ストリームの受信デバイスへの適応化、エア・インターフェースにおいて変化を相殺するためのストリームの修正、および技術間ハンドオーバーに対処するためのストリームの修正を含むことができる。これらの変化は、ゲートウェイにおいてパケットを検査し、マルチメディア・ストリーム・パケット・フローに合わせてプロキシを確定することによって得ることができる。プロキシは、ストリームを変化させるために行われるコード変換を調整することができる。また、ゲートウェイはリアル・タイム制御プロトコルおよびその他の適用可能なプロトコルを用いて、移動体ノードにおいて条件を監視することもできる。【選択図】      図５
2010512694.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおけるゲートウェイであって、
前記ゲートウェイ内に常駐し、メディア・ストリームのセットアップに関する情報についてパケットを検査するプロキシ・インスタンスと、
前記ゲートウェイ内に常駐し、メディア・ストリーム・パラメータを設定するために移動体ノードとセッションを取り決め、前記移動体ノードから受信するフィードバックを監視し、コード変換を管理するインライン・サービスと、
前記ゲートウェイ内に常駐し、メディア・ストリームに対してコード変換を行うディジタル信号プロセッサ（ＤＳＰ）と、
を備えている、ゲートウェイ。
【請求項２】
請求項１記載のゲートウェイにおいて、
前記プロキシ・インスタンスは、セッションの前記セットアップのためにリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）パケットを検査し、
前記インライン・サービスは、前記移動体ノードからのフィードバックについて、リアル・タイム制御プロトコル（ＲＴＣＰ）パケットを検査する、
ゲートウェイ。
【請求項３】
請求項１記載のゲートウェイであって、更に、前記プロキシ・インスタンスが、メディア・ストリームのセットアップを検出し、前記メディア・ストリームをインライン・サービスに通過させるように、受信したメッセージを修正し、前記メディア・ストリームを管理するためにインライン・サービスを確定する、ゲートウェイ。
【請求項４】
移動体ノードへのメディア・ストリームのセットアップを検出するためにパケットを検査するステップと、
前記メディア・ストリームをインライン・サービスに通過させるように、セットアップ・メッセージを修正するステップと、
前記移動体ノードから受信するフィードバックを監視するステップと、
前記メディア・ストリームに対する修正を決定するためにフィードバックを分析し、ディジタル信号処理（ＤＳＰ）エンジンを管理するステップと、
を備えている、方法。
【請求項５】
請求項４記載の方法において、メディア・ストリームのセットアップを検出するためにリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）パケットを検査し、前記移動体ノードからフィードバックを取得するためにリアル・タイム制御プロトコル（ＲＴＣＰ）パケットを監視する、方法。
【請求項６】
請求項４記載の方法であって、更に、
メディア・ストリームにおいて受信したコンテンツのパラメータを判定するステップと、
前記移動体ノードの処理能力に適したコンテンツを提供するために、前記メディア・ストリームをコード変換するステップと、
を備えている、方法。
【請求項７】
請求項４記載の方法であって、更に、
ポリシーおよび課金規則機能（ＰＣＲＦ）から命令を受信するステップと、
前記移動体ノードに配信するサービス品質（ＱｏＳ）を動的に変化させるステップと、
を備えている、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願に対する相互引用
本願は、２００６年１２月７日に出願した、"Apparatus and Method for Providing a Call Session Control Function"（呼セッション制御機能を提供する装置および方法）と題する米国仮特許出願第６０／８７３，４９３号の、３５Ｕ．Ｓ．Ｃ．§１１９（ｅ）に基づく優先権を主張するものである。この特許出願の内容は、ここで引用したことにより、その全体が本願にも含まれるものとする。
開示の分野
本開示は、通信ネットワークにおいて、パケット・フローに動的変化を与えるシステムおよび方法に関するものである。
【従来技術】
【０００２】
ワイヤレス通信システムおよびネットワークは、例えば、衛星通信システム、携帯ディジタル・アシスタント（ＰＤＡ）、ラップトップ・コンピュータ、およびセルラ電話機を含む多くの用途と共に用いられている。このような用途のユーザが受ける重要な恩恵の１つに、ユーザがこのようなワイヤレス通信システムの範囲内にいる限りは、ネットワーク（例えば、インターネット）に接続することができる、ということがあげられる。
【０００３】
現在のワイヤレス通信システムは、回線交換およびパケット交換のいずれか、またはその組み合わせを用いて、移動体ノードにモバイル・データ・サービスを提供している。移動体ノードとは、セル・フォン、ＰＤＡ、ブラックベリー(Blackberry)、ワイヤレス・カードを有するラップトップ・コンピュータ、またはその他のいずれのワイヤレス・デバイスとすることもできる。一般的に言うと、回線型手法では、ワイヤレス・データは、データの送出元と受信先との間で、物理スイッチング・パスを用いて、専用（および継続）接続によって搬送される。一旦直接接続を確定すれば、送出元および受信先が交換するデータを有する限り、それが維持される。このような直接かつ専用のスイッチング・パスを確立すると、接続を閉じるまではネットワーク・リソースの一定の配分量が拘束されることになる。送出元と受信先との間において物理的接続がもはや望ましくなくなったなら、それを解除(teardown)してネットワーク・リソースを他のユーザに必要に応じて割り当てる。
【０００４】
パケット型手法は、一方、送信リソースを所与の呼に永続的に割り当てることはせず、データの送出元と受信先との間における物理的接続のセットアップ（確定）およびティアダウン（解除）を必要としない。一般に、パケット型手法におけるデータ・フローは「パケット化」されており、データは別個の情報セグメントに分割され、各セグメントは「ヘッダ」情報を受信する。「ヘッダ」情報は、例えば、発信元情報、宛先情報、パケット内にあるビット番号に関する情報、優先順位情報、およびセキュリティ情報を提供することができる。次いで、ヘッダ情報に基づいて、パケットを独立して宛先にルーティングする。パケット・フローは、多数のパケットまたは１つのパケットを含む場合もある。サービスは、合法的傍受（ｌａｗｆｕｌ  ｉｎｔｅｒｃｅｐｔｉｏｎ）（傍受：wire tapping）、バーチャル・プライベート・ネットワーク（ＶＰＮ）、およびファイアウオールというような、パケット・フローに適用することができる。
【０００５】
パケット型通信の発展の一部は、ＩＰマルチメディア・サブシステム（ＩＭＳ）の開発であった。ＩＭＳは、インターネット・プロトコル（ＩＰ）マルチメディアを移動体ノードに配信するためのアーキテクチャ・フレームワークである。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳコアにおいて生ずるシグナリングの多くを管理することができる。ＣＳＣＦ機能性は、論理的に３つの機能性、プロキシ−ＣＳＣＦ（Ｐ−ＣＳＣＦ）、インターロゲーテリングＣＳＣＦ（Ｉ−ＣＳＣＦ）、およびサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）に分割することができる。加えて、ＣＳＣＦ機能性の構想には、２つの異なるトポロジに含ませるために、モバイル通信向けグローバル・システム（ＧＳＭ；Global System for Mobile Communications）およびＣＤＭＡ２０００という２つの異なるグループがある。第三世代パートナーシップ・プロジェクト（３ＧＰＰ）は、ＧＳＭシステムで作動するＩＭＳを担当し、第三世代パートナーシップ・プロジェクト２（３ＧＰＰ２）は、ＣＤＭＡシステムと共に用いられ３ＧＰＰ  ＩＭＳの概念に基づくマルチメディア・ドメイン（ＭＭＤ）を担当する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＶｏＩＰ、ストリーミング・メディア、ゲーム等のようなアプリケーションを起動して移動体ノードに伝えるために、ユーザに対するサービス・レベルを保証することをネットワークが目指しているため、著名性を獲得している別の側面としてサービス品質（ＱｏＳ）がある。ＱｏＳは、あるレベルの帯域幅を、配信プロセスのある時点におけるデータ・フローに供給することによって作用するのが通例である。これがうまくいくのは、ワイヤライン・ネットワーク上において、情報の送信がほぼ一定である場合である。しかしながら、送信媒体がさほど信頼できない場合、ＱｏＳは干渉やフェーディングのような条件によっては、ユーザに実際のレベルのサービスを提供し損なう可能性がある。
【課題を解決するための手段】
【０００７】
通信ネットワークにおいてパケット・フローに動的変化を与えるシステムおよび方法を開示する。一部の実施形態では、マルチメディア・セッションに対して、適応したサービス品質（ＱｏＳ）をリアル・タイムで提供し、より良いユーザ体験を提供するために当該セッションを監視し、管理することができる。ある種の実施形態では、通信ネットワークにおけるゲートウェイは、ゲートウェイ内に常駐し、メディア・ストリームのセットアップに係る情報についてパケットを検査するプロキシ・インスタンスと、ゲートウェイ内に常駐し、メディア・ストリーム・パラメータを設定するために移動体ノードとのセッションを取り決め、移動体ノードから受信するフィードバックを監視し、コード変換を管理するインライン・サービスと、ゲートウェイ内に常駐しメディア・ストリームに対してコード変換を行うディジタル信号プロセッサ（ＤＳＰ）とを含む。
【０００８】
実施形態の中には、移動体ノードへのメディア・ストリームのセットアップを検出するためにパケットを検査するステップと、メディア・ストリームをインライン・サービスに通過させるように、セットアップ・メッセージを修正するステップと、移動体ノードから受信するフィードバックを監視するステップと、メディア・ストリームに対する修正を決定するためにフィードバックを分析し、ディジタル信号処理（ＤＳＰ）エンジンを管理するステップとを含む方法もある。
【図面の簡単な説明】
【０００９】
【図１】図１は、ある種の実施形態によるＩＰマルチメディア・サブシステム（ＩＭＳ）アーキテクチャを示すブロック図である。
【図２】図２は、ある種の実施形態によるマルチメディア・ドメイン（ＭＭＤ）アーキテクチャを示すブロック図である。
【図３】図３は、ある種の実施形態による、移動体ノードへのストリーミング・メディアの配信を示すブロック図である。
【図４】図４は、ある種の実施形態によるメディア・ストリームのセットアップおよびティアダウンを示すシグナリング・フローである。
【図５】図５は、ある種の実施形態によるメディア・ストリームの動的管理の提供を示すブロック図である。
【図６】図６は、ある種の実施形態にしたがって、メディア・ストリームの動的管理を提供するためのゲートウェイ内におけるメカニズムを示すブロック図である。
【図７】図７は、ある種の実施形態によるメディア・ストリームの動的管理を示すシグナリング・フローである。
【図８】図８は、ある種の実施形態によるアクセス・ネットワークにわたるメディア・ストリームの動的管理を示すブロック図である。
【図９】図９は、ある種の実施形態による、デバイス・ハンドオーバー中におけるメディア・ストリームの動的管理を示すブロック図である。
【図１０】図１０は、ある種の実施形態にしたがってゲートウェイ上で走るモジュールを示すブロック図である。
【発明を実施するための形態】
【００１０】
通信ネットワークにおいてメディア・ストリームに動的変化を加えるシステムおよび方法を、いくつかの実施形態において開示する。ＩＰマルチメディア・サブシステム（ＩＭＳ）およびマルチメディア・ドメイン（ＭＭＤ）アーキテクチャのためのパケット・フローについてサービス品質を実現するためにゲートウェイを用いることができる。ＱｏＳの実施およびＱｏＳの動的適用は、ハードウェアおよびソフトウェアの組み合わせによって行うことができる。１つ以上のネットワーク処理ユニット、ライン・カード、ならびにパケット処理カードおよび音声処理カードを、ゲートウェイ内に実装しておくことができる。ＱｏＳは、通例、配信プロセスにおけるある時点においてデータ・フローに、あるレベルの帯域幅を供給することによって作用する。例えば、データ・パケット配給ノード（ＰＤＳＮ）または同様のネットワーキング機器においてある帯域幅を保証する。この手法を用いたＱｏＳに伴う問題は、エアリンクを通じて移動体ノードに得られる実際の帯域幅が素因(factor)でないことである。無線アクセス・ネットワークまでの距離のために、干渉や信号強度の落下があった場合、フィードバックがないので、ＱｏＳを調節できない。規格によって規定されたＱｏＳメカニズムは静的である。ある種の実施形態では、フィードバックの使用によって、ＩＭＳトポロジおよびＭＭＳトポロジにおいてＱｏＳを動的に提供する。
【００１１】
図１は、一部の実施形態によるＩＰマルチメディア・サブシステム（ＩＭＳ）を示し、ネットワーク・セットアップの論理コンポーネントを示す。図１は、Ｐ−ＣＳＣＦ１１０、Ｉ−ＣＳＣＦ１１２、Ｓ−ＣＳＣＦ１１４、ホーム加入者サーバ（ＨＳＳ）１１６、加入者測位機能（ＳＬＦ）１１８、ユーザ機器（ＵＥ）１２０、ブレークアウト・ゲートウェイ制御機能（ＢＧＣＦ）１２２、メディア・ゲートウェイ制御機能（ＭＧＣＦ）１２４、メディア・ゲートウェイ（ＭＧＷ）１２６、公衆電話交換網（ＰＳＴＮ）１２８、マルチメディア・リソース・コントローラ（ＭＲＦＣ）１３０、およびマルチメディア・リソース機能プロセッサ（ＭＲＦＰ）１３２を含む。ＨＳＳ１１６は、マスタ・ユーザ・データベースであり、Ｓ−ＣＳＣＦまたは呼およびセッションを扱う別のネットワーク実体をサポートする。ＨＳＳ１１６は、ユーザ・プロファイルのような加入に関する情報を格納し、ユーザ認証および許可を実行し、ユーザの物理的ロケーションに関する情報を提供することができる。ネットワークにおいて多数のＨＳＳを用いる場合、この情報を格納するＨＳＳ１１６にクエリを送出するために、ＳＬＦ１１８を用いることができる。旧来のシグナリング・ネットワークも、サービスのためにＨＳＳを用いることができる。ＭＲＦＣ１３０はＳ−ＣＳＣＦ１１４と通信し、メディアに関する機能を実現するようにＭＲＦＰ１３２を制御する。ＭＲＦＣ１３０およびＭＲＦＰ１３２の組み合わせによって、ホーム・ネットワークにおけるメディア・ソースが設けられる。ＢＧＣＦ１２２は、電話番号に基づいてルーティングすることができるサーバであり、回線交換ネットワーク上で発呼するときに用いられる。ＭＧＣＦ１２４およびＭＧＷ１２６は、シグナリングをＩＭＳからＰＳＴＮ１２８回線交換ネットワークに適したそれに変換するために用いられる。ＩＰマルチメディア・サブシステム・ネットワークは、アプリケーション・サーバ、およびサービスをユーザ機器（即ち、移動体ノード）１２０に供給するその他のネットワーク実体を含むことができる。
【００１２】
図２は、上位ネットワークにおけるマルチメディア・ドメイン（ＭＭＤ）システム２１０を示す。ＭＭＤシステム２１０は、図１のＩＭＳシステムと同じ機能の多くを含むが、更に、アクセス・ネットワーク２１４と通信するためのアクセス・ゲートウェイ／外部(foreign)エージェント２１２、および移動局２１８（即ち、移動体ノード）にモバイルＩＰサポートを提供する外部(foreign)エージェント２１６も含む。ポリシー判断機能（ＰＤＦ）を、ＩＭＳまたはＭＭＤネットワークに含むことができ、これはユーザのセッションを統制するポリシーを格納する。オープン・システム・アーキテクチャ（ＯＳＡ）アプリケーション・サーバ２２２およびＳＩＰアプリケーション・サーバ２２４のようなアプリケーション・サーバが、ロケーションに基づくサービス、ビデオ、電子メール、チャット、ゲームのようなアプリケーション、ならびにその他のデータおよびマルチメディア・コンテンツを提供する。
【００１３】
図１および図２に示すように、多数の機能をＩＭＳおよびＭＭＤトポロジに含ませることができる。これらの機能のいくつかは、例えば、ボイス・オーバーＩＰ（ＶｏＩＰ）ルーティング、および改良した請求書発行、ステートフル・ファイアウオール、トラフィック・パフォーマンス最適化（ＴＰＯ）のような高度サービスを提供する際に用いられる。実施形態によっては、これらの機能の１つ以上の、ゲートウェイのような、ネットワークにおける１つの実体によって提供することができる場合もある。また、ＩＭＳおよびＭＭＳトポロジは、ＶｏＩＰ、ストリーミング・ビデオ、ストリーミング・ミュージック、マルチ・ユーザ・ゲーム、ロケーションに基づくサービス、および移動体ノードに配信する種々のコンテンツの提供も可能にする。
【００１４】
図３は、ある種の実施形態による移動体ノードへのストリーミング・メディアの配信を示す。図３は、移動体ノード３１０、無線アクセス・ネットワーク（ＲＡＮ）、ＩＰキャリア・アクセス・ネットワーク（ＩＰＣＡＮ）３１４、アクセス・ゲートウェイ３１６、インターネット３１８、Ｗｅｂサーバ３２０、およびメディア・サーバ３２２を含む。アクセス・ゲートウェイ３１６は、パケット・データ配給ノード（ＰＤＳＮ）、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）、またはその他の適用可能なネットワーク機器とすることができる。ユーザは、彼らの移動体ノード３１０上において、ＨＴＴＰリクエスト記述メッセージ３２４を用いてコンテンツを要求することができる。Ｗｅｂサーバ３２０は、どこでそのコンテンツが位置され得るかを移動体ノード３１０に特定するメッセージ３２４で応答することができる。次いで、移動体ノード３１０は、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）リクエスト３２６をメディア・サーバ３２２に送ることができる。メディア・サーバは、移動体ノード３１０に、レスポンスおよびリアル・タイム・トランスポート・プロトコル・ストリーミング・メディア３２６を供給することができる。
【００１５】
図４は、ある種の実施形態にしたがってストリーミング・メディアを供給する際に関与する通信のシグナリング図を示す。図４は、移動体ノード４１０、インターネット・アクセス・ポイント・ネーム（ＡＰＮ）４１２、Ｗｅｂサーバ４１４、およびメディア・サーバ４１６を含む。インターネットＡＰＮは、例えば、バーチャル・プライベート・ネットワーク（ＶＰＮ）のような、インターネット・サーバである。移動体ノード４１０は、取得メッセージ４１８をインターネットＡＰＮ４１２に送り、ユーザが指定したコンテンツを取得しようとする。インターネットＡＰＮ４１２は、取得メッセージ４２０をしかるべきＷｅｂサーバ４１４に転送する。Ｗｅｂサーバ４１４はＨＴＴＰ２００ＯＫメッセージ４２２を送る。メッセージ４２２は、メッセージ本体に、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）情報を含むことができる。情報メッセージ４２２の一例は次に内容を含むことができる。
v = 0
o = - 2890 2890842807 IN IP4 192.16.24.202
s = RTSP Session
m = audio 0 RTP/AVP 0
a = control:rtsp://audio.com/terminator/audio.en
m = video 0 RTP/AVP 31
a = control:rtsp://video.com/terminator/video
インターネットＡＰＮ４１２は、メッセージ４２２を受信し、メッセージ４２４を移動体ノード４１０に転送する。
【００１６】
ＲＴＳＰメッセージ４２６において、所望のコンテンツに関するセットアップ・リクエストおよび再生リクエストが行われる。インターネットＡＰＮは、セットアップ・リクエストおよび再生リクエストのメッセージ４２６を遂行する、しかるべきメディア・サーバ４１６にメッセージ４２８を転送する。メディア・サーバ４１６は、ＲＳＴＰ２００ＯＫメッセージ４３０を送る。インターネットＡＰＮはメッセージ４３０を受信し、メッセージ４３２をしかるべき移動体ノード４１０に転送する。４３４において、同じ形式のメッセージングを実行して、メディア・サーバ４１６からビデオ・コンテンツを読み出す。メディア・サーバ４１６は、ＲＴＰビデオおよびオーディオを、パケット・フロー４３６によって移動体ノード４１０に送り始める。リアル・タイム制御プロトコル（ＲＴＣＰ）メッセージング４３８を用いると、ＲＴＰパケット・フローに関する帯域外制御情報を提供し、ＱｏＳフィードバックを供給することができる。ＲＴＣＰメッセージング４３８は、移動体ノード４１０においてＱｏＳレベルについてのフィードバックを取得するために、アクセス・ゲートウェイであるインターネットＡＰＮによって監視することができる。ＲＴＣＰメッセージング４３８によって取得されたＱｏＳレベルに応じて、インターネットＡＰＮはメッセージをメディア・サーバに送り、メディア・ストリームのＱｏＳを格上げ（アップグレード）または格下げ（ダウングレード）することができる。
【００１７】
移動体ノードが１００ｋｂｐｓのサービス品質を受けている場合に、移動体ノードに２５０ｋｂｐｓで送られていると、インターネットＡＰＮ４１２は、エア・インターフェース干渉を克服するために、ＱｏＳを例えば５００ｋｂｐｓに格上げすることができる。また、インターネットＡＰＮ４１２は、ＲＴＣＰメッセージにおいて受信するＱｏＳフィードバックに応じて、メディア・ストリームに対してコード変換を実行することもできる。コード変換は、冗長性の追加、インターリービング、または移動体ノードによってはあり得る誤り訂正コードを伴う可能性がある。実施形態によっては、インターネットＡＰＮ４１２は、移動体ノードに割り当てられる帯域幅を広げることができ、メディア・サーバ４１６から受信するストリーミング・メディアをコード変換するために、この追加帯域幅を用いることができる。また、コード変換は、ストリーミング・メディアのフォーマットを変更することを伴うこともあり得る。ある時点で、移動体ノード４１０はティアダウン・メッセージ４４０を送り、メディア・サーバ４１６が送ったレスポンス・メッセージ４４２について、セッションを解除(tear down)する。
【００１８】
ストリーミング・メディアは、解像度、コーデック、およびフレーム・レートというような、多数のパラメータによって定義することができる。ビデオに対する解像度は、水平方向ビット×垂直方向ビット（例えば、移動体ノードには、１／４共通中間フォーマット（ＱＣＩＦ：quarter common intermediate format）を用いることもできる）である。オーディオ・コーデックは、ＡＭＲ  ＮＢ（適応マルチレート狭帯域）を用いた約８ｋｂｐｓのテレフォニ品質、またはＡＡＣ  ＷＢ（高度オーディオ・コーディング広帯域）を用いた約９６ｋｂｐｓのｍｐ３／ｃｄ品質とすることができる。ビデオのフレーム・レートは、例えば、ムービー品質（３０ｆｐｓ）またはビデオ・テレフォニ品質（５ｆｐｓ）とすることができる。ビデオのＩ−フレーム（イントラ・フレーム）レートは、１つ以上の基準フレームおよびデルタ・フレームを用いることによって、ビデオを圧縮することができる。デルタ・フレームは、フレーム毎に情報を送るのではなく、基準フレームからの変化を含む。ビデオ・コーデックは、例えば、約１００ｋｂｐｓのビデオ・テレフォニ品質を提供するＨ２６ｘ、あるいは約５１２ｋｂｐｓのムービー品質を提供するＭＰＥＧ−ｘを用いた、インター・フレームおよび／またはイントラ・フレームとすることができる。ゲートウェイにおけるコード変換機構は、コーデック、フレーム・レート、および加入者が移動体ノードに期待することと一致するＱｏＳレベルを提供するためのその他のパラメータを変更するために用いることができる。メディア・パラメータの選択により、ＱｏＳを調節するための目標ビットレートに到達する。目標ビットレートは、ある種の実施形態では動的である。
【００１９】
ストリーミング・メディアを移送するためには、多数の異なるメディア・コンテナを用いることができる。メディア・コンテナは、特定のオーディオ／ビデオ・コーデックに合わせてフォーマットしたデータを含む。実施形態によっては、トランスコーダが、３ＧＰ、ＭＰＥＧ−ｘ、ＡＶＩ、ＭＯＶ、ＷＡＶ、Ｒｅａｌｍｅｄｉａ、ＡＩＦＦ、ＸＭＦ、ＩＦＦ、ＡＳＦ、ＤＶＲ−ＭＳ、Ｏｇｇ、ＯＧＭ、ＮＵＴ、ＭＸＦ、ｒａｔＤＶＤ、ＳＶＩ、ＶＯＢ、ＤＩＶＸ、およびその他の適用可能なあらゆるメディア・コンテナのような、コンテナ間で切り換えることができる。また、ゲートウェイは、これがなければ移動体ノードにはアクセス不可能なコンテンツへのアクセスも提供することができる。これを行うことができるのは、コンテンツ・サーバがいくつかの既知のフォーマットでコンテンツを保持しているからであり、ワイヤレス加入者およびワイヤライン加入者の特性が異なるために、これら双方に同じコンテンツを提供することが困難な場合もある。例えば、低帯域幅、低パケット損失のｘＤＳＬアクセス・ネットワークがあるが、一般パケット無線サービス（ＧＰＲＳ）用の同様の帯域幅および１ｘワイヤレス・ネットワークは高パケット損失である。加えて、高帯域幅ワイヤライン・ネットワーク（例えば、ケーブルおよびファイバ）はパケット損失が少ないが、ワイヤレス・ネットワーク（例えば、３Ｇ、ＷｉＭＡＸ、およびＷｉＦｉ）はパケット損失が多い。
【００２０】
更に、アクセス・デバイスは、オーディオ処理能力およびビデオ処理能力(capabilities)に関して異なる。例えば、デスクトップ・モニタは、１２８０×７２０の解像度で動作することができ、一方移動体ノードは１７６×１４４または３５２×２８８で動作する。実施形態によっては、ゲートウェイは、実行中のコード変換によって、ネットワークに取り付けられているデバイスに合わせてコンテンツをテイル(tail)することができる。３Ｇ移動体デバイスに対して、ゲートウェイは、エア・インターフェースに伴う干渉やパケット損失にも拘わらず所望のＱｏＳを確保するために、フォーマットおよびデータ・レートを変更しつつ、解像度を下げることができる。
【００２１】
図５は、ある種の実施形態にしたがって、アクセス・ゲートウェイにおいて動的なサービス品質調節を設ける場合を示す。図５は、移動体ノード５１０、３Ｇインターネット・プロトコル・キャリア・アクセス・ネットワーク（ＩＰＣＡＮ）５１２、ゲートウェイ５１４、インターネット５１６、Ｗｅｂサーバ５１８、メディア・サーバ５２０、ならびにポリシーおよび課金規則機能（ＰＣＲＦ）５２２を含む。ゲートウェイ５１４は、ディープ・パケット検査(deep packet inspection)を利用してＲＴＳＰを検出し、ゲートウェイにおけるセッションについてＲＴＳＰバック・ツー・バック・ユーザ・エージェント（Ｂ２ＢＵＡ）インスタンスを生成することができる。ＲＴＳＰ  Ｂ２ＢＵＡは、ゲートウェイ５１４のいずれの側においてもコール・レッグ(call legs)間で別のサービスのコード変換および提供を可能にする。移動体ノード５１０は、ＨＴＴＰメッセージング５２４をＷｅｂサーバ５１８と通信することによって、なおもセッションを開始することができる。ゲートウェイ５１４は、パケットを検査することによって、移動体ノード５１０とメディア・サーバ５２０との間におけるＲＴＳＰリクエスト／レスポンス・メッセージング５２６を検出することができる。
【００２２】
実施形態によっては、ゲートウェイがＢ２ＢＵＡインスタンスを確定し、Ｂ２ＢＵＡインスタンスが移動体ノード５１０とのコール・レッグを確定（setting up）し、メディア・サーバ５２０との第２のコール・レッグを確定することができる。また、ゲートウェイ５１４は、１つ以上のＲＴＳＰプロキシ・インスタンスを生成することもできる。プロキシ・インスタンスは、ディープ・パケット検査でコンテンツのリクエストを検出したときに確定することができる。ゲートウェイ５１４は、プロキシ・インスタンスを確定し、メディア・サーバ５２０からのコンテンツの配信、およびゲートウェイ５１４から移動体ノード５１０へのコンテンツの配信を取り決めることができる。ストリーミング・メディア・セッションの最中におけるゲートウェイ５１４では、ゲートウェイはメディア・ストリームを制御し、ストリームの提供(provision)またはパラメータを取り決め直すことができ、ストリームに対するコード変換のような処理を実行することができる。実施形態によっては、ＲＴＳＰはメディア・ストリームを確定するために用いることができ、ＲＴＰはコンテンツを配信するために用いることができる。また、ゲートウェイは、ストリームを修正することなく、メディア・ストリームを中継することができる。メディア・ストリームを移動体ノード５１０に中継する場合でも、ゲートウェイ５１４はセッション毎にコード変換またはその他のサービスを導入することができる。また、ゲートウェイは、メディア・ストリームをどのようにおよび／またはいつ変更するかについて命令を受信することもできる。これらの命令はＰＣＲＦ５２２から来ることができる。例えば、図５において、ＰＣＲＦ５２２は移動体ノード５１０に対してＱｏＳを格下げする。ゲートウェイ５１４は、格下げされたＱｏＳに適応するために、ＲＴＰフローを取り決め直す。これは、例えば、２５６ｋｂｐｓから８０ｋｂｐｓへの格下げとすることができる。これを遂行するには、実施形態によっては、ゲートウェイにおけるディジタル信号処理（ＤＳＰ）カードを通過するように中継するフローを変更する。ＤＳＰカードは、符号変換を備えたＤＳＰエンジンを含むことができる。
【００２３】
また、ゲートウェイは、例えば、エア・インターフェースを通じて移動体ノードに送ることにコンパチブルでないまたは容易に利用できないフォーマットで、所望のコンテンツが格納されているときに、ストリーミング・メディア・プロキシ機能を提供することもできる。これを行うことができるのは、移動体ノード５１０に提供されているエアリンクが、コンテンツをその元のフォーマットでストリームするだけの帯域幅を有していない場合である。別の実施形態では、移動体ノード５１０は、メディア・サーバ５２０とのセッションを確定し、ゲートウェイがパケットを中継しつつ、変更を実施するまで、フィードバックを検査する。その後、ゲートウェイは、ストリームをコード変換するためまたは他のサービスをストリームに提供するために、セッションを内部に導き直すことができる。
【００２４】
図６は、一部の実施形態によるゲートウェイを通過するパケット・フローを示す。図６は、移動体ノード６１０、無線アクセス・ネットワーク（ＲＡＮ）６１２、アクセス・ゲートウェイ６１４、ゲートウェイ６１６、サーバ６１８、インターネット６２０、ならびに外部または内部インライン・サービス６２２および６２４を含む。アクセス・ゲート６１４およびゲートウェイ６１６は、ある種の実施形態では、同じゲートウェイとすることができる。ゲートウェイ６１６は、ネットワーク処理ユニット（ＮＰＵ）６２６、ＲＴＳＰフロー６２８、流入ＩＰデータ・フロー６３０、流出ＩＰデータ・フロー６３２、ＩＰＳＧマネージャ６３４、セッション・マネージャ６３６、その他のサービス・モジュール６３８、コンテンツ・サービス・ステアリング（ＣＳＳ）アプリケーション・プログラム・インターフェース（ＡＰＩ）６４０、およびモジュール通信６４２を含む。ＲＴＳＰフロー６２８、流入ＩＰデータ・フロー６３０、流出ＩＰデータ・フロー６３２、ＩＰＳＧマネージャ６３４、およびセッション・マネージャ６３６は、ソフトウェアで実装することができ、サービスをパケット・フローに提供するために用いることができる。ＲＴＳＰフロー６２８は、ＩＰＳＧマネージャ６３４によって、メディア・サーバ６１８に宛てられたＲＴＳＰメッセージングを監視するために用いることができる。フローは、ある情報についてのメッセージをチェックすることによって、メッセージを監視することができ、メッセージがある判断基準を満たす場合、ある種の実施形態では、ディープ・パケット検査のために、そのメッセージをＩＰＳＧマネージャまたはその他のモジュールに送出する。
【００２５】
ＲＴＳＰリクエストは、処理のために、ＩＰＳＧマネージャ６３４によって受信される。ＩＰＳＧマネージャ６３４は、ゲートウェイ６１６におけるセッションを活性化および非活性化するために、メッセージを検査する。ＩＰＳＧマネージャ６３４によるメッセージの検査中にも、情報を入手する。この情報は、セッションを確定し、セッションを認証し、セッションを加入者プロファイルにリンクするために用いることができる。この情報は、モジュール通信６４２を通じて、セッション・マネージャ６３６に送ることができる。モジュール通信６４２は、ハードウェアまたはソフトウェアのいずれの組み合わせでも実現することができる。ＩＰＳＧマネージャ６３４は、メディア・サーバ６１８に通信するときにアクセス・ゲートウェイ６１４が用いるポート数に対応する１つ以上のＲＴＳＰフロー６２８を確定することができる。
【００２６】
ＩＰＳＧマネージャ６３４は、アクセス機器から受信するＲＴＳＰメッセージの扱いに関して少なくとも２つのモードで機能することができる。実施形態によっては、ＩＰＳＧマネージャ６３４はサーバ・モードになっている。サーバ・モードでは、ＲＴＳＰメッセージはゲートウェイ６１６に宛てて送られ、ＩＰＳＧマネージャ６３４はＲＴＳＰレスポンス６４４を発行し、ゲートウェイ６１６がＢ２ＢＵＡまたはプロキシ・メディア・サーバを実現する。別の実施形態では、ＩＰＳＧマネージャ６３４は検査モードにあり、メッセージはゲートウェイに宛てて送られないので、メッセージはＮＰＵ６２６によってＩＰＳＧマネージャ６３４に導かれる。ＩＰＳＧマネージャ６３４では、メッセージが検査され、メッセージが転送される前に６４６、情報を抽出する。双方のモードにおいて、メッセージを検査し、情報を抽出してセッション・マネージャ６３６に送る。ＩＰＳＧマネージャ６３４は、ＲＴＳＰセットアップおよびティアダウン・メッセージを検査して、通信モジュール６４２を介して、セッションを活性化および非活性化する。インライン・サービス６２２のような、内部インライン・サービスは、ＲＴＣＰパケットを監視し、メディア・ストリームをどのように修正するか判断するために用いることができる。当該修正は、ＤＳＰカード上にあるＤＳＰエンジンによって行うことができる。
【００２７】
セッション・マネージャ６３６は、少なくとも１つのＩＰデータ・フローを作成することができ、ＩＰデータ・フローはＩＰデータ・フロー６３０および６３２を含むことができる。流出ＩＰデータ・フロー６３２の方がストリーミング・メディアに実現される可能性が高い。何故なら、ストリームはダウンリンクを通じて提供されるからである。しかしながら、ユーザが移動体ノード上でビデオ・テレフォニまたはゲームに参加しているときには両方のＩＰフローを用いることができる。何故なら、アップリンクおよびダウンリンク双方を用いるからである。流入ＩＰデータ・フロー６３０は、セッション・マネージャ６３６に、パケットが移動体ノード６１０から来つつあるので、セッション・マネージャ６３６はそのパケットを中継するか、またはコード変換のようなサービスを提供できることを示す。パケットが流出ＩＰデータ・フロー６３２に到達すると、同様のプロセスが行われる。流出ＩＰデータ・フロー６３２は、流入ＩＰデータ・フロー６３０と同様に、加入者セッション毎にパケットを認識し、中継するためまたはコード変換のようなサービスを提供するために、セッション・マネージャ６３６に転送する。新たなセッションを活性化し、セッション・マネージャ６３６がＩＰＳＧマネージャ６３４から抽出した情報を受信したとき、ある種の実施形態では、セッション・マネージャ６３６は呼を認証して加入者プロファイルをロードすることができる。認証には、ＮＡＩ、ＭＳＩＤ、ユーザ名、およびパスワード、または移動体ノード６１０のその他の何らかの認証属性が必要となることもあり得る。加入者プロファイルは、加入者アクセス制御リスト（ＡＣＬ）のような構成情報、対応するＣＳＳ再導出 (リダイレクト；redirection)、およびこの加入者に適用するその他のサービスを含む。呼が認証または許可されると、セッション毎の動的ＱｏＳを確定し、データ・フローが開始する。また、セッション・マネージャは、ＰＣＲＦがＱｏＳに関する命令を送ることができるように、加入者をＰＣＲＦで認証することもできる。
【００２８】
ＣＳＳ  ＡＰＩ６４０は、パケットの内容に基づいて、パケット・フローをゲートウェイによってどのように扱うかを定めるモジュールである。パケットは、パケット・ヘッダの中に情報を含む。コンテンツ・サービス・ステアリング（ＣＳＳ）ＡＰＩ６４０は、負荷均衡、ネットワーク・アドレス変換（ＮＡＴ）、ＨＴＴＰリダイレクト、およびＤＮＳリダイレクトというような機構を含む。実施形態によっては、ＣＳＳ  ＡＰＩ６４０は、加入者プロファイルから得た情報を用いて、しかるべきコンテンツ・サービス・プロバイダ（例えば、インライン・サービスまたは外部コンテンツ・サーバ）を選択すること、および負荷の均衡を取りつつパケット・フローをルーティングすることの双方を行う。負荷均衡は、ラウンド・ロビン、最小負荷、宛先ハッシュ、および正規化レスポンス時間監視のような、多数のアルゴリズムによって実行することができる。また、ＣＳＳ  ＡＰＩ６４０は、インターネット制御メッセージ・プロトコル（ＩＣＭＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、転送制御プロトコル（ＴＣＰ）、およびファイル転送プロトコル（ＦＴＰ）のキープアライブ・メカニズムを通じて、外部サーバの正常／異常(health)を監視することもできる。外部サーバの正常／異常を監視することにより、外部サーバに障害が発生した場合には、ＣＣＳ  ＡＰＩ６４０はパケット・フローをリダイレクトすることができる。ＣＳＳ  ＡＰＩ６４０は、メディア・ストリームを処理のためにＤＳＰカードにリダイレクトすることによって、コード変換を実施することもできる。ＣＳＳ  ＡＰＩ６４０は、メディア・ストリーム・パケット・フローを、動的サービス品質と共に、改良課金サービス（ＥＣＳ）に導出することができる。
【００２９】
図７は、ある種の実施形態によるＱｏＳの動的適用をサポートするネットワークにおけるシグナリングを示す。図７は、移動体ノード（ＭＮ）７１０、ゲートウェイ７１２、メディア・サーバ７１４、Ｗｅｂサーバ７１６、並びにポリシーおよび課金規則機能（ＰＣＲＦ）７１８を含む。７２０において、ディープ・パケット検査（ＤＰＩ）規則をゲートウェイ７１２上にインストールして、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を検出する。移動体ノードは、取得メッセージ７２２をＷｅｂサーバ７１６に送る。Ｗｅｂサーバ７１６は、レスポンス・メッセージ７２４を送り、移動体ノード７１０に、コンテンツを読み出すための情報を提供する。ゲートウェイは、ＲＴＳＰプロキシ・インスタンスを７２６において生成する。別の実施形態では、他のストリーミング・プロトコルに合わせてプロキシ・インスタンスを生成することができる。移動体ノードは、ＲＴＳＰセットアップ・メッセージ７２８を送り、ゲートウェイ７１２がこれを受信する。ゲートウェイは、ＲＴＳＰセットアップ・メッセージ７３０をメディア・サーバ７１４に送る。ゲートウェイ７１２の中に常駐するプロキシ・インスタンスは、ＲＴＳＰセットアップ・メッセージ７２８を修正してＲＴＳＰセットアップ・メッセージ７３０を生成することができる。メディア・サーバ７１４は、レスポンス・メッセージ７３２を送り、ゲートウェイ７１２がこれを受信する。ゲートウェイ７１２は、メッセージ７３２を修正し、その後にレスポンス・メッセージ７３４を移動体ノード７１０に送ることができる。メッセージ７３２は、ゲートウェイにおけるＲＴＳＰプロキシ・インスタンス・セットアップによる傍受(interception)に備えるために修正することができる。
【００３０】
移動体ノード７１０は、ＲＴＳＰ再生メッセージ７３６をゲートウェイ７１２に送る。ゲートウェイは、ＲＴＳＰ再生メッセージ７３６を修正し、その後にＲＴＳＰ再生メッセージ７３８をメディア・サーバ７１４に送ることができる。レスポンス・メッセージ７４０をゲートウェイ７１２に送る。ゲートウェイ７１２は、このメッセージを修正し、その後にレスポンス・メッセージ７４２を移動体ノード７１０に送ることができる。メディア・サーバ７１４は、高信頼性（ＨｉＦｉ）のＲＴＰストリーミングを、パケット・フロー７４４によって開始する。ゲートウェイ７１２は、メディア・リレー７４６を生成し、パケット・フローを移動体ノード７１０に受け渡す。メディア・リレーは、基礎となるコンテンツを変更することなく、パケット・フローの移動体ノードまでルーティングすることができるが、パケット・ヘッダの中にある情報を変更すること、または実施形態によってはパケットをカプセル化する場合もある。ＲＴＰストリーミング・パケット・フロー７４８は、移動体ノード７１０に送られる。ＰＣＲＦ７１８は、ＲＴＰストリームのＱｏＳを格下げする命令７５０を送る。ゲートウェイ７１２は、７５２においてＱｏＳを格下げし、７５４においてコード変換ブリッジを挿入する。コード変換ブリッジは、ストリームを移動体ノード７１０に送る前におけるコード変換処理のための、パケット・フローのディジタル信号プロセッサ（ＤＳＰ）への内部ルーティングとすることができる。実施形態によっては、コード変換ブリッジは、セッション・マネージャによって、パケット・フローをコード変換ブリッジに導く(steering)ＣＳＳ  ＡＰＩと共に実現することができる。ゲートウェイ７１２は、更新セッション・メッセージ７５６を移動体ノード７１０に送る。更新セッション・メッセージ７５６は、低忠実度メディア・パラメータ、およびその他の情報を含むことができる。移動体ノード７１０は、メッセージ７５８によって更新を承認する。ゲートウェイは、低忠実度のメディア・パケット・フロー７６０を送り始める。ＱｏＳの格上げも同様に行うことができる。
【００３１】
図７を参照すると、一部の実施形態をどのように実現するかの一例として、メッセージ・フローのサンプルが設けられている。７２０において、ディープ・パケット検査（ＤＰＩ）規則を活性化するまたはインストールして、コンテンツ・ストリームを検出する。メッセージ７２２によって、移動体ノード７１０は取得メッセージをＷｅｂサーバ７１６にゲートウェイ７１２を経由して送る。取得メッセージの一例を以下に示す。
GET /terminator.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
メッセージ７２４によって、Ｗｅｂサーバ７１６は２００ＯＫメッセージをゲートウェイ７１２を経由して送る。２００ＯＫメッセージの一例を以下に示す。
HTTP/1.1 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://mediaserver.com/terminator/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://mediaserver.com/terminator/video
ゲートウェイ７１２は、ＲＴＳＰパケット・フローを検出し、ＲＴＳＰプロキシおよびコンテンツ・ステア(content steer)を生成することができる。ＲＴＳＰプロキシの一部として、メッセージ７２４を修正して、移動体ノードがメッセージを直接ゲートウェイ７１２に送るようにすることができる。メッセージ７２４の一例を以下に示す。
HTTP/1.1 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://ST16.inline.rtsp-service.com/terminator/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://ST16.inline.rtsp-service.com/terminator/video
上のメッセージ例に示すように、ゲートウェイは、コンテンツを不変のままに残しつつ、Ｗｅｂサーバ７１６からのコンテンツに関する情報を修正することができる。  
【００３２】
マルチメディア・ストリームを確定するために、移動体ノード７１０はＲＴＳＰセットアップ・メッセージ７２８を送る。メッセージ７２８の一例を以下に示す。
SETUP rtsp://ST16.inline.rtsp-service.com/terminator/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast
client_port=3056-3057
ゲートウェイは、メッセージ７２８を修正することができ、メッセージ７３０をメディア・サーバ７１４に送る。メッセージ７３０の一例を以下に示す。
SETUP rtsp://mediaserver.com/terminator/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast
;client_port=3056-3057
メディア・サーバ７１４は、メッセージ７３２をゲートウェイに送る。メッセージ７３２の一例を以下に示す。
RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast
;client_port=3056-3057;
;server_port=5000-5001
ゲートウェイは、メッセージ７３２を修正し、その後に移動体ノード７１０に送ることができ、またはメッセージ７３４を送ることができる。メッセージ７３４の一例を以下に示す。
RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast
;client_port=3056-3057;
;server_port=5000-5001
ビデオ・ストリームに対するセットアップ・メッセージングも同様に行うことができる。
【００３３】
マルチメディア・ストリームを再生または開始する準備を整える際、移動体ノード７１０は、ビデオ用ＲＴＳＰ再生メッセージ７３６をゲートウェイ７１２に送る。メッセージ７３６の一例を以下に示す。
PLAY rtsp://st16.inline.rtsp-service.com/terminator/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
ゲートウェイは、メッセージ７３６を修正し、その後にメッセージ７３８を送ることができる。メッセージ７３８の一例を以下に示す。
PLAY rtsp://mediaserver.com/terminator/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
メディア・サーバ７１４は、例えば、以下に示すようなメッセージ７４０によって、ゲートウェイに応答することができる。
RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://mediaserver.com/terminator/video 
;seq=12312232;rtptime=78712811
ゲートウェイは、メッセージ７４０を修正し、メッセージ７４２を移動体ノード７１０に送ることができる。メッセージ７４２の一例を以下に示す。
RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://st16.inline.rtsp-service.com/terminator/video 
;seq=12312232;rtptime=78712811
オーディオ・ストリームに対する開始または再生メッセージングも同様に行うことができる。前述のように、プロキシ・インスタンスは、メディア・ストリームのセットアップを検出し、メディア・ストリームをインライン・サービスを通じて受け渡すように、受信したメッセージを修正し、メディア・ストリームを管理するためにインライン・サービスを確定することができる。
【００３４】
ＰＣＲＦは、メッセージをゲートウェイに送り、セッションに合わせてＱｏＳを変更することができる。変更は、ＱｏＳの格上げ、ＱｏＳの格下げ、またはコンテンツのフォーマット変更を含むことができる。また、変更は、ゲートウェイの中で、移動体ノード７１０から取得したフィードバックから内部でトリガすることもできる。ＰＣＲＦ７１８からのメッセージは、（オーディオおよびビデオＲＴＰフローに合わせてＱｏＳを５１２ｋｂｐｓから８０ｋｂｐｓに格下げする）命令を含むことができる。これらの命令は、ポリシーおよび課金施行機能（ＰＣＥＦ）において受信することができ、ポリシーおよび課金施行機能（ＰＣＥＦ）はこの命令をプロキシ・インスタンスに伝達することができる。プロキシ・インスタンスは、ＤＳＰトランスコーダを、例えば、ＣＩＦ、２４ｆｐｓ、ｍｐｅｇ−２、ＡＡＣオーディオからＱＣＩＦ、５ｆｐｓ、Ｈ．２６４、ＡＭＲ−ＮＢへのコード変換に割り当てることができる。移動体ノードにおける情報収集処理能力は、実施形態に応じて、静的または動的とすることができる。静的な実施形態では、情報はＵｔインターフェースから入手することができる。Ｕｔインターフェースは、オープン・モバイル・アライアンス（ＯＭＡ）によって明記されている。動的な実施形態では、クライアント処理能力は、ＲＴＳＰオプションを用いてクライアント処理能力をクエリすることによって、リアル・タイムで入手することができる。
【００３５】
移動体ノードとゲートウェイとの間におけるメディア・ストリームを変更するための再取り決めは、セッション記述プロトコル（ＳＤＰ）メッセージを新たなメディア・パラメータと共に送り、コード変換を扱うＤＳＰを有するＸＭＥカードを指し示すＲＴＰソース・ポートを送り、更にＸＭＥカードを指し示すＲＴＣＰ宛先ポートを送ることを含むことがある。ゲートウェイは、一時中止ＲＴＳＰメッセージを送り、セッションの取り決めをやり直し、次いでＲＴＳＰ再生メッセージを送ることができる。ゲートウェイは、ＲＴＣＰフローまたはその他のフィードバック信号を監視して、移動体ノードに到達するメディア・ストリームに関する情報を入手することができる。ストリーミング・パケット・フローに対する調節は、ＱｏＳの格上げや格下げには関係なく起動することができる。これらの調節は、ユーザが、例えば、フェーディング、高ビット・エラー・レート（ＢＥＲ）、およびセルの境界(boundary)のような無線の問題に遭遇したときに、ユーザ体験(experience)を増大させることができる。実施形態によっては、スラッシングを回避するためにヒステリシスを用いる場合もある。当該ヒステリシスは、例えば、フィードバック・メトリックの加重平均を計算し、周期的に加重平均を閾値と比較することによって実施することができる。
【００３６】
図８は、ある種の実施形態による、エア・インターフェース制約が変化するアクセス技術間におけるハンドオーバーを示す。図８は、移動体ノード８１０、アクセス・ポイント８１２、ネットワーク・アドレス変換部（ＮＡＴ）／ファイアウオール８１４、サービス・プロバイダ・ネットワーク８１６、ＷｉＭＡＸ／３Ｇ無線アクセス・ネットワーク（ＲＡＮ）８１８、ゲートウェイ８２０、ＰＣＲＦ８２２、およびメディア・サーバを含むパケット・データ・ネットワーク（ＰＤＮ）を含む。ゲートウェイ８２０は、パケット・データ相互作業(interworking) 機能（ＰＤＩＦ）、外部(foreign)エージェント／ホーム・エージェント（ＦＡ／ＨＡ）、アクセス・ゲートウェイ、およびプロキシ・インスタンスを含む。これは、例えば、ユーザがＷｉＦｉ接続したラップトップ上でムービーを見ているときに用いることができる。接続は、ラップトップにムービーに合わせた高データ・レートを提供することができる。しかしながら、ユーザがＷｉＦｉ接続から離脱して、マクロ・セルラ環境、例えば、高レート・パケット・データ（ＨＲＰＤ）またはＷｉＭＡＸにローミングすると、接続は低い方のデータ・レートをサポートする。ゲートウェイは、加入者セッションを監視し、セッションを修正して、ユーザに容認可能なサービス・レベルを提供して、ユーザがムービーを見続けることを可能にすることができる。
【００３７】
図９は、ある種の実施形態による、デバイス要件が変化する可能性がある場合におけるデバイス・ハンドオーバーを示す。図９は、移動体ノード８１０、移動体ノード８１２、３Ｇ／４Ｇネットワーク８１４、ゲートウェイ８１６、ＰＣＲＦ８１８、およびパケット・データ・ネットワーク８２０を含む。この種のハンドオーバーは、例えば、ユーザがＳＩＭカードを１つのデバイスから別のデバイスに移動したとき、またはユーザ・レベルの登録が行われたときに、生ずる可能性がある。ユーザ・レベル登録は、ユーザを特定するためにＳＩＭカードまたはその他のハードウェアを用いるときではなく、加入者の個人情報を、ユーザ名およびパスワードの登録に結び付けるときに行われる。ユーザにとっての利点は、サービスの流動性(mobility)である。例えば、ユーザは、セッションを彼らのラップトップ上でＰＤＡから継続することができる。ゲートウェイ８１６は、デバイスのハンドオーバーを監視し、コンテンツを新しいデバイス特性およびエア・インターフェースに適応させることができる。例えば、ＰＤＡからラップトップに変更するとき、ムービーの解像度を変更して、より大きな画面に合わせることができる。
【００３８】
図１０は、ある種の実施形態にしたがって、ゲートウェイにおいて動的ＱｏＳを実施するために用いることができる制御面アーキテクチャを示す。セッション・マネージャ１０１０は、ユーザ・セッション・データ・フローを、ユーザ機器および移動体加入者向けに、サービス（配給）および処理する。セッション・マネージャ１０１０は、前述のセッション・マネージャと同一であり、システム・サービス・レイヤ１０１２、呼処理レイヤ１０１４、および呼処理サポート・サービス・レイヤ１０１６のような機能レイヤを含む。システム・サービス・レイヤ１０１２は、セッション・マネージャおよびその他のレイヤに渡すべき命令のためにインターフェースを提供する。コマンド・ライン・インターフェース（ＣＬＩ）１０１８を設けることができる。ネットワーク処理ユニット１０２０は、パケット・フローを供給するために、そしてその他の処理のために用いることができる。呼処理レイヤ１０１４は、サービス・ブローカ／サービス制御相互作用マネージャ（ＳＣＩＭ）１０２２、Ｉ−ＣＳＣＦ１０２６、Ｐ−ＣＳＣＦ１０２８、およびＳ−ＣＳＣＦ１０３０を含むＣＳＣＦコア１０２４、統一メッセージ・マッピング・インターフェース１０３２、アプリケーション１０３４、ならびにＳＩＰスタック１０３６を含む。アプリケーション１０３４は、登記機能(registrar function)を含む。登記機能は、加入者、および外部データベースにクエリする必要なく情報の参照を可能にするセッションに関する情報をキャッシュする。実施形態によっては、ＣＳＣＦコアがＣＳＣＦ機能性の１つ、例えば、Ｐ−ＣＳＣＦを含む場合もある。呼処理サポート・サービス・レイヤ１０１６は、ルーティングおよびアドレス変換サービス１０３８、加入者管理サービス１０４０、変更インターフェース・サービス１０４２、メディア・インターフェース・サービス１０４４、ＱｏＳポリシー・インターフェース・サービス１０４６、セキュリティ・インターフェース１０４８、および規制サーバ・インターフェース１０５０というような種々のサービスを含む。
【００３９】
呼処理レイヤ１０１４を見ると、このレイヤはユニバーサルＳＩＰをアプリケーション・プログラム・インターフェース（ＡＰＩ）として用いる、シグナリング・プロトコルおよび呼制御を含む。シグナリング・プロトコルは、ＳＩＰとすることができ、あるいはＩＳＵＰ、ＭＧＣＰ、またはＨ．３２３のような他のプロトコルとすることもできる。更に、呼処理レイヤ１０１４は、統一マッピング・インターフェースを通じたＳＩＰの異種と他のプロトコルとの間の相互作業も可能にする。統一マッピング・インターフェースは、プロトコル特定メッセージおよびパラメータをＡＰＩフォーマットのようなユニバーサルＳＩＰに変換することができる。実施形態によっては、メッセージングのようなＳＩＰを用いる場合もある。何故なら、ＳＩＰは最大のメッセージ・集合であり、ＳＩＰおよびその他のプロトコルに可能なメッセージングの想定場面全てを有効範囲に含めることができるからである。また、呼処理レイヤ１０１４は、ＣＳＣＦコアが処理する必要がないデータに対して透過性を与えることができる。こうするには、その情報をエンベロープの中に入れる。対象にならないパラメータは、エンベロープの中に入れ、未修正のままにしておくことができる。ＣＳＣＦコアは、発呼番号および被呼番号のようなあらゆるテキスト文字列を許容し、番号をＥ．１６４番号に制限する必要はない。例えば、番号は、レコードのアドレス（ＡｏＲ）またはドメイン名を有するいずれの名称文字列でも可能である。
【００４０】
ディマックス・マネージャ(demux manager)１０５２は、図１０に示すように、信号ルーティング・レイヤ１０５４に常駐する。信号ルーティング・レイヤ１０５４は、ディマックス・マネージャと共に、いつパケット・フローを処理のために送るか判断することができる。パケット・フローは、更なる処理および／または信号の取扱のために、プロセス・インスタンスに送ることができる。ディマックス・マネージャは、ゲートウェイに入るパケット・フローまたはトラフィックを分析するために用いることができる。この分析は、パケット吸い込み(sniffing)、パケット・ヘッダからの情報の抽出、抽出した情報の並べ替え、ディープ・パケット検査、および１つ以上パケットから取得された情報の処理を含むことができる。ディマックス・マネージャによって分析されたメッセージは、情報を収容することができ、移動体ノードに割り当てたＩＰ−アドレス、ネットワーク・アクセス識別子（ＮＡＩ）、国際移動体加入者個人情報（ＩＭＳＩ）、移動体加入者識別（ＭＳＩＤ）、相関ＩＤ（ＣＤＭＡ実施態様のため）、ユーザ・データ・レコード（ＵＤＲ）、イベント・データ・レコード（ＥＤＲ）、発呼局ＩＤ、および／またはその他のあらゆる該当する情報のように、抽出（または吸い込む）ことができる。実施形態によっては、ディマックス・マネージャのバージョンをＲＴＳＰプロキシとして用いることができる。
【００４１】
ある種の実施形態では、動的ＱｏＳメカニズムが設けられる。標準で設けられるＱｏＳメカニズムは静的である。ＣＳＣＦ／ＳＩＰ−ＡＳのようなネットワーク・デバイスは、要求されたサービスを検査し、これを端末処理能力と照合し、ＱｏＳプロファイルを発行する。このような方式は、エンド・ユーザに対する帯域幅全体がほぼ一定であるワイヤライン・アクセスでは問題なく機能する。しかしながら、このような方式は、ワイヤレス・アクセス・ネットワークでは、「空中」即ちエアリンク接続に固有な動的性質のために機能しない場合もある。ワイヤレス接続は、有効データ・レート、レイテンシ、およびジッタ（例えば、ユーザが車で移動しているとき、マイクロ波デバイスに近いステップ等）の変動が生じやすい。このため、サービス品質をユーザ機器／移動体加入者（即ち、移動体ノード）に配信するためのモバイルの用途では将来において問題が生ずる。
【００４２】
実施形態によっては、フィードバック・コンポーネントをＱｏＳメカニズムに導入する。ＣＳＣＦは、サービス・クラスに基づいてＱｏＳプロファイルを発行し、ＱｏＳの適用を監視することができる。ＣＳＣＦは、フィードバックを受動的に受け取ることができる。即ち、電話機が合間に情報を送り、エアリンク情報または帯域幅受信情報を提供する。あるいはＣＳＣＦまたは別の実体が情報を要求することができる。要求する情報は、既知のデータ集合である可能性もあり、これを処理してエアリンク帯域幅を決定することができる。実施形態によっては、移動体ノードは同意メトリック(agreed upon metric)を送り、これによってＣＳＣＦが、移動体ノードに割り当てられた帯域幅をどのように調節するか判断することが可能となる。ある種の実施形態では、移動体ノードからのフィードバックを、ＱｏＳパラメータを再適用することができる機能に供給し、所望の動作パラメータの範囲内でサービスを保持することができる。別の実施形態では、データ・フローは、冗長パケットの送出、誤り訂正コードの採用、あるいはビデオまたはその他のストリーミング・メディア上におけるフレーム・レートの下降(dropping)というような別の方法で修正することができる。
【００４３】
一部の実施形態によれば、移動体ノードから逆にＣＳＣＦにおけるＱｏＳ監視機能に、連続フィードバックを供給する。この機能は、サービスを意識することができ、ＱｏＳを微調整するためにフィードバックに適用することができる。  例えば、ビデオ・オン・デマンドの場合、この機能は、１）フレーム・レート、２）Ｉ−フレーム間隔、または３）離散余弦変換（ＤＣＴ）を変更することができる。ＤＣＴは、損失がでる圧縮アルゴリズムであり、規則的な間隔で画像をサンプリングし、サンプルの中にある周波数成分を分析し、人の目が知覚する画像に影響を及ぼさない周波数を破棄する。ＤＣＴは、ＪＰＥＧ、ＭＰＥＧ、Ｈ．２６１、およびＨ．２６３のような規格の基準である。
【００４４】
前述のゲートウェイは、実施形態によってはシャーシに実装する場合もある。このシャーシは、多数の異なる統合機能性を実現することができる。実施形態によっては、アクセス・ゲートウェイ、パケット・データ配給ノード（ＰＤＳＮ）、外部エージェント（ＦＡ）、またはホーム・エージェント（ＨＡ）をシャーシ上に実装することができる。別の実施形態においてシャーシ上でも実装可能な別の種類の機能性は、ゲートウェイ汎用パケット無線サービス・サポート・ノード（ＧＧＳＮ）、担当(serving)ＧＰＲＳサポート・ノード（ＳＧＳＮ）、パケット・データ相互作業機能（ＰＤＩＦ）、アクセス・サービス・ネットワーク・ゲートウェイ（ＡＳＮＧＷ）、基地局、アクセス・ネットワーク、ユーザ・プレーン・エンティティ（ＵＰＥ）、ＩＰゲートウェイ、アクセス・ゲートウェイ、セッション開始プロトコル（ＳＩＰ）サーバ、プロキシ−呼セッション制御機能（Ｐ−ＣＳＣＦ）、および質問−呼セッション制御機能（Ｉ−ＣＳＣＦ）である。ある種の実施形態では、前述した他の種類の機能性の内１つ以上を統合するか、または同じ機能性によって提供する。例えば、アクセス・ネットワークをＰＤＳＮと統合することができる。シャーシは、ＰＤＳＮ、ＦＡ、ＨＡ、ＧＧＳＮ、ＰＤＩＦ、ＡＳＮＧＷ、ＵＰＥ、ＩＰゲートウェイ、アクセス・ゲートウェイ、または適用可能なその他のアクセス・インターフェース・デバイスであればいずれでも含むことができる。ある種の実施形態では、シャーシは、マサチューセッツ州TewksburyのStarent Networks, Corp.によって、ＳＴ１６またはＳＴ４０マルチメディア・プラットフォームにおいて提供される。
【００４５】
シャーシは、アプリケーション・カードおよびライン・カードを装填するためのスロットを含む。シャーシにおいてミッドプレーン(midplane)を用いて、インストールした種々のカード間におけるシャーシ内通信、電力接続、および伝達経路を設けることができる。ミッドプレーンは、スイッチ・ファブリック、制御バス、システム管理バス、冗長バス、および時分割多重（ＴＤＭ）バスのようなバスを含むことができる。スイッチ・ファブリックは、アプリケーション・カードおよびライン・カード間にカード間通信を確立することによって実施したシャーシ全体におけるユーザ・データのためのＩＰベースの伝達経路である。制御バスは、シャーシ内部にある制御および管理プロセッサを相互接続する。シャーシの管理バスは、給電、温度監視、ボード・ステータス、データ経路の障害、カードのリセット、およびその他のフェイルオーバ機構(failover feature)のようなシステム機能の管理を行うためにある。冗長バスは、ハードウェア障害の場合に、ユーザ・データの伝達を行い、冗長リンクを設ける。ＴＤＭバスは、システム上における音声サービスのサポートを設ける。
【００４６】
シャーシは、少なくとも２種類のアプリケーション・カード、すなわちスイッチ・プロセッサ・カードおよびパケット・アクセレレータ・カードを支持する。スイッチ・プロセッサ・カードは、シャーシのコントローラの役割を果たし、シャーシの初期化、およびシャーシ内にある別のカードへのソフトウェア構成の実装というようなことを責務とする。パケット・アクセレレータ・カードは、パケット処理および転送能力を備えている。各パケット・アクセレレータ・カードは、多数のコンテキストをサポートすることができる。ハードウェア・エンジンをカードと共に展開すれば、圧縮、分類トラフィック・スケジューリング、転送、パケット・フィルタリング、および統計編集(statistics compilation)のために並列分散処理をサポートすることが可能になる。
【００４７】
パケット・アクセレレータ・カードは、制御プロセッサおよびネットワーク演算装置（ＮＰＵ）の使用によって、パケット処理動作を実行する。ネットワーク演算装置は、パケット処理要件を判断し、ユーザ・データ・フレームを種々の物理的インターフェースとの間で受信および送信し、ＩＰ転送の判断を行い、パケット・フィルタリング、フロー挿入、削除、および修正を実施し、トラフィック管理およびトラフィック・エンジニアリングを実行し、パケット・ヘッダを修正／追加／削除し、ライン・カード・ポートおよび内部パケットの伝達を管理する。制御プロセッサもパケット・アクセレレータ・カード上に配置され、パケットに基づくユーザ・サービスの処理を行う。ライン・カードは、シャーシに装填されると、入力／出力接続機能を設け、冗長接続も設けることができる。
【００４８】
オペレーティング・システム・ソフトウェアは、Linuxソフトウェア・カーネルに基づき、シャーシにおいてタスクの監視やプロトコル・スタックの提供というような、特定のアプリケーションを走らせることができる。このソフトウェアによって、シャーシのリソースを制御およびデータ経路に別個に割り当てることが可能となる。例えば、ある種のパケット・アクセレレータ・カードは、ルーティングまたはセキュリティ制御機能の実行専用にすることができ、一方他のパケット・アクセレレータ・カードはユーザ・セッション・トラフィックの処理専用とする。実施形態によっては、ネットワーク要件が変更するに連れて、要件を満たすようにハードウェア・リソースを動的に展開することができる場合もある。システムは、技術機能（例えば、ＰＤＳＮ、ＡＳＮＧＷ、またはＰＤＩＦ、ＨＡ、ＧＧＳＮ、またはＩＰＳＧ）のような、サービスの多数の論理的インスタンスをサポートするために、仮想化することができる。
【００４９】
シャーシのソフトウェアは、特定の機能を実行する一連のタスクに分割することができる。これらのタスクは、必要に応じて、互いに通信し合い、シャーシ全体を通じて制御およびデータ情報を共有する。タスクとは、システム制御またはセッション処理に関する特定の機能を実行するソフトウェア・プロセスのことである。実施形態の中には、シャーシ内部で３種類のタスクが動作する場合もある。即ち、クリティカル・タスク、コントローラ・タスク、およびマネージャ・タスクである。クリティカル・タスクは、シャーシの初期化、誤り検出、および復元タスクのような、シャーシの呼を処理する能力に関係する機能を制御する。コントローラ・タスクは、ソフトウェアの分散性をユーザからマスクし、従属マネージャの状態を監視する、同じサブシステム内部においてマネージャ内通信に備える、そして他のサブシステムに属するコントローラと通信することによってサブシステム間通信を可能にする、というようなタスクを実行する。マネージャ・タスクは、システム・リソースを制御し、システム・リソース間における論理的マッピングを維持することができる。
【００５０】
アプリケーション・カード内にあるプロセッサ上で走る個々のタスクは、サブシステムに分割することができる。サブシステムとは、特定のタスクを実行するソフトウェア・エレメント、または多数の別のタスクの集合体である。１つのサブシステムが、クリティカル・タスク、コントローラ・タスク、およびマネージャ・タスクを含むことができる。シャーシ上で走ることができるサブシステムの一部は、システム起動タスク・サブシステム、高可用性タスク・サブシステム、復元制御タスク・サブシステム、共有構成タスク・サブシステム、リソース管理サブシステム、バーチャル・プライベート・ネットワーク・サブシステム、ネットワーク演算装置サブシステム、カード／スロット／ポート・サブシステム、およびセッション・サブシステムを含む。
【００５１】
システム起動タスク・サブシステムは、システム起動時に初期タスクの集合を起動し、必要に応じて個々のタスクを提供することを責務とする。高可用性タスク・サブシステムは、復元制御タスク・サブシステムと共に作動して、シャーシの種々のソフトウェアおよびハードウェア・コンポーネントを監視することにより、シャーシの動作状態を維持する。復元制御タスク・サブシステムは、シャーシ内で発生した障害に対して復元措置を実行することを責務とし、高可用性タスク・サブシステムから復元措置を受け取る。共有構成タスク・サブシステムは、シャーシに、シャーシ構成パラメータ変更の通知を設定し、読み取り、受信する能力を設け、シャーシ内部で走るアプリケーションの構成データを格納することを責務とする。リソース管理サブシステムは、リソース（例えば、プロセッサおよびメモリ能力）をタスクに割り当て、タスクのリソース使用を監視することを責務とする。
【００５２】
バーチャル・プライベート・ネットワーク（ＶＰＮ）サブシステムは、シャーシ内にあるＶＰＮに関するエンティティの統括(administrative)面および動作面を管理する。ＶＰＮに関するエンティティには、別個のＶＰＮコンテキストの生成、ＶＰＮコンテキストにおけるＩＰサービスの開始、ＩＰプールおよび加入者ＩＰアドレスの管理、ならびにＶＰＮコンテキスト内部におけるＩＰフロー情報の分配が含まれる。実施形態によっては、シャーシ内部で、特定のＶＰＮコンテキスト内においてＩＰ動作が行われる場合がある。ネットワーク演算装置サブシステムは、ネットワーク演算装置について先にリストした機能の多くを責務とする。カード／スロット／ポート・サブシステムは、新たに挿入したカード上におけるポートの発見および構成のようなカード活動(acting)に関して発生するイベントを調整し、ライン・カードがどのようにアプリケーション・カードにマッピングするか判断することを責務とする。セッション・サブシステムは、実施形態によっては、移動体加入者のデータ・フローを処理し監視することを責務とする場合がある。モバイル・データ通信のためのセッション処理タスクには、例えば、ＣＤＭＡネットワークに対するＡ１０／Ａ１１終端、ＧＰＲＳおよび／またはＵＭＴＳネットワークに対するＧＳＭトンネリング・プロトコル終端、非同期ＰＰＰ処理、パケット・フィルタリング、パケット・スケジューリング、ディフサーブ・コードポイント・マーキング(Difserv codepoint marking)、統計収集、ＩＰ転送、およびＡＡＡサービスが含まれる。これらの項目の各々に対する責務は、従属タスク（コールしたマネージャ）にわたって分散し、処理効率の向上および冗長性の増大を図ることができる。別個のセッション・コントローラ・タスクは、一体制御ノードとしての役割を果たし、マネージャを規制および監視し、他のアクティブなサブシステムと通信する。また、セッション・サブシステムは、ペイロード変換、フィルタリング、統計収集、ポリシー決定(policing)、およびスケジューリングのような、特殊なユーザ・データ処理も管理する。  
【００５３】
実施形態によっては、プロセスを実現するために必要なソフトウェアが、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、またはＰｅｒｌのような高レベル手続言語またはオブジェクト指向言語を含む場合がある。また、ソフトウェアは、所望であれば、アセンブリ言語でも実施することができる。シャーシ内において実施するパケット処理には、コンテキストによって決定されるいずれの処理でも含むことができる。例えば、パケット処理は、上位データ・リンク制御（ＨＤＬＣ）フレーミング、ヘッダ圧縮、および／または暗号化を伴う可能性がある。ある種の実施形態では、リード・オンリ・メモリ（ＲＯＭ）、プログラマブル・リード・オンリ・メモリ（ＰＲＯＭ）、電気的消去可能プログラマブル・リード・オンリ・メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、あるいはこの文書に記載したプロセスを実行するために汎用または特殊目的演算装置によって読み取り可能な磁気ディスクのような、記憶媒体またはデバイス上にソフトウェアを格納する。
【００５４】
以上、前述の実施形態例において本発明を説明および例示したが、本開示は、一例として行ったに過ぎず、本発明の実施態様の詳細において、本発明の主旨や範囲から逸脱することなく、多数の変更が可能であることは言うまでもない。本発明の範囲は、以下の特許請求の範囲のみによって限定されるものとする。
【図１】
2010512694.tif 000003
【図２】
2010512694.tif 000004
【図３】
2010512694.tif 000005
【図４】
2010512694.tif 000006
【図５】
2010512694.tif 000007
【図６】
2010512694.tif 000008
【図７】
2010512694.tif 000009
【図８】
2010512694.tif 000010
【図９】
2010512694.tif 000011
【図１０】
2010512694.tif 000012
【国際調査報告】
2010512694.tif 000013