NB-IoT技术原理与应用开发 -课件汇 崔雁松 项目1.1.1 AT指令的功能和分类-5.1.6 使用示例

项目1必备知识

NB-IoT常用AT指令NB-IoT常用AT指令1.1.1AT指令的功能和分类1.1.2AT指令集1.1.3NB-IoT模组接入云平台用AT指令1.1.1AT指令的功能和分类Attention命令：控制移动终端的联网响应：移动终端的状况、联网情况TEMT1.1.1AT指令的功能和分类测试：Test查询：Read执行：Execution设置：Write谢谢观看！项目1必备知识

NB-IoT常用AT指令NB-IoT常用AT指令1.1.1AT指令的功能和分类1.1.2AT指令集1.1.3NB-IoT模组接入云平台用AT指令1.1.2AT指令集《Quectel_BC35-G&BC28&BC95R2.0_AT_Commands_Manual_》1.1.2AT指令集1.1.2AT指令集谢谢观看！项目1必备知识

NB-IoT常用AT指令NB-IoT常用AT指令1.1.1AT指令的功能和分类1.1.2AT指令集1.1.3NB-IoT模组接入云平台用AT指令1.1.3NB-IoT模组接入云平台用AT指令1.1.3NB-IoT模组接入云平台用AT指令编号指令功能参数测试指令查询指令执行指令设置指令1AT2AT+NRB3AT+CMEE4AT+CGDCONT5AT+CGSN6AT+NCDP7AT+CFUN8AT+CGATT9AT+NUESTATS10AT+CGPADDR11AT+CSCON12AT+CIMI13AT+CGMR14AT+CCLK1.1.3NB-IoT模组接入云平台用AT指令谢谢观看！项目2必备知识

NB-IoT模组入网设计NB-IoT模组入网设计2.1.1设计思路2.1.2工具软件2.1.3开发步骤2.1.1设计思路使用NB-IoT主板控制模组联网，即发送AT指令控制BC35G执行联网操作，有以下两种方式：方式1：通过将JP3跳线区的串口模式设置为模式3（UART3），通过电脑串口调试工具输入AT命令直接对BC35G进行控制（发送AT指令需要遵循一定的顺序）；2.1.1设计思路方式2：通过将串口模式设置为模式2，将MCU串口2（UART2）和BC35G模组相连，通过程序发送AT指令，并通过将串口模式设置为模式1，将MCU获取到的BC35G数据通过串口3（UART3）打印到电脑串口调试工具中。MCU给BC35G发送的AT指令可以是通过按键触发程序中预设的AT指令，也可以是通过电脑串口调试工具逐条发送给MCU的AT指令。2.1.1设计思路谢谢观看！项目2必备知识

NB-IoT模组入网设计NB-IoT模组入网设计2.1.1设计思路2.1.2工具软件2.1.3开发步骤2.1.2工具软件（1）STM32CubeMxST公司发布的一款STM32微控制器芯片配置工具，几乎覆盖了STM32全系列芯片。它通过亲和的图形界面逐步配置并生成初始化C代码，可以大大减轻开发工作、缩减时间、降低费用。可以根据不同的集成开发环境（IDE）工具生成对应的初始化配置工程。2.1.2工具软件（2）KeilMDK5

KeilMDK（基本架构组成如图2-3所示）是Keil公司开发的一个集成开发环境（IDE），可以完美运行于多种操作系统，目前最新的版本是uVision5。它提供工程管理、源代码编辑、编译uVision设置、下载调试和模拟仿真等功能。2.1.2工具软件（2）KeilMDK52.1.2工具软件（3）STM32ST-LinkUtilitySTM32ST-LinkUtility是一个和ST-Link烧录器配套使用的工具软件。它的功能和J-Link烧录器对应的工具软件相类似，主要用于向STM32芯片中烧写代码。该软件本身包含有ST-Link驱动。利用STM32ST-LINKUtility软件可以快速读取FLASH数据（前提是没有添加保护），还可以快速读取STM32芯片型号、ID、版本等信息。

当开发完成的STM32产品需要量产时，可以很方便地利用这个软件直接下载hex代码，并可以对代码进行加密保护。谢谢观看！项目2必备知识

NB-IoT模组入网设计NB-IoT模组入网设计2.1.1设计思路2.1.2工具软件2.1.3开发步骤2.1.3开发步骤本实验的软件开发步骤如下：步骤1：使用STM32CubeMx软件基于STM32L431VCT6芯片进行图形化配置，包括RCC时钟配置、程序下载配置、串口3配置、串口2配置、按键GPIO配置，其中按键使用中断方式。注：若所有配置均采用默认值，则此步骤可省略。步骤2：将生成的代码使用KeilMDK5打开，并在里面进行代码的添加修改，按照软件设计流程图进行程序设计。步骤3：将程序代码通过ST-Link烧录到主板上。步骤4：在电脑串口调试工具上观察程序运行情况并查看BC35G执行AT指令后的返回状态。谢谢观看！项目3必备知识

NB-IoT终端和平台对接NB-IoT终端和平台对接3.1.1NB-IoT终端和云平台组网3.1.2Profile文件和编解码插件3.1.3主要业务流程3.1.1NB-IoT终端和云平台组网

目前要访问AppServer（应用服务器）都采用JSON（JavaScript

ObjectNotation，Javascript对象简谱）语言格式，但考虑到数据量问题，这种语言并不适合于物联网空口的传输。同时，由于NB-IoT设备一般对耗电要求较高，所以设备的应用层数据一般不采用流行的JSON格式，而是采用二进制格式。为此，NB-IoT设备和IoT平台之间应用层的下一层（传输层）采用CoAP协议进行通信，以承载应用层的二进制数据。到了IoT平台，再调用编解码插件来完成CoAP协议数据到JSON格式数据的转换，以适配地传送给应用服务器。IoT设备应用层数据的格式由设备自行定义；在设备侧，CoAP协议栈一般由NB-IoT芯片模组来实现。谢谢观看！项目3必备知识

NB-IoT终端和平台对接NB-IoT终端和平台对接3.1.1NB-IoT终端和云平台组网3.1.2Profile文件和编解码插件3.1.3主要业务流程3.1.2Profile文件和编解码插件1、Profile文件

每款设备都需要一个Profile文件，设备的Profile文件为JSON格式。3.1.2Profile文件和编解码插件一个Profile文件主要包括两部分：1）设备能力（DeviceCapability）设备能力用来描述一款设备的能力特征，即设备的基础属性信息，包括：manufacturerId（厂商ID）、manufacturerName（厂商名字）、deviceType（设备类型）、model（设备型号）、protocolType（协议类型）等。2）设备服务（Service）

设备具有的某项服务（也可以理解为物理设备的功能模块或者虚拟设备提供的服务，如一个系统提供的天气预报服务），即设备的业务数据（包括设备上报的上行数据和厂商服务器下发给设备的下行数据），包括命令和属性两部分。3.1.2Profile文件和编解码插件2、编解码插件（1）解码过程

编解码插件的解码过程属于数据上报过程中的一步。3.1.2Profile文件和编解码插件2、编解码插件（2）编码过程

编解码插件的编码过程属于命令下发过程中的一步。3.1.2Profile文件和编解码插件3、编解码插件和Profile实现不同厂商设备接入3.1.2Profile文件和编解码插件4、透传模式和非透传模式根据客户的不同需求，IoT平台提供透传和非透传两种传输模式。所谓透传模式，是指IoT平台不负责解码终端数据，直接透传给第三方应用平台。在一些政府机关、保密单位等部门，要求平台不能保存终端的数据，因此必须使用透传模式。在透传模式下，不需上传编解码插件，即找不到编解码插件就认为是透传模式，但需要在Profile中定义透传能力。所谓非透传模式，就是IoT平台需要调用编解码插件对终端数据进行转换。当前主要推荐使用非透传模式，前面所述内容也都讲的是这种模式。谢谢观看！项目3必备知识

NB-IoT终端和平台对接NB-IoT终端和平台对接3.1.1NB-IoT终端和云平台组网3.1.2Profile文件和编解码插件3.1.3主要业务流程3.1.3主要业务流程1、设备注册流程3.1.3主要业务流程2、订阅资源流程3.1.3主要业务流程3、数据上报流程3.1.3主要业务流程4、命令下发流程立即下发场景3.1.3主要业务流程4、命令下发流程缓存下发场景谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.1开机流程开机流程的过滤关键字为：EMMSM_INIT||RRC_INIT||PDH_INIT||SIM_INIT||MN_INIT||USIM_READ开机流程的关键信息有：EMMSM_INIT_REQ是MN下发NAS开机请求；EMMSM_INIT_CNF是NAS回复MN开机确认消息；PDH_INIT_REQ是MN下发给PDH开机请求；RRC_INIT_REQ是NAS下发给RRC开机请求；RRC_INIT_CNF是RRC回复NAS开机确认消息；SIM_INIT_REQ是MN下发SIM开机请求；SIM_INIT_CNF是SIM回复MN开机读卡确认消息；USIM_READ_PART_1_DATA_CNF可以查看SIM卡读取内容，在工具右侧“Detail”选项卡；MN_INIT_IND是MN回复AT开机成功，这里说明NAS层开机完成，表示可以开始搜索网络。谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.2搜网流程搜网流程指小区搜索/小区选择/PLMN选择的过程。如果通过AT命令锁频，则只搜索配置的频点。频点搜索时，首先搜到主同步信号NPSS，有效的辅同步信号NSSS中会携带小区ID。获取的SIB1中有PLMN，和NAS下发的PLMN作比较，如果不匹配就搜索下一个频点。频点搜索，按顺序是：存储（存储器里存储的上次成功驻留的频点，仅有一个）、先验（内存里的历史存储频点，有5个，下电丢失），然后是所有频点。4.1.2搜网流程搜网主流程的过滤关键字为：RRC_CELL_SELECT||LL1_FREQ_SEARCH||ASN||RRC_DBG_CELL_SUITABILITY搜网主流程的关键信息有：RRC_CELL_SELECT_REQ是NAS下发的RRC选网请求；LL1_FREQ_SEARCH_REQ是RRC下发的LL1搜网请求；LL1_FREQ_SEARCH_CNF是上报给RRC的搜索结果；RRC_DBG_CELL_SUITABILITY是RRC层判断是否适合驻留；RRC_CELL_SELECT_CNF是RRC上报NAS选网结果；RRC_DBG_ASN是RRC读取的MIB/SIB消息。谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.3附着流程小区附着流程的过滤关键字为：RRC_EST||NAS_DBG_NAS_MSG||SUITABILITY。关于小区附着流程的说明如下：NAS_DBG_NAS_MSG是EMM发起核心网附着请求，能够看到RRC_DBG_CELL_SUITABILITY，说明UE是在搜到合适小区后，由EMM发起了附着。附着第一步是先和基站建立起RRC连接。附着的关键信息是鉴权和安全模式过程，包括AUTH和SECURITY对应的消息。ATTACH_COMPLETE说明核心网附着完成。附着后的EMM_INFO是核心网下发部分信息，例如世界时钟。此时，UE已经建立了缺省的PDP承载，也就可以开始做数据传输业务了。谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.4随机接入流程随机接入流程的过滤关键字为：NAS_MSG||ASN||RRC_EST_REQ||RRC_EST_CNF||LL1_RACH_REQ||DCI_FORMAT||RAR||MSG3||LL1_RACH_CONTENTION_RESOLUTION_IND||LL1_RACH_CNF随机接入流程的关键信息有：LL1_RACH_REQ中的“initiator”信息表示发起随机接入的是初始接入还是MAC重同步；LL1_RACH_CNF中的“cause”表示接入结果，通常随机接入的结果有以下几种：LL1_RACH_SUCCESS（随机接入成功）；LL1_RACH_INTERRUPTED_BY_MAC_CANCEL（接入被MAC层打断，一般情况是重同步接入获取到上行调度后不需要继续重同步操作，属于正常结果）；LL1_RACH_CONTENTION_RESOLUTION_MISMATCH（竞争解决不匹配）；LL1_RACH_ERROR（接入错误）；LL1_RACH_CANCEL（接入被取消）；LL1_RACH_INTERRUPTED_BY_RRC_RELEASE（接入被RRC释放打断）；LL1_RACH_INTERRUPTED_BY_MAC_RESET（接入被MAC层复位打断）；LL1_RACH_ERROR_MAX_NUM_PREAMBLE_ATTEMPTS（Preamble达到最大尝试次数，接入失败）。谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.5上下行数据传输流程上行数据传输流程（连接态）：4.1.5上下行数据传输流程上行数据传输流程（空闲态）：4.1.5上下行数据传输流程下行数据传输流程（连接态）：4.1.5上下行数据传输流程下行数据传输流程（空闲态）：4.1.5上下行数据传输流程上行数据传输的过滤关键字为：APPLI_||PDH_DATA||MAC_UL_UPDAT||NPRACH||RACH_RESET||DCI_FORMAT||UL_DATA||UL_GRANT||ESM_DATA||RRC_DATA||RACH_MSG3||LL1_DATA||RLC_UL_STATUS_IND下行数据传输的过滤关键字为：APPLI_||PDH_DATA||MAC_UL_UPDAT||NPRACH||RACH_RESET||DCI_FORMAT||UL_DATA||UL_GRANT||ESM_DATA||RRC_DATA||RACH_MSG3||LL1_DATA||RLC_UL_STATUS_IND||RLC_UL_SR|RLC_DL_DATA_IND谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.6小区重选流程小区重选过滤的关键字有：LL1_IDLE_MEAS_START_REQ||RRC_DBG_READING_SIBS_FOR_NCELL||RRC_DBG_RESELECTION_CANDIDATES||RRC_DBG_RESELECTION_MEASUREMENTS小区重选的关键信息有（如图4-22所示）：LL1_IDLE_MEAS_START_REQ：启动测量；RRC_DBG_READING_SIBS_FOR_NCELL：测量上报；RRC_DBG_RESELECTION_CANDIDATES：测量的小区信息；RRC_DBG_RESELECTION_MEASUREMENTS：主服务小区信号信息。谢谢观看！项目4必备知识

NB-IoT终端日志分析NB-IoT终端日志分析4.1.1开机流程4.1.2搜网流程4.1.3附着流程4.1.4随机接入流程4.1.5上下行数据传输流程4.1.6小区重选流程4.1.7寻呼注意事项及服务小区信号查看4.1.7寻呼注意事项及服务小区信号查看查看寻呼Paging问题的典型注意事项有：过滤RRC_DBG_LONG_EDRX_INFO，确认是否能使能eDRX特性4.1.7寻呼注意事项及服务小区信号查看需要确保UE成功接入后回到IDLE态，并且UE不能进入PSM状态。测试时可以看到UE收到“release”。4.1.7寻呼注意事项及服务小区信号查看在使能eDRX特性时，由于eDRX周期较长以及时钟同步问题，核心网可能很久之后才下发Paging消息，并且eNB有的可能丢掉核心网下发的Paging消息，因此Paging没有成功时请先确认eNB是否下发Paging。可以过滤PROTO_LL1_SERVING_CELL_MEASUREMENT_IND，看到服务小区的相关信号信息，其中“valid”指示打印值是否有效。4.1.7寻呼注意事项及服务小区信号查看更细致的信号测量值，可以通过LL1_NRS_MEASURE过滤查看。谢谢观看！项目5必备知识

CoAP协议分析CoAP协议分析5.1.1报文结构5.1.2逻辑分层模型5.1.3代理5.1.4块传输5.1.5加密算法5.1.6使用示例5.1.1报文结构1.基本报文结构第一行为报文头（header），其余是报文体（body）：第二、第三行是可选项，其余行是负载（Payload）。5.1.1报文结构2.Code字段

占1个字节，分为两个部分：前3个二进制位和后5个二进制位。为了便于阅读，可以将Code描述为“c.dd”的形式。“c”的可取值有4个，用来标识本CoAP报文是“CoAP请求”还是某种类型的“CoAP响应”。c代表含义0CoAP请求2CoAP响应，对应请求已被正确执行4CoAP响应，对应请求的客户端有问题5CoAP响应，对应请求的服务器有问题5.1.1报文结构2.Code字段c=0c=25.1.1报文结构2.Code字段c=45.1.1报文结构2.Code字段c=55.1.1报文结构3.Option字段Option的属性有如下两类：CriticalOption：重要的Option，接收方必须能够理解的Option，否则报文无法正常处理；ElectiveOption：可选的Option，接收方不能识别时可以忽略，不影响报文的正常处理。谢谢观看！项目5必备知识

CoAP协议分析CoAP协议分析5.1.1报文结构5.1.2逻辑分层模型5.1.3代理5.1.4块传输5.1.5加密算法5.1.6使用示例5.1.2逻辑分层模型CoAP协议在逻辑上分为两层：资源请求/响应层（Request/Response）和消息层（Message）。消息层只负责控制端到端的报文交互；资源请求/响应层负责传输资源操作的请求和响应。CoAP协议模型是基于UDP的类似于HTTP的客户端/服务器交互模型。客户端通过不同的请求方法向服务器发送请求对资源（通过URI表示）进行操作，服务器返回响应（携带着对资源的描述）和状态码。5.1.2逻辑分层模型CoAP协议的资源请求/响应层的消息包括3种：请求（Request）、响应（Response）和空消息（EmptyMessage）。CoAP协议的消息层的消息有如下4种类型，由报文中的“T”字段确定：CON消息（ConfirmableMessage）：需要确认的消息，接收方必须对消息回复Acknowledgement或Reset；NON消息（Non-ConfirmableMessage）：不需要确认的消息，但是接收方可能回复Reset；ACK消息（ACKMessage）：用于向发送方确认CON消息已收到，可以携带附带响应（PiggybackedResponse）；RST消息（ResetMessage）：用于回复收到的无法处理的消息（CON消息或NON消息）；也可以通过一个空的CON消息触发一个RST消息，用于端点的保活检测。5.1.2逻辑分层模型消息层4种消息类型与其承载的资源请求/响应层3种消息类型之间的映射关系：5.1.2逻辑分层模型消息层承载资源请求/响应层的消息有以下两种模式：（1）可靠模式（ReliabilityMode）对可靠传输请求的响应方式有如下两种：同步可靠响应模式（PiggybackedResponse）异步可靠响应模式（SeparateResponse）5.1.2逻辑分层模型消息层承载资源请求/响应层的消息有以下两种模式：（2）非可靠模式（Non-ReliabilityMode）非可靠传输模式下采用非可靠响应模式，请求和响应也通过Token配对。对于通过NON承载的请求，服务器可以选择通过NON消息返回响应。谢谢观看！项目5必备知识

CoAP协议分析CoAP协