JP5273739B2 - 回線交換とマルチメディアサブシステム音声継続 - Google Patents

Description

本発明は通信に関し、特に回線交換サブシステムとパケットサブシステム上のセッションをサポートする集中制御機能を提供すると共に、一つのサブシステムから他のサブシステムへ複数確立されたセッションの転送を達成することに関する。

本出願は、2006年10月4日に出願された米国特許仮出願第６０／８４９，３９１号の利益を主張し、これによって、その全内容が参照として組み込まれる。
パケット通信は、音声セッション、すなわち電話が回線交換通信により提供されるのと基本的に同じ質のサービスをサポートできるレベルにまで発展してきている。パケット通信は一般的にパケットサブシステムによりサポートされ、それは元来ローカルエリアネットワークによりサポートされたが、現在では無線ローカルエリアネットワーク（無線LAN）等によりサポートされる。ユーザー要素は無線LANにアクセスして無線LAN内全域を移動している間、パケット通信を使用して音声セッションを保持することが出来る。そのように無線LANアクセスは、セルラー環境の中でセルラーアクセスが利用者に提供するのと同じ移動の自由を、無線LAN内で利用者に提供する。

多くの場合、無線LANとセルラーネットワークから提供されるサービスエリアは相補的である。例えば無線LANは、セルラーの電波の受信可能範囲が制限される建物内に構築し得る。無線LANの性質上、受信可能範囲の局部的なので、セルラーネットワークは複数の無線LANの間の受信可能範囲の隙間を橋渡しさせることができる。残念なことに無線LANアクセス技術は、従来セルラーのアクセス技術とは伝統的に独立したものである。セルラーネットワークは一般的に回線交換通信をサポートし、無線LANは一般的にパケット通信をサポートする。このため、ユーザー要素は、セルラーと無線LAN通信の両方を異なる通信インターフェースを使ってサポートする様に開発されてきた。これらのユーザー要素では、利用者はそれぞれの通信インターフェースを使って、セルラーネットワークと無線LANの両方を介してセッションを確立できる。しかしながら、セルラーネットワークを介して確立されたセッションは無線LANに簡単に転送できず、その逆もまたしかりである。さらに、セッションが転送されると、セッションを制御し、セッションに関連したサービスを提供する能力が限られたものになる。

これらの問題に対処するために、2006年3月17日に出願され、「回線交換とマルチメディアサブシステム音声継続」と題された、同一出願人による米国特許出願番号11/378,776は、セルラーネットワークと無線LANの両方におけるユーザー要素のセッションを有効にサポートし、それぞれのネットワーク間のセッションのシームレスな転送を行う新たな技術を提供している。この技術により、セッションと関連しているサービスをもまた、一つのネットワークからもう一つのネットワークへの転送後に維持されるようになる。2006年3月17日に出願された米国特許出願番号11/378,776は、その全内容が参照として本書に取り込まれている。

特に、公開されている技術は、ユーザー要素用のセッション制御を含むサービス制御を、セルラーネットワークからインターネットプロトコル（IP）マルチメディアサブシステム（IMS）などのマルチメディアサブシステム（MS）へと移動させる。このため、セッション制御は、ユーザー要素が、セッション用にセルラーアクセスを使っているのか、無線LAN（などの）アクセスを使っているのかに関係なく、MSから提供される。明確且つ簡潔のため、回線交換通信を提供するセルラーネットワークは、ここでは回線交換サブシステム（CS）と称し、パケット通信を提供している無線LAN等の無線ネットワークは、MSの一部か又はそれに関連していると説明上ここでは仮定する。当業者は理解することであるが、MS、無線LAN、又はその他の関連したパケットを基礎としたネットワークをサポートするために、パケットネットワークはいくつ用いても良い。

CS又はMS内でセッションを開始または終了、またはCSとMS間でセッションを転送するための、呼制御を含むセッション制御は、MSの中の継続制御機能（CCF）にアンカーされている。このセッションのセッションシグナリングは全て、CCFを通して渡される。CCFはMSの中に提供されるサービスで、ユーザー要素の現在進行中のCSにサポートされるセッション又はMSにサポートされるセッションを、CSとMSとの間で移動可能となる様、アンカーする。特に、「セッション」という単語は、声、データ、音声、又は映像セッションを含む、いかなるタイプの回線交換あるいはパケットを基礎とした通信セッションをも対象としている。

CSにサポートされるセッションの場合には、CCFはユーザー要素によりメディアゲートウェイにおいてCS内で開始、終了されるセッションのベアラパスをアンカーしても良く、メディアゲートウェイはMSのメディアゲートウェイコントローラで制御され得る。MSにサポートされるセッションの場合には、CCFは、ユーザー要素とリモートエンドポイントと相互作用することにより、MSを介してユーザー要素とリモートエンドポイントの間に直接ベアラパスを確立するためのセッション制御を提供する。CCFはパブリックサービスアイデンティティ（PSI）を使うことによりアドレス可能で、PSIは電話登録番号（Directory Number）、ＵＲＬなどのようなアドレスの形を取り得る。CS内では、CCFに関連した電話登録番号PSIをCSの中のルーティングセッションシグナリングメッセージに使用しても良い。MS内では、CCFに関連したPSI URLがMSの中のルーティングセッションシグナリングメッセージに使用しても良い。

サブシステム転送により、ユーザー要素は、一つ又はそれ以上のアクティブセッションを維持しながら、CSとMSの間を移動できるようになる。ある所定のセッションに関するセッション転送では、一般的にユーザー要素から受け取った要求に基づいて、開始とそれに続く転送も含めて、CCFによってMS内で実行、制御される。この転送を可能にするために、CCFはセッションのシグナリングパス内へ、サービング呼セッション制御機能（S−CSCF）により挿入される。シグナリングパスをアンカーするために、CCFはバックトゥバックユーザーエージェント機能を用いてもよく、その動作は次のようである。ユーザー要素がセッションを開始すると、CCFがユーザー要素からのアクセスシグナリングレッグを終了し、リモートエンドポイントへ向かってリモートシグナリングレッグを確立する。ユーザー要素においてセッションを終了する時は、CCFがリモートエンドポイントからのリモートシグナリングレッグを終了し、ユーザー要素に向かってアクセスシグナリングレッグを確立する。その後、CCFはこのセッションのアクセスシグナリングレッグとリモートシグナリングレッグとの間のセッションシグナリングを調整又は相互機能する。

ユーザー要素がセッションを開始すると、CCFはアプリケーションサーバーから提供されるサービスとして現れ得る。一実施形態によると、CCFは一連のサービスの中の最初のサービスとして呼び出される。ユーザー要素がセッションを終了すると、CCFは一連のサービスの中の最後のサービスとして呼び出される。この様に他のサービスに関してCCFを置くことにより、セッションに関連する他のアプリケーションがセッションのリモートシグナリングレッグの一部としてCCFによってアンカーされ、それ故、アクセスシグナリングレッグに作用する転送による影響を受けない。

転送を必要とする条件を検出した際、ユーザー要素は、CS又はMSを基礎にしたCCF用のアドレスを使ってCCFとのアクセスシグナリングレッグを確立する。アクセスシグナルレッグは「転入」サブシステムを介して、転入サブシステムへの転送要求をするために確立される。CCFは、リモートシグナリングレッグと現在通信中のアクセスシグナルレッグを、転入サブシステムを介して確立されたアクセスシグナリングレッグと置換することによって、サブシステム転送手続きを実行する。CCFはその後、「転出」サブシステムにより確立されたアクセスシグナリングレッグを解放する。

アクセスシグナリングレッグの、転出サブシステムから転入サブシステムへの交換はリモートシグナリングレッグあるいは、リモートシグナリングレッグ内のアプリケーションサービスに影響を与えない。リモートシグナリングレッグと転入サブシステムの中のアクセスシグナルレッグを通して、適切なCSクライアント又はMSクライアントを介してユーザー要素に適切なベアラパスを確立しても良い。全てのセッションシグナリングはCCFを通して提供されるので、何度転送されても追加サービスをセッションと関連付けても良い。

多くの場合、ユーザー要素は同じドメイン内で同時に複数セッションをサポートしている。ユーザー要素が一つのドメインから他のドメインへ転送する場合、例えばCSからMSへ、またはその逆などの場合、複数セッションのそれぞれを転出ドメインから転入ドメインに転送し、ドメイン転送にわたってセッション継続を維持することが望ましい。従って、サービス継続を維持しながら、ドメイン転送に関連して、ドメイン間の複数同時セッションを転送する技術が必要である。

本発明は、セルラーネットワークのような回線交換サブシステムから、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）などのようなマルチメディアサブシステム（MS）への、ユーザー要素のセッション制御の移動に関する。セッション制御は、ユーザー要素が、セッション用にセルラーアクセスを使用しているか、ローカル無線アクセスを使用しているかに関わらず、MSにより提供される。特に、複数セッションは、ある所定のユーザー要素用に同時に制御されるようにしても良い。CS又はMS内での複数同時セッションの開始と終了や、これらのセッションのCSとMS間の転送のためのセッション制御は、MSの中の継続制御機能（CCF）によりアンカーされる。複数セッションのそれぞれのための全てのセッションシグナリングはCCFを通過する。CCFはMS内で提供されるサービスであり、ユーザー要素のセッションをアンカーすると共に、CSとMS間でのドメイン転送を可能にする。

ドメイン転送を必要とする条件を検出した際に、ユーザー要素は、転入ドメインを介し、転出ドメインから転入ドメインへの複数セッション用のドメイン転送を開始しても良い。複数セッションのそれぞれのための新しいアクセスシグナリングレッグは、複数ドメインを転入ドメインに転送するための要求に関連して、転入ドメインを介して確立される。CCFは、転出ドメインの古いアクセスシグナリングレッグの各々を、転入ドメインを介して確立された対応する新しいアクセスシグナリングレッグと置換することにより、サブシステム転送手続きを実行する。それから転入ドメイン内のアクセスシグナリングレッグは、CCFによって、複数セッションの対応するリモートシグナリングレッグと相互機能する。その後CCFは転出ドメインを介して確立された古いアクセスシグナリングレッグを解放する。

CSアクセスの場合は、ユーザー要素に向かってCSへ拡張しているアクセスシグナリングレッグはリモートユーザーエージェントを通って拡張すれば良く、ユーザーエージェントはMSの中の要素に対し、自身をユーザー要素として表している。CSのシグナリング能力によっては、リモートユーザーエージェントは、ユーザー要素と実質的に直接的に、あるいはCSアクセス適応機能（CAAF）を介して相互接続され得る。CAAFはセッションシグナリングを、それぞれのサブシステムの適切なフォーマットへ変換するために、MSとCSとの間の連絡係としての役割を果たす。

個々の複数セッションは関連したベアラパスを持ち得る。ベアラパスのCSに含まれていない部分は、お互いに分離されていることが好ましい。しかしながら、CSによって部分的にサポートされているセッションの場合は、共通のCSベアラ部分がそれぞれのベアラパスによって共有され得る。共通のCSベアラ部分が共有される場合は、MS内のベアラパスの部分は、分離されたままになっていても良い。

次に続く、添付されている図面に関連している好ましい形態の詳細な説明を読めば、本発明の範囲は当業者であれば理解できるであろうことは言うまでもなく、そのさらなる特徴も理解されることである。

一つのセッションがサポートされた実施形態によるユーザー要素に対しての回線交換サブシステムアクセスを説明する、通信環境図である。 一つのセッションがサポートされた実施形態によるユーザー要素に対してのマルチメディアサブシステムアクセスを説明する、通信環境図である。 ベアラパスのCS部分の制御用のシグナリングパスがサポートされた実施形態によるユーザー要素に対しての回線交換サブシステムアクセスを説明する、通信環境図である。 複数セッションがサポートされた本発明の実施形態によるユーザー要素に対しての回線交換サブシステムアクセスを説明する、通信環境図である。 複数セッションがサポートされた本発明の実施形態によるユーザー要素に対してのマルチメディアサブシステムアクセスを説明する、通信環境図である。 本発明の一実施形態による、セッションのCSからMSへの転送を説明する通信フローである。 本発明の一実施形態による、セッションのCSからMSへの転送を説明する通信フローである。 本発明の一実施形態による、セッションのMSからCSへの転送を説明する通信フローである。 本発明の一実施形態による、セッションのMSからCSへの転送を説明する通信フローである。 本発明の一実施形態による、セッションのMSからCSへの転送を説明する通信フローである。 複数セッションがサポートされた本発明の他の実施形態によるユーザー要素に対しての回線交換サブシステムアクセスを説明する、通信環境図である。 複数セッションがサポートされた本発明の他の実施形態によるユーザー要素に対してのマルチメディアサブシステムアクセスを説明する、通信環境図である。 本発明の他の実施形態による、セッションのMSからCSへの転送を説明する通信フローである。 本発明の他の実施形態による、セッションのMSからCSへの転送を説明する通信フローである。 本発明の他の実施形態による、セッションのMSからCSへの転送を説明する通信フローである。 本発明の一実施形態によるサービスノードのブロック図である。 本発明の一実施形態によるユーザー要素のブロック図である。

この明細書に組み込まれ、その一部を成している添付図面は本発明のいくつかの特徴を説明するものであり、その説明と共に本発明の主要部を明らかにするものである。
以下に説明する実施形態は、当業者が本発明を実施するために必要な情報であり、本発明の実施の最も好ましい態様を説明している。添付の図面を踏まえて次の記述を読むことにより、当業者は本発明の概念を理解し、これらの概念の、特にここに記載されていない応用を認識するであろう。これらの概念と応用もまた、開示と添付の特許請求の範囲に含まれることは理解されるべきことである。

次の記述は、一つのセッションに係属するユーザー要素のCSアクセスとMSアクセスの両方の例示的な概要を初めに説明するものである。一つのセッションの、CSアクセスとMSアクセスの両方のベアラパスとシグナリングパスについて、一つのセッションが一つのドメインからもう一つのドメインへ転送される場合のCSドメインとMSドメイン間のドメイン転送の概要と共に説明する。次に、ユーザー要素が複数セッションに係属しているときのCSアクセスとMSアクセスの両方の概要について、本発明の一実施形態に関して説明する。複数同時セッションの各々のベアラパスとシグナリングパスについて、複数セッションが同時に転送されている時のCSドメインとMSドメイン間のドメイン転送の概要と共に説明する。それから、本発明の選択的な実施形態によって複数同時セッションが行われている場合の、CSドメインとMSドメイン間のドメイン転送手順を例示的に説明するため通信フローを詳細に示す。最後に、複数セッションが転送されている時に利用できるドメイン転送手順を示した、別のCSアクセス技術と共にそれに対応する通信の流れを説明する。

図１には、本発明の一実施形態による通信環境１０が示されている。通信環境１０では、MS１２と移動先のCS１４がユーザー要素１６用に通信をサポートしている。MS１２はユーザー要素１６のホームネットワークであっても良い。ユーザー要素１６は、CS１４を介して回線交換通信をサポートし、MS１２を介してパケット通信をサポートするよう構成されているCSクライアント１８とMSクライアント２０を含んでいても良い。CS１４内の通信の場合、移動先の移動交換局（VMSC）２２がユーザー要素１６の回線交換通信をサポートする。VMSC２２は、メディアゲートウェイコントローラ（MGC）２４と、関連したメディアゲートウェイ（MG)２６を介してMS１２と相互接続しても良い。メディアゲートウェイコントローラ２４とメディアゲートウェイ２６は両方ともMS１２に関連している。

MS１２は、インテロゲーティング・サービング呼セッション制御機能（I/S-CSCF）２８、CCF３０、リモートユーザーエージェント（RUA)３２Ｒ、CAAF３２Cとホームサブスクライバーサービス（HSS)３４を含む様々な機能やエンティティを含み得る。特に、インテロゲーティングCSCFは標準的なI-CSCF機能を提供し、サービングCSCFは標準的なS-CSCF機能を提供する。これらの機能は、しばしば分離されているが、簡潔さのためにI/S-CSCF２８として表されている。さらに、HSS３４はCS１４とMS１２の両方にも存在し得る。HSS３４は、ホームCSのホームロケーションリソース（HLR)成分を含み得る。MS１２内の呼セッション制御機能（CSCF)は、一般的にセッション開始プロトコル（SIP)又は同様なプロキシの役割を演じ、セッション制御と共に様々な機能を提供することは、当業者であれば理解できるであろう。動作中、インテロゲーティングCSCF（I-CSCF)は、ある所定のユーザー要素をサポートするように割り当てられるサービングCSCF（S-CSCF)を識別するためにHSS３４と相互的に作用すれば良い。HSS３４は、ユーザー要素１６とユーザー要素１６に割り当てられている特定のCCF３０との関連を維持し得る。そのために、HSS３４はユーザー要素１６に使用されることが出来るサービングCSCFを認識する援助をして、特定のCCF３０とユーザー要素１６との関連を持続し得る。CCF３０へのアクセスを得るために使われるユーザー要素１６のCCF・PSIは、CCF３０によってユーザー要素１６による転送開始やそのほかのコントロールの開始を可能にするためにユーザー要素１６内に位置され得る。あるいは、CCF・PSIはネットワーク登録上又は他の時でもユーザー要素１６へ転送され得る。

HSS３４は、CCF３０に関連するフィルタ基準をユーザー要素の加入者プロフィールの一部として記憶し得る。CCFフィルタ基準は、現在割り当てられているI/S-CSCF２８に、ユーザー要素１６がMS１２に登録される時に使われる最初のフィルタ基準の一部としてダウンロードされる。このフィルタ基準は一般的に、I/S-CSCF２８によって、ユーザー要素１６からセッションが開始される時か、あるいはユーザー要素１６に向け入ってくるセッションを受け取る時に、実行される。このフィルタ基準は、少なくともセッション用のベアラパスを制御するためにCCF３０を呼び出すよう、I/S-CSCF２８に指示を与えても良い。

RUA３２Rは、ユーザー要素１６の代わりにCS１４にサポートされるセッション用にMS１２内のリモートユーザーエージェント機能を提供し得る。従って、RUA３２Rは、ユーザー要素１６がCS１４によってサポートされている時に、I/S-CSCF２８などのMS１２の様々な構成要素に対し、自身をユーザー要素１６として表している。RUA３２RはCAAF３２Cと共に緊密な協力関係で働いてもよく、CAAF３２CがCS１４にインターフェースを提供し、CS１４とRUA３２R間でシグナリング連絡係の役割を果たす。CS１４からのCSシグナリングはCAAF３２Cで受け取られ、MS１２内で、セッション開始プロトコル（SIP)シグナリングのように、適切な形で配信のためにRUA３２Rに送られる。同様に、MS１２からのMSシグナリングはRUA３２Rで受け取られ、CS１４内で適切な形で配信のためCAAF３２に送られる。高いレベルでは、CAAF３２CとRUA３２Rは、少なくとも部分的にCS１４によってサポートされているセッション用に、CS１４とMS１２間でシグナリングゲートウェイとプロキシ機能を提供する。

任意の数の機能やサービスを実装するために、アプリケーションサーバー（図示せず）を呼び出し、セッションシグナリングパス内に設置しても良い。アプリケーションサーバーから提供されている特定のアプリケーションサービスが呼び出されると、関連している単数或いは複数のセッションの全てのシグナリングは、アプリケーションサービスを通り、このアプリケーションサービスがセッションシグナリングメッセージを、目的とするサービスを実行するために必要に応じて処理する機会を持つ。特に、CCF３０はサービスのような役割を果たし、I/S-CSCF２８自体はこのセッションの全てのセッションシグナリングメッセージがCCF３０を通るように動作し、それによりCCF３０がセッションをアンカーする役割を果たすようになる。

図１では、ユーザー要素１６はCSクライアント１８にサポートされてCCF３０に制御されているセッションに係属している。そのために、このセッションのセッションシグナリングは、VMSC２２、CAAF３２C、RUA３２R、I/S-CSCF２８、CCF３０と、もしサーバーが呼び出されているならアプリケーションサーバーを通り、リモートユーザー要素３６へ向かう。特に、CS１４により提供されるアクセスシグナリングレッグはCCF３０でアンカーされ、I/S-CSCF２８、RUA３２R、CAAF３２C、VMSC２２、そしてユーザー要素１６のCSクライアント１８を通って延びている。リモートユーザー要素３６へのリモートシグナリングレッグはCCF３０内でアンカーされており、I/S-CSCF２８と、呼び出されている任意のアプリケーションサーバーを通って延びている。この構成では、CCF３０はセッションの制御を維持することができ、セッション中に任意の必要なセッション処理を提供することが出来る。さらに、セッション転送が要求されると、CCF３０はリモートシグナリングレッグを維持しながら、転入ドメインを介してユーザー要素１６との新しいアクセスシグナリングレッグを確立する。

図１で図解されているセッションのベアラパスは、リモートユーザー要素３６へ向かって、CSクライアント１８からVMSC２２とメディアゲートウェイ２６を通って延びている。特に、メディアゲートウェイコントローラ２４は、メディアゲートウェイ２６と協力して、メディアゲートウェイ２６とCSクライアント１８間にVMSC２２を介して回線交換接続が確立されるようになる。メディアゲートウェイ２６からMS１２を通ってリモートユーザー要素３６へのセッション用にパケットセッションが確立されても良い。

図２を参照すると、ユーザー要素１６のMSクライアント２０によってサポートされているセッションが示されている。特に、セッションはCS１４を通って延びておらず、VMSC２２、CAAF３２C、RUA３２R、メディアゲートウェイコントローラ２４、或いはメディアゲートウェイ２６のサービスを用いない。その代わりに、MSクライアント２０は直接MS１２を使って、特にCCF３０を使って、I/S-CSCF２８を介してセッションシグナリングをサポートする。特に、異なる複数のドメインを介したアクセス用には異なる複数のCSCFを使っても良い。

図示されているように、セッションシグナリングはCCF３０内でアンカーされ、アクセスシグナリングレッグは、IS-CSCF２８を介してCCF３０とMSクライアント２０間に提供されている。リモートシグナリングレッグは、IS-CSCF２８と、セッションに関して追加のサービスを提供し得る任意の望ましいアプリケーションサーバーを介してリモートユーザー要素３６とCCF３０間でサポートされている。ベアラパスはMSクライアント２０から、CS１４を通らないでMS１２を介してリモートユーザー要素３６へ延びている（図２）。そしてまた、CCF３０はセッションをアンカーし、それによりもし一つのドメインから他のドメインへの転送が要求された場合は、リモートユーザー要素３６へのリモートシグナリングレッグは維持され、一方で、次にさらに述べるようにアクセスシグナリングレッグはMS１２からCS１４への転送を促進するよう変換され得る。CS１４とMS１２間のセッションの転送の場合は、図１と２に図解されているアクセスシグナリングレッグがそれぞれ、転送をサポートするように変換され、一方でリモートシグナリングレッグがCCF３０によって維持される。

一般的に、サブシステム転送によりユーザー要素１６は、一つ又はそれ以上の、音声や他のメディアなどのアクティブセッションを維持しながら、CS１４とMS１２間で移動可能になる。ある所定のセッションに関するセッション転送は、その開始とそれに続く転送も含め、ユーザー要素１６からの要求を受けると、MS１２内でCCF３０により実行、制御される。そのような転送を可能にするために、CCF３０は、I/S-CSCF２８によってセッションのシグナリングパスに挿入される。シグナリングパスをアンカーするために、CCF３０は、バックトゥバックユーザーエージェント機能（Ｂ２ＢＵＡ）を用いてもよく、その動作は次のように動作し得る。ユーザー要素１６がセッションを開始すると、CCF３０がユーザー要素１６からのアクセスシグナリングレッグを終了し、リモートユーザー要素３６へリモートシグナリングレッグを確立する。ユーザー要素１６がセッションを終了すると、CCF３０はリモートユーザー要素３６からのリモートシグナリングレッグを終了し、ユーザー要素１６へアクセスシグナリングレッグを確立する。続いて、CCF３０はこのセッションに対し、アクセスシグナリングレッグとリモートシグナリング間のセッションシグナリングを調整する。

ユーザー要素１６がセッションを開始しようとするとき、CCF３０はアプリケーションサーバーによって提供されるサービスのように見え得る。一実施形態では、CCF３０は一連のサービスの中の最初のサービスとして呼び出される。ユーザー要素１６がセッションを終了しようとする時、CCF３０は一連のサービスの最後のサービスとして呼び出される。この様に他のサービスに関してCCFを置くことにより、セッションに関連する他のアプリケーションがセッションのリモートシグナリングレッグの一部としてCCF３０によってアンカーされ、それ故、アクセスシグナリングレッグに作用する転送による影響を受けない。

転送を必要とする条件を検出した際、ユーザー要素１６は、CCF３０用の、CS又はMSを基礎にしたアドレスを使ってCCF３０とのアクセスシグナリングレッグを確立する。アクセスシグナルレッグは、転入サブシステムを介して、転入サブシステムへの転送要求をするために、確立される。CCF３０は、リモートシグナリングレッグと現在通信しているアクセスシグナルレッグを、転入サブシステムを介して確立されたアクセスシグナリングレッグと置換することによって、サブシステム転送手続きを実行する。CCF３０はその後、転出サブシステムにより確立されたアクセスシグナリングレッグを解放する。アクセスシグナリングレッグの、転出サブシステムから転入サブシステムへの交換はリモートシグナリングレッグあるいは、リモートシグナリングレッグ内のアプリケーションサービスに影響を与えない。リモートシグナリングレッグと転入サブシステムの中のアクセスシグナルレッグを通して、適切なベアラパスが、適切なCSクライアント１８又はMSクライアント２０を介してユーザー要素１６に確立され得る。全てのセッションシグナリングはCCF３０を通して提供されるので、何度転送をしても追加サービスをセッションと関連付けることができる。

セッションがCS１４を介してサポートされている時、ベアラパスの回線交換部分はユーザー要素１６からVMSC２２を通って、メディアゲートウェイ２６へ延びる。ベアラパスのこの部分の確立と制御とに関わるシグナリングは、図３に図解されているようにユーザー要素１６とRUA３２R間をVMSC２２、メディアゲートウェイコントローラ２４、そしてI/S-CSCF２８を通って延び得る。これにより、RUA３２ＲとVMSC２２は、セッションがCS１４にサポートされている時に、ベアラパスの回線交換部分を、メディアゲートウェイ２６からリモートユーザー要素３６へ延びるベアラパスのパケット方式の部分と連携して有効に制御することができる。

本発明では、ある所定のユーザー要素１６が複数セッションを同時にサポートしても良く、そしてユーザー要素１６が一つのドメインから別のドメインへ転送する時は、複数セッションの各々も、セッションの継続を維持しながら転送される。図４では、ユーザー要素１６が２つのセッション、セッション１とセッション２に係属しており、その両方がCSクライアント１８によってサポートされ、セッションを制御しているCCF３０にアンカーされている。このため、それぞれのセッションのセッションシグナリングは、リモートユーザー要素３６へ向かう途中でVMSC２２、CAAF３２C、RUA３２R、I/S-CSCF２８、CCF３０と、もしサーバーが呼び出されているならアプリケーションサーバーを通る。特に、それぞれのセッションのアクセスシグナリングレッグはCCF３０にアンカーされ、I/S-CSCF２８、RUA３２R、CAAF３２C、そしてユーザー要素１６のCSクライアント１８を通って延びている。それぞれのセッションのリモートシグナリングレッグはCCF３０でアンカーされ、I/S-CSCF２８と、呼び出されている任意のアプリケーションサーバーを通ってそれぞれのリモートユーザー要素３６Bと３６Cへ向かって延びている。この構成では、CCF３０が両方のセッションの制御を維持することができ、セッション中に必要な任意のセッション処理を提供することができる。セッション転送が要求されると、CCF３０はリモートシグナリングレッグを維持しながら、転入ドメインを介してユーザー要素１６との新しいアクセスシグナリングレッグを確立する。

図解されているように、各々のセッションはCS１４では共通のベアラパスを共有し、そしてMS１２内には特有のベアラパスがある。特に、単独又は共通のCSベアラ部分はCSクライアント１８からVMSC２２を通ってメディアゲートウェイ２６へ延び得る。両方のセッションは、特に両方のセッションが音声セッションである場合、この共通のCSベアラ部分を共有し得る。MS１２内では、各々のセッションが特有のMSベアラ部分を持っている。そのために、２つのMSベアラ部分がメディアゲートウェイ２６からそれぞれリモートユーザー要素３６Bと３６Cへ延びている。メディアゲートウェイコントローラ２４の制御下にあるメディアゲートウェイ２６は、どのセッションがアクティブになっているかにより、単数のCSベアラ部分と適切なMSベアラ部分とを有効に相互機能させる。

図５を参照すると、セッション１とセッション２の両方がユーザー要素１６のMSクライアント２０によってサポートされている。セッションはCS14を通って延びておらず、VMSC２２、CAAF３２C、RUA３２R、メディアゲートウェイコントローラ２４、又はメディアゲートウェイ２６のサービスを用いない。その代わりに、MSクライアント２０が直接MS１２を使って、特にI/S-CSCF２８を介してCCF３０を使って両方のセッションのセッションシグナリングをサポートする。

そしてまた、セッションシグナリングはCCF３０にアンカーされ、それぞれのセッションのアクセスシグナリングレッグは、I/S-CSCF２８を介してCCF３０とMSクライアント２０間に提供される。リモートシグナリングレッグはリモートユーザー要素３６Bと３６CとCCF３０との間でI/S-CSCF２８を介して、セッションに関して追加のサービスを提供し得る任意の望ましいアプリケーションサーバーとの間でサポートされる。これらのセッションの異なるベアラパスは、MSクライアント２０から、CS１４を通らずにMS１２を介してそれぞれリモートユーザー要素３６Bと３６Cへ向かって延びている。そしてまた、一つのドメインから他のドメインへの転送が要求された場合にリモートユーザー要素３６Bと３６Cへのリモートシグナリングレッグが維持されるようにCCF３０はセッションをアンカーし、一方でアクセスシグナリングレッグはMS１２からCS１４への転送を促進するよう変換され得る。セッションをCS１４とMS１２間で転送するために、図４と５に図解されているアクセスシグナリングレッグは転送をサポートするように変換され、一方でリモートシグナリングレッグはCCF３０によって維持される。

単数のセッション転送のように、複数セッション転送により、現在進行中の複数セッションと、これらの複数セッションの適切な状態を維持しつつ、ユーザー要素１６はCS１４とMS１２間で移動できるようになる。それぞれの現在進行中のセッションに関わる複数のセッション転送は、その開始とそれに続く転送も含め、ユーザー要素１６からの要求を受けると、CCF３０によってMS１２内で実行、制御される。そしてまた、I/S-CSCF２８によってそれぞれの複数セッション用にCCF３０がシグナリングパスに挿入される。シグナリングパスをアンカーするために、CCF３０は各々のセッションために一つのB２BUAを使用してもよい。CCF３０は、各々のセッションに対し、アクセスシグナリングレッグとリモートシグナリングレッグ間のセッションシグナリングを調整する。

転送を必要とする条件を検出する上で、ユーザー要素１６は、CCF３０用の、CS又はMSを基礎にしたアドレスを使ってCCF３０とのセッション用にアクセスシグナリングレッグを確立する。アクセスシグナルレッグは転入サブシステムを介して、転入サブシステムへの転送要求をするために確立される。CCF３０は、リモートシグナリングレッグと現在通信しているアクセスシグナルレッグを、転入サブシステムを介して確立されたアクセスシグナリングレッグと置換することによって、サブシステム転送手続きを実行する。CCF３０はその後、転出サブシステムを通って確立されたアクセスシグナリングレッグを解放する。アクセスシグナリングレッグの、これらの複数のセッションに対しての転出サブシステムから転入サブシステムへの交換は、複数のリモートシグナリングレッグにも、リモートシグナリングレッグ内のアプリケーションサービスにも影響を与えない。さらなる詳細を、次に続く複数の通信の流れ図に関連して示す。通信フローは本発明の例示的な実施形態として示されており、本発明の範囲をいかなる意味でも限定するものではない。これらの通信フローには、以下の原則を当てはめる。

パケットアクセスネットワークを介して、およびCS１４の外側において確立されたセッションは、第３世代移動体通信システムの標準化プロジェクト（３GPP）によって説明されているものなどの、標準IMS制御手順を使用する。各々のセッションは、それぞれ自身のシグナリングパスとベアラパスを持つ。セッション自体には複数のシグナリングパスと複数のベアラパスが必要になる。例えば、２つの呼に係属しているユーザー要素１６には各々がシグナリングパスとベアラパスを有する２つのセッションが必要である。全てのセッションはCCF３０内でアンカーされており、各々のセッションの各々のシグナリングパスは一つのシグナリングレッグと一つのリモートシグナリングレッグを有する。

CS１４を介して確立されたセッションは、CSベアラ部分を、CS１４を通ってMS１２へ延びているベアラパスの部分用に使用する。RUA３２Rは、これらのセッションのセッションシグナリングをMS１２に対して標準IMSセッションとして表す。それぞれのセッションはそれ自身のシグナリングパスを有するが、各々のセッションは、CS１４を通って延びているベアラパスのCSベアラ部分上でベアラパスを共有しても良い。異なるMSベアラ部分がMS１２を通って提供されている。そのために、複数セッションには、MS１２を通る複数のシグナリングパスと複数のベアラパスを必要とする。再び、一例として、２つの呼に係属しているユーザー要素１６には各々のセッションが一つのシグナリングパスと一つのベアラパスを有する２つのセッションが必要である。両方のセッションはCCF３０でアンカーされており、各々のセッションの各々のシグナリングパスは一つのアクセスシグナリングレッグと一つのリモートシグナリングレッグを有する。これらの実施形態では、一つのユーザー要素１６にとって、複数の音声でないセッションがアクティブになり得るが、単独のユーザーが２つの会話を同時に行える実行可能性からすると、常に一つの音声セッションだけがアクティブになっている。

ドメイン転送のためのセッション確立とドメイン転送の更新は、最初にセッションを設定するセッション確立に似ている。ドメイン転送の時に転出ドメインに存在している全てのセッションのためのアクセスシグナリングレッグは、転入ドメインからの情報を使ってCCF３０において更新される。これによりドメイン転送の後の現在進行中のセッションの適切な制御が確実なものとなり、現在進行中のセッションに対しての制御が、ドメイン転送後に確立されたどの新しいセッションとも一致したものとなる。

さらに、保留にされているセッションのための（保留セッションと称されるが）ベアラパスの確立は、ドメイン転送手順の完了のために必要でなくなる。ユーザーの観点に立つと、ドメイン転送手順は、アクティブセッション用に有効にサービスを回復した、アクティブセッションのためのベアラパスの確立の成功後に完了したと見なされる。保留セッションに対しての転出ドメイン内のアクセスシグナリングレッグは、転入ドメイン内の対応するアクセスシグナリングレッグが転入ドメインからの情報に更新された後に、いつでも解放されてもよい。転入ドメイン内での保留セッションに対してのベアラパスの確立は、転出ドメイン内でのアクセスシグナリングレッグの解放後までか、あるいは保留セッションが再開されるまで延期され得る。特に、リアルタイムプロトコル（RTP）情報が保留セッション内のベアラパスに存在し得ないが、ベアラパス上のリアルタイム制御プロトコル（PTCP）シグナリングは必要とされ得る。もしベアラパス上のRTCPシグナリングが保留セッション用に必要とされるなら、転入ドメイン内でのベアラパスが確立され、保留セッションが再開されるまで、ベアラパスは転出ドメイン内に維持され得る。

図６Aと６Bを参照すると、CS１４からMS１２へのドメイン転送を図解するために通信フローが提示されている。最初に、ユーザー要素１６（UE-A）が第１のセッション、つまりセッション１ではリモートユーザー要素３６B（UE-B）と係属しており、第２のセッション、つまりセッション２ではリモートユーザー要素３６C(UE-C)と係属している。この例の目的用にのみ、セッション１、つまりユーザー要素１６とリモートユーザー要素３６B間のセッションが保留され、セッション２、つまりユーザー要素１６とリモートユーザー要素３６C間のセッションがアクティブであると仮定する（ステップ１００）。さらに、両方のセッションは、リモートユーザー要素３６Bと３６Cそれぞれと電話通話をサポートする音声セッションであると仮定する。CS１４を通ってユーザー要素１６へ延びているセッション２のベアラパスは、VMSC２２とメディアゲートウェイ２６を通って、ユーザー要素１６とリモートユーザー要素３６Cの間を延びていると図解される（ステップ１０２）。セッション１のメディアは保留され、帯域内シグナリングの他に、ユーザー要素１６とリモートユーザー要素３６B間ではメディアは交換されていない。

ある時点で、ユーザー要素１６は、CS１４からMS１２へのドメイン転送に必要な条件を検出し得る（ステップ１０４）。言い換えると、ユーザー要素１６との無線通信を現在サポートしているCSアクセスはMS１２と関連しているパケットアクセスネットワークを通ってパケットアクセスへ転送されるべきである。ユーザー要素１６は異なるアクセスネットワークの条件を監視し、単独で、あるいは稼働中の基地局、アクセスポイント等と共同で決定を下してもよい。好ましくは、ユーザー要素１６は、アクティブでないあるいは保留セッションに先立ってアクティブセッションの転送を開始する。アクティブセッションであるセッション２に対しドメイン転送を開始するために、ユーザー要素１６はMS１２へCCF３０を対象としたInviteメッセージを送り得る。特に、InviteメッセージはCS１４を通ってはMS１２へ送られないが、その代わりにMS１２に関わるパケットアクセスネットワークを通って送られる。この場合、CS１４は転出ドメインで、MS１２は転入ドメインである。

InviteメッセージはCCF３０に対してのPSI（PSIA-C）を使って宛てられており、I/S-CSCF２８へ送られる（ステップ１０６）。I/S-CSCF２８はInviteメッセージをCCF３０へ転送する（ステップ１０８）。PSIは特有のセッションに関連付けられていても良く、又は転送を要求しているセッションを認識するために、他の方法を用いても良い。当業者には、別個のセッションIDを複数セッションに共通したPSIと併せて用いるなどのように、セッションを認識するための他の技術は認識されることである。Inviteメッセージは、セッション２（SDP-２UE）に対してのセッションデータプロトコル（SDP）を含んでいてもよい。そのSDPは、リモートユーザー要素３６Cが、CS１４の代わりにMS１２を通ってユーザー要素１６と通信する時に使うのに必要な通信パラメータを認識する。CCF３０は、InviteメッセージをMS１２へのドメイン転送用の要求として認識し、そのために、Re-Inviteメッセージを新しいSDP−２UEと共にリモートユーザー要素３６Cへ、I/S-CSCF２８を介して送る（ステップ１１０と１１２）。リモートユーザー要素３６Cへ送られたRe-Inviteメッセージは、メディアゲートウェイ２６を間接的に介して通信する代わりにMS１２を直接的に介してユーザー要素１６と通信するようリモートユーザー要素３６Cに有効に指示を与える。このプロセスを通して、ユーザー要素１６は、ドメイン転送にわたってセッション状態情報を維持し、CCF３０へ、必要であれば状態情報の更新を提供しても良い。同様に、CCF３０は、もしそう望まれればユーザー要素１６へも状態情報を提供し得る。

上記のことから、ドメイン転送用の要求を検出した場合、ユーザー要素１６は、CCF３０へ転入ドメイン内の新しいアクセスシグナリングレッグを介してInviteメッセージを送ることによりドメイン転送を開始し、これが、CS１４からMS１２へのセッション２のベアラパスの移行を容易にするためにリモートシグナリングレッグ上からリモートユーザー要素３６Cへ適切な更新を提供する。特にCCF３０からリモートユーザー要素１６へのアクセスシグナリングレッグはCS１４からMS１２へと変化し、一方でリモートシグナリングレッグはそのまま残る。必要な確認信号や追加のシグナリングが、新しいアクセスシグナリングパスと既存のリモートシグナリングパス上を通ってユーザー要素１６とリモートユーザー要素３６C間を流れ得る。CS１４を通るアクセスシグナリングレッグはその後、解放される。

同様に、この例において保留されているセッション１は、アクティブセッションであるセッション２の転送と同時、あるいはその後に転送される。そしてまた、InviteメッセージがMS１２を通ってCCF３０へ送られる。特に、セッション１用にMS１２を通って確立された新しいアクセスシグナリングレッグはセッション２のためのアクセスシグナリングレッグとは異なっている。ドメイン転送手順では、転出ドメインと転入ドメインとの間で、現在進行中のセッションのためのアクセスシグナリングレッグの対称を維持する。転出ドメインに２つのアクセスシグナリングレッグがある場合は、転入ドメインにも２つのアクセスシグナリングレッグがある。そのために、ユーザー要素１６から送られたInviteメッセージはセッション１に関わるアクセスシグナリングレッグ上でI/S-CSCF２８により受信される（ステップ１１４）。I/S-CSCF２８はInviteメッセージをCCF３０へ転送する（ステップ１１６）。Inviteメッセージは、おそらくSDP内に、セッションが保留されているという指示を含んでいても良い。そのために、CCF３０はセッションが保留されていると認識し、リモートユーザー要素３６Bに、対応するセッション１のためのリモートシグナリングレッグ上で更新させるかどうか判断しても良い。

セッション１が保留されているので、リモートユーザー要素３６Bをユーザー要素１６のドメイン内での変更に更新するのはすぐには必要でない可能性があるが、それはユーザー要素１６とリモートユーザー要素３６B間でアクティブメディアの交換が行われていないからである。しかしながら、そのような更新はセッション１がアクティブになる前か、そうでなければ再開される前に提供されなければならない。従って、ステップ１１８と１２０に関連する点線は、ドメイン転送があったことを示すことで、CCF３０がリモートユーザー要素３６Bを更新させることを反映している。この例では、SDPはセッションが保留されていることを示す。この時点では、セッション１は保留のままであり、セッション２はアクティブのままである。セッション２のベアラパスは、直接ユーザー要素１６とリモートユーザー要素３６C間を、MS１２を介して、あるいは関連するパケットネットワークを介して延びている（ステップ１２２）。これらドメイン転送中、通して、各々のセッションは、アクセスシグナリングパスとリモートシグナリングパスを含む独立したシグナリングパスを含む。転送を達成するために、転入ドメイン内に新しいシグナリングパスが提供され、転出ドメインからの古いアクセスシグナリングパスは解放される。CCF３０は、ある所定のセッション用の適切なアクセスシグナリングレッグとリモートシグナリングレッグを認識する情報を記憶し、セッション制御を容易にするために、そして重要なことはドメイン転送を通じて継続を維持するように、シグナリングメッセージが適切なアクセスシグナリングレッグとリモートシグナリングレッグ間を確実に通過する必要なステップを講じるようにしている。

次に、ユーザー要素１６に関連している利用者が、セッション１を再開し、セッション２を保留するための必要なステップを講じると仮定する（ステップ１２４）。それに応じて、ユーザー要素１６は、MS１２内のアクセスシグナリングパスでRe-InviteメッセージをI/S-CSCF２８を介してCCF３０へ送る（ステップ１２６から１２８）。Re-Inviteメッセージは、セッション又はセッションに関わるリモートパーティーを認識し（C）、セッション２が保留されているという指示を提供する。この例では、SDPはセッションが保留になっているという指示を出す。CCF３０は呼状態について記録し、セッションがユーザー要素１６によって保留されているということを示すためにRe-InviteメッセージをI/S-CSCF２８を通ってリモートユーザー要素３６Cへ転送しても良い（ステップ１３０と１３２）。適切な確認信号の後、ユーザー要素１６とリモートユーザー要素３６C間のセッション２が保留される。一方、ユーザー要素１６は、セッション１を再開するためにMS１２を介してRe-InviteメッセージをCCF３０へ送る（ステップ１３４と１３６）。Re-Inviteメッセージはセッション１又はリモートユーザー要素３６Bを認識し、ユーザー要素１６との通信に必要に応じてSDP（SDP−１UE）を提供する。SDPは、リモートユーザー要素３６Cとの通信用に使われたものと同じでも異なっていても良い。CCF３０はセッション状態について記憶し、I/S-CSCF２８を通ってRe-Inviteメッセージをリモートユーザー要素３６Bへ送ることにより、リモートユーザー要素３６Bを更新させる（ステップ１３８と１４０）。この時点で、セッション１はアクティブであり、CS14を通らずに、MS１２又は関連するパケットネットワークを通ってユーザー要素１６とリモートユーザー要素３６C間に延びているベアラパスによってサポートされている（ステップ１４２）。特に、セッション２に最初に割り当てられたリソースはセッション１が再開され、セッション２が保留される時に再利用され得る。

図７Aから７Cを参照すると、MS１２からCS１４へのドメイン転送を容易にするための例示的な通信フローが示されている。MS１２は転出ドメインを表し、CS１４は転入ドメインを表す。そしてまた、セッション１はユーザー要素１６（UE-A）とリモートユーザー要素３６B（UE-B）間で延びるセッションで、保留されていると仮定する。セッション２はアクティブで、ユーザー要素１６（UE-A）とリモートユーザー要素３６C（UE-C）間で延びている（ステップ２００）。しかしながら、これら両方のセッションは、CS１４を横断せず、直接MS１２又は、それに関するパケットネットワークを通るベアラパスをすでに有しているか、又は有することになる。そのために、アクティブセッション、すなわちセッション２、はMS１２を通って、ユーザー要素１６とリモートユーザー要素３６C間を延びるベアラパスを有している（ステップ２０２）。ユーザー要素１６がMS１２からCS１４へのドメイン転送の状態を検出すると（ステップ２０４）、ユーザー要素１６は、CS１４を介してユーザー要素１６からメディアゲートウェイ２６へのCSベアラ部分の確立を開始するように、VMSC２２へセットアップメッセージを送る（ステップ２０６）。セットアップメッセージはRUA３２Ｒに関連した電話登録番号（DN）に向けられても良く、DNがRUA３２Ｒに対してのPSIを表す。セットアップメッセージの受信を受け、VMSC２２は、メディアゲートウェイ２６を制御するメディアゲートウェイコントローラ２４へ、イニシャルアドレスメッセージ（IAM）を送る（ステップ２０８）。当業者には認識されることであるが、VMSC２２を通ってユーザー要素１６とメディアゲートウェイ２６間にCSベアラ部を確立するために、メディアゲートウェイコントローラ２４とVMSC２２は、様々な統合サービス網ユーザー部（ISUP）メッセージを交換する。メディアゲートウェイコントローラ２４は、I/S-CSCF２８を介してRUA３２Rへ対応するInviteメッセージをも送る（ステップ２１０と２１２）。InviteメッセージはRUA３２Rに関連したPSIに宛てられ、CSベアラ部分についてRUA３２Ｒに通知し、ユーザー要素１６がCS１４によって取り扱われている間、RUA３２Rがユーザー要素１６の代わりを行う準備をさせることを目的としている。

好ましくは、ユーザー要素１６はアクティブセッション、つまりセッション２の転送を最初に開始する。MS１２からCS１４への転送を開始するために、ユーザー要素１６はCCF３０へ送られるInviteメッセージを発生させ得る。先の通信フローのように、ユーザー要素１６はセッションに関する状態情報を追跡し、Inviteメッセージ内で転送中のセッションに対してのそのような状態情報を提供しても良い。Inviteメッセージは直接CS１４上でMS１２へ送れないので、InviteメッセージあるいはInviteメッセージの情報はCS１４上でRUA３２Rへ送られなければならない。この例では、従来CS１４内で使われていたCSシグナリングは、InviteメッセージをVMSC２２へ運ぶのに使われ（ステップ２１４）、VMSC２２はInviteメッセージあるいはInviteメッセージの情報とさらなるCSシグナリングをCAAF３２Cへ転送する（ステップ２１６）。CAAF３２Cは、CSシグナリングからInviteメッセージまたはInviteメッセージの情報を抽出でき、MS１２へ送るためにInviteメッセージを提供するためにRUA３２Rと協力する（ステップ２１８）。この例では、VMSC２２を介してユーザー要素１６とCAAF３２Ｃ間で非構造化付加サービスデータ（USSD）シグナリングチャンネルが利用できる。USSDメッセージはシグナリングエンベロープを含んでいても良く、このエンベロープの中で、InviteメッセージあるいはInviteメッセージの情報は、ユーザー要素１６からCAAF３２Ｃへ運ばれる。特に、ユーザー要素１６がCS１４によって取り扱われている間、ユーザー要素１６とCAAF３２C間を様々なシグナリング情報を運ぶのに様々なエンベロープが使われ得る。

図解されているように、CAAF３２CとRUA３２Rは単独で、あるいは一緒に、CS１４内のセッション２用に使用するCSベアラ部分がメディアゲートウェイ２６を通過することを認識する。RUA３２RはMS１２内のユーザー要素１６の代わりに動作するので、I/S-CSCF２８を通ってCCF３０へ送られる、対応するInviteメッセージ内のメディアゲートウェイ２６（SDP-２MG）に対してのSDPを送らなければならない（ステップ２２０と２２２）。
セッション２のベアラパスのためのパケットベアラ部分がメディアゲートウェイ２６とリモートユーザー要素３６C間で延びているので、リモートユーザー要素３６Cはメディアゲートウェイ２６用にSDPが必要である。そのように、リモートユーザー要素３６Cからユーザー要素１６へ送られたパケットはメディアゲートウェイ２６により受信され、メディアゲートウェイ２６はパケットを、CSベアラ部分上を送るための適切なCSフォーマットへ変換する。逆方向では、メディアゲートウェイ２６でユーザー要素１６から受信された、CSフォーマットされた情報は、リモートユーザー要素３６Cへ送られるパケット情報に変換される。

いったんCCF３０がI/S-CSCF２８を介してRUA３２RからInviteメッセージを受け取ると、Inviteメッセージは処理され、新しいアクセスシグナリングレッグ情報がCCF３０で更新される。CCF３０は、リモートユーザー要素３６Cは更新を提供するために、Re-InviteメッセージをI/S-CSCF２８を通ってリモートシグナリングレッグを介してリモートユーザー要素３６Cへ送る（ステップ２２４と２２６）。更新は、事実上、リモートユーザー要素３６Cに、ユーザー要素１６と直接通信する代わりに、メディアゲートウェイ２６を介してユーザー要素１６と通信するよう伝える。この時点で、CSベアラ部分が確立され、セッション２はMS１２からCS１４へ転送されている。一方、ユーザー要素１６は、MS１２からCS１４へのセッション１の転送を開始する。上に述べたのと同様な方法で、ユーザー要素１６はInviteメッセージ、あるいはInviteメッセージの情報をCSシグナリングのエンベロープ内でVMSC２２に提供し（ステップ２２８）、VMSC２２は、Inviteメッセージ、又はInviteメッセージに関連した情報を、CSシグナリングを使ってCAAF３２Cへ転送する（ステップ２３０）。CAAF３２CとRUA３２RはInviteメッセージ、あるいはInviteメッセージに関連した情報を処理し（ステップ２３２）、I/S-CSCF２８を介してCCF３０へ送るためのInviteメッセージを発生させる（ステップ２３４と２３６）。

特に、ユーザー要素１６により提供されたInviteメッセージは、セッション１が保留されており、セッション２で使用されたものとは実質上別個のアクセスシグナリングパスを通じて送られることを示す。特に、同じUSSDシグナリングチャンネルが使用されても良く、しかしInviteメッセージはセッション１（PSIA-B)を別個に認識し、セッション２と関連したシグナリングとは別に、CAAF３２CとRUA３２Rによって処理される。CAAF３２CあるいはRUA３２Rから提供されたInviteメッセージは、保留中のセッションを示すSDPを含む。

前述の通信フローのように、CCF３０は、必ずしもセッション１のInviteメッセージの受信直後にリモートユーザー要素３６Bを更新する必要はない。しかしながら、セッション１が再開される前に、CCF３０はリモートユーザー要素３６Bを更新して、これによりリモートユーザー要素３６Bはドメイン転送が行われたことを認識し、或いは少なくとも直接ユーザー要素１６と通信する代わりにメディアゲートウェイ２６を介してユーザー要素１６と通信する必要があることを認識する必要がある。図解されているように、セッションが保留されているということを示すために、CCF３０は、Inviteメッセージを、セッション１のリモートシグナリングレッグ上でI/S-CSCF２８を通ってリモートユーザー要素３６Bへ送ることによって、比較的即時の更新を行っている（ステップ２３８と２４０）。セッションが保留されていても、セッションを維持するために帯域内の通信が必要とされる場合は、Inviteメッセージはメディアゲートウェイ２６を、通信の新しい目的地として認識し得る。

この時点で、セッション１とセッション２の両方はMS１２からCS１４へ転送されている。さらに、リモートユーザー要素３６Bを使ったセッション１は保留されたままで、一方リモートユーザー要素３６Cを使ったセッション２はアクティブのままになっている。セッション２のベアラパスはユーザー要素１６とリモートユーザー要素３６C間をVMSC２２とメディアゲートウェイ２６を介して延びている（ステップ２４２）。CSベアラ部分はVMSC２２を通って、ユーザー要素１６とメディアゲートウェイ２６間を延びていて、一方MSベアラ部分はMS１２又は関連するパケットネットワークを介し、メディアゲートウェイ２６とリモートユーザー要素３６C間を延びている。

次に、ユーザー要素１６がセッション１を再開し、セッション２を保留するのに必要な動作を行うと仮定する（ステップ２４４）。それに応じて、ユーザー要素１６は、リモートユーザー要素３６Cに向けてセッションが保留されていることを示すRe-Inviteメッセージを発生させる。Re-InviteメッセージはCSシグナリングのエンベロープの中に置かれ、VMSC２２に提供される（ステップ２４６）。VMSC２２はCSシグナリング内のRe-InviteメッセージをCAAF３２Cへ転送する（ステップ２４８）。そしてまた、CAAF３２CとRUA３２Rは協力してCSシグナリングからRe-Inviteメッセージを抽出し（ステップ２５０）、リモートユーザー要素３６Cを対象としており、セッション２が保留されていることを示すためのSDPを提供する、適切なRe-Inviteメッセージを発生させる。RUA３２Rは、Re-InviteメッセージをI/S-CSCF２８を介してCCF３０へ送る（ステップ２５２と２５４）。CCF３０はセッション２のアクセスシグナリングレッグを介してRe-Inviteメッセージを受信し、Re-Inviteメッセージを、セッション２用のリモートシグナリングレッグを介してI/S-CSCF２８を通ってリモートユーザー要素３６Cへ転送する（ステップ２５６と２５８）。ここでセッション２は保留中となる。

ユーザー要素１６とリモートユーザー要素３６B間でセッション１をアクティブにするために、ユーザー要素１６はリモートユーザー要素３６Bへ送られるRe-Inviteメッセージを発生させるが、Re-Inviteメッセージは現在保留されているセッション１をアクティブにするよう構成されている。Re-InviteメッセージはVMSC２２までCSシグナリングによって運ばれ（ステップ２６０）、VMSC２２はCSシグナリングを介してRe-InviteメッセージをCAAF３２Cへ送る（ステップ２６２）。そしてまた、CAAF３２CとRUA３２Rは協力してCSシグナリングからRe-Inviteメッセージを抽出し（ステップ２６４）、I/S-CSCF２８を介してCCF３０へ送るためにRe-Inviteメッセージを提示する（ステップ２６６と２６８）。特に、リモートユーザー要素３６Bは、ここでユーザー要素１６と直接に通信する代わりにメディアゲートウェイ２６と通信する必要となるため、RUA３２Rはメディアゲートウェイ２６をセッション１用に使うためにSDP（SDP−１MG）を含むためのRe-Inviteメッセージを発生させる。CCF３０は、Re-Inviteメッセージを、セッション１のリモートシグナリングレッグを介してI/S-CSCF２８を通って、リモートユーザー要素３６Bに送ることによって、リモートユーザー要素３６Bを更新させる（ステップ２７０と２７２）。この時点で、セッション１はアクティブであり、セッション１のベアラパスは、VMSC２２とメディアゲートウェイ２６を介してユーザー要素１６とリモートユーザー要素３６B間で延びている（ステップ２７４）。CSベアラ部分はセッション２用に使われた同じCSベアラ部分でも良く、VMSC２２を介してユーザー要素１６とメディアゲートウェイ２６間を延びている。セッション１のMSベアラ部分は、セッション２のMSベアラ部分と異なっていても良く、メディアゲートウェイ２６とリモートユーザー要素３６B間を直接延びていても良い。このように、メディアゲートウェイ２６は、ユーザー要素１６がリモートユーザー要素３６Bと３６Cとのセッションに係属している時、CS１４を介してユーザー要素１６との単数のCSベアラ部分を用いながら複数リモートユーザー要素３６B、３６Cとの複数のMSベアラ部分の経過を追っても良い。

上述の実施形態では、CAAF３２CがRUA３２Rと関連付けられ、CS１４とMS１２間のシグナリングゲートウェイとして使われている。図８と９で図解されている実施形態では、移動体通信用グローバルシステム（GSM（登録商標））ネットワークで提供されている、パケット方式の無線通信サービスである汎用パケット無線システム（GPRS）内で用いられている環境のような、回線交換ネットワーク上でパケット方式の通信がCS１４により、サポートされている環境ではCAAF３２Cは用いられない。これらの例では、ユーザー要素１６は、CS１４を介してサポートされている時でも、ユーザー要素１６は、直接的にMS１２を対象とした、あるいはMS１２から受信されたセッションシグナリングのために、GPRSなどの伝送を使用し得しても良い。図８に図解されているように、セッション１とセッション２のアクセスシグナリングレッグは、VMSC２２、RUA３２R、I/S-CSCF２８を介してユーザー要素１６のCSクライアント１８とCCF３０間を延びている。セッション１とセッション２のリモートシグナリングレッグは上述の通りである。CCF３０は、ユーザー要素１６とリモートユーザー要素３６Bと３６Cとのの間のセッション制御を容易にするためにセッション１とセッション２のそれぞれのアクセスとリモートシグナリングレッグをアンカーし、そして関連付けている。図９を参照すると、ユーザー要素１６がMS１２などのパケットネットワークによってサポートされている時の、セッション１とセッション２のアクセスとリモートシグナリングレッグが図解されている。

CS１４とMS１２間の転送は、有効に、転出ドメインから転入ドメインへ、それぞれのセッションのベアラパスとシグナリングパスを変更する。このように、CS１４からMS１２への転送は、図８に示されているものから図９に示されているものへのベアラパスとシグナリングパスの変更を実行する。MS１２からCS１４への転送の場合、ベアラパスとシグナリングパスは図９に示されているものから図８に示されているものへ変更する。２つのセッションしか図示されていないが、ユーザー要素１６と関連するネットワーク用に利用できるリソースに基づいて、いくつのセッションでもサポートされ得る。

図１０Aから１０Cに例が図解されているが、ユーザー要素１６（UE-A）が２つのセッションに係属している。セッション１はリモートユーザー要素３６B（UE-B）とのもので、保留されており、一方セッション２はリモートユーザー要素３６C（UE-C）とのもので、アクティブである。さらに、セッション１とセッション２の両方がMS１２を介してサポートされており、このため、図９に示されているように、これらのセッションのベアラパスやシグナリングパスのどちらも、CS１４を通って延びていないと仮定する。この例では、ユーザー要素１６はMS１２からCS１４へのドメイン転送を必要とする条件を検出し、MS１２からCS１４へのドメイン転送を開始する。MS１２は転出ドメインで、CS１４は転入ドメインである。

最初にユーザー要素１６は、リモートユーザー要素３６Bとともに保留されているセッション１に参加し、それからリモートユーザー要素３６Cとともにアクティブであるセッション２に参加する（ステップ３００）。セッション２のベアラパスは、CS１４を横断せずにユーザー要素１６とリモートユーザー要素３６C間を直接延びる（ステップ３０２）。ある時点で、ユーザー要素１６は、MS１２からCS１４へのドメイン転送を必要とする条件を検出する（ステップ３０４）。その結果、ユーザー要素１６は、CSベアラ部分と、VMSC２２を通ってRUA３２Rとの、関連するコントロールパスの確立のために必要なステップを踏むことによって、CS１４へのドメイン転送を開始する。特に、ユーザー要素１６は、CSベアラ部分を要求するためのセットアップメッセージをVMSC２２へ送る（ステップ３０６）。セットアップメッセージは、RUA３２Rに関する電話登録番号（PSI）を含んでいても良い。VMSC２２はメディアゲートウェイ２６に関するメディアゲートウェイコントローラ２４へIAMを送る（ステップ３０８）。CSベアラ部分は、VMSC２２を介して、ユーザー要素１６とメディアゲートウェイ２６間に確立される。メディアゲートウェイコントローラ２４はCSベアラ部分のRUA３２Rにも通知を発して、I/S-CSCF２８を介してRUA３２RへInviteメッセージを送ることにより、CSベアラ部分に対し制御パスを確立する（ステップ３１０と３１２）。Inviteメッセージは、RUA３２RのPSIを認識し、InviteメッセージがI/S-CSCF２８を介してRUA３２Rを経由できるようになる。この時点で、メディアゲートウェイ２６とユーザー要素１６間のCSベアラ部分は確立され、関連する制御パスはRUA３２Rを通して設定される。

次に、ユーザー要素１６は、先ずInviteメッセージをセッション２に関するPSIを使ってGPRS伝送上でCCF３０へ送ることによって、アクティブセッションであるセッション２のドメイン転送を開始する。GPRS伝送が用いられているので、InviteメッセージはCAAF３２Cを横断せず、直接I/S-CSCF２８へ送られても良い。従って、InviteメッセージはI/S-CSCF２８へ送られ（ステップ３１４）、I/S-CSCF２８はInviteメッセージをRUA３２Rへ転送し（ステップ３１６）、ユーザー要素１６がCS１４によってサポートされている間、RUA３２Rはユーザー要素１６のリモートユーザーエージェントの役割を果たす。RUA32Rは、CSベアラ部分がメディアゲートウェイ２６でアンカーされているということを認識し、ユーザー要素１６の代わりの役割を果たしメディアゲートウェイ２６のSDP（SDPMG）を含むCCF３０へ送るためのInviteメッセージを発生させる。メディアゲートウェイ２６のSDPは、リモートユーザー要素３６Cがメディアゲートウェイ２６と通信する時に使うために必要な通信パラメータを含む。RUA３２Rは、メディアゲートウェイ２６のために、SDPを含むInviteメッセージを発生させ、Inviteメッセージを、セッション２のPSIを使ってI/S-CSCF２８を通り、CCF30へ転送する（ステップ３１８と３２０）。ユーザー要素１６によって提供されたInviteメッセージは、セッション２がMS１２内でサポートされる間のセッション２に関する状態情報を含んでいても良い。CCF３０は状態情報の経過を追跡しても良く、またリモートユーザー要素３６Cへ状態情報を転送しても良い。CCF３０は、Re-Inviteメッセージをセッション２のリモートシグナリングレッグを介してI/S-CSCF２８を通ってリモートユーザー要素３６Cへ送る（ステップ３２２と３２４）。Re-Inviteメッセージは、ユーザー要素１６によってリモートユーザー要素３６Cへ最初に提供された必要な状態情報とともに、メディアゲートウェイ２６のSDPを含む。任意の確認信号や後に続くセッションシグナリングは、CS１４とセッション１のリモートアクセスレッグを通って新しいアクセスシグナリングレッグによって提供されるシグナリングパス上で提供される。

一方で、ユーザー要素１６はMS１２からCS１４へのセッション１の転送を開始する。そのために、ユーザー要素１６はセッション１用に必要な状態情報を含むInviteメッセージを発生させ、Inviteメッセージを、セッション１と関わっているPSIを使ってMS１２内へ送る（ステップ３２６）。この例の状態情報は、セッション１が、保留状態を示すSDPを提供することにより、保留されていることを示しても良い。InviteメッセージはMS１２内でI/S-CSCF２８において受信され、RUA３２Rに転送され、RUA３２Rは、ユーザー要素１６がCSによって取り扱われている間にユーザー要素１６の代わりの役割を果たしている（ステップ３２８）。RUA３２RはInviteメッセージをI/S-CSCF２８を介してCCF３０へ転送する（ステップ３３０と３３２）。CCF３０はセッション１の状態情報を更新し、リモートシグナリングレッグ上でI/S-CSCF２８を通ってリモートユーザー要素３６BへのRe-Inviteを開始しても良い（ステップ３３４と３３６）。リモートユーザー要素３６Bは、直接ユーザー要素１６と通信する代わりに、セッション２のベアラパス上でメディアゲートウェイ２６と通信するように、Re-Inviteメッセージはセッションが保留のままになっていることを示すSDPを含んでも良く、もし保留セッション用に帯域内シグナリングが必要とされるなら、メディアゲートウェイ２６のSDPを含んでも良い。

この時点で、セッション２はアクティブであり、セッション２のベアラパスはCS１４を介してユーザー要素１６へ延びる（ステップ３３８）。特に、ベアラパスのCSベアラ部分はVMSC２２を介してユーザー要素１６とメディアゲートウェイ２６間を延び、一方でベアラパスのMS部分はメディアゲートウェイ２６とリモートユーザー要素３６C間を延びる。セッション１は保留のままである。

上の例のように、ユーザー要素１６に関連する利用者がセッション１を再開し、セッション２を保留することにしたと仮定する（ステップ３４０）。この時点で、セッション１とセッション２の両方はCS１４を介してサポートされ、このため、ユーザー要素１６はリモートユーザー要素３６C用にRe-Inviteメッセージを開始し、Re-Inviteメッセージはセッション２を保留させる指示を提供する。この例では、保留指示は、セッションが保留されていることを示すSDPを送ることにより提供される。Re-InviteメッセージはGPRS伝送を使って直接MS１２へ送られ、I/S-CSCF２８により受信される（ステップ３４２）。Re-InviteメッセージはRUA３２Rへ送られ（ステップ３４４）、ユーザー要素１６の代わりにその役割を果たすRUA３２Rは、Re-InviteメッセージをI/S-CSCF２８を介してCCF３０へ転送する（ステップ３４６と３４８）。CCF３０はセッション２の状態情報を更新し、Re-Inviteメッセージを、I/S-CSCF２８を通ってリモートシグナリングレッグ上でリモートユーザー要素３６Cへ送る（ステップ３５０と３５２）。Re-Inviteメッセージはセッション２が保留されていることを示すSDPを含む。

次に、ユーザー要素１６はリモートユーザー要素３６Bとのセッション１を再開する。それをするために、ユーザー要素１６はリモートユーザー要素３６Bを対象としたRe-Inviteメッセージを、セッション１のアクセスシグナリングレッグ上でGPRS伝送を使用してMS１２へ送る（ステップ３５４）。I/S-CSCF２８はRe-InviteメッセージをRUA３２Rへ転送し（ステップ３５６）、ユーザー要素１６の代わりにその役割を果たすRUA３２Rは、Re-InviteメッセージをI/S-CSCF２８を介してCCF３０へ転送する（ステップ３５８と３６０）。CCF３０は、ユーザー要素１６から提供される状態情報に基づいて関連するいかなる状態情報をも更新し、I/S-CSCF２８を通ってセッション１のリモートシグナリングレッグを介してリモートユーザー要素３６BへのRe-Inviteメッセージを開始する（ステップ３６２と３６４）。RUA３２Rによって開始されたRe-Inviteメッセージは、そのような情報がまだ提供されてない場合はメディアゲートウェイ２６のSDPを含んでいても良い。リモートユーザー要素３６BはRe-Inviteメッセージを、セッション１を開始せよとの指示として認識し、セッション１のベアラパスがメディアゲートウェイ２６を通過すると認識する。この時点でベアラパスは、VMSC２２とメディアゲートウェイ２６を通ってユーザー要素１６とリモートユーザー要素３６B間を延びる（ステップ３６６）。CSベアラ部分は、VMSC２２を通ってメディアゲートウェイ２６とユーザー要素１６間を延び、一方でベアラパスのMS部分はメディアゲートウェイ２６とリモートユーザー要素３６B間を延びる。ここでセッション１はアクティブで、セッション２は保留されている。

この実施態様の場合、プロセスは図６Aと６Bに関連して提供されているものと実質的に同じである。要するに、アクセスシグナリングパスがCS１４の外へ移行され、RUA３２Rを用いずにI/S-CSCF２８を介してCCF３０に直接入るため、MS１２へ転送する場合に、CAAF３２の除去とGPRS伝送等の使用はほとんど重要性をもたない。

以上の実施例では、現在ユーザー要素１６によってサポートされている複数セッションの中の一つが保留状態を維持される。しかしながら、当業者には理解されることであるが、複数のセッションが一つのドメインから他のドメインへ移行され得て、複数セッションの各々がアクティブでありドメイン転送の間、アクティブのままとなる。一つまたはそれ以上のセッションが保留されるという例は、セッションが音声セッションであり、任意の所定の時に複数のアクティブ音声セッションを有することを避けるためにしかるべく処理されるという、より複雑なシナリオを単に表しているに過ぎない。複数セッションがアクティブで、ユーザー要素１６がCS１４によりサポートされている時、CS１４を通る複数のCSベアラ部分は、各々のセッションが対応するCSベアラ部分を有するように提供されても良い。あるいは、単数のCSベアラ部分が複数アクティブセッションに共有されても良い。

図１１を参照すると、サービスノード４４は、本発明の一実施形態に従って提供されている。サービスノード４４はMS１２内に存在していても良く、CCF３０、I/S-CSCF２８、CAAF３２C、RUA３２Rの群から選ばれた任意の一つ、あるいは組み合わせに機能性を与えるために、制御システム４６と、関連するメモリ４８を含む。制御システム４６は、MS１２と連携しているエンティティや、関連するネットワークとの通信を容易にするために通信インターフェース５０とも関連する。

図１２を参照すると、ユーザー要素１６のブロック図が示されている。ユーザー要素１６は、CSクライアント１８とMSクライアント２０の動作をサポートするのに十分なメモリ５４を有する制御システム５２を含んでいても良い。制御システム５２は、上に説明されているように、CSクライアント１８とMSクライアント２０がCS１４とMS１２上で容易に通信できるように通信インターフェース５６と密接に協力する。制御システム５２は、ユーザーとの相互対話を促進するユーザーインターフェース５８と関連し得る。ユーザーインターフェース５８は、ユーザーとの音声通信を容易にするマイクとスピーカーと、ユーザーに情報を入力して見ることができるようなキーパッドと画面をも含んでいても良い。

本技術に係る技術者は、本発明の好ましい実施形態への改良や修正を認識するであろう。そのような改良や修正の全ては、本明細書と以下に続く特許請求に開示される概念の範囲内であると見なされる。

Claims (22)

1. 複数セッションに同時に係属しているユーザー要素用のドメイン転送を容易にする方法であって、
   対応する複数セッションに対し複数のセッションシグナリングパスを提供することと、
   前記複数のセッションシグナリングパスの各々が、対応する前記複数セッションのうちの一つのための第１のアクセスシグナリングレッグとリモートシグナリングレッグを含み、
   前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグがマルチメディアサブシステム内にある制御機能でアンカーされ、転出ドメインを介して第１のユーザー要素へ延びていることを特徴とするものであって、
   前記複数セッションの各々に対して、
   前記制御機能でアンカーされ、転入ドメインを介して前記第１のユーザー要素へ延びている第２のアクセスシグナリングレッグを提供することと、
   前記第１のアクセスシグナリングレッグを前記第２のアクセスシグナリングレッグと置換することと、
   前記第１のユーザー要素が前記転入ドメインによって取り扱われている間に、前記第１のユーザー要素用のセッションシグナリングを容易にするために更新されたセッションシグナリングパスを提供するために、前記第２のアクセスシグナリングレッグと前記リモートシグナリングレッグ間のセッションシグナリングを回線交換することと
   を含み、
   前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの一方が、前記第１のユーザー要素が回線交換サブシステムによって取り扱われている時に、前記マルチメディアサブシステムに対して自身を前記第１のユーザー要素として表しているリモートユーザーエージェントを通って前記回線交換サブシステムへ延びており、
   回線交換サブシステムアクセス適応機能は、前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの前記一方とともに、前記第１のユーザー要素を取り扱う移動交換局と前記リモートユーザーエージェントとの間に存在し、前記回線交換サブシステムアクセス適応機能は回線交換サブシステムとマルチメディアサブシステムとの間のシグナリング変換を提供し、
   前記マルチメディアサブシステムで使用するためのセッションシグナリングメッセージは、前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの前記一方を介して前記回線交換サブシステムによって提供されるパケット伝送方式によって伝えられることを特徴とする方法。
2. 前記複数セッションの各々に対し、前記第１のユーザー要素と接続しているベアラパスの少なくとも一部分を、前記転出ドメインと関連している第１のネットワークから、前記転入ドメインと関連している第２のネットワークへ転送することを遂行することをさらに含む、請求項１に記載の前記方法。
3. 前記第１のユーザー要素から前記転入ドメインを介してドメイン転送用の要求を受信することと、
   前記要求を受信することに応じて、前記複数セッションの各々のために前記第２のアクセスシグナリングレッグを提供することをさらに含む、請求項１に記載の前記方法。
4. 前記第１のユーザー要素が前記転出ドメインから前記転入ドメインへ前記複数セッションを転送する必要を判断した時に、前記第１のユーザー要素から前記要求が発生されることを特徴とする、請求項３に記載の前記方法。
5. 前記要求は、前記制御機能用のマルチメディアサブシステムアドレスと、前記マルチメディアサブシステムアドレスと関連している回線交換サブシステム内の電話登録番号とのうちの少なくとも一方を使って前記第１のユーザー要素から発せられることを特徴とする、請求項３に記載の前記方法。
6. 前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの他方が、前記回線交換サブシステムと横断せずに前記第１のユーザー要素へ延びていることを特徴とする、請求項１に記載の前記方法。
7. 前記マルチメディアサブシステムで使用するためのセッションシグナリングメッセージは、回線交換サブシステムシグナリングによって、前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの前記一方を介して前記回線交換サブシステムアクセス適応機能へ運ばれることを特徴とする、請求項１に記載の前記方法。
8. 前記回線交換サブシステムシグナリングは、少なくとも部分的に、非構造化付加サービスデータチャンネル内で提供されることを特徴とする、請求項７に記載の前記方法。
9. 前記パケット伝送方式は、移動体通信用グローバルシステムネットワーク内の汎用パケット無線システムであることを特徴とする、請求項１に記載の前記方法。
10. 前記複数セッションのアクティブセッションと保留セッションとは音声セッションであり、前記アクティブセッションの転送は、前記保留セッションの前記転入ドメインへの転送の開始前に開始されることを特徴とする、請求項１に記載の前記方法。
11. 前記転入ドメインと前記転出ドメインとのうちの一方は、前記マルチメディアサブシステムであり、前記転入ドメインと前記転出ドメインのうちの他方は回線交換サブシステムであることを特徴とする、請求項１に記載の前記方法。
12. 前記転入ドメインと前記転出ドメインのうちの前記一方へのアクセスは、前記回線交換サブシステムの外の無線アクセスを介して提供されることを特徴とする、請求項１１に記載の前記方法。
13. 前記無線アクセスはパケット方式の通信をサポートし、前記回線交換サブシステムは回線交換通信をサポートすることを特徴とする、請求項１２に記載の前記方法。
14. 前記回線交換サブシステムは、セルラーネットワークによって提供されることを特徴とする、請求項１１に記載の前記方法。
15. 前記複数セッションは、対応する複数の特定のベアラパスに関連していることを特徴とする、請求項１に記載の前記方法。
16. マルチメディアサブシステムによってサポートされている前記複数の特定のベアラパスの第１の部分は、前記マルチメディアサブシステム内でお互いに分離されていることを特徴とする、請求項１５に記載の前記方法。
17. 前記複数セッションが少なくとも部分的に回線交換サブシステムによってサポートされる時、
    前記複数セッションの各々のための前記特定のベアラパスは、前記回線交換サブシステムを通って前記第１のユーザー要素へ延びている共通の回線交換ベアラ部分によってサポートされていることを特徴とする、請求項１６に記載の前記方法。
18. 前記複数セッションの各々は、前記第１のユーザー要素と複数のリモートエンドポイントの異なるものとの間に接続されていることを特徴とする、請求項１に記載の前記方法。
19. 前記複数セッションのうちの一つが前記第１のユーザー要素から発生される時、前記制御機能以外の複数のサービスの全てが前記リモートシグナリングレッグ内に提供されるように、および前記リモートシグナリングレッグが前記制御機能でアンカーされるように、前記制御機能は、前記第１のアクセスシグナリングレッグと前記リモートシグナリングレッグによって形成される前記複数のセッションシグナリングパスのうちの一つの中に提供される複数のサービスのうちの最初のサービスとして呼び出されることを特徴とする、請求項１に記載の前記方法。
20. 前記複数セッションのうちの一つが前記第１のユーザー要素において終了される時、前記制御機能以外の複数のサービスの全てがリモートシグナリングレッグ内に提供されるように、および前記リモートシグナリングレッグが前記制御機能でアンカーされるように、前記制御機能は、前記第１のアクセスシグナリングレッグと前記リモートシグナリングレッグによって形成される前記複数のセッションシグナリングパスのうちの一つの中に提供される複数のサービスのうちの最後のサービスとして呼び出されることを特徴とする、請求項１に記載の前記方法。
21. 前記制御機能は、前記第１のユーザー要素から、あるいは前記第１のユーザー要素を対象としたセッション用のサービング呼セッション制御機能によってサービスとして呼び出されることを特徴とする、請求項１に記載の前記方法。
22. 複数セッションに同時に係属しているユーザー要素用のドメイン転送を容易にする方法であって、
    マルチメディアサブシステム内に存在する制御機能で、対応する複数セッションに対し複数のセッションシグナリングパスの各々のための第１のアクセスシグナリングレッグをアンカーすることと、
    前記複数のセッションシグナリングパスの各々は、対応する前記複数セッションのうちの一つのための前記第１のアクセスシグナリングレッグとリモートシグナリングレッグを備えることを特徴とし、
    前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグが、転出ドメインを介して第１のユーザー要素へ延びていることを特徴とするものであって、
    前記複数セッションの各々に対して、
    転入ドメインを介して前記第１のユーザー要素へ延びている第２のアクセスシグナリングレッグを前記制御機能でアンカーすることと、
    前記第１のアクセスシグナリングレッグを前記第２のアクセスシグナリングレッグと置換することと、
    前記第１のユーザー要素が前記転入ドメインによって取り扱われている間に、前記第１のユーザー要素用のセッションシグナリングを容易にするために更新されたセッションシグナリングパスを提供するために、前記第２のアクセスシグナリングレッグと前記リモートシグナリングレッグ間のセッションシグナリングを回線交換することと
    を含み、
    前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの一方が、前記第１のユーザー要素が回線交換サブシステムによって取り扱われている時に、前記マルチメディアサブシステムに対して自身を前記第１のユーザー要素として表しているリモートユーザーエージェントを通って前記回線交換サブシステムへ延びており、
    回線交換サブシステムアクセス適応機能は、前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの前記一方とともに、前記第１のユーザー要素を取り扱う移動交換局と前記リモートユーザーエージェントとの間に存在し、前記回線交換サブシステムアクセス適応機能は回線交換サブシステムとマルチメディアサブシステムとの間のシグナリング変換を提供し、
    前記マルチメディアサブシステムで使用するためのセッションシグナリングメッセージは、前記複数のセッションシグナリングパスの各々のための前記第１のアクセスシグナリングレッグと前記第２のアクセスシグナリングレッグとのうちの前記一方を介して前記回線交換サブシステムによって提供されるパケット伝送方式によって伝えられることを特徴とする方法。

Images