一、设备入网
设备是指设备连连上了基站、路由器（AP）或者网关，此时设备具备了向对应的基站 / 路由器 / 网关收发底层报文的能力。比如你的手机连上路由器（AP），此时你的手机可以正常上网收发信息。但此时的设备，还没注册到 IOT 系统。
所以设备入网 会被很多人忽略，因为它与IOT系统没啥关系、存在感很低。或者有些人直接把它当成设备注册的一部分，这句话也能说得通，毕竟设备入网后才能注册，不过严谨一点，设备入网是设备注册的前提，入网解决的是【设备通信】问题，而设备注册解决的是【设备能不能被 IoT 系统识别、管理】问题。设备入网并不是为了设备注册而存在，只不过 IOT 系统中，两者经常会被放在一起实现，而设备入网又不在系统界面中体现，所以会把它们联想在一起。
2.通信模组支撑与连网流程
设备入网要区分开独立设备 与子设备。独立设备是自己有独立IP，自己可连云。而子设备没有独立IP，依靠网关把数据的上云。网关可以理解是一个代理机构，需要别人代理的、自己不能独立上云的，就归到子设备分组中。
tips : 如何区分设备是属于独立设备、还是子设备，这就要看设备的通信模组（设备本身具有的能力），看其是否内置完整 TCP/IP 协议栈。
TCP/IP 是一套网络协议簇。一般情况下设备内置 TCP/IP 协议栈，就能独立上云（上云依赖 ：IP协议栈 + 能够独立到达公网的通信链路），但 Tread 是个例外，它本身内置TCP/IP 协议栈，但不具备外网射频能力，需依靠 BR边界路由转发，因此Tread 归到子设备分组。
设备通信协议分析：
| 设备通信协议 | 设备类型 | 通信模组 | 是否原生支持TCP/IP | 说明 |
|---|---|---|---|---|
| Wi-Fi （如手机、电脑） | 独立设备 | Wi-Fi 模组（ESP8266/ESP32） | ✅ 是 | 完整 TCP/IP 栈 |
| 4G/5G （手机） | 独立设备 | 4G/5G模组 | ✅ 是 | 完整 TCP/IP 栈 |
| 以太网（电脑） | 独立设备 | 以太网模组（W5500、CH395） | ✅ 是 | 有独立 IP |
| NB-IoT/Cat.1 （水电燃气智能表） | 独立设备 | 蜂窝模组 NB‑IoT / Cat.1 / 4G 模组（SIM7000、Air780、EC800 等） | ✅ 是 | 蜂窝分配 IP |
| Thread （智能门锁、门窗传感器、全屋智能类） | 子设备 | Thread 模组（OpenThread） | ✅ 是 | IPv6，原生 IP |
| Zigbee （传统智能家居传感器，如开关、插座） | 子设备 | Zigbee 模组 | ❌ 否 | 网关协议转换 |
| LoRa、LoRaWAN （球阀） | 子设备 | LoRaWAN 模组（SX1262/SX1276 | ❌ 否 | 网关协议转换 |
| BLE （蓝牙耳机） | 子设备 | 普通 BLE 蓝牙模组（非 IP-BLE） | ❌ 否 | 网关或手机上云 |
| RS485 Modbus （工业仪表、传感器、变频器、电表、PLC） | 子设备 | RS485/Modbus 射频 / 串口模组 | ❌ 否 | 串口总线 |
2.1、子设备连网流程
2.2、独立设备连网流程
网关属于独立设备，上面的子设备连网成功后，数据未必能上云，还需要网关桥接。
3.设备所需时长
设备上电后，需要多长时间才能入网呢？这会影响到用户体验，但并没有统一的值，需要根据模组跟现场网络情况而定。一般情况下：有线的比无线的快些，短距的比蜂窝的快一些，低功耗的比蜂窝的要慢些。但并不是绝对，比如有线，未必比短距无线快（WiFi、蓝牙等）。
之前做智慧农业项目时，球阀多用LoRa和NB模组。问开发同事关于设备入网时长时，他们也没给出一个相对明确的答案，只是跟你说12小时后，准都能连上，连不上应该是哪里出问题啦。所以每次新增设备时，都是先让一线同事把设备提前安装并通好电（或者说激活设备），再批量导入设备（注册）。然后第二天再过来检查结果，整合注册不成功的清单，逐一排查问题。
不同通信方式入网时长总对比
| 分类 | 技术制式 | 典型入网时长 | 关键影响因素 / 备注 |
|---|---|---|---|
| 蜂窝物联网 | NB-IoT | 首次注册：约 55秒 （无先验频点） 锁定频点后：约 8秒 复杂多频段：50秒甚至更久 厂商建议预留：至少 3分钟 特定良好环境：约 10秒 | 频段数量、信号质量、是否有历史频点记录；首次注册最慢 |
| 4G Cat.1 | 正常注册：不超过2分钟 | 合宙文档给出的正常注册网络时间上限 | |
| 短距无线 | Wi-Fi | 已保存网络重连：150ms~200ms 首次 WPA2-AES 连接：约 10秒 （密钥生成） 理想实验条件：约 224.5ms | 是否首次连接、加密方式、是否已保存网络 |
| 蓝牙 | 协议层连接：中心设备发起约 2.69ms ，外设等待约 1.3ms | 仅为协议层连接时间；实际从模块上电到可连接还需额外启动时间 | |
| 低功耗广域 | LoRa / LoRaWAN | 理想环境单次 Join：数秒 （单次交互约 68ms~1.8秒） 拥堵/占空比受限时：37.5分钟 甚至更久 实测最差：2小时内 15 个设备未能入网（单次重传达 173 次） | 受占空比法规和网络拥塞影响极大；高扩频因子（SF12）下入网时间可比无限制场景增加 100 倍以上 |
| 网状网络 | Thread | 初始连接建立较快；通常 2 分钟内从子节点升级为路由器 | 时间主要用于网络拓扑稳定和角色升级 |
| 有线 | 以太网 | 常规自协商（10/100/1000BASE-T）：2.5秒~5.3秒 快速/工业场景需求：500ms 甚至 100ms 以内 （如 1000BASE-T1） 实验室理想：约 600ms | 取决于速率、是否启用自协商、MDI/MDIX 切换；工业场景追求毫秒级 |
| 卫星通信 | 卫星终端 | 便携/手持首次入网：≤90秒 （天通），同波束再开机 ≤70秒 船载终端：≤180秒 自动对星终端：约 5分钟 （卫星捕获不到 3 分钟） 电子可控天线：捕获 30秒以内 跨星跨波束切换优化：2秒（特定技术，非首次开机） | 高度依赖终端类型（手持/船载/自动对星）；首次开机与波束切换差异巨大 |
说明：表中"入网"含义因技术而异------蜂窝/LoRa/Thread/卫星指完成网络协议层注册或对星，Wi-Fi/蓝牙指建立连接，以太网仅指物理层链路连通。实际产品从"上电"到"可用"还需叠加硬件启动、协议栈初始化等时间，具体以模组手册和实测为准。
（以上信息来源deepseek，仅供参考）
4.入网失败原因
1、入网失败原因，大概可以从以下几方面入手排查：
一是硬件问题：如设备本身坏了，蜂窝的设备SIM 卡坏了、或者是无效卡，模组的 IMEI 不合法，接口存在氧化或接触不良等情况
二是外界问题：如设备断电，信号强度过低、或者设备所处位置存在覆盖盲区（如地下室、隔墙、农作物遮挡等）；
三是操作问题：如插卡不对、没激活设备、线缆未完全插入；
四是费用问题：如卡欠费停机等、套餐开通存在延时等；
五是技术问题：上面问题都排查了，那大概率是技术问题，这事找开发吧，我么不瞎猜测。
5.入网许可
上面讲的是入网失败问题，入网失败的前提是网关、基站、路由等都是开着的，是欢迎设备/子设备来连接的，还有一种情况是网关/基站/路由 提前设置不让新设备接入，也就是关掉入网许可。
目前并不是所有 网关/基站/路由 都支持这样的操作。具体还需要跟厂商了解，基站是支持的，但不是个人/企业可以设置的，需要跟运营商协商设定。
tips：关掉入网许可，是拒绝新子设备入网；射频可以保持打开，已经入网的老设备不受影响
哪些网关/路由支持 关闭入网许可
| 设备类型 | 能否禁止新设备接入 | 实现方式 & 说明 |
|---|---|---|
| 家用 / 工业 Wi‑Fi 路由器 | ✅ 支持 | 1. 关闭 WPS；2.MAC 地址白名单 / 黑名单；3. 隐藏 SSID（弱防护）。射频常开，已连设备正常通信 |
| Zigbee 网关（协调器） | ✅ 支持 | permit join开关，关闭入网许可；也可基于 IEEE MAC 黑白名单。射频常开，老子设备不受影响 |
| Thread 边界路由器 BR | ✅ 支持 | 关闭 Commissioning（入网授权）；射频常开，已入网 Mesh 设备正常通信，新设备无法加入 |
| 蓝牙 Mesh 网关 | ✅ 支持 | 关闭 Provisioning 调配权限，MAC 白名单过滤；普通 BLE 网关可配置 MAC 过滤 |
| LoRaWAN 网关 | ⚠️ 有限支持 | 普通网关本身不做鉴权，Join 鉴权在 LNS 服务器；高端工业网关可本地过滤 DevEUI，丢弃陌生入网报文。常规方案在 IoT 平台拉黑设备 |
| 蜂窝基站（NB/4G/5G 基站） | ❌ 基站本地不能设置 | 鉴权不在基站，由运营商核心网 / HSS 完成；不能在基站侧直接拦新终端，只能在核心网拉黑 SIM 卡 / IMEI，基站射频持续工作 |
| CAN 网关 | ✅ 支持（总线层面） | 可配置报文过滤，拒绝陌生节点报文；一般较少用于 "禁止新节点入网" 场景，多用于报文过滤 |
tips：还有一种方法：不关掉基站/网关/路由的入网许可功能（相当于不是关掉所有新设备的入网许可），而只是拒绝特定一批设备的入网申请。这种方式可通过设备SN、设备名称、设备秘钥等做标记。
蜂窝基站不支持本地关闭新终端附着，鉴权在运营商核心网。
二、设备注册
对于 IOT 系统，设备入网后，一般接下来就是进行设备注册。设备注册，我们前面也说过，是解决设备能不能被 IOT系统识别和管理问题。
设备就算入网成功，如果被 iot 系统识别，还是不能被 IOT系统、 以及上层系统如 PC端和移动端去管控设备。
设备注册相当于与 IOT系统对口号，一方面是设备本身得具有的信息，然后在 IOT 系统上设置对应的通过方式。当面市面上流行的方式大概分三种：
1、一机一密（TLS单向认证）
一机一密：是指每一台设备有单独的设备名称、设备密码。
设备通过一机一密的方式与iot 系统连接，是指设备在出厂时已经烧录好：ProductKey + DeviceName + DeviceSecret（三元组）信息。设备连接iot 系统前，系统预先批量导入三元组信息。具体某一设备注册时，只需录入其三元组信息即可（也可批量导入），这一步也叫设备鉴权，如果输入的信息与系统预先导入的信息不一致，系统会拒绝它的建联申请。设备鉴权成功后，在系统建立设备档案信息。
适用场景：一机一密的验证方法需要每台设备都要烧录不同的设备名称 和密钥，产线烧录工作量大，密钥泄露单台风险。因而这种方式适用于安全要求较高、设备量不是很多的场景。
2、一型一密（TLS单向认证）
一型一密：是指同型号全部设备共用一套ProductKey、PruductSecret。设备没烧录单独的DeviceName 和 DeviceSecret。
设备通过一机一密的方式与iot 系统连接，是指设备在出厂时已经烧录好：ProductKey和PruductSecret 信息（产品信息，用于动态注册）。然后在系统先录入ProductKey + ProductSecret + 本机 DeviceName (设备是没有烧录这个信息的，一般取设自设备芯片 的SN/MAC/IMEI，具体需要使用哪个，事先要预定好)。设备首次连接iot 系统时，输入设备的 ProductKey + ProductSecret + 本机 DeviceName。云端校验 ProductSecret 是否合法，如果合法，在平台新建改DeviceName的设备档案，生成DeviceSecret下发给设备。获取到DeviceSecret 后，设备把DeviceName + DeviceSecret 存入Flash（设备闪存） 。之后每次鉴权，使用ProductKey + DeviceName + DeviceSecret 三元组信息。后续不再用 ProductSecret。
适用场景：一型一密的验证方法需要同一型号的设备都要烧录一样的产品名称，产品密码，产线烧录工作量相对小，但密钥泄露同一型号设备，风险较大。因而这种方式适用于安全要求不高、设备量很多的场景。
3、X.509证书鉴权 （mTLS双向认证）
X.509证书鉴权：是指每一个设备都单独有自己的设备证书（公钥）和设备私钥。设备在出厂前已经烧录好私钥，它相当于私人印章，烧在设备Flash/安全芯片，永远不发给任何人。
设备验证流程：
1.平台CA（证书颁发机构，可以是IOT平台自建的内部发证机构，也可以是外部第三方官方CA）预先给每台设备生产X.509证书（里面包含设备公钥）+设备私钥。
2.工厂把【证书+私钥】烧录到设备，云端平台预先存入该设备证书的公钥。
3.设备连云建立MQTTS 连接时（握手阶段）：
- 设备校验平台：设备验证云端证书（确认云是真云，不是假服务器），如果是假的服务器，设备放弃连接。
- 平台校验设备：设备拿出本地私钥，对一段随机数据签名（相当于盖上自己的私章），连同设备证书一起发给云端。云端取出证书里的公钥，校验这个签名。
4.校验结果：签名对得上，确认设备是真的，允许接入，签名对不上。拒绝连接。
适用场景：X.509证书鉴权的验证方法需要每个的设备都要烧录单独的公私秘钥，产线烧录工作量大，且每个设备的鉴权都需要设备满足证书解析能力要求。
私钥不出设备，安全性能极高。因而这种方式适用于安全要求极高。
日常项目中使用 X.509证书鉴权 相对少些，如有伙伴对这一块干兴趣，可以去读下 华为关于 MQTT(S)协议-证书鉴权的描述：https://support.huaweicloud.com/intl/zh-cn/usermanual-iothub/iot_01_0211.html
设备注册三种方式对比
|--------|---------------------------------------------|-----------------------------------------------------------------------------|-----------------------------|
| 对比项 | 一机一密（三元组） | 一型一密 | X.509 证书鉴权 |
| 核心凭证 | ProductKey + DeviceName + DeviceSecret（三元组） | ProductKey + ProductSecret（产品级密钥）+DeviceName（设备唯一名称，每台设备不一样，常用 SN、MAC、IMEI） | 设备证书 + 设备私钥（非对称） |
| 密钥特点 | 一机一钥，每台设备 DeviceSecret 互不相同 | 同型号全部设备共用一套 ProductSecret | 一机一证书，私钥仅保存在设备本地，不对外泄露 |
| 烧录方式 | 出厂前烧完整三元组；云端提前批量创建设备档案 | 出厂只烧ProductKey + ProductSecret，不烧 DeviceSecret | 出厂烧录设备证书与私钥，可存入安全芯片 |
| 注册流程 | 上电直接鉴权接入，无需动态注册 | 首次联网动态注册，向云端申请 DeviceSecret 并保存 Flash；后续使用三元组鉴权 | 上电直接使用证书做 mTLS 双向认证，无动态注册环节 |
| 加密类型 | 对称加密（HMAC-SHA） | 对称加密（HMAC-SHA） | 非对称加密 |
| 安全等级 | 中等偏高 | 中等（ProductSecret 泄露会被批量注册伪造设备） | 最高，私钥不出设备，难以伪造 |
| 产线工作量 | 大，每台设备烧录不同密钥 | 很小，同型号统一烧一套产品密钥 | 中等，证书签发 + 烧录，推荐安全芯片存放私钥 |
| 设备算力要求 | 低，普通 MCU 即可 | 低，普通 MCU 即可 | 较高，需要证书解析能力 |
| 适用场景 | 工业设备、高安全要求项目，批量可控量产 | 海量量产传感器，不想产线逐个烧录独立密钥 | 车联网、工业高安全、金融级 IoT，对防伪造要求极高 |
| 短板 | 产线烧录成本高，密钥泄露单台风险 | 产品密钥泄露，攻击者可批量注册假设备 | 证书占用存储，开发调试复杂，硬件成本更高 |
关于设备注册与鉴权，上面3种情况，是比较理想的情况，也就是设备先烧录信息、并提供过来。但如果碰获取不到完整的信息，比如设备不烧录：ProductKey + ProductSecret + DeviceName + DeviceSecret。那就只能提供 设备的 SN/MAC/IMEI（一般会把 SN/MAC/IMEI 当成 DeviceName） 动态注册，通过系统动态获取 ProductKey + DeviceSecret，注册成功后，系统还是通过设备的三元组去 与网关或者云连接收发报文的。
tips：一般设备都会烧录 SN/MAC/IMEI。
三者都是硬件出厂就固化在芯片 / 模组里面的一串唯一编号，不是人工烧录的密钥，常用来充当设备标识（DeviceName）