メインコンテンツまでスキップ

5. 6LoWPAN Routing Requirements (6LoWPANルーティング要件)

本セクションでは、6LoWPANルーティングの要件リストを定義します。低電力ネットワークに特有の重要な設計特性として、LoWPANは以下のような複数のデバイスタイプと役割をサポートする必要があります:

  • 一次電池から電力を供給されるか、エネルギーハーベスティングを使用するホストノード(「電力制約ノード」と呼ばれることもあります)
  • 電源供給されるホストノード(「電力豊富ノード」と呼ばれるものの例)
  • 電力豊富な(ただし必ずしも電源供給されているとは限らない)高性能ゲートウェイ
  • さまざまな機能を持つノード(データアグリゲータ、リレー、ローカルマネージャー/コーディネーターなど)

これらの異なるデバイスタイプと役割により、LoWPANは以下の2つの主要な属性を考慮する必要があります:

  • 電力保存: 一部のデバイスは電源供給されていますが、多くは電池駆動であり、単一のAA電池で数か月から数年持続する必要があります。多くのデバイスはほとんどの時間は電源供給されていますが、長期間(例えば、建設現場で建物の電源が初めて投入される前)にわたって電池で機能する必要があります。

  • 低性能: 小型デバイス、小メモリサイズ、低性能プロセッサ、低帯域幅、高損失率など。

LoWPANのこれらの基本的な属性は、ルーティングソリューションの設計に影響を与えます。既存のルーティング仕様が簡素化および修正されるか、LoWPANの低電力要件に適合するために新しいソリューションが導入されるかにかかわらず、以下に説明する要件を満たす必要があります。

5.1. Support of 6LoWPAN Device Properties (6LoWPANデバイス特性のサポート)​

本セクションに記載されている一般的な目標は、6LoWPANルーティングプロトコルによって満たされるべきです (SHOULD)。各要件の重要性は、プロトコルが実行されているノードタイプとノードの役割に依存します。以下の要件は、LoWPAN内の電池駆動ノードの存在を考慮しています。

[R01] 6LoWPANルーティングプロトコルは、小さなコードサイズでの実装を許可し (SHOULD)、典型的な6LoWPANノード容量に適合するために低いルーティング状態を必要とすべきです (SHOULD)。一般的に、コードサイズは利用可能なフラッシュメモリサイズによって制限され、ルーティングテーブルはRAMサイズによって制限され、32エントリ未満に制限される可能性があります。

LoWPANノードのRAMサイズは通常4 KBから10 KBの範囲(最小2 KB)であり、プログラムフラッシュメモリは通常48 KBから128 KBで構成されます。(例えば、現在の市場では、MICAzは128 KBのプログラムフラッシュ、4 KBのEEPROM、512 KBの外部フラッシュROMを持っています; TIP700CMは48 KBのプログラムフラッシュ、10 KBのRAM、1 MBの外部フラッシュROMを持っています。)

これらのハードウェア制限により、コードは小さなメモリサイズに収まるべきです (SHOULD) -- 少なくとも数十KBのアプリケーションコードサイズを含む、48 KBから128 KB以下のフラッシュメモリ。(一般的な観察として、低複雑度のルーティングプロトコルは、電力消費削減の目標達成を支援し、堅牢性を向上させ、より低いルーティング状態を必要とし、分析が容易で、セキュリティ攻撃を受けにくい可能性があります。)

さらに、限られた量のルーティング状態(ルーティングテーブルやネイバーリストなど)での動作を維持すべきです (SHOULD)。なぜなら、一部の典型的なメモリサイズでは、多数のノードの状態を保存することができないためです。例えば、産業監視アプリケーションでは最大20ホップをサポートする必要がある場合があります [RFC5673]。小規模ネットワークは、より少ないホップ数をサポートするように設計できます。これに対するニーズはネットワークアーキテクチャに大きく依存しますが、32以下の転送エントリで機能できる少なくとも1つの動作モードが存在すべきです。

[R02] 6LoWPANルーティングプロトコルは、制御パケットを効率的に使用し(例えば、LoWPAN全体へのリンクブロードキャストを引き起こす高価なIPマルチキャストを最小化)、データパケットを効率的にルーティングすることにより、最小限の電力消費を引き起こすべきです (SHOULD)。

電池寿命を最適化する1つの方法は、最小限の制御メッセージオーバーヘッドを達成することです。計算操作やセンサーサンプリングなどの機能と比較して、無線通信は電力消費の圧倒的に支配的な要因です [Doherty]。送信および/または受信の電力消費は、データユニットの長さと、データユニットの送信および受信の頻度に線形に依存します [Shih]。

低電力ノード用の2つの例示的な無線周波数(RF)コントローラのエネルギー消費は [Hill] に示されています。TR1000無線は0.75 mWで送信するときに21 mWを消費し、受信中に15 mWを消費します(受信感度は-85 dBm)。CC1000は0.75 mWで送信するときに31.6 mWを消費し、受信中に20 mWを消費します(受信感度は-105 dBm)。理想的な電源の概念下での電力持続性は [Hill] で説明されています。理想的なAA電池のエネルギーに基づくと、CC1000は約4日間連続して送信するか、9日間連続して受信できます。実際のタスクに対する可用性は、通信の頻度と他の低デューティサイクル動作、および電池が提供するエネルギー容量に依存することに注意してください。

場合によっては、ルーティングプロトコルによって導入されるオーバーヘッドは大きくなります。[Doherty] は、階層ルーティングに使用されるLEACHプロトコルでは、[Heinzelman] で提案されたデータおよびプロトコルパケットが毎秒100ビットのレートで送信エネルギーの97%を消費すると報告しています。制御パケットのオーバーヘッド要件がそれほど厳しくない場合でも、制御パケットは依然として重要な役割を果たします。低レート低電力無線パーソナルエリアネットワーク(LR-WPAN)のセンサーデータについて、ZigBee (IEEE 802.15.4) はセンサーデータ送信でAODVルーティングを使用し、ルーティングプロトコルパケットは送信エネルギーの約15%を消費し、データパケットの送信エネルギー消費は約85%です [Doherty]。したがって、ルーティングプロトコルは効率的なルーティングメカニズムとシンプルな交換プロトコルパケット形式の使用を考慮すべきです (SHOULD)。

[R03] 6LoWPANルーティングプロトコル制御メッセージは、高価なフラグメンテーションと再構成コストを避けるために、単一のIEEE 802.15.4 MACフレームサイズ(最大127バイト)を超えるべきではありません (SHOULD NOT)。

単一のIEEE 802.15.4フレームの最大物理層パケットサイズは127バイトです [IEEE802.15.4]。LLC/SNAPがイーサネットフレームタイプを運ぶ場合、40バイトのIPv6ヘッダーとUDPヘッダーは8バイトを必要とするため、UDPペイロードは74バイトです。一般的に、プロトコルをシンプルに保ち、フレームのフラグメンテーションと再構成を避けるために、6LoWPANルーティングプロトコル制御メッセージは制限された量で送信され、可能な限り小さくすべきです (SHOULD)。

LoWPANのトポロジカル条件により、リンク障害と送信障害が頻繁に発生します。パケットの信頼性を高めるか、追加のバックアップ送信を使用する必要がある場合があります。予期しないネットワーク条件(失われたデータまたは制御パケット、単方向リンク、変化するリンク品質など)の処理は、堅牢で信頼性の高いルーティングプロトコルを設計する上で重要です。ルーティングプロトコルは、設計においてこれらのタイプのネットワーク条件を認識するだけでなく、データがソースから宛先に確実に配信されることを保証するために、6LoWPAN相互接続性によって提供される機能も利用する必要があります。以下の要件は、LoWPAN内のリンクの特性を考慮しています。

[R04] LoWPAN用のルーティングプロトコルの設計は、ルーティング最適化のためにリンクの信頼性、リンクエラー率、リンク品質、およびリンク安定性を考慮しなければなりません (MUST)。

無線低電力リンクは本質的に信頼性が低く、パケット損失の複数の理由があります:

  • 多くのデバイスはほとんどの時間スリープモードにある可能性があるため、パケットが送信されるときにリスニングしている近隣がいない可能性があります。
  • EMI、建物やインフラストラクチャからの障害物、地形などの環境要因が、送信失敗や対称リンクが非対称になる(またはその逆)原因となる可能性があります。
  • 輻輳、特にセンサーネットワークでは、マルチホップ通信と多くのソースからゲートウェイに収束するルーティングトラフィックが、ゲートウェイ近くのノード周辺の輻輳の可能性を高めます [Shelby-6LoWPAN]。
  • 無線スペクトラムは通常共有されており、ISMバンドを使用するいくつかの無線技術間での調整が必要であり、これらのバンドで動作するネットワークは、他のネットワークやデバイスからの干渉の影響を受ける可能性があります。

したがって、6LoWPANルーティングプロトコルの設計は、ルーティング最適化のためにリンクの信頼性、リンクエラー率、リンク品質、およびリンク安定性を考慮しなければなりません (MUST)。

[R05] LoWPAN用のルーティングプロトコルの設計は、非対称リンクを考慮しなければなりません (MUST)。

6LoWPANルーティングプロトコルは非対称リンクをサポートしなければなりません (MUST)。なぜなら、多くのLoWPANにおける実際のリンクは非対称だからです(例えば、低電力センシングノードと電力豊富な基地局間のリンク)[Shelby-CoAP]。このような場合、ルーティングパスの選択は非対称リンクを処理しなければなりません (MUST)。

[R06] 6LoWPANルーティングプロトコルは、リンクの動的な損失変化に対して堅牢であるべきです (SHOULD)。

6LoWPANルーティングプロトコルは、IEEE 802.15.4リンクの信頼性のない性質を処理するために、リンク損失の変化に対して堅牢であるべきです (SHOULD)。LoWPANノードに接続された典型的なリンクは、常に利用可能であるとは限りません。リンク損失の変化は、ノードの移動、電力/電池の枯渇、スリープサイクル、信号フェーディングまたは受信信号強度の低下、干渉などのさまざまな要因によって引き起こされる可能性があり、長期間にわたってリンクが無効になる可能性があります。ルーティングプロトコルは、これらのリンクの特性を適切な方法で処理すべきです (SHOULD)。

[R07] 6LoWPANルーティングプロトコルは、可能なフレームサイズを正しく処理するように設計されるべきです (SHOULD)。

一部のLoWPANでは、制御パケットの可能な最大サイズが非常に制限されています(単一のIEEE 802.15.4 MACフレームで最大127バイト)。これは、MAC層にネイティブのフラグメンテーションと再構成サポートがないためです。

最大フレームサイズは、小さなヘッダーと低状態メッセージオーバーヘッドが強制されなければならないことを意味します (MUST)。制御パケットは、単一のリンク層フレーム内に収まる程度に小さくあるべきです (SHOULD)。ただし、メッセージを構築する際には柔軟性が必要です。メッセージ設計は、標準IPv6ヘッダーと他のヘッダー(リンク層ヘッダーやアダプテーション層ヘッダーなど)に必要なスペースに対応しなければならず (MUST)、他のルーティングプロトコルや既存のIETFプロトコルに必要なオプションも収容できなければなりません (MUST)。

5.3. Support of 6LoWPAN Characteristics (6LoWPAN特性のサポート)​

本セクションでは、6LoWPANルーティングプロトコルの設計に影響を与える可能性のある基本的なネットワーク特性を考慮します。

[R08] 6LoWPANルーティングプロトコルの設計は、トラフィックパターン、ネットワーク密度、ノードの可能な役割または機能、および異なるネットワーク構成の使用と数を考慮すべきです (SHOULD)。

6LoWPANルーティングプロトコルは、さまざまな異なるLoWPANトポロジを処理できるべきです (SHOULD):

  • ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーポイント、またはマルチポイントツーマルチポイントのトラフィックパターン
  • 単一のポイント(ゲートウェイなど)に集中する通信トラフィック
  • 変化するホストとルーター密度、変化するルーター対ホスト比
  • ルーター機能がホスト機能と異なる場合や、同じノード上にある場合
  • 制約のあるノードと制約のないノード、またはルーティング、リレー、集約などの機能を実行するノードなど、異なるノード機能
  • ピアツーピア、スター、メッシュネットワークなど、異なるネットワーク構成
  • 展開後期間(ランタイム)中の動的ネットワーク形成とトポロジ変化
  • 変化するネットワークサイズ; ネットワークのサイズも非常に多様で、数個のノードのネットワークから数百個以上のノードまで
  • ネットワークパーティション化が発生する可能性があり、処理する必要がある

[R09] 6LoWPANルーティングプロトコルで使用されるメトリックは、ノードとリンク属性の複合的な影響を考慮すべきです (SHOULD)。

エネルギー消費を最小化し、配信の成功を保証するために、リンク品質とノード属性をルーティングメトリックに組み込むことが重要です。例えば、最小ホップ数の最短パスは、最もエネルギー効率の高いパスではない可能性があります。なぜなら、非常に輻輳したノードを経由するか、より多くのエラーを経験し、したがってより多くの再送信を必要とするリンクを経由する可能性があるためです。

メトリックのタイプに関して、ルーティングメトリックは以下を効果的に表現できるべきです:

  • リンクメトリック: 受信信号強度表示(RSSI)、リンク品質表示(LQI)、期待送信カウント(ETX)、スループット、レイテンシ
  • ノードメトリック: 状態(スリープ、起動、リスニング)、残存エネルギー、ホップカウント、地理情報(GPS座標など)
  • 複合メトリック(リンクとノード)

以下のような他の可能なメトリックも考慮すべきです (SHOULD):

  • 信頼性
  • 堅牢性
  • 安定性

[R10] 6LoWPANルーティングプロトコルは、6LoWPANにおけるスケーラビリティと寿命の両方を達成するように設計されるべきです (SHOULD)。

スケーラビリティと寿命の要件は、LoWPANの基本的な特性です:

  • スケーラビリティ: LoWPANは、わずか数個のノード(例えば、パーソナルエリアネットワークまたはボディエリアネットワーク用)しか含まない場合がありますが、はるかに多くのデバイス(例えば、都市インフラストラクチャまたは高速道路の監視)を含む場合もあります。ホームオートメーションアプリケーションの場合、ルーティングプロトコルはネットワーク内の250デバイスをサポートしなければなりません (MUST) [RFC5826]。一方、メトロポリタンスケールのセンサーネットワーク用のルーティングプロトコルは、各領域に10^2から10^4個のセンシングノードを含む領域に多数のセンシングノードをクラスタリングできなければなりません (MUST) [RFC5548]。したがって、さまざまなサイズのネットワークで動作するためにスケーラブルになるようにルーティングメカニズムを設計することが必要です。ただし、メモリサイズと計算能力の不足により、6LoWPANルーティングは転送エントリを少数(最大32個のルーティングテーブルエントリなど)に制限する可能性があります。特に大規模ネットワークでは、ルーター数がホスト数よりも少なくなるようにルーティングメカニズムを設計しなければなりません (MUST)。

  • 寿命: ルート修復の手順と関連する制御メッセージは、ルーティングプロトコルからの全体的なエネルギー消費を損なうべきではありません (SHOULD NOT)。

[R11] ルート修復の手順と関連する制御メッセージは、ルーティングプロトコルからの全体的なエネルギー消費を損なうべきではありません (SHOULD NOT)。

ローカル修復は、特に大規模ネットワークにおいて、スループットとエンドツーエンドレイテンシを向上させます。ルートが迅速に修復されるため、ドロップされるデータパケットが少なくなり、ルートはソースが開始するルート発見なしで修復できるため、ルーティングプロトコルパケット送信の数が少なくて済みます [Lee]。ここでの重要な考慮事項の1つは、他の要件を損なう場合でも、早期のエネルギー枯渇を回避することかもしれません。

[R12] 6LoWPANルーティングプロトコルは、動的に適応的なトポロジとモバイルノードを許可すべきです (SHOULD)。動的トポロジとモバイルノードをサポートする場合、ルート維持は、最小限のルーティング状態とルーティングプロトコルメッセージオーバーヘッドの目標を念頭に置くべきです。

トポロジカルノードモビリティは、物理的な移動および/または変化する無線環境の結果である可能性があり、物理的に静的なノードを持つネットワークでもモビリティを処理する必要がある可能性が非常に高くなります。6LoWPANは、移動ノードへの接続を維持するために別個のプロトコルを使用せず、ルーティングプロトコルがそれを処理することを期待しています。

さらに、一部のノードは1つの6LoWPANから別の6LoWPANに移動する可能性があり、限られた時間内に後者の6LoWPANの機能的なメンバーになることが期待されます。

例えば、ビル監視アプリケーションには、モビリティの回復時間と安定時間に関する多くの要件があり、5秒から20秒の範囲です([RFC5867]のセクション5.3.1)。ホームオートメーションシステムで使用されるような、ユーザーが入力を提供し即座のフィードバックを期待する、よりインタラクティブなアプリケーションの場合、モビリティ要件もより厳格であり、ネットワーク内の移動の場合、一般的に0.5秒未満の収束時間が必要です([RFC5826]のセクション3.2)。移動機器(クレーンなど)が動き回る産業環境では、ルーティングプロトコルは最大35 km/hの車両速度をサポートする必要があります [RFC5673]。現在、6LoWPANは通常、このような高速モビリティには使用されていませんが、6LoWPANでは動的な関連付けと関連付け解除がサポートされなければなりません (MUST)。

動的環境で堅牢なルーティングを作成するために、6LoWPANルーティングプロトコルが対処すべきいくつかの課題があります:

  • LoWPAN内で位置を変更するモバイルノード: ノードの移動パターンが不明な場合、ルーティングプロトコルはモビリティを簡単に検出または区別できません。モバイルノードは、ある場所で消え、別の場所で再び現れるノードとして扱うことができます。移動パターンの追跡は複雑さを増し、リアクティブルート更新を使用して移動ノードを処理することで回避できます。

  • 他の(相互)接続されたLoWPANに対するLoWPANの移動: 各スタブネットワーク内で、(1つ以上の)比較的強力なゲートウェイノード(6LBR)を、移動するLoWPANを処理するように構成する必要があります。

  • LoWPANに永続的に参加または離脱するノード: ルーティングテーブルの更新を容易にし、これらの更新のサイズを削減し、エラー制御メッセージを最小化するために、ネットワークを離脱するノードは、最も近いエッジルーターまたはローカルな関連付けと関連付け解除を担当する特定のノード(存在する場合)に、その関連付け解除を通知できます。

[R13] 6LoWPANルーティングプロトコルは、LoWPAN内の過剰なマルチキャストトラフィックを回避しながら、ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーポイントなど、さまざまなトラフィックパターンをサポートすべきです (SHOULD)。

6LoWPANは多くの場合、ポイントツーマルチポイントまたはマルチポイントツーポイントのトラフィックパターンを持ちます。多くの新興アプリケーションには、ポイントツーポイント通信も含まれています。6LoWPANルーティングプロトコルは、複数のソース/宛先との間でパケットを転送することを考慮して設計されるべきです。ROLL WGの現在の文書は、LoWPANのユースケースのワークロードまたはトラフィックパターンは、典型的なクライアントおよびサーバーワークロードを支配する任意間のデータ転送とは異なり、非常に構造化される傾向があることを説明しています。多くの場合、そのような構造を利用することで、リソース制約または接続の変動から生じる困難な問題を簡素化できます。

5.4. Support of Security (セキュリティのサポート)​

セキュリティは、低電力ネットワークにとって重要な問題です。6LoWPANルーティングプロトコルのあらゆるソリューションは、以下の基本的なセキュリティ要件を満たすべきです (SHOULD)。これらの要件は、ルーティングメカニズムとネットワークデータ交換に適用されなければなりませんが (MUST)、過度の電力消費と処理能力の使用は避けるべきです。

[R14] 6LoWPANルーティングプロトコルは、ルーティング脅威に対抗するために、メッセージ完全性、メッセージ送信元認証、およびメッセージ機密性サービスをサポートすべきです (SHOULD)。

ルーティングプロトコルセキュリティの重要性と6LoWPANへのセキュリティ脅威の性質(例えば、[ROLL-SEC]で説明されている)を考慮すると、ルーティングプロトコルは以下をサポートすべきです (SHOULD):

  • 中間ノードによるプロトコルメッセージの変更を防ぐためのメッセージ完全性
  • 偽造ソースからのなりすまし攻撃を防ぐためのメッセージ送信元認証
  • パッシブ盗聴を防ぐためのメッセージ機密性

メッセージの適時性も考慮すべきです。古いメッセージ自体が攻撃の一形態である可能性があり、その場合、アプリケーション層自体またはデータリンクセキュリティ機能と共に適時性サービスが6LoWPANに役立ちます。

ルーティングプロトコルは、リプレイ、インジェクション、変更などの攻撃から保護されなければなりません (MUST)。これらの攻撃は、ルーティングまたはトポロジループ、特定のノードへの標的型サービス拒否、誤ったルーティング情報の生成、リソース枯渇、ネットワークパーティション化などの脅威につながる可能性があります [ROLL-SEC]。

セキュリティサポートはオプションであり、有効にされた場合、セキュアな6LoWPANルーティングプロトコルを使用するためのすべてのルールに準拠します。リンク層セキュリティ(IEEE 802.15.4のサブクローズ7.6で定義されているCCM*モードのセキュリティ)を実装し、追加のルーティングプロトコル固有のセキュリティおよびメッセージ完全性チェックメカニズム(タイムスタンプやシーケンス番号など)を追加することにより、ほとんどのセキュリティ脅威に対する耐性を実現できます。

設計は、プロトコルが実行しなければならない重量級操作のコストを考慮しなければなりません (MUST)。例えば、対称鍵と比較して、公開鍵を使用すると、より高いエネルギー消費につながる可能性があります。大量のノード状態を必要とするセキュリティ操作(アドレス/鍵管理、認証、リンク層鍵確立など)の汎用ソリューションは、オーバーヘッドを節約するために、すべてのLoWPANプロトコルで使用されるべきです。6LoWPANルーティングプロトコルは、これらの機能を有効にするためのサポート用に設計されるべきであり (SHOULD)、これらの機能自体も過度の電力を消費しないように注意すべきです。

5.5. Support of Mesh-Under Forwarding (Mesh-Under転送のサポート)​

現在の6LoWPANアーキテクチャは、mesh-underルーティングによるマルチホップ転送を可能にします [RFC4944]。このアプローチの主要な特徴は、mesh-under転送とroute-overルーティングをサポートする能力が6LoWPANプロトコルの要件になり得ることです。しかし、これが6LoWPANルーティングプロトコルの要件であるかどうかは、依然として未解決の問題です。この点で、これら2つの異なるアプローチ(1つはIPルーティングを使用し、もう1つは独自の転送メカニズムを使用)の要件を考慮する必要があります。

mesh-under転送メカニズムはリンク層アドレス(MACアドレス)を使用するため、IPサブネットの境界で停止します。IPv6アドレスとルーティングテーブルを使用するroute-overルーティングと組み合わせて使用する場合、独自の転送テーブルを含むクロスレイヤー情報が必要になる可能性があります。

このため、mesh-under転送メカニズムは、関連する操作のために独自のトポロジ維持メッセージと転送テーブルを提供する可能性があります。これは、ネイバー/リンク発見、転送テーブルエントリの管理、トポロジ維持、パス発見に使用されるroute-overルーティングプロトコルに必要な機能に匹敵する可能性があります。

したがって、重要な問題は、これら2つのアプローチ(route-overとmesh-under)をどのように組み合わせるべきか、どのように協調して動作できるか、それによって発生する可能性のある冗長性や相互運用性の問題を回避することです。将来の作業は、特にこれらのアーキテクチャの問題に焦点を当てるべきです。

5.6. Support of Management (管理のサポート)​

ネットワーク管理については、以下の要件を考慮すべきです (SHOULD)。

LoWPANは動的に構成および初期化される必要がある場合があります。例えば、ゲートウェイの電源投入後、そのサブネットにどのノードが属しているかがわかりません。ノードがネットワークに参加する能力は、本質的にルーティング技術とは独立していますが、一部のルーティングプロトコルはこのプロセスを容易にする可能性があります。ルーティングプロトコルは、ネットワークの初期化と構成をサポートすべきです (SHOULD)。これには、ルーティングプロトコルと、アドレス割り当て、自動構成、ネイバー発見などの他の機能との間の相互作用が含まれる可能性があります。

監視とデバッグについては、関連するルーティングプロトコルパラメータ、現在の構成、ルーターとホスト機能の現在の状態を取得する能力が重要です。ルーティングテーブル、ネイバーテーブル、メッセージカウント、リンク品質情報などの情報を取得できるべきです。診断、障害検出、監視、およびイベント/アラーム報告機能のインターフェイスを考慮すべきです。場合によっては既存のプロトコルとインターフェイスをこの目的に使用できますが、LoWPANに特化したソリューションが必要になる可能性があります。

特定のLoWPANは通常周期的にスリープモードに入るため、より低いレイテンシで情報を収集できるように、ノードのスリープ/ウェイクパターンを制御できるべきです。

ルーティングプロトコルの進化をサポートし、状況とトラフィックパターンに基づいてルーティングパラメータを変更する能力が重要です。例えば、メトリックタイプの選択、タイマー値の調整、またはプロトコルのモード(サポートされている場合)の選択/変更が必要になる場合があります。1つの可能性は、完全に異なるプロトコルに切り替えることです。ただし、コードサイズの要件のために、これは実現不可能な場合があります。ユーザーは、複数のルーティングプロトコルの実装をサポートできるべきです。

以下の追加の管理面を考慮すべきです:

  • デバイス管理とノードトポロジ構成機能
  • 鍵管理を含むセキュリティ管理
  • スリープスケジュール管理
  • サービス品質管理
  • パス修復、障害検出、および制御
  • クロスレイヤー統合と調整
に最終更新