3. Classes of Constrained Devices (制約デバイスのクラス)
3. Classes of Constrained Devices (制約デバイスのクラス)
インターネット接続デバイスの圧倒的な多様性にもかかわらず, さまざまなクラスの制約デバイスについて簡潔な用語を持つことは価値があるかもしれません。
この文書では, 表1のクラス指定をデバイス機能の大まかな指標として使用できます:
| 名前 | データサイズ (例: RAM) | コードサイズ (例: Flash) |
|---|---|---|
| Class 0 | << 10 KiB | << 100 KiB |
| Class 1 | ~ 10 KiB | ~ 100 KiB |
| Class 2 | ~ 50 KiB | ~ 250 KiB |
表 1: 制約デバイスのクラス (KiB = 1024バイト)
この文書の執筆時点では, これらの特性は制約デバイス用の商業的に入手可能なチップと設計コアの識別可能なクラスターに対応しています。これらのクラスの境界は時間とともに移動すると予想されますが, ムーアの法則は個人用コンピューティングデバイスよりも組み込み空間では効果が低い傾向があります: トランジスタ数と密度の増加によって利用可能になった利益は, 計算能力の継続的な増加よりも, コストと電力要件の削減に投資される可能性が高くなります。
Class 0 デバイスは非常に制約されたセンサーのようなモートです。メモリと処理能力において非常に厳しく制約されているため, セキュアな方法でインターネットと直接通信するために必要なリソースを持っていない可能性が最も高いです (まれな英雄的で慎重に作成された実装は別として)。Class 0 デバイスは, プロキシ, ゲートウェイ, またはサーバーとして機能するより大きなデバイスの助けを借りてインターネット通信に参加します。Class 0 デバイスは一般的に従来の意味で包括的に保護または管理することはできません。非常に小さなデータセットで事前構成されている可能性が最も高いです (そして, もしあったとしても, まれに再構成されます)。管理目的で, キープアライブ信号に応答し, オン/オフまたは基本的な健康状態の指示を送信できます。
Class 1 デバイスはコードスペースと処理能力においてかなり制約されているため, HTTP, トランスポート層セキュリティ (TLS, Transport Layer Security), 関連するセキュリティプロトコル, およびXMLベースのデータ表現などの完全なプロトコルスタックを使用して他のインターネットノードと簡単に通信することはできません。ただし, 制約ノード用に特別に設計されたプロトコルスタック (UDP上の制約アプリケーションプロトコル (CoAP, Constrained Application Protocol) [COAP] など) を使用し, ゲートウェイノードの助けなしに意味のある会話に参加するのに十分な能力があります。特に, 大規模ネットワークで必要なセキュリティ機能のサポートを提供できます。したがって, IPネットワークに完全に開発されたピアとして統合できますが, プロトコルとアプリケーションの使用において状態メモリ, コードスペース, そしてしばしば電力消費を節約する必要があります。
Class 2 デバイスはより制約が少なく, ノートブックやサーバーで使用されているものと同じプロトコルスタックのほとんどを基本的にサポートできます。ただし, これらのデバイスでさえ, 軽量で効率が最適化されたプロトコルから恩恵を受け, より少ない帯域幅とネットワークリソースを消費することから恩恵を受けることができます。さらに, ネットワーキングにより少ないリソースを使用することで, アプリケーションにより多くのリソースを利用できるようになります。したがって, Class 2 デバイスでより制約されたデバイス用に定義されたプロトコルスタックを使用すると, 開発コストが削減され, 相互運用性が向上する可能性があります。
Class 2 デバイスを大幅に超える機能を持つ制約デバイスが存在します。これらは既存のプロトコルを大部分変更せずに使用できるため, 標準開発の観点からはそれほど要求が厳しくありません。したがって, この文書はClass 2を超える制約クラスを定義する試みは行っていません。これらのデバイスは依然として限られたエネルギー供給によって制約される可能性があります。
制約ノードの能力を検討することに関して, 特にClass 1デバイスの場合, それらがどのタイプのアプリケーションを実行できるか, どのプロトコルメカニズムが最も適しているかを理解することが重要です。メモリやその他の制限のため, 各特定のClass 1デバイスは, その意図された操作に必要ないくつかの選択された機能のみをサポートできる可能性があります。言い換えれば, 実際にサポートできる機能のセットはデバイスタイプごとに静的ではありません: 同様の制約を持つデバイスは異なる機能をサポートすることを選択する可能性があります。Class 2デバイスにはより多くの機能が利用可能であり, より完全な機能セットを提供できる可能性がありますが, それらが実行するアプリケーションのタイプと必要なプロトコル機能についてはまだ評価する必要があります。要件を導き出すためには, ユースケースとアプリケーションおよびネットワークへのデバイスの関与を分析する必要があります。ユースケースは複数のクラスの制約デバイスとより伝統的なインターネットノードを組み合わせる可能性があります。