JP2005519522A - 無線ローカル・エリア・ネットワークを介して接続されたノードのクロック同期に対応する内部信号方法 - Google Patents

Abstract

本発明は、無線ローカル・エリア・ネットワーク（すなわち802.11ネットワーク）を介した有線又は無線ノードの無線同期のクロック・レジスタを無線で同期するためのクロック同期プロトコルに対応する一式の内部信号（すなわち管理プリミティブ）を開示する。クロック同期は、２つの異なる無線局（STA）内に存在する２つの高レイヤのプロトコル間で実行される。

Description

本発明は、概してクロック同期に関するものであり、特に高レイヤのプロトコルで厳しいクロック同期に対応する内部信号方法に関するものである。

高精度のクロック同期は、分散リアルタイムシステムにおける最も基本的な要件のうちの１つである。ローカル・クロックの避けられないドリフトにより、地球時間基準はクロック同期プロトコルを用いてのみ達成され得る。2002年3月7日に出願された同時係属の米国出願60/362,518は、その全てが参照として取り込まれ、それは無線ローカル・エリア・ネットワーク（すなわち802.11ネットワーク）を介した有線又は無線ノードの無線同期のクロック・レジスタ用のクロック同期プロトコルを対象にする。ここで開示されるクロック同期プロトコルに対応するために、媒体アクセス制御（MAC）からより高レイヤのプロトコルまで同期フレームについての情報を提供する一式の管理プリミティブ（すなわち内部信号）に対する必要性が存在する。

本発明は、無線ローカル・エリア・ネットワーク（すなわち802.11ネットワーク）を介した有線又は無線ノードの無線同期のクロック・レジスタ用のクロック同期プロトコルに対応する一式の内部信号（すなわち管理プリミティブ）を提供する。クロック同期は、２つの異なる無線局（STA）内に存在する２つの高レイヤのプロトコル間で実行される。

本発明の前述の特徴が、添付の図面と共に本発明の例示的な実施例の以下の詳細な説明を参照することにより、容易に明らかになり、理解され得る。

以下の説明において、限定のためではなく説明のため、本発明の完全な理解を提供するために、特定のアーキテクチャ、インタフェース、技術等のような特定の詳細が示されている。しかし、本発明は特定の詳細から逸脱した他の実施例で実施されることがあることは、当業者に明らかである。ある場合に、本発明をあいまいにすることを回避するため、周知の構成と装置が詳細にではなく、ブロック図の形式で示される。

本発明は、802.11無線LANを介した1394無線ノードの同期に関して以下に説明される。しかし、ここで説明される本発明の教示はそれに限定されないことがわかる。すなわち、本発明は、有線であれ無線であれ、ここで定められる厳しい同期を必要とする如何なる通信システムに適用できる。例えば、本発明は、IEEE802.3やイーサーネットのような有線通信システムに対する適用を有する。

次に図面、特に図１を参照すると、本発明の好ましい実施例が実施されることがあるIEEE802.11無線ネットワーク10が表されている。図示の通り、ネットワーク10は、1394バス16と18と20を有し、そのバスは例示的な実施例ではそれに関連付けられた無線ブリッジ（ノード）16aと18aと20aを有する。無線ブリッジ16aと18aと20aは、1394バス16と18と20の間のネットワーク10上で無線通信が生じ得る入口点としての役割をする。ネットワーク10はまた、1394スタンドアローン無線ノード21を有し、その1394スタンドアローン無線ノード21は、デジタルビデオカメラ又はパーム装置のような、他の装置と通信するために1394プロトコルを使用可能な何らかのスタンドアローン装置を表し得る。ネットワーク10は、有線1394ノード16bと18bを更に有する。

図１の例示的な実施例は、本発明をより明確に説明するためにのみ示されており、形式と機能の双方において多数の変形形態が可能であることを当業者は認識するであろう。例えば、ネットワーク10は、より多くの数若しくはより少ない数の1394バス、及び／又は同期を必要とする何らかの種類のノードを有することがある。ネットワーク10はまた、同期を必要とするより多くの数又はより少ない数のスタンドアローン・ノード又は非スタンドアローン・ノードを有することがある。図１の例示的な実施例に示される通り、ネットワーク10が無線／有線のノード／バスを接続するために、802.11WLAN技術又は何らかの他の種類の無線／有線通信システムを使用することがあることが認識されるべきである。そのような変形形態は本発明の意図内及び範囲内であると考えられる。ネットワーク10と以下の例示的な図は、単に説明の目的の例として提供されており、アーキテクチャの限定を示すものと意図されたものではない。

ネットワーク10でクロック同期を実行するために、ネットワーク10でマスター・ノード（又は“ルート・ノード”）として任意に指定されたノードからタイムスタンプ値が作られる。ネットワーク10において、ノード16aはマスター・クロックのマスター・ノードとして任意に選択され、そのマスター・ノードとネットワークのその他の非マスター・ノード（スレーブ・ノード）が同期される。ネットワーク10のマスター・ノード16aは、ネットワーク内でクロック配信の役割を有する。

図２ａを参照すると、簡単な説明のため、マスター・ノード16aと単一の非マスター・ノード18aのみを使用して、クロック同期の処理が示されている。単一の図示された非マスター・ノード18aで実行される動作が、ネットワーク10のその他の全ての非マスター・ノードで同一の方法で生じることがわかる。図２ａは、本発明の実施例によるマスター・ノード16aと非マスター・ノード18aの構成を示したものである。マスター・ノード16aと非マスター・ノード18aは、内部24,576Hzクロック（発振器）16cと18cと、関連するサイクル時間レジスタ16dと18dを有するものとして示されている。24.576Hzクロック16cと18cは自由に動作し、関連するサイクル時間レジスタ16dと18dの内容を更新する。サイクル時間レジスタ16dと18dは、現在時刻の値を指定するフィールドを提供し、サイクル時間レジスタがクロックのハードウェアを書き込みトランザクションに含まれる値に初期化するのを待つ。マスター・ノード16aと非マスター・ノード18aを構成する要素は従来式であり、更に説明されない。

図２ｂは、クロック同期を実行する２つの連続送信の同期フレームF_i27とF_i+128を示したものである。同期フレーム27と28は、ネットワーク10でマスター・ノード16aから全ての非マスター・ノード（すなわち非マスター・ノード18a）に、ほとんど定期的な間隔で送信されることがある。それぞれの同期フレームは、そのソースアドレス（すなわちフレームを送信するマスター・ノードのMACアドレス）と宛先アドレスの双方により特定される。宛先アドレスは、クロック同期を実行するために明示的に用意された特別のマルチキャストアドレスである。それぞれの同期フレームは、ほとんど定期的な間隔でサイクル時間レジスタ16dと18dを同期するクロック同期情報を有する。同期フレーム27と28は、マスター・ノード16a及び非マスター・ノード18内に存在する高レイヤのプロトコルのエンティティを同期するように、マスター・ノード16aから作られる。本発明は、その高レイヤのプロトコルに対応するための方法を対象にする。

マスター・ノード16aと非マスター・ノード18のステーション管理エンティティ（SME: Station Management Entity）とMACとの間の管理プリミティブを示すために、802.11一般管理アーキテクチャが以下に説明され、図３に示される。ここで管理プリミティブは1394クロック同期の適用について説明されるが、本発明の管理プリミティブは、厳しい同期を必要とする如何なる高レイヤのプロトコルに対して広い適用を有することがわかる。

図３は、ノード16aと18aを説明するための802.11管理アーキテクチャを示したものである。前記アーキテクチャは、３つの構成要素（MACレイヤ管理エンティティ（MLME）31と、物理レイヤ管理エンティティ（PLME）33と、システム管理エンティティ（SME）35）で構成される。管理構成要素32と34と36の間に３つの定義済みのインタフェースが存在する。SME35は、MACとPHYの管理情報ベース（MIB）の双方を変更することがある。MAC37とPHY39レイヤの双方は、MIBへのアクセスを有する。MIBは、状態情報と特定の動作が行われることを引き起こし得るオブジェクトとを取得するために照会され得る。MLMEレイヤ31は、MLME_PLMEサービス・アクセス・ポイント（SAP）34を通じて、特定のプリミティブを介してPLME33と通信する。MLMEレイヤ31が命令する場合、PLMEサブレイヤ33がPLCPサブレイヤ43に命令し、送信のためにMPDUを準備する。PLCPサブレイヤ43はまた、無線媒体からMACレイヤ37に入力フレームを配信する。PLCPサブレイヤ43は、PMDサブレイヤ45による送信に適したフレームフォーマットにMPDUをマッピングすることにより、PMDサブレイヤ45へのMACレイヤ37の依存を最小化する。PLCPサブレイヤ43の指示を受けて、PMDサブレイヤ45は、無線媒体を通じた２つのステーション間のPHYエンティティの実際の送受信を提供する。このサービスを提供するために、PMDサブレイヤ45は空気媒体との直接のインタフェースになり、フレーム送信の変調と復調を提供する。

次に図４のフローチャートと図５の処理フロー図を参照すると、本発明の例示的な実施例による図１の無線ノードのように、高レイヤのプロトコルのクロック同期に対応することが含まれる例示的なステップが以下に説明される。

処理はステップ55で始まり、マスター・ノード16aの高レイヤのプロトコルがSMEの同期要求を作る。高レイヤのプロトコルからの同期要求は、高レイヤの同期プロトコルを開始するために必要である。次に、SMEは、特にMLME31の同期サポート機構の起動を要求するMLME-HL-SYNC.requestプリミティブの形式でMLME31に同期要求を出す。第１の管理プリミティブは下記のように記述される。
Ａ．一般的な形式のMLME-HL-SYNC.requestプリミティブ
MLME-HL-SYNC.request {
RxAddress
}
Ｂ．パラメータの説明

MACレイヤ37はどのフレームが同期フレームであるかを独自に知る方法を有さないことに留意すべきである。従って、同期フレームが高レイヤのプロトコルにより出されると、それは同期フレームを認識するいくつかの方法を有していなければならない。“RxAddress”パラメータは、MACレイヤ37がフレームを同期フレームとして認識する手段である。特に、“RxAddress”は、MACレイヤ37が高レイヤ又はPHYレイヤからマルチキャストアドレスである“RxAddress”に等しい宛先アドレスを有するフレームを受信した時をMACレイヤ37に通知し、そのフレームはMACレイヤ37により同期フレームとして認識されるべきである。

ステップ59において、MACレイヤ37が同期サービス要求をSME35から受け入れるか否かが判断される。サービス要求がMACレイヤ37により受け入れられない場合、処理はステップ61で終了する。その他に、MACレイヤ37がSME35の同期サービス要求を受け入れる場合、処理はステップ63に続く。

ステップ61において、MACレイヤ37がSMEから同期サービス要求を受け入れないため、処理が終了する。この場合、MLME31はMLME-HL-SYNC.confirmプリミティブをSME35に出し、“ResultCode”=NotSupportedというパラメータの設定でMACレイヤ37において同期サービスが対応されていないことを示す。

ステップ63において、同期サービス要求がMACレイヤ37により受け入れられたことが判断される。この場合、MLME31はMLME-HL-SYNC.confirmプリミティブをSMEに出し、“ResultCode”=Successというパラメータの設定で同期サービスが対応されていることを示す。
Ａ．一般的な形式のMLME-HL-SYNC.confirmプリミティブ
MLME-HL-SYNC.confirm {
ResultCode
}
Ｂ．パラメータの説明

ステップ65において、第３のプリミティブが同期フレームの完全な送信／受信を通知する。特に、MLME-HL-SYNC.indicationプリミティブがMLME31により作られ、PLME33の結果としてSME35に送信され、それがフレームを受信／送信したことをMLME31に通知する。

第３のプリミティブは、２つの場合（同期フレームの受信と送信）を含む。同期フレームの受信は、非マスター・ノード（すなわちノード18a）で生じ、その非マスター・ノードは、マスター・ノード（すなわちノード16a）から同期フレームを受信する。同期フレームの送信は、マスター・ノード16aで生じる。

同期フレームが非マスター・ノード18aで受信された場合、MACレイヤ37は、受信された同期フレームの宛先アドレスを確認し、それをMLME-HL-SYNC.requestプリミティブにより前に特定されたその“RxAddress”と比較する。合致する場合、MLME31は、MLME-HL-SYNC.indicationプリミティブを介して、同期フレームを受信したことをSME35に示す。受信同期フレームの無線の最後の符号がPHYレイヤにより検出され、通知されると、MLME-HL-SYNC.indicationが出される。

同期フレームがマスター・ノード16aから送信された場合、MACレイヤ37は、送信されたフレームの宛先アドレスを確認し、それをMLME-HL-SYNC.requestプリミティブにより前に特定されたその“RxAddress”と比較する。合致する場合、MLME31は、MLME-HL-SYNC.indicationプリミティブを介して、同期フレームを送信したことをSME35に示す。送信同期フレームの無線の最後の符号がPHYレイヤにより検出され、通知されると、MLME-HL-SYNC.indicationが出される。
Ａ．一般的な形式のプリミティブ
MLME-HL-SYNC.indication {
TxAddress
SequenceNumber
ProcDelay
}
Ｂ．パラメータの説明

本発明の好ましい実施例が説明され、記載されたが、多様な変化と変更が行われることがあり、本発明の真の範囲を逸脱することなく、同等のものがその要素に代用されることがあることを当業者により認識されるであろう。更に、中心の範囲から逸脱することなく、特定の状況と本発明の教示に取り入れられるように多くの変更が行われることがある。従って、本発明は、本発明を実行するために企図されたベストモードとして開示された特定の実施例に限定されず、特許請求の範囲内にある全ての実施例を含むものと意図される。

本発明の実施例が適用される無線通信システムのアーキテクチャを示したものである。 aは、図１の通信システムからのマスター・ノードと代表的な非マスター・ノードとを示したものである。ｂは、マスター・ノードから非マスター・ノードにほとんど定期的な間隔で送信される２つの連続送信の同期フレームを示したものである。 図２ａのマスター・ノードを表すための802.11管理アーキテクチャの説明図である。 本発明の実施例によるクロック同期に対応するための動作ステップを示したフローチャートである。 図４のフローチャートの動作ステップを更に示した処理フロー図である。

Claims (13)

1. ネットワークに通信で結合された複数の非マスター・ノードを有する通信システムにおいて、
   前記複数の非マスター・ノードのそれぞれが、ローカル時間基準を有し、
   前記複数の非マスター・ノードのうちの１つが、前記非マスターのローカル時間基準が同期されるマスター・クロックとしての役割をするマスター時間基準を有するマスター・ノードとして指定され、
   前記マスター及び非マスター・ノードの高レイヤプロトコルでクロック同期に対応する方法であって、
   (a)前記マスター・ノードの高レイヤのプロトコルで同期要求を作るステップと、
   (b)前記ノードに関連するステーション管理エンティティ（SME）からMACレイヤ管理エンティティ（MLME）に、同期対応機構を要求する要求プリミティブを出すステップと、
   (c)前記MLMEで、前記ステップ(b)の前記同期対応機構の要求を受け入れるか否かを判断するステップと、
   (d)前記ステップ(c)で前記要求が受け入れられると、前記MLMEから前記SMEに、前記同期対応機構が対応されたことを示す確認プリミティブを出すステップと、
   (e)前記ノードに関連する物理レイヤ（PHY）から前記MLMEへのフレームの受信と送信のうちの１つを通知するステップと、
   (f)前記ステップ（e）に応じて、前記MLMEから前記SMEに指示プリミティブを出すステップと
   を有する方法。
2. 請求項１に記載の方法であって、
   ステップ(c)で前記同期対応機構を受け入れないことが前記MLMEにより判断された場合、前記MLMEによる前記同期要求を終了するステップと、
   “NotAccepted”と等しいResultCodeのパラメータでMLME-HL-SYNC.confirmプリミティブを出すステップと
   を更に有する方法。
3. 請求項１に記載の方法であって、
   前記MLMEから前記SMEに出された前記指示プリミティブが、受信又は送信された同期フレームの無線の最後の符号が前記PHYレイヤにより検出され、通知された時に出される方法。
4. 請求項１に記載の方法であって、
   前記SMEから前記MLMEに送信された前記要求プリミティブが、
   MLME-HL-SYNC.request {
   RxAddress
   }
   の一般的な形式を有するMLME-HL-SYNC要求プリミティブであり、
   RxAddressがマルチキャストアドレスである方法。
5. 請求項１に記載の方法であって、
   前記MLMEから前記SMEに出された前記確認プリミティブが、
   MLME-HL-SYNC.confirm {
   ResultCode
   }
   の一般的な形式を有するMLME-HL-SYNC要求プリミティブであり、
   RequestCodeが“support”又は“not support”の値を有する方法。
6. 請求項１に記載の方法であって、
   前記MLMEから前記SMEに出された前記指示プリミティブが、
   MLME-HL-SYNC.indication {
   TxAddress
   SequenceNumber
   ProcDelay
   }
   の一般的な形式を有するMLME-HL-SYNC指示プリミティブであり、
   TxAddressが、同期フレームを送信するMACエンティティのアドレスを特定し、
   SequenceNumberが、前記同期フレームのシーケンス番号を特定し、
   ProcDelayが、前記プリミティブの生成と、前記プリミティブを生成したフレームのある所定の検出ポイントが無線で検出された時間との間の推定時間を特定する方法。
7. 請求項１に記載の方法であって、
   前記ネットワークが、無線ネットワークと有線ネットワークのうちの１つである方法。
8. ネットワークを介して通信で結合された複数の非マスター・ノードを有する通信システムにおいて、
   前記複数の非マスター・ノードのそれぞれが、ローカル時間基準を有し、
   前記複数の非マスター・ノードのうちの１つが、前記非マスターのローカル時間基準が同期されるマスター・クロックとしての役割をするマスター時間基準を有するマスター・ノードとして指定され、
   前記マスター・ノードの高レイヤのプロトコルで同期要求を作るための手段と、
   前記ノードに関連するステーション管理エンティティ（SME）からMACレイヤ管理エンティティ（MLME）に、同期サポート機構を要求する要求プリミティブを出すための手段と、
   前記MLMEで、前記ステップ(b)の前記同期サポート機構の要求を受け入れるか否かを判断するための手段と、
   前記ステップ(c)で前記要求が受け入れられると、前記MLMEから前記SMEに、前記同期サポート機構が対応されたことを示す確認プリミティブを出すための手段と、
   前記ノードに関連する物理レイヤ（PHY）から前記MLMEへのフレームの受信と送信のうちの１つを通知するための手段と、
   (f) 前記ステップ（e）に応じて、前記MLMEから前記SMEに指示プリミティブを送信するための手段と
   を有するシステム。
9. 請求項８に記載のシステムであって、
   ステップ(c)で前記同期サポート機構を受け入れないことが前記MLMEにより判断された場合、前記MLMEによる前記同期要求を終了するための手段と、
   前記同期サポート機構の受け入れをしないことを示すResultCodeのパラメータでMLME-HL-SYNC.confirmプリミティブを出すための手段と
   を更に有するシステム。
10. 請求項８に記載のシステムであって、
    前記指示プリミティブを送信するための手段が、受信又は送信された同期フレームの無線の最後の符号が前記PHYレイヤにより検出され、通知された時を示すための手段を更に有するシステム。
11. 請求項８に記載のシステムであって、
    前記要求プリミティブが、マルチキャストアドレスを特定する少なくとも１つのパラメータを有するシステム。
12. 請求項８に記載のシステムであって、
    前記指示プリミティブが、
    同期フレームを送信するMACエンティティのアドレスを特定するための第１のパラメータと、
    前記同期フレームのシーケンス番号を特定するための第２のパラメータと、
    前記プリミティブの生成と、前記プリミティブを生成したフレームのある所定の検出ポイントが無線で検出された時間との間の推定時間を特定するための第３のパラメータと
    を少なくとも有するシステム。
13. 請求項８に記載のシステムであって、
    前記ネットワークが、無線ネットワークと有線ネットワークのうちの１つであるシステム。

Images