JP2010539773A - 通信ネットワークにおけるチャンネル切り替え - Google Patents

Abstract

【課題】
【解決手段】 通信ネットワーク内のチャンネルを変更する方法が提供される。前記ネットワーク内の第１のデバイスおよび第２のデバイス上の第１のチャンネル上にトラフィック流れがある。前記方法は、情報要素を形成する工程であって、前記情報要素は、前記第１のデバイスからのチャンネル変更リクエストを含む、工程と、前記情報要素をビーコンフレームに入れて前記第１のデバイスから前記第２のデバイスへと送信する工程とを含む。
【選択図】図５

Description

本発明は、ネットワークにおけるチャンネル切り替えに関し、詳細には、超広帯域ネットワークにおけるチャンネル切り替えのための方法および装置に関する。

超広帯域は、極めて広い周波数範囲である３．１〜１０．６ＧＨｚにわたってデジタルデータを送信する無線技術である。大きな帯域にわたってＲＦエネルギー分散すると、従来のＲＦ技術では、送信された信号を検出することは実質的に不可能である。しかし、送信電力が低い場合、通信距離は典型的には１０〜１５メートルに制限されることが多い。

ＵＷＢについては、時間領域アプローチおよび周波数領域変調アプローチの２つのアプローチがある。時間領域アプローチでは、ＵＷＢ特性を有するパルス波形から信号を構築し、周波数領域変調アプローチでは、複数の（周波数）帯域にわたって従来のＦＦＴベースの直交周波数分割多重（ＯＦＤＭ）を用いて、ＭＢ−ＯＦＤＭを得る。どちらのＵＷＢアプローチの場合も、周波数スペクトル中の極めて広い帯域を網羅するスペクトル成分が発生する（そのため、超広帯域という用語が用いられる）、そのため、この帯域は、中央周波数（典型的には少なくとも５００ＭＨｚ）の２０パーセントを占領する。

これらの超広帯域特性が極めて広い帯域と組み合わさると、ＵＷＢは、自宅またはオフィス環境において高速無線通信を提供し、これにより通信デバイスを相互に１０〜１５ｍの範囲にするための理想的技術となる。

図１は、超広帯域通信のためのマルチバンド直交周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数帯域の配置構成を示す。このＭＢ−ＯＦＤＭシステムは、それぞれ５２８ＭＨｚの１４個のサブバンドを含み、アクセス方法として、サブバンド間で３１２．５ｎｓ毎に周波数ホッピングを用いている。各サブバンド内において、ＯＦＤＭおよびＱＰＳＫまたはＤＣＭコーディングがデータ送信に用いられる。およそ５ＧＨｚのサブバンド（現在では５．１〜５．８ＧＨｚ）は、既存の狭帯域システム（例えば、８０２．１１ａＷＬＡＮシステム、秘密保全通信システムまたは航空産業）との干渉を回避するために、ブランクのまま残される点に留意されたい。

これらの１４個のサブバンドは５個の帯域群に分類され、そのうち４個は３つの５２８ＭＨｚサブバンドを有し、１つの帯域群は２つの５２８ＭＨｚのサブバンドを有する。図１に示すように、第１の帯域群は、サブバンド１、サブバンド２およびサブバンド３を含む。一例としてのＵＷＢシステムは、帯域群のサブバンド間において周波数ホッピングを用い、これにより、第１のデータシンボルが帯域群の第１の周波数サブバンド内の第１の３１２．５ｎｓの継続時間間隔で送信され、第２のデータシンボルが帯域群の第２の周波数サブバンド内の第２の３１２．５ｎｓの継続時間間隔で送信され、第３のデータシンボルが前記帯域群の第３の周波数サブバンド内の第３の３１２．５ｎｓの継続時間間隔で送信される。そのため、各時間間隔において、データシンボルは、帯域が５２８ＭＨｚである各サブバンド（例えば、３９６０ＭＨｚにおいて中心を持つ５２８ＭＨｚのベース帯域信号を有するサブバンド２）において、送信される。

各データシンボルを送信するための３つの周波数のシーケンスは、時間周波数コード（ＴＦＣ）チャンネルを表す。第１のＴＦＣチャンネルは、シーケンス１、２、３、１、２および３に追随することができ、ここで、１は第１のサブバンドでり、２は第２のサブバンドであり、３は第３のサブバンドである。第２のＴＦＣチャンネルおよび第３のＴＦＣチャンネルは、シーケンス１、３、２、１、３、２および１、１、２、２、３、３をそれぞれ追随することができる。ＥＣＭＡ−３６８仕様に従って、第１の４つの帯域群それぞれに対して７個のＴＦＣチャンネルが規定され、そのうち２つのＴＦＣチャンネルは第５の帯域群に対して規定される。前記５個の帯域群内のＴＦＣチャンネルそれぞれに対するシーケンスを図２（ａ）〜図２（ｅ）中に示す。

超広帯域の技術的特性とは、データ通信分野における適用のために超広帯域が展開されていることを意味する。例えば、以下の環境におけるケーブル交換に着目した多様な適用が存在する：
−ＰＣと周辺機器（すなわち、外部デバイス（例えば、ハードディスクドライブ、ＣＤライター、プリンタ、スキャナ）との間の通信。
−家庭用娯楽機器（例えば、無線手段、無線スピーカーなどによって接続されるテレビおよびデバイス）。
−ハンドヘルドデバイスおよびＰＣ（例えば、携帯電話およびＰＤＡ、デジタルカメラおよびＭＰ３プレーヤ）間の通信。

ＵＷＢネットワークなどの無線ネットワークにおいて、１つ以上のデバイスが、ビーコン期間内において、ビーコンフレームを定期的に送信する。前記ビーコンフレームの主な目的は、媒体上のタイミング構造を提供すること（すなわち、いわゆるスーパーフレームへの時間の分割）と、ネットワークのデバイスをその隣接デバイスと同期させることとである。

ＵＷＢシステムの基本的タイミング構造は、図３に示すようなスーパーフレームである。欧州コンピュータ製造業者連合基準（Ｅｕｒｏｐｅａｎ Ｃｏｍｐｕｔｅｒ Ｍａｎｕｆａｃｔｕｒｅｒｓ Ａｓｓｏｃｉａｔｉｏｎ 基準）（ＥＣＭＡ）、（ＥＣＭＡ−３６８、第二版）に従ったスーパーフレームは２５６個のメディアアクセススロット（ＭＡＳ）からなり、各ＭＡＳは規定継続時間（例えば、２５６μｓ）を有する。各スーパーフレームはビーコン期間と共に開始する。このビーコン期間は、１つ以上の隣接するＭＡＳの間継続し、これらのＭＡＳの間、デバイスはそのビーコンフレームを送信することができる。前記ビーコン期間内における第１のＭＡＳの開始は、ビーコン期間開始時間（ＢＰＳＴ）として知られる。特定のデバイスに対するビーコン群は、前記特定のデバイスとの共有ビーコン期間開始時間（＋−１μｓ）を有するデバイスの群として定義され、これらのデバイスは、前記特定のデバイスの送信範囲内にある。

ＥＣＭＡ−３６８において、通信デバイスからのデータ送信は、単一の割り当てられた時間周波数コード（ＴＦＣ）チャンネルにわたって、メディアアクセススロット（ＭＡＳ）の明示的群内において、搬送される。デバイスと、使用されるべきＭＡＳとの間のマッピング（すなわち、どのデバイス対がこれからどのどのメディアアクセススロット（単数または複数）において通信するのかという表示）は、ビーコン期間内における各スーパーフレーム開始時において各デバイスによって通信される。デバイスは、予約されていないＭＡＳにおいてデータを交換することもできる（ただし、前記ＭＡＳが予約されているハードＤＲＰではないか、あるいは、ハードＤＲＰまたは予約されていたプライベートＭＡＳが放棄された場合）。

現在のＥＣＭＡ−３６８基準によれば、個々のデバイスは、適切なＴＦＣチャンネルに参加し、これにより、命令を受けるかまたは他の決断を行うまで、この単一のチャンネル上で送信／受信を行う。デバイス（単数または複数）によって用いられるＴＦＣチャンネルを変更する場合、当該変更はより高層によって管理され、現在の前記現在のスーパーフレームを完了する必要がある。

超広帯域ネットワーク内のデバイスがチャンネルの変更を決定する場合としては、リンク品質が低くかつ／または低下している場合、チャンネル占有度が高くかつ／または増加している場合、現在のチャンネルがその通信要求を満たしておらずかつ当該デバイスの使用チャンネルの変更によって当該問題を解消できる場合、がある。

しかし、当該デバイスに付随する通信流れ（すなわち、当該デバイスにおいて終結するかまたは当該デバイスから開始する通信流れ）が妨害される。

既存のＥＣＭＡ−３６８基準は、デバイスがチャンネルを切り換えようとする時を（現在のスーパーフレームの後のスーパーフレームの数によって）通知する能力を前記デバイスに付与するが、この通知は、当該デバイスの隣接デバイス（すなわち、当該デバイスが直接通信するデバイス）のみに対してであり、チャンネル変更カウントダウン（ＣＣＣ）の値（これは、当該チャンネル切り換えが発生する時を通知するために用いられる）をどのようにして計算すべきかについて詳述するものではない。このチャンネル切り替え動作は、デバイスが、トラフィック流れを異なるチャンネル上に再分配することにより、そのサービス品質（ＱｏＳ）要求を満足することを可能にするためのものである。

加えて、デバイスが情報を送信しようとするかまたは情報を受信しようとする相手先デバイスが当該デバイスの隣接デバイスではない場合（すなわち、当該デバイスが通信している別のデバイスが、当該デバイスから１個よりも多く離れて「ホップ」している場合）、前記基準の場合、当該デバイスがトラフィック流れ接続性を維持しつつチャンネルを変更することを可能にするメカニズムが無い。

従って、チャンネル変更動作完了後にこの種の通信の継続を可能にする方法および装置が必要とされている。

本発明の第１の局面によれば、通信ネットワーク内のチャンネルを変更する方法が提供される。前記ネットワーク内の第１のデバイスおよび第２のデバイス上の第１のチャンネル上にトラフィック流れが存在する。前記方法は、情報要素を形成する工程であって、前記情報要素は、前記第１のデバイスからのチャンネル変更リクエストを含む、工程と、前記情報要素をビーコンフレームに入れて前記第１のデバイスから前記第２のデバイスへと送信する工程とを含む。

本発明の第２の局面によれば、通信ネットワークにおいて用いられる第１のデバイスが提供される。、前記第１のデバイスは、第１のチャンネル上のトラフィック流れを前記ネットワーク内の１つ以上の他のデバイスと共に維持するように適合され、前記第１のデバイスは、情報要素を形成する手段であって、前記情報要素はチャンネル変更リクエストを含む、手段と、前記第１のデバイスからの前記情報要素をビーコンフレームに入れて前記１つ以上の他のデバイスへと送信する手段と、を含む。

ここで、本発明について、例示目的のみのために、以下の図面を参照しながら詳細に説明する。

超広帯域通信のためのマルチバンド直交周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数帯域の配置構成である。 ５個の帯域群それぞれにおけるＴＦＣチャンネルのシーケンス定義を示す。 ＵＷＢシステム内におけるスーパーフレームの基本的タイミング構造を示す。 本発明による例示的ネットワークを示す。 本発明の一実施形態によるチャンネル変更用占有度情報要素（ＣＣＯＩＥ）の構造を示す。 本発明の一局面によるチャンネル切り替え推進デバイスによって実施される工程を示すフローチャートである。 図６の方法の工程をより詳細に示す。 前記チャンネル切り替え推進によって行われるかまたはビーコンフレームがＣＣＯＩＥ要素と共に受信されるのに応答して行われる工程を示すフローチャートである。 ビーコンフレームがＣＣＯＩＥと共に受信された後にリレーデバイスによって行われる工程を示すフローチャートである。 チャンネル切り替え推進器からＣＣＯＩＥを受信した後に、リレーデバイスがビーコンフレームを送信する際に行う工程を示すフローチャートである。 ビーコンフレームをＣＣＯＩＥと共に受信した後、接続先デバイスが行う工程を示すフローチャートである。 図１１の方法をより詳細に示すフローチャートである。 チャンネルを切り替えるか否かを決定する際にチャンネル切り替え推進器によって行われる方法における工程を示すフローチャートである。 チャンネル切り替えを実現する決定後にチャンネル切り替え推進によって行われる工程を示す。

ここで本発明について超広帯域ネットワークを参照しながら説明するが、本発明は、デバイス間の通信において「ホップ」が１つよりも多く行われ得る他の任意の種類のピアツーピアネットワークにも適用可能であることが理解される。

図４は、本発明による例示的ネットワーク２を示す。ネットワーク２は、７つのデバイス４（Ａ〜Ｇを付して区別する）を含む。これらのデバイスは、超広帯域を用いた通信が可能な任意の適切なデバイス（例えば、携帯電話、ラップトップ、ＰＤＡ）であり得る。

デバイス４間の線６はデバイス４間の物理的通信リンクを示し、矢印８は流れを示す。１つの流れは、単一または複数の「ホップ」をトラバースし得る一対のデバイス４間の接続として定義される。よって、デバイスＡはデータ流れをデバイスＢを介してデバイスＣへと送信しているところであり、この場合は「ホップ」は２回であり、第１の「ホップ」はデバイスＡからデバイスＢへ、第２の「ホップ」はデバイスＢからデバイスＣへと行われる。任意のデバイス４は、自身に付随する入来流れおよび／または送出流れを持ち得る。例えば、デバイスＣは４つの付随流れ（すなわち、デバイスＡからデバイスＣ、デバイスＢからデバイスＣ（どちらも入来流れ）、デバイスＣからデバイスＥおよびデバイスＣからデバイスＦ（どちらも送出流れ））を有する。

「接続先デバイス」とは、特定のデバイスに対して任意の付随流れを介して接続された１組のデバイスを示す。例えば、デバイスＣの接続先デバイスはデバイスＡ、Ｂ、ＥおよびＦであり、デバイスＦの接続先デバイスはデバイスＣおよびＧである。

「チャンネル切り替え推進器」とは、チャンネル切り替えプロシージャをトリガするデバイスである。図４に示す例では、デバイスＣがチャンネル切り替え推進器となる。

トラフィック流れにおいて中間位置にいるデバイスを「リレー」デバイスと呼ぶ。二種類のリレーデバイスがあり、そのうち１種類はリレーとしてのみ機能するリレーデバイスであり、これらのデバイスの場合、これらのデバイスにおいて終結するかまたは開始する流れは無い（例えば、図４中のデバイスＤ）、もう一種類は、リレーとして機能するが他の接続先デバイスも有するリレーデバイスである（例えば、図４中のデバイスＢ）。後者のデバイスは、その独立した流れに加えてトラフィックをリレーする能力に起因して、リレーとして分類される。

以下の記載において、チャンネル切り替えの通知および調整をどのようにしてチャンネル切り替え推進器によって行うのかについて、説明する。しかし、以下の説明においては、チャンネル切り替え動作を開始するために満たさなければならない条件または基準、あるいは、デバイスが切り替え先とする実際のチャンネルを選択する方法については、説明しない。これらのプロシージャは、任意の適切な様式（ＥＣＭＡ−３６８基準中に記載のものを含む）において実施可能であることが、理解される。

本発明の一局面によれば、チャンネル切り替えプロシージャがトリガまたは推進されると、チャンネル切り替え推進器は、チャンネルを切り替えたいという自身の意図を、その接続先デバイス全てに対してビーコンフレームを通じて通信する。このプロシージャは、２つのフェーズを含む。第１のフェーズは、チャンネル切り替えの通知であり、第２のフェーズは、チャンネル切り替えそのものの実現である。各デバイスの動作は、送信ビーコンサブフェーズおよび受信ビーコンサブフェーズの２つのサブフェーズにさらに分割することができる。

チャンネル切り替え推進器によって取られる工程を高レベルに見ると、以下のようになる。すなわち、チャンネル切り替えプロシージャがトリガされると、チャンネル切り替え推進器は、自身のビーコンフレーム内にチャンネル切り替え情報を含める。好適には、超広帯域ネットワークにおいて、このチャンネル切り替え情報は、前記ビーコンフレームのチャンネル変更用占有度情報要素（ＣＣＯＩＥ）内に含まれる。チャンネル変更用占有度情報要素（ＣＣＯＩＥ）について、以下にさらに説明する。チャンネル切り替え情報は好適には、カウントダウン要素を含む。このカウントダウン要素は、ネットワーク内において（ホップ数において）最も遠隔位置にあるデバイスまでチャンネル切り替え通知を伝搬させることが可能であり、かつ、応答を前記チャンネル切り替え推進器まで返送させることを可能にする値に、設定される。好適には、このカウントダウンは、前記ＣＣＯＩＥ内のチャンネル変更カウントダウン（ＣＣＣ）要素の形態をとる。加えて、チャンネル切り替え推進器は好適には、前記ビーコンフレーム中に接続先デバイスのリストも含み、これにより、適切なデバイスが、適切なデバイスがチャンネルを切り換えようとしていることを知る。

超広帯域ネットワークを参照した本発明の説明を容易にするため、チャンネル変更用占有度情報要素（ＣＣＯＩＥ）構造について、図５を参照して説明する。しかし、他の種類のネットワークに対して本発明を実施する場合、チャンネル切り換えを通知および実施するために、別の情報構造も使用することができることが、理解される。

チャンネル変更用占有度情報要素（ＣＣＯＩＥ）構造は、ＣＣＯＩＥの要素ＩＤを示す第１のオクテットと、前記ＣＣＯＩＥの長さ（前記長さは２＋Ｋ＋２Ｎに等しい）を示す第２のオクテットと、チャンネル変更カウントダウン（ＣＣＣ）要素の値（これは、後続チャンネルＩＤフィールド内において規定された新規チャンネルにデバイスが移動するまでの残りのスーパーフレームの数を示す）を示す第３のオクテットと、前記デバイスが切り替え先としているチャンネルの識別情報を示す第４のオクテットと、各接続先およびリレーデバイスのチャンネル変更通知状態（ＣＣインフォビットマップ）を示すＫオクテットの２ビット要素と、最後に、これらのデバイスのアドレスを示す、接続先およびリレーデバイス毎の２つのオクテットと、を含む。

前記チャンネル変更情報マップ中の２ビット要素の値は、チャンネル切り替えリクエストが送られた後の特定の接続先またはリレーデバイスの状態を示す。一実施形態において、００という値は、当該デバイスがチャンネル切り替えリクエストを拒絶したことを示す。０１という値は、当該デバイスがチャンネル切り替えリクエストに対して未だ応答していない（すなわち、このリクエストは未決になっている）ことを示す。１０という値は、当該デバイスがチャンネル切り替えリクエストに対して応答してはいるが、延長を要請している（すなわち、前記リクエストは未決かつ延長状態にある）ことを示す。１１という値は、当該デバイスがチャンネル切り替えリクエストを受信したことを示す。

図６は、本発明の一局面による、チャンネル切り替え推進器がチャンネル切り替えを通知する方法における工程を示すフローチャートである。工程１０１において、前記チャンネル切り替え推進器は、任意の適切な方法に従ってチャンネルを目的地チャンネル（ＤＣｈ）に切り替えることを決定または決断する。これにより、チャンネル切り替え通知プロシージャが開始する。チャンネル切り替え推進器に接続されているデバイスまたはチャンネル切り替え推進器のためのリレーデバイスは既知である。

工程１０３〜工程１１１は、チャンネル切り替え推進器が適切なＣＣＯＩＥを生成するために必要な動作を示す。これらの工程は前記した順序で行わなくてもよいことが、理解される。

工程１０３において、チャンネル切り替え推進器からの接続先デバイスの最大ホップ距離Ｈ_Ｍを決定する。この情報は、ルーティング層によって提供される。このルーティング層は、ＭＡＣプロトコル上方の層である。

工程１０５において、チャンネル切り替え推進器は、チャンネル変更用占有度情報要素（ＣＣＯＩＥ）を生成し、好適にはチャンネル変更カウントダウン（ＣＣＣ）オクテットを２＊Ｈ_Ｍ＋１の値に設定し、チャンネルＩＤオクテットＤ_Ｃｈに設定する。このＣＣＣの値が選択されるのは、ＣＣＣは、最も遠隔位置にある接続先デバイスそれぞれに到達するためのホップ数と、同一数のホップバック数と、１とを合計した値だからである。なぜならば、前記ＣＣＯＩＥは、次のスーパーフレームに入れられて送信されるからである。

工程１０７において、チャンネル切り替え推進器は、接続先およびリレーデバイスそれぞれについてそのメモリ内にエントリを生成して、前記チャンネル切り替えリクエストに対する応答が未決であることを示す（すなわち、前記エントリは、ＣＣインフォビットマップ中の未決リクエストを示すために用いられる値に対応する０１となり得る）。

工程１０９において、チャンネル切り替え推進器は、自身のアドレスを記ＣＣインフォビットマップ内における対応する状態である１１と共に前記ＣＣＯＩＥに付加し、これにより、チャンネル切り替え推進器が前記チャンネル切り替えリクエストを受け入れたことを示す。

工程１１１において、チャンネル切り替え推進器は、前記接続先およびリレーデバイスのアドレスを前記ＣＣＯＩＥに付加し、前記ＣＣインフォビットマップ内における前記接続先およびリレーデバイスの状態を０１として示し、これにより、前記チャンネル切り替えリクエストが未決であることを示す。

工程１１３において、前記チャンネル切り替え推進器は、前記生成されたＣＣＯＩＥをそのビーコンフレーム内で送信し、このビーコンフレームは、スーパーフレーム開始時においてビーコン期間内に送信される。

従って、前記生成されたＣＣＯＩＥにより、前記チャンネル切り替え推進器は、複数のホップにわたる切り替えを協調させることができる。なぜならば、これらのデバイスは、前記ＣＣＯＩＥ内のリストに記載されており、ＣＣＣフィールドを用いてチャンネル切り替えのタイミングを調整することができるからである。

図７は、図６の工程１１３をより詳細に示す。図６の工程１１１後、前記ＣＣＯＩＥ内のＣＣＣの値を１だけ低減させ（工程１２１）、前記ＣＣＯＩＥ（これは、ＣＣインフォビットマップに対して変更が有る場合、当該変更と共に適宜更新される）を、前記チャンネル切り替え推進器の次のビーコンフレーム内において送信する（工程１２３）。ＣＣＣが０に等しい場合（工程１２５）、前記プロシージャはＡに移動し、前記チャンネル切り替え通知プロシージャは完了する。ＣＣＣが０に等しくない場合、前記方法は工程１２１に戻って、ＣＣＣを１だけ低減させ、前記ＣＣＯＩＥ（これは、ＣＣインフォビットマップに対して変更が有る場合、当該変更と共に適宜更新される）を、次のスーパーフレームのビーコン期間において、前記チャンネル切り替え推進器のビーコンフレーム内において送信する。

ビーコンフレームをＣＣＯＩＥと共に受信したデバイスは、リレーデバイスでも接続先デバイスでもないチャンネル切り替え推進器の範囲内において、リレーデバイス、接続先デバイスまたは他のデバイスであり得る。リレーデバイスでも接続先デバイスでもないデバイスの場合、前記デバイスは、ＣＣＯＩＥを無視するか、または、ＥＣＭＡ基準に従って行動する。あるいは、前記ＣＣＯＩＥを使用およびより高位の層へと伝播させて、各デバイスの隣接表を更新してもよい（換言すれば、前記ルーティング層は、前記ＣＣＯＩＥを用いて、前記デバイスが所与の時間においてチャンネル上に存在するデバイスを知ることを可能にすることができる）。

リレーデバイスの場合、図１０に示す方法に従って前記リレーデバイスから他のリレーデバイスまたは接続先デバイスへの後続ビーコンフレームの送信が行われている間、受信されたビーコンフレームは、以下の図９に示す方法に従って処理される。リレーデバイスがビーコンフレームをＣＣＯＩＥと共に受信した場合、前記リレーデバイスは、前記ＣＣＯＩＥを、自身のビーコンフレーム（これは、図７中の方法に従って１だけ減少されたＣＣＣを有する）内に複製する。各後続のスーパーフレームの間、ＣＣＣ値が０になるまで、各伝播したＣＣＯＩＥのＣＣＣフィールドの値は１だけ減少される。

接続先デバイスは、受信したＣＣＯＩＥを有するビーコンフレームを、以下の図１１中に示す方法に従って処理する。接続先デバイスは、自身がこのようなデバイスとして分類されていることを認識している。なぜならば、前記接続先デバイスは、前記ＣＣＯＩＥ中の接続先デバイスの１つとしてリスト記載されており、また、この情報もルーティング層内に保存されているからである。この段階において、接続先デバイスは、各接続先デバイス（これらの各接続先デバイスは、前記チャンネル切り替え推進器の接続先デバイスではないため、前記ＣＣＯＩＥの接続先デバイスリスト内に記載されていない）を有するデバイスと、各接続先デバイスを有さない接続先デバイスとに、さらに分割される。

前者の場合、前記接続先デバイスは、前記ＣＣＣを適切に延長して、これにより、チャンネルを自身の接続先デバイスに切り替えて、チャンネルからの応答が戻るまでの時間を可能にするという意志を伝搬させることを可能にする。従って、前記デバイスがチャンネル切り替え推進器に応答すると、前記デバイスは、自身の状態を「未決延長状態」として示す。接続先デバイスが各接続先デバイスを全く持っていない場合、前記接続先デバイスは、前記チャンネル切り替えリクエストを受け入れるかまたは拒絶して、チャンネル切り替え推進器に対する応答内に示すことができる（以下の図１２を参照）。

このプロシージャは、全てのデバイスが状態フィールド受入／拒絶に応答するまでか、または、前記ＣＣＯＩＥ内のスペース（これは、ビーコン期間内に送信されるＩＥ数に依存する）が足りなくなるまで、継続される。後者の場合、前記デバイスは、チャンネルを変更するか否かについて決断するための意志決定プロシージャに従わなくてはならない。

上述したように、前記チャンネル切り替え通知プロシージャが終了するのは、前記推進器のＣＣＯＩＥのＣＣＣがゼロになった場合か、あるいは、全ての接続先デバイスがチャンネル切り替え受け入れまたはチャンネル切り替え拒絶と共に前記推進器に対して応答した場合である。この時点において、チャンネル切り替え推進器は、チャンネル切り替えを実施するか否かについて決断する。図１３は、チャンネルを切り替えるか否かについて決断するためのプロシージャを示す。

上記したように、図８は、ビーコンフレームをＣＣＯＩＥ要素ともに受信したのに応答してチャンネル切り替え推進器が行う方法を示す。工程１３１において、ビーコンフレームがＣＣＯＩＥと共に受信される。工程１３３において、チャンネル切り替え推進器は、前記ＣＣＯＩＥのＣＣインフォビットマップ内に含まれる情報に応答して、そのメモリ内に保存されている接続先デバイスの状態を更新する。工程１３５において、前記受信されたＣＣＯＩＥ内のＣＣＣフィールドの値がチャンネル切り替え推進器によって維持されている値よりも高いか否かについて、決定する。前記受信されたＣＣＣの値が前記チャンネル切り替え推進器が維持している値よりも高い場合、前記チャンネル切り替え推進器が維持している値を前記受信された値に更新する（工程１３７）か、または、前記チャンネル切り替え推進器が維持しているＣＣＣ値を変更しないでおく。

チャンネル切り替え推進器は、別の推進器デバイスからの異なるチャンネル切り替えリクエストに関連するＣＣＯＩＥを受信することが可能であることが理解される。しかし、一度に進めることができるのは１つのチャンネル切り替えリクエストだけであり、そのため、この場合、後者のチャンネル切り替え推進器は、自身のチャンネル切り替えリクエストをキャンセルする。

図９は、ビーコンフレームがＣＣＯＩＥと共に受信された後に、リレーデバイスによって行われる方法を示す。工程１４１において、ビーコンフレームがＣＣＯＩＥと共にリレーデバイスによって受信される。前記ビーコンフレームは、チャンネル切り替え推進器からかまたは別の中間リレーデバイスから受信され得る。工程１４３において、ビーコンフレームがＣＣＯＩＥと共にが同じチャンネル切り替え推進器から以前に受信されているか否か決定される。ＣＣＯＩＥが以前に受信されている場合、前記方法は工程１４５へと進み、工程１４５において、チャンネル切り替えリクエストに応答する必要のあるデバイスがまだ有るか否かまたはＣＣＣフィールドの値が最後の既知の値よりも高いか否かについて、決定する。これらのうちのいずれかに対する回答が「はい」である場合、前記方法は終了する。

工程１４３または工程１４５のいずれかに対する回答が「いいえ」である場合、前記方法は工程１４７へと進み、前記リレーデバイスが接続先デバイスを有するか否かについて決定する。

前記リレーデバイスが接続先デバイスを有する場合、前記方法は工程１４９へと進み、ＣＣＯＩＥ内においてチャンネル切り替え推進器の接続先デバイスとしてリスト中のデバイスを通過する流れを前記リレーデバイスが有するか否かについて、決定する。すなわち、前記リレーデバイスは、任意の接続先デバイスが、前記リレーデバイスから発生するかまたは前記リレーデバイスにおいて終結する流れに対するリレーデバイスでもあるか否かを確認する。前記リレーデバイスは、前記ルーティング層に接触することによってこれを行うが、これは、前記リレーデバイス自身のトラフィック流れが前記受信されたＣＣＯＩＥ内のリストに記載されているデバイスを通過する場合のみに、行われる。そうではない場合、前記リレーデバイスは、チャンネル切り替えに関与しない。

前記リレーデバイスが、前記受信されたＣＣＯＩＥ内にリスト記載されたデバイス（単数または複数）を通過するトラフィック流れを実際に有する場合、前記方法は工程１５１へと進み、ルーティングエージェントに接触して、影響を受ける流れについて新規または別の経路を発見する。

工程１４７または工程１４９のいずれかにおける決定に対する答えが「いいえ」である場合、または、工程１５１を行った後、前記方法は工程１５３へと進み、前記リレーデバイスは、ＣＣＯＩＥを生成するかまたは前記受信されたＣＣＯＩＥを新規ＣＣＣ値（これは、図７中に示す方法に従って決定される）と共に更新する。その後、前記方法は終了する。

図１０は、チャンネル切り替え推進器からＣＣＯＩＥを受信した後にリレーデバイスがビーコンフレームを送信する際に行われる方法を示す。工程１６１において、前記リレーデバイスが自身のビーコンフレーム内に含まれるべきＣＣＯＩＥを持つか否かを決定する。含まれるべきＣＣＯＩＥが無い場合、工程１６２において前記ビーコンフレームを送信する。含まれるべきＣＣＯＩＥが有る場合、ＣＣＯＩＥを前記リレーデバイスのビーコンフレームの適切な位置にコピーする（工程１６３）。

工程１６３後、前記方法は工程１６５に進み、前記ビーコンフレームを送信する。

工程１６５後、前記デバイスは、次のスーパーフレーム内のビーコンフレームの送信の準備をする。具体的には、前記方法は工程１６７へと進み、前記ＣＣＯＩＥ内のＣＣＣフィールドの値がＯであるかを決定する。前記ＣＣＣフィールドがＯである場合、前記ＣＣＯｌＥを前記リレーデバイスのメモリから削除する（工程１６９）。前記ＣＣＣフィールドがゼロではない場合、前記リレーデバイスのメモリ内に保存されているＣＣＣ値を１だけ低減させる（工程１７１）。

工程１６９または工程１７１後、前記方法は工程１７３へと進み、前記リレーデバイスは、前記ビーコンフレームの送信の準備をする。

図１１は、ビーコンフレームをＣＣＯＩＥと共に受信した後、接続先デバイス（以下、明確さのため、「第１の接続先デバイス」と呼ぶ）が行う工程を示す。工程１８１において、ビーコンフレームがＣＣＯＩＥと共に受信される。工程１８３において、第１の接続先デバイスの状態が前記ＣＣＯＩＥ内のＣＣインフォビットマップから既に決断されているか（すなわち、前記デバイスの状態が拒絶されているかまたは受け入れられているか？）について決定する。第１の接続先デバイスの状態が決断されている場合、前記方法は工程１８５へと進み、第１の接続先デバイスはビーコンフレームを送信する。

工程１８５は、図６中の工程１１３に対応するため、図７中に示す方法に対応する。

前記第１の接続先デバイスの状態が決断されていない場合、前記方法は工程１８７へと進み、第１の接続先デバイスの状態が「１０」であるか（すなわち、前記リクエストが未決でありかつ延長されているか）について決定する。第１の接続先デバイスは、前記ＣＣＯＩＥの関連部分を調査することによりこれを決定し、前記状態を内部メモリ中に保存する。第１の接続先デバイスの状態が「未決でなくかつ延長されている」（すなわち、前記状態は単に未決である−０１）場合、前記方法は工程１８８へと進み、第１の接続先デバイスが前記デバイスリスト内に記載されている接続先デバイスを有するか否かについて決定する。第１の接続先デバイスが接続先デバイスを有さない場合、前記方法は工程２０１へと進み、チャンネル変更リクエストを受け入れるかまたは拒絶するかを決定する。

第１の接続先デバイスが実際に接続先デバイスを有する場合、前記方法は工程１８９へと進み、第１の接続先デバイスに接続されたデバイスの最大ホップ距離（ＨＭ）を決定する。上記したように、この情報は、ＭＡＣプロトコルの上方の層であるルーティング層によって提供される。

工程１８９後、前記方法は工程１９０へと進み、第１の接続先デバイスは、自身の状態を「１０」に更新して、第１の接続先デバイスが自身の接続先デバイスからの応答を待機していることを示す。その後、前記方法は工程１９１へと進み、第１の接続先デバイスは、第１の接続先デバイスが接続されているデバイスの識別情報を前記ＣＣＯＩＥ中のデバイスリストに付加する（ただし、これらのデバイスがまだ当該リスト中に記載されていない場合）。第１の接続先デバイスに接続されたデバイスはそれぞれ、ＣＣインフォビットマップ内において０１の状態が付与されている（すなわち、これらのデバイスについてのチャンネル切り替えリクエストは未決となっている）。

工程１９３において、第１の接続先デバイスは、第１の接続先デバイスに接続されたデバイスそれぞれについて、対応する状態エントリを内部メモリ内に生成する。工程１９５において、チャンネル変更カウントダウンフィールドの値を、前記受信されたＣＣＯＩＥ中のＣＣＣの値と、２＊Ｈ_Ｍとを合計した値に設定する。その後、前記方法は工程１８５へと進み、第１の接続先デバイスは、前記新規ＣＣＯＩＥを自身のビーコンフレームに入れて送信する。

工程１８７において第１の接続先デバイスの状態が未決として決定されかつ延長「１０」されている場合、前記方法は工程１９７へと進み、前記ＣＣＯＩＥ中の受信されたＣＣインフォビットマップに基づいて、第１の接続先デバイスに接続されたデバイスの内部保管された状態を更新する。工程１９９において、第１の接続先デバイスに接続されたデバイス全てがチャンネル変更リクエストを受け入れるという応答をしたかについて、決定する。

その後、前記方法は工程２０１へと進み、前記デバイスは、工程１９９の出力に基づいて、前記ＣＣＯＩＥ内に含まれるチャンネル切り替えリクエストを受け入れるかまたは拒絶するかについて、決定する。前記受け入れるかまたは拒絶するかについての意志決定工程からの出力の結果、前記第１の接続先デバイスについての状態は、自身のビーコンフレーム内に入れてられて送信されたＣＣＯＩＥ内に含められる（工程１８５）。

図１２は、受入／拒絶についての意志決定の工程２０１をより詳細に示す。工程１９９の出力が「いいえ」である場合（すなわち、接続先デバイス全てが、チャンネル切り替えリクエスト受け入れについて未だ応答していない場合（例えば、１つ以上の「チャンネル切り替えリクエスト拒絶」を受信しておりかつ／またはい（応答が肯定または否定であるかに拘わらず）特定のデバイスからの応答をまだ受信していない場合））、第１の接続先デバイスが前記チャンネル切り替えについていずれにせよ従うつもりなのかについて決定する（工程２０３）。デバイスが前記切り替えに従うかについて決定する際に用いる基準は、ネットワークオペレータが設定することができ、かつ、影響を受けるトラフィック流れおよび／またはチャンネル切り替え推進器に対する前記デバイスの相対的位置に基づいて測定された品質サービスに基づくことができる。

第１の接続先デバイスがいずれにせよ前記切り替えに従うと決断した場合、第１の接続先デバイスは、ＣＣインフォビットマップ内における自身の状態を１１に設定して、自身が前記チャンネル切り替えリクエストを受け入れていることを示す（工程２０５）。第１の接続先デバイスが前記チャンネル切り替えに従わないと決断した場合、第１の接続先デバイスは、前記ＣＣインフォビットマップ内における自身の状態を００に設定して、自身が前記チャンネル切り替えリクエストを拒絶していることを示す（工程２０７）。

工程１９９の出力が「はい」である（すなわち、全ての接続先デバイスがチャンネル切り替えリクエスト受入と共に応答している場合）、前記方法は工程２０５へと進み、第１の接続先デバイスは、ＣＣインフォビットマップ内における自身の状態を１１に設定して、前記チャンネル切り替えリクエストを受け入れていることを示す。

いずれの場合も、前記方法は工程１８５に進んで、前記デバイスの決断を示すビーコンを送信する。

図１３に示すように、前記ＣＣＯＩＥ中のチャンネル変更カウントダウン（ＣＣＣ）が０になった場合、チャンネル切り替え推進器は、チャンネルを切り替えるかについて決定する。この方法はＡから開始し、チャンネル切り替え推進器は、自身の接続先デバイス全てが前記チャンネル切り替えリクエストを受け入れたかについて決定する（工程２１１）。自身の接続先デバイス全てが前記チャンネル切り替えリクエストを受け入れていない場合、前記方法は工程２１３へと進み、チャンネル切り替え推進器は、いずれにせよチャンネル切り替えを実施するかについて決定する。いずれにせよ切り替えをするかについての決定の際に用いられる基準は、ネットワークオペレータまたはデバイス製造業者が所望に設定することができる。

工程２１１または工程２１３の結果が肯定である場合（すなわち、全ての接続先デバイスが前記チャンネル切り替えリクエストを受け入れたかまたはチャンネル切り替え推進器がいずれにせよ前記チャンネル切り替えを実施するつもりである場合）、前記方法は工程２１５へと進み、前記チャンネル切り替えを実現する。

工程２１３においてチャンネル切り替え推進器が前記切り替えを実施しないと決定した場合、前記方法は工程２１７へと進み、前記チャンネル切り替えを中止する。

図１４は、チャンネル切り替え推進器が前記チャンネル切り替えを実現するかについて決断する際にチャンネル切り替え推進器が用いる工程を示す（工程２１５）。チャンネル切り替え推進器は、新規ＣＣＯＩＥを生成する。この新規ＣＣＯＩＥは、チャンネル切り替えに関与する全てのデバイスをこれらのデバイスの適切な切り替え状態と共に含む（工程２２１および工程２２３）。そして、チャンネル切り替え推進器は、ＣＣＣを通知継続時間（これは、通知プロシージャ時に用いられる延長全てを含む）の半分に等しい値に設定する（工程２２５）。工程２２７において、要素ＩＤを設定して、前記ＣＣＯＩＥが暫定的なチャンネル変更リクエストではなく明確なチャンネル変更に関連することを示す。

その後、チャンネル切り替え推進器は、生成されたＣＣＯＩＥを自身のビーコンフレームに入れて送信する（工程２２９（これは、図７中に記載の方法に対応する））。その後、前記ＣＣＯＩＥにおいて示される明確な変更は、トラフィック流れ経路内の全デバイスと、チャンネル切り替えリクエストを受け入れたデバイスとに提供される。

前記ＣＣＯＩＥを前記変更された要素ＩＤと共に受信したデバイスは、前記情報要素を自身のビーコンフレーム内に複製し、その際、前記ＣＣＣフィールドの値を１単位だけ低減させる。

前記ＣＣＣフィールドの値がＯ０になった場合、全ての関連デバイス（すなわち、チャンネル切り替え推進器、任意のリレーデバイスおよび接続先デバイス）は、自身のＲＦインターフェースを前記ＣＣＯＩＥのチャンネルＩＤフィールド中で示されるチャンネルに同調させ（工程２３１）、チャンネル切り替えプロシージャが完了する。

従って、単一のおよび複数の「ホップ」にわたるチャンネル切り替え動作を調整するために、通信ネットワークにおいて用いられる方法が提供される。前記方法は、ＥＣＭＡ３６８基準ＭＡＣに従った超広帯域環境に特に適している。上記したように、デバイス推進前記チャンネル切り替えは、前記プロシージャの調整者として機能し、ビーコンフレーム内に含まれる情報要素を介してチャンネル切り替え活動を調整する。ビーコンフレームを使用することにより、専用のチャンネル切り替え用信号生成機構と比較して、ネットワークが持つオーバーヘットが大幅に低減する。加えて、チャンネル切り替え推進器がチャンネルを切り替えようとしているという意図を通知することにより、最大接続性を維持したまま、ネットワーク妨害（より低レベルのパケット損失および遅延を含む）が最小になる。

重要な点は、提案されている本方法は、チャンネル変更プロセスに予測可能性および制御を導入する点である。なぜならば、チャンネル切り替え推進器および接続先デバイスは、チャンネル変更が発生し得るかまたは発生するであろう時期について知識を持つからである。これは、先行技術のインプレメンテーションでは不可能である。

ネットワークユーザの観点から、チャンネル切り替え動作は、（切り替え先となるチャンネルの選択に関連する決断プロセスと共に）透明であり、余分なリソースは最小限しか必要としない。

上記したアルゴリズムは、前記アルゴリズムをサポートしない従来のデバイスと適合可能であり、このようなデバイスは、本発明によるデバイスの機能性に妥協をきたすことなく、従来の様式で共存およびチャンネル切り替えすることができる。

Claims (34)

1. 通信ネットワーク内のチャンネルを変更する方法であって、前記ネットワーク内の第１のデバイスおよび第２のデバイス上の第１のチャンネル上にトラフィック流れがあり、前記方法は、
   情報要素を形成する工程であって、前記情報要素は、前記第１のデバイスからのチャンネル変更リクエストを含む、工程と、
   前記情報要素をビーコンフレームに入れて前記第１のデバイスから前記第２のデバイスへと送信する工程と、
   を含む、方法。
2. 前記ネットワークは複数対のデバイス間の複数のトラフィック流れを含み、前記情報要素を送信する工程は、前記第１のデバイスからの前記情報要素を前記ネットワーク内のその他のデバイスへと送信する工程を含む、請求項１に記載の方法。
3. 前記方法は、
   前記情報要素を受信した後、前記情報要素を処理して、前記前記第１のデバイスからのチャンネル変更リクエストを受け入れるかまたは拒絶するかについて決定する工程、
   をさらに含む、請求項１または２に記載の方法。
4. 前記情報要素を処理して、前記第１のデバイスからのチャンネル変更リクエストを受け入れるかまたは拒絶するかについて決定する工程の後、前記方法は
   前記受信された情報要素を用いて各情報要素を形成する工程であって、前記各情報要素は、前記デバイスが前記チャンネル変更リクエストを受け入れているかかまたは拒絶しているかを示す状態フィールドを含む、工程と、
   前記各情報要素を後続ビーコンフレームに入れて送信する工程と、
   をさらに含む、請求項３に記載の方法。
5. 前記情報要素をデバイスによって処理する工程は、前記第１のデバイス以外の任意のデバイスを含むトラフィック流れを前記デバイスが有するかについて決定する工程を含む、請求項３または４に記載の方法。
6. 前記デバイスが別のデバイス（単数または複数）を含むトラフィック流れを実際に有する場合、前記受信された情報要素から各情報要素を形成する工程であって、前記各情報要素は、前記第１のデバイスからのチャンネル変更リクエストを含む、工程と、
   前記デバイスからの前記各情報要素を後続ビーコンフレームに入れて送信する工程と、
   をさらに含む、請求項５に記載の方法。
7. 前記受信された情報要素はカウントダウン要素を含み、前記各情報要素を形成する工程は、前記受信された情報要素からの前記カウントダウンコンポーネントを所定量だけ増加させて含める工程を含む、請求項６に記載の方法。
8. 前記受信された情報要素は、トラフィック流れを前記第１のデバイスと共に有するデバイスのリストを含み、前記形成工程は、前記デバイスのリストを前記各情報要素中に含める工程と、前記別のデバイス（単数または複数）を含むように前記リストを更新する工程とを含む、請求項６または７に記載の方法。
9. 前記情報要素中の前記デバイスのリストは、各デバイスについての関連付け状態を含み、前記状態は、前記リスト中のデバイスが前記チャンネル変更リクエストを受け入れているかまたは拒絶しているか、あるいは、前記デバイスによる決断は未だに未決であるかを示す、請求項８に記載の方法。
10. 前記第１のデバイスと第２のデバイスとの間の前記トラフィック流れは、少なくとも１つの第３のデバイスを含み、前記第３のデバイスは、前記第１のデバイスと前記第２のデバイスとの間に配置され、前記トラフィック流れにおける中間リレーデバイスとして機能し、
    前記第３のデバイスが前記情報要素を受信すると、前記第３のデバイスは、前記受信された情報要素から各情報要素を形成し、前記各情報要素は、前記第１のデバイスからのチャンネル変更リクエストを含み、
    前記第３のデバイスからの前記各情報要素を後続ビーコンフレームに入れて前記第２のデバイスへと送信する、
    上記請求項のいずれかに記載の方法。
11. 受信された情報要素はカウントダウン要素を含み、前記各情報要素を形成する工程は、前記受信された情報要素からの前記カウントダウンコンポーネントを１だけ低減させて含める工程を含む、上記請求項のいずれかに記載の方法。
12. 前記受信された情報要素は、トラフィック流れを前記第１のデバイスと共に有するデバイスのリストを含み、前記形成工程は、前記デバイスのリストを前記各情報要素内に含める工程を含む、請求項１０または１１に記載の方法。
13. 前記情報要素内の前記デバイスのリストは、各デバイスについての関連付け状態を含み、前記状態は、前記リスト中のデバイスが前記チャンネル変更リクエストを受け入れているかまたは拒絶しているか、あるいは、前記デバイスによる決断は未だに未決であるかを示す、請求項１２に記載の方法。
14. 前記情報要素は、前記第１のデバイスが切り替え先として切り替えようといている前記チャンネルの情報を示すフィールドを含む、上記請求項のいずれかに記載の方法。
15. 決定された間隔の後、前記第１のデバイスは、前記チャンネル切り替えを行うかについて決断する、上記請求項のいずれかに記載の方法。
16. 情報要素を形成する工程であって、前記情報要素は、前記第１のデバイスからのチャンネル変更命令を含む、工程と、
    前記第１のデバイスからの前記情報要素を前記チャンネル切り替えに関与するその他のデバイスへと送信する工程と、
    をさらに含む、請求項１５に記載の方法。
17. 前記情報要素は、前記チャンネル切り替えに関与するその他のデバイスに関連する切り替え状態情報を含む、請求項１６に記載の方法。
18. 前記情報要素はカウントダウン要素を含み、前記カウントダウン要素は、前記チャンネル切り替えが発生するであろう時期を確認する、請求項１６または１７に記載の方法。
19. 通信ネットワークにおいて用いられる第１のデバイスであって、前記第１のデバイスは、第１のチャンネル上のトラフィック流れを前記ネットワーク内の１つ以上の他のデバイスと共に維持するように適合され、前記第１のデバイスは、
    情報要素を形成する手段であって、前記情報要素はチャンネル変更リクエストを含む、手段と、
    前記第１のデバイスからの前記情報要素をビーコンフレームに入れて前記１つ以上の他のデバイスへと送信する手段と、
    を含む、第１のデバイス。
20. 前記第１のデバイスは手段をさらに含み、前記手段は、推進器デバイスから情報要素を受信するのに応答して、前記情報要素を処理して、前記推進器デバイスからの前記チャンネル変更リクエストを受け入れるかまたは拒絶するかを決定する、請求項１９に記載の第１のデバイス。
21. 前記情報要素を形成する手段は、前記受信された情報要素を用いて情報要素を形成するようにさらに適合され、前記情報要素は状態フィールドを含み、前記状態フィールドは、前記第１のデバイスが前記チャンネル変更リクエストを受け入れているかまたは拒絶しているかを示し、前記送信手段は、前記情報要素を後続ビーコンフレームに入れて送信するようにさらに適合される、請求項２０に記載の第１のデバイス。
22. 前記情報要素を処理する手段は、前記第１のデバイスが前記推進器デバイス以外の任意のデバイスと共にトラフィック流れを有するかを決定するように適合される、請求項２１に記載の第１のデバイス。
23. 前記第１のデバイスがトラフィック流れ（単数または複数）を前記推進器デバイス以外の任意のデバイスと共に有する場合、前記情報要素を形成する手段は、前記受信された情報要素から情報要素を形成するように適合され、前記情報要素は、前記推進器デバイスからの前記チャンネル変更リクエストを含み、前記送信手段は、前記第１のデバイスからの前記各情報要素を後続ビーコンフレームに入れて送信するように適合される、請求項２２２に記載の第１のデバイス。
24. 前記受信された情報要素はカウントダウン要素を含み、前記情報要素を形成する手段は、前記受信された情報要素からの前記カウントダウンコンポーネントを前記形成された情報要素内に含めるようにさらに適合され、前記形成された情報要素は所定量だけ増加される、請求項２３に記載の第１のデバイス。
25. 前記受信された情報要素は、トラフィック流れを前記推進器デバイスと共に有するデバイスのリストを含み、前記情報要素を形成する手段は、前記情報要素中の前記デバイスのリストを含み、かつ、前記第１のデバイスがトラフィック流れ（単数または複数）と共に有する任意のデバイスを前記リスト内に含めるように前記リストを更新するように適合される、請求項２３または２４に記載の第１のデバイス。
26. 前記情報要素内の前記デバイスのリストは、前記リスト中の各デバイスと関連付けられた状態を含み、前記状態は、前記リスト中のデバイスが前記チャンネル変更リクエストを受け入れているかまたは拒絶しているか、あるいは、前記デバイスによる決断が未だ未決であるかを示す、請求項２５に記載の第１のデバイス。
27. 前記第１のデバイスは、前記推進器デバイスと第２のデバイスとの間のトラフィック流れのためのリレーデバイスであり、
    前記推進器デバイスからの前記情報要素を受信すると、前記情報要素を形成する手段は、前記受信された情報要素からの情報要素を形成するように適合され、前記情報要素は、前記推進器デバイスからの前記チャンネル変更リクエストを含み、
    前記送信手段は、前記情報要素を後続ビーコンフレームに入れて前記第２のデバイスに送信するように適合される、請求項１９〜２６のいずれかに記載の第１のデバイス。
28. 受信された情報要素はカウントダウン要素を含み、前記情報要素を形成する手段は情報要素を形成するように適合され、前記情報要素は、前記受信された情報要素からの前記カウントダウンコンポーネントを含み、前記カウントダウンコンポーネントは１だけ低減される、請求項１９〜２７のいずれかに記載の第１のデバイス。
29. 前記受信された情報要素は、トラフィック流れを前記推進器デバイスと共に有するデバイスのリストを含み、前記情報要素を形成する手段は、前記デバイスのリストを前記情報要素内に含めるように適合される、請求項２７または２８に記載の第１のデバイス。
30. 前記情報要素内の前記デバイスのリストは、各デバイスについての関連付け状態を含み、前記状態は、前記リスト中のデバイスが前記チャンネル変更リクエストを受け入れているかまたは拒絶しているか、あるいは、前記デバイスによる決断が未だ未決であるかを示す、請求項２９に記載の第１のデバイス。
31. 前記情報要素はフィールドを含み、前記フィールドは、前記推進器デバイスが切り替え先として切り替えようとしている前記チャンネルの前記識別情報を示す、請求項１９〜３０のいずれかに記載の第１のデバイス。
32. 前記情報要素を形成する手段は、チャンネル変更命令を含む情報要素を形成するようにさらに適合され、前記送信手段は、前記情報要素を前記チャンネル切り替えに関与する前記１つ以上の他のデバイスに送信するようにさらに適用される、請求項３１に記載の第１のデバイス。
33. 前記情報要素は、前記チャンネル切り替えに関与するその他のデバイスに関連する切り替え状態情報を含む、請求項３２に記載の第１のデバイス。
34. 前記形成された情報要素はカウントダウン要素を含み、前記カウントダウン要素は、前記チャンネル切り替えが発生するであろう磁気を確認する、請求項３２または３３に記載の第１のデバイス。
    

Images