LoRaWAN仕様：6 端末のアクティベーション

LoRaWANネットワークに参加するには、各エンドデバイスをパーソナライズし、アクティベートする必要があります。
エンドデバイスのアクティベーションは、Over-The-Air Activation（OTAA）または Activation By Personalization（ABP）の2つの方法で実現できます。

アクティベーション方式

方式	説明
OTAA（Over The Air Activation）	Join Request/Acceptによる動的な接続。セキュリティ性が高い
ABP（Activation By Personalization）	固定キーとアドレスで事前設定。接続は簡易だがセキュリティは劣る

6.1 エンドデバイスに保存されるデータ

6.1.1 アクティベーション前

6.1.1.1 JoinEUI

JoinEUI は、IEEE EUI64 アドレス空間におけるグローバルなアプリケーション ID であり、接続手続きの処理およびセッションキーの導出を支援できる接続サーバーを唯一無二に識別します。
OTAA デバイスにおいては、接続手続きを実行する前に、JoinEUI をエンドデバイスに保存しなければなりません。ABP専用エンドデバイスにおいては、JoinEUIは必須ではありません

6.1.1.2 DevEUI

DevEUIは、IEEE EUI64アドレス空間におけるグローバルなエンドデバイスIDであり、エンドデバイスを一意に識別します。
DevEUI は、ネットワークをローミングするデバイスを識別するため、ネットワークサーバーが推奨する一意のデバイス識別子です。これは、使用されるアクティベーション手順に関わらず適用されます。
OTAA デバイスについては、Join 手順を実行する前に、DevEUI をエンドデバイスに保存しなければなりません。ABPデバイスは、DevEUIをデバイス自体に保存する必要はありませんが、保存することが推奨されます。

注記：デバイス管理のため、DevEUIをデバイスラベルにも記載することが推奨される慣行です。

6.1.1.3 デバイスルートキー（AppKey および NwkKey）

NwkKey および AppKey は、製造時に端末に割り当てられる端末固有の AES-128 ルートキーです。1 端末が無線によるアクティベーションを通じてネットワークに参加する際には、NwkKey を使用して FNwkSIntKey および 1335 NwkSEncKey セッションキーが導出され、AppKey は AppSKey セッションキーの導出に使用されます。1337 SNwkSIntKey および NwkSEncKey セッション鍵を導出するために使用され、AppKey は AppSKey セッション鍵を導出するために使用されます。

注記：v1.1ネットワークサーバーを使用する場合、アプリケーションセッションキーはAppKeyからのみ導出されます。したがって、ネットワークオペレーターがアプリケーションペイロードデータを傍受する権限を与えずに、JOINプロシージャを管理するためにNwkKeyをオペレーターに提供することが可能です。

エンドデバイスおよびバックエンドにおけるルートキー NwkKey および AppKey の安全なプロビジョニング、保管、使用は、ソリューション全体のセキュリティに不可欠です。これらは実装に委ねられており、本ドキュメントの範囲外となります。ただし、本ソリューションの構成要素には、SE（セキュアエレメント）および HSM（ハードウェアセキュリティモジュール）が含まれる場合があります。
LoraWAN 1.0 およびそれ以前のネットワークサーバー（2つのルートキーをサポートしないもの）との下位互換性を確保するため、エンドデバイスは、そのようなネットワークに参加する際には、単一ルートキー方式にデフォルトで戻らなければなりません。この場合、ルートNwkKeyのみが使用されます。この状態は、Join-acceptメッセージのDLsettingフィールドの「OptNeg」ビット（ビット7）がゼロであることでエンドデバイスに通知されます。この場合、エンドデバイスは必ず

LoRaWAN 1.0仕様書に記載されている通り、NwkKeyを用いてAppSKeyおよびFNwkSIntKeyの両セッションキーを導出すること。
・SNwkSIntKey および NwkSEncKey を FNwkSIntKey と同一に設定します。これにより、LoRaWAN 1.0 仕様に従い、アップリンクおよびダウンリンクの MIC 計算ならびに MAC ペイロードの暗号化に同一のネットワークセッション鍵が効果的に使用されます。

OTAAプロシージャを使用するエンドデバイスには、NwkKeyを保存する必要があります。
ABPのみを使用するエンドデバイスには、NwkKeyは不要です。
OTAAプロシージャを使用するエンドデバイスには、AppKeyを保存する必要があります。
ABPのみを使用するエンドデバイスにはAppKeyは不要です。
NwkKeyおよびAppKeyは、悪意のある者による抽出や再利用を防ぐ方法で保存されるべきです。

6.1.1.4 JSIntKey および JSEncKey の導出

OTA デバイスでは、NwkKey ルートキーから 2 つの特定の有効期間キーが導出されます：

JSIntKey は、Rejoin-Request タイプ 1 メッセージおよび Join-Accept 応答の MIC に使用されます
JSEncKey は、Rejoin-Request によってトリガーされる Join-Accept の暗号化に使用されます。

JSIntKey = aes128_encrypt(NwkKey, 0x06 | DevEUI | pad16)
JSEncKey = aes128_encrypt(NwkKey, 0x05 | DevEUI | pad16)

¹. すべてのエンドデバイスには、各エンドデバイス固有のアプリケーションルートキーおよびネットワークルートキーが装備されているため、エンドデバイスから AppKey/NwkKey を抽出しても、侵害されるのはそのエンドデバイスのみとなります。

6.1.2 アクティベーション後

アクティベーション後、エンドデバイスには以下の追加情報が保存されます：デバイスアドレス（DevAddr）、ネットワークセッションキーの3要素（NwkSEncKey/ SNwkSIntKey/ FNwkSIntKey）、およびアプリケーションセッションキー（AppSKey）。

6.1.2.1 エンドデバイスアドレス（DevAddr）

DevAddrは32ビットで構成され、現在のネットワーク内でエンドデバイスを識別します。DevAddrはエンドデバイスのネットワークサーバーによって割り当てられます。
その形式は以下の通りです：

N は [7:24] の範囲の整数です。
LoRaWANプロトコルは、異なるネットワークアドレス空間サイズを持つ様々なネットワークアドレスタイプをサポートしております。可変サイズのAddrPrefixフィールドは、LoRa Allianceによって割り当てられたネットワークサーバーの固有識別子NetID（6.2.3節参照）から派生したもので、実験用/プライベートネットワーク用に予約されたAddrPrefix値を除きます。アドレプレフィックスフィールドにより、ローミング中にエンドデバイスを管理しているネットワークサーバーの検出が可能となります。この規則に従わないデバイスは、ホームネットワークサーバーが特定できないため、2つのネットワーク間でローミングできません。
最下位ビット（32-N）であるエンドデバイスのネットワークアドレス（NwkAddr）は、ネットワーク管理者により任意に割り当てられます。
以下のアドレプレフィックス値は、あらゆるプライベート/実験ネットワークで使用可能であり、LoRa Alliance により割り当てられることはありません。

AddrPrefixフィールドの正確な構成および各種アドレスクラスの定義については、[BACKEND]をご参照ください。

6.1.2.2 転送ネットワークセッション完全性キー（FNwkSIntKey）

FNwkSIntKey は、エンドデバイス固有のネットワークセッションキーです。エンドデバイスは、4.4 で規定されているデータ整合性を確保するため、すべてのアップリンクデータメッセージの MIC（メッセージ整合性コード）またはその一部を計算するためにこれを使用します。
FNwkSIntKey は、悪意のある者による抽出や再利用を防ぐ方法で保存されるべきです。

6.1.2.3 サービングネットワークセッション完全性キー (SNwkSIntKey)

SNwkSIntKeyは、端末デバイス専用のネットワークセッションキーです。端末デバイスは、このキーを用いて、すべてのダウンリンクデータメッセージのMIC（メッセージ完全性コード）を検証し、データの完全性を確保するとともに、アップリンクメッセージのMICの半分を計算します。アップリンクMICの計算には、2つのキー（FNwkSIntKeyおよびSNwkSIntKey）が使用されます。これにより、ローミング設定における転送ネットワークサーバーがMICフィールドの半分のみを検証できるようになります。
デバイスがLoRaWAN1.0ネットワークサーバーに接続する場合、4.4で規定されている通り、アップリンクおよびダウンリンクのMIC計算には同一の鍵が使用されます。この場合、SNwkSIntKeyはFNwkSIntKeyと同一の値を取ります。
SNwkSIntKey は、悪意のある者による抽出や再利用を防ぐ方法で保存されるべきです。

6.1.2.4 ネットワークセッション暗号化キー (NwkSEncKey)

NwkSEncKey は、エンドデバイス固有のネットワークセッションキーです。ポート 0 または FOpt フィールドのペイロードとして送信されるアップリンクおよびダウンリンクの MAC コマンドの暗号化および復号化に使用されます。デバイスが LoRaWAN 1.0 ネットワークサーバーに接続する際、MAC ペイロードの暗号化と MIC 計算の両方に同じキーが使用されます。この場合、NwkSEncKeyはFNwkSIntKeyと同じ値を取ります。

NwkSEncKey は、悪意のある者による抽出や再利用を防ぐ方法で保管されるべきです。

6.1.2.5 アプリケーションセッションキー (AppSKey)

AppSKey は、エンドデバイス固有のアプリケーションセッションキーです。アプリケーションサーバーとエンドデバイスの双方が、アプリケーション固有のデータメッセージのペイロードフィールドを暗号化および復号化するために使用します。アプリケーションのペイロードは、エンドデバイスとアプリケーションサーバー間でエンドツーエンド暗号化されますが、完全性はホップごとの方式で保護されます。つまり、エンドデバイスとネットワークサーバー間の1ホップ、およびネットワークサーバーとアプリケーションサーバー間のもう1ホップで保護されます。これは、悪意のあるネットワークサーバーが、転送中のデータメッセージの内容を改変できる可能性があることを意味します。改変されたデータに対するアプリケーションエンドポイントの反応を観察することで、ネットワークサーバーがデータに関する情報を推測する助けとなる可能性さえあります。ネットワークサーバーは信頼されているものとみなされますが、エンドツーエンドの機密性および完全性保護を実装したいアプリケーションは、この仕様の範囲を超える追加のエンドツーエンドセキュリティソリューションを使用することができます。
AppSKeyは、悪意のある行為者による抽出や再利用を防止する方法で保管されるべきです。

6.1.2.6 セッションコンテキスト

セッションコンテキストには、ネットワークセッションとアプリケーションセッションが含まれます。
ネットワークセッションは以下の状態で構成されます：

F/SNwkSIntKey
NwkSEncKey
FCntUp
FCntDwn (LW 1.0) または NFCntDwn (LW 1.1)
DevAddr

アプリケーションセッションは以下の状態から構成されます：

AppSKey
FCntUp
FCntDown (LW 1.0) または AFCntDwn (LW 1.1)

ネットワークセッションの状態は、NS およびエンドデバイスによって維持されます。アプリケーションセッションの状態は、AS およびエンドデバイスによって維持されます。

OTAA または ABP 手順のいずれかが完了すると、NS/AS とエンドデバイスの間に新しいセキュリティセッションコンテキストが確立されます。セッションの期間中、キーおよびエンドデバイスのアドレスは固定されます（FNwkSIntKey、SNwkSIntKey、AppSKey、DevAddr）。セッション中にフレームトラフィックが交換されるにつれて、フレームカウンタはインクリメントされます（FCntUp、FCntDwn、NFCntDwn、AFCntDwn）。

OTAAデバイスにおいては、特定のキーに対してフレームカウンタを再利用してはなりません。したがって、フレームカウンタが飽和状態に達する前に、新たなセッションコンテキストを確立する必要があります。
エンドデバイスの電源投入/切断時においても、セッション状態を維持することが推奨されます。
OTAAデバイスにおいてこれを怠った場合、デバイスの電源投入のたびにアクティベーション手順を実行する必要が生じます。

6.2 無線によるアクティベーション

無線によるアクティベーションでは、エンドデバイスはネットワークサーバーとのデータ交換に参加する前に、参加手順に従わなければなりません。
エンドデバイスは、セッションコンテキスト情報を失った場合、毎回新たな参加手順を経る必要があります。前述の通り、参加手順を開始する前に、エンドデバイスは以下の情報でパーソナライズされている必要があります：DevEUI、JoinEUI、NwkKey、およびAppKey。

注記：
無線によるアクティベーションの場合、端末デバイスはネットワークセッションキーのペアでパーソナライズされません。代わりに、端末デバイスがネットワークに参加するたびに、その端末デバイス専用のネットワークセッションキーが導出され、ネットワークレベルでの通信の暗号化と検証が行われます。この方式により、異なるプロバイダーのネットワーク間における端末のローミングが容易になります。異なるネットワークセッションキーとアプリケーションセッションキーを使用することで、アプリケーションデータがネットワークプロバイダーによって読み取られないフェデレーションネットワークサーバーの実現が可能となります。

6.2.1 Join手順

エンドデバイスの観点から、参加手順は、参加要求または再参加要求と、参加承諾の交換で構成されます。

6.2.2 Join-requestメッセージ

参加手順は、常にエンドデバイスから参加要求メッセージを送信することで開始されます。

Joinリクエストメッセージには、エンドデバイスのJoinEUIおよびDevEUIが含まれ、その後に2オクテットのノンス（DevNonce）が続きます。
DevNonceは、デバイスが最初に電源投入された際に0から開始されるカウンタであり、各Joinリクエストごとに1ずつ増加します。特定のJoinEUI値に対してDevNonce値を再利用することは決してあってはなりません。エンドデバイスが電源再投入可能な場合、DevNonceは永続的である必要があります（不揮発性メモリに保存されます）。JoinEUIを変更せずにDevNonceをリセットすると、ネットワークサーバーは当該デバイスのJoinリクエストを破棄します。ネットワークサーバーは、各エンドデバイスについて、そのデバイスが最後に使用したDevNonce値を追跡し、DevNonceが増分されていないJoinリクエストは無視します。

このメカニズムは、ネットワークから該当するエンドデバイスを切断する意図で、以前に記録されたJoinリクエストメッセージを送信するリプレイ攻撃を防止します。ネットワークサーバーがJoin-Requestを処理しJoin-acceptフレームを生成する際は、新しいセキュリティコンテキスト（鍵およびカウンタ、該当する場合）が使用される最初の成功したアップリンクフレーム（RekeyIndコマンドを含む）を受信するまで、従来のセキュリティコンテキスト（鍵およびカウンタ、該当する場合）と新しいセキュリティコンテキストの両方を維持しなければなりません。その後、従来のコンテキストは安全に削除できます。

ジョイン要求メッセージのメッセージ完全性コード（MIC）値（MACメッセージの説明については第4章を参照）は、以下の方法で計算されます：

cmac = aes128_cmac(NwkKey, MHDR | JoinEUI | DevEUI | DevNonce)
MIC = cmac[0..3]

ジョイン要求メッセージは暗号化されません。ジョイン要求メッセージは、任意のデータレートを使用し、指定されたジョインチャネル全体でランダムな周波数ホッピングシーケンスに従って送信することができます。複数のデータレートを使用することが推奨されます。Join-Requestの送信間隔は、第7章に記載された条件を遵守しなければなりません。Join-Requestを送信するたびに、エンドデバイスはDevNonceの値をインクリメントしなければなりません。

6.2.3 Join-acceptメッセージ

ネットワークサーバーは、端末デバイスがネットワークへの参加を許可されている場合、join参加要求またはrejoin-request再参加要求メッセージに対して参加承認メッセージで応答します。Join-Acceptメッセージは通常のダウンリンクと同様に送信されますが、RECEIVE_DELAY1およびRECEIVE_DELAY2の代わりに、それぞれJOIN_ACCEPT_DELAY1またはJOIN_ACCEPT_DELAY2の遅延を使用します。これら2つの受信ウィンドウで使用されるチャネル周波数およびデータレートは、[PHY]
の「受信ウィンドウ」セクションで説明されているRX1およびRX2受信ウィンドウで使用されるものと同一です。Joinリクエストが受け入れられなかった場合、エンドデバイスには応答は返されません。
Join-Acceptメッセージには、3オクテットのサーバーノンス（JoinNonce）、ネットワーク識別子（NetID）、エンドデバイスアドレス（DevAddr）、ダウンリンクパラメータの一部を提供する(DLSettings)フィールド、送信(TX)と受信(RX)間の遅延(RxDelay)、およびエンドデバイスが参加するネットワークのオプションのネットワークパラメータリスト(CFList)を含みます。オプションのCFListフィールドは地域固有であり、[PHY]で定義されています。

JoinNonceは、Joinサーバーが提供するデバイス固有のカウンター値（決して繰り返さない）であり、エンドデバイスがセッションキーFNwkSIntKey、SNwkSIntKey、NwkSEncKey、およびAppSKeyを導出するために使用されます。JoinNonceは、Join-1552 acceptメッセージごとにインクリメントされます。
デバイスは、最後に正常に処理されたJoin-accept（最後の成功した鍵導出に対応）で使用されたJoinNonce値を追跡します。デバイスは、MICフィールドが正しく、かつJoinNonceが記録済みの値よりも厳密に大きい場合にのみ、Join-acceptを受け入れるものとします。その場合、新しいJoinNonce値が以前に保存された値に置き換わります。
デバイスが電源再投入の影響を受ける可能性がある場合、JoinNonceは永続的である必要があります（不揮発性メモリに保存）。
LoRa Allianceは、実験用／プライベートネットワーク用に予約され管理対象外となる以下のNetID値を除き、すべてのネットワークに24ビットの一意のネットワーク識別子（NetID）を割り当てます。
2^15個のプライベート／実験用ネットワーク予約NetID値は、以下の構成で構築されています

Join-acceptフレームのhome_NetIDフィールドは、デバイスのホームネットワークのNetIdに対応します。
ローミングシナリオにおいては、devAddrを割り当てるネットワークとホームネットワークが異なる場合があります。より詳細な情報につきましては、[BACKEND]をご参照ください。
DLsettingsフィールドには、ダウンリンク設定が含まれます：

OptNegビットは、ネットワークサーバーがLoRaWAN1.0プロトコルバージョン（未設定）または1.1以降（設定）を実装しているかを示します。OptNegビットが設定されている場合

プロトコルバージョンは、エンドデバイスとネットワークサーバー間で、RekeyInd/RekeyConf MACコマンドの交換を通じてさらに（1.1以降）ネゴシエーションされます。
デバイスは NwkKey から FNwkSIntKey、SNwkSIntKey、NwkSEncKey を導出します。
デバイスは AppKey から AppSKey を導出します。

OptNegビットが設定されていない場合

デバイスはLoRaWAN1.0に復帰し、オプションはネゴシエーションできません
デバイスはRekeyIndコマンドを送信しません
デバイスはNwkKeyからFNwkSIntKeyとAppSKeyを導出します
デバイスはSNwkSIntKeyおよびNwkSEncKeyをFNwkSIntKeyと同一に設定します

メッセージの長さは16バイトまたは32バイトです。

注記：ECBモードにおけるAES復号操作は、参加承諾メッセージの暗号化に使用されます。これにより、エンドデバイスはAES暗号化操作を用いてメッセージを復号することが可能となります。この方式により、エンドデバイスはAES暗号化のみを実装すればよく、AES復号を実装する必要はありません。

注記： これら4つのセッションキーを確立することで、ネットワーク事業者がアプリケーションデータを傍受できないフェデレーテッドネットワークサーバーインフラストラクチャが実現されます。アプリケーションプロバイダーは、エンドデバイスが発生したトラフィックの料金を負担することをネットワーク事業者に保証し、アプリケーションデータ保護に使用されるAppSKeyに対する完全な管理権限を保持します。

注記：デバイスのプロトコルバージョン（1.0 または 1.1）は、DevEUI およびデバイスの NwkKey、場合によっては AppKey と同時に、バックエンド側でアウトオブバンドに登録されます。

RX1DRoffsetフィールドは、最初の受信スロット（RX1）においてエンドデバイスとの通信に使用されるアップリンクデータレートとダウンリンクデータレートの間のオフセットを設定します。デフォルトではこのオフセットは0です。このオフセットは、一部の地域における基地局の最大電力密度制約を考慮し、アップリンクとダウンリンクの無線リンクマージンを均衡化するために使用されます。
アップリンクとダウンリンクのデータレート間の実際の関係は地域固有であり、[PHY] に詳細が記載されています。
遅延 RxDelay は、RXTimingSetupReq コマンドの Delay フィールドと同じ規約に従います。
以下の送信後に Join-accept メッセージを受信した場合：

Join-RequestまたはRejoin-request（タイプ0または1）の送信後、かつCFlistフィールドが存在しない場合、デバイスはデフォルトのチャネル定義に戻すものとします。CFlistが存在する場合、現在定義されているすべてのチャネルを上書きします。MAC層パラメータ（Join-Acceptメッセージで伝送されるRXdelay1、RX2データレート、RX1 DRオフセットを除く）は、すべてデフォルト値にリセットされるものとします。
再参加要求タイプ2の場合、CFlistフィールドが存在しない場合、デバイスは現在のチャネル定義を変更せず維持しなければなりません。CFlistが存在する場合、現在定義されているすべてのチャネルを上書きします。その他のすべてのMACパラメータ（リセットされるフレームカウンタを除く）は変更されません。

Join-acceptメッセージの正常な処理後、いかなる場合においても、デバイスはRekeyConfコマンドを受信するまでRekeyInd MACコマンドを送信しなければなりません（5.9参照）。ネットワークサーバーは、RekeyIndアップリンクコマンドの受信を、新しいセキュリティコンテキストへの切り替えの信号として使用します。

6.2.4 再接続要求メッセージ

デバイスが起動されると、通常のアプリケーション通信に加えて、定期的に再接続要求メッセージを送信することがあります。この再接続要求メッセージにより、バックエンドは定期的にエンドデバイス用の新しいセッションコンテキストを初期化する機会を得ます。この目的のため、ネットワークは参加承諾メッセージで応答します。これは、デバイスを二つのネットワーク間でハンドオーバーする場合や、特定のネットワーク上のデバイスの鍵更新および／またはデバイスアドレス変更に使用できます。
ネットワークサーバーは、Rejoin-request RX1/RX2ウィンドウを利用して、MACコマンドを任意で含む通常の確認済みまたは未確認のダウンリンクフレームを送信することも可能です。この機能は、デバイスとネットワークサーバー間でMAC層の状態が非同期化した場合に、デバイスの受信パラメータをリセットするのに有用です。
例：このメカニズムは、現在のダウンリンク構成ではダウンリンクで到達不能となったデバイスに対し、RX2ウィンドウのデータレートおよびRX1ウィンドウのデータレートオフセットを変更するために使用される可能性があります。
再参加手順は、常にエンドデバイスから再参加要求メッセージを送信することで開始されます。

注記： ネットワークバックエンドがReJoin-Request（タイプ0、1、または2）を処理し、Join-acceptメッセージを生成するたびに、新しいコンテキストを使用した最初の成功したアップリンクフレームを受信するまで、古いセキュリティコンテキスト（鍵およびカウンタ、存在する場合）と新しいコンテキストの両方を維持しなければなりません。その後、古いコンテキストは安全に破棄できます。いずれの場合においても、ネットワークバックエンドによるReJoin-requestメッセージの処理は、標準的なJoin-requestメッセージの処理と同様です。すなわち、メッセージを最初に処理するネットワークサーバーは、応答としてJoin-acceptメッセージを作成するために、そのメッセージをJoinサーバーに転送すべきかどうかを判断します。

エンドデバイスが送信可能なRejoin-requestメッセージには3種類あり、それぞれ異なる目的に対応します。Rejoin-requestメッセージの最初のバイトはRejoin Typeと呼ばれ、Rejoin-requestのタイプを符号化するために使用されます。以下の表は、各Rejoin-Requestメッセージタイプの目的を説明しています。

RejoinReq タイプ　内容と目的
0　NetID+DevEUI を含みます。すべての無線パラメータ（devAddr、セッションキー、フレームカウンタ、無線パラメータなど）を含むデバイスコンテキストをリセットするために使用されます。このメッセージは、受信ネットワークサーバーによってデバイスのホームネットワークサーバーにのみルーティングされ、デバイスのJoinServerにはルーティングされません。このメッセージのMICは、サービス提供ネットワークサーバーまたはホームネットワークサーバーによってのみ検証可能です。
1　JoinEUI+DevEUIを含みます。初期のJoin-Requestメッセージと完全に同等ですが、デバイスを切断せずに通常のアプリケーション通信上に送信可能です。受信ネットワークサーバーは、このメッセージをデバイスのJoinServerにのみルーティングできます。失われたセッションコンテキストを復元するために使用されます（例：ネットワークサーバーがセッションキーを喪失し、デバイスをJoinServerに関連付けられない場合）。このメッセージのMICを確認できるのはJoinServerのみです。
2　NetID+DevEUIを含みます。デバイスの再鍵設定、またはDevAddr（デバイスのアドレス、セッション鍵、フレームカウンタ）の変更に使用されます。無線パラメータは変更されません。このメッセージは、訪問ネットワークからデバイスのホームネットワークサーバーにのみルーティングされ、デバイスのJoinサーバーにはルーティングされません。このメッセージのMICは、サービス提供ネットワークサーバーまたはホームネットワークサーバーでのみ検証可能です。