JP5734486B2 - ワイヤレス通信システム内の通信セッションの間の呼設定のＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ（ＱｏＳ）リソース予約の選択的なプロビジョニング - Google Patents

Description

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、全体が参照によって明白に本明細書に組み込まれる、2010年5月28日に出願した「SELECTIVELY PROVISIONING CALL SETUP QUALITY OF SERVICE (QoS) RESOURCE RESERVATIONS DURING A COMMUNICATION SESSION WITHIN A WIRELESS COMMUNICATIONS SYSTEM」という名称の仮出願第61/349,339号の優先権を主張する。

本発明は、ワイヤレス電気通信システムにおける通信に関し、より具体的には、ワイヤレス通信システム内の通信セッションの間の、呼設定のQuality of Service(QoS)リソース予約の選択的なプロビジョニングに関する。

ワイヤレス通信システムは、第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)が、基地局に隣接するかまたはこれを囲む特定の地理的領域内での通信リンクまたはサービスをサポートする、固定位置の基地局(セルサイトまたはセルとも呼ばれる)からの信号を受信する。基地局は、一般に、Quality of Service(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 High Rate Packet Data Air Interface、2006年9月12日 3GPP2 X.S0011-004-C Version 2.0 cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction specification TSB58-G Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards

休止ATが、少なくとも1つのターゲットATとの通信セッションを開始するための要求を受信する。この時点で、ATは、開始される通信セッションのための呼設定と関連付けられるアクティブTCHを有さず、またはその呼設定と関連付けられる少なくともIPフローのためのQoS予約を有さない。ATは、開始される通信セッションのための呼設定と関連付けられるIPフローのためのQoSリソース予約を少なくとも要求するようにメッセージを構成して、そのメッセージをアクセスネットワーク(AN)に送信する。ANは、IPフローのためのQoSリソース予約の要求を許可する。ある実施形態では、ANは、ATに割り当てられたTCHで、QoSリソース予約割当メッセージを送信することによって、QoSリソース要求を許可することができる。セッションのターゲットATはまた、アクティブTCHとIPフローのQoSリソース予約とを、ANによって割り振られる。

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

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

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

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

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

本明細書でアクセス端末(AT)と呼ぶHigh Data Rate(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を介してアクセスネットワークまたは無線アクセスネットワーク(RAN)120と通信している、セルラー電話102などのアクセス端末を含み得る。本明細書に示すように、アクセス端末は、セルラー電話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が押される)、無線アクセスネットワーク(RAN)120との通信を確立するために必要な情報がアクセスチャネルメッセージにバンドルされる(たとえば、接続要求(ConnectionRequest)およびルート更新情報(RouteUpdate)、通信に使用される任意のQoSサービスのプロビジョニング(ReservationOnRequest)など)。加えて、アプリケーション層データ(たとえばDataOverSignaling(DOS)メッセージ)がアクセスチャネルメッセージの中にバンドルされ、末端のアプリケーション(たとえば、グループサーバ、別のATに常駐するアプリケーションなど)との通信を促すことができる。アクセスメッセージが所望の情報とバンドルされると(たとえば、DOS+ConnectionRequest+RouteUpdate+ReservationOnRequest)、アクセスメッセージは、無線アクセスネットワーク(RAN)120へのアクセスチャネル(AC)を介して送信され得る(320)。

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

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

当業者が諒解するように、必要とされるQoSリソースは、異なるアプリケーションでは、またはアプリケーション内で変化し得る。以下の例では、異なるQoSリソースのシナリオの下で、QoS設計について説明する。
・トラフィックチャネルリソースおよびQoSリソース(たとえば、呼中シグナリングおよびメディア予約(In-Call Signaling and Media reservations))が発信者AT302セクタのセクタにおいて使用可能であるとき、RANは、呼中シグナリングおよびメディア予約のためにFwdReservationOnメッセージおよびRevReservationOnメッセージを送信することによって、順方向と逆方向の両方のリンクにQoSリソースが使用可能であることを信号で伝える。このケースは、図3Aに示され、上記の説明において説明されている。
・発信者AT302が位置するセクタにおいてトラフィックチャネルリソースが使用可能であり、しかし予約の一部または全部についてQoSリソースが使用不可であるとき、RAN120は、トラフィックチャネルを依然として割り振ることができ、発信者AT302にTCAメッセージを送信する。しかしながら、RAN120は、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は、RAN120とのトラフィックチャネル接続を確立し、次いで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 specificationで説明されるように、構成される。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を達成するために、トラフィックの区別は、エンドツーエンドで可能でなければならない。AT302、RAN120(BTS466、BSC464)、PDSN452を含むすべてのネットワーク構成要素、およびインターネットルータは、QoSを実装/サポートしなければならない。1xEV-DO Revision AネットワークにおけるエンドツーエンドのQoSは、以下の機構によって実現することができる。
・パケットフィルタ:PDSNマッピングにおけるパケットフィルタは、ATにトラフィックフローを転送し、データトラフィックを転送するために適用されるべきQoS処置を定義することができる。ATは、3GPP2 X.S0011-004-C Version 2.0 cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction specificationで説明されるように、そのPDSNにおいてパケットフィルタを確立する、QoS要求をシグナリングする。
・QoSプロファイル(プロファイルID):QoSプロファイルおよび/またはプロファイルIDは、データサービスのための関連するエアインターフェースパラメータおよびネットワークQoS要件を指定(またはあらかじめ定義)するための機構である。それは、フローのためのQoS予約をRANに要求するときATが使用する「簡略的な」識別子である。様々なデータサービスで利用可能な標準プロファイルID割当ては、その内容が参照により本明細書に組み込まれる、TSB58-G Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standardsに記載されている。
・逆方向トラフィックマーキング:ATは、Differentiated Services(DiffServ)のフレームワークおよび規格に従って、逆方向トラフィックデータをマーキングすることができる。これらのマーキングは、PDSNにおいてアウトバウンドデータについて要求されるQoSネットワーク処理を定義する。

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

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

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

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

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

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

たとえば、図7に示すように、アクセス端末(AT)472は、PTTシステムにおける告知メッセージまたは呼設定メッセージのような、トリガを受信することができる(705)。具体的には、呼設定メッセージを、PDSN452およびRAN120を介して送信することができる(705)。アクセスネットワーク120は、制御チャネル上で呼設定メッセージをターゲットAT472に転送することができる(710)。AT472は、呼設定パケットを受信し復号すると、要求された通信(たとえばPTT呼)がQoSリソースを使用すると決定することができる。したがって、ネットワークから受信された呼設定メッセージは、その後の応答のバンドリングを開始するためのトリガとして働き得る。

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

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

上で論じられたように、通信セッションは、呼設定シグナリングのためのフロー、呼中シグナリングのためのフロー、およびメディアのためのフローを含む、3つのIPフローをATにおいて含み得る。これらの3つのフローの各々は、所与のQoSリソース予約要件と関連付けられ得る。従来は、呼設定シグナリングフローのためのQoSリソース予約は常にオンにされているが、呼中シグナリングおよびメディアのためのQoSリソース予約は、それぞれのIPフローを要求する通信セッションがアクティブである場合、または設定中である場合のみ、オンにされる。シグナリングチャネルを通じたデータの送信を許可しないネットワーク(たとえば、data-over-signaling(DoS)をサポートしない、またはネットワークの1つもしくは複数のセクタにおいて無効にされるDoSを有する、EV-DOネットワークなど)において、呼設定シグナリングIPフローのためのQoSリソース予約を常にオンに保つことによって、従来の呼設定のレイテンシは低減する可能性がある。それは、呼発信者が、RAN120との呼設定シグナリングの交換の間に、ある量のQoSリソースを保証されるからである。本発明の実施形態は全般に、EV-DOの専門用語(たとえば、アクセスチャネル、順方向トラフィックチャネル(F-TCH)、RouteUpdate、ConnectionRequestなど)に関して以下で説明されるが、他の実施形態は、W-CDMAのような他のエアインターフェースを対象にできることが、諒解されよう。呼設定処理の例が、図8Aおよび図8Bに関して以下で説明される。

したがって、図8Aおよび図8Bは、サーバ調停型の通信セッションの呼設定処理を示す。図8Aを参照すると、800において、AT1は休止状態にあると仮定し、したがって、AT1はアクティブトラフィックチャネル(TCH)を有さず、メディアおよび呼中IPフローのためのQoSリソース予約も有さない。しかし、AT1の呼設定IPフローのための、AT1のQoSリソース予約は「オン」である(たとえば、現在RAN120によってAT1に割り振られており、またはRAN120によってAT1のために予約されている)。やはり、ATが休止状態であったとしても、ATのための呼設定IPフローのQoSリソース予約は、従来は常に「オン」である。

次に、802において、AT1が休止状態にある間に、AT1のユーザがサーバ調停型の通信セッション(たとえば、PTTセッション、VoIPセッション、グループ通信セッション、半二重通信セッション、全二重通信セッションなど)の開始を要求すると仮定する。たとえば、PTTセッションの場合、802のトリガ操作は、PTT通信セッションを開始するために、AT1のユーザがAT1上のPTTボタンを押すことに対応し得る。

通信セッション要求がAT1で受信された後、AT1は、RouteUpdateメッセージ、ConnectionRequestメッセージ、およびReservationOnRequestメッセージを、逆方向リンクアクセスチャネル(AC)で、RAN120に送る(804)。804のReservationOnRequestメッセージ、またはROnRメッセージは、IPフロー1(すなわち呼中IPフロー)およびIPフロー2(すなわちメディアIPフロー)のためのQoSリソース予約は要求するが、IPフロー0(すなわち呼設定IPフロー)のためのQoSリソース予約は要求しない。それは、IPフロー0のためのQoSリソースは常にAT1のために予約されまたは割り振られているが、IPフロー1および2のためのQoSリソース予約は、AT1が関与する通信セッションの間だけオンにされるからである。

諒解されるように、804で送信されるメッセージは必ずしも、呼メッセージとはバンドルされず、かつ/またはdata over signaling(DoS)パケットに含まれない。RAN120は、ダウンリンク制御チャネル上でアクセスチャネル肯定応答(ACAck)をAT1に送ることによって、804からのメッセージの受信に肯定応答する(806)。808において、RAN120は、804からのConnectionRequestメッセージに応答して、ダウンリンク制御チャネル上でTCH割当をAT1に送り、RAN120は、(たとえば、図8Aには示されないAT1からのDRCおよびパイロットの受信および復号に成功した後で)TCH Assignmentメッセージの中で、AT1に割り振られた順方向トラフィックチャネル(F-TCH)上で、Reverse Traffic Channel Acknowledge(RTCAck)メッセージを送信する(810)。RTCAckメッセージを受信すると、AT1は、新たに割り振られた逆方向トラフィックチャネル(R-TCH)上で、Traffic Channel Complete(TCC)メッセージをRAN120に送ることができる(812)。RAN120はまた、IPフロー1(すなわち呼中IPフロー)およびIPフロー2(すなわちメディアIPフロー)のための要求されたQoSリソース予約がAT1のために予約されまたは割り振られたことを示すReservation Acceptメッセージを、AT1に送る(814)。814で示されるように、単一のReservation Acceptメッセージは、複数の「一方向の」QoSフロー(すなわち、複数の逆方向リンクQoSフロー、または順方向リンクQoSフロー)に対して送られ得る。しかし、異なるReservation Acceptメッセージは、異なる方向のQoSフローに対して送られるように、EV-DOプロトコルによって要求される。たとえば、Reservation Acceptは、予約許可メッセージ(FwdReservationOnまたはRevReservationOnメッセージのような)ごとに必要である。

TCHを取得した後、AT1は、R-TCH上で少なくとも1つの呼メッセージを送り(たとえば、STATUSメッセージがRAN120から受信されるまで、500msごとのような所与の間隔で)(816)、RAN120は、少なくとも1つの呼メッセージをアプリケーションサーバ170に転送する(818)。アプリケーションサーバ170は、「構成された」告知メッセージ(ANN)を、AT2...Nへの送信のためにRAN120に転送し(820)、また、少なくとも1つの呼メッセージの受信をRAN120に肯定応答し(822)、RAN120はCALL-ACKメッセージをF-TCH上でAT1に転送し戻す(824)。820において、ANNは、AT2...NからのQoSリソースのための明示的な要求なしで、呼び出し(828における)に応答するAT2...NにQoSリソースを先取りで割り振るように、RAN120に促すように構成される。この先取り的なQoSリソース割振りの機構は、「予測」QoSと呼ばれ得る。ある例では、820において、アプリケーションサーバ170は、事前に定められたビット列をANNのIPヘッダに挿入して、AT2...Nのうちの呼び出しに応答する任意の呼ターゲットにQoSリソースを割り振る(たとえば、FwdReservationOnおよびRevReservationOnメッセージを840および842において送ることによって)ように、RAN120をトリガすることができる。さらなる例では、事前に定められたビット列は、ANNのIPヘッダに含まれる所与のDSCP値に対応し得る。

図8Aを参照すると、826において、呼要求がターゲットAT2...Nへの通信セッションの開始を要求しており(たとえば、直接の呼、またはN=2の1対1の呼、またはN>2のグループ通信セッションのために)、ターゲットAT2...Nの各々がTCHのない休止状態にあり、QoSリソースが呼設定IPフロー0に対しては予約されているが、呼中IPフロー1および/またはメディアIPフロー2に対しては予約されていないと、仮定する。したがって、アプリケーションサーバ170からの告知メッセージANNを受信すると、RAN120は、ダウンリンク制御チャネル上で呼出メッセージを送ることによって、AT2...Nの各々を呼び出す(828)。AT2...Nの各々は、逆方向リンクアクセスチャネル上でConnectionRequestメッセージおよびRouteUpdateメッセージを送ることによって、呼び出しに応答すると仮定する(830)。ある例では、呼び出し応答は、ハイレベルのマルチメディアアプリケーションに対する呼び出しの受信をハイレベルのマルチメディアアプリケーションに必ずしも通知することなく、自動的に呼び出しに応答して、QoSを要求するかどうか判定するように構成される、ローレベルのアプリケーションによって処理されるので、QoSの要求はこの時点ではAT2...Nから送られない。言い換えると、呼び出しは、様々な理由でAT2...Nに到達し、呼び出しは、告知メッセージANNと関連付けられる通信セッションを管理している特定のハイレベルのマルチメディアアプリケーションとは、必ずしも関連しない。したがって、下位層のアプリケーションは、ハイレベルのマルチメディアアプリケーションに呼び出しを必ずしも通知しない。しかし、820のANNは、RAN120による先取り的なQoSリソース割振りを促すように構成されるので、実際には、QoSリソースの明示的な要求を、AT2...Nによって送ることは必要とされない。RAN120は、ダウンリンク制御チャネル832でAT2...NにACAckメッセージを送ることによって、830からのメッセージに肯定応答し、ダウンリンク制御チャネルでTCH割当メッセージを送ることによって、TCHをAT2...Nに割り当てる(834)。RAN120は、(たとえば、図8Aには示されないAT2...NからのDRCおよびパイロットの受信および復号に成功した後)TCH Assignmentメッセージの中でAT2...Nに割り振られる順方向トラフィックチャネル(F-TCH)で、Reverse Trafic Channel Acknowledge(RTCAck)メッセージを送信する(836)。

RTCAckメッセージを受信すると、AT2...Nは、新たに割り振られた逆方向トラフィックチャネル(R-TCH)上で、Traffic Channel Complete(TCC)メッセージをRAN120に送ることができる(838)。次に、RAN120は、FwdReservationOnメッセージおよびRevReservationOnメッセージをAT2...Nに送り、呼中IPフロー1およびメディアIPフロー2のためのQoSリソースを割振りまたは予約する(840および842)。ある例では、840および842においてAT2...Nに送られるFwdReservationOnメッセージおよびRevReservationOnメッセージは、AT2...NからのQoSリソースの明示的な要求(たとえばReservationOnRequestメッセージ)ではなく、820のANNメッセージのIPヘッダ構成によってトリガされ得る。諒解されるように、呼設定IPフロー0のためのQoSリソース予約はすでに割り振られ、図8Aの処理ではこの時点でAT2...Nに割り振られる必要はない。

図8Bを見ると、RAN120は、F-TCH上で告知メッセージをAT2...Nに送る(844)。845において告知された呼をサポートし呼告知を受け入れ、したがって告知ACK(受け入れ)メッセージをR-TCH上でRAN120に送るのに、十分なQoSリソースが許可されたとAT2...Nは判定し(846)、RAN120は次いで、告知ACK(受け入れ)メッセージをアプリケーションサーバ170に転送する(848)。AT2...Nはまた、Reservation Acceptメッセージを送り、IPフロー1および2のための、順方向リンクおよび逆方向リンクQoS予約の受信を受け入れ、肯定応答する(850および852)。850および852で示されるように、異なるReservation Acceptメッセージは、RAN120によって840および842で割り振られるような異なる方向のQoSフローのために送られ、このとき840は順方向リンクQoSをカバーし、842は逆方向リンクQoSをカバーする。

告知された通信セッションに対する第1の応答側からの告知ACK(受け入れ)メッセージを受信すると、アプリケーションサーバ170は、AT1への送信のためにSTATUSメッセージをRAN120に送り(854)、RAN120は、F-TCH上でAT1にSTATUSメッセージを送信する(856)。STATUSメッセージを受信すると、AT1は、QoSリソース予約が、通信セッションに関連するAT1のIPフローの各々(たとえば、IPフロー0、1および2)に割り振られたかどうかを判定する(858)。この場合、IPフロー0、1および2の各々のためのQoSリソース予約がAT1に割り振られることがすでに確証されているので、AT1は858において呼を進めると決定する。したがって、AT1は、R-TCHでSTATUS-ACKメッセージをRAN120に送ることによって、STATUSメッセージに肯定応答し(860)、RAN120は次いで、STATUS-ACKメッセージをアプリケーションサーバ170に転送する(862)。

STATUS-ACKメッセージを受信すると、アプリケーションサーバ170は、AT1...Nへの送信のために、連絡メッセージをRAN120に送る(864および866)。ある例では、連絡メッセージは、通信セッションの間にAT1...Nの間のメディアの交換を扱うアプリケーションサーバ170におけるメディアサーバに、AT1...Nがどのように連絡できるかについての、情報を提供する。RAN120は、AT1のF-TCHで連絡メッセージをAT1に送信し(868)、AT2...NのそれぞれのF-TCHでAT2...Nにも送信する(870)。AT1において連絡メッセージを受信すると、AT1は、R-TCHでCONTACT-ACKをRAN120に送り(872)、RAN120は、AT1からのCONTACT-ACKをアプリケーションサーバ170に転送する(874)。同様に、AT2...Nにおいて連絡メッセージを受信すると、AT2...Nは、それぞれのR-TCHでCONTACT-ACKをRAN120に送り(876)、RAN120は、AT2...NからのCONTACT-ACKをアプリケーションサーバ170に転送する(878)。

連絡メッセージの中で連絡情報を受信した後、AT1...Nは、通信セッションの間に、アプリケーションサーバ170を通じてメディアを交換する(880および882)。諒解されるように、AT1は、AT1が呼を発信したのでフロア保有者として通信セッションを開始するが、フロア保有者は、呼中IPフロー上のシグナリングに基づいて、通信セッションの間に変化し得る。同様に、メディアは、メディアIPフローを用いてAT1...Nの間で転送される。こうして、IPフロー1および2のためのQoSリソース予約は、通信セッションの間「オン」になる。IPフロー0、すなわち呼設定IPフローのためのQoSリソース予約は、AT1...Nの各々に対して「常にオン」であると仮定されるので、これらのQoSのリソース予約も通信セッションの間「オン」である。

通信セッションの間、AT1は、通信セッションを終了するかどうかを定期的に判定する(884)。たとえば、AT1は、TCHが非アクティブであることによって、通信セッションを終了すると決定してもよく、または代替的には、AT1のユーザによる明示的な要求によって、通信セッションを終了すると決定してもよい。884において、AT1が通信セッションを終了しないと決定した場合、処理は880に戻り、通信セッションは継続する。そうではなく、884においてAT1が通信セッションを終了すると決定した場合、AT1は、R-TCH上でENDメッセージをRAN120に送り(886)、RAN120は、F-TCH上でEND-ACKメッセージによってENDメッセージに応答する(888)。そして、AT1は、ReservationOffRequestメッセージをR-TCH上でRAN120に送ることによって、IPフロー1および2のためのQoSリソース予約を解放し(890)、RAN120は、F-TCH上でReservation AcceptメッセージをAT1に送ることによって、IPフロー1および2のためのQoSリソース予約の割振り解除または解放を受け入れる(892)。この時点で、894において、AT1は800から休止状態に再び入るので、IPフロー1および2のためのQoSリソース予約は「オフ」になりまたは中止されるが、IPフロー0(すなわち呼設定IPフロー)のためのQoSリソース予約は維持される。動作884から894は、AT1において起きるものとして示されるが、AT2...Nもこれらの動作を実行できることが諒解されよう。言い換えると、AT2...Nは、通信セッションを終了するかどうかも、自身で決定することができる。しかし、AT2...Nで起きる可能性のあるこの決定の論理は、説明の便宜上図8Bでは省略されている。また、図8Bには示されないが、TCHの所与の非アクティブ期間の後、TCH非アクティブタイマーが満了し、TCHはAT1...Nにおいて切断される。

諒解されるように、AT1...Nにおいて呼設定IPフローのQoSリソース予約を保持することは、呼設定IPフローのためのQoSリソース予約が、図8Aおよび図8Bの処理の間に、AT1...Nによって要求される必要がなく、かつAT1...Nに割り振られる必要がないことを意味する。このことは、(たとえば、少なくとも、DoSをサポートしないか、1つまたは複数のセクタで無効にされるDoSを有するかのいずれかであるネットワークにおいて)図8Aおよび図8Bの通信セッション設定処理の時間を短くする可能性がある。しかし、AT1...Nにおいて呼設定フローのためのQoSリソース予約を保持することで、RAN120の容量(たとえばDoSが可能な容量)が減ることも、諒解されよう。AT1...Nが関与するアクティブな通信セッションが実際にはまったく実行されていない場合、上で述べられたQoSリソース予約と関連付けられるAT1...Nの呼設定IPフローが実際には使われていないとしても、容量の減少はシステムの性能を低下させ得る。

したがって、図9Aおよび図9Bは、本発明のある実施形態による、サーバ調停型の通信セッションのための呼設定処理を示し、このとき、所与のATの呼設定IPフローのためのQoSリソース予約は、通信セッションがアクティブであるまたは設定中である場合に「オン」にされ、それ以外の場合は「オフ」にされる。

図9Aを参照すると、900において、AT1は休止状態にあると仮定し、したがって、AT1はアクティブトラフィックチャネル(TCH)を有さず、メディアおよび呼中IPフローのために予約されるQoSリソースも有さない。さらに、図8Aおよび図8Bとは異なり、900の休止状態では、AT1は呼設定IPフローのためのQoSリソース予約も有さない。対照的に、図8Aおよび図8Bに示されるように、呼設定IPフローは、ATが休止状態であっても、従来は常に「オン」である。

次に、902において、AT1が休止状態にある間に、AT1のユーザがサーバ調停型の通信セッション(たとえば、PTTセッション、グループ通信セッションなど)の開始を要求すると仮定する。たとえば、PTTセッションの場合、902のトリガ操作は、PTT通信セッションを開始するために、AT1のユーザがAT1上のPTTボタンを押すことに対応し得る。

AT1において通信セッション要求が受信された後、AT1は、(たとえば、図3A、図3Bおよび/または図3Cの320におけるように)RouteUpdateメッセージ、ConnectionRequestメッセージ、ReservationOnRequestメッセージ、および呼メッセージを含むバンドルされたメッセージを、逆方向リンクアクセスチャネル(AC)上のDoSパケットの中で、RAN120に送る(904)。904のReservationOnRequestメッセージ、またはROnRメッセージは、IPフロー0(すなわち呼設定IPフロー)、IPフロー1(すなわち呼中IPフロー)、およびIPフロー2(すなわちメディアIPフロー)のための、QoSリソース予約を要求する。対照的に、図8Aの804においては、IPフロー0(すなわち呼設定IPフロー)のためのQoSリソース予約が図8Aではこの時点ですでにオンにされていたので、ReservationOnRequestメッセージは、IPフロー0に関連するQoSリソース予約を要求しなかった。また、呼メッセージを、RouteUpdateメッセージ、ConnectionRequestメッセージ、および/またはReservationOnRequestメッセージとともにDoSパケット内にバンドルすることが、本発明の実施形態であるので、呼メッセージは図8AではDoSパケットに含まれなかった。

したがって、図9Aにおいて、AT1は、逆方向リンクアクセスチャネルにおいて904のバンドルされたメッセージ内で呼メッセージを送り、RAN120は、呼メッセージをアプリケーションサーバ170に転送する(906)。RAN120は、ダウンリンク制御チャネル上でアクセスチャネル肯定応答(ACAck)をAT1に送ることによって、904からのメッセージの受信を肯定応答し(908)、904からのConnectionRequestメッセージに応答して、ダウンリンク制御チャネル上でTCH割当をAT1に送る(910)。

912において、RAN120は、(たとえば、図9Aには示されないAT1からのDRCおよびパイロットの受信および復号に成功した後)TCH Assignmentメッセージの中でAT1に割り振られる順方向トラフィックチャネル(F-TCH)で、Reverse Traffic Channel Acknowledge(RTCAck)メッセージを送信する。RTCAckメッセージを受信すると、AT1は、新たに割り振られた逆方向トラフィックチャネル(R-TCH)上で、Traffic Channel Complete(TCC)メッセージをRAN120に送ることができる(914)。RAN120はまた、IPフロー0(すなわち呼設定IPフロー)、IPフロー1(すなわち呼中IPフロー)およびIPフロー2(すなわちメディアIPフロー)のための、要求されたQoSリソース予約がAT1に割り振られたことを示すReservation Acceptメッセージを、AT1に送る(916)。

906においてRAN120から呼メッセージを受信すると、アプリケーションサーバ170は、告知メッセージ(ANN)を、AT2...Nへの送信のためにRAN120に転送し(918)、また、呼メッセージの受信をRAN120に肯定応答し(920)、RAN120はCALL-ACKメッセージをF-TCH上でAT1に送信し戻す(922)。図8Aの820におけるように、ANNは、AT2...NからのQoSリソースのための明示的な要求なしで、呼び出し(926における)に応答するAT2...NにQoSリソースを先取りで割り振るように、RAN120に促すように構成される。この先取り的なQoSリソース割振りの機構は、「予測」QoSと呼ばれ得る。ある例では、918において、アプリケーションサーバ170は、事前に定められたビット列をANNのIPヘッダに挿入して、AT2...Nのうちの呼び出しに応答する任意の呼ターゲットにQoSリソースを割り振る(たとえば、FwdReservationOnおよびRevReservationOnメッセージを938および940において送ることによって)ように、RAN120をトリガすることができる。さらなる例では、事前に定められたビット列は、ANNのIPヘッダに含まれる所与のDSCP値に対応し得る。

図9Aを参照すると、(たとえば900におけるAT1の休止状態と同様に)924において、呼要求が、ターゲットAT2...Nへの通信セッションの開始を要求しており、ターゲットAT2...Nの各々が、TCHのない休止状態にあり、呼設定IPフロー0、呼中IPフロー1および/またはメディアIPフロー2のために予約されるQoSリソースがないと、仮定する。

したがって、アプリケーションサーバ170からの告知メッセージANNを受信すると、RAN120は、ダウンリンク制御チャネル上で呼び出しメッセージを送ることによって、AT2...Nの各々を呼び出す(926)。AT2...Nの各々は、逆方向リンクアクセスチャネル上でConnectionRequestメッセージおよびRouteUpdateメッセージを送ることによって、呼び出しに応答すると仮定する(928)。ある例では、呼び出し応答は、ハイレベルのマルチメディアアプリケーションに対する呼び出しの受信をハイレベルのマルチメディアアプリケーションに必ずしも通知することなく、自動的に呼び出しに応答して、QoSを要求するかどうか判定するように構成される、ローレベルのアプリケーションによって処理されるので、QoSの要求はこの時点ではAT2...Nから送られない。言い換えると、呼び出しは、様々な理由でAT2...Nに到達し、呼び出しは、告知メッセージANNと関連付けられる通信セッションを管理している特定のハイレベルのマルチメディアアプリケーションとは、必ずしも関連しない。したがって、下位層のアプリケーションは、ハイレベルのマルチメディアアプリケーションに呼び出しを必ずしも通知しない。たとえば、942において、ハイレベルのマルチメディアアプリケーションは、ANNメッセージが受信されると呼を通知され、このことは、図9Aの実施形態では、(938および940において)AT2...NがQoSリソースを取得した後に起きる。言い換えると、918のANNは、RAN120による先取り的なQoSリソース割振りを促すように構成されるので、実際には、QoSリソースの明示的な要求を、AT2...Nによって送ることは必要とされない。RAN120は、ダウンリンク制御チャネル930でAT2...NにACAckメッセージを送ることによって、928からのメッセージに肯定応答し、ダウンリンク制御チャネルでTCH割当メッセージを送ることによって、TCHをAT2...Nに割り当てる(932)。RAN120は、(たとえば、図9Aには示されないAT2...NからのDRCおよびパイロットの受信および復号に成功した後)TCH Assignmentメッセージの中でAT2...Nに割り振られる順方向トラフィックチャネル(F-TCH)で、Reverse Trafic Channel Acknowledge(RTCAck)メッセージを送信する(934)。

RTCAckメッセージを受信すると、AT2...Nは、新たに割り振られた逆方向トラフィックチャネル(R-TCH)上で、Traffic Channel Complete(TCC)メッセージをRAN120に送ることができる(936)。次に、RAN120は、FwdReservationOnメッセージおよびRevReservationOnメッセージをAT2...Nに送り、呼設定IPフロー0、呼中IPフロー1およびメディアIPフロー2のためのQoSリソース予約を割り振る(938および940)。ある例では、938および940においてAT2...Nに送られるFwdReservationOnメッセージおよびRevReservationOnメッセージは、AT2...NからのQoSリソースの明示的な要求(たとえばReservationOnRequestメッセージ)ではなく、918のANNメッセージのIPヘッダ構成によってトリガされ得る。諒解されるように、図8Aおよび図8Bとは異なり、呼設定IPフロー0のためのQoSリソース予約が、938および940においてAT2...Nに割り振られる。

RAN120は、F-TCH上で告知(ANN)メッセージをAT2...Nに送る(942)。943において告知された呼をサポートし呼告知を受け入れ、したがって告知ACK(受け入れ)メッセージをR-TCHでRAN120に送るのに、十分なQoSリソースが許可されたとAT2...Nは判定し(944)、RAN120は次いで、告知ACK(受け入れ)メッセージをアプリケーションサーバ170に転送する(946)。AT2...Nはまた、Reservation Acceptメッセージを送り、IPフロー0、1および2のための、順方向リンクおよび逆方向リンクQoSリソース予約の受信を受け入れ、肯定応答する(948および950)。948および950で示されるように、異なるReservation Acceptメッセージは、RAN120によって938および940で割り振られるような異なる方向のQoSフローのために送られ、このとき938は順方向リンクQoSをカバーし、940は逆方向リンクQoSをカバーする。

告知された通信セッションに対する第1の応答側からの告知ACK(受け入れ)メッセージを受信すると、アプリケーションサーバ170は、AT1への送信のためにSTATUSメッセージをRAN120に送り(952)、RAN120は、F-TCH上でAT1にSTATUSメッセージを送信する(954)。図9Bを見ると、STATUSメッセージを受信すると、AT1は、QoSリソース予約が通信セッションのために割り振られたかどうかを判定する(956)。この場合、IPフロー0、1および2の各々のためのQoSリソース予約がAT1に割り振られることがすでに確証されているので、AT1は956において呼を進めると決定する。したがって、AT1は、R-TCHでSTATUS-ACKメッセージをRAN120に送ることによって、STATUSメッセージに肯定応答し(958)、RAN120は次いで、STATUS-ACKメッセージをアプリケーションサーバ170に転送する(960)。

STATUS-ACKメッセージを受信すると、アプリケーションサーバ170は、AT1...Nへの送信のために、連絡メッセージをRAN120に送る(962および964)。ある例では、連絡メッセージは、通信セッションの間にAT1...Nの間のメディアの交換を扱うアプリケーションサーバ170におけるメディアサーバに、AT1...Nがどのように連絡できるかについての、情報を提供する。RAN120は、AT1のF-TCHで連絡メッセージをAT1に送信し(966)、AT2...NのそれぞれのF-TCHでAT2...Nにも送信する(968)。AT1において連絡メッセージを受信すると、AT1は、R-TCHでCONTACT-ACKをRAN120に送り(970)、RAN120は、AT1からのCONTACT-ACKをアプリケーションサーバ170に転送する(972)。同様に、連絡メッセージを受信すると、AT2...Nは、それぞれのR-TCH上でCONTACT-ACKをRAN120に送り(974)、RAN120は、AT2...NからのCONTACT-ACKをアプリケーションサーバ170に転送する(976)。

連絡メッセージの中で連絡情報を受信した後、AT1...Nは、通信セッションの間に、アプリケーションサーバ170を通じてメディアを交換する(978および980)。諒解されるように、AT1は、AT1が呼を発信したのでフロア保有者として通信セッションを開始するが、フロア保有者は、呼中IPフロー上のシグナリングに基づいて、通信セッションの間に変化し得る。同様に、メディアは、メディアIPフローを用いてAT1...Nの間で転送され、通信セッションの最初の呼設定に関連するシグナリングは、呼設定IPフローを用いる。こうして、IPフローのためのQoSリソース予約は、通信セッションの間「オン」になる。

通信セッションの間、AT1は、通信セッションを終了するかどうかを定期的に判定する(982)。たとえば、AT1は、TCHが非アクティブであることによって、通信セッションを終了すると決定してもよく、または代替的には、AT1のユーザによる明示的な要求によって、通信セッションを終了すると決定してもよい。982において、AT1が通信セッションを終了しないと決定した場合、処理は978に戻り、通信セッションは継続する。そうではなく、982においてAT1が通信セッションを終了すると決定した場合、AT1は、R-TCH上でENDメッセージをRAN120に送り(984)、RAN120は、F-TCH上でEND-ACKメッセージによってENDメッセージに応答する(986)。そして、AT1は、ReservationOffRequestメッセージをR-TCH上でRAN120に送ることによって、IPフロー1および2のためのQoSリソース予約を解放し(988)、RAN120は、F-TCH上でReservation AcceptメッセージをAT1に送ることによって、IPフロー1および2のためのQoSリソース予約の割振り解除または解放を受け入れる(990)。この時点で、992において、IPフロー1および2のためのAT1のQoSリソース予約は「オフ」になりまたは中止されるが、IPフロー0(すなわち呼設定IPフロー)のためのQoSリソース予約は維持される。

992の後の何らかの時点において、AT1は、TCH休止タイマー(またはTCH非アクティブタイマー)の満了時間を超える期間の間非アクティブであり、そのためTCH休止タイマーが満了すると仮定する(994)。TCH休止タイマーの満了は、AT1が、Connection CloseメッセージをR-TCH上でRAN120に送ることによって、TCHを切断するのをトリガする(996)。この時点において、AT1におけるTCHは停止しており、IPフロー0のためのQoSリソース予約は「オフ」でありまたは中止される(998)。ある例では、図9Bに示されるように、AT1からのConnection Closeメッセージは、IPフロー0のための明示的なReservationOffRequestとして機能し得るので、IPフロー0のための明示的なReservationOffRequestを送る必要はない。別の実施形態では、図9Aおよび図9Bには示されないが、AT1は、996のConnection Closeメッセージに加えて、IPフロー0のための明示的なReservationOffRequestを送り、IPフロー0のためのQoSリソース予約をオフにすることができる。

ある代替的な実施形態では、ENDメッセージが984で送られる前に、TCH休止タイマーが満了し得ることが可能である。この場合、996のConnection Closeメッセージは、呼フロー中のこの早い時点においてTCH休止タイマーが満了すると、トリガされ得る。諒解されるように、この代替的な実施形態におけるConnection Closeメッセージは、IPフロー0、1および2の各々のための明示的なReservationOffRequestとして機能するように構成され得るので、IPフロー0、1および2のための明示的なReservationOffRequestメッセージを送る必要はない。別の実施形態では、図9Aおよび図9Bには示されないが、AT1は、「早い」Connection Closeメッセージに加えて、IPフロー0、1および2のための明示的なReservationOffRequestを送り、この代替的な実施形態におけるIPフロー0、1および2のためのQoSリソース予約をオフにすることができる。

動作982から998は、AT1において起きるものとして示されるが、AT2...Nはこれらの動作も実行できることが諒解されよう。言い換えると、AT2...Nは、通信セッションを終了するかどうかも、自身で決定することができる。しかし、AT2...Nで起きる可能性のあるこの決定の論理は、説明の便宜上図9Bでは省略されている。

さらに、上記の本発明の実施形態では、それぞれのAT(たとえば、図8Bの845および/または858、図9Bの943および/または956など)で実行されたQoS評価は、QoSが2値変数(すなわち、QoS「オン」またはQoS「オフ」)であるかのように説明されている。しかしながら、本発明の他の実施形態では、所与のATおよび/またはRAN120において異なる数の段階のQoSのレベルを評価することができる。たとえば、2値タイプの実装では、上記のように、グループ通信セッション管理アプリケーション(たとえばQChatクライアント)の起動時に、QoSレベルを交渉し、割り当てることができる。W-CDMAのこの実装形態は、1つのQoSフローのみが用いられ、このQoSフローはオンとオフのいずれかであるという意味で、2値タイプの実装形態に対応する。

あるいは、所与のATは、2つ以上のQoSフローを要求することができ、RAN120は、部分的ないくつかのフローのみを許可することができる。この意味で、要求されたQoSは、一例では、所与のATには「部分的に」しか使用可能にされないことがある。たとえば、RAN120は、順方向のQoSフローを許可し、逆方向のフローを拒否することができる。そのような割振りに基づいて、所与のATは、STATUSに肯定応答し(STATUSを受け付け)、後で逆方向のフローを再度要求すると決定することができる。言い換えると、図8Bの845および/もしくは858、または図9Bの943および/もしくは956の判定ブロックは、要求されたすべてのQoSが取得されたかどうかの代わりに、十分なレベルのQoSリソースが取得されたかどうかを評価することができる(たとえば、逆方向リンクQoSフローが半二重呼ターゲットにとってあまり重要でない順方向リンクQoSフロー、順方向リンクQoSフローが半二重呼発信者またはフロア保持者にとってあまり重要でない逆方向リンクQoSフローなど)。EV-DOのこの実装形態は、複数のQoSフローを展開し、QoSフローは、複数のフローのうちのいずれもが利用可能ではない場合、またはRAN120によってオンにされない場合、オフであると考えられる。

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

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

本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(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 エアインターフェース
120 無線アクセスネットワーク
122 基地局コントローラ/パケット制御機能
124 モデムプールトランシーバ
126 キャリアネットワーク
160 パケットデータサービングノード
165 ブロードキャストサービングノード
170 アプリケーションサーバ
175 インターネット
200 アクセス端末
202 プラットフォーム
206 送受信機
208 特定用途向け集積回路
210 アプリケーションプログラミングインターフェース
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
226 キーパッド
228 プッシュツートークボタン

Claims (18)

1. ワイヤレス通信システム内の通信セッションの間にQuality of Service(QoS)リソース予約を取得する方法であって、
   休止状態の発信側アクセス端末において、少なくとも1つのターゲットアクセス端末との通信セッションを開始するための要求を受信するステップであって、前記発信側アクセス端末の前記休止状態が、(i)前記発信側アクセス端末が、開始される前記通信セッションと関連付けられるアクティブトラフィックチャネル(TCH)を有さないことと、(ii)前記発信側アクセス端末が、少なくとも、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのための、QoSリソース予約を有さず、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別されることとによって特徴付けられる、ステップと、
   開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約を少なくとも要求するように、メッセージを構成するステップと、
   前記構成されたメッセージをアクセスネットワークに送信するステップとを含む、方法。
2. 前記構成されたメッセージが、(i)開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約の前記要求と、(ii)前記アクティブTCHの要求と、(iii)開始される前記通信セッションのための呼中シグナリングと関連付けられる前記IPフローのためのQoSリソース予約の要求と、(iv)開始される前記通信セッションのためのメディアと関連付けられるIPフローのためのQoSリソース予約の要求と、(v)呼要求メッセージと、(vi)位置更新メッセージとのうちの2つ以上を含む、バンドルされたメッセージに対応し、
   前記バンドルされたメッセージに応答して、前記アクセスネットワークから、前記要求されたTCHの割り当て、ならびに、開始される前記通信セッションのための、呼設定、呼中シグナリング、およびメディアの各々と関連付けられた前記IPフローの受け入れの通知を、受信するステップをさらに含む、請求項1に記載の方法。
3. 前記構成されたメッセージが、data-over-signaling(DoS)パケットであり、
   前記送信するステップが、前記構成されたメッセージを、シグナリングチャネルを通じて送信する、請求項1に記載の方法。
4. 前記アクセスネットワークが、開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約の前記要求を受け入れたことの通知を受信するステップをさらに含む、請求項1に記載の方法。
5. 前記通信セッションのための呼設定に関連付けられるIPフローは、前記通信セッションのための呼設定中にシグナリングを搬送するように構成され、
   前記構成されたメッセージは、呼設定中の前記シグナリングの少なくとも一部に適用されるQoSを取得するために、前記QoSリソース予約を要求する、請求項1に記載の方法。
6. 前記通信セッションのための呼設定に関連付けられる前記IPフローは、前記通信セッションの以前、前記通信セッション中、および前記通信セッション以降において維持され、
   前記通信セッションのための呼設定に関連付けられる前記IPフローは、前記要求が受信されたとき、前記QoSリソース予約をサポートしない状態である非QoS状態で動作し、
   前記構成されたメッセージは、前記通信セッションのための呼設定に関連付けられる前記IPフローが、前記非QoS状態から前記QoSリソース予約をサポートする状態であるQoS状態に移行するように要求する、請求項1に記載の方法。
7. ワイヤレス通信システム内のサーバ調停型の通信セッションの間にQuality of Service(QoS)リソース予約をプロビジョニングする方法であって、
   アクセスネットワークにおいて、発信側アクセス端末と少なくとも1つのターゲットアクセス端末との間の通信セッションを開始するための要求と関連して、第1のメッセージを受信するステップであって、前記第1のメッセージが、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのためのQoSリソース予約を少なくとも要求するように構成され、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、ステップと、
   前記第1のメッセージに応答して、第2のメッセージを送信するステップであって、前記第2のメッセージが、開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約のための、前記発信側アクセス端末による前記要求が、前記アクセスネットワークによって受け入れられていることを少なくとも示す、ステップとを含む、方法。
8. 前記第1のメッセージが、(i)開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約の前記要求と、(ii)トラフィックチャネル(TCH)の要求と、(iii)開始される前記通信セッションのための呼中シグナリングと関連付けられるIPフローのためのQoSリソース予約の要求と、(iv)開始される前記通信セッションのためのメディアと関連付けられる前記IPフローのためのQoSリソース予約の要求と、(v)呼要求メッセージと、(vi)位置更新メッセージとのうちの2つ以上を含む、バンドルされたメッセージに対応し、
   前記バンドルされたメッセージに応答して、前記アクセスネットワークから、前記要求されたTCHの割り当て、ならびに、開始される前記通信セッションのための、呼設定、呼中シグナリング、およびメディアの各々と関連付けられた前記IPフローの受け入れの通知を、送信するステップをさらに含む、請求項7に記載の方法。
9. 開始される前記通信セッションを調停するように構成されるアプリケーションサーバに、前記呼要求メッセージを転送するステップをさらに含む、請求項8に記載の方法。
10. 前記第1のメッセージが、data-over-signaling(DoS)パケット内に含まれ、シグナリングチャネル上で受信される、請求項7に記載の方法。
11. 前記通信セッションのための呼設定に関連付けられる前記IPフローは、前記通信セッションのための呼設定中にシグナリングを搬送するように構成され、
    前記第1のメッセージは、呼設定中の前記シグナリングの少なくとも一部に適用されるQoSを取得するために、前記QoSリソース予約を要求する、請求項7に記載の方法。
12. 前記通信セッションのための呼設定に関連付けられる前記IPフローは、前記通信セッションの以前、前記通信セッション中、および前記通信セッション以降において維持され、
    前記通信セッションのための呼設定に関連付けられる前記IPフローは、前記第1のメッセージが前記アクセスネットワークにおいて受信されたとき、前記QoSリソース予約をサポートしない状態である非QoS状態で動作し、
    前記第1のメッセージは、前記通信セッションのための呼設定に関連付けられる前記IPフローが、前記非QoS状態から前記QoSリソース予約をサポートする状態であるQoS状態に移行するように要求する、請求項7に記載の方法。
13. ワイヤレス通信システム内の通信セッションの間にQuality of Service(QoS)リソース予約を取得するように構成されるアクセス端末であって、
    前記アクセス端末が休止状態の間、少なくとも1つのターゲットアクセス端末との通信セッションを開始するための要求を受信するための手段であって、前記アクセス端末の前記休止状態が、(i)前記アクセス端末が、開始される前記通信セッションと関連付けられるアクティブトラフィックチャネル(TCH)を有さないことと、(ii)前記アクセス端末が、少なくとも、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのための、QoSリソース予約を有さず、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、こととによって特徴付けられる、手段と、
    開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約を少なくとも要求するように、メッセージを構成するための手段と、
    前記構成されたメッセージをアクセスネットワークに送信するための手段と
    を含む、アクセス端末。
14. ワイヤレスシステム内のサーバ調停型の通信セッションの間にQuality of Service(QoS)リソース予約をプロビジョニングするように構成されるアクセスネットワークであって、
    発信側アクセス端末と少なくとも1つのターゲットアクセス端末との間の通信セッションを開始するための要求と関連して、第1のメッセージを受信するための手段であって、前記第1のメッセージが、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのためのQoSリソース予約を少なくとも要求するように構成され、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、手段と、
    前記第1のメッセージに応答して、第2のメッセージを送信するための手段であって、開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約のための前記発信側アクセス端末による前記要求が、前記アクセスネットワークによって受け入れられていることを、前記第2のメッセージが少なくとも示す、手段とを含む、アクセスネットワーク。
15. ワイヤレス通信システム内の通信セッションの間にQuality of Service(QoS)リソース予約を取得するように構成されるアクセス端末であって、
    前記アクセス端末が休止状態の間、少なくとも1つのターゲットアクセス端末との通信セッションを開始するための要求を受信するように構成される論理回路であって、前記アクセス端末の前記休止状態が、(i)前記アクセス端末が、開始される前記通信セッションと関連付けられるアクティブトラフィックチャネル(TCH)を有さないことと、(ii)前記アクセス端末が、少なくとも、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのための、QoSリソース予約を有さず、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、こととによって特徴付けられる、論理回路と、
    開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約を少なくとも要求するように、メッセージを構成するように構成される論理回路と、
    前記構成されたメッセージをアクセスネットワークに送信するように構成される論理回路とを含む、アクセス端末。
16. ワイヤレス通信システム内のサーバ調停型の通信セッションの間にQuality of Service(QoS)リソース予約をプロビジョニングするように構成されるアクセスネットワークであって、
    発信側アクセス端末と少なくとも1つのターゲットアクセス端末との間の通信セッションを開始するための要求と関連して、第1のメッセージを受信するように構成される論理回路であって、前記第1のメッセージが、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのためのQoSリソース予約を少なくとも要求するように構成され、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、論理回路と、
    前記第1のメッセージに応答して、第2のメッセージを送信するように構成される論理回路であって、開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約のための前記発信側アクセス端末による前記要求が、前記アクセスネットワークによって受け入れられていることを、前記第2のメッセージが少なくとも示す、論理回路とを含む、アクセスネットワーク。
17. ワイヤレス通信システム内の通信セッションの間にQuality of Service(QoS)リソース予約を取得するように構成されるアクセス端末によって実行されると、前記アクセス端末に動作を実行させる命令を記録するコンピュータ可読記録媒体であって、前記命令が、
    前記アクセス端末が休止状態の間、少なくとも1つのターゲットアクセス端末との通信セッションを開始するための要求を受信するためのプログラムコードであって、前記アクセス端末の前記休止状態が、(i)前記アクセス端末が、開始される前記通信セッションと関連付けられるアクティブトラフィックチャネル(TCH)を有さないことと、(ii)前記アクセス端末が、少なくとも、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのための、QoSリソース予約を有さず、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、こととによって特徴付けられる、プログラムコードと、
    開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約を少なくとも要求するように、メッセージを構成するためのプログラムコードと、
    前記構成されたメッセージをアクセスネットワークに送信するためのプログラムコードとを含む、コンピュータ可読記録媒体。
18. ワイヤレス通信システム内の通信セッションの間にQuality of Service(QoS)リソース予約をプロビジョニングするように構成されるアクセスネットワークによって実行されると、前記アクセスネットワークに動作を実行させる命令を記録するコンピュータ可読記録媒体であって、前記命令が、
    発信側アクセス端末と少なくとも1つのターゲットアクセス端末との間の通信セッションを開始するための要求と関連して、第1のメッセージを受信するためのプログラムコードであって、前記第1のメッセージが、開始される前記通信セッションのための呼設定と関連付けられるインターネットプロトコル(IP)フローのためのQoSリソース予約を少なくとも要求するように構成され、前記開始される通信セッションのための呼設定と関連付けられるIPフローが、開始される前記通信セッションのためのメディアに関係付けられるIPフローと区別される、プログラムコードと、
    前記第1のメッセージに応答して、第2のメッセージを送信するためのプログラムコードであって、開始される前記通信セッションのための呼設定と関連付けられる前記IPフローのための前記QoSリソース予約のための前記発信側アクセス端末による前記要求が、前記アクセスネットワークによって受け入れられていることを、前記第2のメッセージが少なくとも示す、プログラムコードとを含む、コンピュータ可読記録媒体。

Images