这个处理流程应用在LoRaWAN1.1的终端设备和网络中。
9.1 切换漫游开始流程
下图说明一个终端设备的持续的LoRa会话切换漫游的信息流流程。在后面章节会介绍基于一个新的LoRa会话的切换漫游流程。
Step 0:
前提是终端设备已经激活在NS1。因此，NS1在流程中扮演fNS、sNS、hNS角色对于终端设备。
Step 1:
终端设备在响应接收ForceRejoinReq MAC命令(未显示)或在没有外部触发器的情况下自动发送一个0类型的Rejoin-request消息。
Step 2:
如果NS2作为接收DevEUI所标识的终端设备的sNS，并且NS2没有通过发送ForceRejoinReq请求类型0的应答请求，然后NS2将静静地丢弃这个消息并终止处理流程。
如果NS2不作为终端的sNS，然后NS2将根据Rejoin-request中的NetID查询漫游策略。如果NS2没有配置使能切换漫游基于标识，然后NS2将修改Rejoin-request并终止流程。否则，如果NS2没有配置NS1的IP地址/主机名通过外部的机制，NS2将使用DNS发现NS1的IP地址。
Step 3:
当在NS2的缓存中没有终端对应的设备属性时，NS2将发送一个携带DevEUI的ProfileReq消息到NS1，如果ProfileReq消息不发送，Step 4和Step5被跳过。
Step 4:
NS1将查询它的漫游策略基于接收到的NetID。
Step 5:
如果NS1配置为允许与NS2和终端设备进行切换漫游，则NS1应向NS2发送ProfileAns消息携带Result=Success，设备属性和设备属性时间戳（它携带最后一个设备属性更改的时间戳）。如果不允许切换漫游，ProfileAns消息将携带Result=NoRoamingAgreement 或者 DevRoamingDisallowed和Lifetime并且流程终止。Lifetime允许NS1请求NS2在生命周期到期之前，不为终端设备发送额外的ProfileReq消息。
Step 6:
NS2将向NS1发送HRStartReq消息，其中包含Rejoin-request、MACVersion、ULMetadata、Device Profile Timestamp，以及NS2指定的终端设备的DevAddr、DLSettings、RxDelay和可选的CFList参数。NS2将MACVersion的值设置为终端设备与NS2之间的最高通用版本。
Step 7:
如果NS2或者终端设备不允许切换漫游，或者如果消息的MIC校验失败，然后NS1将执行Step 9。切换漫游被拒绝可能是由于每台NS或者每台设备的漫游策略，或者当终端设备已经被另一台sNS服务时，可能不需要切换漫游。
如果NS1确定Device Profile自接收到Device Profile Timestamp所指示的时间以来发生了更改，那么NS1将得出结论，NS2具有陈旧的Device Profile信息。在这种情况下，NS1将继续执行Step 9。
否则，NS1将转发RejoinReq信息到JS，其中包含接收来自NS2的Rejoin-reques、MACVersion、MACVersion、DevAddr、DLSettings、RxDelay、CFList。
Step 8:
JS服务按照MACVersion处理Rejoin-request，一旦如果Rejoin-Request JS被接受，并且发送一个携带Result=Success的RejoinAns消息到NS1，物理层消息载体包含Join-accept、SNwkSIntKey, FNwkSIntKey, NwkSEncKey, Lifetime。否则JS将发送一个RejoinAns消息给NS1，并包含Result=UnknownDevEUI 或者 MICFailed。
NS1将接收到的Lifetime值视为它分配给LoRa会话的会话生命周期的上限。
Step 9:
如果在第7步中NS1决定不允许切换漫游，然后NS1将发送一个Result为失败的值的HRStartAns消息和Lifetime给NS2。生命周期允许NS1请求NS2在生命周期到期之前不为终端设备发送额外的HRStartReq。
如果NS1断定NS2所知道的Device Profile过时，那么NS1将向NS2发送HRStartAns消息，其中携带Result=StaleDeviceProfile、最新的Device Profile以及Device Profile Timestamp。NS2将跳转会步骤6以使用它刚刚收到的新的Device Profile。
否则，NS1转发接收到的RejoinAns的payload作为HRStartAns消息转发到NS2，包含DLMetadata 和Service Profile。NS1将同时缓存接收到的SNwkSIntKey，以至于在决定转发它们到JS之前可以对Rejoin-Type 0 的消息做MIC验证。
Step 10:
如果HRStartAns消息指示成功。然后NS2将转发接收到的消息到终端设备作为Join-accept。否则，NS2将不发送任何响应报文到终端设备。
如果Rejoin处理流程成功，然后NS2将开始转发接收到的报文从终端设备到NS1，并且NS1将收到报文从NS2。同时，NS1将开始转发接收到的报文从AS到NS2，NS2将接收此包佛那个NS1。
Step 11:
终端设备发送他的第一个上行报文。NS2传输这个报文到NS1。
Step 12:
只要第一个来自终端设备的上行报文被接收，NS2开始做为sNS并且NS1同时作为sNS服务。与此同时，NS1继续作为终端设备的hNS。
包传输
在切换漫游的情况下，hNS和sNS将和使用和被动漫游方式一样的XmitDataReq/Ans消息。仅仅不同的是，hNS-sNS携带的FRMPayload代替了PHYPayload，并且ULMetadata/DLMetadata包含了不同的对象集，具体在后面描述。
切换漫游终止
下图说明当终端设备通过切换漫游到一个新的sNS之后，hNS终止与先前的sNS服务的切换漫游。
Step 0:
终端设备在NS1和NS2之间实现切换漫游。
Step 1:
终端设备在NS1和NS3之间实现切换漫游。
Step 2:
通过新的sNS（NS3）接收来自终端设备的第一个上行报文。
Step 3:
当NS1接收到第一个来自终端的报文通过新的sNS（NS3），NS1将发送HRStopReq消息到先前的sNS（NS2）并携带DevEUI。
如果HRStopReq消息携带可选的Lifetime，这意味着NS1不希望在规定的时间内从NS2收到另一个HRStartReq。
Step 4:
如果NS2通过接收到的DevEUI标识的终端设备已经激活切换漫游并结合NS1，那么先前的服务sNS（NS2）将终止切换漫游并且将发送一个携带Result=Success的HRStopAns报文给NS1。如果NS2结合NS1不存在该终端的一个激活的切换漫游，然后NS2将发送一个携带Result=UnknownDevEUI的HRStopAns到NS1。
Step 5:
针对该LoRa会话的终端设备，NS2停止作为sNS服务。如果NS2使能被动漫游和其他的NS服务对于这个LoRa会话的终端设备，然后这个NS2也将终止这个被动漫游。
如果之前使用HRStopReq命令终止了对终端设备的切换漫游，一个新的HRStopReq命令它的Lifetime值将被设置为0，允许NS2接收到一个新的Rejoin-request Type 为0的消息时，再次发送这个终端设备的HRStart消息。
另一种情况当sNS决定终止漫游时，切换漫游被终止。sNS可能先于中断流程通过发送一个ForceRejoinReq命令给终端设备。然后，sNS将发送一个HRStopReq到hNS并携带DevEUI。如果该hNS通过接收到的DevEUI辨别的终端设备已经激活了切换漫游，这个hNS将终端切换漫游，发送一个HRStopAns报文到sNS并携带Result=Success。如果hNS没有该终端设备的激活切换漫游，然后hNS发送一个HRStopAns带sNS并携带UnknownDevEUI。如果sNS接收一个失败的Result来自hNS，这个sNS可能仍然终止切换漫游。
hNS恢复控制
下图说明说明hNS通过当前服务的sNS的控制变成sNS的信息流程。
Step 0:
终端设备在NS1和NS2之间执行切换漫游。
Step 1:
NS1决定变成sNS。
Step 2:
NS1将发送一个HRStartReq消息到NS1，并携带DevEUI启动切换漫游。
Step 3:
如果NS2通过接收到的DevEUI标识的终端设备已经激活切换漫游，NS2将发送HRStartAns到NS1，并携带Result=Success，否则Result=UnknownDevEUI。
Step 4:
NS2将初始化网络触发的切换漫游。当这个处理流程被初始化，NS2断定终端设备在NS1的无线覆盖范围内，并且NS1拒绝来自其他的NS服务的切换漫游，包括NS2，然后变为sNS。
Step 5:
NS1接收到直接来自终端设备的第一个上行报文。
Step 6:
NS1将执行切换漫游停止流程与NS2，具体在其他章节已经描述。
Step 7:
对于上述LoRa会话的终端设备，NS2停止作为sNS服务。如果对该LoRa会话的终端设备，NS2与其他的NS已经使能了被动漫游，然后这个NS2也将终止与该NS的被动漫游。
否则，NS2等待知道终端设备将通过自身决定初始化切换漫游，有效的跳过Step 2和3，直接到Step4-7。