(57)【要約】  本発明は、例えばＩＰマルチメディアサブシステム（ＩＭＳ）のようなキャリアのマルチメディアサブシステム（ＭＳ）のサービスを、効率的かつ有効な方法でエンタープライズネットワークにまで拡張するサービスノードを提供する。これにより、ＭＳ加入者は、キャリアの回線交換サブシステム（ＣＳ）とパケットサブシステム（ＰＳ）を介して提供されたキャリアのサービスに加え、エンタープライズサービスにもアクセスできるようになる。ＭＳに対してエンタープライズアプリケーションサーバがＭＳアプリケーションサーバのように見えるようにするために、サービスノードは、エンタープライズアプリケーションサーバとＭＳの間の連絡役として機能する。サービスノードは、エンタープライズおよびＭＳそれぞれのユーザ識別子とプロトコルとの間にユーザ識別子とプロトコル変換を提供する。こうして、エンタープライズアプリケーションサーバがＭＳにアクセスし、また、ＭＳによってアクセスされるようになることで、エンタープライズネットワークとキャリアネットワークの間でのユーザのモビリティが、サービスの継続性を維持しながらもサポートされる。【選択図】  図１
2010509792.tif 000002
【特許請求の範囲】
【請求項１】
キャリアネットワークに関連し、通信セッションに関連しているユーザを識別するキャリアユーザ識別子を含むマルチメディアサブシステムから、第１キャリアセッションメッセージを受信することと、
前記第１キャリアセッションメッセージの前記キャリアユーザ識別子に対応したエンタープライズユーザ識別子を識別することと、
前記第１キャリアセッションメッセージに対応し、前記エンタープライズユーザ識別子を含む第１エンタープライズセッションメッセージを作成することと、
前記第１エンタープライズセッションメッセージを前記識別されたエンタープライズネットワーク内へ転送することとを含む方法。
【請求項２】
前記セッションを確立する前記ユーザに代わって、前記通信セッション用のエンタープライズアプリケーションサーバが提供する発呼元エンタープライズアプリケーションサービスを呼び出すために、前記第１エンタープライズセッションメッセージは前記エンタープライズアプリケーションサーバへ転送される、請求項１に記載の方法。
【請求項３】
前記エンタープライズアプリケーションサーバから、前記通信セッションに関連し、前記エンタープライズユーザ識別子を含み、前記第１エンタープライズセッションメッセージへの前記エンタープライズアプリケーションサービスの提供に応答する、第２エンタープライズセッションメッセージを受信することと、
前記第２エンタープライズセッションメッセージの前記エンタープライズユーザ識別子に対応した前記キャリアユーザ識別子を識別することと、
前記第２エンタープライズセッションメッセージに対応し、前記キャリアユーザ識別子を含む第２キャリアセッションメッセージを作成することと、
前記第２キャリアセッションメッセージを前記マルチメディアサブシステム内へ転送することと
をさらに含む請求項２に記載の方法。
【請求項４】
前記エンタープライズネットワークから、前記通信セッションに関連し、前記エンタープライズユーザ識別子を含む第２エンタープライズセッションメッセージを受信することと、
前記第２エンタープライズセッションメッセージの前記エンタープライズユーザ識別子に対応した前記キャリアユーザ識別子を識別することと、
前記第２エンタープライズセッションメッセージに対応し、前記キャリアユーザ識別子を含む第２キャリアセッションメッセージを作成することと、
前記第２キャリアセッションメッセージを前記マルチメディアサブシステム内へ転送することと
をさらに含む、請求項１に記載の方法。
【請求項５】
前記エンタープライズユーザ識別子は、前記エンタープライズネットワーク内で端末を識別するために使用され、前記キャリアユーザ識別子は、前記キャリアネットワーク内で前記端末を識別するために使用される、請求項１に記載の方法。
【請求項６】
前記エンタープライズユーザ識別子は、前記キャリアネットワーク内で有効なユーザ識別子ではない、請求項１に記載の方法。
【請求項７】
前記通信セッションの制御は前記マルチメディアサブシステムによって提供される、請求項１に記載の方法。
【請求項８】
前記マルチメディアサブシステムは、前記キャリアネットワークのインターネットプロトコルマルチメディアサブシステムである、請求項１に記載の方法。
【請求項９】
前記エンタープライズネットワークの外で、前記キャリアネットワークの回線交換サブシステムを介して、前記通信セッションのベアラパスの少なくとも一部の確立を実行することをさらに含む、請求項１に記載の方法。
【請求項１０】
前記マルチメディアサブシステムから、前記ユーザの前記キャリアユーザ識別子を含む第１登録メッセージを受信することと、
前記第１登録メッセージの前記キャリアユーザ識別子に対応した前記エンタープライズユーザ識別子を識別することと、
前記第１登録メッセージに対応し、前記エンタープライズユーザ識別子を含む第２登録メッセージを作成することと、
前記ユーザを前記エンタープライズネットワークに登録するために、前記第２登録メッセージを前記エンタープライズネットワーク内へ転送することをさらに含む、請求項１に記載の方法。
【請求項１１】
前記第１キャリアセッションメッセージと前記第１エンタープライズセッションメッセージとは、前記通信セッションの確立と、前記通信セッションが確立した後の前記通信セッションの制御とのうち少なくとも１つを容易にするセッション制御メッセージである、請求項１に記載の方法。
【請求項１２】
少なくとも１つの通信インターフェースと、制御システムとを備え、
前記制御システムは、
前記少なくとも１つの通信インターフェースに関連し、かつ
キャリアネットワークに関連し、通信セッションに関連しているユーザを識別するキャリアユーザ識別子を含むマルチメディアサブシステムから、第１キャリアセッションメッセージを受信するように、
前記第１キャリアセッションメッセージの前記キャリアユーザ識別子に対応したエンタープライズユーザ識別子を識別するように、
前記第１キャリアセッションメッセージに対応し、前記エンタープライズユーザ識別子を含む第１エンタープライズセッションメッセージを作成するように、
前記第１エンタープライズセッションメッセージをエンタープライズネットワーク内へ転送するように適合されているシステム。
【請求項１３】
前記セッションを確立する前記ユーザに代わって、前記通信セッション用のエンタープライズアプリケーションサーバが提供する発呼元エンタープライズアプリケーションサービスを呼び出すために、前記第１エンタープライズセッションメッセージは前記エンタープライズアプリケーションサーバへ転送される、請求項１２に記載のシステム。
【請求項１４】
前記制御システムが、
前記エンタープライズアプリケーションサーバから、前記通信セッションに関連し、前記エンタープライズユーザ識別子を含み、前記第１エンタープライズセッションメッセージへの前記エンタープライズアプリケーションサービスの提供に応答する、第２エンタープライズセッションメッセージを受信するように、
前記第２エンタープライズセッションメッセージの前記エンタープライズユーザ識別子に対応した前記キャリアユーザ識別子を識別するように、
前記第２エンタープライズセッションメッセージに対応し、前記キャリアユーザ識別子を含む第２キャリアセッションメッセージを作成するように、
前記第２キャリアセッションメッセージを前記マルチメディアサブシステム内へ転送するように
さらに適合されている、請求項１３に記載のシステム。
【請求項１５】
前記制御システムが、
前記エンタープライズネットワークから、前記通信セッションに関連し、前記エンタープライズユーザ識別子を含む第２エンタープライズセッションメッセージを受信するように、
前記第２エンタープライズセッションメッセージの前記エンタープライズユーザ識別子に対応した前記キャリアネットワークアドレスを識別するように、
前記第２エンタープライズセッションメッセージに対応し、前記キャリアユーザ識別子を含む第２キャリアセッションメッセージを作成するように、
前記第２キャリアセッションメッセージを前記マルチメディアサブシステム内へ転送するように
さらに適合されている、請求項１２に記載のシステム。
【請求項１６】
前記エンタープライズユーザ識別子は、前記エンタープライズネットワーク内で端末を識別するために使用され、前記キャリアユーザ識別子は、前記キャリアネットワーク内で前記端末を識別するために使用される、請求項１２に記載のシステム。
【請求項１７】
前記エンタープライズユーザ識別子は、前記キャリアネットワーク内で有効なユーザ識別子ではない、請求項１２に記載のシステム。
【請求項１８】
前記通信セッションの制御は前記マルチメディアサブシステムによって提供される、請求項１２に記載のシステム。
【請求項１９】
前記マルチメディアサブシステムは、前記キャリアネットワークのインターネットプロトコルマルチメディアサブシステムである、請求項１２に記載のシステム。
【請求項２０】
前記制御システムはさらに、前記エンタープライズネットワークの外で、前記キャリアネットワークの回線交換サブシステムを介して、前記通信セッションのベアラパスの少なくとも一部の確立を実行するように適合されている、請求項１２に記載のシステム。
【請求項２１】
前記制御システムが、
前記マルチメディアサブシステムから、前記ユーザの前記キャリアユーザ識別子を含む第１登録メッセージを受信するように、
前記第１登録メッセージの前記キャリアユーザ識別子に対応した前記エンタープライズユーザ識別子を識別するように、
前記第１登録メッセージに対応し、前記エンタープライズユーザ識別子を含む第２登録メッセージを作成するように、
前記ユーザを前記エンタープライズネットワークに登録するために、前記第２登録メッセージを前記エンタープライズネットワーク内へ転送するようにさらに適合されている、請求項１２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はキャリアネットワークにおけるマルチメディアサブシステムに関し、具体的には、マルチメディアサブシステムの加入者にエンタープライズサービスとキャリアサービスの両方へのアクセスを提供することに関する。
【背景技術】
【０００２】
電気通信サービスプロバイダは、回線交換音声サービスから、ボイスオーバインターネットプロトコル（ＶｏＩＰ）を使用してサービスをサポートするパケットネットワークへの移行を行っている。
パケット通信にはマルチメディア性能が要求されており、また、収益を上げるために努力して、サービスプロバイダは、音声サービスと共に通信関連のサービスを絶え間なく提供している。こうしたサービスを制御および追跡するために、サービスプロバイダは、ＩＰマルチメディアサブシステム（ＩＭＳ）と呼ばれ、第３世代移動体通信システム標準化プロジェクト（３ＧＰＰ）によって定義されたサービス配信プラットフォームを採用する。セッション確立プロトコル（ＳＩＰ）を使用することで、サービスプロバイダは有線サービスと無線サービスを統合し、公衆交換電話ネットワーク（ＰＳＴＮ）の従来の時分割多重方式（ＴＤＭ）ネットワークをサポートすることができる。サービスプロバイダは、ＩＭＳを、それぞれのキャリアネットワークに不可欠な部分として採用している。そのため、ＩＭＳはキャリアネットワーク内で提供される。
【０００３】
従来、サービスプロバイダの収益源の大半は、概して自社の専用ネットワークを所有する事業である。こうした専用ネットワークは、一般的にエンタープライズネットワークと呼ばれ、独自のアドレス指定または番号計画を使用する。エンタープライズネットワークはＰＳＴＮのキャリアネットワークに接続されているが、エンタープライズネットワークとキャリアネットワーク間の相互接続は従来制限されてきた。ＩＭＳが展開されるにつれ、エンタープライズネットワークとキャリアネットワーク間の相互接続は、エンタープライズネットワークに関連したアドレス指定とセキュリティの問題のために制限されたままである。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
多くの場合、エンタープライズネットワークは、キャリアネットワークでは利用できない様々なサービスを権限のあるユーザに提供することができ、またこの逆も行える。エンタープライズネットワークの外でローミングした後にキャリアネットワークによってサポートされている権限のあるユーザは、エンタープライズネットワーク内にいる権限のあるユーザが利用できるエンタープライズサービスにアクセスすることができなくなる。同様に、エンタープライズネットワークのサービスを受けている権限のあるユーザは、キャリアネットワークが提供するサービスを利用することができない。
そのため、権限のあるユーザがどこにいようとエンタープライズサービスとキャリアサービスにアクセスできるようにする方法が必要である。さらに、エンタープライズネットワークとキャリアネットワーク間のより大型の相互通信を容易にし、また、各ネットワークの、相違し多くの場合互換性を持たないアドレス指定の問題を解決する方法も必要である。
【課題を解決するための手段】
【０００５】
本発明は、キャリアのマルチメディアサブシステム（ＭＳ）のサービス、例えばＩＰマルチメディアサブシステム（ＩＭＳ）を、エンタープライズネットワークにまで効率的かつ有効な方法で拡大するサービスノードを提供する。これにより、ＭＳ加入者は、キャリアの回線交換サブシステム（ＣＳ）とパケットサブシステム（ＰＳ）が提供するキャリアのサービスに加えて、エンタープライズサービスにもアクセスできるようになる。前記サービスノードは、ＭＳドメイン内のユーザがエンタープライズアプリケーションを利用できるようにするための、エンタープライズアプリケーションサーバとＭＳの間の連絡役として機能する。前記サービスノードはまた、エンタープライズ、ＭＳアドレス、プロトコル間のそれぞれにアドレスとプロトコル変換を提供する。これにより、エンタープライズアプリケーションサーバはＭＳにアクセスし、またＭＳによってアクセスされることが可能になることで、エンタープライズネットワークとキャリアネットワークの間におけるユーザのモビリティを、サービスの継続性を維持しながらサポートできるようになる。
【０００６】
当業者は、添付の図面に関連した以下の好ましい実施形態の詳細な説明を読解すれば、本発明の範囲を理解し、そのさらなる態様に気付くことができる。
【０００７】
本明細書に組み込まれてその一部を形成する添付の図面は、本発明のいくつかの態様を例証し、また、本発明の詳細な説明を伴うことで本発明の原理を説明する。
【図面の簡単な説明】
【０００８】
【図１】一実施形態に係る本発明を採用できる通信環境のブロック図である。
【図２Ａ】モバイル端末がＣＳを介した呼サービスを受けるためにＩＭＳに登録している呼フローであり（その１）、この場合、モバイル端末はエンタープライズネットワークからもサービスも受けることができる。
【図２Ｂ】モバイル端末がＣＳを介した呼サービスを受けるためにＩＭＳに登録している呼フローであり（その２）、この場合、モバイル端末はエンタープライズネットワークからもサービスも受けることができる。
【図２Ｃ】モバイル端末がＣＳを介した呼サービスを受けるためにＩＭＳに登録している呼フローであり（その３）、この場合、モバイル端末はエンタープライズネットワークからもサービスも受けることができる。
【図３Ａ】モバイル端末が、ＣＳを介してエンタープライズネットワーク内にあるユーザ端末への呼を開始している呼フローである（その１）。
【図３Ｂ】モバイル端末が、ＣＳを介してエンタープライズネットワーク内にあるユーザ端末への呼を開始している呼フローである（その２）。
【図４Ａ】モバイル端末が、ＰＳを介して、エンタープライズネットワーク内にあるユーザ端末への呼を開始している呼フローであり（その１）、この場合、呼のベアラパスはＣＳによってサポートされている。
【図４Ｂ】モバイル端末が、ＰＳを介して、エンタープライズネットワーク内にあるユーザ端末への呼を開始している呼フローであり（その２）、この場合、呼のベアラパスはＣＳによってサポートされている。
【図５】第２実施形態に係る本発明を採用できる通信環境のブロック図である。
【図６Ａ】モバイル端末がＷＬＡＮモードを介して呼サービスを受けるためにＩＭＳに登録している呼フローであり（その１）、この場合、モバイル端末はエンタープライズネットワークを介したサービスも受けることができる。
【図６Ｂ】モバイル端末がＷＬＡＮモードを介して呼サービスを受けるためにＩＭＳに登録している呼フローであり（その２）、この場合、モバイル端末はエンタープライズネットワークを介したサービスも受けることができる。
【図６Ｃ】モバイル端末がＷＬＡＮモードを介して呼サービスを受けるためにＩＭＳに登録している呼フローであり（その３）、この場合、モバイル端末はエンタープライズネットワークを介したサービスも受けることができる。
【図７】本発明の一実施形態に係るサービスノードのブロック図である。
【図８】本発明の一実施形態に係るエンタープライズアプリケーションサーバのブロック図である。
【図９】本発明の一実施形態に係るサービング呼／セッション制御機能（Ｓ‐ＣＳＣＦ）のブロック図である。
【発明を実施するための形態】
【０００９】
以下に述べる実施形態は、当業者が本発明を実施できるようにするために必要な情報を示し、本発明を実施する最良の形態を例証している。当業者は、添付の図面を考慮しながら以下の記述を読解することで、本発明の概念を理解し、また、ここでは特に指示していない概念の用途に気付くだろう。  こうした概念および用途は、本開示および添付の請求項の範囲内に入ることが理解されるべきである。
【００１０】
本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）といったキャリアのマルチメディアサブシステム（ＭＳ）のキャリアのサービスを効率的かつ有効な方法でエンタープライズネットワークまたは別の非ＭＳネットワークにまで拡大するサービスノードを提供する。これにより、ＭＳ加入者は、キャリアの回線交換サブシステム（ＣＳ）およびパケットサブシステム（ＰＳ）により提供されたサービスに加えて、エンタープライズサービスにもアクセスできるようになる。前記サービスノードがエンタープライズアプリケーションサーバとＭＳ間の連絡役として機能することで、ＭＳドメイン内のユーザがエンタープライズアプリケーションを利用できるようになる。サービスノードは、それぞれエンタープライズアドレス／プロトコルとＭＳアドレス／プロトコル間でアドレス／プロトコルの変換を行う。これにより、エンタープライズアプリケーションサーバはＭＳにアクセスでき、またＭＳからアクセスされることもできるので、サービスの継続性を保ちつつ、エンタープライズネットワークとキャリアネットワーク間でユーザのモビリティをサポートすることが可能となる。
本発明の詳細を探求する前に、本発明を採用することができる通信環境１０の概観を図１に示す。
【００１１】
通信環境１０は、ＩＭＳ１４のようなマルチメディアサブシステムを採用したキャリアネットワーク１２を含んでいる。キャリアネットワーク１２には、適切なＩＰアクセスネットワーク１８を介して非キャリアエンタープライズネットワーク１６が接続している。キャリアネットワーク１２がＣＳ２０およびＰＳ２２を提供することにより、ユーザ１に関連するモバイル端末２４と固定端末２４’を含んだ様々なモバイル端末／固定端末との、回線交換ベースおよびパケットベースの有線／無線通信が容易になる。ＩＭＳ１４はセッション制御アーキテクチャであるので、セッション（呼を含む）シグナリングは、適切なメディアゲートウェイ制御機能（ＭＧＣＦ）２６を通過してＩＭＳ１４内へ送られる。ＣＳ  ＭＧＣＦ２６は、ＣＳメディアゲートウェイ（ＣＳＭＧ）２８に密接に関連している。  本質的に、ＣＳ２０とＩＭＳ１４の間で交換された呼シグナリングがＣＳ  ＭＧＣＦ２６を通過すると、ＣＳ  ＭＧＣＦ２６が前記呼シグナリングを斟酌して、ＣＳ２０とこれに関連するパケットネットワークとの間にベアラパスを確立するようにＣＳメディアゲートウェイ２８を制御する。パケットベースのアクセスでは、ＰＳ２２が代理呼セッション制御機能（Ｐ‐ＣＳＣＦ）３０を介してＩＭＳ１４と対話する。
【００１２】
例証した実施形態では、ＩＭＳ１４全体にわたってセッションシグナリングにＳＩＰが使用されている。さらに、特定の加入者、またはモバイル端末２４のような加入者装置に対してサービングＣＳＣＦ（Ｓ‐ＣＳＣＦ）３２が割り当てられる。全ての、または殆どのセッションシグナリングはこれを介して送られる。セッションシグナリングの処理時には、Ｓ‐ＣＳＣＦ３２が様々なアプリケーションサーバ（ＡＳ）３４にアクセスすることができる。多くの場合、セッションシグナリングは特定のアプリケーションサーバ（ＡＳ）３４を介して送られ、前記アプリケーションサーバ（ＡＳ）３４は、セッションシグナリングメッセージを変更することで特定のサービスを採用する。一般的に、これらのアプリケーションサーバ（ＡＳ）３４はＩＭＳ１４内にある。
【００１３】
本発明では、サービスノード３６を、ＩＭＳ１４と別の非キャリアまたは非ＩＭＳアプリケーションサーバとの間の連絡役として機能するように採用している。これについては以降でより詳細に述べる。本質的に、サービスノード３６は、これらの非キャリアおよび非ＩＭＳアプリケーションサーバに代わるＩＭＳアプリケーションサーバとして見える。ＩＭＳ１４はホーム加入者サービス（ＨＳＳ）３８をさらに含んでいるが、前記ホーム加入者サービス３８は、加入者装置のＳ‐ＣＳＣＦの識別を補助し、加入者装置とＩＭＳ１４内のセッション制御ノードとの間の関連を保つ。
【００１４】
ＩＭＳ１４はまた、ＣＳ２０とインターフェースする方法と類似した方法で、適切なＰＳＴＮ  ＭＧＣＦ４２とこれに関連するＰＳＴＮメディアゲートウェイ４４を介して、公衆交換電話ネットワーク（ＰＳＴＮ）４０とインターフェースすることができる。これにより、セッションシグナリングがＳ‐ＣＳＣＦ３２とＰＳＴＮ４０の間でＰＳＴＮ  ＭＧＣＦ４２を介して送られる。ＰＳＴＮ  ＭＧＣＦ４２はＰＳＴＮメディアゲートウェイ（ＰＳＴＮ  MG）４４を制御することで、ＰＳＴＮ４０まで延びている回線交換レッグとＩＭＳ１４に関連してパケットネットワーク全体にかけて延びているパケットセッションとの間のベアラパスを制御する。
【００１５】
エンタープライズネットワーク１６は、様々なタイプのユーザ端末と、ＰＳＴＮ４０への接続とを設けた状態で図示されている。第１ユーザ端末４６はユーザ１と関連しており、パケットベースの通信装置であると仮定する。さらに、第２ユーザ端末４８はユーザ２と関連しており、パケットベースの通信装置であると仮定する。第１ユーザ端末４６と第２ユーザ端末４８の両方は、エンタープライズネットワーク１６内の通信を制御するためにセッションシグナリングを取り扱うエンタープライズアプリケーションサーバ５０によってサポートされる。エンタープライズネットワーク１６はパケット主体であるが、従来型の時分割多重（ＴＤＭ）ベースのユーザ端末をサポートすることもできる。
図に示すように、第３ユーザ端末５２は、エンタープライズアプリケーションサーバ５０とインターフェースするＴＤＭメディアゲートウェイ（ＴＤＭ  MG）５４によってサポートされている。エンタープライズアプリケーションサーバ５０は、音声ベースの通信に限らない任意数の通信サービスをサポートすることができる。特に、エンタープライズアプリケーションサーバ５０は、サービスノード３６を介してＩＭＳ１４にアクセスし、アクセスされることが可能な、典型的には非キャリア、非ＩＭＳアプリケーションサーバである。ＩＭＳ１４にはサービスノード３６が、エンタープライズアプリケーションサーバ５０の代りのアプリケーションサーバに見える。以下でさらに詳細に説明する。エンタープライズネットワーク１６のＰＳＴＮ４０へのアクセスは適切なＰＳＴＮメディアゲートウェイ５６（ＰＳＴＮ  MG）を介してもよい。
【００１６】
図１ではさらに、ＩＰアクセスネットワーク１８とキャリアネットワーク１２間のキャリアファイアウォール５８と、ＩＰアクセスネットワーク１８とエンタープライズネットワーク１６間のエンタープライズファイアウォール６０を図示している。一実施形態では、仮想専用ネットワーク（ＶＰＮ）のようなトネリング機構を採用することにより、キャリアファイアウォール５８からエンタープライズファイアウォール６０までのパスを提供し、ＩＰアクセスネットワーク上でリンクを保護している。
キャリアファイアウォール５８とエンタープライズファイアウォール６０をつなぐトンネルのエンドポイントをトネリングノード６２および６４でそれぞれ示す。
【００１７】
エンタープライズネットワーク１６内にある第１ユーザ端末４６で呼の発着を行う場合の様々な例を挙げて本発明の概念を例証する。これらの中から選択した例はまた、エンタープライズネットワーク１６の外に存在し、ＣＳ２０ならびにＰＳ２２を介して通信を提供することができる、互いに関連し合ったモバイル端末２４の相互作用を例証するものでもある。
【００１８】
第１例を図２Ａ〜２Ｃの通信フローにより提供する。この説明では、主なメッセージのみを示すために通信フローを簡素化している。前記通信フロー図は、ユーザ１のモバイル端末２４がＩＭＳ１４に登録する場合に、モバイル端末２４に対して送られた着呼がＰＳ２２ではなくＣＳ２０を介してベアラパスを採用すべきであることを表示する方式で登録を行うシナリオを例証している。このシナリオは、ボイスオーバパケット（ＶｏＰ）セッション全体をサポートするのに、あるいは現在のネットワーク条件に基づいてサポートするのに十分なリソースをＰＳ２２が備えていない可能性のあるケースを表す。モバイル端末２４の登録が完了すると、ユーザ２が第２ユーザ端末４８からユーザ１の第１ユーザ端末４６に対して発呼する。エンタープライズアプリケーションサーバ５０は、第２ユーザ端末４８からの発呼を受けると、登録されている両装置、つまりエンタープライズネットワーク１６内の第１ユーザ端末４６とＩＭＳ１４を介したモバイル端末２４に対して前記呼を提示する。前記例では、着呼が第１ユーザ端末４６とモバイル端末２４に提示された後に、モバイル端末２４が前記着呼に応答し、ベアラパスがＣＳ２０を介して確立されると仮定する。次に、この通信フローについて詳細に述べる。
【００１９】
まず、ユーザ１のモバイル端末２４が、この端末に関連したモバイルディレクトリ番号（ＭＤＮ）が含まれているＣＳレジスタメッセージをＣＳ２０に送ることで、ＣＳ２０に登録を行う（ステップ１００）。ＣＳ２０は、ＭＤＮを使用してモバイル端末２４の登録通知（ＲＥＧＮＯＴ）をＨＳＳ３８に提供するように構成されている（ステップ１０２）。前記モバイル端末２４のＣＳ２０への登録はＨＳＳ３８によって追跡される。モバイル端末２４はまた、ＰＳ２２を介してＩＭＳ１４にも登録できる。具体的には、モバイル端末２４がＳＩＰレジスタメッセージをＰ‐ＣＳＣＦ３０へ送信し（ステップ１０４）、次いでＰ‐ＣＳＣＦ３０が前記ＳＩＰレジスタメッセージをＳ‐ＣＳＣＦ３２へ転送することができる（ステップ１０６）。Ｓ‐ＣＳＣＦ３２がＳＩＰレジスタメッセージをＨＳＳ３８へ転送すると（ステップ１０８）、ＨＳＳ３８がユーザ１の登録をモバイル端末２４とＩＭＳ１４の関連において追跡する。特に、ＳＩＰレジスタメッセージは、ユーザ１のキャリアユーザ識別子（ＵＳＥＲ１＠ＣＡＲＲＩＥＲ）を識別し、さらに、ユーザ１が使用しているモバイル端末２４がＣＳモードで動作していることを示す。ユーザ識別子はユニフォームリソースロケータ（ＵＲＬ）、ディレクトリ番号、または他の適切な識別情報であってよい。ＣＳモードは、その呼がＰＳ２２ではなくＣＳ２０を介してモバイル端末２４へ送られなければならない旨を示す。
【００２０】
ユーザ１の登録に加え、ＨＳＳ３８は、ユーザ１がエンタープライズネットワーク１６およびＩＭＳ１４のサービスの統合を呼び出すことを望んでいると認識する。具体的には、ＨＳＳ３８は、エンタープライズネットワーク１６のエンタープライズアプリケーションサーバ５０を採用しなければならないこと認識する。そのため、この登録をエンタープライズアプリケーションサーバ５０へ転送するように、Ｓ‐ＣＳＣＦ３２に命令が出される（ステップ１１０）。次に、Ｓ‐ＣＳＣＦ３２が、ユーザ１のキャリアアドレスユーザ識別子を使用して、ＳＩＰ通知登録メッセージをサービスノード３６へ送信する（ステップ１１２）。サービスノード３６は、ユーザ１のキャリア識別子をユーザ１のエンタープライズ識別子にマッピングし（ステップ１１４）、ユーザ１のエンタープライズ識別子（ＵＳＥＲ１＠ＸＹＺ）を使用してＳＩＰレジスタメッセージをエンタープライズアプリケーションサーバ５０へ送信する（ステップ１１６）。こうして、ユーザ１は、キャリアネットワーク１２およびＩＭＳ１４のＣＳ２０のサービスを受けながら、エンタープライズアプリケーションサーバ５０にも有効に登録される。登録時、エンタープライズアプリケーションサーバ５０は、従来のＳＩＰ形式のＳＩＰ２００ＯＫメッセージをサービスノード３６へ返信することによって応答する。（ステップ１１８）
【００２１】
次に、ユーザ２が、第２ユーザ端末４８からユーザ１に関連したエンタープライズ識別子へ発呼を開始すると仮定する。ここでも、用語「識別子」は、従来のＵＲＬまたは関連するディレクトリ番号を表すために使用される。第２ユーザ端末４８に関連したディレクトリ番号は、一般的にキャリアネットワーク１２が認識できないエンタープライズ番号である。発呼を開始するために、第２ユーザ端末４８がエンタープライズアプリケーションサーバ５０にＳＩＰ  ＩＮＶＩＴＥメッセージを送ると仮定する（ステップ１２０）。ＳＩＰ  ＩＮＶＩＴＥメッセージは、ユーザ２に関連した識別子またはディレクトリ番号（ＵＳＥＲ２ＤＮ）から、ユーザ１に関連したエンタープライズ識別子（ＵＳＥＲ１＠ＸＹＺ）へのセッションが開始されつつある旨を表す。エンタープライズアプリケーションサーバ５０は、ユーザ１が、ユーザ１に関連した登録済みの全端末に対して呼を提示させるために、呼処理ルールを採用したことを認識する。
【００２２】
これにより、エンタープライズアプリケーションサーバ５０が呼を第１ユーザ端末４６ならびにモバイル端末２４へルーティングする。第１ユーザ端末４６へ呼をルーティングするために、エンタープライズアプリケーションサーバ５０は、ＳＩＰ  ＩＮＶＩＴＥメッセージを第１ユーザ端末４６へ転送し（ステップ１２２）、その後、第１ユーザ端末４６が着呼の提示を認識し、その旨をユーザ１に注意喚起する。第１ユーザ端末４６は、ＳＩＰ  ＩＮＶＩＴＥメッセージに応答して、第１ユーザ端末４６がユーザ１に注意喚起を行っていることを示すＳＩＰ１８０リンギングメッセージをエンタープライズアプリケーションサーバ５０へ返送する（ステップ１２４）。次に、エンタープライズアプリケーションサーバ５０がＳＩＰ１８０リンギングメッセージを第２ユーザ端末４８へ転送する（ステップ１２６）。
【００２３】
一方、エンタープライズアプリケーションサーバ５０は前記呼をモバイル端末２４へもルーティングする。呼をモバイル端末２４へルーティングするために、エンタープライズアプリケーションサーバ５０は、ユーザ１に代わって登録済みアプリケーションサーバとして機能するサービスノード３６へＳＩＰ  ＩＮＶＩＴＥメッセージを転送する（ステップ１２８）。サービスノード３６は、ユーザ１のエンタープライズアドレス（ＵＳＥＲ１＠ＸＹＺ）をユーザ１のキャリアアドレス（ＵＳＥＲ１＠ＣＡＲＲＩＥＲ）にマッピングすることで、必要なアドレス変換を提供する（ステップ１３０）。
次に、サービスノード３６が、ユーザ１のキャリア識別子を使用して、ＳＩＰ  ＩＮＶＩＴＥメッセージをＩＭＳ１４のＳ‐ＣＳＣＦ３２へ送信する（ステップ１３２）。Ｓ‐ＣＳＣＦ３２は、キャリアアドレスを最新のＭＤＮに変換せよとのメッセージをＨＳＳ３８へ送る（ステップ１３４）。ＨＳＳ３８は、キャリアアドレスに関連したモバイルディレクトリ番号をＳ‐ＣＳＣＦ３２に提供してこれに応答する（ステップ１３６）。Ｓ‐ＣＳＣＦ３２は、次に、モバイル端末２４のＭＤＮをサポートしているＰ‐ＣＳＣＦ３０を介して、ＳＩＰ  ＩＮＶＩＴＥをＣＳ  ＭＧＣＦ２６へ転送する（ステップ１３８）。続いて、ＣＳ  ＭＧＣＦ２６がＭＤＮを使用し、適切な統合サービスユーザパート（ＩＳＵＰ）初期アドレスメッセージ（ＩＡＭ）をＣＳ２０に提供する（ステップ１４０）。ＣＳ２０は、モバイル端末２４に注意喚起メッセージを提供してこれに応答し、ユーザ１への注意喚起を開始する（ステップ１４２）。これに応じて、モバイル端末２４がＣＳ２０にリンギングメッセージを返送すると（ステップ１４４）、ＣＳ２０がＩＳＵＰアドレス完了メッセージ（ＡＣＭ）をＣＳ  ＭＧＣＦ２６へ送る（ステップ１４６）。すると、ＣＳ  ＭＧＣＦ２６が、Ｐ‐ＣＳＣＦ３０、Ｓ‐ＣＳＣＦ３２およびサービスノード３６を介し、ＳＩＰ１８０リンギングメッセージをエンタープライズアプリケーションサーバ５０へ送り戻す（ステップ１４８）。
【００２４】
モバイル端末２４においてユーザ１が着呼に応答すると、モバイル端末２４が応答メッセージをＣＳ２０へ送り（ステップ１５０）、続いてＣＳ２０がＩＳＵＰ応答メッセージ（ＡＮＭ）をＣＳ  ＭＧＣＦ２６へ転送する（ステップ１５２）。ＣＳ  ＭＧＣＦ２６は、Ｐ‐ＣＳＣＦ３０、Ｓ‐ＣＳＣＦ３２およびサービスノード３６を介して、適切なＳＩＰ２００ＯＫメッセージをエンタープライズアプリケーションサーバ５０へ送る（ステップ１５４）。特に、サービスノード３６は、キャリア識別子とエンタープライズ識別子の間に必要な識別子変換と、両識別子間を通過する全てのメッセージのプロトコル変換とを提供する。前記プロトコル変換により、ＳＩＰの様々なバージョン間での変換が可能となる。
【００２５】
次に、モバイル端末２４が着呼に応答したことを示すために、エンタープライズアプリケーションサーバ５０がＳＩＰ２００ＯＫメッセージを第２ユーザ端末４８へ転送する（ステップ１５６）。
特に、ＣＳメディアゲートウェイ２８と第２ユーザ端末４８の間に通信を確立するのに必要な通信能力およびパラメータを交換するために、ＳＩＰ２００ＯＫメッセージのセッションデータプロトコル（ＳＤＰ）を使用している。第２ユーザ端末４８は、ＳＩＰ２００ＯＫメッセージを受信すると、エンタープライズアプリケーションサーバ５０、サービスノード３６、Ｓ‐ＣＳＣＦ３２およびＰ‐ＣＳＣＦ３０を介して、ＳＩＰ肯定応答メッセージ（ＡＣＫ）をＣＳ  ＭＧＣＦ２６へ転送する（ステップ１５８）。ここでも、サービスノード３６は必要なアドレスおよびプロトコル変換を提供する。
【００２６】
この時点で、第２ユーザ端末４８とモバイル端末２４の間に、ＣＳ２０を介してベアラパスが確立される（ステップ１６０）。具体的には、端末２４とＣＳ２０の間に無線接続が確立され、ＣＳ  ＭＧＣＦ２６に関連して、ＣＳ２０とＣＳメディアゲートウェイ２８の間にＴＤＭ接続が確立され、３コンポーネントベアラパスを形成するために、ＣＳメディアゲートウェイ２８と第２ユーザ端末４８の間にボイスオーバインターネットプロトコル（ＶｏＩＰ）接続が確立される。エンタープライズアプリケーションサーバ５０は、モバイル端末２４が応答され、モバイル端末２４と第２ユーザ端末４８の間のベアパスの確立が成功したことを認識すると、第１ユーザ端末４６にＳＩＰキャンセルメッセージを送信して、第１ユーザ端末４６への着呼の提示が終了したことを伝える（ステップ１６２）。
【００２７】
上述からわかるように、ＩＭＳ１４はユーザをエンタープライズアプリケーションサーバ５０に登録して、エンタープライズネットワーク１６が提供するサービスにアクセスできるようにすることが可能である。この登録が完了すると、エンタープライズアプリケーションサーバ５０はＩＭＳ１４のサービスと対話することもできるようになる。
【００２８】
図３Ａおよび３Ｂを参照すると、モバイル端末２４が、ＣＳ２０を介して、エンタープライズネットワーク１６内にある第２ユーザ端末４８への発呼を開始するシナリオの通信フローを示している。
まず、モバイル端末２４が、ユーザ２または第２ユーザ端末４８のダイヤルされたＤＮをＣＳ２０に提示する（ステップ２００）。ＣＳ２０、特にこの例ではモバイル交換センターが、ユーザ２のディレクトリ番号を識別する初回ダイヤルパルス（ＤＰ）メッセージをサービスノード３６に提供する（ステップ２０２）。サービスノード３６が、暫定ルーティング番号をユーザ２のＤＮに関連付け（ステップ２０４）、暫定ルーティング番号が呼の宛先であるＣＳ  ＭＧＣＦ２６を識別する。サービスノード３６が暫定ルーティング番号を接続メッセージ内に提供し、前記接続メッセージがＣＳ２０へ返送される（ステップ２０６）。
【００２９】
こうして暫定ルーティング番号を伴ったＣＳ２０は、前記番号を使用してＩＡＭをＣＳ  ＭＧＣＦ２６へルーティングする（ステップ２０８）。ＩＡＭは、発呼がユーザ１のＭＤＮから開始されたものであることを示す。ＣＳ  ＭＧＣＦ２６は、ＳＩＰ  ＩＮＶＩＴＥメッセージをＩＭＳ１４内へ送信することで、ＩＡＭの受信に応答する。具体的には、ＳＩＰ  ＩＮＶＩＴＥメッセージは、Ｐ‐ＣＳＣＦ３０を通ってＳ‐ＣＳＣＦ３２へ送られ、次に、Ｓ‐ＣＳＣＦ３２によってサービスノード３６へルーティングされる（ステップ２１０）。サービスノード３６はＨＳＳ３８にアクセスし、ＳＩＰ  ＩＮＶＩＴＥメッセージ内に提供されているユーザ１のＭＤＮに基づいて、ユーザ１のエンタープライズアドレス（ＵＳＥＲ１＠ＸＹＺ）を識別する。このケースでは、サービスノード３６が、ユーザ１のＭＤＮを識別するＣＳ変換メッセージをＨＳＳ３８へ送信し（ステップ２１２）、次に、ＨＳＳ３８が、ユーザ１のエンタープライズアドレスを、ユーザ１のＭＤＮ（キャリア識別子）に関連するものとして識別するＣＳ変換応答メッセージによってこれに応答する（ステップ２１４）。次に、サービスノード３６は、ＣＳ２０が取得時に保存しておいた暫定ルーティング番号に基づいてユーザ２のＤＮを識別する（ステップ２１６）。
【００３０】
この時点で、サービスノード３６はユーザ１のエンタープライズ識別子（ＵＳＥＲ１＠ＸＹＺ）と、以前に保存されたユーザ２のエンタープライズ識別子（ＵＳＥＲ２ＤＮ）とを取得したことになる。
こうして、サービスノード３６は、発呼側装置と着呼側装置のエンタープライズ識別子を持ち、適切なＳＩＰ  ＩＮＶＩＴＥをエンタープライズアプリケーションサーバ５０に提供することができる（ステップ２１８）。エンタープライズアプリケーションサーバ５０がＳＩＰ  ＩＮＶＩＴＥを第２ユーザ端末４８へ転送すると（ステップ２２０）、次に、第２ユーザ端末４８が、着呼が提示されている旨の注意喚起をユーザ２に対して開始する。第２ユーザ端末４８は、ＳＩＰ１８０リンギングメッセージをエンタープライズアプリケーションサーバ５０に送り戻すことでこれに応答し（ステップ２２２）、次に、エンタープライズアプリケーションサーバ５０が前記ＳＩＰ１８０リンギングメッセージをサービスノード３６へ転送する（ステップ２２４）。サービスノード３６は、ＳＩＰ１８０リンギングメッセージをＳ‐ＣＳＣＦ３２およびＰ‐ＣＳＣＦ３０を介してＣＳ  ＭＧＣＦ２６へ転送するために、エンタープライズネットワーク１６とキャリアネットワーク１４の間に必要なアドレス変換を提供する（ステップ２２６）。ＣＳ  ＭＧＣＦ２６は、これに応答してＩＳＵＰ  ＡＣＭをＣＳ２０内へ送る（ステップ２２８）。
【００３１】
ユーザ２が通話に応答する場合、第２ユーザ端末４８がＳＩＰ２００ＯＫメッセージをエンタープライズアプリケーションサーバ５０へ送り（ステップ２３０）、前記エンタープライズアプリケーションサーバ５０がＳＩＰ２００ＯＫメッセージをサービスノード３６へ転送する（ステップ２３２）。
サービスノード３６は必要な識別子とプロトコル変換を提供し、ＳＩＰ２００ＯＫメッセージを、Ｓ‐ＣＳＣＦ３２およびＰ‐ＣＳＣＦ３０を介してＣＳ  ＭＧＣＦ２６へ転送する（ステップ２３４）。
ＣＳ  ＭＧＣＦ２６がＩＳＵＰ  ＡＮＭをＣＳ２０へ送信すると（ステップ２３６）、ＣＳ２０が、ベアラパスの回線交換部分を有効にするために、接続メッセージをモバイル端末２４へ送信する（ステップ２３８）。ＣＳ  ＭＧＣＦ２６は、Ｐ‐ＣＳＣＦ３０、Ｓ‐ＣＳＣＦ３２、必要な識別子とプロトコル変換を提供するサービスノード３６、およびエンタープライズアプリケーションサーバ５０を介して、ＳＩＰ肯定応答メッセージを第２ユーザ端末４８へ返送する（ステップ２４０）。
この時点で、モバイル端末２４と第２ユーザ端末４８の間にＣＳ２０を介してベアラパスが確立される（ステップ２４２）。具体的には、モバイル端末２４とＣＳ２０の間に無線接続が確立され、ＣＳ２０とＣＳメディアゲートウェイ２８の間にＴＤＭベースの接続が確立され、ＣＳメディアゲートウェイ２８と第２ユーザ端末４８の間にＶｏＩＰセッションが確立される。
【００３２】
上述の実施形態では、モバイル端末２４からのアウトバウンドコールが開始され、ＣＳ２０を介して確立される。ＣＳ２０はＩＭＳ１４と対話することでサービスノード３６を呼び出し、エンタープライズネットワーク１６にアクセスするように構成されている。以下の例では、ＰＳ２２を介したモバイル端末２４から第２ユーザ端末４８への発呼が開始されたが、ベアラパスはＣＳ２０を介して確立される。図４Ａおよび４Ｂは、このようなシナリオの例証的な通信フローを提供する。
【００３３】
最初に、モバイル端末２４が、キャリア識別子（ＵＳＥＲ１＠ＣＡＲＲＩＥＲ）を使用して、自己からセッションを開始するために、第２ユーザ端末４８に関連したエンタープライズ識別子（ＵＳＥＲ２ＤＮ）へＳＩＰ  ＩＮＶＩＴＥを送る。ＳＩＰ  ＩＮＶＩＴＥはＰＳ２２を介してＰ‐ＣＳＣＦ３０に受信され（ステップ３００）、次に、Ｐ‐ＣＳＣＦ３０が前記ＳＩＰ  ＩＮＶＩＴＥをＳ‐ＣＳＣＦ３２へ転送する（ステップ３０２）。Ｓ‐ＣＳＣＦ３２の内部フィルタ基準（ＩＦＣ）は、モバイル端末２４への全ての発呼開始をサービスノード３６へ送信せよと命令する（ステップ３０４）。これにより、Ｓ‐ＣＳＣＦ３２がＳＩＰ  ＩＮＶＩＴＥをサービスノード３６へ転送し（ステップ３０６）、次に、サービスノード３６がＨＳＳ３８にアクセスして、モバイル端末２４に関連したＭＤＮを、ユーザ１のキャリアアドレスに基づいて識別する（ステップ３０８および３１０）。続いて、サービスノード３６がＳＩＰ  ＩＮＶＩＴＥを、前記セッションがモバイル端末２４に関連したＭＤＮのためのものであり、サービスノード３６によって開始されたことを示すように処理する。次に、サービスノード３６が修正されたＳＩＰ  ＩＮＶＩＴＥメッセージをＳ‐ＣＳＣＦ３２へ転送すると（ステップ３１２）、Ｓ‐ＣＳＣＦ３２が、モバイル端末２４のＭＤＮに関連して、ＳＩＰ  ＩＮＶＩＴＥメッセージをＣＳ  ＭＧＣＦ２６へ転送する（ステップ３１４）。これに応答して、ＣＳ  ＭＧＣＦ２６がＩＳＵＰ  ＩＡＭをＣＳ２０内へ送り、ＣＳ２０を介したモバイル端末２４への発呼を開始する（ステップ３１６）。ＣＳ２０は、呼が提示されており、前記呼がサービスノード３６からのものであることを示す注意喚起メッセージをモバイル端末２４に提示する（ステップ３１８）。
【００３４】
モバイル端末２４は、ＣＳ２０が提示した着呼に自動応答するように構成されている（ステップ３２０）。呼が応答されると、モバイル端末２４がＣＳ２０に応答メッセージを返送する（ステップ３２２）。次に、ＣＳ２０がＩＳＵＰ  ＡＣＭをＣＳ  ＭＧＣＦ２６へ転送すると（ステップ３２４）、ＣＳ  ＭＧＣＦ２６が、Ｐ‐ＣＳＣＦ３０およびＳ‐ＣＳＣＦ３２を介して、ＳＩＰ１８０リンギングメッセージをサービスノード３６へ送信する（ステップ３２６）。続いて、ＣＳ２０がＩＳＵＰ  ＡＮＭをＣＳ  ＭＧＣＦ２６へ送信し（ステップ３２８）、その後、ＣＳ  ＭＧＣＦ２６は、呼が応答された旨を示すＳＩＰ２００ＯＫメッセージを、Ｐ‐ＣＳＣＦ３０およびＳ‐ＣＳＣＦ３２を介してサービスノード３６へ送信する（ステップ３３０）。ＳＩＰ２００ＯＫメッセージは、サービスノード３６から開始したＩＮＶＩＴＥメッセージを考慮した従来のＳＩＰ応答である。
【００３５】
サービスノード３６は、ＳＩＰ２００ＯＫメッセージを受信すると、モバイル端末２４が開始したＳＩＰ  ＩＮＶＩＴＥメッセージに対応したＳＩＰ  ＩＮＶＩＴＥメッセージを作成する。サービスノード３６は、モバイル端末２４に関連したキャリアアドレス（ＵＳＥＲ１＠ＣＡＲＲＩＥＲ）を識別するＳＩＰ  ＩＮＶＩＴＥメッセージの代わりに、モバイル端末２４のエンタープライズアドレス（ＵＳＥＲ１＠ＸＹＺ）を使用して通話の発信元を識別する。これにより、ＳＩＰ  ＩＮＶＩＴＥメッセージは、モバイル端末２４の関連エンタープライズアドレスから第２ユーザ端末４８に関連したエンタープライズアドレスにまでセッションが確立中であることを示す。次に、ＳＩＰ  ＩＮＶＩＴＥメッセージはエンタープライズアプリケーションサーバ５０へ転送され（ステップ３３２）、その後、前記エンタープライズアプリケーションサーバ５０から第２ユーザ端末４８へ転送される（ステップ３３４）。第２ユーザ端末４８はユーザ２に注意喚起を出して着呼を知らせ、ＳＩＰ１８０リンギングメッセージをエンタープライズアプリケーションサーバ５０に送信する（ステップ３３６）。
次に、サーバ５０がＳＩＰ１８０リンギングメッセージをサービスノード３６へ転送する（ステップ３３８）。
【００３６】
第２ユーザ端末４８が応答されると、ＳＩＰ２００ＯＫメッセージがエンタープライズアプリケーションサーバ５０へ送信され（ステップ３４０）、続いて、前記エンタープライズアプリケーションサーバ５０がＳＩＰ２００ＯＫメッセージをサービスノード３６へ転送する（ステップ３４２）。この時点で、サービスノード３６は、Ｓ‐ＣＳＣＦ３２およびＰ‐ＣＳＣＦ３０を介してＣＳＭＧＣＦ２６へＳＩＰ肯定応答メッセージを送信することで、ステップ３３０の２００ＯＫメッセージに応答する（ステップ３４４）。サービスノード３６は、ステップ３４２のＳＩＰ２００ＯＫメッセージに応答して、ＳＩＰ肯定メッセージを、エンタープライズアプリケーションサーバ５０を介して第２ユーザ端末４８にも送信する（ステップ３４６）。この時点で、ＣＳ２０およびＣＳメディアゲートウェイ２８を介して、モバイル端末２４と第２ユーザ端末４８との間に、ＣＳ  ＭＧＣＦ２６に関連したベアラパスが確立される（ステップ３４８）。ここでも、ベアラパスは無線、ＴＤＭ、ＶｏＩＰセグメントを含む。上述のように、サービスノード３６は、呼がＰＳ２２を介して開始されたものであったとしても、ＣＳ２０を介してＣＳベースのベアラパスを呼び出すことができる。
【００３７】
図５を参照すると、エンタープライズネットワーク１６内でモバイル端末２４はアクセスポイント６６によってサポートされても良い。アクセスポイント６６は適切なルータまたはスイッチ６８と関連しており、前記ルータまたはスイッチ６８は、さらに、エンタープライズアプリケーションサーバ５０と、エンタープライズファイアウォール６０およびキャリアファイアウォール５８を介してキャリアネットワーク１２へ向かうパスとに接続している。図示のとおり、キャリアネットワーク１２内に入るシグナリングパスは、エンタープライズネットワーク１６内でのモバイル端末２４のサポートに使用されるＰ‐ＣＳＣＦ７０へ続いてよい。この実施形態では、エンタープライズファイアウォール６０とキャリアファイアウォール５８を介した、モバイル端末２４のシグナリングパスのための安全なトネリングは存在しない。特に、他の実施形態では、エンタープライズネットワーク１６とキャリアネットワーク１２の間に安全なトンネルを採用している場合と、採用していない場合がある。
安全なトネリングを採用していない場合は、追加の認証機構を採用する必要がある。図示の実施形態では、モバイル端末２４はセルラー通信とローカル無線通信の両方をサポートすることができ、この場合、ローカル無線通信はブルートゥース、無線ローカルエリアネットワーク（ＷＬＡＮ）、および同様の通信技術を含む。
【００３８】
図６Ａ〜６Ｃを参照すると、モバイル端末２４がＷＬＡＮモードでＩＭＳ１４に登録した通信フローが提供されており、これは、モバイル端末２４がアクセスポイント６６を介してパケットベースのローカル無線通信をサポートできることを示す。モバイル端末２４の登録が完了すると、ＩＭＳ１４が、サービスノード３６を介してエンタープライズアプリケーションサーバ５０に登録する。この登録後、第２ユーザ端末４８が、ユーザ１のエンタープライズアドレス（ＵＳＥＲ１＠ＸＹＺ）への発呼を開始する。エンタープライズアプリケーションサーバ５０は第２ユーザ端末４８からの着呼を受信して、これを第１ユーザ端末４６およびユーザ１のモバイル端末２４に提示する。第１ユーザ端末４６とモバイル端末２４のうち最初にこの着呼に応答した方が、呼が確立される端末となる。
【００３９】
モバイル端末２４がアクセスポイント６６のローカル無線通信範囲内に入ると、モバイル端末２４のＩＭＳ１４への登録を実行するために、ＳＩＰレジスタメッセージがＰ‐ＣＳＣＦ７０へ送信される（ステップ４００）。ＳＩＰレジスタメッセージは、モバイル端末２４と関連したユーザ１のキャリア識別子（ＵＳＥＲ１＠ＣＡＲＲＩＥＲ）を提供し、さらに、ローカル無線通信が利用可能な場所にある際には、モバイル端末２４がＷＬＡＮモードで動作している旨を示す。Ｐ‐ＣＳＣＦ７０は、ＳＩＰレジスタメッセージを受信すると、ＳＩＰレジスタメッセージをＳ‐ＣＳＣＦ３２へ転送し（ステップ４０２）、続いて、Ｓ‐ＣＳＣＦ３２がこれをＨＳＳ３８へ転送する（ステップ４０４）。ＨＳＳ３８はユーザ１のモバイル端末２４を登録し、モバイル端末２４がＷＬＡＮモードで動作している旨を示す。ＨＳＳ３８はユーザ１に関連した規則にアクセスし、モバイル端末２４をエンタープライズネットワーク１６にアクセスできるようにするエンタープライズモバイルパッケージにユーザ１が加入したことをＳ‐ＣＳＣＦ３２に通知する（ステップ４０６）。
【００４０】
この例では、呼制御および呼アンカリングのような任意数のＩＭＳサービスを提供するために、アプリケーションサーバ３４が呼シグナリングパス内に引き入れられる。
これらのサービスについては、権利者が共通で、共通譲渡された、２００６年３月１７日に出願の米国特許出願第１１／３７８，７７６号にさらに詳細に開示されており、その開示内容全体を本明細書で援用する。この出願は、遠隔通話レッグはアプリケーションサーバ３４に留まったままで、モバイル端末２４が１つのネットワークから別のネットワークへ移動できるようにするための効果的な技術を定義している。アプリケーションサーバ３４のサービスを呼び出すために、Ｓ‐ＣＳＣＦ３２がアプリケーションサーバ３４に対して、アプリケーションサーバ３４が提供するサービスに加入するためのＳＩＰ通知登録メッセージを送ることができる（ステップ４０８）。
【００４１】
ユーザ１がエンタープライズモバイル機能を採用しているので、Ｓ‐ＣＳＣＦ３２は、サービスノード３６に代わって提供されたサービスにもアクセスすべきであると認識する。このため、Ｓ‐ＣＳＣＦ３２は、エンタープライズアプリケーションサーバ５０から提供されているが、サービスノード３６が提示したサービスに加入するために、ＳＩＰ通知登録メッセージをサービスノード３６へ送信する（ステップ４１０）。ＳＩＰ通知登録メッセージがユーザ１のキャリア識別子を識別し、サービスノード３６が、ユーザ１のエンタープライズ識別子（ＵＳＥＲ１＠ＸＹＺ）を識別するためにＨＳＳ３８にアクセスする（ステップ４１２および４１４）。特に、この例で提供されているネットワークアクセスは安全性に乏しいため、特別な認証機構または認可機構を設けて、サービスノード３６がユーザ１をエンタープライズアプリケーションサーバ５０に登録できるようにする必要がある。この例では、ＨＳＳ３８は、パスワードまたは他の認証マークへのアクセスを保持または所有し、（ステップ４１２での）ＨＳＳの質問に応じてこれをサービスノード３６へ提供することができる。
【００４２】
サービスノード３６は、ＳＩＰレジスタメッセージをエンタープライズアプリケーションサーバ５０へ送信することで、ユーザ１のエンタープライズ識別子を使用し、ユーザ１をエンタープライズアプリケーションサーバ５０に登録しようと試みる（ステップ４１６）。従来のＳＩＰ方式では、初回ＳＩＰレジスタメッセージはパスワードまたは他の認証マーク無しで提供される。認証が必要な場合には、エンタープライズアプリケーションサーバ５０が、ＳＩＰ４０１非認可メッセージをサービスノード３６に送信することにより、この登録を戻す（ステップ４１８）。サービスノード３６は、これに対して、パスワードまたは他の認証マークを含めたＳＩＰ登録メッセージをエンタープライズアプリケーションサーバ５０へ再送することで応答する（ステップ４２０）。エンタープライズアプリケーションサーバ５０は前記認証マークを処理し、許可があったらＳＩＰ２００ＯＫメッセージをサービスノード３６へ返送する（ステップ４２２）。この時点で登録処理が完了し、モバイル端末２４経由のユーザ１は、キャリアネットワーク１２のＩＭＳ１４と、エンタープライズネットワーク１６のエンタープライズアプリケーションサーバ５０とにサービスノード３６を介して有効に登録される。
【００４３】
次に、ユーザ２が、ユーザ１に関連したエンタープライズアドレスを使用して第２ユーザ端末４８から発呼を開始すると仮定する。発呼を開始するには、第２ユーザ端末４８はＳＩＰ  ＩＮＶＩＴＥメッセージをエンタープライズアプリケーションサーバ５０へ送信して、ユーザ２に関連したディレクトリ番号からユーザ１のエンタープライズアドレスへのセッションを開始する（ステップ４２４）。
エンタープライズアプリケーションサーバ５０は、呼をユーザ１の全ての登録端末に提示するという規則を採用することができる。第１ユーザ端末４６は登録したばかりのモバイル端末２４と共にエンタープライズアプリケーションサーバ５０に登録されていると仮定した場合、エンタープライズアプリケーションサーバ５０は第１ユーザ端末４６とモバイル端末２４の両方に呼を提示する。
【００４４】
ＳＩＰ  ＩＮＶＩＴＥメッセージを第１ユーザ端末４６に転送することで第１ユーザ端末４６に呼が提示され（ステップ４２６）、これにより、ユーザ１に着呼を知らせる注意喚起が開始され、同時に、ＳＩＰ１８０リンギングメッセージをエンタープライズアプリケーションサーバ５０へ返送する（ステップ４２８）。次に、ユーザ１に対して着呼が提示されている旨をユーザ２に知らせるために、ＳＩＰ１８０リンギングメッセージが第２ユーザ端末４８に転送される（ステップ４３０）。
【００４５】
呼をモバイル端末２４に提示するために、エンタープライズアプリケーションサーバ５０はＳＩＰ  ＩＮＶＩＴＥメッセージをサービスノード３６へ転送する（ステップ４３２）。サービスノード３６は、ユーザ１のエンタープライズ識別子をユーザ１のキャリア識別子にマッピングし（ステップ４３４）、任意のプロトコル変換を提供し、ＳＩＰ  ＩＮＶＩＴＥメッセージをＳ‐ＣＳＣＦ３２へ送信する（ステップ４３６）。ＳＩＰ  ＩＮＶＩＴＥメッセージは、ユーザ１のエンタープライズ識別子の代わりに、ユーザ１のキャリア識別子を使用する。アプリケーションサーバ３４は呼シグナリングパス内に留まるように呼び出されているため、Ｓ‐ＣＳＣＦ３２は、前記アプリケーションサーバ３４を介してＳＩＰ  ＩＮＶＩＴＥメッセージをルーティングする。前記アプリケーションサーバ３４は、所望のサービスを提供するようにＳＩＰ  ＩＮＶＩＴＥメッセージに処理してもしなくても良い。このために、Ｓ‐ＣＳＣＦ３２がＳＩＰ  ＩＮＶＩＴＥメッセージをアプリケーションサーバ３４へ転送し（ステップ４３８）、アプリケーションサーバ３４はＳＩＰ  ＩＮＶＩＴＥメッセージを処理してもしなくてもよく、次に、その後得られたＳＩＰ  ＩＮＶＩＴＥメッセージをＳ‐ＣＳＣＦ３２へ転送する（ステップ４４０）。次に、Ｓ‐ＣＳＣＦ３２はＳＩＰ  ＩＮＶＩＴＥメッセージをＰ‐ＣＳＣＦ７０へ転送すると（ステップ４４２）、Ｐ‐ＣＳＣＦ７０が、アクセスポイント６６を介して、ＳＩＰ  ＩＮＶＩＴＥメッセージをモバイル端末２４へ転送する（ステップ４４４）。
【００４６】
モバイル端末２４は、ＳＩＰ  ＩＮＶＩＴＥメッセージを受信すると、着呼がある旨の注意喚起をユーザ１に対して開始し、さらに、ＳＩＰ１８０リンギングメッセージをＰ‐ＣＳＣＦ７０へ返送する（ステップ４４６）。Ｐ‐ＣＳＣＦ７０はＳＩＰ１８０リンギングメッセージをＳ‐ＣＳＣＦ３２へ転送し（ステップ４４８）、次に、Ｓ‐ＣＳＣＦ３２が、前記ＳＩＰ１８０リンギングメッセージをアプリケーションサーバ３４を介して転送し（ステップ４５０および４５２）、その後さらに、前記ＳＩＰ１８０リンギングメッセージをサービスノード３６へ転送する（ステップ４５４）。サービスノード３６は、キャリア識別子からエンタープライズ識別子への変換を、任意の必要なプロトコル変換と共に提供し、ＳＩＰ１８０リンギングメッセージをエンタープライズアプリケーションサーバ５０に転送する（ステップ４５６）。第２ユーザ端末４８は、ユーザ１に着呼が提示されていることを既に知得しているので、第２ユーザ端末４８にはＳＩＰ１８０リンギングメッセージは転送されない。
【００４７】
ユーザ１がモバイル端末２４にて呼に応答すると仮定した場合は、モバイル端末２４からＰ‐ＣＳＣＦ７０にＳＩＰ２００ＯＫメッセージが送信される（ステップ４５８）。Ｐ‐ＣＳＣＦ７０がＳＩＰ２００ＯＫメッセージをＳ‐ＣＳＣＦ３２へ転送すると（ステップ４６０）、Ｓ‐ＣＳＣＦ３２が、ＳＩＰ２００ＯＫメッセージをアプリケーションサーバ３４を介して転送してから（ステップ４６２および４６４）、さらにサービスノード３６へ転送する（ステップ４６６）。ここでも、サービスノード３６は、ＳＩＰ２００ＯＫメッセージをエンタープライズアプリケーションサーバ５０へ転送する前に、適切なキャリア識別子からネットワーク識別子への変換とプロトコル変換とを提供する（ステップ４６８）。次に、エンタープライズアプリケーションサーバ５０は、モバイル端末２４が呼に応答したことを示すために、ＳＩＰ２００ＯＫメッセージを第２ユーザ端末４８へ転送する（ステップ４７０）。第２ユーザ端末４８とモバイル端末２４が通信機能を交換できるようにし、これらの間にＶｏＩＰベースのベアラパスを確立できるようにするために、ＳＩＰ  ＩＮＶＩＴＥとＳＩＰ２００ＯＫメッセージのそれぞれを、必要なＳＤＰ情報を伝送する目的で使用することができる（ステップ４７２）。
モバイル端末２４が呼に応答すると、エンタープライズアプリケーションサーバ５０はＳＩＰキャンセルメッセージを第１ユーザ端末４６へ送信して、第１ユーザ端末４６への呼の提示を終了させる（ステップ４７４）。
【００４８】
この実施形態では、モバイル端末２４はＩＭＳ１４を通ってエンタープライズネットワーク１６にアクセスする。こうすることで、アプリケーションサーバ３４を使用して、呼シグナリングを第２ユーザ端末４８にアンカリングできるようになり、このためにモバイル端末２４は、この後、呼の中断なくＣＳ２０またはＰＳ２２へ容易に移動できるようになる。アプリケーションサーバ３４は、上で参照した用途にて述べたとおりに呼をアンカリングすることができる。アプリケーションサーバ３４は、呼処理と呼アンカリングに加えて、他のサービスを提供することもできる。呼の別例では、パケットネットワークを介してＩＭＳネットワークに接続した固定端末２４’を使用して、ユーザ１を呼び出すことができる。このシナリオでは、サービスノード３６は、先述の例と同様に、キャリア識別子からエンタープライズ識別子への変換を、任意の必要なプロトコル変換と共に実行する。
【００４９】
図７を参照すると、本発明の一実施形態に係るサービスノード３６を示す。サービスノード３６は、必要なソフトウェア７６が上述通りに動作するのに十分な容量のメモリ７４を実装した制御システム７２を備えている。制御システム７２は、通信環境１０内の他のノードとの直接または間接的な通信を容易にするために、通信インターフェース７８にも関連している。
【００５０】
図８を参照すると、本発明の一実施形態に係るエンタープライズアプリケーションサーバ５０を図示している。エンタープライズアプリケーションサーバ５０は、必要なソフトウェアが上述どおりに動作するのに十分な容量のメモリ８２を実装した制御システム８０を含んでいる。 制御システム８０はまた、通信環境１０内の他のノードとの直接または間接的な通信を促進するために、通信インターフェース８６にも関連している。
【００５１】
図９を参照すると、本発明の一実施形態に係るＳ‐ＣＳＣＦ３２を示している。Ｓ‐ＣＳＣＦ３２は、必要なソフトウェア９２が上述どおりに動作するのに十分な容量のメモリ９０を実装した制御システム８８を含む。制御システム８８は、通信環境１０内の他のノードとの直接または間接的な通信を促進するために、通信インターフェース９４にも関連している。
【００５２】
当業者は、本発明の好ましい実施形態に対する改善および改良を理解するだろう。
このような全ての改善および改良は、本明細書で開示した概念と以下の請求項の範囲内に含まれるものと考える。
【図１】
2010509792.tif 000003
【図２Ａ】
2010509792.tif 000004
【図２Ｂ】
2010509792.tif 000005
【図２Ｃ】
2010509792.tif 000006
【図３Ａ】
2010509792.tif 000007
【図３Ｂ】
2010509792.tif 000008
【図４Ａ】
2010509792.tif 000009
【図４Ｂ】
2010509792.tif 000010
【図５】
2010509792.tif 000011
【図６Ａ】
2010509792.tif 000012
【図６Ｂ】
2010509792.tif 000013
【図６Ｃ】
2010509792.tif 000014
【図７】
2010509792.tif 000015
【図８】
2010509792.tif 000016
【図９】
2010509792.tif 000017