NWネットワークスペシャリスト試験 午後Ⅱ

令和7年度春期 ネットワークスペシャリスト 午後Ⅱ 問2

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問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帯の一つである920MHz帯を利用する。920MHz帯はWi-Fiが利用する周波数帯と同様に,[d]バンドと呼ばれる周波数帯であるが,2.4GHz帯と比べて電波[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に示す。 図1 Z社のIoT向け通信サービスを利用したときのIoTシステムの構成(抜粋) 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に示す。 図2 CoAPのメッセージ形式 CoAPでは,確認が必要なメッセージ(以下,CONという),確認が不要なメッセージ(以下,NONという),確認応答メッセージ(以下,ACKという),リセットメッセージの4種類が定義されており,図2中のタイプでメッセージ種類を指定する。CoAPサーバ及びCoAPクライアントは,CONを受信したときはACKを返送し,NONを受信したときはACKを返送しない。 図2中のコードは,要求の場合,メソッドコードを示し,応答の場合,レスポンスコードを示す。メソッドコードを表1に,レスポンスコードを表2に示す。 表1 メソッドコード(抜粋) 表2 レスポンスコード(抜粋) メッセージIDは,要求と応答のメッセージを関連付けるとともに,メッセージの重複を検出するのに使用される。CoAPは,[l]層のプロトコルであるUDP上での動作を前提としている。通信品質の劣るネットワークなどでは,パケットが[m]で到着したり,[n]して出現したり,通知なしに消失したりすることがあるので,CoAPは,メッセージIDを利用することによって,送受信が正しく行われるための仕組みを実装している。 トークンは,要求した情報と応答された情報を関連付けるために使用される。CoAPクライアントはトークンの値によって,どの要求に対して応答された情報なのかを判断する。 CONとACKを用いた通信例を図3に示す。 図3 CONとACKを用いた通信例 図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 機器がサーバにデータの提供を要求したときのトークンの使用例 図4では,機器がサーバ宛てのCONの中で,提供を求めるデータに0x10という値のトークンを指定している。この要求を受信したサーバは,提供するデータに0x10という値のトークンを付与して応答する。機器は,トークン値から要求したデータとしてデータAが回答されたことを知ることができる。 図4中のACKには,Contentのデータも含まれている。このように,CoAPでは,ACKにContentのデータを加えて送信する,ピギーバックと呼ばれる応答方式が利用される。 機器が連続してサーバに異なるデータの提供を要求する場合もある。 機器が連続してサーバに異なるデータの提供を要求したときの応答例を図5に示す。 図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 TLS 1.2とDTLS 1.3のハンドシェークの違い 図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 GメーターとGメーター管理サーバとの間の通信の概要 図8 Gメーターによる測定と測定データの送信タイミング 図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 X主任が設計したIoTシステムの構成(抜粋) 図9中のY社サービス拠点のサーバは,NTPサーバとの間で時刻同期を行う。 Gメーター管理サーバは,全Gメーターから1日分の測定データを受信した後に,2時からGメーターごとにLPガス消費量などを集計する。集計したデータはLPガス販売業者別に情報提供サーバに送信される。情報提供サーバは,受信した情報をLPガス販売業者向けに公開する。 Gメーターから送信される異常情報は,Gメーター管理サーバを介して情報提供サーバに送信される。情報提供サーバは,LPガス販売業者宛ての異常通知メールを作成し,メールサーバに送信する。 IoTシステムの機能と構成の検討が完了したので,X主任は,検討結果をW課長に報告した。W課長は,報告内容を基に,IoTシステム開発の概要を経営会議で提案した。提案内容が承認され,IoTシステム開発プロジェクトが本格的に開始されることになった。 設問1 本文中の[a]~[f]に入れる適切な字句を答えよ。 設問2 本文中の[g]~[k]に入れる適切な字句又は数字を答えよ。 設問3 〔CoAPの調査〕について答えよ。 (1) 本文中の[l]~[p]に入れる適切な字句を答えよ。 (2) 本文中の下線①について,(iv)で送信できなかったデータが送信されるメッセージを,図5中の(i)~(ix)で答えよ。また,そのメッセージが(i)の要求に対する応答であると判断できる理由を,15字以内で答えよ。 (3) 本文中の下線②について,サーバが送信したACKを,図5中の(i)~(ix)で答えよ。 (4) 本文中の下線③について,受信した機器が重複したACKであると判断する理由及び実施する処理を,それぞれ30字以内で答えよ。 (5) 本文中の下線④について,攻撃者が行う偽装の内容を,40字以内で具体的に答えよ。また,その攻撃は,複数のDDoS攻撃の手法の中で,何と呼ばれる手法の攻撃か。攻撃名を答えよ。 (6) 本文中の下線⑤について,cookieが正しい場合にDTLSサーバが判断できることを,30字以内で答えよ。また,cookieが不正のものであると判断した場合にDTLSサーバが行う対応を,30字以内で答えよ。 設問4 〔IoTシステムの機能と構成の検討〕について答えよ。 (1) 本文中の下線⑥について,測定データの送信をランダムの時間控えることによる効果を,35字以内で答えよ。 (2) 本文中の下線⑦について,スリープ状態になることによる効果を,25字以内で答えよ。 (3) 本文中の下線⑧について,HTTPバージョン1.1を利用した場合,やり取りするIPパケットの数が多くなる理由を,35字以内で答えよ。 (4) 本文中の下線⑨について,DTLSを利用しなくてもセキュリティが確保されると判断した理由を,30字以内で答えよ。 (5) 本文中の下線⑩について,時刻の誤差によって発生する問題を,30字以内で答えよ。 (6) 本文中の下線⑪について,時刻の誤差を抑えるために考えられる,CoAP通信を利用した処理の内容を,40字以内で答えよ。
図1 Z社のIoT向け通信サービスを利用したときのIoTシステムの構成(抜粋)。複数のGメーターがLTE-MでZ社のLPWA閉域接続サービスに接続する構成図。GWからZ社サービス拠点のルータ、IPsecルータ1を経てインターネットに入り、Y社サービス拠点のIPsecルータ2とGメーター管理サーバにつながる。GWの説明と注記がある。
図1 Z社のIoT向け通信サービスを利用したときのIoTシステムの構成(抜粋)。複数のGメーターがLTE-MでZ社のLPWA閉域接続サービスに接続する構成図。GWからZ社サービス拠点のルータ、IPsecルータ1を経てインターネットに入り、Y社サービス拠点のIPsecルータ2とGメーター管理サーバにつながる。GWの説明と注記がある。
図2 CoAPのメッセージ形式。CoAPメッセージの形式を示す図。ビット0〜31の範囲に、Ver(2ビット)、T(2ビット)、TKL(4ビット)、コード(8ビット)、メッセージID(16ビット)が並び、その後にトークン、オプション、アプリケーションのデータなどが続く。注記は先頭4バイトが固定長ヘッダーであることを示す。
図2 CoAPのメッセージ形式。CoAPメッセージの形式を示す図。ビット0〜31の範囲に、Ver(2ビット)、T(2ビット)、TKL(4ビット)、コード(8ビット)、メッセージID(16ビット)が並び、その後にトークン、オプション、アプリケーションのデータなどが続く。注記は先頭4バイトが固定長ヘッダーであることを示す。
表1 メソッドコード(抜粋)。CoAPのメソッドコードの表。0.01はGETで指定したリソースを取得し、0.02はPOSTで指定したリソースを作成し、0.04はDELETEで指定したリソースを削除する。
表1 メソッドコード(抜粋)。CoAPのメソッドコードの表。0.01はGETで指定したリソースを取得し、0.02はPOSTで指定したリソースを作成し、0.04はDELETEで指定したリソースを削除する。
表2 レスポンスコード(抜粋)。CoAPのレスポンスコードの表。2.01 Createdはリソースの作成、2.02 Deletedはリソースの消去、2.05 Contentはリソースの取得を表し、いずれもリクエストが正常に処理されたことを示す。
表2 レスポンスコード(抜粋)。CoAPのレスポンスコードの表。2.01 Createdはリソースの作成、2.02 Deletedはリソースの消去、2.05 Contentはリソースの取得を表し、いずれもリクエストが正常に処理されたことを示す。
図3 CONとACKを用いた通信例。(i)はCoAPクライアントがサーバ1とサーバ2へCON 0x7d34と0x75f0を連続送信し、それぞれACKを受ける例。(ii)はACKが届かず、時間aとbの経過後にCON 0x81abを再送してACKを受ける例。0xとメッセージIDに関する注記がある。
図3 CONとACKを用いた通信例。(i)はCoAPクライアントがサーバ1とサーバ2へCON 0x7d34と0x75f0を連続送信し、それぞれACKを受ける例。(ii)はACKが届かず、時間aとbの経過後にCON 0x81abを再送してACKを受ける例。0xとメッセージIDに関する注記がある。
図4 機器がサーバにデータの提供を要求したときのトークンの使用例。機器がサーバへCON [0x1234] GET /data(トークン0x10)を送る。サーバはACK [0x1234] 2.05 Content(トークン0x10)でデータAを返し、同じトークンで要求と応答を関連付けるシーケンス図。
図4 機器がサーバにデータの提供を要求したときのトークンの使用例。機器がサーバへCON [0x1234] GET /data(トークン0x10)を送る。サーバはACK [0x1234] 2.05 Content(トークン0x10)でデータAを返し、同じトークンで要求と応答を関連付けるシーケンス図。
図5 機器が連続してサーバに異なるデータの提供を要求したときの応答例。(i)~(iii)で機器がdata1~3をトークン0x71、0x82、0x90付きのCONで要求する。(iv)は空のACK、(v)と(vi)はContent付きACK、(vii)は(vi)の複製である。(viii)はサーバからのCONでデータZ(トークン0x71)を送り、(ix)は機器のACK。複製の注記がある。
図5 機器が連続してサーバに異なるデータの提供を要求したときの応答例。(i)~(iii)で機器がdata1~3をトークン0x71、0x82、0x90付きのCONで要求する。(iv)は空のACK、(v)と(vi)はContent付きACK、(vii)は(vi)の複製である。(viii)はサーバからのCONでデータZ(トークン0x71)を送り、(ix)は機器のACK。複製の注記がある。
図6 TLS 1.2とDTLS 1.3のハンドシェークの違い。(1)TLS 1.2では、ClientHelloの直後にServerHelloが返る。(2)DTLS 1.3では、(i)ClientHello、(ii)HelloRetryRequest + cookie、(iii)ClientHello + cookie、(iv)ServerHelloの順に送られる。以降は省略されている。
図6 TLS 1.2とDTLS 1.3のハンドシェークの違い。(1)TLS 1.2では、ClientHelloの直後にServerHelloが返る。(2)DTLS 1.3では、(i)ClientHello、(ii)HelloRetryRequest + cookie、(iii)ClientHello + cookie、(iv)ServerHelloの順に送られる。以降は省略されている。
図7 GメーターとGメーター管理サーバとの間の通信の概要。(1)遠隔検針では、GメーターがCONのPOSTで0時・1時…23時の測定データを送り、管理サーバが2.01 CreatedのACKを返す。(2)異常通知では、CON [0x1234] POST /異常情報を送り、2.01 CreatedのACKを受ける。
図7 GメーターとGメーター管理サーバとの間の通信の概要。(1)遠隔検針では、GメーターがCONのPOSTで0時・1時…23時の測定データを送り、管理サーバが2.01 CreatedのACKを返す。(2)異常通知では、CON [0x1234] POST /異常情報を送り、2.01 CreatedのACKを受ける。
図8 Gメーターによる測定と測定データの送信タイミング。Gメーターが1時~23時、0時、1時、2時の毎時に測定を行い、0時の測定後から1時までの間にGメーター管理サーバへ測定データを複数回送信するタイミングを示すタイムチャート。凡例に測定と測定データの送信の記号がある。
図8 Gメーターによる測定と測定データの送信タイミング。Gメーターが1時~23時、0時、1時、2時の毎時に測定を行い、0時の測定後から1時までの間にGメーター管理サーバへ測定データを複数回送信するタイミングを示すタイムチャート。凡例に測定と測定データの送信の記号がある。
図9 X主任が設計したIoTシステムの構成(抜粋)。Gメーターh1~hzがLTE-MでLPWA閉域接続サービスに接続し、GW、Z社拠点のルータ、IPsecルータ1、インターネットを経てY社拠点のIPsecルータ2とGメーター管理サーバにつながる。FW配下のDMZには情報提供、メール、NTPの各サーバとL2SWがある。LPガス販売業者の管理用PCと注記も示す。
図9 X主任が設計したIoTシステムの構成(抜粋)。Gメーターh1~hzがLTE-MでLPWA閉域接続サービスに接続し、GW、Z社拠点のルータ、IPsecルータ1、インターネットを経てY社拠点のIPsecルータ2とGメーター管理サーバにつながる。FW配下のDMZには情報提供、メール、NTPの各サーバとL2SWがある。LPガス販売業者の管理用PCと注記も示す。
解き方のヒントを見る

判断の前提と目的のつながりを確認

この分野を学ぶときは、個々の用語から結論を急がず、判断の前提が何かを整理しましょう。ある説明が成り立つ条件と、その説明で達成したい目的とのつながりに注目すると、考える範囲を定めやすくなります。

この問題で問われていること

考える際には、自分が置いている前提と、扱っている目的が対応しているかを確認してください。明示された条件と自分で補った条件を区別し、その前提を採用する理由を言葉にして、判断の根拠を整理しましょう。

視点

判断の前提と目的のつながりに注目します。前提を無意識に付け足していないか、その前提が目的にどう関わるのかを、自分の言葉で説明できるか点検しましょう。

確認ポイント

  • 考える目的を整理したか
  • 与えられた条件と自分の仮定を区別したか
  • 前提と目的のつながりを説明できるか
正解と解説を見る

解説

全国の電池駆動メーターによる遠隔検針を実現するため、LPWAの選択、CoAPの応答・再送・重複検出、DTLSの攻撃対策を理解し、閉域網、負荷分散、省電力、時刻補正を設計に結び付ける問題です。

問題の全体像

Y社は、全国に設置される電池駆動のGメーターから検針データを収集するIoTシステムを計画している。全国で利用できる無線回線と長時間稼働が主要な要件であり、LTE-M、閉域網、CoAPを組み合わせて実現する。出題趣旨では、LPWAによる無線回線の選択、CoAPの利用検討、情報セキュリティ対策にネットワークの知識を活用できるかを問うとしている。通信図の読み取りに加え、負荷、電力、時刻の管理を要件と関連付けることが重要です。

設問1(a)

公式解答例では「消費」。本文の「低[a]電力」と、Gメーターを電池で長時間動作させる要件に着目する。LPWAのLow Powerは、通信に伴う消費電力を低く抑える特性を表しており、「低消費電力」となる。

設問1(b)

公式解答例では「非セルラー」。本文はLPWAをセルラー系と非セルラー系に分類し、その具体例を並べている。LoRaWANとSigfoxが属するのは非セルラー系であり、次のLTE-M、NB-IoTとの対比で整理する。

設問1(c)

公式解答例では「セルラー」。LTE-MとNB-IoTについて、通信事業者が全国規模で構築したLTE網を利用すると説明されている。この移動体通信網を利用する点から、セルラー系のLPWAと判断する。全国対応というシステム要件にもつながる分類です。

設問1(d)

公式解答例では「ISM」。本文の「Wi-Fiが利用する周波数帯と同様に」という記述が着眼点となる。採点講評では、Wi-Fiなどが利用する2.4GHz帯と920MHz帯がISM(Industrial Scientific and Medical)バンドに割り当てられていることを学習事項として挙げている。

設問1(e)

公式解答例では「干渉」。本文は920MHz帯と2.4GHz帯を比較し、「電波[e]の影響が少ない」と述べている。ここでは、ほかの無線通信の電波が通信に影響を与える現象を指すので、「電波干渉」となる。伝搬距離ではなく、周波数帯の利用に伴う干渉の比較を読み取る。

設問1(f)

公式解答例では「3GPP」。問われているのは、LTE-MとNB-IoTの技術仕様を作成する標準化プロジェクトです。採点講評でも、LTEなどの移動体通信の技術仕様が3GPPで作成されることを覚えておくよう述べている。通信サービスを提供する事業者と、仕様を作成する組織を区別する。

設問2(g)

公式解答例では「2」。本文に、IKEv2が四つのメッセージを交換すると明記されている。要求と応答の二つのメッセージで1往復となるので、四つのメッセージは2往復に当たる。メッセージ数と往復数を区別して数える。

設問2(h)

公式解答例では「Gメーター管理サーバ」。図1で、Gメーターから送られる検針データの宛先を追うと、Y社サービス拠点の管理サーバに到達する。IPsecルータ1のSPDには、この宛先への通信をIPsecで保護する方針を設定する。宛先として答える対象は、VPNの終端であるIPsecルータ2ではなく、通信先の管理サーバです。

設問2(i)

公式解答例では「SIM」。本文の「通信事業者が契約者を識別する情報を記録している」「カードを装着する」という説明に着目する。LTE-Mを利用するGメーターに、契約者の識別情報を保持するSIMカードを装着するという意味です。

設問2(j)

公式解答例では「372」。1時間ごとの検針なので、30日間の検針回数は24×30=720回。1回100バイトから月間通信量は72、000バイトとなり、通信費は72、000÷1、000×1=72円です。これに1回線の月額基本料金300円を加え、利用料は372円となる。

設問2(k)

公式解答例では「RESTful」。本文の「WebシステムにおけるAPIの形式」と、表1のGET、POST、DELETEに着目する。指定したリソースに対して取得、作成、削除を行う構成が、RESTfulアーキテクチャとの対応を示している。空欄には公式解答例の表記である「RESTful」を入れる。

設問3(1)(l)

公式解答例では「トランスポート」。空欄はCoAPの層ではなく、CoAPが利用するUDPの層を問うている。UDPはトランスポート層のプロトコルであり、本文はその上でCoAPが動作すると説明している。修飾されている語がUDPであることを確認する。

設問3(1)(m)

公式解答例では「順不同」。本文は、通信品質の劣るネットワークで起こり得るパケットの到着状況を列挙している。送信した順序どおりに届かない状態を指して「順不同で到着」となる。UDP上では、到着順序の乱れも考慮して上位の通信処理を設計する必要がある。

設問3(1)(n)

公式解答例では「重複」。本文の「[n]して出現」は、同じパケットが複数回到着する現象を指します。図5の(vi)と(vii)にも、ネットワーク上で複製された同じACKが示されている。このような重複を検出するためにメッセージIDが使われる。

設問3(1)(o)

公式解答例では「同期」。図3(i)では、一つ目のCONに対するACKを受信する前に、別のサーバへ次のCONを送信している。応答を待たずに次の送信へ進める通信なので「非同期通信」となる。空欄の前に「非」があるため、記入する語は「同期」です。

設問3(1)(p)

公式解答例では「バックオフ」。図3(ii)と本文の再送待ち時間の説明から、「指数バックオフ」という方式を答える。再送までの待ち時間を指数的に増やし、再送が集中する状況を緩和して通信の成功を図る。採点講評でも、この技術がイーサネットでも利用されることに触れ、学習を促している。

設問3(2)(メッセージ)

公式解答例では「(viii)」。図5の(iv)はメッセージIDが0xbc90のACKで、Contentのデータを含んでいない。その後、(viii)でサーバから「データZ」が送られ、トークンは(i)と同じ0x71となっている。要求の受信確認を先に返し、準備できたデータを別のCONで送信する流れを読み取る。

設問3(2)(理由)

公式解答例では「トークン値が一致するから」。図5の(i)と(viii)のトークンはいずれも0x71です。一方、メッセージIDは0xbc90と0xcdf2で異なる。別のメッセージとして送られるデータ応答と元の要求を関連付けるのはトークンであり、15字以内ではその一致を理由として示す。

設問3(3)

公式解答例では「(v)」。図5の(ii)は、メッセージIDが0xab20、トークンが0x82のGET要求です。(v)のACKは同じメッセージIDとトークンを持ち、2.05 Contentとして「データX」を含んでいる。要求の確認応答とデータ応答を一つのACKにまとめるピギーバックの例です。

設問3(4)(理由)

公式解答例では、二つのパケットのメッセージIDが同じであることを理由としている。図5の(vi)と(vii)はいずれもメッセージIDが0xde10であり、本文はメッセージIDを重複検出に使用すると説明している。30字以内の答案では「二つのACKのメッセージIDが同じだから。」と要点を示せる。

設問3(4)(処理)

公式解答例では、受信した(vii)のACKは処理済みなので無視するとしている。(vi)で同じACKを既に処理しているため、(vii)を再びデータ処理に回す必要はない。30字以内では「受信した(vii)のACKは処理済みなので無視する。」と、重複を検出した後の処理を答える。

設問3(5)(内容)

公式解答例では、送信元IPアドレスを攻撃対象ホストのIPアドレスに偽装するとしている。図6の説明では、サーバがClientHelloの送信元に大きな応答を返す点が攻撃に利用される。40字以内では「送信元IPアドレスを攻撃対象ホストのIPアドレスに偽装する。」と、書き換える情報と偽装先を具体的に示す。

設問3(5)(攻撃名)

公式解答例では「リフレクション」。攻撃者は攻撃対象のIPアドレスを送信元に設定し、サーバからの応答を攻撃対象へ向かわせる。第三者のサーバを介して応答を送り付ける仕組みが、リフレクションに当たる。本文には応答サイズが大きいことも示されているが、攻撃名は公式解答例の名称を押さえる。

設問3(6)(判断できること)

公式解答例では、(i)の送信元が偽装されていないことを判断できるとしている。図6では、サーバが送信元へ返したcookieを、クライアントが受け取って(iii)に付けて送り返す。正しいcookieの返送は、その送信元で応答を受信できたことの確認になる。30字以内では「(i)の送信元が偽装されたものでないこと。」と示す。採点講評でも、この確認の仕組みから導くことを求めている。

設問3(6)(対応)

公式解答例では、(iv)を送信せず、ハンドシェークを終了するとしている。cookieが不正なら、送信元の確認が成立していないため、図6の(iv)のServerHelloへ進めない。30字以内では「(iv)を送信せず、ハンドシェークを終了する。」と、送信しないメッセージと終了処理を示します。

設問4(1)

公式解答例では、Gメーター管理サーバやネットワークへの負荷の集中を避けられるとしている。数万台のGメーターが午前0時の測定後に送信するため、同時に通信すると処理と通信の負荷が集中する。送信開始を0時から1時の間に分散する効果を答える。35字以内では「管理サーバやネットワークへの負荷の集中を避けられる。」とまとめられる。

設問4(2)

公式解答例では、Gメーターの消費電力を抑えられるとしている。測定や送信が終わった後、次の測定までスリープする動作は、電池で長時間稼働させる要件に対応する。25字以内では「Gメーターの消費電力を抑えられる。」と、スリープによる直接の効果を示します。

設問4(3)

公式解答例では、TCPコネクションの確立と切断の処理が行われることを理由としている。本文のCoAPはUDPを利用する一方、HTTP/1.1ではTCPを利用するため、接続管理のためのパケットが加わる。35字以内では「TCPコネクションの確立と切断の処理が行われるから。」と示す。採点講評でも、UDPにはない確立・切断のパケットに着目するよう述べている。

設問4(4)

公式解答例では、CoAP通信がY社向けの閉域網の中で行われることを理由としている。図1と図9では、LPWA閉域接続サービス、専用線、IPsec VPNによってGメーターと管理サーバを結んでいる。30字以内では「CoAP通信はY社向けの閉域網内で行われるから。」と答える。インターネットを経由する区間にもIPsec VPNを利用するという、本事例の構成を根拠にする。

設問4(5)

公式解答例では、測定と送信が誤った時刻に行われることになるとしている。図8では毎時の測定と、午前0時の測定後から1時までの送信が時計に基づいて実行される。時計の誤差が蓄積すると、これらの動作時刻が実際の時刻からずれる。30字以内では「測定と送信が誤った時刻に行われる。」と、二つの動作への影響を示します。

設問4(6)

公式解答例では、Gメーター管理サーバから現在時刻を取得し、Gメーターの時刻を更新するとしている。図9の説明ではY社拠点のサーバがNTPサーバと時刻同期するため、管理サーバの時刻を補正の基準にできる。設問はCoAP通信を利用した処理を求めているので、40字以内では「Gメーター管理サーバから現在時刻を取得し、自身の時刻を更新する。」と、取得先と更新処理を示します。

学習のポイント

メッセージIDとトークンの役割、cookieによる送信元確認、TCPとUDPの通信処理の違いを重点的に学びます。

出典:独立行政法人 情報処理推進機構(IPA)令和7年度春期 ネットワークスペシャリスト試験 午後Ⅱ 問2(公式資料:問題冊子(PDF) / 解答例 / 採点講評)

関連する過去問一覧

IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針