JP7090721B2 - サイドリンク支援型ダウンリンクブロードキャストのためのプロトコル - Google Patents

Description

本願は、サイドリンク支援型ダウンリンクブロードキャストのためのプロトコルに関する。

関連出願の相互参照
本出願は、その内容が参照により本明細書に組み込まれる、２０１８年３月２日に出願された米国特許仮出願第６２／６３７，７１５号の利益を主張する。

ワイヤレス通信のための第３世代パートナーシッププロジェクト（３ＧＰＰ）規格では、グループのあらゆる個々のメンバは、受信されたかまたは紛失されたかにかかわらず送られたあらゆるパケットの報告を与える必要があり得る。これは、大量のオーバーヘッドをもたらし得る。

ワイヤレス送信／受信ユニット（ＷＴＲＵ）は、ＷＴＲＵのグループ中の１つまたは複数のＷＴＲＵに送信されたダウンリンク通信を第１のインターフェースを介してネットワークから受信し得る。ＷＴＲＵは、ダウンリンク通信のパケットロス割合に基づいてＷＴＲＵのアクセスクラスを決定し得る。アクセスクラスは、第２のインターフェースにアクセスするためのコンテンションウインドウに関連付けられ得る。ＷＴＲＵは、コンテンションウインドウ中で第２のインターフェースを介して１つまたは複数のＷＴＲＵにパケットロス情報を送信し得る。ＷＴＲＵは、第２のインターフェースを介して１つまたは複数のＷＴＲＵからパケットロスフィードバックを受信し得る。ＷＴＲＵは、ＷＴＲＵのアクセスクラスが１つまたは複数のＷＴＲＵのうちで最も高いクラスであると決定し得る。ＷＴＲＵは、パケットロスフィードバックに基づいて、第１のインターフェースを介して１つまたは複数のＷＴＲＵの代わりにネットワークに単一のグループキャスト否定応答（ｇＮＡＣＫ）を送信し得る。

より詳細な理解は、添付の図面と併せて例として与えられる以下の説明から得ることができ、ここにおいて、図中の同様の参照番号は同様の要素を示す。

１つまたは複数の開示する実施形態が実装され得る例示的な通信システムを示すシステム図である。 一実施形態による、図１Ａに示す通信システム内で使用され得る例示的なワイヤレス送信／受信ユニット（ＷＴＲＵ）を示すシステム図である。 一実施形態による、図１Ａに示す通信システム内で使用され得る例示的な無線アクセスネットワーク（ＲＡＮ）と例示的なコアネットワーク（ＣＮ）とを示すシステム図である。 一実施形態による、図１Ａに示す通信システム内で使用され得るさらなる例示的なＲＡＮとさらなる例示的なＣＮとを示すシステム図である。 無人航空機（ＵＡＶ）のグループ化を示す。 グループキャスト否定応答（ｇＮＡＣＫ）フィードバックのためのダウンリンクおよびアップリンクサブフレームタイミングを示す。 ｇＮＡＣＫ決定を示すフローチャートである。 同じパケットが多くのメンバによって要求される単純なブロードキャストを示す。 ２パケットネットワークコーディングのための紛失パターンを示す。 ３パケットネットワークコーディングのための紛失パターンを示す。 ４パケットネットワークコーディングのための紛失パターンを示す。 グループキャストパケット修復を示すフローチャートである。 例示的なＵＡＶを示す。

図１Ａは、１つまたは複数の開示する実施形態が実装され得る例示的な通信システム１００を示す図である。通信システム１００は、複数のワイヤレスユーザに音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを与える多元接続システムであり得る。通信システム１００は、ワイヤレス帯域幅を含むシステムリソースの共有を通してそのようなコンテンツに複数のワイヤレスユーザがアクセスすることを可能にし得る。たとえば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）、ゼロテールユニークワード離散フーリエ変換拡散ＯＦＤＭ（ＺＴ－ＵＷ－ＤＦＴ－Ｓ－ＯＦＤＭ：ｚｅｒｏ－ｔａｉｌ ｕｎｉｑｕｅ－ｗｏｒｄ ｄｉｓｃｒｅｔｅ Ｆｏｕｒｉｅｒ ｔｒａｎｓｆｏｒｍ Ｓｐｒｅａｄ ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ－ＯＦＤＭ：ｕｎｉｑｕｅ ｗｏｒｄ ＯＦＤＭ）、リソースブロックフィルタ処理済みＯＦＤＭ（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ－ｆｉｌｔｅｒｅｄ ＯＦＤＭ）、フィルタバンクマルチキャリア（ＦＢＭＣ：ｆｉｌｔｅｒ ｂａｎｋ ｍｕｌｔｉｃａｒｒｉｅｒ）などの１つまたは複数のチャネルアクセス方法を採用し得る。

図１Ａに示すように、通信システム１００は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、無線アクセスネットワーク（ＲＡＮ）１０４と、コアネットワーク（ＣＮ）１０６と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含み得るが、開示する実施形態が、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することを諒解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、ワイヤレス環境において動作および／または通信するように構成された任意のタイプのデバイスであり得る。例として、いずれかが局（ＳＴＡ）と呼ばれることがあるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成され得、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、サブスクリプションベースのユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、ホットスポットまたはＭｉ－Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、ウォッチまたは他のウェアラブルなもの、ヘッドマウントディスプレイ（ＨＭＤ）、ビークル、ドローン、医療デバイスおよびアプリケーション（たとえば、遠隔手術）、産業用デバイスおよびアプリケーション（たとえば、産業および／または自動処理チェーンコンテキストで動作するロボットおよび／または他のワイヤレスデバイス）、家庭用電子機器デバイス、商用および／または産業用ワイヤレスネットワーク上で動作するデバイスなどを含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのいずれかは、互換的にＵＥと呼ばれることがある。

通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含み得る。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６、インターネット１１０、および／または他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースするように構成された任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、送受信基地局（ＢＴＳ）、ノードＢ、ｅノードＢ（ｅＮＢ）、ホームノードＢ、ホームｅノードＢ、ｇノードＢ（ｇＮＢ）などの次世代ノードＢ、新無線（ＮＲ：ｎｅｗ ｒａｄｉｏ）ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであり得る。基地局１１４ａ、１１４ｂが単一の要素として示されているが、基地局１１４ａ、１１４ｂが任意の数の相互接続された基地局および／またはネットワーク要素を含み得ることを諒解されよう。

基地局１１４ａは、他の基地局および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなどのネットワーク要素（図示せず）をも含み得るＲＡＮ１０４の一部であり得る。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれることがある１つまたは複数のキャリア周波数上でワイヤレス信号を送信および／または受信するように構成され得る。これらの周波数は、認可スペクトル、無認可スペクトル、または認可スペクトルと無認可スペクトルとの組合せ中にあり得る。セルは、比較的固定され得るか、または時間とともに変化し得る特定の地理的エリアにワイヤレスサービスのためのカバレージを与え得る。セルは、セルセクタにさらに分割され得る。たとえば、基地局１１４ａに関連するセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバ、すなわち、セルのセクタごとに１つを含み得る。一実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用し得、セルのセクタごとに複数のトランシーバを利用し得る。たとえば、所望の空間的方向で信号を送信および／または受信するために、ビームフォーミングが使用され得る。

基地局１１４ａ、１１４ｂは、任意の好適なワイヤレス通信リンク（たとえば、無線周波数（ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であり得るエアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信し得る。エアインターフェース１１６は、任意の好適な無線アクセス技術（ＲＡＴ）を使用して確立され得る。

より具体的には、上記のように、通信システム１００は、多元接続システムであり得、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの１つまたは複数のチャネルアクセス方式を採用し得る。たとえば、ＲＡＮ１０４中の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェース１１６を確立し得るユニバーサル移動体（電話）通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装し得る。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）および／または高速アップリンク（ＵＬ）パケットアクセス（ＨＳＵＰＡ）を含み得る。

一実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ－Ａ）および／またはＬＴＥアドバンストプロ（ＬＴＥ－Ａ Ｐｒｏ）を使用してエアインターフェース１１６を確立し得る発展型ＵＭＴＳ地上波無線アクセス（Ｅ－ＵＴＲＡ）などの無線技術を実装し得る。

一実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＮＲを使用してエアインターフェース１１６を確立し得るＮＲ無線アクセスなどの無線技術を実装し得る。

一実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装し得る。たとえば、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、たとえば、デュアル接続性（ＤＣ）原理を使用してＬＴＥ無線アクセスとＮＲ無線アクセスとを一緒に実装し得る。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数のタイプの無線アクセス技術および／または複数のタイプの基地局（たとえば、ｅＮＢおよびｇＮＢ）との間で送られる送信によって特徴づけられ得る。

他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、ワイヤレスフィデリティー（ＷｉＦｉ））、ＩＥＥＥ８０２．１６（すなわち、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ＥＶ－ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ２０００（ＩＳ－２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ９５（ＩＳ－９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ８５６（ＩＳ－８５６）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）、ＧＳＭ進化型高速データレート（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装し得る。

図１Ａ中の基地局１１４ｂは、たとえば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントであり得、職場、家庭、ビークル、構内、産業設備、（たとえば、ドローンが使用するための）空中回廊、道路などの局所的エリアでのワイヤレス接続性を容易にすることのために任意の好適なＲＡＴを利用し得る。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立するためにＩＥＥＥ８０２．１１などの無線技術を実装し得る。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立するためにＩＥＥＥ８０２．１５などの無線技術を実装し得る。また別の実施形態中で、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するためにセルラーベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、ＮＲなど）を利用し得る。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスする必要がないことがある。

ＲＡＮ１０４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスを与えるように構成された任意のタイプのネットワークであり得るＣＮ１０６と通信していることがある。データは、異なるスループット要件、レイテンシ要件、誤り耐性要件、信頼性要件、データスループット要件、モビリティ要件などの変動するサービス品質（ＱｏＳ）要件を有し得る。ＣＮ１０６は、呼の制御、課金サービス、モバイルロケーションベースのサービス、プリペイド発呼、インターネット接続性、ビデオ配信などを与え、および／またはユーザ認証などの高レベルなセキュリティ関数を実行し得る。図１Ａには示されていないが、ＲＡＮ１０４および／またはＣＮ１０６が、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接的または間接的に通信していることがあることを諒解されよう。たとえば、ＮＲ無線技術を利用していることがあるＲＡＮ１０４に接続されることに加えて、ＣＮ１０６はまた、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ－ＵＴＲＡ、またはＷｉＦｉ無線技術を採用する別のＲＡＮ（図示せず）と通信していることがある。

ＣＮ１０６はまた、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとして働き得る。ＰＳＴＮ１０８は、簡易電話サービス（ＰＯＴＳ）を与える回線交換電話網を含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート中で伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）および／またはインターネットプロトコル（ＩＰ）などの共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有および／または動作されるワイヤードおよび／またはワイヤレス通信ネットワークを含み得る。たとえば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用し得る１つまたは複数のＲＡＮに接続された別のＣＮを含み得る。

通信システム１００中でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力を含み得る（たとえば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なるワイヤレスリンクを介して異なるワイヤレスネットワークと通信するための複数のトランシーバを含み得る）。たとえば、図１Ａに示すＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用し得る基地局１１４ａと通信し、ＩＥＥＥ８０２無線技術を採用し得る基地局１１４ｂと通信するように構成され得る。

図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、特に、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取外し不能メモリ１３０、取外し可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および／または他の周辺機器１３８を含み得る。ＷＴＲＵ１０２が、実施形態に一致したままでありながら、上記の要素の任意の部分組合せを含み得ることを諒解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、他のタイプの集積回路（ＩＣ）、状態機械などであり得る。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２がワイヤレス環境において動作することを可能にする任意の他の機能を実行し得る。プロセッサ１１８は、送信／受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｂに、別個の構成要素としてプロセッサ１１８とトランシーバ１２０とを示しているが、プロセッサ１１８とトランシーバ１２０とが電子パッケージまたはチップ中で一緒に統合され得ることを諒解されよう。

送信／受信要素１２２は、エアインターフェース１１６を介して基地局（たとえば、基地局１１４ａ）に信号を送信し、それから信号を受信するように構成され得る。たとえば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであり得る。一実施形態では、送信／受信要素１２２は、たとえば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／検出器であり得る。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送信および／または受信するように構成され得る。送信／受信要素１２２が、ワイヤレス信号の任意の組合せを送信および／または受信するように構成され得ることを諒解されよう。

送信／受信要素１２２が単一の要素として図１Ｂに示されているが、ＷＴＲＵ１０２は任意の数の送信／受信要素１２２を含み得る。より詳細には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用し得る。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６を介してワイヤレス信号を送信および受信するための２つ以上の送信／受信要素１２２（たとえば、複数のアンテナ）を含み得る。

トランシーバ１２０は、送信／受信要素１２２によって送信されるべきである信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成され得る。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有し得る。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が、たとえば、ＮＲおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含み得る。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され得、それらからユーザ入力データを受信し得る。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力し得る。さらに、プロセッサ１１８は、取外し不能メモリ１３０および／または取外し可能メモリ１３２などの任意のタイプの好適なメモリから情報にアクセスし、それの中にデータを記憶し得る。取外し不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ハードディスク、または他のタイプのメモリストレージデバイスを含み得る。取外し可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に位置しないメモリからの情報にアクセスし、その中にデータを記憶し得る。

プロセッサ１１８は、電源１３４から電力を受電し得、ＷＴＲＵ１０２中の他の構成要素に電力を分散および／または制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の好適なデバイスであり得る。たとえば、電源１３４は、１つまたは複数の乾電池バッテリ（たとえば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ－ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。

プロセッサ１１８はまた、ＷＴＲＵ１０２の現在のロケーションに関するロケーション情報（たとえば、経度および緯度）を与えるように構成され得るＧＰＳチップセット１３６に結合され得る。ＧＰＳチップセット１３６からの情報に加えて、または、それの代わりに、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介してロケーション情報を受信し、および／または２つ以上の近くの基地局から受信している信号のタイミングに基づいてそれのロケーションを決定し得る。ＷＴＲＵ１０２が、実施形態に一致したままでありながら、任意の好適なロケーション決定方法によってロケーション情報を捕捉し得ることを諒解されよう。

プロセッサ１１８は、追加の特徴、機能および／またはワイヤードもしくはワイヤレス接続性を与える１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含み得る他の周辺機器１３８にさらに結合され得る。たとえば、周辺機器１３８は、加速度計、ｅコンパス、衛星トランシーバ、（写真および／またはビデオのための）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、バーチャルリアリティおよび／または拡張現実（ＶＲ／ＡＲ）デバイス、アクティビティトラッカなどを含み得る。周辺機器１３８は、１つまたは複数のセンサを含み得る。センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、向きセンサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体センサ、湿度センサなどのうちの１つまたは複数であり得る。

ＷＴＲＵ１０２は、（（たとえば、送信のための）ＵＬと（たとえば、受信のための）ＤＬとの両方のための特定のサブフレームに関連する）信号の一部または全部の送信および受信が並列および／または同時であり得る全二重無線を含み得る。全二重無線は、ハードウェア（たとえば、チョーク）またはプロセッサ（たとえば、別個のプロセッサ（図示せず）またはビアプロセッサ１１８）を介した信号処理のいずれかを介して自己干渉を小さくするおよび／または実質的になくすために干渉管理ユニットを含み得る。一実施形態では、ＷＴＲＵ１０２は、（（たとえば、送信のための）ＵＬまたは（たとえば、受信のための）ＤＬのいずれかのための特定のサブフレームに関連する）信号の一部または全部の送信および受信のための半二重無線を含み得る。

図１Ｃは、一実施形態による、ＲＡＮ１０４およびＣＮ１０６を示すシステム図である。上記のように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ－ＵＴＲＡ無線技術を採用し得る。ＲＡＮ１０４はまた、ＣＮ１０６と通信していることがある。

ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４が、実施形態に一致したままでありながら、任意の数のｅノードＢを含み得ることを諒解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含み得る。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装し得る。したがって、ｅノードＢ１６０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信するおよび／またはそれからワイヤレス信号を受信するために複数のアンテナを使用し得る。

ｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）に関連付けられ得、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリングなどを扱うように構成され得る。図１Ｃに示すように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いと通信し得る。

図１Ｃに示すＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２と、サービングゲートウェイ（ＳＧＷ）１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）１６６とを含み得る。上記の要素がＣＮ１０６の一部として示されているが、これらの要素のいずれかがＣＮオペレータ以外のエンティティによって所有および／または動作され得ることを諒解されよう。

ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４中のｅノードＢ１６２ａ、１６２ｂ、１６２ｃの各々に接続され得、制御ノードとして働き得る。たとえば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担当し得る。ＭＭＥ１６２は、ＲＡＮ１０４とＧＳＭおよび／またはＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を与え得る。

ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４中のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は、概して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットをルーティングおよび転送し得る。ＳＧＷ１６４は、ｅノードＢ間のハンドオーバ中にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのために利用可能であるときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどの他の機能を実行し得る。

ＳＧＷ１６４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするためにインターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与え得るＰＧＷ１６６に接続され得る。

ＣＮ１０６は、他のネットワークとの通信を容易にし得る。たとえば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定通信デバイスとの間の通信を容易にするためにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与え得る。たとえば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含み得るかまたはそれと通信し得る。さらに、ＣＮ１０６は、他のサービスプロバイダによって所有および／または動作される他のワイヤードおよび／またはワイヤレスネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与え得る。

ＷＴＲＵがワイヤレス端末として図１Ａ～図１Ｄに記載されているが、そのような端末が（たとえば、一時的にまたは永続的に）使用し得るいくつかの代表的な実施形態では、ワイヤード通信が通信ネットワークとインターフェースすることが企図される。

代表的な実施形態では、他のネットワーク１１２は、ＷＬＡＮであり得る。

インフラストラクチャ基本サービスセット（ＢＳＳ）モードのＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）とＡＰに関連する１つまたは複数の局（ＳＴＡ）とを有し得る。ＡＰは、配信システム（ＤＳ）またはＢＳＳを出入りするトラフィックを搬送する別のタイプのワイヤード／ワイヤレスネットワークへのアクセスまたはインターフェースを有し得る。ＢＳＳの外部から発信するＳＴＡへのトラフィックは、ＡＰを通して到着し得、ＳＴＡに配信され得る。ＢＳＳ外の宛先にＳＴＡから発信されたトラフィックは、それぞれの宛先に配信されるためにＡＰに送られ得る。ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを通して送られることがあり、たとえば、ここで、ソースＳＴＡはＡＰにトラフィックを送り得、ＡＰは、宛先ＳＴＡにトラフィックを配信し得る。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なされ、および／またはそう呼ばれることがある。ピアツーピアトラフィックは、ダイレクトリンクセットアップ（ＤＬＳ）を用いてソースＳＴＡと宛先ＳＴＡとの間で（たとえば、それらの間で直接）送られ得る。いくつかの代表的な実施形態では、ＤＬＳは、８０２．１１ｅ ＤＬＳまたは８０２．１１ｚトンネリングされたＤＬＳ（ＴＤＬＳ：ｔｕｎｎｅｌｅｄ ＤＬＳ）を使用し得る。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮはＡＰを有しないことがあり、ＩＢＳＳ内のまたはそれを使用するＳＴＡ（たとえば、ＳＴＡのすべて）は互いに直接通信し得る。ＩＢＳＳ通信モードは、時々、本明細書では「アドホック」通信モードと呼ぶことがある。

８０２．１１ａｃインフラストラクチャ動作モードまたは同様の動作モードを使用するとき、ＡＰは、１次チャネルなどの固定チャネル上でビーコンを送信し得る。１次チャネルは、固定幅（たとえば、２０ＭＨｚ幅の帯域幅）であるか、または動的に設定された幅であり得る。１次チャネルは、ＢＳＳの動作チャネルであり得、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。いくつかの代表的な実施形態では、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が、たとえば８０２．１１システム中に実装され得る。ＣＳＭＡ／ＣＡでは、ＡＰを含むＳＴＡ（たとえば、あらゆるＳＴＡ）が１次チャネルを感知し得る。１次チャネルが特定のＳＴＡによって感知／検出されるおよび／またはビジーであると決定される場合、特定のＳＴＡはオフに戻り得る。１つのＳＴＡ（たとえば、ただ１つの局）が、所与のＢＳＳ中で所与の時間に送信し得る。

高スループット（ＨＴ）のＳＴＡは、４０ＭＨｚ幅のチャネルを形成するために、たとえば、隣接するまたは隣接していない２０ＭＨｚのチャネルとの１次の２０ＭＨｚのチャネルの組合せを介した通信のために４０ＭＨｚ幅のチャネルを使用し得る。

極高スループット（ＶＨＴ）のＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚ幅のチャネルをサポートし得る。４０ＭＨｚおよび／または８０ＭＨｚのチャネルは、連続する２０ＭＨｚのチャネルを組み合わせることによって形成され得る。１６０ＭＨｚのチャネルは、８つの連続する２０ＭＨｚのチャネルを組み合わせることによって、または８０＋８０構成と呼ばれることがある２つの不連続の８０ＭＨｚのチャネルを組み合わせることによって形成され得る。８０＋８０構成では、データは、チャネル符号化後に、２つのストリームにデータを分割し得るセグメントパーサを通してパスされ得る。逆高速フーリエ変換（ＩＦＦＴ）処理と時間領域処理とが別々に各ストリームに対して行われ得る。ストリームは、２つの８０ＭＨｚのチャネル上にマッピングされ得、データは、送信ＳＴＡによって送信され得る。受信ＳＴＡの受信機では、８０＋８０構成について上記で説明した動作が逆行され得、組み合わされたデータが媒体アクセス制御（ＭＡＣ）に送られ得る。

８０２．１１ａｆおよび８０２．１１ａｈによってサブ１ＧＨｚ動作モードがサポートされる。チャネル動作帯域幅およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃで使用されるものと比較して８０２．１１ａｆおよび８０２．１１ａｈでは低減される。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトル中の５ＭＨｚ、１０ＭＨｚ、および２０ＭＨｚの帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚの帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレージエリア中のＭＴＣデバイスなどのメータ型制御／マシン型通信（ＭＴＣ）をサポートし得る。ＭＴＣデバイスは、いくつかの能力、たとえば、いくつかのおよび／または限定された帯域幅のサポート（たとえば、それだけのサポート）を含む限定された能力を有し得る。ＭＴＣデバイスは、（たとえば、非常に長いバッテリ寿命を維持するために）しきい値を上回るバッテリ寿命をもつバッテリを含み得る。

８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなどの複数のチャネルおよびチャネル帯域幅をサポートし得るＷＬＡＮシステムは、１次チャネルとして指定され得るチャネルを含む。１次チャネルは、ＢＳＳ中のすべてのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有し得る。１次チャネルの帯域幅は、ＢＳＳ中で動作するすべてのＳＴＡの中から、最小の帯域幅動作モードをサポートするＳＴＡによって設定および／または限定され得る。８０２．１１ａｈの例では、ＡＰおよびＢＳＳ中の他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／または他のチャネル帯域幅動作モードをサポートする場合でも、１次チャネルは、１ＭＨｚモードをサポートする（たとえば、それだけをサポートする）ＳＴＡ（たとえば、ＭＴＣタイプのデバイス）について１ＭＨｚ幅であり得る。キャリア検知および／またはネットワーク割振りベクトル（ＮＡＶ）の設定は、１次チャネルのステータスに依存し得る。たとえば（１ＭＨｚ動作モードだけをサポートする）ＳＴＡのために１次チャネルがビジーである場合、利用可能な周波数帯域の大部分がアイドルのままである場合であっても、ＡＰにすべての利用可能な周波数帯域を送信することがビジーであると見なされ得る。

米国では、８０２．１１ａｈによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚまである。韓国では、利用可能な周波数帯域は、９１７．５ＭＨｚから９２３．５ＭＨｚまである。日本では、利用可能な周波数帯域は、９１６．５ＭＨｚから９２７．５ＭＨｚまである。８０２．１１ａｈのために利用可能な総帯域幅は、国コードに応じて６ＭＨｚから２６ＭＨｚまでである。

図１Ｄは、一実施形態による、ＲＡＮ１０４およびＣＮ１０６を示すシステム図である。上記のように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＮＲ無線技術を採用し得る。ＲＡＮ１０４はまた、ＣＮ１０６と通信していることがある。

ＲＡＮ１０４は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１０４が、実施形態に一致したままでありながら、任意の数のｇＮＢを含み得ることを諒解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含み得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装し得る。たとえば、ｇＮＢ１８０ａ、１０８ｂは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信し、および／またはそれから信号を受信するためにビームフォーミングを利用し得る。したがって、ｇＮＢ１８０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、および／またはそれからワイヤレス信号を受信するために複数のアンテナを使用し得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装し得る。たとえば、ｇＮＢ１８０ａは、ＷＴＲＵ１０２ａ（図示せず）に複数コンポーネントキャリアを送信し得る。これらのコンポーネントキャリアのサブセットは、無認可スペクトル上にあり得るが、残りのコンポーネントキャリアは、認可スペクトル上にあり得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、協調マルチポイント（ＣｏＭＰ）技術を実装し得る。たとえば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調送信を受信し得る。

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルな数秘学に関連する送信を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。たとえば、ＯＦＤＭシンボル間隔および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または異なるワイヤレス送信スペクトルの部分ごとに変動し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（たとえば、様々な数のＯＦＤＭシンボルを含んでいるおよび／または変動する長さの絶対時間の間続く）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成中のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（たとえば、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなど）にアクセスすることもなしにｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、モビリティアンカーポイントとしてｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数を利用し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無認可帯域中の信号を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信しながら／それにも接続しながらｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る／それに接続し得る。たとえば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃおよび１つまたは複数のｅノードＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信するためにＤＣ原理を実装し得る。非スタンドアロン構成では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカーとして働き得、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃをサービスするための追加のカバレージおよび／またはスループットを与え得る。

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）に関連付けられ得、無線リソース管理の決定、ハンドオーバの決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、ＤＣ、ＮＲとＥ－ＵＴＲＡとの間の相互接続、ユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂに向けたユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂに向けた制御プレーン情報のルーティングなどを扱うように構成され得る。図１Ｄに示すように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いと通信し得る。

図１Ｄに示すＣＮ１０６は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂと、少なくとも１つのＵＰＦ１８４ａ、１８４ｂと、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂと、場合によっては、データネットワーク（ＤＮ）１８５ａ、１８５ｂとを含み得る。上記の要素がＣＮ１０６の一部として示されているが、これらの要素のいずれかがＣＮオペレータ以外のエンティティによって所有および／または動作され得ることを諒解されよう。

ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１０４中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続され得、制御ノードとして働き得る。たとえば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシング（たとえば、異なる要件をもつ異なるプロトコルデータユニット（ＰＤＵ）セッションの扱い）のサポート、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、登録エリアの管理、非アクセス層（ＮＡＳ）シグナリングの終了、モビリティ管理などを担当し得る。ネットワークスライシングは、利用されたＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃであるサービスのタイプに基づいてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮのサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。たとえば、異なるネットワークスライスは、高信頼低遅延（ＵＲＬＬＣ）アクセスに依拠するサービス、拡張大規模モバイルブロードバンド（ｅＭＢＢ）アクセスに依拠するサービス、ＭＴＣアクセスのサービスなどの異なる使用事例のために確立され得る。ＡＭＦ１８２ａ、１８２ｂは、ＲＡＮ１０４とＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術などの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を与え得る。

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介してＣＮ１０６中のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介してＣＮ１０６中のＵＰＦ１８４ａ、１８４ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択および制御し、ＵＰＦ１８４ａ、１８４ｂを通してトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＥのＩＰアドレスを管理し、割り振ること、ＰＤＵセッションを管理すること、ポリシーの実施およびＱｏＳを制御すること、ＤＬデータの通知を与えることなどの他の機能を実行し得る。ＰＤＵセッションのタイプは、ＩＰベースのもの、非ＩＰベースのもの、イーサネットベースのものなどであり得る。

ＵＰＦ１８４ａ、１８４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするためにインターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与え得るＮ３インターフェースを介してＲＡＮ１０４中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続され得る。ＵＰＦ１８４、１８４ｂは、パケットをルーティングおよび転送すること、ユーザプレーンのポリシーを強制すること、マルチホームＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳを扱うこと、ＤＬパケットをバッファリングすること、モビリティアンカリングを与えることなどの他の機能を実行し得る。

ＣＮ１０６は、他のネットワークとの通信を容易にし得る。たとえば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含み得るかまたはそれと通信し得る。さらに、ＣＮ１０６は、他のサービスプロバイダによって所有および／または動作される他のワイヤードおよび／またはワイヤレスネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与え得る。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェースおよびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介してＵＰＦ１８４ａ、１８４ｂを通してローカルＤＮ１８５ａ、１８５ｂに接続され得る。

図１Ａ～図１Ｄおよび図１Ａ～図１Ｄの対応する説明に鑑みて、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、ｅノードＢ１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ、および／または本明細書で説明する任意の他のデバイスのうちの１つまたは複数に関して本明細書で説明する機能のうちの１つもしくは複数またはすべては、１つまたは複数のエミュレーションデバイス（図示せず）によって実行され得る。エミュレーションデバイスは、本明細書で説明する機能のうちの１つもしくは複数またはすべてをエミュレートするように構成された１つまたは複数のデバイスであり得る。たとえば、エミュレーションデバイスは、他のデバイスをテストする、ならびに／またはネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために使用され得る。

エミュレーションデバイスは、ラボ環境でおよび／またはオペレータネットワーク環境で他のデバイスの１つまたは複数のテストを実施するように設計され得る。たとえば、１つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするためにワイヤードおよび／またはワイヤレス通信ネットワークの一部として完全にまたは部分的に実装および／または展開されながら、１つもしくは複数またはすべての機能を実行し得る。１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワークの一部として一時的に実装／展開されながら、１つもしくは複数またはすべての機能を実行し得る。エミュレーションデバイスは、オーバージエアワイヤレス通信を使用してテストするおよび／またはテストを実行するために別のデバイスに直接結合され得る。

１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワークの一部として実装／展開されることなしに、すべてを含む１つまたは複数の機能を実行し得る。たとえば、エミュレーションデバイスは、１つまたは複数の構成要素のテストを実施するために試験所ならびに／または展開されていない（たとえば、テスト用の）ワイヤードおよび／もしくはワイヤレス通信ネットワーク中のテストシナリオで利用され得る。１つまたは複数のエミュレーションデバイスは、テスト機器であり得る。データを送信および／または受信するためにエミュレーションデバイスによって、直接ＲＦ結合および／または（たとえば、１つまたは複数のアンテナを含み得る）ＲＦ回路を介したワイヤレス通信が使用され得る。

無人航空機（ＵＡＶ）は、様々な適用例、たとえば、小荷物配達、農業、石油およびガス検査、ならびに映画撮影技術に展開され得る。地上モバイルユーザと共存するＵＡＶを有することを期待する、通信の観点から最近の３ＧＰＰ航空研究項目において識別されているいくつかの技術課題がある。ＵＡＶと地上ユーザとの間での動作シナリオの主要な差のうちの１つは、前者が０から４００フィートの間の高度で動作し、一方、後者が最高５０フィートの任意の場所で動作することが予想されるということである。ドローンのための動作シナリオは、より広い高度範囲を有し得、異種チャネル伝搬環境を経験し得る。航空ユーザと地上ユーザとの共存に関して航空研究項目によって識別されている問題は、航空機によって生じるおよび／または航空機に影響を及ぼすアップリンクおよび／またはダウンリンク干渉、シグナリング態様（たとえば、測定報告態様、セル再選択トリガ態様、ハンドオーバ／モビリティ態様など）の最適化、ならびに航空機の識別のうちの１つまたは複数を含み得る。３ＧＰＰ研究項目の重点は、ここまで、ＵＡＶとネットワークとの間のＵｕインターフェースであった。サイドリンク通信は対処されていない。３ＧＰＰにおけるサイドリンク通信は、ＰｒｏＳｅダイレクトディスカバリ、ダイレクト通信（リリース１２から）、およびＶ２Ｘ通信（リリース１４から）について考慮した。

新技術市場の最近の実現可能性研究において考慮された使用事例のうちの１つは、ネットワーク協調なしに局所的に行われ得るＵＡＶ対ＵＡＶコラボレーションである。ＵＡＶのグループが、共通のミッションを達成するために展開され得る。たとえば、ＵＡＶのグループは、共通の侵入機または疑わしい機体を探索するか、天災を連続的に監視するか、または、自律測量を実行し得る。これらのシナリオでは、共通の仮定とそれの変形形態とが、たとえば、以下のシナリオのうちの１つまたは複数に基づいてモデル化され得る。

グループ中のすべてのＵＡＶを管理するパイロットなどの１つのＵＡＶコントローラがあり得る。たとえば、制御中のパイロットは、ブロードキャストメッセージングを通してグループのすべてのメンバに共通のコマンドおよび制御メッセージを与え得、一方、１つのＵＡＶにユニキャストを通してメンバ固有の制限付きコマンドおよび制御メッセージを与える。

ＵＡＶは、サイドリンク通信を使用してグループを自律的に形成する能力を有し得る。代替的に、ＵＡＶは、サービスレベルの観点から、たとえば、中央コントローラによって指名された特定のグループに属し得る。ＵＡＶは、互いに、さらに中央コントローラに直接リンクを有し得る。

ＵＡＶグループの１つのメンバは、代表のＵＡＶと見なされ得、一方、他のＵＡＶは、随員のＵＡＶとして指名され得る。代表のＵＡＶと随員のＵＡＶとの割当ては、事前指定されたルールおよび／または遭遇した条件のセットに基づいて瞬時に、たとえば、動的にＵＡＶによって共同で決定され得る。代替的に、代表と随員とは、中央コントローラによってミッションのために静的に選定され得る。ＵＡＶグループがミッションのために従う必要があり得るルートは、事前指定され、決定論的であり得る。

発展型マルチメディアブロードキャストマルチキャストサービス（ｅＭＢＭＳ）は、３ＧＰＰにおいてリリース１１で導入され、ブロードキャスト／マルチキャストサービスのために使用され得る。ｅＭＢＭＳ通信は、単指向性サービスであり得る。パケットは、ソースから受信機のグループに配信され得、受信機のいずれかからソースに送られるフィードバックがないことがある。

フィードバックがないことの１つの理由は、パケットを受信していないブロードキャスト／マルチキャストグループのメンバがいるであろうという確率が高いことであり得る。これは、具体的には、ブロードキャスト／マルチキャストグループのサイズがかなり大きく、グループの各メンバが独立したチャネル状態を経験する場合に発生し得る。したがって、ソース（たとえば、ｅＮＢ）によって送信されるパケットごとに、パケットを再送信することの確率は、ブロードキャスト／マルチキャストグループサイズの増加とともに増加する。コーディングレートおよび変調符号化方式（ＭＣＳ）がグループ中で最も弱いユーザに基づいて設計され得るが、グループのあらゆるメンバによるパケット受信に関する保証はない。さらに、再送信および保守的なコーディングは、特にグループ中のより強いユーザにとって減少されたスペクトル効率につながり得る。パケットの再送信を要求するグループのメンバによってトリガされ得る再送信の複雑性と信頼性との間のバランスを取るために、グループのメンバによるパケット受信にかかわらずソースによって実行される固定数の再送信があり得る。これは、減少した効率につながり得る。

グループ中に同じパケットを紛失した複数のメンバがある場合、ソースが処理しなければならないことがある否定応答（ＮＡＣＫ）のフラッディングがあり得る。これは、ＷＴＲＵが、他のＷＴＲＵのパケット紛失シナリオに気づいていないことがあり、フィードバックを個々に送り得るという事実のためであり得る。

単方向トランスポートを介したファイル配信（ＦＬＵＴＥ：Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコルは、単方向ベアラを使用してファイルを配信するために使用され得る。ＦＬＵＴＥを介したエラーのない受信を保証することが可能でないことがある。したがって、ユニキャスト方式は、紛失したパケットを回復するために使用され得る。

ブロードキャストセッションが完了した後、ソースは、ブロードキャスト／マルチキャストグループのメンバの各々とユニキャストセッションを開始し得る。各メンバは、たとえば、アプリケーションレベルおよび／またはパケット紛失情報などのＦＬＵＴＥレベルを与え得る。ソースは、成功した配信まで各メンバに紛失したパケットのみを再送信し得る。代替的に、パケットがファウンテンコーディングされる場合、各メンバは、紛失したパケットの数のみを与え得、どのパケットが紛失されたのかをソースに知らせる必要がないことがある。ソースは、メンバが要求するより多数のパケットを送信し得、これは、ファイルの復号可能性を改善し得る。

物理ダウンリンク共有チャネル（ＰＤＳＣＨ）は、ユニキャストデータ送信のために使用され得、物理マルチキャストチャネル（ＰＭＣＨ）は、発展型マルチメディアブロードキャストマルチキャストサービス（ｅＭＢＭＳ）送信のために使用され得る。ＰＤＳＣＨは、時間と周波数との両方にわたって多重化され得、一方、ＰＭＣＨは、時間のみにわたって多重化され得る。すなわち、ＰＤＳＣＨは、時間と周波数との両方にわたってユーザに割り振られ得るが、これは、ＰＭＣＨでは可能でないことがある。ＰＭＣＨは、サブフレームレベル上でのみ切り替われ得る。ＰＭＣＨは、マルチキャストブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）エリアを構成する複数のセルにわたって協調され得る。各ｅＮＢが有する可能性がある独立したユニキャストリソース割振りによりＭＢＳＦＮエリア中のすべてのセルの総リソースブロック（ＰＲＢ）の観点からリソース割振りにおいて均一性を保証することが困難であり得る。ＰＭＣＨ上でのリソース割振りの粒度は、サブフレームレベルで粗くなり得、これは、不十分なリソース利用につながり得る。たとえば、ブロードキャストレートが低い場合、またはマルチキャスト送信が実行され得るセルにわたってユーザが移動している場合、ｅＭＢＭＳサービスを呼び出すことは、サブフレームレベルですべてのｅＮＢを協調させる必要により効率的でないことがある。単一セルポイントツーマルチキャスト（ＳＣ－ＰＴＭ）は、これに対処し得、それによって、各セルは、ブロードキャスト／マルチキャストならびにユニキャストの両方をサービスするためにそれのＰＤＳＣＨを独立して使用し得る。

ブロードキャスト／マルチキャストのための方式は、ブロードキャストにおけるパケット復号可能性を向上させるために保守的なコーディングレート、ＭＣＳ、および固定された再送信を使用し得る。さらに、ブロードキャスト／マルチキャストグループのメンバに紛失したパケットを再送信するためにユニキャストが使用され得る。ネットワーク／インデックスコーディングを使用してパケット紛失のための最適な送信方式を発見する必要があり得る。

ブロードキャスト／マルチキャストＵｕ通信のパケット修復効率とスペクトル効率とを改善するためにブロードキャスト／マルチキャストグループのメンバがサイドリンク／ＷｉＦｉ直接通信の存在を活用するグループ協働を実行し得るプロトコルについて本明細書で説明する。

図２は、ＵＡＶグループ化の概念を示す。例示的なＵＡＶグループは、共通のミッションを達成するために展開され得る第１のＵＡＶ２０２と、第２のＵＡＶ２０４と、第３のＵＡＶ２０６と、第４のＵＡＶ２０８とを含み得る。グループのメンバは、ＵＡＶトラフィック管理（ＵＴＭ）コントローラまたはパイロットによって与えられ得、ｅＮＢ２１０によってマルチキャストを介して送信され得る共通のコマンドおよび制御（Ｃ２）メッセージを受信し得る。ｅＮＢ２１０は、Ｕｕインターフェースを介して第１のＵＡＶ２０２と、第２のＵＡＶ２０４と、第３のＵＡＶ２０６と、第４のＵＡＶ２０８とのうちの１つまたは複数と通信し得る。ｅＮＢ２１０は、共通のグループ固有のＣ２を送信するためにＵＡＶのグループのためのグループ無線ネットワーク一時識別子（Ｇ－ＲＮＴＩ）を構成し得る。グループ固有のＣ２は、Ｇ－ＲＮＴＩを共有するグループのあらゆるメンバが復号し得るダウンリンク上の単一の送信であり得る。グループの各メンバによって経験される独立したチャネル状態により、紛失および受信されるパケットはグループの他のメンバごとに異なり得る。異なるグループメンバによって紛失および受信されるパケットの差は、局所的に活用され得る。たとえば、グループの１つのメンバは、デバイス間またはビークル間（Ｄ２Ｄ／Ｖ２Ｖ）のサイドリンク通信を使用してこのパケットを紛失した別のメンバにそれの受信されたパケットを送り得る。

たとえば、変数Ｂ_iは、グループのメンバｉによって紛失されるパケットを表し得、変数Ｓは、ｅＮＢによって送信されるパケットを表し得、変数∪は、グループ中のメンバの数を表し得る。グループによる紛失したパケットのセットＬは以下の通りであり得る。
∪が大きくなるにつれて、
Ｌ：＝［Ｓ＼∪_i｛Ｂ_i｝］≒φ 式１

ｅＮＢによって送信されたパケットを受信する可能性があるグループの少なくとも１つのメンバがあり得るので、∪が増加するにつれてグループによる紛失したパケットのセットＬは０（すなわち、ヌルセット）に近づき得る。

図２に示されたＵＡＶグループでは、以下の通りであり得る。
Ｓ＝｛１，２，３，４｝、Ｂ₁＝｛３，４｝、Ｂ₂＝｛１，３，４｝、Ｂ₃＝｛１，４｝、Ｂ₄＝｛２，４｝、およびＬ＝｛４｝ 式２

この例では、パケット｛４｝は、ＵＡＶグループのいかなるメンバによっても受信されないことがあり、一方、他のパケット｛１，２，３｝は、ＵＡＶグループの１つまたは複数のメンバによって受信され得る。パケット｛１，２，３｝は、グループのメンバの間で局所的に回復され、それによって、ユニキャストまたはマルチキャストによってパケットを再送信するためにグループのメンバがｅＮＢに依拠しなければならないことを回避し得る。しかしながら、パケット｛４｝は、グループのいかなるメンバによっても受信されていなかったので、局所的に回復され得ない。

サイドリンクを通して紛失したＵｕパケットを回復するために、各メンバは、他のグループメンバの紛失／受信されたパケット情報に気づいている必要があり得る。あらゆるメンバのパケット紛失情報が他のグループメンバと効率的に共有されるようにプロトコルが使用され得る。あらゆるメンバが他のメンバによって紛失または受信されるパケットに気づいていると、パケットがメンバの間で効率的に交換され得るサイドリンクベースのパケット修復のためにプロトコルが使用され得るので、あらゆるメンバは、別のメンバからそれの紛失したパケットを直接取得し得る。サイドリンクチャネルは、ＩＥＥＥ８０２．１１またはＶ２Ｖなどの特定のプロトコルを使用して実装され得る。

サイドリンク支援型ダウンリンクブロードキャスト（ＳＡＤＢ：Ｓｉｄｅｌｉｎｋ Ａｓｓｉｓｔｅｄ Ｄｏｗｎｌｉｎｋ Ｂｒｏａｄｃａｓｔ）のために使用されるプロトコルは、グループキャストＮＡＣＫ（ｇＮＡＣＫ）送信と、グループメンバの間でのパケット紛失伝播のための効率的なプロトコルと、グループメンバの間でのパケット修復のための効率的なプロトコルとを含み得る。

ＳＡＤＢでは、グループメンバは、ネットワークインフラストラクチャ（たとえば、ｅＮＢ）にパケットを再送信させる代わりにグループの別のメンバから紛失したパケットを取得し得る。場合によっては、ブロードキャスト／マルチキャスト中での再送信は、たとえば、３ＧＰＰおよび／またはＩＥＥＥ８０２．１１プロトコルスタックのレイヤ中で許可されないことがある。しかしながら、ブロードキャスト送信中に発生するエラーは、ＦＬＵＴＥなどのユニキャスト機構によって訂正され得る。

ＳＡＤＢでは、グループメンバによって紛失されたダウンリンクブロードキャストパケットは、グループの別のメンバから利用可能であり得る。グループメンバによって経験されるパケット紛失は独立していることがあり、したがって、１つのメンバからの紛失したパケットが少なくとも１つの他のグループメンバから利用可能であり得る。ＳＡＤＢプロトコルは、ユーザデータグラムプロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ）を介してアプリケーションレイヤにおいて構築され得、下位レイヤとは無関係であり得る。ＳＡＤＢプロトコルはまた、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）、無線リンク制御（ＲＬＣ）、およびメディアアクセス制御／物理（ＭＡＣ／ＰＨＹ）レイヤなどの下位レイヤ上に構築され得る。ＳＡＤＢのためのＰＤＣＰ実装は、アプリケーションレベルの実装と同様であり得る。ＳＡＤＢのＲＬＣ実装は、グループメンバのただ１つがパケットを紛失した場合でもパケットが再送信される必要があり得るのでオーバーヘッドを招き得る確認型モードでＲＬＣレイヤが送信することを必要とし得る。ＳＡＤＢのためのアプリケーションレベルプロトコルについて以下で考慮する。

図２に示されるように、パケット｛４｝は、グループメンバのすべてによって紛失され得る。サイドリンクベースのローカル協働を通してパケットを修復することが可能でないことがある。ｇＮＡＣＫは、パケットが受信されていなかったことを示すためにグループの任意のメンバによって送信され得る。ｇＮＡＣＫメッセージは、パケット｛４｝が送信メンバによってだけでなく、グループメンバのすべてによっても受信されていなかったことを示し得る。

すべてのグループメンバによって紛失された共通のパケットを決定する１つのやり方は、各メンバがそれのグループメンバに局所的にそれの紛失／受信されたパケット情報をブロードキャストすることであり得る。あらゆるユーザが特定のタイムスロット（たとえば、それの紛失／受信された情報をブロードキャストするためにユーザが使用しなければならない時間スロット／周波数リソース）においてチャネルにアクセスするために従わなければならないユーザの事前指定された順序が使用され得る。事前指定されたチャネルアクセス機構を使用することの１つの利点は衝突回避であり得る。パケットステータス情報（たとえば、受信および紛失された情報）はグループのメンバに知られ得る。

Ｎ個のグループメンバがあり得、各メンバは、ｎ個のパケットの各々についてのステータス情報を送信し得る。共通の周波数リソース、たとえば、パケットステータス送信リソースプールが利用可能であり得る。この方式は、グループ中の各メンバのパケットの各々についてのグローバル情報を取得するためにＮｎビットの総数をもつＮ個の時間リソースを使用し得る。

表１は、３人のユーザ（Ｕ１，Ｕ２，Ｕ３）のためのダウンリンクブロードキャストによって受信された６つのパケット（Ｐ１～Ｐ６）のためのパケットステータス情報を示す。表１では、１の値は、パケットが正常に受信されたことを表し、０の値は、紛失したパケットを表す。

各ユーザは、事前指定されたパケット順序（たとえば、増加するパケットシーケンス番号）で報告されなかった各パケットのステータスを送信し得る。第１のユーザＵ１は、６つのパケットのステータスを示すために６ビットを送信しなければならないことがある。第２のユーザＵ２は、紛失したパケットしか注目しないので、第１のユーザによって紛失されたと報告されたパケットのステータスしか送信する必要がない。他のメンバが、メッセージを受信し、それに応じてそれら自体のパケットステータス情報を準備し得るように、各ユーザが送信した後にリードタイム（たとえば、４つのサブフレーム）があり得る。たとえば、Ｕ２は、第２に送信する場合、２ビットを招く、｛Ｐ１，Ｐ２｝であり得る事前指定された順序、（たとえば、増加するパケットシーケンス番号）でＵ１によって受信されなかったパケットのステータスを報告し得る。第３のユーザＵ３は、Ｕ１とＵ２との両方によって紛失されたことが報告されたパケットのみのステータスを報告する必要があり得る。Ｕ３は、第３に送信する場合、１ビットを招く｛Ｐ２｝のステータスを与え得る。Ｕ３が送信した後に、すべてのユーザによってどのパケットが受信されなかったのかが明らかになり得る。それに応じて、送信に必要なビット数は、６＋２＋１＝９ビットであり得る。

表２は、異なるユーザ送信順序のためのｇＮＡＣＫ決定に必要なビット数を示す。

送信の順序は、ｇＮＡＣＫ情報を伝播するのに必要とされるビットの総数を最適化するのに重要な役目を果たし得る。最大数の正しく受信されたパケットをもつユーザが第１に送信し、より高い送信優先度を有することが有利であり得る。第１に送信するユーザは、それがどれくらいの数を正しく受信したかにかかわらず、すべてのパケットのステータス情報を与えなければならないことがある。その後に送信するユーザは、差分情報のみを与え得る。あらゆる送信瞬間において前に報告されてない受信されたパケットの受信に関する最大限の情報を与えることが望ましいことがある。

分散フレームワークにより、グループメンバは、それが最も多くの受信されたパケットを有するのかどうかを知ることが可能でないことがある。したがって、グループメンバがグループの他のメンバと比較して受信されたパケットの数を決定することが暗黙的に可能であり得る機構がある必要があり得る。この概念は、上述の観察を活用する優先度ベースの確率論的方式であり得るｇＮＡＣＫプロトコルの根拠であり得る。

ｇＮＡＣＫプロトコルは、ダウンリンクブロードキャストを通して受信されたｎ個のパケットのブロックＰ＝（｛１，２．．．ｎ｝）で続け得る。サイズＮのグループの場合、変数Ａ_iは、ユーザｉによって受信されたパケットを示し得、変数

は、ユーザｉの損失割合を示し得る。ユーザは、損失割合に基づいて異なるアクセスクラスにカテゴリー分類され得る。アクセスクラスへのユーザの例示的なカテゴリー分類を表３に示す。

最小のパケット紛失を有するユーザがチャネルにアクセスするのに最高の優先度が与えられ得る。たとえば、

を有するユーザはクラス１に割り当てられ得る。クラス１は、コンテンションウインドウ範囲によって見られるチャネルへの最小アクセス遅延を有し得る。

アクセスクラスのためのコンテンションウインドウ範囲は、以下のように定義され得る。
ＣＷ_i＝［ＣＷｍｉｎ_i ＣＷｍａｘ_i］ 式３

それは、異なるクラス、たとえば、

にわたって重複し得ず、したがって、
ＣＷｍｉｎ_i+1＞ＣＷｍａｘ_i＞ＣＷｍｉｎ_i 式４
となる。

アクセスクラスｉのためのバックオフ範囲は、より高い優先度のクラスにアクセス利点を与えるように、クラス（ｉ＋１）よりも低くなり得る。複数のユーザが同じアクセスクラスに分類される場合、ユーザは、アクセスクラスの特定のコンテンションウインドウ範囲に従ってそれらのバックオフ時間をランダムに選定し得る。

ｇＮＡＣＫプロトコルの初期化は、Ｙ＝｛φ｝をグループによって正しく受信されたと報告されたパケットのセットに設定することを含み得る。第１のステップでは、

は、Ａ_i、∀ｉ＝１，２，．．．Ｎから計算され得る。あらゆるメンバは、Ｅｒｒｏｒ！ Ｒｅｆｅｒｅｎｃｅ ｓｏｕｒｃｅ ｎｏｔ ｆｏｕｎｄ．中で上記で説明されたプロシージャに基づいてアクセスクラスに割り当てられ得る。ステップ２では、それのアクセスクラス割当てに基づいて最小バックオフ時間を選定したグループメンバｋは、チャネルにアクセスし、すべてのメンバに受信されたパケットのそれのリストＡ_kをブロードキャストし得る。ステップ３では、Ｙ＝Ｙ∪Ａ_kが計算され得、Ａ_k＝φが設定され得る。ステップ４では、ｉ＝１，２，．．．Ｎ，Ａ_i＝（Ａ_i∩（Ｐ＼Ｙ））がすべてのメンバのために更新され得る。ステップ５では、ステップ１から４が、Ａ_i＝φ，∀ｉ＝１，２．．Ｎまで繰り返され得る。ステップ６では、ｇＮＡＣＫ＝Ｐ＼Ｙが計算され得る。

このプロトコルのアプリケーションレベルの使用事例は、ビデオブロードキャスティングにおいてあり得、クライアントのいずれも受信していないことをＲＴＰパケットが示すグループＲＴＣＰフィードバックがクライアントのいずれかによって送られ得る。

表１のパケット紛失シナリオを参照すると、ユーザは、（パケットエラー＜０．３５）である場合はクラス１に割り当てられ得、（０．３５＜パケットエラー＜０．６５）である場合はクラス２に割り当てられ得、（０．６７＜パケットエラー＜１）である場合はクラス３に割り当てられ得る。ｇＮＡＣＫプロトコルは、＝｛φ｝，Ｐ＝｛１，２，３，４，５，６｝，Ａ₁＝｛３，４，５，６｝，Ａ₂＝｛１，３｝，Ａ₃＝｛１｝に設定することによって初期化され得る。

第１の反復のステップ１では、

、

、

である。ユーザ１はクラス１に割り当てられ得、ユーザ２はクラス２に割り当てられ得、ユーザ３はクラス３に割り当てられ得る。ユーザ１は、チャネルにアクセスし得る。第１の反復のステップ２では、Ａ₁＝｛３，４，５，６｝である。第１の反復のステップ３では、Ｙ＝｛３，４，５，６｝，Ａ₁＝｛φ｝である。第１の反復のステップ４では、Ｐ＼Ｙ＝｛１，２｝，Ａ₂＝｛１｝，Ａ₃＝｛１｝である。

第２の反復のステップ１では、ユーザ２とユーザ３とは、パケット１しか有しないので（第１の反復からのステップ４を参照）、両方は、５／６の新しい誤り率を有し得る。したがって、それらは、クラス３に割り当てられ得る。ユーザ２は、より低いバックオフを選択し得、それは、ユーザ３の前にチャネルにアクセスし得る。第２の反復のステップ２では、Ａ₂＝｛１｝である。第２の反復のステップ３では、Ｙ＝｛１，３，４，５，６｝，Ａ₂＝｛φ｝である。第２の反復のステップ４では、Ｐ＼Ｙ＝｛２｝，Ａ₃＝｛φ｝である。したがって、Ｐ＼Ｙ＝｛２｝である。

ｇＮＡＣＫに対するＭＡＣ／ＰＨＹレイヤ手法では、ｅＮＢによって送られたブロードキャストパケットを復号するためにブロードキャスト／マルチキャストグループのユーザが使用し得るグループ固有のＧ－ＲＮＴＩにブロードキャスト／マルチキャスト送信が関連付けられ得る。ユーザ固有のセル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ）もユニキャストパケットを復号するために使用され得る。以下の説明は、フレーム／サブフレームタイミングと、ｇＮＡＣＫフィードバックがユニキャストフィードバックとはどのように異なるのかと、それの設計に影響を及ぼし得るパラメータとを含む。

図３は、ｇＮＡＣＫフィードバックのためのダウンリンクおよびアップリンクサブフレームタイミングを示す。ｇＮＡＣＫプロトコルは、Ｒ個のサブフレームのブロックで続け得る。長さＲのダウンリンクサブフレームのためのｇＮＡＣＫフィードバックは、アップリンク中で後でＫ個のサブフレームを送られ得る。この例では、Ｋ＞Ｒであると仮定する。図３に示されるように、ダウンリンクサブフレーム［ｎ，（ｎ＋Ｒ－１）］のためのｇＮＡＣＫフィードバックは、アップリンクフレーム（ｎ＋２Ｋ）において送り出され得、一方、ダウンリンクサブフレーム［（ｎ＋Ｒ）、（ｎ＋２Ｒ－１）］のためのｇＮＡＣＫフィードバックは、アップリンクフレーム（ｎ＋３Ｋ）において送り出され得る。

パラメータＫは、ｇＮＡＣＫを送り出すのに必要とされ得る遅延を示し得、グループ中のメンバの数Ｎに依存し得る。より多数のメンバがグループ通信に参加する場合、ｇＮＡＣＫを決定するのに必要な時間がより長くなり得る。ｇＮＡＣＫフィードバックが過大に遅延されないことを保証するために、ｅＮＢは、グループサイズＮを許容できる数に制限し得る。グループサイズが許容できる次元数を超える場合、ｅＮＢは２つ以上のグループを形成することを選定し得る。この状況では、２つ以上のＧ－ＲＮＴＩが、各グループとそれの従属メンバとに割り振られ得る。

パラメータＲは、ｇＮＡＣＫが探されるサブフレームの数を示し得る。ｅＭＢＭＳでは、ブロードキャストスケジューリングは、あらゆるサブフレームに対して実行されないことがある。Ｒ個のサブフレーム中にスケジュールされるブロードキャストパケットの数は、ｇＮＡＣＫプロトコルのために必要とされる情報のすべてであり得る。

変数ｄは、グループ固有のブロードキャスト／マルチキャスト送信に対して定義されるＨＡＲＱプロセスの最大数であり得る。したがって、ｇＮＡＣＫ生成では、ｄは、Ｒ（ブロードキャストスケジュールされたサブフレームの数）とＫ（ｇＮＡＣＫを送るための遅延パラメータ）とに応じて適応可能である必要があり得る。ＨＡＲＱプロセスの最大数ｄがＲとＫとの両方の増加関数であり得るが、ｅＮＢにおける増加したバッファリングの必要は、グループ固有であり、ユーザ固有でないことがある。ブロードキャスト送信のためのユーザ固有のＮＡＣＫでは、バッファ要件は、ｇＮＡＣＫ方式のためのバッファ要件よりもはるかに高いことがある。ブロードキャスト送信のためのユーザ固有のＮＡＣＫの場合、一部のユーザは、他のユーザよりも多くのパケット紛失を有し得、ｅＮＢは、最も高いパケット紛失をもつユーザに基づいてパケットをバッファしなければならないことがある。

ユニキャストシナリオにおけるＨＡＲＱフィードバックは、それが単一レイヤであるのか二重レイヤであるのかに応じて１または２ビットしか必要としないことがある。アップリンクでは、ｅＮＢは、それがＷＴＲＵからのフィードバックを予想している一意のＨＡＲＱプロセスに気づいていることがある。しかしながら、ｇＮＡＣＫの場合、フィードバックは、エラーで受信されていることのある明示的なＨＡＲＱプロセスを示し得る。ｇＮＡＣＫがｘ個のＨＡＲＱプロセスごとに試みられる場合、単一のＨＡＲＱプロセスのためのフィードバックは、［ｌｏｇ₂ｘ］ビットであり得る。

図３に示されるように、ダウンリンクサブフレーム［ｎ，（ｎ＋Ｒ－１）］のためのｇＮＡＣＫフィードバックは、ｍ₁個のアップリンクフレーム［ｎ＋２Ｋ，（ｎ＋２Ｋ＋ｍ₁－１）］中で送り出され得る。２ビットがＰＵＣＣＨ上でｇＮＡＣＫフィードバックを送るためにサブフレームごとに割り振られると仮定すると、ｇＮＡＣＫフィードバックは、合計

個のＨＡＲＱプロセスまで送られ得る。アップリンク中の開始サブフレームおよびｇＮＡＣＫを送るためのサブフレームの数（ｍ₁）は、ｅＮＢによってシグナリングされ得る。ｇＮＡＣＫを送るためにＷＴＲＵによって使用される必要があるＰＵＣＣＨリソースは、たとえば、ＳＣ－ＰＴＭの場合にブロードキャスト／マルチキャスト関連のダウンリンク制御情報（ＤＣＩ）をシグナリングするために使用されるＰＤＣＣＨ中の開始制御チャネル要素（ＣＣＥ）ロケーションに基づき得る。

代替的に、ｅＮＢは、Ｇ－ＲＮＴＩのための開始リソース（ｘ₁）をシグナリングし得、ＷＴＲＵは、次のようにリソースロケーションを計算し得る。

ＷＴＲＵは、現在のサブフレーム上の２つの連続するＰＵＣＣＨリソース（ｊおよびｊ＋１）上で最高４ビットのフィードバックを与え得、このパターンは、

個の連続サブフレームの１／４の間続き得る。ｇＮＡＣＫリソースロケーションのための

は、上位レイヤによって構成され得るか、またはシステム情報ブロードキャストメッセージを通して取得される。

ｇＮＡＣＫを送るために使用されるべきＰＵＣＣＨリソースは、グループ固有であり、ＷＴＲＵ固有でないことがある。Ｃ－ＲＮＴＩによって識別され得るｇＮＡＣＫを送信する必要があるグループメンバは、事前指定され得るか、またはｅＮＢによってシグナリングされ得る。グループメンバのいずれもｇＮＡＣＫパケットを有していないことがあるとき、ｅＮＢは、グループ全体に紛失したパケットを再送信またはブロードキャストするためにＧ－ＲＮＴＩを使用し得る。代替的に、ｅＮＢは、再送信されたパケットがＧ－ＲＮＴＩに関連付けられることと、受信側が他のグループメンバへのこのパケットのサイドリンクブロードキャストを実行する必要があり得ることとを示す追加のシグナリングを用いてグループの任意のメンバにユニキャストを実行し得る。

ｇＮＡＣＫアップリンクフィードバックのサイズは、グループメンバの数Ｎ、たとえば、アップリンクサブフレームの数ｍ₁およびサブフレームごとのフィードバックビットの数に依存し得る。パケットがグループメンバのいずれかで利用可能でない確率は、増加するＮとともに減少し得る。したがって、ｅＮＢは、現在のグループメンバの数Ｎに動的に基づいてアップリンクサブフレームの数ｍ₁とサブフレームごとのフィードバックビットの数とを適応させ得る。

ｇＮＡＣＫは、グループに対して送られ、ＷＴＲＵごとに送られないことがある。パケットは、高い確率でグループのいくつかのメンバによって受信されていることがあり、したがって、パケットがすべてのメンバによって紛失される確率は小さくなり得る。変数Ｂ_iは、メンバｉによって紛失されたパケットのセットを示し得る。ｇＮＡＣＫ方式を使用するためのガイドラインは、以下の通りであり得る。
｜｛∩_iＢ_i｝｜≪｜｛∪_iＢ_i｝｜ 式６

ここで、｜（．）｜は基数を示し得る。すなわち、グループのすべてのメンバによって紛失された共通のパケットの数は、グループによって招かれたパケット紛失の和集合よりもはるかに小さくなり得る。さらに、ｇＮＡＣＫは、Ｒ個のサブフレームのブロック上で送信され得る。この方式は、すべてのメンバがサブフレーム上でパケットを紛失する確率が小さくなり得るということを活用することによってサブフレームに基づいてフィードバックを送らなければならないことのオーバーヘッドを回避し得る。

一方、以下の式
｜｛∩_iＢ_i｝｜≒｜｛∪_iＢ_i｝｜ 式７

は、およそ、各パケットが高い確率であらゆるメンバによって紛失され得、サイドリンク通信を使用して紛失したパケットを一致させることが可能でないことがあることを暗示し得る。このレジームでは、肯定応答／否定応答（ＡＣＫ／ＮＡＣＫ）が瞬時に実行され得る。ユーザが紛失したパケット上でフィードバックを受信または送信するためのいくつかのプロシージャがあり得る。

同じＧ－ＲＮＴＩ（ブロードキャスト／マルチキャスト）中のすべてのユーザについて、ｅＮＢは、接続セットアップ時にグループメンバにシグナリングされるＰＵＣＣＨ中に共通のリソース要素を割り振り得る。すべてのユーザは、彼らがパケット紛失（すなわち、ＮＡＣＫ）を有する場合にフィードバックを送るために共通のリソースを使用し得る。

パケットが間違って受信された場合、あらゆるユーザは、同じシグナリングされた共通のリソース、たとえば、エネルギーまたはシーケンスを使用してフィードバックを送り得る。すべてのユーザは、ダウンリンクフレーム（ｎ－４）中で受信されたブロードキャストパケットのためのフィードバックをアップリンクフレームｎ中で送り得る。

パケットを復号していない、およびＮＡＣＫを送信しているメンバの数に応じて、ｅＮＢによって感知される受信されたエネルギーは変化し得る。たとえば、グループメンバがＮＡＣＫの場合に一意の信号を送信する場合、ｅＮＢによって感知される受信されたエネルギーは、Ｎｘであり得、ここで、Ｎは、特定の送信時間間隔（ＴＴＩ）でＮＡＣＫを送信するメンバの数を表し得、ｘは、送信されたＮＡＣＫシーケンスであり得る。

ｅＮＢは、何人のユーザがパケットを間違って受信していることがあるのかを推定するために共通のリソースのエネルギーを感知し得る。たとえば、共通のリソース中の受信されたエネルギー（Ｅ）は、次のように推定を出すために異なるしきい値に対してチェックされ得る。Ｅ＞Ｔｈｒｅｓｈｏｌｄ１である場合、すべてのグループメンバは、共通のリソース中でＮＡＣＫを送っていることがある。Ｔｈｒｅｓｈｏｌｄ２＜Ｅ＜Ｔｈｒｅｓｈｏｌｄ３である場合、メンバの半分は、共通のリソース中でＮＡＣＫを送っていることがある。Ｔｈｒｅｓｈｏｌｄ４＜Ｅ＜Ｔｈｒｅｓｈｏｌｄ５である場合、メンバの１／５は、共通のリソース中でＮＡＣＫを送っていることがある。しきい値は、グループ中のメンバの数と、ｅＮＢがＮＡＣＫ送信のためにシグナリングした電力ｐと、グループメンバの経路損失／予想されるフェージングプロファイルを考慮に入れて設定され得る。

１つの共通のリソース要素が、エネルギー／シーケンスフィードバックを送るためにすべてのグループメンバによって使用され得る。代替的に、複数のリソース要素が割り振られ得、ここにおいて、グループメンバの相互排他的なサブセットが、エネルギー伝送のために一意のリソース要素を割り振られ得る。たとえば、グループメンバ１とメンバ２とは共に、エネルギー伝送のために共通のリソース要素ｆ₁を割り振ら得、一方、グループメンバ３とメンバ４とは共に、異なる共通のリソース要素ｆ₂を割り振られ得る。これは、ｅＮＢにグループメンバによって経験されるパケット紛失シナリオについてのより精細な情報を与え得る。このプロシージャを拡張し、それによって、一意のリソース要素がサイズが１のグループメンバの相互排他的なサブセットに割り振られることは、ＷＴＲＵごとのフィードバックを低減し得る。

特定のＧ－ＲＮＴＩに属するＷＴＲＵ／ＵＡＶは、サイズｃ_k（ｋ＝１，２．．．Ｋ）の合計Ｋ個のサブグループに分割され得る。各サブグループには、ｇＮＡＣＫを送信するためにｅＮＢによって一意のＰＵＣＣＨリソースＹ_k（ｋ＝１，２．．．Ｋ）が割り当てられ得る。ＷＴＲＵ／ＵＡＶとｅＮＢプロトコルとは、次の通りであり得る。サブグループの各メンバｋは、ＮＡＣＫが送られている場合に送信するために共通の割り当てられたリソースＹ_kを使用し得る。ｅＮＢは、リソースＹ_k（ｋ＝１，２．．．Ｋ）中でのＮＡＣＫの存在を復号し得、それがすべてのＫ個のリソース中のＮＡＣＫを復号する場合、パケットを再送信し得る。

以下の表４に示されるようにＵＥ／ＵＡＶにＧＲＮＴＩが割り当てられるとき、ＷＴＲＵ／ＵＡＶのためのサブグループｇＮＡＣＫ ＰＵＣＣＨリソース割当てＹ_kは、ＲＲＣ再構成を使用して行われ得る。

グループメンバは、｜｛∩_iＢ_i｝｜≒｛∪_iＢ_i｝｜を満たし得る相関するパケット紛失レジームで動作し得る。グループメンバは、｜｛∩_iＢ_i｝｜≪｛∪_iＢ_i｝｜を満たし得る独立したパケット紛失レジームで動作し得る。ある時間期間（たとえば、いくつかのサブフレーム／フレーム）にわたって使用されるエネルギー感知手法に応じて、ｅＮＢは、ＤＣＩまたは上位レイヤシグナリングを通してグループのメンバが従う必要があり得るパケット紛失回復のモードをシグナリングし得る。

上記で説明されたように、優先度は、損失率に基づいてチャネルにアクセスするためにユーザに割り当てられ得る。より高い優先度が、より少ないパケット紛失をもつメンバに割り当てられ得る。代替的に、より高い優先度は、一定量の送信機会を仮定すれば、グループメンバの間でパケット紛失伝播情報を最大化するために高いパケット紛失をもつメンバに割り当てられ得る。より少ないパケット紛失を有するユーザによって経験されるパケット紛失のセットは、より多い紛失を有するユーザによって経験されるパケット紛失のサブセットであり得る。グループメンバが紛失したパケット情報の差を報告することは最適であり得る。このシナリオのためのアクセスクラス決定のための一例を表５に与え、これは、ユーザのアクセスクラスへの例示的なカテゴリー分類と、固定された送信機会をもつパケット紛失伝播のための各アクセスクラスのためのコンテンションウインドウの最小値および最大値とを示す。

図４は、ｇＮＡＣＫ決定プロセスを示すフローチャートである。ステップ４０２において、ＵＡＶは、構成されたタイムウインドウ中のＵＡＶとｅＮＢとの間のＵｕインターフェースのためのパケット紛失を決定し得る。ステップ４０４において、ＵＡＶは、それの決定されたＵｕパケット紛失に基づいて最初のサイドリンクアクセスクラスを決定し得る。ステップ４０６において、ＵＡＶは、サイドリンク通信を介してそれのグループの他のメンバからＵｕパケット紛失情報を受信し得る。ステップ４０８において、ＵＡＶは、グループ内のＵｕパケットの差動ＮＡＣＫ／ＡＣＫを決定し得、サイドリンク通信のためのそれのアクセスクラスを更新し得る。ステップ４１０において、ＵＡＶは、ｇＮＡＣＫが完全であるかどうかを決定し得る。ｇＮＡＣＫが完全でない場合、プロセスはステップ４０６に戻り得る。ｇＮＡＣＫが完全である場合、プロセスはステップ４１２に進み得る。ステップ４１２において、ＵＡＶは、Ｕｕインターフェースを介してｅＮＢに単一のｇＮＡＣＫを送信し得る。ｇＮＡＣＫは、グループ内のＵｕパケットの差動ＮＡＣＫ／ＡＣＫに基づいてグループにわたって協調ＮＡＣＫを反映し得る。

グループパケット修復では、グループの各メンバは、すべての他のメンバのパケット紛失と、各メンバが他のメンバをどのように支援することができ、したがって、すべてのメンバがそれらの紛失したパケットを一致させることができることとを知り得る。

このプロシージャは、グループメンバごとにあらゆるパケットの紛失／受信されたパケット情報を必要とし得る。しかしながら、ｇＮＡＣＫプロトコルは、各メンバが最大の報告されてない差分情報を与えるように設計されるので、メンバごとにあらゆるパケットに関する情報を与えることができないことがある。各メンバは、送信されるＮｎビットの最大オーバーヘッドを招くあらゆるパケットに関する情報を与え得、ここで、Ｎは、グループメンバの数であり得、ｎは、紛失／受信された情報が報告されるべきであるパケットの数であり得る。

グループパケット修復では、すべてのグループメンバが可能な最低量の送信時間中にそれらの紛失したパケットを取得するやり方を最適化することが望ましいことがある。さらに、固定された送信機会を仮定すれば、グループ全体のために修復され得るパケットの量を最大化することが望ましいことがある。

図５Ａ～図５Ｄは、グループパケット修復の例を示す。グループメンバは、他のメンバによって経験されるパケット紛失と助けようとしているメンバにおける紛失したパケットの利用可能性とに基づいて他のメンバを助けることが可能であり得る。図５Ａは、同じパケットが多くのメンバによって要求される単純なブロードキャストを示す。図５Ｂは、２パケットネットワークコーディングのための紛失パターンを示す。図５Ｃは、３パケットネットワークコーディングのための紛失パターンを示す。図５Ｄは、４パケットネットワークコーディングのための紛失パターンを示す。

グループメンバは、何個のグループメンバが１つの送信機会中に同時にサーブされ得るのかを決定し得る。これは、他のメンバによって経験されるパケット紛失と助けようとしているグループメンバでの紛失したパケットの利用可能性とに依存し得る。図５Ａでは、同じパケット（パケット＃２）が、メンバＵ₁，．．．Ｕ_nによって紛失され得、このパケットは、別のメンバＵ₀で利用可能であり得る。したがって、１つの送信が、このパケット紛失をもつすべてのユーザ、Ｎ人のユーザを修復するのに十分であり得る。

図５Ｂでは、Ｕ₁は、パケット１を受信し得、パケット２を紛失し得るが、Ｕ₂では逆シナリオが存在する。パケット１とパケット２との両方を受信した別のメンバＵ₀は、これらのパケットの排他的論理和ＸＯＲをブロードキャストし得る。したがって、単一の送信を用いてメンバＵ₁とＵ₂との両方のパケット紛失を同時に修復することが可能であり得る。

図５Ｃでは、Ｕ₁は、パケット１を紛失し得るが、他の２つを受信し得、Ｕ₂は、パケット２を紛失し得るが、他の２つを受信し得、Ｕ₃は、パケット３を紛失し得るが、他の２つを受信し得、Ｕ₀は、すべてのパケットを受信し得る。単一の送信を用いて３つのメンバＵ₁とＵ₂とＵ₃とのパケット紛失を同時に修復することが可能であり得る。

図５Ｄでは、４つのメンバが１つの送信中でサーブされ得る。グループメンバの紛失したパケットパターンを慎重に考慮することによって、１つの送信機会中で複数のメンバを同時にサーブすることが可能であり得る。変数ｌは、グループメンバによって同時にサーブされ得るユーザの数であり得、Ｎは、グループメンバの総数であり得る。パケット修復段階のためのグループメンバのアクセスクラス決定のための一例を表６に示す。

ネットワークコーディングされたパケットをシグナリングするために、ＭＡＣヘッダは、ネットワークコーディングされたパケットを形成するために使用されたパケットのシーケンス番号（たとえば、媒体アクセス制御プロトコルデータユニット（ＭＰＤＵ）シーケンス番号）を示し得る。グループメンバがサイドリンク中でネットワークコードを使用し得るので、サイドリンクのためのＭＡＣパケットヘッダは、現在のＭＰＤＵのためのシーケンス番号を表すための既存のビット割振りに加えてネットワークコードを形成するために使用されていることがあるＭＰＤＵのためのシーケンス番号を表すために割り振られたビットを有し得る。ネットワークコーディングを可能にするのに必要なＭＡＣパケットヘッダ更新は、サイドリンク通信のためにのみ実行され得る。

グループメンバは、ランダムに送信し得る。各グループメンバは、各反復中でパケットの特定のセットを送信するように割り当てられ得る。パケットの割り当てられたセットは、メンバによって正しく受信されていないことがある。この場合、他のメンバは、結局異なる反復中でこのパケットを送信することになり得る。

一例では、｛０，１，．．Ｎ－１｝と番号付けされたＮ個のメンバと、｛０，１，．．Ｍ－１｝と番号付けされたＭ個のパケットとがあり得る。ｋが以下を満たす場合、ユーザｊはパケットｋを送信し得る。

Δ＝０，１，．．Ｎ－１ 式９

変数Δは、反復を表し得、ｍは、送信されるパケットの数を表し得る。

一例では、Ｍ＝１２であり、Ｎ＝４であり、ｍ＝０，１，２である。表７に示されるように各反復中のユーザによって送信されるパケットは、上式を使用することによって取得され得る。表７は、サイクル中に各ユーザによって送信されるパケットを示す。各パケットは、サイクルごとにユーザによって一意に送信され得る。各ユーザは、すべてのサイクルにわたってすべてのパケットを送信し得る。

各反復中で、パケットは、ユーザによって一意に送信され得る。たとえば、反復Δ＝０中で、ユーザ０は、それぞれｍ＝０，１，２に対応するパケット０、４、８を送信し得る。すべての反復にわたって、各メンバは、すべてのパケットを送信し得る。パケットが反復Δ＝３後に少なくとも１つのメンバによって受信される場合、各メンバは、それの紛失したパケットを回復していることがある。

メンバは、それが反復中で送信すると考えられるパケットを紛失した場合、それは、異なる反復中で別のメンバによって最終的に送信され得る。たとえば、ユーザ０がパケット４を紛失した場合、それはΔ＝０中にそれを送信することが可能でないことになる。しかしながら、パケット４は、Δ＝１中にユーザ３によって送信され得る。各メンバは、パケット送信のために公平なローディングを割り当てられ得る。上記の例では、各メンバは、あらゆる反復中で３つのパケットを送信する要件を有し得る。代替的に、メンバは、あらゆる反復中で同じでないパケットを送信し得る。メンバがあらゆる反復中で同じでないパケットを送信する場合でも、各メンバは、依然として、あらゆる反復にわたって等しい数のパケットを送信し得る。たとえば、Δ＝１中で、ユーザ１およびユーザ２は、それぞれ、２つおよび６つのパケットを送信し得るが、それらは、Δ＝２中で６つおよび２つのパケットを送信し得る。この方式が各反復にわたってユーザに不当であり得るが、それはすべての反復にわたって公平であり得る。

各メンバは、それの紛失したパケットを修復すると、グループにシグナリングし得、したがって、反復は、グループのすべてのメンバからこのメッセージを受信した後に停止され得る。ネットワークは、パケット修復プロセスを開始するために開始時間、たとえば、システムフレーム番号－サブフレーム番号（ＳＦＮ－ＳＦ）の組合せを構成し得る。ユーザがそれのパケットを送信すべき時間は、表７に示されるようにユーザＩＤに基づいて事前構成され得る。たとえば、ネットワークは、偶数または奇数のフレーム番号ごとにパケット修復プロセスを開始するように構成され得る。この絶対時間から、各ユーザＩＤは、送信のためのそれの機会を計算し得る。

優先度ベースの確率論的方式は、最小送信機会でパケット紛失を修復しようと試み得るので、その方式を使用したパケット修復モードは、サイドリンクリソースに制約があるときに効率的であり得る。十分なサイドリンクリソース／帯域幅があるときおよび／またはパケット紛失が多いとき、ランダムパケット紛失方式を使用したパケット修復モードが有用になり得る。

本明細書の説明が３ＧＰＰ固有のプロトコルについて考慮するが、実施形態は、このシナリオに制限されず、他のワイヤレスシステムに適用可能であることを理解されたい。さらに、本明細書で説明される例がドローンと航空機とを含むが、実施形態は、すべてのワイヤレス端末に適用されることを理解されたい。

図６は、グループパケット修復を示すフローチャートである。ステップ６０２において、ＵＡＶは、それが他のものによって要求されているＵｕインターフェースを介して受信されたパケットを有するのかどうかを決定し得る。有しない場合、ステップ６０４において、ＵＡＶは、他のものが送信するのを待ち得る。有する場合、ステップ６０６において、ＵＡＶは、パケットを要求するグループメンバの数に基づいて修復のためのサイドリンクアクセスクラスを決定し得る。ステップ６０８において、ＵＡＶは、サイドリンク通信を使用して他のグループメンバにパケットを送信し得る。

図７は、ＵＴＭシステムにおいて使用され得る例示的なＵＡＶ７００を示す。ＵＡＶ７００は、パイロットなしで飛行する能力を有する任意のタイプの従来の航空機であり得る、ＵＡＶ７００は、固定翼ドローン、複数ロータドローン、単一ロータドローン、インフレータブルドローンまたはハイブリッドドローンであり得る。ＵＡＶ７００は、４プロペラドローンとして示されているが、展開の予期されたエリア内を飛ぶことができる任意のドローン構成が使用され得る。ＵＡＶ７００は、本明細書で説明されるタスクを実行するために機械語命令を実行するように構成される電子処理回路を有し得る。ＵＡＶ７００は、たとえば、公開されている利用可能な周波数を使用して、例はＷｉＦｉ、ＷｉＭＡＸ、ＢＬＵＥＴＯＯＴＨ、ＳＩＧＦＯＸ、３Ｇ、４Ｇ、ＬＴＥ、または別のプロトコルを含む、たとえば、短距離または長距離ワイヤレス通信プロトコルを使用して、フライト中にワイヤレスにＵＴＭおよび／または他のＵＡＶと通信し得る。

ＵＡＶ７００は、様々な量の処理能力を有し得るが、飛行するのに少なくとも十分な処理容量を含み、推進の手段、たとえば、モータ７０４によって駆動される１つまたは複数のプロペラ７０２、電源１３４、１つまたは複数のカメラ７０６、制御回路７１０などのＵＡＶに通常に関連する構成要素をさらに含む。ＵＡＶ７００は、完全自律型として実装され得るが、制御回路７１０は、フライト関連のセンサ、電子回路およびソフトウェアならびに遠隔または半自律制御のためのワイヤレス双方向通信を含む通信電子回路を含み得る。
制御回路７１０は、それが遠隔操縦されるか、半自律であるか、または完全自律型であるかにかかわらず、意図されたミッションに従ってフライトを実行するのに必要な電子回路を含み得る。制御回路７１０中の電子回路は、図１Ｂに関して上記で説明されたＷＴＲＵ１０２の電子回路と同様であり得る。電子回路は、１つまたは複数のプロセッサ１１８、１つまたは複数のトランシーバ１２０、１つまたは複数のアンテナ１２２、ＧＰＳチップセット１３６などを含み得る。

ＵＡＶは、構成されたタイムウインドウ中のＵｕインターフェース中のパケット紛失を決定し得る。ＵＡＶは、サイドリンクにアクセスするためのアクセスクラスを決定し得、決定されたアクセスクラスに基づいてランダムバックオフを実行し得る。ＧＲＮＴＩをもつグループの任意のメンバは、グループによって経験される共通のパケット紛失のためのｇＮＡＣＫを生成し得るか、またはｅＮＢは、ｇＮＡＣＫを送信するようにグループのメンバを構成し得る。

グループ中のＵＡＶは、サブグループＰＵＣＣＨ ｇＮＡＣＫリソースを含むＧＲＮＴＩ固有の構成を受信し得る。復号が失敗する場合、ＵＡＶは、割り当てられたサブグループＰＵＣＣＨ ｇＮＡＣＫリソース中でＮＡＣＫを送信し得る。ＮＡＣＫが、すべてのサブグループＰＵＣＣＨ ｇＮＡＣＫリソース中で復号される場合、ｅＮＢは、パケットを再送信し得る。

ｅＮＢは、Ｔ個のサブフレームについて連続的にすべてのサブグループＰＵＣＣＨ ｇＮＡＣＫリソース中でのＮＡＣＫの存在／不在を復号し得る。ＵＡＶは、ｅＮＢからブロックベースのｇＮＡＣＫと瞬時ｇＮＡＣＫとの間にモード変更のためのシグナリングを受信し得る。ＵＡＶは、ブロックベースのｇＮＡＣＫフィードバックを送信するための構成情報（たとえば、開始サブフレーム番号、長さ、サブフレームごとのビット数）をさらに受信し得る。

ＵＡＶは、構成されたタイムウインドウ中にグループの他のメンバによって紛失／受信されたパケットを決定し得る。ＵＡＶは、現在の送信機会中に同時に修復され得るユーザの数に基づいてサイドリンクにアクセスするためのアクセスクラスを決定し得る。ＵＡＶは、決定されたアクセスクラスに基づいてランダムバックオフを実行し得る。

ｅＮＢは、Ｕｕグループパケット紛失および／またはサイドリンク帯域幅制約を決定し得る。グループ中のＵＡＶは、Ｕｕグループパケット紛失に基づいてサイドリンクパケット修復モード（たとえば、ランダムパケット送信修復モードおよび／またはネットワークコーディング）のための構成を受信し得る。

グループメンバは、上記で説明されたアクセスクラスベースの方式を実装するためにＭＡＣパケットがネットワークコーディングのために適用できる等しいサイズになる要求をｅＮＢにシグナリングし得る。代替的に、上記で説明されたエネルギーしきい値方式に基づいて、ｅＮＢは、それのＵｕブロードキャストパケットを送信するときにＭＡＣパケットが等しいサイズになる必要があるのかどうかを決定し得る。

特徴および要素について、特定の組合せで上記で説明したが、各特徴または要素が単独でまたは他の特徴および要素との任意の組合せで使用され得ることを、当業者は諒解されよう。さらに、本明細書で説明する方法は、コンピュータまたはプロセッサが実行するためのコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。コンピュータ可読媒体の例は、（ワイヤードまたはワイヤレス接続を介して送信される）電子信号およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、限定はしないが、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気メディア、光磁気メディア、ならびにＣＤ－ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光メディアを含む。ソフトウェアに関連するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用され得る。

Claims (22)

1. ワイヤレス送信／受信ユニット（ＷＴＲＵ）において使用する方法であって、
   第１のインターフェースを介してネットワークからダウンリンク通信を受信することであって、前記ダウンリンク通信はＷＴＲＵのグループ中の１つまたは複数のＷＴＲＵに送信されている、ことと、
   ダウンリンク通信のパケットロス割合に基づいて前記ＷＴＲＵのアクセスクラスを決定することであって、前記アクセスクラスは第２のインターフェースにアクセスするためのコンテンションウインドウに関連付けられている、ことと、
   前記コンテンションウインドウ中で前記第２のインターフェースを介して前記１つまたは複数のＷＴＲＵにパケットロス情報を送信することと、
   前記第２のインターフェースを介して前記１つまたは複数のＷＴＲＵからパケットロスフィードバックを受信することと、
   前記ＷＴＲＵの前記アクセスクラスが前記１つまたは複数のＷＴＲＵのうちで最も高いクラスであると決定することと、
   前記第１のインターフェースを介して前記１つまたは複数のＷＴＲＵの代わりに前記ネットワークに単一のグループキャスト否定応答（ｇＮＡＣＫ）を送信することであって、前記ｇＮＡＣＫは前記パケットロスフィードバックに基づいている、ことと、
   を含む、方法。
2. 前記パケットロス情報は前記コンテンションウインドウ中でランダムバックオフ手順を使用して送信される、請求項１に記載の方法。
3. 前記アクセスクラスはパケットロス割合値の予め定められた範囲に対応する、請求項１に記載の方法。
4. 前記１つまたは複数のＷＴＲＵは前記パケットロス割合値の前記予め定められた範囲と関連付けられる、請求項３に記載の方法。
5. 低パケットロス割合は早いコンテンションウインドウ及び優先的チャネルアクセスを有するアクセスクラスに対応する、請求項１に記載の方法。
6. 高パケットロス割合は早いコンテンションウインドウ及び優先的チャネルアクセスを有するアクセスクラスに対応する、請求項１に記載の方法。
7. 前記パケットロスフィードバックは、前記ＷＴＲＵのグループ中の前記１つまたは複数のＷＴＲＵのアクセスクラスに基づいて、１つまたは複数のコンテンションウインドウ中で受信される、請求項１に記載の方法。
8. 前記パケットロスフィードバックは、前記１つまたは複数のＷＴＲＵによって以前に示されていない紛失したパケットの表示を含む、請求項７に記載の方法。
9. 前記第１のインターフェースはＵｕインターフェースである、請求項１に記載の方法。
10. 前記第２のインターフェースはサイドリンクインターフェースである、請求項１に記載の方法。
11. 前記ｇＮＡＣＫは、前記ＷＴＲＵのグループ中のＷＴＲＵの数及びｅＮＢからの事前設定された時間の１つまたは複数に基づく遅延の後に、送信される、請求項１に記載の方法。
12. ワイヤレス送信／受信ユニット（ＷＴＲＵ）であって、
    アンテナと、
    前記アンテナに動作可能に結合されたプロセッサと、
    を備え、
    前記アンテナ及び前記プロセッサは、第１のインターフェースを介してネットワークからダウンリンク通信を受信するように構成されており、前記ダウンリンク通信はＷＴＲＵのグループ中の１つまたは複数のＷＴＲＵに送信されており、
    前記プロセッサは、ダウンリンク通信のパケットロス割合に基づいて前記ＷＴＲＵのアクセスクラスを決定するように構成されており、前記アクセスクラスは第２のインターフェースにアクセスするためのコンテンションウインドウに関連付けられており、
    前記アンテナ及び前記プロセッサは、前記コンテンションウインドウ中で前記第２のインターフェースを介して前記１つまたは複数のＷＴＲＵにパケットロス情報を送信するようにさらに構成されており、
    前記アンテナ及び前記プロセッサは、前記第２のインターフェースを介して前記１つまたは複数のＷＴＲＵからパケットロスフィードバックを受信するようにさらに構成されており、
    前記プロセッサは、前記ＷＴＲＵの前記アクセスクラスが前記１つまたは複数のＷＴＲＵのうちで最も高いクラスであると決定するようにさらに構成されており、
    前記アンテナ及び前記プロセッサは、前記第１のインターフェースを介して前記１つまたは複数のＷＴＲＵの代わりに前記ネットワークに単一のグループキャスト否定応答（ｇＮＡＣＫ）を送信するようにさらに構成されており、前記ｇＮＡＣＫは前記パケットロスフィードバックに基づいている、
    ＷＴＲＵ。
13. 前記パケットロス情報は前記コンテンションウインドウ中でランダムバックオフ手順を使用して送信される、請求項１２に記載のＷＴＲＵ。
14. 前記アクセスクラスはパケットロス割合値の予め定められた範囲に対応する、請求項１２に記載のＷＴＲＵ。
15. 前記１つまたは複数のＷＴＲＵは前記パケットロス割合値の前記予め定められた範囲と関連付けられる、請求項１４に記載のＷＴＲＵ。
16. 低パケットロス割合は早いコンテンションウインドウ及び優先的チャネルアクセスを有するアクセスクラスに対応する、請求項１２に記載のＷＴＲＵ。
17. 高パケットロス割合は早いコンテンションウインドウ及び優先的チャネルアクセスを有するアクセスクラスに対応する、請求項１２に記載のＷＴＲＵ。
18. 前記パケットロスフィードバックは、前記ＷＴＲＵのグループ中の前記１つまたは複数のＷＴＲＵのアクセスクラスに基づいて、１つまたは複数のコンテンションウインドウ中で受信される、請求項１２に記載のＷＴＲＵ。
19. 前記パケットロスフィードバックは、前記１つまたは複数のＷＴＲＵによって以前に示されていない紛失したパケットの表示を含む、請求項１８に記載のＷＴＲＵ。
20. 前記第１のインターフェースはＵｕインターフェースである、請求項１２に記載のＷＴＲＵ。
21. 前記第２のインターフェースはサイドリンクインターフェースである、請求項１２に記載のＷＴＲＵ。
22. 前記ｇＮＡＣＫは、前記ＷＴＲＵのグループ中のＷＴＲＵの数及びｅＮＢからの事前設定された時間の１つまたは複数に基づく遅延の後に、送信される、請求項１２に記載のＷＴＲＵ。

Images