ワイヤレス・ローカル・エリア・ネットワークにおける緊急呼のサポート

トップ :: H 電気 :: H04 電気通信技術

【発明の名称】	ワイヤレス・ローカル・エリア・ネットワークにおける緊急呼のサポート
【発明者】	【氏名】マリアンルドルフ【氏名】シャミンアブカルラーマン【氏名】ジュアンカルロスズニガ【氏名】ジョセフクァク
【要約】	【課題】ワイヤレス・ローカル・エリア・ネットワークにおいて緊急呼を識別する【構成】ワイヤレス・ローカル・エリア・ネットワークにおいて緊急呼を識別する装置は、呼を緊急呼として識別する表示を含む。表示は、ビットフラグまたは情報要素であるとすることができる。情報要素は、緊急呼を加える端末の位置に関する位置情報を含むことができる。上述の情報は、発呼者の位置を突き止めるのに使用することができる。位置情報を、緊急呼とは別個に、端末からアクセスポイントに送信することができる。

【特許請求の範囲】
【請求項１】
ワイヤレス・ローカル・エリア・ネットワークにおいて緊急呼を識別する装置であって、呼を緊急呼として識別する表示を備えたことを特徴とする装置。
【請求項２】
前記表示が、ビットフラグであることを特徴とする請求項１に記載の装置。
【請求項３】
前記ビットフラグが、メディアアクセス制御のフレームに位置することを特徴とする請求項２に記載の装置。

【発明の詳細な説明】【技術分野】
【０００１】
本発明は、一般には、ワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）に関し、より詳細には、ＷＬＡＮにおいて緊急呼をサポートすることに関する。
【背景技術】
【０００２】
従来、現存する８０２技術（８０２．１１ＷＬＡＮ、８０２．１５ＷＰＡＮ（ＷｉｒｅｌｅｓｓＰｅｒｓｏｎａｌＡｒｅａＮｅｔｗｏｒｋ）など）は、セルラーで行われているような緊急呼をサポートする必要はない。セルラーに対する緊急呼についてのサポートは、セルラー技術に課され、規定された要件に起因することが多く、したがって、現在展開されているワイヤレス・セルラー・ネットワークおよびハンドセットの大部分において広く実装される。緊急呼に対するサポートは、すべての通信レイヤにわたる多くの側面を、特に信号送信のサポートおよび命令手順を含む。緊急呼に対するサポートは、８０２．１１技術および８０２．１５技術に対して存在しない。ＷＬＡＮにおけるＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）の出現およびＷＬＡＮについての増大する日常使用により、ＷＬＡＮにおける緊急呼に対するサポートは、必要になるであろう。
【０００３】
住宅市場に対する「固定」ＶｏＩＰ電話サービスの提供でさえ、制限された緊急呼サポートを含む。電話番号の位置情報を、ＰＳＡＰ（ＰｕｂｌｉｃＳａｆｅｔｙＡｎｓｗｅｒｉｎｇＰｏｉｎｔ）におけるディスパッチャー（ｄｉｓｐａｔｃｈｅｒ）が必ずしもトラッキングを行うことができるとは限らず、コールバックが必ずしも可能であるとは限らないので、アドレス登録を、固定ＶｏＩＰ電話サービスの装置購入のときに必要とすることがある。固定ＶｏＩＰ電話が新しい位置に移動される場合、緊急呼は、依然として、登録されたアドレス位置に基づいて送信されるであろう。原則として、登録されたアドレスを、変更することができるが、遅延は、ＰＳＡＰにおいて情報を更新する場合、少なくとも、およそ何日かまたは何週間かである。さらに、あるユーザは、とにかく即時的なやり方において、登録情報を更新しないかもしれない。
【０００４】
この状況は、ＷＬＡＮを使用するＶｏＩＰ電話により可能となるような、さらなる移動性によってより悪化する。ＷＬＡＮを基にしたＶｏＩＰ電話は、あらゆる位置から作動することができ、ユーザが、職場から自宅へ、公衆のホットスポット（登録商標）へなど、位置間をシームレスにローミングすると思われることがある。
【０００５】
無線アクセス、アクセスポイント（ＡＰ）位置、発呼者位置、および緊急呼許可を含む、８０２．１１仕様のある問題が、存在する。無線アクセスに関しては、緊急呼に対するプライオリティ（ｐｒｉｏｒｉｔｙ）が、８０２．１１規格に現在、存在せず、およびＷＬＡＮアクセスネットワークに対して、緊急呼を一般呼と区別する手段がない。現在、ＡＰまたはＳＴＡ（ｓｔａｔｉｏｎ）の位置は、例えば、ＡＰの識別を容易に決定することができる場合でさえ、専用でない（ｎｏｎ－ｐｒｏｐｒｉｅｔａｒｙ）やり方において、ＷＬＡＮアクセスネットワークに知られていない。さらに、現在、専用でないやり方において、発呼者の位置をマッピングすることが可能でない。
【０００６】
許可に関して、しっかり管理されたＷＬＡＮは、緊急発呼者がネットワークに入る権限を与えられない場合、緊急発呼者が緊急呼を確立することを防止することができる。ＳＴＡとＡＰとの間の通常の接続手順は、ＳＴＡにアソシエーション要求（Ａｓｓｏｃｉａｔｉｏｎｒｅｑｕｅｓｔ）を送信するよう要求する。ＳＴＡがＡＰに対してアソシエーションを行うより前に、ＡＰによるネゴシエーションが続く。ＳＴＡはＳＴＡが緊急呼を生起していることを示すことが不可能である場合、ＳＴＡは、ＳＴＡがネットワークに入ることを許されるかどうかを決定するアソシエーション手順全体を通過しなければならないであろう。この類の困難さの一例として、ＳＴＡがシステムにアクセスするのに適したパスワードまたは認証証明書を有さない場合（例えば、個人のホットスポット（登録商標）または企業／事務所のＷＬＡＮによって存在するかもしれないようなＡＰが、パスワードを要求するかまたは認証証明書を要求するかのように構成される場合）、ＡＰは、ＳＴＡのアソシエーション要求をあからさまに拒絶するであろう。しかしながら、ＳＴＡが適したパスワードまたは認証証明書を有する場合でさえ、ＡＰは、依然として、音声ユーザに対するＡＰの設計された最大能力に基づいてネットワークに入る許可を拒絶することがある。ＡＰに対して、ＳＴＡが適したパスワードまたは認証証明書を有する場合の正しい決定は、新たな緊急呼に（最も高いプライオリティにおいて）入ることを許すこと、および別の現存する音声呼を中断することであろう。現在、第一に、ＡＰが緊急呼の区別を行う手段を欠いているので、このような特徴を、現存する最新のＷＬＡＮ技術によって実施することができない。上述のことと、あらゆる装置が、ＳＩＭカードなしの装置でさえ、緊急呼を生起することができるセルラーシステムの処理とを対比せよ。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、８０２．１１技術および８０２．１５技術による緊急呼処理のサポートを可能にする様々なシステム動作形態を提案する。
【課題を解決するための手段】
【０００８】
本提案のいくつかは、緊急呼をＡＰに示す、新しいＬ２信号メッセージまたは情報要素に関係する。新しい手順および制御機構が、緊急状態に対して提案される。さらに、デュアルモード（ＷＬＡＮおよび第２世代（２Ｇ）セルラーまたは第３世代（３Ｇ）セルラー）実行のための手順に、向けられる。緊急呼要件を、緊急発呼者の場所の位置報告についての規定要件に結び合わせることがよくあるので、ＷＬＡＮネットワークにおける地理的な場所についての要求および報告を可能にする手段および信号発信手順を、提案する。場所情報を、緊急呼に連結することができ、または個々に実装することができる。
【０００９】
ＳＴＡが緊急呼を識別することができる利点は、ＡＰが通常に処理するべき（すなわち、通常のアソシエーション手順に従わせるべき）ＳＴＡと、ネットワークがどう構成されているかに関係なく（すなわち、緊急呼に入ることを許すためにあらゆるセキュリティ要件を迂回する）、すべての状況において入ることを許されるべきＳＴＡとを区別することをＡＰに可能にする簡単な論理を、ＡＰにおいてインストールすることができることである。
【００１０】
ワイヤレス・ローカル・エリア・ネットワークにおいて緊急呼を識別する装置は、緊急呼として呼を識別する表示（ｉｎｄｉｃａｔｏｒ）を含む。緊急呼として呼を識別する表示は、ビットフラグまたは情報要素とすることができる。
【００１１】
ワイヤレス・ローカル・エリア・ネットワークにおいて端末（ｓｔａｔｉｏｎ）の位置情報を報告する装置は、位置情報フィールドを含む。
【００１２】
ＳＴＡによる緊急呼をＷＬＡＮに加える方法は、緊急呼を加えるＳＴＡによって開始する。ＳＴＡがセルラーネットワーク上において動作する性能があるかどうかについての決定が、行われる。緊急呼は、ＳＴＡがセルラーネットワーク上において動作する性能がある場合には、セルラーネットワーク上において継続される。そして、緊急呼がセルラーネットワーク上において完了されたかどうかの決定が、行われる。緊急呼がセルラーネットワーク上において完了されていない場合には、緊急呼は、ＷＬＡＮ上において継続される。
【００１３】
ＳＴＡからＷＬＡＮに緊急呼を加えているユーザの位置を突き止める方法は、ユーザが緊急呼をＳＴＡに加えることにより開始する。緊急信号フレームが、予め定められた時間間隔に対してＳＴＡから送信されることにより、緊急信号フレームを、エマージェンシワーカ（ｅｍｅｒｇｅｎｃｙｗｏｒｋｅｒ）が受信して、ユーザの位置を突き止めることができる。
【００１４】
ＳＴＡからＷＬＡＮに緊急呼を加えているユーザの位置を突き止める方法は、ユーザが緊急呼をＳＴＡに加えることにより開始する。緊急信号フレームが、ＳＴＡから送信され、およびエマージェンシワーカにより受信される。エマージェンシワーカが予め定められたユーザ範囲内にあるかどうかについての決定が、行われる。エマージェンシワーカが予め定められたユーザ範囲内にあると、ユーザとエマージェンシワーカとの間の直接接続が、確立される。
【００１５】
ＷＬＡＮにおいて緊急呼をサポートする方法は、緊急呼をＳＴＡによりＷＬＡＮに加えることによって開始する。緊急呼は、ＷＬＡＮ上においてＡＰにより受信される。ＳＴＡが緊急呼を完了するのに十分な性能を有するかどうかについての決定が、行われる。ＡＰは、ＳＴＡが緊急呼を完了するのに十分な性能を有さない場合には、ＳＴＡに対するプロキシとして動作する。
【００１６】
ＡＰにおいてＷＬＡＮにおけるＳＴＡに対する位置情報を保持する方法は、ＡＰにおいてＳＴＡから位置情報を受信すること、およびＡＰにおいて位置情報を格納することを含む。
【００１７】
ＡＰにおいてＷＬＡＮにおけるＳＴＡに対する位置情報を保持する方法は、ＡＰが位置情報を受信するためにＳＴＡをポーリングすることにより開始する。位置情報は、端末からＡＰに報告され、およびＡＰにおいて格納される。
【００１８】
緊急呼をＷＬＡＮに加える方法は、ＳＴＡがＡＰに対して緊急呼を生起することによって、ＲＴＳ（ＲｅａｄｙＴｏＳｅｎｄ）フレームを送信することにより開始する。ＲＴＳフレームは、ＳＴＡが緊急呼を生起しているという表示を含む。ＲＴＳフレームがＡＰにおいて受信され、および緊急でないＳＴＡが後退させられることによって、緊急呼を生起しているＳＴＡは、緊急でないＳＴＡに先立って、ネットワークにアクセスすることができる。
【００１９】
本発明についてのより詳細な理解を、例として与えられおよび本明細書において添付の図面と結合して理解されるべき、好ましい実施形態についての以下の説明から得ることができる。
【発明を実施するための最良の形態】
【００２０】
本明細書において以後、用語の「端末」（ＳＴＡ）は、制限されないが、ワイヤレス送受信ユニット（ＷｉｒｅｌｅｓｓＴｒａｎｓｍｉｔ／ＲｅｃｅｉｖｅＵｎｉｔ；ＷＴＲＵ）、ユーザ装置、固定もしくは移動の加入者ユニット、ページャ、またはワイヤレス環境において作動する性能のある他のあらゆる類の装置を含む。本明細書において以後参照する場合、用語の「アクセスポイント」（ＡＰ）は、制限されないが、基地局、ノードＢ、サイトコントローラ、またはワイヤレス環境における他のあらゆる類のインタフェース装置を含む。
【００２１】
本発明は、すべてのＷＬＡＮ、ＰＡＮ（ＰｅｒｓｏｎａｌＡｒｅａＮｅｔｗｏｒｋ）、およびＭＡＮ（ＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋ）、特に８０２．１１を基にしたＷＬＡＮ、８０２．１５を基にしたワイヤレスＰＡＮ、８０２．１６／２０を基にしたワイヤレスＭＡＮ、および加えて同等のものに適用可能である。１つの実現において、本発明は、ＷＬＡＮ、ＰＡＮ、ＭＡＮ、およびセルラー・マルチ・モードのＷＴＲＵを含む、ＷＬＡＮ、ＰＡＮおよびＭＡＮのアクセス技術の組合せを実装するＷＴＲＵに適用可能である。
【００２２】
緊急サポートを処理する本発明は、３つの主要な領域に分類され、本明細書において以下に説明されるであろう。しかしながら、このことは、説明の都合のためであり、本発明の制限として受取るべきではない。
【００２３】
（Ｉ．信号送信／サポートおよび手順に関連したエアインタフェース）
（Ａ．ＭＡＣフレームおよびＭＡＣ信号メッセージにおける緊急呼の表示）
図１に、標準規格のＭＡＣフレーム１００を示す。ＭＡＣフレーム１００は、フレーム制御フィールド１０２、デュレーション／ＩＤフィールド１０４、１つまたは複数のアドレスフィールド１０６ａ～１０６ｄ、シーケンス制御フィールド１０８、サービス品質（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ；ＱｏＳ）制御フィールド１１０、フレーム本体１１２、およびフレーム検査シーケンス（ＦｒａｍｅＣｈｅｃｋＳｅｑｕｅｎｃｅ；ＦＣＳ）フィールド１１４を含む。ＱｏＳ制御フィールド１１０は、図に示すような複数のサブフィールドに分割される。
【００２４】
緊急呼に対するプライオリティを、ＭＡＣフレームにおいて、ビットフラグにより、緊急メッセージ型ＩＥにより、既存もしくは新規のＩＥ上における緊急メッセージフィールド部分により、または既存のあらゆるＩＥまたはＭＡＣフレームフィールドにおける予備の（現在未使用の）値を使用して実装される緊急呼コードにより、示すことができる。表示は、ＡＰが緊急呼に入ることを許す必要があることを、ＡＰに知らせることを可能にする。同様の目的のために、ＱｏＳプライオリティまたは要件が、ＱｏＳクラス（例えば、ＤｉｆｆＳｅｒｖ）を用いて示される。既存のあらゆるＭＡＣフレーム型（制御、管理、またはデータ）を、緊急呼表示を含むように変更することができる。緊急呼表示を、説明される機構のいずれかを使用して、ヘッダまたは本体において、ＭＡＣフレームにおけるあらゆる位置に加えることができる。
【００２５】
図２Ａに示すように、ＭＡＣフレーム２００は、図１に関連して上述されたフィールド１０２～１１４と同一であるフィールド２０２～２１４を含む。一実施形態において、簡単なビットフラグ２２０を使用して、これが緊急呼であることを受信機に示す。図２Ａに示すように、ビットフラグ２２０に対して１つの可能な位置は、ＱｏＳ制御フィールド２１０の予備ビット（ビット７）である。当事業者は、ＭＡＣフレームにおいて、既存のヘッダまたはフレーム本体のいずれかにおける現在予備のあらゆる位置にビットフラグ２２０を置くことが可能であることに気づくであろう。
【００２６】
図２Ｂに示すように、ＭＡＣフレーム２５０は、フレーム制御フィールド２５２、長さフィールド２５４、および緊急呼を表示する緊急呼ＩＥ２５６を含む。緊急呼ＩＥ２５６は、制限されないが、緊急呼フラグ２６０、理由コードフィールド２６２、性能情報フィールド２６４、位置情報フィールド２６６、音声コーデック適用フィールド２６８、および追加フィールド２７０を含むことができる。緊急呼ＩＥ２５６を、あらゆるＭＡＣフレームに追加することができる。加えて、緊急呼ＩＥ２５６に含まれる情報を、既存のＩＥ型に追加することができる。
【００２７】
緊急呼フラグ２６０を、呼が緊急呼であることを識別する簡単な表示（例えば、ビットフラグ）とすることができる。理由コードフィールド２６２は、緊急呼に対する理由（例えば、火事、医療緊急事態など）を示す。性能情報フィールド２６４は、ＳＴＡが緊急呼を加える性能を含み、および緊急呼をできるだけ迅速に完了させるのを助けるのに使用される。位置情報フィールド２６６は、緊急呼を加えているＳＴＡの位置を含む。音声コーデック適用フィールド２６８は、ＳＴＡによって使用されている音声コーデックを識別し、および緊急呼を処理しようと試みるＳＴＡと緊急呼との間に非互換性がある場合に使用される。緊急呼ＩＥ中に含むことができる（フィールド２７０のような）追加情報は、タイムスタンプと、ＷＴＲＵおよび／または事業者サービス性能情報とである。
【００２８】
８０２．１１ｅ下の既存のＭＡＣフレームは、呼のプライオリティを含む。ＴＳＰＥＣ（ＴｒａｎｓｍｉｓｓｉｏｎＳＰＥＣｉｆｉｃａｔｉｏｎ）ＩＥは、伝送仕様情報フィールドにおいて３ビットのプライオリティサブフィールドを含む。さらに、本発明の原理を、緊急呼に対する値を定義することによって、ＴＳＰＥＣＩＥにおいて実装することができる。セルラーシステムにおいて、同様の機構（信号フレーム）を使用して、呼パラメータをネットワークに送信し、および同様の機構（信号フレーム）は、緊急呼を識別する予備フィールドを含む。
【００２９】
（Ｂ．位置情報）
さらに、位置情報を、緊急呼確立の理由を伝達することに加えて、これらの新規ＭＡＣフレーム２００、２５０に（例えば、位置情報フィールド２６６において）連結することができる。例えば、ＡＰまたはＳＴＡは、基本サービスセット（ＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ；ＢＳＳ）ＩＤ、ＡＰもしくはＳＴＡのＭＡＣアドレス、静的もしくは動的に割当てられたＩＰアドレス、または全地球測位システム（ＧＰＳ）の機能を実装するＡＰもしくはＳＴＡからのＧＰＳ情報を使用して、位置情報を緊急呼センターに転送することができる。さらに、位置情報を、個々に緊急呼情報により伝達することができることを補足する。
【００３０】
緊急のＳＴＡの位置を突き止める他の手段は、制限されないが、発呼者ＩＤにより緊急呼を加えているＳＴＡを識別すること、コールバック番号を利用すること、および緊急呼センターによりＳＴＡの位置を突き止めるのに役に立つ既知のアドレスを使用すること（例えば、ＡＰもしくはネットワークＩＤ、またはＡＰの地理座標など、ＳＴＡに対する現在の連結点（ｐｏｉｎｔｏｆａｔｔａｃｈｍｅｎｔ）についてのＭＡＣアドレスを使用すること）を含む。
【００３１】
例えば、ＷＬＡＮに対するＭＡＣ信号送信機構を、ＡＰがＳＴＡに位置情報を要求することができる場合に、使用することができる。ＳＴＡは、ＳＴＡの位置情報をつけてＡＰに報告するだろう。１つの可能な実装は、現在、セルラーハンドセットにおいて広く使用されているＡ－ＧＰＳ（ＡｓｓｉｓｔｅｄＧＰＳ）の座標についての使用を含む。限定されないが、Ｕ－ＴＤＯＡ（ＵｐｌｉｎｋＴｉｍｅＤｉｆｆｅｒｅｎｃｅＯｆＡｒｒｉｖａｌ）、Ｅ－ＯＴＤ（ＥｎｈａｎｃｅｄＯｂｓｅｒｖｅｄＴｉｍｅＤｉｆｆｅｒｅｎｃｅ）、ＩＰＤＬ－ＯＴＤＯＡ（ＩｄｌｅＰｅｒｉｏｄＤｏｗｎＬｉｎｋＯｂｓｅｒｖｅｄＴｉｍｅＤｉｆｆｅｒｅｎｃｅＯｆＡｒｒｉｖａｌ）、Ａ－ＧＰＳ、（例えば、ＩＥＥＥ規格８０２．１１ｋまたはＩＥＴＦＲＦＣ３８２５において定義されるような）ＵｎｉｖｅｒｓａｌＧｅｏｇｒａｐｈｉｃＣｏｏｒｄｉｎａｔｅ、ならびにＷＬＡＮのＡＰ位置情報、セルサイト情報、またはセクター情報、およびタイミング進行測定または往復行程の時間測定を用いる方法を含む複数の位置決定方法を、異なるアクセスネットワークに対してサポートすることができる。位置情報を伝達する先行例について特に言及しているが、当事業者は、地理座標を伝達するあらゆる形式を使用することができることに気づくであろう。
【００３２】
緊急呼機能を、位置報告機能から独立して（補足的ではあるが）実行することができる。実例で示すために、以下が可能である。すなわち、（１）ＳＴＡが実際に緊急呼を発呼すると、緊急信号フレームに位置情報を連結すること、および（２）緊急呼がなければスタンドアロンの機能性として位置の更新の信号を送信することである。後者の例は、周期的（例えば、数秒毎）か、ＡＰのバックグランド動作の一部としてのポーリングが行われることか、またはＳＴＡによるＡＰへの自立的な通常の位置報告かのいずれかにより、ＡＰを、最新のＳＴＡの位置情報について通知かつ更新される状態にしておくことであろう。ＡＰにおいて位置情報を保持することは、好ましいことがある。なぜならば、ＳＴＡが緊急呼を発呼すると、ＡＰは、ＳＴＡが緊急呼要求の上にＳＴＡの位置情報を明示的に相乗りさせる必要がないような、ＳＴＡの位置情報の合理的な最近の評価を既に有するからである。
【００３３】
例えば、上述したスタンドアロンのＳＴＡ位置情報報告を、規定要件に取り組むことに対応して、ＷＬＡＮネットワークにおける位置依存のサービスについての実施を可能にするのに使用することができる。
【００３４】
上述のように、さらに、位置情報を、Ｉ－ＷＬＡＮ（ＩｎｔｅｒｗｏｒｋｉｎｇＷＬＡＮ）内に、公衆移動通信網（ＰＬＭＮ）内に、またはＳＴＡにおいて、現存する位置サービス（ＬｏＣａｔｉｏｎＳｅｒｖｉｃｅ：ＬＣＳ）アプリケーションに提供することができる。さらに、発呼者のサービング（ｓｅｒｖｉｎｇ）・セル・アイデンティティ（ｉｄｅｎｔｉｔｙ）、またはサービングＡＰアイデンティティを、ＬＣＳクライアントに提供することができる。
【００３５】
（Ｃ．現存するＲＴＳ／ＣＴＳフレーム交換の機構および手順の拡張）
図３に、標準規格のＲＴＳフレーム３００を示す。ＲＴＳフレーム３００は、フレーム制御フィールド３０２、デュレーションフィールド３０４、受信アドレス（ＲｅｃｅｉｖｅｒＡｄｄｒｅｓｓ；ＲＡ）フィールド３０６、送信アドレス（ＴｒａｎｓｍｉｔｔｅｒＡｄｄｒｅｓｓ；ＴＡ）フィールド３０８、およびＦＣＳフィールド３１０を含む。
【００３６】
緊急呼を送信したいＳＴＡは、図４Ａに示すような特別な信号フラグを含む拡張されたＲＴＳフレーム４００、または図４Ｂに示すような新規のＩＥを含む拡張されたＲＴＳフレーム４５０を送信する。
【００３７】
図４Ａは、ＲＴＳフレーム４００を示す。ＲＴＳフレーム４００のフィールド４０２～４１０は、図３に関連して上述したＲＴＳフレーム３００のフィールド３０２～３１０と同一である。フレーム制御フィールド４０２は、プロトコル・バージョン・サブフィールド４１２、タイプサブフィールド４１４、サブタイプサブフィールド４１６、送信先ＤＳ（ＤｉｓｔｒｉｂｕｔｉｏｎＳｙｓｔｅｍ）サブフィールド４１８、送信元ＤＳサブフィールド４２０、ＭＦ（ＭｏｒｅＦｒａｇｍｅｎｔ）サブフィールド４２２、リトライサブフィールド４２４、電力管理サブフィールド４２６、ＭＤ（ＭｏｒｅＤａｔａ）サブフィールド４２８、ＷＥＰ（ＷｉｒｅｄＥｑｕｉｖａｌｅｎｔＰｒｉｖａｃｙ）サブフィールド４３０、およびオーダー（ｏｒｄｅｒ）サブフィールド４３２を含む、いくつかのサブフィールドを含む。
【００３８】
信号フラグを、ＲＴＳフレーム４００におけるあらゆる予備ビットに加えることができる。予備ビットに対して可能性のある位置は、プロトコル・バージョン・サブフィールド４１２、タイプサブフィールド４１４、およびサブタイプサブフィールド４１６を含む。当事業者が、ＲＴＳフレーム４００におけるあらゆる予備ビットにおいて信号フラグを加えることができるであろうことを補足する。
【００３９】
図４Ｂは、フレーム制御フィールド４５２、デュレーションフィールド４５４、ＲＡフィールド４５６、ＴＡフィールド４５８、目的ＩＥ４６０、およびＦＣＳフィールド４６２を含む拡張されたＲＴＳフレーム４５０を示す。目的ＩＥ４６０は、上述した緊急呼ＩＥ２５６の内容と同種とすることができる。さらにまた、拡張されたＲＴＳフレーム４５０を受信するすべてのＳＴＡは、予め定められた量の時間に対してあらゆる送信の試みを停止することにより、無線媒体を空きにして、緊急状態のＳＴＡに送信する機会を与えることを要求される。
【００４０】
一実施形態において、拡張されたＲＴＳフレームの受信によって、受信するＳＴＡは、緊急呼を加えるＳＴＡに、無線媒体へのアクセスの獲得に成功する、より高い確率を与えるために、変更されたバックオフ（ｂａｃｋｏｆｆ）処理に入る。バックオフ処理を変更する２つの実装が可能である。すなわち、（１）他のＳＴＡと比較して、緊急呼を加えるＳＴＡに対するバックオフ時間を短くすること、または（２）緊急でないＳＴＡに対するバックオフ時間を長くすることである。どちらの実装においても、最終的な結果は、緊急のＳＴＡが、緊急でないＳＴＡよりも、より短いバックオフ時間を有することである。
【００４１】
図５に、ＲＴＳフレーム４００または４５０を使用する方法５００を示す。方法５００の目的は、ＳＴＡに緊急呼を送信することを許可するために、送信媒体を空きにすることである。方法５００は、ＳＴＡがＲＴＳフレーム４００または４５０を送信することにより緊急呼を加えることによって開始する（ステップ５０２）。ＡＰは、ＲＴＳフレームを受信し（ステップ５０４）、および標準規格のＣＴＳフレームを用いてＳＴＡに応答する（ステップ５０６）。ＡＰにより使用されるバックオフタイプが、決定される（ステップ５０８）。２つの可能なバックオフタイプがある。両方のバックオフタイプは、緊急呼を加えるＳＴＡに、送信を待つ他のすべてのＳＴＡより前に送信媒体にアクセスすることを許可するであろう。
【００４２】
緊急状態のＳＴＡ（すなわち、緊急呼を加えるＳＴＡ）が、より短いバックオフ時間を有するバックオフタイプである場合、緊急状態のＳＴＡは、短くされたバックオフ時間の間、待ち（ステップ５１０）、および次に緊急呼を送信する（ステップ５１２）。送信媒体にアクセスすることを試みている他のすべてのＳＴＡは、標準のバックオフ時間の間、待ち（ステップ５１４）、および次に送信することができる（ステップ５１６）。次に、方法５００は、終了する（ステップ５１８）。
【００４３】
他のすべてのＳＴＡが、より長いバックオフ時間を有するバックオフタイプである場合（ステップ５０８）、緊急状態のＳＴＡは、標準のバックオフ時間の間、待ち（ステップ５２０）、および緊急呼を送信する（ステップ５２２）。他のＳＴＡのすべては、より長いバックオフ時間の間、待ち（ステップ５２４）、および次に送信することができる（ステップ５１６）。次に、方法５００は、終了する（ステップ５１８）。
【００４４】
一般に、ＳＴＡがバックオフ手順に入ると、ＳＴＡは、連続したＮ個のタイムスロットの中の１つにおいて無作為に送信することを試みる。送信の衝突がある場合、ＳＴＡは、再度バックオフとなり、Ｎの値を、Ｎに対して予め定められた最大値まで増加させる。送信することを試みることできる前に、ＳＴＡは、Ｍ個のタイムスロットの間、待たなければならない。上述の基本手順は、あらゆるＳＴＡに、送信媒体へのアクセスを獲得することについての平等な機会を提供する。８０２．１１ｅにおいて、ＱｏＳを実施するために、個々の端末が、送信媒体へのアクセスを獲得することについての、より大きい機会を有することを保証する２つの方法がある。第１は、Ｍの値を縮小することによって、ＳＴＡに、より短い待ち時間を与えることである。第２は、Ｎに対して、より小さい値を使用することであり、ＳＴＡが個々のタイムスロットにおいて送信することができる機会を増加させることである。
【００４５】
方法５００において、ＳＴＡが、使用するバックオフ値を識別するいくつかの可能な手段がある。第1の手段は、緊急呼に関連して、ＭおよびＮに対してハードコード化された（ｈａｒｄ－ｃｏｄｅｄ）値が緊急状態のＳＴＡにより使用されるような、ＭおよびＮに対するハードコード化された値を使用することである。第２の手段は、ＡＰから緊急状態のＳＴＡに、ＭおよびＮに対する値を明示的に送信することである。通常、ＡＰは、正常なシステム動作の間に、ブロードキャストフレームかまたは専用管理フレームかのいずれかを使用することによって、それらのパラメータをＳＴＡに送信するであろう。ＳＴＡは、ＳＴＡが緊急呼を設定する必要がある場合に使用される、緊急呼に関連した構成パラメータを読み出す。一例は、ＡＰが、ビーコンまたはプローブの応答管理フレームの部分として、他のＢＳＳの構成値を、ＡＰのＢＳＳにおけるすべてのＳＴＡに送信する。緊急呼に関連したＭおよびＮのパラメータを加えることは、これらの自然な拡張である。例えば、今日では、アクセス種類毎に、ＢＳＳにおけるすべてのＳＴＡにより使用される、８０２．ｌｌｅのＱｏＳに関連した構成パラメータ（バックオフ値、ウィンドウなど）は、ＡＰが同種の機構を使用することによって送信される。
【００４６】
第３の手段は、第１および第２の手段の結合である。第３の手段により、ＳＴＡは、ＳＴＡが通常使用する、ＭおよびＮに対するハードコード化されたデフォルト値を有し、およびＳＴＡが緊急状態にある場合には、ＡＰは、ハードコード化されたデフォルト値に優先するＭおよびＮに対する新しい値を送信するであろう。当事業者は、緊急状態のＳＴＡおよび送信媒体へのアクセスを得ようとする他のすべてのＳＴＡに、適切なバックオフ時間を伝達する追加の手段を想像することができるであろう。
【００４７】
（Ｄ．デュアルモードＷＬＡＮ（例えば、３ＧおよびＷＬＡＮ）のＳＴＡに対する別の無線技術への強制切替）
緊急の場合において、デュアルモードＷＬＡＮのＳＴＡは、第一に、ＷＬＡＮ上でなく、セルラーネットワーク上においてあらゆる緊急呼を試みるであろう。原則として、このことは、ＳＴＡ単独における「ハードコード化された」手順である。図６に、上述の手順を実装する方法６００を示す。
【００４８】
方法６００は、ユーザがＳＴＡにおいて緊急呼を生起することにより開始する（ステップ６０２）。ＳＴＡがセルラーネットワーク上かＷＬＡＮ上かのいずれかにおいて動作する性能があるかどうかの決定が、行われる（ステップ６０４）。ＳＴＡがセルラーネットワーク上において動作する（すなわち、現在、セルラーネットワークに接続している）場合、ＳＴＡは、緊急呼に対して、セルラーネットワーク上のままである（ステップ６０６）。ＳＴＡがセルラーネットワーク上において動作する性能があるが、現在、セルラーネットワークに接続されていない場合、ＳＴＡは、セルラーネットワークへの接続を確立し（ステップ６０８）、およびセルラーネットワーク上において緊急呼を生起する（ステップ６０６）。ＳＴＡがＷＬＡＮ上において動作している場合、ＳＴＡは、セルラーネットワークに切替えて、緊急呼を生起する（ステップ６１０）。
【００４９】
緊急呼が加えられた後に、緊急呼がセルラーネットワーク上を経由したかどうかの決定が、行われる（ステップ６１２）。緊急呼がセルラーネットワーク上を経由した場合には、方法６００を、終了する（ステップ６１４）。緊急呼がセルラーネットワーク上を経由しなかった場合には、ＳＴＡは、ＷＬＡＮに切替わり、緊急呼を生起し（ステップ６１６）、および方法６００を、終了する（ステップ６１４）。
【００５０】
緊急呼がデュアルモードのＷＬＡＮ－セルラーハンドセットにより生起する必要がある場合、好ましい手順は、セルラーモデムの上にハンドセットのフォールバック（ｆａｌｌｂａｃｋ）を有する（すなわち、セルラー無線リンク上に緊急呼を確立する）ことである。なぜならば、緊急呼サポートは、ＷＬＡＮに関して、使用可能でないことがあり、または信頼性がいっそう少ないことがあるからである。
【００５１】
方法６００に対する代替案は、以下を含む。すなわち、（１）緊急呼を送信しようと試みると、切替えるのに、望ましい、強制的な、または推奨される無線技術（例えば、ＷＬＡＮまたはセルラー）についてのオーダーを確立すること、（２）システム運用者が、デュアルモードのハンドセットに対して、ＳＩＭカードまたは同種の装置上において緊急呼ビヘイビアを構成すること、（３）緊急の場合に、ＶｏＩＰ呼をセルラーネットワーク上において保持するか、またはＶｏＩＰ呼を従来技術の回線交換の音声チャンネル上に移動させること、（４）システム運用者が、無線インタフェースを通じて望ましい無線技術についての局所的なオーダーを送信すること、または（５）ユーザが、ポリシー設定を手動により構成することである。
【００５２】
（Ｅ．緊急呼を試みる場合の認証およびセキュリティの迂回）
ＷＬＡＮにおいて緊急呼を確立しようとするあらゆる８０２．ｘｘのＳＴＡが、ＡＰによって許可されるべきである手順は、強制的である。このことは、８０２．１ｘのような認証を、およびネットワーク側における他のセキュリティ手段を迂回することを含む。本手順を、（図５に示すように）拡張されたＲＴＳ／ＣＴＳの方法５００を使用することにより、または（図２Ａおよび図２Ｂに示すように）ＭＡＣフレームにおけるビットフラグ、ＩＥ、ヘッダ、予備情報フィールド、もしくはビット／シーケンス値により、起動することができるであろう。
【００５３】
（ＩＩ．緊急の場合におけるＷＴＲＵビヘイビア／手順）
（Ａ．発呼者の検出を容易にするＷＬＡＮのＳＯＳビーコン信号の送信）
緊急呼が終了すると（または話中であっても）、ＳＴＡおよび／または関与するＡＰが図７に示すようなＳＯＳ型の信号フレーム７００を一定の間隔において送信し始める手順は、ＳＴＡにおいて強制的であるか、またはネットワークにより構成される。
【００５４】
ＳＯＳ信号フレーム７００は、プローブ要求（ＰｒｏｂｅＲｅｑｕｅｓｔ）フレームの修正版である。ＳＯＳ信号フレーム７００は、フレーム制御フィールド７０２、デュレーションフィールド７０４、送信先アドレス（ＤＡ）フィールド７０６、送信元アドレス（ＳＡ）フィールド７０８、ＢＳＳＩＤフィールド７１０、シーケンス制御フィールド７１２、ＳＳＩＤＩＥ７１４、サポート速度ＩＥ７１６、および緊急呼ＩＥ７１８を含む。緊急呼ＩＥ７１８は、図２Ｂに関連して上述した緊急呼ＩＥ２５６と同一であるとすることができる。サポート速度ＩＥ７１６は、オプションであり、およびサポート速度ＩＥの機能性に影響を及ぼすことなくＳＯＳ信号フレーム７００から削除することができることを補足する。
【００５５】
一実施形態において、ＳＯＳ信号フレーム７００を、送信媒体へのアクセスを確実にするＳＩＦＳ（ＳｈｏｒｔＩｎｔｅｒＦｒａｍｅＳｐａｃｅ）プライオリティまたはＰＩＦＳ（ＰｒｉｏｒｉｔｙＩｎｔｅｒＦｒａｍｅＳｐａｃｅ）プライオリティ付きで送信されるプローブ要求フレームとして定義することができる。ＳＯＳ信号フレームは、９１１ＩＤ（例えば、発呼者ＩＤ）、装置の詳細（ＩＭＥＩ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＥｑｕｉｐｍｅｎｔＩｄｅｎｔｉｆｉｃａｔｉｏｎ）など）、ネットワーク所属、ユーザ名、および緊急理由コードなど、緊急呼ＩＥにおける新規の緊急呼関連要素を含む。緊急理由コードを、装置がユーザに緊急呼に対する理由を識別させることを促すこと（例えば、「火災緊急の場合には１を押下する」など）により取得することができる。理由コードは、進行中の呼を終了する方法がない場合に、緊急の場合を処理する何らかの能力を提供するであろう。
【００５６】
ＳＯＳ信号フレームを、約１００ミリ秒毎に送信に対してスケジューリングを行うことにより、位置のロギングおよびトラッキングを容易にすることができる。ＡＰは、タイムスタンプおよび信号の項目に付いたあらゆるＳＯＳ信号フレームの受信をロギングする必要があるであろう。信号強度項目は、信号強度、信号品質、アンテナ方位および利得、ならびにＩＭＥＩ、ユーザ名（使用可能の場合）、識別と性能とに有用な他の８０２．１１装置情報など、発呼者の詳細を含む。さらに、ＳＯＳ信号フレームを受信するＡＰは、緊急応答、無線リソース調整、位置、および発信装置トラッキングのための緊急ネットワークノードにイベントを報告する必要があるであろう。
【００５７】
これは、ＳＯＳ信号フレームが送信され、およびエマージェンシワーカが発呼者に近づきながら、エマージェンシワーカがＳＯＳ信号フレームを受信することができる有効なプローブ機構である。１つの類似は、航空機のブラック・ボックスにおける緊急ビーコンである。新規のＭＡＣフレームを、本目的のために導入することができ、または既存のＭＡＣフレーム、例えば、プローブ要求フレームを、本目的を果たすために、新規のＩＥ（緊急呼ＩＥ２５６など）により拡張することができる。
【００５８】
図８に、ＳＯＳ信号フレームを利用する方法８００を示す。ユーザにより、ＳＴＡから緊急呼が生起される（ステップ８０２）。ＳＴＡは、ＳＯＳフレームを送信し始める（ステップ８０４）。要求される実施に基づいて、ＳＯＳフレームを、プローブとして送信するか、またはエマージェンシワーカとの直接接続を確立するのに使用するかのいずれかができる（ステップ８０６）。
【００５９】
ＳＯＳフレームがプローブとして送信される場合、送信周期が設定され、および送信周期の終了に到達しているかどうかの決定が行われる（ステップ８１０）。送信周期が終了していない場合、ＳＴＡは、ＳＯＳフレームの送信を継続し（ステップ８１２）、および方法８００は、ステップ８１０に戻る。送信周期の終了に到達している場合（ステップ８１０）、ＳＴＡは、ＳＯＳフレームの送信を停止し（ステップ８１４）、および方法８００は、終了する（ステップ８１６）。
【００６０】
ＳＯＳフレームがエマージェンシワーカとの直接接続を確立するのに使用されるべきである場合（ステップ８０６）、エマージェンシワーカがＳＴＡの範囲内にあるかどうかの決定が行われる（ステップ８２０）。エマージェンシワーカがＳＴＡの範囲内にない場合、ＳＴＡは、ＳＯＳフレームの送信を継続し（ステップ８２２）、および方法８００は、ステップ８２０を続ける。エマージェンシワーカがＳＴＡの範囲内である場合（ステップ８２０）、ＳＴＡは、ＳＯＳフレームの送信を停止し、発呼者とエマージェンシワーカとの間の直接接続を確立し（ステップ８２４）、および方法８００は、終了する（ステップ８１６）。
【００６１】
第１の代替案（ステップ８１０～８１４）において、ＳＴＡにより送信されるＳＯＳフレームを、緊急呼が終了すると、ＡＰからの信号送信によって、またはセッション開始プロトコル（ＳＩＰ）のような、より高いレイヤのプロトコルによって、起動することができるであろう。ＳＯＳフレームのデュレーション／頻度は、上述の起動信号に含まれる。緊急呼が終了した後のＳＯＳフレームの送信は、緊急呼が誤りである場合に、またはエマージェンシワーカが緊急呼に応答して近づく必要がない場合に、不要なＳＯＳフレームの送信を防止する。
【００６２】
第２の代替案（ステップ８２０～８２４）において、エマージェンシワーカと発呼者との間の直接ＶｏＩＰ接続は、エマージェンシワーカと発呼者とが互いの範囲内にあると、確立される。ＳＯＳフレームが届く他のＳＴＡは、図４Ａ、図４Ｂ、および図５に関連して上述した拡張されたＲＴＳフレームのようなＳＯＳフレームを処理することができる（すなわち、他のＳＴＡは、緊急発呼者が帯域幅に対してより有利なアクセスを有するよう、通信媒体にアクセスしようとしないであろう）。
【００６３】
（Ｂ．ネットワーク（例えば、ＡＰ）への、緊急呼を処理するコールバックの機能性の実装）
緊急呼が確立されると、ＷＬＡＮは、コールバックの場合に、緊急呼が終了した後、ある一定の時間、緊急呼を起動したユーザへのアクティブ接続を保持する。上述の機能性は、ユーザに対してトランスペアレントとすることができる。
【００６４】
（ＩＩＩ．インフラストラクチャにおける機能性）
（Ａ．プロキシ機能）
図９に、ＡＰがＳＴＡに対してプロキシとして動作する必要があるかどうかを決定する方法９００を示す。ＳＴＡが緊急呼を生起し（ステップ９０２）、およびＡＰが緊急呼を受信する（ステップ９０４）。ＳＴＡが緊急呼を伝送するのに使用されるネットワークに基づいて、緊急呼を完了する性能を有するかどうかの決定が行われる（ステップ９０６）。ＡＰは、ＳＴＡが緊急呼をサポートするのに必要なすべての機能性（例えば、ＳＩＰ／Ｈ．３２３プロトコル終端、ボコーダなど）を有するかどうかを検査する。上述の情報を、ＭＡＣフレームの一部分（例えば、ＭＡＣフレーム２００、２５０）として示すことができ、またはＡＰがアクセスすることができるネットワークにおける加入者情報の一部分とすることができる。
【００６５】
ＳＴＡが必要な性能のすべてを有する場合、ＳＴＡは、通常通りに緊急呼を続行する（ステップ９０８）。ＡＰは必要に応じて緊急呼に、ＳＴＡの位置および／またはＡＰの位置（ネットワークＩＤ、ＡＰのＭＡＣアドレス他など）を含む、位置情報を加えることができる（ステップ９１０）。次に、方法９００は、終了する（ステップ９１２）。
【００６６】
ＳＴＡが緊急呼を完了するのに必要な性能のすべてを有する場合ではないと（ステップ９０６）、ＡＰがＳＴＡに対するプロキシとして動作し、必要なあらゆる機能性を提供する（ステップ９１４）。ＡＰは必要に応じて緊急呼に位置情報を追加（ステップ９１０）し、および方法９００は、終了する（ステップ９１２）。
【００６７】
ＡＰは、ＳＴＡが現在の環境において緊急呼を完全に完了するのに必要なすべての機能性を有する場合ではないと決定すると、ＡＰは、ＳＴＡに対するプロキシとして動作する（ステップ９１４）。例えば、ＳＴＡがＳＩＰプロトコルサポートを有さない場合には、ＡＰは、ＳＴＡに対するＳＩＰプロキシとして動作することができる。別の例として、ＳＴＡはＳＩＰサポートを有するがネットワークはＨ．３２３をサポートするだけの場合には、ＡＰは、残りのネットワークに対して、ＳＴＡからのＳＩＰメッセージをＨ．３２３メッセージに相互に作用させることができる。ＳＴＡがボコーダさえ有さない極端な場合には、ＡＰは、ＳＴＡにシン・ボコーダ・クライアントをダウンロードし、およびネットワークの中のどこか他の場所の、より標準的なボコーダに相互に作用させることができる。
【００６８】
ＡＰが、ＳＴＡおよびネットワークにおけるＳＴＡのコレスポンデントにより信号送信または通常のトラヒックのために使用されるＩＰパケットの内容をスプーフする（すなわち、情報の内容および／または種別が公式にはサポートされない場合でさえ、情報の内容および／または種別を読取る）別の方法がある。例えば、通常、ＩＰによるＳＩＰ信号送信プロトコルメッセージが、現在では呼処理のために使用される。そのようなＳＩＰ信号送信は、性能情報および送信先アドレスなど、プロキシとしてのＡＰの役割を果たすＡＰに対して有用な情報を含む。先に説明された方法に加えて、ＡＰがＳＴＡリモート（ＳＴＡ－ｒｅｍｏｔｅ）の送信先高位層（すなわち、Ｌ２ＭＡＣ上）のメッセージコンテンツをスプーフすることによりそのような情報を抽出する場合、ＡＰは、より効率的にＡＰの役割を果たすことができる。当事業者は、ＳＩＰがＩＰベースの呼に対する管理プロトコルの一例であり、および他の同等なプロトコルが存在して、産業上、広く使用されていることを認めるであろう。したがって、上述の方法は、ＳＩＰだけに限定されない。
【００６９】
（Ｂ．緊急呼センターへのＡＰのリンク）
ＡＰはＳＴＡが緊急呼を生起することを知ると、ＡＰは、ＳＴＡからの緊急呼を適切にルーティングするために、緊急呼センターへのリンクを確立する必要がある。緊急呼をＡＰから緊急呼センターに届けることができるいくつかの転送機構がある。例えば、ＡＰがゲートウェイと通信して、ＡＰを緊急呼センターにリンクさせることができる。
【００７０】
緊急ネットワークノードの概念を拡張して、ｍａｎ-ｉｎ-ｔｈｅ-ｌｏｏｐ性能を有する緊急応答のオペレーションセンターを包含することができる。緊急ネットワークノードは、インフラストラクチャアプリケーションに適応させ拡張されたサービスセットまたはネットワークであろう。例えば、大学構内において、指定される緊急ネットワークノードは、構内警備員部門であろう。別の例として、製造プラントにおいて、緊急ネットワークノードは、警備員室であろう。緊急ネットワークノードは、ＶｏＩＰ呼を受信し、呼情報をロギングし、呼を保護し、および次に公衆電話交換網（ＰＳＴＮ）に緊急呼を加えることにより適切な機関に警報を出すオペレータを包含するであろう。
【００７１】
緊急ネットワークノードの概念をさらに拡張して、ＰＳＴＮへの直通電話による自動ノードを包含することができる。自動ノードが音声回線ブリッジとして作動することにより、電話をかけ、およびワイヤレスの発呼者をＰＳＴＮ緊急センターに接続するであろう。
【００７２】
緊急ネットワークノードへの接続方法を拡張して、認証、許可またはセキュリティ機能なしに呼をルーティングかつ処理する能力を包含することができるであろう。このことは、ワイヤレス発呼者と緊急ネットワークノードとの間の、暗号化されない直接接続またはトンネル接続を可能にするであろう。
【００７３】
緊急ネットワークノードの機能を拡張して、呼処理、呼のハンドオフ、およびローミングの調整を包含することできるであろう。上述の機能性が隣のＡＰ（ワイヤレス呼を処理しているＡＰに隣接するＡＰ）におけるリソースを予め許可することにより、発呼者は、ＡＰの境界を横切って移動する場合にワイヤレス接続を失うことなしに、および新規の緊急呼を再確立する必要なしに、ローミングすることができるであろう。したがって、同一の緊急の場合に重複する呼を排除することができる。
【００７４】
本発明の概念は、上で例示した特定の例より優れた拡張を行うことができる。例えば、本発明を、メッシュネットワークおよびアドホックネットワークに対して拡張することができる。代替案として、人間のユーザの代わりに、本発明は、ＷＬＡＮによる緊急処理のために、マシン対マシン使用のシナリオに対して拡張することができる。１つの可能性は、ホーム・セキュリティ・システムにおける８０２．１１の使用であろう、すなわち、ＷＬＡＮが（切断することができる）有線の電話線に代わって使用される。上述の例において、人間のユーザがＷＬＡＮの緊急呼を発呼する代わりに、ホーム・セキュリティ・システムは、何者かが侵入すると、緊急呼をセキュリティ・コール・センターに自動発呼する。あるいはまた、ホーム・セキュリティ・システムは、上述された通りに、緊急ＳＯＳフレームを送信し始めることができるであろう。
【００７５】
本発明の特徴および要素が、特有な組合せにおける望ましい実施形態において説明されるが、各々の特徴または要素を、単独において（望ましい実施形態の他の特徴および要素なしに）、または本発明の他の特徴および要素の有無に関わらず、様々の組合せにおいて、使用することができる。
【図面の簡単な説明】
【００７６】
【図１】標準規格のメディアアクセス制御（ＭＡＣ）フレームの図である。
【図２Ａ】緊急呼を示すビットフラグを有するＭＡＣフレームの図である。
【図２Ｂ】緊急呼を示す情報要素（ＩＥ）を有するＭＡＣフレームの図である。
【図３】標準規格のＲＴＳ（ＲｅａｄｙＴｏＳｅｎｄ）フレームの図である。
【図４Ａ】緊急呼を示すビットフラグを有するＲＴＳフレームの図である。
【図４Ｂ】緊急呼を示すＩＥを有するＲＴＳフレームの図である。
【図５】図４Ａまたは図４Ｂに示される通りのＲＴＳフレームを使用する方法のフローチャートである。
【図６】緊急呼を完了する無線技術を切替える方法のフローチャートである。
【図７】緊急呼を示すＳＯＳビーコンフレームの図である。
【図８】図７において示すＳＯＳフレームを送信かつ使用する方法のフローチャートである。
【図９】プロキシ機能を適用するかどうかを決定する方法のフローチャートである。
【符号の説明】
【００７７】
２５２フレーム制御
２５４長さ
２５６緊急呼情報
２６０緊急呼フラグ
２６２理由コード
２６４性能情報
２６６位置情報
２６８コーデック

【出願人】	【識別番号】５９６００８６２２【氏名又は名称】インターデイジタルテクノロジーコーポレーション
【出願日】	平成１９年８月３０日（２００７．８．３０）
【代理人】	【識別番号】１０００７７４８１【弁理士】【氏名又は名称】谷義一【識別番号】１０００８８９１５【弁理士】【氏名又は名称】阿部和夫
【公開番号】	特開２００８－３５５３１（Ｐ２００８－３５５３１Ａ）
【公開日】	平成２０年２月１４日（２００８．２．１４）
【出願番号】	特願２００７－２２４８６２（Ｐ２００７－２２４８６２）