在上期的文章里，我们一起了解了 OceanConnect 物联网平台的部分内容。后台也收到了不少小伙伴的提问，主要聚焦关于 NB-IoT 终端如何进行拥塞控制，以及如何定位上。今天我们就来讲：
&NB-IoT 上行离散控制
&NB-IoT 下行拥塞控制
&NB-IoT 位置服务
&支持 Non-IP
NB-IoT 上行离散控制
大量设备并发接入网络，造成网络拥塞甚至雪崩。NB-IoT 上行离散控制是一种通过平台统一为设备分配上线时间，让设备可以错峰接入的特性。
实现原理
IoT 平台新增上行离散微服务，提供调度分配算法。设备接入数分布的生成，需要用户到OP Portal上打开「设备并发接入控制」开关，打开后OP Portal的KPI中会统计每分钟小区接入设备数并呈现在界面上。
打开开关时需要设置「无线侧保活时长」参数，IoT 平台收到设备的消息（设备注册/数据上报/命令响应）时，如果距离上一次收到设备发送的消息时间超过设置的无线保活时长，则记录为一次新的设备接入事件，IoT 平台的接入数统计加1。
上行离散业务流程如下：
平台持续统计小区每分钟接入设备个数。
1、设备首次上线时，会携带CELLID字段。
2、IoT 平台根据CELLID统计每个小区每分钟的设备接入数
3、应用向平台请求调度，请求设备可上线的时间段。
4、平台根据前一天统计的接入数分布，识别最空闲的时隙为应用请求的设备分配可上线时间段。
5、平台将设备可上线的时间段返回给应用。
说明：若应用请求调度的设备自身可存储上线时间，那么平台在计算出空闲时隙后，会直接下发命令到设备，通知设备更新上线时间；若设备本身不具备存储上线时间的能力，则平台将空闲时隙仅返回给应用。
6、应用可根据实际情况选择对设备下发命令的时间。
特性价值
在 NB-IoT 网络中，通过上行离散控制技术，实现控制设备的上线时间，可提高设备的上线率。
应用场景
当有大量的NB-IoT 设备需要上线时，为保证设备上线率，可以使用该特性，使设备可以错峰接入，提高设备上线率。
约束与影响
当前平台只在设备注册时查询设备的小区ID，如果设备移动导致小区ID 变化，则平台无法获取实时的小区ID，因此设备移动会导致小区接入统计的不准，进一步影响上行离散的效果。
NB-IoT下行拥塞控制
NB-IoT 下行拥塞控制是一种通过 IoT 平台控制并发寻呼数的特性，保证从 IoT 平台或应用下发到网络侧的消息数不超过网络处理能力，从而实现网络拥塞控制。
实现原理
NB-IoT基于信令面的数据传输组网结构如图所示：
NB-IoT基站的空口寻呼能力资源有限，并随基站信号的覆盖等级不同而变化。为保证重要业务预留资源，有限的空口寻呼资源不能被完全占用，需要对寻呼并发数进行控制。即同一个小区内，同一时间通过TMSI（Temporary Mobile Subscriber Identity）或IMSI(International Mobile Subscriber Identity)来寻呼终端的消息数量不能超过小区的寻呼能力。
如表1所示，在eRAN12.1SPC220版本在覆盖等级0时，每一秒中最多支持15个通过 IMSI号来寻呼终端。
当应用跟设备进行通信时，会对处于空闲状态的设备发送寻呼请求，如图所示的数据传输流程，寻呼主要作用于5~7步。
说明： 如果设备与 IoT 平台之间在 20 秒内有消息收发，则判定设备处于连接状态，否则为空闲状态。
网络侧发起的数据传输流程如下:
如果当寻呼请求个数大于空口寻呼资源时，网络会发生拥塞，基于以下两个方面原因会进一步加剧网络拥塞：
&&&如果IoT 平台或应用下行消息的速度大于基站寻呼并发能力，基站会缓存寻呼请求。但下行消息等不到及时响应后，平台或应用又会重发下行消息，可能会加剧拥塞。
&&&MME与UE之间寻呼不成功时，MME会重新给基站下发寻呼指令，同时MME还会扩大寻呼范围，向多个基站下发寻呼指令。与此同时基站无法识别同一个设备的多次寻呼请求，因此随着请求数增加，也会加剧基站的拥塞。
NB-IoT 下行拥塞控制实现流程如下：
****网络应用 NA 向设备发出下行消息。
****IoT 平台检查是否需要对下行消息进行流控。流控判断标准参考约束与影响。
是=>参考 3
否=>转发给 MME 处理，参考 4
****判断当前下行消息数是否超过小区空口寻呼资源阈值。
是=>判断消息类别，如果是立即下发类型消息，直接报错不下发，如果是缓存下发类型消息，将消息写入到消息等待队列等待下发。
否=>直接下发消息，针对空闲状态的设备，MME 下发寻呼请求。
****针对空闲状态的设备，MME 下发寻呼请求。
特性价值
在 NB-IoT 网络中，通过下行拥塞控制技术，实现控制并发消息数，防止因短时间大量的寻呼指令抢占寻呼资源导致网络拥塞或雪崩等问题，同时为重要业务预留一定的空口寻呼资源。
应用场景
当基站的空口寻呼资源有限且需要为重要业务预留资源或者网络可能发生拥塞时，针对立即下发及缓存下发两种请求，实施下行拥塞控制，减少从IoT 平台或应用下发到网络侧的寻呼数，从而实现网络拥塞控制目标。
&&&针对立即下发的下行消息，如果基站小区寻呼并发数超过小区阈值时，则直接拒绝该请求，减少下发的下行消息数量。
&&&针对缓存下发的下行消息，如果基站小区寻呼并发数超过小区阈值时，则排队等待，延迟下行消息的下发时间。
约束与影响
除以下情况外，IoT 平台都会对下行消息进行控制：
A设备处于 eDRX 模式
B设备处于连接状态
C设备的所归属的 Cell ID 未查询到
D未通过 Post command 接口下发下行消息
**
NB-IoT 位置服务
**
NB-IoT 位置服务是指通过配置 IoT 平台对接 GMLC（Gateway Mobile Location Center），可以使物联网平台集成 GMLC 的定位能力，通过测量无线信号来确定 NB-IoT 设备地理位置信息及其移动速度等能力。
实现原理
IoT 在 GMLC 中的位置
UE 通过 LPP 协议将 ECID(Enhanced Cell ID) 测量信息上报到 E-SMLC，后者进行位置计算并通过 GMLC 开放给 IoT 平台。平台向 NA 提供位置服务开放，可以支持应用实时查询设备位置、订阅或取消订阅设备的功能，以下是三种功能的交互流程。
下图中 LCS 为 Location Service ，代表 IoT 平台。
位置的实时查询流程：
位置的订阅通知消息流程：
取消位置订阅通知消息流程：
特性价值
通过物联网平台集成 GMLC 的定位能力，实现对 NB-IoT 设备的位置定位。
应用场景
当应用或者 IoT 平台查询设备位置信息时使用该功能。
约束与影响
当前 IoT 平台只支持对接一个 GMLC，不支持对接多个 GMLC。
支持 Non-IP
Non-IP 是指终端在接入平台的时候不依赖 IP 地址，而是通过运营商分配的 ExternalID（外部 ID）获取到 DeviceID，并用 DeviceID 与IoT 平台进行交互，这样可以确保终端不暴露在 IP 网络上，从而避免一切基于 IP 技术的攻击和远程控制。
实现原理
Non-IP 端到端业务流程：
***应用下发命令到 IoT 平台。
***IoT 平台根据设备当前状态（ PSM、DRX、eDRX 模式策略不同）决定缓存数据还是立即下发。
***IoT平台感知到设备上线后，创建 NIDD（Non-IP Data Delivery，Non-IP 数据传输）下行投递，下发命令到 SCEF，指定立即下发模式。
***SCEF 投递数据到设备，同时反馈投递结果到 IoT平台。
***IoT平台收到投递结果，向应用上报命令已经到达设备。
***设备处理数据，处理完毕后，如果有命令执行结果，则上报给 SCEF。
***SCEF 收到命令执行结果，上报 IoT平台。
***IoT平台回复收到数据。
***IoT平台收到数据后，业务匹配该数据是命令执行结果，通知应用此次命令执行结果。
APP 寻址设备，仍然通过 DeviceID，平台收到 APP 的 DeviceID 后转换成 ExternalID，加上自身的 scwAsId（该 ID 由 SCEF 分配，平台部署时配置），下发给 SCEF，SCEF 通过核心网寻址设备。
***SP 用户从设备制造商处购买设备。
***设备制造商提供设备给 SP 用户，并提供设备 IMEI。
***运营商客户在运营商开户 （比如购买 NB-IoT 设备 SIM 卡）。
***HSS 分配 ExternalID，保存 <externalID、IMSI>关系，返回该关系给运营商客户。(注：实际局点中，***看运营商业务模型，有可能一次返回 <ExternalID、IMSI>。也有可能分两步，先开户返回 IMSI 给运营商客户，运营商客户用 IMSI 申请业务，再返回 <ExternalID、IMSI>关系。)
***运营商客户将 <ExternalID、IMSI>关系同步给 SP 用户。
***SP 用户通过IoT平台北向接口开户，录入 <IMEI、ExternalID>信息。
***IoT平台返回 DeviceID 给 SP 用户，后续 SP 用户通过该 DeviceID 访问设备。
若 ExternalID变更，则运营商客户通知运营商变更 <ExternalID、IMSI>的关系，HSS 更新 <ExternalID，IMSI>关系，并通知 SCEF 变更，SP 用户通过IoT 北向接口更新 <DeviceID、ExternalID>关系。
设备注册流程如图所示：
***设备注册前，平台需要已完成 NIDD（Non-IP Data Delivery，Non-IP 数据传输）配置。
***设备注册报文到达 CIG 后，CIG 完成 SCEF over HTTP 的协议栈解析后，回复 SCEF（Service ***Capability Exposure Function）。
***CIG 继续解析 coap over LWM2M 之后，上报设备注册消息到 CM。
***CM 处理设备注册消息。
***CIG 同时组帧设备注册响应报文，发送给 SCEF（Service Capability Exposure Function）。
特性价值
使用该特性后，NB-IoT 设备无需获取公网 IP 地址，节省了公网 IP 资源，同时避免了因为终端被控制，导致 IoT平台收到基于 IP 网络的 DDoS 攻击。
应用场景
适用于 NB-IoT 设备使用的各种场景，防止终端数据在传输过程中被攻击。
影响与限制
仅限于 NB-IoT设备使用该特性。