ネットワークスペシャリスト 試験情報＆徹底解説

a
LPWAのLow Power（省電力） Wide Areaと低（a）電力から、消費がすんなり出てきたのではないでしょうか。
bc
セルラー系はLTEの応用技と覚えておくと、今後困らないのではないでしょうか（後付け）。
「LPWAとは？通信の仕組みや活用事例を紹介｜IoTコラム｜さくらのIoT」とかを見るとよくわかります。

de
920MHzというキーワードだと、
https://www.nw-siken.com/kakomon/01_aki/am2_15.html
とか
https://www.nw-siken.com/kakomon/03_haru/am2_12.html
で勉強された方もいると思いますが、ISMバンドと結びつけたやつはなかったかもしれません。
ただ、eとの兼ね合いで、ISM（Industry（産業）、Science（科学）、Medical（医療）の頭文字で、産業科学医療の分野にて許可なく自由に使える帯域）で、なんで2.4GHzでbluetooth使って電子レンジでブツブツ切れるんだよ、ということから逆算すると、これは要するに電波干渉しているわけで、11b/gで利用される2.4GHz帯がISMバンドであるということを考えれば、ISMだろと行きついたかもしれません（後付け）。まあ、追加されたのは2012年7月25日の話なので、いまさら、な話でしょう、たぶん。
「920MHz帯vs2.4GHz帯（2.4GHz帯と920MHz帯無線モジュールの比較） - MONO-WIRELESS.COM」も参考になります

f
「3GPPとは、かつて各国ごとや地域ごとに行っていた移動通信システムの標準化を、共通の国際標準を策定すべく、各地域の標準化団体が集まって1998年に設立されたプロジェクト」（※）なんですが、知名度が低いので地雷的に仕込んだ問題なんじゃないかと思います。正答率がきわめて低いんじゃないでしょうか。
※：5G標準化動向ウォッチ?3GPPをご存知ですか
小野沢 庸 ノキアソリューションズ&ネットワークス シニアスペシャリスト
2015.06.15

g
IKEv2のシーケンス自体は出ていませんが、令和4年春午後1問2P11でIKEバージョン2（IKEv2）の流れが書いてあるので、勉強した方はIKE_SA_INIT（IKE SAの設定合意・鍵交換）で1巡、IKE_AUTH（接続相手の認証、Child SAの設定合意・鍵交換）で2巡というわけですぐわかったのではないでしょうか。ま、そうでなくとも、4つのメッセージ交換を何往復で、と来れば2しかないだろ、となるのですが。
https://www.nw-siken.com/pdf/04_haru/pm1_2.pdf
設定ってなにを？という方は、平成28年秋午後2問2のP15-16を見てみましょう。
https://www.nw-siken.com/pdf/28_aki/pm2_2.pdf

h
「IPsecルータ1のSPD（Security Policy Database）中のセレクターには、（h）宛てのパケットを受信したとき（・・・）」とあるので、図1を見れば、IPsecルータ1の対向側（IPsecルータ2）の機器はGメーター管理サーバしかないのでGメーター管理サーバです。

i
平成28年午後1問2のP8空欄ウで同じことを聞かれています。
https://www.nw-siken.com/pdf/28_aki/pm1_2.pdf

j
1ヶ月が30日の場合
1回線あたりの基本料金が月額300円
1ヶ月の通信量1,000バイト当たり1円
Gメーター1台当たりの1回の検針時の通信量を100バイトとし、1時間ごとに検針を実施
とくると、100バイト×1日24時間×1ヶ月が30日/1ヶ月の通信量1,000バイト当たり1円=72
これに固定費月額300円を足して、372円。

k
RESTfulアーキテクチャなりリソース指向アーキテクチャでないとダメくさい感じです。リソース指向アーキテクチャは実際マルがついたのかわかりません。
RESTだけだと、自分の自己採点でバツにした点数と同じになったので、たぶんダメなんじゃないでしょうか。左門はOKにしてそうな気がする。
RESTは設計思想で、RFC として標準化されているわけではない（Roy Fieldingの論文やその後の解説や実践に基づいた一定の原則や制約によりある種のデファクトスタンダードとなっている状態）で、先の原則や制約に従った設計を「RESTful」と呼ぶことから、CoAPの実装設計そのものを聞いているという意味では、RESTfulが正解で、RESTはそれ以前の話だろ、と作問者は思ってバツにしている可能性はあります。日本語の問題じゃないか、と思うかもわかりませんが、それがネスペです。
RFC IndexのRFC6690
Constrained RESTful Environments (CoRE) Link Format Z. Shelby [ August 2012 ] (TXT, HTML) (Status: PROPOSED STANDARD) (Stream: IETF, Area: wit, WG: core) (DOI: 10.17487/RFC6690)はある
これをもとに、RESTfulだろ！と言ってきている可能性が高い

• l
  UDPで動作するのだからトランスポート層です。
  https://www.nw-siken.com/kakomon/27_aki/am2_3.html
  
  m
  順不同のイメージは、令和3年春午後1問3設問2（2）のジッタをイメージするとわかりやすいです。
  https://www.nw-siken.com/pdf/03_haru/pm1_3.pdf
  
  n
  重複のイメージは、平成30年秋午後2問1設問2（2）をイメージするとわかりやすいです。
  https://www.nw-siken.com/pdf/30_aki/pm2_1.pdf
  
  o
  日頃async/awaitとかajaxとかやっていればすんなり同期が頭に浮かんできたかと思います
  
  p
  指数バックオフは、CSMA/CDやCSMA/CAのインターバルのアルゴリズムで昔からある古典的な話でしたが（後付け）、実際は指数バックオフでもジッタでランダムにばらけさせるのが主流です。
  これも正答率が低い気がしています
• P18
  「メッセージIDは、要求と応答のメッセージを関連付けるとともに、メッセージの重複を検出するのに使用される。」
  図3から、CON〔0x○○〕に対応してACK〔0x○○〕となることがわかる。
  P19
  「要求したデータと応答されたデータを関連付けるのにトークンが利用される。」
  より、
  ivのACKのメッセージIDは0xbc90なので、CONのメッセージIDが同一なのはiであり、iのトークン値が0x71で同一のACKはviiiである。理由も、トークン値が一致するから、という趣旨で書けば問題ない。
• 下線②「（ii）を受信したサーバはデータを送信できている。」に対するサーバが送信したACKはなにか？という問題で、
  P18
  「メッセージIDは、要求と応答のメッセージを関連付けるとともに、メッセージの重複を検出するのに使用される。」
  図3から、CON〔0x○○〕に対応してACK〔0x○○〕となることがわかる。
  を思い出せば、（ii）はCON〔0xab20〕なので、ACK〔0xab20〕を探せばいい。よってv。
• 下線③「（vii）を受信した機器は、ACKが重複したものであると判断して、対応する処理を行う。」で、受信した機器が重複したACKであると判断する理由と実施する処理はなにか？という話だが、
  （vii）のメッセージIDである0xde10はviでも同一である。
  P18
  「メッセージIDは、要求と応答のメッセージを関連付けるとともに、メッセージの重複を検出するのに使用される。」
  より、メッセージIDが同一であるということを書けばそれでいい。2つのパケットの、という部分をどう書くかは、ACKで表現してもよいとは思っている。
  処理については、平成30年のMQTTのQoS 2と考え方は似ていて、重複とみなしたメッセージを処理しないことを主軸に無視なり廃棄なりすることを書けばそれでよいです。
• 下線④「攻撃者が（i）のClientHelloメッセージの送信元を偽装して送信した場合、TLSサーバはパケットサイズの大きな（ii）のServerhellメッセージを返送することになり、TLSサーバがDDoS攻撃の加害者になるおそれがある。」で、攻撃者が行う偽装の内容と攻撃手法の名称を問われているわけだが、攻撃者が行う偽装の内容は下線③「攻撃者が（i）のClientHelloメッセージの送信元を偽装して送信」とまんま書いているわけであり、送信元IPアドレスを攻撃対象のホスト（機器）のIPアドレスに偽装することを書けばよい。これは、平成26年秋午後1問3設問3（1）の踏み台にされることの類例といえる。
  https://www.nw-siken.com/pdf/26_aki/pm1_3.pdf
  このときはDNSリフレクタ攻撃だったが、これがリフレクション攻撃として言い換えられているだけである。
• 下線⑤「DTLSサーバは、（iii）に添付されたcookieを検査し、cookieが不正な場合は対応する処理を行う。」から、cookieが正しい場合にDTLSサーバが判断できることと、cookieが不正と判断した際にDTLSサーバが行う対応を問われている。
  （i）のClientHelloを送信したDTLSクライアントと（iii）のClientHelloを送信したDTLSクライアントが同一であることになるので、「結果から」「DTLSサーバが判断できること」を「事実レベルに最も近いこと」として「DTLSクライアントが同一である」ことを書くか、そこから踏み込んで「偽装されていないこと」を書くか悩むが、結果としては偽装されていないことを求めていたので、「判断できること」は、事実から1歩進んで導出できることを要求されていると解釈できる。ただし、一応点数的には「DTLSクライアントが同一である」こともマルがついていたように思う。
  
  対応としてハンドシェークに触れる必要があるのは、令和元年秋午後2問2
  https://www.nw-siken.com/pdf/01_aki/pm2_2.pdf
  のP17のディレイドバインディングやSYNクッキーを思い出してほしいが、ハンドシェークを残存させているままではメモリをDTLSサーバが食い続けてしまい、SYN Flood攻撃につながりかねないので、解放しなければならない（当時は特に考えなかったが）。そういう意味では、「ServerHelloメッセージを送出しない」のみでは2/5点くらいの途中点だと思われる。

• まとめて通信が来ると当然サーバにもネットワークにも負荷が集中してしまう。これに似た考え方をしているのが指数バックオフにジッタを入れているのもあるが、平成29年午後2問1
  https://www.nw-siken.com/pdf/29_aki/pm2_1.pdf
  のEDNS-Client-Subnetでのエッジサーバの考え方で、設問3（5）の「Web-Bのサーバ処理能力不足」と「機械とWeb-B間の通信遅延」に対する対策になぜなるのかを理解していれば、本問に応用して負荷集中の抑止という観点で解答を書くことが出来る。
• P15で、「（2）Gメーターは電池で動作させるので、長時間の稼働を可能にすること」を思い出していれば、消費電力の抑制という観点で書くことができる。まあ、元々のCoAPの目的がZigBeeなどの低電力稼働のためのものという理解があれば、ムダに電力を使っている場合じゃないという観点から、どう電力をけちるかという方向性で書けたと思われる。
• HTTP/1.1がTCPで動作することを意識している場合、UDPの特徴を思い出せば、TCPコネクションの確立と終了（解放）の手順が不要であることが思い出せる（平成27年午後2問1設問3（3））ので、TCPでは裏を返せばTCPコネクションの確立と終了の処理が発生し、IPパケットのやりとりが起こることを書けばよい。
• 他人が見えるところでの通信は暗号化したいが、別に他人に見えなければ平文でもよいのだ、という社内用システムのような思考をすれば、P24の図9のように、LPWA閉域接続サービスを経由して閉域網でやりとりするので、CoAP通信を閉域網でやりとりするから、という趣旨で書けばよい。※後付け
• 時刻の誤差が発生するとどうなるかを純粋に書けばそれでいいようなので、測定と送信のタイミングがずれることだけ書けばよかったようである。※後付け
• NTPサーバがY社サービス拠点にあり、GメーターはGメーター管理サーバとしかやりとりしないので、Gメーター管理サーバから現在時刻を取得し、その時刻を用いて時刻補正を行うことを書けばよい。
  これで、CONとかを使って・・・とか具体的な内容に触れると、触れすぎということにもなりかねない。
  令和4年午後1問3設問2（3）では、時刻同期を行うことだけ書いてあり、NTPでやる、とかは触れすぎになってしまうので書いていない。どの程度まで書けばよいかは、こういう問題からも勉強になったりする。