JP4875169B2 - ホームネットワークに対するリモートアクセスのための方法及び装置 - Google Patents

Description

本発明は、概して、ホームネットワーク内のマルチメディアゲートウェイを用いてメディアを通信するために、リモートデバイスからホームネットワーク内のデバイスへのリモートアクセスを提供するための方法及び装置に関する。

今日、例えば固定の又は移動可能なコンピュータや電話のような、ＩＰ（インターネットプロトコル）を使用するパケットベースのマルチメディア通信に対応した多数の様々な通信端末及び通信デバイスを入手可能である。マルチメディアサービスは典型的には、様々なフォーマット及び組み合わせでのメディアの、ＩＰネットワークを介した伝送を伴う。例えば、ＩＰ対応移動体端末は、オーディオ情報に加えてビジュアル情報を、他のＩＰ対応移動体端末と交換したり、コンテンツサーバから何らかのフォーマットのメディアをダウンロードしたりすることができる。

「ＩＰマルチメディア・サブシステム」（ＩＭＳ）と呼ばれる、サービス及びサービス配信制御のアーキテクチャが、マルチメディアサービス及びマルチメディアセッションを管理するためのプラットフォーム（一般にＩＭＳネットワークと呼ばれる）として、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって開発されてきた。こうして、ＩＭＳネットワークは、アクセス技術に関わらず、様々なアクセスネットワークに接続されたＩＭＳ対応端末のためのマルチメディアセッションを開始して制御するために使用可能である。移動体ＩＰ端末のためのマルチメディアサービスを可能にすることが主として考えられてきたが、ＩＭＳのコンセプトは固定ＩＰ端末によっても使用可能である。ＥＴＳＩ（欧州電気通信標準化協会）では、ＴＩＳＰＡＮ(Telecom and Internet Services and Protocols for Advanced Networks)と呼ばれるワーキンググループが、現在、固定ネットワークにおけるＩＭＳの採用について取り組んでいる。

マルチメディアセッションは、ＩＭＳネットワーク内の特定のセッション制御ノードによって処理され、このノードには、典型的には、Ｐ−ＣＳＣＦ（プロキシ呼セッション制御機能）、Ｓ−ＣＳＣＦ（サービング呼セッション制御機能）、及びＩ−ＣＳＣＦ（インテロゲーティング呼セッション制御機能）が含まれる。ＩＭＳネットワークは、多様なマルチメディアサービスを可能にする多様なアプリケーションサーバ、及び、加入者データ及び認証データを格納するためのＨＳＳ（ホーム加入者サーバ）というデータベースノードも含み得るものである。

「ＳＩＰ」（セッション開始プロトコル）と呼ばれるシグナリングプロトコルが一般的に、ＩＭＳネットワークにおけるマルチメディアセッションのセットアップの間にメッセージをシグナリングするために使用される。標準的なＳＩＰメッセージはそれゆえ、ＩＰ端末又はＩＰデバイスによって、マルチメディアセッションを確立するために使用可能である。例えば、セッションのセットアップ手順において（例えば、マルチメディアアプリケーションが端末において起動された時に）他の通信相手とのセッションを開始するために、端末は「ＳＩＰ ＩＮＶＩＴＥ」と呼ばれるＳＩＰメッセージを送信することができる。

ＳＩＰでは、「ＳＤＰ」（セッション記述プロトコル）と呼ばれる追加プロトコルが、マルチメディアセッションを記述して指定するために使用され、ＳＤＰメッセージは、ＳＩＰメッセージ内の完結したボディとして埋め込み可能である。当技術分野においてよく知られている通り、ＳＤＰメッセージは、マルチメディアセッションに関するセッションパラメータを指定して交渉するために、デバイス能力及メディアプロパティに関する情報を提供するために通常は使用される。「セッションパラメータ」という用語は、ここでは、セッションを確立するために必要な、任意のデバイス能力、メディアプロパティ、及びアドレス情報を表すために使用される。上述したＳＩＰ ＩＮＶＩＴＥメッセージと、その一般的な応答メッセージである「ＳＩＰ ２００ ＯＫ」とは一般的に、１以上のコーデック（コーダ／デコーダ）に関する情報、並びにセッションのために必要なＩＰアドレス及びポート番号のような他の通信パラメータを伴う埋め込みＳＤＰメッセージを含む。

３ＧＰＰによれば、端末は、ＩＭＳネットワークに登録する際に必要な認証データ及び加入者データを提供するために、「ＩＳＩＭ」（ＩＭＳ ＳＩＭ）と通常は呼ばれる、ＩＭＳに対して有効なＳＩＭ（加入者ＩＤモジュール）アプリケーションを持たなければならない。ＩＳＩＭは、ＩＭＳプライベートアイデンティティ「ＩＭＰＩ」と、少なくとも１つのＩＭＳパブリックアイデンティティ「ＩＭＰＵ」とを格納し、両者は共にＩＭＳネットワークに知られている。ＩＭＰＩは認証のために使用され、各ＩＭＰＵは、典型的にはユーザに結び付けられているＩＭＳサービスプロファイルに関連付けられている。

一般的にホームネットワーク、ホームＬＡＮ（ローカルエリアネットワーク）、又はローカルＬＡＮと呼ばれる、例えばレジデンシャルネットワークやオフィスネットワークのようなプライベートネットワークに接続された様々なＩＰ端末に対して、ＩＭＳベースのサービスを提供することも、望ましいことである。本明細書では、そのようなあらゆるネットワークのために「ホームネットワーク」という一般用語が使用され、ホームネットワーク内のあらゆるＩＰ端末のために「ホームデバイス」という用語が使用される。

ホームネットワークは一般的に、様々な種類のホームデバイスを含み、これには例えば、固定電話及び無線電話、コンピュータ、メディアプレーヤ、サーバ、及びテレビ受像機が含まれる。ホームネットワーク内のＩＭＳ非対応ホームデバイスにＩＭＳサービスを提供するために、「ホームＩＭＳゲートウェイ（ＨＩＧＡ）」と呼ばれるマルチメディアゲートウェイが定義されてきており、ＨＩＧＡは、ホームネットワーク内のあらゆるホームデバイスに代理してＩＭＳサービスにアクセスするＩＭＳ対応端末として動作可能である。

ＨＩＧＡはとりわけ、ＩＭＳ非対応ホームデバイスとＩＭＳネットワークとの間の通信のためのブリッジとして基本的に動作する「バック・ツー・バック・ユーザエージェント」（Ｂ２ＢＵＡ）を含む。Ｂ２ＢＵＡは、ＩＳＩＭアプリケーションを備え、ホームデバイスに代理してＩＭＳネットワークとのＩＭＳシグナリングを処理する。例えば、ＳＩＰアイデンティティを含むがＩＭＳアイデンティティを含まないＳＩＰ ＲＥＧＩＳＴＥＲメッセージをホームデバイスが送信する場合、ＨＩＧＡ内のＢ２ＢＵＡは、通常のＩＭＳ手順に従い、そのメッセージを、ＩＭＰＩ及びＩＭＰＵの両方を含むＩＭＳに有効なＲＥＧＩＳＴＥＲメッセージに変換する。

図１において、家庭内又はオフィス内に複数の様々なホームデバイスを含んだホームネットワーク１００が示される。ここで示されるように、これらのデバイスには、無線電話、固定電話、ＴＶ受像機、ＰＣ（パーソナルコンピュータ）、及びサーバが含まれる。ホームネットワーク１００はまた、ネットワーク１００内のデバイスのために外部通信リンクを提供する外部のアクセスネットワーク１０４に接続された従来のレジデンシャルゲートウェイ（ＲＧＷ）１０２も含む。当技術分野においてよく知られている通り、ＲＧＷ１０４は典型的には、ＮＡＴ（ネットワークアドレス変換）機能と、ホームネットワーク内でのみ有効なローカルＩＰアドレスをデバイスに提供するローカルＤＨＣＰ（ダイナミック・ホスト・コンフィグレーション・プロトコル）サーバとを含む。

ホームネットワーク１００は更に、ＩＭＳネットワーク１０８（その中にＨＳＳ１１０が示されている）に対する接続を提供するＨＩＧＡ１０６を含む。ＨＩＧＡ１０６は、ネットワーク１００内の様々なデバイスに対する、デバイスに適合したプロトコルを使用する適切なインタフェースを備える。本明細書においてＨＩＧＡ１０６は個別の機能ユニットとして論理的には見なされているが、実際上は、ＨＩＧＡ１０６は、ＲＧＷ１０２内に物理的に組み込まれていてもよい。

ＨＩＧＡ１０６において、プロファイルに関連付けられたＩＤ情報１１２が、ネットワーク１００内の各ユーザのために格納されており、これは典型的には上述したＩＭＰＵであり、ＩＭＳネットワーク１０８に対するアクセスのために有効である。ＩＭＳネットワーク１０８においては、図に示す通り、同一のＩＤ情報が加入者情報１１４としてＨＳＳ１１０内に格納されている。ユーザが特定のデバイスを介してＩＭＳネットワークに通常通りログオンする際に、そのデバイスのＩＰアドレスがそのユーザのＩＭＰＵに関連付けられる。それゆえ、ネットワーク１００内の各ホームデバイスには、ユーザがその特定のデバイスにログオンした際に、特定のＩＭＳアイデンティティに関連付けられ得るローカルＩＤが割り当てられていることになる。ＷＯ２００６／０４５７０６は、ホームネットワーク内のホームデバイスが、ＩＭＰＩ及びＩＭＰＵの様々な組み合わせを使用するＨＩＧＡを用いてＩＭＳサービスをどのようにして取得可能かを、概説する。

ネットワーク１００内のホームデバイスがＨＩＧＡ１０６に対して自分の能力内のプロトコルを使用してＩＭＳサービスの要求を送信すると、ＨＩＧＡ１０６はデバイスのローカルＩＤ（例えば、デバイスのローカルＩＰアドレス）を用いてデバイスを特定し、典型的には、デバイス自体又はそのデバイスにログオンしているユーザに関する対応するＩＭＳアイデンティティ１１２を引き出す。次いで、ＨＩＧＡ１０６はデバイスに代理して、サービス要求を有効なＩＭＳ要求（例えば、ＳＩＰ ＩＮＶＩＴＥ）に変換し、適切なＳＩＰメッセージをＩＭＳネットワーク１０８と適宜通信することにより、デバイスのためのセッションをセットアップする。同様に、ホームデバイスのうちの１つとのＩＭＳセッションについての到来するメッセージは、そのデバイスに関連付けられたＩＭＳアイデンティティ１１２を使用してＨＩＧＡ１０６によってセットアップされ得る。いずれの場合も、図に示すように、アクセスネットワーク１０４を介してメディアを通信するために、セッションは、ＲＧＷ１０２を介してデバイスから、又はデバイスへとルーティングされる。

ＵＰｎＰ（ユニバーサル・プラグアンドプレイ）は、ＵＰｎＰフォーラムと呼ばれる複数ベンダの共同作業において開発された、ホームネットワーク内のＩＰデバイス間の通信のための標準的なデバイスプロトコルを確立するためのアーキテクチャである。ＵＰｎＰはそれゆえ、デバイスによって使用される様々なアクセス技術、オペレーティングシステム、プログラミング言語、フォーマット標準、及び通信プロトコルに対して、ホームネットワーク内のデバイス間のピア・ツー・ピア接続を提供する。更に、ＵＰｎＰは「ディスカバリ」（又は「ペアリング」）と呼ばれるプロセスをサポートする。このプロセスにおいて、デバイスはホームネットワークに動的に参加し、ローカルＩＰアドレスを取得し、自分の名前及びＩＰアドレスを告知し、他のホームデバイスと能力を交換することができる。ＵＰｎＰフォーラムは現在、プライベートネットワークの外に位置するリモートＵＰｎＰデバイスがホームネットワーク内のホームデバイスとメディアを通信可能なような、リモートアクセスを可能にするアーキテクチャを規定する過程にある。

図１は更に、ホームデバイス１００ａがホームネットワーク１００の外へ移動してリモートデバイス１００ａ’になることを示している。そしてリモートデバイス１００ａは、ネットワーク１００内のホームデバイスのうちの１つとのメディア通信を開始するために、ＩＭＳネットワーク１０８を介してＩＮＶＩＴＥメッセージをＨＩＧＡ１０６へ送信するが、ＩＭＳネットワークにアクセスするためにはリモートデバイスが有効なＩＭＳアイデンティティを持つことが必要とされる。ＷＯ２００６／０７９８９１（ノキア）では、例えばＩＰＳｅｃ（ＩＰセキュリティ）を使用してリモートＵＰｎＰアクセスのためのデータ／メディアのトランスポートチャネルとしてＶＰＮ（仮想プライベートネットワーク）トンネルをセットアップするソリューションが説明されている。

ホームデバイスに遠隔的にアクセスするために、リモートデバイスは、ディスカバリプロセスにおいてどうにかして、ホームデバイスに関する知識を得ていなければならない。リモートデバイスは、最近ホームネットワーク１００の中に位置していた間に、通常のディスカバリプロセスに参加していた可能性があり、典型的には、ＳＳＤＰ（シンプル・セッションディスカバリプロトコル）と呼ばれるプロトコルに従って或るディスカバリメッセージを交換することに関与している。しかしながら、そうでない場合（例えば、リモートデバイスが実際にネットワークの中にいたことが一切無い場合）は、ディスカバリメッセージを遠隔的に交換する必要がある。

図２は、ネットワーク内のホームデバイス（不図示）に対するリモートアクセスを可能にするための、リモートデバイス２００とホームネットワークのレジデンシャルゲートウェイ２０２とにおける可能な論理構造を示す。リモートアクセスクライアント（ＲＡＣ）２００ａがリモートデバイス２００の中で設定されており、対応するリモートアクセスサーバ（ＲＡＳ）２０２ａがレジデンシャルゲートウェイ２０２の中で設定されている。ＲＡＣ２００ａ及びＲＡＳ２０２ａはマッチングプロファイルを用いて設定されるべきであるので、これらは両者がホームネットワーク内に存在する際に設定可能であることが好ましい。

リモートアクセスクライアント２００ａは、リモートアクセスディスカバリエージェント（ＲＡＤＡ）２００ｂを含み、リモートアクセスサーバ２０２ａは対応するリモートアクセスディスカバリエージェント（ＲＡＤＡ）２０２ｂを含む。これらは、ホームネットワークとリモートデバイスとの間でディスカバリメッセージを交換するように構成される。リモートアクセスクライアント２００ａは更に、リモートアクセス伝送エージェント（ＲＡＴＡ）２００ｃを含み、リモートアクセスサーバ２０２ａは対応するリモートアクセス伝送エージェント（ＲＡＴＡ）２０２ｃを含む。これらは、リモートデバイスとリモートアクセスサーバ２０２ａとの間でメディアのための伝送チャネルを確立するように構成される。ＲＡＤＡ機能は、代わりに、「ＵＰｎＰプロキシ」と呼ばれてもよく、ＲＡＴＡ機能は、代わりに、「接続クライアント」と呼ばれてもよい。

ＲＡＴＡ２００ｃ，２０２ｃの構成は、典型的には、使用される伝送チャネルの特性に適合している。動的ＩＰアドレスの割り当てがレジデンシャルゲートウェイのために使用される場合、動的ＤＮＳ（ドメイン名システム）のよく知られているソリューションが、レジデンシャルゲートウェイ２０２のＩＰアドレスを解決するために使用可能である。

或いは、ＲＡＤＡ２００ｂ，２０２ｂは、ホームデバイス及びサービスのうちの少なくとも一方のリモートデバイスに対する（或いはその逆方向の）可視性を制限するために、フィルタなどを適用してもよい。各ＲＡＤＡ２００ｂ，２０２ｂは、ホームデバイス及びサービスに関する情報を収集するＳＳＤＰプロキシと、リモートアクセスクライアント２００ａ及びリモートアクセスサーバ２０２ａを同期させるように構成されたディスカバリエージェントとを含み得る。

メディアの通信に関与する様々な種類のサービスは、受信側で満足のいく結果を提供するために、データ伝送の速度及び遅延のうちの少なくとも一方に関して様々な要求条件を持つことがよく知られている。例えば、音声又はビデオのリアルタイム通信を伴う従来のサービスは、極めて短い遅延しか許容できない。更に、受信側で同時に再生される大量のデータの伝送を伴うストリーミングサービスは、再生における中断を回避するために或るデータレート又は帯域（「スループット」と呼ばれることもある）がセッション中に維持されることを要求する、などがある。それゆえ、ＱｏＳ（サービス品質）に関する様々なレベル又はクラスが使用され、そのうちの例えば「リアルタイム」は低遅延を保証し、「ストリーミング」は或る帯域を保証し、「ベストエフォート」は遅延及び帯域に関するいかなる保証も持たない。

図３は、概して、ＴＩＳＰＡＮによって規定される固定ネットワーク内でのＩＭＳセッションのためのＱｏＳ管理に関するアーキテクチャを概略的に示す。ユーザ装置３００と呼ばれる通信端末が、固定ネットワーク内の固定アクセスノード３０２に接続されている。レイヤ２リンクが、アクセスノード３０２を適切なレイヤ２終端ポイントＬ２Ｔ３０４に接続させ、Ｌ２Ｔ３０４はレイヤ２通信とレイヤ３におけるＩＰ通信との間の遷移におけるＩＰエッジを構成する。Ｌ２Ｔ３０４は、次に、他のネットワークとの通信のための、一般的に「ブローダ・ゲートウェイ機能（ＢＧＦ）」３０６と呼ばれるゲートウェイに更に接続される。ＢＧＦ３０６内には、一般的には、ＮＡＴ機能が実装されている。

ＴＩＳＰＡＮによれば、ＩＭＳセッションのためのＱｏＳの制御／管理は、「リソース及びアドミッション制御サブシステム（ＲＡＣＳ）」３０８と呼ばれる機能によって取り扱われる。ＲＡＣＳ３０８は各セッションのためのＱｏＳを確立するように構成され、次いで、Ｌ２Ｔ３０４において「リソース制御実施機能（ＲＣＥＦ）」３１０によって実施される。ＲＡＣＳ３０８はまた、一般的に、通常はユーザに応じて、ＩＭＳセッションのためのポリシー制御、リソース予約、及びアドミッション制御も担う。例えばセッション制御のためのＰ−ＣＳＣＦノード３１２ａを使用してＩＭＳネットワーク３１２によってＩＭＳセッションが確立されると、上述の通り、要求されるセッションパラメータやメディアプロパティがＳＤＰメッセージ内で規定され、Ｐ−ＣＳＣＦノード３１２ａはこれらをＱｏＳ要求情報へとマッピングし、ＱｏＳ要求情報はＲＡＣＳ３０８へ送信されてＲＣＥＦによって実施される。ネットワーク内のセッションのために必要なあらゆるアドレス変換も、ＢＧＦ３０６においてＲＡＣＳ３０８を介して確立される。ＲＡＣＳの現在の範囲は、概ね、アクセスネットワーク、及び、他のコアネットワークとの間の相互接続点をカバーする。

しかしながら、ホームネットワークへのリモートアクセス中にメディアセッションのための適切な又は正確なサービス品質（ＱｏＳ）を提供するという課題に対しては、未だに取り組みが行われていない。リモートデバイスがマルチメディアセッションを実行するためにホームネットワーク内のデバイスにアクセスする際には、使用されるサービスが比較的高い要求を伴うＱｏＳレベルを必要とするかもしれないにも関わらず、ＱｏＳ実施機能が存在しないために、そのセッションのためにベストエフォート・タイプのＱｏＳしか得られないであろう。

上で概説した課題に取り組むことが、本発明の目的である。より具体的には、ホームネットワークへのリモートアクセス中にメディアセッションのための適切なＱｏＳを確保するためのメカニズムを提供することが、本発明の目的である。これらの目的などは、以下に添付する独立請求項に従う方法及び構成を提供することにより、達成可能である。

一態様によれば、ホームネットワークと前記ホームネットワークの外に位置するリモートデバイスとの間のマルチメディアセッションのためにアクセスネットワークにおいてＱｏＳを確立する方法であって、前記リモートデバイス及び前記ホームネットワークのうちの少なくとも一方が前記アクセスネットワークに接続される方法が提供される。前記方法において、前記セッションの最初の部分の最中の、デバイスディスカバリと前記ホームネットワーク内のメディアの任意的な閲覧とのために、前記リモートデバイスからセッション招待メッセージが受信される。そして、前記セッションの前記最初の部分のために前記アクセスネットワークにおいてＱｏＳが実施される。前記セッションの２番目の部分の最中の、前記ホームネットワーク内の選択されたホームデバイスとのメディア通信のために、前記ＱｏＳを更新するために、前記リモートデバイスからセッション再招待メッセージが受信されると、前記メディア通信のためのセッションパラメータに基づいて、前記セッションの前記２番目の部分のためのＱｏＳ要求条件が判定される。そして、前記判定されたＱｏＳ要求条件を満足するために、前記セッションの前記２番目の部分における前記メディア通信のために、前記アクセスネットワークにおいて更新されたＱｏＳが実施される。

他の態様によれば、ホームネットワークの外に位置する時にリモートデバイスとして動作することにより前記ホームネットワークにアクセスするように構成される通信デバイスが提供される。前記通信デバイス及び前記ホームネットワークのうちの少なくとも一方がアクセスネットワークに接続される。前記リモートデバイスは、前記通信デバイスは、マルチメディアセッションの最初の部分の最中の、デバイスディスカバリと前記ホームネットワーク内のメディアの任意的な閲覧とのために、前記ホームネットワーク内のマルチメディアゲートウェイへセッション招待メッセージを送信するように構成される送信ユニットを備え、前記セッションの前記最初の部分のために前記アクセスネットワークにおいてＱｏＳが実施される。前記リモートデバイスは、前記セッションの２番目の部分の最中の、前記ホームネットワーク内の選択されたホームデバイスとのメディア通信のために、前記ＱｏＳを更新しなければならないか否かを判定するように構成される判定ユニットも備える。前記送信ユニットは、前記選択されたホームデバイスとの前記メディア通信のために前記ＱｏＳを更新するために、前記マルチメディアゲートウェイへセッション再招待メッセージを送信するように更に構成され、前記更新されたＱｏＳは、前記セッションの前記２番目の部分のために前記アクセスネットワークにおいて実施される。

更に他の態様によれば、マルチメディアサービスネットワーク内の、ホームネットワークの外に位置するリモートデバイスのためにホームネットワークへのアクセスを可能にするように構成されるセッション制御ノードが提供される。前記リモートデバイス及び前記ホームネットワークのうちの少なくとも一方が前記マルチメディアサービスネットワークに接続されたアクセスネットワークに接続される。前記セッション制御ノードは、セッションの最初の部分の最中の、デバイスディスカバリと前記ホームネットワーク内のメディアの任意的な閲覧とのための、前記ホームネットワークへ宛てられたセッション招待メッセージを前記リモートデバイスから受信するように構成され、前記セッションの２番目の部分の最中の、前記ホームネットワーク内の選択されたデバイスとのメディア通信のための、前記ホームネットワークへ宛てられたセッション再招待メッセージを前記リモートデバイスから受信するように更に構成される受信ユニットを備える。前記セッション制御ノードは、前記セッションの前記最初の部分のために前記アクセスネットワークにおいてＱｏＳを実施するように構成されるＱｏＳ実施ユニットと、前記メディア通信のためのセッションパラメータに基づいて前記セッションの前記２番目の部分のために前記ＱｏＳを更新するように構成されるＱｏＳ更新ユニットとも備える。前記ＱｏＳ実施ユニットは、前記２番目のセッションのために前記アクセスネットワークにおいて前記更新されたＱｏＳを実施するように更に構成される。

本発明の更なる可能な特徴及び利点は、以下の詳細な説明において説明されるであろう。

好適な実施形態を用いて、そして添付の図面を参照して、本発明を更に詳細に説明する。

先行技術に従う、ホームデバイスとのメディア通信のためにリモートデバイスがホームネットワークにアクセスする際のホームネットワークを示す概略図である。 先行技術に従う、リモートデバイス及びレジデンシャルゲートウェイにおけるリモートアクセス特徴を示すブロック図である。 先行技術に従う、固定ネットワーク内でＩＭＳセッションのためにＱｏＳを提供するためのネットワークアーキテクチャを示すブロック図である。 一実施形態に従う、リモートデバイスとホームネットワーク内のホームデバイスとの間のマルチメディアセッションのために適切な又は正確なＱｏＳが確立される際の概略的なネットワーク概観図である。 他の実施形態に従う、リモートデバイスとホームネットワーク内のホームデバイスとの間のマルチメディアセッションをセットアップする手順におけるステップを伴うフローチャートである。 他の実施形態に従う、リモートデバイス、レジデンシャルゲートウェイ（ＲＧＷ）、及びマルチメディアゲートウェイ（ＨＩＧＡ）の機能アーキテクチャを示す概略ブロック図である。 他の実施形態に従う、リモートデバイスがホームネットワーク内のホームデバイスとメディアを通信する際に或るＱｏＳを確保する本発明のソリューションをどのようにして実装可能であるかを示すシグナリング図である。 更に他の実施形態に従う、リモートデバイスを示す概略ブロック図である。 更に他の実施形態に従う、セッション制御ノードを示す概略ブロック図である。

本明細書において、ＨＩＧＡという用語は、ＩＭＳネットワークに接続されるホームネットワーク内のマルチメディアゲートウェイを一般的に表すために使用され、ＵＰｎＰという用語は、ホームネットワークアーキテクチャを一般的に表すために使用される。しかしながら、本発明はこれらの特定の用語に限定されないし、以下で言及されるいかなる特定のプロトコル及び標準にも限定されない。

短く説明すると、本発明は、ホームネットワーク内のＨＩＧＡを使用して、ホームネットワーク外に位置するリモートデバイスのために、ホームネットワーク内のホームデバイスとのマルチメディア通信にとって適切な又は必要なＱｏＳを確保するために使用可能である。ホームネットワークとのセッションにおけるディスカバリプロセスを実行し、例えばホームネットワーク内のメディアコンテンツを閲覧するために、リモートデバイスが最初にＨＩＧＡにアクセスする際に、ＨＩＧＡとの最初のセッションのための或るＱｏＳが選択される。最初のセッションのためのＱｏＳは、ＩＭＳネットワークを介してリモートデバイスとＨＩＧＡとの間で交換されるセッションセットアップメッセージを用いて選択され得る。ＩＭＳネットワーク内のセッション制御ノード（例えば、Ｐ−ＣＳＣＦ）が次に、セッションのセットアップ中のリモートデバイスとＨＩＧＡとの間でのセッションパラメータ又はメディアプロパティ（典型的には、リモートデバイスからのＩＮＶＩＴＥメッセージ内に、そしてＨＩＧＡからの２００ ＯＫ応答メッセージ内にも埋め込まれる、ＳＤＰメッセージ）の交換に基づいて、必要なＱｏＳを決定する。

或いは、一般的にディスカバリ及び閲覧のプロセスに伴う通常のシグナリング及び限定的なメディア交換にとっては十分であると見なされる比較的低レベルのデフォルトＱｏＳが選択されてもよい。例えば、デフォルトＱｏＳはベストエフォート・タイプのものであってもよい。

いずれの場合でも、選択されたＱｏＳは、リモートデバイスによって使用されるアクセスネットワークにおいて実施され、ホームネットワーク及びＨＩＧＡが接続されるアクセスネットワークにおいても実施される。ディスカバリプロセス及び任意的なメディアの閲覧が完了してリモートデバイスがメディア通信のためのホームデバイスを選択すると、例えばＳＤＰメッセージの中で２つのデバイスのためのセッションパラメータ又はメディアプロパティの更なる交換を伴う新しいセッションが、ホームデバイスと確立される。次いで、交換されたセッションパラメータに基づいて、新しいセッションのためにＱｏＳが更新されなければならないか否かが判定される。換言すれば、使用されるアクセスネットワークにおいて以前のＱｏＳレベルよりも高いＱｏＳレベルが必要とされるか否かが判定される。その場合、リモートアクセス中にデバイス間の適切なメディア通信を確保するために、新しいＱｏＳがアクセスネットワーク内で実施される。

図４は、一実施形態に従う、リモートデバイス４００とホームネットワーク４０２内のホームデバイス４０２ａとの間のＨＩＧＡ４０２ｂを介したマルチメディアセッションのために適切な又は必要とされるＱｏＳがどのようにして確立可能であるかを示すネットワーク概観図である。この例において、リモートデバイス４００は現在、第１のアクセスネットワーク４０４に接続されており、ホームネットワーク４０２は、第２のアクセスネットワーク４０６に接続されており、ネットワーク４０４及び４０６は、任意の（単数又は複数の）中間ネットワークと一般的に「バックボーン」ネットワーク４０８と呼ばれる（これは伝送ネットワークと呼ばれる場合もある）通信リンクとを介して通信可能である。更に、ネットワーク４０４は第１のＩＭＳネットワーク４１０に接続されており、ネットワーク４０６は第２のＩＭＳネットワーク４１２に接続されている。但し、ネットワーク４０４及び４０６は同一のＩＭＳネットワークに接続されていても構わない。

リモートデバイス４００とホームネットワーク４０２との間の相互接続は、それゆえ、基本的にデータ伝送のための３つの主な通信リンクを伴う。即ち、第１のアクセスネットワーク４０４を介した第１のリンク４：１、バックボーンネットワーク４０８を介した第２のリンク４：２、及び第２のアクセスネットワーク４０６を介した第３のリンク４：３である。もちろん、主なリンクの各々は、様々なルータ及びスイッチの間での複数のサブリンクを含んでもよい。

図に示すように、アクセスネットワーク上の第１のリンク４：１及び第２のリンク４：３は、セッションのために適切なＱｏＳを確立することを必要とするが、第２のリンク４：２はこれを必要としない。一般的には、無線インタフェースが関与する場合に特に、限られた伝送リソースしか持たないアクセスネットワークがデータ伝送に関する「ボトルネック」を構成してＱｏＳが重要になり得ると考えられており、一方で、バックボーンネットワークはいかなるＱｏＳ要件に対しても十分な伝送リソースを提供するものであると期待される。

アクセスネットワーク４０４，４０６上のリンク４：１及び４：３の各々に対する適切なＱｏＳは、基本的には以下のように確立可能である。リモートデバイス４００は、ディスカバリプロセスを実行し、任意的なものとしてホームネットワーク４０２内のメディアを閲覧するために、例えば埋め込みＳＤＰメッセージ内に提案セッションパラメータを含むセッション招待メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥ）を送信することにより、ＨＩＧＡ４０２ｂとのセッションを開始する。ＨＩＧＡ４０２ｂは次いで、応答メッセージ（例えば、ＳＩＰ ２００ ＯＫ）を送信するが、これも例えば埋め込みＳＤＰメッセージ内に提案セッションパラメータを含む。これらのセッションセットアップメッセージは、第１のＩＭＳネットワーク４１０内のセッション制御ノード４１０ａと第２のＩＭＳネットワーク４１２内のセッション制御ノード４１２ａとを通過する。

セッション制御ノード４１０ａ，４１２ａの各々は、最初は、ディスカバリ及び任意的な閲覧のために十分であると見なされるデフォルトＱｏＳをセッションのために選択してもよいし、セッションセットアップメッセージのＳＤＰ内に含まれる提案セッションパラメータに基づいて適切なＱｏＳを選択してもよい。

いずれの場合も、ノード４１０ａ及び４１２ａは次に、選択されたＱｏＳをそれぞれ、アクセスネットワーク４０４及び４０６の中の伝送制御機能４０４ａ及び４０６ａへと送信する。伝送制御機能４０４ａ及び４０６ａは、ＱｏＳを設定して実施し、個々のセッションにおけるデータ伝送のために各アクセスネットワークにおいてリソースを割り当てることを一般的に担う。「伝送制御機能」という用語は、ここでは汎用的な意味で使用されており、各機能４０４ａ，４０６ａは、ＱｏＳの実施及び伝送リソースの割り当てのためのＲＣＥＦと、アドレス変換のためのＢＧＦという、上述したノードを含み得る。

リモートデバイス４００が確立されたセッションを用いてディスカバリプロセス及び任意的な閲覧を実行し、メディア通信のためのホームデバイス４０２ａを選択すると、リモートデバイス４００は、進行中のセッションの２番目の部分の最中に、選択されたホームデバイスとメディアを通信するために、セッション再招待メッセージを送信して新しいＱｏＳ設定を確立する。セッションの２番目の部分のためのＱｏＳ更新手順は、セッションの最初の部分のためのＱｏＳ確立に類似しており、ここでも、選択されたデバイスとの通信のためのメディアプロパティなどをこの時点で反映するセッションパラメータ又はメディアプロパティを例えばＳＤＰメッセージ内で交換することを伴う。しかしながら、今回は、セッション制御ノード４１０ａ，４１２ａは交換されたセッションパラメータに基づいて適切なＱｏＳを選択する。ここで、対話ダイアログ及び大量のメディアデータの伝送のうちの少なくとも一方が、遅延及び帯域のうちの少なくとも一方に関する更に高い要求をもたらすので、ＱｏＳの要求条件は一般的に、セッションの最初の部分のためのものよりも高い。

ＱｏＳは次に、交換されたセッションパラメータ又はメディアプロパティに基づいて、伝送制御機能４０４ａ及び４０６ａにおいてセッションの２番目の部分のために更新され、新しいＱｏＳは、セッション中にデバイス間の適切なメディア通信を確保するために、アクセスネットワークにおいて実施される。アクセスネットワーク４０４，４０６が共に同一のＩＭＳネットワーク（例えば、ネットワーク４１０）に接続されている場合、その中のセッション制御ノード（例えば、Ｐ−ＣＳＣＦ）が、点線の双方向矢印によって示されるように、伝送制御機能４０４ａ及び４０６ａの両方においてＱｏＳを選択して実装する。

図５において、他の実施形態に従う、リモートデバイスとホームネットワーク内のホームデバイスとの間のマルチメディアセッションのために、ＩＭＳネットワークに接続されるアクセスネットワークにおける適切なＱｏＳを確保する手順に関するフローチャートを示す。図５の手順は、リモートデバイス及びホームネットワークの接続先である１又は２のアクセスネットワークにおいて実装可能であるものとする。それゆえ、リモートデバイス及びホームネットワークは、別々のアクセスネットワークに接続されていてもよいし、同一のアクセスネットワークに接続されていてもよい。各アクセスネットワークは、別々のＩＭＳネットワークに接続されていてもよいし、同一のＩＭＳネットワークに接続されていてもよい。図５に関する以下の説明は、リモートデバイス及びホームネットワークのうちの少なくとも１つの接続先である１つのアクセスネットワークのみを参照するが、２つのアクセスネットワークに対しても適切であって、適用可能であればこの手順を基本的に同時に実行する。

最初のステップ５００で、ホームネットワークとのセッションの最初の部分の最中にデバイスディスカバリ及び任意的な閲覧のプロセスを実行するための、セッション招待メッセージがリモートデバイスから受信される。セッション招待メッセージは、ＩＭＳネットワーク内のセッション制御ノード（例えば、Ｐ−ＣＳＣＦ）において最初に実際に受信され、次にホームネットワーク内のＨＩＧＡにおいて受信される。次のステップ５０２において、セッション制御ノードは、アクセスネットワーク（適用可能な場合はいずれかの側）においてセッションのために実施されるデフォルトＱｏＳを選択する。上述の通り、交換されたセッションパラメータ又はメディアプロパティに基づいて、この時点でセッションのために適切なＱｏＳをデフォルトＱｏＳの代わりに選択することも可能である。

リモートデバイスがセッションの最初の部分においてホームネットワークとのディスカバリプロセスを実行し、選択されたホームデバイスとメディアを通信するために任意的なこととしてメディアコンテンツを閲覧すると、更なるステップ５０４においてセッションの２番目の部分におけるメディア伝送のためにＱｏＳを更新するために、セッション再招待メッセージがリモートデバイスから受信される。同様に、再招待メッセージはＩＭＳセッション制御ノードにおいて受信され、次にＨＩＧＡにおいて受信される。

一実施形態において、リモートデバイスは、セッション再招待メッセージを送信する前に、関与するメディアパラメータに応じてセッションの２番目の部分のためのＱｏＳ要求条件が異なることが原因で、セッションのために既に最初に確立されているＱｏＳが更新されなければならないか否かをチェックしていてもよい。以前に実施されたＱｏＳが、セッションの２番目の部分の最中のメディア伝送のために十分であれば、セッション再招待メッセージは不要である。

他の実施形態において、メディア通信のためにホームデバイスが選択された際に、リモートデバイスは、更新されたセッションパラメータを含むセッション再招待メッセージを常に送信する。そして、アクセスネットワークにおいてＱｏＳ設定を更新するか否かの決定を行うのは、ＩＭＳセッション制御ノード次第である。

図５に戻って、次のステップ５０６で、来るべきメディア伝送のためのＱｏＳ要求条件が、再招待メッセージ及びＨＩＧＡからの応答メッセージに含まれてリモートデバイスと（ホームデバイスの代理としての）ＨＩＧＡとの間で交換されたセッションパラメータ又はメディアプロパティに基づいて、ＩＭＳセッション制御ノードによって決定される。上述の通り、そのようなセッションパラメータ又はメディアプロパティは、ＳＩＰメッセージ（ＩＮＶＩＴＥ及び２００ ＯＫ）に埋め込まれるＳＤＰメッセージ内に含まれ得る。

次に、ステップ５０８で、デバイス間の適切なメディア通信を確保するために、セッションのために最初に実施されたＱｏＳが、セッションの２番目の部分のために更新される必要があるか否かが判定される。必要が無ければ、ステップ５１０で、セッションの最初の部分の最中に使用されたデフォルトＱｏＳが、セッションの２番目の部分の最中に維持される。しかしながら、ステップ５０８においてデフォルトＱｏＳがセッションの２番目の部分のために十分ではない、又は「概ね十分(good enough)」ではないと判断された場合、最後のステップ５１２で、上のステップ５０６で決定されたＱｏＳ要求条件を満足する更新されたＱｏＳが選択され、これがセッションの２番目の部分の最中にメディア伝送のために実施される。

図６は、一方の側のリモートデバイス６００と、他方の側のホームネットワークのレジデンシャルゲートウェイ（ＲＧＷ）６０２及びマルチメディアゲートウェイ（ＨＩＧＡ）６０４とに、ＵＰｎＰアーキテクチャに基づいて上述のソリューションを達成する様々な機能をどのようにして実装可能かに関する例を示す概略ブロック図である。マルチメディアゲートウェイ（ＨＩＧＡ）６０４は、ＩＭＳネットワーク（不図示）に接続されており、ＨＩＧＡ６０４及びリモートデバイス６００の両方は、ＩＭＳクライアントとして登録されている。なお、図６は、様々な構成を単に論理的に示しており、当業者であれば、任意の適切なハードウェア及びソフトウェアを用いてこれらの機能を実際に実装することができるであろう。

リモートデバイス６００は、ホームネットワーク内のホームデバイスと遠隔的に通信するリモートアクセスアプリケーション（ＲＡＡ）６００ａを備える。ホームネットワークの外に在る場合、ＩＭＳ ＵＡ（ユーザエージェント）６００ｂが、ＩＭＳサービスにアクセスするために一般的に使用される。この文脈において、ＩＭＳ ＵＡ６００ｂは、ホームネットワーク内のホームデバイスと通信する際に、ＲＧＷ６０２の接続パラメータ（例えば、ルーティング可能なＩＰアドレス／ポート番号の組）を取得するためにも使用される。

リモートデバイス６００は更に、ＵＰｎＰデバイスを制御するＵＰｎＰ ＣＰ（コントロールポイント）６００ｃと、ホームネットワークとの遠隔的な接続及びアクセスを取得するＵＰｎＰリモートアクセスクライアント（ＲＡＣ）６００ｄとを内包する、ＵＰｎＰプロトコルスタックを備える。ＵＰｎＰ ＲＡＣ６００ｄの中で、リモートデバイスとホームネットワークとの間でＵＰｎＰディスカバリメッセージを同期させるために、ＲＡＤＡ６００ｅが使用され、ＩＭＳを介して通常のＳＩＰメッセージを用いて引き出し可能なＲＧＷ６０２のＩＰアドレスに基づいて接続を確立するために、ＲＡＴＡ６００ｆが使用される。リモートデバイス６００は、受信したメディアを処理するＵＰｎＰ ＤＭＲ（デジタルメディアレンダラ）（不図示）も備え得る。

ＲＧＷ６０２は、ＮＡＴ機能６０２ａ及びＵＰｎＰインターネットゲートウェイデバイス（ＩＧＤ）６０２ｂのような、ＮＡＴ ＩＰアドレス及びポートマッピングを制御するための標準的なレジデンシャルゲートウェイ機能を備える。ＲＧＷ６０２は更に、デバイス６００を含むリモートデバイスのためにリモートアクセスを可能にするＵＰｎＰリモートアクセスサーバ（ＲＡＳ）６０２ｃを備え、これは同様にＲＡＤＡ６０２ｄ及びＲＡＴＡ６０２ｅを含む。

ＨＩＧＡ６０４は、ホームネットワーク内のホームデバイスのプライベートＩＰアドレスを含むデバイスデータベース（ＤＢ）６０４ａを備え、ここでは、ディスカバリプロセスにおいてホームデバイス情報も収集可能である。ＤＢ６０４ａに格納されるホームデバイスのディスカバリ情報はまた、ホームデバイスの名前及び能力も含み得る。ＨＩＧＡ６０４は更に、ＨＩＧＡ論理機能６０４ｂと、ホームデバイスとＩＭＳネットワークとの間の通信のための（ＩＳＩＭアプリケーションを持つ）Ｂ２ＢＵＡ６０４ｃと、ホームネットワーク内のローカルＵＰｎＰデバイス（例えば、ＲＧＷ６０２内のＮＡＴ６０２ａ）を管理するＵＰｎＰ ＣＰ６０４ｄと、を備える。

図７は、更なる実施形態に従い、リモートデバイス７００とホームネットワーク内に位置するホームデバイス７０２との間のマルチメディアセッションのために適切なＱｏＳを実現するために、様々なノード及びコンポーネント間のシグナリング手順をどのようにして実装可能かを更に詳細に示す。関与するノードには更に、ＩＭＳネットワーク内に位置するセッション制御ノード（Ｐ−ＣＳＣＦ）７０２、及びアクセスネットワーク内に位置する伝送制御機能（ＢＧＦ／ＲＣＥＦ）７０４が含まれ、加えて、レジデンシャルゲートウェイ（ＲＧＷ）７０６、マルチメディアゲートウェイ（ＨＩＧＡ）７０８、及びホームデバイス７１０が含まれ、これら３つは全てホームネットワーク内に位置する。

この文脈において、機能Ｐ−ＣＳＣＦ７０２及びＢＧＦ／ＲＣＥＦ７０４は基本的に、それぞれ、上の図４で説明したセッション制御ノード（４１０ａ，４１２ａ）、及び伝送制御機能（４０４ａ，４０６ａ）と同等のものである。図７においては、１つのみのアクセスネットワークと１つのみのＩＭＳネットワークが関与するものとするが、ここでの例は、２つのアクセスネットワーク及び２つのＩＭＳネットワークが関与する場合、即ち、上述のようにリモートデバイス及びホームネットワークが別々のＩＭＳネットワークによってサービス提供される別々のアクセスネットワークに接続されている場合にも、有効である。その場合、このシグナリングスキームにおいて、機能Ｐ−ＣＳＣＦ７０２及びＢＧＦ／ＲＣＥＦ７０４は、それぞれ、各アクセス／ＩＭＳネットワークにおいて動作するように二重にされる。

ここでも、リモートデバイス７００及びＨＩＧＡ７０８の両方がＩＭＳクライアントとして登録されているということが前提条件である。リモートデバイス７００は、基本的には図６に示した対応する機能のように、ＲＡＡ７００ａ、ＩＭＳ ＵＡ７００ｂ、及びＵＰｎＰ機能７００ｃを備え、ＵＰｎＰ機能７００ｃの中にはリモートアクセスクライアント（ＲＡＣ）が実装されている。同様に、基本的には図６に示すように、ＲＧＷ７０６も、ＵＰｎＰ機能（不図示）を備え、その中にはリモートアクセスサーバ（ＲＡＳ）が実装されている。或いは、ＵＰｎＰ機能及びＲＡＳは、ＨＩＧＡ７０８の中に存在してもよいが、ここの例ではそうではないように示されている。図示されているシグナリングステップを、以下に簡潔に説明する。

ステップ７：１ − リモートデバイス７００からホームネットワーク内のデバイスへアクセスすることを望むユーザが、適切な入力コマンドを用いて、ＲＡＡ７００ａを起動する。

ステップ７：２ − ＲＡＡ７００ａがＩＭＳ ＵＡ７００ｂに対して、ＨＩＧＡ７０８のＩＭＰＵに宛てられたＩＭＳベースのセッション招待メッセージ（ＳＩＰ ＩＮＶＩＴＥ）を送信するようにトリガする。ＳＩＰ ＩＮＶＩＴＥメッセージ内に埋め込まれるＳＤＰメッセージは、上では概ねセッションパラメータと呼ばれた所望のメディアプロパティに関する情報を、含んでもよいし、含まなくてもよい。

ステップ７：３ − これに応えて、ＩＭＳ ＵＡ７００ｂはＳＩＰ ＩＮＶＩＴＥメッセージを送信し、これはＩＭＳネットワーク内のＰ−ＣＳＣＦノード７０８によって最初に受信される。

ステップ７：４ − Ｐ−ＣＳＣＦノード７０８は、ＩＮＶＩＴＥメッセージをＨＩＧＡ７０８へ転送する。ＩＮＶＩＴＥメッセージは、ＨＩＡＧ７０８内のＢ２ＢＵＡ（不図示）によって受信されて処理される。ＳＩＰ ＩＮＶＩＴＥメッセージ内に埋め込まれるＳＤＰメッセージは、リモートデバイス７００によって使用されるＩＰアドレス及びポート番号を含む。

ステップ７：５ − ＨＩＧＡ７０８内のＢ２ＢＵＡは、ＳＩＰ ＩＮＶＩＴＥメッセージ内に含まれるリモートデバイスのＩＭＳユーザアイデンティティと、ＨＩＧＡ７０８に事前に格納されている許可されたユーザのアイデンティティとを比較することにより、ユーザを認証する。例えば、ＳＩＰ ＩＮＶＩＴＥヘッダは、ＩＭＳユーザアイデンティティとして所謂P-Asserted-Identityを含むことができる。

ステップ７：６ − ＨＩＧＡ７０８内のＵＰｎＰ ＣＰ（不図示）を使用して、リモートデバイス７００のＩＰアドレス及びポート番号と、ＲＧＷ７０６内（或いは、ＨＩＧＡ７０８内）のＵＰｎＰ ＲＡＳのローカルアドレスとについての、ＮＡＴバインディングがＲＧＷ７０６内で要求される。

ステップ７：７ − ＲＧＷ７０６内のＵＰｎＰ ＩＧＤ（不図示）がＮＡＴバインディングを確認する。

ステップ７：８ − ＨＩＧＡ７０８内のＢ２ＢＵＡが、リモートデバイス７００に対して、ＲＧＷ７０６内のＵＰｎＰ ＲＡＳのＩＰアドレス及びポート番号を含む取得されたＮＡＴバインディング情報を伴うＳＩＰ ２００ ＯＫメッセージを送信する。ＳＩＰ ２００ ＯＫメッセージは、Ｐ−ＣＳＣＦノード７０２によって最初に受信される。

ステップ７：９ − Ｐ−ＣＳＣＦノード７０２は、（基本的にはＢＧＦを通る接続である）ＢＧＦ７０４内の所謂「ピンホール」を確立するための関係するＳＤＰパラメータを抽出し、「ＵＰｎＰリモートアクセスシグナリング」と呼ばれるサービス（即ち、上述したように、ディスカバリプロセスを実行し、任意的にメディアを閲覧するための、セッションの最初の部分）をサポートするために、最初のＱｏＳポリシー設定を決定する。Ｐ−ＣＳＣＦノード７０２は次に、ＢＧＦ／ＲＣＥＦ機能７０４に対して（例えば図３に示すＲＡＣＳ機能を介して）、ディスカバリプロセスのために必要なＱｏＳを有効に実施するための、ピンホール確立に関するＱｏＳ／ポリシー設定及びＩＰアドレスを含んだ標準のＨ．２４８メッセージを送信する。好ましくは、上述の通り、デフォルトＱｏＳがセッションの最初の部分のために選択される。２つのＩＭＳネットワークが関与する場合、このステップは、各ＩＭＳネットワークにおけるユーザサービスプロファイルに基づいて、２つのＰ−ＣＳＣＦノードによって並行して実行され得る。

ステップ７：１０ − ＢＧＦ／ＲＣＥＦ機能７０４は、（例えばＲＡＣＳ機能を用いて、）Ｐ−ＣＳＣＦノード７０２に対して確認メッセージによる応答を行う。

ステップ７：１１ − Ｐ−ＣＳＣＦノード７０２は、ステップ７：８において受信されたＳＩＰ ２００ ＯＫメッセージをリモートデバイス７００内のＩＭＳ ＵＡ７００ｂへ転送する。ＳＩＰ ２００ ＯＫメッセージは、ＲＧＷ７０６内のＵＰｎＰ ＲＡＳにアクセスするために使用されるＩＰアドレス及びポート番号を含むＮＡＴバインディング情報を伴う埋め込みＳＤＰメッセージを含む。

ステップ７：１２ − ＩＭＳ ＵＡ７００ｂは、受信したＳＤＰ情報をＲＡＡ７００ａへ送信する。

ステップ７：１３ − ＲＡＡ７００ａは、ホームネットワークとのリモートアクセスを確立するために、ＵＰｎＰ機能７００ｃのＲＡＣ内のＵＰｎＰ ＲＡＴＡを開始させるか又はトリガする。

ステップ７：１４ − ＵＰｎＰ機能７００ｃのＲＡＣ内のＵＰｎＰ ＲＡＴＡ、及びＲＧＷ７０６のＲＡＳ内のＲＡＴＡは、ステップ７：１１−１２のＳＤＰ内で受信されたＩＰアドレス及びポート番号を使用して、リモートデバイス７００とＲＧＷ７０６との間のＶＰＮトンネル（例えば、ＩＰＳｅｃ）を確立する。

ステップ７：１５ − ＶＰＮトンネルの確立が成功した後に、ＵＰｎＰ機能７００ｃのＵＰｎＰ ＲＡＤＡは、上述したようにセッションの最初の部分の最中にディスカバリプロセスを実行することによりホームネットワーク上のデバイス及びサービスを発見するために、ＲＧＷ７０６のＲＡＳ内の（或いは、ＨＩＧＡ７０８内の）対応するＵＰｎＰ ＲＡＤＡと同期することができる。

ステップ７：１６ − リモートデバイス７００のＵＰｎＰ機能７００ｃ内のＵＰｎＰ ＣＰは、この時点で、ホームデバイス７１０を選択し、選択されたデバイスにおいて入手可能なコンテンツを閲覧する。これは、例えばUPnP ContentDirectory Browseアクションを使用することにより、実行可能である。BrowseFlagをBrowseMetadataにセットすれば、選択されたＵＰｎＰデバイスからの結果応答には、閲覧されたコンテンツのメディアプロパティ（例えば、Item type: imageltem, audioltem 又は videoltem、加えて、選択されたコンテンツのサイズ及び符号化ビットレート）が含まれる。

ステップ７：１７ − ユーザはこの時点で、適切な入力コマンドを用いて、セッションの２番目の部分においてホームデバイス７１０から引き出すべきコンテンツ／サービスを選択する。

ステップ７：１８ − ＵＰｎＰ機能７００ｃ内のＲＡＣは、選択されたコンテンツの関連メディアプロパティに関して、ＲＡＡ７００ａに通知する。関連メディアプロパティは、ＱｏＳ決定に影響を与えるであろうものであり、また、ステップ７：１６において引き出されたものであり、例えば、選択されたコンテンツのメディアタイプ、サイズ、及び符号化ビットレートである。

ステップ７：１９ − ＲＡＡ７００ａは、メディアプロパティを、ステップ７：１２において受信されたＳＤＰ情報（これは、ステップ７：１４においてＶＰＮ接続をセットアップするためにも使用されたものである）と比較する。選択されたコンテンツのメディアプロパティが受信されたＳＤＰ情報と著しく異なる場合、セッションのＶＰＮ接続のためにステップ７：９において選択され実施されたデフォルトＱｏＳは、セッションの２番目の部分の最中に適切なメディア伝送を確保するために、更新／修正されなければならない。ステップ７：１８において受信されたＵＰｎＰパラメータに基づいて、更新の決定は、例えばメディアタイプ、又はサイズ及び／又は符号化ビットレートとの組み合わせによって、トリガ可能である。

ステップ７：２０ − ＲＡＡ７００ａは、ＨＩＧＡ７０８へと送信される、選択されたメディアコンテンツに基づく現在のメディアプロパティを少なくとも含むＳＤＰメッセージを伴うＳＩＰ ＲＥ−ＩＮＶＩＴＥメッセージをトリガする。ステップ７：１８及び７：１９において例として与えられたＵＰｎＰパラメータは、ＳＤＰメッセージ内で対応するメディア及び属性の記述（ｍ＝及びａ＝）の行にマッピングされる。

ステップ７：２１ − ＳＩＰ ＲＥ−ＩＮＶＩＴＥメッセージが、ＩＭＳ ＵＡ７００ｂからＨＩＧＡ７０８へ向かって送信され、Ｐ−ＣＳＣＦノード７０２によって最初に受信される。

ステップ７：２２ − Ｐ−ＣＳＣＦノード７０２によってＳＩＰ ＲＥ−ＩＮＶＩＴＥメッセージがＨＩＧＡ７０８へと転送される。

ステップ７：２３ − ＨＩＧＡ７０８内のＢ２ＢＵＡは、ＳＩＰ ２００ ＯＫメッセージをＰ−ＣＳＣＦノード７０２へ返す。ＨＩＧＡ７０８は、必要であれば、ホームネットワーク内で何らかのＱｏＳ設定を適用するために、更新されたメディアプロパティを伴うＳＤＰメッセージ内の情報を使用することができる。

ステップ７：２４ − Ｐ−ＣＳＣＦノード７０２は、ＱｏＳポリシー設定に関係するＳＤＰパラメータ（例えば、メディアタイプ、帯域要件、及び、ＩＰアドレス及びポート番号に関する情報）を抽出することにより、新しいＱｏＳを決定する。

ステップ７：２５ − それに応じて、Ｐ−ＣＳＣＦノード７０２は、ステップ７：９において送信されたメッセージと同様に、Ｈ．２４８メッセージをＲＣＥＦ７０４へ送信することにより（ＲＡＣＳを介して）ＲＣＥＦ７０４におけるＱｏＳ／ポリシー設定を更新し、セッションの２番目の部分の最中の来るべきメディア伝送のために必要なＱｏＳを有効に実施する。２つのＩＭＳネットワークが関与する場合、このステップは、各ＩＭＳネットワークにおけるユーザサービスプロファイルに基づいて、２つのＰ−ＣＳＣＦノードによって並行して実行され得る。

ステップ７：２６ − ＢＧＦ／ＲＣＥＦ機能７０４は、ステップ７：１０と同様に、（例えばＲＡＣＳ機能を用いて、）Ｐ−ＣＳＣＦノード７０２に対して確認メッセージによる応答を行う。

ステップ７：２７ − Ｐ−ＣＳＣＦノード７０２は、ステップ７：１１と同様に、ステップ７：２３において受信された、埋め込みＳＤＰメッセージを含むＳＩＰ ２００ ＯＫメッセージをリモートデバイス７００内のＩＭＳ ＵＡ７００ｂへ転送する。

ステップ７：２８ − ＩＭＳ ＵＡ７００ｂは、ステップ７：１２と同様に、受信されたＳＤＰ情報をＲＡＡ７００ａへ送信する。

ステップ７：２９ − 次にＲＡＡ７００ａは、ＵＰｎＰ機能７００ｃ内のＵＰｎＰ ＣＰに対して、選択されたメディアをホームデバイス７１０からフェッチ又はダウンロードするＨＴＴＰ ＧＥＴコマンドを送信するようにトリガする。

ステップ７：３０ − ＵＰｎＰ機能７００ｃ内のＵＰｎＰ ＣＰは、ＨＴＴＰ ＧＥＴコマンドをホームデバイス７１０へ送信する。

ステップ７：３１ − 選択されたメディアが最終的に、例えばストリーミングアプリケーションを用いて、ホームデバイス７１０からＵＰｎＰ機能７００ｃを使用するリモートデバイス７００へと、セッションの２番目の部分においてダウンロードされる。ステップ７：２５におけるＱｏＳの実施の結果として、このステップの間に、アクセスネットワークを介した伝送の最中に必要なＱｏＳが保証される。上述した通り、ＱｏＳの実施は、適用可能であれば２つのアクセスネットワークにおいて同時に実行可能である。

図７に関して上で説明した例は、リモートデバイスがホームネットワーク内のホームデバイス（例えば、メディアサーバ）からメディアをフェッチ又はダウンロードする事例に関するものである。しかしながら、図示される手順は、例えばリモートデバイスからホームデバイスへメディアを転送する時や、双方向におけるメディア伝送を伴うダイアログセッションの最中のように、いずれの方向での通信に対しても適用可能である。それゆえ、当業者によって容易に理解可能な通り、ホームデバイスからのメディアの閲覧及びメディアのフェッチを伴う説明された手順は、少々違うものとなるであろう。

図８は、例えば図４、５、及び７に関して上で説明したような手順においてホームネットワークの外に位置する場合にホームネットワーク（不図示）にアクセスするように構成されたリモートデバイス８００を示す概略ブロック図である。リモートデバイス及びホームネットワークのうちの少なくとも一方が、ＱｏＳを実施可能なアクセスネットワーク（不図示）に接続されている。

リモートデバイス８００は、マルチメディアセッションの最初の部分の最中のホームネットワークにおけるデバイスディスカバリ及び任意的なメディアの閲覧のために、ホームネットワーク内のマルチメディアゲートウェイ８０４へセッション招待メッセージを送信するように構成される送信ユニット８００ａを備える。そして、基本的に上述したように、セッションの最初の部分のために、アクセスネットワークにおいてＱｏＳが実施される。マルチメディアゲートウェイ８０４は、図に示すように、ＨＩＧＡであってもよい。

リモートデバイス８００は更に、セッションの２番目の部分の最中の、ホームネットワーク内の選択されたホームデバイスとのメディア通信のために、ＱｏＳを更新しなければならないか否かを判定するように構成される、判定ユニット８００ｂを備える。送信ユニット８００ａは更に、選択されたホームデバイスとのメディア通信のためにＱｏＳを更新するために、マルチメディアゲートウェイに対してセッション再招待メッセージを送信するように構成される。次に、基本的に上述したように、更新されたＱｏＳがアクセスネットワークにおいて実施される。

判定ユニット８００ｂは更に、メディア通信のメディアプロパティに基づいて、セッションの２番目の部分の最中のメディア通信のためにＱｏＳを更新しなければならないか否かを判定するように構成されてもよい。

図９は、例えば図４、５、及び７に関して上で説明した手順において前記ホームネットワークの外に位置するリモートデバイス９０２に対してホームネットワーク（不図示）へのアクセスを可能にするように構成された、マルチメディアサービスネットワーク内のセッション制御ノード９００を示す概略ブロック図である。リモートデバイス及びホームネットワークのうちの少なくとも一方が、伝送制御ノード９０６を用いてＱｏＳを実施可能なアクセスネットワーク９０４に接続されている。

セッション制御ノード９００は、セッションの最初の部分の最中のホームネットワークにおけるデバイスディスカバリ及び任意的なメディアの閲覧のために、ホームネットワークへ宛てられたセッション招待メッセージを、リモートデバイス９０２から受信するように構成される受信ユニット９００ａを備える。

セッション制御ノード９００は更に、セッションの最初の部分のためにアクセスネットワーク９０４の伝送制御ノード９０６においてＱｏＳを実施するように構成されるサービス品質（ＱｏＳ）実施ユニット９００ｂを備える。

受信ユニット９００ａは更に、セッションの２番目の部分の最中におけるホームネットワーク内の選択されたホームデバイスとのメディア通信のために、ホームネットワークに宛てられたセッション再招待メッセージを、リモートデバイス９０２から受信するように構成される。

セッション制御ノード９００は、最後に、メディア通信のためのセッションパラメータに基づいてセッションの２番目の部分のためにＱｏＳを更新するように構成されるＱｏＳ更新ユニット９００ｃを備え、ＱｏＳ実施ユニット９００ｂは更に、２番目のセッションのためにアクセスネットワーク９０４の伝送制御ノード９０６において更新されたＱｏＳを実施するように構成される。

セッション制御ノード９００は、マルチメディアサービスネットワークであるＩＭＳネットワーク内のＰ−ＣＳＣＦノードであってもよい。ＱｏＳ実施ユニット９００ｂは更に、セッションの最初の部分のためのＱｏＳをデフォルトＱｏＳとして選択するように構成されてもよいし、セッションの最初の部分のセットアップ中に交換されたセッションパラメータに基づいて選択するように構成されてもよい。

ＱｏＳ更新ユニット９００ｃは更に、セッションの２番目の部分のためのセッションパラメータを、リモートデバイスからのセッション再招待メッセージの中、又はホームネットワークからの応答メッセージの中、又はその両方の中に埋め込まれたＳＤＰメッセージから抽出するように構成されてもよい。交換されるセッションパラメータは、デバイス能力、及びメディアプロパティのうちの少なくとも一方を指し示してもよい。伝送制御ノードは、ＲＣＥＦ機能を含んでもよい。

図８及び図９はそれぞれ、内部で本発明を使用可能なリモートデバイス９００及びセッション制御ノード９００の中の多様な可視論理機能ユニットを示す。しかしながら、当業者は、適切なソフトウェア及びハードウェアを使用することにより、特定の図示される構造に限定されることなく、ここで説明される機能を実装することができるはずである。

上述した実施形態はこうして、例えばアプリケーション及び使用される装置のうちの少なくとも一方、並びに通信されるメディアに応じて、リモートデバイスとホームネットワーク内のホームデバイスとの間のメディア通信において満足のいく結果をもたらすように適合された適切な又は正確なＱｏＳを確立するために使用可能である。

特定の典型的な実施形態を参照して本発明を説明してきたが、この説明は概して、発明のコンセプトを示すことを意図したのみであり、本発明の範囲を限定するものとして受け取られるべきではない。上の実施形態を説明する際に全体を通してＩＭＳ、ＨＩＧＡ、及びＵＰｎＰというコンセプトが使用されてきたが、マルチメディア通信を可能にする任意の他の標準及びネットワークエレメントを基本的には使用することができる。例えば、ＩＭＳ、ＴＩＳＰＡＮ、及び／又はＵＰｎＰという標準が使用されているか否かに関わらず、汎用シグナリングプロトコルとしてＳＩＰを使用可能である。本発明は、概して、以下の独立請求項によって規定される。

Claims (17)

1. ホームネットワーク（４０２）と前記ホームネットワークの外に位置するリモートデバイス（４００）との間のマルチメディアセッションのためにアクセスネットワーク（４０４，４０６）においてサービス品質（ＱｏＳ）を確立する方法であって、前記リモートデバイス及び前記ホームネットワークのうちの少なくとも一方が前記アクセスネットワークに接続され、前記方法は、
   前記セッションの最初の部分の最中の、デバイスディスカバリと前記ホームネットワーク内のメディアの任意的な閲覧とのために、前記リモートデバイスからセッション招待メッセージを受信するステップと、
   前記セッションの前記最初の部分のために前記アクセスネットワークにおいてＱｏＳを実施するステップと、
   前記セッションの２番目の部分の最中の、前記ホームネットワーク内の選択されたホームデバイスとのメディア通信のために、前記ＱｏＳを更新するために、前記リモートデバイスからセッション再招待メッセージを受信するステップと、
   前記メディア通信のためのセッションパラメータに基づいて、前記セッションの前記２番目の部分のためのＱｏＳ要求条件を判定するステップと、
   前記判定されたＱｏＳ要求条件を満足するために、前記セッションの前記２番目の部分における前記メディア通信のために、前記アクセスネットワークにおいて更新されたＱｏＳを実施するステップと、
   を備えることを特徴とする方法。
2. 前記セッションの前記最初の部分のための前記ＱｏＳは、デフォルトＱｏＳとして選択されるか、又は、前記セッションの前記最初の部分のセットアップ中に交換されるセッションパラメータに基づいて選択されることを特徴とする請求項１に記載の方法。
3. 前記セッションの前記２番目の部分又は前記最初の部分のための前記セッションパラメータは、前記リモートデバイスからの前記セッション招待メッセージ／前記セッション再招待メッセージの中に、又は、前記ホームネットワークからの応答メッセージの中に、若しくはその両方の中に埋め込まれた、ＳＤＰメッセージから抽出されることを特徴とする請求項１又は２に記載の方法。
4. 前記交換されるセッションパラメータは、デバイス能力及びメディアプロパティのうちの少なくとも一方を指し示すことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記ＱｏＳ要求条件は、前記２番目のセッションのために判定され、前記ＱｏＳは、前記アクセスネットワークの接続先であるマルチメディアサービスネットワーク内のセッション制御ノードによって更新されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記マルチメディアサービスネットワークはＩＭＳネットワークであり、前記セッション制御ノードはＰ−ＣＳＣＦノードであることを特徴とする請求項５に記載の方法。
7. 前記ＱｏＳは、前記アクセスネットワーク内の伝送制御ノードにおいて実施されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記伝送制御ノードはＲＣＥＦ機能を含むことを特徴とする請求項７に記載の方法。
9. ホームネットワークの外に位置する時にリモートデバイスとして動作することにより前記ホームネットワークにアクセスするように構成される通信デバイス（８００）であって、前記通信デバイス及び前記ホームネットワークのうちの少なくとも一方がアクセスネットワークに接続され、
   前記通信デバイスは、マルチメディアセッションの最初の部分の最中の、デバイスディスカバリと前記ホームネットワーク内のメディアの任意的な閲覧とのために、前記ホームネットワーク内のマルチメディアゲートウェイ（８０４）へセッション招待メッセージを送信するように構成される送信ユニット（８００ａ）を備え、
   前記セッションの前記最初の部分のために前記アクセスネットワークにおいてサービス品質（ＱｏＳ）が実施され、
   前記通信デバイスは、前記セッションの２番目の部分の最中の、前記ホームネットワーク内の選択されたホームデバイスとのメディア通信のために、前記ＱｏＳを更新しなければならないか否かを判定するように構成される判定ユニット（８００ｂ）を備え、
   前記送信ユニット（８００ａ）は、前記選択されたホームデバイスとの前記メディア通信のために前記ＱｏＳを更新するために、前記マルチメディアゲートウェイへセッション再招待メッセージを送信するように更に構成され、
   前記更新されたＱｏＳは、前記セッションの前記２番目の部分のために前記アクセスネットワークにおいて実施される
   ことを特徴とする通信デバイス。
10. 前記判定ユニットは、前記セッションの前記２番目の部分の最中の、前記メディア通信のために、前記ＱｏＳを更新しなければならないか否かを、前記メディア通信のメディアプロパティに基づいて判定するように更に構成されることを特徴とする請求項９に記載の通信デバイス。
11. マルチメディアサービスネットワーク（９０６）内の、ホームネットワークの外に位置するリモートデバイスのためにホームネットワークへのアクセスを可能にするように構成されるセッション制御ノード（９００）であって、前記リモートデバイス及び前記ホームネットワークのうちの少なくとも一方が前記マルチメディアサービスネットワークに接続されたアクセスネットワークに接続され、前記セッション制御ノードは、
    セッションの最初の部分の最中の、デバイスディスカバリと前記ホームネットワーク内のメディアの任意的な閲覧とのための、前記ホームネットワークへ宛てられたセッション招待メッセージを前記リモートデバイスから受信するように構成され、前記セッションの２番目の部分の最中の、前記ホームネットワーク内の選択されたデバイスとのメディア通信のための、前記ホームネットワークへ宛てられたセッション再招待メッセージを前記リモートデバイスから受信するように更に構成される受信ユニット（９００ａ）と、
    前記セッションの前記最初の部分のために前記アクセスネットワークにおいてサービス品質（ＱｏＳ）を実施するように構成されるＱｏＳ実施ユニット（９００ｂ）と、
    前記メディア通信のためのセッションパラメータに基づいて前記セッションの前記２番目の部分のために前記ＱｏＳを更新するように構成されるＱｏＳ更新ユニット（９００ｃ）と、
    を備え、
    前記ＱｏＳ実施ユニット（９００ｂ）は、前記２番目のセッションのために前記アクセスネットワークにおいて前記更新されたＱｏＳを実施するように更に構成される
    ことを特徴とするセッション制御ノード。
12. 前記セッション制御ノードはＰ−ＣＳＣＦノードであり、前記マルチメディアサービスネットワークはＩＭＳネットワークであることを特徴とする請求項１１に記載のセッション制御ノード。
13. 前記ＱｏＳ実施ユニット（９００ｂ）は、前記セッションの前記最初の部分のための前記ＱｏＳを、デフォルトＱｏＳとして選択するか、又は、前記セッションの前記最初の部分のセットアップ中に交換されるセッションパラメータに基づいて選択するように更に構成されることを特徴とする請求項１１又は１２に記載のセッション制御ノード。
14. 前記ＱｏＳ更新ユニット（９００ｃ）は、前記リモートデバイスからの前記セッション再招待メッセージの中に、又は、前記ホームネットワークからの応答メッセージの中に、若しくはその両方の中に埋め込まれた、ＳＤＰメッセージから、前記セッションの前記２番目の部分のための前記セッションパラメータを抽出するように更に構成されることを特徴とする請求項１１乃至１３のいずれか１項に記載のセッション制御ノード。
15. 前記交換されるセッションパラメータは、デバイス能力及びメディアプロパティのうちの少なくとも一方を指し示すことを特徴とする請求項１１乃至１４のいずれか１項に記載のセッション制御ノード。
16. 前記ＱｏＳ実施ユニット（９００ｂ）は、前記アクセスネットワーク内の伝送制御ノードにおいて前記ＱｏＳを実施するように更に構成されることを特徴とする請求項１１乃至１５のいずれか１項に記載のセッション制御ノード。
17. 前記伝送制御ノードはＲＣＥＦ機能を含むことを特徴とする請求項１６に記載のセッション制御ノード。

Images