一、设备侧在四步协商中的角色 在OpenHarmony统一互联的EC-SPEKE协议中，CH585瘦设备作为Server（SPEKE_TYPE_SERVER）响应协商，手机App（运行OpenHarmony/HarmonyOS的富设备）作为Client（SPEKE_TYPE_CLIENT）发起。四步协商的报文流转为 spekeMsg1 → spekeMsg2 → spekeMsg3 → speke

一、GATT服务注册模型不匹配 现象 iot_connect_sdk 调用 BleGattsStartServiceEx 传入属性列表动态注册GATT服务（OHOS标准流程），但CH585的WCH协议栈使用 GATTServApp_RegisterService 注册静态属性表。直接调用动态注册API会导致服务注册失败或属性表损坏。 根因 两种GATT注册模型的差异： 维度IOTC SDK (OH

一、IOTC GATT注册的分层架构 IOTC SDK的GATT服务注册遵循OHOS标准蓝牙接口，采用动态属性表注册模型。整个注册流程从应用层Profile定义出发，经过三层结构转换，最终通过OHOS C API BleGattsStartServiceEx 将属性列表提交给底层协议栈。 注册流程经过六层调用： ble_svc.c: BleServiceInit() └─ ble_svc.c: B

一、EC-SPEKE在OpenHarmony统一互联中的角色 OpenHarmony统一互联的安全底座分为两个层级。富设备（手机、平板）通过分布式软总线（DSoftBus）认证模块，基于HiChain框架运行PAKE协议族完成设备间安全认证。瘦设备（如CH585 BLE SoC）资源受限，无法承载HiChain的完整状态机和protobuf报文，转而通过 iot_connect_sdk 内置的EC