JP2016523009A - リアルタイム通信セッションのリワインド - Google Patents

Abstract

一実施形態では、送信デバイスが、リアルタイム通信セッションのためのリアルタイムメディアストリームを1組のターゲットデバイスに送信する。1組のターゲットデバイスのうちの少なくとも1つが、リアルタイム通信セッション内のメディア受信空白を検出し、メディア受信空白中に失われたメディアを含む、リアルタイムメディアストリームの時間遅延バージョンを生成し、提供するように送信デバイスをトリガするリワインド要求を送信デバイスに送信する。送信デバイスは、リワインド要求に基づいてリワインドストリームを生成し、リワインドストリームを少なくとも1つのターゲットデバイスに送信する。

Description

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれる、本出願と同じ発明人による、「REWINDING A REAL-TIME COMMUNICATION SESSION」と題する2013年4月3日に出願された仮出願第61/807,962号の利益を主張する。

本発明の実施形態は、リアルタイムグループ通信セッションをリワインドすることに関する。

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

最近になって、モバイル電話および他のデータ端末のための高速データのワイヤレス通信のためのワイヤレス通信プロトコルとして、長期発展型(LTE)が開発された。LTEはGMSに基づいており、GSM(登録商標)発展のための拡張データレート(Enhanced Data rates for GSM(登録商標) Evolution:EDGE)のような様々なGSM(登録商標)関連プロトコル、および高速パケットアクセス(HSPA)のようなユニバーサルモバイル電気通信システム(UMTS)からの寄与を含む。

上記の通信プロトコルのいずれにおいても、ユーザ機器(UE)が他のUEとの通信セッションに参加することができ、その通信セッションによって、メディア(たとえば、オーディオメディア、ビデオメディアなど)がリアルタイムに交換され、再生される。リアルタイム通信セッションでは、メディアの価値は、時間(たとえば、ほんの10分の数秒)が経過すると、急激に低下する。たとえば、通話中に受信されたオーディオパケットに含まれるオーディオデータ(たとえば、1つまたは複数のオーディオフレーム)は通常、ターゲットUEによって受信された後に、比較的直ちに(たとえば、100ms〜200ms)で再生される必要があり、そうでないと、そのオーディオデータは、その通話との関連性を失う。また、オーディオパケットが通話中に失われた場合には、失われたオーディオパケットを再び入手するのに(たとえば、話者から、または通話のためのオーディオパケットをアーカイブするサーバから)比較的に長い時間(たとえば、数秒)を要する可能性がある。リアルタイム通信セッション中のパケット損失を軽減するために、順方向誤り訂正(FER)またはインターリービングのような機構が使用される。

しかしながら、リアルタイム通信セッション中にターゲットUEのメディアにおいて比較的長い供給停止が生じる(たとえば、ターゲットUEが8秒間、トンネル内を走行し、その期間中に送信されたすべてのメディアパケットを失う)場合には、一般的に、リアルタイム通信セッションへの能動的な参加も保持しながら、供給停止中に失われたメディアパケットを復元することに関するターゲットUEのためのリソースはほとんどない。いくつかのシステムはリアルタイム通信セッションを記録またはアーカイブするように設定され、その場合、ターゲットUEは後に、アーカイブされたセッションから、失われた部分に同調しようと試みることができるが、これは一般に、リアルタイム通信セッションが進行中に都合良く実施することはできない。

米国特許出願第13/796,455号 米国特許出願第13/796,561号

一実施形態では、送信デバイスが、リアルタイム通信セッションのためのリアルタイムメディアストリームを1組のターゲットデバイスに送信する。1組のターゲットデバイスのうちの少なくとも1つが、リアルタイム通信セッション内のメディア受信空白を検出し、メディア受信空白中に失われたメディアを含む、リアルタイムメディアストリームの時間遅延バージョンを生成し、提供するように送信デバイスをトリガするリワインド要求を送信デバイスに送信する。送信デバイスは、リワインド要求に基づいてリワインドストリームを生成し、リワインドストリームを少なくとも1つのターゲットデバイスに送信する。

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

本発明の一実施形態によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。 本発明の一実施形態による、1x EV-DOネットワークの場合の無線アクセスネットワーク(RAN)と、コアネットワークのパケット交換部分との例示的な構成を示す図である。 本発明の一実施形態による、3G UMTS W-CDMA(登録商標)システム内の、RANと、汎用パケット無線サービス(GPRS)コアネットワークのパケット交換部分との例示的な構成を示す図である。 本発明の一実施形態による、3G UMTS W-CDMA(登録商標)システム内の、RANと、汎用パケット無線サービス(GPRS)コアネットワークのパケット交換部分との別の例示的な構成を示す図である。 本発明の一実施形態による、RANと、発展型パケットシステム(EPS)または長期発展型(LTE)ネットワークに基づくコアネットワークのパケット交換部分との例示的な構成を示す図である。 本発明の一実施形態による、EPSまたはLTEネットワークに接続される拡張高レートパケットデータ(enhanced High Rate Packet Data:HRPD)RANと、HRPDコアネットワークのパケット交換部分との例示的な構成を示す図である。 本発明の一実施形態による、ユーザ機器(UE)の例を示す図である。 本発明の一実施形態による、機能を実行するように構成された論理手段を含む通信デバイスを示す図である。 本発明の一実施形態による、サーバを示す図である。 アプリケーションサーバによって調停され、それにより、送信UEがメディアをターゲットUEに送達している従来のリアルタイム通信セッションを示す図である。 本発明の一実施形態による、リアルタイム通信セッションに参加し続けるために、ターゲットデバイスがリワインドストリームを要求するプロセスを示す図である。 本発明の別の実施形態による、送信デバイスがリワインド要求を受信し、リワインドストリームを選択的に生成し、ターゲットデバイスに送達するプロセスを示す図である。 本発明の一実施形態による、図7および図8のプロセスの例示的な実施態様を示す図である。 本発明の一実施形態による、図9Aのさらに詳細な実施態様例を示す図である。 本発明の一実施形態による、図9Aの代替的な実施態様例を示す図である。 本発明の別の実施形態による、図9Aのプロセスの継続を示す図である。 本発明の一実施形態による、図10Aの代替的な実施態様例を示す図である。 本発明の一実施形態による、ターゲットUEがリワインドモードにおいて動作している間に、ターゲットUEに発言権を移行するプロセスを示す図である。 本発明の一実施形態による、リアルタイム通信セッション中に交換される閉ループフィードバックのプロセスを示す図である。

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

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

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

本明細書においてユーザ機器(UE)と呼ばれるクライアントデバイスは、モバイルまたは固定とすることができ、無線アクセスネットワーク(RAN)と通信することができる。本明細書において使用されるときに、「UE」という用語は、「アクセス端末」または「AT」、「ワイヤレスデバイス」、「加入者デバイス」、「加入者端末」、「加入者局」、「ユーザ端末」またはUT、「モバイル端末」、「移動局」、およびそれらの変化形と入替え可能に呼ばれる場合がある。一般に、UEは、RANを介してコアネットワークと通信することができ、コアネットワークを通じて、UEはインターネットなどの外部ネットワークに接続することができる。当然、UEには、有線アクセスネットワーク、(たとえば、IEEE 802.11などに基づく)WiFiネットワークなど、コアネットワークおよび/またはインターネットに接続する他の機構も考えられる。UEは、限定はしないが、PCカード、コンパクトフラッシュ（登録商標）デバイス、外付けまたは内蔵のモデム、あるいはワイヤレスまたは有線の電話を含むいくつかのタイプのデバイスのうちの任意のものによって具現することができる。UEが信号をRANに送ることができる通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、逆方向制御チャネル、アクセスチャネルなど)と呼ばれる。RANが信号をUEに送ることができる通信リンクは、ダウンリンクチャネルまたは順方向リンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書において使用されるとき、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向トラフィックチャネル、またはダウンリンク/順方向トラフィックチャネルのいずれかを指すことができる。

図1は、本発明の一実施形態によるワイヤレス通信システム100のハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム100はUE1...Nを含む。UE1...Nは、セルラー電話、携帯情報端末(PDA)、ページャ、ラップトップコンピュータ、デスクトップコンピュータなどを含むことができる。たとえば、図1において、UE1...2は発呼側セルラー電話として示され、UE3...5はタッチスクリーンセルラー電話またはスマートフォンとして示され、UENはデスクトップコンピュータまたはPCとして示されている。

図1を参照すると、UE1…Nは、図1においてエアインターフェース104、106、108および/または直接有線接続として示される、物理通信インターフェースまたは層を介してアクセスネットワーク(たとえば、RAN120、アクセスポイント125など)と通信するように構成される。エアインターフェース104および106は、所与のセルラー通信プロトコル(たとえば、CDMA、EVDO、eHRPD、GSM(登録商標)、EDGE、W-CDMA(登録商標)、LTEなど)に準拠することができ、一方、エアインターフェース108はワイヤレスIPプロトコル(たとえば、IEEE 802.11)に準拠することができる。RAN120は、エアインターフェース104および106などのエアインターフェースを介してUEをサービングする複数のアクセスポイントを含む。RAN120内のアクセスポイントは、アクセスノードまたはAN、アクセスポイントまたはAP、基地局またはBS、Node B、eNode Bなどと呼ばれ得る。これらのアクセスポイントは、地上アクセスポイント(もしくは地上局)または衛星アクセスポイントとすることができる。RAN120は、RAN120によってサービングされるUEとRAN120または異なるRANによってサービングされる他のUEとの間の回線交換(CS)呼を完全にブリッジングすることを含む様々な機能を実行することができ、かつインターネット175などの外部ネットワークとのパケット交換(PS)データの交換を仲介することもできるコアネットワーク140に接続するように構成される。インターネット175は、いくつかのルーティングエージェントおよび処理エージェント(便宜上図1には示されていない)を含む。図1において、UENはインターネット175に直接接続する(すなわち、WiFiまたは802.11ベースネットワークのイーサネット(登録商標)接続を介するなど、コアネットワーク140から分離される)ように示されている。それによって、インターネット175は、コアネットワーク140を介してUENとUE1...Nとの間のパケット交換データ通信をブリッジングするように機能することができる。図1には、RAN120から分離されたアクセスポイント125も示されている。アクセスポイント125は、コアネットワーク140とは無関係に(たとえば、FiOS、ケーブルモデムなどの光通信システムを介して)インターネット175に接続される場合がある。エアインターフェース108は、一例ではIEEE 802.11などのローカルワイヤレス接続を介してUE4またはUE5をサービングすることができる。UENは、一例ではアクセスポイント125自体に対応することができるモデムまたはルータとの直接接続などの、インターネット175との有線接続を含むデスクトップコンピュータとして示されている(たとえば、有線接続性とワイヤレス接続性の両方を有するWiFiルータの場合)。

図1を参照すると、アプリケーションサーバ170は、インターネット175、コアネットワーク140、またはその両方に接続されるように示されている。アプリケーションサーバ170は、構造的に分離された複数のサーバとして実現することができるか、または代替的には単一のサーバに対応することができる。以下にさらに詳細に説明されるように、アプリケーションサーバ170は、コアネットワーク140および/またはインターネット175を介してアプリケーションサーバ170に接続することができるUEのための1つまたは複数の通信サービス(たとえば、Voice-over-Internet Protocol(VolP)セッション、Push-to-Talk(PTT)セッション、グループ通信セッション、ソーシャルネットワーキングサービスなど)をサポートするように構成される。

ワイヤレス通信システム100をさらに詳細に説明するのを助けるために、図2A〜図2Dに関して、RAN120およびコアネットワーク140のためのプロトコル特有実施態様の例が以下に提供される。詳細には、RAN120およびコアネットワーク140の構成要素は、パケット交換(PS)通信をサポートすることに関連付けられる構成要素に対応し、これらのネットワーク内にレガシー回線交換(CS)構成要素も存在することができるが、図2A〜図2Dには、いかなるレガシー回線交換(CS)構成要素も明示されていない。

図2Aは、本発明の一実施形態による、CDMA2000 1x Evolution-Data Optimized(EV-DO)ネットワークにおけるパケット交換通信のためのRAN120およびコアネットワーク140の例示的な構成を示す。図2Aを参照すると、RAN120は、有線バックホールインターフェースを介して基地局コントローラ(BSC)215Aに結合される複数の基地局(BS)200A、205Aおよび210Aを含む。単一のBSCによって制御される一群のBSはまとめてサブネットと呼ばれる。当業者によって理解されるように、RAN120は、複数のBSCおよびサブネットを含むことができ、図2Aには便宜的に単一のBSCが示される。BSC215Aは、A9接続を介してコアネットワーク140内のパケット制御機能(PCF)220Aと通信する。PCF220Aは、パケットデータに関連するBSC215Aのための特定の処理機能を実行する。PCF220Aは、A11接続を介してコアネットワーク140内のパケットデータサービングノード(PDSN)225Aと通信する。PDSN225Aは、ホームエージェント(HA)および/またはフォーリンエージェント(FA)としての役割を果たす、ポイントツーポイント(PPP)セッションを管理することを含む様々な機能を有し、GSM(登録商標)およびUMTSネットワーク内のゲートウェイ汎用パケット無線サービス(GPRS)サポートノード(GGSN)に機能的に類似である(以下にさらに詳細に説明される)。PDSN225Aは、コアネットワーク140をインターネット175のような外部IPネットワークに接続する。

図2Bは、本発明の一実施形態による、RAN120と、3G UMTS W-CDMA(登録商標)システム内のGPRSコアネットワークとして構成されるコアネットワーク140のパケット交換部分との例示的な構成を示す。図2Bを参照すると、RAN120は、有線バックホールインターフェースを介して無線ネットワークコントローラ(RNC)215Bに結合される複数のNodeB200B、205Bおよび210Bを含む。1x EV-DOネットワークと同様に、単一のRNCによって制御される一群のNodeBはまとめてサブネットと呼ばれる。RAN120が複数のRNCおよびサブネットを含むことができ、便宜的に、図2Bには単一のRNSが示されることは、当業者には理解されよう。RNC215Bは、コアネットワーク140内のサービングGRPSサポートノード(SGSN)220Bと、RAN120によってサービングされるUEとの間でシグナリングし、ベアラチャネル(すなわち、データチャネル)を確立し、解除する責任を担う。また、リンクレイヤ暗号化が可能な場合、RNC215Bは、エアインターフェースを介して送信するために、コンテンツをRAN120に転送する前に暗号化する。RNC215Bの機能は、当技術分野でよく知られており、簡潔にするためこれ以上は説明されない。

図2Bにおいて、コアネットワーク140は、先に言及されたSGSN220B(そして、潜在的にはいくつかの他のSGSN)と、GGSN225Bとを含む。一般的に、GPRSは、IPパケットをルーティングするためにGSM(登録商標)において用いられるプロトコルである。GPRSコアネットワーク(たとえば、GGSN225Bおよび1つまたは複数のSGSN220B)は、GPRSシステムの中心部分であり、W-CDMA(登録商標)ベースの3Gネットワークのためのサポートも提供する。GPRSコアネットワークは、GSM(登録商標)コアネットワーク(すなわち、コアネットワーク140)の一体化された部分であり、GSM(登録商標)およびW-CDMA(登録商標)ネットワークにおけるIPパケットサービスのためのモビリティ管理、セッション管理、およびトランスポートを提供する。

GPRSトンネリングプロトコル(GTP)は、GPRSコアネットワークを特徴付けるIPプロトコルである。GTPは、GGSN225Bにおいて、1つの場所からインターネット175に接続し続けているかのようにしながら、GSM(登録商標)またはW-CDMA(登録商標)ネットワークのエンドユーザ(たとえば、UE)が方々に移動できるようにするプロトコルである。これは、UEの現在のSGSN220Bから、それぞれのUEのセッションを処理しているGGSN225BにそれぞれのUEのデータを転送することによって達成される。

GTPの3つの形態、すなわち、(i)GTP-U、(ii)GTP-Cおよび(iii)GTP'(GTP Prime)がGPRSコアネットワークによって使用される。GTP-Uは、パケットデータプロトコル(PDP)コンテキストごとに分離されたトンネルでのユーザデータの転送に使用される。GTP-Cは、制御シグナリング(たとえば、PDPコンテキストの設定および削除、GSN到達可能性の検証、加入者があるSGSNから別のSGSNに移動した場合のような更新または変更)のために使用される。GTP'は、GSNから課金機能への課金データの転送のために使用される。

図2Bを参照すると、GGSN225Bは、GPRSバックボーンネットワーク(図示せず)とインターネット175との間のインターフェースとしての役割を果たす。GGSN225Bは、SGSN220Bから来るGPRSパケットから、関連するパケットデータプロトコル(PDP)形式(たとえば、IPまたはPPP)を有するパケットデータを抽出し、そのパケットを対応するパケットデータネットワーク上で送る。反対方向において、着信データパケットは、GGSNに接続されたUEによってSGSN220Bに向けられ、SGSN220Bは、RAN120によってサービングされるターゲットUEの無線アクセスベアラ(RAB)を管理および制御する。それによって、GGSN225Bは、ターゲットUEの現在のSGSNアドレスおよびその関連付けられるプロファイルを、そのロケーションレジスタ(たとえば、PDPコンテキスト内)に記憶する。GGSN225Bは、IPアドレス割当てを担い、接続されたUEのデフォルトのルータである。また、GGSN225Bは、認証および課金機能を実行する。

一例では、SGSN220Bは、コアネットワーク140内の多くのSGSNのうちの1つの代表である。各SGSNは、関連する地理的サービスエリア内で、UEとの間でのデータパケットを送達する責任を担う。SGSN220Bのタスクは、パケットルーティングおよび転送、モビリティ管理(たとえば、アタッチ/デタッチおよび位置管理)、論理リンク管理、ならびに認証機能および課金機能を含む。SGSN220Bのロケーションレジスタは、位置情報(たとえば、現在のセル、現在のVLR)、および、SGSN220Bに登録されたすべてのGPRSユーザのユーザプロファイル(たとえば、パケットデータネットワークにおいて使用されるIMSI、PDPアドレス)を、たとえばユーザまたはUEごとに1つまたは複数のPDPコンテキスト内に記憶する。したがって、SGSN220Bは、(i)GGSN225BからのダウンリンクGTPパケットの逆トンネリング、(ii)GGSN225Bに向かうIPパケットのアップリンクトンネリング、(iii)UEがSGSNサービスエリアの間を移動するときのモビリティ管理の実行、(iv)モバイル加入者の支払い請求の責任を担う。当業者によって理解されるように、(i)〜(iv)の他に、GSM(登録商標)/EDGEネットワークのために構成されたSGSNは、W-CDMA(登録商標)ネットワークのために構成されたSGSNと比較して、わずかに異なる機能を有する。

RAN120(たとえば、またはUMTSシステムアーキテクチャにおけるUTRANなど)は、無線アクセスネットワークアプリケーションパート(Radio Access Network Application Part:RANAP)プロトコルを介して、SGSN220Bと通信する。RANAPは、Iuインターフェース(Iu-ps)を介して、フレームリレーまたはIPなどの伝送プロトコルによって動作する。SGSN220Bは、SGSN220Bおよび他のSGSN(図示せず)と内部のGGSNとの間のIPベースのインターフェースであり、上記で規定されたGTPプロトコル(たとえば、GTP-U、GTP-C、GTP'など)を使用するGnインターフェースを介してGGSN225Bと通信する。図2Bの実施形態では、SGSN220BとGGSN225Bとの間のGnは、GTP-CとGTP-Uの両方を搬送する。図2Bには示されないが、Gnインターフェースは、ドメインネームシステム(DNS)によっても使用される。GGSN225Bは、公衆データネットワーク(PDN)(図示せず)に接続され、さらには、IPプロトコルによるGiインターフェースを介して直接、またはワイヤレスアプリケーションプロトコル(WAP)ゲートウェイを通して、インターネット175に接続される。

図2Cは、本発明の一実施形態による、RAN120と、3G UMTS W-CDMA(登録商標)システム内のGPRSコアネットワークとして構成されるコアネットワーク140のパケット交換部分との別の例示的な構成を示す。図2Bと同様に、コアネットワーク140は、SGSN220Bと、GGSN225Bとを含む。しかしながら、図2Cでは、ダイレクトトンネルは、SGSN220Bが、RAN120と、パケット交換(PS)ドメイン内のGGSN225Bとの間にダイレクトユーザプレーントンネル、GTP-Uを確立できるようにする、Iuモードにおけるオプションの機能である。図2CのSGSN220Bのようなダイレクトトンネル対応SGSNは、SGSN220Bがダイレクトユーザプレーン接続を使用できるか否かにかかわらず、GGSN単位およびRNC単位で構成され得る。図2CのSGSN220Bは、制御プレーンシグナリングを処理し、ダイレクトトンネルをいつ確立するべきか決定を行う。PDPコンテキストのために割り当てられたRABが解放される(すなわち、PDPコンテキストが保たれる)とき、ダウンリンクパケットを処理できるようにするために、GGSN225BとSGSN220Bとの間にGTP-Uトンネルが確立される。

図2Dは、本発明の一実施形態による、RAN120と、発展型パケットシステム(EPS)またはLTEネットワークに基づくコアネットワーク140のパケット交換部分との例示的な構成を示す。図2Dを参照すると、図2B〜図2Cに示されるRAN120と異なり、EPS/LTEネットワーク内のRAN120は、図2B〜図2CからのRNC215Bなしに、複数の発展型NodeB(ENodeBまたはeNB)200D、205D、および210Dを用いて構成される。これは、EPS/LTEネットワーク内のENodeBが、コアネットワーク140と通信するためにRAN120内に個別のコントローラ(すなわち、RNC215B)を必要としないためである。言い換えると、図2B〜図2CからのRNC215Bの機能のうちのいくつかは、図2C内のRAN120のそれぞれのeNodeBに組み込まれる。

図2Dにおいて、コアネットワーク140は複数のモビリティ管理エンティティ(MME)215Dおよび220Dと、ホーム加入者サーバ(HSS)225Dと、サービングゲートウェイ(S-GW)230Dと、パケットデータネットワークゲートウェイ(P-GW)235Dと、ポリシーおよび課金規則機能(PCRF)240Dとを含む。これらの構成要素と、RAN120と、インターネット175との間のネットワークインターフェースが図2Dに示されており、表1(以下)において次のように規定される。

図2DのRAN120およびコアネットワーク140に示される構成要素の概要がここで説明される。しかしながら、これらの構成要素はそれぞれ、様々な3GPP TS標準規格においてよく知られており、本明細書に含まれる説明は、これらの構成要素によって実行されるすべての機能の包括的な説明とするつもりはない。

図2Dを参照すると、MME215Dおよび220Dは、EPSベアラのための制御プレーンシグナリングを管理するように構成される。MME機能は、非アクセス層(NAS)シグナリング、NASシグナリングセキュリティ、技術間および技術内ハンドオーバのためのモビリティ管理、P-GWおよびS-GW選択、MME変更を伴うハンドオーバのためのMME選択を含む。

図2Dを参照すると、S-GW230Dは、RAN120に向かうインターフェースを終端するゲートウェイである。EPSベースシステムのためのコアネットワーク140に関連付けられるUEごとに、所与の時点において、単一のS-GWが存在する。S-GW230Dの機能は、GTPベースおよびプロキシモバイルIPv6(PMIP)ベースS5/S8の両方の場合に、モビリティアンカーポイント、パケットルーティングおよび転送、ならびに関連付けられるEPSベアラのQoSクラス識別子(QCI)に基づくDiffServコードポイントの設定を含む。

図2Dを参照すると、P-GW235Dは、パケットデータネットワーク(PDN)、たとえば、インターネット175に向かうSGiインターフェースを終端するゲートウェイである。UEが複数のPDNにアクセスしている場合には、そのUEのための2つ以上のP-GWが存在する場合があるが、S5/S8接続性およびGn/GP接続性の混在は通常、そのUEの場合に同時にサポートされない。P-GW機能は、GTPベースS5/S8の両方の場合に、パケットフィルタリング(ディープパケットインスペクションによる)、UEIPアドレス割当て、関連付けられるEPSベアラのQCIに基づくDSCP設定、事業者間課金のためのアカウンティング、3GPP TS 23.203において規定されるアップリンク(UL)およびダウンリンク(DL)ベアラバインディング、3GPP TS 23.203において規定されるULベアラバインディング検証を含む。P-GW235Dは、E-UTRAN、GERANまたはUTRANのいずれかを用いて、GSM(登録商標)/EDGE無線アクセスネットワーク(GERAN)/UTRANのみのUEおよびE-UTRAN対応UEの両方にPDN接続性を提供する。P-GW235Dは、S5/S8インターフェースを介して、E-UTRANのみを用いてE-UTRAN対応UEにPDN接続性を提供する。

図2Dを参照すると、PCRF240Dは、EPSベースコアネットワーク140のポリシーおよび課金制御要素である。非ローミングシナリオでは、UEのインターネットプロトコル接続性アクセスネットワーク(IP-CAN)セッションに関連付けられるHPLMN内に単一のPCRFが存在する。PCRFは、RxインターフェースおよびGxインターフェースを終端する。ローミングシナリオでは、トラフィックのローカルブレイクアウトに伴って、UEのIP-CANセッションに関連付けられる2つのPCRFが存在する場合がある。ホームPCRF(H-PCRF)は、HPLMN内に存在するPCRFであり、ビジテッドPCRFは、訪問先VPLMN内に存在するPCRFである。PCRFは、3GPP TS 23.203内にさらに詳細に説明されており、したがって、簡潔のためにさらに説明されない。図2Dでは、アプリケーションサーバ170(たとえば、3GPP用語ではAFと呼ぶことができる)は、インターネット175を介してコアネットワーク140に、または代替的にはRxインターフェースを介して直接PCRF240Dに接続されるように示される。一般的に、アプリケーションサーバ170(またはAF)は、コアネットワークとともにIPベアラリソース(たとえば、UMTS PSドメイン/GPRSドメインリソース/LTE PSデータサービス)を用いてアプリケーションを提供する要素である。アプリケーション機能の一例は、IPマルチメディアサブシステム(IMS)コアネットワークサブシステムのプロキシコールセッション制御機能(P-CSCF)である。AFはRX基準点を用いて、PCRF240Dにセッション情報を提供する。セルラーネットワークを介してIPデータサービスを提供する任意の他のアプリケーションサーバも、RX基準点を介してPCRF240Dに接続することができる。

図2Eは、本発明の一実施形態による、EPSまたはLTEネットワーク140Aに接続される拡張高レートパケットデータ(HRPD)RANとして構成されるRAN120と、HRPDコアネットワーク140Bのパケット交換部分との一例を示す。コアネットワーク140Aは、図2Dに関して先に説明されたコアネットワークに類似のEPSまたはLTEコアネットワークである。

図2Eにおいて、eHRPD RANは複数のトランシーバ基地局(BTS)200E、205Eおよび210Eを含み、それらのトランシーバ基地局は、拡張BSC(eBSC)および拡張PCF(ePCF)215Eに接続される。eBSC/ePCF215Eは、S101インターフェースを介してEPSコアネットワーク140A内のMME215Dまたは220Dのうちの1つに接続することができ、EPSコアネットワーク140A内の他のエンティティとのインターフェースを構成するためのA10および/またはA11インターフェースを介してHRPDサービングゲートウェイ(HSGW)220Eに(たとえば、S103インターフェースを介してS-GW220Dに、S2aインターフェースを介してP-GW235Dに、Gxaインターフェースを介してPCRF240Dに、STaインターフェースを介して3GPP AAAサーバに(図2Dには明示されない)など)接続することができる。HSGW220Eは、HRPDネットワークとEPS/LTEネットワークとの間のネットワーキングを提供するために3GPP2において規定される。理解されるように、eHRPD RANおよびHSGW220Eは、レガシーHRPDネットワークにおいて利用できないEPC/LTEネットワークへのインターフェース機能によって構成される。

eHRPD RANに戻ると、EPS/LTEコアネットワーク140Aとのインターフェースを構成することに加えて、eHRPD RANは、HRPDネットワーク140BのようなレガシーHRPDネットワークとのインターフェースも構成することができる。理解されるように、HRPDネットワーク140Bは、図2AからのEV-DOネットワークのような、レガシーHRPDネットワークの例示的な実施態様である。たとえば、eBSC/ePCF 215Eは、A12インターフェースを介して認証許可アカウンティング(AAA)サーバ225Eとのインターフェースを構成することができるか、またはA10もしくはA11インターフェースを介してPDSN/FA 230Eとのインターフェースを構成することができる。PDSN/FA 230EはさらにHA235Aに接続し、それを通して、インターネット175がアクセスされ得る。図2Eにおいて、いくつかのインターフェース(たとえば、A13、A16、H1、H2など)は明確に説明されないが、完全を期すために示されており、HRPDまたはeHRPDに通じている当業者によって理解される。

図2B〜図2Eを参照すると、LTEコアネットワーク(たとえば、図2D)およびeHRPD RANおよびHSGW(たとえば、図2E)とのインターフェースを構成するHRPDコアネットワークは、場合によって、ネットワーク開始サービス品質(QoS)をサポートすることができる(たとえば、P-GW、GGSN、SGSNなどによる)。

図3は、本発明の一実施形態によるUEの例を示す。図3を参照すると、UE300Aは発呼側電話として示され、UE300Bはタッチスクリーンデバイス(たとえば、スマートフォン、タブレットコンピュータなど)として示されている。図3に示されるように、UE300Aの外部ケーシングは、当技術分野で知られているように、数ある構成要素の中でも、アンテナ305A、ディスプレイ310A、少なくとも1つのボタン315A(たとえば、PTTボタン、電源ボタン、音量調節ボタンなど)、キーパッド320Aなどで構成される。また、UE300Bの外部ケーシングは、数ある構成要素の中でも、当技術分野で知られているように、タッチスクリーンディスプレイ305B、周辺ボタン310B、315B、320B、および325B(たとえば、電力調節ボタン、音量または振動調節ボタン、飛行機モードトグルボタンなど)、少なくとも1つのフロントパネルボタン330B(たとえば、Homeボタン)などで構成される。UE300Bの一部として明示的に示されてはいないが、UE300Bは、限定はしないが、WiFiアンテナ、セルラーアンテナ、衛星位置システム(SPS)アンテナ(たとえば、全地球測位システム(GPS)アンテナ)などを含む、1つまたは複数の外部アンテナおよび/またはUE300Bの外部ケーシングに内蔵される1つのまたは複数の内蔵アンテナを含むことができる。

UE300AおよびUE300BなどのUEの内部構成要素は、それぞれに異なるハードウェア構成によって具現することができるが、内部ハードウェア構成要素のための基本的なハイレベルUE構成は図3にプラットフォーム302として示されている。プラットフォーム302は、最終的にコアネットワーク140、インターネット175、および/または他のリモートサーバおよびネットワーク(たとえば、アプリケーションサーバ170、ウェブURLなど)から得ることのできるRAN120から送信されたソフトウェアアプリケーション、データ、および/またはコマンドを受信し実行することができる。プラットフォーム302は、RANとやりとりすることなく、ローカルに記憶されたアプリケーションを独立して実行することができる。プラットフォーム302は、特定用途向け集積回路(「ASIC」308)または他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合された送受信機306を含むことができる。ASIC308または他のプロセッサは、ワイヤレスデバイスのメモリ312中の任意の常駐プログラムとインターフェースを構成するアプリケーションプログラミングインターフェース(「API」)310レイヤを実行する。メモリ312は、読取り専用メモリもしくはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通する任意のメモリから構成することができる。プラットフォーム302は、メモリ312中でアクティブに使用されないアプリケーション、および他のデータを記憶することができるローカルデータベース314も含むことができる。ローカルデータベース314は、一般的にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。

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

UE300Aおよび/またはUE300BとRAN120との間のワイヤレス通信は、たとえばCDMA、W-CDMA(登録商標)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元(OFDM)、GSM(登録商標)、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用され得る他のプロトコルのような、様々な技術に基づくことができる。先に論じられ、当技術分野で知られているように、音声送信、および/またはデータは、様々なネットワークおよび構成を使用してRANからUEに送信され得る。したがって、本明細書において提供される例は、本発明の実施形態を限定するためのものではなく、単に本発明の実施形態の態様の説明を助けるためのものにすぎない。

図4は、機能を実行するように構成された論理手段を含む通信デバイス400を示す。通信デバイス400は、限定はしないが、UE300Aもしくは300B、RAN120の任意の構成要素(たとえば、BS200A〜210A、BSC 215A、NodeB200B〜210B、RNC 215B、eNodeB 200D〜210Dなど)、コアネットワーク140の任意の構成要素(PCF 220A、PDSN 225A、SGSN 220B、GGSN 225B、MME 215Dまたは220D、HSS 225D、S-GW 230D、P-GW 235D、PCRF 240D)、コアネットワーク140および/またはインターネット175に結合される任意の構成要素(たとえば、アプリケーションサーバ170)などを含む、先に言及された通信デバイスのいずれかに対応することができる。したがって、通信デバイス400は、図1のワイヤレス通信システム100を介して1つまたは複数の他のエンティティと通信する(または通信を容易にする)ように構成された任意の電子デバイスに対応することができる。

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

図4を参照すると、通信デバイス400は、情報を処理するように構成された論理手段410をさらに含む。一例では、情報を処理するように構成された論理手段410は、少なくともプロセッサを含むことができる。情報を処理するように構成された論理手段410によって実行され得るタイプの処理の例示的な実施態様は、限定はしないが、判断を行うこと、接続を確立すること、異なる情報オプション間で選択を行うこと、データに関係する評価を行うこと、測定演算を実行するために通信デバイス400に結合されたセンサとやりとりすること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviへなど、異なるプロトコル間で)変換することなどを含む。たとえば、情報を処理するように構成された論理手段410中に含まれるプロセッサは、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、ASIC、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタロジック、個別ハードウェア構成要素、あるいは本明細書において説明される機能を実行するように設計されたそれらの任意の組合せに対応することができる。汎用プロセッサはマイクロプロセッサとすることができるが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることができる。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実現され得る。情報を処理するように構成された論理手段410は、実行されるときに、情報を処理するように構成された論理手段410の関連ハードウェアがその処理機能を実行できるようにする、ソフトウェアも含むことができる。しかしながら、情報を処理するように構成された論理手段410は、ソフトウェア単体に対応するのではなく、情報を処理するように構成された論理手段410は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

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

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

図4を参照すると、通信デバイス400は、場合によっては、ローカルユーザ入力を受信するように構成された論理手段425をさらに含む。一例では、ローカルユーザ入力を受信するように構成された論理手段425は、少なくともユーザ入力デバイスおよび関連ハードウェアを含むことができる。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、またはマイクロフォンジャックなど、オーディオ情報を搬送することができるポートなど)、および/または情報がそれによって通信デバイス400のユーザもしくは操作者から受信され得る任意の他のデバイスを含むことができる。たとえば、通信デバイス400が図3に示されるようなUE300AまたはUE300Bに対応する場合には、ローカルユーザ入力を受信するように構成された論理手段425は、キーパッド320A、ボタン315Aまたは310B〜325Bのうちのいずれか、タッチスクリーンディスプレイ305Bを含むことができる。さらなる例では、ローカルユーザ入力を受信するように構成された論理手段425は、(たとえば、ネットワークスイッチ、またはルータ、リモートサーバなど)ローカルユーザを有しないネットワーク通信デバイスのようないくつかの通信デバイスでは省略されることがある。ローカルユーザ入力を受信するように構成された論理手段425は、実行されるときに、ローカルユーザ入力を受信するように構成された論理手段425の関連ハードウェアがその入力受信機能を実行できるようにする、ソフトウェアも含むことができる。しかしながら、ローカルユーザ入力を受信するように構成された論理手段425は、ソフトウェア単体に対応するのではなく、ローカルユーザ入力を受信するように構成された論理手段425は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。

図4を参照すると、405〜425の構成された論理手段は、図4では別個のまたは相異なるブロックとして示されているが、それぞれの構成された論理手段がその機能を実行するためのハードウェアおよび/またはソフトウェアは、部分的に重複し得ることは理解されよう。たとえば、405〜425の構成された論理手段の機能を容易にするために使用されるいずれのソフトウェアも、情報を記憶するように構成された論理手段415に関連する非一時的メモリに記憶することができ、そうすることによって、405〜425の構成された論理手段はそれぞれ、その機能(すなわち、この場合、ソフトウェア実行)を、情報を記憶するように構成された論理手段415によって記憶されたソフトウェアの動作に部分的に基づいて実行する。同様に、構成された論理手段のうちの1つに直接関連付けられたハードウェアは、時々、他の構成された論理によって借用または使用され得る。たとえば、情報を処理するように構成された論理手段410のプロセッサは、データを、情報を受信および/または送信するように構成された論理手段405によって送信される前に、適切な形式にフォーマットすることができるので、情報を受信および/または送信するように構成された論理手段405は、その機能(すなわち、この場合、データの送信)を、情報を処理するように構成された論理手段410に関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実行する。

概して、別段に明示的に記載されていない限り、本開示全体にわたって使用される「ように構成された論理手段」という句は、ハードウェアにより少なくとも部分的に実施される実施形態を引き合いに出すものとし、ハードウェアから独立したソフトウェアだけの実施形態に位置づけるものではない。様々なブロックにおける構成された論理手段または「ように構成された論理手段」は、特定の論理ゲートまたは論理要素に限定されるのではなく、概して、本明細書に記載した機能性を、(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実施するための能力を指すことは理解されよう。したがって、様々なブロックに示す構成された論理手段または「ように構成された論理手段」は、「論理(ロジック)」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実現されるとは限らない。様々なブロックの論理手段間の他のやりとりまたは協働が、以下でより詳細に説明する実施形態の検討から、当業者には明らかになるであろう。

様々な実施形態は、図5に示されたサーバ500などの、様々な市販のサーバデバイスのいずれかにおいて実現することができる。一例では、サーバ500は、上記のアプリケーションサーバ170の一例の構成に対応することができる。図5において、サーバ500は、揮発性メモリ502と、ディスクドライブ503のような大容量の不揮発性メモリとに結合された、プロセッサ501を含む。サーバ500はまた、プロセッサ501に結合された、フロッピー(登録商標)ディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ506を含むことができる。サーバ500はまた、他のブロードキャストシステムコンピュータおよびサーバに、またはインターネットに結合されたローカルエリアネットワークなど、ネットワーク507とデータ接続を確立するための、プロセッサ501に結合されたネットワークアクセスポート504も含むことができる。図4との関連で、図5のサーバ500は、通信デバイス400の一例の実施態様を示しており、それにより、情報を送信および/または受信するように構成された論理手段405は、ネットワーク507と通信するためにサーバ500によって用いられるネットワークアクセスポート504に対応し、情報を処理するように構成された論理手段410はプロセッサ501に対応し、情報を記憶するように構成された論理手段415は、揮発性メモリ502、ディスクドライブ503および/またはディスクドライブ506の任意の組合せに対応する。情報を提示するように構成されたオプションの論理手段420およびローカルユーザ入力を受信するように構成されたオプションの論理手段425は、図5には明示的に示されず、そこに含まれる場合も、含まれない場合もある。したがって、図5は、図3の場合のような305Aまたは305BのようなUEの実施態様に加えて、通信デバイス400がサーバとして実現できることを実証するのを助ける。

上記の通信プロトコル(たとえば、EV-DO、W-CDMA、LTE、eHRPDなど)ではいずれも、ユーザ機器(UE)が他のUEとの通信セッションに参加することができ、その通信セッションによって、メディア(たとえば、オーディオメディア、ビデオメディアなど)が「リアルタイムに」交換され、再生される。リアルタイム通信セッションでは、メディアの価値は、時間(たとえば、ほんの10分の数秒)が経過すると、急激に低下する。たとえば、通話中に受信されたオーディオパケットに含まれるオーディオデータ(たとえば、1つまたは複数のオーディオフレーム)は通常、ターゲットUEによって受信された後に、比較的直ちに(たとえば、100ms〜200ms)で再生される必要があり、そうでないと、そのオーディオデータは、その通話との関連性を失う。また、オーディオパケットが通話中に失われた場合には、失われたオーディオパケットを再び入手するのに(たとえば、話者から、または通話のためのオーディオパケットをアーカイブするサーバから)比較的に長い時間(たとえば、数秒)を要する可能性がある。リアルタイム通信セッション中のパケット損失を軽減するために、順方向誤り訂正(FER)またはインターリービングのような機構が使用される。

しかしながら、リアルタイム通信セッション中にターゲットUEのメディアにおいて比較的長い供給停止が生じる(たとえば、ターゲットUEが8秒間、トンネル内を走行し、その期間中に送信されたすべてのメディアパケットを失う)場合には、一般的に、リアルタイム通信セッションへの能動的な参加も保持しながら、供給停止中に失われたメディアパケットを復元することに関するターゲットUEのためのリソースはほとんどない。いくつかのシステムはリアルタイム通信セッションを記録またはアーカイブするように設定され、その場合、ターゲットUEは後に、アーカイブされたセッションから、失われた部分に同調しようと試みることができるが、これは一般に、リアルタイム通信セッションが進行中に都合良く実施することはできない。

図6は、アプリケーションサーバ170によって調停され、それにより、UE1がメディア(たとえば、オーディオメディア、ビデオメディアなど)をUE2に送達している従来のリアルタイム通信セッションを示す。図6がUE1からUE2への一方向メディアパケットのフローに焦点を合わせる場合であっても、図6のリアルタイム通信セッションは半二重または全二重とすることができる。一例では、図6のリアルタイム通信セッションは、リアルタイムトランスポートプロトコル(RTP)オーバー(over)ユーザデータグラムプロトコル(UDP)セッションに対応することができ、それにより、メディア(たとえば、オーディオメディア、ビデオメディアなど)は、少なくとも1つのメディアフレームをそれぞれ含むRTPパケット内に含まれる。

図6を参照すると、リアルタイム通信セッション中に、UE1はメディアを取り込む、600。600におけるメディア取込みは、UE1の操作者の発話のようなオーディオデータを取り込むオーディオ記録デバイス(たとえば、マイクロフォン)、および/またはUE1の環境のビデオデータを取り込むビデオ記録デバイス(たとえば、カメラ)に対応することができる。UE1は、取り込まれたメディアを1組のメディアパケット内にバッファリングする、605。取り込まれ、バッファリングされたメディアが、リアルタイムメディアストリームとして、アプリケーションサーバ170を介してUE2に送信される、610。特定のメディアがUE1によって送信された後に、送信されたメディアはUE1のバッファから除去される、620。625において、UE2は、リアルタイムメディアストリームを受信し、バッファリングし、再生する。

リアルタイム通信セッション中のある時点で、UE2は著しい時間的空白(たとえば、1秒、2秒、7秒など)を検出すると仮定し、時間的空白では、リアルタイム通信セッションのためのリアルタイムメディアストリームのために使用可能なメディアパケットがまったく、またはほとんどUE2に到着するのに成功しない(たとえば、UE1またはUE2における干渉またはチャネル条件不良、バックホール接続不良などに起因する)、630。リアルタイム通信セッションへのUE2の参加が継続できるか否か(すなわち、空白が終わっているか否か)を判断するために、UE2は、635において、リアルタイムメディアストリームのための任意の到来するメディアパケットを復号しようと試み続ける。UE2が635においてリアルタイムメディアストリームに再び同調できる場合には、プロセスは625に戻り、UE2はリアルタイムメディアストリームのためのプレイバックを再開する。この場合、630において検出された時間的空白からの任意の使用できないか、または送達されないメディアパケットは復元されず、UE2においてまったく再生されない。そうでなく、UE2が635においてリアルタイムメディアストリームに再び同調できない場合には、UE2は、リアルタイム通信セッションへの参加を終了する、640。

本発明の実施形態は、セッション中に少なくとも1つのターゲットデバイスのためのリアルタイム通信セッションを時間的にリワインドすることに向けられる。このようにして、リアルタイム通信セッションをリワインドすることによって、セッションのかなりの部分を失うユーザが、失われたセッション部分の少なくとも一部を復元することができる。

図7は、本発明の一実施形態による、リアルタイム通信セッションに参加し続けるために、ターゲットデバイスがリワインドストリームを要求するプロセスを示す。図7のプロセスを実行するターゲットデバイスは、(i)リアルタイム通信セッションに参加しているターゲットUEに、または(ii)リアルタイム通信セッションを調停し、および/または仲介するアプリケーションサーバ170に対応することができる。

図7を参照すると、ターゲットデバイスは、送信デバイスからリアルタイム通信セッションのためのリアルタイムメディアストリームを受信する、700。ターゲットデバイスがアプリケーションサーバ170に対応する場合には、ターゲットデバイスはまた、700において、少なくとも1つのターゲットUEにリアルタイムメディアストリームを送達する。代替的には、ターゲットデバイスがターゲットUEに対応する場合には、ターゲットデバイスはまた、700においてリアルタイムメディアストリームを再生する。また、ターゲットデバイスがアプリケーションサーバ170に対応する場合には、送信デバイスは送信UEに対応する。代替的には、ターゲットデバイスがターゲットUEに対応する場合には、送信デバイスは送信UE(すなわち、リアルタイムメディアストリームの発信源)か、またはアプリケーションサーバ170(すなわち、送信UEの代わりにリアルタイムメディアストリームを転送する)に対応することができる。

リアルタイム通信セッション中のある時点で、ターゲットデバイスはメディア受信空白を検出する、705。本明細書において用いられるときに、705において検出されるメッセージ受信空白は、図6の630と同様に、ターゲットデバイスに到着するのに成功するリアルタイム通信セッションのためのリアルタイムメディアストリームのために使用可能なメディアパケットがしきい値数(たとえば、1、3など)未満である時間的空白(たとえば、1秒、2秒、7秒など)に対応することができる(たとえば、干渉またはチャネル条件不良、バックホール接続不良などのネットワーク条件の低下に起因する)。代替的には、705において検出されるメディア受信空白は、リアルタイム通信セッションのための使用可能なメディアパケットのしきい値数がターゲットデバイスに到着するのに成功するが、ターゲットデバイスにおける条件がプレイバックを妨げる時間的空白に対応することができる。たとえば、ターゲットデバイスのユーザが、再生されてもユーザがオーディオメディアを聞くことを期待されない騒々しい環境内を歩行しており、ターゲットデバイスのユーザは、ある時間にわたって、ターゲットデバイス自体から離れて歩行している。さらに別の代替形態では、メディア受信空白は、ターゲットUEのユーザがセッションをリワインドしたいという明示的な指示に基づいて、705において検出することができる。この場合、ターゲットデバイスは、リアルタイムメディアストリームが正確に再生されていたことを記録している場合があるが、それでも、何らかの理由で、ユーザが数秒だけセッションをリワインドすることを望む(たとえば、聞き逃した重要な文を復元するため、など)。それにより、メディア受信空白は、705において、デバイスによって検出され得るか、またはユーザによって検出され得る。

710において、ターゲットデバイスは、メディア受信空白の持続時間がしきい値を超えるか否かを判断する。ターゲットデバイスが、710においてメディア受信空白の持続時間がしきい値をまだ超えていないと判断する場合には、ターゲットデバイスは、メディア受信空白の持続時間を追跡し続けながら、710においてリアルタイムメディアストリームのための任意の到来するメディアパケットを復号しようと試みる。図7には示されないが、しきい値を超える前にメディア受信空白が終了する場合には、リアルタイム通信セッションは、リワインドすることなく、700において再開することができる。代替的には、ターゲットデバイスが、710においてメディア受信空白の持続時間がしきい値を超えると判断する場合には、ターゲットデバイスは、送信デバイスがリアルタイム通信セッションをリワインドすることを要求するリワインド要求を生成し、送信デバイスに送信する、715。

図7の715を参照すると、715において送信されるリワインド要求は、暗黙的、または明示的のいずれかとすることができる。「明示的な」リワインド要求は、ターゲットデバイスへのリワインドストリームを生成し、送達するように送信デバイスをトリガすることを意図して、ターゲットデバイスによって送信デバイスに送信されるメッセージに対応する。「暗黙的な」リワインド要求は、ターゲットデバイスへのリワインドストリームを生成し、送達するように送信デバイスをトリガするための役割を果たすことができる明示的なリワインド要求以外の任意のデータに対応する。たとえば、明示的なリワインド要求は、送信デバイスがリアルタイムメディアストリームから4秒のリワインド(または遅延時間)を伴ってリワインドストリームを送達することへの、ターゲットデバイスによる要求に対応することができるのに対して、暗黙的なリワインド要求は、送信デバイスが4秒のリワインドを伴うリワインドストリームを送達することを実際に要求することなく、ターゲットデバイスが4秒のメディア受信空白を被ったことを送信デバイスに単に通知することができる。以下の実施形態では、図9A〜図11は、暗黙的または明示的いずれかとすることができるリワインド要求の例を包括的に示し、図12は、暗黙的なリワインド要求のために具体的に使用され得るデータフィードバックに焦点を合わせる。

たとえば、明示的なリワインド要求は、リアルタイム通信セッションが指定された時間だけリワインドされることを要求するように構成することができる。たとえば、リワインド要求が715において送信されるときにメディア受信空白が3秒の長さである場合には、リワインド要求は3秒のリワインドを要求することができる。代替的には、応答時間に関する遅延を考慮するために、リワインド要求は、現在のメディア受信空白より長いリワインドを要求するように構成することができる(たとえば、メディア受信空白が3秒である場合には、2秒だけオフセットし、5秒のリワインドを要求する)。別の代替形態では、「暗黙的な」リワインド要求は、送信デバイスにリワインドの程度を独立して決定するように促すために、現在のメディア受信空白を指示するように構成することができる(たとえば、ターゲットデバイスは3秒のメディア受信空白を報告することができ、送信デバイスは、この情報に基づいてリワインドのための適切な時間を特定するように期待される)。

リワインド要求(暗黙的、明示的いずれか)は、要求されるリワインドストリームがリアルタイムメディアストリームの代わりに、またはリアルタイムメディアストリームに加えて提供されることを要求するように構成することができる。たとえば、ターゲットデバイスは、メディア受信空白に起因してリワインドストリームを望む場合があるが、リアルタイムメディアストリームを失うことを実際に望まない場合があり、それは、リワインドストリームおよびリアルタイムメディアストリームの両方がターゲットデバイスに同時に提供されることを要求するようにリワインド要求に促すことになる。代替的には、帯域幅制約または他の考慮すべき事柄に起因して、ターゲットデバイスは、ある時間にわたってリワインドストリームのみがターゲットデバイスに与えられるように、リアルタイムメディアストリームからリワインドストリームに切り替えることを望む場合がある。この場合、リワインドストリームは、その時間中にリアルタイムメディアストリームに取って代わることになる。

715においてリワインド要求を送信した後に、ターゲットデバイスは、要求されたリワインドストリームを待ちながら、メディア受信空白の持続時間を追跡し続ける、720。720において、リワインドストリームが受信されない場合には、710において別のしきい値時間が経過したと判断された後に、ターゲットデバイスは、より長いリワインドを要求する別のリワインド要求を生成し、送信する、715、などとなる。図7には示されないが、最終的には、メディア受信空白が長くなるので、ターゲットデバイスがリワインド要求を単に断念することができる(たとえば、10秒のリワインド上限を強制することができる、など)。これが生じる場合、ターゲットデバイスは単に、可能なら、リアルタイム通信セッションへの参加を継続することをリアルタイムに試みる。

そうでなく、720においてリワインドストリームが検出された場合には、725においてターゲットデバイスはリワインドストリームを受信する。725において受信されたリワインドストリームは、715からの要求されたリワインドストリームのうちの1つに、または異なるリワインドストリームに対応することができる(たとえば、後にさらに詳細に論じられる、送信デバイスがターゲットデバイスに対して異なるリワインド持続時間を選択する場合)。先に論じられたように、725において受信されたリワインドストリームは、リアルタイムメディアストリームの代わりに、またはリアルタイムメディアストリームに加えて受信することができる。

730において、ターゲットデバイスはオプションで、リワインドストリームのためのキャッチアッププロトコルを実行する。キャッチアッププロトコルは、リアルタイムメディアストリームに追い付く(または合流する)ために、ターゲットデバイスがリワインドストリームを時間的に進めようと試みることができる任意の機構に対応する。キャッチアッププロトコルの例は、高速転送プロトコル(たとえば、リアルタイムメディアストリームより高い速度において再生されるようにリワインドストリームをフォーマットする)、特定のメディアフレームがリワインドストリームから外されるようにするフレームスキッププロトコル(たとえば、1/8フレームスキップする、半二重セッションの場合の発言権保有者移行のような、有益なメディアに関連付けられないと予想されるイベントに近いメディアフレームをスキップする)、リワインドストリームに含まれるデータを解析し、(可能なら)任意のオーディオデータをテキストに変換して、オーディオを出力する代わりにユーザにテキストを表示すること(「オーディオキャプショニング」)などを含む。通信セッションのためのオーディオをキャプショニングする方法の例が、2013年3月12日に出願されたKergerらによる「OUTPUT MANAGEMENT FOR PRESS-TO-TRANSMIT COMMUNICATIONS」と題する米国特許出願第13/796,455号、および2013年3月12日に出願されたKergerらによる「OUTPUT MANAGEMENT FOR ELECTRONIC COMMUNICATIONS」と題する米国特許出願第13/796,561号においてさらに詳細に説明されており、それぞれ参照により全体が本明細書に組み込まれる。

キャッチアッププロトコルは、ターゲットデバイスにおいて直接実行することができるか、または送信デバイスにおいて実行することができる。たとえば、ターゲットデバイスが、リワインドストリームを再生しているターゲットUEに対応する場合には、ターゲットUEは、たとえば、1/8フレームまたは他の関連性の低いフレームを独立してスキップすることができる、リワインドプレイバックのための音声テキスト変換を実行することができる、などである。別の例では、ターゲットデバイスが、リワインドストリームを再生しているターゲットUEに対応する場合には、ターゲットUE(またはそのユーザ)が、送信デバイスに、特定のキャッチアッププロトコルを実行したいという意向を指示することができる。別の例では、ターゲットデバイスが、ターゲットUEにリワインドストリームを送達しているアプリケーションサーバ170に対応する場合には、アプリケーションサーバ170は、キャッチアッププロトコルを実行したいという意向に関するターゲットUEからの指示を受信し、その意向を送信UEに中継することができるか、またはアプリケーションサーバ170自体においてキャッチアッププロトコルを実施することができる。代替的には、キャッチアッププロトコルは、送信デバイスにキャッチアッププロトコルを実行したいという意向を伝達することなく、デフォルトで送信デバイスにおいて実行することができる(たとえば、送信デバイスは、ターゲットデバイスからの要求を用いることなく、高速転送モードにおいて動作するようにリワインドストリームを自律的に設定する、など)。

図7の730を参照すると、キャッチアッププロトコルを使用するオプションは、一例において、ターゲットデバイスにおけるバッファサイズに基づくことができる。たとえば、725におけるリワインドストリームのための時間遅延が、ターゲットデバイスのバッファ内の空き領域の量より短い時間である場合には、失われた一瞬のみがリワインドされる必要があり、送信デバイスは「リアルタイム」の一瞬をリアルタイムに送信し続けることができ、ターゲットデバイスはリワインドストリームおよび進行中のリアルタイムメディアストリームの両方を受け入れる余裕があるので、「追い付くこと」は必要とされない。しかしながら、725におけるリワインドストリームのため時間遅延が、ターゲットデバイスのバッファの空き領域の量より長い時間の場合には、リアルタイムメディアストリームとともにリワインドストリームが送信されたなら、バッファがオーバーフローすることになる。この場合、730においてキャッチアッププロトコルを用いて、デバイスをリアルタイムにシフトバックすることができる。

735において、ターゲットデバイスは、リワインドストリームがリアルタイムメディアストリームに追い付いたか否かを判断する。追い付いていない場合、プロセスは725に戻る。735において、ターゲットデバイスが、リワインドストリームがリアルタイムメディアストリームに追い付いたと判断すると、プロセスは700に戻り、ターゲットデバイスはリアルタイム通信セッションへの参加をリアルタイムに再開する。この時点で、リワインドストリームを破棄することができるが、リワインドストリームは、リワインドモードにおいて依然として動作している(または動作をサポートしている)他のデバイスに別々に送達され続けることができる。

図8は、本発明の別の実施形態による、送信デバイスがリワインド要求を受信し、リワインドストリームを選択的に生成し、ターゲットデバイスに送達するプロセスを示す。図8のプロセスを実行する送信デバイスは、(i)リアルタイム通信セッションのためのリアルタイムメディアストリームを発信する送信UEに、または(ii)リアルタイム通信セッションを調停し、および/または仲介するアプリケーションサーバ170に対応することができる。

図8を参照すると、送信デバイスは、リアルタイム通信セッションのためのリアルタイムメディアストリームをターゲットデバイスに送信する、800。送信デバイスがアプリケーションサーバ170に対応する場合には、送信デバイスは800において少なくとも1つのターゲットUEにリアルタイムメディアストリームを送信する。代替的には、送信デバイスが送信UEに対応する場合には、送信デバイスは、800において、少なくとも1つのターゲットUEに送達するためのリアルタイムメディアストリームをアプリケーションサーバ170に送信する。

図8を参照すると、送信デバイスは805においてターゲットデバイスから1つまたは複数のリワインド要求を受信する。たとえば、1つまたは複数のリワインド要求は、図7の715においてターゲットデバイスによって送信される1つまたは複数のリワインド要求に対応することができる。図7の715に関して先に論じられたように、1つまたは複数のリワインド要求は、暗黙的、明示的いずれかのリワインド要求に対応することができる。送信デバイスは、805からの受信されたリワインド要求に基づいて、ターゲットデバイスに送達するためのリワインドストリームを生成する。一例では、送信デバイスは805において受信されたリワインド要求のうちの1つに単に応じることができる(たとえば、リワインド要求が7秒のリワインドを要求し、810において生成されるリワインドストリームはリアルタイムメディアストリームから7秒の遅延またはリワインドを割り振られる)。別の例では、送信デバイスは、リワインド要求のいずれかによって要求されるのとはわずかに異なるリワインド持続時間を割り振ることができる(たとえば、ターゲットデバイスは7秒のリワインドを要求するが、送信デバイスは、ターゲットデバイスが処理リソースおよびシステムリソースの両方を保存するために、6秒遅延したリワインドストリームを与えられるように、送信デバイスは3つの他のターゲットデバイスに6秒遅延したリワインドストリームをすでに与えている)。別の例では、ターゲットリワインド持続時間またはリワインド遅延は、送信デバイスによって自律的に決定することができるか、または代替的にはユーザが制御することができる。たとえば、送信デバイスの操作者に、805からのリワインド要求を通知することができ、操作者自身が、リワインド要求のうちの1つに同意することができか、またはターゲットデバイスのための異なるリワインド遅延を許可することができる。この例のための使用事例は、送信UEを操作している教授が、ターゲットUEを操作している100人の学生のクラスに講義している場合である。異なる学生が異なるリワインド遅延を要求している場合があり、教授の送信UEに数多くのリワインド要求が到着する場合には、教授は単に、困惑した学生が追い付くことができるように、20秒〜30秒だけ(要求されたリワインド遅延に関係なく)すべてのターゲットデバイスのためのセッション全体をリワインドすることを選ぶことができる。

810においてリワインドストリームを生成した後に、送信デバイスはターゲットデバイスにリワインドストリームを送信する、815。また、815において、送信デバイスはオプションで、ターゲットデバイスにリアルタイムメディアストリームを送信し続ける。たとえば、805からのリワインド要求は、リワインドストリームおよびリアルタイムメディアストリームの両方の並列送達を要求するように構成することができるか、または代替的には、805からのリワインド要求は、リアルタイムメディアストリームに時間的に取って代わるように、リワインドストリームのみが送達されることを要求するように構成することができる。代替的には、リワインド要求は、リアルタイムメディアストリームがターゲットデバイスに送達され続けるべきであるか否かを指定することはできず、送信デバイス自体がこの決定を行うことができる。たとえば、リワインドストリームがリアルタイムメディアストリームから比較的短い時間(たとえば、しきい値時間未満)だけ遅れる場合には、ターゲットデバイスが比較的迅速にリアルタイムに追い付くことができる可能性が高いので、ターゲットデバイスに、リワインドストリームに加えてリアルタイムメディアストリームを送達することができる。同様に、リワインドストリームがリアルタイムメディアストリームから比較的長い時間(たとえば、少なくともしきい値時間)だけ遅れる場合には、ターゲットデバイスがリアルタイムに追い付くのに比較的長い時間を要する可能性が高いので、ターゲットデバイスにリアルタイムメディアストリームを送達するのを一時的に中止することができる。820において、送信デバイスはオプションで、図7の730と同様に、リワインドストリームのためのキャッチアッププロトコルを実行する(たとえば、高速転送、1/8フレームもしくは発言権保有者移行をスキップする、オーディオの代わりにオーディオキャプショニングを与える、この場合、メディア受信空白からのテキストを読みながら、ターゲットUEがリアルタイムオーディオを聴取することができるように、ターゲットデバイスにリアルタイムメディアストリームも与えることができる、など)。図7の730に関して先に論じられたように、キャッチアッププロトコルを使用するオプションは、一例では、ターゲットデバイスにおけるバッファサイズに基づくことができる。たとえば、810〜815におけるリワインドストリームのための時間遅延が、ターゲットデバイスのバッファ内の空き領域の量より短い時間である場合には、失われた一瞬のみがリワインドされる必要があり、送信デバイスは「リアルタイム」の一瞬をリアルタイムに送信し続けることができ、ターゲットデバイスはリワインドストリームおよび進行中のリアルタイムメディアストリームの両方を受け入れる余裕があるので、「追い付くことは」必要とされない。しかしながら、810〜815におけるリワインドストリームのため時間遅延が、ターゲットデバイスのバッファの空き領域の量より長い時間の場合には、リアルタイムメディアストリームとともにリワインドストリームが送信されたなら、バッファがオーバーフローすることになる。この場合、820においてキャッチアッププロトコルを用いて、デバイスをリアルタイムにシフトバックすることができる。

825において、送信デバイスは、リワインドストリームがリアルタイムメディアストリームに追い付いたか否かを判断する。追い付いていない場合、プロセスは815に戻る。825において、送信デバイスが、リワインドストリームがリアルタイムメディアストリームに追い付いたと判断すると、プロセスは800に戻り、送信デバイスはターゲットデバイスにリワインドストリームを送信するのを中止し、ターゲットデバイスへのリアルタイムメディアストリームの送信を再開する(または継続する)。この時点で、リワインドストリームを完全に破棄することができるが、リワインドストリームは、リワインドモードにおいて依然として動作している(または動作をサポートしている)他のデバイスに別々に送達され続けることができる。

図9Aは、本発明の一実施形態による、図7および図8のプロセスの例示的な実施態様を示す。図9Aの実施形態では、図7〜図8からの送信デバイスはUE1に対応し、ターゲットデバイスはUE2に対応する。図9Aの実施形態では、図9AがUE1からUE2への一方向メディアストリームのフローに焦点を合わせる場合であっても、リアルタイム通信セッションは半二重または全二重とすることができる。一例では、図9Aのリアルタイム通信セッションは、RTPオーバーUDPセッションに対応することができ、メディア(たとえば、オーディオメディア、ビデオメディアなど)は、少なくとも1つのメディアフレームをそれぞれ含むRTPパケット内に含まれる。また、図9Aのリアルタイム通信セッションは、1:1もしくは直接セッションまたはグループセッション(たとえば、図示されない他のUEもセッションに参加している)に対応することができる。

図9Aを参照すると、リアルタイム通信セッション中に、UE1はメディアを取り込む、900A。900Aにおいて生じるメディア取込みは、UE1の操作者の発話のようなオーディオデータを取り込むオーディオ記録デバイス(たとえば、マイクロフォン)、および/またはUE1の環境のビデオデータを取り込むビデオ記録デバイス(たとえば、カメラ)に対応することができる。UE1は、取り込まれたメディアを1組のメディアパケット内にバッファリングし、905A、UE1は、アプリケーションサーバ170を介してUE2にリアルタイムメディアストリームを送信する、910A。図6の620の場合のように905Aからのバッファをクリアする代わりに、UE1は、リアルタイム通信セッションに参加する任意のターゲットデバイスからのリワインド要求に対応するために、延長された時間(たとえば、20秒、25秒など)にわたって、リアルタイムメディアストリームからのメディアフレームをバッファ内に保持する、915A。

図9Aを参照すると、UE2は、リアルタイムメディアストリームを受信し、バッファリングし、再生する、920A。後に、リアルタイム通信セッション中のある時点で、UE2はメディア受信空白を検出し、920A(たとえば、図7の710と同様)、UE2はUE1に1つまたは複数のリワインド要求を送信する、930A(たとえば、図7の715と同様)。たとえば、930Aにおいて、UE2は、リワインドストリームが受信されるか、またはリワインド上限(たとえば、10秒、全部でN回のリワインド要求など)に達するまでリワインド要求を送信することができる。

UE1は、リワインド要求を受信し、UE2に送達するためのリワインドストリームを生成し、935A(たとえば、図8の810と同様)、940AにおいてリワインドストリームがUE2に送信され(たとえば、815と同様)、945AにおいてUE2がリワインドストリームを再生する(たとえば、図7の725および/または730と同様)。明示的に図示されないが、UE1および/またはUE2はオプションで、図7の730または図8の820に関して先に論じられたように、940A中にリワインドストリームに対するキャッチアッププロトコルを実行することができる。また、明示的に図示されないが、910Aからのリアルタイムメディアストリームは、940AにおいてリワインドストリームとともにUE2に送信され続けることができるか、または代替的には、リアルタイムメディアストリームが940Aにおいて送信を中止するように、リワインドストリームがリアルタイムメディアストリームに取って代わることができる。950Aにおいて、UE1はオプションで、リワインドストリームがリアルタイムに追い付いたか否かを判断する。追い付いていない場合には、プロセスは940Aに戻り、UE1は、UE2にリワインドストリームを送達し続ける。追い付いた場合には、プロセスは910Aに戻り、UE1はUE2へのリアルタイムメディアストリームの送達を再開する(ただし、先に言及されたように、UE2がリワインドモードにおいて動作していた間に、UE2はリアルタイムメディアストリームを他のUEに提供していることができたことは理解されよう)。図9Aにおいて、950Aはオプションであり、ターゲットUE(この場合、UE2)のバッファサイズに基づくことができる。たとえば、935A〜945Aにおけるリワインドストリームのための時間遅延が、UE2のバッファ内の空き領域の量より短い時間である場合には、失われた一瞬のみがリワインドされる必要があり、話者側は「リアルタイム」の一瞬をリアルタイムに送信し続けることができ、受信側はリワインドストリームおよび進行中のリアルタイムメディアストリームの両方を受け入れる余裕があるので、「追い付くことは」必要とされない。しかしながら、935A〜945Aにおけるリワインドストリームのため時間遅延が、UE2のバッファの空き領域の量より長い時間の場合には、リアルタイムメディアストリームとともにリワインドストリームが送信されたなら、UE2のバッファがオーバーフローすることになる。この場合、940Aと950Aとの間においてキャッチアッププロトコルを用いて、UE2をリアルタイムにシフトバックすることができる。

図9Bは、本発明の一実施形態による、図9Aのさらに詳細な実施態様例を示す。図9Bを参照すると、900B〜925Bは、それぞれ図9Aの900A〜925Aに対応しており、簡潔にするためにさらには説明されない。930Bにおいて、UE2は、それぞれ2秒、3秒、4秒および5秒のリワインド遅延を要求する4つの別々のリワインド要求を送信するのに成功する。図9Bにおいて、リワインド要求#1、#2および#3がUE1に到着し、その時点で、UE1は、任意の早期の(古い)リワインド要求を無視しながら、リワインドストリームを生成するための最新のリワインド要求を選択する、935B。それにより、935Bにおいて4秒のリワインド遅延を用いてリワインドストリームが生成され、940BにおいてリワインドストリームがUE2に送信される。最終的に、リワインド要求#4もUE1に到着する、945B。この時点で、古すぎるためではなく、到着が遅すぎるために(すなわち、UE1はすでにUE2にリワインドストリームを与えている)、UE1はリワインド要求#4を無視する。950Bにおいて、UE2は、リワインドストリームを受信し、バッファリングし、再生する。また、明示的に図示されないが、910Bからのリアルタイムメディアストリームは、940BにおいてリワインドストリームとともにUE2に送信され続けることができるか、または代替的には、リアルタイムメディアストリームが940Bにおいて送信を中止するように、リワインドストリームがリアルタイムメディアストリームに取って代わることができる。955Bにおいて、UE1はオプションで、リワインドストリームがリアルタイムに追い付いたか否かを判断する。追い付いていない場合には、プロセスは940Bに戻り、UE1は、UE2にリワインドストリームを送達し続ける。追い付いた場合には、プロセスは910Bに戻り、UE1はUE2へのリアルタイムメディアストリームの送達を再開する(ただし、先に言及されたように、UE2がリワインドモードにおいて動作していた間に、UE2はリアルタイムメディアストリームを他のUEに提供していることができたことは理解されよう)。955Bがオプションである理由は、図9Aの950Aに関して先に説明された理由と同じである。

図9Cは、本発明の一実施形態による、図9Aの代替的な実施態様例を示す。図9Aとは異なり、図9Cの実施形態では、図7および図8からの送信デバイスはUE1に対応するが、ターゲットデバイスはアプリケーションサーバ170に対応する(その場合に、UE2は間接的なターゲットデバイスである)。図9Cを参照すると、900C〜920Cおよび935C〜950Cはそれぞれ図9Aの900A〜920Aおよび935A〜950Aに対応しており、簡潔にするためにさらには説明されない。925Cおよび930CがUE2の代わりにアプリケーションサーバ170において実施されることを除いて、925Cおよび930Cは925Aおよび930Aと同様である。

図10Aは、本発明の一実施形態による、図9Aのプロセスの継続を示す。図10Aの実施形態では、図7〜図8からの送信デバイスはUE1に対応し、ターゲットデバイスは、UE2...Nのそれぞれに対応し、ただし、Nは少なくとも6に等しい。図10Aのリアルタイム通信セッションは、グループセッションに対応することは理解されよう。

図10Aを参照すると、UE2は図9Aの945A後に依然としてリワインドモードにあると仮定する。したがって、UE1は、UE3...Nにリアルタイムメディアストリームを送信し、1000A、UE1は、UE2に935A〜940Aのリワインドストリームを送信する、1005A。図10Aにおいて、1005Aからのリワインドストリームは、6秒のリワインド遅延を有すると仮定され(ただし、これは、リワインドストリームがリアルタイムメディアストリームに追い付くにつれて変更することができる)、以下に提供される図10Aの説明は複数のリワインドストリームへの参照を含むので、これ以降、リワインドストリーム#1と呼ばれる。UE2は、リワインドストリーム#1を受信し、バッファリングし、再生し、1010A、UE3...Nはそれぞれリアルタイムメディアストリームを受信し、バッファリングし、再生する、1015Aおよび1020A。また、明示的に図示されないが、1000Aからのリアルタイムメディアストリームは、1005Aにおいてリワインドストリームとともに、UE3...Nに加えてUE2に送信され続けることができるか、または代替的には、リアルタイムメディアストリームが1005AにおいてUE2に送信されないように、リワインドストリームがリアルタイムメディアストリームに取って代わることができる。

後に、リアルタイム通信セッション中のある時点で、UE3...5はそれぞれメディア受信空白を独立して検出し、1025A(たとえば、図7の710と同様)、UE3...5はそれぞれUE1に1つまたは複数のリワインド要求を独立して送信する、1030A(たとえば、図7の715と同様)と仮定する。たとえば、1030Aにおいて、UE3...5はそれぞれ、リワインドストリームが受信されるか、またはリワインド上限(たとえば、10秒、全部でN回のリワインド要求など)に達するまでリワインド要求を送信することができる。説明の便宜上、1030Aにおいて、UE3は5秒の遅延を有するリワインドストリームを要求し、UE4は2秒の遅延を有するリワインドストリームを要求し、UE5は3秒の遅延を有するリワインドストリームを要求すると仮定する。

UE1はUE3...5からリワインド要求を受信し、4つの個別のリワインドストリームを生成することによって、それぞれのリワインド要求に応じる代わりに、UE1は、UE3のためのリワインド要求をリワインドセッション#1でグループ化し、UE4およびUE5のためのリワインド要求を取り扱うための新たなリワインドストリーム#2を形成する、1035A。X個のターゲットUEにX個のリワインドストリームを送信することは、Xが増えるにつれて、処理、帯域幅制約などに関して過酷になる可能性があるので、共通のリワインド遅延を共有するリワインドグループを形成することが、この負担を軽減するのを助けることができることは理解されよう(たとえば、リワインドグループの数は、処理制約および/または帯域幅制約に基づくことができる)。この場合、UE2およびUE3のためのリワインド遅延は比較的近い(たとえば、5秒および6秒)ので、UE2およびUE3は、現在の6秒のリワインド遅延を有するリワインドストリーム#1にまとめてグループ化される。また、UE4およびUE5のためのリワインド遅延は比較的近い(たとえば、2秒および3秒)ので、UE4およびUE5は、現在の3秒のリワインド遅延を有するリワインドストリーム#2にまとめてグループ化される。したがって、図10Aでは、4つの独立したリワインドストリームの代わりに、遅れたUEに対して2つのリワインドストリームが生成される。

図10Aを参照すると、UE3のリワインド要求をリワインドストリーム#1に統合し、リワインドストリーム#2を生成した後に、UE1は、UE2およびUE3にリワインドストリーム#1を送信し、UE4およびUE5にリワインドストリーム#2も送信する、1040A。UE2およびUE3はそれぞれ、リワインドストリーム#1を受信し、バッファリングし、再生し、1045A、UE4およびUE5はそれぞれ、リワインドストリーム#2を受信し、バッファリングし、再生する、1050A。図10Aには明示的に図示されないが、いずれかのリワインドストリーム#1または#2がキャッチアッププロトコルの実行によってリアルタイムに追い付く場合には、それぞれのリワインドストリームをリアルタイムメディアストリームと入れ替えることができる。代替的には、先に言及されたように、リアルタイムメディアストリームは、リワインドストリーム#1および/または#2とともに単に送達され続けることができる。また、いずれかのリワインドストリームがリアルタイムメディアストリームに追い付く前に、リワインドストリーム#1がリワインドストリーム#2に追い付く場合には、2つのそれぞれのリワインドストリームを統合して単一のリワインドストリームにすることができ、そのリワインドストリームがUE2...5にそれぞれ送達される。

明示的に図示されないが、図10Aは、アプリケーションサーバ170が(UE3...5の代わりに)、図9Cと同様に1030Aからのリワインド要求を発信するように変更できることは理解されよう。図10Aのこの代替の実施態様では、図7〜図8からの送信デバイスはUE1に対応し、一方、ターゲットデバイスは、個々のUE3...5の代わりにアプリケーションサーバ170に対応する。

図10Bは、本発明の一実施形態による、図10Aの代替的な実施態様例を示す。図10Aとは異なり、図10Bの実施形態では、ターゲットデバイスはUE2...Nのそれぞれに対応し、Nは少なくとも6に等しいが、図7〜図8の送信デバイスはアプリケーションサーバ170に対応する。これは、UE1が送信しているのではなく、アプリケーションサーバ170が、図10Bにおいてリワインドストリームを生成するエンティティであることを意味する。

図10Bを参照すると、1005Bのリワインドストリームが図10Aの1005Aの場合のようにUE1の代わりに、アプリケーションサーバ170によって送信されていることを除いて、1000B〜1030Bおよび1050B〜1055Bはそれぞれ図10Aの1000A〜1030Aおよび1045A〜1050Aに実質的に対応するが、簡潔にするためにさらに説明されない。1035Bにおいて、図10Aの場合のように、リワインド要求をUE3...UE5からUE1に単に転送する代わりに、アプリケーションサーバ170は、要求されたリワインドストリームのためのメディアフレームがアプリケーションサーバ170において入手可能であると判断する。一例では、この判断は、セッション中にアプリケーションサーバ170によって実行されるバッファリングに基づいて可能である(たとえば、アプリケーションサーバ170は、リワインドストリーム生成に対応するために、20秒〜30秒のセッションデータをバッファリングすることができる)。1040Bおよび1045BがUE1の代わりにアプリケーションサーバ170において実行されることを除いて、1040Bおよび1045Bは図10Aの1035Aおよび1040Aと同様である。また、図10Bでは、アプリケーションサーバ170は、アプリケーションサーバ170がリワインドストリーム送達の取扱いを完全に引き継ぐことになることをUE1に通知できることが可能であり、その場合、UE1は、UE2にリワインドストリーム#1を送信するのを中止することができる。代替的には、アプリケーションサーバ170は、リワインドストリームがUE1によって搬送されるのを単に補助することができ、その場合、アプリケーションサーバ170は、UE2に加えてUE3にリワインドストリーム#1を送信することをUE1に通知しながら、リワインドストリーム#2を生成し、UE3およびUE4に送達することができる。さらに別の代替形態では、アプリケーションサーバ170は単に、リワインドストリーム#1を受信し続けることができ、UE2の代わりに、リワインドストリーム#1をUE2およびUE3の両方に転送することができる。この場合、UE1は、リワインドストリーム#1がUE2以外のUEに送達されていることを必ずしも通知される必要はない。

ターゲットUEがリワインドモードにおいて動作しているとき、ターゲットUEは近い過去からのメディア(たとえば、3秒前、7秒前などのメディア)を再生している。オーディオの例では、ターゲットUEの操作者は、リワインドモードにある間に別のユーザが話すのを聞いている場合があり、他のユーザを遮って、発言したい場合があるが、これは、ターゲットUEが実際にはリアルタイムに動作していないためできない。図11は、本発明の一実施形態による、ターゲットUEがリワインドモードにおいて動作している間に、ターゲットUEに発言権を移行するプロセスを示す。図11の実施形態では、リアルタイム通信セッションは半二重であり、グループセッションまたは1:1もしくは直接セッションとすることができる。また、説明の便宜上、図11は、図9Aのプロセスの継続として説明される。

図11を参照すると、UE1は、UE2にリワインドフレーム(図9Aの935A〜940Aから)を送信し続け、1100、UE2は、リワインドフレームを受信し、バッファリングし、再生し続ける、1105。リアルタイム通信セッション中のある時点で、UE2は依然としてリワインドモードにおいて動作しているが、UE2の操作者はそのセッションのための発言権を得たいとの希望を示すと仮定する(たとえば、PTTボタンを押下すること、話し始めることなどによる)、1110。1110からの指示に応答して、UE2が依然としてリワインドモードにある間に、アプリケーションサーバ170に発言権要求が送信され、1115、アプリケーションサーバ170は発言権を与える、1120。しかしながら、UE2が発言権を有する場合であっても、UE2は実際にはリアルタイムにまだ追い付いていない。したがって、UE1は、リワインドストリームが、UEが発言権を与えられた時点に追い付くまで、リワインドストリームを送信し続け、1125、UE2は、UE2が発言権を有する場合であっても、リワインドストリームを再生し続ける、1130。また、1130において、UE2は、リワインドストリームが依然として再生されている間、その操作者のメディアをいずれもUE1に実際には送信しない。1135において、UE2は、リワインドセッションにおいてUE2に発言権が与えられた時点に追い付くか、またはUE2の操作者は、UE1にメディアを送信し始めることができるように、リワインドセッションの任意の残りの部分をスキップすることを望む。一例では、キャッチアッププロトコルに従って、UE2が発言権を与えられた後にリワインドストリームをオーディオデータからテキストに変換することができ(たとえば、UE1によるか、アプリケーションサーバ170によるか、またはUE2自体による)、その場合に、UE2の操作者は、同時にUE2に送信できるようにしながら、リワインドセッションを読むことを望む場合がある。UE2が発言権を得て、リワインドモードにおいてもはや動作しなくなると、1140〜1155は、UE1の代わりにUE2において実行されていることを除いて、900A〜915Aに実質的に対応するので、簡潔にするためにさらには説明されない。

上記の実施形態は概して、特定のターゲットデバイスの場合に、リアルタイムモードからリワインドモードへのセッションの移行をトリガするメディア受信空白(デバイス検出またはユーザ検出)に関して説明されてきた。いずかの動作モード(リワインドまたはリアルタイム)中に、閉ループフィードバックプロトコルを実施して、リアルタイム通信セッションの現在の送信機(たとえば、半二重における発言権保有者)に、セッション品質に関連するリアルタイムフィードバックを与えることができる。このシナリオが、図12に関して以下でさらに詳細に説明される。リアルタイムフィードバックは、暗黙的なリワインド要求をいかに実施することができるかの一例であり、送信デバイスは、特定のリアルタイムフィードバックを暗黙的要求と解釈し、リワインドストリームの送達を開始する(または既存のリワインドストリームの送達を変更する)。

図12を参照すると、UE1は1組のメディアストリーム(たとえば、リアルタイムメディアストリームおよび/またはリワインドメディアストリーム)をUE2...Nに送信する、1200。UE2...Nはそれぞれ、それぞれのメディアストリームに関連付けられる性能測定基準を監視しながら、1210、それぞれのメディアストリームを受信し、バッファリングし、再生する、1205。たとえば、1210においてUE2...Nによって監視される性能測定基準はパケット誤り率(PER)などを含むことができる。1215において、UE2...Nは性能測定基準をUE1に報告する。一例では、UE2...Nは、所与の間隔(たとえば、1/4秒ごと、10秒ごとなど)に従って1215において性能測定基準を報告することができ、その間隔はUEごとに変更することができるか、またはUE2...Nにわたって一定にすることができる。さらに、性能測定基準が報告される方法は、明示的な数に(たとえば、先行する10秒報告間隔内に13個のパケットが破棄された)、または品質範囲に対応することができる。代替的には、性能測定基準は、UE1に数字として報告することができ、その後、UE1によって、UE1の操作者に提示するための品質範囲に変換することができる。

UE1はUE2...Nから報告された性能測定基準を受信し、その後、UE1は、報告された性能測定基準に関してUE1の操作者に通知し、および/または報告された性能測定基準に基づいて1つまたは複数のストリームパラメータを調整する、1220。UE1が1220において報告された性能測定基準に基づいて1つまたは複数のストリームパラメータを調整することに決める場合には、1225において調整されたメディアストリームが送信される。1220におけるオプションの調整は、リアルタイムメディアストリームに、(存在するなら)リワインドストリームのうちの1つもしくは複数に、または両方に影響を及ぼす可能性があることは理解されよう。一例では、1220におけるオプションの調整は、(i)リアルタイムメディアストリームを中止し、リワインドストリームを生成し、その後送信すること、(ii)リアルタイムメディアストリームおよびリワインドストリームの両方のストリームを同時に並行して送達するために、リアルタイムメディアストリームに加えてリワインドストリームを生成し、その後送信すること、(iii)リワインドストリームを生成することなく、リアルタイムメディアストリームのフォーマットまたは品質レベルを変更することと、(iv)既存のリワインドストリームのフォーマットまたは品質レベルを変更すること、および/または(v)その任意の組合せのうちの1つまたは複数を含むことができる。

図12を参照すると、性能測定基準が複数の品質範囲のうちの1つとして提示される例を詳細に説明するとき、UE2...Nがそれぞれ10秒の報告サイクルと、6=〜83パケット/10secのバンドリングファクタ(bundling-factor)とを使用すると仮定する。刻々と、UE2...Nは、受信されたパケットを評価する(そして、パケット遅延を平均する)。所与のUEにおいて2個未満のパケットが破棄される場合には、所与のUEは、1215において「良好な品質」を報告し、その特定のUEに対して、1220におけるストリームパラメータ調整または通知は不要である。所与のUEにおいて2個〜5個のパケットが破棄される場合には、所与のUEは、1215において、「何らかの損失」を報告することができ、UE1がフレームレート、全体的なデータ量を落とす可能性があること、スループットを上げること、および/または所与のUEに送達されるメディアストリームにインターリーブ処理を適用することを報告することができる。所与のUEにおいて6個以上のパケットが破棄される場合には、所与のUEは、1215において「高い損失」を報告することができ、そのように多くのパケットがなぜ失われたかを特定しようと試みることもできる。たとえば、失われたパケットが1つのバースト内に集まっていた場合には、所与のUEは、先に論じられたように、リワインドコマンドを発行することができる。別の例では、失われたパケットが、より均等に分散されていた場合には、これは所与のUEにおけるチャネル条件不良を表すものである可能性があり、その場合、所与のUEは、「高い損失-チャネル条件不良」通告をUE1に送信することができる(たとえば、一例では、テキストまたはオーディオによる通告として送信することができ、それは1220においてUE1が操作者に提示することができる)。理解されるように、UE2...Nにおいて経験されたパケット損失の知識をUE1の操作者に伝達することは、その通話のためのユーザ体感を改善することができる特定の措置を講じるように操作者を促すのを助けることができる(たとえば、チャネル条件不良にあるUEが、言われていることを理解できるように、操作者がさらにゆっくり話すことができる、操作者がオーディオの代わりにテキストの送信を開始することができる、など)。

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

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

本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(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)は、コンパクトディスク(disc)(CD)、レーザディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読記録媒体の範囲の中に含まれるべきである。

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

100 ワイヤレス通信システム
104 エアインターフェース
106 エアインターフェース
108 エアインターフェース
120 RAN
125 アクセスポイント
140 コアネットワーク
140A LTE/EPSネットワーク
140B HRPDコアネットワーク
170 アプリケーションサーバ
175 インターネット
200A 基地局
200B NodeB
200D 発展型NodeB
205D 発展型NodeB
210D 発展型NodeB
200E ベーストランシーバ基地局(BTS)
205A 基地局
205B NodeB
205D eNodeB
205E ベーストランシーバ基地局(BTS)
210A 基地局
210B NodeB
210D eNodeB
210E ベーストランシーバ基地局(BTS)
215A 基地局コントローラ(BSC)
215B 無線ネットワークコントローラ(RNC)
215D モビリティ管理エンティティ(MME)
215E eBSC/ePCF
220A PCF
220B SGSN
220D モビリティ管理エンティティ(MME)
225A PDSN
225B GGSN
225D ホーム加入者サーバ(HSS)
225E 認証許可アカウンティング(AAA)サーバ
230D サービングゲートウェイ(S-GW)
230E PDSN/FA
235D パケットデータネットワークゲートウェイ(P-GW)
240D ポリシーおよび課金規則機能(PCRF)
300A UE
300B UE
302 プラットフォーム
305A アンテナ
305B タッチスクリーンディスプレイ
306 送受信機
308 ASIC
310A ディスプレイ
310B 周辺ボタン
312 メモリ
314 ローカルデータベース
315A ボタン
315B 周辺ボタン
320A キーパッド
320B 周辺ボタン
325B 周辺ボタン
330B フロントパネルボタン
400 通信デバイス
405 情報を受信および/または送信するように構成された論理手段
415 情報を処理するように構成された論理手段
415 情報を記憶するように構成された論理手段
420 情報を提示するように構成された論理手段
425 ローカルユーザ入力を受信するように構成された論理手段
500 サーバ
501 プロセッサ
502 揮発性メモリ
503 ディスクドライブ
504 ネットワークアクセスポート
506 ディスクドライブ
507 ネットワーク

Claims (31)

1. リアルタイム通信セッション中に送信デバイスからデータを受信している受信デバイスを操作する方法であって、
   前記受信デバイスが前記送信デバイスからリアルタイムメディアストリームを受信しようと試みている間に、メディア受信空白を検出するステップと、
   前記検出に応答して、前記メディア受信空白中に失われたメディアを含む前記リアルタイムメディアストリームの時間遅延バージョンを生成し、提供するように前記送信デバイスをトリガするように構成されるリワインド要求を前記送信デバイスに送信するステップと、
   前記リワインド要求に応答して、リワインドストリームを受信するステップとを含む、方法。
2. 前記リワインドストリームが受信されている間に前記リアルタイムメディアストリームを受信し続けるステップをさらに含む、請求項1に記載の方法。
3. 前記リアルタイムメディアストリームの受信は、前記リワインド要求に応答して前記リワインドストリームが受信されている間に停止する、請求項1に記載の方法。
4. 前記リワインド要求は、前記送信デバイスが前記リワインドストリームの生成および送達を独立してトリガできるように、前記送信デバイスによる評価のために構成される情報を伝達する暗黙的なリワインド要求に対応する、請求項1に記載の方法。
5. 前記伝達された情報は、メディア受信空白に関連する、請求項4に記載の方法。
6. 前記リワインド要求は、前記リアルタイムメディアストリームの前記時間遅延バージョンを提供するように前記送信デバイスに明示的に要求する明示的なリワインド要求に対応する、請求項1に記載の方法。
7. 前記明示的なリワインド要求は、前記リアルタイムメディアストリームに対して第1の遅延量を有する前記リアルタイムメディアストリームの前記時間遅延バージョンを提供するように前記送信デバイスに要求し、
   前記リワインドストリームは、前記リアルタイムメディアストリームに対して、前記第1の遅延量とは異なる第2の遅延量を含む、請求項6に記載の方法。
8. 前記受信デバイスは、前記リアルタイム通信セッションに参加しているターゲットユーザ機器(UE)に対応し、
   前記リワインドストリームを再生するステップをさらに含む、請求項1に記載の方法。
9. 前記受信デバイスは、前記リアルタイム通信セッションを調停し、および/または仲介しているサーバに対応し、
   前記リワインドストリームを前記リアルタイム通信セッションに参加している少なくとも1つのターゲットユーザ機器(UE)に送信するステップをさらに含む、請求項1に記載の方法。
10. 前記メディア受信空白は、(i)前記受信デバイスに到着するのに成功する前記リアルタイムメディアストリームのための使用可能なメディアパケットがしきい値数未満である第1の時間的空白か、または(ii)前記リアルタイムメディアストリームのための使用可能なメディアパケットの前記しきい値数が入手可能であるが、前記受信デバイスにおける条件が前記受信デバイスによるプレイバックを妨げる第2の時間的空白に対応する、請求項1に記載の方法。
11. 前記メディア受信空白は、ネットワーク接続劣化に基づいて生じる、請求項1に記載の方法。
12. 前記ネットワーク接続劣化は、サービングネットワークと、前記受信デバイスおよび/またはバックホール接続との間の接続において生じる、請求項10に記載の方法。
13. 前記リワインドストリームが前記リアルタイムメディアストリームに追い付くように、前記リワインドストリームに対してキャッチアッププロトコルを実行するステップをさらに含む、請求項1に記載の方法。
14. 前記リアルタイム通信セッションは半二重セッションであり、前記受信デバイスは、前記リワインドストリームが受信されている間に非発言権保有者として前記リアルタイム通信セッションに参加しているターゲットユーザ機器(UE)であり、
    前記受信デバイスが前記リワインドストリームを受信している間に、前記リアルタイム通信セッションのための発言権を要求するステップと、
    前記発言権要求に応答して、前記発言権が前記受信デバイスに与えられたという指示を受信するステップと、
    前記指示が受信された後に、(i)前記リワインドストリームが、前記発言権が前記受信デバイスに与えられた時点に追い付くまで、および/または(ii)前記受信デバイスがリワインドモードを出ることに決めるまで、前記リワインドストリームを受信し、再生し続けるステップと、
    (i)または(ii)後に発言権保有者として前記リアルタイム通信セッションのためのメディアを送信し始めるステップとをさらに含む、請求項1に記載の方法。
15. 前記リアルタイムメディアストリームおよび/または前記リワインドストリームに関連付けられる1つまたは複数の性能測定基準を監視するステップと、
    前記リアルタイムメディアストリームおよび/または前記リワインドストリームの発信者に前記1つまたは複数の性能測定基準を報告するステップとをさらに含む、請求項1に記載の方法。
16. 前記1つまたは複数の性能測定基準は、前記リアルタイムメディアストリームおよび/または前記リワインドストリームのパケット誤り率(PER)を含む、請求項14に記載の方法。
17. リアルタイム通信セッション中に1組のターゲットデバイスにデータを送信している送信デバイスを操作する方法であって、
    前記1組のターゲットデバイスに前記リアルタイム通信セッションのためのリアルタイムメディアストリームを送信するステップと、
    前記1組のターゲットデバイスのうちの少なくとも1つのターゲットデバイスから、前記1組のターゲットデバイスによって検出されたメディア受信空白中に失われたメディアを含む、前記リアルタイムメディアストリームの時間遅延バージョンを生成し、提供するように前記送信デバイスをトリガするように構成されるリワインド要求を受信するステップと、
    前記リワインド要求に基づいてリワインドストリームを生成するステップと、
    前記リワインドストリームを前記少なくとも1つのターゲットデバイスに送信するステップとを含む、方法。
18. 前記リワインドストリームが送信されている間に、前記リアルタイムメディアストリームを送信し続けるステップをさらに含む、請求項16に記載の方法。
19. 前記リワインドストリームが送信されている間に、前記少なくとも1つのターゲットデバイスへの前記リアルタイムメディアストリームの送信を中止するステップをさらに含む、請求項16に記載の方法。
20. 前記リワインド要求は、前記送信デバイスが前記リワインドストリームの生成および送達をトリガすることを独立して決めることができるように、前記送信デバイスによる評価のために構成される情報を伝達する暗黙的なリワインド要求に対応するか、または
    前記リワインド要求は、前記リアルタイムメディアストリームの前記時間遅延バージョンを提供するように、前記送信デバイスに明示的に要求する明示的なリワインド要求に対応する、請求項16に記載の方法。
21. 前記送信デバイスは、前記リアルタイム通信セッションに参加している発信元ユーザ機器(UE)に対応する、請求項16に記載の方法。
22. 前記少なくとも1つのターゲットデバイスは、前記リアルタイム通信セッションに参加している少なくともターゲットユーザ機器(UE)に対応するか、または
    前記少なくとも1つのターゲットデバイスは、前記リアルタイム通信セッションを調停し、および/または仲介しているサーバに対応する、請求項20に記載の方法。
23. 前記送信デバイスは、前記リアルタイム通信セッションを調停し、および/または仲介しているサーバに対応し、
    前記少なくとも1つのターゲットデバイスは、前記リアルタイム通信セッションに参加している少なくともターゲットユーザ機器(UE)に対応する、請求項16に記載の方法。
24. 前記メディア受信空白は、(i)前記少なくとも1つのターゲットデバイスに到着するのに成功する前記リアルタイムメディアストリームのための使用可能なメディアパケットがしきい値数未満である第1の時間的空白か、または(ii)前記リアルタイムメディアストリームのための使用可能なメディアパケットの前記しきい値数が、前記少なくとも1つのターゲットデバイスに到着するのに成功するが、前記少なくとも1つのターゲットデバイスにおける条件が前記少なくとも1つのターゲットデバイスによるプレイバックを妨げる第2の時間的空白に対応する、請求項16に記載の方法。
25. 前記リワインドストリームが前記リアルタイムメディアストリームに追い付くように、前記リワインドストリームに対してキャッチアッププロトコルを実行するステップをさらに含む、請求項16に記載の方法。
26. 前記少なくとも1つのターゲットデバイスから、前記リアルタイムメディアストリームおよび/または前記リワインドストリームに関連する、前記少なくとも1つのターゲットデバイスによって監視される1つまたは複数の性能測定基準に関連する報告を受信するステップと、
    前記報告に基づいて、前記報告に関連する通知を提示し、および/または前記リアルタイムメディアストリームおよび/または前記リワインドストリームに関連付けられる1つまたは複数のストリームパラメータを調整するステップとをさらに含む、請求項16に記載の方法。
27. 前記1つまたは複数の性能測定基準は、前記リアルタイムメディアストリームおよび/または前記リワインドストリームに関する前記少なくとも1つのターゲットデバイスにおけるパケット誤り率(PER)を含む、請求項25に記載の方法。
28. N個のリワインド要求が、前記リアルタイムメディアストリームの異なる時間遅延バージョンをそれぞれ要求するN個のターゲットデバイスから受信され、
    前記生成するステップは1組のリワインドストリームを生成し、前記1組のリワインドストリームは、N個未満のリワインドストリームを含み、前記1組のリワインドストリーム内の各リワインドストリームは、前記リアルタイムメディアストリームに対して異なる遅延量を有する、前記リアルタイムメディアストリームのバージョンに関連付けられ、
    前記N個のターゲットデバイスはそれぞれ、(i)前記リアルタイムメディアストリームの要求された時間遅延バージョン、および(ii)所与のリワインドストリームの場合の前記リアルタイムメディアストリームに対する所与の遅延量に基づいて、前記1組のリワインドストリーム内の前記所与のリワインドストリームに割り振られる、請求項16に記載の方法。
29. 前記1組のリワインドストリーム内のリワインドストリームの数は、帯域幅制約または処理制約に少なくとも部分的に基づく、請求項27に記載の方法。
30. リアルタイム通信セッション中に送信デバイスからデータを受信している受信デバイスであって、
    前記受信デバイスが前記送信デバイスからリアルタイムメディアストリームを受信しようと試みている間に、メディア受信空白を検出するように構成される論理手段と、
    前記検出に応答して、前記メディア受信空白中に失われたメディアを含む前記リアルタイムメディアストリームの時間遅延バージョンを生成し、提供するように前記送信デバイスをトリガするように構成されるリワインド要求を前記送信デバイスに送信するように構成される論理手段と、
    前記リワインド要求に応答してリワインドストリームを受信するように構成される論理手段とを備える、受信デバイス。
31. リアルタイム通信セッション中に1組のターゲットデバイスにデータを送信している送信デバイスであって、
    前記リアルタイム通信セッションのためのリアルタイムメディアストリームを前記1組のターゲットデバイスに送信するように構成される論理手段と、
    前記1組のターゲットデバイスのうちの少なくとも1つのターゲットデバイスから、前記1組のターゲットデバイスによって検出されたメディア受信空白中に失われたメディアを含む前記リアルタイムメディアストリームの時間遅延バージョンを生成し、提供するように前記送信デバイスをトリガするように構成されるリワインド要求を受信するように構成される論理手段と、
    前記リワインド要求に基づいてリワインドストリームを生成するように構成される論理手段と、
    前記少なくとも1つのターゲットデバイスに前記リワインドストリームを送信するように構成される論理手段とを備える、送信デバイス。

Images