無線通信システムにおけるグループ通信セッションのためのメディア転送
各実施形態は、無線通信システム内のグループ通信セッションのためのメディア転送に関する。サーバが、グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する。サーバは、受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する。サーバは、選択された少なくとも1つのフレームを、グループ通信セッションに参加している第2の複数のアクセス端末に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
35U.S.C.§119に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により全体が明示的に本明細書に組み込まれる、2009年7月10日に出願した「Media Forwarding For a Group Communication Session In A Wireless Communications System」という名称の米国特許仮出願第61/224,797号の優先権を主張する。
【０００２】
本発明の各実施形態は、無線通信セッションにおけるグループ通信セッションのためのメディア転送に関する。
【背景技術】
【０００３】
第1世代アナログ無線電話サービス(1G)、第2世代(2G)デジタル無線電話サービス(暫定2.5Gネットワークおよび2.75Gネットワークを含む)、および第3世代(3G)高速データ/インターネット対応無線サービスを含め、様々な世代を通じて無線通信システムが開発されている。現在、セルラ通信サービスシステムおよびパーソナル通信サービス(PCS)システムを含む、多数の異なる種類の無線通信システムが使用されている。公知のセルラシステムの例には、セルラAnalog Advanced Mobile Phone System (AMPS)、ならびに符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、時間分割多元接続(TDMA)、TDMAのGlobal System for Mobile access(GSM（登録商標）)変形例、およびTDMA技術とCDMA技術の両方を使用する最新のハイブリッドデジタル通信システムに基づくデジタルセルラシステムが含まれる。
【０００４】
CDMA移動通信を実現する方法は、「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」と題し、本明細書ではIS-95として引用されるTIA/EIA/IS-95-Aにおいて電気通信工業協会/電子工業協会によって米国で標準化された。TIA/EIA規格IS-98には複合AMPS&CDMAシステムが記載されている。他の通信システムは、広帯域CDMA(WCDMA)、CDMA2000(たとえば、CDMA2000 1xEV-DO規格など)、またはTD-SCDMAと呼ばれるシステムを対象とする規格であるIMT-2000/UM、すなわちInternational Mobile Telecommunications System 2000/Universal Mobile Telecommunications Systemに記載されている。
【０００５】
無線通信システムでは、移動局、ハンドセット、またはアクセス端末(AT)が、基地局自体に隣接するかあるいは基地局自体の周囲に位置する特定の地理的領域内の通信リンクまたはサービスをサポートする固定位置の基地局(セルサイトまたはセルとも呼ばれる)から信号を受信する。基地局は、一般に、サービス品質(QoS)要件に基づいてトラフィックを区別する方法をサポートする標準的なInternet Engineering Task Force(IETF)方式のプロトコルを使用するパケットデータネットワークである、アクセスネットワーク(AN)/無線アクセスネットワーク(RAN)へのエントリポイントを実現する。したがって、基地局は一般に、無線インターフェースを通じて、かつインターネットプロトコル(IP)ネットワークデータパケットを介してANによってATと相互作用する。
【０００６】
無線通信システムでは、サービスセクタおよび消費者にプッシュトゥトーク(PTT)機能が普及しつつある。PTTは、CDMA、FDMA、TDMA、GSMなど標準的な市販の無線インフラストラクチャを介して動作する「ディスパッチ」音声サービスをサポートすることができる。ディスパッチモデルでは、エンドポイント(AT)同士の通信が仮想グループ内で行われ、1人の「話し手」の声が1人または複数の「聞き手」に送信される。この種の通信の単一のインスタンスは一般に、ディスパッチ呼または単にPTT呼と呼ばれる。PTT呼とは、グループのインスタンス化であり、呼の特性を定義する。グループは基本的に、メンバリストおよびグループ名またはグループIDなど関連情報によって定義される。
【０００７】
従来、無線通信ネットワーク内のデータパケットは、単一の宛先またはアクセス端末に送信されるように構成されている。単一の宛先へのデータの送信は「ユニキャスト」と呼ばれる。移動通信が増大するにつれて、所与のデータを複数のアクセス端末に同時に送信する能力がより重要になっている。したがって、複数の宛先またはターゲットアクセス端末への同じパケットまたはメッセージの同時データ送信をサポートするプロトコルが採用されている。「ブロードキャスト」は、(たとえば、所与のサービスプロバイダがサービスの対象とする所与のセル内での)すべての宛先またはアクセス端末へのデータパケットの送信を指し、「マルチキャスト」は、宛先またはアクセス端末の所与のグループへのデータパケットの送信を指す。一例として、宛先の所与のグループすなわち「マルチキャストグループ」は、(たとえば、所与のサービスプロバイダがサービスの対象とする所与のグループ内の)考えられる宛先またはアクセス端末のうちの複数でありかつ全数よりも少ない数の宛先またはアクセス端末を含んでよい。しかし、少なくとも、状況によっては、マルチキャストグループが、ユニキャストと同様に1つのアクセス端末のみを含むか、あるいはマルチキャストグループが、ブロードキャストと同様に(たとえば、セルまたはセクタ内の)すべてのアクセス端末を含むこともあり得る。
【０００８】
ブロードキャストおよび/またはマルチキャストは、無線通信システムにおいて、複数の順次ユニキャスト動作を実行してマルチキャストグループに対処したり、複数のデータ送信を同時に処理できるように固有のブロードキャスト/マルチキャストチャネル(BCH)を割り振ることのように、いくつかの方法で実施することができる。プッシュトゥトーク通信にブロードキャストチャネルを使用する従来のシステムが、2007年3月1日付けの、「Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network」という名称の米国特許出願公開第2007/0049314号に記載されており、その内容が全体として参照により本明細書に組み込まれる。米国特許出願公開第2007/0049314号に記載されているように、従来のシグナリング技術を使用するプッシュトゥトーク呼にブロードキャストチャネルを使用することができる。ブロードキャストチャネルを使用すると従来のユニキャスト技術と比べて帯域幅要件を改善することができるが、ブロードキャストチャネルの従来のシグナリングでは依然として追加的なオーバヘッドおよび/または遅延が発生することがあり、システム性能が低下する可能性がある。
【０００９】
3rd Generation Partnership Project 2(3GPP2)は、CDMA2000ネットワークにおけるマルチキャスト通信をサポートするブロードキャスト-マルチキャストサービス(BCMCS)仕様を定めている。したがって、「CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification」と題する、2006年2月14日付けの3GPP2のBCMCS仕様Version 1.0 C.S0054-Aを全体として参照により本明細書に組み込む。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許出願公開第2007/0049314号
【非特許文献】
【００１１】
【非特許文献１】Telecommunications Industry Association/Electronic Industries Association「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」
【非特許文献２】3rd Generation Partnership Project 2「CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification」
【発明の概要】
【課題を解決するための手段】
【００１２】
各実施形態は、無線通信システム内のグループ通信セッションのためのメディア転送に関する。サーバが、グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する。サーバは、受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する。サーバは、選択された少なくとも1つのフレームを、グループ通信セッションに参加している第2の複数のアクセス端末に送信する。
【００１３】
一例として、サーバは、宛先向けに選択されたフレームの数が1よりも大きい場合、任意にフレーム同士を混合する。フレーム同士の選択および/または混合は、複数のアクセス端末の各々について行われるが、場合によっては、選択または混合された同じフレームを複数のアクセス端末に送信することができ、それによって、サーバに対する処理負荷を低減させることができる。他の例では、1つまたは複数のフレームをそれに関連するデータレートに少なくとも部分的に基づいて選択することができ、次に、選択されたフレームを(たとえば、信号処理的に)混合することができる。各実施形態は、比較的小さなグループに関連する実施形態であっても、比較的少数の参加者が同時に話すことがある大きなグループに関する実施形態であってもよい。したがって、あるタイムスロットに関する、潜在的に多数の利用可能なフレームから比較的少数のフレームを選択することができ、次に、選択されたフレームを混合してグループに配信することができる。
【００１４】
本発明の実施形態およびそれに付随する利点の多くが、以下の詳細な説明を参照し、本発明の限定ではなく単に例示として提示された添付の図面と一緒に検討したときによりよく理解されるようになるため、本発明の実施形態およびそれに付随する利点の多くをより完全に理解することは容易である。
【図面の簡単な説明】
【００１５】
【図１】本発明の少なくとも1つの実施形態によるアクセス端末およびアクセスネットワークをサポートする無線ネットワークアーキテクチャの図である。
【図２】本発明の例示的な実施形態によるキャリアネットワークを示す図である。
【図３】本発明の少なくとも1つの実施形態によるアクセス端末の図である。
【図４Ａ】従来の半二重グループ通信セッションプロセスを示す図である。
【図４Ｂ】従来の全二重グループ通信セッションプロセスを示す図である。
【図５Ａ】本発明の一実施形態によるグループ通信セッションプロセスを示す図である。
【図５Ｂ】本発明の一実施形態による、各グループ通信セッション参加者が同じ優先順位レベルを有するフレーム選択の例を示す図である。
【図５Ｃ】本発明の一実施形態による、2人以上のグループ通信セッション参加者がそれぞれの異なる優先順位レベルを有するフレーム選択の例を示す図である。
【図５Ｄ】本発明の一実施形態による、複数のフレームが選択される図5Bのプロセスの変形例を示す図である。
【図５Ｅ】本発明の一実施形態による、複数のフレームが選択される図5Cのプロセスの変形例を示す図である。
【図６Ａ】本発明の一実施形態による、図5Bまたは図5Cの選択プロセスに従って実行された図5Aのグループ通信セッションプロセスを示す図である。
【図６Ｂ】本発明の一実施形態による、図5Dまたは図5Eの選択プロセスに従って実行された図5Aのグループ通信セッションプロセスを示す図である。
【図７】本発明の一実施形態による図6Aのプロセスに続くプロセスを示す図である。
【図８】本発明による複数のタイムスロットにわたる図6Aのプロセスを示す図である。
【図９】本発明の一実施形態による、入力メディアフローの選択されたフレームに関連する1つまたは複数のメディアフローパラメータを出力メディアフローにおいて修正することのできる高レベルプロセスを示す図である。
【図１０】図9のプロセスが送信元同期(SSRC)メディアフローパラメータに対して実行されない復号プロセスの一例を示す図である。
【図１１】図9のプロセスがSSRCメディアフローパラメータに対して実行される復号プロセスの一例を示す図である。
【図１２】図9のプロセスがシークエント番号メディアフローパラメータに対して実行されない復号プロセスの一例を示す図である。
【図１３】図9のプロセスがシーケンス番号メディアフローパラメータに対して実行される復号プロセスの一例を示す図である。
【発明を実施するための形態】
【００１６】
本発明の特定の実施形態に関する以下の説明および関連する図面に本発明の各態様が開示されている。本発明の範囲から逸脱せずに他の実施形態が考案されてよい。また、本発明の公知の要素については、本発明の関連する細部を曖昧にしないように詳しく説明しないかあるいは省略する。
【００１７】
「例示的な」および/または「例」という用語は、本明細書では、「一例または例示として働くこと」を意味するのに使用される。本明細書で「例示的な」および/または「例」として記載される実施形態が必ずしも他の実施形態と比べて好ましいかあるいは有利であるとみなされるわけではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、本明細書で述べられる特徴、利点、または動作モードを含むことを必要とするわけではない。
【００１８】
また、多くの実施形態は、たとえばコンピューティングデバイスの要素によって実行すべき動作のシーケンスに関して記載されている。本明細書に記載された様々な動作を特定の回路(たとえば、特定用途向け集積回路(ASIC))、1つまたは複数のプロセッサによって実行されるプログラム命令、またはその両方の組み合わせによって実行できることが理解されよう。また、本明細書に記載されたこれらの動作シーケンスは、実行されたときに関連するプロセッサに本明細書に記載された機能を実行させる対応する1組のコンピュータ命令が記憶された任意の形態のコンピュータ可読記憶媒体内で完全に具体化されるとみなすことができる。したがって、本発明の様々な態様は、すべてが請求される主題の範囲内と考えられているいくつかの異なる形態で具体化することができる。また、本明細書に記載された各実施形態について、あらゆるそのような実施形態の対応する形態が、本明細書において、たとえば、記載された動作を実行するように「構成された論理」として記載されることもある。
【００１９】
ハイデータレート(HDR)加入者局は、本明細書ではアクセス端末(AT)と呼ばれ、移動局であっても固定局であってもよく、本明細書ではモデムプールトランシーバ(MPT)または基地局(BS)と呼ばれる1つまたは複数のHDR基地局と通信することができる。アクセス端末は、1つまたは複数のモデムプールトランシーバを通じて、モデムプールコントローラ(MPC)、基地局コントローラ(BSC)、および/またはパケット制御機能(PCF)と呼ばれるHDR基地局コントローラとの間でデータパケットを送受信する。モデムプールトランシーバおよびモデムプールコントローラは、アクセスネットワークと呼ばれるネットワークの一部である。アクセスネットワークは、複数のアクセス端末でデータパケットを転送する。
【００２０】
アクセスネットワークはさらに、企業イントラネットまたはインターネットなどアクセスネットワークの外部の他のネットワークに接続されてよく、各アクセス端末とそのような外部ネットワークとの間でデータパケットを転送することができる。1つまたは複数のモデムプールトランシーバとのアクティブトラフィックチャネル接続を確立したアクセス端末は、アクティブアクセス端末と呼ばれ、かつトラフィック状態にあると言われる。1つまたは複数のモデムプールトランシーバとアクティブトラフィックチャネル接続を確立する過程であるアクセス端末は、接続セットアップ状態であると言われる。アクセス端末は、無線チャネルを通じて通信するか、あるいはたとえば光ファイバケーブルまたは同軸ケーブルを使用して有線チャネルを通じて通信する任意のデータデバイスであってよい。アクセス端末はさらに、PCカード、コンパクトフラッシュ（登録商標）、外部モデムまたは内部モデム、あるいは無線電話または有線電話を含むがそれらに限らないいくつかの種類のデバイスのうちのいずれかのデバイスであってよい。アクセス端末がモデムプールトランシーバに信号を送信するための通信リンクは、下りリンクまたはトラフィックチャネルと呼ばれる。モデムプールトランシーバがアクセス端末に信号を送信するための通信リンクは、上りリンクまたはトラフィックチャネルと呼ばれる。本明細書では、トラフィックチャネルという用語は、上りトラフィックチャネルまたは下りトラフィックチャネルのいずれかを指すことがある。
【００２１】
図1は、本発明の少なくとも1つの実施形態による無線システム100の例示的な一実施形態のブロック図である。システム100は、パケット交換データネットワーク(たとえば、イントラネット、インターネット、および/またはキャリアネットワーク126)とアクセス端末102、108、110、112との間のデータ接続性を実現するネットワーク機器にアクセス端末102を接続することのできるアクセスネットワークまたは無線アクセスネットワーク(RAN)120と無線インターフェース104を介して通信する携帯電話102などのアクセス端末を含んでよい。図示のように、アクセス端末は、携帯電話102、パーソナルデジタルアシスタント108、図1には2方向テキストページャとして示されているページャ110、場合によっては無線通信ポータルを有する別個のコンピュータプラットフォーム112であってよい。したがって、本発明の各実施形態は、無線モデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組み合わせもしくは部分組み合わせを制限なしに含む、無線通信ポータルを含むかあるいは無線通信機能を有する任意の形態のアクセス端末で実現することができる。また、本明細書では、「アクセス端末」、「無線デバイス」、「クライアントデバイス」、「移動端末」という用語、およびそれらの変形例は交換可能に使用されてよい。
【００２２】
再び図1を参照すると、無線ネットワーク100の構成要素および本発明の例示的な実施形態の要素の相互関係は、図示の構成に限定されない。システム100は、例示的なシステムに過ぎず、無線クライアントコンピューティングデバイス102、108、110、112などのリモートアクセス端末が、無線による互いの通信と、無線インターフェース104ならびにキャリアネットワーク126、インターネット、および/またはその他のリモートサーバを含むがそれらに限らないRAN120を介して接続された構成要素との間の通信を行うのを可能にする任意のシステムを含んでよい。
【００２３】
RAN120は、基地局コントローラ/パケット制御機能(BSC/PCF)122に送信されるメッセージ(通常データパケットとして送信される)を制御する。BSC/PCF122は、パケットデータサービスノード160(PDSN)とアクセス端末102/108/110/112との間のベアラチャネル(すなわち、データチャネル)のシグナリング、確立、および切り離しに責任を負う。リンク層暗号化が有効化される場合、BSC/PCF122はまた、コンテントを無線インターフェース104を介して転送する前に暗号化する。BSC/PCF122の機能は当技術分野で公知であり、説明を簡潔にするためにこの機能についてはこれ以上は論じない。キャリアネットワーク126は、ネットワーク、インターネット、および/または公衆交換電話網(PSTN)によってBSC/PCF122と通信することができる。あるいは、BSC/PCF122を直接インターネットまたは外部ネットワークに接続することができる。通常、キャリアネットワーク126とBSC/PCF122との間のネットワーク接続またはインターネット接続はデータを転送し、PSTNは音声情報を転送する。BSC/PCF122は、複数の基地局(BS)またはモデムプールトランシーバ(MPT)124に接続することができる。キャリアネットワークと同様に、BSC/PCF122は通常、データ転送および/または音声情報のためにネットワーク、インターネット、および/またはPSTNによってMPT/BS124に接続される。MPT/BS124は、携帯電話102などのアクセス端末に無線によってデータメッセージをブロードキャストすることができる。MPT/BS124、BSC/PCF122、およびその他の構成要素は、当技術分野で公知のようにRAN120を形成することができる。しかし、他の構成も使用されてよく、本発明は図示の構成に限定されない。たとえば、他の実施形態では、BSC/PCF122および1つまたは複数のMPT/BS124の機能が、BSC/PCF122とMPT/BS124の両方の機能を有する単一の「ハイブリッド」モジュールに組み込まれてよい。
【００２４】
図2は、本発明の一実施形態によるキャリアネットワーク126を示している。図2の実施形態では、キャリアネットワーク126は、パケットデータサービングノード(PDSN)160と、ブロードキャストサービングノード(BSN)165と、アプリケーションサーバ170と、インターネット175とを含む。しかし、他の実施形態では、アプリケーションサーバ170およびその他の構成要素はキャリアネットワークの外部に配置されてよい。アプリケーションサーバ170は、機能について以下に詳しく説明するmedia content complex(MCC)モジュール172を含む。PDSN160は、たとえば、cdma2000無線アクセスネットワーク(RAN)(たとえば、図1のRAN120)を利用する移動局(たとえば、図1の102、108、110、112などのアクセス端末)に対して、インターネット175、イントラネット、および/またはリモートサーバ(たとえば、アプリケーションサーバ170)にアクセスするのを可能にする。PDSN160は、アクセスゲートウェイとして働き、単純なIPアクセスおよび移動IPアクセス、フォーリンエージェントのサポート、およびパケット転送を実行することができる。PDSN160は、当技術分野で公知のように、Authentication, Authorization, and Accounting(AAA)サーバおよびその他のサポートインフラストラクチャ用のクライアントとして働くことができ、移動局に対してIPネットワークへのゲートウェイを実現する。図2に示されているように、PDSN160は、従来のA10接続を介してRAN120(たとえば、BSC/PCF122)と通信することができる。A10接続は当技術分野で公知であり、説明を簡潔にするためにA10接続についてはこれ以上説明しない。
【００２５】
図2を参照すると、ブロードキャストサービングノード(BSN)165は、マルチキャストサービスおよびブロードキャストサービスをサポートするように構成されてよい。BSN165については以下に詳しく説明する。BSN165は、ブロードキャスト(BC)A10接続を介してRAN120(たとえば、BSC/PCF122)と通信し、インターネット175を介してアプリケーションサーバ170と通信する。BCA10接続は、マルチキャストメッセージおよび/またはブロードキャストメッセージを転送するのに使用される。したがって、アプリケーションサーバ170は、インターネット175を介してPDSN160にユニキャストメッセージを送信し、インターネット175を介してBSN165にマルチキャストメッセージを送信する。
【００２６】
一般に、以下に詳しく説明するように、RAN120は、BCA10接続を介してBSN165から受信されたマルチキャストメッセージを無線インターフェース104のブロードキャストチャネル(BCH)上で1つまたは複数のアクセス端末200に送信する。
【００２７】
図3を参照すると、携帯電話などのアクセス端末200(ここでは無線デバイス)は、RAN120から送信され、最終的にキャリアネットワーク126、インターネット、ならびに/あるいはその他のリモートサーバおよびリモートネットワークから得られるソフトウェアアプリケーション、データ、および/またはコマンドを受信して実行することができるプラットフォーム202を有する。プラットフォーム202は、特定用途向け集積回路(「ASIC」)208、またはその他のプロセッサ、マイクロプロセッサ、論理回路、もしくはその他のデータ処理デバイスに動作可能に結合されたトランシーバ206を含んでよい。ASIC208またはその他のプロセッサは、無線デバイスのメモリ212内の任意の常駐プログラムと相互作用するアプリケーションプログラミングインターフェース(「API」)210層を実行する。メモリ212は、読み取り専用メモリまたはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、あるいは各コンピュータプラットフォームに共通する任意のメモリで構成されてよい。プラットフォーム202は、メモリ212内で能動的には使用されないアプリケーションを保持することのできるローカルデータベース214も含んでよい。ローカルデータベース214は通常、フラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトディスクまたはハードディスクなど当技術分野で公知の任意の二次的記憶デバイスであってよい。内部プラットフォーム202の各構成要素は、当技術分野で公知のように、特に、アンテナ222、ディスプレイ224、プッシュトゥトークボタン228、キーパッド226などの外部デバイスに動作可能に結合されてよい。
【００２８】
したがって、本発明の一実施形態は、本明細書で説明する機能を実行する機能を含むアクセス端末を含んでよい。当業者によって理解されるように、様々な論理要素は、本明細書に開示される機能を実現するように離散要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアの任意の組み合わせで具体化することができる。たとえば、ASIC208、メモリ212、API210、およびローカルデータベース214はすべて、本明細書に開示された様々な機能をロードし、記憶し、実行するように協働させてよく、したがって、これらの機能を実行する論理は様々な要素間で分散されてよい。あるいは、機能を1つの離散構成要素に組み込んでもよい。したがって、図3のアクセス端末の特徴は単に例示的なものとみなすべきであり、本発明は例示された特徴または構成に限定されない。
【００２９】
アクセス端末102とRAN120との無線通信は、符号分割多元接続(CDMA)、WCDMA、時間分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多重化(OFDM)、Global System for Mobile Communications (GSM)、または無線通信ネットワークもしくはデータ通信ネットワークで使用されてよいその他のプロトコルなど様々な技術に基づいて行うことができる。データベース通信は通常、クライアントデバイス102とMPT/BS124とBSC/PCF122との間で行われる。BSC/PCF122は、キャリアネットワーク126、PSTN、インターネット、仮想プライベートネットワークなど複数のデータネットワークに接続することができ、したがって、アクセス端末102がより広い通信ネットワークにアクセスするのを可能になる。上記で論じられかつ当技術分野で公知のように、様々なネットワークおよび構成を使用して音声送信および/またはデータをRANからアクセス端末に送信することができる。したがって、本明細書における例示は、本発明の各実施形態を限定するものではなく、本発明の各実施形態の態様の説明を助けるものであるに過ぎない。
【００３０】
図4Aは、従来の半二重グループ通信セッション(たとえば、呼、転送セッションなど)プロセスを示している。図4Aのグループ通信セッションは、IPマルチキャスティングプロトコルまたはIPユニキャスティングプロトコルによってサポートされるグループ通信セッションに相当するセッションであってよい。IPマルチキャスティングでは、ダウンリンクブロードキャストチャネル(BCH)が、1つまたは複数のセクタ内で単一のマルチキャストフローを各「聞き手側」マルチキャストグループメンバに伝送し、一方、マルチキャストグループメンバがダウンリンクBCHに同調するにはどうすればよいかを示す別個のスケジューリングメッセージ(たとえば、ブロードキャストオーバヘッドメッセージ(BOM))がダウンリンク制御チャネル上で送信される。IPユニキャスティングでは、各グループメッセージが、各グループメンバに個別にアドレス指定された別個のユニキャストメッセージとして各グループ通信セッション参加者またはマルチキャストグループメンバに送信される。
【００３１】
図4Aを参照すると、400で、所与のAT(ATA)が、グループ通信セッションを開始する要求をRAN120を介してアプリケーションサーバ170に送信する。たとえば、このグループ通信セッションは、プッシュトゥトーク(PTT)セッションまたはプッシュトゥトランスファー(PTX)セッションに相当するセッションであってよく、400における要求の送信は、ATAのユーザがATA上でPTTボタンまたはPTXボタンを押すことに基づいて指示されてよい。アプリケーションサーバ170は、ATAからグループ通信セッション要求を受信し、無線通信システム100の1つまたは複数のセクタでアナウンスメッセージを送信する(405)。少なくともATB...ATEがアナウンスメッセージを受信し、告知されたグループ通信セッションに参加することを決定する。したがって、ATB...ATEは、アプリケーションサーバ170に呼受け入れメッセージを送信し、またRAN120に登録メッセージ(たとえば、BCMCSFlowRegistrationメッセージ)を送信してグループ通信セッションに登録する(410および415)。ATB...ATEの各々からの呼受け入れメッセージおよび登録メッセージは、下りリンクアクセスチャネル上の別個のメッセージ内で送信されるか、あるいは同じメッセージ内にバンドルされてよい。
【００３２】
アプリケーションサーバ170は、ATB...ATEからのアナウンスメッセージに対する第1の応答者からの呼受け入れメッセージを受信した後、グループ通信セッションに関するフロアをATAに許可する(420)。したがって、ATAは、フロア許可メッセージを受信した後、ATAのユーザに話し始めてよいことを示す音を鳴らし、ATAは、下りリンクチャネル上でアプリケーションサーバ170へのフレームの送信を開始する(425)。425における一連のフレーム送信は、音声データを実際に含むデータフレームに相当するフレーム送信であってよく、あるいは音声データを実際に含まない無音フレームに相当するフレーム送信であってよい。
【００３３】
各フレーム送信は、リアルタイム転送プログラム(RTP)パケットまたはデータグラムあるいはRTCP(RTP制御プロトコル)パケットに相当するフレーム送信であってよい。40オクタットオーバヘッドRTPパケットのヘッダ部は以下のように構成されてよい。
【００３４】
【表１】
【００３５】
Table 1(表1)を参照すると、RTPパケットヘッダ部の各フィールドは当技術分野で公知である。しかし、あるフィールドについては、以下に詳しく説明する実施形態に関して詳しく論じることとし、したがって、本節ではこれらのフィールドを簡単に参照する。次に、たとえば、寄与カウント(CC)フィールド、シーケンス番号フィールド、タイムスタンプフィールド、およびSSRC番号フィールドについて簡単に述べる。CCフィールドは、寄与送信元(CSRC)カウント値を保持することのできる任意のフィールドである。Table 1(表1)(上記)の見出し部分には示されていないが、CCフィールドの12オクテットヘッダは、より多くの寄与送信元を含むように任意に拡張することができる。寄与送信元は、アプリケーションサーバ170におけるミキサによって付加することができ、データペイロードの各要素が異なるコンピュータから得られる会議アプリケーションに適している。ポイントツーポイント通信では、CSRCは必ずしも必要とされない。シーケンス番号フィールドは、特定の送信元またはATからRTPパケットが送信されるたびに1だけ増分する固有の参照番号を保持する。シーケンス番号フィールドは、受信側が送信側のパケットシーケンスを再構成するのを可能にする。タイムスタンプフィールドは、RTPパケットがATによって送信された時間に対応する。タイムスタンプフィールドは、受信側ATがデータをバッファリングし連続ストリームとして再生するのを可能にする。SSRC番号フィールドは、RTPパケットの送信元を識別し、425でATAを識別する数に対応する。SSRC番号は、グループ通信セッションの開始時にアプリケーションサーバ170によってプロビジョニングすることができる。
【００３６】
RTPパケットは、RTPヘッダ部の後に、データペイロード部を含む。データペイロード部は、音声および/またはビデオのデジタル化サンプルを含んでよい。データペイロードの長さは、RTPパケットに応じて異なってよい。たとえば、音声RTPパケットでは、データペイロードによって保持される音声サンプルの長さは20ミリ秒(ms)の音声に相当する長さであってよい。一般に、メディア持続時間がこれよりも長い場合(たとえば、よりレートの高いフレームの場合)、データペイロードも長くする必要があり、あるいはメディアサンプルの品質が低下する。
【００３７】
図4Aの425に戻ると、ATAから送信されるフレームは、RTPパケット内に大きなデータペイロードを有するフルレートフレーム(たとえば、8.6kbps)、RTPパケット内に「中」データペイロードを含むハーフレートフレーム(たとえば、4.3kbps)、RTPパケット内に小さなデータペイロードを含む1/8レートフレーム(たとえば、1.0kbps)などに相当するフレームであってよい。概してEVRC-Aが参照されるが、異なるフレームレート選択肢を含む他のボコーダに対処するにはこれらの実施形態をどのように修正すればよいかが容易に明らかになろう。理解されるように、ATAは、ATAのユーザの発話時には、ATAのユーザが発話しておらず、ATAが無音フレームを送信しているときよりも高いレートのフレームを送信する。アプリケーションサーバ170は、フロアホルダからのメディアストリームの受信、およびグループ通信セッションの1人または複数の「聞き手側」グループメンバへの出力ストリームの変換に対処するmedia control complex(MCC)172モジュールを含む。言い換えれば、MCCモジュール172は、RTPパケット内のフレームを複製してATAからATB...ATEの各々に再ブロードキャストする。したがって、アプリケーションサーバ170のMCCモジュール172で受信されたATAからの一連のフレーム送信は以下のように表されてよい。
【００３８】
【表２】
【００３９】
時間間隔10t...Tはそれぞれ、ATAからの所与のデータレートを有する1つのフレーム(たとえば、RTPパケット)を含む。■1/2フレームが(たとえば、音声データを含む)データフレームに相当し、一方、□1/8が無音フレームに相当すると仮定されてよい。しかし、少なくとも、■1/2フレームが、無音フレームと同様に、限られた量の雑音を含むことがあり得ることを理解されたい。また、図4Aは半二重グループ通信セッションであるため、ATAが(たとえば、1つまたは複数のRTPパケットで)フレームを送信しており、一方、ATB...ATEがパケットを送信していないことをTable 2(表2)(上記)が示していることに留意されたい。Table 2(表2)に示されているフレーム(たとえば、RTPパケット)は、アプリケーションサーバ170で受信されるパケットまたはフレームの入力ストリームに相当する。
【００４０】
上記に指摘したように、MCCモジュール172は、上記でTable 2(表2)に示されているように入力ストリームを受信し、ATA...ATEに送信される出力ストリームを生成または変換する。したがって、Table 2(表2)に基づいて、アプリケーションサーバ170のMCCモジュール172によって生成される出力ストリームは以下のように構成されてよい。
【００４１】
【表３】
【００４２】
Table 3(表3)(上記)に示されているように、出力ストリームは、ATAのフレーム送信がATAに送り返されるのではなく、上記のTable 2(表2)においてATB...ATEに送信されるように構成される。
【００４３】
出力ストリームはMCCモジュール172によって生成されるため、アプリケーションサーバ170は、出力ストリームの出力フレームを含むRTPパケットを一連のグループメッセージとしてATB...ATEに送信し(430)、ATB...ATEはグループ通信セッションに関するグループメッセージを監視する(435および440)。グループ通信セッションは次いで、ATAのユーザがフロアを放棄することに決定するまである期間にわたって継続する。445は、フロアを放棄することを求めるATAからの明示的な命令に対応するか、あるいはATAからのイナクティビティ期間(すなわち、無音フレームが多過ぎること)に基づくものであってよい。
【００４４】
アプリケーションサーバ170は、ATAがグループ通信セッションのフロアを放棄したと判定した後、ATB...ATEにフロア解放メッセージを送信する(450)。ATBのユーザおよびATC...ATEのうちの少なくとも1つのユーザが、フロアの制御権の獲得を試みることに決定し、アプリケーションサーバ170にフロア要求メッセージを送信する(455および460)と仮定する。それによって、アプリケーションサーバ170は複数のフロア要求メッセージを受信し、フロアを要求しているATの優先順位レベルを評価して、次にフロアを許可されるATを判定する。たとえば、RAN120は、グループ通信セッションの種類に基づいて、RAN120に維持されている1つまたは複数の優先順位テーブルを評価することができ、かつフロアを要求しているATの中から最高優先順位のATにフロアに許可することができる。たとえば、優先順位テーブルは以下のように構成されてよい。
【００４５】
【表４】
【００４６】
465で、アプリケーションサーバ170は、このグループ通信セッションのコールタイプに関しては、要求しているATの中でATBが最高優先順位レベルを有していると判定し、ATBにフロア許可メッセージを送信すると仮定する。次に、ATBが、音を鳴らして、現在ATBがフロアを有していることをATBのユーザに通知し、アプリケーションサーバ170への1つまたは複数のRTPパケットでのフレーム(たとえば、データフレーム、無音フレームなど)の送信を開始し(470)、次に、フレームが、MCCモジュール172によって出力ストリームに変換され、ATAおよびATC...ATEに再送される(475)。470および475が、上記にATAに関して説明したように425および430と同様に実行されることが理解されよう。したがって、説明を簡潔にするために470および475についてはこれ以上説明しない。
【００４７】
半二重セッションの特徴として、(たとえば、RTPパケットでの)フレームを送信するのは図4Aのグループ通信セッションにおける特定のATだけであり、一方、(たとえば、RTPパケットで)フレームを受信するのはグループ通信セッションにおける他のATだけである。図4Aのプロセスに代わるプロセスとして、以下に図4Bに関して説明する全二重グループ通信セッションがある。全二重セッションでは、セッションの各参加者が(たとえば、RTPパケットでの)フレームの送信と受信の両方を行うことができる。
【００４８】
図4Bは、従来の全二重グループ通信セッション(たとえば、呼、データ転送セッションなど)プロセスを示している。図4Aと同様に、図4Bのグループ通信セッションは、IPマルチキャスティングプロトコルまたはIPユニキャスティングプロトコルによってサポートされるグループ通信セッションに相当するセッションであってよい。図4Bを参照すると、400B〜415Bは、図4Aの400〜415に対応している。したがって、説明を簡潔にするために400B〜415Bについてはこれ以上論じない。
【００４９】
420Bで、アプリケーションサーバ170は、セッションイニシエータ(すなわち、ATA)にフロアを許可する代わりに、このグループ通信セッションに参加した各ATに、セッションを開始できることを示すメッセージを送信する(420B)。ATA...ATEはいずれも、メッセージを受信した(420B)ときに、発話を開始し、それによってデータフレームを送信するか、あるいは沈黙を続けて無音フレームを送信することができる(425B、430B、435B)。
【００５０】
アプリケーションサーバ170のMCCモジュール172で受信されるATA...ATEからの入力ストリームの一例(たとえば、特定のタイムスロットについてのATA...ATEからのRTPパケット内に含まれるフレーム)は以下のように表されてよい。
【００５１】
【表５】
【００５２】
Table 5(表5)(上記)を参照すると、ATA...ATEの各々は、タイムスロット10t...T上で所与のデータレートでフレームを送信する。特に、ATAは、一連のハーフレートフレームを送信しており(このことは、たとえば、ATAのユーザがATB...ATEに対して発話しており、音声データを送信している可能性が高いことを示す)、一方、ATB...ATEは、一連の1/8レートフレームを送信している(このことは、たとえば、ATB...ATEのユーザがATAの発話を聞いている可能性が高い、電話から離れている、などを示している)
【００５３】
図4Bを参照すると、440Bで、アプリケーションサーバ170のMCCモジュール172は、各時間間隔tに入力ストリームから得られる各フレームを含み、集結されたメディアストリームのジッタを除去し、次いで、その時間間隔についてのATA...ATEの各々からのすべてのメディアコンテントを含む出力ストリームを生成する。アプリケーションサーバ170は次に、結果として得られたメディアストリームを1つまたは複数のRTPパケット内の集結された一連のフレームとしてATA...ATEの各々に送信する。しかし、フィードバック問題を回避するために、ATA...ATEの各々が、そのAT自体を除くすべてのセッション参加者からのフレームを含む集結されたメディアストリームを受信することを理解されたい。したがって、ATAは、ATB...ATEからの集結されたメディアで構成された出力ストリームを受信し、ATBは、ATAおよびATC...ATEからの集結されたメディアで構成された出力ストリームを受信し、他のATについても同様である。
【００５４】
上記に指摘したように、MCCモジュール172は、上記にTable 5(表5)(上記)に示されているようにATA...ATEからフレームを受信し(すなわち、入力ストリーム)、次にATA...ATEに送信される出力ストリームを生成または変換する(たとえば、各出力ストリームは、フィードバックを低減させるために、ターゲットから受信された入力ストリームのフレームを省略するため、それぞれ異なる)。したがって、Table 5(表5)(上記)に基づいて、タイムスロット10t...T上でアプリケーションサーバ170のMCCモジュール172によって生成される出力ストリームは以下のように構成されてよい。
【００５５】
【表６】
【００５６】
Table 6(表6)(上記)に示されているように、グループ通信セッションが簡略的なブルートフォース転送実装形態であるため、出力ストリームの各タイムスロットにおけるATA...ATEへの集結されたメディアフレームは、そのAT自体以外のATからのフレーム(または、たとえばRTPパケット)のデータレートの和に等しい総データレートを有する。
【００５７】
図4Aのグループ通信セッションに関する従来の半二重実装形態に関しては、帯域幅使用率が図4Aのグループ通信セッションに関する全二重実装形態と比べて優れていることが理解されよう。しかし、ATがグループへの送信を行うことができないことが問題になることもある(たとえば、現在のフロアホルダがフロアを放棄せず、関連のない話題に関して話している場合)。半二重では、現在のフロアホルダは、フロアが解放されるまで他のグループメンバからフィードバックを受信することができないためグループの感情に気付かない。
【００５８】
この問題は、図4Bの全二重実装形態では生じない。しかし、グループ通信セッション参加者がN人である場合、各参加者が、組み合わされたN-1個のメディアフローを有する集結された出力ストリームを受信し、それによって、比較的大量の帯域幅が消費されるため、全二重実装形態の帯域幅要件は高い。また、多数のメディアフレームを集結して出力ストリームのメディアフレームを形成することは、アプリケーションサーバ170における集中的な処理になることがある。また、アプリケーションサーバ170のMCCモジュール172は、メディアフロー同士を区別しない。したがって、各フレームが出力ストリーム内の同じタイムスロットを求めて競合するとき、無音フレームには出力フレーム中のデータフレームと同じ優先順位が与えられる。
【００５９】
したがって、次に、半二重実装形態と全二重実装形態の両方のある特性を含むハイブリッド実装形態に関する実施形態について詳しく説明する。以下に詳しく説明するように、グループ通信セッションの複数の参加者(たとえば、すべての参加者)は、全二重の場合と同様に(たとえば、RTPパケットでの)フレームの送信と受信の両方を行うことができる。しかし、MCCモジュール172は、(選択された参加者以外の)特定のグループ通信セッション参加者への出力ストリーム内の任意の所与の出力フレームが、選択された参加者のみからのメディアコンテントを含むように、各グループ通信セッション参加者への出力として、着信したメディアストリームの1つまたは複数を選択するように構成されている。1つのメディアストリームが選択された場合、出力ストリームは、半二重と同様である(それによって、たとえば、帯域幅使用効率が高くなる)。入力メディアストリームのうちの複数でありかつ全数よりも少ない数のメディアストリームが選択された場合、出力メディアストリームは、フレームが選択された、選択された一部のATについては全二重と同様であり、一方、全二重とは異なり、すべてのフレームが出力ストリームに含まれるわけではないので帯域幅使用率が高くなる(ただし、たとえば、少なくとも一実施形態では、少なくとも、すべてのフレームが選択されることがあり得る)。MCCモジュール172がグループ通信セッション参加者の出力ストリームをどのように生成するかに関する選択機構については以下に詳しく説明する。
【００６０】
以下に、本発明の各実施形態をフルレートフレーム、ハーフレートフレーム、および1/8レートフレームに関して説明する。上記のフレームレートを含む1組のフレームレートがEVRC-Aボコーダに特有のフレームレートである。EVRC-Bおよび/または4Gなど他のボコーダは、フレームレートセットの一部として1/4レートフレームを含んでよい。以下でEVRC-Aを概略的に参照すると、様々なフレームレート選択肢を含む他のボコーダに対処するにはこれらの実施形態をどのように修正すればよいかが容易に明らかになろう。
【００６１】
また、以下に説明する本発明の各実施形態では、特定の節においてRTPパケットとフレーム(たとえば、無音フレーム、データフレームなど)を交換可能に参照する。しかし、RTPパケットが実際には複数のフレームを含んでよいことを理解されたい。それによって、RTPパケットが1つのフレームを含むと仮定したRTPパケットの特定の参照を、本発明の他の実施形態では、本明細書で開示されるプロセスがフレーム固有のプロセスであり、必ずしもRTPパケット固有のプロセスではないように修正できることが理解されよう。言い換えれば、フレーム選択が第1のタイムスロットについて行われ、次いで第2のタイムスロットについて行われる場合、第1および第2のタイムスロットにおける選択に利用できるフレームのうちの1つまたは複数が実際には同じRTPパケットで受信されたフレームであることがあり、この場合、選択はフレーム固有の選択であり、パケット固有の選択ではない。概して、本発明の各実施形態はフレームの混合および選択に関する実施形態であり、RTPパケットは、1つ(または複数)のフレームを保持する例示的な機構に過ぎない。
【００６２】
したがって、図5Aは、本発明の一実施形態によるグループ通信セッション(たとえば、呼、転送セッションなど)プロセスを示している。特に、図5Aは、比較的高いレベルでのグループ通信セッションプロセスを示しており、その後に、図5Aに示されている高レベルプロセスの一部のより詳細な例が示されている。図5Aのグループ通信セッションは、IPマルチキャスティングプロトコルまたはIPユニキャスティングプロトコルによってサポートされるグループ通信セッションに相当するセッションであってよい。IPマルチキャスティングでは、ダウンリンクブロードキャストチャネル(BCH)が、1つまたは複数のセクタ内で単一のマルチキャストフローを各「聞き手側」マルチキャストグループメンバに伝送し、一方、マルチキャストグループメンバがダウンリンクBCHに同調するにはどうすればよいかを示す別個のスケジューリングメッセージ(たとえば、ブロードキャストオーバヘッドメッセージ(BOM))がダウンリンク制御チャネル上で送信される。IPユニキャスティングでは、各グループメッセージが、各グループメンバに個別にアドレス指定された別個のユニキャストメッセージとして各グループ通信セッション参加者またはマルチキャストグループメンバに送信される。
【００６３】
図5Aを参照すると、500で、所与のAT(ATA)が、グループ通信セッションを開始する要求をRAN120を介してアプリケーションサーバ170に送信する。たとえば、このグループ通信セッションは、プッシュトゥトーク(PTT)セッションまたはプッシュトゥトランスファー(PTX)セッションに相当するセッションであってよく、500における要求の送信は、ATAのユーザがATA上でPTTボタンまたはPTXボタンを押すことに基づいて指示されてよい。アプリケーションサーバ170は、ATAからグループ通信セッション要求を受信し、無線通信システム100の1つまたは複数のセクタでアナウンスメッセージを送信する(505)。少なくともATB...ATEがアナウンスメッセージを受信し、告知されたグループ通信セッションに参加することを決定する。したがって、ATB...ATEは、アプリケーションサーバ170に呼受け入れメッセージを送信し、またRAN120に登録メッセージ(たとえば、BCMCSFlowRegistrationメッセージ)を送信してグループ通信セッションに登録する(510および515)。ATB...ATEの各々からの呼受け入れメッセージおよび登録メッセージは、下りリンクアクセスチャネル上の別個のメッセージ内で送信されるか、あるいは同じメッセージ内にバンドルされてよい。
【００６４】
図5Aを参照すると、520で、アプリケーションサーバ170は、ATB...ATEから呼受け入れメッセージを受信した後、ATAおよびATB...ATEの少なくとも1つにフロア許可メッセージを送信する。一例として、アプリケーションサーバ170は、このグループ通信セッションに参加する各ATにフロア許可メッセージを送信するように構成されてよい。他の例では、アプリケーションサーバ170は、このグループ通信セッションに参加するATのうちの全数よりも少ないが複数のATにフロア許可メッセージを送信するように構成されてよい。したがって、特定のATが(全二重と同様に)送信と受信の両方を行うように構成され、一方、他のATが(半二重と同様に)受信または送信のみを行うように構成されてよい。また、ATAおよびATB...ATEの少なくとも1つがアプリケーションサーバ170にグループメッセージを送信することができるとともにアプリケーションサーバ170からグループメッセージを受信することもできる限り、520でフロア許可メッセージが送信される代わりに、任意の種類のメッセージが送信されてよい。
【００６５】
したがって、ATA...ATEの各々において、グループ通信セッションが開始されたことをそれぞれのATのユーザに示す音が鳴らされ、ATA...ATEは、下りリンクチャネル上における所与のデータレートでのアプリケーションサーバ170へのフレーム(たとえば、1つまたは複数のRTPパケット内に含まれるデータフレーム、無音フレーム)の送信を開始する。(525、530、535)
【００６６】
アプリケーションサーバ170は、所与の時間間隔またはタイムスロットにわたってATA...ATEからフレームを受信し、ATA...ATEのうちの1つまたは複数のATからのフレームを出力ストリーム上でATA...ATEのうちの他の各ATに送信されるフレームとして選択する(540)。540の選択は、アプリケーションサーバ170のMCCモジュール172によって実行され、MCCモジュール172での所与のタイムスロットについての、ATA...ATEからの入力ストリーム内のフレームのデータレートに少なくとも部分的に基づいて実行される。540の選択については以下に詳しく説明する。アプリケーションサーバ170は、540で選択を行った後、540で選択されたフレームの送信元であるATを除く各ATに、選択されたフレームを送信する。図5Aには明示的に示されていないが、アプリケーションサーバ170は、以下に詳しく説明するように、選択されないATからのフレームを選択されたフレームに関連するATに送信してもよい。
【００６７】
540の選択はいくつかの方法で実行され、次に、これらの方法の例について、図5B〜5Dに関して説明する。たとえば、ATA...ATEは、直接呼、アドホック呼、クローズドグループ呼、およびクローズドチャットルーム呼に関してTable 4(表4)(上記)によって定義されている優先順位レベルを有する。この仮定の下では、図5Aで確立されたグループ通信セッションが直接呼またはアドホック呼である場合、ATA...ATEの優先順位は同じであり(ただし、たとえば、このことはすべての直接呼またはアドホック呼に当てはまるわけではない)、一方、クローズドグループ呼またはクローズドチャットルーム呼の場合、ATA...ATEの優先順位レベルは必ずしも同じではないことが理解されよう。
【００６８】
したがって、図5Bは、本発明の一実施形態によって、各グループ通信セッション参加者が同じ優先順位レベルを有する、アプリケーションサーバ170で実行される540のフレーム選択の一例を示している。図5Bを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(たとえば、1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500B)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って選択を行う。たとえば、所与の選択規則は、第1の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1のAT)からの無音フレームが選択されるように訂正することができる。505Bの選択が、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが無音フレームを伝送するため、多数の異なる選択プロセスとして構成されてよい(たとえば、第2の聞き手の無音フレームが選択されたり、発信側の無音フレームが選択されたりしてよい)ことが理解されよう。
【００６９】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510B)。510Bで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515B)。このようなデータレートフレームが1つだけではなく、510Bで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、複数の高データレートフレームのうちのどのフレームが最高のデータレートを有するかを判定する(520B)。MCCモジュール172は次に、高データレートフレームの中に1つだけ他の高データレートフレーム(たとえば、ハーフレートフレーム)よりも高いデータレート(たとえば、フルレートフレーム)を有するフレームが存在するかどうかを判定する(525B)。他の実施形態では、MCCモジュール172は、複数の高データレートフレームを選択し、これらの高データレートフレームを(デジタル処理的に)混合し、後で、送信されるフレームとして選択できる単一の混合フレームを生成する。混合すべきフレームをこのように選択することは、MCCモジュール172で利用可能な処理パワーに基づいて行うことができ(たとえば、利用可能な処理パワーが低い場合には選択されるフレームを少なくし、利用可能な処理パワーが高い場合には選択されるフレームを多くすることができる)、かつ/あるいは単一の混合フレームを使用してサービスを提供することができるターゲットATの数に基づいて行うことができる(たとえば、同じ混合フレームを受信するターゲットATの数が多い場合、「多数の」ATに使用されるこの種の混合フレームの混合に割り振られる処理パワーが多くなるようにAT当たり処理消費量が比較的少なくなり、一方、混合フレームを受信するATの数が比較的少ない場合、混合されるフレームとして選択されるフレームを少なくすることができる)。1つだけ、他のすべてのフレームよりも高いデータレートを有するフレームが存在する場合、515Bで最高のデータレートを有するこ
のフレームが選択される。最高のデータレートを有するフレームが1つだけではない場合、MCCモジュール172は、他の所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、最高のデータレートを有するフレーム(たとえば、複数のフルレートフレーム、複数のハーフレートフレームなど)からの選択を行う。たとえば、この所与の選択規則は、RTPパケットが最小SSRC値を有するフレームの選択に相当する規則であってよい。530Bの選択が、ある程度恣意的なものであり、多数の異なる選択プロセスとして構成されてよい(たとえば、RTPパケットが最大SSRCパケットを有するフレームが選択されてよい)ことが理解されよう。
【００７０】
図5Cを参照すると、図5Cは、本発明の一実施形態によって、2人以上のグループ通信セッション参加者がそれぞれの異なる優先順位レベルを有する、アプリケーションサーバ170で実行される540のフレーム選択の一例を示している。図5Cを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500C)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って選択を行う。たとえば、所与の選択規則は、第1の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1のAT)からの無音フレームが選択されるように訂正することができる。505Cの選択が、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが無音フレームを伝送するため、多数の異なる選択プロセスとして構成されてよい(たとえば、第2の聞き手の無音フレームが選択されたり、発信側の無音フレームが選択されたり、Table 4(表4)(上記)から判定された最高優先順位のATの無音フレームが選択されたりしてよい)ことが理解されよう。
【００７１】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510C)。510Cで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515C)。このようなデータレートフレームが1つだけではなく、510Cで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、Table 4(表4)(上記)によって指定された最高優先順位レベルを有するATに関連付けられた高データレートフレームを選択する(520C)。図5Cには図示されていないが、複数のフレームが高データレートを有し、同じ最高優先順位レベルを有するATに関連付けられている場合、MCCモジュール172は、図5Bの530BにおけるフレームのRTPパケットのSSRC番号など他の所与の選択規則に基づいて520Cの選択を行うことができる。
【００７２】
理解されるように、図5Bおよび5Cは、図5Aの540の選択の比較的簡単な2つの例を表しており、本発明の他の実施形態では、他の多数の異なる選択アルゴリズムを実施してもよい。また、図5Bおよび/または5Cには示されていないが、他の実施形態では、図5Bおよび/または5Cのプロセスは、相対優先順位レベルおよび/または相対データレートなど他の留意事項にかかわらず、発信側が高データレートフレームを送信したときはいつでも発信側から高データレートフレームを選択してよい(あるいは、このことは、たとえば、他の留意事項に優先する最高優先順位レベルを発信側に与えることとみなされてよい)。また、Table 4(表4)(上記)はATA...ATEに対する静的な1組の優先順位レベルを示しているが、本発明の他の実施形態では、優先順位レベルが動的なものであってよく、呼の間に変更されてよいことが理解されよう。たとえば、多数の異なるATが高データレートフレームを送信する場合、公平のために、所与のATのフレームが選択されるたびにその所与のATの優先順位レベルを減分し、その所与のATのフレームが選択されないときにはそのATの優先順位レベルを増分してもよい。しかし、当業者には理解されるように、優先順位レベルを動的に調整する多数の異なる方法がある。
【００７３】
また、図5Bおよび5Cは、単一の高データレートフレームが(利用可能な場合)選択される選択アルゴリズムに関する図であるが、図5Bおよび5Cのプロセスは、以下にそれぞれ図5Dおよび5Eに関して説明するように、複数のフレームが選択されるように修正することができる。
【００７４】
図5Dは、各グループ通信セッション参加者が同じ優先順位レベルを有し、本発明の一実施形態によって複数のフレーム(たとえば、2つ以上のフレーム)が選択される、アプリケーションサーバ170で実行される図5Aの540のフレーム選択の一例を示している。特に、図5Dは、単一のフレームではなく複数のフレームを選択することができるような上述の図5Bのプロセスの変形例を示している。
【００７５】
図5Dを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(たとえば、1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500D)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って1つまたは複数のフレームを選択する。たとえば、所与の選択規則は、2人以上の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1および第2のAT)からの無音フレームが選択されるように訂正することができる。選択すべきフレームの実際の数(たとえば、2つ、3つなど)は、アプリケーションサーバ170のオペレータによって決定することができる。
【００７６】
505Dの選択が、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが複数の混合無音フレームを伝送するため、多数の異なる選択プロセスとして構成されてよい(たとえば、第2および第3の聞き手の無音フレームが選択されたり、発信側の無音フレームおよび第1の無音フレームが選択されたりしてよい)ことが理解されよう。
【００７７】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510D)。510Dで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515D)。次いで、520Dで、所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、選択された高データレートフレームよりも低いデータレート(たとえば、1/8レート)を有する少なくとも1つの追加的なフレームも選択される。たとえば、他の所与の選択規則は、520Dで所与の数の聞き手(たとえば、第1の聞き手、第2の聞き手など)から1つ(または複数)の無音フレームが選択されるような、505Bおよび/または505Dの選択に相当する規則であってよい。
【００７８】
このようなデータレートフレームが1つだけではなく、510Dで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、複数の高データレートフレームのうちで最高のデータレートを有するのはどれかを判定する(525D)。MCCモジュール172は次に、高データレートフレームの中に1つだけ他の高データレートフレーム(たとえば、ハーフレートフレーム)よりも高いデータレート(たとえば、フルレートフレーム)を有するフレームが存在するかどうかを判定する(525D)。1つだけ、他のすべてのフレームよりも高いデータレートを有するフレームが存在する場合、515Dでこの最高データレートフレームが選択され、プロセスは上述のように520Dに進む。最高のデータレートを有するフレームが1つだけではない場合、MCCモジュール172は、他の所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、最高のデータレートを有するフレーム(たとえば、複数のフルレートフレーム、複数のハーフレートフレームなど)のからすべてのフレームを選択し、選択される必要のあるフレームの数が最高データレートフレームの数よりも小さい場合、MCCモジュール172は、他の所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、最高のデータレートを有するフレームからの選択を行う。たとえば、この所与の選択規則は、RTPパケットが最小SSRC値を有する2つ(または3つ以上)のフレームの選択に相当する規則であってよい。535Dの選択が、ある程度恣意的なものであり、多数の異なる選択プロセスとして構成されてよい(たとえば、RTPパケットが最大SSRCパケットを有するフレームが選択されてよい)ことが理解されよう。535Dの選択の後、MCCモジュール172は、任意の追加的なフレームを選択するかどうかを判定する(540D)。追加的なフレームを選択する場合、プロセスは上述のように520Dに進む。追加的なフレームを選択しない場合、この特定のタイムスロットについて図5Dの選択プロセスが完了する。
【００７９】
図5Eを参照すると、2人以上のグループ通信セッション参加者がそれぞれの異なる優先順位レベルを有し、本発明の一実施形態によって複数のフレーム(たとえば、2つ以上のフレーム)が選択される、アプリケーションサーバ170で実行される540のフレーム選択の一例を示している。特に、図5Eは、単一のフレームではなく複数のフレームを選択することができるような上述の図5Cのプロセスの変形例を示している。
【００８０】
図5Eを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500E)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って1つまたは複数のフレームを選択する。たとえば、所与の選択規則は、2人以上の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1および第2のAT)からの無音フレームが選択されるように、505B、505Dおよび/または505Eの選択に対して訂正することができる。選択すべきフレームの実際の数(たとえば、2つ、3つなど)は、アプリケーションサーバ170のオペレータによって決定することができる。
【００８１】
505Dの選択は、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが依然として複数の混合無音フレームを搬送するので、多数の様々な方法で構成されてよい(たとえば、第2および第3の聞き手の無音フレームが選択されたり、発信側の無音フレームおよび第1の無音フレームが選択されたりしてよい)ことが理解されよう。
【００８２】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510E)。510Eで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515E)。次いで、520Eで、所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、選択された高データレートフレームよりも低いデータレート(たとえば1/8レート)を有する少なくとも1つの追加的なフレームも選択される。たとえば、他の所与の選択規則は、520Eで所与の数の聞き手(たとえば、第1の聞き手、第2の聞き手など)から1つ(または複数)の無音フレームが選択されるような、上記に図5Dに関して論じた520Dに相当する規則であってよい。
【００８３】
このようなデータレートフレームが1つだけではなく、510Eで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、Table 4(表4)(上記)によって指定された最高優先順位レベルを有するATに関連付けられた高データレートフレームを選択する(525E)。520Eでこのように選択されるフレームの数は、アプリケーションサーバ170のオペレータによって決定することができる。図5Eには示されていないが、選択に必要なフレームよりも多くのフレームが、高データレートを有し、かつ同じ最高優先順位レベルを有するATに関連付けられている場合、MCCモジュール172は、図5Bの530BにおけるフレームのRTPパケットのSSRC番号(たとえば、最大SSRC番号または最小SSRC番号)に基づく選択など所与の選択規則に基づいて、525Eの選択を行うことができる。
【００８４】
525Eの選択の後、MCCモジュール172は、任意の追加的なフレームを選択するかどうかを判定する(530E)。追加的なフレームを選択する場合、プロセスは上述のように520Eに進む。追加的なフレームを選択しない場合、この特定のタイムスロットについて図5Eの選択プロセスが完了する。
【００８５】
理解されるように、特定のタイムスロットの利用可能なフレームのサブセット(たとえば、そのようなフレームのうちの複数でありかつ全数よりも少ない数のフレーム)を選択する多数の異なる機構があり、図5Dおよび5Eはそのような選択プロセスの2つの例を示してきるに過ぎない。
【００８６】
以下に、図5B、5C、5D、および/または5Eに示されているような選択アルゴリズムに基づく、図5Aの高レベルグループ通信セッションプロセスのより詳細ないくつかの例について、図6A〜8に関して説明する。特に、図6Aおよび図7〜8は、図5Bおよび/または5Cと同様に単一のフレームが選択される例を示しており、図6Bは、図5Dおよび/または5Eと同様に複数のフレームが選択される例を示している。
【００８７】
したがって、図6Aは、本発明の一実施形態による図5Aのグループ通信セッションプロセスを示している。図6Aを参照すると、同じタイムスロット内で、ATBは1/8レートの無音フレームを送信し(600A)、ATC...ATEもそれぞれ、1/8レートの無線フレームを送信し(605A)、ATAは、音声データを保持するハーフレートのデータフレームを送信する(610A)。次に、615Aで、アプリケーションサーバ170のMCCモジュール172は、ATA...ATEのうちの1つからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図6Aの例では、高データレート(たとえば、この場合は、、1/2データレート、すなわち、ハーフデータレート)を有するのはATAからのフレームだけであるため、615でATAが選択される。515Bで図5Bの選択アルゴリズムがATAを選択し、一方、515Cで図5Cの選択アルゴリズムがATAを選択するため、図6Aのグループ通信セッションのコールタイプにかかわらずATAが選択されることが理解されよう。また、説明を明確にするために、図6Aの600A〜615Aがそれぞれ図5Aの525〜540に対応することが理解されよう。600A〜610Aの送信が10個のタイムスロット(すなわち、10t...T)にわたって繰り返されると仮定すると、タイムスロット10t...Tにおいてアプリケーションサーバ170で受信される入力ストリームは以下のように表されてよい。
【００８８】
【表７】
【００８９】
Table 7(表7)(上記)を参照すると、タイムスロット10t...Tの各々は、ATAがハーフレートフレームを送信することを示しており、一方、ATB...ATEの各々は、タイムスロット10t...Tで1/8レートフレームまたは無音フレームを送信する。したがって、タイムスロット10t...Tの各々について、図6Aの615Aで、出力ストリーム上でATB...ATEに送信されるフレームとしてATAのハーフレートフレームが選択される。
【００９０】
次に、620Aで、タイムスロット10t...Tの各々について、アプリケーションサーバ170は、ATAのハーフレートフレームを含む、出力ストリームの所与のタイムスロットに関するフレームを、ATB...ATEの各々に送信する。また、625Aおよび630Aは、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。625Aで、アプリケーションサーバ170は、615Aで選択されなかったATB...ATEのうちの1つからの所与のタイムスロットに関するフレームのうちの1つをATAに送信されるフレームとして選択する。たとえば、この選択は、625AではATAのフレームが考慮されないことを除いて、図5Bまたは5Cの選択アルゴリズムに従って実行されてよい。Table 7(表7)(上記)に基づいて、タイムスロット10t...Tの各々は、ATA...ATEの各々からの同じフレームレートで構成される。説明の都合上、625Aの選択では、タイムスロット10t...Tの各々についてATCのフレームが選択されると仮定する。したがって、630Aで、アプリケーションサーバ170は、10t...Tの各々について、ATCの1/8レートフレームを含む、出力ストリームの1つまたは複数のタイムスロットに関するフレームを、ATAに送信する。送信620Aおよび630Aは、別個のブロックとして示されているが、同時に実行されてよいことが理解されよう。したがって、上記に示した仮定に基づいて、620Aおよび630AでATA...ATEに送信される出力ストリームは以下のように表されてよい。
【００９１】
【表８】
【００９２】
表において、出力ストリーム内の各フレームについて括弧内に示されたATは、対応するタイムスロットに関する入力ストリーム上のこの示されたATからのフレームを示している。
【００９３】
図6Bは、本発明の他の実施形態による図5Aのグループ通信セッションプロセスを示している。特に、図6Bは、図6Aに示されているような図5Bおよび/または5Cの単一フレーム選択プロセスの代わりに、図5Dおよび/または5Eの多重フレーム選択プロセスが実施されるプロセスを示している。
【００９４】
したがって、図6Aと同様に、同じタイムスロット内で、ATBは1/8レートの無音フレームを送信し(600B)、ATC...ATEもそれぞれ、1/8レートの無線フレームを送信し(605B)、ATAは、音声データを保持するハーフレートのデータレートフレームを送信する(610B)。
【００９５】
次に、615Bで、アプリケーションサーバ170のMCCモジュール172は、ATA...ATEのうちの複数のATからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図6Bの例では、ATA...ATEのうちで高データレートフレーム(たとえば、ハーフレートフレーム)を送信するのがATAだけであるため、ATAからのフレームが選択されるフレームのうちの1つに相当すると仮定されてよい。したがって、図5Dの選択プロセスでは、510Dで高データレートフレームが1つしか存在しないことが判定された後、515DでATAのフレームが選択される。次に、この例では、説明の都合上、ATAのフレームが選択された後、520DでATBのフレームも選択されると仮定されてよい。したがって、本明細書の例では、615Bで2つのフレームが選択されると仮定する。ただし、他の実施形態では、615Bで3つ以上のフレームが選択されてよい。他の例では、図5Dの代わりに図5Eの選択プロセスが実施された場合、510Eで高データレートフレームが1つしか存在しないことが判定された後、515EでATAのフレームが選択されることが理解されよう。説明の都合上、この実装形態ではさらに、520EでATBのフレームが選択されると仮定する。したがって、後に615BでATAおよびATBからのフレームが選択されると仮定する。
【００９６】
MCCモジュール172は、615BでATAおよびATBからのフレームを選択した後、620Bで選択されたフレームを混合する。この混合は、従来のメディアストリームを(たとえば、デジタル処理的に)混合するのと同じ方法に相当する混合であってよい。ただし、620Bの混合は、フレームの選択された(たとえば、ATAおよびATBのみから選択された)サブセットに限定され、送信を行うことが許可されているグループ通信セッションの各参加者(たとえば、この場合は、ATA...ATE)からの各フレームを混合するわけではない。したがって、MCCモジュール172は次に、混合されたフレーム(すなわち、フレームA+フレームB)をATC...ATEに送信し、ATBからの混合されていないフレームをATAに送信し、ATAからの混合されていないフレームをATBに送信する。この実施形態では、フィードバックの発生を低減させるために混合されたフレームがATAにもATBにも送信されないことが理解されよう。ただし、他の実施形態においてMCCモジュール172でのプログラミング論理を簡略化するために混合されたフレームをすべての参加者に同様に送信することが少なくとも理論的にはあり得る。しかし、615Bで3つ以上のフレームが選択される他の実施形態では、選択されたフレームに関連付けられた各ATが実際に、混合されたフレームを受信する。ただし、選択された各AT自体のフレームは、それが受信するストリームから除去される。
【００９７】
また、説明を明確にするために、図6Aの600B〜615Bがそれぞれ、図5Aの525〜540に相当することが理解されよう。600B〜610Bの送信および615Bの選択が10個のタイムスロット(すなわち、10t...T)について繰り返されると仮定すると、タイムスロット10t...Tにおいてアプリケーションサーバ170で受信される入力ストリームは、上記にTable 7(表7)に示されているように表されてよい。
【００９８】
したがって、620Bで、タイムスロット10t...Tの各々について、アプリケーションサーバ170は、ATAのハーフレートフレームおよびATBの1/8レートフレームを含む、出力ストリームの所与のタイムスロットに関するフレームを、ATC...ATEの各々に送信する。また、625Bおよび630Bは、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。625Bで、アプリケーションサーバ170は、615Bで選択されなかったATC...ATEのうちの1つからの所与のタイムスロットに関するフレームのうちの1つをATAおよびATBに送信されるフレームとして選択する。たとえば、625Bの選択は、625BではATAおよびATBのフレームが考慮されないことを除いて、図5Bまたは5Cの選択アルゴリズムに従って実行されてよい。Table 7(表7)(上記)に基づいて、タイムスロット10t...Tの各々は、ATA...ATEの各々からの同じフレームレートで構成される。説明の都合上、625Bの選択では、タイムスロット10t...Tの各々についてATCのフレームが選択されると仮定する。したがって、630Bで、アプリケーションサーバ170は、10t...Tの各々について、(たとえば、ATAからATBへの混合されていないフレームおよびATBからATAへの混合されていないフレームに加えて)ATCの1/8レートフレームを含む、出力ストリームの1つまたは複数のタイムスロットに関するフレームを、ATAおよびATBに送信する。送信620Bおよび630Bは、別個のブロックとして示されているが、同時に実行されてよいことが理解されよう。したがって、上記に示した仮定に基づいて、620Bおよび630BでATA...ATEに送信される出力ストリームは以下のように表されてよい。
【００９９】
【表９】
【０１００】
この場合、10t...Tの各タイムスロットにおいて、ATAは1/4レートフレームを受信し(すなわち、ATBおよびATCからの1/8レートフレーム同士を組み合わせたフレームを受信し)、ATBは5/8レートフレームを受信し(すなわち、ATAからの1/2レートフレームとATCからの1/8レートフレームを組み合わせたフレームを受信し)、ATC...ATEの各々は5/8レートフレームを受信する(すなわち、ATAからの1/2レートフレームとATBからの1/8レートフレームを組み合わせたフレームを受信する)。
【０１０１】
したがって、図6Aおよび6Bを検討すると理解されるように、図5Aの540の選択は、タイムスロット当たりに1つのATからの単一のフレームを他の各ATに送信されるフレームとして選択することに相当する選択であってよく(たとえば、図6A参照)、あるいはタイムスロット当たりに複数のAT(たとえば、2つ以上のAT)からの単一のフレームを他の各ATに送信されるフレームとして選択することに相当する選択であってよい(たとえば、図6B参照)。以下の他の実施形態は、図6Aのようにタイムスロット当たりに単一のATから単一のフレームを選択すること、すなわち、図5Bおよび5Cの選択プロセスに関する実施形態である。しかし、これらの実施形態についての説明は、説明の都合上のものであり、以下に図7〜13に関して説明する実施形態において複数のATからのフレームを選択できないことを意味するものではない。言い換えれば、図5D、5E、または6Bのようにタイムスロット当たりに複数のフレームを選択することを後述の各実施形態に適用することは当業者の能力の範囲内であり、したがって、タイムスロット当たりに単一のATからの単一のフレームを選択することの参照は、各実施形態の理解を容易にするための例に過ぎない。
【０１０２】
したがって、次に、ATA...ATEのそれぞれが高データレートフレームを順に送信する(たとえば、多数の参加者同士の会話が行われていることを示すと考えられる)分散トークサポート(interspersed talk support)の例について説明する。したがって、図6A(または他の実施形態では、たとえば、図6B)のプロセスが、少なくとも1つの時間間隔またはタイムスロットについて実行され、次いで図7の700に進むと仮定する。
【０１０３】
図7を参照すると、図6Aの620Aおよび630Aにおいて所与のタイムスロットに関する出力ストリームが送信されたことに続く次のタイムスロットで、ATBが音声データを保持するハーフレートデータフレームを送信し(700)、ATC...ATEがそれぞれ1/8レート無音フレームを送信し(705)、ATAが1/8レート無音フレームを送信する(710)と仮定する。次に、715で、アプリケーションサーバ170のMCCモジュール172は、ATA...ATEのうちの1つからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図7の例では、高データレート(たとえば、この場合は、1/2データレート、すなわち、ハーフデータレート)を有するのはATBからのフレームだけであるため、715でATBが選択される。515Bで図5Bの選択アルゴリズムがATBを選択し、一方、515Cで図5Cの選択アルゴリズムがATBを選択するため、図7のグループ通信セッションのコールタイプにかかわらずATBが選択されることが理解されよう。また、説明を明確にするために、図7の700〜715がそれぞれ図5Aの525〜540に対応することが理解されよう。
【０１０４】
600A〜610Aの送信が5個のタイムスロット(10t...6t)にわたって繰り返され、700〜710の送信が次の5個のタイムスロット(5t...T)にわたって繰り返されると仮定すると、タイムスロット10t...Tにわたってアプリケーションサーバ170で受信される入力ストリームは以下のように表されてよい。
【０１０５】
【表１０】
【０１０６】
Table 9(表10)(上記)を参照すると、タイムスロット10t...6tの各々は、ATAがハーフレートフレームを送信することを示しており、一方、ATB...ATEの各々は、1/8レートフレームまたは無音フレームを送信する。さらに、タイムスロット5t...Tの各々は、ATBがハーフレートフレームを送信することを示しており、一方、ATAおよびATC...ATEの各々は、1/8レートフレームまたは無音フレームを送信する。したがって、タイムスロット10t...6tの各々については、図6Aの615Aで、出力ストリーム上でATB...ATEに送信されるフレームとしてATAのハーフレートフレームが選択され、一方、5t...Tの各々については、図7の715で、出力ストリーム上でATAおよびATC...ATEに送信されるフレームとしてATBのハーフレートフレームが選択される。
【０１０７】
次に、720で、タイムスロット5t...Tの各々について、アプリケーションサーバ170は、ATBのハーフレートフレームを含む出力ストリームをATAおよびATC...ATEの各々に送信する。また、725および730は、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。725で、アプリケーションサーバ170は、タイムスロット5t...Tについて、715で選択されなかったATAおよびATC...ATEのうちの1つからの所与のタイムスロットに関するフレームのうちの1つをATBに送信されるフレームとして選択する。たとえば、725の選択は、725ではATBのフレームが考慮されないことを除いて、図5Bまたは5Cの選択アルゴリズムに従って実行されてよい。Table 9(表10)(上記)に基づいて、タイムスロット5t...Tの各々は、ATA...ATEの各々からの同じフレームレートで構成される。説明の都合上、725の選択では、タイムスロット5t...Tの各々についてATCのフレームが選択されると仮定する。したがって、730で、アプリケーションサーバ170は、5t...Tの各々について、ATCの1/8レートフレームを含む出力ストリームをATBに送信する。送信720および730は、別個のブロックとして示されているが、同時に実行されてよいことが理解されよう。したがって、上記の仮定に基づき、Table 9(表10)(上記)の入力ストリームに基づいてタイムスロット10t...TにわたってATA...ATEに送信される出力ストリームは、以下のように表されてよい。
【０１０８】
【表１１】
【０１０９】
図6Aの例は、単一のAT(すなわち、ATA)からの連続トークサポート(continuous talk support、たとえば、一連の高データレートフレーム)に関する例であり、図7は分散トークサポート(たとえば、各ATが順に高データレートフレームを送信する)に関する例であるが、次に、複数のATが高データレートフレームを同時に送信する例について図8に関して説明する。図8は、どのATも高データレートフレームを送信しないタイムスロットをどのように評価するかについての例も示している。
【０１１０】
図8を参照すると、各ATA...ATEは、10t...Tの10個のタイムスロット間隔にわたって所与のデータレートでフレーム(たとえば、データフレームおよび/または無音フレーム)を送信する(800、805および810)。
【０１１１】
815で、アプリケーションサーバ170のMCCモジュール172は、タイムスロット10t...Tの各々について、ATA...ATEのうちの1つからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図8の例では、800〜810の送信によって、アプリケーションサーバ170のMCCモジュール172で、Table 11(表12)(下記)に示されているような入力ストリームが得られる。
【０１１２】
【表１２】
【０１１３】
したがって、Table 11(表12)(上記)のタイムスロット10tおよび3t...Tについての選択は、図6Aに従って実行され(たとえば、上記のTable 7(表7)を参照されたい)、ATA...ATEのうちで、これらのタイムスロットで高データレートフレームを送信するATがATAだけであるため、ATAからのハーフレートフレームが選択される。同様に、Table 11(表12)(上記)のタイムスロット8t、7t、および5tについての選択は、図7のタイムスロット5t...Tに従って実行され(たとえば、上記のTable 9(表10)を参照されたい)、ATA...ATEのうちで、これらのタイムスロットで高データレートフレームを送信するATがATBだけであるため、ATBからのハーフレートフレームが選択される。
【０１１４】
しかし、Table 11(表12)(上記)のタイムスロット9tおよび6tでは、ATAとATBの両方がハーフレートフレームを送信する。したがって、アプリケーションサーバ170は、図8の815における9tおよび6tについては、グループ通信セッションのコールタイプに基づいて図5Bおよび/または5Cに示されているような選択アルゴリズムを適用する。たとえば、ATA...ATEの各々がグループ通信セッションのコールタイプに関して同じ優先順位レベルを有する場合、815の選択が図5Bに従って実行され、ATA...ATEのうちの2つ以上がグループ通信セッションのコールタイプに関してそれぞれの異なる優先順位レベルを有する場合、815の選択が図5Cに従って実行される。いずれの場合も、説明の都合上、図8におけるATAとATBの同時高データレートフレーム送信に関する評価によって、コールタイプにかかわらず、(たとえば、図5Bにおける530Bの選択または図5Cにおける520Cの選択に基づいて)ATBのフレームが選択される。
【０１１５】
また、タイムスロット4tでは、ATA...ATEの各々が1/8レート無音フレームを送信する。したがって、図5Bの500Bおよび図5Cの500Cの判定はそれぞれ505Bおよび505Cに進み、4tにおける送信には、コールタイプにかかわらず、第1の聞き手の無音フレームが選択される。
【０１１６】
また、上記の625A/725および630A/730と同様に、825および830は、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。825で、アプリケーションサーバ170は、タイムスロット10t...Tの各々について、815で対応するタイムスロットについて選択されなかったATA...ATEのうちの1つからの所与のタイムスロットに関するフレームの1つを、対応するタイムスロットの選択されたフレームに関連付けられたATに送信されるフレームとして選択する。825で、10tおよび3t...TについてATBの1/8レートフレームが選択され、9t...5tについてATCの1/8レートフレームが選択される。入力ストリームにはデータフレームがなく、したがって、(たとえば、ATA...ATEの1つがそれ自体の無音フレームをフィードバックされるにもかかわらず)815で選択された1/8無音フレームがATA...ATEの各々に送信されるため、4tでは825および830が実行されないことが理解されよう。アプリケーションサーバ170は次に、10t...5tおよび3t...Tにわたって、825で選択されたフレームを各ATに送信する(830)。
【０１１７】
したがって、上記に示した仮定に基づいて、820および830でタイムスロット10t...TにわたってATA...ATEに送信される出力ストリームは以下のように表されてよい。
【０１１８】
【表１３】
【０１１９】
当業者によって理解されるように、ATA...ATEへの出力ストリーム上でRTPパケットのヘッダをどのように構成するかが、ターゲットATが、フレームを含むRTPパケットを首尾よく復号するかあるいは単にフレームを破棄するかに影響を与えることがある。たとえば、RTPパケットヘッダ部の概略的な構造がTable 1(表1)(上記)に示されている。上記のように、RTPパケットヘッダは、いくつかのあるフィールドの中で特に、それぞれ、上記にTable 1(表1)(上記)に関して定義された、CCフィールド、シーケンス番号フィールド、タイムスタンプフィールド、およびSSRCフィールドを含む。
【０１２０】
メディアストリームを復号するATは、これらのフィールドの各々についてのメディアストリームの有効なRTPパケットにどんな種類の値が関連付けられるかに関するある程度の予想をすることができる。たとえば、誤ったSSRC番号、タイムスタンプ値、および/またはシーケンス番号を有するATでRTPパケットが受信された場合、そのRTPパケットはATによって単に破棄される。理解されるように、ATA...ATEからアプリケーションサーバ170で受信される各メディアストリームは、各ATの下りリンクメディアストリームに固有のフィールド値を有するRTPパケットで構成される。たとえば、ATAはそのメディアストリームを識別するATA自体のSSRC値を有する。
【０１２１】
図9は、本発明の一実施形態によって、アプリケーションサーバ170においてあるATのフレームから他のATのフレームに切り替える際にグループ通信セッションのメディアフローのターゲットATでのパケット破棄率を低下させることのできる高レベルプロセスを示している。
【０１２２】
図9を参照すると、900で、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する。一例として、900の選択は、上述の各実施形態における任意のフレーム選択(たとえば、図5Aの540、図6Aの615A、図6Aの625Aなど)に相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内でATAに送信される出力フレームを生成する(905)。905で、アプリケーションサーバ170は、ATAの出力されたフレームを保持するRTPパケットのRTPパケットヘッダを、ATA...ATEのうちのどのATのフレームが、構成されたRTPパケット内でATAに送信されるかにかかわらず、ATAでの復号を容易にするように構成する。言い換えれば、入力ストリーム上の選択されたフレームから得られるメディアフローパラメータ(たとえば、CCフィールド、タイムスタンプフィールド、SSRCフィールド、シーケンス番号フィールドなど)は、必要に応じて、出力ストリームを保持するRTPパケット向けに再構成される。
【０１２３】
たとえば、以下に詳しく説明するように、905の構成は、送信側ATまたは送信元ATに固有のアプリケーションサーバ170の入力ストリームで受信されるRTPパケットヘッダにおけるCCフィールド、シーケンス番号フィールド、タイムスタンプフィールド、および/またはSSRC番号フィールドを、グループ通信セッションの出力ストリーム用の値としてアプリケーションサーバ170によって維持されているフィールド値に修正することを含んでよい。したがって、RTPパケットのデータペイロード部は、入力ストリームにおけるどのフレームがATAに出力されるフレームとして選択されるかに応じて修正されるが、RTPパケットヘッダ部は、必要に応じてATAでの復号を容易にするように調整することができ、入力ストリーム上に選択されたフレームを保持するRTPパケットにマップするだけでよいわけではない。
【０１２４】
アプリケーションサーバ170は、出力フレームを修正されたRTPパケットヘッダ部を含むように構成した後、構成された出力フレームをATAに送信する(910)。ATAは、出力フレームのRTPパケットヘッダ部をどのように構成するかに少なくとも部分的に基づいて、RTPパケットを復号すべきかどうかを判定する(915)。RTPパケットヘッダ部の構成のために、ATAが915でRTPパケットを復号すべきであると判定し、RTPパケットおよび関連するフレームがATAによって復号される(920)。
【０１２５】
次に、グループ通信セッションに対するターゲットATでの復号を容易にするようにアプリケーションサーバ170で行うことのできるRTPパケットヘッダ修正のより具体的な例について図10〜13に関して説明する。
【０１２６】
たとえば、図10は、アプリケーションサーバ170が出力ストリームでATAに転送されるRTPパケットのSSRC値の修正を行わない、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示し、一方、図11は、アプリケーションサーバ170が図9に従ってSSRC値を修正する同じグループ通信セッション中のATAでの復号結果を示している。
【０１２７】
図10を参照すると、アプリケーションサーバ170は、グループ通信セッションについての現在の話し手、すなわち、フロアホルダを識別するSSRC値(たとえば、SSRC=2)をATAに割り当てる(1000)。たとえば、1000におけるSSRC値の割り当てはASK/FYIメッセージに相当する割り当てであってよく、ATAは、最後に割り当てられたSSRC値に相当するSSRC値を有するグループ通信セッションに関するRTPパケットのみを復号する。したがって、ATAは、ATAで他のSSRC値割り当てメッセージ(たとえば、ASK/FYIメッセージ)が受信されるまでSSRC値が2であるRTPパケットのみを復号する。理解されるように、ASK(ユーザID)メッセージは、ATが未知のSSRCまたは予期しないSSRCを含むRTPパケットを受信した場合にATによってアプリケーションサーバ170に送信される。アプリケーションサーバ170は、未知のSSRC値に対応するクライアントのIDでASKメッセージに応答する。図10の上部で、図10のステップ1000におけるSSRC割り当てを指示するASKメッセージまたはFYIメッセージは、ステップ1000でSSRC2が割り当てられる前にATAがSSRC2からRTPパケットを受信したときにATAでトリガすることができ、かつ後に後述のステップ1040でSSRC3が受信された後でATAでトリガすることができる。
【０１２８】
次に、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する(1005)。一例として、1000の選択は図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1010)。図10の例では、出力フレームを保持するRTPパケットが、SSRC値2を有するこのフレームの送信元ATに関連付けられたSSRC値をパケットのヘッダ部に維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないSSRC値の2を含むRTPパケットで出力フレームをATAに送信する(1015)。
【０１２９】
ATAは、送信された出力フレームを(場合によっては、たとえば、他の出力フレームと一緒に)保持するRTPパケットを受信し、RTPパケットヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1020)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が2に等しいかどうかを検査する。RTPパケットのSSRC値は2と仮定されているので、ATAはこのフレームを復号する(1025)。
【０１３０】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1030)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1035)。図10の例では、(たとえば、アプリケーションサーバ170が、別のATからあるフレームに切り替えたため)出力フレームを保持するRTPパケットが、この場合はSSRC値3を有するこのフレームの送信元ATに関連付けられたSSRC値を維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないSSRC値の3を含むRTPパケットで出力フレームをATAに送信する(1040)。
【０１３１】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1045)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が2に等しいかどうかを検査する。RTPパケットのSSRC値は3と仮定されているので、ATAはこのフレームを破棄する(1050)。また、ATAがSSRC3を復号するように指定された後のSSRC2からのRTPパケットを破棄すべきであるのは、RTPパケットヘッダ内の関連するタイムスタンプがSSRC3からの最新のパケットよりも古い場合だけであり、これによって、SSRC2RTPパケットがSSRC2への正当な切り替えである場合に破棄されるパケットの発生が少なくなることを理解されたい。
【０１３２】
図示の例では、この下りリンクRTPパケット送信についてATA...ATEに割り当てられるSSRC値はそれぞれ、1...5であると仮定する。次に、タイムスロット10t...Tにわたってアプリケーションサーバ170のMMCモジュール172で受信される入力ストリームはTable 11(表12)(上記)に相当する入力ストリームであると仮定する。したがって、すでに上記にTable 12(表13)(上記)に関して説明した、ATA...ATEに送信される出力ストリームは、以下のように、各出力フレームのSSRC値、または出力フレームのRTPパケットを含んでよい(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)。
【０１３３】
【表１４】
【０１３４】
次に、パケット復号のための1000のSSRC値割り当てによって、上述のように(SSRC=2)がATAに送信され、(SSRC=1)がATB...ATEの各々に別個に示されると仮定する。これらの仮定の下で、他のSSRC値割り当てメッセージがATA...ATEに送信されることはなく、図10のプロセスがタイムスロット10t...TにわたってATA...ATEで実行されると仮定すると、Table 14(表15)(下記)が、ATA...ATEの各々で実際に復号または再生されるRTPパケットを示す(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)ことが理解されよう。
【０１３５】
【表１５】
【０１３６】
Table 14(表15)に示されているように、ATB...ATEは、関連するSSRC値が1ではないためタイムスロット9t...4t間の各パケットを破棄する。
【０１３７】
したがって、図11は、図10に示されたシナリオに適用される図9のプロセスを示している。図11は、アプリケーションサーバ170が、図9に従って出力ストリームでATAに転送されるRTPパケットのSSRC値を修正する、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示している。
【０１３８】
図11を参照すると、アプリケーションサーバ170は、アプリケーションサーバ170によってグループ通信セッションに関して転送される任意のRTPパケットを識別するのに使用されるSSRC値(たとえば、SSRC=1)をATAに割り当てる(1000)。1000のSSRC値割り当ては、アプリケーションサーバ170がグループ通信セッション中に様々なATのフレーム同士を切り替えるにもかかわらず、グループ通信セッション当たりに1度実行されるだけでよい。したがって、ATAは、グループ通信セッション中にSSRC値が1のパケットを復号するに過ぎない。図11には明示的に示されていないが、ATB...ATEの各々も、ATB...ATEに、グループ通信セッションのために、SSRC値が1に等しいRTPパケットを復号するよう指示するSSRC値割り当てメッセージを受信する。
【０１３９】
次に、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する(1105)。一例として、1105の選択は、図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1110)。特に、アプリケーションサーバ170は、必要に応じて、生成される出力フレームのSSRC値が1になるように、1110で出力フレームを保持するRTPパケットのSSRC値を修正する。また、アプリケーションサーバ170は、出力フレームを保持するRTPパケットのCSRC値を、その出力フレームの送信元ATのSSRC値を示すSSRC値に任意に修正してよい。したがって、入力ストリーム内の選択されたフレームに関連付けられたRTPパケットのSSRC値が4である場合、出力フレームのSSRC値は4から1に置き換わり、CSRCが4に等しく設定される。したがって、アプリケーションサーバ170は、(場合によっては)修正されたSSRC値の1(および適宜、たとえば、CSRC値4)を含むRTPパケットで出力フレームをATAに送信する(1115)。
【０１４０】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1120)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が1に等しいかどうかを検査する。アプリケーションサーバ170がRTPパケットのSSRC値を1に設定したため、ATAはこのフレームを復号する(1125)。
【０１４１】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1130)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1135)。1110と同様に、新たに選択されたフレームについてのRTPパケットの入力ストリーム内のSSRC値にかかわらず、ATAへの出力ストリーム内に出力フレームを保持するRTPパケットのSSRC値が1に設定され、入力ストリーム上の選択されたフレームのRTPパケットのSSRC値に対応するCSRC値を任意に、出力フレームを保持するRTPパケットのRTPパケットヘッダ部に付加してよい(1135)。したがって、アプリケーションサーバ170は、(場合によっては)修正されたSSRC値の1(および場合によっては、たとえば、CSRC値4)を含むRTPパケットで出力フレームをATAに送信する(1140)。
【０１４２】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1145)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が1に等しいかどうかを検査する。アプリケーションサーバ170がRTPパケットのSSRC値を1に設定したため、ATAはこのフレームを復号する(1150)。
【０１４３】
図示の例では、ATA...ATEの下りリンクRTPパケット送信に関してATA...ATEに割り当てられたSSRC値がそれぞれ1...5であると仮定する。次に、タイムスロット10t...Tにわたってアプリケーションサーバ170のMCCモジュール172で受信された入力ストリームがTable 11(表12)(上記)に相当する入力ストリームであると仮定する。したがって、すでに上記にTable 12(表13)(上記)に関して説明した、ATA...ATEに送信される出力ストリームは、以下のように、出力ストリームの出力フレームを保持する各RTPパケットのSSRC値を含んでよい(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)。
【０１４４】
【表１６】
【０１４５】
次に、パケット復号のための1000のSSRC値割り当てによって、上述のように(SSRC=1)がATAに送信され、(SSRC=1)がATB...ATEの各々に別個に示されると仮定する。これらの仮定の下で、他のSSRC値割り当てメッセージがATA...ATEに送信されることはなく、図11のプロセスがタイムスロット10t...TにわたってATA...ATEで実行されると仮定すると、Table 15(表16)(上記)が、出力ストリームを示すだけでなく、破棄されるパケットがないため、それぞれのATA...ATEの各々での再生も示すことが理解されよう。
【０１４６】
図10および11は、グループ通信セッション中の各ATでのパケット復号の決定に対するSSRC値の影響を示すことに関する図であるが、パケット復号の決定に影響を与える可能性のある他のRTPパケットヘッダフィールドは、次に図12および13に関して説明するようにシーケンス番号である。
【０１４７】
たとえば、図12は、アプリケーションサーバ170が出力ストリームでATAに転送されるRTPパケットのシーケンス番号値を修正しない、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示しており、一方、図13は、アプリケーションサーバ170が図9に従ってシーケンス番号値を修正する、同じグループ通信セッション中のATAでの復号結果を示している。
【０１４８】
図12を参照すると、1200で、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する(1200)。一例として、1200の選択は図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1205)。図12の例では、出力フレームを保持するRTPパケットが、現在のタイムスロットのシーケンス番号の2021を有するこのフレームを保持する送信元ATのRTPパケットに関連付けられたシーケンス番号値を維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないシーケンス番号値の2021を含むRTPパケットで出力フレームをATAに送信する(1210)。
【０１４９】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1215)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が1つまたは複数の以前のRTPパケットと連続しているかどうかを検査する。1215では、シーケンス番号値が連続していると仮定し、ATAはこのRTPパケットペイロードを復号し、それによってこのフレームを復号する(1220)。
【０１５０】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1225)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1230)。図12の例では、出力フレームを保持するRTPパケットが、たとえば、シーケンス番号102を有する可能性があるこのフレームの送信元ATに関連付けられたシーケンス番号値を維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないシーケンス番号値の102を含むRTPパケット内の出力フレームをATAに送信する(1235)。
【０１５１】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1240)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が1つまたは複数の前のRTPパケットと連続しているかどうかを検査する。シーケンス番号102はシーケンス番号2021と連続していないため、ATAはこのフレームを破棄する(すなわち、RTPパケットペイロード部を復号しない)(1245)。
【０１５２】
図示の例では、Table 11(表12)(上記)の入力ストリームのタイムスロット10t...Tにわたるこの下りリンクRTPパケット送信についてATA...ATEに割り当てられるシーケンス番号値は、以下のようにTable 16(表17)(下記)によって示される値であると仮定する。
【０１５３】
【表１７】
【０１５４】
したがって、すでに上記にTable 12(表13)(上記)に関して説明した、ATA...ATEに送信される出力ストリームは、以下のように、出力ストリームの関連する出力フレームを保持する各RTPパケットのシーケンス番号値を含んでよい(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)。
【０１５５】
【表１８】
【０１５６】
これらの仮定の下で、図12のプロセスがタイムスロット10t...TにわたってATA...ATEで実行される場合、Table 18(表19)(下記)が、ATA...ATEの各々で実際に復号または再生されるRTPパケットを示すことが理解されよう。
【０１５７】
【表１９】
【０１５８】
Table 18(表19)に示されているように、ATB...ATEは、関連するシーケンス番号が連続していないため、タイムスロット9t...4t間の各フレームを破棄する。
【０１５９】
次に、図13は、図12に示されたシナリオに適用される図9のプロセスを示している。図12は、アプリケーションサーバ170が、図9に従って出力ストリームでATAに転送されるRTPパケットのシーケンス番号値を修正する、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示している。
【０１６０】
図13を参照すると、アプリケーションサーバ170は、入力ストリーム上のRTPパケットに関連付けられた個々のシーケンス番号にかかわらず、出力ストリーム上のRTPパケットに使用されるシーケンス番号値(たとえば、0001、0002、0003など)の単一のストリームを維持する。
【０１６１】
1300で、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する。一例として、1300の選択は、図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1305)。特に、アプリケーションサーバ170は、必要に応じて、RTPパケットのシーケンス番号値がグループ通信セッションの出力フレームシーケンスの現在のシーケンス番号(グループ通信セッションシーケンス番号)(たとえば、0001)に対応するように、1305で出力フレームを保持するRTPパケットのシーケンス番号値を修正する。したがって、アプリケーションサーバ170は、現在のグループ通信セッションシーケンス番号を含むRTPパケットで出力フレームをATAに送信し(1310)、次にグループ通信セッションシーケンス番号を(たとえば、0001から0002に)増分する(1315)。
【０１６２】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1320)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が順序正しい値であるかどうかを検査する。アプリケーションサーバ170がそれぞれの異なるATのメディアフロー同士を切り替えるかどうかにかかわらず、グループ通信セッションシーケンス番号の順序が維持されるため、ATAは、RTPパケットペイロード部を復号し、それによってこのフレームを復号する(1325)。
【０１６３】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1330)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1335)。1305と同様に、新たに選択されたフレームを保持するRTPパケットの入力ストリーム内のシーケンス番号値にかかわらず、ATAへの出力ストリーム内に出力フレームを保持するRTPパケットのシーケンス番号値が現在のグループ通信セッションシーケンス番号(たとえば、0002)に設定される(1335)。したがって、アプリケーションサーバ170は、現在のグループ通信セッションシーケンス番号を含むRTPパケット内の出力フレームをATAに送信する(1340)。
【０１６４】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1345)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が順序正しい値であるかどうかを検査する。アプリケーションサーバ170がそれぞれの異なるATのメディアフロー同士を切り替えるかどうかにかかわらず、グループ通信セッションシーケンス番号の順序が維持されるため、ATAは、RTPペイロード部を復号し、それによってこのフレームを復号する(1350)。
【０１６５】
図示の例では、Table 11(表12)(上記)の入力ストリームのタイムスロット10t...TにわたるATA...ATEの下りリンクRTPパケット送信に関してATA...ATEに割り当てられたシーケンス番号値が、Table 16(表17)(上記)によって示されている値であると仮定する。これらの仮定の下では、図13のプロセスがタイムスロット10t...TにわたってATA...ATEで実行された場合、Table 19(表20)(下記)が、すでに上記でTable 12(表13)(上記)に関して説明済みであり、出力ストリームの各出力フレームを保持するRTPパケットのシーケンス番号値を含む、ATA...ATEに送信される出力ストリームを示す(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)ことが理解されよう。
【０１６６】
【表２０】
【０１６７】
これらの仮定の下で、図13のプロセスがタイムスロット10t...TにわたってATA...ATEで実行されると仮定すると、Table 19(表20)(上記)が、出力ストリームを示すだけでなく、破棄されるRTPパケットがないため、それぞれのATA...ATEの各々での再生も示すことが理解されよう。
【０１６８】
図11および13は、それぞれSSRCおよびシーケンス番号に対する修正に基づく図9の実装形態に関する図であるが、図11および13のプロセスが同時に実行されてもよいことが理解されよう。また、図9の他の実装形態は、RTPパケットヘッダのタイムスタンプフィールドなど、RTPパケットヘッダの他のフィールド(メディアフローパラメータ)の復号を容易にするように修正することに関する実装形態であってもよい。この実施形態については、図9から13の説明に鑑みて容易に明らかになるので、あまり詳しく説明しない。
【０１６９】
各実施形態を概してオーディオベースのグループ通信セッションに関して説明したが、他の実施形態は、テレビ会議など他の種類のグループ通信セッションに関する実施形態であってよい。また、各実施形態はRTPパケットに関する実施形態であるが、本発明の他の実施形態が他の種類のメディアパケットに関するものであってよいことが理解されよう。たとえば、RealNetworksプロトコルに従って動作するシステムでは、RTPパケットの代わりにRDTパケットを使用してよい。言い換えれば、上述のように、各実施形態は概してEVRC-Aプロトコルに従った実装形態に関する実施形態であるが、本発明の他の実施形態では、離散フレームレートセットを有する他のボコーダ(たとえば、AMRなど)を使用してよい。
【０１７０】
当業者には、様々な異なる技術および技法のいずれかを使用して情報および信号を表してよいことが理解されよう。たとえば、上記の説明全体を通して参照される可能性があるデータ、命令、コマンド、情報、信号、ビット、記号、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光学場または光学粒子、あるいはそれらの組み合わせによって表されてもよい。
【０１７１】
また、当業者には、本明細書に開示された実施形態に関連して記載された様々な例示的な論理ブロック、モジュール、回路、アルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、またはその両方の組み合わせとして実現されてよいことが理解されよう。ハードウェアとソフトウェアをこのように交換可能であることを明確に示すために、上記では、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを概してその機能に関して説明した。そのような機能がハードウェアとして実施されるかそれともソフトウェアとして実施されるかは、特定の用途およびシステム全体に課される設計上の制約によって決まる。当業者は、上述の機能を各々の特定の用途に関して様々な方法で実施することができるが、そのような実装上の決定を本発明の範囲から逸脱させるものと解釈すべきではない。
【０１７２】
本明細書に開示された実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくはその他のプログラマブル論理デバイス、離散ゲート論理回路もしくは離散トランジスタ論理回路、離散ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組み合わせによって実施または実行されてよい。汎用プロセッサはマイクロプロセッサであってよいが、従来のプロセッサ、コントローラ、マイクロコントローラ、または状態マシンであってよい。プロセッサは、コンピューティングデバイス同士の組み合わせ、たとえば、DSPとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサの組み合わせ、1つまたは複数のマイクロプロセッサとDSPコアの組み合わせ、あるいはそのような任意の他の構成として実施されてもよい。
【０１７３】
本明細書で開示された各実施形態に関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで直接具体化されても、プロセッサによって実行されるソフトウェアモジュールで具体化されても、ハードウェアとソフトウェアモジュールの組み合わせで具体化されてもよい。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、取り外し可能なディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体に常駐してよい。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、かつ記憶媒体に情報を書き込むことができるようにプロセッサに結合される。あるいは、記憶媒体はプロセッサと一体であってよい。プロセッサと記憶媒体はASICに常駐してよい。ASICはユーザ端末(たとえば、アクセス端末)に常駐してよい。あるいは、プロセッサと記憶媒体は、ユーザ端末内の離散構成要素として常駐してよい。
【０１７４】
1つまたは複数の実施形態では、上述の機能が、ハードウェア、ソフトウェア、またはファームウェアで実現されても、あるいはそれらの任意の組み合わせで実現されてもよい。各機能は、ソフトウェアで実現される場合、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして記憶または送信されてよい。コンピュータ可読媒体は、コンピュータ記憶媒体と、コンピュータプログラムのある場所から他の場所への転送を容易にする任意の媒体を含む通信媒体との両方を含む。記憶媒体は、コンピュータによってアクセスできる利用可能な任意の媒体であってよい。制限ではなく一例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、またはその他の光学ディスクストレージ、磁気ディスクストレージまたはその他の磁気記憶デバイス、あるいは所望のプログラムコードを命令またはデータ構造の形態で保持または記憶するのに使用でき、かつコンピュータによってアクセスできる任意の他の媒体を備えてよい。また、任意の接続が適宜、コンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、撚り線対、デジタル加入者線(DSL)、または赤外線、無線、マイクロ波など無線技術を使用してウェブサイト、サーバ、またはその他のリモート送信元から送信される場合、同軸ケーブル、光ファイバケーブル、撚り線対、DSL、または赤外線、無線、マイクロ波など無線技術が媒体の定義に含められる。ディスク(diskおよびdisc)は、本明細書では、コンパクトディスク(CD)、レーザディスク、光学ディスク、デジタルバーサティルディスク(DVD)、フレキシブルディスク、およびブルーレイディスクを含み、この場合、diskは通常、データを磁気的に再生するディスクであり、一方、discはデータをレーザによって光学的に再生するディスクである。上記の組み合わせもコンピュータ可読媒体の範囲内に含まれるべきである。
【０１７５】
上記の開示は本発明の例示的な実施形態を示しているが、本明細書では、添付の特許請求の範囲によって定義される本発明の範囲から逸脱せずに様々な変更および修正が施されてよいことに留意されたい。本明細書に記載された本発明の実施形態による方法クレームの機能、ステップおよび/または動作を特定の順序で実行する必要はない。さらに、本発明の要素は単数形で記載または請求される場合があるが、単数形の限定が明示的に述べられていない限り複数形も考慮される。
【符号の説明】
【０１７６】
100 無線システム
102 携帯電話
104 無線インターフェース
108 パーソナルデジタルアシスタント
110 ページャ
112 コンピュータプラットフォーム
120 無線アクセスネットワーク
122 基地局コントローラ/パケット制御機能
124 基地局またはモデムプールトランシーバ
126 キャリアネットワーク
160 パケットデータサービスノード
165 ブロードキャストサービングノード
170 アプリケーションサーバ
172 メディアコンテントコンプレックスモジュール
175 インターネット
200 アクセス端末
202 プラットフォーム
208 特定用途向け集積回路
210 アプリケーションプログラミングインターフェース
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
226 キーパッド
228 プッシュトゥトークボタン
【技術分野】
【０００１】
35U.S.C.§119に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により全体が明示的に本明細書に組み込まれる、2009年7月10日に出願した「Media Forwarding For a Group Communication Session In A Wireless Communications System」という名称の米国特許仮出願第61/224,797号の優先権を主張する。
【０００２】
本発明の各実施形態は、無線通信セッションにおけるグループ通信セッションのためのメディア転送に関する。
【背景技術】
【０００３】
第1世代アナログ無線電話サービス(1G)、第2世代(2G)デジタル無線電話サービス(暫定2.5Gネットワークおよび2.75Gネットワークを含む)、および第3世代(3G)高速データ/インターネット対応無線サービスを含め、様々な世代を通じて無線通信システムが開発されている。現在、セルラ通信サービスシステムおよびパーソナル通信サービス(PCS)システムを含む、多数の異なる種類の無線通信システムが使用されている。公知のセルラシステムの例には、セルラAnalog Advanced Mobile Phone System (AMPS)、ならびに符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、時間分割多元接続(TDMA)、TDMAのGlobal System for Mobile access(GSM（登録商標）)変形例、およびTDMA技術とCDMA技術の両方を使用する最新のハイブリッドデジタル通信システムに基づくデジタルセルラシステムが含まれる。
【０００４】
CDMA移動通信を実現する方法は、「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」と題し、本明細書ではIS-95として引用されるTIA/EIA/IS-95-Aにおいて電気通信工業協会/電子工業協会によって米国で標準化された。TIA/EIA規格IS-98には複合AMPS&CDMAシステムが記載されている。他の通信システムは、広帯域CDMA(WCDMA)、CDMA2000(たとえば、CDMA2000 1xEV-DO規格など)、またはTD-SCDMAと呼ばれるシステムを対象とする規格であるIMT-2000/UM、すなわちInternational Mobile Telecommunications System 2000/Universal Mobile Telecommunications Systemに記載されている。
【０００５】
無線通信システムでは、移動局、ハンドセット、またはアクセス端末(AT)が、基地局自体に隣接するかあるいは基地局自体の周囲に位置する特定の地理的領域内の通信リンクまたはサービスをサポートする固定位置の基地局(セルサイトまたはセルとも呼ばれる)から信号を受信する。基地局は、一般に、サービス品質(QoS)要件に基づいてトラフィックを区別する方法をサポートする標準的なInternet Engineering Task Force(IETF)方式のプロトコルを使用するパケットデータネットワークである、アクセスネットワーク(AN)/無線アクセスネットワーク(RAN)へのエントリポイントを実現する。したがって、基地局は一般に、無線インターフェースを通じて、かつインターネットプロトコル(IP)ネットワークデータパケットを介してANによってATと相互作用する。
【０００６】
無線通信システムでは、サービスセクタおよび消費者にプッシュトゥトーク(PTT)機能が普及しつつある。PTTは、CDMA、FDMA、TDMA、GSMなど標準的な市販の無線インフラストラクチャを介して動作する「ディスパッチ」音声サービスをサポートすることができる。ディスパッチモデルでは、エンドポイント(AT)同士の通信が仮想グループ内で行われ、1人の「話し手」の声が1人または複数の「聞き手」に送信される。この種の通信の単一のインスタンスは一般に、ディスパッチ呼または単にPTT呼と呼ばれる。PTT呼とは、グループのインスタンス化であり、呼の特性を定義する。グループは基本的に、メンバリストおよびグループ名またはグループIDなど関連情報によって定義される。
【０００７】
従来、無線通信ネットワーク内のデータパケットは、単一の宛先またはアクセス端末に送信されるように構成されている。単一の宛先へのデータの送信は「ユニキャスト」と呼ばれる。移動通信が増大するにつれて、所与のデータを複数のアクセス端末に同時に送信する能力がより重要になっている。したがって、複数の宛先またはターゲットアクセス端末への同じパケットまたはメッセージの同時データ送信をサポートするプロトコルが採用されている。「ブロードキャスト」は、(たとえば、所与のサービスプロバイダがサービスの対象とする所与のセル内での)すべての宛先またはアクセス端末へのデータパケットの送信を指し、「マルチキャスト」は、宛先またはアクセス端末の所与のグループへのデータパケットの送信を指す。一例として、宛先の所与のグループすなわち「マルチキャストグループ」は、(たとえば、所与のサービスプロバイダがサービスの対象とする所与のグループ内の)考えられる宛先またはアクセス端末のうちの複数でありかつ全数よりも少ない数の宛先またはアクセス端末を含んでよい。しかし、少なくとも、状況によっては、マルチキャストグループが、ユニキャストと同様に1つのアクセス端末のみを含むか、あるいはマルチキャストグループが、ブロードキャストと同様に(たとえば、セルまたはセクタ内の)すべてのアクセス端末を含むこともあり得る。
【０００８】
ブロードキャストおよび/またはマルチキャストは、無線通信システムにおいて、複数の順次ユニキャスト動作を実行してマルチキャストグループに対処したり、複数のデータ送信を同時に処理できるように固有のブロードキャスト/マルチキャストチャネル(BCH)を割り振ることのように、いくつかの方法で実施することができる。プッシュトゥトーク通信にブロードキャストチャネルを使用する従来のシステムが、2007年3月1日付けの、「Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network」という名称の米国特許出願公開第2007/0049314号に記載されており、その内容が全体として参照により本明細書に組み込まれる。米国特許出願公開第2007/0049314号に記載されているように、従来のシグナリング技術を使用するプッシュトゥトーク呼にブロードキャストチャネルを使用することができる。ブロードキャストチャネルを使用すると従来のユニキャスト技術と比べて帯域幅要件を改善することができるが、ブロードキャストチャネルの従来のシグナリングでは依然として追加的なオーバヘッドおよび/または遅延が発生することがあり、システム性能が低下する可能性がある。
【０００９】
3rd Generation Partnership Project 2(3GPP2)は、CDMA2000ネットワークにおけるマルチキャスト通信をサポートするブロードキャスト-マルチキャストサービス(BCMCS)仕様を定めている。したがって、「CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification」と題する、2006年2月14日付けの3GPP2のBCMCS仕様Version 1.0 C.S0054-Aを全体として参照により本明細書に組み込む。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許出願公開第2007/0049314号
【非特許文献】
【００１１】
【非特許文献１】Telecommunications Industry Association/Electronic Industries Association「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」
【非特許文献２】3rd Generation Partnership Project 2「CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification」
【発明の概要】
【課題を解決するための手段】
【００１２】
各実施形態は、無線通信システム内のグループ通信セッションのためのメディア転送に関する。サーバが、グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する。サーバは、受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する。サーバは、選択された少なくとも1つのフレームを、グループ通信セッションに参加している第2の複数のアクセス端末に送信する。
【００１３】
一例として、サーバは、宛先向けに選択されたフレームの数が1よりも大きい場合、任意にフレーム同士を混合する。フレーム同士の選択および/または混合は、複数のアクセス端末の各々について行われるが、場合によっては、選択または混合された同じフレームを複数のアクセス端末に送信することができ、それによって、サーバに対する処理負荷を低減させることができる。他の例では、1つまたは複数のフレームをそれに関連するデータレートに少なくとも部分的に基づいて選択することができ、次に、選択されたフレームを(たとえば、信号処理的に)混合することができる。各実施形態は、比較的小さなグループに関連する実施形態であっても、比較的少数の参加者が同時に話すことがある大きなグループに関する実施形態であってもよい。したがって、あるタイムスロットに関する、潜在的に多数の利用可能なフレームから比較的少数のフレームを選択することができ、次に、選択されたフレームを混合してグループに配信することができる。
【００１４】
本発明の実施形態およびそれに付随する利点の多くが、以下の詳細な説明を参照し、本発明の限定ではなく単に例示として提示された添付の図面と一緒に検討したときによりよく理解されるようになるため、本発明の実施形態およびそれに付随する利点の多くをより完全に理解することは容易である。
【図面の簡単な説明】
【００１５】
【図１】本発明の少なくとも1つの実施形態によるアクセス端末およびアクセスネットワークをサポートする無線ネットワークアーキテクチャの図である。
【図２】本発明の例示的な実施形態によるキャリアネットワークを示す図である。
【図３】本発明の少なくとも1つの実施形態によるアクセス端末の図である。
【図４Ａ】従来の半二重グループ通信セッションプロセスを示す図である。
【図４Ｂ】従来の全二重グループ通信セッションプロセスを示す図である。
【図５Ａ】本発明の一実施形態によるグループ通信セッションプロセスを示す図である。
【図５Ｂ】本発明の一実施形態による、各グループ通信セッション参加者が同じ優先順位レベルを有するフレーム選択の例を示す図である。
【図５Ｃ】本発明の一実施形態による、2人以上のグループ通信セッション参加者がそれぞれの異なる優先順位レベルを有するフレーム選択の例を示す図である。
【図５Ｄ】本発明の一実施形態による、複数のフレームが選択される図5Bのプロセスの変形例を示す図である。
【図５Ｅ】本発明の一実施形態による、複数のフレームが選択される図5Cのプロセスの変形例を示す図である。
【図６Ａ】本発明の一実施形態による、図5Bまたは図5Cの選択プロセスに従って実行された図5Aのグループ通信セッションプロセスを示す図である。
【図６Ｂ】本発明の一実施形態による、図5Dまたは図5Eの選択プロセスに従って実行された図5Aのグループ通信セッションプロセスを示す図である。
【図７】本発明の一実施形態による図6Aのプロセスに続くプロセスを示す図である。
【図８】本発明による複数のタイムスロットにわたる図6Aのプロセスを示す図である。
【図９】本発明の一実施形態による、入力メディアフローの選択されたフレームに関連する1つまたは複数のメディアフローパラメータを出力メディアフローにおいて修正することのできる高レベルプロセスを示す図である。
【図１０】図9のプロセスが送信元同期(SSRC)メディアフローパラメータに対して実行されない復号プロセスの一例を示す図である。
【図１１】図9のプロセスがSSRCメディアフローパラメータに対して実行される復号プロセスの一例を示す図である。
【図１２】図9のプロセスがシークエント番号メディアフローパラメータに対して実行されない復号プロセスの一例を示す図である。
【図１３】図9のプロセスがシーケンス番号メディアフローパラメータに対して実行される復号プロセスの一例を示す図である。
【発明を実施するための形態】
【００１６】
本発明の特定の実施形態に関する以下の説明および関連する図面に本発明の各態様が開示されている。本発明の範囲から逸脱せずに他の実施形態が考案されてよい。また、本発明の公知の要素については、本発明の関連する細部を曖昧にしないように詳しく説明しないかあるいは省略する。
【００１７】
「例示的な」および/または「例」という用語は、本明細書では、「一例または例示として働くこと」を意味するのに使用される。本明細書で「例示的な」および/または「例」として記載される実施形態が必ずしも他の実施形態と比べて好ましいかあるいは有利であるとみなされるわけではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、本明細書で述べられる特徴、利点、または動作モードを含むことを必要とするわけではない。
【００１８】
また、多くの実施形態は、たとえばコンピューティングデバイスの要素によって実行すべき動作のシーケンスに関して記載されている。本明細書に記載された様々な動作を特定の回路(たとえば、特定用途向け集積回路(ASIC))、1つまたは複数のプロセッサによって実行されるプログラム命令、またはその両方の組み合わせによって実行できることが理解されよう。また、本明細書に記載されたこれらの動作シーケンスは、実行されたときに関連するプロセッサに本明細書に記載された機能を実行させる対応する1組のコンピュータ命令が記憶された任意の形態のコンピュータ可読記憶媒体内で完全に具体化されるとみなすことができる。したがって、本発明の様々な態様は、すべてが請求される主題の範囲内と考えられているいくつかの異なる形態で具体化することができる。また、本明細書に記載された各実施形態について、あらゆるそのような実施形態の対応する形態が、本明細書において、たとえば、記載された動作を実行するように「構成された論理」として記載されることもある。
【００１９】
ハイデータレート(HDR)加入者局は、本明細書ではアクセス端末(AT)と呼ばれ、移動局であっても固定局であってもよく、本明細書ではモデムプールトランシーバ(MPT)または基地局(BS)と呼ばれる1つまたは複数のHDR基地局と通信することができる。アクセス端末は、1つまたは複数のモデムプールトランシーバを通じて、モデムプールコントローラ(MPC)、基地局コントローラ(BSC)、および/またはパケット制御機能(PCF)と呼ばれるHDR基地局コントローラとの間でデータパケットを送受信する。モデムプールトランシーバおよびモデムプールコントローラは、アクセスネットワークと呼ばれるネットワークの一部である。アクセスネットワークは、複数のアクセス端末でデータパケットを転送する。
【００２０】
アクセスネットワークはさらに、企業イントラネットまたはインターネットなどアクセスネットワークの外部の他のネットワークに接続されてよく、各アクセス端末とそのような外部ネットワークとの間でデータパケットを転送することができる。1つまたは複数のモデムプールトランシーバとのアクティブトラフィックチャネル接続を確立したアクセス端末は、アクティブアクセス端末と呼ばれ、かつトラフィック状態にあると言われる。1つまたは複数のモデムプールトランシーバとアクティブトラフィックチャネル接続を確立する過程であるアクセス端末は、接続セットアップ状態であると言われる。アクセス端末は、無線チャネルを通じて通信するか、あるいはたとえば光ファイバケーブルまたは同軸ケーブルを使用して有線チャネルを通じて通信する任意のデータデバイスであってよい。アクセス端末はさらに、PCカード、コンパクトフラッシュ（登録商標）、外部モデムまたは内部モデム、あるいは無線電話または有線電話を含むがそれらに限らないいくつかの種類のデバイスのうちのいずれかのデバイスであってよい。アクセス端末がモデムプールトランシーバに信号を送信するための通信リンクは、下りリンクまたはトラフィックチャネルと呼ばれる。モデムプールトランシーバがアクセス端末に信号を送信するための通信リンクは、上りリンクまたはトラフィックチャネルと呼ばれる。本明細書では、トラフィックチャネルという用語は、上りトラフィックチャネルまたは下りトラフィックチャネルのいずれかを指すことがある。
【００２１】
図1は、本発明の少なくとも1つの実施形態による無線システム100の例示的な一実施形態のブロック図である。システム100は、パケット交換データネットワーク(たとえば、イントラネット、インターネット、および/またはキャリアネットワーク126)とアクセス端末102、108、110、112との間のデータ接続性を実現するネットワーク機器にアクセス端末102を接続することのできるアクセスネットワークまたは無線アクセスネットワーク(RAN)120と無線インターフェース104を介して通信する携帯電話102などのアクセス端末を含んでよい。図示のように、アクセス端末は、携帯電話102、パーソナルデジタルアシスタント108、図1には2方向テキストページャとして示されているページャ110、場合によっては無線通信ポータルを有する別個のコンピュータプラットフォーム112であってよい。したがって、本発明の各実施形態は、無線モデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組み合わせもしくは部分組み合わせを制限なしに含む、無線通信ポータルを含むかあるいは無線通信機能を有する任意の形態のアクセス端末で実現することができる。また、本明細書では、「アクセス端末」、「無線デバイス」、「クライアントデバイス」、「移動端末」という用語、およびそれらの変形例は交換可能に使用されてよい。
【００２２】
再び図1を参照すると、無線ネットワーク100の構成要素および本発明の例示的な実施形態の要素の相互関係は、図示の構成に限定されない。システム100は、例示的なシステムに過ぎず、無線クライアントコンピューティングデバイス102、108、110、112などのリモートアクセス端末が、無線による互いの通信と、無線インターフェース104ならびにキャリアネットワーク126、インターネット、および/またはその他のリモートサーバを含むがそれらに限らないRAN120を介して接続された構成要素との間の通信を行うのを可能にする任意のシステムを含んでよい。
【００２３】
RAN120は、基地局コントローラ/パケット制御機能(BSC/PCF)122に送信されるメッセージ(通常データパケットとして送信される)を制御する。BSC/PCF122は、パケットデータサービスノード160(PDSN)とアクセス端末102/108/110/112との間のベアラチャネル(すなわち、データチャネル)のシグナリング、確立、および切り離しに責任を負う。リンク層暗号化が有効化される場合、BSC/PCF122はまた、コンテントを無線インターフェース104を介して転送する前に暗号化する。BSC/PCF122の機能は当技術分野で公知であり、説明を簡潔にするためにこの機能についてはこれ以上は論じない。キャリアネットワーク126は、ネットワーク、インターネット、および/または公衆交換電話網(PSTN)によってBSC/PCF122と通信することができる。あるいは、BSC/PCF122を直接インターネットまたは外部ネットワークに接続することができる。通常、キャリアネットワーク126とBSC/PCF122との間のネットワーク接続またはインターネット接続はデータを転送し、PSTNは音声情報を転送する。BSC/PCF122は、複数の基地局(BS)またはモデムプールトランシーバ(MPT)124に接続することができる。キャリアネットワークと同様に、BSC/PCF122は通常、データ転送および/または音声情報のためにネットワーク、インターネット、および/またはPSTNによってMPT/BS124に接続される。MPT/BS124は、携帯電話102などのアクセス端末に無線によってデータメッセージをブロードキャストすることができる。MPT/BS124、BSC/PCF122、およびその他の構成要素は、当技術分野で公知のようにRAN120を形成することができる。しかし、他の構成も使用されてよく、本発明は図示の構成に限定されない。たとえば、他の実施形態では、BSC/PCF122および1つまたは複数のMPT/BS124の機能が、BSC/PCF122とMPT/BS124の両方の機能を有する単一の「ハイブリッド」モジュールに組み込まれてよい。
【００２４】
図2は、本発明の一実施形態によるキャリアネットワーク126を示している。図2の実施形態では、キャリアネットワーク126は、パケットデータサービングノード(PDSN)160と、ブロードキャストサービングノード(BSN)165と、アプリケーションサーバ170と、インターネット175とを含む。しかし、他の実施形態では、アプリケーションサーバ170およびその他の構成要素はキャリアネットワークの外部に配置されてよい。アプリケーションサーバ170は、機能について以下に詳しく説明するmedia content complex(MCC)モジュール172を含む。PDSN160は、たとえば、cdma2000無線アクセスネットワーク(RAN)(たとえば、図1のRAN120)を利用する移動局(たとえば、図1の102、108、110、112などのアクセス端末)に対して、インターネット175、イントラネット、および/またはリモートサーバ(たとえば、アプリケーションサーバ170)にアクセスするのを可能にする。PDSN160は、アクセスゲートウェイとして働き、単純なIPアクセスおよび移動IPアクセス、フォーリンエージェントのサポート、およびパケット転送を実行することができる。PDSN160は、当技術分野で公知のように、Authentication, Authorization, and Accounting(AAA)サーバおよびその他のサポートインフラストラクチャ用のクライアントとして働くことができ、移動局に対してIPネットワークへのゲートウェイを実現する。図2に示されているように、PDSN160は、従来のA10接続を介してRAN120(たとえば、BSC/PCF122)と通信することができる。A10接続は当技術分野で公知であり、説明を簡潔にするためにA10接続についてはこれ以上説明しない。
【００２５】
図2を参照すると、ブロードキャストサービングノード(BSN)165は、マルチキャストサービスおよびブロードキャストサービスをサポートするように構成されてよい。BSN165については以下に詳しく説明する。BSN165は、ブロードキャスト(BC)A10接続を介してRAN120(たとえば、BSC/PCF122)と通信し、インターネット175を介してアプリケーションサーバ170と通信する。BCA10接続は、マルチキャストメッセージおよび/またはブロードキャストメッセージを転送するのに使用される。したがって、アプリケーションサーバ170は、インターネット175を介してPDSN160にユニキャストメッセージを送信し、インターネット175を介してBSN165にマルチキャストメッセージを送信する。
【００２６】
一般に、以下に詳しく説明するように、RAN120は、BCA10接続を介してBSN165から受信されたマルチキャストメッセージを無線インターフェース104のブロードキャストチャネル(BCH)上で1つまたは複数のアクセス端末200に送信する。
【００２７】
図3を参照すると、携帯電話などのアクセス端末200(ここでは無線デバイス)は、RAN120から送信され、最終的にキャリアネットワーク126、インターネット、ならびに/あるいはその他のリモートサーバおよびリモートネットワークから得られるソフトウェアアプリケーション、データ、および/またはコマンドを受信して実行することができるプラットフォーム202を有する。プラットフォーム202は、特定用途向け集積回路(「ASIC」)208、またはその他のプロセッサ、マイクロプロセッサ、論理回路、もしくはその他のデータ処理デバイスに動作可能に結合されたトランシーバ206を含んでよい。ASIC208またはその他のプロセッサは、無線デバイスのメモリ212内の任意の常駐プログラムと相互作用するアプリケーションプログラミングインターフェース(「API」)210層を実行する。メモリ212は、読み取り専用メモリまたはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、あるいは各コンピュータプラットフォームに共通する任意のメモリで構成されてよい。プラットフォーム202は、メモリ212内で能動的には使用されないアプリケーションを保持することのできるローカルデータベース214も含んでよい。ローカルデータベース214は通常、フラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトディスクまたはハードディスクなど当技術分野で公知の任意の二次的記憶デバイスであってよい。内部プラットフォーム202の各構成要素は、当技術分野で公知のように、特に、アンテナ222、ディスプレイ224、プッシュトゥトークボタン228、キーパッド226などの外部デバイスに動作可能に結合されてよい。
【００２８】
したがって、本発明の一実施形態は、本明細書で説明する機能を実行する機能を含むアクセス端末を含んでよい。当業者によって理解されるように、様々な論理要素は、本明細書に開示される機能を実現するように離散要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアの任意の組み合わせで具体化することができる。たとえば、ASIC208、メモリ212、API210、およびローカルデータベース214はすべて、本明細書に開示された様々な機能をロードし、記憶し、実行するように協働させてよく、したがって、これらの機能を実行する論理は様々な要素間で分散されてよい。あるいは、機能を1つの離散構成要素に組み込んでもよい。したがって、図3のアクセス端末の特徴は単に例示的なものとみなすべきであり、本発明は例示された特徴または構成に限定されない。
【００２９】
アクセス端末102とRAN120との無線通信は、符号分割多元接続(CDMA)、WCDMA、時間分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多重化(OFDM)、Global System for Mobile Communications (GSM)、または無線通信ネットワークもしくはデータ通信ネットワークで使用されてよいその他のプロトコルなど様々な技術に基づいて行うことができる。データベース通信は通常、クライアントデバイス102とMPT/BS124とBSC/PCF122との間で行われる。BSC/PCF122は、キャリアネットワーク126、PSTN、インターネット、仮想プライベートネットワークなど複数のデータネットワークに接続することができ、したがって、アクセス端末102がより広い通信ネットワークにアクセスするのを可能になる。上記で論じられかつ当技術分野で公知のように、様々なネットワークおよび構成を使用して音声送信および/またはデータをRANからアクセス端末に送信することができる。したがって、本明細書における例示は、本発明の各実施形態を限定するものではなく、本発明の各実施形態の態様の説明を助けるものであるに過ぎない。
【００３０】
図4Aは、従来の半二重グループ通信セッション(たとえば、呼、転送セッションなど)プロセスを示している。図4Aのグループ通信セッションは、IPマルチキャスティングプロトコルまたはIPユニキャスティングプロトコルによってサポートされるグループ通信セッションに相当するセッションであってよい。IPマルチキャスティングでは、ダウンリンクブロードキャストチャネル(BCH)が、1つまたは複数のセクタ内で単一のマルチキャストフローを各「聞き手側」マルチキャストグループメンバに伝送し、一方、マルチキャストグループメンバがダウンリンクBCHに同調するにはどうすればよいかを示す別個のスケジューリングメッセージ(たとえば、ブロードキャストオーバヘッドメッセージ(BOM))がダウンリンク制御チャネル上で送信される。IPユニキャスティングでは、各グループメッセージが、各グループメンバに個別にアドレス指定された別個のユニキャストメッセージとして各グループ通信セッション参加者またはマルチキャストグループメンバに送信される。
【００３１】
図4Aを参照すると、400で、所与のAT(ATA)が、グループ通信セッションを開始する要求をRAN120を介してアプリケーションサーバ170に送信する。たとえば、このグループ通信セッションは、プッシュトゥトーク(PTT)セッションまたはプッシュトゥトランスファー(PTX)セッションに相当するセッションであってよく、400における要求の送信は、ATAのユーザがATA上でPTTボタンまたはPTXボタンを押すことに基づいて指示されてよい。アプリケーションサーバ170は、ATAからグループ通信セッション要求を受信し、無線通信システム100の1つまたは複数のセクタでアナウンスメッセージを送信する(405)。少なくともATB...ATEがアナウンスメッセージを受信し、告知されたグループ通信セッションに参加することを決定する。したがって、ATB...ATEは、アプリケーションサーバ170に呼受け入れメッセージを送信し、またRAN120に登録メッセージ(たとえば、BCMCSFlowRegistrationメッセージ)を送信してグループ通信セッションに登録する(410および415)。ATB...ATEの各々からの呼受け入れメッセージおよび登録メッセージは、下りリンクアクセスチャネル上の別個のメッセージ内で送信されるか、あるいは同じメッセージ内にバンドルされてよい。
【００３２】
アプリケーションサーバ170は、ATB...ATEからのアナウンスメッセージに対する第1の応答者からの呼受け入れメッセージを受信した後、グループ通信セッションに関するフロアをATAに許可する(420)。したがって、ATAは、フロア許可メッセージを受信した後、ATAのユーザに話し始めてよいことを示す音を鳴らし、ATAは、下りリンクチャネル上でアプリケーションサーバ170へのフレームの送信を開始する(425)。425における一連のフレーム送信は、音声データを実際に含むデータフレームに相当するフレーム送信であってよく、あるいは音声データを実際に含まない無音フレームに相当するフレーム送信であってよい。
【００３３】
各フレーム送信は、リアルタイム転送プログラム(RTP)パケットまたはデータグラムあるいはRTCP(RTP制御プロトコル)パケットに相当するフレーム送信であってよい。40オクタットオーバヘッドRTPパケットのヘッダ部は以下のように構成されてよい。
【００３４】
【表１】
【００３５】
Table 1(表1)を参照すると、RTPパケットヘッダ部の各フィールドは当技術分野で公知である。しかし、あるフィールドについては、以下に詳しく説明する実施形態に関して詳しく論じることとし、したがって、本節ではこれらのフィールドを簡単に参照する。次に、たとえば、寄与カウント(CC)フィールド、シーケンス番号フィールド、タイムスタンプフィールド、およびSSRC番号フィールドについて簡単に述べる。CCフィールドは、寄与送信元(CSRC)カウント値を保持することのできる任意のフィールドである。Table 1(表1)(上記)の見出し部分には示されていないが、CCフィールドの12オクテットヘッダは、より多くの寄与送信元を含むように任意に拡張することができる。寄与送信元は、アプリケーションサーバ170におけるミキサによって付加することができ、データペイロードの各要素が異なるコンピュータから得られる会議アプリケーションに適している。ポイントツーポイント通信では、CSRCは必ずしも必要とされない。シーケンス番号フィールドは、特定の送信元またはATからRTPパケットが送信されるたびに1だけ増分する固有の参照番号を保持する。シーケンス番号フィールドは、受信側が送信側のパケットシーケンスを再構成するのを可能にする。タイムスタンプフィールドは、RTPパケットがATによって送信された時間に対応する。タイムスタンプフィールドは、受信側ATがデータをバッファリングし連続ストリームとして再生するのを可能にする。SSRC番号フィールドは、RTPパケットの送信元を識別し、425でATAを識別する数に対応する。SSRC番号は、グループ通信セッションの開始時にアプリケーションサーバ170によってプロビジョニングすることができる。
【００３６】
RTPパケットは、RTPヘッダ部の後に、データペイロード部を含む。データペイロード部は、音声および/またはビデオのデジタル化サンプルを含んでよい。データペイロードの長さは、RTPパケットに応じて異なってよい。たとえば、音声RTPパケットでは、データペイロードによって保持される音声サンプルの長さは20ミリ秒(ms)の音声に相当する長さであってよい。一般に、メディア持続時間がこれよりも長い場合(たとえば、よりレートの高いフレームの場合)、データペイロードも長くする必要があり、あるいはメディアサンプルの品質が低下する。
【００３７】
図4Aの425に戻ると、ATAから送信されるフレームは、RTPパケット内に大きなデータペイロードを有するフルレートフレーム(たとえば、8.6kbps)、RTPパケット内に「中」データペイロードを含むハーフレートフレーム(たとえば、4.3kbps)、RTPパケット内に小さなデータペイロードを含む1/8レートフレーム(たとえば、1.0kbps)などに相当するフレームであってよい。概してEVRC-Aが参照されるが、異なるフレームレート選択肢を含む他のボコーダに対処するにはこれらの実施形態をどのように修正すればよいかが容易に明らかになろう。理解されるように、ATAは、ATAのユーザの発話時には、ATAのユーザが発話しておらず、ATAが無音フレームを送信しているときよりも高いレートのフレームを送信する。アプリケーションサーバ170は、フロアホルダからのメディアストリームの受信、およびグループ通信セッションの1人または複数の「聞き手側」グループメンバへの出力ストリームの変換に対処するmedia control complex(MCC)172モジュールを含む。言い換えれば、MCCモジュール172は、RTPパケット内のフレームを複製してATAからATB...ATEの各々に再ブロードキャストする。したがって、アプリケーションサーバ170のMCCモジュール172で受信されたATAからの一連のフレーム送信は以下のように表されてよい。
【００３８】
【表２】
【００３９】
時間間隔10t...Tはそれぞれ、ATAからの所与のデータレートを有する1つのフレーム(たとえば、RTPパケット)を含む。■1/2フレームが(たとえば、音声データを含む)データフレームに相当し、一方、□1/8が無音フレームに相当すると仮定されてよい。しかし、少なくとも、■1/2フレームが、無音フレームと同様に、限られた量の雑音を含むことがあり得ることを理解されたい。また、図4Aは半二重グループ通信セッションであるため、ATAが(たとえば、1つまたは複数のRTPパケットで)フレームを送信しており、一方、ATB...ATEがパケットを送信していないことをTable 2(表2)(上記)が示していることに留意されたい。Table 2(表2)に示されているフレーム(たとえば、RTPパケット)は、アプリケーションサーバ170で受信されるパケットまたはフレームの入力ストリームに相当する。
【００４０】
上記に指摘したように、MCCモジュール172は、上記でTable 2(表2)に示されているように入力ストリームを受信し、ATA...ATEに送信される出力ストリームを生成または変換する。したがって、Table 2(表2)に基づいて、アプリケーションサーバ170のMCCモジュール172によって生成される出力ストリームは以下のように構成されてよい。
【００４１】
【表３】
【００４２】
Table 3(表3)(上記)に示されているように、出力ストリームは、ATAのフレーム送信がATAに送り返されるのではなく、上記のTable 2(表2)においてATB...ATEに送信されるように構成される。
【００４３】
出力ストリームはMCCモジュール172によって生成されるため、アプリケーションサーバ170は、出力ストリームの出力フレームを含むRTPパケットを一連のグループメッセージとしてATB...ATEに送信し(430)、ATB...ATEはグループ通信セッションに関するグループメッセージを監視する(435および440)。グループ通信セッションは次いで、ATAのユーザがフロアを放棄することに決定するまである期間にわたって継続する。445は、フロアを放棄することを求めるATAからの明示的な命令に対応するか、あるいはATAからのイナクティビティ期間(すなわち、無音フレームが多過ぎること)に基づくものであってよい。
【００４４】
アプリケーションサーバ170は、ATAがグループ通信セッションのフロアを放棄したと判定した後、ATB...ATEにフロア解放メッセージを送信する(450)。ATBのユーザおよびATC...ATEのうちの少なくとも1つのユーザが、フロアの制御権の獲得を試みることに決定し、アプリケーションサーバ170にフロア要求メッセージを送信する(455および460)と仮定する。それによって、アプリケーションサーバ170は複数のフロア要求メッセージを受信し、フロアを要求しているATの優先順位レベルを評価して、次にフロアを許可されるATを判定する。たとえば、RAN120は、グループ通信セッションの種類に基づいて、RAN120に維持されている1つまたは複数の優先順位テーブルを評価することができ、かつフロアを要求しているATの中から最高優先順位のATにフロアに許可することができる。たとえば、優先順位テーブルは以下のように構成されてよい。
【００４５】
【表４】
【００４６】
465で、アプリケーションサーバ170は、このグループ通信セッションのコールタイプに関しては、要求しているATの中でATBが最高優先順位レベルを有していると判定し、ATBにフロア許可メッセージを送信すると仮定する。次に、ATBが、音を鳴らして、現在ATBがフロアを有していることをATBのユーザに通知し、アプリケーションサーバ170への1つまたは複数のRTPパケットでのフレーム(たとえば、データフレーム、無音フレームなど)の送信を開始し(470)、次に、フレームが、MCCモジュール172によって出力ストリームに変換され、ATAおよびATC...ATEに再送される(475)。470および475が、上記にATAに関して説明したように425および430と同様に実行されることが理解されよう。したがって、説明を簡潔にするために470および475についてはこれ以上説明しない。
【００４７】
半二重セッションの特徴として、(たとえば、RTPパケットでの)フレームを送信するのは図4Aのグループ通信セッションにおける特定のATだけであり、一方、(たとえば、RTPパケットで)フレームを受信するのはグループ通信セッションにおける他のATだけである。図4Aのプロセスに代わるプロセスとして、以下に図4Bに関して説明する全二重グループ通信セッションがある。全二重セッションでは、セッションの各参加者が(たとえば、RTPパケットでの)フレームの送信と受信の両方を行うことができる。
【００４８】
図4Bは、従来の全二重グループ通信セッション(たとえば、呼、データ転送セッションなど)プロセスを示している。図4Aと同様に、図4Bのグループ通信セッションは、IPマルチキャスティングプロトコルまたはIPユニキャスティングプロトコルによってサポートされるグループ通信セッションに相当するセッションであってよい。図4Bを参照すると、400B〜415Bは、図4Aの400〜415に対応している。したがって、説明を簡潔にするために400B〜415Bについてはこれ以上論じない。
【００４９】
420Bで、アプリケーションサーバ170は、セッションイニシエータ(すなわち、ATA)にフロアを許可する代わりに、このグループ通信セッションに参加した各ATに、セッションを開始できることを示すメッセージを送信する(420B)。ATA...ATEはいずれも、メッセージを受信した(420B)ときに、発話を開始し、それによってデータフレームを送信するか、あるいは沈黙を続けて無音フレームを送信することができる(425B、430B、435B)。
【００５０】
アプリケーションサーバ170のMCCモジュール172で受信されるATA...ATEからの入力ストリームの一例(たとえば、特定のタイムスロットについてのATA...ATEからのRTPパケット内に含まれるフレーム)は以下のように表されてよい。
【００５１】
【表５】
【００５２】
Table 5(表5)(上記)を参照すると、ATA...ATEの各々は、タイムスロット10t...T上で所与のデータレートでフレームを送信する。特に、ATAは、一連のハーフレートフレームを送信しており(このことは、たとえば、ATAのユーザがATB...ATEに対して発話しており、音声データを送信している可能性が高いことを示す)、一方、ATB...ATEは、一連の1/8レートフレームを送信している(このことは、たとえば、ATB...ATEのユーザがATAの発話を聞いている可能性が高い、電話から離れている、などを示している)
【００５３】
図4Bを参照すると、440Bで、アプリケーションサーバ170のMCCモジュール172は、各時間間隔tに入力ストリームから得られる各フレームを含み、集結されたメディアストリームのジッタを除去し、次いで、その時間間隔についてのATA...ATEの各々からのすべてのメディアコンテントを含む出力ストリームを生成する。アプリケーションサーバ170は次に、結果として得られたメディアストリームを1つまたは複数のRTPパケット内の集結された一連のフレームとしてATA...ATEの各々に送信する。しかし、フィードバック問題を回避するために、ATA...ATEの各々が、そのAT自体を除くすべてのセッション参加者からのフレームを含む集結されたメディアストリームを受信することを理解されたい。したがって、ATAは、ATB...ATEからの集結されたメディアで構成された出力ストリームを受信し、ATBは、ATAおよびATC...ATEからの集結されたメディアで構成された出力ストリームを受信し、他のATについても同様である。
【００５４】
上記に指摘したように、MCCモジュール172は、上記にTable 5(表5)(上記)に示されているようにATA...ATEからフレームを受信し(すなわち、入力ストリーム)、次にATA...ATEに送信される出力ストリームを生成または変換する(たとえば、各出力ストリームは、フィードバックを低減させるために、ターゲットから受信された入力ストリームのフレームを省略するため、それぞれ異なる)。したがって、Table 5(表5)(上記)に基づいて、タイムスロット10t...T上でアプリケーションサーバ170のMCCモジュール172によって生成される出力ストリームは以下のように構成されてよい。
【００５５】
【表６】
【００５６】
Table 6(表6)(上記)に示されているように、グループ通信セッションが簡略的なブルートフォース転送実装形態であるため、出力ストリームの各タイムスロットにおけるATA...ATEへの集結されたメディアフレームは、そのAT自体以外のATからのフレーム(または、たとえばRTPパケット)のデータレートの和に等しい総データレートを有する。
【００５７】
図4Aのグループ通信セッションに関する従来の半二重実装形態に関しては、帯域幅使用率が図4Aのグループ通信セッションに関する全二重実装形態と比べて優れていることが理解されよう。しかし、ATがグループへの送信を行うことができないことが問題になることもある(たとえば、現在のフロアホルダがフロアを放棄せず、関連のない話題に関して話している場合)。半二重では、現在のフロアホルダは、フロアが解放されるまで他のグループメンバからフィードバックを受信することができないためグループの感情に気付かない。
【００５８】
この問題は、図4Bの全二重実装形態では生じない。しかし、グループ通信セッション参加者がN人である場合、各参加者が、組み合わされたN-1個のメディアフローを有する集結された出力ストリームを受信し、それによって、比較的大量の帯域幅が消費されるため、全二重実装形態の帯域幅要件は高い。また、多数のメディアフレームを集結して出力ストリームのメディアフレームを形成することは、アプリケーションサーバ170における集中的な処理になることがある。また、アプリケーションサーバ170のMCCモジュール172は、メディアフロー同士を区別しない。したがって、各フレームが出力ストリーム内の同じタイムスロットを求めて競合するとき、無音フレームには出力フレーム中のデータフレームと同じ優先順位が与えられる。
【００５９】
したがって、次に、半二重実装形態と全二重実装形態の両方のある特性を含むハイブリッド実装形態に関する実施形態について詳しく説明する。以下に詳しく説明するように、グループ通信セッションの複数の参加者(たとえば、すべての参加者)は、全二重の場合と同様に(たとえば、RTPパケットでの)フレームの送信と受信の両方を行うことができる。しかし、MCCモジュール172は、(選択された参加者以外の)特定のグループ通信セッション参加者への出力ストリーム内の任意の所与の出力フレームが、選択された参加者のみからのメディアコンテントを含むように、各グループ通信セッション参加者への出力として、着信したメディアストリームの1つまたは複数を選択するように構成されている。1つのメディアストリームが選択された場合、出力ストリームは、半二重と同様である(それによって、たとえば、帯域幅使用効率が高くなる)。入力メディアストリームのうちの複数でありかつ全数よりも少ない数のメディアストリームが選択された場合、出力メディアストリームは、フレームが選択された、選択された一部のATについては全二重と同様であり、一方、全二重とは異なり、すべてのフレームが出力ストリームに含まれるわけではないので帯域幅使用率が高くなる(ただし、たとえば、少なくとも一実施形態では、少なくとも、すべてのフレームが選択されることがあり得る)。MCCモジュール172がグループ通信セッション参加者の出力ストリームをどのように生成するかに関する選択機構については以下に詳しく説明する。
【００６０】
以下に、本発明の各実施形態をフルレートフレーム、ハーフレートフレーム、および1/8レートフレームに関して説明する。上記のフレームレートを含む1組のフレームレートがEVRC-Aボコーダに特有のフレームレートである。EVRC-Bおよび/または4Gなど他のボコーダは、フレームレートセットの一部として1/4レートフレームを含んでよい。以下でEVRC-Aを概略的に参照すると、様々なフレームレート選択肢を含む他のボコーダに対処するにはこれらの実施形態をどのように修正すればよいかが容易に明らかになろう。
【００６１】
また、以下に説明する本発明の各実施形態では、特定の節においてRTPパケットとフレーム(たとえば、無音フレーム、データフレームなど)を交換可能に参照する。しかし、RTPパケットが実際には複数のフレームを含んでよいことを理解されたい。それによって、RTPパケットが1つのフレームを含むと仮定したRTPパケットの特定の参照を、本発明の他の実施形態では、本明細書で開示されるプロセスがフレーム固有のプロセスであり、必ずしもRTPパケット固有のプロセスではないように修正できることが理解されよう。言い換えれば、フレーム選択が第1のタイムスロットについて行われ、次いで第2のタイムスロットについて行われる場合、第1および第2のタイムスロットにおける選択に利用できるフレームのうちの1つまたは複数が実際には同じRTPパケットで受信されたフレームであることがあり、この場合、選択はフレーム固有の選択であり、パケット固有の選択ではない。概して、本発明の各実施形態はフレームの混合および選択に関する実施形態であり、RTPパケットは、1つ(または複数)のフレームを保持する例示的な機構に過ぎない。
【００６２】
したがって、図5Aは、本発明の一実施形態によるグループ通信セッション(たとえば、呼、転送セッションなど)プロセスを示している。特に、図5Aは、比較的高いレベルでのグループ通信セッションプロセスを示しており、その後に、図5Aに示されている高レベルプロセスの一部のより詳細な例が示されている。図5Aのグループ通信セッションは、IPマルチキャスティングプロトコルまたはIPユニキャスティングプロトコルによってサポートされるグループ通信セッションに相当するセッションであってよい。IPマルチキャスティングでは、ダウンリンクブロードキャストチャネル(BCH)が、1つまたは複数のセクタ内で単一のマルチキャストフローを各「聞き手側」マルチキャストグループメンバに伝送し、一方、マルチキャストグループメンバがダウンリンクBCHに同調するにはどうすればよいかを示す別個のスケジューリングメッセージ(たとえば、ブロードキャストオーバヘッドメッセージ(BOM))がダウンリンク制御チャネル上で送信される。IPユニキャスティングでは、各グループメッセージが、各グループメンバに個別にアドレス指定された別個のユニキャストメッセージとして各グループ通信セッション参加者またはマルチキャストグループメンバに送信される。
【００６３】
図5Aを参照すると、500で、所与のAT(ATA)が、グループ通信セッションを開始する要求をRAN120を介してアプリケーションサーバ170に送信する。たとえば、このグループ通信セッションは、プッシュトゥトーク(PTT)セッションまたはプッシュトゥトランスファー(PTX)セッションに相当するセッションであってよく、500における要求の送信は、ATAのユーザがATA上でPTTボタンまたはPTXボタンを押すことに基づいて指示されてよい。アプリケーションサーバ170は、ATAからグループ通信セッション要求を受信し、無線通信システム100の1つまたは複数のセクタでアナウンスメッセージを送信する(505)。少なくともATB...ATEがアナウンスメッセージを受信し、告知されたグループ通信セッションに参加することを決定する。したがって、ATB...ATEは、アプリケーションサーバ170に呼受け入れメッセージを送信し、またRAN120に登録メッセージ(たとえば、BCMCSFlowRegistrationメッセージ)を送信してグループ通信セッションに登録する(510および515)。ATB...ATEの各々からの呼受け入れメッセージおよび登録メッセージは、下りリンクアクセスチャネル上の別個のメッセージ内で送信されるか、あるいは同じメッセージ内にバンドルされてよい。
【００６４】
図5Aを参照すると、520で、アプリケーションサーバ170は、ATB...ATEから呼受け入れメッセージを受信した後、ATAおよびATB...ATEの少なくとも1つにフロア許可メッセージを送信する。一例として、アプリケーションサーバ170は、このグループ通信セッションに参加する各ATにフロア許可メッセージを送信するように構成されてよい。他の例では、アプリケーションサーバ170は、このグループ通信セッションに参加するATのうちの全数よりも少ないが複数のATにフロア許可メッセージを送信するように構成されてよい。したがって、特定のATが(全二重と同様に)送信と受信の両方を行うように構成され、一方、他のATが(半二重と同様に)受信または送信のみを行うように構成されてよい。また、ATAおよびATB...ATEの少なくとも1つがアプリケーションサーバ170にグループメッセージを送信することができるとともにアプリケーションサーバ170からグループメッセージを受信することもできる限り、520でフロア許可メッセージが送信される代わりに、任意の種類のメッセージが送信されてよい。
【００６５】
したがって、ATA...ATEの各々において、グループ通信セッションが開始されたことをそれぞれのATのユーザに示す音が鳴らされ、ATA...ATEは、下りリンクチャネル上における所与のデータレートでのアプリケーションサーバ170へのフレーム(たとえば、1つまたは複数のRTPパケット内に含まれるデータフレーム、無音フレーム)の送信を開始する。(525、530、535)
【００６６】
アプリケーションサーバ170は、所与の時間間隔またはタイムスロットにわたってATA...ATEからフレームを受信し、ATA...ATEのうちの1つまたは複数のATからのフレームを出力ストリーム上でATA...ATEのうちの他の各ATに送信されるフレームとして選択する(540)。540の選択は、アプリケーションサーバ170のMCCモジュール172によって実行され、MCCモジュール172での所与のタイムスロットについての、ATA...ATEからの入力ストリーム内のフレームのデータレートに少なくとも部分的に基づいて実行される。540の選択については以下に詳しく説明する。アプリケーションサーバ170は、540で選択を行った後、540で選択されたフレームの送信元であるATを除く各ATに、選択されたフレームを送信する。図5Aには明示的に示されていないが、アプリケーションサーバ170は、以下に詳しく説明するように、選択されないATからのフレームを選択されたフレームに関連するATに送信してもよい。
【００６７】
540の選択はいくつかの方法で実行され、次に、これらの方法の例について、図5B〜5Dに関して説明する。たとえば、ATA...ATEは、直接呼、アドホック呼、クローズドグループ呼、およびクローズドチャットルーム呼に関してTable 4(表4)(上記)によって定義されている優先順位レベルを有する。この仮定の下では、図5Aで確立されたグループ通信セッションが直接呼またはアドホック呼である場合、ATA...ATEの優先順位は同じであり(ただし、たとえば、このことはすべての直接呼またはアドホック呼に当てはまるわけではない)、一方、クローズドグループ呼またはクローズドチャットルーム呼の場合、ATA...ATEの優先順位レベルは必ずしも同じではないことが理解されよう。
【００６８】
したがって、図5Bは、本発明の一実施形態によって、各グループ通信セッション参加者が同じ優先順位レベルを有する、アプリケーションサーバ170で実行される540のフレーム選択の一例を示している。図5Bを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(たとえば、1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500B)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って選択を行う。たとえば、所与の選択規則は、第1の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1のAT)からの無音フレームが選択されるように訂正することができる。505Bの選択が、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが無音フレームを伝送するため、多数の異なる選択プロセスとして構成されてよい(たとえば、第2の聞き手の無音フレームが選択されたり、発信側の無音フレームが選択されたりしてよい)ことが理解されよう。
【００６９】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510B)。510Bで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515B)。このようなデータレートフレームが1つだけではなく、510Bで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、複数の高データレートフレームのうちのどのフレームが最高のデータレートを有するかを判定する(520B)。MCCモジュール172は次に、高データレートフレームの中に1つだけ他の高データレートフレーム(たとえば、ハーフレートフレーム)よりも高いデータレート(たとえば、フルレートフレーム)を有するフレームが存在するかどうかを判定する(525B)。他の実施形態では、MCCモジュール172は、複数の高データレートフレームを選択し、これらの高データレートフレームを(デジタル処理的に)混合し、後で、送信されるフレームとして選択できる単一の混合フレームを生成する。混合すべきフレームをこのように選択することは、MCCモジュール172で利用可能な処理パワーに基づいて行うことができ(たとえば、利用可能な処理パワーが低い場合には選択されるフレームを少なくし、利用可能な処理パワーが高い場合には選択されるフレームを多くすることができる)、かつ/あるいは単一の混合フレームを使用してサービスを提供することができるターゲットATの数に基づいて行うことができる(たとえば、同じ混合フレームを受信するターゲットATの数が多い場合、「多数の」ATに使用されるこの種の混合フレームの混合に割り振られる処理パワーが多くなるようにAT当たり処理消費量が比較的少なくなり、一方、混合フレームを受信するATの数が比較的少ない場合、混合されるフレームとして選択されるフレームを少なくすることができる)。1つだけ、他のすべてのフレームよりも高いデータレートを有するフレームが存在する場合、515Bで最高のデータレートを有するこ
のフレームが選択される。最高のデータレートを有するフレームが1つだけではない場合、MCCモジュール172は、他の所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、最高のデータレートを有するフレーム(たとえば、複数のフルレートフレーム、複数のハーフレートフレームなど)からの選択を行う。たとえば、この所与の選択規則は、RTPパケットが最小SSRC値を有するフレームの選択に相当する規則であってよい。530Bの選択が、ある程度恣意的なものであり、多数の異なる選択プロセスとして構成されてよい(たとえば、RTPパケットが最大SSRCパケットを有するフレームが選択されてよい)ことが理解されよう。
【００７０】
図5Cを参照すると、図5Cは、本発明の一実施形態によって、2人以上のグループ通信セッション参加者がそれぞれの異なる優先順位レベルを有する、アプリケーションサーバ170で実行される540のフレーム選択の一例を示している。図5Cを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500C)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って選択を行う。たとえば、所与の選択規則は、第1の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1のAT)からの無音フレームが選択されるように訂正することができる。505Cの選択が、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが無音フレームを伝送するため、多数の異なる選択プロセスとして構成されてよい(たとえば、第2の聞き手の無音フレームが選択されたり、発信側の無音フレームが選択されたり、Table 4(表4)(上記)から判定された最高優先順位のATの無音フレームが選択されたりしてよい)ことが理解されよう。
【００７１】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510C)。510Cで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515C)。このようなデータレートフレームが1つだけではなく、510Cで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、Table 4(表4)(上記)によって指定された最高優先順位レベルを有するATに関連付けられた高データレートフレームを選択する(520C)。図5Cには図示されていないが、複数のフレームが高データレートを有し、同じ最高優先順位レベルを有するATに関連付けられている場合、MCCモジュール172は、図5Bの530BにおけるフレームのRTPパケットのSSRC番号など他の所与の選択規則に基づいて520Cの選択を行うことができる。
【００７２】
理解されるように、図5Bおよび5Cは、図5Aの540の選択の比較的簡単な2つの例を表しており、本発明の他の実施形態では、他の多数の異なる選択アルゴリズムを実施してもよい。また、図5Bおよび/または5Cには示されていないが、他の実施形態では、図5Bおよび/または5Cのプロセスは、相対優先順位レベルおよび/または相対データレートなど他の留意事項にかかわらず、発信側が高データレートフレームを送信したときはいつでも発信側から高データレートフレームを選択してよい(あるいは、このことは、たとえば、他の留意事項に優先する最高優先順位レベルを発信側に与えることとみなされてよい)。また、Table 4(表4)(上記)はATA...ATEに対する静的な1組の優先順位レベルを示しているが、本発明の他の実施形態では、優先順位レベルが動的なものであってよく、呼の間に変更されてよいことが理解されよう。たとえば、多数の異なるATが高データレートフレームを送信する場合、公平のために、所与のATのフレームが選択されるたびにその所与のATの優先順位レベルを減分し、その所与のATのフレームが選択されないときにはそのATの優先順位レベルを増分してもよい。しかし、当業者には理解されるように、優先順位レベルを動的に調整する多数の異なる方法がある。
【００７３】
また、図5Bおよび5Cは、単一の高データレートフレームが(利用可能な場合)選択される選択アルゴリズムに関する図であるが、図5Bおよび5Cのプロセスは、以下にそれぞれ図5Dおよび5Eに関して説明するように、複数のフレームが選択されるように修正することができる。
【００７４】
図5Dは、各グループ通信セッション参加者が同じ優先順位レベルを有し、本発明の一実施形態によって複数のフレーム(たとえば、2つ以上のフレーム)が選択される、アプリケーションサーバ170で実行される図5Aの540のフレーム選択の一例を示している。特に、図5Dは、単一のフレームではなく複数のフレームを選択することができるような上述の図5Bのプロセスの変形例を示している。
【００７５】
図5Dを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(たとえば、1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500D)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って1つまたは複数のフレームを選択する。たとえば、所与の選択規則は、2人以上の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1および第2のAT)からの無音フレームが選択されるように訂正することができる。選択すべきフレームの実際の数(たとえば、2つ、3つなど)は、アプリケーションサーバ170のオペレータによって決定することができる。
【００７６】
505Dの選択が、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが複数の混合無音フレームを伝送するため、多数の異なる選択プロセスとして構成されてよい(たとえば、第2および第3の聞き手の無音フレームが選択されたり、発信側の無音フレームおよび第1の無音フレームが選択されたりしてよい)ことが理解されよう。
【００７７】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510D)。510Dで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515D)。次いで、520Dで、所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、選択された高データレートフレームよりも低いデータレート(たとえば、1/8レート)を有する少なくとも1つの追加的なフレームも選択される。たとえば、他の所与の選択規則は、520Dで所与の数の聞き手(たとえば、第1の聞き手、第2の聞き手など)から1つ(または複数)の無音フレームが選択されるような、505Bおよび/または505Dの選択に相当する規則であってよい。
【００７８】
このようなデータレートフレームが1つだけではなく、510Dで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、複数の高データレートフレームのうちで最高のデータレートを有するのはどれかを判定する(525D)。MCCモジュール172は次に、高データレートフレームの中に1つだけ他の高データレートフレーム(たとえば、ハーフレートフレーム)よりも高いデータレート(たとえば、フルレートフレーム)を有するフレームが存在するかどうかを判定する(525D)。1つだけ、他のすべてのフレームよりも高いデータレートを有するフレームが存在する場合、515Dでこの最高データレートフレームが選択され、プロセスは上述のように520Dに進む。最高のデータレートを有するフレームが1つだけではない場合、MCCモジュール172は、他の所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、最高のデータレートを有するフレーム(たとえば、複数のフルレートフレーム、複数のハーフレートフレームなど)のからすべてのフレームを選択し、選択される必要のあるフレームの数が最高データレートフレームの数よりも小さい場合、MCCモジュール172は、他の所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、最高のデータレートを有するフレームからの選択を行う。たとえば、この所与の選択規則は、RTPパケットが最小SSRC値を有する2つ(または3つ以上)のフレームの選択に相当する規則であってよい。535Dの選択が、ある程度恣意的なものであり、多数の異なる選択プロセスとして構成されてよい(たとえば、RTPパケットが最大SSRCパケットを有するフレームが選択されてよい)ことが理解されよう。535Dの選択の後、MCCモジュール172は、任意の追加的なフレームを選択するかどうかを判定する(540D)。追加的なフレームを選択する場合、プロセスは上述のように520Dに進む。追加的なフレームを選択しない場合、この特定のタイムスロットについて図5Dの選択プロセスが完了する。
【００７９】
図5Eを参照すると、2人以上のグループ通信セッション参加者がそれぞれの異なる優先順位レベルを有し、本発明の一実施形態によって複数のフレーム(たとえば、2つ以上のフレーム)が選択される、アプリケーションサーバ170で実行される540のフレーム選択の一例を示している。特に、図5Eは、単一のフレームではなく複数のフレームを選択することができるような上述の図5Cのプロセスの変形例を示している。
【００８０】
図5Eを参照すると、アプリケーションサーバ170は、所与の時間間隔またはタイムスロット内にATA...ATEから高データレートフレーム(1/8レートよりも高いデータレートを有するフレーム)が受信されているかどうかを判定する(500E)。高データレートフレームは存在しないと判定された場合、アプリケーションサーバ170のMCCモジュール172は所与の選択規則に従って1つまたは複数のフレームを選択する。たとえば、所与の選択規則は、2人以上の聞き手(たとえば、ATB...ATEのうちの、図5Aの505からの呼アナウンスメッセージを受け入れた第1および第2のAT)からの無音フレームが選択されるように、505B、505Dおよび/または505Eの選択に対して訂正することができる。選択すべきフレームの実際の数(たとえば、2つ、3つなど)は、アプリケーションサーバ170のオペレータによって決定することができる。
【００８１】
505Dの選択は、ある程度恣意的な選択であり、アプリケーションサーバ170からの出力ストリーム上でどの無音フレームが再送されるかにかかわらず、出力ストリームが依然として複数の混合無音フレームを搬送するので、多数の様々な方法で構成されてよい(たとえば、第2および第3の聞き手の無音フレームが選択されたり、発信側の無音フレームおよび第1の無音フレームが選択されたりしてよい)ことが理解されよう。
【００８２】
高データレートフレームが存在すると判定された場合、ATA...ATEからの少なくとも1つのフレームがデータフレームであると判定された(たとえば、フレームが1/8よりも高いデータレートを有する)場合には、MCCモジュール172は、複数の高データレートフレームが存在するかどうかを判定する(510E)。510Eで、所与のタイムスロットに存在するATA...ATEからの高データレートフレームが1つだけであると判定された場合、この高データレートフレームが選択される(515E)。次いで、520Eで、所与の選択規則(たとえば、上述の所与の選択規則と同じ規則であっても異なる規則であってもよい)に基づいて、選択された高データレートフレームよりも低いデータレート(たとえば1/8レート)を有する少なくとも1つの追加的なフレームも選択される。たとえば、他の所与の選択規則は、520Eで所与の数の聞き手(たとえば、第1の聞き手、第2の聞き手など)から1つ(または複数)の無音フレームが選択されるような、上記に図5Dに関して論じた520Dに相当する規則であってよい。
【００８３】
このようなデータレートフレームが1つだけではなく、510Eで複数の高データレートフレームが存在すると判定された場合、MCCモジュール172は、Table 4(表4)(上記)によって指定された最高優先順位レベルを有するATに関連付けられた高データレートフレームを選択する(525E)。520Eでこのように選択されるフレームの数は、アプリケーションサーバ170のオペレータによって決定することができる。図5Eには示されていないが、選択に必要なフレームよりも多くのフレームが、高データレートを有し、かつ同じ最高優先順位レベルを有するATに関連付けられている場合、MCCモジュール172は、図5Bの530BにおけるフレームのRTPパケットのSSRC番号(たとえば、最大SSRC番号または最小SSRC番号)に基づく選択など所与の選択規則に基づいて、525Eの選択を行うことができる。
【００８４】
525Eの選択の後、MCCモジュール172は、任意の追加的なフレームを選択するかどうかを判定する(530E)。追加的なフレームを選択する場合、プロセスは上述のように520Eに進む。追加的なフレームを選択しない場合、この特定のタイムスロットについて図5Eの選択プロセスが完了する。
【００８５】
理解されるように、特定のタイムスロットの利用可能なフレームのサブセット(たとえば、そのようなフレームのうちの複数でありかつ全数よりも少ない数のフレーム)を選択する多数の異なる機構があり、図5Dおよび5Eはそのような選択プロセスの2つの例を示してきるに過ぎない。
【００８６】
以下に、図5B、5C、5D、および/または5Eに示されているような選択アルゴリズムに基づく、図5Aの高レベルグループ通信セッションプロセスのより詳細ないくつかの例について、図6A〜8に関して説明する。特に、図6Aおよび図7〜8は、図5Bおよび/または5Cと同様に単一のフレームが選択される例を示しており、図6Bは、図5Dおよび/または5Eと同様に複数のフレームが選択される例を示している。
【００８７】
したがって、図6Aは、本発明の一実施形態による図5Aのグループ通信セッションプロセスを示している。図6Aを参照すると、同じタイムスロット内で、ATBは1/8レートの無音フレームを送信し(600A)、ATC...ATEもそれぞれ、1/8レートの無線フレームを送信し(605A)、ATAは、音声データを保持するハーフレートのデータフレームを送信する(610A)。次に、615Aで、アプリケーションサーバ170のMCCモジュール172は、ATA...ATEのうちの1つからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図6Aの例では、高データレート(たとえば、この場合は、、1/2データレート、すなわち、ハーフデータレート)を有するのはATAからのフレームだけであるため、615でATAが選択される。515Bで図5Bの選択アルゴリズムがATAを選択し、一方、515Cで図5Cの選択アルゴリズムがATAを選択するため、図6Aのグループ通信セッションのコールタイプにかかわらずATAが選択されることが理解されよう。また、説明を明確にするために、図6Aの600A〜615Aがそれぞれ図5Aの525〜540に対応することが理解されよう。600A〜610Aの送信が10個のタイムスロット(すなわち、10t...T)にわたって繰り返されると仮定すると、タイムスロット10t...Tにおいてアプリケーションサーバ170で受信される入力ストリームは以下のように表されてよい。
【００８８】
【表７】
【００８９】
Table 7(表7)(上記)を参照すると、タイムスロット10t...Tの各々は、ATAがハーフレートフレームを送信することを示しており、一方、ATB...ATEの各々は、タイムスロット10t...Tで1/8レートフレームまたは無音フレームを送信する。したがって、タイムスロット10t...Tの各々について、図6Aの615Aで、出力ストリーム上でATB...ATEに送信されるフレームとしてATAのハーフレートフレームが選択される。
【００９０】
次に、620Aで、タイムスロット10t...Tの各々について、アプリケーションサーバ170は、ATAのハーフレートフレームを含む、出力ストリームの所与のタイムスロットに関するフレームを、ATB...ATEの各々に送信する。また、625Aおよび630Aは、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。625Aで、アプリケーションサーバ170は、615Aで選択されなかったATB...ATEのうちの1つからの所与のタイムスロットに関するフレームのうちの1つをATAに送信されるフレームとして選択する。たとえば、この選択は、625AではATAのフレームが考慮されないことを除いて、図5Bまたは5Cの選択アルゴリズムに従って実行されてよい。Table 7(表7)(上記)に基づいて、タイムスロット10t...Tの各々は、ATA...ATEの各々からの同じフレームレートで構成される。説明の都合上、625Aの選択では、タイムスロット10t...Tの各々についてATCのフレームが選択されると仮定する。したがって、630Aで、アプリケーションサーバ170は、10t...Tの各々について、ATCの1/8レートフレームを含む、出力ストリームの1つまたは複数のタイムスロットに関するフレームを、ATAに送信する。送信620Aおよび630Aは、別個のブロックとして示されているが、同時に実行されてよいことが理解されよう。したがって、上記に示した仮定に基づいて、620Aおよび630AでATA...ATEに送信される出力ストリームは以下のように表されてよい。
【００９１】
【表８】
【００９２】
表において、出力ストリーム内の各フレームについて括弧内に示されたATは、対応するタイムスロットに関する入力ストリーム上のこの示されたATからのフレームを示している。
【００９３】
図6Bは、本発明の他の実施形態による図5Aのグループ通信セッションプロセスを示している。特に、図6Bは、図6Aに示されているような図5Bおよび/または5Cの単一フレーム選択プロセスの代わりに、図5Dおよび/または5Eの多重フレーム選択プロセスが実施されるプロセスを示している。
【００９４】
したがって、図6Aと同様に、同じタイムスロット内で、ATBは1/8レートの無音フレームを送信し(600B)、ATC...ATEもそれぞれ、1/8レートの無線フレームを送信し(605B)、ATAは、音声データを保持するハーフレートのデータレートフレームを送信する(610B)。
【００９５】
次に、615Bで、アプリケーションサーバ170のMCCモジュール172は、ATA...ATEのうちの複数のATからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図6Bの例では、ATA...ATEのうちで高データレートフレーム(たとえば、ハーフレートフレーム)を送信するのがATAだけであるため、ATAからのフレームが選択されるフレームのうちの1つに相当すると仮定されてよい。したがって、図5Dの選択プロセスでは、510Dで高データレートフレームが1つしか存在しないことが判定された後、515DでATAのフレームが選択される。次に、この例では、説明の都合上、ATAのフレームが選択された後、520DでATBのフレームも選択されると仮定されてよい。したがって、本明細書の例では、615Bで2つのフレームが選択されると仮定する。ただし、他の実施形態では、615Bで3つ以上のフレームが選択されてよい。他の例では、図5Dの代わりに図5Eの選択プロセスが実施された場合、510Eで高データレートフレームが1つしか存在しないことが判定された後、515EでATAのフレームが選択されることが理解されよう。説明の都合上、この実装形態ではさらに、520EでATBのフレームが選択されると仮定する。したがって、後に615BでATAおよびATBからのフレームが選択されると仮定する。
【００９６】
MCCモジュール172は、615BでATAおよびATBからのフレームを選択した後、620Bで選択されたフレームを混合する。この混合は、従来のメディアストリームを(たとえば、デジタル処理的に)混合するのと同じ方法に相当する混合であってよい。ただし、620Bの混合は、フレームの選択された(たとえば、ATAおよびATBのみから選択された)サブセットに限定され、送信を行うことが許可されているグループ通信セッションの各参加者(たとえば、この場合は、ATA...ATE)からの各フレームを混合するわけではない。したがって、MCCモジュール172は次に、混合されたフレーム(すなわち、フレームA+フレームB)をATC...ATEに送信し、ATBからの混合されていないフレームをATAに送信し、ATAからの混合されていないフレームをATBに送信する。この実施形態では、フィードバックの発生を低減させるために混合されたフレームがATAにもATBにも送信されないことが理解されよう。ただし、他の実施形態においてMCCモジュール172でのプログラミング論理を簡略化するために混合されたフレームをすべての参加者に同様に送信することが少なくとも理論的にはあり得る。しかし、615Bで3つ以上のフレームが選択される他の実施形態では、選択されたフレームに関連付けられた各ATが実際に、混合されたフレームを受信する。ただし、選択された各AT自体のフレームは、それが受信するストリームから除去される。
【００９７】
また、説明を明確にするために、図6Aの600B〜615Bがそれぞれ、図5Aの525〜540に相当することが理解されよう。600B〜610Bの送信および615Bの選択が10個のタイムスロット(すなわち、10t...T)について繰り返されると仮定すると、タイムスロット10t...Tにおいてアプリケーションサーバ170で受信される入力ストリームは、上記にTable 7(表7)に示されているように表されてよい。
【００９８】
したがって、620Bで、タイムスロット10t...Tの各々について、アプリケーションサーバ170は、ATAのハーフレートフレームおよびATBの1/8レートフレームを含む、出力ストリームの所与のタイムスロットに関するフレームを、ATC...ATEの各々に送信する。また、625Bおよび630Bは、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。625Bで、アプリケーションサーバ170は、615Bで選択されなかったATC...ATEのうちの1つからの所与のタイムスロットに関するフレームのうちの1つをATAおよびATBに送信されるフレームとして選択する。たとえば、625Bの選択は、625BではATAおよびATBのフレームが考慮されないことを除いて、図5Bまたは5Cの選択アルゴリズムに従って実行されてよい。Table 7(表7)(上記)に基づいて、タイムスロット10t...Tの各々は、ATA...ATEの各々からの同じフレームレートで構成される。説明の都合上、625Bの選択では、タイムスロット10t...Tの各々についてATCのフレームが選択されると仮定する。したがって、630Bで、アプリケーションサーバ170は、10t...Tの各々について、(たとえば、ATAからATBへの混合されていないフレームおよびATBからATAへの混合されていないフレームに加えて)ATCの1/8レートフレームを含む、出力ストリームの1つまたは複数のタイムスロットに関するフレームを、ATAおよびATBに送信する。送信620Bおよび630Bは、別個のブロックとして示されているが、同時に実行されてよいことが理解されよう。したがって、上記に示した仮定に基づいて、620Bおよび630BでATA...ATEに送信される出力ストリームは以下のように表されてよい。
【００９９】
【表９】
【０１００】
この場合、10t...Tの各タイムスロットにおいて、ATAは1/4レートフレームを受信し(すなわち、ATBおよびATCからの1/8レートフレーム同士を組み合わせたフレームを受信し)、ATBは5/8レートフレームを受信し(すなわち、ATAからの1/2レートフレームとATCからの1/8レートフレームを組み合わせたフレームを受信し)、ATC...ATEの各々は5/8レートフレームを受信する(すなわち、ATAからの1/2レートフレームとATBからの1/8レートフレームを組み合わせたフレームを受信する)。
【０１０１】
したがって、図6Aおよび6Bを検討すると理解されるように、図5Aの540の選択は、タイムスロット当たりに1つのATからの単一のフレームを他の各ATに送信されるフレームとして選択することに相当する選択であってよく(たとえば、図6A参照)、あるいはタイムスロット当たりに複数のAT(たとえば、2つ以上のAT)からの単一のフレームを他の各ATに送信されるフレームとして選択することに相当する選択であってよい(たとえば、図6B参照)。以下の他の実施形態は、図6Aのようにタイムスロット当たりに単一のATから単一のフレームを選択すること、すなわち、図5Bおよび5Cの選択プロセスに関する実施形態である。しかし、これらの実施形態についての説明は、説明の都合上のものであり、以下に図7〜13に関して説明する実施形態において複数のATからのフレームを選択できないことを意味するものではない。言い換えれば、図5D、5E、または6Bのようにタイムスロット当たりに複数のフレームを選択することを後述の各実施形態に適用することは当業者の能力の範囲内であり、したがって、タイムスロット当たりに単一のATからの単一のフレームを選択することの参照は、各実施形態の理解を容易にするための例に過ぎない。
【０１０２】
したがって、次に、ATA...ATEのそれぞれが高データレートフレームを順に送信する(たとえば、多数の参加者同士の会話が行われていることを示すと考えられる)分散トークサポート(interspersed talk support)の例について説明する。したがって、図6A(または他の実施形態では、たとえば、図6B)のプロセスが、少なくとも1つの時間間隔またはタイムスロットについて実行され、次いで図7の700に進むと仮定する。
【０１０３】
図7を参照すると、図6Aの620Aおよび630Aにおいて所与のタイムスロットに関する出力ストリームが送信されたことに続く次のタイムスロットで、ATBが音声データを保持するハーフレートデータフレームを送信し(700)、ATC...ATEがそれぞれ1/8レート無音フレームを送信し(705)、ATAが1/8レート無音フレームを送信する(710)と仮定する。次に、715で、アプリケーションサーバ170のMCCモジュール172は、ATA...ATEのうちの1つからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図7の例では、高データレート(たとえば、この場合は、1/2データレート、すなわち、ハーフデータレート)を有するのはATBからのフレームだけであるため、715でATBが選択される。515Bで図5Bの選択アルゴリズムがATBを選択し、一方、515Cで図5Cの選択アルゴリズムがATBを選択するため、図7のグループ通信セッションのコールタイプにかかわらずATBが選択されることが理解されよう。また、説明を明確にするために、図7の700〜715がそれぞれ図5Aの525〜540に対応することが理解されよう。
【０１０４】
600A〜610Aの送信が5個のタイムスロット(10t...6t)にわたって繰り返され、700〜710の送信が次の5個のタイムスロット(5t...T)にわたって繰り返されると仮定すると、タイムスロット10t...Tにわたってアプリケーションサーバ170で受信される入力ストリームは以下のように表されてよい。
【０１０５】
【表１０】
【０１０６】
Table 9(表10)(上記)を参照すると、タイムスロット10t...6tの各々は、ATAがハーフレートフレームを送信することを示しており、一方、ATB...ATEの各々は、1/8レートフレームまたは無音フレームを送信する。さらに、タイムスロット5t...Tの各々は、ATBがハーフレートフレームを送信することを示しており、一方、ATAおよびATC...ATEの各々は、1/8レートフレームまたは無音フレームを送信する。したがって、タイムスロット10t...6tの各々については、図6Aの615Aで、出力ストリーム上でATB...ATEに送信されるフレームとしてATAのハーフレートフレームが選択され、一方、5t...Tの各々については、図7の715で、出力ストリーム上でATAおよびATC...ATEに送信されるフレームとしてATBのハーフレートフレームが選択される。
【０１０７】
次に、720で、タイムスロット5t...Tの各々について、アプリケーションサーバ170は、ATBのハーフレートフレームを含む出力ストリームをATAおよびATC...ATEの各々に送信する。また、725および730は、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。725で、アプリケーションサーバ170は、タイムスロット5t...Tについて、715で選択されなかったATAおよびATC...ATEのうちの1つからの所与のタイムスロットに関するフレームのうちの1つをATBに送信されるフレームとして選択する。たとえば、725の選択は、725ではATBのフレームが考慮されないことを除いて、図5Bまたは5Cの選択アルゴリズムに従って実行されてよい。Table 9(表10)(上記)に基づいて、タイムスロット5t...Tの各々は、ATA...ATEの各々からの同じフレームレートで構成される。説明の都合上、725の選択では、タイムスロット5t...Tの各々についてATCのフレームが選択されると仮定する。したがって、730で、アプリケーションサーバ170は、5t...Tの各々について、ATCの1/8レートフレームを含む出力ストリームをATBに送信する。送信720および730は、別個のブロックとして示されているが、同時に実行されてよいことが理解されよう。したがって、上記の仮定に基づき、Table 9(表10)(上記)の入力ストリームに基づいてタイムスロット10t...TにわたってATA...ATEに送信される出力ストリームは、以下のように表されてよい。
【０１０８】
【表１１】
【０１０９】
図6Aの例は、単一のAT(すなわち、ATA)からの連続トークサポート(continuous talk support、たとえば、一連の高データレートフレーム)に関する例であり、図7は分散トークサポート(たとえば、各ATが順に高データレートフレームを送信する)に関する例であるが、次に、複数のATが高データレートフレームを同時に送信する例について図8に関して説明する。図8は、どのATも高データレートフレームを送信しないタイムスロットをどのように評価するかについての例も示している。
【０１１０】
図8を参照すると、各ATA...ATEは、10t...Tの10個のタイムスロット間隔にわたって所与のデータレートでフレーム(たとえば、データフレームおよび/または無音フレーム)を送信する(800、805および810)。
【０１１１】
815で、アプリケーションサーバ170のMCCモジュール172は、タイムスロット10t...Tの各々について、ATA...ATEのうちの1つからのフレームを出力ストリーム上で他の各ATに再送されるフレームとして選択する。図8の例では、800〜810の送信によって、アプリケーションサーバ170のMCCモジュール172で、Table 11(表12)(下記)に示されているような入力ストリームが得られる。
【０１１２】
【表１２】
【０１１３】
したがって、Table 11(表12)(上記)のタイムスロット10tおよび3t...Tについての選択は、図6Aに従って実行され(たとえば、上記のTable 7(表7)を参照されたい)、ATA...ATEのうちで、これらのタイムスロットで高データレートフレームを送信するATがATAだけであるため、ATAからのハーフレートフレームが選択される。同様に、Table 11(表12)(上記)のタイムスロット8t、7t、および5tについての選択は、図7のタイムスロット5t...Tに従って実行され(たとえば、上記のTable 9(表10)を参照されたい)、ATA...ATEのうちで、これらのタイムスロットで高データレートフレームを送信するATがATBだけであるため、ATBからのハーフレートフレームが選択される。
【０１１４】
しかし、Table 11(表12)(上記)のタイムスロット9tおよび6tでは、ATAとATBの両方がハーフレートフレームを送信する。したがって、アプリケーションサーバ170は、図8の815における9tおよび6tについては、グループ通信セッションのコールタイプに基づいて図5Bおよび/または5Cに示されているような選択アルゴリズムを適用する。たとえば、ATA...ATEの各々がグループ通信セッションのコールタイプに関して同じ優先順位レベルを有する場合、815の選択が図5Bに従って実行され、ATA...ATEのうちの2つ以上がグループ通信セッションのコールタイプに関してそれぞれの異なる優先順位レベルを有する場合、815の選択が図5Cに従って実行される。いずれの場合も、説明の都合上、図8におけるATAとATBの同時高データレートフレーム送信に関する評価によって、コールタイプにかかわらず、(たとえば、図5Bにおける530Bの選択または図5Cにおける520Cの選択に基づいて)ATBのフレームが選択される。
【０１１５】
また、タイムスロット4tでは、ATA...ATEの各々が1/8レート無音フレームを送信する。したがって、図5Bの500Bおよび図5Cの500Cの判定はそれぞれ505Bおよび505Cに進み、4tにおける送信には、コールタイプにかかわらず、第1の聞き手の無音フレームが選択される。
【０１１６】
また、上記の625A/725および630A/730と同様に、825および830は、アプリケーションサーバ170によって実行されてもよい任意のステップに相当する。825で、アプリケーションサーバ170は、タイムスロット10t...Tの各々について、815で対応するタイムスロットについて選択されなかったATA...ATEのうちの1つからの所与のタイムスロットに関するフレームの1つを、対応するタイムスロットの選択されたフレームに関連付けられたATに送信されるフレームとして選択する。825で、10tおよび3t...TについてATBの1/8レートフレームが選択され、9t...5tについてATCの1/8レートフレームが選択される。入力ストリームにはデータフレームがなく、したがって、(たとえば、ATA...ATEの1つがそれ自体の無音フレームをフィードバックされるにもかかわらず)815で選択された1/8無音フレームがATA...ATEの各々に送信されるため、4tでは825および830が実行されないことが理解されよう。アプリケーションサーバ170は次に、10t...5tおよび3t...Tにわたって、825で選択されたフレームを各ATに送信する(830)。
【０１１７】
したがって、上記に示した仮定に基づいて、820および830でタイムスロット10t...TにわたってATA...ATEに送信される出力ストリームは以下のように表されてよい。
【０１１８】
【表１３】
【０１１９】
当業者によって理解されるように、ATA...ATEへの出力ストリーム上でRTPパケットのヘッダをどのように構成するかが、ターゲットATが、フレームを含むRTPパケットを首尾よく復号するかあるいは単にフレームを破棄するかに影響を与えることがある。たとえば、RTPパケットヘッダ部の概略的な構造がTable 1(表1)(上記)に示されている。上記のように、RTPパケットヘッダは、いくつかのあるフィールドの中で特に、それぞれ、上記にTable 1(表1)(上記)に関して定義された、CCフィールド、シーケンス番号フィールド、タイムスタンプフィールド、およびSSRCフィールドを含む。
【０１２０】
メディアストリームを復号するATは、これらのフィールドの各々についてのメディアストリームの有効なRTPパケットにどんな種類の値が関連付けられるかに関するある程度の予想をすることができる。たとえば、誤ったSSRC番号、タイムスタンプ値、および/またはシーケンス番号を有するATでRTPパケットが受信された場合、そのRTPパケットはATによって単に破棄される。理解されるように、ATA...ATEからアプリケーションサーバ170で受信される各メディアストリームは、各ATの下りリンクメディアストリームに固有のフィールド値を有するRTPパケットで構成される。たとえば、ATAはそのメディアストリームを識別するATA自体のSSRC値を有する。
【０１２１】
図9は、本発明の一実施形態によって、アプリケーションサーバ170においてあるATのフレームから他のATのフレームに切り替える際にグループ通信セッションのメディアフローのターゲットATでのパケット破棄率を低下させることのできる高レベルプロセスを示している。
【０１２２】
図9を参照すると、900で、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する。一例として、900の選択は、上述の各実施形態における任意のフレーム選択(たとえば、図5Aの540、図6Aの615A、図6Aの625Aなど)に相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内でATAに送信される出力フレームを生成する(905)。905で、アプリケーションサーバ170は、ATAの出力されたフレームを保持するRTPパケットのRTPパケットヘッダを、ATA...ATEのうちのどのATのフレームが、構成されたRTPパケット内でATAに送信されるかにかかわらず、ATAでの復号を容易にするように構成する。言い換えれば、入力ストリーム上の選択されたフレームから得られるメディアフローパラメータ(たとえば、CCフィールド、タイムスタンプフィールド、SSRCフィールド、シーケンス番号フィールドなど)は、必要に応じて、出力ストリームを保持するRTPパケット向けに再構成される。
【０１２３】
たとえば、以下に詳しく説明するように、905の構成は、送信側ATまたは送信元ATに固有のアプリケーションサーバ170の入力ストリームで受信されるRTPパケットヘッダにおけるCCフィールド、シーケンス番号フィールド、タイムスタンプフィールド、および/またはSSRC番号フィールドを、グループ通信セッションの出力ストリーム用の値としてアプリケーションサーバ170によって維持されているフィールド値に修正することを含んでよい。したがって、RTPパケットのデータペイロード部は、入力ストリームにおけるどのフレームがATAに出力されるフレームとして選択されるかに応じて修正されるが、RTPパケットヘッダ部は、必要に応じてATAでの復号を容易にするように調整することができ、入力ストリーム上に選択されたフレームを保持するRTPパケットにマップするだけでよいわけではない。
【０１２４】
アプリケーションサーバ170は、出力フレームを修正されたRTPパケットヘッダ部を含むように構成した後、構成された出力フレームをATAに送信する(910)。ATAは、出力フレームのRTPパケットヘッダ部をどのように構成するかに少なくとも部分的に基づいて、RTPパケットを復号すべきかどうかを判定する(915)。RTPパケットヘッダ部の構成のために、ATAが915でRTPパケットを復号すべきであると判定し、RTPパケットおよび関連するフレームがATAによって復号される(920)。
【０１２５】
次に、グループ通信セッションに対するターゲットATでの復号を容易にするようにアプリケーションサーバ170で行うことのできるRTPパケットヘッダ修正のより具体的な例について図10〜13に関して説明する。
【０１２６】
たとえば、図10は、アプリケーションサーバ170が出力ストリームでATAに転送されるRTPパケットのSSRC値の修正を行わない、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示し、一方、図11は、アプリケーションサーバ170が図9に従ってSSRC値を修正する同じグループ通信セッション中のATAでの復号結果を示している。
【０１２７】
図10を参照すると、アプリケーションサーバ170は、グループ通信セッションについての現在の話し手、すなわち、フロアホルダを識別するSSRC値(たとえば、SSRC=2)をATAに割り当てる(1000)。たとえば、1000におけるSSRC値の割り当てはASK/FYIメッセージに相当する割り当てであってよく、ATAは、最後に割り当てられたSSRC値に相当するSSRC値を有するグループ通信セッションに関するRTPパケットのみを復号する。したがって、ATAは、ATAで他のSSRC値割り当てメッセージ(たとえば、ASK/FYIメッセージ)が受信されるまでSSRC値が2であるRTPパケットのみを復号する。理解されるように、ASK(ユーザID)メッセージは、ATが未知のSSRCまたは予期しないSSRCを含むRTPパケットを受信した場合にATによってアプリケーションサーバ170に送信される。アプリケーションサーバ170は、未知のSSRC値に対応するクライアントのIDでASKメッセージに応答する。図10の上部で、図10のステップ1000におけるSSRC割り当てを指示するASKメッセージまたはFYIメッセージは、ステップ1000でSSRC2が割り当てられる前にATAがSSRC2からRTPパケットを受信したときにATAでトリガすることができ、かつ後に後述のステップ1040でSSRC3が受信された後でATAでトリガすることができる。
【０１２８】
次に、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する(1005)。一例として、1000の選択は図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1010)。図10の例では、出力フレームを保持するRTPパケットが、SSRC値2を有するこのフレームの送信元ATに関連付けられたSSRC値をパケットのヘッダ部に維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないSSRC値の2を含むRTPパケットで出力フレームをATAに送信する(1015)。
【０１２９】
ATAは、送信された出力フレームを(場合によっては、たとえば、他の出力フレームと一緒に)保持するRTPパケットを受信し、RTPパケットヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1020)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が2に等しいかどうかを検査する。RTPパケットのSSRC値は2と仮定されているので、ATAはこのフレームを復号する(1025)。
【０１３０】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1030)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1035)。図10の例では、(たとえば、アプリケーションサーバ170が、別のATからあるフレームに切り替えたため)出力フレームを保持するRTPパケットが、この場合はSSRC値3を有するこのフレームの送信元ATに関連付けられたSSRC値を維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないSSRC値の3を含むRTPパケットで出力フレームをATAに送信する(1040)。
【０１３１】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1045)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が2に等しいかどうかを検査する。RTPパケットのSSRC値は3と仮定されているので、ATAはこのフレームを破棄する(1050)。また、ATAがSSRC3を復号するように指定された後のSSRC2からのRTPパケットを破棄すべきであるのは、RTPパケットヘッダ内の関連するタイムスタンプがSSRC3からの最新のパケットよりも古い場合だけであり、これによって、SSRC2RTPパケットがSSRC2への正当な切り替えである場合に破棄されるパケットの発生が少なくなることを理解されたい。
【０１３２】
図示の例では、この下りリンクRTPパケット送信についてATA...ATEに割り当てられるSSRC値はそれぞれ、1...5であると仮定する。次に、タイムスロット10t...Tにわたってアプリケーションサーバ170のMMCモジュール172で受信される入力ストリームはTable 11(表12)(上記)に相当する入力ストリームであると仮定する。したがって、すでに上記にTable 12(表13)(上記)に関して説明した、ATA...ATEに送信される出力ストリームは、以下のように、各出力フレームのSSRC値、または出力フレームのRTPパケットを含んでよい(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)。
【０１３３】
【表１４】
【０１３４】
次に、パケット復号のための1000のSSRC値割り当てによって、上述のように(SSRC=2)がATAに送信され、(SSRC=1)がATB...ATEの各々に別個に示されると仮定する。これらの仮定の下で、他のSSRC値割り当てメッセージがATA...ATEに送信されることはなく、図10のプロセスがタイムスロット10t...TにわたってATA...ATEで実行されると仮定すると、Table 14(表15)(下記)が、ATA...ATEの各々で実際に復号または再生されるRTPパケットを示す(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)ことが理解されよう。
【０１３５】
【表１５】
【０１３６】
Table 14(表15)に示されているように、ATB...ATEは、関連するSSRC値が1ではないためタイムスロット9t...4t間の各パケットを破棄する。
【０１３７】
したがって、図11は、図10に示されたシナリオに適用される図9のプロセスを示している。図11は、アプリケーションサーバ170が、図9に従って出力ストリームでATAに転送されるRTPパケットのSSRC値を修正する、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示している。
【０１３８】
図11を参照すると、アプリケーションサーバ170は、アプリケーションサーバ170によってグループ通信セッションに関して転送される任意のRTPパケットを識別するのに使用されるSSRC値(たとえば、SSRC=1)をATAに割り当てる(1000)。1000のSSRC値割り当ては、アプリケーションサーバ170がグループ通信セッション中に様々なATのフレーム同士を切り替えるにもかかわらず、グループ通信セッション当たりに1度実行されるだけでよい。したがって、ATAは、グループ通信セッション中にSSRC値が1のパケットを復号するに過ぎない。図11には明示的に示されていないが、ATB...ATEの各々も、ATB...ATEに、グループ通信セッションのために、SSRC値が1に等しいRTPパケットを復号するよう指示するSSRC値割り当てメッセージを受信する。
【０１３９】
次に、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する(1105)。一例として、1105の選択は、図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1110)。特に、アプリケーションサーバ170は、必要に応じて、生成される出力フレームのSSRC値が1になるように、1110で出力フレームを保持するRTPパケットのSSRC値を修正する。また、アプリケーションサーバ170は、出力フレームを保持するRTPパケットのCSRC値を、その出力フレームの送信元ATのSSRC値を示すSSRC値に任意に修正してよい。したがって、入力ストリーム内の選択されたフレームに関連付けられたRTPパケットのSSRC値が4である場合、出力フレームのSSRC値は4から1に置き換わり、CSRCが4に等しく設定される。したがって、アプリケーションサーバ170は、(場合によっては)修正されたSSRC値の1(および適宜、たとえば、CSRC値4)を含むRTPパケットで出力フレームをATAに送信する(1115)。
【０１４０】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1120)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が1に等しいかどうかを検査する。アプリケーションサーバ170がRTPパケットのSSRC値を1に設定したため、ATAはこのフレームを復号する(1125)。
【０１４１】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1130)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1135)。1110と同様に、新たに選択されたフレームについてのRTPパケットの入力ストリーム内のSSRC値にかかわらず、ATAへの出力ストリーム内に出力フレームを保持するRTPパケットのSSRC値が1に設定され、入力ストリーム上の選択されたフレームのRTPパケットのSSRC値に対応するCSRC値を任意に、出力フレームを保持するRTPパケットのRTPパケットヘッダ部に付加してよい(1135)。したがって、アプリケーションサーバ170は、(場合によっては)修正されたSSRC値の1(および場合によっては、たとえば、CSRC値4)を含むRTPパケットで出力フレームをATAに送信する(1140)。
【０１４２】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともSSRC値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1145)。特に、ATAは、RTPパケットヘッダ部内のSSRC値が1に等しいかどうかを検査する。アプリケーションサーバ170がRTPパケットのSSRC値を1に設定したため、ATAはこのフレームを復号する(1150)。
【０１４３】
図示の例では、ATA...ATEの下りリンクRTPパケット送信に関してATA...ATEに割り当てられたSSRC値がそれぞれ1...5であると仮定する。次に、タイムスロット10t...Tにわたってアプリケーションサーバ170のMCCモジュール172で受信された入力ストリームがTable 11(表12)(上記)に相当する入力ストリームであると仮定する。したがって、すでに上記にTable 12(表13)(上記)に関して説明した、ATA...ATEに送信される出力ストリームは、以下のように、出力ストリームの出力フレームを保持する各RTPパケットのSSRC値を含んでよい(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)。
【０１４４】
【表１６】
【０１４５】
次に、パケット復号のための1000のSSRC値割り当てによって、上述のように(SSRC=1)がATAに送信され、(SSRC=1)がATB...ATEの各々に別個に示されると仮定する。これらの仮定の下で、他のSSRC値割り当てメッセージがATA...ATEに送信されることはなく、図11のプロセスがタイムスロット10t...TにわたってATA...ATEで実行されると仮定すると、Table 15(表16)(上記)が、出力ストリームを示すだけでなく、破棄されるパケットがないため、それぞれのATA...ATEの各々での再生も示すことが理解されよう。
【０１４６】
図10および11は、グループ通信セッション中の各ATでのパケット復号の決定に対するSSRC値の影響を示すことに関する図であるが、パケット復号の決定に影響を与える可能性のある他のRTPパケットヘッダフィールドは、次に図12および13に関して説明するようにシーケンス番号である。
【０１４７】
たとえば、図12は、アプリケーションサーバ170が出力ストリームでATAに転送されるRTPパケットのシーケンス番号値を修正しない、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示しており、一方、図13は、アプリケーションサーバ170が図9に従ってシーケンス番号値を修正する、同じグループ通信セッション中のATAでの復号結果を示している。
【０１４８】
図12を参照すると、1200で、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する(1200)。一例として、1200の選択は図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1205)。図12の例では、出力フレームを保持するRTPパケットが、現在のタイムスロットのシーケンス番号の2021を有するこのフレームを保持する送信元ATのRTPパケットに関連付けられたシーケンス番号値を維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないシーケンス番号値の2021を含むRTPパケットで出力フレームをATAに送信する(1210)。
【０１４９】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1215)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が1つまたは複数の以前のRTPパケットと連続しているかどうかを検査する。1215では、シーケンス番号値が連続していると仮定し、ATAはこのRTPパケットペイロードを復号し、それによってこのフレームを復号する(1220)。
【０１５０】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1225)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1230)。図12の例では、出力フレームを保持するRTPパケットが、たとえば、シーケンス番号102を有する可能性があるこのフレームの送信元ATに関連付けられたシーケンス番号値を維持すると仮定する。したがって、アプリケーションサーバ170は、修正されていないシーケンス番号値の102を含むRTPパケット内の出力フレームをATAに送信する(1235)。
【０１５１】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1240)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が1つまたは複数の前のRTPパケットと連続しているかどうかを検査する。シーケンス番号102はシーケンス番号2021と連続していないため、ATAはこのフレームを破棄する(すなわち、RTPパケットペイロード部を復号しない)(1245)。
【０１５２】
図示の例では、Table 11(表12)(上記)の入力ストリームのタイムスロット10t...Tにわたるこの下りリンクRTPパケット送信についてATA...ATEに割り当てられるシーケンス番号値は、以下のようにTable 16(表17)(下記)によって示される値であると仮定する。
【０１５３】
【表１７】
【０１５４】
したがって、すでに上記にTable 12(表13)(上記)に関して説明した、ATA...ATEに送信される出力ストリームは、以下のように、出力ストリームの関連する出力フレームを保持する各RTPパケットのシーケンス番号値を含んでよい(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)。
【０１５５】
【表１８】
【０１５６】
これらの仮定の下で、図12のプロセスがタイムスロット10t...TにわたってATA...ATEで実行される場合、Table 18(表19)(下記)が、ATA...ATEの各々で実際に復号または再生されるRTPパケットを示すことが理解されよう。
【０１５７】
【表１９】
【０１５８】
Table 18(表19)に示されているように、ATB...ATEは、関連するシーケンス番号が連続していないため、タイムスロット9t...4t間の各フレームを破棄する。
【０１５９】
次に、図13は、図12に示されたシナリオに適用される図9のプロセスを示している。図12は、アプリケーションサーバ170が、図9に従って出力ストリームでATAに転送されるRTPパケットのシーケンス番号値を修正する、図5A、6、7、および/または8のいずれかのグループ通信セッション中のATAでの復号結果を示している。
【０１６０】
図13を参照すると、アプリケーションサーバ170は、入力ストリーム上のRTPパケットに関連付けられた個々のシーケンス番号にかかわらず、出力ストリーム上のRTPパケットに使用されるシーケンス番号値(たとえば、0001、0002、0003など)の単一のストリームを維持する。
【０１６１】
1300で、アプリケーションサーバ170は、ATB...ATEのうちの1つからのフレームを出力ストリーム上の所与のタイムスロット内にATAに送信されるフレームとして選択する。一例として、1300の選択は、図5Aの540、図6Aの615A、図6Aの625Aなどに相当する選択であってよい。次に、アプリケーションサーバ170は、出力ストリームの所与のタイムスロット内にATAに送信される出力フレームを生成する(1305)。特に、アプリケーションサーバ170は、必要に応じて、RTPパケットのシーケンス番号値がグループ通信セッションの出力フレームシーケンスの現在のシーケンス番号(グループ通信セッションシーケンス番号)(たとえば、0001)に対応するように、1305で出力フレームを保持するRTPパケットのシーケンス番号値を修正する。したがって、アプリケーションサーバ170は、現在のグループ通信セッションシーケンス番号を含むRTPパケットで出力フレームをATAに送信し(1310)、次にグループ通信セッションシーケンス番号を(たとえば、0001から0002に)増分する(1315)。
【０１６２】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1320)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が順序正しい値であるかどうかを検査する。アプリケーションサーバ170がそれぞれの異なるATのメディアフロー同士を切り替えるかどうかにかかわらず、グループ通信セッションシーケンス番号の順序が維持されるため、ATAは、RTPパケットペイロード部を復号し、それによってこのフレームを復号する(1325)。
【０１６３】
次に、アプリケーションサーバ170は、ATB...ATEのうちの異なる1つのATからのフレームを出力ストリーム上の次のタイムスロット内にATAに送信されるフレームとして選択する(1330)。次に、アプリケーションサーバ170は、出力ストリームの次のタイムスロット内にATAに送信される出力フレームを生成する(1335)。1305と同様に、新たに選択されたフレームを保持するRTPパケットの入力ストリーム内のシーケンス番号値にかかわらず、ATAへの出力ストリーム内に出力フレームを保持するRTPパケットのシーケンス番号値が現在のグループ通信セッションシーケンス番号(たとえば、0002)に設定される(1335)。したがって、アプリケーションサーバ170は、現在のグループ通信セッションシーケンス番号を含むRTPパケット内の出力フレームをATAに送信する(1340)。
【０１６４】
ATAは、送信された出力フレームを保持するRTPパケットを受信し、ヘッダ内の少なくともシーケンス番号値を評価して、RTPパケットのペイロードを復号すべきかどうかを判定する(1345)。特に、ATAは、RTPパケットヘッダ部内のシーケンス番号値が順序正しい値であるかどうかを検査する。アプリケーションサーバ170がそれぞれの異なるATのメディアフロー同士を切り替えるかどうかにかかわらず、グループ通信セッションシーケンス番号の順序が維持されるため、ATAは、RTPペイロード部を復号し、それによってこのフレームを復号する(1350)。
【０１６５】
図示の例では、Table 11(表12)(上記)の入力ストリームのタイムスロット10t...TにわたるATA...ATEの下りリンクRTPパケット送信に関してATA...ATEに割り当てられたシーケンス番号値が、Table 16(表17)(上記)によって示されている値であると仮定する。これらの仮定の下では、図13のプロセスがタイムスロット10t...TにわたってATA...ATEで実行された場合、Table 19(表20)(下記)が、すでに上記でTable 12(表13)(上記)に関して説明済みであり、出力ストリームの各出力フレームを保持するRTPパケットのシーケンス番号値を含む、ATA...ATEに送信される出力ストリームを示す(たとえば、出力フレームとRTPパケットとの間で1対1のマッピングが行われ、かつ複数の出力フレームが単一のRTPパケット内にバンドルされないと仮定する場合)ことが理解されよう。
【０１６６】
【表２０】
【０１６７】
これらの仮定の下で、図13のプロセスがタイムスロット10t...TにわたってATA...ATEで実行されると仮定すると、Table 19(表20)(上記)が、出力ストリームを示すだけでなく、破棄されるRTPパケットがないため、それぞれのATA...ATEの各々での再生も示すことが理解されよう。
【０１６８】
図11および13は、それぞれSSRCおよびシーケンス番号に対する修正に基づく図9の実装形態に関する図であるが、図11および13のプロセスが同時に実行されてもよいことが理解されよう。また、図9の他の実装形態は、RTPパケットヘッダのタイムスタンプフィールドなど、RTPパケットヘッダの他のフィールド(メディアフローパラメータ)の復号を容易にするように修正することに関する実装形態であってもよい。この実施形態については、図9から13の説明に鑑みて容易に明らかになるので、あまり詳しく説明しない。
【０１６９】
各実施形態を概してオーディオベースのグループ通信セッションに関して説明したが、他の実施形態は、テレビ会議など他の種類のグループ通信セッションに関する実施形態であってよい。また、各実施形態はRTPパケットに関する実施形態であるが、本発明の他の実施形態が他の種類のメディアパケットに関するものであってよいことが理解されよう。たとえば、RealNetworksプロトコルに従って動作するシステムでは、RTPパケットの代わりにRDTパケットを使用してよい。言い換えれば、上述のように、各実施形態は概してEVRC-Aプロトコルに従った実装形態に関する実施形態であるが、本発明の他の実施形態では、離散フレームレートセットを有する他のボコーダ(たとえば、AMRなど)を使用してよい。
【０１７０】
当業者には、様々な異なる技術および技法のいずれかを使用して情報および信号を表してよいことが理解されよう。たとえば、上記の説明全体を通して参照される可能性があるデータ、命令、コマンド、情報、信号、ビット、記号、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光学場または光学粒子、あるいはそれらの組み合わせによって表されてもよい。
【０１７１】
また、当業者には、本明細書に開示された実施形態に関連して記載された様々な例示的な論理ブロック、モジュール、回路、アルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、またはその両方の組み合わせとして実現されてよいことが理解されよう。ハードウェアとソフトウェアをこのように交換可能であることを明確に示すために、上記では、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを概してその機能に関して説明した。そのような機能がハードウェアとして実施されるかそれともソフトウェアとして実施されるかは、特定の用途およびシステム全体に課される設計上の制約によって決まる。当業者は、上述の機能を各々の特定の用途に関して様々な方法で実施することができるが、そのような実装上の決定を本発明の範囲から逸脱させるものと解釈すべきではない。
【０１７２】
本明細書に開示された実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくはその他のプログラマブル論理デバイス、離散ゲート論理回路もしくは離散トランジスタ論理回路、離散ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組み合わせによって実施または実行されてよい。汎用プロセッサはマイクロプロセッサであってよいが、従来のプロセッサ、コントローラ、マイクロコントローラ、または状態マシンであってよい。プロセッサは、コンピューティングデバイス同士の組み合わせ、たとえば、DSPとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサの組み合わせ、1つまたは複数のマイクロプロセッサとDSPコアの組み合わせ、あるいはそのような任意の他の構成として実施されてもよい。
【０１７３】
本明細書で開示された各実施形態に関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで直接具体化されても、プロセッサによって実行されるソフトウェアモジュールで具体化されても、ハードウェアとソフトウェアモジュールの組み合わせで具体化されてもよい。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、取り外し可能なディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体に常駐してよい。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、かつ記憶媒体に情報を書き込むことができるようにプロセッサに結合される。あるいは、記憶媒体はプロセッサと一体であってよい。プロセッサと記憶媒体はASICに常駐してよい。ASICはユーザ端末(たとえば、アクセス端末)に常駐してよい。あるいは、プロセッサと記憶媒体は、ユーザ端末内の離散構成要素として常駐してよい。
【０１７４】
1つまたは複数の実施形態では、上述の機能が、ハードウェア、ソフトウェア、またはファームウェアで実現されても、あるいはそれらの任意の組み合わせで実現されてもよい。各機能は、ソフトウェアで実現される場合、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして記憶または送信されてよい。コンピュータ可読媒体は、コンピュータ記憶媒体と、コンピュータプログラムのある場所から他の場所への転送を容易にする任意の媒体を含む通信媒体との両方を含む。記憶媒体は、コンピュータによってアクセスできる利用可能な任意の媒体であってよい。制限ではなく一例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、またはその他の光学ディスクストレージ、磁気ディスクストレージまたはその他の磁気記憶デバイス、あるいは所望のプログラムコードを命令またはデータ構造の形態で保持または記憶するのに使用でき、かつコンピュータによってアクセスできる任意の他の媒体を備えてよい。また、任意の接続が適宜、コンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、撚り線対、デジタル加入者線(DSL)、または赤外線、無線、マイクロ波など無線技術を使用してウェブサイト、サーバ、またはその他のリモート送信元から送信される場合、同軸ケーブル、光ファイバケーブル、撚り線対、DSL、または赤外線、無線、マイクロ波など無線技術が媒体の定義に含められる。ディスク(diskおよびdisc)は、本明細書では、コンパクトディスク(CD)、レーザディスク、光学ディスク、デジタルバーサティルディスク(DVD)、フレキシブルディスク、およびブルーレイディスクを含み、この場合、diskは通常、データを磁気的に再生するディスクであり、一方、discはデータをレーザによって光学的に再生するディスクである。上記の組み合わせもコンピュータ可読媒体の範囲内に含まれるべきである。
【０１７５】
上記の開示は本発明の例示的な実施形態を示しているが、本明細書では、添付の特許請求の範囲によって定義される本発明の範囲から逸脱せずに様々な変更および修正が施されてよいことに留意されたい。本明細書に記載された本発明の実施形態による方法クレームの機能、ステップおよび/または動作を特定の順序で実行する必要はない。さらに、本発明の要素は単数形で記載または請求される場合があるが、単数形の限定が明示的に述べられていない限り複数形も考慮される。
【符号の説明】
【０１７６】
100 無線システム
102 携帯電話
104 無線インターフェース
108 パーソナルデジタルアシスタント
110 ページャ
112 コンピュータプラットフォーム
120 無線アクセスネットワーク
122 基地局コントローラ/パケット制御機能
124 基地局またはモデムプールトランシーバ
126 キャリアネットワーク
160 パケットデータサービスノード
165 ブロードキャストサービングノード
170 アプリケーションサーバ
172 メディアコンテントコンプレックスモジュール
175 インターネット
200 アクセス端末
202 プラットフォーム
208 特定用途向け集積回路
210 アプリケーションプログラミングインターフェース
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
226 キーパッド
228 プッシュトゥトークボタン
【特許請求の範囲】
【請求項１】
無線通信システム内のグループ通信セッション中にメディアを転送する方法であって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する段階と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する段階と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信する段階とを含む方法。
【請求項２】
前記受信段階は、リアルタイム転送プロトコル(RTP)パケットで前記第1の複数のアクセス端末の各々からの前記フレームを受信する、請求項1に記載の方法。
【請求項３】
1つまたは複数の前記RTPパケットは複数のフレームを含む、請求項2に記載の方法。
【請求項４】
前記第1の複数のアクセス端末は、前記グループ通信セッション用のメディアを送信するための下りリンクチャネルが割り当てられる各アクセス端末に相当し、前記第2の複数のアクセス端末は、前記選択された少なくとも1つのフレームが受信される前記アクセス端末または複数のアクセス端末を除く、前記グループ通信セッションに参加している各アクセス端末に相当する、請求項1に記載の方法。
【請求項５】
前記選択段階は、前記選択された少なくとも1つのフレームとして単一のフレームを選択する、請求項1に記載の方法。
【請求項６】
前記選択段階は、前記受信されたフレームの中に高データレートフレームが存在するかどうかを判定する段階を含む、請求項5に記載の方法。
【請求項７】
前記判定段階が、前記受信されたフレーム内に高データレートフレームは存在しないと判定した場合、前記選択段階は、所与の選択規則に従って選択を行う、請求項6に記載の方法。
【請求項８】
前記所与の選択規則は、前記グループ通信セッションに参加している第1の聞き手を選択する、請求項7に記載の方法。
【請求項９】
前記判定段階は、前記受信されたフレーム内に少なくとも1つの高データレートフレームが存在することを判定した場合、前記選択段階は、前記受信されたフレームの中から高データレートフレームの数を判定する段階をさらに含む、請求項6に記載の方法。
【請求項１０】
1つの高データレートフレームが存在すると判定された場合、前記選択段階は前記1つの高データレートフレームを選択する段階をさらに含む、請求項9に記載の方法。
【請求項１１】
前記選択段階は、
複数の高データレートフレームが存在すると判定された場合に、前記複数の高データレートフレームの中から最高のデータレートを有するフレームを選択するか、あるいは
複数のフレームが前記最高のデータレートを有する場合に、所与の選択規則に従って選択を行う段階をさらに含む、請求項9に記載の方法。
【請求項１２】
前記所与の選択規則は、前記複数のフレームのうちで、最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケットで受信されたフレームが選択される規則である、請求項11に記載の方法。
【請求項１３】
前記所与の選択規則は、前記複数のフレームのうちで、最高の優先順位レベルを有するアクセス端末から受信されたフレームを選択する、請求項11に記載の方法。
【請求項１４】
前記選択段階は、前記選択された少なくとも1つのフレームとして複数のフレームを選択する、請求項1に記載の方法。
【請求項１５】
前記選択段階は、
前記受信されたフレームの中に高データレートフレームが存在するかどうかを判定する段階を含む、請求項14に記載の方法。
【請求項１６】
前記判定段階が、前記受信されたフレーム内に高データレートフレームは存在しないと判定した場合、前記選択段階は、所与の選択規則に従って選択を行う、請求項15に記載の方法。
【請求項１７】
前記所与の選択規則は、前記グループ通信セッションに参加している前記第1の聞き手に相当する1組の聞き手が選択される規則である、請求項16に記載の方法。
【請求項１８】
前記判定段階は、前記受信されたフレーム内に少なくとも1つの高データレートフレームが存在することを判定した場合、前記選択段階は、前記受信されたフレームのうちの高データレートフレームの数を判定する段階をさらに含む、請求項15に記載の方法。
【請求項１９】
前記選択段階は、
1つの高データレートフレームが存在すると判定された場合、前記選択段階は前記1つの高データレートフレームを選択する段階をさらに含む、請求項18に記載の方法。
【請求項２０】
前記選択段階は、
所与の選択規則に従って、前記受信されたフレームの中から少なくとも1つの追加的なフレームを選択する段階をさらに含む、請求項19に記載の方法。
【請求項２１】
前記所与の選択規則は、前記受信されたフレームのうちで、最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケットで受信された1つまたは複数のフレームを選択する規則である、請求項20に記載の方法。
【請求項２２】
前記選択段階は、
複数の高データレートフレームが存在すると判定された場合に、前記複数の高データレートフレームの中から最高のデータレートを有するフレームを選択するか、あるいは
選択に必要な数よりも多くのフレームが前記最高のデータレートを有する場合に、所与の選択規則に従って、前記複数の高データレートフレームのうちで、前記最高のデータレートを有する所与の数のフレームを選択する段階をさらに含む、請求項19に記載の方法。
【請求項２３】
前記選択段階は、
複数の高データレートフレームよりも多くのフレームが選択に必要である場合に、他の所与の選択規則に基づいて、受信されたフレームから少なくとも1つの追加的なフレームを選択する段階をさらに含む、請求項22に記載の方法。
【請求項２４】
前記他の所与の選択規則は、前記受信されたフレームのうちで、前記複数の高データレートフレームに含まれず、かつ最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケットで受信された1つまたは複数のフレームを選択する規則である、請求項23に記載の方法。
【請求項２５】
前記所与の選択規則は、前記複数のフレームのうちで、最高の優先順位レベルを有するアクセス端末から受信された2つ以上のフレームを選択する、請求項22に記載の方法。
【請求項２６】
前記他の所与の選択規則は、前記複数のフレームのうちで、最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケット内の2つ以上のフレームを選択する規則である、請求項22に記載の方法。
【請求項２７】
前記第2の複数のアクセス端末はそれぞれ、フレームが選択されなかった各アクセス端末を含み、前記送信段階は、前記選択された複数のフレームの各フレームの組み合わせバージョンに相当する混合フレームを前記第2の複数のアクセス端末に送信する、請求項14に記載の方法。
【請求項２８】
前記グループ通信セッションを調停するサーバで利用可能な処理電力のレベルに基づいて、前記選択された複数のフレームを前記混合フレームを生成するようにデジタル処理する段階をさらに含む、請求項27に記載の方法。
【請求項２９】
同じ混合フレームが送信される前記第2の複数のアクセス端末の数に基づいて、前記選択された複数のフレームを前記混合フレームを生成するようにデジタル処理する段階をさらに含む、請求項27に記載の方法。
【請求項３０】
前記送信段階は、フレームが選択された各アクセス端末に、前記アクセス端末自体の選択されたフレームが省略されることを除いて同じ混合フレームを送信する、請求項27に記載の方法。
【請求項３１】
前記受信段階は、前記複数のアクセス端末の各々からの所与のパケットで前記複数のアクセス端末から前記フレームを受信し、前記所与の各パケットが、特定のアクセス端末の入力メディアフローに固有の1つまたは複数のメディアフローパラメータをヘッダ部に含む、請求項1に記載の方法。
【請求項３２】
前記出力ストリームの前記1つまたは複数のメディアフローパラメータが前記入力メディアフローに関する前記メディアフローパラメータと一致するかどうかにかかわらず、前記選択された少なくとも1つのフレームを保持するパケットのヘッダ部を、前記グループ通信セッションに関する出力メディアフローの前記1つまたは複数のメディアフローパラメータを含むように構成する段階をさらに含む、請求項31に記載の方法。
【請求項３３】
前記送信段階は、前記構成されたヘッダ部を有する前記パケットで前記選択された少なくとも1つのフレームを送信する、請求項32に記載の方法。
【請求項３４】
前記パケットはリアルタイム転送プロトコル(RTP)パケットに相当し、前記1つまたは複数のメディアフローパラメータは、送信元同期(SSRC)値フィールド、寄与送信元(CSRC)カウント値を保持する寄与カウント(CC)フィールド、および/またはタイムスタンプフィールド、および/またはシーケンス番号フィールドを含む、請求項32に記載の方法。
【請求項３５】
前記受信されたフレームから、前記選択された少なくとも1つのフレームとは異なる追加的なフレームを選択する段階をさらに含み、
前記選択段階は、前記選択された少なくとも1つのフレームからフレームを送信した前記第1の複数のアクセス端末の各々に前記選択された追加的なフレームを送信する段階を含む、請求項1に記載の方法。
【請求項３６】
無線通信システム内のグループ通信セッションを調停するように構成されたサーバであって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する手段と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する手段と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信する手段とを備えるサーバ。
【請求項３７】
前記受信手段は、リアルタイム転送プロトコル(RTP)パケットで前記第1の複数のアクセス端末の各々からの前記フレームを受信する、請求項36に記載のサーバ。
【請求項３８】
1つまたは複数の前記RTPパケットは複数のフレームを備える、請求項37に記載のサーバ。
【請求項３９】
前記第1の複数のアクセス端末は、前記グループ通信セッション用のメディアを送信するための下りリンクチャネルが割り当てられる各アクセス端末に相当し、前記第2の複数のアクセス端末は、前記選択された少なくとも1つのフレームが受信される前記アクセス端末または複数のアクセス端末を除く、前記グループ通信セッションに参加している各アクセス端末に相当する、請求項36に記載のサーバ。
【請求項４０】
前記選択手段は、前記選択された少なくとも1つのフレームとして単一のフレームを選択する、請求項36に記載のサーバ。
【請求項４１】
前記選択手段は、前記受信されたフレームの中に高データレートフレームが存在するかどうかを判定する手段を含む、請求項40に記載のサーバ。
【請求項４２】
前記判定手段が、前記受信されたフレーム内に高データレートフレームは存在しないと判定した場合、前記選択手段は、所与の選択規則に従って選択を行う、請求項41に記載のサーバ。
【請求項４３】
前記所与の選択規則は、前記グループ通信セッションに参加している第1の聞き手を選択する、請求項42に記載のサーバ。
【請求項４４】
前記判定手段は、前記受信されたフレーム内に少なくとも1つの高データレートフレームが存在することを判定した場合、前記選択手段は、
前記受信されたフレームの中から高データレートフレームの数を判定する手段をさらに含む、請求項41に記載のサーバ。
【請求項４５】
前記選択手段は、
1つの高データレートフレームが存在すると判定された場合、前記1つの高データレートフレームを選択することをさらに含む、請求項44に記載のサーバ。
【請求項４６】
前記選択手段は、
複数の高データレートフレームが存在すると判定された場合に、前記複数の高データレートフレームの中から最高のデータレートを有するフレームを選択するか、あるいは
複数のフレームが前記最高のデータレートを有する場合に、所与の選択規則に従って選択を行うことをさらに含む、請求項44に記載のサーバ。
【請求項４７】
無線通信システム内のグループ通信セッションを調停するように構成されたサーバであって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信するように構成された機能と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択するように構成された機能と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信するように構成された機能とを備えるサーバ。
【請求項４８】
コンピュータ可読媒体において、無線通信システム内のグループ通信セッションを調停するように構成されたサーバによって実行されたときに、前記サーバに動作を実行させる命令であって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する命令と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する命令と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信する命令とを含む命令を備えるコンピュータ可読媒体。
【請求項１】
無線通信システム内のグループ通信セッション中にメディアを転送する方法であって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する段階と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する段階と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信する段階とを含む方法。
【請求項２】
前記受信段階は、リアルタイム転送プロトコル(RTP)パケットで前記第1の複数のアクセス端末の各々からの前記フレームを受信する、請求項1に記載の方法。
【請求項３】
1つまたは複数の前記RTPパケットは複数のフレームを含む、請求項2に記載の方法。
【請求項４】
前記第1の複数のアクセス端末は、前記グループ通信セッション用のメディアを送信するための下りリンクチャネルが割り当てられる各アクセス端末に相当し、前記第2の複数のアクセス端末は、前記選択された少なくとも1つのフレームが受信される前記アクセス端末または複数のアクセス端末を除く、前記グループ通信セッションに参加している各アクセス端末に相当する、請求項1に記載の方法。
【請求項５】
前記選択段階は、前記選択された少なくとも1つのフレームとして単一のフレームを選択する、請求項1に記載の方法。
【請求項６】
前記選択段階は、前記受信されたフレームの中に高データレートフレームが存在するかどうかを判定する段階を含む、請求項5に記載の方法。
【請求項７】
前記判定段階が、前記受信されたフレーム内に高データレートフレームは存在しないと判定した場合、前記選択段階は、所与の選択規則に従って選択を行う、請求項6に記載の方法。
【請求項８】
前記所与の選択規則は、前記グループ通信セッションに参加している第1の聞き手を選択する、請求項7に記載の方法。
【請求項９】
前記判定段階は、前記受信されたフレーム内に少なくとも1つの高データレートフレームが存在することを判定した場合、前記選択段階は、前記受信されたフレームの中から高データレートフレームの数を判定する段階をさらに含む、請求項6に記載の方法。
【請求項１０】
1つの高データレートフレームが存在すると判定された場合、前記選択段階は前記1つの高データレートフレームを選択する段階をさらに含む、請求項9に記載の方法。
【請求項１１】
前記選択段階は、
複数の高データレートフレームが存在すると判定された場合に、前記複数の高データレートフレームの中から最高のデータレートを有するフレームを選択するか、あるいは
複数のフレームが前記最高のデータレートを有する場合に、所与の選択規則に従って選択を行う段階をさらに含む、請求項9に記載の方法。
【請求項１２】
前記所与の選択規則は、前記複数のフレームのうちで、最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケットで受信されたフレームが選択される規則である、請求項11に記載の方法。
【請求項１３】
前記所与の選択規則は、前記複数のフレームのうちで、最高の優先順位レベルを有するアクセス端末から受信されたフレームを選択する、請求項11に記載の方法。
【請求項１４】
前記選択段階は、前記選択された少なくとも1つのフレームとして複数のフレームを選択する、請求項1に記載の方法。
【請求項１５】
前記選択段階は、
前記受信されたフレームの中に高データレートフレームが存在するかどうかを判定する段階を含む、請求項14に記載の方法。
【請求項１６】
前記判定段階が、前記受信されたフレーム内に高データレートフレームは存在しないと判定した場合、前記選択段階は、所与の選択規則に従って選択を行う、請求項15に記載の方法。
【請求項１７】
前記所与の選択規則は、前記グループ通信セッションに参加している前記第1の聞き手に相当する1組の聞き手が選択される規則である、請求項16に記載の方法。
【請求項１８】
前記判定段階は、前記受信されたフレーム内に少なくとも1つの高データレートフレームが存在することを判定した場合、前記選択段階は、前記受信されたフレームのうちの高データレートフレームの数を判定する段階をさらに含む、請求項15に記載の方法。
【請求項１９】
前記選択段階は、
1つの高データレートフレームが存在すると判定された場合、前記選択段階は前記1つの高データレートフレームを選択する段階をさらに含む、請求項18に記載の方法。
【請求項２０】
前記選択段階は、
所与の選択規則に従って、前記受信されたフレームの中から少なくとも1つの追加的なフレームを選択する段階をさらに含む、請求項19に記載の方法。
【請求項２１】
前記所与の選択規則は、前記受信されたフレームのうちで、最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケットで受信された1つまたは複数のフレームを選択する規則である、請求項20に記載の方法。
【請求項２２】
前記選択段階は、
複数の高データレートフレームが存在すると判定された場合に、前記複数の高データレートフレームの中から最高のデータレートを有するフレームを選択するか、あるいは
選択に必要な数よりも多くのフレームが前記最高のデータレートを有する場合に、所与の選択規則に従って、前記複数の高データレートフレームのうちで、前記最高のデータレートを有する所与の数のフレームを選択する段階をさらに含む、請求項19に記載の方法。
【請求項２３】
前記選択段階は、
複数の高データレートフレームよりも多くのフレームが選択に必要である場合に、他の所与の選択規則に基づいて、受信されたフレームから少なくとも1つの追加的なフレームを選択する段階をさらに含む、請求項22に記載の方法。
【請求項２４】
前記他の所与の選択規則は、前記受信されたフレームのうちで、前記複数の高データレートフレームに含まれず、かつ最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケットで受信された1つまたは複数のフレームを選択する規則である、請求項23に記載の方法。
【請求項２５】
前記所与の選択規則は、前記複数のフレームのうちで、最高の優先順位レベルを有するアクセス端末から受信された2つ以上のフレームを選択する、請求項22に記載の方法。
【請求項２６】
前記他の所与の選択規則は、前記複数のフレームのうちで、最小または最大の送信元同期(SSRC)番号を有するリアルタイム転送プロトコル(RTP)パケット内の2つ以上のフレームを選択する規則である、請求項22に記載の方法。
【請求項２７】
前記第2の複数のアクセス端末はそれぞれ、フレームが選択されなかった各アクセス端末を含み、前記送信段階は、前記選択された複数のフレームの各フレームの組み合わせバージョンに相当する混合フレームを前記第2の複数のアクセス端末に送信する、請求項14に記載の方法。
【請求項２８】
前記グループ通信セッションを調停するサーバで利用可能な処理電力のレベルに基づいて、前記選択された複数のフレームを前記混合フレームを生成するようにデジタル処理する段階をさらに含む、請求項27に記載の方法。
【請求項２９】
同じ混合フレームが送信される前記第2の複数のアクセス端末の数に基づいて、前記選択された複数のフレームを前記混合フレームを生成するようにデジタル処理する段階をさらに含む、請求項27に記載の方法。
【請求項３０】
前記送信段階は、フレームが選択された各アクセス端末に、前記アクセス端末自体の選択されたフレームが省略されることを除いて同じ混合フレームを送信する、請求項27に記載の方法。
【請求項３１】
前記受信段階は、前記複数のアクセス端末の各々からの所与のパケットで前記複数のアクセス端末から前記フレームを受信し、前記所与の各パケットが、特定のアクセス端末の入力メディアフローに固有の1つまたは複数のメディアフローパラメータをヘッダ部に含む、請求項1に記載の方法。
【請求項３２】
前記出力ストリームの前記1つまたは複数のメディアフローパラメータが前記入力メディアフローに関する前記メディアフローパラメータと一致するかどうかにかかわらず、前記選択された少なくとも1つのフレームを保持するパケットのヘッダ部を、前記グループ通信セッションに関する出力メディアフローの前記1つまたは複数のメディアフローパラメータを含むように構成する段階をさらに含む、請求項31に記載の方法。
【請求項３３】
前記送信段階は、前記構成されたヘッダ部を有する前記パケットで前記選択された少なくとも1つのフレームを送信する、請求項32に記載の方法。
【請求項３４】
前記パケットはリアルタイム転送プロトコル(RTP)パケットに相当し、前記1つまたは複数のメディアフローパラメータは、送信元同期(SSRC)値フィールド、寄与送信元(CSRC)カウント値を保持する寄与カウント(CC)フィールド、および/またはタイムスタンプフィールド、および/またはシーケンス番号フィールドを含む、請求項32に記載の方法。
【請求項３５】
前記受信されたフレームから、前記選択された少なくとも1つのフレームとは異なる追加的なフレームを選択する段階をさらに含み、
前記選択段階は、前記選択された少なくとも1つのフレームからフレームを送信した前記第1の複数のアクセス端末の各々に前記選択された追加的なフレームを送信する段階を含む、請求項1に記載の方法。
【請求項３６】
無線通信システム内のグループ通信セッションを調停するように構成されたサーバであって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する手段と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する手段と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信する手段とを備えるサーバ。
【請求項３７】
前記受信手段は、リアルタイム転送プロトコル(RTP)パケットで前記第1の複数のアクセス端末の各々からの前記フレームを受信する、請求項36に記載のサーバ。
【請求項３８】
1つまたは複数の前記RTPパケットは複数のフレームを備える、請求項37に記載のサーバ。
【請求項３９】
前記第1の複数のアクセス端末は、前記グループ通信セッション用のメディアを送信するための下りリンクチャネルが割り当てられる各アクセス端末に相当し、前記第2の複数のアクセス端末は、前記選択された少なくとも1つのフレームが受信される前記アクセス端末または複数のアクセス端末を除く、前記グループ通信セッションに参加している各アクセス端末に相当する、請求項36に記載のサーバ。
【請求項４０】
前記選択手段は、前記選択された少なくとも1つのフレームとして単一のフレームを選択する、請求項36に記載のサーバ。
【請求項４１】
前記選択手段は、前記受信されたフレームの中に高データレートフレームが存在するかどうかを判定する手段を含む、請求項40に記載のサーバ。
【請求項４２】
前記判定手段が、前記受信されたフレーム内に高データレートフレームは存在しないと判定した場合、前記選択手段は、所与の選択規則に従って選択を行う、請求項41に記載のサーバ。
【請求項４３】
前記所与の選択規則は、前記グループ通信セッションに参加している第1の聞き手を選択する、請求項42に記載のサーバ。
【請求項４４】
前記判定手段は、前記受信されたフレーム内に少なくとも1つの高データレートフレームが存在することを判定した場合、前記選択手段は、
前記受信されたフレームの中から高データレートフレームの数を判定する手段をさらに含む、請求項41に記載のサーバ。
【請求項４５】
前記選択手段は、
1つの高データレートフレームが存在すると判定された場合、前記1つの高データレートフレームを選択することをさらに含む、請求項44に記載のサーバ。
【請求項４６】
前記選択手段は、
複数の高データレートフレームが存在すると判定された場合に、前記複数の高データレートフレームの中から最高のデータレートを有するフレームを選択するか、あるいは
複数のフレームが前記最高のデータレートを有する場合に、所与の選択規則に従って選択を行うことをさらに含む、請求項44に記載のサーバ。
【請求項４７】
無線通信システム内のグループ通信セッションを調停するように構成されたサーバであって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信するように構成された機能と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択するように構成された機能と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信するように構成された機能とを備えるサーバ。
【請求項４８】
コンピュータ可読媒体において、無線通信システム内のグループ通信セッションを調停するように構成されたサーバによって実行されたときに、前記サーバに動作を実行させる命令であって、
前記グループ通信セッションに参加している第1の複数のアクセス端末の各々から、各受信されたフレームが関連するデータレートを有する所与のタイムスロットのフレームを受信する命令と、
前記受信されたフレームの各々の関連するデータレートに少なくとも部分的に基づいて前記受信されたフレームのうちの少なくとも1つでありかつ全数よりも少ない数のフレームを選択する命令と、
前記選択された少なくとも1つのフレームを、前記グループ通信セッションに参加している第2の複数のアクセス端末に送信する命令とを含む命令を備えるコンピュータ可読媒体。
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図５Ｅ】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図５Ｅ】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１】
【公表番号】特表２０１２−５３３２２１（Ｐ２０１２−５３３２２１Ａ）
【公表日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願番号】特願２０１２−５１９６３０（Ｐ２０１２−５１９６３０）
【出願日】平成２２年７月２日（２０１０．７．２）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０４０９６９
【国際公開番号】ＷＯ２０１１／００５７０８
【国際公開日】平成２３年１月１３日（２０１１．１．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
【出願人】（５０７３６４８３８）クアルコム，インコーポレイテッド (446)
【Ｆターム（参考）】
【公表日】平成２４年１２月２０日（２０１２．１２．２０）
【国際特許分類】
【出願日】平成２２年７月２日（２０１０．７．２）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０４０９６９
【国際公開番号】ＷＯ２０１１／００５７０８
【国際公開日】平成２３年１月１３日（２０１１．１．１３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
【出願人】（５０７３６４８３８）クアルコム，インコーポレイテッド (446)
【Ｆターム（参考）】
[ Back to top ]