(57)【要約】【課題】ネットワーク環境で、コール連続性を管理するスキームを提供すること。【解決手段】一つの実施形態において、ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）を含むネットワーク環境（１００）において、コール連続性を管理するスキームが、開示される。ここで、ルーティング可能な番号の戻りをトリガして動作可能であるリクエストＵＲＩに含まれるドメイン転送ＵＲＩを有するＳＩＰインバイトメッセージが、利用される。ＵＥデバイス（３０２）のＳＩＰインバイトメッセージに応答して、ネットワークノード（３０８）は、ＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答）を提供する。このＳＩＰ応答メッセージは、１つ以上の無線アクセス技術と、一つのドメインから他のドメインへのコールを連続させるために、このＵＥデバイス（３０２）で利用可能な代替ドメインとを含む。【選択図】図１
2008092579.tif 000002
【特許請求の範囲】
【請求項１】
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）において、コールと関連するユーザ装備（ＵＥ）デバイス（３０２）で動作可能な方法であって、該コールは、コールされたパーティに向けて発信され、該方法は、
セッション開始プロトコル（ＳＩＰ）インバイトメッセージ（３１２、３５６）を介して、該ＵＥデバイス（３０２）による該コールと関連するコール情報を、該ＩＭＳネットワーク（３５０）内に配置されたネットワークノード（３０８）に提供すること（２２２）であって、該ＳＩＰインバイトメッセージ（３１２、３５６）は、コール連続性のための呼び出しとして動作可能なユニフォームリソース識別子（ＵＲＩ）を含む、提供すること（２２２）と、
ＳＩＰ応答メッセージ（３１６、３６４／３６６）を介して該ネットワークノード（３０８）から、ルーティング可能な番号を受信することに応答して、該コールと関連するコールリファレンス番号が有効であることを確認すること（２２４）と、
該確認（２２４）後に、コール連続性を実行するために、該ＵＥデバイス（３０２）によって、該ネットワークノード（３０８）に該ルーティング可能な番号を提供すること（２２６）と
を包含する、方法。
【請求項２】
前記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、ＳＩＰ３８０（代替サービス）応答を備え、該ＳＩＰ３８０応答は、無線アクセス技術のリストをさらに含む、請求項１に記載の方法。
【請求項３】
前記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、前記コールを連続させるために、前記ＵＥデバイス（３０２）に利用可能な代替ドメインをさらに含む、請求項１に記載の方法。
【請求項４】
前記代替ドメインは、パケット交換（ＰＳ）ネットワークドメインと回路交換（ＣＳ）ネットワークドメインとのうちの一つを備える、請求項３に記載の方法。
【請求項５】
前記ルーティング可能な番号は、ＶＣＣドメイン転送番号（ＶＤＮ）とＩＰマルチメディアルーティング番号（ＩＭＲＮ）とのうちの一つを備える、請求項１に記載の方法。
【請求項６】
前記コールが、第一のドメインから第二のドメインに連続されるべきであると決定されると、前記ＳＩＰインバイトメッセージ（３１２、３５６）は、前記ＵＥデバイス（３０２）によって提供される、請求項１に記載の方法。
【請求項７】
前記ＵＲＩは、前記ＵＥデバイス（３０２）と関連する取り外し可能なストレージモジュールに、ローカルに格納される、請求項１に記載の方法。
【請求項８】
前記ＵＲＩは、前記ＵＥデバイス（３０２）内に集積されたメモリ回路に、ローカルに格納される、請求項１に記載の方法。
【請求項９】
前記ＵＲＩは、前記ＩＭＳネットワーク（３５０）によって前記ＵＥデバイス（３０２）に動的に割り当てられている、請求項１に記載の方法。
【請求項１０】
前記ＵＲＩは、ＳＩＰヘッダまたはＳＩＰメッセージのボディのうちの一つを提供される、請求項９に記載の方法。
【請求項１１】
前記ＵＲＩは、前記ＵＥデバイス（３０２）と関連するユーザＩＤパラメータに基づいて、該ＵＥデバイス（３０２）によって、生成される、請求項１に記載の方法。
【請求項１２】
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）において、コールを発信するように動作可能であるユーザ装備（ＵＥ）デバイス（３０２）であって、該コールは、コールされたパーティに向けて導かれ、該ＵＥデバイス（３０２）は、
セッション開始プロトコル（ＳＩＰ）インバイトメッセージ（３１２、３５６）を介して、該コールと関連するコール情報を、該ＩＭＳネットワーク（３５０）内に配置されたネットワークノード（３０８）に提供する（２２２）手段であって、該ＳＩＰインバイトメッセージ（３１２、３５６）は、コール連続性のための呼び出しとして動作可能なユニフォームリソース識別子（ＵＲＩ）を含む、提供する（２２２）手段と、
ＳＩＰ応答メッセージ（３１６、３６４／３６６）を介して、該ネットワークノード（３０８）から、ルーティング可能な番号を受信したことに応答して動作可能であり、該コールと関連するコールリファレンス番号が有効であることを確認する（２２４）手段と、
該確認（２２４）に応答して動作可能で、コール連続性を実行するために、該ＵＥデバイス（３０２）によって、該ネットワークノード（３０８）に、該ルーティング可能な番号を提供する（２２６）手段と
を備える、ＵＥデバイス（３０２）。
【請求項１３】
前記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、ＳＩＰ３８０（代替サービス）応答を備え、該ＳＩＰ３８０応答は、無線アクセス技術のリストをさらに含む、請求項１２に記載のＵＥデバイス（３０２）。
【請求項１４】
前記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、前記コールを連続させるために、前記ＵＥデバイス（３０２）に利用可能な代替ドメインをさらに含む、請求項１２に記載のＵＥデバイス（３０２）。
【請求項１５】
前記代替ドメインは、パケット交換（ＰＳ）ネットワークドメインと回路交換（ＣＳ）ネットワークドメインとのうちの一つを備える、請求項１４に記載のＵＥデバイス（３０２）。
【請求項１６】
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）内で動作可能なネットワークノード（３０８）であって、該ネットワークノード（３０８）は、
ユーザ装備（ＵＥ）デバイス（３０２）から受信したセッション開始プロトコル（ＳＩＰ）インバイトメッセージが、リクエスト−ユニフォームリソース識別子（Ｒ−ＵＲＩ）フィールドを含み、該Ｒ−ＵＲＩフィールドが、コール連続性のための呼び出しとして動作可能であるＵＲＩを含むことを確認する（３１３）手段と、
該ＵＥデバイス（３０２）に提供されるべきＳＩＰ応答メッセージを生成する手段（３１３）であって、該ＳＩＰ応答メッセージは、動的に割り当てられたＩＰマルチメディアルーティング番号（ＩＭＲＮ）と、１つ以上の無線アクセス技術と、該ＵＥデバイス（３０２）と動作可能な代替ドメインとのうちの少なくとも一つを含むように動作可能である、生成する手段（３１３）と
を備える、ネットワークノード（３０８）。
【請求項１７】
前記代替ドメインは、パケット交換（ＰＳ）ネットワークドメインと回路交換（ＣＳ）ネットワークドメインとのうちの一つを備える、請求項１６に記載のネットワークノード（３０８）。
【請求項１８】
前記ＵＲＩは、前記ネットワークノード（３０８）と関連するデータベース（１２２）に格納されている、請求項１６に記載のネットワークノード（３０８）。
【請求項１９】
前記代替ドメインは、Ｔｅｌ−ＵＲＩフォーマットで前記ＳＩＰ応答メッセージの中に識別される、請求項１６に記載のネットワークノード（３０８）。
【請求項２０】
前記代替ドメインは、Ｅ．１６４フォーマットで前記ＳＩＰ応答メッセージの中に識別される、請求項１６に記載のネットワークノード（３０８）。
【発明の詳細な説明】
【技術分野】
【０００１】
（開示の分野）
本特許開示は、通信ネットワークにおけるコール処理に、一般的に関連する。より具体的には、何ら制限を加える分けではないが、本特許開示は、セッション開始プロトコル（ＳＩＰ）メッセージ伝達を用いる回路交換（ＣＳ）ネットワークおよびＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークを含むネットワーク環境において、コール連続性を管理するシステムおよび方法に向けられる。
【背景技術】
【０００２】
（背景）
モバイルボイスオーバＩＰ（ＶｏＩＰ）ハンドオーバは、ユーザがＩＰベースのパケット交換（ＰＳ）ネットワーク（例えば、無線ＬＡＮ（ＷＬＡＮ）またはＷｉ−ＭＡＸネットワークなど）と回路交換（ＣＳ）セルラネットワークとの間で移動するときに、ボイスコールを連続させる処理である。このようなハンドオーバを実行するために、現行の第三世代パートナシッププロジェクト（３ＧＰＰ）標準は、デュアルモード無線ユーザ装備（ＵＥ）デバイスがドメイン間連続性をリクエストするコールを発信するとき、コールが、ＩＰマルチメディアサブシステム（ＩＭＳ）と称される新たなＩＰベースのネットワークアーキテクチャ内に配置されたコール連続性制御機能（ＣＣＣＦ）エレメントにルーティングされることに仕様を定めている。コールルーティング処理をインプリメントするために提案された解決策の一つは、パブリックサービスアイデンティティを、コールリファレンスアイデンティティがＩＰマルチメディアルーティング番号（ＩＭＲＮ）を付加され、生成し得るＥ．１６４番号（例えば、コールされたパーティの番号）の形式で、提供することを含む。このＩＭＲＮはまた、３ＧＰＰ  ＴＳ  ２３．２０６の仕様で、ボイスコール連続性（ＶＣＣ）ドメイン転送番号（ＶＤＮ）とも称される。しかしながら、コールリファレンス識別デジットが、Ｅ．１６４番号に付加されるとき、その結果、ＩＵＴ−Ｔ標準の下で特定される１５桁の長さ制限よりも長い番号となる。したがって、このような番号がネットワークを介してルーティングされるとき、追加の数字は、失われ得る可能性もある。さらに、ＩＭＳネットワークのＶＣＣアプリケーションまたはＣＣＣＦエレメントに提供されているコーラＩＤ情報に対する信頼がある場合、この情報は、ＩＳＤＮユーザパーツ（ＩＳＵＰ）信号伝達を用いる国際ＩＳＤＮインフラの中で失われる。追加として、ＩＭＳは、異なるＵＥデバイスから共通のパブリックアイデンティティ（Ｐｕｂｌｉｃ  Ｉｄｅｎｔｉｔｙ）の複数の登録をサポートするように設計されているので、正しいコールレグ（ｃａｌｌ  ｌｅｇ）の確立は、コール連続性を実行するにあたっての最重要点となっている。
【発明の開示】
【課題を解決するための手段】
【０００３】
（概要）
本特許開示は、回路交換（ＣＳ）ネットワークおよびＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク環境を含むネットワーク環境において、コール連続性を管理するスキームに、幅広く向けられる。ここで、セッション開始プロトコル（ＳＩＰ）インバイトメッセージ（あるいは別のＳＩＰリクエスト）が利用され、ＳＩＰインバイトメッセージは、リクエスト−ユニフォームリソース識別子（Ｒ−ＵＲＩ）フィールドに含まれるＵＲＩを有し、Ｒ−ＵＲＩフィールドは、アプリケーションサーバで、ＣＳドメインで使用され得るルーティング可能な電話番号を提供する表示として公知である。すなわち、リクエストＵＲＩフィールドに含まれるＵＲＩは、アプリケーションサーバによって、ホストされ、アプリケーションサーバによって提供されるべきＣＳドメインルーティング可能な番号に対するリクエストとして、動作可能である。このようなルーティング可能な番号の例は、ＶＤＮ、ＩＭＲＮ、Ｅ．１６４番号などを含む。ＵＥデバイスからのＳＩＰインバイトメッセージに応答して、ネットワークノードは、ＳＩＰ応答メッセージ、例えば、代替サービス応答メッセージ（ＳＩＰ３８０応答とも称される）を提供する。このメッセージは、コールを一つのドメインから他のドメインへと連続させるために、ＵＥデバイスに利用可能な１つ以上の無線アクセス技術（ＲＡＴ）および代替ドメインを含む。好ましくは、利用可能なＲＡＴおよび代替ドメイン情報は、ＵＥデバイスのロケーションに基づき得る。
【０００４】
ＳＩＰインバイトメッセージには、特定の一意的なＩＤ情報が含まれ、このＩＤ情報は、進行中のコールを識別するために、記録のアドレス（ＡＯＲ）、グローバルにルーティング可能なユーザエージェントユニフォームリソース識別子（ＧＲＵＵ）、および／またはインスタンスＩＤ、あるいはこれらの任意の組み合わせを備え得る。インスタンスＩＤは、ＩＭＥＩ、ＩＭＥＩＳＶ、ＭＩＮ、ＥＳＮ、ＵＵＩＤ、ＭＡＣアドレス、ソフトウェアＩＤ（例えば、モバイルソフトウェア端末識別子）、あるいはＵＥデバイスを一意的に識別するために使用され得る任意の他の一意的なＬａｙｅｒ−２アドレスであり得る。コールが、ＵＥデバイスによって発信されるとき、そのコールと関連し、一意的なＩＤ情報を含むコール情報は、ＩＭＳネットワークに配置されたサーバ／ノードに提供される。これは、ＳＩＰヘッダ（例えば、ターゲット対話ヘッダまたは同一セッションヘッダ）の中のインバイトに含まれる対話情報、あるいはインバイトメッセージのボディ（例えば、ＳＩＰｆｒａｇボディ）に含まれる対話情報に基づき得る。ネットワークノードで、Ｅ．１６４番号のプールは、ＩＰマルチメディアルーティング番号（ＩＭＲＮ）（３ＧＰＰ  ＴＳ  ２３．２０６の仕様で、ボイスコール連続性（ＶＣＣ）ドメイン転送番号またはＶＣＣディレクトリ番号（ＶＤＮ）としても公知である）として維持される。このＩＭＲＮは、例えば、進行中のコールを識別するために、ＵＥデバイスから受信されたコール情報のプールの少なくとも一部分と関連付けるために、動的に割り当てられ得る。本特許開示の目的のために、「ＶＤＮ」および「ＩＭＲＮ」（より一般的には、「ルーティング可能な番号」）は、相互に置き換わるように使用される。ここで、基本的に、両者は、ルーティング可能な番号を意味し、一つのドメインから他のドメインにハンドオーバする能力が存在する場合、ＩＭＳアプリケーションサーバにルーティングするために使用される。さらに、ルーティング可能な番号の割り当ては、一意的に進行中のコールを識別する一部の形式において、一意的であるという意味で、動的である。その番号は、番号のプールからであり得るか、あるいは特定の変数を用いて生成され得る何らかのアルゴリズムの番号であり得る。ルーティング可能な番号の主たる特徴は、ある期間の間にわたって、その番号が一意的であることであり、この期間は、可変的に構成可能である。したがって、この一意的な番号は、適切なタイマメカニズムによって、規定される寿命を有する「循環する（ｒｅｖｏｌｏｖｉｎｇ）」番号としてみなされ得る。
【０００５】
ＵＥデバイスが、異なるドメインで、コールを続けることを決定するとき、ＳＩＰインバイトメッセージを受信することに応答して、ネットワークノードは、選択ルーティング可能な番号（すなわち、ＩＭＲＮまたはＶＤＮ）をマッピング関係にあるコール情報の少なくとも一部分と関連付けし、ＳＩＰ３８０応答メッセージを介してそれをＵＥデバイスに戻す。このＳＩＰ３８０応答メッセージはまた、利用可能なＲＡＴ、代替ドメインと、適用されるような追加情報とを含み得る。好ましくは、ＳＩＰ３８０応答メッセージのボディは、適切なマークアップ言語（例えば、拡張マークアップ言語、すなわちＸＭＬ）にコード化される。他のドメインにコール設定するために、動的に割り当てられたＩＭＲＮが、ＵＥデバイスによって送信され、ネットワークノードに戻るとき、ネットワークノードは、ＩＭＲＮマッピングを利用し、コールされたパーティに対して、コール連続性を実行する。ＩＭＲＮは、次いで、将来の使用のために、ＩＭＲＮのプールにリリースバックされ得る。適切なタイマが、デバイスおよびネットワーク終点で提供され得る。これは、コールと関連するコールリファレンス番号が、有効な状態に留まっている（例えば、タイムアウトしていない）かどうか、あるいは動的に割り当てられたＩＭＲＮが、有効な状態に留まっている（例えば、タイムアウトしていない）かどうかを、ＩＭＲＮが確認されるようにするためである。オプションとして、リリースされたＩＭＲＮは、ある期間にわたって、隔離され得る。
【０００６】
上述の実施形態は、特定のＳＩＰメッセージ（すなわち、インバイトリクエストおよびＳＩＰ３８０応答メッセージ）を説明しているが、この機能性は、他のメッセージ伝達インプリメンテーションにおいても、得られ得ることを当業者は、理解するはずである。一つの局面において、ＩＭＳネットワークにおけるコールと関連するＵＥデバイスを用いて動作可能であるコール連続性方法の実施形態は、本特許出願で、開示される。該方法は、ＩＭＳネットワークにおけるコールと関連するＵＥデバイスで動作可能である。特許請求に係る実施形態は、以下：ＳＩＰインバイトメッセージを介して、ＵＥデバイスによるコールと関連するコール情報を、ＩＭＳネットワーク内に配置されたネットワークノードに提供することであって、該ＳＩＰインバイトメッセージは、ＩＭＲＮまたはＶＤＮのようなルーティング可能な番号を提供する（すなわち、ＵＲＩは、コール連続性のための呼び出し（ｉｎｖｏｃａｔｉｏｎ）として動作可能である）ことの表示として、ＳＩＰアプリケーションサーバ、例えば、ＶＣＣアプリケーションサーバに知られているＵＲＩを含む、提供することと、ＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答メッセージ）を介して該ネットワークノードから、動的に割り当てられたルーティング可能な番号を受信することに応答して、該コールと関連するコールリファレンス番号が有効であることを確認することと、該確認後に、コール連続性を実行するために、該ＵＥデバイスによって、該動的に割り当てられたルーティング可能な番号を該ネットワークノードに提供することとのうちの１つ以上を包含する。本特許開示の目的のために、ルーティング可能な番号に対するリクエストを含むＶＣＣ呼び出しとして、取り扱われるように動作可能であるＵＲＩは、ＶＣＣノードまたはドメイン転送機能（ＤＴＦ）で処理されるドメイン転送ＵＲＩ（ＤＴＲ−ＵＲＩ）またはＶＣＣドメインＶＤＮ番号ＵＲＩ（ＶＶＮＵ）とも称され得る。
【０００７】
別の局面において、本明細書において、ＩＭＳネットワークにおいて、ドメイン間連続性を用いるコールを連続して動作可能なＵＥデバイスの実施形態が、開示される。特許請求に係る実施形態は、以下：ＳＩＰインバイトメッセージを介して、コールと関連するコール情報をＩＭＳネットワーク内に配置されたネットワークノードに提供する手段であって、該ＳＩＰインバイトメッセージは、ＶＣＣ呼び出しに対して動作可能であるＵＲＩを含む、提供する手段と、ＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答）を介して、該ネットワークノードから、動的に割り当てられたルーティング可能な番号（例えば、ＩＭＲＮまたはＶＤＮ）を受信したことに応答して動作可能であり、該コールと関連するコールリファレンス番号が有効であることを確認する手段と、該確認に応答して動作可能で、コール連続性を実行するために、該ネットワークノードに、該動的に割り当てられたルーティング可能な番号を提供する手段とのうちの１つ以上を備える。
【０００８】
さらなる別の局面において、本明細書において、ＩＭＳネットワークノードの実施形態が、開示される。該ネットワークノードは、以下：ＵＥデバイスから受信したＳＩＰインバイトメッセージが、ＳＩＰアプリケーションサーバ、例えば、ＶＣＣアプリケーションサーバで、コール連続性のために動作可能であるＵＲＩを含むことを確認する手段と、該ＵＥデバイスに提供されるべきＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答）を生成する手段とのうちの１つ以上を備え、該ＳＩＰ応答メッセージは、動的に割り当てられたＩＭＲＮと、１つ以上の無線アクセス技術と、該ＵＥデバイスと動作可能な代替ドメインとのうちの少なくとも一つを含むように動作可能である。
【０００９】
本発明は、さらに、以下の手段を提供する。
【００１０】
（項目１）
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）において、コールと関連するユーザ装備（ＵＥ）デバイス（３０２）で動作可能な方法であって、該コールは、コールされたパーティに向けて発信され、該方法は、
セッション開始プロトコル（ＳＩＰ）インバイトメッセージ（３１２、３５６）を介して、該ＵＥデバイス（３０２）による該コールと関連するコール情報を、該ＩＭＳネットワーク（３５０）内に配置されたネットワークノード（３０８）に提供すること（２２２）であって、該ＳＩＰインバイトメッセージ（３１２、３５６）は、コール連続性のための呼び出しとして動作可能なユニフォームリソース識別子（ＵＲＩ）を含む、提供すること（２２２）と、
ＳＩＰ応答メッセージ（３１６、３６４／３６６）を介して該ネットワークノード（３０８）から、ルーティング可能な番号を受信することに応答して、該コールと関連するコールリファレンス番号が有効であることを確認すること（２２４）と、
該確認（２２４）後に、コール連続性を実行するために、該ＵＥデバイス（３０２）によって、該ネットワークノード（３０８）に該ルーティング可能な番号を提供すること（２２６）と
を包含する、方法。
【００１１】
（項目２）
上記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、ＳＩＰ３８０（代替サービス）応答を備え、該ＳＩＰ３８０応答は、無線アクセス技術のリストをさらに含む、項目１に記載の方法。
【００１２】
（項目３）
上記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、上記コールを連続させるために、上記ＵＥデバイス（３０２）に利用可能な代替ドメインをさらに含む、項目１に記載の方法。
【００１３】
（項目４）
上記代替ドメインは、パケット交換（ＰＳ）ネットワークドメインと回路交換（ＣＳ）ネットワークドメインとのうちの一つを備える、項目３に記載の方法。
【００１４】
（項目５）
上記ルーティング可能な番号は、ＶＣＣドメイン転送番号（ＶＤＮ）とＩＰマルチメディアルーティング番号（ＩＭＲＮ）とのうちの一つを備える、項目１に記載の方法。
【００１５】
（項目６）
上記コールが、第一のドメインから第二のドメインに連続されるべきであると決定されると、上記ＳＩＰインバイトメッセージ（３１２、３５６）は、上記ＵＥデバイス（３０２）によって提供される、項目１に記載の方法。
【００１６】
（項目７）
上記ＵＲＩは、上記ＵＥデバイス（３０２）と関連する取り外し可能なストレージモジュールに、ローカルに格納される、項目１に記載の方法。
【００１７】
（項目８）
上記ＵＲＩは、上記ＵＥデバイス（３０２）内に集積されたメモリ回路に、ローカルに格納される、項目１に記載の方法。
【００１８】
（項目９）
上記ＵＲＩは、上記ＩＭＳネットワーク（３５０）によって上記ＵＥデバイス（３０２）に動的に割り当てられている、項目１に記載の方法。
【００１９】
（項目１０）
上記ＵＲＩは、ＳＩＰヘッダまたはＳＩＰメッセージのボディのうちの一つを提供される、項目９に記載の方法。
【００２０】
（項目１１）
上記ＵＲＩは、上記ＵＥデバイス（３０２）と関連するユーザＩＤパラメータに基づいて、該ＵＥデバイス（３０２）によって、生成される、項目１に記載の方法。
【００２１】
（項目１２）
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）において、コールを発信するように動作可能であるユーザ装備（ＵＥ）デバイス（３０２）であって、該コールは、コールされたパーティに向けて導かれ、該ＵＥデバイス（３０２）は、
セッション開始プロトコル（ＳＩＰ）インバイトメッセージ（３１２、３５６）を介して、該コールと関連するコール情報を、該ＩＭＳネットワーク（３５０）内に配置されたネットワークノード（３０８）に提供する（２２２）手段であって、該ＳＩＰインバイトメッセージ（３１２、３５６）は、コール連続性のための呼び出しとして動作可能なユニフォームリソース識別子（ＵＲＩ）を含む、提供する（２２２）手段と、
ＳＩＰ応答メッセージ（３１６、３６４／３６６）を介して、該ネットワークノード（３０８）から、ルーティング可能な番号を受信したことに応答して動作可能であり、該コールと関連するコールリファレンス番号が有効であることを確認する（２２４）手段と、
該確認（２２４）に応答して動作可能で、コール連続性を実行するために、該ＵＥデバイス（３０２）によって、該ネットワークノード（３０８）に、該ルーティング可能な番号を提供する（２２６）手段と
を備える、ＵＥデバイス（３０２）。
【００２２】
（項目１３）
上記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、ＳＩＰ３８０（代替サービス）応答を備え、該ＳＩＰ３８０応答は、無線アクセス技術のリストをさらに含む、項目１２に記載のＵＥデバイス（３０２）。
【００２３】
（項目１４）
上記ＳＩＰ応答メッセージ（３１６、３６４／３６６）は、上記コールを連続させるために、上記ＵＥデバイス（３０２）に利用可能な代替ドメインをさらに含む、項目１２に記載のＵＥデバイス（３０２）。
【００２４】
（項目１５）
上記代替ドメインは、パケット交換（ＰＳ）ネットワークドメインと回路交換（ＣＳ）ネットワークドメインとのうちの一つを備える、項目１４に記載のＵＥデバイス（３０２）。
【００２５】
（項目１６）
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）内で動作可能なネットワークノード（３０８）であって、該ネットワークノード（３０８）は、
ユーザ装備（ＵＥ）デバイス（３０２）から受信したセッション開始プロトコル（ＳＩＰ）インバイトメッセージが、リクエスト−ユニフォームリソース識別子（Ｒ−ＵＲＩ）フィールドを含み、該Ｒ−ＵＲＩフィールドが、コール連続性のための呼び出しとして動作可能であるＵＲＩを含むことを確認する（３１３）手段と、
該ＵＥデバイス（３０２）に提供されるべきＳＩＰ応答メッセージを生成する手段（３１３）であって、該ＳＩＰ応答メッセージは、動的に割り当てられたＩＰマルチメディアルーティング番号（ＩＭＲＮ）と、１つ以上の無線アクセス技術と、該ＵＥデバイス（３０２）と動作可能な代替ドメインとのうちの少なくとも一つを含むように動作可能である、生成する手段（３１３）と
を備える、ネットワークノード（３０８）。
【００２６】
（項目１７）
上記代替ドメインは、パケット交換（ＰＳ）ネットワークドメインと回路交換（ＣＳ）ネットワークドメインとのうちの一つを備える、項目１６に記載のネットワークノード（３０８）。
【００２７】
（項目１８）
上記ＵＲＩは、上記ネットワークノード（３０８）と関連するデータベース（１２２）に格納されている、項目１６に記載のネットワークノード（３０８）。
【００２８】
（項目１９）
上記代替ドメインは、Ｔｅｌ−ＵＲＩフォーマットで上記ＳＩＰ応答メッセージの中に識別される、項目１６に記載のネットワークノード（３０８）。
【００２９】
（項目２０）
上記代替ドメインは、Ｅ．１６４フォーマットで上記ＳＩＰ応答メッセージの中に識別される、項目１６に記載のネットワークノード（３０８）。
【００３０】
（摘要）
一つの実施形態において、回路交換（ＣＳ）ネットワークおよびＩＰマルチメディアサブシステム（ＩＭＳ）ネットワーク（３５０）を含むネットワーク環境（１００）において、コール連続性を管理するスキームが、開示される。ここで、ルーティング可能な番号の戻りをトリガして動作可能であるリクエストＵＲＩに含まれるドメイン転送ＵＲＩを有するＳＩＰインバイトメッセージが、利用される。ＵＥデバイス（３０２）のＳＩＰインバイトメッセージに応答して、ネットワークノード（３０８）は、ＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答）を提供する。このＳＩＰ応答メッセージは、１つ以上の無線アクセス技術と、一つのドメインから他のドメインへのコールを連続させるために、このＵＥデバイス（３０２）で利用可能な代替ドメインとを含む。
【発明を実施するための最良の形態】
【００３１】
本特許開示の実施形態のより完全な理解は、添付図面と合わせて、以下の詳細な説明を参照することによって、得られ得る。
【００３２】
（図面の詳細な説明）
ここで、本特許開示のシステムおよび方法が、実施形態が最適に行われ、使用される方法の様々な例を参照して説明される。同様の参照番号が、同様または対応するパーツを示すために、説明および図面の幾つかの図を通して使用される。なお、様々なエレメントは、必ずしも縮尺どおりには描かれていない。ここで、図面を参照すると、より具体的には、図１を参照すると、例示的なネットワーク環境１００が示される。ここで、本特許開示の実施形態は、ＵＥデバイスによって生成されたコールに対して、コール連続性を管理するために、実行され得る。図示されるように、ネットワーク環境１００は、複数のＵＥデバイス１０２−１〜１０２−Ｎにとって利用可能な幾つかのアクセス技術からなるアクセススペース１０４を含む。本開示の目的において、ＵＥデバイスは、任意の繋げられた、あるいは繋げられてない通信デバイスであり得、そして、適切な無線モデムまたはモバイル通信デバイス（例えば、メッセージの送受信、ウェブブラウジングなどの可能なセルラ電話、またはデータ可能な携帯デバイス）を備えた任意のパーソナルコンピュータ（例えば、デスクトップ、ラップトップ、パームトップ、またはハンドヘルド計算デバイス）、あるいはｅメール、ビデオメール、インターネットアクセス、社内データアクセス、メッセージ伝達、カレンダ記入、スケジューリング、情報管理などが可能な任意の強化ＰＤＡデバイスまたは統合情報装置であり得る。好ましくは、ＵＥデバイスは、回路交換（ＣＳ）通信とパケット交換（ＰＳ）通信との双方に関与し得る複数のモードで動作可能であること、および、連続性を失うことなく、一方の通信モードから他方の通信モードへと移行し得る。
【００３３】
アクセススペース１０４は、ＣＳネットワークとＰＳネットワークとの双方からなり得、これらネットワークは、無線技術、有線技術、広帯域アクセス技術などと関与し得る。例えば、参照番号１０６は、モバイル通信用グローバルシステム（ＧＳＭ）ネットワークおよび符号分割多元接続（ＣＤＭＡ）ネットワークのような無線技術を意味するが、それらの教示は、任意の第三世代パートナシッププロジェクト（３ＧＰＰ）に準拠したセルラネットワーク（例えば、３ＧＰＰまたは３ＧＰＰ２）にも拡張され得ることも考慮される。参照番号１０８は、無線ローカルエリアネットワークすなわちＷＬＡＮ、Ｗｉ−ＭＡＸネットワークを含む広帯域アクセスネットワークと、ＤＳＬ、ケーブルブロードバンドなどのような固定ネットワークとを意味する。したがって、本開示の目的に対して、アクセス技術は、ＩＥＥＥ  ８０２．１１ａ技術、ＩＥＥＥ  ８０２．１１ｂ技術、ＩＥＥＥ  ８０２．１１ｇ技術、ＩＥＥＥ  ８０２．１１ｎ技術、ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）技術（ＣＳドメインおよびＰＳドメインの双方）、およびユニバーサルモバイル電気通信システム（ＵＭＴＳ）技術、ならびにＥｖｏｌｕｔｉｏｎ−Ｄａｔａ  Ｏｐｔｉｍｉｚｅｄ（ＥＶＤＯ）技術などから選択される無線アクセス技術を備え得る。追加として、アクセススペース１０４の一部として、図１に示される従来のワイヤ線ＰＳＴＮインフラ１１０が、例示される。
【００３４】
ＩＰマルチメディアサブシステム（ＩＭＳ）コアネットワーク１１２は、任意のＣＳベースのネットワークを含む上述の様々なアクセスネットワークに結合される。周知のように、３ＧＰＰによって規定されるＩＭＳ標準は、サービスプロバイダが、任意のネットワークタイプ上のＩＰを介して配信され得る様々なサービスを管理可能なように設計される。ここで、ＩＰは、ベアラトラフィック（ｂｅａｒｅｒ  ｔｒａｆｆｉｃ）とセッション開始プロトコル（ＳＩＰ）ベースの信号伝達トラフィックとの双方を伝送する（ｔｒａｎｓｐｏｒｔ）ために使用される。大まかに、ＩＭＳは、アプリケーション（すなわち、サービス）およびネットワーク（すなわち、アクセス）を管理するための枠組みであり、この枠組みは、マルチメディアサービスを提供することが可能である。ＩＭＳは、サービス加入者が使用する、例えば、音声コール連続性（ＶＣＣ）、プッシュトゥトーク（ＰＴＴ）などを配信するネットワークエレメントとして、「アプリケーションサーバ」を規定する。ＩＭＳは、各アプリケーションサーバ（ＡＳ）が、例えば、加入者プロファイル、ＩＭＳ移動性、ネットワークアクセス、認証、サービス認可、課金および請求、オペレータ間機能、従来電話ネットワークとの相互動作などを有するように要求される共通の制御コンポーネントを規定することによって、アプリケーションを管理する。
【００３５】
ＩＭＳは、主としてＧＳＭネットワークを扱う３ＧＰＰ標準ボディによって規定されるのに対し、他のグループである３ＧＰＰ２標準は、マルチメディアドメイン（ＭＭＤ）と称される非常に類似したアーキテクチャを規定することに関与することは、理解されるべきである。ＭＭＤは、本質的に、ＣＤＭＡネットワークに対するＩＭＳであり、ＭＭＤとＩＭＳとは、概ね同等なので、本特許開示において、「ＩＭＳ」という用語は、適用可能なとき、ＩＭＳとＭＭＤとの双方を集合的に意味するように使用され得る。さらに、ＩＭＳに基づき、および／またはＩＭＳを再使用するＮＧＮ（次世代ネットワーク）に対する固定ネットワーク標準もまた、ＥＴＳＩ  ＴＩＳＰＡＮ、Ｃａｂｌｅｌａｂｓ、およびＩＴＵ−Ｔのようなボディによって開発されている。ＮＧＮおよびＩＭＳは、概ね同等なので、したがって、本特許開示において、「ＩＭＳ」という用語は、適用可能なとき、ＩＭＳとＮＧＮとの双方を集合的に意味するように使用され得る。
【００３６】
図１を参照して続けると、参照番号１１４−１〜１１４−Ｎは、例えば、ＶＣＣ、ＰＴＴなどの上記で暗示したような様々なサービスをサポートするように動作可能な複数のＡＳノードを意味する。特に、ＶＣＣ  ＡＳノード１１４−Ｎは、ＶＣＣ可能なデバイスによって生成されたコールに対して、コール連続性および適切なドメイン選択を実行するように動作可能である。典型的には、ＡＳ  １１４−Ｎは、加入者のホームＩＭＳコアネットワークの一部として提供され得、この加入者のホームＩＭＳコアネットワークは、コール連続性制御機能（ＣＣＣＦ）１１６およびネットワークドメイン選択（ＮｅＤＳ）１１８と称される機能性をインプリメントする。本質的に、ＡＳ  １１４−ＮのＣＣＣＦポーション１１６は、ホームＩＭＳネットワーク内に常駐し、全てのコールセッションと、ＣＳドメインとＩＭＳドメインとの間でのコールのハンドオーバ／ルーティングを含む関連モバイルボイスオーバＩＰ（ＶｏＩＰ）ベアラトラフィックとを追跡する新たなＩＭＳアプリケーションサーバエレメントとして動作可能である。ＡＳ  １１４−ＮのＮｅＤＳポーション１１８は、とりわけ、ＩＭＳネットワークとＣＳネットワーク（例えば、ＧＳＭまたはＣＤＭＡ）との間の登録／登録削除の管理を実行する役割を担う。ＣＣＣＦ機能性とＮｅＤＳ機能性とは、潜在的には別の機能であるが、図１に示されるような単一のＩＭＳ互換可能なネットワークエレメント１１４−Ｎに、両機能性を統合することも可能である。また、適切なセッション制御機能（ＳＣＦ）１２０は、適用可能な無線アクセス技術、例えば、ｇｓｍＳＣＦに対するＶＣＣ  ＡＳノード１１４−Ｎの一部として提供され得る。追加のＶＣＣ関連機能エンティティは、以下：ドメイン転送機能（ＤＴＦ）（機能エンティティＦＥ−Ａとも称される）、ＣＳ適合機能（ＣＳＡＦ）（ＦＥ−Ｂとも称される）、ＣＡＭＥＬサービス（ＦＥ−Ｃとも称される）、およびドメイン選択機能（ＤＳＦ）（ＦＥ−Ｄとも称される）とを含み得、これらは、「ＶＣＣアプリケーション」を形成する。したがって、本開示の目的において、（例えば、ＡＳ  １１４−Ｎのような）ＩＭＳコアネットワークと関連する「ネットワークノード」という用語は、適用可能なとき、ＦＥ−Ａ〜ＦＥ−Ｄ、ｇｓｍＳＣＦ、ＣＣＣＦ、およびＮｅＤＳと、本明細書で以下に詳細に記載される追加のサービスロジックとの機能性の１つ以上を任意の組み合わせで、備え得る。
【００３７】
さらに、図１には示されていないが、ホーム加入者サーバ、すなわちＨＳＳとも称されるマスタユーザデータベースが、ホームＩＭＳネットワーク１１２の一部として、ＶＣＣノード１１４−Ｎのようなコールまたはセッションを実際に管理する様々なＩＭＳネットワークエンティティをサポートするために、提供される。一般に、ＨＳＳデータベースは、ユーザプロファイル（すなわち、加入者関連情報）を含み得、ユーザプロファイルは、国際モバイル加入者ＩＤ（ＩＭＳＩ）、一時的モバイル加入者ＩＤ（ＴＭＳＩ）、国際モバイル装備ＩＤ（ＩＭＥＩ）、モバイル加入者ＩＳＤＮ番号（ＭＳＩＳＤＮ）、ユニバーサルに一意的な識別子（ＵＵＩＤ）のような様々なユーザおよびデバイスのＩＤと、ＩＭマルチメディアプライベートＩＤ（ＩＭＰＩ）およびＩＰマルチメディアパブリックＩＤ（ＩＭＰＵ）のような追加的なＩＭＳ特有のＩＤとを含み、これらは、Ｔｅｌ−ユニフォームリソース識別子（ＵＲＩ）またはＳＩＰ−ＵＲＩとしてインプリメントされる。ＩＭＰＩは、３ＧＰＰシステム（すなわち、（Ｉ）ＳＩＭ）において、特定のユーザに一意的であるか、あるいは別の技術において、特定のＵＥデバイスに一意的であり得るのに対し、ＩＭＰＩごとに、複数のパブリックＩＤ（すなわち、ＩＭＰＵ）を有することも可能である。さらに、ＩＭＰＵはまた、ＩＭＰＩと共有され得、その結果、２つ以上のデバイスが、同じＩＤを有して到達され得る（例えば、ファミリ全体に対し、単一の電話番号）。
【００３８】
追加として、適切なデータベース構造（例えば、ＤＢ１２２）、タイマメカニズム（例えば、タイマ１２４）、および適切なロジック１２６は、ＩＰマルチメディアルーティング番号（ＩＭＲＮ）のプールを構成して、管理する目的のために、ＡＳ１１４−Ｎと関連して提供され得る。ＩＭＲＮは、ＶＣＣディレクトリ番号、すなわちＶＤＮとも称され、この番号から、選択ＩＭＲＮ／ＶＤＮは、コールルーティングおよびコール連続性を管理する目的のために、動的に割り当てられ得る。さらに、ＤＢ１２２は、幾つかのＵＲＩを格納して動作可能でもあり、幾つかのＵＲＩは、ＶＣＣノードで、ＶＣＣサービスを呼び出すために使用される。しかしながら、リクエストＵＲＩの扱いに関して以前に暗示したように、ＶＣＣノードは、リクエストＵＲＩの受信および検査から、リクエストしているＵＥデバイスがＶＣＣサービスを呼び出したいと望んでいることを知っている。以下により詳細に記載されるように、ＳＩＰインバイトメッセージが、ＵＥデバイスによってＶＣＣノードに送信されるとき、そのノードで適切なサービスロジックが、コール連続性を実行するために、ＶＤＮに対するリクエストとして、インバイトメッセージを解釈して、処理するように動作可能である。
【００３９】
本特許開示の教示に従うと、ＣＣＣＦ能力を有するＩＭＳネットワークノードは、適切なロジック／構造／ソフトウェア／ファームウェアモジュールを提供されることが好ましく、これは、ＵＥデバイスから受信されたＳＩＰインバイトメッセージが、リクエストＵＲＩフィールドの中に、ＶＣＣ呼び出し（すなわち、ＤＴＲ／ＵＲＩ）として動作可能なＵＲＩを含むことの確認と、ＵＥデバイスに提供されるべき適切なＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答メッセージ）の生成とを実行するためである。ここで、ＳＩＰ応答メッセージは、動的に割り当てられたＩＭＲＮ／ＶＤＮと、１つ以上の無線アクセス技術と、ＵＥデバイスで動作可能な代替ドメインとのうちの少なくとも１つを含むように動作可能である。ＩＭＳノードまたはＶＣＣアプリケーションは、したがって、リクエストＵＲＩフィールドを解析して、ＳＩＰインバイトメッセージの中で受信されたＧＲＵＵによって識別されたＵＥおよびユーザに対して、進行中のコールに割り当てられるべきＶＤＮを要求するのは、ＵＲＩであることを決定する。ＶＤＮまたはＩＭＲＮを割り当て、管理するために、ネットワークノードはまた、ネットワークノード上で完了するＩＭＲＮとして動作可能であるＥ．１６４番号のプールを維持することと、コールされたパーティ番号に選択ＩＭＲＮおよび／またはＵＥデバイスから受信された特定の一意的なＩＤ情報（例えば、ＧＲＵＵ）を動的に割り当て、発信ＵＥデバイスに選択ＩＭＲＮを提供することと、その選択ＩＭＲＮが、コールされたパーティ番号に対するコールルーティング／連続性処理を実行するために、ネットワークノードに戻るとき、選択ＩＭＲＮがタイムアウトしていなかったことを確認することと、そして、オプションとして、将来の使用のために、ＩＭＲＮプールに選択ＩＭＲＮをリリースバックすると、その選択ＩＭＲＮをある期間にわたって隔離することとを行うのに適切なロジック／構造／ソフトウェア／ファームウェアを含む。したがって、ＩＭＲＮまたはＩＭＲＮのグループは、動作構成可能なデータとして、ＶＣＣアプリケーションサーバに格納され得るか、あるいは、フォーマットの検査によって、ＶＣＣアプリケーションは、ＩＭＲＮ／ＶＤＮが何のためであるかを決定するように動作可能である。
【００４０】
動的に割り当て可能なＩＭＲＮのプールを管理するために、ネットワークノード（例えば、ＶＣＣ  ＡＳ  １１４−Ｎ）は、Ｅ．１６４番号に対して、幾つかの方法で構成され得る。例えば、特定のＥ．１６４番号は、ＩＭＲＮ範囲の「開始アドレス」番号として提供され得る。別のＥ．１６４番号は、そのＩＭＲＮ範囲に対して、範囲デリミタとして動作し得る。融通性を可能にするために、異なる番号範囲から構成されるように、ＩＭＲＮの異なるプールを提供することが、望ましいこともあり得る。さらに、適切なタイマメカニズムが、割り当てられたＩＭＲＮが有効な状態で留まっていること（例えば、ＩＭＲＮがタイムアウトしなかったこと、すなわち、ＩＭＲＮが適切な期限内に使用されること）、あるいは適切な隔離期間が適用されることを確実にするために、ネットワークノードで、インプリメントされ得る。以下に詳細に記載されるように、ネットワークノードでＩＭＲＮと関連するタイマと、発信ＵＥデバイスでのコールリファレンス番号と関連するタイマとを管理することによって、Ｅ．１６４番号に追加のデジットを付加して、ＩＭＲＮを生成する必要なしに、コールルーティング／連続性のために使用され得るＩＭＲＮを動的に提供することが可能になる。
【００４１】
一つの実施形態において、以下のステップが、ＳＩＰメッセージ伝達を用いて、コール連続性を実行するために、典型的に含まれる。ＵＥデバイスが、ドメイン転送する必要（すなわち、既存のコールが、そのコールの発信されたドメインとは異なるドメインで続けられる必要）があると決定するとき、ＵＥデバイスは、ＰＳＩ、すなわち、ＶＤＮを戻して提供するように動作可能なＵＲＩを含むリクエストＵＲＩに向けたＳＩＰインバイトメッセージを送信する。このＳＩＰインバイトメッセージは、ＶＣＣネットワークノードがリクエストを転送されるべきコールの既存のＳＩＰ対話と相関付けることを可能にする情報をおそらく含む（例えば、ターゲット対話ヘッダまたは同一セッションヘッダのようなＳＩＰヘッダ、あるいはＳＩＰｆｒａｇボディのようなインバイトのボディに含まれるものを用いて）。ＶＣＣネットワークノードで、サービスロジックは、インバイトメッセージを受信すると、受信されたインバイトメッセージがＶＤＮに対するリクエストであることを決定するように動作可能である。ＶＣＣアプリケーションノードは、ＳＩＰインバイトメッセージの中に、受信されたコール情報に対する進展中のＳＩＰ対話（すなわち、コールセッション）があることを確認するように動作可能であり、その後、ＵＥデバイスによって提供されたコールＩＤ／ＳＩＰ対話情報に基づいて、ネットワークノードは、現在アクティブであるドメイン（例えば、ＷＬＡＮを介するＩＭＳ／ＰＳコール）における既存のコールを一意的に識別する動的なＶＤＮを割り当てる（例えば、（ターゲット対話ヘッダまたは同一セッションヘッダのような）ＳＩＰヘッダにおけるインバイトメッセージ内に含まれる対話情報、あるいは（ＳＩＰｆｒａｇボディのような）インバイトのボディに含まれる対話情報に基づいて）。動的なＶＤＮは、利用可能なＲＡＴおよび代替ドメイン情報とともに、ＳＩＰ応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答）を介して、ＵＥデバイスに返信される。他の３ｘｘ応答コードもまた、このＶＣＣドメイン転送機能性を実行するために使用され得ることは理解されるべきである。ＵＥが、ＣＳドメインに付着されていない場合（進行中のＰＳドメインコールが、ＣＳドメインで続けられる必要があると仮定して）、ＵＥは、最初に、ＣＳ付着手順を実行し、次いで、動的にアサインされたＶＤＮを用いて、ボイスコール設定を開始する。特定のＲＡＴおよびネットワークは、ＳＩＰ３８０応答内に提供された情報に基づいて選択され得る。これらの処理は、追加の詳細を以下に記載される。
【００４２】
図２Ａは、ＵＥデバイスによるコールに対するコールルーティング／連続性を管理するための本特許開示の方法論全体の例示的な実施形態の流れ図を示す。ブロック２０２で、コールに関連する様々な情報の断片（本明細書にて、集合的に「コール情報」と称され得る）、例えば、コールリファレンス番号、またはコールと関連するＳＩＰ対話と、ＵＥと関連する一意的なＩＤ情報と、リクエストＵＲＩとは、発信ＵＥデバイスによって、ＳＩＰインバイトメッセージを介して、ＩＭＳネットワークノード、例えば、ＶＣＣネットワークノード１１４−Ｎに提供される。以前に指摘したように、リクエストＵＲＩは、ＵＲＩ（すなわち、ＤＴＲ−ＵＲＩまたはＶＶＮＵ）を含むＳＩＰ識別子またはフィールドであり、ＵＲＩは、ＵＥデバイスロジックがドメイン転送の呼び出しに使用するＶＤＮを戻すように動作可能なトリガとして公知である。ＤＴＲ−ＵＲＩを提供することに対して、幾つかのインプリメンテーションが可能である。一つの実施形態において、ＳＩＰ−ＵＲＩまたはＴｅｌ−ＵＲＩの形式の１つ以上のＤＴＲ−ＵＲＩが、取り外し可能なストレージモジュール（ユニバーサル加入者識別モジュール（ＵＳＩＭ）または取り外し可能なユーザ識別モジュール（ＲＵＩＭ））に格納され得る。代替として、これらは、デバイスの中に集積されるメモリ回路に格納され得る。いずれにせよ、ＤＴＲ−ＵＲＩが、オープンモバイルアライアンス（ＯＭＡ）デバイス管理（ＤＭ）か、あるいはショートメッセージサービス（ＳＭＳ）、非構造付加サービスデータ（ＵＳＳＤ）メッセージ伝達、またはＧＰＲＳ、Ｉ−ＷＬＡＮなどのＩＰトランスポートを用いる他の無線（ＯＴＡ）メカニズムを使用して、特定のＵＥデバイスに対して提供され得るか、もしくはＳＩＰ構成フレームワークを用いて提供され得る。さらなる実施形態において、ＤＴＲ−ＵＲＩは、Ｐ関連ＵＲＩヘッダ、またはＳＩＰ  ２００  ＯＫメッセージにおける他のＳＩＰヘッダを用いる登録のときに、ＩＭＳネットワークによって、ＵＥデバイスに動的に割り当てられ得る。またさらなる実施形態において、ＶＤＮリクエストに対して利用可能な格納されたＤＴＲ−ＵＲＩがない場合、ＩＭＳＩ、パブリックまたはプライベートなユーザＩＤなどのようなＵＥデバイスと関連するユーザＩＤ情報から生成され得る。ＩＭＳＩを使用する例は、以下：
“＜ＶＤＮ−ｔａｇ＞＜ＩＭＳＩ＞＠ｉｍｓ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ
“＜ＩＭＳＩ＞＜ＶＤＮ−ｔａｇ＞＠ｉｍｓ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ
を含む。プライベートユーザＩＤを使用する例は、以下：
Ｕｓｅｒｎａｍｅ＜ＶＤＮ−ｔａｇ＞＠ｈｏｍｅｎｅｔｗｏｒｋ．ｃｏｍ
＜ＶＤＮ−ｔａｇ＞Ｕｓｅｒｎａｍｅ＠ｈｏｍｅｎｅｔｗｏｒｋ．ｃｏｍ
を含む。
【００４３】
格納される場合、ＤＴＲ−ＵＲＩのテキストによる表現は、以下：
・＜ＶＤＮ−ｔａｇ＞＠ｌａｂｅｌ．ｌａｂｅｌ
・Ｕｓｅｒｎａｍｅ＜ＶＤＮ−ｔａｇ＞＠ｈｏｍｅｎｅｔｗｏｒｋ．ｃｏｍ
・＜ＶＤＮ−ｔａｇ＞Ｕｓｅｒｎａｍｅ＠ｈｏｍｅｎｅｔｗｏｒｋ．ｃｏｍ
・＜ＶＤＮ−ｔａｇ＞＠ｈｏｍｅｎｅｔｗｏｒｋ．ｃｏｍ
の通りであり得る。さらに、ＵＲＩは、以下の表：
表Ｉ
【００４４】
【表１】
2008092579.tif 000003
表ＩＩ
【００４５】
【表２】
2008092579.tif 000004
に、例示されるようなメモリの中にコード化され得る。
【００４６】
コールに関連する一意的なＩＤ情報は、ユーザおよびＵＥデバイス、および／またはインスタンス識別子（ＩＤ）と関連するＧＲＵＵを備え得る。ここで、インスタンスＩＤは、デバイスとともに提供されるＩＭＥＩ、ＩＭＥＩソフトウェアバージョン（ＩＭＥＩＳＶ）、ＭＡＣアドレスまたは一意的なＬａｙｅｒ−２アドレス、電子シリアル番号（ＥＳＮ）、モバイルソフトウェア端末識別子のようなソフトウェアＩＤ、ユニバーサルに一意的な識別子（ＵＵＩＤ）、およびモバイル識別番号（ＭＩＮ）のうちの少なくとも１つを含み得る。ブロック２０２に示されるように、タイマは、コール情報の少なくとも一部分をモニタするために使用されるＵＥデバイス上で開始され得る。特に、タイマは、特定のコールリファレンス番号が、生成され、ネットワークノードに転送されてからの経過時間をモニタするために、インプリメントされる。ネットワークノードで、リクエストＵＲＩを有するＳＩＰインバイトメッセージは、ＶＤＮリクエストとして処理される。したがって、ＶＤＮ／ＩＭＲＮのプールから選択されたＶＤＮ／ＩＭＲＮは、コールリファレンス番号に対して動的に関連付けられる。ここで、ＩＭＲＮは、コール情報の少なくとも一部分、例えば、ＳＩＰ対話ＩＤ、インスタンスＩＤ、および／またはＧＲＵＵにマッピングされる（ブロック２０４）。また、タイマは、動的に割り当てられたＩＭＲＮと関連付けられた有効期間変数をモニタするために、ネットワークノードで開始され得る。その後、動的に割り当てられたＩＭＲＮは、代替ドメインおよび利用可能なＲＡＴ情報とともに、適切なＳＩＰ３８０応答メッセージを用いて、ＵＥデバイスに提供される。ＵＥデバイスで、動的に割り当てられたＩＭＲＮを受信すると、コールリファレンス番号と関連する経過時間は、その番号が古くなっていないことを確実にするようにモニタされる（ブロック２０６）。その経過時間が選択条件、例えば、有効期間の値の範囲内であることを満足している場合、動的に割り当てられたＩＭＲＮは、そのＵＥデバイスによって受け入れられる（ブロック２０８）。適切な設定は、次いで、動的なＩＭＲＮを用いて、ＵＥデバイスによって開始され、これによって、受け入れられたＩＭＲＮは、ネットワークノード上で終了するので、ネットワークノードに戻される。ネットワークノードで、ＩＭＲＮを受信すると、その有効期間変数は、それがタイムアウトしないことを確実にするように、モニタされる。その後、動的に割り当てられたＩＭＲＮと関連するコールされたパーティの番号、ＧＲＵＵおよび／またはインスタンスＩＤ（すなわち、一意的なＩＤデータ）が、コールレグ間の適切なドメイン間接続を作ることによって、コールを続けるために利用される（ブロック２１０）。一つのインプリメンテーションにおいて、動的なＩＭＲＮは、オプションとして、ＩＭＲＮのプールに戻され得る。ここで、この動的なＩＭＲＮは、それが再使用されるか、あるいは将来の使用のために利用可能になるまで、特定の期間にわたって隔離され得る（ブロック２１２）。
【００４７】
ここで、図２Ｂおよび図２Ｃを参照すると、上記の方法論のデバイス中心およびネットワーク中心の部分が、例示的な実施形態において、追加的に詳細に示される。ブロック２２２で、ＵＥデバイスの適切なロジックは、コールおよび（ＶＤＮを戻すように知らされている）ＤＴＲ−ＵＲＩに関連するコール情報を、図１のＡＳ  １１４−ＮのようなＶＣＣノードに提供するように動作可能である。ＳＩＰ３８０応答を介して動的に割り当てられたＶＤＮ／ＩＭＲＮおよびドメイン／ＲＡＴ情報を受信することに応答して、ＵＥデバイスは、そのコールと関連するコールリファレンス番号が、有効な状態に留まっていることを確認するように動作可能である（ブロック２２４）。確認すると、ＵＥデバイスは、その後、ＶＤＮ／ＩＭＲＮをＶＣＣノードに提供し、進行中のコールレグを設定し、異なるドメインにある既存のコールとの連続性を維持する（ブロック２２６）。
【００４８】
ネットワークノード、例えば、ＡＳ  １１４−Ｎでの動作に関して、ＳＩＰインバイトメッセージを介して、リクエストＵＲＩを、ＧＲＵＵおよび／またはインスタンスＩＤ情報などとともに受信すると、そのノードで適切なロジックが、そのデータベースを質問し、幾つかの確認を実行する。確認は、ユーザがＶＣＣサービスを取得することが可能であるかどうかを決定するために行われ得る。別の確認は、ＵＥデバイスから受信した一意的なＩＤ情報が、ネットワークノードのデータベースに存在するかどうかに関し、一例は、受信された一意的なＩＤが、既に進展中のＳＩＰ対話を有し、存在する場合、動的であり得るＶＤＮ／ＩＭＲＮが、割り当てられ、その受信された一意的なＩＤ情報に対応する進行中のコールと関連付けられることである。これらの処理は、ブロック２５２で例示される。その後、動的なＶＤＮ／ＩＭＲＮおよび代替ドメイン／ＲＡＴ情報が、適切なＳＩＰ３８０応答メッセージを介してＵＥデバイスに提供される（ブロック２５４）。以前に暗示したように、ＳＩＰ３８０メッセージのボディは、ＸＭＬでコード化され、ＲＡＴに関連する情報の様々な断面を、ＵＥデバイスに利用可能な代替ＣＳまたはＰＳドメインとともに提供し得る。一つのインプリメンテーションにおいて、このような情報は、例えば、ＵＥデバイスのロケーションに基づいて、さらに調節され（ｍｏｄｕｌａｔｅｄ）得る。代替として、優先および／または禁止ネットワークに関連する加入者プロファイルが、ネットワークノードでサービスロジックに利用可能な場合、ＳＩＰ３８０応答メッセージが、適切にコード化される前に、追加のフィルタリングが行われ得る。動的なＩＭＲＮが、ＵＥのＶＣＣコールレグ設定の一部として、ネットワークノードに戻されるとき、そのネットワークノードは、戻されたＩＭＲＮを、ＶＣＣコールレグを進行中のコールに対してリンクするために以前に生成されたＧＲＵＵ／インスタンスＩＤ記録に対して相関付ける（ブロック２５６）。また、ネットワークノードは、本明細書で上述されたように、受信されたＩＭＲＮがタイムアウトしないことを確認する適切なロジックを含み得る。  
【００４９】
以上に基づいて、ネットワークノードでのＶＣＣアプリケーションロジックは、ＳＩＰインバイトメッセージを介して受信されるリクエストＵＲＩを検査して、リクエストＵＲＩフィールドに含まれるＵＲＩがＶＣＣ呼び出しと関連付けられるかどうかを決定する機能性を好ましくは含むことを当業者は、理解する。ＶＣＣ呼び出しと関連付けられる場合、リクエストＵＲＩのコンテンツは、コール完了のために、ＶＣＣノードによって利用されない。その代わりに、アプリケーションロジックは、ＳＩＰヘッダのインバイトに含まれる対話情報、または以前に記載されたようなボディに含まれる対話情報に基づいて、受信されたユーザＩＤまたはＧＲＵＵに対する進行中のコールがあるかどうかを確認する。一つのインプリメンテーションにおいて、進行中のコールがない場合、受信されたＳＩＰインバイトメッセージは、拒絶され得る。以前に詳細に記載されたように、進行中のコールが存在するという決定に基づいて、動的なＩＭＲＮ／ＶＤＮは、ＧＲＵＵに割り当てられる。この進行中のコールは、コール情報の他の断片、例えば、Ｐアサートされた（Ｐ−Ａｓｓｅｒｔｅｄ）ＩＤパラメータ、Ｂ番号などとともに、ＧＲＵＵにマッピングされ得る。さらに、ＶＣＣアプリケーションロジックは、ＵＥデバイスのロケーションを識別するために、Ｐアクセスネットワーク情報ヘッダを検査する機能性を提供され得る。さらに、ロケーション情報はまた、ネットワークベースのロケーション情報を用いて入手され得るか、あるいはまたユーザによって入力され、ＶＣＣアプリケーションに通信され得る。ＵＥデバイスのロケーション情報と、ＤＳＦ（ＦＥ−Ｄ）から入手され得るＣＳネットワーク内のそのデバイスの状態とを用いて、アプリケーションロジックは、ＵＥデバイスによって使用するＲＡＴを適切に設定または選択し得る。コールハンドオーバがなされるアクセス技術は、ＩＥＥＥ  ８０２．１１；ＩＥＥＥ  ８０２．１１ａ；ＩＥＥＥ  ８０２．１１ｂ；ＩＥＥＥ  ８０２．１１ｇ；３ＧＰＰ−ＧＥＲＡＮ−ＣＳ；３ＧＰＰ−ＧＥＲＡＮ−ＰＳ；３ＧＰＰ−ＵＴＲＡＮ−ＦＤＤ；３ＧＰＰ−ＵＴＲＡＮ−ＴＤＤ；ＡＤＳＬ；ＡＤＳＬ２；ＡＤＳＬ２＋；ＲＡＤＳＬ；ＳＤＳＬ；ＨＤＳＬ；ＨＤＳＬ２；Ｇ．ＳＨＤＳＬ；ＶＤＳＬ；ＩＤＳＬ；３ＧＰＰ２−１Ｘ；３ＧＰＰ２−１Ｘ−ＨＲＰＤ；ＤＯＣＳＩＳ；ＥＶＤＯ、ＣＤＭＡ１Ｘ、ＷｉＭＡＸなどのような周知の技術と、さらに従来知られていない有線アクセスおよび無線アクセスのタイプの任意のものとを含み得るが、これらに限定されない。
【００５０】
本特許開示の目的のために、ＸＭＬでコード化されたボディを含むＳＩＰ３８０応答メッセージの例が、以下：
表ＩＩＩ
【００５１】
【表３】
2008092579.tif 000005
に示される。
【００５２】
他のＸＭＬコード化スキームにおいて、様々な追加エレメントもまた、緊急セッション、オペレータ構成可能なテキストメッセージなどを表示するために提供され得る。
【００５３】
全体的に、ＶＣＣアプリケーションロジックは、例示的なＳＩＰ３８０応答メッセージのＸＭＬボディにおいて、以下のエレメント：
−代替サービスのパラメータを設定する＜ａｌｔｅｒｎａｔｉｖｅ−ｓｅｒｖｉｃｅ＞エレメント、
−ＶＣＣ呼び出しのパラメータを設定する＜ＶＣＣ  Ｉｎｖｏｃａｔｉｏｎ＞エレメント、
−「ＶＤＮ」にＶＤＮ番号を設定する＜ＶＤＮ＞エレメント、
−代替ドメインとして、ＣＳドメインを表示する「ｃｓ」を設定する＜ＣＳ＞エレメント、
−緊急コールであったことを表示する「緊急」を設定する＜ｔｙｐｅ＞チャイルドエレメント、および
−オペレータ構成可能な理由を、例えば、テキストメッセージで設定する＜ｒｅａｓｏｎ＞チャイルドエレメント
を含んで動作可能である。
【００５４】
ＵＥデバイスとホームＩＭＳネットワークのＶＣＣネットワークノードとの間のメッセージフローは、デバイスの能力と、使用されるネットワークの特徴およびプロトコルとによって、幾つかの他の適切なネットワークインフラエレメントを仲介され得、また幾つかの方法でインプリメントされ得ることは、当業者によって認識されるべきである。典型的には、メッセージフローは、ＵＥデバイスとそのホームＩＭＳ  ＶＣＣ／ネットワークノードとの間に配置されたモバイルスイッチングセンタ（ＭＳＣ）および媒体ゲート制御機能（ＭＧＣＦ）エレメントのようなネットワークエレメントで仲介され得る。また、ＭＧＣＦノードとＶＣＣノードとの間に配置された質問コールセッション制御機能（Ｉ−ＣＳＣＦ）ノードおよびサービシングＣＳＣＦ（Ｓ−ＣＳＣＦ）ノードのような追加のＩＭＳ制御プレーンノードも存在し得る。以下に、ＳＩＰメッセージ伝達および動的に割り当てられたＩＭＲＮが、ＵＥデバイスによって発信されたコールに対するコールルーティング／連続性を実行するために利用されるメッセージフローの例示的なインプリメンテーションが示される。
【００５５】
図３Ａは、一実施形態に従って、リクエストＵＲＩフィールド内にドメイン転送ＵＲＩを有するＳＩＰインバイトメッセージを用いることによって、コール連続性を実行するためのメッセージフロー図３００Ａを示す。機能性のＣＳドメインモードおよびＩＭＳドメインモードを有する例示的なＵＥデバイス３０２は、ネットワークノード３０８へのＳＩＰインバイトメッセージ３１２を生成するように動作可能である。ここで、インバイトメッセージは、ＧＲＵＵおよび／またはインスタンスＩＤ情報に加え、リクエストＵＲＩ内のＤＴＲ−ＵＲＩと、コールリファレンスアイデンティティまたは番号のような適用可能なコール情報と、あるいは（例えば、ＳＩＰヘッダにおけるインバイト内の対話情報、またはインバイトのボディに含まれる対話情報に基づく）ＳＩＰ対話ＩＤなどを含む。コールリファレンス番号と関連する有効期間変数をモニタするために、適切なタイマメカニズム３１０が、ＵＥデバイスで開始され得る。この動作は、特定の時間枠内に、特定の情報を有するＳＩＰ３８０応答を提供することで知られているので、このタイマは、通常のＳＩＰタイマに加えて、提供され得ることは、理解されるべきである。Ｉ−ＣＳＣＦおよび／またはＳ−ＣＳＣＦノードを介して仲介され得るインバイトメッセージ３１２に応答して、ユーザのホームＩＭＳネットワーク内に配置されたネットワークノード３０８は、上述のように、適切な応答メッセージ（例えば、ＳＩＰ代替サービス３８０応答メッセージ）を確認し、生成して、ポピュレートするために、ＤＴＲ−ＵＲＩロジック３１３を開始するように動作可能である。ユーザがＶＣＣコールすることを許可され、インバイトメッセージが進行中のコールに対してＶＣＣ呼び出しを含むことを確認すると、ネットワークノードは、そのコールにマッピングされた選択ＩＭＲＮを動的に割り当て、ＳＩＰ３８０メッセージ３１６を介して、それをＵＥデバイス３０２に戻す。インバイトヘッドまたはインバイトのボディに含まれる対話情報は、そのコールと相関付けするために使用され得る。適切なタイマメカニズムが、動的に割り当てられたＩＭＲＮと関連する有効期間変数をモニタするために、ネットワークノード３０８で開始され得る（ブロック３１４）。コールリファレンスが、ＵＥデバイスのタイマメカニズムに基づいて、タイムアウトしなかったことを確認した後に、ＳＩＰ３８０応答メッセージ３１６の受信に応答して、ＵＥデバイス３０２は、動的なＩＭＲＮを含むコール設定メッセージ３２０を開始する。これに応答して、ＭＳＣ３０４は、ＭＧＣＦ３０６に向けた初期アドレスメッセージ（ＩＡＭ）３２２を生成する。ＩＭＲＮを含むＳＩＰインバイトメッセージ３２４は、ＭＧＣＦ３０６によって生成され、ネットワークノード３０８に向かい、次いで、ネットワークノード３０８は、コールされたパーティ（図示せず）へのコールを続けるために、ＩＭＲＮ−ＧＲＵＵマッピングを使用する。ネットワークノード３０８は、ＧＲＵＵおよび／またはインスタンスＩＤが見出され得るかどうかを調べるために、その進行中のコールをルックアップするように動作可能である。様々な中間ＳＩＰメッセージおよびリソース割り当て／予約交渉が、ＭＣＧＦ３０６とＳＩＰインバイト３２４に引き続いてコールされたパーティとの間で行われ得ることは、認識されるべきであるが、これらは、本明細書に、特に詳細には記載されない。また、ベアラ経路がＵＥデバイス３０２とコールされたパーティとの間に確立される前に行われる追加のＩＳＵＰメッセージ伝達も、本明細書には、示されない。
【００５６】
ＳＩＰインバイト３２４を介して、動的に割り当てられたＩＭＲＮまたはＶＤＮをネットワークノード３０８で受信すると、タイマメカニズムは、ＩＭＲＮがタイムアウトしたかどうかを確認するために停止され得る（ブロック３２６）。タイムアウトした場合、ＳＩＰインバイトメッセージは、処分され得、コールルーティング処理は、完了され得る。ＩＭＲＮがタイムアウトしていなかった場合、ＣＣＣＦは、当初コールされた番号を用いて、コールレグを設定し得、ＧＲＵＵ−ＩＭＲＮの相関に基づいて、進行中のセッションとそのコールレグをリンクし得る。ＣＣＣＦによってコール相関に対するＩＭＲＮを用いた後に、そのＩＭＲＮは、ＩＭＲＮプールに戻され得る。ここで、隔離タイマが、開始され得（ブロック３２８）、その結果、ある期間経過後に、隔離タイマが、停止されるまで、ＩＭＲＮは、さらなる使用を禁止される（ブロック３３０）。
【００５７】
以前に指摘されたように、デバイス側でのタイマメカニズムはまた、（例えば、タイマメカニズム３１８を用いて）コールリファレンス番号が、タイムアウトしたことを確実にするようにも使用され得る。このリファレンス番号は、ネットワークノードから受信された情報（例えば、動的ＩＭＲＮ）を相関づけるために、ＵＥデバイスによって使用される。同じリファレンス番号が、ネットワークノードから戻って受信される前に、タイマが、満了する場合、ＵＥデバイスは、所定の回数（例えば、５回の試行）コール処理を再び試行し得る。その後、応答が全く受信されない場合、コール手順は、失敗したものとみなされ得る。換言すれば、ＵＥデバイスは、もはや有効でないリファレンス番号を受信する場合、そのリファレンス番号は、処分され得、コール手順は、完了され得る。
【００５８】
図３Ｂは、リクエストＵＲＩフィールドにおいて、ＤＴＲ−ＵＲＩを有するＳＩＰインバイトメッセージを用いることによって、コール連続性を実行するためのメッセージフロー図３００Ｂを示す。ここで、ホームネットワーク３５０における特定の中間ノードが、例示される。上述のフロー図の実施形態３００Ａと同様に、ＵＥデバイス３０２は、Ｉ−ＣＳＣＦ３５２に向かうＳＩＰインバイトメッセージ３５６を生成するように動作可能である。ここで、ＳＩＰインバイトメッセージは、ＧＲＵＵと、ＶＣＣを呼び出すことで知られるＲ−ＵＲＩ内に含まれるＵＲＩとを有する。このインバイトメッセージは、ＳＩＰインバイト３６２のように直接、あるいはＳＩＰインバイトメッセージ３５８および３６０のようにＳ−ＣＳＣＦ３５４を介してのいずれかで、ＶＣＣアプリケーション３０８に伝播される。以前に記載されたように、ドメインおよびＶＤＮ情報を有するＳＩＰ３８０（代替サービス）応答メッセージ３６４は、ＶＣＣアプリケーション３０８によって生成され、Ｓ−ＣＳＣＦ３５４に向かい、次いで、ＳＩＰ応答３６６を介して、ＵＥデバイス３０２に伝播される。ＶＤＮを有するコール設定メッセージ３６８は、ＭＳＣ３０４に提供され、ＭＳＣ３０４は、ＣＳ発信手順３７０を開始する。ＭＳＣ３０４からＭＧＣＦ３０６に向かうＩＡＭメッセージ伝達３７２は、Ｉ−ＣＳＣＦ３５２に向かうＳＩＰインバイト３７４を生成するように動作可能であり、Ｉ−ＣＳＣＦ３５２は、ＶＤＮを有するインバイトメッセージ３８０のように、ＶＣＣアプリケーション３０８に直接伝播され得る。代替として、Ｉ−ＣＳＣＦ３５２は、ＳＩＰインバイト３７６をＳ−ＣＳＣＦ３５４に最初に提供し、次いで、Ｓ−ＣＳＣＦ３５４は、ＳＩＰインバイト３７８をＶＣＣアプリケーション３０８に伝播する。いずれにせよ、一度ＶＤＮが、ＶＣＣアプリケーション３０８で受信されると、適切なコール相関付けが、選択されたドメインにおけるコール連続性を実行するために行われる。
【００５９】
図４は、本特許開示の目的のために、例えば、ＵＥ３０２のような無線ＵＥデバイスとして動作可能な通信デバイスの実施形態のブロック図である。ＵＥ３０２の実施形態は、図４に示される実施形態と同様な配置を備え得るが、ハードウェア、ソフトウェアまたはファームウェアにおいて、図示された様々なモジュールに対して、幾つかのバリエーションおよび改変があり得ることは、本明細書を参照した当業者によって理解される。従って、図４の配置は、本特許開示の実施形態に対して、制限をするものとしてよりも、むしろ、例示的なものとして取られるべきである。ＵＥ３０２の実施形態の全体制御のために提供されるマイクロプロセッサ４０２は、マルチモード通信（例えば、ＣＳドメイン、ＩＭＳのようなＩＰドメインなど）が可能な通信サブシステム４０４に、動作可能なように結合される。通信サブシステム４０４は、一般に、１つ以上の受信機４０８および１つ以上の送信機４１４、ならびに、１つ以上の局所発振器（ＬＯ）モジュール４１０のような関連コンポーネントおよびデジタル信号プロセッサ（ＤＳＰ）４１２のような処理モジュールを含む。通信分野の当業者には理解されるように、通信モジュール４０４の特定の設計は、モバイルデバイスが動作することを意図される通信ネットワーク（例えば、ＣＤＭＡネットワーク、ＧＳＭネットワーク、ＷＬＡＮなど）に依存し得る。しかしながら、特定の設計に関わらず、適切なアクセスインフラ４０５（例えば、セルラ基地局タワー、ＷＬＡＮホットスポットなど）を介するアンテナ４０６によって受信された信号は、受信機４０８に提供され、この受信機は、信号増幅、周波数下方変換、フィルタリング、チャネル選択、アナログデジタル（Ａ／Ｄ）変換などのような一般の受信機機能を実行し得る。同様に、送信されるべき信号は、例えば、ＤＳＰ４１２によって、変調およびコード化を含む処理がなされ、デジタルアナログ（Ｄ／Ａ）変換、周波数上方変換、フィルタリング、増幅、およびアンテナ４１６を介する無線インターフェース上の送信を行うために、送信機４１４に提供される。
【００６０】
マイクロプロセッサ４０２はまた、補助入力／出力（Ｉ／Ｏ）４１８、シリアルポート４２０、ディスプレイ４２２、キーボード／キーパッド４２４、スピーカ４２６、マイク４２８、ランダムアクセスメモリ（ＲＡＭ）４３０、短距離通信サブシステム４３２、および、一般的に参照番号４３３でラベル付けされ、例えば、タイマメカニズムなどの任意の他のデバイスサブシステムのようなさらなるデバイスサブシステムとも、インターフェースし得る。アクセスを制御するために、ＳＩＭ／ＲＵＩＭ４３４もまた、マイクロプロセッサ４０２との通信に提供され得る。一つのインプリメンテーションにおいて、ＳＩＭ／ＲＵＩＭインターフェース４３４は、幾つかのキー構成４４４と、Ｒ−ＵＲＩのような他の情報４４６と、さらに識別および加入者関連データとを有するＳＩＭ／ＲＵＩＭカードとで、動作可能である。
【００６１】
オペレーティングシステムソフトウェアおよび適用可能なサービスロジックソフトウェアは、フラッシュメモリ４３５のような永続的ストレージモジュール（すなわち、不揮発性ストレージ）内に具現化され得る。一つのインプリメンテーションにおいて、フラッシュメモリ４３５は、例えば、コンピュータプログラム（例えば、サービス処理ロジック）４３６用のストレージエリアと、デバイス状態４３７、アドレス帳４３９、他の個人情報マネージャ（ＰＩＭ）データ４４１のようなデータストレージ領域と、全体的に参照番号４４３でラベル付けされた他のデータストレージエリアとのように、異なるエリアに分離され得る。伝送（ｔｒａｎｓｐｏｒｔ）スタック４４５は、１つ以上の適切な無線パケット伝送プロトコルを実行するために提供され得る。さらに、ＤＴＲ−ＵＲＩ生成およびコールハンドオーバ／連続性ロジックモジュール４４８は、本明細書で上述されたように、ＤＴＲ−ＵＲＩおよびコールリファレンスＩＤの生成、有効化、検証、およびＩＭＲＮとの相関を実行するために提供される。
【００６２】
本特許出願の実施形態の動作および構成は、上記の詳細な説明から明らかになるものと考えられる。図示され、記載された例示的な実施形態は、好ましいものとして特徴付けられ得る一方で、以下の請求項に示される本開示の範囲から逸脱することなく、様々な変更および改変が、行われ得ることは、容易に理解されるべきである。
【図面の簡単な説明】
【００６３】
【図１】図１は、回路交換ネットワークインフラおよびＩＭマルチメディアサブシステム（ＩＭＳ）インフラを含むネットワーク環境を示し、この環境において、本特許開示の実施形態が実行され得る。
【図２Ａ】図２Ａは、本特許開示の例示的な実施形態と関連する流れ図を示す。
【図２Ｂ】図２Ｂは、本特許開示の例示的な実施形態と関連する流れ図を示す。
【図２Ｃ】図２Ｃは、本特許開示の例示的な実施形態と関連する流れ図を示す。
【図３Ａ】図３Ａは、リクエストＵＲＩフィールドにおいて、ＤＴＲ−ＵＲＩを有するＳＩＰインバイトメッセージを用いることによって、コール連続性を実行する例示的なメッセージ流れ図を示す。
【図３Ｂ】図３Ｂは、リクエストＵＲＩフィールドにおいて、ＤＴＲ−ＵＲＩを有するＳＩＰインバイトメッセージを用いることによって、コール連続性を実行する例示的なメッセージフローの図を示す。
【図４】図４は、本特許開示の目的のために動作可能な通信デバイスの実施形態のブロック図を示す。
【符号の説明】
【００６４】
１００  ネットワーク環境
３００Ａ、３００Ｂ  メッセージフロー図
３０２  ユーザ装備（ＵＥ）デバイス
３０４  ＭＳＣ
３０６  ＭＧＣＦ
３０８  ネットワークノード
３１０  タイマメカニズム
３１２、３５６  セッション開始プロトコル（ＳＩＰ）インバイトメッセージ
３１３  ＤＴＲ−ＵＲＩロジック
３１６、３６４／３６６  ＳＩＰ３８０メッセージ
３５０  インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク
３０４  モバイルスイッチングセンタ（ＭＳＣ）
３０６  媒体ゲート制御機能（ＭＧＣＦ）
３０８  ネットワークノード、ＶＣＣアプリケーション
３５０  インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク
３５２  質問コールセッション制御機能（Ｉ−ＣＳＣＦ）
３５４  サービシングコールセッション制御機能（Ｓ−ＣＳＣＦ）
３５６、３５８、３６０  ＳＩＰインバイトメッセージ
３６２、３７４、３７６、３７８  ＳＩＰインバイト
３６４  ＳＩＰ３８０応答メッセージ
３６６  ＳＩＰ応答
３６８  コール設定メッセージ
３７０  コール発信手順
３７２  ＩＡＭメッセージ
【図１】
2008092579.tif 000006
【図２Ａ】
2008092579.tif 000007
【図２Ｂ】
2008092579.tif 000008
【図２Ｃ】
2008092579.tif 000009
【図３Ａ】
2008092579.tif 000010
【図３Ｂ】
2008092579.tif 000011
【図４】
2008092579.tif 000012