令和7年度 春期 ネットワークスペシャリスト試験 午後II 問題 問2 LPWAとCoAPによるIoT遠隔検針

問2 IoTシステムの設計に関する次の記述を読んで，設問に答えよ。

Y社は，LPガスメーターを製造し，全国のLPガス販売業者に販売している。このたび，Y社では，LPガス販売業者向けにLPガス使用量の遠隔検針サービスを開始することになり，遠隔検針機能をもつY社製LPガスメーター（以下，Gメーターという），Gメーターを管理するサーバなどから構成されるIoTシステムを開発することにした。

IoTシステム開発プロジェクトチームの責任者には，W課長が任命された。W課長は，IoTシステムの要件として次の二つを設定し，プロジェクトチームのメンバーでネットワーク技術者のX主任に，IoTシステムの機能と構成の検討を指示した。
(1) Gメーターは全国に設置されるので，全国規模で提供可能なIoT向けの無線回線を利用すること
(2) Gメーターは電池で動作させるので，長時間の稼働を可能にすること

〔IoT向けの無線技術の調査と無線回線の選定〕

最初に，X主任は，IoT向けの無線技術を調査し，調査結果を次のようにまとめた。

• IoT向けには，LPWA（Low Power Wide Area）と呼ばれる，低a電力の無線通信技術が利用される。
• LPWAは，セルラー系と非セルラー系の二つに大別される。b系にはLoRaWAN，Sigfoxなどがあり，c系にはLTE-M（LTE Cat.M1），NB-IoT（LTE Cat.NB1）などがある。
• LoRaWAN，Sigfoxは，日本ではSub-GHz帯の一つである920 MHz帯を利用する。920 MHz帯はWi-Fiが利用する周波数帯と同様に，dバンドと呼ばれる周波数帯であるが，2.4 GHz帯と比べて電波eの影響が少ない。
• LTE-M，NB-IoTは，fと呼ばれる標準化プロジェクトが作成した技術仕様を基に，通信事業者が全国規模で構築したLTE網でサービスが提供されている。

調査の結果，LTE-Mを利用すれば全国の幅広い地域でIoTシステムを稼働させることができることが分かった。次に，X主任は，LTE-Mを利用したIoT向けのサービスを提供している企業の中からZ社を選定し，Z社のIoT向け通信サービスについて調査することにした。

〔Z社のIoT向け通信サービスの調査〕

Z社のIoT向け通信サービスは，LPWA閉域接続サービスとIPsec VPNを用いて顧客ごとに閉域網を構成する。

Z社のIoT向け通信サービスを利用したときのIoTシステムの構成を図1に示す。

Z社は，GWとルータとの間を専用線で接続し，Z社サービス拠点とY社サービス拠点との間はIPsec VPNで接続することによって，Y社向けの閉域網を構成する。

図1中のIPsecルータ1で動作するIKEv2は，IPsecルータ2との間で，四つのメッセージの交換を g 往復で行い，SAD (Security Association Database) を作成する。IPsecルータ1のSPD (Security Policy Database) 中のセレクターには， h 宛てのパケットを受信したとき，SADを参照してIPsecの処理を行うことが設定されている。

閉域網が構成されることによって，GメーターとIPsecルータ2に接続する予定のGメーター管理サーバとの通信は，プライベートIPアドレスで行うことができる。Gメーターには，通信事業者が契約者を識別する情報を記録している i カードを装着する。

X主任は，Z社のIoT向け通信サービスの利用料を，次の条件を基に試算した。

• Gメーター1台当たりの1回の検針時の通信量を100バイトとし，1時間ごとに検針を実施する。
• 通信費は1か月の通信量1,000バイト当たり1円とし、Gメーターごとに割り当てる1回線当たりの基本料金は月額300円とする。

この条件から、Z社のIoT向け通信サービスを利用すると、1か月が30日の場合、Gメーター1台当たりの検針に必要な1か月の利用料は j 円なので、LPガス販売業者向けに安価な遠隔検針サービスを提供できることが分かった。

次にX主任は、GメーターとGメーター管理サーバとの間でデータを送受信するための通信プロトコルを検討した。IoT向けの通信プロトコルには、RFC 7252で標準化されたCoAP (Constrained Application Protocol) とOASIS標準メッセージングプロトコルであるMQTT (Message Queuing Telemetry Transport) がある。CoAPは、WebシステムにおけるAPIの形式である k アーキテクチャを採用しているので、Web技術でIoTシステムを構築する場合に適している。そこで、X主任は、CoAPについて調査した。

〔CoAPの調査〕

CoAPは、伝送効率を考慮して標準ではUDPを利用し、データの保護が必要な場合は、RFC 9147で標準化されたDTLS (Datagram TLS) を利用することができる。

CoAPのメッセージ形式を図2に示す。

CoAPでは、確認が必要なメッセージ（以下、CONという）、確認が不要なメッセージ（以下、NONという）、確認応答メッセージ（以下、ACKという）、リセットメッセージの4種類が定義されており、図2中のタイプでメッセージ種類を指定する。CoAPサーバ及びCoAPクライアントは、CONを受信したときはACKを返送し、NONを受信したときはACKを返送しない。

図2中のコードは，要求の場合，メソッドコードを示し，応答の場合，レスポンスコードを示す。メソッドコードを表1に，レスポンスコードを表2に示す。

メッセージIDは，要求と応答のメッセージを関連付けるとともに，メッセージの重複を検出するのに使用される。CoAPは，l層のプロトコルであるUDP上での動作を前提としている。通信品質の劣るネットワークなどでは，パケットがmで到着したり，nして出現したり，通知なしに消失したりすることがあるので，CoAPは，メッセージIDを利用することによって，送受信が正しく行われるための仕組みを実装している。

トークンは，要求した情報と応答された情報を関連付けるために使用される。CoAPクライアントはトークンの値によって，どの要求に対して応答された情報なのかを判断する。

CONとACKを用いた通信例を図3に示す。

図3中の(i)では，CoAPクライアントは，CONに対して返送されたACKによって，CONがCoAPサーバに到達して処理されたことが分かることを示している。CoAPでは，図3中の(i)に示したように，ACKの受信を待たずに連続してCONを送信することができる，非o通信が行われる。

(ii)では，ACK不達時に，CONの再送によってCON又はACKを確実に到達させることを示している。(ii)に示したように，CoAPクライアントはCONを送信後，デフォルトのタイムアウト時間であるaの時間ACKの受信を待ち，ACKが受信できなかった場合は，指数pと呼ばれる方式で算出したbの時間経過後にCONを再送する。図3で示したように，CoAPでは，CONに対するACKの返送及びCONの再送によって，パケットロスなどが発生するネットワークを利用した場合も，確実な通信を行うことができる。

IoT向けの機器は，サーバにデータの提供を要求する場合がある。このような場合，要求したデータと応答されたデータを関連付けるのにトークンが利用される。

機器がサーバにデータの提供を要求したときのトークンの使用例を図4に示す。

図4では，機器がサーバ宛てのCONの中で，提供を求めるデータに0x10という値のトークンを指定している。この要求を受信したサーバは，提供するデータに0x10という値のトークンを付与して応答する。機器は，トークン値から要求したデータとしてデータAが回答されたことを知ることができる。

図4中のACKには，Contentのデータも含まれている。このように，CoAPでは，ACKにContentのデータを加えて送信する，ピギーバックと呼ばれる応答方式が利用される。

機器が連続してサーバに異なるデータの提供を要求する場合もある。
機器が連続してサーバに異なるデータの提供を要求したときの応答例を図5に示す。

図5中の①(iv)は，サーバが要求を受信したときにデータをすぐに送信できない場合の応答である。②(ii)を受信したサーバはデータを送信できている。(vii)は，ネットワーク上の何らかの原因によって，(vi)と重複したACKが機器に到達したことを示している。③(vii)を受信した機器は，ACKが重複したものであると判断して，対応する処理を行う。

CoAP通信で，データの保護が必要な場合はDTLSを利用する。DTLSは，TCP通信のアプリケーション層のデータを暗号化するTLSの機能をUDPに適用した技術である。

DTLSバージョン1.3（以下，DTLS 1.3という）は，TLSバージョン1.2（以下，TLS 1.2という）と異なった方法でClientHelloメッセージの送信を求める。
TLS 1.2とDTLS 1.3のハンドシェークの違いを図6に示す。

図6中の(1)に示したTLS 1.2のハンドシェークをUDP上で行うと，④攻撃者が(i)のClientHelloメッセージの送信元を偽装して送信した場合，TLSサーバはパケットサイズの大きな(ii)のServerHelloメッセージを返送することになり，TLSサーバがDDoS攻撃の加害者になるおそれがある。この攻撃に対処するために，(2)に示したDTLS 1.3のハンドシェークでは，(i)のClientHelloメッセージを受信したDTLSサーバが，(ii)のHelloRetryRequestメッセージにcookieを添付して送信する。(ii)を受信したDTLSクライアントは，受信したcookieを添付した(iii)のClientHelloメッセージを再度送信する。⑤DTLSサーバは，(iii)に添付されたcookieを検査し，cookieが不正な場合は対応する処理を行う。

無線回線の選定及びGメーターとY社拠点に導入するGメーター管理サーバとの間で利用するCoAPの調査が終わったので，X主任は，IoTシステムの機能と構成の検討に取り掛かった。

〔IoTシステムの機能と構成の検討〕

まず，X主任は，Gメーター開発技術者からGメーターが送受信できる情報の説明を受け，次の2点の主要な機能を実現するための方式を検討した。

(1) 遠隔検針
(2) 異常通知

Gメーター管理サーバは数万台のGメーターを管理することを前提に，GメーターでCoAPクライアント機能を，Gメーター管理サーバでCoAPサーバ機能を動作させることにした。

X主任が考えた，Gメーターの動作を次に示す。

(1)について，Gメーターは1時間ごとにLPガスの流量積算値を測定して，測定時刻と測定値（以下，測定データという）をメモリに記録し，毎日午前0時の測定の後，⑥ランダムな時間経過後に，前日に測定した1時間ごとの測定データを24回に分けてGメーター管理サーバに送信する。⑦LPガスの流量積算値の測定又は測定データ送信後，次の測定を行う時刻までの間は，Gメーターはスリープ状態になる。

(2)について，Gメーターはウェイクアップして測定を行うタイミングを利用して，Gメーター自身の稼働状態をチェックし，異常を検知したときに異常内容をGメーター管理サーバに送信する。

X主任は，Gメーターの動作を基に，GメーターとGメーター管理サーバとの間の通信方法をまとめた。GメーターとGメーター管理サーバとの間の通信の概要を図7に，Gメーターによる測定と測定データの送信タイミングを図8に示す。

図7中の(1)及び図8に示したように，Gメーターは，毎日午前0時の測定を行った後，1時までの間のランダムな時間経過後に，1時間ごとに記録した1日分24件の測定データを，それぞれPOSTメソッドでGメーター管理サーバに送信する。これによって，図7中の(1)では，GメーターがPOSTメソッドを24回発行することになる。
⑧CoAPでやり取りされるIPパケットの数は，HTTPバージョン1.1を利用して同様の方法で測定データを送信する場合と比べると少ないので，測定データの通信時間は短くて済む。

図7で示したCoAP通信でDTLSを利用すると，Gメーターで実施する通信処理の負荷が，Gメーターの性能に影響を与えるおそれがある。そこで，X主任は，⑨今回開発するIoTシステムでは，DTLSを利用しなくてもCoAP通信のセキュリティは確保されると判断し，DTLSは利用しないことにした。

Gメーターは図8に示した動作を行うので，時計機能の実装が必要になる。Gメーターに精度の高いリアルタイムクロックを実装しても，⑩Gメーターを長時間稼働させると時刻の誤差が無視できないほど大きくなるおそれがある。そこで，X主任は，⑪Gメーターに時刻の誤差を抑えるための処理を組み込むことにした。

これらの検討を基に，X主任は，IoTシステムの構成を設計した。X主任が設計したIoTシステムの構成を図9に示す。

図9中のY社サービス拠点のサーバは，NTPサーバとの間で時刻同期を行う。

Gメーター管理サーバは，全Gメーターから1日分の測定データを受信した後に，2時からGメーターごとにLPガス消費量などを集計する。集計したデータはLPガス販売業者別に情報提供サーバに送信される。情報提供サーバは，受信した情報をLPガス販売業者向けに公開する。

Gメーターから送信される異常情報は，Gメーター管理サーバを介して情報提供サーバに送信される。情報提供サーバは，LPガス販売業者宛ての異常通知メールを作成し，メールサーバに送信する。

IoTシステムの機能と構成の検討が完了したので，X主任は，検討結果をW課長に報告した。W課長は，報告内容を基に，IoTシステム開発の概要を経営会議で提案した。提案内容が承認され，IoTシステム開発プロジェクトが本格的に開始されることになった。