低速近距離無線に代表されるZigBeeは、ネットワーク層以上で動くプロトコルです。したがって、物理層とMAC層は他の規格を採用しなければなりません。そこで、ZigBeeはIEEEが定めたIEEE802.15.4という規格を採用しています。IEEE802.15.4は低速のPAN向けの規格です。ワイヤレスセンサネットワーク(WSN : Wireless Sensor Network)で動かすのに適しています。同じPANでもBluetoohは中速なので、IEEE802.15.1を採用しています。
OSI参照モデルに倣うと、IEEE802.15.4/ZigBeeの概要は以下のようになっています 。このNetwork層がZigBeeになります。実際には、ZigBeeはアプリケーション層とのサポート層も実装しているので、ネットワーク層より少し上の層(アプリケーション副層)まであります。
SAP : Service Access Point
(PD-SAPやPLME-SAPは後述。MCPS-SAPやMLME-SAPに関しては、次回まとめる予定)
IEEE802.15.4は上の画像のように、各層とそれをつなぐインターフェースで構成されています。
IEEE802.15.4を規格化するグループは、IEEE802.2 LMSC(LAN and MAN Standard Committee)という標準委員会の下にいるので、IEEE802.2 type1 LLC(Logical Link Control)のサポートが義務付けられています。しかし、これはワイヤレスセンサーネットワークよりも以前に規格化された有線向けのものです。そこで、これでは不十分なので、IEEE802.15.4はそれをさらにサポートする形で、SSCS(Service Specific Convergence Sublayer)を定義しました。
IEEE802.2 LLCはtype１、type２、type３の３種類あります。
type１：コネクションを確立しないし、Ackも返さない。
type２：コネクションを確立する。Ackあり。
type３：コネクションを確立しないが、Ackは返す。
どのような通信をするかによって、実装するタイプが異なります。IEEE802.15.4はワイヤレスセンサーネットワークをターゲットとしているので、type１が使われています。しかし、ワイヤレスセンサーネットワークの運用の仕方によっては、信頼性を高めたい場合もあるかもしれません。そこでIEEE802.15.4は、MAC層でAckの有無をオプションとして選択できるようにしています。
IEEE802.15.4 SSCSついてはこちら。
URL : https://wireless-network.net/ieee802-15-4-mac-sscs/
このIEEE802.15.4を理解する分には、IEEE802.2 type1 LLCやSSCSはそこまで意識する必要はないかと思います。メインとなるのは物理層とMAC層のところなので、人によっては説明するときに、 IEEE802.2 type1 LLCやSSCS を省く人もいます。
IEEE802.15.4 サービス＆プリミティブ
ではもう少し具体的な内容に入っていきます。
少し横暴な表現をすると、物理層・MAC層ともに、"サービス"と"プリミティブ"の二つで出来ています。 サービスとプリミティブに関しては、実際にどのようなものがあるか、見た方が理解しやすいと思います。初めに両者の簡単な説明をした後に、実際に中身を見てみましょう。
ある層が提供するサービスには、"データサービス"と管理サービス"があります。名前の通りデータサービスでは、通信のデータに関するサービスを提供し、管理サービスでは通信の設定に関するサービスを提供します。
フレームが上位層と下位層を行き来するように、各層をつなぐインターフェースが必要です。IEEE802.15.4タスクグループ含め、IEEE802.2標準化委員会では、各層をつなぐインターフェースのことを"プリミティブ"と表現しています。サービスを提供する際に、各層間でやり取りするときに使われるものだと思って下さい。
そしてプリミティブには ４種類あります。
- 要求(request) : 上位層から下位層に何かを要求するとき
- 確認(confirm) : 要求に対する返答
- 通知(indication) : 下位層が上位層へ通知するとき
- 応答(response) : 通知に対する返答
プリミティブ各種の説明はイメージで、正確性に少し欠けますが、大体このようなときに使われます。
また全てのサービスに、４種類とも全てのプリミティブが揃っているとは限りません。後述しますが例えば、物理層には データを送受信 するデータサービスがあります。 この"送受信する"という機能のプリミティブには、要求・確認・通知しかありません。応答はありません。データを受信した際、物理層はMAC層に通知します。しかし、物理層からの通知に対して、MAC層は"受け取ったよ！ありがとう"ということは、 物理層にわざわざ言わないんですね。
ここまでで、IEEE802.15.4の物理層・MAC層に共通することを簡単に説明しました。
それでは次に、物理層に焦点を当てて見ていきます。変調方式や周波数などの基本的な仕様の説明は、他のサイトでたくさん紹介があるのでここでは省きたいと思います。ここでは、物理層の機能や実際何をやっているのかについてまとめていきます。
IEEE802.15.4 物理層
先ほど、各層が提供するサービスは２種類あると言いました。データサービスと管理サービスです。
物理層におけるデータサービスは、データの送信/受信と通信経路のリンク品質の測定があります。
管理サービスには、電界エネルギー測定、クリアチャネル判定(CSMA/CAをするときにチャネルがビジーでないかの判定)、送受信機のON/OFF制御、物理層で管理するパラメータの管理があります。
ワイヤレスセンサネットワーク向けの規格であるので、出来るだけ無駄を省いて動作できるような目的で作られていることが分かります。一見難しそうに見えますが、上位層から送られてきたデータを、"干渉することなく、高品質の経路で送信し、それ以外のときは寝る"という機能を実装するための土台を、物理層では提供しています。
では実際に、物理層のサービスとプリミティブについて見ていきます。
以下、物理層の"データサービス"と"管理サービス"のパートに分けて説明します。
ではまず、物理層データサービスからです。
物理層データサービスはPD(PHY Data)と呼ばれています。PDには以下の種類があります。
- PD-DATA : データの送信 と受信
"データを送信/受信する"データサービスをPD-DATAと言います。先ほど物理層のデータサービスは 、 データの送信/受信と通信経路のリンク品質の測定 の二つあると書きました。このリンク品質測定はPD-DATAの中に組み込まれています。
IEEE802.15.4 PD-DATA
"データを送信/受信する"データサービス : PD-DATAは、次のようにサービス提供します。
"PD-DATA.～"が、PD-DATAというサービスにおけるプリミティブです。
PD-DATA.request
MAC層は物理層に向けて、データ伝送の要求(PD-DATA.request)を出します。PD-DATA.requestの中身は、PSDU(Physical Layer Service Data Unit, つまりMPDUのこと)とPSDUの長さから成り立っています。このPSDUは物理層におけるペイロードのことです。
PD-DATA.request (
psduLength ,
psdu
)
物理層はrequestを受け取ると、PPDU(Physical Protocol Data Unit, 物理層フレーム)を完成させてから(プリアンブルとSFDを加える)、受信機に向けて送信します。
ACKはオプションで、 受信機はデータを受信したら、必要に応じてACKを返します。IEEE802.15.4のフレームフォーマット基本形を見ると、PD-DATAが何をやっているのか分かりやすいと思います。
下位層のペイロード(○SDU)が、上位層のフレーム全体(○PDU)に相当します。
PD-DATA.confirm
PPDUの送信が成功すると物理層はMAC層にPD-DATA.confirmを返します。 PD-DATA.confirmのパラメータは、statusを入れます。statusは、Success・Rx_ON(受信中でデータ送信できんかった)・TRX_OFF(そもそもRF回路動いてないよ！)の３パターンのいずれかです。
PD-DATA.confirm (
status
)
PD-DATA.indication
受信機はデータを受信するときに、LQI(Link Quality Indication : リンク品質指数)を計算します。この計算結果と受信したデータをMAC層に渡します(PD-DATA.indication)。LQIの測定は、物理層が提供するのデータサービスの一つです。送受信機間の電界強度と干渉の程度によって算出されますが、IEEE802.15.4では具体的な計算方法は定められておりません。しかし、0x00～0xffの整数を渡すことは規定されています。
PD-DATA.indication (
psduLength,
psdu,
ppduLinkQuality
)
IEEE802.15.4物理層におけるデータサービスとプリミティブは以上です。
次はIEEE802.15.4物理層における管理サービスとプリミティブです。
物理層管理サービスはPLME(Physical Layer Management Entity)と呼ばれています。先ほど、 管理サービスには、電界エネルギー測定、クリアチャネル判定、送受信機のON/OFF制御、物理層で管理するパラメータの管理があると書きました。 それぞれ以下のように言います
- PLME-ED : 電界エネルギー測定
- PLME-CCA : クリアチャネル判定(CSMA/CA時のチャネル状況確認)
- PLME-GET/SET : 物理層が管理するパラメータの読み書き
- PLME-TRX-STATE : スリープモードのON・OFF
では順に説明していきます。
IEEE802.15.4 PLME-ED
"電界エネルギーを測定する"管理サービス : PLME-EDは、次のようにサービス提供します。
PLME-ED.request
MAC層から、チャネルの電界エネルギーを測定してほしいと、要求が出されます。PLME-ED.requestを受け取ったら、物理層は指定されたチャネルの電界エネルギーを測定します。要求を出すだけなので、PLME-EDのパラメータはありません。
PLME-ED.request ()
PLME-ED.confirm
測定が完了したら、結果をMAC層に返します(PLME-ED.confirm)。測定結果は、0x00～0xffの整数で表されます。PLME-ED.confirmのパラメータは、送信できたか否かのステータスと測定結果が含まれています。ステータスには、測定成功ならSuccessが入ります。
Success : 測定成功
TRX_OFF : RF回路が動いていないので、電界エネルギーの測定ができなかった。
TX_OF : 送信中につき、電界エネルギーの測定ができなかった。
PLME-ED.confirm (
status,
energyLevel
)
IEEE802.15.4 PLME-CCA
IEEE802.15.4のアクセス方式はCSMA/CAを採用しています。したがって、他のデバイスとの通信衝突を防ぐために、通信する前にチャネルの空き状況を確認しなければいけません。CSMA/CAはMAC層のお仕事だと一見考えがちですが、チャネルのfree/busyを確認するのは、物理層の役割です。MAC層ではチャネル状況のチェックができない、ということです。
この確認する作業はクリアチャネル判定(CCA : Clear Channel Assesment)と呼ばれており、物理層の管理サービスが提供します。PLME-EDと似ており、MAC層から要求が来たら、確認して返答する、といった感じです。判定方法は、何を基準にしてどうしたら空いているか、などによって違います。つまり判定方法が３種類存在します(各方法の説明は省略)。どの判定方法を用いるかは、物理層が管理する情報庫に格納されている(後述)。
PLME-CCA.request
MAC層はCSMA/CAが必要になったら、物理層に クリアチャネル判定を要求を出します(PLME-CCA.confirm)。これもPLME-ED同様に要求だけなので、パラメータはなしです。
PLME-CCA.request ()
PLME-CCA.confirm
要求を受け取ったら、物理層は外部から電波を受信することによって、チャネル状況を確認します。PLME-ED.confirmでは、整数とステータスをパラメータとして返しますが、PLME-CCA.confirmはステータスのみを返します。PLME-CCA.confirmのステータスは４種類あります。TRX_OFF 、 TX_ON、BUSY、IDLEのどれかに該当します。
TRX_OFF : RF回路が起動していない
TX_ON : 送信中でCCAできなかった
BUSY : チャネルビジー状態
IDLE : チャネル空いている
PLME-CCA.confirm (
status
)
IEEE802.15.4 PLME-GET/SET
これは物理層で管理されているデータの読み書きを行います。
物理層で管理されているデータはPHY PIB(Primitive Information Base)と呼ばれています。同様にMAC層で格納されている情報は、MAC PIBと言います。層によって情報が異なりますが、物理層で格納されているのは以下です。
phyCurrentChannel : 現在のチャネル(CH：0～26)
phyTransmitPower : 送信出力
phyCCAMode : CCAの判定する際のやり方(モード１～3の３つある)
など
PLME-GET.require
MAC層は物理層にPHY PIBの読み出し要求をします。
PLME-GET.require (
pibAttribute
)
PLME-GET.confirm
要求を受け取ったら、物理層は情報とステータスをMAC層に渡します。ステータスは２つだけです。もし要求された情報に対し、物理層が所持している情報ならSUCCESSを返し、所持していない情報なら、UNSUPPORTED_ATTRIBUTE を返します。
PLME-GET.confim (
status,
pibAttribute,
pibAttributValue
)
PLME-SET.request
MAC層は物理層にPHY PIBの書き込みを要求します(新しい情報を物理層に渡します)。
PLME-SET.require (
pibAttribute,
pibAttributeValue
)
PLME-SET.confirm
物理層はPIBへの書き込みを行います。MAC層から受け取った新しい情報の書き込みに成功したら、更新したPIBとともにSUCCESSを返します。
PLME-SET.confirm (
status,
pibAttribure
)
PLME-SET-TRX-STATE
センサーは必要ないときはRF回路をオフ(スリープモード)にしておくことが望ましいです。そうすることで、バッテリーが長持ちします。この管理サービスでは、RF回路のON/OFFを提供します。
PLME-SET-TRX-STATE.require
MAC層は、RF回路をどの状態にするか、物理層にステータスを渡します(PLME-SET-TRX-STATE.require)。ステータスは以下のものがあります。
RX_ON : 受信のみ許可
TX_ON : 送信のみ許可
TRX_OFF : RF回路をオフ(送受信ともにオフ)
FORCE_TRX_OFF : RF回路の強制オフ(要求出したときにRF回路が動いていても関係なくオフにする)
PLME-SET-TRX-STATE.request (
state
)
PLME-SET-TRX-STATE.confirm
要求(ステータス)にしたがって、物理層はRF回路のオン・オフをする。強制オフでない場合は、RF回路が動作中にはオフにできないため、その際はBUSYを返す。設定に成功した場合は、SUCCESSを返す。ここでもし、既にRX_ONなのに、"RX_ONにして"、という要求がMAC層から来たら物理層は、"既にオン"という意味を込めて"RX_ON"を返す。
PLME-SET-TRX-STATE.confirm (
status
)
以上で、IEEE802.15.4物理層の説明は終わりです。
最後まで読んでいただきありがとうございました。
お世話になった参考文献
- https://www.iith.ac.in/~tbr/teaching/docs/802.15.4-2003.pdf
- http://vaddina.com/images/ZIGBEE_zigbee.pdf
- http://www.cs.unibo.it/~lbedogni/files/vario/802.15.4-summary.pdf