(57)【要約】都市間ディスパッチ・サービスの提供を求めるニーズに応えるため、都市間ディスパッチ・プライベート・コール及びディスパッチコール・アラート・サービスをサポートする実施形態を開示する。ローカル・ネットワーク装置（１１０〜１３１）におけるコール制御により、ローカル都市エリア（１０１）及びリモート都市エリア（１５１）の双方におけるディスパッチ・サービスを管理する。都市エリアの境界をまたがるプライベート・コール及びコール・アラート・サービスのこのローカル管理を可能にするコール・フロー実施形態を詳細に記載する。
2005520462.tif 000002
【特許請求の範囲】
【請求項１】
リモート・ネットワーク装置によってサービスを提供される通信ユニット宛てのサービス・リクエストであって、ローカル・ネットワーク装置によってサービスを提供される発信元ユニットから受信されるサービス・リクエストを、前記ローカル・ネットワーク装置によって受信するステップと、
前記リモート・ネットワーク装置に対して、前記通信ユニットを呼び出すように求めるリクエストを前記ローカル・ネットワーク装置によって送信するステップと、
前記通信ユニットが利用可能であることを示す指標を前記リモート・ネットワーク装置から前記ローカル・ネットワーク装置によって受信するステップと、
前記リモート・ネットワーク装置に対して、前記サービス・リクエストをサポートするためにチャネル・リソースを初期化するように求めるリクエストを、前記ローカル・ネットワーク装置によって送信するステップと、
前記発信元ユニットが送信セッションを完了したことを示す指標をローカル・ネットワーク装置によって受信するステップと、
前記発信元ユニットが前記送信セッションを完了したことを示す指標を前記ローカル・ネットワーク装置によって前記リモート・ネットワーク装置へ送信するステップと、からなる都市間ディスパッチ・プライベート・コールのための方法。
【請求項２】
現在のローカル・コール状態を示す指標を前記ローカル・ネットワーク装置によって前記リモート・ネットワーク装置へ送信するステップと、
現在のリモート・コール状態が前記現在のローカル・コール状態と同期していることを示す指標を前記リモート・ネットワーク装置から前記ローカル・ネットワーク装置によって受信するステップとをさらに有する請求項１記載の方法。
【請求項３】
前記通信ユニットが通話を要求したことを示す指標を前記リモート・ネットワーク装置から前記ローカル・ネットワーク装置によって受信するステップと、
通話特権が未だ割り当てられていないかどうかを前記ローカル・ネットワーク装置によって判断するステップと、
前記通信ユニットが送信セッションのための通話特権を許可されていることを示す指標を、前記ローカル・ネットワーク装置によって前記リモート・ネットワーク装置へ送信するステップと、
前記通信ユニットが前記送信セッションを完了したことを示す指標を前記リモート・ネットワーク装置から前記ローカル・ネットワーク装置によって受信するステップと、をさらに有する請求項１記載の方法。
【請求項４】
リモート・ネットワーク装置によってサービスを提供されるコール・アラート・ユニット宛てのディスパッチ・コール・アラート・リクエストであって、ローカル・ネットワーク装置によってサービスを提供されるコール・アラート発信元ユニットから受信されるディスパッチ・コール・アラート・リクエストを、前記ローカル・ネットワーク装置によって受信するステップと、
前記リモート・ネットワーク装置に対して、前記コール・アラート発信元ユニットからのコール・アラートにより前記コール・アラート・ユニットを呼び出すように求めるリクエストを、前記ローカル・ネットワーク装置により送信するステップと、をさらに有する請求項１記載の方法。
【請求項５】
リモート・ネットワーク装置に対し、ローカル・サービス・リクエストの送信先である通信ユニットを呼び出すように求めるリクエストを、ローカル・ネットワーク装置からリモート・ネットワーク装置によって受信するステップと、
前記通信ユニットが利用可能であることを示す指標を前記リモート・ネットワーク装置
によって前記ローカル・ネットワーク装置へ送信するステップと、
前記リモート・ネットワーク装置に対して、前記ローカル・サービス・リクエストをサポートするためにチャネル・リソースを初期化するように求めるリクエストを、前記ローカル・ネットワーク装置から受信するステップと、
前記ローカル・ネットワーク装置によってサービスを提供されるサービス発信元ユニットが送信セッションを完了したことを示す指標を、前記ローカル・ネットワーク装置から前記リモート・ネットワーク装置によって受信するステップと、からなる都市間ディスパッチ・プライベート・コールのための方法。
【請求項６】
通話のリクエストを前記通信ユニットから前記リモート・ネットワーク装置によって受信するステップと、
前記通信ユニットが通話のリクエストを行なったことを示す指標を前記リモート・ネットワーク装置によって前記ローカル・ネットワーク装置へ送信するステップと、
前記通信ユニットが送信セッションのための通話特権を許可されていることを示す指標を、前記ローカル・ネットワーク装置から前記リモート・ネットワーク装置によって受信するステップと、
前記通信ユニットが送信セッションを完了したことを示す指標を前記リモート・ネットワーク装置によって受信するステップと、
前記通信ユニットが前記送信セッションを完了したことを示す指標を前記リモート・ネットワーク装置によって前記ローカル・ネットワーク装置へ送信するステップと、をさらに有する請求項５記載の方法。
【請求項７】
現在のローカル・コール状態を示す指標を前記ローカル・ネットワーク装置から前記リモート・ネットワーク装置によって受信するステップと、
現在のリモート・コール状態と前記現在のローカル・コール状態とを前記リモート・ネットワーク装置によって比較するステップと、
現在のリモート・コール状態が前記現在のローカル・コール状態と同期していることを示す指標を前記リモート・ネットワーク装置によって前記ローカル・ネットワーク装置へ送信するステップと、をさらに有する請求項５記載の方法。
【請求項８】
前記リモート・ネットワーク装置に対して、コール・アラート発信元ユニットからのコール・アラートによりコール・アラート・ユニットを呼び出すように求めるリクエストを、前記ローカル・ネットワーク装置から前記リモート・ネットワーク装置によって受信するステップと、
前記コール・アラート発信元ユニットからのコール・アラートにより、前記コール・アラート・ユニットを前記リモート・ネットワーク装置によって呼び出すステップと、をさらに有する請求項５記載の方法。
【請求項９】
通信制御装置であって、
ネットワーク・トランシーバと、
前記ネットワーク・トランシーバを使用して動作するために適したプロセッサと、
リモート・ネットワーク装置によってサービスを提供される通信ユニット宛てのサービス・リクエストであって、前記通信制御装置によってサービスを提供される発信元ユニットから受信されるサービス・リクエストを受信することと、
前記リモート・ネットワーク装置に対して、前記通信ユニットを呼び出すように求めるリクエストを送信することと、
前記通信ユニットが利用可能であることを示す指標を前記リモート・ネットワーク装置から受信することと、
前記リモート・ネットワーク装置に対して、前記サービス・リクエストをサポートするためにチャネル・リソースを初期化するように求めるリクエストを送信することと、
前記発信元ユニットが送信セッションを完了したことを示す指標を受信するステップと、
前記発信元ユニットが前記送信セッションを完了したことを示す指標を前記リモート・ネットワーク装置へ送信することと、を有する通信制御装置。
【請求項１０】
通信制御装置であって、
ネットワーク・トランシーバと、
前記ネットワーク・トランシーバを使用して動作するために適したプロセッサと、
前記通信制御装置に対して、ローカル・サービス・リクエストの送信先である通信ユニットを呼び出すように求めるリクエストをローカル・ネットワーク装置から受信することと、
前記通信ユニットが利用可能であることを示す指標を前記ローカル・ネットワーク装置へ送信することと、
前記通信制御装置に対して、前記ローカル・サービス・リクエストをサポートするためにチャネル・リソースを初期化するように求めるリクエストを、前記ローカル・ネットワーク装置から受信することと、
前記ローカル・ネットワーク装置によってサービスを提供されるサービス発信元ユニットが送信セッションを完了したことを示す指標を前記ローカル・ネットワーク装置から受信することと、
前記サービス発信元ユニットが前記送信セッションを完了したことを示す指標を前記通信ユニットへ送信することと、を有する通信制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、同一日付に出願され本願とともに係属中の「都市間ディスパッチ・グループ・コールのための方法及び装置」と題する、本出願の譲受人に譲渡された出願に関するものであり、参照により本開示に援用される。
【０００２】
本発明は一般に通信システムに関し、より詳細には都市間ディスパッチ通信システムに関する。
【背景技術】
【０００３】
今日のセルラー方式により提供される相互接続サービスと異なり、ディスパッチ・サービスは従来から双方向無線システムによって提供されてきた。このようなサービスにより、利用者は今日のセルラー方式を使用して困難な、またはコストの掛かる方法で通信することになる。例えばディスパッチ・グループ・コール・サービスを利用すると、利用者は一グループの人々と、通常単に「押して話す」（ｐｕｓｈ−ｔｏ−ｔａｌｋ：ＰＴＴ）ボタンを押すだけで同時かつ瞬時に通信が出来る。セルラー方式では、そのようなコールは瞬時には起こらない。この理由は、３方向コールを行なうためにいずれの電話番号もダイヤルする必要があるか、或いは電話会議を設定するために調整が必要となるためである。ディスパッチ・グループ・コールはグループとして共に働き、頻繁に互いが同時に話す必要のある或る一団の人々にとって理想的である。
【０００４】
同じように、ディスパッチ個別コール・サービス（通常、プライベート・コールまたはコール・アラート）によって、利用者は、別の利用者と迅速かつ同時に通信することができる。この特徴は一緒に働いていても互いが直接話すことができない２人の人にとって理想的である。会話にはワイヤレス電話コールがより適切であると考えられる場合、２人の人が働いているときに交わされる２人の間の短いメッセージはディスパッチ個別コール・サービスにより一層簡単になる。
【０００５】
現在、モトローラの「ｉＤＥＮ」方式はこのようなディスパッチ・サービスを提供するが、この提供は都市エリアと呼ばれる限られたサービスエリア内のみに限定される。このように、「ｉＤＥＮ」利用者は現在、同じ都市エリアに位置する他の利用者に対してディスパッチ・グループ・コール及びディスパッチ・プライベート・コールを行なうことができる。しかしながら、これらの利用者の内の一人が都市エリアを離れて（例えば別の都市に旅行する）新規の都市エリアで登録する場合、前の都市エリアに居たときに利用者に提供されていたディスパッチ・サービスはもはや利用できない。
【０００６】
従って、都市間ディスパッチ・サービスを提供する方法及び装置が必要となる。
【発明を実施するための最良の形態】
【０００７】
都市間ディスパッチ・サービスの提供に対するニーズに対処するために、都市間ディスパッチ・プライベート・コール及びディスパッチコール・アラート・サービスをサポートする実施形態を開示する。ローカル・ネットワーク装置におけるコール制御により、ローカル都市エリア及びリモート都市エリアの双方におけるディスパッチ・サービスを管理することができる。プライベート・コール及びコール・アラート・サービスの都市エリア境界をまたがってのローカル管理を可能にするコール・フロー実施形態について詳細に記載する。
【０００８】
開示する実施形態は、図１，２を参照することにより一層深く理解されるものと考えら
れる。図１は本発明の一実施形態による通信システム１００のブロック図を示したものである。システム１００は、イリノイ州シャウムバーグに本拠を置くモトローラ社が供給する市販の「ｉＤＥＮ」通信システムを備え、このシステムは構成要素としての都市エリアに分割される。都市エリア１０１，１５１が図１に示されるが、この技術分野の当業者であればシステム１００は、図示のエリアに都市エリアを追加できることが理解できるであろう。都市エリアは通常、地理的に明確に離れた領域にサービスを提供する「ｉＤＥＮ」システムを指すが、この技術分野の当業者であれば都市エリアが別のタイプのシステム（または非「ｉＤＥＮ」装置）を指すことができることも理解できると考えられ、この場合の別タイプのシステムは都市間インタフェースをサポートすることにより「ｉＤＥＮ」以外のシステムとの接続を行なう。
【０００９】
システム１００はディスパッチ制御装置として機能し、「ｉＤＥＮ」ホーム・ロケーション・レジスタ（ＩＨＬＲ）１５０のインタフェースとなる「ｉＤＥＮ」ディスパッチ・アプリケーション・プロセッサ（ＤＡＰ）１１０，１１１，１６０，１６１を備える。ＤＡＰはまた、ベースサイト、すなわち「ｉＤＥＮ」色を強めたベース・トランシーバ・システム（ＥＢＴＳ）１２０，１２１，１７０，１７１のインタフェースとなる。図１に示すように、ＥＢＴＳ１２０，１２１，１７０及び１７１は無線サービスを移動局１４０，１４１，１９０及び１９１にそれぞれ提供する。しかしながら、本発明は移動する通信ユニットに限定されない。例えば、通信ユニットはシステム１００に無線接続されるコンピュータ、またはシステム１００にインターネットを通して接続されるコンピュータを含む。ＤＡＰ１１０，１１１，１６０，１６１はまた、「ｉＤＥＮ」ディスパッチ・アクセス制御装置（Ｄｉｓｐａｔｃｈ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌｌｅｒ：ＩＤＡＣ）１３０，１３１，１８０，１８１との接続を行い、これらの制御装置によりシステム１００における都市エリア１０１と都市エリア１５１との間の都市間接続が可能となる。
【００１０】
この技術分野の当業者であれば、図１がシステム１００が動作するために必要なネットワーク装置及び装置構成要素の全てを示してはいないことがわかるであろう。図１は本発明の実施形態の記載に特に関連するこれらのシステム構成要素を簡易化した図を示しているに過ぎない。例えば、ＤＡＰ１１０，１１１，１６０，１６１はそれぞれディスパッチ制御装置であり、これらの制御装置は共に公知の構成要素であるネットワーク・トランシーバ及びプロセッサを備える。この技術分野の当業者であれば多くの方法により、これらの構成要素の各々が「モトローラ」のような無線通信企業により実現することができる、および／または無線通信企業から購入することができることがわかるであろう。例えば、プロセッサは通常、コンピュータ命令として、および／または回路の中で表現されるアルゴリズムを実行するように設計されるマイクロプロセッサ、メモリ、および／または論理回路のような要素を備える。またプロセッサはネットワーク・トランシーバとの接続を行なって、データ通信ネットワークおよび／または専用通信リンクを通して他の装置と通信することが知られている。アルゴリズム、論理フロー、またはメッセージング・フローが与えられると、この技術分野の当業者であれば、特定の論理を実行し、かつ、必要に応じてネットワーク・トランシーバを通して通信するプロセッサを実現するために多くの設計及び開発技術を使用することができることに気付くものと思われる。さらに、この技術分野の当業者であれば、本発明のディスパッチ制御装置の態様がただ単にＤＡＰの中ではなく、システム１００の種々の物理的構成要素の中に、かつ種々の物理的構成要素に亘って実現できることが理解できるであろう。
【００１１】
本発明の実施形態によるシステム１００の動作は、図１及び図２を参照して実際に以下に示すように行なわれる。図２は、本実施形態によるシステム構成要素により交換されるメッセージングを示すコール・フローチャートである。ＭＳ１４０の利用者がＭＳ１９０の利用者と、ディスパッチ・プライベート・コール・サービスを使用して通話すると仮定する。ＭＳ１４０はサービス・リクエストをそのサービスを提供する側、すなわちＥＢＴ
Ｓ１２０に送信し、このＥＢＴＳ１２０がサービス・リクエストをＤＡＰ１１０にルーティングする。本発明の一実施形態においては、ＤＡＰ１１０がＭＳ１４０に対してサービスを提供するＤＡＰとして指定される。このように特定の通信制御装置に対して予め通信ユニットをマッピングしておくことは都市間コールプロセスを構築するためのほんの一つの方法に過ぎない。確かにそれに代えて、例えば負荷をバランスさせるという観点に基づいて制御装置をリアルタイムで選択するといった他の手法を用いることができる。
【００１２】
ローカル・ネットワーク装置が受信するディスパッチ・プライベート・コールリクエストの宛先は、リモート・ネットワーク装置、すなわちＭＳ１９０によってサービスを提供される通信ユニットである。本実施形態においては、ＤＡＰ１１０がＳＥＮＤ＿ＲＯＵＴＩＮＧ＿ＲＥＱＵＥＳＴメッセージをＩＨＬＲ１５０に送信し（２０１）、どのリモート・ネットワーク装置が送信先ユニットＭＳ１９０にサービスを提供すべきかを判断する。ローカル・ネットワーク装置とリモート・ネットワーク装置との間の都市間ディスパッチ・サービスをサポートするために、ローカルディスパッチ制御装置が適切なリモート・ディスパッチ制御装置と協力してディスパッチ・サービスを管理する。本実施形態ではホーム・ロケーション・レジスタへのアクセスを行なうが、他の実施形態は移動情報を含む他のタイプのデータベースまたはキャッシュへのアクセスを含む。ＭＳ１９０は、ユニバーサル・フリート・メンバー識別子（Ｕｎｉｖｅｒｓａｌ  Ｆｌｅｅｔ  Ｍｅｍｂｅｒ  Ｉｄｅｎｔｉｆｉｅｒ：ＵＦＭＩ）のような識別子を使用するＳＥＮＤ＿ＲＯＵＴＩＮＧ＿ＲＥＱＵＥＳＴメッセージの中で特定される。
【００１３】
ＤＡＰ１１０はＩＨＬＲ１５０から、ＭＳ１９０にサービスを提供するリモート・ネットワーク装置を特定するＳＥＮＤ＿ＲＯＵＴＩＮＧ＿ＲＥＳＰＯＮＳＥメッセージを受信する（２０２）。ＭＳ１９０にサービスを提供するのは都市エリア１５１のネットワーク装置であるが、本実施形態ではＳＥＮＤ＿ＲＯＵＴＩＮＧ＿ＲＥＳＰＯＮＳＥメッセージにより、どの特定のＤＡＰがＭＳ１９０にサービスを提供しているＤＡＰ（例えばＤＡＰ１６０）であるのかが示される。
【００１４】
ＤＡＰ１１０はリモート・ネットワーク装置に要求して、ＤＡＰ１６０にＰＣ＿ＰＡＧＥ＿ＲＥＱ＿ＦＷＤメッセージを送信する（２０３）ことによりＭＳ１９０を呼び出す。本実施形態においては、ＰＣ＿ＰＡＧＥ＿ＲＥＱ＿ＦＷＤメッセージによって都市エリア１０１におけるディスパッチ・プライベート・コールをサポートする搬送ゲートウェイも特定される。ＰＣ＿ＰＡＧＥ＿ＲＥＱ＿ＦＷＤメッセージを受信した後、ＤＡＰ１６０はＭＳ１９０を呼び出す。ＭＳ１９０がこの呼び出しに応答すると、ＤＡＰ１６０はＰＣ＿ＰＡＧＥ＿ＲＳＰ＿ＦＷＤメッセージをＤＡＰ１１０に送信し（２０４）、ＭＳ１９０が応答したことと、ディスパッチ・プライベート・コールをサポートするために必要なチャネル・リソースが都市エリア１５１で利用できることを示し、特にコールをサポートする搬送ゲートウェイを特定する。他のシステム構成を用いるとＭＳ１９０を積極的に呼び出す必要が無く、ＤＡＰ１６０は即座に応答することができる。また、リソースがそのときに利用できない場合、また、リソースがそのときに利用できない場合、コールがキューイングされて、リソースが利用可能になるときに、追加のメッセージ交換が必要となる。
【００１５】
ＭＳ１９０及びチャネル・リソースがコールに対応可能であることを示すＰＣ＿ＰＡＧＥ＿ＲＳＰ＿ＦＷＤメッセージを受信すると、ＤＡＰ１１０はチャネル・リソースを初期化してディスパッチ・プライベート・コールをサポートするようＤＡＰ１６０に要求するＰＣ＿ＳＴＡＲＴ＿ＦＯＲＷＡＲＤメッセージを送信する（２０５）。このようにして、ＤＡＰ１１０及びＤＡＰ１６０は共にコールの送信準備をする。一旦コール設定が完了する（例えば必要な無線及び都市間チャネルが初期化される）と、ＭＳ１４０からＭＳ１９０へのプライベート・コール送信が行なわれる。
【００１６】
ＭＳ１４０が送信を終えてコールの第１送信セッションが完了すると、ＤＡＰ１１０は送信終了の指標（ｉｎｄｉｃａｔｉｏｎ）を受信し、ＰＣ＿ＯＰＥＮ＿ＣＨＡＮ＿ＦＷＤメッセージをＤＡＰ１６０に送信し（２０６）、このメッセージによりＭＳ１４０が送信を終了したことを示す。ＰＣ＿ＯＰＥＮ＿ＣＨＡＮ＿ＦＷＤメッセージを受信すると、ＤＡＰ１６０はＭＳ１９０にＭＳ１４０が送信セッションを完了したことを通知する。
【００１７】
本実施形態においては、コール中に、ローカル・ネットワーク装置は、コール状態確認を実施して、ローカル・ネットワーク装置とリモート・ネットワーク装置とのコール状態が同期されているようにする。タイマーが時間切れ（例えば４５秒）になるとＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＥＱメッセージが送信されるため、コールの種々の局面の間に送信される。例えば図２には、ＭＳ１４０がその送信セッションを完了した後にＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＥＱメッセージが送信される様子を示している。しかしながら、ＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＥＱメッセージはコール状態タイマーが時間切れになると必ず送信される。ＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＥＱメッセージはＤＡＰ１１０に従ったコールの現在の状態を示す。可能なコール状態には、「リソース待ち」、「送信先を呼び出し中」、「プレコール開始」「発信元が送信中」、「待機時間」及び「送信先が送信中」が含まれる。
ＤＡＰ１６０はＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＥＱメッセージを受信し、メッセージコール状態をコール状態判定と比較する。受信したコール状態がＤＡＰ１６０の現在の状態に基づいて有効ではない場合、ＤＡＰ１６０は操作を進めてコールを切断し、ＤＡＰ１１０に指標を送信してコールを終了させたことを知らせる。コール状態が有効である場合、ＤＡＰ１６０はＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＥＱメッセージに対して、コール状態が同期していることを示すＤＡＰ１１０へのＰＣ＿ＤＡＰ＿ＤＡＰ＿ＣＳＣ＿ＲＳＰメッセージで応答する（２０８）。
【００１８】
ＭＳ１４０はその第１送信セッションを完了したため、プライベート・コールはこの時点で話し手から離れる。説明の都合上、ＭＳ１９０の利用者が通話を希望していると仮定する。ＭＳ１９０の利用者は「押して話す」（ｐｕｓｈ−ｔｏ−ｔａｌｋ）ボタンを押下し、ＤＡＰ１６０は、ＭＳ１９０から通話のリクエストを受信した後、ＰＣ＿ＵＰＤＡＴＥ＿ＲＥＱＵＥＳＴ＿ＦＷＤメッセージをＤＡＰ１１０に送信して（２０９）、ＭＳ１９０から通話のリクエストがあることを知らせる。ＤＡＰ１１０はＰＣ＿ＵＰＤＡＴＥ＿ＲＥＱＵＥＳＴ＿ＦＷＤメッセージを受信し、通話特権が割り当てられていない状態のままであるかどうかを判断する。（例えば、ＭＳ１４０が再度通話を要求し、ＤＡＰ１１０がＭＳ１４０に通話特権を既に許可している可能性がある。）未だ特権を許可していない場合、ＤＡＰ１１０はＰＣ＿ＣＯＮＴ＿ＦＷＤメッセージをＤＡＰ１６０に送信して（２１０）、送信セッション期間中におけるＭＳ１９０の通話特権が受け入れられたことを知らせる。ＰＣ＿ＣＯＮＴ＿ＦＷＤメッセージを受信すると、ＤＡＰ１６０はＭＳ１９０に送信の順番が回ってきたことを知らせる。
【００１９】
ＭＳ１９０が送信を終えてコールの第２送信セッションが完了すると、ＤＡＰ１６０は送信終了の指標を受信し、ＰＣ＿ＯＰＥＮ＿ＣＨＡＮ＿ＦＷＤメッセージをＤＡＰ１１０に送信して（２１１）、ＭＳ１９０が送信を終了したことを通知する。ＰＣ＿ＯＰＥＮ＿ＣＨＡＮ＿ＦＷＤメッセージを受信すると、ＤＡＰ１１０はＭＳ１４０に、ＭＳ１９０が送信セッションを完了したことを知らせる。このとき、ＭＳ１４０またはＭＳ１９０のいずれかが次の送信者になるようにリクエストできる。ＭＳ１４０もＭＳ１９０もともに所定期間（ディスパッチにおいては「待機時間（ｈａｎｇ  ｔｉｍｅ）」と呼ばれる）に通話をリクエストしない場合、ＤＡＰ１１０はＰＣ＿ＯＲＩＧ＿ＣＡＬＬ＿ＴＥＲＭメッセージを送信して（２１２）、ＤＡＰ１６０に対してコールを終了させることを知らせる。
【００２０】
別の通信ユニットとコンタクトするためのディスパッチ・プライベート・コール・サー
ビスの使用に代えて、または加えて、利用者はディスパッチコール・アラート・サービス、またはステータス・メッセージ・サービスを使用することができる。例えばコール・アラート・サービスを使用して、利用者は別の通信ユニットを呼び出してそのユニットの利用者が後で折り返し電話するように求めることができる。ＤＡＰ１１０はＭＳ１４０からＭＳ１９０宛てのコール・アラートリクエストを受信する。次にＤＡＰ１１０は、ＣＡ＿ＰＡＧＥ＿ＲＥＱ＿ＦＷＤメッセージをＤＡＰ１６０に送信し（２１３）、ＤＡＰ１６０に要求してＭＳ１９０をＭＳ１４０からのコール・アラートで呼び出す。２０１及び２０２について上に議論したように、ＩＨＬＲ１５０にコンタクトして送信先の位置を判断する必要がある。ＣＡ＿ＰＡＧＥ＿ＲＥＱ＿ＦＷＤメッセージを受信した後、ＤＡＰ１６０はＭＳ１９０を呼び出して、ＭＳ１４０がリクエストを出しているユニットであることを知らせる。ＭＳ１９０がこの呼び出しに応答すると、ＤＡＰ１６０はＣＡ＿ＰＡＧＥ＿ＲＳＰ＿ＦＷＤメッセージをＤＡＰ１１０に送信し（２１４）、ＭＳ１９０が応答したことを知らせる。
【００２１】
前述の明細書において、本発明は特定の実施形態を参照して記載されてきた。しかしながら、この技術分野の当業者であれば、種々の変形及び変更が添付の請求項に示される本発明の技術思想及び技術範囲から逸脱しない範囲において為し得ることが理解できるであろう。従って、明細書及び図が本発明を制限するものというよりも例示と考えられるべきであり、全てのそのような変形は本発明の技術範囲内に含まれるべきものと考えられる。さらにこの技術分野の当業者であれば、図の構成要素は簡易化のためと明瞭化のために示されていることが理解できよう。
【００２２】
効果、他の利点、及び問題解決法が本発明の特定の実施形態に関連する形で上に記載されてきた。しかしながら、効果、利点、問題解決法、及びこのような効果、利点、または問題解決法をもたらし、またはそれらに至る、或いはそのような効果、利点、または問題解決法をさらに顕著にさせるすべての要素（群）が、必須の、必要な、または基本的な特徴である、或いはいかなる請求項または全ての請求項の要素であると考えられるべきではない。この明細書および添付の特許請求の範囲において使用されるように、「ｃｏｍｐｒｉｓｅｓ」、「ｃｏｍｐｒｉｓｉｎｇ」という用語、または他のすべてのこれらの変形は包括的な意味を指すものであり、例えば一連の要素を備えるプロセス、方法、製品、または装置が一連のこれらの要素のみを含む、ということではなく、明らかには挙げられていない、またはそのようなプロセス、方法、製品、または装置に固有の他の要素を含むことができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の一実施形態による通信システムのブロック図を示したものである。
【図２】本発明の一実施形態によるシステム構成要素により交換されるメッセージングを示すコール・フローチャートである。
【図１】
2005520462.tif 000003
【図２】
2005520462.tif 000004
【国際調査報告】
2005520462.tif 000005