特許 7443345 通信技法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-26

(45)【発行日】2024-03-05

(54)【発明の名称】通信技法

(51)【国際特許分類】

   H04B 10/116 20130101AFI20240227BHJP

   H04W 74/08 20240101ALI20240227BHJP

   H04W 72/04 20230101ALI20240227BHJP

【ＦＩ】

H04B10/116

H04W74/08

H04W72/04

【請求項の数】 22

(21)【出願番号】P 2021513282

(86)(22)【出願日】2019-09-10

(65)【公表番号】

(43)【公表日】2022-01-04

(86)【国際出願番号】 EP2019074147

(87)【国際公開番号】W WO2020053235

(87)【国際公開日】2020-03-19

【審査請求日】2022-09-12

(31)【優先権主張番号】18193567.7

(32)【優先日】2018-09-10

(33)【優先権主張国・地域又は機関】EP

(31)【優先権主張番号】18206353.7

(32)【優先日】2018-11-14

(33)【優先権主張国・地域又は機関】EP

(31)【優先権主張番号】19162055.8

(32)【優先日】2019-03-11

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】500242786

【氏名又は名称】フラウンホファー ゲセルシャフト ツール フェールデルンク ダー アンゲヴァンテン フォルシュンク エー．ファオ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】フォルカー・ユングニッケル

(72)【発明者】

【氏名】カイ・レナート・ボーバー

【審査官】前田 典之

(56)【参考文献】

【文献】特表２０１６－５１１９９７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／０３４９８８７（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０４９８１９９１（ＣＮ，Ａ）

【文献】国際公開第２０１８／０７８３２３（ＷＯ，Ａ１）

【文献】米国特許出願公開第２００７／００５８６６５（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００８／０１７１５５０（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ １０／１１６

Ｈ０４Ｗ ７４／０８

Ｈ０４Ｗ ７２／０４４６

(57)【特許請求の範囲】

【請求項1】

第2の通信装置(15)との通信のための第1の通信装置(16)であって、前記第1の通信装置(16)が、
前記第2の通信装置(15)の1つまたは複数のフロントエンド(14a…14g)からの1つまたは複数の基準信号および/またはビーコン信号(11)の受信からチャネル状態情報を取得し、
時間領域チャネル状態情報を取得するために、周波数領域から時間領域に前記チャネル状態情報を変換し、
前記時間領域チャネル状態情報を符号化し、
前記時間領域チャネル状態情報を、前記第2の通信装置(15)の1つまたは複数のフロントエンド(14a…14g)に送信する、
ように構成され、
前記第1の通信装置(16)が、コンテンションアクセス期間(CAP)(11a)においてアソシエーションのためのチャネル状態情報を送信し、コリジョンフリー期間(CFP)(11b)において更新されたチャネル状態情報(32b)を送信する、
ように構成される、第1の通信装置(16)。

【請求項2】

1つまたは複数のフロントエンド(14a…14g)から1つまたは複数の基準信号またはビーコン信号(11)を受信するように構成され、
前記第1の通信装置(16)が、前記1つまたは複数の基準信号またはビーコン信号(11)の前記受信に基づいてチャネル状態情報を決定する(31)、
ように構成される、請求項1に記載の第1の通信装置(16)。

【請求項3】

前記第1の通信装置(16)が、前記1つまたは複数の基準信号またはビーコン信号(11)を送信した第2の通信装置(15)とのアソシエーションの際、コンテンションアクセス期間(CAP)(11a)において前記チャネル状態情報(32)を送信するように構成される、請求項1または2に記載の第1の通信装置(16)。

【請求項4】

前記チャネル状態情報(32、32b)が測定された信号対雑音比(SNR)に結び付けられる、請求項1から3のいずれか一項に記載の第1の通信装置(16)。

【請求項5】

複数のフロントエンド(14a…14g)から複数の基準信号(11)を受信し、
前記受信された基準信号の評価に基づいて、前記チャネル状態情報を取得し(31)、
符号化されたチャネル状態情報を提供するために、前記チャネル状態情報を符号化し、
複数の考えられる符号化分解能の中からの、前記チャネル状態情報を符号化するために使用される符号化分解能の選択(902)を記述する情報(450、450b)を提供する
ように構成される、請求項1から4のいずれか一項に記載の第1の通信装置(16)。

【請求項6】

前記取得されたチャネル状態情報値に基づいて分解能を発見するように構成される、請求項1から5のいずれか一項に記載の第1の通信装置(16)。

【請求項7】

前記符号化分解能の前記選択を記述する前記情報が、
タップフォーマット、
タップ強度のステップサイズ(933)、
遅延(943)のステップサイズ(933)、
前記受信された基準信号(11)の前記強度(461、461b)、またはそれに関連付けられる値、
前記受信された基準信号(11)の前記遅延(462、462b)、またはそれに関連付けられる値、
前記基準信号(11)の指示(921)、
のうちの少なくとも1つを定義する、請求項5に記載の第1の通信装置(16)。

【請求項8】

光通信を通じて前記第2の通信装置(15)と通信するように構成される、請求項1から7のいずれか一項に記載の、第1の通信装置(16)。

【請求項9】

フロントエンド(14a-14g)に接続される第2の通信装置(15)であって、
前記第2の通信装置(15)が、1つまたは複数のフロントエンド(14a…14g)から1つまたは複数の基準信号またはビーコン信号(11)を送信するように構成され、
前記第2の通信装置(15)が、コンテンションアクセス期間(CAP)(11a)においてアソシエーションのためのチャネル状態情報を受信し、コリジョンフリー期間(CFP)(11b)において更新されたチャネル状態情報(32b)を受信するように構成される、第2の通信装置(15)。

【請求項10】

前記フロントエンドが光フロントエンドである、請求項9に記載の第2の通信装置(15)。

【請求項11】

複数のフロントエンド(14a…14g)の間で初期の粗い同期を実行し、
前記複数のフロントエンド(14a…14g)への基準信号および/またはビーコン信号(11)の送信を命令し、
第1の通信装置(16)によって測定されるチャネル状態情報(32、32b、35)を取得し、
続いて、前記フロントエンド(14a…14g)を同期することによって、前記チャネル状態情報(32)に基づいて第2の精密な同期を実行する
ように構成される、請求項9または10に記載の第2の通信装置(15)。

【請求項12】

より遅延の大きい前記フロントエンド(14a…14g)の前記送信に備えることによって、および/またはより遅延の小さい前記フロントエンド(14a…14g)の前記遅延を増やすことによって、前記フロントエンド(14a…14g)を精密に同期するようにさらに構成され、
前記第2の通信装置(15)が、観測される遅延に比例して、前記フロントエンド(14a…14g)からの前記送信に備え、および/または前記送信を遅らせることによって、前記フロントエンド(14a…14g)を同期するようにさらに構成される、請求項11に記載の第2の通信装置(15)。

【請求項13】

前記初期の粗い同期がインターネットベースのプロトコルを使用することによって、または中央ユニット(12)のクロックを同期することによって得られる、請求項12に記載の第2の通信装置(15)。

【請求項14】

前記1つまたは複数の基準信号またはビーコン信号(11)が、前記第1の通信装置(16)に特徴的であり、前記1つまたは複数の基準信号またはビーコン信号(11)を受信し前記チャネル状態情報(32、32b)を送信した、第2の通信装置(15)によって知られているパイロット信号を含む、請求項11から13のいずれか一項に記載の第2の通信装置(15)。

【請求項15】

前記フロントエンド(14a…14g)が、異なる直交シーケンスに従って前記基準信号またはビーコン信号(11)を使用するように構成される、請求項14に記載の第2の通信装置(15)。

【請求項16】

複数の考えられる符号化分解能の中からの、チャネル状態情報(32、32b、35、450、450b)を符号化するために使用される符号化分解能の選択を記述する情報(902)を受信し、
前記チャネル状態情報を符号化するために使用される符号化分解能の選択を記述する前記情報(902)に応じて、前記符号化されたチャネル状態情報(32、32b、35、450、450b)を復号する、
ように構成される、請求項9から15のいずれか一項に記載の第2の通信装置(15)。

【請求項17】

複数のフロントエンドを含み、それらを基準信号に送信するように構成された、請求項9から16のいずれか一項に記載の第2の通信装置(15)。

【請求項18】

前記符号化分解能の前記選択を記述する前記情報において示されるタップフォーマットに従って、前記チャネル状態情報から複数の伝播経路の強度および/または遅延を復号するように構成される、請求項16に記載の第2の通信装置(15)。

【請求項19】

サブキャリアがインデクシングされ、前記サブキャリアの各グループがそれらのインデックスによって識別される、請求項16に記載の第2の通信装置(15)。

【請求項20】

通信が光通信である、請求項9から19のいずれか一項に記載の第2の通信装置(15)。

【請求項21】

第1の通信装置(16)と第2の通信装置(15)との間で通信するための方法であって、
前記第2の通信装置(15)から、1つまたは複数のフロントエンド(14a…14g)からの1つまたは複数の基準信号またはビーコン信号(11)を送信し、
前記第1の通信装置(16)において、1つまたは複数のフロントエンド(14a…14g)からの1つまたは複数の基準信号またはビーコン信号(11)を受信し、
前記第1の通信装置(16)において、1つまたは複数の基準信号またはビーコン信号(11)の受信に基づいてチャネル状態情報を決定し、
前記第1の通信装置(16)から、チャネル状態情報(32、32b)を送信し、
前記第2の通信装置(15)において、コンテンションアクセス期間(CAP)(11a)においてアソシエーションのためのチャネル状態情報を受信し、コリジョンフリー期間(CFP)(11b)において更新された、ネットワーク協調のためのチャネル状態情報(32b)を受信する、
ことを含む、方法。

【請求項22】

前記第2の通信装置(15)において、
複数のフロントエンド(14a…14g)の間で初期の粗い同期を実行し、
前記複数のフロントエンド(14a…14g)への基準信号および/またはビーコン信号(11)の送信を命令し、
前記基準信号および/またはビーコン信号(11)に基づいて、第1の通信装置(16)によって測定されるチャネル状態情報(32、32b、35)を取得し、
前記チャネル状態情報(32)に基づいて前記フロントエンド(14a…14g)を同期する、
ことをさらに含む、請求項21に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

以下では、少なくとも1つの第1の装置と少なくとも1つの第2の装置との間の通信のための技法が開示される。たとえば、第2の装置は(たとえば、ワイヤレスフロントエンド、たとえば光フロントエンドを伴う)設備であってもよく、少なくとも1つの第1の装置は1つまたは複数のデバイス(たとえば、ワイヤレスデバイス、たとえば光デバイス)であってもよい。いくつかの例では、設備(または第2の装置)は(少なくとも、1つのフロントエンドにおいて)固定され、1つまたは複数の第1のデバイスは移動式であってもよい。ビットローディングのための技法も論じられる。媒体アクセス(MAC)のための技法も論じられる。多入力/多出力(MIMO)技法がここで論じられる。

【背景技術】

【0002】

たとえば、設備(たとえば固定されたリレーまたはフロントエンドを伴う)と1つまたは複数のデバイス(たとえば、モバイルデバイス)との間の、ワイヤレス通信(たとえば、可視光通信(VLC)および他の通信、たとえば高周波(RF)通信、超音波通信など)が知られている。

【先行技術文献】

【非特許文献】

【0003】

【文献】L. Cosart、「Precision Packet Delay Measurements Using IEEE 1588v2」、2007 IEEE Int. Symp. on Precision Clock Synchronization for Measurement、Control and Communication、ウィーン、2007年、pp.85-91

【文献】R. L. Scheiterer、C. Na、D. Obradovic、G. Steindl、F.-J. Goetz、「Synchronization Performance of the Precision Time Protocol in the Face of Slave Clock Frequency Drift」、4th IEEE Conference on Automation Science and Engineering、Key Bridge Marriott、米国ワシントンDC、2008年8月23日～26日

【発明の概要】

【発明が解決しようとする課題】

【0004】

信頼性が低いと、たとえば、通信チャネルの変更および/またはデバイスの移動によって、これらの通信が損なわれることがある。したがって、信頼性を高めるための技法が一般に求められている。

【0005】

場合によっては、ビットローディングを定義するのが難しいことがある。たとえば、各フロントエンド(たとえば、リレー)と各デバイス(たとえば、モバイルデバイス)が送信する周波数(たとえば、サブキャリア)を定義するのが難しいことがある。したがって、通信を増強するための技法が一般に求められている。

【課題を解決するための手段】

【0006】

本発明の定義は、独立請求項において見出される。

【0007】

例によれば、1つまたは複数のフロントエンド(たとえば、光フロントエンド)から1つまたは複数の基準信号および/またはビーコン信号を受信するように構成される、第1の通信装置が開示され、
第1の通信装置は、1つまたは複数の基準信号および/またはビーコン信号の受信に基づいてチャネル情報を決定するように構成され、
第1の通信装置は、コンテンションアクセス期間(CAP)においてチャネル情報を送信するように構成される。

【0008】

例によれば、通信方法が開示され、この通信方法は、
第1の通信装置において、1つまたは複数のフロントエンド(たとえば、光フロントエンド)から1つまたは複数の基準信号および/またはビーコン信号を受信するステップと、
第1の通信装置において、1つまたは複数の基準信号および/またはビーコン信号の受信に基づいてチャネルを決定するステップと、
第1の通信装置から、コンテンションアクセス期間(CAP)においてチャネル情報を送信するステップとを含む。

【0009】

例によれば、フロントエンドに接続された調整器によって調整される第2の通信装置が開示され、
第2の通信装置は、1つまたは複数のフロントエンド(たとえば、光フロントエンド)から1つまたは複数の基準信号および/またはビーコン信号を送信するように構成され、
第2の通信装置は、コンテンションアクセス期間(CAP)においてチャネル情報を受信するように構成される。

【0010】

例によれば、通信方法が開示され、この通信方法は、
1つまたは複数のフロントエンド(たとえば、光フロントエンド)から1つまたは複数の基準信号および/またはビーコン信号を送信するステップと、
コンテンションアクセス期間(CAP)においてチャネル情報を受信するステップとを備える。

【0011】

例によれば、中央ユニットが開示され、中央ユニットは、
複数のフロントエンドの間で初期の粗い同期を実行し、
複数の分散したフロントエンドへの基準信号および/またはビーコン信号の送信を命令し、
第1の通信装置によって測定されるチャネル情報を取得し、
続いて、フロントエンドを同期することによって、チャネル情報に基づいて第2の精密な同期を実行する
ように構成される。

【0012】

例によれば、複数のフロントエンドを通じて送信および/または受信するための第2の通信装置が開示され、第2の通信装置は、
複数のフロントエンドの間で初期の粗い同期を実行し、
フロントエンドを通じて1つまたは複数の第1の装置に基準信号および/またはビーコン信号を送信し、
第1の通信装置によって測定されるチャネル情報を取得し、
チャネル情報に基づいて、第2の精密な同期を使用してフロントエンドを同期する
ように構成される。

【0013】

例によれば、複数のフロントエンドを通じて送信および/または受信するための第2の通信装置が開示され、第2の通信装置は、
複数のフロントエンドの間で初期の粗い同期を実行し、
フロントエンドを通じて1つまたは複数の第1の通信装置に基準信号および/またはビーコン信号を送信し、
第1の通信装置によって測定されるチャネル情報を取得し、
チャネル情報に基づいて、第2の精密な同期を使用してフロントエンドを同期する
ように構成される。

【0014】

例によれば、方法が開示され、この方法は、
複数のフロントエンドの間で初期の粗い同期を実行するステップと、
複数のフロントエンド(たとえば、光フロントエンド)への基準信号および/またはビーコン信号の送信を命令するステップと、
基準信号および/またはビーコン信号に基づいて第1の通信装置によって測定されるチャネル情報を取得するステップと、
チャネル情報に基づいて、フロントエンドを同期するステップとを含む。

【0015】

例によれば、複数のフロントエンド(たとえば、光フロントエンド)を通じてデータを送信および/または受信するための通信方法が開示され、この方法は、
複数のフロントエンドの間で初期の粗い同期を実行するステップと、
フロントエンドを通じて1つまたは複数の第1の通信装置に基準信号および/またはビーコン信号を送信するステップと、
第1の通信装置によって測定されるチャネル情報を取得するステップと、
チャネル情報に基づいて、フロントエンドを同期するステップとを含む。

【0016】

例によれば、第2の通信装置との通信のための第1の通信装置が開示され、第1の通信装置は、
1つまたは複数のフロントエンドからの1つまたは複数の基準信号および/またはビーコン信号の受信からチャネル状態情報を取得し、
時間領域チャネル状態情報を取得するために、周波数領域から時間領域にチャネル状態情報を変換し、
時間領域チャネル状態情報を符号化し、
時間領域チャネル状態情報を1つまたは複数のフロントエンドに送信する
ように構成される。

【0017】

例によれば、第1の通信装置との通信のための第2の通信装置が開示され、第2の通信装置は、
各々がCSIの時間領域表現に関連付けられる、第2の値および第1の値の文字列を備え、
文字列の中の各々の第2の値に対して、特定のサンプルにおける時間領域表現の振幅の符号化された値を備え、
文字列の中の各々の第1の値に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSIを受信し、
第2の値に関連付けられるサンプル値に基づいてCSIを再構築する
ように構成される。

【0018】

例によれば、第2の通信装置との第1の通信装置の通信のための通信方法が開示され、この通信方法は、
1つまたは複数のフロントエンドからの1つまたは複数の基準信号および/またはビーコン信号の受信からチャネル状態情報を取得するステップと、
時間領域チャネル状態情報を取得するために、周波数領域から時間領域にチャネル状態情報を変換するステップと、
時間領域チャネル状態情報を符号化するステップと、
時間領域チャネル状態情報を1つまたは複数のフロントエンドに送信するステップとを含む。

【0019】

例によれば、第2の通信装置と第1の通信装置との間の通信のための通信方法が開示され、この通信方法は、
各々がCSIの時間領域表現に関連付けられる、第2の値および第1の値の文字列を備え、
文字列の中の各々の第2の値に対して、特定のサンプルにおける時間領域表現の振幅の符号化された値を備え、
各々の第1の値に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSIを受信するステップと、
第2の値に関連付けられるサンプル値に基づいてCSIを再構築するステップとを備える。

【0020】

例によれば、第1の装置が開示され、第1の装置は、
複数のフロントエンドから複数の基準信号を受信し、
受信された基準信号の評価に基づいてチャネル状態情報(CSI)を取得し、
符号化されたCSIを提供するためにCSIを符号化し、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する情報を提供する
ように構成される。

【0021】

例によれば、[たとえば、送信機、モバイルデバイス、光送信機など、たとえば、上または下の例のいずれかのようなものなどの、第1の通信装置によって実行される]方法が開示され、この方法は、
複数の[たとえば、光]フロントエンド[たとえば、OFE]から複数の基準信号を受信するステップと、
受信された基準信号の評価に基づいてチャネル状態情報(CSI)を取得するステップと、
符号化されたCSIを提供するためにCSIを符号化するステップと、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する[たとえば、信号]情報[たとえば、TAPフォーマット]を提供するステップと
を含む。

【0022】

例によれば、第2の通信装置が開示され、第2の通信装置は、
符号化されたチャネル状態情報(CSI)を受信し、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する情報を受信し、
CSIを符号化するために使用される符号化分解能の選択を記述する情報に応じて、符号化されたCSIを復号する
ように構成される。

【0023】

例によれば、上または下の例のいずれかによるデバイス、および上または下の例のいずれかによるデバイスを備える、システムが開示される。

【0024】

例によれば、[たとえば、受信機、デバイス、光受信機、および/または上もしくは下の例のいずれかによるデバイスなどの、第1の通信装置によって実行される]方法が開示され、この方法は、
符号化されたチャネル状態情報(CSI)を受信するステップと、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する[たとえば、信号]情報[たとえば、TAPフォーマット]を受信するステップと、
CSIを符号化するために使用される符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]に応じて、符号化されたCSIを復号するステップと
を備える。

【0025】

例によれば、第1の通信装置および/または第2の通信装置は、光通信を実行するためのデバイスであってもよい。

【0026】

例によれば、第1の通信装置および/または第2の通信装置は、可視光通信(VLC)を通じて通信を実行するためのデバイスであってもよい。

【0027】

例によれば、第1の通信装置および/または第2の通信装置は、移動可能なデバイスであってもよい。

【0028】

例によれば、第1の通信装置および/または第2の通信装置は、少なくとも部分的には固定されたデバイスであってもよい(たとえば、少なくとも1つのフロントエンドは固定されていてもよい)。

【0029】

例によれば、第1の通信デバイスおよび/または第2の通信装置は、複数の光フロントエンドを含んでもよい。

【0030】

例によれば、第1の通信装置および/または第2の通信装置は、調整器および/または複数のフロントエンドの間にフロントホールを含んでもよい。

【0031】

例によれば、第2の通信装置はスター型トポロジを有してもよい。

【0032】

例によれば、異なるフロントエンドが、調整器から外部の第1の装置へのDL送信を中継し、および/または外部の第1の装置から調整器へのUL送信を中継するように構成され得る。

【0033】

例によれば、異なるフロントエンドが、異なる直交シーケンスを使用して少なくとも1つのDL送信を同時に中継するように構成され得る。

【0034】

例によれば、異なるフロントエンドが、調整器に向かってULの受信された送信を中継するように構成され得る。

【0035】

例によれば、第2の通信装置と通信するための第1の通信装置が開示され、第1の通信装置は、ビット割振りテーブル(BAT)メッセージを送信することになっており、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効であるかをシグナリングする有効性情報、および/または
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報
のうちの少なくとも1つを含み、第1の通信装置は、
確認を予想し、確認が、更新BAT情報によって提供されるような更新されたBATおよび有効性情報によって提供されるような有効なBATのうちの少なくとも1つに従ったビット割振りの使用から導かれ、
第2の通信装置から有効な確認を受信しない場合、BATメッセージを再送信する
ことになっている。

【0036】

例によれば、第2の通信装置と通信するための第1の通信装置が開示され、第1の通信装置は、ビット割振りテーブル(BAT)メッセージを送信することになっており、
BAT更新情報は、更新されるようにシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報を含み、
BAT更新情報の長さは可変である。

【0037】

例によれば、第1の通信装置と通信するための第2の通信装置が開示され、第2の通信装置は、第1の通信装置からビット割振りテーブル(BAT)メッセージを受信するように構成され、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効であるかをシグナリングする有効性情報、
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報
のうちの少なくとも1つを備え、第2の通信装置は、
確認を送信することになっており、確認は、更新BAT情報によって提供されるような更新されたBATおよび有効性情報によって提供されるような有効なBATのうちの少なくとも1つに従ったビット割振りの使用から導かれる。

【0038】

例によれば、第1の通信装置と通信するための第2の通信装置が開示され、第2の通信装置は、ビット割振りテーブル(BAT)メッセージを受信することになっており、
BAT更新情報は、更新されるようにシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報を含み、
BAT更新情報の長さは可変である。

【0039】

例によれば、通信デバイスと通信設備との間の通信のための方法が開示され、この方法は、ビット割振りテーブル(BAT)メッセージを送信するステップを含み、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効であるかをシグナリングする有効性情報、
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報、
更新されるようにシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報
を備える。

【0040】

例によれば、第2の通信装置と第1の通信装置との間の通信のための方法が開示され、この方法は、ビット割振りテーブル(BAT)メッセージを送信するステップを含み、BATメッセージは、
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報、および
複数のBATのうちのどの1つまたは複数のBATが有効であるかをシグナリングする有効性情報
のうちの少なくとも1つを備え、
方法はさらに、
通信設備から通信デバイスに、確認を送信するステップであって、確認が、更新されたBATおよび有効なBATのうちの少なくとも1つに従ったビット割振りの使用から導かれる、ステップと、
通信設備から有効な確認を通信デバイスが受信しない場合、通信デバイスから通信設備にBATメッセージを再送信するステップとを備える。

【0041】

例によれば、第1の通信装置と第2の通信装置との間で通信するための方法が開示され、この方法は、第1の通信装置からビット割振りテーブル(BAT)メッセージを送信するステップを含み、
BAT更新情報は、更新されるようにシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報を含み、
BAT更新情報の長さは可変である。

【0042】

例によれば、プロセッサによって実行されると、上または下の例のいずれかによる方法をプロセッサに実行させる情報を記憶した、非一時的記憶ユニットが開示される。

【0043】

例によれば、上または下の例のいずれかによる通信設備と、上または下の例のいずれかによる通信デバイスとを備える、システムが開示される。

【図面の簡単な説明】

【0044】

【図1】設備およびデバイスの例を示す図である。

【図1a】設備およびデバイスの例を示す図である。

【図2】スケジューリングの例を示す図である。

【図2a】通信の例を示す図である。

【図3】通信の例を示す図である。

【図3a】通信の例を示す図である。

【図3b】通信の例を示す図である。

【図4】装置のユニットの例を示す図である。

【図4a】フレームの例を示す図である。

【図5a】フレームの例を示す図である。

【図5b】フレームの例を示す図である。

【図5c】フレームの例を示す図である。

【図6】調整器の部分的な例を示す図である。

【図7a】フレームの例を示す図である。

【図7b】フレームの例を示す図である。

【図7c】フレームの例を示す図である。

【図7d】フレームの例を示す図である。

【図7e】フレームの例を示す図である。

【図8】フレームの例を示す図である。

【図8a】リストの例を示す図である。

【図8b】フレームの例を示す図である。

【図8c】通信の例を示す図である。

【図8d】通信の例を示す図である。

【図9-1】トポロジの例を示す図である。

【図9-3】トポロジの例を示す図である。

【図9-4】トポロジの例を示す図である。

【図9-5】トポロジの例を示す図である。

【図9-6】アーキテクチャの例を示す図である。

【図9-7】通信の例を示す図である。

【図10-8】プロセスの例およびフレームの例を示す図である。

【図10-9】プロセスの例およびフレームの例を示す図である。

【図10-10】プロセスの例およびフレームの例を示す図である。

【図10-11】プロセスの例およびフレームの例を示す図である。

【図10-12】プロセスの例およびフレームの例を示す図である。

【図10-13】プロセスの例およびフレームの例を示す図である。

【図10-14】プロセスの例およびフレームの例を示す図である。

【図10-16】プロセスの例およびフレームの例を示す図である。

【図10-17】プロセスの例およびフレームの例を示す図である。

【図10-18】プロセスの例およびフレームの例を示す図である。

【図10-19】プロセスの例およびフレームの例を示す図である。

【図11-21】フレームの例を示す図である。

【図11-22】フレームの例を示す図である。

【図11-23】フレームの例を示す図である。

【図11-24】フレームの例を示す図である。

【図11-25】フレームの例を示す図である。

【図11-26】フレームの例を示す図である。

【図11-27】フレームの例を示す図である。

【図11-28】フレームの例を示す図である。

【図11-29】フレームの例を示す図である。

【図11-30】フレームの例を示す図である。

【図11-31】フレームの例を示す図である。

【図11-32】フレームの例を示す図である。

【図11-33】フレームの例を示す図である。

【図11-34】フレームの例を示す図である。

【図11-35】フレームの例を示す図である。

【図11-36】フレームの例を示す図である。

【図11-37】フレームの例を示す図である。

【図11-38】フレームの例を示す図である。

【図11-39】フレームの例を示す図である。

【図11-40】フレームの例を示す図である。

【図11-41】フレームの例を示す図である。

【図11-42】フレームの例を示す図である。

【図11-43】フレームの例を示す図である。

【図11-44】フレームの例を示す図である。

【図11-45】フレームの例を示す図である。

【図11-46】フレームの例を示す図である。

【図11-47】フレームの例を示す図である。

【図11-48】フレームの例を示す図である。

【図11-49】フレームの例を示す図である。

【図11-50】フレームの例を示す図である。

【図11-51】フレームの例を示す図である。

【図11-52】フレームの例を示す図である。

【図11-53】フレームの例を示す図である。

【図11-54】フレームの例を示す図である。

【図11-55】フレームの例を示す図である。

【図11-56】フレームの例を示す図である。

【図11-57】フレームの例を示す図である。

【図11-58】フレームの例を示す図である。

【図11-59】フレームの例を示す図である。

【発明を実施するための形態】

【0045】

以下の例では、同じ種類のデバイスに対する参照符号は、同じ参照番号(たとえば、16、14)を用い、点を使用してそれらを区別する(たとえば、16'、16")ことによって、または異なる文字(14a、14b、14cなど)を使用することによって参照されることが多い。同じ種類のすべてのデバイスに全般に関連付けられる特性に言及するとき、参照番号は、その種類全体に言及するように(たとえば、16、14)、または代替として、複数の参照を使用することによって(たとえば、14a…14g)、使用されることがある。

【0046】

下と上の例は主に、可視光通信(VLC)に基づく通信を主に対象として説明されるが、いくつかの例では、たとえばワイヤレス通信(たとえば、RF、超音波などを使用した)に一般化され得る。

【0047】

下と上の例は、光フロントエンドなどの固定されたフロントエンドを有する設備であり得る第2の装置と、モバイルデバイスであり得る第1の装置との間の通信を主に対象とするものとして説明される。しかしながら、いくつかの特定の事例では、それらは、第1の装置が移動式である(たとえば、少なくとも1つのモバイルフロントエンドを伴う)例、および/または少なくとも1つの固定位置のデバイス(たとえば、複数のフロントエンドを伴う)を伴う例に一般化され得る。いくつかの例では、第1の装置のうちの少なくとも1つは移動式であってもよい。追加または代替として、第1の装置のうちの少なくとも1つは固定されていてもよい。

【0048】

下と上の例は、(たとえば、設備からデバイスへの)ペイロードのダウンリンク(DL)送信のための構成を選ぶことを主に対象として説明される。しかしながら、(たとえば、デバイスから設備への)ペイロードのアップリンク(UL)送信のための構成を定義することも可能である。

【0049】

下と上の例は、たとえば、複数のデバイス(たとえば、モバイルデバイス)が、産業オートメーションまたは同様の用途向けの通信のための設備にデータを送信し、それからデータを受信していてもよいような、ネットワークに関連付けられるものとして主に意図されるものとして説明される。そのネットワークもしくは異なるネットワークの中の他のデバイスへの通信、および/またはそれからの通信が意図され得る。以下のいくつかの例は、多入力/多出力(MIMO)ネットワークに言及する。

【0050】

下と上の例では、ペイロード送信は、たとえば産業環境における、センシング値、アクチュエーション値、フィードバック値などを指し得る。追加または代替として、ペイロード送信は、たとえば音声通信のための、音声データ、ウェブページデータなどを指し得る。以下の例では、主に制御シグナリングに注目し、この用途のためのペイロードデータの使用は、概ね自由なままにされる。

【0051】

下と上の例は、調整器(たとえば、1つの単独の調整器)およびスター型トポロジで調整器に接続された複数のフロントエンド(たとえば、光フロントエンド(OFE))を有する分散した設備によって具現化される第2の装置を主に対象とするものとして説明される。たとえば、調整器がスターの中心であってもよく、複数のフロントエンドが、バックホールを通じて形成されるスター接続を通じてスターの頂点にある。他のトポロジ(たとえば、バストポロジ、ワイヤレストポロジ、ポイントツーポイントトポロジなど)が可能である。

【0052】

下と上の例では、フロントエンドの少なくともいくつかは一般にリレーと見なされ、これらは、設備の調整器から得られたパケットを再送信し、および/または、ワイヤレスに得られた調整器ワイヤレスパケットを調整器に再送信する。いくつかの場合、フロントエンドはそれでもなお、自身の送信を(たとえば、直交シーケンスなどの異なるシーケンスを使用することによって、および/または異なる識別子を使用することによって)わずかに「個人化する」ことがある。したがって、異なるフロントエンドが調整器から取得されるのと同じ信号を同時に中継するときであっても、それらは、少なくともわずかに異なる信号を送信することができ、および/または、それらの送信を区別することができる。

【0053】

図1は、ここでは通信設備15(これは、たとえば基地局(BS)であり得る)である少なくとも1つの第2の通信装置と少なくとも1つの第1の通信装置との間のワイヤレス通信(たとえば、光通信、または可視光通信(VLC))のためのネットワーク10(システム)を示す。ここでは、少なくとも1つの第1の通信装置は、少なくとも1つの通信デバイス(たとえば、ユーザ機器(UE)、リレーエンドポイント(REP)、モバイルデバイス)を含む。

【0054】

第2の装置(通信設備)15は調整器12を含んでもよく、これはコンピュータベースのシステム(たとえば、プロセッサベースのシステム)であってもよい。調整器12は、いくつかの例では、通信設備15の唯一の知的な部分(または1つの知的な部分)であると理解され得る。産業オートメーションの例では、調整器12は、一部の機械に関連付けられる、または複数の機械を調整する(または複数の機械を調整するデバイスに関連付けられる)、固定された機器の一部でもあり得る。

【0055】

第2の装置(通信設備)15は、少なくとも1つのフロントエンドまたは複数のフロントエンド(たとえば、リレーエンドポイント(REP))14a…14gを含み得る。フロントエンド14a…14gは、たとえば光フロントエンド(OFE)であり得る。OFEの場合、各OFEは、フォトトランシーバ、フォトダイオード、送信ダイオード、発光ダイオード(LED)を含み得る。RFの場合、各フロントエンドはRFトランシーバを含み得る。超音波の場合、各フロントエンドは超音波トランシーバを含み得る。

【0056】

例では、複数のフロントエンド14a…14gは、通信設備15の一部であり得る。光フロントエンド14a…14gは、環境の様々な部分において送信および受信するように、チャネル(たとえば、光チャネル)18a…18gを通じて通信を送信/受信するように、(たとえば、既知の位置に)空間的に分散していてもよい。例では、フロントエンド14a…14gは、固定されたおよび/または既知の位置を有し得る。

【0057】

第2の装置15のフロントエンド14a…14gは、フロントホール17を通じて調整器12に接続され得る。フロントホール17は、フロントエンド14a…14gと調整器12との間の送信を可能にするための通信チャネル(たとえば、17a、17b…17g)によって構成され得る(またはそれを少なくとも備え得る)。フロントホール17は、少なくとも1つの通信ネットワークを備え得る。フロントホール17は、スター型トポロジをサポートし得る。フロントホール17は、複数のポイントツーポイント接続を備え得る。フロントホール17は、少なくとも、1つのフロントエンドとの接続のために、(たとえば、金属導体を使用して)有線接続され、または(少なくともいくつかの接続に対して)ケーブル接続され得る(いくつかの例では、フロントエンドとのすべての接続が有線接続および/またはケーブル接続される)。いくつかの例では、(少なくとも、1つのフロントエンドとの接続に対して)フロントホール17はワイヤレスである。いくつかの例では、フロントホール17はイーサネットに基づき得る。

【0058】

図6は調整器12の物理レイヤ12'の例を示すが、調整器12のより高次のレイヤ12"は示されていない。調整器12は、複数の送信ポート12a…12z(送信チェーン)を含み得る。各送信ポート12a…12zは、それぞれのフロントエンドに向かう送信のために通信チャネル17a…17zに接続され得る。送信は、PD-SAPを介してPLCP Service Data Unit(PSDU)ごとに実行され得る。RX構成(図には示されない)は、PLME-SAP(PLME:物理レイヤ管理エンティティ)を通じたものであり得る。

【0059】

フロントエンド14a…14gは、ワイヤレスリンク、たとえば、VLCリンクなどの光リンク18a…18gまたは他のワイヤレスリンクを通じて、通信デバイス16(たとえば、16'、16")との送信を実行し得る。異なるリンクが18によりまとめて示されるが、各フロントエンド14a…14gとそれぞれのモバイルデバイス16'、16"との間の通信は、それぞれのフロントエンドに関連付けられる文字を用いて示される。たとえば、図1において(少なくとも図により示される事例において)、
フロントエンド14a、14b、および14cはたまたま、それぞれ、3つの光接続(チャネル)18a、18b、18cを通じてモバイルデバイス16'と通信している。
光フロントエンド14dは、いずれのモバイルデバイスとも通信していない。
光フロントエンド14e、14f、および14gは、それぞれ、ワイヤレス接続18e、18f、および18gを通じてモバイルデバイス16"と通信している。

【0060】

各フロントエンド14a…14gは、外部デバイスに向かう、および外部デバイスからのデータパケットを中継し得る。たとえば、フロントホール17を通じてフロントエンド14a…14gへ調整器12よって送信される信号は、(たとえば、光学的に、またはより一般的にはワイヤレスに)直ちに再送信され得る。同様に、フロントエンド14a…14gによって(たとえば、光学的に、またはより一般的にはワイヤレスに)受信される信号は、フロントホール17を通じて調整器12に直ちに再送信される。いくつかの場合、異なるフロントエンド14a…14gは、異なるシーケンス(たとえば、直交シーケンス)を使用して、および/または各フロントエンドを識別する識別子を使用して、調整器12から信号を同時に再送信する。たとえば、第1のフロントエンド14aは、第1のシーケンスを使用して調整器12から信号を再送信してもよく、一方で同時に、第2のフロントエンドは、第1のシーケンスに直交する異なるシーケンスを使用して調整器12から同じ信号を再送信してもよい(異なる識別子も使用され得る)。同じことが、重複しないサブキャリアの様々なセットを使用することによって適用され得る。

【0061】

第1の通信装置であり得る少なくとも1つのモバイルデバイス16(たとえば、16'および16")は、フロントエンド14a…14gまたはそれらの少なくとも1つに関して移動式(移動可能)であり得る、ユーザ機器および/または装置として記述され得る。したがって、モバイルデバイス16'、16"と光フロントエンド14a…14gの少なくとも1つとの間の相互の位置は変化することがあるので、これは、リンク18a…18gに対するチャネル条件が変化することを示唆する。それでもなお、各モバイルデバイス16'、16"と各フロントエンド14a…14gとの間の高速な接続および再接続が可能である。たとえば、図1によって示される事例では、モバイルデバイス16"はその位置によりたまたまフロントエンド14e…14gに接続されているが、モバイルデバイス16"は、移動した後、モバイルデバイス16'により近い位置に到達することがある。その場合、モバイルデバイス16"は、恐らくフロントエンド14e…14gから切断されるが、フロントエンド14a…14cに接続される。これは、恐らくその位置では光チャネル18e…18gより光チャネル18a…18cの方が良い(たとえば、雑音が少ない、および/または信号対雑音比が高い)という事実によるものである。

【0062】

フロントエンド14a…14gと様々な第1の装置(たとえば、通信デバイス16'、16")との間の通信は、異なる通信デバイス16'、16"からの異なる信号間の競合を避けるために、異なるリソースを異なるモバイルデバイスに割り当てるスケジューリングを使用して実行され得る。

【0063】

例では、リソースの少なくともいくつかは、タイムスロットであり得る。例では、リソースの少なくともいくつかは、フロントエンド14a…14gの中からの選択されたフロントエンドであり得る。

【0064】

上と下の例では、調整器12は、複数のフロントエンドへのいくつかの同時送信(たとえば、ビーコン送信、基準信号など)を要求し得る。したがって、異なるフロントエンドが、ビーコンまたは基準信号を同時に中継し得る。上と下の例では、調整器12は、たとえば少なくとも2つの異なるフロントエンドが異なるデータを送信および/もしくは受信するように、ならびに/または同時に送信および/もしくは受信するように、スケジューリングされた送信を要求し得る。

【0065】

図2は、異なるモバイルデバイス16(ここではA、B、C、およびDで示されているが、それらの少なくとも1つはデバイス16'および16"のうちの1つであり得る)に割り当てられるようなタイムスロットおよびフロントエンドをマッピングする通信方式20を示す。方式20では、時間は期間21に従ってスケジューリングされる。たとえば、現在の期間21は、直前の期間の後にあり、直後の期間の前にある。期間21は、第1のビーコン送信11'(現在の期間のためのビーコン送信)で開始し、および/または第2のビーコン送信11"(直後の期間のためのビーコン送信)で終了し得る。ビーコン送信(「ビーコン」とも呼ばれる)は、ビーコンが最初であるか、または後続の期間の中核期間を開始するビーコンであるかを示すことが必要ではないとき、11を用いて示され得る。例では、ビーコン11は、複数の(たとえば、全体の)光フロントエンド14a…14gによって、たとえば同時に(同じ時間に、同じスロットにおいて)送信され得る。ビーコン11は、異なる周波数(たとえば、キャリア、サブキャリア)において異なるフロントエンドによって送信されてもよい。たとえば、各フロントエンド14a…14gは、たとえば、同時に、および/または異なる瞬間に、および/または複数のタイムスロットにわたって、異なる周波数で複数の信号においてビーコンを送信し得る。追加または代替として、ビーコン11の中には、異なるサブキャリアが同時に存在し得る。

【0066】

フロントエンド14a…14gの全体からのビーコン11の送信の間、各モバイルデバイス16は、それぞれのワイヤレスリンク18の条件を決定するための測定を実行し得る。たとえば、偶然、または意図的にのいずれかで、フロントエンド14aとデバイス16'との間に不透明な要素がたまたま挿入されている場合、結果として光リンク18aは遮断されるので、モバイルデバイス16'がビーコン11を受信するのを妨げる。このようにビーコン11を受信できないことは、光リンク18aに関連付けられるチャネル接続が悪いという決定を引き起こし得る。同じことが、挿入された不透明な要素の形状および位置に従って、モバイルデバイス16'とフロントエンド14b、14e、14f、14gとの間に当てはまり得る。フロントエンド14b、14e、14f、14gから受信されるようなビーコン11は、悪い受信を引き起こし、これは、モバイルデバイス16'がそれらのフロントエンドからのビーコン11の正しくない受信を認知することを示唆する。

【0067】

各ビーコン11は、たとえば、異なる周波数に沿って掃引することによって、異なる周波数(たとえば、サブキャリア)において送信され得るので、各モバイルデバイス16が各サブキャリアに関連付けられる測定結果を取得することを可能にする。測定結果は、たとえば、ビーコン信号の振幅、および/または、受信されるビーコン信号のパワー、および/またはエネルギー、および/またはパワーなどに関連付けられ得る。測定結果は、たとえば、特定のパイロットシーケンス(たとえば、デバイス16によって知られている)を復号することによって、およびパイロットシーケンスの中のエラーを測定することによって、および/または信号を分析することによって取得され得る。パイロットシーケンスを復号する際に大きいエネルギーおよび/または大きいパワーおよび/または大きい振幅および/または低いエラーレートを有することに関連付けられる、たとえばビーコン11のそれらの受信によって、良い性能がもたらされる。いくつかの例では、受信されるパイロットシーケンスのより多くが、あらかじめ定められるパイロットシーケンスに対応するほど、品質がより高くなる。

【0068】

いくつかの例では、ビーコン11は、異なるフロントエンド14a…14gによってわずかに異なるように中継される。たとえば、異なるフロントエンド14a…14gは、異なる直交シーケンスおよび/または異なる周波数および/または異なる識別子を使用することによって同じビーコン11を再送信し得るので、各デバイス16は、各フロントエンド14a…14gによって取得されるような異なるパイロットシーケンスを区別し得る。続いて、各デバイス16(第1の装置)は、複数のフロントエンド14a…14gから取得されるパイロット信号の各々の測定を実行して、異なるチャネル18a…18gの品質を取得し得る。

【0069】

2つの連続するビーコン11'と11"の送信の中で、スケジューリングによれば、期間21は、通信設備15とモバイルデバイス16との間のデータ(たとえば、ペイロード)および/または制御信号の通信を可能にするためのタイムスロットを有する。たとえば、期間21の一部は、コンテンションアクセス期間(CAP)11aに関連付けられ得る(たとえば、タイムスロットへと再分割され得る)。CAP11aは、ランダムアクセスフレームとして理解され得る。例では、CAP11aは、ビーコン11'の直後にあり得る。CAP11aは、リッスンビフォアトーク(LBT)媒体アクセス戦略によって制御され得る。たとえば、プロトコルAlohaが使用され得る。CAP11aの各タイムスロットにおいて、各モバイルデバイス16'が、他のモバイルデバイスが送信を開始していないことを検出した後で、データまたは制御信号を送信する可能性がある。競合を回避または解決するための、いくつかの既知のLBTプロトコルが開発されている。

【0070】

スケジューリング20によれば、期間21はコリジョンフリー期間(CFP)11b(たとえば、タイムスロットへと再分割される)を含み得る。CFP11bは、CAP11aの直後および/または後続のビーコン11"の直前にあり得る。CFP11bの中の各タイムスロットの間、アップリンク(UL)および/またはダウンリンク(DL)における通信は、モバイルデバイス16の各々(A、B、C、D)を用いて実行され得る。

【0071】

図2から理解され得るように、空間は、異なるフロントエンド14a…14jに従って区分されるものとしても理解され得る。たとえば、図2に示されるスケジューリング20では、3つのフロントエンド14a、14b、14cに対する全体のCFP11bが、たまたまモバイルデバイスAに割り当てられている。異なる第4のフロントエンド14eは、偶然モバイルデバイスBに一意に関連付けられている。フロントエンド14fは、いくつかのタイムスロット(CFP11bの中の最初の13個のタイムスロット)の間、モバイルデバイスCに割り当てられ得るが、フロントエンド14eの後続のスロット(後続のビーコン11'の前のCFP11bの最後の11個のタイムスロット)は異なるモバイルデバイスD(16)に割り当てられる。とりわけ、CFP11bの最初のスロットは、モバイルデバイスA、B、およびCの両方に偶然割り当てられている(フロントエンド14a…14cはモバイルデバイスAに割り当てられ、フロントエンド14dはモバイルデバイスBに割り当てられ、フロントエンド14eおよび14fはモバイルデバイスCに割り当てられ、いずれのフロントエンドもモバイルデバイスDに関連付けられず、フロントエンド14d、14h、および14jはいずれのモバイルデバイスにもまったく関連付けられない)。

【0072】

各タイムスロットが一般に複数の異なるフロントエンド14a…14jに関連付けられ、異なるフロントエンドが異なるデバイスに送信できるという事実により、「スーパーフレームスロット」への言及が行われ得る。時間だけではなく空間も、各々がデバイス16または設備15による送信のために使用される、複数のリソースへと細分化されることになる。基本的に、各CFP11bに対して、各モバイルデバイス16(A、B、C、D)は、1つまたは複数のタイムスロットの組合せに、1つまたは複数のフロントエンド14a…14jにおいて割り当てられる。この概念は、保証されたタイムスロットの頭字語GTSによって示される。

【0073】

スケジューリング20は調整器12によってリアルタイムで定義されてもよく、調整器12は、通信のために使用されることになる必要なタイムスロットおよび/またはフロントエンド14a…14jを各モバイルデバイス16(A、B、C、D)に割り当て得る。特定のスケジューリング20は、各通信デバイス16(A、B、C、D)によって調整器12(またはより一般的には、通信設備15)に提供されるシグナリング情報に基づいて実行されてもよく、および/または、少なくとも1つの基準に基づいてもよい。少なくとも1つの基準は、いくつかの基準のうちの1つの中から(調整器12によって、静的または動的のいずれかで)選ばれ得る。1つの基準は、通信デバイス16によって提供されるフィードバックに基づいてもよく(これは現在の戦略に対しては考慮されなくてもよい)、1つの基準は送信の緊急性に基づいてもよく、1つの基準はデバイスによる要求に基づいてもよい、などである。

【0074】

いくつかの興味深い態様が以下で論じられる。場合によっては、同じ例に対して、異なる態様が互いに組み合わせられてもよい。

【0075】

態様I
ここでは、「デバイス」は「第1の装置(16)」へと一般化されることがあり、「設備」は「第2の装置(15)」へと一般化されることがあり、変形においてそれらが入れ替えられ得る場合であってもそうされることがある。フロントエンドは光フロントエンドであり得る。デバイス16はモバイルデバイスであり得る。設備は固定されていてもよく、設備のフロントエンドは分散していてもよい。調整器12または中央ユニットは、設備の知的な部分であり得る。

【0076】

特に、デバイス16(16'、16")が移動可能であるとき、デバイスの少なくとも1つの移動の後にスケジューリング20がデバイスの位置にもはや適合しないという可能性が生じ得る。たとえば、図1において、デバイス16"がデバイス16'の位置に向かって動く場合、恐らくデバイス16"がフロントエンド14e、14f、および14gによってよりもフロントエンド14a、14b、14cによってより良好にサービスされるという状況が生じ得る。しかしながら、フロントエンド14a、14b、14cは恐らく、スケジューリング20によって、デバイス16'に割り当てられる。したがって、以下のような状況が生じ得る。
実際にはデバイス16'に宛てられるDL送信がデバイス16"に到達する。
デバイス16"がスケジューリング20によって割り当てられたタイムスロットにおいてフロントエンド14e、14f、および14gに送信(ULにおける)を試み、これを行う際に、デバイス16"が実際に、同じタイムスロットにおいてデバイス16'によって実行される同時のUL送信に自身の送信を重ね、結果として、フロントエンド14a…14cがデバイス16"の同時送信の干渉とともにデバイス16'の送信を受信した。同時に、フロントエンド14e…14gは、デバイス16"からの送信を無為に待機したままである。

【0077】

しかしながら、そのようなまたは類似の不便さに対処することを可能にする、いくつかの技法が開発されている。

【0078】

基本的に、(ULおよび/またはDLにおいて)
第1の静的なまたは準静的なスロットの付与(たとえば、これには期限がなく、上書きされるまで有効なままである)、および/または
第2の動的な付与(たとえば、これには有効期限があり、したがって一時的である)
を提供する戦略に従って通信を実行することが可能であることが理解されている。

【0079】

したがって、デバイス16は、固定された、または一時的な、付与されたタイムスロットを有することが可能である。たとえば、デバイス16は、移動している間、動的な第2のタイムスロットの付与を(完全にまたはほとんど)割り当てられてもよく、動いていない(たとえば、固定された)デバイス16は、準静的な第1のタイムスロットの付与を(完全にまたはほとんど)割り当てられてもよい。ここで、スロット(第1のタイムスロットまたは第2のタイムスロット)はスーパーフレームスロットであってもよく、これは、同時に、異なるフロントエンド14a…14gが異なる(または同じ)デバイス16'、16"へ異なるデータパケットを送信し得ること、またはそれらから異なるデータパケットを受信し得ることを示唆する。第1のタイムスロット付与および/または第2のタイムスロット付与の割振りをデバイス16'、16"に知らせるために、設備15は、第1のタイムスロット付与の割振りを通信するための第1のタイムスロット付与情報および/または第2のタイムスロット付与の割振りを通信するための第2のタイムスロット付与情報を送信し得る。したがって、デバイス16'、16"は、それらがいつ設備15にデータパケットを送信できるか、および/または設備15からデータパケットを受信できるかを決定し得る。

【0080】

第1のタイムスロット付与情報(静的なまたは準静的な第1のタイムスロット付与)を、管理フレームの一部として通信することが可能である。

【0081】

制御フレームにおいて(たとえば、動的な記述子を使用して)、(動的な第1のタイムスロット付与のための)第2のタイムスロット付与情報を送信することが可能である。

【0082】

設備15は、制御フレームに関してより低い優先度で管理フレームを送信することが可能であることに留意されたい。したがって、動的な第2のタイムスロット付与情報の通信は、準静的な第1のタイムスロット付与情報の通信より高い優先度を有する。

【0083】

いくつかの例では、デバイス16は、(たとえば、移動した後)新しい付与されたタイムスロット(GTS)を設備15に要求し得る。デバイス要求において、設備15から応答が与えられない場合、デバイス16は、要求が失敗したと見なし得る。これは、たとえば、所定の数の期間(たとえば、スーパーフレーム)が経過した後で行われ得る。たとえば、設備15からデバイス16への第1のタイムスロット付与情報および/または第2のタイムスロット付与情報の送信なしで、5つのスーパーフレームが経過した後、要求はデバイス16によって失敗したと見なされ、デバイス16は、たとえば新しい要求を設備15に送信し得る。

【0084】

図7(a)～図7(c)は、第1のタイムスロット付与情報および第2のタイムスロット付与情報に基づいて割振りを互いに通信するための、デバイス16と設備15との間で交換されるシグナリング情報を示す。

【0085】

図7(a)は、デバイス16によって設備15に提供されるような要求720を示す。要求720は、たとえば要求されたMCSを示し得る(追加または代替として、他のデータが要求720に挿入され得る)。

【0086】

図7(b)は、たとえば設備15によって送信されるような、第1のタイムスロット付与情報710の例(静的または準静的なGTS記述子)を示す。第1のタイムスロット付与情報710は、静的または準静的なタイムスロットが割り当てられるデバイスに送信され得る。第1のタイムスロット付与情報710はGTS開始スロットフィールド712を含んでもよく、これは、第1のGTSの始点(たとえば、第1のGTSが、たとえば期間21において開始する箇所)を示し得る。第1のタイムスロット付与情報710は即刻有効性フィールド713を含んでもよく、これは、付与が(同じ期間21において)直ちに有効であるか、または直ちに有効ではない(そして後続の期間において有効になる)かを示し得る。第1のタイムスロット付与情報710はGTS長さフィールド714を含んでもよく、これは第1のGTSの長さを示し得る。第1のタイムスロット付与情報710がデバイス16によって受信されると、第1のタイムスロット付与情報710においてシグナリングされるような割振りは、スケジューリングを恒久的に(少なくとも、第1のタイムスロット付与情報710の後続の受信まで)変更するために、デバイス16によって使用される。したがって、第1のタイムスロット付与情報710は、設備15によって要求されない場合(たとえば、上書きされない場合)、期限切れにならない。

【0087】

図7(c)は、たとえば設備15によって送信されるような、第2のタイムスロット付与情報700の例(動的なGTS記述子)を示す。第2のタイムスロット付与情報700は、複数のデバイスに送信され得る。第2のタイムスロット付与情報700は、アドレスの指示を欠いていることがある(たとえば、複数のデバイス16がそれを受信する)。第2のタイムスロット付与情報700はGTS開始スロットフィールド702を含んでもよく、これは、動的な第2のGTSの始点(たとえば、動的な第2のGTSが、たとえば期間21において開始する箇所)を示し得る。第2のタイムスロット付与情報700はGTS長さフィールド704を含んでもよく、これは、動的な第2のGTSの長さを示し得る。第2のタイムスロット付与情報700は有効性フィールド706を含んでもよく、これは、どれだけの後続の期間21の間、動的な第2のGTSが特定のデバイス16に割り当てられるかを示し得る。

【0088】

第2のタイムスロット付与情報700がデバイス16によって受信されると、第2のタイムスロット付与情報700においてシグナリングされるような割振りが、スケジューリングを一時的に(たとえば、有効性フィールド706において示される期間の数の間)変更するために、デバイス16によって使用される。したがって、第1のタイムスロット付与情報710は、設備15によって要求されない場合、期限切れにならない。

【0089】

情報710および700(GTS記述子)は、1つの単一のGTSに関連付けられる情報であることに留意されたい。

【0090】

しかしながら、複数のスロットに関する情報710および700を1つの単独のフレームで提供し、それによりペイロードを減らすように、同じフレーム(制御フレームまたは管理フレーム)において複数のGTS記述子を符号化することが可能であることが理解されている。図7(d)に示されるように、いくつかの例では、複数の記述子は、1つの単独のリスト730(たとえば、700'、700"、または710'、710"…)において連結され得る。リスト730は、どれだけ多くのGTS記述子700'、700"、または710'、710"がリストに含まれるかを示すGTS記述子カウントフィールドを含み得る。

【0091】

追加または代替として、メッセージ740(図7(e))が送信され得る。メッセージ740は、情報710および700ならびに/またはリスト730を含み得る。メッセージ740は、どれだけ多くの記述子がリスト730の中にあるかを示すGTS記述子カウントフィールドを含み得る。メッセージ740は、どれだけ多くのGTS記述子700'、700"、または710'、710"がリスト730に含まれるかを示すGTS記述子カウントフィールドを含み得る。メッセージ740は有効性存在指示742を含んでもよく、これは、有効性フィールド706がフレームに含まれるかどうかを示す(記述子700を参照されたい)。メッセージ740は予約ビット743を含み得る。メッセージ740はGTS方向フィールドを含んでもよく、これはGTSの方向(たとえば、DL、UL)を示し得る。

【0092】

情報700、710、730、および/または740を使用することによって、設備15は、新しいスケジューリング情報をデバイス16に示すことができるので、動的なGTS、静的なGTS、または準静的なGTSを異なるデバイスに割り振り直すことができる。

【0093】

いくつかの例では、スケジューリング20は設備15によって変更されてもよく、ならびに/または、情報700、710、730、および/もしくは740は、チャネル18に関するデバイス16によって提供されるフィードバックに基づいてデバイス16に提供される。フィードバックは、複数のフロントエンド14から受信されるようなビーコン11についての測定結果に基づき得る。

【0094】

例が図2aによって提供される。別の例が図3によって提供され、ビーコン11はフロントエンド14a…14gによって同時に提供される。測定31は、複数のフロントエンドから受信されるようなビーコン11の異なるバージョンに対して実行される。次いで、フィードバック32(たとえば、チャネル状態情報(CSI)32)が、デバイス16から設備15に提供される。設備15は、取得されたフィードバック32に基づいてスケジューリングを再定義し得る。したがって、設備15は、構成情報33(700、710、720、730など)をデバイス16に提供し得る(図3において、「動的なGTS」だけが書き込まれる場合であっても、「静的なGTS」または「準静的なGTS」についての情報を提供することも可能である)。フィードバック32の例が以下で提供される(さらなる態様を参照されたい)。

【0095】

上の例では、情報33、700、730、740などを割り振られるGTSは、図2および図3に示されるようなCFP11bのGTSであり得る。

【0096】

したがって、通信設備(15)が提供され、通信設備(15)は割り振られたタイムスロットにおいて情報を送信するように構成され、通信設備(15)は、1つまたは複数の管理フレーム(740)に含まれる構成情報(700)を送信するように構成され、通信設備(15)は、1つまたは複数の制御フレーム(740)に含まれる構成情報(710)を送信するように構成され、通信設備(15)は、第1のタイムスロット付与情報(710)を送信するように構成され、これは管理フレームに含まれ、通信設備(15)は、制御フレーム(740)に含まれる第2のタイムスロット付与情報(700)を送信するように構成され、これは限られた時間の有効性を備え、通信設備(15)は、第1のタイムスロット付与情報(710)に依存して、および第2のタイムスロット付与情報(700)に依存して、通信のために1つまたは複数のタイムスロットを割り振るように構成される。

【0097】

態様II
ここでは、「デバイス」は「第1の装置(16)」へと一般化されることがあり、「設備」は「第2の装置(15)」へと一般化されることがあり、変形においてそれらが入れ替えられ得る場合であってもそうされることがある。フロントエンドは光フロントエンドであり得る。デバイス16はモバイルデバイスであり得る。設備は固定されていてもよく、設備のフロントエンドは分散していてもよい。調整器12または中央ユニットは、設備の知的な部分であり得る。

【0098】

スーパーフレームスロットを割り振るために(たとえば、図2のように見えるように、たとえば、および/または態様1について説明されたように見えるように)、第1の装置(たとえば、デバイス)16(16'、16"、A、B、C、Dなど)への第2の装置(たとえば、設備)15のフロントエンド14a-14g(たとえば、光フロントエンド)からの送信の受信に関するフィードバック32を設備15に提供するために、ある機構が使用され得る。大まかに言えば、第2の装置(たとえば、設備)15(および具体的には、中央ユニットまたは調整器12)は、各々の第1の装置(たとえば、デバイス)16(たとえば、16'、16"、A、B、C、D)に最も適切な付与されたスロットおよび/または最も適切なフロントエンドを定義し得る。

【0099】

大まかに言えば、1つまたは複数のフロントエンド(14a…14g)から1つまたは複数の基準信号および/またはビーコン信号(たとえば、11)を受信するように構成される、第1の通信装置(たとえば、デバイス16)を取得することが可能である。第1の通信装置(16)は、1つまたは複数の基準信号および/またはビーコン信号(11)の受信に基づいて、チャネル情報(たとえば、CSI)を決定する(たとえば、31)ように構成され得る。第1の通信装置(たとえば、16)は、コンテンションアクセス期間(またはランダムアクセスフレーム)、たとえばCAP11a(図2および図3a)において、チャネル情報(32)を送信するように構成され得る。第1の通信デバイス(たとえば、16)は、コリジョンフリー期間、たとえばCFP11b(たとえば、図2および図3b)においてチャネル情報(たとえば、32b)を続いて更新するように構成され得る。

【0100】

したがって、いくつかの例では、
第1の装置(たとえば、デバイス)16が最初にネットワークに到達するとき、第1の装置16は、CAP11aにおいて(図3のように)チャネル情報(たとえば、CSI)32(または図3aのようにアソシエーション要求35)を送信することがあり、それは、第1の装置(たとえば、デバイス)16に割り当てられた付与されたスロットがなく、第2の装置(たとえば、設備)が第1の装置16を認識してないからである。
それに応答して、第2の装置(たとえば、設備)15は、GTS33(図3)を通じて、付与されたタイムスロット(GTS)を第1の装置16に割り当て得る(たとえば、CFP11bのGTS、図2)。
続いて、第1の装置16が期間21のCFP11bにおいて付与されたタイムスロットを割り当てられた後で、第1の装置16は、期間21のCFP11bにおいて(図3bのように)後続のチャネル情報(たとえば、CSI)32を送信(更新)し得る。
それに応答して、第2の装置15は、GTS33b(図3b)を通じて、GTSを第1の装置16に割り当て得る(たとえば、CFP11bのGTS)。

【0101】

図3に示されるように、第2の装置(たとえば、設備)15は、ビーコン11をデバイス16に送信し得る。いくつかの例では、ビーコン11は、上で論じられるものと同じビーコンであってもよく、および/または、図2のビーコン11と同じであってもよい。他の例では、ビーコン11の代わりに、ビーコンではなくてもよい基準信号が送信される。いずれにしても、代替の例において基準信号も使用され得ることが明らかであっても、それはここでは「ビーコン」と呼ばれる。ビーコン11はグローバルメッセージであってもよく、これは、それを中継するすべてのフロントエンド14a…14gに対して同じ(またはほぼ同じ)であってもよく、すべてのフロントエンド14a…14gから、およびすべての第1の装置(たとえば、デバイス16)に向かって同時に送信され得る。

【0102】

複数のフロントエンド14a…14gが、たとえば調整器12によって、有線接続(たとえば、フロントホール17)を通じて、互いに調整および/または同期され得る。

【0103】

ビーコン11および/または基準信号の受信から、デバイス16は、基準信号および/またはビーコンの受信に基づくチャネル情報(チャネル状態情報)を決定し得る。たとえば、デバイス16は、チャネル18の品質を測定し得る。デバイス16は、SNRに関連付けられる信号対雑音比(SNR)またはパラメータを測定し得る。デバイス16はチャネル推定を実行し得る。第2の装置(たとえば、デバイス16)はチャネル測定を実行し得る。

【0104】

たとえば、ビーコン11および/または基準信号は、たとえばパイロットシーケンス(デバイス16によって知られている)を備えてもよく、第1の装置(たとえば、デバイス16)は、パイロット信号の受信について測定を実行し得る。パイロットシーケンスはデバイス16によって知られている(たとえば、デバイス16の記憶ユニットに記憶されている)ので、デバイス16は、パイロットシーケンスのあらかじめ記憶されているバージョンと、受信されるパイロットシーケンスを比較し、あらかじめ記憶されている信号との受信された信号の類似性に基づいて測定を実行し得る。デバイス16は、正しくない受信された値の量を数え得る。正しくない値の量が多いほど、チャネル状態は悪い(たとえば、SNRが低い)。したがって、デバイス16は、チャネルの状態および/または品質および/またはSNRを測定するための測定ユニットを備え得る。図3は、測定31を実行するためにデバイス16によって使用されるチャネル測定時間を示す。

【0105】

図3に示されるように、デバイス16は、ビーコンまたは基準信号(11)の受信に基づいて、測定されたチャネル情報がその中に符号化されているメッセージ32を送信し得る。符号化された測定されたチャネル情報は、各々のフロントエンドおよび/またはデバイス16の間のチャネルが最適であるかどうかを設備15(および/または調整器12)が理解できるようなものであり得る。(したがって、符号化された測定されたチャネル情報は、態様Iを参照して上で説明されたように、情報700、710、730、および/または740を定義するための調整器12によって使用され得る)。

【0106】

第1の装置(たとえば、デバイス16)は、少なくとも第1の送信に対するコンテンションアクセス期間(CAP)において(第1の装置16によるネットワークへのアクセスにおいて)、チャネル情報32を伴うフィードバックメッセージを送信し得ると理解されている。コンテンションアクセス期間(CAP)11aは、図2におけるようなものであり得る(上を参照されたい)。CAP11aの後で、設備15は、メッセージ33を用いて新しい割振り(たとえば、スーパーフレームへと再分割される)を知らせ得る。メッセージ33の例は、たとえば、管理フレームおよび/または制御フレームを含み得る。メッセージ33によって提供される情報の例は、第1のタイムスロット付与情報710および/または動的な第2のタイムスロット付与情報700である。したがって、メッセージ33は、グラントをデバイス16に割り振る構成情報であってもよく、またはそれを含んでもよい。メッセージ33は、後続の期間21の後続のビーコン11の前または後に送信され得る。

【0107】

大まかに言えば、第2の装置(たとえば、設備)15は、複数のデバイスによって提供されるチャネル状態情報に基づいて、タイムスロットおよび/またはフロントエンド14a…14gについての割振り情報を提供し得る。たとえば、図1において、第2の装置(たとえば、通信設備)15は、フロントエンド14a、14b、14cをデバイス16に関連付け、フロントエンド14e、14f、14gをデバイス16"に関連付け、フロントエンド14bにはデバイスをまったく関連付けない。同様に、第2の装置(たとえば、設備)15は、たとえば、デバイス16から得られるフィードバックを考慮することによって、図2におけるようなスケジューリングの定義に到達し得る。

【0108】

上で説明されたように、フィードバック32は複数のデバイス16(たとえば、16'および16")から受信され得る。したがって、第2の装置15の調整器12は、CFP11bの間、付与されたもの(GTS)を分配し得る。異なるチャネル18a…18g(および異なるフロントエンド14a…14g)から到達するものとして異なるビーコン信号11を認識する能力を1つのデバイス16が有するとき、フィードバック32は異なるチャネル18a…18gを参照し得ることに留意されたい。これは、各フロントエンド14a…14gが、異なるシーケンス(たとえば、直交シーケンス)を使用することによってビーコン信号を中継することが可能であることがあり、したがって、異なる中継されるビーコン信号がデバイス16によって決定され測定され得るからである。したがって、ビーコン信号11の複数の受信された中継されたバージョンに対して、フィードバック32が提供され得る。異なるチャネル18a…18gに関連付けられる異なるフィードバックに基づいて、調整器12は、適切なスケジューリングを実行し、最も適切なスーパーフレームGTS(最も適切なフロントエンド14a…14gを含む)を、フロントエンドとアソシエートしている最良のチャネルを検出するデバイスに割り振り得る。例では、フロントエンド14a…14gは、ビーコン信号11を同時に送信するために互いと同期される(同期のためのいくつかの戦略が以下で説明される)。

【0109】

図3aの例がここで論じられる。フロントエンド14a…14gのうちの1つの近くに到達した新しい未知の第1の装置(たとえば、未知のデバイス)16が、いくつかのGTSがCFP11bにおいて割り当てられるようにすることによって、第2の装置(たとえば、設備15)との間でペイロードデータを後で送信および/または受信することを可能にするために、少なくとも1つのアソシエーション要求35(たとえば、35'、35"、35'''など)を送信し得る。

【0110】

(知られていないような)新しい第1の装置(たとえば、デバイス16)は、アソシエーションの前に割り当てられたGTSを有しないので、CAP11aにおいてアソシエーション要求フレーム35を送信する(しかしCFP11bにおいて送信しない)第1の装置16が提供され得る。したがって、要求するデバイス16は、Association Request要素を含むフレームを準備した後で、CAP送信手順を開始し得る。

【0111】

いくつかの例では、要求するデバイス16は、同じ期間21における最新のビーコンの受信から得られたチャネル情報(CSI、SNRなど)を含むフィードバック32を、要求35に含め得る。

【0112】

第1のアソシエーション要求フレーム35'を送信した後、新しい第1の装置(たとえば、デバイス)16は、設備15からアソシエーション応答フレーム聴取し続け得る。

【0113】

アソシエーション応答要素が所定の時間制限以内に受信されない場合、新しいデバイス16は、アソシエーション要求35"、35'''などを送信することを通じてアソシエーションを再び試み得る。図3aでは、アソシエーション応答フレームは検出されていない。(いくつかの例では、アソシエーション要求は他のデバイス16によっても送信され得ることに留意されたい)。

【0114】

いくつかの例では、アソシエーション要求35(35'、35"など)は、フィードバックメッセージ32の例であり得る(図3aの「アソシエーション/再接続+フィードバック」を参照されたい)。したがって、いくつかの例では、フィードバック32の特徴の少なくとも一部は、アソシエーション要求35の特徴の少なくとも一部と同じであってもよく、その逆であってもよい。具体的には、アソシエーション要求35はフィードバック32の例であってもよく、その逆であってもよい。

【0115】

他の例では、フィードバック32b(CFP11bにおいて送信される)は、アソシエーション要求35およびフィードバックメッセージ32とは別個である。

【0116】

要約すると、1つまたは複数の光フロントエンド(14a…14g)から1つまたは複数の基準信号および/またはビーコン信号(11)を受信するように構成される、第1の装置(たとえば、光通信デバイス)(16)が提供され得る。光通信デバイス(16)は、1つまたは複数の基準信号および/またはビーコン信号の受信に基づいてチャネル情報を決定する(31)ように構成され得る。光通信デバイス(16)は、コンテンションアクセス期間CAP(11a)においてチャネル情報(32)を送信し、続いて、CFP(11b)の中の付与されたタイムスロットにおいてチャネル情報(32b)を送信するように構成され得る。応答として、CFP11bのGTS33および/またはGTS更新33bが、第2の装置(たとえば、設備)15によって第1の装置(たとえば、デバイス)に割り当てられ得る。

【0117】

上では、第1の装置16が未知である状況に対して、主に言及がなされた。

【0118】

しかしながら、第1の装置16が接続を失うとき(たとえば、一時的に、たとえば第1の装置16と、たとえば第2の装置15のフロントエンド14a…14gとの間に不透明な物体が挿入されたことにより)、同じ状況が発生し得る。したがって、前の例の代替または追加として、第2の装置15との接続を失い再接続を試みている第1の装置16によって、同じ手順が行われ得る。

【0119】

したがって、
第1の通信装置(16)が、1つまたは複数の基準信号および/もしくはビーコン信号(11)を送信した第2の通信装置(15)とのアソシエーションの際、コンテンションアクセス期間CAP(11a)においてチャネル情報(32)またはアソシエーション要求(35)を送信してもよく、ならびに/または、
第1の通信装置(16)が、1つまたは複数の基準信号および/もしくはビーコン信号(11)を送信した第2の通信装置(15)とともに、コンテンションアクセス期間CAP(11a)においてチャネル情報(32,35)を送信してもよく、ならびに/または、
第1の通信装置(16)が、1つまたは複数の基準信号および/もしくはビーコン信号(11)を送信した第2の通信装置(15)との接続がすでに確立されているとき、チャネル情報(32b)を送信してもよい
ことを確立することが可能であり得る。

【0120】

第2のデバイス(たとえば、設備)15は、ネットワーク側にあるものとして理解され得る。したがって、「接続」、「アソシエーション」、「再接続」などは、「ネットワークとの接続」、「ネットワークとのアソシエーション」、「ネットワークとの再接続」などとしても理解され得る。

【0121】

大まかに言えば、第2の装置(たとえば、設備)15は、フィードバック32の受信の際、および/または接続(もしくは再接続)の要求(35)の受信の際、第1の通信装置16を認める(受け入れる)ことができる。

【0122】

追加または代替として、第2の装置(たとえば、設備)15は、フィードバック32、32b、および/または接続の要求35(もしくは再接続)を送信した第1の装置16に、CFP11bにおけるGTSを割り当て得る。

【0123】

態様IIは、いくつかの例では、光通信デバイス(たとえば、受信機)を指すものとして理解されてもよく、光通信デバイスは、1つまたは複数の光フロントエンドから1つまたは複数の基準信号および/またはビーコン信号を受信するように構成され[複数の光フロントエンドは、たとえば有線接続、たとえばイーサネットベースで接続され得る、たとえば調整器によって、互いに調整および/または同期される]、光通信デバイスは、1つまたは複数の基準信号および/またはビーコン信号[これは、たとえば、受信機に知られているパイロットシーケンスおよび/または信号であってもよく、もしくはそれを備えてもよい]の受信に基づいて、チャネル情報[たとえば、CSI][たとえば、SNRに結び付けられる][たとえば、チャネル推定、および/またはチャネル測定]を決定するように構成され、光通信デバイスは、チャネル情報を[たとえば、1つまたは複数の基準信号および/もしくはビーコン信号がそこから受信された1つまたは複数の光フロントエンドに、または、1つまたは複数の送信機に結合された調整器に]コンテンションアクセス期間(CAP)において[たとえば、その間は、割り振られた(付与された)タイムスロットなしで複数の光通信デバイスが送信することが許容される]送信するように構成される[たとえば、通信デバイスは、光送信機が同じCAPにおいて属するネットワークとのアソシエーションも要求し得る]。

【0124】

態様IIはまた、光通信方法(たとえば、光通信デバイスなどの受信機における)に言及するものとしても理解されてもよく、この方法は、
光通信デバイスにおいて、1つまたは複数の基準信号および/またはビーコン信号を1つまたは複数の光フロントエンドから受信するステップ[複数の光フロントエンドは、たとえば有線接続で接続され得る、たとえばイーサネットベースであり得る、たとえば調整器によって、互いに調整および/または同期される]と、
光通信デバイスにおいて、1つまたは複数の基準信号および/またはビーコン信号[これは、たとえば、受信機に知られているパイロットシーケンスおよび/または信号であってもよく、もしくはそれを備えてもよい]の受信に基づいて、チャネル情報[たとえば、CSI][たとえば、SNRに結び付けられる][たとえば、チャネル推定、および/またはチャネル測定]を決定するステップと、
光通信デバイスから、チャネル情報を[たとえば、1つまたは複数の基準信号および/もしくはビーコン信号がそこから受信された1つまたは複数の光フロントエンドに、または、1つまたは複数の送信機に結合された調整器に]コンテンションアクセス期間(CAP)において[その間は、割り振られた(付与された)タイムスロットなしで複数の光通信デバイスが送信することが許容される]送信するステップ[デバイスは、光送信機が同じCAPにおいて属するネットワークとのアソシエーションも要求し得る]とを含む。

【0125】

態様IIは、光通信設備[たとえば通信デバイスに信号を送信するための、および/または通信デバイスから信号を受信するための、たとえば光フロントエンドを伴うデバイス]を指すものとして理解されてもよく、たとえば、光通信設備は、たとえば、有線ネットワークによってフロントエンドに接続され得る調整器によって調整されてもよく、光通信設備は、1つまたは複数の光フロントエンドから1つまたは複数の基準信号および/またはビーコン信号[たとえば、受信する通信デバイスによってすでに知られていてもよいパイロットシーケンス]を送信するように構成され[複数の光フロントエンドは、たとえば有線接続で接続され得る、たとえばイーサネットベースであり得る、たとえば調整器によって、互いに調整および/または同期される]、光通信設備は、コンテンションアクセス期間(CAP)において[たとえば、その間は、割り振られた(付与された)タイムスロットなしで複数の光通信デバイスが送信することが許容される]チャネル情報を受信するように構成される。

【0126】

態様IIは、(複数の光フロントエンドを含む光通信設備における)光通信方法を指すものとして理解されてもよく、この方法は、
1つまたは複数の光フロントエンドから1つまたは複数の基準信号および/またはビーコン信号[たとえば、受信する通信デバイスによってすでに知られていてもよいパイロットシーケンス]を送信するステップ[複数の光フロントエンドは、たとえば有線接続で接続され得る、たとえばイーサネットベースであり得る、たとえば調整器によって、互いに調整および/または同期される]と、
コンテンションアクセス期間(CAP)において[たとえば、その間は、割り振られた(付与された)タイムスロットなしで複数の光通信デバイスが送信することが許容される]チャネル情報を受信するステップとを含む。

【0127】

態様III
ここでは、「デバイス」は「第1の装置(16)」へと一般化されることがあり、「設備」は「第2の装置(15)」へと一般化されることがあり、変形においてそれらが入れ替えられ得る場合であってもそうされることがある。フロントエンドは光フロントエンドであり得る。デバイス16はモバイルデバイスであり得る。設備は固定されていてもよく、設備のフロントエンドは分散していてもよい。調整器12または中央ユニットは、設備の知的な部分であり得る。

【0128】

複数のフロントエンド14a…14g(たとえば、光フロントエンド)が存在することにより、異なるフロントエンド14a…14gが異なる瞬間に誤って信号(たとえば、ビーコン信号11)を送信する可能性が生じる。これは、設備15からデバイス16に、またはデバイス16から設備15に送信するときに、望まれないエラーをもたらし得る。例が図1aに示されており、各送信18a、18b、18cには、伝搬遅延t_P1、t_P2、t_P3と、フロントホール遅延t_F1、t_F2、t_F3と、フロントホール17がある。この問題は、デバイス16が移動可能であることがあり、これが異なるフロントエンド14a…14gからの通信について予測不可能な遅延につながることがあるという事実により、悪化する。

【0129】

しかしながら、これらの問題は、
複数の光フロントエンド(14a…14g)への基準信号および/もしくはビーコン信号(11)の送信を命令し、ならびに/または
光通信デバイス(16)によって測定されるチャネル情報(32)を取得し、ならびに/または
チャネル情報に基づいて、光フロントエンド(14a-14g)を同期する
ように構成される調整器または中央ユニット12を使用することによって、軽減または克服され得ると理解されている。

【0130】

例がここで図1aにより与えられる。ビーコン11(またはより一般的には、基準信号)は、マルチセルチャネル推定シンボルを含んでもよく、またはそれに関連付けられてもよい。マルチセルチャネル推定シンボルは、異なるフロントエンドに対しては異なり得る。異なるフロントエンド14a…14gは、異なるシンボルを使用することによってビーコン11を中継し得る。シンボルは、直交シーケンス(たとえば、ビーコンの何らかのフィールドにおける、またはビーコンに関連付けられる送信の、多入力/多出力(MIMO)のための)に関連付けられ得る。この点において、各デバイス16は、各フロントエンドから受信された送信の遅延を測定し得る。図1aの例を参照すると、デバイス16は、フロントエンド14aから取得されたビーコンバージョンに対する遅延t_P1+t_F1を観測し、t_P1+t_F1はフロントエンド14bから取得されるようなビーコン信号に対して観測される遅延t_P2+t_F2より大きく、そしてt_P2+t_F2はフロントエンド14cからの送信の遅延t_P3+t_F3より大きい。各フロントエンド14a、14b、14cからの送信が(たとえば、直交シーケンスの使用によって、または他の方法によって)認識され得るので、デバイス16は、遅延の測定結果を決定することに至り得る。

【0131】

したがって、測定を実行した後(これは図3の測定31であり得る)、デバイス16は、各フロントエンド14a～14cからの各送信18a～18cの遅延がその中で提供される(たとえば、特定のフレームに符号化されている)フィードバック32(たとえば、CSIフィードバックおよび/またはSNRフィードバックなど)を送信し得る。

【0132】

続いて、設備15(および具体的には、調整器または中央ユニット12)は、比較的遅延の大きいフロントエンド(たとえば、図1aのフロントエンド14a)からの送信が、比較的遅延の小さいフロントエンド(たとえば、フロントエンド14c)によって実行される送信よりわずかに前に送信されるように、異なるフロントエンド14a…14gを同期し得る。一般に、観測された遅延に比例して、より遅延の大きいフロントエンドの送信に備えることができる。

【0133】

中央ユニットまたは調整器12の動作がここで論じられる。

【0134】

まず、調整器12は、フロントホール17を通じて、すべてのフロントエンド14a…14cへの基準信号(たとえば、ビーコン)11の送信を実行し得る。初期の送信に対して、初期の粗い同期が、たとえばPTP(たとえば、precision time protocol IEEE1588 V2)または別のインターネットベースのプロトコルを使用することによって実行され得る。

【0135】

光フロントエンド14a…14cは、フロントホール17から取得されるような、粗く同期された基準信号および/またはビーコン信号を中継し得る。したがって、異なるビーコンバージョンが、異なるチャネル18a…18cに沿って送信され得る。

【0136】

デバイス16(ならびに/または、通信設備15との間で信号を送信および/または受信している可能性のある他のデバイスのいずれか)が、異なるチャネル18a…18cを通る受信されるビーコンバージョンの各々を損なう遅延を(たとえば、31において)測定し得る。

【0137】

したがって、デバイス16は、たとえば実行された測定31に基づいて、フロントエンド14a、14b、14cにそれぞれ関連付けられるチャネルの各々に対するチャネル状態情報を含むフィードバック32を送信する。

【0138】

調整器12は、フロントエンド14a、14b、14c、およびバックホール17を通じて、フィードバック32に符号化されているCSI情報を受信し得る。したがって、調整器12は、調整器12から、フロントホール17、光フロントエンド14a、14b、14c、チャネル18a、18b、18cを通り、デバイス16までの、各ビーコンバージョンを損なった遅延を知っている。調整器12はまた、デバイス16によって測定されるような遅延の確認のために、自身のクロックを利用し得る(遅延t_F1+t_P1はデバイス16によって測定されるときt_F3+t_P3より大きいので、同じことが逆方向の遅延に当てはまる)。

【0139】

態様IIIは、いくつかの例では、
複数の光フロントエンド(14a-14g)への基準信号および/またはビーコン信号(11)の送信を命令し、
光通信デバイス(16)(たとえば、受信機および/またはモバイルデバイス)によって測定されるチャネル情報(32)[たとえば、フロントエンド(14a-14g)によって中継されるチャネル情報]を取得し、
チャネル情報に基づいて、[たとえば、遅いフロントエンド(14a-14g)を遅らせることによって]光フロントエンド(14a-14g)を同期する
ように構成される、中央ユニット(12)[たとえば、調整器として動作する][たとえば、複数の光フロントエンド(14a-14g)への送信および/またはそれからの受信を命令するためのデバイス]を指すものとして理解され得る。

【0140】

態様IIIは、複数の光フロントエンド(14a-14g)を通じて送信および/または受信するための光通信設備[たとえば、調整器]を指すものとしても理解されてもよく、光通信設備は、
光フロントエンド(14a-14g)を通じて1つまたは複数の通信デバイス[たとえば、光受信機]に基準信号および/またはビーコン信号を送信し、
光通信デバイス(16)によって測定されるチャネル情報[フロントエンド(14a-14g)によって中継されているチャネル情報]を取得し、
チャネル情報に基づいて、[たとえば、遅いフロントエンド(14a-14g)を遅らせることによって]光フロントエンド(14a-14g)を同期する
ように構成される。

【0141】

[任意選択で、初期の粗い同期は、たとえばPTPまたは別のイーサネットベースのプロトコルなどのプロトコルによって、たとえば、光フロントエンド(14a-14g)に対して中央ユニットによって実行され得る]

【0142】

[例では、設備は中央ユニットを含み得る]

【0143】

態様IIIはまた、上のような通信設備および少なくとも1つの光通信デバイス(16)を備えることを指すものとしても理解され得る。

【0144】

態様IIIはまた、[たとえば、複数の光フロントエンド(14a-14g)への送信および/またはそれからの受信を命令するための調整器および/またはデバイスにおいて]方法を指すものとしても理解されてもよく、この方法は、
複数の光フロントエンド(14a-14g)への基準信号および/またはビーコンの送信を命令するステップと、
光通信デバイス(16)(たとえば、受信機および/またはモバイルデバイス)によって測定されるチャネル情報[たとえば、フロントエンド(14a-14g)によって中継されているチャネル情報]を取得するステップと、
チャネル情報に基づいて、[たとえば、遅いフロントエンド(14a-14g)を遅らせることによって]光フロントエンド(14a-14g)を同期するステップと
を含む。

【0145】

態様IIIは、複数の光フロントエンド(14a-14g)を通じて送信および/または受信するための光通信方法[たとえば、調整器]を指すものとしても理解されてもよく、光通信方法は、
光フロントエンド(14a-14g)を通じて1つまたは複数の通信デバイス[たとえば、光受信機]に基準信号および/またはビーコン信号を送信するステップと、
光通信デバイス(16)によって測定されるチャネル情報[フロントエンド(14a-14g)によって中継されているチャネル情報]を取得するステップと、
チャネル情報に基づいて、[たとえば、遅いフロントエンド(14a-14g)を遅らせることによって]光フロントエンド(14a-14g)を同期するステップと
を含む。

【0146】

[任意選択で、初期の粗い同期は、たとえばPTPまたは別のイーサネットベースのプロトコルなどのプロトコルによって、たとえば、光フロントエンド(14a-14g)に対して中央ユニットによって実行され得る]

【0147】

参考文献:
1 L. Cosart、「Precision Packet Delay Measurements Using IEEE 1588v2」、2007 IEEE Int. Symp. on Precision Clock Synchronization for Measurement、Control and Communication、ウィーン、2007年、pp.85-91
2 R. L. Scheiterer、C. Na、D. Obradovic、G. Steindl、F.-J. Goetz、「Synchronization Performance of the Precision Time Protocol in the Face of Slave Clock Frequency Drift」、4th IEEE Conference on Automation Science and Engineering、Key Bridge Marriott、米国ワシントンDC、2008年8月23日～26日

【0148】

態様IV
ここでは、「デバイス」は「第1の装置(16)」へと一般化されることがあり、「設備」は「第2の装置(15)」へと一般化されることがあり、変形においてそれらが入れ替えられ得る場合であってもそうされることがある。フロントエンドは光フロントエンドであり得る。デバイス16はモバイルデバイスであり得る。設備は固定されていてもよく、設備のフロントエンドは分散していてもよい。調整器12または中央ユニットは、設備の知的な部分であり得る。

【0149】

以下では、たとえばデバイス16(16'、16"、A、B、C、D)から設備15(および具体的には調整器12)に、チャネル状態情報(CSI)を提供するための技法が論じられる。この技法は、いくつかの例では、上の態様I、II、IIIのいずれとも互換性がある。

【0150】

たとえば、CSI(たとえば、32または32bまたは35などの1つのフィードバックメッセージにおいて符号化される)は、ビーコン11(またはより一般的には基準信号)に対して測定31を実行することによってデバイス16により取得され得る。ビーコンまたは基準信号11は、(デバイス16によって受信されるような)その受信されたバージョンが測定31を受け得る、あらかじめ確立されているパイロットシーケンスを表し得る。いくつかの例では、測定31は、ビーコン11(および結果として、チャネル18)の品質を決定するために、記憶されている信号(たとえば、インパルス応答の記憶されているバージョン)と(たとえば、調整器12によって)比較され得る信号(たとえば、インパルス応答)を取得することに寄与し得る。いくつかの例では、CSIは、各フロントエンド14a…14gから受信されるようなビーコン11の各バージョンに対して測定され得る(たとえば、デバイス16は、ビーコン11の異なる同時のバージョンを区別する能力を有してもよく、異なるフロントエンド14a…14gは、異なるシーケンス、たとえば直交シーケンスを使用することによってビーコン11の異なるバージョンを同時に中継する能力を有してもよい)。測定されるようなCSIは、たとえば図3のフィードバックメッセージ32の一部として(または設備15にデバイス16によって送信される別のフィードバックメッセージの一部として)、設備15に提供され得る。

【0151】

したがって、調整器または中央ユニット12は、各デバイス16によって測定されるようなCSIを知っていることがあり、スケジューリングを実行するためのこの情報を使用することがある。たとえば、調整器12は、受信されるようなビーコン11のインパルス応答を再構築し、それに基づいて、チャネル18の品質を決定し得る。

【0152】

調整器12は、複数のデバイス16(たとえば、16'、16"、A、C、C、Dなど)から、複数のフロントエンド14a…14gの各々に対するCSIを取得してもよく、調整器12は、各デバイス16および各フロントエンド14a…14gに対する各チャネル18a…18gの品質の知識を取得してもよい。図1の例を参照すると、フロントエンド14a…14cに関連付けられるチャネル18a…18cに対してデバイス16'によって測定されるCSIは、フロントエンド14d…14gに関連付けられるチャネルに対して同じデバイス16'によって測定されるCSIより良いチャネル条件を示す可能性が高い(長い距離の結果として、デバイス16'がフロントエンド14d…14gの一部からのビーコンバージョン11を認識すらしないことすらあり得る)。したがって、調整器12がフィードバックメッセージ32または32bまたは35を取得するとき、調整器12は好ましくは、フロントエンド14a…14cのスーパーフレームスロットをデバイス16'に(および同様に、フロントエンド14d…14gのスーパーフレームスロットをデバイス16"に)割り当てる。

【0153】

大まかに言えば、測定されたCSIを提供するために、デバイス16は、たとえばサンプルごとに、受信されるようなビーコン11の高分解能のコピーを符号化するフィードバックメッセージ32または32bまたは35を送信し得る。しかしながら、この解決法は、ビーコン信号11のすべての受信されたバージョンのすべてのサンプルが符号化されて設備15に送信されなければならないので、あまりにも多くのペイロードを必要とする。

【0154】

それにもかかわらず、デバイス16は、CSIなどの情報を圧縮し、圧縮されたフォーマットでCSIを提出することが可能であることが理解されている。たとえば、CSIが周波数領域(FD)で測定される場合、デバイス16は、
FDから時間領域(TD)にCSIを変換してTD CSIを取得すること、
TD CSIを符号化すること、および
TD CSI(たとえば、フィードバックメッセージ32または32bまたは35のような)を1つまたは複数のフロントエンド14a…14gに送信して、1つまたは複数のフロントエンド14a…14gがTD CSIを調整器12に中継するようにすること
のうちの少なくとも1つを実行し得る。

【0155】

図4は、CSIの例を測定および/または符号化するためのユニット400(デバイス16の一部であり得る)の例を示す。図4aは、CSIを符号化するデータパケット450の例を示す。データパケット450は、図3のフィードバックメッセージ32(または図3bの32bまたは図3aの35)の例であってもよく、またはその一部であってもよい。

【0156】

デバイス16は、それぞれのチャネル18a…18gを通じて異なるフロントエンド14a…14gからビーコン11のいくつかのバージョンを受信し得る。

【0157】

デバイス16は、ビーコン11のパイロット信号(または設備からデバイス16に送信される別の種類の基準メッセージ)に対するFD CSIを測定し得る。

【0158】

ブロック404において、デバイス16は、複数のフロントエンド14a…14gの各々から取得されるような、ビーコン11から測定されるチャネルのバージョン406を取得するために、クラスタ化チャネル推定を実行し得る。したがって、異なるフロントエンド14a…14gから受信されるビーコン11の異なるバージョン406(Hを用いても示される)が取得され得る。いくつかの例では、ビーコン11のバージョンの一部のみが、実際に各デバイス16によって測定される。CSIは、受信されないビーコン11のバージョンのために提供されず(たとえば、チャネル18を遮る障害物があるので、または遠すぎるので)、ビーコン11のこれらのバージョンも(たとえば、過剰な数のエラーがあることで)認識されることが不可能であり、または、(たとえば、パワーが低すぎる、たとえば最低の閾値を下回ることにより)無効であるものとして認識され得る。図1を参照すると、デバイス16'はチャネル18a、18b、18cに対するCSIを測定することを開始するだけであるが、デバイス16"はチャネル18e、18f、18gに対するCSIを測定することを開始するだけであることが想起され得る。したがって、ビーコン11の一部のバージョンのみが、各デバイス16によって測定され得る。

【0159】

ブロック408において、デバイス16はFDからTDへの変換を実行し得る。たとえば、逆離散フーリエ変換(IDFT)が適用され得る。したがって、ビーコン11の残りのバージョンの各バージョンに対するCSIのTDバージョン410(hとしても表される)が取得される。

【0160】

残りのチャネルの各々に対して、ブロック412において、タップに関する表現を使用することによって、各ビーコンバージョン(特定のフロントエンドから受信されるような)のTD表現を再分割することが可能である。したがって、各TD信号410は、タップのシーケンスとして表され得る。各タップは、インパルス応答の時間領域における特定のサンプル値またはサンプル値のシーケンスとして理解され得る。各信号410をサンプルごとに提供する代わりに、デバイス16は、フィードバック信号410(たとえば、32または32bまたは35)において、振幅に関連付けられる値(たとえば、強度、パワー、エネルギーなどのうちの少なくとも1つ)および/または受信されるようなインパルス応答におけるタップの遅延を符号化し得る。

【0161】

例では、最も重要なタップ414(たとえば、振幅および/または強度および/またはパワーおよび/またはエネルギーが最も大きいもの)のみが選ばれてもよく、一方で残りのタップは廃棄されてもよい。例では、ノンゼロタップは選択されるが、ゼロタップ(または振幅が無視できるタップ)は廃棄される。タップを選ぶか廃棄するかを決めるために、振幅(または強度またはエネルギーまたはパワー)が、特定の閾値470と比較され得る。したがって、最も重要なタップ(ノンゼロタップ)のみが選択される(閾値470は、干渉に依存する閾値であってもよく、ならびに/または、たとえば幾何学的因子G472、および/もしくは、ユニット400によって取得されるような遅延および/もしくは強度の値などの、フィードバック474に基づいて、ブロック471において動的に定義されてもよい)。

【0162】

次いで、ブロック416において、最も重要なタップ414に対して量子化が実行され得る。たとえば、量子化ステップΔおよび/または量子化ビットBの数(またはβ)が定義され得る。量子化を用いて、タップを適切に記述する量子化された信号を提供するための、圧縮を得ることができる。

【0163】

続いて、選択されたタップの各々の振幅(または強度またはエネルギーまたはパワーなど)の値および/またはそれらの遅延が、フィードバックメッセージ450(32または32bまたは35)において符号化され、設備15に(たとえば、フロントエンド14およびフロントホール17を通じて調整器12に)提供され得る。

【0164】

(たとえば、ユニット400による)デバイス16の動作の例がここで論じられる。

【0165】

最初に、デバイス16(たとえば、16'、16"、A、B、C、Dなど)が、複数のチャネル18a…18gを通じて複数のフロントエンド14a…14gからビーコン11の複数のビーコンバージョンを受信し得る。一般に、必ずしもすべてのビーコンバージョンがデバイス16によって受信または認識されるのではなく、後続のステップは認識されたビーコンバージョンだけに言及する(たとえば、離れたフロントエンドからのビーコンは受信されず、または、認識されないほど、もしくは廃棄されるほど雑音が多い)。

【0166】

次いで、受信または認識されたチャネルの中から、一部のチャネルのみが(たとえば、ブロック404によって)選ばれ得る。この選択は、測定31に基づいて、たとえば、各フロントエンドから受信されるようなビーコン信号に対して行われるパワーまたは強度の測定の比較に基づいて実行され得る。したがって、クラスタ化チャネル推定が実行され得る。

【0167】

次いで、最も重要なタップが、たとえばブロック412によって、(たとえば、それらの振幅、強度、パワー、エネルギーなどを閾値470と比較することによって)選択され得る。

【0168】

次いで、選択されたタップは、たとえばブロック416によって量子化され得る。

【0169】

次いで、選択されたタップの遅延および/または強度(たとえば、振幅、エネルギー、パワーなど)についての量子化された情報は、(たとえば、フィードバックメッセージ32、32b、35、450などとして)符号化され、(たとえば、フロントエンド14a…14gを通じて)調整器12に送信され得る。

【0170】

図4aは、調整器12に提供されるべき、CSIを符号化するフィードバックメッセージ450(たとえば、フィードバック32、32b、35など)の例を示す。数451は、あり得るビットの量を指す(異なる量があり得る)。(異なる順序でも)符号化され得るフィールドの一部が以下で論じられる。

【0171】

数452は、認識されるような特定のフロントエンドのインデックスを指す。したがって、調整器12は、特定のフロントエンドから受信されるようなビーコンバージョンをCSIが参照することを知っている。

【0172】

数454はステップサイズ(量子化ステップΔ)を指す。

【0173】

数456は量子化ビット(Bまたはβ)の数を指す。

【0174】

数458は遅延情報を指す。具体的には、遅延ベクトルが提供され得る。遅延ベクトルは、遅延ベクトルビットマップであり得る。遅延ベクトルビットマップの中の各々のn番目の位置がn番目のタップに対応するようになされ得る。したがって、遅延ベクトルビットマップは、受信されたパイロットシーケンスの中のn番目のタップが、それに対する強度および/または遅延が示される選択されたタップのうちの1つ(最も重要なタップ)であるかどうかを示し得る。遅延ベクトルビットマップは、たとえばブロック412において実行されるような選択の結果に基づいて、選択されたタップ(ノンゼロタップ)に対応する場合には1(または他の例では0)であってもよく、選択されないタップ(ゼロタップ)に対応する場合には0(または他の場合には1)であってもよい。

【0175】

数460(タップ記述子)は、選択された(ノンゼロ)タップの各々の強度および/または遅延についての量子化された情報を指す。遅延ベクトルにおいて示されるような選択されたタップの各々に対して、強度(または振幅、パワー、エネルギー)461'、461"、461'''など、および/または遅延情報462'、462"、462'''などについての指示(「タップ記述子要素」)が提供され得る。

【0176】

例では、フィールド460のビット長はあらかじめ決定されていない。これは、どれだけのタップがメッセージ450(32)において記述されることになるかがあらかじめ定められていないからである。

【0177】

上記に鑑みて、調整器12は、チャネル情報を含むフィードバックメッセージ32を取得し、
CSIの時間領域表現に各々関連付けられる、第2の値(たとえば、「1」)および第1の値(たとえば、「0」)の文字列(たとえば、ビットマップ458)を備え、
文字列(458)の中の各々の第2の値(「1」)に対して、特定のサンプルにおける時間領域表現の振幅の符号化された値(たとえば、強度461および/または遅延462)を備え、
文字列(458)の中の各々の第1の値(「0」)に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSI(32)を受信するステップ、および
第2の値に関連付けられるサンプル値(461)に基づいてCSIを再構築するステップ
のうちの少なくとも1つを実行し得る。

【0178】

この手順によれば、調整器12はスケジューリングを実行し得る。

【0179】

例では、各CSIは複数のデバイス16の各々から取得され、各デバイス16からの各CSIは、選ばれたチャネル(たとえば、ブロック404によって選ばれた)の中からの各々の特定のフロントエンドから中継されるような特定のビーコンバージョン11を参照する。

【0180】

したがって、調整器12は、フロントエンドから受信されたビーコンバージョンに対する品質が良好であるデバイスに、好ましくはそれらのフロントエンドが割り当てられるように、フロントエンドを適切に割り当て得る。

【0181】

図4の例では、遅延ベクトル458と符号化された遅延フィールド462の両方として遅延情報が提供されることが示されている。しかしながら、これは厳密に必須ではなく、いくつかの例では、遅延ベクトル458と符号化された遅延フィールド462のいずれかが欠けていてもよく、これによりビットの量を減らす。

【0182】

態様IVは、光通信設備との通信のための光通信デバイス(16)に関連していてもよく、光通信デバイスは、
1つまたは複数の光フロントエンド(14a…14g)からの1つまたは複数の基準信号および/またはビーコン信号[たとえば、パイロット信号および/またはシーケンス]の受信から[たとえば、周波数領域]チャネル状態情報(たとえば、CSI)を取得し[たとえば、複数の実数値または複素数値のチャネル状態値が異なる周波数範囲と関連付けられるように]、
[多数のタップおよび/または多数のサンプルを用いて]周波数領域から時間領域にチャネル状態情報を変換して、時間領域チャネル状態情報を取得し[たとえば、それによってチャネルインパルス応答を再構築する]、
時間領域チャネル状態情報を符号化し、
時間領域チャネル状態情報を1つまたは複数の光送信機に送信する
ように構成される。

【0183】

態様IVはまた、光通信デバイス(16)との通信のための光通信設備に関連していてもよく、光通信設備は、
CSIの時間領域表現に各々関連付けられる、「1」の値と「0」の値(または他の記号)の文字列を備え、
[たとえば、強い信号に関連付けられる]文字列の中の各々の「1」の値に対して、特定のサンプル[タップ]における時間領域表現の振幅の符号化された値を備え、
[たとえば、弱い信号に関連付けられる]各々の「0」の値に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSIを受信し
1の値に関連付けられるサンプル値[タップ]に基づいてCSIを再構築する
ように構成される。

【0184】

[例では、閾値に基づいて、最も強いフロントエンド(14a…14g)の信号のみが、フィードバック生成のために選択される。]

【0185】

態様IVはまた、光通信設備との光通信デバイス(16)の通信のための光通信方法に関連していてもよく、光通信方法は、
[たとえば、複数の実数値または複素数値のチャネル状態値が異なる周波数範囲と関連付けられるように]1つまたは複数の光フロントエンド(14a…14g)からの1つまたは複数の基準信号および/またはビーコン信号[たとえば、パイロット信号および/またはシーケンス]の受信から[たとえば、周波数領域]チャネル状態情報(たとえば、CSI)を取得するステップと、
[多数のタップおよび/または多数のサンプルを用いて]周波数領域から時間領域にチャネル状態情報を変換して、時間領域チャネル状態情報を取得するステップ[たとえば、それによってチャネルインパルス応答を再構築する]と、
時間領域チャネル状態情報を符号化するステップと、
時間領域チャネル状態情報を1つまたは複数の光フロントエンド(14a…14g)(たとえば、光トランシーバ)に送信するステップと
を含む。

【0186】

態様IVはまた、光通信設備と光通信デバイス(16)との間の通信のための光通信方法に関連していてもよく、光通信方法は、
CSIの時間領域表現に各々関連付けられる、「1」の値と「0」の値の文字列を備え、
文字列の中の各々の「1」の値に対して、特定のサンプル[タップ]における時間領域表現の振幅の符号化された値を備え、
各々の「0」の値に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSIを受信するステップと、
「1」の値に関連付けられるサンプル値[タップ]に基づいてCSIを再構築するステップと
を備える。

【0187】

態様IVは、光通信設備との通信のための光通信デバイスを指すものとして理解されてもよく、光通信デバイスは、
[たとえば、複数の実数値または複素数値のチャネル状態値が異なる周波数範囲と関連付けられるように]1つまたは複数の光フロントエンドからの1つまたは複数の基準信号および/またはビーコン信号[たとえば、パイロット信号および/またはシーケンス]の受信から[たとえば、周波数領域]チャネル状態情報(たとえば、CSI)を取得し、
[多数のタップおよび/または多数のサンプルを用いて]周波数領域から時間領域にチャネル状態情報を変換して、時間領域チャネル状態情報を取得し[たとえば、それによってチャネルインパルス応答を再構築する]、
時間領域チャネル状態情報を符号化し、
時間領域チャネル状態情報を1つまたは複数の光送信機に送信する
ように構成される。

【0188】

態様IVは、光通信デバイスとの通信のための光通信設備を指すものとして理解されてもよく、光通信設備は、
CSIの時間領域表現に各々関連付けられる、「1」の値と「0」の値(または他の記号)の文字列を備え、
[たとえば、強い信号に関連付けられる]文字列の中の各々の「1」の値に対して、特定のサンプル[タップ]における時間領域表現の振幅の符号化された値を備え、
[たとえば、弱い信号に関連付けられる]各々の「0」の値に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSIを受信し、
1の値に関連付けられるサンプル値[タップ]に基づいてCSIを再構築する
ように構成される。

【0189】

[例では、閾値に基づいて、最も強いフロントエンドの信号のみが、フィードバック生成のために選択される。]

【0190】

態様IVはまた、光通信設備との光通信デバイスの通信のための光通信方法を指すものとして理解されてもよく、光通信方法は、
[たとえば、複数の実数値または複素数値のチャネル状態値が異なる周波数範囲と関連付けられるように]1つまたは複数の光フロントエンドからの1つまたは複数の基準信号および/またはビーコン信号[たとえば、パイロット信号および/またはシーケンス]の受信から[たとえば、周波数領域]チャネル状態情報(たとえば、CSI)を取得するステップと、
[多数のタップおよび/または多数のサンプルを用いて]周波数領域から時間領域にチャネル状態情報を変換して、時間領域チャネル状態情報を取得するステップ[たとえば、それによってチャネルインパルス応答を再構築する]と、
時間領域チャネル状態情報を符号化するステップと、
時間領域チャネル状態情報を1つまたは複数の光フロントエンド(たとえば、光トランシーバ)に送信するステップと
を含む。

【0191】

態様IVはまた、光通信設備と光通信デバイスとの間の通信のための光通信方法を指すものとして理解されてもよく、光通信方法は、
CSIの時間領域表現に各々関連付けられる、「1」の値と「0」の値の文字列を備え、
文字列の中の各々の「1」の値に対して、特定のサンプル[タップ]における時間領域表現の振幅の符号化された値を備え、
各々の「0」の値に対して、符号化されており、かつ0と見なされるサンプル値を備えない
ように符号化されるCSIを受信するステップと、
「1」の値に関連付けられるサンプル値[タップ]に基づいてCSIを再構築するステップと
を備える。

【0192】

態様V
ここでは、「デバイス」は「第1の装置(16)」へと一般化されることがあり、「設備」は「第2の装置(15)」へと一般化されることがあり、変形においてそれらが入れ替えられ得る場合であってもそうされることがある。フロントエンドは光フロントエンドであり得る。デバイス16はモバイルデバイスであり得る。設備は固定されていてもよく、設備のフロントエンドは分散していてもよい。調整器12または中央ユニットは、設備の知的な部分であり得る。

【0193】

態様IVに対する変更がここで論じられる。

【0194】

ここで、
複数の[たとえば、光]フロントエンド[たとえば、OFE]14a…14gから複数の(たとえば、同時の)基準信号(たとえば、ビーコン)11を受信し、および/または
受信された基準信号11の評価に基づいてチャネル状態情報(CSI)(たとえば、測定31の後)を取得し、
符号化されたCSIを提供するためにCSIを符号化し、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する、[たとえば、信号]情報[たとえば、TAPフォーマット]を提供する
ように構成される、デバイス[たとえば、送信機、たとえばモバイルデバイス、たとえば光送信機であり得る、第1の装置16]に対する言及が、特に行われる。

【0195】

CSIは、たとえば、図4および/または図4aにおけるように(たとえば、特にフィールド461および/または462におけるように)符号化され得る。

【0196】

ここで、CSIについて、これは、チャネルについての情報を含むフィードバックメッセージ(たとえば、32、32b、35、450、450bなど)であることが意図され得る。

【0197】

各々の第1の装置16が、特定のフォーマットを使用することによってCSIを送信することが可能であることが、理解されている。例が以下の表によって与えられる。

【0198】

【表1】

【0199】

これらのフォーマットのうちの少なくとも1つが使用され得る(他のフォーマットが使用され得る)。

【0200】

CSIまたはフィードバックメッセージ(たとえば、32、32b、35、450、450bなど)において、以下のフィールド
フィールド901:認識されるフロントエンドの数N
フィールド902:TAPフォーマット
フィールド920:フロントエンドフィードバック記述子要素1…N(フィールド901において示されるものと同じ数)
のうちの少なくとも1つであり得る。

【0201】

各フィールド920(フロントエンドフィードバック記述子要素)は、
フィールド921:パイロットシーケンスの時間位置に関連付けられるパイロットシンボル数
フィールド922:パイロット分割(たとえば、アダマール符号、サブキャリア離隔など)
フィールド923:どれだけのタップが後で記述されているかを示す、タップの数
フィールド460b:タップ記述子(各々の記述されたタップについての情報を提供する)
のうちの少なくとも1つを含み得る。

【0202】

各フィールド460b(1つの特定のタップを記述するための)は、
フィールド461b(タップの強度または振幅またはパワーまたはエネルギー)
フィールド462b(タップの遅延)
のうちの少なくとも1つを含み得る。

【0203】

フィールド461bおよび462において、たとえばdBmまたはpsまたはns(ピコ秒またはナノ秒)の単位で、決められた分解能で量を符号化することが可能であることが理解されている。たとえば、タップの強度を記述するために、いくつかの場合には、0.15dBmのステップを伴う特定の分解能が好ましく、一方でいくつかの他の場合には、2dBmのステップを伴う特定の分解能が好ましい。同様の理由で、遅延を記述するために、30psの分解能を使用するのが好ましいことがあるが、他の場合には、4nsの分解能を使用するのが好ましいことがある。いくつかの場合には、基準値(たとえば、「0値」、オフセットなど)が与えられ得る。いくつかの場合には、フィールド461bおよび/または462bを符号化するために、8ビットを使用するのが好ましく、一方でいくつかの場合には4ビットで十分であり、他の場合には10ビットが必要である。

【0204】

したがって、様々なフォーマットが使用され得る。各々の第1の装置16は、フォーマット(たとえば、符号化分解能)を選択し、フォーマットをフィールド902においてシグナリングし得る。したがって、第2の装置15がフィールド461bおよび/または462bを復号するとき、第2の装置15は、必要な精度および高い圧縮度を伴うフィードバック測定結果を取得することができる。

【0205】

フィールド461bおよび/または462bに対する異なる構成は互いにグループ化されてもよいことが理解されている。第1の装置16は、符号化分解能の選択を利用することが可能であり、これは、各選択に対して互いに組み合わせられてもよい。フィールド902の異なる符号は、タップを記述するための構成データを各々が組み合わせる、異なるセクションに関連付けられ得る。フィールド902は、選択された符号化分解能のすべての構成データを指すインデックスを符号化し得る。たとえば、次の通りである。

【0206】

【表2】

【0207】

フィールド461bの各フォーマットに対して、
ビットの数931
基準値932
ステップ933
のうちの少なくとも1つが定義され得る。

【0208】

フィールド462bの各フォーマットに対して、
ビットの数941
基準値942
ステップ943
のうちの少なくとも1つが定義され得る。

【0209】

したがって、第1の装置16は、取得された測定結果に基づいて最も好ましい分解能(フォーマット)を選択し、選択された最も好ましい分解能に従ってCSIを符号化し得る。したがって、フィールド461bおよび462は、良好な分解能および精度と高い圧縮度をもたらすために量子化される。

【0210】

いくつかの例では、符号化分解能の選択を記述する情報は、複数の伝搬経路の振幅および/もしくは強度および/もしくは遅延、ならびに/またはそれらに関連付けられる値を符号化するフィールドのフォーマットを含むことに留意されたい。

【0211】

第2の装置15(たとえば、調整器)は、
符号化されたチャネル状態情報(CSI)(たとえば、フィードバックメッセージ32、32b、35、または450、450bとして符号化されるメッセージ)を受信すること、
複数の考えられる符号化分解能の中からの、CSI(32、32b、35、450、450b)を符号化するために使用される符号化分解能の選択を記述する情報(902)を受信すること、
CSIを符号化するために使用される符号化分解能の選択を記述する情報(902)に応じて、符号化されたCSI(32、32b、35、450、450b)を復号すること
のうちの少なくとも1つを実行し得る。

【0212】

第2の装置15は、CSIから取得されるようなフィードバック情報に基づいてスケジューリングを実行し得る。

【0213】

上の例では、いくつかの態様はデバイス[たとえば送信機、たとえばモバイルデバイス、たとえば光送信機]に関し、このデバイスは、
複数の[たとえば、光]フロントエンド[たとえば、OFE]から複数の基準信号を受信し、
受信された基準信号の評価に基づいてチャネル状態情報(CSI)を取得し、
符号化されたCSIを提供するためにCSIを符号化し、および/または
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]を提供する[たとえば、シグナリングする]
ように構成される。

【0214】

デバイスは、複数の伝播経路の強度および/もしくは遅延、ならびに/またはそれらに関連付けられる値を符号化するフィールドのフォーマットを、符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]が含むように、さらに構成され得る。

【0215】

デバイスは、CSIが基準信号識別情報を含むように、またはそれに関連付けられるようにさらに構成されてもよく、および/または、符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]は、基準信号識別情報に関連付けられる。

【0216】

デバイスは、符号化分解能を記述する情報が、タップ強度を符号化するために使用されるビットの数および/またはタップ遅延を符号化するために使用されるビットの数を定義するように、さらに構成され得る。

【0217】

デバイスは、符号化分解能を記述する情報が、タップ強度および/または遅延のステップサイズ[たとえば、0.15dBmまたは30ps]を定義するように、さらに構成され得る。

【0218】

デバイスは、符号化分解能を記述する情報が、タップ強度および/または遅延に対する基準値(たとえば、「0値」)を定義するように、さらに構成され得る。

【0219】

デバイスは、取得されたCSI値に基づいて[適切な]分解能[量子化のための]を見つけるようにさらに構成され得る。

【0220】

デバイスは、CSIを丸めた量子化された値に基づいて分解能を選択するようにさらに構成され得る。

【0221】

デバイスは、CSIが、受信された基準信号の[または、異なる伝播経路を介して移動する、および/もしくは異なる時間にデバイスに到達する基準信号の複数のバージョンの]強度、またはそれに関連付けられる値を備えるように、さらに構成され得る。

【0222】

デバイスは、CSIが、受信された基準信号の遅延[または、異なる伝播経路を介して移動する、および/もしくは異なる時間にデバイスに到達する基準信号の複数のバージョン間の遅延]、またはそれに関連付けられる値を備えるように、さらに構成され得る。

【0223】

デバイスは、CSIが基準信号の指示[たとえば、フィールド「パイロットシンボル番号」および/または「分割」]を備えるようにさらに構成され得る。

【0224】

デバイスは、デバイスがネットワーク調整器であるように、またはそれを含むように、さらに構成され得る。

【0225】

デバイスは、符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]が[「強度」もしくは「遅延」のいずれかについて、または両方について]以下のフォーマットのうちの少なくとも1つに従ったフォーマットを含むように、さらに構成され得る。

【0226】

【表3】

【0227】

上の例では、いくつかの態様は[たとえば、送信機、モバイルデバイス、光送信機によって、たとえば上および/または下の例のいずれかに従って実行される]方法に関し、この方法は、
複数の[たとえば、光]フロントエンド[たとえば、OFE]から複数の基準信号を受信するステップ、
受信された基準信号の評価に基づいてチャネル状態情報(CSI)を取得するステップ、
符号化されたCSIを提供するために、CSIを符号化するステップ、および/または
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する[たとえば、信号]情報[たとえば、TAPフォーマット]を提供するステップ
を含む。

【0228】

上の例では、いくつかの態様は、
符号化されたチャネル状態情報(CSI)を受信し、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する[たとえば、信号]情報[たとえば、TAPフォーマット]を受信し、
CSIを符号化するために使用される符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]に応じて、符号化されたCSIを復号する
ように構成されるデバイス[たとえば受信機、たとえばデバイス、たとえば光受信機]に関する。

【0229】

デバイスは、デバイスが複数の[たとえば、光フロントエンド]を含むようにさらに構成され、それらに基準信号を送信させるように構成され得る。

【0230】

デバイスは、[たとえば、上および/または下の例のいずれかに従って]デバイスがネットワーク調整器であるように、またはそれを含むように、さらに構成され得る。

【0231】

デバイスは、符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]において示されるタップフォーマットに従って、CSIから複数の伝播経路の強度および/または遅延を復号するために、さらに構成され得る。

【0232】

デバイスは、CSIが基準信号識別情報を含むように、またはそれに関連付けられるようにさらに構成されてもよく、および/または、符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]は、基準信号識別情報に関連付けられる。

【0233】

デバイスは、符号化分解能を記述する情報が、「タップ強度」を符号化するために使用されるビットの数もしくはそれに関連付けられる値、および/またはタップ「遅延」を符号化するために使用されるビットの数もしくはそれに関連付けられる値を定義するように、さらに構成され得る。

【0234】

デバイスは、符号化分解能を記述する情報が、タップ強度および/もしくは遅延、またはそれらに関連付けられる値のステップサイズ[たとえば、0.15dBmまたは30ps]を定義するように、さらに構成され得る。

【0235】

デバイスは、符号化分解能を記述する情報が、タップ強度および/もしくは遅延、またはそれらに関連付けられる値の基準値(「0値」)を定義するように、さらに構成され得る。

【0236】

デバイスは、CSIが、受信された基準信号[または、異なる伝播経路を介して移動する、および/もしくは異なる時間にデバイスに到達する基準信号の複数のバージョンの]強度、またはそれに関連付けられる値を備えるように、さらに構成され得る。

【0237】

デバイスは、CSIが、受信された基準信号の遅延[または、異なる伝播経路を介して移動する、および/もしくは異なる時間にデバイスに到達する基準信号の複数のバージョン間の遅延]、またはそれに関連付けられる値を備えるように、さらに構成され得る。

【0238】

デバイスは、CSIが基準信号の指示[たとえば、フィールド「パイロットシンボル番号」および/または「分割」]を備えるようにさらに構成され得る。

【0239】

デバイスは、符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]が[「強度」もしくは「遅延」のいずれかについて、または両方について]以下のフォーマットのうちの少なくとも1つに従ったフォーマットを含むように、さらに構成され得る。

【0240】

【表4】

【0241】

上の例では、いくつかの態様は、上および/または下の例のいずれかによるデバイスと、上および/または下の例のいずれかによるデバイスとを備えるシステムに関する。

【0242】

上の例では、いくつかの態様は、
符号化されたチャネル状態情報(CSI)を受信するステップと、
複数の考えられる符号化分解能の中からの、CSIを符号化するために使用される符号化分解能の選択を記述する[たとえば、信号]情報[たとえば、TAPフォーマット]を受信するステップと、
CSIを符号化するために使用される符号化分解能の選択を記述する情報[たとえば、TAPフォーマット]に応じて、符号化されたCSIを復号するステップと
を備える、方法[たとえば、受信機、デバイス、光受信機、ならびに/または、上および/もしくは下の例のいずれかによるデバイスによって実行される]に関する。

【0243】

態様VI
図8dを参照する。ビーコン11(たとえば、フロントエンド14a…14gの各々によって再送信されるような)が、第1の通信装置(たとえば、デバイス16)(たとえば、16'、16"、A、B、C、D)によって取得され、これは光デバイス(たとえば、モバイルデバイス)であり得る。第1の通信装置16は、ビーコン11(またはフロントエンド14a…14gからの異なる信号)を(32において)測定し得る。次いで、第1の通信装置(たとえば、デバイス)16がフィードバック32(チャネル状態情報(CSI))を送信してもよく、これは、測定結果に由来するチャネル18a…18gの各々の状態を示す(たとえば、強度が強いほど、または検出エラーが少ないほど、チャネルは良好である)。次いで、第2の通信装置(たとえば設備、たとえば固定された設備)15がスケジューリング20を定義し得る。続いて、設備15が、スケジューリングメッセージ33(これはいくつかの例では、図3のメッセージ33または図4bのメッセージ33bと同じであり得る)を送信してもよく、スケジューリングメッセージ33において、スケジューリング20が定義される(そして、いくつかのスーパーフレームスロットまたはGTSが第1の装置16'、16"、A、B、C、Dなどの各々に割り当てられる)。

【0244】

高性能なリアルタイムスケジューリング技法を用いても、リンク18a…18gの条件は時間とともに大きく変化することに留意されたい。いくつかの場合、何らかの特定の周波数(たとえば、サブキャリア)が好ましいが、他の場合には、異なるサブキャリアが好ましいことがある。これらの現象は、一般に決定論的にまたは先験的に定義することが容易ではないことに留意されたい。

【0245】

これらの問題に対処するために、少なくとも1つのモバイルデバイス16(たとえば、16'、16"、A、B、C、D)が、たとえばフロントエンド14から受信された信号に対して実行される測定に頼ることによって、いくつかの特定のサブキャリア(およびより一般には、いくつかの特定の通信構成)を要求することが可能であることが理解されている。たとえば、測定はビーコン11に対して実行され得る。(いくつかの例では、ビーコン11に対して測定が実行されることは厳密に必須ではない。他の例では、他の信号が測定され得る。測定された信号が、すべてのフロントエンドによって同時に送信される信号であることが好ましいことがあり、これは、ビーコン11に対する測定を有利にする。以下では、フロントエンド14a…14gによって送信される任意の他の信号、たとえばフロントエンドによって同時に送信される任意の信号が、測定を実行するために使用され得ることが理解されたままでありながら、わかりやすくするために、ビーコン11に対する言及が行われる。)測定されるべきビーコン信号11は、各モバイルデバイス16によって検出され得るパイロットシーケンスを提示し得る。ビーコン信号11は、異なる周波数(サブキャリア)のシーケンスを含み得る。各デバイス16は、たとえば、ULおよび/またはDLに対して、ビーコン信号11に対して実行される測定に基づいて、特に、ビーコン信号の異なるサブキャリアに対して実行される測定に基づいて、どれが好ましい周波数(サブキャリア)であるかを決定し得る。モバイルデバイス16は、ビーコン信号がそれから復号される、各フロントエンド14a…14gに対してこの決定を実行し得る。

【0246】

好ましいサブキャリア(および使用されるべき周波数の選択)をシグナリングすることは、一般には簡単な仕事ではない。好ましいサブキャリアの指示は、第1の通信装置(たとえば、デバイスまたはモバイルデバイス)16から第2の通信装置(たとえば、設備)15へ迅速にシグナリングされなければならず、通信エラーの影響も受けやすい。たとえば、特定の第1の通信装置16が好ましいサブキャリアを示す場合であっても、第2の通信装置15は、この通信を受信することに失敗することがあり、したがって、第1の通信装置16にとってはもはや望ましくないかもしれない以前のサブキャリアを用いて、送信し続けることがある。さらに、第1の通信装置16に時間内に設備12からの合意を通知するのは一般に難しく、それは、肯定応答信号に時間がかかり、これが時間遅延の増大も伴うからである。

【0247】

様々な考えられる構成(たとえば、周波数、サブキャリアのためのビットの数など)を定義し、それらを迅速かつ容易に識別する、ビット割振りテーブル(BAT)を定義することが可能であることが理解されている。例では、BATは、第2の通信装置15と第1の通信装置16との間でのデータの送信を可能にするための構成データを示すテーブルと見なされ得る。BATについての情報は、第2の通信装置15(たとえば、調整器12)および第1の通信装置16の各々によって維持され得る。したがって、第2の通信装置15および第1の通信装置16は、BATについての情報を共有するために互いに通信し得る。したがって、複数のアクティブBATが定義されてもよく、それらの各々が通信において使用されるべき異なる周波数を指してもよく、各通信はアクティブBATのうちの1つを選択した後に実行される。

【0248】

図8aは、複数のBAT51-0、51-1…51-22、51-23を示すリスト50を示す。ここでは、24個のBATが存在するが、他の例では異なる数が選ばれてもよい。

【0249】

リスト50は、各々がBATに関連付けられる複数の記録を含み得る。各BATに対して、識別子が選ばれ得る(これはここでは0から23の数である)。数52は、特定のBATに関連付けられる識別子を各々記憶する、フィールドのリストの列を参照する。しかしながら、後の部分では、同じ数52が、特定のBATに関連付けられる識別子を示すためにも使用され得る。

【0250】

各BATに対して、有効性情報が提供され得る。いくつかの例では、有効性情報はメッセージ61のフィールドにおいて符号化され得る。(数53は、特定のBATに関連付けられる有効性情報を各々記憶する、フィールドのリストの例を参照する。しかしながら、後の部分では、同じ数53が、特定のBATに関連付けられる有効性情報を示すためにも使用され得る。)有効なBATは選択可能なBATのうちの1つであり得るが、(少なくとも後続の更新まで)無効なBAT(たとえば、51-1、51-22、51-23)を選ぶことはできない。有効性情報53は、第1の通信装置16にデータを送信するために第2の通信装置15によって使用可能なBATについての情報を含み得る。(有効性情報53から、無効なBATを知ることも可能であり得る。いくつかの例では、有効性BAT情報53は、無効なBATについての明示的な情報を備え得る。)有効性情報は、各BATに対するバイナリ情報であり得る。

【0251】

各BATに対して、更新BAT情報が提供され得る。(数54は、各々が特定のBATに関連付けられる更新BAT情報を記憶する、フィールドのリストの列を参照する。しかしながら、後の部分では、同じ数54が、特定のBATに関連付けられる更新BAT情報を示すためにも使用され得る。)更新BAT情報54は、たとえば、特定のBATが更新されるべきBATであるかどうかについての情報を含んでもよく、たとえば、BAT51-1は更新されるべき最後のBATであるが、BAT51-0、51-22、および51-23は更新されるべきBATではない。(更新されるべきBATは一般に無効なBATであり得る)。いくつかの例では、1つだけのBATが毎回更新されることになる。

【0252】

各BATに対して、BAT更新情報が提供され得る。(数55は、各々が特定のBATに関連付けられるBAT更新情報を記憶する、フィールドのリストの列を参照する。しかしながら、後の部分では、同じ数55が、特定のBATに関連付けられるBAT更新情報を示すためにも使用され得る。)BAT更新情報は、特に、通信のために使用されるべきサブキャリア、前方誤り訂正(FEC)ブロックサイズおよび/もしくはFECコードレートなどのFEC情報、ならびに/または、特定のBATに従って通信を特徴付けるための他の情報を含み得る。BAT更新情報はインデクシングされ得る。各サブキャリアは、BAT更新情報に記憶され得る特定のインデックスに関連付けられ得る。同じことが、BAT更新情報の一部であり得る、FEC情報および/または他の考えられる情報に当てはまり得る。

【0253】

リスト50は、各モバイルデバイス16および調整器12の記憶ユニットの異なるインスタンスに記憶され得る。すべてのBAT51-0…51-23を伴うリスト50は、チャネルの条件(たとえば、光リンク18a…18gの条件)に基づいてオンザフライで更新され得る。よって、リスト50のコピーは、調整器12と各モバイルデバイス16の両方に記憶される。調整器12において、リスト50のインスタンスは各モバイルデバイス16を参照して記憶されるが、各モバイルデバイス16は1つの単独のリスト50を有し得るだけであることに留意されたい。他の解決法も可能である。

【0254】

リスト50は、複数の光フロントエンドに起因するようものとしてチャネルに関連付けられ得る。したがって、チャネルは、デバイス(16'または16")に関連付けられ、特定のリンクには関連付けられない(たとえば、フロントエンド14からデバイス16へのリンク18aには関連付けられないが、デバイス16'が経験するリンク18a、18b、および18cによって形成されるグローバルチャネルには関連付けられる)。一般に、異なるフロントエンド16a…16gが、同じリスト50に関連付けられ得る。

【0255】

例では、第1の装置16は、たとえば図8に示されるBATメッセージ61を送信し得る。BATメッセージ61は、
たとえばリスト50の複数のBAT51-0から51-23の中から有効なBATを示す、有効性情報フィールド53
更新BAT情報フィールド54、たとえば現在更新されるBAT(たとえば、現在更新されているBAT、これはこの場合51-1である)
BAT更新情報フィールド55、これは、BATを更新するかどうかについて、および/または、続いて(たとえば、BS15からモバイルデバイス16に向かうDLにおいて)通信を構成するかどうかを知らせ得る
のうちの少なくとも1つを備え得る。

【0256】

第1の装置16から第2の装置15へのBATメッセージ61の送信は、第2の装置15におけるリスト50の変更を引き起こし得る(一方で、第1の装置16におけるリスト50のインスタンスは、BATメッセージ61の送信の前にすでに更新されている)。

【0257】

第1の装置16は好ましいBATを選ぶ自由を有し得る(たとえば、ビーコン信号11に対して実行される測定についての決定に基づいて)が、第2の装置15は、(有効性情報フィールド53に従って)有効なBATに対するBAT更新情報フィールド55によって定義される構成データの中から、DL送信のための構成データを使用することが義務付けられ得る。したがって、モバイルデバイス16は少数の異なる構成を決定し得るが、第2の装置15は一般に、第1の装置16によって提案される考えられる構成の中から1つの構成を選択し得る。

【0258】

図8bはBATメッセージ61の例を示す。BATメッセージ61は、
送信デバイス(たとえば、16'、16"、A、B、C、Dのうちの1つ)
関連付けられるフロントエンド(たとえば、14a…14jのうちの1つ)
少なくとも1つのBAT(有効なBATおよび/または更新されたBAT)
のうちの少なくとも1つに関連付けられ得る。

【0259】

BATメッセージ61は、有効なBATとして、有効性情報53の中の1、5、14として識別されるBAT(51-1、51-5、51-14)を定義し得る。この場合、更新BAT情報フィールド54は、現在のBATメッセージ61を用いて更新されるBATが、1として識別されるBAT(すなわち、図8のBAT51-1)であることを示し得る。残りのBAT更新情報フィールド55は、フロントエンド14から第1の装置16へのDL通信の送信を更新するための更新データを提供し得る。したがって、第2の装置15は、有効性情報53を変更することによって(変更される場合)、および/または、更新BAT情報54に従ってBAT1(51-1)に対するBAT更新情報55を更新することによって、リスト50のインスタンスをオンザフライで変更する。

【0260】

第2の装置15と第1の装置16との間の通信の例が図8cにおいて与えられる。ここで、後続のBATメッセージ61は、61'、61"、61'''などによって示される。ここで、ビーコン11はわかりやすくするために示されていない(しかし、ビーコン11は第1の装置16によって時間内に受信されており、第1の装置16が測定を実行し、好ましいフロントエンドおよび好ましいサブキャリアを決定したことが理解される)。

【0261】

理解され得るように、第1の装置16は第1のBATメッセージ61'を第2の装置15に送信する。第1のBATメッセージ61'は、(たとえば、有効性情報フィールド53において)
BAT1(51-1)が現在無効であること(これは、すべての有効なBATを明示的に列挙して、それにより無効なBATを決定することを可能にすることによって、または、すべての無効なBATを明示的に列挙することによって取得され得る)、および
BAT2(51-2)が今更新されることを更新BAT情報フィールド54が示すこと
を示す。

【0262】

BATメッセージ61'は、ここでは掘り下げられない何らかの現象(たとえば、第1の装置16とフロントエンド14との間のチャネル18を遮る物体、干渉、高いエラーレート、低いエネルギーなど)によって失われる(または何らかの形で説明可能ではない、たとえば復号可能ではない)ことがここで示される。したがって、BATメッセージ61'は第2の装置15に到達しない。

【0263】

そのような現象に対処するために、第2の装置15から第1の装置16への肯定応答(ACK)および/または否定応答(NACK)の送信を予見することは可能であり得ると、当然のように考えるかもしれない。残念ながら、時間の制約が厳しく、それは、ACKおよび/またはNACKの送信が難しく時間のかかるものであることがわかっているほどである。

【0264】

しかしながら、第1の装置16は、第2の装置15が更新されたBATおよび/もしくは有効なBATを使用して後続のメッセージを送信するか、またはそれを使用せずに後続のメッセージを送信するかに基づいて、暗黙的な肯定応答を決定できることが理解されている。

【0265】

BATメッセージ61'の受信が失われた後で、第2の装置15は、BAT1(52-1)に関連付けられる構成データを使用することによって、メッセージ62'(ペイロードおよび/または制御データを搬送する)を送信する。BAT1(52-1)は現在無効である(しかし、第2の装置15は、BATメッセージ61'を受信していないことにより、BAT1が無効であることを認識していない)。したがって、無効なBATに基づいてメッセージ62'を受信することによって、第1の装置16は、第2の装置15がBATメッセージ61'を正しく受信していない(正しく受信していれば、メッセージ62'は有効な構成を有しているはずである)ことを理解することができる。

【0266】

この誤った認識を決定すると、第1の装置16は、有効性情報フィールド53において、BAT1(51-1)が無効であることを(再び)示すBATメッセージ61の新しいバージョン(ここではBATメッセージ61"として示される)を送信し、第2の装置15から第1の装置16への後続のDLメッセージのための構成情報を搬送する更新BAT情報フィールド54ならびにBAT更新情報フィールド55において、BAT2の現在の更新を送信し得る。反復的なBATメッセージ61"が第2の装置15によって正しく受信されて復号される場合、第2の装置15は、BATメッセージ61"において示されるようなBAT更新情報フィールド55において符号化されるBAT更新情報を用いてリスト50を更新する。

【0267】

したがって、第2の装置15から第1の装置16への後続のDLメッセージ62"は、BAT2(52-2)に関連付けられる構成データを利用し、第1の装置16によって正しく復号される。

【0268】

したがって、DLメッセージ62を送信するための第2の装置15によって、更新されたBATを使用することにより、固有の肯定応答が提供される。DLメッセージ62'は無効なBATに関連付けられる無効な構成データを使用した(したがって、第1のBATメッセージ61'の受信の暗黙的な否定応答を提供した)が、反復的なBATメッセージ61"の正しい受信およびコーディングの後にあるDLメッセージ62"におけるその使用は、正しい受信の暗黙的な肯定応答およびBATメッセージ61"の復号をもたらす。

【0269】

BATメッセージ61の後続の再送信(たとえば、61"、61'''など)は、(たとえば、後続のビーコン11'、11"などの受信に続いて)後で実行される。たとえば、第3のBATメッセージ61'''は、(ここでは掘り下げられない何らかの理由で)有効性情報フィールド53において、BAT2(51-2)が今は無効でありBAT1(51-1)が今は有効であることを示し、一方、更新BAT情報フィールド54は、BAT1(51-1)が今更新されることを示す(そして当然、BATメッセージ61'''の中のBAT更新情報フィールド55は、第2の装置15から第1の装置16に送信されるDL信号62に関連付けられる構成データを示す)。続いて、第2の装置15が第3のBATメッセージ61'''を正しく受信して復号する場合、第2の装置15は、BAT更新情報55において示される構成に従ってDLメッセージを送信する。

【0270】

いくつかの例では、
1)第1の装置16が
a.有効なBATおよび無効なBAT、ならびに
b.現在更新されるBAT
を決定し得ること、
2)一般に、第2の装置15が、すべてのアクティブBATの中から、デバイス16へのDL送信のために好ましいBATを選ぶことができる
3)第1の装置16が、第1の受信61から第2の装置15への暗黙的な肯定応答または否定応答を決定し得る
4)第2の装置15から第1の装置16への後続のDL送信の間に、第2の装置15が有効なBATのうちの1つを選ぶ
のうちの1つを備え得る規則を定義することが可能である。

【0271】

BATメッセージ61の例のフォーマットについてのより深い議論がここで与えられる(特に図8および図8bを参照されたい)。BATメッセージ61は、たとえば搬送する情報が可変であることの結果として、可変の長さを有し得る。

【0272】

有効性情報フィールド53は、たとえば、有効性情報ビットマップを含み得る。有効性情報ビットマップは、各ビット位置を1つの特定のBATに関連付け得る。24個のBATの場合、有効性情報ビットマップは24個のビット(たとえば、24個の後続のビット)を含み得る。各ビットは、たとえば有効性情報ビットマップにおけるビットの位置に従って、各BATに関連付けられ得る。たとえば、有効性情報ビットマップの最初のビット(ビット0)は、図8aのリスト50の最初のBAT51-0に関連付けられ得る。たとえば、有効性情報ビットマップの2番目のビット(ビット1)は、リスト50の2番目のBAT51-1に関連付けられ得る。有効性情報ビットマップの中の各ビット位置は特定のBATに関連付けられ得るが、ビットの値(1対0)はBATの有効性(たとえば、有効状態対無効状態)に関連付けられ得る。図8bの例では、有効性情報53を具現化する有効性情報ビットマップは、「0100010000000010000000000b」として表されてもよく、これは以下を意味する。

【0273】

【表5】

【0274】

有効性情報フィールド53をビットマップとして表現することによって、有効/無効なBATのあらゆる考えられる組合せに対して、有効性情報フィールド53の長さを常に確実に一定にすることが可能である。

【0275】

第2の通信装置15および第1の通信装置16は、有効性情報ビットマップにおけるBATの位置に基づいてBATの知識を共有し得る。有効性情報ビットマップにおける位置は、リスト50の中の各BAT51-0…51-23の識別子52に関連付けられ得る。この知識は、たとえばあらかじめ定められていてもよい(または、たとえばオフラインセッションにおいて構成されてもよい)。

【0276】

有効性情報ビットマップにおける順序がBATの識別子に厳密に対応することは常に必須ではない。第1の通信装置16および第2の通信装置15が、各有効性情報ビットマップにおける位置と特定のBAT(たとえば、BATの識別子および/またはリスト50におけるBATの位置)との間の関係の知識を共有することが重要である。

【0277】

例では、値「1」と「0」の意味は反転されてもよい。他の種類の記号が使用されてもよい。

【0278】

変形では、ビットマップではなく、他の技法を使用してもよい。符号化された値、リスト、アレイ、行列などを使用することが可能である。

【0279】

更新BAT情報フィールド54は、特定の更新BAT情報フィールドの中にあり得る。この場合、ビットマップの代わりに、好ましくは符号化されたフィールドが使用され得る。たとえば、24個の考えられるBATがある場合、5つのビットが使用され得る。たとえば、更新されたBATがBAT1(51-1)であることを示すために、更新BAT情報フィールドは「00001b」として符号化され得る。たとえば、更新されたBATがBAT14(51-14)であることを示すために、更新BAT情報フィールドは「01110b」として符号化され得る。

【0280】

この目的で、いくつかの符号化技法が使用され得る。ビッグエンディアンまたはリトルエンディアン表記、固定長または可変長などを使用することが可能である。「1」を「0」と交換しても、またはその逆を行っても、結果は変化しない。

【0281】

実際には、有効性情報フィールド53に対して、ビットマップが好ましいことがあるが、更新BAT情報54に対する符号化されたフィールドの使用は重要な利点を有する。すなわち、別のビットマップを使用する必要なく、5ビットでBATの識別子を簡単に符号化することが可能である。決定されていない数の有効/無効なBATが有効性情報フィールド53において示され得るが、1つだけの単独のBATが更新BAT情報フィールド54において示され得る(1つだけの単独のBATがBATメッセージ61の各送信に対して更新されるという事実の結果として)。(より一般的には、固定された数のBATが毎回更新され得る。)

【0282】

いくつかの例では、しかしながら、有効性情報フィールド53および更新BATフィールド情報54は、固定された量のビットを一緒に有する。たとえば、それらは24+5=29ビットを有し得る。

【0283】

BAT更新情報フィールド55は長さが可変であり得る。BAT更新情報フィールド55は、設備15によって送信されるべき信号62の構成(フォーマット)を示し得る。したがって、BAT更新情報フィールド55は、BATメッセージ61の直後に信号62を送信するときに第2の装置15によって使用されるべき物理レイヤパラメータを示し得る。

【0284】

BAT更新情報フィールド55は、たとえば、DLメッセージ61を送信するときに設備15によって使用されるべき前方誤り符号(FEC)情報55aを含み得る。異なるFEC方式が、符号化されたフィールドであり得るFEC情報フィールド55aにおいてインデクシングされ得る。FEC情報フィールド55aは、いくつかのビットで、たとえば7ビット(たとえば、フィールド55a'に対して3ビットおよび/またはフィールド55a"に対して4ビット)で符号化され得る。FEC情報55aを符号化するフィールドの長さは一定であり得る。FEC情報フィールド55aは、使用される具体的なFEC方式を示し得る。たとえば、1/2、2/3、5/6、16/18、20/21として知られているコードレート(CR)、ブロックサイズ(BS)960、4320などのうちの1つが選択され得る。いくつかの例では(たとえば、図8bでは)、FEC情報フィールド55aは、FECブロックサイズフィールド55a'(たとえば、信号62を送信するときに使用されるべきFECブロックのサイズを示す)、および/またはFECコードレート情報フィールド55a"(たとえば、使用されるべき具体的なコードレートを示す)へと分割され得る。FEC方式が第1の通信装置16によって選択されると、第2の通信装置15は、DLメッセージ62を送信するためにそれを使用する。大まかに言えば、FEC方式は、冗長性をメッセージ62にもたらし、何らかの値(たとえば、不正確に復号されたビットなど)を読み取る際の考えられるエラーに耐えることを可能にする。

【0285】

BAT更新情報フィールド55は、たとえば、サブキャリアの異なるグループに関する情報フィールド55bを含み得る。情報フィールド55bは、更新されたBATに割り当てられるサブキャリアを示し得る。サブキャリアは、(たとえば、周波数などの特定の値に従って、または任意の他の考えられるインデクシングに従って)インデクシングされてもよく、それらのインデックスに従ってグループ化されてもよい。したがって、第1の通信装置16および第2の通信装置15は、サブキャリア0(既知の周波数における)、サブキャリア1、サブキャリア2、…最後のサブキャリアまで、という考え方を共有し得る。

【0286】

したがって、情報フィールド55bは、複数のグループ情報フィールド55b'、55b"などへと再分割され得る。各グループ情報フィールド55b'は、サブキャリアの特定のグループを参照し得る。

【0287】

各グループ情報フィールド55b'(または55b")に対して、サブキャリアグループ化情報フィールド55c'(または55c")が定義され得る。このサブキャリアグループ化情報フィールド55c'は、どのサブキャリアが特定のグループの一部であるかについての情報である。たとえば、第1のサブキャリアグループ化情報フィールド55c'は、128個のサブキャリアがグループ1の一部であることを示す。これらの128個のサブキャリアは、それらのインデックスによっても識別され得る(それらはインデックスが小さい方から128個のサブキャリアである)。第2のサブキャリアグループ化情報フィールド55c"は、512個のサブキャリアがグループ2の一部であることを示し得る。これらの512個のサブキャリア(少なくとも、それらの中で既存のもの)も、それらのインデックスによって識別され得る(それらは129番目のサブキャリアから開始し、漸進的に続く)。したがって、各グループはサブキャリアの間隔から構成されてもよく、間隔はサブキャリアのインデックスに従って定義される。

【0288】

サブキャリアグループ化情報フィールド55d'および55d"において示される各グループ(たとえば、1、2)に対して、ビットローディング情報が提供される(たとえば、どれだけのビットがグループの各サブキャリアに対してロードされるべきであるか)。(この情報は、第1の通信装置16の決定に基づいて提供されてもよく、たとえば、最初の128個のサブキャリアのノイズがより少なくより送信が良好であるという決定に従ってもよく、このことは、たとえばビーコン11が受信されたときに測定される)。

【0289】

各グループに対して、第1の装置(たとえば、デバイス)16は、あらかじめ定められた限られた数のグループ化の中から選んでもよく(たとえば、各グループに対して、サブキャリアの数は、1、2、4、8、16、32、64、128、256、512、1024、2048、または4096の中から選ばれ得る)、この数は4ビットで特定され得る。したがって、各サブキャリアグループ化情報フィールド55c'は4ビットのフィールドにおいて符号化されてもよく、フィールドが「0000b」を符号化する場合、グループは1つだけの単独のサブキャリアを有し、フィールドが「0001b」を符号化する場合、グループは2つのサブキャリアを有し、フィールドが「0110b」を符号化する場合、グループは4096個のサブキャリアを有する、などである。

【0290】

各グループに対して、ロードされるビットの数は、固定された数のビットの中から選ばれ得る。たとえば、各サブキャリアは、0…12ビットをロードされ得る(そして、これは同じグループのすべてのサブキャリアに対して有効である)。したがって、ロードビット情報フィールド55d'(および55d")は、固定された数のビット(たとえば、4ビット)で符号化され得る。

【0291】

したがって、各グループに対して、各グループ情報フィールド55b'は、固定された数のビット(たとえば、情報55c'または55c"を符号化するために4ビット、および情報55d'または55d"を符号化するために4ビット)で符号化され得る。

【0292】

しかしながら、サブキャリアの異なるグループに関するグループ情報フィールド55bの長さ(時間長)は、一般に可変であり得る。これは、第1の装置16が一般に、グループのいずれに従ってもサブキャリアを自由に再分割できるからである。図8bの例では、2つの異なるグループ1および2が定義されるが、第1の装置16は、異なるグループを定義することが可能である。例を与えると、フィールド55c'において、選択が「128個のサブキャリア」ではなく「1個のサブキャリア」であった場合、これは、グループ1が1つの単独のサブキャリアを有することになることを意味する。第1の装置16は、同じ残りの127個のサブキャリアに対して、他のグループを自由に定義できる(たとえば、他の127個の単一サブキャリアのグループ、または63個の2キャリアのグループ+1個の単一キャリアグループなど)。その場合、情報55bの長さは、グループの各々に対して1つのグループ情報55b'を定義する結果として、はるかに大きくなるであろう。

【0293】

BATメッセージ61は、最後のグループ情報の末尾(たとえば、図8bのフィールド55b"の後)に、BATメッセージ61の末尾を決定することを可能にし得るend-of-frameシーケンスのようなものを有し得ることが予想され得る。このシーケンスは、価値のある情報を提供せずに、BATメッセージ61の時間長を増やす。

【0294】

しかしながら、デバイス16および設備15によって共有される情報による知識、たとえばサブキャリアの数に基づいてBATメッセージ61の末尾を決定することを可能にする、特に有効な技法を採用することが可能であることが理解されている。サブキャリアは数が限られている(これはデバイス16と設備15の両方によって知られている)ので、グループ化についての情報は、BATメッセージ61の末尾を決定することを可能にし得る。たとえば、サブキャリアが640個である場合、BATメッセージ61は第2のグループ情報55b"の後で完了し(グループ1は128個のサブキャリアを有し、第2のグループは512個のサブキャリアを有し、128+512=640)、データを符号化し続ける意味はない。たとえば、サブキャリアが630個である場合、グループ2は(符号化された情報55c"によって512個のサブキャリアを有するものとして示されていても)、502個のサブキャリアしか有しない。

【0295】

例:
BAT Request要素(たとえば、図5および図5bのBATメッセージ61)が、将来の送信機から何らかのビットローディングおよびエラーコーディング方式の使用を要求するために、HB-PHYを使用する受信デバイス16によって使用され得る。
Valid BAT Bitmap(有効性情報53):有効であることが要求されるBATを指定する。ビットマップの最初のビットはBAT ID 8に対応するが、最後の(すなわち、一番右の)ビットはBAT ID 31に対応する。1に設定されたビットはBATが有効であることを示し、0はBATが無効であること、すなわち送信機によりこれ以上使用されるべきではないことを示す。
Updated BAT(更新BAT情報54):更新されるべき、ランタイム定義されるBATのIDを指定する。値8-31のみが許可される。値0は、新しいBATが更新されないことを示す。これは、有効性情報のみがBAT Request要素においてシグナリングされる場合に当てはまり得る。値1-7は予約されている。
FEC Block Size(55a'):
FEC Code Rate:要求されるFECコーディングレートを指定する。
BAT Group 1…N:サブキャリアのn番目のグループに対する変調を記述するBAT Group要素。すべてのサブキャリアをカバーするのに十分なグループがあるものとする。最後のグループはサブキャリアの残りの数より広くてもよい。それらの過剰なサブキャリアに対する要求される変調は無視されるものとする。
BAT Group要素(55b'、55b"など)は、ビットローディング可能なPHY送信において同じ数のビットがロードされている、隣接するサブキャリアのグループについての情報を含む。
BAT Group要素は、ビットローディング可能なPHY送信において同じ数のビットがロードされている、隣接するサブキャリアのグループについての情報を含む。
BAT Group要素の構造は図に示されている。これは、以下のフィールドを有する:
Grouping:このフィールドは、このグループの中のサブキャリアの数を含む。有効な値は次の通りである。
1,2,4,8,16,32,64,128,256,512,1024,2048,4096
Loaded Bits:グループの各サブキャリアにロードされるビットの数。有効な値は次の通りである。
0,1,2,3,4,5,6,7,8,9,10,11,12

【0296】

上では、有効性情報は有効性情報フィールド53によって具現化されるものとして、更新BAT情報は更新BAT情報フィールド54によって具現化されるものとして、およびBAT更新情報はBAT更新情報フィールド55によって具現化されるものとして言及された。しかしながら、いくつかの例では、これは厳密に必要とはされない。いくつかの例では、有効性情報フィールド53はBATメッセージ61に存在しなくてもよいが、有効性情報は、たとえば更新BAT情報フィールド54から導出されてもよい。いくつかの例では、更新BAT情報フィールド54はBATメッセージ61に存在しなくてもよいが、更新BAT情報は、たとえば有効性情報フィールド53から導出されてもよい。

【0297】

信号62は、ペイロードおよび/またはシグナリングを搬送する信号であり得る。いくつかの例では、信号62は、信号33、33b、700などのいずれかによって具現化され得る。

【0298】

上の例では、いくつかの態様は、ビット割振りテーブル(BAT)メッセージを[たとえば、通信設備に]送信するように構成される、[たとえば、光通信を実行するための]通信デバイス[たとえば、通信設備と通信するための、たとえばユーザ機器、たとえばモバイルデバイス、通信デバイスは、たとえば基地局(BS)または調整器である]に関し、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効である[たとえば、通信デバイスにデータを送信するためにBSまたは調整器によって使用可能である]かをシグナリングする有効性情報[たとえば図8bの例において「Valid BAT」として示されている、たとえばビットマップ][いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]、および/または
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報[たとえば、図8bの例において「Updated BAT」として示される]、および/または
更新されるものとしてシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]
を備える。

【0299】

上の例では、いくつかの態様は、ビット割振りテーブル(BAT)メッセージ[これは、複数のBATのうちのどの1つまたは複数のBATが有効であるかをシグナリングする有効性情報、たとえば図8bの例において「Valid BAT」として示されている、たとえばビットマップを備え得る][たとえば、BSまたは調整器によって使用可能である]を[たとえば、通信設備に][たとえば、通信デバイスにデータを送信するための通信設備に]送信する[いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]ように構成される、[たとえば、光通信を実行するための]通信デバイス[たとえば、通信設備と通信するための、たとえばユーザ機器、たとえばモバイルデバイス、通信デバイスは、たとえば基地局(BS)または調整器である]に関し、BATメッセージは、
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報[たとえば、図8bの例では「Updated BAT」として示される]、
[任意選択で、更新されるものとしてシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報、たとえば、図8bの例では最後の5つのフィールド]
を含み、通信デバイスは、
[たとえば、通信設備からの]確認を予想し、確認が、更新されたBATに従ったビット割振りの使用から導かれ、および/または、通信設備からの有効性確認を受信しない場合、BATメッセージを再送信する
ように構成される。

【0300】

通信デバイスはさらに、
複数のBATのうちの1つまたは複数のBATが有効である[たとえば、通信デバイスにデータを送信するためにBSまたは調整器によって使用可能である]かをシグナリングする有効性情報[たとえば図8bの例において「Valid BAT」として示されている、たとえばビットマップ][いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]、および/または
更新されるものとしてシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]
を備えるBATメッセージからなり得る。

【0301】

通信デバイスがさらに構成されてもよく、BATメッセージの長さは可変である。

【0302】

通信デバイスがさらに構成されてもよく、サブキャリアの異なるグループに関するBATメッセージグループ情報[グループ当たりのサブキャリアの数はグループごとに異なり得る][たとえば、BATメッセージは、複数のグループに対して、どれだけのサブキャリアをそれぞれのグループが備えるか、および/またはどれだけのビットがそれぞれのグループのサブキャリアにロードされるかについての情報を備え得る]。

【0303】

通信デバイスは、無効であるものとして以前にシグナリングされたBATを選択的に更新するように構成され得る。

【0304】

通信デバイスは、有効であるものとして以前にシグナリングされたBATを更新するのを控えるように構成され得る。

【0305】

通信デバイスは、[たとえば、図8cにおいて示されるような]通信設備からの確認を予想するように構成されてもよく、確認は、更新されたBATに従ったビット割振りの使用から導かれる。

【0306】

通信デバイスは、通信設備からの有効な確認を受信しない場合、BATメッセージを再送信するように構成され得る。

【0307】

通信デバイスは、通信設備からの受信において、有効であるものとして示されるBATのうちの1つを使用した送信を予想するように構成され得る。

【0308】

通信デバイスは、BATメッセージの中の情報を[たとえばビーコンメッセージから、たとえば決定されるような]チャネル条件についてのフィードバックに基づくものにするように構成され得る。

【0309】

通信デバイスが構成されてもよく、BAT更新情報は前方誤り訂正(FEC)情報を含む[たとえば、通信設備から送信されることになるデータに対する、要求される冗長性の期待値に関する情報を含む]。

【0310】

上の例では、いくつかの態様は、通信デバイス[たとえばネットワークの一部であり得る、たとえばユーザ機器、たとえばモバイルデバイス]からビット割振りテーブル(BAT)メッセージを受信するように構成される通信設備[たとえば、基地局(BS)または調整器][たとえば、光通信設備][たとえば、複数の通信デバイスを伴うワイヤレスネットワークのための]に関し、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効である[たとえば、通信デバイスにデータを送信するために通信設備によって使用可能である]かをシグナリングする有効性情報[たとえば図8bの例において「Valid BAT」として示されている、たとえばビットマップ][いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]、および/または
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報[たとえば、図8bの例において「Updated BAT」として示される]、および/または
更新されるものとしてシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]
を備える。

【0311】

上の例では、いくつかの態様は、通信デバイス[たとえばネットワークの一部であり得る、たとえばユーザ機器、たとえばモバイルデバイス]からビット割振りテーブル(BAT)メッセージを受信するように構成される通信設備[たとえば、基地局(BS)または調整器][たとえば、光通信設備][たとえば、複数の通信デバイスを伴うワイヤレスネットワークのための]に関し、BATメッセージは、
[任意選択:複数のBATのうちのどの1つまたは複数のBATが有効であるか、たとえば、通信デバイスにデータを送信するために通信設備によって使用可能であるかをたとえばシグナリングし、いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする、有効性情報、たとえば図8bの例において「Valid BAT」として示されるような、たとえばビットマップ]、および/または
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報[たとえば、図8bの例において「Updated BAT」として示される]、および/または
[任意選択:更新されるようにシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]]
を備え、通信設備は、
確認を[たとえば、通信デバイスに]送信するように構成され、確認は、更新されたBATに従ったビット割振りの使用から導かれる。

【0312】

通信設備が構成されてもよく、ビット割振りテーブル(BAT)メッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効である[たとえば、通信デバイスにデータを送信するために通信設備によって使用可能である]かをシグナリングする有効性情報[たとえば、図8bの例において「Valid BAT」として示されている、たとえばビットマップ][いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]、および/または
更新されるものとしてシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]
を備える。

【0313】

通信設備が構成されてもよく、BATメッセージの長さは可変である。

【0314】

通信設備が構成されてもよく、サブキャリアの異なるグループに関するBATメッセージグループ情報[グループ当たりのサブキャリアの数はグループごとに異なり得る]。

【0315】

通信設備が構成されてもよく、無効であるものとして以前にシグナリングされたBATが選択的に更新され得る。

【0316】

通信設備が構成されてもよく、有効であるものとして以前にシグナリングされたBATを更新することはできない。

【0317】

通信デバイスは、[たとえば、図8cの図において示されるような]通信デバイスに確認を送信するように構成されてもよく、確認は、更新されたBATに従ったビット割振りの使用から導かれる。

【0318】

通信設備は、通信デバイスに、有効であるものとして示されるBATのうちの1つを使用した送信を送信するように構成され得る。

【0319】

通信設備が構成されてもよく、BATメッセージの中の情報は、[たとえばビーコンメッセージから、たとえば決定されるような]チャネル条件についてのフィードバックに基づく。

【0320】

通信設備が構成されてもよく、BAT更新情報は前方誤り訂正(FEC)情報を含む[たとえば、通信設備から送信されることになるデータに対する、要求される冗長性の期待値に関する情報を含む]。

【0321】

上の例では、いくつかの態様は、[たとえば、光通信を実行するための]通信デバイス[たとえばユーザ機器、たとえばモバイルデバイス]と通信設備[たとえば、基地局(BS)または調整器]との間の通信[たとえばワイヤレス通信、たとえば光通信]に関し、方法は、ビット割振りテーブル(BAT)メッセージを[たとえば、通信デバイスから通信設備に]送信するステップを含み、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効である[たとえば、通信デバイスにデータを送信するためにBSまたは調整器によって使用可能である]かをシグナリングする有効性情報[たとえば図8bの例において「Valid BAT」として示されている、たとえばビットマップ][いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]、および/または
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報[たとえば、図8bの例において「Updated BAT」として示される]、および/または
更新されるものとしてシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]
を備える。

【0322】

上の例では、いくつかの態様は、[たとえば、光通信を実行するための]通信デバイス[たとえばユーザ機器、たとえばモバイルデバイス]と通信設備[たとえば、基地局(BS)または調整器]との間の通信[たとえばワイヤレス通信、たとえば光通信]のための方法に関し、方法は、ビット割振りテーブル(BAT)メッセージを[たとえば、通信デバイスから通信設備に]送信するステップを含み、BATメッセージは、
[任意選択:複数のBATのうちのどの1つまたは複数のBATが有効であるか、たとえば、通信デバイスにデータを送信するためにBSまたは調整器によって使用可能であるかをたとえばシグナリングし、いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする、有効性情報、たとえば図8bの例において「Valid BAT」として示されるような、たとえばビットマップ]、および/または
複数のBATのうちのどのBATが更新されるべきであるかをシグナリングする更新BAT情報[たとえば、図8bの例において「Updated BAT」として示される]、および/または
[任意選択:更新されるようにシグナリングされるBATを更新するための更新情報をたとえばシグナリングする、BAT更新情報、たとえば図8bの例における最後の5つのフィールド]
を備え、方法はさらに、
通信設備から通信デバイスに、確認を送信するステップであって、確認が、更新されたBATに従ったビット割振りの使用から導かれる、ステップ、および/または、
[たとえば、所定の閾値以内に]通信設備から有効な確認を通信デバイスが受信しない場合、通信デバイスから通信設備にBATメッセージを再送信するステップと
を備える。

【0323】

方法はさらに、ビット割振りテーブル(BAT)メッセージからなっていてもよく、BATメッセージは、
複数のBATのうちのどの1つまたは複数のBATが有効である[たとえば、通信デバイスにデータを送信するためにBSまたは調整器によって使用可能である]かをシグナリングする有効性情報[たとえば図8bの例において「Valid BAT」として示されている、たとえばビットマップ][いくつかの例では、複数のBATのうちのどの1つまたは複数のBATが有効ではないかもシグナリングする]、および/または
更新されるようにシグナリングされるBATを更新するための更新情報をシグナリングするBAT更新情報[たとえば、図8bの例における最後の5つのフィールド]
を備える。

【0324】

方法はさらに、機器を使用して構成され得る。

【0325】

上の例では、いくつかの態様は、プロセッサによって実行されると、プロセッサに方法を実行させる情報を記憶する、非一時的記憶ユニットに関する。

【0326】

上の例では、いくつかの態様は、通信設備および通信デバイスを備えるシステムに関する。

【0327】

上の説明はとりわけ、たとえばスター型トポロジにおける分散した光フロントエンドおよび/またはMIMO技法をサポートするための、手順およびフレームタイプの例を含む。例が下で論じられる。

【0328】

分散した光フロントエンド(OFE)手法の目標:
信号レベルでの空間ダイバーシティの導入、および/または
円滑なハンドオーバー性能と高いQoSを伴った空間再使用を可能にすること、および/または
低レベルの「ソフトハンドオーバー」:管理プロトコルに対して完全に透過的である、デバイスの移動に従ったOFE形式の仮想セル。2つのデバイスに同時にサービスする分散したOFEを伴うスター型トポロジにおける調整器を示すものとして理解され得る、図1を参照されたい。

【0329】

空間再使用およびジョイント送信+受信のためのスーパーフレーム構造:
CAPにおけるキャリア検知を伴わないスロット化アップリンクランダムアクセス(ALOHA)。アソシエーションおよび再接続だけに対して、コリジョンが発生し得る;ならびに/または
通常のコリジョンフリー送信のための、およびCFPにおける、デバイスごとのGTS割振り;ならびに/または
同じスーパーフレームスロットにおいて、しかし異なるOFEスロットにおいて割り振られる異なるGTS(SDMA);ならびに/または
GTSが複数のOFEスロットにまたがり、これは、ジョイント送信/受信のための「仮想セル」を示唆する。図2を参照されたい。

【0330】

チャネル推定、CSIフィードバック、およびGTS更新:
マルチセルチャネル推定は、ビーコンの中のマルチセルパイロットに基づく。個々の仮想セル送信に対して、追加の望まれるBATまたはMCSフィードバックが生成され得る;および/または
調整器がフィードバックに基づいてGTSをスケジューリングし、適応的な送信を選択する;および/または
動的なGTSは、制御フレームを介して更新され、有効性=0の場合は次のスーパーフレームの間、それ以外の場合は複数のスーパーフレームの間、有効である。以前の動的なGTSの割振りは有効性を失う。GTS更新は次のフィードバックフレームにおいて肯定応答される。図3を参照されたい。

【0331】

マルチセルチャネル推定フィードバック:
タップに対する可変の分解能の設定のためのTAPフォーマット;および/または
パイロット/OFE識別のためのシンボル(1-7)+分割(1-32);および/または
第1のタップの強度はSNR[dB]である;および/または
他のTAPに対して、それは第1のTAPと現在のTAPとの比[dB]である;および/または
第1のOFE/TAPは最も遅延が小さいものである。

【0332】

適応ビットローディングフィードバック:要求されるBAT制御フレームフォーマット:
有効BATビットマップは、BAT要求フレームの送信者に向かう受信者からの送信のための24個のランタイムBATの各々の適用可能性を示す;および/または
「Updated BAT」フィールドは、更新されるものとする要求されるBATフレームの送信者に向かう受信者からの送信のためのBATを示す;および/または
すべてのランタイムBATが無効である場合、フレームは0の2オクテットのみを含む;および/または
FEC方式:コードレート(CR)1/2、2/3、5/6、16/18、20/21、&ブロックサイズ(BS)960、4320;および/または
グループ化:1,2,4,8,16,32,64,128,256,512,1024,2048,4096
ロードされるビット:1,2,4,8,9,10,11,12
に基づいて異なる数のビットをロードするためのサブキャリアのグループのリスト
最後のグループはPHYに存在するサブキャリアの実際の数を超えるグループである。図5を参照されたい。

【0333】

適応ビットローディングフィードバックプロトコル:
チャネルが変化し、以前有効であったBATが使用不可能になるとき、新しいBATが設定される(「更新される」)。古いBATは無効であるとマークされる;および/または
更新におけるBAT IDの再使用は、更新されるBAT IDが以前に無効であった場合にのみ許可される。更新されるBAT IDは有効であるとマークされなければならない;および/または
要求されるBATフレームの受信は、要求されるBATフレームの送信者に向かう送信に対する最新の更新されるBATを使用することによって受信者により確認される;および/または
要求されるBATフレームの喪失は、後続の受信における無効なBAT IDの使用を通じて除去され得る

【0334】

要求されるBATフレームの例:
512個のサブキャリアを伴うHB-PHYのための要求されるBATフレームの例;および/または
ここでは、BAT1、5および14だけが、要求されるBATフレームの送信者に向かう送信のために使用され得ることが示される;および/または
BAT1は、所与のFECのために、ならびに、8ビットおよび6ビットをそれぞれロードされたサブキャリアの2つのグループのために更新される;および/または
要求されるBATフレームの受信者は、実際の数よりも多くのサブキャリアを指定するので、サブキャリアの第2のグループが最後のグループであることを知っている;および/または
第2のグループの過剰なサブキャリアは無視されて変調されない。図5bを参照されたい。

【0335】

適応変調およびコーディングフィードバック:
特定のMCSの使用を要求するために送信される要求されるMCS制御フレーム;および/または
要求されるBATフレームに対するものと同じ手順、しかしMCSが要求される;および/または
送信機が正しいMCSを適用しないとき、制御フレームが繰り返される。

【0336】

動的なGTS記述子:
規格にすでに存在するような、GTS更新フレームを介したまたはビーコンフレームを介したGTS割振り;および/または
有効性フィールドは、GTSがその中で有効であるスーパーフレームの数を指定する;および/または
最初の適用されるGTS方向のみが考慮される。余剰のビットは無視される。図7aおよび図7bを参照されたい。

【0337】

スーパーフレームの例:
新しいデバイス、または接続を失いGTSを割り振られていないデバイスが、CAPにおいてアソシエーション要求および再接続フィードバックフレームを送信することができる;および/または
制御送信、管理送信、およびデータ送信のすべてがCFPの中のGTSにおいて実行される。

【0338】

さらなる例
ここで、上の態様のいずれかに関連付けられ得る、複数の光フロントエンドに対するMACレイヤサポートに言及する。

【0339】

このセクションは、とりわけ、スター型トポロジにおいて分散した光フロントエンドおよびMIMO技術をサポートするために必要な、プロトコル手順およびフレームタイプの態様に対する提案を含む。

【0340】

分散した光フロントエンド(OFE)手法の目標:
信号レベルでの空間ダイバーシティの導入
円滑なハンドオーバー性能と高いQoSを伴った空間再使用を可能にする
低レベルの「ソフトハンドオーバー」:ネットワークレイヤに対して完全に透過的である、デバイスの移動に従ったOFE形式の仮想セル
図1:2つのデバイスに同時にサービスする分散したOFEを伴うスター型トポロジにおける調整器

【0341】

フロントホール技術および機能分割:
調整器のPHYはフロントホールを介してOFEと接続される
フロントホールの実装形態は範囲外である
アナログフロントホールは、単純な同軸ケーブル、またはアナログ信号のファイバー伝送であり得る
デジタルフロントホールは、デジタル化された波形サンプル(CPRI)の伝送であり得る
モバイルネットワークにおいて「新しい機能分割」としても論じられるような、信号チェーン機能の分割は範囲外である
デジタルフロントホール伝送技術は、現在モバイルネットワークの分野で研究中であり、以下の異なる標準化活動において要件が定義されている:
eCPRI
IEEE 802.1CM

【0342】

フロントホール遅延:
フロントホールは伝播遅延を仮想的に増やす。オーダーは最大で100μsである。
フロントホール遅延t_Fは、すべてのOFEに対して知られており概ね同じでなければならない。
アナログフロントホール遅延は伝播遅延の一部である。
デジタルフロントホールのための適切な同期技法はIEEE 1588v2(PTP)である。各OFEにおけるMACフレームの開始は、各OFEにおけるPTPスレーブから取得され得る。
そのような技法が利用可能ではない場合、独自の手法が考慮され得る。
異なるOFEにおけるエアタイム間の残りの遅延差分は非常に小さくなければならず、すなわち、巡回プレフィックス長の1/2を大きく下回らなければならない。

【0343】

複数のOFEのPHYサポート(図6参照):
調整器のPHYは、複数の送信および受信チェーン(TRXチェーン)とOFEのための複数のポート(OFEポート)とを有する。
PD-SAPを介したPSDUごとのTX構成
どのOFEで送信すべきか
(任意選択でクロック周期における)OFEごとの遅延差分補償
PLME-SAPを通じたRX構成
アップリンクにおいて組み合わせるための仮想セルの中のOFEのグループ
フロントホール遅延は各OFEに対して一定である
MACレイヤは上で説明されたようにこの値を補償しなければならない

【0344】

空間再使用およびジョイント送信+受信のためのスーパーフレーム構造:
CAPにおけるキャリア検知を伴わないスロット化アップリンクランダムアクセス。アソシエーションおよび再接続だけに対して、コリジョンが発生し得る。
CFPにおける通常の送信と受信のためのデバイスごとのGTS割振り。
同じスーパーフレームスロットにおいて、しかし異なるOFEスロットにおいて割り振られる異なるGTS(SDMA)。
GTSが複数のOFEスロットにまたがり、これは、ジョイント送信/受信のための「仮想セル」を示唆する。

【0345】

動的なGTS:
同じスーパーフレームスロットが異なるデバイスのGTSにおいて「再使用」される場合(空間多重化)、そのようなGTSを伴うデバイスが互いに近づくと、移動がフレームのコリジョンにつながり得る。
したがって、GTSの割振りは移動に高速に適応しなければならない。
管理フレームを介した既存の準静的なGTS割振り機構を維持する(5.1.10およびD3の付録G)
提案:いわゆる動的なGTSは、準静的なGTSの割振りに加えて、制御フレームを介して調整器によってデバイスに割り当てられ得る。
動的なGTSは、指定された数のスーパーフレームに対してのみ有効であり、その後で使用されないものとする。
準静的なGTSは、管理プロトコルを介して割振り解除されない限り有効である。

【0346】

動的なGTS記述子:
動的なGTS記述子は制御フレームを介して送信される。
動的なGTS記述子は、準静的なGTS記述子と類似しているが、デバイスアドレスを有せず、Validityフィールドを含む。
動的なGTS記述子のValidityフィールドは、動的なGTSが割り当てられるスーパーフレームの数を含み得る。
GTSリストに対するテーブルを追加する。

【0347】

アソシエーションおよび再接続(たとえば、態様IIに関する;図3aも参照されたい):
調整器12との接続を失いGTSを割り振られていない新しいデバイス16は、CAP11aにおいてアソシエーション要求および再接続フィードバックフレーム35を送信することができる。
提案:CAP送信:複数のスーパーフレームスロットを含むマクロスロットの中のスロット化Aloha、スーパーフレームスロットは各々フレーム全体を保持することができる。
提案:推定されるダウンリンクCSIがランダムアクセスフレームに含まれる

【0348】

チャネル推定、CSIフィードバック(たとえば、32、32b、35)、およびGTS更新:
チャネル推定はビーコン11の中のマルチセルパイロットに基づき得る。CSIフィードバック(たとえば、32、32b、35)は通常、GTSの中の制御フレームを介して送信され得る。
調整器12は、CSIフィードバックに基づいてGTS割振りを動的に更新し得る。
動的なGTSは、制御フレームを介して更新され、有効性=0である場合には次のスーパーフレームの間、それ以外の場合には複数のスーパーフレームの間有効であり得る。例では、以前の動的なGTS割振りは有効性を失う。GTS更新は次のフィードバックフレームにおいて肯定応答され得る。

【0349】

態様III(上を参照されたい)および図1aがここで特に参照される。分散した光フロントエンドを伴うMU MIMO:
単一の調整器を伴う複数の分散した光フロントエンド(OFE)をMU-MIMOシステムとして使用すること
複数のOFEに対する遅延差分補償
MU MIMOのための制御シグナリング
遅延差分:例
たとえばPTPを使用したイーサネットを介した、デジタルフロントホールを想定する
光ネットワークは小さく、たとえば、10-100m*5ns/m=50-500nsのフロントホール遅延である
PTP=Precision time protocol IEEE 1588v2
PTPパケットは高い優先度を得て、静止シナリオ^1,2では正確さは<<1μsである
フロントホール+伝播遅延+PTPの正確さ<長いCPまたは同期シーケンス長
LB PHY@32MHz:CP=160サンプル*31.25ns=4.8μs
HB PHY:CP=1.28μs
PM PHY@200MHz:同期シーケンス長=384サンプル*5ns=1.92μs
明らかに、すべての遅延を合わせても長いCP/同期シーケンス長より短い
高精度のフロントホール整列がover the airで達成され得る
(L. Cosart、「Precision Packet Delay Measurements Using IEEE 1588v2」、2007 IEEE Int. Symp. on Precision Clock Synchronization for Measurement、Control and Communication、ウィーン、2007年、pp.85-91も参照されたい。R. L. Scheiterer、C. Na, D. Obradovic、G. Steindl, F.-J. Goetz、「Synchronization Performance of the Precision Time Protocol in the Face of Slave Clock Frequency Drift」、4th IEEE Conference on Automation Science and Engineering、Key Bridge Marriott、米国ワシントンDC、2008年8月23日～26日も参照されたい)
遅延差分補償:問題(図1aも参照されたい):
光フロントエンド(OFE)は時間が揃っていなければならない
フロントホールプロトコルは、もしあれば、OWCに対して透過的である
フロントホールはアナログまたはデジタルであるが、何らかの遅延を示唆する
調整器は各OFEにおける残りの遅延差分を補償する
状況:
システムがオンにされる
たとえば、PTPが適用される
各OFEにおいて個々の時間誤差t_F1、t_F2、t_F3がある
各OFEからの個々の伝播遅延t_P1、t_P2、t_P3がある
全体の遅延の広がりは1μs未満である
時間整列:提案される解決法:
提案される解決法:
over the airで個々の遅延差分を測定する
遅延差分について調整器に知らせる
それらを各OFEにおける可変のFIFO遅延バッファを用いて訂正する
提案:
ビーコンが、チャネル推定、ヘッダ、任意選択のフィールド、およびペイロードに対する十分に長いCPを使用する
ビーコンが任意選択のフィールドにおけるMIMOに対する直交シーケンスを含む
デバイスがすべてのOFEに対するマルチセルチャネル推定を実行する
デバイスがアソシエーション要求(CSIフィードバック)においてすべての可視のOFEに対するCIRを送信する
調整器がそれに従って各OFEにおける遅延差分を訂正する
ダウンリンクMIMO動作:
ビーコンがすべてのOFEを介して一緒に送信される
遅延差分測定がMIMO基準信号を使用してサポートされる
OFEが異なるMIMO基準信号によって識別される
デバイスが各OFEに対するマルチセルチャネル推定を実行する
デバイスが可視のOFEごとにチャネル状態情報(CSI)のフィードバックを調整器に提供し、CSIは大幅に圧縮され得る(以下も参照されたい)
調整器が各OFEにおいて遅延差分補償を適用する
適応CSIフィードバック圧縮:
可視のOFEを選択する
チャネルを周波数領域から時間領域に変換する→CIRを再構築する
ノイズおよび干渉に依存する閾値に基づいてノンゼロタップを選択する
各ノンゼロタップの振幅を量子化する
固定量子化または可変量子化を使用し、変数はSINRに依存する
MIMO CSIフィードバックフォーマット:
すべての可視のOFEに対する時間領域フィードバック
各タップ振幅に対して、適応量子化が使用される(固定され得る)
インパルス応答フィードバックフォーマット³:
OFE indexはソースOFEを表す
Step sizeおよびquant. bitsは適応量子化を記述する
Delay vectorはビットマップであり、l番目のタップが0ではない場合位置lにおいて1であり、それ以外の場合0である
L=sum(Delay vector)はCIRにおけるノンゼロタップの数である
Tapsは、Bビットの深度で量子化されたL個のタップの振幅を含む
適応ビットローディング:
適応ビットローディングはHB OFDM PHYと一緒に使用される。
ランタイムビット割振りテーブル(BAT)はMACによってネゴシエートされる。
デバイスは、サブキャリア固有のSNR値を測定し、サブキャリアまたはサブキャリアグループ当たりのビットの数を含む望ましいBATを計算する。
望ましいBATは、望ましいBAT制御メッセージを介して、すなわちチャネルが変更される場合、調整器にフィードバックされる。
調整器は、望ましいBATが使用されるか、または別のBATが使用されるかを決定する。
調整器は、付与されたBAT制御メッセージを使用してデバイスに知らせる。
あらかじめ定められたBATとランタイムBATとの高速な切り替えのために、PHYヘッダは復調に必要なBAT IDを含む。
適応ビットローディング:手順:
基本的なBAT維持手順:
デバイスがサポートできるBATをデバイスが定期的に更新する
デバイスまたは調整器によって手順が開始され得る
各プリアンブルフレームにおいて、またはデバイスによる要求の後で、調整器がチャネル推定シンボルを送信する
説明されたようなネゴシエーション
望ましいBATフォーマット:
含まれる情報:
更新されるべきBAT ID
1、2、4、8、16のグループにおけるサブキャリアのグループ
有効なBAT ID
FECブロックサイズ
FECコードレート
最低のロードされるサブキャリア(グループ)
最高のロードされるサブキャリア(グループ)
サブキャリア(グループ)当たりのロードされるビット
フレームフォーマットが後に続く

【0350】

他の態様
Wireless specialty networks
1.1 範囲
1.2 目的

【0351】

2 説明
本セクションにおいて論じられる概念は、たとえば、光学的または非光学的であり得るワイヤレスリンクを通じて通信している、第1の装置16および/または第2の装置15を伴うシステムに一般化され得る。ここで論じられる概念は、上で論じられた他の概念と奇妙にも組み合わせられ得る。光フロントエンド(OFE)の代わりに、より一般的に、フロントエンド(たとえば、ワイヤレスフロントエンド)と呼ぶことが可能である。OWPANの代わりに、ネットワーク(たとえば、光ネットワークなどのワイヤレスネットワーク)への言及が行われ得る。

【0352】

3 定義、頭字語、および略語
3.1 定義
この項は、本開示全体で使用される用語を列挙する。それぞれの用語は太字で印刷されている。定義はコロンの後に与えられる。用語が同義語、すなわち本開示において同じエンティティを記述する他の用語を有する場合、これらの同義語が括弧の中に列挙され得る。定義は同義語の指定によって置き換えられることがあり、この場合、同義語の定義を参照することができる。
コンテンションアクセス期間(CAP):
CAPスロット:CAPにおける複数のスーパーフレームスロットの合成物
保証されたタイムスロット(GTS):
MACフレーム:MACサブレイヤで扱われるフレーム
[MACプロトコルデータユニット]
MACプロトコルデータユニット(MPDU):
[MACフレーム]
変調およびコーディング方式(MCS):物理レイヤでのレート適応パラメータ。これは、たとえば、変調のタイプまたはエラーコーディング方式の詳細を含む。
スーパーフレームスロット:ビーコン対応チャネルアクセスモードで各スーパーフレームのブロックを構築する基本の時間リソース。他の時間長、すなわち、ビーコンスロットまたはCAPスロットの時間長は、スーパーフレームスロット時間長の倍数である。

【0353】

3.2 頭字語および略語
FCS フレーム確認シーケンス
DME デバイス管理エンティティ
TAIFS ターンアラウンドインターフレーム空間
LLC リンクレイヤ制御

【0354】

4 一般的な説明
4.1 導入
4.2 IEEE 802.15.13 OWPANの構成要素
OWPAN(またはより一般的にはネットワーク)は、開示に準拠するデバイスからなり得る。デバイスは、ネットワークにおける識別およびフラットアドレス指定のためのMAC-48アドレスを持つ。デバイスは、準拠するMAC実装形態からなり、本開示において定義される準拠するPHYを利用する。OWPANを維持するための機能を、すべてのデバイスが実装することは要求されない。機能をサポートするデバイスは、OWPANを能動的に維持する場合、調整器対応デバイスまたは調整器とも呼ばれる。

【0355】

各OWPANにおいて、単一の調整器対応デバイスが調整器(たとえば、第2の装置15)の役割を引き受け得る。調整器は、OWPANを開始し、維持し、最後に停止することを担い得る。調整器はさらに、OWPANにおけるすべてのデータ送信に関与し得る。したがって、OWPANの唯一の論理ネットワークトポロジは、4.3で詳述されるように、スター型トポロジであり得る。

【0356】

以後単にデバイスと呼ばれる、非調整器デバイスは、調整器よりも少ない機能を実装する。デバイスは、ネットワークとのレイヤ2接続を得るために、OWPANとアソシエートする。

【0357】

4.3 ネットワークサービス
OWPANは、デバイス間のネットワークを表す。MCPS-SAPは、MAC-48アドレスに基づいて、デバイス間のMSDUの送信をサービスとして提供する。その上、調整器は、外部ネットワークの中のピアと、維持されているOWPANとアソシエートされるデバイスを接続する、アクセスポイント[ブリッジ]として動作し得る。

【0358】

4.3.1 トポロジ
すべてのIEEE 802.15.13 OWPANはスター型トポロジを有する。したがって、単一の調整器は、図9-1に示されるように、2つのデバイス間の、または、外部ピアとOWPANにアソシエートされるデバイスとの間のすべてのデータ送信に関与し得る。その上、同じOWPANの2つのデバイス間のデータ送信は、(いくつかの例では)調整器によっても中継されなければならない。

【0359】

用途に応じて、スター型トポロジは異なる特性を有し得る。以後の項は、実現されるべきスター型トポロジの様々な特別な場合を列挙する。

【0360】

4.3.1.1 分散MIMOスター型トポロジ
送信特性を改善し、モビリティサポートを高めるために、MIMO原理をサポートするようなスター型トポロジが実現され得る。その場合、調整器は、そのPHYと関連付けられる送信および受信のための複数の光フロントエンド(OFE)を有し得る。各OFEを用いて、調整器は同じまたは異なる信号を送信することが可能であり得る。しかしながら、個々のOFEはデバイスによりアドレス指定可能ではなく、それにより、個々のOFEは、デバイスが観測する様々なパイロット信号とは別に、デバイスに対して透過的になる。

【0361】

分散MIMOスター型トポロジの実現は、一般に本開示の範囲外である。たとえば、OFEは、空間に分散しており、何らかのフロントホール技術を介して、たとえばIEEE 802.1CM-2018に従って、単一の中央調整器インスタンスに接続され得る。そのような可能性を考慮するために、本開示は実現に有用な手段を定義する。それらは、たとえば、物理レイヤにおいて各OFEから直交パイロットシンボルを送信する可能性である。しかしながら、詳細な実装の規則は省略する。MACはさらに、大きいフロントホール遅延に対処することが可能であり得るチャネルアクセス機構を通じてこれらの考えられる実現形態をサポートし、実質的に伝播遅延を数百マイクロ秒に増やす。

【0362】

分散MIMOスター型トポロジは、図9-3に示され得る(図9-2はない)。調整器のOFE()は様々な方法で配置され得る。1つの考えられる配置は、OWPANの目標カバレッジエリアにわたってOFEを分散させることであり得る。

【0363】

4.3.1.2 無指向性スター型トポロジ(ブロードキャスト)
無指向性スター型トポロジ(図9-4に示される)では、OWPANは調整器のみを備える。無指向性スター型トポロジの調整器は、デバイスによるアソシエーションを受け入れない。それは、デスティネーションアドレスとしてブロードキャストアドレスを有するフレームを送信し得る。

【0364】

4.3.1.3 協調スター型トポロジ
同じエリアに展開される複数の調整器は、マスター調整器によって協調させられ得る。対応するトポロジは、協調スター型トポロジと呼ばれ得る。

【0365】

マスター調整器(たとえば、12)の機能は一般に、本開示の範囲外である。協調スター型トポロジの展開は、単一のベンダーからのデバイスを含み、したがって、調整器とマスター調整器との間のインターフェースの標準化を必要としないことが現在予想されている。

【0366】

マスター調整器を個々の調整器と相互接続するネットワークは、情報を操縦するだけではなく、データフレームの進路変更のためにも使用され得る。これはバックホール17とも呼ばれ得る。マスター調整器は(いくつかの例では)、[IEEE802ブリッジ定義]に従ったブリッジとして協調OWCネットワークを抽象化するために、SAPをより高次のレイヤに提供するものとする。協調トポロジは図9-5に示され得る。

【0367】

光は極めて局所的であるので、通常は、単一のエリアで、異なるプロバイダからの複数の協調していないインフラストラクチャが整備されることはない。したがって、近隣のIEEE 802.15.13 OWPANは、協調した方式で展開されると想定される。複数のOWPANインフラストラクチャがカバレッジエリアにおいて重複する場合、それらは常に、対応する調整器間のリソース割振りを管理するマスター調整器によって協調させられるべきである。

【0368】

4.3.1.4 無線周波数ハイブリッドトポロジ
ハイブリッドトポロジは、各デバイスにおける任意選択のRFベースの接続を伴う。ハイブリッドトポロジの実現は、本開示の範囲外であり得る。代替的なOWCベースおよびRFベースの接続の管理は、802.15.13 MACの上で、たとえば802.1AXに従って実行され得ることが予想され得る。

【0369】

4.3.1.5 ピアツーピアトポロジ
ピアツーピアトポロジでは、2つのデバイスは、互いとのポイントツーポイント通信を実行することを模索する。その場合、デバイスの一方が調整器の役割を引き受け、アドホックOWPANを他方のデバイスに提供する。したがって、ピアツーピアトポロジは、調整器と、提供されるOWPANにアソシエートされる単一の非調整器デバイスとを伴う、スター型トポロジの特別な場合であってもよい。

【0370】

4.3.2 統合
OWPANは、3つの論理的に別個の送信サービスを提供する:
1)調整器からデバイスへの、またはデバイスから調整器への送信
2)デバイスからOWPANの中の別のデバイスへの、または外部ネットワークのピアへの送信
3)OWPANの中の別のデバイスまたは外部ネットワークのピアからOWPANの中のデバイスへの送信

【0371】

第4の事例であるブリッジングは、本開示では現在サポートされないことがある。ブリッジングにおいては、調整器の背後にある外部ネットワークのピアは、関連するデバイスの背後にある外部ネットワークのピアと通信することが可能である。

【0372】

事例1)において、送信されるフレームは、調整器からデバイスに、またはデバイスから調整器に送信される、制御フレームまたは管理フレームであり得る。また、フレームは、調整器のアドレスまたはデバイスのアドレスのいずれかに設定されるデスティネーションMAC-48アドレスを伴うデバイスまたは調整器で実行される、より高次のレイヤのアプリケーションまたはプロトコルからのデータフレームであり得る。

【0373】

事例2)において、デバイスで実行されるより高次のレイヤのアプリケーションまたはプロトコルは、デスティネーションが調整器のユニキャストアドレス以外のMAC-48アドレスに設定されたフレームを送信する。デスティネーションアドレスは、調整器が接続され得る、OWPANの別のデバイスまたは別のネットワークのピアのいずれかに属してもよい。

【0374】

4.4 共存
光の高い指向性は、エネルギー検出に基づく共存方式を困難にする。これは、無指向性の伝播特性を有するRFベースの通信技術とは対照的であり得る。これらの無指向性の特性を通じて、相互に復号可能ではない信号を特徴とする異種RF技術は、所与の信号エネルギー閾値を超えることでチャネルがビジーであることを検出できるようになった後、送信を控えることに頼ることができる(エネルギー検出を通じたCCA)。

【0375】

しかしながら、指向性があると、デバイスAは、第2のデバイスBの送信が現在デバイスAの将来の受信機において受信されていることを推測することが可能ではない。

【0376】

本開示は、協調しない送信、すなわちランダムチャネルアクセスを、アソシエーションまたは再接続などの最小限の必要な目的に制限する。しかしながら、異質な技術がIEEE 802.15.13 OWPANのカバレッジエリアに入る場合、挙動は指定されないことがある。現在、異なるOWC開示間での共存のための協調はないことがある。

【0377】

4.5 アーキテクチャ
他のIEEE802規格と同様に、本開示のアーキテクチャは、関連する機能をグループ化して開示を簡単にするために、いくつかのレイヤによって定義され得る。各レイヤは、本開示に含まれる機能のサブセットを担うことがあり、次に高いレイヤにサービスを提供する。

【0378】

各レイヤは、他のレイヤとの交換を担うインターフェースを含む。より具体的には、より低次のレイヤは次に高いレイヤにサービスを提供する。本開示における対応するインターフェースのために使用される用語は、サービスアクセスポイント(SAP)であり得る。

【0379】

本開示は、異なるベンダーによって提供されるエンティティを接続する可能性が高い、公開のインターフェースを規定する。現在、これらは、図9-6に示されるような、MCPS-SAPおよびMLME-SAPである。他のインターフェースは、ベンダー内部のものであると想定され、または、詳細な規定を必要としない。

【0380】

レイヤの様々な機能は、所与のSAPを構成するいわゆるプリミティブを通じてアクセス可能である。プリミティブの概念は、4.6項でさらに説明され得る。

【0381】

OWPANを介して送信されることになるデータは、複数のレイヤを通る。レイヤ間を通されることになる制御ビット、管理ビット、および/またはデータビットの集合体は、プロトコルデータユニット(PDU)とも呼ばれ得る。PDUの交換に関わるレイヤおよび交換の向きに応じて、PDUは固有の名称を有する。より高次のレイヤのプロトコルによってMACサブレイヤに渡されるデータPDUは、MSDUと呼ばれ得る。MSDUは、OWPANを介した送信のためにMCPS-SAPを通じてMACサブレイヤに入り、OWPANを介した送信が成功した後でMCPS-SAPを通じてMACサブレイヤから出る。

【0382】

(送信の間の)MACサブレイヤを通じた処理の後、またはMACサブレイヤを通じた処理の前、PHYと交換されるデータユニットは、(MACの観点から)MPDUまたは(PHYの観点から)(PHYサービスデータユニット)PSDUのいずれかとして呼ばれ得る。PSDUは、PHY-SAPを通じてPHYに入り、PHYから出る。

【0383】

送信方向において、PHYはPSDUを処理してPPDUを生み、これは、光媒体を介して送信されるべき物理信号を表す。1つまたは複数のOFEを介した送信の後で、PPDUは、PHYレイヤによって受信されてPSDUへと処理されてもよく、これは続いて、MCPS-SAPまで複数のレイヤを横断する。

【0384】

4.6 プリミティブの概念
レイヤのサービスは、次に低いレイヤのサービス上にそのレイヤの機能を構築することによって、次に高いレイヤまたはサブレイヤにおいてそのレイヤがユーザに提供する能力である。この概念は、サービスユーザとサービスプロバイダ(次に低いレイヤ)との関係を示す、図9-7において示され得る。

【0385】

サービスは、ユーザとレイヤとの間の情報の流れを記述することによって規定される。この情報の流れは、サービスの提供を特徴付ける、個別の瞬間的なイベントによってモデル化される。各イベントは、ユーザに関連付けられるレイヤSAPを通じてあるレイヤから他のレイヤにサービスプリミティブを渡すことからなる。サービスプリミティブは、特定のサービスを提供することによって必要とされる情報を伝える。これらのサービスプリミティブは、サービスが提供される手段ではなく提供されるサービスを規定するので、抽象化である。この定義は、いずれの他のインターフェースの実装形態とも無関係である。

【0386】

4.7 機能的な概要
この項は、本開示によりサポートされる機能についての概要を与える。

【0387】

4.7.1 MACサブレイヤ
本開示のMACレイヤは、2つのモードのチャネルアクセス動作を許容する。

【0388】

4.7.2 PHYレイヤ
本開示は、3つの別個のPHYレイヤをサポートする。

【0389】

4.7.2.1 PM-PHY紹介

【0390】

4.7.2.2 LB-PHY紹介

【0391】

4.7.2.3 HB-PHY紹介

【0392】

4.7.3 アドレス指定
OWPANでは、デバイスのフラットアドレス指定が容易にされる。OWPANの中の各デバイスは、48ビットからなる固有のMAC-48アドレスを有する。このアドレスは、MAC-48アドレスフォーマットに依存している他のLANとOWPANを統合するために使用され得る[Std.802.1DおよびStd.802.1Qを参照]。

【0393】

シグナリング効率を高めるために、デバイスは、アソシエーションプロセスの間により短いアドレスを割り当てられる。短いアドレスは16ビットからなり、様々な制御および管理手順においてデバイスを識別するために、またはMACフレームにおけるアドレス指定を容易にするために使用され得る。

【0394】

いくつかのアドレスは、特別な目的のために予約されている。MAC-48アドレスでは、予約アドレスは、[IEEE 802 MACアドレス詳細規格]におけるものと(いくつかの例では)同じであるものとする。

【0395】

短いアドレス0x0000は(いくつかの例では)使用されないものとする。短いアドレス0xFFFFは(いくつかの例では)ブロードキャストアドレスとして使用されるものとする。ブロードキャストアドレスにアドレス指定されるフレームは(いくつかの例では)すべてのデバイスによって受信されるものとする。

【0396】

4.7.4 複信モード
すべての媒体アクセスは、OWPANの調整器によって制御される。調整器は、デバイスがcapFullDuplex能力をサポートする場合、デバイスの暗黙的な全二重送信および受信を可能にし得る。

【0397】

4.8 本開示における約束事
この項は、本開示内でのフォーマット、用語、およびユニットについての様々な約束事を列挙する。

【0398】

4.8.1 フォーマットの約束事
MACサブレイヤによって規定され維持される定数および属性は、斜体で、かつスペースなしで書かれる。定数は「a」という一般的なプレフィックスを有し、たとえば、aMinFragmentSizeである。可変の属性は「mac」という一般的なプレフィックスを有し、たとえばmacOwpanIdである。

【0399】

フレーム、要素、またはフィールドの名前も斜体で書かれる。それらは、先頭が大文字にされ、空白を含むことがあり、たとえば、Association Request要素である。

【0400】

4.8.2 基準を与える用語
本開示の準拠する実装形態に対する要件は、以下の用語を使用して表される。
a.ものとする(shall)は、必須の要件のために使用される
b.てもよい(may)は、実装形態がサポートすることが許可される任意選択の機能を記述するために使用される
c.べきである(should)は、推奨される実装形態および構成の選択のために使用される

【0401】

4.8.3 パワーレベル
光ワイヤレス通信は、強度変調された光および受信機における直接検出を利用する。したがって、受信するDSPにおいて測定されるような電気信号レベルは、すべてのデバイスに対して同じようには、受信された光パワーレベルと関連しない。むしろ、受信された光パワーと受信された電気パワーの関係は、LEDおよび光検出器の特性などの、所与のデバイスの実装形態の詳細に依存する。

【0402】

したがって、信号レベルを比較するために、(いくつかの例では)電気パワーではなく光パワーを参照しなければならない。信号レベルが本開示において規定されるとき、これらは光パワーである。これは、放出される信号レベルと受信される信号レベルにも当てはまる。

【0403】

5 MAC機能の説明
この項は、MACサブレイヤの機能および手順を規定する。手順は、MACによって、またはMLME-SAPプリミティブ呼び出しの結果によって開始され得る。MACは、物理レイヤサービスを利用し、以下のタスクを担う。
・OWPANの構成に対応するチャネルアクセスおよび送信を実行する
・OWPANを開始して維持する
・OWPANにアソシエートする/OWPANからアソシエート解除する
・MSDUを断片化およびアグリゲートする
・2つのピアMACエンティティ間で信頼性のあるリンクを提供する
・交互に入れ替わるチャネル条件に適応する

【0404】

MACの機能をサポートするMACフレームフォーマットは、6項において規定される。サービス、MAC PIB属性、およびデバイス能力は、7項において規定される
セキュリティに対するサポートは、8項において規定される。

【0405】

5.1 MACの概要
この項はMAC機能の大半を規定する。この項は、PHYを通じたPSDU処理の開始までMCPS-DATA.requestプリミティブを通じて開始されるような、フレーム送信の手順をカバーする。同様に、PHYを通じたPSDUの受信成功の後に始まり、MCPS-DATA.indicationプリミティブのトリガまでの、フレーム受信の手順が説明される。

【0406】

OWPANは、ビーコン有効モードまたはビーコン無効モードで動作することができる。どちらのモードが調整器によって使用されるかに応じて、チャネルアクセスは異なるように実行される。しかしながら、残りの送信および受信プロセスは、適用されるチャネルアクセス機構とは無関係に同じである。

【0407】

5.1.1 送信プロセス
送信プロセスは、MACがMCPS-SAPを通じてMSDUを受信すると、またはMLMEが管理フレームの送信を要求すると開始する。

【0408】

MACは(いくつかの例では)、MAC-48アドレスと短いデバイスアドレスとの間の変換テーブルを維持するものとする。

【0409】

デバイスは、適用されるチャネルアクセスモードを通じて規定されるような最大の時間長に従って、送信のためにMPDUを準備する。送信機会を取得することの詳細は、アソシエートされるOWPANにおいて適用されるチャネルアクセス機構に依存する(5.2項および5.3項参照)。

【0410】

図10-8はMAC送信プロセスを示す。

【0411】

デバイスは(いくつかの例では)、使用されるPHYの最大のサポートされるPSDUサイズをMPDUサイズが超えないことを確実にする。

【0412】

5.1.2 受信プロセス
受信プロセスは、PHYから入来するMPDUをMACが受信すると開始する。

【0413】

図10-9はMAC受信プロセスを示す。

【0414】

PSDUがPHYによって抽出された後、PSDUは思い付いたPHY-SAPを通じてMACに入る。MACは(いくつかの例では)次いで、フレームに含まれるFCSに基づいてフレームの完全性をまず確認するものとする。フレームが訂正不可能なエラーを含む場合、MACは(いくつかの例では)フレームを廃棄するものとする。フレームが受信に成功した場合、MACはフレームを解析してもよい。

【0415】

MACは(いくつかの例では)、Frame Control要素の中にサポートされないFrame Versionを有するフレームを廃棄するものとする(6.6.1.1)。

【0416】

MACは(いくつかの例では)、含まれる受信機アドレスに基づいてフレームをフィルタリングするものとする。MACは(いくつかの例では)、自身へのユニキャストではない、またはブロードキャストアドレスにアドレス指定されていない、すべてのフレームを廃棄するものとする。デバイスが、フレームがアドレス指定されるマルチキャストグループのメンバーである場合、MACはまた(いくつかの例では)、フレームを廃棄しないものとする。MACはまた(いくつかの例では)、MACがアソシエートされるOWPANに属しないデータおよび管理フレームを廃棄するものとする。

【0417】

ヘッダにおいてセキュリティの使用を示す残りの受信されるフレームについて、MACは(いくつかの例では)、それぞれのセキュリティの項において詳述されるように、暗号解読、信頼性確認、リプレイの検出と防止を実行するものとする。その目的で、MACは、セキュリティタイプのそれぞれの項において指定されるような、フレームのAuxiliary Security Headerに含まれるセキュリティ情報を利用する。

【0418】

フレームがフラグメントを含むことを示す場合、MACは(いくつかの例では)フレームをバッファリングし、5.5に従ってリアセンブリを実行するものとする。続いて、MACは(いくつかの例では)、フレームがアグリゲートされたMSDUを含む場合、5.6.2に従ってアグリゲート解除を実行するものとする。

【0419】

各々の受信されたMSDUに対して、MACは(いくつかの例では)、5.7項に従って重複物を除去するものとする。最後に、MACは(いくつかの例では)、構成に応じて、5.7.1または5.7.2に従って各々の受信に成功したMSDUに対する肯定応答を生成するものとする。

【0420】

5.2 ビーコン対応チャネルアクセス
OWPANがビーコン対応チャネルアクセスモードで動作する場合、チャネル時間は後続のスーパーフレームへと分割される。各スーパーフレームは、ビーコン送信、任意選択のコンテンションアクセス期間(CAP)、およびコンテンションフリー期間(CFP)という3つの主要な部分からなる。

【0421】

OWPAN調整器によるビーコンの送信は5.2.2に記述される。

【0422】

CAPにおいて、デバイスは、スロット化ALOHAによってランダムにチャネルにアクセスしてもよい。CAPにおけるランダムアクセスチャネルは、5.2.3において規定されるような特定の手順およびフレームタイプに対してのみ許容されてもよい。

【0423】

すべての他のフレーム送信は、CFPにおいて発生する(5.2.4参照)。CFPは、予約リソース、呼び出されたGTSからなり、これらは、所与のスーパーフレームに対して各デバイスに割り当てられる。調整器は、5.2.5において記述されるようにGTS割振りをスケジューリングして告知する。

【0424】

5.2.1 スーパーフレーム構造
スーパーフレームは、macNumSuperframeSlotsスーパーフレームスロットの合計からなり得る。macNumSuperframeSlotsは、OWPAN調整器によって決定される変数であり、ビーコンフレームにおいてデバイスに告知される。スーパーフレーム内のスーパーフレームスロットの最大の数は65535である(6.6.1.10参照)。各スーパーフレームスロットは、aSuperframeSlotDurationの時間長を有する。スーパーフレームスロットの数およびそれらのそれぞれの時間長は、各スーパーフレームの合計時間長を決定する。

【0425】

本開示は、スーパーフレーム内の時間長を指定するために、整数個のスーパーフレームスロットを利用する。それは、CAP、CAPスロット、GTS、およびスーパーフレームの他の一部の時間長であってもよい。

【0426】

各OWPAN調整器は、その調整されたOWPANのためのスーパーフレーム構造を定義する。OWPANの連続するスーパーフレームは、必ずしも隣接していなくてもよいが、OWPANによって使用されないスーパーフレームとスーパーフレームの間のチャネル時間を有してもよい。

【0427】

協調トポロジでは、マスター調整器が、各OWPANのスーパーフレームがいつ始まるか、およびそれがどれだけ長いかを決定する。協調トポロジの詳細は本開示の範囲外である。

【0428】

図10-10に示されるように、スーパーフレームの中のmacNumSuperframeSlotsスーパーフレームスロットのうちで、3つの連続するスロットグループが、それぞれビーコン送信、CAP、およびCFPのために使用される。ビーコン送信のために確保されるスーパーフレームスロットの数は、ビーコンフレームの長さに依存する。CAPの長さは、OWPAN調整器によって決定され、スーパーフレームごとに変化し得る。スーパーフレームの中の残りのスロットは、CFPのために使用され、デバイスと調整器との間のフレーム送信のために使用されてもよい。

【0429】

5.2.2 ビーコン送信
ビーコン対応チャネルアクセスモードでは、調整器は(いくつかの例では)、スーパーフレームの最初にビーコンを送信するものとする。ビーコンフレームは、Superframe Descriptor要素のみを含むか、または、Superframe Descriptor要素およびVariable Element Container要素を介した追加の要素を含むかのいずれかである、制御フレームである。ビーコンは、可能なとき、一定の周期で送信されるべきである。スーパーフレームタイミングの変更は、たとえば、ビーコン周期が変化する場合であってもよい。

【0430】

調整器は(いくつかの例では)、macBeaconNumber PIB属性を維持し、1つ1つの開始されるスーパーフレームおよび対応するビーコン送信に対して、それを1だけインクリメントするものとする。macBeaconNumberは、最高のとり得る値に達した後、1にラップアラウンドしてもよい。最高のとり得る値は調整器によって決定される。

【0431】

調整器は(いくつかの例では)、現在のmacBeaconNumberを各ビーコンのSuperframe Descriptor要素へと埋め込むものとする。ビーコンフレームを受信すると、各々の関連付けられるデバイスは(いくつかの例では)、受信されたビーコンフレームの中の値に、それらのmacBeaconNumber属性の値を設定するものとする。

【0432】

ビーコンフレームを受信すると、デバイスは(いくつかの例では)、5.2.6において説明されるような受信されるビーコンフレームにそれらのクロックを同期させるものとする。その上、対応するOWPANにアソシエートされるか、または所与のOWPANにアソシエートすることを試みるかのいずれかであるデバイスは(いくつかの例では)、MACのそのmacNumSuperframeSlots、macCapSlotLength属性を、受信されたSuperframe Descriptor要素に含まれる値に設定する。

【0433】

複数のOFEが調整器によって使用されるとき、ビーコンフレームは(いくつかの例では)、すべてのOFEにわたって同時に送信されるものとする。調整器がcapMultiOfeFeedback能力をサポートする場合、調整器は(いくつかの例では)、5.8.4項において詳述されるように、ビーコンフレームに直交パイロットシンボルを埋め込むものとする。

【0434】

デバイスは(いくつかの例では)、スーパーフレームの直後に次のビーコン受信を予想するものとする。ビーコンフレームが検出されない場合、デバイスは(いくつかの例では)、さらなる送信を試みる前に同期するために、次のビーコンフレームを聴取し続けるものとする。

【0435】

5.2.3 CAPにおける媒体アクセス
CAPは(いくつかの例では)、
a)アソシエーション手順(5.2.3.1参照)
b)リソース要求手順(5.2.3.2参照)
においてフレーム送信のために使用されるだけであるものとする。

【0436】

CAPは(いくつかの例では)、ビーコンの後にあるスーパーフレームスロットで開始し、スーパーフレームスロット境界上でCFPの開始の前に終了するものとする。CAPの長さはビーコンフレームにおいてアドバタイズされる(6.6.1.10参照)。CAP期間とCFP期間の両方が、CAPにおけるより多くのランダムアクセス送信またはCFPにおけるより多くのスケジューリングされる送信を可能にするために、スーパーフレームごとに動的に短縮または延長してもよい。

【0437】

スロット化Aloha方式が、CAPにおけるコンテンションベースのアクセスのために使用される。CAPの中のスーパーフレームスロットは、いわゆるCAPスロットにおいてグループ化され、これらは、macCapSlotLengthスーパーフレームスロットを各々備える。CAPスロット当たりのスーパーフレームスロットの数は、スロット化Aloha方式に対するスロットサイズを、およびしたがって、コリジョン防止の有効性を決定する。macCapSlotLengthは、ビーコンフレームにおいてアドバタイズされる(6.6.1.10項)。

【0438】

送信することを望むデバイスは(いくつかの例では)、[1,CW]からランダムにCAPスロットRSユニフォームの数を選ぶものとし、CWは第1の試行される送信に対するaInitialCapCwに等しい。すべてのデバイスの乱数発生器は(いくつかの例では)、統計的に相関しないものとする。続いて、デバイスは(いくつかの例では)、送信を試行する前にRS CAPスロットを待機するものとする。待機プロセスは、全体のRS CAPスロットが経過するまで、複数のスーパーフレームにわたって延長してもよい。送信は(いくつかの例では)次いで、次のCAPスロットの最初の境界において実行されるものとする。

【0439】

CAPにおける送信は、5.7において定義されるように、他のフレームのように肯定応答されなくてもよい。たとえば、予想される応答が受信されないという事実により、CAP送信が成功しなかったことをデバイスが暗黙的に検出する場合、デバイスは(いくつかの例では)、変数RCを1だけインクリメントするものとする。RCは(いくつかの例では)、最初は0であるものとする。成功しないCAP送信をどのように検出するかは、具体的な手順に依存する。詳細は、それぞれの5.2.3.1項および5.2.3.2項において与えられる。CAP送信は(いくつかの例では)、RCが実装形態固有の値を超えると、最終的には諦められるものとする。

【0440】

1つ1つの失敗した送信に対して、デバイスは(いくつかの例では)、CAPにおいてフレームの再送信を試みる前にCWを二倍にするものとする。しかしながら、CWはaMaximumCapCwを超えるべきではない。再送信のために、デバイスは(いくつかの例では)次いで、[1,CW]から導かれる、ランダムな数のCAPスロットRSの間再び待機し、後続のCAPスロットの最初における再送信を追い求めるものとする。

【0441】

CAP送信に続いて、デバイスは(いくつかの例では)、CAPにおいて送信されるフレームに対する起こり得る応答を受信するために、CFPにおいて継続的に聴取するものとする。

【0442】

CAP送信のプロセスは、それぞれ図10-4および図10-5における、アソシエーション手順およびリソース要求手順に対して視覚化される。

【0443】

5.2.3.1 CAPにおけるアソシエーション手順
デバイスはアソシエーションの前にGTSを割り当てられていないので、アソシエーション要求フレームが(いくつかの例では)CAPにおいて送信されなければならない。したがって、要求するデバイスは、5.4.5において説明されるように、Association Request要素を含むフレームを準備した後で、CAP送信手順を開始する。

【0444】

デバイスがcapMultiOfeFeedback能力をサポートする場合、デバイスは(いくつかの例では)、同じフレームの中の最新のビーコンフレーム受信から得られるCSIを含む、Multi-OFE Feedback要素を含むものとする。ビーコンが追加のマルチOFEチャネル推定パイロットを含まない場合、デバイスは(いくつかの例では)Multi-OFE Feedback要素を含まないものとする。

【0445】

アソシエーション要求手順のフローチャートが図10-11において与えられる。

【0446】

アソシエートするデバイスが、実装形態に依存する数のスーパーフレームの後にAssociation Responseを受信しない場合、そのデバイスは、Association Requestの送信が失敗したと推測してもよい。その場合、デバイスは(いくつかの例では)、5.2.3において説明されるようにCAPにおいてAssociation Requestの再送信を試みるものとする。

【0447】

5.2.3.2 CAPにおけるリソース要求手順
デバイスがその送信のために割り振られたGTS時間をまったく有しないとき、または(いくつかの例では)不十分なGTS時間しか有しないとき、デバイスはリソース要求手順を実行してもよい。たとえば、調整器からの接続が中断されて、調整器がデバイスにGTSを割り振るのを止めた後に、これが起こってもよい。

【0448】

その場合、デバイスは、GTS時間に対する要件を調整器にシグナリングするために、CAPにおいて制御フレームを送信してもよい。capMultiOfeFeedback能力がアソシエーションの間にネゴシエートされた場合、制御フレームは(いくつかの例では)、最新のビーコンフレーム受信から得られるマルチOFE CSIを含む、Multi-OFE Feedback要素を含むものとする。

【0449】

CAPにおけるGTS要求のための手順は、アソシエーション手順と同様である。対応するフローチャートが図10-12に示される。

【0450】

5.2.4 CFPにおける媒体アクセス
CFPにおけるチャネルアクセスは、動的TDMAの原理に基づく。スーパーフレームスロットは、コンテンションフリー媒体アクセスを可能にするために、デバイスごとに確保され得る。特定のデバイスのために確保される隣接するスーパーフレームスロットのグループは、保証されたタイムスロット(GTS)と呼ばれる。整数個のスーパーフレームスロットにおいて与えられる、第1のスーパーフレームスロットおよび時間長は、6.1.13.1項において説明されるようなスーパーフレームにおけるGTSの位置を定義する。GTSは(いくつかの例では)、CFP内だけに存在するものとする。

【0451】

デバイスは(いくつかの例では)、それが対応するGTS Descriptor要素を受信した後の、今後来るすべてのGTSのリストを維持する。デバイスは(いくつかの例では)、デバイスに割り当てられたGTSにおいてのみ送信するものとする。

【0452】

デバイスは、送信された信号が任意の他のデバイスにおける他のGTSでの送信と干渉できないことを確実にすべきである。これは、たとえば、使用されるPHYによってもたらされる全体の送信遅延、ならびに想定される伝播遅延および範囲を考慮することを含む。デバイスは(いくつかの例では)、5.2.7において説明されるように、その送信がインターフレーム空間の規則に従うことを確実にするものとする。

【0453】

GTSを伴うデバイスは、GTS内のすべての割り振られた時間長を利用してもよく、または利用しなくてもよい。送信のためのMPDUの選択は、キューの中にある未処理のフレームの数、およびそれらのユーザ優先度フィールドの値、および場合によっては他の基準に応じて、デバイスによってローカルに決定される。

【0454】

調整器は、CFPの中の任意の点においてデバイスへの送信を実行してもよい。したがって、すべてのデバイスが(いくつかの例では)、CFP全体の間、受信について聴取しなければならない。その逆も同様であり、調整器は(いくつかの例では)、各GTSの間の受信についてチャネルを聴取していなければならない。

【0455】

5.2.5 GTS割振りおよびシグナリング
(いくつかの例では)OWPAN調整器のみが、GTSを割り振る(GTSの割振りを解除する)資格を与えられる。あらゆる割り振られるGTSが(いくつかの例では)、CFP内に位置するものとする。

【0456】

調整器が複数の空間的に分散するOFEを監督する場合、調整器は、OWPANのカバレッジエリア全体でリソースの空間的な再使用を容易にするために、複数の空間的に離れたデバイスに対して異なるGTSの中の同じスーパーフレームスロットを割り振ってもよい。しかしながら、調整器は(いくつかの例では)、同じスーパーフレームスロットを共有するデバイスからの送信およびデバイスへの送信が干渉しないことを確実にしなければならない。

【0457】

デバイスは、キューの状態についての情報を提供してフローの確保を行うことを通じて、GTS割振りプロセスにおいて調整器を助ける。

【0458】

デバイスは、最も近いOFEを受信する際の信号強度についての情報を提供することを通じて、GTS割振りプロセスにおいて干渉を回避するように調整器を助ける。

【0459】

調整器は、スーパーフレームごとにスーパーフレーム内のGTSを移動し得る。これにより、調整器は、GTS割当てを再配置し、リソースの利用を最適化し、移動によりOFEとデバイスの間で可視性と信号強度が変動する場合にGTSのコリジョンを防止するための、柔軟性を得る。

【0460】

GTS割振りは(いくつかの例では)、GTS Descriptor要素を含む制御フレームを介して、調整器から対応するデバイスにアドバタイズされるものとする。これらの制御フレームは(いくつかの例では)、ユニキャストであり、(いくつかの例では)GTS割振りが指定されるデバイスによってのみ受信されるものとする。GTS割振りは(いくつかの例では)、デバイスの中のすべての既存のGTS割振りを直ちに上書きするものとする。以前に割り振られたGTSは(いくつかの例では)、新しいGTS割振りを受信した後は使用されないものとする。GTS割振りは、後続のスーパーフレームにおいて、またはGTS割振りフレームにおいて示されるスーパーフレームにおいて、有効になる。

【0461】

5.2.6 同期
すべてのデバイスが、それらがビーコン対応OWPANにアソシエートされるか、またはアソシエーションを試みているかにかかわらず、(いくつかの例では)送信または受信を開始する前に調整器のクロックに同期されるものとする。1つ1つのスーパーフレームの最初に送信されるビーコンは、到着時間の同期を通じて、ビーコン対応OWPANにおけるデバイスの同期を可能にする。

【0462】

調整器を含むOWPANの中の各デバイスは(いくつかの例では)、図10-13に示されるように、ビーコンのPHYプリアンブルの始めにある最初のスーパーフレームスロットを数え始めるものとする。よって、すべてのスーパーフレームスロット、およびしたがって、スーパーフレーム内のタイミングが、ビーコンプリアンブルの開始に対して相対的である。

【0463】

準拠するデバイスの実装形態は(いくつかの例では)、少なくともaClockAccuracyと同じくらい正確であるように、ローカル時間の正確さを維持する。

【0464】

5.2.7 インターフレーム空間
本開示によって定義される(いくつかの例では)唯一のIFSは、Turn Around Interframe Space (TAIFS)である。TAIFSは、送信と送信の間に十分なターンアラウンドタイムがあることを確実にするために必要である。ターンアラウンドタイムは、送信することから受信の準備ができていること、または、受信することから後続の送信を開始することに切り替えるためにトランシーバが必要とする最大の時間として定義される。送信機は、すべての受信するデバイスが最初からそれらのGTSを完全に利用することを可能にするために、GTSの終わりよりも少なくともTAIFS前にその送信が終了することを確実にしなければならない。TAIFSは(いくつかの例では)、各PHYに対して定義されるような、少なくとも最大の予想されるターンアラウンドタイムであるものとする。

【0465】

すべての他のデバイスがそれらのGTSにおいて順序通りに送信して受信することが、たとえばそれらがcapFullDuplex能力を実装することにより可能であることを、デバイスが確実にできる場合、デバイスは、GTSの終わりより少なくともTAIFS前に送信を終えるという要件を無視してもよい。

【0466】

単一の送信機の連続する送信と送信の間の空間は厳密に必要とはされない。受信機は、連続する送信を扱うのに十分に高速に、入来するフレームを処理することが可能であると予想される。

【0467】

5.2.8 ガード時間
TDMAシステムでは、ガード時間は、デバイスのローカルクロックが、たとえばデバイスのローカルクロックの周波数の不正確さにより引き起こされるドリフトを通じて不完全に同期されるときに、隣接するGTSにおける送信が競合するのを防ぐために必要とされる。GTSは、GTS要素において規定されるように、開始時間および時間長によって定義される(6.6.1.13項参照)。ガード時間は、1つのGTSの終了と次のGTSの開始との間の時間である。

【0468】

図10-14は、隣接するGTSの所有者が他のGTSに向かってドリフトする場合、連続する送信が常に少なくともTAIFSだけ離れているような、ガード時間の例示を図示する。

【0469】

必要とされるガード時間は、デバイスのローカル時間と理想時間との間の最大のドリフトMaxDriftに依存する。このドリフトは、同期した基準イベント、すなわちビーコン受信から経過した時間と、ローカルサンプリングクロックを定義するOFEおよびデバイスにおけるローカル発振器の精度との関数である。IEEE 802.15.13 OWPANでは、同期イベントはビーコンのプリアンブルの開始である。最大のドリフトMaxDriftは次のように計算され得る。
MaxDrift=クロックの正確さ/スーパーフレームの時間長

【0470】

クロックの正確さは、デバイスの実装形態に依存するが、(いくつかの例では)aClockAccuracy PIB属性によって与えられる値より悪くないものとする。スーパーフレーム時間長は、スーパーフレームの現在の時間長、およびしたがって、同期イベントの周期である。

【0471】

同期の正確さSyncAccuracyは、デバイスが調整器のクロックにどれだけ正確に同期され得るかを記述する。この値は、調整器の実装形態に依存し、(いくつかの例では)ベンダーによって決定されるものとする。値は(いくつかの例では)、同期がそれに基づいて実行されるビーコンフレームの、変化する伝播時間を通じてもたらされる不確実性を含むものとする。

【0472】

調整器は(いくつかの例では)、空間的に直交しない2つの後続のGTS間に少なくとも2・(MaxDrift+SyncAccuracy)のガード時間があることを確実にするものとする。

【0473】

5.3 非ビーコン対応チャネルアクセス
[文書15-18-0488-01-0013参照]

【0474】

5.4 OWPAN管理
この項は、既存のOWPANのスキャン、新しいOWPANの開始、ならびに、既存のOWPANとのデバイスのアソシエーションおよびそれからのデバイスのアソシエーション解除を説明する。

【0475】

5.4.1 OWPANのスキャン
近くで動作しているあらゆるOWPANを検出するために、デバイスによってスキャン手順が実行される。光通信では、ベースバンドにおける単一の周波数範囲が、すべての送信に利用される。したがって、既存のOWPANのスキャンは、単一の周波数チャネルのスキャンへと縮小する。しかしながら、複数のOWPANが、マスター調整器によって協調させられ、全体の利用可能なチャネル時間を共有してもよい。

【0476】

IEEE 802.15.13デバイスは(いくつかの例では)、OWPANのパッシブスキャンをサポートするものとする。パッシブスキャンの間、デバイスは、入来するフレームを聴取するだけではなく、その受信されるパワーがmacEdScanThresholdの閾値を超える復号不可能な信号も聴取する。デバイスが複数の光フロントエンドを利用する場合、デバイスは(いくつかの例では)、すべてのフロントエンドで聴取し、各フロントエンドに対する受信を個別に復号することを試みるものとする。

【0477】

スキャンは、MLME-SCAN.requestプリミティブを通じたDMEによる要求、またはMLME自体による要求で開始される。OWPANをスキャンするように指示されたデバイスは(いくつかの例では)、同じ期間の間の受信されるビーコンまたはRAフレームを聴取するものとする。スキャンの間、MACサブレイヤは(いくつかの例では)、すべての他の受信されるフレームを廃棄するものとする。

【0478】

スキャン期間の中の1つ1つの復号に成功したビーコンまたはRAフレームに対して、デバイスは(いくつかの例では)、対応するOWPAN IDおよびOWPAN名をスキャン結果リストに追加するものとする。デバイスは(いくつかの例では)、受信された電気的SNRおよびフレームにおいて示されるようなセキュリティタイプを結果リストにさらに追加するものとする。返されるリストは(いくつかの例では)、重複するエントリを含まないものとする。

【0479】

スキャン時間の間にmacEdScanThresholdを超える受信されるパワーを有する少なくとも1つの復号不可能な信号をデバイスが検出する場合、デバイスは(いくつかの例では)、OWPAN ID=0xFFFF、OWPAN name=「Unknown」であるエントリ、および最も強い受信された信号の受信されたパワーレベルをスキャン結果リストに追加するものとする。

【0480】

スキャンがMLME-SCAN.requestプリミティブを通じて開始された場合、スキャンの結果は(いくつかの例では)、MLME-SCAN.confirmプリミティブを介して返されるものとする。

【0481】

5.4.2 OWPANの開始
新しいOWPANを開始するプロセスは、MLME-SAPのMLME-START.requestプリミティブを通じて調整器対応デバイスがそうするように指示された後で開始される。この項は、OWPANを開始して維持することに関与するステップを説明する。将来の調整器が以前にOWPANを維持していた場合、DMEは(いくつかの例では)、すべてのMACおよびPHY状態ならびにアソシエート解除されたアソシエートされる可能性のあるデバイスをリセットするために、新しいOWPANを開始する前に、5.4.4に従ってOWPANを停止するものとする。

【0482】

DMEは(いくつかの例では)、新しいOWPANを開始することを試みる前に直ちにスキャンを行うものとする。DMEは(いくつかの例では)、対応するスキャンが空の結果リストを報告した場合、または、複数のOWPAN調整器間のリソース協調が協調トポロジを通じて提供され得る場合、MLME-START.requestプリミティブを出すだけであるものとする。

【0483】

将来の調整器のDMEは(いくつかの例では)、OWPAN IDおよびOWPAN名を選択するものとする。調整器がcapShortAddressing能力を実装する場合、調整器は(いくつかの例では)、選択されたOWPAN IDをその短いアドレスとして採用するものとする。DMEは(いくつかの例では)、選択されたOWPAN ID、OWPAN名、およびその短いアドレスを、MLME-START.requestのパラメータとして提供するものとする。MACは(いくつかの例では)、MLME-START.requestプリミティブを介して搬送されるセキュリティタイプに、macSecurityType属性を設定するものとする。

【0484】

注意-OWPAN IDはマスター調整器によって割り振られてもよい。2つの隣り合うOWPANは(いくつかの例では)、同じOWPAN IDを使用しないものとする。2つのOWPANが同じOWPAN名を使用してもよい。

【0485】

MLME-START.requestを受信すると、将来の調整器のMLMEは(いくつかの例では)、調整器としての動作を準備し、続いて、構成されるチャネルアクセスモードに従ってフレームを送信し始めるものとする。

【0486】

5.4.3 OWPANの維持
OWPANの開始に成功した後、調整器およびアソシエートされるデバイスは(いくつかの例では)、MCPS-SAPのプリミティブおよび対応するMACデータ経路機能、ならびに、サポートされる能力の一部を実装したMLME-SAPのプリミティブをサポートするものとする。

【0487】

調整器は、OWPANにアソシエートされるデバイスがそれらのそれぞれのPIB属性を修正する必要があるように、動作しているOWPANのパラメータを変更してもよい。アソシエートされるデバイスのPIB属性を制御するために、調整器は、Attribute Change Request要素を関係するデバイスに送信してもよい。Attribute Change Request要素は(いくつかの例では)、対応するPIB属性名および設定されるべき新しい値を含むものとする。

【0488】

Attribute Change Requestを受信するデバイスは(いくつかの例では)、要求される変更を反映するように、示される属性の値を修正するものとする。続いて、デバイスは(いくつかの例では)、試行される属性変化の結果を示す、Attribute Change Responseを用いて調整器に応答するものとする。

【0489】

5.4.4 OWPANの停止
既存のOWPANを停止するために、調整器のDMEは(いくつかの例では)、MLME-SAPを通じてMLME-STOP.requestを出すものとする。プリミティブを受信すると、調整器は(いくつかの例では)、適切な理由コードを用いてすべてのアソシエートされるデバイスのアソシエーションを解除するものとする。続いて、調整器のDMEは(いくつかの例では)、OWPANの稼働時間の間にもたらされたすべての状態を排除するものとする。

【0490】

5.4.5 OWPANとのアソシエーション
アソシエーション手順は複数のステップを伴う。
1.(一時的な)チャネルアクセスを得るために対象とのアソシエーションを要求する
2.OWPANによって要求されるような任意選択の要求認証

【0491】

5.4.5.1 アソシエーション要求
デバイスMLMEは、MLME-ASSOCIATE.requestプリミティブを通じてDMEによって既存のOWPANとのアソシエーションを試みるように指示される。アソシエーション手順を開始する前に、デバイスは(いくつかの例では)、キューを含むすべての状態、およびそのMACの変数をリセットするものとする。

【0492】

MLME-ASSOCIATE.requestを受信した後、デバイスは(いくつかの例では)、OWPAN調整器に送信されるように管理フレームを準備するものとする。管理フレームは(いくつかの例では)、専用のAssociation Requestフレームであること、または他の手段により含まれるAssociation Request要素を有することのいずれかによって、Association Request要素を含むものとする。

【0493】

Association Request要素は(いくつかの例では)、望まれるアソシエーションのためにデバイスによってサポートされる能力を含むものとする。さらに、要求は(いくつかの例では)、6.6.1.3項において詳述されるような必須の情報を含むものとする。

【0494】

要求するデバイスは(いくつかの例では)、アソシエーションのためのチャネルアクセス規則に従って、管理フレームをOWPANの調整器に送信するものとする。これらは、5.2項および5.3項においてそれぞれ詳述されるようなOWPANにおける適用されるチャネルアクセスモードに応じて異なる。フレームは(いくつかの例では)、保護されずに送信されるものとする(5.7項参照)。

【0495】

調整器MLMEがアソシエーションを追い求めると決定する場合、調整器MLMEは(いくつかの例では)、Association Response要素を含む管理フレームを準備するものとする。Association Response要素は(いくつかの例では)、将来のアソシエーションの間に使用されることになる能力のセットを含むものとする。能力のセットは(いくつかの例では)、Association Request要素においてデバイスによって以前に示されたもの以外の能力を含まないものとする。能力の精密なセットは調整器によって選択されてもよい。

【0496】

調整器がアソシエーションを追い求めないと決定する場合、調整器は(いくつかの例では)、適切なStatus Codeセットを伴うAssociation Response要素ものとする。

【0497】

OWPANがセキュアであり、さらなる認証を必要とする場合、Association Response要素は(いくつかの例では)、8項において詳述されるようなデバイスの後続の認証に必要とされるさらなる情報を含むものとする。Association Response要素の受信の成功の後、デバイスは(いくつかの例では)、必要な場合、OWPAN調整器を用いて認証を実行するものとする。

【0498】

成功したアソシエーション手順のシーケンスチャートが図10-16に示される。

【0499】

5.4.5.2 認証要求
さらなる認証が必要とされることを、デバイスによって受信されるAssociation Response要素が示す場合、デバイスは(いくつかの例では)、適用されるセキュリティタイプに対応して、Association Response要素に含まれる認証材料を処理するものとする。得られる認証データは(いくつかの例では)次いで、Association Request要素に含まれ、管理フレームを介して調整器に送信されるものとする。

【0500】

Association Request要素の送信のために、調整器は、アソシエートするデバイスに一時的なチャネルアクセスを付与してもよい。そうしない場合、デバイスは、CAPにおけるアソシエーション要求に類似するAssociation Request要素を送信してもよい。

【0501】

アソシエートするデバイスからAssociation Request要素を受信した後、調整器MLMEは(いくつかの例では)、MLME-AUTHENTICATE.indicationを介して、デバイスが認証を求めていることをDMEに示すものとする。DMEは(いくつかの例では)次いで、デバイスを認証し、MLME-AUTHENTICATE.requestを介して結果をMLMEに提供するものとする。DMEは(いくつかの例では)、30秒以内のMLME-AUTHENTICATE.indicationに対応するものとする。

【0502】

MLMEは(いくつかの例では)、アソシエーションを試みるデバイスにAssociation Response要素を送信するものとする。認証が成功した場合、デバイスは(いくつかの例では)、OWPANにアソシエートされるものと見なす。アソシエーションが進行している時間の間、デバイスは(いくつかの例では)、OWPANによって必要とされそれぞれのセキュリティタイプの項において詳述されるセキュリティ、すなわち暗号化、完全性保証、およびリプレイ保護を利用するものとする。

【0503】

調整器は、Association Response要素またはAuthentication Response要素をそれぞれ含むフレームに対する肯定応答を受信した後、デバイスがアソシエーションに成功したと見なしてもよい。

【0504】

5.4.6 OWPANからのアソシエーション解除
OWPANからの単一のデバイスのアソシエーション解除は、OWPANの調整器または影響を受けるデバイス自体のいずれかによって、MLME-DISASSOCIATE.requestプリミティブを通じて開始されてもよい。

【0505】

OWPANからデバイスをアソシエーション解除するために、調整器は(いくつかの例では)、Disassociation Notification要素を含む管理フレームを、図10-17 a)に示されるようにアソシエーションを解除されるべきデバイスに送信するものとする。調整器が対応する肯定応答フレームを受信しない場合、調整器は(いくつかの例では)、Timeoutプリミティブパラメータとして提供されるタイムアウトの間さらなるフレームをデバイスから受信しなかった後、アソシエーションが解除されているものとしてデバイスを見なしてもよい。

【0506】

OWPANからのアソシエーション解除を望むデバイスは(いくつかの例では)、Disassociation Notification要素を含む管理フレームを、図10-17 b)に示されるようにOWPANの調整器に送信するものとする。そのデバイスは(いくつかの例では)、送信される管理フレームに対する肯定応答を受信した後、アソシエーション解除されていると見なすものとする。

【0507】

5.5 断片化およびリアセンブリ
断片化は、MSDUまたはA-MSDUに対して送信デバイスによって実行されてもよい。(A-)MSDUは(いくつかの例では)、最大で16個のフラグメントへと断片化されるものとする。すべてのフラグメントが(いくつかの例では)、奇数のオクテットを含んでもよい最後のフラグメントを除き、偶数のオクテットを含むものとする。(A-)MSDUが断片化され、送信が試みられると、それは(いくつかの例では)再び断片化されないものとする。最後のフラグメントを除くフラグメントの最小のサイズは(いくつかの例では)、少なくともaMinFragmentSizeであるものとする。

【0508】

断片化されたMSDUまたはA-MSDUを含むMPDUには(いくつかの例では)、Sequence Control要素が存在するものとする。最後のフラグメント以外のすべてのフラグメントは(いくつかの例では)、データMPDUのLast Fragmentフィールドが0に設定された状態で送信されるものとする。最後のフラグメントは(いくつかの例では)、Last Fragmentフィールドが1に設定されているものとする。各々の後続のフラグメントは(いくつかの例では)、Fragment Numberフィールドがインクリメントされた状態で送信されてもよい。しかしながら、Fragment Numberフィールドは(いくつかの例では)、フラグメントが再送信されるときインクリメントされないものとする。

【0509】

フラグメントを含むMPDUは(いくつかの例では)、ヘッダのSequence Control要素の中に存在するシーケンス番号を有するものとする。したがって、断片化された(A-)MSDUは(いくつかの例では)、常に保護された状態で送信されるものとする。同じ(A-)MSDUのすべてのフラグメントが(いくつかの例では)、MPDUヘッダにおいて同じシーケンス番号を有するものとする。(A-)MSDUの断片化解除は、完全な(A-)MSDUへの受信されたフラグメントのリアセンブリである。(A-)MSDUは(いくつかの例では)、それをより高次のレイヤに伝える前に、正しい順序で完全にリアセンブルされるものとする。

【0510】

受信デバイスは、MSDUのフラグメントを、受信デバイスによって決定されるタイムアウト以内に完全にそれが受信されない場合、廃棄してもよい。デスティネーションデバイスはまた、そうしなければバッファのオーバーフローが発生するであろう場合に、最も古い不完全なMSDUを廃棄してもよい。フラグメントは(いくつかの例では)、フラグメント番号の順序で送信されるものとする。no-ACKポリシーが使用される場合、デスティネーションデバイスは(いくつかの例では)、フラグメントが欠けていればMSDUを直ちに廃棄するものとする。デバイスは(いくつかの例では)、少なくとも3つのMSDUのフラグメントの同時受信をサポートするものとする。

【0511】

5.6 アグリゲーション
デバイスは、複数のMPDUおよび対応するPPDUを送信することのオーバーヘッドを避けるために、複数のMSDUを単一のMPDUにアグリゲートしてもよい。アグリゲートされたMSDU(A-MSDU)は、A-MSDUサブタイプのデータフレームのペイロードにおいて送信される(6.3参照)。

【0512】

5.6.1 アグリゲーション手順
単一のMPDUに複数のMSDUをアグリゲートすることをデバイスMACが決定するとき、アグリゲーション手順は、図10-8において詳述される送信プロセスの一部として適用される。

【0513】

デバイスは(いくつかの例では)、MSDUがMCPS-DATA.requestプリミティブを介して搬送されるのと同じデスティネーションアドレスを有する場合、単一のMPDUにおいて複数のMSDUを送信するだけであるものとする。A-MSDUの中のすべてのMSDUは(いくつかの例では)、保護されるか、保護されないかのいずれかであるものとする。保護されるMSDUは(いくつかの例では)、保護されないMSDUと混合されないものとする。すべてアグリゲートされたMSDUおよびアグリゲーションのための追加のフィールドから生じる、オクテット単位の全体の得られるMPDUサイズは(いくつかの例では)、使用されるPHYのphyMaxPsduSizeを超えないものとする。

【0514】

A-MSDUの一部となるべき各MSDUは(いくつかの例では)、MSDU Aggregation要素にラップされてもよい。MSDU Aggregation要素は(いくつかの例では)、オクテット単位のラップされたMSDUの全体の長さを含むものとする。さらに、MSDU Aggregation要素は(いくつかの例では)、MSDUに割り当てられたシーケンス番号を含むものとする。

【0515】

アグリゲートされたMSDUを含むMPDUが確実に送信される場合、そのMPDUは(いくつかの例では)、単一のMSDUのみを(いくつかの例では)含むMPDUのように、単一のシーケンス番号を割り当てられるものとする。MPDUの受信機によって肯定応答を受信すると、MPDUに含まれるすべてのMSDUは(いくつかの例では)、肯定応答され、したがって送信に成功すると見なされるものとする。

【0516】

図10-18は、フレームの送信の間のアグリゲーションおよび断片化を示す。MCPS-SAPを通じてMACに到達する3つのMSDUは、MSDU Aggregation要素(MAEと略される)に含まれることによってアグリゲートされる。しかしながら、アグリゲーションは任意選択である。

【0517】

A-MSDUは任意選択で断片化されてもよい。例では、3つのMSDU A、B、およびCからなるA-MSDUは、2つのフラグメントへと分割され、各々MPDUにラップされる。MPDUは新しいシーケンス番号を含み、受信機におけるA-MSDUのリアセンブリに役立つ。そのシーケンス番号は、受信者デバイスによって肯定応答されなくてもよい。しかしながら、A-MSDUの中の各MSDUは、MSDU Aggregation要素において関連付けられるシーケンス番号を有する。これらのシーケンス番号は(いくつかの例では)、MPDUのFrame Control要素がAck Requestビットセットを有する場合、受信機によって肯定応答されなければならない。

【0518】

5.6.2 アグリゲーション解除手順
デバイスがA-MSDUデータフレームを受信する場合、デバイスは(いくつかの例では)まず、MPDU FCSフィールドに基づいてMPDU全体の完全性を確認する。MPDUがエラーなしで受信された場合、デバイスは(いくつかの例では)、MPDUの対応するシーケンス番号に肯定応答するものとする。

【0519】

続いて、受信するデバイスは(いくつかの例では)、MSDU Aggregation要素において与えられるサイズに基づいて、A-MSDUフレームのペイロードを別個のMSDU Aggregation要素に分離するものとする。MACは(いくつかの例では)次いで、対応するMSDU Aggregation要素に含まれるFCSに基づいて、各MSDUの完全性を確認するものとする。MSDUがエラーなしで受信された場合、MACは(いくつかの例では)、MSDU Aggregation要素に含まれる対応するシーケンス番号に肯定応答するものとする。

【0520】

図10-19は、リアセンブリおよびアグリゲーション解除手順を示す。2つのMPDU1および2がPHYから受信される。

【0521】

5.7 保護される送信
IEEE 802.15.13デバイス間の送信は保護されてもよい。保護は、2つのMAC間の送信の間に、MSDUが複製も順序の変更もされないことを確実にする。その上、保護は、肯定応答と再送信の機構によってMSDUの喪失を防ぐ。その目的で、あらゆる送信されるMSDUには、シーケンス番号が割り当てられている。

【0522】

各デバイスは(いくつかの例では)、1つ1つのピアデバイスに向かう送信のための個別のシーケンス番号カウンタを維持するものとする。シーケンス番号は12ビット幅の符号なしの整数であり、これは、とり得る最高の値の後で0にラップアラウンドする。シーケンス番号は(いくつかの例では)、デスティネーションアドレスに基づいてMCPS-SAPを通じて受信されるあらゆるMSDUに割り当てられるものとする。

【0523】

各々の発信MPDUには(いくつかの例では)、保護される送信を必要とするMSDUを含む場合、Sequence Control要素が存在する。単一のMSDUデータMPDUに対して、Sequence Control要素は(いくつかの例では)、MSDUに割り当てられるシーケンス番号を含むものとする。A-MSDUに対して、MPDUは(いくつかの例では)新しいシーケンス番号を含むものとし、これは、含まれるMSDUのすべてのシーケンス番号にマッピングする。それでも、A-MSDUの中の各MSDUは、依然として固有のシーケンス番号を有する。

【0524】

送信デバイスは(いくつかの例では)、肯定応答されていないaProtectedWindow個より多くのMSDUを送信していないものとする。

【0525】

(A-)MSDUの受信機は、あるシーケンス番号を受信しないという事実によって欠けているMSDUを検出することが可能である。その受信機は、同じシーケンス番号のMSDUを複数回受信するという事実により、重複したMSDUを検出することが可能である。同じシーケンス番号の2つの受信されたMSDUは(いくつかの例では)、重複している可能性のあるMSDUのうちの最初のMSDUの受信から、aProtectedWindow個を超える固有のシーケンス番号を受信機が受信した場合、重複であると見なされないものとする。受信機は(いくつかの例では)、最後の受信された重複を廃棄するものとする。

【0526】

MPDUが、肯定応答された送信を示し、Frame Control要素ならびにSequence Control要素の中に存在するACK Requestビットセットを有する場合、受信機は(いくつかの例では)、以下の肯定応答タイプのいずれかを用いて、送信の成功を認めるものとする。
・シングル肯定応答(5.7.1項)
・ブロック肯定応答(5.7.2項)

【0527】

それ以外の場合、受信機は(いくつかの例では)肯定応答を送信しないものとする。

【0528】

5.7.1 単一の肯定応答
MSDUの受信機は、単一の肯定応答によって受信の成功を認めることを決定してもよい。したがって、送信機に返される情報は、単一のMSDUの受信の成功についての情報のみを含む。

【0529】

肯定応答情報は(いくつかの例では)、以下のいずれかの一部としてAcknowledgment Information要素に埋め込まれるものとする。
・任意のデータまたは管理フレームのヘッダ
・専用のAcknowledgment制御フレームにおいて、そのペイロードの中にAcknowledgment Information要素のみを(いくつかの例では)含む
・Variable Element Container要素を含む任意のフレームにおいて、Acknowledgment Information要素を含む

【0530】

5.7.2 ブロック肯定応答
受信機は、累積的な肯定応答によって、受信に成功したMSDUに肯定応答してもよい。対応するブロック肯定応答フレームは、Block Acknowledgment要素を含めることを通じて、アグリゲートされた方式で1つまたは複数の受信に成功したMPDUについての情報を含む。

【0531】

受信機は、求められずに、または、Block Acknowledgment Request要素を通じた受信されたMPDUの送信機による要求があると、のいずれかでブロック肯定応答を送信してもよい。

【0532】

ブロック肯定応答要素は(いくつかの例では)、固有のソースアドレスを有するフレームにおいてのみ送信されるものとする。Block Acknowledgment要素を含む、フレームのソースアドレスは、肯定応答するデバイスを識別する。

【0533】

5.7.3 再送信
デバイスは(いくつかの例では)、少なくともmacRetransmitTimeoutの間デバイスが肯定応答されなかった後、保護されるMSDUを再送信するものとする。macRetransmitTimeout PIB属性は、5.4.3において説明されるパラメータ管理手順を通じて調整器によって調整されてもよい。

【0534】

5.8 適応送信およびチャネル状態フィードバック
デバイスは、たとえば変調およびコーディングを選ぶことを通じて、デバイス自体と受信機との間のチャネルについての利用可能な情報に基づいて、各発信PPDUに対するレートを選択してもよい。この情報は通常、フィードバック機構を介して各々の指定される受信機から取得され、または他の手段により送信機によって推測される。

【0535】

5.8.1 マルチレートMCS
IEEE 802.15.13 PHYは、変化する変調およびコーディング方式(MCS)の適用のもとでフレームを送信することが可能である。MCSの具体的な定義は、使用されるPHYに依存する。それは、エラーコーディングおよび変調に関する詳細を含んでもよい。

【0536】

デフォルトで、デバイスは、別のデバイスへの送信のためのMCSを自由に選択してもよい。レート選択アルゴリズムは、本開示の範囲外である。しかしながら、いくつかのフレームに対して、特定の変調およびコーディングの使用が必須である(5.8.2参照)。

【0537】

2つのデバイスがcapEffectiveChannelFeedback能力をサポートする場合、フレームの将来の受信機は、未来の送信機からの特定のMCSの使用を要求してもよい(5.8.3参照)。

【0538】

5.8.2 不可欠なフレームの送信
いくつかのフレームは(いくつかの例では)、各PHYのそれぞれの項において定義される、使用されるPHYに固有の基本レートで送信されるものとする。

【0539】

基本レートで送信されるべきフレームがTable 1(表6)に列挙されている。

【0540】

【表6】

【0541】

5.8.3 MCS要求フィードバック
capEffectiveChannelFeedback能力をサポートIEEE 802.15.13デバイスは、他のデバイスから受信される信号の品質を測定することが可能である。その上、それは(いくつかの例では)、MCS Request制御フレームを送信し、受信された変調要求制御フレームを次のように処理することが可能であるものとする。

【0542】

MCS Request制御フレームは、フレームの将来の受信機から将来の送信機に送信される。将来の受信機は、以前に要求されたMCSがうまく復号可能ではない可能性があること、またはよりレートの高いMCSが使用され得ることを検出する場合、MCS Request要素を送信してもよい。

【0543】

デバイスが別のデバイスからMCS Request制御フレームを受信する場合、デバイスは(いくつかの例では)、5.8.2において定義されるような特別な変調およびコーディングを必要とするフレームを送信が備えない場合、後続の送信のために要求された変調およびコーディング方式を利用するものとする。

【0544】

5.8.3.1 ビットローディングMCS要求
cabHbPhyがアソシエーションの間にネゴシエートされた場合、デバイス(調整器を含む)は、将来の送信機からのあるBATの使用を要求してもよい。その上、各デバイスは(いくつかの例では)、デバイスへのユニキャストフレームの各受信の間に有効なチャネルを測定するものとする。より前に要求されたBATがうまく復号可能ではないことを結果が示す場合、デバイスは(いくつかの例では)、送信機からの新しい十分にロバストなBATの使用を要求するものとする。デバイスはまた、たとえばチャネル品質が改善したので、スループットを上げるために、新しいBATの使用を要求してもよい。

【0545】

要求に対して、デバイスは(いくつかの例では)、次のようにBAT Request要素を準備するものとする。

【0546】

Valid Bat Bitmapフィールドは(いくつかの例では)、デバイスへの送信のために使用されてもよいBATのセットを示すものとする。ビットマップは(いくつかの例では)、将来の送信機がデバイスと同じ構成をとることをデバイスが確信しているBATを示すだけであるものとする。デバイスおよび将来の送信機において異なる構成を有する可能性のあるBATに対して、デバイスは(いくつかの例では)ビットマップの中のビットを0に設定するものとする。将来の送信機がBATに対して同じ構成を有することをどのように推測するかが、文字でさらに説明される。

【0547】

Updated BATフィールドは(いくつかの例では)、新しい構成が要求される、以前には無効であった新しいBAD IDを示すものとする。FEC Block Sizeフィールドは(いくつかの例では)、エラーコーディングのためのブロックサイズを含むものとし、FEC Code Rateフィールドは(いくつかの例では)、後続の送信のために使用されるように休息させられるコードレートを含むものとする。

【0548】

デバイスは(いくつかの例では)、サブキャリアごとの要求されたビットでBAT Group 1…Nフィールドを埋めるものとする。これは、同じ変調フォーマットを有するように、変化する数のサブキャリアを含む、複数のグループを形成してもよい。グループの総数は(いくつかの例では)、PHYのすべての利用可能なサブキャリアをカバーするものとする。グループによってカバーされるサブキャリアの総数は、サブキャリアの実際の数より多くてもよい。その場合、最後のBAT Groupに含まれる余剰のサブキャリアは(いくつかの例では)無視されるものとする。

【0549】

デバイスは(いくつかの例では)、制御フレームまたは管理フレームにおいてBAT Request要素を送信するものとする。デバイスが制御フレームを介して要素を送信する場合、デバイスは、肯定応答を予想できないので、将来の送信機が要求を受信したかどうかを知らない。

【0550】

5.8.4 マルチOFEチャネルフィードバック
capMultiOfeFeedback能力をサポートする調整器は(いくつかの例では)、マルチOFEパイロットを送信することが可能であるものとし、一方、capMultiOfeFeedback能力をサポートする非調整器デバイスは(いくつかの例では)、マルチOFEパイロットを受信し、続いてマルチOFEパイロットの各送信機間のチャネルを推定することが可能であるものとする。

【0551】

調整器が複数のOFEを利用する場合、調整器は、11および13において定義されるように、1つ1つのOFEのためのPPDUにマルチOFEパイロットシンボルの異なる区分を埋め込んでもよい。調整器が協調トポロジの一部である場合、マルチOFEパイロットの埋め込みのために使用されるべき区分およびタイムスロットは(いくつかの例では)、すべての調整器のためのマスター調整器によって協調させられるものとする。

【0552】

マルチOFEパイロットの受信機は、各パイロットシンボルの送信機と受信機自体との間の個々のCSIを推定することが可能であるが、複数の送信機の信号が時間的に重複してもよい。収集されるCSIは時間領域タップを備え、これは、それぞれの光信号パワーおよび最初の受信されるタップに対する相対的な遅延によって記述される。

【0553】

マルチOFEパイロットシンボルを含むPPDUを受信すると、デバイスは(いくつかの例では)、個々のチャネルを推定するものとする。デバイスは(いくつかの例では)次いで、直交パイロットの各々の識別された送信するOFEに対する測定されたCSIを含む、Multi-OFE Feedback要素をOWPANの調整器に送信するものとする。

【0554】

(いくつかの例では)デバイスは、(いくつかの例では)量子化のために実際の強度値より小さい値しか提供しないフォーマットを使用しないものとする。

【0555】

6 MACフレームフォーマット
この項は、MACによって使用されるフレームフォーマットの仕様を提供する。

【0556】

6.1 ビット順序および表現
6項の図は、MACフレームに含まれる情報を表してもよい。図は、全体のMACフレーム、要素、またはフィールドを示すことがある。要素は一般に使用されるフィールドのグループである。要素は本開示の読みやすさを高める。MACフレームは、それが含むフィールドおよび要素により記述される。

【0557】

6.1.1 ビット順序
MACフレームの処理(送信または解釈を意味する)と本開示におけるそれらの表現との間の関係は、次の通りである。ビット、フィールド、および要素は、左から右に、図におけるそれらの表現の順序で処理される。この関係は図11～図21に示される。

【0558】

フィールドが複数のビットの組合せにより表される数値を含む場合、ビットはMSBitを優先する順序で処理される。したがって、値の最も大きいビットが最初に処理される。数値が本開示内のバイナリ表現で指定される場合、MSBit表現が使用される。

【0559】

フィールドの数値がオクテットの長さを超える場合、それは、ビッグエンディアン表現でフィールド内に記憶される。したがって、数値のMSBitを含むオクテットが最初に処理される。

【0560】

「予約」のフィールドは、本開示の現在のバージョンにおいて意味のある情報を搬送しない。これは後のバージョンでは変更されてもよい。予約フィールドは(いくつかの例では)、送信のためにすべて0に設定されるものとし、(いくつかの例では)受信の際に無視されるものとする。予約フィールドの値は(いくつかの例では)、デバイスの挙動に影響しないものとする。

【0561】

6.1.2 表現
本開示におけるMACフレームまたは要素は、テーブルフォーマットで図として表される。一番上の行はフィールドまたは要素の幅を指定する。2番目の(中間の)行は、そのフィールドの説明、または本開示の他の箇所で指定される要素への参照を提供する。3番目の(一番下の)行は任意選択であり、その列に対応するフィールドまたは要素の代替的な説明を提供してもよい。方式は図11-22において表される。

【0562】

フィールドの幅は、ビットの総数が整数個のオクテットによって表現可能である場合、ビット数とオクテット数の両方で指定される。

【0563】

親フレームまたは要素の開始から可変の幅を含まない連続するフィールドにおいて、フィールドは、フィールドの最初のビットおよび最後のビットによって記述され得る。対応する概念は、「ビット」という語、およびそれに続く、最初と最後の表記されるビットの指定と読める。これは図11-24のフィールド1に対して明示されている。

【0564】

連続するフィールドの要素またはセットが可変の幅を有する場合、その幅は「可変」という語によって指定される。フィールドとMACフレームの開始との間に可変の幅のフィールドがある場合、絶対的なビット指定を使用することはできない。

【0565】

注意-MACフレームの正しい処理を可能にするために、可変の幅の要素の幅は他のフィールドから推論可能でなければならない。

【0566】

幅はビットまたはオクテットの数によって与えられ得る。対応する概念は、図11-23のフィールド2、3、および5に示されるように、ビットまたはオクテットの数と、それに続く「ビット」または「オクテット」という語を含む。

【0567】

6.2 一般的なMACフレームフォーマット
各MACフレームは、フレームのTypeおよびSubtypeを示す、6.6.1.1において定義されるFrame Control要素で開始する。本開示は、データ、管理情報、および制御情報の送信のための、3つの基本的なフレームTypesを伴う。

【0568】

データフレーム、管理フレーム、および制御フレームは、m 6.3項、6.4項、および6.5項においてそれぞれ詳述される、別個のMACヘッダを有する。そして、ペイロードは、データフレーム、管理フレーム、または制御フレームの異なるSubtypesに対して異なる。

【0569】

ペイロードは、MACフレームを介して搬送されるべき情報を含む。データフレームに対して、これは、送信のためのMCPS-SAPを介して受信される1つまたは複数のMSDUであってもよい。管理フレームでは、ペイロードは管理情報からなる。同様に、制御フレームのペイロードは、その動作においてMACを助ける制御情報を備える。

【0570】

各MACフレームは(いくつかの例では)、MACフレームのすべての先行する情報ビットにわたる32ビットのCRCサムを含む、FCSフィールドで終了するものとする。

【0571】

一般的なMACフレーム構造は図11-24に示される。

【0572】

6.2.1 FCSフィールド
FCSフィールドは、32ビットCRCを含む32ビットフィールドである。FCSは、MACヘッダのすべてのフィールドおよびフレームボディフィールドにわたって計算される。これらは計算フィールドと呼ばれる。FCSは、以下の本開示の32次生成多項式を使用して計算される。
G(x)=x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1

【0573】

FCSは、以下の合計の1の補数(modulo 2)である。
a)x^k(x³¹+x³⁰+x²⁹+…+x²+x+1)をG(x)で割った余り(modulo 2)、kは計算フィールドにおけるビットの数である
b)計算フィールドの内容(多項式として扱われる)をx³²と乗じて、次いでG(x)で割った後の余り

【0574】

FCSフィールドは、次数が最高である項の係数が最初になるような順序で送信される。

【0575】

典型的な実装形態では、送信機において、除算の最初の余りは、すべて1にあらかじめ設定されており、次いで、生成多項式G(x)による計算フィールドの除算により修正される。この余りの1の補数が、最も次数の高いビットを最初にして、FCSフィールドとして送信される。受信機において、最初の余りはすべて1にあらかじめ設定され、計算フィールドおよびFCSの連続的な入来するビットは、G(x)により除算されると、送信エラーがなくなり、固有の0ではない余りの値をもたらす。固有の余りの値は多項式である。
x³¹+x³⁰+x²⁶+x²⁵+x²⁴+x¹⁸+x¹⁵+x¹⁴+x¹²+x¹¹+x¹⁰+x⁸+x⁶+x⁵+x⁴+x³+x+1

【0576】

6.3 データフレーム
データフレームは、ピアデバイスへの、MCPS-SAPを介して受信されたMSDUの送信を担う。データフレームのMPDU構造は図11-25に示される。

【0577】

Frame Control要素はさらに、6.6.1.1において説明される。それは、フレームヘッダの残りの構造を決定する複数のビットを含む。

【0578】

データフレームは、ヘッダにおいてACK Information要素を搬送してもよい。ACK Information要素の存在は、フレームのFrame Control要素の中のACK Infoフィールドによって示される。ACK Information要素は、より前のフレームの受信の成功を認めるために、送信機によって使用されてもよい。

【0579】

各データフレームは、Receiver AddressおよびTransmitter Addressフィールドを有する。これらのフィールドは、16ビットの短いMACアドレスまたは48ビットのフルMACアドレスのいずれかを備えてもよい。アドレスフォーマットは、6.6.1.1において説明されるようなFrame Control要素の中のShort Addressingフィールドによって示される。

【0580】

データフレームには、Auxiliary Address 1およびAuxiliary Address 2という、最高で2つの追加のアドレスフィールドが存在してもよい。これらが存在するかどうか、およびそれらが何の情報を含むかは、6.6.1.1において説明されるようなFrame Control要素の中のTo BackhaulおよびFrom Backhaulフィールドから導かれ得る。

【0581】

管理フレームは、シーケンス番号によって保護され、失われると再送信されてもよい。Sequence Control要素は、Frame Control要素において1に設定されるACK Requestビットを有する管理フレームに存在する。

【0582】

ペイロードがセキュアである場合、データフレームには、Auxiliary Security Headerが存在しなければならない。Auxiliary Security Headerの存在は、Frame Control要素の中のSecurity Enabledビットによって示される(6.6.1.1)。Auxiliary Security Headerのフォーマットは、8項において定義されるように、可変であり、適用されるセキュリティタイプの詳細に依存する。

【0583】

データフレームのペイロードコンテンツは、Frame Control要素のサブタイプフィールドによって記述される。現在、ペイロードは、Table 2(表7)に列挙されるような異なるフォーマットを含むことがある。

【0584】

【表7】

【0585】

Subtype 0000のデータフレームに対して、ペイロードは長さが0である。これらのヌルフレームは、様々な理由で、MPDUまたは対応するPPDUを送信するために使用されてもよい。

【0586】

Subtype 0001は、データフレームのペイロードが単一のMSDUを含むことを示す。

【0587】

Subtype 0010は、データフレームのペイロードにおいてA-MSDUを示す。A-MSDUのフォーマットは5.6において詳述される。

【0588】

データフレームのFCSフィールドは、6.2.1において定義されるようなフレーム確認シーケンスを含む。

【0589】

6.4 管理フレーム
管理フレームは、異なるプロトコル交換手順において2つのMLMEの通信を助ける、管理情報を搬送する。管理フレームのMPDUフォーマットは、図11-25に示される。

【0590】

あらゆるMACフレームと同様に、管理フレームは、6.6.1.1においてさらに説明されるように、Frame Control要素で開始する。

【0591】

管理フレームは、それらのヘッダにおいてACK Information要素を搬送してもよい。ACK Information要素の存在は、フレームのFrame Control要素の中のACK Infoフィールドによって示される。ACK Information要素は、より前のフレームの受信の成功を認めるために送信機によって使用されてもよい。

【0592】

各管理フレームは、Receiver AddressおよびTransmitter Addressフィールドを有する。これらのフィールドは、16ビットの短いMACアドレスまたは48ビットのフルMACアドレスのいずれかを備えてもよい。アドレスフォーマットは、6.6.1.1において説明されるようなFrame Control要素の中のShort Addressingフィールドによって示される。

【0593】

管理フレームは、シーケンス番号によって保護され、失われると再送信されてもよい。Sequence Control要素は、Frame Control要素において1に設定されるACK Requestビットを有する管理フレームに存在する。

【0594】

管理フレームのペイロードは、6.6項において定義される1つまたは複数の要素を含む。サブタイプは、どの要素がペイロードフィールドに存在するかを記述する。簡単な管理フレームでは、ペイロードは単一の要素だけからなる。サブタイプのために存在すべき要素はTable 3(表8)から導かれ得る。

【0595】

【表8】

【0596】

ペイロードの中にVariable Element Container要素が存在することによって、単一の管理フレームが1つより多くの要素を含むことが可能である。

【0597】

管理フレームのFCSフィールドは、6.2.1において定義されるようなフレーム確認シーケンスを含む。

【0598】

6.5 制御フレーム
制御フレームは、その動作においてより低いMACおよびPHYを助ける。制御フレームのMPDU構造は図11-27に示される。

【0599】

MACフレームとして、各制御フレームは、6.6.1.1においてさらに説明される、Frame Control要素で開始する。

【0600】

各管理フレームは、Receiver AddressおよびTransmitter Addressフィールドを有する。これらのフィールドは、16ビットの短いMACアドレスまたは48ビットのフルMACアドレスのいずれかを備えてもよい。アドレスフォーマットは、6.6.1.1において説明されるようなFrame Control要素の中のShort Addressingフィールドによって示される。

【0601】

制御フレームを介して搬送される情報は短命であり、すぐに古くなる。したがって、制御フレームは喪失の際に再送信されない。むしろ、直近の制御情報を含む新しい制御フレームが送信されてもよい。

【0602】

制御フレームは、それらの性質により、シーケンス番号を搬送する。結果として、フレームヘッダは非常に単純に保たれ、(いくつかの例では)Frame Control要素、Receiver Addressフィールド、およびTransmitter Addressフィールドのみを含む。

【0603】

【表9】

【0604】

6.6 要素
要素は、6.1項において定義されるような一般的なMAC機能を担う関連するフィールドの集合体である。要素は、いくつかのフレームの内容を定義し、文書の読みやすさを高めるために使用されてもよい。要素が可変の数のフィールドまたは他の要素を含む場合、要素の全体の長さが、構文解析を可能にするためにそのフィールドの内容から推論可能でなければならない。

【0605】

各要素には、いくつかのフレームにおいて要素を識別するIDが割り当てられている。Table 5(表10)は、本開示内で定義される要素と、それらの対応するIDおよび定義条項とを列挙する。

【0606】

【表10】

【0607】

6.6.1.1 Frame Control Element
図11-28は、フレーム制御要素の例を示す。

【0608】

Frame Control要素は、さらなるMACフレーム構造の決定を担う、またはペイロードの性質を示す、複数のビットを備える。Frame Control要素は、各MACフレームの最初に存在する。

【0609】

Frame Version:Frame Versionサブフィールドは、フレームに対応するバージョン番号を指定する。このサブフィールドは(いくつかの例では)、IEEE 802.15.13と互換性のあるフレームを示すために「00」に設定されるものとする。すべての他の値は(いくつかの例では)今後の使用のために予約されているものとする。

【0610】

Type:管理フレームでは、Typeフィールドは(いくつかの例では)00に設定されるものとする。制御フレームでは、このフィールドは01である。データフレームでは、このフィールドは00に設定される。値11は予約されている。

【0611】

Subtype:フレームのサブタイプ、すなわちペイロードの内容を示す。

【0612】

To Backhaul / From Backhaul:これらのフィールドは、OWPANが論理LANへと統合されるトポロジにおける、データフレームのアドレス指定フィールドの正しい解釈のために必要である。たとえば、これは協調トポロジにおいて当てはまることがある。

【0613】

LAN内のデータフレーム(MSDU)は、ソースアドレスおよびデスティネーションアドレスを有する。対照的に、受信機アドレスおよび送信機アドレスは、それぞれMPDUを受信または送信するための、802.15.13デバイスのアドレスである。

【0614】

【表11】

【0615】

Security Enabled:Security Enabledフィールドは(いくつかの例では)、フレームがMACサブレイヤによって保護される場合は1に設定されるものとし、(いくつかの例では)それ以外の場合には0に設定されるものとする。MHRのAuxiliary Security Headerフィールドは(いくつかの例では)、Security Enabledサブフィールドが1に設定される場合にのみ存在するものとする。

【0616】

ACK Request:Acknowledment Requestフィールドは、データまたはMAC管理/制御フレームの受信に際して肯定応答が受信者デバイスから必要とされるかどうかを指定する。このサブフィールドが「1」に設定される場合、受信者デバイスは(いくつかの例では)肯定応答フレームを送信するものとする。このサブフィールドが「0」に設定される場合、受信者デバイスは(いくつかの例では)肯定応答フレームを送信しないものとする。

【0617】

ACK Info:ACK Information要素が残りのMACヘッダに存在するかどうかを指定する。ACK情報要素が存在する場合、このフィールドは(いくつかの例では)1に設定されるものとする。それ以外の場合、それは(いくつかの例では)0に設定されるものとする。

【0618】

Short Addressing:短いアドレスがMACヘッダのアドレスフィールドにおいて使用されるかどうかを示す。短いアドレスがヘッダにおいて使用される場合、このフィールドは(いくつかの例では)1に設定されるものとする。それ以外の場合、それは(いくつかの例では)0に設定されるものとする。OWPAN IDなどのいくつかのアドレスは、常に短い表現である。長いアドレスは(いくつかの例では)、MAC-48アドレスの等価物を有するアドレスだけのために使用されてもよい。

【0619】

More Fragments:データフレームにおいて、このフィールドは(いくつかの例では)、ペイロードが最後のフラグメントではない(A-)MSDUのフラグメントを含む場合、1に設定されるものとする。それ以外の場合、それは(いくつかの例では)0に設定されるものとする。

【0620】

6.6.1.2 Sequence Control Element
図11-29は、シーケンス制御要素の例を示す。

【0621】

Sequence Control要素は、フレームの断片化および信頼性のある送信のための情報を含む。

【0622】

Fragment Number:MPDUが(A-)MSDUのフラグメントを含む場合、このフィールドはそれぞれのフラグメント番号を含む。

【0623】

Sequence Number:このフィールドはMPDUの割り当てられたシーケンス番号を含む。

【0624】

6.6.1.3 Association Request Element
図11-30は、アソシエーション要求要素の例を示す。

【0625】

Association Request要素は、デバイスがアソシエーションを要求するときに、OWPANの調整器へデバイスによって最初に送信される。

【0626】

Device Mac Address:アソシエーションを要求するデバイスのMAC-48アドレス。

【0627】

Capability List:アソシエーションを要求するデバイスのサポートされる能力を記述する、1つのCapability List要素。

【0628】

OWPAN ID:

【0629】

Supported Rates:

【0630】

Extended Supported Rates:

【0631】

6.6.1.4 Association Response Element
図11-31は、アソシエーション応答要素の例を示す。

【0632】

Association Response要素は、アソシエーションを要求するデバイスへ調整器に送信される。

【0633】

Device MAC Address:アソシエーションを要求するデバイスのMAC-48アドレス。

【0634】

Status Code:ステータスコードは、先行するアソシエーション要求の結果を示す。

【0635】

【表12】

【0636】

Capability List:このフィールドは、アソシエーションが拒否されなかった場合に更なるチャネルアクセスのために使用されるべき能力のセットを記述する、Capability List要素を含む。アソシエーションが拒否された場合、このフィールドは(いくつかの例では)無視されるものとする。

【0637】

Short Address:アソシエーションが拒否されなかった場合にデバイスに割り当てられる短いアドレス。アソシエーションが拒否された場合このフィールドは(いくつかの例では)無視されるものとする。

【0638】

Supported Rates:

【0639】

Extended Supported Rates:

【0640】

6.6.1.5 Reassociation Request Element

【0641】

6.6.1.6 Reassociation Response Element

【0642】

6.6.1.7 Disassociation Notification Element
図11-32は、アソシエーション解除通知要素の例を示す。

【0643】

Disassociation Notification要素は、OWPANからのデバイスのアソシエーション解除についての情報を伝える。

【0644】

Reason Code:理由コードはアソシエーション解除の理由を示す。

【0645】

【表13】

【0646】

OWPAN ID:デバイスをアソシエーション解除すべきOWPAN ID

【0647】

Device Short Address:OWPANからアソシエーション解除すべきデバイス

【0648】

6.6.1.8 Authentication Request Element
図11-33は認証要求要素の例を示す。

【0649】

Authentication Request要素は、OWPANとのアソシエーションに成功するために必要とされる場合に認証を要求するために、デバイスによってそのOWPANの調整器に送信される。

【0650】

Authentication Algorithm:認証のために使用される認証アルゴリズム

【0651】

Authentication Transaction Token:認証のために使用される認証アルゴリズム

【0652】

Status Code:認証のために使用される認証アルゴリズム

【0653】

Challenge:認証のために使用される認証アルゴリズム

【0654】

6.6.1.9 Authentication Response Element

【0655】

6.6.1.10 Superframe Descriptor Element
図11-34は、スーパーフレーム記述子要素の例を示す。

【0656】

Superframe Descriptor要素は、開始するスーパーフレームについての情報を伝える。

【0657】

Superframe Number:後続のスーパーフレームの数。5.2.2において説明されるようなラップアラウンドする整数。

【0658】

Total Superframe Slots:後続のスーパーフレームの中のスーパーフレームスロットの数。OWPANとアソシエートされる、またはアソシエーションを試みるデバイスは(いくつかの例では)、このフィールドに含まれる値にそれらのmacNumSuperframeSlots PIB属性を設定するものとする。

【0659】

Superframe Slot Duration:単一のスーパーフレームスロットの時間長。

【0660】

CAP Slot Width:CAPスロット当たりのスーパーフレームスロットの数。

【0661】

CAP Slots:後続のCAPに含まれるCAPスロットの数。

【0662】

6.6.1.11 OWPAN Descriptor Element
図11-35は、OWPAN記述子要素の例を示す。

【0663】

OWPAN Descriptor要素は、OWPANについての情報を伝える。

【0664】

OWPAN Name:ヌル終端ASCII文字列としてのOWPANの名称。長さは(いくつかの例では)、文字列の終端を含めて、3オクテットと32オクテットの間であるものとする。

【0665】

OWPAN ID:OWPANの数値ID。

【0666】

Coordinator Address:OWPAN調整器のMAC-48アドレス。

【0667】

Security Type:OWPANにおいて適用されるセキュリティタイプ。有効なタイプはTable 2(表7)に列挙される。

【0668】

6.6.1.12 Capability List Element
図11-36は、能力リスト要素の例を示す。

【0669】

Capability List要素は、2つのデバイス間で7.4項に記載されるような能力についての情報を移すために使用される。

【0670】

Bitmap Width:後続のCapability Bitmapフィールドをオクテット単位で指定する。したがって、Capability Bitmapフィールドは最大で、ID Bitmap Width*8-1を伴う能力を含み得る。Bitmap Width 0が、必要な場合、能力の空のリストを示すために使用されてもよい。

【0671】

Capability Bitmap:Table 36(表43)において与えられるような能力のサブセットを示すビットマップ。このビットマップにおいて、一番左のビット、すなわち最初に処理されることになるビットは、ID 0に対応する。一番右のビット、すなわち6.1.1において与えられる定義によって最後に処理されることになるビットは、ID Bitmap Width*8-1に対応する。能力がサブセットに含まれる場合、能力のIDに対応するビットは(いくつかの例では)1に設定されるものとする。それ以外の場合、ビットは(いくつかの例では)0に設定されるものとする。

【0672】

たとえば、ID 1、4、および7を伴う能力の存在を示す、1オクテット(8ビット)の幅を伴うビットマップは、01001001(左から右に処理する)である。

【0673】

6.6.1.13 GTS Descriptor List Element
図11-37は、GTS記述子リスト要素の例を示す。

【0674】

GTS Descriptor List要素は、ビーコン対応チャネルアクセスモードにおけるデバイスに対する複数のGTS Descriptor要素を保持する。

【0675】

GTS Descriptor Count:このフィールドは、後に含まれるGTS記述子の数を含む。

【0676】

Validity Present:1に設定される場合、子GTS記述子には有効性フィールドが存在する。存在しない場合、0に設定される。

【0677】

Device Address Present:1に設定される場合、各子GTS Descriptorには(いくつかの例では)、Device Short Addressフィールドが存在するものとする。

【0678】

GTS Directions:Directions Presentフィールドが1に設定される場合、このフィールドは、後に含まれるGTSの方向を示す。

【0679】

GTS Descriptor 1…N:これらのフィールドは1つまたは複数のGTS Descriptor要素を含む。

【0680】

6.6.1.13.1 GTS Descriptor Element
図11-38は、GTS記述子要素の例を示す。

【0681】

この要素は、ビーコン対応チャネルアクセスモードにおけるデバイスに対する単一のGTS割振りを記述する。

【0682】

Device Short Address:このフィールドは、親GTS Descriptor List要素が1に設定されたDevice Address Presentフィールドを有する場合に存在する。このフィールドは、GTSが割り振られたデバイスの短いアドレスを含む。

【0683】

GTS Start Slot:このフィールドは、割り振られたGTSの最初のスロットを指定する。

【0684】

GTS Length:このフィールドは、スーパーフレームスロットにおけるGTSの時間長を指定する。

【0685】

Validity:このフィールドは、親GTS Descriptor List要素が1に設定されたValidity Presentフィールドを有する場合に存在する。このフィールドは示す。

【0686】

6.6.1.14 Multi-OFE Feedback Element
図11-39は、マルチOFEフィードバック要素の例を示す。

【0687】

Multi-OFE Feedback要素は、OWPANの調整器にデバイスからマルチOFEチャネルフィードバックを転送するために使用されてもよい。

【0688】

Number of OFEs:別個の認識されるOFEの数。これは、全体の含まれるOFE Feedback Descriptor要素の数を決定してもよい。

【0689】

Tap format:このフィールドは、子Tap Descriptor要素に含まれるタップのフォーマットを記述してもよい。

【0690】

【表14】

【0691】

OFE Feedback Descriptor Element 1…N:デバイスと各々の送信するOFEとの間のチャネルのためのCSIを含んでいてもよいOFE Feedback Descriptor要素。要素の数NはNumber of OFEsフィールドに等しくてもよい。

【0692】

6.6.1.14.1 OFE Feedback Descriptor Element
図11-40は、OFEフィードバック記述子要素の例を示す。

【0693】

OFE Feedback Descriptor要素は、所与の送信機からの受信された信号についてのチャネル状態情報、すなわち単一のマルチOFEパイロット分割を含んでもよい。

【0694】

Pilot Symbol Number:例では、含まれるフィードバックがそこから測定された、PPDU内のパイロットシンボルの、それぞれの受信されたPPDU内での位置(たとえば、時間的な)を指定する。値は1-7であり、0は予約であってもよい。

【0695】

Division:例では、パイロット分割を指定する。これは、たとえば、アダマール符号、またはPPDUヘッダにおいて示されるようなサブキャリア離隔およびシフトである。

【0696】

Number of Taps:例では、後続のTap Descriptor要素の数を指定し、Nとも表記される。

【0697】

Tap Descriptor 1…N:それぞれのタップに対するTap Descriptor要素を指してもよい。第1のTap Descriptor要素は(いくつかの例では)、そのOFEからの第1の受信されたタップに対応するものとする。

【0698】

6.6.1.14.2 Tap Descriptor Element
表11-41は、タップ記述子要素の例を示す。

【0699】

Tap Descriptor要素は単一のタップについての情報を含んでもよい。

【0700】

Strength:所与のタップの光信号強度を指してもよい。フォーマットは、親Multi-OFE Feedback要素のTap Formatフィールドにおいて指定されてもよい。

【0701】

Delay:親Multi-OFE Feedback要素のTap Formatフィールドにおいて指定されるフォーマットにおける整数遅延を指してもよい。この遅延は、すべてのOFEの最初の受信されたタップに対する相対的なものであってもよい。いくつかの例では、最初のタップに対する遅延は0であってもよい。

【0702】

6.6.1.15 MSDU Aggregation Element
MSDU Aggregation要素は、A-MSDUフレームにおける複数のMSDUのアグリゲーションを担う。

【0703】

MSDU Length:フィールドはオクテット単位の後続のMSDUの長さを含む。

【0704】

ACK Request:このフィールドは(いくつかの例では)、MSDU Aggregation要素に含まれるMSDUが保護される場合は1に設定されるものとし、それ以外の場合は0に設定されるものとする。

【0705】

MSDU Sequence Number:送信機によってMSDUに割り当てられるシーケンス番号。このフィールドは(いくつかの例では)、ACK Requestフィールドが1に設定される場合にのみ存在する。

【0706】

MSDU:このフィールドはアグリゲートされるべきMSDUを含む。

【0707】

MSDU FCS:6.2.1項に従って計算されるMSDU CRCチェックサム。

【0708】

6.6.1.16 ACK Information Element
図11-43は、ACK情報要素の例を示す。

【0709】

ACK Information要素は、MPDUの受信機によって、そのMPDUの受信の成功をMPDUの送信機にシグナリングするために使用される。

【0710】

Device Short Address:MPDUを受信した、肯定応答するデバイスの短いアドレス。

【0711】

Sequence Number:肯定応答されるべきMPDUのシーケンス番号。

【0712】

6.6.1.17 Block ACK Request Element
図11-44は、ブロックACK要求要素の例を示す。

【0713】

Block ACK Request要素は、受信機からの受信の成功に対する肯定応答を要求するためにMPDUの送信機によって使用される。

【0714】

Device Short Address:MPDUを受信した、肯定応答するデバイスの短いアドレス。このフィールドは(いくつかの例では)、含まれるだけであるものとする。

【0715】

Sequence Number:肯定応答されるべきMPDUのシーケンス番号。

【0716】

6.6.1.18 Block ACK Element
図11-43は、ブロックACK要素の例を示す。

【0717】

Block ACK要素は、成功した受信を送信機にまとめてシグナリングするために、複数のMPDUの受信機によって使用される。この要素は(いくつかの例では)、マルチキャストアドレスでもブロードキャストアドレスでもないソースアドレスを有するフレームにおいてのみ送信されるものとする。

【0718】

Bitmap Width:含まれる肯定応答の最大の数。このフィールドは、ACK Bitmapフィールドの幅を整数個のオクテットとして決定する。ビットマップの実際の幅は、Bitmap Widthフィールドに含まれる整数に1を足したものである。

【0719】

First Sequence Number:後続のACK Bitmapフィールドにおける最初のビットに対応するシーケンス番号。

【0720】

ACK Bitmap:実際の肯定応答情報。ビットマップは、Bitmap Width+1オクテットの幅である。Block ACK要素の送信機は(いくつかの例では)、望まれる数の肯定応答をビットマップが保持できるように、ビットマップの幅を選択するものとする。

【0721】

ビットマップにおいて、一番右のビット、すなわち6.1.1において与えられる定義によって最後に処理されることになるビットは、First Sequence Numberフィールドにおいて与えられるような、第1のシーケンス番号に対応する。一番左のビット、すなわち最後に処理されることになるビットは、シーケンス番号
First Sequence Number+(Bitmap Width+1)*8-1
に対応する。

【0722】

1つ1つの受信に成功したMPDUに対して、Block ACK要素の送信機は(いくつかの例では)、そのシーケンス番号に対応するビットを1に設定するものとする。すべての他のビットは(いくつかの例では)0に設定されるものとする。

【0723】

00001(1)というBitmap Widthおよび321という第1のシーケンス番号を伴うACK Bitmapフィールドは、シーケンス番号320、321、322、324、325、326、327、328、329、330、332、333が受信に成功した場合、次のように見える。

【0724】

【表15】

【0725】

6.6.1.19 MCS Request Element
図11-46は、MCS要求要素の例を示す。

【0726】

MCS Request要素は、将来の送信機によるあるMCSの使用を要求するために、送信の将来の受信機によって使用される。MCS Request要素は、PM-PHYとともに使用されてもよい。

【0727】

Requested MCS ID:要求されるMCSのID。MCS IDは(いくつかの例では)、PM-PHYに対する有効なMCSであるものとする。

【0728】

6.6.1.20 BAT Request Element
図11-47は、BAT要求要素の例を示す。

【0729】

BAT Request要素は、あるビットローディングおよびエラーコーディング方式を使用するように送信機に要求するために、HB-PHYを使用する受信するデバイスによって使用されてもよい。

【0730】

Valid BAT Bitmap:有効であるように要求されるBATを指定する。

【0731】

Updated BAT:更新されるべきBATのIDを指定する。

【0732】

FEC Block Size:

【0733】

【表16】

【0734】

FEC Code Rate:要求されるFECコーディングレートを指定する。有効な値および対応するコードレートがTable 11(表17)に列挙される。

【0735】

【表17】

【0736】

BAT Group 1…N:サブキャリアのn番目のグループに対する変調を記述するBAT Group要素。(いくつかの例では)すべてのサブキャリアをカバーするのに十分なグループがあるものとする。最後のグループはサブキャリアの残りの数より広くてもよい。それらの余剰のサブキャリアに対する要求される変調は(いくつかの例では)無視されるものとする。

【0737】

6.6.1.20.1 BAT Group Element
図11-48は、BATグループ要素の例を示す。

【0738】

BAT Group要素は、ビットローディング対応PHY送信においてロードされる同じ数のビットを有する、隣接するサブキャリアのグループについての情報を含む。

【0739】

Grouping:このフィールドは、このグループの中のサブキャリアの数を含む。有効な値は、
1、2、4、8、16、32、64、128、256、512、1024、2048、4096
である。

【0740】

Loaded Bits:グループの各サブキャリアにロードされるビットの数。有効な値は、
0、1、2、3、4、5、6、7、8、9、10、11、12
である。

【0741】

6.6.1.21 Queue State Element
図11-49は、キュー状態要素の例を示す。

【0742】

Queue State要素は、他のデバイスにMSDUキューの状態について知らせるために、デバイスによって送信される。

【0743】

6.6.1.22 HCM Allocation Element
図11-50は、HCM割振り要素の例を示す。

【0744】

HCM Allocation要素は、1つまたは複数のHCM行をデバイスに割り振るために使用される。

【0745】

HCM Mask:デバイスに割り当てられるHCM行。各ビットはHCM行に対応する。MSBit、すなわち一番左のビットは行0に対応し、一方で一番右のビットは行7に対応する。

【0746】

6.6.1.23 Alien Signal Element
図11-51は、外来信号要素の例を示す。

【0747】

Alien Signal要素は、受信されたが同じOWPAN(またはより一般的には同じネットワーク)のメンバーであるデバイスに由来するものではないと特定された信号についての情報を含んでもよい。

【0748】

Signal Power:外来信号のdBm単位の光パワーを指してもよい。

【0749】

Decodable:このビットは(いくつかの例では)、外来信号がPHYおよびMACによって復号可能である場合にのみ1に設定されるものとする。これは、別のIEEE 802.15.13デバイスにその信号が由来する場合に当てはまるべきである。

【0750】

Same MAC Mode:このビットは(いくつかの例では)、受信されたフレームが、5.2および5.3においてそれぞれ定義されるものと同じチャネルアクセスモードを使用するIEEE 802.15.13 OWPANに由来する場合にのみ、1に設定されるものとする。

【0751】

OWPAN ID Clash:このビットは(いくつかの例では)、受信されたフレームが、同じOWPAN IDを有するOWPANに由来する場合にのみ、1に設定されるものとする。

【0752】

Foreign OWPAN ID:このフィールドは(いくつかの例では)、OWPAN ID Clashフィールドが0に設定された場合にのみ存在するものとする。このフィールドは、外来フレームがそれから受信された外部ネットワークのOWPAN IDを含む。

【0753】

Foreign Device Address:このフィールドは(いくつかの例では)、Decodableフィールドが1に設定された場合にのみ存在するものとする。このフィールドは、外部の送信するデバイスのDevice Short Addressを含む。アドレスが未知である場合、このフィールドは(いくつかの例では)短いブロードキャストアドレスに設定されるものとする。

【0754】

6.6.1.24 Supported MCS Element
図11-52は、サポートされるMCS要素の例を示す。

【0755】

Supported MCS要素は、デバイスのサポートされるレートのセットを伝えるために使用されてもよい。考えられる含まれる値は、使用されるPHYに依存する。

【0756】

PHY ID:以下のPHY Rates要素がそれに対して固有であるPHYのID。

【0757】

PHY Rates Element:それぞれのPHY項において定義されるようなPHY固有のPHY Rates要素。

【0758】

6.6.1.25 OFE Selection Element
図11-53は、OFE選択要素の例を示す。

【0759】

OFE Selection要素は、複数のOFEとデバイスとの間のチャネルの測定を担う連続的なフィールドを含む。

【0760】

6.6.1.26 Waveform Control Element
図11-54は、進化した6.6.1.26 Wave Control Elementの例を示す。

【0761】

波形制御フレームは、適応OFDM技法に関する。eU-OFDMおよびRPO-OFDMなどの複数の波形がネットワークに存在してもよい。制御フレームは、波形の適応的な調整が必要とされるときに使用され得る。

【0762】

Timestamp:Timestampフィールドは、OWPANの中のデバイス間の同期を可能にする。OWPANのマスタータイムキーパーは、それがアクティブであったマイクロ秒数を定期的に送信する。カウンタは、最大の値に達するとラップアラウンドする。

【0763】

OWPAN ID:OWPAN IDフィールドはOWPANのIDを与える。

【0764】

New Waveform:これらの8ビットは、IEEE 802.15.13によるサポートされる波形の間で切り替えるために、波形を示すものである。

【0765】

6.6.1.27 Advanced Modulation Control Element
図11-55は、Advanced Modulation Control Elementの例を示す。

【0766】

進化した変調制御フレームは、通信ノードの進化した変調能力を示す。

【0767】

Adaptive Loading:進化した変調制御フレームを送信する通信ノードが適応ビットおよびエネルギーローディングをサポートするかどうかを、単一のビットが示す:
「1」は、適応ビットおよびエネルギーローディングがサポートされることを示す。
「0」は、適応ビットおよびエネルギーローディングがサポートされないことを示す。

【0768】

eU:これらの4ビットは、ノードがeU-OFDMをサポートするかどうかを示す。4つの位置のうちの所与の位置のビット値は、ビット位置と同じ数のストリームを伴うeU-OFDMの実装形態がサポートされるかどうかを示す。位置は左から右にカウントされ、たとえば、
「1000」は1つのストリームを伴うeU-OFDMだけが(いくつかの例では)サポートされることを示す。
「1100」は1つおよび2つのストリームを伴うeU-OFDMだけが(いくつかの例では)サポートされることを示す。
「1010」は1つおよび3つのストリームを伴うeU-OFDMだけが(いくつかの例では)サポートされることを示す。
「1111」はすべての考えられるストリームを伴うeU-OFDMがサポートされることを示す。
「0000」はeU-OFDMがサポートされないことを示す。

【0769】

RPO:進化した変調制御フレームを送信する通信ノードがRPO-OFDMをサポートするかどうかを、単一のビットが示す。
「1」は、RPO-OFDMがサポートされることを示す。
「0」は、RPO-OFDMがサポートされないことを示す。

【0770】

Relaying:この4ビットは、進化した変調制御フレームを送信する通信ノードがサポートする中継動作のタイプを示す。

【0771】

第1のビットは、FDにおける中継がサポートされるかどうかを示す。
「1」は、FDにおける中継がサポートされることを示す。
「0」は、FDにおける中継がサポートされないことを示す。

【0772】

第2のビットは、HDにおける中継がサポートされるかどうかを示す。
「1」は、HDにおける中継がサポートされることを示す。
「0」は、HDにおける中継がサポートされないことを示す。

【0773】

第3のビットは、AF中継がサポートされるかどうかを示す。
「1」は、AF中継がサポートされることを示す。
「0」は、AF中継がサポートされないことを示す。

【0774】

第4のビットは、DF中継がサポートされるかどうかを示す。
「1」は、DF中継がサポートされることを示す。
「0」は、DF中継がサポートされないことを示す。

【0775】

MIMO:進化した変調制御フレームを送信する通信ノードがMIMO通信をサポートするかどうかを、単一のビットが示す。
「1」は、MIMOがサポートされることを示す。
「0」は、MIMOがサポートされないことを示す。

【0776】

MIMO Channel Number:これらの4ビットは、進化した変調制御フレームを送信する通信ノードがサポートするMIMO通信チャネルの最大の数を示す。

【0777】

「0000」という値は1個のチャネルに対応し、「1111」という値は16個のチャネルに対応する。

【0778】

6.6.1.28 Random Access Element
図11-56は、ランダムアクセス要素の例を示す。

【0779】

Random Access要素は、非ビーコン対応チャネルアクセスモードにおけるランダムアクセス手順を惹起するために使用される情報を含む。

【0780】

さらに、Random Accessフレームは、非ビーコン対応ネットワークの存在を告知する。それらは、デバイスがネットワークを発見し識別して、場合によってはそれに参加することを可能にするために、調整器によって一定の間隔で(すなわち、各ランダムアクセス間隔で)送信される。ランダムアクセスフレームは、丁度ランダムアクセス間隔が終了するときに、いわゆるターゲットランダムアクセス送信時間(TBTT)において送信されことになっている。インフラストラクチャネットワークにおいて、調整器は、タイムスタンプ、OWPAN ID、および調整器に関する他のパラメータなどの情報を伴うRandom Accessフレームを、範囲内にあるデバイスに送信することを担う。

【0781】

Timestamp:Timestampフィールドは、OWPANの中のデバイス間の同期を可能にする。調整器がBeaconフレームを送信する準備をするとき、調整器タイマーは、Beaconのタイムスタンプフィールドに複製される。調整器と関連付けられるデバイスは、任意の受信されたBeaconの中のタイミング値を受け入れるが、それらは、アンテナおよびトランシーバによるローカル処理を考慮するために、小さいオフセットを受信されたタイミング値に追加してもよい。

【0782】

Random Access Interval:各OWPANは、それ自体の固有の間隔でRandom Accessフレームを送信することができる。

【0783】

Capability Information:ネットワークの能力をアドバタイズするために、16ビットのCapability Informationフィールドが使用される。このフィールドにおいて、各ビットは、ネットワークの特定の機能をアドバタイズするためのフラグとして使用される。デバイスは、OWPANにおけるすべての特徴をデバイスがサポートできるかどうかを決定するために、能力アドバタイズメントを使用する。能力アドバタイズメントの中のすべての特徴を実装しないデバイスは、参加することが許可されない。

【0784】

OWPAN ID:OWPAN IDフィールドはOWPANのIDを与える。

【0785】

Supported Rates:いくつかのデータレートが、IEEE 802.15.13において各PHYに対して標準化されている。モバイルデバイスがネットワークに参加することを試みるとき、モバイルデバイスはネットワークにおいて使用されるデータレートを確認する。いくつかのレートは必須でありモバイルデバイスによりサポートされなければならないが、他のレートは任意選択である。

【0786】

Country:初期の仕様は、主要先進国において課されている既存の規制要件に沿って設計された。新しい国が追加される度に仕様を改訂し続けるのではなく、ネットワークが新しい局に対する規制要件を記述するための方法を提供する、新しい仕様が追加された。最大の送信パワーは、ビーコンフレームの中の国要素を使用して指定される。この情報は、ネットワークにアソシエートすることを望むあらゆる局に対して利用可能である。Country要素は規制上の最大パワーを指定し、ネットワークに固有のより低い最大送信パワーを指定するためにPower Constraint要素が使用され得る。

【0787】

Extended Supported Rates:Extended Supported Rates要素は、8個より多くのデータレートを扱うように標準化された。

【0788】

6.6.1.29 Attribute Change Request Element
図11-57は、属性変更要求要素の例を示す。

【0789】

Attribute Change Request要素は、アソシエートされたデバイスのPIB属性値を変更するために、OWPANの調整器によって使用されてもよい。

【0790】

Attribute ID:このフィールドは、更新されるべき属性を示す。所与の属性のIDはTable 34(表41)において見出され得る。

【0791】

New Value:属性に割り当てるべき新しい値。フィールドフォーマットは、Table 34(表41)から推論されることになる。

【0792】

6.6.1.30 Attribute Change Response Element
図11-58は、属性変更応答要素の例を示す。

【0793】

Attribute Change Response要素は、属性変更が成功したかどうかを示すために、Attribute Change Request要素への応答としてデバイスから調整器に送信される。

【0794】

Attribute ID:このフィールドは更新されるべき属性を示す。所与の属性のIDはTable 34(表41)において見出され得る。

【0795】

New Value:属性に割り当てられる新しい値。フィールドフォーマットは、Table 34(表41)から推論されることになる。

【0796】

Status:以前の属性変更要求の結果。とり得る値がTable 12(表18)に記述される。

【0797】

【表18】

【0798】

6.6.1.31 Variable Element Container Element
図11-59は、可変要素コンテナ要素の例を示す。

【0799】

Variable Element Container要素は、1つまたは複数の他の要素を備える。

【0800】

Multiple Elements:このビットは、複数の要素が後続のフィールドに含まれるかどうかを示す。

【0801】

Size Prefix:

【0802】

Contained Element 1…N:含まれる要素。

【0803】

7 MACサービス
IEEE 802.15.13 MACは、それぞれMCPS-SAPおよびMLME-SAPを通じて、より高次のプロトコルレイヤおよびDMEにサービスを提供する。MCPS-SAPは、IEEE 802.1ACに従って、ブリッジングされたLANにおけるIEEE 802.15.13ネットワークの統合をサポートするプリミティブを含む。MLME-SAPは、基本的な管理機能およびさらに進化した機能をDMEに公開する。

【0804】

サービスユーザ、すなわちより高次のレイヤに由来するプリミティブ呼び出しは、サフィックス.requestを持つ。したがって、それは、次に低いレイヤであるサービスプロバイダに対するサービス、すなわちアクションの開始を要求する。.requestに対する即刻の応答は、サービスプロバイダ、すなわちMACまたはMLMEによって返される、.confirmプリミティブである。

【0805】

MACまたはMLMEにおいて外部的に引き起こされるイベントは、.indicationサフィックスを持つプリミティブを通じてより高次のレイヤに示される。そのようなイベントは、要求されないアクション、たとえば、特定の管理フレームの受信に由来することがあり、または、先行するサービス要求を通じた終了したサービス呼び出しへの同期しない応答として発生することがある。

【0806】

PIB属性の数は、MACの挙動を定義し、現在のシステム状態を反映する。

【0807】

その上、能力は、所与のデバイスの実装形態によってサポートされる本開示の機能の一部を示す。それらの能力は、デバイスが所与のOWPANにアソシエートされている間に使用され得る機能をネゴシエートするために使用される。

【0808】

7.1 MCPS-SAP
MCPS-SAPは、Table 13(表19)に列挙されるプリミティブを通じて、ピアIEEE 802.15.13デバイスのMAC間でのMSDUの伝送をサポートする。

【0809】

【表19】

【0810】

7.1.1 MCPS-DATA.request
MCPS-DATA.requestプリミティブは、別のデバイスへのデータの移送を要求するためにより高次のレイヤによって使用される。

【0811】

このプリミティブのパラメータはTable 14(表20)に列挙される。

【0812】

【表20】

【0813】

7.1.2 MCPS-DATA.indication
MCPS-DATA.indicationプリミティブは、ピアデバイスからMSDUを受信するとデバイスのMACによって出される。

【0814】

このプリミティブのパラメータはTable 15(表21)に列挙される。

【0815】

【表21】

【0816】

7.2 MLME-SAP
MLME-SAPは、DMEを通じてデバイスのMLME機能の管理および使用をサポートする。

【0817】

【表22】

【0818】

7.2.1 MLME-ASSOCIATE
MLME-ASSOCIATEプリミティブは、5.4.5項において説明されるようなOWPANとのデバイスのアソシエーションプロセスを担う。

【0819】

7.2.1.1 Request
MLME-ASSOCIATE.requestは、所与のOWPANとのアソシエーションプロセスを開始するために、DMEによってデバイスMACに出される。プリミティブを受信すると、MLMEは(いくつかの例では)、5.4.5において詳述されたようなアソシエーション手順を開始する。

【0820】

デバイスのMLMEが異なるターゲットOWPAN IDに対する複数のMLME-ASSOCIATE.requestプリミティブを受信する場合、それは(いくつかの例では)、第1の要求以外のすべての要求を廃棄し、別の要求を受け入れる前にその完了またはタイムアウトを待機するものとする。

【0821】

このプリミティブのパラメータはTable 17(表23)に列挙される。

【0822】

【表23】

【0823】

7.2.1.2 Indication
MLME-ASSOCIATE.indicationプリミティブが、先行するMLME-ASSOCIATE.requestプリミティブの結果を報告するためにMLMEによって出される。

【0824】

このプリミティブのパラメータはTable 18(表24)に列挙される。

【0825】

【表24】

【0826】

7.2.2 MLME-AUTHENTICATE
MLME-AUTHENTICATEプリミティブは、以前に認証を要求したデバイスをOWPAN調整器のDMEが認証することを可能にする。

【0827】

7.2.2.1 Request
MLME-AUTHENTICATE.requestプリミティブは、要求するデバイスの認証を許可または拒否するために調整器DMEによって出される。このプリミティブは、先行するMLME-AUTHENTICATE.indicationプリミティブの後に呼び出される。

【0828】

このプリミティブのパラメータはTable 19(表25)に列挙される。

【0829】

【表25】

【0830】

7.2.2.2 Indication
MLME-AUTHENTICATE.indicationプリミティブは、アソシエーションを試みるデバイスからAuthentication Request要素を受信すると、調整器MACによってDMEに出される。

【0831】

このプリミティブのパラメータはTable 20(表26)に列挙される。

【0832】

【表26】

【0833】

7.2.3 MLME-DISASSOCIATE
MLME-DISASSOCIATEプリミティブは、OWPANから所与のデバイスをアソシエート解除するために呼び出される。このプリミティブは、5.4.6において説明されたように、参加者デバイスまたはOWPAN調整器によって呼び出されてもよい。

【0834】

7.2.3.1 Request
MLME-DISASSOCIATE.requestは、5.4.6において説明されたようなアソシエーション解除手順で開始することをMLMEに示す。

【0835】

プリミティブのパラメータはTable 21(表27)に列挙される。

【0836】

【表27】

【0837】

7.2.3.2 Indication
MLME-DISASSOCIATE.indicationは、OWPANからのデバイスのアソシエーション解除を示すためにMACによって呼び出される。それは、OWPANの調整器デバイスまたは参加者デバイスのMLMEによって使用されてもよい。

【0838】

プリミティブのパラメータはTable 22(表28)に列挙される。

【0839】

【表28】

【0840】

7.2.4 MLME-GET
MLME-GETプリミティブは、DMEがある可読のMACおよびPHY PIB属性の値を取得することを可能にする。

【0841】

7.2.4.1 Request
MLME-GET.reqeustプリミティブを受信すると、MLMEは(いくつかの例では)、要求されたMACまたはPHY PIB属性をその情報ストレージから読み取るものとする。

【0842】

このプリミティブのパラメータはTable 23(表29)に列挙される。

【0843】

【表29】

【0844】

7.2.4.2 Confirm
MLME-GET.confirmプリミティブは、先行するMLME-GET.requestプリミティブへの応答としてMLMEによって出される。

【0845】

このプリミティブのパラメータはTable 24(表30)に列挙される。

【0846】

【表30】

【0847】

7.2.5 MLME-SET
MLME-SETプリミティブは、ある書き込み可能なMACおよびPHY PIB属性の値をDMEが変更することを可能にする。

【0848】

7.2.5.1 Request
MLME-GET.requestプリミティブを受信すると、MLMEは(いくつかの例では)、AttributeValueパラメータを用いて提供される値を有するように、要求されたMACまたはPHY PIB属性を設定するものとする。

【0849】

PIB属性がOWPAN動作構成に従って調整器によって設定される場合、それは(いくつかの例では)MLME-SET.requestプリミティブを介して書き込み可能ではないものとする。

【0850】

読取り専用属性を設定することが試みられる場合、MLMEは(いくつかの例では)、FailureReasonパラメータがREAD_ONLYに設定された対応するconfirmにおいて応答するものとする。

【0851】

このプリミティブのパラメータはTable 25(表31)に列挙される。

【0852】

【表31】

【0853】

7.2.5.2 Confirm
MLME-SET.confirmプリミティブを出すことを通じて、MLMEは以前のMLME-SET.requestに対応する。

【0854】

プリミティブのパラメータはTable 26(表32)に列挙される。

【0855】

【表32】

【0856】

7.2.6 MLME-SCAN
MLME-SCANプリミティブは、既存のOWPANに対するスキャンを行うようにMLMEに要求する際に、DMEをサポートする。

【0857】

7.2.6.1 Request
MLME-SCAN.requestは、スキャン手順を開始するためにDMEによって出される。

【0858】

このプリミティブのパラメータはTable 27(表33)に列挙される。

【0859】

【表33】

【0860】

7.2.6.2 Confirm
MLME-SCAN.confirmプリミティブは、DMEにスキャンの結果を報告するためにMLMEによって使用される。

【0861】

このプリミティブのパラメータはTable 28(表34)に列挙される。

【0862】

【表34】

【0863】

ResultListパラメータは(いくつかの例では)、Table 29(表35)に列挙される要素を1つ1つのエントリが有するリストを含むものとする。

【0864】

【表35】

【0865】

7.2.7 MLME-START
MLME-STARTプリミティブは、調整器となり新しいOWPANの動作を開始するようにデバイスMACに指示するために使用される。

【0866】

7.2.7.1 Request
MLME-START.requestプリミティブは、DMEによって出されてMLMEによって受信され、OWPANを開始するための手順を惹起する。

【0867】

MLME-START.requestプリミティブは(いくつかの例では)、後続のMLME-START.confirmプリミティブ呼び出しを通じてMLMEによって確認される。

【0868】

このプリミティブのパラメータはTable 30(表36)に列挙される。

【0869】

【表36】

【0870】

7.2.7.2 Confirm
MLMLE-START.confirmプリミティブは、新しいOWPANを開始するための先行する要求の結果を報告するために調整器MLMEによって出される。

【0871】

このプリミティブのパラメータはTable 31(表37)に列挙される。

【0872】

【表37】

【0873】

7.2.8 MLME-STOP
MLME-STOPプリミティブは、動作中のOWPANの動作を止めるために、調整器のDMEによって出される。

【0874】

7.2.8.1 Request
MLME-STOP.requestプリミティブは、動作中のOWPANを止めるために、アクティブ調整器のDMEによってMLMEに出される。

【0875】

このプリミティブのパラメータはTable 32(表38)に列挙される。

【0876】

【表38】

【0877】

7.2.8.2 Confirm
MLME-STOP.confirmプリミティブは、先行するMLME-STOP.requestプリミティブへの応答として調整器のMLMEによって出される。

【0878】

このプリミティブのパラメータはTable 33(表39)に列挙される。

【0879】

【表39】

【0880】

7.3 PIB Attributes
MACは、その挙動を定義する変数および定数を備える。MACの状態は、そのキューの状況ならびにその変数および定数の現在値を通じて定義される。変数および定数は「PIB属性」と呼ばれる。

【0881】

Table 34(表40)およびTable 35(表41)は、変数および定数のPIB属性を列挙する。それは、属性の名称、定数またはとり得る値の空間についての説明および情報、ならびに関連する単位を提供する。一部の変数は(いくつかの例では)、それぞれMLME-GET.requestおよびMLME-SET.requestを介して、読み取り可能であり書き込み可能であるものとする。変数が読み取られ得るか、または書き込まれ得るかは、読み取りについてはget/set列におけるgetによって示され、書き込みについてはsetによって示される。完全にMACの内部にある属性は、読み取り可能でも書き込み可能でもない。

【0882】

PHY PIB Attributes
PHY PIB属性は、MAC PIB属性がMACのために何をするかということと同様に、MACの挙動を決定する。PLME-SAPが指定されていないので、PHY PIB属性の管理は実装者に任される。しかしながら、必要な場合、属性をDMEからアクセス可能にするために、一部のPHY PIB属性は、MLME-GETプリミティブおよびMLME-SETプリミティブを介して、読み取られ、または書き込まれ得る。このようにして、r/w列は、属性が読み取り可能であるか、または書き込み可能であるかを示す。

【0883】

【表40】

【0884】

【表41】

【0885】

【表42】

【0886】

7.4 Capabilities
能力は、デバイスによってサポートされる、すなわち実装される機能を正式に示す。各能力は、16ビットの幅を伴う名称および数値IDを有する。一部の能力は、他の能力がデバイスを通じて実装されることを必要とすることがある。能力はTable 36(表43)に列挙される。

【0887】

【表43】

【0888】

8 セキュリティ
MACサブレイヤは、指定される入来フレームと発信フレーム上のセキュリティサービスを提供することを担う。本開示は、以下のセキュリティサービスをサポートする。
・データ機密性
・データ真正性
・リプレイ保護

【0889】

本開示は、異なるセキュリティタイプの使用をサポートする。この目的で、MACプロトコルにおける複数のアプローチの区別を容易にするために、1つ1つの別個のセキュリティタイプにIDが割り当てられる。Table 37(表44)は、異なるセキュリティタイプおよびそれらの対応するID、ならびにそれらが説明される項を列挙する。

【0890】

【表44】

【0891】

Open Systemsセキュリティを除き、各セキュリティタイプは、適用される暗号化アルゴリズムおよび認証方法によって表記される。各セキュリティタイプは、既存のプロトコル手順を利用してもよい。たとえば、アソシエーションの間、認証ハンドシェイクのための一般的なフィールドが交換されるフレームに含まれる。

【0892】

8.1 一般的なセキュリティの説明
IEEE 802.15.13規格において、セキュリティは主に2つの処理に影響を及ぼす。
1.OWPANがセキュアである場合、OWPANとのアソシエーション
2.MSDUおよび管理MPDUの送信と受信

【0893】

[セキュリティを含む最大のMPDUサイズ!]

【0894】

8.2 Open Systems

【0895】

8.3 AES-256 PSK

【0896】

8.4 AES-256 EAPOL

【0897】

9 PHY機能説明
この項は、802.15.13規格に含まれるすべてのPHYに共通の、一般的なPHY機能を説明する。

【0898】

9.1 一般的なPHY機能
9.1.1 基本レート
各PHYは基本レートを定義し、これは、ビーコンまたはRA制御フレームなどの特定のフレームを送信するために使用される。

【0899】

9.1.2 ターンアラウンドタイム
PHYが時分割半二重モードで動作する場合、送信モードと受信モードを切り替えるにはある時間を必要とすることが予想される。

【0900】

10 PHYサービス
10.1 PHY-SAP

【0901】

10.2 PLME-SAP

【0902】

10.3 PHY PIB Attributes
PHY PIB属性は、MAC PIB属性がMACのために何をするかということと同様である、MACの挙動を決定する。PLME-SAPが指定されないので、PHY PIB属性の管理は実装者に任される。しかしながら、必要な場合に属性をDMEからアクセス可能にするために、一部のPHY PIB属性は、MLME-GETプリミティブおよびMLME-SETプリミティブを介して読み取られ、または書き込まれ得る。このようにして、r/w列は、属性が読み取り可能であるかまたは書き込み可能であるかを示す。

【0903】

【表45】

【0904】

11 PM-PHY
[文書15-18-0003-07-0013参照]

【0905】

12 LB-PHY
[文書15-18-0267-05-0013参照]

【0906】

13 HB-PHY
[文書15-18-0273-02-0013参照]

【0907】

一部の総括
態様Iは、[たとえば、光]通信設備(15)[たとえば、LEDなどの複数の光フロントエンド(14)を伴う][たとえば、ネットワーク調整器を含む設備]として設備15を用意することによって得られる解決法に基づくものとして理解されてもよく、および/もしくは、[たとえば、光]通信設備(15)は、割り振られた[たとえば、「付与された」]タイムスロット[たとえば、GTS]において情報を送信する[ならびに/または、ネットワークにおける通信デバイスへのリソース割振りをシグナリングおよび/もしくは決定する]ように構成され、および/もしくは、[たとえば、光]通信設備(15)は、1つまたは複数の管理フレームに含まれる構成情報(700、710)を送信するように構成され、ならびに/または、
[たとえば、光]通信設備(15)は、1つまたは複数の制御フレームに含まれる構成情報を送信するように構成され、および/もしくは、通信設備(15)は、[たとえば、準静的な]第1のタイムスロット付与[たとえば、GTS]情報(710)を送信するように構成され、これは管理フレームに含まれ[および、たとえば、期限切れにならない、ならびに/または、新しいタイムスロット付与情報によって上書きされるまで有効なままである]、ならびに/または、
通信設備(15)は、制御フレームに含まれる[たとえば、動的な]第2のタイムスロット付与[たとえば、GTS]情報(700)を送信するように構成され、これは限定的な時間有効性を備え[たとえば、1つだけのスーパーフレームまたは指定された数のスーパーフレーム、限定的な有効性は第2のタイムスロット付与情報の有効性フィールドにおいて任意選択で定義されてもよい]、ならびに/または、
通信設備(15)は、第1のタイムスロット付与情報(710)に応じて、および第2のタイムスロット付与情報(700)に応じて、通信のために1つまたは複数のタイムスロットを割り振るように構成される。

【0908】

さらに、[たとえば、光]通信方法[たとえば、LEDなどの複数の光フロントエンドを用いた][たとえば、スケジューリング情報および/もしくは異なる光デバイスへの他のリソース割振りを送信ならびに/またはシグナリングするための]である方法が開発され、この方法は、
[たとえば、[たとえば、光]通信設備(15)において、割り振られた[たとえば、「付与された」]タイムスロット[たとえば、GTS]において情報を送信するステップ]、および/または、
[たとえば、光]通信設備(15)から、1つまたは複数の管理フレームに含まれる構成情報を送信するステップ、および/または、
[たとえば、光]通信設備(15)から、1つまたは複数の制御フレームに含まれる構成情報を送信するステップ、および/または、
[たとえば、光]通信設備(15)から、[たとえば、準静的な]第1のタイムスロット付与[たとえば、GTS]情報を送信するステップであって、これが管理フレームに含まれる[および、たとえば期限切れにならず、ならびに/または、新しいタイムスロット付与情報によって上書きされるまで有効なままである]、ステップ、および/または、
[たとえば、光]通信設備(15)から、制御フレームに含まれる[たとえば、動的な]第2のタイムスロット付与[たとえば、GTS]情報を送信するステップであって、これが限定的な時間有効性を備える[たとえば、1つだけのスーパーフレームまたは指定された数のスーパーフレーム、限定的な有効性は第2のタイムスロット付与情報の有効性フィールドにおいて任意選択で定義されてもよい]、ステップ、および/または、
[たとえば、光]通信設備(15)から、第1のタイムスロット付与情報に応じて、および第2のタイムスロット付与情報に応じて、通信のために1つまたは複数のタイムスロットを割り振るステップを含む。

【0909】

上記の通信デバイス(16、16'、16"、A、B、C、D)のうちの少なくとも1つは、[たとえば、光]通信デバイス(16)[たとえば、上記のものなどの通信設備(15)から送信を受信することになる、ならびに/または、スケジューリングおよび/もしくは他のリソース割振りに関するシグナリングを受信してもよい受信機]として定義されてもよく、
[たとえば、光]通信デバイスは、割り振られた[たとえば、「付与された」]タイムスロット[たとえば、GTS]において情報を受信するように構成され、および/または、
[たとえば、光]通信デバイスは、1つまたは複数の管理フレームに含まれる構成情報を受信するように構成され、および/または、
[たとえば、光]通信デバイスは、1つまたは複数の制御フレームに含まれる構成情報を受信するように構成され、および/または、
[たとえば、光]通信デバイスは、[たとえば、準静的な]第1のタイムスロット付与[たとえば、GTS]情報を受信するように構成され、これは管理フレームに含まれ[および、たとえば、期限切れにならない、ならびに/または、新しいタイムスロット付与情報によって上書きされるまで有効なままである]、および/または、
[たとえば、光]通信デバイスは、制御フレームに含まれる[たとえば、動的な]第2のタイムスロット付与[たとえば、GTS]情報を受信するように構成され、これは限定的な時間有効性を備え[たとえば、1つだけのスーパーフレームまたは指定された数のスーパーフレーム、限定的な有効性は第2のタイムスロット付与情報の有効性フィールドにおいて任意選択で定義されてもよい]、および/または、
[たとえば、光]通信デバイスは、第1のタイムスロット付与情報に応じて、および第2のタイムスロット付与情報に応じて、通信のために1つまたは複数のタイムスロットを割り振るように構成される。

【0910】

[たとえば、光]通信方法[たとえば、上記のものなどの通信設備(15)から送信を受信するように構成される、ならびに/または、スケジューリングおよび/もしくはリソース割振りに関するシグナリングを受信してもよい、たとえば光受信機における][たとえば、割り振られた[たとえば、「付与された」]タイムスロット[たとえば、GTS]において情報を受信する、[たとえば、光]通信デバイスにおける]である方法に従った方法が開発され、この方法は、
[たとえば、光]通信デバイスにおいて、1つまたは複数の管理フレームに含まれる構成情報を受信するステップ、および/または、
[たとえば、光]通信デバイスにおいて、1つまたは複数の制御フレームに含まれる構成情報を受信するステップ、および/または、
[たとえば、光]通信デバイスにおいて、[たとえば、準静的な]第1のタイムスロット付与[たとえば、GTS]情報を受信するステップであって、これが管理フレームに含まれる[および、たとえば、期限切れにならない、ならびに/または、新しいタイムスロット付与情報によって上書きされるまで有効なままである]、ステップ、および/または、
[たとえば、光]通信デバイスにおいて、制御フレームに含まれる[たとえば、動的な]第2のタイムスロット付与[たとえば、GTS]情報を受信するステップであって、これが限定的な時間有効性を備える[たとえば、1つだけのスーパーフレームまたは指定された数のスーパーフレーム、限定的な有効性は第2のタイムスロット付与情報の有効性フィールドにおいて任意選択で定義されてもよい]、ステップ、および/または、
[たとえば、光]通信デバイスにおいて、第1のタイムスロット付与情報に応じて、および第2のタイムスロット付与情報に応じて、通信のために1つまたは複数のタイムスロットを割り振るステップを含む。

【0911】

他の実施形態
様々な進歩性のある例、実施形態、および態様が説明される。

【0912】

また、さらなる例が、添付の特許請求の範囲によって定義される。

【0913】

特許請求の範囲によって定義されるような任意の実施形態が、以下の章において説明される詳細(特徴および機能)のいずれによっても補足され得ることに留意されたい。

【0914】

また、以下の章において説明される実施形態は個別に使用されることが可能であり、別の章における特徴のいずれかによって、または特許請求の範囲に含まれる任意の特徴によって補足されることも可能である。

【0915】

また、本明細書において説明される個々の態様は、個別に、または組み合わせて使用され得ることに留意されたい。したがって、前記態様の別の1つに詳細を追加することなく、前記個々の態様の各々に詳細が追加され得る。

【0916】

本開示は、モバイル通信デバイスの、およびモバイル通信システムの受信機の特徴を、明示的にまたは暗黙的に説明することにも留意されたい。したがって、本明細書において説明される特徴のいずれもが、モバイル通信デバイスの文脈において、およびモバイル通信システム(たとえば、衛星を備える)の文脈において使用され得る。したがって、開示される技法は、すべての静止衛星サービス(FSS)および移動衛星サービス(MSS)に適している。

【0917】

その上、方法に関する本明細書において開示される特徴および機能は、装置においても使用され得る。さらに、装置に関して本明細書において開示される任意の特徴および機能は、対応する方法においても使用され得る。言い換えると、本明細書において開示される方法は、装置に関して説明される特徴および機能のいずれかによって補足され得る。

【0918】

また、本明細書において開示される特徴および機能は、以下で説明されるように、ハードウェアもしくはソフトウェアで、または、ハードウェアとソフトウェアの組合せを使用して実装され得る。

【0919】

ある実装形態の要件に応じて、例はハードウェアで実装され得る。実装は、それぞれの方法が実行されるようにプログラマブルコンピュータシステムと協働する(または協働することが可能な)電気的読み取り可能制御信号が記憶されたデジタル記憶媒体、たとえば、フロッピーディスク、デジタル多用途ディスク(DVD)、Blu-Rayディスク(登録商標)、コンパクトディスク(CD)、読取り専用メモリ(ROM)、プログラマブル読取り専用メモリ(PROM)、消去可能プログラマブル読取り専用メモリ(EPROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、またはフラッシュメモリを使用して実行され得る。したがって、デジタル記憶媒体はコンピュータ可読であってもよい。

【0920】

一般に、例は、プログラム命令を伴うコンピュータプログラム製品として実装されてもよく、プログラム命令は、コンピュータプログラム製品がコンピュータ上で実行されるとき、方法のうちの1つを実行するために動作可能である。たとえば、プログラム命令は、機械可読媒体に記憶されてもよい。

【0921】

他の例は、機械可読担体に記憶された、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムを備える。言い換えると、方法の例は、したがって、コンピュータプログラムがコンピュータ上で実行されると本明細書において説明される方法のうちの1つを実行するためのプログラム命令を有する、コンピュータプログラムである。

【0922】

したがって、方法のさらなる例は、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムが記録されたデータ担持媒体(またはデジタル記憶媒体、またはコンピュータ可読媒体)である。データ担持媒体、デジタル記憶媒体、または記録媒体は、無形の一時的な信号ではなく、有形であり、および/または非一時的である。

【0923】

さらなる例は、本明細書において説明される方法のうちの1つを実行する、処理ユニット、たとえばコンピュータ、またはプログラマブル論理デバイスを備える。

【0924】

さらなる例は、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムがインストールされたコンピュータを備える。

【0925】

さらなる例は、本明細書において説明される方法のうちの1つを実行するためのコンピュータプログラムを受信機に(たとえば、電気的または光学的に)移す装置またはシステムを備える。受信機は、たとえば、コンピュータ、モバイルデバイス、メモリデバイスなどであってもよい。装置またはシステムは、たとえば、コンピュータプログラムを受信機に移すためのファイルサーバを備えてもよい。

【0926】

いくつかの例では、プログラマブル論理デバイス(たとえば、フィールドプログラマブルゲートアレイ)が、本明細書において説明される方法の機能の一部またはすべてを実行するために使用されてもよい。いくつかの例では、フィールドプログラマブルゲートアレイは、本明細書において説明される方法のうちの1つを実行するために、マイクロプロセッサと協働してもよい。一般に、方法は、任意の適切なハードウェア装置によって実行されてもよい。

【0927】

上で説明された例は、上で論じられた原理を説明するためのものである。本明細書において説明される構成および詳細の修正と変形は明らかであろうことが理解される。したがって、本明細書の例の記述および説明により提示される具体的な詳細ではなく、後の特許請求の範囲により限定されることが意図される。

【0928】

上の例の説明は、
中央ユニット、および/または
フロントエンド(たとえば、発光器、たとえばLEDまたは他の光トランシーバなどの、光フロントエンド)、および/または
有線ネットワーク(たとえば、PTPT、イーサネット、インターネット)であり得る、中央ユニットとフロントエンドとの間の通信手段(たとえば、フロントホール)
を含む通信設備(たとえば、ネットワーク調整器を含む)、
(たとえば、光学的に)フロントエンドに信号を送信しフロントエンドから信号を受信し得る、複数の通信デバイスの中にあり得る通信デバイス(たとえば、モバイルデバイス)
の少なくとも1つの要素を備え得る。

【0929】

例は、
通信デバイス間のリソース割振り(たとえば、付与されたまたはコンテンションベースのリソース)、
通信設備の異なるフロントエンド間の時間同期、
通信デバイスによって収集されるようなチャネル状態情報
より一般的には、MAC戦略(たとえば、光通信のための)
を指し得る。

【符号の説明】

【0930】

10 ネットワーク
11 ビーコン
12 調整器
14 光フロントエンド
15 通信設備
16 通信デバイス
17 フロントホール
18 チャネル
31 測定
32 フィードバック
53 有効性情報フィールド
54 更新BAT情報フィールド
55 BAT更新情報フィールド
61 BATメッセージ
700 第2のタイムスロット付与情報

【図1】

【図1a】

【図2】

【図2a】

【図3】

【図3a】

【図3b】

【図4】

【図4a】

【図5a】

【図5b】

【図5c】

【図6】

【図7a】

【図7b】

【図7c】

【図7d】

【図7e】

【図8】

【図8a】

【図8b】

【図8c】

【図8d】

【図9-1】

【図9-3】

【図9-4】

【図9-5】

【図9-6】

【図9-7】

【図10-8】

【図10-9】

【図10-10】

【図10-11】

【図10-12】

【図10-13】

【図10-14】

【図10-16】

【図10-17】

【図10-18】

【図10-19】

【図11-21】

【図11-22】

【図11-23】

【図11-24】

【図11-25】

【図11-26】

【図11-27】

【図11-28】

【図11-29】

【図11-30】

【図11-31】

【図11-32】

【図11-33】

【図11-34】

【図11-35】

【図11-36】

【図11-37】

【図11-38】

【図11-39】

【図11-40】

【図11-41】

【図11-42】

【図11-43】

【図11-44】

【図11-45】

【図11-46】

【図11-47】

【図11-48】

【図11-49】

【図11-50】

【図11-51】

【図11-52】

【図11-53】

【図11-54】

【図11-55】

【図11-56】

【図11-57】

【図11-58】

【図11-59】