LoRaWAN1.1-被动漫游（8）

Lora 的漫游存在两种，分别是被动漫游和切换漫游。被动漫游是在多个网关的情况下，网关是由不同的NS控制，而在两个网络中存在重叠的RF，终端设备可以自由的切换(此段话完全是自己的理解～)。终端的LoRa会话和Mac层控制都被在先前的NS服务中维持，这个NS叫做sNS，然而从空口接收到的数据帧被转发后面的NS处理，这个后面的NS叫做fNS。对于一个LoRa会话只能有一个sNS服务，然而存在相同的会话的fNS服务可能一个都没有或者多个fNS。

存在两种类型的fNS服务，有状态的和无状态的。一个有状态的fNS在一系列的被动漫游过程中创建一个终端的上下文并且利用这个上下文来处理该终端的任何的上下行报文。一个无状态的fNS不会创建上面提到的上下文，因此处理的所有上下行报文都是独立的。

切换漫游允许MAC层控制从一个NS转移到另一个NS。即使在终端设备从一个NS到另一个NS执行切换漫游之后，hNS仍然使用JS和AS维护控制面板和数据面板。对于给定的LoRa会话，hNS保持不变直到终端设备执行下一个连接过程。与fNS不同，sNS具有控制终端FR设置的能力，这将允许更灵活的漫游场景。

被动漫游和切换漫游

上图是一个在LoRa会话中同时使用切换漫游和被动漫游的例子。在这个例子中，终端设备被激活通过作为hNS角色的NS1。随后，当NS2变成sNS，终端设备将进行切换漫游从NS1到NS2，当NS3变为fNS，终端设备将进行被动漫游从NS2到NS3。

漫游激活在访问的NS覆盖范围内是终端设备进行激活的能力。

这个规格描述了如下漫游过程：

- 被动漫游在一个持续的LoRa会话期间

- 切换漫游在一个持续的LoRa会话期间

- 漫游激活一个新的LoRa会话基于切换漫游在hNS和访问的NS之间

- 漫游激活一个新的LoRa会话基于被动漫游在hNS和访问的NS之间

当hNS和和访问的NS没有任何漫游协议时激活一个新的LoRa会话超出了本规范的范围。这包括两个NS服务可能与第三个NS有漫游协议的情况。(例如hNS和第三方NS服务有切换漫游协议，第三方NS服务和访问的NS有一个被动漫游协议)

漫游策略

每一个网络运营商将被配置一个漫游策略来单独的允许/不允许被动漫游、切换漫游、基于被动漫游的激活、基于切换漫游的激活以及其他的网络运营商通过他们的NetID。

对于被动漫游，这个策略将包含对上行报文是否由fNS做MIC校验。

每一个网络运营商将被配置一个允许/不允许被动漫游、切换漫游、基于被动漫游激活的漫游策略，基于切换漫游激活的策略是独立的由DevEUI区分。

被动漫游

这个流程在终端设备和网络适用LoRA1.0和LoRa1.1协议。

下图展示了对于一个持续的LoRa会话的终端设备，在两个NS服务之间被动漫游信息流的流程。响应的基于被动漫游激活一个新的LoRa会话流程在后面章节介绍。

被动漫游

Step 0:

终端设备被激活通过NS1.

Step 1:

当终端设备传递一个报文到NS2，NS2不包括任何的与这个终端设备对应的上下文信息。

Step 2:

如果NS2被网络运营商配置为使能被动漫游，然后该NS2将尝试将接收到的数据包中的NwkID映射到与它有被动漫游协议的运营商NetID。如果映射失败，NS服务将丢弃这个报文流程终止。

Step 3:

如果一个或多个匹配的NetID被匹配到，如果NS2没有通过一个额外的机制去配置NS的IP地址/主机名，NS2服务将使用DNS解析去查找每一个匹配的NetID对应的IP地址。如果有多个匹配的，对于每一个匹配的NS将执行下面的Steps 4-6。

Step 4:

NS2将发送一个PRStartReq消息到NS1，包含传入数据包的PHYPayload和相关的ULMetada。

Step 5:

NS1核实是否已经存在一个被动漫游协议基于网络运营商通过NetID，并决定回复的PRStartAns携带的内容，如果没有协议发现，PRStartAns里面携带的Result=NoRoamingAgreement信息。

NS1将在终端发送的PHYPayload报文中提取DevAddr，区分相对应的网络会话密钥对(SNwkSIntKey和FNwkSIntKey在LoRa1.1协议中，NwkSKey是LoRaWAN1.0)，校验PHYPayload中的MIC。如果网络会话密钥对没有找到或者MIC校验失败，NS1将返回一个携带Result=MICFailed的PRStartAns应答。

Step 6:

在被动漫游的生命周期中，如果辨认到终端设备被配置为使用被动漫游，并且NS1断定使能被动路由通过NS2，NS1将发送一个携带Result=Success的PRStartAns报文到NS2。如果NS2作为一个有状态的fNS服务，NS1将包含DevEUI和ServiceProfile。如果NS1与NS2之间的被动路由协议要求NS2对上行报文进行MIC校验，则在回复的PRStartAns消息中需要包括FCntUp和FNwkSIntKey（LoraWAN1.1）或NwkSKey（LoraWAN1.0）。

如果NS1不希望启动NS2的被动漫游，然后他想发送一个携带Result=Deferred的PRStartAns报文给NS2，对于同一个终端设备的上行报文NS2，将不在发送任何PRStartReq到NS1.

如果错误发生在第5步，NS1将发送一个携带相应Result信息的PRStartAns到NS2。

在同一时刻，NS1可能接收到来自多个NS的PRStartReq，断定是否对这些NS开启被动漫游。

连接有效生命周期到期，NS1和NS2将自行终止被动漫游（即彼此之间不涉及额外的信号），除非在期满前被动漫游通过一个新的PRStartReq/PRStartAns延期，这个NS1将设置被动漫游模式的期限为0。

Step 7:

只要NS2收到成功的PRStartAns它就变成一个fNS对于一个终端设备。NS1继续作为sNS。

在此之后，NS2将转发来自终端的报文到NS1，NS1将接收这些报文来自NS2。NS1也将NS2标记为fNS的候选者为终端发送报文。NS2将接收来自NS1的报文并转发给终端通过网关。

包传输

下图说明在被动漫游的模式下从终端设备发送和接收信息流程。即使该流程显示的是一个上行数据包紧跟着一个下行数据包，但该数据流的上下行顺序可以按照终端设备的Class等级独立运行的。

在无状态的fNS处理流程下，每个上行的报文将被处理按照上面的流程处理。

被动漫游下的包传输

Step 0:

有状态的被动漫游在fNS和sNS之间使能。

Step 1:

终端设备传输一个包从fNS接收到的包。

Step 2:

在sNS-fNS被动漫游协议中，如果fNS被要求对上行的报文进行MIC校验，然后fNS将从报文中提取终端的DevAddr，辨认FNwkSIntKey/NwkSKey并校验MIC。如果FNwkSIntKey/NwkSKey没有找到或者MIC校验失败，fNS将丢弃这个报文。

Step 3:

如果终端设备被识别，fNS将接收到的报文的PHYPayload字段发送到辨别这个终端的sNS服务通过一个XmitDataReq消息和ULMetadata。

Step 4:

sNS将发送一个XmitDataAns消息回复给fNS携带XmitDataReq结果。

Step 5:

sNS发送一个包到终端设备。

Step 6:

sNS决定是否通过它控制下的某一个网关或者fNS控制下的某一个网关发送这个报文。

Step 7:

如果sNS决定发送报文通过一个fNS，sNS将发送XmitDataReq消息给fNS携带PHYPayload和DLMetadata信息。

Step 8:

如果在接收到的XmitDataReq又一个错误发生，fNS将发送一个携带Result为失败值的XmitDataAns消息给sNS，并且将不尝试传输这个报文。否则，fNS将尝试将来自sNS的报文传输到终端设备。如果元数据包括GWInfo.ULToken，fNS可能使用这个字段来选择下行的网关。由于时间限制和网络条件，fNS可能传输数据包失败。一旦发生，fNS将不会重试传输。

Step 9:

在传输包之后，fNS将发送一个XmitDataAns消息给sNS，并携带DLFreq1或DLFreq2或者两者都同时携带（取决于包是通过RX1或者RX2或者两者）在传输成功的情况下。

被动漫游停止

下图说明了终止被动漫游的信息流程图。这个处理流程只是针对于有状态的fNS服务。

sNS终止被动漫游

Step 0:

被动漫游在fNS和sNS之间使能。

Step 1:

在终端设备被动漫游有效期截止之前，sNS想要终止被动漫游，sNS将发送PRStopReq消息给fNS服务，其中包括DevAddr、DevEUI以及可选的Lifetime。如果fNS是有状态的并且在规定的时间内不希望接收接收来自fNS的PRStartReq，sNS则包含Lifetime。

Step 2:

fNS通过DevEUI来核实已经处于被动漫游的终端设备并与sNS关联。如果两个条件都满足，fNS将发送PRStopAns消息给sNS，其中携带Result=Success。否则fNS将发送Result=Success消息，其中携带Result=UnknownDevEUI。如果接收到的PRStopAns包含Lifetime，然后fNS将不发送PRStartReq消息到sNS直到Lifetime过期。

fNS终止被动漫游

Step 0：

被动漫游模式使能在fNS和sNS之间。

Step 1:

在被动漫游有效期截止之前，当fNS决定终止被动漫游，fNS发送PRStopReq消息给sNS，其中携带终端设备的DevEUI。

Step 2:

sNS将核实终端设备基于D额 vEUI是否由他自己服务并且在fNS中处理被动漫游。如果两个条件同时满足，sNS将发送携带Result=Success的PRStopAns消息给fNS。否则，sNS将发送携带Result=UnknownDevEUI的PRStopAns消息给fNS。

被动漫游终止以后，对于指定的终端设备sNS和fNS将停止在彼此之间转发报文。