JP5531115B2

JP5531115B2 - ワイヤレス通信システム内でのサービス品質（ＱｏＳ）の取得およびプロビジョニング

Info

Publication number: JP5531115B2
Application number: JP2012555040A
Authority: JP
Inventors: ヴィヴェク・マンプリア; アッシュ・ラズダン; アルルモジ・ケイ・アナンタナラヤナン; エリック・シー・ローゼン
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2010-02-26
Filing date: 2011-02-16
Publication date: 2014-06-25
Anticipated expiration: 2031-02-16
Also published as: EP2615866A1; US20150304990A1; EP2615866B1; US9107188B2; US20110211439A1; JP2013520930A; EP2618608A1; KR20120125650A; US20140321393A1; WO2011106211A1; US8804518B2; CN102845104B; CN102845104A; KR101385394B1; EP2618607B1; EP2540111A1; EP2618608B1; EP2618607A1

Description

実施形態は、ワイヤレス通信システム内での通信セッションに対するサービス品質(QoS)リソースの割振りに関する。

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により明白に本明細書に組み込まれる、2010年2月26日に出願された「QUALITY OF SERVICE (QoS) ACQUISITION AND PROVISIONING WITHIN A WIRELESS COMMUNICATIONS SYSTEM」という名称の仮出願第61/308,768号の優先権を主張する。

同時係属特許出願の参照
本特許出願は、本出願の譲受人に譲渡され、参照により明白に本明細書に組み込まれる、2009年7月27日に出願された「QUALITY OF SERVICE (QoS) RESOURCES WITHIN A WIRELESS COMMUNICATIONS SYSTEM」という名称の同時係属の米国出願第12/509,980号に関する。

ワイヤレス通信システムは、第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接続(GSM(登録商標))変形に基づくデジタルセルラーシステム、およびTDMA技術とCDMA技術の両方を使用する、より新しいハイブリッドデジタル通信システムがある。

CDMAモバイル通信を提供するための方法は、本明細書ではIS-95と呼ぶ、「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」と題するTIA/EIA/IS-95-Aにおいて、米国電気通信工業会/米国電子工業会によって米国で規格化された。複合AMPS&CDMAシステムはTIA/EIA規格IS-98に記載されている。他の通信システムは、広帯域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)にエントリポイントを与える。したがって、基地局は、一般に、無線インターフェースによってATと情報のやり取りをし、インターネットプロトコル(IP)ネットワークデータパケットによってANと情報のやり取りをする。

ワイヤレス電気通信システムでは、プッシュツートーク(PTT)機能がサービスセクタおよび消費者に普及している。PTTは、CDMA、FDMA、TDMA、GSM(登録商標)などのような標準商用ワイヤレスインフラストラクチャを介して動作する「ディスパッチ」ボイスサービスをサポートし得る。ディスパッチモデルでは、エンドポイント(AT)の間の通信は、仮想グループ内で起こり、1人の「話者」の声が、1人または複数の「受話者」に送信される。このタイプの通信の単一のインスタンスは、通常、ディスパッチ呼、または単にPTT呼と呼ばれる。PTT呼は、呼の特性を定義する、グループのインスタンシエーションである。グループは、本質的に、グループ名またはグループ識別情報などのメンバーリストおよび関連情報によって定義される。

従来、ワイヤレス通信ネットワーク内のデータパケットは、単一の宛先またはアクセス端末に送られるように構成された。単一の宛先へのデータの送信は「ユニキャスト」と呼ばれる。モバイル通信が増加するにつれて、所与のデータを複数のアクセス端末に同時に送信する能力がより重要になった。したがって、複数の宛先またはターゲットアクセス端末への同じパケットまたはメッセージの同時データ送信をサポートするためにプロトコルが採用された。「ブロードキャスト」は、(たとえば、所与のセル内にある、所与のサービスプロバイダによってサービスされるものなど)すべての宛先またはアクセス端末へのデータパケットの送信を指し、一方、「マルチキャスト」は、宛先またはアクセス端末の所与のグループへのデータパケットの送信を指す。一例では、宛先の所与のグループまたは「マルチキャストグループ」は、(たとえば、所与のセル内にある、所与のサービスプロバイダによってサービスされるものなど)可能な宛先またはアクセス端末のうちの2つ以上かつすべて未満のものを含むことができる。ただし、少なくともいくつかの状況においては、マルチキャストグループが、ユニキャストと同様に、ただ1つのアクセス端末を含むこと、あるいは代替的に、マルチキャストグループが、ブロードキャストと同様に、(たとえば、セルまたはセクタ内などの)すべてのアクセス端末を含むことが可能である。

ブロードキャストおよび/またはマルチキャストは、マルチキャストグループに対応するために複数の連続ユニキャスト動作を実行する、複数のデータ送信を同時に処理するための一意のブロードキャスト/マルチキャストチャネル(BCH)を割り当てるなど、いくつかの方法でワイヤレス通信システム内において実行できる。プッシュツートーク通信のためのブロードキャストチャネルを使用する従来のシステムが、その内容の全体が参照により本明細書に組み込まれる、「Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network」と題する、2007年3月1日付けの米国特許出願公開第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号

TIA/EIA/IS-95-A「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」 3rd Generation Partnership Project 2 (「3GPP2」)、「CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification」、2006年2月14日 3GPP2 C.S0024-A Version 3.0、cdma2000高速パケットデータエアインターフェース、2006年9月12日 3GPP2 X.S0011-004-C Version 2.0 cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction cdma2000スペクトラム拡散のためのパラメータ値割当ての管理標準TSB58-G

一実施形態において、アクセスネットワーク(AN)は、アクセス端末(AT)に対するサービス品質(QoS)リソースの条件付き割振りを促すように構成されたメッセージを受信する。メッセージは、ATから、または、ATのための通信セッションを調停するアプリケーションサーバ(AS)から受信することができる。別の実施形態では、ATは、QoSリソース要求がまだ認められていないことを決定した場合、QoSリソース要求を再送する前に、通信セッションのためにトラフィックチャネル(TCH)が取得されるまで待つ。別の実施形態では、第1の通信セッションのためのQoSリソースが放棄されることの確認の前に第2の通信セッションを開始すること、または第2の通信セッションに加わることをATが決定した場合、ATは、第2の通信セッションのためのQoSリソースの要求が送られる前に確認が受信されるまで待つ。

本発明の実施形態およびその付随する利点の多くのより完全な理解は、本発明を限定するためではなく単に例示するために提示する添付の図面とともに考察する際に以下の発明を実施するための形態を参照することによってより良く理解されれば、これは容易に得られる。

本発明の少なくとも1つの実施形態によるアクセス端末とアクセスネットワークとをサポートするワイヤレスネットワークアーキテクチャの図である。例示的な本発明の実施形態によるキャリアネットワークを示す図である。本発明の少なくとも1つの実施形態によるアクセス端末の図である。本発明の実施形態による信号流れ図である。本発明の実施形態による信号流れ図である。本発明の実施形態による信号流れ図である。本発明の少なくとも1つの実施形態によるグループ通信システムの図である。本発明の少なくとも1つの実施形態による無線リンクプロトコル(RLP)フローの図である。本発明の少なくとも1つの実施形態によるフローチャートである。本発明の少なくとも1つの実施形態によるターゲットアクセス端末に関連する信号流れ図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による通信セットアッププロセスを示す図である。本発明の異なる実施形態による第2の連続通信セッションのセットアッププロセスを示す図である。本発明の異なる実施形態による第2の連続通信セッションのセットアッププロセスを示す図である。本発明の異なる実施形態による第2の連続通信セッションのセットアッププロセスを示す図である。本発明の異なる実施形態による第2の連続通信セッションの別のセットアッププロセスを示す図である。本発明の異なる実施形態による第2の連続通信セッションの別のセットアッププロセスを示す図である。本発明の異なる実施形態による第2の連続通信セッションの別のセットアッププロセスを示す図である。

本発明の特定の実施形態を対象とする以下の説明および関連する図面で本発明の態様を開示する。本発明の範囲から逸脱することなく代替実施形態を考案することができる。さらに、本発明の関連する詳細を不明瞭にしないように、本発明のよく知られている要素については詳細に説明しないか、または省略する。

「例示的な」という言葉は、「一例、実例または例として」を意味するために本明細書で使用される。「例示的」として本明細書で説明する任意の実施形態は、必ずしも他の実施形態よりも好ましいまたは有利であると解釈されない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、論じられた特徴、利点または動作モードを含むことを必要としない。

さらに、多くの実施形態については、たとえば、コンピューティングデバイスの要素によって実行すべき一連のアクションに関して説明する。本明細書で説明する様々なアクションは、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つまたは複数のプロセッサによって実行されるプログラム命令によって、あるいは両方の組合せによって実行できることを認識されよう。さらに、本明細書で説明するこれらの一連のアクションは、実行時に、関連するプロセッサに本明細書で説明する機能を実行させるコンピュータ命令の対応するセットを記憶した任意の形式のコンピュータ可読記憶媒体内で全体として実施すべきものと見なすことができる。したがって、本発明の様々な態様は、そのすべてが、請求する主題の範囲内に入ることが企図されているいくつかの異なる形式で実施できる。さらに、本明細書で説明する実施形態ごとに、そのような任意の実施形態の対応する形式を、たとえば、記載のアクションを実行する「ように構成された論理」として本明細書で説明することがある。

本明細書でアクセス端末(AT)と呼ぶ高データレート(HDR)加入者局(たとえば1xEV-DO対応ワイヤレスデバイス)は、移動でも固定でもよく、本明細書でモデムプールトランシーバ(MPT)または基地局(BS)と呼ぶ1つまたは複数のHDR基地局と通信することができる。アクセス端末は、1つまたは複数のモデムプールトランシーバを介して、モデムプールコントローラ(MPC)、基地局コントローラ(BSC)および/または移動交換センター(MSC)と呼ばれるHDR基地局コントローラとの間でデータパケットを送信および受信する。モデムプールトランシーバおよびモデムプールコントローラは、アクセスネットワークと呼ばれるネットワークの一部である。アクセスネットワーク(AN)(本明細書では無線アクセスネットワーク(RAN)とも呼ぶ)は、複数のアクセス端末間にデータパケットをトランスポートする。

アクセスネットワークは、企業イントラネットまたはインターネットなど、アクセスネットワークの外部の追加のネットワークにさらに接続され得、各アクセス端末とそのような外部のネットワークとの間でデータパケットをトランスポートし得る。1つまたは複数のモデムプールトランシーバとのアクティブトラフィックチャネル接続を確立したアクセス端末は、アクティブアクセス端末と呼ばれ、トラフィック状態にあると言われる。1つまたは複数のモデムプールトランシーバとのアクティブトラフィックチャネル接続を確立中であるアクセス端末は、接続セットアップ状態にあると言われる。アクセス端末は、ワイヤレスチャネルを介して、あるいは、たとえば、光ファイバまたは同軸ケーブルを使用するワイヤードチャネルを介して通信する任意のデータデバイスであり得る。アクセス端末はさらに、限定はしないが、PCカード、コンパクトフラッシュ(登録商標)、外部または内部モデム、あるいはワイヤレス電話または有線電話を含む、いくつかのタイプのデバイスのいずれかであり得る。アクセス端末が信号をモデムプールトランシーバに送信するための通信リンクは、逆方向リンクまたは逆方向トラフィックチャネルと呼ばれる。モデムプールトランシーバが信号をアクセス端末に送信するための通信リンクは、順方向リンクまたは順方向トラフィックチャネルと呼ばれる。本明細書で使用するトラフィックチャネルという用語は、順方向トラフィックチャネルまたは逆方向トラフィックチャネルのいずれかを指すことができる。

図1Aに、本発明の少なくとも1つの実施形態によるワイヤレスシステム100の例示的な一実施形態のブロック図を示す。システム100は、アクセス端末102をネットワーク機器に接続して、パケット交換データネットワーク(たとえば、イントラネット、インターネット、および/またはキャリアネットワーク126)とアクセス端末102、108、110、112との間にデータ接続性を与えることができるエアインターフェース104を介してアクセスネットワーク(AN)120または無線アクセスネットワーク(RAN)120と通信している、セルラー電話102などのアクセス端末を含むことができる。以下では、AN120とRAN120との間を互換的に言及する。本明細書に示すように、アクセス端末は、セルラー電話102、携帯情報端末108、本明細書に双方向テキストページャとして示すページャ110、さらにはワイヤレス通信ポータルを有する別個のコンピュータプラットフォーム112であり得る。したがって、本発明の実施形態は、ワイヤレスモデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組合せもしくは部分的な組合せを限定なしに含む、ワイヤレス通信ポータルを含むか、またはワイヤレス通信機能を有する任意の形態のアクセス端末上で実現され得る。さらに、本明細書で使用する「アクセス端末」、「ワイヤレスデバイス」、「クライアントデバイス」、「モバイル端末」という用語およびそれらの変形は、互換的に使用され得る。

再び図1Aを参照すると、ワイヤレスネットワーク100の構成要素および本発明の例示的な実施形態の要素の相互関係は、図示の構成に限定されない。システム100は、例示的なものにすぎず、ワイヤレスクライアントコンピューティングデバイス102、108、110、112などのリモートアクセス端末が、互いに、および/またはキャリアネットワーク126、インターネットおよび/または他のリモートサーバを限定なしに含む、エアインターフェース104およびRAN120を介して接続された構成要素との間において無線で通信することを可能にする任意のシステムを含むことができる。

RAN120は、基地局コントローラ/パケット制御機能(BSC/PCF)122に送信される(一般に、データパケットとして送信される)メッセージを制御する。BSC/PCF122は、パケットデータサービスノード160(「PDSN」)(たとえば図1Bに示す)とアクセス端末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の機能とMPT/BS124の1つまたは複数とを、BSC/PCF122とMPT/BS124の両方の機能を有する単一の「ハイブリッド」モジュールに縮小することができる。

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

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

図2を参照すると、セルラー電話などのアクセス端末200(本明細書ではワイヤレスデバイス)は、キャリアネットワーク126、インターネットおよび/または他のリモートサーバおよびネットワークから最終的に発生することがある、RAN120から送信されたソフトウェアアプリケーション、データおよび/またはコマンドを受信および実行することができるプラットフォーム202を有する。プラットフォーム202は、特定用途向け集積回路(「ASIC」208)または他のプロセッサ、マイクロプロセッサ、論理回路、あるいは他のデータ処理デバイスに動作可能に結合されたトランシーバ206を含むことができる。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212内の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース(「API」)210層を実行する。メモリ212は、読取り専用またはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、あるいはコンピュータプラットフォームに共通の任意のメモリから構成することができる。プラットフォーム202は、メモリ212において活発に使用されないアプリケーションを保持することができるローカルデータベース214も含み得る。ローカルデータベース214は、一般的に、フラッシュメモリセルであるが、たとえば磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。内部プラットフォーム202の構成要素は、当技術分野で知られているように、構成要素の中でも、アンテナ222、ディスプレイ224、プッシュツートークボタン228、およびキーパッド226などの外部デバイスに動作可能に結合されてもよい。

したがって、本発明の一実施形態は、本明細書で説明する機能を実行するための能力を含むアクセス端末を含むことができる。たとえば、アクセス端末は、アクセスメッセージに接続要求およびQoSリソースの予約をバンドルするように構成された論理、およびアクセスメッセージをアクセスネットワークに送信するように構成された論理を含むことができる。当業者であれば分かっているように、本明細書で開示する機能を達成するために、様々な論理要素を、個別要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで実施することができる。たとえば、ASIC208、メモリ212、API210およびローカルデータベース214をすべて協働的に使用して、本明細書で開示する様々な機能をロード、記憶および実行することができ、したがってこれらの機能を実行する論理を様々な要素に分散することができる。代替的に、機能を1つの個別構成要素に組み込むことができる。したがって、図2中のアクセス端末の特徴は例示的なものにすぎないと見なすべきであり、本発明は図示の特徴または構成に限定されない。

アクセス端末102とRAN120との間のワイヤレス通信は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、Global System for Mobile Communications(GSM(登録商標))、あるいはワイヤレス通信ネットワークまたはデータ通信ネットワークにおいて使用できる他のプロトコルなど、様々な技術に基づくことができる。データ通信は、一般に、クライアントデバイス102とMPT/BS124とBSC/PCF122との間で行われる。BSC/PCF122は、キャリアネットワーク126、PSTN、インターネット、バーチャルプライベートネットワークなどの複数のデータネットワークに接続でき、したがって、アクセス端末102はより広範囲の通信ネットワークにアクセスできるようになる。前述のように、および当技術分野で知られているように、様々なネットワークおよび構成を使用して、ボイス送信および/またはデータをアクセスネットワークからアクセス端末に送信することができる。したがって、本明細書で提供する例は、本発明の実施形態を限定するものではなく、本発明の実施形態の態様の説明を助けるものにすぎない。

図3Aは、本発明の実施形態による通信をバンドルするための流れ図を示す。310で、アクセス端末(AT)302において、通信要求を確立するための最初のトリガがあり(たとえば、PTTボタン228が押される)、アクセスネットワーク(AN)120との通信を確立するために必要な情報がアクセスチャネルメッセージにバンドルされる(たとえば、接続要求(ConnectionRequest)およびルート更新情報(RouteUpdate)、通信に使用される任意のQoSサービスのプロビジョニング(ReservationOnRequest)など)。さらに、アプリケーション層データ(たとえばDataOverSignaling(DOS)メッセージ)は、エンドアプリケーション(たとえば、グループサーバ、別のATの上に常駐するアプリケーションなど)との通信を促進するために、アクセスチャネルメッセージにバンドルすることもできる。ひとたびアクセスメッセージが所望の情報とともにバンドルされる(たとえば、DOS+ConnectionRequest+RouteUpdate+ReservationOnRequest)と、320で、アクセスメッセージをアクセスチャネル(AC)上でアクセスネットワーク(AN)120に送ることができる。

バンドルされたメッセージ320がひとたびアクセスネットワーク120で受信されると、アクセスネットワークは要求330を処理することができる。330において、アクセスネットワークは、トラフィックチャネル(TCH)およびQoSリソースが使用可能であると仮定して、トラフィックチャネルおよび要求されたQoSリソースを要求された予約に割り振ることができる。具体的には、アクセスネットワーク120は、332でアクセスメッセージを肯定応答(ACAck)し、334でトラフィックチャネル割当て(TCA)を送信し、336で予約受付けメッセージ(ReservationAccept)を送信することができる。これらのメッセージは、制御チャネル(CC)上でAT302に送信することができる。340で、AN120とのデータ通信レートを確立するために、AT302からデータレート制御(DRC)メッセージを送ることができる。DRCおよびパイロットの受信に成功し、復号した後、AN120は、350で、順方向トラフィックチャネル(F-TCH)上で、逆方向トラフィックチャネル肯定応答(RTCAck)メッセージを送信することができる。RTCAckメッセージを受信すると、AT302は、360で、逆方向トラフィックチャネル(R-TCH)上で、トラフィックチャネル完了(TCC)メッセージを送ることができる。次いで、順方向と逆方向の両方で専用チャネルが確立され、AT302およびAN120は両方とも、双方向にデータを通信することができる。アクセス端末302とアクセスネットワーク120との間で通信される様々なメッセージは、当技術分野で知られており、2006年9月12日付けの3GPP2 C.S0024-A Version 3.0、cdma2000高速パケットデータエアインターフェースにおいて文書化されており、その全体が参照により本明細書に組み込まれる。したがって、セットアップ手順およびメッセージの詳細な説明については、本明細書では提供しない。

DOSメッセージまたは他のアプリケーション層メッセージが接続要求アクセスメッセージに随意にバンドルされる場合、その情報は、上記で論じた、トラフィックチャネルのセットアップに影響を与えない。一般に、アプリケーションに固有のデータは、AN120によって検出され、単に適切な宛先に渡され得る。しかしながら、AT302とAN120との間にひとたびトラフィックチャネルがセットアップされると、アプリケーション固有の情報は、データ通信(たとえば、PTT呼)を確立するために、リモートアプリケーション(たとえば、PTTサーバ)によるさらなる処理に必要なデータ(たとえば、PTT呼要求)を提供することによって、遅延敏感なアプリケーションのレイテンシをさらに低減することができる。したがって、アプリケーション層メッセージに含まれるデータは、ネットワークに転送される前に、AT302とAN120との間のトラフィックチャネルの確立を待つ必要はない。

当業者であれば分かっているように、必要とされるQoSリソースは、異なるアプリケーションについて、またはアプリケーション内で変化し得る。以下の例では、異なるQoSリソースのシナリオの下で、QoS設計について説明する。
・トラフィックチャネルリソースおよびQoSリソース(たとえば、呼中シグナリングおよびメディア予約(In-Call Signaling and Media reservations))が発信者AT302セクタのセクタにおいて使用可能であるとき、RANは、呼中シグナリングおよびメディア予約のためにFwdReservationOnメッセージおよびRevReservationOnメッセージを送信することによって、順方向と逆方向の両方のリンクにQoSリソースが使用可能であることを信号で伝える。このケースは、図3Aに示され、上記の説明において説明されている。
・発信者AT302が位置するセクタにおいてトラフィックチャネルリソースが使用可能であり、しかし予約の一部または全部についてQoSリソースが使用不可であるとき、AN120は、トラフィックチャネルを依然として割り振ることができ、発信者AT302にTCAメッセージを送信する。しかしながら、AN120は、AT302にReservationRejectメッセージを送信することによって、プロビジョニングすることができない予約についてQoS要求を拒否する。トラフィックチャネルが使用可能であることによって、AT302は、QoSリソース(たとえば、呼中シグナリングおよびメディア予約)が使用不可であるとき、トラフィックチャネル上のその呼セットアップシグナリングハンドシェイクを完了することを試行することができる。このケースは、図3Bに示されている。
・発信者ATのセクタにおいてトラフィックチャネルリソースが使用不可であるとき、ANは、(たとえば、1xEV-DO Revision A規格に従って)ConnectionDenyメッセージを送信することによって、トラフィックチャネル要求を拒否する。
この場合、予約についてのQoS要求も、AT302にReservationRejectメッセージを送信することによって拒否される。このケースは、図3Cに示されている。

呼セットアップパケットの到着時点に呼中シグナリングおよびメディア予約の一部が発信者ATにすでに割り振られている場合、AN/RANは、現在割り振られていない呼中シグナリングおよびメディア予約をアクティブ化するだけでよい。

上記のように、本発明の実施形態は、遅延敏感のアプリケーションにおけるプロセスの遅延を低減することができる。グループ通信/プッシュツートーク(PTT)システムは、本明細書で開示する通信信号バンドリングによって提供される接続回数の低減を利用することができる遅延敏感システムの一例である。たとえば、本発明の実施形態は、ATが、その接続要求(たとえば、ConnectionRequest+RouteUpdate)メッセージと同じアクセスカプセルでReservationOnRequestメッセージを送信することによって、必要なQoSリソースについての予約(たとえば、PTT呼のための呼中シグナリングおよびメディア予約)をオンにするための要求を送ることを提供する。随意に、DataOverSignaling(DOS)メッセージを同じアクセスカプセルにバンドルすることができる。呼中シグナリングの順方向および逆方向のQoS予約がPTT呼のときに割り振られる場合、ATはメディアQoS予約をオンにするよう要求することができる。これらの要求は、ReservationOnRequestメッセージの一部として行うことができる。

グループ通信システムは、プッシュツートーク(PTT)システム、ネットブロードキャストサービス(NBS)、ディスパッチシステム、またはポイントツーマルチポイント通信システムとしても知られ得る。一般的に、アクセス端末ユーザのグループは、各グループメンバーに割り当てられるアクセス端末を使用して、互いに通信することができる。「グループメンバー」という用語は、互いに通信することが許可されたアクセス端末ユーザのグループを示す。グループ通信システム/PTTシステムは、複数のメンバー間のものであると考えられ得るが、システムはこの構成に限定されず、個々のデバイス間の1対1ベースでの通信に適用することができる。

グループは、既存のインフラストラクチャに対する実質的な変更を必要とすることなく、既存の通信システム上で動作することができる。したがって、コントローラおよびユーザは、たとえば符号分割多元接続(CDMA)システム、時分割多元接続(TDMA)システム、global system for mobile communications(GSM(登録商標))システム、衛星通信システム、有線システムとワイヤレスシステムとの組合せなど、インターネットプロトコル(IP)を使用して、パケット情報を送信および受信することができる任意のシステムで動作することができる。

グループメンバーは、アクセス端末(AT)102、108および302など割り当てられたアクセス端末を使用して互いに通信することができる。ATは、たとえば地上ワイヤレス電話、プッシュツートーク機能を有する有線電話、プッシュツートーク機能を備えた衛星電話、ラップトップまたはデスクトップのコンピュータ、ページングデバイス、あるいはそれらの任意の組合せなど、有線またはワイヤレスのデバイスとすることができる。さらに、各ATは、セキュアモードまたは非セキュア(クリア)モードのいずれかで情報を送信および受信することもできる。ATへの言及は、示されている例または列挙された例に限定されるものではなく、インターネットプロトコル(IP)によってパケット情報を送信および受信するための機能を有する他のデバイスを含み得ることを理解されたい。

あるグループメンバーがグループの他のメンバーに情報を送信したいとき、そのメンバーは、分散型ネットワーク上の送信用にフォーマットされた要求を生成するAT上のプッシュツートークボタンまたはキー(たとえば、図2の228)を押すことによって、送信特権を要求することができる。たとえば、要求は、AT102から、1つまたは複数のMPT(または基地局)124に無線で送信され得る。データパケットを処理するための、よく知られたインターワーキング機能(IWF)、パケットデータサービングノード(PDSN)、またはパケット制御機能(PCF)を含み得るBSC/PCF122は、MPT/BS124と分散型ネットワークとの間に存在し得る。しかしながら、要求は、公衆交換電話網(PSTN)を介してキャリアネットワーク126に送信されてもよい。キャリアネットワーク126は、要求を受信し、RAN120に提供することができる。

図4を参照すると、1つまたは複数のグループ通信サーバ402は、分散型ネットワークへのその接続を介してグループ通信システムのトラフィックを監視することができる。グループ通信サーバ402は、様々な有線のおよびワイヤレスのインターフェースを介して分散型ネットワークに接続することができるので、グループ参加者への地理的近接度は必要ない。一般的に、グループ通信サーバ402は、PTTシステムにおいて設定されたグループメンバーのワイヤレスデバイス(AT302、472、474、476)の間の通信を制御する。図示のワイヤレスネットワークは、例にすぎず、リモートモジュールが互いの間で、ならびに/あるいは、それだけには限定されないが、ワイヤレスネットワークキャリアおよび/またはサーバを含むワイヤレスネットワークの構成要素の間で、無線で通信する任意のシステムを含むことができる。さらに、一連のグループ通信サーバ402は、グループ通信サーバLAN450に接続され得る。

グループ通信サーバ402は、ここではキャリアネットワーク426上に常駐するように示されるPDSN452など、ワイヤレスサービスプロバイダのパケットデータサービスノード(PDSN)に接続され得る。各PDSN452は、パケット制御機能(PCF)462によって基地局460の基地局コントローラ464とインターフェースすることができる。PCF462は、基地局460に位置していてもよい。キャリアネットワーク426は、MSC458に(一般にデータパケットの形態で)送られるメッセージを制御する。MSC458は、1つまたは複数の基地局460に接続され得る。MSC458は一般的に、キャリアネットワークと同様の方法で、データ転送のためのネットワークおよび/またはインターネットと、ボイス情報のためのPSTNの両方によってBTS466に接続される。当技術分野においてよく知られているように、BTS466は、最終的に、携帯電話302、472、474、476など、ワイヤレスATにおよびワイヤレスATから、ワイヤレスでメッセージをブロードキャストし、受信する。したがって、グループ通信システムの一般的な詳細については、これ以上は説明しない。さらに、本明細書における説明は、追加の詳細および例を提供するために、特定のシステムの特定の態様(たとえばPTT、QChat(登録商標)、1xEV-DOなど)について論じているが、本発明の実施形態はこれら特定の例示に限定されない。

上記で説明したように、AT302は、通信(たとえば、PTT呼)を確立するために、トラフィックチャネルを要求する。トラフィックチャネルと、呼中シグナリングおよびメディアのためのQoSリソースの両方が使用可能である場合(QoSリソースに関する追加の詳細については以下および図5で提供する)、PTT呼は、発信者AT302によって開始され得る。従来のシステムでは、AT302は、AN120とのトラフィックチャネル接続を確立し、次いでQoSリソースを要求しなければならない。しかしながら、本発明の実施形態に従ってこの遅延を低減するために、PTT呼を確立するために必要な信号メッセージは、最初の接続要求とともに最初のアクセスチャネルメッセージにバンドルされる。

1xEV-DO Revision Aは、パケットデータネットワークに対する効率的なアクセスを提供するように設計されており、そのネットワークアーキテクチャについてはインターネットに広く基づく。PDSN452、PCF462、およびRAN120においてインターネットプロトコル(IP)ネットワーク要素をトラバースするデータトラフィックは、QoS要件に基づいてトラフィックを差別化するための方法をサポートする標準Internet Engineering Task Force (IETF)ベースのプロトコルに基づき得る。AT302と1xEV-DO Revision Aネットワークと間のQoSは、3GPP2 X.S0011-004-C Version 2.0 cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction仕様書に記載されているように構成され、その内容は参照により本明細書に組み込まれる。AT302とRAN120との間においてエアインターフェース上で送信されるデータトラフィックは、上記で参照した3GPP2 C.S0024-A Version 3.0の文書に記述されているように、1xEV-DO Revision Aプロトコルによって適切なQoS処理のために構成することができる。1xEV-DO Revision Aは、AT内およびAT間のQoSを提供するための標準機構を提供する。AT内のQoSは、同じユーザに属するデータストリームの差別化を提供し、一方、AT間のQoSは、異なるユーザに属するパケットの差別化を提供する。

QoSを達成するために、トラフィックの差別化(traffic differentiation)は、エンドツーエンドで使用可能でなければならない。AT302、RAN120(BTS466、BSC464)、PDSN452を含むすべてのネットワーク構成要素、およびインターネットルータは、QoSを実装/サポートしなければならない。1xEV-DO Revision AネットワークにおけるエンドツーエンドのQoSは、以下の機構によって実現することができる。
・パケットフィルタ:パケットフィルタは、PDSNでのフローを識別する。パケットフィルタは、QoSネゴシエーションの間(たとえば、QChatの起動時)に確立されたチャネルへの順方向データトラフィックをマップするために使用される。パケットフィルタは、3GPP2 X.S0011-004-C Version 2.0 cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction仕様書に記述されているようにPDSNで設定される。
・QoSプロファイル(プロファイルID):QoSプロファイルおよび/またはプロファイルIDは、データサービスのための適切なエアインターフェースパラメータを指定(または予め定義)するための機構である。それは、フローについてのQoS予約をRANと交渉するときATが使用する「速記」の識別子である。様々なデータサービスに利用可能な標準プロファイルID割当ては、その内容が参照により本明細書に組み込まれる、cdma2000スペクトラム拡散のためのパラメータ値割当ての管理標準TSB58-Gに記載されている。
・逆方向トラフィックマーキング:ATは、差別化サービス(DiffServ)フレームワークおよび標準に従って逆方向トラフィックデータをマーキングすることができる。これらのマーキングは、PDSNにおいてアウトバウンドデータについて要求されるQoSネットワーク処理を定義する。

1xEV-DO Revision AネットワークにおけるQoSは、たとえば以下のような、ATのPPPセッションのための以下の要素の適切なマッピングまたはバインディングにも基づく。
・IP(アプリケーション)フロー:エアインターフェースについてのアプリケーション層QoS要件は、一意のIPフローごとに識別される。ATとRANとの間のフローのためのQoS要件を識別するために、IPフローには予約ラベルが関連付けられる。次いで、IPフローは、QoS要件を最も満たすRLPフローにマップされる。
・RLP(リンク)フロー:無線リンクプロトコル(RLP)フローは、上位層フローのためのQoS要件(たとえば、RLPパラメータ構成)に基づいて割り振られる。同じQoS要件を有するIPフローは、同じRLPフローにマップすることができる。逆方向では、RLPフローは、RTCMAC(逆方向トラフィックチャネル媒体アクセス制御)フローにマップされる。
・RTCMACフロー:RTCMACフローは、上位層フローのための物理層レイテンシおよび/または容量の必要性を定義するQoS要件に基づいて割り振られる。たとえば、フローは、低レイテンシまたは大容量のフローとすることができる。同じQoS要件を有するRLPフローは、同じRTCMACフローにマップすることができる。

図5は、アクセスネットワーク120と通信するPTT対応AT302のための複数のRLPフロー500を示す。各フローのためのQoS要件は、QoSプロファイルを介して指定することができる。上記のように、異なるアプリケーションは、異なるQoS要件を有することができる。たとえば、1xEV-DO Revision A上のPTTは、ネットワークQoS要件の仕様によって高優先度および低レイテンシのデータ配信を受信する。例示的なPTTシステムは、ATでの3つのIPフロー、呼セットアップシグナリングのためのフロー、呼中シグナリングのためのフロー、およびメディアのためのフローの割振りを使用することができる。各IPフローは、固有のQoS要件を有し、3つの個別のRLPフローにマップされる。ATは、デフォルトのベストエフォート(BE)フローをさらに使用することができる。メディアのためのQoS要件は、VoIP媒体と類似していると考えることができ、したがって、このRLPフローは、VoIPと共有され得る。

上記の説明は、本発明の実施形態の様々な態様の詳細な例示を提供するために、PTT/QChat(登録商標)システムおよび1xEV-DOネットワークに固有の多くの詳細を提供しているが、本発明の実施形態が任意の特定のアプリケーションおよび/またはネットワークに限定されるものではないことを当業者であれば理解しうる。本発明の実施形態は、QoS要件を有する任意のアプリケーションを含むことができる。さらに、最初の接続セットアップ要求とともにバンドルされるQoSリソースの割振りをサポートすることができる任意のネットワークも本発明の実施形態に含まれ得る。

図6を参照すると、本発明の実施形態によるバンドリングプロセスを示すフローチャートが提供される。たとえば、この方法は、ブロック610で、アプリケーションが、QoSリソース(たとえば、PTT呼)を必要とする通信を識別するステップを含むことができる。追加のメッセージが使用され、アクセスプローブに余裕がある場合、620で、追加のメッセージは、バンドリングのためのもの(たとえば、DOSメッセージ)と考えることができる。次いで、ブロック630で、バンドルされたアクセスメッセージ(たとえば、アクセスプローブ)のための要求は、要求されたメッセージのアクセスプローブへのバンドリングのために、アプリケーション層から下位層に伝達され得る。本明細書で使用する場合、アプリケーション層は、要求側アプリケーション(たとえば、PTTクライアント)、およびアプリケーション層と下位層(たとえば、RLC、MAC、および物理層)との間のインターフェースを円滑にするバンドリングAPIを含み得る。しかしながら、本発明の実施形態はこの構成に限定されないことを諒解されたい。たとえば、アプリケーション自体がバンドリングAPIの機能を含むことができる。

ブロック634で、バンドルされた要求の受信後、QoS要求をアクセスプローブに追加することができる。同様に、ブロック636で、要求され、アクセスプローブに十分なスペースがある場合、DOSメッセージをアクセスプローブに追加することができる。さらに、ブロック638で、接続要求およびルート更新メッセージがアクセスプローブに追加される。ブロック645で、バンドルされたメッセージが完了したかどうかを決定するためのチェックを行うことができる。そうでない場合、欠落したメッセージが遅延している可能性があるので、プロセスはもとのループに戻って、欠落したメッセージがないかチェックすることができる。アクセスプローブのバンドリングを可能にするために、ブロック640で、アプリケーション層に遅延要素(たとえば、タイマー)をセットすることもできる。645で、アプリケーション層が下位層からメッセージバンドリングが完了したという表示を受信するまで(またはイベントが時間切れになり、アクセスプローブが送られるまで)、プロセスは、ブロック650を経由してループすることができる。確認を受信した後、660でアクセスプローブ遅延を解放することができ、670でアクセスプローブを送信することができる。

上記で説明したように、トリガ(たとえば310)は、アプリケーションに知られているQoS要件とともに接続要求をアプリケーションに開始させる任意のイベントとすることができる。トリガは、ハードキーまたはソフトキーによる起動によって手動で起動されてもよく、受信された信号(たとえばボイスコマンド、ネットワークからの信号など)に応答して起動されてもよく、またはアプリケーションによって検出された状態に応答して起動されてもよい。

たとえば、図7に示すように、アクセス端末(AT)472は、705で、PTTシステムにおける告知メッセージまたは呼セットアップメッセージなどのトリガを受信することができる。具体的には、705で、呼セットアップメッセージを、PDSN452およびAN120を介して送信することができる。710で、アクセスネットワーク120は制御チャネル上で呼セットアップメッセージをターゲットAT472に転送することができる。AT472は、呼セットアップパケットを受信し、復号すると、要求された通信(たとえばPTT呼)がQoSリソースを使用することを決定することができる。したがって、ネットワークから受信された呼セットアップメッセージは、その後の応答のバンドリングを開始するためのトリガとして働くことができる。図7は、呼セットアップパケットがDoSパケットを介してAT472に送られることを示すが、本発明の代替的実施形態では、標準ページに続いてトラフィックチャネル(TCH)セットアップが実行され得ることを理解しうる。この代替的実施形態において、呼セットアップパケットは、TCHが立ち上がるまでAT472に送られないことを理解しうる。

たとえば、AT472は、720で、接続要求(たとえばConnectionRequest+RouteUpdate)、QoS予約(たとえばReservationOnRequest)、および随意にアクセスチャネル上のアプリケーション層メッセージ(たとえばDOS)を含むバンドルされた要求で応答することができる。DOSを含むことは、アプリケーションデータがトラフィックチャネル確立前に宛先に送られることを可能にする。QoSリソースを要求することは、トラフィックチャネル確立前に必要なQoSリソースの割振りを可能にする。したがって、通信システムの応答性を改善することができる。接続要求が受信されると、712で、トラフィックチャネルおよび要求されたリソースを、アクセスネットワーク(AN)120において割り振ることができる。714で、トラフィックチャネル割当て(TCA)、QoSリソース受付け、およびアクセスチャネルメッセージの肯定応答を、AT472に送信することができる。AN120とAT472の両方がデータを送信し、受信する準備が整うまで、722、716、および724で、トラフィックチャネルのセットアップを継続することができ、このことは、上記で説明され、また、当技術分野で知られている。したがって、詳細には説明しない。

上記の開示に鑑みて、本発明の実施形態が以前に論じたアクション、操作、および/または機能のシーケンスを実行する方法を含むことを当業者であれば認識されよう。たとえば、ワイヤレスネットワークにおいて通信信号を送信するための方法は、アクセス端末において接続要求およびQoSリソースの予約をアクセスメッセージの中にバンドルするステップと、アクセスメッセージをアクセスネットワークに送信するステップとを含むことができる。バンドルされたメッセージは、接続要求および予約とともにアクセスメッセージの中にバンドルされるアプリケーション層メッセージ(たとえばDOSメッセージ)をさらに含むことができる。

さらに、当業者には知られているように、所与のアクセス端末は一般に、アクセスネットワークが所与のアクセス端末にリソース(たとえば、トラフィックチャネル(TCH)、QoSなど)をプロビジョニングする前に、その端末自体をアクセスネットワークに対して証明することが必要とされる。たとえば、EV-DO 1xでは、所与のアクセス端末は、アクセス端末に対して、ユニキャストアクセス端末識別子(UATI)でそれ自体を証明することができる。したがって、所与のアクセス端末は、たとえば、そのUATIを使用して逆方向リンク上の逆方向リンクのメッセージングを変調することによって、アクセスネットワークが送信者の識別に気づくように、逆方向リンクのメッセージングを介してそのUATIを伝達する。同様に、UATIは、ダウンリンクメッセージ通信において、指定受信者またはアクセス端末を識別するために使用され得る。

UATIは、ある特定のサービングエリア(たとえば、ある特定のサービングセクタ、セルなど)内でのみATを一意に識別するように機能する。したがって、ATが、サービングエリアの外に動いた(たとえば、ATが、別のセル、別のサブネットなどにハンドオフした)場合、新たなUATIがATに割り当てられる。ATが、古いサービングエリアからのATに割り振られたUATIにより、新しいサービングエリア内のアクセスネットワークに対してリソース(たとえば、QoSリソース、TCHなど)を要求することを試みた場合、ATは新しいサービングセクタについての適切なUATIをまだ有していないので、アクセスネットワークは、要求されたリソースを認めない。

ATが新しいサービングエリアに入り、新しいサービングエリア(たとえば、セル間またはセクタ間の境界領域)においてそれ自体を証明するためのUATIをまだ有していない状態が起こる可能性があり、ATは、それによって、逆方向リンクリソース要求において新しいサービングエリアに対して古いUATIでそれ自体を誤って証明する。この状況によって、図8Aおよび図8Bに関して後述するように、呼失敗が生じ得る。

図8Aおよび図8Bは、一実施形態による通信セットアッププロセスを示す。図8Aおよび図8Bを参照すると、800で、AT1は第1のサービングエリア(たとえば、セクタ、セルなど)内にあり、第1のサービングエリア内でそれ自体を証明するための第1のUATIが割り当てられていると仮定する。さらに、800で、AT1がアクティブなTCHを有していないと仮定する。次に、AT1は、802で、第1のサービングエリアから第2のサービングエリアに移動する。図8Aおよび図8B内では、第2のサービングエリアが第1のサービングエリアと同じUATIを使用しないと仮定することができる。

したがって、第2のサービングエリアに入る(たとえば、ハンドオフ後)と、AT1は、804で、第2のサービングエリア内で第2のUATIを要求するために、逆方向リンクアクセスチャネル上でUATI要求をRAN120に送る。RAN120がUATI要求を受信した後、RAN120は、806で、ダウンリンク制御チャネル(CC)上でACAckメッセージをAT1に送ることによって、AT1からのUATI要求の受信に肯定応答する。しかしながら、RAN120は、806でUATI要求に肯定応答するが、第2のUATIをAT1にまだ割り当てていない。

次に、AT1がUATI要求を送った後、しかし第2のサービングエリア内で使用するための第2のUATIが実際にAT1に割り当てられる前に、AT1のユーザは、808で、TCHとQoSリソースの両方を必要とするグループ通信セッションの開始を要求する。たとえば、808のグループ通信セッションのトリガ操作は、PTT通信セッションを開始するために、AT1のユーザがAT1上のPTTボタンを押すことに対応し得る。

グループ通信セッション要求がAT1で受信された後、AT1は、809で、AT1がTCHについての要求を再送する前にTCHリソースを取得するのを待つ用意がある時間に対応するタイマー(「接続信頼性タイマー」)を開始する。たとえば、接続信頼性タイマーは、以下でより詳細に説明する、改良型モバイル加入者ソフトウェア(AMSS)などの下位層通信プロトコルアプリケーションによって開始することができる。また、AT1の通信プロトコルアプリケーション(たとえばAMSS)は、810で、アプリケーションがQoSリソースの割振りを受信するのを待つ用意がある時間に対応する満了期間に関連付けられたQoSタイマーを開始する。また、810で、グループ通信セッションを管理する役目を果たすアプリケーション(「グループ通信セッション管理アプリケーション」)(たとえばQChat)は、通信プロトコルアプリケーションによって送信するための呼メッセージを生成する。通信プロトコルアプリケーションによって送信するための呼メッセージをサブミットすると、グループ通信セッション管理アプリケーションは、(接続信頼性タイマーおよびQoSタイマーとは別の)呼信頼性タイマーを開始する。呼メッセージは、呼信頼性タイマーが満了するたびに、グループ通信セッション管理アプリケーション(たとえばQChat)によって作成され、通信プロトコルアプリケーションによって送信するためにサブミットされる。一例では、グループ通信セッション管理アプリケーション(たとえばQChat)は、(たとえば、アクセスチャネル上のDoSメッセージとして)逆方向シグナリングチャネル上の迅速な送信のために第1の呼メッセージをスケジュールし、TCHが取得された後、R-TCH上の送信のために残りの呼メッセージをスケジュールするよう通信プロトコルアプリケーション(たとえばAMSS)に命令することができる。

たとえば、複数の呼メッセージを待ち行列に入れる通信プロトコルアプリケーションは、QUALCOMM(登録商標)が開発したAMSSに対応し得る。一例では、AMSSは、下にあるMSMチップセットを駆動し、CDMA2000 1XおよびCDMA2000 1xEV-DOを含むCDMA通信技術のスイート全体のソフトウェアプロトコルスタックを実装する。本実施形態では、これもまたQUALCOMMによって開発されたBREW(登録商標)であるモバイルオペレーティングシステム層がある。AMSSおよびコンピュータプラットフォーム上の任意のOEMソフトウェアへの直接の接触をなくす絶縁層を提供しながら、チップまたはデバイスに固有の操作のためのモバイルオペレーティングシステム層アプリケーションプログラミングインターフェース。モバイルオペレーティングシステム層は、デバイスに固有のソフトウェアの新しいリリースが発表されるたびにアプリケーションを書き直す必要なしに、モバイルデバイスの機能を使用するアプリケーション開発を可能にする。グループ通信セッション管理アプリケーションは、セッションを確立する、またはセットアップするためにAMSSと連携することができる、AT1上で動作するQChatクライアントアプリケーションに対応し得る。

812で、バンドルされたメッセージ(たとえば、DOS+ConnectionRequest+RouteUpdate+ReservationOnRequest)が構成され、逆方向リンクアクセスチャネル上でAT1からRAN120に送信される。たとえば、バンドルされたメッセージは、810で、グループ通信セッション管理アプリケーションによって生成される複数の呼メッセージのうちの第1のもの(通信プロトコルアプリケーションによるTCH依存の送信待ち行列に追加されない)を含むことができる。さらなる一例では、812のバンドルされたメッセージは、図3A〜図3Cの320または図7の720に関して上述したバンドルされたメッセージに対応することができる。さらに、本発明の上記の実施形態では明示的に開示されていないが、812で送信されるバンドルされたメッセージのヘッダ部分は、RAN120に対してAT1を証明するように、第1のUATIを含むようにさらに構成される。RAN120は、バンドルされたメッセージの受信を肯定応答し、814で、ダウンリンク制御チャネル上でアクセスチャネル肯定応答(ACAck)をAT1に送る。しかしながら、第1のUATIが第2のサービングエリアで知られていない、または少なくともAT1に関連付けられていることが知られていないので、816で、バンドルされたメッセージおよびその関連のリソース要求は、RAN120によって認められない。したがって、812のDoSメッセージは、816で、RAN120によってドロップされる。

818において、RAN120は、第2のサービングエリア内で使用するために、第2のUATIをAT1に割り振るUATIの割当てをダウンリンク制御チャネル上でAT1に送信する。諒解されるように、818のUATIの割当ては、804で、AT1から受信されたUATI要求に応答する。UATIの割当てを受信した後、AT1は、その現在のUATIを記憶する1つまたは複数のレジスタを第2のUATIで更新し(図示せず)、820で逆方向リンクアクセスチャネル上でUATI完了メッセージをRAN120に送信する。

次に、812で送信された呼リソースを要求する最初のバンドルされたメッセージが816でRAN120によって無視されるかドロップされるので、RAN120は、要求されたリソースを実際には割り振らない。したがって、ReservationOnRequestメッセージによって要求されたQoSリソースは、AT1に割り振られず、ある時点において、810でグループ通信セッション管理アプリケーション(たとえばQChat)によって開始される呼信頼性タイマーは、821で満了する(たとえば、呼ACKメッセージが受信されるまで、STATUSメッセージが受信されるまで、または呼メッセージ再送の合計数が閾値を超えるまで毎500ms後になど)。821で呼信頼性タイマーが満了したので、呼信頼性タイマーは821でリセットされ、別の呼メッセージが送信のために通信プロトコルアプリケーション(たとえばAMSS)にサブミットされる。TCHはまだアップしていないので、TCHが使用可能になると、通信プロトコルアプリケーション(たとえばAMSS)は、後の送信のために、その送信待ち行列に呼メッセージを入れる。最終的に、QoSタイマーも満了し、通信プロトコルアプリケーション(たとえばAMSS)は、そのQoS要求操作を一時停止し、QoSが一時停止状態にあることをグループ通信セッション管理アプリケーション(たとえばQChat)に通知する。QoSが失敗したので、グループ通信セッション管理アプリケーション(たとえばQChat)はその呼セットアップ操作を一時停止し、(たとえば、要求されたQoSリソースがグループ通信セッションを開始するための条件であると仮定されるので)822で呼を失敗する。言い換えれば、822後のある時点においてRAN120が要求されたQoSリソースを割り振る場合でさえ、呼がすでに失敗しているので、グループ通信セッション管理アプリケーションはQoSリソースを無視する。しかしながら、いくつかの操作は通信プロトコルアプリケーション(たとえばAMSS)によってすでに待ち行列に入れられているので、通信セッションのセットアップに関連する他の操作は継続する。代替実施形態では、図8Aおよび図8Bには示されていないが、822でQoSリソース要求が失敗するという決定は、QoSリソース要求が認められないことを示すRAN120からの明示的メッセージに基づき得る。したがって、QoSリソース要求についての失敗の決定は、タイマーの満了、またはQoS失敗の明示的指示に基づき得る。

最終的に、809で開始される接続信頼性タイマーも824で満了し、これによって、824で、TCHについてのその要求(たとえば、ConnectionRequestメッセージ)を再送するように、通信プロトコルアプリケーション(たとえばAMSS)がトリガされる。接続信頼性タイマーはトラフィックチャネル(TCH)リソースのセットアップに関連付けられており、QoSリソースには関連付けられていないので、この時点では、QoSリソースは再度要求されない。814でバンドルされたメッセージに応答してACAckが受信されたので、AT1はRAN120がバンドルされたメッセージを受信したことを知っている。したがって、AT1の通信プロトコルアプリケーションは単に、ReservationOnRequestを再送することなく、ReservationOnRequestによって要求されるQoSリソースを受信するのを待つだけである。したがって、AT1は、TCH要求を再送するとき、826で、逆方向リンクアクセスチャネル上でConnectionRequestメッセージおよびRouteUpdateメッセージを送るだけであり、ReservationOnRequestメッセージは再送しない(たとえば、トラフィックチャネル(TCH)リソースのセットアップには関連付けられており、QoSリソースには関連付けられていない接続信頼性タイマーが満了になったので)。また、AT1は、第2のサービングエリア内で第2のUATIに対応するようにそのUATIを更新したので、第2のUATIを使用して826でメッセージを変調する。RAN120は、826でリソース要求メッセージを受信し、828でダウンリンク制御チャネル上でACAckによりメッセージを肯定応答し、830でトラフィックチャネル割当てを送信し、832で順方向トラフィックチャネル(F-TCH)上で逆方向トラフィックチャネル肯定応答(RTCAck)メッセージを送信する(たとえば、図8Aおよび図8Bには示されていないが、AT1からDRCおよびパイロットをうまく受信し、復号した後)。RTCAckメッセージを受信すると、AT1は、834で、逆方向トラフィックチャネル(R-TCH)上で、トラフィックチャネル完了(TCC)メッセージを送ることができる。

TCHを取得した後、AT1は、810から待ち行列に入れられた呼メッセージの各々を次々に送る。したがって、AT1は、836でR-TCH上で第1の待ち行列に入れられた呼メッセージを送り、RAN120は、838で、第1の待ち行列に入れられた呼メッセージをアプリケーションサーバ170に転送する。アプリケーションサーバ170は、840で、AT2…Nに送信するために、告知メッセージをRAN120に転送する。一方、AT1は待ち行列に入れられた呼メッセージの各々を次々と送り続け、842で、R-TCH上でRAN120に別の待ち行列に入れられた呼メッセージを送り、RAN120は、844で、アプリケーションサーバ170に呼メッセージを再度転送する。アプリケーションサーバ170は、846および850で、第1および第2の待ち行列に入れられた呼メッセージにACKで応答し、これらは848および852で、F-TCH上でAT1に送信される。図8Aおよび図8Bでは、待ち行列に入れられた呼メッセージが2つのみ送信されるものとして示されているが、他の実施形態においてより多くの(またはより少ない)待ち行列に入れられた呼メッセージが送信されてもよいことは理解しうる。

854で、AT2…Nのうちの少なくとも1つは、告知メッセージを受信し、肯定応答し、告知された通信セッションを受け付ける。RAN120は、AT2…Nのうちの少なくとも1つから逆方向リンクアクセスチャネル上でACKを受信し、アプリケーションサーバ170にACKを転送する。告知されたグループ通信セッションに対する第1の応答側からのACKを受信すると、アプリケーションサーバ170は、856で、AT1に送信するためのSTATUSメッセージをRAN120に送り、RAN120は、858で、F-TCH上でAT1にSTATUSメッセージを送信する。STATUSメッセージを受信すると、AT1は、860で、呼が依然としてアクティブであるかどうかを決定する。この場合、QoSリソースが遅れずに(すなわち、QoSタイマーの満了前に)割り振られなかったので、822で、呼が失敗したことがすでに確立され、したがって、AT1は、862で、R-TCH上で呼を拒否するACKを送信し、RAN120は、864で、ACK(拒否)をアプリケーションサーバ170に転送し、これによってグループ通信セッションがキャンセルされる。

当業者であれば分かっているように、812のバンドルされたメッセージに、第2のサービングエリアには不適切なUATIを含めることによって、図8Aおよび図8Bのプロセス中に呼失敗ならびに不要なシグナリングおよびリソース割振りがもたらされる。次に、バンドルされたメッセージの最初の送信に不適切なUATIが添付される場合でも、呼失敗を低減し、および/または回避することができるいくつかの代替的実施形態について、図9A〜図11Bに関してより詳細に説明する。

図9Aおよび図9Bは、別の本発明の実施形態による通信セットアッププロセスを示す。図9Aおよび図9Bに関して、図8Aおよび図8Bが800で開始し、821まで続くと仮定する。

900で、QoSタイマーが満了すると、グループ通信セッション管理アプリケーションは、通信プロトコルアプリケーションからSUSPEND通知を受信するが、その呼セットアップ操作を一時停止し呼を失敗する代わりに、グループ通信セッション管理アプリケーションは、呼セットアップの一時停止を控え、QoSリソースがAT1に割り振られるのを待ち続ける。代替実施形態では、図9Aおよび図9Bには示されていないが、900でQoSリソース要求が失敗することの決定は、QoSリソース要求が認められないことを示すRAN120からの明示的メッセージに基づき得る。したがって、QoSリソース要求についての失敗の決定は、タイマーの満了、またはQoS失敗の明示的指示に基づき得る。

824の場合のように、902で接続信頼性タイマーが満了すると、不適切なUATIのために、バンドルされたメッセージがAT1のためのTCH割当てをもたらさなかったので、AT1は、TCHを取得しようとするその試行を継続し、902で、TCHについてのその要求(たとえばConnectionRequestメッセージ)を再送することを決定する。826の場合のように、AT1は、TCH要求を再送するとき、接続信頼性タイマーはTCHのセットアップに関連付けられているが、QoSリソースには関連付けられていないので、904で、逆方向リンクアクセスチャネル上でConnectionRequestメッセージおよびRouteUpdateメッセージのみを送る。

904の再送後、図9Aおよび図9Bのブロック906〜922は概ね図8Aおよび図8Bのブロック828〜844に対応しており、したがって、簡潔のためにこれ以上は説明しない。924で、図8Aおよび図8Bの846の場合のように、単に転送された呼メッセージにACKで応答するだけの代わりに、アプリケーションサーバ170は、AT1のためのQoSリソースの条件付き割振りを実行するようRAN120を促すように機能する所与のフラグを有するACKメッセージを構成する。一例では、所与のフラグは、ACKメッセージのヘッダ部分の所与のディフサーブコードポイント(DSCP)の値に対応することができ、この場合、RAN120は、フラグが付けられた値に設定されたDSCPフィールドを、ACKメッセージのターゲット(すなわち、この場合AT1)に対するQoSリソースの条件付き割振りを実行するための命令として解釈するように構成される。

したがって、ACKメッセージのDSCPフィールドを、RAN120によって認識されるいくつかの予め交渉された値を有するように変更することによって、アプリケーションサーバ170が924でフラグをACKメッセージに挿入すると仮定する。しかしながら、これは単にACKメッセージにフラグを付ける1つの方法にすぎず、他の実施形態がACKメッセージのDSCPフィールドをフラグ部として使用することに限定される必要はないことを理解しうる。924でACKメッセージを構成した後、アプリケーションサーバ170は、926で構成されたACKをRAN120に送る。

926で構成されたACKメッセージを受信すると、RAN120は、構成されたACKメッセージをチェックし、フラグを抽出し、928で、(たとえば、フラグに関連付けられたあるレベルのQoSリソースがAT1にまだ割り振られていないので)QoSリソースの条件付き割振りを実行することを決定すると仮定する。したがって、928で、RAN120は、QoSリソースがグループ通信セッションのためにAT1にすでに割り振られているかどうかを決定する。上記で説明したように、AT1は、第2のサービングエリアにおいて、第1のサービングエリアのために第1のUATIを誤って使用したので、AT1からのReservationOnRequestメッセージは認められず、要求されたQoSリソースは、グループ通信セッションのためにAT1にはまだ割り振られていない。したがって、適切なReservationOnRequestメッセージが受信されていない場合であっても、RAN120は、QoSリソース(たとえば呼中およびメディアQoSフローなど、ACKメッセージの受信者であるAT1と交渉されることがわかっているあるレベルのQoS)をAT1に割り振ることを決定し、それによってRAN120は、930および932で、それぞれTCHの順方向および逆方向のリンク上のそのQoSリソースの割振りをAT1に通知するために、F-TCH上でFwdReservationOnメッセージおよびRevReservationOnメッセージをAT1に送る。また、RAN120は、934で、構成されたACKに基づいて、F-TCH上でAT1にACKを転送する。少なくとも1つの実施形態では、934のACKがアプリケーションサーバ170とは異なるように構成されたACKに基づく場合であっても、934でF-TCH上で送信されるACKが848のACKと異なる必要はないことは理解しうる。AT1は、936および938で、R-TCH上で、それぞれFwdReservationAckメッセージおよびRevReservationAckメッセージでFwdReservationOnメッセージおよびRevReservationOnメッセージに応答する。

次に、アプリケーションサーバ170は、940で、第2の呼メッセージのための別のACKを構成する。940の構成は、924の構成と同様の方法で実行され得る。したがって、少なくとも1つの実施形態では、アプリケーションサーバ170は、呼のためのQoSリソースがグループ通信セッションの発信側に割り振られることを確実にするために、呼メッセージを肯定応答する各ACKにDSCPフラグを挿入することができる。アプリケーションサーバ170は、942で、構成されたACKをRAN120に送り、RAN120は、再度DSCPフラグを識別し、944でQoSリソースがグループ通信セッションのためにAT1に割り振られているかどうかをチェックする。アプリケーションサーバ170からの第1の構成されたACKに応答して、QoSリソースがAT1に割り振られているので、RAN120は、QoSリソースがAT1にすでに割り振られていると決定し、946で、追加のQoSリソースを割り振ることなく、構成されたACKをF-TCH上でAT1に送る。

918の告知メッセージに応答して、AT2…Nのうちの少なくとも1つは、逆方向リンクアクセスチャネル上でRAN120に呼の受付けを示すACKを送り、RAN120は、948で、アプリケーションサーバ170にACK(受付け)を転送する。告知されたグループ通信セッションに対する第1の応答側からのACK(受付け)を受信すると、アプリケーションサーバ170は、950で、RAN120においてQoSリソースの条件付き割振りを促すためのフラグを含むようにSTATUSメッセージを構成する。一例では、STATUSメッセージのフラグは、(たとえば、メッセージのヘッダ部分におけるDSCPフィールドの所与の値など)ACKメッセージにおいて使用される同じフラグに対応し得る。950でSTATUSメッセージを構成した後、アプリケーションサーバ170は、952で、AT1に送信するために、構成されたSTATUSメッセージをRAN120に送る。

RAN120は、再度DSCPフラグを識別し、954で、QoSリソースがグループ通信セッションのためにAT1に割り振られているかどうかをチェックする。アプリケーションサーバ170からの第1の構成されたACKに応答して、QoSリソースがAT1に割り振られているので、RAN120は、QoSリソースがAT1にすでに割り振られていると決定し、956で、追加のQoSリソースを割り振ることなく、F-TCH上でAT1にSTATUSメッセージを送る。

AT1で、860の場合のように、グループ通信セッションを開始できることを示すSTATUSメッセージを受信すると、AT1は、958で、QoSリソースがグループ通信セッションのために割り振られているかどうかを決定する。この場合、(i)アプリケーションサーバ170は、条件付きQoS割振り操作を実行するようRAN120を促すためのフラグを有する複数のメッセージを構成し、(ii)RAN120は、930および932でQoSリソースを割り振り、および(iii)900で、QoSタイマーがタイムアウトしたとき、AT1は、呼を先制して失敗しないので、AT1は、958で、QoSリソースがグループ通信セッションのために割り振られていることを決定する。したがって、AT1は、960でR-TCHを介してACK(受付け)メッセージをRAN120に送信し、RAN120は、962で、アプリケーションサーバ170にACK(受付け)メッセージを転送する。次いで、AT1は、964で、最初のフロア保持者または呼発信者としてグループ通信セッションに関連付けられたメディアを送信し始めることができる。

図9Aおよび図9Bには明示的に示されていないが、本発明の一実施形態では、呼が進行中である間にQoSをセットアップするために、956でAT1にてSTATUSメッセージが受信された後(すなわち、呼の間)、追加のメッセージングを交換することができる。たとえば、STATUSメッセージがAT1に送られてしまうまで、RAN120からQoS割振り(すなわち、Fwd/RevReservationAcceptメッセージ)が送られない場合、呼は、続行することができ、QoSは、呼中にセットアップすることができる。

当業者であれば分かっているように、図9Aおよび図9Bのプロセスは図8Aおよび図8Bのプロセスと比較して、呼失敗の発生を低減するが、図9Aおよび図9Bのプロセスの実施は、AT1、RAN120、およびアプリケーションサーバ170の各々における操作を変える。次に、図8Aおよび図8Bのプロセスと比較して、AT1およびRAN120での変化を伴い、アプリケーションサーバ170の機能に対する変化は必ずしも伴わない一実施形態について説明する。

図10Aおよび図10Bは、別の本発明の実施形態による通信セットアッププロセスを示す。図10Aおよび図10Bに関して、図9Aおよび図9Bの場合のように、図8Aおよび図8Bが800で開始し、821まで続くと仮定する。

次に、図10Aおよび図10Bのブロック1000〜1012は、図9Aおよび図9Bの900〜912に対応すると仮定する。したがって、ブロック1000〜1012については、簡潔のためにこれ以上は説明しない。AT1が1012のTCH完了メッセージを送った後、AT1は、1014で、AT1のためのQoSリソースの条件付き割振りを実行するようRAN120を促すように機能するフラグを含むために、821で構成された待ち行列に入れられた呼メッセージの各々を送る準備をする。一例では、所与のフラグは、呼メッセージのヘッダ部分の所与のディフサーブコードポイント(DSCP)の値に対応することができ、この場合、RAN120は、フラグが付けられた値に設定されたDSCPフィールドを、呼メッセージの送信者(すなわち、この場合、AT1)に対するQoSリソースの条件付き割振りを実行するための命令として解釈するように構成される。言い換えれば、構成された呼メッセージに挿入されたフラグは、少なくとも1つの実施形態で図9Aおよび図9BにおけるACKおよび/またはSTATUSメッセージに挿入されたフラグと同じ効果(すなわち、QoSリソースの条件付き割振りのトリガ)を有することができ、ただし、図9Aおよび図9BのDSCP値は、QoSをACKまたはSTATUSメッセージの「ターゲット」または宛先に割り振るようRAN120に命令するが、図10Aおよび図10BのDSCP値は、QoSを呼メッセージの「送信者」または発信者に割り振るようRAN120に命令する。したがって、一例では、異なるDSCP値は、特定のフラグ付きのメッセージの送信者またはターゲットにQoS割振りをトリガするために確立することができる。たとえば、グループ通信セッション管理アプリケーション(たとえばQChatクライアント)は、通信プロトコルアプリケーション(たとえばAMSS)に、呼メッセージに「スタンプが押される」または挿入されるようにしてDSCP番号を提供することができ、その場合、通信プロトコルアプリケーションは、1014で、送信待ち行列内の呼メッセージのそれぞれのIPヘッダにDSCP番号を追加することができる。

したがって、呼メッセージのDSCPフィールドを、RAN120によって認識されるいくつかの予め交渉された値を有するように変更することによって、AT1がフラグを1014の待ち行列に入れられた呼メッセージに挿入すると仮定する。しかしながら、これは単に待ち行列に入れられた呼メッセージにフラグを付ける1つの方法にすぎず、他の実施形態が待ち行列に入れられた呼メッセージのDSCPフィールドをフラグ部として使用することに限定される必要はないことを理解しうる。

待ち行列に入れられた呼メッセージのうちの1つまたは複数をDSCPフラグを含むように構成した後、AT1は、1016で、第1の待ち行列に入れられた、構成された呼メッセージをR-TCH上でRAN120に送信し、RAN120は、1018で、待ち行列に入れられた、構成された呼メッセージをアプリケーションサーバ170に転送し、アプリケーションサーバ170は、1020で、グループ通信セッションを告知するための告知メッセージANNを生成しこれをAT2…Nに送る。第1の待ち行列に入れられた、構成された呼メッセージを送った後、AT1は、1022で、待ち行列に入れられた、構成された呼メッセージのうちの第2のものをRAN120に送る。追加の待ち行列に入れられた、構成された呼メッセージを次々と送信することもできるが、簡潔のために、これらの追加の送信については、図10Aおよび図10Bに関して示しておらず、または説明しない。一例では、図10Aおよび図10Bでは、待ち行列に入れられた各呼メッセージがRAN120によって条件付きQoS割振りを促すように構成されるものとして示されているが、本発明の他の実施形態では、待ち行列に入れられた呼メッセージ(たとえば、第1の待ち行列に入れられた呼メッセージのみ)のうちのすべて未満のものを送信待ち行列内でこのようにして構成することができることを理解しうる。別の実施形態では、812でDoSパケットによって送信される第1の呼メッセージも構成された呼メッセージとすることもできるが、この構成された呼メッセージは、メッセージヘッダが第2のサービングエリア内で割り当てられたUATIを含まない場合、QoSを認めるようにRAN120をトリガしない。

1016で第1の構成された呼メッセージを受信した後、RAN120は、待ち行列に入れられた、構成された通知メッセージのヘッダ部分をチェックし、フラグを抽出し、1024で、QoSリソースの条件付き割振りを実行することを決定すると仮定する。したがって、1024で、RAN120は、QoSリソースがグループ通信セッションのためにAT1にすでに割り振られているかどうかを決定する。上記で説明したように、AT1は、第2のサービングエリアに実際にいたとき、第1のサービングエリアのために第1のUATIを誤って使用したので、AT1からのReservationOnRequestメッセージは認められず、QoSリソースは、グループ通信セッションのためにAT1にはまだ割り振られていない。したがって、適切なReservationOnRequestメッセージが受信されていない場合であっても、RAN120は、QoSリソース(たとえば呼中およびメディアQoSフローなど、AT1と交渉されることがわかっているあるレベルのQoS)をAT1に割り振ることを決定し、それによってRAN120は、1026および1028で、それぞれTCHの順方向および逆方向のリンク上のそのQoSリソースの割振りをAT1に通知するために、F-TCH上でFwdReservationOnメッセージおよびRevReservationOnメッセージをAT1に送る。また、RAN120は、1030で、(1022でAT1から受信された)待ち行列に入れられた、構成された呼メッセージのうちの第2のものをアプリケーションサーバ170に転送する。AT1は、1032および1034で、R-TCH上で、それぞれFwdReservationAckメッセージおよびRevReservationAckメッセージでFwdReservationOnメッセージおよびRevReservationOnメッセージに応答する。RAN120は、1036で、アプリケーションサーバ170から、待ち行列に入れられた、構成された通知メッセージ(1018で転送された)のうちの第1のものを肯定応答するACKを受信する。また、RAN120は、1038で、F-TCH上でACKをAT1に送信する。

図10Aおよび図10Bには明示的には示されていないが、AT1から送信される各呼メッセージはフラグ(たとえばDSCPフラグ)を含むように構成されるので、RAN120は、AT1からRAN120に送信される待ち行列に入れられた、構成された呼メッセージごとに、ブロック1024の決定を実行することができる。しかしながら、RAN120は、1026および1028のQoSリソースの割振りの後、QoSリソースがすでにAT1に割り振られていることを決定することになるので、図10Aおよび図10Bには、1024の決定ブロックのみが示されている。

次に、アプリケーションサーバ170は、1040で、第2の待ち行列に入れられた、構成された呼メッセージのためのACKを送り、RAN120は、1042で、F-TCH上でACKをAT1に送る。1020の告知メッセージに応答して、AT2…Nのうちの少なくとも1つは、逆方向リンクアクセスチャネル上でRAN120に呼の受付けを示すACKを送り、RAN120は、1044で、アプリケーションサーバ170にACK(受付け)を転送する。告知されたグループ通信セッションに対する第1の応答側からのACK(受付け)を受信すると、アプリケーションサーバ170は、1046で、AT1に送信するためのSTATUSメッセージをRAN120に送り、RAN120は、1048で、F-TCH上でAT1にSTATUSメッセージを送る。

AT1で、958の場合のように、グループ通信セッションを開始できることを示すSTATUSメッセージを受信すると、AT1は、1050で、QoSリソースがグループ通信セッションに割り振られているかどうかを決定する。この場合、(i)QoSタイマーがタイムアウトしたとき、AT1は、呼を先制して失敗せず、(ii)AT1は、条件付きQoS割振りの評価を実行するようRAN120を促すためのフラグを有する1つまたは複数の待ち行列に入れられた呼メッセージを構成し、および(iii)RAN120は、1026および1028でQoSリソースを割り振るので、AT1は、1050で、QoSリソースがグループ通信セッションのために割り振られていることを決定する。したがって、AT1は、1052でR-TCHを介してACK(受付け)メッセージをRAN120に送信し、RAN120は、1054で、アプリケーションサーバ170にACK(受付け)メッセージを転送する。次いで、AT1は、1056で、最初のフロア保持者または呼発信者としてグループ通信セッションに関連付けられたメディアを送信し始めることができる。

当業者であれば分かっているように、図10Aおよび図10Bのプロセスは図8Aおよび図8Bのプロセスと比較して、呼失敗の発生を低減するが、図10Aおよび図10Bのプロセスの実施は、AT1およびRAN120の各々における操作を変える(しかし、たとえば、図9Aおよび図9Bの場合のように、アプリケーションサーバ170での操作は必ずしも変えない)。次に、図8Aおよび図8Bのプロセスと比較して、AT1のみでの変化を伴い、アプリケーションサーバ170および/またはRAN120の機能に対する変化は必ずしも伴わない一実施形態について説明する。

図11Aおよび図11Bは、別の本発明の実施形態による通信セットアッププロセスを示す。図11Aおよび図11Bに関して、図9および図10の場合のように、図8Aおよび図8Bが800で開始し、821まで続くと仮定する。

次に、図10Aおよび図10Bのブロック1100〜1112は、図9Aおよび図9Bの900〜912ならびに/あるいは図10Aおよび図10Bの1000〜1012に対応すると仮定する。したがって、ブロック1100〜1112については、簡潔のためにこれ以上は説明しない。通信プロトコルアプリケーション(たとえばAMSS)は、1108でAT1はTCHが割り当てられ、1112でTCHの割当てを肯定応答すると通知されることを理解しうる。したがって、通信プロトコルアプリケーションが1114でTCHアップイベントを検出すると仮定され得る。

1108で、通信プロトコルアプリケーションがTCHを割り当てられた後、1108の前に(たとえば、グループ通信セッション管理アプリケーションをロードするときに)TCH検出またはTCHイベントの通知を受信するために、グループ通信セッション管理アプリケーションが通信プロトコルアプリケーション(たとえばAMSS)に登録している場合、通信プロトコルアプリケーションは、グループ通信セッション管理アプリケーション(たとえばQChatクライアント)にTCH検出またはTCHイベントを通知することができる。したがって、1114で、グループ通信セッション管理アプリケーションは、1114でTCHアップイベントを検出し、次いでグループ通信セッション管理アプリケーションは、1116で、QoSリソースがグループ通信セッションのためにAT1にすでに割り振られているかどうかを決定する。一時停止された表示がすでに受信されているので、QoSリソースは、AT1に割り振られていない。したがって、グループ通信セッション管理アプリケーションは、QoSリソースがグループ通信セッションのためにAT1にまだ割り振られていないことを決定する。

1118で、グループ通信セッション管理アプリケーション(たとえばQChat)は、通信プロトコルアプリケーション(たとえばAMSS)に、QoS取得プロセスを再開するよう要求する。通信プロトコルアプリケーション(たとえばAMSS)は、QoSタイマーを再開し、RAN120に送信するために、別のReservationOnRequestメッセージをスケジュールすることによって、QoS取得プロセスを再開する。次に、TCHがアップしたので、AT1は、1120で、待ち行列に入れられた呼メッセージのうちの第1のものをR-TCH上でRAN120に送り、RAN120は、1122で、アプリケーションサーバ170に呼メッセージを転送し、アプリケーションサーバ170は、1124で、グループ通信セッションを告知するための告知メッセージANNを生成しこれをAT 2…Nに送る。第1の待ち行列に入れられた呼メッセージが送信された後、AT1は、1126で、待ち行列に入れられた呼メッセージのうちの第2のものをRAN120に送り、RAN120は、1128で、アプリケーションサーバに呼メッセージを転送する。追加の待ち行列に入れられた呼メッセージを次々と送信することもできるが、簡潔のために、これらの追加の送信については、図11Aおよび図11Bに関して示しておらず、または説明しない。

1130で、AT1は、別のReservationOnRequestメッセージ(たとえば、第1のReservationOnRequestメッセージが図8Aおよび図8Bの812でバンドルされたパケットで送られた状態で)をR-TCH上でRAN120に送信する。前のReservationOnRequestメッセージとは異なり、第2のサービングエリア内で確立された、R-TCH上において1130で送信されたReservationOnRequestメッセージ。

また、RAN120は、1132で、第1の待ち行列に入れられた呼メッセージを肯定応答するACKをアプリケーションサーバ170から受信し、RAN120は、1134で、F-TCH上でAT1にACKを送信する。また、RAN120は、使用可能である場合、AT1に要求されたQoSリソースを割り振ることによってReservationOnRequestメッセージに応答し、それによって、1136で、F-TCH上でAT1にReservationAcceptメッセージを送る。

次に、アプリケーションサーバ170は、1138で、第2の待ち行列に入れられた呼メッセージのためのACKを送り、RAN120は、1140で、F-TCH上でACKをAT1に送る。1124の告知メッセージに応答して、AT2…Nのうちの少なくとも1つは、逆方向リンクアクセスチャネル上でRAN120に呼の受付けを示すACKを送り、RAN120は、1142で、アプリケーションサーバ170にACK(受付け)を転送する。告知されたグループ通信セッションに対する第1の応答側からのACK(受付け)を受信すると、アプリケーションサーバ170は、1144で、AT1に送信するためのSTATUSメッセージをRAN120に送り、RAN120は、1146で、F-TCH上でAT1にSTATUSメッセージを送る。

AT1で、図9Aおよび図9Bの958、ならびに/あるいは図10Aおよび図10Bの1050の場合のように、グループ通信セッションを開始できることを示すSTATUSメッセージを受信すると、AT1は、1148で、QoSリソースがグループ通信セッションに割り振られているかどうかを決定する。この場合、(i)QoSタイマーがタイムアウトしたとき、AT1は、呼を先制して失敗せず、(ii)AT1は、RAN120が1136でQoSリソースを割り振るように、TCHアップイベントの後、ReservationOnRequestメッセージを再送するので、AT1は、1148で、QoSリソースがグループ通信セッションのために割り振られていることを決定する。したがって、AT1は、1150でR-TCHを介してACK(受付け)メッセージをRAN120に送信し、RAN120は、1152で、アプリケーションサーバ170にACK(受付け)メッセージを転送する。次いで、AT1は、1154で、最初のフロア保持者または呼発信者としてグループ通信セッションに関連付けられたメディアを送信し始めることができる。

当業者であれば分かっているように、図10Aおよび図10Bのプロセスは図8Aおよび図8Bのプロセスと比較して、呼失敗の発生を低減するが、図10Aおよび図10Bのプロセスの実施は、AT1のみにおける操作を変える(たとえば、アプリケーションサーバ170および/またはRAN120での操作は必ずしも変えない)。

さらに、上記で説明した本発明の実施形態は「呼」の言及を含むが、実施形態は、必ずしも呼に固有のセッションではなく、任意のタイプの通信セッションをカバーするものとすることを理解しうる。たとえば、本明細書で開示する実施形態では、データトランスポートセッションは、必ずしも一方の当事者から別の当事者への呼であると考えるのではなく、通信セッションまたは呼の解釈内に含まれるものとする。

さらに、図の多くに示される呼フローは特にEV-DO実装を対象としているが、本発明の他の実施形態は、他のワイヤレス通信プロトコル(たとえば、Yagatta、CDMA、W-CDMAなど)を対象とすることができることを理解しうる。

さらに、上記の本発明の実施形態では、AT1および/またはRAN120で実行したQoS評価は、QoSが2値変数(すなわち、QoS「ON」またはQoS「OFF」)であるかのように説明されている。たとえば、従来のW-CDMA実装では、単一のQoSフローが通信セッションに割り振られ、単一のQoSフローは「ON」または「OFF」のいずれかとすることができる。従来のEV-DO実装において、通信セッションへの割振りのために、複数のQoSフローが要求され、QoSフローのうちの任意の1つが認められない場合、QoSは「OFF」であると考えられる。

しかしながら、本発明の他の実施形態では、AT1および/またはRAN120において様々な程度のQoSのレベルを評価することができる。たとえば、2値タイプの実装では、上記のように、グループ通信セッション管理アプリケーション(たとえばQChatクライアント)の起動時に、QoSレベルを交渉し、割り当てることができる。呼が開始する(上記の実施形態に記載されているシナリオ)と、グループ通信セッション管理アプリケーションは、交渉されたQoSを認める、または拒否するようRAN120に依頼する。本発明の実施形態では、要求されたQoS-レベルと比較して、より低い量のQoSを認めることができ、呼は依然として続行することができる。

あるいは、AT1は、(たとえばEV-DOの場合のように)2つ以上のQoSフローを要求することができ、RAN120は、部分的ないくつかのフローのみを認めることができる。この意味で、要求されたQoSは、一例で、AT1にとって「部分的に」しか使用可能にならないことがある。従来のEV-DO実装とは異なり、本発明の実施形態では、この部分的QoSフローのシナリオで、呼を続けることが許可され得る。たとえば、RAN120は、順方向のQoSフローを認め、逆方向のフローを拒否することができる。そのような割振りに基づいて、グループ通信セッション管理アプリケーションは、STATUSをACKする(受け付ける)ことを決定し、後で逆方向のフローを再度要求することができる。言い換えれば、図9Aおよび図9Bの958、図10Aおよび図10Bの1050、ならびに/あるいは図11Aおよび図11Bの1148の決定ブロックは、要求されたすべてのQoSが取得されたかどうかの代わりに、十分なレベルのQoSリソースが取得されたかどうかを評価することができる(たとえば、逆方向リンクQoSフローが半二重呼ターゲットにとってあまり重要でない順方向リンクQoSフロー、順方向リンクQoSフローが半二重呼発信者またはフロア保持者にとってあまり重要でない逆方向リンクQoSフローなど)。

さらに、図9A、図9B、図10A、および図10Bにおいて、AT1またはアプリケーションサーバ170がQoSリソースの条件付き割振りをトリガする機構は(たとえば、呼パケット、ACKパケット、またはSTATUSパケットの)パケットヘッダにおける特別に構成されたDSCP構成として上記実施形態に説明されているが、本発明の他の実施形態は、QoSリソースの条件付き割振りを実行するようにRAN120に命令するための他の機構を対象とすることができ、具体的にはパケットのDSCPフィールドである必要はないことを理解しうる。同様に、図9Aおよび図9Bは呼メッセージACKとSTATUSパケットの両方をフラグとして変更されたDSCPフィールドを含むものとして説明しているが、他の実施形態は、これらのパケットの必ずしも両方ではなく、いずれかにフラグを含むことができることを理解しうる。他の実施態様では、STATUSメッセージの後交換されるパケットを、QoSリソースの条件付き割振りをトリガするように構成することができる。たとえば、STATUSメッセージがAT1に送られてしまうまで、QoS割振り(すなわち、Fwd/RevReservationOnメッセージ)がRAN120から送られない場合、呼は、続行することができ、QoSは、呼中にセットアップすることができる。

図9A〜図11Bに関して上記で説明した実施形態は、全般的に、QoSリソースを必要とする新しい呼をセットアップすることを対象としていた。図12に関して後述するように、現在の呼のためのQoSリソースが解放される前に新しい呼のセットアップが始まる場合、たとえば、新しい呼が現在の呼の終了後連続して、または直ちに行われるとき、新しい呼のセットアップの間に困難が生じ得る。したがって、図13Aおよび図13Bに関して後述される本発明の別の実施形態は、現在の呼が終了した直後の新しい呼のセットアップを対象とする。

図12を参照すると、1200で、AT1はTCHを有し、所与のレベルのQoSリソースを有しており、AT1は、AT2…Nのうちの1つまたは複数への第1の呼においてこれらの呼リソースを使用していると仮定する。したがって、1200で、メディアおよび/または呼中シグナリングは、AT1とAT2…Nの中の他の呼参加者との間で交換されている。一例では、図12内では明示的には示されていないが、図9A〜図11Bのうちのいずれかに従って、第1の呼をセットアップすることができる。

次に、AT1は、1204で、第1の呼へのその参加を終了することを決定する。たとえば、1204の決定は、AT1のユーザがAT1の「END」ボタンを押すことに応答することができる。したがって、AT1は、1208で、RAN120にR-TCH上でENDメッセージを送り、RAN120は、1212で、F-TCH上でEND-ACKをAT1に送ることによって第1の呼へのその参加を終了する旨のAT1の要求を肯定応答する。1216で、RAN120が第1の呼のためのAT1のQoSリソースをティアダウンする、または解放することを要求するために、R-TCH上のReservationOffRequestをRAN120に送ることによって、AT1は、第1の呼についてのその呼終了プロセスを継続する。

この時点で、1220で、1216のReservationOffRequestメッセージに対する応答はRAN120から受信されていないので、AT1は、依然としてそのTCHを有しており、そのQoSリソースを放棄することをまだ完了していない。RAN120がReservationOffRequestメッセージに応答する前のこの状態の間、1224で、AT1が第2の呼をセットアップすることを決定すると仮定する。たとえば、1224の決定は、AT1のユーザがAT1の新しい呼の開始を要求することに応答することができる。

この場合、AT1のQoSリソースは現在、1228で、QoS取得の再開についての無効な状態である一時停止状態であるので、一般的に、グループ通信セッション管理アプリケーションはAT1が第2の呼をセットアップすることを許可しない。言い換えれば、グループ通信セッション管理アプリケーションは、第1の呼のためのその「古い」QoSリソースのティアダウンが差し迫っているということを知っていると同時に、第2の呼のための「古い」QoSリソースがオフにされたことをRAN120はまだ肯定応答していないので、第2の呼のための「新しい」QoSリソースを要求することは許可されない。したがって、グループ通信セッション管理アプリケーションは、1228で、単に第2の呼を開始する試行に失敗する。

最終的に、RAN120は、1232で、第1の呼のためのQoSリソースがオフにされることを確認するために、F-TCH上でReservationAcceptメッセージをAT1に送り、その後、AT1は、1236で、第1の呼のためのQoSリソースをもはや有していないことに気づく。この時点で、図12には示されていないが、AT1のユーザは、第2の呼の開始を再度手動で要求することができる。

当業者であれば分かっているように、AT1のユーザは、第2の呼をセットアップしようとするユーザの試行について呼失敗を経験するので、図12のユーザエクスペリエンスは低下する。図13Aおよび図13Bは、図12に関して上記で説明した無効なQoS状態の間でさえ、呼失敗なしに連続呼をセットアップすることができる一実施形態を対象とする。

図13Aおよび図13Bを参照すると、1300〜1320はそれぞれ図12の1200〜1220に対応し、したがって、簡潔のためにこれ以上は説明しない。次に、図12の1220とは異なり、AT1は、1324で、AT1が第2の呼のためのQoSリソースを取得したかどうかとは無関係に、第2の呼のセットアップを試行することを決定する。たとえば、QoSリソースとは無関係に呼のセットアップを進めることによって、呼の間の後のある時点で、QoSリソースを確立することができ、下位レベルのQoSリソースを、呼のためにAT1に割り振ることができ、呼をQoSリソースなしで続けることができる。

したがって、グループ通信セッション管理アプリケーションは、1328で、通信プロトコルアプリケーションの送信待ち行列に呼メッセージを追加し、AT1は、1332で、RAN120にR-TCH上で呼メッセージを送信する。諒解されるように、この時点ではAT1の無効なQoS状態のために、1332で送信される呼メッセージの後、ReservationOnRequestメッセージは続かない。言い換えれば、RAN120が第1の呼のための古いQoSリソースのティアダウンを受け付けるまで、第2の呼のためのQoSリソースを取得するためのReservationOnRequestメッセージの送信は許可されない。しかしながら、QoSを要求することができる前に、AT1は1332で呼メッセージを送信することによって、第2の呼のセットアップを依然として継続することができる。また、AT1が第1の呼からのそのTCHを依然として有しているので、1332の呼メッセージは、DoSメッセージで、逆方向リンクアクセスチャネル上で送られる必要はなく、したがって、単に、より迅速な送信のためにRAN120に呼メッセージを送信するためにそのR-TCHを使用だけでよい。また、図13Aおよび図13Bに示すように、少なくとも1つの実施形態では、逆方向リンク共有チャネルまたはアクセスチャネルと比較して、TCHの信頼性がより高いことによって、AT1は、呼メッセージを1つだけ送るように許可され得る。

したがって、RAN120は、1332でR-TCH上でAT1から呼メッセージを受信し、RAN120は、1336で、呼メッセージをアプリケーションサーバ170に転送する。アプリケーションサーバ170は、1340で、AT2…Nに送信するために、告知メッセージをRAN120に転送する。アプリケーションサーバ170は、1344で、ACKで呼メッセージに応答し、これは、1348で、RAN120によってF-TCH上でAT1に送信される。

この時点で、RAN120は、1352で、F-TCH上でReservationAcceptメッセージを送ることによって、1316で、AT1によって送られたReservationOffRequestメッセージに対して応答すると仮定する。この時点で、グループ通信セッション管理アプリケーションは、1356で、第1の呼のためのQoSリソースがオフされた、またはキャンセルされたことが、通信プロトコルアプリケーションによって通知される。このイベントによって、1360で、グループ通信セッション管理アプリケーションは、無効なQoS状態のためこの時点まで遅れた第2の呼のためのQoSリソース取得をトリガする。したがって、グループ通信セッション管理アプリケーションは、通信プロトコルアプリケーション(たとえばAMSS)に、QoS取得を再開するよう要求する。通信プロトコルアプリケーション(たとえばAMSS)は、1364でQoSタイマーを開始して、1368で、第2の呼のためのQoSリソースを取得するために、R-TCH上でReservationOnRequestメッセージを送信する。RAN120は、1376で、第2の呼のためのそのQoSリソースが予約されていることをAT1に通知するために、ReservationAcceptメッセージをF-TCH上でAT1に送る。一例では、1376のReservationAcceptメッセージは、1368からのReservationOnRequestメッセージに暗黙的なACKとして機能することができ、したがって、ReservationOnRequestメッセージに対する個別のACKが送られる必要はない。

1380で告知されたグループ通信セッション(すなわち第2の呼)に対する第1の応答側からのACK(受付け)メッセージを受信すると、アプリケーションサーバ170は、1383で、AT1に送信するためのSTATUSメッセージをRAN120に送り、RAN120は、1386で、F-TCH上でAT1にSTATUSメッセージを送信する。STATUSメッセージを受信すると、AT1は、1389で、十分なQoSリソースが第2の呼に割り振られたかどうかを決定する。この場合、1376で、第2の呼のためのQoSリソースが割り振られているので、AT1は、1392で、R-TCH上で呼を受け付けるACKを送信し、RAN120は、1395で、アプリケーションサーバ170にACK(受付け)を転送する。その後、1398で、メディアおよび/または呼中シグナリングは、第2の呼の間、AT1とAT2…Nの中の他の呼参加者との間で交換されている。

図13Aおよび図13Bの実施形態では、1376のReservationAcceptメッセージは、1386のSTATUSメッセージの前に、AT1に到達する。代替実施形態では、STATUSメッセージは、ReservationAcceptメッセージの前にAT1に到達することができる。この場合、STATUSメッセージがAT1に到達したときQoSリソースはまだ使用不可であるので、呼を失敗する代わりに、AT1は、ReservationAcceptメッセージを受信するために所与の時間量待つことができる。最終的にReservationAcceptメッセージが到着すると、図13Aおよび図13Bのプロセスは、1392においてACK(受付け)メッセージを引き続き送ることができる。

図15Aおよび図15Bに関して後述する他の実施態様では、呼が終了し、QoSが一時停止状態であり、ATが告知(ANN)メッセージを受信し、予測的なQoSが失敗したか利用できない場合、QoSが一時停止状態であったので、呼が失敗するのを防ぐために、QoSをオンにするための要求を送る前に、予約がオフになるのを待ち、ANNをACKする前に予約の受付けを待つ同じ手順を適用することができる。

図14を参照すると、1400〜1420はそれぞれ図12の1200〜1220に対応し、したがって、簡潔のためにこれ以上は説明しない。次に、1424で、AT1が次のまたは連続の通信セッションを開始することを決定する代わりに、AT2…Nのうちの1つは、別の通信セッションを開始することを決定し、それによって呼メッセージをアプリケーションサーバ170に送り、これは1428でアプリケーションサーバ170によってACKされる。次いで、アプリケーションサーバ170は、1432で、告知(ANN)メッセージを送ることによって、通信セッションを少なくともAT1に告知する。

この場合、AT1のQoSリソースは現在、1428で、QoS取得の再開についての無効な状態である一時停止状態であるので、一般的に、グループ通信セッション管理アプリケーションはAT1が第2の呼をセットアップすることを許可しない。言い換えれば、グループ通信セッション管理アプリケーションは、第1の呼のためのその「古い」QoSリソースのティアダウンが差し迫っているということを知っていると同時に、第2の呼のための「古い」QoSリソースがオフにされたことをRAN120はまだ肯定応答していないので、第2の呼のための「新しい」QoSリソースを要求することは許可されない。

したがって、グループ通信セッション管理アプリケーションは、1428で、単に第2の呼を開始する試行に失敗する。AT1は、それによって、1432で、R-TCH上でRAN120にACK(拒否)メッセージを送り、これは、1436で、アプリケーションサーバ170に転送される。アプリケーションサーバ170は、ACK(拒否)メッセージのためにAT1がセッションに参加できないことを決定し、1440で、STATUS(失敗)メッセージをAT2に送る。最終的に、RAN120は、1444で、第1の呼のためのQoSリソースがオフにされることを確認するために、F-TCH上でReservationAcceptメッセージをAT1に送り、その後、AT1は、1448で、第1の呼のためのQoSリソースをもはや有していないことに気づく。

当業者であれば分かっているように、呼発信者および呼ターゲットの両方(すなわちAT1)は、第2の呼について呼失敗を経験するので、図14のユーザエクスペリエンスは低下する。図15Aおよび図15Bは、図14に関して上記で説明した無効なQoS状態の間でさえ、呼失敗なしに連続呼をセットアップすることができる一実施形態を対象とする。

図15Aおよび図15Bを参照すると、1500〜1532はそれぞれ図14の1400〜1432に対応し、したがって、簡潔のためにこれ以上は説明しない。次に、図14の1428とは異なり、AT1は、1536で、AT1が第2の呼のためのQoSリソースを取得したかどうかとは無関係に、第2の呼のセットアップを試行することを決定する。たとえば、QoSリソースとは無関係に呼のセットアップを進めることによって、呼の間の後のある時点で、QoSリソースを確立することができ、下位レベルのQoSリソースを、呼のためにAT1に割り振ることができ、呼をQoSリソースなしで続けることができる。

したがって、グループ通信セッション管理アプリケーションは、1536で、無効なQoS状態のために単に第2の呼を失敗する代わりに、第1の呼のためのQoSリソースが放棄されるのを待つことを決定する。言い換えれば、RAN120が第1の呼のための古いQoSリソースのティアダウンを受け付けるまで、第2の呼のためのQoSリソースを取得するためのReservationOnRequestメッセージの送信は許可されない。

最終的に、RAN120は、1540で、F-TCH上でReservationAcceptメッセージを送ることによって、1516で、AT1によって送られたReservationOffRequestメッセージに対して応答すると仮定する。この時点で、グループ通信セッション管理アプリケーションは、1544で、第1の呼のためのQoSリソースがオフされた、またはキャンセルされたことが、通信プロトコルアプリケーションによって通知される。このイベントによって、1548で、グループ通信セッション管理アプリケーションは、無効なQoS状態のためこの時点まで遅れた第2の呼のためのQoSリソース取得をトリガする。したがって、グループ通信セッション管理アプリケーションは、通信プロトコルアプリケーション(たとえばAMSS)に、QoS取得を再開するよう要求する。通信プロトコルアプリケーション(たとえばAMSS)は、1552でQoSタイマーを開始して、1556で、第2の呼のためのQoSリソースを取得するために、R-TCH上でReservationOnRequestメッセージを送信する。RAN120は、1560で、第2の呼のためのそのQoSリソースが予約されていることをAT1に通知するために、ReservationAcceptメッセージをF-TCH上でAT1に送る。一例では、1560のReservationAcceptメッセージは、1556からのReservationOnRequestメッセージに暗黙的なACKとして機能することができ、したがって、ReservationOnRequestメッセージに対する個別のACKが送られる必要はない。

この時点で、グループ通信セッション管理アプリケーションは、第2の呼のためのQoSリソースとTCHの両方を確立することを決定し、それによって、1564で、1532からの告知(ANN)メッセージに対するACK(受付け)メッセージをRAN120に送り、これは、1568でアプリケーションサーバに転送される。告知されたグループ通信セッション(すなわち第2の呼)に対する第1の応答側(すなわちAT1)からのACK(受付け)メッセージを受信すると、アプリケーションサーバ170は、1572で、第2の呼を開始するためにSTATUSメッセージをAT2に送り、AT2は、1576で、STATUSメッセージをACKする。その後、1584で、メディアおよび/または呼中シグナリングは、第2の呼の間、AT1とAT2…Nの中の他の呼参加者との間で交換されている。

さらに、図15Aおよび図15Bの実施形態はAT1が1504で第1の呼を終了することを決定し、1508でRAN120にENDメッセージを送ることを示しているが、代替実施形態では、ENDメッセージは、RAN120からAT1に送ることができる(すなわち、アクセスネットワークはAT1についてのセッションの終了を開始する)。この場合、AT1は、セッションを終了することをそれ自体独立して決定する、またはAT1のユーザに、セッションを終了するようAT1に命令させる代わりに、ENDメッセージの受信に基づいて第1の呼を終了することを決定する。

情報および信号は、多種多様な技術および技法のいずれかを使用して表すことができることを当業者は理解しうる。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。

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

本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。

本明細書で開示した実施形態と関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはその2つの組合せで直接実施され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に常駐することができる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に常駐することができる。ASICはユーザ端末(たとえば、アクセス端末)中に常駐し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として常駐し得る。

1つまたは複数の例示的な実施形態では、説明した機能はハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは命令またはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用でき、コンピュータによってアクセスできる、任意の他の媒体を含むことができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、またはたとえば赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義内に含まれる。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるものとする。

したがって、本発明の一実施形態は、コンピュータに接続要求およびQoSリソースの予約をアクセスメッセージにバンドルさせるためのコード、ならびにコンピュータにアクセスメッセージをアクセスネットワークに送信させるためのコードを含む、ワイヤレスネットワークにおいて通信メッセージをバンドルするためのコードをその中に記憶するコンピュータ可読媒体を含むことができる。さらに、本発明のさらなる実施形態では、本明細書で説明した機能のいずれかを追加のコードとして含めることができる。

上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく本明細書において様々な変更および修正を行うことができることに留意されたい。本明細書で説明した本発明の実施形態による方法クレームの機能、ステップおよび/またはアクションを特定の順序で実行しなくてもよい。さらに、本発明の要素は、単数形で説明または請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。

100 ワイヤレスシステム
102 アクセス端末
104 エアインターフェース
108 アクセス端末
110 アクセス端末
112 アクセス端末
120 アクセスネットワーク
122 BSC/PCF
124 MPT
126 キャリアネットワーク
160 パケットデータサービスノード
165 ブロードキャストサービングノード
170 アプリケーションサーバ
200 アクセス端末
202 プラットフォーム
206 トランシーバ
208 ASIC
210 API
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
226 キーパッド
228 プッシュツートークボタン
302 アクセス端末
402 グループ通信サーバ
426 キャリアネットワーク
450 グループ通信サーバLAN
452 PDSN
458 MSC
460 基地局
462 パケット制御機能
464 基地局コントローラ
466 BTS
472 アクセス端末

Claims

ワイヤレス通信システム内で、アクセス端末でサービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップする方法であって、
第2のサービングエリア内で、QoSリソースについての要求を送るステップであり、前記要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、ステップと、
前記第2のサービングエリア内で、アプリケーションサーバによる前記グループ通信セッションのセットアップを要求する呼メッセージを送るステップであり、前記呼メッセージが、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、ステップと、
前記呼メッセージに応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するステップと
を含む方法。
受信する前記ステップが、STATUSメッセージが前記アクセス端末で受信される前に、前記要求されたQoSリソースの前記割振りを受信し、前記STATUSメッセージが、前記グループ通信セッションが開始可能であることを前記アクセス端末に対して示す、請求項1に記載の方法。
受信する前記ステップが、STATUSメッセージが前記アクセス端末で受信された後に、前記要求されたQoSリソースの前記割振りを受信し、前記STATUSメッセージが、前記グループ通信セッションが開始可能であることを前記アクセス端末に対して示す、請求項1に記載の方法。
フラグを含むように前記呼メッセージを構成するステップ
をさらに含み、受信する前記ステップが、アクセスネットワークから前記QoSリソースの割振りを受信し、前記QoSリソースの割振りが、前記呼メッセージに含まれる前記フラグによってトリガされる
請求項1に記載の方法。
前記フラグが前記呼メッセージのヘッダ部分に含まれるディフサーブコードポイント(DSCP)値に対応する請求項4に記載の方法。
前記フラグが、前記メッセージの発信者に対してQoSリソースを割り振るように、前記アクセスネットワークに指示するように構成された値を含む請求項4に記載の方法。
前記グループ通信セッションが、(i)前記アクセス端末と1つの他のアクセス端末との間の呼、または(ii)前記アクセス端末と2つ以上の他のアクセス端末との間の呼に対応する請求項1に記載の方法。
受信する前記ステップが、アクセスネットワークから前記QoSリソースの割振りを受信し、前記QoSリソースの割振りが、前記グループ通信セッションを調停するように構成された前記アプリケーションサーバで開始するメッセージに含まれるフラグによってトリガされる請求項1に記載の方法。
前記フラグ付きのメッセージが、前記呼メッセージを肯定応答するメッセージ、または前記グループ通信セッションが開始可能であることを前記アクセス端末に示すように構成されたメッセージに対応する請求項8に記載の方法。
前記フラグが、前記メッセージの宛先またはターゲットに対してQoSリソースを割り振るように、前記アクセスネットワークに指示するように構成された値を含む請求項8に記載の方法。
前記フラグが前記フラグ付きのメッセージのヘッダ部分に含まれるディフサーブコードポイント(DSCP)値に対応する請求項8に記載の方法。
QoSリソースについての前記要求が失敗したことを決定するステップと、
QoSリソースについての前記要求が失敗したと決定される場合であっても、前記グループ通信セッションの試行を失敗しないステップと、
失敗しない前記ステップの後、前記呼メッセージを送る前記ステップを実行するステップと
をさらに含む請求項1に記載の方法。
決定する前記ステップが、タイマーの満了または前記要求の失敗を示すメッセージに基づく請求項12に記載の方法。
前記第2のアクセス端末識別子を取得するために、識別子の要求を送るステップと、
前記識別子の要求に応答して、前記第2のアクセス端末識別子を割り当てる割当てメッセージを受信するステップと
をさらに含み、前記第2のアクセス端末識別子が割り当てられる前に、前記要求を送る前記ステップが実行され、前記第2のアクセス端末識別子が割り当てられた後、前記呼メッセージを送る前記ステップが実行される
請求項1に記載の方法。
前記第1および第2のアクセス端末識別子がユニキャストアクセス端末識別子(UATI)に対応する請求項1に記載の方法。
前記第1および第2のサービングエリアが前記ワイヤレス通信システム内の異なるセルまたはセクタに対応する請求項1に記載の方法。
前記要求が、ReservationOnRequestメッセージ、データオーバシグナリング(DoS)メッセージ、ConnectionRequestメッセージ、およびRouteUpdateメッセージを含むバンドルされたメッセージに対応する請求項1に記載の方法。
ワイヤレス通信システム内で、アクセス端末でサービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップする方法であって、
第2のサービングエリア内で、前記グループ通信セッションのためのトラフィックチャネル(TCH)およびQoSリソースを取得するために、第1の要求を送るステップであり、前記第1の要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、ステップと、
前記TCHリソースが前記アクセス端末に割り振られていること、および前記QoSリソースが前記アクセス端末に割り振られていないことを決定するステップと、
決定する前記ステップに応答して、前記第2のサービングエリア内で、前記グループ通信セッションのための前記QoSリソースを要求する第2の要求を送るステップであり、前記第2の要求が、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、ステップと、
前記第2の要求に応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するステップと
を含む方法。
前記第1の要求が前記要求されたQoSリソースを取得することに失敗したことを決定するステップと、
前記第1の要求が前記要求されたQoSリソースを取得することに失敗したと決定される場合であっても、前記グループ通信セッションの試行を失敗しないステップと、
失敗しない前記ステップの後、前記第2の要求を送る前記ステップを実行するステップと
をさらに含む請求項18に記載の方法。
QoSリソースについての前記要求が失敗したことを決定する前記ステップが、タイマーの満了または前記第1の要求の失敗を示すメッセージに基づく請求項18に記載の方法。
前記第2のアクセス端末識別子を取得するために、識別子の要求を送るステップと、
前記識別子の要求に応答して、前記第2のアクセス端末識別子を割り当てる割当てメッセージを受信するステップと
をさらに含み、前記第2のアクセス端末識別子が割り当てられる前に、前記第1の要求を送る前記ステップが実行され、前記第2のアクセス端末識別子が割り当てられた後、前記第2の要求を送る前記ステップが実行される
請求項18に記載の方法。
前記第1および第2のアクセス端末識別子がユニキャストアクセス端末識別子(UATI)に対応する請求項18に記載の方法。
前記第1および第2のサービングエリアが前記ワイヤレス通信システム内の異なるセルまたはセクタに対応する請求項18に記載の方法。
前記第1の要求が、ReservationOnRequestメッセージ、データオーバシグナリング(DoS)メッセージ、ConnectionRequestメッセージ、およびRouteUpdateメッセージを含むバンドルされたメッセージに対応する請求項18に記載の方法。
前記グループ通信セッションが、(i)前記アクセス端末と1つの他のアクセス端末との間の呼、または(ii)前記アクセス端末と2つ以上の他のアクセス端末との間の呼に対応する請求項18に記載の方法。
ワイヤレス通信システム内で、アクセスネットワークでサービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップする方法であって、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るよう前記アクセスネットワークを促すように構成されたフラグを含むメッセージを受信するステップと、
前記QoSリソースが前記アクセス端末にすでに割り振られているかどうかを決定するステップと、
決定する前記ステップが前記QoSリソースがまだ割り振られていないことを決定した場合、前記QoSリソースを前記アクセス端末に割り振るステップと
を含む方法。
第2のサービングエリア内で、前記QoSリソースについての要求を受信するステップであり、前記要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子を含む、ステップと、
前記第1のアクセス端末識別子が前記第2のサービングエリア内で前記アクセス端末を識別しないので前記要求を認めないステップと
をさらに含む請求項26に記載の方法。
前記第2のサービングエリア内で、アプリケーションサーバによる前記グループ通信セッションのセットアップを要求する呼メッセージを受信するステップであり、前記呼メッセージが、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、ステップ
をさらに含む請求項27に記載の方法。
前記呼メッセージが、前記受信されたメッセージに対応する請求項28に記載の方法。
前記アプリケーションサーバに前記呼メッセージを転送するステップと、
前記アプリケーションサーバから前記転送された呼メッセージの肯定応答を受信するステップと
をさらに含み、前記受信されたメッセージが前記肯定応答に対応する
請求項28に記載の方法。
前記第2のアクセス端末識別子を取得するために、前記アクセス端末から識別子の要求を受信するステップと、
前記識別子の要求に応答して、前記アクセス端末に前記第2のアクセス端末識別子を割り当てる割当てメッセージを送るステップと
をさらに含み、前記メッセージを受信する前記ステップが、前記第2のアクセス端末識別子が割り当てられた後、前記メッセージを受信する
請求項28に記載の方法。
前記第1および第2のアクセス端末識別子がユニキャストアクセス端末識別子(UATI)に対応する請求項28に記載の方法。
前記第1および第2のサービングエリアが前記ワイヤレス通信システム内の異なるセルまたはセクタに対応する請求項28に記載の方法。
受信する前記ステップが、前記アクセス端末から、または前記グループ通信セッションを調停するように構成されたアプリケーションサーバから前記メッセージを受信する請求項26に記載の方法。
前記メッセージが、前記グループ通信セッションが開始可能であることを前記アクセス端末に命令するように構成された、前記アクセス端末に送信するための前記アプリケーションサーバから受信されたメッセージに対応する請求項34に記載の方法。
前記メッセージがSTATUSメッセージである請求項35に記載の方法。
前記フラグが前記受信されたメッセージのヘッダ部分に含まれるディフサーブコードポイント(DSCP)値に対応する請求項26に記載の方法。
前記グループ通信セッションが、(i)前記アクセス端末と1つの他のアクセス端末との間の呼、または(ii)前記アクセス端末と2つ以上の他のアクセス端末との間の呼に対応する請求項26に記載の方法。
ワイヤレス通信システム内で、グループ通信セッションを調停するように構成されたアプリケーションサーバでサービス品質(QoS)リソースを必要とする前記グループ通信セッションをセットアップする方法であって、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るようアクセスネットワークを促すように構成されたフラグを含むようにメッセージを構成するステップと、
前記アクセス端末に送信するために、前記構成されたメッセージをアクセスネットワークに転送するステップと
を含む方法。
前記アプリケーションサーバによって前記グループ通信セッションのセットアップを要求する呼メッセージを前記アクセス端末から受信するステップと、
前記アクセス端末に送信するために、前記呼メッセージの肯定応答を前記アクセスネットワークに転送するステップと
をさらに含み、前記構成されたメッセージが前記転送された肯定応答に対応する
請求項39に記載の方法。
前記アプリケーションサーバによって前記グループ通信セッションのセットアップを要求する呼メッセージを前記アクセス端末から受信するステップと、
ターゲットアクセス端末のグループに送信するために、前記アクセスネットワークに告知メッセージを転送するステップと、
前記告知されたグループ通信セッションが受け付けられたことを示す受付けメッセージをターゲットアクセス端末の前記グループのうちの1つから受信するステップと、
前記受信された受付けメッセージに応答して、前記グループ通信セッションが開始可能であることを示すステータスメッセージを、前記アクセス端末に送信するために、前記アクセスネットワークに転送するステップと
をさらに含み、前記構成されたメッセージが前記転送されたステータスメッセージに対応する
請求項39に記載の方法。
前記グループ通信セッションが、(i)前記アクセス端末と1つの他のアクセス端末との間の呼、または(ii)前記アクセス端末と2つ以上の他のアクセス端末との間の呼に対応する請求項39に記載の方法。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセス端末であって、
第2のサービングエリア内で、QoSリソースについての要求を送るための手段であり、前記要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、手段と、
前記第2のサービングエリア内で、アプリケーションサーバによる前記グループ通信セッションのセットアップを要求する呼メッセージを送るための手段であり、前記呼メッセージが、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、手段と、
前記呼メッセージに応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するための手段と
を含むアクセス端末。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセス端末であって、
第2のサービングエリア内で、前記グループ通信セッションのためのトラフィックチャネル(TCH)およびQoSリソースを取得するために、第1の要求を送るための手段であり、前記第1の要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、手段と、
前記TCHリソースが前記アクセス端末に割り振られていること、および前記QoSリソースが前記アクセス端末に割り振られていないことを決定するための手段と、
決定する前記ステップに応答して、前記第2のサービングエリア内で、前記グループ通信セッションのための前記QoSリソースを要求する第2の要求を送るための手段であり、前記第2の要求が、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、手段と、
前記第2の要求に応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するための手段と
を含むアクセス端末。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセスネットワークであって、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るよう前記アクセスネットワークを促すように構成されたフラグを含むメッセージを受信するための手段と、
前記QoSリソースが前記アクセス端末にすでに割り振られているかどうかを決定するための手段と、
決定する前記ステップが前記QoSリソースがまだ割り振られていないことを決定した場合、前記QoSリソースを前記アクセス端末に割り振るための手段と
を含むアクセスネットワーク。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションを調停するように構成されたアプリケーションサーバであって、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るようアクセスネットワークを促すように構成されたフラグを含むようにメッセージを構成するための手段と、
前記アクセス端末に送信するために、前記構成されたメッセージをアクセスネットワークに転送するための手段と
を含むアプリケーションサーバ。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセス端末であって、
第2のサービングエリア内で、QoSリソースについての要求を送るように構成された論理であり、前記要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、論理と、
前記第2のサービングエリア内で、アプリケーションサーバによる前記グループ通信セッションのセットアップを要求する呼メッセージを送るように構成された論理であり、前記呼メッセージが、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、論理と、
前記呼メッセージに応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するように構成された論理と
を含むアクセス端末。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセス端末であって、
第2のサービングエリア内で、前記グループ通信セッションのためのトラフィックチャネル(TCH)およびQoSリソースを取得するために、第1の要求を送るように構成された論理であり、前記第1の要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、論理と、
前記TCHリソースが前記アクセス端末に割り振られていること、および前記QoSリソースが前記アクセス端末に割り振られていないことを決定するように構成された論理と、
決定する前記ステップに応答して、前記第2のサービングエリア内で、前記グループ通信セッションのための前記QoSリソースを要求する第2の要求を送るように構成された論理であり、前記第2の要求が、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、論理と、
前記第2の要求に応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するように構成された論理と
を含むアクセス端末。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセスネットワークであって、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るよう前記アクセスネットワークを促すように構成されたフラグを含むメッセージを受信するように構成された論理と、
前記QoSリソースが前記アクセス端末にすでに割り振られているかどうかを決定するように構成された論理と、
決定する前記ステップが、前記QoSリソースがまだ割り振られていないことを決定した場合、前記QoSリソースを前記アクセス端末に割り振るように構成された論理と
を含むアクセスネットワーク。
ワイヤレス通信システム内で、サービス品質(QoS)リソースを必要とするグループ通信セッションを調停するように構成されたアプリケーションサーバであって、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るようアクセスネットワークを促すように構成されたフラグを含むようにメッセージを構成するように構成された論理と、
前記アクセス端末に送信するために、前記構成されたメッセージをアクセスネットワークに転送するように構成された論理と
を含むアプリケーションサーバ。
ワイヤレス通信システム内でサービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセス端末によって実行されると前記アクセス端末に操作を実行させる命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令が、
第2のサービングエリア内で、QoSリソースについての要求を送るためのプログラムコードであり、前記要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、プログラムコードと、
前記第2のサービングエリア内で、アプリケーションサーバによる前記グループ通信セッションのセットアップを要求する呼メッセージを送るためのプログラムコードであり、前記呼メッセージが、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、プログラムコードと、
前記呼メッセージに応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するためのプログラムコードと
を含む非一時的コンピュータ可読記憶媒体。
ワイヤレス通信システム内でサービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセス端末によって実行されると前記アクセス端末に操作を実行させる命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令が、
第2のサービングエリア内で、前記グループ通信セッションのためのトラフィックチャネル(TCH)およびQoSリソースを取得するために、第1の要求を送るためのプログラムコードであり、前記第1の要求が、前記第2のサービングエリアとは別の第1のサービングエリア内の前記アクセス端末を識別する第1のアクセス端末識別子に少なくとも部分的に基づく、プログラムコードと、
前記TCHリソースが前記アクセス端末に割り振られていること、および前記QoSリソースが前記アクセス端末に割り振られていないことを決定するためのプログラムコードと、
決定する前記ステップに応答して、前記第2のサービングエリア内で、前記グループ通信セッションのための前記QoSリソースを要求する第2の要求を送るためのプログラムコードであり、前記第2の要求が、前記第2のサービングエリア内の前記アクセス端末を識別する第2のアクセス端末識別子に少なくとも部分的に基づく、プログラムコードと、
前記第2の要求に応答して前記第2のサービングエリア内の前記要求されたQoSリソースの割振りを受信するためのプログラムコードと
を含む非一時的コンピュータ可読記憶媒体。
ワイヤレス通信システム内でサービス品質(QoS)リソースを必要とするグループ通信セッションをセットアップするように構成されたアクセスネットワークによって実行されると前記アクセスネットワークに操作を実行させる命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令が、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るよう前記アクセスネットワークを促すように構成されたフラグを含むメッセージを受信するためのプログラムコードと、
前記QoSリソースが前記アクセス端末にすでに割り振られているかどうかを決定するためのプログラムコードと、
決定する前記ステップが前記QoSリソースがまだ割り振られていないことを決定した場合、前記QoSリソースを前記アクセス端末に割り振るためのプログラムコードと
を含む非一時的コンピュータ可読記憶媒体。
ワイヤレス通信システム内でサービス品質(QoS)リソースを必要とするグループ通信セッションを調停するように構成されたアプリケーションサーバによって実行されると前記アプリケーションサーバに操作を実行させる命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令が、
前記グループ通信セッションを開始するためのアクセス端末の試行に関連し、QoSリソースが前記アクセス端末にすでに割り振られているかどうかに基づいて前記QoSリソースを前記アクセス端末に条件付きで割り振るようアクセスネットワークを促すように構成されたフラグを含むようにメッセージを構成するためのプログラムコードと、
前記アクセス端末に送信するために、前記構成されたメッセージをアクセスネットワークに転送するためのプログラムコードと
を含む非一時的コンピュータ可読記憶媒体。