JP2012533265A

JP2012533265A - 無線通信システムにおけるグループ通信セッション中のメディアの選択的な混合

Info

Publication number: JP2012533265A
Application number: JP2012520729A
Authority: JP
Inventors: アブヒシェク・グプタ; アルヴィンド・ヴィ・サンタナム; ヴィディヤダール・カマット; ラジャン・ヴェルマ
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2009-07-13
Filing date: 2010-07-13
Publication date: 2012-12-20
Anticipated expiration: 2030-07-13
Also published as: CN102474513A; US9088630B2; KR101397266B1; US20110167104A1; EP2454865A1; CN102474513B; WO2011008789A1; JP5420073B2; KR20120042966A

Abstract

各実施形態は、通信グループのグループ通信セッションを調停するアプリケーションサーバでのメディアの選択的な混合に関する。一実施形態では、アプリケーションサーバは、グループ通信セッションの1人または複数のセッション参加者から、通信グループに送信されるメディアを受信する。アプリケーションサーバは、受信されたメディアを供給するセッション参加者の数を判定する。アプリケーションサーバは、判定された数に少なくとも部分的に基づいて、セッション参加者からのメディアをグループ通信セッション中にアプリケーションサーバによって混合されるようにキューに入れておくように構成されたデジッタバッファに受信されたメディアが入らないように受信されたメディアを迂回させるべきかどうかを判定する。たとえば、アプリケーションサーバは、この数がしきい数よりも小さい場合に、受信されたメディアをデジッタバッファに入らないように迂回させるべきであると判定することができる。アプリケーションサーバは、受信されたメディアを通信グループに送信する。

Description

35U.S.C.§119に基づく優先権の主張
本特許出願は、「SELECTIVITY MIXING MEDIA DURING A GROUP COMMUNICATION SESSION WITHIN A WIRELESS COMMUNICATIONS SYSTEM」という名称を有し、2009年7月13日に出願され、本出願の譲受人に譲渡され、引用によって本明細書に明示的に組み込まれる米国特許仮出願第61/225,130号の優先権を主張する。

同時係属特許出願の参照
本特許出願は、以下の同時係属米国特許出願、すなわち、「Media Forwarding For a Group Communication Session In A Wireless Communications System」という名称を有し、2009年7月10日に出願され、本出願の譲受人に譲渡され、引用によって本明細書に明示的に組み込まれる米国特許仮出願第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号に記載されているように、従来のシグナリング技術を使用するプッシュトゥトーク呼にブロードキャストチャネルを使用することができる。ブロードキャストチャネルを使用すると従来のユニキャスト技術と比べて帯域幅要件を改善することができるが、ブロードキャストチャネルの従来のシグナリングでは依然として追加的なオーバヘッドおよび/または遅延が発生することがあり、システム性能が低下する可能性がある。

3^rd 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の無線通信の例を詳しく示す図である。本発明の一実施形態によるアプリケーションサーバを示す図である。本発明の少なくとも1つの実施形態によるアクセス端末の図である。従来の半二重グループ通信セッションプロセスを示す図である。従来の全二重グループ通信セッションプロセスを示す図である。図4Aおよび/または図4Bにおけるアプリケーションサーバで実行される従来の混合プロセスを示す図である。図4Cのプロセスの実装例を示す図である。図4Cのプロセスの実装例を示す図である。本発明の一実施形態によるアプリケーションサーバで実行される選択的な混合プロセスを示す図である。本発明の一実施形態による図5Bのプロセスの実装例を示す図である。

本発明の特定の実施形態に関する以下の説明および関連する図面に本発明の各態様が開示されている。本発明の範囲から逸脱せずに他の実施形態が考案されてよい。また、本発明の公知の要素については、本発明の関連する細部を曖昧にしないように詳しく説明しないかあるいは省略する。

「例示的な」および/または「例」という用語は、本明細書では、「一例または例示として働くこと」を意味するのに使用される。本明細書で「例示的な」および/または「例」として記載される実施形態が必ずしも他の実施形態と比べて好ましいかあるいは有利であるとみなされるわけではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、本明細書で述べられる特徴、利点、または動作モードを含むことを必要とするわけではない。

また、多くの実施形態は、たとえばコンピューティングデバイスの要素によって実行すべき動作のシーケンスに関して記載されている。本明細書に記載された様々な動作を特定の回路(たとえば、特定用途向け集積回路(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は、パケットデータサービスノード100(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の両方の機能を有する単一の「ハイブリッド」モジュールに組み込まれてよい。

図2Aは、本発明の一実施形態によるキャリアネットワーク126を示している。図2Aの実施形態では、キャリアネットワーク126は、パケットデータサービングノード(PDSN)160と、ブロードキャストサービングノード(BSN)165と、アプリケーションサーバ170と、インターネット175とを含む。しかし、他の実施形態では、アプリケーションサーバ170およびその他の構成要素はキャリアネットワークの外部に配置されてよい。PDSN160は、たとえば、cdma2000無線アクセスネットワーク(RAN)(たとえば、図1のRAN120)を利用する移動局(たとえば、図1の102、108、110、112などのアクセス端末)に対して、インターネット175、イントラネット、および/またはリモートサーバ(たとえば、アプリケーションサーバ170)にアクセスするのを可能にする。PDSN160は、アクセスゲートウェイとして働き、単純なIPアクセスおよび移動IPアクセス、フォーリンエージェントのサポート、およびパケット転送を実行することができる。PDSN160は、当技術分野で公知のように、Authentication, Authorization, and Accounting(AAA)サーバおよびその他のサポートインフラストラクチャ用のクライアントとして働くことができ、移動局に対してIPネットワークへのゲートウェイを実現する。図2Aに示されているように、PDSN160は、従来のA10接続を介してRAN120(たとえば、BSC/PCF122)と通信することができる。A10接続は当技術分野で公知であり、説明を簡潔にするためにA10接続についてはこれ以上説明しない。

図2Aを参照すると、ブロードキャストサービングノード(BSN)165は、マルチキャストサービスおよびブロードキャストサービスをサポートするように構成されてよい。BSN165については以下に詳しく説明する。BSN165は、ブロードキャスト(BC)A10接続を介してRAN120(たとえば、BSC/PCF122)と通信し、インターネット175を介してアプリケーションサーバ170と通信する。BCA10接続は、マルチキャストメッセージおよび/またはブロードキャストメッセージを転送するのに使用される。したがって、アプリケーションサーバ170は、インターネット175を介してPDSN160にユニキャストメッセージを送信し、インターネット175を介してBSN165にマルチキャストメッセージを送信する。

一般に、以下に詳しく説明するように、RAN120は、BCA10接続を介してBSN165から受信されたマルチキャストメッセージを無線インターフェース104のブロードキャストチャネル(BCH)上で1つまたは複数のアクセス端末200に送信する。

図2Bは、図1の無線通信100の一例を詳しく示している。特に、図2Bを参照すると、AT1...ATNは、様々なパケットデータネットワークエンドポイントがサービスの対象とする位置でRAN120に接続されるように示されている。したがって、AT1およびAT3は、第1のパケットデータネットワークエンドポイント162(たとえば、PDSN160、BSN165、フォーリンエージェント(FA)、ホームエージェント(HA)などに相当するエンドポイントであってよい)がサービスの対象とする部分でRAN120に接続されている。第1のパケットデータネットワークエンドポイント162は、ルーティングユニット188を介して、インターネット175に接続され、かつ/あるいはauthentication, authorization, and accounting(AAA)サーバ182、プロビジョニングサーバ184、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)/セッション開始プロトコル(SIP)登録サーバ186、および/またはアプリケーションサーバ170のうちの1つまたは複数に接続されている。AT2およびAT5...ATNは、第2のパケットデータネットワークエンドポイント164(たとえば、PSDN160、BSN165、FA、HAなどに相当するエンドポイントであってよい)のサービスの対象となる部分でRAN120に接続されている。第1のパケットデータネットワークエンドポイント162と同様に、第2のパケットデータネットワークエンドポイント164は、ルーティングユニット188を介して、インターネット175に接続され、かつ/あるいはAAAサーバ182、プロビジョニングサーバ184、IMS/SIP登録サーバ186、および/またはアプリケーションサーバ170のうちの1つまたは複数に接続されている。AT4は、インターネット175に直接接続されており、さらにインターネット175を通じて上述のシステム構成要素のいずれかに接続することができる。

図2Bを参照すると、AT1、AT3、およびAT5...ATNは無線携帯電話として示され、AT2は無線タブレットPCとして示され、AT4は有線デスクトップステーションとして示されている。しかし、他の実施形態では、無線通信システム100を任意の種類のATに接続することができ、かつ図2Bに示されている例が、システム内で実現できるATの種類を限定するものではないことが理解されよう。また、AAAサーバ182、プロビジョニングサーバ184、IMS/SIP登録サーバ186、およびアプリケーションサーバ170はそれぞれ、構造的に分離されたサーバとして示されているが、本発明の少なくとも1つの実施形態では、これらのサーバの1つまたは複数が統合されてよい。

また、図2Bを参照すると、アプリケーションサーバ170は、複数のメディア制御コンプレックス(MCC)1...N 170Bと複数の地域ディスパッチャ1...N 170Aとを含むように示されている。地域ディスパッチャ170AとMCC170Bは全体として、少なくとも1つの実施形態では、集合的に無線通信システム100内の通信セッション(たとえば、IPユニキャスティングプロトコルおよび/またはIPマルチキャスティングプロトコルを介した半二重グループ通信セッション)を調停するように機能するサーバの分散ネットワークに相当するサーバであってよいアプリケーションサーバ170内に含められている。たとえば、アプリケーションサーバ170によって調停される通信セッションは、理論的には、システム100内のあらゆる場所に位置するAT間で行われる可能性があるため、調停される通信セッションのレイテンシを短縮するように(たとえば、北米のMCCが中国に位置するセッション参加者同士の間のメディアのやり取りを中継することがないように)複数の地域ディスパッチャ170AおよびMCCが分散されている。したがって、アプリケーションサーバが参照されるときは、関連する機能を1つもしくは複数の地域ディスパッチャ170Aおよび/または1つもしくは複数のMCC170Bによって実行できることが理解されよう。地域ディスパッチャ170Aは一般に、通信セッションの確立に関する機能に責任を負い(たとえば、AT同士の間の信号メッセージの処理、アナウンスメッセージのスケジューリングおよび/または送信など)、一方、MCC170Bは、調停される通信セッションの間に通話中シグナリングおよびメディアの実際の交換を実施することを含め、呼インスタンスの持続時間の間通信セッションをホスティングする責任を負う。

図2Cは、本発明の一実施形態によるアプリケーションサーバ170を示している。図2Cに示されているように、アプリケーションサーバ170は、図2Bと同様にMCC1...MCCN 170Bを含んでいる。図2Cは、MCC170Bのうちの1つ(「MCC1」)の構成要素を詳しく示している。したがって、図2CのMCC1は、コントローラ172Aと、デジッタバッファ172Bと、ミキサ172Cとを含むように示されている。一般に、コントローラ172Aは、MCC1の上位動作を制御し、デジッタバッファ172Bは、ミキサ172Cによって混合されるフレームをキューに入れる責任を負い、ミキサ172Cは、様々なATからのメディアフレームを実際に混合するか、あるいは単一の入力フレームを、MCC170Bから通信グループに送信される出力ストリームと互換性のあるフォーマットに変換する責任を負う。MCC1の構成要素は集合的に、グループ通信セッションの1人または複数の参加者からフレームを受信し、適切な出力ストリームを各セッション参加者に転送するように働く。一般に、このことは、MCC1で様々なセッション参加者から受信された各フレームを組み合わせるかあるいは「混合」し、次いで混合バージョンをセッション参加者に転送することを意味する。理解されるように、ミキサ172Cは、所与のユーザの発話がそのユーザに再送されないように、各ターゲット自体の入力ストリームをそのターゲットに転送される出力ストリームから取り消すかあるいは除去することもできる。MCC1およびそのそれぞれの構成要素の機能について、以下に本発明の実施形態に関して詳しく説明する。

図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)170Bモジュールを含む。言い換えれば、MCCモジュール170Bは、RTPパケット内のフレームを複製してATAからATB...ATEの各々に再ブロードキャストする。したがって、アプリケーションサーバ170のMCCモジュール170Bで受信された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モジュール170Bは、上記でTable 2(表2)に示されているように入力ストリームを受信し、ATA...ATEに送信される出力ストリームを生成または変換する。したがって、Table 2(表2)に基づいて、アプリケーションサーバ170のMCCモジュール170Bによって生成される出力ストリームは以下のように構成されてよい。

Table 3(表3)(上記)に示されているように、出力ストリームは、ATAのフレーム送信がATAに送り返されるのではなく、上記のTable 2(表2)においてATB...ATEに送信されるように構成される。

出力ストリームはMCCモジュール170Bによって生成されるため、アプリケーションサーバ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モジュール170Bによって出力ストリームに変換され、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モジュール170Bで受信される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モジュール170Bは、上記にTable 5(表5)(上記)に示されているようにATA...ATEからフレームを受信し(すなわち、入力ストリーム)、次にATA...ATEに送信される出力ストリームを生成または変換する(たとえば、各出力ストリームは、フィードバックを低減させるために、ターゲットから受信された入力ストリームのフレームを省略するため、それぞれ異なる)。したがって、Table 5(表5)(上記)に基づいて、タイムスロット10t...T上でアプリケーションサーバ170のMCCモジュール170Bによって生成される出力ストリームは以下のように構成されてよい。

Table 6(表6)(上記)に示されているように、グループ通信セッションが簡略的なブルートフォース転送実装形態であるため、出力ストリームの各タイムスロットにおけるATA...ATEへの集結されたメディアフレームは、そのAT自体以外のATからのフレーム(または、たとえばRTPパケット)のデータレートの和に等しい総データレートを有する。

図4Aのグループ通信セッションに関する従来の半二重実装形態に関しては、帯域幅使用率が図4Aのグループ通信セッションに関する全二重実装形態と比べて優れていることが理解されよう。しかし、ATがグループへの送信を行うことができないことが問題になることもある(たとえば、現在のフロアホルダがフロアを放棄せず、関連のない話題に関して話している場合)。半二重では、現在のフロアホルダは、フロアが解放されるまで他のグループメンバからフィードバックを受信することができないためグループの感情に気付かない。

この問題は、図4Bの全二重実装形態では生じない。しかし、グループ通信セッション参加者がN人である場合、各参加者が、組み合わされたN-1個のメディアフローを有する集結された出力ストリームを受信し、それによって、比較的大量の帯域幅が消費されるため、全二重実装形態の帯域幅要件は高い。また、多数のメディアフレームを集結して出力ストリームのメディアフレームを形成することは、アプリケーションサーバ170における集中的な処理になることがある。また、アプリケーションサーバ170のMCCモジュール172は、メディアフロー同士を区別しない。したがって、各フレームが出力ストリーム内の同じタイムスロットを求めて競合するとき、無音フレームには出力フレーム中のデータフレームと同じ優先順位が与えられる。

図4Cは、図4Aの430、図4Aの475、および/または図4Bの440Bの各送信段階の間にアプリケーションサーバ170で実行されるプロセスを詳しく示している。図4Cを参照すると、アプリケーションサーバ170は、ATのグループに送信される1つまたは複数のフレームを受信する(400C)。たとえば、図4Aの430で、アプリケーションサーバ170は、図4Aの425でATAから送信されたフレームを受信し、図4Aの475で、図4Aの470でATBから送信されたフレームを受信する。他の例では、図4Bの440Bで、アプリケーションサーバ170は、図4Bの425Bと435Bの間にATA...ATEの各ATから送信されたフレームを受信する。

サーバが調停するグループ通信セッションのメディア交換を処理する特定のMCC170Bのコントローラ172Aは、400Cで各フレームを受信した後、400Cで受信された各フレームを関連するATのデジッタバッファ172B内の対応するキューに加える(405C)。ミキサ172Cは、準備が整うと、特定のタイムスロットについてデジッタバッファ172Bのそれぞれのキューから1つまたは複数のフレームを取り出し、これらのフレームに対して混合動作を実行する(410C)。半二重の場合、通常、1つのATのみ(たとえば、現在のフロアホルダ)からのフレームが存在し、したがって、メディアの混合を実際に実行する必要はなく、デジッタバッファを使用する必要がなく、受信されたままのフレームをヘッダ修正を施すことなくMCC170Bから転送するだけでよい。したがって、図4Cは主として、全二重セッションに関して実行されるプロセスに関する図である。全二重の場合、通常、複数のATからのフレームが存在し(ただし、たとえば、タイムスロット当たりに各ATからのフレームが存在する必要はない)、したがって、ミキサ172Cは、当技術分野で公知のように、特定のタイムスロットについての各フレーム内の実際のメディア、すなわち、ペイロード部を混合する。理解されるように、全二重では、セッション中の発話の大部分が1人のセッション参加者によるものであるときなどに、半二重と同様に、ある期間にわたって1つのATのみからフレームが受信されることもあり得る。しかし、全二重セッション中に単一のフレームが受信されたときでも、デジッタバッファ172Bは複数のフレームが受信されたときのように使用され、したがって、この場合もデジッタバッファ172Bに関連する遅延が生じる。410Cでフレームが混合された後、コントローラ172Aは、混合されたフレームをグループに送信させる。

図4Dおよび4Eは、図4Cのプロセスの実装例を示している。特に、図4Dは、図4Bと同様にATA...ATEの各々が各タイムスロットの間にフレームを送信する全二重セッション実装例を示し、図4Eは、ある期間にわたる各タイムスロットの間にAT1のみがフレームを送信する実装例(たとえば、この期間にわたる発話のすべてがATAによるものである全二重セッション)を示している。

図4Dを参照すると、グループ通信セッションの調停を処理するアプリケーションサーバ170のMCC170Bで、ATA...ATEの各ATからデータストリーム(たとえば、一連のフレーム)が受信される(400C)。コントローラ172Aは、400Cで受信された各フレームを関連するATのデジッタバッファ172B内のキューに加える(405C)。図4Dに示されているように、ATA...ATEの各ATのキューは、ミキサ172Cによる処理または混合を受けるために待機しているいくつかのフレーム(たとえば、これらのフレームの送信元の対応するATの文字によって示されている)を示している。所与のタイムスロットのフレームがそれぞれのキューの1番上に到着すると、コントローラ172Aは、デジッタバッファ172B内のキューからこれらのフレームを取り出し、これらのフレームをミキサ172Cに送信して混合させる(410C)。このため、ミキサ172Cは、410Cで、所与のタイムスロットについてのATA...ATEの各ATからのフレームを混合する。次に、コントローラ172Aは、混合されたフレームをグループ通信セッションの各セッション参加者に送信させる(415C)。図4Dに示されているように、各ATに送信される混合フレームは、他の各ATからのメディアを含み、したがって、ATAに送信される混合フレームはATB+ATC+ATD+ATEからのフレームを含み、ATBに送信される混合フレームは、ATA+ATC+ATD+ATEからのフレームを含み、ATCに送信される混合フレームはATA+ATB+ATD+ATEからのフレームを含み、ATDに送信される混合フレームは、ATA+ATB+ATC+ATEからのフレームを含み、ATEに送信される混合フレームは、ATA+ATB+ATC+ATDからのフレームを含む。

図4Eを参照すると、全二重グループ通信セッションの調停を処理するアプリケーションサーバ170のMCC170Bで、ATAのみからデータストリーム(たとえば、一連の音声フレームまたは高データレートフレーム)が受信される(400C)。上述のように、1つのATのみ(たとえば、この場合はATA)からフレームが受信されるのは、グループに送信される音声メディアを送信しているATが1つだけである全二重セッション中の期間に生じる可能性がある。理解されるように、MCC170BでATB...ATEに含まれる1つまたは複数の他のATから他のフレームを受信することができるが、これらのフレームは、図4Eではノイズフレームまたは無音フレーム(たとえば、低データレートフレーム)に相当するフレームと仮定されており、コントローラ170Aは、そのようなフレームを破棄し、そのようなフレームをデジッタバッファ172Bにおけるキューに加えないように構成されている。コントローラ172Aは、400Cで受信された各フレームを関連するAT(すなわち、ATA)のデジッタバッファ172B内のキューに加える(たとえば、受信された各音声フレームまたは高データレートフレームをキューに加え、一方、ノイズフレームおよび/または無音フレームを除外することを意味する)(405C)。図4Eに示されているように、ATAのキューは、ミキサ172Cによる処理または混合を受けるために待機しているいくつかのフレーム(たとえば、ATAのキュー内に文字「A」で示されている)を示し、一方、ある期間にわたってATB...ATEから音声パケットが受信されていないことが想定されるためATB...ATEのキューはそれぞれ空である。所与のタイムスロットにおけるATAのフレームがATAのキューの1番上に到着すると、コントローラ172Aは、デジッタバッファ172B内のキューからこのフレームを取り出し、このフレームをミキサ172Cに送信して混合させる(410C)。このため、ミキサ172Cは、410Cで、所与のタイムスロットに関するATAからのフレームに対して混合動作を実行する。この場合、ミキサ172Cによって実行される混合動作は、出力フレームのRTPヘッダが出力ストリームに適切なヘッダになるように、入力フレーム内のメディアをフォーマットする(たとえば、ATAの入力ストリームにおけるシーケンス番号が、出力ストリーム内の次のフレームの正しいシーケンス番号に対応するように修正される)ことに相当する。次に、コントローラ172Aは、混合された(あるいは、この場合は、フォーマットされた)フレームをグループ通信セッションの1人または複数のセッション参加者に送信させる(415C)。図4Eに示されているように、各ATに送信される混合フレームは、このタイムスロットに関するフレームを送信する他の各ATからのメディアを含む。この場合、現在のタイムスロットに関するフレームを送信しているのはATAだけであるため、ATB...ATEの各ATに送信されるフォーマット済みフレームはATAのフレームのみを含み、ATAにはヌルフレーム(たとえば、メディアを含まないフレーム)を送信することができる。あるいは、図4Eには示されていないが、ヌルフレームの代わりに、415CでATAにフレームを送信しなくてもよい。

当業者には理解されるように、図4Dに示されているように410Cにおいてミキサ172Cで実行される複数のフレームからのメディアの混合は、比較的処理集約的な混合であり、場合によっては、フレームをデジッタバッファ172B内のキューに入れる必要が生じる。したがって、ミキサ172Cは一般に、複数のフレームからのメディアをただちに、すなわちリアルタイムで混合する際に適切な性能を確実に発揮することができず、そのため、ミキサ172Cは、各フレームをキューに入れ、各タイムスロットに関する混合を順に処理する。デジッタバッファ172Bのサイズを大きくすると、出力ストリーム内の各フレームの音声品質が向上する。ただし、デジッタバッファ172Bのサイズを過度に大きくすると、出力ストリームで時間差が生じる。

一方、図4Eの410Cに示されているようにミキサ172Cで特定のタイムスロットに関する1つのフレームを再パッケージまたはフォーマットする混合動作は、図4Dの多重メディアフレーム混合ほど処理集約的な動作ではない。したがって、このようなフォーマットをデジッタバッファ172Bを使用せずにリアルタイムに実行することが可能である。しかし、(たとえば、図4Dに示されている全二重セッションのように)場合によっては単一のタイムスロットの間に複数の多重メディアフレームを混合する従来のグループ通信セッションは、このタイムスロットに関して混合されるフレームの数にかかわらず各フレームをデジッタバッファ172B内のキューに入れる。

したがって、本発明の各実施形態は各フレームを選択的にデジッタバッファ172B内のキューに入れることに関する。以下に図5Aおよび5Bに関して論じるように、所与のタイムスロットに関して混合すべきフレームの数がフレームのしきい数より大きい(たとえば、1よりも大きい)場合、各フレームはデジッタバッファ172B内にキューに加えられる。しかし、混合すべきフレームの数が連続する所与の数のタイムスロット(たとえば、3つのタイムスロット、6つのタイムスロットなど)における各タイムスロットに関するフレームのしきい数(たとえば、1つのフレーム)以下である場合、少なくとも、特定のタイムスロットにおいて混合すべきフレームの数がしきい数を超えるまで、混合すべき以後のフレームが(たとえば、RTPヘッダをフォーマットまたは再パッケージするために)ミキサ172Cに直接送られるように、デジッタバッファ172Bは迂回される。このように、ミキサ172Cによってより集約的な処理が使用されることが予想されないときには、少なくともタイムスロットの間デジッタバッファ172Bに関連する遅延を抑制することができる。

図5Aは、本発明の一実施形態によるアプリケーションサーバ170のMCC170Bで実行される選択的な混合プロセスを示している。一例として、図5Aのプロセスは、図4Aの430、図4Aの475、および/または図4Bの440Bの各送信段階の間に実施されてよい。図5Aを参照すると、アプリケーションサーバ170は、ATのグループに送信される1つまたは複数のフレームを受信する(500A)。たとえば、図4Aの430で、アプリケーションサーバ170は、図4Aの425でATAから送信されたフレームを受信し、図4Aの475で、図4Aの470でATBから送信されたフレームを受信する。たとえば、図4Bの440Bで、アプリケーションサーバ170は、図4Bの425Bと435Bの間にATA...ATEの各ATから送信されたフレームを受信する。

500Cでフレームの各々を受信したとき、サーバが調停するグループ通信セッションのメディア交換を処理する特定のMCC170Bのコントローラ172Aは、現在発話していると考えられるグループセッション参加者の数を判定する(505A)。たとえば、505Aの判定は、500Aで受信されたフレームの中に非無音フレーム(たとえば、データレートが1/8よりも高いフレームなど)はいくつあるかに相当する判定であってよい。510Aで、コントローラ172Aは、505Aで判定された数が所与の数のタイムスロット(たとえば、1つのタイムスロット、デジッタバッファ172B内のキューの深さと等しい数のタイムスロット、デジッタバッファ172B内のキューの深さよりも大きい数のタイムスロットなど)に関する所与のしきい値よりも大きいかどうかを判定する。この数が、所与の数のタイムスロットに関するしきい値よりも大きい場合、プロセスは、概して図4Cのそれぞれ405C、410C、および415Cに対応する515A、520A、および525Aに進む。したがって、説明を簡潔にするために、515A、520A、および525Aについてはこれ以上説明しない。しかし、上記に410Cに関して説明した特定の混合例が、考えられる混合方法の非制限的な例として示されており、かつ本発明の他の実施形態において通信セッション中に複数のフレームのメディアを混合することのできるいくつかの方法があることが理解されよう。525Aの後で、プロセスは、図5Aの500Aに戻り、以後のタイムスロットについて実行される。

510Aに戻り、非無音フレームの数がしきい値以下である場合、コントローラ172Aは、デジッタバッファ172B全体を迂回すべきであると判定する(530A)。530Aで、デジッタバッファ172Bの1つまたは複数のキューが、ミキサ172Cによる混合を受けるために待機しているフレームを含んでよいことが理解されよう。この場合、一例として、「混合」モードから「転送」モードまたは「デジッタバッファ迂回」モードへの切り替え時に、コントローラ172Aは、キューに入っているパケットまたはフレームを必要に応じて(たとえば、混合を施さずに)フォーマットすることができ(たとえば、以下の535Aの説明を参照されたい)、次に、キューに入っておりグループに送信される各パケットを転送する(たとえば、以下の540Aの説明を参照されたい)。一例として、話し手の数がしきい値よりも小さい期間が、デジッタバッファ172Bのキューの深さよりも長くならない限り、決定ブロック510Aの評価が「N」にならない場合、デジッタバッファ172Bが、キューに入っている1つの特定のATからのフレームのみを含み、したがって、転送される各フレームが同じATからのフレームであるため、決定ブロック510Aの判定が「N」になったときのデジッタバッファ172Bの「破棄」をジッタなしで実行できることが理解されよう。デジッタバッファ172B内のキューが除去されると、プロセスは535Aに進む。

530Aに戻ると、デジッタバッファ172Bの迂回が、このプロセス中にはいかなるバッファも使用されないことを意味するものではなく、(たとえば、少なくともこの特定のタイムスロットについては)デジッタバッファ172Bが使用されないことを意味するに過ぎないことが理解されよう。この場合でも、着信メッセージがMCC170Bで受信されたときに単にこのようなメッセージを保持する一時記憶バッファのような他のバッファをアプリケーションサーバ170での一時的な記憶に使用してよい。コントローラ172Aは、535Aで、受信されたメッセージをミキサ172Cに送り、ミキサ172Cは、500Aで受信されたフレームのヘッダを出力ストリームフレームのヘッダと一致するように修正する(たとえば、フォーマットおよび/または再パッケージを施す)。上述のように、この場合、出力ストリームに使用されるRTPパケットのヘッダの1つまたは複数のフィールドが予想されるシーケンス番号と一致するように変更されることなどが実行される場合がある。コントローラ172Aは次いで、フォーマット済みのフレームをグループ通信セッションの1人または複数のセッション参加者に送信させる(540A)。

図4Eと同様な図5Bを参照すると、グループ通信セッションの調停を処理するアプリケーションサーバ170のMCC170Bで、ATAのみからデータストリーム(たとえば、一連の音声フレームまたは高データレートフレーム)が受信される(ただし無音フレームまたはノイズフレームを依然として他のATから受信し、コントローラ172Aによって破棄することができる)(500A)。上述のように、1つのATのみ(たとえば、この場合はATA)からフレームが受信されるフレームは、全二重セッションまたはハイブリッド全二重セッション(たとえば、2人以上の参加者が同時に発話することができ、その間他の参加者はそれを聞いているだけである)中の、グループに送信される音声メディアを送信しているATが1つだけである期間に相当する。コントローラ172Aは、この特定のタイムスロットにおいて発話しているグループセッション参加者の数を1人と判定し(505A)、次に、話し手の数(すなわち、1)が話し手しきい値以下であると判定する(510A)。図5Bに示されているように、話し手の数は、迂回動作をトリガするのに十分な時間の間話し手しきい値よりも小さいと仮定されてよい。したがって、コントローラ172Aは、ATAから受信されたフレームをデジッタバッファ172Bを迂回させ(530A)、それによって、フレームを再フォーマットされるようにミキサ172Cに送信する(535A)。このため、ミキサ172Cは、535Aで、所与のタイムスロットについてのATAからのフレームを再フォーマットし、それによって、ATAのフレームは、出力フレームのRTPヘッダが出力フレームに適切なヘッダになるようにフォーマットされる(たとえば、ATAの入力ストリームにおけるシーケンス番号が、出力ストリーム内の次のフレームの正しいシーケンス番号に修正される)。次に、コントローラ172Aは、フォーマット済みのフレームをATB...ATEに送信させる。図5Bに示されているように、各ATに送信されるフォーマット済みのフレームは、そのタイムスロットに関するフレームを送信する他の各ATからのメディアを含む。この場合、現在のタイムスロットに関するフレームを送信しているのがATAだけであるため、ATB...ATEの各ATに送信されるフォーマット済みフレームはATAのフレームのみを含み、ATAにはヌルフレーム(たとえば、メディアを含まないフレーム)を送信することができる。あるいは、図5Bには示されていないが、ヌルフレームの代わりに、540AでATAにフレームを送信しなくてもよい。

理解されるように、デジッタバッファ172Bをタイムスロットごとに選択的に使用すると、集約的な処理を必ずしも必要としないタイムスロットを、デジッタバッファ172Bを迂回させつつミキサ172Cに直接送信することが可能になり、グループ通信セッションの少なくともいくつかのタイムスロットの間デジッタバッファ172Bに伴う遅延が回避されることによってグループ通信セッションの性能を向上させることができる。また、混合プロセス中にパケットを再符号化する必要がないため、デジッタバッファ172Bを迂回する再フォーマット済みパケットの音声品質を向上させることができる。

本発明の上述の実施形態は概して、全二重セッション中のフレームの選択的な混合に関する実施形態であるが、同じ一般的な教示をハイブリッド全二重実装形態に適用するにはどうすればよいかが理解されよう。ハイブリッド全二重セッションでは、2人以上の参加者が同時に発話することができ、その間他の参加者はそれを聞いているだけである。したがって、ある期間にわたるハイブリッド全二重セッションの間に、しきい数よりも少ない数(たとえば、1人)の話し手が所与の期間にわたって発話するときはいつでも、デジッタバッファ迂回手順を呼び出して、ハイブリッド全二重セッションを調停するMCC170Bにおけるリソースを節約することができる。

当業者には、様々な異なる技術および技法のいずれかを使用して情報および信号を表してよいことが理解されよう。たとえば、上記の説明全体を通して参照される可能性があるデータ、命令、コマンド、情報、信号、ビット、記号、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光学場または光学粒子、あるいはそれらの組み合わせによって表されてもよい。

また、当業者には、本明細書に開示された実施形態に関連して記載された様々な例示的な論理ブロック、モジュール、回路、アルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、またはその両方の組み合わせとして実現されてよいことが理解されよう。ハードウェアとソフトウェアをこのように交換可能であることを明確に示すために、上記では、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを概してその機能に関して説明した。そのような機能がハードウェアとして実施されるかそれともソフトウェアとして実施されるかは、特定の用途およびシステム全体に課される設計上の制約によって決まる。当業者は、上述の機能を各々の特定の用途に関して様々な方法で実施することができるが、そのような実装上の決定を本発明の範囲から逸脱させるものと解釈すべきではない。

本明細書に開示された実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(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 アプリケーションサーバ
170B MCC
172 メディアコンテントコンプレックスモジュール
172A コントローラ
172B デジッタバッファ
172C ミキサ
175 インターネット
200 アクセス端末
202 プラットフォーム
208 特定用途向け集積回路
210 アプリケーションプログラミングインターフェース
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
226 キーパッド
228 プッシュトゥトークボタン

Claims

通信グループのグループ通信セッションを調停するアプリケーションサーバでメディアを選択的に混合する方法であって、
前記グループ通信セッションの1人または複数のセッション参加者から、前記通信グループに送信されるメディアを受信する段階と、
前記受信されたメディアを供給するセッション参加者の数を判定する段階と、
前記判定された数に少なくとも部分的に基づいて、セッション参加者からのメディアを前記グループ通信セッション中に前記アプリケーションサーバによって混合されるようにキューに入れておくように構成されたデジッタバッファに前記受信されたメディアが入らないように前記受信されたメディアを迂回させるべきかどうかを判定する段階と、
前記受信されたメディアを前記通信グループに送信する段階とを含む方法。
前記受信されたメディアを迂回させるべきかどうかを判定する段階は、
前記判定された数をしきい数と比較する段階と、
前記比較に基づいて、判定された数が前記しきい数を超える期間が所与の期間より長いかどうかを判定する段階と、
判定された数が前記しきい数を超える期間が所与の期間以下である場合に前記受信されたメディアを前記デジッタバッファに入らないように迂回させる段階とを含む、請求項1に記載の方法。
前記しきい数は1である、請求項2に記載の方法。
前記所与の期間は複数のタイムスロットに相当する、請求項2に記載の方法。
前記所与の期間は単一のタイムスロットに相当する、請求項2に記載の方法。
前記判定された数は、前記迂回段階が実行されるように、前記しきい数を超える期間が前記所与の期間以下であると判定される、請求項2に記載の方法。
前記送信段階は、前記受信されたメディアを混合せずに送信する、請求項6に記載の方法。
前記判定された数は、前記迂回段階が実行されないように、前記しきい値を超える期間が前記所定の期間よりも長いと判定される、請求項2に記載の方法。
前記受信されたメディアを前記デジッタバッファに加える段階と、
前記受信されたメディアの1つまたは複数のフレームを前記デジッタバッファから取り出す段階と、
前記1つまたは複数のフレームを混合する段階とを含み、
前記送信段階は、前記混合されたフレームを前記通信グループに送信する、請求項8に記載の方法。
前記受信されたメディアをフォーマットし、前記通信セッション中に前記アプリケーションサーバによって前記通信グループに送信される出力ストリームと一致する受信されたメディアのフォーマット済みバージョンを生成する段階をさらに備え、
前記送信段階は、前記受信されたメディアのフォーマット済みバージョンを前記通信グループに送信する、請求項1に記載の方法。
前記フォーマット段階は、前記受信されたメディアのヘッダ部を前記出力ストリームに関連するヘッダ部と一致するように修正する、請求項10に記載の方法。
前記送信段階は、前記受信されたメディアの供給元のそれぞれのセッション参加者を除く前記通信グループの各アクティブセッション参加者に前記受信されたメディアを送信する、請求項1に記載の方法。
前記グループ通信セッション中にメディアを供給するセッション参加者の数の変化に基づいて、(i)前記グループ通信セッションに関連するメディアを前記デジッタバッファに加える段階と(ii)前記グループ通信セッションに関連するメディアを前記デジッタバッファに入らないように迂回させる段階とを切り替える段階をさらに含む、請求項1に記載の方法。
前記変化は、セッション参加者の数の減少に相当し、前記切り替え段階は(i)から(ii)に切り替わる、請求項13に記載の方法。
前記変化は、セッション参加者の数の増加に相当し、前記切り替え段階は(ii)から(i)に切り替わる、請求項13に記載の方法。
迂回を行うかどうかを判定する段階は、前記受信されたメディアを前記デジッタバッファに入らないように迂回させるべきであると判定し、前記方法は、
前記デジッタバッファ内に現在存在する前記キューに入れられたメディアを取り出す段階と、
前記キューに入れられたメディアを混合せずに前記通信グループに送信する段階とをさらに含む、請求項1に記載の方法。
前記グループ通信セッションは、前記グループ通信セッション中にそれぞれの異なる数のフロアホルダを有することができる半二重通信セッション、全二重通信セッション、またはハイブリッド二重通信セッションに相当する、請求項1に記載の方法。
前記受信されたメディアは、前記1人または複数のセッション参加者からの音声メディアを含む1つまたは複数のメディアフレームに相当する、請求項1に記載の方法。
通信グループのグループ通信セッションを調停し、前記グループ通信セッションに関連するメディアを選択的に混合するように構成されたアプリケーションサーバであって、
前記グループ通信セッションの1人または複数のセッション参加者から、前記通信グループに送信されるメディアを受信する手段と、
前記受信されたメディアを供給するセッション参加者の数を判定する手段と、
前記判定された数に少なくとも部分的に基づいて、セッション参加者からのメディアを前記グループ通信セッション中に前記アプリケーションサーバによって混合されるようにキューに入れておくように構成されたデジッタバッファに前記受信されたメディアが入らないように前記受信されたメディアを迂回させるべきかどうかを判定する手段と、
前記受信されたメディアを前記通信グループに送信する手段とを備えるアプリケーションサーバ。
通信グループのグループ通信セッションを調停し、前記グループ通信セッションに関連するメディアを選択的に混合するように構成されたアプリケーションサーバであって、
前記グループ通信セッションの1人または複数のセッション参加者から、前記通信グループに送信されるメディアを受信するように構成された機能と、
前記受信されたメディアを供給するセッション参加者の数を判定するように構成された機能と、
前記判定された数に少なくとも部分的に基づいて、セッション参加者からのメディアを前記グループ通信セッション中に前記アプリケーションサーバによって混合されるようにキューに入れておくように構成されたデジッタバッファに前記受信されたメディアが入らないように前記受信されたメディアを迂回させるべきかどうかを判定するように構成された機能と、
前記受信されたメディアを前記通信グループに送信するように構成された機能とを備えるアプリケーションサーバ。
コンピュータ可読記憶媒体において、通信グループのグループ通信セッションを調停し、前記グループ通信セッションに関連するメディアを選択的に混合するように構成されたアプリケーションサーバによって実行されたときに、前記アプリケーションサーバに動作を実行させる命令であって、
前記グループ通信セッションの1人または複数のセッション参加者から、前記通信グループに送信されるメディアを受信するプログラムコードと、
前記受信されたメディアを供給するセッション参加者の数を判定するプログラムコードと、
前記判定された数に少なくとも部分的に基づいて、セッション参加者からのメディアを前記グループ通信セッション中に前記アプリケーションサーバによって混合されるようにキューに入れておくように構成されたデジッタバッファに前記受信されたメディアが入らないように前記受信されたメディアを迂回させるべきかどうかを判定するプログラムコードと、
前記受信されたメディアを前記通信グループに送信するプログラムコードとを含む命令が記憶されたコンピュータ可読記憶媒体。