MasaのITC Life

夢は起業家！全てにおいて凡人だけど頑張ることだけはいっちょ前！

IoT

IEEE802.15.4/ZigBee MAC層の役割について(その1)

投稿日：2019年3月11日 更新日：

ZigBeeの物理層・MAC層を担っているのは、IEEEで規格化されたIEEE802.15.4です。IEEE802.15.4は低伝送速度のPAN(Private Area Network)を対象としてします。IEEE802.15.4/ZigBeeの階層モデルは、OSI参照モデルに倣うと以下のようになっています。

SAP : Service Access Point

IEEE802.15.4は上の画像のように、各層とそれをつなぐインターフェースで構成されています。




IEEE802.15.4/ZigBee 物理層の役割をまとめたものはこちら。物理層の動きをすべて書き下ろしました。実際に、実装するときの手助けになるかと思います。

IEEE802.15.4/ZigBee 物理層の役割について


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.15.4 SSCSについてまとめたものはこちら。
URL : https://wireless-network.net/ieee802-15-4-mac-sscs/



IEEE802.2 LLCはtype１、type２、type３の３種類あります。

type１：コネクションを確立しないし、Ackも返さない。
type２：コネクションを確立する。Ackあり。
type３：コネクションを確立しないが、Ackは返す。

どのような通信をするかによって、実装するタイプが異なります。IEEE802.15.4はワイヤレスセンサーネットワークをターゲットとしているので、type１が使われています。しかし、ワイヤレスセンサーネットワークの運用の仕方によっては、信頼性を高めたい場合もあるかもしれません。そこでIEEE802.15.4は、MAC層でAckの有無をオプションとして選択できるようにしています。 各typeの例として、type1はEthernt、type2はIEEE802.11、type3は衛星通信などがあげられます。




MAC層スーパフレームやビーコンなど、MAC層の概念について紹介さているサイトは、たくさんあるので今回は省略します。ここではMAC層の挙動について詳しくみていきます。これが理解できると、実装もイメージしやすくなるかと思います。



それではもう少し踏み込んだ説明に入っていきます。

IEEE802.15.4 サービス＆プリミティブ


少し横暴な表現をすると、物理層・MAC層ともに、"サービス"と"プリミティブ"の二つで出来ています。サービスとプリミティブに関しては、実際にどのようなものがあるか、見た方が理解しやすいと思います。初めに両者の簡単な説明をした後に、実際に中身を見てみましょう。

ある層が提供するサービスには、"データサービス"と管理サービス"があります。名前の通りデータサービスでは、通信のデータに関するサービスを提供し、管理サービスでは通信の設定に関するサービスを提供します。

フレームが上位層と下位層を行き来するように、各層をつなぐインターフェースが必要です。IEEE802.15.4タスクグループ含め、IEEE802.2標準化委員会では、各層をつなぐインターフェースのことを"プリミティブ"と表現しています。サービスを提供する際に、各層間でやり取りするときに使われるものだと思って下さい。なので、サービスにプリミティブが備わっているイメージです。



そしてプリミティブには ４種類あります。

  • 要求(request) : 上位層から下位層に何かを要求するとき
  • 確認(confirm) : 要求に対する返答
  • 通知(indication) : 下位層が上位層へ通知するとき
  • 応答(response) : 通知に対する返答


プリミティブ各種の説明はイメージで、正確性に少し欠けますが、大体このようなときに使われます。



また全てのサービスに、４種類とも全てのプリミティブが揃っているとは限りません。後述しますが例えば、物理層には データを送受信 するデータサービスがあります。 この"送受信する"という機能のプリミティブには、要求・確認・通知しかありません。応答はありません。データを受信した際、物理層はMAC層に通知します。しかし、その物理層からの通知に対して、MAC層は"受け取ったよ！ありがとう"ということは、わざわざ物理層に言わないんですね。




ここまでで、IEEE802.15.4の物理層・MAC層に共通することを簡単に説明しました。

次に、MAC層の機能や実際何をやっているのかについてまとめていきます。



IEEE802.15.4 MAC層データサービス

先ほど、各層が提供するサービスは２種類あると言いました。データサービスと管理サービスです。またMAC層は追加オプションとして、セキュリティサービスを実装することも可能です。



まずはMAC層の"データサービス"から説明します。

MAC層データサービスはMCPS(MAC Comman Part Sublayer)と呼ばれています。

  • MCPS-DATA
  • MCPS-PURGE

そして、上の２つがMAC層が提供するデータサービスの名前です。

MCPS-DATAはデータの送信をします。
（※実際に電波に乗せるのは物理層。MAC層は上位層と下位層のデータ転送の中継役）
MCPS-PURGEは送信データの取り消しを行います(オプション)。


それぞれ具体的に見ていきましょう！


IEEE802.15.4　MCPS-DATA

物理層のデータサービス:PD-DATA同様に、MAC層でもデータ送受信の役割をします。実際は物理層が電波を発して物理的に送信します。MAC層から相手のMAC層にデータを届ける機能を担っています。MCPS-DATAにはプリミティブが３つあります。下の図は、データを送受信するときおの流れを少し具体的に表現したものです。実際はもうちょっとだけ複雑ですが、本質は以下の図になります。

MCPS-DATA.request

MAC層は上位層である(SSCS)からデータ送信の要求を受けます(MCPS-DATA.request)。このMCPS-DATA.requestにはMAC層のペイロードやヘッダーなどを含む、以下のようなパラメータが入っています。MAC層の上位層はネットワーク層だと思いがちですが、厳密にはIEEE802.15.4では、(本記事冒頭の画像のように)SSCSが間に入ってます。

MCPS-DATA.request (
srcAddrMode
srcPanID
srcAddr
dstAddrMode
dstPanID
dstAddr
msduLength
msdu
muduHandle
txOption
)

MAC層のフレーム構造を見ると分かりやすいと思います。SSCSから要求を受け取った時点では、まだMPDUは完成していませんが、それに近い構造をもったデータが送られてきます。そして要求を受けたら、CSMA/CAなどをした後に、物理層にPD-DATA.requestを出しますが、そのときにMPDUを完成させ、そしてMPDUの長さも加えて渡します。



MCPS-DATA.reqestを受けたあと、MAC層は物理層にPLME-SET-TRX-STATE.requestを発行します。これはIEEE802.15.4の物理層をまとめた記事を見ていただければ、わかりやすいと思います。物理層に、RF回路を送信できる状態にするように要求し、SUCCESSもしくはTX_ONの返答を待ちます。

MCPS-DATA.requestは、様々なパラメータが入っています。各パラメ―タの詳細は以下の内容です。

srcAddrMode
送信元アドレスをどうするか。アドレスなし(0x00)・予約済み(0x01)・16ビットショートアドレス(0x02)・64ビットIEEEアドレス(0x03)など、どのアドレスを"srcAddr"に格納するか、0x00～0x03で指定する。srcAddrMode(dstAddrMode)はMAC層ヘッダー中のフレームコントロールの一部になる。

srcPanID
送信者が所属するPAN IDを入れる。

srcAddr
送信モードで指定されたアドレスを入れる。

dstAddrMode / dstPanID / dstAddr
受信側のアドレスとPAN IDの情報

msduLength
MSDUの長さ

msdu
MSDU(MAC層ペイロード/言い換えるならSSCS層のフレーム)、つまり上位層のデータが入っている。

msduHandle
MSDUのハンドル(プログラミングの話になるので省略)。

txOption
Ack、GTS(Guaranteed Time Slot )、セキュリティ有無などの設定をする。もし、Ackを有効にしたなら、送信側はAckが返ってくるまでAck時間だけ待つ。待ってもAckが受信できなければ、再送処理をする。実際に物理層に渡すときは、Ackの有無などはMAC層ヘッダー中のフレームコントロールの中に入れて渡す。



以上がMCPS-DATA.requestのパラメータです。MAC層はrequestに対して返答します。

MCPS-DATA.confirm

MAC層はSSCSからの送信要求に対して、その結果を報告します(MCPS-DATA.confirm)。パラメータは以下のものが入っています。

MCPS-DATA.confirm (
msduHanlle
status
)

statusについて少し触れますが、読み飛ばしてもらっても大丈夫です。
いずれにせよ成功したかしてないか、成功してない場合は原因は何かはっきり分かるように、MCPS-DATA.confirmします。

パラメータ : statusの一部詳細

SUCCESS
データが受信機まで届いた

CHANNEL_ACCESS_FAILURE
IEEE802.15.4はデータを送信する前に、CSMA/CAを行う。MAC層は物理層にクリアチャネル判定(CCA)を要求する(PLME-CCA.request)。チャネルが空いていれば、物理層にデータ送信の要求を出す(PD-DATA.request)。ビジーなら、MAC層はSSCSにCHANNEL_ACCESS_FAILUREを入れてMCPS-DATA.confirmを返す。

NO_ACK
MCPS-DATA.requestのtxOptionにAckの有無が指定されています。もしAck返信希望で送信したなら、相手からAckが届くのを待ちます。一定時間経ってもAckが返ってこなければ、データの再送を行います。それでもまだAckが返ってこなければ、再び再送します。送信が成功しない場合は、上記のことを指定された回数繰り返します。指定回数行っても、Ackが届かない場合は、MAC層はSSCSにNO_ACKをstatusの中に入れて返信します。

INVALID_PARAMETER
MCPS_DATA.requestのパラメータのどれかが、定義外の設定だった場合は、statusにINVALID_PARAMETERを格納する。

などがあります。上記以外にも 数種類のエラーコードが定義されています。



送信データが受信側に届くと、受信側のMAC層はSSCSにMCPS-DATA.indicationをします。

MCPS-DATA.indication

データを送信機かた受信したら、MAC層はSSCSに向けて到着を通知します(MCPS-DATA.indication)。パラメータは以下にようになっています。

MCPS-DATA.indication (
srcAddrMode
srcPanID
srcAddr
dstAddrMode
dstPanID
dstAddr
msduLength
msdu
mpduLinkQuality
securityUse
aclEntry
)

MCPS-DATA.requestと内容がよく似ていますが、パラメータ最後の方の部分が少し異なります。

mpduLinkQuality
PD-DATA.indicationが送られてきた際に、PSDU(Phy Service Data Unit：物理層ペイロード)とともにLQI(Link Quality Indication：リンク品質指数)が送られてきます。

securityUse
MCPS-DATA.requestのtxOptionでセキュリティ有無が指定されています。送信側のMAC層で物理層に渡す際に、MPDU(MAC Protocol Data Unit：MAC層フレーム)を完成させるという話をしました。そしてセキュリティ有無は、MAC層ヘッダーの一部であるフレームコントロールの一部として、セットされます。受信側で、このフレームコントロール中のセキュリティ有無を読み取って、SSCSに渡します。有無の二択なので、"TRUE "or "FALSE"が入ります。

ACLEntry
ACLとはAccess Control Listの略です。名前から想像できる通り、アクセスの許可が記されたテーブルです。あるデバイスがどのデバイスからのフレームを受け取ってよいのかが分かります。セキュリティ目的で使用されます。






以上でMAC層データサービスの一つである"MCPS-DATA"の説明は終わりです。
次はもう一つのMAC層データサービス(MCPS-PERGE)について説明します。





IEEE802.15.4　MCPS-PURGE

このデータサービスはオプション機能で、"まだ送信していないデータ(MSDU)の送信を取り消すサービス"です。RFD(Reduced Function Device)つまりエンドポイントになるデバイスは、実装の否かを開発の段階で選択することが出来ます。

MCPS-PURGE.request

MAC層は、SSCSから送信取り消し要求を受け取る場合があります(MCPS-PURGE.request)。パラメータは以下になっています。

MCPS-PURGE.request (
msduHandle
)

この要求を受け取ったら、MAC層は自分が保持しているトランザクションキューから、指定されたハンドルを探します。もし見つかれば、そのハンドルが示すMSDUをトランザクションキューから削除します。マッチするMSDUが見つからなければ、その旨を返答します。

MCPS-PURGE.confirm

要求に対し、MAC層は送信を取り消したかどうか結果を報告します。パラメータは以下のようになっています。

MCPS-PURGE.confirm (
msduHandle
status
)

どのデータ(MSDU)を取り消そうとして、結果は成功か失敗かを報告します。なので、statusは"SUCCESS" or "INVALID_HANDLE"のどちらかが入ります。





以上でMAC層データサービスの説明は終了です。


続いて、MAC層管理サービスの説明をします。





IEEE802.15.4 MAC層管理サービス

MAC層管理サービスはMLME : MAC Layer Management Entityと呼ばれています。MLMEにはいくつか種類はあります。

  • MLME-ASSOCIATE
  • MLME-DISASSOCIATE
  • MLME-ORPHAN
  • MLME-GTS
  • MLME-SYNC
  • MLME-SYNC-LOSS
  • MLME-START
  • MLME-BEACON-NOTIFY
  • MLME-POLL
  • MLME-COMM-STATUS
  • MLME-RX-ENABLE
  • MLME-SCAN
  • MLME-GET
  • MLME-SET
  • MLME-RESET

見て分かるように、MLMEはたくさんあります。

続きは、IEEE802.15.4/ZigBee MAC層の役割について(その２)で説明します。





最後まで読んでいただきありがとうございました。

-IoT

Copyright© MasaのITC Life , 2023 All Rights Reserved Powered by STINGER.