概要
概説すると、本発明は、無線通信ネットワーク上の無線通信デバイスグループ間でのプッシュ・トゥ・トーク(PTT)コールのような直接グループ通信のレイテンシーを最小化するシステムおよび方法である。無線通信デバイスは、そこからの通信のためのオープンの専用トラフィックチャンネル(open dedicated traffic channel)が無いドーマント状態と、直接通信(direct communication)ストリームを含むように無線デバイスがそこから出て行く通信のための専用のトラフィックチャンネルをオープンするアクティブ状態とを有する。グループ通信ストリームのための無線通信デバイスあるいは間欠通信サーバーのいずれも、無線通信デバイスがドーマント状態からオープンな専用トラフィックチャンネルを有するアクティブ状態に遷移する間、グループ通信ストリームの初期の通信データをバッファリングすることができる。
そのシステムと方法は、グループ通信システム内の送信に先立ち、あるいはその送信の間に、メディアバッファリングを行い、バッファリングは、無線通信デバイスで、あるいはグループ通信サーバーで行う。バッファリングは、ドーマント状態から目覚める(wakeup)期間、無線デバイスのトラフィックチャンネルを持ち出す(bringing up)ことに関連する話し手(talker)から遅れを隠すために使用される。特に、クライアントベースのメディアバッファリングは、ドーマント状態から目覚める(wakeup)期間、話し手(talker)のトラフィックチャンネルを持ち出す(bringing up)ことに関連する遅れを隠すために使用され、一方、メディアバッファリングは、ドーマント状態から目覚める(wakeup)期間、聞き手(listener)のトラフィックチャンネルを持ち出すことに関連する遅れを隠すために使用される。
一般に、従来のパケットデータ・アプリケーション上の音声でのリアルタイムメディアのバッファリングは、また、ネットワークジッタを滑らかにするために使用することができる。1つの実施例では、無線デバイスは、ネットワークジッタあるいは他のセットアップ問題を補償するために、メディアプレーアウトバッファーをインプリメントする。
1つの実施例では、無線通信デバイスは、単一のグループ通信ストリームを無線通信ネットワークを通して複数の無線通信デバイスの指定された1つのグループに導くことができ、その無線通信デバイスは、そこからの通信のためのオープンな専用トラフィックチャンネルが無いドーマント状態と、その無線通信デバイスからの直接通信ストリームを含むように無線デバイスがそこから出て行く通信のための専用のトラフィックチャンネルをオープンするアクティブ状態とを有する。無線通信デバイスは、さらに、その無線通信デバイスが、少なくともドーマント状態からオープンな専用トラフィックチャンネルを持ったアクティブ状態に変化する間、グループ通信ストリームの初期の通信情報を選択的にバッファリングするためのデータストア(data store)を含む。
1つの実施例では、無線通信ネットワーク上の無線通信デバイスからの初期のグループ通信データをバッファリングするシステムは、複数の無線通信デバイスを含み、そのうちの少なくとも1つの無線デバイスは、無線通信ネットワークを介して単一のグループ通信ストリームを複数の無線通信デバイスの1つの指定されたグループに導き、その無線通信デバイスはそこからの通信のためのオープンの専用トラフィックチャンネルが無いドーマント状態と、その無線通信デバイスからの直接通信ストリームを含むように無線デバイスがそこから出て行く通信のための専用のトラフィックチャンネルをオープンするアクティブ状態を有する。システムは、さらに、通信サーバーを含み、通信サーバーは、入ってくるグループ通信データストリームを選択的に受け取り、グループ通信データをそのグループ通信ストリームのターゲットグループの他のメンバーに送る。さらに、通信サーバーは、ドーマント状態の無線通信デバイスのために意図されたグループ通信ストリームの通信データを選択的にバッファリングするためのデータストアを含み、ドーマント状態の無線通信デバイスに対して専用のトラフィックチャンネルがオープンされている間、少なくともいくつかの通信データがバッファリングされる。
1つの実施例では、無線通信ネットワーク上の無線通信デバイスからの初期のグループ通信データをバッファリングする方法は、送りの無線通信デバイス(sending wireless telecommunication device)から、通信サーバーを介して、無線通信ネットワーク中の複数の無線通信デバイスの指定された1つのグループへの単一のグループ通信ストリームを開始するステップを含み、送信の無線通信デバイスは、そこからの通信のためのオープンの専用トラフィックチャンネルが無いドーマント状態と、その無線通信デバイスから出て行く通信のための専用のトラフィックチャンネルをオープンしているアクティブ状態とを有し、通信サーバーは、入ってくるグループ通信データストリームを選択的に受け取り、グループ通信データをそのグループ通信ストリームのターゲットグループの他のメンバーに送り、その後、ドーマント状態の無線通信デバイスからの、あるいはドーマント状態の無線通信デバイスへのグループ通信ストリームの通信データを、無線デバイスあるいは通信サーバーのいずれかのデータストア中に選択的にバッファリングし、初期の通信データは、少なくとも専用のトラフィックチャンネルがドーマントの無線通信デバイスにオープンされている間はバッファリングされ、次に、アクティブチャンネルが送信あるいは受信の無線通信デバイスにオープンされた後、バッファリングされた初期の通信データはデータストアからターゲットグループに送られる。
したがって、システムと方法は、話し手がグループ通信を送信することができるように無線通信デバイスが十分なアクティブ専用トラフィックチャンネルを確立したという肯定応答を話し手が待つ必要がない、プッシュ・トゥ・トーク・システムを提供することができる。信号チャンネル上で送られているデータの使用を通じて、初期のグループ通信データは、チャンネルがターゲットデバイスに対して開かれている間話し手にとって透明に、通信サーバーにおいてバッファリングされる。さらに、データのバッファリングはクライアントデバイスにおいて行うことも可能で、グループ通信機能を有する既存の無線通信システム上でインプリメントされる。
本発明の他の目的、利点および特徴は、以下に記載された図面の概要、発明の詳細な説明および請求項のレビューの後に明白となろう。
詳細な説明
全体を通して同様の番号が同様のエレメントを表わす図に関して、図1は、無線ネットワーク20上の無線通信デバイスグループ(ターゲットセット12)間の無線通信システム10の1つの実施例を示す。ここで、無線電話14、スマートページャー16および携帯情報端末(PDA)18のような1つ以上の無線通信デバイスは、無線ネットワーク20を通して他の無線通信デバイスと共に、1つのPTTグループにある。システム10において、各無線通信デバイス14、16、18は、無線通信ネットワーク20を通して他の1つ以上の無線通信デバイスのターゲットセット12(複数)と選択的、直接的に通信することができる。例えば、携帯電話14用のターゲットセットは、ターゲットセット12中のすべてのデバイスであり得、あるいは、ページャー16およびPDA 18のような、そのサブグループであり得る。
特に、システム10は、音声データ、マルチメディアあるいは他の申込者のようなメディアをアドホック形式で定義された非常に大規模なプッシュ・トゥ・トーク(あるいは他の同様のサービス)コールに伝えることができる。これらのPTTコールは、オペレーターの無線ネットワーク20を通して散在し、あるいは同じネットワーク資源上の少数のセクターにすべてが位置している、非常に多くのコールの参加者(数百)を含むことができる。更に、ターゲットセット12(あるいはグループ)は、ただ1つのターゲット無線デバイスを含むことができる。そのような場合は、PTT通信は、単に1つの無線デバイスからPTTシステムを介して他のデバイスに伝わる。
1つの実施例では、グループ通信サーバー32は、通信している無線通信デバイス14、16、18と、通信する無線通信デバイスとして指定されたターゲットセット12中の1つ以上の他の無線通信デバイスとの間の直通通信をブリッジ(bridge)するための要求を選択的に受け取る。その後、通信サーバー32は、PTT音声通信のような要求された直通通信を選択的にブリッジする。ターゲットセット12の同一性(identity)は、グループ通信サーバー32上のレジデント、あるいは、接続されているデータベース34中、あるいは、おそらくパケットフロー・コントロールサーバー36(ネットワークインフラでは一般的なように)のような別のコンピュータ上のレジデントであるように、グループ通信サーバー32によって選択的に利用可能である。
システム10は、無線ネットワーク20上の無線通信デバイス(セット12)グループ中の直接グループ通信のレイテンシーを最小化する。無線通信デバイス装置14、16、18はそれぞれ、複数の無線通信デバイスの指定されたグループ(セット12のすべてのデバイスのような)に単一のグループ通信ストリームを導くことができ、また、ここでさらに記述されるように、各無線通信デバイス14、16、18は選択的に要求し、そして、その無線通信デバイスから出て行く通信(それは直通通信ストリームを含むことができる)のためのオープンの専用ブロードキャストチャンネルを受信する。通信している無線デバイスから単一の通信ストリームを受け取る通信サーバー32は、典型的には、指定されたグループのすべての無線デバイス14、16、18へのグループ通信を生成する。
無線通信デバイス14、16、18は、そこからの通信のためのオープンの専用トラフィックチャンネルが無いドーマント状態と、その無線デバイスが、PTT通信のような直通通信を含むために出て行く通信用の専用トラフィックチャンネルをオープンするアクティブ状態とを有する。ここで、無線通信デバイスは、さらに、グループ通信ストリームの初期の通信データを選択的にバッファリングするためのデータストア(無線デバイス14上のローカルデータベース90あるいはメモリ88のような)を含み、少なくとも、無線通信デバイス14、16、18がドーマント状態からオープンな専用トラフィックチャンネルを持ったアクティブ状態に遷移する間、初期の通信データをバッファリングする。所定の時間期間が経過した後、無線通信デバイス14、16、18はバッファリングされた初期のグループ通信データを送出し、あるいは、アクティブな専用のトラフィックチャンネルがオープンした後、バッファリングされた初期のグループ通信データを送出することができる。データストア(無線デバイスあるいは通信サーバー32のいずれかに位置した)は、さらに、以下に述べるように、グループ通信ストリームの中断と同時にバッファリングされたグループ通信ストリームをパージ(purge)する。他の方法で述べられない限り、本願における用語「バッファリング」は、送信に先立ってバッファリングすることを指す(ボコーダーにおける、プレーアウトあるいはプレゼンテーションに先立つバッファリングとは異なり)。
図2に示されるように、典型的には、通信サーバー32と無線通信デバイスグループ12との間に通信ストリームをブリッジする1つ以上の間欠的な通信デバイスが存在する。また、通信サーバー32は、さらに、どの無線通信デバイスのメンバーが無線デバイス14、16、18との通信の最良のモードを決定できるかを決定することができる。通信サーバー32は、その後、セット12のそれらの無線通信デバイスにデータパケットを送信するよう、1つ以上の間欠的通信デバイスに指示する。
図2は、通常のセルラー通信構成における無線ネットワークの1つの実施例の代表的なダイアグラムであり、PTTシステムでのセットグループメンバーの無線デバイス(デバイス70、72、74、76)間の通信を制御するグループ通信サーバー32を有する。無線ネットワークは単に典型的なものであって、それによって遠隔のモジュールがエアを通して互いの間で、および/または、無線ネットワークキャリアおよび/またはサーバーを制限なしで含む、無線ネットワーク20のコンポーネント間で、通信する任意のシステムを含むことができる。一連のグループ通信サーバー32は、グループ通信サーバーLAN 50に接続される。無線電話は、データサービスオプションを使用して、グループ通信サーバー32(複数のサーバーでもよい)からパケットデータセッション(CDMAのような)を要求することができる。
グループ通信サーバー32は、ここではキャリアネットワーク54上のレジデントであるPSDN52のような無線サービスプロバイダー・パケットデータサービスノード(PDSN)に接続される。PSDN 52はそれぞれ、パケット制御機能(PCF)62を介して基地局60の基地局制御装置(BSC)64とインターフェースすることができる。PCF 62は、典型的には基地局60中に位置する。キャリアネットワーク54は、メッセージサービス制御装置(「MSC」)58に送られるメッセージ(一般に、データパケット形式)を制御する。キャリアネットワーク30は、ネットワーク、インターネットおよび/またはPOTS(「通常の音声電話システム」)によってMSC32と通信する。典型的には、キャリアネットワーク54とMSC 58との間のネットワークあるいはインターネット接続はデータを転送し、POTSは音声情報を転送する。MSC 58は、1つ以上の基地局60に接続することができる。キャリアネットワークと似た方法で、MSC 58は、典型的には、データ転送用のネットワークおよび/またはインターネットと音情報用のPOTSの両方によって、ブランチ−トゥ−ソース(BTS)66に接続される。BTS 66は、結局、ショートメッセージサービス(「SMS」)あるいはこの技術において既知の他の放送手段によって携帯電話70、72、74、76のような無線デバイスに無線でメッセージをブロードキャストし、また無線デバイスから無線でメッセージを受信する。
グループメンバーのセット12を指定した無線デバイスにおいて、その無線デバイスは、直接、そのセットの別のメンバーに接続して、音声およびデータ通信に携わることができる。しかしながら、すべてのそのような直接通信は、グループ通信サーバー32を介して、あるいはそのコントロール下で発生する。デバイスのすべてのデータパケットは、必ずしもグループ通信サーバー32それ自体を通って移動する必要はない。しかし、サーバー32は、結局、通信を制御できなければならない。なぜなら、サーバー32は、典型的には、セット12のメンバーの同一性(identity)を知り、および/または検索でき、あるいは、セット12のメンバーの同一性を他のコンピュータデバイスに導くことができるただ1つのサーバー側LAN30のコンポーネントとなるからである。
1つの PTT実施例では、無線システム10は、標準の商用無線インフラストラクチャー(CDMA、FDMA、GSMなど)上で作動する音声ディスパッチサービスを可能にする。ディスパッチモデルでは、終点(無線デバイス14、16、18)間の通信は仮想のグループ内で発生し、そこでは、1つの「話し手(talker)」の声が1つ以上の「聞き手(listener)」にブロードキャストされる。このタイプの通信の単一のインスタンスは、通常、「ディスパッチコール」と呼ばれる。コールは「グループ」のインスタンス化であり、それは、コールの特性を定義する。本質的なグループは、グループ名またはグループIDのような、メンバーリストと関連情報によって定義される。無線マルチキャストチャンネルがない状態で、各グループは、各終点とコールを管理するために割り当てられたグループ通信サーバー32(複数でもよい)との間の個別のポイント・トゥ・ポイントの組み合わせによって形成される。
PTTインフラストラクチャーの各領域は、キャリアパケットデータネットワークの特定部分上に展開される。領域内のグループ通信サーバー32(複数でもよい)は、キャリアネットワーク54中の1つ以上のPDSN 52の間のトラフィックを定めている。「ダイレクトコール」は、それでもなおPTTシステムを使用する、単に2人のメンバー、発信者(call originator)とコールターゲット(call target)だけがあるコールである。このコールのタイプについては、パフォーマンス要件に合致するための最も挑戦的なシナリオは、発信者とターゲットハンドセットの双方がドーマント・パケットデータ接続の状態、つまり、無線デバイス14、16、18がオープンの専用チャンネルを持たない状態でダイレクトコールがプレースされる場合である。反対に、発信者および/またはターゲットのパケットデータ接続はアクティブ状態にあり、専用トラフィックチャネルは、ダイレクトコールがプレースされている時に利用可能である。ドーマントからドーマントへのシナリオ(dormant-to-dormant scenario)は、パフォーマンス要件に合致する最も大きな挑戦を提供するものであり、ここにおいてより完全に記述されるように、それはコールセットアップにおける顕著なレイテンシーを防止する。
図3は、デバイスのターゲットセット12に直接通信を開くPTTボタン78を備えた携帯電話14である無線通信デバイスの一実施例を示すブロック図である。無線デバイス14は、また、無線デバイス14のユーザーに対するグラフィックスディスプレイ80を持つものとして示されている。無線デバイス14はコンピュータ・プラットフォーム82を含み、プラットフォーム82は音声パケットおよびデータパケットを扱うことができ、無線ネットワーク20を通して送信されたソフトウェアアプリケーションを受け取り、実行することができる。コンピュータ・プラットフォーム82は、他のコンポーネントの中で、特定用途向けIC(「ASIC」)84、あるいは他のプロセッサー、マイクロプロセッサー、論理回路プログラマブルゲートアレイ、あるいは他のデータ処理デバイスを含む。ASIC 84は無線デバイスの製造時にインストールされ、通常、アップグレードはできない。ASIC 84あるいは他のプロセッサーは、アプリケーション・プログラミング・インターフェース(API)層86(それは常駐アプリケーション環境を含む)を実行し、ASIC 84に搭載されたオペレーティングシステムを含むことができる。常駐アプリケーション環境は、無線デバイスのメモリ88中の任意の常駐プログラムとインターフェースする。常駐アプリケーション環境の一例は、クアルコム社によって無線デバイスプラットフォーム用に開発された「無線用バイナリー・ランタイム環境(binary runtime environment for wireless)」(BREW(登録商標))ソフトウェアである。
ここに示されるように、無線デバイスはグラフィックスディスプレイを備えた携帯電話14であるが、携帯情報端末(PDA)、グラフィックスディスプレイを備えたページャー、あるいは、無線通信ポータルを有し、もしくはネットワークまたはインターネットに対して有線接続を有する別個のコンピュータ・プラットフォームなどのような、この技術分野で知られているコンピュータ・プラットフォームを備えた任意の無線デバイスであってもよい。さらに、メモリ88はリードオンリーまたはランダムアクセスメモリ(RAM、ROM)、EPROM、EEPROM、フラッシュカード、あるいはコンピュータ・プラットフォームで通常の任意のメモリで構成することができる。コンピュータ・プラットフォーム82は、また、メモリ88中では積極的に使用されないソフトウェアアプリケーションを記憶するためのローカルデータベース90を含むことができる。ローカルデータベース90は、典型的には、1つ以上のフラッシュメモリセルで構成されるが、磁気媒体、EPROM、EEPROM、光学的媒体、テープ、あるいはソフトまたはハードディスクのようなこの技術分野で知られている任意の二次的あるいは三次的記憶デバイスであってもよい。ローカルデータベース90あるいはメモリは、バッファリングされる直接グループ通信データ用のデータストアを含むことができる。無線電話は、典型的には、遠隔通信のために全2重チャンネル(full duplex channel)をオープンし、また、いくつかの場合においては半2重チャンネルを介して単に話すだけあるいは音声ストリームを受け取るだけの通信を行う。
無線デバイス14のこの実施例では、コンピュータ・プラットフォーム82は、また、通信インターフェース92を含み、このインターフェース92は無線デバイスからの直接通信チャンネルをオープンすることができる直接通信インターフェース94を含む。直接通信インターフェース94は、さらに、通常、無線デバイスにあるいは無線デバイスから送信された音声およびデータを運ぶ無線デバイス用の標準通信インターフェースの一部であり得る。直通無線インターフェース92は、典型的には、この技術分野で知られているようにハードウェアで構成される。
図4は、PTT通信を確立するためのアプリケーション層シグナリング用のコール進行ダイアグラムである。制御チャンネルのような単なる一般的な共有フォワードリンクチャンネルとは違って、コールセットアップシグナリングが形式上のブロードキャストチャンネルを介して発生することに注目されたい。例えば、現存するある遠隔通信システムでは、制御チャンネル(CC)および別個のブロードキャストチャンネル(BCH)が使用される。ダイレクトコールにおける重要な性能上のメトリクスは、ユーザーがPTTボタンを押す時とユーザーが(音もしくは視覚手段のいずれかによって)通話許可を通知される時との間の時間遅れが具現されるところの、初期のPTTレイテンシー(initial PTT latency)(図示)を含む。また、コールが最初に確立された後のフロア許可に続いて発信者が話し始める時からターゲットが発信者の話しを聞くまでの間で現実化されるところの遅れで構成される、初期のメディアレイテンシー(initial media latency)(図示)がある。
ダイレクトコール確立のための図4に示されたアプリケーション層シグナリングは、直接PTTコール(direct PTT call)を確立するためのアプリケーション層メッセージングに交換して示されている。図4のダイアグラムは、このシステムが様々な異なる物理的システム上でインプリメントされ得ることから、いかなる物理層シグナリング機構も識別しない。
図5は、アラート(alert)を確立するためのアプリケーション層シグナリング用のコール進行ダイアグラムである。「アラート」は、あるユーザーが直接PTTコールで望みの通信相手である他のユーザーに通知する機構を提供するコール形式である。アラートコールは、少数の短いアプリケーション層メッセージが発信者、グループ通信サーバー32およびターゲット無線デバイス12、14、16、18で交換された後、完了される。ダイレクトコール形式について記述されたように、アラートに関してパフォーマンス要件に合致する最も挑戦的なシナリオは、アラートが送られ、発信者およびターゲットハンドセットの双方がドーマントのパケットデータ接続の場合、つまり、アクティブな専用チャンネルを持っていない場合である。したがって、アラートレイテンシー(図示)は、ユーザーがPTTボタン78を押す時からユーザーがアラート伝送の状態を通知される(音もしくは視覚手段のいずれかによって)までの時間遅れである。アラートは物理層で確立することができるため、このダイアグラムは物理層シグナリング機構を識別しない。
図6は、クライアント−メディア・バッファリング・イベント・タイムラインを示す通信進行ダイアグラムである。1つの実施例では、コンピュータ・プラットフォーム82上に常駐するクライアント管理ソフトウェアは、ドーマンシー・ウェイクアップ(dormancy wakeup)の間、典型的には、8秒以内で、メディアをバッファーすることができるメディア送信キュー(media transmission queue)をインプリメントする。このデバイス実施例の中では、バッファリングは、PTXドーマンシー応答タイマーおよびウェイクアップタイマーの相互の設定によって制御される。具体的には、メディアは、PTXドーマンシー応答タイマーが終了する時点からウェイクアップタイマーが終了する時点までバッファリングされる。一般に、PTXドーマンシー応答タイマーは、ウェイクアップタイマー以下である。もし、これらのタイマーが値において等しく構成される場合は、CMメディアのバッファリングは実行されない。一般に、グループドーマンシーウェイクアップ推移は、直線的に進行する。グループは、ユーザーが「話し手」クライアント("talker" client)上でプッシュ・トゥ・トーク・ボタン78を押すまではドーマントである。その後、話し手クライアントはトラフィックチャンネルを持ち出し(brings up)、PTT要求を送信する。通信サーバー32はPTT要求を受け取り、フロアの許可を決定する。通信サーバー32は、PTXドーマンシー応答タイマー、ウェイクアップタイマーおよびレイトライザータイマー(Late Riser timer)を初期化し、次に、すべてのグループ聞き手参加者にウェイクアップ要求を送り始める。PTXドーマンシー応答タイマーが終了し、通信サーバー32は話し手クライアント(無線デバイス14、16、18)にPTX許可を送る。話し手クライアントはPTX許可を受け取り、ユーザーに警報し、通信サーバー32にメディアのストリーミングを開始する。この実施例では、通信サーバー32は、話し手クライアントから受け取られたメディアをバッファリングする。その後、ウェイクアップタイマーが終了し、通信サーバー32は話し手に通知(PTAの許可)し、そして、グループの聞き手に向けてメディアの中継を開始する。その後、話し手クライアントがフロアを解放してメディアのストリーミングを停止すると、通信サーバー32はPTT解放(PTT release)を受け取り、直ちに、話し手クライアントにPTX確認を応答する。その後、通信サーバーは、話し手データのデータストア(メディアバッファー)を空にし、トークスパート(talk-spurt)の終了(PTAの解放)を通知する。
通信サーバー32でのメディアのバッファリングは、グループのウェイクアップタイマーが終了する前に、話し手クライアントのPTT要求に対して応答することを可能にする。もし、PTXドーマンシー応答タイマーが0にセットされると、CMはPTT要求に(本質的に)直ちに応答し、話し手クライアントは、話し手自身のトラフィックチャンネルを再確立する際の遅れ以外にドーマンシー・ウェイクアップによる追加の遅れは経験しない。
名目上、典型的なPTTシステムで、グループがドーマントでない場合、話し手クライアントはそのPTT要求に対する応答をおよそ300ミリ秒以内に受け取る。しかしながら、ドーマントから回復中のいくつかのシステムにおいては、話し手クライアントのトラフィックチャンネルが再確立された後までPTT要求を送ることができない。そのようなシステムでは、典型的には、ドーマントパケットデータサービスオプションの再確立に関連した3秒の遅れが生じる。もし、メディアが話し手クライアントもしくは通信サーバー32においてバッファリングされなければ、(話し手)ユーザーはPTTレイテンシーとしてこの遅れを経験する。
ドーマントでないときに経験されるものと本質的に同じPTTレイテンシーをユーザーに提供するために、この実施例では、ユーザーがドーマントグループ中のPTTを押し、クライアントのパケットデータサービスがドーマントの場合に、話し手クライアント(無線デバイス14のような)はメディアをバッファリングする。もし、グループはドーマントであるが、ユーザーがPTTを押した時にクライアントが既にアクティブなパケットデータトラフィックチャンネルを有している場合は、クライアントは、メディアをバッファーせずに、直ちにPTT許可を送り、PTX応答を待つことができる。メディアバッファリングは、グループの構成によってはCMにおいても起こるかもしれない。ここで、ダイアグラムは、グループがドーマントで、また、トラフィックチャンネルが割り付けられないと仮定している。図6に示されるように、100でユーザーがPTTを押し、102でクライアントがパケットデータトラフィックチャンネルの再確立を開始する。104で、クライアントは、フロアが付与されてメディアのバッファリングを開始することを、ユーザーに通報する。通報は、ユーザーアクションのおよそ300-500ミリ秒以内で発生する。106で専用のトラフィックチャネルが形式的に再確立される。クライアントは通信サーバー32にPTT要求を送信する。108で、クライアントは通信サーバー32からのPTX許可応答を受け取る。110で、クライアントは通信サーバー32にバッファリングされたメディアのストリーミングを開始する。112で、話し手クライアントはPTX許可を受け取り、ユーザーに通報し、通信サーバー32へのメディアのストリーミングを開始する。114で、ユーザーはPTTボタン78を解放する。116で、クライアントは、通信サーバー32へのバッファリングされたメディアのストリーミングを終え、通信サーバー32にPTT解放を送信する。118で、クライアントは、通信サーバー32から、トークスパートの終了を示すPTX確認応答を受け取る。
グループがドーマントであると仮定すると、話し手ユーザーが聞くだけの特権を持っている場合にのみ話し手クライアントはフロアを拒否され、PTXドーマンシー応答タイマーが終了する前により高い優先権を持つユーザーが割り込むか、あるいは、話し手ユーザーはグループ内のアクティブな参加者として残る唯一のユーザーである。もし、クライアントが、グループ加入に際して通信サーバー32に「聞くだけ」の条件を求める能力を持っている場合は、クライアントは、通信サーバー32をシグナリングせずに、あるいはトラフィックチャネルの再確立を試みずに、ユーザーのPTT要求をローカルに否定するかもしれない。
グループのPTXドーマンシー応答タイマーが終了する前に、より高い優先権を持つユーザーにフロアが付与される結果として最終的にフロアが付与されないかも知れないが、ユーザーは、ドーマントグループにおいて話し手特権を持って、フロアが付与されることを期待してPTTを押すことは可能である。この種の割込みは、PTXドーマンシー応答タイマーがゼロでない場合にのみ発生し得る。もし、ドーマンシー・ウェイクアップの間のPTTレイテンシーが問題であれば、通信サーバー32によるメディアバッファリングの利点を十分得るために、PTXドーマンシー応答タイマーはゼロで構成されるべきであり、それによってこの場合は回避することができる。
もし、PTX応答が通信サーバー32から受け取られる前にユーザーがPTTを解放すれば、話し手クライアントはPTX応答を受信するまで、あるいは、要求が失敗するまで、バッファーされたトークスパートを保持しなければならない。もし、PTX許可応答が受け取られると、トークスパートは正常に通信サーバー32に流される。もし、ユーザーの解放後にそのような要求が失敗するか、PTX不許可を受信した場合は、トークスパートは中断される。ユーザーが、彼または彼女がグループのフロア管理をしていると信じていても、話し手クライアントは様々な例外的なイベントを扱う準備をしなければならない。話し手クライアントは、典型的には少なくとも2つの状況で進行中のトークスパートを終了する非同期PTXを受け取る(PTX許可が受け取られた後に)ことができる。2つの状況とは、話し手がグループのフェールセーフタイマーを過ぎてフロアを保持するか、あるいは、話し手がより高い優先権のユーザーによって中断されるかである。これらの場合は、話し手クライアントは、ユーザーに例外的条件であることを警告してトークスパートを中断し、通信サーバー32へのメディアの流れを止めてドーマント状態に移行する。
話し手クライアントでのメディアのバッファリングは、PTX許可を受け取る前に、あるいは、PTX許可を受け取ることなく、トークスパートを中断する可能性を導入することに注目すべきである。もし、中断が生じるときに話し手ユーザーが話していれば、話し手クライアントは、メディアがバッファーされていない時に使用される機構と同じ、もしくは同様の機構によって、ユーザーに警報することができる。ユーザーの経験は割込みに類似しており、ユーザーは話した話はすべて警報前にグループに伝わったと期待するとしても、実際は、伝達されたのはトークスパートの小さい部分だけ(場合によっては、無)である。
PTX許可の受信に先立って生じるトークスパートの中断はまれである。クライアントがグループのフェールセーフタイマーを過ぎたトークスパートを延長するために十分なメディアをバッファーするということは、非常にありそうもない。実際、グループのフェールセーフタイマーをクライアントのバッファリングキャパシティーを超える値に構成することによって、この状況を完全に回避することが可能である。これは、クライアントがバッファーされたメディアをそれが集められたのと同じレートで送信すると仮定している。現実的には、メディアバッファーはほとんどの場合、最大許容のトークスパートの予期される長さよりも比較的小さい。しかしながら、もし、グループがドーマントのときに2人以上のユーザーがほぼ同時にトークスパートを開始し、また、もし、それらのユーザーが等しい優先権を持っておらず、より低い優先権のユーザーに最初にフロアが与えられれば、上に記述されるように、より低い優先権のユーザーがトークスパートの中断を経験する可能性はある。
名目上、クライアントは、メディアが集められるのと同じレートで送信用のメディアを運ぶ。言い換えれば、20ミリ秒のボコーダーフレームを含んでいる1つのパケットは、20ミリ秒ごとに送信される。クライアントはバッファーされたメディアを、この同じレートで送信しなければならない。シグナリングトラフィックおよび他の遅れの存在により、クライアントが送信においてメディアにいくらかのジッタを導入する可能性がある。また、可変レートのボコーダーが使用される場合は、可変レートのメディアデータレート(集められたヘッダーを備えた)は、対応するトラフィックチャネルのキャパシティより低いため、クライアントは、メディアを20ミリ秒ごとの1フレームよりも速い、一定の保持されたレートで転送する。圧倒的な聞き手クライアントのトラフィックチャンネルとプレーアウトのバッファーを回避するために、話し手クライアントは、保持されたメディアの送信を、20ミリ秒ごとに1フレームの名目上のフレームレートよりも速いレートにすべきではない。同様に、通信サーバー32は、概して、それが受け取られたのと同じ割合でメディアを再放送するべきである。
1つの実施例では、メディアバッファリングを実行するためにクライアントメモリ88が用意される。このバッファーの最大サイズは、クライアントがPTX許可の受信を待つ間にメディアをバッファリングすることができる最大時間を決定する。例えば、クライアントがUDPデータグラム当たり5つのボコーダーフレームを100ミリ秒ごとにカプセル化する場合、クライアントはRTPを使用してボコーダーフレームをカプセル化し、各UDPペイロードは、100ミリ秒ごとに、5つのハーフレートのボコーダーフレーム(合計85バイト、各17バイト)、1つのメディアヘッダー(1バイト)、1つのRTPヘッダ(12バイト)の計98バイトで構成される。したがって、クライアントが各RTPメディアペイロードを備えた1つのRTPヘッダーをバッファーした場合、980バイト/秒、あるいは、7840bpsのバッファリングデータレートが生成されることなる。ユーザーに話すように促すこととCMからのPTX応答を受け取ることとの間に10秒が予期される最悪の場合の遅れから生き残るために、クライアントでは9800バイトのバッファーが必要であろう。もし、クライアントがRTPおよびボコーダーフレームを備えたメディアヘッダーをバッファリングしない場合、わずかに複雑なクライアントインプリメンテーションを犠牲にすれば、バッファーメモリでのさらなる蓄積を達成することができる。
図7は、アクティブなトラフィックチャンネルがセットアップされている間に無線デバイスのデータストア(メモリ88)で初期のFXTメディアをバッファリングするプロセスの1つの実施例のフローチャートである。ステップ120で示されるように、ユーザーはPTTボタン78を押し、次に、ステップ122で示されたように、フロア許可の肯定応答を受け取り、彼または彼女が話し始めることができることをユーザーに示す。ユーザーの初期のグループ通信データは、その後、ステップ124で示されるようにデバイスデータストア(メモリ88)に保存され、そして、ステップ126で示されるように、無線デバイス14、16、18への専用のアクティブトラフィックチャンネルを確立するために、予め定義されたプロセスが実行される。
その後、決定ステップ128で示されるように、無線デバイス14、16、18にアクティブなトラフィックチャンネルがオープンされたかどうかの決定がなされる。もし、ステップ128でチャンネルがオープンされていない場合は、ステップ130で示されるように、バッファーはパージされ、プロセスはユーザーへのエラー出力で終了する。そうではなく、ステップ128でアクティブチャンネルが確立されている場合は、ステップ132で示されるように、クライアントデバイスはトラフィックチャンネルを通してバッファーからメディアを流す。その後、決定ステップ134で示されるように、ユーザーによってPTTボタン78が解放されたかどうかが決定される。もし、PTTが解放されていない場合は、ステップ132を繰り返し、メディアのストリーミングを継続する。そうではなく、ステップ134でPTTが解放されている場合は、次に、ステップ136で示されるように、バッファー中の残存データが通信サーバー32に流されてPTT送信は終了する。
図8は、アクティブトラフィックチャンネルが受信無線デバイスにセットアップされている間に、グループ通信サーバー32が初期のPTTデータを受け取ってバッファーするための実行プロセスの1つの実施例のフローチャートである。バッファリングは、通信サーバー32で、あるいは、データベース34のような付属のデータストアで発生することができる。通信サーバー32は、ステップ140で示されるように、無線デバイス14、16、18からグループ通信要求を受け取り、次に、通信サーバー32との通信を始めるために無線デバイス14、16、18に許可を送る。その後、通信サーバー32は、ステップ144で示されるように、無線デバイスから初期のグループ通信データの受信を開始し、そしてステップ146で示されるように、初期の通信データのバッファリングを開始する。その後、予め決められたプロセス148で示されるように、ターゲット無線デバイスにアクティブな専用トラフィックチャンネルが確立される。
その後、決定ステップ150で示されるように、受信無線デバイス14、16、18にアクティブトラフィックチャンネルがオープンされているかどうかについて決定される。もし、ステップ150で専用のトラフィックチャンネルがオープンされていない場合は、いかなるプレーアウトも停止され、ステップ152で示されるようにバッファーがパージされ、プロセスはエラー出力で終了する。そうでなく、ステップ150でチャンネルがオープンされている場合は、メディアはバッファーから流され、ステップ154で示されるようにグループ通信が実行され、次に、決定ステップ156で示されるように、グループ通信が終了したかどうかについて決定される。もし、グループ通信ストリームがなされない場合(つまり、ユーザーがPTTボタン78を解放していた場合)は、プロセスはステップ154へと繰り返し、メディアのストリーミングを継続する。そうではなく、グループ通信ストリームがステップ156で終了している場合、ステップ158で示されるように、バッファー中の残存データがグループに送られ、グループ通信が終了する。
このように、システム10は、無線通信ネットワーク20上の無線通信デバイス14、16、18からの初期のグループ通信データをバッファリングするための方法を提供し、この方法は、そこからの通信のためのオープンの専用トラフィックチャンネルが無いドーマント状態と、出て行く通信のためのオープンの専用トラフィックチャンネルを有するアクティブ状態とを有する送りの(および/または、受けの)無線通信デバイス14によって、送りの無線通信デバイス14、16、18から複数無線デバイスの指定グループ12への単一のグループ通信ストリームを無線通信ネットワークを通して通信サーバー32を介して開始するステップ(ここで、通信サーバー32は、その後、入ってくるグループ通信データストリームを選択的に受信し、グループ通信データをグループ通信ストリーム用にターゲットグループ12の他のメンバーに送信する。)と、少なくともドーマントの無線通信デバイス14,16,18に専用のトラフィックチャンネルがオープンされる間、ドーマントの無線通信デバイス14,16,18からのグループ通信ストリームの少なくとも初期の通信データをデータストア(通信サーバー32もしくは無線デバイスのメモリ88のような)にバッファリングするステップと、そして、送りの無線通信デバイス14,16,18にアクティブチャンネルがオープンされた後に、バッファリングされた初期の通信データをデータストアからターゲットグループ12へ送信するステップを備える。
もし無線通信デバイスでデータストアを持つように具体化されれば、バッファリングのステップは無線通信デバイス14.16、18で生じる。そうではなく、データストアが通信サーバー32にある場合は、ターゲットの無線デバイス14、16、18にアクティブチャンネルがオープンされる間、バッファリングのステップは通信サーバー32で生じる。バッファリングされた、初期のグループ通信データをグループ通信データとして送信するステップは、予め設定された所定の期間が経過した後に発生することができ、あるいは、アクティブな専用のトラフィックチャンネルがオープンされた後に発生することができる。この方法は、さらに、中断されたトークスパートのようなグループ通信の割込みによって、バッファリングされた初期の通信データをデータストアからパージするステップを含むことができる。
システム10は、さらに、創造性のある無線通信デバイス(図3に示される無線電話14のような)を含む。無線通信デバイスは、単一のグループ通信ストリームをセット12のような複数の無線通信デバイスの指定のグループに導くことができ、また、任意の直接通信ストリーム用に無線通信デバイスから出て行く通信のために、無線通信ネットワークに専用のブロードキャストチャンネルを選択的にオープンする。無線通信デバイス14、16、18は、メモリ88あるいは局所データベース90のようなデータストア中の最初の集団通信データをバッファーする創造性のある方法を実現する。
他の実施例は、コンピュータ可読媒体に常駐するプログラムを含む。ここでプログラムは、本発明による方法の創造性あるステップを実行するためのコンピュータ・プラットフォームを有する無線デバイスを指揮する。コンピュータ可読媒体は、無線電話14あるいは他の無線デバイスのコンピュータ・プラットフォーム82のメモリ88であってよく、あるいは、無線電話14のローカルデータベース90のようなローカルデータベース中にあってもよい。さらに、コンピュータ可読媒体は、磁気ディスク、磁気テープ、光ディスク、ハードディスク、フラッシュメモリあるいはこの技術分野で知られているその他の記憶媒体のような、無線デバイスコンピュータプラットフォーム上にロード可能な補助記憶装置の中にあってもよい。
図7および図8のコンテキスト中で、方法は、例えば、無線プラットフォーム82および通信サーバー32のような、機械可読命令のシーケンスを実行するための無線ネットワーク20の一部を操作することにより実現されてもよい。その命令は、様々なタイプの信号保存あるいはデータ保存の主要、第2あるいは第3のメディアに存在することができる。記憶媒体は、例えば、無線ネットワーク20のコンポーネントによってアクセス可能な、あるいはその中に常駐するRAM(図示せず)を備えてもよい。RAM、ディスケットあるいはその他の補助記憶メディアに含まれるだけでなく、命令は、DASD記憶装置(例えば従来の「ハードドライブ」あるいはRAID配列)、磁気テープ、電子的読み取り専用メモリ(例えばROM、EPROMあるいはEEPROM)、フラッシュメモリカード、光学的記憶装置(例えばCD-ROM、WORM、DVD(ディジタル光学テープ)、紙「パンチ」カードのような様々の機械可読データ保存メディア、あるいは、ディジタルおよびアナログ伝送メディアを含む他の適切なデータ保存メディアに格納されてもよい。
先の開示は本発明の例示的な実施例を示しているが、請求項によって定義されたような本発明の範囲から外れることなく、様々な変更および修正が可能であることに注目されるべきである。更に、本発明の要素は単数で記述されあるいは請求されているが、単数への制限が明示的に述べられていない限り、複数を含むと意図されている。