JP5118208B2 - 無線緊急呼のために音声呼継続性（ｖｃｃ）をサポートする装置と方法 - Google Patents

無線緊急呼のために音声呼継続性（ｖｃｃ）をサポートする装置と方法 Download PDF

Info

Publication number
JP5118208B2
JP5118208B2 JP2010541569A JP2010541569A JP5118208B2 JP 5118208 B2 JP5118208 B2 JP 5118208B2 JP 2010541569 A JP2010541569 A JP 2010541569A JP 2010541569 A JP2010541569 A JP 2010541569A JP 5118208 B2 JP5118208 B2 JP 5118208B2
Authority
JP
Japan
Prior art keywords
emergency
domain transfer
domain
vcc
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010541569A
Other languages
English (en)
Other versions
JP2011512703A (ja
Inventor
エッジ、スティーブン・ダブリュ．
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2011512703A publication Critical patent/JP2011512703A/ja
Application granted granted Critical
Publication of JP5118208B2 publication Critical patent/JP5118208B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1225—Details of core network interconnection arrangements
    • H04M7/123—Details of core network interconnection arrangements where the packet-switched network is an Internet Protocol Multimedia System-type network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1095—Inter-network session transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1225—Details of core network interconnection arrangements
    • H04M7/1235—Details of core network interconnection arrangements where one of the core networks is a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/50—Connection management for emergency connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2242/00—Special services or facilities
    • H04M2242/04—Special services or facilities for emergency applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Alarm Systems (AREA)

Description

米国特許法１１９条に基づく優先権の主張
本出願は、本出願の譲受人に譲渡され、参照により本明細書に組み込まれる、2008年1月4日に出願された「IMPROVED SUPPORT OF VOICE CALL CONTINUITY （VCC） FOR WIRELESS EMERGENCY CALLS」と題する米国仮出願61/019,103号の優先権を主張する。
同時係属出願への参照
本出願は、本出願の譲受人に譲渡され、参照により本明細書に組み込まれる、2007年4月25日に出願された「SYSTEM AND METHOD FOR SUPPORTING VOICE CALL CONTINUITY FOR VOIP EMERGENCY CALLS」と題する同時係属米国出願11/740,220号に関連する。
記述される態様は、VoIP（ボイスオーバーIP：Voice over IP）を使用して掛けられるIPマルチメディア サブシステム（IMS：IP Multimedia Subsystem）緊急呼（例えば、米国のE911またはヨーロッパのE112）のための音声呼継続性（VCC：Voice Call Continuity）に関する。
音声呼継続性（VCC）は、第３世代パートナーシッププロジェクト（3GPP）、および、第3世代パートナーシッププロジェクト2（3GPP2）よって評価されている機能である。VCCの定義は、公的に入手可能な文書である3GPP TS 23.206（「回線交換（CS）とIPマルチメディアサブシステム（IMS）間のVCC；ステージ2」）、および、3GPP TS 23.237（「IPマルチメディアサブシステム（IMS）サービス継続性；ステージ2」）において、3GPPによって示されている。また、VCCの定義は、公的に入手可能な文書である3GPP2 X.S0042-A（「IMSと回線交換システム間のVCC」）において、3GPP2によって示されている。双方のVCCの定義は酷似しており、回線モードをサポートする無線アクセスの使用とVoIPをサポートする無線アクセスの使用との間で無線端末が切り替わる際に、無線端末と任意の他のデバイス（無線または有線）との間で予め確立された音声呼の継続性をサポートする。特に、VCCの使用は、ユーザーがアクセスを切り替える時に（呼に関わるユーザーに著しい遅延と妨害を引き起こし、呼の再確立を不可能にしうる）、呼（例えば、回線モード呼）をリリースすること、および、呼を（例えば、VoIPを使用して）再確立することの必要性を減少させる。
時に回線交換（CS）ドメインと称される回線モードをサポートする無線アクセスネットワークの例は、汎ヨーロッパデジタル移動通信システム（GSM）、広帯域符号分割多元接続（W-CDMA）を使用する万国移動通信システム（UMTS）、および、cdma2000 1Xを含む。VoIPをサポートする無線アクセスネットワークの例は、UMTS W-CDMA、cdma2000 1xEV-DO（高速データ通信の最適化：Evolution Data Optimized）、様々な無線LAN（WLAN）ネットワークを含む。幾つかの場合において、ユーザーの無線端末は、特定の呼のために、（任意の一回につき）回線モードとVoIPとの一方のみの使用を要求されるが、同一のアクセスネットワーク（例えば、UMTS W-CDMA）が、回線モードとVoIPとの両方をサポートできる。
リリース７の3GPPドラフトTS 23.206「CSとIMS間の音声呼継続性（Voice Call Continuity between CS and IMS）」ステージ2で、VCCは、ネットワークにおけるIPマルチメディアサブシステム（IMS）の一部であり、現在の解法を展開する過程で幾つかの異なる名称を割り当てられた新エンティティにおいて、主にサポートされる。3GPP TS 23.206の初期バージョンにおいて、このエンティティはVCC呼継続性制御機能（CCCF）として知られていた。TS 23.206の最新バージョンにおいては、VCCアプリケーション、または、ドメイン転送機能（DTF：domain transfer function）と呼ばれる。3GPP TS 23.237において、サービス集中化および継続性アプリケーションサーバ（SCC AS：Service Centralization and Continuity Application Server）と呼ばれる。3GPP2 X.S0042-A（「IMSと回線交換システム間の音声呼継続性−ステージ2（Voice Call Continuity between IMS and Circuit Switched Systems − Stage 2）」）において、VCCは、VCCアプリケーションサーバ（VCC AS：VCC Application Server）として知られるこれらの3GPPエンティティと類似したエンティティによってサポートされる。3GPP VCC CCCF、3GPP VCCアプリケーション、3GPP SCC AS、3GPP2 VCC ASは全てコーリング無線ユーザーのホームネットワークに配置されるように定義されており、それは、一般的に、リリース７とリリース8の3GPP TS 23.167において定義されるVoIP IMS緊急呼のための現在の解法、および、IMS VoIP緊急呼サポートが訪問先ネットワークに限定される3GPP2X.S0049において定義される類似の3GPP2の解法と互換性がない。これは、VCCの新しい方法が訪問先ネットワークについて定義されない限り、または、IMS緊急呼がホームネットワークを通してルートされない限り、IMS緊急呼のためにVCCをサポートすることが一般的に不可能であろうことを意味する。IMS緊急呼のホームネットワークサポートが、責任問題、訪問国規制条件のサポート、起こりうる潜在的な問題といった数々の新しい問題を引き起こすだけでなく、VoIP緊急呼のための現在の解法を著しく変化させる故に、本発明の例示的な実施形態は、以前の代替を使用する。また、そういったホームネットワークベースの解法は、権限のないユーザーからのIMS緊急呼をサポートすることと互換性がないであろう。
無線緊急呼のためにVCCをサポートする幾つかの代替の解法は、TR 23.824で3GPPによって定義される。これらの解法に付随する幾つかの問題は以下の通りである：（a）サービングネットワークにとって、緊急呼を発信するUEがVCCをサポートするか否かを知ること、および、UEからの新しい緊急呼とUEに対する既存の緊急呼のためのドメイン転送の要求とを区別することは困難である；（b）呼をサポートすることに関わる任意のGMLCに、（a）に関係あるネットワークMSCによって獲得された任意の表示（indication）を運ぶことは、困難、複雑、および／または費用がかかる；そして、（c）UEおよびMSCによる緊急呼のためのVCCのサポートは、新しいインパクトがほぼ無い、または全く無いことを、むしろ要求すべきである。
以下に、態様の基本的な理解を提供するために、１つ以上の態様の簡易化された概要を示す。この概要は、全ての予期される態様の広範囲な概観ではなく、全ての態様のキーや不可欠な要素を識別し、若しくは、任意の、または、全ての態様の範囲を描写することを意図するものではない。唯一の目的は、以下で示される、より詳細な記述への前置として、簡易な形で１つ以上の態様の幾つかのコンセプトを示すことである。
本明細書に記述される態様は、１つ以上の上記問題を取り扱う。例えば、上記のシナリオ（a）は、緊急セットアップ（Emergency Setup）メッセージ中の既存のサービスカテゴリ（Service Category）パラメータを拡大して、UEがVCCをサポートすること、および／または、UEが新しい緊急呼を発信するのか、それとも既存の呼の為にドメイン変換を要求するのかを示すために現在未使用のビットを割り当てることによって対処される。シナリオ（b）は、ネットワークGMLCに複数のSCCP E.164アドレスを割り当て、クエリに関連のあるUEがVCCをサポートするか否か、および／または、クエリが、ドメイン変換が要求される既存の緊急呼に対するものであるか、新しい緊急呼に対するものであるかを区別するために、GMLCに向けられた任意のMAPクエリにおいて異なるE.164アドレスを使用することにより、対処される。さらに、シナリオ（c）は、サービスネットワークに、ドメイン変換を要求するために後にUEによって使用され、ネットワークによって既存の緊急呼のためのドメイン変換の要求として認識されるであろう修正VDN（E.164音声ドメイン変換番号）及びVDI（音声ドメイン変換SIP URI）をUEに提供させることで、対処される。
ある態様において、無線アクセス環境で緊急呼のために音声呼継続性（VCC）をサポートする方法は、ユーザー機器（UE）からの緊急およびドメイン転送情報（emergency and domain transfer information）を含むメッセージをサービスドメインで受信することを備える。方法は、緊急およびドメイン転送情報に基づいて、緊急呼またはドメイン転送の必要性を決定することも備える。さらに、方法は、決定に基づいて、緊急呼発信またはドメイン転送を実行することを備える。
緊急およびドメイン転送情報は、修正VDNまたは修正VDIを備える。あるいは、または追加として、緊急およびドメイン転送情報は、UEが音声呼継続性（VCC）をサポートできることを示す。
メッセージは3GPP DTAP緊急セットアップメッセージであり、緊急およびドメイン転送情報は、随意のサービスカテゴリパラメータにおいて、予備のビットを備える。あるいは、被呼者番号（called party number）パラメータにおいて、メッセージは3GPP DTAP セットアップメッセージであり、修正VDNは、E.164番号である。さらに、メッセージはSIP INVITEであり、修正VDIはSIP URIである。
サービングドメイン（serving domain）は、回線交換（CS）サービスドメイン、またはパケット交換（PS）ドメインである。
さらに、メッセージはサービングドメインのサービングMSCにおいて受信され、サービングMSCはサービングドメインでGMLCにクエリを送信し、クエリは緊急呼発信要求、または、ドメイン転送要求を含み、GMLCは、緊急呼発信、または、ドメイン転送要求に基づいて、サービングMSCにルーティング情報を戻す。さらに、GMLCは２つのSCCP E.164アドレスを有し、サービングMSCは、緊急およびドメイン転送情報が緊急呼発信を示す場合は一方のアドレスに、そして、緊急およびドメイン転送情報がドメイン転送を示す場合には他方のアドレスにクエリを送信する。なお、一方のアドレスは、緊急呼発信を示し、他方のアドレスはドメイン転送要求を示す。また、GMLCは、どのSCCPアドレスがクエリを送信したかに基づいてルーティング情報を決定する。さらに、ルーティング情報はESRDまたはESRKを備える。その上、GMLCへのクエリの送信とGMLCからのルーティング情報の受信は、サービングMSCにとって透明（transparent）である。
上記のクエリはMAP SLRであり、緊急呼発信またはドメイン転送要求は、MAP SLRの随意のパラメータに含まれる。
緊急呼発信の実行は、VCC DTFにおいて緊急呼を固定（anchor）することを含む。また、VCC DTFは修正VDIと修正VDNをUEに戻す。修正VDIと修正VDNはSIP 200 OKメッセージでUEに戻される。
ドメイン転送の実行は、VCC DTFにおいて、UEに対する呼記録を見つけることを含む。さらに、方法は、呼記録が見つからなかった場合、UEにエラーメッセージを戻すことを含む。
サービングドメインがCSサービングドメインの場合、方法は、ドメイン転送を実行するために使用されるISUP初期アドレスメッセージ（IAM：Initial Address Message）においてサービングセルIDまたはMSC IDを含むことをさらに備える。サービスセルIDまたはMSC IDは、IAMにおいて、汎用数列（Generic Digits）パラメータを含む。
別の態様において、少なくとも１つのプロセッサは、無線アクセス環境で、緊急呼のために音声呼継続性（VCC）をサポートするように構成され、緊急およびドメイン転送情報を含むメッセージをユーザー機器（UE）から受信する第1のモジュールを備える。少なくとも1つのプロセッサは、また、緊急およびドメイン転送情報に基づいて、緊急呼発信またはドメイン転送のための必要性を決定する第2のモジュールと、その決定に基づいて、緊急呼発信またはドメイン転送を実行する第3のモジュールを含む。
さらなる態様において、無線アクセス環境で緊急呼のために音声呼継続性（VCC）をサポートするように構成されたコンピュータプログラム製品は、複数のコードを有するコンピュータ可読メディアを備える。コードは、ユーザー機器（UE）からの緊急およびドメイン転送情報を含むメッセージをコンピュータに受信させることが実行可能な、第1のコードセットを備える。コードは、緊急およびドメイン転送情報に基づいて、緊急呼発信またはドメイン転送の必要性をコンピュータに決定させることが実行可能な、第2のコードセットも備える。さらに、コードは、その決定に基づいて緊急呼発信またはドメイン転送をコンピュータに行わせることが実行可能な、第3のコードセットを備える。
別の態様において、無線アクセス環境で緊急呼のために音声呼継続性（VCC）をサポートするように構成された装置は、ユーザー機器（UE）から、緊急およびドメイン転送情報を含むメッセージを受信するための手段を備える。また、装置は、緊急およびドメイン転送情報に基づいて、緊急呼発信またはドメイン転送の必要性を決定するための手段を備える。さらに、装置は、その決定に基づいて緊急呼発信またはドメイン転送を実行するための手段を備える。
さらに別の態様において、無線アクセス環境で緊急呼のために音声呼継続性（VCC）をサポートする装置は、サービスドメインでユーザー機器（UE）から緊急およびドメイン転送情報を含むメッセージを受信する；緊急およびドメイン転送情報に基づいて緊急呼発信またはドメイン転送の必要性を決定する；その決定に基づいて緊急呼発信またはドメイン転送を実行する；命令を実行することができる少なくとも1つのプロセッサを備える。
前述および関連する目的の達成のために、１つ以上の態様は、十分に記述された特徴を以下に備え、請求項において顕著に示される。以下の記述と添付図は、１つ以上の態様の実例となる特徴を詳細に示す。しかしながら、これらの特徴は、様々な態様の原理が用いられる多様な方法のごく一部を示し、本記述は、その様な態様全て、および、それらと同等のものを含むことを意図する。
開示される態様は、開示されるがそれに限定されない態様を描写すために提供される添付図に関連して以下に記述される。なお、同様の指示は同様の要素を表す。
図1は、多数のユーザーをサポートし、本明細書に記述される少なくとも幾つかの態様を実施することができる、例示的な通信システム100の1つの態様の概略図である。 図2は、例示的CDMA通信システムの態様の概略図である。 図3は、HDR送信（HDR transmission）をサポートし、スケジュール送信（scheduling transmission）に適合された、例示的な通信システムの態様の概略図である。 図4は、例示的なアクセス端末の態様の概略図である。 図5は、VCC動作のための参照モデル構造の態様の概略図である。 図6は、IMS（VoIP）緊急呼をサポートするために3GPP TS 23.167で定義されたモデルの観点から、図5の構造500に相補的な参照モデルシステム構造６００概略図である。 図7は、VCC UEとIPケーパブルPSAP（IP Capable PSAP）との間で、ユーザープレーン（U-plane）パスを切り替えるモデルの態様の概略図である。 図8は、VCC UEとCSケーパブルPSAP（CS Capable PSAP）との間で、ユーザープレーンパスを切り替えるモデルの態様の概略図である。 図9は、VCCサポートを伴うIMS緊急呼発信におけるメッセージフローの態様の概略図である。 図10は、VCCサポート伴うCS緊急呼発信におけるメッセージフローの態様の概略図である。 図11は、IMS からCSへのドメイン転送のための手順Aの態様の概略図である。 図12は、IMSからCSへのドメイン転送のための手順Bの態様の概略図である。 図13は、CSからIMSへのドメイン転送のための手順Cの態様の概略図である。 図14は、CSからIMSへのドメイン転送のための手順Dの態様の概略図である。
発明の詳細な説明
様々な態様が図面に関して記述される。以下の記述において、説明の目的のために、数々の特定な詳細は、1つ以上の態様の完全な理解を提供するために示される。しかし、そういった態様が、これらの特定な詳細なしに実施されうることは明白である。
本文書の目的のために、其々が参照によって本明細書に組み込まれる3GPP技術報告書23.826（TR 23.826）、3GPP技術仕様書23.206（TS 23.206）、3GPP技術仕様書23.167（TS 23.167）、3GPP技術仕様書23.271（TS 23.271）、および、下記文書において示される略語が適用される。本文書の目的のために、下記略語が適用および優先される：VCCは音声呼継続性を意味する；I-WLANは相互作用WLAN（Interworking WLAN）を意味する；WLANは無線ローカルエリアネットワーク（Wireless Local Area Network）を意味する；ICCFはIMS CS制御機能（IMS CS Control Function）を意味する；RUAは遠隔ユーザーエージェント（Remote User Agent）を意味する；E-RUAは緊急RUA（Emergency RUA）を意味する；SLRは加入者位置報告（Subscriber Location Report）を意味する。
記述される態様は、無線緊急呼のためにVCCの改善されたサポートを提供する。ある態様において、そのようなサポートは、UEがVCCをサポートすること、および／または、UEが既存の呼に対するドメイン転送を要求しているのか、新しい緊急呼を発信しているのかを示すために、現在未使用のビットを割り当てることにより、緊急セットアップメッセージにおいて既存するサービスカテゴリパラメータを拡張することを含む。例えば、本態様は、SIP INVITE、DTAPセットアップ、またはDTAP緊急セットアップメッセージなどの、呼確立、および／または、登録に関係したメッセージにおけるVCCサポートの明示的な表示を考慮に入れる。別の態様において、無線緊急呼のためのVCCのサポートは、クエリに関連付けられたUEがVCCをサポートするか否か、および／または、ドメイン転送が要求される既存の緊急呼に対するものであるか、新しい緊急呼に対するものであるかを区別するために、ネットワークGMLCに複数SCCP E.164アドレスを割り当てることと、GMLCに向けられる任意のMAPクエリにおいて別のE.164アドレスを使用することを含む。そのうえ、さらなる態様において、無線緊急呼のためのVCCのサポートは、ドメイン転送を要求するために、後にUEによって使用される、および、既存の緊急呼のためのドメイン転送要求としてネットワークによって認識されるであろう修正VDNとVDIをUEに提供するサービスネットワークを含む。これらの態様は、個々に、または、任意の組み合わせで実施されうる。それゆえ、本態様は、発信呼がドメイン転送の要求から区別されることを可能にし、VCCリソースの割り当てを防止し、非VCCケーパブルUE（non-VCC capable UE）からの緊急呼のための使用を別のコードに転送することで、緊急呼発信用の手順の一部を再利用するドメイン転送用の下記手順がさらに信頼性を高めることを可能にし、全体の効率を向上する。
I．無線通信システム
図１を参照すると、記述される装置と方法を実施することが可能な携帯通信システム100の例は、各セルが対応する基地局160A-160Gを含む１つ以上のセル102A-102Gを含み、１つ以上のアクセス端末（AT）106A-106Gは、互いに、または有線電話に、若しくはインターネットなどのパケットベースのネットワークに接続するために、其々に基地局を有する其々のセルにおいて通信する。通信システムは、単一キャリア周波数、または、マルチキャリア周波数を使用する。無線通信システムにおいて、チャネルは、其々の基地局160から其々のAT 106への送信用の順方向リンク（FL）と、其々のAT 106から其々の基地局160への送信用の逆方向リンク（RL）から成り立つ。各リンクは、異なる数のキャリア周波数を組み込む。
AT 106は、遠隔局、移動局、ユーザー機器、または、加入者局としても知られる。さらに、AT 106は、無線チャネルや有線チャネルを通して、例えば、光ファイバや同軸ケーブルを使用して通信する任意のデータデバイスである。AT 106は、さらに、PCカード、コンパクトフラッシュ（登録商標）、外付けまたは内臓モデム、若しくは無線や有線電話を含むが、それに限定されない任意の多種類のデバイスである。また、AT 106は移動または固定である。
データレート制御（DRC：data rate control）、データソース制御（DSC：data source control）、承認（ACK：acknowledge）、逆レートインジケータ（RRI：reverse rate indicator）、パイロットおよびデータ（Pilot and Data）（またはトラフィック（Traffic））チャネルは、逆方向リンク上で送信されるチャネルであることに注意されたい。DRC、DSC、ACK、RRIおよびパイロットはオーバーヘッドチャネルである。逆方向リンクキャリア上に、ただ1つのDSCが存在する時、1つの順方向リンクキャリア、つまり、主（primary）の順方向リンク（FL）キャリアに対して、基地局160に情報が提供される。一方、複数のDRCとACKチャネルがある場合、主と二次（secondary）のFLキャリアに対して、基地局160に情報を提供する。また、各逆方向リンク上に、ATに情報を提供する1つのRRIと1つのパイロットチャネルが存在するであろう。FLキャリアが、トラフィック（またはデータ）チャネル、ACKチャネルなどのオーバーヘッドチャネル、逆電力チャネル（RPC：reverse power channel）および逆アクティビティビット（RAB：reverse activity bit）チャネルを運ぶことも注意される。これらのオーバーヘッドチャネルはATに情報を提供する。
システム100は、HDR標準において明記されるような高データレート（HDR）オーバーレイシステムを有する符号分割多元接続（CDMA）システムである。HDRシステムにおいて、HDR基地局160は、アクセスポイント（AP）またはモデムプールトランシーバ（MPT：modem pool transceiver）としても記述され、HDRアクセス端末106は加入者局として記述される。さらに、各基地局160は、各セクタが少なくとも１つのチャネルを提供する複数のセクタを含む。チャネルは、所与の周波数割り当ての範囲内において、基地局160とAT 106との間の伝達のための通信リンクのセットとして定義される。1つ以上のモデムプールトランシーバ160とのアクティブトラフィックチャネル接続の確立を行うアクセス端末１０６は、アクティブアクセス端末106と呼ばれ、トラフィック状態にあると言われる。1つ以上のモデムプールトランシーバ130とのアクティブトラフィックチャネル接続を確立するプロセス中のアクセス端末106は、接続セットアップ状態にあると言われる。
図2を参照すると、例示的なCDMA通信システムは、ネットワーク104と地理的地域全体に分散した全ての基地局160との間にインターフェースを提供するために基地局コントローラ130を含む。説明を容易にするために、1つの基地局160だけが示される。地理的地域は、一般的に、セル102として知られるより小さい地域に細分される。各基地局160は、その其々のセルにおいて、全ての加入者局106をサービスするように構成される。幾つかの高トラフィックアプリケーションにおいて、セル102は、各セクタをサービスする基地局160を有するセクタに分割される。記述される例示的な実施形態においては、3つの加入者局106A-Cが基地局160と通信している状態で示される。各加入者局106A-Cは、基地局コントローラ130の制御の下、１つ以上の基地局160を通してネットワーク104にアクセスし、または、別の加入者局106と通信する。
最新の通信システムは、複数のユーザーが共通の通信メディアにアクセスできるように設計されている。時分割多元接続（TDMA）、周波数分割多元接続（FDMA）、空間分割多元接続、偏光分割多元接続、符号分割多元接続（CDMA）、および、他の類似した多元接続技法などの数々の多重アクセス技法が、当技術分野において知られている。多重アクセスコンセプトは、複数のユーザーが共通の通信リンクにアクセスすることを可能にするチャネル割り当て方法である。チャネル割り当ては、特定の多重アクセス技法に依存し、様々な形態をとる。例として、FDMAシステムにおいて、合計周波数スペクトルは、多数のより小さいサブバンド（sub-band）に分割され、各ユーザーは、通信リンクにアクセスするために自己のサブバンドを与えられる。あるいは、TDMAシステムにおいて、各ユーザーは、周期的に反復するタイムスロットの間、全周波数スペクトルを与えられる。CDMAシステムにおいて、各ユーザーは、いつでも全周波数スペクトルを与えられるが、符号の使用を通して伝達を区別する。
図３を参照すると、HDR送信をサポートし、複数のユーザーへのスケジュール送信に適応された通信システム120の一例は、パケットネットワークインターフェース（packet network interface）146と、公衆電話交換ネットワーク（PSTN：Public Switched Telephone Network）148とをインターフェースでつなぐ基地局コントローラ130にインターフェースでつながる基地局160を含む。基地局コントローラ130は、システム120において伝達のためにスケジューリングアルゴリズム（scheduling algorithm）を実施するチャネルスケジューラ132を含む。チャネルスケジューラ132はサービス間隔の長さを決定し、その期間に、（最新の受信DRC信号において示されるように）データを受信するための遠隔局の関連瞬間レート（associated instantaneous rate）に基づいて、データが任意の特定の遠隔局に送信される。サービス間隔は、時間において連続的ではないが、nスロット毎に起きる。１つの実施形態によると、パケットの第1の部分は、第1の時間において第1のスロットの間に送信され、第2の部分は、後続時間において4スロット後に送信される。また、パケットの任意の後続部分は、同等の4スロット間隔、すなわち、互いに4スロット離れた、を有する複数のスロットにおいて送信される。ある実施形態によると、データ受信の瞬間レート（Ri）は、特定のデータ待ち行列に関連したサービス間隔の長さ（Li）を決定する。
さらに、チャネルスケジューラ132は、送信のために特定のデータ待ち行列を選択する。次に、送信される関連データ量は、データ待ち行列172から検索され、データ待ち行列172に関連付けられた遠隔局に送信するために、チャネル要素168に提供される。以下で議論されるように、チャネルスケジューラ132は、各待ち行列に関連付けられた重みを含む情報を使用して、後続のサービス間隔において送信されるデータを提供するための待ち行列を選択する。次に、送信された待ち行列に関連付けられた重みはアップデートされる。
示されるように、基地局コントローラ130は、パケットネットワークインターフェース146、公衆電話交換ネットワーク（PSTN）148、および、通信システム内の全ての基地局（簡潔のために、1つの基地局160だけが図示される）とインターフェースする。基地局コントローラ130は、通信システム内の遠隔局と、パケットインターフェース146およびPSTN 148に接続された他のユーザーとの間の通信を調整する。PSTN 148は、標準電話ネットワークを通して、ユーザーとインターフェースする。
基地局コントローラ130は、多数の選択エレメント136（簡潔のために、1つだけが図示される）を含む。各選択エレメント136は、1つ以上の基地局160と1つの遠隔局（図示されない）との間の通信を制御するために割り当てられる。選択エレメント136が所与の遠隔局に割り当てられていない場合、呼制御プロセッサ141は、遠隔局をページ（page）する必要性を通知される。呼制御プロセッサ141は、次に、遠隔局をページするように遠隔局160に指示する。
データソース122は所与の遠隔局に送信される量のデータを含む。データソース122はパケットネットワークインターフェース146にデータを提供する。パケットインターフェース146はデータを受信し、選択エレメント136にデータをルートする。次に、選択エレメント136は、目的の遠隔局と通信している各基地局160にデータを送信する。例示的な実施形態において、各基地局160は遠隔局に送信されるデータを記憶するデータ待ち行列１７２を維持する。
データは、データ待ち行列172からチャネルエレメント168へのデータパケットにおいて、制御ユニット162とDTXコントローラ166の制御下で送信される。ある態様において、順方向リンク上で、「データパケット」は、最大1024ビットのデータ容量で、既定の「タイムスロット（例えば、1.667ミリ秒）」内に目的の遠隔局に送信されるデータ容量を表す。各データパケットに対して、チャネルエレメント168は制御フィールドを挿入する。例示的な実施形態において、チャネルエレメント168は、巡回冗長検査（CRC：Cyclic Redundancy Check）、データパケットおよび制御フィールドの符号化を実行し、一組の符号テールビットを挿入する。データパケット、制御フィールド、CRCパリティビット、符号テールビットは、フォーマットされたパケットを備える。次に、例示的な実施形態において、チャネルエレメント168は、フォーマットされたパケットを符号化し、符号化されたパケット内で記号をインターリーブ（または、再配列）する。例示的な実施形態において、インターリーブパケットはウォルシュ符号（Walsh code）でカバーされ、短いPNIおよびPNQ符号で拡散される。拡散データは、信号を直交変調し、フィルタし、増幅するRFユニット170に提供される。順方向リンク信号は、アンテナを通して順方向リンク（FL）に無線で送信される。
遠隔局106（図1および図2参照）において、順方向リンク信号はアンテナによって受信され、受信機にルートされる。受信機は、信号をフィルタし、増幅し、直交復調し、量子化する。デジタル化された信号は、短いPNIおよびPNQ符号で逆拡散（despread）され、ウォルシュカバーでデカバー（decover）される復調器（DEMOD）に提供される。復調されたデータは、基地局160において行われる信号処理機能、厳密には、デインターリービング（de-interleaving）、復号化、および、CRCチェック機能、の逆を実行する復調器に提供される。復号化されたデータはデータシンク124に提供される。
各加入者局106から送信されたDRC信号は、逆方向リンク（RL）チャネルを通して移動し、RFユニット170に結合された受信アンテナを通して、基地局160で受信される。例示的な実施形態において、DRC情報は、チャネルエレメント168で復調され、基地局コントローラ130に位置するチャネルスケジューラ132、または、基地局160に位置するチャネルスケジューラ174に提供される。第1の例示的な実施形態において、チャネルスケジューラ174は基地局160に配置される。代替の実施形態において、チャネルスケジューラ132は、基地局コントローラ130に配置され、基地局コントローラ13０内の全ての選択エレメント136に接続される。
本方法と装置で実行されるステップは、ある態様において、1つ以上のプロセッサを含む制御ユニット162によって実行される命令として、基地局160のメモリ163に記憶される。
図4を参照すると、ある態様において、ユーザー機器（UE）（3GPPのコンテキストにおいて）、または、アクセス端末（AT）（3GPP2のコンテキストにおいて）106は、送信回路構成264、受信回路構成408、スロットル制御（throttle control）306、復号処理ユニット258、処理ユニット302、キャリア制御ユニット412、メモリ416を含む。スロットル制御ユニット306は、上に図示されたそれらなどの、少なくとも一組のスロットルルールを実施する。スロットルルールはRL上で送信電力を制御する手段と方法を提供する。
本方法と装置において実行されるステップは、ある態様において、プロセッサユニット302によって実行される命令として、モバイルユニット106のメモリ416に記憶される。
II．構造参照モデル（Architecture Reference Model）
下記の議論において、態様は、3GPP構造参照モデルのコンテキストに主に記述されであう。しかし、開示される情報を用いて、当業者は、3GPP2ネットワーク構造、または、別のネットワーク構造において、これらの態様の使用および実施に容易に順応することは理解される。
図5を参照すると、ある態様において、IMS緊急呼のためのVCCサポートの参照モデルシステム構造500は、回路交換（CS）アクセスドメイン502と、インターネット プロトコル マルチメディア サブシステム（IMS）アクセスドメイン504との両方を含む3GPP実施のために図示される。構造500において、緊急呼セッション制御機能（E-CSCF：Emergency Call Session Control Function）506とドメイン転送機能（DTF）508は、訪問先IMSネットワーク510に存する。ドメイン転送機能（DTF）508は、VCCアプリケーション、VCC呼継続性制御機能（CCCF）、VCCアプリケーションサーバ（VCC AS）、または、サービス集中化および継続性アプリケーションサーバ（SCC AS）とも呼ばれる。訪問先ネットワークP-CSCF（モデルの一部でもある）は、この図に示されない。ユーザー機器（UE）512がローミングしていない時、ホームIMSネットワークは訪問先IMSネットワーク510になる。
一般的に、ドメイン固有のVCCケーパブルアップリンク（UL）514と516を使用する時、緊急呼のためのドメイン転送手順は、アクティブ音声セッションを維持している間に、回路交換（CS）ドメイン502と、インターネットプロトコル（IP）ベースのドメイン504との間で、音声呼継続性（VCC）を可能にする。最初と後続の転送を含むVCC加入者呼に関連した全てのドメイン転送手順は、ドメイン転送機能（DTF）508によって、訪問先IMSネットワーク510において実行され、制御される。
図5で示されるように、スタティックな固定技法（anchoring techniques）は、セッション確立後、DTF 508において、VCCケーパブルUE 514と516を使用して、VCC加入者音声呼用の第3者呼制御（3 pcc）機能を確立するために用いられる。DTF 508は、訪問先E-CSCF 506において、初期フィルタ標準（iFC：Initial Filter Criteria）の実行を開始、または、終了することの一部として引き起こされる。DTF 508は、ルーティング３pcc機能を用いて、VCC UE 514と516を使用して掛けられるVCC加入者の音声呼のシグナリングパスにDTF 508自体を挿入する。
発信音声セッションに関して、DTF 508は、ユーザーからのアクセスレグ（Access Leg）を終了し、公衆安全応答ポイント（PSAP：Public Safety Answering Point）などの遠隔端（remote end）に向けて遠隔レグ（Remote Leg）を確立する。例えば、CSアクセスドメイン502において、VCCおよびCSケーパブルUE 514は、訪問先CSネットワーク520の訪問先モバイル スイッチング センタ（VMSC）517へのCSシグナリング アクセス パスを有し、それはメディアゲートウェイ制御機能（MGCF）522を通って、後にDTF 508によって遮断されるE-CSCF 506に向かう。ベアラパス（bearer path）がVMSC 517からメディアゲートウェイ（MGW）522を通して遠隔エンドに向かうことは注意されるべきである。さらに、例えば、IMSドメイン504において、VCCとIMSまたはパケット交換（PS）ケーパブルUE 516は、後にDTF 508によって遮断されるE-CSCF 506へのIMSまたはPSシグナリング アクセス パスを有する。ベアラパスがUE IMS 516から遠隔エンドにつながることは注意されるべきである。
幾つかの例において、CSアクセス502に関して、メディアゲートウェイ制御機能（MGCF）518は、CSドメイン502からの緊急呼発信、またはCSドメイン502からの新しい緊急呼発信を使用するパケット交換（PS）からCSへのドメイン転送の場合に、ISDNユーザー部（ISUP：ISDN User Part）ID／アクセス管理（IAM：Identity and Access Management）メッセージ中で受信された情報から必要な情報をSIP INVITE中に適切に置くと仮定される。
上記のCSアクセス図502は、MGCF 518とE-CSCF 506との間のセッショパス内のコンポーネント全てを示すわけではない− 例えば、IMSでパケット交換インターフェース（PSI：Packet Switching Interface）のルーティングを処理するI-CSCF（Interrogating Call Session Control Function）である。
図６を参照すると、参照モデルシステム構造600は、IMS（VoIP）緊急呼をサポートするために3GPP TS 23.167において定義されたモデルの観点から、図5の構造500に相補的である。この図において、VCC DTF 504は、インターフェースによってE-CSCF 506に加えられる。緊急呼は、VCC DTF 504において固定されるであろう。さらに、位置サポートは訪問先ネットワークにおいて位置検索機能（LRF：Location Retrieval Function）602で固定され、PSAPはドメインの任意の変化に続く同じLRFから、アップデートされた位置推定(location estimate)を取得し続けることができる。このLRF 602はアンカLRF（anchor LRF）と呼ばれる。構造600がプロキシCSCF（P-CSCF）604およびサービングCSCF（S-CSCF）606をさらに明確に含むことに注意されたい。
III．VCCサポートのネゴシエーション：
TS23.206で定義される標準VCC（normal VCC）について、ネットワーク（例えば、CSCFおよびCMSC）は、HSS/HLRに記憶される、ユーザーの加入ベースの情報（すなわち、供給されたiFCおよびCAMEL加入）からユーザーのVCCケーパビリティを知る。UEは、スタティックに供給されるVDN（E.164音声ドメイン転送番号：Voice Domain Transfer Number）とVDI（音声ドメイン転送SIP URI：Voice Domain Transfer SIP URI）を使用する。
IMS緊急呼に対するVCCのために、訪問先ネットワークは、ユーザーのVCCケーパビリティ（VCC capability）を知る必要がある。例えば、UEがドメインを変える時、旧ドメインと新ドメインがVCCをサポートするために共同して作用するか否かについて、ローミング状態では判断できず、それ故、既存の呼が継続できるか否かについて知りえないため、VCCサポートの任意のネゴシエイトなしでは、VCCをサポートすることは難しい。下記の議論において、IMS緊急呼に対するVCCサポートは、訪問先ネットワークにおいて提供されるとみなされる。
III．A．UEがVCCケーパブルであることを伝える方法
幾つかの例において、UEがVCCケーパブルであることを伝える装置と方法は、任意の下記の代替を含む：
（a）訪問先ネットワークが、UEにとってホームネットワークである場合、ユーザーについての加入情報からUE VCCケーパビィティを発見する。
（b）訪問先ネットワーク（例えば、E-CSCF）は、全てのUEがVCCケーパブルであると仮定する（任意の特定UEが実際にそうであろうとなかろうと）。
（c）訪問先ネットワーク（例えば、E-CSCFおよびGMLC）は、全てのUEがVCCをサポートすると仮定される特定のネットワークのID、若しくは、VCCをサポートすると仮定される特定のUE（例えば、ローミングパートナーに属する）のIDの内の一方で構成される。
（d）UEは、呼の確立、および／または、登録に関係するメッセージに情報を含む − 例えば、SIP INVITE、DTAPセットアップ、DTAP緊急セットアップメッセージにおいてである。緊急セットアップメッセージの場合、随意のサービスカテゴリIE内の幾つかの未使用のビットがこの為に使用される。− 例えば、以前に未使用の2つのビットは、VCCドメイン転送からのVCCサポートを有する呼発振とVCCサポートを有さない呼発信とを区別するために割り当てられる。別の代替は、緊急セットアップメッセージではなく、標準のセットアップメッセージを送信することであり、標準のセットアップメッセージは、異なる被呼者番号が、緊急呼を示し、VCCをサポートし、ドメイン転送と呼発信を区別するために使用される。そういった番号はグローバルに定義され、および／または、UEは、特定のネットワーク固有の番号で構成され、若しくはそ、の代わりに下記に示されるように、ドメイン転送固有の被呼者番号が修正VDNとしてUEに戻される。
代替（a）は、PS（パケット交換）ドメインにおいて発信された緊急呼に適用可能であり、UEがローミングしてない場合（すなわち、ホームネットワークによってサービスされている場合）、3GPP TS 23.206に記述されるように、標準VCCサポート（非緊急呼用）のために使用されるVCCケーパビリティ発見と同一メカニズムを使用する。
代替（b）を用いると、訪問先ネットワークは、UEがVCCケーパブルであると仮定し、緊急呼が発信された時にVCCリソースを割り当てる。次に、VCCリソースは、VCCケーパブルでないUEのために浪費される。PSドメインで発信された緊急呼について、そのような呼の数は一般的に、PSドメインに全てのIMS呼の内の非常に小さい割合であるため、浪費は少量である。加えて、もし代替（a）が代替（b）と組み合わせられると、ホームネットワークではない場合にのみ、訪問先ネットワークは、UEがVCCケーパブルであるとみなし、浪費はさらに削減される。しかし、CS発信緊急呼についてはほとんどのCS緊急呼は、少なくとも最初は、VCCをサポートすることができない古いUEから来るため、より高レベルの浪費になりうる。
代替（c）を用いると、特定のオペレータは、規定のローミング協定（roaming agreement）の一部として、別のオペレータに属するUEにVCCサポートを提供することに同意する。
代替（d）を用いると、訪問先ネットワークは、UEに、そして場合によってはIP-CANに多少のインパクトという犠牲を払って、UEサポートであるか非サポートであるかを確かなものとすることができる。代替（d）は、また、ドメイン転送を実行するために送られるメッセージと、緊急呼を発信するために送られるSIP INVITEまたはDTAP緊急セットアップメッセージとを区別する可能性を与える。
代替（a）、（b）、（c）は、緊急呼および非緊急呼の両方に対して、UEの見地から、共通VCC解法を可能にすることが望まれるUEに新しいインパクトを加えないようにする。
III．B．訪問先ネットワークがVCCケーパブルであることを伝える方法
幾つかの例において、UEに訪問先ネットワークがVCCケーパブルであることを伝え、VDNとVDIを転送するために、下記代替が可能性をもつ。
（e）UEは、システム同報メッセージから、訪問先ネットワークのVCCケーパビリティ（そしてVDNおよびVDI）を発見する。
（f）UEは、緊急呼（ローカル緊急呼も含む）に関係する情報を提供する役割がある訪問先ネットワークにおいて、DHCPを使用して、またはサーバからのHTTPやHTTPSを使用して、訪問先ネットワークのVCCケーパビリティと、必要な場合は、VDNおよびVDIを見つける。
（g）ホームネットワークは、緊急呼のためにVCCをサポートすることで知られるネットワークに関係するUE、またはUICCに、情報をダウンロードする。例えば、ホームネットワークは、緊急呼のためにVCCをサポートする全ての既知ネットワークのMCCとMNCをUEに提供する。そういったネットワークによるVDNおよびVDIの使用などの追加情報も提供される。
（h）VCCのサポート、および、任意のVDNまたはVDIを伝えるためのSIPメッセージとパラメータの使用（例えば、呼セットアップまたはSIP200 OKメッセージの使用の後のUE加入／通知）
代替（e）はUMTS、GPRS、GSMネットワークに適当であり、WLANに適当でありうる。
CS発信呼ではなくIMSに適用可能な代替（f）は、訪問先ネットワークにおいて、幾つかのサーバからUEへのローカル緊急番号の供給と組み合わされる。このサーバのアドレスは、訪問先ネットワークの既知のドメイン名と幾つかの固定ユーザー名を含む幾つかの既知のFQDN（例えば、「emergency-support@<訪問先ネットワークドメイン>」）上で、DHCPまたはDNSクエリの一方を使用してUEによって獲得される。変形として、VCCケーパビリティ（そして、必要であれば、VDNおよびVDIアドレス）は、UEがP-CSCF／DNSサーバアドレスを見つけるためにDHCPを使用する場合直接、信号で送られる。
代替（g）は、全てのUEに対して有効であり、ホームネットワークとUEとの間でプロトコル拡張（protocol enhancement）を含む。
代替（h）は、緊急呼がIMSにおいて発信される時に利用可能であり、呼がCSにおいて発信された時にも利用可能である。
IV．ドメイン転送
ドメイン転送は、TS23.206に定義されるように、標準VCCのドメイン転送に酷似した方法で発生する。図7と図8はTS 23.206の図6.4.1.3-1と6.4.1.3-2に基づいており、図7と図8は、IPケーパブルPSAPとCS（PSTN）ケーパブルPSAPへのIMS緊急呼のためのユーザープレーンの切り替えを、それぞれ、図示する。幾つかのエレメント（例えば、I-CSCFおよび、場合によっては、CSドメインアクセスの場合のI-CSCFとE-CSCFとの間のRUAまたはCSAF）は、双方の図から省かれ、または省かれうることに注意されたい。
Ｖ．修正VDNおよびVDI
記述された態様は、VCCを達成するためのVDNとVDIを修正する装置と方法をさらに含む。特に、VDNおよびVDIは、緊急呼認識と処理のコンテキストにおいて、ドメイン転送を可能にするために修正される。VDNの場合、VPLMNは修正VDNを割り当て（そして、VCCサポートのネゴシエーションに関して上述されたメカニズムの１つを介してそれをUEに提供する）、修正VDNはMSCによって緊急番号として認識され、それによって、IMSからCSへのドメイン転送に関して以下に示されるように、手順B（図12）、MAPクエリをGMLCでトリガする。SCCPシグナリング移送のための異なるGMLC E.164アドレスは、MAP SLRが（新しい緊急呼に対立するものとして）ドメイン転送が要求される既存の緊急呼に関連付けられたことを暗黙的にGMLC に（SCCPプロトコル層を介して）通知するために、この修正VDNと連携してMSCにおいて構成される。信号物理GMLCは、新しい発信緊急呼のためのMAP SLRとドメイン転送が要求される既存の緊急呼のためのMAP SLRが両方とも同一のGMLCに到達することを確実にするために、幾つかのSCCP E.164アドレスに関連付けられる。この態様のさらなる詳細は、「IMSからCSへのドメイン転送−手順B」（図12）に関して、以下の詳細な手順の記述で提供される。
修正VDIの場合、URI（例えば、SIP URI）はVPLMNによって割り当てられ、若しくは、既存の緊急呼のためのドメイン転送の要求を示すとグローバルに定義される。これは、以下に記述されるCSからIMSドメインへの転送手順のために使用される。この態様は、さらに、UEに提供されるA PLMN割り当てVCIを含む（例えば、「VCCサポートのネゴシエイト」に関して、上述された任意の方法を使用して）。
修正VDNおよびVDIを使用することの重要性（および、既存のVDNおよびVDI用語を保持する理由）は、UEの見地から、ドメイン転送が、TS 23.206において定義された標準VCCに関する限りにおいて、（ほぼ、または完全に）行われることである。
VI．手順
下記手順において、VDNおよびVDIは、訪問先IMSネットワーク（例えば、訪問先ネットワークにおいてスタティックである）によって割り当てられると仮定され、従って、TS 23.206に定義される標準VCCに関する限りではUEにおいて構成されない。
VI．A．IMS緊急呼発信
緊急呼発信は、TS 23.167において定義されるように発生する。ただしVCCのネゴシエイトされた使用を加えるために幾つかの変更を伴う。特に、任意のドメイン転送に続く音声呼の継続性に加え、位置サポートの継続性を保つために、訪問先ネットワークのE-CSCFは、位置を獲得または確認（verify）し、目的地PSAPを選択するために、LRFを引き起こす前にVCC DTFにSIP INVITEを（IMS緊急呼のために）送信する必要がある。次に、VCC DTFは入呼レグを固定し、E-CSCFを通してPSAPに新しい出呼レグを発信する。VCC DTFからのSIP INVITEの受信を受けて、E-CSCFは、TS 23.167に定義されるように通常位置特定とルーティングを実行し、IPを通して、または、MGCFおよびPSTNを通して、呼をPSAPに転送する。これはDTFからの出呼レグの一部であるE-CSCFという結果になる。つまり、このことは、LRFが任意のドメイン転送に続く出呼レグに関連し続ける。従って、ドメインの任意の変更に続くアクセスネットワークへの変更に関する新しい情報でアップデートされるとすれば、提供された位置の継続的サポートを提供することが可能である。
図９を参照すると、呼発信手順900の1つの態様は、下記ステップと動作を含む。
1．ユーザーが緊急呼を開始する。
2． UE 902がローミングしている場合、または、UEがローミングしておらず、IMSが登録していない場合、UEは、TS 23.167に記述されるように、それが必要な資格（credential）を含む場合、訪問先ネットワークP-CSCF 904およびホームネットワークS-CSCF（図示されない）と緊急登録手順を実行する。
3．UE 902は、訪問先ネットワークP-CSCF 904に、緊急表示と共にINVITEを送信する。INVITEは、UEが有する任意の位置オブジェクトを含む。INVITEは、例えば、UEについてのアドレスや番号（例えば、公衆ユーザーSIP URIおよび電話URI）などの識別情報を含む。INVITEは、UEがVCCをサポートすることと、ドメイン転送の要求に対立するものとしての呼発信であることを示す。
4．P-CSCF 904はSIP INVITEをE-CSCF 908に送る。
5．UE 902によるVCCサポートの仮定または情報に基づいて、または、INVITE内のVCCサポートの表示に基づいて、E-CSCF 908はSIP INVITEをVCC DTF 910に送る。
6．VCC DTF 910は、入呼レグを固定し、E-CSCF 908にINVITEを送信する（または戻す）ことにより出呼レグを発信する。INVITEは緊急表示を運ぶ。
7．E-CSCF 908は、3GPP TS 23.167で定義されるように、緊急呼セットアップのための通常の処置を実行する。INVITEにおいて提供される位置オブジェクトが正確なPSAPを決定するのに不適当である場合、IMSコアがRDFの補助を要求した場合、またはIMSコアが位置オブジェクトを確認（verify）するように要求された場合、検索位置要求が、位置検索機能を実行するLRF 906に送信される。検索位置要求は、UE 902（例えば、公衆ユーザー電話URIおよびSIP URI）を識別する情報、IP接続性アクセスネットワーク（IP-CAN）を含み、UEにアクセスするための手段（例えば、UE IPアドレス）を含みうる。検索位置要求は、ステップ3のINVITEにおいて提供される任意の位置オブジェクトも含む。検索位置要求は、（LRF 906にまだ知られていない（例えば、提供されていない）場合）UEによるVCCサポートの表示およびVCC DTF 910のための識別情報（例えば、VCC DTF 910によって割り当てられたVDNおよびVDI）をさらに含む。この情報は、ドメイン転送に関連する別のセクションで記述されるように、LRF 906による位置サポートの継続性を可能にする。
8．LRF 906は、TS 23.167に記述されるように、暫定位置推定（interim location estimate）を獲得する。LRF 906は、暫定位置、または、ステップ6で受信された任意の位置オブジェクトをPSAPのアドレスに変換するためにRDFを引き起こす。LRF 906は、ステップ6で受信された情報を記録する。
9．ステップ７において獲得された位置情報および／またはPSAPアドレスは、E-CSCF 908に戻される。LRF 906も、自己を識別する相関情報（例えばESQK）と、ステップ7で記憶される任意の記録を戻す。残りの呼ために、LRF 906はアンカLRFとして仕える。
10．E-CSCF 908は、ステップ8において提供されたPSAPアドレスを使用するか、ステップ8において提供された位置情報に基づいて緊急センタまたはPSAPを選択し、緊急センタまたはPSAP 914に、位置情報と任意の相関情報を含む要求を送信する。ステップ10aにおいて、INVITEはMGCF/MGW 912に送信され、ステップ10bにおいて、IAMは緊急センタまたはPSAP 914に向けて続けられる。若しくは、ステップ10cにおいて、INVITEは、緊急センタまたはPSAP 914に直接送信される。
11．呼確立のための中間シグナリングが発生する（例えば、PSTNケーパブルPSAP（図示されない）からのACMの返還）。PSAPが呼に応答する時、下記のステップが発生する：ステップ11aにおいて、PSAP 914がANMをMGCF/MGW 912に戻す；ステップ11bにおいて、MGCF/MGW 912が200 OKをE-CSCF 908に戻す；または、ステップ11cにおいて、PSAP 914が200 OKを直接E-CSCF 908に戻す。
12．E-CSCF 908は、200 OKをVCC DTF 910に（ステップ5において開始した出呼レグ上で）戻す。
13．VCC DTF 910は、200 OKをE-CSCF 908に戻す。VCC DTF（またはE-CSCF）は、以下に記述されるドメイン転送手順AとCをサポートするために、VDNおよび／またはVDIを200 OKに挿入する。あるいは、VCC DTF（またはE-CSCF）は、以下に記述されるドメイン転送手順BとDをサポートするために、修正VDNおよび／または修正VDI（「修正VDNおよびVDI」セクションで記述されたように）を、SIP INVITEに挿入する。
14．E-CSCF 908は、P-CSCF 904を介して200 OKをUE 902に戻す。
VI．B．CS緊急呼発信
図10を参照すると、CSドメインにおいて発信した緊急呼に対するVCCサポートのためのメッセージフロー1000の1つの態様は、下記ステップおよび動作を含む。
1．ユーザーが緊急呼を開始する。
2．UE 1002は、VMSC 1006に緊急セットアップメッセージを送信することで、CSドメインにおいて緊急音声呼を発信する（本明細書において、参照によって組み込まれる3GPP TS 24.008に定義されるように）。緊急セットアップは、UEがVCCをサポートすることを示し、さらにドメイン転送の要求に対立するものとしての呼発信であることを示す。
3．VMSC 1006は、3GPP TS 23.271において定義され、認められているように、UE 1002のための暫定位置推定を獲得するために、RANにおいて手順を開始する。
4．全てのCS緊急呼のための通常処理に基づいて（例えば、TS 23.271に記述されるように）、または、UEのホームネットワークオペレータに従った仮定VCCサポートに基づいて、または、UEのホームHLR/HSSから獲得された加入情報に基づいて、または、緊急セットアップメッセージ内のVCCサポートの明確な表示に基づいて、VMSC 1006は、通常呼が送られる（例えば、サービングセルIDおよび電話が掛けられた緊急番号基づいて）緊急サービスプロバイダ（PSAP）に関連するGMLC/LRF 1008にMAP加入者位置報告（SLR）を送信する。MAP加入者位置報告は、。UEのためのIMSI、MSIDN、IMEI、VMSCアドレス、サービングセル識別子またはSAIを運ぶ。それはステップ3において獲得された任意の暫定位置推定も含む。GMLC/LRF 1008ではなくVMSC 1006がPSAP（例えば、UE）を通常決定する地域において、メッセージは、意図された目的地PSAPのアドレスを運ぶ。また、メッセージは、VCCサポート、および／または、緊急セットアップにおいて受信された呼発信用かドメイン転送用かの任意の表示を移送する。この表示は、MAP SLRの明確なパラメータ、または、パラメータ値であり、若しくは、それは、MAP SLRがルートされる明瞭なSCCP E.164アドレス（GMLCに関連した）に関連付けられる。
5．GMLC/LRF 1008は、UE 1002がVCCをサポートすると仮定し（例えば、全てのUE、または、ただの特定のオペレータのUEに対する仮定）、または、UEがホームネットワークによってサービスされる場合は、加入情報からこれを決定するかもしれず、もしくは、MAP SLRにおける表示、またはMAP SLRがルートされるアドレス（例えば、SCCP E.164アドレス）からこれを決定する。GMLC 1008は、ステップ4において受信された全ての情報を含む、UE 1002のための呼記録を記憶する。GMLC 1008は、IPマルチメディア ルーティング ナンバ（IMRN）などのルーティング情報を呼に割り当てる。最小限、IMRNは、ステップ6および7においてVCC DTF 1012への呼ルーティングを可能にし、必要に応じて、GMLC 1008を識別する。随意的に、IMRNは、また、GMLC 1008に記憶された呼記録を一時的に識別する。IMRNはGMLC 1008に関連するLRFを選択するために後のステップにおいて使用され、このステップにおいてGMLC 1008に記憶される呼記録がLRFによって検索されることを可能にし、また、LRFがGMLC 1008を介してUEを探し出すことを可能にする。GMLC 1008は、NA-ESRD、NA-ESRK、または、別の新しいパラメータでIMRNを運ぶVMSC 1006にMAP加入者位置報告承認を戻す。そういうものとして、ルーティング情報の受信は、VMSC 1006がCSドメインにおいて緊急呼発信のサポートのための既存能力を活用し、VCCをサポートする任意の新しい能力の追加の必要がないところにおいて、VMSC 1006に対して透明である。その後、GMLC 1008は、VMSCを有するCS-MT-LR（図示されない）に、ルーティンのための暫定位置推定、あるいは、PSAPへの後の供給のための正確な位置推定を獲得させる。代替として、GMLC 1008ではなくMSC 1004がIMRNを割り当て、ステップ4でこれをGMLC 1008に転送する。
6．VMSC 1006は、ステップ5で受信されたIMRNに基づいて呼をルートする。IMRNが既存のNA-ESRKやNA-ESRDパラメータを使用して運ばれると、VMSC 1006における呼ルーティング手順は、TS 23.271における通常の緊急呼発信のために使用されたものと同一である（すなわち、IMRNは、VMSC 1006にとってESRKやESRDのように見える）。IMRNルーティングに基づいて、VMSC 1006は、訪問先ネットワークにおいて、MGCF 1006に呼をルートする。
7．MGCF 1006は、訪問先IMSにおいて、I-CSCF（図示されない）に向けてINVITEを開始し、または、場合によっては、MGCF 1006は、E-CSCF 1010、S-CSCF（図示されない）またはVCC DTF 1012に直接ルートする。INVITEは、UEのID（例えば、コンタクト アドレスとしてのMSISDN Tel URI）を含む。I-CSCF、S-CSCF（図示されない）またはE-CSCF 1010は、IMRNに基づいて、VCC DTFにPSIベースのアプリケーションサーバ終了を引き起こす。
8．VCC DTF 1012は、入呼レグを固定し、E-CSCF 1010にINVITEを送信する（または戻す）ことによって出呼レグを発信させる。INVITEは、緊急呼を識別し、IMRNの回復を運び、または、可能にする情報を運ぶ。
9．例えば、ステップ8におけるIMRN情報の包含に基づいて、E-CSCF1010は、IMRNによって識別された、またはIMRNに関連付けられたLRFに検索位置要求を送信する。検索位置要求は、IMRN情報とステップ8で受信された任意のUE識別子（例えば、MSISDN Tel URI）を含む。検索位置要求は、VCCサポートの表示と、VCC DTF 1012のための識別子情報（例えば、VDNおよびVDI）をさらに含む。
10．ステップ9において受信された任意のUE識別子（例えば、MSISDN）に基づいて、および／またはIMRN情報に基づいて、LRFは、GMLC 1008と相互に作用し、ステップ5においてGMLCによって記録された呼記録を検索する。すでに呼記録にある任意の暫定位置情報、または、ステップ5に従って獲得された任意の暫定位置を使用して、LRFは、PSAPアドレスと、場合によっては位置情報をE-CSCF 1010に戻す。LRFは、位置の将来的なサポートのためにアンカポイント（anchor point）を提供するであろう。また、ステップ9のE-CSCF 1010から受信された情報を記憶することに加え、GMLCから獲得された呼記録を複写する。LRFは、自己と呼記録を識別するE-CSCFに相関情報（例えば、ESQK）を戻す。LRFは、さらに、UEのために正確な位置推定を、VMSCを用いるCS-MT-LR手順に（3GPP TS 23.271に定義されるように）獲得させるために、GMLCに相互に作用する。
11．E-CSCF 1010は、ステップ10において提供されたPSAPアドレスを使用して、位置情報と任意の相関情報を含む呼要求上で緊急センタまたはPSAP（図示されない）に送信する。呼要求は、PSTN（図示されない）にMGCF/MGMを介して送られ、またはIPケーパブル緊急センタまたはPSAPにSIP INVITEとして直接的に送られる。
12．呼確立手順の残りは、TS23.206に記述されるVCC CS発信手順に基づいて、UE1002、VMSC1006、VCC DTF1012、E-CSCF1010、PSAPの間で発生する。
上記手順は、TS23.271で今日、定義される方法において既存のPSAPルーティングオプションのためのサポートを維持し（例えば、セルIDや任意の暫定位置推定を使用して）、必ずしもMSCへの任意の新たなインパクトを必要とせず、PSAPによる正確な位置回復をサポートする。それはCS発信緊急呼がIPケーパブルPSAPに送られることも可能にする。
VI．C．IMSからCSへのドメイン転送−手順A
UEがIMSカバレッジから出てCSカバレッジに入る時に、IMS緊急呼のためにIMSドメインからCSドメインへのドメイン転送をサポートするために、二つの代替手順が記述される。手順Aにおいて、VCCケーパブルUEは、標準VCCのようにふるまい（TS 23.206に記述される）、「VCCサポートのネゴシエイト」に関して上述の代替（e）、（f）、（g）、（h）のいずれかを使用して、訪問先ネットワークから獲得されたVDNを使用し、CSドメインにおいて、VCC DTFに新しい呼レグを発信する。
手順Aは、CSドメインをサポートする新しい訪問先ネットワークにおいて登録するために十分な資格を有するUEに適用可能であり、さらなるUE位置アップデートをPSAPに提供するためのサポートの継続性に制限を設ける。しかし、手順は、UEの観点から、標準VCCのためのIMSからCSドメインへの転送と互換性があるという利点を有する。
図11を参照すると、UEがIMSカバレッジから出てCSカバレッジに入る時に、IMS緊急呼のためにIMSドメインからCSドメインへのドメイン転送をサポートするためのメッセージフロー手順1100の1つの態様は、下記ステップと動作を含む。
1． UE 1102がCSへのドメイン転送の必要性を決定する時にユーザーがCSドメインに付属しない場合、UEは、自己のHLR/HSSへの位置アップデートを含むCSアタッチ（CS Attach）を実行する。その後、被呼者番号パラメータにおいて、VDNを含むサービングMSCやサービングVMSCにDTAP セットアップメッセージを送信することにより、CSドメインにおいて音声呼を発信する。VDNは、CSドメインを介してアクセスレグ（access leg）を確立するために最初の訪問先ネットワークから早期に獲得されたVDNである。この手順のために、UE 1102がCSドメインにおいて認証されることが仮定される。注意：通常の呼が発信されるため、ドメイン転送は、新しいCSドメインにおいて優先処理を受信しないであろう。
2．VMSC 1104において、発信呼は、CSネットワークにおいて通常のCS呼発信として処理される。
3．VMSC 1104は、最初の訪問先ネットワークで、MGCF 1106を介して、最初の訪問先IMSネットワークに向かう呼をルートする。注意：VMSC 1104は、緊急呼またはVCCサポートに気づかず、従って、CS緊急呼発信についてはGMLCクエリを実行しないであろう。位置の継続サポートは、さらに下に記述される。
4．MGCF 1106は、もともとの訪問先IMSにおいてI-CSCF（図示されない）に向かうINVITEを開始し、または、MGCF 1106は、おそらく、E-CSCF 1110、S-CSCF（図示されない）またはVCC DTF 1112に直接ルートする。I-CSCF、S-CSCF（図示されない）、E-CSCF 1110は、VDNに基づいて、VCC DTF 1112に、PSIベースのアプリケーションサーバ終了を引き起こす。
5．DTF 1112は、E-CSCF 1110を介してリモートエンドへの転入(transferring-in)ドメインにおいて確立されたアクセスレグのSDPと通信することにより、出力アクセスレグ（outgoing Access Leg）をアップデートする。アクセスレグアップデートは、IETF RFC 3261において、SIPセッション修正手順に従って発生する。DTF 1112は、また、E-CSCFが次のステップにおいてLRF 1108に通知することを可能にするために、E-CSCF 1110にドメイン転送を明示的に表示する。
6．E-CSCF 1110は、ドメイン転送の種類を識別することにおいて、LRF 1108を補助しうる新しいSDP情報と一緒に、位置アップデートをアンカLRF 1108に送信する。最小限、E-CSCF 1110はCSドメイン転送が存在していることをLRF 1108に示す（例えば、これは、DTF 1112によって、VDIではなくVDNの使用から、および／または、MGCF 1106を巻き込んだドメイン転送から知ることができる）。
7．アップデートは、E-CSCF 1110から、IPケーパブルの場合はPSAP（図示されない）に向けて、またはMGCFに続く。
8．転入CSドメインにおける新しい呼レグは、VCC DTF 1112、E-CSCF 1110またはS-CSCF（存在する場合）、I-CSCF（存在する場合）、MGCF、VMSC 1104とUE 1102との間で確立される。
9．以前にIMSによって確立されたアクセスレグである、先の入力アクセスレグはリリースされる。UE 1102は、訪問先ネットワークP-CSCFおよびホームネットワークS-CSCFにおいて、可能であれば、登録解除（de-register）すべきである。
手順AがUEをCSドメインに転送した後の位置の継続的サポートは、下記手順を含む。PSAPが、UEの位置を獲得するためにアンカLRFに要求を送信すると、LRFにとって、UEがIMSドメインにいる間に使用（または使用すると期待）されていたため、位置を獲得するために同一の手順を使用し続けることは不可能である。例えば、LRFがUDP/IPまたはLRFとUEとの間のSIPプッシュ初期移行に基づいてOMA SUPLを使用していた場合、IMSからCSドメインに付随する、UEによるPSドメインへのアクセスの損失は、SUPLのさらなる使用を妨げる。加えて、LRFは、VMSCアドレスを知らないが故に、CS緊急呼のために（例えば、TS 23.271の条項9.1.3）3GPP TS 23.271に定義された制御プレーン位置解法を使用することができない。しかし、LRFは、LRF（GMLCとしてふるまう、またはGMLCにアクセスする）がUEのホームHLR/HSSをクエリすることによってVMSCアドレスを獲得する、より一般的なCS-MT-LR手順（3GPP TS 23.271の条項9.1.1および9.1.2に記述される）を使用する。しかし、これの不利な点は、UEのHLR/HSSが、CS-MT-LRクエリ手順をサポートする必要があり、訪問先ネットワークとホームネットワークとの間でビリング（billing）問題になりうることである（ホームネットワークが緊急呼の重要さに気づかないため）。この不利な点を避けるために、MSC1104は、ステップ3において送られるISUP IAMにおいて、UE 1102の現行サービングセルや自己のID（例えば、ISUP汎用数列パラメータ（Generic Digits parameter）の10ディジット番号の形式で）を運ぶ。MGCF 1106は、ステップ４において送信されるSIP INVITEでVCC DTF 1112に同一の情報を運ぶ（例えば、SIP URLパラメータや幾つかの他のSIPパラメータを使用して）。情報は、次に、ステップ5でE-CSCF 1110に運ばれ、ステップ6でLRFに運ばれる。LRF 1108は、次に、MSC 1104のIDと、任意の後の位置要求のための適切なGMLCを決定し、3GPP TS 23.271における既存の手順を使用し、MSC 1104か
らUE 1102の位置をクエリするためにGMLCを利用する。
VI．D．IMSからCSへのドメイン転送−手順B
IMSからCSへのドメイン転送を可能にする手順Bは、それが、新しい訪問先ネットワークで登録するのに十分な資格を有し、制限なく位置サポートの継続性を可能にしようとしまいと、UEに適応可能である。しかし、同一のオペレータに属するネットワーク（例えば同一のMCCとMNCを共有するネットワーク）間のドメイン転送に限定されるべきである。手順は、VDNの知識を必要としないUEにおいて、VCCドメイン転送の新しい変形を要求する。
図12を参照すると、IMS緊急呼のIMSからCSドメイン転送を可能にするメッセージフロー手順1200の１つの態様は、下記ステップと動作を含む。
1．UE 1202がCSへのドメイン転送の必要性を決定する時に、ユーザーがCSドメインに付属されないとすると、UE 1202は、必要な資格を含む場合、CSアタッチを実行する。その後、それは、3GPP TS 24.008に定義されるように、VMSCに緊急セットアップメッセージを送信することによって、CSドメインにおいて、緊急音声呼を発信する。緊急セットアップは、UE 1202がVCCをサポートすることを示し、さらに、これがドメイン転送の要求であることを示す。代替として、UE 1202は、被呼者番号パラメータにおいて修正VDNを運ぶ通常セットアップメッセージを送信する。
2．UE 1202がステップ1において緊急セットアップメッセージを送信する場合、次に、全てのCS緊急呼に対する通常処理に基づいて（例えば、TS 23.271に示されるように）または、UEのホームネットワークオペレータに従う推定VCCサポートに基づいて、または、緊急セットアップメッセージにおけるVCCサポートの明確な表示に基づいて、VMSC 1204は、呼が通常送られるであろう（例えば、現行サービスセル、または、SAIに基づいて）緊急サービスプロバイダ（PSAP）に関連付けられたGMLC 1208にMAP加入者位置報告（SLR）を送信する。あるいは、UE 1202が、ステップ1において、修正VDNを運ぶ標準セットアップメッセージを送信すると、MSC 1204は、既存の緊急呼のためのドメイン転送要求を表しているとしてVDNを認識し、同様に、GMLC 1208にMAP SLRを送信する。MAP SLRは、IMSI、MSIDN、IMEI、VMSCアドレス、サービングセルIDまたはSAIを含む通常の緊急呼発信（例えば、図10のステップ4のように）のために送られる情報と同一の情報を運ぶ。位置推定は含まれない。メッセージは、VCCサポートおよび緊急セットアップにおいて受信されたドメイン転送のためか否かの任意の表示を運ぶ。この表示は、MAP SLRにおける明確なパラメータまたはパラメータ値であり、または、MAP SLRがルートされる明瞭なSCCP E.164アドレス（GMLCに関連する）に関連付けられる。
3．ローカルポリシーに基づいて、またはMAP SLRにおいて受信されたドメイン転送のためのVCCサポートと要求の明確な表示に基づいて、またはMAP SLPがルートされるアドレス（例えば、SCCP E.164アドレス）に基づいて、GMLC 1208は、元来、アンカLRFにおいて確立された（例えば、図9または図10に図示される手順を使用して）UE 1202のための呼記録を探すために、関連LRF（同一の物理エンティティ内に存在する）と相互に作用する。アンカLRFは、正確な呼記録を識別するためにステップ2において受信されたIMSI、MSISDNおよび／またはIMEIを使用する。認証されていない緊急呼の場合、IMEIは、認証が完全には信頼できないが故に、さらなる検討用のアイテムである呼記録を識別するために使用されなければならないことに注意されたい。呼記録が見つからず、ドメイン転送のための要求であるという表示がMAP SLRにおいて受信されない、またはMAP SLRに関連付けられない場合、GMLCはこれが新しい緊急呼であると仮定し、図10にある様にに進む。しかし、呼記録が見つからず、MAP SLRがドメイン転送のための要求を示す場合、GMLC 1208は、VMSCによるドメイン返還要求の拒絶を引き起こすために、MAP SLR返還誤り応答または幾つかの別の誤りメッセージを戻す。その場合、UE 1202は、IMSドメインにおいて呼を継続し、それが不可能な場合には呼をリリースしなければならない。そうでなではなく、呼記録が見つかる場合は、GMLC 1208は、新しいアクセスレグを確立するために必要なVDN（ステップ１で受信される任意の修正VDNとは異なることに注意）を運ぶVMSC 1204にMAP加入者位置報告承認を戻す。このVDNは、呼が最初に発信された時に（例えば、図9のステップ7や図10のステップ9で）、LRFによって獲得される。VDNは、MAP加入者位置報告承認において、既存のNA-ESRKまたは既存のNA-ESRDパラメータによって運ばれる。GMLC 1208は、また、ステップ2においてVMSC 1204から受信された情報を記憶する。
4．VMSC 1204は、ステップ3において受信されたVDNに基づいて、新しいレグをルートする。VDNが、既存のNA-ESRKやNA-ESRDパラメータを使用して運ばれると、呼ルーティング手順は通常緊急呼発信に対して使用されたものと同じである（すなわち、さらなるVMSCインパクトはない）。VDNルーティングに基づいて、VMSC 1204は、最初の訪問先ネットワークにおいて、MGCF 1206を介して最初の訪問先IMSネットワークに呼をルートする。
5．MGCF 1206は、最初の訪問先IMSにおいてI-CSCF（図示されない）に向けてINVITEを開始するか、場合によっては、MGCF 1206は、E-CSCF 1210、S-CSCF（図示されない）またはVCC DTF 1212に直接ルートする。I-CSCF、S-CSCF（図示されない）またはE-CSCF 1210は、VDNに基づいてVCC DTF 1212にPSIベースのアプリケーションサーバ終了を起こさせる。
6．DTF 1212は、E-CSCF 1210を介してリモートエンドへの転入ドメインにおいて確立されたアクセスレグのSDPと通信することで、出力アクセスレグをアップデートする。アクセスレグアップデートは、IETF RFC 3261において、SIPセッション修正手順に従って発生する。DTF 1212は、また、E-CSCF 1210にCSドメイン転送を明確に表示する。
7．E-CSCF 1210は、新しいSDP情報と一緒に、アンカLRF1208に位置アップデートを送信する。最小限、E-CSCF 1210は、CSドメイン転送があったことをLRF 1208に表示する。LRF 1208は、この表示をステップ３において決定されるドメイン転送の表示と、相互に関係させ、UE 1202が、今、ステップ2において示されるドメインにドメインを変えたことを決定する。LRF 1208は、ステップ2においてVMSC 1204によって選択されたGMLC 1208（必ずしも同一のエンティティ内でなくてもよい）にこの情報を通知する。
8．アップデートは、E-CSCF 1210からPSAPまたはMGCF（図示されない）に続く。
9．転入CSドメインにおける新しい呼レグは、VCC DTF 1212、E-CSCF 1210またはS-CSCF（存在するのであれば）、I-CSCF（存在するのであれば）、MGCF 1206、VMSC 1204とUE 1202との間で確立される。
10．IMS上で以前に確立されたアクセスレグであるソースアクセスレグはリリースされる。UE 1202は、訪問先ネットワークP-CSCF（図示されない）およびホームネットワークS-CSCF（図示されない）において、可能であれば登録解除するべきである。
登録されていないUEのためのドメイン転送を可能にすることに加え、手順Bは、また、アンカLRFが、緊急呼を発信したUEを位置するために、3GPP TS 23.271で定義された（例えば、条項9.1.3）通常位置手順を利用することを可能にする。これは、VMSCがGMLCに関連する情報を獲得して記憶する図12のステップ2と3によって、可能となり、LRFとGMLCは、VMSCに関連する情報を獲得して記憶する。次に、これはUEのホームHSS/HLRをクエリする必要なしに、CS-MT-LRを許可する。
手順Bのさらなる態様は、VMSCでの呼発信手順が、TS 23.271に記述されるように、通常の緊急呼に対するものと同じ、またはほぼ同じであり、または、図10での手順について記述されたとおり、CS発信緊急呼のためのVCCサポートのためのものと同じ、またはほぼ同じである。GMLCの見地から、手順も、VMSCとのMAPシグナリング送信に関する通常緊急呼のためのものとほぼ同じである。
しかし、手順Bは、ステップ３において最初の呼記録を見つけるGMLCとLRFに依存する。GMLCとLRFが同一のオペレータに属する場合、これは可能であるように見受けられる（例えば、その時、GMLCとLRFが同一の物理エンティティの一部であるか、少なくとも相互に接続関係にあるため）。しかし、最初の呼記録が見つからず、緊急セットアップメッセージにおいて、ドメイン転送の明確または暗黙的な表示がない場合、GMLCは、これが新しい緊急呼であり、ユーザーから新しいPSAPオペレータへの接続という結果を生むドメイン転送でないと仮定する。しかし、この不利な点は、上に記述されるように、緊急セットアップとMAP SLRメッセージにおいてVCCとドメイン転送表示を含むことによって避けることができる。
VI．E．CSからIMSへのドメイン転送−手順C
2つの代替手順が、緊急呼のためにCSドメインからIMSドメインへのドメイン転送をサポートするために記述される。ここに記述される手順Cにおいて、VCCケーパブルUEは、標準VCC（3GPP TS 23.206に記述されるように）のようにふるまい、本明細書において以前に記述された任意の代替（e）、（f）、（g）、（h）を使用し、訪問先ネットワークから獲得されたVDIを使用して、IMSドメインにおいて、VCC DTFへの新しい呼レグを発信する。呼は、通常発信SIP呼のように処理され、従って、新しい訪問先ネットワークにおいて登録するために十分な資格を有するUEに対してのみ適当可能である。
図１３を参照すると、CSドメインからIMSドメインへのドメイン転送のためのメッセージフロー手順1300の1つの態様は、以下のステップと動作を含む。
1．UE 1302がIMSへのドメイン転送の必要を決定する時に、ユーザーがIMSに登録されていない場合、UE 1302は、3GPPドラフトTS 23.206に詳細に記されるように、IMへの登録を開始する。その後、IMSを介してアクセスレグを確立し、アクティブCSセッションのドメイン転送をIMSに要求するために、訪問先ネットワークから早期に獲得されたVDI（例えば、図9と図10においてIMS呼発信に関して上述されるように）を使用し、最初の訪問先ネットワークにおいて、DTF 1308へのIMS発信セッションを開始する。通常の呼処理のために、SIP INVITEは、新しい訪問先ネットワークまたはホームネットワークのいずれか一方のP-CSCF（図示されない）と、ホームネットワークのS-CSCF（図示されない）を通してルートされ、結局は最初の訪問先ネットワークにおけるS-CSCF（図示されない）、または、到達するであろう。注意：通常呼が発信されるため、ドメイン転送は、新しいIMSドメインにおいて優先処理を受けないであろう。
2．IMSセッションは、最初の訪問先ネットワークにおいて、S-CSCF（図示されない）、またはE-CSCF 1306で処理され、VCC DTF 1308に運ばれる。
3．DTF 1308は、IMSを介して新しい入力アクセスレグの確立を完了する。DTF 1308は、3GPP TS 23.206に明確に示されるように、アクセスレグアップデート手順を使用して、新しく確立されたアクセスレグの接続情報で遠隔レグをアップデートすることによりドメイン転送を実行する。UPDATEまたはReINVITEは、呼を発信するために使用されたE-CSCF 1306に送られる（例えば、図9または図10に従って）。DTF 1308は、また、E-CSCF 1306にドメイン転送を明示的に表示する。
4．E-CSCF 1306は、新しいSDP情報でアンカLRF 1304をアップデートする（例えば、UE 1302が、現在、IMSドメインを使用していることを示し、UE IPアドレスを提供する）。
5．アップデートは、E-CSCF 1306からPSAPまたはMGCF（図示されない）に続く。
6．CS上で以前に確立されたアクセスレグであるソースアクセスレグは、3GPP TS23.206に詳細に記述されるように、その後リリースされる。これは、前回の入力CSレグを、E-CSCF 1306を通してリリースすることを含む。
手順Cが完了すると、LRFが、現在、UEのIPアドレスを有し、従ってOMA SUPL（又は、IP移行を伴う任意の別の解法）を引き出しうるため、UEのための位置サポートを継続することが可能になるであろう。GPRSアクセスのためにUEの位置特定を可能にする3GPP制御プレーン解法の使用は、条項9.1.1と9.1.6において記述される、LRFが訪問先SGSNアドレスのためにUEのホームHLR/HSSをクエリする、より一般的なPS-MT-LR手順を使用することができる。
VI．F．CSからIMSへのドメイン転送−手順D
別の態様において、CSからIMSへのドメイン転送をサポートする手順Dは、VDIの使用を要求せず、継続位置サポート上に、より少ない制限を置く。しかし、手順Bに関する場合と同一のオペレータによって所有され、管理されるネットワーク間のドメイン転送に制限される。
図14を参照すると、CSからIMSへのドメイン転送をサポートするメッセージフロー手順1400の１つの態様は、下記ステップと動作を含む。
1．INVITEを送信する前に、UE 1402は、3GPP TS23.167において定義されるように十分な資格を含む場合、新しい訪問先IMSネットワークにおいて緊急登録を実行する（すなわち、通常登録は使用されない）。これは、UE 1402に（新しい訪問先ネットワークを介して）戻る呼をサポートすること、および、新しい訪問先IMSにおいてUE 1402を認証することが必要になるであろう。
2．UE 1402は、次に、訪問先ネットワークP-CSCF 1404に緊急表示と共にINVITEを送信する。INVITEは、UE 1402のための識別情報（例えば、MSISDN Tel URIや公衆ユーザーSIP URI）を含む。INVITEは、UE 1402がVCCをサポートすることを示し、呼発信に対立するものとして、ドメイン転送の要求であることを示す。この表示は、ヘッダーフィールドへのSIPで運ばれた修正VDIで運ばれる。この場合、個別の緊急表示は必要ない。
3．「VCCサポートのネゴシエーション」において上述された代替（a）、（b）、（c）に従ったVCCサポートの知識や推定に基づいて、または、INVITE内のVCCサポートの表示に基づいて（例えば、修正VDIの包含を介して）、P-CSCF 1404はSIP INVITEをE-CSCF 1408に進める。
4．推定または知識またはVCCサポートの表示に基づくE-CSCF 1408は、SIP INVITEをVCC DTF 1410に進める。
5.VCC DTF 1410が（例えば、図9のステップ5に従って確立されたように）最初の呼記録を見つける。DTF 1410は、次に、転入ドメインにおいて確立されたアクセスレグのSDPをE-CSCF 1408を介してリモートエンドへ通信することによって出力アクセスレグをアップデートする。DTF 1410も、E-CSCF 1408にドメイン転送を明示的に表示する。VCC DTF 1410が最初の呼記録を見つけず、INVITEにおいてドメイン転送の要求であるという表示が受信されなかった場合、VCC DTF 1410は、新しい緊急呼（ドメイン転送ではなく）であると仮定し、図9のステップ6のように進む。しかし、呼記録が見つかり、INVITEがドメイン転送に対する要求を表示する場合、VCC DTF 1410は、UEに、幾つかの誤りメッセージを戻すことで、ドメイン転送要求を拒絶する。この場合、UE 1402はCSドメインにおいて呼を継続し、それが不可能な場合は呼をリリースしなければならない。
6．E-CSCF 1408は、新しいSDP情報を用いてアンカLRF 1406をアップデートする（例えば、UE 1402が、現在、IMSドメインを使用していることを表示し、UE IPアドレスを提供する）。
7．アップデートは、E-CSCFからPSAPまたはMGCF（図示されない）へと続く。
8．CS上で以前に確立されたアクセスレグであるソースアクセスレグは、続いて、3GPPドラフトTS23.206に明記される通りにリリースされる。これは、E-CSCF 1408を介して前の入力CSレグをリリースすることを含む。
位置サポートを継続することは、手順Cのそれと同一である（例えば、ステップ5でアンカLRFに提供されたUE IPアドレスを有するOMA SUPLを使用して、または、GPRSアクセスを有する位置特定のために3GPP PS-MT-LR手順を使用して）。しかし、それ以上の利益として、3GPP TS 23.271（条項9.1.6Aと9.1.7において）に定義された緊急呼に特有の3GPP PS-NI-LRとPS-MT-LR手順を使用することが可能である。これは、UEがGPRSアクセスおよび／またはGPRS PDPコンテキスト確立のための緊急呼を表示する場合に可能になる。これは、PS-NI-LRに位置を獲得させるか、あるいは、GMLCに自己のアドレスを提供させるようにSGSNをトリガする。GMLCがアンカLRFに関連する場合、SGSNアドレスをアンカLRFに提供することが可能になるであろう。それによって、ホームHLR/HSSをクエリせずに、PS-MT-LRの使用を可能にする（そして、場合によってはHLR/HSSを有さない権限のないUEに対する位置を許可する）。
本出願で使用されるように、用語「コンポーネント」、「モジュール」、「システム」および、それらと同様のものは、限定はされないが、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアなどの、コンピュータ関連エンティティを含むことを意図する。例えば、コンポーネントは、プロセッサ上の処理実行、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラムおよび／またはコンピュータであるが、それに限定されない。実例として、計算デバイス上のアプリケーション実行と計算デバイスは共に、コンポーネントでありうる。１つ以上のコンポーネントは、プロセスおよび／または実行のスレッドに存在し、コンポーネントは１つのコンピュータ上でローカライズされ、および／または、2つ以上のコンピュータ間に分散される。さらに、これらのコンポーネントは、それについて記憶された多様のデータ構造を有する多様なコンピュータ可読メディアから実行される。コンポーネントは、ローカルシステム内の、分散型システム内の、および／または、インターネットなどの信号経由での他のシステムとのネットワークにわたる別のコンポーネントと相互に作用する１つのコンポーネントからのデータといった1つ以上のデータパケットを有する信号に従ったローカルおよび／または遠隔プロセッサを通して通信する。
さらに、多様な態様が、有線端末または無線端末である端末に関して本明細書において記述される。端末は、システム、デバイス、加入者ユニット、加入者局、移動局、モバイル、モバイルデバイス、遠隔局、遠隔端末、アクセス端末、ユーザー端末、端末、通信デバイス、ユーザーエージェント、ユーザーデバイス、ユーザー機器（UE）とも呼ばれる。無線端末は、携帯電話、衛星電話、コードレス電話、セッション開始プロトコル（SIP）電話、無線ローカルループ（WLL）局、携帯情報端末（PDA）、無線接続性能を有するハンドヘルドデバイス、処理デバイス、または、無線モデムに接続される他の処理デバイスである。さらに、多様な態様が基地局に関して本明細書で記述される。基地局は、無線端末と通信するために利用され、アクセスポイント、ノードB、または、幾つかの別の用語で呼ばれる。
さらに、用語「または」は、排他的な「または」というよりは、包括的な「または」を意図している。明確に表記されない、または、コンテキストから明らかでない場合、表現「XはAまたはBを用いる」は、任意の自然な包括的順序を意味する。すなわち、表現「XはAまたはBを用いる」は、任意の下記例によって満たされる：XはAを用いる；XはBを用いる；または、XはAとBの両方を用いる。加えて、この明細書に使用される冠詞「a」と「an」および添付された請求項は、一般的に、そうではないと明確に示されている場合、または単数形に向けられていることがコンテキストから明らかである場合でない限り、「１つ以上の」を意味すると解釈される。
本明細書に記述された技法は、CDMA、TDMA、FDMA、OFDMA、SC-FDMA、他のシステムなどの多様な無線通信のために使用されうる。「システム」と「ネットワーク」という用語は、しばしば交換可能に使用される。CDMAシステムは、ユニバーサル地上波無線アクセス （UTRA）やcdma2000などの無線テクノロジーを実施する。UTRAは広帯域CDMA（W-CDMA）やCDMAの別の変形を含む。さらに、cdma2000はIS-2000、IS-95、IS-856標準をカバーする。TDMAシステムは、汎ヨーロッパデジタル移動通信システム（GSM）などの無線テクノロジーを実施する。OFDMAシステムは、次世代UTRA（E−UTRA）、ウルトラモバイルブロードバンド（UMB：Ultra Mobile Broadband）、IEEE 802.11（Wi-Fi）、IEEE 802.16（WiMAX）、IEEE 802.20、フラッシュOFDM（Flash-OFDM）などの無線テクノロジーを実施する。UTRAとE-UTRAは、万国移動通信システム（UMTS）の一部である。3GPPロングタームエボリューション（LTE：long term evolution）は、ダウンリンク上でOFDMAを用い、アップリンク上でSC-FDMAを用いるE-UTRAを使用するUMTSのリリースである。UTRA、E-UTRA、UMTS、LTE、GSMは、「第3世代パートナーシッププロジェクト」（3GPP）という名称の団体からの文書に記述される。cdma2000およびUMBは、「第3世代パートナーシッププロジェクト2」（3GPP2）という名称の団体からの文書に記述される。さらに、それらの無線通信システムは、対になっていない許可スペクトル、802.xx無線LAN、ブルートゥース、任意の他の近距離、または、長距離の無線通信技法をしばしば使用するピアツーピア（例えば、モバイルツーモバイル）アドホックネットワークシステムを追加として含む。
様々な態様または特徴は、多数のデバイス、コンポーネント、モジュール、およびそれらと同様のものを含むシステムという点から表される。多様なシステムが、図に関して議論されたよりもさらなるデバイス、コンポーネント、モジュールなどを含むこと、および／または図に関して議論された全てのデバイス、コンポーネント、モジュールなどを必ずしも含まないことが理解および認識されるべきである。これらのアプローチの組み合わせも使用されうる。
本明細書に開示された実施形態と関連して記述される様々な実例となる論理ブロック、モジュール、回路は、汎用のプロセッサ、デジタル信号プロセッサ（DSP）、特定用途向けIC（ASIC）、書替え可能ゲートアレイ（FPGA）又は他のプログラマブル論理デバイス、ディスクリートゲート又はトランジスター論理、ディスクリートハードウェアコンポーネント、若しくは本明細書に記述された機能を実行するよう設計されたこれらの任意の組み合わせと一緒に実行または実施されうる。汎用のプロセッサはマイクロプロセッサである。汎用のプロセッサはマイクロプロセッサであるが、代替で、プロセッサは、通常のプロセッサ、コントローラ、マイクロコントローラ、ステートマシン（state machine）でありうる。プロセッサは計算デバイスの組み合わせとしても実施されうる。例えば、DSPとマクロプロセッサ、複数のマイクロプロセッサ、DSPコアに結合した1つ以上のマイクロプロセッサ、その他の上記構成の組み合わせである。加えて、少なくとも1つのプロセッサは、上述の１つ以上のステップおよび／または動作が実行可能な1つ以上のモジュールを備えうる。
本明細書に開示された実施形態に関して示される方法またはアルゴリズムのステップおよび／または動作は、直接的にハードウェア、プロセッサによって実行されるソフトウェアモジュール、またはそれら二つの組み合わせに組み込まれうる。ソフトウェアモジュールは、ランダムアクセスメモリ（RAM）、フラッシュメモリ、読み取り専用メモリ（ROM）、消去可能PROM（EPROM）、電気的消去可能PROM（EEPROM）、レジスタ、ハードディスク、取外し可能ディスク、CD-ROM、または本技術分野において周知の記憶メディアの他の形態に存在しうる。例示的な記憶メディアは、プロセッサが記憶メディアから情報を読み取り、記憶メディアに情報を書き込むことができるプロセッサに結合されうる。代替において、記憶メディアはプロセッサに一体化されうる。プロセッサと記憶メディアはASICに存在しうる。ASICはユーザー端末に存在しうる。代替において、プロセッサと記憶メディアは、個別コンポーネントとして、ユーザー端末に存在しうる。さらに、少なくとも2つのネットワーク側コンポーネントや、ユーザー端末などの装置は、それぞれの動作を行うための命令を実行可能な少なくとも１つのプロセッサを使用して、上述された機能を実行するように構成されうる。加えて、幾つかの態様において、方法またはアルゴリズムのステップおよび／または動作は、コンピュータプログラム製品に組み込まれる機械可読メディアおよび／またはコンピュータ可読メディア上で、単一、任意の組み合わせ、符号および／または命令のセットとして存在しうる。
1つ以上の例示的な実施形態において、上記機能はハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせで実施されうる。ソフトウェアで実施された場合、その機能はコンピュータ可読メディア上の１つ以上の命令またはコードとして記憶または送信される。コンピュータ可読メディアは、コンピュータ記憶メディアと、ある箇所から別の箇所へのコンピュータプログラム移送を容易にする任意のメディアを含む通信メディアとの両方を含む。記憶メディアはコンピュータによりアクセスされることができる任意の利用可能なメディアである。それに制限されない例として、上記コンピュータ可読メディアはRAM、ROM、EEPROM、CD-ROMまたは他の光学ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、若しくはコンピュータによってアクセスされることができ、命令やデータ構造形で所望のプログラムコードを運んだり記憶したりするために使われる任意の別メディアからなる。また、任意の接続は適切にコンピュータ可読メディアと呼ばれる。例えば、仮に同軸ケーブル、光ファイバーケーブル、撚線対、デジタル加入者回線（DSL）、又は赤外線、無線、マイクロ波などの無線テクノロジーを使用してウェブサイト、サーバ、又は他のリモートソース（remote source）からソフトウェアが送信されると、同軸ケーブル、光ファイバーケーブル、撚線対、デジタル加入者回線（DSL）、又は赤外線、無線、マイクロ無線などの無線テクノロジーはメディアの定義に含まれる。ディスク（disk）とディスク（disc）は、本明細書で使用されているように、コンパクトディスク（CD）、レーザディスク、光ディスク、デジタルビデオディスク（DVD）、フロッピー（登録商標）ディスク、ブルーレイディスクを含む。ディスク（disk）は通常磁気作用によってデータを再生し、ディスク（disc）はレーザーで光学的にデータを再生する。上記の組み合わせもコンピュータ可読メディアの範囲内に含まれるべきである。
前述の開示は実例となる様態および／または実施形態を議論するが、添付された請求項によって定義されるように、記述された態様および／または実施形態の範囲を逸脱することなく、多様な変更および修正されうることは注意されるべきである。さらに、記述された態様および／または実施形態の要素が、単数形で記述または要求されているとしても、単数形への限定が明確に示されていない場合は複数形が企図される。加えて、記述がない限り、任意の態様および／または実施形態の全て、または、一部は、任意の別の態様および／または実施形態の全て、または、一部と共に利用される。

Claims (49)

  1. 無線アクセス環境において、緊急呼のために音声呼継続性（VCC）をサポートする方法であって：
    サービングドメインにおいて、ユーザー機器（UE）からの緊急およびドメイン転送情報を含むメッセージを受信すること、ここで、前記緊急およびドメイン転送情報は、前記UEがVCCをサポートするかどうかを明示的に表示する、１またはそれより多くの未使用のメッセージビットの内の少なくとも１つのＶＣＣ表示ビットを有する、と；
    緊急呼発信またはドメイン転送のいずれかの必要性を、前記緊急およびドメイン転送情報に基づいて決定することと；
    前記決定に基づいて、前記緊急呼発信または前記ドメイン転送のいずれかを実行することと；
    を備える方法。
  2. 前記緊急およびドメイン転送情報は、修正音声ドメイン転送番号（VDN）を備える、請求項1の方法。
  3. 前記緊急およびドメイン転送情報は、修正音声ドメイン転送セッション開始プロトコル・ユニフォームリソース表示（VDI）を備える、請求項1の方法。
  4. 前記メッセージは3GPP 直接転送アプリケーションパート（DTAP）緊急セットアップメッセージであり、前記緊急およびドメイン転送情報は、随意のサービスカテゴリパラメータに予備のビットを備える、請求項1の方法。
  5. 前記メッセージは3GPP直接転送アプリケーションパート（DTAP）セットアップメッセージであり、前記修正VDNは前記被呼者番号パラメータにおけるE.164番号である、請求項2の方法。
  6. 前記メッセージは直接転送アプリケーションパート（DTAP） INVITEであり、前記修正VDIはセッション開始プロトコル（SIP）・ユニフォームリソース表示（URI）である、請求項3の方法。
  7. 前記サービングドメインは回線交換（CS）サービングドメインである、請求項1の方法。
  8. 前記サービングドメインは、パケット交換（PS）サービングドメインである、請求項1の方法。
  9. 前記サービングドメインのサービング・モバイルスイッチングセンター（MSC）において、前記メッセージを受信することをさらに備え、前記サービングMSCは、前記サービングドメインにおいて、ゲートウェイモバイルロケーションセンター（GMLC）にクエリを送信し、前記クエリは緊急呼発信要求またはドメイン転送要求を含み、前記GMLCは、前記緊急呼発信または前記ドメイン転送要求に基づいて、前記サービングMSCにルーティング情報を戻す、請求項7の方法。
  10. 前記GMLCは2つのスキニー呼制御プロトコル（SCCP） E.164アドレスを所有し、前記サービングMSCは、前記緊急およびドメイン転送情報が緊急呼発信を示す場合は一方のアドレスへ、前記緊急およびドメイン転送情報がドメイン転送を示す場合は他方のアドレスへ前記クエリを送信し、前記一方のアドレスは前記緊急呼発信を示し、前記他方のアドレスは前記ドメイン転送要求を示す、請求項９の方法。
  11. 前記GMLCは、どのSCCPアドレスに前記クエリが送信されたかに基づいて、前記ルーティング情報を決定する、請求項10の方法。
  12. 前記ルーティング情報は、緊急サービスルーティングデジット（ESRD）または緊急サービスルーティングキー（ESRK）を備える、請求項11の方法。
  13. 前記クエリを前記GMLCに送信すること、および、前記GMLCから前記ルーティング情報を受信することは、前記サービングMSCにとって透明である、請求項12の方法。
  14. 前記緊急およびドメイン転送情報は、前記UEが音声呼継続性（VCC）をサポートできることを示す、請求項1の方法。
  15. 前記緊急呼発信は、VCC ドメイン転送機能（DTF）において、前記緊急呼を固定することを含む、請求項１の方法。
  16. 前記VCC DTFは、修正音声ドメイン転送セッション開始プロトコル（VDI）および修正音声ドメイン転送番号（VDN）を前記UEに戻す、請求項15の方法。
  17. 前記修正VDIおよび前記修正VDNは、SIP200 OKメッセージで前記UEに戻される、請求項16の方法。
  18. 前記クエリはMAP 加入者位置報告（SLR）であり、前記緊急呼発信またはドメイン転送要求は前記MAP SLRの随意のパラメータに含まれる、請求項9の方法。
  19. 前記緊急呼発信要求または前記ドメイン転送要求は、前記UEがVCCをサポートすることを示す、請求項9の方法。
  20. 前記ドメイン転送を実行することは、VCCドメイン転送機能（DTF）において、前記UEのために呼記録を見つけることを含む、請求項1の方法。
  21. 前記呼記録が見つからない場合に、前記UEに誤りメッセージを戻すことをさらに備える、請求項20の方法。
  22. 前記ドメイン転送を実行するために使用されるISUP初期アドレスメッセージ（IAM）において、サービングセル表示（ID）またはMSC IDを含むことをさらに備える、請求項7の方法。
  23. 前記サービングセルIDまたはMSC IDは、前記IAMにおいて汎用数列パラメータに含まれる、請求項22の方法。
  24. 無線アクセス環境において、緊急呼のために音声呼継続性（VCC）をサポートするように構成された少なくとも1つのプロセッサであって、
    ユーザー機器（UE）からの緊急およびドメイン転送情報を含むメッセージを受信するための第1のモジュール、ここで、前記緊急およびドメイン転送情報は、前記UEがVCCをサポートするかどうかを明示的に表示する、１またはそれより多くの未使用のメッセージビットの内の少なくとも１つのＶＣＣ表示ビットを有する、と；
    緊急呼発信またはドメイン転送のいずれかの必要性を、前記緊急およびドメイン転送情報に基づいて決定する第2のモジュールと；
    前記決定に基づいて、前記緊急呼発信または前記ドメイン転送のいずれかを実行する第3のモジュールと；
    を備えるプロセッサ。
  25. コンピュータ可読メディアを備え、無線アクセス環境において緊急呼のために音声呼継続性をサポートするように構成されたコンピュータプログラムであって、前記可読メディアは：
    ユーザー機器（UE）からの緊急およびドメイン転送情報を含むメッセージをコンピュータに受信させることを可能にする第1の符号セット、ここで、前記緊急およびドメイン転送情報は、前記UEがVCCをサポートするかどうかを明示的に表示する、１またはそれより多くの未使用のメッセージビットの内の少なくとも１つのＶＣＣ表示ビットを有する、と；
    緊急呼発信またはドメイン転送のいずれかの必要性を、前記緊急およびドメイン転送情報に基づいて前記コンピュータに決定させることを可能にする第2の符号セットと；
    前記決定に基づいて、前記緊急呼発信または前記ドメイン転送のいずれかを前記コンピュータに実行させることを可能にする第3の符号セットと；
    を備える、コンピュータプログラム製品。
  26. 無線アクセス環境において、緊急呼のために音声呼継続性（VCC）をサポートするように構成された装置であって：
    ユーザー機器（UE）からの緊急およびドメイン転送情報を含むメッセージを受信する、ここで、前記緊急およびドメイン転送情報は、前記UEがVCCをサポートするかどうかを明示的に表示する、１またはそれより多くの未使用のメッセージビットの内の少なくとも１つのＶＣＣ表示ビットを有する、手段と；
    緊急呼発信またはドメイン転送のいずれかの必要性を、前記緊急およびドメイン情報に基づいて決定する手段と；
    前記決定に基づいて、前記緊急呼発信または前記ドメイン転送のいずれかを実行する手段と；
    を備える装置。
  27. 無線アクセス環境において、緊急呼のために音声呼継続性（VCC）をサポートする装置であって：
    サービングドメインで、ユーザー機器（UE）からの緊急およびドメイン転送情報を含むメッセージを受信し、ここで、前記緊急およびドメイン転送情報は、前記UEがVCCをサポートするかどうかを明示的に表示する、１またはそれより多くの未使用のメッセージビットの内の少なくとも１つのＶＣＣ表示ビットを有する；
    緊急呼発信またはドメイン転送のいずれかの必要性を、前記緊急およびドメイン転送情報に基づいて決定し；
    前記決定に基づいて、前記緊急呼発信または前記ドメイン転送のいずれかを実行する；
    命令を実行可能な少なくとも1つのプロセッサを備える装置。
  28. 前記緊急およびドメイン転送情報は修正音声ドメイン転送番号（VDN）を備える、請求項27の装置。
  29. 前記緊急およびドメイン転送情報は修正音声ドメイン転送セッション開始プロトコル・ユニフォームリソース表示（VDI）を備える、請求項27の装置。
  30. 前記メッセージは3GPP直接転送アプリケーションパート（DTAP）緊急セットアップメッセージであり、前記緊急およびドメイン転送情報は、前記随意のサービスカテゴリパラメータにおいて予備のビットを備える、請求項27の装置。
  31. 前記メッセージは3GPP直接転送アプリケーションパート（DTAP）セットアップメッセージであり、前記修正VDNは、被呼者番号パラメータにおいてE.164番号である、請求項28の装置。
  32. 前記メッセージはセッション開始プロトコル（SIP） INVITEであり、前記修正VDIはSIP ユニフォームリソース表示（URI）である、請求項29の装置。
  33. 前記サービングドメインは回線交換（CS）サービスドメインである、請求項27の装置。
  34. 前記サービングドメインは、パケット交換（PS）サービングドメインである、請求項27の装置。
  35. 前記サービングドメインのサービングモバイルスイッチングセンター（MSC）において、前記メッセージを受信することをさらに備え、前記サービングMSCは、前記サービングドメインにおいて、ゲートウェイモバイルロケーションセンター（GMLC）にクエリを送信し、前記クエリは緊急呼発信要求またはドメイン転送要求を含み、前記GMLCは、前記緊急呼発信または前記ドメイン転送要求に基づいて、前記サービングMSCにルーティン情報を戻す、請求項33の装置。
  36. 前記GMLCは2つのスキニー呼制御プロトコル（SCCP） E.164アドレスを所有し、前記サービングMSCは、前記緊急およびドメイン転送情報が緊急呼発信を示す場合は一方のアドレスへ、前記緊急およびドメイン転送情報がドメイン転送を示す場合は他方のアドレスへ前記クエリを送信し、前記一方のアドレスは前記緊急呼発信を示し、前記他方のアドレスは前記ドメイン転送要求を示す、請求項25の装置。
  37. 前記GMLCは、どのSCCPアドレスに前記クエリが送信されたかに基づいて、前記ルーティング情報を決定する、請求項36の装置。
  38. 前記ルーティング情報は緊急サービスルーティングデジット（ESRD）または緊急サービスルーティングキー（ESRK）を備える、請求項37の装置。
  39. 前記クエリを前記GMLCへ送信すること、および、前記GMLCから前記ルーティング情報を受信することは、前記サービングMSCにとって透明である、請求項38の装置。
  40. 前記緊急およびドメイン転送情報は、前記UEが音声呼継続性をサポートできることを示す、請求項27の装置。
  41. 前記緊急呼発信は、VCC ドメイン転送機能（DTF）において、前記緊急呼を固定することを含む、請求項27の装置。
  42. 前記VCC DTFは修正VDIおよび修正VDNを前記UEに戻す、請求項41の装置。
  43. 前記修正VDIおよび前記修正VDNはSIP200 OKメッセージで前記UEに戻される、請求項42の装置。
  44. 前記クエリはMAP加入者位置報告（SLR）であり、前記緊急呼発信またはドメイン転送要求は前記MAP SLRの予備パラメータに含まれる、請求項35の装置。
  45. 前記緊急呼発信要求または前記ドメイン転送要求は、前記UEがVCCをサポートすることを示す、請求項35の装置。
  46. 前記ドメイン転送を実行することは、VCC ドメイン転送機能（DTF）において前記UEのため呼記録を見つけることを含む、請求項27の装置。
  47. 前記呼記録が見つからない場合に、前記UEに誤りメッセージを戻すことをさらに備える、請求項46の装置。
  48. 前記ドメイン転送を実行するために使用されるISUP初期アドレスメッセージ（IAM）において、サービングセルIDまたはMSC IDを含むことをさらに備える、請求項33の装置。
  49. 前記サービングセル表示（ID）またはMSC IDは、前記IAMにおいて汎用数列パラメータに含まれる、請求項48の装置。
JP2010541569A 2008-01-04 2009-01-02 無線緊急呼のために音声呼継続性（ｖｃｃ）をサポートする装置と方法 Expired - Fee Related JP5118208B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US1910308P 2008-01-04 2008-01-04
US61/019,103 2008-01-04
US12/346,645 2008-12-30
US12/346,645 US8340627B2 (en) 2008-01-04 2008-12-30 Support of voice call continuity (VCC) for wireless emergency calls
PCT/US2009/030008 WO2009089085A1 (en) 2008-01-04 2009-01-02 Apparatus and methods of supporting voice call continuity (vcc) for wireless emergency calls

Publications (2)

Publication Number Publication Date
JP2011512703A JP2011512703A (ja) 2011-04-21
JP5118208B2 true JP5118208B2 (ja) 2013-01-16

Family

ID=40513382

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010541569A Expired - Fee Related JP5118208B2 (ja) 2008-01-04 2009-01-02 無線緊急呼のために音声呼継続性（ｖｃｃ）をサポートする装置と方法

Country Status (7)

Country Link
US (1) US8340627B2 (ja)
EP (1) EP2238729B1 (ja)
JP (1) JP5118208B2 (ja)
KR (1) KR101243955B1 (ja)
CN (1) CN101911647B (ja)
TW (1) TW200943868A (ja)
WO (1) WO2009089085A1 (ja)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101292489B (zh) * 2005-08-22 2013-03-27 北方电讯网络有限公司 用于电路交换子***呼叫的多媒体子***业务控制
US8811954B1 (en) 2005-10-31 2014-08-19 Genband Us Llc Network domain selection
US8665818B2 (en) * 2006-06-02 2014-03-04 Qualcomm Incorporated Method and system for dynamic anchoring of circuit-switched calls
US8331961B1 (en) 2006-06-12 2012-12-11 Apple, Inc. Transfer of emergency services session between disparate subsystems
US8180338B1 (en) 2006-06-14 2012-05-15 Genband Us Llc Selective call anchoring in a multimedia subsystem
US8045568B2 (en) * 2006-09-29 2011-10-25 Genband Us Llc Enterprise mobility
US8600006B2 (en) * 2006-12-27 2013-12-03 Genband Us Llc Voice continuity among user terminals
US8169968B1 (en) * 2007-05-10 2012-05-01 Rockstar Consortium Reducing communication silence when performing inter-technology handoff
US8644298B1 (en) 2007-09-12 2014-02-04 Genband Us Llc Adding a service control channel after session establishment
US8504635B2 (en) * 2008-04-28 2013-08-06 Alcatel Lucent Method and apparatus for IMS support for multimedia session, recording, analysis and storage
US9928379B1 (en) 2008-09-08 2018-03-27 Steven Miles Hoffer Methods using mediation software for rapid health care support over a secured wireless network; methods of composition; and computer program products therefor
EP2347607B1 (en) * 2008-11-12 2020-01-01 Nokia Technologies Oy Method, apparatus and computer readable storage medium for supporting srvcc emergency call
WO2010055410A1 (en) * 2008-11-17 2010-05-20 Nokia Corporation Method for srvcc emergency call support
US8879526B2 (en) * 2009-01-22 2014-11-04 Telefonaktiebolaget L M Ericsson (Publ) Method and system for addressing a mobile terminal
JP5506819B2 (ja) * 2009-01-27 2014-05-28 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 緊急呼の処理
US9432409B2 (en) * 2009-03-12 2016-08-30 At&T Intellectual Property I, L.P. Apparatus and method for managing emergency calls
US9332041B2 (en) * 2009-03-24 2016-05-03 Blackberry Limited System and method for providing a circuit switched domain number
US9002315B2 (en) * 2009-05-01 2015-04-07 Qualcomm Incorporated Systems, apparatus and methods for facilitating emergency call service in wireless communication systems
ES2809240T3 (es) * 2009-05-26 2021-03-03 Alcatel Lucent Procedimiento y aparatos para la transferencia de sesiones entre redes de acceso
US8879486B2 (en) * 2009-06-18 2014-11-04 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangements in a mobile telecommunications system
RU2513914C2 (ru) 2009-06-18 2014-04-20 Телефонактиеболагет Л М Эрикссон (Пабл) Способы и устройства в телекоммуникационной сети
US8570883B1 (en) * 2009-07-10 2013-10-29 Sprint Communications Company L.P. Selective power mode control of wireless communication devices
US8514876B2 (en) * 2009-08-11 2013-08-20 Cisco Technology, Inc. Method and apparatus for sequencing operations for an incoming interface check in data center ethernet
US8270574B2 (en) * 2009-09-08 2012-09-18 Verizon Patent And Licensing Inc. Emergency calls in internet protocol multimedia subsystem (IMS) over evolved packet core (EPC) networks
CA2776248C (en) 2009-10-02 2016-06-14 Research In Motion Limited Determining establishment causes for emergency sessions
CN102550077B (zh) * 2009-10-30 2014-06-25 上海贝尔股份有限公司 减小isc会话切换中的信令延迟的方法、网络单元和***
WO2011056034A2 (en) * 2009-11-09 2011-05-12 Lg Electronics Inc. Method for controlling session and server using the same
EP2534881B1 (en) * 2010-02-12 2014-01-15 Telefonaktiebolaget LM Ericsson (publ) Handover from circuit switched to packet switched
CN101827322B (zh) 2010-03-02 2013-02-13 华为终端有限公司 一种业务控制方法和装置
EP2536220B1 (en) 2010-06-02 2016-11-16 HTC Corporation Methods and apparatuses for controlling PS and CS communication services
JP4834167B1 (ja) 2010-06-04 2011-12-14 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法及び移動通信システム
CN103155607B (zh) * 2010-10-05 2016-03-23 诺基亚技术有限公司 用于紧急回叫或点击拨号会话的单无线电语音呼叫连续性
WO2012088717A1 (zh) * 2010-12-31 2012-07-05 华为技术有限公司 业务切换方法、装置及***
US8842662B2 (en) * 2011-01-07 2014-09-23 Samsung Electronics Co., Ltd. Techniques for trunk optimization for IMS voice calls between originating UE and terminating UE homed in a circuit switched network
JP5805200B2 (ja) * 2011-02-16 2015-11-04 ノキア ソリューションズ アンド ネットワークス オサケユキチュア 非常サービスのための登録を維持する方法及び装置
US8989697B2 (en) 2011-05-11 2015-03-24 Qualcomm Incorporated Priority registration for in-vehicle emergency call service
US8849237B2 (en) * 2011-05-11 2014-09-30 Qualcomm Incorporated Priority registration for in-vehicle emergency call service
JP5626166B2 (ja) * 2011-09-22 2014-11-19 日本電気株式会社 移動通信方法、移動通信システム、移動局の通信方法、移動局、制御ノードの制御方法及び制御ノード
US9338625B2 (en) * 2011-11-23 2016-05-10 Telefonaktiebolaget L M Ericsson (Publ) Geographically redundant and multiple EATF nodes
EP2807857B1 (en) * 2012-01-27 2017-06-28 Telefonaktiebolaget LM Ericsson (publ) Handover of emergency calls from a circuit switched to a packet switched access network
CN104081820A (zh) * 2012-01-27 2014-10-01 瑞典爱立信有限公司 利用单无线电语音呼叫连续性从电路交换接入网络的优先呼叫切换
US8738014B2 (en) * 2012-06-15 2014-05-27 Telefonaktiebolaget L M Ericsson (Publ) Dynamic VCC assignment
US9380609B2 (en) * 2013-08-28 2016-06-28 Qualcomm Incorporated Method and apparatus for processing emergency calls
US9351203B2 (en) 2013-09-13 2016-05-24 Microsoft Technology Licensing, Llc Voice call continuity in hybrid networks
KR102179048B1 (ko) 2013-11-08 2020-11-16 삼성전자 주식회사 패킷망을 통한 응급 콜 서비스를 지속적으로 제공하기 위한 방법
US9992709B2 (en) 2013-12-03 2018-06-05 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic session transfer number for voice call continuity
US9510251B2 (en) 2013-12-31 2016-11-29 Microsoft Technology Licensing, Llc Call handoff initiation in hybrid networks
US9560185B2 (en) 2014-03-19 2017-01-31 Microsoft Technology Licensing, Llc Hybrid telecommunications network connection indicator
US9363711B2 (en) 2014-04-07 2016-06-07 Microsoft Technology Licensing, Llc User experiences during call handovers on a hybrid telecommunications network
US9456333B2 (en) * 2014-07-09 2016-09-27 Microsoft Technology Licensing, Llc Centralized routing in hybrid networks
US9596040B2 (en) * 2015-02-19 2017-03-14 Telefonaktiebolaget Lm Ericsson (Publ) Local oscillator phase synchronization for beamforming and MIMO
US10327126B2 (en) * 2015-06-26 2019-06-18 Nec Corporation Communication apparatus, terminal, and communication method
US9877224B2 (en) * 2015-10-05 2018-01-23 Blackberry Limited Establishing a voice call
US9894504B2 (en) * 2015-11-30 2018-02-13 Verizon Patent And Licensing Inc. Emergency call support for VoLTE roaming within S8 home routing architecture
CN113489748A (zh) 2017-12-29 2021-10-08 黑莓有限公司 用于供给紧急号码的方法和***
EP3811685A1 (en) * 2018-06-25 2021-04-28 Nokia Technologies Oy Apparatus, method and computer program for emergency call
US11729599B2 (en) 2018-10-08 2023-08-15 Nokia Technologies Oy Communication system

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050009499A1 (en) * 2003-07-08 2005-01-13 Karl Koster Systems and methods for billing a mobile wireless subscriber for fixed location service
US7174149B2 (en) 2003-07-14 2007-02-06 Lucent Technologies Inc. Method and system for indirectly establishing a call
US8145182B2 (en) * 2004-05-07 2012-03-27 Interdigital Technology Corporation Supporting emergency calls on a wireless local area network
US7848769B2 (en) * 2005-06-06 2010-12-07 At&T Mobility Ii Llc System and methods for providing updated mobile station location estimates to emergency services providers
CN101208970A (zh) * 2005-06-15 2008-06-25 阿泽尔网络公司 在ip-can与cs网络之间的话音呼叫连续性应用服务器
US10178522B2 (en) * 2005-08-02 2019-01-08 Qualcomm Incorporated VoIP emergency call support
US9137770B2 (en) 2005-09-15 2015-09-15 Qualcomm Incorporated Emergency circuit-mode call support
US20070149166A1 (en) 2005-12-23 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Voice call continuity for emergency calls
EP1985088A4 (en) 2006-01-10 2009-06-17 Research In Motion Ltd SYSTEM AND METHOD FOR SELECTING A DOMAIN IN A NETWORK ENVIRONMENT COMPRISING AN IP MULTIMEDIA SUBSYSTEM NETWORK
KR20070108429A (ko) 2006-02-06 2007-11-12 엘지전자 주식회사 도메인 전환의 요청 방법, 그 단말 및 그 서버
US7706779B2 (en) * 2006-03-16 2010-04-27 Research In Motion Limited System and method for controlling VCC functionality in a network environment including IMS
US8340626B2 (en) 2006-04-28 2012-12-25 Qualcomm Incorporated System and method for supporting voice call continuity for VOIP emergency calls
KR101233176B1 (ko) * 2006-05-02 2013-02-15 엘지전자 주식회사 Ｖｃｃ에서의 호처리 방법, 서버 및 엔티티
CN101115028B (zh) * 2006-07-28 2011-05-18 摩托罗拉*** 在双模接入终端建立分组交换呼叫的方法
IES20070550A2 (en) * 2006-08-03 2008-04-30 Accuris Technologies Ltd A roaming gateway
US7760712B2 (en) * 2006-08-11 2010-07-20 Research In Motion Limited System and method for managing call continuity in IMS network environment
US7668159B2 (en) * 2007-04-25 2010-02-23 Research In Motion Limited Methods and apparatus for obtaining variable call parameters suitable for use in originating a SIP call via a circuit-switched network from a user equipment device
US8681737B2 (en) * 2007-09-21 2014-03-25 Motorola Mobility Llc Method and apparatus for inter-technology handoff between a packet data network and a circuit switched network

Also Published As

Publication number Publication date
KR101243955B1 (ko) 2013-03-13
CN101911647A (zh) 2010-12-08
JP2011512703A (ja) 2011-04-21
EP2238729B1 (en) 2017-11-01
KR20100108584A (ko) 2010-10-07
US8340627B2 (en) 2012-12-25
US20100124897A1 (en) 2010-05-20
TW200943868A (en) 2009-10-16
EP2238729A1 (en) 2010-10-13
CN101911647B (zh) 2014-07-09
WO2009089085A1 (en) 2009-07-16

Similar Documents

Publication Publication Date Title
JP5118208B2 (ja) 無線緊急呼のために音声呼継続性（ｖｃｃ）をサポートする装置と方法
US8340626B2 (en) System and method for supporting voice call continuity for VOIP emergency calls
US10708748B2 (en) VoIP emergency call support
JP5866022B2 (ja) 単一無線ボイスコール継続性ハンドオーバーのための最少のアクセス転送コントロールファンクション要求
EP2238728B1 (en) Method and apparatus for extended call establishment and location support for ims emergency calls
KR101030627B1 (ko) Ｖｏｉｐ 긴급 호출 처리
US8599838B2 (en) System and method for effectuating a SIP call in a network environment including IMS
EP1816823B1 (en) Method and system for routing a SIP call in a network environment including a circuit-switched network and an IP Multimedia Subsystem IMS
CN102970655B (zh) Voip紧急呼叫处理
KR101565626B1 (ko) 패킷 교환 방식 멀티미디어 가입자 서비스들을 제공하는 아키텍처에 의해 정의된 기능들을 갖는 인터페이스들을 갖는 이동 교환국 플랫폼
EP1972123A1 (en) Domain selection system and method operable in a network environment including ims
US9467485B2 (en) Method for switching session of IMS network and EATF
JP2018501745A (ja) トラブルシューティングの方法、装置、およびシステム
KR102340567B1 (ko) Sip 등록을 위한 사용자 단말의 통신 방법 및 그 사용자 단말
TW200816752A (en) System and method for supporting voice call continuity for VoIP emergency calls

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120514

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120522

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120822

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120918

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121018

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151026

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees