JP2019525559A - ワイヤレス通信ネットワークにおける通信ノードの動作方法、関連する通信ノード、通信システム、および格納システム - Google Patents

Abstract

ワイヤレス通信ネットワークにおける通信ノードの動作方法を開示した。ノードは、少なくとも１つのアクセス・ポイントを経由して中央通信ユニットと通信する。この動作方法は、ノードにおいて、アクセス・ポイントからのワイヤレス信号を受信するステップと、ノードによって、受信したワイヤレス信号に基づいてチャネル品質情報を判定するステップと、ノードによって、判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定するステップと、ノードによって、決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択するステップと、ノードによって、選択したアクティブ・チャネル上でワイヤレス信号を送信するステップとを含む。この方法を実行する通信ノード、通信システム、およびこの通信ノードを含む格納システムも開示した。【選択図】図４

Description

本発明は、ワイヤレス通信技術に関する。
更に特定すれば、本発明は、ワイヤレス通信ネットワークにおける通信ノードの動作方法に関し、ノードが少なくとも１つのアクセス・ポイントを経由して中央通信ユニットと通信する。更に、本発明は、このようなワイヤレス通信ネットワークにおいて動作する通信ノードに関する。

また、本発明は、このような通信ノードが含まれる、ワイヤレス通信システムおよび格納システムに関する。

垂直スタックに積層された複数の収納庫を収容する三次元格納グリッドを含む格納システムは、オートストア(AutoStore)として知られている。グリッド構造上には支持レールが配置され、複数の車両がグリッド構造上のレールに沿って移動するように構成されている。

車両は、垂直スタックから収納庫を選出し(pick up)、これらの収納庫を所望の位置に移動させ、これらを垂直ポートに搬送し、更に、中央ユニットによって要求されたときには操作員に搬送するように、遠隔制御される。

このような格納システムの動作を可能にするために、ワイヤレス通信ネットワークが設けられる。各車両には通信ノードが提供され、通信ノードは、多数の通信アクセス・ポイントを経由して中央ユニットと通信する。アクセス・ポイントは、システム全体にわたって固定位置に位置付けられてもよい。

このような通信ノード、それらの動作方法、および通信システム全体を提供するとき、様々な課題が発生する。
例えば、このシステムは、物理的レイアウトおよび規模に関して汎用性がなければならない。使用中の車両数（および関連する通信ノード）は柔軟でなければならない。グリッドは、格納システムが設置される構内の物理的固有性(properties)によって決定される種々の形状をなすことができる。したがって、広範囲の異なる物理的トポロジを当然処理できる通信ノードを、車両に提供しなければならない。

ワイヤレス通信システムは、グリッド上の全ての位置に対して見通し線を有することが不可能であっても、全ての車両と常時通信できなければならない。信号を妨害する柱および壁のような、多数の障害物があるおそれがある。このような障害物は、反射を混入させる可能性もあり、ワイヤレス通信システムはこの反射も処理しなければならない(handle)る。

通信システムは、干渉する背景無線信号、例えば、Ｗｉ−Ｆｉ通信が存在しても、信頼性高く動作するとことが好ましい。更に、通信システムは、フェイルセーフ緊急時停止機能を提供することも好ましい。

また、通信速度、タイミング、およびスループット要件というような、一般的な要件も満たさなければならない。
その他の可能性のある要件および／または所望の固有性には以下が含まれる。

・ノード間通信を必要としない。
・多重ホップ・ルーティングを必要としない。
・短い応答時間が要求される。

・完全なデータよりも更新データの方が重要である。即ち、メッセージの損失の方が、長い遅延よりも優先することができる。
・ノードによって送信されるデータの量が、ノードによって受信されるデータの量よりもはるかに多い。

・中央ユニットは、ネットワーク・マネージャとして機能できなくてよい。
・ノードは、アクセス・ポイント間で素早く切り替えることができなければならない。
・データ負荷は、実質的に時間単位で(by time)変動することができる。

・ノードの割り当て容量の固定は望ましくない。
種々の標準化された通信プロトコルや、その他の既に知られている通信プロトコルが存在するが、これらは以上の要件および所望の固有性の内一部を満たすことができるに過ぎない。

しかしながら、既存の通信プロトコルの短所(shortcoming)および欠点(drawback)のために、ワイヤレス通信ネットワークにおける改良通信ノード動作方法、改良通信ノード、改良通信システム、および改良格納システムを提供することが求められている。

ＵＳ−２０１４／０８６０８１Ａ１は、ノードを含む通信システム、中央通信システム、およびアクセス・ポイントについて記載する。これらは、チャネル品質を判定し、整列チャネル・リストを提供するために使用する。整列リストにしたがって、アクティブな通信チャネルを選択する。整列チャネル・リストの提供、および整列リストにしたがうアクティブ・チャネルの選択は、中央ダイナミック・スペクトル管理エンジンに含まれるチャネル管理機能によって実行される。チャネル管理機能およびダイナミック・スペクトル管理エンジンは、通信システムにおいて中央エレメントとして設けられる。

本発明は、添付する独立請求項によって定められている。好ましい実施形態は、従属請求項によって定められている。
したがって、本発明の一態様では、ワイヤレス通信ネットワークにおける通信ノードの動作方法を提供する(has been provided)。この方法では、ノードは少なくとも１つのアクセス・ポイントを経由して中央通信ユニットと通信し、この方法は、
−ノードにおいて、アクセス・ポイントからのワイヤレス信号を受信するステップと、
−ノードによって、受信したワイヤレス信号に基づいてチャネル品質情報を判定するステップと、
−ノードによって、判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定するステップと、
−ノードによって、決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択するステップと、
−ノードによって、選択したアクティブ・チャネル上でワイヤレス信号を送信するステップと、
を含む。

他の態様では、ワイヤレス通信ネットワークにおいて動作する通信ノードを提供する。ネットワークは、このノード、中央通信ユニット、および少なくとも１つのアクセス・ポイントを含む。このノードは、
−アクセス・ポイントからのワイヤレス信号を受信し、
−受信したワイヤレス信号に基づいてチャネル品質情報を判定し、
−判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定し、
−決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択し、
−ノードによって、選択したアクティブ・チャネル上でワイヤレス信号を送信する、
ように構成されている。

中央通信ユニット、少なくとも1つのアクセス・ポイント、および本明細書において開示するような少なくとも１つの通信ノードを含むワイヤレス通信システムも、本発明によって提供する。

最後に、本発明は格納システムに関する。この格納システムは、垂直スタックに積層された複数の収納庫を収容する三次元格納グリッドと、グリッド構造上の支持レールと、格子構造上のレールに沿って移動するように配置された複数の車両であって、各車両が少なくとも1つのアクセス・ポイントを経由して中央通信ユニットと通信するように構成され、各車両が本明細書において開示するような通信ノードを含む、車両とを含む。

本発明の種々の態様および特徴について、理解を助ける例として示す添付図面と合わせて説明するが、開示する態様および特徴に本発明を限定するのではない。
図１は、格納システムの原理を示す模式図である。 図２は、通信システムの原理を示す模式ブロック図である。 図３は、通信ノードの原理を示す模式ブロック図である。 図４は、通信ノードの動作方法を示す模式フロー・チャートである。 図５は、基本ビーコン・シーケンス(basic beacon sequence)の原理を示す模式タイミング図である。 図６は、チャネル間の時間オフセットの原理を示す模式タイミング図である。 図７は、ビーコン送信のフェーズ(phase)の原理を示す模式タイミング図である。 図８は、通信シーケンスの種々の態様を示す、４つの模式タイミング図を含む。 図８は、通信シーケンスの種々の態様を示す、４つの模式タイミング図を含む。

図１は、格納システム１００の原理を示す模式図である。
格納システム１００は、垂直スタックに積層された複数の収納庫を収容する三次元格納グリッド構造１１０を含む。グリッド構造１１０の上面上に支持レール１２０が二次元的に配置されており、グリッド構造１１０の上面上に配置されたレールに沿って移動するように、複数の車両１３０が配置されている。

車両１３０は、垂直スタックから収納庫を選出し、これらの収納庫をグリッド構造１１０の上面上における所望の位置に移動させ、これらを垂直リフトおよび／またはポートに搬送し、中央ユニット１５０によって要求されたときに更に操作員まで搬送するように遠隔制御される。

このような格納システム１００の動作を可能にするために、ワイヤレス通信ネットワークが設けられている。各車両１３０には通信ノード（図１には示されていない）が設けられており、通信ノードは、多数の通信アクセス・ポイント１４０（簡略化のために１つだけ示されている）を経由して、中央ユニット１５０と通信する。通信アクセス・ポイント１４０は、システム１００全域にわたり固定位置に位置付けることができる。

図２は、通信システムの原理を示す模式ブロック図である。
図２において、４つの通信ノード３００ａ、３００ｂ、３００ｃ、３００ｄが示されている。各ノードは、格納システム１００内にある車両（図１に示す車両１３０のような）に含まれることを意図している。尚、１および２５０の間の任意の数というように、任意の適した数の通信ノードをこの通信システム内に設けることができることは理解されてしかるべきである。場合によっては、２５０個よりも多い通信ノードも使用することができる。一部のノードは、格納システムにおける車両のための通信ノードであること以外の目的に供することもできる。

各ノード３００ａ、３００ｂ、３００ｃ、３００ｄは、アクセス・ポイント１４０ａ、１４０ｂを経由して中央ユニット１５０と通信するように構成されている。図示のように、アクセス・ポイント１４０ａは、ノード３００ａとのワイヤレス通信を提供し、一方アクセス・ポイント１４０ｂは、ノード３００ｂ、３００ｃ、および３００ｄとのワイヤレス通信を提供する。ワイヤレス通信は、好ましくは、無線通信である。尚、１および１０の間の任意の数というように、任意の適した数のアクセス・ポイントを通信システム内に設けてもよいことは理解されてしかるべきである。場合によっては、１０箇所よりも多いアクセス・ポイントも使用することができる。尚、通信ノードとアクセス・ポイントとの間の連携(association)は、通信システムおよび格納システム１００の動作中に動的に変更できることは理解されてしかるべきである。

アクセス・ポイント１４０ａ、１４０ｂと中央ユニット１５０との間の通信は、場合によっては、例えば、電気または光接続による有線であってもよい。他の態様では、アクセス・ポイント１４０ａ、１４０ｂと中央ユニット１５０との間の通信は、ワイヤレス、例えば、無線(radio)にしてもよい。

図３は、通信ノードの原理を示す模式ブロック図である。
通信ノード３００は、内部バス３１０を含むことができ、とりわけ、マイクロプロセッサのような処理デバイス３４０、ＲＯＭまたはフラッシュ・メモリのような不揮発性メモリ３２０、およびＲＡＭのような揮発性メモリ３３０を相互接続する。不揮発性メモリ３２０は、１組の処理命令をコンピュータ・プログラムの形態で収容することができ、処理デバイス３４０によって処理命令が実行されると、本開示において指定するような方法を通信ノード３００に実行させる。揮発性メモリ３３０は、処理命令の実行中に処理デバイスによって使用される可変データ(variable data)を収容することができる。また、ワイヤレス通信デバイス３７０もバス３１０に相互接続されており、アンテナ３９０の接続によって、外部アクセス・ポイント（図２には示されていない）と通信ノード３００との間で双方向無線通信を行う。また、Ｉ／Ｏデバイス３５０もバス３１０に相互接続されており、通信ノード３００と外部制御デバイス３６０との間でデータ通信を行う。外部制御デバイス３６０は、例えば、通信ノード３００が組み込まれた(arrange)車両の移動を制御するように構成された制御回路を含むことができる。また、外部制御デバイス３６０は、車両の動作に関連する信号を供給するセンサ、変換器等も含むことができる。これらの信号は、通信ノード３００によって残りの通信システムに、関連するアクセス・ポイントを経由して伝達され、更に中央ユニットにも伝達されなければならない。更に、通信ノード３００は、電源または電力処理ユニット(power handling unit)３８０も含み、通信ノード３００に含まれる回路を動作させるために電力を供給する。
通信ノード３００は、例えば、ＩＥＥＥ８０２．１５．４として知られている仕様書によって定められるような物理レベル・プロトコルを実装するように構成されてもよい。

図４は、通信ノードの動作方法を示す模式流れ図である。
図示する方法４００は、１組の処理命令として具体化された、コンピュータ・プログラムとして実装することもでき、処理命令はメモリ（先に図３を参照して述べた不揮発性メモリ３２０のような）に収容され、通信ノード３００において処理デバイス３４０によって実行することができる。

方法４００は、ワイヤレス通信ネットワークにおいて通信ノードを動作させる方法であり、ノード３００は、少なくとも１つのアクセス・ポイント１４０を経由して、中央通信ユニット１５０と通信する。

この方法は、初期化ステップ４１０において開始する。
最初に、受信ステップ４２０において、アクセス・ポイント１４０からワイヤレス信号をノード３００において受信する。

更に、チャネル品質判定ステップ４３０において、ノード３００によって、受信したワイヤレス信号に基づいてチャネル品質情報を判定する。
更に、順序決定ステップ４４０において、判定されたチャネル品質にしたがって序列されたアクティブ・チャネルの順序をノード３００によって決定する。

次に、選択ステップ４５０において、決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルが、ノードによって選択している。
次に、送信ステップ４６０において、ノードによって、選択ステップ４５０において選択された通りに、選択されたアクティブ・チャネル上でワイヤレス信号を送信する。

この方法は、繰り返すか、または終了ステップ４７０において終了することができる。
好ましくは、ワイヤレス通信ネットワークは、ビーコン対応搬送波感知多重アクセス（ＣＳＭＡ）に基づくネットワークである(beacon enabled carrier sense multiple access (CSMA) based network)。

選択されたアクティブ・チャネル上でノードによってワイヤレス信号を送信する送信ステップ４６０は、好ましくは、搬送波感知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してメッセージを送信することを含んでもよい。

好ましい態様では、ノードによって実行される方法４００は、更に、アクセス・ポイントからのビーコン・データの受信によって提供されるビーコン・タイミング情報を連続追跡する(lock on)ステップを含んでもよい。

好ましい態様では、この方法は、更に、ノードによって、タイムスロット・パターンにしたがってチャネル全体を反復するステップも含む。
また、図示する方法４００は、アクセス・ポイント１４０と共に付与または実行されるステップあるいはエレメントを含んでもよい。一態様では、方法４００は、更に、ビーコン送信モードでアクセス・ポイント１４０を動作させるステップを含んでもよい。このようなビーコン送信モードでは、アクセス・ポイントはワイヤレス・ビーコン・データをノード３００に送信する。また、アクセス・ポイントを待ち受けモード(listening mode)で動作させることもできる。待ち受けモードでは、アクセス・ポイントは、ノードから受信したデータを、中央通信ユニット１５０に中継する。

好ましい態様では、ノード３００およびアクセス・ポイント１４０を共通クロック信号によって同期させることができる。
開示する動作方法に可能な更に別の一般的態様および関連する利点は、以下から明らかになる。

態様１。任意の数の時間同期されたＡＰが、それらに現在割り当てられているチャネルにしたがって専用タイムスロットにおいてビーコン・フレームを送信することができる。任意の所定パターンを使用することができる。ノードは、ビーコン・タイミングを連続追跡することができ、タイムスロット・パターンにしたがって全てのチャネルにわたって連続的に反復する。利点：ノードは範囲内における全てのＡＰを把握し、これらの全てからビーコンおよび収容データ(contained data)を受信する。

態様２。ＡＰは、そのビーコン送信の間、待ち受けモードになり、ノードからの全ての着信フレームを中継する。ビーコン・フレームは、直前のビーコン以来受信したフレームに対する確認応答(acknowledgement)、および発信データ(outgoing data)を収容することができる。ビーコンにおいてデータを受信したノードは、専用確認応答フェーズにおいて、または通常のデータ・フレームを通じて、これに確認応答することができる。

態様３。ノードは、受信信号品質にしたがって、アクティブ・チャネルを序列することができる。ノードが送信することを望むとき、この序列にしたがって順次利用可能なチャネル上でＣＣＡを実行することができる。一旦空きチャネルが発見されたなら、送信を開始することができ、そうでない場合、ノードは、再試行する前に、ランダム遅延を実行すればよい。利点：大多数のノードが同じＡＰをそれらの好ましいものと見なす場合でも、トラフィックが自動的に利用可能なＡＰにわたって分散する。

態様４。中央ユニットがフレームを特定のノードに送信することを望むとき、そのフレームを、そのノードの範囲内にある任意のＡＰを経由して導出する(route)ことができる。最も簡単な場合では、これは、ユニットが最後にそのノードからメッセージを受信したＡＰを経由して、それを導出することを伴うのでもよい。この手法の精度は、ＡＰに対するノードの速度と比較して、ノードがメッセージを送信する頻度のみに依存する。利点：ノードは、単にフレームを送信することによって自動的に中央ユニットに経路表(route table)を維持するので、ルーティング・アルゴリズムの必要性がない。

態様５。ＡＰが、何らかの理由で、他のチャネルに移動することを望む場合、物理的に周波数を変更することを除いて、必要とされる唯１つのアクションは、そのビーコン・タイミングを適宜に変更することである。範囲内にあるノードはいずれも、１つのＡＰが範囲から出て、他のものが入ったかのようにこれを単純に解釈し、このプロセスを完全にシームレスにし、更に中央ユニットおよびノード双方から見えなくする。利点：スループットの低下(penalty)を殆ど生ずることなくチャネル選択を行うことができ、非常に小さいコストで、ノイズが多いチャネルからＡＰが移動することを可能にする。

態様６。ノードは、ビーコンを待ち受けている間、全てのチャネル上でエネルギ測定を実行する。このデータを列挙して、送信されるフレームに添付することができ、互いについてのＡＰの知識、および範囲内におけるあらゆる外部送信機(alien transmitter)についての知識を与える。利点：ＡＰは、その特定の地理的位置において最適なチャネルをインテリジェントに選択することができる。このように、規則的干渉および不規則な干渉の双方を動的に回避し、プロトコルを極めてロバストに、そして非常に非侵襲的にすることができる。

開示した動作方法、通信ノード、通信システム、および格納システムは、図５、図６、図７、および図８ならびに以下のそれらの対応する説明を参照することによって、更に詳しく図示および説明することができる。
未確認応答フレーム(unacknowledged frames)
１つの態様では、ノード３００からアクセス・ポイント１４０に送信されるメッセージ については、直接確認応答(direct acknowledgement)を飛ばしてもよい。代わりに、確認応答は、ビーコン内にノード・アドレスのリストの形態で含むことができる。この手法は、全体的なオーバーヘッドを著しく低減することができるが、ビーコンが大きくなり、フレームと確認応答との間の最大遅延がビーコン期間と等しくなり、ノードはビーコンの頻度よりも高い頻度で送信することができないという欠点がある。

ノードが７Ｈｚの最大頻度で送信することを指定する要件を一例としてあげると、ビーコン頻度がこれよりも高い場合はいつもで、ノードは、それらが望むメッセージを全て送信できることを意味する。２０から４０Ｈまでの任意のビーコン頻度を有することが実現可能であると仮定すると、ビーコン期間は５０および２５ｍｓの間のいずれかの値となる。メッセージの大部分を１００ｍｓ以内に送信しなければならないことを指定する要件では、確認応答のために５０ｍｓまで待たなければならないとしても、十分に許容範囲内であることがわかる。
専用確認応答フェーズ
１つの態様では、ビーコンに続くアクセス・フェーズ内のある時点における時間期間を、直前のビーコンにおいてメッセージを受信したノードからの確認応答専用にすることができる。これによって、ノードがＣＳＭＡ／ＣＡを使用しなければならない場合と比較して、確実にそれらの確認応答を送ることができる。８０２.１５.４規格の下では、これは、メッセージを受信したノードにＧＴＳを割り当てることによって行うことができ、ノードはその確認応答、および保留中のメッセージを有する場合には、おそらくそのメッセージも送信する。これの欠点は、ＧＴＳがビーコン期間の終了時に制限されることであり、これが意味するのは、可能な最も遅い時点に確認応答が到達するということである。また、この規格は、ＧＴＳのサイズに関して柔軟性が限定され、要するに、１回の確認応答に対してＧＴＳがかなり過大となる(way oversized)ため、帯域幅が浪費されることになる。これに対する可能な解決策は、８０２.１５.４規格を破棄して、ＧＴＳがビーコンの直後に来る固有の解決策を作ることであろう。
チャネル・アジリティ(Channel agility)
１つの態様では、チャネルに関して、システムをもっと動的にし、自己管理させて、全てのチャネル処理(handling)をプロトコル自体の内側に隠すことを究極的な目標とすることが望ましい場合もある。何らかの全体タイミング基準(global timing reference)に対して一意の時間オフセットを全てのチャネルに割り当てる解決策が提案された。各アクセス・ポイントは、それに割り当てられたチャネルに専用のタイミング・オフセットに続いてそのビーコンを送信する。

図５は、基本的なビーコン・シーケンスの原理を示す模式タイミング図である。
アイドル・ノードが一旦シーケンスに同期されると、全てのチャネルを巡回して、範囲内にある全てのアクセス・ポイントからのビーコンを検出する。これの簡単な図を図５におけるタイミング図５００に表し、７つのチャネルを使用する例、およびどのようにそれらのビーコンを順次時間内に(in time)配置するかについて示す。この図では、チャネル１および５がアクティブであり、一方残りのチャネルは使用されていない。これが意味するのは、ノードは待ち受けているが、ビーコンを全く取得せず(pick up)、つまりこれらのチャネルをアクティブ・チャネルのリストには含まないということである。これは、シーケンスがチャネル７に達したときに、どのようにしてチャネル１に戻るかを示す。全体的時間基準の導入は、この手法の成否を決めることであるが、可能でありしかも便利であった。何故なら、オートストアにおいて使用されている既存のプロトコルは既にこのような基準を有しており、したがってこの機能を再利用するためには、些細な調節しか必要とされないからである。既存の同期メカニズムは、１３０Ｈｚ信号が、中央安全モジュール(central safety module)から全てのＡＰに、ＡＰのＰＯＥ供給に関連付けて分散されるという形態となっている。この手法を使用することにより、ルーティングの必要性が著しく低下する。ノードは、ＡＰがいつ範囲に入るかまたは範囲から出るか自動的に検出し、それに応じてその利用可能なＡＰのリストを調節する。ノードが送ることを望むとき、チャネル巡回を続け(put on hold)送信に最も適したチャネルを連続追跡する。ここでは、ＣＳＭＡ／ＣＡを使用してそのメッセージを送信し、試みが成功した場合、確認応答を収容する次のビーコンを待つ。ＣＣＡが失敗した場合、１つよりも多いチャネルが利用可能であるならば、ノードは直ちに他のチャネル上で自由にアクセスを試すことができる。このように、トラフィック負荷は利用可能なＡＰ間で自動的に拡散する。

サーバがメッセージをノードに送ることを望むとき、そのノードからメッセージを最後に受信したＡＰを経由して、メッセージを中継する。これによって、サーバのための経路表を非常に簡単にし、更に自己管理を行わせる。

また、ＡＰは、前もってノードまたはサーバに通知する必要なく、チャネルを随意に変更することができ、ノードは、単に、１つのＡＰが範囲から出て、他のＡＰが範囲に入ったことを確認するだけでよく、システムを非常に柔軟にする。

この手法を用いることによる２つの落とし穴の内１つは、ノードが、１つのチャネル上で送信している間に、異なるチャネル上でビーコンにおいてメッセージを受信しているかもしれないことである。これは、ノードが２つのＡＰ間の境界を交差し、つまりそれがその好ましい送信チャネルであると見なすものを変更するときには、当然の成り行きである。また、ノードは、送信元ＡＰの範囲から単に退出した(move out of)だけであるという可能性もある。この問題を克服するために、最も重要なことは、全ての再送信の役割(responsibility)をサーバに移すことである。このようにすると、メッセージに対する確認応答を受信しないＡＰは、単に、メッセージが失敗したことをサーバに報告するだけでよい。したがって、メッセージを再送信するのは、同じＡＰであれ異なるＡＰであれ、サーバ次第となる。この手法を使用すると、この効果から(from this effect)失われた各パケットを正しいチャネル上で殆ど直ちに再送信することができる。何故なら、サーバにおいてノードに接続されているチャネルは、殆どの場合、最初の送信失敗と並列に更新されるからである。また、ノードからサーバに向かうメッセージの数は、他に向かうメッセージの数よりも遙かに多いので（表１．１に指定するように、毎秒１〜７に対して３秒毎に０〜１）、サーバが新たなメッセージを最初に送信しようとする前に、ノードが新たなチャネル上でメッセージを送信する可能性が非常に高く、したがってそういう事態は発生しそうもない(less likely)と推論することができる。

第２の落とし穴は、ＡＰが異なるものに移動した後に、ノードがチャネル上で送信しているかもしれないことである。これは、チャネル交換が差し迫っていることの何らかの情報をビーコンに添付させ、ＡＰに、ノードが送信するのを防止することによって回避することができ、またはこの事態からパケット損失が発生することを単に受け入れることもできる。ビーコン期間が２５〜５０ｍｓであると仮定すると、ノードは次の期間においてメッセージを安全に再送信することができ、それでもなお１００ｍｓ以内というレイテンシ要件を十分に満たすことができる。したがって、このアーチファクトは、この手法全体で得ることができる効果を考えれば、容認可能な犠牲と見なすことができる。
シーケンス番号
このシナリオでは、全ての確認応答された通信に関して、一見すると失敗のように見える送信は、元のメッセージが正しく送信されなかったことによって、または確認応答が失敗したことによって発生する可能性があり、送り手の視点からのみ、送信が不成功であったように思わせる。これは、シーケンス番号の使用によって最良に処理する(handle)ことができ、受信機は、メッセージが以前のメッセージの再送信か否かチェックする。この場合、直前の章で紹介したように、ノードがＡＰ間で継ぎ目なく移動すると、ＡＰはメッセージが複製か否か知ることができないことは明らかである。これは、ノードが受信するメッセージはいずれも、以前に異なるチャネル上で送信することを試されていたかもしれないからである。理論的に、ノードは、パケット送信毎に、２つのＡＰ間で交換することができる。このために、シーケンス番号をプロトコルに含ませることは無意味であり、サーバおよびノード上で実行するアプリケーションによって、もっと高いレベルでシーケンス番号が添付されなければならない。これによって、シーケンス番号が有効に作用するために必要とされる、直接の１対１リンクが形成される(create)。
アドレシング
表１．１において、２５０、つまり、１バイトのアドレシングで十分可能なことを暗示する数の独立したノードをシステムは処理(handle)できなければならないことが指定されている。しかしながら、この要件は、システムによってサポートされるノード数ではなく、スループットに大きく関係する。したがって、２５６よりも多いノードのアドレシングを可能にすることが非常に望ましい。これによって、本解決策が、後の段階において可能性がある拡張や変更に対して将来においても有効であることを確保する。８０２．１５．４規格は、通常の通信の間１６ビット・アドレスを使用し、必要であれば、標準的なＭＡＣアドレス全てを利用して、６４ビット・アドレスに戻ることができる。この場合には６４ビット・アドレスの必要性には全く関心がなさそうであっても、１６ビットは、関連するシステム要件を満たすべき非常に合理的なノード数を生み出す。

拡張チェックサム(extended checksum)
他の可能な考慮事項に、８０２．１５．４において使用される通常の１６ビットよりも大きなチェックサムの必要性がある。これの理由は、破損したパケットが純正なコマンド(genuine command)として受け入れられたという以前の経験である。わずか１／６５５３４の確率であるが、無線環境にノイズが多く最適でない場合、送信されるメッセージ量が、このような小さい確率であっても、それを毎年複数回発生させることになり、このような事態の結果は破滅的となる可能性がある。新たなプロトコルを用いれば、この問題は、この以前の解決策による短期の場合ほど重大になりそうにない。しかし、その時点以降、選択は備えあれば憂いなしとなった。これが意味するのは、余分な１６ビットチェックサムの追加は、十分に価値のあるオーバーヘッドであると見なされるということである。
ネットワークＩＤ
チャネル巡回が有効に作用するためには、ノードをシーケンス・タイミングから逸脱させる(bring out of)可能性がある外来ビーコン(alien beacon)によってノードが混乱させられなくすることが有用であろう。これは、２つのオートストアの設置(installation)が互いの無線範囲内で行われた場合に起こる可能性がある。２つの設備 (installation) のＡＰは、同じ全体クロックに従わず、このため互いに同期から外れることになる。すると、ビーコンを求めている(search for)ノードが、正しくないウェアハウスのシーケンスを連続追跡する危険に晒される可能性がある。この問題を克服するために、ネットワークＩＤを導入することができる。これによって、ノードが、それらに全く関心のないビーコンを排除することを可能にし、更に、ＡＰが、近隣ネットワークからのあらゆるデータ・フレームを排除することも可能にする。通常の実行条件(running conditions)の下では、ＡＰは異なるチャネル上に定在しており、更に、十中八九、同期が外れているはずなので、いずれの事態も一般には発生しない。これが意味するのは、同期されているノードは偽ビーコンを全く取得せず(pick up)、外来ノードが近隣ＡＰのチャネル上で送信することはないということである。しかしながら、ノードが同期を失いビーコンを捜さなければならない場合、衝突が差し迫っている。

この手法に伴う１つの課題は、ノードがいかにして最初にネットワークと連携すべきかである。何故なら、ノードは純粋に無線でシステムと通信することを意図しているからである。これを克服するために、この１つの特定ネットワークｉｄを「ドントケア」値(don't care value)に設定することであり、この場合、ノードは任意のネットワークに同期し、次いで、この値は、プロトコルによって使用されるデフォルト値となる。次いで、この特定のネットワーク上でサーバと接触し、これらが連携するか否か尋ねるのは、アプリケーションに委ねられる。そうでない場合、このネットワークｉｄはブラックリストに追加される可能性があり、ノードは新たなビーコン・スキャンを行うことを強制される。正しいネットワークが発見されたなら、このネットワークｉｄを今後の使用のために不揮発性メモリに格納するとよい。これが意味するのは、この連携手順は、最初にノードがネットワークに追加されるときにだけ行えばよいということである。
ブロードキャスティング
システムの通常動作に加えて、ブロードキャスティングのための特殊モードもサポートすることができる。このモードは、無線リンクを跨いでノードを再プログラムするために使用することができる。これは、ＡＰが大きなプログラム・ファイルを全てのノードにブロードキャストすることを伴い、ファイルを検証した後、ブート・ローダがモジュール上にそれをロードする役割を担う(take care of)。このモードは、通常動作とは完全に別にすることができる。何故なら、これが使用されるのはシステムが静止(stationary)およびアイドル状態にあるときだけであるからである。また、このモードは比較的単純である。何故なら、ノードは１つのチャネルを連続追跡し、そのＡＰからファイル全体を受信でき、そして受信しなければならないからである。したがって、この機能(feature)の実施は本願(this thesis)にとっては全く関心がないが、一旦作業が完了して統一システムを得るためにプロトコルを定めるときには、考慮に入れなければならない。

完全に固有の解決策(proprietary solution)が相応しい場合もある。何故なら、これは、既存の規格に調整する必要なく、最初から構築することによって大きな効果が得られるからである。また、システムは、必ずしも、他のいずれかのシステムまたはモジュールと通信することを仮定しておらず、実際、エラーを回避するために、このようなイベントをできるだけ起こり難くすることが望ましい。先に説明した戦略を想定した８０２．１５．４の使用が可能であるが、結果的に得られるプロトコルは必ずしも最適であるとは限らず、８０２．１５．４が提供する機能(feature)の多くは必ずしも必要とされず、不必要なオーバーヘッドを追加するおそれがある。このプロトコルの効率を最大限高めるために、ＭＡＣレベルの完全に固有の解決策を、８０２．１５．４において記載されているＰＨＹレベルと共に使用することもできる。これは、無線ＳｏＣの大多数が８０２．１５．４をサポートしており、この規格における物理的記述(physical description)上に構築されるという事実に基づいて、行うことができる。しかしながら、ＭＡＣレベル上の機能は、多くの場合、部分的にソフトウェアで行われる。これが意味するのは、開発者は、望むときに、容易に規格から逸脱できるということである。
無線モジュール
無線ハードウェアは、Ｄｒｅｓｄｅｎ Ｅｌｅｃｔｒｏｎｉｋ社のｄｅＦＲＭｅｇａ１２８−２２Ｃ０２を含むのでもよい。このモジュールは、ＡｔＭｅｇａ１２８ＲＦＡ１チップをカプセル化し、ＲＦ遮蔽、オンボードＥＥＰＲＯＭ、オンボード水晶発振器、およびオンボード同軸アンテナ・コネクタを含む。ＡｔＭｅｇａの事実上全てのピンが、外部からアクセス可能であり、このチップをプラグ・アンド・プレイ・ハードウェア解決策としつつも、最大の柔軟性に対処する。このモジュールは、カスタム無線モジュール上に実装される。また、このチップは、ＡＰ上におけるＴＣＰ／ＩＰ通信および格納システム内にある車両上のハードウェアの残り部分との通信を処理する(handling)他のマイクロコントローラも内蔵する。
ＡｔＭｅｇａ１２８ＲＦＡ１
ＡｔＭｅｇａ１２８ＲＦＡ１は、強力なマイクロプロセッサを内蔵し、無線モジュールに直接アクセスすることができる完全なチップ上システムである。無線モジュールは、使いやすいインターフェースを有し、制御およびデータ・レジスタにソフトウェアから直接アクセスすることができる。また、これは、全ての重要な無線イベントを示す様々な専用割り込みも有する。
トランシーバ
トランシーバは、ＩＥＥＥ８０２.１５.４物理レイヤ変調方式、チャネル構造、物理プリアンブル、チェックサム計算、およびＣＣＡを実現する。また、エネルギ検出およびリンク品質指示は、ハードウェアで利用可能である。ＭＡＣレベルには、自動確認応答(automated acknowledgement)、規格によるＣＳＭＡ／ＣＡ送信および再送信、ならびに自動アドレス・フィルタリングのために専用モードがある。他のハードウェア・アクセレレータには、ＡＥＳ１２８ビット暗号、真の乱数発生器、および８０２.１５．４規格においてサポートされるものよりも高いＰＳＤＵレートが含まれる。５００ｋｂ／ｓ、１Ｍｂ／ｓ、および２Ｍｂ／ｓの双方がサポートされる。

全体的に、このチップは、８０２.１５．４規格上に直接構築される任意のプロトコルの容易な実装を可能にするが、トランシーバは、ユーザが、必要とされるときに、規格から逸脱することを許容するレベルで制御可能である。とりわけ、ＳＦＤは、専用レジスタを介してアクセス可能であり、可能な限り最も低い「変調前」レベル(pre modulation level)上で、無線機がそのフレームを８０２．１５．４フレームから区別することを可能にする。
Ｍａｃシンボル・カウンタ
８０２.１５．４は、プロトコルのタイミングを維持するために、シンボル・カウンタの使用を暗示しており、このカウンタは、計画されているフレーム受信の前に、トランシーバを起動する(wake up)ことができなければならず、更に、規格に指定されている通りに、ＧＴＳスロットおよびＣＳＭＡ／ＣＡバックオフ・スロット(CSMA/CA backoff slot)の精度高い実行を可能にする。ＡｔＭｅｇａ１２８ＲＦＡ１では、このカウンタは、３つの独立した比較器、および専用のバックオフ・スロット・カウンタを内蔵しており、８０２.１５．４準拠フレームを使用するときに、自動ビーコン・タイムスタンプ付与(timestamping)を可能にする。
ＲＳＳＩおよびエネルギ検出
任意の受信モードにあるとき、このチップは、現在のＲＳＳＩを用いて、レジスタを継続的に更新する。これは、信号がデコード可能か否かには関係なく、チャネル上における現在のエネルギ・レベルの測定値である。次いで、この値を直接読み出すことができ、または代わりに、もっと精度の高いエネルギ検出レジスタを使用することができる。エネルギ検出は、ハードウェア先導(hardware driven)であり、８シンボルにわたる平均ＲＳＳＩを計算する。次いで、この手順の完了が割り込みによって通知される。手作業によるエネルギ検出に加えて、これは有効なＳＨＲの受信時に常に自動的に開始される。これが意味するのは、一旦フレームが完全に受信されたなら、ＥＤレジスタは、受信された物理信号強度の指示を収容するということである。
最終的なプロトコルの概念
先に示した要件および論述にしたがって、プロトコルを満たすためにおそらく望まれる機能(feature)のリストを示す。

−設定周波数でビーコンを送信する。チャネル間の時間オフセットは１つのこのようなビーコンの長さに等しい。
−全てのＡＰ、およびその後に同期するノードに対する全体時間基準。

−送信に使用されている場合を除いて、ノードが全てのチャネルをスキャンし、全てのビーコンを受信する。
−ビーコン期間のアクセス・ウィンドウにおいてＣＳＭＡ／ＣＡを使用して送信されるデータ・フレーム。

−１つのチャネル上でＣＣＡが失敗すると、ノードは他の利用可能なチャネルにアクセスしようとする。
−続くビーコンにおいてノード・アドレスのリストとして送られるデータ・フレームに対する確認応答。

−各ビーコンの直後にあり、メッセージを受信したノードによって使用される専用確認応答フェーズ。
−プロトコル・レベルでは再送信せず、全ての送信失敗を逆にアプリケーションに報告する。

−必要とされるときにおける、チャネル品質の測定値およびチャネルの変更。全てはプロトコル内部に隠蔽される。
−ＡＰがもっと大きなファイルを接続されている全てのノードに転送することを許可するブロードキャスト・モード。

−チャネルによってのみ識別されるノード、ＡＰの１６ビット・アドレシング。
−近隣以内において複数の設備(installation)を許容するネットワークＩＤ。
−合計３２ビットのチェックサム。

−オーバーヘッドを最小に抑えるための特殊フレーム・ヘッダ。
この機能リストに基づいて図５から修正したバージョンのビーコン・シーケンスを図６に示す。これは、チャネル間の時間オフセットの原理を示す模式タイミング図６００を含む。

専用確認応答フェーズの追加により、データ・フェーズが多少短縮するが、他の方法では確認応答がアクセス・ウィンドウ内で送信されることを考慮に入れると、これは全体的なスループットには全く影響がない。アクティブ・チャネル毎の総アクセス・ウィンドウは、利用可能なチャネル数から２を減算し、１副期間(subperiod)の長さを乗算した値に等しい。通常の状況下では、８０２.１５.４物理定義(physical definition)は、２．４ＧＨｚ帯域において１６チャネルを使用する。これが意味するのは、チャネルは、時間の内１４／１６を送信に使用可能であり、最後の２／１６はビーコンおよび確認応答フェーズによって占有されるということである。

ビーコンは厳格なタイミングに従わなければならないので、これらが予想されるときには常に送信していることが重要である。これが意味するのは、この送信の前にＣＣＡを行うのは無駄であるということである。この衝突回避対策がないと、態様によっては、エリア内の他のネットワーク、Ｗｉ−Ｆｉ等に問題を起こすおそれがあるが、２．４ＧＨｚ帯域において利用可能な全帯域幅を想定すると、他のシステムと共有されていないチャネルをプロトコルが発見できるという仮定は、合理的である。このように、直接送信は全く問題を生じないはずである(should)。衝突があった場合、このプロトコルにとって最悪のシナリオは、ノードがビーコンをデコードできず、このため、ＡＰが範囲から外れたと信じてしまうことである。これはパケット損失を誘発する可能性がある。この事態においても、過度に頻繁に起こるのではない限り、スループットの一時的な低下を招くに過ぎない。確認応答フェーズの効率を最大限高めるためには、それを専用スロットに分割し、ノードは専用スロットにおいてそれらの確認応答フレームを直接送信することも望ましい。必要なスロット数は、１つのビーコン内に収めるメッセージ数によって異なり、これについては以下で更に論ずる。
最終的なプロトコルの定義
８０２．１５．４規格から逸脱する実施態様では、カスタム・ヘッダおよびフレーム構造を定義しなければならない。
フレーム・ヘッダ
プロトコルは、表２.１にまとめた４つの異なるフレーム形式を利用することができる。

４つの異なるフレーム形式は、ヘッダにおいて２ビット・フィールドを使用して表すことができる。使用する形式は非常に一般的であり、ほとんどの今後のシナリオにおいて十中八九再利用できそうなので、これ以上のフレーム形式は必要とされなさそうに思われる。

ヘッダにおける次のフィールドはネットワークｉｄでなければならない。２つまたは３つよりも多い独立した設備が互いの範囲内に含まれる可能性は非常に高い。しかしながら、非常に大きい設備では、それを複数の物理格子に分割することが増々実用的になっており、したがって、１つの設備が複数の独立した格子を構成するシナリオは非常に可能性が高い。このような場合、２〜６つのグリッド、またはそれ以上のグリッドは、実際には同じ全体的な設備の一部であっても、互いの範囲内にあると想像することができる。また、いくつかのネットワークＩＤを特殊目的のために、とりわけ、全ての待ち受け側(listener)によって受け入れられる「ドントケア」値のために、保存しておかなければならない。結局(in total)、８つよりも多い異なるＩＤが必要になることは可能性が低くはなく、１６個の異なるＩＤを与える４ビットが好ましい選択肢であることを意味する。

結局、６ビットのヘッダとなり、これを完全な１バイトにするために、２つの余分なビットを終端に付加する。すると、これらのビットは今後の拡張またはフレーム特定機能(frame specific feature)に利用可能となる。例えば、チャネル管理機能に関係する。ヘッダ全体を表２.２に示す。

フレーム・レイアウト
チップの一例であるａｔｍｅｇａ１２８ＲＦＡ１は、８０２．１５．４規格によるハードウェア先導チェックサム生成および検証をサポートする。また、これは、フレーム・バッファにおける第１バイトが、送信の間、同様に８０２．１５．５において定義されているＰＨＲであることも要求する。このバイトは、フレーム長と、フレームが８０２．１５．４規格に準拠するか否かを示すビットから成る。フレーム・バッファは合計で１２８バイト長であり、表２．３に見られるようなフレーム・レイアウトを有する(giving us)。次いで、チェックサムおよびその他のオーバーヘッドを差し引くと、一般的なフレームに利用可能なペイロードは、最大で１２２バイトとなる。有効なペイロードの大きさは、異なるフレーム形式が導入する余分なオーバーヘッドによって左右され、以下で更に徹底的に定義する。

データ・フレーム
データ・フレームは、ノードによってＡＰに、アクセス・ウィンドウにおいてＣＳＭＡ／ＣＡを使用して送られる。これは、１つのＡＰだけが所与のチャネル上で待ち受けているからであり、目標アドレスを全く必要としないが、送信ノードのＩＤを含まなければならい。また、データのリストが始まる前に、データ・バイトの数も添付される。結局、このために、表２．４に見られるレイアウトとなり、ここでわかるように、これには有効ペイレードに１１９バイトの余裕がある。

確認応答フレーム
確認応答フレームは、ノードによって、確認応答フェーズの間に専用スロットにおいて送ることができる。これは、厳格なタイミングを維持するためにチャネルの感知を全く行うことなく、直接送信される。このフレームは、送信ノードのＩＤだけを収容していればよい。何故なら、その特定のノードにアドレスされたメッセージの受信成功を確認することは全てのＡＰに求められるからである。フレームをできるだけ小さく抑えるために、余分なチェックサムを欠落させて(skip)、１６ビットのハードウェア先導チェックサムだけを残す。これを行うことができるのは、このフレームの破損は、ビーコンおよびデータ・フレームと比較すると、全く取るに足らないからである(completely uncritical)。ＡＰは、直前のビーコンにおいて本当のアドレス(fact address)でそれが捜したノードＩＤだけを探す。これが意味するのは、ランダムなＩＤを有する破損フレームは、チェックサムが正かったとしても、ＡＰによって受け入れられる可能性は低いということである。つまり、ノードＩＤ自体が事実上チェックサムとして作用する。結局、このために、フレーム・レイアウトは表２．５に示すようになる。

ビーコン・フレーム
ビーコンは、直前のアクセス・ウィンドウにおいて受信されたデータ・フレームに対する確認応答のリストと、異なるノードにアドレスされた可変数のメッセージとを収容することができる。プロトコルの機能を最適化するために、最も合理的な手法は、最初に確認応答のリストを追加し、次いで余裕がある限りできるだけ多くのメッセージを添付することであろう。これが意味するのは、高トラフィックの状況では、「ＡＰ−ノード」スループットが最初に影響を受け(suffer)、ノードが然るべき頻度でコマンドを受信できなくなり、更に、ノードが一層頻繁にアイドルになり、このため「ノードからＡＰに」生成されるトラフィックが減少するということである。このように、トラフィック・フローは自己規制する。

ノードが、可変数のエントリを有するビーコンを正しく解釈するために、ビーコン・ヘッダが必要となる。これは、リストにおける確認応答の数、および続くメッセージの数を収容しなければならない。また、これは、確認応答を期待していないノードが直接メッセージ・リストにジャンプすることを容易にする。

確認応答リスト
アクセス・ウィンドウが長い程、一層多くのデータ・フレームが送信される可能性が高くなり、一層多くの確認応答をビーコン内に収容しなければならない。表２．９は、送信される全てのメッセージが８バイト・ペイロードを収容すると仮定して、アクセス・ウィンドウ当たりの絶対最大理論的メッセージ数を、計算したものである。しかしながら、この数値は、ＣＳＭＡ／ＣＡのランダム性のために、非常に論理的になっている。それでもなお、フィールドの大きさを決定する(dimensioning)ときにインディケータとして使用することができる。ビーコン周波数が３０Ｈｚのとき、最大理論的データ・フレーム数は３３となり、２５Ｈｚのとき、この数は４０フレームに増加することがわかる。

他の要素にビーコンの最大サイズがある。各確認応答が２バイトを占めると、３２個の確認応答のリストは６４バイトを占めることになる。表２．９から、ビーコン・フェーズ全体で利用可能なシンボル数を求めることができ、これらのシンボルの相当な部分が、オーバーヘッドおよびノードとＡＰとの間の同期に使用されることを考慮に入れて、６４バイトよりも多くのデータまたは実際のデータを収容可能であるためには、ビーコン周波数は３０Ｈｚよりもはるかに低くなければならないと想定することができる。

これに基づくと、最大で３２個の確認応答は、リスト長を示すためには５バイトを必要とし、あらゆる現実的な状況下では十分なはずであることは明白である。
メッセージ・リスト
確認応答数と同様に、メッセージの最大数も評価しなければならない。ここでは、２つの事項を考慮しなければならない。第１に、確認応答フェーズは、最大許容メッセージ数に等しい数の確認応答を収容する(fit)ことができなければならない。表２．５に指定するように、１つの確認応答フレームは、表２．３に示すように更に５バイトから成る物理ヘッダに加えて、５バイトのデータを収容する。結局、これが意味するのは、確認応答フレームは、完全に送信するには２０シンボルを必要とし、これに加えて、確認応答スロットはいくらかのドリフトを見込んでおかなければならないということであり、あらゆる計算に対しても基本として少なくとも２５シンボルが使用されることを意味する。表２．９に見られるように、各副期間は、３０Ｈｚのビーコン周波数では１３０シンボル長となる。これは、５つまでの確認応答に対応する(allow)ことができる。

第２に、最大数のメッセージをビーコン・フレームに収容しなければならない。各メッセージは、ノードＩＤ、データ量を指定するパラメータ、およびデータ自体によって表される。表１．１において指定した要件を使用し、平均メッセージ・サイズを８バイトとすると、これはメッセージ当たり１１バイトを意味する。これに加えて、ＡＰに着信するメッセージとＡＰから発信するメッセージとの比が３／１および２１／１の間のいずれかの値にすることも、前述の要件に指定されている。各発信メッセージには、着信メッセージに対する少なくとも３つの確認応答が付随すると仮定できることを意味する。結局、これが意味するのは、ＡＰからの１つの発信メッセージは、ビーコンにおいて少なくとも平均１７バイトを占め、多くの場合、確認応答の数は遙かに多いので、それよりもかなり多くのバイトを占めると仮定することができる。

以上で述べた２つの制限(limitation)に基づいて、メッセージ・リストを最大で３に設定し、２ビットのみでコード化できるリスト長にする。これによって、後の段階で使用することができる１つの余分な保存ビットをビーコン・ヘッダに与える。
メッセージの唯一性
以上のようにプロトコルを設計すると、ＡＰが、同じノードにアドレスされた複数のメッセージを１つのビーコンに追加することを妨げるものはない。しかしながら、このためには、ノードおよびＡＰ双方が、全ての前記メッセージの確認応答を処理する(handle)ことができなければならず、望ましくない複雑さが加わる。複数の同時送信の必要性は、このプロトコルを作る対象となるユース・ケースでは決して起こるはずはなく、一般に、アプリケーションは、メッセージをバッファに追加する前に、これらを連結する(concatenate)と仮定される。何故なら、これによって十分な量のオーバーヘッドが削られる(save)からである。したがって、ビーコンはノード当たり１つよりも多いメッセージを収容してはならず、いずれのブロードキャスト・メッセージもそのビーコン内では唯一のメッセージでなければならないという単純な規則を、プロトコル定義に追加する。この制限は、ＡＰはあらゆる衝突を防止するためにメッセージをフィルタリングしなければならないが、ノードは１回の確認応答送信よりも長い間起動している必要は全くないことを暗示する。
全ビーコン・ヘッダ(full beacon header)
最終的なビーコン・ヘッダは、表２．６において見ることができる。全ビーコン・フレームは、表２．７において見ることができる。ここでは、変数ａは追加される確認応答の数を示し、ｍはメッセージの数を示し、ｋ_ｉはメッセージｉに収容されるデータ・バイト数を示す。総和、

は、現在のビーコン周波数に対する最大ビーコン・サイズよりも大きくなることはできない。この最大ビーコン・サイズについては以下で更に論ずる。
ビーコン・サイズ
ビーコン・フレームは、ビーコン周波数によってサイズが制限される。表２．９において、異なる周波数におけるビーコン期間のシンボル長を見ることができる。計算は、毎秒６２５００個の８０２．１５．４−シンボルに基づく(62500 802.15.4-symbols per second)。１つのこのようなシンボルから４ビットが得られ(make out)、１バイトは２シンボルを必要とすることを意味する。
チャネル交換
図７は、ビーコン送信のフェーズの原理を示す模式タイミング図である。

図７では、ビーコン送信および接続フェーズの大まかな素描が示されている。ビーコンを受信するようにノードを準備するために、ＡＰがその送信を開始する前に、ノードを新たなチャネルに調節しなければならない。これに要する時間を、ビーコン送信に利用可能な時間から差し引かなければならない。

トランシーバが新たなチャネル上で静定するために必要とされる時間は、最大で２４μｓにすればよい。割り込みに対する遅延は、最大９μｓであると指定されている。ノード上のチャネル交換は割り込みとして開始されるので、必要とされる合計時間は９＋２４μｓ＋（交換を開始するのに必要とされる計算時間）になると推定することができる。シンボル長を１６μｓとすると、これは最小で２．１シンボルに等しくなる。これを３シンボルに切り上げることは、合理的である。
ＡＰドリフト
第２に、ＡＰが完全に同期されることは想定できないので、１つのシンボルに至るまで、ＡＰ間におけるいくらかのタイミング・ドリフトのために常時余裕がなければならない。タイミング・バッファが適所にあると、２つのＡＰは、何の問題も生ずることなく、バッファのサイズまで、ドリフトして離れることができる。これらがドリフトして更に離れた場合、ノードがチャネルに調整し終える前に、トリガするのが早すぎたＡＰがリスクを誘発し(AP that triggers too early risk triggering)、このため、ノードはビーコンを受信することができず、その後、ＡＰが範囲から外れたまたはオフラインになったと想定するので、ノードはそのチャネル上で送信を行わない。このバッファのサイズは、ＡＰ同期の精度のみに依存し、前もって推定するのは非常に難しいことを意味する。長さ１０のバッファによって、ＡＰが正しいタイミングからいずれの方向にも５シンボル、即ち、８０μｓ逸脱しても許容される。これよりも遙かに正しく同期を行うことができる場合、後の段階において、もっと大きなビーコンに対応する(allow)ために、この値を調節することができる。
解釈
最後に、ノードは、次のビーコンがトリガする前に、そのビーコンの解釈を完了できなければならず、そうでないと、ビーコン・トリガが遅れ、ノードが同期から外れる危険性があり、その結果切断されることになる。この期間の長さは、理論的に推定するのが難しく、最良の方法は、多分、「最悪事態」検査手順を設定し、外れ始める(failing)転換点を発見することである。
オーバーヘッド
一旦無線送信(on air transmission)を含まない部分が差し引かれたなら、実際のオーバーヘッドを評価することができる。表２．３に見られるように、一般的なフレームは１１バイトのオーバーヘッドを有する。ビーコン・ヘッダを追加すると、１２バイト、または２４シンボルとなる。

尚、このオーバーヘッド全てがフレームの前に位置するのではないことを注記しておく。何故なら、これはチェックサムおよび終端部のＦＣＳも含むからである。プログラム自体においてタイミング変数および定数の大きさを決定する(dimensioning)とき、これを考慮に入れなければならない。
最終的なサイズ
表２．８において、各ビーコン周囲のタイミング・オーバーヘッドを、図２．３におけるフェーズにしたがって、要約する。解釈に必要とされる時間は、最初に１０に設定し、後に最適値を求めるために検査するとよい(should)。
チェックサム
破損されたフレームの殆どは大きな破損度を有するのが通例なので、カスタム・チェックサムはエラー訂正能力を有する必要はない。したがって、フレームにおける全てのバイトの単純なＸＯＲを使用する。２バイトのチェックサムでは、最初に、全ての奇数バイト(odd indexed byte)のＸＯＲを取り、次に、全ての偶数バイト(even indexed byte)のＸＯＲを取る。フレームが１バイトのペイロードしか収容していない場合、第２バイトはその初期値、即ち、０を持ち続けているはずである。尚、チェックサムにはＰＨＲは含まれないことを注記しておく。何故なら、このバイトは、フレームが受信されるときには、フレーム・バッファに挿入されないからである。したがって、チェックサムに含まれる第１バイトは、カスタム・フレーム・ヘッダとなる。
同期
アクセス・ポイント間で厳格なタイミング要件を維持するために、全体タイミング基準を導入することができる。この信号の周波数は、ビーコン周波数を超えてはならない。したがって、既存の１３０Ｈｚは使用できない。簡素化のために、同期信号を１Ｈｚにすると定義してもよい。
機能の説明
図８において、通信シーケンスの例を４通り示す。４通りの例８（ａ）、８（ｂ）、８（ｃ）、および８（ｄ）は、ノードに対する送信および受信の図である。

図８（ａ）では、単純な受信を示す。ノードは、チャネル５上でビーコン内においてメッセージを受信し、続く確認応答フェーズにわたってこのチャネルを連続追跡し続け、その確認応答を送信する。

図８（ｂ）では、ノードが送信のためにチャネル１にアクセスしようとして、直ちにアクセスを得る。図示のように、ノードは、その時点ではチャネル１上で送信しているので、チャネル５上でビーコンを受信することができない。ここで問題が発生するのは、チャネル５上で受信したビーコンが、そのノードに宛てられたメッセージを収容する場合、またはブロードキャストの場合だけである。しかしながら、以上で論じたように、このように直接アドレスされたメッセージをノードが失う確率は、十分に小さく、ノードにとっては容認可能な不利(penalty)に過ぎない。図８（ｃ）では、ノードはチャネル１上でそのＣＣＡに失敗し、その時点で、チャネル５はビーコンおよび確認応答フェーズによって遮断される(block)。これに続いて、ノードはランダム・タイムアウト(random timeout)を実行し、後の段階においてその送信を再試行する。図８（ｄ）では、ノードはチャネルの序列(ranking)を変更し、最初にチャネル５上で送信しようとし、これは失敗するが、チャネル１が現在利用可能であるので、直ちにそこで再試行し、成功する。尚、丁度図８（ｂ）におけるように、これは、ノードがチャネル５上でビーコンを逸失する原因となることを注記しておく。

以上、本開示では、具体的な例によって本発明について説明した。本発明の範囲は、添付する特許請求の範囲によって定められるものとする。

本発明は、ワイヤレス通信技術に関する。
更に特定すれば、本発明は、ワイヤレス通信ネットワークにおける通信ノードの動作方法に関し、ノードが少なくとも１つのアクセス・ポイントを経由して中央通信ユニットと通信する。更に、本発明は、このようなワイヤレス通信ネットワークにおいて動作する通信ノードに関する。

また、本発明は、このような通信ノードが含まれる、ワイヤレス通信システムおよび格納システムに関する。

垂直スタックに積層された複数の収納庫を収容する三次元格納グリッドを含む格納システムは、オートストア(AutoStore)として知られている。グリッド構造上には支持レールが配置され、複数の車両がグリッド構造上のレールに沿って移動するように構成されている。

車両は、垂直スタックから収納庫を選出し(pick up)、これらの収納庫を所望の位置に移動させ、これらを垂直ポートに搬送し、更に、中央ユニットによって要求されたときには操作員に搬送するように、遠隔制御される。

このような格納システムの動作を可能にするために、ワイヤレス通信ネットワークが設けられる。各車両には通信ノードが提供され、通信ノードは、多数の通信アクセス・ポイントを経由して中央ユニットと通信する。アクセス・ポイントは、システム全体にわたって固定位置に位置付けられてもよい。

このような通信ノード、それらの動作方法、および通信システム全体を提供するとき、様々な課題が発生する。
例えば、このシステムは、物理的レイアウトおよび規模に関して汎用性がなければならない。使用中の車両数（および関連する通信ノード）は柔軟でなければならない。グリッドは、格納システムが設置される構内の物理的固有性(properties)によって決定される種々の形状をなすことができる。したがって、広範囲の異なる物理的トポロジを当然処理できる通信ノードを、車両に提供しなければならない。

ワイヤレス通信システムは、グリッド上の全ての位置に対して見通し線を有することが不可能であっても、全ての車両と常時通信できなければならない。信号を妨害する柱および壁のような、多数の障害物があるおそれがある。このような障害物は、反射を混入させる可能性もあり、ワイヤレス通信システムはこの反射も処理しなければならない(handle)る。

通信システムは、干渉する背景無線信号、例えば、Ｗｉ−Ｆｉ通信が存在しても、信頼性高く動作するとことが好ましい。更に、通信システムは、フェイルセーフ緊急時停止機能を提供することも好ましい。

また、通信速度、タイミング、およびスループット要件というような、一般的な要件も満たさなければならない。
その他の可能性のある要件および／または所望の固有性には以下が含まれる。

・ノード間通信を必要としない。
・多重ホップ・ルーティングを必要としない。
・短い応答時間が要求される。

・完全なデータよりも更新データの方が重要である。即ち、メッセージの損失の方が、長い遅延よりも優先することができる。
・ノードによって送信されるデータの量が、ノードによって受信されるデータの量よりもはるかに多い。

・中央ユニットは、ネットワーク・マネージャとして機能できなくてよい。
・ノードは、アクセス・ポイント間で素早く切り替えることができなければならない。
・データ負荷は、実質的に時間単位で(by time)変動することができる。

・ノードの割り当て容量の固定は望ましくない。
種々の標準化された通信プロトコルや、その他の既に知られている通信プロトコルが存在するが、これらは以上の要件および所望の固有性の内一部を満たすことができるに過ぎない。

しかしながら、既存の通信プロトコルの短所(shortcoming)および欠点(drawback)のために、ワイヤレス通信ネットワークにおける改良通信ノード動作方法、改良通信ノード、改良通信システム、および改良格納システムを提供することが求められている。

ＵＳ−２０１４／０８６０８１Ａ１は、ノードを含む通信システム、中央通信システム、およびアクセス・ポイントについて記載する。これらは、チャネル品質を判定し、整列チャネル・リストを提供するために使用する。整列リストにしたがって、アクティブな通信チャネルを選択する。整列チャネル・リストの提供、および整列リストにしたがうアクティブ・チャネルの選択は、中央ダイナミック・スペクトル管理エンジンに含まれるチャネル管理機能によって実行される。チャネル管理機能およびダイナミック・スペクトル管理エンジンは、通信システムにおいて中央エレメントとして設けられる。
ＵＳ−６０５２５９４は、メディア・アクセスを制御する方法およびシステムに関し、データ・パケットがワイヤレス局へのダウンリンク送信のために受信されたときに、基地局からワイヤレス局にページング・メッセージが送信される。基地局は、複数の基地局の内の１つであり、ワイヤレス局はこの基地局と関連付けられている。ページング・メッセージに応答して、ワイヤレス局において、複数のパイロット周波数信号の各々のレベルが検出される。各パイロット周波数は、ダウンリンク・トラフィック・チャネルに対応し、そのダウンリンク・トラフィック・チャネルが割り当てられた基地局によって送信される。ワイヤレス局は、トラフィック・チャネルの優先順位、およびパイロット周波数信号の検出されたレベルに基づいて、好ましいトラフィック・チャネルのリストを生成し、関連付けられた基地局にこのリストを送信する。ダウンリンク・トラフィック・チャネルは、好ましいトラフィック・チャネルのリストに基づいて、受信したデータ・パケットをワイヤレス局に送信するダウンリンクのために割り当てられ、基地局においてチャネル優先順位を更新する。

本発明は、添付する独立請求項によって定められている。好ましい実施形態は、従属請求項によって定められている。
したがって、本発明の一態様では、ワイヤレス通信ネットワークにおける通信ノードの動作方法を提供する(has been provided)。この方法では、ノードは少なくとも１つのアクセス・ポイントを経由して中央通信ユニットと通信し、この方法は、
−ノードにおいて、アクセス・ポイントからのワイヤレス信号を受信するステップと、
−ノードによって、受信したワイヤレス信号に基づいてチャネル品質情報を判定するステップと、
−ノードによって、判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定するステップと、
−ノードによって、決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択するステップと、
−ノードによって、選択したアクティブ・チャネル上でワイヤレス信号を送信するステップと、
を含む。

他の態様では、ワイヤレス通信ネットワークにおいて動作する通信ノードを提供する。ネットワークは、このノード、中央通信ユニット、および少なくとも１つのアクセス・ポイントを含む。このノードは、
−アクセス・ポイントからのワイヤレス信号を受信し、
−受信したワイヤレス信号に基づいてチャネル品質情報を判定し、
−判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定し、
−決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択し、
−ノードによって、選択したアクティブ・チャネル上でワイヤレス信号を送信する、
ように構成されている。

中央通信ユニット、少なくとも1つのアクセス・ポイント、および本明細書において開示するような少なくとも１つの通信ノードを含むワイヤレス通信システムも、本発明によって提供する。

最後に、本発明は格納システムに関する。この格納システムは、垂直スタックに積層された複数の収納庫を収容する三次元格納グリッドと、グリッド構造上の支持レールと、格子構造上のレールに沿って移動するように配置された複数の車両であって、各車両が少なくとも1つのアクセス・ポイントを経由して中央通信ユニットと通信するように構成され、各車両が本明細書において開示するような通信ノードを含む、車両とを含む。

本発明の種々の態様および特徴について、理解を助ける例として示す添付図面と合わせて説明するが、開示する態様および特徴に本発明を限定するのではない。
図１は、格納システムの原理を示す模式図である。 図２は、通信システムの原理を示す模式ブロック図である。 図３は、通信ノードの原理を示す模式ブロック図である。 図４は、通信ノードの動作方法を示す模式フロー・チャートである。 図５は、基本ビーコン・シーケンス(basic beacon sequence)の原理を示す模式タイミング図である。 図６は、チャネル間の時間オフセットの原理を示す模式タイミング図である。 図７は、ビーコン送信のフェーズ(phase)の原理を示す模式タイミング図である。 図８は、通信シーケンスの種々の態様を示す、４つの模式タイミング図を含む。 図８は、通信シーケンスの種々の態様を示す、４つの模式タイミング図を含む。

図１は、格納システム１００の原理を示す模式図である。
格納システム１００は、垂直スタックに積層された複数の収納庫を収容する三次元格納グリッド構造１１０を含む。グリッド構造１１０の上面上に支持レール１２０が二次元的に配置されており、グリッド構造１１０の上面上に配置されたレールに沿って移動するように、複数の車両１３０が配置されている。

車両１３０は、垂直スタックから収納庫を選出し、これらの収納庫をグリッド構造１１０の上面上における所望の位置に移動させ、これらを垂直リフトおよび／またはポートに搬送し、中央ユニット１５０によって要求されたときに更に操作員まで搬送するように遠隔制御される。

このような格納システム１００の動作を可能にするために、ワイヤレス通信ネットワークが設けられている。各車両１３０には通信ノード（図１には示されていない）が設けられており、通信ノードは、多数の通信アクセス・ポイント１４０（簡略化のために１つだけ示されている）を経由して、中央ユニット１５０と通信する。通信アクセス・ポイント１４０は、システム１００全域にわたり固定位置に位置付けることができる。

図２は、通信システムの原理を示す模式ブロック図である。
図２において、４つの通信ノード３００ａ、３００ｂ、３００ｃ、３００ｄが示されている。各ノードは、格納システム１００内にある車両（図１に示す車両１３０のような）に含まれることを意図している。尚、１および２５０の間の任意の数というように、任意の適した数の通信ノードをこの通信システム内に設けることができることは理解されてしかるべきである。場合によっては、２５０個よりも多い通信ノードも使用することができる。一部のノードは、格納システムにおける車両のための通信ノードであること以外の目的に供することもできる。

各ノード３００ａ、３００ｂ、３００ｃ、３００ｄは、アクセス・ポイント１４０ａ、１４０ｂを経由して中央ユニット１５０と通信するように構成されている。図示のように、アクセス・ポイント１４０ａは、ノード３００ａとのワイヤレス通信を提供し、一方アクセス・ポイント１４０ｂは、ノード３００ｂ、３００ｃ、および３００ｄとのワイヤレス通信を提供する。ワイヤレス通信は、好ましくは、無線通信である。尚、１および１０の間の任意の数というように、任意の適した数のアクセス・ポイントを通信システム内に設けてもよいことは理解されてしかるべきである。場合によっては、１０箇所よりも多いアクセス・ポイントも使用することができる。尚、通信ノードとアクセス・ポイントとの間の連携(association)は、通信システムおよび格納システム１００の動作中に動的に変更できることは理解されてしかるべきである。

アクセス・ポイント１４０ａ、１４０ｂと中央ユニット１５０との間の通信は、場合によっては、例えば、電気または光接続による有線であってもよい。他の態様では、アクセス・ポイント１４０ａ、１４０ｂと中央ユニット１５０との間の通信は、ワイヤレス、例えば、無線(radio)にしてもよい。

図３は、通信ノードの原理を示す模式ブロック図である。
通信ノード３００は、内部バス３１０を含むことができ、とりわけ、マイクロプロセッサのような処理デバイス３４０、ＲＯＭまたはフラッシュ・メモリのような不揮発性メモリ３２０、およびＲＡＭのような揮発性メモリ３３０を相互接続する。不揮発性メモリ３２０は、１組の処理命令をコンピュータ・プログラムの形態で収容することができ、処理デバイス３４０によって処理命令が実行されると、本開示において指定するような方法を通信ノード３００に実行させる。揮発性メモリ３３０は、処理命令の実行中に処理デバイスによって使用される可変データ(variable data)を収容することができる。また、ワイヤレス通信デバイス３７０もバス３１０に相互接続されており、アンテナ３９０の接続によって、外部アクセス・ポイント（図２には示されていない）と通信ノード３００との間で双方向無線通信を行う。また、Ｉ／Ｏデバイス３５０もバス３１０に相互接続されており、通信ノード３００と外部制御デバイス３６０との間でデータ通信を行う。外部制御デバイス３６０は、例えば、通信ノード３００が組み込まれた(arrange)車両の移動を制御するように構成された制御回路を含むことができる。また、外部制御デバイス３６０は、車両の動作に関連する信号を供給するセンサ、変換器等も含むことができる。これらの信号は、通信ノード３００によって残りの通信システムに、関連するアクセス・ポイントを経由して伝達され、更に中央ユニットにも伝達されなければならない。更に、通信ノード３００は、電源または電力処理ユニット(power handling unit)３８０も含み、通信ノード３００に含まれる回路を動作させるために電力を供給する。
通信ノード３００は、例えば、ＩＥＥＥ８０２．１５．４として知られている仕様書によって定められるような物理レベル・プロトコルを実装するように構成されてもよい。

図４は、通信ノードの動作方法を示す模式流れ図である。
図示する方法４００は、１組の処理命令として具体化された、コンピュータ・プログラムとして実装することもでき、処理命令はメモリ（先に図３を参照して述べた不揮発性メモリ３２０のような）に収容され、通信ノード３００において処理デバイス３４０によって実行することができる。

方法４００は、ワイヤレス通信ネットワークにおいて通信ノードを動作させる方法であり、ノード３００は、少なくとも１つのアクセス・ポイント１４０を経由して、中央通信ユニット１５０と通信する。

この方法は、初期化ステップ４１０において開始する。
最初に、受信ステップ４２０において、アクセス・ポイント１４０からワイヤレス信号をノード３００において受信する。

更に、チャネル品質判定ステップ４３０において、ノード３００によって、受信したワイヤレス信号に基づいてチャネル品質情報を判定する。
更に、順序決定ステップ４４０において、判定されたチャネル品質にしたがって序列されたアクティブ・チャネルの順序をノード３００によって決定する。

次に、選択ステップ４５０において、決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルが、ノードによって選択している。
次に、送信ステップ４６０において、ノードによって、選択ステップ４５０において選択された通りに、選択されたアクティブ・チャネル上でワイヤレス信号を送信する。

この方法は、繰り返すか、または終了ステップ４７０において終了することができる。
好ましくは、ワイヤレス通信ネットワークは、ビーコン対応搬送波感知多重アクセス（ＣＳＭＡ）に基づくネットワークである(beacon enabled carrier sense multiple access (CSMA) based network)。

選択されたアクティブ・チャネル上でノードによってワイヤレス信号を送信する送信ステップ４６０は、好ましくは、搬送波感知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用してメッセージを送信することを含んでもよい。

好ましい態様では、ノードによって実行される方法４００は、更に、アクセス・ポイントからのビーコン・データの受信によって提供されるビーコン・タイミング情報を連続追跡する(lock on)ステップを含んでもよい。

好ましい態様では、この方法は、更に、ノードによって、タイムスロット・パターンにしたがってチャネル全体を反復するステップも含む。
また、図示する方法４００は、アクセス・ポイント１４０と共に付与または実行されるステップあるいはエレメントを含んでもよい。一態様では、方法４００は、更に、ビーコン送信モードでアクセス・ポイント１４０を動作させるステップを含んでもよい。このようなビーコン送信モードでは、アクセス・ポイントはワイヤレス・ビーコン・データをノード３００に送信する。また、アクセス・ポイントを待ち受けモード(listening mode)で動作させることもできる。待ち受けモードでは、アクセス・ポイントは、ノードから受信したデータを、中央通信ユニット１５０に中継する。

好ましい態様では、ノード３００およびアクセス・ポイント１４０を共通クロック信号によって同期させることができる。
開示する動作方法に可能な更に別の一般的態様および関連する利点は、以下から明らかになる。

態様１。任意の数の時間同期されたＡＰが、それらに現在割り当てられているチャネルにしたがって専用タイムスロットにおいてビーコン・フレームを送信することができる。任意の所定パターンを使用することができる。ノードは、ビーコン・タイミングを連続追跡することができ、タイムスロット・パターンにしたがって全てのチャネルにわたって連続的に反復する。利点：ノードは範囲内における全てのＡＰを把握し、これらの全てからビーコンおよび収容データ(contained data)を受信する。

態様２。ＡＰは、そのビーコン送信の間、待ち受けモードになり、ノードからの全ての着信フレームを中継する。ビーコン・フレームは、直前のビーコン以来受信したフレームに対する確認応答(acknowledgement)、および発信データ(outgoing data)を収容することができる。ビーコンにおいてデータを受信したノードは、専用確認応答フェーズにおいて、または通常のデータ・フレームを通じて、これに確認応答することができる。

態様３。ノードは、受信信号品質にしたがって、アクティブ・チャネルを序列することができる。ノードが送信することを望むとき、この序列にしたがって順次利用可能なチャネル上でＣＣＡを実行することができる。一旦空きチャネルが発見されたなら、送信を開始することができ、そうでない場合、ノードは、再試行する前に、ランダム遅延を実行すればよい。利点：大多数のノードが同じＡＰをそれらの好ましいものと見なす場合でも、トラフィックが自動的に利用可能なＡＰにわたって分散する。

態様４。中央ユニットがフレームを特定のノードに送信することを望むとき、そのフレームを、そのノードの範囲内にある任意のＡＰを経由して導出する(route)ことができる。最も簡単な場合では、これは、ユニットが最後にそのノードからメッセージを受信したＡＰを経由して、それを導出することを伴うのでもよい。この手法の精度は、ＡＰに対するノードの速度と比較して、ノードがメッセージを送信する頻度のみに依存する。利点：ノードは、単にフレームを送信することによって自動的に中央ユニットに経路表(route table)を維持するので、ルーティング・アルゴリズムの必要性がない。

態様５。ＡＰが、何らかの理由で、他のチャネルに移動することを望む場合、物理的に周波数を変更することを除いて、必要とされる唯１つのアクションは、そのビーコン・タイミングを適宜に変更することである。範囲内にあるノードはいずれも、１つのＡＰが範囲から出て、他のものが入ったかのようにこれを単純に解釈し、このプロセスを完全にシームレスにし、更に中央ユニットおよびノード双方から見えなくする。利点：スループットの低下(penalty)を殆ど生ずることなくチャネル選択を行うことができ、非常に小さいコストで、ノイズが多いチャネルからＡＰが移動することを可能にする。

態様６。ノードは、ビーコンを待ち受けている間、全てのチャネル上でエネルギ測定を実行する。このデータを列挙して、送信されるフレームに添付することができ、互いについてのＡＰの知識、および範囲内におけるあらゆる外部送信機(alien transmitter)についての知識を与える。利点：ＡＰは、その特定の地理的位置において最適なチャネルをインテリジェントに選択することができる。このように、規則的干渉および不規則な干渉の双方を動的に回避し、プロトコルを極めてロバストに、そして非常に非侵襲的にすることができる。

開示した動作方法、通信ノード、通信システム、および格納システムは、図５、図６、図７、および図８ならびに以下のそれらの対応する説明を参照することによって、更に詳しく図示および説明することができる。
未確認応答フレーム(unacknowledged frames)
１つの態様では、ノード３００からアクセス・ポイント１４０に送信されるメッセージ については、直接確認応答(direct acknowledgement)を飛ばしてもよい。代わりに、確認応答は、ビーコン内にノード・アドレスのリストの形態で含むことができる。この手法は、全体的なオーバーヘッドを著しく低減することができるが、ビーコンが大きくなり、フレームと確認応答との間の最大遅延がビーコン期間と等しくなり、ノードはビーコンの頻度よりも高い頻度で送信することができないという欠点がある。

ノードが７Ｈｚの最大頻度で送信することを指定する要件を一例としてあげると、ビーコン頻度がこれよりも高い場合はいつもで、ノードは、それらが望むメッセージを全て送信できることを意味する。２０から４０Ｈｚまでの任意のビーコン頻度を有することが実現可能であると仮定すると、ビーコン期間は５０および２５ｍｓの間のいずれかの値となる。メッセージの大部分を１００ｍｓ以内に送信しなければならないことを指定する要件では、確認応答のために５０ｍｓまで待たなければならないとしても、十分に許容範囲内であることがわかる。
専用確認応答フェーズ
１つの態様では、ビーコンに続くアクセス・フェーズ内のある時点における時間期間を、直前のビーコンにおいてメッセージを受信したノードからの確認応答専用にすることができる。これによって、ノードがＣＳＭＡ／ＣＡを使用しなければならない場合と比較して、確実にそれらの確認応答を送ることができる。８０２.１５.４規格の下では、これは、メッセージを受信したノードにＧＴＳを割り当てることによって行うことができ、ノードはその確認応答、および保留中のメッセージを有する場合には、おそらくそのメッセージも送信する。これの欠点は、ＧＴＳがビーコン期間の終了時に制限されることであり、これが意味するのは、可能な最も遅い時点に確認応答が到達するということである。また、この規格は、ＧＴＳのサイズに関して柔軟性が限定され、要するに、１回の確認応答に対してＧＴＳがかなり過大となる(way oversized)ため、帯域幅が浪費されることになる。これに対する可能な解決策は、８０２.１５.４規格を破棄して、ＧＴＳがビーコンの直後に来る固有の解決策を作ることであろう。
チャネル・アジリティ(Channel agility)
１つの態様では、チャネルに関して、システムをもっと動的にし、自己管理させて、全てのチャネル処理(handling)をプロトコル自体の内側に隠すことを究極的な目標とすることが望ましい場合もある。何らかの全体タイミング基準(global timing reference)に対して一意の時間オフセットを全てのチャネルに割り当てる解決策が提案された。各アクセス・ポイントは、それに割り当てられたチャネルに専用のタイミング・オフセットに続いてそのビーコンを送信する。

図５は、基本的なビーコン・シーケンスの原理を示す模式タイミング図である。
アイドル・ノードが一旦シーケンスに同期されると、全てのチャネルを巡回して、範囲内にある全てのアクセス・ポイントからのビーコンを検出する。これの簡単な図を図５におけるタイミング図５００に表し、７つのチャネルを使用する例、およびどのようにそれらのビーコンを順次時間内に(in time)配置するかについて示す。この図では、チャネル１および５がアクティブであり、一方残りのチャネルは使用されていない。これが意味するのは、ノードは待ち受けているが、ビーコンを全く取得せず(pick up)、つまりこれらのチャネルをアクティブ・チャネルのリストには含まないということである。これは、シーケンスがチャネル７に達したときに、どのようにしてチャネル１に戻るかを示す。全体的時間基準の導入は、この手法の成否を決めることであるが、可能でありしかも便利であった。何故なら、オートストアにおいて使用されている既存のプロトコルは既にこのような基準を有しており、したがってこの機能を再利用するためには、些細な調節しか必要とされないからである。既存の同期メカニズムは、１３０Ｈｚ信号が、中央安全モジュール(central safety module)から全てのＡＰに、ＡＰのＰＯＥ供給に関連付けて分散されるという形態となっている。この手法を使用することにより、ルーティングの必要性が著しく低下する。ノードは、ＡＰがいつ範囲に入るかまたは範囲から出るか自動的に検出し、それに応じてその利用可能なＡＰのリストを調節する。ノードが送ることを望むとき、チャネル巡回を続け(put on hold)送信に最も適したチャネルを連続追跡する。ここでは、ＣＳＭＡ／ＣＡを使用してそのメッセージを送信し、試みが成功した場合、確認応答を収容する次のビーコンを待つ。ＣＣＡが失敗した場合、１つよりも多いチャネルが利用可能であるならば、ノードは直ちに他のチャネル上で自由にアクセスを試すことができる。このように、トラフィック負荷は利用可能なＡＰ間で自動的に拡散する。

サーバがメッセージをノードに送ることを望むとき、そのノードからメッセージを最後に受信したＡＰを経由して、メッセージを中継する。これによって、サーバのための経路表を非常に簡単にし、更に自己管理を行わせる。

また、ＡＰは、前もってノードまたはサーバに通知する必要なく、チャネルを随意に変更することができ、ノードは、単に、１つのＡＰが範囲から出て、他のＡＰが範囲に入ったことを確認するだけでよく、システムを非常に柔軟にする。

この手法を用いることによる２つの落とし穴の内１つは、ノードが、１つのチャネル上で送信している間に、異なるチャネル上でビーコンにおいてメッセージを受信しているかもしれないことである。これは、ノードが２つのＡＰ間の境界を交差し、つまりそれがその好ましい送信チャネルであると見なすものを変更するときには、当然の成り行きである。また、ノードは、送信元ＡＰの範囲から単に退出した(move out of)だけであるという可能性もある。この問題を克服するために、最も重要なことは、全ての再送信の役割(responsibility)をサーバに移すことである。このようにすると、メッセージに対する確認応答を受信しないＡＰは、単に、メッセージが失敗したことをサーバに報告するだけでよい。したがって、メッセージを再送信するのは、同じＡＰであれ異なるＡＰであれ、サーバ次第となる。この手法を使用すると、この効果から(from this effect)失われた各パケットを正しいチャネル上で殆ど直ちに再送信することができる。何故なら、サーバにおいてノードに接続されているチャネルは、殆どの場合、最初の送信失敗と並列に更新されるからである。また、ノードからサーバに向かうメッセージの数は、他に向かうメッセージの数よりも遙かに多いので（表１．１に指定するように、毎秒１〜７に対して３秒毎に０〜１）、サーバが新たなメッセージを最初に送信しようとする前に、ノードが新たなチャネル上でメッセージを送信する可能性が非常に高く、したがってそういう事態は発生しそうもない(less likely)と推論することができる。

第２の落とし穴は、ＡＰが異なるものに移動した後に、ノードがチャネル上で送信しているかもしれないことである。これは、チャネル交換が差し迫っていることの何らかの情報をビーコンに添付させ、ＡＰに、ノードが送信するのを防止することによって回避することができ、またはこの事態からパケット損失が発生することを単に受け入れることもできる。ビーコン期間が２５〜５０ｍｓであると仮定すると、ノードは次の期間においてメッセージを安全に再送信することができ、それでもなお１００ｍｓ以内というレイテンシ要件を十分に満たすことができる。したがって、このアーチファクトは、この手法全体で得ることができる効果を考えれば、容認可能な犠牲と見なすことができる。
シーケンス番号
このシナリオでは、全ての確認応答された通信に関して、一見すると失敗のように見える送信は、元のメッセージが正しく送信されなかったことによって、または確認応答が失敗したことによって発生する可能性があり、送り手の視点からのみ、送信が不成功であったように思わせる。これは、シーケンス番号の使用によって最良に処理する(handle)ことができ、受信機は、メッセージが以前のメッセージの再送信か否かチェックする。この場合、直前の章で紹介したように、ノードがＡＰ間で継ぎ目なく移動すると、ＡＰはメッセージが複製か否か知ることができないことは明らかである。これは、ノードが受信するメッセージはいずれも、以前に異なるチャネル上で送信することを試されていたかもしれないからである。理論的に、ノードは、パケット送信毎に、２つのＡＰ間で交換することができる。このために、シーケンス番号をプロトコルに含ませることは無意味であり、サーバおよびノード上で実行するアプリケーションによって、もっと高いレベルでシーケンス番号が添付されなければならない。これによって、シーケンス番号が有効に作用するために必要とされる、直接の１対１リンクが形成される(create)。
アドレシング
表１．１において、２５０、つまり、１バイトのアドレシングで十分可能なことを暗示する数の独立したノードをシステムは処理(handle)できなければならないことが指定されている。しかしながら、この要件は、システムによってサポートされるノード数ではなく、スループットに大きく関係する。したがって、２５６よりも多いノードのアドレシングを可能にすることが非常に望ましい。これによって、本解決策が、後の段階において可能性がある拡張や変更に対して将来においても有効であることを確保する。８０２．１５．４規格は、通常の通信の間１６ビット・アドレスを使用し、必要であれば、標準的なＭＡＣアドレス全てを利用して、６４ビット・アドレスに戻ることができる。この場合には６４ビット・アドレスの必要性には全く関心がなさそうであっても、１６ビットは、関連するシステム要件を満たすべき非常に合理的なノード数を生み出す。

拡張チェックサム(extended checksum)
他の可能な考慮事項に、８０２．１５．４において使用される通常の１６ビットよりも大きなチェックサムの必要性がある。これの理由は、破損したパケットが純正なコマンド(genuine command)として受け入れられたという以前の経験である。わずか１／６５５３４の確率であるが、無線環境にノイズが多く最適でない場合、送信されるメッセージ量が、このような小さい確率であっても、それを毎年複数回発生させることになり、このような事態の結果は破滅的となる可能性がある。新たなプロトコルを用いれば、この問題は、この以前の解決策による短期の場合ほど重大になりそうにない。しかし、その時点以降、選択は備えあれば憂いなしとなった。これが意味するのは、余分な１６ビットチェックサムの追加は、十分に価値のあるオーバーヘッドであると見なされるということである。
ネットワークＩＤ
チャネル巡回が有効に作用するためには、ノードをシーケンス・タイミングから逸脱させる(bring out of)可能性がある外来ビーコン(alien beacon)によってノードが混乱させられなくすることが有用であろう。これは、２つのオートストアの設置(installation)が互いの無線範囲内で行われた場合に起こる可能性がある。２つの設備 (installation) のＡＰは、同じ全体クロックに従わず、このため互いに同期から外れることになる。すると、ビーコンを求めている(search for)ノードが、正しくないウェアハウスのシーケンスを連続追跡する危険に晒される可能性がある。この問題を克服するために、ネットワークＩＤを導入することができる。これによって、ノードが、それらに全く関心のないビーコンを排除することを可能にし、更に、ＡＰが、近隣ネットワークからのあらゆるデータ・フレームを排除することも可能にする。通常の実行条件(running conditions)の下では、ＡＰは異なるチャネル上に定在しており、更に、十中八九、同期が外れているはずなので、いずれの事態も一般には発生しない。これが意味するのは、同期されているノードは偽ビーコンを全く取得せず(pick up)、外来ノードが近隣ＡＰのチャネル上で送信することはないということである。しかしながら、ノードが同期を失いビーコンを捜さなければならない場合、衝突が差し迫っている。

この手法に伴う１つの課題は、ノードがいかにして最初にネットワークと連携すべきかである。何故なら、ノードは純粋に無線でシステムと通信することを意図しているからである。これを克服するために、この１つの特定ネットワークｉｄを「ドントケア」値(don't care value)に設定することであり、この場合、ノードは任意のネットワークに同期し、次いで、この値は、プロトコルによって使用されるデフォルト値となる。次いで、この特定のネットワーク上でサーバと接触し、これらが連携するか否か尋ねるのは、アプリケーションに委ねられる。そうでない場合、このネットワークｉｄはブラックリストに追加される可能性があり、ノードは新たなビーコン・スキャンを行うことを強制される。正しいネットワークが発見されたなら、このネットワークｉｄを今後の使用のために不揮発性メモリに格納するとよい。これが意味するのは、この連携手順は、最初にノードがネットワークに追加されるときにだけ行えばよいということである。
ブロードキャスティング
システムの通常動作に加えて、ブロードキャスティングのための特殊モードもサポートすることができる。このモードは、無線リンクを跨いでノードを再プログラムするために使用することができる。これは、ＡＰが大きなプログラム・ファイルを全てのノードにブロードキャストすることを伴い、ファイルを検証した後、ブート・ローダがモジュール上にそれをロードする役割を担う(take care of)。このモードは、通常動作とは完全に別にすることができる。何故なら、これが使用されるのはシステムが静止(stationary)およびアイドル状態にあるときだけであるからである。また、このモードは比較的単純である。何故なら、ノードは１つのチャネルを連続追跡し、そのＡＰからファイル全体を受信でき、そして受信しなければならないからである。したがって、この機能(feature)の実施は本願(this thesis)にとっては全く関心がないが、一旦作業が完了して統一システムを得るためにプロトコルを定めるときには、考慮に入れなければならない。

完全に固有の解決策(proprietary solution)が相応しい場合もある。何故なら、これは、既存の規格に調整する必要なく、最初から構築することによって大きな効果が得られるからである。また、システムは、必ずしも、他のいずれかのシステムまたはモジュールと通信することを仮定しておらず、実際、エラーを回避するために、このようなイベントをできるだけ起こり難くすることが望ましい。先に説明した戦略を想定した８０２．１５．４の使用が可能であるが、結果的に得られるプロトコルは必ずしも最適であるとは限らず、８０２．１５．４が提供する機能(feature)の多くは必ずしも必要とされず、不必要なオーバーヘッドを追加するおそれがある。このプロトコルの効率を最大限高めるために、ＭＡＣレベルの完全に固有の解決策を、８０２．１５．４において記載されているＰＨＹレベルと共に使用することもできる。これは、無線ＳｏＣの大多数が８０２．１５．４をサポートしており、この規格における物理的記述(physical description)上に構築されるという事実に基づいて、行うことができる。しかしながら、ＭＡＣレベル上の機能は、多くの場合、部分的にソフトウェアで行われる。これが意味するのは、開発者は、望むときに、容易に規格から逸脱できるということである。
無線モジュール
無線ハードウェアは、Ｄｒｅｓｄｅｎ Ｅｌｅｃｔｒｏｎｉｋ社のｄｅＦＲＭｅｇａ１２８−２２Ｃ０２を含むのでもよい。このモジュールは、ＡｔＭｅｇａ１２８ＲＦＡ１チップをカプセル化し、ＲＦ遮蔽、オンボードＥＥＰＲＯＭ、オンボード水晶発振器、およびオンボード同軸アンテナ・コネクタを含む。ＡｔＭｅｇａの事実上全てのピンが、外部からアクセス可能であり、このチップをプラグ・アンド・プレイ・ハードウェア解決策としつつも、最大の柔軟性に対処する。このモジュールは、カスタム無線モジュール上に実装される。また、このチップは、ＡＰ上におけるＴＣＰ／ＩＰ通信および格納システム内にある車両上のハードウェアの残り部分との通信を処理する(handling)他のマイクロコントローラも内蔵する。
ＡｔＭｅｇａ１２８ＲＦＡ１
ＡｔＭｅｇａ１２８ＲＦＡ１は、強力なマイクロプロセッサを内蔵し、無線モジュールに直接アクセスすることができる完全なチップ上システムである。無線モジュールは、使いやすいインターフェースを有し、制御およびデータ・レジスタにソフトウェアから直接アクセスすることができる。また、これは、全ての重要な無線イベントを示す様々な専用割り込みも有する。
トランシーバ
トランシーバは、ＩＥＥＥ８０２.１５.４物理レイヤ変調方式、チャネル構造、物理プリアンブル、チェックサム計算、およびＣＣＡを実現する。また、エネルギ検出およびリンク品質指示は、ハードウェアで利用可能である。ＭＡＣレベルには、自動確認応答(automated acknowledgement)、規格によるＣＳＭＡ／ＣＡ送信および再送信、ならびに自動アドレス・フィルタリングのために専用モードがある。他のハードウェア・アクセレレータには、ＡＥＳ１２８ビット暗号、真の乱数発生器、および８０２.１５．４規格においてサポートされるものよりも高いＰＳＤＵレートが含まれる。５００ｋｂ／ｓ、１Ｍｂ／ｓ、および２Ｍｂ／ｓの双方がサポートされる。

全体的に、このチップは、８０２.１５．４規格上に直接構築される任意のプロトコルの容易な実装を可能にするが、トランシーバは、ユーザが、必要とされるときに、規格から逸脱することを許容するレベルで制御可能である。とりわけ、ＳＦＤは、専用レジスタを介してアクセス可能であり、可能な限り最も低い「変調前」レベル(pre modulation level)上で、無線機がそのフレームを８０２．１５．４フレームから区別することを可能にする。
Ｍａｃシンボル・カウンタ
８０２.１５．４は、プロトコルのタイミングを維持するために、シンボル・カウンタの使用を暗示しており、このカウンタは、計画されているフレーム受信の前に、トランシーバを起動する(wake up)ことができなければならず、更に、規格に指定されている通りに、ＧＴＳスロットおよびＣＳＭＡ／ＣＡバックオフ・スロット(CSMA/CA backoff slot)の精度高い実行を可能にする。ＡｔＭｅｇａ１２８ＲＦＡ１では、このカウンタは、３つの独立した比較器、および専用のバックオフ・スロット・カウンタを内蔵しており、８０２.１５．４準拠フレームを使用するときに、自動ビーコン・タイムスタンプ付与(timestamping)を可能にする。
ＲＳＳＩおよびエネルギ検出
任意の受信モードにあるとき、このチップは、現在のＲＳＳＩを用いて、レジスタを継続的に更新する。これは、信号がデコード可能か否かには関係なく、チャネル上における現在のエネルギ・レベルの測定値である。次いで、この値を直接読み出すことができ、または代わりに、もっと精度の高いエネルギ検出レジスタを使用することができる。エネルギ検出は、ハードウェア先導(hardware driven)であり、８シンボルにわたる平均ＲＳＳＩを計算する。次いで、この手順の完了が割り込みによって通知される。手作業によるエネルギ検出に加えて、これは有効なＳＨＲの受信時に常に自動的に開始される。これが意味するのは、一旦フレームが完全に受信されたなら、ＥＤレジスタは、受信された物理信号強度の指示を収容するということである。
最終的なプロトコルの概念
先に示した要件および論述にしたがって、プロトコルを満たすためにおそらく望まれる機能(feature)のリストを示す。

−設定周波数でビーコンを送信する。チャネル間の時間オフセットは１つのこのようなビーコンの長さに等しい。
−全てのＡＰ、およびその後に同期するノードに対する全体時間基準。

−送信に使用されている場合を除いて、ノードが全てのチャネルをスキャンし、全てのビーコンを受信する。
−ビーコン期間のアクセス・ウィンドウにおいてＣＳＭＡ／ＣＡを使用して送信されるデータ・フレーム。

−１つのチャネル上でＣＣＡが失敗すると、ノードは他の利用可能なチャネルにアクセスしようとする。
−続くビーコンにおいてノード・アドレスのリストとして送られるデータ・フレームに対する確認応答。

−各ビーコンの直後にあり、メッセージを受信したノードによって使用される専用確認応答フェーズ。
−プロトコル・レベルでは再送信せず、全ての送信失敗を逆にアプリケーションに報告する。

−必要とされるときにおける、チャネル品質の測定値およびチャネルの変更。全てはプロトコル内部に隠蔽される。
−ＡＰがもっと大きなファイルを接続されている全てのノードに転送することを許可するブロードキャスト・モード。

−チャネルによってのみ識別されるノード、ＡＰの１６ビット・アドレシング。
−近隣以内において複数の設備(installation)を許容するネットワークＩＤ。
−合計３２ビットのチェックサム。

−オーバーヘッドを最小に抑えるための特殊フレーム・ヘッダ。
この機能リストに基づいて図５から修正したバージョンのビーコン・シーケンスを図６に示す。これは、チャネル間の時間オフセットの原理を示す模式タイミング図６００を含む。

専用確認応答フェーズの追加により、データ・フェーズが多少短縮するが、他の方法では確認応答がアクセス・ウィンドウ内で送信されることを考慮に入れると、これは全体的なスループットには全く影響がない。アクティブ・チャネル毎の総アクセス・ウィンドウは、利用可能なチャネル数から２を減算し、１副期間(subperiod)の長さを乗算した値に等しい。通常の状況下では、８０２.１５.４物理定義(physical definition)は、２．４ＧＨｚ帯域において１６チャネルを使用する。これが意味するのは、チャネルは、時間の内１４／１６を送信に使用可能であり、最後の２／１６はビーコンおよび確認応答フェーズによって占有されるということである。

ビーコンは厳格なタイミングに従わなければならないので、これらが予想されるときには常に送信していることが重要である。これが意味するのは、この送信の前にＣＣＡを行うのは無駄であるということである。この衝突回避対策がないと、態様によっては、エリア内の他のネットワーク、Ｗｉ−Ｆｉ等に問題を起こすおそれがあるが、２．４ＧＨｚ帯域において利用可能な全帯域幅を想定すると、他のシステムと共有されていないチャネルをプロトコルが発見できるという仮定は、合理的である。このように、直接送信は全く問題を生じないはずである(should)。衝突があった場合、このプロトコルにとって最悪のシナリオは、ノードがビーコンをデコードできず、このため、ＡＰが範囲から外れたと信じてしまうことである。これはパケット損失を誘発する可能性がある。この事態においても、過度に頻繁に起こるのではない限り、スループットの一時的な低下を招くに過ぎない。確認応答フェーズの効率を最大限高めるためには、それを専用スロットに分割し、ノードは専用スロットにおいてそれらの確認応答フレームを直接送信することも望ましい。必要なスロット数は、１つのビーコン内に収めるメッセージ数によって異なり、これについては以下で更に論ずる。
最終的なプロトコルの定義
８０２．１５．４規格から逸脱する実施態様では、カスタム・ヘッダおよびフレーム構造を定義しなければならない。
フレーム・ヘッダ
プロトコルは、表２.１にまとめた４つの異なるフレーム形式を利用することができる。

４つの異なるフレーム形式は、ヘッダにおいて２ビット・フィールドを使用して表すことができる。使用する形式は非常に一般的であり、ほとんどの今後のシナリオにおいて十中八九再利用できそうなので、これ以上のフレーム形式は必要とされなさそうに思われる。

ヘッダにおける次のフィールドはネットワークｉｄでなければならない。２つまたは３つよりも多い独立した設備が互いの範囲内に含まれる可能性は非常に高い。しかしながら、非常に大きい設備では、それを複数の物理格子に分割することが増々実用的になっており、したがって、１つの設備が複数の独立した格子を構成するシナリオは非常に可能性が高い。このような場合、２〜６つのグリッド、またはそれ以上のグリッドは、実際には同じ全体的な設備の一部であっても、互いの範囲内にあると想像することができる。また、いくつかのネットワークＩＤを特殊目的のために、とりわけ、全ての待ち受け側(listener)によって受け入れられる「ドントケア」値のために、保存しておかなければならない。結局(in total)、８つよりも多い異なるＩＤが必要になることは可能性が低くはなく、１６個の異なるＩＤを与える４ビットが好ましい選択肢であることを意味する。

結局、６ビットのヘッダとなり、これを完全な１バイトにするために、２つの余分なビットを終端に付加する。すると、これらのビットは今後の拡張またはフレーム特定機能(frame specific feature)に利用可能となる。例えば、チャネル管理機能に関係する。ヘッダ全体を表２.２に示す。

フレーム・レイアウト
チップの一例であるａｔｍｅｇａ１２８ＲＦＡ１は、８０２．１５．４規格によるハードウェア先導チェックサム生成および検証をサポートする。また、これは、フレーム・バッファにおける第１バイトが、送信の間、同様に８０２．１５．５において定義されているＰＨＲであることも要求する。このバイトは、フレーム長と、フレームが８０２．１５．４規格に準拠するか否かを示すビットから成る。フレーム・バッファは合計で１２８バイト長であり、表２．３に見られるようなフレーム・レイアウトを有する(giving us)。次いで、チェックサムおよびその他のオーバーヘッドを差し引くと、一般的なフレームに利用可能なペイロードは、最大で１２２バイトとなる。有効なペイロードの大きさは、異なるフレーム形式が導入する余分なオーバーヘッドによって左右され、以下で更に徹底的に定義する。

データ・フレーム
データ・フレームは、ノードによってＡＰに、アクセス・ウィンドウにおいてＣＳＭＡ／ＣＡを使用して送られる。これは、１つのＡＰだけが所与のチャネル上で待ち受けているからであり、目標アドレスを全く必要としないが、送信ノードのＩＤを含まなければならい。また、データのリストが始まる前に、データ・バイトの数も添付される。結局、このために、表２．４に見られるレイアウトとなり、ここでわかるように、これには有効ペイレードに１１９バイトの余裕がある。

確認応答フレーム
確認応答フレームは、ノードによって、確認応答フェーズの間に専用スロットにおいて送ることができる。これは、厳格なタイミングを維持するためにチャネルの感知を全く行うことなく、直接送信される。このフレームは、送信ノードのＩＤだけを収容していればよい。何故なら、その特定のノードにアドレスされたメッセージの受信成功を確認することは全てのＡＰに求められるからである。フレームをできるだけ小さく抑えるために、余分なチェックサムを欠落させて(skip)、１６ビットのハードウェア先導チェックサムだけを残す。これを行うことができるのは、このフレームの破損は、ビーコンおよびデータ・フレームと比較すると、全く取るに足らないからである(completely uncritical)。ＡＰは、直前のビーコンにおいて本当のアドレス(fact address)でそれが捜したノードＩＤだけを探す。これが意味するのは、ランダムなＩＤを有する破損フレームは、チェックサムが正かったとしても、ＡＰによって受け入れられる可能性は低いということである。つまり、ノードＩＤ自体が事実上チェックサムとして作用する。結局、このために、フレーム・レイアウトは表２．５に示すようになる。

ビーコン・フレーム
ビーコンは、直前のアクセス・ウィンドウにおいて受信されたデータ・フレームに対する確認応答のリストと、異なるノードにアドレスされた可変数のメッセージとを収容することができる。プロトコルの機能を最適化するために、最も合理的な手法は、最初に確認応答のリストを追加し、次いで余裕がある限りできるだけ多くのメッセージを添付することであろう。これが意味するのは、高トラフィックの状況では、「ＡＰ−ノード」スループットが最初に影響を受け(suffer)、ノードが然るべき頻度でコマンドを受信できなくなり、更に、ノードが一層頻繁にアイドルになり、このため「ノードからＡＰに」生成されるトラフィックが減少するということである。このように、トラフィック・フローは自己規制する。

ノードが、可変数のエントリを有するビーコンを正しく解釈するために、ビーコン・ヘッダが必要となる。これは、リストにおける確認応答の数、および続くメッセージの数を収容しなければならない。また、これは、確認応答を期待していないノードが直接メッセージ・リストにジャンプすることを容易にする。

確認応答リスト
アクセス・ウィンドウが長い程、一層多くのデータ・フレームが送信される可能性が高くなり、一層多くの確認応答をビーコン内に収容しなければならない。表２．９は、送信される全てのメッセージが８バイト・ペイロードを収容すると仮定して、アクセス・ウィンドウ当たりの絶対最大理論的メッセージ数を、計算したものである。しかしながら、この数値は、ＣＳＭＡ／ＣＡのランダム性のために、非常に論理的になっている。それでもなお、フィールドの大きさを決定する(dimensioning)ときにインディケータとして使用することができる。ビーコン周波数が３０Ｈｚのとき、最大理論的データ・フレーム数は３３となり、２５Ｈｚのとき、この数は４０フレームに増加することがわかる。

他の要素にビーコンの最大サイズがある。各確認応答が２バイトを占めると、３２個の確認応答のリストは６４バイトを占めることになる。表２．９から、ビーコン・フェーズ全体で利用可能なシンボル数を求めることができ、これらのシンボルの相当な部分が、オーバーヘッドおよびノードとＡＰとの間の同期に使用されることを考慮に入れて、６４バイトよりも多くのデータまたは実際のデータを収容可能であるためには、ビーコン周波数は３０Ｈｚよりもはるかに低くなければならないと想定することができる。

これに基づくと、最大で３２個の確認応答は、リスト長を示すためには５バイトを必要とし、あらゆる現実的な状況下では十分なはずであることは明白である。
メッセージ・リスト
確認応答数と同様に、メッセージの最大数も評価しなければならない。ここでは、２つの事項を考慮しなければならない。第１に、確認応答フェーズは、最大許容メッセージ数に等しい数の確認応答を収容する(fit)ことができなければならない。表２．５に指定するように、１つの確認応答フレームは、表２．３に示すように更に５バイトから成る物理ヘッダに加えて、５バイトのデータを収容する。結局、これが意味するのは、確認応答フレームは、完全に送信するには２０シンボルを必要とし、これに加えて、確認応答スロットはいくらかのドリフトを見込んでおかなければならないということであり、あらゆる計算に対しても基本として少なくとも２５シンボルが使用されることを意味する。表２．９に見られるように、各副期間は、３０Ｈｚのビーコン周波数では１３０シンボル長となる。これは、５つまでの確認応答に対応する(allow)ことができる。

第２に、最大数のメッセージをビーコン・フレームに収容しなければならない。各メッセージは、ノードＩＤ、データ量を指定するパラメータ、およびデータ自体によって表される。表１．１において指定した要件を使用し、平均メッセージ・サイズを８バイトとすると、これはメッセージ当たり１１バイトを意味する。これに加えて、ＡＰに着信するメッセージとＡＰから発信するメッセージとの比が３／１および２１／１の間のいずれかの値にすることも、前述の要件に指定されている。各発信メッセージには、着信メッセージに対する少なくとも３つの確認応答が付随すると仮定できることを意味する。結局、これが意味するのは、ＡＰからの１つの発信メッセージは、ビーコンにおいて少なくとも平均１７バイトを占め、多くの場合、確認応答の数は遙かに多いので、それよりもかなり多くのバイトを占めると仮定することができる。

以上で述べた２つの制限(limitation)に基づいて、メッセージ・リストを最大で３に設定し、２ビットのみでコード化できるリスト長にする。これによって、後の段階で使用することができる１つの余分な保存ビットをビーコン・ヘッダに与える。
メッセージの唯一性
以上のようにプロトコルを設計すると、ＡＰが、同じノードにアドレスされた複数のメッセージを１つのビーコンに追加することを妨げるものはない。しかしながら、このためには、ノードおよびＡＰ双方が、全ての前記メッセージの確認応答を処理する(handle)ことができなければならず、望ましくない複雑さが加わる。複数の同時送信の必要性は、このプロトコルを作る対象となるユース・ケースでは決して起こるはずはなく、一般に、アプリケーションは、メッセージをバッファに追加する前に、これらを連結する(concatenate)と仮定される。何故なら、これによって十分な量のオーバーヘッドが削られる(save)からである。したがって、ビーコンはノード当たり１つよりも多いメッセージを収容してはならず、いずれのブロードキャスト・メッセージもそのビーコン内では唯一のメッセージでなければならないという単純な規則を、プロトコル定義に追加する。この制限は、ＡＰはあらゆる衝突を防止するためにメッセージをフィルタリングしなければならないが、ノードは１回の確認応答送信よりも長い間起動している必要は全くないことを暗示する。
全ビーコン・ヘッダ(full beacon header)
最終的なビーコン・ヘッダは、表２．６において見ることができる。全ビーコン・フレームは、表２．７において見ることができる。ここでは、変数ａは追加される確認応答の数を示し、ｍはメッセージの数を示し、ｋ_ｉはメッセージｉに収容されるデータ・バイト数を示す。総和、

は、現在のビーコン周波数に対する最大ビーコン・サイズよりも大きくなることはできない。この最大ビーコン・サイズについては以下で更に論ずる。
ビーコン・サイズ
ビーコン・フレームは、ビーコン周波数によってサイズが制限される。表２．９において、異なる周波数におけるビーコン期間のシンボル長を見ることができる。計算は、毎秒６２５００個の８０２．１５．４−シンボルに基づく(62500 802.15.4-symbols per second)。１つのこのようなシンボルから４ビットが得られ(make out)、１バイトは２シンボルを必要とすることを意味する。
チャネル交換
図７は、ビーコン送信のフェーズの原理を示す模式タイミング図である。

図７では、ビーコン送信および接続フェーズの大まかな素描が示されている。ビーコンを受信するようにノードを準備するために、ＡＰがその送信を開始する前に、ノードを新たなチャネルに調節しなければならない。これに要する時間を、ビーコン送信に利用可能な時間から差し引かなければならない。

トランシーバが新たなチャネル上で静定するために必要とされる時間は、最大で２４μｓにすればよい。割り込みに対する遅延は、最大９μｓであると指定されている。ノード上のチャネル交換は割り込みとして開始されるので、必要とされる合計時間は９＋２４μｓ＋（交換を開始するのに必要とされる計算時間）になると推定することができる。シンボル長を１６μｓとすると、これは最小で２．１シンボルに等しくなる。これを３シンボルに切り上げることは、合理的である。
ＡＰドリフト
第２に、ＡＰが完全に同期されることは想定できないので、１つのシンボルに至るまで、ＡＰ間におけるいくらかのタイミング・ドリフトのために常時余裕がなければならない。タイミング・バッファが適所にあると、２つのＡＰは、何の問題も生ずることなく、バッファのサイズまで、ドリフトして離れることができる。これらがドリフトして更に離れた場合、ノードがチャネルに調整し終える前に、トリガするのが早すぎたＡＰがリスクを誘発し(AP that triggers too early risk triggering)、このため、ノードはビーコンを受信することができず、その後、ＡＰが範囲から外れたまたはオフラインになったと想定するので、ノードはそのチャネル上で送信を行わない。このバッファのサイズは、ＡＰ同期の精度のみに依存し、前もって推定するのは非常に難しいことを意味する。長さ１０のバッファによって、ＡＰが正しいタイミングからいずれの方向にも５シンボル、即ち、８０μｓ逸脱しても許容される。これよりも遙かに正しく同期を行うことができる場合、後の段階において、もっと大きなビーコンに対応する(allow)ために、この値を調節することができる。
解釈
最後に、ノードは、次のビーコンがトリガする前に、そのビーコンの解釈を完了できなければならず、そうでないと、ビーコン・トリガが遅れ、ノードが同期から外れる危険性があり、その結果切断されることになる。この期間の長さは、理論的に推定するのが難しく、最良の方法は、多分、「最悪事態」検査手順を設定し、外れ始める(failing)転換点を発見することである。
オーバーヘッド
一旦無線送信(on air transmission)を含まない部分が差し引かれたなら、実際のオーバーヘッドを評価することができる。表２．３に見られるように、一般的なフレームは１１バイトのオーバーヘッドを有する。ビーコン・ヘッダを追加すると、１２バイト、または２４シンボルとなる。

尚、このオーバーヘッド全てがフレームの前に位置するのではないことを注記しておく。何故なら、これはチェックサムおよび終端部のＦＣＳも含むからである。プログラム自体においてタイミング変数および定数の大きさを決定する(dimensioning)とき、これを考慮に入れなければならない。
最終的なサイズ
表２．８において、各ビーコン周囲のタイミング・オーバーヘッドを、図２．３におけるフェーズにしたがって、要約する。解釈に必要とされる時間は、最初に１０に設定し、後に最適値を求めるために検査するとよい(should)。
チェックサム
破損されたフレームの殆どは大きな破損度を有するのが通例なので、カスタム・チェックサムはエラー訂正能力を有する必要はない。したがって、フレームにおける全てのバイトの単純なＸＯＲを使用する。２バイトのチェックサムでは、最初に、全ての奇数バイト(odd indexed byte)のＸＯＲを取り、次に、全ての偶数バイト(even indexed byte)のＸＯＲを取る。フレームが１バイトのペイロードしか収容していない場合、第２バイトはその初期値、即ち、０を持ち続けているはずである。尚、チェックサムにはＰＨＲは含まれないことを注記しておく。何故なら、このバイトは、フレームが受信されるときには、フレーム・バッファに挿入されないからである。したがって、チェックサムに含まれる第１バイトは、カスタム・フレーム・ヘッダとなる。
同期
アクセス・ポイント間で厳格なタイミング要件を維持するために、全体タイミング基準を導入することができる。この信号の周波数は、ビーコン周波数を超えてはならない。したがって、既存の１３０Ｈｚは使用できない。簡素化のために、同期信号を１Ｈｚにすると定義してもよい。
機能の説明
図８において、通信シーケンスの例を４通り示す。４通りの例８（ａ）、８（ｂ）、８（ｃ）、および８（ｄ）は、ノードに対する送信および受信の図である。

図８（ａ）では、単純な受信を示す。ノードは、チャネル５上でビーコン内においてメッセージを受信し、続く確認応答フェーズにわたってこのチャネルを連続追跡し続け、その確認応答を送信する。

図８（ｂ）では、ノードが送信のためにチャネル１にアクセスしようとして、直ちにアクセスを得る。図示のように、ノードは、その時点ではチャネル１上で送信しているので、チャネル５上でビーコンを受信することができない。ここで問題が発生するのは、チャネル５上で受信したビーコンが、そのノードに宛てられたメッセージを収容する場合、またはブロードキャストの場合だけである。しかしながら、以上で論じたように、このように直接アドレスされたメッセージをノードが失う確率は、十分に小さく、ノードにとっては容認可能な不利(penalty)に過ぎない。図８（ｃ）では、ノードはチャネル１上でそのＣＣＡに失敗し、その時点で、チャネル５はビーコンおよび確認応答フェーズによって遮断される(block)。これに続いて、ノードはランダム・タイムアウト(random timeout)を実行し、後の段階においてその送信を再試行する。図８（ｄ）では、ノードはチャネルの序列(ranking)を変更し、最初にチャネル５上で送信しようとし、これは失敗するが、チャネル１が現在利用可能であるので、直ちにそこで再試行し、成功する。尚、丁度図８（ｂ）におけるように、これは、ノードがチャネル５上でビーコンを逸失する原因となることを注記しておく。

以上、本開示では、具体的な例によって本発明について説明した。本発明の範囲は、添付する特許請求の範囲によって定められるものとする。

Claims (16)

1. ワイヤレス通信ネットワークにおける通信ノード（３００）の動作方法であって、前記ノード（３００）が、少なくとも１つのアクセス・ポイント（１４０）を経由して中央通信ユニット（１５０）と通信し、前記動作方法が、
   −前記ノード（３００）において、前記アクセス・ポイント（１４０）からのワイヤレス信号を受信するステップ（４２０）と、
   −前記ノードによって、前記受信したワイヤレス信号に基づいてチャネル品質情報を判定するステップ（４３０）と、
   −前記ノードによって、前記判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定するステップ（４４０）と、
   −前記ノードによって、前記決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択するステップ（４５０）と、
   −前記ノードによって、前記選択したアクティブ・チャネル上でワイヤレス信号を送信するステップ（４６０）と、
   を含む、方法。
2. 請求項１記載の方法において、
   前記ワイヤレス通信ネットワークが、ビーコン対応搬送波感知多重アクセスに基づくネットワークである、方法。
3. 請求項２記載の方法において、
   前記ノードによって、前記選択したアクティブ・チャネル上でワイヤレス信号を送信するステップ（４６０）が、搬送波感知多重アクセス／衝突回避を使用してメッセージを送信するステップを含む、方法。
4. 請求項１〜３のいずれか１項記載の方法であって、更に、
   前記ノード（３００）によって、前記アクセス・ポイントからのビーコン・データの受信によって提供されるビーコン・タイミング情報を連続追跡するステップを含む、方法。
5. 請求項４項記載の方法であって、更に、
   前記ノード（３００）によって、タイムスロット・パターンにしたがって、前記チャネル全体を繰り返すステップを含む、方法。
6. 請求項１〜５のいずれか１項記載の方法であって、更に、
   前記アクセス・ポイント（１４０）がワイヤレス・ビーコン・データを前記ノード（３００）に送信するビーコン送信モード、または前記アクセス・ポイント（１４０）が前記ノード（３００）から受信したデータを前記中央通信ユニット（１５０）に中継する待ち受けモードで、前記アクセス・ポイント（１４０）を動作させるステップを含む、方法。
7. 請求項６記載の方法において、
   前記ノード（３００）および前記アクセス・ポイント（１４０）が、共通クロック信号によって同期される、方法。
8. ワイヤレス通信ネットワークにおいて動作する通信ノード（３００）であって、前記ネットワークが、前記ノード（３００）と、中央通信ユニット（１５０）と、少なくとも１つのアクセス・ポイント（１４０）とを含み、前記ノード（３００）が、
   −前記アクセス・ポイント（１４０）からのワイヤレス信号を受信し（４２０）、
   −前記受信したワイヤレス信号に基づいてチャネル品質情報を判定し（４３０）、
   −前記判定したチャネル品質にしたがって序列されたアクティブ・チャネルの順序を決定し（４４０）、
   −前記決定した順序にしたがって、ワイヤレス信号を送信するためのアクティブ・チャネルを選択し（４５０）、
   −前記ノードによって、前記選択したアクティブ・チャネル上でワイヤレス信号を送信する、
   ように構成される、通信ノード（３００）。
9. 請求項８記載のノード（３００）において、前記ワイヤレス通信ネットワークが、ビーコン対応搬送波感知多重アクセスに基づくネットワークである、ノード（３００）。
10. 請求項９記載のノード（３００）であって、更に、前記選択したアクティブ・チャネル上でワイヤレス信号を送信するステップ（４６０）において、搬送波感知多重アクセス／衝突回避を使用してメッセージを送信するように構成される、ノード（３００）。
11. 請求項８〜１０のいずれか１項記載のノード（３００）であって、更に、前記アクセス・ポイント（１４０）からのビーコン・データの受信によって提供されるビーコン・タイミング情報を連続追跡するように構成される、ノード（３００）。
12. 請求項１１記載のノード（３００）であって、更に、タイムスロット・パターンにしたがって、前記チャネル全体を繰り返すように構成される、ノード（３００）。
13. 請求項７〜１２のいずれか１項記載のノード（３００）において、前記アクセス・ポイント（１４０）がワイヤレス・ビーコン・データを前記ノードに送信するように構成されるビーコン送信モード、または前記アクセス・ポイント（１４０）が前記ノードから受信したデータを前記中央通信ユニット（１５０）に中継する待ち受けモードで、前記アクセス・ポイント（１４０）が動作するように構成される、ノード（３００）。
14. 請求項１３記載のノード（３００）において、
    前記ノード（３００）および前記アクセス・ポイント（１４０）が、共通クロック信号によって同期される、ノード（３００）。
15. ワイヤレス通信システムであって、
    中央通信ユニット（１５０）と、少なくとも１つのアクセス・ポイント（１４０）と、請求項８〜１４のいずれか１項記載の少なくとも１つの通信ノード（３００）とを含む、ワイヤレス通信システム。
16. 格納システム（１００）であって
    −垂直スタックに積層された複数の収納庫を収容する三次元格納グリッド構造（１１０）と、
    −前記グリッド構造（１１０）上の支持レール（１２０）と、
    −前記グリッド構造（１１０）上の前記レール（１２０）に沿って移動するように構成された複数の車両（１３０）であって、各車両（１３０）が少なくとも１つのアクセス・ポイント（１４０）を経由して中央通信ユニット（１５０）と通信するように構成される、複数の車両（１３０）と、
    を含み、
    各車両（１３０）が、請求項８〜１４のいずれか１項記載の通信ノード（３００）を含む、格納システム（１００）。