《NB-IoT 端到端优化分析》
《NB-IoT 端到端优化分析》
1.端到端系统架构
NB-IoT的端到端系统架构如下图所示：
- NB-IoT终端：通过空口连接到基站。
- eNodeB：主要承担空口接入处理，小区管理等相关功能，并通过S1接口与IoT核心网进行连接，将非接入层数据转发给高层网元处理。
- IoT核心网：承担与终端非接入层交互的功能，并将IoT业务相关数据转发到IoT平台进行处理。
- IoT平台：汇聚从各种接入网得到的IoT数据，并根据不同类型转发至相应的业务应用进行处理。
- 应用服务器：是IoT数据的最终汇聚点，根据客户的需求进行数据处理等操作。
2.端到端分析方法简介
NB-IOT网络端到端产业链条长，涉及产品多，整个业务过程与模组终端、无线网络、核心网、IOT平台、应用服务器等多网元相关，且物联网终端数量多，普遍上报周期长，问题发生后，不会像传统的网络一样有手机用户反馈。基于传统的问题分析方法和优化模式很难快速定位NB-IOT的网络问题。
为了快速定位及优化网络问题，基于经验总结出了“三层五元四阶法”，搜集各网元日志，对各网元日志进行关联分析，输出终端在各网元的业务轨迹信息，快速找出故障网元，实现NB-IOT端到端优化。
五元：NB-IOT端到端的业务的流程主要涉及5个网元，分别是各类NB-IOT终端、无线eNodeB、NB-IOT核心网、NB-IOT平台、NB-IOT应用服务器；
四阶：从业务的流程上分为四个阶段，分别是终端和eNodeB无线通信阶段、终端和核心网的NAS阶段、终端和IOT平台之间的数据传输阶段、IOT平台和应用服务器的数据传输阶段；
三层：通过用户->会话->消息逐层分析的方法，首先定位到用户级别的问题，然后利用故障时间节点确定CallID定位到会话级问题，最后根据具体的信元定位到消息，解析消息解决问题。
建网初期的问题分析步骤：
步骤一：当某些用户的业务发生异常时，从应用服务器导出异常用户的IMEI、IMSI或者终端号码等信息；
步骤二：在IOT平台和应用服务器之间进行抓包，根据包序号确认在IOT平台和应用服务器之间异常用户是否有发生过丢包的现象；
步骤三：在核心网和IOT平台之间进行抓包，根据包序号确认在IOT平台和核心网之间异常用户是否有发生过丢包的现象；
步骤四：根据应用服务器提供的异常终端的IMSI，在核心网侧获取该异常用户的单用户跟踪；
步骤五：在核心网侧查询异常终端IMSI对应的TMSI信息，或者获得异常用户对应的MME-UE-S1APID和eNB-UE-S1APID信息后，在eNodeB侧找到异常用户的CallID，根据CallID获取异常用户的跟踪消息；
步骤六：核对核心网侧的跟踪和eNodeB侧的跟踪后，进行eNodeB和核心网之间的消息拼接及比对，隔离问题是发生在eNodeB侧还是核心网侧；
步骤七：比对eNodeB侧的UU口信令和S1口信令，隔离问题发生在空口还是S1口；
步骤八：比对eNodeB侧的UU口信令和终端侧的信令，隔离问题发生在eNodeB还是终端。
网络成熟期的问题定位步骤：
随着网络的发展，IOT平台对应的维测功能会逐步完善，在分析IOT平台的上下游的问题时，可以通过IOT平台的维测手段进行问题定位。
在问题定位之初，为了确保时间信息前后一致，需要在核对终端、基站、核心网、IOT平台和应用服务器的时间，确认设备之间的时间差。
步骤一：当某些用户的业务发生异常时，从应用服务器导出异常用户的IMEI、IMSI或者终端号码等信息；
步骤二：根据用户的IMEI信息在IOT平台上获取对应用户的所有消息，从应用服务器获取问题发生的时间点，核对对应时间点的前后IOT平台和应用服务器之间数据发送否异常；
步骤三：根据用户的IMEI信息从IOT平台上获取对应用户的所有消息，根据用户的IMSI从核心网侧获取到单用户跟踪，在对应的时间点进行关联分析，核对IOT平台和核心网之间是否异常；
步骤四：在核心网查询异常终端IMSI对应的TMSI信息，或者获得异常用户对应的MME-UE-S1APID和eNB-UE-S1APID信息后，在eNodeB侧找到异常用户的CallID，根据CallID获取异常用户的跟踪消息；
步骤五：核对核心网侧的跟踪和eNodeB侧的跟踪后，进行eNodeB和核心网之间的消息拼接及比对，隔离问题是发生在eNodeB侧还是核心网侧；
步骤六：比对eNodeB侧的UU口信令和终端的信令跟踪，隔离问题发生在终端侧还是eNodeB侧；
步骤七：比对eNodeB侧的UU口信令和终端侧的信令，隔离问题发生在eNodeB还是终端。
3.端到端问题排查
端到端的分析方法从异常终端的数量，区分为网络级故障问题定位（针对多终端大面积故障）和终端级故障问题定位（针对少数终端故障或某类典型问题终端）。
网络级故障问题主要通过端到端网元的异常排查并结合各网元的问题现象来综合隔离定界定位。
终端级故障问题主要通过将终端在端到端网元的维测信息串联起来比对分析来隔离定界定位。
网络级故障问题隔离定界：
网络级问题隔离定界首先并行地对各个网元进行基本动作的排查，主要包含告警排查、设备运行状态排查、配置排查和话统排查。若基本动作排查完毕，问题仍然无法解决，则进行关联排查。
- 应用服务器
1、现象确认
NB业务因涉及的垂直行业众多，不同的垂直行业的指标感知需要从不同业务应用的角度，确认问题现象：XX应用业务从XX时间到XX时间指标恶化，恶化的幅度是多少？
2、对应UseCase信息获取及现象细化；
打开各个应用的业务平台，通过对应的管理模块，获取终端的信息：问题终端列表（DeviceID、IMEI、IMSI）、问题终端位置信息等，以判断问题的范围和发生的时间点。确认问题发生的范围是否集中；问题发生的时间点是否集中；
以灯杆为例说明：从灯杆的服务器可以看到的业务信息如下：
Check检查项 | Check结果举例 |
|---|---|
业务类型 | 智能灯杆 |
业务成功率 | 98% |
业务故障时长 | 2018/02/03 10:00 ~至今 |
问题终端列表（DeviceID、IMEI、IMSI） | 从应用平台导出列表 |
问题终端位置信息 | 从应用平台导出列表 |
- IoT平台
IOT 平台的相关操作方法，当前全网采用的IOT平台不统一，手册仅以华为的IOT平台为例进行介绍。
1、告警排查
告警排查达标标准：对应的业务模块没有影响业务的重要活动告警。
当产品的业务处理模块或软件模块检测到本模块故障时会产生并上报告警。及时发现并处理告警，对系统稳定运行有重要作用，重点关注严重级别或者影响业务运行的告警。
2、查看节点和进程状态
当产品的磁盘空间、CPU、内存、进程状态异常时会产生异常告警。及时查看进程状态并处理，对系统稳定运行有重要作用。
达标标准：
1）磁盘空间、内存、CPU占用率低于阈值。
2）所有进程状态都显示正常。
- 核心网
1、告警排查
告警排查达标标准：对应的业务模块没有影响业务的重要活动告警。
以华为核心网为例，核心网关键告警信息如下，若存在如下关键告警，建议联系核心网人员快速处理。
MME关键告警 | UGW关键告警 |
|---|---|
继承LTE告警：M3UA链路故障M3UA路由不可用M3UA目的实体不可达系统业务资源过载单个DNS服务器无响应所有DNS服务器无响应GTPC路径故障Diameter链路故障Diameter路由不可用Diameter对等端不可达GTPC路径故障GTPU路径故障S1ap链路故障新增告警：H-SFN参考时间晚于当前系统时间/相同TAI下eNodeB上报的RAT-Type不一致原有告警新增上报资源项:话务量超过峰值/业务即将因License容量而受限/资源达到LICENSE扩容门限/资源达到License限制值 | 继承LTE告警：磁盘分区满告警资源单元虚拟磁盘空间超阈值告警本地地址池占用率超过指定门限RADIUS鉴权服务器无响应DHCP服务器无响应信令路径断路径资源不足CG无响应话单缓存话单池空间不足RADIUS计费服务器无响应OCS无响应PCRF无响应原有告警新增上报资源项:话务量超过峰值/业务即将因License容量而受限/资源达到LICENSE扩容门限/资源达到License限制值 |
2、设备运行状态排查
执行MML命令查询相应的设备运行状态，以确保设备的运行都是正常的，需要查询的
设备状态包括license状态、单板的状态、CPU状态、核心网传输的状态等。
3、操作排查：
对比故障时间点前后，基站是否有相关操作，升级或者修改MML命令等，根据各厂家的操作参考手册，确认操作的影响，以确认是否对相关指标造成影响；
4、话统排查
NB-IoT EPC侧提供的话统指标分类与LTE类似，用于支撑网络KPI计算、网络负载评估、业务情况评估等。对比故障时刻前后的话统是否有突变，将关键话统和初步分析结果反馈给核心网人员进行分析。
以华为核心网为例，需要重关注的话统如下：
MME KPI指标 | UGW KPI指标 |
|---|---|
NB-S1模式忙时每用户附着请求次数NB-S1模式附着成功率NB-S1模式忙时每用户MME内TAU次数NB-S1模式忙时每用户MME间TAU次数NB-S1模式MME内的TAU成功率NB-S1模式MME间的TAU成功率NB-S1模式分组寻呼成功率NB-S1模式忙时每用户分组寻呼次数NB-S1模式CPSR成功率NB-S1模式忙时每用户SR次数NB-S1模式算法协商成功率NB-S1模式忙时每用户鉴权次数 | SGW创建承载成功率PGW创建承载成功率SGW当前在线的用户数PGW当前在线的用户数忙时每用户附着次数忙时每用户平均S1 Release次数忙时每用户平均发送寻呼/Service Request次数忙时平均包长忙时每激活的Bearer平均吞突量SGi接收用户面报文峰值速率SGi发送用户面报文峰值速率 |
- 基站
1、告警排查
告警排查达标标准：基站当前没有影响业务的重要活动告警。
登录网管，选择需求排查的站点，获取站点的告警信息，以华为的基站为例，对于NB-IoT业务建议重点排查和清除以下告警。
模块 | 类别 | 告警/故障内容 | 告警/故障影响 |
|---|---|---|---|
传输类 | 告警 | S1接口故障告警 | 对于“S1接口闭塞”原因引起的故障，该S1接口不允许接入新的用户；但对已经接入的用户的消息、非用户相关的消息无影响。对于其他原因，基站将释放已经接入该异常S1接口上的所有用户。 |
告警 | 基站S1控制面传输中断告警 | 基站所有承载S1Interface的SCTP链路（链路个数不少于2条）状态都异常，导致基站所有S1接口无法建立成功，小区无法建立，用户无法入网。 | |
小区类 | 告警 | 小区不可用告警 | 告警小区不能提供业务 |
告警 | 小区重配置失败告警 | 本次修改小区PDSCH功率配置失败，小区覆盖不符合配置预期。 | |
告警 | 小区服务能力下降告警 | 告警小区提供给客户可用的无线空口能力会下降。 | |
告警 | 小区闭塞告警 | 告警小区不能提供业务。 | |
告警 | 小区模拟负载启动告警 | 本小区对邻区的下行干扰增大。 | |
单板类 | 告警 | 单板过载告警 | 可能导致用户接入成功率和业务质量下降。 |
告警 | 单板硬件故障告警 | 单板无法正常工作，单板承载的业务可能中断。 | |
License | 告警 | 系统超出License容量限制告警 | 超出License容量限制部分的业务无法接入。 |
射频通道类 | 告警 | 射频单元业务不可用告警 | 告警小区的RRU不能提供业务。 |
2、设备运行状态排查
执行MML命令查询相应的设备运行状态，以确保设备的运行都是正常的，需要查询的
设备状态包括license状态、单板的状态、小区的状态、RRU的状态、RRU射频通道的状态、基站传输的状态等。
3、操作排查
对比故障时间点前后，基站是否有相关操作，比如升级或者修改MML命令等，根据各厂家的操作参考手册，确认操作的影响，以确认操作是否对相关指标造成影响；
4、话统排查
对比故障时间点前后一周的KPI监控数据，识别关键话统指标是否在故障时刻前后有明显的波动，问题定位过程中需要关注的相关的重点指标如下表：
- 终端
业务模型获取：
NO | 问题 | 答案 | 类型 |
|---|---|---|---|
1 | 什么类型终端？芯片厂家是哪家？模组厂家是哪家？ | 必答 | |
2 | 什么功能受影响：无法接入？数据无法上报？ | 必答 | |
3 | 问题终端数量：个例？批量？ | 必答 | |
4 | 问题终端所处的环境？批量问题终端所处环境是否有相关性？同设备商基站？同基站？同小区？ | 必答 | |
5 | 问题终端问题时刻？是否在此时刻批量出现问题？ | 必答 | |
6 | 问题出现时刻，其他网元是否有重大操作？IOT平台操作？核心网操作？基站操作？（重大操作：升级、参数配置等） | 必答 |
终端级故障问题隔离定界：
终端级问题隔离定界，首先从服务器获取的异常终端的IMSI、IMEI和用户地址信息，然后通过IMSI和IMEI关系在各个网元找到对应的终端的维测信息，通过各网元的分析结果综合判断进行隔离定界，利用三层五元四阶法，逐层隔离问题，逐层定位，解决问题。
一、应用服务器
Usecase应用服务器查看异常数据，给出异常Device的IMSI和IMEI信息。
不同的应用服务器具体功能可以不一致，操作以实际的应用为准，这里以灯杆应用服务器举例如下：
应用服务器的观察目的是获取 “问题终端的列表” ，主要包含：1、用户编号 2、灯杆编码 3、灯杆地址码 4、灯杆地址 5、IMSI 6、IMEI。
二、IoT平台
1、典型问题
典型问题分为两类：
对于上报类业务，数据上报失败，具体表现为某天的数据没报上来；
对于控制类业务，控制命令下发失败，具体表现为相关指令下发失败，NB终端未按照命令执行；
2、上报类问题排查：
步骤一：登录IOT平台，根据用户的IMEI查看设备上的上报数据历史记录，
步骤二、如果有数据上报，则证明数据已经正常送到到IOT平台，需要IOT重点排查其是否将数据正确的发送到了应用服务器；
步骤三、如果没有数据上报，需要重点排查IOT平台以下的网元；
3、命令下发类问题排查：
步骤1：登陆IOT平台，查看设备历史命令记录，查看对应时间是否有针对问题终端的命令下发；
步骤2：如果没有命令下发，联系应用服务器人员检查应用服务器是否有下发命令；
步骤3：如果有命令下发，则需要重点排查IOT平台以下的网元；
三、核心网
对于单用户的异常情况，可以通过核心网的单用户跟踪进行问题的详细定位。通过应用服务器提供的异常用户的IMSI号，分析核心网该用户对应的单用户跟踪。踪分析是否有数据上报或者信令消息异常。
四、基站
针对异常用户，核心网可以根据异常用户的IMSI信息查询到TMSI，提供给基站；或者核心网根据IMSI信息在核心网具体信令中查询到MME-UE-S1APID和eNB-UE-S1APID提供给基站，基站进行可针对该用户进行具体的信令分析。
1、如果基站侧有虚用户跟踪，则根据虚用户跟踪查看用户的具体信令流程，判断问题具体出现在哪条信令。
2、如果没有虚用户跟踪，则可以分析基站侧的标口跟踪。华为的信令分析能够根据TMSI获取到用户的信息，同样也能够根据MME-UE-S1APID和eNB-UE-S1APID获取到用户信息。
五、终端
获取到终端日志后，根据核心网提供的TMSI信息，通过终端日志分析工具，可以分析终端侧的信令流程，联合eNodeB侧的信令，可以明确问题发生点。
例如找到该用户时，发现IMSI号为460XXXXXXXXXX72用户针对eNodeB的消息发送了多条的上行消息，均未收到基站的响应，经分析无线环境，该站点的干扰很高，可以确认因为上行高干扰，导致终端发送的上行消息基站未收到。
NB-IoT的终端与传统无线业务终端相比，种类繁多。传统无线业务终端类型单一，以手机和上网卡等居多。而面向物联网应用，大量面向不同垂直行业的智能终端，只要集成了NB-IoT模组，就成为了一款NB-IoT终端。各个终端的维测成熟度也不如传统的无线业务，因此建议各个终端厂家遵守行业规范，在商用之前完成实验室认证，获取认证证书，保障终端能够提供足够的维测功能。例如需要各个终端厂家后续可支持终端日志远程获取功能，可以达到问题发生后免复测的目的。