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