物联网在智慧路灯端到端运营中的应用探讨

2019-01-08叶鑫华中国电信股份有限公司鹰潭分公司鹰潭市33500

江西通信科技 2018年4期

关键词：调光核心网路灯

叶鑫华中国电信股份有限公司鹰潭分公司鹰潭市 33500

王荣中国电信股份有限公司江西分公司网络运行维护部南昌市 330046

周川中国电信股份有限公司江西分公司无线网优中心南昌市 330046

张雷金璇中国电信股份有限公司江西分公司网络运营支撑事业部南昌市 330046

1 简介

智慧路灯是指通过应用先进、高效、可靠的电力线载波通信技术和无线通信技术等,实现对路灯的远程集中控制与管理。与传统的电力线载波通信方式相比，NB-IoT技术构建于蜂窝网络，通信距离长、覆盖范围大，基于运营商公网，稳定性高；不需要集中网关，减少了通信故障点。在城市智慧照明中应用NBIoT技术，可构建更为稳定的路灯物联网，同时能够提高单灯控制的实时性、可靠性和灵活性。

智慧路灯作为NB-IOT网络应用的重要场景，从总体技术架构上，可分为以下四方面：

（1）终端层

终端设备是物联网的基础载体，通过安装智能控制器，可突破电力线载波通信受限于照明控制箱（箱变）的缺点，提高单灯控制的稳定性、实时性和灵活性。通过手机APP，可以实现对每一盏灯的开关及调光等节能控制

（2）网络层

网络是整个物联网的通讯基础，NB-IoT具有覆盖广、功耗低、成本低、大连接等特点，其基于运营商公网，不需要集中网关，具有更高的稳定性。在城市智慧照明中应用NB-IoT技术，可构建更为稳定的路灯物联网，能够提高单灯控制的可靠性和灵活性。

（3）平台层

平台是物联网行业应用的基础，具备连接、数据管理及能力开放的能力，上层应用无需关心终端设备具体数据传输的实现方式。

（4）应用层

对城市道路每盏灯实现全面的感知、智能的控制、广泛的交互和深度的融合，在满足正常照明需求的前提下，通过智能调光、降功率、按需开关灯等管理方式，减少过度照明，电能节约率可达30%～60%。

图1 华为NB-IoT智慧路灯行业解决方案

一般要求智能路灯具备五遥的功能：遥测、遥讯、遥控、遥调和遥视。具体如下：

● 遥控：自动或手动远程控制路灯的开/关/调光，可依据路灯的用途、马路类型分别配置不同的开、关、调光时间。

● 遥测：远程测量单个路灯的电气参数，可使用手持式设备显示或配置参数。

● 遥信：实时回传或轮巡路灯设备的故障和自诊断信息，便于管理部门及时处理，偏离预定阈值及时报送告警信息。

● 遥调：可远程对路灯进行参数调整，可根据经纬度、时间远程调光，实现最大化节能；

● 遥视：可远程查看单个路灯的状态，可定位故障并进行电量采集。

除上述功能外，在实际的项目实施中，还可根据客户需求在此基础上，集成其他增值功能，例如智能广播、环境监测和信息交互等。

图2 华为NB-IoT智慧路灯行业解决方案

按照路灯行业《CJJT 227-2014城市照明自动控制系统技术规程》的要求，智慧路灯的上线率与遥控正确率要高于99%，且单灯控制时延要求小于10s。NBIoT智能路灯的主要业务流程包括下行控制、上行控制以及路灯远程控制等，具体如下：

（1）下行控制：APP触发开关灯命令，下发给平台/核心网，核心网转化为Paging命令下发给终端。

（2）上行控制：主要包括主动数据上报和心跳上报两大类，其中主动数据上报包括上电注册，上报电压、异常告警等信息上报；心跳上报包括周期性心跳上报等。

（3）远程控制：主要应用于重大等突发事件、领导视察、巡测等场景。为达到路灯的二次节能，需要对单灯进行调光，开，关，以及单灯状态的查询，尤其是在突发事件，如重大事件，天气恶劣等情况下需要从云端对路灯进行实时控制；正常情况下是对路灯进行批量操作，对于不同时的场景时延要求不同，如领导视察时延需要控制在1分钟以内，如正常使用时延可以在30分钟之内，如时延太长，可考虑提前下发指令，并不受时延的影响。此外，需要根据路灯类型进行分组如公路灯、街道灯、饰灯、景观灯、CBD、小区等，并采用工作日、节假日、重大活动等不同的制定不同的控制模式。

根据不同的业务场景，建议将重大事件保障、远程控制优先、本地控制优先定义为三种不同的业务配置。对于重大事件保障类，由于时延要求低，需要使用上行保活的方式工作，如电气参数上报（心跳）周期可调节到90秒；对于远程控制优先类，电气参数上报（心跳）周期可调节为30分钟；对于本地控制优先类，电气参数上报（心跳）周期可调节为1小时一次。

正常状态的业务流程如下：

（1）应用服务器根据事先的分组，分组分批下发开/关/调光/查询指令，对于执行类指令，如开/关/调光。

（2）终端接收到指令后进行指令执行，路灯随之开/关/调光。

（3）指令执行完毕后上报路灯状态到应用服务器，刷新当前路灯状态。

异常状态的业务流程如下：

（1）如果路灯状态为离线，直接报异常；

（2）如果下行指令未收到终端响应或下行失败，则需要进行重发，重发三次失败后不再重发，应用侧不修改路灯状态，但提示异常；

（3）应用需要保证指令的时序性，该设备有前序指令未处理，判断指令与前序指令是否一样；如一样则丢弃，如不一样，则看缓存的指令里指令顺序，只执行最后一条指令即可；

（4）平台、EPC、UE需要对重复的命令进行过滤，避免不必要的重复的指令执行。

具体业务流程图如下：

2 关键业务模型设计

2.1 上电接入模型

若路灯上电时间不离散，当大量路灯同时接入网络时，会对网络造成一定冲击。建议采取随机数*离散间隔的方式，来区分不同路灯终端的接入时间，具体模型建议如下：

接入离散时间Ts：按照终端序号Mod（x），余数*Ymin

Mod（x）：终端上参数x设计为可配变量，NB下行12个子载波，考虑一定余量，建议为x=10

Ymin：终端上参数Y设计为可配变量，按照路灯行业感知要求，统一上电后30minAPP可监测上线，建议按照Mod10分组后，Y设置为3min。

2.2 心跳间隔模型

路灯心跳的主要目的是保活应用层连接，属于非必须功能，尤其考虑通信按连接收取资费，客户可能会减少甚至取消心跳；因此路灯心跳时间Tm参数设计为可配变量，当前IoT平台设定的应用层老化时间一般为30min，建议设置为25min。如果心跳过于频繁，会对网络资源、用户资费造成浪费。

2.3 上行控制模型

路灯数据的上报分为两大类：主动上报，触发型上报。其中主动型包括定时路灯状态上报，心跳上报用以链路保活；触发型上报为事件触发弄的，如主动查询，远程控制等。

路灯的上报频次会影响网络容量及下行控制时延，为减少对网络容量的影响，建议路灯一个小时上报一次，如果状态上报可以满足链路保活，则不需要心跳。由于不同的路灯管理处、路灯厂商、地方协会对上报周期的要求不一样，对于路灯上行数据以及周期性上报数据，可随心跳数据一同上报。

由于不同客户的数据收费方式不同，上行数据的上报模型可有所差异。对于一般场景，可参考以下模型：

2.4 下行控制模型

由于NB的窄带特性，必须通过控制瞬时下行数据量，才能保证下行控制的及时性和有效性。下行控制的离散原则如下：

（1）并发量控制在每秒不超过1个；

（2）从服务器下发命令开始，以s为单位进行分组离散控制

（3）路灯下行数据主要包括远程控制、配置更新、主动查询、软件升级。具体如下：

2.5 数据通信模型

原则：同一次通信多条数据合并一个报文上报，建议不超过200 Byte；非实时性数据按每周通信一次，例如时钟对时报文；一定程度实时要求的数据按每天通信一次，例如路灯异常上报。

2.6 重传业务模型

平台和终端需要保证单设备指令的时序性，即当先下发开灯，再下发关灯时，路灯收到的指令也应先为开，后为关。需要保证一组路灯的状态，即一组路灯同时开时，不能有的路灯收到开的指令，有的路灯收到关的指令。

2.7 并发接入业务模型

根据前期经验，终端入网、上报的离散化方式有如下几种：

（1）按ID

一般路灯出厂时都有单灯标识，每个路灯有自己的ID，路灯可以根据自身的ID，以ID为序号进行顺序入网和状态上报，如公式为：上电时间+ID*错峰时间（建议1秒）

（2）随机

每个路灯获取随机值，当随机值计算的时间到时，进行入网或状态上报，例如公式：上电时间+随机值（不大于3秒）

2.8 终端异常等通信保护设计

异常场景包括：

（1）路灯终端异常的告警上报：路灯不亮或闪烁、路灯控制电路接线错误等；

（2）路灯通信异常的反复重连：主要指路灯和基站、核心网、平台、服务器等通信异常场景；

建议方案：对于异常场景需要增加上报或重连次数限制，告警上报建议一天上报一次，通信异常建议重试3次后停等5min再重试。

3 典型参数配置建议

3.1 终端侧配置

3.2 无线侧配置

经过智能路灯现场调测经验，无线侧的参数配置建议如下表所示。主要包括三大类：第一类保证3GPP协议兼容开关根据对应终端关系匹配打开，保证智能路灯可正常接入；第二类backoff开关，使得路灯接入随机化，避免空口资源拥塞；第三类主要为定时器类优化参数，保证接入性能最优。

3.3 核心网配置

智能路灯不涉及PSM和eDRX，对寻呼要求较高，建议开启精准寻呼方式。另外，由于智能路灯存在大规模并发业务，会对NB-IoT网络侧产生信令和数传冲击，故需根据客户方案具体采用不同的接入和传输控制。具体说明如下：

3.4 应用服务器配置

4 业务端到端典型问题

N B的组网架构涉及终端、无线、核心网、专网、平台及应用服务器等，而大量终端仍然沿用2G终端的业务模型， NB-IoT终端侧的问题较为突出。

4.1 【芯片】终端接入底噪抬升显著分析

4.1.1 问题：在测试底噪问题时发现终端以满功率发射是造成底噪抬升的重要因素，需对此问题进行详细分析。

4.1.2 分析：从芯片日志可以看到，芯片在覆盖等级0接入时，最低发送功率-7db大于协议规定的-40dbm,对邻区干扰也有影响。

（1）终端初始接入时未选择最好信号小区接入，从信号较差小区接入导致终端接入覆盖等级1/2，终端满功率发射导致底噪抬升。(当前终端选择覆盖等级时，除了考虑R S R P还考虑S I N R，-3

从现网复测log可以看到，终端初始接入pci 7，从覆盖等级1接入，对应SINR平均4.8左右。相同地点终端重新测试时发现终端接入pci 222小区，覆盖等级0接入，对应SINR14.3左右。

（2）终端从覆盖等级0接入失败，尝试从覆盖等级1/2接入。

协议规定当终端从覆盖等级0接入时，如果连续尝试次数达到最大尝试次数时就会尝试从更高一级覆盖等级接入。测试数据分析，终端初始从覆盖等级0接入（LL1_RACH_SELECTED_BY_MEASUREMENT），失败后尝试从覆盖等级1/2接入（LL1_RACH_ECL_SELECTED_NEXT_COVERAGE_LEVEL）

邻区干扰会导致SINR值的降低，而芯片协议规定只要SINR值小于7，依据RSRP值，覆盖等级只能为1、2 ，而在覆盖等级1、2下，UE会满功率进行发射。从灯杆信号的摸查以及提取的终端日志来看，能检测到多个PCI，且rsrp强度在-60～70的情况下，SNR值波动较大，最低可以达到负十几。

4.1.3 解决方案：由于3gpp协议缺陷，需要推动3gpp协议完善。

4.2 【终端】控制时延高分析

4.2.1 问题：通过路灯APP对单灯进行控制时，发现控制时延较大，平均在20s以上。

4.2.2 分析：UE侧打开了eDRX，所以UE会在hfn:970，sfn:256到hfn:971，sfn:256这段时间内接收paging，但是在基站侧却在hfn:971，sfn:449这个点上给UE发射paging。核查参数发现核心网侧打开了eDRX，基站侧未打开eDRX，配置不一致，导致Paging帧不对齐丢失。