(57)【要約】【課題】話し手が経験するＰＴＴ待ち時間と、モバイルに参加するトラフィックチャンネルの再確立に必要な合計時間との両方を低減すること。【解決手段】本発明は、グループ通信ネットワーク１００におけるプッシュトーク通信デバイスに効率的な休止モードを提供する方法及び装置であって、専用のトラフィックチャンネルを保持している通信デバイス１０２，１０４，１０６が、予め定めた第１の期間の間、不動作状態にあったか否かを判定し、そうである場合には通信デバイスを制御ホールドモードにする。ここで、この通信デバイスは、専用のトラフィックチャンネルを維持している。また、専用のトラフィックチャンネルを解放した通信デバイスが、予め定めた第２の期間の間、制御ホールドモードにあるか否かを判定し、そうである場合には、この通信デバイスを休止モードにする。【選択図】図１
2004533170.tif 000002
【特許請求の範囲】
【請求項１】
グループ通信ネットワークで動作している通信デバイスにおいて、前記通信デバイスを休止モードにする方法であって、
前記通信デバイスが、予め定めた第１の期間の間、不動作状態にあったか否かを判定し、
前記通信デバイスが、前記第１の期間の間、不動作状態にあったと判定された場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを制御ホールドモードにし、
前記通信デバイスが、予め定めた第２の期間の間、前記制御ホールドモードにあったか否かを判定し、
前記通信デバイスが、前記第２の期間の間、制御ホールドモードにあったと判定された場合には、専用のトラフィックチャンネルを解放した前記通信デバイスを休止モードにするようにした方法。
【請求項２】
請求項１に記載の方法において、
前記通信デバイスが、前記第２の期間の間、前記制御ホールドモードになかったと判定された場合には、
更に、前記通信デバイスがメディアを受信したか、または前記通信デバイスがグループ呼出を要求した場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを動作モードに戻すようにした方法。
【請求項３】
グループ通信ネットワークで動作している通信デバイスにおいて、前記通信デバイスを休止モードにする方法であって、
前記通信デバイスが、予め定めた期間の間、不動作状態にあったか否かを判定し、
前記通信デバイスが前記期間の間、不動作状態にあったと判定された場合には、前記通信デバイスを前記休止モードにし、
前記休止モードに入る前に、前記通信デバイスにサービス設定の状態をキャッシュさせるようにした方法。
【請求項４】
請求項３に記載の方法において、
前記休止モードにする場合、更に、前記通信デバイスに、専用のトラフィックチャンネルを解放させるようにした方法。
【請求項５】
グループ通信ネットワークで動作している通信デバイスにおいて、前記通信デバイスを休止モードにする方法を具現化しているコンピュータ読み取り可能な媒体であって、
前記方法は、
前記通信デバイスが、予め定めた第１の期間の間、不動作状態にあったか否かを判定し、
前記通信デバイスが、前記第１の期間の間、不動作状態にあったと判定された場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを制御ホールドモードにし、
前記通信デバイスが、予め定めた第２の期間の間、前記制御ホールドモードにあったか否かを判定し、
前記通信デバイスが、前記第２の期間の間、制御ホールドモードにあったと判定された場合には、専用のトラフィックチャンネルを解放した前記通信デバイスを休止モードにする媒体。
【請求項６】
請求項５に記載の媒体において、
前記通信デバイスが、前記第２の期間の間、前記制御ホールドモードになかったと判定された場合には、
前記方法は更に、前記通信デバイスがメディアを受信したか、または前記通信デバイスがグループ呼出を要求した場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを動作モードに戻すようにする媒体。
【請求項７】
グループ通信ネットワークで動作している通信デバイスにおいて、前記通信デバイスを休止モードにする方法を具現化しているコンピュータ読み取り可能な媒体であって、
前記方法は、
前記通信デバイスが、予め定めた期間の間、不動作状態にあったか否かを判定し、
前記通信デバイスが、期間の間、不動作状態にあったと判定された場合には、前記通信デバイスを前記休止モードにし、
前記休止モードに入る前に、前記通信デバイスにサービス設定の状態をキャッシュさせるようにする媒体。
【請求項８】
請求項７に記載の媒体において、
前記方法は、前記休止モードにする場合、更に、前記通信デバイスに、専用のトラフィックチャンネルを解放させるようにした媒体。
【請求項９】
グループ通信ネットワークで動作している通信デバイスにおいて、
前記通信デバイスが、予め定めた第１の期間の間、不動作状態にあったか否かを判定する手段と、
前記通信デバイスが、前記第１の期間の間、不動作状態にあったと判定された場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを制御ホールドモードにする手段と、
前記通信デバイスが、予め定めた第２の期間の間、前記制御ホールドモードにあったか否かを判定する手段と、
前記通信デバイスが、第２の期間の間、制御ホールドモードにあったと判定された場合には、専用のトラフィックチャンネルを解放した前記通信デバイスを休止モードにする手段と
を備えた通信デバイス。
【請求項１０】
請求項９に記載の通信デバイスにおいて、
前記通信デバイスが前記第２の期間の間、前記制御ホールドモードになかったと判定された場合には、
更に、前記通信デバイスがメディアを受信したか、または前記通信デバイスがグループ呼出を要求した場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを動作モードに戻す手段を備えた通信デバイス。
【請求項１１】
グループ通信ネットワークで動作している通信デバイスにおいて、
前記通信デバイスが、予め定めた期間の間、不動作状態にあったか否かを判定する手段と、
前記通信デバイスが、前記期間の間、不動作状態にあったと判定された場合には、前記通信デバイスを前記休止モードにする手段と、
前記休止モードに入る前に、前記通信デバイスにサービス設定の状態をキャッシュさせる手段と
を備えた通信デバイス。
【請求項１２】
請求項１１に記載の通信デバイスにおいて、
前記通信デバイスを前記休止モードにする手段は、
前記通信デバイスに専用のトラフィックチャンネルを解放を解放させる手段を更に備えた通信デバイス。
【請求項１３】
休止モードを提供する通信デバイスであって、
ネットワークを通じて情報を受信する受信器と、
前記ネットワークを通じて情報を送信する送信器と、
前記受信器および前記送信器と通信可能な状態で接続されたプロセッサとを備え、
前記プロセッサは、
前記通信デバイスが、予め定めた第１の期間の間、不動作状態にあったか否かを判定し、
前記通信デバイスが、前記第１の期間の間、不動作状態にあったと判定された場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを制御ホールドモードにし、
前記通信デバイスが、予め定めた第２の期間の間、前記制御ホールドモードにあったか否かを判定し、
前記通信デバイスが、前記第２の期間の間、制御ホールドモードにあったと判定された場合には、専用のトラフィックチャンネルを解放した前記通信デバイスを休止モードにすることを可能とした通信デバイス。
【請求項１４】
請求項１３に記載の通信デバイスにおいて、
前記通信デバイスが、前記第２の期間の間、前記制御ホールドモードになかったと判定された場合には、
前記プロセッサは更に、前記通信デバイスがメディアを受信したか、または前記通信デバイスがグループ呼出を要求した場合には、専用のトラフィックチャンネルを維持している前記通信デバイスを動作モードに戻すことを可能とした通信デバイス。
【請求項１５】
休止モードを提供する通信デバイスであって、
受信器と、
送信器と、
前記受信器および前記送信器と通信可能な状態で接続されたプロセッサとを備え、
前記プロセッサは、
前記通信デバイスが、予め定めた期間の間、不動作状態にあったか否かを判定し、
前記通信デバイスが、前記期間の間、不動作状態にあったと判定された場合には、前記通信デバイスを休止モードにし、
前記休止モードに入る前に、前記通信デバイスにサービス設定の状態をキャッシュさせることを可能とした通信デバイス。
【請求項１６】
請求項１５に記載の通信デバイスにおいて、
前記通信デバイスを前記休止モードにする場合、前記通信デバイスに専用のトラフィックチャンネルを解放させるようにした通信デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ポイント対多数ポイントの通信システムに係り、更に詳しくは、グループ通信ネットワークにおけるプッシュトーク通信デバイスに、効率的な休止モードを提供する方法および装置に関する。
【背景技術】
【０００２】
迅速で効率的な１対１あるいは１対多数（グループ）の通信を念頭においた無線サービスのクラスは、長年、様々な型式のものが存在している。一般に、これらのサービスは半二重であった。このサービスでは、ユーザは、通話を開始するために、電話機や無線機の「プッシュトーク」（ＰＴＴ）ボタンを押す。ボタンを押すことは、無線機を調整することか、またはある型式のサーバを介してなされている適切なシステムにおいてユーザが「発言」を要求したことを示す。仮に、発言が許可された場合、すなわち話し手が許可された場合には、ユーザは大抵数秒間通話する。そして、ＰＴＴボタンを解放すると、他の話し手が発言を要求することができる。通信は、一般に、１人の話し手から、聞き手グループへとなされるが、１人対１人もありうる。このサービスは、従来、１人の「ディスパッチャー」が、フィールドサービス要員や、タクシー運転手などのように、グループに対して通信する必要がある場合に適用されている。したがって、「ディスパッチ」という名前は、フィールドサービス要員や、タクシー運転手などへのサービスから由来している。
【０００３】
最近、同様なサービスが、インターネットでも提供されている。それは一般に「音声チャット」として知られている。これらのサービスは、通常は、インターネットプロトコル（ＩＰ）パケット、すなわちＶｏＩＰサービスによってボーコーダフレームを中央グループチャットサーバに送信するパーソナルコンピュータアプリケーションとして実施される。あるいは、ピァツーピァサービスで、クライアントからクライアントへと送信するようにしても良い。
【０００４】
これらのサービスの主な特徴は、通信が速く、自発的であり、通常は単にＰＴＴボタンを押すだけで、典型的なダイアルや呼出シーケンスを介すことなく開始されることである。この種のサービスにおける通信は、一般的に非常に短く、一般的に数秒のオーダでなされる個々の通話「スパート」と、おそらく高々１分ほど継続するであろう「会話」とを伴う。
【０００５】
ユーザが発言を要求した時と、ユーザがサーバから、このユーザが発言をしており、話し始めて良い旨の許可または非許可の確認を受けた時との間の時間遅延は、半二重のグループ通信システムにとっては重要なパラメータである。この時間遅延は、ＰＴＴ待ち時間として知られている。前述したように、ディスパッチシステムは、短く、迅速な会話を優先しているので、ＰＴＴ待ち時間が長くなる場合には、サービス効率を低下させてしまう。
【０００６】
既存のグループ通信インフラストラクチャ（以下、「インフラストラクチャ」を単に「インフラ」と称する。）は、ＰＴＴ待ち時間を大きく減少させることに関しては、能力が制限されている。すなわち、実際のＰＴＴ待ち時間は、休止パケットデータセッション内でトラフィックチャンネルを再確立するために必要な時間以下にはどうしてもならない。また、休止グループの呼び起こしを開始する有効な唯一のメカニズムは、再確立される話し手のトラフィックチャンネルが、サーバに信号を送るまで待つことであるので、話し手と聞き手とのトラフィックチャンネルは、連続して生成される。現在、モバイルから発したユーザ信号データを、トラフィックチャンネル以外のチャンネルにのせて送信するメカニズムは存在しない。これは、クライアントとサーバとの間のあらゆる通信がなされる前に、トラフィックチャンネルが再確立されねばならないという制約である。
【特許文献１】
米国仮特許出願60/291,454（2001年5月15日）
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、システム能力、クライアントのバッテリ寿命、あるいはその他のリソースに対してマイナスの影響を与えることなく、話し手が経験するＰＴＴ待ち時間と、モバイルに参加するトラフィックチャンネルの再確立に必要な合計時間との両方を低減するメカニズムが望まれる。
【課題を解決するための手段】
【０００８】
ここで開示される実施例は、グループ通信ネットワークにおいて、プッシュトーク通信デバイスのための効率的な休止モードを提供する斬新かつ改良された方法および装置である。本発明のある局面では、効率的な休止モードを提供する方法は、専用のトラフィックチャンネルを保持している通信デバイスが、予め定めた第１の期間の間、不動作状態にあったか否かを判定し、もしそうである場合には、この通信デバイスを、制御ホールドモードにする。この方法は、更に、専用のトラフィックチャンネルを解放した通信デバイスが、予め定めた第２の期間の間、制御ホールドモードにあったか否かを判定し、もしそうである場合には、この通信デバイスを、休止モードにする。
【０００９】
本発明の別の局面は、グループ通信ネットワークにおいて、プッシュトーク通信デバイスのために効率的な休止モードを提供する方法である。この方法は、通信デバイスが、予め定めた期間の間、不動作状態にあったか否かを判定し、もしそうである場合には、この通信デバイスを、休止モードにすることとし、休止モードに入る前に、この通信デバイスに対して、サービス設定状態をキャッシュさせる。
【００１０】
また別の局面は、グループ通信ネットワークにおけるプッシュトーク通信デバイスに休止モードを提供する通信デバイスである。この通信デバイスは、受信器と、記憶ユニットと、送信器と、受信器、記憶ユニット、および送信器と通信可能なように接続されたプロセッサとを含んでいる。このプロセッサは、上記各処理を実行することができる。ある局面では、この通信デバイスは、プッシュトークデバイスである。
【発明の効果】
【００１１】
本発明によれば、システム能力、クライアントのバッテリ寿命、あるいはその他のリソースに対してマイナスの影響を与えることなく、話し手が経験するＰＴＴ待ち時間と、モバイルに参加するトラフィックチャンネルの再確立に必要な合計時間との両方を低減することが可能となる。
【発明を実施するための最良の形態】
【００１２】
本出願は、上記特許文献１の優先権を主張するものであり、その全内容は参考文献として本明細書に組み込まれている。
【００１３】
本発明の実施例を詳細に記述する前に、本発明は、後述する記述や図面に示された構成の構造や配置の詳細に対する使用に限定されるものではないことを理解されたい。本発明は、他の実施例において実施されることも可能であり、様々な方法で実行される。また、ここで使用された文言および専門用語は、説明目的に用いたものであって、制限されるべきものではないことにも留意されたい。
【００１４】
図１は、グループ通信システム１００の典型的な機能ブロック図を示している。グループ通信１００はまた、プッシュトークシステム、ネット放送サービス（ＮＢＳ）、ディスパッチシステム、あるいはポイント対多数ポイントの通信システムとしても知られている。ＮＢＳ１００では、おのおのネットメンバとして知られている通信デバイスユーザのグループは、各ネットメンバに割り当てられた通信デバイスを用いて互いに通信する。「ネット」という用語は、お互いに通信することを許可された通信デバイスユーザのグループを意味している。
【００１５】
ある実施例では、中央データベースが、各特定ネットのメンバを識別する情報を含んでいる。複数のネットが、同一の通信システムにおいて動作しうる。例えば、１０人のメンバを持つ第１のネットが定義され、２０人のメンバを持つ第２のネットが定義されうる。第１のネットの１０人のメンバは互いに通信できるが、第２のネットのメンバとは通信できない。別の実施例では、異なるネットのメンバは、複数のネットのメンバ間における通信をモニタすることができるが、自己のネット内のメンバに対してのみ情報を送信することができる。
【００１６】
ネットは、既存の通信システムを通じて、既存のインフラに実質的な変更を要すことなく動作しうる。したがって、ネットにおけるコントローラおよびユーザは、例えば、コード分割多元接続（ＣＤＭＡ）システム、時分割多重接続（ＴＤＭＡ）システム、モバイル通信用のグローバル（ＧＳＭ）システム、Globalstar（登録商標）またはIridium（登録商標）のような衛星通信システム、あるいはその他の種々のシステムのようにインターネットプロトコル（ＩＰ）を用いてパケット情報の送受信が可能な何れのシステムにおいても動作しうる。
【００１７】
ネットメンバは、通信デバイス（ＣＤ）１０２，１０４，１０６，および１０８として示されているように、割り当てられた通信デバイスを用いて互いに通信する。ＣＤ１０２，１０４，１０６，および１０８は、例えば、地上無線電話、プッシュトーク能力を備えた無線電話、プッシュトーク機能を備えた衛星電話、無線ビデオカメラ、スチルカメラ、音楽録音機または再生機のようなオーディオデバイス、ラップトップまたはデスクトップのコンピュータ、ページングデバイス、またはそれらの組み合わせなどといった有線または無線の通信デバイスでありうる。例えば、ＣＤ１０２は、ビデオカメラとディスプレイとを備えた無線地上電話からなる。更に、各ＣＤは、秘密モードまたは非秘密（クリア）モードの何れかで、情報の送受信を行うことができる。以下の議論を通して、各ＣＤに対するリファレンスとしては、無線プッシュトーク電話を想定している。しかしながら、ＣＤに対するリファレンスは、それに限定されることを意図しておらず、インターネットプロトコル（ＩＰ）にしたがってパケット情報を送受信する能力を持つ他の通信デバイスを含みうるものと理解されたい。
【００１８】
図２に示すＮＢＳシステム２００では、一般に送信権利とは、単一ユーザに対して、与えられた時間に他のネットメンバへ情報を送信することを許可することである。この送信権利は、要求がなされた時に、この送信権利が別のネットメンバに割り当てられているか否かに基づいて、要求元のネットメンバに対し許可または不許可される。送信要求の許可および不許可にするプロセスは、裁定として知られている。裁定スキームは、要求元のネットメンバに送信権利を許可するか否かを判定する場合、各ＣＤに割り当てられた優先レベル、送信権利を取得するためになされた試行の失敗回数、ネットメンバが送信権利を持っていた時間の長さ、あるいはその他の各要因を評価する。
【００１９】
ＮＢＳシステム１００に参加するために、ＣＤ１０２，１０４，１０６および１０８は、それぞれコントローラ、すなわち通信マネジャ（ＣＭ）１１０から、送信権利を要求する能力を持つことができる。ＣＭ１１０は、ネットのリアルタイムかつ総括的な管理を行う。ＣＭは、少なくも１つのプロセッサとメモリとを備えていれば、どのようなコンピュータタイプのデバイスであってもよい。ある実施例では、ＣＭとして、Ｓｕｎ社製のワークステーションNetra T1（登録商標）を用いる。
【００２０】
サービスプロバイダによって許可された場合、ＣＭ１１０は、通信システムサービスプロバイダか、ネットメンバとのうちの何れか、またはその両方を通じて遠隔動作しうる。ＣＭ１１０は、外部の管理インタフェースを通じ、ネット定義を取得しうる。ネットメンバは、自己のサービスプロバイダ、またはメンバによって操作され、ＣＭ管理インタフェースに対応したセキュリティマネジャ（ＳＭ）１１２のように定義されたシステムを通じた管理ネット機能によって管理動作を要求しうる。ＣＭ１１０は、ネットの確立または変更を試みる当事者を認証する。
【００２１】
ＳＭ１１２は、キー管理、ユーザ認証、および安全なネットのサポートに関連したタスクを実行する。単一のグループ通信システムは、１以上のＳＭ１１２と通信する。ＳＭ１１２は、ネットのリアルタイム制御には含まれないが、ネット動作すなわちＰＴＴ裁定には含まれる。ＳＭ１１２は、管理機能を自動化するために、ＣＭ１１０インタフェースと互換の管理機能を持っている。ＳＭ１１２はまた、ネット、放送ネットキー、あるいは単にネットトラフィックのモニタに参加することを目的としたデータ端末として動作する。
【００２２】
ある実施例では、ＣＭから送信権利を要求する手段は、プッシュトーク（ＰＴＴ）キーまたはスイッチを備えている。ＮＢＳ１００内のユーザが他のネットメンバに情報を送信したい場合には、このユーザは、自己のＣＤに配置されたプッシュトークスイッチを押すことによって、発言制御要求を送信し、ＣＭ１１０から送信権利を取得する。仮にその時、他のどのメンバにも送信権利が割り当てられていない場合には、要求元のユーザに送信権利が許可され、このユーザには、可聴な、ビジュアルな、あるいは認識可能な警告がＣＤを通じて通知される。この要求元のユーザに送信権利が許可された後、このユーザから他のネットメンバに対して情報が送信される。
【００２３】
本発明のある実施例では、各無線ネットメンバは、状況に応じて、１つ以上の基地局１１６または衛星ゲートウェイ１１８と、順方向リンクおよび逆方向リンクを確立する。基地局１１６は、基地局１１６または衛星ゲートウェイ１１８からＣＤへの通信チャンネルを記載するために使用される。衛星ゲートウェイ１１８は、ＣＤから基地局１１６または衛星ゲートウェイ１１８への通信チャンネルを説明するために使用される。音声および／またはデータは、例えばＣＤを用いてデータパケットへと変換される。データパケットは、他のユーザへの通信が起こりうる特定の分散型ネットワーク１２０に適している。ある実施例では、分散型ネットワーク１２０はインターネットである。
【００２４】
ある実施例では、各ネットメンバから他のネットメンバへと情報を放送するために、専用の順方向チャンネルが各通信システム、すなわち、地上通信システムと衛星通信システムにおいて確立される。各ネットメンバは、この専用チャネルを通じて、他のネットメンバからの通信を受信する。別の実施例では、ＣＭ１１０に情報を送信するために、各通信システムにおいて、専用の逆方向リンクが確立される。上述したスキームの組み合わせが用いられる実施例もある。例えば、あるスキームは、専用の順方向放送チャンネルの確立を含みうるが、各ＣＤに割り当てられた専用の逆方向リンクを通じ、情報をＣＭ１１０に送信するよう無線ＣＤに対して要求することをも含みうる。
【００２５】
第１のネットメンバがネットの他のメンバに情報を送信することを望んだ場合、この第１のネットメンバは、自己のＣＤのプッシュトークキーを押し、分散型ネットワーク１２０を通じた送信用にフォーマットされた要求を生成し、送信権利を要求しうる。ＣＤ１０２および１０４の場合、この要求は、空間を通じて１以上の基地局１１６へと送信される。データパケットを処理するためのモバイル切換センタ（ＭＳＣ）１２２は、相互作用機能（ＩＷＦ：interworking function）、パケットデータサービングノード（ＰＤＳＮ：packet data serving node）、あるいはパケット制御機能（ＰＣＦ：packet control function）のように良く知られた機能を備えうるものであって、ＢＳ１１６と分散型ネットワーク１２０との間に存在する。ＣＤ１０６のために、この要求は、衛星ゲートウェイ１１８を経由して送信される。ＣＤ１０８のために、この要求は、公衆通信交換網（ＰＳＴＮ）１２４を通して、モデムバンク１２６に送信される。モデムバンク１２６は、この要求を受信し、これを分散型ネットワーク１２０に提供する。ＮＢＳターミナル１２８は、分散型ネットワーク１２０への接続を通じて、ＮＢＳシステムからのトラフィックをモニタする。ＮＢＳターミナル１２８は、分散型ネットワーク１２０と接続しているので、ネット参加者に対する地理的な近さは必要ない。
【００２６】
仮にその時、どのメンバも送信権利を持っておらず、ＣＭ１１０が送信権利要求を受信した場合には、ＣＭ１１０は、要求元のネットメンバにメッセージを送信し、送信権利が許可されたことを知らせる。第１のネットメンバからのオーディオ、ビジュアル、あるいはその他の情報は、まさに記載された送信経路の一つを使ってＣＭ１１０に送信され、その後、他のネットメンバに送信されうる。ある実施例では、その場合、ＣＭ１１０はこの情報をコピーし、各コピーを他のネットメンバに送信することによって、この情報を他のネットメンバに提供する。仮に、単一の放送チャンネルが使用されている場合には、この情報は単に、各放送チャンネルの使用のために一度だけコピーされる必要がある。
【００２７】
その代わりの実施例では、ＣＭ１１０は、サポートしている基地局からのデータパケットが、分散型ネットワーク１２０にルーティングされることなくＣＭ１１０に直接的にルーティングされるようにＭＳＣ１２２に組み入れられる。この実施例では、ＣＭ１１０は、他の通信システムとデバイスがグループ通信に参加しうるように、分散型ネットワーク１２０に接続されている。更にまた別の実施例では、このＣＭは、ＰＤＳＮか、またはＭＳＣのＰＣＦモジュールの中に組み込まれる。
【００２８】
ある実施例では、ＣＭ１１０は、定義された各ネットと同様に、各ネットメンバに関連する情報を管理するための１つ以上のデータベースを維持している。このデータベースは、例えば、各ネットメンバについて、ユーザ名、アカウント番号、メンバのＣＤに対応した電話番号すなわちダイアル番号、ＣＤに割り当てられたモバイル認証番号、メンバがネットに参加中であるか否かといったネットにおけるメンバの現在の状況、同様にして送信権利が割り当てられるかを判定するための優先コード、ＣＤに対応したデータ電話番号、ＣＤに対応したＩＰアドレス、メンバが通信を許可されたネットのインデクス等の情報を備えている。その他の関連情報もまた、各ネットメンバに関連したデータベースに格納されている。
【００２９】
ある実施例では、ＣＤは、個々の通信端末との接続を形成し、１つの通話グループすなわちネットを形成する。またＣＭは、ハードウェアやソフトウェア内に種々の機能を備えうる。これら機能は、異なるアプリケーションに適用するために、異なる方法で構成することが可能である。更にＣＭは、（ＮＢＳ）ネットのリアルタイムな、管理的な、あるいは認証するための動作と、プッシュトーク（ＰＴＴ）要求裁定と、ネット会員と登録リストのメンテナンスおよび分配と、必要な通信の呼出設定およびティアダウンと、例えばＣＤＭＡのようなシステムと、ネットワークリソースとを、ネット状況の全体制御と同様に管理する能力を備えている。
【００３０】
ＮＢＳネットは、スタンドアローンタイプの携帯システムや、大きな複数サイト構造内に存在しうる。大きな構造内にある場合、多数のＣＭが、幾何学的に配置されることによって、単一の統合システムを形成する。ここでは、各々が既存の携帯インフラに組み込まれたプラグインモジュールとして動作する。そのようなものとして、ＮＢＳネットによって導入された新しい機能は、既存の携帯インフラに対して変更を必要とせず、携帯ユーザにとって有効である。
【００３１】
このＣＭは、定義されたＮＢＳネットのリストを維持する。ある実施例では、各ネット定義は、ネット識別子と、電話番号または他の認証情報を含むメンバリストと、ユーザ優先情報と、その他の一般的管理情報とを含む。ネットは、クリアまたは安全かの何れかであると統計的に定義される。また、クリアと安全との間での移行は許容されない。安全なＮＢＳネットは、一般に、認証を行ったり、盗み聞きに対する警戒のために、メディア暗号化技術を用いている。安全なネットのためのメディア暗号化は、エンドトゥエンド原理に基づいてなされている。これは、暗号化および復号化ともに通信デバイス内でなされることを意味している。ＣＭは、セキュリティアルゴリズムや、キー、あるいはポリシーの知識が無くても動作しうる。
【００３２】
図２は、通信デバイス２０２とＣＭ２０４との相互動作を示すために、典型的なＮＢＳネット２００を示した図である。多数のＣＭが、大規模なＮＢＳネット用に要求されたように配置される。図２では、ＣＤ２０２が、ネットの他のメンバにメディアを送信する許可を得ている。この場合、ＣＤ２０２は、話し手として知られており、チャンネルを通じてメディアを送信する。ＣＤ２０２が話し手として指定された場合、残りのネット参加者であるＣＤ２０６およびＣＤ２０８は、メディアをネットに送信する許可を有していない。
【００３３】
したがって、ＣＤ２０６およびＣＤ２０８は、聞き手として指定される。
【００３４】
上述したように、ＣＤ２０２，２０６，２０８は、少なくとも１つのチャンネルを使ってＣＭ２０４に接続される。ある実施例では、このチャンネルは、セッション開始プロトコル（ＳＩＰ：session initiation protocol）チャンネル２１０、ＮＢＳメディア信号チャンネル２１２、およびメディアトラフィックチャンネル２１４からなる別のチャンネルに分割される。ＳＩＰチャンネル２１０とＮＢＳメディア信号チャンネル２１２とは、話し手または聞き手に指定されたに関わらず、バンド幅が許容するように、ＣＤ２０２，２０６，２０８のうちの何れかによって、いかなる時でも使用されうる。ＳＩＰは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって定義されたアプリケーション層プロトコルであって、インターネットプロトコル（ＩＰ）を通じて動作するマルチメディアセッションの確立、変更、および終了させるための制御メカニズムを記述している。ＳＩＰは、インターネットテレフォニーアプリケーションに対する呼出信号問題に、ユーザの登録および位置を突き止めるメカニズムと、ユーザ能力の定義とメディアパラメータの記述とを行うメカニズムと、ユーザ利用性、呼出設定、および呼出ハンドリングを決定するメカニズムとをサポートすることによって、一般的な解決策を提供する。
【００３５】
ある実施例では、ＳＩＰチャンネル２１０は、ＮＢＳネット１００内におけるＣＤの参加の開始および終了のために使用される。セッション記述プロトコル（ＳＤＰ：session description protocol）は、ＳＩＰチャンネル２１０内でもまた使用されうる。例えば、ＳＩＰチャンネル２１０を使用することによってＮＢＳネット内におけるＣＤの参加が設定された場合には、例えば、ＮＢＳメディア信号チャンネル２１２を使用することによって、ＣＤとＣＭとの間でリアルタイムの呼出制御と信号化が引き起こる。ある実施例では、ＮＢＳメディア信号チャンネル２１２は、プッシュトーク要求および解放の取り扱い、かち合った要求間の調停あるいは発言制御、情報送信の開始および終了のアナウンス、ネット休止の管理、端末の接続性の追跡、ネット状況の要求および交換、およびあらゆるエラーメッセージの連絡のために用いられる。ＮＢＳメディア信号チャンネル２１２のプロトコルは、最も一般的なメッセージの長さを最小化し、将来的な機能拡張に対する柔軟性を保ちながら応答の解釈や要求に対する回答からなるタスクを簡素化する。ＮＢＳメディア信号チャンネル２１２のプロトコルはまた、プロトコル状態に不利な影響を与えることなく要求を再送信することを可能とする。
【００３６】
ある実施例では、ＮＢＳメディア信号チャンネル２１２における信号トラフィックは、呼出の設定および制御を行う信号と、メディア信号とを含んでいる。呼出の設定および制御を行う信号は、セッション勧誘要求と確認から構成されうる。メディア信号は、リアルタイムの発言制御要求と、それに関連する非同期型のメッセージとを含みうる。メディアトラフィックチャンネル２１４におけるメディアトラフィックは、リアルタイムのポイント対多ポイントの音声および／またはデータ放送を含む。何れのメッセージカテゴリも、ユニークな機能属性を持っている。さらに、各ＣＤは、インターネットネットワークアドレスに対して完全に適合したマッピングを容易にするために、ドメインネームサービス（ＤＮＳ）クライアント要求を発行する。
【００３７】
ある実施例では、ＮＢＳ呼出設定と呼出制御の信号化は、ＳＩＰの意味にしたがって実行される。ＳＩＰは、良く知られたユーザデータグラムプロトコル（ＵＤＰ）か送信制御プロトコル（ＴＣＰ）かの何れかを用いて搬送されうるが、ある実施例では、各ＣＤは、ＵＤＰを使った信号化機能に基づいてＳＩＰを実行する。また、各ＣＭは、ＵＤＰを経由してＳＩＰ信号化要求を受信することを想定している。リアルタイムの信号化は、ＣＭおよび各ＣＤにおける動的なＵＤＰ／ＩＰインタフェースを経由して起こりうる。他の信号化は、例えばＳＩＰを使って、ＣＭとＣＤとの間の固定されたＴＣＰ／ＩＰインタフェースを経由して起こりうる。
【００３８】
（ＰＴＴ待ち時間）
ある実施例では、パケットデータサービスが動作中である場合、例えば基地局トランシーバサブシステム（ＢＴＳ）、基地局コントローラ（ＢＳＣ）、相互作用機能（ＩＷＦ）、および無線リンクのようなインフラにおけるリソースが移動局（ＭＳ）に対して動作中であると割り当てられる。ＩＰベースのＶｏＩＰディスパッチサービスでは、グループ参加者間のアクティブな会話がある一方、各ユーザのパケットデータ接続は動作中のままである。しかしながら、グループ通信において例えば「ハング時間」などの非動作時間の後、ユーザトラフィックチャンネルは、休止状態に移行する。
【００３９】
この休止状態への移行は、システム能力を温存し、サービスコストとバッテリ消費を減らし、ユーザは、到来する従来の音声呼出を受信できるようになる。例えば、ユーザが、動作中のパケットデータ呼出をしている場合、このユーザは一般的に、到来する音声呼出に対して「ビジー」であると考えられる。仮に、このユーザのパケットデータ呼出が休止状態にある場合には、このユーザは、到来する音声呼出を受信することが可能となるであろう。これらの理由のために、パケットデータの不動作状態期間の後、このパケットデータ呼出は、休止状態に移行することが望ましい。
【００４０】
パケットデータ呼出が動作中である一方、たとえデータパケットが全く交換されない場合であっても、基地局との同期と出力制御とを維持するために、無線周波数（ＲＦ）エネルギーは、低いレベルではあるが移動電話によって送信される。これらの送信は、電話機にとって重大な出力の消費をもたらす。休止状態では、電話は、ＲＦ送信を実行しない。電話出力を温存し、バッテリ寿命を延ばすために、ハング時間は、データ送信がされない時間後には、この電話を休止モードに移行させるために設定される。
【００４１】
パケットデータサービスが全ユーザに対して動作中である一方、ＭＳとディスパッチサーバとの間で送信されたＩＰデータグラムであるＰＴＴ要求は、極めて短い待ち時間を伴う。しかしながら、仮にこのユーザチャンネルが、以前に休止状態に移行していた場合、ＰＴＴ待ち時間はもっと長くなりうる。パケットデータが休止している間、移動ＩＰアドレスを含むパケットデータセッションに関連する状態情報は維持されうる。しかしながら、物理トラフィック層のようにＰＰＰより下の層に対応する状態情報は、解放されるか、配分が解除されるかの何れかがなされる。
【００４２】
あるインフラでは、休止状態のデータ接続を呼び起こすために、トラフィックチャンネルは再配分され、リソースは再割り当てされ、無線リンクプロトコル（ＲＬＰ）層は再び初期化されねばならない。この効果は、話し手グループがしばらく会話をしなかった後であって、ユーザがＰＴＴボタンを押して発言を要求した場合、最初の会話スパートに対するＰＴＴ待ち時間は、一般的に、次に来る会話スパートに対するＰＴＴ待ち時間よりも極めて長いということである。比較的まれではあるが、これはサービスの有用性に影響を与えるので、最小化されるべきである。
【００４３】
ある実施例では、グループ通信デバイスが休止状態にある場合、ＰＴＴ待ち時間は、以下によって引き起こされる。
【００４４】
１．話し手のチャンネル割り当て遅れ
プッシュトークボタンを押すユーザと、ＩＰベースの発言要求メッセージを初期化するディスパッチアプリケーションとに応答した話し手の電話に対するトラフィックチャンネルの割り当てと初期化との遅れ。
【００４５】
２．呼出要求の伝搬遅れ
発言要求メッセージがディスパッチサーバに伝搬する時間。
【００４６】
３．裁定の遅れ
ディスパッチサーバが多数の発言要求を処理する時間。
【００４７】
４．呼び起こしメッセージの遅れ
ディスパッチサーバからのＩＰメッセージを、例えばＰＤＳＮのような聞き手にサービスを提供する携帯インフラへと伝搬する時間。
【００４８】
５．聞き手のページング遅れ
聞き手の電話が呼び起こされ、適切なページングチャンネルスロットのページを受信するのを待つ必要性による時間遅れ。
【００４９】
６．聞き手のチャンネルの割り当て遅れ
聞き手の電話のトラフィックチャンネルの割り当ておよび初期化における遅れ。
【００５０】
これらの遅滞のうちのいくつかは、全体のＰＴＴ待ち時間に対する寄与が、他のものよりも十分に大きい。例えば、話し手と聞き手のチャンネル割り当て待ち時間、および聞き手のページング待ち時間は、他の要因よりも１桁以上大きいので、これらの組み合わせは、究極的にＰＴＴ待ち時間性能を決定してしまう。
【００５１】
ＰＴＴ待ち時間を減少するために、ある実施例では、発言制御要求、発言制御応答、および休止からの呼び起こしメッセージのようなグループ呼出信号は、専用のトラフィックチャンネルが再確立されるのを待つことなく、有効な共通チャンネルで送信されうる。モバイルの状態に関わらず、そのような共通チャンネルは常に有効とは限らない。また、ユーザがグループ呼出を開始したいたび毎に、要求されたり再割り当てされる必要もない。したがって、グループ呼出信号は、モバイルが休止の場合であっても交換され、話し手と聞き手のモバイルに対し並行して専用トラフィックチャンネルを再確立する手段を備えうる。
【００５２】
ある実施例では、この呼出モバイルは、逆方向アクセスチャンネルおよび逆方向高速アクセスチャンネルのような有効な逆方向共通チャンネルを通じて、発言制御要求を無線インフラに送信する。この呼出モバイルはまた、順方向ページングチャンネルおよび順方向共通制御チャンネルのような有効な順方向共通チャンネルによってこの発言制御要求に対する応答を受信しうる。ある実施例において、休止中の聞き手のモバイルは、順方向ページングチャンネルおよび順方向共通制御チャンネルのような有効な順方向共通チャンネルにおいて休止を起こすためのメッセージを受信しうる。
【００５３】
（短いデータバースト呼出信号メッセージ）
ある実施例では、実際の休止起こし時間の合計を有意に低減することと、話し手によって感じられたＰＴＴ待ち時間とは、例えば「TIA/EIA/IS-2000 Standards for cdma2000 Spread Spectrum System」（以下、単にcdma2000と称する）で与えられている短いデータバースト（ＳＤＢ）メッセージを使用することによって改善されうる。ある実施例では、ＳＤＢメッセージは、順方向基本チャンネル（ＦＣＨ）または順方向専用共通制御チャンネル（Ｆ−ＤＣＣＨ）のような専用物理チャンネルや、逆方向アクセスチャンネル（Ｒ−ＡＣＨ）、逆方向エン高速アクセスチャンネル（Ｒ−ＥＡＣＨ）、順方向共通制御チャンネル（Ｆ−ＣＣＣＨ）、またはページングチャンネル（ＰＣＨ）のような共通物理チャンネルの両方を通じて送信されうる。ＳＤＢメッセージは、無線バーストプロトコル（ＲＢＰ）によって搬送されうる。ＲＢＰは、メッセージを、適切でかつ有効な物理層チャンネルにマップする。ＳＤＢメッセージは、裁定ＩＰトラフィックを搬送し、共通物理チャンネルを通じて送信されうるので、ＳＤＢメッセージは、呼出をしているクライアントのモバイルが専用のトラフィックチャンネルを持っていない場合には、グループ呼出信号を交換するメカニズムを与える。
【００５４】
（モバイルから送信された呼出信号メッセージ）
ある実施例では、メディア信号メッセージは、逆方向リンクあるいはモバイルから発せられるリンクを通じてＩＰデータグラムを搬送する。クライアントの移動局は、ユーザが発言を要求しても専用の逆方向トラフィックチャンネルがすぐに有効にならない場合には、ＣＭに迅速に信号を送る。クライアントの移動局が、全ての専用トラフィックチャンネルを解放した場合、クライアントの移動局は、無線インフラの逆方向共通チャンネルを通じて、発言制御要求を直ちに転送する。これによって、この要求をＣＭに中継する。例えば、専用の逆方向チャンネルが有効ではない場合には、逆方向アクセスチャンネルあるいは逆方向高速アクセスチャンネルとのうちの何れか一方が、このメッセージを送信するために使用される。ある実施例ではクライアントの移動局は、発言要求メッセージを、ＳＤＢメッセージとしてＣＭに送信する。
【００５５】
図３は、発言制御要求プロセスに対する典型的な呼出信号を示す図である。クライアント移動局（ＭＳ）は、グループ呼出の開始を望むユーザからの要求を受信する。ある実施例では、このクライアントＭＳは、ＰＴＴデバイスである。ある実施例では、このクライアントＭＳは、専用トラフィックチャンネルの再確立を試みる前に、例えばアクセスチャンネルや高速アクセスチャンネルのような逆方向共通チャンネルを通じてＰＴＴ発言要求３０２を送信する。ある実施例では、このクライアントＭＳは、どのチャンネルが使用されているかに関わらず、ＳＤＢメッセージにおけるＰＴＴ発言要求３０２を送信する。
【００５６】
その後、このクライアントＭＳは、例えば、「サービスオプション３３  再オリジネーション」を実行することによって、専用トラフィックチャンネル３０４の再確立を開始する。このクライアントＭＳはまた、無線リンクプロトコル（ＲＬＰ）同期化３０６を開始する。ある実施例では、このクライアントは、専用トラフィックチャンネルを再確立し、ＰＴＴ発言要求３０２の送信と並行して、ＲＬＰの同期化を優先的に行う。
【００５７】
したがって、移動局が動作中の専用トラフィックチャンネルを持っていない場合、有効な逆方向共通チャンネルおよび／またはＣＭに対して発言制御要求を送っているＳＤＢ機能を用いることによって、参加モバイルを呼び起こすために必要な合計時間を減少する。話し手であるクライアントは、話し手の順方向トラフィックチャンネルが再確立されるまで、発言要求許可確認を取得しないが、参加している聞き手の呼び起こしを開始するために迅速にＣＭに信号を送る能力によって、全体の待ち時間を減少させる。
【００５８】
図３に示すように、無線インフラは、ＰＴＴ発言制御要求３０８をパケットデータサービスノード（ＰＤＳＮ）に送信し、その後、ＣＭに送信する。ある実施例では、発言制御要求３１０を受信した後に、ＣＭがこの要求を裁定し、メディア信号呼び起こしメッセージ（トリガ）を目標参加者のグループ（聞き手）に発信し、更に／または参加者（聞き手）のトラフィックチャンネルの再確立を引き起こす。仮に、このＣＭがＰＴＴ発言要求を許可する場合には、このＣＭは、ＰＴＴ発言許可３１２をインフラに送信し、インフラは、ＰＴＴ発言許可３１４を、クライアントＭＳに送信する。ある実施例では、仮に、クライアントの専用トラフィックチャンネルが再確立されない場合には、このインフラが、ＰＴＴ発言許可３１４を、例えば、順方向ページングチャンネルや順方向共通制御チャンネルのような有効な順方向共通チャンネルによってクライアントＭＳに送信する。ある実施例では、このインフラは、どのチャンネルが使用されているかに関わらず、ＰＴＴ発言許可３１４を、ＳＤＢ形式でクライアントＭＳに送信する。
【００５９】
ある実施例では、このＣＭは、ＰＴＴ発言制御要求に対して応答する前に、休止応答タイマが終了するまで待機する。仮に、グループの休止応答タイマがゼロに設定されている場合には、このＣＭは、この発言制御要求に対して直ちに応答する。ある実施例では、仮に、このクライアントＭＳがトラフィックチャンネルの再確立と、ＲＬＰの同期とを完了した場合には、このクライアントＭＳは、バッファしていたメディア３１６をＣＭへとストリームする。
【００６０】
（ネットワークから発信された呼出信号メッセージ）
ある実施例では、発言制御要求を受信した後に、ＣＭは、メディア信号呼び起こしメッセージを目標参加者（聞き手）のグループに発信し、参加者（聞き手）のトラフィックチャンネルの再確立を引き起こす。仮に、このグループの休止応答タイマがゼロに設定されている場合には、このＣＭは、発言制御要求に対して直ちに応答する。ある実施例では、仮に、話し手がＰＴＴ要求を送信することによって、トラフィックチャンネルの再確立を直ちに開始した場合には、呼出人および聞き手のトラフィックチャンネルは並行して都合良く再確立されうる。
【００６１】
図４は、ネットワークによって開始された休止呼び起こしプロセスにおける典型的な呼出信号を示す図である。ＣＭがＰＴＴ発言制御要求３１０（図３）を受信した後、このＣＭは、呼び起こしトリガ４０２を、目標とする聞き手に対して直接的に送信する。ＰＳＤＮは、目標モバイルにパケットデータセッションが存在するか否かを判定し、トリガパケットを、例えば基地局のような適切なインフラ要素へと転送する。このインフラは、専用トラフィックチャンネルの再確立を開始するために、各目標ＭＳ毎にページ４０６を行いうる。そのとき、目標ＭＳは、例えば「サービスオプション３３  再オリジネーション」を実行することによって、専用トラフィックチャンネル４０８の再確立を開始する。この目標ＭＳはまた、無線リンクプロトコル（ＲＬＰ）の同期化４１０を開始する。ある実施例では、この目標ＭＳは、専用トラフィックチャンネルを再確立し、クライアントＭＳによってなされているものと同一の機能によって、並行して都合良くＲＬＰを同期化する。
【００６２】
ある実施例では、目標ＭＳが専用トラフィックチャンネルの再確立とＲＬＰの同期化とを完了した後に、ＣＭが呼び起こしトリガ４１２を目標ＭＳに再送信する。この目標ＭＳは、呼び起こし応答４１４をＣＭに送信し、この目標ＭＳがメディアを受信する準備ができていることを示す。このＣＭは、バッファしていたメディア４１８を目標ＭＳにストリーミングする前に、話し手アナウンスメント４１６をクライアントＭＳに送信する。
【００６３】
ある実施例では、目標とする聞き手のトラフィックチャンネルが再確立されていない一方で、このインフラは、順方向ページングチャンネルや順方向共通制御チャンネルのようないくつかの有効な共通順方向チャンネルを通じて、目標とする聞き手に対して呼び起こしトリガ４１２を送る。ある実施例では、このインフラは、どのチャンネルが使用されているかに関わらず、呼び起こしトリガ４１２を、目標である聞き手に対してＳＤＢ形式で送信する。仮に、ＰＴＴ発言制御要求がＳＤＢメッセージとして話し手の逆方向共通チャンネルを通じて送信され、目標グループの休止応答タイマがＣＭにおいてゼロに設定されている場合には、話し手クライアントにおける実際のＰＴＴ待ち時間は、順方向リンクでのＳＤＢ応答メッセージがその後に続く逆方向リンクによるＳＤＢ要求メッセージを送るために必要な時間に減少される。
【００６４】
（呼出信号メッセージに対するネットワークインタフェース）
たとえばＳＤＢペイロードのようなネットワークから発信された特別のトラフィックのうちのどれが、専用トラフィックチャンネルを伴うことなく、アイドル状態の移動局のために送信されたかを判定するために、このようなトラフィックと他のトラフィックとを区別するための幾つかのインフラポリシーまたはインタフェースが実装されうる。
【００６５】
第１の実施例では、ＳＤＢメッセージが、制限されたユーザペイロードを搬送しうるように、ＩＰデータグラムが、そのサイズに基づいてフィルタされる。予め定めたサイズ制限よりも小さいＩＰデータグラムが、仮に、専用トラフィックチャンネルを持たないモバイルに向けられている場合、ＳＤＢメッセージとして送信される。アプリケーション発言要求応答メッセージは、例えばＩＰヘッダを含めても３４バイトであり極めて小さいので、グループ通信システムはこのようなフィルタを使用しうる。
【００６６】
第２の実施例では、インフラベンダは、配信のために移動局に向けられたＩＰトラフィックをカプセル化するためのＩＰベースのサービスを定義しうる。このサービスの知識を有するＩＰサーバは、例えばＵＤＰのように、配信のためのサービス向けのＩＰヘッダとともに、適切にカプセル化された小さなＩＰデータグラムを、専用トラフィックチャンネルを持っていないと思われるモバイルに送信する。グループ通信システムは、インフラに対して、例えば、この発言要求応答メッセージが、要求元のクライアントＭＳに対してＳＤＢ形式で配信されたことを示すために、このサービスを使用しうる。未決定のページまたはサービスオリジネーション要求を持つＳＤＢトラフィックの調整はまた、ユーザトラフィックの迅速で信頼できる配信を保証するために重要である。
【００６７】
第３の実施例では、ＩＰサーバは、例えばＵＤＰのような特別なＩＰデータグラムを、配信のためのＩＰヘッダとともに、専用トラフィックチャンネルを持っていないと思われるモバイルに送信する。このＩＰサーバは、例えば、ＩＰヘッダに特別な値を指定することによって、このＩＰデータグラムをクライアントＭＳに配信するようにインフラに対して指示するＩＰデータグラムを付加しうる。このグループ通信システムは、このサービスを用いて、例えば、発言要求応答メッセージが、要求元のクライアントＭＳへとＳＤＢ形式で配信されたことをインフラに対して示す。第３の実施例では、ＵＤＰあるいはＴＣＰポート範囲は、例えばＳＤＢメッセージのような特別なＩＰデータグラムを配信するために確保されうる。
【００６８】
（モバイルによって開始されたサービスオリジネーション要求およびページング）
ある実施例では、図３を用いて説明したように、話し手の移動局（ＭＳ）は、発言制御要求３０２を、例えばＳＤＢ形式でＣＭに送信する。すると、その後すぐに、トラフィックチャンネルを迅速に再確立するために、例えばＣＤＭＡのような無線インフラに対し、サービスオリジネーション要求３０４がなされる。しかしながら、仮に休止応答タイマが小さな値に設定されている場合には、ＣＭは、この発言制御要求３１０に対して迅速に応答し、応答３１２を話し手のＭＳへと返信する。仮に、この応答が、サービスオリジネーションプロセス３０４の初期段階の間にインフラに到達した場合には、このインフラは、この話し手ＭＳは、動作中のトラフィックチャンネルを全く持っていないことに気づき、この話し手ＭＳに対する応答をページするよう試みる。しかしながら、このページング動作は、既に進行中のサービスオリジネーションプロセスを中断させるかもしれない。ある実施例では、話し手ＭＳは、このページに対して応答し、この発言制御応答メッセージが話し手に対して配信されたことを保証する。そして、サービスオリジネーションを再び要求する。しかしながら、中断されたオリジナルのサービスオリジネーションの試行の結果として、話し手のトラフィックチャンネルを再確立する場合に、不要な遅延が生じる。
【００６９】
第１の実施例では、サービスオリジネーションプロセスとページングとの競合状態を避けるために、ＣＭは、発言制御要求３１０に対して迅速に応答することがないように構成される。したがって、例えばＣＭ内においては、サービスオリジネーションプロセス３０４が完了した後に、ＣＭが話し手ＭＳへ応答３１２を送信することができるように、休止応答タイマが調整される。
【００７０】
第２の実施例では、ＣＭによって開始された応答３１２を受信するＰＤＳＮと、話し手のサービスオリジネーション要求に対して応答するモバイル切換センタ（ＭＳＣ）とが調整される。すなわち、ＣＭによって開始された応答３１２がインフラに到達した場合、仮に、ＰＤＳＮが、話し手ＭＳに対するパケットデータサービスオリジネーションプロセスが既に進行中であると判定した場合には、ＭＳＣは、話し手ＭＳのページングを延期しうる。サービスオリジネーションプロセスが一旦完了すると、ＰＤＳＮは、この応答をキャッシュし、これを、話し手のモバイルの順方向トラフィックチャンネルを通じて送信する。別の方法として、仮に、このサービスオリジネーションプロセスがまだ進行中である場合には、ＭＳＣは、この応答を、ＳＤＢメッセージとして話し手のＭＳに送信する。
【００７１】
第３の実施例では、話し手ＭＳが、発言制御要求３０２に対する応答の受信後まで、サービスオリジネーション要求３０４を出さないことによって、この話し手ＭＳは、競合状態を回避しうる。ある実施例では、話し手ＭＳは、動作中の専用トラフィックチャンネルを持っていないので、ＣＭは、順方向ページングチャンネルや順方向共通制御チャンネルなどの有効な順方向共通チャンネルによって話し手ＭＳに対して応答を送信する。ある実施例では、ＣＭは、ＳＤＢ形式で話し手ＭＳに対して応答を送る。この話し手ＭＳは、ＣＭによって生成された発言制御メッセージ３１２に依存して、トラフィックチャンネルの再動作にトリガをかける。同様にして、ＣＭによって送られた呼び起こし要求は、聞き手のモバイルに対するトラフィックチャンネルの再動作にトリガをかける。モバイルによって開始されたサービスオリジネーションと、ネットワークによって開始されたモバイルのページングとが同時になされる潜在性が回避されることによって、前記競合状態は回避される。
【００７２】
（ネットワークによって開始されたパケットデータトリガのキャッシュ）
呼び起こしトリガ４０２を含み、例えばＣＤＭＡのような無線インフラに到達し、専用のトラフィックチャンネルを持たない聞き手のモバイルに向けられたＩＰデータグラムは、一般にネットワーク、あるいは無線インフラかの何れかによって失われうる。ある実施例では、聞き手モバイルに送信された呼び起こしトリガ４０２は、定義されたスケジュールにしたがって、聞き手の応答またはグループの呼び起こしタイマが終了するまで積極的に再送信される。例えば、呼び起こしトリガ４０２は、５００ｍｓ毎に再送信される。しかしながら、この割合で呼び起こしトリガ４０２を再送信することは、聞き手のトラフィックチャンネルが再確立された時間から、聞き手に向けられた次の呼び起こしトリガがインフラに到達するまでの時間までに、最大で５００ｍｓに至る遅延、平均で２５０ｍｓの遅延をもたらしうる。
【００７３】
ある実施例では、ネットワークにおけるインフラ、あるいはやもう一つのエンティティは、ＣＭによって送信された呼び起こしトリガ４０２をキャッシュし、目標ＭＳがそのトラフィックチャンネルを再確立するとすぐに、それを目標ＭＳに配信する。これは、ＣＭによってなされた呼び起こし要求４１２を再送信する必要性を取り除き、休止呼び起こしに要する合計時間を減少する。例えば、５００ｍｓの割合で再送信することと比べ、呼び起こしトリガ４０２をキャッシュすることによって、休止呼び起こしに要する合計時間から、最大で５００ｍｓに至る遅延を取り除くことができる。
【００７４】
（メディアバッファリング）
ある実施例では、ユーザは、発言制御を要求した後に、クライアントと聞き手との間で専用チャンネルが再確立される前にメディアをバッファすることによって、会話の開始が許可される。話し手の音声をバッファすることによって、聞き手のトラフィックチャンネルが完全に再確立される前に、このシステムは、話し手に対して、会話の開始を許可する。これによって話し手は、より早く話し始めることができるようになり、外見的なＰＴＴ待ち時間を減少させる。聞き手は、ＰＴＴ待ち時間を経験しないので、これによって影響は受けない。すなわち、ＰＴＴ待ち時間は、システムにおける話し手から他の部分へとシフトされる。話し手は、聞き手からの応答を受信するまで待ってから話し始める。しかしながら、前述したとおり、話し手は既に、実際の会話の中でなされる応答よりも、話し始めに対する応答に対して時間が長くかかるであろうことを期待している。話し手による話し始めのバッファリングは、ＣＭ側あるいはクライアントＭＳ側でなされる。
【００７５】
（ＣＭバッファリング）
ある実施例では、ＣＭが話し手による話し始めをバッファする。ユーザが自分のＰＴＴボタンを押し、ユーザのトラフィックチャンネルが再確立された後、ユーザは、ＣＭとの通信を許可される。この時、聞き手のトラフィックチャンネルはまだ確立されていないので、ＣＭは、話し手の音声を、目標である聞き手に対する将来の送信のためにバッファする。ＣＭバッファリングは、話し手のトラフィックチャンネルを引き起こす適切な時間であると話し手がみなしている外見的なＰＴＴ待ち時間を減少する。図５は、ある実施例に従ったＣＭバッファリングを示す図である。
【００７６】
（クライアント側バッファリング）
ある実施例では、より短い外見的な待ち時間が望まれている場合には、話し手は、自分のトラフィックが再確立される前に話し始めることが許可されうる。クライアントＭＳは、ＣＭと未だに通信していないので、会話を開始するための話し手への信号は、クライアントＭＳによって作成される。仮に、話し手のトラフィックチャンネルが再確立される前に話し手に会話が許可された場合には、クライアントＭＳは音声をバッファしうる。ＣＭとの通信が確立されていないので、会話する許可は「楽観的に」与えられる。図６は、ある実施例にしたがったクライアント側によるバッファリングを示す図である。ある実施例では、ＣＭバッファリングとクライアント側バッファリングとは同時に動作しうる。クライアント側バッファリングによって、外見的なＰＴＴ待ち時間を小さくすることができる。
【００７７】
ＣＭバッファリングによって、遅延の合計は変わらないかもしれない。ユーザは、聞き手からの応答の返信を受信する場合、同じ遅延を経験するかもしれないが、話し手の外見的なＰＴＴ遅延は小さくなる。
【００７８】
ある実施例では、クライアントＭＳはメディアをバッファし、ユーザによって経験された外見的なＰＴＴ遅延を制御する。モバイルから発したＳＤＢと、クライアント側におけるメディアバッファの組み合わせによって、動作中のトラフィックチャンネルの再確立に関連した遅延を減少する。
【００７９】
（迅速なページングチャンネル）
ある実施例では、ＣＭは、グループの呼び起こし時間が終了するまでか、または全ての聞き手クライアントが、ネットワークによって開始されたトリガに対して応答し、それぞれのトラフィックチャンネルを生成するまで、話し手のＰＴＴ要求に対し応答することが遅れる。ＣＭは、話し手がグループにおいてメディアをストリームすることが許可される前に、全ての聞き手がページされるまで待機する。グループの聞き手が、ページに対する応答に長い時間を要するほど、話し手によって感じられたＰＴＴ待ち時間もまたより長くなる。
【００８０】
ある実施例では、休止呼び起こし時間の間、各聞き手クライアントには、ＣＭによって個別に一連の呼び起こしトリガが送られる。これが例えばＣＤＭＡのようなインフラに到達することによって、各モバイルに対して１つ以上のページを引き起こす。ページの受信後、各モバイルは、トラフィックチャンネルを再確立し、送信された次の呼び起こし要求を受信し、呼び起こし要求の返答とともにＣＭに対して応答する。聞き手のハンドセットがこのアプリケーションレベル「ping」に対して応答するために要求される時間の大部分は、インフラにおいて、モバイルをページするための適切な時間を待つために費やされる。
【００８１】
バッテリの寿命を温存するために、モバイルは、アイドル状態にある場合、ページングチャンネル内で定義された例えば２０４８の各スロットをコンスタントにモニタする必要はない。むしろモバイルは、その能力に応じて、順方向共通制御チャンネル（Ｆ−ＣＣＣＨ）か、順方向ページングチャンネル（Ｆ−ＰＣＨ）かのいずれかをモニタしうる。さらに、モバイルは、スロット周期インデクスにしたがって、ページングスロットをモニタしうる。
【００８２】
ある実施例では、バッテリ寿命を温存するために、モバイルは、「スロットページング」モードで動作する。このモードでは、モバイルは、短時間の間、周期的に動作し、基地局（ＢＳ）から送られたページを聞く。モバイルが聞く時を知りうるこのＢＳは、特定のページングスロットの間、この特定のモバイルに対してページを送信しうる。
【００８３】
ある実施例では、モバイルが動作し、ページングチャンネルを聞く期間は、スロット周期インデクス（ＳＣＩ）と呼ばれるパラメータによって制御される。ＳＣＩが大きいほど、モバイルが動作し、ページングチャンネルを聞くスロット間時間もまた長くなる。電話機は、大部分の時間は休止中であるために、大きなスロット周期の値は、電話機のスタンバイ時間を増大させるが、この電話機をページする前にＢＳが待たねばならない時間を増加する。
【００８４】
電話機に対するページを遅延させる必要のあるＢＳの合計時間は、ゼロとフルスロット周期との間で変化する。ＢＳがページする必要がある時、電話機のスロットが開始した場合はゼロである。ＢＳが電話機をページする必要がある時まで、電話機のスロットが終了した場合はフルスロット周期である。平均すると、電話機のスロットが到来するのを持つことによる遅延は、スロット周期時間の半分である。モバイルによって使用されたスロット周期が短いほど、聞き手がインフラによってより速くページされる。しかしながら、スロット周期が短くなると、バッテリ消費の割合も高くなる。
【００８５】
ある実施例では、モバイルがページングチャンネルをモニタすることを必要とすることなく未決定のページが存在する時、順方向迅速ページングチャンネル（Ｆ−ＱＰＣＨ）は、このモバイルが、効率的な出力にあることの判定を可能とするために使用される。Ｆ−ＱＰＣＨをモニタすることができるモバイルは、予め定めた数のスロット毎に動作し、ページングチャンネルにおいて、例えば８０ｍｓ以内の１ビットのインディケータの値を抽出する。仮に、抽出されたビットが設定されていない場合には、ページングチャンネルにおいて未決定であるページははなく、別のスロット周期でこのモバイルは休止する。仮に、抽出されたビットが設定されている場合には、このモバイルに対するページは未決定となり、このモバイルは動作を開始し、次の適切なページングチャンネルスロットにおいて、ページングチャンネルをモニタするように自己をスケジュールする。
【００８６】
Ｆ−ＱＰＣＨによって適用された変調によって、このモバイルは、ページングチャンネルをモニタするよりも十分効率的にＦ−ＱＰＣＨをモニタすることができるようになる。これによって、モバイルは、効率的な出力で、極めて短いスロット周期で、効率的に動作できるようになる。Ｆ−ＱＰＣＨを使用することによる１つの利点は、モバイルは、インフラからの一般的なページメッセージ、すなわち、ＣＭからの呼び起こし要求メッセージを同じバッテリ消費率で許容されるよりもより速いスロット周期で検出し、これに応答する手段を備えていることである。これは、遅延の１つの成分を最小化する能力に変わる。つまり、ＰＴＴ待ち時間と、休止呼び起こしに要する合計時間、すなわち聞き手のトラフィックチャンネルの再確立に要する時間に対して直接的に寄与する。
【００８７】
（スロットタイマ）
ある実施例では、このモバイルは、「スロットタイマ」と連結したノンスロットのページングモードで動作しうる。動作状態になった場合、このスロットタイマは、モバイルが、専用トラフィックチャンネルを解放し、スロットタイマによって定義された時間期間のアイドルモードに入ることによって、ノンスロットモードにおけるページングチャンネルをモニタするよう要求する。このタイマの値は、基地局で設定可能である。この機能によってインフラは、アイドルモードの場合、モバイルに対してページングチャンネルにある例えば８０ｍｓの各々のスロットをモニタするよう指示することができる。また、この機能は、インフラに対して、あらゆるスロット内におけるモバイルをページする手段を提供する。迅速なページングチャンネル機能を単独で使用した場合、ノンスロットモードを使用する１つの利点は、同じバッテリ消費率であってもより迅速にページを検出し応答する手段をモバイルのために提供することと、これによって、休止呼び起こし期間において聞き手のトラフィックチャンネルを再確立するために必要な時間を減らすことである。
【００８８】
迅速なページングチャンネル機能が無いと、ノンスロットモニタを長く使用することは、バッテリ寿命の観点から高価なものになりうる。しかしながら、この迅速なページングチャンネルとノンスロットモードとを合わせて使用することによって、例えば８０ｍｓから１６０ｍｓといった１つまたは２つのスロット期間内というように極めて迅速にモバイルをページする手段を提供する。
【００８９】
ノンスロットモードは、移動局に対して有効な２つの中間的な休止のうちの１つとみなすことができる。ノンスロットモードで動作した場合、モバイルは、専用の物理チャンネルを持っていないので、技術的に休止しているものと考えられる。しかしながら、このモードでは、モバイルは、スロットにおいて本質的に直ちにページ化されるので、ネットワークによって開始された再動作にともなうページング遅延は回避される。
【００９０】
（制御ホールドモード）
ある実施例では、モバイルは、パケットデータ規格の下で動作しうる。この規格は、モバイルとインフラがモバイルに関連したＰＰＰ層状態を維持する一方、端末が専用トラフィックチャンネルと、モバイルのパケットデータサービスオプション呼出に関連するリソースとを解放することを許可する付加的な休止／アイドル状態を提供する。モバイルか、またはインフラかの何れか一方は、トラフィックチャンネルを再確立し、ＲＬＰと再交渉することによって、パケットデータ呼出の状態を、休止／アイドル状態から動作状態へと移行させる。トラフィックチャンネルを再確立するために必要な時間は、モバイルまたはインフラが再確立を開始したか否かに依存する。しかしながら、本質的に全てのシステムリソースが要求され、モバイルに割り当てられる必要があるので、何れの場合であっても、この遅延は、システムにおける新たな呼出を生成するために必要な遅延と同等である。
【００９１】
ある実施例では、このモバイルは、動作モードとアイドルモードとの間の中間的なポジションとして動作する「制御ホールド」モードで動作しうる。制御ホールドモードでは、モバイルと関連した専用トラフィックチャンネルは解放され、モバイルの逆パイロットが「ゲート」モードで動作しうる。ある実施例では、専用の共通制御チャンネルおよび／またはＲＬＰ状態もまた管理される。本質的に、制御ホールドモードは、半休止状態を与える。この状態では、ほとんどのシステムリソースが割り当てられているものの、平均的な逆方向リンク送信出力は、システム能力に対するインパクトを低減するために、ゲートパイロットに低減される。図７は、無線モードに対する典型的な構成を示す図である。
【００９２】
ある実施例では、モバイルは、リソース解放要求メッセージかまたはリソース解放要求ミニメッセージかの何れかを送信することによって、動作モードから制御ホールドモードへと移行しうる。モバイルは、リソース要求メッセージかまたはリソース要求ミニメッセージかの何れかを送信することによって、制御ホールドモードから動作モードへと移行しうる。これらのメッセージは専用の制御チャンネルを経由して搬送されうる。そして、ミニメッセージは、より短い、例えば５ｍｓのフレームを用いることによって送信されうる。これによって、制御ホールドモードへの、および制御ホールドからの迅速な移行を可能とする。制御ホールドモードの利点としては、上述したように、伝統的なアイドルモードまたは休止／アイドルモードと比較して、制御ホールドモードから動作モードへの比較的迅速な移行が可能であることである。
【００９３】
ある実施例では、登録済のグループがグループ休止状態に移行したとの表示をＣＭから受信すると、クライアントのモバイルは、制御ホールドモードへの移行をまず開始し、動作の時間が持続した後に、更にアイドルモードへと移行する。したがって、いったんユーザがＰＴＴを押すか、または呼び起こし要求トリガがインフラにおいて受信されると、制御ホールドモードは、専用のトラフィックチャンネルを再確立するために必要な時間を有意に低減するためのメカニズムを提供する。
【００９４】
（格納されたサービス設定）
ある実施例では、インフラは、アイドルモードに移行する場合、モバイルおよびインフラにおけるサービス設定状態をキャッシュまたは格納する能力を与える。動作モードに戻り、トラフィックチャンネルを再確立する場合、モバイルは、呼出に対するサービス設定をキャッシュしたか、または格納したかということを、オリジネーションメッセージまたはページ応答メッセージかの何れかによって示す。モバイルは、また、オリジネーションまたはページ応答メッセージの中に、周期的冗長性チェック（ＣＲＣ）を含みうる。これは、サービス設定の全体長さを通じて計算されうるものである。仮に、基地局もサービス設定をキャッシュした場合には、この基地局は、受信したＣＲＣを使って、サービス設定が、モバイルに格納されたサービス設定と一致していることを確認する。そして、もし一致する場合には、ＢＳは、「サービス接続メッセージ」の中に、このモバイルは、以前に格納されたサービス設定を用いていることを示す。
【００９５】
ある実施例では、アイドルモードから移行する場合には、パケットデータサービスオプションを使用することによって、サービス設定を変更する必要はない。よって、格納されたサービス設定を使用することによって、専用のトラフィックチャンネルリソースを再確立するために必要な時間は有意に減少する。したがって、格納されたサービス設定機能は、ＰＴＴ信号および関連するメディアとの両方を搬送するトラフィックチャンネルの再確立に必要な時間を低減し、ＰＴＴ待ち時間を有意に減少するメカニズムを与えることによって、アイドルモードに対して重要な改善をもたらす。
【００９６】
ある実施例では、クライアントＭＳの動作モードからアイドルモードへの移行は、以下のようにして実現されうる。
１．グループが動作中であり、モバイルが専用のトラフィックチャンネルを持つ。
２．グループのハング時間タイマを超える不動作時間の後、アプリケーション層のグループ休止アナウンスメントが、モバイルの順方向トラフィックチャンネルを通じて受信される。
３．モバイルが、制御ホールドモードへ移行し、サービス設定の状態をキャッシュする。その上、クライアントの基地局もまた、サービス設定の状態をキャッシュする。
４．不動作時間の後、モバイルは、専用チャンネルを解放し、アイドルモードに移行する。モバイルは、インフラによって指示された場合には、迅速なページングチャンネルのモニタリングを開始し、ノンスロットモードに入る。ローカルユーザによるＰＴＴの押圧によるものか、または、ネットワークから発せられる他のグループ参加者からのパケットデータトラフィックかの何れかによって、比較的短い不動作時間である場合には、モバイルは、動作モードに戻る前に、アイドルモードに達しないであろう。この場合、モバイルは専用チャンネルを保持しているので、動作モードへと迅速に戻る。
ある実施例では、休止呼び起こしイベントは、以下のようにして実行される。
１．グループが休止状態にあり、全てのモバイルが、専用の物理チャンネルを持たずアイドル状態にある。モバイルは、迅速なページングチャンネルをモニタしている。
２．ユーザのプッシュトークに応答して、話し手のモバイルが、幾つかの有効な逆方向共通チャンネルを通じて、アプリケーション層の発言要求メッセージとともに、ＣＭに信号を送る。このメッセージは、短いデータバースト形式でありうる。話し手のモバイルは、この点から前にあるユーザメディアのバッファリングを開始しうる。
３．話し手のモバイルは、「オリジネーションメッセージ」をインフラに送信し、トラフィックチャンネルを再確立する。これによって、サービス設定がキャッシュされ、設定データを通じたＣＲＣを含んでいると要求内に示す。これは、話し手のモバイルトラフィックチャンネルを再確立するプロセスを開始する。
４．ＣＭは、発言要求を受信し、裁定プロセスを介してこの要求を認めるか否かを決定し、発言要求応答メッセージを話し手に送る。ＣＭはまた、全ての参加者に対し、一連の呼び起こし要求の送信を開始する。
５．各呼び起こし要求を取得することによって、インフラは、次の適切なスロットを決定する第１の決定によって、各聞き手のモバイルをページする。この第１の決定では、聞き手のモバイルをページし、聞き手のモバイルに対してチャンネルをページングすることについてページが未決定であるスロットに先立ち、Ｆ−ＱＰＣＨを経由して信号化を行う。
６．ページが未決定であるＦ−ＱＰＣＨにおける表示を取得することによって、各聞き手モバイルは、ページのためのページングチャンネルをモニタする。
７．ページングチャンネルにおけるページを取得することによって、各聞き手モバイルは、サービス設定がキャッシュされ、設定データを介したＣＲＣを含んでいることを示したページに対して応答する。これは、聞き手のモバイルトラフィックチャンネルを再確立するプロセスを開始する。
８．話し手のトラフィックチャンネルの確立後に、ＣＭからの次の発言要求応答が話し手において受信される。話し手は、ＣＭに対してメディアのストリーミングを開始する。
９．各聞き手のトラフィックチャンネルの確立後、ＣＭによって送信された次の起こし要求は、聞き手において受信される。聞き手は、呼び起こし応答メッセージを用いて応答する。
１０．一旦全ての聞き手が応答したか、またはグループの呼び起こしタイマが終了すると、ＣＭは、グループへのメディアのストリーミングを開始する。
【００９７】
したがって、以上記載したグループ通信ネットワークにおける待ち時間を減少するための方法および装置に対する実施例は、モバイルが休止状態にあり、トラフィックチャンネルが動作中でない場合であっても、グループ呼出信号を交換することによって、休止呼び起こし時間に要する実際の合計時間と、ＰＴＴ待ち時間とを大幅に減少する。この方法および装置は、短いデータバースト（ＳＤＢ）メッセージ信号を使用することによって、グループ呼出信号を交換する。この方法および装置は、話し手のモバイルと、休止状態にある聞き手のモバイルための専用のトラフィックチャンネルを、並行して都合良く再確立する。
【００９８】
別の実施例では、グループ通信ネットワークにおける休止−呼び起こし待ち時間は、目標聞き手に向けられたネットワークから発せられた呼び起こしトリガをキャッシュし、目標移動局がトラフィックチャンネルを再確立するやいなや呼び起こしトリガを目標移動局に配信することによって減少される。
【００９９】
別の実施例では、グループ通信ネットワークにおいて動作しているモバイルにおける同時サービスオリジネーションおよびページングは、サービスオリジネーションプロセスの完了後に、発言制御要求に対する応答を送信することによって回避される。ある実施例では、仮に、サービスオリジネーションプロセスが完了していない場合には、発言制御要求に対する応答はＳＤＢ型式となる。別の実施例では、このソース通信デバイス用のサービスオリジネーションプロセスは、この応答がソース通信デバイスに送信された後に開始される。
【図面の簡単な説明】
【０１００】
【図１】グループ通信システムを示す図。
【図２】通信デバイスと通信マネジャとの相互作用を示す図。
【図３】ある実施例に係る発言制御要求プロセスのための呼出信号の詳細を示す図。
【図４】ある実施例に係るネットワークによって初期化された休止−呼び起こし（wake up）プロセスのための呼出信号の詳細を示す図。
【図５】ある実施例に係る通信マネジャ側におけるメディアのバッファリングを示す図。
【図６】ある実施例に係るクライアント側におけるメディアのバッファリングを示す図。
【図７】ある実施例に係る典型的な無線リンクモードを示す図。
【符号の説明】
【０１０１】
１００…グループ通信システム、１０２，１０４，１０６，１０８，２０２，２０６，２０８…通信デバイス（ＣＤ）、１１０，２０４…通信マネジャ（ＣＭ）、１１２…セキュリティマネジャ（ＳＭ）、１１６…基地局（ＢＳ）、１１８…衛星ゲートウェイ、１２０…分散型ネットワーク、１２２…モバイル切換センタ（ＭＳＣ）、１２４…公衆通信交換網、１２６…モデムバンク、１２８…ＮＢＳターミナル、２００…ＮＢＳシステム、２１０…セッション開始プロトコルチャンネル（ＳＩＰ）、２１２…ＮＢＳメディア信号チャンネル、２１４…メディアトラフィックチャンネル、３０２…ＰＴＴ発言要求、３０４，４０８…専用トラフィックチャンネル、３０６，４１０…無線リンクプロトコル同期化、３０８，３１０…ＰＴＴ発言制御要求、３１２，３１４…ＰＴＴ発言許可、３１６，４１８…メディア、４０２，４１２…トリガ、４０６…ページ、４１４…呼び起こし応答、４１６…話し手アナウンスメント
【図１】
2004533170.tif 000003
【図２】
2004533170.tif 000004
【図３】
2004533170.tif 000005
【図４】
2004533170.tif 000006
【図５】
2004533170.tif 000007
【図６】
2004533170.tif 000008
【図７】
2004533170.tif 000009
【国際公開パンフレット】
2004533170.tif 000010
2004533170.tif 000011
2004533170.tif 000012
2004533170.tif 000013
2004533170.tif 000014
2004533170.tif 000015
2004533170.tif 000016
2004533170.tif 000017
2004533170.tif 000018
2004533170.tif 000019
2004533170.tif 000020
2004533170.tif 000021
2004533170.tif 000022
2004533170.tif 000023
2004533170.tif 000024
2004533170.tif 000025
2004533170.tif 000026
2004533170.tif 000027
2004533170.tif 000028
2004533170.tif 000029
2004533170.tif 000030
2004533170.tif 000031
2004533170.tif 000032
2004533170.tif 000033
2004533170.tif 000034
2004533170.tif 000035
2004533170.tif 000036
2004533170.tif 000037
2004533170.tif 000038
2004533170.tif 000039
2004533170.tif 000040
2004533170.tif 000041
2004533170.tif 000042
2004533170.tif 000043
2004533170.tif 000044
2004533170.tif 000045
2004533170.tif 000046
【国際調査報告】
2004533170.tif 000047