▶ インターデジタル シーイー パテント ホールディングスの特許一覧
特表2024-513707クラウドゲーミングにおける体感品質向上に関する方法、装置、及びシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-27
(54)【発明の名称】クラウドゲーミングにおける体感品質向上に関する方法、装置、及びシステム
(51)【国際特許分類】
H04N 21/44 20110101AFI20240319BHJP
H04N 21/437 20110101ALI20240319BHJP
H04N 21/238 20110101ALI20240319BHJP
H04N 21/239 20110101ALI20240319BHJP
H04L 67/131 20220101ALI20240319BHJP
【ＦＩ】
H04N21/44
H04N21/437
H04N21/238
H04N21/239
H04L67/131
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023556866
(86)(22)【出願日】2022-03-18
(85)【翻訳文提出日】2023-10-26
(86)【国際出願番号】 EP2022057178
(87)【国際公開番号】W WO2022200215
(87)【国際公開日】2022-09-29
(31)【優先権主張番号】21305349.9
(32)【優先日】2021-03-22
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＩＲＥＷＩＲＥ
２．３ＧＰＰ
(71)【出願人】
【識別番号】518341334
【氏名又は名称】インターディジタル・シーイー・パテント・ホールディングス・ソシエテ・パ・アクシオンス・シンプリフィエ
(74)【代理人】
【識別番号】100079108
【弁理士】
【氏名又は名称】稲葉 良幸
(74)【代理人】
【識別番号】100109346
【弁理士】
【氏名又は名称】大貫 敏史
(74)【代理人】
【識別番号】100117189
【弁理士】
【氏名又は名称】江口 昭彦
(74)【代理人】
【識別番号】100134120
【弁理士】
【氏名又は名称】内藤 和彦
(74)【代理人】
【識別番号】100108213
【弁理士】
【氏名又は名称】阿部 豊隆
(72)【発明者】
【氏名】サーモン－レガヌール，チャールズ
(72)【発明者】
【氏名】タイビ，シャルリーヌ
(72)【発明者】
【氏名】オーモン，フランク
(72)【発明者】
【氏名】ゲグー，エイドリアン
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA22
5C164SB21P
5C164SB29P
5C164UB04P
5C164UB21S
5C164UB26P
5C164UB41S
5C164YA24
(57)【要約】
クラウドゲーミングにおけるＱｏＥ改善に関する方法、装置、システムなどが本明細書に開示される。一実施形態では、ビデオコンテンツ（例えば、ゲームなど）のＱｏＥを改善するための方法が、クライアントデバイスにおいて実装され得る。例えば、クライアントデバイスは、ゲームサーバから、ビデオコンテンツのビデオフレームを搬送する複数のパケットを受信し得る。例えば、クライアントデバイスは、復号及び表示の前に、受信されたパケットに初期（例えば、セキュアリライアブルトランスポート（ＳＲＴ））レイテンシ値を適用し得る。例えば、クライアントデバイスは、復号及び表示の前に、受信された後続パケットに適用されるべきフレームペース変動に基づく新しいレイテンシ値を示す要求メッセージをサーバに送信し得る。
【特許請求の範囲】
【請求項1】
クライアントデバイスにおいて実施される方法であって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをサーバから受信することと、
－復号及び表示の前に受信された前記パケットに初期レイテンシ値を適用することと、
－要求メッセージを前記サーバに送信することであって、前記要求メッセージは、フレームペース変動に基づいて決定された要求されたレイテンシ値を示す第１の情報を含む、ことと、
－前記サーバから応答メッセージを受信することであって、前記応答メッセージは、新しいレイテンシ値を示す第２の情報を含む、ことと、
－復号及び表示の前に、受信された後続パケットに前記新しいレイテンシ値を適用することと、を含む、方法。
【請求項2】
前記初期レイテンシ値及び前記新しいレイテンシ値は、（ｉ）それぞれ前記初期レイテンシ値及び前記新しいレイテンシ値と、（ｉｉ）前記パケット及び前記後続パケットに含まれるタイムスタンプ情報と、に基づいて、前記パケット及び前記後続パケットを受信機バッファからそれぞれ抽出することによって、前記パケット及び前記後続パケットにそれぞれ適用され、前記タイムスタンプ情報は、前記サーバの送信機バッファにおける前記パケット及び前記後続パケットの格納に関連付けられたそれぞれの時間を示す、請求項１に記載の方法。
【請求項3】
前記パケット及び前記後続パケットのいずれかのパケットに含まれる前記タイムスタンプ情報は、前記パケットが前記送信機バッファにおいて格納された第１の時間を示し、前記パケットは、前記第１の時間の後の時間量に対応する第２の時間に抽出され、前記時間量は、連続するパケットに対して一定であり、前記初期レイテンシ値及び前記新しいレイテンシ値のいずれかに関連付けられている、請求項２に記載の方法。
【請求項4】
前記フレームペース変動は、前記ビデオフレームが受信される、前記受信機バッファから抽出される、及び復号されるのうちのいずれかであるペースの変動である、請求項２又は３に記載の方法。
【請求項5】
前記新しいレイテンシ値は、異なる先行する期間についてのフレームペース変動の履歴に基づいて取得される、請求項１～４のいずれか一項に記載の方法。
【請求項6】
前記新しいレイテンシ値は、遅延フレームの数及びドロップフレームの数のいずれかに更に基づく、請求項１～５のいずれか一項に記載の方法。
【請求項7】
前記新しいレイテンシ値は、前記新しいレイテンシ値が前記要求されたレイテンシ値に等しいか、又は前記要求されたレイテンシ値と前記初期レイテンシ値との間に厳密に含まれるという条件で、前記後続パケットに適用される、請求項１～６のいずれか一項に記載の方法。
【請求項8】
前記ビデオフレームを搬送する前記パケットが受信される前に、ハンドシェイク要求メッセージが前記クライアントデバイスによって前記サーバに送信され、前記ハンドシェイク要求メッセージは、ダイナミックレイテンシ動作をサポートするクライアント能力を示す第３の情報を含む、請求項１～７のいずれか一項に記載の方法。
【請求項9】
前記ハンドシェイク要求メッセージに応答して、前記サーバからハンドシェイク応答メッセージが前記クライアントデバイスによって受信され、前記クライアントデバイスは、前記ハンドシェイク応答メッセージが、ダイナミックレイテンシ動作をサポートするサーバ能力を示す第４の情報を含むという条件で、前記要求メッセージを送信することによってダイナミックレイテンシ動作を実行する、請求項８に記載の方法。
【請求項10】
前記ビデオフレームを搬送する前記パケットが受信される前に、ハンドシェイク要求メッセージが前記サーバから前記クライアントデバイスによって受信され、前記ハンドシェイク要求メッセージがダイナミックレイテンシ動作をサポートするサーバ能力を示す第３の情報を含むという条件で、ハンドシェイク応答メッセージが前記クライアントデバイスによって前記サーバに送信され、前記ハンドシェイク応答メッセージは、ダイナミックレイテンシ動作をサポートするクライアント能力を示す第４の情報を含む、請求項１～７のいずれか一項に記載の方法。
【請求項11】
前記初期レイテンシ値及び前記新しいレイテンシ値は、ＳＲＴプロトコルに関連付けられたセキュアリライアブルトランスポートレイテンシ値、すなわち、ＳＲＴレイテンシ値である、請求項１～１０のいずれか一項に記載の方法。
【請求項12】
伝送機、受信機、プロセッサ、及びメモリのうちのいずれかを含む、回路を備えるクライアントデバイスであって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをサーバから受信することと、
－復号及び表示の前に受信された前記パケットに初期レイテンシ値を適用することと、
－要求メッセージを前記サーバに送信することであって、前記要求メッセージは、フレームペース変動に基づいて決定された要求されたレイテンシ値を示す第１の情報を含む、ことと、
－前記サーバから応答メッセージを受信することであって、前記応答メッセージは、新しいレイテンシ値を示す第２の情報を含む、ことと、
－復号及び表示の前に、受信された後続パケットに前記新しいレイテンシ値を適用することと、を行うように構成されている、クライアントデバイス。
【請求項13】
サーバにおいて実施される方法であって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信することと、
－初期レイテンシ値に関連付けられた第１の時間量の間、再送のために前記パケットをバッファに保持することと、
－前記クライアントデバイスから要求メッセージを受信することであって、前記要求メッセージは、要求されたレイテンシ値を示す第１の情報を含む、ことと、
－応答メッセージを前記クライアントデバイスに送信することであって、前記応答メッセージは、新しいレイテンシ値を示す第２の情報を含む、ことと、
－前記ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットを前記クライアントデバイスに送信することと、
－前記新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために前記後続パケットを前記バッファ内に保持することと、を含む、方法。
【請求項14】
伝送機、受信機、プロセッサ、及びメモリのうちのいずれかを含む、回路を備えるサーバであって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信することと、
－初期レイテンシ値に関連付けられた第１の時間量の間、再送のために前記パケットをバッファに保持することと、
－前記クライアントデバイスから要求メッセージを受信することであって、前記要求メッセージは、要求されたレイテンシ値を示す第１の情報を含む、ことと、
－応答メッセージを前記クライアントデバイスに送信することであって、前記応答メッセージは、新しいレイテンシ値を示す第２の情報を含む、ことと、
－前記ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットを前記クライアントデバイスに送信することと、
－前記新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために前記後続パケットを前記バッファ内に保持することと、を行うように構成されている、サーバ。
【請求項15】
クライアントデバイスにおいて実施される方法であって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをサーバから受信することと、
－復号及び表示の前に受信された前記パケットに初期レイテンシ値を適用することと、
－前記サーバに情報を送信することであって、前記情報は、フレームペース変動を表すメトリックを示す、ことと、
－前記サーバから要求メッセージを受信することであって、前記要求メッセージは、要求されたレイテンシ値を示す第１の情報を含む、ことと、
－応答メッセージを前記サーバに送信することであって、前記応答メッセージは、前記要求されたレイテンシ値に基づく新しいレイテンシ値を示す第２の情報を含む、ことと、
－復号及び表示の前に、受信された後続パケットに前記新しいレイテンシ値を適用することと、を含む、方法。
【請求項16】
前記メトリックは、フレーム到着時間、パケット到着時間、フレーム復号時間、及びフレーム表示時間のいずれかの分散関数に基づき、前記分散関数は、平均値、中央値、標準偏差、分散、平均絶対偏差、及び四分位数のいずれかを含む、請求項１５に記載の方法。
【請求項17】
前記メトリックは、遅延フレームの数及びドロップフレームの数のいずれかに更に基づく、請求項１５又は１６に記載の方法。
【請求項18】
伝送機、受信機、プロセッサ、及びメモリのうちのいずれかを含む、回路を備えるクライアントデバイスであって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをサーバから受信することと、
－復号及び表示の前に受信された前記パケットに初期レイテンシ値を適用することと、
－前記サーバに情報を送信することであって、前記情報は、フレームペース変動を表すメトリックを示す、ことと、
－前記サーバから要求メッセージを受信することであって、前記要求メッセージは、要求されたレイテンシ値を示す第１の情報を含む、ことと、
－応答メッセージを前記サーバに送信することであって、前記応答メッセージは、前記要求されたレイテンシ値に基づく新しいレイテンシ値を示す第２の情報を含む、ことと、
－復号及び表示の前に、受信された後続パケットに前記新しいレイテンシ値を適用することと、を行うように構成されている、クライアントデバイス。
【請求項19】
サーバにおいて実施される方法であって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信することと、
－初期レイテンシ値に関連付けられた第１の時間量の間、再送のために前記パケットをバッファに保持することと、
－フレームペース変動を表すメトリックを示す情報を受信することと、
－要求メッセージを前記クライアントデバイスに送信することであって、前記要求メッセージは、前記示されたメトリックに基づいて決定された要求されたレイテンシ値を示す第１の情報を含む、ことと、
－応答メッセージを前記クライアントデバイスから受信することであって、前記応答メッセージは、新しいレイテンシ値を示す第２の情報を含む、ことと、
－前記ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットを前記クライアントデバイスに送信することと、
－前記新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために前記後続パケットを前記バッファ内に保持することと、を含む、方法。
【請求項20】
伝送機、受信機、プロセッサ、及びメモリのうちのいずれかを含む、回路を備えるサーバであって、－ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信することと、
－初期レイテンシ値に関連付けられた第１の時間量の間、再送のために前記パケットをバッファに保持することと、
－フレームペース変動を表すメトリックを示す情報を受信することと、
－要求メッセージを前記クライアントデバイスに送信することであって、前記要求メッセージは、前記示されたメトリックに基づいて決定された要求されたレイテンシ値を示す第１の情報を含む、ことと、
－応答メッセージを前記クライアントデバイスから受信することであって、前記応答メッセージは、新しいレイテンシ値を示す第２の情報を含む、ことと、
－前記ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットを前記クライアントデバイスに送信することと、
－前記新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために前記後続パケットを前記バッファ内に保持することと、を行うように構成されている、サーバ。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本出願は、２０２１年３月２２日に出願された欧州特許出願第２１３０５３４９．９号の利益を主張するものであり、その全体が参照により本明細書に組み込まれる。
本出願は、２０２１年３月２２日に出願された欧州特許出願第２１３０５３４９．９号の利益を主張するものであり、その全体が参照により本明細書に組み込まれる。
【0002】
（発明の分野）
本開示は、ゲームストリーミングとも呼ばれるクラウドゲーミングドメインに関し、より詳細には、クラウドゲーミングにおける体感品質（quality of experience、ＱｏＥ）に関する。
本開示は、ゲームストリーミングとも呼ばれるクラウドゲーミングドメインに関し、より詳細には、クラウドゲーミングにおける体感品質（quality of experience、ＱｏＥ）に関する。
【背景技術】
【0003】
クラウドゲーミングでは、エンドユーザデバイスは、サーバ（例えば、インスタンス）上で実行され得るゲーム実行可能プログラムを実行しなくてもよい。サーバインスタンスは、（例えば、クラウドプロバイダによって、又は任意の種類のオペレータによって操作される）データセンタ内に位置し得る。クラウドゲーミングでは、ゲームのユーザ体験は、例えば、ネットワークレイテンシ、サーバ負荷、及びゲーム複雑性のいずれかなどの異なる要因に応じて変動し得る。本開示は、上記を念頭に置いて設計されている。
【発明の概要】
【0004】
クラウドゲーミングにおけるＱｏＥ改善に関する方法、装置、システムなどが本明細書に開示される。一実施形態では、ビデオコンテンツ（例えば、ゲームなど）のＱｏＥを改善するための方法は、クライアントデバイスにおいて実装され得る。例えば、クライアントデバイスは、サーバから、ビデオコンテンツのビデオフレームを搬送する複数のパケットを受信してもよい。例えば、クライアントデバイスは、復号及び表示の前に、受信されたパケットに初期（例えば、セキュアリライアブルトランスポート（secure reliable transport、ＳＲＴ））レイテンシ値を適用してもよい。例えば、クライアントデバイスは、要求メッセージをサーバに送信してもよい。例えば、要求メッセージは、フレームペース変動に基づく新しいレイテンシ値を示す第１の情報を含んでもよい。例えば、クライアントデバイスは、サーバから応答メッセージを受信してもよく、応答メッセージは、新しいレイテンシ値を示す第２の情報を含む。例えば、クライアントデバイスは、（例えば、後続パケットを）復号して表示する前に、受信された後続パケットに新しいＳＲＴレイテンシ値を適用してもよい。
【0005】
本明細書では、装置、システム、デバイスなど、及び／又はそれらの任意の要素が、動作、プロセス、アルゴリズム、機能など、及び／又はそれらの任意の部分を行うように構成されている様々な実施形態が記載及び／又は特許請求されているが、本明細書に記載及び／又は特許請求されている任意の実施形態は、任意の装置、システム、デバイスなど、及び／又はそれらの任意の要素が、任意の動作、プロセス、アルゴリズム、機能など、及び／又はそれらの任意の部分を行う（逆の場合も同じ）と仮定することを理解されたい。
【図面の簡単な説明】
【0006】
より詳細な理解は、例示として添付の図面と併せて与えられる、以下の詳細な説明から得られ得る。そのような図面の図は、詳細な説明と同様、例である。したがって、図及び詳細な説明は限定的であるとみなされるべきではなく、他の同様に効果的な例が可能であり、可能性が高い。また、図中の同様の参照番号は、同様の要素を示している。
【図1】ゲームストリーミングの高レベルアーキテクチャの例を示すシステム図である。
【図2】クラウドゲーミングアーキテクチャにおけるビデオストリーミングの例を示すシステム図である。
【図3】ＳＲＴレイテンシバッファにおけるレイテンシウィンドウ動作の例を示す図である。
【図4-01】ＳＲＴにおける肯定応答動作の例を示す図である。
【図4-02】ＳＲＴにおける肯定応答動作の例を示す図である。
【図5】ＳＲＴ拡張ハンドシェイク手順後の受信機及び送信機のバッファレイテンシの例を示す図である。
【図6A】フレーム間遅延変動メトリックの例を示す図である。
【図6B】フレーム間遅延変動メトリックの例を示す図である。
【図7】ＳＲＴに基づくクラウドゲーミングシステムの例を示すシステム図である。
【図8A】拡張ハンドシェイクパケットフォーマットの２つの例を示す図である。
【図8B】ハンドシェイク拡張メッセージフラグの例を示す図である。
【図9A】レイテンシダイナミック変更をサポートする能力を示すための拡張ハンドシェイクメッセージ交換の例を示す図である。
【図9B】レイテンシダイナミック変更をサポートする能力を示すための拡張ハンドシェイクメッセージ交換の例を示す図である。
【図10】新しいＳＲＴレイテンシ値を要求するＳＲＴメッセージのフォーマットの例を示す図である。
【図11A-01】それぞれクライアントデバイス及びサーバによって開始されるダイナミックレイテンシ変更手順のためのメッセージ交換の例を示す図である。
【図11A-02】それぞれクライアントデバイス及びサーバによって開始されるダイナミックレイテンシ変更手順のためのメッセージ交換の例を示す図である。
【図11B-01】それぞれクライアントデバイス及びサーバによって開始されるダイナミックレイテンシ変更手順のためのメッセージ交換の例を示す図である。
【図11B-02】それぞれクライアントデバイス及びサーバによって開始されるダイナミックレイテンシ変更手順のためのメッセージ交換の例を示す図である。
【図12A】ゲームのＱｏＥを改善するためのクライアント処理デバイス１２Ａの例を示す図である。
【図12C】ゲームのＱｏＥを改善するためのサーバ処理デバイス１２Ｃの例を示す図である。
【図13】ゲームのＱｏＥを改善するための方法の例を示す図である。
【図14】例えば、ビデオコンテンツのＱｏＥを改善するためにクライアントデバイスにおいて実施される方法の第１の例を示す図である。
【図15】例えば、ビデオコンテンツのＱｏＥを改善するためにサーバにおいて実施される方法の第２の例を示す図である。
【図16】例えば、ビデオコンテンツのＱｏＥを改善するためにクライアントデバイスにおいて実施される方法の第３の例を示す図である。
【図17】例えば、ビデオコンテンツのＱｏＥを改善するためにサーバにおいて実施される方法の第４の例を示す図である。
【0007】
（複数の）図面は、本開示の概念を示すことを目的としており、必ずしも本開示を示すための唯一の可能な構成ではないことを理解されたい。
【発明を実施するための形態】
【0008】
図に示される要素は、様々な形態のハードウェア、ソフトウェア、又はそれらの組み合わせで実装され得ることを理解されたい。好ましくは、これらの要素は、１つ以上の適切にプログラムされた汎用デバイス上のハードウェア及びソフトウェアの組み合わせで実装され、プロセッサ、メモリ、及び入力／出力インターフェースを含み得る。本明細書では、「相互接続された」という用語は、１つ以上の中間構成要素に直接接続されていること、又は１つ以上の中間構成要素を介して間接的に接続されていることを意味する。そのような中間構成要素は、ハードウェアベースの構成要素及びソフトウェアベースの構成要素の両方を含んでもよい。「相互接続された」という用語は、有線相互接続に限定されず、無線相互接続も含む。
【0009】
本明細書に列挙される全ての例及び条件付き言語は、本開示の原理及び当該技術分野を促進するために発明者によって寄与される概念を読者が理解するのを助ける教育目的を意図しており、かかる具体的に列挙された例及び条件に限定されるものではないものとして解釈されるべきである。
【0010】
更に、例えば、本明細書に提示されるブロック図は、本開示の原理を具現化する例示的な回路の概念図を表すことが当業者には理解されよう。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コードなどは、コンピュータ可読媒体で実質的に表され、かかるコンピュータ又はプロセッサが明示的に示されているかどうかにかかわらず、コンピュータ又はプロセッサによって実行され得る様々なプロセスを表すことが理解されよう。
【0011】
図に示される様々な要素の機能は、専用のハードウェア、並びに適切なソフトウェアと関連してソフトウェアを実行することができるハードウェアの使用を通じて提供され得る。プロセッサによって提供される場合、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、又は複数の個々のプロセッサによって提供され得、そのいくつかは、共有され得る。更に、「プロセッサ」又は「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアを排他的に指すと解釈されるべきではなく、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）ハードウェア、ソフトウェアを記憶するための読み取り専用メモリ（read only memory、ＲＯＭ）、ランダムアクセスメモリ（random access memory、ＲＡＭ）、及び不揮発性記憶装置を暗黙的に含み得るが、これらに限定されない。
【0012】
従来の及び／又はカスタムの他のハードウェアも含まれ得る。同様に、図に示されるいずれのスイッチも、概念的なものに過ぎない。それらの機能は、プログラム論理の動作を通じて、専用論理の動作を通じて、プログラム制御及び専用論理との対話を通じて、又は手動でさえ実行され得、特定の技術は、その文脈からより具体的に理解されるように、実装者によって選択可能である。
【0013】
本明細書の特許請求の範囲において、特定の機能を実施するための手段として表される任意の要素は、例えば、ａ）その機能を実施する回路要素の組み合わせ、又はｂ）その機能を実施するためにそのソフトウェアを実行するための適切な回路と組み合わされた、ファームウェア、マイクロコードなどを含む任意の形態のソフトウェアを含む、その機能を実施する任意の方式を包含することが意図される。かかる特許請求の範囲によって定義される本開示は、様々な列挙される手段によって提供される機能性が、特許請求の範囲が要求する様式で組み合わされ、まとめられるという事実に存する。したがって、それらの機能性を提供することができるいずれの手段も、本明細書に示されるものと均等であるとみなされる。
【0014】
例えば、「Ａ／Ｂ」、「Ａ及び／又はＢ（A and/or B）」及び「Ａ及びＢのうちの少なくとも１つ（at least one of A and B）」の場合、次の「／」、「及び／又は（and/or）」、及び「のうちの少なくとも１つ（at least one of）」のいずれかの使用は、第１のリストされた選択肢（Ａ）のみの選択、又は第２のリストされた選択肢（Ｂ）のみの選択、又は両方の選択肢（Ａ及びＢ）の選択を包含することが意図されていることを理解されるべきである。更なる実施例として、「Ａ、Ｂ、及び／又はＣ（A,B,and/or C）」及び「Ａ、Ｂ、及びＣのうちの少なくとも１つ（at least one of A,B,and C）」の場合、かかる表現は、第１のリストされた選択肢（Ａ）のみの選択、又は第２のリストされた選択肢（Ｂ）のみの選択、又は第３のリストされた選択肢（Ｃ）のみの選択、又は第１及び第２のリストされた選択肢（Ａ及びＢ）のみの選択、又は第１及び第３のリストされた選択肢（Ａ及びＣ）のみの選択、又は第２及び第３のリストされた選択肢のみの選択（Ｂ及びＣ）のみ、又は３つ全ての選択肢の選択（Ａ及びＢ及びＣ）を包含することが意図される。このことは、当該技術分野及び関連技術分野の当業者に明らかであるように、リストされたアイテムの数だけ拡張され得る。
【0015】
本明細書で説明される実施形態は、ゲームストリーミングとも呼ばれ得るクラウドゲーミングに関する。クラウドゲーミングは、（例えば、リモート）サーバ（本明細書では「ゲームサーバ」及び「サーバ」のいずれか、総称して「サーバ」と呼ばれる）上でゲームを実行し、その結果をビデオストリームとしてエンドユーザデバイスに送信する概念とみなすことができ、エンドユーザデバイスは、本明細書では「クラウドゲーミングクライアント」、「シンクライアントデバイス」、「クライアントゲームデバイス」、総称して「クライアントデバイス」のいずれかと呼ばれ得る。ゲームサーバ及びクライアントデバイスは、任意のタイプのネットワークを介して相互接続され得る。例えば、サーバは、クラウド内に配置されてもよく、ゲームは、サーバの任意の（例えば、タイプの）インスタンス上で実行されてもよい。
【0016】
簡単にするために、実施形態は、ビデオコンテンツ（例えば、ストリーミング）の例としてゲーム（例えば、ストリーミング）を参照することによって本明細書で説明される。本明細書で説明される実施形態は、ゲームストリーミングに限定されず、任意の種類のビデオコンテンツに適用可能であり得る。本明細書で説明される実施形態全体を通して、「ゲーム」及び「ビデオコンテンツ」という用語は、互換的に使用され得る。
【0017】
簡単にするために、本明細書では、実施形態は、セキュアリライアブルトランスポート（ＳＲＴ）プロトコル及びその関連するＳＲＴレイテンシを参照することによって説明される。ＳＲＴプロトコル（例えば、及びＳＲＴレイテンシ）は、本明細書で説明される実施形態に適用可能であり得るプロトコル（例えば、及びレイテンシ）の単なる例である。サーバにおいて生成され得るパケット（例えば、データ、ビデオフレーム）のレート（例えば、時間シーケンス）と同様であり得る（例えば、それを表し得る）パケット（例えば、データ、ビデオフレーム）のレート（例えば、時間シーケンス）をクライアントデバイスにおいて再現することが可能な任意のトランスポートプロトコル及び任意の種類のレイテンシ（例えば、管理システム）が、本明細書で説明される実施形態に適用可能であり得る。「ＳＲＴ（例えば、要求、応答、ハンドシェイク）メッセージ」及び「（例えば、要求、応答、ハンドシェイク）メッセージ」という用語は、本明細書で説明する実施形態全体を通して互換的に使用され得る。「ＳＲＴレイテンシ」及び「レイテンシ」という用語は、本明細書では互換的に使用され得る。
【0018】
図１は、ゲームストリーミングの高レベルアーキテクチャの例を示すシステム図である。クライアントデバイス１１は、サーバ１２（例えば、その専用インスタンス）上で実行され得るゲーム実行ファイルを実行しなくてもよい。サーバ（例えば、インスタンス）は、例えば、（例えば、クラウドプロバイダ及びオペレータのいずれかによって運用され得る）データセンタ内に位置し得る。サーバ１２は、例えば、グラフィック処理ユニット（graphics processing unit、ＧＰＵ）などの（例えば、高性能の）ハードウェアを含み得る。例えば、サーバ１２は、（例えば、所与のキャプチャ）レート（例えば、６０フレーム毎秒（frame per second、ＦＰＳ））でＧＰＵによってレンダリングされた（例えば、ゲームのシーンの）画像１２２を取得（例えば、キャプチャ）してもよい。取得された（例えば、キャプチャされた）画像は、クライアントデバイス１１に送信され（例えば、伝送され）得る、（例えば、ライブ）ビデオストリームに符号化され得る（１２１）ビデオフレームのフローをもたらし得る。ビデオストリームは、ゲームの（例えば、符号化された）ビデオフレームを搬送する複数のパケットを含んでもよい。クライアントデバイス１１上で、シンゲームクライアントアプリケーションは、このビデオストリームを受信し（例えば、聴取し）得、フレームが受信され得るときにフレームを復号し得、それらをクライアントデバイス１１のスクリーンに提示し（例えば、表示し）得る。
【0019】
クライアントデバイス１１は、これらのいくつかの動作（例えば、それらのみ）を実行することによって、軽量であり得る（限られた処理リソースを含み得る）。「ビデオストリーム」という用語は、例えば、トランスポート層オーバーヘッド及び（例えば、対応する）メタデータのいずれかを含む複数のパケットとして、ゲームサーバによってクライアントデバイスに伝送され得るゲームのビデオ（例えば、符号化された）フレームのセットを指定するために使用される。
【0020】
クラウドゲーミングでは、体感品質（ＱｏＥ）は、客観的要因及び主観的要因のいずれかに依存し得る。例えば、ＱｏＥは、ユーザコマンドに対する応答（例えば、応答時間、レイテンシ）、及びビデオの滑らかさ（video smoothness）と呼ばれ得るビデオスタッタリングの有無のいずれかに依存し得る。
【0021】
ビデオの滑らかさは、ＱｏＥに影響を与える重要な主観的要因であり得、それは、ユーザが寛容であり得るか又は適応し得る、応答時間又は視覚品質と同程度に重要であると思われる。ビデオスタッタリング（例えば、滑らかさの欠如）は、例えば、任意の数のフレームが、クライアントデバイスにおいてドロップ及び複製のいずれかが行われた場合に発生し得る（これは、クライアントスクリーン上で視認され得る）。フレーム複製（例えば、同じフレームを２回レンダリングすること）は、例えば、表示されるべき次のフレームについて（例えば、レイテンシの増加に起因して）受信、復号、及び表示が間に合わないことがある場合に発生し得る。同様に、フレームドロップ（例えば、スキップする、復号しない、フレームを表示しない）は、例えば、クライアントデバイスの受信バッファが満杯であり（例えば、バーストデータの到着に起因して）、いくつかのフレームが削除され得る場合に発生し得る。（例えば、クライアントバッファが満杯であることに起因して）削除され得るフレームは、例えば、そのフレームについてサーバ再送がもはや可能でない場合に、もはや受信されないおそれがある。
【0022】
クラウドゲーミングでは、ゲームのビデオフレームがクライアントデバイスによって受信され得る（例えば、クライアントデバイスに配信され得る）レートの規則性（例えば、不変性）は、例えば、ネットワークの（例えば、変化する）制約、符号化変動性、例えば、サーバインスタンス上で実行され得るゲーム実行ファイルの数にリンクされるサーバリソースの利用可能性（例えば、ディスクＩ／Ｏアクセス、ＣＰＵ、ＧＰＵ、及びエンコーダ機能共有のいずれか）、所与の時間におけるシーンの複雑さなどの任意の数の（例えば、変化する）条件（例えば、要因）によって悪影響を受け得る（例えば、影響が与えられ得る）。例えば、クライアントデバイススクリーン上で、例えば、（クライアントデバイスのメモリバッファ内の）フレームのオーバーフロー（それぞれアンダーフロー）に起因して、何らかのビデオスタッタリングが発生するおそれがあり、これは、クライアントデバイスにそれらの一部をドロップ（それぞれ複製）させ、レンダリングされたビデオのペース（例えば、レート規則性）を変更（例えば、劣化）させ得る。
【0023】
クラウドゲーミングでは、クライアントデバイスは、ビデオがスクリーン上にレンダリングされ得る前に、例えば、数１００ミリ秒の間、受信時にビデオをバッファリングするためのメモリバッファを含み得る。ビデオスタッタリング問題は、メモリバッファのサイズ（例えば、時間）を増加させることによって低減（例えば、除去）され得、これは、ＱｏＥにとって重要な要因と見なされ得る全体的なクラウドゲーミングレイテンシを増加させ得る。クラウドゲームレイテンシの低い（例えば、最小）値とビデオスタッタリングの低いレベル（例えば、なし）との両方を保つことによって推定されるべき妥協点（例えば、バランス）が存在し得る。
【0024】
（例えば、ライブ、リアル）条件は、ゲームセッション中に継続的に発展し得るので、クライアントデバイスにおけるジッタの散発的かつ長期の変動のいずれかの高い値が存在し得る。本明細書で説明される実施形態は、サーバ及びクライアントデバイスが（例えば、適切に）同期されたままであることを可能にする、（例えば、レイテンシを増加させることとビデオスタッタリングを低減することとの間の）バランスを（例えば、定期的に、繰り返し）調整することを可能にし得る。
【0025】
クラウドゲーミングレイテンシの例
クラウドゲーミングでは、高い応答性は、ストリーミングされたコンテンツをユーザのアクションに（例えば、迅速に）適合させることを可能にし得る。「クラウドゲーミングレイテンシ」という用語は、ゲームにおけるユーザのアクションとディスプレイ上のその効果との間の遅延を指すために使用され得る。クラウドゲーミングレイテンシは、以下を含み得る。
－パケットがクライアントデバイスによって送信され得る第１の時間と、応答パケットがサーバから受信され得る第２の時間との間のネットワークトランスポート遅延として見られ得る、ラウンドトリップ時間遅延（ＲＴＴ）。ＲＴＴは、例えば、現在のネットワーク状態、輻輳問題などに応じて、時間とともに変化し得る。
－サーバがフレームを符号化するための時間として見られ得る、処理遅延。この時間は、サーバ側のリソース管理に依存し得る。
－クライアントデバイスがフレームを復号し、それをスクリーン上に提示する（例えば、表示する）ための時間と見なされ得る、プレイアウト遅延。
－受信されたパケットがプレイアウトのためにアプリケーションに配信され得る前に、受信プロトコルスタック内の内部バッファにおいて費やされる時間として見られ得る、キューイング遅延。バッファリングのディメンジョニングは、設定であってもよく、設定は、スタートアップ時に事前に構成されたもの、選択された（例えば、決定された）もののいずれかであってもよい。例えば、バッファリングのディメンジョニングは、サーバとクライアントデバイスとの間でネゴシエートされ得る。
クラウドゲーミングでは、高い応答性は、ストリーミングされたコンテンツをユーザのアクションに（例えば、迅速に）適合させることを可能にし得る。「クラウドゲーミングレイテンシ」という用語は、ゲームにおけるユーザのアクションとディスプレイ上のその効果との間の遅延を指すために使用され得る。クラウドゲーミングレイテンシは、以下を含み得る。
－パケットがクライアントデバイスによって送信され得る第１の時間と、応答パケットがサーバから受信され得る第２の時間との間のネットワークトランスポート遅延として見られ得る、ラウンドトリップ時間遅延（ＲＴＴ）。ＲＴＴは、例えば、現在のネットワーク状態、輻輳問題などに応じて、時間とともに変化し得る。
－サーバがフレームを符号化するための時間として見られ得る、処理遅延。この時間は、サーバ側のリソース管理に依存し得る。
－クライアントデバイスがフレームを復号し、それをスクリーン上に提示する（例えば、表示する）ための時間と見なされ得る、プレイアウト遅延。
－受信されたパケットがプレイアウトのためにアプリケーションに配信され得る前に、受信プロトコルスタック内の内部バッファにおいて費やされる時間として見られ得る、キューイング遅延。バッファリングのディメンジョニングは、設定であってもよく、設定は、スタートアップ時に事前に構成されたもの、選択された（例えば、決定された）もののいずれかであってもよい。例えば、バッファリングのディメンジョニングは、サーバとクライアントデバイスとの間でネゴシエートされ得る。
【0026】
クラウドゲーミングレイテンシは、ゲーミングにおける楽しいユーザエクスペリエンスを可能にするために低い値に保たれ得る。例えば、１００ミリ秒～１５０ミリ秒のままであり得るクラウドゲーミングレイテンシは、例えば、一人称シューティングゲームのための楽しいユーザ体験を提供することを可能にし得る。
【0027】
クラウドゲーミングにおけるビデオストリーミングの例
図２は、クラウドゲーミングアーキテクチャにおけるビデオストリーミングの例を示すシステム図である。サーバ２１上で、ビデオキャプチャ及び符号化処理モジュール２１１は、ターゲットレート（例えば、６０Ｈｚ）でゲームによってレンダリングされる（複数の）フレームをキャプチャするように構成され得る。新しい符号化フレームは、処理モジュール２１１によって符号化され得、同じターゲットレートで出力され得る。（例えば、各）符号化フレームは、ユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）及び伝送制御プロトコル（transport control protocol、ＴＣＰ）のいずれかより上位の信頼できるストリーミングプロトコルを使用して、クライアントデバイス２２に伝送され得る。例えば、信頼できるストリーミングプロトコルの例は、例えば、Ｓｔａｄｉａのためのウェブリアルタイム通信プロトコル（web real time communication protocol、ＷＥＢＲＴＣ）、及び例えば、ＧｅＦｏｒｃｅ ＮｏｗのためのＵＤＰ上のリアルタイムプロトコル（real time protocol、ＲＴＰ）のうちのいずれかを含み得る。
図２は、クラウドゲーミングアーキテクチャにおけるビデオストリーミングの例を示すシステム図である。サーバ２１上で、ビデオキャプチャ及び符号化処理モジュール２１１は、ターゲットレート（例えば、６０Ｈｚ）でゲームによってレンダリングされる（複数の）フレームをキャプチャするように構成され得る。新しい符号化フレームは、処理モジュール２１１によって符号化され得、同じターゲットレートで出力され得る。（例えば、各）符号化フレームは、ユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）及び伝送制御プロトコル（transport control protocol、ＴＣＰ）のいずれかより上位の信頼できるストリーミングプロトコルを使用して、クライアントデバイス２２に伝送され得る。例えば、信頼できるストリーミングプロトコルの例は、例えば、Ｓｔａｄｉａのためのウェブリアルタイム通信プロトコル（web real time communication protocol、ＷＥＢＲＴＣ）、及び例えば、ＧｅＦｏｒｃｅ ＮｏｗのためのＵＤＰ上のリアルタイムプロトコル（real time protocol、ＲＴＰ）のうちのいずれかを含み得る。
【0028】
例えば、ライブビデオシステムでは、伝送は、輻輳、パケット損失、並べ替え、及びジッタのいずれかによって影響を受けることがある。パケット遅延到着及びパケット損失のいずれも、ビデオスタッタリング、ビデオフリーズ、及び視覚的障害のいずれかを生じさせ得る。プロトコルスタック（例えば、ネットワーク配信システム）は、これらの影響を補償（例えば、減衰）して、以下の技法のいずれかによってＱｏＥを改善することができる。
－パケットのバッファ２２２は、例えば、ネットワーク（例えば、時間配信）揺らぎを吸収するために使用され得る。
－前方誤り訂正（forward error correction、ＦＥＣ）などの情報の冗長性が、送信信頼性を改善するために使用され得る。
－例えば、受信機（セキュアリライアブルトランスポートプロトコル（ＳＲＴ）など）によって破損又は欠落していると検出された可能性があるパケットを再送するようにサーバに要求することによって、修復機構を使用することができる。
－パケットのバッファ２２２は、例えば、ネットワーク（例えば、時間配信）揺らぎを吸収するために使用され得る。
－前方誤り訂正（forward error correction、ＦＥＣ）などの情報の冗長性が、送信信頼性を改善するために使用され得る。
－例えば、受信機（セキュアリライアブルトランスポートプロトコル（ＳＲＴ）など）によって破損又は欠落していると検出された可能性があるパケットを再送するようにサーバに要求することによって、修復機構を使用することができる。
【0029】
キューイング遅延及びグローバルクラウドレイテンシを大幅に増加させ得る、例えば、秒単位で測定される重要なバッファリングを使用し得るビデオストリーミング技法があり得る。これらの技法は、ビデオバッファリングが低減され得る、クラウドゲーミング及びその対応する（例えば、超低）レイテンシ（＜１５０ｍｓ）予想に適用可能でないことがある。
【0030】
実施形態によれば、クライアントデバイス２２は、（例えば、ネットワークプロトコルスタックを通して）（例えば、ビデオフレームを搬送する）パケットを受信することができ、パケットは、復号２２２及び提示（例えば、表示）２２３のためにアプリケーションに配信され得る前に、バッファされ得る（例えば、受信機バッファ２２１に格納され得る）キューである。例えば、パケットは、（例えば、最大）時間制限の間、バッファ２２１に格納され得る。例えば、復号処理モジュール２２２は、（複数の）フレームを復号するために、クライアントデバイス上で利用可能な（例えば、任意の）ＨＷアクセラレーションを活用し得る。例として、ＧｅＦｏｒｃｅ Ｎｏｗ及びＳｔａｄｉａは、ＤｉｒｅｃｔＸビデオアクセラレーション（ＤＸＶＡ２）を使用することができる。復号ビデオフレームは、例えば、任意のティアリング効果を回避するために、（例えば、６０Ｈｚにおける）周期的ビデオ同期信号（本明細書ではＶＳｙｎｃと呼ばれ得る）に同期されて、スクリーンに提示され（例えば、スクリーン上に表示され）得る。
【0031】
例えば、何らかの理由（例えば、パケットジッタ、パケットエラー及び修復などのいずれかなど）に起因して、ビデオフレームは、（例えば、かなり）遅く復号されることがあり、ＶＳｙｎｃデッドライン時間の後のある時間（例えば、数ミリ秒）に提示モジュール２２３に利用可能になり得る。そのような場合、前のビデオフレームは、スクリーン上で２つのＶＳｙｎｃ期間にわたって提示され（例えば、表示され）得、最後に復号されたビデオフレームは、次のＶＳｙｎｃ期間（例えば、１６．６６ｍｓ後）に延期され得る。欠落した（例えば、遅い）フレームの（例えば、いくつかの、全ての）発生に対してこのプロセスが繰り返される場合、スクリーン上に提示された（例えば、表示された）ビデオフレームとサーバによって生成された（例えば、符号化）ビデオフレームとの間の遅延は、時間とともに累積し得、シフトし得る。例えば、（例えば、ある時点において）、クライアントデバイスは、任意の数の（例えば、かなり）遅い復号ビデオフレームをスキップすることによってビデオソース（例えば、符号化レート）と再同期し、最後に受信されたものを提示（例えば、表示）し得る。例えば、表示されるビデオフレームのシーケンスは、キャプチャされたビデオフレームのシーケンスと厳密に同一ではない場合があるのは、それらが、ビデオスタッタリングの原因となり得る、繰り返されたフレーム及びスキップされたフレームのいずれかを含み得るからである。
【0032】
例えば、（ティアリングのリスクを生じ得る）ＶＳｙｎｃを無効にすることは、ビデオスタッタリングが生じることを防止しないおそれがある。（例えば、連続する）復号フレーム間の相互間遅延が一定でない場合、ビデオフレームは、同じ時間量の間表示されないことがあり、それは何らかのビデオスタッタリングを生じさせ得る。
【0033】
ＳＲＴプロトコルの例
セキュアリライアブルトランスポートプロトコル（ＳＲＴ）は、クラウドゲーミングに使用され得るストリーミングプロトコルの一例である。
セキュアリライアブルトランスポートプロトコル（ＳＲＴ）は、クラウドゲーミングに使用され得るストリーミングプロトコルの一例である。
【0034】
ＳＲＴは、当初、ビデオストリーミングアプリケーションに対処するためにビデオストリーミング会社（Haivision）によって内部的に開発された。ＳＲＴは、ＨａｉｖｉｓｉｏｎとＷｏｗｚａによって設立されたＳＲＴアライアンスによってサポートされる。ＳＲＴはまた、２０２０年９月９日に発行されたインターネットエンジニアリングタスクフォース（ＩＥＴＦ）ドラフト「Ｔｈｅ ＳＲＴ ｐｒｏｔｏｃｏｌ ｄｒａｆｔ－ｓｈａｒａｂａｙｋｏ－ｍｏｐｓ－ｓｒｔ－０１」として利用可能であり得る。
【0035】
ＵＤＰベースのデータ転送（ＵＤＴ）プロトコルに基づいて、ＳＲＴパケットは、パケット番号、メッセージ番号、タイムスタンプ、宛先ソケット識別子などのいずれかを示す情報を含み得るＳＲＴヘッダを含み得る。ＳＲＴパケットは、例えば、制御タイプ（制御パケット用）及びデータタイプ（データパケット用）などの異なるタイプであり得る。制御パケットは、セッション管理、肯定応答などのいずれかのために使用され得る。データパケットは、ストリームデータ（例えば、ビデオ／オーディオフレームを搬送するパケット）を配信するために使用され得る。
【0036】
実施形態によれば、ＳＲＴは、パケットをアプリケーションに適時に配信することを可能にし得る。例えば、ＳＲＴは、パケットがＳＲＴで取り込まれたタイミングに対応するタイミングでパケットをアプリケーションに送信することを可能にし得る。
【0037】
実施形態によれば、ＳＲＴは、遅いパケットを再送しないことを可能にし得る。例えば、ＳＲＴは、アプリケーションに問題なくかつタイムリーに配信されるには遅すぎる可能性があるパケットを識別し、それらの再送を停止することができる。
【0038】
実施形態によれば、ＳＲＴは、ＡＣＫ及びＡＣＫＡＣＫメカニズムを使用してＲＴＴを（例えば、定期的に、繰り返し）推定することを可能にし得る。
【0039】
ＳＲＴバッファレイテンシの例
図３は、ＳＲＴレイテンシバッファにおけるレイテンシウィンドウ動作の例を示す図である。例えば、（例えば、ゲーム）サーバは、送信機Ｔｘバッファ３１及び送信機Ｒｘバッファ３３を含み得る。例えば、クライアントデバイスは、受信機Ｒｘバッファ３２及び受信機Ｔｘバッファ３４を含み得る。サーバデバイスバッファ３１及びクライアントデバイスバッファ３２のサイズは、バッファ３１、３２内のウィンドウ３１０、３２０に対応し得、本明細書ではレイテンシウィンドウと呼ばれ得る。例えば、サーバ送信機Ｔｘバッファ３１及びクライアントデバイス受信機Ｒｘバッファ３２のための同じ長さのレイテンシウィンドウ３１０、３２０は、本明細書に記載のように、ＳＲＴ拡張ハンドシェイク中に、例えば、セッション確立中に、サーバとクライアントデバイスとの間でネゴシエートされ得る。
図３は、ＳＲＴレイテンシバッファにおけるレイテンシウィンドウ動作の例を示す図である。例えば、（例えば、ゲーム）サーバは、送信機Ｔｘバッファ３１及び送信機Ｒｘバッファ３３を含み得る。例えば、クライアントデバイスは、受信機Ｒｘバッファ３２及び受信機Ｔｘバッファ３４を含み得る。サーバデバイスバッファ３１及びクライアントデバイスバッファ３２のサイズは、バッファ３１、３２内のウィンドウ３１０、３２０に対応し得、本明細書ではレイテンシウィンドウと呼ばれ得る。例えば、サーバ送信機Ｔｘバッファ３１及びクライアントデバイス受信機Ｒｘバッファ３２のための同じ長さのレイテンシウィンドウ３１０、３２０は、本明細書に記載のように、ＳＲＴ拡張ハンドシェイク中に、例えば、セッション確立中に、サーバとクライアントデバイスとの間でネゴシエートされ得る。
【0040】
サーバ側では、（例えば、循環）レイテンシバッファ３１が、ビデオエンコーダから取得された符号化ビデオフレームのフラグメント化から取得されたＳＲＴパケットを格納するために使用され得る。例えば、ＳＲＴパケットは、ＳＲＴレイテンシ値に関連付けられた時間量の間、再送のために（例えば、循環）レイテンシバッファ３１に保持されてもよい。これらのパケットは、例えば、ＳＲＴセッションの作成時間に対して（例えば、ＳＲＴセッションが確立されたであろう時間に対して）相対的にタイムスタンプ付与され得る。例えば、時間値は、ＳＲＴセッションの作成時に初期化されてもよく、（例えば、システム）クロックに基づいて増分されてもよい。（例えば、システム）クロックは、例えば、ＳＲＴセッションの開始から経過したＣＰＵサイクル数の尺度に基づく定常クロックであってもよい。例えば、（例えば、各）パケットは、サーバ送信機Ｔｘバッファ３１内のパケットの格納に関連付けられた時間を示すタイムスタンプ情報を含み得る。例えば、タイムスタンプ情報は、パケット送信時間（例えば、パケットがクライアントデバイスに（例えば、初めて）伝送されたときを示すことができる。別の例では、タイムスタンプ情報は、パケット起点時間（例えば、パケットが作成され、送信側Ｔｘバッファ３１に格納（例えば、挿入）されたとき（例えば、送信時間の前、後、及び（例えば、最初の）送信時間のいずれか））を示すことができる。異なるパケットがエンコーダから取得された（例えば、サーバ送信機Ｔｘバッファ３１に格納された）時間値に対応するタイムスタンプ情報がパケットに挿入されてもよい。（例えば、タイムスタンプ情報によって示される異なる時間を有する）異なるパケットは、（例えば、制限された）時間量の間、バッファ中に残り得る。例えば、パケットは、肯定応答（ＡＣＫ）がそのパケットに対して受信され得るまで、バッファ内に残り得る。例えば、パケットは、送信機レイテンシウィンドウ（sender latency window、ＳＬＷ）の終了（例えば、それに対応する時間）までバッファ中に残り得る。パケットの受信がクライアントデバイスによって（例えば、タイムアウト内に）肯定応答されておらず、パケットのタイムスタンプ情報によって示される時間がＳＬＷ内に残っている場合、パケットは、送信機によって再送され得る。そうでない場合（例えば、パケットのタイムスタンプ情報が、パケットがＳＬＷを超えてバッファに記憶されていることを示す場合）、パケットはドロップされ得、サーバは、パケットの再送を停止し得る。遅いパケットの再送を停止することは、クライアント側の受信機レイテンシウィンドウ（receiver latency window、ＲＬＷ）内にもはや存在しないパケットが、表示されるのに間に合うように復号されない可能性があるので、無用な伝送を回避することを可能にし得る。
【0041】
クライアントデバイス側では、受信機レイテンシバッファ３２は、例えば、（復号及びレンダリングのために）それらをアプリケーションに配信する時間が生じ得るまで、受信されたパケットを記憶する（例えば、保持する）ために使用され得る。例えば、パケットは、パケット中に含まれるタイムスタンプ情報によって示される時間と、（例えば、ローカル、システム）時間との間の比較に基づいて、復号されるために、受信機レイテンシバッファ３２から抽出され得る。例えば、パケットは、パケットがサーバの送信機レイテンシバッファ３１に挿入された（例えば、第１の時間に伝送された）可能性がある時間と、クライアントデバイスによる正常な受信の後にパケットがクライアントデバイスの受信機レイテンシバッファ３２から抽出され得る時間との間に経過した可能性がある（例えば、一定の）時間量の後に復号されるために抽出され得る。（例えば、一定の）時間量は、少なくとも連続する（例えば、引き続く）パケットのセットに対して一定であり得る。（例えば、一定の）時間量は、ＳＲＴレイテンシ値に関連付けられ得る。例えば、（例えば、一定の）時間量は、少なくとも、ＳＲＴレイテンシ値と、ＲＴＴを表す初期値（例えば、（例えば、ＳＲＴハンドシェイク交換中に測定され得る）初期ＲＴＴの半分など）との和に相当し得る。パケットタイムスタンプは、パケットが送信機側で（例えば、エンコーダによって）生成された可能性があるペース（例えば、タイミング）を受信機側で反映することを可能にし得る。クライアントデバイスにおいて送信機ペースを反映することは、アプリケーションについてのジッタを排除することを可能にし得る。これは、アプリケーションが小さい（例えば、制限された）バッファリングを有することを可能にし得る。例えば、ＳＲＴ受信機は、例えば、パケット番号付けに基づいてパケットを並べ替えることができる。例えば、ＳＲＴ受信機は、例えば、パケット番号のシーケンスにおけるホール（例えば、不連続性）に基づいて、欠落パケットを検出してもよい。例えば、非肯定応答パケット（本明細書ではＮＡＫと呼ばれ得る）をサーバに伝送することによって、任意の数の欠落パケットが報告されることがあり、それが欠落パケットの再送をトリガする場合がある。（例えば、並べ替えられた）パケットがアプリケーションに配信され得た後、クライアントデバイスは、肯定応答パケット（本明細書ではＡＣＫと呼ばれ得る）を送信し得る。例えば、ＡＣＫ及びＮＡＫのいずれも、規則的かつ構成可能な間隔ベース（例えば、１０ｍｓ）で送信され得る。
【0042】
図４は、ＳＲＴにおける肯定応答動作の例を示す図である。ＡＣＫメッセージ４１は、ＳＲＴ受信機がＲＴＴ（及び任意のＲＴＴ分散値）を計算することを可能にするために、ＳＲＴ送信機によるＡＣＫＡＣＫメッセージ４２の伝送をトリガするために、ＳＲＴ受信機によって伝送されてもよい。例えば、伝送されたパケットの数がＡＣＫ期間４０内で多い場合、例えば、いかなるＡＣＫＡＣＫ伝送及びＲＴＴ測定もトリガせずに、パケットに肯定応答するためにライトＡＣＫ４３メッセージが伝送され得る。
【0043】
実施形態によれば、アプリケーションにパケットを（例えば、復号及び表示のために）配信するのに間に合うようにはパケットが受信されていない場合、パケットを（再）伝送しようとする更なる試みは、サーバによって行われなくてもよい。例えば、パケットは、その予想抽出時間（例えば、タイムスタンプ情報において示される時間の後の（例えば、一定の）時間量に相当し、（例えば、一定の）時間量は、ＳＲＴレイテンシ値に関連付けられている）の後に受信される場合に、時間内に受信されていないとみなされてもよい。パケットが時間内に受信されなかった場合、クライアントデバイス（例えば、受信機スタック）は、パケットが受信された場合と同じ方法でその受信機レイテンシウィンドウを進めてもよい。同様に、サーバは、パケットが問題なく伝送されたかのように、その送信側レイテンシウィンドウを進めてもよい。
【0044】
実施形態によれば、（例えば、受信機、送信機の）レイテンシウィンドウは、（例えば、予測可能な）有限レイテンシを提供することを可能にし得る。例えば、低減されたレイテンシは、ネットワーク条件に応じて、より多くのパケットを失うリスクで取得され得る。
【0045】
ＳＲＴ拡張ハンドシェイクの例
ＳＲＴは、ＳＲＴ拡張ハンドシェイクプロセス（本明細書ではＨＳｖ５と呼ばれ得る）を含み得る。ＳＲＴ拡張ハンドシェイクプロセスは、ＳＲＴコーラ－リスナハンドシェイクの第２の部分に含まれてもよい。ＳＲＴ拡張ハンドシェイクは、少なくとも送信方向におけるＳＲＴレイテンシ値（本明細書では、送信機ＳＲＴレイテンシ及びＳｎｄＴｓｂＰｄＤｅｌａｙのいずれかと呼ばれ得る）と、受信方向におけるＳＲＴレイテンシ値（本明細書では、受信機ＳＲＴレイテンシ及びＲｃｖＴｓｂＰｄＤｅｌａｙのいずれかと呼ばれ得る）と、を決定することを可能にし得る。送信機及び受信機のＳＲＴレイテンシ情報（例えば、フィールド）の両方は、レイテンシを指してもよい。通信は双方向であり得るので、拡張ＳＲＴハンドシェイクメッセージにおいて方向ごとに１つのレイテンシ値が存在し得る。例えば、拡張ハンドシェイク要求（ＨＳＲＥＱ）メッセージ及び拡張ハンドシェイク応答（ＨＳＲＳＰ）メッセージの両方は、送信機及び受信機のＳＲＴレイテンシ情報（例えば、ＳｎｄＴｓｂＰｄＤｅｌａｙ及びＲｃｖＴｓｂＰｄＤｅｌａｙ）を含み得る。
ＳＲＴは、ＳＲＴ拡張ハンドシェイクプロセス（本明細書ではＨＳｖ５と呼ばれ得る）を含み得る。ＳＲＴ拡張ハンドシェイクプロセスは、ＳＲＴコーラ－リスナハンドシェイクの第２の部分に含まれてもよい。ＳＲＴ拡張ハンドシェイクは、少なくとも送信方向におけるＳＲＴレイテンシ値（本明細書では、送信機ＳＲＴレイテンシ及びＳｎｄＴｓｂＰｄＤｅｌａｙのいずれかと呼ばれ得る）と、受信方向におけるＳＲＴレイテンシ値（本明細書では、受信機ＳＲＴレイテンシ及びＲｃｖＴｓｂＰｄＤｅｌａｙのいずれかと呼ばれ得る）と、を決定することを可能にし得る。送信機及び受信機のＳＲＴレイテンシ情報（例えば、フィールド）の両方は、レイテンシを指してもよい。通信は双方向であり得るので、拡張ＳＲＴハンドシェイクメッセージにおいて方向ごとに１つのレイテンシ値が存在し得る。例えば、拡張ハンドシェイク要求（ＨＳＲＥＱ）メッセージ及び拡張ハンドシェイク応答（ＨＳＲＳＰ）メッセージの両方は、送信機及び受信機のＳＲＴレイテンシ情報（例えば、ＳｎｄＴｓｂＰｄＤｅｌａｙ及びＲｃｖＴｓｂＰｄＤｅｌａｙ）を含み得る。
【0046】
例えば、送信機ＳＲＴレイテンシは、ＳＲＴ受信機が使用することをＳＲＴ送信機が予期し得る（例えば、最低）レイテンシに相当し得る。例えば、受信機ＳＲＴレイテンシは、受信機が受信ストリームに適用し得る（例えば、最低）レイテンシ値に相当し得る。
【0047】
例えば、クライアントデバイスは、拡張ハンドシェイク要求（ＨＳＲＥＱ）メッセージをサーバに送信し得る。拡張ＨＳＲＥＱメッセージは、（例えば、要求された）受信機ＳＲＴレイテンシ値を示す受信機ＳＲＴレイテンシ情報を含んでもよい。例えば、サーバは、拡張ハンドシェイク応答（ＨＳＲＳＰ）メッセージをクライアントデバイスに送信し得る。拡張ＨＳＲＳＰメッセージは、（例えば、応答された）送信機ＳＲＴレイテンシ値を示す送信機ＳＲＴレイテンシ情報を含んでもよい。実施形態によれば、サーバ及びクライアントデバイスは、それぞれ送信バッファ及び受信バッファ内のそれぞれのＳＲＴレイテンシ値を、２つの値（例えば、要求された受信機レイテンシ値及び応答された送信機レイテンシ値）のうちの最も高い同じ値に設定し得る。
【0048】
図５は、拡張ＳＲＴハンドシェイク手順後の受信機及び送信機のバッファレイテンシの例を示す図である。拡張ＳＲＴハンドシェイクは、両方向（送信方向及び受信方向）における送信機及び受信機のＳＲＴレイテンシ値を決定することを可能にし得る。例えば、コーラは、その側の（例えば、Ｒｘ、Ｔｘの）ＳＲＴレイテンシ値を示す第１の情報を含む拡張ＨＳＲＥＱメッセージを送信し得る。リスナは、受信した拡張ＨＳＲＥＱに含まれるＳＲＴレイテンシ値と自身の値との間の最高値を計算し得る。リスナは、（例えば、両側で）使用されるＳＲＴレイテンシ値を示す第２の情報を含む拡張ＨＳＲＳＰメッセージを送信し得る。言い換えれば、ＳＲＴ（例えば、バッファ）レイテンシは、イニシエータとレスポンダ（サーバ及びクライアントデバイスのいずれかであり得る）との間の拡張ハンドシェイクプロセス中のレイテンシ情報の交換を通して構成され得る。ハンドシェイク拡張メッセージは、ＳＲＴ受信機及びＳＲＴ送信機の両方からの、ミリ秒単位のＳＲＴレイテンシ値を示すタイムスタンプベースのパケット配信（ＴＳＢＰＤ）遅延情報を含んでもよい。接続のためのＳＲＴレイテンシは、イニシエータ及びレスポンダによって伝送されるＳＲＴレイテンシの最高値として確立され得る（例えば、最高値に設定され得る）。例えば、ＳＲＴレイテンシ値は、接続の持続時間に対して設定されてもよい。
【0049】
フレーム間遅延変動の例
実施形態によれば、クラウドゲーミングの状況では、クライアントデバイスにおいてビデオスタッタリングが発生するおそれがあり、ユーザにとって不快なユーザ体験をもたらす。例えば、プロトコルスタックの出力におけるビデオフレーム（例えば、ビデオフレームを搬送するパケット）の配信時間を監視するために、ソフトウェアプローブを使用して、クライアントデバイス（例えば、ＤＸＶＡ２ ＡＰＩなど）の復号機能への呼出しを追跡することができる。例えば、１秒当たりに受信された符号化フレームの数は、サーバ上で１秒当たりに生成されたフレームの数に等しくてもよい。例えば、受信時の平均フレーム数毎秒（ＦＰＳ）は、サーバにおけるＦＰＳと同一であり得るが、例えば、フレーム間遅延に関して、いくらかの分散が測定され得る。
実施形態によれば、クラウドゲーミングの状況では、クライアントデバイスにおいてビデオスタッタリングが発生するおそれがあり、ユーザにとって不快なユーザ体験をもたらす。例えば、プロトコルスタックの出力におけるビデオフレーム（例えば、ビデオフレームを搬送するパケット）の配信時間を監視するために、ソフトウェアプローブを使用して、クライアントデバイス（例えば、ＤＸＶＡ２ ＡＰＩなど）の復号機能への呼出しを追跡することができる。例えば、１秒当たりに受信された符号化フレームの数は、サーバ上で１秒当たりに生成されたフレームの数に等しくてもよい。例えば、受信時の平均フレーム数毎秒（ＦＰＳ）は、サーバにおけるＦＰＳと同一であり得るが、例えば、フレーム間遅延に関して、いくらかの分散が測定され得る。
【0050】
実施形態によれば、フレームペース変動（例えば、フレーム間遅延の変動など）の尺度（例えば、メトリック）は、本明細書ではジッタローカルと呼ばれ得る。ジッタローカルは、ジッタメトリックを平均周期で除算することによって取得され得る。例えば、ジッタｌｏｃａｌは、次のように与えることができる：
【0051】
【数1】
【0052】
ジッタメトリックは、連続する間隔持続時間間の差の和として定義されてもよく、間隔持続時間は、あるフレーム時間と前のフレーム時間との間の持続時間を表してもよい。例えば、ジッタメトリックは、次のように与えることができる：
【0053】
【数2】
【0054】
例えば、Ｔｉは、ｉ番目のフレームに関連付けられた第１の時間と、先行する（ｉ－１）番目のフレームに関連付けられた第２の時間との間のｉ番目の間隔の持続時間を表し得る。例えば、持続時間は、（例えば、外れ値を排除するために）１～３２ミリ秒に含まれるという条件で、ジッタメトリックに含まれ得る。
【0055】
図６Ａ及び図６Ｂは、クライアントデバイス上で測定されたフレーム間遅延変動メトリック（ジッタローカル）の２つの例を示す２つの図である。図６Ａは、ファイバネットワーク（例えば、２００Ｍｂｐｓ）を使用して、特定のゲーム（一人称シューティングゲーム、例えば、Ｄｅｓｔｉｎｙ ２）の１３分のゲームセッションについて取得されたフレーム間遅延変動メトリック（ジッタローカル）を示す。図６Ｂは、５０秒の期間６１上のズームについて同じゲームに対して取得されたフレーム間遅延変動メトリック（ジッタローカル）を示す。
【0056】
フレーム間遅延変動の値が大きい例
例えば、サービスプロバイダは、強度のクラウドゲーミングレイテンシ（例えば、約１２０ｍｓ）を有するクラウドゲーミングソリューションを運用してもよく、そのレイテンシを可能な限り小さく維持しようとしてもよい。ゲーミングセッションの間、小さなレイテンシ値は、プレーヤの入力に対する反応性を改善することを可能にし得る。（例えば、レイテンシ及びビデオの滑らかさを考慮した）（例えば、グローバルな）ＱｏＥは、ビデオスタッタリング問題に起因してスケールダウンされ得、これにより、例えば、ユーザは、システム不調に悩まされるおそれがある。
例えば、サービスプロバイダは、強度のクラウドゲーミングレイテンシ（例えば、約１２０ｍｓ）を有するクラウドゲーミングソリューションを運用してもよく、そのレイテンシを可能な限り小さく維持しようとしてもよい。ゲーミングセッションの間、小さなレイテンシ値は、プレーヤの入力に対する反応性を改善することを可能にし得る。（例えば、レイテンシ及びビデオの滑らかさを考慮した）（例えば、グローバルな）ＱｏＥは、ビデオスタッタリング問題に起因してスケールダウンされ得、これにより、例えば、ユーザは、システム不調に悩まされるおそれがある。
【0057】
図６Ａ及び図６Ｂに示されるように、測定されたジッタローカルは、０．２の平均値を有する０．４を上回るいくつかの位相に起因する高レベルのフレーム間遅延変動を示し得る。例えば、図６Ｂは、４秒間の０．５を超えるジッタローカル（例えば、フレーム＃１０５００～＃１０７５０）のシーケンスを示す。０．５のジッタローカル値は、フレーム間平均遅延の±５０％の変動を表し得る。例えば、（例えば、６０フレーム毎秒のフレーム間遅延を表し得る）１６．６６ｍｓの平均遅延の場合、ジッタ変動は［８ｍｓ～２４ｍｓ］に属し得る。例えば、そのような変動、及び、例えば、所与の閾値（例えば、この例では０．２）を上回るジッタローカル値は、ビデオスタッタリングの存在に相関され得る。ジッタローカル値は、ビデオスタッタリング発生の頻度に相当してもよく、例えば、ジッタローカル値が高いほど、ビデオ内のスタッタリング発生の頻度が高い。
【0058】
フレーム間遅延変動（例えば、ジッタローカル）は、以下の理由のいずれかのために増加し得る。
－第１の理由は、ネットワーク条件の変動（例えば、ＲＴＴの変動、輻輳のいずれかの発生、及びエラー（例えば、損失）回復に関連付けられた時間量だけ（複数の）ビデオフレームの利用可能性を遅延させ得るネットワークエラー）に関連し得る。
－第２の理由は、キャプチャレート、符号化レート、及びビデオフレーム（例えば、ビデオフレームを搬送するパケット）の送達のいずれかに影響を及ぼし得るサーバ条件の変動に関連し得る。符号化パラメータ（例えば、関心があるゾーンによる圧縮）、画像のタイプ（例えば、Ｉ対Ｐ対イントラリフレッシュ画像）、及び画像内の動きの量のいずれも、符号化持続時間、符号化画像のサイズ、次いで送信（例えば、伝送）時間のいずれかに影響を及ぼし得る。例えば、フレーム時間到着時に観測され得るジッタは、符号化のジッタに相関する（例えば、相当する）場合がある。
－他の理由は、例えば、実行中のゲームの現在の状態（及び対応する画像の複雑さ）、サーバ上の同時ストリーミングフローの存在、並びに（例えば、一定の）ＦＰＳでフレームをレンダリングするために利用可能なＧＰＵ電力など、サーバにおけるリソース利用可能性に関連し得る。
－第１の理由は、ネットワーク条件の変動（例えば、ＲＴＴの変動、輻輳のいずれかの発生、及びエラー（例えば、損失）回復に関連付けられた時間量だけ（複数の）ビデオフレームの利用可能性を遅延させ得るネットワークエラー）に関連し得る。
－第２の理由は、キャプチャレート、符号化レート、及びビデオフレーム（例えば、ビデオフレームを搬送するパケット）の送達のいずれかに影響を及ぼし得るサーバ条件の変動に関連し得る。符号化パラメータ（例えば、関心があるゾーンによる圧縮）、画像のタイプ（例えば、Ｉ対Ｐ対イントラリフレッシュ画像）、及び画像内の動きの量のいずれも、符号化持続時間、符号化画像のサイズ、次いで送信（例えば、伝送）時間のいずれかに影響を及ぼし得る。例えば、フレーム時間到着時に観測され得るジッタは、符号化のジッタに相関する（例えば、相当する）場合がある。
－他の理由は、例えば、実行中のゲームの現在の状態（及び対応する画像の複雑さ）、サーバ上の同時ストリーミングフローの存在、並びに（例えば、一定の）ＦＰＳでフレームをレンダリングするために利用可能なＧＰＵ電力など、サーバにおけるリソース利用可能性に関連し得る。
【0059】
散発性及び長持続時間フレーム間遅延変動の例
例えば、復号ビデオフレームがそれらの提示時間に表示のために利用可能であり得るように、ジッタを吸収し、より滑らかな復号フレームレートを得るために、恒常的な臨時のバッファリングがクライアントデバイス側に含まれ得る。
例えば、復号ビデオフレームがそれらの提示時間に表示のために利用可能であり得るように、ジッタを吸収し、より滑らかな復号フレームレートを得るために、恒常的な臨時のバッファリングがクライアントデバイス側に含まれ得る。
【0060】
図６Ａに示されるように、フレーム間遅延変動は、経時的に一定でなくてもよく、ゲームセッション中に著しく変動してもよく、例えば、異なる時間において、長期間の間に散発的な高い値を有してもよい。そのような状況（例えば、図６Ｂに示されるフレーム＃８０００～＃１１０００のジッタローカル値）では、大幅な臨時のバッファリングは、スタッタリングを防止し、全てのケースをカバーすることを可能にし得、これは、ゲームのレイテンシを有意に増加させ得、ＱｏＥを減少させ得る。例えば、大幅な臨時のバッファリングを追加することは、この種のパラメータがセッションの持続時間にわたって（例えば、セッションの開始時に）設定され得るという事実により、ゲームセッション全体に影響を及ぼし得る。
【0061】
図７は、ＳＲＴに基づくクラウドゲーミングシステムの例を示すシステム図である。実施形態によれば、クラウドゲーミングシステムは、ゲームのＱｏＥを改善することを可能にし得る。ゲームは、サーバインスタンス７１上で実行することができる。（例えば、実行中の）ゲームの画像は、エンコーダ７１１によってキャプチャされ、例えば、所与の符号化フレームレートで符号化され得る。符号化フレームは、カプセル化処理モジュール７１２によって複数のパケットにカプセル化され得る。パケットは、例えば、ＳＲＴプロトコルに基づいて、クライアントデバイスに伝送され得る。例えば、伝送の前に、パケットは、修復モジュール７１３を介して（例えば、非肯定応答された）パケットを再送することができるように、送信機ＳＲＴバッファ７１４に記憶されてもよい。パケットは、パケットが生成され、送信され、送信機ＳＲＴバッファに記憶された時間に関連付けられたタイムスタンプ情報でタイムスタンプ付与されてもよい（例えば、タイムスタンプを含んでもよい）。サーバインスタンス７１は、クライアントデバイス７２とのＳＲＴメッセージの交換に基づいて、送信機ＳＲＴバッファ７１４のサイズを調整するように構成され得るレイテンシマネージャモジュール７１５を含んでもよい。
【0062】
実施形態によれば、クライアントデバイス７２は、例えば、ＳＲＴプロトコルを介して、ゲームのビデオフレームを搬送する複数のパケットを受信することができる。受信されたパケットは、受信機ＳＲＴバッファ７２４に記憶され、ＳＲＴバッファレイテンシと、パケットに含まれるタイムスタンプ情報と、に基づいて抽出されて、脱カプセル化モジュール７２２によって脱カプセル化され、復号モジュール７２７によって復号され得る。復号モジュール７２７は、復号フレームキュー７２８に格納（例えば、プッシュ通知）され得るビデオフレームを生成することができる。提示モジュール７２９は、Ｖｓｙｎｃ信号に基づいて表示されるためのビデオフレームを検索する（例えば、ポップする）ことができる。
【0063】
実施形態によれば、クライアントデバイス７２は、スタッタリングのレベルを監視（例えば、検出、予測）するように構成され得るスタッタリング監視モジュール７２６を含んでもよい。クライアントデバイス７２は、ＳＲＴメッセージをサーバと交換することに基づいて、受信機ＳＲＴバッファ７２４のサイズを調整するように構成され得るレイテンシマネージャモジュール７２５を含み得る。
【0064】
実施形態によれば、ＳＲＴプロトコル及びそのレイテンシバッファは、サーバ側のプロダクション出力７１０と同じペースでクライアントデバイスプロトコルスタック７２０の出力においてビデオフレームを利用可能にすることによって、ビデオスタッタリングを低減することを可能にし得る。
【0065】
本明細書で説明される実施形態は、ＱｏＥを改善するためにＳＲＴバッファレイテンシをダイナミックに適応させる（例えば、調整する）ために、例えば、ゲームセッション中に（例えば、ゲームセッションの開始に加えて）、クライアントデバイスとサーバとの間でレイテンシ情報を（例えば、ダイナミックに）交換することを可能にし得る。
【0066】
例えば、クライアントデバイスは、いくつかのメトリックを（例えば、定期的に）監視して、ビデオスタッタリングの（複数の）発生（例えば、及びレベル）を検出し、かつ予測することができる。
【0067】
実施形態によれば、クライアントデバイス及びサーバのいずれかは、例えば、フレームペース変動（例えば、監視されたスタッタリング（例えば、レベル、予測レベル）など）に基づいて、ＳＲＴバッファに設定される新しいＳＲＴレイテンシ値を決定してもよい。
【0068】
実施形態によれば、クライアントデバイスは、クライアントデバイス（例えば、そのレイテンシマネージャモジュール）によって決定（例えば、選択）され得る新しいＳＲＴバッファレイテンシにサーバを同期させるために、ＳＲＴ制御メッセージを交換してもよい。サーバは、クライアントデバイスと対話するためのレイテンシマネージャモジュールを含み得る。
【0069】
実施形態によれば、クライアントデバイスのプレゼンテーションモジュール７２９の同期は、ビデオフレームスキップを低減するために新しいＳＲＴバッファレイテンシ値を考慮するために、ＳＲＴレイテンシ値の変化に基づいて（例えば、ダイナミックに）調整されてもよい。
【0070】
スタッタリング検出の例
例えば、スタッタリング監視モジュールは、プロトコルスタックの出力のいずれかにおいて、及び復号モジュール７２３の出力において（例えば、復号の前後のいずれかにおいて）、（例えば、ビデオフレームを搬送するパケットが受信機ＳＲＴバッファ７２４から抽出された時間に相当する）フレームの到達時間を取得（例えば、監視）してもよい。
例えば、スタッタリング監視モジュールは、プロトコルスタックの出力のいずれかにおいて、及び復号モジュール７２３の出力において（例えば、復号の前後のいずれかにおいて）、（例えば、ビデオフレームを搬送するパケットが受信機ＳＲＴバッファ７２４から抽出された時間に相当する）フレームの到達時間を取得（例えば、監視）してもよい。
【0071】
例えば、スタッタリング監視モジュールは、１つのフレームを搬送するパケットのセットの最初のパケット及び最後のパケットのいずれかの到達時間を監視することができる。例えば、パケットは、パケットがビデオフレームの最初のパケットに相当するか、又は最後のパケットに相当するかを示すシグナリング情報を含んでもよい。
【0072】
例えば、（例えば、ビデオスタッタリングレベル及びフレームペース変動のいずれかを表す）メトリックは、クライアントデバイス内の任意の点における任意の監視された到達時間（例えば、フレーム、パケットのいずれか）に分散関数を適用することによって取得され得る。分散関数は、（例えば、スライディング）ウィンドウに適用されるフレーム間遅延変動（ジッタローカル）関数、平均値、中央値、標準偏差、分散、平均絶対偏差（mean absolute deviation、ＭＡＤ）、四分位数範囲、及び任意の他のタイプの範囲関数（例えば、［２５％～７５％］の範囲を超える）のいずれかに基づき得る。
【0073】
例えば、スタッタリング監視モジュールは、１秒当たりの遅延フレーム数（例えば、ＶＳｙｎｃを逃した可能性があるフレーム）及び１秒当たりのドロップフレーム数（例えば、復号フレームキュー７２８のオーバーフローの場合）のいずれかを取得する（例えば、監視する）ことができる。例えば、スタッタリング監視モジュールは、（同じ期間の間）フレームの第１の数対フレームの第２の数の比を取得してもよく、第１の数は、時間内に（例えば、それらの提示時間に従って）表示されるフレームに相当してもよく、フレームの第２の数は、表示されるフレームの総数（例えば、重複フレームを含む）に相当してもよい。
【0074】
例えば、受信レートが（例えば、送信におけるエラーに起因して）キャプチャレートよりも低い場合、スタッタリング監視モジュールは、１秒当たりに受信された（例えば、復号された）フレーム数、復号後のフレームエラー数、及びプロトコルスタックからの任意の統計（例えば、パケットエラー、順序誤りパケット、サーバ側及びクライアント側のいずれかにおけるパケットドロップなど）のうちのいずれかを取得（例えば、監視）し得る。
【0075】
例えば、本明細書で説明する任意の例による任意のメトリックは、クライアントデバイス７２及びサーバ７１のいずれかに配置され得るレイテンシマネージャモジュール７１５、７２５によって処理され得る。レイテンシマネージャモジュール７１５、７２５は、本明細書で説明する任意の監視されるメトリックに適用される（例えば、任意の分散関数）に基づいて、例えば、ビデオスタッタリングのレベル及びフレームペース変動のいずれかを表すメトリックを取得するように構成され得る。
【0076】
第１の例では、レイテンシマネージャモジュール７２５は、クライアントデバイス中に含まれてもよく、クライアントデバイスは、例えば、ビデオスタッタリングのレベル及びフレームペース変動のいずれかを表すメトリックを取得し得る。第２の例では、レイテンシマネージャモジュール７５５は、サーバに含まれてもよく、クライアントデバイスは、本明細書に記載のように任意の監視されたメトリックをサーバに伝送し得る。第１の例及び第２の例のいずれにおいても、新しいＳＲＴレイテンシ値は、本明細書に記載の任意の実施形態によるメトリックに基づいて決定（例えば、要求）されてもよい。
【0077】
レイテンシマネージャモジュール７１５、７２５によって取得された、ビデオスタッタリングのレベルを表すメトリックは、本明細書ではＹ＝スタッタリング値（ｔｉ，ウィンドウ）と呼ばれてもよく、式中、ｔｉは、ｉ番目のフレームの受信（それぞれ、復号）の時間を表してもよく、ウィンドウは、メトリックが処理され（組み合わせられ、計算され）得る時間間隔（例えば、［ｔｉ－ウィンドウ，ｔｉ］）を表してもよい。メトリックＹは、例えば、（例えば、各）新しい着信フレームＦｉに対して取得され得る。
【0078】
実施形態によれば、レイテンシマネージャモジュール７１５、７２５は、過去の値の履歴に基づいて、メトリックＹの（例えば、予測された）値（本明細書ではＹ予測と呼ばれ得る）を取得し得る。例えば、新しいＳＲＴレイテンシ値（本明細書ではＳＲＴバッファレイテンシ目標と呼ばれ得る）は、例えば、Ｙのいずれかの履歴（例えば、Ｙ予測）と、例えば、異なる先行する時間期間に対するフレームペース変動と、に基づいて取得されてもよい。新しいＳＲＴバッファレイテンシ値は、ＳＲＴクライアントにおいて設定されてもよく、（例えば、予測された）スタッタリング値を低減するのに十分な大きさの（例えば、最低）レイテンシ値に相当してもよい。例えば、新しいＳＲＴレイテンシ値は、ある値を超えてレイテンシを増加させないための限度に制限されたままで、（例えば、初期ＳＲＴレイテンシ値と比較して）増加されてもよい。例えば、新しいＳＲＴレイテンシ値は、ヒステリシスに基づいて取得され得る。例えば、レイテンシは、スタッタリングのレベルが第１のレベル（例えば、最大閾値）を上回る場合、（例えば、第１の値だけ）増分されてもよく、スタッタリングのレベルが第２のレベル（例えば、閾値）を下回る場合、（例えば、第２の値だけ）減少されてもよい。より一般的には、新しい（例えば、要求された）レイテンシ値は、（例えば、クライアントデバイス及びサーバのいずれかに配置され得るレイテンシマネージャモジュール７１５、７２５によって）フレームペース変動に基づいて決定され得る。例えば、（例えば、観測された、測定された、予測された）フレームペース変動が増加する場合、新しい（例えば、要求された）レイテンシ値は、（初期レイテンシ値と比較して）増加すると決定され得、（例えば、観測された、測定された、予測された）フレームペース変動が減少する場合、新しい（例えば、要求された）レイテンシ値は、（初期レイテンシ値と比較して）減少すると決定され得る。
【0079】
ＳＲＴレイテンシは、本明細書で説明される実施形態において開示されるように、ＳＲＴメッセージを交換することによって、送信機及びクライアントデバイスにおいて調整（例えば、更新）されてもよい。例えば、ＳＲＴバッファリングレイテンシ更新は、（例えば、レイテンシマネージャモジュールの位置に応じて）クライアントデバイス又はサーバのいずれかが主導するものであり得る（例えば、それによってトリガされ得る）。
【0080】
例えば、限定するものではないが、新しいＳＲＴレイテンシ値は、以下の式によって記述されるように、到達時間Ｔｉ間に適用されるフレーム間遅延変動（ジッタローカル）関数に基づいて取得されてもよい。
【0081】
【数3】
【0082】
ＳＲＴセッションレイテンシ設定の例
例えば、（例えば、ＳＲＴバッファレイテンシ値の設定を通した）レイテンシは、拡張ハンドシェイクフェーズ中に構成されてもよく、ゲームセッションに対して同じ値のままであってもよい。
例えば、（例えば、ＳＲＴバッファレイテンシ値の設定を通した）レイテンシは、拡張ハンドシェイクフェーズ中に構成されてもよく、ゲームセッションに対して同じ値のままであってもよい。
【0083】
実施形態によれば、ＳＲＴプロトコルは、ライブ送信モード及びクラウドゲーミング送信モードのいずれかを含んでもよい。クラウドゲーミング送信モードは、例えば、ＳＲＴセッションの生成後（例えば、任意の時点で）、ＳＲＴレイテンシ値をダイナミックに更新（例えば、調整）する機能に関連付けられてもよい。
【0084】
図８Ａは、拡張ハンドシェイクパケットフォーマットの２つの例を示す図である。第１の例では、ＨＳｖ４拡張ハンドシェイクパケット８１は、ダイナミックＳＲＴレイテンシ更新をサポートする能力を示す能力情報８１０を含み得る。第２の例では、ＨＳｖ５拡張ハンドシェイクパケット８２は、ダイナミックＳＲＴレイテンシ更新をサポートする能力を示す能力情報８２０を含み得る。
【0085】
例えば、ダイナミックＳＲＴレイテンシ更新をサポートする能力は、本明細書ではＳＲＴ＿ＯＰＴ＿ＤＹＮＴＳＢＰＤ（例えば、ダイナミックタイムスタンプバッファパケット配信）と呼ばれ得る、ＳＲＴフラグ８１０、８２０のフィールドの第７のビットによって示され得る。１に設定されたＳＲＴ＿ＯＰＴ＿ＤＹＮＴＳＢＰＤフラグを有するＳＲＴメッセージは、ダイナミックＳＲＴレイテンシ更新をサポートするＳＲＴメッセージの送信機の能力を示してもよい。ＳＲＴフラグ８１０、８２０のフィールドの任意の他のビットを介してダイナミックＳＲＴレイテンシ更新をサポートする能力を示すことは、本明細書で説明される実施形態に適用可能である。
【0086】
図８Ｂは、ハンドシェイク拡張メッセージフラグの例を示す図である。例えば、ＳＲＴ＿ＯＰＴ＿ＤＹＮＴＳＢＰＤのビットマスクは、０ｘ０００００１００であり得る。
【0087】
本明細書で説明される実施形態は、シングルビットフラグを介してダイナミックＳＲＴレイテンシ更新をサポートする能力を示すことに限定されない。例えば、ダイナミックＳＲＴレイテンシ更新をサポートする能力を示すＳＲＴ拡張ハンドシェイクパケットのフィールドの任意の値が、本明細書に記載の実施形態に適用可能であってもよい。
【0088】
実施形態によれば、任意のエンティティ（例えば、ＳＲＴリスナ及びＳＲＴコーラのいずれか）が、ダイナミックＳＲＴレイテンシ更新がゲームセッションに対してアクティブ化され得るかどうかを示してもよい。他のエンティティは、ダイナミックＳＲＴレイテンシ更新をアクティブ化することを受諾してもよく、拒否してもよい。
【0089】
図９Ａは、レイテンシダイナミック変更をサポートする能力を示すための拡張ハンドシェイクメッセージ交換の一例を示す図である。例えば、メッセージ交換は、サーバによって開始されてもよい。
【0090】
第１の例９０Ａでは、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新をサポートするサーバ能力を示す情報を含むＳＲＴ拡張ハンドシェイク要求メッセージ９０１Ａを受信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新をサポートするクライアント能力を示す情報を含むＳＲＴ拡張ハンドシェイク応答メッセージ９０２Ａを伝送することによって、ゲームセッション中にダイナミックＳＲＴレイテンシ更新を実行することを受諾してもよい。
【0091】
第２の例９１Ａでは、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新サポートがないことを示す情報を含む第１のＳＲＴ拡張ハンドシェイク要求メッセージ９１１Ａをサーバから受信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新を実行するようにサーバに要求するために、ダイナミックＳＲＴレイテンシ更新をサポートするクライアント能力を示す情報を含む第１のＳＲＴ拡張ハンドシェイク応答メッセージ９１２Ａを伝送してもよい。例えば、クライアントデバイスは、サーバからのダイナミックＳＲＴレイテンシ更新サポートがないことを確認する情報を含む第２のＳＲＴ拡張ハンドシェイク要求メッセージ９１３Ａを受信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新がゲームセッションにおいて実行されない場合があることを確認する情報を含む第２のＳＲＴ拡張ハンドシェイク応答メッセージ９１４Ａを伝送してもよい。
【0092】
第３の例９２Ａでは、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新サポートがないことを示す情報を含む第１のＳＲＴ拡張ハンドシェイク要求メッセージ９２１Ａをサーバから受信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新を実行するようにサーバに要求するために、ダイナミックＳＲＴレイテンシ更新をサポートするクライアント能力を示す情報を含む第１のＳＲＴ拡張ハンドシェイク応答メッセージ９２２Ａを伝送してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新をサポートするサーバ能力を示し、ゲームセッション中にダイナミックＳＲＴレイテンシ更新を実行するサーバからの同意を示す情報を含む第２のＳＲＴ拡張ハンドシェイク要求メッセージ９２３Ａを受信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新がゲームセッションにおいて実行されてもよいことを確認する情報を含む第２のＳＲＴ拡張ハンドシェイク応答メッセージ９２４Ａを伝送してもよい。
【0093】
図９Ｂは、レイテンシダイナミック変更をサポートする能力を示すための拡張ハンドシェイクメッセージ交換の別の例を示す図である。例えば、メッセージ交換は、クライアントデバイスによって開始されてもよい。
【0094】
第１の例９０Ｂでは、クライアントデバイスは、ゲームセッション中にＳＲＴレイテンシをダイナミックに更新できるようにサーバに要求するために、ダイナミックなＳＲＴレイテンシ更新をサポートするクライアントデバイスの能力を示す情報を含むＳＲＴ拡張ハンドシェイク要求メッセージ９０１Ｂを送信してもよい。クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新をサポートするサーバ能力を示す情報を含むＳＲＴ拡張ハンドシェイク応答メッセージ９０２Ｂを受信してもよく、この情報は、ゲームセッション中にダイナミックＳＲＴレイテンシ更新を実行するサーバの同意を示してもよい。
【0095】
第２の例９１Ｂにおいて、クライアントデバイスは、クライアントデバイスからのダイナミックＳＲＴレイテンシ更新サポートがないことを示す情報を含む第１のＳＲＴ拡張ハンドシェイク要求メッセージ９１１Ｂを送信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新を実行するようクライアントデバイスに要求するために、ダイナミックＳＲＴレイテンシ更新をサポートするサーバ能力を示す情報を含む第１のＳＲＴ拡張ハンドシェイク応答メッセージ９１２Ｂを受信してもよい。例えば、クライアントデバイスは、サーバ要求を拒絶するために、クライアントデバイスからのダイナミックＳＲＴレイテンシ更新サポートがないことを確認する情報を含む第２のＳＲＴ拡張ハンドシェイク要求メッセージ９１３Ｂを送信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新がゲームセッションにおいて実行されない場合があることを確認する情報を含む第２のＳＲＴ拡張ハンドシェイク応答メッセージ９１４Ｂを受信してもよい。
【0096】
第３の例９２Ｂでは、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新サポートがないことを示す情報を含む第１のＳＲＴ拡張ハンドシェイク要求メッセージ９２１Ｂを送信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新を実行するようにクライアントデバイスに要求するために、ダイナミックＳＲＴレイテンシ更新をサポートするサーバ能力を示す情報を含む第１のＳＲＴ拡張ハンドシェイク応答メッセージ９２２Ｂを受信してもよい。例えば、クライアントデバイスは、ゲームセッション中にダイナミックＳＲＴレイテンシ更新を実行する同意を示すために、ダイナミックＳＲＴレイテンシ更新をサポートするクライアント能力を示す情報を含む第２のＳＲＴ拡張ハンドシェイク要求メッセージ９２３Ｂを送信してもよい。例えば、クライアントデバイスは、ダイナミックＳＲＴレイテンシ更新がゲームセッションにおいて実行されてもよいことを確認する情報を含む第２のＳＲＴ拡張ハンドシェイク応答メッセージ９２４Ｂを受信してもよい。
【0097】
ＳＲＴセッションレイテンシの変化の例
例えば、ダイナミックレイテンシの更新が、（例えば、ＳＲＴ拡張ハンドシェイク機能の交換に基づく）（例えば、所与の）ＳＲＴセッションにおいて操作可能であり得る後、受信機は、例えば、ビデオスタッタリングの検出に基づいて、レイテンシ変更手順（例えば、ダイナミックＳＲＴレイテンシの更新）を起動してもよい。本明細書で説明される実施形態全体を通して、「ダイナミックＳＲＴレイテンシの更新」及び「レイテンシ変更手順」という表現を互換的に使用して、サーバ及びクライアントデバイス内のＳＲＴレイテンシ値を更新するためのＳＲＴメッセージの交換を指すことができる。
例えば、ダイナミックレイテンシの更新が、（例えば、ＳＲＴ拡張ハンドシェイク機能の交換に基づく）（例えば、所与の）ＳＲＴセッションにおいて操作可能であり得る後、受信機は、例えば、ビデオスタッタリングの検出に基づいて、レイテンシ変更手順（例えば、ダイナミックＳＲＴレイテンシの更新）を起動してもよい。本明細書で説明される実施形態全体を通して、「ダイナミックＳＲＴレイテンシの更新」及び「レイテンシ変更手順」という表現を互換的に使用して、サーバ及びクライアントデバイス内のＳＲＴレイテンシ値を更新するためのＳＲＴメッセージの交換を指すことができる。
【0098】
例えば、新しいＳＲＴレイテンシ値は、本明細書で説明される任意の実施形態に従って取得され得る。本明細書で更に説明されるように、レイテンシ変更手順は、クライアントデバイス及びサーバのいずれかによって開始され得る。
【0099】
実施形態によれば、イニシエータ（例えば、サーバ及びクライアントデバイスのいずれか）は、新しいＳＲＴレイテンシ値を示す、本明細書ではダイナミックタイムスタンプバッファパケット配信（dynamic timestamp buffer packet delivery、ＤＹＮＴＳＢＰＤ）要求メッセージと呼ばれ得るＳＲＴ要求メッセージを送信し得る。
【0100】
図１０は、新しいＳＲＴレイテンシ値を要求するためのＳＲＴメッセージのフォーマットの一例を示す図である。例えば、ＳＲＴダイナミックタイムスタンプバッファパケット配信（ＤＹＮＴＳＢＰＤ）要求メッセージ１０１０は、ＳＲＴレイテンシ変更手順のイニシエータ（例えば、サーバ及びクライアントデバイスのいずれか）によって要求されている新しいＳＲＴレイテンシ値を示す第１の情報を含んでもよい。例えば、ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０は、イニシエータ（例えば、サーバ及びクライアントデバイスのいずれか）によって要求されている新しいＳＲＴレイテンシ値に応答して、応答されたＳＲＴレイテンシ値を示す第２の情報を含んでもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０は、イニシエータによって送信されたＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０に応答して、他のパーティ（例えば、サーバ及びクライアントデバイスのいずれか）によって送信されてもよい。
【0101】
【0102】
図１０及び図１１Ａを参照すると、ステップ１１１０Ａにおいて、クライアントデバイスは、ゲームのビデオフレームを搬送するパケットを受信することができ、ＳＲＴプロトコルに従ってそれらに肯定応答することができる。クライアントデバイスは、本明細書で説明される任意の実施形態に従って、メトリック及び新しいＳＲＴレイテンシ値のいずれかを取得してもよい。
【0103】
例えば、ステップ１１２０Ａにおいて、ＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０、１１２１Ａがクライアントデバイスによってゲームサーバに送信されてもよい。新しい（例えば、要求された）ＳＲＴレイテンシ値は、ＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０、１１２１Ａに含まれ得る第１の情報（例えば、ＴｓｂＰｄ Ｒｃｖフィールド）１０１１において示されてもよい。例えば、ＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０、１１２１Ａは、初期ＳＲＴレイテンシを示し得る送信機レイテンシ値を示すＴｓｂＰｄ Ｓｎｄフィールド１０１２を含み得る。初期ＳＲＴレイテンシは、例えば、ＳＲＴレイテンシの更新前に（例えば、現在のＳＲＴレイテンシ値）を示してもよい。初期ＳＲＴレイテンシは、（例えば、初期）ＳＲＴハンドシェイク中に合意されたような値であってもよい。
【0104】
例えば、ステップ１１３０Ａにおいて、サーバは、ＳＲＴレイテンシ値を新しい（例えば、要求された）値に更新することを受諾してもよい。受諾を示すために、サーバは、新しいＳＲＴレイテンシ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ａをクライアントデバイスに伝送してもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ａは、新しい（例えば、要求された）ＳＲＴレイテンシ値に設定され得る第２の情報（例えば、ＴｓｂＰｄ Ｓｎｄフィールド）１０２２を含んでもよい。例えば、ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ａは、新しいＳＲＴ（例えば、要求された）レイテンシ値に設定され得るＴｓｂＰｄ Ｓｎｄフィールド１０２１を含んでもよい。ステップ１１３２Ａにおいて、クライアントデバイスは、新しいＳＲＴレイテンシ値の受諾を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ａの受信後、ＳＲＴ受信機レイテンシ値を新しいＳＲＴレイテンシ値に更新してもよい。
【0105】
例えば、ステップ１１４０Ａにおいて、サーバは、変更を拒否（例えば、拒絶）してもよい。拒絶を示すために、サーバは、現在の（例えば、初期）ＳＲＴ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１４１Ａをクライアントデバイスに伝送してもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１４１Ａは、現在の（例えば、初期）ＳＲＴレイテンシ値に設定され得る第２の情報（例えば、ＴｓｂＰｄ Ｓｎｄフィールド）１０２２を含んでもよい。ステップ１１４２Ａにおいて、クライアントデバイスは、新しいＳＲＴレイテンシ値の拒絶を示す第２の情報を含むＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１４１Ａの受信後、ＳＲＴ受信機レイテンシ値を現在の（例えば、初期）ＳＲＴレイテンシ値に維持してもよい。
【0106】
例えば、ステップ１１５０Ａにおいて、サーバは、ＳＲＴレイテンシ値を（例えば、新しい値とは異なる）代替値で更新することを受諾してもよい。例えば、代替値は、現在の（例えば、初期）ＳＲＴレイテンシ値と新しい（例えば、要求された）ＳＲＴレイテンシ値との間に厳密に含まれる任意のＳＲＴレイテンシ値であってもよい。
【0107】
部分的な受諾（例えば、及び代替提案）を示すために、サーバは、代替ＳＲＴ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１５１Ａをクライアントデバイスに伝送してもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１５１Ａは、代替ＳＲＴレイテンシ値に設定され得る第２の情報（例えば、ＴｓｂＰｄ Ｓｎｄフィールド）１０２２を含んでもよい。ステップ１１５２Ａにおいて、クライアントデバイスは、代替ＳＲＴレイテンシ値を示す第２の情報を含むＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１５１Ａの受信後、ＳＲＴ受信機レイテンシ値を代替ＳＲＴレイテンシ値に更新してもよい。
【0108】
図１０及び図１１Ｂを参照すると、ステップ１１１０Ｂにおいて、クライアントデバイスは、ゲームのビデオフレームを搬送するパケットを受信することができ、ＳＲＴプロトコルに従ってそれらに肯定応答することができる。クライアントデバイスは、本明細書で説明される任意の実施形態に従って、メトリック及び新しいＳＲＴレイテンシ値のいずれかを取得し得る。
【0109】
例えば、ステップ１１１１Ｂにおいて、クライアントデバイスは、例えば、ビデオフレームペース変動を表す情報を含むメッセージを送信することができる。例えば、情報は、本明細書で説明する任意の実施形態によるクライアントデバイスにおける任意の到着時間の監視に基づいて取得された任意のメトリックの任意の値を記述する（例えば、示す）ことができる。
【0110】
例えば、ステップ１１２０Ｂにおいて、ＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０、１１２１Ｂがサーバによってクライアントに送信されてもよい。新しい（例えば、要求された）ＳＲＴレイテンシ値は、ＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０、１１２１Ｂに含まれ得る第１の情報（例えば、ＴｓｂＰｄ Ｓｎｄフィールド）１０１２において示されてもよい。例えば、ＳＲＴ ＤＹＮＴＳＢＰＤ要求メッセージ１０１０、１１２１Ｂは、現在の（例えば初期）ＳＲＴレイテンシを示し得る受信機レイテンシ値を示すＴｓｂＰｄ Ｒｃｖフィールド１０１１を含んでもよい。
【0111】
例えば、ステップ１１３０Ｂにおいて、クライアントデバイスは、ＳＲＴレイテンシ値を新しい値に更新することを受諾してもよい。例えば、クライアントデバイスは、新しい値に従ってＳＲＴ受信機バッファレイテンシを更新してもよい。受諾を示すために、クライアントデバイスは、新しいＳＲＴレイテンシ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ｂをサーバに伝送してもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ｂは、新しい（例えば、要求された）ＳＲＴレイテンシ値に設定され得る第２の情報（例えば、ＴｓｂＰｄ Ｒｃｖフィールド）１０２１を含んでもよい。例えば、ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ｂは、新しいＳＲＴ（例えば、要求された）レイテンシ値に設定され得るＴｓｂＰｄ Ｓｎｄフィールド１０２２を含んでもよい。ステップ１１３２Ｂにおいて、サーバは、新しいＳＲＴレイテンシ値の受け入れを示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ｂの受信後、ＳＲＴ送信機レイテンシ値（ＳｎｄＴｓｂＰｄＤｅｌａｙ）を新しいＳＲＴレイテンシ値に更新してもよい。
【0112】
例えば、ステップ１１４０Ｂにおいて、クライアントデバイスは、変更を拒否する（例えば、拒絶する）ことができ、ＳＲＴ受信機レイテンシ値を現在の（例えば、初期）ＳＲＴレイテンシ値に維持することができる。拒絶を示すために、クライアントは、現在の（例えば、初期）ＳＲＴ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１４１Ｂをサーバに伝送してもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１４１Ｂは、現在の（例えば、初期）ＳＲＴレイテンシ値に設定され得る第２の情報（例えば、ＴｓｂＰｄ Ｒｃｖフィールド）１０２１を含んでもよい。ステップ１１４２Ｂにおいて、サーバは、新しいＳＲＴレイテンシ値の拒絶を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１３１Ｂの受信後、ＳＲＴ送信機レイテンシ値を現在の（例えば、初期）ＳＲＴレイテンシ値に維持してもよい。
【0113】
例えば、ステップ１１５０Ａにおいて、クライアントデバイスは、ＳＲＴレイテンシ値を（例えば、新しい値とは異なる）代替値で更新することを受諾してもよい。例えば、（例えば、サーバによって要求された）新しい値は、クライアントデバイスのバッファリング能力と互換性がない場合がある（バッファが小さすぎる場合がある）。別の例では、クライアントデバイスは、サーバによって要求された新しいＳＲＴレイテンシ値が、（例えば、新しいレイテンシが現在のＲＴＴ値の３倍より小さい場合、）再送技法が紛失パケットを（例えば、効率的に）回復することを可能にするには小さすぎる場合があると判定する場合がある。例えば、代替値は、現在の（例えば、初期）ＳＲＴレイテンシ値と新しい（例えば、要求された）ＳＲＴレイテンシ値との間に厳密に含まれる任意のＳＲＴレイテンシ値であってもよい。部分的な受諾（例えば、及び代替提案）を示すために、クライアントデバイスは、代替ＳＲＴ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１５１Ｂをサーバに伝送してもよい。ＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１５１Ｂは、代替ＳＲＴレイテンシ値に設定され得る第２の情報（例えば、ＴｓｂＰｄ Ｓｎｄフィールド）１０２１を含んでもよい。ステップ１１５２Ｂにおいて、サーバは、代替ＳＲＴレイテンシ値を示すＳＲＴ ＤＹＮＴＳＢＰＤ応答メッセージ１０２０、１１５１Ｂの受信後、ＳＲＴ送信機レイテンシ値を代替ＳＲＴレイテンシ値に更新してもよい。
【0114】
本明細書で説明される実施形態は、本明細書で説明される（複数の）ＳＲＴメッセージフォーマット（例えば、フィールド）に限定されず、任意の他のＳＲＴメッセージフォーマット、より一般的には、サーバとクライアントデバイスとの間のバッファサイズを更新するための任意の他のプロトコルに従う任意のメッセージが、本明細書で説明される実施形態に適用可能であり得る。
【0115】
プロトコルレイテンシの更新に対する提示モジュール処理の例
クライアントデバイス（例えば、クライアントデバイスの提示処理モジュール）の処理の例は、例えば、図７を参照して本明細書で説明される。
クライアントデバイス（例えば、クライアントデバイスの提示処理モジュール）の処理の例は、例えば、図７を参照して本明細書で説明される。
【0116】
第１の例では、クライアントデバイス（例えば、クライアントデバイスの提示処理モジュール７２９）の処理は、任意のＳＲＴレイテンシ（例えば、ダイナミック）更新の場合に非依存性（例えば、不変）であり得る。例えば、提示処理モジュール７２９は、復号フレームキュー７２８における復号フレームを取得（例えば、聴取）し得る。ＶＳｙｎｃ信号の（例えば、各）周期において、１つの利用可能なフレームがキュー７２８からポップされ（例えば、抽出され）、スクリーン上に表示され得る。ＶＳｙｎｃ信号期間にキューにおいて利用可能なフレームがない場合、前に提示された（例えば、表示された）フレームが再び提示され得る（例えば、表示され得る）。復号フレームキュー７２８がオーバーフローした場合、任意の数のフレームが任意の基準に従ってドロップされ得る。基準は、例えば、フレームの提示時間から独立していてもよい。
【0117】
第２の例では、クライアントデバイス（の提示処理モジュール７２９）は、（例えば、各）フレームに関連付けられた提示時間を処理することができる。例えば、ＳＲＴレイテンシ値が新しい値で更新される場合、提示処理モジュール７２９は、（例えば、クライアントデバイス内部の任意のメカニズムに従って）この変更を通知（例えば、指示）されてもよい。例えば、ＳＲＴレイテンシの更新は、追加の符号付き遅延（例えば、レイテンシ増加の場合は正であり、そうでない場合は負）の形態で表され得る（例えば、示され得る）。例えば、前のプロトコルレイテンシと現在のプロトコルレイテンシとの間の差に対応する追加の符号付き遅延は、（例えば、復号のために）アプリケーションに配信される前に、フレームがプロトコルスタックにおいてバッファされていた可能性がある追加の符号付き時間を表し得る。
【0118】
例えば、提示処理モジュール７２９は、第１のフレーム（Ｆ０）がＶＳｙｎｃ期間においてスクリーン上に提示され得る（例えば、表示され得る）時間に対応し得るクロック基準時間（Ｔ０）を取得し得る（例えば、保持し得る）。簡略化のために、かつ一般性を失うことなく、フレームはキャプチャレートで順次配信され得る。例えば、フレームは、フレームのシーケンスインデックス（例えば、ｉ番目のフレームＦｉは、Ｔｉ＝Ｔ０＋ｉ ｘ ｃａｐｔｕｒｅ＿ｐｅｒｉｏｄにおいて提示され得る）から得られ得る計算された提示時間Ｔｉに基づいて提示（例えば、表示）され得る。ＳＲＴレイテンシが更新される場合、追加の符号付き遅延は、クロック基準時間を正又は負、例えば、Ｔ０＝Ｔ０＋遅延にシフトするように使用されてもよい。
【0119】
例えば、ＳＲＴレイテンシが増加する場合、提示のために復号フレームキュー７２８からフレームをポップする動作を復元する前に、最後に表示されたフレームが、レイテンシ増加に対応する回数だけ再び表示され得る（例えば、表示のために復号フレームキュー７２８からフレームがポップされ得ない）。ＳＲＴレイテンシ増加時の（複製され得る）最後の表示フレームは、ＳＲＴレイテンシが更新され得る前に表示され得る最後のフレームに対応し得る。例えば、（例えば、フレームＦｉが表示された後の）提示時間Ｔｉにおいて（例えば、６０Ｈｚスクリーンの２つの期間に対応する）３３ミリ秒のＳＲＴレイテンシ増加が発生する場合、提示モジュールが、キューから任意のフレームをポップし得る前に、２つの次の（例えば、キャプチャ）期間の間、この同じフレームを表示し得る。例えば、１つのフレームが３つの期間にわたってフリーズされ得る一方で、全ての後続のフレームは、スタッタリングなしに規則的な間隔で表示され得る。レイテンシバッファ増加に対応する（例えば、単一の）時点においてフレームを複製することは、レイテンシ変更時間において任意のスタッタリング問題を集中させることを可能にし得、全体的なＱｏＥ改善に寄与する。
【0120】
例えば、追加の符号付き遅延に基づいてクロック基準時間を調整することはまた、どの（例えば、遅い）フレームがドロップされ得る（例えば、表示されない）かを決定することを可能にし得る。例えば、フレームＦｉが復号されて時間通りに提示されるには遅すぎる場合、かつ次のフレームＦｉ＋１が復号フレームキュー７２８において利用可能である場合、提示処理モジュールは、クロック基準時間に基づいて、どのフレームがＶＳｙｎｃ信号の次の周期において（例えば、時間Ｔｓｙｎｃ＿ｐｅｒｉｏｄにおいて）提示（例えば、表示）され得るかを決定し得る。例えば、クロック基準時間を使用して、Ｔ０に基づいて、それぞれｉ番目及び（ｉ＋１）番目のフレームの提示時間Ｔｉ及びＴｉ＋１を決定し得る。例えば、ＶＳｙｎｃ信号の次の周期で表示されるフレームは、提示時間がＴｓｙｎｃ＿ｐｅｒｉｏｄに最も近い可能性がある（例えば、｜Ｔｓｙｎｃ＿ｐｅｒｉｏｄ－Ｔｉ｜、｜Ｔｓｙｎｃ＿ｐｅｒｉｏｄ－Ｔｉ＋１｜の間の最小値）（Ｆｉ及びＦｉ＋１の中の）フレームであってもよく、（Ｆｉ及びＦｉ＋１の中の）他のフレームはドロップされてもよい。
【0121】
プロトコルレイテンシの更新に関するサーバ処理の例
実施形態によれば、ＳＲＴバッファレイテンシは、サーバ側で使用されて、送信されたパケットを（例えば、ＳＲＴバッファレイテンシに対応する時間量の間）保持し、受信機によるそれらの肯定応答を（例えば、可能な再送のために）待機することができる。実施形態によれば、サーバは、ＳＲＴ送信機バッファを、ＳＲＴセッション中に起こり得るバッファレイテンシ値の変化に適合させることができる。
実施形態によれば、ＳＲＴバッファレイテンシは、サーバ側で使用されて、送信されたパケットを（例えば、ＳＲＴバッファレイテンシに対応する時間量の間）保持し、受信機によるそれらの肯定応答を（例えば、可能な再送のために）待機することができる。実施形態によれば、サーバは、ＳＲＴ送信機バッファを、ＳＲＴセッション中に起こり得るバッファレイテンシ値の変化に適合させることができる。
【0122】
第１の例では、ＳＲＴバッファレイテンシ（例えば、ＲｃｖＴｓｂＰｄＤｅｌａｙ）は、クライアントデバイス（例えば、受信機）によって低減され得る。サーバ（例えば、送信機）は、（例えば、更新されたより短いクライアント期限（例えば、より小さいＳＲＴバッファレイテンシ）のために期限切れとなり得る）いくつかの再送パケットを送信することを決定し得る。高いジッタの差異（例えば、及び、例えば、頻繁なバッファレイテンシ変化に起因するＳＲＴバッファレイテンシの将来の増加）を予想するために、サーバは、バッファが近い将来に増加する場合にパケットを再送することができるように、期限切れになったばかりであり得るパケットを余分な持続時間にわたって保持することができる。
【0123】
第２の例では、より多くのパケットをバッファリングするためにＳＲＴバッファレイテンシが受信機によって増加される場合、送信機が追加の時間を使用して、より多くの再送パケットを送信することができる。
【0124】
図１２Ａは、例えば、ゲームなどのビデオコンテンツのＱｏＥを改善するためのクライアント（例えば、処理）デバイス１２Ａの一例を示す図である。例えば、処理デバイス１２Ａは、コンテンツ（例えば、ゲーム）サーバと対話することができるクラウドゲーミング（例えば、シン）クライアントを含むことができる。例えば、処理デバイス１２Ａは、任意の数の入力装置（例えば、ジョイスティック、マウス、キーボード、リモコンなどのいずれか）からコマンド（例えば、ユーザ入力）を受信するように構成された入力インターフェース１２６０を備えてもよい。コマンドは、コンテンツ（例えば、ゲーム）サーバに宛てられてもよい。例えば、処理デバイス１２Ａは、ネットワークに接続するためのネットワークインターフェース１２００を備えてもよい。ネットワークインターフェース１２００は、サーバから複数のパケットを受信するように構成され得る。パケットは、クライアント（例えば、処理）デバイス１２Ａによって復号及び表示されるビデオコンテンツ（例えば、ゲーム）のビデオフレームを含む（例えば、搬送する）ことができる（例えば、パケットは、ビデオフレームの一部を含むことができ、ビデオフレームは、パケットのセットを介して搬送することができる）。例えば、ネットワークインターフェース１２００は、パケットをサーバに送信するように構成され得る。パケットは、例えば、（例えば、ユーザ）入力コマンドを含み得る。例えば、ネットワークインターフェース１２００は、任意の種類の制御メッセージ（例えば、ＳＲＴメッセージ）をサーバと交換するように構成されてもよい。実施形態によれば、ネットワークインターフェース１２００は、以下のいずれかであってもよい。
－Ｂｌｕｅｔｏｏｔｈ、任意の種類のＷｉ－Ｆｉ、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の種類の無線インターフェースなどの無線ローカルエリアネットワークインターフェース、
－Ｅｔｈｅｒｎｅｔ、ＩＥＥＥ８０２．３、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の有線インターフェースなどの有線ＬＡＮインターフェース、
－ＵＳＢ、ＦｉｒｅＷｉｒｅ、又は任意の種類の有線バス技術などの有線バスインターフェース、
－リリースのいずれかにおける３ＧＰＰ仕様に準拠する２Ｇ／３Ｇ／４Ｇ／５Ｇセルラーワイヤレスネットワークインターフェースなどのブロードバンドセルラーワイヤレスネットワークインターフェース、
－ｘＤＳＬ、ＦＦＴｘ、又はＷｉＭＡＸインターフェースなどの広域ネットワークインターフェース。
－Ｂｌｕｅｔｏｏｔｈ、任意の種類のＷｉ－Ｆｉ、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の種類の無線インターフェースなどの無線ローカルエリアネットワークインターフェース、
－Ｅｔｈｅｒｎｅｔ、ＩＥＥＥ８０２．３、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の有線インターフェースなどの有線ＬＡＮインターフェース、
－ＵＳＢ、ＦｉｒｅＷｉｒｅ、又は任意の種類の有線バス技術などの有線バスインターフェース、
－リリースのいずれかにおける３ＧＰＰ仕様に準拠する２Ｇ／３Ｇ／４Ｇ／５Ｇセルラーワイヤレスネットワークインターフェースなどのブロードバンドセルラーワイヤレスネットワークインターフェース、
－ｘＤＳＬ、ＦＦＴｘ、又はＷｉＭＡＸインターフェースなどの広域ネットワークインターフェース。
【0125】
より一般的には、（例えば、ユーザ入力コマンド及び制御）パケットのいずれかを送信すること、及びビデオフレームを搬送する複数のパケットを受信することを可能にする任意のネットワークインターフェースを本明細書で説明される実施形態に適用可能であり得る。
【0126】
実施形態によれば、ネットワークインターフェース１２００は、復号及び表示の前に、受信されたパケットに初期レイテンシ値を適用するように構成され得る処理モジュール１２２０に結合され得る。例えば、処理モジュール１２２０は、ビデオスタッタリングレベル及びビデオフレームが到着し得るペースの変動のいずれかを表すメトリックの値を取得するように構成され得る。例えば、処理モジュール１２２０は、メトリックの値に基づいて新しいレイテンシ値を取得するための、ネットワークインターフェース１２００を介してサーバとメッセージを交換するように構成され得る。メッセージ交換の第１の例では、処理モジュール１２２０は、フレームペース変動に基づいて決定された要求されたレイテンシ値を示す第１の情報を含む要求メッセージをサーバに送信するように構成されてもよく、処理モジュール１２２０は、新しいレイテンシ値を示す第２の情報を含む応答メッセージをサーバから受信するように構成されてもよい。メッセージ交換の第２の例では、処理モジュール１２２０は、フレームペース変動を表すメトリックを示す情報をサーバに送信するように構成されてもよく、処理モジュール１２２０は、要求されたレイテンシ値を示す第１の情報を含む要求メッセージをサーバから受信するように構成されてもよく、処理モジュール１２２０は、要求されたレイテンシ値に基づく新しいレイテンシ値を示す第２の情報を含む応答メッセージをサーバに送信するように構成されてもよい。例えば、処理モジュール１２２０は、後続パケットを復号及び表示する前に、受信された後続パケットに新しいＳＲＴレイテンシ値を適用するように構成されてもよい。例えば、処理モジュール１２２０は、ビデオフレームを復号し、例えば、表示手段などのビデオ出力部１２４０上での表示のためにビデオフレームを送信するように構成されてもよい。実施形態によれば、内部又は外部の表示手段は、パーソナルコンピュータ画面、ＴＶ画面、タブレット画面、スマートフォン画面のいずれかであってもよい。より一般的には、例えば、ゲームなどのビデオコンテンツのビデオを表示することを可能にする任意の表示手段が、本明細書で説明される実施形態に適用可能であり得る。
【0127】
図１２Ｃは、例えばゲームなどのビデオコンテンツのＱｏＥを改善するためのサーバ（例えば処理）デバイス１２Ｃの一例を示す図である。例えば、処理デバイス１２Ｃは、クライアントデバイスと相互作用してもよい。例えば、処理デバイス１２Ｃは、ネットワークに接続するためのネットワークインターフェース１２１０を備えてもよい。ネットワークインターフェース１２１０は、複数のパケットをクライアントデバイスに送信するように構成され得る。パケットは、クライアントデバイスによって復号及び表示されるべきビデオコンテンツ（例えば、ゲーム）のビデオフレームを含む（例えば、搬送する）ことができる。例えば、パケットは、ビデオフレームの一部を含んでもよく、ビデオフレームは、パケットのセットを介して搬送されてもよい。例えば、ネットワークインターフェース１２１０は、クライアントデバイスからパケットを受信するように構成され得る。パケットは、例えば、（例えば、ユーザ）入力コマンドを含み得る。例えば、ネットワークインターフェース１２１０は、任意の種類の制御メッセージ（例えば、ＳＲＴメッセージ）をクライアントデバイスと交換するように構成され得る。実施形態によれば、ネットワークインターフェース１２１０は、以下のいずれかであってもよい。
－Ｂｌｕｅｔｏｏｔｈ、任意の種類のＷｉ－Ｆｉ、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の種類の無線インターフェースなどの無線ローカルエリアネットワークインターフェース、
－Ｅｔｈｅｒｎｅｔ、ＩＥＥＥ８０２．３、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の有線インターフェースなどの有線ＬＡＮインターフェース、
－ＵＳＢ、ＦｉｒｅＷｉｒｅ、又は任意の種類の有線バス技術などの有線バスインターフェース、
－リリースのいずれかにおける３ＧＰＰ仕様に準拠する２Ｇ／３Ｇ／４Ｇ／５Ｇセルラーワイヤレスネットワークインターフェースなどのブロードバンドセルラーワイヤレスネットワークインターフェース、
－ｘＤＳＬ、ＦＦＴｘ、又はＷｉＭＡＸインターフェースなどの広域ネットワークインターフェース。
－Ｂｌｕｅｔｏｏｔｈ、任意の種類のＷｉ－Ｆｉ、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の種類の無線インターフェースなどの無線ローカルエリアネットワークインターフェース、
－Ｅｔｈｅｒｎｅｔ、ＩＥＥＥ８０２．３、又はネットワークインターフェースのＩＥＥＥ８０２シリーズの任意の有線インターフェースなどの有線ＬＡＮインターフェース、
－ＵＳＢ、ＦｉｒｅＷｉｒｅ、又は任意の種類の有線バス技術などの有線バスインターフェース、
－リリースのいずれかにおける３ＧＰＰ仕様に準拠する２Ｇ／３Ｇ／４Ｇ／５Ｇセルラーワイヤレスネットワークインターフェースなどのブロードバンドセルラーワイヤレスネットワークインターフェース、
－ｘＤＳＬ、ＦＦＴｘ、又はＷｉＭＡＸインターフェースなどの広域ネットワークインターフェース。
【0128】
より一般的には、（例えば、ユーザ入力コマンド及び制御）パケットのいずれかを受信すること、及びビデオフレームを搬送する複数のパケットを送信することを可能にする任意のネットワークインターフェースを本明細書で説明される実施形態に適用可能であり得る。
【0129】
実施形態によれば、ネットワークインターフェース１２１０は、ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信するように構成され得る処理モジュール１２３０に結合され得る。例えば、処理モジュール１２３０は、初期レイテンシ値に関連付けられた第１の時間量の間、再送のためにパケットをバッファ中に保持するように構成されてもよい。例えば、処理モジュール１２３０は、新しいレイテンシ値を取得するために、ネットワークインターフェース１２１０を介してサーバとメッセージを交換するように構成され得る。メッセージ交換の第１の例では、処理モジュール１２３０は、クライアントデバイスから、要求されたレイテンシ値を示す第１の情報を含む要求メッセージを受信するように構成されてもよく、処理モジュール１２３０は、クライアントデバイスに、（例えば、要求されたレイテンシ値に設定され得る）新しいレイテンシ値を示す第２の情報を含む応答メッセージを送信するように構成されてもよい。メッセージ交換の第２の例では、処理モジュール１２３０は、フレームペースの変動を表すメトリックを示す情報を受信するように構成されてもよく、処理モジュール１２３０は、要求メッセージをクライアントデバイスに送信するように構成されてもよく、要求メッセージは、示されたメトリックに基づいて決定された要求されたレイテンシ値を示す第１の情報を含み、処理モジュール１２３０は、応答メッセージをクライアントデバイスから受信するように構成されてもよく、応答メッセージは、新しいレイテンシ値を示す第２の情報を含む。
【0130】
例えば、処理モジュール１２３０は、ゲームインスタンスを実行するように構成されてもよい。例えば、処理モジュール１２３０は、ゲームの（例えば、後続の）ビデオフレームをレンダリングするように構成され得るＧＰＵ（図示せず）を備えてもよい。例えば、処理モジュール１２３０は、レンダリングされた（例えば、後続の）ビデオフレームを符号化し、符号化された（例えば、後続の）ビデオフレームを、クライアントデバイスに送信されるべき複数の（例えば、後続の）パケットにおいてカプセル化するように構成されてもよい。例えば、処理モジュール１２３０は、ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットをクライアントデバイスに送信するように構成されてもよい。例えば、処理モジュール１２３０は、新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために後続パケットをバッファにおいて保持するように構成されてもよい。
【0131】
図１２Ｂは、本明細書に記載されたクライアント及びサーバ（例えば、処理）デバイス１２Ａ、１２Ｃのうちのいずれかのアーキテクチャの例を表す。処理デバイス１２Ａ、１２Ｃは、内部メモリ１２５０（例えば、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭのいずれか）とともに、例えば、ＣＰＵ、ＧＰＵ、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒの英語頭字語）のいずれかであり得る、１つ以上のプロセッサ１２１０を備え得る。処理デバイス１２Ａ、１２Ｃは、出力情報を送信し、かつ／又はユーザがコマンド及び／又はデータを入力することを可能にし（例えば、キーボード、マウス、タッチパッド、ウェブカム、ディスプレイのいずれか）、かつ／又はネットワークインターフェースを介してデータを送信／受信するように適合された任意の数の（複数の）入力／出力インターフェース１２３０と、処理デバイス１２Ａ、１２Ｃの外部にあってもよい電源１２７０と、を備えてもよい。
【0132】
実施形態によれば、処理デバイス１２Ａ、１２Ｃは、メモリ１２５０に記憶されたコンピュータプログラムを更に含むことができる。コンピュータプログラムは、処理デバイス１２Ａ、１２Ｃによって、特に（複数の）プロセッサ１２１０によって実行されたときに、図１３、図１４、図１５、図１６及び図１７のいずれかを参照して説明した処理方法を処理デバイス１２Ａ、１２Ｃに実行させる命令を含むことができる。一変形形態によれば、コンピュータプログラムは、処理デバイス１２Ａ、１２Ｃの外部で、非一時的デジタルデータサポート上に、例えば、全て当該技術分野で知られているＳＤカード、ＨＤＤ、ＣＤ－ＲＯＭ、ＤＶＤ、読取り専用及び／又はＤＶＤドライブ、ＤＶＤ読取り／書込みドライブのいずれかなどの外部記憶媒体上に記憶され得る。処理デバイス１２Ａ、１２Ｃは、コンピュータプログラムを読み取るためのインターフェースを備えることができる。更に、処理デバイス１２Ａ、１２Ｃは、対応するＵＳＢポート（図示せず）を介して、任意の数のユニバーサルシリアルバス（Universal Serial Bus、ＵＳＢ）タイプのストレージデバイス（例えば、「メモリスティック」）にアクセスすることができる。
【0133】
実施形態によれば、処理デバイス１２Ａは、ゲームデバイス、セットトップボックスデバイス、ＴＶセット、デジタルメディアプレーヤ（例えば、レンダラ）デバイス、インターネットゲートウェイ、モバイルデバイス、通信デバイス、タブレット（又はタブレットコンピュータ）、スマートフォン、ラップトップコンピュータ、デスクトップコンピュータのいずれかであってもよい。実施形態によれば、処理デバイス１２Ｃは、デスクトップコンピュータ、サーバ、及びサーバのインスタンスのいずれかであってもよい。
【0134】
図１３は、ゲームのＱｏＥを改善するための方法の一例を示す図である。例えば、方法は、（例えば、クラウドゲーミング）クライアントデバイスにおいて実装されてもよい。実施形態によれば、ステップ１３１０において、ゲームのビデオフレームを搬送する複数のパケットが、サーバから（例えば、クラウドゲーミング）クライアントデバイスによって受信され得る。実施形態によれば、ステップ１３２０において、初期ＳＲＴレイテンシ値が、復号及び表示の前に受信パケットに適用されてもよい。実施形態によれば、ステップ１３３０において、ビデオスタッタリングレベルを表すメトリックの値が、ビデオフレームペース変動に基づいて取得され得る。実施形態によれば、ステップ１３４０において、ＳＲＴメッセージは、メトリックの値に基づいて新しいＳＲＴレイテンシ値を取得するために、（例えば、クラウドゲーミング）クライアントデバイスとサーバとの間で交換されてもよい。実施形態によれば、ステップ１３５０において、ゲームのＱｏＥは、復号及び表示の前に受信された後続パケットに新しいＳＲＴレイテンシ値を適用することによって改善され得る。
【0135】
例えば、受信されたパケット及び受信された後続パケットは、ＳＲＴ受信機バッファに格納されてもよく、ＳＲＴレイテンシ値は、ＳＲＴレイテンシ値及びパケットに含まれるタイムスタンプ情報に基づいてＳＲＴ受信機バッファからパケットを抽出することによってパケットに適用されてもよい。例えば、タイムスタンプ情報は、サーバのＳＲＴ送信機バッファにおけるパケットの格納に関連付けられたそれぞれの時間を示してもよい。例えば、ＳＲＴレイテンシ値は、初期ＳＲＴレイテンシ値及び新しいＳＲＴレイテンシ値のいずれかであってもよい。
【0136】
例えば、パケットに含まれるタイムスタンプは、パケットがＳＲＴ送信機バッファに格納されていた可能性がある最初の時刻を示してもよい。例えば、パケットは、第１の時間の後の時間量に対応する第２の時間において抽出されてもよく、時間量は、連続するパケットに対して一定であってもよく、ＳＲＴレイテンシ値に関連付けられてもよい。
【0137】
例えば、ビデオフレームペース変動は、ビデオフレームが受信され、ＳＲＴ受信機バッファから抽出され、復号されるペースの変動であってもよい。
【0138】
例えば、新しいＳＲＴレイテンシ値は、異なる先行する期間について取得されたメトリックの値の履歴に基づいて取得されてもよい。
【0139】
例えば、メトリック値は、フレーム到着時間、パケット到着時間、フレーム復号時間、及びフレーム表示時間のうちのいずれかの分散関数に基づいて取得され得る。
【0140】
例えば、分散関数は、平均値、中央値、標準偏差、分散、平均絶対偏差、及び四分位数のいずれかであってもよい。
【0141】
例えば、メトリックの値は、遅延フレームの第１の数及びドロップフレームの第２の数のいずれかに更に基づき得る。
【0142】
例えば、ＳＲＴ要求メッセージは、（例えば、クラウドゲーミング）クライアントデバイスによってサーバに送信されてもよい。ＳＲＴ要求メッセージは、要求されたＳＲＴレイテンシ値を示す第１の情報を含んでもよい。要求されたＳＲＴレイテンシ値は、（例えば、クラウドゲーミング）クライアントデバイスによって決定され得る新しいＳＲＴレイテンシ値に対応してもよい。
【0143】
例えば、ＳＲＴ応答メッセージは、サーバから（例えば、クラウドゲーミング）クライアントデバイスによって受信されてもよい。ＳＲＴ応答メッセージは、要求されたレイテンシ値に応答して送信機ＳＲＴレイテンシ値を示す第２の情報を含んでもよい。例えば、受信された後続パケットに適用される新しいＳＲＴレイテンシ値は、送信機ＳＲＴレイテンシ値が要求されたＳＲＴレイテンシ値に等しいか、又は要求されたＳＲＴレイテンシ値と初期ＳＲＴレイテンシ値との間に厳密に含まれるという条件で、送信機ＳＲＴレイテンシ値に設定されてもよい。
【0144】
例えば、メトリックの値は、（例えば、クラウドゲーミング）クライアントデバイスによってサーバに送信されてもよい。
【0145】
例えば、ＳＲＴ要求メッセージは、サーバから（例えば、クラウドゲーミング）クライアントデバイスによって受信されてもよい。ＳＲＴ要求メッセージは、新しいＳＲＴレイテンシ値を示す第１の情報を含んでもよい。
【0146】
例えば、ＳＲＴ応答メッセージは、（例えば、クラウドゲーミング）クライアントデバイスによってサーバに送信されてもよい。ＳＲＴ応答メッセージは、新しいＳＲＴレイテンシ値を肯定応答するための、新しいＳＲＴレイテンシ値を示す第２の情報を含んでもよい。
【0147】
例えば、ビデオフレームを搬送するパケットが受信され得る前に、ＳＲＴ拡張ハンドシェイク要求メッセージが（例えば、クラウドゲーミング）クライアントデバイスによってサーバに送信され得る。ＳＲＴ拡張ハンドシェイク要求メッセージは、ダイナミックレイテンシ動作をサポートするクライアント能力を示すことができる。
【0148】
例えば、ＳＲＴ拡張ハンドシェイク応答メッセージは、ＳＲＴ拡張ハンドシェイク要求メッセージに応答してサーバから（例えば、クラウドゲーミング）クライアントデバイスによって受信されてもよい。（例えば、クラウドゲーミング）クライアントデバイスは、ＳＲＴ拡張ハンドシェイク応答メッセージがダイナミックレイテンシ動作をサポートするサーバ能力を示すという条件で、ダイナミックレイテンシ動作を実行してもよい。
【0149】
例えば、ビデオフレームを搬送するパケットが受信され得る前に、ＳＲＴ拡張ハンドシェイク要求メッセージが、サーバから（例えば、クラウドゲーミング）クライアントデバイスによって受信され得る。ＳＲＴ拡張ハンドシェイク要求メッセージがダイナミックレイテンシ動作をサポートするサーバ能力を示す場合、ダイナミックレイテンシ動作をサポートするクライアント能力を示すＳＲＴ拡張ハンドシェイク応答メッセージが（例えば、クラウドゲーミング）クライアントデバイスによってサーバに送信されてもよい。
【0150】
例えば、ビデオフレームを搬送するパケットが受信され得る前に、ＳＲＴ拡張ハンドシェイク要求メッセージがサーバから（例えば、クラウドゲーミング）クライアントデバイスによって受信されてもよく、ＳＲＴ拡張ハンドシェイク要求メッセージがダイナミックレイテンシ動作をサポートするサーバ能力の指示を含まないという条件で、ＳＲＴ拡張ハンドシェイク応答メッセージが、ダイナミックレイテンシ動作をサポートするクライアント能力を示すサーバに（例えば、クラウドゲーミング）クライアントデバイスによって送信されてもよい。
【0151】
例えば、別のＳＲＴ拡張ハンドシェイク要求メッセージが（例えば、クラウドゲーミング）クライアントデバイスによって受信されてもよく、ダイナミックレイテンシ動作は、他のＳＲＴ拡張ハンドシェイク要求メッセージがダイナミックレイテンシ動作をサポートするサーバ能力を示すという条件で実行されてもよい。
【0152】
図１４は、例えば、ビデオコンテンツのＱｏＥを改善するための、クライアントデバイスにおいて実施される方法の第１の例を示す図である。例えば、ステップ１４１０において、クライアントデバイスは、サーバからビデオコンテンツのビデオフレームを搬送する複数のパケットを受信し得る。例えば、ステップ１４２０において、クライアントデバイスは、復号及び表示の前に、受信されたパケットに初期レイテンシ値を適用し得る。例えば、ステップ１４３０において、クライアントデバイスは、フレームペース変動に基づいて決定され得る要求されたレイテンシ値を示す第１の情報を含むことができる要求メッセージをサーバに送信することができる。例えば、ステップ１４４０において、クライアントデバイスは、サーバから新しいレイテンシ値を示す第２の情報を含むことができる応答メッセージを受信することができる。例えば、ステップ１４５０において、クライアントデバイスは、復号及び表示の前に、受信された後続パケットに新しいレイテンシ値を適用し得る。
【0153】
例えば、初期レイテンシ値及び新しいレイテンシ値は、（ｉ）それぞれ初期レイテンシ値及び新しいレイテンシ値と、（ｉｉ）パケット及び後続パケットに含まれるタイムスタンプ情報と、に基づいて、パケット及び後続パケットのそれぞれを受信機バッファから抽出することによって、パケット及び後続パケットのそれぞれに適用され得る。タイムスタンプ情報は、例えば、サーバの送信機バッファにおけるパケット及び後続パケットの格納に関連付けられたそれぞれの時間を示すことができる。
【0154】
例えば、パケット及び後続パケットのうちのいずれかのパケットに含まれるタイムスタンプ情報は、パケットが、例えば、送信機バッファに格納されていた可能性がある第１の時間を示すことができる。例えば、パケットは、第１の時間の後の時間量に対応する第２の時間において抽出され得、時間量は、連続するパケットに対して一定であり、初期レイテンシ値及び新しいレイテンシ値のいずれかに関連付けられる。
【0155】
例えば、フレームペース変動は、ビデオフレームが受信される、受信機バッファから抽出される、復号されるのうちのいずれかであり得るペースの変動であってもよい。
【0156】
例えば、新しいレイテンシ値は、異なる先行する期間についてのフレームペース変動の履歴に基づいて取得され得る。
【0157】
例えば、新しいレイテンシ値は、遅延フレームの数及びドロップされたフレームの数のいずれかに更に基づき得る。
【0158】
例えば、新しいレイテンシ値は、新しいレイテンシ値が要求されたレイテンシ値に等しいか、又は要求されたレイテンシ値と初期レイテンシ値との間に厳密に含まれるという条件で、後続パケットに適用され得る。
【0159】
例えば、ビデオフレームを搬送するパケットが受信され得る前に、クライアントデバイスは、ハンドシェイク要求メッセージをサーバに送信し得る。例えば、ハンドシェイク要求メッセージは、ダイナミックレイテンシ動作をサポートするクライアント能力を示す第３の情報を含み得る。
【0160】
例えば、クライアントデバイスは、例えば、ハンドシェイク要求メッセージに応答して、サーバからハンドシェイク応答メッセージを受信し得る。例えば、クライアントデバイスは、ハンドシェイク応答メッセージが、ダイナミックレイテンシ動作をサポートするためのサーバ能力を示す第４の情報を含むという条件で、要求メッセージを送信することによって、ダイナミックレイテンシ動作を実行し得る。
【0161】
例えば、ビデオフレームを搬送するパケットが受信され得る前に、クライアントデバイスは、サーバからハンドシェイク要求メッセージを受信し得る。ハンドシェイク要求メッセージが、ダイナミックレイテンシ動作をサポートするサーバ能力を示す第３の情報を含むという条件で、クライアントデバイスは、ハンドシェイク応答メッセージをサーバに送信することができ、ハンドシェイク応答メッセージは、ダイナミックレイテンシ動作をサポートするクライアント能力を示す第４の情報を含むことができる。
【0162】
例えば、初期レイテンシ値及び新しいレイテンシ値は、ＳＲＴプロトコルに関連付けられたセキュアリライアブルトランスポート（ＳＲＴ）レイテンシ値であり得る。
【0163】
図１５は、例えば、ビデオコンテンツのＱｏＥを改善するための、サーバにおいて実施される方法の第２の例を示す図である。例えば、ステップ１５１０において、サーバは、ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信することができる。例えば、ステップ１５２０において、サーバは、初期レイテンシ値に関連付けられた第１の時間量の間、例えば、再送のためにバッファ内にパケットを保持することができる。例えば、ステップ１５３０において、サーバは、クライアントデバイスから要求メッセージを受信することができ、要求メッセージは、要求されたレイテンシ値を示す第１の情報を含むことができる。例えば、ステップ１５４０において、サーバは、応答メッセージをクライアントデバイスに送信することができ、応答メッセージは、新しいレイテンシ値を示す第２の情報を含むことができる。例えば、新しいレイテンシ値は、要求されたレイテンシ値のサーバによる受諾を示すために、要求されたレイテンシ値に設定され得る。例えば、ステップ１５５０において、サーバは、ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットをクライアントデバイスに送信することができる。例えば、ステップ１５６０において、サーバは、新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために後続パケットを、例えば、バッファに保持することができる。
【0164】
図１６は、例えば、ビデオコンテンツのＱｏＥを改善するための、クライアントデバイスにおいて実施される方法の第３の例を示す図である。例えば、ステップ１６１０において、クライアントデバイスは、サーバからビデオコンテンツのビデオフレームを搬送する複数のパケットを受信し得る。例えば、ステップ１６２０において、クライアントデバイスは、復号及び表示の前に、受信されたパケットに初期レイテンシ値を適用し得る。例えば、ステップ１６３０において、クライアントデバイスは、フレームペース変動を表すメトリックを示す情報をサーバに送信することができる。例えば、ステップ１６４０において、クライアントデバイスは、サーバから要求メッセージを受信することができ、要求メッセージは、要求されたレイテンシを示す第１の情報を含むことができる。例えば、ステップ１６５０において、クライアントデバイスは、応答メッセージをサーバに送信することができ、応答メッセージは、要求されたレイテンシ値に基づく新しいレイテンシ値を示す第２の情報を含むことができる。例えば、新しいレイテンシ値は、要求されたレイテンシ値のクライアントデバイスによる受諾を示すために、要求されたレイテンシ値に設定され得る。例えば、ステップ１６６０において、クライアントデバイスは、復号及び表示の前に、受信された後続パケットに新しいレイテンシ値を適用し得る。
【0165】
例えば、メトリックは、フレーム到着時間、パケット到着時間、フレーム復号時間、及びフレーム表示時間のうちのいずれかの分散関数に基づき得る。
【0166】
例えば、分散関数は、平均値、中央値、標準偏差、分散、平均絶対偏差、及び四分位数のいずれかを含むことができる。
【0167】
例えば、メトリックは、遅延フレームの数及びドロップされたフレームの数のいずれかに更に基づき得る。
【0168】
図１７は、例えば、ビデオコンテンツのＱｏＥを改善するための、サーバにおいて実施される方法の第４の例を示す図である。例えば、ステップ１７１０において、サーバは、ビデオコンテンツのビデオフレームを搬送する複数のパケットをクライアントデバイスに送信することができる。例えば、ステップ１７２０において、サーバは、初期レイテンシ値に関連付けられた第１の時間量の間、例えば、再送のためのバッファ内にパケットを保持することができる。例えば、ステップ１７３０において、サーバは、フレームペース変動を表すメトリックを示す情報を受信することができる。例えば、ステップ１７４０において、サーバは、要求されたレイテンシ値を示す第１の情報を含むことができる要求メッセージをクライアントデバイスに送信することができる。例えば、サーバは、示されたメトリックに基づいて要求されたレイテンシ値を決定し得る。例えば、ステップ１７５０において、サーバは、クライアントデバイスから、新しいレイテンシ値を示す第２の情報を含むことができる応答メッセージを受信することができる。例えば、新しいレイテンシ値は、要求されたレイテンシ値のクライアントデバイスによる受諾を示すために、要求されたレイテンシ値に設定され得る。例えば、ステップ１７６０において、サーバは、ビデオコンテンツの後続ビデオフレームを搬送する複数の後続パケットをクライアントデバイスに送信することができる。例えば、ステップ１７７０において、サーバは、新しいレイテンシ値に関連付けられた第２の時間量の間、再送のために後続パケットを、例えば、バッファに保持することができる。
【0169】
結論
特徴及び要素は、特定の組み合わせにおいて上で説明されているが、当業者は、各特徴又は要素が単独で又は他の特徴及び要素との任意の組み合わせで使用され得ることを理解されよう。加えて、本明細書に説明される方法は、コンピュータ又はプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア又はファームウェアに実装され得る。コンピュータ可読媒体の例には、電子信号（有線接続又は無線接続を介して伝送される）及びコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例としては、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスク及びリムーバブルディスクなどの磁気媒体、磁気光学媒体及びＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（digital versatile disk、ＤＶＤ）などの光学媒体が挙げられるが、これらに限定されない。ソフトウェアと関連付けられたプロセッサを使用して、ＷＴＲＵ１０２、ＵＥ、端末、基地局、ＲＮＣ又は任意のホストコンピュータにおける使用のための無線周波数トランシーバを実装し得る。
特徴及び要素は、特定の組み合わせにおいて上で説明されているが、当業者は、各特徴又は要素が単独で又は他の特徴及び要素との任意の組み合わせで使用され得ることを理解されよう。加えて、本明細書に説明される方法は、コンピュータ又はプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア又はファームウェアに実装され得る。コンピュータ可読媒体の例には、電子信号（有線接続又は無線接続を介して伝送される）及びコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例としては、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスク及びリムーバブルディスクなどの磁気媒体、磁気光学媒体及びＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（digital versatile disk、ＤＶＤ）などの光学媒体が挙げられるが、これらに限定されない。ソフトウェアと関連付けられたプロセッサを使用して、ＷＴＲＵ１０２、ＵＥ、端末、基地局、ＲＮＣ又は任意のホストコンピュータにおける使用のための無線周波数トランシーバを実装し得る。
【0170】
明示的に記載されていないが、本明細書に記載の実施形態は、任意の組み合わせ又は部分的な組み合わせで用いられ得る。例えば、本明細書に記載の原理は、記載された変形例に限定されず、変形例及び実施形態の任意のアレンジを使用することができる。更に、本明細書に記載の原理は、記載されたチャネルアクセス方法に限定されず、任意の他のタイプのチャネルアクセス方法が、本原理と互換性がある。
【0171】
方法について説明される任意の特徴、変形例、又は実施形態は、開示された方法を処理するための手段を含む装置デバイスと互換性があり、開示された方法を処理するように構成されたプロセッサを備えるデバイスと互換性があり、プログラムコード命令を含むコンピュータプログラム製品と互換性があり、かつプログラム命令を記憶する非一時的なコンピュータ可読記憶媒体と互換性がある。
【0172】
更に、上記の実施形態では、処理プラットフォーム、コンピューティングシステム、コントローラ、及びプロセッサを含む他のデバイスが記載されている。これらのデバイスは、少なくとも１つの中央処理装置（「ＣＰＵ」）及びメモリを含み得る。コンピュータプログラミングの技術分野における当業者の慣例によれば、動作、及び演算又は命令の記号表現の言及は、様々なＣＰＵ及びメモリによって実施され得る。そのような動作及び演算又は命令は、「実行される」、「コンピュータによって実行される」、又は「ＣＰＵによって実行される」と言及されることがある。
【0173】
当該技術分野における通常の技術を有する者には、動作及び記号的に表現された演算又は命令が、ＣＰＵによる電気信号の操作を含むことが理解されるであろう。電気システムは、電気信号の結果的な変換又は減少を引き起こすことができるデータビットを表し、メモリシステムのメモリ位置にデータビットを維持し、それによってＣＰＵの動作及び他の信号の処理を再構成又は別の方法で変更する。データビットが維持されるメモリ位置は、データビットに対応する、又はデータビットを表す特定の電気的特性、磁気的特性、光学的特性、又は有機的特性を有する物理的位置である。代表的な実施形態は、上述のプラットフォーム又はＣＰＵに限定されず、他のプラットフォーム及びＣＰＵが、提供された方法をサポートし得るということを理解されたい。
【0174】
データビットはまた、磁気ディスク、光学ディスク、及び任意の他の揮発性（例えば、ランダムアクセスメモリ（「ＲＡＭ」））又はＣＰＵによって読み取り可能な不揮発性（例えば、読み取り専用メモリ（「ＲＯＭ」））大容量記憶システムを含む、コンピュータ可読媒体上に維持され得る。コンピュータ可読媒体は、処理システム上に排他的に存在するか、又は処理システムに対してローカル又はリモートであり得る複数の相互接続された処理システム間で分散された、協調的又は相互接続されたコンピュータ可読媒体を含んでもよい。代表的な実施形態は、上述のメモリに限定されず、他のプラットフォーム及びメモリが、記載された方法をサポートし得るということが理解される。
【0175】
例示的な実施形態において、本明細書に記載されている動作、プロセスなどのいずれも、コンピュータ可読媒体に記憶されたコンピュータ可読命令として実装されてもよい。コンピュータ可読命令は、移動体、ネットワーク要素、及び／又は任意の他のコンピューティングデバイスのプロセッサによって実行され得る。
【0176】
システムの態様のハードウェア実装とソフトウェア実装との間には、ほとんど区別がない。ハードウェア又はソフトウェアの使用は、概して（例えば、常にではないが、ある特定のコンテキストにおいて、ハードウェアとソフトウェアとの間の選択が重要になり得るという点で）、コスト対効率のトレードオフを表す設計上の選択である。本明細書に記載されているプロセス及び／又はシステム及び／又は他の技術が効果的であり得る様々なビークル（例えばハードウェア、ソフトウェア、及び／又はファームウェア）が存在し得、好ましいビークルは、プロセス及び／又はシステム及び／又は他の技術が配備される状況によって変化し得る。例えば、実装者が、速度及び正確性が最重要であると判定した場合、実装者は、主にハードウェア及び／又はファームウェアのビークルを選択することができる。柔軟性が最重要である場合、実装者は、主にソフトウェア実装を選択することができる。代替的に、実装者は、ハードウェア、ソフトウェア、及び／又はファームウェアの何らかの組み合わせを選択してもよい。
【0177】
前述の詳細な説明では、ブロック図、フローチャート、及び／又は例の使用を通じて、デバイス及び／又はプロセスの様々な実施形態を示した。そのようなブロック図、フローチャート、及び／又は例が１つ以上の機能及び／又は動作を含む限り、そのようなブロック図、フローチャート、又は例の中の各機能及び／又は各動作は、広範なハードウェア、ソフトウェア、ファームウェア、又はそれらの実質的に任意の組み合わせによって、個別にかつ／又は集合的に実装されてよいことが当業者には理解されるであろう。好適なプロセッサとしては、例として、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、特定用途用標準製品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、及び／又は状態機械が挙げられる。
【0178】
上記では特徴及び要素が特定の組み合わせにおいて提供されているが、当該技術分野の通常の技術を有する者には、各特徴若しくは各要素を単独で使用する、又は他の特徴及び要素との任意の組み合わせにおいて使用できることが理解されるであろう。本開示は、本出願に記載されている特定の実施形態の観点において限定されるものではなく、これらの実施形態は、様々な態様の例示として意図されるものである。当業者には明らかなように、本発明の趣旨及び範囲から逸脱することなく、多くの修正及び変形を行うことができる。本出願の説明において使用されているいかなる要素、動作、又は指示も、そのように明示的に提示されていない限り、本発明にとって重要又は本質的であると解釈されるべきではない。本明細書に列挙したものに加えて、本開示の範囲内の機能的に等価な方法及び装置が、上述した説明から、当業者には明らかであろう。そのような修正及び変形は、添付の請求項の範囲に入ることが意図されている。本開示は、添付の請求項の条項によってのみ限定されるものであり、かかる請求項が権利を有する均等物の完全な範囲とともに、限定されるものである。本開示は、特定の方法又はシステムに限定されないことを理解されたい。
【0179】
また、本明細書で使用されている用語は、特定の実施形態を説明することのみを目的としており、本発明を制限することを意図していないことを理解されたい。本明細書で使用される場合、本明細書で言及される場合、「局」及びその略語「ＳＴＡ」、「ユーザ機器」及びその略語「ＵＥ」は、（ｉ）記載されたインフラストラクチャなどの無線伝送及び／又は受信ユニット（ＷＴＲＵ）、（ｉｉ）記載されたインフラストラクチャなどの、ＷＴＲＵのいくつかの実施形態の任意のもの、（ｉｉｉ）とりわけ、記載されたインフラストラクチャなどのＷＴＲＵの一部又は全ての構造及び機能を有して構成された、無線可能及び／又は有線可能な（例えば、テザー可能な）デバイス、（ｉｉｉ）記載されたインフラストラクチャなどのＷＴＲＵの、全てよりも少ない構造及び機能を有して構成された無線可能及び／又は有線可能なデバイス、又は（ｉｖ）その他、を意味し得る。本明細書に列挙される任意のＵＥを代表し得る例示的なＷＴＲＵの詳細が、図１Ａ～図１Ｄに関して以下に提供される。
【0180】
特定の代表的な実施形態では、本明細書に記載の主題のいくつかの部分は、特定用途用集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、及び／又は他の統合フォーマットを介して実装され得る。しかしながら、本明細書に開示されている実施形態のいくつかの態様は、その全体又は一部が、１つ以上のコンピュータ上で動作する１つ以上のコンピュータプログラムとして（例えば１つ以上のコンピュータシステム上で動作する１つ以上のプログラムとして）、１つ以上のプロセッサ上で動作する１つ以上のプログラムとして（例えば１つ以上のマイクロプロセッサ上で動作する１つ以上のプログラムとして）、ファームウェアとして、又はこれらの実質的に任意の組み合わせとして、集積回路において等価的に実装され得ること、並びに、回路を設計すること、及び／又は、ソフトウェア及び／若しくはファームウェアのコードを書くことが、この開示に照らして当業者の技術の範囲内であることが、当業者には認識されるであろう。加えて、本明細書に記載されている主題のメカニズムが、様々な形態のプログラム製品として配布され得ること、及び、本明細書に記載されている主題の例示的な実施形態が、配布を実際に行うために使用される特定のタイプの信号担持媒体にかかわらず適用されることが、当業者には理解されるであろう。信号担持媒体の例としては、フロッピーディスク、ハードディスクドライブ、ＣＤ、ＤＶＤ、デジタルテープ、コンピュータメモリなどの記録可能型媒体、並びに、デジタル及び／又はアナログ通信媒体（例えば光ファイバケーブル、導波管、有線通信リンク、無線通信リンクなど）などの送信型媒体が挙げられ、ただしこれらに限定されない。
【0181】
本明細書に記載されている主題は、場合によっては、異なる他の構成要素内に含まれるか、又は、異なる他の構成要素に接続されている、異なる構成要素を示していることがある。そのような図示されたアーキテクチャは単なる例であり、実際には、同じ機能を達成する他の多くのアーキテクチャが実装され得ることを理解されたい。概念的には、同じ機能を達成するための構成要素の任意の配置は、所望の機能が達成され得るように、効果的に「関連付けられる」。したがって、特定の機能を達成するために本明細書において組み合わされた、任意の２つの構成要素は、アーキテクチャ又は中間構成要素に関係なく、所望の機能が達成されるように、互いに「関連付けられた」として見ることができる。同様に、そのように関連付けられた任意の２つの構成要素は、所望の機能を達成するために互いに「動作可能に接続されている」、又は「動作可能に結合されている」とみなすこともでき、そのように関連付けることができる任意の２つの構成要素は、所望の機能を達成するために互いに「動作可能に結合可能」であるとみなすこともできる。動作可能に結合可能の具体例としては、物理的に嵌合可能かつ／若しくは物理的に相互作用する構成要素、及び／又は、無線で相互作用可能かつ／若しくは無線で相互作用する構成要素、及び／又は、論理的に相互作用するかつ／若しくは論理的に相互作用可能な構成要素が挙げられ、ただしこれらに限定されない。
【0182】
本明細書における実質的に任意の複数形及び／又は単数形の用語の使用に関して、当業者は、文脈及び／又は用途に適切であるように、複数形から単数形に、かつ／又は単数形から複数形に変換することができる。本明細書では、明瞭にする目的で、様々な単数形／複数形の並べ換えが明示的に記載され得る。
【0183】
一般に、本明細書、特に添付の請求項（例えば添付の請求項の本体）において使用されている用語は、一般に「非限定」用語として意図されることが当業者には理解されるであろう（例えば、「含んでいる」という用語は、「含んでいるがそれらに限定されない」と解釈するべきであり、「有する」という用語は、「を少なくとも有する」と解釈するべきであり、「含む」という用語は、「含むがそれらに限定されない」と解釈するべきである）。更に、導入された請求項の特定の数の記載が意図される場合、そのような意図は請求項に明示的に記載されており、そのような記載がない場合、そのような意図は存在しないことが、当業者には理解されるであろう。例えば、１つの項目のみが意図される場合、「単一」という用語又は類似する言葉が使用され得る。理解を助けるために、以下の添付の請求項及び／又は本明細書の説明は、請求項の記載を導入するために「少なくとも１つの」及び「１つ以上の」という導入句の使用を含み得る。しかしながら、このような句の使用は、不定冠詞「ａ」又は「ａｎ」による請求項の記載の導入が、そのような導入された請求項の記載を含む任意の特定の請求項を、１つのそのような記載のみを含む実施形態に制限することを意味するものと解釈すべきではなく、たとえ同じ請求項に、導入句「１つ以上の」又は「少なくとも１つの」及び「ａ」又は「ａｎ」などの不定冠詞が含まれていても同様である（例えば「ａ」及び／又は「ａｎ」は「少なくとも１つの」又は「１つ以上」を意味するものと解釈すべきである）。請求項の記載を導入するために使用される定冠詞の使用も同様である。加えて、導入された請求項の特定の数の記載が明示的に記載されている場合でも、かかる記載は少なくとも記載された数を意味するものと解釈されるべきであることが、当業者には認識されるであろう（例えば、他の修飾語なしの「２つの記載」という単純な記載は、少なくとも２つの記載、又は２つ以上の記載を意味する）。
【0184】
更に、「Ａ、Ｂ、及びＣのうちの少なくとも１つ」に類似する表記が使用される場合、一般に、そのような構造は、当業者がその表記を理解するであろう意味として意図される（例えば、「Ａ、Ｂ、及びＣのうちの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、Ａ及びＢを一緒に、Ａ及びＣを一緒に、Ｂ及びＣを一緒に、並びに／又は、Ａ、Ｂ、及びＣを一緒に、有するシステムを含み、ただしこれらに限定されない）。「Ａ、Ｂ、又はＣのうちの少なくとも１つ」に類似する表記が使用される場合、一般に、そのような構造は、当業者がその表記を理解するであろう意味として意図される（例えば、「Ａ、Ｂ、又はＣのうちの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、Ａ及びＢを一緒に、Ａ及びＣを一緒に、Ｂ及びＣを一緒に、並びに／又は、Ａ、Ｂ、及びＣを一緒に、有するシステムを含み、ただしこれらに限定されない）。明細書、特許請求の範囲、又は図面のいずれにおいても、２つ以上の代替的な用語を提示する実質的に任意の離接的な語及び／又は句は、用語の一方、用語のいずれか、又は両方の用語を含む可能性を企図するものと理解されるべきであることが、当業者には更に理解されるであろう。例えば、「Ａ又はＢ」という句は、「Ａ」若しくは「Ｂ」又は「Ａ及びＢ」の可能性を含むものと理解されたい。更に、本明細書で使用される、複数の項目のリスト及び／又は複数の項目のカテゴリのリストが後ろに続く「～のいずれか」という用語は、項目及び／又は項目のカテゴリの、「のいずれか」、「の任意の組み合わせ」、「の任意の複数」、及び／又は「の任意の複数の組み合わせ」を、個別に、又は他の項目及び／又は他の項目のカテゴリとの組み合わせにおいて、含むことを意図している。更に、本明細書で使用される場合、「セット／組」又は「グループ／群」という用語は、ゼロを含む任意の数の項目を含むことが意図される。追加的に、本明細書で使用される、「数」という用語は、ゼロを含む任意の数を含むことを意図している。
【0185】
加えて、本開示の特徴又は態様がＭａｒｋｕｓｈ群の観点から説明されている場合、当業者には、本開示がそれによってＭａｒｋｕｓｈ群の任意の個々のメンバー又はメンバーのサブグループの観点からも説明されることが認識されるであろう。
【0186】
当業者には理解されるように、書面による説明を提供するという観点など、あらゆる目的のために、本明細書に開示される全ての範囲は、その任意の可能な部分範囲及び部分範囲の組み合わせも包含している。任意の列挙された範囲は、同じ範囲が、少なくとも等しい２分の１、３分の１、４分の１、５分の１、１０分の１などに分解されることを十分に説明して可能にするものとして、容易に認識することができる。非限定的な例として、本明細書に記載されている各範囲は、下位３分の１、中央の３分の１、及び上位３分の１などに容易に分解され得る。また、当業者には理解されるように、「まで」、「少なくとも」、「より大きい」、「より小さい」等の全ての言葉は、言及された数を含み、かつ、上述したように更に部分範囲に分解され得る範囲を意味する。最後に、当業者には理解されるように、範囲は個々の各要素を含む。したがって、例えば、１～３個のセルを有するグループは、１個、２個、又は３個のセルを有するグループを指す。同様に、１～５個のセルを有するグループは、１個、２個、３個、４個、又は５個のセルを有するグループを指し、以下同様である。
【0187】
更に、請求項は、特にそのように記載されない限り、提供された順序又は提供された要素に限定されるものとして読まれるべきではない。加えて、いかなる請求項においても、「ための手段」という用語の使用は、米国特許法第１１２条、第６項、又はミーンズプラスファンクションの請求項形式に訴えることを意図しており、「ための手段」という用語を有さないいかなる請求項もそのようには意図されていない。
【0188】
ソフトウェアに関連するプロセッサを使用して、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、モビリティ管理エンティティ（ＭＭＥ）若しくは進化型パケットコア（Evolved Packet Core、ＥＰＣ）、又は任意のホストコンピュータで使用するための、無線周波数トランシーバを実装し得る。ＷＴＲＵは、例えば、ソフトウェア無線（Software Defined Radio、ＳＤＲ）などのハードウェア及び／又はソフトウェアに実装されたモジュールと併せて使用され得、また、カメラ、ビデオカメラモジュール、テレビ電話、スピーカ電話、振動デバイス、スピーカ、マイクロフォン、テレビジョントランシーバ、ハンズフリー式ヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、近距離無線通信（Near Field Communication、ＮＦＣ）モジュール、ＬＣＤディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、及び／又は無線ローカルエリアネットワーク（ＷＬＡＮ）又は超広帯域（Ultra Wide Band、ＵＷＢ）モジュールなどの他のコンポーネントに実装され得る。
【0189】
本発明は、通信システムに関して説明されてきたが、システムは、マイクロプロセッサ／汎用コンピュータ（図示せず）上のソフトウェアに実装され得ることが企図される。特定の実施形態では、様々な構成要素の機能のうちの１つ以上は、汎用コンピュータを制御するソフトウェアに実装され得る。
【0190】
加えて、本発明は、特定の実施形態を参照して本明細書に例示及び説明されるが、本発明は、示された詳細に限定されることを意図していない。むしろ、特許請求の範囲及びその等価物の範囲内において、しかも本発明から逸脱することなく、詳細に様々な修正を行うことができる。
【0191】
本開示を通して、当業者は、ある特定の代表的な実施形態が、代替的又は他の代表的な実施形態と組み合わせて使用され得ることを理解する。
【図1】
【図2】
【図3】
【図4-01】
【図4-02】
【図5】
【図6A】
【図6B】
【図7】
【図8A】
【図8B】
【図9A】
【図9B】
【図10】
【図11A-01】
【図11A-02】
【図11B-01】
【図11B-02】
【図12A】
【図12B】
【図12C】
【図13】
【図14】
【図15】
【図16】
【図17】
【国際調査報告】