JP5872708B2 - バンドリング係数デジッタバッファサイズの調整 - Google Patents

Description

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により明示的に本明細書に組み込まれる、2011年11月15日に出願された「ADJUSTING A BUNDLING FACTOR FOR A COMMUNICATION SESSION BASED ON WHETHER A TARGET ACCESS NETWORK SUPPORTS HEADER COMPRESSION」という名称の仮出願第61/560,002号の優先権を主張する。

本発明の実施形態は、ターゲットアクセスネットワークがヘッダ圧縮をサポートするかどうかに基づいて、通信セッションのバンドリング係数を調整することに関する。

ワイヤレス通信システムは、第1世代アナログワイヤレス電話サービス(1G)、第2世代(2G)デジタルワイヤレス電話サービス(暫定の2.5Gおよび2.75Gネットワークを含む)、ならびに第3世代(3G)高速データ/インターネット対応ワイヤレスサービスを含む、様々な世代を通じて発展してきた。現在、セルラーシステムおよびパーソナル通信サービス(PCS)システムを含む、多くの様々なタイプのワイヤレス通信システムが使用されている。知られているセルラーシステムの例には、セルラーAnalog Advanced Mobile Phone System(AMPS)、および、符号分割多元接続(CDMA)、Long Term Evolution(LTE)、周波数分割多元接続(FDMA)、時分割多元接続(TDMA)、TDMAのGlobal System for Mobile access(GSM（登録商標）)変形に基づくデジタルセルラーシステム、および、TDMA技術とCDMA技術の両方を使用するより新しいハイブリッドデジタル通信システムがある。

ある実施形態では、ユーザ機器(UE)は、通信セッションを始めることを決定し、UEはさらに、UEにサービスするアクセスネットワークがヘッダ圧縮をサポートするかどうかを判定する。ヘッダ圧縮の判定に基づいて、UEは、所与のバンドリング係数(BF)を確立する。UEは、通信セッションの間にメディアパケットの第1のセットをサーバに送信し、メディアパケットの第1のセットは各々、所与のBFに基づく第1の数のメディアフレームを含む。サーバは、ターゲットUEに対する目標のBFを決定し、目標のBFに基づいて所与のBFを修正するかどうか判定する。これらの判定に基づいて、サーバは、データパケットの第1のストリームから修正されない、または目標のBFに基づいて修正された、メディアパケットの第2のセットを送信する。ターゲットUEは、データパケットの第2のストリームを受信し、関連するBFに基づいてデジッタバッファサイズを設定する。

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

本発明の少なくとも1つの実施形態によるユーザ機器(UE)を示す図である。 機能を実行するように構成された論理部を含む通信デバイスを示す図である。 本発明のある実施形態による、発信側UEと少なくとも1つのターゲットUEとの間で通信セッションをセットアップするプロセスを示す図である。 本発明のある実施形態による、図3のプロセスの続きを示す図である。 本発明のある実施形態による、第1の無線アクセスネットワークによってサービスされる発信側UEと、第2の無線アクセスネットワークによってサービスされるターゲットUEの第1のセットと、第3の無線アクセスネットワークによってサービスされるターゲットUEの第2のセットとの間で通信セッションをセットアップするプロセスを示す図である。 本発明のある実施形態による、図5のプロセスの続きを示す図である。 本発明のある実施形態による、同じ無線アクセスネットワークによってサービスされ異なるレベルの性能を伴う、発信側UEとターゲットUEの第1のセットと第2のセットとの間で通信セッションをセットアップするプロセスを示す図である。 本発明のある実施形態による、図7のプロセスの続きを示す図である。

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

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

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

本明細書ではユーザ機器(UE)と呼ばれるHigh Data Rate(HDR)加入者局は、移動式でも固定式でもよく、Node Bと呼ばれ得る1つまたは複数のアクセスポイント(AP)と通信することができる。UEは、Node Bのうちの1つまたは複数を介して、無線ネットワークコントローラ(RNC)との間でデータパケットを送受信する。Node BおよびRNCは、無線アクセスネットワーク(RAN)と呼ばれるネットワークの部分である。無線アクセスネットワークは、複数のアクセス端末間で音声パケットおよびデータパケットを運ぶことができる。

無線アクセスネットワークは、無線アクセスネットワークの外部の追加のネットワークにさらに接続されていてもよく、そのようなコアネットワークは、特定のキャリア関連のサーバおよびデバイス、ならびに企業内イントラネット、インターネット、公衆交換電話網(PSTN)、Serving General Packet Radio Service(GPRS) Support Node(SGSN)、Gateway GPRS Support Node(GGSN)のような他のネットワークへの接続を含んでおり、各UEとそのようなネットワークとの間で音声パケットおよびデータパケットを運ぶことができる。1つまたは複数のNode Bとのアクティブなトラフィックチャネル接続を確立したUEは、アクティブなUEと呼ばれることがあり、トラフィック状態であると呼ばれることがある。1つまたは複数のNode Bとのアクティブなトラフィックチャネル(TCH)接続を確立する過程にあるUEは、接続セットアップ状態であると呼ばれることがある。UEは、ワイヤレスチャネルまたは有線チャネルを介して通信する任意のデータデバイスであり得る。UEは、さらに、限定はされないが、PCカード、コンパクトフラッシュ（登録商標）デバイス、外付けまたは内蔵のモデム、またはワイヤレスもしくは有線の電話を含むいくつかのタイプのデバイスのうちのいずれかであり得る。UEが信号をNode Bに送る通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、制御チャネル、アクセスチャネルなど)と呼ばれる。Node Bが信号をUEに送る通信リンクは、ダウンリンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書で使用される場合、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向トラフィックチャネル、またはダウンリンク/順方向トラフィックチャネルのいずれかを指し得る。

図1は、本発明のある実施形態によるUEを示す。図1を参照すると、セルラー電話のようなUE200(ここではワイヤレスデバイス)は、プラットフォーム202を有し、プラットフォーム202は、所与の無線アクセス技術(たとえば、long term evolution(LTE)、EV-DO、広帯域符号分割多元接続(W-CDMA)など)と関連付けられるアクセスネットワークから送信され、最終的にはコアネットワーク、インターネット、ならびに/または他のリモートサーバもしくはネットワークから来る可能性がある、ソフトウェアアプリケーション、データ、および/またはコマンドを受信し実行することができる。プラットフォーム202は、特定用途向け集積回路(ASIC)208または他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合された送受信機206を含み得る。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212中の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース(API)210層を実行する。メモリ212は、読取り専用メモリまたはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成され得る。プラットフォーム202は、メモリ212中でアクティブに使用されないアプリケーションを保持することができるローカルデータベース214も含み得る。ローカルデータベース214は、一般にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなどのような、当技術分野で知られている任意の二次記憶デバイスであってもよい。内部プラットフォーム202のコンポーネントはまた、当技術分野で知られていているように、コンポーネントのうちでもとりわけ、アンテナ222、ディスプレイ224、プッシュツートークボタン228およびキーパッド226のような外部デバイスに動作可能に結合され得る。

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

UE200とサービングアクセスネットワークとの間のワイヤレス通信は、たとえばLTE、CDMA、W-CDMA、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元(OFDM)、Global System for Mobile Communications(GSM（登録商標）)、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用され得る他のプロトコルのような、様々な無線アクセス技術に基づき得る。たとえば、W-CDMAでは、データ通信は通常、UE200と、1つまたは複数のNode Bと、無線ネットワークコントローラ(RNC)との間の通信である。RNCは、コアネットワーク、PSTN、インターネット、仮想専用ネットワーク、SGSN、GGSNなどのような複数のデータネットワークに接続され得るので、UE200はより広範な通信ネットワークにアクセスすることが可能になる。上で論じられ、当技術分野で知られているように、音声送信、および/またはデータは、種々のネットワークおよび構成を使用してRANからUEに送信され得る。したがって、本明細書で提供される例は、本発明の実施形態を限定するためのものではなく、単に本発明の実施形態の態様の説明を助けるためのものにすぎない。

図2は、機能を実行するように構成された論理部を含む通信デバイス400を示す。通信デバイス400は、限定はされないが、UE200またはネットワーク要素(たとえば、サーバ、基地局またはNode B、パケットデータネットワークエンドポイント(たとえば、SGSN、GGSN、Long Term Evolution(LTE)におけるモビリティ管理エンティティ(MME)など)など)を含む、上で述べられた通信デバイスのいずれかに対応し得る。したがって、通信デバイス400は、ネットワークを介して1つまたは複数の他のエンティティと通信する(または通信を容易にする)ように構成された任意の電子デバイスに対応し得る。

図2を参照すると、通信デバイス400は、情報を受信および/または送信するように構成された論理部405を含む。ある例では、通信デバイス400がワイヤレス通信デバイス(たとえば、UE200、Node Bまたは基地局など)に対応する場合、情報を受信および/または送信するように構成された論理部405は、ワイヤレス送受信機および関連ハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)のようなワイヤレス通信インターフェース(たとえば、Bluetooth（登録商標）、WiFi、2G、3G、LTEなど)を含み得る。別の例では、情報を受信および/または送信するように構成された論理部405は、有線通信インターフェース(たとえば、シリアル接続、USBまたはファイアワイヤ接続、それを通じてインターネットにアクセスできるイーサネット（登録商標）接続など)に対応し得る。したがって、通信デバイス400が、何らかのタイプのネットワークベースのサーバ(たとえば、SGSN、GGSN、アプリケーションサーバ170など)に対応する場合、情報を受信および/または送信するように構成された論理部405は、ある例では、イーサネット（登録商標）プロトコルによってネットワークベースのサーバを他の通信エンティティに接続するイーサネット（登録商標）カードに対応し得る。さらなる例では、情報を受信および/または送信するように構成された論理部405は、通信デバイス400がその局所環境を監視する手段となり得る感知または測定ハードウェア(たとえば、加速度計、温度センサ、光センサ、局所RF信号を監視するためのアンテナなど)を含み得る。情報を受信および/または送信するように構成された論理部405は、実行されると、情報を受信および/または送信するように構成された論理部405の関連ハードウェアがその受信および/または送信機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、情報を受信および/または送信するように構成された論理部405は、ソフトウェア単体に対応するのではなく、情報を受信および/または送信するように構成された論理部405は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図2を参照すると、通信デバイス400は、情報を処理するように構成された論理部410をさらに含む。ある例では、情報を処理するように構成された論理部410は、少なくともプロセッサを含み得る。情報を処理するように構成された論理部410によって実行され得るタイプの処理の例示的な実装形態は、限定はされないが、判定の実行、接続の確立、異なる情報の選択肢からの選択、データに関連した評価の実行、測定動作を実行するための通信デバイス400に結合されたセンサとの対話、ある形式から別の形式への(たとえば、.wmvから.aviなどのような、異なるプロトコル間の)情報の変換などを含む。たとえば、情報を処理するように構成された論理部410に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェアコンポーネント、あるいは本明細書で説明する機能を実行するように設計されたそれらの任意の組合せに相当し得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。情報を処理するように構成された論理部410は、実行されると、情報を処理するように構成された論理部410の関連ハードウェアがその処理機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、情報を処理するように構成された論理部410は、ソフトウェア単体に対応するのではなく、情報を処理するように構成された論理部410は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図2を参照すると、通信デバイス400は、情報を記憶するように構成された論理部415をさらに含む。ある例では、情報を記憶するように構成された論理部415は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含み得る。たとえば、情報を記憶するように構成された論理部415に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体に相当し得る。情報を記憶するように構成された論理部415はまた、実行されると、情報を記憶するように構成された論理部415の関連ハードウェアがその記憶機能を実行することを可能にする、ソフトウェアを含み得る。しかしながら、情報を記憶するように構成された論理部415は、ソフトウェア単体に対応するのではなく、情報を記憶するように構成された論理部415は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図2を参照すると、通信デバイス400はさらに、情報を提示するように構成された論理部420を任意選択で含む。ある例では、情報を表示するように構成された論理部420は、少なくとも出力デバイスおよび関連ハードウェアを含み得る。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMI（登録商標）のようなビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカー、マイクロホンジャック、USB、HDMI（登録商標）のようなオーディオ情報を搬送することができるポートなど)、振動デバイス、および/または、情報が出力のためにフォーマットされる際、または通信デバイス400のユーザもしくは操作者によって実際に出力される際の手段となり得る任意の他のデバイスを含み得る。たとえば、通信デバイス400が、図1に示されるようなUE200に対応する場合、情報を提示するように構成された論理部420は、ディスプレイ224を含み得る。さらに別の例では、情報を提示するように構成された論理部420は、ローカルユーザをもたないネットワーク通信デバイス(たとえば、ネットワークスイッチやルータ、リモートサーバなど)のような、いくつかの通信デバイスに対しては省略されてよい。情報を提示するように構成された論理部420は、実行されると、情報を提示するように構成された論理部420の関連ハードウェアがその提示機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、情報を提示するように構成された論理部420は、ソフトウェア単体に対応するのではなく、情報を提示するように構成された論理部420は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図2を参照すると、通信デバイス400はさらに、ローカルユーザ入力を受け取るように構成された論理部425を任意選択で含む。ある例では、ローカルユーザ入力を受け取るように構成された論理部425は、少なくともユーザ入力デバイスおよび関連ハードウェアを含み得る。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロホンジャックのようなオーディオ情報を搬送することができるマイクロホンもしくはポートなど)、および/または、通信デバイス400のユーザまたは操作者から情報を受け取る際の手段となり得る任意の他のデバイスを含み得る。たとえば、通信デバイス400が、図1に示されるようなUE200に対応する場合、ローカルユーザ入力を受け取るように構成された論理部425は、ディスプレイ224(タッチスクリーンを実装した場合)、キーパッド226などを含み得る。さらに別の例では、ローカルユーザ入力を受け取るように構成された論理部425は、ローカルユーザをもたないネットワーク通信デバイス(たとえば、ネットワークスイッチやルータ、リモートサーバなど)のような、いくつかの通信デバイスに対しては省略されてよい。ローカルユーザ入力を受け取るように構成された論理部425は、実行されると、ローカルユーザ入力を受け取るように構成された論理部425の関連ハードウェアがその入力受取機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、ローカルユーザ入力を受け取るように構成された論理部425は、ソフトウェア単体に対応するのではなく、ローカルユーザ入力を受け取るように構成された論理部425は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図2を参照すると、405〜425の構成された論理部は、図2では別個のまたは相異なるブロックとして示されているが、それぞれの構成された論理部がその機能を実行するためのハードウェアおよび/またはソフトウェアは、部分的に重複し得ることが諒解されよう。たとえば、405〜425の構成された論理部の機能を支援するために使用されるいずれのソフトウェアも、情報を記憶するように構成された論理部415に関連付けられた非一時的メモリに記憶され得るので、405〜425の構成された論理部は各々、それらの機能(すなわち、この場合、ソフトウェア実行)を、情報を記憶するように構成された論理部415によって記憶されたソフトウェアの動作に部分的に基づいて実行する。同様に、構成された論理部のうちの1つと直接関連付けられたハードウェアは、時々、他の構成された論理部によって借用または使用され得る。たとえば、情報を処理するように構成された論理部410のプロセッサは、データを、情報を受信および/または送信するように構成された論理部405によって送信される前に、適切な形式にフォーマットすることができるので、情報を受信および/または送信するように構成された論理部405は、その機能(すなわち、この場合、データの送信)を、情報を処理するように構成された論理部410と関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実行する。さらに、405〜425の構成された論理部または「ように構成された論理部」は、特定の論理ゲートまたは論理要素に限定されず、全般に、本明細書で説明された機能を、(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実行するための能力を指す。したがって、405〜425の構成された論理部または「ように構成された論理部」は、「論理部」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるとは限らない。構成された論理部405〜425の間の他の対話または協働が、以下でより詳しく説明される実施形態の検討から、当業者には明らかになるであろう。

ロバストヘッダ圧縮(RoHC)は、インターネットプロトコル(IP)パケット、ユーザデータグラムプロトコル(UDP)パケット、リアルタイムトランスポートプロトコル(RTP)パケット、伝送制御プロトコル(TCP)パケットなどのような、インターネットパケットのヘッダの圧縮に対応する。高水準では、RoHCは、圧縮されたパケットを通信リンクを通じて送信するとき、パケットヘッダの比較的長い部分をはるかに短いコンプレッサ(たとえば、数バイトの長さ)と置き換えることによって機能する。通信リンクの受信端は、圧縮されたパケットを受信し、デコンプレッサ(たとえば、事前に確立されたマッピングまたはインデックステーブル)を介して元のパケットヘッダを再生成する。したがって、適切な解凍を確実にするために特定の通信リンクを通じた何らかのセットアップを伴うが、RoHCがサポートされれば、通信リンクを通じて送られる必要のあるオーバーヘッドデータはより少なくなる。

UEは、W-CDMA、LTEなどのような、上で述べられたような様々な無線アクセス技術によってサポートされるサービングネットワークに接続し得る。Evolution-Data Optimized(EV-DO)ネットワークおよび/またはW-CDMAネットワークのようないくつかの無線アクセス技術は、商用的にRoHCをサポートしない。これは、理論的にはRoHCのサポートはEV-DOネットワークまたはW-CDMAネットワークにおいて使用され得るが、商用上の実装では通常そのようなサポートを実際には含まないということを意味する。したがって、フルサイズのヘッダを伴うRTP、UDP、TCP、および/またはIPパケットは、通常のEV-DOネットワークおよび/またはW-CDMAネットワークを通じてルーティングされる。諒解されるように、これは、オーバーヘッドデータのために使用されるデータトラフィックの割合を増加させる。このオーバーヘッドの問題は、パケットバンドリングを通じていくらか軽減され、このパケットバンドリングによって、たとえば複数の音声フレームが、単一のヘッダを有する単一のパケットへとバンドリングされるので、N個の音声フレームにN個未満のヘッダしか割り振られなくてもよい。しかしながら、パケットをバンドリングすることは、ジッタを増やし(たとえば、各フレームがバンドリングによりさらに離れて受信されるので)、メディアの損失率を上げ(たとえば、単一のパケット損失が複数のフレームの損失をもたらすので)、音の発生から音が聞こえるまでの遅延を増やす(たとえば、送信のための複数の音声フレームをバンドリングするまで送信側UEが複数の音声フレームを収集するのを待機するので)ことによって、呼の条件を悪化させ得る。

LTEのような他の無線アクセス技術に従って動作するネットワークは、商用的にRoHCをサポートする。たとえば、LTEでは、バンドリングと関連付けられる性能低下の問題を避けつつ、それでもRoHCのサポートによる比較的高いリンクの効率を達成するために、バンドリングを伴わないRoHCが通常は使用される。

通常のボイスオーバーIP(VoIP)セッションでは、メディアパケットは従来、直接的なサーバの調停を伴わずにピアツーピアで転送される。プッシュツートーク(PTT)セッションまたはプッシュツートランスファー(PTX)セッションのような他のタイプの通信セッションでは、通信セッションのためのメディアはサーバを通じて仲介されるが、サーバは通常、メディアのフローのためのアプリケーション層ルータとしてのみ動作する。

したがって、異なる無線アクセス技術(たとえば、DO/W-CDMAおよびLTEなど)と関連付けられる無線ネットワークに接続されたUEの間の通信セッションが、各々のそれぞれの無線アクセス技術に適切なバンドリング係数(BF)を達成することは難しい。たとえば、LTEネットワークに接続された第1のUEは、LTEネットワークがRoHCをサポートしていることを理由に1というBFを設定する(たとえば、パケット当たり1個の音声フレームをバンドリングする)ことを望み得るが、一方、DO/W-CDMAネットワークに接続された第2のUEは、DO/W-CDMAネットワークがRoHCのサポートを欠いていることを理由に6というBFを設定する(たとえば、パケット当たり6個の音声フレームをバンドリングする)ことを望み得る。この例では、ある無線ネットワークに対して望まれる各BF値は、他の無線ネットワークでは不適切である。

図3は、本発明のある実施形態による、発信側UE(すなわち、UE1)と少なくとも1つのターゲットUE(すなわち、UE2...N)との間で通信セッションをセットアップするプロセスを示す。図3を参照すると、発信側UEすなわちUE1は、UE2...Nとの通信セッションを確立することを決定し(600)、ここで1対1の通信セッションまたは直接の通信セッションではN=2であり、グループ通信セッションではN>2である。UE1は、第1の無線アクセス技術に従って動作する現在のサービングネットワーク(「RAT1」)に対して呼の要求を送信し、RAT1は、通信セッションを調停するように構成されるアプリケーションサーバ170にその呼の要求を転送する(605)。アプリケーションサーバ170は、通信セッションのターゲットUE(すなわち、UE2...N)を特定し、第2の無線アクセス技術に従って動作するネットワーク(「RAT2」)を通じて、通信セッションをターゲットUE2...Nに告知する(610)。

図3を参照すると、RAT1およびRAT2は、それぞれのUE1およびUE2...Nの現在のサービングネットワークを示すために使用される。たとえば、RAT1は、RoHCのサポートを伴わないDO/W-CDMAネットワークに対応してよく、RAT2は、RoHCのサポートを伴うLTEネットワークに対応してよい。あるいは、RAT1およびRAT2はともに、同じ無線アクセス技術(たとえば、DO/W-CDMA、LTEなど)と関連付けられてよい。上で述べられたように、RAT1およびRAT2が異なる無線アクセス技術を実装する場合、RAT1およびRAT2は、ヘッダ圧縮をサポートしていることまたはサポートしていないことに対応するために、それぞれのネットワークを通じてデータトラフィックを交換するための異なる好適なBF値または目標のBF値を有し得る。また、以下でより詳しく論じられるように、RAT1およびRAT2が同じ無線アクセス技術を使用する場合でも、他の要因が、ある特定のネットワークに対する好適なBF値または目標のBF値に影響を与え得る。言い換えると、無線アクセス技術自体は、ネットワークに対する目標のBF値を決定付ける必要はない。

図3を参照すると、UE2...Nは、RAT2に対するBF関連の情報を決定する(615)。ある例では、615の決定は、RAT2の無線アクセス技術(たとえば、LTE、EV-DO、W-CDMAなど)を単に特定することに対応し得る。この場合、615の決定は、BF値を計算するのに十分な情報が決定される(たとえば、以下でより詳しく論じられるように、アプリケーションサーバ170が630において目標のBF値を計算できるように)という点で、UE1における635の判定(以下でより詳しく論じられる)と同様である。別の例では、615の決定は、BF=1、BF=6などのような、RAT2に対してある特定の目標のBF値を決定することを含み得る。この場合、615の決定は、実際のBF値がUEにおいて計算される(たとえば、630が、以下でより詳しく論じられる、ターゲットUEから報告されたBF値の単なる認識に対応し得るように、アプリケーションサーバ170において計算される代わりに)という点で、UE1における635と640の両方の判定(以下でより詳しく論じられる)と同様である。いずれの場合でも、615において決定されるBF関連の情報は、RAT2内のUE2...Nに送達されるパケットに対する目標のBF値をアプリケーションサーバ170が決定するのに十分である。

UE2...Nは、セッション告知メッセージと、615において決定されたBF関連の情報とを受け入れることを、アプリケーションサーバ170に示す(620)。ある例では、BF関連の情報は、UE2...Nによる通信セッションの受け入れを示す、UE2...Nからの告知肯定応答メッセージ内に含まれ得る。あるいは、BF関連の情報は、告知肯定応答メッセージとは無関係な登録メッセージ(たとえば、図3のプロセスが開始する前でも送信され得る)を介して、アプリケーションサーバ170に伝えられ得る。したがって、呼の受け入れとBF関連の情報とを示すものは、620において同じメッセージに含まれていても含まれていなくてもよい。

さらなる例では、BF関連の情報は、呼の受け入れとともに伝えられる必要はない。たとえば、BF関連の情報が図3の620において送信された後、UE2...Nの1つまたは複数は、通信セッション中のより後の時点で、RAT2(またはRAT2の一部分)に対する補足的なBF関連の情報を送信することができ、このことは、アプリケーションサーバ170に、RAT2BFを更新すること(または、補足的なBF関連の情報を報告するUEのすべてに対して異なる目標のBFを生成すること)を促し得る。たとえば、補足的なBF関連の情報は、UEに対する新たな要求された目標のBFをアプリケーションサーバ170に通知することができ、補足的なBF関連の情報は、異なるRAT、もしくは、異なるレベルの性能(たとえば、異なるレベルのRoHCのサポート)と関連付けられる同じRATネットワークの異なる部分へと、UEが移行もしくはハンドオフしたこと、または、報告するUEのためにRAT2BFを調整するようにアプリケーションサーバ170に促し得る任意の他のタイプの情報を、アプリケーションサーバ170に通知することができる。

図3を参照すると、UE2...Nの少なくとも1つから呼の受け入れを示すものを受信した後、アプリケーションサーバ170は、通信セッションが開始できることをUE1に通知する(625)。たとえば、半二重通信セッションの場合、625の通知はフロア付与メッセージに対応し得る。アプリケーションサーバ170はまた、RAT2と関連付けられるBF関連の情報を評価して、UE2...NのためにRAT2内のUE2...Nに送達されるパケットに対する目標のBF(「RAT2BF」)を決定する(630)。たとえば、RAT2がLTEネットワークであることをBF関連の情報が示す場合、RAT2BF=1である。別の例では、RAT2がDO/W-CDMAネットワークであることをBF関連の情報が示す場合、RAT2BF=6である。別の例では、RAT2がRoHCを実装することが不可能なLTEローミングネットワークであることをBF関連の情報が示す場合、RAT2BFは、3のような中間的な値に設定され得る。したがって、RAT2の無線アクセス技術は、RAT2BFに影響を与え得るが、必ずしもそれを決定するものではなく、同じ無線技術のターゲットUEに対して、または同じネットワーク中のターゲットUEに対しても、異なるBFが実装され得る(たとえば、以下の図7〜図8参照)。

さらなる例では、図3の630を参照すると、RAT2BFは、UE2...Nの各々に対して特別に最適化されるとは限らない。たとえば、N=12であり、最小の可能なBFが5であることをUE2...6に対するBF関連の情報が示し、最小の可能なBFが6であることをUE7...11に対するBF関連の情報が示し、最小の可能なBFが4であることをUE12に対するBF関連の情報が示すと仮定する。各ターゲットUEの最小の可能なBFに固有の目標のBFを確立する代わりに、アプリケーションサーバ170は、最小の可能なBFが異なる少なくともいくつかのUEを共通のBFとともにグループ化することができ、共通のBFは各々のグループ化されたUEに適合する。たとえば、最小の可能なBFが5である第1のUEは6というBFに対応できるが、最小の可能なBFが6である第2のUEは5というBFに対応できないので、第1のUEおよび第2のUEは6に等しい共通のBFを得ることができる。こうして、アプリケーションサーバ170がリソース(またはオーバーヘッド)の節約を望む場合、アプリケーションサーバ170は、ターゲットUEの何らかのグルーピングに対して共通のBFを実装することができ、これによって、グループ化されるべきUEの最小の可能なBFのうちで最大のBFが、グループ化されるUEに対する共通のBFとして選択される。

図3を参照すると、UE1は、625からの呼の開始の通知を受信し、RoHCがRAT1によってサポートされるかどうかを判定する(635)。RoHCがRAT1によってサポートされるかどうかに基づいて、UE1は、625からのRoHCのサポートの判定に基づいて、BFを第1の値に設定する。たとえば、UE1は、635において、RAT1がLTEネットワークに対応するのでRoHCがサポートされると判定することがあり、640において、第1のBF値を1に設定することができる。別の例では、UE1は、635において、RAT1がDO/W-CDMAネットワークに対応するのでRoHCがサポートされないと判定することがあり、640において、第1のBF値を6に設定することができる。別の例では、UE1は、RAT1がLTEネットワークに対応すると判定することがあるが、RAT1がRoHCをサポートしないローミングネットワークであるとさらに判定することがあり、640において、第1のBF値を3という中間的な値に設定することができる。従来は、UE1は、BF値を算定するためにRAT1を評価せず、代わりに、現在のサービングネットワークのRoHCのサポート能力とは無関係に、一定のデフォルトのBF値を単に課すだけである。

645において、UE1は、640からの第1のBF値に従って、メディアのバッファリングと、パケットへのフレームのバンドリングとを開始する。UE1は、第1のBF値に従ってバンドリングされたフレームとともに、RAT1を通じて、パケットをアプリケーションサーバ170に定期的に送信する(650)。アプリケーションサーバ170は、メディアパケットを受信し、受信されたメディアパケットの関連するBF値を決定し、次いで、RAT2BFに基づくある数と、決定されたBF値(すなわち、640においてUE1によって設定された第1のBF値)を比較する(655)。ある実施形態では、アプリケーションサーバ170がUE1からの着信メディアパケットの決定されたBF値を比較する対象の数は、(i)RAT2BF自体または(ii)RAT2BFのオフセットされたバージョンのいずれかに対応してよく、(ii)の場合、RAT2BFは「A」と示される調整係数によって乗算される。ある例では、調整係数Aは、0≦A≦1という式を満たし、再バンドリングの遅延とパッキングの効率とのトレードオフに基づいて設定され得る。したがって、第1のBF値がRAT2BFよりもわずかに小さいだけである場合、アプリケーションサーバ170におけるパケットの再バンドリングと関連付けられるオーバーヘッドにより、アプリケーションサーバ170は、調整係数AがRAT2BFを小さくするように機能することに基づいて、再バンドリングを回避し得る。

図3の実施形態では、655において、第1のBF値がRAT2BFおよび/またはRAT2BF*Aより大きいとアプリケーションサーバ170が判定すると仮定する。この場合、アプリケーションサーバ170は、何ら特別な再バンドリング手順を伴わずに、UE1からUE2...Nへと受信されたメディアパケットを単に転送する(660)。したがって、660においてアプリケーションサーバ170によって送信されたメディアパケットは、650においてアプリケーションサーバ170へUE1によって送信されたメディアパケットと同じBF値、すなわち、640において設定された第1のBF値を有する。660において第1のBF値に従ってメディアパケットを受信すると、ターゲットUE2...Nは、第1のBF値に基づいて、デジッタバッファサイズを設定する(665)。一般に、より大きなBF値に対して、より大きなデジッタバッファサイズが確立される。

UE1に戻ると、UE1は、通信セッションの間のある期間、第1のBF値に従ってフレームを含むメディアパケットを送信し続ける。通信セッションの間、定期的に、またはイベント駆動の方式で、UE1は、現在のBF値を変更するかどうか判定する(670)。たとえば、670の判定は、UE1が異なるネットワークにハンドオフするたびに起こり得る。この場合、UE1は、ハンドオフ後の新しいネットワークが、古いネットワークと同じ無線アクセス技術と関連付けられるかどうかを確認し、関連付けられない場合、現在のBF値を変更すると判定する。いずれの場合でも、670においてUE1がBF値を変更しないと判定すると、プロセスは645に戻り、UE1は、通信セッションの間、第1のBF値に従ってメディアパケット内にフレームをバンドリングし続ける。そうではなく、670においてUE1がBF値を変更すると判定すると、プロセスは図4の700に進む。図4の715に関してより詳しく以下で論じられるように、1つまたは複数のUE2...Nはまた、異なるRATにハンドオフすることができ、これにより、新しいBF関連の情報がアプリケーションサーバ170に報告され得るとともに、このことが、アプリケーションサーバ170にRAT2BFを更新させ得る。

図4は、本発明のある実施形態による、図3のプロセスの続きを示す。図4を参照すると、図3の670において現在のBF値を調整すると判定した後、UE1は、BFを第2の値に設定する(700)。たとえば、図3の635においてRAT1がDO/W-CDMAに対応すると以前に判定されたので、図3の640において第1のBF値が6に設定されたと仮定する。次に、UE1がLTEネットワークにハンドオフしたので、UE1のサービングネットワーク、すなわちRAT1がLTEになったと仮定する。この場合、第2のBF値は1に設定され得る。

700において第2のBF値を確立した後で、UE1は、第2のBF値に従って、メディアのバッファリングと、パケットへのフレームのバンドリングとを開始する(705)。UE1は、第2のBF値に従ってバンドリングされたフレームとともに、RAT1を通じて、パケットをアプリケーションサーバ170に定期的に送信する(710)。アプリケーションサーバ170は、メディアパケットを受信し、受信されたメディアパケット(すなわち、第2のBF値)の関連するBF値を決定し、次いで、RAT2BFに基づくある数と、決定されたBF値(すなわち、700においてUE1によって設定された第2のBF値)を比較する(715)。図4の実施形態では、図4の715の間、RAT2は図3の615からUE2...Nに対して変化していないことが仮定される。したがって、第1のBF値の代わりに第2のBF値に対して比較されることを除き、715において行われる比較は図3の655と他の点では同様であり、したがって、簡潔にするためにこれ以上は論じられない。しかしながら、RAT2が変化した場合、たとえば、UE2...Nの1つまたは複数が異なる無線アクセス技術を伴う異なるネットワークにハンドオフする場合、RAT2BFはまた、UE2...Nの1つまたは複数から提供される補足的な通知(図示せず)に基づいて変化し得ることが諒解されるだろう。

図4の実施形態では、図3の655と異なり、715において、第2のBF値がRAT2BFおよび/またはRAT2BF*Aより大きいとアプリケーションサーバ170が判定すると仮定する。この場合、何ら特別な再バンドリング手順を伴わずにUE1からUE2...Nへ受信されたメディアパケットを単に転送する代わりに、アプリケーションサーバ170は、メディアバッファ内に含まれる着信メディアパケットとメディアフレームとをバッファリングすることを始める(720)。アプリケーションサーバ170は次いで、RAT2を通じたUE2...Nへの送信のために、バッファリングされたメディアからRAT2BFに基づいて固有のメディアパケットを生成する(725)。たとえば、第2のBF値が1に等しい場合、UE1からの各々の着信メディアパケットは、1個のメディアフレーム(たとえば、音声フレーム)を含む。RAT2BFが6に等しい場合、720のバッファリングステップは、UE1から受信された6個のメディアパケットから少なくとも6個のメディアフレームをバッファリングする。次いで、725において、アプリケーションサーバ170は、6個のメディアフレームを含むバンドリングされたメディアパケットを生成する。730において、アプリケーションサーバ170は、RAT2BFに従ってメディアパケットを送信する。730においてRAT2BFに従ってメディアパケットを受信すると、ターゲットUE2...Nは、RAT2BFに基づいて、デジッタバッファサイズを更新する(735)。上で述べられたように、一般に、より大きなBF値に対して、より大きなデジッタバッファサイズが確立される。したがって、図4の実施形態では、第2のBF値の代わりにRAT2BFに適合するようにメディアフレームをアプリケーションサーバ170が再バンドリングすることで、より大きなデジッタバッファサイズがUE2...Nにおいて実装されるようになる。

UE1に戻ると、UE1は、通信セッションの間のある期間、第2のBF値に従ってフレームを含むメディアパケットを送信し続け、アプリケーションサーバ170は、RAT2BFに従ってこれらのパケットからのメディアフレームをバッファリングし再バンドリングし続ける。図3の670と同様に、通信セッションの間、定期的に、またはイベント駆動の方式で、UE1は、現在のBF値を変更するかどうか判定する(740)。740においてUE1がBF値を変更しないと判定すると、プロセスは705に戻り、UE1は、通信セッションの間、第2のBF値に従ってメディアパケット内にフレームをバンドリングし続ける。そうではなく、740においてUE1がBF値を第1のBF値に戻すと判定すると、プロセスは上で説明された図3の640に進む。

図3および図4の実施形態では、UE2...Nは、同じアクセスネットワークRAT2によって各々がサービスされるものとして説明されている。しかしながら、発信側UEと、異なる無線アクセス技術および/または異なるRoHCパラメータと各々が関連付けられる異なるアクセスネットワークによってサービスされる複数のターゲットUEとの間で、グループ通信セッションが橋渡しされ得ることが理解される。したがって、図5および図6は、本発明のある実施形態による、第1の無線アクセスネットワークRAT1によってサービスされる発信側UE(すなわち、UE1)と、第2の無線アクセスネットワークRAT2によってサービスされるターゲットUEの第1のセット2...5と、第3の無線アクセスネットワークRAT3によってサービスされるターゲットUEの第2のセット6...Nとの間で通信セッションをセットアップするプロセスを示す。図5および図6において、RAT1がRAT2またはRAT3と同じネットワークに対応することが可能であるが(しかし、これは必ずしもそうであるとは限らない)、RAT2およびRAT3は、異なる無線アクセス技術(たとえば、LTE、DO/W-CDMA)を使用する無線アクセスネットワークに対応する。後で、図7および図8において、例示的な実装形態が、異なるレベルのRoHCのサポートと関連付けられる同じ無線アクセス技術(たとえば、RoHCをサポートするホームLTEネットワーク、RoHCをサポートしないローミングLTEネットワークなど)を介して動作するUEに関して説明される。

図5を参照すると、発信側UEすなわちUE1は、UE2...Nとの通信セッションを確立すると決定し(800)、ここでN>6である。UE1は、第1の無線アクセス技術に従って動作する現在のサービングネットワーク(「RAT1」)に対して呼の要求を送信し、RAT1は、通信セッションを調停するように構成されるアプリケーションサーバ170にその呼の要求を転送する(805)。アプリケーションサーバ170は、通信セッションのターゲットUE(すなわち、UE2...N)を特定し、UE2...5が第2の無線アクセス技術に従って動作するネットワーク(「RAT2」)によってサービスされることと、UE6...Nが第3の無線アクセス技術に従って動作するネットワーク(「RAT3」)によってサービスされることとを判定する。やはり、RAT2またはRAT3と関連付けられる第2の無線アクセス技術と第3の無線アクセス技術のいずれかがRAT1と同一であり得るが、RAT2およびRAT3は、異なる無線アクセス技術と関連付けられるか、異なるレベルのRoHCのサポートを伴う同じ無線アクセス技術と関連付けられるかのいずれかである。ターゲットUE2...Nの位置を特定した後、アプリケーションサーバ170は、RAT2を通じて通信セッションをターゲットUE2...5に告知し(810)、アプリケーションサーバ170は、RAT3を通じて通信セッションをターゲットUE6...Nに告知する(815)。

図5を参照すると、UE2...5は、RAT2に対するBF関連の情報を決定し(820)(たとえば、図3の615と同様に)、UE6...Nは、RAT3に対するBF関連の情報を決定する(825)。図3の615と同様に、ある例では、820および/または825の決定は、RAT2またはRAT3の無線アクセス技術(たとえば、LTE、EV-DO、W-CDMAなど)を単に特定することに対応し得る。別の例では、820および/または825の決定は、それぞれ、BF=1、BF=6などのような、RAT2およびRAT3に対してある特定の目標のBF値を決定することを含み得る。いずれの場合でも、820および825において決定されるBF関連の情報は、それぞれRAT2内のUE2...5およびRAT3内のUE6...Nに送達されるパケットに対する目標のBF値をアプリケーションサーバ170が決定するのに十分である。

UE2...Nは、セッション告知メッセージと、820および825において決定されたBF関連の情報とを受け入れることを、アプリケーションサーバ170に示す(830および835)。ある例では、BF関連の情報は、UE2...Nによる通信セッションの受け入れを示す、UE2...Nからの告知肯定応答メッセージ内に含まれ得る。あるいは、BF関連の情報は、告知肯定応答メッセージとは無関係な登録メッセージ(たとえば、図5のプロセスが開始する前でも送信され得る)を介して、アプリケーションサーバ170に伝えられ得る。したがって、呼の受け入れとBF関連の情報とを示すそれぞれのものは、820および/または825において同じメッセージに含まれていても含まれていなくてもよい。

図5を参照すると、UE2...Nの少なくとも1つから呼の受け入れを示すものを受信した後、アプリケーションサーバ170は、通信セッションが開始できることをUE1に通知する(840)。たとえば、半二重通信セッションの場合、840の通知はフロア付与メッセージに対応し得る。アプリケーションサーバ170は、RAT2と関連付けられるBF関連の情報を評価して、RAT2内のUE2...5に送達されるパケットに対する目標のBF(「RAT2BF」)を決定し(845)、アプリケーションはさらに、RAT3と関連付けられるBF関連の情報を評価して、RAT3内のUE6...Nに送達されるパケットに対する目標のBF(「RAT3BF」)を決定する(850)。ある例では、RAT2がDO/W-CDMAネットワークであることをUE2...5からのBF関連の情報が示し、RAT3がLTEネットワークであることをUE6...NからのBF関連の情報が示すと仮定する。この例では、RAT2BFは6に設定されてよく、RAT3BFは1に設定されてよい。別の例では、RAT2またはRAT3がRoHCを実装することが不可能なLTEローミングネットワークであることをBF関連の情報が示す場合、RAT2BFまたはRAT3BFは、3のような中間的な値に設定され得る。したがって、RAT2またはRAT3の無線アクセス技術はRAT2BFおよびRAT3BFに影響を与え得るが、これらを決定するものであるとは限らない。さらなる例では、820、830および845、ならびに/または、825、835および/もしくは850は、(たとえば、UE2...Nの1つまたは複数が異なるRATにハンドオフすることに応答して)通信セッションの間に1回または複数回繰り返すことができ、このことは、それぞれのUEに対する目標のBFを更新するようにアプリケーションサーバ170に促す。

図6は、本発明のある実施形態による、図5のプロセスの続きを示す。図6を参照すると、(たとえば、図3の650と同様に)UE1は、第1のBF値に従ってバンドリングされたフレームとともに、RAT1を通じて、パケットをアプリケーションサーバ170に定期的に送信する(900)。明示的には示されないが、900の送信は、図3に示されるようなブロック625〜645の実行の結果であり得る。これらの動作は、説明の便宜上、図6から省略されている。

図6を参照すると、アプリケーションサーバ170は、900においてUE1からメディアパケットを受信し、受信されたメディアパケットの関連するBF値を決定し、次いで、RAT2BFに基づくある数と、決定されたBF値(すなわち、第1のBF値)を比較する(905)。905の比較は、図3の655において行われる比較と同様である。したがって、ある実施形態では、655に関して上で論じられたように、アプリケーションサーバ170がUE1からの着信メディアパケットの決定されたBF値を905において比較する対象の数は、(i)RAT2BF自体または(ii)RAT2BFのオフセットされたバージョンのいずれかに対応してよく、(ii)の場合、RAT2BFは「A」と示される調整係数によって乗算される。

図6の実施形態では、905において、第1のBF値がRAT2BFおよび/またはRAT2BF*Aより大きいとアプリケーションサーバ170が判定すると仮定する。この場合、アプリケーションサーバ170は、何ら特別な再バンドリング手順を伴わずに、UE1からUE2...5へと受信されたメディアパケットを単に転送する(910)。したがって、910においてアプリケーションサーバ170によって送信されたメディアパケットは、900においてアプリケーションサーバ170へUE1によって送信されたメディアパケットと同じBF値、すなわち、第1のBF値を有する。910において第1のBF値に従ってメディアパケットを受信すると、ターゲットUE2...5は、第1のBF値に基づいて、デジッタバッファサイズを設定する(915)。

図6をさらに参照すると、アプリケーションサーバ170はまた、RAT3BFに基づく別の数と、決定されたBF値(すなわち、第1のBF値)を比較する(920)。920の比較は、図4の715において行われる比較と同様である。したがって、ある実施形態では、アプリケーションサーバ170がUE1からの着信メディアパケットの決定されたBF値を915において比較する対象の数は、(i)RAT3BF自体または(ii)RAT3BFのオフセットされたバージョンのいずれかに対応してよく、(ii)の場合、RAT3BFは「A」と示される調整係数によって乗算される。ある例では、920においてRAT3BFをオフセットするために使用される調整係数Aは、905においてRAT2BFをオフセットするために使用される調整係数Aと同じである必要はない。

920において、905とは異なり、第1のBF値がRAT3BFおよび/またはRAT3BF*Aよりも大きいとアプリケーションサーバ170が判定すると仮定する。この場合、何ら特別な再バンドリング手順を伴わずにUE1からUE6...Nに受信されたメディアパケットを単に転送する代わりに、アプリケーションサーバ170は、メディアバッファに含まれる着信メディアパケットとメディアフレームとをバッファリングすることを開始する(925)。アプリケーションサーバ170は次いで、RAT3を通じたUE6...Nへの送信のために、バッファリングされたメディアからRAT3BFに基づいて固有のメディアパケットを生成する(930)。たとえば、第1のBF値が1に等しい場合、UE1からの各々の着信メディアパケットは、1個のメディアフレーム(たとえば、音声フレーム)を含む。RAT3BFが6に等しい場合、925のバッファリングステップは、UE1から受信された6個のメディアパケットから少なくとも6個のメディアフレームをバッファリングする。次いで、930において、アプリケーションサーバ170は、6個のメディアフレームを含むバンドリングされたメディアパケットを生成する。935において、アプリケーションサーバ170は、RAT3BFに従ってメディアパケットを送信する。935においてRAT3BFに従ってメディアパケットを受信すると、ターゲットUE6...Nは、RAT3BFに基づいて、デジッタバッファサイズを更新する(940)。上で述べられたように、一般に、より大きなBF値に対して、より大きなデジッタバッファサイズが確立される。したがって、第1のBF値の代わりにRAT3BFに適合するようにメディアフレームをアプリケーションサーバ170が再バンドリングすることで、図6の実施形態の915におけるUE2...5と比較して、940においてより大きなデジッタバッファサイズがUE6...Nにおいて実装されるようになる。

図7を参照すると、発信側UEすなわちUE1は、UE2...Nとの通信セッションを確立すると決定し(1000)、ここでN>6である。UE1は、第1の無線アクセス技術に従って動作する現在のサービングネットワーク(「RAT1」)に対して呼の要求を送信し、RAT1は、通信セッションを調停するように構成されるアプリケーションサーバ170にその呼の要求を転送する(1005)。アプリケーションサーバ170は、通信セッションのターゲットUE(すなわち、UE2...N)を特定し、第2の無線アクセス技術に従って動作するネットワーク(「RAT2」)によってUE2...Nがサービスされると判定する。RAT2と関連付けられる第2の無線アクセス技術は、RAT1と同じであり得る。さらに、RAT2は、異なるレベルの性能と関連付けられる、第1の部分と第2の部分とを含む。たとえば、RAT2の第1の部分はRoHCをサポートできるが、RAT2の第2の部分はRoHCをサポートできない。ターゲットUE2...Nの位置を特定した後で、アプリケーションサーバ170は、第1の部分および第2の部分においてRAT2を通じて通信セッションをターゲットUE2...Nに告知する(1010および1015)。

図7を参照すると、UE2...5は、RAT2の第1の部分に対するBF関連の情報を決定し(1020)(たとえば、図3の615と同様に)、UE6...Nは、RAT2の第2の部分に対するBF関連の情報を決定する(1025)。図3の615と同様に、ある例では、1020および/または1025の決定は、RAT2の無線アクセス技術(たとえば、LTE、EV-DO、W-CDMAなど)を単に特定することに対応し得る。別の例では、1020および/または1025の決定は、それぞれ、BF=1、BF=6などのような、第1の部分および第2の部分のRAT2に対してある特定の目標のBF値を決定することを含み得る。いずれの場合でも、1020および1025において決定されるBF関連の情報は、それぞれRAT2の第1の部分内のUE2...5およびRAT2の第2の部分内のUE6...Nに送達されるパケットに対する目標のBF値をアプリケーションサーバ170が決定するのに十分である。

UE2...Nは、セッション告知メッセージと、1020および1025において決定されたBF関連の情報とを受け入れることを、アプリケーションサーバ170に示す(1030および1035)。ある例では、BF関連の情報は、UE2...Nによる通信セッションの受け入れを示す、UE2...Nからの告知肯定応答メッセージ内に含まれ得る。あるいは、BF関連の情報は、告知肯定応答メッセージとは無関係な登録メッセージ(たとえば、図7のプロセスが開始する前でも送信され得る)を介して、アプリケーションサーバ170に伝えられ得る。したがって、呼の受け入れとBF関連の情報とを示すそれぞれのものは、1020および/または1025において同じメッセージに含まれていても含まれていなくてもよい。

図7を参照すると、UE2...Nの少なくとも1つから呼の受け入れを示すものを受信した後、アプリケーションサーバ170は、通信セッションが開始できることをUE1に通知する(1040)。たとえば、半二重通信セッションの場合、1040の通知はフロア付与メッセージに対応し得る。アプリケーションサーバ170は、RAT2の第1の部分と関連付けられるBF関連の情報を評価して、RAT2の第1の部分内のUE2...5に送達されるパケットに対する目標のBF(「RAT2BF#1」)を決定し(1045)、アプリケーションはさらに、RAT2の第2の部分と関連付けられるBF関連の情報を評価して、RAT2の第2の部分内のUE6...Nに送達されるパケットに対する目標のBF(「RAT2BF#2」)を決定する(1050)。ある例では、RAT2の第1の部分がRoHCをサポートしないことをUE2...5からのBF関連の情報が示し、RAT2の第2の部分がRoHCをサポートすることをUE6...NからのBF関連の情報が示すと仮定する。この例では、RAT2BF#1は6に設定されてよく、RAT2BF#2は1に設定されてよい。別の例では、RAT2の第1の部分または第2の部分がRoHCを実装することが不可能なLTEローミングネットワークであることをBF関連の情報が示す場合、RAT2BF#1またはRAT2BF#2は、3のような中間的な値に設定され得る。したがって、RAT2の第1の部分および第2の部分の無線アクセス技術および性能レベル(たとえば、RoHCサポートのレベルのような)は、RAT2BF#1およびRAT2BF#2に影響を与え得るが、必ずしもそれらを決定するものではない。さらなる例では、1020、1030および1045、ならびに/または、1025、1035および/もしくは1050は、(たとえば、UE2...Nの1つまたは複数が異なるRATにハンドオフすること、異なるRoHCサポートのレベルを伴う同じRATの異なる部分に移行することなどに応答して)通信セッションの間に1回または複数回繰り返すことができ、このことは、それぞれのUEに対する目標のBFを更新するようにアプリケーションサーバ170に促す。

図8は、本発明のある実施形態による、図7のプロセスの続きを示す。図8を参照すると、(たとえば、図3の650と同様に)UE1は、第1のBF値に従ってバンドリングされたフレームとともに、RAT1を通じて、パケットをアプリケーションサーバ170に定期的に送信する(1100)。明示的には示されないが、1100の送信は、図3に示されるようなブロック625〜645の実行の結果であり得る。これらの動作は、説明の便宜上、図8から省略されている。

図8を参照すると、アプリケーションサーバ170は、1100においてUE1からメディアパケットを受信し、受信されたメディアパケットの関連するBF値を決定し、次いで、RAT2BF#1に基づくある数と、決定されたBF値(すなわち、第1のBF値)を比較する(1105)。1105の比較は、図3の655において行われる比較と同様である。したがって、ある実施形態では、図3の655に関して上で論じられたように、アプリケーションサーバ170がUE1からの着信メディアパケットの決定されたBF値を1105において比較する対象の数は、(i)RAT2BF#1自体または(ii)RAT2BF#1のオフセットされたバージョンのいずれかに対応してよく、(ii)の場合、RAT2BF#1は「A」と示される調整係数によって乗算され、または他の方法で修正される。

図8の実施形態では、1105において、第1のBF値がRAT2BF#1および/またはRAT2BF#1*Aより大きいとアプリケーションサーバ170が判定すると仮定する。この場合、アプリケーションサーバ170は、何ら特別な再バンドリング手順を伴わずに、UE1からRAT2の第1の部分内のUE2...5へと受信されたメディアパケットを単に転送する(1110)。したがって、1110においてアプリケーションサーバ170によって送信されたメディアパケットは、1100においてアプリケーションサーバ170へUE1によって送信されたメディアパケットと同じBF値、すなわち、第1のBF値を有する。1110において第1のBF値に従ってメディアパケットを受信すると、ターゲットUE2...5は、第1のBF値に基づいて、デジッタバッファサイズを設定する(1115)。

図8をさらに参照すると、アプリケーションサーバ170はまた、RAT2BF#2に基づく別の数と、決定されたBF値(すなわち、第1のBF値)を比較する(1120)。1120の比較は、図4の715において行われる比較と同様である。したがって、ある実施形態では、アプリケーションサーバ170がUE1からの着信メディアパケットの決定されたBF値を1115において比較する対象の数は、(i)RAT2BF#2自体または(ii)RAT2BF#2のオフセットされたバージョンのいずれかに対応してよく、(ii)の場合、RAT2BF#2は「A」と示される調整係数によって乗算される。ある例では、1120においてRAT2BF#2をオフセットするために使用される調整係数Aは、1105においてRAT2BF#1をオフセットするために使用される調整係数Aと同じである必要はない。

1120において、1105とは異なり、第1のBF値がRAT2BF#2および/またはRAT2BF#2*Aよりも大きいとアプリケーションサーバ170が判定すると仮定する。この場合、何ら特別な再バンドリング手順を伴わずにUE1からUE6...Nに受信されたメディアパケットを単に転送する代わりに、アプリケーションサーバ170は、メディアバッファに含まれる着信メディアパケットとメディアフレームとをバッファリングすることを開始する(1125)。アプリケーションサーバ170は次いで、RAT2の第2の部分を通じたUE6...Nへの送信のために、バッファリングされたメディアからRAT2BF#2に基づいて固有のメディアパケットを生成する(1130)。たとえば、第1のBF値が1に等しい場合、UE1からの各々の着信メディアパケットは、1個のメディアフレーム(たとえば、音声フレーム)を含む。RAT2BF#2が6に等しい場合、1125のバッファリングステップは、UE1から受信された6個のメディアパケットから少なくとも6個のメディアフレームをバッファリングする。次いで、1130において、アプリケーションサーバ170は、6個のメディアフレームを含むバンドリングされたメディアパケットを生成する。1135において、アプリケーションサーバ170は、RAT2BF#2に従ってメディアパケットを送信する。1135においてRAT2BF#2に従ってメディアパケットを受信すると、ターゲットUE6...Nは、RAT2BF#2に基づいて、デジッタバッファサイズを更新する(1140)。上で述べられたように、一般に、より大きなBF値に対して、より大きなデジッタバッファサイズが確立される。したがって、第1のBF値の代わりにRAT2BF#2に適合するようにメディアフレームをアプリケーションサーバ170が再バンドリングすることで、図8の実施形態の1115におけるUE2...5と比較して、1140においてより大きなデジッタバッファサイズがUE6...Nにおいて実装されるようになる。

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

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

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

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

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

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

170 アプリケーションサーバ
200 UE
202 プラットフォーム
206 送受信機
208 ASIC
210 アプリケーションプログラミングインターフェース
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
226 キーパッド
228 プッシュツートークボタン
400 通信デバイス
405 情報を受信および/または送信するように構成された論理部
410 情報を処理するように構成された論理部
415 情報を記憶するように構成された論理部
420 情報を提示するように構成された論理部
425 ローカルユーザ入力を受け取るように構成された論理部

Claims (56)

1. 複数のユーザ機器(UE)の間の通信セッションを調停するように構成されたサーバを動作させる方法であって、
   前記複数のUEのうちの少なくとも1つのターゲットUEに対して、前記少なくとも1つのターゲットUEに送信されるメディアパケット当たり目標の数のメディアフレームがあることを示す少なくとも1つの目標のバンドリング係数(BF)を決定するステップであって、前記目標のBFが、前記少なくとも1つのターゲットUEの接続先の、前記少なくとも1つのターゲットUEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、ステップと、
   前記通信セッションの間に前記複数のUEのうちの送信側UEから、前記少なくとも1つのターゲットUEへの送信のために所与の数のメディアフレームを各々含むメディアパケットのセットを受信するステップであって、前記所与の数がメディアパケットの前記セットに適用される所与のBFに基づく、ステップと、
   前記少なくとも1つの目標のBFに基づいて、メディアパケットの前記セットに適用される前記所与のBFを修正するかどうか判定するステップと、
   前記修正の判定に基づいて、メディアパケットの前記セットからの前記メディアフレームを前記少なくとも1つのターゲットUEに送信するステップとを含む、方法。
2. 前記少なくとも1つの目標のBFが、複数のターゲットUEと適合する共通の目標のBFを含み、前記複数のターゲットUEの各々に対する前記所与のBFを修正するかどうかを判定するために使用される、請求項1に記載の方法。
3. 前記少なくとも1つの目標のBFを決定するステップが、
   前記複数のターゲットUEの各々に対して、前記ターゲットUEが適合する最小のBFを決定するステップと、
   前記決定された最小のBFのうちの最大のBFに基づいて、前記共通の目標のBFを確立するステップとを含む、請求項2に記載の方法。
4. 前記共通の目標のBFを確立するステップが前記サーバにおけるオーバーヘッドを低減するように、前記決定された最小のBFが2つ以上の異なるBFを含む、請求項3に記載の方法。
5. 共通のバッファが、前記共通の目標のBFに従って前記複数のターゲットUEへの送達のためにパケットをバッファリングするために前記サーバによって使用される、請求項2に記載の方法。
6. 前記少なくとも1つの目標のBFを前記決定するステップが、
   前記少なくとも1つのターゲットUEからBF関連の情報を受信するステップを含む、請求項1に記載の方法。
7. 前記受信されたBF関連の情報が、(i)前記少なくとも1つの目標のBFを示すもの、(ii)ヘッダ圧縮が前記少なくとも1つのターゲットUEの現在のサービングネットワークにおいてサポートされるかどうかを示すもの、および/または、(iii)ヘッダ圧縮が前記少なくとも1つのターゲットUEの接続先の前記現在のサービングネットワークのサブセットにおいてサポートされるかどうかを示すものを含む、請求項6に記載の方法。
8. ヘッダ圧縮が前記現在のサービングネットワークにおいてサポートされるかどうかを前記示すものが、前記現在のサービングネットワークのタイプを示すものに対応する、請求項7に記載の方法。
9. 前記受信されたBF関連の情報が、前記現在のサービングネットワークの前記タイプがLong Term Evolution(LTE)であることを示すことによってヘッダ圧縮がサポートされることを示す、請求項8に記載の方法。
10. 前記受信されたBF関連の情報が、前記現在のサービングネットワークの前記タイプがW-CDMAおよび/またはEV-DOであることを示すことによってヘッダ圧縮がサポートされないことを示す、請求項8に記載の方法。
11. ヘッダ圧縮が前記現在のサービングネットワークの前記サブセットにおいてサポートされるかどうかを前記示すものが、前記現在のサービングネットワークの前記サブセットのサブセット固有の性能レベルを示すものに対応する、請求項7に記載の方法。
12. 少なくとも1つの目標のBFを前記決定するステップが、
    メディアパケット当たりに許容可能な目標の数のメディアフレームが、前記少なくとも1つのターゲットUEの1つまたは複数のUEに送信されることを示す、第1のBFを特定するステップと、
    調整係数に基づいて前記第1のBFを低減して第2のBFを生成するステップとを含み、
    前記第2のBFが、前記1つまたは複数のUEに対する前記少なくとも1つの目標のBFに対応する、請求項1に記載の方法。
13. 前記第1のBFが低減される程度を前記調整係数が制御し、
    前記第1のBFのより大きな低減が、前記送信されるメディアフレームの再バンドリングの遅延を改善し、前記第1のBFのより小さな低減が、前記送信されるメディアフレームのパッキングの効率を改善し、
    前記調整係数が、前記再バンドリングの遅延と前記パッキングの効率とのトレードオフとして確立される、請求項12に記載の方法。
14. 修正するかどうか前記判定するステップが、
    前記所与のBFを、前記少なくとも1つの目標のBFに基づく少なくとも1つの数と比較するステップを含む、請求項1に記載の方法。
15. 修正するかどうか前記判定するステップが、
    前記所与のBFが前記少なくとも1つの数より大きくないことを前記比較が示す場合、前記所与のBFを修正すると判定するステップと、
    前記所与のBFが前記少なくとも1つの数より大きいことを前記比較が示す場合、前記所与のBFを修正しないと判定するステップとをさらに含む、請求項14に記載の方法。
16. 前記少なくとも1つの数が、前記少なくとも1つの目標のBFまたは前記少なくとも1つの目標のBFの少なくとも1つのオフセットされたバージョンに対応する、請求項15に記載の方法。
17. 修正するかどうか前記判定するステップが前記所与のBFを修正すると判定し、前記方法が、
    前記サーバにおいてメディアパケットの前記セットをバッファリングするステップと、
    メディアパケットの前記バッファリングされたセットに基づいて、前記少なくとも1つの目標のBFに基づいてメディアパケットの異なるセットを生成するステップとをさらに含み、
    前記送信するステップが、メディアパケットの前記異なるセットを前記少なくとも1つのターゲットUEに送信する、請求項1に記載の方法。
18. 前記少なくとも1つのターゲットUEが、ターゲットUEの第1のセットおよびターゲットUEの第2のセットを含み、
    少なくとも1つの目標のBFを前記決定するステップが、ターゲットUEの前記第1のセットに対する第1の目標のBFおよびターゲットUEの前記第2のセットに対する第2の目標のBFを決定する、請求項1に記載の方法。
19. ターゲットUEの前記第1のセットおよびターゲットUEの前記第2のセットが、異なるタイプのサービングネットワークに接続される、請求項18に記載の方法。
20. ターゲットUEの前記第1のセットおよびターゲットUEの前記第2のセットが、同じタイプのサービングネットワークに接続される、請求項18に記載の方法。
21. 前記第1のターゲットUEおよび第2のターゲットUEが、異なる性能レベルと関連付けられる同じサービングネットワークの異なるサブセットに接続される、請求項20に記載の方法。
22. 修正するかどうか前記判定するステップが、ターゲットUEの前記第1のセットに対する前記所与のBFを修正すると判定し、ターゲットUEの前記第2のセットに対する前記所与のBFを修正しないと判定する、請求項18に記載の方法。
23. 修正するかどうか前記判定するステップが、
    前記所与のBFを、前記第1の目標のBFに基づく第1の数および前記第2の目標のBFに基づく第2の数と比較するステップを含む、請求項18に記載の方法。
24. 修正するかどうか前記判定するステップが、
    前記所与のBFが前記第1の数より大きくないことを前記比較が示す場合、ターゲットUEの前記第1のセットに対する前記所与のBFを修正すると判定するステップと、
    前記所与のBFが前記第1の数より大きいことを前記比較が示す場合、ターゲットUEの前記第1のセットに対する前記所与のBFを修正しないと判定するステップと、
    前記所与のBFが前記第2の数より大きくないことを前記比較が示す場合、ターゲットUEの前記第2のセットに対する前記所与のBFを修正すると判定するステップと、
    前記所与のBFが前記第2の数より大きいことを前記比較が示す場合、ターゲットUEの前記第2のセットに対する前記所与のBFを修正しないと判定するステップとをさらに含む、
    請求項23に記載の方法。
25. 前記第1の数および第2の数が、前記第1の目標のBFおよび第2の目標のBFにそれぞれ対応し、または、前記第1の目標のBFおよび第2の目標のBFの第1のオフセットされたバージョンおよび第2のオフセットされたバージョンにそれぞれ対応する、請求項24に記載の方法。
26. 前記送信側UEから、前記少なくとも1つのターゲットUEへの送信のために別の所与の数のメディアフレームを各々含むメディアパケットの別のセットを受信するステップであって、前記別の所与の数がメディアパケットの前記別のセットに適用される別の所与のBFに基づく、ステップをさらに含み、
    修正するかどうか前記判定するステップおよび前記送信するステップが、前記別の所与のBFに基づいて繰り返される、請求項1に記載の方法。
27. 前記送信側UEの、(i)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う異なるサービングネットワークへの、または、(ii)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う同じサービングネットワークの異なる部分への移行に基づいて、メディアパケットの別のセットを前記受信するステップが行われる、請求項26に記載の方法。
28. 前記少なくとも1つのターゲットUEに対する別の少なくとも1つの目標のBFを決定するステップと、
    前記決定された別の少なくとも1つの目標のBFに基づいて、前記受信するステップと、修正するかどうか判定するステップと、送信するステップとを繰り返すステップとをさらに含む、請求項1に記載の方法。
29. 別の少なくとも1つの目標のBFを前記決定するステップが、前記少なくとも1つのターゲットUEの、(i)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う異なるサービングネットワークへの、または、(ii)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う同じサービングネットワークの異なる部分への移行に基づく、請求項28に記載の方法。
30. 複数のUEの間の通信セッションに参加しているユーザ機器(UE)を動作させる方法であって、
    前記通信セッションの間に、第1の数のメディアフレームを各々含むメディアパケットの第1のセットを受信するステップであって、前記第1の数が、メディアパケットの前記第1のセットに適用される第1のバンドリング係数(BF)に基づく、ステップと、
    前記UEのデジッタバッファサイズを、前記第1のBFに基づく第1のレベルに設定するステップと、
    前記UEの前記デジッタバッファサイズを前記第1のレベルに設定した後で、前記通信セッションの間に、第2の数のメディアフレームを各々含むメディアパケットの第2のセットを受信するステップであって、前記第2の数が、メディアパケットの前記第2のセットに適用される第2のBFに基づく、ステップと、
    前記UEの前記デジッタバッファサイズを、前記第2のBFに基づく第2のレベルに移行するステップとを含み、
    前記第1のBFまたは第2のBFは目標のBFに基づいて修正され、前記目標のBFが、前記UEの接続先の、前記UEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、
    方法。
31. メディアフレームの前記第1の数および第2の数を提供する、前記UEと関連付けられるBF関連の情報を、サーバに提供するステップをさらに含む、請求項30に記載の方法。
32. 前記提供されたBF関連の情報が、(i)前記UEと適合する、前記目標のBFを含む少なくとも1つの目標のBFを示すもの、(ii)ヘッダ圧縮が前記UEの現在のサービングネットワークにおいてサポートされるかどうかを示すもの、および/または、(iii)ヘッダ圧縮が前記UEの接続先の前記現在のサービングネットワークのサブセットにおいてサポートされるかどうかを示すものを含む、請求項31に記載の方法。
33. ヘッダ圧縮が前記現在のサービングネットワークにおいてサポートされるかどうかを前記示すものが、前記現在のサービングネットワークのタイプを示すものに対応する、請求項32に記載の方法。
34. 前記提供されたBF関連の情報が、前記現在のサービングネットワークの前記タイプがLong Term Evolution(LTE)であることを示すことによってヘッダ圧縮がサポートされることを示す、請求項33に記載の方法。
35. 前記提供されたBF関連の情報が、前記現在のサービングネットワークの前記タイプがW-CDMAおよび/またはEV-DOであることを示すことによってヘッダ圧縮がサポートされないことを示す、請求項33に記載の方法。
36. ヘッダ圧縮が前記現在のサービングネットワークの前記サブセットにおいてサポートされるかどうかを前記示すものが、前記現在のサービングネットワークの前記サブセットのサブセット固有の性能レベルを示すものに対応する、請求項32に記載の方法。
37. メディアフレームの前記第1の数および/または第2の数が、前記サーバに提供された前記BF関連の情報に少なくとも一部基づく、請求項31に記載の方法。
38. (i)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う異なるサービングネットワークへ、または、(ii)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う同じサービングネットワークの異なる部分へ移行するステップをさらに含む、請求項30に記載の方法。
39. 前記移行に基づいて、メディアフレームの前記第1の数および第2の数を提供するBF関連の情報をサーバに提供するステップをさらに含む、請求項38に記載の方法。
40. 前記第1の数のメディアフレームを各々含むパケットを受信することから、前記第2の数のメディアフレームを各々含むパケットを受信することへの変更が、前記移行に基づいて前記サーバに提供される前記BF関連の情報によって引き起こされる、請求項39に記載の方法。
41. ユーザ機器(UE)を操作する方法であって、
    少なくとも1つのターゲットUEとの、サーバによって調停されるべき通信セッションを、始めると決定するステップと、
    前記UEにサービスするアクセスネットワークがヘッダ圧縮をサポートするかどうかを判定するステップと、
    前記ヘッダ圧縮のサポートの判定に基づいて、メディアパケット当たり第1の数のメディアフレームがあることを示す第1のバンドリング係数(BF)を確立するステップと、
    前記第1のBFに基づいて、前記通信セッションの間の前記少なくとも1つのターゲットUEへの送信のために、前記第1の数のメディアフレームを各々含むメディアパケットの第1のセットを前記サーバに送信するステップとを含む、方法。
42. メディアパケット当たり第2の数のメディアフレームがあることを示す第2のBFを確立するステップと、
    前記第2のBFに基づいて、前記通信セッションの間の前記少なくとも1つのターゲットUEへの送信のために、前記第2の数のメディアフレームを各々含むメディアパケットの第2のセットを前記サーバに送信するステップとをさらに含む、請求項41に記載の方法。
43. 前記第2のBFが、(i)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う異なるアクセスネットワークへの、または、(ii)異なるレベルのヘッダ圧縮のサポートおよび/または異なるレベルの性能を伴う前記アクセスネットワークの異なる部分への前記UEの移行に応答して確立される、請求項42に記載の方法。
44. 前記UEにサービスする前記アクセスネットワークがヘッダ圧縮をサポートするかどうかの前記判定が、前記アクセスネットワークのタイプに基づく、請求項41に記載の方法。
45. 前記アクセスネットワークの前記タイプがLong Term Evolution(LTE)である場合、前記アクセスネットワークがヘッダ圧縮をサポートすると判定される、請求項44に記載の方法。
46. 前記アクセスネットワークの前記タイプがW-CDMAおよび/またはEV-DOである場合、前記アクセスネットワークがヘッダ圧縮をサポートしないと判定される、請求項44に記載の方法。
47. 前記UEにサービスする前記アクセスネットワークがヘッダ圧縮をサポートするかどうかの前記判定が、前記アクセスネットワークのサブセットのサブセット固有の性能レベルに基づく、請求項41に記載の方法。
48. 複数のユーザ機器(UE)の間の通信セッションを調停するように構成されたサーバであって、
    前記複数のUEのうちの少なくとも1つのターゲットUEに対して、前記少なくとも1つのターゲットUEに送信されるメディアパケット当たり目標の数のメディアフレームがあることを示す少なくとも1つの目標のバンドリング係数(BF)を決定するための手段であって、前記目標のBFが、前記少なくとも1つのターゲットUEの接続先の、前記少なくとも1つのターゲットUEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、手段と、
    前記通信セッションの間に前記複数のUEのうちの送信側UEから、前記少なくとも1つのターゲットUEへの送信のために所与の数のメディアフレームを各々含むメディアパケットのセットを受信するための手段であって、前記所与の数がメディアパケットの前記セットに適用される所与のBFに基づく、手段と、
    前記少なくとも1つの目標のBFに基づいて、メディアパケットの前記セットに適用される前記所与のBFを修正するかどうか判定するための手段と、
    前記修正の判定に基づいて、メディアパケットの前記セットからの前記メディアフレームを前記少なくとも1つのターゲットUEに送信するための手段とを含む、サーバ。
49. 複数のUEの間の通信セッションに参加するように構成されたユーザ機器(UE)であって、
    前記通信セッションの間に、第1の数のメディアフレームを各々含むメディアパケットの第1のセットを受信するための手段であって、前記第1の数が、メディアパケットの前記第1のセットに適用される第1のバンドリング係数(BF)に基づく、手段と、
    前記UEのデジッタバッファサイズを、前記第1のBFに基づく第1のレベルに設定するための手段と、
    前記UEの前記デジッタバッファサイズを前記第1のレベルに設定した後で、前記通信セッションの間に、第2の数のメディアフレームを各々含むメディアパケットの第2のセットを受信するための手段であって、前記第2の数が、メディアパケットの前記第2のセットに適用される第2のBFに基づく、手段と、
    前記UEの前記デジッタバッファサイズを、前記第2のBFに基づく第2のレベルに移行するための手段とを含み、
    前記第1のBFまたは第2のBFは目標のBFに基づいて修正され、前記目標のBFが、前記UEの接続先の、前記UEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、
    ユーザ機器。
50. 複数のUEの間の通信セッションに参加するように構成されたユーザ機器(UE)であって、
    少なくとも1つのターゲットUEとの、サーバによって調停されるべき前記通信セッションを、始めると決定するための手段と、
    前記UEにサービスするアクセスネットワークがヘッダ圧縮をサポートするかどうかを判定するための手段と、
    前記ヘッダ圧縮のサポートの判定に基づいて、メディアパケット当たり第1の数のメディアフレームがあることを示す第1のバンドリング係数(BF)を確立するための手段と、
    前記第1のBFに基づいて、前記通信セッションの間の前記少なくとも1つのターゲットUEへの送信のために、前記第1の数のメディアフレームを各々含むメディアパケットの第1のセットを前記サーバに送信するための手段とを含む、ユーザ機器。
51. 複数のユーザ機器(UE)の間の通信セッションを調停するように構成されたサーバであって、
    前記複数のUEのうちの少なくとも1つのターゲットUEに対して、前記少なくとも1つのターゲットUEに送信されるメディアパケット当たり目標の数のメディアフレームがあることを示す少なくとも1つの目標のバンドリング係数(BF)を決定するように構成された論理部であって、前記目標のBFが、前記少なくとも1つのターゲットUEの接続先の、前記少なくとも1つのターゲットUEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、論理部と、
    前記通信セッションの間に前記複数のUEのうちの送信側UEから、前記少なくとも1つのターゲットUEへの送信のために所与の数のメディアフレームを各々含むメディアパケットのセットを受信するように構成された論理部であって、前記所与の数がメディアパケットの前記セットに適用される所与のBFに基づく、論理部と、
    前記少なくとも1つの目標のBFに基づいて、メディアパケットの前記セットに適用される前記所与のBFを修正するかどうか判定するように構成された論理部と、
    前記修正の判定に基づいて、メディアパケットの前記セットからの前記メディアフレームを前記少なくとも1つのターゲットUEに送信するように構成された論理部とを含む、サーバ。
52. 複数のUEの間の通信セッションに参加するように構成されたユーザ機器(UE)であって、
    前記通信セッションの間に、第1の数のメディアフレームを各々含むメディアパケットの第1のセットを受信するように構成された論理部であって、前記第1の数が、メディアパケットの前記第1のセットに適用される第1のバンドリング係数(BF)に基づく、論理部と、 前記UEのデジッタバッファサイズを、前記第1のBFに基づく第1のレベルに設定するように構成された論理部と、
    前記UEの前記デジッタバッファサイズを前記第1のレベルに設定した後で、前記通信セッションの間に、第2の数のメディアフレームを各々含むメディアパケットの第2のセットを受信するように構成された論理部であって、前記第2の数が、メディアパケットの前記第2のセットに適用される第2のBFに基づく、論理部と、
    前記UEの前記デジッタバッファサイズを、前記第2のBFに基づく第2のレベルに移行するように構成された論理部とを含み、
    前記第1のBFまたは第2のBFは目標のBFに基づいて修正され、前記目標のBFが、前記UEの接続先の、前記UEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、
    ユーザ機器。
53. 複数のUEの間の通信セッションに参加するように構成されたユーザ機器(UE)であって、
    少なくとも1つのターゲットUEとの、サーバによって調停されるべき前記通信セッションを、始めると決定するように構成された論理部と、
    前記UEにサービスするアクセスネットワークがヘッダ圧縮をサポートするかどうかを判定するように構成された論理部と、
    前記ヘッダ圧縮のサポートの判定に基づいて、メディアパケット当たり第1の数のメディアフレームがあることを示す第1のバンドリング係数(BF)を確立するように構成された論理部と、
    前記第1のBFに基づいて、前記通信セッションの間の前記少なくとも1つのターゲットUEへの送信のために、前記第1の数のメディアフレームを各々含むメディアパケットの第1のセットを前記サーバに送信するように構成された論理部とを含む、ユーザ機器。
54. 複数のユーザ機器(UE)との間の通信セッションを調停するように構成されたサーバによって実行されると、前記サーバに動作を実行させる、記憶された命令を含む非一時的コンピュータ可読記録媒体であって、前記命令が、
    前記複数のUEのうちの少なくとも1つのターゲットUEに対して、前記少なくとも1つのターゲットUEに送信されるメディアパケット当たりに目標の数のメディアフレームがあることを示す少なくとも1つの目標のバンドリング係数(BF)を決定するための少なくとも1つの命令であって、前記目標のBFが、前記少なくとも1つのターゲットUEの接続先の、前記少なくとも1つのターゲットUEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、命令と、
    前記通信セッションの間に前記複数のUEのうちの送信側UEから、前記少なくとも1つのターゲットUEへの送信のために所与の数のメディアフレームを各々含むメディアパケットのセットを受信するための少なくとも1つの命令であって、前記所与の数がメディアパケットの前記セットに適用される所与のBFに基づく、命令と、
    前記少なくとも1つの目標のBFに基づいて、メディアパケットの前記セットに適用される前記所与のBFを修正するかどうか判定するための少なくとも1つの命令と、
    前記修正の判定に基づいて、メディアパケットの前記セットからの前記メディアフレームを前記少なくとも1つのターゲットUEに送信するための少なくとも1つの命令とを含む、
    非一時的コンピュータ可読記録媒体。
55. 複数のユーザ機器(UE)の間の通信セッションに参加するように構成されたUEによって実行されると、前記UEに動作を実行させる、記憶された命令を含む非一時的コンピュータ可読記録媒体であって、前記命令が、
    前記通信セッションの間に、第1の数のメディアフレームを各々含むメディアパケットの第1のセットを受信するための少なくとも1つの命令であって、前記第1の数が、メディアパケットの前記第1のセットに適用される第1のバンドリング係数(BF)に基づく、命令と、
    前記UEのデジッタバッファサイズを、前記第1のBFに基づく第1のレベルに設定するための少なくとも1つの命令と、
    前記UEの前記デジッタバッファサイズを前記第1のレベルに設定した後で、前記通信セッションの間に、第2の数のメディアフレームを各々含むメディアパケットの第2のセットを受信するための少なくとも1つの命令であって、前記第2の数が、メディアパケットの前記第2のセットに適用される第2のBFに基づく、命令と、
    前記UEの前記デジッタバッファサイズを、前記第2のBFに基づく第2のレベルに移行するための少なくとも1つの命令とを含み、
    前記第1のBFまたは第2のBFは目標のBFに基づいて修正され、前記目標のBFが、前記UEの接続先の、前記UEの現在のサービングネットワークにおいて、または、前記現在のサービングネットワークのサブセットにおいて、ヘッダ圧縮がサポートされるかどうかに基づいて決定される、
    非一時的コンピュータ可読記録媒体。
56. 複数のユーザ機器(UE)の間の通信セッションに参加するように構成されたUEによって実行されると、前記UEに動作を実行させる、記憶された命令を含む非一時的コンピュータ可読記録媒体であって、前記命令が、
    少なくとも1つのターゲットUEとの、サーバによって調停されるべき通信セッションを、始めると決定するための少なくとも1つの命令と、
    前記UEにサービスするアクセスネットワークがヘッダ圧縮をサポートするかどうかを判定するための少なくとも1つの命令と、
    前記ヘッダ圧縮のサポートの判定に基づいて、メディアパケット当たりに第1の数のメディアフレームがあることを示す第1のバンドリング係数(BF)を確立するための少なくとも1つの命令と、
    前記第1のBFに基づいて、前記通信セッションの間の前記少なくとも1つのターゲットUEへの送信のために、前記第1の数のメディアフレームを各々含むメディアパケットの第1のセットを前記サーバに送信するための少なくとも1つの命令とを含む、非一時的コンピュータ可読記録媒体。

Images