JP5384723B2 - 通信ネットワークにおける認証手順による緊急通報処理 - Google Patents

Description

本願は、第６１／１６９，９２９号で識別される、２００９年４月１６日出願の米国仮特許出願の優先権を主張するものであり、その開示を全体として参照により本明細書に組み込む。

本発明は、一般に通信ネットワークに関し、より詳細には、緊急通報が認証手順に影響を及ぼすときに緊急通報の処理が行われる通信ネットワークに関する。

本節では、本発明のさらに深い理解の促進に役立ち得る態様を紹介する。したがって、本節の文言はこの観点から読まれるべきであり、何が従来技術であるか、または何が従来技術でないかについての了承事項として理解されるべきではない。

例を挙げると、ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ）によれば、次世代ネットワーク（ＮＧＮ）とは、電気通信サービスを含むサービスを提供でき、かつサービス品質（ＱｏＳ）制御可能な広帯域のさまざまな転送技術を活用できるパケットベースのネットワークであり、サービス関連機能が、基礎となる転送関連技術から独立している。ＮＧＮは、利用者が種々のサービスプロバイダに自在にアクセスすることを可能にすることができる。また、汎用的なモビリティをサポートすることができ、その汎用的なモビリティによって、利用者への一貫したユビキタスなサービス提供を可能にすることができる。

ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）とは、ＮＧＮを開発する取り組みに合わせて、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）の携帯電話規格を改善し、次世代モバイルブロードバンドに、改良されたユーザエクスペリエンスおよび簡略化された技術を提供しようとすることを目的とする３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）である。ＬＴＥ無線アクセス技術はＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と呼ばれており、ネットワークはＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）と呼ばれている。ＥＰＳネットワークのアーキテクチャは、３ＧＰＰ技術仕様書２３．４０１および２３．４０２で説明されており、その開示を全体として参照により本明細書に組み込む。

３ＧＰＰ技術仕様書ＴＳ２３．４０１ ３ＧＰＰ技術仕様書ＴＳ２３．４０２ ３ＧＰＰ技術仕様書ＴＳ３１．１０２ ３ＧＰＰ技術仕様書ＴＳ３１．１０３ ３ＧＰＰ技術仕様書ＴＳ３３．１０２ ３ＧＰＰ技術仕様書ＴＳ２３．１２２

本発明の実施形態は、通信ネットワークで緊急通報が認証手順に影響を及ぼすときに緊急通報を処理するための技法を提供する。

通信ネットワークにおいて、第１のコンピューティングデバイスがユーザ機器を備え、第２のコンピューティングデバイスが認証機能を備えると想定される第１の態様において、方法は以下のステップを含む。

第２のコンピューティングデバイスにおいて、第１のコンピューティングデバイスからの第１のタイプの呼インジケータ（ｃａｌｌ ｉｎｄｉｃａｔｏｒ）メッセージが受信される。この第１のタイプの呼インジケータメッセージに基づいて、第２のコンピューティングデバイスにおいて第１のコンピューティングデバイスのための認証手順を続行するかまたは打ち切るための決定が行われる。第２のコンピューティングデバイスは、第１のコンピューティングデバイスのために第１のタイプの呼を発することを可能にすることができる。第１のタイプの呼は緊急通報とすることができる。

１つまたは複数の例示的実施形態において、認証手順は、第１の認証試行により、第２のコンピューティングデバイスから第１のコンピューティングデバイスに認証要求を送信するステップと、第２のコンピューティングデバイスにおいて、第２のコンピューティングデバイスによって送信された認証要求に応答して第１のコンピューティングデバイスによって送信された認証失敗メッセージを第１のコンピューティングデバイスから受信するステップと、第２のコンピューティングデバイスにおいて、この認証失敗メッセージに応答して第２の認証試行を開始するステップとを含み、第２の認証試行が、第２のコンピューティングデバイスにおいて第１のタイプの呼インジケータメッセージに応答して中止されるようにする。第２の認証試行は、再同期手順を含むことができる。

通信ネットワークは、ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）アーキテクチャを含むことができ、第１のコンピューティングデバイスはモバイル機器（ＭＥ）とＵＳＩＭ（ＵＭＴＳ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）とを備え、第２のユーザデバイスはＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）を備える。認証手順は、ＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）プロトコルを含むことができる。

有利には、本発明の例示的実施形態は、ＬＴＥ環境におけるパケットベースの緊急通報セットアップの改良されたパフォーマンスを提供する。

本発明のこれらおよびその他の特徴および利点は、添付の図面および以下の詳細な説明からさらに明らかになるであろう。

本発明の一実施形態によるモバイルローミングアーキテクチャの図である。 本発明の一実施形態による認証手順の図である。 本発明の一実施形態による再同期手順の図である。 本発明の一実施形態による緊急通報処理手順の図である。 本発明の一実施形態による認証および緊急通報サービスの実装に適した通信ネットワークのハードウェアアーキテクチャの図である。

ＬＴＥ（またはＥＰＳ）ローミングアーキテクチャ１００の一実施形態が図１に示されている。図示のように、アーキテクチャ１００は、ＨＰＬＭＮ（Ｈｏｍｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）１１０と、ＶＰＬＭＮ（Ｖｉｓｉｔｅｄ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）１２０とを含む。

ＨＰＬＭＮ１１０では、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）１１２、ＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）ゲートウェイサーバ１１４、ＰＣＲＦ（Ｐｏｌｉｃｙ Ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）サーバ１１６、およびネットワーク事業者のインターネットプロトコル（ＩＰ）サービス１１８が例示的に示されている。これらのＩＰサービスは、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）、パケット交換システム（ＰＳＳ）などを含むことができるが、これらに限定されない。本明細書では、「ネットワーク事業者」（または「電気通信事業者」）は、電気通信ネットワークを所有および運営させ、したがって加入者にサービス（ＩＭＳ、ＰＳＳなど）を提供する企業と定義されることができる。たとえば、ＮＧＮ事業者とは、ＮＧＮネットワークを所有および動作するネットワーク事業者である。したがって、ネットワーク事業者を定義する２つの特徴は、（１）ネットワークを所有すること、および（２）加入者にサービスを提供し、課金すること、とすることができる。第３の特徴は、ネットワーク事業者が典型的には規制され、それによりネットワーク事業者に、通信の秘密などの確保に対する法的責任を負わせることができることである。ネットワーク事業者の例としては、例示的にはＡＴ＆ＴまたはＶｅｒｉｚｏｎを含むことができる。

ＶＰＬＭＮ１２０では、ＧＳＭ（登録商標） Ｅｄｇｅ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ、（ＧＥＲＡＮ、ここでＧＳＭはＧｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓを指す）およびＵＴＲＡＮ（ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）などであるがこれらに限定されないレガシーネットワークのＳｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）１２２（ＳＧＳＮ、ここでＧＰＲＳはＧｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅを指す）が例示的に示されている。また、Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ（ＭＭＥ）１２４、サービングゲートウェイ１２６、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ ＵＴＲＡＮ ｎｅｔｗｏｒｋ）１２８、およびユーザ機器１３０も例示的に示されている。

サービングゲートウェイ１２６は、Ｅ−ＵＴＲＡＮモビリティのローカルモビリティアンカーであり、接続モードのモバイル用インタフェース間でパケットを交換する。モバイルがアイドルモードの場合、サービングゲートウェイ１２６は、ダウンリンクデータパスを終わらせ、ダウンリンクデータが受信されると、ＭＭＥ１２４の信号を転送することによってデータをバッファに入れ、ページング手順をトリガする役割を果たす。

ＭＭＥ１２４は、Ｅ−ＵＴＲＡＮアクセスの制御プレーン機能である。ＭＭＥ１２４は、モバイルデバイスの認証および重要な管理、ならびにアイドルモードのモバイルの追跡およびページング手順を担当する。

ＵＥ１３０（または移動局（ＭＳ））は、モバイル機器（ＭＥ）と、ＵＭＴＳ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ（ＵＳＩＭ）とから構成される。移動局またはユーザ機器の例としては、携帯電話、ポータブルコンピュータ、無線電子メールデバイス、携帯情報端末（ＰＤＡ）、または他の何らかのユーザモバイル通信デバイスを含むことができるが、これらに限定されない。

Ｅ−ＵＴＲＡＮ１２８は、少なくとも１つのｅＮＢ（ｅＮｏｄｅＢ）ノードを含むアクセスノードから構成され、ｅＮＢ（ｅＮｏｄｅＢ）ノードは、ＵＥがＶＰＬＭＮネットワークにアクセスするための基地局として機能する。

一実施形態では、以下に詳細に説明されるように、ＵＥ１３０（ＭＥ＋ＵＳＩＭ）、ｅＮｏｄｅＢ（Ｅ−ＵＴＲＡＮ１２８）、ＭＭＥ１２４、およびＨＳＳ１１２は、本発明の例示的な原理による影響を受けるネットワーク要素である。

したがって、ＵＥ（ユーザ機器）はＭＥ（モバイル機器）＋ＵＳＩＭであることを理解されたい。ＵＳＩＭとは、物理デバイスＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ、一般に携帯電話の「ＳＩＭカード」として知られている）上にあるソフトウェアかつファイルシステムである。ＵＩＣＣは、不正使用防止スマートカードである。ＵＳＩＭは、３ＧＰＰによって標準化された認証および鍵合意（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ ｋｅｙ ａｇｒｅｅｍｅｎｔ）プロトコル（以下に引用される）であるＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）を終了させる。ＵＭＴＳおよびＥＰＳは、類似したバージョンのＡＫＡを使用する。

以下に、成功するＡＫＡ手順が典型的にはどのように動作するかを示す：
１．最初のアタッチ時に、ＵＥは、その内部にＩｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ（ＩＭＳＩ）を有するアタッチ要求をｅＮｏｄｅＢに送信する（セルサイト、Ｅ−ＵＴＲＡＮの一部）。
２．ｅＮｏｄｅＢはそのアタッチ要求をＭＭＥに転送し、ＭＭＥはＩＭＳＩのルーティングラベルを見て、ＵＥの、ＨＳＳを有するホームシステムがどこにあるかを知る。
３．ＭＭＥは、そのＨＳＳに、内部にＩＭＳＩを有する要求メッセージを転送する。
４．ＨＳＳはある計算を行う：乱数ＲＡＮＤを選択し、ＲＡＮＤを使用し、ＵＳＩＭルートキーＫと共有して、認証トークンＡＵＴＮ、ＸＲＥＳ（予想される応答）、および別のルートキーＫ_ＡＳＭＥを計算する。
５．次に、ＨＳＳが、ＡＫＡ ＡＶ（認証ベクトル）を持つＭＭＥに応答する。ＥＰＳ ＡＶは、以下のパラメータを有する：ＲＡＮＤ、ＡＵＴＮ、ＸＲＥＳ、およびＫ_ＡＳＭＥ。
６．ＭＭＥはＥＰＳ ＡＶを受信すると、ＸＲＥＳおよびＫ_ＡＳＭＥを保持し、ＵＳＩＭにｅＮｏｄｅＢおよびＭＥを介してＲＡＮＤおよびＡＵＴＮを転送する。
７．ＵＳＩＭが最初に行うことは、ＡＵＴＮを認証することであり、その認証成功後でのみ、ＵＳＩＭはＲＥＳおよびそれ自体のＫ_ＡＳＭＥを計算する。
８．次にＵＳＩＭは、他のＥＰＳキーを得るためにＭＥにルートキーＫ_ＡＳＭＥを送信し、ＭＭＥにＭＥおよびｅＮｏｄｅＢを介してＲＥＳを送信する。

ＭＭＥは、（ＵＳＩＭから受信した）ＲＥＳと（ＨＳＳから受信した）ＸＲＥＳを比較する。それらが互いに等しい場合、ＵＳＩＭ（およびＵＳＩＭ＋ＭＥ＝ＵＥ）は、サービングネットワークに受け入れられる。

したがって、一実施形態では、ＵＥは、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ（ＡＫＡ）アルゴリズムを認識するアプリケーションプロトコルをサポートすると想定される。そのうえ、この例示的実施形態では、ＵＥは、ＡＫＡアルゴリズムを実装するＵＭＴＳ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ（ＵＳＩＭ）アプリケーションをサポートすると想定される。ＵＳＩＭアプリケーションに関する詳細は、３ＧＰＰ技術仕様書ＴＳ３１．１０２およびＴＳ３１．１０３に見受けられ、その開示を全体として参照により本明細書に組み込む。ＡＫＡに関する詳細は、３ＧＰＰ技術仕様書ＴＳ３３．１０２に見受けられ、その開示を全体として参照により本明細書に組み込む。

この特定の実施形態では３ＧＰＰ認証プロトコルの態様を利用するが、このようなプロトコルは使用できるセキュリティプロトコルの一例であることを理解されたい。したがって、３ＧＰＰ認証プロトコルと類似の機能および特徴を提供する他の適切なセキュリティプロトコルは、本発明の実施形態の範囲内にあると見なすことができる。

Ｅ−ＵＴＲＡＮ初期アタッチ手順は、緊急サービスを実施する必要があるがネットワークから通常のサービスを用いることはできない、ＵＥによる緊急アタッチ（Ｅｍｅｒｇｅｎｃｙ Ａｔｔａｃｈ）に使用される。これらのＵＥは、３ＧＰＰ技術仕様書ＴＳ２３．１２２（「Ｎｏｎ−Ａｃｃｅｓｓ−Ｓｔｒａｔｕｍ （ＮＡＳ） ｆｕｎｃｔｉｏｎｓ ｒｅｌａｔｅｄ ｔｏ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ （ＭＳ） ｉｎ ｉｄｌｅ ｍｏｄｅ」）で定義される制限されたサービス状態（Ｌｉｍｉｔｅｄ Ｓｅｒｖｉｃｅ ＭｏｄｅすなわちＬＳＭ）にあり、その開示を全体として参照により本明細書に組み込む。

セルに通常アタッチできるＵＥ、すなわち制限されたサービス状態にないＵＥは、まだアタッチされていないときは、通常の開始アタッチを開始する。

図２は、例示的な認証および鍵確立手順２００、たとえばＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）手順またはプロトコルを示す。ＡＫＡ手順の目的は、ユーザを認証し、ＭＭＥとＵＳＩＭの間で新しいルートキーＫ_ＡＳＭＥを確立することである。認証中に、ＵＳＩＭは、使用された認証ベクトルの新しさを検証する。

図２（および以下に説明される図３および図４）に示されるエンティティの間で送信されるメッセージは、エンティティによって実装される１つまたは複数の通信プロトコルに従って送受信される信号であることを理解されたい。一連のメッセージ転送は、（いくつかのさらなるメッセージの追加および／またはいくつかのメッセージの削除により）再構成または修正しても、本発明の原理に起因する利点の１つまたは複数を提供できることも理解されたい。

ＭＭＥは、認証ベクトル（ＡＶ）を選択することによって手順を呼び出す。ＭＭＥ１２４は、ＵＳＩＭ（ＵＥ１３０）に、ランダムチャレンジ（ｒａｎｄｏｍ ｃｈａｌｌｅｎｇｅ）ＲＡＮＤと、認証ベクトルからのネットワーク認証ＡＵＴＮのための認証トークンとを送信する。これは、図２のステップ１に示されている。

図２のステップ２では、ＵＳＩＭが、ＭＭＥに、ランダムチャレンジに対するレスポンスを認証応答ＲＥＳの形で返信する。このレスポンスが適切な場合は、認証は通常通り（すなわち、上述のように）続行する。

しかし、同期失敗の場合は、ＵＥ１３０は、ＭＭＥ１２４に、適切な応答ではなく同期失敗メッセージ（図２のステップ３ユーザ認証拒否ＣＡＵＳＥメッセージ）を送信する。

ＭＭＥは、ＵＥから同期失敗メッセージを受信すると、ＨＳＳ１１２に、以下のパラメータと共に「同期失敗標識（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｆａｉｌｕｒｅ ｉｎｄｉｃａｔｉｏｎ）」を有する認証データ要求を送信する：
− 先行するユーザ認証要求においてＭＳに送信されたＲＡＮＤ、および
− 先行するユーザ認証要求に対する応答においてＭＭＥによって受信された、ＴＳ３３．１０２に記載されるようなＡＵＴＳ。

これは図３に示されている。図３は、同期失敗メッセージによって応答されるユーザ認証要求と、認証データ応答によって応答される同期失敗標識を有する認証データ要求とを組み合わせることによって再同期を達成するための手順３００を示す。

図示のように、ステップ１（ＭＭＥがチャレンジを送信する）およびステップ２（ＵＥがＡＵＴＳ応答を送信する）の後で、ステップ３において、ＭＭＥがＨＳＳにＲＡＮＤおよびＡＵＴＳを送信する。

ＭＭＥ１２４は、ＵＥ１３０からの非請求の「同期失敗標識」メッセージに対して応答しないことに留意されたい。

ＭＭＥ１２４は、ＨＳＳ１１２からその認証データ要求に対する応答を受信する前（またはタイムアウトになる前）に、新しいユーザ認証要求をそのユーザに送信しないことにも留意されたい。

ＨＳＳ１１２は、（図３のステップ３において）「同期失敗標識」を有する認証データ要求を受信すると、以下のように作用する：
１．ＨＳＳは、

を計算することによって、Ｃｏｎｃ（ＳＱＮ_ＭＳ）からＳＱＮ_ＭＳを取得する。ＳＱＮはシーケンス番号を表し、「Ｃｏｎｃ」は連結関数を表すことに留意されたい。
２．ＨＳＳは、ＳＱＮ_ＨＥが適正な範囲にあるかどうか、すなわち生成された次のシーケンス番号ＳＱＮ_ＨＥがＵＳＩＭによって受け入れられるかどうかを確認する。
３．ＳＱＮ_ＨＥが適正な範囲にある場合、ＨＳＳは以下のステップ（６）に進み、そうでない場合は以下のステップ（４）に進む。
４．ＨＳＳがＡＵＴＳを検証する。
５．検証が成功した場合、ＨＳＳはカウンタＳＱＮ_ＨＥの値をＳＱＮ_ＭＳにリセットする。
６．ＨＳＳは、ＭＭＥに、新しいバッチの認証ベクトルを有する認証データ応答を送信する（図３のステップ４のＱ_ｉ）。カウンタＳＱＮ_ＨＥがリセットされなかった場合は、これらの認証ベクトルは記憶領域から得ることができ、そうでない場合は、認証ベクトルはＳＱＮ_ＨＥのリセット後に新たに生成される。ＨＳＳにかかるリアルタイム計算の負担を減少させるために、ＨＳＳは、後者の場合に単一の認証ベクトルのみを送信することもできる。

ＭＭＥ１２４は、同期失敗標識を有する認証データ要求に対する認証データ応答においてＨＳＳ１１２から新しい認証ベクトルを受信するたびに、ＭＭＥのそのＵＥ１３０に対する古い認証ベクトルを削除する。

ＵＥ１３０はこれで、ＨＳＳ１１２からの新しい認証ベクトルに基づいて認証されることができる。

しかし、上記の認証セッション中に問題が発生することがある。ＡＫＡ（再）認証中に１つまたは複数の理由でＵＳＩＭ上でのＡＵＴＮ検証が失敗（図２のユーザ認証拒否ＣＡＵＳＥ）しても、ＵＥ１３０が緊急通報（ＥＣ）を作成する必要があると想定する。

正常な状態（たとえば上記で引用したＴＳ３３．１０２を参照されたい）では、ＵＥ１３０は、ＭＡＣ（メディアアクセス制御）認証失敗時に新しいＡＫＡ認証を要求するか、またはＳＱＮの不一致時にＡＵＴＳ手順（そのＨＳＳによる再同期）に入る。このような場合、ＭＭＥ１２４はＲＥＳを受信せず、ＵＥ１３０はＫ_ＡＳＭＥを生じない。

言い換えれば、ＵＥ１３０は、新しいＡＫＡ（ＭＡＣ失敗）を待機するか、またはその後のＨＳＳによる再同期および新しいＡＫＡを待機する。新しいＡＫＡラウンドトリップは最大約１０−１５秒とすることができ、ＨＳＳによる再同期にほぼ同じ時間かかることがある。最悪の場合、ＵＥ１３０は、意図されている呼を続行できるようになるために約３０秒待機しなければならない。ＭＭＥ１２４は、再同期時間を制御することも、緊急通報を行うことを意図するＵＥ１３０への通信を行うための再同期時間を推定することもできない。この機能の相互作用は許容できないことがあり、および／またはこのような緊急通報には不必要であることがあることは理解されよう。

一実施形態によれば、以下のような解決策が提供される。図４は、このような解決策を実装するための手順４００を示す。

ＵＥ１３０のＭＥ（上述のように、ＭＥはＵＥ１３０の一部であるが機能的にはＵＳＩＭから分離していることに留意されたい）は緊急通報を行う意図を知っているので、ＭＥがその意図を、緊急通報（ＥＣ）インジケータを介してＭＭＥ１２４に通信できることは理解されよう。

図４に示すように、ステップ１でＭＭＥが（ＵＥの）ＭＥにユーザ認証要求を送信し、ステップ２でＭＥが（同様にＵＥの）ＵＳＩＭに要求を転送すると想定する。さらに、ＵＳＩＭから認証失敗を受信する（ステップ３）と、ＭＥはそれをＭＭＥに転送し（ステップ４）、新しいＡＫＡ、または再同期＋新しいＡＫＡを期待するのをやめると想定する。その代わり、ＭＥは、認証されていないアタッチモードを想定して、そのようなモードに進む。

ネットワーク側では、ＭＭＥ１２４は、ＥＣを行うというＵＥの意図を、ステップ５で送信されたＥＣインジケータを介して知っている。ＵＥから認証失敗を受信すると、ＭＭＥは、通常の認証／再同期手順（図２および図３で上記に概説した）に従うのをやめる。その代わり、ＭＭＥは、認証されていないアタッチモードを想定して、そのようなモードに進む。ＭＭＥは、ＥＣのみを通過させることを許可する。

上記の例におけるＥＣインジケータメッセージは、認証失敗メッセージがＭＭＥによって受信された後で送信されるので、認証手順は有利には中止または打ち切られることができることに留意されたい。あるいは、ＥＣインジケータメッセージは、同じ認証セッションでこれより早く、かつ認証が実際に始まる前に受信することができるが、その場合、認証手順は有利には、開始されないかまたは完全に打ち切られることが可能である。したがって、ＥＣインジケータメッセージは、セッションで受信されるたびに、有利にはＭＭＥが認証手順に関する決定（たとえば打ち切るか続行するか）を下すことを可能にするのに役立ち得ることが理解されよう。

いずれにしても、ＥＣ呼が終了した後で、両当事者（ＵＥおよびＭＭＥ）は通常の認証手順にリセットする。ＥＣを作成しようとしながら認証が失敗したときにＭＥおよびＭＭＥの挙動を基本的に制御するのは、ＥＣインジケータの存在である。

緊急アタッチの場合、ＵＥのＭＥは、アタッチタイプを「Ｅｍｅｒｇｅｎｃｙ（緊急）」に設定し、認証されない緊急通報に進む。

ＭＭＥ１２４が緊急アタッチをサポートするように構成され、ＵＥがアタッチタイプ「Ｅｍｅｒｇｅｎｃｙ」を示した場合、ＭＭＥは認証およびセキュリティセットアップをスキップするか、またはＭＭＥは認証が失敗することがあることを受け入れ、アタッチ手順を続行する。

ＭＭＥ１２４が緊急アタッチをサポートするように構成されない場合、ＭＭＥは、アタッチタイプ「Ｅｍｅｒｇｅｎｃｙ」を示すいかなるアタッチ要求も拒否する。

最後に、図５は、本発明の上述の原理による認証および緊急通報処理サービスの実装に適した通信ネットワーク５００の汎用的なハードウェアアーキテクチャを示す。

図示のように、ユーザ機器５１０（ＵＥ１３０に相当する）およびＭＭＥサーバ５２０（ＭＭＥ１２４に相当する）は、通信ネットワーク媒体５５０を介して動作可能に結合される。ネットワーク媒体は、その上でユーザ機器およびウェブサーバが通信することを望む任意のネットワーク媒体とすることができる。例を挙げると、このネットワーク媒体は、エンドツーエンドでＩＰパケットを運ぶことができ、前述の通信ネットワークのいずれかを含んでよい。しかし、本発明は特定のタイプのネットワーク媒体に限定されない。典型的には、ユーザ機器５１０はクライアントマシンまたはデバイスとすることができ、ＭＭＥ５２０はサーバマシンまたはデバイスとすることができる。本明細書には明示的に示されていないが、図１に示されるその他のネットワーク要素（以下に説明されるのと同じプロセッサ／メモリ構成を有することができる）がＭＭＥおよび／またはＵＥに動作可能に結合されることは理解されよう。

当業者には容易に明らかであるように、サーバおよびクライアントは、コンピュータプログラムコードの制御下で動作するプログラムされたコンピュータとして実装することができる。コンピュータプログラムコードは、コンピュータ（またはプロセッサ）可読な記憶媒体（たとえば、メモリ）に格納され、コードはコンピュータのプロセッサによって実行される。本発明のこの開示を考慮して、当業者は、本明細書において説明されるプロトコルを実装するために、適切なコンピュータプログラムコードを容易に作製することができる。

それにもかかわらず、図５は、ネットワーク媒体上で通信する各デバイスの例示的なアーキテクチャを全体的に示す。図示のように、ユーザ機器５１０は、Ｉ／Ｏデバイス５１２と、プロセッサ５１４と、メモリ５１６とを備える。ＭＭＥサーバ５２０は、Ｉ／Ｏデバイス５２２と、プロセッサ５２４と、メモリ５２６とを備える。

本明細書では「プロセッサ」という用語は、中央処理装置（ＣＰＵ）を含む１つもしくは複数の処理デバイス、または１つもしくは複数の信号プロセッサ、１つもしくは複数の集積回路などを含むがこれらに限定されない他の処理回路を含むことを意図することを理解されたい。同様に、本明細書では「メモリ」という用語は、ＲＡＭ、ＲＯＭ、固定メモリデバイス（たとえば、ハードドライブ）、または着脱可能なメモリデバイス（たとえば、ディスケットまたはＣＤＲＯＭ）などの、プロセッサまたはＣＰＵに関連するメモリを含むことを意図する。さらに、本明細書では「Ｉ／Ｏデバイス」という用語は、処理ユニットにデータを入力するための１つまたは複数の入力デバイス（たとえば、キーボード、マウス）、ならびに処理ユニットに関連する結果を提供するための１つまたは複数の出力デバイス（たとえば、ＣＲＴディスプレイ）を含むことを意図する。

したがって、本明細書において説明される、本発明の方法を実施するためのソフトウェアの命令またはコードは、ＲＯＭ、固定メモリ、または着脱可能なメモリなどの関連メモリデバイスの１つまたは複数に格納され、利用する準備が整うと、ＲＡＭにロードされてＣＰＵによって実行されることができる。すなわち、図５に示される各コンピューティングデバイス（５１０および５２０）は、図２から図４に示されるプロトコルのそれぞれのステップを実施するように個別にプログラムされることができる。

本明細書では、本発明の例示的実施形態について添付の図面を参照して説明してきたが、本発明はそれらの正確な実施形態に限定されず、本発明の範囲または趣旨から逸脱することなく当業者によって種々の他の変更および修正を加えることができることを理解されたい。

Claims (10)

1. 第１のコンピューティングデバイスがユーザ機器を備え、第２のコンピューティングデバイスが、そのユーザ機器を認証するための認証機能を備える通信ネットワークにおいて、
   第２のコンピューティングデバイスにおいて、第１のコンピューティングデバイスから認証拒否メッセージを受信するステップと、
   第２のコンピューティングデバイスにおいて、第１のコンピューティングデバイスから第１のタイプの呼インジケータメッセージを受信するステップと、
   認証拒否メッセージおよび第１のタイプの呼インジケータメッセージの受信に基づいて、第２のコンピューティングデバイスにおいて第１のコンピューティングデバイスのための認証手順を続行するかまたは打ち切るかに関して決定するステップとを含む、方法。
2. 認証手順を打ち切る決定がなされた場合、第２のコンピューティングデバイスが、第１のタイプの呼を第１のコンピューティングデバイスのために発することを可能にするステップをさらに含む、請求項１に記載の方法。
3. 認証手順が、
   第１の認証試行により、第２のコンピューティングデバイスから第１のコンピューティングデバイスに認証要求を送信するステップと、
   第２のコンピューティングデバイスにおいて第１のコンピューティングデバイスから、第２のコンピューティングデバイスによって送信された認証要求に応答して第１のコンピューティングデバイスによって送信された認証失敗メッセージを受信するステップと、
   第２のコンピューティングデバイスにおいて、認証失敗メッセージを受信した後、第２の認証試行を開始するステップと、
   第１のタイプの呼インジケータメッセージが開始するステップに続いて受信される場合、第２の認証試行を第２のコンピューティングデバイスにおいて中止するステップとを含む、請求項１に記載の方法。
4. 第２の認証試行が再同期手順を含む、請求項３に記載の方法。
5. 第１のタイプの呼が緊急通報である、請求項１に記載の方法。
6. 第１のコンピューティングデバイスがユーザ機器を備え、第２のコンピューティングデバイスが、そのユーザ機器を認証するための認証機能を備える通信ネットワークにおいて、第２のコンピューティングデバイスが、
   メモリと、
   メモリに結合され、第１のコンピューティングデバイスから認証拒否メッセージを受信し、第１のコンピューティングデバイスから第１のタイプの呼インジケータメッセージを受信し、認証拒否メッセージおよび第１のタイプの呼インジケータメッセージの受信に基づいて、第１のコンピューティングデバイスのための認証手順を続行するかまたは打ち切るかに関して決定するように構成されたプロセッサとを備える、装置。
7. プロセッサがさらに、第１のタイプの呼を第１のコンピューティングデバイスのために発することを可能にするように構成された、請求項６に記載の装置。
8. 第１のタイプの呼が緊急通報である、請求項６に記載の装置。
9. 第１のコンピューティングデバイスがユーザ機器を備え、第２のコンピューティングデバイスが、そのユーザ機器を認証するための認証機能を備える通信ネットワークにおいて、
   第１のコンピューティングデバイスから第２のコンピューティングデバイスに認証拒否メッセージを送信するステップと、
   第１のコンピューティングデバイスから第２のコンピューティングデバイスに第１のタイプの呼インジケータメッセージを送信するステップと、
   認証拒否メッセージおよび第１のタイプの呼インジケータメッセージの受信に基づいて、第２のコンピューティングデバイスにおいて第１のコンピューティングデバイスのための認証手順を続行するかまたは打ち切るかに関する決定に応じて、第１のコンピューティングデバイスにより第１の呼タイプの呼を開始するステップとを含む、方法。
10. 第１のタイプの呼が緊急通報である、請求項９に記載の方法。

Images