DLMS/COSEM 蓝皮书解读（四十三）：ISO/IEC 8802-2 LLC Type 1 setup（class_id = 57）—— 无连接、不确认的 LLC

DLMS/COSEM 蓝皮书解读四十三ISO/IEC 8802-2 LLC Type 1 setupclass_id 57—— 无连接、不确认的 LLCType 1 只有UI 帧最大多少字节一个开关系列说明本系列基于 DLMS UA《Blue Book蓝皮书第 16 版 · 第 2 部分》一个接口类一篇。第 40/41 篇在 S-FSK 的 LLC/发现机制里打转本篇class_id 57跳到更通用的ISO/IEC 8802-2 LLC标准。文档把 LLC 按操作类型分成 Type 1 / 2 / 3 三族class_id 57/58/59本篇是Type 1 —— 无连接、不确认connectionless, unacknowledged后续两篇再讲面向连接和确认无连接。上篇回顾第 42 篇的S-FSK Reporting system list(56) 解决新表怎么被发现。但无论什么下层应用数据最终都要过一层 LLC 才能成帧。ISO/IEC 8802-2 是业界通用的 LLC 规范DLMS 在某些通信 profile里用它。本篇的 Type 1 是其中最轻量的一档不建链、不确认、只管我能发多大的 UI 帧。0. 为什么需要这个类 —— 不是所有链路都要可靠传输ISO/IEC 8802-2 把 LLC 定义了三种操作类型对应三种可靠度 / 复杂度取舍类型操作方式是否建链是否确认典型 PDU适合场景Type 1无连接connectionless否否UIUnnumbered Information广播、状态通告、对可靠性要求不高的偶发数据Type 2面向连接connection-oriented是是I 帧 确认I / RR / REJ …需要可靠、按序、流控的对话第 44 篇Type 3确认无连接acknowledged connectionless否是ACn 命令/应答ACn command / response要确认但又不想建链的偶发请求第 45 篇DLMS/COSEM 在some communication profiles里用到 ISO/IEC 8802-2 LLC原文“used in some DLMS/COSEM communication profiles”。Type 1 因为最轻常出现在不需要逐帧确认的链路比如某些基于 802.2 的 MAC 之上、只传 UI 帧的抄表通道。没有Type 1 setup对象你就没法统一约定 UI PDU 信息段的最大字节数——而 LLC 本身对这个值不施加限制原文全靠 MAC 和本对象的约定来兜底。蓝皮书原文ISO/IEC 8802-2 LLC Type 1 setup, Overview“An instance of the ‘ISO/IEC 8802-2 LLC Type 1 setup’ IC holds the parameters necessary to set up the ISO/IEC 8802-2 LLC layer in Type 1 operation.”1. 类蓝图ISO/IEC 8802-2 LLC Type 1 setup 0…n class_id 57, version 0属性静态/动态数据类型MinMaxDefShort namelogical_namestaticoctet-string———xmax_octets_ui_pdustaticlong-unsigned——128x 0x08Specific methodsm/oISO/IEC 8802-2 LLC Type 1 setup该类无方法。说明max_octets_ui_pdu蓝图里只列了Def 128没有 Min/Max。最大值的硬约束来自 MAC 层与互操作下限——见 §2.1。2. 属性逐条解读2.1 logical_name蓝皮书原文ISO/IEC 8802-2 LLC Type 1 setup, attribute description“Identifies the ‘ISO/IEC 8802-2 LLC Type 1 setup’ object instance.”示例 OBIS0.0.27.0.0.255非蓝皮书原文实际以设备对象列表为准。2.2 max_octets_ui_pdustatic, long-unsigned, 默认 128蓝皮书原文ISO/IEC 8802-2 LLC Type 1 setup, attribute description“Refer to the appropriate MAC protocol specification for any limitation on the maximum number of octets in a UI PDU. No restrictions are imposed by the LLC sublayer. However, in the interest of having a value that all users of Type 1 LLC may depend upon, all MACs shall at least be capable of accommodating UI PDUs with information fields up to and including 128 octets in length.”这段话信息量很大拆开看LLC 子层本身不限制UI PDU 的字节数“No restrictions are imposed by the LLC sublayer”真正的上限看 MAC具体介质访问方法HDLC、各种 PLC MAC…的规范会规定它能承载多大的 UI PDU互操作下限 128 字节为了让所有 Type 1 用户都有可依赖的值标准规定任何 MAC 至少要能装下信息段最长 128 字节的 UI PDU——这就是默认 128 的来由见 ISO/IEC 8802-2, 6.8.1。工程含义取值含义128默认最保守、互操作最安全——任何合规 MAC 都接得住 128本链路只用更小的 UI 帧少见除非上层有意限制 128仅当所用 MAC 确实支持更大 UI PDU 时才设否则对端可能收不下3. 方法无蓝皮书原文Specific methods m/o该类 methods 列为空——ISO/IEC 8802-2 LLC Type 1 setup没有方法。Type 1 本身就是无连接、不确认没有建链/断链/重置之类动作自然不需要方法。配置完max_octets_ui_pdu即可用。4. 【实战举例】示例 1Type 1 的 UI 帧长预算工程示意设max_octets_ui_pdu 128典型 802.2 LLC 头DSAPSSAPUI 控制字节 可能的 SNAP约 3~8 字节则UI PDU 总长上限 ≈ 128信息段 LLC 头说明128 是原文信息段(information field)下限LLC 头 3~8 字节为工程示意具体看 802.2 封装。排一帧装不下问题时用 128 当信息段上限去算 APDU 是否要分段。示例 2为什么默认 128 是安全值甲设备 MAC 只支持 UI 信息段 ≤ 128 乙设备 MAC 支持 ≤ 512 两者协商 Type 1 → 取 max_octets_ui_pdu 128 → 任一方向发的 UI 帧信息段都不超 128 → 双方都接得住原文all MACs shall at least … 128 octets保证了只要双方都遵守默认 128永远不会出现我发了你收不下。示例 3某 MAC 上限更小怎么办工程示意非蓝皮书原文若所用 MAC 规范规定 UI 信息段最大只能 64 字节小于 128则必须把max_octets_ui_pduSET 为 64否则按 128 发的帧会被该 MAC 丢弃SET ISO/IEC 8802-2 LLC Type 1 setup / max_octets_ui_pdu long-unsigned 64注意这是MAC 规范比 128 更严的假设场景标准只强制 128 是下限实际 MAC 上限可能更小也可能更大以所用 MAC 规范为准。示例 4Type 1 与不确认带来的丢帧风险Type 1 不确认所以主站 发 UI PDU含 xDLMS 请求 → server 链路丢了 → 无 ACK → 主站不知道丢了 主站 只能靠上层超时重发xDLMS 自己的重传/应用层重试要点Type 1 把可靠性完全交给上层。它适合发了就走、丢了再说的轻量交互要可靠就得上 Type 2第 44 篇或 Type 3第 45 篇。示例 5与 SN / LN 访问的关系工程视角无论 Type 1/2/3LLC 之上是同样的 xDLMS 服务GET/SET/ACTION。区别只在LLC 怎么传LN 访问按 logical_name attribute_index 寻址套在 LLC PDU 里 SN 访问按 short namex 偏移寻址同样套在 LLC PDU 里 Type 1 只负责把这一 PDU 以 UI 帧发出去、不确认示例 6何时该选 Type 1 而不是 Type 2/3你的需求选周期广播时钟/费率、丢了无所谓Type 1本篇一问一答的关键抄读、要可靠按序Type 2第 44 篇单笔请求要确认、但不想建链开销Type 3第 45 篇示例 7DSAP / SSAP 与 UI 帧结构工程示意非本类原文逐字Type 1 的 UI PDU 在 802.2 里典型封装| DSAP (1B) | SSAP (1B) | ControlUI (1B) | [SNAP 5B 可选] | Information (≤ UI 上限) |DSAP 目的服务访问点谁收SSAP 源服务访问点谁发Control0x03 表示 UI无编号信息。max_octets_ui_pdu 128约束的是Information 段上限原文“information fields up to … 128 octets”。说明DSAP/SSAP/Control 取值为 802.2 通用知识非本类蓝皮书逐字此处帮理解 UI 帧结构以所用 MAC/LLC 规范为准。示例 8Type 1 在 DLMS 里的典型落点Type 1 常用于对可靠性要求不高、追求简单的通道例如某些基于 802.2 LLC 的 MAC 之上的广播/组播参数下发周期性的时钟/费率广播丢了重发即可无需逐帧确认。关键交互建档、读数一般走更可靠的 Type 2/3 或直接 xDLMS over 其它传输。示例 9为什么 128 是所有人都满足的公约数工程视角设网络里混了老 MAC只支持 64 字节 UI和新 MAC支持 512。若按原文至少 128老 MAC 其实不满足 128——这时就要把max_octets_ui_pdu设成两 MAC 的较小上限(64)。原文的 128 是理想下限真实互操作要以链路两端 MAC 的真实上限取小。示例 10Type 1 与上层重传的分工Type 1 不确认所以丢了怎么办完全由上层决定链路层发 UI不确认无重传 应用层(xDLMS)若超时没收到响应 → 应用层重试 GET/SET这意味着 Type 1 通道上的 xDLMS 超时设置要宽容些否则会把链路偶丢放大成应用层频繁重试风暴。示例 11和 Type 2/3 的配置量对比类属性数有无确认有无窗口适用57 Type 11max_octets_ui_pdu否否轻量广播59 Type 35是(ACn)否单笔确认58 Type 28是(I帧)是(k/RW)可靠会话配置越重越可靠选型看业务对可靠/按序/流控的需求强度。示例 12误把 Type 1 当可靠通道的现场事故某项目用 Type 1 传关键「remote disconnect」命令结果 PLC 一次突发噪声把 UI 帧丢了链路不确认、上层又没配重传 → 跳闸命令石沉大海。教训关键控制命令别走 Type 1要么上 Type 2/3要么在应用层显式加重传确认。示例 13Type 1 能传的就只有 UIType 1 操作下LLC 只处理 UI无编号信息一类 PDU它没有I/S/U 的建链/确认帧。所以 Type 1 “能传的就只有 UI”——所有 xDLMS APDU 都以 UI 帧承载。若业务需要确认/流控那是 Type 2/3 的职责不是 Type 1 setup 能补的。示例 14LN/SN 寻址不影响选 Type 1 还是 Type 2无论 logical_name(LN) 还是 short name(SN) 访问到了 LLC 层都封装成 UI PDUmax_octets_ui_pdu限制的是这层 UI 信息段。LN/SN 的选择在更上面和选 Type 1 还是 Type 2是正交的两件事。5. 工程上容易踩的坑max_octets_ui_pdu默认 128 是下限互操作值标准只保证 MAC 至少支持 128设更大要看 MAC 真支持否则对端收不下。LLC 不限制 UI 长度限制来自 MAC别以为 128 是硬上限——上限是 MAC 规范定的128 只是所有人都得满足的最小能力。Type 1 不确认 不可靠丢帧无 ACK、无重传可靠性只能靠上层别拿它传丢了就出大事的数据。蓝图只有 Def128没有 Min/Max不要自行假设 Min1、Max某个值实际上限以 MAC 规范为准。无方法Type 1 没有 reset / 重初始化之类动作配置是纯静态属性。和 Type 2/3 别混三个类(57/58/59)对应三种操作不能配了 Type 1 又期待有窗口/确认——那是要 Type 2。some profiles才用不是所有 DLMS profile 都跑 8802-2 LLC确认你的设备链路确实用了 ISO/IEC 8802-2 再谈这些类。6. 小结 下期预告本篇要点ISO/IEC 8802-2 LLC Type 1 setup(57) 配置Type 1 无连接、不确认的 LLC用于某些 DLMS profile只有一个配置属性max_octets_ui_pdu默认128——它是所有 MAC 至少支持的互操作下限LLC 本身不限制长度上限真正由MAC 规范决定设超过 MAC 能力会导致对端收不下该类无方法Type 1 把可靠性完全交给上层。下一篇第 44 篇ISO/IEC 8802-2 LLC Type 2 setupclass_id 58—— Type 2 面向连接、确认式传输。它有 8 个属性发送/接收窗口(k/RW)、I 帧最大字节(N1)、最大重传次数(N2)以及 4 个定时器确认 / P 位 / 拒绝 / 忙状态。这才是可靠对话的完整参数本。参考资料DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》ISO/IEC 8802-2 LLC Type 1 setup(class_id 57, version 0) 章节文中属性、数据类型、Short name 偏移、引文均与原文一致示例中的 OBIS、字节预算、场景为帮助理解而构造标注示例/非蓝皮书原文实际以设备对象列表及所用 MAC 规范为准。