支持NB-IOT终端低功耗模式的空口会话保持和指令缓存技术

时间：2024-05-04

朱明

（天翼物联科技有限公司江苏省南京市 210006）

1 背景介绍

NB-IoT 业务规模发展与所承载业务模型密切相关，如表1所示的技术特点，其能适用场景是“小流量、上报为主、长期休眠、功耗敏感性、低移动性”应用。为了实现NB-IoT 网络承载海量的低功耗终端，可管可控。其最为重要的4 个技术要素为：eDRX、PSM、空口会话保持和下行指令缓存。

这四个技术要素中，3GPP Release 12 规范里就定义了PSM，Release 13 规范里也引入了eDRX 技术。如果采用PSM 和eDRX 技术，要对NB-IOT 终端的低功耗产生有益的影响，除了取决于终端本身的软硬件能力及配置外，还取决于与之相配套的网络侧的实现。这些在3GPP 规范已经定义的网络侧能力及配置的参考实现中，基本都有章可循。差别仅仅在于终端支持的低功耗能力，在网络不同情况下，配置亦可以不同（主流终端不支持的能力，一般网络都不会配置）；不同终端用于不同的低功耗业务场景，需要网络侧给予配合的协同参数也有所不同。

但是对于终端低功耗所需要依赖的另外两个重要技术特性：空口会话保持和下行指令缓。在3GPP 规范中，并没有明确的描述和参考定义。本文将分别从网络和平台两个方面的架构优化和相应的参考实现，论述这两个技术要素对终端低功耗，同时也是对PSM的重要作用。

2 空口会话保持(免心跳)模式

eDRX（扩展不连续接收）和PSM（省电模式）模式，虽然可以给NB-IOT 终端提供省电的可能，但是这种省电的是以牺牲终端和物联专网的NB-IOT 网关的连接次数作为代价，通过长时间的“罢工”来换取的。事实上，在所有物联网的应用场景中，终端UE 可以通过IP 地址、域名等方式找到NB-IOT 网关的服务器。但是由于现网IPv4 地址的局限性，物联网终端自己是没有域名，也没有独立不变的IP 地址，物联网专网为客户NB-IOT 终端分配的是10网段的私网地址，通过NAT 的转换，将私有IP 地址转化为公用IP地址，服务器才能找到终端。由于在物联网专网中存在多个防火墙，涉及到私网IP 与公网IP 的转换。NB-IOT 终端采用的轻量化CoAP协议的传输层采用的是无连接的UDP 协议，大概120 秒左右终端的会话就会释放（即使采用TCP 协议，1200 秒会话也会被NAT 释放），所以NB-IOT 网关的服务器将无法寻找到终端，因此下行的指令也无法通过IOT 平台的服务器下发到终端。对于电子锁具，消防控制终端，路灯、白电这类有实时控制需求的终端，终端如果不接对采用和NB-IOT 网关保持频繁心跳的方式维持空口建立以后的会话，以保证下行可达，频繁的心跳不仅会带来无线资源的浪费同时也会增加终端的功耗和连接次数。而这种增加和NB-IOT 网关间的心跳包连接次数的方式和eDRX、PSM 模式以牺牲连接次数换取低功耗的方式是截然相反和矛盾的。

针对这样存在的问题和矛盾，本文给出了以下NB-IOT 网关的解决方案的参考实现，并在现网测试中取得了很好的效果。

图1：NB-IOT 网关空口会话保持模型

图1 为保持长连接空口会话的网络架模型，网关采用了负载均衡LVS(Linux 虚拟服务器)，构建负载均衡集群。通过LVS 维护一个映射表，映射算法是源地址和目的地址均映射，LVS 在处理请求时，会保存终端、真实服务器的信息，存储在跟踪表中。跟踪表信息在一定程度上呈现了与会话一样的状态。

基本原理是：LVS 接收NB-IOT 终端请求，并转发到真实服务器时，在跟踪表会刷新一条跟踪信息，包含源地址/目的地址五元组转换，在收到服务器的响应消息时，会根据跟踪表信息找到此消息对应的终端IP 和端口，然后对报文进行处理，然后返回给终端。如果跟踪信息过期，LVS 就不会处理响应报文，可能导致终端无法收到消息。

转换流程如下：

（1）NB-IOT 终端上传报文。

（2）LVS 转发给后端真实服务器，刷新跟踪表。

（3）指令下发到LVS，跟踪表若存在，则下发给终端，若不存在，则下发失败。

目前采用该模型的NB-IOT 网关在现网中已经实现24 小时的空口会话保活(支持超过4500 万终端)，只要NB-IOT 终端在24内存在一次业务数据包的上下行传输，即可确保下行时可达的，终端无需发送心跳包，从而可以降低终端的功耗，减少上报次数，满足PSM 模式和节约终端耗电量的需求，降低用户的使用和更换终端电池的成本。未来随着IPv6 的部署，该模型将被进一步简化。

3 下行指令缓存机制(网关连接型)

除了采用空口会话保持技术降低终端功耗外外，下行指令缓存机制对于保障PSM 和eDRX 模式下终端的控制也是至关重要的。3GPP 的规范和协议中有对下行指令缓存的要求，但并不设计具体实现的研究，本文接下来将对下行指令缓存(网关连接型，即NBIOT 终端通过NB 业务接入网关与北向的客户应用相连)的具体实现逻辑和技术要点进行分析和阐述。

图2：eDRX 模式下指令数据不可达处理流程

图3：PSM 模式下指令数据不可达处理流程

下行指令缓存的基本场景和过程是：当NB-IOT 终端处于PSM模式时，终端与基站之间的空口已经释放，无法接收下行数据。NB 业务接入网关为客户应用提供了下行指令缓存的功能，NB-IOT网关能够感知终端的状态，当终端处于PSM 模式时，NB 网关将会对下行数据进行缓存。当终端退出了PSM 模式能够接收下行数据时，网关将会立即将缓存数据下发，确保客户业务数据下发的可靠性。由于PSM 和eDRX 模式涉及终端、网关、网络配置的协同配合，因此要实现下行指令缓存机制，本质上还要考虑四个方面的重要机制，分别是离线缓存机制，在线缓存机制，以及指令发送超时处理机制，指令超期处理机制。

3.1 下行指令缓存的逻辑过程

当应用向NB-IOT 网关下发指令后，网关根据指令携带的TTL(Time To Live 生存时间值，是IPv4 报头的一个8 bit 字段)参数判断是立即下发指令还是缓存下发指令。TTL=0：立即下发指令。TTL＞0：缓存下发指令。缓存时间依据指令下发API 接口携带的TTL 参数时间实现。TTL = 0 时，指令不做任何缓存。若终端在线，则指令直接下发；若终端不在线，则指令直接判断为超期。TTL ＞0 时，指令根据时间顺序存放入队列。当TTL 超期时，缓存队列中的对应指令将被清除，并向应用侧推送指令超期。

NB-IOT 网关对于NB 指令采用队列模式串行下发，即当上一条指令确认送达（收到终端ack）或指令发送超时之后，再触发下一条指令的处理。NB-IOT 网关对NB 指令缓存机制包含离线缓存及在线缓存两种机制。同一终端缓存队列最多支持N 条，即当队列满时应用再次下发指令会收到失败返回。

3.2 离线缓存机制

离线缓存机制，是指当指令下发时，终端处于离线状态下的缓存机制。离线缓存依赖于Redis 实现。指令到达终端接入模块后，终端接入判断终端为离线状态，则将指令根据时间顺序存入redis。终端由离线变为上线时，平台按照redis 中的缓存队列顺序串行下发指令。

3.3 在线缓存机制

在线缓存机制，是指当指令下发时，终端处于在线状态下的缓存机制。指令到达终端接入模块后，终端接入将指令存入终端会话的指令在线缓存队列尾部。指令下发采用队列模式串行下发方式，即当上一条指令确认送达（收到终端ack）或指令发送超时之后，再触发下一条指令的处理。

3.3.1 eDRX 模式下队列处理

对于eDRX 模式在线终端，NB-IOT 网关收到指令将指令存入终端会话的指令在线缓存队列尾部，并触发队列立即下发，指令下发采用串行方式下发。

3.3.2 PSM 模式下队列处理

网关根据PSM 模式的特点，在收到终端的任何上行报文时，设置N 秒(＞20 秒)的空窗期。

（1）若收到指令时，终端不处于空窗期范围内，则指令将存放于在线缓存队列尾部，等待下一次收到任何上行报文后，触发队首的指令下发。

（2）若收到指令时，终端处于N 秒(＞20 秒)空窗期范围内：

（3）若在线缓存队列中无指令，则会直接下发该条指令；

（4）若在线缓存队列中有其他指令，则将该条指令放在队列尾部缓存，同时下发队首的指令。

3.4 指令发送超时处理机制

对于eDRX/PSM 模式，NB-IOT 网关超时判断规则：若网关下发指令后一直未收到终端回复的ack 报文，指令会在下发后，间隔5s、10s、20s、40s 各重传一次，若最后一次下发后N 秒（N＞45 秒）仍未收到ack 信息，则会判断指令发送超时；对于eDRX 模式，网关会根据终端注册时填写的eDRX 超时时间来判断超时，且在整个周期内仅会发送一次。若指令发送超时，则根据省电模式的不同，处理逻辑不同：

（1）对于PSM 模式终端，上一条指令超时，队列发送即停止，等待下一次收到终端的上行报文，继续触发队列的下发；

（2）对于eDRX 模式终端，上一条指令超时后，队列中的后续指令依然继续下发，直到队列为空即止。

3.5 指令超期处理机制

TTL ＞ 0 时，指令根据时间顺序存放入队列。当TTL 超期时，缓存队列中的对应指令将被清除，并向应用侧推送指令超期。

指令超期依赖redis-expire 服务判断，当终端收到指令后，将指令存入缓存队列尾部，同时通知redis-expire 服务将指令及指令超期时间戳存入本地队列，redis-expire 服务定时器循环扫描队列，将超期的指令移出队列并通知终端接入指令超期。

终端收到指令超期通知后，清除本地会话在线缓存队列中的指令或者redis 中缓存的指令。同时生成指令超期通知推送给北向应用。

3.6 网元侧对下行指令的处理机制

上述我们分析了下行指令通过NB 网关进行离线缓存和在线缓存的机制。当缓存的指令下发到网元侧时，针对eDRX 状态和PSM 状态，如果下行指令数据仍不可到达终端，则相应的处理分析如下：

3.6.1 eDRX模式下行指令数据不可达的处理

当前收到DDN（DDN：Downlink Data Notification）消息时刻。

如果在寻呼时间窗口内：

（1）MME向SGW发送DDN Ack并携带DL Buffering Duration信元，通知SGW下行数据的缓存时长。

（2）MME下发Paging寻呼UE。

（3）若缓存时间超时仍没有建立用户面通道，则SGW丢弃缓存下行数据。

如果在寻呼时间窗口外：

（1）MME向SGW发送DDN Ack并携带DL Buffering Duration信元，通知SGW下行数据的缓存时长。

（2）MME启动eDRX延迟寻呼定时器。

（3）eDRX延迟寻呼定时器超时后，向UE下发Paging。

（4）若缓存时间超时仍没有建立用户面通道，则SGW丢弃下行数据。

eDRX模式下指令数据不可达处理流程如图2所示。3.6.2 PSM 模式下行指令数据不可达的处理

如图3所示，当有下行数据，SGW发送Downlink Data Notification消息给MME触发对处于PSM状态的终端的寻呼时，MME可直接通过Data Notification Acknowledge消息携带DL Buffering Duration信元指示SGW缓存数据，也可以在Data Notification Acknowledge消息发送完成后再向SGW发送Downlink Data Notification Failure Indication消息指示SGW丢弃数据，可通过MME本地设置。

若缓存时间超时仍没有建立用户面通道，则SGW丢弃下行数据。