グループ通信ネットワークにおけるアクティブなグループに新しいメンバーを加えるための方法および装置
【課題】グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための方法および装置を提供する。
【解決手段】ユーザからメンバーリストを受信し、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送る（１３０４）。メンバーリスト内の各メンバーに、彼らがグループ呼に加えられたことをアナウンスし（１３１２）、グループ呼に参加したいメンバーから肯定応答を受信し（１３１４）、メディアをメンバーへ発送する（１３１４）。さらに加えて、移動局が休止状態であり、かつトラヒックチャネルがアクティブでないときでも、グループ呼シグナリングを交換することによって、休止状態からの起動の実合計時間と待ち時間とを相当に低減する。
【解決手段】ユーザからメンバーリストを受信し、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送る（１３０４）。メンバーリスト内の各メンバーに、彼らがグループ呼に加えられたことをアナウンスし（１３１２）、グループ呼に参加したいメンバーから肯定応答を受信し（１３１４）、メディアをメンバーへ発送する（１３１４）。さらに加えて、移動局が休止状態であり、かつトラヒックチャネルがアクティブでないときでも、グループ呼シグナリングを交換することによって、休止状態からの起動の実合計時間と待ち時間とを相当に低減する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ポイント ツウ マルチポイント通信システムに関する。とくに、本発明は、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法および装置に関する。
【背景技術】
【０００２】
迅速で、効率的な、１対１または１対多数（グループ）の通信のための無線サービスのクラスは、種々の形態で何年も前から存在している。一般に、これらのサービスは、半二重式であり、ユーザは、電話装置／無線機上の“プッシュトーク（push-to-talk, PTT）”ボタンを押して、話し始める。いくつかのタイプのサーバを介して通信を行うとき、いくつかの構成、または適当なシステム内の無線機のボタンまたはキーを押すと、ユーザが“フロア”を要求していることが示される。ユーザは、フロア、すなわち送話者の許可を譲与されると、一般に数秒間話し、その後で、ＰＴＴボタンを放すと、他の話者がフロアを要求することができる。通信は、一般に、１対１ではなく、１人の話者から１グループの受話者へ行われる。このサービスは、１人の人、すなわち“ディスパッチャ”が、フィールドサービスの担当者またはタクシードライバーのような１グループの人々と通信する必要があるとき、アプリケーションにおいて以前から使用されてきた。なお、“ディスパッチャ”は、サービスを“ディスパッチする（発送する）”ための呼び名から由来している。
【０００３】
同様のサービスは、インターネット上で提供されており、一般に、“ボイスチャット”として知られている。これらのサービスは、一般に、ボイスオーバーＩＰ（voice-over-IP）サービスで、ボコーダフレームをインターネットプロトコル（Internet protocol, IP）パケットで中央グループチャットサーバへ送るか、または恐らくはピア ツウ ピア サービスで、クライアントからクライアントへ送るパーソナルコンピュータアプリケーションとして実行される。
【０００４】
これらのサービスにおける重要な特徴は、通信が、通常のダイヤリングおよびリンギングの順序を経ることなく、迅速で自動的に、普通は単にＰＴＴボタンを押すことによって開始されることである。このタイプのサービスの通信は、一般に非常に短く、個々のトーク“スパート”は、通常は数秒間程度であり、“会話”の継続は、恐らくは１分以下である。
【０００５】
ユーザがフロアを要求するときと、ユーザがフロアをもち、かつ話し始めることに対する肯定または否定の確認をサーバから受信するときとの間の時間遅延（ＰＴＴ待ち時間として知られている）は、半二重式グループ通信システムにおける重要なパラメータである。既に記載したように、ディスパッチシステムは、短い、すなわち短時間の会話を優先しており、したがってＰＴＴ待ち時間が長くなると、サービスの効果が低減する。
【０００６】
既存のグループ通信のインフラストラクチャは、ＰＴＴ待ち時間を相当に低減するための機会が制限されている。すなわち、実際のＰＴＴ待ち時間が、恐らくは、休止状態のパケットデータセッション内でトラヒックチャネルを再設定するのに必要な時間よりも短くならないという制限がある。さらに加えて、休止状態のグループを起動し始めるのに使用可能な唯一の機構は、送話者のトラヒックチャネルが再設定されるのを待って、サーバに信号を送るので、送話者と受話者とのトラヒックチャネルは直列に構成される。現在、移動局が生成したユーザシグナリングデータを、トラヒックチャネル以外で送るための機構は存在せず、したがってトラヒックチャネルが再設定された後で、クライアントとサーバとの通信が可能になるといった制約がある。
【０００７】
したがって、システム容量、クライアントのバッテリ寿命、または他の資源にマイナスの影響を与えることなく、送話者が経験する見掛けのＰＴＴ待ち時間と、参加している移動局のトラヒックチャネルを再設定するのに必要な全時間との両者を低減するための機構が必要とされている。
【０００８】
ディスパッチモデルにおいて、エンドポイント間の通信は仮想グループ内で行われ、１人の“送話者”の音声が、１人以上の“受話者”へ同報通信される。このタイプの通信の一例は、一般に、ディスパッチ呼、または単に呼と呼ばれる。呼はグループのインスタンシエーションであり、これは、呼の特性を定め、本質的には、グループ名またはグループ識別子のような、いくつかの関係付けられた情報をもつメンバーリストである。メンバーリストは、呼に参加するように勧誘された１人以上のユーザのリストである。
【０００９】
グループ呼サービスのチャットルームモデルとアドホック・モデルとの両者を支援するディスパッチモデルが必要とされている。チャットルームモデルでは、グループは予め定められ、ディスパッチサーバ上に記憶される。しかしながら、アドホック・モデルでは、グループは実時間で定められる、または変更される、あるいはこの両者である。
【発明の概要】
【００１０】
開示されている実施形態は、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための通信装置における新奇で向上した方法であって、ユーザからメンバーリストを受信することと、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとを含む方法を提供する。
【００１１】
本発明の別の態様において、通信装置におけるコンピュータ読み出し可能メディアは、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための方法であって、上述のステップを含む方法を具現する。
【００１２】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための通信装置であって、ユーザからメンバーリストを受信するための手段と、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送るための手段とを含む。
【００１３】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための通信装置は、受信機と、送信機と、受信機および送信機に通信上で接続されるプロセッサとを含む。プロセッサは、ユーザからメンバーリストを受信することと、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとができる。１つの態様において、通信装置は、プッシュトーク（push-to-talk, PTT）装置である。
【００１４】
開示されている実施形態は、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバにおける新奇で向上した方法であって、アクティブなグループ呼からメンバーリストを加える要求を受信するステップと、アクティブなグループからメンバーリストを加えるステップとを含む方法も提供する。１つの態様において、方法は、メンバーリスト内の各メンバーに、彼らがグループ呼から加えられたことをアナウンスすることをさらに含む。
【００１５】
本発明の別の態様において、サーバ内のコンピュータ読み出し可能メディアは、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための方法であって、上述のステップを含む方法を具現する。
【００１６】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバであって、アクティブなグループ呼にメンバーリストを加える要求を受信するための手段と、アクティブなグループ呼にメンバーリストを加えるための手段とを含む。１つの態様において、サーバは、メンバーリスト内の各メンバーに、彼らがグループ呼に加えられたことをアナウンスするための手段をさらに含む。
【００１７】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバは、受信機と、送信機と、受信機および送信機に通信上で接続されるプロセッサとを含む。プロセッサは、アクティブなグループ呼にメンバーリストを加える要求を受信することと、アクティブなグループ呼にメンバーリストを加えることとができる。１つの態様において、プロセッサは、さらに加えて、メンバーリスト内の各メンバーに、彼らがアクティブなグループ呼に加えられたことをアナウンスすることができる。
【図面の簡単な説明】
【００１８】
【図１】図１は、グループ通信システムを示す図である。
【図２】図２は、いくつかのアプリケーションが相互にどのように対話するかを示す図である。
【図３】図３は、１つの実施形態にしたがう、例示的なユーザ登録処理を示す図である。
【図４】図４は、１つの実施形態にしたがう、例示的な局所の領域内呼のセットアップ処理を示す図である。
【図５】図５は、１つの実施形態にしたがう、例示的な遠隔の領域内呼のセットアップ処理を示す図である。
【図６】図６は、１つの実施形態にしたがう、例示的な局所の領域間呼のセットアップ処理を示す図である。
【図７】図７は、１つの実施形態にしたがう、例示的な遠隔の領域間呼のセットアップ処理を示す図である。
【図８】図８は、１つの実施形態にしたがう、グループ呼から抜け出るための例示的な処理を示す図である。
【図９】図９は、１つの実施形態にしたがう、グループ呼を終了するための例示的な処理を示す図である。
【図１０】図１０は、１つの実施形態にしたがう、グループ呼へ警告を送るための例示的な処理を示す図である。
【図１１】図１１は、１つの実施形態にしたがう、グループ呼への遅れ加入のための例示的な処理を示す図である。
【図１２】図１２は、１つの実施形態にしたがう、送話者をプリエンプトするための例示的な処理を示す図である。
【図１３】図１３は、１つの実施形態にしたがう、新しいメンバーをアクティブなグループ呼に加えるための例示的な処理を示す図である。
【図１４】図１４は、１つの実施形態にしたがう、グループ呼から参加者を削除するための例示的な処理を示す図である。
【図１５】図１５は、１つの実施形態にしたがう、ユーザの登録を削除するための例示的な処理を示す図である。
【図１６】図１６は、１つの実施形態にしたがう、いくつかの通信装置が通信マネージャとどのように対話するかを示す図である。
【図１７】図１７は、１つの実施形態にしたがう、通信マネージャ側でメディアをバッファリングすることを示す図である。
【図１８】図１８は、１つの実施形態にしたがう、クライアント側でメディアをバッファリングすることを示す図である。
【詳細な説明】
【００１９】
本発明の１つの実施形態を詳しく記載する前に、本発明は、その応用において、以下の記述に記載されているか、または図面に示されている構成要素の構成および配置の詳細に制限されないことが分かるであろう。本発明は、種々のやり方で実行される他の実施形態において実現できることが分かるであろう。さらに加えて、ここに使用されている専門語および用語は説明のためであり、制限しているとみなされるべきではないことが分かるであろう。
【００２０】
図１は、グループ通信システム100の例示的な機能ブロック図を示している。グループ通信システム100は、プッシュトーク（push-to-talk, PTT）システム、ネット同報通信サービス（net broadcast service, NBS）、ディスパッチシステム、ポイント ツウ マルチポイント通信システムとしても知られている。１つの実施形態において、グループ通信システム100は、ディスパッチャ、位置サーバ、メディア制御装置（media control unit, MCU）複合体、使用ログサーバ、およびインターネットプロトコル（ＩＰ）クライアント（ＩＰと接続したワイヤレス装置またはワイヤーライン装置、あるいはこの両者）のような、アプリケーションサーバ構成要素を含む。アプリケーションサーバ構成要素は、構成要素の機能に基づいて、中央配置か、または領域内配置の何れかで配置されうる。中央配置は、ホームディスパッチャ（home dispatcher, HD）102、ホーム位置サーバ（home location server, HLS）104、およびユーザ／グループデータベース106を含む。これらの構成要素は、サービスプロバイダネットワーク内で集中して配置され、領域内配置によってアクセス可能でありうる。中央構成要素は、ローミング中のユーザの位置を特定し、かつ領域間のグループ呼を開始するのに使用されうる。領域内配置108、110は、領域内位置サーバ（regional location server, RLS）112、領域内ディスパッチャ（regional dispatcher, RD）114、領域内メディア制御装置（media control unit, MCU）複合体116、および領域内使用ログサーバ（usage log server, ULS）118を含みうる。
【００２１】
領域内配置では、サービスプロバイダネットワーク全体に分散され、インスタント応答要求を満足させるために、呼のセットアップに伴うネットワークの遅延を最小に維持することを保証しうる。いくつかの領域ごとに分けられたシステムの全体に呼のロードを分散させると、多数のユーザを支援できるように、適切なスケーラビリティ方式を展開できることも保証される。領域内アプリケーションサーバ構成要素は、ユーザ登録、領域内呼のセットアップおよび管理、並びに領域内に登録されたユーザへの警告の開始および伝達を行う。
【００２２】
グループ通信装置（クライアント）120、122は、例えばcdma2000のハンドセット上に配置されることができ、標準のデータサービスオプションを使用して、パケットデータセッションを要求し、このセッションを使用して、ＩＰアドレスをアプリケーションサーバに登録し、グループ呼を開始する。１つの実施形態において、アプリケーションサーバ構成要素108、110は、サービスプロバイダのパケットデータサービスノード（packet data service node, PDSN）へ接続される。クライアント120、122は、無線インフラストラクチャからパケットデータセッションを要求するときに、ＰＤＳＮを介して、アプリケーションサーバ構成要素108、110とＩＰ接続する。
【００２３】
クライアント120、122は、パワーアップ時に、データサービスオプションを使用して、パケットデータセッションを要求する。クライアントは、パケットデータセッションの設定の一部として、ＩＰアドレスを割り当てられる。このとき、クライアントは、ドメイン名サービス（domain name service, DNS）サーバ124のアドレスも受信する。クライアント120、122は、例えば、サービス記録（service record, SRV）のルックアップを使用することによって、ＤＮＳサーバ124に照会して、ＲＬＳ112のアドレスを検出する。クライアント120、122は、ＲＬＳ112の位置を特定した後で、登録を行って、その位置情報、例えば、ＩＰアドレスをアプリケーションサーバへ通知しうる。登録は、ユーザデータグラムプロトコル（user datagram protocol, UDP）上のセッション開始プロトコル（session initiation protocol, SIP）のような、ＩＰプロトコルを使用して行われうる。クライアント120、122のＩＰアドレスは、ユーザがグループ呼へ勧誘されたときに、クライアントと接触するのに使用される。
【００２４】
１つの実施形態において、クライアントは、登録が完了した後に、別のＤＮＳのＳＲＶの記録をルックアップして、領域内ディスパッチャ114のアドレスを検出しうる。クライアントは、ユーザが呼を開始することを要求するか、または警告を送るときは必ず、領域内ディスパチャーに接触する。領域内ディスパッチャ114とクライアント120、122との間のインターフェイスは、ＵＤＰ上のシグナリングプロトコルでありうる。
【００２５】
グループ呼が設定されると、クライアント120、122とＭＣＵ複合体116とは、メディアおよびシグナリングメッセージを交換する。１つの実施形態において、メディアは、呼の参加者とＭＣＵ複合体116との間で、ＵＤＰ上の実時間プロトコル（real-time protocol, RTP）を使用して送られうる。シグナリングメッセージも、ＵＤＰ上のシグナリングプロトコルである。これらのプロトコルと、それらが与える機能については別途記載する。
【００２６】
構成要素
グループ通信システム100は、ＩＰエンドポイントを含むことができ、ＩＰエンドポイントには、クライアントソフトウエア、領域内サーバ構成要素、および中央サーバ構成要素が含まれ、これらはグループ通信サービスを提供するのに必要である。グループ通信クライアントおよびアプリケーションサーバ構成要素は、次に続くセクションにより詳しく記載する。
【００２７】
クライアント
グループ通信クライアント120、122は、適切なボコーダにアクセスするＩＰエンドポイント上で実行される。ＩＰエンドポイントは、無線システム、例えばcdma2000、アプリケーション開発プラットフォーム、例えば、無線用二元実行時環境（binary runtime environment for wireless, BREW）、およびパーソナルコンピュータ上で実行されるアプリケーションを含みうる。
【００２８】
クライアントは、ＢＲＥＷを使用して展開されるソフトウエアアプリケーションを含むことができ、移動局モデムソフトウエア（mobile station modem software, MSM）にインターフェイスし、ＢＲＥＷ環境を含むクライアントへダウンロードされうる。開発者は、ＢＲＥＷプラットフォームを用いて、クライアント通信装置上で実行されるアプリケーションを生成することができる。アプリケーションの開発者は、ＢＲＥＷを分離層として、ＭＳＭソフトウエアおよび相手先ブランド製造者（original equipment manufacturer, OEM）ソフトウエアとに直接に接触することなく、アプリケーションを開発することができる。これにより、アプリケーションを迅速に開発し、ＭＳＭのソフトウエア、またはＯＥＭのソフトウエア、あるいはこの両者とは無関係に発展させることができる。さらに加えて、アプリケーションを、ＢＲＥＷ環境を含む任意の装置へダウンロードすることもできる。図２に示されているように、クライアントグループ通信アプリケーションソフトウエア202は、他のアプリケーション204、206、208、および210と並列に実行されうる。これらのサービスは、ＯＥＭ212およびＭＳＭ214のインターフェイスによって直接に提供されるが、ＢＲＥＷは、これらの層においてアプリケーションによって行われる変更から分離する。したがって、ＯＥＭ212およびＭＳＭ214は、データアプリケーション202、204、206、208、210から個々に発展することができる。
【００２９】
クライアントがパーソナルコンピュータ上で効果的に動作するために、パーソナルコンピュータは、互換性のあるボコーダへのアクセス、サウンドドライバーへのアクセス、およびアプリケーションサーバへのＩＰ接続を含みうる。
【００３０】
位置サーバ
１つの実施形態において、位置サーバ（location server, LS）は、ユーザの位置情報を受領および／または維持する。ユーザの位置情報は、例えば、ネットワークレベルのＩＰアドレス、経度および緯度のようなユーザの物理的な位置、および／またはパケットゾーン識別子、すなわち、順方向共通チャネル上で空中で同報通信され、パケットデータサービスをそのセクターへ供給するＰＤＳＮの範囲を識別するシステム識別子である。１つの実施形態において、ＬＳは、クライアントからの登録を処理し、ユーザ位置情報を、ＳＩＰインターフェイスを使用して、インスタントメッセージングのような他のアプリケーションへ供給する構成要素を含みうる。
【００３１】
ＬＳは、２つの機能素子、すなわち領域内位置サーバ（regional location server, RLS）112およびホーム位置サーバ（home location server, HLS）104を含みうる。ＲＬＳ112は、領域ごとに配置され、ＨＬＳ104は中央に位置する。これらの要素および機能の詳細は、別途記載する。
【００３２】
領域内位置サーバ
ＲＬＳ112は、その領域内に位置するクライアントからの登録を処理し、維持しうる。１つの実施形態において、ＲＬＳ112は、ユーザ位置情報のための付属メモリを備えた標準のＳＩＰベースのＬＳである。ＲＬＳ112は、登録エントリの維持の一部として、各登録の有効期限日、すなわち“有効期限”範囲を検査する。ＲＬＳは、有効期限の切れたエントリを削除し、領域内ディスパッチャ（regional dispatcher, RD）およびＨＬＳに、削除したエントリを知らせることを保証する。
【００３３】
前述のように、クライアントは、アプリケーションサーバへその位置を通知するために、ＩＰ登録を行なうことができる。クライアントは、グループ通信サービスが使用可能な期間の間、その登録を維持しうる。クライアントは、クライアントのＩＰアドレスが変わるとき、および登録の期限が切れようとしているときに、再登録を行いうる。
【００３４】
クライアントが登録または再登録するとき、ＲＬＳ112は、関係付けられたＲＤ114に通知しうる。したがって、ＲＤ114は、呼セットアップ要求を準備するとき、ユーザデータをプレロードして、呼セットアップ時間を低減することができる。ＲＤ114は、ユーザの位置情報をキャッシュし、呼セットアップ中にＲＬＳと接触して、ユーザの位置情報を検索する必要をなくしうる。
【００３５】
ＲＬＳ112は、ユーザの位置情報を更新するか、またはＲＬＳ112から削除するときに、ＲＤ114へ通知しうる。したがって、ＲＬＳ112よびＲＤ114は、領域内に登録されたユーザについての最新情報で同期を維持することが保証される。
【００３６】
ＲＬＳ112はまた、ＨＬＳ104を、登録されたユーザの位置情報で定期的に更新しうる。ＲＬＳ112が、別の領域内に有効な登録を既にもっているユーザの登録をＨＬＳ104へ提出するとき、ＨＬＳは競合を解消しうる。
【００３７】
ホーム位置サーバ
ＨＬＳ104は、ユーザの位置情報についての照会を処理しうる。１つの実施形態において、ＨＬＳ104は、ＳＩＰベースのインターフェイスを用意して、インスタントメッセージングアプリケーションのような他のアプリケーションが、個々のユーザの位置情報を照会できるようにする。
【００３８】
ＨＬＳ104が中央構成要素であり、ＲＬＳがそれと通信するとき、ＨＬＳは、ローミング中のユーザが異なる領域において行った多数の登録を分析する。ＨＬＳ104は、ＲＬＳの各々から登録情報を受信しうる。ＨＬＳ104が同一ユーザの多数の登録を受信するとき、ＨＬＳ104は最近の登録を維持して、そのユーザの古い登録をＲＬＳから削除することを要求する。これは、また、古い登録を収めているＲＬＳと関係付けられたＲＤ114から、そのユーザについてのキャッシュされた情報の除去をトリガしうる。
【００３９】
ディスパッチャ
ディスパッチャは、ユーザの位置を特定して、かつグループ呼をメディア制御装置（media control unit, MCU）複合体116へ割り当てることによって、呼のセットアップを促しうる。ディスパッチャは、“インスタントアクセス”要求を満たすための鍵であるサーバ構成要素である。ディスパッチャは、最低呼セットアップ時間を保証するために、同様の構造および機能をもつが、配置方式が異なる２つの機能要素を含みうる。これらの２つの要素、すなわち領域内ディスパッチャ（regional dispatcher, RD）114およびホームディスパッチャ（home dispatcher, HD）102は、次に続くセクションにおいて詳しく記載する。
【００４０】
領域内ディスパッチャ
ＲＤ114は、呼セットアップ要求および警告要求のための最初の接触点でありうる。ＲＤ114は、ＲＬＳ112からユーザが登録したという指示を受信するとき、ユーザ情報をプレロードしうる。ＲＤ114は、ユーザ情報と一緒に、システム内で実行されているグループ呼に関する情報をキャッシュしうる。ＲＤ114は、呼セットアップ中にユーザおよびグループについてのキャッシュされた情報を使用して、すなわち、データベースをルックアップする必要をなくして、セットアップ時間を最低に維持しうる。
【００４１】
１つの実施形態において、ＲＤがキャッシュに記憶しているグループ情報は、グループメンバーリストと、グループが載っているＭＣＵ複合体116のアドレスとを含む。ＲＤ114は、メンバーリストおよびＭＣＵのアドレスを、呼の存続期間の間、維持しうる。これは、ＲＤ114が、到来呼が、システムにおいて既に実行されている関係付けられた呼を含むグループと同じグループである必要があるかどうかを迅速に判断するのを助け、これにより、ＲＤは、呼セットアップ要求に迅速に応答し、かつ応答において“フロア”要求を確信をもって承諾または拒絶することができる。
【００４２】
ＲＤ114は、フロア制御要求を承諾または拒絶しうる。ＲＤ114は、ユーザを“遅れ加入”の参加者として呼に加えるか、または関係付けられたメンバーリストを用いて新しい呼を開始するように、ＭＣＵ複合体116に要求するかどうかを決定しうる。
【００４３】
ＲＤ114は、呼セットアップ要求の処理の間に、キャッシュされたユーザ情報を使用して、呼セットアップ要求において指定されたユーザの位置情報を検索しうる。ユーザの位置を特定できないときは、ＲＤ114は、ユーザの位置を特定するようにＨＤ102に要求しうる。１つの実施形態において、少なくとも１人以上の目標のユーザの位置が特定されるときは、ＲＤ114は呼のセットアップを継続する。ＲＤ114は、目標のユーザの位置が特定された後で、呼を何れのＭＣＵに割り当てるかを決定しうる。この判断は、発信者を含む、グループ内のユーザのＩＰアドレスに基づいてもよい。
【００４４】
ＲＤ114は、呼要求と同様に、警告要求を処理しうる。１つの実施形態において、警告要求は、目標のユーザの位置に関係なく、処理のために局所ＭＣＵ複合体116に割り当てられる。
【００４５】
１つの実施形態において、ＲＤのキャッシュ内の情報は、信頼できるメモリ機構へ定期的に書込まれ、したがって、故障の際は、回復されうる。ＲＤの故障が回復されると、信頼できるメモリ機構へ書込まれたユーザおよびグループの情報は、キャッシュへ再びロードされ、ＲＤは、到来呼のセットアップ要求の処理と関係して、キャッシュされた情報を確認することを始める。
【００４６】
１つの実施形態において、ＲＤ114は、ＲＬＳ112から各ユーザの登録を通知されると、ユーザデータを局所キャッシュへロードする。呼をセットアップするときに、いくつかのデータベースをルックアップする必要を無くすことによって、ＲＤ114は、呼セットアップ要求または警告要求を確認して応答するのにかかる時間を相当に低減する。
【００４７】
ＲＤ114は、呼セットアップ中にユーザ／グループデータベース106にアクセスして、要求の中にあるときは、所定のグループアドレスを個々のユーザのリストへ拡張し、必要であれば、ユーザまたはグループの代わりの識別子（例えば電話番号、会議ＩＤ）を、標準アドレスへ変換しうる。
【００４８】
ホームディスパッチャ
ホームディスパッチャ（home dispatcher, HD）102は、登録されたユーザの位置情報を追跡しうる。ＨＤは、ＲＬＳ112に登録されたユーザの位置情報を含みうる。
【００４９】
前述のように、各ＲＬＳ112は、ユーザ登録、再登録、登録解除、または登録の有効期限切れのたびに、関係付けられたＲＤ114へ通知しうる。ＲＤ114は、この情報を使用して、局所キャッシュ内のユーザ情報をロードまたは解放する。各ＲＤ114は、ユーザ位置情報についてＨＤ102を更新しうる。ＨＤ102はＲＤ114から更新を受信するので、ＨＤ102は、異なる領域に地理的にまたがって分散しているユーザを検出するのを助けうる。ＲＤ114は、領域内に現在登録されていないユーザ、すなわちＲＤのキャッシュ内にそのユーザ情報がないユーザの要求を受信するとき、ＨＤ102からの支援を要求しうる。
【００５０】
ＤＮＳサーバ
１つの実施形態において、グループ通信システム100は、サービスプロバイダのＤＮＳサーバ124を使用して、ＲＬＳ112およびＲＤ114の位置情報を、クライアントへ供給しうる。この情報は、各領域内配置ごとに構成され、その精度を保証するために、定期的に更新されうる。
【００５１】
１つの実施形態において、各クライアントは、パケットデータセッションを要求するとき、ポイント ツウ ポイント プロトコル（ＰＰＰ）セッションの設定中に、インターネットプロトコル制御プロトコル（Internet protocol control protocol, IPCP）のネゴシエーションによって、ＤＮＳサーバのアドレスを知る。ＤＮＳサーバ124は、このやり方で領域ごとに公示されうる。したがって、クライアントは領域から領域へロームして、クライアントが位置しているのと同じ領域内のＤＮＳサーバ124と通信することができる。ＤＮＳサーバ124は、領域ごとに、各ＰＤＳＮと共に配置される。１つの実施形態において、ＤＮＳサーバ124は、ＤＮＳサーバ124が関係付けられているＰＤＳＮにサービスしている各ＲＤ114およびＲＬＳを用いて更新されうる。
【００５２】
１つの実施形態において、適切なＲＤ114およびＲＬＳ112の位置を特定するのに使用される機構は、ＤＮＳおよびＳＩＰのアドレス指定の組合せに基づいている。ＤＮＳのサービス（service, SRV）記録のルックアップは、クライアントが登録しているＳＩＰのＵＲＩの“＜ドメイン＞”部分に基づいて行われうる。ＳＲＶ記録要求は、要求者が検出しようとしているプロトコルまたはサービスを含みうる。例えば、ＲＬＳ112の位置を特定しようとする場合に、クライアントは、ＤＮＳのＳＲＶの記録のルックアップにおいて“登録サービス”を要求する。ＤＮＳ応答は、１つ以上の有効なネットワークおよび要求されたサービスを提供するサーバのポートアドレスを含みうる。ＤＮＳサーバ124を使用して、クライアントの要求への返答を戻すときに、ＤＳＮサーバ124を多数のサーバ間でラウンドロビンさせることによって、同じサービスを提供するサーバ間でロードの平衡をとりうる。
【００５３】
ユーザ／グループデータベース
１つの実施形態において、ユーザ／グループデータベース106は、ユーザおよびグループ情報のための中央リポジトリである。各ユーザについて、データベースは、ユーザアドレス、プリエンプションランク、認証情報、ユーザ接触情報、およびユーザが監視されているかどうかを示す合法の傍受フラグのような情報を含みうる。データベースは、ディスパッチサービスのチャットルームモデルのための所定のグループの定義、すなわちユーザおよび関係付けられたグループ名のリストも含みうる。各グループは、例えば、グループデータベースによって固有に識別されうる。クライアントは、グループアドレスを使用して、グループ呼設定要求のグループを識別しうる。ＲＤ114は、ユーザ／グループデータベース106内の所定のグループとのグループ呼セットアップ要求を受信すると、グループアドレスを使用して、そこから、関係付けられたメンバーリストを検索しうる。
【００５４】
メディア制御装置複合体
メディア制御装置（media control unit, MCU）の複合体は、メディア制御ホスト（media control host, MCH）とメディア制御装置（media control unit, MCU）とを含みうる。ＭＣＨは、多数のＭＣＵの処理をホストし、管理しうる。各ＭＣＵは、１つの呼ごとに、実時間のシグナリングおよびメディア処理を取扱いうる。ＭＣＵが行なう機能は下記機能を含みうる：
・ＲＤ114からの呼の割当てを処理する機能；
・ローディングおよび状態情報をＭＣＨへ送る機能；
・呼開始情報をクライアントへ送る機能；
・ＰＴＴ要求のような、クライアントからのインコールシグナリングを処理する機能；
・シグナリングメッセージが、クライアントへ確実に伝送されるのを保証する機能；
・“１対多数”の呼において、メディアを複製して、分配する機能；
・“ミックス”ボコーダの“１対多数”の呼において、適切なトランスコーダを使用してメディアを変換する機能；
・呼のアクティビティを監視して、メディアの流れのアクティビティがないことに基づいて、呼の終了を開始する機能；
・使用ログサーバ（usage log server, ULS）118のために使用情報を生成する機能；
・要求されたときに、メディアおよびシグナリング情報を、適切な合法の傍受点へ送る機能。
【００５５】
ＭＣＵは、ＲＤ114からの警告要求を処理し、警告通知をクライアントへ送り、クライアントからの肯定応答を待ちうる。ＭＣＵは、目標のユーザから肯定応答を受信すると、警告トランザクションに割り当てられた資源を解放する。このとき、ＭＣＵは、他の呼割当てまたは警告要求を処理してもよい。
【００５６】
使用ログサーバ
ＵＬＳ118は、各領域内に存在し、ＭＣＵ複合体116と一緒に配置されうる。ＵＬＳ118は、各呼または警告処理ごとにＭＣＵ複合体116から使用イベントを収集し、それらを使用データ記録（usage data record, UDR）へフォーマットし、これらのＵＤＲを、一連のＵＤＲファイルに記憶しうる。呼のＵＤＲは、参加者と参加者使用合計のリストを含めて、個々の呼に関する情報を含みうる。警告のＵＤＲは、警告の発信者、および警告が送られた目標のユーザを示す情報を含む。ＵＤＲファイルは、サービスプロバイダーによって課金解析のために収集され、一定の時間の後で削除されうる。
【００５７】
ＵＬＳ118は、各呼の最後に、呼のインスタンスごとに、１つのＵＤＲを書込む。ＵＬＳ118は、警告要求が処理されるたびに、単一のＵＤＲを書込む。ＵＬＳ118によって書込まれるＵＤＲは、次の情報を含みうる：
・呼インスタンス識別子または警告インスタンス識別子；
・ＭＣＵ識別子。これは、呼の位置を示唆する。呼を開始するとき、適切なＭＣＵが、全予定参加者の登録された位置に基づいて選択される。ＭＣＵの位置は、発信者と同じ領域内にあっても、そうでなくてもよい；
・呼または警告の開始時間；
・呼または警告の終了時間；
・発信元ユーザの名前および／または識別子；
・発信元ユーザのＩＰアドレス；
・各参加者ごとの、ユーザ名、ユーザアドレス、ユーザＩＰアドレス、累積参加時間（警告はゼロであってもよい）、および参加者がフロアを保持した合計時間（秒）（警告はゼロであってもよい）。
【００５８】
１つの実施形態では、各呼ごとに、１つのＵＤＲが発行される。ＵＤＲは、呼中のトークセグメントの全収集を表わす。各トークセグメントごとに、ＵＤＲへのイベントのロギングが要求されるとき、これは、ロード要件、ファイルのＩ／Ｏ要件、およびディスク空間要件をさらに処理するという犠牲を払って実行されうる。
【００５９】
グループ通信システム100は、グループサービスを行うために、幾つかの異なる機能を実行する。ユーザの経験に関係する機能は、登録、呼の開始、呼の終了、警告の送付、遅れ加入、送話者の調停、ユーザの追加、メンバーの除去、登録解除、アドレス指定、および認証を含む。システムの準備および動作に関係する機能は、管理および準備、スケーラビリティ、および信頼性を含む。これらの機能は、次に続くセクションに詳しく記載する。
【００６０】
登録
無線通信システム、例えば、ＣＤＭＡシステムにおいて、登録とは、移動局の位置を、無線通信システムのインフラストラクチャに分かる位置にする処理である。この位置情報は、移動局が位置する地理的領域、および移動局にサービスしている基地局の識別子を含み、ページングおよびアクセスチャネルの効率的な使用を助けるのに使用されうる。
【００６１】
１つの実施形態において、ユーザ位置情報は、クライアントがワイヤレスサービスを介して接続されるか、またはワイヤーラインサービスを介して接続されるかとに関係なく、クライアントのＩＰアドレスである。ＩＰアプリケーションがＩＰアドレスに基づいてクライアントの位置を特定できるようにする例示的なＩＰプロトコルは、セッション開始プロトコル（ＳＩＰ）である。とりわけ、ＳＩＰは、クライアントが、ＩＰアドレスおよび他の位置情報をＳＩＰサーバ構成要素に登録するための方法を与える。さらに加えて、ＳＩＰは、クライアントを“検出する”ことに関係しているＩＰアプリケーションが、クライアントのＩＰアドレスのような位置情報について、同じＳＩＰサーバ構成要素に照会する方法を与える。
【００６２】
登録は、ＩＰクライアントがＳＩＰサーバ構成要素と通信して、その位置情報、例えば、ＩＰアドレスを通知して、維持する処理を含みうる。この機能を備えたＳＩＰサーバ構成要素は、位置サーバである。クライアントが位置サーバにその位置を通知するか、またはその位置を変更する方法は、ＳＩＰ登録（SIP REGISTER）方法である。
【００６３】
１つの実施形態において、クライアントは、その位置情報を、領域内位置サーバへ登録する。インスタントメッセージングのような、他のＩＰベースのアプリケーションは、位置サーバで得られる各クライアントのＩＰアドレスの情報を得ることを利用する。外部のサービスまたはクライアントが、登録を行ってもよい。図３は、登録機能を行うための例示的な呼の流れを示す。
【００６４】
パワーアップ時に302、クライアントはパケットデータセッションを要求して、そのＩＰアドレスをＲＬＳ112に登録する処理を開始する。クライアントは、登録を行うために、ＤＮＳのＳＲＶの記録をルックアップし304、ＲＬＳのアドレスを判断しうる。クライアントは、ＲＬＳアドレスを検索すると306、その位置情報を、例えば、ＳＩＰ登録メッセージを使用することによって登録しうる308。ＲＬＳはユーザを認証し310、応答をクライアントへ発行する312。ＲＬＳは、ユーザが登録されていることを領域内ディスパッチャへ通知し314、領域内ディスパッチャは、この情報を使用して、ユーザに関係するデータ記録をプレロードして、呼のセットアップ中により迅速な応答を促しうる。この時点で、クライアントは、グループ呼に参加する勧誘のために接触されうる。１つの実施形態において、クライアントは、実行するデータ接続の形式、すなわちワイヤレスか、またはワイヤーラインかとは無関係に、グループ呼を受信するために、登録を行う必要がありうる。
【００６５】
登録は、それと関係付けられた“有効期限切れ”の範囲を有しうる。“有効期限切れ”の範囲は、クライアントの登録情報が有効であると考えられる期間を示す。ＩＰによってクライアントに常に到達可能であることを保証するために、クライアントは、登録の有効期限切れを意識して、有効期限が切れる前に再登録を行いうる。登録は、クライアントのＩＰアドレスが変更されたとき、またはクライアントと位置サーバとのデータ接続が切断されたときのような、他の環境のために、無効または失効になることもある。クライアントは、データ接続の状態と、ＩＰアドレスが変更されたかどうかとを意識しうる。
【００６６】
最初の登録が完了すると、クライアントは、そのパケットデータセッションを休止状態にし、専用トラヒックチャネルを解放しうる。クライアントは、そのパケットデータセッションを監視して、休止状態の延長期間中は、有効のままであることを保証しうる。セッションの有効性に影響を与えうる状況は、異なるパケットゾーンＩＤをもつ区域へ移動すること、フェードまたはサービスの損失を経験すること、および／またはＰＴＳＮの呼を行うことを含む。クライアントのＩＰアドレスは変わり、クライアントは、インフラストラクチャとのデータ接続を再設定することを要求されうる。クライアントは、そのパケットデータセッションを再設定すると、新しいＩＰアドレスを受信する。クライアントの位置情報が正確であり続けることを保証するために、新しいＩＰアドレスを位置サーバへ伝えなければならない。これは、再登録を行うことによって達成されうる。
【００６７】
ファイアウォールを通って位置サーバと通信するワイヤーラインのクライアントは、位置サーバを定期的に“ピング”することによって、ファイアウォールを通る穴を維持する必要がある。これは、再登録を行うことによって達成される。
【００６８】
グループ呼開始
ユーザは、登録完了後に、呼を発信または受信しうる。クライアントは、パワーアップ後に、最初の呼を開始する前に、ＤＮＳのＳＲＶの記録をルックアップし、領域内ディスパッチャの位置を検出しうる。これは、立ち上げ処理の一部として行われうる。
【００６９】
“グループ”は、発信者、グループのセットアップを開始したユーザ、１人以上の目標のユーザを含むメンバーリストと関係付けられる。メンバーリストは、１人以上のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを含む。メンバーリストが１人のユーザのみを含むとき、そのメンバーリストを使用して開始される呼は、一般に、プライベートコールと呼ばれる。メンバーリストが所定のグループを含むときは、領域内ディスパッチャは、例えば、元のメンバーリスト内の所定のグループの識別子を、所定のグループの関係付けられたメンバーリストと置換することによって、所定のグループを、１人以上の目標のユーザのリストへ拡張する。所定のグループの拡張後に、生成されたメンバーリストは、目標のユーザ名を含む。この時点で、領域内ディスパッチャは、領域内ディスパッチャのキャッシュをユーザ情報について走査することによって、メンバーリスト内の目標のユーザの位置を特定することを試みる。目標のユーザが、領域内ディスパッチャのキャッシュ内に位置するときは、グループのメンバーは、領域内ディスパッチャと同じ領域内に登録される。このタイプのグループ呼は、“領域内”呼と分類される。領域内ディスパッチャが位置を特定できないユーザがいるときは、領域内ディスパッチャは、ホームディスパッチャからの支援を要求して、ユーザの位置を特定する。２つ以上の領域からのメンバーを含むグループと関係付けられている呼は、“領域間”呼と呼ばれる。
【００７０】
領域内ディスパッチャは、呼が領域内であるか、または領域間であるかを判断した後で、何れのメディア制御装置（ＭＣＵ）が呼をホストするかを判断する処理を開始しうる。領域内呼において、領域内ディスパッチャは、領域内ディスパッチャと同じ領域内に位置するＭＣＵへ、その領域内においてＭＣＵの資源が使用可能であるときは、呼を割り当てうる。このタイプの呼のセットアップを使用して生成される呼は、“局所的にホストされた”呼、または局所呼と呼ばれる。領域間呼では、領域内ディスパッチャは、同じ領域内のＭＣＵか、あるいは遠隔または外部の領域のＭＣＵへ呼を割り当てる選択肢をもつ。領域内ディスパッチャは、ユーザの位置情報に基づいて、この決定を行って、メディアおよびシグナリングを含むＩＰパケットの最適移動経路を検出しうる。ユーザの大半が特定の領域内で位置を特定されるときは、呼はその領域へ割り当てられる。ユーザが領域間で均等に分散しているときは、呼は、目標のユーザを含む領域の１つへ割り当てられうる。領域間呼が、領域内ディスパッチャが位置する領域とは、異なる領域内のＭＣＵへ割り当てられるときは、呼は“遠隔でホストされる”または遠隔呼と呼ばれる。領域内ディスパッチャは、ＭＣＵと、それらがサービスしているＰＤＳＮとのネットワークトポロジまたは接続、あるいはこの両者について知ると、この知識を使用して、呼の割当てをより適切に決定しうる。
【００７１】
領域内呼
グループ通信システム100は、呼の大半が領域内であることを保証するように配置されうる。領域内呼では、呼のセットアップ時に、領域内ディスパッチャ114とホームディスパッチャ102とが通信をする必要をなくしうる。領域内呼の大半に当てはまるように、目標のユーザが同じ領域内にあり、かつ呼が局所的にホストされているときも、領域間で通信する必要をなくしうる。次に続くセクションは、領域内呼における、呼の流れ、タイミングの推定、およびメッセージング方式を記載している。
【００７２】
局所呼の開始
図４は、局所グループ呼を開始するための例示的なメッセージの流れを示している。ユーザは、１人以上の目標のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを選択して、プッシュトーク（ＰＴＴ）ボタンを押しうる402。別途詳しく記載するように、クライアントは、移動局が専用トラヒックチャネルをもつかどうかとは関係なく、グループ呼をセットアップする要求を領域内ディスパッチャへ送る404。要求を送った後で、移動局のパケットデータセッションが休止状態であるときは、クライアントは、専用トラヒックチャネルを再設定し、メディアのアクティビティのためのパケットデータセッションを準備する処理を開始しうる。クライアントは、発信者から受信したスピーチ入力を所定の期間の間、バッファリングしうる。
【００７３】
領域内ディスパッチャは、要求を受信すると、要求において指定された所定のグループを、目標のユーザのメンバーリストへ拡張しうる。その後で、領域内ディスパッチャは、目標のユーザの位置情報を検索する406。この時点で、領域内ディスパッチャは、グループがシステムにおいて既に実行されているかどうかを判断しうる。図４は、グループがまだ実行されていないシナリオを示す。遅れ加入の呼のシナリオは、グループが既に実行されている場合を示し、本明細書において別途記載する。
【００７４】
領域内ディスパッチャは、目標のユーザの少なくとも１人の位置を特定した後で、グループ呼がセットアップされたことを示す応答をクライアントへ送りうる408。この時点で、クライアントは、発信者が話す要求を楽観的に承諾して410、メディアをバッファリングし始めうる412。
【００７５】
領域内ディスパッチャは、目標のユーザの位置を使用して、呼が割り当てられる領域を判断しうる。図４に示されているように、目標のユーザが、領域内ディスパッチャと同じ領域内にあると判断されたときは、領域内ディスパッチャは、呼を領域内ＭＣＵへ割り当てうる。ＭＣＵは、呼が始まっていることを示すアナウンスメントをグループ全体へ送る414。目標のユーザへアナウンスメントを送ると、パケットデータセッションが休止状態から抜け出て、かつトラヒックチャネルを再設定することをトリガしうる。
【００７６】
クライアントが呼のアナウンスメントをＭＣＵから受信し、かつ移動局のトラヒックチャネルが再設定された後で、クライアントは、バッファリングされたメディアをＭＣＵへ送りうる416。ＭＣＵは、発信者から受信したメディアをバッファリングしうる418。１つの実施形態において、ＭＣＵは、“目標の応答の閾値”が満たされるか、またはそれを越えるまで、メディアをバッファリングしうる。目標の応答の閾値は、メディアの送付を始めるのに必要な目標の応答の量の指標である。閾値は、構成可能なパラメータであってもよい。閾値が満たされると、ＭＣＵは、メディアを複製して、目標のユーザへ送り420、目標のユーザは呼のアナウンスメントに応答する422。
【００７７】
ショートデータバーストによるメッセージング
“インスタント応答”は、アプリケーションサーバが、ＰＴＴまたは呼セットアップ要求に応答するのにかかる応答時間に関係する。グループ呼セットアップ要求を含む、ＰＴＴ要求への応答は、常に一貫して、所定の時間期間（例えば、1秒以下）で常に要求に応答することを目標とする。多くの場合に、ユーザがグループ呼をセットアップすることを要求するとき、ユーザのパケットデータセッションは休止状態であり、専用トラヒックチャネルは存在しない。専用トラヒックチャネルの再設定には相当な時間がかかる。したがって、アプリケーションサーバへの通信を、他の手段によって達成してもよい。
【００７８】
グループ通信システムが“インスタント応答”を実現することを保証するために、小さいＩＰデータグラムを、パケットデータセッションの状態に関係なく、常に何れかの方向、すなわち移動局から発信する方向または移動局で終端する方向へ送りうる。１つの実施形態において、ＩＰデータグラムは、ショートデータバーストメッセージ（short data burst message, SDB）の形で送られる。パケットデータセッションが休止状態である状況では、ＳＤＢメッセージは、オーバーヘッドチャネル上で送られることになる。専用トラヒックチャネルが接続されているときは、ＳＤＢメッセージはトラヒックチャネル上で送られる。
【００７９】
図４を参照すると、グループ呼セットアップ要求は、ＳＤＢメッセージによって送られる404。アプリケーションサーバからのグループ呼セットアップ応答も、ＳＤＢメッセージで送られる408。呼セットアップ要求および応答のメッセージをＳＤＢメッセージによって送ることにより、グループ通信システム100は、“インスタント応答”の目標を満たすことができる。
【００８０】
ＭＣＵは、発信者を含むメンバーリスト内のユーザへ、呼のアナウンスメントを送ることにより、グループ呼をセットアップする処理を完了しうる。この呼のアナウンスメントは、専用トラヒックチャネルを介して送られうる。大抵の場合に、グループメンバーのパケットデータセッションは休止状態であり、すなわち専用トラヒックチャネルは設定されない。したがって、メンバーの全トラヒックチャネルが再設定され、かつメンバーがメッセージを肯定応答するか、または信頼性タイマーが切れるまで、ＭＣＵは、しつこく確実なスケジュールで、呼アナウンスメントメッセージを再送しなければならない。呼のアナウンスメントをアグレッシブに送ることにより、クライアント上でメディアをバッファリングすることが促され、ＭＣＵは最低に維持されることを保証する。クライアントは、そのトラヒックチャネルの準備が完了し、かつＭＣＵ接触情報を含む呼のアナウンスメントを受信すると直ぐに、バッファリングされたメディアを送る。ＭＣＵは、目標の応答閾値が満たされるか、または越えると直ぐに、バッファリングされたメディアを複製して、送りうる。したがって、より迅速に目標のクライアントが呼のアナウンスメントを受信して、応答し、かつより速くこの閾値が満たされると、より速くＭＣＵはバッファリングを止めて、メディアを送り始める。
【００８１】
発信者への呼のアナウンスメントも、ＳＤＢによって送られうる。これは、２つの効果を与える。第１に、呼のアナウンスメントはＭＣＵ接触情報を含むので、移動局のトラヒックチャネルが再設定されると直ぐに、グループ呼のクライアントは、バッファリングされたメディアをＭＣＵへ送り始め、バッファリングされたメディアを保持する移動局のＲＡＭの要件が緩和されうる。第２に、呼のアナウンスメントがＳＤＢによって届くとき、トラヒックチャネルが再設定される前に、発信者が呼を捨てるか、またはフロアを解放すると決定するならば、クライアントはその情報をＭＣＵに通知することができる。呼のアナウンスメントをＳＤＢによって発信者へ送ると、共通チャネル上のロードが増し、かつＭＣＵは、発信者の呼アナウンスメントメッセージに特別な処理を行なわなければならなくなる。
【００８２】
遠隔呼の開始
全メンバーが同じ領域内に位置しているときは、領域内の呼は局所的にホストされうる。領域内ディスパッチャは、局所資源がオーバーロードしているか、または使用できないという理由で、領域内呼を遠隔領域へ割り当てうる。このような場合に、ユーザのＰＤＳＮと遠隔のＭＣＵとの通信経路が伸びるので、メディアおよびシグナリングの待ち時間および誤りが追加されることがある。図５は、遠隔の領域内呼に対する例示的な呼セットアップを示している。
【００８３】
遠隔のホスト上で領域内呼を開始することは、図４に関係して記載した呼セットアップのシナリオに類似しているが、領域内ディスパチャーが呼をＭＣＵへ割り当てることが異なる。領域内ディスパッチャは、グループメンバーの位置を検索した後で、呼が割り当てられるＭＣＵを判断する。領域内ディスパッチャは、ユーザの位置情報、ローディング、およびＭＣＵの可用性に基づいて、この決定を行いうる。領域内呼では、ユーザは同じ領域内に位置を特定されるので、領域内ディスパッチャは、局所領域内のＭＣＵ複合体のローディングおよび可用性を検査しうる。領域内ディスパッチャは、局所ＭＣＵ複合体がオーバーロードしているか、または一時的に動作障害を経験したという指標を受信すると、呼を遠隔のＭＣＵへ割り当てうる。１つの実施形態において、各ＭＣＵでは、呼構成を除いて、同一の機能が複製されているので、遠隔のＭＣＵは、局所ＭＣＵと同様に、呼を処理しうる。
【００８４】
領域間呼
グループ呼システム100は、ユーザが他のユーザと、相互の物理的な位置または近さに関係なく、通信できるように設計されうる。領域間呼では、呼セットアップ時間に領域内ディスパッチャとホームディスパッチャとの通信が必要であるので、グループ通信システム100は、領域間呼の数を制限するように配置されうる。呼は、呼の参加者の１人以上から、遠隔領域内のＭＣＵへ割当てられうる。次に続くセクションでは、例示的な呼の流れ、タイミング推定、および領域間の呼のメッセージ方式を記載する。
【００８５】
局所呼の開始
図６は、局所的にホストされるグループ呼を開始するための例示的なメッセージの流れを示している。局所の領域間呼の呼セットアップは、図４に関係して記載した局所の領域内呼の呼セットアップに類似しているが、局所ディスパッチャが目標のユーザの位置情報を検索する処理をすることが異なる。１つの実施形態において、領域内ディスパッチャは、そのキャッシュ内の目標のユーザの位置を特定することを試みる。何人かのユーザがキャッシュ内で検出されないときは、局所ディスパッチャは、ホームディスパッチャからの支援を要求して、ユーザの位置を特定する。ホームディスパッチャは、領域内位置サーバを使用して、ＩＰ登録を行ったユーザのユーザ位置情報を収めうる。前述のように、領域内位置サーバは、ユーザの登録が行われるたびに、関係付けられた領域内ディスパッチャに通知しうる。各領域内ディスパッチャは、ホームディスパッチャにユーザの登録を通知する。したがって、ホームディスパッチャは、地理的に異なる領域にまたがって分散しているユーザを検出する際に、領域内ディスパッチャを支援することができる。
【００８６】
遠隔呼の開始
図７は、遠隔の領域間呼の例示的なセットアップを示している。遠隔のホストにおける領域間呼を開始することは、図４に関係して記載した呼セットアップのシナリオに類似しているが、領域内ディスパッチャがＭＣＵへ呼を割り当てることが異なる。領域内ディスパッチャ（ＲＤ）114は、グループメンバーの位置を検索した後で、呼が割り当てられるＭＣＵを判断しうる。ＲＤ114は、ユーザの位置情報、ローディング、およびＭＣＵの可用性に基づいて、この決定を行いうる。ＲＤは、グループメンバーの位置を使用して、サービスプロバイダのネットワーク上での、メディアおよびシグナリングを含むＩＰパケットの、メンバーの大半への最適移動経路を検出することを試みる。ユーザの大半が特定の領域に位置を特定されるときは、呼はその領域に割り当てられうる。ユーザが領域にまたがって均等に分散しているときは、呼は、目標のユーザを含む領域の1つへ割り当てられうる。
【００８７】
グループ呼の終了
グループ呼は２つの理由で終了する。すなわち、全参加者が、呼から抜け出るように要求されたとき、または全参加者が、所定の時間期間の間、話すのを止めるとき（“ハングタイム”と呼ばれる）である。各参加者は、呼の予定された終了前に、呼に参加するのを止めることを選択してもよい。全参加者が呼から抜け出るときは、ＭＣＵは呼を終了して、呼に割当てられた全資源を解放する。１人を除く全参加者が呼から抜け出ると、ＭＣＵは、“単独のユーザ”と呼ばれる参加者に通知しうる。単独のユーザは、直ちに呼から抜け出るか、またはハングタイムのタイマーが切れるのを待つことを選択し、これにより、ＭＣＵは呼の切断をトリガしうる。
【００８８】
ＭＣＵは、ハングタイムタイマーが切れたときに、呼を終了しうる。ＭＣＵは、各トークスパートを追跡し、トークスパートの完了後にタイマーをセットする。このタイマーは、ハングタイムタイマーと呼ばれ、呼中の、沈黙期間、すなわち、トークまたはメディアの流れのアクティビティがない期間を追跡しうる。呼が、サービスプロバイダによって構成されるハングタイム期間の沈黙のままであるときは、ＭＣＵは、参加者が呼に最早関心がないと断定し、呼を終了しうる。
【００８９】
ユーザが呼の終了を開始
図８は、ユーザがグループ呼への参加を止めることを選択する例示的なシナリオを示している。シナリオは、ユーザが参加を止めるメッセージの流れを示している。ユーザがグループ呼への参加を止めることを選択するとき802、クライアントはユーザを呼から削除する要求をＭＣＵへ送る804。ＭＣＵは、ユーザを呼から削除し806、ユーザが削除されたことをクライアントへ通知しうる808。
【００９０】
サーバが呼の終了を開始
図９は、ハングタイムタイマーが切れて、ＭＣＵがグループ呼を終了するときに行われる例示的なメッセージの流れを示す。ハングタイムタイマーが切れると902、ＭＣＵは、呼が終ったという通知を参加者へ送りうる904。呼終了通知を受信した各クライアントは、肯定応答で応答する906。ＭＣＵは、肯定応答を受信すると、呼が終了したことをＲＤへ知らせ、呼に割り当てられた資源を解放しうる908。
【００９１】
警告の送付
警告機構は、別のユーザ、すなわち警告発信者が、目標のユーザをグループ呼に参加させたいという意向を、目標のユーザに通知するのに使用されうる。警告機構は、発信者が呼の対象を指定できるようにするテキストメッセージ、呼の希望時間、または他のユーザのカスタマイズ可能なテキストメッセージを含みうる。図１０は、ユーザが警告を送るときに行われる例示的なメッセージの流れを示す。
【００９２】
発信者は、１人以上の目標のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを選択し、警告を送ることを示しうる1002。クライアントは、要求に指定されている目標のユーザへ警告を送付する要求を、ＲＤへ送りうる1004。ＲＤは、要求を受信すると、要求に指定されている所定のグループを、目標のユーザのメンバーリストへ拡張し、目標のユーザの位置情報を検索しうる1006。ＲＤは、目標のユーザの少なくとも1人の位置を特定した後に、クライアントへ応答を送りうる1008。ＲＤは、警告要求をＭＣＵへ割り当てて1010、警告メッセージを目標のユーザへ同報通信しうる1012。
【００９３】
図１０に示されているように、警告要求はショートデータバースト（ＳＤＢ）によって送られうる。ＳＤＢメッセージによって警告を送ることにより、関係する当事者のパケットデータセッションを、休止状態のままにすることができる。警告通知は、目標のユーザが、例えば、警告通知を選択して、ＰＴＴを押すことによって、発信者および目標のユーザの残りとのグループ呼をセットアップできるようにするための必要な情報を含む。これが行われるとき、グループ呼のセットアップは、図４に関係して記載された呼セットアップのシナリオに類似して進められる。
【００９４】
遅れ加入
呼セットアップ要求に指定されているメンバーリストが、システムにおいて既に進行中の呼と関係付けられるメンバーリストと同じであると判断されるとき、グループ呼セットアップ要求は、遅れ加入であると見なされる。この状況は、次の２つの一方において現れうる。第１に、ユーザは、例えば、それと関係している呼を予め含んでいるメンバーリストと全く同じメンバーリストを、例えば、同一ユーザまたはグループ、あるいはこの両者を選択し、かつＰＴＴボタンを押すことによって、生成する。第２に、ユーザは、システムにおいて依然として実行されている呼を、呼履歴リストから選択し、ＰＴＴを押す。何れの場合においても、ＲＤは、ユーザが始めるように要求した呼が、既に進行中であることを検出し、ユーザを遅れ加入として取扱いうる。
【００９５】
図１１は、ユーザが呼履歴リストから呼を選択する例示的な遅れ加入の事例を示す。ユーザは、呼履歴リストから呼を選択し、ＰＴＴボタンを押す1102。クライアントは、グループ呼を開始する要求をＲＤへ送りうる1104。ＲＤは、呼が既に実行されていると判断し1106、ユーザが進行中の呼に加えられたという応答をクライアントへ送りうる1108。呼が既に実行されているときは、フロアは現在の呼の参加者によって既に保持されているので、遅れ加入のユーザがメディアを受信する用意が整うときまで、すなわち、パケットデータセッションが休止状態から抜け出るときまで、フロアはユーザに譲与されない。ＲＤは、呼をホストしているＭＣＵに、遅れ加入のユーザをグループへ加えるように要求する1110。ＭＣＵは、ユーザを加え、ＭＣＵ接触情報を含むアナウンスメントをユーザへ送る1112。遅れ加入ユーザのトラヒックチャネルが再設定された後で、呼内のメディアの流れが、ユーザへ伝送されうる。このとき、遅れ加入のユーザは、話す特権を要求することを試みることができる。
【００９６】
遅れ加入のシナリオは、図４に関係して記載された新しいグループ呼を開始するシナリオに類似している。異なるのは、遅れ加入のユーザが、最初のグループ呼セットアップ要求に対する応答において、フロアを拒絶されることである。
【００９７】
送話者の調停
１つの実施形態において、各グループ呼のユーザは、送話者プリエンプションランクを割り当てられる。これは、“フロア”を得る特権を要求して、話し始めるときに、ユーザが何れのレベルの権利をもつかを決定する。ＭＣＵは、グループ呼のセットアップ後に、フロア制御を担当し、フロアを要求する参加者が話すのを許可するかどうかを決定しうる。ＭＣＵは、２人以上の呼の参加者が、特定のグループのフロアの制御について競合しているときに、送話者の調停を行いうる。
【００９８】
図１２は、調停処理中に行われうる例示的なイベントを示している。このシナリオにおいて使用される調停方式では、ユーザＡがフロアを要求するとき、ユーザＢのプリエンプションを可能にする。ユーザＡが、ＰＴＴボタンを押すことによって話す許可を要求するとき1202、ユーザＢはフロアを制御している、すなわち、ユーザＢは話している。クライアントは、話すための許可を要求するメッセージをＭＣＵへ送りうる1204。ＭＣＵは、送話者の調停を行い1206、ユーザＢをプリエンプトし、ユーザＡへフロアを譲与すると決定しうる。メディアの流れの中断、すなわちユーザＢが話すのを止めた後で、ユーザＡのメディアが伝送されるのを保証するために、ＭＣＵは、最初に、フロアが別のユーザによってプリエンプトされたことを示すメッセージを、ユーザＢのクライア
アクティブなグループ呼へのユーザの追加
グループ通信システム100では、グループ呼の参加者は、進行中のグループ呼へ新しいユーザを加えることができる。これは、呼の参加者が、１人以上の目標のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを選択し、かつ参加者が、参加者が現在入っているグループ呼に、目標のユーザを加えたいことを示すことによって達成する。図１３は、新しい目標のユーザを、進行中のグループ呼に加えるときに行われるイベントを示している。呼の参加者は、呼に加えられる１人以上の目標のユーザ、１つ以上のグループ、またはこの２つの組合せを選択する1302。クライアントは、要求に指定したように、指定した目標のユーザを進行中のグループ呼に加えることを要求するメッセージをＲＤへ送りうる1304。ＲＤは、要求を受信すると、要求に指定されている所定のグループを、目標のユーザのメンバーリストへ拡張しうる。その後で、ＲＤは、目標のユーザの位置情報を検索しうる1306。ＲＤは、目標のユーザの少なくとも１人の位置を特定した後で、目標のユーザが呼に加えられることを示す応答をクライアントへ送りうる1308。ＲＤは、指定されたユーザを呼に加える要求をＭＣＵへ送りうる1310。ＭＣＵは、呼のアナウンスメントを新しい目標のユーザへ送り、これによりパケットデータセッションを休止状態から戻す処理が始まりうる1312。アナウンスメントは、目標のユーザがメッセージを受信することを保証するように、確実なスケジュールで送られうる。目標のユーザのトラヒックチャネルの再設定後に、目標のユーザは、ＭＣＵへ肯定応答を送りうる1314。追加の目標のユーザは、呼中に行われるメディアおよびシグナリングの通信に含まれうる1316。
【００９９】
アクティブなグループ呼からのメンバーの削除
グループ通信システム100では、グループ呼の参加者は、アクティブなグループからメンバーを削除することができる。１つの実施形態において、これは、呼の参加者が、１人以上の目標の参加者を選択し、グループ呼から削除すべきであることを示すことによって達成されうる。図１４は、参加者が進行中のグループ呼から削除されるときに行われうる例示的なイベントを示している。グループ呼の参加者は、呼から削除されることになる１人以上の目標の参加者を選択しうる1402。クライアントは、メッセージに指定されている目標の参加者を、グループ呼から削除することを要求するメッセージをＲＤへ送りうる1404。ＲＤは、要求を受信すると、目標の参加者の位置情報を検索し1406、目標の参加者が削除されることを示す応答をクライアントへ送りうる1408。ＲＤは、目標の参加者を呼から削除する要求をＭＣＵへ送りうる1410。ＭＣＵは、削除要求に指定されている目標の参加者へ、彼らが呼から削除されることを示すメッセージを送りうる1412。目標の参加者は、肯定応答をＭＣＵへ送りうる1414。
【０１００】
登録解除
ユーザが、アプリケーションサーバによって、またはユーザのＩＰアドレスを使用して、ユーザに接触する他のＩＰアプリケーションによって、接触されることを最早望まないとき、登録解除機能が実行される。登録解除機能は、ユーザのＩＰアドレスおよび他の接触情報をＲＬＳから削除し、ユーザのために割り当てられた資源を解放する。図１５は、１つの実施形態にしたがって、移動局がパワーダウンした結果、ユーザの登録をＲＬＳからどのようにして削除するかを示す。クライアントは、クライアントが位置している移動局がパワーダウンしたという指示を受信しうる1502。シャットダウン処理の一部として、クライアントは、ユーザの位置情報を削除すべきであることを示すメッセージをＲＬＳへ送りうる1504。ＲＬＳは、その要求を認証し、それが有効なソースからであることを確認しうる1506。ＲＬＳは、認証に成功すると、成功の指示をクライアントに通知し1508、ＲＤにユーザの削除に関して通知しうる1510。ＲＤは、ユーザのデータ記録をキャッシュから削除し、ユーザに割当てられた資源を解放しうる。登録解除に失敗したときは、ユーザの位置情報は、最終的に、期限切れの範囲と関係付けられた時間が経過したときに、ＲＬＳから削除されうる。
【０１０１】
１つの実施形態において、グループ通信システム100は、チャットルームモデルとアドホック・モデルの両者を支援する。チャットルームモデルでは、グループは予め定められ、ディスパッチサーバ上に記憶される。所定のグループは公開であり、したがって、グループが開かれたメンバーリストをもち、すなわち、ディスパッチユーザが潜在的な参加者であることが示唆される。チャットルームモデルでは、１人目がチャットルームに加入するのを選択するときに、呼は開始され、サーバ資源が、トークアクティビティに関係なく、サービスプロバイダによって構成された所定の時間の間、呼に割り当てられているならば、呼は継続する。ユーザは、これらのタイプの呼に加入したり、抜けたりすることを明確に要求する。別途記載するように、トークアクティビティのない期間の間は、各呼は、ユーザが話す許可を要求するまで、グループ休止状態に入る。
【０１０２】
アドホック・モデルでは、グループは実時間で定められ、グループと関係付けられた限定メンバーのリストを有しうる。限定メンバーリストは、何れのユーザがグループに参加するのを許可されるかを指定し、限定メンバーリスト以外のユーザには無効であり、呼の存続期間の間のみ存在しうる。アドホック・グループの定義は、どこにも記憶されず、したがって、この定義は、呼を設定するのに使用され、呼の終了後に解放されうる。
【０１０３】
アドホック・グループは、発信ユーザが１人以上の目標のユーザを選択し、かつ呼を開始するためにサーバへ送られる要求を生成するときに、形成されうる。目標のユーザは、彼らがグループに含まれたという通知を送られ、関係付けられた呼に自動的に加えられうる。すなわちユーザは動作を要求されない。アドホック呼がアクティブでなくなると、アプリケーションサーバは、呼を“切り”、呼を開始するのに使用されるグループの定義を含めて、それに割り当てられた資源を解放しうる。
【０１０４】
グループ通信システム100において、チャットルームモデルで動作するとき、通信装置のユーザのグループ（個々のユーザは、ネットメンバーとして知られている）は、各ネットメンバーに割当てられた通信装置を使用して、相互に通信する。“ネット”という用語は、相互に通信する権利を与えられた通信装置のユーザのグループを示す。
【０１０５】
１つの実施形態において、中央データベースは、各個々のネットのメンバーを識別する情報を含む。同一通信システムにおいて、１つより多いネットが動作しうる。例えば、第１のネットは、１０人のメンバーを有すると定義され、第２のネットは、２０人のメンバーを有すると定義されうる。第１のネットの１０人のメンバーは、相互に通信するが、第２のネットのメンバーとは通信しない。別の実施形態において、異なるネットのメンバーは、２つ以上のネットのメンバー間の通信を監視することはできるが、情報を伝送できるのは、自分のネット内のメンバーのみでありうる。
【０１０６】
ネットは、既存のインフラストラクチャに実質的な変更を要求することなく、既存の通信システム上で動作しうる。したがって、ネット上の制御装置およびユーザは、インターネットプロトコル（ＩＰ）を使用して、パケット情報を送受信することができるシステム、例えば、符号分割多重アクセス（Code Division Multiple Access, CDMA）システム、時分割多重アクセス（Time Division Multiple Access, TDMA）システム、移動通信用グローバルシステム（Global System for Mobile Communication）のシステム、Globalstar(商標)またはIridium（商標）のような衛星通信システム、または種々の他のシステムにおいて動作しうる。
【０１０７】
ネットメンバーは、割り当てられた通信装置（通信装置（communication device, CD）120、122として示されている）を使用して、相互に通信しうる。ＣＤ120および122は、ワイヤーラインまたはワイヤレスの通信装置であり、地上ワイヤレス電話、プッシュトーク機能をもつワイヤーライン電話、プッシュトーク機能を備えた衛星電話、ワイヤレスビデオカメラ、静止カメラ、ミュージックレコーダまたはプレーヤのようなオーディオ装置、ラップトップまたはデスクトップコンピュータ、ページング装置、またはその組み合わせである。例えば、ＣＤ120は、ビデオカメラおよびディスプレイを備えたワイヤレス地上電話を含みうる。さらに、各ＣＤは、セキュアモードまたはノンセキュア（クリア）モードの何れかで情報を送受信することができる。以下の記述全体で、個々のＣＤに対する参照は、プッシュトーク電話を示唆する。しかしながら、ＣＤに対する参照は、それに制限することを意図されておらず、インターネットプロトコル（ＩＰ）にしたがってパケット情報を送受信する能力をもつ他の通信装置を含みうる。
【０１０８】
グループ通信システム100では、一般に、１人のユーザは、伝送特権により、所与の時間に、残りのネットメンバーへ情報を伝送することができる。要求が受信されたときに、伝送特権が現在別のネットメンバーに割り当てられているかどうかに依存して、伝送特権は、要求しているネットメンバーへ譲与されるか、または拒絶される。伝送要求の承諾および拒絶の処理は、調停として知られている。調停方式では、要求しているネットメンバーが伝送特権を譲与されるかどうかを判断するときに、各ＣＤに割り当てられた優先度レベル、伝送特権を得る試行の失敗した数、ネットメンバーが伝送特権を保持する時間の長さ、または他の要素のような要素を評価しうる。
【０１０９】
システム100に参加するために、ＣＤ120および122の各々は、制御装置またはＭＣＵ116から伝送特権を要求する能力を有しうる。ＭＣＵ116は、グループの実時間の管理動作を処理しうる。ＭＣＵは、少なくとも１つのプロセッサおよびメモリをもつ任意のタイプのコンピュータ形装置である。ＭＣＵ116は、サービスプロバイダによって権利が与えられると仮定して、通信システムサービスプロバイダ、メンバー、またはこの両者の何れかを介して遠隔動作しうる。ＭＣＵ116は、外部の管理インターフェイスを介して、グループ定義を受信しうる。グループメンバーは、サービスプロバイダーによる管理を要求するか、またはＭＣＵ管理インターフェイスに適合しうる、メンバーが動作するセキュリティマネージャ（security manager, SM）のような規定のシステムによるネット機能を管理しうる。ＭＣＵ116は、ネットを設定または変更することを試みる当事者を認証しうる。
【０１１０】
ＳＭは、キーの処理、ユーザ認証、およびセキュアネットを支援するための関係するタスクを行いうる。１つのグループ通信システムは、１つ以上のＳＭと対話しうる。ＳＭは、ネットのアクティベーションまたはＰＴＴの調停を含む、ネットの実時間の制御に関与しなくてもよい。ＳＭは、ＭＣＵインターフェイスと互換性のある管理能力をもち、管理機能を自動化しててもよい。ＳＭはまた、ネットに参加するためのデータエンドポイントとして働くことができるか、ネットキーを同報通信するか、または単にネットトラヒックを監視しうる。
【０１１１】
１つの実施形態において、ＭＣＵから伝送特権を要求する手段は、プッシュトーク（ＰＴＴ）キーまたはスイッチを含む。システム100のユーザは、情報を他のメンバーへ伝送したいとき、ＣＤ上に配置されたプッシュトークスイッチを押して、フロア制御要求を送り、ＭＣＵ116から伝送特権を得る。他のネットメンバーが現在伝送特権を割り当てられていないときは、要求しているユーザは、伝送特権を譲与され、ＣＤを介して、聴覚、視覚、または触覚による警告によって通知されうる。要求しているユーザが伝送特権を譲与された後で、このユーザから他のメンバーへ情報が伝送されうる。
【０１１２】
本発明の１つの実施形態において、各無線ネットメンバーは、１つ以上の基地局126か、またはその代りに、場合によっては、衛星ゲートウエイと、順方向リンクおよび逆方向リンクを設定する。音声またはデータ、あるいはこの両者は、例えば、ＣＤを使用して、他のユーザと通信するための個々の分散形ネットワーク128に適したデータパケットへ変換されうる。１つの実施形態において、分散形ネットワーク128はインターネットである。
【０１１３】
１つの実施形態では、各通信システム、すなわち地上通信システムおよび衛星通信システムにおいて、各ネットメンバーから他のネットメンバーへ情報を同報通信するために、専用順方向チャネルが設定される。各ネットメンバーは、専用チャネルによって、他のネットメンバーから通信を受信する。別の実施形態では、各通信システムにおいて、情報をＭＣＵ116へ伝送するために、専用逆方向リンクが設定される。１つの実施形態では、上述の方式の組合せを使用しうる。例えば、１つの方式では、専用順方向同報通信チャネルを設定するが、無線ＣＤは、各ＣＤに割り当てられた専用逆方向リンクによってＭＣＵ116へ情報を伝送しなければならない。
【０１１４】
第１のネットメンバーは、ネットの他のメンバーへ情報を伝送したいとき、自分のＣＤ上のプッシュトークキーを押すことによって、伝送特権を要求し、分散形ネットワーク128上で伝送するためにフォーマットされた要求を生成しうる。ＣＤ120および122の場合に、要求は、１つ以上の基地局126へ空中で伝送されうる。移動交換局（mobile switching center, MSC）130は、データパケットを処理するために、周知のインターワーキング機能（inter-working function, IWF）、パケットデータ供給ノード（packet data serving node, PDSN）、またはパケット制御機能（packet control function, PCF）を含んでおり、ＢＳ126と分散形ネットワーク128との間に存在する。要求は、公衆交換電話ネットワーク（public switched telephone network, PSTN）を介して、モデムバンクへ伝送され、モデムバンクは要求を受信して、それを分散形ネットワーク128へ供給しうる。端末は、分散形ネットワーク128に接続することによって、システム100のトラヒックを監視しうる。
【０１１５】
他のメンバーが伝送特権を現在保持していないときは、ＭＣＵ116は、伝送特権要求を受信すると、要求しているネットメンバーにメッセージを伝送して、伝送特権が譲与されたことを通知する。第１のネットメンバーからの聴覚、視覚、または他の情報は、上述の伝送経路の1つを使用して、ＭＣＵ116へ情報を送ることによって、他のネットメンバーへ伝送される。１つの実施形態において、ＭＣＵ116は、情報を複製して、各複製を他のネットメンバーへ送ることによって、他のネットメンバーへ情報を供給する。１本の同報通信チャネルが使用されるときは、使用される各同報通信チャネルごとに、情報を１回だけ複製すればよい。
【０１１６】
代わりの実施形態では、ＭＣＵ116をＭＳＣ130内に組込んで、基地局を支援するために、データパケットを、分散形ネットワーク128上へルート設定することなく、ＭＣＵ116へ直接にルート設定する。この実施形態において、ＭＣＵ116は分散形ネットワーク128に接続されたままであるので、他の通信システムおよび装置は、グループ通信に参加することができる。さらに別の実施形態において、ＭＣＵ116は、ＭＳＣ130のＰＤＳＮまたはＰＣＦのモジュールへ組込まれうる。
【０１１７】
１つの実施形態において、ＭＣＵ116は、個々のネットメンバーおよび各所定のネットに関係する情報を管理するための１つ以上のデータベースを維持する。例えば、データベースは、各ネットメンバーごとに、ユーザ名、口座番号、メンバーのＣＤと関係付けられた電話番号、すなわちダイヤル番号、ＣＤに割り当てられた移動局識別番号、ネットにおける現在のメンバーの状態（例えば、メンバーがネットにアクティブに参加しているかどうか）、伝送特権の割当て方を判断するための優先コード、ＣＤと関係付けられたデータ電話番号、ＣＤと関係付けられたＩＰアドレス、およびメンバーが何れのネットと通信することを許可されたかについての指標のような情報を含みうる。他の関係するタイプの情報は、各ネットメンバーに関係して、データベースによって記憶されうる。
【０１１８】
１つの実施形態において、ＣＤは個々の通信端末と接続して、１つのトークグループ、すなわちネットを形成しうる。ＭＣＵは、異なるアプリケーションに対応するように異なる様式で構成可能な、ハードウエアおよびソフトウエアにおける種々の機能能力を含みうる。ＭＣＵは、ネットの実時間の管理および認証動作、プッシュトーク（ＰＴＴ）要求の調停、ネットメンバーシップおよび登録リストの保守および分配、必要な通信（例えば、ＣＤＭＡ）の呼のセットアップおよび切断、システムおよびネットワークの資源、並びにネット状態の全体的な制御を管理する能力を備えうる。
【０１１９】
ネットは、スタンドアローン形の配置可能なセルラシステムか、または大きい多数のサイトの構成内にありうる。大きい構成の場合は、多数のＭＣＵを地理的に配置して、１つの統合形システムを形成し、各ＭＣＵは、既存のセルラのインフラストラクチャへのプラグインモジュールとして動作しうる。したがって、ネットによって取り入れられる新しい特徴は、既存のセルラのインフラストラクチャを変更する必要なく、セルラユーザに使用可能である。
【０１２０】
ＭＣＵは、所定のネットのリストを維持しうる。１つの実施形態において、各ネットの定義は、ネット識別子、電話番号または他の識別情報を含むメンバーのリスト、ユーザ優先情報、および他の一般管理情報を含む。ネットは、静的にクリアまたはセキュアであると定義され、クリアとセキュアとの間の遷移は許されない。セキュアネットは、一般に、メディアの暗号化を使用して、認証を与え、盗聴から保護する。セキュアネットにおけるメディアの暗号化は、エンド ツー エンドで行われ、したがって、暗号化および復号は通信装置内で行われうる。ＭＣＵは、セキュリティアルゴリズム、キー、またはポリシーを知らなくても動作することができる。
【０１２１】
図１６は、通信装置（communication device, CD）1602、1604、および1606がＭＣＵ1608とどのように対話するかを示すための例示的なグループ1600を示している。多数のＭＣＵが、大きいグループに望ましいように配置される。図１６において、ＣＤ1602は、メディアを、グループの他のメンバーへ伝送することができる。この場合に、ＣＤ1602は、送話者として知られていて、チャネルによりメディアを伝送する。ＣＤ1602が送話者として指定されると、残りの参加者、すなわちＣＤ1604およびＣＤ1606は、メディアをグループへ伝送することができない。したがって、ＣＤ1604およびＣＤ1606は、受話者として指定される。
【０１２２】
上述のように、ＣＤ1602、1604、および1606は、少なくとも１本のチャネルを使用して、ＭＣＵ1608へ接続される。１つの実施形態において、チャネルは、セッション開始プロトコル（ＳＩＰ）チャネル1610、メディアシグナリングチャネル1612、およびメディアトラヒックチャネル1614を含む別々のチャネルへ分けられる。ＳＩＰチャネル1610およびメディアシグナリングチャネル1612は、バンド幅が許すときはいつでも、ＣＤ1602、1604、および1606によって、送話者として指定されるか、または受話者として指定されるかとは関係なく、使用されうる。ＳＩＰは、インターネット技術標準化委員会（Internet engineering task force, IETF）が定めたアプリケーション層プロトコルであり、インターネットプロトコル（ＩＰ）によって動作するマルチメディアセッションを設定し、変更し、終了するための制御機構を記載している。ＳＩＰは、ユーザを登録し、かつ位置を特定するための機構、ユーザの能力を定め、かつメディアのパラメータを記載するための機構、並びにユーザの可用性、呼のセットアップ、および呼の処理を判断するための機構を支援することによって、インターネット電話アプリケーションの呼−シグナリングの問題を概ね解決する。
【０１２３】
１つの実施形態では、ＳＩＰチャネル1610を使用して、グループ1600内におけるＣＤの参加を開始および終了する。また、ＳＩＰチャネル1610内では、セッション記述プロトコル（session description protocol, SDP）信号が使用されうる。例えば、ＳＩＰチャネル1610を使用することによって、グループ内のＣＤの参加がセットアップされると、例えば、ＮＢＳメディアシグナリングチャネル1612を使用することによって、ＣＤとＭＣＵとの実時間の制御およびシグナリングが行なわれる。１つの実施形態において、メディアシグナリングチャネル1612は、プッシュトークの要求および解放の処理、競合する要求、すなわちフロア制御の調停、情報伝送の開始および終了のアナウンス、ネットの休止状態の管理、エンドポイントの接続の追跡、ネット状態の要求および交換、並びにエラーメッセージの通知に使用される。メディアシグナリングチャネル1612のプロトコルは、最も一般的なメッセージの長さを最小化し、要求に対する返答および応答を解釈するタスクを簡潔化し、一方で将来の拡張のために融通性を維持する。さらに加えて、メディアシグナリングチャネル1612のプロトコルは、プロトコルの状態に悪影響を与えることなく、要求の再送を可能にする。
【０１２４】
１つの実施形態において、メディアシグナリングチャネル1612上のシグナリングトラヒックは、呼のセットアップおよび制御のシグナリング（セッション勧誘要求および肯定応答を含む）と、メディアのシグナリング（実時間のフロア制御要求および関係する非同期メッセージを含む）とを含む。メディアトラヒックチャネル1614上のメディアトラヒックは、実時間の、ポイント ツウ マルチポイントの、音声またはデータ、あるいはこの両者の同報通信を含む。両者のメッセージングカテゴリは、固有の機能属性をもつ。さらに加えて、各ＣＤは、ドメイン名サービス（ＤＳＮ）のクライアントの要求を発行し、完全修飾されたＤＳＮのホスト名をインターネットのネットワークアドレスへマップするのを促しうる。
【０１２５】
１つの実施形態において、呼セットアップおよび呼制御のシグナリングは、ＳＩＰの意味論にしたがって行われる。１つの実施形態において、ＳＩＰは、周知のユーザデータグラムプロトコル（user datagram protocol, UDP）または伝送制御プロトコル（transmission control protocol, TCP）の何れかを使用して移送されるが、各ＣＤは、ＵＤＰを使用して、ＳＩＰベースのシグナリング機能を行う。さらに加えて、各ＣＤは、ＵＤＰによって、ＳＩＰシグナリング要求を受信すると予測する。実時間のシグナリングは、ＣＭおよび各ＣＤにおいて、動的なＵＤＰ／ＩＰインターフェイスを介して行われうる。他のシグナリングは、例えば、ＳＩＰを使用して、ＣＭとＣＤとの間の固定のＴＣＰ／ＩＰインターフェイスを介して行われうる。
【０１２６】
ＰＴＴ待ち時間
１つの実施形態において、パケットデータサービスがアクティブであるときは、インフラストラクチャ（例えば、基地局トランシーバサブシステム（base station transceiver subsystem, BTS）、基地局制御装置（base station controller, BSC）、インターワーキング（ＩＷＦ）、および無線リンク）内の資源は、移動局（ＭＳ）へアクティブに割り当てられる。ＩＰベースのＶｏＩＰディスパッチサービスにおいて、グループの参加者間でアクティブな会話が行われているときは、各ユーザのパケットデータ接続はアクティブなままである。しかしながら、グループ通信では、アクティビティのない期間、すなわち“ハング時間”の後で、ユーザトラヒックチャネルは、休止状態へ遷移しうる。
【０１２７】
休止状態へ遷移することにより、システム容量を節約し、サービスコストおよびバッテリの消耗を低減し、ユーザが、到来する従来の音声呼を受信できるようにする。例えば、ユーザは、アクティブなパケットデータ呼に加わっているときは、通常は、到来する音声呼に対して“ビジー”であるとみなされる。ユーザのパケットデータ呼が休止状態であるときは、ユーザは、到来する音声呼を受信することができる。これらの理由のために、パケットデータのアクティビティのない期間の後で、パケットデータ呼を休止状態に遷移することが望ましい。
【０１２８】
パケットデータ呼がアクティブである間は、パケットデータが交換されていなくても、無線周波数（radio frequency, RF）エネルギーが、低レベルではあるが、移動電話によって引き続き伝送され、基地局との同期および電力制御が維持される。これらの伝送により、電話は相当に電力を消耗する。しかしながら、休止状態では、電話はＲＦの伝送を行わない。電話の電力を節約し、かつバッテリの寿命を延ばすために、長くデータが伝送されなかった後で、電話を休止モードへ遷移するように、ハングタイムを設定してもよい。
【０１２９】
全ユーザにおいてパケットデータサービスがアクティブであるときは、ＰＴＴ要求（ＭＳとディスパッチサーバとの間で送られるＩＰデータグラム）の待ち時間は非常に短い。しかしながら、ユーザチャネルが、休止状態に既に遷移されているときは、ＰＴＴ待ち時間は相当に長くなる。パケットデータの休止状態の間は、移動局のＩＰアドレスを含めて、パケットデータセッションと関係付けられた状態情報は維持されうる。しかしながら、ＰＰＰよりも低い層（例えば、物理トラヒック層）と関係付けられた状態情報は、解放、または割当て解除、あるいはこの両者を行われうる。
【０１３０】
いくつかのインフラストラクチャでは、休止状態からデータ接続を起こすために、トラヒックチャネルを再割り当てしなければならず、資源を再割り振りしなければならず、無線リンクプロトコル（radio link protocol, RLP）層を再初期化しなければならない。このために、トークグループがしばらく話しをしなかった後で、ユーザがＰＴＴボタンを押して、フロアを要求するとき、第１の送話者のスパートに対するＰＴＴ待ち時間は、一般に、次のトークのスパートよりも相当に長くなる。これは比較的に頻繁ではないが、サービスのユーティリティに影響を与えることがあり、最小化されるべきである。
【０１３１】
１つの実施形態では、ＰＴＴ待ち時間を低減するために、フロア制御要求、フロア制御応答、および休止状態からの起動メッセージのような、グループ呼のシグナリングは、専用トラヒックチャネルが再設定されるのを待つことなく、使用可能な共通チャネル上で伝送されうる。このような共通チャネルは、移動局の状態とは関係なく、常に使用可能であり、ユーザがグループ呼を開始することを望むたびに、要求および再割当てする必要はない。したがって、移動局が休止状態であっても、グループ呼のシグナリングは交換され、並行して、送話者および受話者の移動局への専用トラヒックチャネルを再設定するための手段が与えられうる。
【０１３２】
１つの実施形態において、発呼側移動局は、逆方向アクセスチャネルおよび逆方向拡張アクセスチャネルのような、いくつかの使用可能な逆方向共通チャネル上で、フロア制御要求を無線インフラストラクチャへ送りうる。発呼側移動局はまた、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な順方向共通チャネル上で、フロア制御要求に対する応答を受信しうる。１つの実施形態において、休止状態の受話者の移動局は、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な順方向共通チャネル上で、休止状態からの起動のメッセージを受信しうる。
【０１３３】
ショートデータバースト呼のシグナリングメッセージ
１つの実施形態において、送話者が認識する、休止状態からの起動の実合計時間およびＰＴＴ待ち時間は、ショートデータバースト（ＳＤＢ）メッセージを使用することによって、相当に低減されうる。これは、例えば、“TIA/EIA/IS-2000 Standard for cdma2000 Spread Spectrum System”（以下では、“cdma2000標準規格”と呼ばれる）に与えられている。１つの実施形態において、ＳＤＢメッセージは、専用物理チャネル（例えば、順方向基礎チャネル（forward fundamental channel, FCH）または順方向専用共通制御チャネル（forward dedicated common control channel, F-DCCH））、あるいは共通物理チャネル（例えば、逆方向アクセスチャネル（reverse access channel, R-ACH）、逆方向拡張アクセスチャネル（reverse enhanced access channel, R-EACH）、順方向共通制御チャネル（forward common control channel, F-CCCH）、またはページングチャネル（paging channel, PCH））上で送られる。ＳＤＢメッセージは、無線バーストプロトコル（radio burst protocol, RBP）によって移送され、適切な使用可能な物理層チャネル上へマップされうる。ＳＤＢメッセージは、任意のＩＰトラヒックを送り、共通物理チャネル上で送られうるので、発呼側クライアントの移動局が専用トラヒックチャネルをもたないとき、ＳＤＢメッセージは、グループ呼のシグナリングを交換するための機構を用意する。
【０１３４】
移動局が生成する呼シグナリングメッセージ
１つの実施形態において、メディアシグナリングメッセージは、逆方向リンクまたは移動局が生成するリンク上でＩＰデータグラムを送りうる。ユーザがフロアを要求し、かつ専用逆方向トラヒックチャネルが直ぐに使用可能でないときは必ず、クライアントの移動局は直ちにＭＣＵへ知らせうる。クライアントの移動局が全専用トラヒックチャネルを切断していると仮定すると、クライアントの移動局は、直ちに、無線インフラストラクチャの逆方向共通チャネル上でフロア制御要求を、ＭＣＵを中継して、送りうる。例えば、専用逆方向チャネルが使用可能でないときは、逆方向アクセスチャネルまたは逆方向拡張アクセスチャネルの何れかを使用して、このようなメッセージを送ってもよい。１つの実施形態において、クライアントの移動局は、フロア要求メッセージを、ＳＤＢメッセージとして、ＭＣＵへ伝送しうる。
【０１３５】
図４を参照すると、１つの実施形態において、クライアントＭＳは、専用トラヒックチャネルを再設定する前に、アクセスチャネルまたは拡張アクセスチャネルのような、逆方向共通チャネル上で、ＰＴＴフロア要求404を送りうる。１つの実施形態において、クライアントＭＳは、何れのチャネルが使用されているかに関係なく、ＳＤＢメッセージで、ＰＴＴフロア要求404を送りうる。
【０１３６】
例えば、クライアントＭＳは、例えば、“サービスオプション３３の再生成”を行うことによって、専用トラヒックチャネルの再設定を開始しうる。クライアントＭＳは、無線リンクプロトコル（ＲＬＰ）の同期化も開始しうる。１つの実施形態において、クライアントＭＳは、専用トラヒックチャネルを再設定し、かつＰＴＴフロア要求404を送ることと並行して、ＲＬＰを適切に同期させうる。
【０１３７】
したがって、移動局がアクティブな専用トラヒックチャネルをもたないとき、使用可能な逆方向共通チャネルおよび／またはＳＤＢの特徴を使用して、フロア制御要求をＣＭへ送ることにより、参加している移動局を起動するのに必要な全時間を低減する。送話者の順方向トラヒックチャネルが再設定されるまで、送話者のクライアントは、フロア要求が譲与されたという確認を受信しないが、参加している受話者を起動し始めることをＣＭへ迅速に知らせることができ、全体的な待ち時間が低減する。
【０１３８】
図４を参照すると、無線インフラストラクチャは、ＰＴＴフロア制御要求404をパケットデータ供給ノード（ＰＤＳＮ）を経由して、ＭＣＵへ送りうる。１つの実施形態において、ＭＣＵは、フロア制御要求を受信した後で、要求の調停、目標の参加者（受話者）へのメディアシグナリング起動メッセージ（トリガ）のバースト、および／または、参加者（受話者）のトラヒックチャネルの再設定のトリガを行いうる414。ＭＣＵは、ＰＴＴフロア要求を譲与すると、ＰＴＴフロア譲与408をクライアントＭＳへ送りうる。１つの実施形態において、クライアントの専用トラヒックチャネルが、まだ再設定されていないときは、順方向ページングチャネルおよび順方向共通チャネルのような、使用可能な順方向共通チャネル上で、ＰＴＴフロア譲与408をクライアントＭＳへ送りうる。１つの実施形態において、インフラストラクチャは、何れのチャネルが使用されるかに関係なく、ＰＴＴフロア譲与408をクライアントＭＳへ送りう
１つの実施形態において、ＭＣＵは、ＰＴＴフロア制御要求に応答する前に、休止状態応答タイマーが切れるのを待ちうる。グループ休止状態応答タイマーがゼロに設定されるときは、ＣＭは、フロア制御要求に直ちに応答しうる。１つの実施形態において、クライアントＭＳは、そのトラヒックチャネルの再設定およびＲＬＰの同期化を完了すると、（クライアントＭＳ内にバッファリングされている412）メディアをＭＣＵへ送りうる416。
【０１３９】
ネットワークが生成する呼シグナリングメッセージ
１つの実施形態において、ＭＣＵは、フロア制御要求を受信した後で、メディアシグナリング起動メッセージを目標の参加者（受話者）のグループへバーストし、参加者（受話者）のトラヒックチャネルの再設定をトリガしうる。グループ休止状態応答タイマーがゼロに設定されると、ＭＣＵは、フロア制御要求に直ちに応答しうる。１つの実施形態において、送話者が、ＰＴＴ要求を送って直ぐに、トラヒックチャネルを再設定し始めるとき、並行して発呼者と受話者とのトラヒックチャネルが適切に再設定されうる。
【０１４０】
図４を参照すると、ＭＣＵは、ＰＴＴフロア制御要求を受信した後で、目標の受話者へ起動トリガを送りうる414。ＭＣＵは、パケットデータセッションが、目標の移動局において存在し、かつトリガパケットを適切なインフラストラクチャ要素、例えば、基地局へ送るかどうかを判断しうる。インフラストラクチャは、各個々の目標のＭＳへページングして、その専用トラヒックチャネルを再設定し始めうる。その後で、例えば、目標のＭＳは、例えば、“サービスオプション３３の再生成”を行うことによって、その専用トラヒックチャネルを再設定し始めうる。目標のＭＳは、無線リンクプロトコル（ＲＬＰ）の同期化も開始しうる。１つの実施形態において、目標のＭＳは、その専用トラヒックチャネルを再設定し、クライアントＭＳが行うのと同じ機能を用いて、並行して、ＲＬＰを適切に同期させうる。
【０１４１】
１つの実施形態において、目標のＭＳは、その専用トラヒックチャネルの再設定およびそのＲＬＰの同期化を完了した後で、目標のＭＳがメディアを受信する準備ができたことを示す起動応答をＭＣＵへ送りうる422。ＭＣＵは、ＭＣＵにおいてバッファリングされている418メディアを目標のＭＳへ送る420前に、送話者のアナウンスメントをクライアントＭＳへ送りうる。
【０１４２】
１つの実施形態において、ＭＣＵは、目標の受話者のトラヒックチャネルがまだ再設定されていないとき、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な共通順方向チャネル上で、起動トリガを目標の受話者へ送りうる414。１つの実施形態において、ＭＣＵは、何れのチャネルが使用されているかに関係なく、起動トリガをＳＤＢの形で目標の受話者へ送りうる414。ＰＴＴフロア制御要求が、ＳＤＢメッセージとして、送話者の逆方向共通チャネル上で送られ、目標のグループの休止状態応答タイマが、ＭＣＵにおいてゼロに設定されるときは、送話者のクライアントにおける実際のＰＴＴ待ち時間は、逆方向リンク上でＳＤＢ要求メッセージを送り、その後で、順方向リンク上でＳＤＢ応答メッセージを送るのにかかる時間に低減されうる。
【０１４３】
呼シグナリングメッセージのためのネットワークインターフェイス
何れのネットワークが生成する特定のトラヒック、例えば、ＳＤＢペイロードが、専用トラヒックチャネルをもたないアイドル状態の移動局へ送られるかを判断するために、このような特定のトラヒックを他のトラヒックと区別するための、いくつかのインフラストラクチャのポリシーまたはインターフェイスが実行されうる。
【０１４４】
第１の実施形態において、ＳＤＢメッセージは、制限されたユーザペイロードを保持するので、ＩＰデータグラムは、そのサイズに基づいてフィルターにかけられうる。所定のサイズ制限よりも小さいＩＰデータグラムは、専用トラヒックチャネルをもたない移動局へ送られるとき、ＳＤＢメッセージとして送られる。アプリケーションフロア要求応答メッセージが非常に小さい、例えば、ＩＰヘッダを含めて、３４バイトであるときは、グループ通信システムは、このようなフィルターを使用しうる。
【０１４５】
第２の実施形態において、インフラストラクチャのベンダは、移動局へ送られるＩＰトラヒックをカプセル化するためのＩＰベースのサービスを定めうる。専用トラヒックチャネルをもたないと疑われる移動局へ送るためのこのサービスのために、このサービスを知っているＩＰサーバは、小さいＩＰ、例えば、ＵＤＰのデータグラムを、ＩＰヘッダと共に適切にカプセル化して送りうる。グループ通信システムは、このサービスを使用して、フロア要求応答メッセージを、例えば、ＳＤＢの形で、要求しているクライアントＭＳへ送ることを、インフラストラクチャに示す。ＳＤＢトラヒックと、保留中のページまたはサービス生成要求との調整も、ユーザトラヒックの迅速で確実な伝送を保証するのに重要である。
【０１４６】
第３の実施形態において、ＩＰサーバは、ＩＰヘッダをもつ特定のＩＰ、例えばＵＤＰのデータグラムを、専用トラヒックチャネルをもたないと疑われる移動局へ送りうる。ＩＰサーバは、例えば、ＩＰヘッダの特定の値を示すことによって、ＩＰデータグラムをクライアントＭＳへ送るようにインフラストラクチャに命令するためのタグを付けうる。グループ通信システムは、このサービスを使用して、例えば、フロア要求メッセージをＳＤＢの形で、要求しているクライアントＭＳへ伝送することを、インフラストラクチャに示す。第３の実施形態では、特定のＩＰデータグラム、例えば、ＳＤＢメッセージを伝送するために、ＵＤＰまたはＴＣＰのポート範囲を確保しうる。
【０１４７】
移動局が開始するサービス生成およびページング
１つの実施形態において、クライアントは、フロア制御要求404をＳＤＢの形で送り、その直ぐ後で、このトラヒックを迅速に再設定するために、サービス生成要求を、無線（例えば、ＣＤＭＡ）のインフラストラクチャへ送りうる。しかしながら、休止状態応答タイマーが小さい値に設定されるときは、ＲＤはフロア制御要求に迅速に応答し、応答408をクライアントへ伝送しうる。この応答が、サービス生成トランザクションの早い段階の間に、インフラストラクチャに到達するときは、インフラストラクチャは、送話者のＭＳがアクティブなトラヒックチャネルをもっていないことに気付いて、送話者のＭＳへの応答をページングすることを試みる。しかしながら、このページング動作は、既に進行中のサービス生成トランザクションを中止することがある。１つの実施形態において、送話者のＭＳはページに応答して、フロア制御応答メッセージが送話者へ伝送されることを確実にして、サービス生成を再び要求するが、最初のサービス生成の試みを中止した結果として、送話者のトラヒックチャネルを再設定するときに、不要な遅延を経験する。
【０１４８】
第１の実施形態において、サービス生成処理とページングとの競合状況を避けるために、ＲＤが、フロア制御要求404に直ちに応答しないように構成してもよい。したがって、サービス生成処理が完了した後で、ＭＣＵが応答408を送話者のＭＳへ送るように、休止状態応答タイマーを調節してもよい。
【０１４９】
第２の実施形態において、応答408を受信するＰＤＳＮと、送話者のサービス生成要求に応答する移動交換局（ＭＳＣ）とを調整する。すなわち、ＰＤＳＮが、応答408がインフラストラクチャに到達したときに、送話者のＭＳにおけるパケットデータサービス生成処理が既に進行していると判断すると、ＭＳＣは、送話者のＭＳのページングを遅らせる。ＰＤＳＮは応答をキャッシュし、サービス生成処理が完了すると、送話者の移動局の順方向トラヒックチャネル上でそれを送る。その代りに、ＭＳＣは、サービス生成処理がまだ進行中であるときに、応答をＳＤＢメッセージとして送話者のＭＳへ送ってもよい。
【０１５０】
第３の実施形態では、送話者のＭＳが、フロア制御要求に対する応答を受信するまで、サービス生成要求を発行しないことによって、送話者のＭＳは競合状態を避けうる。１つの実施形態において、送話者のＭＳは、アクティブな専用トラヒックチャネルをもたないので、ＭＣＵは、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な順方向共通チャネル上で、送話者のＭＳへ応答を送りうる。１つの実施形態では、ＭＣＵは、応答をＳＤＢの形で送話者のＭＳへ送りうる。ＭＣＵによって送られた起動要求が、受話者の移動局のトラヒックチャネルの再アクティベーションをトリガするのと同じやり方で、送話者のＭＳは、ＲＤが生成したフロア制御応答に依存して、トラヒックチャネルの再アクティベーションをトリガする。移動局が開始するサービス生成と、ネットワークが開始する移動局のページングが同期する潜在性を避けると、競合状態は避けられる。
【０１５１】
ネットワークが開始したパケットデータトリガのキャッシング
起動トリガ414を含むＩＰデータグラムであって、無線（例えば、ＣＤＭＡ）のインフラストラクチャに到達し、かつ専用トラヒックチャネルをもたない受話者の移動局へ送られるＩＰデータグラムは、一般にはネットワークによって、とくに無線インフラストラクチャによって損われる。１つの実施形態において、受話者の移動局へ送られる起動トリガ414は、受話者の応答またはグループの起動タイマーが切れるまで、所定のスケジュールにしたがって、しつこく再送される。例えば、起動トリガ414は、５００ミリ秒ごとに再送されうる。しかしながら、起動トリガ414をこのレートで再送すると、受話者のトラヒックチャネルが再設定されてから、その受話者へ送られる次の起動トリガがインフラストラクチャに到達するときまでに、最大で５００ミリ秒まで、または平均で２５０ミリ秒の遅延が生じうる。
【０１５２】
１つの実施形態において、ネットワーク内のインフラストラクチャまたは別のエンティティは、ＭＣＵによって送られた起動トリガ414をキャッシュして、目標のＭＳがそのトラヒックを設定すると直ぐに、目標のＭＳへそれを送りうる。したがって、ＭＣＵが起動要求を再送する必要がなくなり、休止状態から起動するための時間の合計が低減する。起動トリガ414をキャッシュすると、例えば、５００ミリ秒のレートでそれを再送することとは対照的に、休止状態から起動する時間の合計からの５００ミリ秒までの遅延がなくなりうる。
【０１５３】
メディアのバッファリング
１つの実施形態において、ユーザは、フロア制御要求後に、クライアントと受話者との専用チャネルが再設定される前に、メディアをバッファリングすることによって、話し始めるのを許可されうる。システムでは、送話者のスピーチをバッファリングすることによって、受話者のトラヒックチャネルが完全に再設定される前に、送話者が話し始めるのを許可する。したがって、送話者はより早く話し始めることができ、見掛けのＰＴＴ待ち時間が低減される。受話者はＰＴＴ待ち時間を経験しないので、この経験は影響されない。すなわち、ＰＴＴ待ち時間は送話者からシステムの他の部分へ移される。送話者は、ちょうど、自分の第１のトークスパートに対する応答を受話者から受信するまで待つが、既に記載したように、送話者は自分の第１のトークスパートに対する応答が、自分がアクティブな会話に加わっている間に始まる次のトークスパートに対する応答よりも長くかかることを既に予測している。送話者の第１のトークスパートのバッファリングは、ＭＣＵ側で行なうことも、クライアントＭＳ側で行なうこともできる。
【０１５４】
ＭＣＵ側のバッファリング
１つの実施形態において、ＭＣＵは、送話者の第１のトークスパートをバッファリングしうる。ユーザがＰＴＴボタンを押し、ユーザのトラヒックチャネルが再設定された後で、ユーザはＭＣＵと通信することができる。このとき、受話者のトラヒックチャネルはまだ準備ができていないので、ＭＣＵは、目標の受話者への将来の伝送のために、送話者のスピーチをバッファリングする418。ＭＣＵのバッファリングにより、送話者が判断する見掛けのＰＴＴ待ち時間は、送話者のトラヒックチャネルを生成するのにかかるおおよその時間に低減しうる。図１７は、１つの実施形態にしたがうＭＣＵ側のバッファリングを示しており、次に記載する：
（１）発信者と目標のトラヒックチャネルが休止状態であるとき、進行中の呼はない；
（２）ユーザは、ＰＴＴボタンを押す。サーバは、クライアントから、“グループ呼セットアップ”要求を受信する；
（３）クライアントがサーバから“セットアップ進行中”の応答を受信した後か、または構成可能な遅延（１秒）の後で、フロアはユーザへ譲与され、ユーザのメディアをバッファリングし始める；
（４）サーバは、目標のパケットデータトラヒックチャネルを再設定するための処理を開始する；
（５）サーバは、“グループ呼アナウンスメント”メッセージをＳＤＢによってクライアントへ送る；
（６）クライアントは、正常にトラヒックチャネルを再設定し、バッファリングされたメディアをサーバへ送り始める；
（７）クライアントは、メディアをサーバへ送る；
（８）目標のトラヒックチャネルは再設定される（“目標の応答閾値”が満たされる）；
（９）ユーザは、ＰＴＴボタンを放す。クライアントは、メディアをバッファリングすることを止める；
（１０）クライアントは、バッファリングされたメディアをサーバへ送ることを止め、サーバによるフロアの解放を要求する；
（１１）サーバは、フロア解放の肯定応答をクライアントへ送る。
【０１５５】
クライアント側のバッファリング
１つの実施形態において、見掛けの待ち時間がより短いことが望ましいとき、送話者は、自分のトラヒックチャネルが再設定される前でも、話し始めるのを許可される。クライアントＭＳは、ＭＣＵとまだ通信していないので、送話者が話し始めるための信号を生成する。送話者のトラヒックチャネルが再設定される前に、送話者が話すことを許可されるとき、クライアントＭＳはスピーチをバッファリングする412。ＣＭとの通信がまだ設定されていないので、話す許可は、“楽観的”に与えられる。図１８は、１つの実施形態にしたがうクライアント側のバッファリングを示しており、次に記載する：
（１）発信者のトラヒックチャネルが休止状態であるとき、進行中の呼はない；
（２）ユーザはＰＴＴボタンを押す。クライアントは、“グループ呼セットアップ”要求をＳＤＢによってサーバへ送る；
（３）クライアントは、パケットデータトラヒックチャネルを再設定する処理を開始する；
（４）クライアントが、サーバから、“セットアップ進行中”の応答を受信した後か、または構成可能な遅延（１秒）の後で、フロアはユーザへ譲与され、ユーザのメディアをバッファリングし始める；
（５）クライアントは、サーバから、“グループ呼アナウンスメント”メッセージをＳＤＢによって受信する；
（６）クライアントは、トラヒックチャネルを正常に再設定する；
（７）クライアントは、バッファリングされたメディアをサーバへ送る；
（８）ユーザは、ＰＴＴボタンを放す。クライアントは、メディアをバッファリングするのを止める；
（９）クライアントは、バッファリングされたメディアをサーバへ送ることを止め、サーバによるフロアの解放を要求する；
（１０）クライアントは、サーバから、フロアの解放の肯定応答を受信する。
【０１５６】
１つの実施形態において、ＭＣＵのバッファリング418とクライアント側のバッファリング412の両者は同時に行われうる。クライアント側のバッファリングは、見掛けのＰＴＴ待ち時間を短くすることができる。１つの実施形態において、クライアントＭＳは、メディアをバッファリングして、ユーザが経験する見掛けのＰＴＴ待ち時間を制御しうる。移動局が生成するＳＤＢとクライアント側のメディアのバッファリングとの組合せは、アクティブなトラヒックチャネルを再設定することに伴う遅延を低減する。
【０１５７】
したがって、開示されている実施形態では、少なくとも２つのタイプのディスパッチ呼を支援するディスパッチモデル、すなわちチャットルームモデルとアドホック・モデルを与える。チャットルームモデルでは、グループは予め定められ、ディスパッチサーバ上に記憶される。しかしながら、アドホック・モデルでは、グループは定義または変更、あるいはこの両者が実時間で行われる。
【０１５８】
開示されている実施形態は、さらに加えて、移動局が休止状態であり、かつトラヒックチャネルがアクティブでないときでも、グループ呼シグナリングを交換することによって、休止状態からの起動の実合計時間とＰＴＴ待ち時間とを相当に低減する。方法および装置は、ショートデータバースト（ＳＤＢ）メッセージのシグナリングを使用することによって、グループ呼シグナリングを交換する。方法および装置は、送話者の移動局と休止状態の受話者の移動局との専用トラヒックチャネルを効果的に並行して再設定する。
【０１５９】
別の実施形態では、ネットワークが開始した、目標の受話者への起動トリガをキャッシュし、かつ目標の移動局がトラヒックチャネルを再設定すると直ぐに、起動トリガを目標の移動局へ伝送することにより、グループ通信ネットワークにおける休止状態からの起動の待ち時間を低減する。
【０１６０】
別の実施形態では、グループ通信ネットワークにおいて、移動局が、サービス生成処理が完了した後で、フロア制御要求に対する応答を伝送することによって、サービス生成とページングの同時実行が避けられる。１つの実施形態では、サービス生成処理が完了しないときは、フロア制御要求に対する応答はＳＤＢの形であってもよい。１つの実施形態では、ソース通信装置へ応答を伝送した後で、ソース通信装置のサービス生成処理が開始される。
【技術分野】
【０００１】
本発明は、ポイント ツウ マルチポイント通信システムに関する。とくに、本発明は、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法および装置に関する。
【背景技術】
【０００２】
迅速で、効率的な、１対１または１対多数（グループ）の通信のための無線サービスのクラスは、種々の形態で何年も前から存在している。一般に、これらのサービスは、半二重式であり、ユーザは、電話装置／無線機上の“プッシュトーク（push-to-talk, PTT）”ボタンを押して、話し始める。いくつかのタイプのサーバを介して通信を行うとき、いくつかの構成、または適当なシステム内の無線機のボタンまたはキーを押すと、ユーザが“フロア”を要求していることが示される。ユーザは、フロア、すなわち送話者の許可を譲与されると、一般に数秒間話し、その後で、ＰＴＴボタンを放すと、他の話者がフロアを要求することができる。通信は、一般に、１対１ではなく、１人の話者から１グループの受話者へ行われる。このサービスは、１人の人、すなわち“ディスパッチャ”が、フィールドサービスの担当者またはタクシードライバーのような１グループの人々と通信する必要があるとき、アプリケーションにおいて以前から使用されてきた。なお、“ディスパッチャ”は、サービスを“ディスパッチする（発送する）”ための呼び名から由来している。
【０００３】
同様のサービスは、インターネット上で提供されており、一般に、“ボイスチャット”として知られている。これらのサービスは、一般に、ボイスオーバーＩＰ（voice-over-IP）サービスで、ボコーダフレームをインターネットプロトコル（Internet protocol, IP）パケットで中央グループチャットサーバへ送るか、または恐らくはピア ツウ ピア サービスで、クライアントからクライアントへ送るパーソナルコンピュータアプリケーションとして実行される。
【０００４】
これらのサービスにおける重要な特徴は、通信が、通常のダイヤリングおよびリンギングの順序を経ることなく、迅速で自動的に、普通は単にＰＴＴボタンを押すことによって開始されることである。このタイプのサービスの通信は、一般に非常に短く、個々のトーク“スパート”は、通常は数秒間程度であり、“会話”の継続は、恐らくは１分以下である。
【０００５】
ユーザがフロアを要求するときと、ユーザがフロアをもち、かつ話し始めることに対する肯定または否定の確認をサーバから受信するときとの間の時間遅延（ＰＴＴ待ち時間として知られている）は、半二重式グループ通信システムにおける重要なパラメータである。既に記載したように、ディスパッチシステムは、短い、すなわち短時間の会話を優先しており、したがってＰＴＴ待ち時間が長くなると、サービスの効果が低減する。
【０００６】
既存のグループ通信のインフラストラクチャは、ＰＴＴ待ち時間を相当に低減するための機会が制限されている。すなわち、実際のＰＴＴ待ち時間が、恐らくは、休止状態のパケットデータセッション内でトラヒックチャネルを再設定するのに必要な時間よりも短くならないという制限がある。さらに加えて、休止状態のグループを起動し始めるのに使用可能な唯一の機構は、送話者のトラヒックチャネルが再設定されるのを待って、サーバに信号を送るので、送話者と受話者とのトラヒックチャネルは直列に構成される。現在、移動局が生成したユーザシグナリングデータを、トラヒックチャネル以外で送るための機構は存在せず、したがってトラヒックチャネルが再設定された後で、クライアントとサーバとの通信が可能になるといった制約がある。
【０００７】
したがって、システム容量、クライアントのバッテリ寿命、または他の資源にマイナスの影響を与えることなく、送話者が経験する見掛けのＰＴＴ待ち時間と、参加している移動局のトラヒックチャネルを再設定するのに必要な全時間との両者を低減するための機構が必要とされている。
【０００８】
ディスパッチモデルにおいて、エンドポイント間の通信は仮想グループ内で行われ、１人の“送話者”の音声が、１人以上の“受話者”へ同報通信される。このタイプの通信の一例は、一般に、ディスパッチ呼、または単に呼と呼ばれる。呼はグループのインスタンシエーションであり、これは、呼の特性を定め、本質的には、グループ名またはグループ識別子のような、いくつかの関係付けられた情報をもつメンバーリストである。メンバーリストは、呼に参加するように勧誘された１人以上のユーザのリストである。
【０００９】
グループ呼サービスのチャットルームモデルとアドホック・モデルとの両者を支援するディスパッチモデルが必要とされている。チャットルームモデルでは、グループは予め定められ、ディスパッチサーバ上に記憶される。しかしながら、アドホック・モデルでは、グループは実時間で定められる、または変更される、あるいはこの両者である。
【発明の概要】
【００１０】
開示されている実施形態は、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための通信装置における新奇で向上した方法であって、ユーザからメンバーリストを受信することと、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとを含む方法を提供する。
【００１１】
本発明の別の態様において、通信装置におけるコンピュータ読み出し可能メディアは、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための方法であって、上述のステップを含む方法を具現する。
【００１２】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための通信装置であって、ユーザからメンバーリストを受信するための手段と、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送るための手段とを含む。
【００１３】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための通信装置は、受信機と、送信機と、受信機および送信機に通信上で接続されるプロセッサとを含む。プロセッサは、ユーザからメンバーリストを受信することと、アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとができる。１つの態様において、通信装置は、プッシュトーク（push-to-talk, PTT）装置である。
【００１４】
開示されている実施形態は、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバにおける新奇で向上した方法であって、アクティブなグループ呼からメンバーリストを加える要求を受信するステップと、アクティブなグループからメンバーリストを加えるステップとを含む方法も提供する。１つの態様において、方法は、メンバーリスト内の各メンバーに、彼らがグループ呼から加えられたことをアナウンスすることをさらに含む。
【００１５】
本発明の別の態様において、サーバ内のコンピュータ読み出し可能メディアは、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるための方法であって、上述のステップを含む方法を具現する。
【００１６】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバであって、アクティブなグループ呼にメンバーリストを加える要求を受信するための手段と、アクティブなグループ呼にメンバーリストを加えるための手段とを含む。１つの態様において、サーバは、メンバーリスト内の各メンバーに、彼らがグループ呼に加えられたことをアナウンスするための手段をさらに含む。
【００１７】
本発明の別の態様において、グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバは、受信機と、送信機と、受信機および送信機に通信上で接続されるプロセッサとを含む。プロセッサは、アクティブなグループ呼にメンバーリストを加える要求を受信することと、アクティブなグループ呼にメンバーリストを加えることとができる。１つの態様において、プロセッサは、さらに加えて、メンバーリスト内の各メンバーに、彼らがアクティブなグループ呼に加えられたことをアナウンスすることができる。
【図面の簡単な説明】
【００１８】
【図１】図１は、グループ通信システムを示す図である。
【図２】図２は、いくつかのアプリケーションが相互にどのように対話するかを示す図である。
【図３】図３は、１つの実施形態にしたがう、例示的なユーザ登録処理を示す図である。
【図４】図４は、１つの実施形態にしたがう、例示的な局所の領域内呼のセットアップ処理を示す図である。
【図５】図５は、１つの実施形態にしたがう、例示的な遠隔の領域内呼のセットアップ処理を示す図である。
【図６】図６は、１つの実施形態にしたがう、例示的な局所の領域間呼のセットアップ処理を示す図である。
【図７】図７は、１つの実施形態にしたがう、例示的な遠隔の領域間呼のセットアップ処理を示す図である。
【図８】図８は、１つの実施形態にしたがう、グループ呼から抜け出るための例示的な処理を示す図である。
【図９】図９は、１つの実施形態にしたがう、グループ呼を終了するための例示的な処理を示す図である。
【図１０】図１０は、１つの実施形態にしたがう、グループ呼へ警告を送るための例示的な処理を示す図である。
【図１１】図１１は、１つの実施形態にしたがう、グループ呼への遅れ加入のための例示的な処理を示す図である。
【図１２】図１２は、１つの実施形態にしたがう、送話者をプリエンプトするための例示的な処理を示す図である。
【図１３】図１３は、１つの実施形態にしたがう、新しいメンバーをアクティブなグループ呼に加えるための例示的な処理を示す図である。
【図１４】図１４は、１つの実施形態にしたがう、グループ呼から参加者を削除するための例示的な処理を示す図である。
【図１５】図１５は、１つの実施形態にしたがう、ユーザの登録を削除するための例示的な処理を示す図である。
【図１６】図１６は、１つの実施形態にしたがう、いくつかの通信装置が通信マネージャとどのように対話するかを示す図である。
【図１７】図１７は、１つの実施形態にしたがう、通信マネージャ側でメディアをバッファリングすることを示す図である。
【図１８】図１８は、１つの実施形態にしたがう、クライアント側でメディアをバッファリングすることを示す図である。
【詳細な説明】
【００１９】
本発明の１つの実施形態を詳しく記載する前に、本発明は、その応用において、以下の記述に記載されているか、または図面に示されている構成要素の構成および配置の詳細に制限されないことが分かるであろう。本発明は、種々のやり方で実行される他の実施形態において実現できることが分かるであろう。さらに加えて、ここに使用されている専門語および用語は説明のためであり、制限しているとみなされるべきではないことが分かるであろう。
【００２０】
図１は、グループ通信システム100の例示的な機能ブロック図を示している。グループ通信システム100は、プッシュトーク（push-to-talk, PTT）システム、ネット同報通信サービス（net broadcast service, NBS）、ディスパッチシステム、ポイント ツウ マルチポイント通信システムとしても知られている。１つの実施形態において、グループ通信システム100は、ディスパッチャ、位置サーバ、メディア制御装置（media control unit, MCU）複合体、使用ログサーバ、およびインターネットプロトコル（ＩＰ）クライアント（ＩＰと接続したワイヤレス装置またはワイヤーライン装置、あるいはこの両者）のような、アプリケーションサーバ構成要素を含む。アプリケーションサーバ構成要素は、構成要素の機能に基づいて、中央配置か、または領域内配置の何れかで配置されうる。中央配置は、ホームディスパッチャ（home dispatcher, HD）102、ホーム位置サーバ（home location server, HLS）104、およびユーザ／グループデータベース106を含む。これらの構成要素は、サービスプロバイダネットワーク内で集中して配置され、領域内配置によってアクセス可能でありうる。中央構成要素は、ローミング中のユーザの位置を特定し、かつ領域間のグループ呼を開始するのに使用されうる。領域内配置108、110は、領域内位置サーバ（regional location server, RLS）112、領域内ディスパッチャ（regional dispatcher, RD）114、領域内メディア制御装置（media control unit, MCU）複合体116、および領域内使用ログサーバ（usage log server, ULS）118を含みうる。
【００２１】
領域内配置では、サービスプロバイダネットワーク全体に分散され、インスタント応答要求を満足させるために、呼のセットアップに伴うネットワークの遅延を最小に維持することを保証しうる。いくつかの領域ごとに分けられたシステムの全体に呼のロードを分散させると、多数のユーザを支援できるように、適切なスケーラビリティ方式を展開できることも保証される。領域内アプリケーションサーバ構成要素は、ユーザ登録、領域内呼のセットアップおよび管理、並びに領域内に登録されたユーザへの警告の開始および伝達を行う。
【００２２】
グループ通信装置（クライアント）120、122は、例えばcdma2000のハンドセット上に配置されることができ、標準のデータサービスオプションを使用して、パケットデータセッションを要求し、このセッションを使用して、ＩＰアドレスをアプリケーションサーバに登録し、グループ呼を開始する。１つの実施形態において、アプリケーションサーバ構成要素108、110は、サービスプロバイダのパケットデータサービスノード（packet data service node, PDSN）へ接続される。クライアント120、122は、無線インフラストラクチャからパケットデータセッションを要求するときに、ＰＤＳＮを介して、アプリケーションサーバ構成要素108、110とＩＰ接続する。
【００２３】
クライアント120、122は、パワーアップ時に、データサービスオプションを使用して、パケットデータセッションを要求する。クライアントは、パケットデータセッションの設定の一部として、ＩＰアドレスを割り当てられる。このとき、クライアントは、ドメイン名サービス（domain name service, DNS）サーバ124のアドレスも受信する。クライアント120、122は、例えば、サービス記録（service record, SRV）のルックアップを使用することによって、ＤＮＳサーバ124に照会して、ＲＬＳ112のアドレスを検出する。クライアント120、122は、ＲＬＳ112の位置を特定した後で、登録を行って、その位置情報、例えば、ＩＰアドレスをアプリケーションサーバへ通知しうる。登録は、ユーザデータグラムプロトコル（user datagram protocol, UDP）上のセッション開始プロトコル（session initiation protocol, SIP）のような、ＩＰプロトコルを使用して行われうる。クライアント120、122のＩＰアドレスは、ユーザがグループ呼へ勧誘されたときに、クライアントと接触するのに使用される。
【００２４】
１つの実施形態において、クライアントは、登録が完了した後に、別のＤＮＳのＳＲＶの記録をルックアップして、領域内ディスパッチャ114のアドレスを検出しうる。クライアントは、ユーザが呼を開始することを要求するか、または警告を送るときは必ず、領域内ディスパチャーに接触する。領域内ディスパッチャ114とクライアント120、122との間のインターフェイスは、ＵＤＰ上のシグナリングプロトコルでありうる。
【００２５】
グループ呼が設定されると、クライアント120、122とＭＣＵ複合体116とは、メディアおよびシグナリングメッセージを交換する。１つの実施形態において、メディアは、呼の参加者とＭＣＵ複合体116との間で、ＵＤＰ上の実時間プロトコル（real-time protocol, RTP）を使用して送られうる。シグナリングメッセージも、ＵＤＰ上のシグナリングプロトコルである。これらのプロトコルと、それらが与える機能については別途記載する。
【００２６】
構成要素
グループ通信システム100は、ＩＰエンドポイントを含むことができ、ＩＰエンドポイントには、クライアントソフトウエア、領域内サーバ構成要素、および中央サーバ構成要素が含まれ、これらはグループ通信サービスを提供するのに必要である。グループ通信クライアントおよびアプリケーションサーバ構成要素は、次に続くセクションにより詳しく記載する。
【００２７】
クライアント
グループ通信クライアント120、122は、適切なボコーダにアクセスするＩＰエンドポイント上で実行される。ＩＰエンドポイントは、無線システム、例えばcdma2000、アプリケーション開発プラットフォーム、例えば、無線用二元実行時環境（binary runtime environment for wireless, BREW）、およびパーソナルコンピュータ上で実行されるアプリケーションを含みうる。
【００２８】
クライアントは、ＢＲＥＷを使用して展開されるソフトウエアアプリケーションを含むことができ、移動局モデムソフトウエア（mobile station modem software, MSM）にインターフェイスし、ＢＲＥＷ環境を含むクライアントへダウンロードされうる。開発者は、ＢＲＥＷプラットフォームを用いて、クライアント通信装置上で実行されるアプリケーションを生成することができる。アプリケーションの開発者は、ＢＲＥＷを分離層として、ＭＳＭソフトウエアおよび相手先ブランド製造者（original equipment manufacturer, OEM）ソフトウエアとに直接に接触することなく、アプリケーションを開発することができる。これにより、アプリケーションを迅速に開発し、ＭＳＭのソフトウエア、またはＯＥＭのソフトウエア、あるいはこの両者とは無関係に発展させることができる。さらに加えて、アプリケーションを、ＢＲＥＷ環境を含む任意の装置へダウンロードすることもできる。図２に示されているように、クライアントグループ通信アプリケーションソフトウエア202は、他のアプリケーション204、206、208、および210と並列に実行されうる。これらのサービスは、ＯＥＭ212およびＭＳＭ214のインターフェイスによって直接に提供されるが、ＢＲＥＷは、これらの層においてアプリケーションによって行われる変更から分離する。したがって、ＯＥＭ212およびＭＳＭ214は、データアプリケーション202、204、206、208、210から個々に発展することができる。
【００２９】
クライアントがパーソナルコンピュータ上で効果的に動作するために、パーソナルコンピュータは、互換性のあるボコーダへのアクセス、サウンドドライバーへのアクセス、およびアプリケーションサーバへのＩＰ接続を含みうる。
【００３０】
位置サーバ
１つの実施形態において、位置サーバ（location server, LS）は、ユーザの位置情報を受領および／または維持する。ユーザの位置情報は、例えば、ネットワークレベルのＩＰアドレス、経度および緯度のようなユーザの物理的な位置、および／またはパケットゾーン識別子、すなわち、順方向共通チャネル上で空中で同報通信され、パケットデータサービスをそのセクターへ供給するＰＤＳＮの範囲を識別するシステム識別子である。１つの実施形態において、ＬＳは、クライアントからの登録を処理し、ユーザ位置情報を、ＳＩＰインターフェイスを使用して、インスタントメッセージングのような他のアプリケーションへ供給する構成要素を含みうる。
【００３１】
ＬＳは、２つの機能素子、すなわち領域内位置サーバ（regional location server, RLS）112およびホーム位置サーバ（home location server, HLS）104を含みうる。ＲＬＳ112は、領域ごとに配置され、ＨＬＳ104は中央に位置する。これらの要素および機能の詳細は、別途記載する。
【００３２】
領域内位置サーバ
ＲＬＳ112は、その領域内に位置するクライアントからの登録を処理し、維持しうる。１つの実施形態において、ＲＬＳ112は、ユーザ位置情報のための付属メモリを備えた標準のＳＩＰベースのＬＳである。ＲＬＳ112は、登録エントリの維持の一部として、各登録の有効期限日、すなわち“有効期限”範囲を検査する。ＲＬＳは、有効期限の切れたエントリを削除し、領域内ディスパッチャ（regional dispatcher, RD）およびＨＬＳに、削除したエントリを知らせることを保証する。
【００３３】
前述のように、クライアントは、アプリケーションサーバへその位置を通知するために、ＩＰ登録を行なうことができる。クライアントは、グループ通信サービスが使用可能な期間の間、その登録を維持しうる。クライアントは、クライアントのＩＰアドレスが変わるとき、および登録の期限が切れようとしているときに、再登録を行いうる。
【００３４】
クライアントが登録または再登録するとき、ＲＬＳ112は、関係付けられたＲＤ114に通知しうる。したがって、ＲＤ114は、呼セットアップ要求を準備するとき、ユーザデータをプレロードして、呼セットアップ時間を低減することができる。ＲＤ114は、ユーザの位置情報をキャッシュし、呼セットアップ中にＲＬＳと接触して、ユーザの位置情報を検索する必要をなくしうる。
【００３５】
ＲＬＳ112は、ユーザの位置情報を更新するか、またはＲＬＳ112から削除するときに、ＲＤ114へ通知しうる。したがって、ＲＬＳ112よびＲＤ114は、領域内に登録されたユーザについての最新情報で同期を維持することが保証される。
【００３６】
ＲＬＳ112はまた、ＨＬＳ104を、登録されたユーザの位置情報で定期的に更新しうる。ＲＬＳ112が、別の領域内に有効な登録を既にもっているユーザの登録をＨＬＳ104へ提出するとき、ＨＬＳは競合を解消しうる。
【００３７】
ホーム位置サーバ
ＨＬＳ104は、ユーザの位置情報についての照会を処理しうる。１つの実施形態において、ＨＬＳ104は、ＳＩＰベースのインターフェイスを用意して、インスタントメッセージングアプリケーションのような他のアプリケーションが、個々のユーザの位置情報を照会できるようにする。
【００３８】
ＨＬＳ104が中央構成要素であり、ＲＬＳがそれと通信するとき、ＨＬＳは、ローミング中のユーザが異なる領域において行った多数の登録を分析する。ＨＬＳ104は、ＲＬＳの各々から登録情報を受信しうる。ＨＬＳ104が同一ユーザの多数の登録を受信するとき、ＨＬＳ104は最近の登録を維持して、そのユーザの古い登録をＲＬＳから削除することを要求する。これは、また、古い登録を収めているＲＬＳと関係付けられたＲＤ114から、そのユーザについてのキャッシュされた情報の除去をトリガしうる。
【００３９】
ディスパッチャ
ディスパッチャは、ユーザの位置を特定して、かつグループ呼をメディア制御装置（media control unit, MCU）複合体116へ割り当てることによって、呼のセットアップを促しうる。ディスパッチャは、“インスタントアクセス”要求を満たすための鍵であるサーバ構成要素である。ディスパッチャは、最低呼セットアップ時間を保証するために、同様の構造および機能をもつが、配置方式が異なる２つの機能要素を含みうる。これらの２つの要素、すなわち領域内ディスパッチャ（regional dispatcher, RD）114およびホームディスパッチャ（home dispatcher, HD）102は、次に続くセクションにおいて詳しく記載する。
【００４０】
領域内ディスパッチャ
ＲＤ114は、呼セットアップ要求および警告要求のための最初の接触点でありうる。ＲＤ114は、ＲＬＳ112からユーザが登録したという指示を受信するとき、ユーザ情報をプレロードしうる。ＲＤ114は、ユーザ情報と一緒に、システム内で実行されているグループ呼に関する情報をキャッシュしうる。ＲＤ114は、呼セットアップ中にユーザおよびグループについてのキャッシュされた情報を使用して、すなわち、データベースをルックアップする必要をなくして、セットアップ時間を最低に維持しうる。
【００４１】
１つの実施形態において、ＲＤがキャッシュに記憶しているグループ情報は、グループメンバーリストと、グループが載っているＭＣＵ複合体116のアドレスとを含む。ＲＤ114は、メンバーリストおよびＭＣＵのアドレスを、呼の存続期間の間、維持しうる。これは、ＲＤ114が、到来呼が、システムにおいて既に実行されている関係付けられた呼を含むグループと同じグループである必要があるかどうかを迅速に判断するのを助け、これにより、ＲＤは、呼セットアップ要求に迅速に応答し、かつ応答において“フロア”要求を確信をもって承諾または拒絶することができる。
【００４２】
ＲＤ114は、フロア制御要求を承諾または拒絶しうる。ＲＤ114は、ユーザを“遅れ加入”の参加者として呼に加えるか、または関係付けられたメンバーリストを用いて新しい呼を開始するように、ＭＣＵ複合体116に要求するかどうかを決定しうる。
【００４３】
ＲＤ114は、呼セットアップ要求の処理の間に、キャッシュされたユーザ情報を使用して、呼セットアップ要求において指定されたユーザの位置情報を検索しうる。ユーザの位置を特定できないときは、ＲＤ114は、ユーザの位置を特定するようにＨＤ102に要求しうる。１つの実施形態において、少なくとも１人以上の目標のユーザの位置が特定されるときは、ＲＤ114は呼のセットアップを継続する。ＲＤ114は、目標のユーザの位置が特定された後で、呼を何れのＭＣＵに割り当てるかを決定しうる。この判断は、発信者を含む、グループ内のユーザのＩＰアドレスに基づいてもよい。
【００４４】
ＲＤ114は、呼要求と同様に、警告要求を処理しうる。１つの実施形態において、警告要求は、目標のユーザの位置に関係なく、処理のために局所ＭＣＵ複合体116に割り当てられる。
【００４５】
１つの実施形態において、ＲＤのキャッシュ内の情報は、信頼できるメモリ機構へ定期的に書込まれ、したがって、故障の際は、回復されうる。ＲＤの故障が回復されると、信頼できるメモリ機構へ書込まれたユーザおよびグループの情報は、キャッシュへ再びロードされ、ＲＤは、到来呼のセットアップ要求の処理と関係して、キャッシュされた情報を確認することを始める。
【００４６】
１つの実施形態において、ＲＤ114は、ＲＬＳ112から各ユーザの登録を通知されると、ユーザデータを局所キャッシュへロードする。呼をセットアップするときに、いくつかのデータベースをルックアップする必要を無くすことによって、ＲＤ114は、呼セットアップ要求または警告要求を確認して応答するのにかかる時間を相当に低減する。
【００４７】
ＲＤ114は、呼セットアップ中にユーザ／グループデータベース106にアクセスして、要求の中にあるときは、所定のグループアドレスを個々のユーザのリストへ拡張し、必要であれば、ユーザまたはグループの代わりの識別子（例えば電話番号、会議ＩＤ）を、標準アドレスへ変換しうる。
【００４８】
ホームディスパッチャ
ホームディスパッチャ（home dispatcher, HD）102は、登録されたユーザの位置情報を追跡しうる。ＨＤは、ＲＬＳ112に登録されたユーザの位置情報を含みうる。
【００４９】
前述のように、各ＲＬＳ112は、ユーザ登録、再登録、登録解除、または登録の有効期限切れのたびに、関係付けられたＲＤ114へ通知しうる。ＲＤ114は、この情報を使用して、局所キャッシュ内のユーザ情報をロードまたは解放する。各ＲＤ114は、ユーザ位置情報についてＨＤ102を更新しうる。ＨＤ102はＲＤ114から更新を受信するので、ＨＤ102は、異なる領域に地理的にまたがって分散しているユーザを検出するのを助けうる。ＲＤ114は、領域内に現在登録されていないユーザ、すなわちＲＤのキャッシュ内にそのユーザ情報がないユーザの要求を受信するとき、ＨＤ102からの支援を要求しうる。
【００５０】
ＤＮＳサーバ
１つの実施形態において、グループ通信システム100は、サービスプロバイダのＤＮＳサーバ124を使用して、ＲＬＳ112およびＲＤ114の位置情報を、クライアントへ供給しうる。この情報は、各領域内配置ごとに構成され、その精度を保証するために、定期的に更新されうる。
【００５１】
１つの実施形態において、各クライアントは、パケットデータセッションを要求するとき、ポイント ツウ ポイント プロトコル（ＰＰＰ）セッションの設定中に、インターネットプロトコル制御プロトコル（Internet protocol control protocol, IPCP）のネゴシエーションによって、ＤＮＳサーバのアドレスを知る。ＤＮＳサーバ124は、このやり方で領域ごとに公示されうる。したがって、クライアントは領域から領域へロームして、クライアントが位置しているのと同じ領域内のＤＮＳサーバ124と通信することができる。ＤＮＳサーバ124は、領域ごとに、各ＰＤＳＮと共に配置される。１つの実施形態において、ＤＮＳサーバ124は、ＤＮＳサーバ124が関係付けられているＰＤＳＮにサービスしている各ＲＤ114およびＲＬＳを用いて更新されうる。
【００５２】
１つの実施形態において、適切なＲＤ114およびＲＬＳ112の位置を特定するのに使用される機構は、ＤＮＳおよびＳＩＰのアドレス指定の組合せに基づいている。ＤＮＳのサービス（service, SRV）記録のルックアップは、クライアントが登録しているＳＩＰのＵＲＩの“＜ドメイン＞”部分に基づいて行われうる。ＳＲＶ記録要求は、要求者が検出しようとしているプロトコルまたはサービスを含みうる。例えば、ＲＬＳ112の位置を特定しようとする場合に、クライアントは、ＤＮＳのＳＲＶの記録のルックアップにおいて“登録サービス”を要求する。ＤＮＳ応答は、１つ以上の有効なネットワークおよび要求されたサービスを提供するサーバのポートアドレスを含みうる。ＤＮＳサーバ124を使用して、クライアントの要求への返答を戻すときに、ＤＳＮサーバ124を多数のサーバ間でラウンドロビンさせることによって、同じサービスを提供するサーバ間でロードの平衡をとりうる。
【００５３】
ユーザ／グループデータベース
１つの実施形態において、ユーザ／グループデータベース106は、ユーザおよびグループ情報のための中央リポジトリである。各ユーザについて、データベースは、ユーザアドレス、プリエンプションランク、認証情報、ユーザ接触情報、およびユーザが監視されているかどうかを示す合法の傍受フラグのような情報を含みうる。データベースは、ディスパッチサービスのチャットルームモデルのための所定のグループの定義、すなわちユーザおよび関係付けられたグループ名のリストも含みうる。各グループは、例えば、グループデータベースによって固有に識別されうる。クライアントは、グループアドレスを使用して、グループ呼設定要求のグループを識別しうる。ＲＤ114は、ユーザ／グループデータベース106内の所定のグループとのグループ呼セットアップ要求を受信すると、グループアドレスを使用して、そこから、関係付けられたメンバーリストを検索しうる。
【００５４】
メディア制御装置複合体
メディア制御装置（media control unit, MCU）の複合体は、メディア制御ホスト（media control host, MCH）とメディア制御装置（media control unit, MCU）とを含みうる。ＭＣＨは、多数のＭＣＵの処理をホストし、管理しうる。各ＭＣＵは、１つの呼ごとに、実時間のシグナリングおよびメディア処理を取扱いうる。ＭＣＵが行なう機能は下記機能を含みうる：
・ＲＤ114からの呼の割当てを処理する機能；
・ローディングおよび状態情報をＭＣＨへ送る機能；
・呼開始情報をクライアントへ送る機能；
・ＰＴＴ要求のような、クライアントからのインコールシグナリングを処理する機能；
・シグナリングメッセージが、クライアントへ確実に伝送されるのを保証する機能；
・“１対多数”の呼において、メディアを複製して、分配する機能；
・“ミックス”ボコーダの“１対多数”の呼において、適切なトランスコーダを使用してメディアを変換する機能；
・呼のアクティビティを監視して、メディアの流れのアクティビティがないことに基づいて、呼の終了を開始する機能；
・使用ログサーバ（usage log server, ULS）118のために使用情報を生成する機能；
・要求されたときに、メディアおよびシグナリング情報を、適切な合法の傍受点へ送る機能。
【００５５】
ＭＣＵは、ＲＤ114からの警告要求を処理し、警告通知をクライアントへ送り、クライアントからの肯定応答を待ちうる。ＭＣＵは、目標のユーザから肯定応答を受信すると、警告トランザクションに割り当てられた資源を解放する。このとき、ＭＣＵは、他の呼割当てまたは警告要求を処理してもよい。
【００５６】
使用ログサーバ
ＵＬＳ118は、各領域内に存在し、ＭＣＵ複合体116と一緒に配置されうる。ＵＬＳ118は、各呼または警告処理ごとにＭＣＵ複合体116から使用イベントを収集し、それらを使用データ記録（usage data record, UDR）へフォーマットし、これらのＵＤＲを、一連のＵＤＲファイルに記憶しうる。呼のＵＤＲは、参加者と参加者使用合計のリストを含めて、個々の呼に関する情報を含みうる。警告のＵＤＲは、警告の発信者、および警告が送られた目標のユーザを示す情報を含む。ＵＤＲファイルは、サービスプロバイダーによって課金解析のために収集され、一定の時間の後で削除されうる。
【００５７】
ＵＬＳ118は、各呼の最後に、呼のインスタンスごとに、１つのＵＤＲを書込む。ＵＬＳ118は、警告要求が処理されるたびに、単一のＵＤＲを書込む。ＵＬＳ118によって書込まれるＵＤＲは、次の情報を含みうる：
・呼インスタンス識別子または警告インスタンス識別子；
・ＭＣＵ識別子。これは、呼の位置を示唆する。呼を開始するとき、適切なＭＣＵが、全予定参加者の登録された位置に基づいて選択される。ＭＣＵの位置は、発信者と同じ領域内にあっても、そうでなくてもよい；
・呼または警告の開始時間；
・呼または警告の終了時間；
・発信元ユーザの名前および／または識別子；
・発信元ユーザのＩＰアドレス；
・各参加者ごとの、ユーザ名、ユーザアドレス、ユーザＩＰアドレス、累積参加時間（警告はゼロであってもよい）、および参加者がフロアを保持した合計時間（秒）（警告はゼロであってもよい）。
【００５８】
１つの実施形態では、各呼ごとに、１つのＵＤＲが発行される。ＵＤＲは、呼中のトークセグメントの全収集を表わす。各トークセグメントごとに、ＵＤＲへのイベントのロギングが要求されるとき、これは、ロード要件、ファイルのＩ／Ｏ要件、およびディスク空間要件をさらに処理するという犠牲を払って実行されうる。
【００５９】
グループ通信システム100は、グループサービスを行うために、幾つかの異なる機能を実行する。ユーザの経験に関係する機能は、登録、呼の開始、呼の終了、警告の送付、遅れ加入、送話者の調停、ユーザの追加、メンバーの除去、登録解除、アドレス指定、および認証を含む。システムの準備および動作に関係する機能は、管理および準備、スケーラビリティ、および信頼性を含む。これらの機能は、次に続くセクションに詳しく記載する。
【００６０】
登録
無線通信システム、例えば、ＣＤＭＡシステムにおいて、登録とは、移動局の位置を、無線通信システムのインフラストラクチャに分かる位置にする処理である。この位置情報は、移動局が位置する地理的領域、および移動局にサービスしている基地局の識別子を含み、ページングおよびアクセスチャネルの効率的な使用を助けるのに使用されうる。
【００６１】
１つの実施形態において、ユーザ位置情報は、クライアントがワイヤレスサービスを介して接続されるか、またはワイヤーラインサービスを介して接続されるかとに関係なく、クライアントのＩＰアドレスである。ＩＰアプリケーションがＩＰアドレスに基づいてクライアントの位置を特定できるようにする例示的なＩＰプロトコルは、セッション開始プロトコル（ＳＩＰ）である。とりわけ、ＳＩＰは、クライアントが、ＩＰアドレスおよび他の位置情報をＳＩＰサーバ構成要素に登録するための方法を与える。さらに加えて、ＳＩＰは、クライアントを“検出する”ことに関係しているＩＰアプリケーションが、クライアントのＩＰアドレスのような位置情報について、同じＳＩＰサーバ構成要素に照会する方法を与える。
【００６２】
登録は、ＩＰクライアントがＳＩＰサーバ構成要素と通信して、その位置情報、例えば、ＩＰアドレスを通知して、維持する処理を含みうる。この機能を備えたＳＩＰサーバ構成要素は、位置サーバである。クライアントが位置サーバにその位置を通知するか、またはその位置を変更する方法は、ＳＩＰ登録（SIP REGISTER）方法である。
【００６３】
１つの実施形態において、クライアントは、その位置情報を、領域内位置サーバへ登録する。インスタントメッセージングのような、他のＩＰベースのアプリケーションは、位置サーバで得られる各クライアントのＩＰアドレスの情報を得ることを利用する。外部のサービスまたはクライアントが、登録を行ってもよい。図３は、登録機能を行うための例示的な呼の流れを示す。
【００６４】
パワーアップ時に302、クライアントはパケットデータセッションを要求して、そのＩＰアドレスをＲＬＳ112に登録する処理を開始する。クライアントは、登録を行うために、ＤＮＳのＳＲＶの記録をルックアップし304、ＲＬＳのアドレスを判断しうる。クライアントは、ＲＬＳアドレスを検索すると306、その位置情報を、例えば、ＳＩＰ登録メッセージを使用することによって登録しうる308。ＲＬＳはユーザを認証し310、応答をクライアントへ発行する312。ＲＬＳは、ユーザが登録されていることを領域内ディスパッチャへ通知し314、領域内ディスパッチャは、この情報を使用して、ユーザに関係するデータ記録をプレロードして、呼のセットアップ中により迅速な応答を促しうる。この時点で、クライアントは、グループ呼に参加する勧誘のために接触されうる。１つの実施形態において、クライアントは、実行するデータ接続の形式、すなわちワイヤレスか、またはワイヤーラインかとは無関係に、グループ呼を受信するために、登録を行う必要がありうる。
【００６５】
登録は、それと関係付けられた“有効期限切れ”の範囲を有しうる。“有効期限切れ”の範囲は、クライアントの登録情報が有効であると考えられる期間を示す。ＩＰによってクライアントに常に到達可能であることを保証するために、クライアントは、登録の有効期限切れを意識して、有効期限が切れる前に再登録を行いうる。登録は、クライアントのＩＰアドレスが変更されたとき、またはクライアントと位置サーバとのデータ接続が切断されたときのような、他の環境のために、無効または失効になることもある。クライアントは、データ接続の状態と、ＩＰアドレスが変更されたかどうかとを意識しうる。
【００６６】
最初の登録が完了すると、クライアントは、そのパケットデータセッションを休止状態にし、専用トラヒックチャネルを解放しうる。クライアントは、そのパケットデータセッションを監視して、休止状態の延長期間中は、有効のままであることを保証しうる。セッションの有効性に影響を与えうる状況は、異なるパケットゾーンＩＤをもつ区域へ移動すること、フェードまたはサービスの損失を経験すること、および／またはＰＴＳＮの呼を行うことを含む。クライアントのＩＰアドレスは変わり、クライアントは、インフラストラクチャとのデータ接続を再設定することを要求されうる。クライアントは、そのパケットデータセッションを再設定すると、新しいＩＰアドレスを受信する。クライアントの位置情報が正確であり続けることを保証するために、新しいＩＰアドレスを位置サーバへ伝えなければならない。これは、再登録を行うことによって達成されうる。
【００６７】
ファイアウォールを通って位置サーバと通信するワイヤーラインのクライアントは、位置サーバを定期的に“ピング”することによって、ファイアウォールを通る穴を維持する必要がある。これは、再登録を行うことによって達成される。
【００６８】
グループ呼開始
ユーザは、登録完了後に、呼を発信または受信しうる。クライアントは、パワーアップ後に、最初の呼を開始する前に、ＤＮＳのＳＲＶの記録をルックアップし、領域内ディスパッチャの位置を検出しうる。これは、立ち上げ処理の一部として行われうる。
【００６９】
“グループ”は、発信者、グループのセットアップを開始したユーザ、１人以上の目標のユーザを含むメンバーリストと関係付けられる。メンバーリストは、１人以上のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを含む。メンバーリストが１人のユーザのみを含むとき、そのメンバーリストを使用して開始される呼は、一般に、プライベートコールと呼ばれる。メンバーリストが所定のグループを含むときは、領域内ディスパッチャは、例えば、元のメンバーリスト内の所定のグループの識別子を、所定のグループの関係付けられたメンバーリストと置換することによって、所定のグループを、１人以上の目標のユーザのリストへ拡張する。所定のグループの拡張後に、生成されたメンバーリストは、目標のユーザ名を含む。この時点で、領域内ディスパッチャは、領域内ディスパッチャのキャッシュをユーザ情報について走査することによって、メンバーリスト内の目標のユーザの位置を特定することを試みる。目標のユーザが、領域内ディスパッチャのキャッシュ内に位置するときは、グループのメンバーは、領域内ディスパッチャと同じ領域内に登録される。このタイプのグループ呼は、“領域内”呼と分類される。領域内ディスパッチャが位置を特定できないユーザがいるときは、領域内ディスパッチャは、ホームディスパッチャからの支援を要求して、ユーザの位置を特定する。２つ以上の領域からのメンバーを含むグループと関係付けられている呼は、“領域間”呼と呼ばれる。
【００７０】
領域内ディスパッチャは、呼が領域内であるか、または領域間であるかを判断した後で、何れのメディア制御装置（ＭＣＵ）が呼をホストするかを判断する処理を開始しうる。領域内呼において、領域内ディスパッチャは、領域内ディスパッチャと同じ領域内に位置するＭＣＵへ、その領域内においてＭＣＵの資源が使用可能であるときは、呼を割り当てうる。このタイプの呼のセットアップを使用して生成される呼は、“局所的にホストされた”呼、または局所呼と呼ばれる。領域間呼では、領域内ディスパッチャは、同じ領域内のＭＣＵか、あるいは遠隔または外部の領域のＭＣＵへ呼を割り当てる選択肢をもつ。領域内ディスパッチャは、ユーザの位置情報に基づいて、この決定を行って、メディアおよびシグナリングを含むＩＰパケットの最適移動経路を検出しうる。ユーザの大半が特定の領域内で位置を特定されるときは、呼はその領域へ割り当てられる。ユーザが領域間で均等に分散しているときは、呼は、目標のユーザを含む領域の１つへ割り当てられうる。領域間呼が、領域内ディスパッチャが位置する領域とは、異なる領域内のＭＣＵへ割り当てられるときは、呼は“遠隔でホストされる”または遠隔呼と呼ばれる。領域内ディスパッチャは、ＭＣＵと、それらがサービスしているＰＤＳＮとのネットワークトポロジまたは接続、あるいはこの両者について知ると、この知識を使用して、呼の割当てをより適切に決定しうる。
【００７１】
領域内呼
グループ通信システム100は、呼の大半が領域内であることを保証するように配置されうる。領域内呼では、呼のセットアップ時に、領域内ディスパッチャ114とホームディスパッチャ102とが通信をする必要をなくしうる。領域内呼の大半に当てはまるように、目標のユーザが同じ領域内にあり、かつ呼が局所的にホストされているときも、領域間で通信する必要をなくしうる。次に続くセクションは、領域内呼における、呼の流れ、タイミングの推定、およびメッセージング方式を記載している。
【００７２】
局所呼の開始
図４は、局所グループ呼を開始するための例示的なメッセージの流れを示している。ユーザは、１人以上の目標のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを選択して、プッシュトーク（ＰＴＴ）ボタンを押しうる402。別途詳しく記載するように、クライアントは、移動局が専用トラヒックチャネルをもつかどうかとは関係なく、グループ呼をセットアップする要求を領域内ディスパッチャへ送る404。要求を送った後で、移動局のパケットデータセッションが休止状態であるときは、クライアントは、専用トラヒックチャネルを再設定し、メディアのアクティビティのためのパケットデータセッションを準備する処理を開始しうる。クライアントは、発信者から受信したスピーチ入力を所定の期間の間、バッファリングしうる。
【００７３】
領域内ディスパッチャは、要求を受信すると、要求において指定された所定のグループを、目標のユーザのメンバーリストへ拡張しうる。その後で、領域内ディスパッチャは、目標のユーザの位置情報を検索する406。この時点で、領域内ディスパッチャは、グループがシステムにおいて既に実行されているかどうかを判断しうる。図４は、グループがまだ実行されていないシナリオを示す。遅れ加入の呼のシナリオは、グループが既に実行されている場合を示し、本明細書において別途記載する。
【００７４】
領域内ディスパッチャは、目標のユーザの少なくとも１人の位置を特定した後で、グループ呼がセットアップされたことを示す応答をクライアントへ送りうる408。この時点で、クライアントは、発信者が話す要求を楽観的に承諾して410、メディアをバッファリングし始めうる412。
【００７５】
領域内ディスパッチャは、目標のユーザの位置を使用して、呼が割り当てられる領域を判断しうる。図４に示されているように、目標のユーザが、領域内ディスパッチャと同じ領域内にあると判断されたときは、領域内ディスパッチャは、呼を領域内ＭＣＵへ割り当てうる。ＭＣＵは、呼が始まっていることを示すアナウンスメントをグループ全体へ送る414。目標のユーザへアナウンスメントを送ると、パケットデータセッションが休止状態から抜け出て、かつトラヒックチャネルを再設定することをトリガしうる。
【００７６】
クライアントが呼のアナウンスメントをＭＣＵから受信し、かつ移動局のトラヒックチャネルが再設定された後で、クライアントは、バッファリングされたメディアをＭＣＵへ送りうる416。ＭＣＵは、発信者から受信したメディアをバッファリングしうる418。１つの実施形態において、ＭＣＵは、“目標の応答の閾値”が満たされるか、またはそれを越えるまで、メディアをバッファリングしうる。目標の応答の閾値は、メディアの送付を始めるのに必要な目標の応答の量の指標である。閾値は、構成可能なパラメータであってもよい。閾値が満たされると、ＭＣＵは、メディアを複製して、目標のユーザへ送り420、目標のユーザは呼のアナウンスメントに応答する422。
【００７７】
ショートデータバーストによるメッセージング
“インスタント応答”は、アプリケーションサーバが、ＰＴＴまたは呼セットアップ要求に応答するのにかかる応答時間に関係する。グループ呼セットアップ要求を含む、ＰＴＴ要求への応答は、常に一貫して、所定の時間期間（例えば、1秒以下）で常に要求に応答することを目標とする。多くの場合に、ユーザがグループ呼をセットアップすることを要求するとき、ユーザのパケットデータセッションは休止状態であり、専用トラヒックチャネルは存在しない。専用トラヒックチャネルの再設定には相当な時間がかかる。したがって、アプリケーションサーバへの通信を、他の手段によって達成してもよい。
【００７８】
グループ通信システムが“インスタント応答”を実現することを保証するために、小さいＩＰデータグラムを、パケットデータセッションの状態に関係なく、常に何れかの方向、すなわち移動局から発信する方向または移動局で終端する方向へ送りうる。１つの実施形態において、ＩＰデータグラムは、ショートデータバーストメッセージ（short data burst message, SDB）の形で送られる。パケットデータセッションが休止状態である状況では、ＳＤＢメッセージは、オーバーヘッドチャネル上で送られることになる。専用トラヒックチャネルが接続されているときは、ＳＤＢメッセージはトラヒックチャネル上で送られる。
【００７９】
図４を参照すると、グループ呼セットアップ要求は、ＳＤＢメッセージによって送られる404。アプリケーションサーバからのグループ呼セットアップ応答も、ＳＤＢメッセージで送られる408。呼セットアップ要求および応答のメッセージをＳＤＢメッセージによって送ることにより、グループ通信システム100は、“インスタント応答”の目標を満たすことができる。
【００８０】
ＭＣＵは、発信者を含むメンバーリスト内のユーザへ、呼のアナウンスメントを送ることにより、グループ呼をセットアップする処理を完了しうる。この呼のアナウンスメントは、専用トラヒックチャネルを介して送られうる。大抵の場合に、グループメンバーのパケットデータセッションは休止状態であり、すなわち専用トラヒックチャネルは設定されない。したがって、メンバーの全トラヒックチャネルが再設定され、かつメンバーがメッセージを肯定応答するか、または信頼性タイマーが切れるまで、ＭＣＵは、しつこく確実なスケジュールで、呼アナウンスメントメッセージを再送しなければならない。呼のアナウンスメントをアグレッシブに送ることにより、クライアント上でメディアをバッファリングすることが促され、ＭＣＵは最低に維持されることを保証する。クライアントは、そのトラヒックチャネルの準備が完了し、かつＭＣＵ接触情報を含む呼のアナウンスメントを受信すると直ぐに、バッファリングされたメディアを送る。ＭＣＵは、目標の応答閾値が満たされるか、または越えると直ぐに、バッファリングされたメディアを複製して、送りうる。したがって、より迅速に目標のクライアントが呼のアナウンスメントを受信して、応答し、かつより速くこの閾値が満たされると、より速くＭＣＵはバッファリングを止めて、メディアを送り始める。
【００８１】
発信者への呼のアナウンスメントも、ＳＤＢによって送られうる。これは、２つの効果を与える。第１に、呼のアナウンスメントはＭＣＵ接触情報を含むので、移動局のトラヒックチャネルが再設定されると直ぐに、グループ呼のクライアントは、バッファリングされたメディアをＭＣＵへ送り始め、バッファリングされたメディアを保持する移動局のＲＡＭの要件が緩和されうる。第２に、呼のアナウンスメントがＳＤＢによって届くとき、トラヒックチャネルが再設定される前に、発信者が呼を捨てるか、またはフロアを解放すると決定するならば、クライアントはその情報をＭＣＵに通知することができる。呼のアナウンスメントをＳＤＢによって発信者へ送ると、共通チャネル上のロードが増し、かつＭＣＵは、発信者の呼アナウンスメントメッセージに特別な処理を行なわなければならなくなる。
【００８２】
遠隔呼の開始
全メンバーが同じ領域内に位置しているときは、領域内の呼は局所的にホストされうる。領域内ディスパッチャは、局所資源がオーバーロードしているか、または使用できないという理由で、領域内呼を遠隔領域へ割り当てうる。このような場合に、ユーザのＰＤＳＮと遠隔のＭＣＵとの通信経路が伸びるので、メディアおよびシグナリングの待ち時間および誤りが追加されることがある。図５は、遠隔の領域内呼に対する例示的な呼セットアップを示している。
【００８３】
遠隔のホスト上で領域内呼を開始することは、図４に関係して記載した呼セットアップのシナリオに類似しているが、領域内ディスパチャーが呼をＭＣＵへ割り当てることが異なる。領域内ディスパッチャは、グループメンバーの位置を検索した後で、呼が割り当てられるＭＣＵを判断する。領域内ディスパッチャは、ユーザの位置情報、ローディング、およびＭＣＵの可用性に基づいて、この決定を行いうる。領域内呼では、ユーザは同じ領域内に位置を特定されるので、領域内ディスパッチャは、局所領域内のＭＣＵ複合体のローディングおよび可用性を検査しうる。領域内ディスパッチャは、局所ＭＣＵ複合体がオーバーロードしているか、または一時的に動作障害を経験したという指標を受信すると、呼を遠隔のＭＣＵへ割り当てうる。１つの実施形態において、各ＭＣＵでは、呼構成を除いて、同一の機能が複製されているので、遠隔のＭＣＵは、局所ＭＣＵと同様に、呼を処理しうる。
【００８４】
領域間呼
グループ呼システム100は、ユーザが他のユーザと、相互の物理的な位置または近さに関係なく、通信できるように設計されうる。領域間呼では、呼セットアップ時間に領域内ディスパッチャとホームディスパッチャとの通信が必要であるので、グループ通信システム100は、領域間呼の数を制限するように配置されうる。呼は、呼の参加者の１人以上から、遠隔領域内のＭＣＵへ割当てられうる。次に続くセクションでは、例示的な呼の流れ、タイミング推定、および領域間の呼のメッセージ方式を記載する。
【００８５】
局所呼の開始
図６は、局所的にホストされるグループ呼を開始するための例示的なメッセージの流れを示している。局所の領域間呼の呼セットアップは、図４に関係して記載した局所の領域内呼の呼セットアップに類似しているが、局所ディスパッチャが目標のユーザの位置情報を検索する処理をすることが異なる。１つの実施形態において、領域内ディスパッチャは、そのキャッシュ内の目標のユーザの位置を特定することを試みる。何人かのユーザがキャッシュ内で検出されないときは、局所ディスパッチャは、ホームディスパッチャからの支援を要求して、ユーザの位置を特定する。ホームディスパッチャは、領域内位置サーバを使用して、ＩＰ登録を行ったユーザのユーザ位置情報を収めうる。前述のように、領域内位置サーバは、ユーザの登録が行われるたびに、関係付けられた領域内ディスパッチャに通知しうる。各領域内ディスパッチャは、ホームディスパッチャにユーザの登録を通知する。したがって、ホームディスパッチャは、地理的に異なる領域にまたがって分散しているユーザを検出する際に、領域内ディスパッチャを支援することができる。
【００８６】
遠隔呼の開始
図７は、遠隔の領域間呼の例示的なセットアップを示している。遠隔のホストにおける領域間呼を開始することは、図４に関係して記載した呼セットアップのシナリオに類似しているが、領域内ディスパッチャがＭＣＵへ呼を割り当てることが異なる。領域内ディスパッチャ（ＲＤ）114は、グループメンバーの位置を検索した後で、呼が割り当てられるＭＣＵを判断しうる。ＲＤ114は、ユーザの位置情報、ローディング、およびＭＣＵの可用性に基づいて、この決定を行いうる。ＲＤは、グループメンバーの位置を使用して、サービスプロバイダのネットワーク上での、メディアおよびシグナリングを含むＩＰパケットの、メンバーの大半への最適移動経路を検出することを試みる。ユーザの大半が特定の領域に位置を特定されるときは、呼はその領域に割り当てられうる。ユーザが領域にまたがって均等に分散しているときは、呼は、目標のユーザを含む領域の1つへ割り当てられうる。
【００８７】
グループ呼の終了
グループ呼は２つの理由で終了する。すなわち、全参加者が、呼から抜け出るように要求されたとき、または全参加者が、所定の時間期間の間、話すのを止めるとき（“ハングタイム”と呼ばれる）である。各参加者は、呼の予定された終了前に、呼に参加するのを止めることを選択してもよい。全参加者が呼から抜け出るときは、ＭＣＵは呼を終了して、呼に割当てられた全資源を解放する。１人を除く全参加者が呼から抜け出ると、ＭＣＵは、“単独のユーザ”と呼ばれる参加者に通知しうる。単独のユーザは、直ちに呼から抜け出るか、またはハングタイムのタイマーが切れるのを待つことを選択し、これにより、ＭＣＵは呼の切断をトリガしうる。
【００８８】
ＭＣＵは、ハングタイムタイマーが切れたときに、呼を終了しうる。ＭＣＵは、各トークスパートを追跡し、トークスパートの完了後にタイマーをセットする。このタイマーは、ハングタイムタイマーと呼ばれ、呼中の、沈黙期間、すなわち、トークまたはメディアの流れのアクティビティがない期間を追跡しうる。呼が、サービスプロバイダによって構成されるハングタイム期間の沈黙のままであるときは、ＭＣＵは、参加者が呼に最早関心がないと断定し、呼を終了しうる。
【００８９】
ユーザが呼の終了を開始
図８は、ユーザがグループ呼への参加を止めることを選択する例示的なシナリオを示している。シナリオは、ユーザが参加を止めるメッセージの流れを示している。ユーザがグループ呼への参加を止めることを選択するとき802、クライアントはユーザを呼から削除する要求をＭＣＵへ送る804。ＭＣＵは、ユーザを呼から削除し806、ユーザが削除されたことをクライアントへ通知しうる808。
【００９０】
サーバが呼の終了を開始
図９は、ハングタイムタイマーが切れて、ＭＣＵがグループ呼を終了するときに行われる例示的なメッセージの流れを示す。ハングタイムタイマーが切れると902、ＭＣＵは、呼が終ったという通知を参加者へ送りうる904。呼終了通知を受信した各クライアントは、肯定応答で応答する906。ＭＣＵは、肯定応答を受信すると、呼が終了したことをＲＤへ知らせ、呼に割り当てられた資源を解放しうる908。
【００９１】
警告の送付
警告機構は、別のユーザ、すなわち警告発信者が、目標のユーザをグループ呼に参加させたいという意向を、目標のユーザに通知するのに使用されうる。警告機構は、発信者が呼の対象を指定できるようにするテキストメッセージ、呼の希望時間、または他のユーザのカスタマイズ可能なテキストメッセージを含みうる。図１０は、ユーザが警告を送るときに行われる例示的なメッセージの流れを示す。
【００９２】
発信者は、１人以上の目標のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを選択し、警告を送ることを示しうる1002。クライアントは、要求に指定されている目標のユーザへ警告を送付する要求を、ＲＤへ送りうる1004。ＲＤは、要求を受信すると、要求に指定されている所定のグループを、目標のユーザのメンバーリストへ拡張し、目標のユーザの位置情報を検索しうる1006。ＲＤは、目標のユーザの少なくとも1人の位置を特定した後に、クライアントへ応答を送りうる1008。ＲＤは、警告要求をＭＣＵへ割り当てて1010、警告メッセージを目標のユーザへ同報通信しうる1012。
【００９３】
図１０に示されているように、警告要求はショートデータバースト（ＳＤＢ）によって送られうる。ＳＤＢメッセージによって警告を送ることにより、関係する当事者のパケットデータセッションを、休止状態のままにすることができる。警告通知は、目標のユーザが、例えば、警告通知を選択して、ＰＴＴを押すことによって、発信者および目標のユーザの残りとのグループ呼をセットアップできるようにするための必要な情報を含む。これが行われるとき、グループ呼のセットアップは、図４に関係して記載された呼セットアップのシナリオに類似して進められる。
【００９４】
遅れ加入
呼セットアップ要求に指定されているメンバーリストが、システムにおいて既に進行中の呼と関係付けられるメンバーリストと同じであると判断されるとき、グループ呼セットアップ要求は、遅れ加入であると見なされる。この状況は、次の２つの一方において現れうる。第１に、ユーザは、例えば、それと関係している呼を予め含んでいるメンバーリストと全く同じメンバーリストを、例えば、同一ユーザまたはグループ、あるいはこの両者を選択し、かつＰＴＴボタンを押すことによって、生成する。第２に、ユーザは、システムにおいて依然として実行されている呼を、呼履歴リストから選択し、ＰＴＴを押す。何れの場合においても、ＲＤは、ユーザが始めるように要求した呼が、既に進行中であることを検出し、ユーザを遅れ加入として取扱いうる。
【００９５】
図１１は、ユーザが呼履歴リストから呼を選択する例示的な遅れ加入の事例を示す。ユーザは、呼履歴リストから呼を選択し、ＰＴＴボタンを押す1102。クライアントは、グループ呼を開始する要求をＲＤへ送りうる1104。ＲＤは、呼が既に実行されていると判断し1106、ユーザが進行中の呼に加えられたという応答をクライアントへ送りうる1108。呼が既に実行されているときは、フロアは現在の呼の参加者によって既に保持されているので、遅れ加入のユーザがメディアを受信する用意が整うときまで、すなわち、パケットデータセッションが休止状態から抜け出るときまで、フロアはユーザに譲与されない。ＲＤは、呼をホストしているＭＣＵに、遅れ加入のユーザをグループへ加えるように要求する1110。ＭＣＵは、ユーザを加え、ＭＣＵ接触情報を含むアナウンスメントをユーザへ送る1112。遅れ加入ユーザのトラヒックチャネルが再設定された後で、呼内のメディアの流れが、ユーザへ伝送されうる。このとき、遅れ加入のユーザは、話す特権を要求することを試みることができる。
【００９６】
遅れ加入のシナリオは、図４に関係して記載された新しいグループ呼を開始するシナリオに類似している。異なるのは、遅れ加入のユーザが、最初のグループ呼セットアップ要求に対する応答において、フロアを拒絶されることである。
【００９７】
送話者の調停
１つの実施形態において、各グループ呼のユーザは、送話者プリエンプションランクを割り当てられる。これは、“フロア”を得る特権を要求して、話し始めるときに、ユーザが何れのレベルの権利をもつかを決定する。ＭＣＵは、グループ呼のセットアップ後に、フロア制御を担当し、フロアを要求する参加者が話すのを許可するかどうかを決定しうる。ＭＣＵは、２人以上の呼の参加者が、特定のグループのフロアの制御について競合しているときに、送話者の調停を行いうる。
【００９８】
図１２は、調停処理中に行われうる例示的なイベントを示している。このシナリオにおいて使用される調停方式では、ユーザＡがフロアを要求するとき、ユーザＢのプリエンプションを可能にする。ユーザＡが、ＰＴＴボタンを押すことによって話す許可を要求するとき1202、ユーザＢはフロアを制御している、すなわち、ユーザＢは話している。クライアントは、話すための許可を要求するメッセージをＭＣＵへ送りうる1204。ＭＣＵは、送話者の調停を行い1206、ユーザＢをプリエンプトし、ユーザＡへフロアを譲与すると決定しうる。メディアの流れの中断、すなわちユーザＢが話すのを止めた後で、ユーザＡのメディアが伝送されるのを保証するために、ＭＣＵは、最初に、フロアが別のユーザによってプリエンプトされたことを示すメッセージを、ユーザＢのクライア
アクティブなグループ呼へのユーザの追加
グループ通信システム100では、グループ呼の参加者は、進行中のグループ呼へ新しいユーザを加えることができる。これは、呼の参加者が、１人以上の目標のユーザ、１つ以上の所定のグループ、またはこの２つの組合せを選択し、かつ参加者が、参加者が現在入っているグループ呼に、目標のユーザを加えたいことを示すことによって達成する。図１３は、新しい目標のユーザを、進行中のグループ呼に加えるときに行われるイベントを示している。呼の参加者は、呼に加えられる１人以上の目標のユーザ、１つ以上のグループ、またはこの２つの組合せを選択する1302。クライアントは、要求に指定したように、指定した目標のユーザを進行中のグループ呼に加えることを要求するメッセージをＲＤへ送りうる1304。ＲＤは、要求を受信すると、要求に指定されている所定のグループを、目標のユーザのメンバーリストへ拡張しうる。その後で、ＲＤは、目標のユーザの位置情報を検索しうる1306。ＲＤは、目標のユーザの少なくとも１人の位置を特定した後で、目標のユーザが呼に加えられることを示す応答をクライアントへ送りうる1308。ＲＤは、指定されたユーザを呼に加える要求をＭＣＵへ送りうる1310。ＭＣＵは、呼のアナウンスメントを新しい目標のユーザへ送り、これによりパケットデータセッションを休止状態から戻す処理が始まりうる1312。アナウンスメントは、目標のユーザがメッセージを受信することを保証するように、確実なスケジュールで送られうる。目標のユーザのトラヒックチャネルの再設定後に、目標のユーザは、ＭＣＵへ肯定応答を送りうる1314。追加の目標のユーザは、呼中に行われるメディアおよびシグナリングの通信に含まれうる1316。
【００９９】
アクティブなグループ呼からのメンバーの削除
グループ通信システム100では、グループ呼の参加者は、アクティブなグループからメンバーを削除することができる。１つの実施形態において、これは、呼の参加者が、１人以上の目標の参加者を選択し、グループ呼から削除すべきであることを示すことによって達成されうる。図１４は、参加者が進行中のグループ呼から削除されるときに行われうる例示的なイベントを示している。グループ呼の参加者は、呼から削除されることになる１人以上の目標の参加者を選択しうる1402。クライアントは、メッセージに指定されている目標の参加者を、グループ呼から削除することを要求するメッセージをＲＤへ送りうる1404。ＲＤは、要求を受信すると、目標の参加者の位置情報を検索し1406、目標の参加者が削除されることを示す応答をクライアントへ送りうる1408。ＲＤは、目標の参加者を呼から削除する要求をＭＣＵへ送りうる1410。ＭＣＵは、削除要求に指定されている目標の参加者へ、彼らが呼から削除されることを示すメッセージを送りうる1412。目標の参加者は、肯定応答をＭＣＵへ送りうる1414。
【０１００】
登録解除
ユーザが、アプリケーションサーバによって、またはユーザのＩＰアドレスを使用して、ユーザに接触する他のＩＰアプリケーションによって、接触されることを最早望まないとき、登録解除機能が実行される。登録解除機能は、ユーザのＩＰアドレスおよび他の接触情報をＲＬＳから削除し、ユーザのために割り当てられた資源を解放する。図１５は、１つの実施形態にしたがって、移動局がパワーダウンした結果、ユーザの登録をＲＬＳからどのようにして削除するかを示す。クライアントは、クライアントが位置している移動局がパワーダウンしたという指示を受信しうる1502。シャットダウン処理の一部として、クライアントは、ユーザの位置情報を削除すべきであることを示すメッセージをＲＬＳへ送りうる1504。ＲＬＳは、その要求を認証し、それが有効なソースからであることを確認しうる1506。ＲＬＳは、認証に成功すると、成功の指示をクライアントに通知し1508、ＲＤにユーザの削除に関して通知しうる1510。ＲＤは、ユーザのデータ記録をキャッシュから削除し、ユーザに割当てられた資源を解放しうる。登録解除に失敗したときは、ユーザの位置情報は、最終的に、期限切れの範囲と関係付けられた時間が経過したときに、ＲＬＳから削除されうる。
【０１０１】
１つの実施形態において、グループ通信システム100は、チャットルームモデルとアドホック・モデルの両者を支援する。チャットルームモデルでは、グループは予め定められ、ディスパッチサーバ上に記憶される。所定のグループは公開であり、したがって、グループが開かれたメンバーリストをもち、すなわち、ディスパッチユーザが潜在的な参加者であることが示唆される。チャットルームモデルでは、１人目がチャットルームに加入するのを選択するときに、呼は開始され、サーバ資源が、トークアクティビティに関係なく、サービスプロバイダによって構成された所定の時間の間、呼に割り当てられているならば、呼は継続する。ユーザは、これらのタイプの呼に加入したり、抜けたりすることを明確に要求する。別途記載するように、トークアクティビティのない期間の間は、各呼は、ユーザが話す許可を要求するまで、グループ休止状態に入る。
【０１０２】
アドホック・モデルでは、グループは実時間で定められ、グループと関係付けられた限定メンバーのリストを有しうる。限定メンバーリストは、何れのユーザがグループに参加するのを許可されるかを指定し、限定メンバーリスト以外のユーザには無効であり、呼の存続期間の間のみ存在しうる。アドホック・グループの定義は、どこにも記憶されず、したがって、この定義は、呼を設定するのに使用され、呼の終了後に解放されうる。
【０１０３】
アドホック・グループは、発信ユーザが１人以上の目標のユーザを選択し、かつ呼を開始するためにサーバへ送られる要求を生成するときに、形成されうる。目標のユーザは、彼らがグループに含まれたという通知を送られ、関係付けられた呼に自動的に加えられうる。すなわちユーザは動作を要求されない。アドホック呼がアクティブでなくなると、アプリケーションサーバは、呼を“切り”、呼を開始するのに使用されるグループの定義を含めて、それに割り当てられた資源を解放しうる。
【０１０４】
グループ通信システム100において、チャットルームモデルで動作するとき、通信装置のユーザのグループ（個々のユーザは、ネットメンバーとして知られている）は、各ネットメンバーに割当てられた通信装置を使用して、相互に通信する。“ネット”という用語は、相互に通信する権利を与えられた通信装置のユーザのグループを示す。
【０１０５】
１つの実施形態において、中央データベースは、各個々のネットのメンバーを識別する情報を含む。同一通信システムにおいて、１つより多いネットが動作しうる。例えば、第１のネットは、１０人のメンバーを有すると定義され、第２のネットは、２０人のメンバーを有すると定義されうる。第１のネットの１０人のメンバーは、相互に通信するが、第２のネットのメンバーとは通信しない。別の実施形態において、異なるネットのメンバーは、２つ以上のネットのメンバー間の通信を監視することはできるが、情報を伝送できるのは、自分のネット内のメンバーのみでありうる。
【０１０６】
ネットは、既存のインフラストラクチャに実質的な変更を要求することなく、既存の通信システム上で動作しうる。したがって、ネット上の制御装置およびユーザは、インターネットプロトコル（ＩＰ）を使用して、パケット情報を送受信することができるシステム、例えば、符号分割多重アクセス（Code Division Multiple Access, CDMA）システム、時分割多重アクセス（Time Division Multiple Access, TDMA）システム、移動通信用グローバルシステム（Global System for Mobile Communication）のシステム、Globalstar(商標)またはIridium（商標）のような衛星通信システム、または種々の他のシステムにおいて動作しうる。
【０１０７】
ネットメンバーは、割り当てられた通信装置（通信装置（communication device, CD）120、122として示されている）を使用して、相互に通信しうる。ＣＤ120および122は、ワイヤーラインまたはワイヤレスの通信装置であり、地上ワイヤレス電話、プッシュトーク機能をもつワイヤーライン電話、プッシュトーク機能を備えた衛星電話、ワイヤレスビデオカメラ、静止カメラ、ミュージックレコーダまたはプレーヤのようなオーディオ装置、ラップトップまたはデスクトップコンピュータ、ページング装置、またはその組み合わせである。例えば、ＣＤ120は、ビデオカメラおよびディスプレイを備えたワイヤレス地上電話を含みうる。さらに、各ＣＤは、セキュアモードまたはノンセキュア（クリア）モードの何れかで情報を送受信することができる。以下の記述全体で、個々のＣＤに対する参照は、プッシュトーク電話を示唆する。しかしながら、ＣＤに対する参照は、それに制限することを意図されておらず、インターネットプロトコル（ＩＰ）にしたがってパケット情報を送受信する能力をもつ他の通信装置を含みうる。
【０１０８】
グループ通信システム100では、一般に、１人のユーザは、伝送特権により、所与の時間に、残りのネットメンバーへ情報を伝送することができる。要求が受信されたときに、伝送特権が現在別のネットメンバーに割り当てられているかどうかに依存して、伝送特権は、要求しているネットメンバーへ譲与されるか、または拒絶される。伝送要求の承諾および拒絶の処理は、調停として知られている。調停方式では、要求しているネットメンバーが伝送特権を譲与されるかどうかを判断するときに、各ＣＤに割り当てられた優先度レベル、伝送特権を得る試行の失敗した数、ネットメンバーが伝送特権を保持する時間の長さ、または他の要素のような要素を評価しうる。
【０１０９】
システム100に参加するために、ＣＤ120および122の各々は、制御装置またはＭＣＵ116から伝送特権を要求する能力を有しうる。ＭＣＵ116は、グループの実時間の管理動作を処理しうる。ＭＣＵは、少なくとも１つのプロセッサおよびメモリをもつ任意のタイプのコンピュータ形装置である。ＭＣＵ116は、サービスプロバイダによって権利が与えられると仮定して、通信システムサービスプロバイダ、メンバー、またはこの両者の何れかを介して遠隔動作しうる。ＭＣＵ116は、外部の管理インターフェイスを介して、グループ定義を受信しうる。グループメンバーは、サービスプロバイダーによる管理を要求するか、またはＭＣＵ管理インターフェイスに適合しうる、メンバーが動作するセキュリティマネージャ（security manager, SM）のような規定のシステムによるネット機能を管理しうる。ＭＣＵ116は、ネットを設定または変更することを試みる当事者を認証しうる。
【０１１０】
ＳＭは、キーの処理、ユーザ認証、およびセキュアネットを支援するための関係するタスクを行いうる。１つのグループ通信システムは、１つ以上のＳＭと対話しうる。ＳＭは、ネットのアクティベーションまたはＰＴＴの調停を含む、ネットの実時間の制御に関与しなくてもよい。ＳＭは、ＭＣＵインターフェイスと互換性のある管理能力をもち、管理機能を自動化しててもよい。ＳＭはまた、ネットに参加するためのデータエンドポイントとして働くことができるか、ネットキーを同報通信するか、または単にネットトラヒックを監視しうる。
【０１１１】
１つの実施形態において、ＭＣＵから伝送特権を要求する手段は、プッシュトーク（ＰＴＴ）キーまたはスイッチを含む。システム100のユーザは、情報を他のメンバーへ伝送したいとき、ＣＤ上に配置されたプッシュトークスイッチを押して、フロア制御要求を送り、ＭＣＵ116から伝送特権を得る。他のネットメンバーが現在伝送特権を割り当てられていないときは、要求しているユーザは、伝送特権を譲与され、ＣＤを介して、聴覚、視覚、または触覚による警告によって通知されうる。要求しているユーザが伝送特権を譲与された後で、このユーザから他のメンバーへ情報が伝送されうる。
【０１１２】
本発明の１つの実施形態において、各無線ネットメンバーは、１つ以上の基地局126か、またはその代りに、場合によっては、衛星ゲートウエイと、順方向リンクおよび逆方向リンクを設定する。音声またはデータ、あるいはこの両者は、例えば、ＣＤを使用して、他のユーザと通信するための個々の分散形ネットワーク128に適したデータパケットへ変換されうる。１つの実施形態において、分散形ネットワーク128はインターネットである。
【０１１３】
１つの実施形態では、各通信システム、すなわち地上通信システムおよび衛星通信システムにおいて、各ネットメンバーから他のネットメンバーへ情報を同報通信するために、専用順方向チャネルが設定される。各ネットメンバーは、専用チャネルによって、他のネットメンバーから通信を受信する。別の実施形態では、各通信システムにおいて、情報をＭＣＵ116へ伝送するために、専用逆方向リンクが設定される。１つの実施形態では、上述の方式の組合せを使用しうる。例えば、１つの方式では、専用順方向同報通信チャネルを設定するが、無線ＣＤは、各ＣＤに割り当てられた専用逆方向リンクによってＭＣＵ116へ情報を伝送しなければならない。
【０１１４】
第１のネットメンバーは、ネットの他のメンバーへ情報を伝送したいとき、自分のＣＤ上のプッシュトークキーを押すことによって、伝送特権を要求し、分散形ネットワーク128上で伝送するためにフォーマットされた要求を生成しうる。ＣＤ120および122の場合に、要求は、１つ以上の基地局126へ空中で伝送されうる。移動交換局（mobile switching center, MSC）130は、データパケットを処理するために、周知のインターワーキング機能（inter-working function, IWF）、パケットデータ供給ノード（packet data serving node, PDSN）、またはパケット制御機能（packet control function, PCF）を含んでおり、ＢＳ126と分散形ネットワーク128との間に存在する。要求は、公衆交換電話ネットワーク（public switched telephone network, PSTN）を介して、モデムバンクへ伝送され、モデムバンクは要求を受信して、それを分散形ネットワーク128へ供給しうる。端末は、分散形ネットワーク128に接続することによって、システム100のトラヒックを監視しうる。
【０１１５】
他のメンバーが伝送特権を現在保持していないときは、ＭＣＵ116は、伝送特権要求を受信すると、要求しているネットメンバーにメッセージを伝送して、伝送特権が譲与されたことを通知する。第１のネットメンバーからの聴覚、視覚、または他の情報は、上述の伝送経路の1つを使用して、ＭＣＵ116へ情報を送ることによって、他のネットメンバーへ伝送される。１つの実施形態において、ＭＣＵ116は、情報を複製して、各複製を他のネットメンバーへ送ることによって、他のネットメンバーへ情報を供給する。１本の同報通信チャネルが使用されるときは、使用される各同報通信チャネルごとに、情報を１回だけ複製すればよい。
【０１１６】
代わりの実施形態では、ＭＣＵ116をＭＳＣ130内に組込んで、基地局を支援するために、データパケットを、分散形ネットワーク128上へルート設定することなく、ＭＣＵ116へ直接にルート設定する。この実施形態において、ＭＣＵ116は分散形ネットワーク128に接続されたままであるので、他の通信システムおよび装置は、グループ通信に参加することができる。さらに別の実施形態において、ＭＣＵ116は、ＭＳＣ130のＰＤＳＮまたはＰＣＦのモジュールへ組込まれうる。
【０１１７】
１つの実施形態において、ＭＣＵ116は、個々のネットメンバーおよび各所定のネットに関係する情報を管理するための１つ以上のデータベースを維持する。例えば、データベースは、各ネットメンバーごとに、ユーザ名、口座番号、メンバーのＣＤと関係付けられた電話番号、すなわちダイヤル番号、ＣＤに割り当てられた移動局識別番号、ネットにおける現在のメンバーの状態（例えば、メンバーがネットにアクティブに参加しているかどうか）、伝送特権の割当て方を判断するための優先コード、ＣＤと関係付けられたデータ電話番号、ＣＤと関係付けられたＩＰアドレス、およびメンバーが何れのネットと通信することを許可されたかについての指標のような情報を含みうる。他の関係するタイプの情報は、各ネットメンバーに関係して、データベースによって記憶されうる。
【０１１８】
１つの実施形態において、ＣＤは個々の通信端末と接続して、１つのトークグループ、すなわちネットを形成しうる。ＭＣＵは、異なるアプリケーションに対応するように異なる様式で構成可能な、ハードウエアおよびソフトウエアにおける種々の機能能力を含みうる。ＭＣＵは、ネットの実時間の管理および認証動作、プッシュトーク（ＰＴＴ）要求の調停、ネットメンバーシップおよび登録リストの保守および分配、必要な通信（例えば、ＣＤＭＡ）の呼のセットアップおよび切断、システムおよびネットワークの資源、並びにネット状態の全体的な制御を管理する能力を備えうる。
【０１１９】
ネットは、スタンドアローン形の配置可能なセルラシステムか、または大きい多数のサイトの構成内にありうる。大きい構成の場合は、多数のＭＣＵを地理的に配置して、１つの統合形システムを形成し、各ＭＣＵは、既存のセルラのインフラストラクチャへのプラグインモジュールとして動作しうる。したがって、ネットによって取り入れられる新しい特徴は、既存のセルラのインフラストラクチャを変更する必要なく、セルラユーザに使用可能である。
【０１２０】
ＭＣＵは、所定のネットのリストを維持しうる。１つの実施形態において、各ネットの定義は、ネット識別子、電話番号または他の識別情報を含むメンバーのリスト、ユーザ優先情報、および他の一般管理情報を含む。ネットは、静的にクリアまたはセキュアであると定義され、クリアとセキュアとの間の遷移は許されない。セキュアネットは、一般に、メディアの暗号化を使用して、認証を与え、盗聴から保護する。セキュアネットにおけるメディアの暗号化は、エンド ツー エンドで行われ、したがって、暗号化および復号は通信装置内で行われうる。ＭＣＵは、セキュリティアルゴリズム、キー、またはポリシーを知らなくても動作することができる。
【０１２１】
図１６は、通信装置（communication device, CD）1602、1604、および1606がＭＣＵ1608とどのように対話するかを示すための例示的なグループ1600を示している。多数のＭＣＵが、大きいグループに望ましいように配置される。図１６において、ＣＤ1602は、メディアを、グループの他のメンバーへ伝送することができる。この場合に、ＣＤ1602は、送話者として知られていて、チャネルによりメディアを伝送する。ＣＤ1602が送話者として指定されると、残りの参加者、すなわちＣＤ1604およびＣＤ1606は、メディアをグループへ伝送することができない。したがって、ＣＤ1604およびＣＤ1606は、受話者として指定される。
【０１２２】
上述のように、ＣＤ1602、1604、および1606は、少なくとも１本のチャネルを使用して、ＭＣＵ1608へ接続される。１つの実施形態において、チャネルは、セッション開始プロトコル（ＳＩＰ）チャネル1610、メディアシグナリングチャネル1612、およびメディアトラヒックチャネル1614を含む別々のチャネルへ分けられる。ＳＩＰチャネル1610およびメディアシグナリングチャネル1612は、バンド幅が許すときはいつでも、ＣＤ1602、1604、および1606によって、送話者として指定されるか、または受話者として指定されるかとは関係なく、使用されうる。ＳＩＰは、インターネット技術標準化委員会（Internet engineering task force, IETF）が定めたアプリケーション層プロトコルであり、インターネットプロトコル（ＩＰ）によって動作するマルチメディアセッションを設定し、変更し、終了するための制御機構を記載している。ＳＩＰは、ユーザを登録し、かつ位置を特定するための機構、ユーザの能力を定め、かつメディアのパラメータを記載するための機構、並びにユーザの可用性、呼のセットアップ、および呼の処理を判断するための機構を支援することによって、インターネット電話アプリケーションの呼−シグナリングの問題を概ね解決する。
【０１２３】
１つの実施形態では、ＳＩＰチャネル1610を使用して、グループ1600内におけるＣＤの参加を開始および終了する。また、ＳＩＰチャネル1610内では、セッション記述プロトコル（session description protocol, SDP）信号が使用されうる。例えば、ＳＩＰチャネル1610を使用することによって、グループ内のＣＤの参加がセットアップされると、例えば、ＮＢＳメディアシグナリングチャネル1612を使用することによって、ＣＤとＭＣＵとの実時間の制御およびシグナリングが行なわれる。１つの実施形態において、メディアシグナリングチャネル1612は、プッシュトークの要求および解放の処理、競合する要求、すなわちフロア制御の調停、情報伝送の開始および終了のアナウンス、ネットの休止状態の管理、エンドポイントの接続の追跡、ネット状態の要求および交換、並びにエラーメッセージの通知に使用される。メディアシグナリングチャネル1612のプロトコルは、最も一般的なメッセージの長さを最小化し、要求に対する返答および応答を解釈するタスクを簡潔化し、一方で将来の拡張のために融通性を維持する。さらに加えて、メディアシグナリングチャネル1612のプロトコルは、プロトコルの状態に悪影響を与えることなく、要求の再送を可能にする。
【０１２４】
１つの実施形態において、メディアシグナリングチャネル1612上のシグナリングトラヒックは、呼のセットアップおよび制御のシグナリング（セッション勧誘要求および肯定応答を含む）と、メディアのシグナリング（実時間のフロア制御要求および関係する非同期メッセージを含む）とを含む。メディアトラヒックチャネル1614上のメディアトラヒックは、実時間の、ポイント ツウ マルチポイントの、音声またはデータ、あるいはこの両者の同報通信を含む。両者のメッセージングカテゴリは、固有の機能属性をもつ。さらに加えて、各ＣＤは、ドメイン名サービス（ＤＳＮ）のクライアントの要求を発行し、完全修飾されたＤＳＮのホスト名をインターネットのネットワークアドレスへマップするのを促しうる。
【０１２５】
１つの実施形態において、呼セットアップおよび呼制御のシグナリングは、ＳＩＰの意味論にしたがって行われる。１つの実施形態において、ＳＩＰは、周知のユーザデータグラムプロトコル（user datagram protocol, UDP）または伝送制御プロトコル（transmission control protocol, TCP）の何れかを使用して移送されるが、各ＣＤは、ＵＤＰを使用して、ＳＩＰベースのシグナリング機能を行う。さらに加えて、各ＣＤは、ＵＤＰによって、ＳＩＰシグナリング要求を受信すると予測する。実時間のシグナリングは、ＣＭおよび各ＣＤにおいて、動的なＵＤＰ／ＩＰインターフェイスを介して行われうる。他のシグナリングは、例えば、ＳＩＰを使用して、ＣＭとＣＤとの間の固定のＴＣＰ／ＩＰインターフェイスを介して行われうる。
【０１２６】
ＰＴＴ待ち時間
１つの実施形態において、パケットデータサービスがアクティブであるときは、インフラストラクチャ（例えば、基地局トランシーバサブシステム（base station transceiver subsystem, BTS）、基地局制御装置（base station controller, BSC）、インターワーキング（ＩＷＦ）、および無線リンク）内の資源は、移動局（ＭＳ）へアクティブに割り当てられる。ＩＰベースのＶｏＩＰディスパッチサービスにおいて、グループの参加者間でアクティブな会話が行われているときは、各ユーザのパケットデータ接続はアクティブなままである。しかしながら、グループ通信では、アクティビティのない期間、すなわち“ハング時間”の後で、ユーザトラヒックチャネルは、休止状態へ遷移しうる。
【０１２７】
休止状態へ遷移することにより、システム容量を節約し、サービスコストおよびバッテリの消耗を低減し、ユーザが、到来する従来の音声呼を受信できるようにする。例えば、ユーザは、アクティブなパケットデータ呼に加わっているときは、通常は、到来する音声呼に対して“ビジー”であるとみなされる。ユーザのパケットデータ呼が休止状態であるときは、ユーザは、到来する音声呼を受信することができる。これらの理由のために、パケットデータのアクティビティのない期間の後で、パケットデータ呼を休止状態に遷移することが望ましい。
【０１２８】
パケットデータ呼がアクティブである間は、パケットデータが交換されていなくても、無線周波数（radio frequency, RF）エネルギーが、低レベルではあるが、移動電話によって引き続き伝送され、基地局との同期および電力制御が維持される。これらの伝送により、電話は相当に電力を消耗する。しかしながら、休止状態では、電話はＲＦの伝送を行わない。電話の電力を節約し、かつバッテリの寿命を延ばすために、長くデータが伝送されなかった後で、電話を休止モードへ遷移するように、ハングタイムを設定してもよい。
【０１２９】
全ユーザにおいてパケットデータサービスがアクティブであるときは、ＰＴＴ要求（ＭＳとディスパッチサーバとの間で送られるＩＰデータグラム）の待ち時間は非常に短い。しかしながら、ユーザチャネルが、休止状態に既に遷移されているときは、ＰＴＴ待ち時間は相当に長くなる。パケットデータの休止状態の間は、移動局のＩＰアドレスを含めて、パケットデータセッションと関係付けられた状態情報は維持されうる。しかしながら、ＰＰＰよりも低い層（例えば、物理トラヒック層）と関係付けられた状態情報は、解放、または割当て解除、あるいはこの両者を行われうる。
【０１３０】
いくつかのインフラストラクチャでは、休止状態からデータ接続を起こすために、トラヒックチャネルを再割り当てしなければならず、資源を再割り振りしなければならず、無線リンクプロトコル（radio link protocol, RLP）層を再初期化しなければならない。このために、トークグループがしばらく話しをしなかった後で、ユーザがＰＴＴボタンを押して、フロアを要求するとき、第１の送話者のスパートに対するＰＴＴ待ち時間は、一般に、次のトークのスパートよりも相当に長くなる。これは比較的に頻繁ではないが、サービスのユーティリティに影響を与えることがあり、最小化されるべきである。
【０１３１】
１つの実施形態では、ＰＴＴ待ち時間を低減するために、フロア制御要求、フロア制御応答、および休止状態からの起動メッセージのような、グループ呼のシグナリングは、専用トラヒックチャネルが再設定されるのを待つことなく、使用可能な共通チャネル上で伝送されうる。このような共通チャネルは、移動局の状態とは関係なく、常に使用可能であり、ユーザがグループ呼を開始することを望むたびに、要求および再割当てする必要はない。したがって、移動局が休止状態であっても、グループ呼のシグナリングは交換され、並行して、送話者および受話者の移動局への専用トラヒックチャネルを再設定するための手段が与えられうる。
【０１３２】
１つの実施形態において、発呼側移動局は、逆方向アクセスチャネルおよび逆方向拡張アクセスチャネルのような、いくつかの使用可能な逆方向共通チャネル上で、フロア制御要求を無線インフラストラクチャへ送りうる。発呼側移動局はまた、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な順方向共通チャネル上で、フロア制御要求に対する応答を受信しうる。１つの実施形態において、休止状態の受話者の移動局は、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な順方向共通チャネル上で、休止状態からの起動のメッセージを受信しうる。
【０１３３】
ショートデータバースト呼のシグナリングメッセージ
１つの実施形態において、送話者が認識する、休止状態からの起動の実合計時間およびＰＴＴ待ち時間は、ショートデータバースト（ＳＤＢ）メッセージを使用することによって、相当に低減されうる。これは、例えば、“TIA/EIA/IS-2000 Standard for cdma2000 Spread Spectrum System”（以下では、“cdma2000標準規格”と呼ばれる）に与えられている。１つの実施形態において、ＳＤＢメッセージは、専用物理チャネル（例えば、順方向基礎チャネル（forward fundamental channel, FCH）または順方向専用共通制御チャネル（forward dedicated common control channel, F-DCCH））、あるいは共通物理チャネル（例えば、逆方向アクセスチャネル（reverse access channel, R-ACH）、逆方向拡張アクセスチャネル（reverse enhanced access channel, R-EACH）、順方向共通制御チャネル（forward common control channel, F-CCCH）、またはページングチャネル（paging channel, PCH））上で送られる。ＳＤＢメッセージは、無線バーストプロトコル（radio burst protocol, RBP）によって移送され、適切な使用可能な物理層チャネル上へマップされうる。ＳＤＢメッセージは、任意のＩＰトラヒックを送り、共通物理チャネル上で送られうるので、発呼側クライアントの移動局が専用トラヒックチャネルをもたないとき、ＳＤＢメッセージは、グループ呼のシグナリングを交換するための機構を用意する。
【０１３４】
移動局が生成する呼シグナリングメッセージ
１つの実施形態において、メディアシグナリングメッセージは、逆方向リンクまたは移動局が生成するリンク上でＩＰデータグラムを送りうる。ユーザがフロアを要求し、かつ専用逆方向トラヒックチャネルが直ぐに使用可能でないときは必ず、クライアントの移動局は直ちにＭＣＵへ知らせうる。クライアントの移動局が全専用トラヒックチャネルを切断していると仮定すると、クライアントの移動局は、直ちに、無線インフラストラクチャの逆方向共通チャネル上でフロア制御要求を、ＭＣＵを中継して、送りうる。例えば、専用逆方向チャネルが使用可能でないときは、逆方向アクセスチャネルまたは逆方向拡張アクセスチャネルの何れかを使用して、このようなメッセージを送ってもよい。１つの実施形態において、クライアントの移動局は、フロア要求メッセージを、ＳＤＢメッセージとして、ＭＣＵへ伝送しうる。
【０１３５】
図４を参照すると、１つの実施形態において、クライアントＭＳは、専用トラヒックチャネルを再設定する前に、アクセスチャネルまたは拡張アクセスチャネルのような、逆方向共通チャネル上で、ＰＴＴフロア要求404を送りうる。１つの実施形態において、クライアントＭＳは、何れのチャネルが使用されているかに関係なく、ＳＤＢメッセージで、ＰＴＴフロア要求404を送りうる。
【０１３６】
例えば、クライアントＭＳは、例えば、“サービスオプション３３の再生成”を行うことによって、専用トラヒックチャネルの再設定を開始しうる。クライアントＭＳは、無線リンクプロトコル（ＲＬＰ）の同期化も開始しうる。１つの実施形態において、クライアントＭＳは、専用トラヒックチャネルを再設定し、かつＰＴＴフロア要求404を送ることと並行して、ＲＬＰを適切に同期させうる。
【０１３７】
したがって、移動局がアクティブな専用トラヒックチャネルをもたないとき、使用可能な逆方向共通チャネルおよび／またはＳＤＢの特徴を使用して、フロア制御要求をＣＭへ送ることにより、参加している移動局を起動するのに必要な全時間を低減する。送話者の順方向トラヒックチャネルが再設定されるまで、送話者のクライアントは、フロア要求が譲与されたという確認を受信しないが、参加している受話者を起動し始めることをＣＭへ迅速に知らせることができ、全体的な待ち時間が低減する。
【０１３８】
図４を参照すると、無線インフラストラクチャは、ＰＴＴフロア制御要求404をパケットデータ供給ノード（ＰＤＳＮ）を経由して、ＭＣＵへ送りうる。１つの実施形態において、ＭＣＵは、フロア制御要求を受信した後で、要求の調停、目標の参加者（受話者）へのメディアシグナリング起動メッセージ（トリガ）のバースト、および／または、参加者（受話者）のトラヒックチャネルの再設定のトリガを行いうる414。ＭＣＵは、ＰＴＴフロア要求を譲与すると、ＰＴＴフロア譲与408をクライアントＭＳへ送りうる。１つの実施形態において、クライアントの専用トラヒックチャネルが、まだ再設定されていないときは、順方向ページングチャネルおよび順方向共通チャネルのような、使用可能な順方向共通チャネル上で、ＰＴＴフロア譲与408をクライアントＭＳへ送りうる。１つの実施形態において、インフラストラクチャは、何れのチャネルが使用されるかに関係なく、ＰＴＴフロア譲与408をクライアントＭＳへ送りう
１つの実施形態において、ＭＣＵは、ＰＴＴフロア制御要求に応答する前に、休止状態応答タイマーが切れるのを待ちうる。グループ休止状態応答タイマーがゼロに設定されるときは、ＣＭは、フロア制御要求に直ちに応答しうる。１つの実施形態において、クライアントＭＳは、そのトラヒックチャネルの再設定およびＲＬＰの同期化を完了すると、（クライアントＭＳ内にバッファリングされている412）メディアをＭＣＵへ送りうる416。
【０１３９】
ネットワークが生成する呼シグナリングメッセージ
１つの実施形態において、ＭＣＵは、フロア制御要求を受信した後で、メディアシグナリング起動メッセージを目標の参加者（受話者）のグループへバーストし、参加者（受話者）のトラヒックチャネルの再設定をトリガしうる。グループ休止状態応答タイマーがゼロに設定されると、ＭＣＵは、フロア制御要求に直ちに応答しうる。１つの実施形態において、送話者が、ＰＴＴ要求を送って直ぐに、トラヒックチャネルを再設定し始めるとき、並行して発呼者と受話者とのトラヒックチャネルが適切に再設定されうる。
【０１４０】
図４を参照すると、ＭＣＵは、ＰＴＴフロア制御要求を受信した後で、目標の受話者へ起動トリガを送りうる414。ＭＣＵは、パケットデータセッションが、目標の移動局において存在し、かつトリガパケットを適切なインフラストラクチャ要素、例えば、基地局へ送るかどうかを判断しうる。インフラストラクチャは、各個々の目標のＭＳへページングして、その専用トラヒックチャネルを再設定し始めうる。その後で、例えば、目標のＭＳは、例えば、“サービスオプション３３の再生成”を行うことによって、その専用トラヒックチャネルを再設定し始めうる。目標のＭＳは、無線リンクプロトコル（ＲＬＰ）の同期化も開始しうる。１つの実施形態において、目標のＭＳは、その専用トラヒックチャネルを再設定し、クライアントＭＳが行うのと同じ機能を用いて、並行して、ＲＬＰを適切に同期させうる。
【０１４１】
１つの実施形態において、目標のＭＳは、その専用トラヒックチャネルの再設定およびそのＲＬＰの同期化を完了した後で、目標のＭＳがメディアを受信する準備ができたことを示す起動応答をＭＣＵへ送りうる422。ＭＣＵは、ＭＣＵにおいてバッファリングされている418メディアを目標のＭＳへ送る420前に、送話者のアナウンスメントをクライアントＭＳへ送りうる。
【０１４２】
１つの実施形態において、ＭＣＵは、目標の受話者のトラヒックチャネルがまだ再設定されていないとき、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な共通順方向チャネル上で、起動トリガを目標の受話者へ送りうる414。１つの実施形態において、ＭＣＵは、何れのチャネルが使用されているかに関係なく、起動トリガをＳＤＢの形で目標の受話者へ送りうる414。ＰＴＴフロア制御要求が、ＳＤＢメッセージとして、送話者の逆方向共通チャネル上で送られ、目標のグループの休止状態応答タイマが、ＭＣＵにおいてゼロに設定されるときは、送話者のクライアントにおける実際のＰＴＴ待ち時間は、逆方向リンク上でＳＤＢ要求メッセージを送り、その後で、順方向リンク上でＳＤＢ応答メッセージを送るのにかかる時間に低減されうる。
【０１４３】
呼シグナリングメッセージのためのネットワークインターフェイス
何れのネットワークが生成する特定のトラヒック、例えば、ＳＤＢペイロードが、専用トラヒックチャネルをもたないアイドル状態の移動局へ送られるかを判断するために、このような特定のトラヒックを他のトラヒックと区別するための、いくつかのインフラストラクチャのポリシーまたはインターフェイスが実行されうる。
【０１４４】
第１の実施形態において、ＳＤＢメッセージは、制限されたユーザペイロードを保持するので、ＩＰデータグラムは、そのサイズに基づいてフィルターにかけられうる。所定のサイズ制限よりも小さいＩＰデータグラムは、専用トラヒックチャネルをもたない移動局へ送られるとき、ＳＤＢメッセージとして送られる。アプリケーションフロア要求応答メッセージが非常に小さい、例えば、ＩＰヘッダを含めて、３４バイトであるときは、グループ通信システムは、このようなフィルターを使用しうる。
【０１４５】
第２の実施形態において、インフラストラクチャのベンダは、移動局へ送られるＩＰトラヒックをカプセル化するためのＩＰベースのサービスを定めうる。専用トラヒックチャネルをもたないと疑われる移動局へ送るためのこのサービスのために、このサービスを知っているＩＰサーバは、小さいＩＰ、例えば、ＵＤＰのデータグラムを、ＩＰヘッダと共に適切にカプセル化して送りうる。グループ通信システムは、このサービスを使用して、フロア要求応答メッセージを、例えば、ＳＤＢの形で、要求しているクライアントＭＳへ送ることを、インフラストラクチャに示す。ＳＤＢトラヒックと、保留中のページまたはサービス生成要求との調整も、ユーザトラヒックの迅速で確実な伝送を保証するのに重要である。
【０１４６】
第３の実施形態において、ＩＰサーバは、ＩＰヘッダをもつ特定のＩＰ、例えばＵＤＰのデータグラムを、専用トラヒックチャネルをもたないと疑われる移動局へ送りうる。ＩＰサーバは、例えば、ＩＰヘッダの特定の値を示すことによって、ＩＰデータグラムをクライアントＭＳへ送るようにインフラストラクチャに命令するためのタグを付けうる。グループ通信システムは、このサービスを使用して、例えば、フロア要求メッセージをＳＤＢの形で、要求しているクライアントＭＳへ伝送することを、インフラストラクチャに示す。第３の実施形態では、特定のＩＰデータグラム、例えば、ＳＤＢメッセージを伝送するために、ＵＤＰまたはＴＣＰのポート範囲を確保しうる。
【０１４７】
移動局が開始するサービス生成およびページング
１つの実施形態において、クライアントは、フロア制御要求404をＳＤＢの形で送り、その直ぐ後で、このトラヒックを迅速に再設定するために、サービス生成要求を、無線（例えば、ＣＤＭＡ）のインフラストラクチャへ送りうる。しかしながら、休止状態応答タイマーが小さい値に設定されるときは、ＲＤはフロア制御要求に迅速に応答し、応答408をクライアントへ伝送しうる。この応答が、サービス生成トランザクションの早い段階の間に、インフラストラクチャに到達するときは、インフラストラクチャは、送話者のＭＳがアクティブなトラヒックチャネルをもっていないことに気付いて、送話者のＭＳへの応答をページングすることを試みる。しかしながら、このページング動作は、既に進行中のサービス生成トランザクションを中止することがある。１つの実施形態において、送話者のＭＳはページに応答して、フロア制御応答メッセージが送話者へ伝送されることを確実にして、サービス生成を再び要求するが、最初のサービス生成の試みを中止した結果として、送話者のトラヒックチャネルを再設定するときに、不要な遅延を経験する。
【０１４８】
第１の実施形態において、サービス生成処理とページングとの競合状況を避けるために、ＲＤが、フロア制御要求404に直ちに応答しないように構成してもよい。したがって、サービス生成処理が完了した後で、ＭＣＵが応答408を送話者のＭＳへ送るように、休止状態応答タイマーを調節してもよい。
【０１４９】
第２の実施形態において、応答408を受信するＰＤＳＮと、送話者のサービス生成要求に応答する移動交換局（ＭＳＣ）とを調整する。すなわち、ＰＤＳＮが、応答408がインフラストラクチャに到達したときに、送話者のＭＳにおけるパケットデータサービス生成処理が既に進行していると判断すると、ＭＳＣは、送話者のＭＳのページングを遅らせる。ＰＤＳＮは応答をキャッシュし、サービス生成処理が完了すると、送話者の移動局の順方向トラヒックチャネル上でそれを送る。その代りに、ＭＳＣは、サービス生成処理がまだ進行中であるときに、応答をＳＤＢメッセージとして送話者のＭＳへ送ってもよい。
【０１５０】
第３の実施形態では、送話者のＭＳが、フロア制御要求に対する応答を受信するまで、サービス生成要求を発行しないことによって、送話者のＭＳは競合状態を避けうる。１つの実施形態において、送話者のＭＳは、アクティブな専用トラヒックチャネルをもたないので、ＭＣＵは、順方向ページングチャネルおよび順方向共通制御チャネルのような、いくつかの使用可能な順方向共通チャネル上で、送話者のＭＳへ応答を送りうる。１つの実施形態では、ＭＣＵは、応答をＳＤＢの形で送話者のＭＳへ送りうる。ＭＣＵによって送られた起動要求が、受話者の移動局のトラヒックチャネルの再アクティベーションをトリガするのと同じやり方で、送話者のＭＳは、ＲＤが生成したフロア制御応答に依存して、トラヒックチャネルの再アクティベーションをトリガする。移動局が開始するサービス生成と、ネットワークが開始する移動局のページングが同期する潜在性を避けると、競合状態は避けられる。
【０１５１】
ネットワークが開始したパケットデータトリガのキャッシング
起動トリガ414を含むＩＰデータグラムであって、無線（例えば、ＣＤＭＡ）のインフラストラクチャに到達し、かつ専用トラヒックチャネルをもたない受話者の移動局へ送られるＩＰデータグラムは、一般にはネットワークによって、とくに無線インフラストラクチャによって損われる。１つの実施形態において、受話者の移動局へ送られる起動トリガ414は、受話者の応答またはグループの起動タイマーが切れるまで、所定のスケジュールにしたがって、しつこく再送される。例えば、起動トリガ414は、５００ミリ秒ごとに再送されうる。しかしながら、起動トリガ414をこのレートで再送すると、受話者のトラヒックチャネルが再設定されてから、その受話者へ送られる次の起動トリガがインフラストラクチャに到達するときまでに、最大で５００ミリ秒まで、または平均で２５０ミリ秒の遅延が生じうる。
【０１５２】
１つの実施形態において、ネットワーク内のインフラストラクチャまたは別のエンティティは、ＭＣＵによって送られた起動トリガ414をキャッシュして、目標のＭＳがそのトラヒックを設定すると直ぐに、目標のＭＳへそれを送りうる。したがって、ＭＣＵが起動要求を再送する必要がなくなり、休止状態から起動するための時間の合計が低減する。起動トリガ414をキャッシュすると、例えば、５００ミリ秒のレートでそれを再送することとは対照的に、休止状態から起動する時間の合計からの５００ミリ秒までの遅延がなくなりうる。
【０１５３】
メディアのバッファリング
１つの実施形態において、ユーザは、フロア制御要求後に、クライアントと受話者との専用チャネルが再設定される前に、メディアをバッファリングすることによって、話し始めるのを許可されうる。システムでは、送話者のスピーチをバッファリングすることによって、受話者のトラヒックチャネルが完全に再設定される前に、送話者が話し始めるのを許可する。したがって、送話者はより早く話し始めることができ、見掛けのＰＴＴ待ち時間が低減される。受話者はＰＴＴ待ち時間を経験しないので、この経験は影響されない。すなわち、ＰＴＴ待ち時間は送話者からシステムの他の部分へ移される。送話者は、ちょうど、自分の第１のトークスパートに対する応答を受話者から受信するまで待つが、既に記載したように、送話者は自分の第１のトークスパートに対する応答が、自分がアクティブな会話に加わっている間に始まる次のトークスパートに対する応答よりも長くかかることを既に予測している。送話者の第１のトークスパートのバッファリングは、ＭＣＵ側で行なうことも、クライアントＭＳ側で行なうこともできる。
【０１５４】
ＭＣＵ側のバッファリング
１つの実施形態において、ＭＣＵは、送話者の第１のトークスパートをバッファリングしうる。ユーザがＰＴＴボタンを押し、ユーザのトラヒックチャネルが再設定された後で、ユーザはＭＣＵと通信することができる。このとき、受話者のトラヒックチャネルはまだ準備ができていないので、ＭＣＵは、目標の受話者への将来の伝送のために、送話者のスピーチをバッファリングする418。ＭＣＵのバッファリングにより、送話者が判断する見掛けのＰＴＴ待ち時間は、送話者のトラヒックチャネルを生成するのにかかるおおよその時間に低減しうる。図１７は、１つの実施形態にしたがうＭＣＵ側のバッファリングを示しており、次に記載する：
（１）発信者と目標のトラヒックチャネルが休止状態であるとき、進行中の呼はない；
（２）ユーザは、ＰＴＴボタンを押す。サーバは、クライアントから、“グループ呼セットアップ”要求を受信する；
（３）クライアントがサーバから“セットアップ進行中”の応答を受信した後か、または構成可能な遅延（１秒）の後で、フロアはユーザへ譲与され、ユーザのメディアをバッファリングし始める；
（４）サーバは、目標のパケットデータトラヒックチャネルを再設定するための処理を開始する；
（５）サーバは、“グループ呼アナウンスメント”メッセージをＳＤＢによってクライアントへ送る；
（６）クライアントは、正常にトラヒックチャネルを再設定し、バッファリングされたメディアをサーバへ送り始める；
（７）クライアントは、メディアをサーバへ送る；
（８）目標のトラヒックチャネルは再設定される（“目標の応答閾値”が満たされる）；
（９）ユーザは、ＰＴＴボタンを放す。クライアントは、メディアをバッファリングすることを止める；
（１０）クライアントは、バッファリングされたメディアをサーバへ送ることを止め、サーバによるフロアの解放を要求する；
（１１）サーバは、フロア解放の肯定応答をクライアントへ送る。
【０１５５】
クライアント側のバッファリング
１つの実施形態において、見掛けの待ち時間がより短いことが望ましいとき、送話者は、自分のトラヒックチャネルが再設定される前でも、話し始めるのを許可される。クライアントＭＳは、ＭＣＵとまだ通信していないので、送話者が話し始めるための信号を生成する。送話者のトラヒックチャネルが再設定される前に、送話者が話すことを許可されるとき、クライアントＭＳはスピーチをバッファリングする412。ＣＭとの通信がまだ設定されていないので、話す許可は、“楽観的”に与えられる。図１８は、１つの実施形態にしたがうクライアント側のバッファリングを示しており、次に記載する：
（１）発信者のトラヒックチャネルが休止状態であるとき、進行中の呼はない；
（２）ユーザはＰＴＴボタンを押す。クライアントは、“グループ呼セットアップ”要求をＳＤＢによってサーバへ送る；
（３）クライアントは、パケットデータトラヒックチャネルを再設定する処理を開始する；
（４）クライアントが、サーバから、“セットアップ進行中”の応答を受信した後か、または構成可能な遅延（１秒）の後で、フロアはユーザへ譲与され、ユーザのメディアをバッファリングし始める；
（５）クライアントは、サーバから、“グループ呼アナウンスメント”メッセージをＳＤＢによって受信する；
（６）クライアントは、トラヒックチャネルを正常に再設定する；
（７）クライアントは、バッファリングされたメディアをサーバへ送る；
（８）ユーザは、ＰＴＴボタンを放す。クライアントは、メディアをバッファリングするのを止める；
（９）クライアントは、バッファリングされたメディアをサーバへ送ることを止め、サーバによるフロアの解放を要求する；
（１０）クライアントは、サーバから、フロアの解放の肯定応答を受信する。
【０１５６】
１つの実施形態において、ＭＣＵのバッファリング418とクライアント側のバッファリング412の両者は同時に行われうる。クライアント側のバッファリングは、見掛けのＰＴＴ待ち時間を短くすることができる。１つの実施形態において、クライアントＭＳは、メディアをバッファリングして、ユーザが経験する見掛けのＰＴＴ待ち時間を制御しうる。移動局が生成するＳＤＢとクライアント側のメディアのバッファリングとの組合せは、アクティブなトラヒックチャネルを再設定することに伴う遅延を低減する。
【０１５７】
したがって、開示されている実施形態では、少なくとも２つのタイプのディスパッチ呼を支援するディスパッチモデル、すなわちチャットルームモデルとアドホック・モデルを与える。チャットルームモデルでは、グループは予め定められ、ディスパッチサーバ上に記憶される。しかしながら、アドホック・モデルでは、グループは定義または変更、あるいはこの両者が実時間で行われる。
【０１５８】
開示されている実施形態は、さらに加えて、移動局が休止状態であり、かつトラヒックチャネルがアクティブでないときでも、グループ呼シグナリングを交換することによって、休止状態からの起動の実合計時間とＰＴＴ待ち時間とを相当に低減する。方法および装置は、ショートデータバースト（ＳＤＢ）メッセージのシグナリングを使用することによって、グループ呼シグナリングを交換する。方法および装置は、送話者の移動局と休止状態の受話者の移動局との専用トラヒックチャネルを効果的に並行して再設定する。
【０１５９】
別の実施形態では、ネットワークが開始した、目標の受話者への起動トリガをキャッシュし、かつ目標の移動局がトラヒックチャネルを再設定すると直ぐに、起動トリガを目標の移動局へ伝送することにより、グループ通信ネットワークにおける休止状態からの起動の待ち時間を低減する。
【０１６０】
別の実施形態では、グループ通信ネットワークにおいて、移動局が、サービス生成処理が完了した後で、フロア制御要求に対する応答を伝送することによって、サービス生成とページングの同時実行が避けられる。１つの実施形態では、サービス生成処理が完了しないときは、フロア制御要求に対する応答はＳＤＢの形であってもよい。１つの実施形態では、ソース通信装置へ応答を伝送した後で、ソース通信装置のサービス生成処理が開始される。
【特許請求の範囲】
【請求項１】
通信装置において、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法であって、
ユーザからメンバーリストを受信することと、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとを含む方法。
【請求項２】
通信装置において、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法を具現するコンピュータ読み出し可能メディアであって、方法が、
ユーザからメンバーリストを受信することと、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとを含むコンピュータ読み出し可能メディア。
【請求項３】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための通信装置であって、
ユーザからメンバーリストを受信するための手段と、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送るための手段とを含む通信装置。
【請求項４】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための通信装置であって、
受信機と、
送信機と、
受信機および送信機に通信上で接続されるプロセッサであって、
ユーザからメンバーリストを受信すること、および、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることができるプロセッサとを含む通信装置。
【請求項５】
サーバにおいて、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法であって、
アクティブなグループ呼にメンバーリストを加える要求を受信することと、
アクティブなグループ呼にメンバーリストを加えることとを含む方法。
【請求項６】
グループ呼をメンバリスト内の各メンバーにアナウンスすることをさらに含む請求項５記載の方法。
【請求項７】
グループ呼に参加したいメンバーリスト内のメンバーから肯定応答を受信することと、
メディアをメンバーへ発送することとをさらに含む請求項６記載の方法。
【請求項８】
前記メディアの発送前に、トラヒックチャネルを再設定するようにメンバーを促すことをさらに含む請求項７記載の方法。
【請求項９】
トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングすることをさらに含む請求項８記載の方法。
【請求項１０】
アナウンスが、無線ネットワークの順方向共通チャネル上でメッセージを伝送することを含む請求項６記載の方法。
【請求項１１】
伝送が、無線ネットワークの順方向ページングチャネル（forward paging channel, F-PCH）上でメッセージを伝送することを含む請求項１０記載の方法。
【請求項１２】
伝送が、無線ネットワークの順方向共通制御チャネル（forward common control channel, F-CCCH）上でメッセージを伝送することを含む請求項１０記載の方法。
【請求項１３】
伝送が、メッセージをショートデータバースト（short data burst, SDB）の形で伝送することを含む請求項１０記載の方法。
【請求項１４】
サーバにおいて、グループ通信ネットワークにおけるグループ呼を開始するための方法を具現するコンピュータ読み出し可能メディアであって、方法が、
メンバーリストをアクティブなグループ呼に加える要求を受信することと、
メンバーリストをアクティブなグループ呼に加えることとを含むコンピュータ読み出し可能メディア。
【請求項１５】
方法が、メンバーリスト内の各メンバーへグループ呼をアナウンスすることをさらに含む請求項１４記載のコンピュータ読み出し可能メディア。
【請求項１６】
方法が、
グループ呼に参加したいメンバーリスト内の各メンバーから肯定応答を受信することと、
メディアをメンバーへ発送することとをさらに含む請求項１５記載のコンピュータ読み出し可能メディア。
【請求項１７】
トラヒックチャネルを再設定するようにメンバーを促すことをさらに含む請求項１６記載のコンピュータ読み出し可能メディア。
【請求項１８】
方法が、トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングすることをさらに含む請求項１７記載のコンピュータ読み出し可能メディア。
【請求項１９】
アナウンスが、無線ネットワークの順方向共通チャネル上でメッセージを伝送することを含む請求項１５記載のコンピュータ読み出し可能メディア。
【請求項２０】
伝送が、無線ネットワークの順方向ページングチャネル（Ｆ−ＰＣＨ）上でメッセージを伝送することを含む請求項１９記載のコンピュータ読み出し可能メディア。
【請求項２１】
伝送が、無線ネットワークの順方向共通制御チャネル（Ｆ−ＣＣＣＨ）上でメッセージを伝送することを含む請求項１９記載のコンピュータ読み出し可能メディア。
【請求項２２】
伝送が、メッセージをショートデータバースト（ＳＤＢ）の形で伝送することを含む請求項１９記載のコンピュータ読み出し可能メディア。
【請求項２３】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるためのサーバであって、
アクティブなグループ呼にメンバーリストを加える要求を受信するための手段と、
アクティブなグループ呼にメンバーリストを加えるための手段とを含むサーバ。
【請求項２４】
メンバリスト内の各メンバーへグループ呼をアナウンスするための手段をさらに含む請求項２３記載のサーバ。
【請求項２５】
グループ呼に参加したいメンバーから肯定応答を受信するための手段と、
メディアをメンバーへ発送するための手段とをさらに含む請求項２４記載のサーバ。
【請求項２６】
トラヒックチャネルを再設定するようにメンバーを促すための手段をさらに含む請求項２５記載のサーバ。
【請求項２７】
トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングするための手段をさらに含む請求項２６記載のサーバ。
【請求項２８】
アナウンス手段が、無線ネットワークの順方向共通チャネル上でメッセージを伝送する手段を含む請求項２４記載のサーバ。
【請求項２９】
伝送手段が、無線ネットワークの順方向ページングチャネル（Ｆ−ＰＣＨ）上でメッセージを伝送するための手段を含む請求項２８記載のサーバ。
【請求項３０】
伝送手段が、無線ネットワークの順方向共通制御チャネル（Ｆ−ＣＣＣＨ）上でメッセージを伝送するための手段を含む請求項２８記載のサーバ。
【請求項３１】
伝送手段が、メッセージをショートデータバースト（ＳＤＢ）の形で伝送するための手段を含む請求項２８記載のサーバ。
【請求項３２】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるためのサーバであって、
受信機と、
送信機と、
受信機および送信機に通信上で接続されるプロセッサであって、
アクティブなグループ呼にメンバーリストを加える要求を受信すること、および、
アクティブなグループ呼にメンバーリストを加えることができるプロセッサとを含むサーバ。
【請求項３３】
プロセッサが、さらに加えて、メンバーリスト内の各メンバーへグループ呼をアナウンスすることができる請求項３２記載のサーバ。
【請求項３４】
プロセッサが、さらに加えて、
グループ呼に参加したいメンバーから肯定応答を受信することと、
メディアをメンバーへ発送することとができる請求項３３記載のサーバ。
【請求項３５】
トラヒックチャネルを設定するようにメンバーを促すことをさらに含む請求項３４記載のサーバ。
【請求項３６】
プロセッサが、さらに加えて、トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングすることができる請求項３５記載のサーバ。
【請求項３７】
アナウンスが、無線ネットワークの順方向共通チャネル上でメッセージを伝送することを含む請求項３６記載のサーバ。
【請求項３８】
伝送が、無線ネットワークの順方向ページングチャネル（Ｆ−ＰＣＨ）上でメッセージを伝送することを含む請求項３７記載のサーバ。
【請求項３９】
伝送が、無線ネットワークの順方向共通制御チャネル（Ｆ−ＣＣＣＨ）上でメッセージを伝送することを含む請求項３７記載のサーバ。
【請求項４０】
伝送が、メッセージをショートデータバースト（ＳＤＢ）の形で伝送することを含む請求項３７記載のサーバ。
【請求項４１】
グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバであって、
メンバーリストに基づいてアクティブなグループ呼に新しいメンバーを加える要求を受信するディスパッチャと、
メンバーリストに基づいてグループ呼をアナウンスする制御装置とを含むサーバ。
【請求項４２】
ディスパッチャーが、メンバリスト内の各メンバーの位置情報を判断する請求項４１記載のサーバ。
【請求項４３】
制御装置が、局所領域内に位置を特定されたメンバーのための局所制御装置を含む請求項４２記載のサーバ。
【請求項４４】
制御装置が、局所領域の外に位置を特定されたメンバーのための遠隔制御装置を含む請求項４２記載のサーバ。
【請求項１】
通信装置において、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法であって、
ユーザからメンバーリストを受信することと、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとを含む方法。
【請求項２】
通信装置において、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法を具現するコンピュータ読み出し可能メディアであって、方法が、
ユーザからメンバーリストを受信することと、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることとを含むコンピュータ読み出し可能メディア。
【請求項３】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための通信装置であって、
ユーザからメンバーリストを受信するための手段と、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送るための手段とを含む通信装置。
【請求項４】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための通信装置であって、
受信機と、
送信機と、
受信機および送信機に通信上で接続されるプロセッサであって、
ユーザからメンバーリストを受信すること、および、
アクティブなグループ呼にメンバーリストを加える要求をサーバへ送ることができるプロセッサとを含む通信装置。
【請求項５】
サーバにおいて、グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるための方法であって、
アクティブなグループ呼にメンバーリストを加える要求を受信することと、
アクティブなグループ呼にメンバーリストを加えることとを含む方法。
【請求項６】
グループ呼をメンバリスト内の各メンバーにアナウンスすることをさらに含む請求項５記載の方法。
【請求項７】
グループ呼に参加したいメンバーリスト内のメンバーから肯定応答を受信することと、
メディアをメンバーへ発送することとをさらに含む請求項６記載の方法。
【請求項８】
前記メディアの発送前に、トラヒックチャネルを再設定するようにメンバーを促すことをさらに含む請求項７記載の方法。
【請求項９】
トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングすることをさらに含む請求項８記載の方法。
【請求項１０】
アナウンスが、無線ネットワークの順方向共通チャネル上でメッセージを伝送することを含む請求項６記載の方法。
【請求項１１】
伝送が、無線ネットワークの順方向ページングチャネル（forward paging channel, F-PCH）上でメッセージを伝送することを含む請求項１０記載の方法。
【請求項１２】
伝送が、無線ネットワークの順方向共通制御チャネル（forward common control channel, F-CCCH）上でメッセージを伝送することを含む請求項１０記載の方法。
【請求項１３】
伝送が、メッセージをショートデータバースト（short data burst, SDB）の形で伝送することを含む請求項１０記載の方法。
【請求項１４】
サーバにおいて、グループ通信ネットワークにおけるグループ呼を開始するための方法を具現するコンピュータ読み出し可能メディアであって、方法が、
メンバーリストをアクティブなグループ呼に加える要求を受信することと、
メンバーリストをアクティブなグループ呼に加えることとを含むコンピュータ読み出し可能メディア。
【請求項１５】
方法が、メンバーリスト内の各メンバーへグループ呼をアナウンスすることをさらに含む請求項１４記載のコンピュータ読み出し可能メディア。
【請求項１６】
方法が、
グループ呼に参加したいメンバーリスト内の各メンバーから肯定応答を受信することと、
メディアをメンバーへ発送することとをさらに含む請求項１５記載のコンピュータ読み出し可能メディア。
【請求項１７】
トラヒックチャネルを再設定するようにメンバーを促すことをさらに含む請求項１６記載のコンピュータ読み出し可能メディア。
【請求項１８】
方法が、トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングすることをさらに含む請求項１７記載のコンピュータ読み出し可能メディア。
【請求項１９】
アナウンスが、無線ネットワークの順方向共通チャネル上でメッセージを伝送することを含む請求項１５記載のコンピュータ読み出し可能メディア。
【請求項２０】
伝送が、無線ネットワークの順方向ページングチャネル（Ｆ−ＰＣＨ）上でメッセージを伝送することを含む請求項１９記載のコンピュータ読み出し可能メディア。
【請求項２１】
伝送が、無線ネットワークの順方向共通制御チャネル（Ｆ−ＣＣＣＨ）上でメッセージを伝送することを含む請求項１９記載のコンピュータ読み出し可能メディア。
【請求項２２】
伝送が、メッセージをショートデータバースト（ＳＤＢ）の形で伝送することを含む請求項１９記載のコンピュータ読み出し可能メディア。
【請求項２３】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるためのサーバであって、
アクティブなグループ呼にメンバーリストを加える要求を受信するための手段と、
アクティブなグループ呼にメンバーリストを加えるための手段とを含むサーバ。
【請求項２４】
メンバリスト内の各メンバーへグループ呼をアナウンスするための手段をさらに含む請求項２３記載のサーバ。
【請求項２５】
グループ呼に参加したいメンバーから肯定応答を受信するための手段と、
メディアをメンバーへ発送するための手段とをさらに含む請求項２４記載のサーバ。
【請求項２６】
トラヒックチャネルを再設定するようにメンバーを促すための手段をさらに含む請求項２５記載のサーバ。
【請求項２７】
トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングするための手段をさらに含む請求項２６記載のサーバ。
【請求項２８】
アナウンス手段が、無線ネットワークの順方向共通チャネル上でメッセージを伝送する手段を含む請求項２４記載のサーバ。
【請求項２９】
伝送手段が、無線ネットワークの順方向ページングチャネル（Ｆ−ＰＣＨ）上でメッセージを伝送するための手段を含む請求項２８記載のサーバ。
【請求項３０】
伝送手段が、無線ネットワークの順方向共通制御チャネル（Ｆ−ＣＣＣＨ）上でメッセージを伝送するための手段を含む請求項２８記載のサーバ。
【請求項３１】
伝送手段が、メッセージをショートデータバースト（ＳＤＢ）の形で伝送するための手段を含む請求項２８記載のサーバ。
【請求項３２】
グループ通信ネットワークにおけるアクティブなグループ呼に新しいメンバーを加えるためのサーバであって、
受信機と、
送信機と、
受信機および送信機に通信上で接続されるプロセッサであって、
アクティブなグループ呼にメンバーリストを加える要求を受信すること、および、
アクティブなグループ呼にメンバーリストを加えることができるプロセッサとを含むサーバ。
【請求項３３】
プロセッサが、さらに加えて、メンバーリスト内の各メンバーへグループ呼をアナウンスすることができる請求項３２記載のサーバ。
【請求項３４】
プロセッサが、さらに加えて、
グループ呼に参加したいメンバーから肯定応答を受信することと、
メディアをメンバーへ発送することとができる請求項３３記載のサーバ。
【請求項３５】
トラヒックチャネルを設定するようにメンバーを促すことをさらに含む請求項３４記載のサーバ。
【請求項３６】
プロセッサが、さらに加えて、トラヒックチャネルが再設定された後でメンバーへ伝送するためにメディアをバッファリングすることができる請求項３５記載のサーバ。
【請求項３７】
アナウンスが、無線ネットワークの順方向共通チャネル上でメッセージを伝送することを含む請求項３６記載のサーバ。
【請求項３８】
伝送が、無線ネットワークの順方向ページングチャネル（Ｆ−ＰＣＨ）上でメッセージを伝送することを含む請求項３７記載のサーバ。
【請求項３９】
伝送が、無線ネットワークの順方向共通制御チャネル（Ｆ−ＣＣＣＨ）上でメッセージを伝送することを含む請求項３７記載のサーバ。
【請求項４０】
伝送が、メッセージをショートデータバースト（ＳＤＢ）の形で伝送することを含む請求項３７記載のサーバ。
【請求項４１】
グループ通信ネットワークにおけるアクティブなグループ呼にメンバーを加えるためのサーバであって、
メンバーリストに基づいてアクティブなグループ呼に新しいメンバーを加える要求を受信するディスパッチャと、
メンバーリストに基づいてグループ呼をアナウンスする制御装置とを含むサーバ。
【請求項４２】
ディスパッチャーが、メンバリスト内の各メンバーの位置情報を判断する請求項４１記載のサーバ。
【請求項４３】
制御装置が、局所領域内に位置を特定されたメンバーのための局所制御装置を含む請求項４２記載のサーバ。
【請求項４４】
制御装置が、局所領域の外に位置を特定されたメンバーのための遠隔制御装置を含む請求項４２記載のサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１０−１５８０３９（Ｐ２０１０−１５８０３９Ａ）
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２３９９７（Ｐ２０１０−２３９９７）
【出願日】平成２２年２月５日（２０１０．２．５）
【分割の表示】特願２００３−５６８９１０（Ｐ２００３−５６８９１０）の分割
【原出願日】平成１５年２月１２日（２００３．２．１２）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願番号】特願２０１０−２３９９７（Ｐ２０１０−２３９９７）
【出願日】平成２２年２月５日（２０１０．２．５）
【分割の表示】特願２００３−５６８９１０（Ｐ２００３−５６８９１０）の分割
【原出願日】平成１５年２月１２日（２００３．２．１２）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]