(57)【特許請求の範囲】
【請求項１】
無線通信システムにおけるモバイル機器のための緊急セッションを処理する方法であって、
ルーティングエリア更新（ＲＡＵ）手順が進行中であるとき、ネットワークからデタッチ要求メッセージを受信する工程と、
前記デタッチ要求メッセージを受信すると、前記ＲＡＵ手順を中断しない工程と、
前記ＲＡＵ手順と、前記デタッチ要求メッセージに対応するデタッチ手順とを同時に実行する工程とを含むことを特徴とする方法。
【請求項２】
前記ネットワークは、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）、または、ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）であり、
前記デタッチ手順は、前記モバイル機器を前記ネットワークにおける回線交換（ＣＳ）サービスからデタッチするために使用されることを特徴とする請求項１に記載の方法。
【請求項３】
タイマーを始動させる工程と、
前記モバイル機器が前記ＲＡＵ手順を試みていることを示す状態に遷移する工程とをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
無線通信システムにおけるネットワークのための緊急セッションを処理する方法であって、
前記ネットワークがデタッチ要求メッセージをモバイル機器に送信しているとき、前記モバイル機器から、ルーティングエリア更新（ＲＡＵ）手順に対応するＲＡＵ要求メッセージを受信する工程と、
前記ＲＡＵ要求メッセージを受信すると、前記ＲＡＵ要求メッセージを処理して、ＲＡＵ承諾メッセージまたはＲＡＵ拒絶メッセージによって前記モバイル機器に応答する工程とを含むことを特徴とする方法。
【請求項５】
前記ＲＡＵ手順と、前記デタッチ要求メッセージに対応するデタッチ手順とを同時に実行する工程をさらに含むことを特徴とする請求項４に記載の方法。
【請求項６】
無線通信システムにおけるモバイル機器のための緊急セッションを処理する方法であって、
ルーティングエリア更新（ＲＡＵ）手順が進行中である場合に、ネットワークからデタッチ要求メッセージを受信する工程と、
前記デタッチ要求メッセージを受信すると、前記ＲＡＵ手順を中断して、前記デタッチ要求メッセージに対応するデタッチ手順を実行する工程と、
前記デタッチ手順が完了すると直ちに、前記ＲＡＵ手順を再開する工程とを含み、
前記ネットワークは、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）、または、ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）であり、
前記デタッチ手順は、前記モバイル機器を前記ネットワークにおける回線交換（ＣＳ）サービスからデタッチするために使用されることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムにおいて緊急セッションを処理する方法に関し、より詳細には、異常なシナリオにおける緊急セッションを処理する方法に関する。
【背景技術】
【０００２】
ユニバーサル移動体通信システム（ＵＭＴＳ：Universal Mobile Telecommunications System）またはロングタームエボルーション（ＬＴＥ：long-term evolution）システムなどの無線通信システムでは、緊急セッションは、ネットワークから、制限されたサービス状態にあるモバイル機器に提供される場合が多い。制限されたサービス状態において緊急サービスを受信することは、サブスクリプションを必要としないが、モバイル機器は、システムから提供される緊急サービスにアクセスするために、まず、ネットワークとのセッションを構築しなければならない。
【０００３】
ＵＭＴＳは、回線交換（ＣＳ）サービスおよびパケット交換（ＰＳ）サービスの両方を提供するが、ＬＴＥシステムは、パケット交換（ＰＳ）サービスだけをサポートするように設計されている。ＵＭＴＳでは、ネットワークは、複数の基地局（Ｎｏｄｅ−Ｂ）と無線ネットワーク制御装置（ＲＮＣ）とを備える、ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ：universal terrestrial radio access network）と呼ばれ、一方、モバイル機器は、ユーザ装置（ＵＥ）と呼ばれる。ＬＴＥでは、進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：evolved universal terrestrial radio access network）が、複数の進化型Ｎｏｄｅ−Ｂ（ｅＮｏｄｅＢ）を含み、ユーザ装置（ＵＥ）とも呼ばれる複数の移動局と通信する。
【０００４】
ＵＭＴＳでは、ＵＥは、外部のネットワーク（例えば、インターネット）におけるサービスにアクセスする前に、当該サービスをサポートすることが可能なサービング汎用パケット無線システム（ＧＰＲＳ）サポートノード（ＳＧＳＮ）および特定ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に適合するために、パケットデータプロトコル（ＰＤＰ）コンテキストアクティブ化手順を実行して、ＰＤＰコンテキスト（パケットをトンネリングするためのルーティング情報を含む）をアクティブ化する必要がある。
【０００５】
ＬＴＥでは、ＵＥとパケットデータネットワーク（ＰＤＮ）との間には、シームレスインターネットプロトコル（ＩＰ）接続性が、インターネットにアクセスするための進化型パケットシステム（ＥＰＳ：evolved packet system）ベアラを介して、提供される。このＥＰＳベアラは、ＥＰＳベアラコンテキストアクティブ化手順によって構築される。ＬＴＥ／ＬＴＥアドバンスシステムでは、ＧＧＳＮはパケットデータネットワークゲートウェイ（Ｐ−ＧＷ）と呼ばれ、ＳＧＳＮはサービングゲートウェイ（Ｓ−ＧＷ）と呼ばれることに留意されたい。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許出願公開第2006/0089137号明細書（2006年4月27日公開）
【非特許文献】
【０００７】
【非特許文献１】3rd Generation Partnership Project，”3GPP TS 24.301 V9.3.0 (2010-06) Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (Release 9)”，June 2010
【非特許文献２】3rd Generation Partnership Project，”3GPP TSG-CT WG1 Meeting #65 C1-102909 24.301 CR 0831 rev 3 Current version:8.6.0 Correction on CS Fallback procedure using Release with Redirection”，June 2010
【非特許文献３】3rd Generation Partnership Project，”3GPP TS 24.008 V9.3.0 (2010-06) Technical Specification; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 9)”，June 2010
【非特許文献４】InterDigital LLC, Huawei, "Requesting emergency bearer services from a CSG cell in LTE", 3GPP TSG-CT WG1 Meeting #65, C1-102354, 28 June - 2 July 2010, Dublin (Ireland), XP050443091, P. 1-5.
【非特許文献５】HTC, "Handling of an emergency EPS context when user plane radio bearer can not be established", 3GPP TSG-CT WG1 Meeting #66, C1-102961, 23-27 August 2010, Xi'an (P.R. China), XP002660399, P. 1-5.
【非特許文献６】HTC, "Handling of collision of a Network Initiated Detach procdure with a Service Request procedure and a RAU procedure", 3GPP TSG-CT WG1 Meeting #66, C1-103240 Rev of C1-102962, Xi'an (P.R. China), 23-27 August 2010, XP002668134, P. 1-9.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
３ＧＰＰ技術仕様書ＴＳ ２４．３０１ リリース９は、サービス要求手順の間に、対応するユーザ・プレーン無線ベアラが構築されない場合には、ネットワーク内の、ＵＥおよびモビリティマネジメントエンティティ（ＭＭＥ）が、ＥＰＳまたはＰＤＰコンテキストを局所的に非アクティブにすることを定めている。これは、もし、ネットワークにおいて無線リソースが利用可能でなく（例えば、Ｅ−ＵＴＲＡＮが十分なリソースを有しておらず）、Ｅ−ＵＴＲＡＮがユーザ・プレーン無線ベアラを緊急コンテキストのために割り当てない場合、緊急呼出を行うために緊急ＥＰＳまたはＰＤＰコンテキストを構築するならば、ＵＥおよびネットワークは、緊急ベアラサービス用のＥＰＳコンテキストを非アクティブにすることになることを意味している。従って、ユーザが、緊急呼出を再びダイアルすると、ＵＥは、緊急セッションを構築するために、コンテキストアクティブ化手順およびサービス要求手順を再び開始する必要がある。この冗長な、緊急コンテキストの非アクティブ化およびアクティブ化は、余計な時間を要し、緊急時にはクリティカルである。最悪の場合、ＵＥが緊急ベアラサービス用のＥＰＳコンテキストだけを有しており、ネットワークがこのコンテキストにリソースを割り当てることが不可能であるならば、ＵＥは、緊急ＥＰＳコンテキストを局所的に非アクティブにし、アタッチ（接続）手順を再び実行することになる。これは、結果的に、不要な追加のシグナリングを生じさせ、従って、緊急セッションの構築における遅延を引き起こす。
【０００９】
加えて、従来技術によれば、緊急セッションは、緊急セッション用のサービス要求手順と、異常なシナリオ中にネットワークによって開始されたデタッチ（切断）手順との間の衝突によって、中断されることもある。３ＧＰＰ技術仕様書ＴＳ ２４．００８ リリース９は、ＵＥが緊急サービスセッション用のサービス要求手順を開始させると（すなわち、GMM-SERVICE-REQUEST-INITIATED状態、またはEMM-SERVICE-REQUEST-INITIATED状態にあるとき）、ＵＥは、サービス要求手順を中断し、ネットワークからデタッチ要求メッセージを受信した後にデタッチ手順を実行することを定めている。例えば、デタッチタイプ“IMSI detach”を有するデタッチ要求メッセージを受信して、ＣＳサービスからＵＥをデタッチした後、ＵＥは、組み合わされたトラッキングエリア更新手順を実行して、ＣＳサービスのために再びアタッチする必要がある。この手順は、緊急呼出アクティブ化手順を中断し、従って、ユーザは、デタッチ手順およびその後のアタッチ手順が終了する前に、別の緊急サービスを開始することが不可能になる。あるいは、ＵＥが、デタッチタイプ“re-attach not requited”を有するデタッチ要求メッセージを受信して、ＰＳサービスからＵＥをデタッチするならば、ＵＥは、サービス要求手順を中断し、デタッチ手順を実行することになる。同様に、ネットワークも、サービス要求手順を中断し、デタッチ手順を実行することになる。この場合、緊急セッションは、デタッチ手順およびその後の緊急アタッチ手順が終了した後にのみ、構築され得る。従って、緊急呼出は、遅延されることになる。スピードが重視される幾つかのケースでは、この遅延は、重大な問題となる。
【００１０】
最終的に、ネットワークは、デタッチタイプ“Re-attach not required”およびＧＰＲＳモビリティマネジメント（ＧＭＭ）理由（cause）“IMSI unknown in HLR”を有するデタッチ要求メッセージを送信して、ＵＥをＣＳサービスからデタッチすることが可能である。ネットワークがデタッチ手順を開始する間に、ＵＥがルーティングエリア更新（ＲＡＵ）手順を試みてネットワーク内のＵＥの場所を更新する場合には、ＵＥおよびネットワークは、ＲＡＵ手順を中断し、ネットワークにより開始されたデタッチ手順が、実行されることになる。この場合、次のＲＡＵ手順は、ＲＡＵタイマーの周期が満了するか、または、ＵＥがルーティングエリアを変更する時に、開始されることになる。この周期の間、ＵＥは、ネットワークからのページングは出来ず、従って緊急コールバックは、機能しないことになる。
【００１１】
上述のように、従来技術では、様々な異常なシナリオが、緊急セッションの構築時に、不要且つ冗長なシグナリング遅延を引き起こし得た。従って、従来技術に対する改善が必要とされている。
【課題を解決するための手段】
【００１２】
無線通信システムにおける緊急セッションを処理する方法が提供される。
【００１３】
無線通信システムにおけるモバイル機器のための緊急セッションを処理する方法が開示される。この方法は、ルーティングエリア更新手順が進行中であるとき、ネットワークからデタッチ要求メッセージを受信する工程と、デタッチ要求メッセージを受信すると、ＲＡＵ手順を中断しない工程と、ＲＡＵ手順とデタッチ要求メッセージに対応するデタッチ手順とを同時に実行する工程とを含む。
【００１４】
無線通信システムにおけるネットワークのための緊急セッションを処理する方法が開示される。この方法は、ネットワークがデタッチ要求メッセージをモバイル機器に送信しているとき、モバイル機器から、ＲＡＵ手順に対応するルーティングエリア更新要求メッセージを受信する工程と、ＲＡＵ要求メッセージを受信すると、ＲＡＵ要求メッセージを処理して、ＲＡＵ承諾メッセージまたはＲＡＵ拒絶メッセージによってモバイル機器に応答する工程とを含む。
【００１５】
無線通信システムにおけるモバイル機器のための緊急セッションを処理する方法が開示される。この方法は、ルーティングエリア更新手順が進行中である場合に、ネットワークからデタッチ要求メッセージを受信する工程と、デタッチ要求メッセージを受信すると、ＲＡＵ手順を中断して、デタッチ要求メッセージに対応するデタッチ手順を実行する工程と、デタッチ手順が完了すると直ちに、ＲＡＵ手順を再開する工程とを含む。
【００１６】
本発明のこれらの目的または他の目的は、様々な図面に図解される以下の好ましい実施形態の詳細な説明を読めば、当業者に明らかとなろう。
【図面の簡単な説明】
【００１７】
【図１】無線通信システムを示す概略的な図である。
【図２】一実施形態に係る典型的な通信装置を示す概略的な図である。
【図３】一実施形態に係る典型的なプロセスを示すフローチャートである。
【図４】一実施形態に係る典型的なプロセスを示すフローチャートである。
【図５】一実施形態に係る典型的なプロセスを示すフローチャートである。
【図６】一実施形態に係る典型的なプロセスを示すフローチャートである。
【図７】一実施形態に係る典型的なプロセスを示すフローチャートである。
【図８】一実施形態に係る典型的なプロセスを示すフローチャートである。
【図９】一実施形態に係る典型的なプロセスを示すフローチャートである。
【発明を実施するための形態】
【００１８】
［関連出願の相互参照］
本願は、「Method to handle emergency session in abnormal scenarios」を名称とする、２０１０年８月５日出願の米国仮出願第６１／３７０，８１３号の利益を主張するものである。当該出願の内容を、本願の一部とする。
【００１９】
［発明の詳細な説明］
図１を参照されたい。図１は、無線通信システム１０を示す概略的な図である。簡単に言うと、無線通信システム１０は、１つのネットワークと、複数のモバイル機器とから構成されている。図１では、ネットワークおよびモバイル機器は、単に、無線通信システム１０の構造を図解するために利用されている。無線通信システム１０は、汎欧州デジタルセルラーシステム（ＧＳＭ（登録商標）：Global System for Mobile communications）、ユニバーサル移動体通信システム（ＵＭＴＳ）、ロングタームエボルーション（ＬＴＥ：long-term evolution）システム、またはＬＴＥ−アドバンスドシステムであってよい。例えば、無線通信システム１０がＬＴＥシステムであるならば、ネットワークは、複数の基地局（ｅＮｏｄｅＢｓ）を備える進化型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Evolved Universal Terrestrial Radio Access Network）と呼ばれ得るが、モバイル機器は、ユーザ装置（ＵＥ）と呼ばれる。ＵＥは、携帯電話やコンピュータシステムなどの機器であってよい。さらに、ネットワークおよびＵＥは、伝送方向に応じて、送信機または受信機として見なすことが可能である。例えば、アップリンク（ＵＬ）の場合、ＵＥが送信機であり、ネットワークが受信機であり、ダウンリンク（ＤＬ）の場合、ネットワークが送信機であり、ＵＥが受信機である。
【００２０】
図２は、典型的な通信装置２０を示す概略的な図である。通信装置２０は、図１に示したモバイル機器であってよいが、これに限定されない。通信装置２０は、マイクロプロセッサまたは特定用途向け集積回路（ＡＳＩＣ）などの処理手段２００、記憶ユニット２１０、および通信インターフェースユニット２２０を含んでいてよい。記憶ユニット２１０は、処理手段２００がアクセスするためのプログラムコード２１４を記憶することが可能な任意のデータ記憶装置であってよい。記憶ユニット２１０の例には、subscriber identity module（ＳＩＭ）、読込専用メモリ（ＲＯＭ）、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、ハードディスク、および光学データ記憶装置が含まれるが、これらに限定されない。通信インターフェースユニット２２０は、好ましくは、無線トランシーバであり、処理手段２００の処理結果に応じて、ネットワークと無線信号を交換することが可能である。
【００２１】
図３を参照されたい。図３は、典型的なプロセス３０を示すフローチャートである。プロセス３０は、ネットワークＮＴ１とＵＥ  ＵＥ１とを備える無線通信システム１０において緊急セッションを処理するために、ネットワークＮＴ１（例えば、図１のネットワーク）に利用される。プロセス３０は、プログラムコード２１４にコンパイルされることが可能であり、次のステップを含む。
【００２２】
ステップ３００：開始。
【００２３】
ステップ３１０：緊急セッションに対応する、ＵＥ  ＵＥ１のための緊急コンテキストＥＣ１を有する。
【００２４】
ステップ３２０：ネットワークＮＴ１が緊急コンテキストＥＣ１に無線リソースを割り当てない場合には、ＵＥ  ＵＥ１のための緊急コンテキストＥＣ１を非アクティブにしない。
【００２５】
ステップ３３０：緊急コンテキストＥＣ１を保持する。
【００２６】
ステップ３４０：終了。
【００２７】
プロセス３０によれば、ネットワークＮＴ１が、ＵＥ  ＵＥ１のための緊急コンテキストＥＣ１を有する。緊急コンテキストＥＣ１は、ＬＴＥ用の緊急ＥＰＳベアラコンテキストであってもよいし、または、ＵＭＴＳ用の緊急ＰＤＰコンテキストであってよい。ネットワークＮＴ１は、ＬＴＥ用のＥ−ＵＴＲＡＮであってよい。無線リソースが、利用できず、ネットワークが無線ベアラを緊急コンテキストＥＣ１に割り当てない場合には、ネットワークＮＴ１は、緊急ベアラサービス用の緊急コンテキストＥＣ１を非アクティブにせず、緊急コンテキストＥＣ１を保持する。好ましくは、緊急コンテキストＥＣ１は、進化型パケットシステム（ＥＰＳ：evolved packet system）コンテキストである。この状態では、ＵＥ  ＵＥ１が緊急呼出発信を行わなければならない場合、ＵＥ  ＵＥ１は、ＥＰＳコンテキスト手順を再び開始する必要はない。従って、冗長な非アクティブ化ステップおよびアクティブ化ステップを、省くことが可能である。さらに、不要な追加のシグナリング、および緊急セッションを構築時の遅延は、回避される。
【００２８】
このため、無線通信システム内のＵＥ  ＵＥ１は、対応するアクションを行うことが可能である。図４を参照されたい。図４は、典型的なプロセス４０を示すフローチャートである。プロセス４０は、緊急セッションを処理するために、無線通信システム１０内のＵＥ  ＵＥ１において、利用される。プロセス４０は、プログラムコード２１４にコンパイルされることが可能であり、次のステップを含む。
【００２９】
ステップ４００：開始。
【００３０】
ステップ４１０：緊急セッションに対応する、ネットワークＮＴ１からの緊急コンテキストＥＣ１を有する。
【００３１】
ステップ４２０：ネットワークが緊急コンテキストＥＣ１に無線リソースを割り当てない場合には、緊急コンテキストＥＣ１を非アクティブにしない。
【００３２】
ステップ４３０：終了。
【００３３】
プロセス４０によれば、ネットワークＮＴ１が、ＵＥ  ＵＥ１のための緊急コンテキストＥＣ１を有するが、緊急コンテキストＥＣ１に無線リソースを割り当てないならば、ＵＥ  ＵＥ１は、緊急コンテキストＥＣ１を局所的に非アクティブにすることを禁止される。従って、ＵＥ  ＵＥ１が緊急呼出を行う場合には、ＵＥ  ＵＥ１は、ＥＰＳコンテキスト手順を再び開始する必要はない。従って、冗長な非アクティブ化ステップおよびアクティブ化ステップを、省くことが可能である。さらに、不要な追加のシグナリング、および緊急セッションを構築時の遅延は、回避される。
【００３４】
簡単に言うと、プロセス３０および４０によれば、ネットワークＮＴ１が、ユーザ・プレーン無線リソースを、ＵＥ  ＵＥ１に割り当てない場合、ネットワークＮＴ１およびＵＥ  ＵＥ１は、緊急コンテキストＥＣ１（例えば、緊急ＥＰＳベアラコンテキスト）を保持するので、不要な追加のシグナリング、および緊急セッションを構築時の遅延は、回避される。
【００３５】
図５を参照されたい。図５は、典型的なプロセス５０を示すフローチャートである。プロセス５０は、ネットワークＮＴ２とＵＥ  ＵＥ２とを含む無線通信システムにおいて緊急セッションを処理するために、ＵＥ  ＵＥ２に利用される。ＵＥ  ＵＥ２は、ネットワークＮＴ２におけるＰＳサービスおよびＣＳサービスの両方のためにアタッチされている。プロセス５０は、プログラムコード２１４にコンパイルされることが可能であり、次のステップを含む。
【００３６】
ステップ５００：開始。
【００３７】
ステップ５１０：ネットワークＮＴ２において、緊急セッションに対応するサービス要求手順ＳＲＱ＿ｐを開始する。
【００３８】
ステップ５２０：サービス要求手順ＳＲＱ＿ｐを開始するとき、または、サービス要求手順ＳＲＱ＿ｐを開始した後に、ネットワークＮＴ２からデタッチ要求メッセージＤＲＱ＿ｍを受信する。
【００３９】
ステップ５３０：デタッチ要求メッセージＤＲＱ＿ｍを受信すると、サービス要求手順ＳＲＱ＿ｐを中断しない。
【００４０】
ステップ５４０：終了。
【００４１】
プロセス５０によれば、ＵＥ  ＵＥ２は、ネットワークＮＴ２におけるＰＳサービスおよびＣＳサービスの両方のために、アタッチされる。ネットワークＮＴ２は、ＬＴＥ用のＥ−ＵＴＲＡＮであってもよいし、または、ＵＭＴＳ用のＵ−ＴＲＡＮであってもよい。サービス要求手順ＳＲＱ＿ｐは、緊急セッションに対応する、ネットワークＮＴ２におけるＰＳサービスのためのものであり、例えば、ネットワークＮＴ２において、緊急ＥＰＳコンテキスト、緊急ＰＤＰコンテキスト、またはユーザ・プレーン無線ベアラを構築するためのものである。ＵＥ  ＵＥ２は、サービス要求手順ＳＲＱ＿ｐを開始するとき、または、サービス要求手順ＳＲＱ＿ｐを開始した後、すなわち、ＵＥ  ＵＥ２が、GMM-SERVICE-REQUEST-INITIATED（ＵＭＴＳの場合）またはＥＭＭ-SERVICE-REQUEST-INITIATED（ＬＴＥの場合）といったモビリティマネジメント（ＭＭ）状態にある場合に、ネットワークＮＴ２からデタッチ要求メッセージＤＲＱ＿ｍを受信する。この状態では、サービス（例えば、緊急ベアラサービス）は、中断されることなく、維持され得る。冗長な遅延は回避され得る。
【００４２】
あるケースでは、デタッチ要求メッセージＤＲＱ＿ｍは、デタッチ手順ＤＲＱ１＿ｐに対応し、ネットワークＮＴ２におけるＣＳサービスからＵＥ  ＵＥ２をデタッチすることが可能である。ＵＥ  ＵＥ２が、ＰＳサービス用のサービス要求手順ＳＲＱ＿ｐを開始する間、または開始した後に、ネットワークＮＴ２からデタッチ要求メッセージＤＲＱ＿ｍを受信すると、ＵＥ  ＵＥ２は、ＰＳドメイン用のサービス要求手順ＳＲＱ＿ｐを中断することを禁止される。ＵＥ  ＵＥ２は、サービス要求手順ＳＲＱ＿ｐを続行する。例えば、ＵＥ  ＵＥ２は、ＰＳサービスおよびＣＳサービスの両方のために、ネットワーク動作モードＩ（ＮＭＯ  Ｉ）のネットワークにアタッチされたＩＭＳＩであってよく、ＵＥ  ＵＥ２が、ＰＳサービス要求手順ＳＲＱ＿ｐを開始して、ＰＤＰコンテキストまたはユーザ・プレーンベアラを構築する間に、ＵＥ  ＵＥ２は、デタッチ要求メッセージＤＲＱ＿ｍを受信する。デタッチ要求メッセージＤＲＱ＿ｍは、デタッチタイプ“IMSI detach”であるか、または、ＧＭＭ理由“IMSI unknown in HLR”を有するデタッチタイプ“Re-attach not required”である。その後、ＵＥ  ＵＥ２は、ＰＳサービス手順ＳＲＱ＿ｐを中断せず、ＰＳサービス要求手順ＳＲＱ＿ｐを実行する。従って、ネットワークＮＴ２は、ＵＥ  ＵＥ２からの、ＰＳサービスのためのサービス要求を無視しないことになり、不要な追加のシグナリング、および緊急セッションを構築時の遅延は回避される。
【００４３】
別のケースでは、デタッチ要求メッセージＤＲＱ＿ｍは、デタッチ手順ＤＲＱ２＿ｐに対応し、ネットワークＮＴ２におけるＰＳサービスからＵＥ  ＵＥ２をデタッチすることが可能である。ＵＥ  ＵＥ２が、サービス要求手順ＳＲＱ＿ｐを開始している間、またはサービス要求手順ＳＲＱ＿ｐを開始した後に、受信されたデタッチ要求メッセージＤＲＱ＿ｍが、ＵＥ  ＵＥ２をＰＳサービスからデタッチするためのデタッチタイプ“Re-attach not required”を有しているならば、ＵＥ  ＵＥ２は、サービス要求手順ＳＲＱ＿ｐを中断することを禁止され、サービス要求手順ＳＲＱ＿ｐを続行する。サービス要求手順ＳＲＱ＿ｐは、緊急ベアラサービス用のＰＤＰコンテキストを構築するためのものであり得る。ＵＥ  ＵＥ２は、もしあるとすれば、全ての非緊急ＰＤＰコンテキストを非アクティブにする。ＵＥ  ＵＥ２は、デタッチ承諾メッセージを、ネットワークに送信し、ＵＥ  ＵＥ２自体が、緊急ベアラサービスためだけにアタッチされていることを認める。ＵＥ  ＵＥ２は、緊急ＰＤＰコンテキストまたは緊急ＥＰＳコンテキストのためのＰＤＰまたはＥＰＳコンテキストアクティブ化手順を開始する。
【００４４】
従って、無線通信システムにおけるネットワークＮＴ２は、対応するアクションを行うことが可能である。典型的なプロセス６０のフローチャートを示す図６を参照されたい。プロセス６０は、ネットワークＮＴ２およびＵＥ  ＵＥ２を含む無線通信システムにおける緊急セッションを処理するために、ネットワークＮＴ２に利用される。プロセス６０は、プログラムコード２１４にコンパイルされることが可能であり、次に示すステップを含む。
【００４５】
ステップ６００：開始。
【００４６】
ステップ６１０：ネットワークＮＴ２がデタッチ手順ＤＲＱ＿ｐを開始するとき、ＵＥ２からサービス要求メッセージＳＲＱ＿ｍを受信する。
【００４７】
ステップ６２０：サービス要求メッセージＳＲＱ＿ｍを破棄も無視もせずに、サービス要求メッセージＳＲＱ＿ｍに対応するサービス要求手順ＳＲＱ＿ｐを進める。
【００４８】
ステップ６３０：終了。
【００４９】
プロセス６０によれば、緊急セッションに対応するネットワークＮＴ２におけるＰＳサービス用の、つまり、緊急ＥＰＳ／ＰＤＰコンテキストまたはユーザ・プレーン無線ベアラを構築するために、サービス要求メッセージＳＲＱ＿ｍはサービス要求手順ＳＲＱ＿ｐに対応する。デタッチ手順ＤＲＱ＿ｐは、ＵＥ  ＵＥ２をＣＳおよびＰＳサービスからデタッチするために、デタッチ手順ＤＲＱ１＿ｐまたはデタッチ手順ＤＲＱ２＿ｐであってもよい。ネットワークＮＴ２は、ＰＳサービスに対するサービス要求メッセージＳＲＱ＿ｍを無視または破棄することは禁止されており、対応するサービス要求手順ＳＲＱ＿ｐを進める。
【００５０】
例えば、ネットワークＮＴ２がネットワーク動作モードＩ（ＮＭＯ  Ｉ）にて動作しており、ＰＳおよびＣＳサービスの両方が添付されたＰＳサービス要求メッセージＳＲＱ＿ｍをＵＥ  ＵＥ２から受信する場合、デタッチタイプ“IMSI detach”またはＧＭＭ理由“IMSI unknown in HLR”を有するデタッチタイプ“Re-attach not required”のデタッチ要求メッセージＤＲＱ＿ｍが送信されている間、ネットワークＮＴ２は、をＵＥ  ＵＥ２からのＰＳサービス要求メッセージＳＲＱ＿ｍを無視するべきではなく、サービス要求手順ＳＲＱ＿ｐを進める。つまり、ネットワークＮＴ２はＰＤＰコンテキストを構築し、ユーザ・プレーン無線ベアラのためにリソースを確保する。それゆえ、デタッチ手順ＤＲＱ＿ｐによる遅延および後続の冗長なリアタッチステップはスキップされ、緊急セッションの構築における不必要な遅延は避けられる。
【００５１】
簡潔に言えば、プロセス５０および６０によれば、ネットワークＮＴ２は、緊急セッションの構築はデタッチ手順ＤＲＱ＿ｐによって遅延されないように、デタッチ手順ＤＲＱ＿ｐを開始するときにＵＥ  ＵＥ２からのサービス要求メッセージＳＲＱ＿ｍを破棄も無視もしない。
【００５２】
典型的なプロセス７０のフローチャートを示す図７を参照されたい。プロセス７０は、ネットワークＮＴ３およびＵＥ  ＵＥ３を含む無線通信システムにおける緊急セッションを処理するために、ユーザ装置ＵＥ３に利用される。プロセス７０は、プログラムコード２１４にコンパイルされることが可能であり、次に示すステップを含む。
【００５３】
ステップ７００：開始。
【００５４】
ステップ７１０：ルーティングエリア更新（ＲＡＵ）手順ＲＡＵ＿ｐが進行しているとき、ネットワークＮＴ３からデタッチ要求メッセージＤＲＱ’＿ｍを受信する。
【００５５】
ステップ７２０：デタッチ要求メッセージＤＲＱ’＿ｍを受信したとき、ＲＡＵ手順ＲＡＵ＿ｐを中断しない。
【００５６】
ステップ７３０：ＲＡＵ手順ＲＡＵ＿ｐおよびデタッチ要求メッセージＤＲＱ’＿ｍに対応するデタッチ要求手順ＤＲＱ’＿ｐを同時に進める。
【００５７】
ステップ７４０：タイマーＴ１を始動させ、ＵＥ  ＵＥ３がＲＡＵ手順ＲＡＵ＿ｐを試みていることを示す状態Ｓ１に遷移する。
【００５８】
ステップ７５０：終了。
【００５９】
プロセス７０によれば、ＲＡＵ手順ＲＡＵ＿ｐが進行中に、ネットワークＮＴ３からのデタッチ要求手順ＤＲＱ’＿ｐに対応するデタッチ要求メッセージＤＲＱ’＿ｍをＵＥ  ＵＥ３が受信したとき、ＵＥ  ＵＥ３はＲＡＵ手順ＲＡＵ＿ｐを中断しない。デタッチ要求メッセージＤＲＱ’＿ｍは、ネットワークＮＴ３においてＣＳサービスからＵＥ  ＵＥ３をデタッチするために、デタッチタイプ“Re-attach not required”およびＧＭＭ理由“IMSI unknown in HLR”を有していてもよい。ＵＥ  ＵＥ３は、ネットワークＮＴ３においてＣＳサービスからデタッチするために、ＲＡＵ手順ＲＡＵ＿ｐおよびデタッチ手順ＤＲＱ’＿ｐを進め、そして、タイマーＴ１を始動させてＲＡＵ手順ＲＡＵ＿ｐを試みていることを示す状態Ｓ１に遷移する。タイマーＴ１は、タイマーＴ３３０２であってもよく、また、状態Ｓ１は、３ＧＰＰ技術仕様書ＴＳ２４．００８に従ってGMM-REGISTERED-ATTEMMPING-TO-UPDATE状態であってもよいが、これに限定されるものではない。それゆえ、ＲＡＵ手順ＲＡＵ＿ｐは中断されず、デタッチ手順ＤＲＱ’＿ｐと衝突したとき成功する。さらに、ＲＡＵ手順ＲＡＵ＿ｐは、タイマーＴ１が満了するか、または、ＵＥ  ＵＥ３がルーティングエリアを変えるまで、遅延しない。
【００６０】
従って、無線通信システムにおけるネットワークＮＴ３は対応するアクションをとってもよい。典型的なプロセス８０のフローチャートを示す図８を参照されたい。プロセス８０は、ネットワークＮＴ３およびＵＥ  ＵＥ３を含む無線通信システムにおける緊急セッションを処理するために、ネットワークＮＴ３に利用される。プロセス８０は、プログラムコード２１４にコンパイルされることが可能であり、次に示すステップを含む。
【００６１】
ステップ８００：開始。
【００６２】
ステップ８１０：ＵＥ  ＵＥ３にデタッチ要求メッセージＤＲＱ’＿ｍを送信したとき、ＵＥ  ＵＥ３から、ＲＡＵ手順ＲＡＵ＿ｐに対応するルーティングエリア更新（ＲＡＵ）要求メッセージＲＡＵ＿ｍを受信する。
【００６３】
ステップ８２０：ＲＡＵ要求メッセージＲＡＵ＿ｍを受信すると、ＲＡＵ要求メッセージＲＡＵ＿ｍを処理し、ＲＡＵ承諾メッセージＲＡＵ＿ＡＣ＿ｍまたはＲＡＵ拒絶メッセージＲＡＵ＿ＲＪ＿ｍをＵＥ  ＵＥ３に応答する。
【００６４】
ステップ８３０：ＲＡＵ手順ＲＡＵ＿ｐとデタッチ要求メッセージＤＲＱ’＿ｍに対応するデタッチ手順ＤＲＱ’＿ｐとを同時に進める。
【００６５】
ステップ８４０：終了。
【００６６】
プロセス８０によれば、ＣＳサービスからＵＥ  ＵＥ３にデタッチ要求メッセージＤＲＱ’＿ｍを送信している間に、ネットワークＮＴ３がＵＥ  ＵＥ３からＲＡＵ要求メッセージＲＡＵ＿ｍを受信したとき、ネットワークＮＴ３は、ＵＥ  ＵＥ３をＣＳサービスからデタッチするために、ＲＡＵ手順ＲＡＵ＿ｐとデタッチ手順ＤＲＱ’＿ｐとを同時に進め、そして、ＲＡＵ承諾メッセージＲＡＵ＿ＡＣ＿ｍまたはＲＡＵ拒否メッセージＲＡＵ＿ＲＪ＿ｍによってＵＥ  ＵＥ３に応答する。
【００６７】
もう一つの方法として、ネットワークＮＴ３が、ＲＡＵ手順ＲＡＵ＿ｐとデタッチ手順ＤＲＱ’＿ｐとを同時に進めないようにすることが可能である。典型的なプロセス９０のフローチャートを示す図９を参照されたい。プロセス９０は、ＵＥ  ＵＥ３に利用される。プロセス９０は、プログラムコード２１４にコンパイルされることが可能であり、次に示すステップを含む。
【００６８】
ステップ９００：開始。
【００６９】
ステップ９１０：ＲＡＵ手順ＲＡＵ＿ｐが進行中のとき、ネットワークＮＴ３からデタッチ要求メッセージＤＲＱ’＿ｍを受信する。
【００７０】
ステップ９２０：デタッチ要求メッセージＤＲＱ’＿ｍを受信すると、ＲＡＵ手順ＲＡＵ＿ｐを中断し、デタッチ要求メッセージＤＲＱ’＿ｍに対応するデタッチ手順ＤＲＱ’＿ｐを進める。
【００７１】
ステップ９３０：デタッチ手順ＤＲＱ’＿ｐが完了すると直ちにＲＡＵ手順ＲＡＵ＿ｐを再開する。
【００７２】
ステップ９４０：終了。
【００７３】
プロセス９０によれば、ＲＡＵ手順と、ネットワークＮＴ３のＣＳサービスからＵＥ  ＵＥ３をデタッチするためのデタッチ手順ＤＲＱ’とを同時には進めない。その代わりに、ＲＡＵ手順は中断され、デタッチ手順ＤＲＱ’＿ｐが完了した後に再開される。
【００７４】
簡潔に言えば、プロセス７０、８０、および９０によれば、ＲＡＵ手順ＲＡＵ＿ｐは、デタッチ手順ＤＲＱ’＿ｐと同時に進められるか、または、デタッチ手順ＤＲＱ’＿ｐが完了した後に直ちに再開される。よって、ＲＡＵ手順ＲＡＵ＿ｐは、タイマーＴ１が満了するか、または、ＵＥ  ＵＥ３がルーティングエリアを変更するまで遅延することなく、よって、ＵＥ  ＵＥ３はネットワークＮＴ３からのページングを失うことがない。そして、緊急コールバック手順は失敗しない。
【００７５】
上述したプロセス３０から９０の各ステップは、ハードウェア、ハードウェア装置とコンピュータ命令とハードウェア装置に読み取り専用ソフトウェアとして常駐するデータとのの組み合わせとして知られるファームウェア、または、電気システムであり得る手段によって実現される。ハードウェアの例としては、マイクロ回路、マイクロチップ、またはシリコンチップとして知られているアナログ、デジタル、および混合された回路である。電気システムの例として、system on chip（ＳＯＣ）、system in package（ＳiＰ）、computer on module（ＣＯＭ）、および、通信デバイス２０が含まれる。
【００７６】
結論として、緊急セッションの構築において不必要な追加のシグナリングおよび遅延を最小限にするために、緊急セッションを処理するとともに、異常なシナリオにおける緊急コンテキストをアクティブに維持する典型例および手段が提供された。
【００７７】
当業者であれば、本発明の教示を維持しつつ、装置および方法の多くの変更例および代替例が成され得ることに直ちに気づくであろう。したがって、上記開示は、添付の特許請求の範囲によってのみ限定されるものと解釈しなければならない。
【００７８】
無線通信システムにおけるネットワークのための緊急セッションを処理する方法が開示される。この方法は、緊急セッションに対応する、モバイル機器のための緊急コンテキストを有する工程と、ネットワークが緊急コンテキストに無線リソースを割り当てない場合に、モバイル機器のための緊急コンテキストを非アクティブにしない工程と、緊急コンテキストを保持する工程とを含む。
【００７９】
無線通信システムにおけるモバイル機器のための緊急セッションを処理する方法が開示される。この方法は、緊急セッションに対応する、ネットワークからの緊急コンテキストを有する工程と、ネットワークが緊急コンテキストに無線リソースを割り当てない場合に、緊急コンテキストを非アクティブにしない工程とを含む。
【００８０】
無線通信システムにおけるモバイル機器のための緊急セッションを処理する方法が開示される。この方法は、ネットワークにおいて、緊急セッションに対応するサービス要求手順を開始する工程と、サービス要求手順を開始するとき、または、サービス要求手順を開始した後に、ネットワークからデタッチ要求メッセージを受信する工程と、デタッチ要求メッセージを受信すると、サービス要求手順を中断しない工程とを含む。
【００８１】
無線通信システムにおけるネットワークのための緊急セッションを処理するための方法が開示される。この方法は、ネットワークがデタッチ手順を開始しているときに、モバイル機器からサービス要求メッセージを受信する工程と、サービス要求メッセージを破棄および無視せずに、サービス要求メッセージに対応するサービス要求手順を実行する工程とを含む。
【図１】
0005469757.tif 000002
【図２】
0005469757.tif 000003
【図３】
0005469757.tif 000004
【図４】
0005469757.tif 000005
【図５】
0005469757.tif 000006
【図６】
0005469757.tif 000007
【図７】
0005469757.tif 000008
【図８】
0005469757.tif 000009
【図９】
0005469757.tif 000010