JP2009517917A - マルチメディア通信を可能にするための方法および装置 - Google Patents

Abstract

プライベートネットワークに接続された通信デバイス（３０２）にマルチメディアサービスへのアクセスを提供するための、マルチメディア・サービス・ネットワーク（３０４）に接続されたマルチメディアゲートウェイ（３００）における方法および装置を提供する。マルチメディアゲートウェイは、デバイスデータベース（３１６）、通信ユニット（３１２）、および論理ユニット（３１４）を含んでもよい。サービスＩＤが、マルチメディアゲートウェイに関連付けられ、サービスＩＤはマルチメディア・サービス・ネットワーク内で有効である。セッション要求が受信されると、プライベートネットワーク内の少なくとも１つのデバイスの代わりにセッションが確立され、その際、前記サービスＩＤと前記少なくとも１つのデバイスの性能とが使用される。これによって、選択された単数又は複数のデバイスについては、個別のサービスＩＤが必要ない。セッション要求が着信する要求のセッション招待である場合、前記少なくとも１つのデバイスが、セッションのための性能要件に基づいて選択される。

Description

本発明は、一般に、マルチメディア・サービス・ネットワークに接続されたマルチメディアゲートウェイを使ってマルチメディア通信を可能にするための方法および装置に関するものである。その結果、マルチメディアサービスへのアクセスが、プライベートネットワークに接続されたデバイス、特に、宅内ネットワーク内のさまざまなタイプの通信デバイスに提供されうる。

今日、例えば固定型もしくは移動型のコンピュータおよび電話のような、ＩＰ（インターネットプロトコル）を用いたパケットに基づくマルチメディア通信が可能な、各種の通信デバイスが利用できる。マルチメディアサービスは通常、多様な形式および組み合わせのメディアを表す、符号化されたデータの送信を伴う。本記述において「マルチメディア」という用語は、パケットに基づくＩＰ（インターネットプロトコル）転送技術を用いて通信されるメディアのいずれかの選択を一般的に表すために用いられるであろう。マルチメディアサービスは、例えば、音声、動画、静止画像、テキスト、文書、アニメーションなどのような多様なタイプのメディアを表すデータのパケット交換型通信を含む。

「ＩＰマルチメディア・サブシステム」（ＩＭＳ）と呼ばれるネットワーク・アーキテクチャが、パケット領域でマルチメディアサービスおよびマルチメディアセッションを取り扱うためのオープンスタンダードとして、第三世代パートナシップ・プロジェクト（３ＧＰＰ）によって開発された。ＩＭＳは、ＩＰトランスポートに基づくサービスを可能にするプラットフォームであり、使用されるアクセス技術に事実上依存せず、いずれの特定のサービスにも限定されない。従って、ＩＭＳネットワークは、マルチメディアセッションを制御するけれども、ペイロードデータの実際の転送には使われず、ペイロードデータは、アクセスネットワーク上、およびインターネットを含む何らかの中間トランスポートネットワーク上でルーティングされる。

図１は、ＩＭＳサービスネットワークを使ってマルチメディアサービスを提供するための基本的なネットワーク構造の典型的な略図である。１つ以上のマルチメディアサービスを含む通信セッションＳにおいて、移動端末Ａが、無線アクセスネットワーク１００に接続され、別のアクセスネットワーク１０２に接続されている固定端末Ｂと通信する。また、アクセスネットワーク１００および１０２を接続する、図示しない中間バックボーンネットワークがあってもよい。

ＩＭＳネットワーク１０４が、無線アクセスネットワーク１００に接続されて、端末Ａに関するセッションを取り扱っており、ここでネットワーク１００および１０４は、通常、１つのオペレータによって所有される。この例では、対応するＩＭＳネットワーク１０６は、端末Ｂに代わってセッションを取り扱っており、そして、２つのＩＭＳネットワーク１０４および１０６は、異なるオペレータによって制御されてもよい。あるいは、２つの通信端末は、もちろん、同じアクセスネットワークに接続されてもよいし、また、同じＩＭＳネットワークに属してもよいし、その両方であってもよい。また端末Ａは、例えば何らかのメディアをコンテンツプロバイダからダウンロードする目的で、代わりにサーバと通信してもよい。また、端末が、在圏アクセスネットワーク内でローミング中の場合、マルチメディアサービスは、端末の「ホーム」ＩＭＳネットワーク、すなわち、それが加入者として登録されているネットワークによって取り扱われる。

図１に示すセッションＳは、ここでは「セッション管理ノード」１０８と総称される、各ＩＭＳネットワーク内の特定のノードによって管理される。これらのノードは通常、Ｓ−ＣＳＣＦ（サービング呼セッション制御機能）と、Ｉ−ＣＳＣＦ（インテロゲーティング呼セッション制御機能）と、そして、Ｐ−ＣＳＣＦ（プロキシ呼セッション制御機能）とを含む。またＩＭＳネットワーク１０４および１０６はそれぞれ、各種のマルチメディアサービスを可能にするための１つ以上のアプリケーションサーバ１１０を含む。さらに、主要なデータベース要素であるＨＳＳ（ホーム加入者サーバ）１１２が、加入者データおよび認証データ、および、特に、サービス情報を記憶する。ＩＭＳネットワーク１０６は、ネットワーク１０４と基本的に同様である。図示するネットワーク要素１０８乃至１１２の各種の固有の機能は、当該分野では一般に知られており、本発明の文脈を理解するためにここでこれ以上記述する必要はない。もちろん、ＩＭＳネットワーク１０４および１０６は、簡潔にするためにここでは図示しない、他のノードおよび機能を多数含んでいる。

「ＳＩＰ」（セッション開始プロトコル：ＩＥＴＦ ＲＦＣ３２６１標準に準拠）と呼ばれる仕様が、ＩＭＳネットワーク内のセッションを取り扱うために使用される。ＳＩＰは、パケット交換型論理上でセッションを開設して一般的に取り扱うための、アプリケーションレイヤのシグナリング制御プロトコルである。従ってＳＩＰ標準は、ＩＰマルチメディア通信を確立して制御する目的で、ＩＭＳシステムおよび端末によって用いられることができる。ＳＩＰ自身は、マルチメディアサービスを提供するのではなく、そのようなサービスを実際に実装する目的で他のプロトコルまたはアプリケーションが使用しうる一連のプリミティブが利用できるようにする。例えば、ＳＩＰでは、あるアプリケーションが呼び出された際に、セットアップ手順の間にセッションを開始するための、「ＩＮＶＩＴＥ」と呼ばれるメッセージが定義される。

ＳＩＰでは、「セッション記述プロトコルＳＤＰ」と呼ばれる追加のプロトコルが用いられるが、これは、自己完結したボディとしてＳＩＰメッセージの中に埋め込まれることのできるＳＤＰメッセージを使ってマルチメディアセッションを記述するためのプロトコルである。従って、当該技術分野ではよく知られているとおり、今度のマルチメディアセッションの間にどのセッションパラメータ、特にメディアのためのコーデックおよびＩＰアドレスとポートと、を使用するかについて交渉して合意することを目的として、端末固有の性能とプリファレンス（好み）とに関する情報を提供するために、ＳＤＰが端末によって使用されることができる。上述のＳＩＰ ＩＮＶＩＴＥメッセージは、今度のセッションに必要な、１つ以上の必要とされるコーデック（符号化器／復号器）およびその他の通信パラメータに関する情報を備えたＳＤＰメッセージを含む。

３ＧＰＰによると、ＩＭＳネットワークにアクセスする加入登録を行う通信端末は、必要な認証データおよび加入者データをＩＭＳネットワークのオペレータに提供することを目的として、ＩＭＳ ＳＩＭすなわち「ＩＳＩＭ」（ＩＭＳ加入者ＩＤモジュール）アプリケーションにアクセスすることが必要とされる。現時点では、ＩＭＳ対応端末だけが、ＩＭＳネットワークにアクセスすることを許可される。

ＩＳＩＭアプリケーションは通常、よく知られたＧＳＭ端末用のＳＩＭカードに類似した汎用ＩＣカード（ＵＩＣＣ）上にインストールされる。ＩＳＩＭを備えた端末は、「ＩＭＳ対応」端末と呼ばれる。特にＩＳＩＭは、「ＩＭＰＩ」と呼ばれるＩＭＳプライベート・アイデンティティと「ＩＭＰＵ」と呼ばれる少なくとも１つのＩＭＳパブリック・アイデンティティとを記憶しており、それらは両方共ＩＭＳネットワークに知られている。ＩＭＰＩは、認証用に使われ、第三者には開示されないが、他方、ＩＭＰＵは、電子メールアドレスもしくは電話番号と同様、ＩＭＳサービスに参加している場合には加入者および彼らの装置のうちの少なくとも一方を識別するため誰によって使われてもよい。その意図とは、各ＩＭＰＵが、ＩＭＳサービスプロファイルに関連付けられることである。

ＩＭＳの概念は元々、モバイルＩＰ端末用のマルチメディアサービスを可能にするため考案されたのだが、上記のように、アクセス技術に関わらず使われることができる。欧州電気通信標準化協会（ＥＴＳＩ）では、ＴＩＳＰＡＮ（高度ネットワークのための電気通信およびインターネットのサービスおよびプロトコル）と呼ばれる作業部会が現在、固定ネットワークにおけるＩＭＳの導入について作業中である。また、ローカルネットワークまたはプライベートネットワーク、特に、例えば従来型のＬＡＮ（ローカルエリアネットワーク）設備およびプロトコルを用いた宅内ネットワーク環境またはオフィス用のネットワーク環境に接続する各種のＩＰ端末に、そのようなＩＭＳベースのサービスを提供することも、望ましいことである。以下の記述においては、「プライベートネットワーク」という総称は、ＬＡＮ、ＷＡＮ（ワイドエリア・ネットワーク）およびＷＬＡＮ（ワイヤレスＬＡＮ）を含めて、そのようないずれのネットワークを表すのにも用いられるであろう。さらに、「デバイス」という用語は、プライベートネットワーク内のＩＰ通信が可能ないずれの端末についても用いられるであろう。

プライベートネットワークは、たとえ「ＳＩＰ対応」であるかもしれないにしてもＩＭＳ対応でない固定通信デバイスもしくはワイヤレス通信デバイスを含んでもよいし、他方、プライベートネットワーク内のその他の通信デバイスは、ＩＭＳ対応でもなくＳＩＰ対応でもなくてもよい。例えば、そのような単純なデバイスには、固定電話およびコードレス電話、並びにパソコン、およびテレビ用のいわゆるＳＴＢ（セットトップボックス）が含まれてもよい。そのような既存の「ホームデバイス」が多量に存在することから、マルチメディアサービスの市場を充実させる目的で、非ＩＭＳデバイスとＩＭＳネットワークとの間で相互動作するソリューションの提供が望まれるようになる。

例えばプライベートの宅内ネットワークまたはオフィス用ネットワークに接続されたＩＭＳ非対応通信デバイスにＩＭＳサービスを提供することを目的として、それに接続するいずれかの通信デバイスに代わってＩＭＳ対応端末として動作できる「ホームＩＭＳゲートウェイ（ＨＩＧ）」と呼ばれるマルチメディアゲートウェイが、定義済みである。このタイプのホームＩＭＳゲートウェイは、出願人の以前の特許出願ＰＣＴ／ＥＰ２００５／０５５２４８の中に記述されている。特に、ＨＩＧは、ＳＩＰ対応であるがＩＭＳ非対応のデバイスとＩＭＳネットワークとの間で相互作用するためのＳＩＰ「バック・ツー・バック・ユーザエージェント（Ｂ２ＢＵＡ）」を含む。Ｂ２ＢＵＡは、ＩＳＩＭアプリケーションを備えており、ＳＩＰデバイスに関するすべてのシグナリングが、ＩＳＩＭアプリケーション上の対応するＩＭＰＩに関連付けられるように、ＳＩＰデバイスに代わってＩＭＳシグナリングを取り扱う。例えば、ＳＩＰ対応デバイスは、ＳＩＰ ＩＤだけを含むＳＩＰ ＲＥＧＩＳＴＥＲメッセージを、ＨＩＧに送信することができる。次いでＨＩＧは、そのメッセージを、通常のＩＭＳ手順に従って、ＩＭＰＩとＩＭＰＵとを両方含むＩＭＳ ＲＥＧＩＳＴＥＲメッセージに翻訳するであろう。

ＨＩＧを使用する典型的なシナリオの概要を図２に示し、プライベートネットワーク２０２の中に一緒に結合されている複数の異なるＩＰ通信デバイスを含む、例えば家庭住宅またはオフィスのような、プライベート環境または「ホーム」環境２００を図解する。ここで図解するように、これらのデバイスには、固定電話、コードレス電話、テレビ、サーバ、およびパソコンが含まれることがあり、以下これらを単純に「デバイス」と呼ぶことにしよう。

プライベートネットワーク２０２は、外部アクセスネットワーク２０６に接続してメディアＭのためにネットワーク２０２内のデバイスへのおよびデバイスからの通信リンクを提供する、従来型レジデンシャルゲートウェイＲＧＷ２０４を含む。ここでは具体的に図解されていないが、ＲＧＷ２０４は通常、ＮＡＴ（ネットワークアドレス変換）機能およびファイアウォール機能を含み、また当該技術分野ではよく知られているように、プライベートＩＰアドレスをデバイスに提供するローカルＤＨＣＰ（ダイナミックホスト構成プロトコル）サーバも含む。

プライベートネットワーク２０２はさらに、ここでは特にＨＳＳ２１２を含むＩＭＳコア２１０として図解されるＩＭＳネットワークへの接続を提供するＨＩＧ２０８を含む。ＨＩＧ２０８は、デバイス固有のプロトコルを用いたシグナリングのための、さまざまなタイプのデバイスに対するインタフェースを備える。特許出願ＰＣＴ／ＥＰ２００５／０５５２４８において、各種のインタフェースとプロトコル変換とゲートウェイ機能とを含めて、ＨＩＧの基本的な機能的アーキテクチャが詳細に記述されている。しかし、これらの構成の詳細をここでこれ以上記述することは、本発明を理解するのに必要ではない。実際には、記述されたＨＩＧの機能は、別個のノードとして、またはＲＧＷの中で、あるいはＩＭＳ対応端末の中でさえ、実装されてもよい。しかし、本記述においては、実装には関係なく、別個の機能ユニットであるとみなす。

ＨＩＧ２０８では、ネットワーク２０２の中の各デバイスについて、典型的には上記のＩＭＰＵを含むＩＤ情報２１４が記憶され、ＩＤ情報２１４は、図示するように、同じＩＤ情報がＨＳＳ２１２の中に加入者情報２１６としても記憶されているＩＭＳコア２１０にアクセスするのに有効である。特許出願ＰＣＴ／ＥＰ２００５／０５５２４８は、この文脈の中でＩＭＰＩとＩＭＰＵとのさまざまな組み合わせがどのように使われうるかを概説する。従って、ネットワーク２０２の中の各デバイスは、例えばＩＭＰＵを含む、そのローカルＩＰアドレスに関連する有効なＩＭＳ ＩＤを割り当てられている。ＩＤ情報２１４は通常、ＨＩＧ２０８の中に実装されたＩＳＩＭアプリケーションの中に記憶される。

従って、ネットワーク２０２の中のデバイスが、その性能の範囲内のプロトコルを用いてＩＭＳサービスを求める要求を送信する場合、ＨＩＧ２０８は、そのデバイスのローカルＩＰアドレスを使ってデバイスを識別し、そのデバイスに関連するＩＭＳ ＩＤ２１４を引き出す。次いでＨＩＧは、引き出されたＩＭＳ ＩＤ２１４を用いて、受信したサービス要求を変換して有効なＳＩＰベースのＩＭＳ要求（例えばＳＩＰ ＩＮＶＩＴＥ）をデバイスに代わって生成することができる。次いでＨＩＧ２０８はそれゆえ、適切なＳＩＰメッセージをＩＭＳコア２１０と通信することによって、デバイスのためのセッションをセットアップするであろう。

同様にして、デバイスのうちの１つに宛てられたかまたは一般的にプライベートホームまたはオフィスに宛てられた、ＩＭＳサービスに関係する着呼は、デバイスに関連するＩＭＳ ＩＤ２１４を用いてデバイスに代わってＨＩＧによってセットアップされてもよい。呼は、次いで、メディアＭを通信するために、ＲＧＷ２０４を介して宛先デバイスまでルーティング可能である。このようにして、ＩＭＳコアは、デバイス２０２をＩＭＳ対応のデバイスとして認識するであろうし、デバイスは、ＨＩＧ２０８を、ＩＭＳネットワークを使って提供されるサービスにアクセスするためのプロキシとして使用するであろう。

しかし、この手順は、ＨＩＧの中で、必要な認証データを含む有効なＩＭＳ ＩＤがプライベートネットワーク２０２の中の各デバイスに割り当てられなければならないことを必要とする。ＩＭＳネットワークオペレータは通常、ＩＭＳ ＩＤを付与するが、それらも、ＨＳＳ２１２の中に記憶される加入者情報としてＩＭＳネットワーク内に登録されなければならない。デバイスがネットワークに追加される度に、新規のＩＭＳ ＩＤがそれに割り当てられなければならない。従って、デバイスがローカル環境、すなわち、プライベートネットワーク２０２に追加されるかそこから除去される度に、位置２０８および２１２でのＩＭＳ ＩＤのセットアップが修正されなければならない。

この幾分柔軟性に欠けるソリューションは、望ましくない管理負荷をユーザとＩＭＳオペレータとに与え、しかも、ＩＭＳ ＩＤ、例えばＩＭＰＵをどのようにユーザが取り扱うべきなのかが、明白でない。その上、管理が必要な多数のＩＭＳ ＩＤおよび加入登録によってＩＭＳネットワークに負荷がかかるかもしれない。従って、ＩＭＳ非対応デバイスにＩＭＳサービスへのアクセスを提供するための、もっと柔軟性があって便利なソリューションが望まれる。

上記に概説した諸問題をおおむね回避するかまたは少なくとも減らすことが、本発明の目的である。具体的には、プライベートネットワーク内の各デバイスへのＩＭＳ ＩＤの個別の割り当てを回避できるようにすることが、本発明の目的である。

これらの目的などは、下記に添付された独立請求項による方法とマルチメディアサービスゲートウェイとを提供することによって、達成される。

マルチメディア・サービス・ネットワークに接続しているマルチメディアゲートウェイを使って、プライベートネットワークに接続している通信デバイスにマルチメディアサービスへのアクセスを提供する本発明の方法において、セッション要求が、最初に受信される。次いでセッションが、セッション要求に応えて、プライベートネットワークの中の少なくとも１つのデバイスに代わっての交渉手順の中で、マルチメディアゲートウェイに関連する有効なサービスＩＤを用いて、そして少なくとも１つのデバイスの性能を用いて、確立される。

第１の例において、セッション要求は、プライベートネットワークへの着信要求のセッション招待であってもよく、そして、次いで、前記少なくとも１つのデバイスが、セッションのための性能要件に基づいて前記通信デバイスから選択される。性能要件は、受信されたセッション招待の中で推奨セッションパラメータによって示されてもよく、そして、次いで、セッションパラメータが、前記少なくとも１つのデバイスを選択するために、プライベートネットワーク内のデバイスの性能と比較される。デバイスの性能は、マルチメディアゲートウェイの中のデバイスデータベースから引き出されてもよいし、それらを要求することによってデバイスから引き出されてもよい。デバイスの性能は、少なくとも１つのメディアコーデックと、伝送速度性能と、記憶容量とのうち少なくとも１つを指してもよい。

セッション招待は、ＳＩＰ ＩＮＶＩＴＥメッセージでもよい。また、推奨セッションパラメータが、ＳＩＰ ＩＮＶＩＴＥメッセージの中に埋め込まれるＳＤＰメッセージの中に含まれてもよい。前記少なくとも１つのデバイスは、さらに所定の規則もしくはポリシーに基づいて選択されてもよい。また、さまざまな組み合わせのメディアストリームを受信するため、または選択されたデバイス上で同時に同じ単数又は複数のメディアストリームを受信するため、複数のデバイスが、セッションのために選択されてもよい。

プライベートネットワーク内の特定の個人およびデバイスのうちの少なくとも一方についてマルチメディアゲートウェイの中で個別のサービスＩＤが割り当てられ、それによって、前記個人およびデバイスのうちの少なくとも一方に代わってそれらの対応する個別サービスＩＤおよび性能を用いてマルチメディアセッションを確立可能なようにしてもよい。

第２の例において、セッション要求は、プライベートネットワークの要求側デバイスから発信される要求に関係してもよく、次いで、要求側デバイスの性能が、セッションを確立する際に使用される。要求側デバイスの性能は、マルチメディアゲートウェイの中のデバイスデータベースから引き出されてもよい。

セッション固有情報が、セッションマッピングテーブルの中に記憶されてもよく、それが、セッションに関連する更なるシグナリングに使われることもできる。セッション固有情報は、セッションを定義（規定）する呼ＩＤと、前記少なくとも１つのデバイスのローカルＩＰアドレスおよび選択されたポートと、プライベートネットワークの宅内（レジデンシャル）ゲートウェイの予約されたポートと、リモート当事者のＩＰアドレスとを含んでもよい。マルチメディアゲートウェイに関連するサービスＩＤは、ＩＭＰＵを含んでもよい。

プライベートネットワークに接続された通信デバイスにマルチメディアサービスへのアクセスを提供するための、マルチメディア・サービス・ネットワークに接続されたマルチメディアゲートウェイにおける本発明の装置は、セッション要求を受信する手段と、マルチメディアゲートウェイに関連する有効なサービスＩＤを用いて、かつ、前記少なくとも１つのデバイスの性能を用いて、前記セッション要求に応えてプライベートネットワーク内の少なくとも１つのデバイスに代わって交渉手順においてセッションを確立する手段とを、含む。

セッション要求が、プライベートネットワークに着信する要求のセッション招待である場合、本装置はさらに、セッションのための性能要件に基づいて前記少なくとも１つのデバイスをプライベートネットワーク内の前記通信デバイスから選択するように構成された論理ユニットを含む。性能要件は、受信されたセッション招待の中で推奨セッションパラメータによって示されてもよく、そして、次いで、論理ユニットは、前記少なくとも１つのデバイスを選択するために、プライベートネットワーク内のデバイスの性能と前記セッションパラメータとを比較するように、さらに構成されてもよい。

論理ユニットはさらに、プライベートネットワーク内のデバイスの前記性能をマルチメディアゲートウェイの中のデバイスデータベースから引き出すように構成されてもよいし、あるいはそれらを要求することによってデバイスから引き出すように構成されてもよい。前記デバイスの性能は、少なくとも１つのメディアコーデックと、伝送速度性能と、記憶容量とのうち少なくとも１つを指してもよい。セッション招待は、ＳＩＰ ＩＮＶＩＴＥメッセージでもよい。また、推奨セッションパラメータは、ＳＩＰ ＩＮＶＩＴＥメッセージの中に埋め込まれるＳＤＰメッセージの中に含まれてもよい。

論理ユニットはさらに、さらに所定の規則もしくはポリシーに基づいて、前記少なくとも１つのデバイスを選択するように構成されてもよい。論理ユニットはさらに、さまざまな組み合わせのメディアストリームを受信するため、または選択されたデバイスについて同時に同じ単数又は複数のメディアストリームを受信するため、セッションのために複数のデバイスを選択するように構成されてもよい。

本装置はさらに、プライベートネットワーク内の特定の個人およびデバイスのうちの少なくとも一方についてマルチメディアゲートウェイの中で個別のサービスＩＤを割り当てるための手段を含んでもよく、それによって、前記個人およびデバイスのうちの少なくとも一方に代わってそれらの対応する個別サービスＩＤを用いてマルチメディアセッションを確立可能なようにしてもよい。

セッション要求が、プライベートネットワークの要求側デバイスから発信される要求に関係する場合、本装置はさらに、セッションを確立する際に要求側デバイスの性能を使用する手段を含んでもよい。本装置はさらに、マルチメディアゲートウェイの中のデバイスデータベースから要求側デバイスの前記性能を引き出す手段を含んでもよい。

本装置はさらに、セッションに関係する更なるシグナリングのために用いられうる、セッションマッピングテーブルの中のセッション固有情報を記憶する手段を含んでもよい。セッション固有情報は、セッションを定義する呼ＩＤと、前記少なくとも１つのデバイスのローカルＩＰアドレスおよび選択されたポートと、プライベートネットワークのレジデンシャルゲートウェイの予約されたポートと、リモート当事者のＩＰアドレスとを含んでもよい。マルチメディアゲートウェイに関連するサービスＩＤは、ＩＭＰＵを含んでもよい。

本発明の更なる特徴および利点の可能性については、以下の詳細記述の中で説明しよう。

次に本発明について、好適な実施形態を用いて、そして添付の図面を参照しながら、より詳細に記述しよう。

簡単に言うと、本発明は、プライベートネットワークに接続しているいかなるＩＰ通信デバイスについても、マルチメディアゲートウェイに関連する共有されたサービスＩＤ（共有サービスＩＤ）を使ってマルチメディア通信を可能にする。従って、マルチメディア・サービス・ネットワーク内で有効な共有サービスＩＤが、プライベートネットワーク内のデバイスに代わってサービスネットワークにアクセスするためのマルチメディアゲートウェイによって、使用される。プライベートネットワークに接続している複数のデバイスのために共有サービスＩＤを使用することによって、マルチメディアサービスにアクセス可能にすることを目的として特定の個別のサービスＩＤを各デバイスに割り当てる必要はなくなる。従って、プライベートネットワーク内の複数のデバイスにサービスを提供するためには、マルチメディアゲートウェイとそのＩＤとをマルチメディア・サービス・ネットワークに登録すれば十分であり、そうすればサービスネットワーク内の登録の数を減らすことになるであろう。さらなる利点は、下記の本発明の実施形態の詳細記述の中で明らかになるであろう。

本記述において、マルチメディアゲートウェイは、ＩＭＳ（ＩＰマルチメディアサブシステム）ネットワークに接続しているＨＩＧ（ホームＩＭＳゲートウェイ）と呼ぶことにする。しかし本発明は、基本的にこれらの具体的な用語に限定されず、また、下記で言及されるいかなる特定のプロトコルおよび標準にも限定されない。

図３は、一実施形態によって、着呼のためのマルチメディアセッションをセットアップするのに使われるマルチメディアゲートウェイすなわちＨＩＧ３００を図解する。図２と同様、ＨＩＧ３００は、プライベートネットワーク内の複数のデバイス３０２と、ここではＩＭＳネットワーク３０４として示すマルチメディア・サービス・ネットワークとの間の、ゲートウェイである。図示するデバイス３０２は、ちょうど図２について上述したように、ＩＭＳ非対応であることが想定されているが、本発明はＩＭＳ対応のデバイスの使用も除外しているわけではない。ＨＩＧ３００には、接続された各デバイスに適合されたインタフェースとプロトコルとが備わっている。

ＨＩＧ３００は、点線のボックスで示すように、ＩＭＳネットワーク３０４の中で有効であってＨＳＳ３０６の中に加入登録として記憶されるＩＭＳ ＩＤを有する。現行の標準によると、必要とされるＩＭＳ ＩＤは、ＩＭＰＩ／ＩＭＰＵの組み合わせを含むが、一般的に本発明は、この点では限定されない。ＨＳＳ３０６はさらに、図示されないが、ＩＭＳ ＩＤに関連する加入者データおよび認証データを記憶する。従って、ＩＭＳネットワークがＨＩＧを１個のＩＭＳ端末として認識するように、ＨＩＧ３００は、いかなるＩＭＳ対応通信端末とも同等な加入者としてＩＭＳネットワーク３０４に登録される。そうすれば、すべてのＩＭＳ非対応デバイスは、いったんローカルにＨＩＧに登録されると、ＨＩＧのＩＤを用いて到達されることができる。

プライベートネットワーク内のデバイス３０２は、さらに、従来型ネットワークゲートウェイＲＧＷ３０８に接続され、それが次には、メディアの通信のために、アクセスネットワーク３１０に接続される。ＨＩＧ３００は、シグナリングメッセージをＩＭＳネットワーク３０４と通信するための通信ユニット３１２と、マルチメディア通信のためにプライベートネットワーク内のデバイスを識別して選択するための論理ユニット３１４とを含む。ＨＩＧ３００は、さらに、デバイス３０２のローカルＩＤ、ローカルＩＰアドレス、現在のステータス、マルチメディア通信に関する性能に関して、ここではＤ１、Ｄ２、Ｄ３、、、として概略的に示す情報を含む、デバイスデータベース３１６を備えている。

デバイスデータベース３１６は、マルチメディアセッションに適したデバイスを、例えばセッションの性質に応じて、選択するために使用可能である。デバイスデータベース３１６は、デバイスがプライベートネットワークに入り、ＨＩＧにローカルに登録する際に、段階的に構築される。非ＩＭＳデバイスは、デバイスのタイプに応じて、例えばＵＰｎＰ（ユニバーサル・プラグアンドプレイ）あるいはＳＩＰのような、適切なプロトコルを用いてＨＩＧ３００に登録してもよいし、あるいは自動登録を円滑化するのであれば他のいかなる適切な手段を用いてもよい。デバイスデータベース３１６は、下記の構造に従って構成されてもよい。

第１列では、ローカルＩＤが各デバイスについて指定され、それは例えばＵＰｎＰデバイスについてはＵＵＩＤ（汎用的一意識別子）、ＳＩＰデバイスについてはＳＩＰ ＵＲＩ（ユニフォーム・リソース・ロケータ）、ホスト名が自分のＩＰアドレスであり得る非ＳＩＰかつ非ＵＰｎＰのデバイスについてはＦＱＤＮ（完全修飾ドメイン名）であってもよい。第２列は、上述のように一時的にＲＧＷによって割り当てられた、各デバイスのためのローカルＩＰアドレスを含む。第３列では、例えば利用可能、利用不可能、使用中といった各デバイスのステータスが指定される。最後の列では、各デバイスについての性能が指定され、通常、１つ以上のコーデックを含むが、伝送速度の性能や記憶容量も含んでよい。

次に、着呼の場合にプライベートネットワーク内のデバイスのためにマルチメディアセッションを確立する手順について、図３に示すステップ３：１乃至３：８を参照しながら記述しよう。第１のステップ３：１において、ＨＩＧ３００の中の通信ユニット３１２は、例えば図示しないＩＭＳ対応端末のような別の当事者からＨＩＧのＩＭＳ ＩＤの公開ＩＤ部分に宛てて送信されたセッション招待（インビテーション）をＩＭＳネットワーク３０４から受信する。セッション招待は、特に、例えばコーデックのような推奨(proposed)セッションパラメータを含んでおり、典型的には、この情報を含んだＳＤＰメッセージを伴ったＳＩＰ ＩＮＶＩＴＥメッセージである。

次いで、推奨セッションパラメータは、次のステップ３：２において論理ユニット３１４へ提出され、論理ユニット３１４は、例えばＳＤＰの中の推奨パラメータをデバイスデータベース３１６の中の情報と次のステップ３：３で比較することによって、「マッピング」動作を実行する。デバイス３０２についてデータベース３１６の中の各種の情報を検討した後、それらのうちの１つが、そのデバイスの現在のステータスが利用可能であると示されていることを条件として、例えばその性能および推奨メディアフォーマットに関して今後のセッションについて最適なデバイスであるとして、選択される。あるいは、性能は、ステップ３：３でデータベース３１６から引き出される代わりに、例えば単純なＩＰデバイス用のＵＰｎＰプロトコルを用いて、直接デバイスに要求されてもよい。この手順が、デバイスの性能を引き出するのに使われる場合、それらをデータベース３１６に記憶させる必要はない。

またデータベース３１６は、プライベートネットワーク内のユーザが、例えばメディアタイプおよび発信者が誰なのかのうちの少なくとも一方に応じて、ある呼を特定のデバイス上で受信することを好むというような、優先順位の表示を含んでもよい。例えば、他の呼は、別のもっとオープンな場所にある電話で受信されることが好まれる一方で、ユーザが、特定の当事者からの呼を自分の個室に位置する電話で受信することを好むことがある。あるいは、そのような優先順位が、選択動作を命令する論理ユニット３１４の中で、規則もしくはポリシーとして定義されてもよい。

また、セッションのために複数のデバイスを選択することも可能である。例えば、最適な再生品質を達成するため、さまざまな組み合わせのメディアストリームをさまざまなデバイス上で受信することが望ましいことがある。また、同じ（単数又は複数の）ストリームが、異なる位置等にある複数のデバイスに同時に受信されてもよい。しかし、下記の記述は、簡潔にするために、デバイスを１つだけ選択することを対象とするであろう。一般に、何らかの規則もしくはポリシーは、好ましくは論理ユニット３１４の中に実装される、デバイスを選択するためのアルゴリズムのようなものとして定義することができる。それゆえ、本発明は、この点で大きな柔軟性を提供する。

デバイスを選択した後、次のステップ３：４において、通信ユニット３１２が、ＨＩＧのＩＭＳ ＩＤを用いて、選択されたデバイスに代わってＩＭＳネットワーク３０４に対するマルチメディアセッションを確立するように命令される。また、このステップにおいて論理ユニット３１４は、セットアップ手順の間に使用される選択されたデバイスの性能データを、通信ユニット３１２に提出する。

次に通信ユニット３１２は、選択されたデバイスの通信リンクを一般的に確立することを目的として、次のステップ３：５でＲＧＷ３０８と通信する。このステップは、例えば内部のＵＰｎＰコントロールポイントを介して、セッションの１つ以上のメディアストリームのためにＲＧＷ３０８のＮＡＴ／ファイアウォールにおいて開くポートを予約することを含んでもよい。次いで通信ユニット３１２は、選択されたデバイスに代わって発信者側とセッションをセットアップすることを目的として、以下のステップ３：６で一般的に示されているように、例えばＳＩＰによって、従来のシグナリングメッセージをＩＭＳネットワークと交換する。セットアップ手順において、通信ユニット３１２は、上記のステップ３：４で受信した、ＨＩＧの共有ＩＭＳ ＩＤと選択されたデバイスの性能データと、ステップ３：５で受信した、ＲＧＷのＩＰアドレスとポートとを用いて、最初に受信したステップ３：１のセッション招待に応答するが、それらは、適切なＳＩＰ応答メッセージの中に埋め込まれたＳＤＰメッセージの中でＩＭＳネットワーク３０４に提供されてもよい。また応答の中で通信ユニット３１２は、パブリックＩＰアドレスとＲＧＷ３０８の選択されたポートとを今度のセッションのための連絡先として提供するが、それらもＳＤＰの中で与えられる。リモートの当事者とのセッションセットアップが完了すると、通信ユニットはリモートの当事者のＩＰアドレスを受信済みということになる。

さらに通信ユニット３１２は、リモートの当事者のＩＰアドレスとＲＧＷ３０８の予約ポートとを、前のステップ３：３においてデータベース３１６の中で発見された、選択されたデバイスのローカルＩＰアドレスと関連付ける。また、このＩＰアドレスのペアは、典型的には最初の受信されたセッション招待メッセージであるＳＩＰ ＩＮＶＩＴＥの中で与えられた、セッションを定義する呼ＩＤに関連付けられる。このセッション固有情報は、ＨＩＧ３００の中のセッションマッピングテーブルの中に記憶されるが、これは、このセッションに関係するさらなるシグナリングのために用いることができる。セッションマッピングテーブルは、以下の構造を有してもよい。

第１列では、発信者ＩＤおよび呼ＩＤによってＩＭＳセッションが定義される。第２列は、リモート当事者のパブリックＩＰアドレスを含む。さらに、第３列は、上記のステップ３：５で要求された、選択された／予約されたＲＧＷのポートを含む。第４列では、デバイスのローカルＩＰアドレスとその中のローカルポートとが指定される。最後の列では、選択されたデバイスについてのローカルＩＤが指定され、それは例えばＵＵＩＤか、ＳＩＰ ＵＲＩか、またはＦＱＤＮであってもよいが、すなわち、基本的に、デバイスデータベース３１６の中の上記のテーブルの第１列からの情報である。

次に通信ユニット３１２は、ステップ３：７で、例えばリモート当事者のＩＰアドレスなどの最後に交渉されたパラメータも含めて、ＮＡＴ内の予約されたポートのマッピングを開けるようにＲＧＷに要求する。最後に、ステップ３：８でセッションが開始可能になり、着信するあらゆるメディアは、ＲＧＷ３０８の中のＮＡＴによって、選択されたデバイスのローカルＩＰアドレスとポートとにマッピングされる。

上記で述べたように、着呼の今度のセッションのためにデバイスを選択する手順は、種々の規則もしくはポリシーによって実行可能であり、それについては以下でより詳細に記述されるであろう。また、ここで留意されるべきだが、本発明は、ＨＩＧ３００のＩＭＳ ＩＤに加えて、ある個人およびパーソナルデバイスのうちの少なくとも一方のためには個別のＩＭＳ ＩＤを使用することを排除するものではない。ここで、「パーソナルデバイス」という用語は、デバイスが、例えば個別のＩＭＰＵを含めて、ＨＩＧの中で定義されている自分自身のＩＭＳ ＩＤを持つことを意味する。また、ユーザが、プライベートネットワーク内のいずれかのデバイス上での通信のために個別のＩＭＰＵを使用することも可能である。このように、対応するパーソナルデバイスもしくは個人に代わってマルチメディアセッションを確立する目的で、個別のＩＭＳ ＩＤが、ＨＩＧによって使用されてもよい。

個別のＩＭＳ ＩＤ宛ての着呼は、当然、そのＩＭＳ ＩＤに関連付けられた１つ以上のパーソナルデバイスに接続されるであろう。例えば、家族の一員が、ＨＩＧの共有ＩＭＳ ＩＤに関連付けられた共有デバイスだけでなく、自分の個別ＩＭＳ ＩＤに関連付けられた１つ以上のパーソナルデバイスを有してもよい。共有ＩＭＳ ＩＤ宛の着呼については、パーソナルデバイスは、デバイスを選択する選択肢として含まれることになる、共有デバイスとして動作してもよい。

従って、デバイスの選択を命令するために、プライベートネットワーク内のデバイスのさまざまなサブセットが定義されてもよく、そして、ＨＩＧの中でそのようなデバイスのサブセットを登録するかどうかは、そのユーザ次第である。ＨＩＧのＩＭＳ ＩＤ宛の呼は、結果として共通デバイスのグループから１つのデバイスを選択することになるであろうし、他方、個別のＩＭＳ ＩＤ宛の呼は、関連するパーソナルデバイスを選択することを意味するであろう。個別のＩＭＳ ＩＤに複数のデバイスが関連付けられてもよい。さらに、特定のデバイスが、着呼に関して、共通デバイスとパーソナルデバイスの両方として動作してもよい。

例えばＳＩＰ ＩＮＶＩＴＥのＳＤＰメッセージの中で指定されるような、着信するセッション招待の中で推奨される性能を複数のデバイスがサポートする場合（上記の例のステップ３：３と比較されたい）、デバイスを選択するため、更なる因子が考慮されてもよい。例えば、ここではこれ以上記述しない何らかのユーザインタフェースを介して着信する呼のためにデバイスを割り当てるようにユーザが要求されてもよい。また、性能要件に合致するすべてのデバイスに呼を受信させること、すなわち、複数のデバイスを鳴らし、最初に「電話に出て」呼を受け付けたデバイスが通信用として選択されるようにすることも可能である。上記のように、デバイスの優先度がＨＩＧにおいてさらに定義され、デバイスの選択を命令してもよい。例えば、ユーザがＨＩＧの中に登録されている場合、性能に関して可能ならば、そのユーザに関連付けられたデバイスが選択されるべきであり、他方、そのユーザが現時点で登録されていない場合、呼はボイスメール機能またはその類似機能に向けられるべきである。

単独ではどのデバイスも着呼の性能要件をサポートできないが、２つ以上のデバイスが一緒になれば、少なくとも要求される最小限度の性能を満足できそうな場合、ＨＩＧは、呼のメディアストリームのさまざまな成分をしかるべくこれらのデバイスに向けることができてもよい。例えば、テレビデバイスが、必要なビデオコーデックをサポートし、電話デバイスが、必要な音声コーデックをサポートする場合がある。この場合、テレビデバイスが視覚コンポーネントを表示し、電話デバイスが音声コンポーネントを発出するようなテレビ会議を確立することができよう。また、さまざまなデバイスへのメディアストリームの分割が、プリファレンスとして定義されてもよい。分割されたメディアストリームが使われる場合、各メディアコンポーネントは、それ自身のＮＡＴポートマッピングを受信するであろう。本発明は、デバイスの選択についての規則もしくはポリシーを定義する場合に、ユーザに大きな柔軟性を提供することは、上記の例から明らかであるはずである。

次に、発呼の場合に、プライベートネットワーク内に含まれるＩＭＳ非対応デバイス４００のためのマルチメディアセッションを確立するための手順について、図４に示すステップ４：１乃至４：８を参照して記述しよう。参加する要素は基本的に図３に示す要素と同じであり、従って、同じ数字がここでもまた使用される。最初のステップ４：１において、ＨＩＧ３００の中の通信ユニット３１２が、例えばＩＭＳ対応端末またはコンテンツサーバのような、リモートの当事者に宛てて送信されたセッション要求をデバイス４００から受信する。受信された要求は、そのデバイス４００の性能の範囲内のプロトコルによって与えられる。

次のステップ４：２で、要求は論理ユニット３１４に提出され、論理ユニット３１４は、次いで、続くステップ４：３で、デバイスデータベース３１６から、デバイス４００の性能と、ＩＤ情報と、ローカルＩＰアドレスとを引き出す。論理ユニット３１４は、次のステップ４：４で、ＩＭＳネットワーク３０４に向けたＨＩＧのＩＭＳ ＩＤを用いて、選択されたデバイスのためのセッションをセットアップするように通信ユニット３１２に命令する。また、このステップにおいて論理ユニット３１４は、セットアップ手順の間に使用される選択されたデバイスの性能データを通信ユニット３１２に提出する。また、選択されたデバイスのローカルＩＰアドレスも、ステップ４：４で提出される。

しかし、デバイス４００が個別のＩＭＳ ＩＤに関連付けられる場合、すなわちパーソナルデバイスである場合、通信ユニット３１２は、そのＩＭＳ ＩＤを、ＨＩＧのＩＭＳ ＩＤの代わりに使ってもよい。あるいは、ユーザは、ＨＩＧの共有ＩＭＳ ＩＤが使用されるべきだと、ステップ４：１のセッション要求の中で指示してもよい。従って、どのＩＭＳ ＩＤを使用するのか決めるのはユーザ次第であることが望ましい。

ここで通信ユニット３１２は、選択されたデバイスのための通信リンクを一般的に確立することを目的として、次のステップ４：５でＲＧＷ３０８と通信する。このステップは、セッションの１つ以上の異なるメディアストリームのためにＲＧＷ３０８のＮＡＴ／ファイアウォールにおいて開くポートの予約も含めて、基本的に前の例のステップ３：５と同様である。またＲＧＷは、アクセスネットワーク側の自分のパブリックＩＰアドレスを提供する。次いで、予約されたＲＧＷのポートが、デバイス４００のローカルＩＰアドレスにも関連付けられる。この情報は、さらに、セッションのセットアップの間に与えられることになる、セッションを定義する呼ＩＤに関連付けられることになり、前の例について記述したように、ＨＩＧ３００の中のセッションマッピングテーブルの中に記憶される。

次いで通信ユニット３１２は、選択されたデバイスに代わって発信側当事者とのセッションをセットアップすることを目的として、下記のステップ４：６で一般的に示すように、例えばＳＩＰによって、従来のシグナリングメッセージをＩＭＳネットワークと、しかるべく交換する。セットアップ手順において、通信ユニット３１２は、ＨＩＧのＩＭＳ ＩＤと、上記のステップ４：４で受信したデバイス４００の性能データと、ステップ４：５で受信したＲＧＷパブリックＩＰアドレスとポートとを用いて、セッション招待、例えばＳＩＰ ＩＮＶＩＴＥを送信し、それらは、ＳＩＰ ＩＮＶＩＴＥメッセージの中に埋め込まれたＳＤＰメッセージの中でＩＭＳネットワーク３０４に提供される。また通信ユニット３１２は、ＲＧＷ３０８のパブリックＩＰアドレスと予約ポートとを、今度のセッション用の連絡先として、性能とともに典型的にはＳＤＰメッセージの中で、提供する。リモート当事者とのセッションセットアップが完了した後、通信ユニットは、リモート当事者のＩＰアドレスを受信済であり、セッションマッピングテーブルが、前の例で記述したように、しかるべく更新される。

次に、通信ユニット３１２は、ステップ４：７で、例えばリモート当事者のＩＰアドレスなどの最後に交渉されたパラメータを含めて、ＮＡＴ内の予約されたポートのマッピングを開けるようにＲＧＷに要求する。最後に、ステップ４：８で、セッションが開始可能になり、この時点で着信するあらゆるメディアは、ＲＧＷ３０８の中のＮＡＴによってデバイス４００のローカルＩＰアドレスとポートとにマッピングされることができる。さらに、ステップ４：６のセッションセットアップの間に与えられた呼ＩＤは、前の例の場合と同様、ＨＩＧ３００の中のセッションマッピングテーブルの中に記憶される。

図５は、別の実施形態によって、プライベートネットワークおよびマルチメディア・サービス・ネットワーク（典型的にはＩＭＳネットワーク）においてマルチメディアゲートウェイを用いてマルチメディアセッションをセットアップするためのさまざまなステップを図解するフローチャートである。図解された手順は一般に、上記の図３および４について記述されたＨＩＧ３００のようなマルチメディアゲートウェイにおいて実行される。マルチメディア・サービス・ネットワークにおいて有効な単一のＩＭＳ ＩＤがマルチメディアゲートウェイについて定義済であることが、想定されている。

最初のステップ５００においてセッション要求が受信されるが、本記述におけるセッション要求とは、図３のステップ３：１における場合のような外部当事者から着信するセッション招待かまたは図４のステップ４：１における場合のような内部デバイスから発信されるセッション招待かいずれか一方についての総括的な用語である。次のステップ５０２において、受信されたセッション要求が、着呼に関連するのかまたは発呼に関連するのかが判断される。着呼の場合、必要な性能は次のステップ５０４で判断されるが、必要な性能は、典型的には、例えばＳＩＰ ＩＮＶＩＴＥメッセージのＳＤＰメッセージの中で受信された、セッション要求の中の、例えば少なくとも１つのコーデックを含む、推奨セッションパラメータとして示される。

次のステップ５０６で、上記の図３のステップ３：３の場合と同様、少なくとも最小限の必要な性能を満たす、適切かつ利用可能なデバイスが、そして任意で所定の規則もしくはポリシーに基づいて、選択される。すでに述べたとおり、デバイス選択アルゴリズムが、選択動作のため、マルチメディアゲートウェイの中に実装されてもよい。例えば、必要とされる性能を完全に満足するようなデバイスが利用できない場合、「匹敵する(comparable)」性能を有するデバイスが選ばれてもよく、そして、続くセッションセットアップ手順において、新たなセッションパラメータが、発信側当事者と交渉されてもよい。望ましいのは、例えば少なくとも１つの代替コーデックを含めて、発信側当事者と選択されたデバイスとの両方によって使用されうる新規セッションパラメータが、交渉されうることである。そうでない場合、結果としてのセッションの中で一部のメディアコンポーネントを除外することが必要になることがあり、例えば、動画コーデックが合意できない場合、提案されたテレビ会議は、単純な音声通話という結果になるかもしれない。

ステップ５０２において発呼の場合、プライベートネットワーク内の発信側デバイスが特定され、上記の図４のステップ４：３の場合と同様、その性能とローカルＩＰアドレスとが、次のステップ５０８で引き出される。

次のステップ５１０において、選択されたデバイスまたは発信側デバイスが、例えばそのユーザによって、「パーソナル」デバイスとして使用されることになるのかどうか、判断される。上記のように、どのＩＭＳ ＩＤをセッションに使うかを決定するのは、ユーザ次第であることが望ましい。個別の有効なＩＭＳ ＩＤがデバイスにすでに割り当てられているかもしれないし、あるいは、ＨＩＧの共有ＩＭＳ ＩＤが使われるべきかまたはユーザの個別の有効なＩＭＳ ＩＤが使われるべきかをユーザがセッション要求の中で示してもよい。この具体的なセッションにおいてデバイスがパーソナルデバイスである場合、次のステップ５１２において、選択されたデバイスまたは発信側デバイスに代わってマルチメディアゲートウェイとマルチメディア・サービス・ネットワークとの間の通常のセットアップ手順を使って、個別のＩＭＳ ＩＤを用いてセッションが確立される。

他方、ステップ５１０において、選択されたデバイスまたは発信側デバイスがパーソナルデバイスではない場合、すなわち、マルチメディア・サービス・ネットワーク内で有効な個別のＩＭＳ ＩＤを有しないデバイスである場合、最後に図解されたステップ５１４において、マルチメディアゲートウェイのＩＭＳ ＩＤを用いて、セッションが確立される。

図６は、さらに別の実施形態による、図５の特にステップ５０６において図解する手順の一部として、着呼のためのデバイスを選択する典型的な手順を図解するフローチャートである。今度のセッションのために必要とされる性能は、上記のステップ５０４の場合のように特定済みであると想定されている。最初のステップ６００において、必要とされる性能が、図３のステップ３：３におけるマッピング動作について記述したように、プライベートネットワーク内の見込まれるデバイスに関して記憶された性能と比較される。あるいは、デバイスデータベースにそれらを記憶させる代わりに、ステップ６００の比較を条件として、プライベートネットワーク内のデバイスが、要求に応じてその性能を提供してもよい。

次のステップ６０２において、少なくとも必要とされる最小限度の性能を満足する適切なデバイスが判断され、また、例えば上記に例示された所定の規則もしくはポリシーがもしあればそれに基づいて、判断される。次のステップ６０４において、対象となるデバイスが現時点で利用可能か否かが、例えば上記のデバイスデータベース構造の第３列に示されるステータスをチェックすることによって、さらに判断される。ここでは、例えば判断された適切なデバイスのステータスが「使用中」であると示された場合などに、デバイスが再度利用可能になるまで着呼が少なくとも所定の時間は待つべきであるとデバイスの選択アルゴリズムが命令できるような、さまざまな代替策が利用できる。

ステップ６０４において、対象となるデバイスが利用可能であると分かった場合、最終ステップ６０６で示すように、そのデバイスは今度のセッションのために最終的に選択され、例えば図５のステップ５１０乃至５１４によって、選択されたデバイスのためのセッションの確立が続いてもよい。

背景技術のセクションで記述したＨＩＧのこれまでに知られている使用法と比べて、本発明は、任意で所定の規則もしくはポリシーに基づいて、着信するマルチメディア呼のためのデバイス選択に大きな柔軟性を提供する。特に、受信されるメディアのさまざまなコンポーネントを受信するため、または同じメディアを受信するために、複数のデバイスが選択されてもよい。さらに本発明は結果として、サービスＩＤ、特に、マルチメディア・サービス・ネットワーク内の端末について定義されなければならないＩＭＰＵの数の削減をもたらす。従って、ネットワークオペレータは、ＩＭＰＵのようなパブリックＩＤの数、およびその関連する加入者データおよび認証データが減るため、管理が軽減されるという恩恵を被るであろう。

更なる利益として、共有サービスＩＤを用いたデバイスは、プライベートネットワークの外部からは認識できないであろうから、プライバシが一層保たれるということがあげられる。言い換えると、ネットワークオペレータも他のユーザもどちらも、個別のデバイスＩＤやそれらの特性や動作を検出できないのである。また、マルチメディア・サービス・ネットワーク内へのデバイスの登録を含めて、手動での構成への努力も最小化されうる。従ってユーザは、マルチメディア・サービス・ネットワークには個別に登録されない共有サービスＩＤを用いて、「隠された」デバイスでプライベートネットワークを構築することができる。

さらに、マルチメディア・サービス・ネットワークを巻き込まずにプライベートネットワーク内に一時的ビジターを導入することも可能であり、一時的ビジターは、次いで、ＨＩＧおよびそのサービスＩＤを用いて、マルチメディア・サービス・ネットワークによって提供されるマルチメディアサービスにアクセスすることができる。ビジターデバイスがこのような形でマルチメディアサービスへのアクセスを許可されるべきかどうかは、完全にプライベートネットワークのユーザ次第である。

本発明について、具体的な典型的な実施形態を参照しながら記述してきたが、この記述は、一般に本発明の概念を説明することが意図されているだけであって、本発明の範囲を限定していると考えられるべきではない。例えば、上記の実施形態を記述する場合に初めから終わりまでＩＭＳおよびＨＩＧの概念が使われたが、マルチメディア通信を実現するために基本的に他のいずれの標準およびネットワーク要素が使用されてもよい。本発明は、添付の請求項によって定義される。

２つの通信端末間でマルチメディアを通信するための従来型ネットワーク構造の略図である。 先行技術による、ローカル「ホームＩＭＳゲートウェイＨＩＧ」を使ったマルチメディアサービスへのアクセスを備えた宅内ネットワークの略図である。 一実施形態による、着呼についてマルチメディアセッションをセットアップするために用いられる場合のマルチメディアゲートウェイのブロック図である。 別の実施形態による、発呼についてマルチメディアセッションをセットアップするために用いられる場合の図３に示すマルチメディアゲートウェイのブロック図である。 別の実施形態による、マルチメディアゲートウェイを用いてマルチメディアセッションをセットアップするためのステップを示すフローチャートである。 別の実施形態による、図５に図解する手順の一部としてデバイスを選択するためのステップを示すフローチャートである。

Claims (30)

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. 前記サービスＩＤはＩＭＰＵを含むことを特徴とする請求項１６乃至２９のいずれか１項に記載の装置。

Images