JP5795660B2 - 通信システム内での通信セッションと関連付けられるデータの交換 - Google Patents

Description

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により明示的に本明細書に組み込まれる、2010年4月30日に出願された「EXCHANGING DATA ASSOCIATED WITH A COMMUNICATION SESSION WITHIN A COMMUNICATIONS SYSTEM」という名称の仮出願第61/330,179号の優先権を主張する。

本発明の実施形態は、通信システム内での通信セッションと関連付けられるデータの交換を対象とする。

ワイヤレス通信システムは、第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)にエントリポイントを与える。したがって、基地局は、一般に、over the airインターフェースによって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号に記載されているように、従来のシグナリング技法を使用するプッシュツートーク呼のためにブロードキャストチャネルを使用することができる。ブロードキャストチャネルの使用は従来のユニキャスト技法よりも帯域幅要件を改善することができるが、ブロードキャストチャネルの従来のシグナリングは、依然として追加のオーバヘッドおよび/または遅延を生じる可能性があり、システムパフォーマンスを劣化させることがある。

第3世代パートナーシッププロジェクト2(「3GPP2」)は、CDMA2000ネットワークにおけるマルチキャスト通信をサポートするためのブロードキャストマルチキャストサービス(BCMCS)規格を定義する。したがって、「CDMA2000 High Rate Broadcast-Multicast Packet Data Air Interface Specification」と題する、2006年2月14日付けの3GPP2のBCMCS規格のバージョンである、バージョン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日

ある実施形態では、アクセス端末は、少なくとも第1、第2、および第3の機能層を含み、第1の機能層(たとえばMAC層)は、第3の機能層(たとえばアプリケーション層)の代わりに、サービングネットワークを介して、データパケットをアプリケーションサーバへ送信することを試みる。サービングネットワークがデータパケットを受信したというACKを第1の機能層が受信すると、第3の機能層はACKを通知される。サービングネットワークへのデータパケットの送信の試みが失敗したと、第1の機能層が判定すると、第3の機能層は送信の失敗を通知される。別の実施形態では、通信セッションのためのトラフィックチャネル(TCH)のセットアップの間、アクセス端末は、アプリケーション層接続情報とトランスポート層接続情報の両方を含むメッセージを、シグナリングポートを通じてアプリケーションサーバに送信し、通信セッションのためのデータポートのセットアップを容易にする。

ある実施形態では、通信デバイスは、第1のアクセス端末と第2のアクセス端末の間で、第1のタイプの通信セッションと関連付けられる高優先度のデータを、さらに第2のタイプの通信セッションと関連付けられる低優先度のデータを、交換する。第1のアクセス端末がデータ速度の低い環境へ移行したと、通信デバイスが判定すると、通信デバイスは、第2のタイプの通信セッションのために第1のアクセス端末とアプリケーションサーバとの間で交換される、データパケットのサイズを低減する。次に来るデータパケットがデータの少ないパケット(たとえば無音パケット)であると通信デバイスが判定すると、データの少ないパケットは圧縮される。第1のアクセス端末が、シーケンスの中で最後のデータパケットまたは最後に近いデータパケットのセットの送信を試みたと、通信デバイスが判定すると、通信デバイスは、ACKを待機することなく、最後のデータパケットまたは最後に近いデータパケットのセットを再送信する。

ある実施形態では、どのウィンドウがATに目立つように表示されるかに基づいて、オブジェクトがアクセス端末(AT)にダウンロードされる。別の実施形態では、ユーザ規定のオブジェクトのダウンロード優先順位のセットに基づいて、オブジェクトがATにダウンロードされる。別の実施形態では、ストリーミングデータセッションと関連付けられるウィンドウの第1のセットから、異なるセッションと関連付けられるウィンドウの第2のセッションへの、ATのディスプレイの移行に応答して、ATへのストリーミングデータセッションの一部が優先順位を下げられる。たとえば、優先順位の低下により、一部(たとえば、音声および映像会議の映像部分)が省略されまたは減らされることになり得る。別の実施形態では、ATが制限された環境に入ったことに応答して、ATにダウンロードされるオブジェクトが、ATの制限された環境と順応するように動的に変更され得る。

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

本発明の少なくとも1つの実施形態による、アクセス端末とアクセスネットワークとをサポートするワイヤレスネットワークアーキテクチャの図である。 本発明のある実施形態による、キャリアネットワークを示す図である。 図1のワイヤレス通信の例をより詳細に示す図である。 本発明の少なくとも1つの実施形態による、アクセス端末(AT)の図である。 ファイルが通信システムにおいてAT間で交換され得る際の、従来の方式を示す図である。 ファイルが通信システムにおいてAT間で交換され得る際の、別の従来の方式を示す図である。 本発明のある実施形態による、発信側ATとターゲットATとの間のファイル転送セッションのセットアップと関連付けられるシグナリングを示す図である。 本発明のある実施形態による、発信側ATとターゲットATとの間のファイル転送セッションのセットアップと関連付けられるシグナリングを示す図である。 通信セッションの間の、発信側アクセス端末またはターゲットアクセス端末の異なる機能層の間の、対話の実施形態を示す図である。 通信セッションの間の、発信側アクセス端末またはターゲットアクセス端末の異なる機能層の間の、対話の実施形態を示す図である。 通信セッションの間の、発信側アクセス端末またはターゲットアクセス端末の異なる機能層の間の、対話の実施形態を示す図である。 通信セッションの間の、発信側アクセス端末またはターゲットアクセス端末の異なる機能層の間の、対話の実施形態を示す図である。 ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、従来の機構を示す図である。 リアルタイムセッションまたはストリーミングセッションのパケット送信の遅延が低減および/または回避されるように、ファイル転送セッションのような非ストリーミングセッションのためのデータパケットのサイズが動的に調整される、本発明の実施形態を示す図である。 ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、別の従来の機構を示す図である。 リアルタイムセッションまたはストリーミングセッションのパケット送信の遅延が低減および/または回避されるように、アプリケーションサーバおよび/またはアクセスネットワークにおいて、ファイル転送セッションのようなダウンリンク非ストリーミングセッションのためのデータパケットのサイズが動的に調整される、本発明の実施形態を示す図である。 ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、従来の機構を示す図である。 ストリーミングマルチメディアセッションのためのサイレンスフレームが圧縮され、低サービス品質(QoS)のファイル転送セッションまたは非QoSのファイル転送セッションのためのより多数のデータパケットが送信される、本発明の実施形態を示す図である。 ストリーミングマルチメディアセッションのためのサイレンスフレームが圧縮され、低QoSのファイル転送セッションまたは非QoSのファイル転送セッションのためのより多数のデータパケットが送信される、本発明の別の実施形態を示す図である。 従来のファイル転送セッションの終了または完了に注目した処理を示す図である。 ファイル転送セッションの終わりにおける、送信ATとアプリケーションサーバとの間のシグナリングに注目した、別の従来の処理を示すので、受信ATとアプリケーションサーバとの間のシグナリングが点線により示される図である。 送信ATがトラフィックチャネル(TCH)を有しデータを送信していない期間における、データパケットの機会主義的な再送信に関連する処理を対象とする図である。 送信ATがトラフィックチャネル(TCH)を有しデータを送信していない期間における、データパケットの先取り的な再送信に関連する処理を対象とする図である。 本発明のある実施形態による、送信ATがTCHを有しデータを送信していない期間における、データパケットの機会主義的な再送信または先取り的な再送信に関連する、別の処理を対象とする図である。 本発明のある実施形態による、ファイル転送セッションと関連付けられた、コンテンツに基づく通信処理を示す図である。 本発明のある実施形態による、ファイル転送セッションと関連付けられた、コンテンツに基づく通信処理を示す図である。 本発明のある実施形態による、ファイル転送セッションと関連付けられた、コンテンツに基づく通信処理を示す図である。 本発明のある実施形態による、ファイル転送セッションと関連付けられた、コンテンツに基づく通信処理を示す図である。

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

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

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

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

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

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

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

RAN120は、基地局コントローラ/パケット制御機能(BSC/PCF)122に送信される(一般に、データパケットとして送信される)メッセージを制御する。BSC/PCF122は、パケットデータサービスノード100(「PDSN」)とアクセス端末102/108/110/112との間のベアラチャネル(すなわちデータチャネル)のシグナリング、確立および切断を担う。リンク層の暗号化が使用可能である場合、BSC/PCF122はまた、エアインターフェース104を介してコンテンツを転送する前にそのコンテンツを暗号化する。BSC/PCF122の機能は当技術分野でよく知られており、簡潔のためにさらに論じない。キャリアネットワーク126は、ネットワーク、インターネットおよび/または公衆交換電話網(PSTN)によってBSC/PCF122と通信することができる。代替的に、BSC/PCF122はインターネットまたは外部ネットワークに直接接続することができる。一般に、キャリアネットワーク126とBSC/PCF122との間のネットワークまたはインターネット接続はデータを転送し、PSTNは音声情報を転送する。BSC/PCF122は複数の基地局(BS)またはモデムプールトランシーバ(MPT)124に接続され得る。キャリアネットワークと同様の方法で、BSC/PCF122は一般に、データ転送および/または音声情報のために、ネットワーク、インターネットおよび/またはPSTNによってMPT/BS124に接続される。MPT/BS124は、携帯電話102などのアクセス端末にデータメッセージをワイヤレスにブロードキャストすることができる。MPT/BS124、BSC/PCF122および他の構成要素は、当技術分野で知られているように、RAN120を形成することができる。ただし、代替構成も使用でき、本発明は、図示の構成に制限されない。たとえば、別の実施形態では、BSC/PCF122の機能とMPT/BS124の1つまたは複数とを、BSC/PCF122とMPT/BS124の両方の機能を有する単一の「ハイブリッド」モジュールに縮小することができる。

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

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

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

図2Bに、図1のワイヤレス通信の例100をより詳細に示す。特に、図2Bを参照すると、AT1...Nは、異なるパケットデータネットワークエンドポイントによってサービスされる位置において、RAN120に接続するものとして示されている。したがって、AT1およびAT3は、(たとえば、PDSN160、BSN165、ホームエージェント(HA)、外部エージェント(FA)などに対応し得る)第1のパケットデータネットワークエンドポイント162によってサービスされる部分において、RAN120に接続する。第1のパケットデータネットワークエンドポイント162は、今度はルーティングユニット188を介して、インターネット175に、ならびに/または、認証、認可および課金(AAA)サーバ182、プロビジョニングサーバ184、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)/セッション開始プロトコル(SIP)登録サーバ186および/もしくはアプリケーションサーバ170のうちの1つまたは複数に、接続する。AT2およびAT5...Nは、(たとえば、PDSN160、BSN165、FA、HAなどに対応し得る)第2のパケットデータネットワークエンドポイント164によってサービスされる部分において、RAN120に接続する。第1のパケットデータネットワークエンドポイント162と同様に、第2のパケットデータネットワークエンドポイント164は、今度はルーティングユニット188を介して、インターネット175に、ならびに/または、AAAサーバ182、プロビジョニングサーバ184、IMS/SIP登録サーバ186および/もしくはアプリケーションサーバ170のうちの1つまたは複数に、接続する。AT4は、インターネット175に直接接続し、次いで、インターネット175を通して、上記で説明したシステム構成要素のうちのいずれかに接続することができる。

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

さらに、図2Bを参照すると、アプリケーションサーバ170は、複数のメディア制御コンプレックス(MCC)1...N170Bと複数の地域ディスパッチャ1...N170Aとを含むものとして示されている。集合的に、地域ディスパッチャ170AおよびMCC170Bは、少なくとも1つの実施形態では、ワイヤレス通信システム100内の通信セッション(たとえば、IPユニキャストプロトコルおよび/またはIPマルチキャストプロトコルを介した半二重グループ通信セッション)を調停するように集合的に機能するサーバの分散型ネットワークに相当し得る、アプリケーションサーバ170内に含まれる。たとえば、アプリケーションサーバ170によって調停される通信セッションは、理論的には、システム100内のどこかに位置するAT間で行われ得るので、調停される通信セッションのレイテンシを低減するために(たとえば、北米のMCCが、中国にいるセッション参加者間でメディアをあちこちに中継していないように)複数の地域ディスパッチャ170AおよびMCCが分散される。したがって、アプリケーションサーバ170に言及する場合、地域ディスパッチャ170Aのうちの1つまたは複数、および/または、MCC170Bのうちの1つまたは複数によって、関連する機能が実施され得ることが理解されよう。地域ディスパッチャ170Aは、概して、(たとえば、AT間のシグナリングメッセージを処理すること、告知メッセージをスケジュールおよび/または送信することなど)通信セッションを確立することに関係する機能を担当し、MCC170Bは、調停された通信セッション中に呼中シグナリングおよびメディアの実際の交換を行うことを含む、呼インスタンスの持続時間の間に通信セッションをホスティングすることを担当する。したがって、本発明の別の実施形態では、調停される通信セッションがPTT呼に相当することを仮定して、MCC170Bは、PTTアプリケーションサーバおよび/またはPTTメディア頒布サーバと呼ばれ得る。

図3を参照すると、携帯電話などのアクセス端末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などの外部デバイスに動作可能に結合されてもよい。

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

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

所与のアクセス端末(AT)が、特定のターゲットに送るべき大量のデータを有する場合、ファイル転送セッションに関連する時間が、ファイル転送セッションのセットアップ時間と比較して相対的に長くなるので、ファイル転送セッションのセットアップ時間は、比較的重要度が低い。しかし、相対的に少量のデータが交換されるファイル転送セッションのセットアップ時間は、セッション自体の長さと比較して、不釣り合いに長くなり得る。

図4Aは、ファイルが通信システムにおいてAT間で交換され得る際の、従来の方式を示す。具体的には、図4Aは、送信ATがすでに通信セッションに関与している時に、送信ATがターゲットATにファイルをどのように送信するかという従来の例を示す。

図4Aを参照すると、所与のAT(「AT1」)は、ファイル転送セッションを開始すべきかどうかを決定する(400A)。AT1が、ファイル転送セッションを開始しないと決定すると、AT1は、400Aにおいて、通信セッションおよび残りの処理のためのリソースをセットアップしない。

それ以外の場合、AT1が、ファイル転送セッションを開始すると決定すると、AT1は、ファイル転送セッションのために、RAN120によりTCHをセットアップする(405A)。次いで、ファイル転送セッションのためのTCHを取得すると、AT1は、アプリケーションサーバ170とのファイル転送セッションの間にデータを交換するためのデータポートを取得するために、3ウェイTCPハンドシェイクに関与することによって、ファイル転送セッションのためのトランスポート接続をセットアップする(410A)。TCPは、当技術分野においてよく知られており、標準的なネットワーク層プロトコルを用いる。一般に、AT1のようなクライアントが、アプリケーションサーバ170のようなサーバとの接続を試みる前に、サーバはまず、接続に向けてクライアントを開放するためにポートに結合しなければならず、これは「パッシブオープン」と呼ばれる。パッシブオープンが確立されると、クライアントは「アクティブオープン」を開始することができる。トランスポートまたはTCP接続を実際に確立するために、3ウェイ(または3ステップ)ハンドシェイクが行われ、これにより、SYNをサーバに送るクライアントによってアクティブオープンが実行されて、サーバはSYN-ACKによって応答し、クライアントはサーバにACKを送り返す。この時点で、この場合はAT1であるクライアントは、アプリケーションサーバ170とのトランスポート接続をアクティブ化しており、アプリケーションサーバ170へのメッセージのタグ付けに用いるデータポートを有する。図4Aには明示的に示されないが、上述のTCPハンドシェイクは、通信セッションのターゲット側においても行われる。ターゲット側で行われるセットアップは、図4Bに関して以下で説明される。

トランスポート接続をセットアップした後、AT1は、AT1においてファイル転送セッションを処理するアプリケーションをセットアップすることができ、AT2への送信のために、アプリケーションサーバ170へのアプリケーション層データ(すなわち、転送されるべきファイル)の送信を開始することができる(415A)。AT1は、ファイル転送セッションの間に転送されるべきファイルが、AT2への送信のためにアプリケーションサーバ170に無事に送られたかどうかを、定期的に判定することができる(420A)。1つもしくは複数のファイルまたはファイルの一部の送信がまだ完了していないと、420AにおいてAT1が判定すると、処理は415Aに戻り、AT1は、405Aおよび410Aで取得されたリソースを用いて、AT2への送信のためにファイルまたはファイルの一部をアプリケーションサーバ170に送り続ける。それ以外の場合、415Aのファイル転送セッションのためのすべてのファイルの転送の送信が完了した後、処理は425Aに進む。

425Aにおいて、AT1は、415Aのデータ送信のために取得されたセッションリソースを解放するので、405AからのTCHは切断され、410Aのトランスポート接続は終了する。何らかの後の時点において、AT1は、任意の追加のファイルをAT2へ送るべきかどうかを決定する(430A)。送るべきである場合、AT1が再びセッションリソース(たとえば、TCH、トランスポート接続など)を取得し、AT2への別のファイル転送セッションの間に1つまたは複数のファイルを送れるように、処理は405Aに戻る。

図4Bは、ファイルが通信システムにおいてAT間で交換され得る際の、従来の方式を示す。具体的には、図4Bは、ターゲットATがどのように送信ATからファイルを受信するかという、従来の例を示す。ある例では、図4Bは、図4Aの処理の間に、ターゲットATまたはAT2において行われ得る処理を示す。

図4Bを参照すると、AT2へ転送されるべきデータをAT1が送信していることを、アプリケーションサーバ170が通知された後、アプリケーションサーバ170は、Openメッセージ(たとえばページメッセージ)をRAN120に送り(401B)、Openメッセージは次いで、RAN120によってAT2に送信される(402B)。AT2は、Openメッセージを受信し、トラフィックチャネル(TCH)のセットアップを開始する(405B)。次に、410Bにおいて、AT2は、410AにおいてAT1で行われる処理と同様に、TCPハンドシェイクを介してトランスポート接続をセットアップする。

この処理の何らかの時点において、415Aで、AT1は、通信セッションのために確立されたデータポートを介して、アプリケーションサーバ170へのデータの送信を開始する。AT2とのTCPハンドシェイクがまだ完了していないので、かつ/または、アプリケーションサーバ170が順序通りにデータパケットを送ることを要求され、パケットが順序がばらばらになって到達し得るので、アプリケーションサーバ170は416BにおいてAT1からのデータのバッファリングを開始する。AT2が、SYN-ACKメッセージにより確認応答することによって、TCHハンドシェイクを完了すると、アプリケーションサーバ170は、バッファリングされたデータのAT2への転送を開始することができる(420B)。しかし、416Bのバッファリングは、ACKが受信される時に必ずしも終わらず、ある期間継続し得ることが理解されよう。

理解されるように、415Aにおいてアプリケーションサーバ170に到達するデータパケットは、ワイヤレスリンクにおける損失のために、順序または順番がばらばらになることがある。したがって、アプリケーションサーバ170は、416Bにおいてすべてのパケットをバッファリングする。データポートがAT2により確立された後、アプリケーションサーバ170は、バッファリングされたデータパケットのAT2への送達を開始することができる(420B)。従来は、n-1個のパケットが利用可能である場合であっても、パケットp+1が依然として欠けているので、1からpまでの連続パケットしかAT2に送達できなかった。これは、当技術分野において「行頭ブロッキング」として知られ、従来のTCPにおける問題点である。以下でより詳細に説明されるように、本発明の少なくとも1つの実施形態では、行頭ブロッキングを減少させ、かつ/または除去することができる。したがって、一つには、TCP中のファイルが順序通りまたは順番通りに送達されることを強いられるので、図4Aおよび/または図4Bに関連する遅延が発生する。

理解されるように、400AにおいてAT1がファイル転送セッションを開始すると決定する時間と、415AにおいてAT1がファイル転送セッションのためのデータパケットの送信を開始できるようになる時間との間には、比較的長い時間が発生し得る。たとえば、TCHをセットアップするには約300msかかることがあり、トランスポート接続をセットアップするためにさらなる時間がかかることがある。したがって、本発明の実施形態は、ATが事前に確立された通信セッション(たとえばVoIPセッションなど)に同時に関与している時に、ファイル転送セッションのためのデータの送信を、ATがより迅速に開始できるようにすることを対象とする。

図4Cおよび図4Dは、本発明のある実施形態による、発信側AT1とターゲットAT2との間のファイル転送セッションのセットアップと関連付けられるシグナリングを示す。具体的には、図4Cは、ファイル転送セッションのセットアップの間にAT1とアプリケーションサーバ170との間で行われるシグナリングに注目し、図4Dは、ファイル転送セッションのセットアップの間にアプリケーションサーバ170とAT2との間で行われるシグナリングに注目する。

図4Cを参照すると、所与のAT(「AT1」)が、ファイル転送セッションを開始すべきかどうかを決定する(400C)。ファイル転送セッションを開始しないと、AT1が決定すると、処理は400Cにとどまる。それ以外の場合、ファイル転送セッションを開始するとAT1が決定すると、AT1は、AT1によりすでに確立されている通信セッションが、ファイル転送セッションのためのファイルの送信に現在利用可能であるセッションリソースへのアクセスを有するかどうかを判定する(405C)。たとえば、AT1が405Cにおいて別のファイル転送セッションにすでに関与している場合、AT1は単に、新たに開始されるファイル転送セッションのために、他のファイル転送セッションのTCHおよびトランスポート接続を用いることができる。それ以外の場合、既存のセッションリソースがファイル転送セッションのために利用可能ではなければ、処理は410Cに進む。

図4Cを参照すると、AT1は、ファイル転送セッションのために、RAN120とのTCHのセットアップを開始する(410C)。図4Aとは異なり、415Cにおいて、TCHのセットアップが完了するのを待機する代わりに、AT1は、トランスポートデータおよびアプリケーションデータを含めるようにdata-over-signaling(DoS)メッセージを構成することによって、トランスポート接続およびアプリケーション層接続のセットアップを先に開始して、逆方向リンクアクセスチャネルでDoSメッセージをRAN120に送り、RAN120は、DoSメッセージをアプリケーションサーバ170に転送する。ある例では、415Cにおいて送信されるDoSメッセージは、AT1のシグナリングメッセージのためにすでにセットアップされている、シグナリングポートまたはDoSポートを用いることができる。たとえば、一部のATは、ATのエンドユーザに対して準備される前に、サービスプロバイダ(たとえばSprint、Verizonなど)によって、DoSポートにより事前構成され得る。その後、カバレッジがRAN120により提供され得る限り、ATは、関連するDoSポートの使用を許可される。

したがって、AT1は、事前に確立されたシグナリングポートを利用して、415Cにおけるファイル転送セッションのための、トランスポート接続およびアプリケーション層接続をセットアップする。アプリケーションサーバ170は、415CにおけるDoSメッセージに含まれる具体的な情報(たとえば、シグナリングポートのようなデータの送信に用いられているポート以外のポートで送達されているメッセージ)を認識し、ファイル転送セッションの間にAT2へデータを送るために、AT1がトランスポート接続のセットアップを試みていると判定する。したがって、アプリケーションサーバ170は、415CからのDoSメッセージに含まれるトランスポート層パラメータを用いて、ファイル転送セッションの間に用いるAT1のためのデータポートを選択する(417C)。

アプリケーションサーバ170は、401DにおいてStartメッセージをAT2に送り、ファイル転送セッションの準備をするようにAT2に指示する。401Dは、図4Dに関して以下でより詳細に論じられ、図4Dは、アプリケーションサーバ170とターゲットAT2との間のシグナリングをより詳細に扱う。

何らかの後の時点において、AT1がTCHのセットアップを完了したと仮定する(420C)。AT1はまた、417CにおいてAT1のためにセットアップされたデータポートで、415CのDoSメッセージへの応答を、アプリケーションサーバ170から受信する(425C)。この時点において、AT1は、そのデータポートでAT2に転送されるべきデータの、アプリケーションサーバ170への送信を開始する(430C)。理解されるように、RAN120へTCHを通じてデータポート上で送られ、アプリケーションサーバ170に転送されることになる、最初のデータメッセージ431Cは、425Cからの応答メッセージへのACKとして機能するので、AT1は、応答メッセージに対する明示的なACKを送る必要はない。アプリケーションサーバ170は、445DにおいてデータをAT1からAT2に転送し(たとえば、AT2がデータの受信の準備ができるまでの期間、データをバッファリングした後で)、これは図4Dに関して以下でより詳細に論じられる。

上で論じられたように、415CのDoSメッセージは、SYNメッセージとして機能し得る。その後、425Cの応答メッセージは、SYN-ACKメッセージとして機能することができ、AT1は、430Cおよび431Cにおいてデータポートでデータを送ることによって、データポートのセットアップを完了することができ、このことが、応答メッセージへのACKとして機能する。したがって、415C、425Cおよび431Cはまとめて、図4Aの415Aに示されるTCPハンドシェイクを実行する異なる方式に対応し、これらにより、TCHが取得される前にトランスポート接続がセットアップを開始できる。

ある例では、TCP SYNメッセージ(たとえば、図4Aの410Aに示される)は、415CのDoSメッセージ内に組み込まれてもよい。TCP SYNメッセージの主要な内容には、発信元ポート、宛先ポートおよび最初のシーケンス番号がある。アプリケーションサーバ170は、SYN_ACKメッセージ(たとえば、425Cの応答メッセージに組み込まれてよく、以下でより詳細に論じられる)により応答することができ、または、呼要求メッセージへのACK(たとえば、ユーザデータグラムプロトコル(UDP)を通じたCall-ACKメッセージ)のような、AT1に送られる別のメッセージの中の、SYN ACKメッセージの主要な内容(たとえば、発信元ポート、宛先ポートおよび最初のシーケンス番号)を符号化することができる。いずれの場合でも、AT1のファイル転送セッションのためのTCPトランスポート接続は、通常はアプリケーション層通信セッション(たとえば、2人以上の参加者の間のマルチメディアセッション)のために用いられる、シグナリングセッションパラメータを利用する。415Cにおいてトランスポート接続のセットアップを開始することによって、SYNメッセージを、アプリケーションサーバ170へより迅速に通信することができ、その結果、TCP接続のセットアップが、参加者間の端末と端末の間の呼のために迅速に行われ得る。言い換えると、TCP接続(図4Aの410Aにおけるような)をセットアップするための3ウェイハンドシェイクを実行することに関連する遅延が、図4Cの実施形態では低減される。

425Cの応答メッセージは、シグナリングポートの代わりにデータポートで送られ、425Cにおいて応答メッセージ(たとえば、SYN-ACKメッセージと同様の情報を含む)が送られた後、AT1は、ファイル転送セッションの間のデータの送信のために、そのデータポートの使用を開始することができる。したがって、TCHを用意しファイル転送セッションのためのトランスポート接続を取得するための処理を同時に開始することによって、AT1は、ファイル転送セッションのためのアプリケーション層のデータの送信をより迅速に開始することができる。図4Cを参照して上で述べられたように、430Cおよび431Cで送られるデータパケットは、ワイヤレスリンクにおける損失のために、順序がばらばらになってアプリケーションサーバ170に到達することがある。この場合、アプリケーションサーバ170は、すべてのパケットをバッファリングする。従来は、n-1個のパケットが利用可能である場合であっても、パケットp+1が依然として欠けているので、1からpまでの連続パケットしかAT2に送達できない。これは、当技術分野において「行頭ブロッキング」として知られ、従来のTCPにおける問題点である。以下でより詳細に説明されるように、本発明の少なくとも1つの実施形態では、行頭ブロッキングを減少させ、かつ/または、(たとえば、データポートがUDPに相当し、ブロッキングが完全に除去される場合)除去することができる。たとえば、以下でより詳細に論じられるように、所与のファイルが転送を完了するまでバッファリングが行われる従来の図4Aおよび図4Bと比較して、バッファリングは、図4Dの440Dにおいて応答メッセージがターゲットAT2から受信されるまでしか、続かなくてよい。

AT1は、ファイル転送セッションの間に転送されるべきファイルが、AT2への送信のためにアプリケーションサーバ170に無事に送られたかどうかを、定期的に判定することができる(440C)。1つもしくは複数のファイルまたはファイルの一部の送信がまだ完了していないと、440CにおいてAT1が判定すると、処理は430Cに戻り、AT1は、AT2への送信のためにファイルまたはファイルの一部をアプリケーションサーバ170に送り続ける。それ以外の場合、430Cのファイル転送セッションのためのすべてのファイルの転送の送信が完了した後、処理は445Cに進む。445Cにおいて、AT1は、任意の追加のファイルをAT2へ送るべきかどうかを決定する。送るべきである場合、処理は430Cに戻り、AT1は、AT2への別のファイル転送セッションの間に1つまたは複数のファイルを送るための前のファイル転送セッションのために410Cから435Cの間に確立されたセッションリソースを、再使用する。それ以外の場合、445Cにおいて、AT2に送信する必要のあるデータはこれ以上ないと、AT1が判定すると、AT1は、430Cおよび431Cのデータ送信のために取得されたセッションリソースを解放するので、410Cおよび420CからのTCHは切断され、トランスポート接続(すなわちデータポート)は終了する。

図4Cの検討から理解されるように、シグナリングポートは、SYNメッセージ(または等価な情報)を送るために用いられ、その後、データはデータポートを介してアプリケーションサーバ170に送られる。したがって、トランスポート接続は、実際のセッションのためにセットアップされているポート以外のポートでセットアップされる。

図4Dは、本発明のある実施形態による、図4Cの処理の間に、アプリケーションサーバ170とターゲットAT2との間で行われる動作を示す。具体的には、図4Dは、図4Cの401Dと445Dとの間での、アプリケーションサーバ170とターゲットAT2との間のシグナリングを示す。

図4Dを参照して、図4Cの415CにおいてAT1からStartメッセージを受信すると、アプリケーションサーバ170は、ファイル転送セッションの各々の意図されるターゲットを特定して位置決定し、Startメッセージを各々の特定され位置決定されたターゲットに送る(401D)。図4Dでは、説明の便宜上、単一のターゲットAT2が示される。401DのStartメッセージは、時間遅延およびメッセージウィンドウのサイズのようなトランスポートデータを、アプリケーションサーバ170がAT2からデータを受信する際に用いる予定のポートの指定のような、何らかのアプリケーションデータとともに、含む。理解されるように、ファイル転送セッションのターゲットに割り当てられるデータポートは、AT2に割り当てられるデータポートと同じである必要はない。401DのStartメッセージは、DoSポートのようなシグナリングポートを通じて送られる。したがって、Startメッセージは、AT1からの415Cにおけるような移動機から発信された(MO)DoSメッセージとは対照的な、移動機で終端する(MT)DoSメッセージに相当し得る。

Startメッセージを受信すると、AT2は、AT2はすでにTCHを有するかといった、AT2が既存の通信セッションにすでに関与しているかどうかを判定する(410D)。AT2がまだTCHを有していないと、410DにおいてAT2が判定すると、415DにおいてAT2はTCHを用意する。

AT1に戻ると、AT1がデータポートを取得した後(たとえば、AT1が図4Cの425Cにおいて応答メッセージを受信した後)、AT1は、データポートでアプリケーションサーバ170へのデータの送信を開始する(430D)。図4Dでは、431Cは、AT1からデータポートを通じて送られる最初のデータパケットに相当し、図4Dの431Cはまた、図4Cに関して上で論じられた同様の番号の信号に相当する。

図4Dの実施形態では、AT2に宛てられたAT1からのデータは、AT2がデータの受信の準備ができる前に、AT1のデータポート上で、アプリケーションサーバ170に到達し始めると仮定される。したがって、アプリケーションサーバ170は、425DにおいてAT1からのデータのバッファリングを開始し、少なくとも、アプリケーションサーバ170からのデータのダウンロードの準備ができていることをAT2が示すまで、アプリケーションサーバ170は、425Dにおいてデータのバッファリングを続ける。

415DにおいてTCHをセットアップした後、または、410DにおいてAT2がすでにTCHを有していたことを確認した後、AT2は、応答メッセージをアプリケーションサーバ170に送る(440D)。440Cの応答メッセージは、AT2がファイル転送セッションのために用いているポートのような、情報を含む。AT2から応答メッセージを受信すると、アプリケーションサーバ170は、ファイル転送セッションのためにAT2により用いられるデータポートを知り、それにより、425CのバッファリングされたデータのAT2への送信を開始する(445D)。

図4Dには示されないが、AT1からのデータが431Cにおいてアプリケーションサーバ170に到達する前に、440Dの応答メッセージがアプリケーションサーバ170に到達できるということが、あり得る。たとえば、AT1がTCHなしで図4Cの処理を開始し、AT2がTCHにより図4Dの処理を開始すると、AT2は、AT1が固有のTCHをセットアップしてデータの送信を開始できるようになるよりも早く、Startメッセージに対して応答できるようになり得る。この場合、アプリケーションサーバ170は、425Dのバッファリングを実行する必要はなく、むしろ、AT1からのデータがアプリケーションサーバ170に到達し始めるとすぐに、AT1からAT2へのデータの転送を開始することができる。

図4C〜図4Dは、ファイル転送セッションがどのようにセットアップされ得るかに関連するが、ワイヤレス通信システムにおけるファイル転送セッションの別の側面は、発信側アクセス端末またはターゲットアクセス端末の異なる機能層の間の対話である。図5Aから図5Dでは、AT1の機能層「1」、「2」、および「3」に言及がなされる。これらの異なる機能層は、異なる層において特定の機能を実行する役割を果たす、ソフトウェアおよび/またはハードウェアの組合せに対応する。しかし、以下で説明される実施形態は、説明の便宜上、3つの機能層に注目するが、実施形態は3つの機能層に限定されず、代わりに任意の数の機能層を含んでもよいことが、理解されよう。

ある例では、機能層1はMAC層と呼ばれることがあり、機能層2はトランスポート層と呼ばれることがあり、機能層3はアプリケーション層と呼ばれることがある。機能層1は、逆方向リンク物理層チャネルでのRAN120への送信のために待ち行列に入れられたデータパケットを保持する、送信ウィンドウまたは送信待ち行列を有するものとして、特徴付けられる。機能層2は、一部のパケットを機能層1の送信ウィンドウに追加することを要求することができ、これらのパケットは実際には、機能層3によって、高レベルまたは高次層において生成され得る。

ある例では、機能層3は、セッション開始プロトコル(SIP)クライアントまたは任意の他のマルチメディアアプリケーション層のインターフェースプロセスのような、アプリケーション層インターフェースに相当し得る。たとえば、SIPクライアントは、メディアアプリケーション(たとえば、VoIPアプリケーション、PTTアプリケーションなど)のアプリケーション層の機能、トランスポート層プロトコル、および低次層コントローラ(たとえば、W-CDMAシステムにおける無線リンク制御(RLC)層のコントローラ、EV-DOシステムにおける無線リンクプロトコル(RLP)層のコントローラなど)を管理する役割を果たし得る。

一般に、機能層3が、別のセッション参加者(たとえばAT2)に送るべきデータを有する場合、機能層3は、データを送るように機能層2に要求し、そして機能層2は、物理チャネルでデータを送るように機能層1に要求する。しかし、機能層3は、データが実際にいつ送信されるかに関して直接の制御権を有さないので、機能層3は、データがいつ機能層1によって物理チャネルで送られるかを決定できない。したがって、機能層3は通常、機能層3がいつデータパケット通信命令を機能層2に対して発行するかを追跡するが、機能層1がいつ実際のデータパケットを物理層で(すなわち、ワイヤレスインターフェース104を通じて)送信するかは追跡しない。

図5Aを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッション(たとえば、ストリーミングメディアセッション、ファイル転送セッションなど)への参加をセットアップして開始すると、仮定する(500A)。次に、機能層3は、通信セッションのための新たなデータパケットをアプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送るための要求を、機能層2に対して発行する(505A)。新たなデータパケットを送信するように機能層2に要求した後、機能層3は、所与の満了期間を有する満了タイマーを始動させる。満了タイマーが動いている間は、機能層3は送信されるデータパケットのACKの受信を待機し、それにより、機能層3は、満了タイマーが満了する前にACKが受信されなかった場合に、データパケットの送信が成功しなかったと推測する(510A)。

機能層2は、新たなデータパケットの送信の要求を受信して、機能層2により保持される送信待ち行列または送信ウィンドウに、データパケットを追加し(515A)、その後、機能層2は、機能層2の送信ウィンドウの中で現在予定されているデータパケットのすべての送信を試みるように、機能層1に指示する(520A)。理解されるように、本発明のすべての実施形態が、固有の送信ウィンドウまたは送信待ち行列を有するように機能層2に要求するわけではない。機能層2がそのような送信ウィンドウを有さない場合、機能層2は単に、新たなデータパケットが送信のために機能層3によって要求される度に、505Aにおいて送信のために要求されたデータパケットを、機能層1の送信ウィンドウに追加することができる。したがって、機能層2は固有の送信待ち行列を必ずしも有さないが、図5Aから図5Dの実施形態は、機能層2が固有の送信待ち行列へのアクセスを有するという仮定の下で、説明される。本発明の他の実施形態において、機能層2に送信待ち行列がないことに対応するように、図5Aから図5Dをどのように修正できるかは、当業者には容易に理解されよう。

機能層1は、機能層2から送信の順序を受信し、次いで、機能層2の送信ウィンドウからのデータパケットを、固有の送信ウィンドウに追加する(525A)。530Aにおいて、機能層1は、機能層1の送信ウィンドウに含まれるデータパケットの送信を、1回または複数回試みる。530Aにおいて、機能層1の送信ウィンドウのデータパケットの1つの送信の試みが成功しなかった場合、データパケットの送信が成功するまで、機能層1は、送信が成功しなかったデータパケットを、所定の回数、機能層1の送信ウィンドウに再び加える。したがって、535Aは、データパケットが機能層1の送信ウィンドウに再び加えられ、その結果送信が成功するのを示す。当業者により理解されるように、機能層3は、データパケットを送信するこれらの個々の試みが成功したか成功しなかったかに関して、通知されない。535Aにおいてデータパケットの送信に成功した後、アプリケーションサーバ170は、機能層3ACKメッセージをAT1に送り返すことによって、データパケットの受信に成功したと確認応答する(540A)。

上で説明されたデータパケット送信処理が、機能層1において進行中である間、機能層3は、機能層1で行われている動作を実際には認識せず、機能層3は単に、505Aにおいて送信のために要求されたデータパケットに対するACKが、機能層3において受信されたかどうかを監視する。したがって、545Aにおいて、機能層3は、505Aからの要求されたデータパケットに対するACKが、満了タイマーが満了する前に受信されたかどうかを判定する。545Aにおいて、データパケットに対する確認応答が成功したと、機能層3が判定した場合、処理は560Aに進む。それ以外の場合、545Aにおいて、データパケットに対する確認応答が成功しなかったと、機能層3が判定した場合、機能層3は、データパケットの送信が失敗したと推測し、データパケットを再び送信するために、トランスポート層プロトコルに対して別の要求を発行する(550A)。図5Aの実施形態では、540AにおけるACKは、満了タイマーの満了の後で受信されるので、545Aにおいて、機能層3はすでに、データパケットに対する確認応答が成功していないと判定している。

したがって、機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する(555A)。この時点において、処理は520Aに戻り、機能層1によるデータパケットの送信の新たな要求を繰り返す。理解されるように、機能層1がデータパケットの送信の試みを続けた場合でも、機能層3は、満了タイマーが満了したことを認識するだけであり、このことはデータパケットの送信の新たな要求を引き起こす。そしてこれによって、アプリケーションサーバ170にデータパケットを2回(すなわち、505Aにおいて機能層3により発行された各々のパケット送信要求に対して1回)送るように、機能層1が要求される。

図5Aの実施形態では、機能層3が送信のために要求したデータパケットの1つに対する、アプリケーションサーバ170による確認応答が成功したと、機能層3が545Aにおいて判定すると、機能層3は次いで、さらなるデータがアプリケーションサーバ170への送信のために要求されるべきかどうかを判定する(560A)。機能層3が560Aにおいて、さらなるデータをアプリケーションサーバ170に送信すると決定すると、処理は505Aに戻り、1つまたは複数のさらなるデータパケットの送信のために繰り返す。それ以外の場合、図5Aの処理は終了するが、500Aの通信セッションは、AT1が、ある期間データパケットを送ることなくデータパケットを受信することで、継続しうる。

機能層1における送信を待機しているパケットの状態に関連する情報を、機能層3および機能層1が交換できる機構を対象とする、本発明のある実施形態が、ここで図5Bを参照して説明される。

図5Bを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッションへの参加をセットアップして開始すると、仮定する(500B)。次に、機能層3は、通信セッションのための新たなデータパケットを、アプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送信するために、機能層2に送ることを要求する(505B)。しかし、図5Aとは異なり、505Bにおいて新たなデータパケットを送るように機能層2に要求した後、データパケットに対するACKを機能層3が待機する期間を定める満了タイマーを、機能層3はまだ始動させない。

次に、図5Bの510Bから530Bは全般に、それぞれ図5Aの515Aから535Aに対応するので、簡潔にするためにさらに詳細には説明されない。機能層1が、530Bにおいて、物理層でのRAN120へのデータパケットの送信に成功した後、RAN120は、AT1の機能層1に層1ACKを送り(534B)、その後、機能層1は、505Bにおいて送信のために要求されたデータパケットがAT1から送信されたことを示す通知メッセージを、機能層3に送る(535B)。たとえば、機能層1から機能層3への通知メッセージは、コールバックAPIとして実装され得る。図5Bには明示的に示されないが、535Bの通知は、機能層3によって送信のために要求された各々のデータパケットについて、それぞれのデータパケットが機能層1においてAT1から送信された時に、実行され得る。

従来、機能層3は、機能層3自体がデータパケットの送信を要求した時に満了タイマーを始動させ、これには、データパケットがAT1から送信できるようになるまでの、機能層2および/または機能層1における遅延が考慮されていない。図5Bの実施形態では、535Bで、機能層3においてデータパケットの送信の通知を受信すると、機能層3は、データパケット送信要求が505Bで発行された時ではなく、540Bにおいて満了タイマーを始動させる。当業者により理解されるように、このように後の時点で満了期間を開始することで、データパケットの送信の前に発生する、AT1の機能層2および/または機能層1における遅延によって、機能層3が同一のデータパケットを送信するための要求を再発行する確率が下がる。また、端の状況を除き、スループットを低下させる必要はない。さらに、540Bで始動する満了タイマーは、510Aにおける満了タイマーよりも短い期間動作するように示されるが、510Aおよび540Bの実際の満了期間は同一であってもよいことが、理解されよう。しかし、540Bにおける満了タイマーは後の時点で始動するので、ACKがタイマーの始動に続いてより迅速に受信され、540Bの満了タイマーはより短い期間しか動作しなくてもよい。

機能層1に戻り、530Bにおいてデータパケットの送信に成功した後、アプリケーションサーバ170は、機能層3のACKメッセージまたはSIP層のACKメッセージをAT1に送り返すことによって、データパケットの受信に成功したと確認応答する(545B)。

550Bにおいて、機能層3は、530BにおいてAT1から送信された、505Bからの要求されたデータパケットに対して、満了タイマーが満了する前に、ACKが受信されたかどうかを判定する。やはり、図5Bの満了タイマーは、実際のデータパケット送信要求が505Bにおいて機能層3から発行された、より早い時点ではなく、535Bの通知の後で開始し、このことは一般に、再送信が機能層3によって要求される前に、最初のデータパケットの送信に確認応答するためのより長いタイマーを、図5Bの満了タイマーがアプリケーションサーバ170に対して許可するということを意味する。550Bにおいて、データパケットに対する確認応答が成功したと、機能層3が判定した場合、処理は565Bに進む。それ以外の場合、550Bにおいて、データパケットに対する確認応答が成功しなかったと、機能層3が判定した場合、機能層3は、データパケットの送信が失敗したと推測し、データパケットを再び送信するために、機能層2に対して別の要求を発行する(555B)。機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する(560B)。この時点において、処理は515Bに戻り、データパケットの送信の新たな要求を繰り返す。図5Bの例では、505Bの送信要求ではなく535Bの通知に応答して、機能層3が満了タイマーを始動させたことに少なくとも一部基づいて、満了期間内で受信されているアプリケーションサーバ170からのACKを、550Bの判定ブロックが評価することが理解されよう。

したがって、図5Bは、ワイヤレス層または物理層を通じたRAN120へのデータパケット送信がいつ成功したかを、機能層1が機能層3に対して通知できる機構を実装することによって、機能層3からの不要な繰り返されるデータパケット送信要求の数をどのように減らせるかを示す、1つの例示的な実施形態である。したがって、図5A〜図5Bは、所与のデータパケットの物理層での送信の成功を、機能層3に早く通知することに関連する利点を示し、図5C〜図5Dは、所与のデータパケットの物理層での送信の失敗を、機能層3に早く通知することに関連する利点を示す。

図5Cを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッション(たとえば、ストリーミングメディアセッション、ファイル転送セッションなど)への参加を、セットアップして開始すると仮定する(500C)。次に、機能層3は、新たなデータパケットをアプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送信するための要求を、機能層2に対して発行する(505C)。図5Aの510Aにおけるように、新たなデータパケットを送るように機能層2に要求した後、機能層3は、所与の満了期間を有する満了タイマーを始動させる。満了タイマーが動いている間は、機能層3は送信されるデータパケットのACKの受信を待機し、それにより、機能層3は、満了タイマーが満了する前にACKが受信されなかった場合に、データパケットの送信が成功しなかったと推測する(510C)。

機能層2は、新たなデータパケットの送信の要求を受信して、機能層2の送信ウィンドウにデータパケットを追加し(515C)、その後、機能層2は、機能層2の送信ウィンドウの中で現在スケジューリングされているデータパケットのすべての送信を試みるように、機能層1に指示する(520C)。機能層1は、機能層2から送信の順序を受信し、次いで、機能層2の送信ウィンドウからのデータパケットを、固有の送信ウィンドウに追加する(525C)。530Cにおいて、機能層1は、機能層1の送信ウィンドウに含まれるデータパケットの送信を、1回または複数回試みる。530Cにおいて、機能層1の送信ウィンドウのデータパケットの1つの送信の試みが成功しなかった場合、データパケットの送信に成功するまで、または繰り返される送信の試みの数が閾値を超えるまで、機能層1は、送信が成功しなかったデータパケットを、所定の回数、機能層1の送信ウィンドウに再び加える。したがって、530Cは、アプリケーションサーバへのデータパケットの送信の、不成功の試みを示し、データパケットのRAN120への送信は不成功である。

RAN120がアプリケーションサーバ170へのデータパケットの送信を完了できないので、RAN120は、層1の否定ACK(NACK)をAT1の機能層1に送る(540C)。あるいは、明示的なNACKがRAN120によって送られる必要はなく、その場合、機能層1は単に、ACKがRAN120から受信されることなく閾値の期間が経過した後(すなわち、ACKタイムアウト)、物理層でのデータパケットの送信の失敗を推測する。しかし、機能層1は、NACKフレームを受信し、またはACKが受信されない場合にパケット損失を推測するが、機能層1は、データパケットの送信の試みがすでに失敗したことを、機能層3に通知しない。

図5Cの実施形態では、上で説明されたデータパケット送信処理が、機能層1において進行中である間、機能層3は、機能層1で行われている動作を実際には認識せず、機能層3は単に、505Cにおいて送信のために要求されたデータパケットに対するACKが、機能層3において受信されたかどうかを監視する。したがって、545Cにおいて、機能層3は、505Cからの要求されたデータパケットに対するACKが、満了タイマーが満了する前に受信されたかどうかを判定する。545Cにおいて、データパケットに対する確認応答が成功したと、機能層3が判定した場合、処理は560Cに進む。それ以外の場合、545Cにおいて、データパケットに対する確認応答が成功しなかったと、機能層3が判定した場合、機能層3は、データパケットの送信が失敗したと推測し、データパケットを再び送信するために、機能層2に対して別の要求を発行する(550C)。機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する(555C)。この時点において、処理は520Cに戻り、データパケットの送信の新たな要求を繰り返す。

理解されるように、540Cにおいて、機能層1がパケット障害またはパケット損失を判定した(たとえば、明示的なNACKと、RAN120からのACKの受信の失敗とのいずれかから)場合であっても、545Cにおいて、機能層3は、満了タイマーの満了のみによって送信の失敗を推測する。したがって、図5Aにおける満了タイマーの利用は、ACKが遅く到達した場合に、データパケットの不必要な繰り返しの送信を引き起こし、図5Cにおける満了タイマーの利用は、送信の試みが実際に失敗した場合に、データパケットの繰り返しの送信を命令するまでの、不必要な遅延を引き起こした。

図5Cに戻り、機能層3が送信のために要求したデータパケットの1つに対する、アプリケーションサーバ170による確認応答が成功したと、機能層3が545Cにおいて判定すると、機能層3は、さらなるデータがアプリケーションサーバ170への送信のために要求されるべきかどうかを判定する(560C)。機能層3が560Cにおいて、さらなるデータをアプリケーションサーバ170に送信すると決定すると、処理は505Cに戻り、1つまたは複数のさらなるデータパケットの送信のために繰り返す。それ以外の場合、図5Cの処理は終了するが、500Cの通信セッションは、AT1が、ある期間データパケットを送ることなくデータパケットを受信することで、継続しうる。

機能層1における送信を待機しているパケットの状態に関連する情報を、機能層1および機能層3が交換できる機構を対象とする、本発明のある実施形態が、ここで図5Dを参照して説明される。

図5Dを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッションへの参加をセットアップして開始すると、仮定する(500D)。次に、機能層3は、通信セッションのための新たなデータパケットを、アプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送信するために、機能層2に送ることを要求する(505D)。しかし、図5Cとは異なり、505Dにおいて新たなデータパケットを送るように機能層2に要求した後、データパケットに対するACKを機能層3が待機する期間を定める満了タイマーを、機能層3はまだ始動させない。

次に、図5Dの510Dから530Dは全般に、それぞれ図5Cの515Cから535Cに対応するので、簡潔にするためにさらに詳細には説明されない。図5Bの535Bと同様に、機能層1が、530Bにおいて、任意のデータパケットのRAN120への送信に成功できた場合、機能層1は、505Dにおいて送信のために要求されたデータパケットがAT1から送信されたことを示す通知メッセージを、機能層3に送る(535D)。しかし、535Dの直後に、RAN120が、データパケットに対する層1のNACKをAT1の機能層1に送り、または代替的には、RAN120がデータパケットに対して確認応答できなかった時に、機能層1がパケット障害またはパケット損失を推測すると、仮定する(540D)。図5Cでは、540Cでパケット送信の失敗を示したことで、データパケットの次の送信の試みが中止された。しかし、図5Dでは、540Dでパケット送信の失敗を示したことで、535Dにおいて機能層3により示されたデータパケットの送信の試みが失敗したことが、545Dにおいて機能層3に通知もされる。図5Bの535Bおよび/または図5Dの535Dの通知と同様に、545Dにおける機能層1から機能層3への通知メッセージは、コールバックAPIとして実装され得る。

図5Dには示されないが、機能層3は、535Dにおいて送信の通知が受信されると、満了タイマーを始動させることができる。しかし、545Dにおいて送信の失敗の通知を次に受信すると、機能層3は、この満了タイマーが満了するのを待つ必要はなく、むしろ、機能層1からの通知を介して、データパケットを再送信する必要があると推測することができる。

したがって、機能層1からの送信の失敗の通知に応答して、機能層3は、データパケットを送信するための別の要求を、(たとえば、データ要求の送信の再発行を避ける期間に対応する満了タイマー、またはACKを待機する期間に対応する満了タイマーが、満了したかどうかに関係なく)機能層2に対して発行する(550D)。機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する(555D)。そして、機能層2は、機能層2の送信ウィンドウでパケットのすべての送信を試みるように、機能層1に指示する(560D)。機能層1は、機能層2から送信の順序を受信し、次いで、機能層2の送信ウィンドウからのデータパケットを、固有の送信ウィンドウに追加する(565D)。570Dにおいて、機能層1が、データパケットのRAN120への送信に成功し、RAN120が、データパケットのアプリケーションサーバ170への転送に成功したと仮定する。したがって、アプリケーションサーバ170は、層3のACKメッセージをAT1に送り返すことによって、データパケットの受信に成功したと確認応答する(575D)。

ACKを受信すると、機能層3は、別のデータパケットを送信すべきかどうかを決定する(580D)。機能層3が別のデータパケットを送信すると決定すると、処理は505Dに戻る。それ以外の場合、機能層3が580Dにおいて別のデータパケットを送信しないと決定すると、図5Dの処理は終了するが、500Dの通信セッションは、AT1が、ある期間データパケットを送ることなくデータパケットを受信することで、継続しうる。

シグナリングダイアグラムを簡潔にするために図5Dには明示的に示されないが、550Dと575Dの間の、データパケットの送信の繰り返しの試みは、適宜、535Dおよび545Dの通知とも関連付けられてよいことが、理解されよう。これらの通知メッセージは、分かりやすくするために省略されるが、たとえば、送信の通知は、570Dの後で機能層1から機能層3に送られてよく、これによって、満了タイマーが機能層3において始動され得ることが、理解されよう。

さらなる例では、図5Dを参照すると、Enhanced Multi-flow Packet Applicationを用いる場合、RLP層(たとえば機能層1)が、最大送信単位(MTU)の設定および設定解除を行う。RLP NACKが機能層1で受信される場合、パケットを閾値の回数再送信したRLP層は、(たとえば、図5Bの535B、図5Dの535Dのように)MTUの送信が成功したかどうかを高次層(たとえば機能層3)に示すことができる。RLP NACKが無効にされるが、MTUが、物理層パケットにわたってさらにセグメント化される複数のRLPパケットにわたり断片化される場合、セグメントの損失が、物理層NACKにより推測され得る。RLPパケットは、これらの物理層NACKに基づいて、成功したと推測され得る。しかし、物理層セグメントの1つのみが完全に失われた場合でも、MTUは失われ、この情報は高次層により利用されて、MTUの再送信を引き起こすことができる(たとえば、言い換えると、任意のパケット「セグメント」に対するNACKまたはパケット送信の失敗が、パケット全体の送信の失敗を推測するために用いられ得る)。損失がRLC層によって推測される場合、同様の手順が、WCDMA(登録商標)の物理層において実施され得る。したがって、540DのNACKまたはパケット送信の失敗は、任意の特定のセグメントに対するNACKまたはパケット送信の失敗であり得る。

図6Aは、ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、従来の機構を示す。したがって、図6Aを参照して、アプリケーションサーバ170は、AT1とAT2との間のストリーミング通信セッション(たとえばVoIPセッション)に相当する第1のセッションをセットアップし(600A)、次いで、アプリケーションサーバ170は、ファイル転送セッションに相当する第2のセッションをセットアップし、AT1からAT2への1つまたは複数のファイルの転送を容易にすると、仮定する(605A)。600Aの第1のセッションは、605Aの第2のセッション(QoSをまったく有さなくてもよい)と比較して、サービス品質(QoS)がより高いことがさらに仮定され得る。

この時点において、AT1は、第1のセッション(すなわちストリーミング通信セッション)のためのAT1のリアルタイムメディア送信をサポートできる、比較的「高速な」ネットワークに位置し、第2のセッション(すなわちファイル転送セッション)のための所与のペイロードサイズにおいて、AT1のパケット送信を同時にサポートすることもできると、さらに仮定する。

したがって、AT1は、第1のセッションのためにストリーミングパケット#1を送信し(610A)、次いで、第2のセッションのためにデータパケット#1を送信する(615Aおよび616A)。そして、AT1は、第1のセッションのためにストリーミングパケット#2を送信し(620A)、次いで、第2のセッションのためにデータパケット#2を送信する(625Aおよび626A)。そして、AT1は、第1のセッションのためにストリーミングパケット#3を送信する(630A)。

以下では、データ速度の「低い」環境およびデータ速度の「高い」環境への言及がなされる。理解されるように、転送されているデータのタイプ(およびどの程度の量のデータが一斉にまたは同時に転送されているか)に基づいて、ユーザが「良好な」ユーザ体験を得るための、時間に対する何らかの期待がある。この場合、ノミナルのデータ速度が定められることがあり、これによって、多くのユーザが、満足のいく体験レベルを判断すると予想される。ノミナルのデータ速度は、様々なネットワーク技術(たとえば、EV-DO、LTE、WiFiなど)の間で変わることがあり、個々のユーザの性能に対する期待および/または他の要因に基づいても変わり得る。したがって、本明細書で用いられる場合、データ速度の低い環境は、データ速度の高い環境と比較して、予測されるデータ速度または実際のデータ速度が低いことと関連付けられる。また、本明細書で用いられる場合、データ速度の低い環境は、関連するノミナルのデータ速度よりも低速な、実際のデータ速度または予測されるデータ速度と関連付けられ、データ速度の高い環境は、関連するノミナルのデータ速度以上の、実際のデータ速度または予測されるデータ速度と関連付けられる。

この時点において、AT1が、データ速度の低い環境に移行した(たとえば、EV-DOから1xシステムへのハンドオフを介して、別のネットワークへのハンドオフを伴わずにネットワーク条件の悪化により、同一の物理チャネルリソースが複数のセッションまたはアプリケーションにより共有されていることにより、など)と仮定する(635A)。したがって、AT1は、スケジューリングされたとおりに第2のセッションのためのデータパケット#3を依然として送り(640A)、アプリケーションサーバ170は、データパケット#3をAT2に送る(641A)。しかし、データ速度の低い環境にあるので、データパケット#3の送信には、より長い時間がかかり、第1のセッションのためのストリーミングパケット#4がスケジューリングされるスロットと、部分的に重複する。したがって、第2のセッションのためのデータパケット#3が送信を完了できるように、第1のセッションのためのストリーミングパケット#4は、645Aにおいて、スケジューリングされたスロットの間、脱落または遅延する。そして、第1のセッションのためのストリーミングパケット#4は、650Aにおける第2のセッションのためのデータパケット#3の送信の後、スロットの送信のために再びスケジューリングされる。

理解されるように、図6Aでは、第1のセッションが一般にパケット送信の遅延の影響をより受けやすいが、低速なデータ速度環境では、データパケット#3の送信が、第1のセッションのための次のストリーミングパケットの送信を遅らせる。たとえば、機能層1はすでに、ある数のパケットを送信待ち行列の中に有するので、第2のセッションのパケットがすでに待ち行列にある時に、第1のセッションのパケットを、第2のセッションのパケットよりも優先し続けることは難しいことがある。

したがって、図6Bは、リアルタイムセッションまたはストリーミングセッションのパケット送信の遅延が低減および/または完全に回避されるように、ファイル転送セッションのような非ストリーミングセッションのためのデータパケットのサイズが動的に調整される、本発明の実施形態を示す。図6Bを参照すると、600Bから630Bは、図6Aの600Aから630Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。

635Bにおいて、AT1は、AT1がデータ速度の低い環境に移行したことを(たとえば635Aにおいて)検知する(AT1は、移行の間にこの検知を必ずしも行わない)。ある例では、データ速度の低い環境の検知は、ハンドセットに対して対応できないQoSを有する、1x、General Packet Radio Service(GPRS)、Evolution Data Optimized(EV-DO) Rel.0ネットワークまたはRev.Aネットワークに入ったことなどに、相当し得る。

635Bにおいてデータ速度の低い環境に移行した後、AT1は、第2のセッションのためのパケット内のデータペイロードのサイズを、動的に低減する(640B)。たとえば、640Bのペイロードサイズ低減は、AT1が移行した先のネットワークに基づいて計算され得る(たとえば、第1のペイロードサイズが、EV-DOネットワークを通じたファイル転送セッションのために用いられ、第2のペイロードサイズが、1xネットワークを通じたファイル転送セッションのために用いられる、など)。あるいは、640Bのペイロードサイズ低減は、第2のセッションのデータパケットが、第1のセッションのストリーミングデータパケットの遅延または再スケジューリングを引き起こさないように、データ速度の低い環境についての任意の他のタイプの推定に基づいて計算されてもよい。あるいは、アプリケーションサーバ170は、次のストリーミングデータパケットへの遅延を招くことなく次のデータパケットに割り当てられ得るサイズを計算することができ、アプリケーションサーバ170は、許容可能なデータパケットサイズを、(たとえばACKパケットなどにおいて)AT1に搬送することができる。

したがって、AT1は、第2のセッションのためのデータパケット#3aを送信する(645Bおよび646B)。上で述べられたように、データパケット#3aのペイロード部分は、615Bおよび616Bならびに/または625Bおよび626Bの、データパケット#1および/またはデータパケット#2のペイロード部分よりも小さい。次に、AT1は、第1のセッションのためにストリーミングパケット#4を送信する(650B)。645Bおよび646Bとは異なり、AT1のデータ速度の低い環境に順応するために、第1のセッションではなく第2のセッションのためのパケットが減らされるので、第1のセッションのためのストリーミングパケット#4は、時間通りに、かつフルペイロードのパケットとして送信され得る。セッションは継続し、これにより、AT1は、減らされたペイロード部分を有する第2のセッションのためのデータパケット#3bを送信し(655Bおよび656B)、次いでAT1は、再スケジューリングすることなく、完全なデータ速度で別のストリーミングデータパケット#5を送信する(660B)。

したがって、ファイル転送セッションよりもストリーミング通信セッションを優先することによって、AT1は、AT1がデータ速度の低い環境に移行した場合に、ストリーミング通信セッションのためのリアルタイムパケットの再スケジューリングまたは遅延の発生を減らすことができる。

さらに、図6Bは、データ速度の高い環境またはネットワークから、データ速度の低い環境またはネットワークへ、AT1が移行する特定の例を示すが、図6Bは、動的な速度制御アルゴリズム(DRCA)をより広く表すものであることが理解されよう。たとえば、DRCAは、高優先度の、遅延の影響を受けやすいストリーミングされるデータを、一定の間隔で(図6Bの第1のセッションにおけるように、用途が変化するごとに)スケジューリングすることができ、非QoSデータ(たとえば図6Bの第2のセッション)を、ストリーミングされるデータの連続する送信の間の時間間隔で、量を制御して送信することができる。たとえば、ネットワークの種類に応じて、非QoS用途のデータの量は、一定の値に制限され得る。

あるいは、非QoS用途のデータの量(図6Bからの第2のセッション)は、1つの適応アルゴリズムまたは探索アルゴリズムに基づいて、すべての連続する時間間隔において調整され得る。このアルゴリズムは、たとえば、慎重な値で開始して、音声/QoSパケットが遅延の影響を受けない場合にはMTUサイズを大きくして、音声パケットが何らかの遅延の影響を受ける場合には送信されるデータの量を減らすというものである。たとえば、reward-penalty型のアルゴリズムのような学習アルゴリズムが、用いられ得る。別の代替的な例では、非QoS用途のデータの量(すなわち、図6Bからの第2のセッション)は、QoSストリーミングデータとともに過去の非QoSストリーミングデータを送信するのに必要なスロットの数に関する正確な情報に基づいて、すべての連続する時間間隔において調整されてよく、この場合、次の時間間隔でスケジューリングされるデータの量は、ハンドセット(または、たとえば、この情報をハンドセットまたはAT1に伝えることができるアプリケーションサーバ170)により計算され得る。

したがって、図6Bは、データ速度の低い環境へ入った時の、データペイロードの「低減」を明示的に示す。ある代替的な例では、図6Bは、データ速度の低い環境からデータ速度の高い環境へ移行するATに対応するように、修正され得る。この代替的な例では、ペイロードは、データ速度の高い環境に入ると上がり、次の非QoSパケットのための実際のペイロードを計算する多くの異なる機構を、用いることができる。図6Cは、ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、別の従来の機構を示す。具体的には、送信AT1ではなくターゲットAT2が、データ速度の低い環境に移行することを除き、図6Cは、いくつかの面で図6Aと同様である。図6Cを参照すると、600Cから630Cは、それぞれ図6Aの600Aから630Aに、および/またはそれぞれ図6Bの600Bから630Bに実質的に対応するので、簡潔にするためにさらに説明はされない。

この時点において、AT2が、データ速度の低い環境に移行した(たとえば、EV-DOから1xシステムへのハンドオフを介して、別のネットワークへのハンドオフを伴わずにネットワーク条件の悪化により、など)と仮定する(635C)。したがって、AT1は、スケジューリングされたとおりに第2のセッションのためのデータパケット#3を依然として送り(640C)、アプリケーションサーバ170は、データパケット#3のAT2への送信を開始する(641C)。データパケット#3のAT2への送信が完了する前に、AT1は、第1のセッションのためのストリーミングパケット#4を、AT2への送信のためにアプリケーションサーバ170に送信する。アプリケーションサーバ170は、ストリーミングパケット#4のAT2への転送を遅延させる(646C)。言い換えると、AT2がデータ速度の低い環境にあるので、アプリケーションサーバ170からAT2へのデータパケット#3の送信には、より長い時間がかかり、第1のセッションのためのストリーミングパケット#4がスケジューリングされるスロットと、部分的に重複する。したがって、第1のセッションのためのストリーミングパケット#4は、646Cにおいて遅延される。そして、第1のセッションのためのストリーミングパケット#4は、647Cにおける第2のセッションのためのデータパケット#3の送信の後、スロットの送信のために再スケジューリングされる。

理解されるように、図6Cでは、第1のセッションが一般にパケット送信の遅延の影響をより受けやすいが、低速なデータ速度環境では、データパケット#3の送信が、第1のセッションのための次のストリーミングパケットの送信を遅らせる。

したがって、図6Dは、リアルタイムセッションまたはストリーミングセッションのパケット送信の遅延が低減および/または完全に回避されるように、アプリケーションサーバ170および/またはRAN120において、ファイル転送セッションのようなダウンリンク非ストリーミングセッションのためのデータパケットのサイズが動的に調整される、本発明の実施形態を示す。図6Dを参照すると、600Dから635Dは、図6Cの600Cから635Cにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。

図6Dを参照すると、AT2が635Dにおいてデータ速度の低い環境に移行した後、アプリケーションサーバ170は、低速のデータ速度環境へのAT2の移行を検知する(640D)。たとえば、データ速度の低い環境へのAT2の移行の、アプリケーションサーバ170による検知は、(i)AT2の現在のデータ速度環境に関するAT2またはRAN120からの通知、(ii)アプリケーションサーバ170のAT2への接続の性能の低下の検知、(iii)AT2の現在の位置の報告、このときアプリケーションサーバ170は特定の地理的な領域またはサービングエリアに関連するデータ速度を知っている、および/または、(iv)AT2へのアプリケーションサーバ170のリンクまたは接続の性能の特性を、アプリケーションサーバ170が推測することができる任意の他の機構に、相当し得る。

AT2がデータ速度の低い環境に移行したと、640Dで判定すると、アプリケーションサーバ170は、アプリケーションサーバ170が第2のセッションのためにAT2に転送している個々のデータパケットのペイロードを、低減する(645D)。たとえば、645Dのペイロードサイズ低減は、AT2が移行した先のネットワークに基づいて計算され得る(たとえば、第1のペイロードサイズが、EV-DOネットワークを通じたファイル転送セッションのために用いられ、第2のペイロードサイズが、1xネットワークを通じたファイル転送セッションのために用いられる、など)。あるいは、645Dのペイロードサイズ低減は、第2のセッションのデータパケットが、第1のセッションのストリーミングデータパケットの遅延または再スケジューリングを引き起こさないように、データ速度の低い環境についての任意の他の種類の推定に基づいて計算され得る。あるいは、AT2は、次のストリーミングデータパケットへの遅延を招くことなく次のデータパケットに割り当ることができるサイズを計算することができ、AT2は、許容可能なデータパケットサイズを、(たとえばACKパケットなどにおいて)アプリケーションサーバ170に伝達することができる。

したがって、AT1は、通常のまたはフルサイズのペイロード部分を有する、第2のセッションのためのデータパケット#3を送信する(650D)。AT1からデータパケット#3を受信すると、アプリケーションサーバ170は、データパケット#3のペイロードサイズを低減して、低減されたペイロード部分を有するデータパケット#3aを生成し、一方で、データパケット#3aから除外された任意のデータペイロードをバッファリングする。そして、アプリケーションサーバ170は、データパケット#3aをAT2に送る(651D)。次に、AT1は、第1のセッションのためのストリーミングパケット#4をアプリケーションサーバ170に送信し(655D)、RAN120が、ペイロードサイズの低減によって、データパケット#3aをより迅速に送信できるようになるので、アプリケーションサーバ170は、図6Cに示される遅延を招くことなく、ストリーミングパケット#4をAT2に送ることができる(656D)。660Dにおいて、アプリケーションサーバ170は、低減されたペイロード部分を有する第2のセッションのためのデータパケット#3bを送信する。

したがって、ファイル転送セッションよりもストリーミング通信セッションを優先することによって、アプリケーションサーバ170は、ターゲットAT2がデータ速度の低い環境に移行した場合に、ストリーミング通信セッションのためのリアルタイムパケットの再スケジューリングまたは遅延の発生を減らすことができる。

さらに、図6Dは、データ速度の高い環境またはネットワークから、データ速度の低い環境またはネットワークへ、AT2が移行する特定の例を示すが、図6Dは、動的な速度制御アルゴリズム(DRCA)をより広く表すものであることが理解されよう。たとえば、DRCAは、高優先度の、遅延の影響を受けやすいストリーミングされるデータを、一定の間隔で(図6Dの第1のセッションにおけるように、用途が変化するごとに)スケジューリングすることができ、非QoSデータ(たとえば図6Dの第2のセッション)を、ストリーミングされるデータの連続する送信の間の時間間隔で、量を制御して送信することができる。たとえば、ネットワークの種類に応じて、非QoS用途のデータの量は、一定の値に制限され得る。

あるいは、非QoS用途(図6Dからの第2のセッション)のデータの量は、1つの適応アルゴリズムまたは探索アルゴリズムに基づいて、すべての連続する時間間隔において調整され得る。このアルゴリズムは、たとえば、慎重な値で開始して、音声/QoSパケットが遅延の影響を受けない場合にはMTUサイズを大きくして、音声パケットが何らかの遅延の影響を受ける場合には送信されるデータの量を減らすというものである。たとえば、reward-penalty型のアルゴリズムのような学習アルゴリズムが、用いられ得る。別の代替的な例では、非QoS用途のデータの量(すなわち、図6Dからの第2のセッション)は、QoSストリーミングデータとともに過去の非QoSストリーミングデータを送信するのに必要なスロットの数に関する正確な情報に基づいて、すべての連続する時間間隔において調整されてよく、この場合、次の時間間隔でスケジューリングされるデータの量は、アプリケーションサーバ170(または、たとえば、この情報をアプリケーションサーバ170に伝えることができるハンドセット)により計算され得る。したがって、図6Dは、データ速度の低い環境に入った時のデータペイロードの「低減」を明示的に示すが、データペイロードが他の実施形態で調整される方式は、ペイロードを上げることができ(たとえば、データ速度の高い環境に入った時に)、次の非QoSパケットのための実際のペイロードを計算する多くの異なる機構を、用いることができる。

また、図6Dは、非QoSセッションまたは非リアルタイムセッションのために、動的なペイロード低減を実行するアプリケーションサーバ170を示すが、これらの動作は、本発明の他の実施形態では、AT2のRAN120により実行されてもよいことが理解されよう。この場合、アプリケーションサーバ170は、第1および第2のセッションのためのデータパケットをRAN120に転送し、RAN120は、ストリーミングパケットのペイロードサイズを動的に低減して、非ストリーミングパケットの送信がストリーミングセッションに対する遅延を招かないようにする役割を果たす。

図7Aは、ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、従来の機構を示す。したがって、図7Aを参照して、アプリケーションサーバ170は、AT1とAT2との間のストリーミング音声通信セッション(たとえばVoIPセッション)に相当する第1のセッションをセットアップし(700A)、次いで、アプリケーションサーバ170は、ファイル転送セッションに相当する第2のセッションをセットアップし、AT1からAT2への1つまたは複数のファイルの転送を容易にすると、仮定する(705A)。700Aの第1のセッションは、705Aの第2のセッション(QoSをまったく有さなくてもよい)と比較して、サービス品質(QoS)がより高いことがさらに仮定され得る。具体的には、AT1のユーザが声による質問「Hello, how are you doing today?」をAT2に転送しており、AT2のユーザが「Good.」を示すことによりAT1のユーザの質問に答えるという、図7Aが説明される。この言葉による第1のセッションの交換の間、AT1は、第2のセッションのためのデータパケットもAT2に送っていると仮定する。

したがって、AT1は、第1のセッションのために音声パケット#1(「Hello, How」)を送信し(710A)、次いで、第2のセッションのためにデータパケット#1を送信する(715Aおよび716A)。そして、AT1は、第1のセッションのために音声パケット#2(「Are You」)を送信し(720A)、次いで、第2のセッションのためにデータパケット#2を送信する(725Aおよび726A)。そして、AT1は、第1のセッションのために音声パケット#3(「Doing Today?」)を送信し(730A)、次いで、第2のセッションのためにデータパケット#3を送信する(735Aおよび736A)。

この時点において、AT1のユーザが、AT1のマイクロフォンに向かって話すのを止めると仮定する。したがって、AT1は、無音パケットを音声パケット#4として送信し、無音パケットは、無音フレームのみを含む音声パケットに相当する(740A)。無音パケットは、比較的少量のデータペイロードを含み、一般に、バックグラウンドの「コンフォート」ノイズのみを含むが、「本物の」音声パケットと同じQoSを有するものとしてネットワークで扱われる。理解されるように、音声とメディアを同時に送る状況では、これらの無音パケットは、ファイル転送セッションまたは第2のセッションのためのデータを代わりに送ることができたであろうパケットである。その後、AT1は、第2のセッションのためのデータパケット#4を送り(745Aおよび746A)、最終的に、AT2は、自身の音声応答パケット#1(「Good」)により応答することによって、AT1の質問に応答する(750A)。

理解されるように、図7Aにおいて、AT1は、実際の音声データがほとんどまたはまったく含まれていない場合であっても、無音パケットを送る。したがって、図7Bを参照して次で説明されるように、音声(または他のマルチメディア)セッションが行われると同時にファイル転送が行われる同時セッションでは、無音パケットを圧縮することができ、ファイル転送セッションのためのデータパケットを代わりに送ることができる。

したがって、図7Bは、ストリーミングマルチメディアセッションのための無音フレームが圧縮され、低QoSのファイル転送セッションまたは非QoSのファイル転送セッションのためのより多数のデータパケットが送信される、本発明の実施形態を示す。図7Bを参照すると、700Bから736Bは、図7Aの700Aから736Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。

第2のセッションのためのデータパケット#3を735Bにおいて送信した後、待ち行列の次のストリーミング音声パケットが無音パケットに相当すると、AT1が判定する(740B)。本明細書で用いられる場合、無音パケットは一連の無音フレームに相当し得る。たとえば、無音が閾値期間(たとえば100ms)に達する一連の無音フレームが740Bで検知されると、このことにより、無音パケットが検知されることになり得る。なぜなら、次の音声パケット(たとえばRTPパケット)は、無音フレームしか含まず、実際の音声データを含まない(すなわち、ノイズ)からである。ある例では、EV-DOプロトコルは、20msごとに無音フレームを特定し、この場合、AT1は、次の音声パケットに含まれることになる20msのフレームの数を数えることができ、これらの20msのフレームの各々が無音フレームである場合、AT1は次の音声パケットが無音パケットであると判定する。

さらに、各無音フレームは一般に、標準的な方式で構築されているので、無音フレームは比較的検知しやすいことがある。したがって、AT1は、各音声フレームを、所定の無音フレームと比較することができる。テンプレートとして用いるために単一の無音フレームを記憶することで、AT1は、テンプレートの無音フレームと、待ち行列にある音声パケットを比較して、特定の音声パケットが無音フレームを搬送しているかどうかを判定することができる。

待ち行列の次のストリーミング音声パケットが無音パケットに相当すると、740Bで判定した後、AT1は、無音パケットを圧縮し、無音パケットまたは音声パケット#4を搬送することになっていたスロットにおいて、第2のセッションのための待ち行列の次のデータパケットをスケジューリングする(745B)。そして、AT1は、最初は第1のセッションの音声パケット#4をスケジューリングされていたスロットで、第2のセッションのための待ち行列の次のデータパケット(すなわちデータパケット#4)を送信する(750B)。AT2は、751Bにおいて予定されていないデータパケット#4を受信し、第2のセッションのための非ストリーミングデータパケットまたは非音声データパケットの連続した受信を、AT1が第1のセッションのための無音パケットを圧縮したことの表れであると解釈し、これにより、一連の無音フレームを含む無音パケットをAT1が実際に送信していた場合にAT2が有していたであろう、「コンフォート」ノイズを再生する(755B)。

そして、AT1は、データパケット#4が無音パケットを置き換える前に、最初はデータパケット#4の送信をスケジューリングされていたスロットで、第2のセッションのためのデータパケット#5を送信する(760B)。何らかの後の時点で、AT2は、固有の音声応答パケット#1(「Good」)により応答することによって、AT1の質問に応答する(765B)。したがって、ストリーミング通信セッションがファイル転送セッションと同時に行われる時に、無音パケットを圧縮することによって、ストリーミングセッションの音声パケットよりも通常は優先順位の低い、ファイル転送セッションのためのデータパケットが代わりに送られる。

図7Cは、ストリーミングマルチメディアセッションのための無音フレームが圧縮され、低QoSのファイル転送セッションまたは非QoSのファイル転送セッションのためのより多数のデータパケットが送信される、本発明の別の実施形態を示す。具体的には、無音パケットの圧縮が、送信AT1ではなくアプリケーションサーバ170で行われることを除き、図7Cは、いくつかの面で図7Bと同様である。図7Cを参照すると、700Cから736Cは、それぞれ図7Aの700Aから736Aに、および/またはそれぞれ図7Bの700Bから736Bに実質的に対応するので、簡潔にするためにさらに説明はされない。

図7Cを参照すると、735Cおよび736Cにおいて第2のセッションのためのデータパケット#3を送信した後、AT1は、第1のセッションのために、音声パケット#4をアプリケーションサーバ170に送信する(740C)。図7Cの実施形態では、音声パケット#4は、所与の数の無音フレームを含む無音パケットに相当することが、仮定され得る。アプリケーションサーバ170は、音声パケット#4を受信して評価し、音声パケット#4が無音パケットであると判定する(745C)。次のストリーミング音声パケットが#4が無音パケットに相当すると、745Cにおいて判定した後、アプリケーションサーバ170は、無音パケットを圧縮して、音声パケット#4を送る代わりに、AT2のためのAT1から受信された次のパケット(たとえば、第2のセッションのためのデータパケットと第1のセッションのための無音ではないパケットのいずれか)を、スケジューリングすると決定する(750C)。

したがって、AT1は次いで、第2のセッションのための待ち行列の次のデータパケット(すなわちデータパケット#4)を、アプリケーションサーバ170に送信する(755C)。この例では、データパケット#4は、AT1において、スケジューリングされたスロットにおいて変えられることなく送られる。アプリケーションサーバ170は、データパケット#4を受信し、最初は第1のセッションの音声パケット#4をスケジューリングされていたスロットで、データパケット#4をAT2に転送する（756Ｃ）。AT2は、予定されていないデータパケット#4を受信し、第2のセッションのための非ストリーミングデータパケットまたは非音声データパケットの連続した受信を、アプリケーションサーバ170が第1のセッションのための無音パケットを圧縮したことの表れであると解釈し、これにより、一連の無音フレームを含む無音パケットをAT1が実際に送信していた場合にAT2が有していたであろう、「コンフォート」ノイズを再生する(760C)。

何らかの後の時点で、AT2は、固有の音声応答パケット#1(「Good」)により応答することによって、AT1の質問に応答する(765C)。したがって、ストリーミング通信セッションがファイル転送セッションと同時に行われる時に、無音パケットを圧縮することによって、ストリーミングセッションの音声パケットよりも通常は優先順位の低い、ファイル転送セッションのためのデータパケットが、代わりにアプリケーションサーバ170により送られる。

図8Aは、従来のファイル転送セッションの終了または完了に注目した処理を示す。図8Aを参照すると、アプリケーションサーバ170は、AT1からAT2への1つまたは複数のファイルの転送を容易にするために、ファイル転送セッションをセットアップする(800A)。図8Aの例では、ファイル転送セッションは、複数のデータパケット1...Nの転送に相当すると仮定することができ、N≧3である。したがって、800Aにおいてファイル転送セッションがセットアップされた後、AT1は、ファイル転送セッションのためのデータパケット1...N-2をAT2に送る(805Aおよび806A)。809Aにおいて、アプリケーションサーバ170は、データパケット1...N-2に対して確認応答する。AT2がデータパケット1...N-2の各々を受信するので、AT2はまた、データパケット1...N-2の各々に対する確認応答をアプリケーションサーバ170に送り返すと、仮定する(810A)。次に、AT1がデータパケットN-1およびNを送り、これらはファイル転送セッションのための最後の2つのパケットである(815Aおよび816A、ならびに820Aおよび821A)。

この時点において、AT1は、ファイル転送セッションのためのパケットのすべてをAT2に送信しているので、AT1は825Aにおいてデータの送信を停止する。しかし、やはり825Aにおいて、AT1は送信されたデータパケットのすべてに対するACKをまだ受信しておらず(すなわちデータパケットN-1およびN)、NACKがデータパケットN-1および/またはデータパケットNに対して受信される(あるいはACKタイムアウト)可能性があり、その場合パケットの再送信が要求されるので、AT1はTCHを保持する。829Aにおいて、アプリケーションサーバ170は、データパケットN-1およびNに対して確認応答し、その後、AT1はTCHを切断する(830A)。この例では、AT2は最終的に、データパケットN-1とデータパケットNの両方に対するACKも送ると、仮定する(835A)。

理解されるように、データパケットN-1およびNが図8Aで示されるように確認応答される場合、AT1は、ファイル転送セッションのために実際に必要な時間よりも長く、不必要にTCHを保持する。また、図8Bを参照して次に説明されるように、データパケットN-1および/またはNの再送信が必要とされる場合、これらのデータパケットの最初の送信から、データパケットの最終的な再送信までの期間は、AT1がTCHを有するが実際にデータを送信していない、「浪費」時間に相当する。図8Bは、ファイル転送セッションの終わりにおける、AT1とアプリケーションサーバ170との間のシグナリングに注目した、別の従来の処理を示すので、AT2とアプリケーションサーバ170との間のシグナリングが点線により示される。

図8Bを参照すると、800Bから810Bは、図8Aの800Aから810Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。データパケット1...N-2に対するACKを受信した後、AT1は、データパケットN-1の送信を試み(820B)、データパケットNの送信を試みる(825B)(たとえば、815BからのACKの一部が、これらの送信の試みの1つまたは複数の後で実際に受信できたとしても)。図8Bの実施形態では、820Bおよび825Bにおいてそれぞれ、データパケットN-1とデータパケットNの両方の送信の試みが失敗すると、仮定する。

830Bにおいて、図8Aの825Aにおけるように、AT1はデータの送信を停止し、TCHを保持する。次に、アプリケーションサーバ170は、データパケットN-1およびNに対するNACKを、AT1に送る(837B)。また、所与の期間の後、AT2はまた、データパケットN-1およびNのためのNACKを、アプリケーションサーバ170に送ることを決定し(839B)、838Bにおいて、NACKが、AT2からアプリケーションサーバ170に送られる。したがって、AT1は、840Bおよび841B、ならびに845Bおよび846Bにおいてそれぞれ、データパケットN-1およびNを再送信する。アプリケーションサーバ170は、AT1からのデータパケットN-1およびNに対して確認応答し(849B)、その後、AT1はTCHを切断する(850B)。AT2はまた、アプリケーションサーバ170からの、AT2における受信が成功したデータパケットN-1およびNに対して、確認応答する(855B)。

図8Cおよび図8Dを参照してここで説明されるように、本発明の実施形態は、送信ATがTCHを有するがデータを送信していない期間における、データパケットの機会主義的な再送信または先取り的な再送信を対象とする。図8Bと同様に、図8Cおよび図8Dは、AT1とアプリケーションサーバ170との間のシグナリングに各々注目するので、AT2とアプリケーションサーバ170との間のシグナリングは、点線により示される。

図8Cを参照すると、800Cから821Cは、図8Aの800Aから821Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。データパケットN-1およびNを、815Cおよび816Cにおいてそれぞれ送信した後、単にTCHを保持して、AT2からのACKまたはNACKを待機するのではなく、AT1は、TCHを維持して、データパケットN-1およびNへのACKまたはNACKが実際に受信される前に、データパケットN-1およびNを先取り的に再送信することを決定する(825C)。

したがって、AT1は、830Cおよび835Cにおいてそれぞれ、データパケットN-1およびNをアプリケーションサーバ170に再送信し、アプリケーションサーバ170は、831Cおよび836Cにおいてそれぞれ、データパケットN-1およびNをAT2に転送する。アプリケーションサーバ170は、データパケットN-1およびNに対して確認応答し(837C)、その後、AT1はTCHを切断する(840C)。また、AT2は、アプリケーションサーバに対して、データパケットN-1およびNへの確認応答を行う(845C)。837CでAT1において受信されるACKは、815Cから820CにおけるデータパケットN-1およびNの最初の送信と、830Cから835CにおけるデータパケットN-1およびNの再送信とのいずれかのためのものであってよい(または、これらの何らかの組合せであってよく、このとき少なくとも1つのACKは最初の送信のためのものであり、少なくとも1つのACKは再送信のためのものである)。

さらに、図8Cは、データパケットN-1およびNの単一の再送信を示すが、ACKまたはNACKが、アプリケーションサーバ170から受信されるまで、または所与の回数(たとえば3回の送信など)受信されるまで、AT1は単に、データパケットN-1およびNの再送信を続けてもよいことを理解されたい。さらに、図8Cは、ファイル転送セッションのためのデータパケットのストリームの中の最後の2つのデータパケット(すなわち、データパケットN-1およびN)に対して再送信が実行される例を対象とするが、他の実施形態では、最後の3つのパケット、最後の4つのパケット、最後のパケットのみなどのような、異なる数のパケットについて、上で説明された先取り的なパケットの再送信を実行することができる。

図8Dを参照すると、800Dから825Dは、図8Bの800Bから825Bにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。データパケットN-1およびNの送信の試みが、820Dおよび825Dにおいてそれぞれ失敗した後、単にTCHを保持して、アプリケーションサーバ170からのACKタイムアウトまたはACKまたはNACKを待機するのではなく、AT1は、TCHを維持して、ACKまたはNACKの前に、データパケットN-1およびNを先取り的に再送信することを決定する(830D)。

したがって、AT1は、831Dおよび836Dにおいてそれぞれ、データパケットN-1およびNをアプリケーションサーバ170に再送信し、アプリケーションサーバ170は、836Dおよび841Dにおいてそれぞれ、データパケットN-1およびNをAT2に転送する。何らかの後の時点において、AT1は、アプリケーションサーバ170から、データパケットN-1およびNに対するACKを受信すると仮定する(845D)(たとえば、ある例では、831Dおよび835DからのデータパケットN-1およびNの前の送信に対するNACKは、AT1においても受信され得るが、その場合、再送信の1つのアプリケーションサーバ170への送信が成功したと仮定される)。AT1において845Dで受信されるACKは、831Dおよび835Dにおける、データパケットN-1およびNの再送信のためのものであることが、理解されよう(たとえば、これらのデータパケットの最初の送信は不成功であると仮定されるので)。この時点において、AT1はTCHを切断することができる(850D)。何らかの後の時点において、AT2はまた、アプリケーションサーバ170に対して、データパケットN-1およびNを受信したことを確認応答することができる(855D)。

さらに、図8Dは、データパケットN-1およびNの単一の再送信を示すが、ACKタイムアウトが判定されるまで、または、ACKもしくはNACKが、アプリケーションサーバ170から受信されるまで、または所与の回数(たとえば3回の送信など)受信されるまで、AT1は単に、データパケットN-1およびNの再送信を続けてもよいことが、理解されよう。さらに、図8Dは、ファイル転送セッションのためのデータパケットのストリームの中の最後の2つのデータパケット(すなわち、データパケットN-1およびN)に対して再送信が実行される例を対象とするが、他の実施形態では、最後の3つのパケット、最後の4つのパケット、最後のパケットのみなどのような、異なる数のパケットについて、上で説明された先取り的なパケットの再送信を実行することができる。

さらに、図8Cおよび図8Dは、データパケットの先取り的な再送信が、ファイル転送セッションの予想される終わりの時点の近くで行われる例を各々示すが、TCHがATにより維持されて連続的に用いられない、パケットの先取り的な再送信を引き起こすために、他の条件が用いられてもよいことが理解されよう。たとえば、送信者は、実際のネットワーク条件を計測していてもよく、ネットワーク条件が貧弱であると判定され、損失が存在する可能性が高い場合に、送信者は、パケットの最後のウィンドウを楽観的に再送信してもよい。あるいは、送信者(すなわちAT1)は、(ACKおよび再送信に利用可能な)接続の経路全体でどれだけのパケットが失われたかを測定する所与のタイプの「学習」アルゴリズムを利用してもよく、先取り的な再送信をいつ実行すべきかについて、経験に基づく推測を行う。学習アルゴリズムは、さらにより複雑であってもよく、特定のターゲットへの特定の呼、特定の位置への特定の呼、特定の時間帯における特定の呼などの期間全体に拡張されてもよい。ある例では、学習アルゴリズムは、データパケットをいつ先取り的に再送信すべきかを予測できるだけではなく、損失の可能性に基づいて、パケットを再送信する順序を、またはどのパケットを再送信すべきかを、予測することもできる。

図8Eは、本発明のある実施形態による、送信ATがTCHを有しデータを送信していない期間における、データパケットの別の機会主義的な再送信または先取り的な再送信を対象とする。図8Cおよび図8Dとは異なり、図8Eは、機械主義的な再送信または先取り的な再送信が、送信AT1ではなく、アプリケーションサーバ170により引き起こされまたは始まる、実装形態を対象とする。したがって、図8Eは、AT2とアプリケーションサーバ170との間のシグナリングに注目するので、AT1とアプリケーションサーバ170との間のシグナリングは、点線により示される。

図8Eを参照すると、800Eから810Eは、図8Dの800Dから810Dにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。図8Cと異なり、815Eおよび820Eにおいて、AT1は、データパケットN-1およびNのアプリケーションサーバ170への送信に成功する。しかし、アプリケーションサーバ170は、816Eおよび821Eにおいてそれぞれ、データパケットN-1およびNのAT2への送信に成功できない。

アプリケーションサーバ170は、825Eにおいて、データパケットN-1およびNに対して確認応答し、その後、AT1はTCHを切断することができる(826E)。830Eにおいて、データパケットN-1およびNの1つのインスタンスを単に転送するのではなく、アプリケーションサーバ170は、データパケットN-1およびNへのACKまたはNACKがAT2から実際に受信される前に、データパケットN-1およびNを先取り的に再送信することを決定する。ある例では、830Eの決定は、データパケットN-1およびNが通信セッションのための最後の2つのパケットに相当することを、アプリケーションサーバ170が知っていることに基づき得る。

したがって、アプリケーションサーバ170は、835Eおよび840Eにおいてそれぞれ、データパケットN-1およびNをAT2へ再送信する。何らかの後の時点において、アプリケーションサーバ170は、データパケットN-1およびNに対するACKを、AT2から受信する(845E)。この時点において、アプリケーションサーバ170は、データパケットN-1およびNの再送信を停止することができる(アプリケーションサーバ170がまだそうしていない場合)(850E)。

さらに、図8Eは、データパケットN-1およびNの単一の再送信を示すが、ACKまたはNACKが、AT2から受信されるまで、または所与の回数(たとえば3回の送信など)受信されるまで、アプリケーションサーバ170は単に、データパケットN-1およびNの再送信を続けてもよいことが、理解されよう。さらに、図8Eは、ファイル転送セッションのためのデータパケットのストリームの中の最後の2つのデータパケット(すなわち、データパケットN-1およびN)に対して再送信が実行される例を対象とするが、他の実施形態では、最後の3つのパケット、最後の4つのパケット、最後のパケットのみなどのような、異なる数のパケットについて、上で説明された先取り的なパケットの再送信を実行することができる。

コンテンツに基づく処理の実施形態が、ここで、図9Aから図9Dを参照して説明される。本明細書で用いられる場合、AT上のディスプレイに関して、ウィンドウは、ディスプレイ上で見えるように構成されるオブジェクトに相当し、AT上で実行される特定のアプリケーションと関連付けられる。たとえば、ATが携帯電話に相当し、ATがモバイルウェブブラウジングアプリケーションを実行しており、特定のウェブページがディスプレイ上でユーザに表示されていると仮定する。この場合、ウィンドウは、ディスプレイ上でATのユーザに特定のウェブページを提示するために、モバイルウェブブラウジングアプリケーションにより用いられる、グラフィカルな構造物に相当する。本明細書で用いられるようなウィンドウは、ATのディスプレイ上で見えるように構成されるが、各ウィンドウは、常にATのディスプレイ上で見えなくてもよいことが、理解されよう。たとえば、そうされなければATのディスプレイ上で見えるであろう特定のウィンドウは、最小化されてもよく、または別のウィンドウと重複してもよいので、ある期間、ATのディスプレイ上で見えなくなる。

別の例では、ATのディスプレイ上の異なるウィンドウは、ATのユーザがダウンロードを要求した異なるオブジェクトと関連付けられてよい。モバイルウェブブラウジングアプリケーションの場合、異なるオブジェクトは、ウィンドウの特定のウェブページと関連付けられてATのユーザに表示および/または提示されることになる、オブジェクトのセットを含み得る。しかし、これらのウィンドウのすべてを、所与の時間において「アクティブ」にはできない。たとえば、ATの所与のユーザは、4つの異なるウェブサイトを、モバイルウェブブラウジングアプリケーションを介してATにダウンロードするように要求できるが、所与のユーザは、4つのウェブサイトの1つを、「アクティブ」に、またはAT上で見える状態に設定することができる。あるいは、複数のウィンドウが見えていてもよいが、1つの特定のウィンドウ(すなわち、「アクティブ」ウィンドウがATのディスプレイ上で完全に見えており、他のウィンドウが、アクティブウィンドウにより、部分的にかつ/または完全に重ねられまたは覆われている場合などは、アクティブウィンドウ)が、他のウィンドウよりも目立つように提示される。理解されるように、このことは、ユーザが他のウェブサイトの前にアクティブなウェブサイトを見ることに興味があることを、示している。しかし、4つのウェブサイトのオブジェクトのダウンロード元のサーバは、従来、所与のユーザがどのウィンドウをアクティブにしたかを認識しない。したがって、図9Aは、本発明のある実施形態における、コンテンツに基づく優先順位の方式に従って、ATにファイルオブジェクトを選択的にダウンロードする処理を示す。

図9Aを参照すると、所与のAT(「AT2」)は、複数のオブジェクトをダウンロードするための、1つまたは複数のユーザ要求を受信する(900A)。ある例では、900Aの要求は、AT2のユーザがダウンロードを要求することに相当してもよく、または、AT1のユーザが複数のオブジェクトをAT2に送るのを要求していることを示す、AT1から受信されたメッセージに相当してもよく、またはこれらの組合せに相当してもよい。上で述べられたように、900Aの要求は、ウェブブラウザの複数のウィンドウの中の、異なるウェブサイトと関連付けられる内容を、ロードするための要求に相当し得る。905Aにおいて、AT2は、AT2上のどのウィンドウが現在「アクティブ」であるかを判定する。上で述べられたように、「アクティブ」ウィンドウは、AT2のユーザにより現在選択されていない「隠れた」ウィンドウとは対照的に、どのブラウザウィンドウが最もAT2上で目立つかに、相当し得る。次に、AT2は、現在のアクティブウィンドウと関連付けられるべき、900Aからの複数のオブジェクトの少なくとも1つを決定する(910A)。たとえば、スポーツのウェブサイト、さらにニュースのウェブサイトをロードすることを、900Aにおいてユーザが要求する場合、スポーツのウェブサイトが表示されることになるウィンドウは、AT2上で最も目立つように表示され、910Aにおいて現在のアクティブウィンドウと関連すると判定されたファイルまたはオブジェクトは、スポーツのウェブサイトと関連付けられるオブジェクトである。

915Aにおいて、AT2は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数のダウンロード要求を構成し、さらに、どのオブジェクトがAT2の現在のアクティブウィンドウと関連付けられるかを示すように、その要求を構成する(915A)。理解されるように、どのオブジェクトがATの現在のアクティブウィンドウと関連付けられるかを示すことは、関連付けられたオブジェクトを、関連付けられていないオブジェクトよりも優先するように機能する。920Aにおいて、AT2は、構成された要求をアプリケーションサーバ170に送る(920A)。そして、アプリケーションサーバ170は、構成された要求をAT1に送る(922A)。920Aで受信される構成された要求に応答して、AT1は、922AでAT1に転送された、構成された要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトのAT2への送信を開始する(924A)。たとえば、AT1は、AT2の現在のアクティブウィンドウと関連付けられるオブジェクトをまず提供し、次いで、関連付けられないオブジェクトを提供することができる。同様に、アプリケーションサーバ170は、924AにおいてAT1からオブジェクトを受信し、そして、構成された要求のオブジェクトの優先順位に従って、複数のオブジェクトのAT2への提供を開始する(925A)。

複数のオブジェクトのダウンロードの間、AT2は、現在のアクティブウィンドウが変化したかどうかを判定する(930A)。変化していない場合、AT2は、ダウンロードが完了したかどうかを判定する(933A)。ダウンロードが完了した場合、処理は900Aに戻り、そこで、AT2は次のオブジェクトのダウンロード要求を待機する。それ以外の場合、現在のアクティブウィンドウが変化しておらず、ダウンロードがまだ完了していない時は、AT2は、複数のオブジェクトのダウンロードの監視を続ける。しかし、現在のアクティブウィンドウが変化したと、930AにおいてAT2が判定した場合(たとえば、ユーザがAT2を異なるアクティブウィンドウに移行した場合)、AT2は、新たな現在のアクティブウィンドウと関連付けられるべき、900Aからの複数のオブジェクトの少なくとも1つを決定する(935A)。

940Aにおいて、AT1は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数の補助的なダウンロード要求を構成し、さらに、どのオブジェクトがAT2の新たな現在のアクティブウィンドウと関連付けられるかを示すように、補助的な要求を構成する。945Aにおいて、AT2は、構成された補助的な要求をアプリケーションサーバ170に送る。945Aで受信される構成された補助的な要求に応答して、アプリケーションサーバ170は、複数のオブジェクトをアプリケーションサーバ170からAT2に提供するための、ダウンロードの優先順位を更新し、また、(たとえば、少なくとも、AT1とAT2のみの間の1対1の通信セッションについて)AT1が複数のオブジェクトをアプリケーションサーバ170にアップロードする際の、アップロードの優先順位も更新する(950A)。また950Aにおいて、アプリケーションサーバ170は、AT2のウィンドウの変化に基づく新たなまたは更新されたオブジェクトの優先順位に順応するように、AT1がアップロードの順序を調整することを、要求するメッセージを、AT1に送ることができる。ある例では、アップロードおよびダウンロードの順序または優先順位は、同じになるように設定され得る。たとえば、ファイルA、B、C、およびDについて、ダウンロードの順序は[A,B,C,D]であってよく、アップロードの順序も[A,B,C,D]であってよい。しかし、ある代替的な実施形態では、アップロードおよびダウンロードの順序は同じである必要はない。たとえば、ファイルBがアプリケーションサーバ170においてすでにアクセス可能である場合には、ダウンロードの順序は[A,B,C,D]であってよく、アップロードの順序は[A,C,D]であってよい。

その後、AT1は、構成された補助的な要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトのアプリケーションサーバ170への送信を続け、アプリケーションサーバ170は同様に、構成された補助的な要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトのAT2への送信を続ける。

理解されるように、図9Aは、ユーザのコンテンツの優先順位が、ユーザがどのウィンドウをアクティブに設定したかに基づいて推測され、推測されたユーザの優先順位が、次いでダウンロードサーバ(またはアプリケーションサーバ170)に運ばれる、処理を説明する。別の例では、ユーザは、オブジェクトをダウンロードするための優先順位を、明示的に確立することができるので、ユーザの挙動からユーザの予想される優先順位を推測することは、行う必要がない。

したがって、図9Bを参照すると、AT2は、ユーザ規定のオブジェクトのダウンロードの優先順位のセットを受信する(900B)。ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、いくつかの異なる方法で構成され得る。

たとえば、ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、あるMIMEタイプを他のMIMEタイプよりも優先する(たとえば、グラフィカルな画像よりも文字を優先する、音声よりも映像を優先する、グラフィクスよりも音声を優先するなど)ように構成され得る。たとえば、AT2は、複数の異なるMIMEタイプのオブジェクトがこれまでにダウンロードされた、頻度を追跡することができ、そして、より頻繁にダウンロードされたMIMEタイプに、より高い優先順位を割り当てることができる。別の例では、多くのウェブサイトで一般的なように、カスケーディングスタイルシート(CSS)を用いた異なる層のz-indexを生成することができ、z-indexは所与のページ内の優先順位を伝えることができる。したがって、特定のウェブサイトが音楽に関連するウェブサイトである場合、音声が、他の形態のメディア(たとえば、文字、画像、映像など)よりも優先され得る。別の例では、特定のウェブサイトがグラフィックの静止画像または美術に関連する場合、画像が、他の形態のメディア(たとえば、文字、音声など)よりも優先され得る。さらなる例では、異なるウェブサイトのz-indexは、ウェブサイト間の優先順位を確立するために用いられ得るので、AT2が複数のウェブサイトを同時にロードしようとしている場合、それぞれのウェブサイトのオブジェクトは、それぞれの相対的な優先度に従ってダウンロードされ得る。別の例では、CSS要素(たとえば、背景テンプレート、ナビゲーションバー、本文、および/または他のjavascript(登録商標)ウィジェット)を含むウェブページは、特定の順序で(たとえば、本文、ナビゲーションバー、背景テンプレート、javascript(登録商標)ウィジェットの順序で)z-indexを編成し、ユーザ体験を向上させることができる。

別の実施形態では、ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、あるアプリケーションのためのファイルを他のアプリケーションのためのファイルよりも優先するものであってよい。ある例では、アプリケーションのタイプは、重要度または緊急性を示すものであり得るので、たとえば、受動的なOSの更新よりも、ウェブブラウジングセッションが優先されるように、より重要なまたはより緊急のアプリケーションに優先権が与えられる。別の例では、AT2は、どの程度頻繁にアプリケーションが使用または実行されるかに関連する、情報を記録することができる。そして、アプリケーションの使用履歴情報は、アプリケーション間の相対的な優先順位を確立するために用いられ得るので、より頻繁に用いられるアプリケーションが、頻繁には用いられないアプリケーションよりも優先される。

別の例では、AT2のユーザがファイルのダウンロードを要求するたびに(たとえば、ユーザが移動しURLをクリックするたびになど)、ファイルのダウンロード要求と関連付けられるタイムスタンプが、AT2に記憶され得る。そして、AT2のユーザがそれぞれのファイルのダウンロードを要求する相対的な時刻が、ファイルのダウンロードの相対的な優先順位を確立するために、用いられ得る。たとえば、より最近に開始されたファイルのダウンロード要求は、ファイルのダウンロードの前の要求または古い要求よりも優先され得る。何らかの後の時点において、AT2は、複数のオブジェクトをダウンロードするための、1つまたは複数のユーザ要求を受信する(905B)。905Bの要求は、1つまたは複数のウェブサイトと関連付けられるコンテンツをロードするための要求に、またはある例では、通信セッションの間に別のATからのファイル転送を受信するための要求に、相当し得る。910Bにおいて、AT2は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数のダウンロード要求を構成し、さらに、900Bからの、ユーザ規定のオブジェクトのダウンロードの優先順位のセットを示すように、その要求を構成する。915Bにおいて、AT2は、構成された要求をアプリケーションサーバ170に送る(915B)。そして、アプリケーションサーバ170は、構成された要求をAT1に送る(918B)。構成された要求に応答して、AT1は、構成された要求で示される、ユーザ規定のオブジェクトのダウンロードの優先順位のセットに従って、複数のオブジェクトのアプリケーションサーバ170への送信を開始し（920B）、アプリケーションサーバ170は同様に、構成された要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトをAT2へ送る（925B）。理解されるように、AT1から見ると、オブジェクトの優先順位は、ダウンロードの優先順位ではなくアップロードの優先順位として解釈され得る。いずれの場合でも、ファイルがAT1からアップロードされる順序は、ファイルがアプリケーションサーバ170からAT2にダウンロードされる順序と一致するように保たれる。

別の実施形態では、図9Bを参照すると、AT2は、AT1からオブジェクトを受信している複数のATを表すものであってよい。この場合、AT1が複数のATにオブジェクトを送信するファイルの順序に、複数のATのすべてが影響を与えることを許され得るのではないことが、理解されよう。ある例では、アプリケーションサーバ170は、複数のATから、最初に要求されたユーザ規定のオブジェクトのダウンロードの優先順位を転送することができ、その後、後で要求されたユーザ規定のオブジェクトのダウンロードの優先順位を、拒絶することができる。ある代替的な例では、アプリケーションサーバ170は、後で要求されたユーザ規定のオブジェクトのダウンロードの優先順位を、AT1に転送することができ、これによってAT1は、最も新しく転送されたユーザ規定のオブジェクトのダウンロードの優先順位に従うが、それは、後で要求されたユーザ規定のオブジェクトのダウンロードの優先順位が、最初に要求されたまたは前に要求されたユーザ規定のオブジェクトのダウンロードの優先順位と比較して優先順位がより高いATから、アプリケーションサーバ170において受信された場合のみである。別の例では、AT2が複数のATの代表である場合、アプリケーションサーバ170は、それぞれのATからの、異なる要求されたユーザ規定のオブジェクトのダウンロードの優先順位の、重み付けまたは平均を実行することができる。たとえば、閾値の割合のATが、ユーザ規定のオブジェクトのダウンロードの優先順位の特定のセットを要求する場合、アプリケーションサーバ170は、ユーザ規定のオブジェクトのダウンロードの優先順位のその特定のセットのみに対して動作を実行でき、または、アプリケーションサーバ170は、複数の要求されたユーザ規定のオブジェクトのダウンロードの優先順位にわたり共通の要素を求め、その共通の要素のみに対して動作を実行できる、などである。

別の実施形態では、図9Bを参照すると、AT1は、AT2にオブジェクトを転送している複数のATの代表であってよい。この場合、ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、あるATからのオブジェクトを他のATからのオブジェクトよりも優先するように構成され得る。この場合、ある例では、915Bにおける複数のオブジェクトのための構成された要求は、AT2により待ち行列に入れられてよく、そして、ATがそれぞれのオブジェクトの転送を完了した後、高優先度から低優先度の順序で、複数のATに連続して送られ得る。あるいは、AT2は、AT2に対するATのそれぞれの優先順位を、アプリケーションサーバ170に通知してもよい。この場合、915Bにおける複数のオブジェクトのための構成された要求は、複数のATの各々に送られてよく、アプリケーションサーバ170は、次いで、ユーザ規定のオブジェクトのダウンロードの優先順位のAT2のセットに対応する順序で、オブジェクトをAT2に送達するために、複数のATから受信されたオブジェクトのバッファリングを試みることができる。

別の例では、図9Cを参照して以下で説明されるように、AT2の所与のユーザは、異なる通信セッション(たとえば、ストリーミング映像会議セッションおよびファイル転送セッションのような)と関連付けられたウィンドウを見進むことができる。どのウィンドウがアクティブであるかに応じて、アクティブウィンドウと関連付けられないセッションのメディアのすべてまたは一部は、(少なくとも所与のユーザが他のセッションのウィンドウに戻るまで)優先順位が下げられ得る。たとえば、AT2でウィンドウが重なっているために、部分的な映像しか表示されていないと仮定する。この場合、示されているウィンドウの一部のみが、映像の一部として送られ得る。AT2は、表示される映像部分を示す何らかのものを伝達することができ、アプリケーションサーバ170は、その表示される映像部分から見えない部分をフィルタリングできる。

図9Cを参照して、AT2が、第1の接続を通じて、ウィンドウの第1のセットと関連付けられるストリーミング通信セッションに参加していると仮定する(900C)。ある例では、第1の接続(または接続1)は、単一のタイプのメディアまたは複数のタイプのメディア(たとえば映像および音声)を搬送する、単一の接続に相当し得る。別の例では、第1の接続は複数の異なる接続に相当してよく、各タイプのストリーミングメディアは、そうした接続の異なる1つに割り当てられている(たとえば、音声は1xを通じて受信され、映像はEV-DOを通じて受信され、映像および音声はEV-DOネットワーク内の異なるポートで受信されるなど)。また、ストリーミング通信セッションは、AT2と、サーバ、AT1、または何らかの他のATとの間のセッションであってよく、図9Cでは、AT1はストリーミング通信セッションの一部として明示的には示されていないが、これは可能な実装形態である。

次に、AT2は、ファイル転送セッションを開始して送信AT1から第2の接続を通じて1つまたは複数のオブジェクトを転送するために、ウィンドウの第2のセットに切り替える(905C)。たとえば、ストリーミング通信セッションは、高QoSの接続(すなわち第1の接続)により支援される映像会議に相当してよく、ファイル転送セッションは、低QoSの接続により、またはさらにはQoSの程度が何ら保証されない接続により支援され得る。

AT2が、現在のアクティブウィンドウを、ストリーミング通信セッションと関連付けられたウィンドウから、ファイル転送セッションと関連付けられたウィンドウに切り替えたので、AT2は、910Cにおいて、ストリーミング通信セッションの少なくとも一部の優先順位を下げるための要求を送る。ある例では、ストリーミング通信セッションが、映像のみのセッションに相当する場合、優先順位を下げる要求は、AT2が映像を表示するウィンドウを見てもいないので、映像フィードをAT2にこれ以上送らないように要求することができる。さらなる例では、ストリーミング通信セッションが、映像および音声を含むフィードに相当する場合、優先順位を下げる要求は、(たとえば、映像がこのインスタンスにおいて見られないとしても、ユーザは依然として、他のウィンドウへユーザが見進む間に、セッションの音声部分を聞くことがあるので)音声フィードまたはストリーミング通信セッションの一部をAT1に送るように依然として要求する一方で、映像フィードをこれ以上AT1に送らないように要求することができる。この例では、第1の接続が音声および映像のために異なる接続を含む場合、優先順位を下げる要求は、映像フレームがAT2に運ばれる速度を下げることを要求し、または代替的には、映像接続を一時的に中断または停止することを要求するように、構成され得る。したがって、915Cにおいて、アプリケーションサーバ170は、910Cからの優先順位を下げる要求に従って、AT1へのストリーミング通信セッションを修正する。

920Cにおいて、AT1は、ファイル転送セッションの第2の接続を通じて1つまたは複数のオブジェクトをダウンロードすることを要求し、アプリケーションサーバ170は、ダウンロード要求をAT1に転送する(922C)。AT1は、要求されたオブジェクトのアプリケーションサーバ170への送信を開始し(924D)、アプリケーションサーバ170は、第2の接続を通じて、AT1からAT2に要求されたオブジェクトを送る(925C)。ある例では、AT2は、話題になっている図のような、ストリーミング通信セッションのセッション参加者(たとえばAT1)からAT2に電子メールで送られる写真を、ダウンロードすることができる。代替的には、ファイル転送セッションは、ストリーミング通信セッションと直接関連付けられる必要はない。

この時点において、ウィンドウの第1のセットが再びアクティブ化され、AT2が再びストリーミング通信セッションに完全に参加できるように、AT2は、ストリーミング通信セッションに再び切り替えると、仮定する(930C)。したがって、AT1は、ストリーミング通信セッションの優先順位が下げられた部分が、高い優先度を与えられるように要求するための、「再」優先順位付け要求を送る(935C)。たとえば、再優先順位付け要求は、映像会議の中止された映像フィードを再開するように、要求することができる。したがって、940Cにおいて、アプリケーションサーバ170は、935Cからの再優先順位付け要求に従って、AT1へのストリーミング通信セッションを修正する。

図9Cの実施形態では、特定のTCP接続と関連するアプリケーションサーバ170および/またはAT1に、ウィンドウの特性のセットが通知される方式を修正するために、所与のトランスポートプロトコル(たとえばTCPなど)が用いられ得る。たとえば、第1のTCP接続はウィンドウの第1のセットと関連付けられてよく、第2のTCP接続はウィンドウの第2のセットと関連付けられてよい。これにより、910Cの優先順位を下げる要求は、ウィンドウの第1のセットの優先順位が低いことを反映するように、ウィンドウの第1のセットの第1のTCP接続のために通知されるウィンドウが小さいという構成に相当してよく、935Cの再優先順位付け要求は、ウィンドウの第2のセットの優先順位が高いことを反映するように、ウィンドウの第2のセットの第2のTCP接続のために通知されるウィンドウが大きいという構成に相当してよい。ウィンドウの第1のセットおよび第2のセットは、TCP接続に各々関連しているものとして上で説明されるが、本発明の他の実施形態では、接続の少なくとも1つはTCPである必要はなく、むしろ、UDPまたは何らかの他のワイヤレストランスポートプロトコルであってよいことが、理解されよう。

図9Aから図9Cは、オブジェクトまたはメディアが、コンテンツの推測される優先順位または明示的な優先順位のいずれかに基づいてAT2に選択的に提供される例を示すが、図9Aから図9Cでは、実際にAT2に提供される任意のデータは、完全な品質のレベルで運ばれることが、全般に仮定される。図9Dを参照して以下で説明される、ある代替的な実施形態では、AT2が制限された環境に位置する場合、AT2は、再フォーマットされたオブジェクトのダウンロードが、その制限された環境に順応するようにすることができる。

本明細書で用いられる場合、「制限された環境」は、AT2のダウンロード要求の性能低下と関連付けられると考えられる、任意の条件、任意の定性的な測定値、および/または任意の定量的な測定値として定義される。たとえば、制限された環境は、AT2が、高干渉のゾーン、1xネットワークで動作しており、かつ/または、AT2が複数のセッションに同時に参加している場合のようにAT2のリソースに対する負荷が高い、帯域幅が制限された環境に相当し得る。別の例では、AT2がEV-DOネットワークに接続され、EV-DOのT2Pが所与の閾値を下回る場合、または、CapProbeもしくはCapProbeのようなプログラムを用いた帯域幅の測定結果が所定の閾値を下回る場合、AT2は制限された環境にあると考えられ得る。

図9Dを参照すると、AT2は、複数のオブジェクトをダウンロードするための、少なくとも1つの要求を受信する(900D)。上で述べられたように、複数オブジェクトのダウンロード要求は、ウェブサイトをロードするための要求、またはある例では、通信セッションの間に別のATからのファイル転送を受信するための要求に、相当し得る。別の例では、複数オブジェクトのダウンロード要求は、写真のスライドショーに相当し得る。905Dでは、ダウンロード要求に対して制限されていると見込まれる制限された環境で、AT2が現在動作しているかどうかを、AT2が判定する。

理解されるように、現在の動作環境が「制限された動作環境」(たとえば、ダウンロード要求に対して制限されている)かどうかをAT2が判定できる、いくつかの異なる方式がある。たとえば、要求されたデータ量の、普通のユーザがそのデータ量を受信するのにかかると予想する時間に対する比率が、所定の量よりも長くかかる場合、環境はダウンロード要求に対して制限され得る。この比率は、ある例では、それぞれのATまたはUEにおいて事前に構成され得る。したがって、ATが10キロバイト(KB)のファイルのダウンロードを要求された場合、1xネットワークに接続されていることは制限された環境ではないが、要求されたダウンロードが10メガバイト(MB)のファイルに対するものである場合、1xネットワークは制限された環境であり得る。同様に、ATが10メガバイト(MB)のファイルのダウンロードを要求された場合、4Gネットワークに接続されていることは制限された環境ではないが、要求されたダウンロードが10ギガバイト(GB)のファイルに対するものである場合、4Gネットワークですら制限された環境であり得る。

別の例では、AT2が1xネットワークにおいて動作している場合、AT2は単純に、環境は制限されているとすることができる。別の例では、AT2は、最近の通信セッションで得られたデータ速度を評価することができ、データ速度が比較的低い場合、または閾値よりも低い場合、AT2は環境が制限されていると判定することができる。

別の例では、903Dで示されるように、アプリケーションサーバ170(またはRAN120)は、AT2の現在の接続品質のレベルを示す接続品質インジケータを、AT2に送ることができる。たとえば、接続品質インジケータは、アプリケーションサーバ170により測定されたような、AT2の現在のサービングネットワークと関連するネットワーク遅延、混雑または損失を、示すものであってよい。理解されるように、帯域幅が広がりレイテンシが小さくなると、ユーザの体験または知覚の範囲では品質低下がなくなる点が最終的には存在するので、帯域幅および/またはレイテンシの変化を評価して、特定の動作環境が制限されているかどうかを判定することができる。さらなる例では、AT2がすでに、アプリケーションサーバ170に対して確立された接続を有する場合、接続品質インジケータは、アプリケーションサーバ170によりAT2に送られるACKパケットまたはデータパケット内で、AT2に運ばれ得る。たとえば、アプリケーションサーバ170は、AT2の現在のネットワークの接続品質に関連する特別な知識を有することがあり、AT2の現在のネットワークは、たとえばAT2の地理的な位置に一部基づき得る。そして、アプリケーションサーバ170は、コードまたはビットセッティングによって、AT2へのパケットのヘッダ部分(たとえばDSCPフィールド)を構成して、特別な知識を伝達することができる。

905Dにおいて、AT2が環境を制限された環境であると判定すると、仮定する。したがって、AT2は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数のダウンロード要求を構成し、さらに、AT2が制限された環境で動作していることを示すように、その要求を構成する(910D)。915Dにおいて、AT2は、構成された要求をアプリケーションサーバ170に送り、アプリケーションサーバ170は、構成された要求をAT1に転送する。構成された要求に応答して、AT1は、自身の接続を介して、要求されたオブジェクトのアプリケーションサーバ170への送信を開始する(920B)。AT1から複数のオブジェクトを受信すると、アプリケーションサーバ170は、変更または修正されるべき少なくとも1つのオブジェクトの送達時間を減らすために、第1の「実現形態」から第2の「実現形態」へ、複数のオブジェクトの少なくとも1つを、変更または修正する(922D)。ある例では、グラフィックオブジェクト(たとえば、JPEG、TIFF、ビットマップなど)について、922Dの修正は、グラフィックオブジェクト(たとえば、写真スライドショーの場合には複数のグラフィックオブジェクト)の解像度を下げること(たとえば、サムネイル画像に標準的な解像度にすることなど)に相当し得る。別の例では、音声オブジェクト(たとえば、wavファイル、MP3など)について、922Dの修正は、音声オブジェクトの品質を下げることに相当し得る。922Dの修正の後、任意の修正されたオブジェクトが修正されていないバージョンの代わりに送られるように、アプリケーションサーバ170は、複数のオブジェクトのAT2への送信を開始する(925D)。

930Dにおいて、何らかの後の時点で、アプリケーションサーバ170は、少なくとも1つのオブジェクトを、最初の形式または修正されていない形式でAT2に送るべきかどうかを、判定する。ある例では、アプリケーションサーバ170は、すべての他の複数のオブジェクトがAT2に送られた後、またはAT2がもう制限された環境では動作していないというメッセージ(たとえば、928Dにおける接続品質更新メッセージを介した)に応答して、または閾値の期間の後などに、「完全な」品質の最初の形式で少なくとも1つのオブジェクトを送ると、決定することができる。AT2が、少なくとも1つのオブジェクトを最初の形式で送信しないと決定した場合、処理は925Dに戻り、アプリケーションサーバ170は、(第1の実現形態でオブジェクトのすべてをAT1に送ることなく)複数のオブジェクトのAT2への送信を続ける。それ以外の場合、AT2が、少なくとも1つのオブジェクトを最初の形式でAT2に送信すると決定した場合、アプリケーションサーバ170は、920Dで修正されたオブジェクトを、元の、または修正されていない第1の実現形態でAT2に送りつつ、複数のオブジェクトのAT1への送信を続ける(935D)。

図9Dでは、ダウンロード要求900Dが、リアルタイムメディアまたはストリーミングメディアに相当することが可能である。この場合、たとえば低解像度の映像がユーザに送られるのであれば、ユーザがより高性能なネットワークに再接続した場合、または他の方法で接続が改善した場合に、高解像度の映像を送ることにはほとんど価値がないことが、理解されよう。この場合、本発明のある実施形態では、ブロック930Dおよび935Dは、ストリーミングセッションまたはリアルタイムセッションに対しては省略される可能性があってよく、このとき、「古い」ファイルがより低い品質で送られたとしても、「古い」ファイルはより新しいファイルよりも価値が低い。

図9Aから図9Dは、上では別々の処理として説明されたが、本発明の他の実施形態では、図9Aから図9Dの2つ以上は、協調的に実施され得ることが理解されよう。たとえば、図9A、図9Bおよび/または図9Cの、優先順位付けに注目する実施形態は、図9Dの制限された環境に注目する実施形態と連携して、実施され得る。この場合、922Dにおいて複数のオブジェクトの実現形態を修正することに加えて、かつ/またはその代わりに、AT2の制限された環境への移行により、図9A、図9Bおよび/または図9Cのオブジェクト転送の優先順位が、修正されるようになり得る。別の例では、図9A、図9Bおよび/または図9Cは単に、図9Dと並行して実行されてもよいが、図9Dにより実際には直接の影響を受けなくてもよい。たとえば、図9DでA1からAT2に転送されるものとして説明される複数のオブジェクトは、図9A、図9Bおよび/または図9Cのそれぞれのオブジェクトの転送の優先順位に基づいた順序で、提供され得る。

さらに、図9Aから図9Dの各々は、オブジェクトがAT1からAT2に転送される実施形態を対象とするが、AT1および/またはAT2のいずれかが、複数のATの代表であってもよいことが理解されよう。言い換えると、図9Aから図9DでAT2に到達するオブジェクトは、代替的には、単一のAT1ではなく複数のATから発信されてよい。また、図9Aから図9DでAT1から送られるオブジェクトは、代替的には、単一のAT2ではなく複数のターゲットATに送られてよい。

AT2が、AT1からオブジェクトを受信している複数のATの1つである場合、図9Aから図9Cに関して、AT1からオブジェクトを受信している各ATは、固有のそれぞれのオブジェクト転送の優先順位と関連付けられてよいことが、理解されよう。したがって、図9Aから図9Cの処理は、各々のそれぞれの受信ATに対して実行されてよく、AT2からのオブジェクトが、それぞれの受信ATに異なる順序で送達されるようになる可能性がある。図9Dに関して、制限された環境へ受信ATの1つが入っても、制限された環境にはない他の受信ATへのオブジェクトの転送は制限されなくてもよいことが、理解されよう。したがって、図9Dの実行は、受信ATのすべてには影響を与えなくてもよい。

さらに、図9Aから図9Dのいずれかにおいて、転送されているオブジェクトの1つまたは複数はある満了時間と関連付けられてよく、その満了時間の後、1つまたは複数のオブジェクトと関連付けられる値は下げられ、かつ/または完全に削除される。したがって、オブジェクトの転送の間、所与のエンティティが、1つまたは複数のオブジェクトの関連する満了時間に対する現在の時間を確認し、1つまたは複数のオブジェクトの優先順位を動的に下げ、かつ/または、1つまたは複数のオブジェクトを完全に脱落させるかどうかを、判定することができる。ある例では、この動作は、AT1において、図9Aの924A、図9Bの920B、図9Cの924C、および/または図9Dの920Dの間に、行われ得る。あるいは、この動作は、アプリケーションサーバ170において、図9Aの925A、図9Bの925B、図9Cの925C、および/または図9Dの925Dの間に、行われ得る。

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

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

本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(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)は、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるものとする。

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

100 ワイヤレス通信
102 アクセス端末
104 エアインターフェース
120 無線アクセスネットワーク
122 基地局コントローラ/パケット制御機能
124 基地局またはモデムプールトランシーバ
126 キャリアネットワーク
160 パケットデータサービングノード
162 パケットデータネットワークエンドポイント
165 ブロードキャストサービングノード
170 アプリケーションサーバ
170A 地域ディスパッチャ
170B メディア制御コンプレックス
175 インターネット
184 プロビジョニングサーバ
186 インターネットプロトコルマルチメディアサブシステム/セッション開始プロトコル登録サーバ
200 アクセス端末
202 プラットフォーム
206 トランシーバ
208 ASIC
210 アプリケーションプログラミングインターフェース
212 メモリ
214 ローカルデータベース

Claims (6)

1. 通信システムにおいてファイル転送セッションをセットアップするように構成されるアクセス端末を動作させる方法であって、
   前記ファイル転送セッションの間に用いられることになる、トラフィックチャネル(TCH)のためのサービングアクセスネットワークを用いたセットアップ手順を開始するステップと、
   前記ファイル転送セッションと関連付けられたアプリケーション層接続およびトランスポート層接続をセットアップするために、アプリケーション層データおよびトランスポート層データによってメッセージを構成するステップと、
   前記TCHセットアップ手順が完了する前に、前記TCHセットアップ手順とは別に、前記構成されたメッセージを、シグナリングポートを介してアプリケーションサーバに送信するステップと、
   前記構成されたメッセージが送信された後、前記TCHセットアップ手順を完了するステップと、
   前記構成されたメッセージの前記送信に応答して、前記アプリケーションサーバからの応答メッセージを、データポートを通じて受信するステップであって、前記データポートが、前記シグナリングポートを介してアプリケーションサーバに送信される前記構成されたメッセージに含まれる前記トランスポート層データに基づいて選択される、ステップと、
   前記ファイル転送セッションの間に、前記TCHを介し前記データポートを通じて、1つまたは複数のファイルを前記アプリケーションサーバに送信するステップとを含む、方法。
2. 前記構成されたメッセージがData-over-Signaling(DoS)メッセージに相当し、前記シグナリングポートがDoSポートに相当する、請求項1に記載の方法。
3. 前記ファイル転送セッションが確立している間に前記アクセス端末によって使用される前記データポートが、前記送信するステップが前記シグナリングポートを介して前記アプリケーションサーバに前記構成されたメッセージを送信した後に選択される、請求項1に記載の方法。
4. 請求項1ないし3のいずれか一項による方法を実行するための手段を含む、通信装置。
5. 請求項1ないし3のいずれか一項による方法をコンピュータに実行させるための、少なくとも1つの命令を記録する、コンピュータ可読記録媒体。
6. 前記構成されたメッセージは、3ウェイハンドシェイクのSYNメッセージであり、
   前記応答メッセージは、前記3ウェイハンドシェイクのSYN-ACKメッセージであり、
   前記1つまたは複数のファイルは、前記3ウェイハンドシェイクのACKメッセージである、請求項1に記載の方法。

Images