零代码制作ESP32轻量级NAS：用KIMI K2.5实现局域网文件共享
2026/10/22 6:12:23
DLMS/COSEM 蓝皮书解读（四十三）：ISO/IEC 8802-2 LLC Type 1 setup（class_id = 57）—— 无连接、不确认的 LLC：Type 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） | 否 | 否 | UI（Unnumbered 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| 属性 | 静态/动态 | 数据类型 | Min | Max | Def | Short name |
|---|---|---|---|---|---|---|
| logical_name | static | octet-string | — | — | — | x |
| max_octets_ui_pdu | static | long-unsigned | — | — | 128 | x + 0x08 |
Specific methods（m/o）：ISO/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.”
示例 OBIS：0.0.27.0.0.255（非蓝皮书原文，实际以设备对象列表为准）。
2.2 max_octets_ui_pdu（static, 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. 【实战举例】
示例 1：Type 1 的 UI 帧长预算（工程示意）
设max_octets_ui_pdu = 128，典型 802.2 LLC 头（DSAP+SSAP+UI 控制字节 + 可能的 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 规范为准。
示例 4：Type 1 与"不确认"带来的丢帧风险
Type 1 不确认，所以：
主站 发 UI PDU（含 xDLMS 请求） → server （链路丢了 → 无 ACK → 主站不知道丢了） 主站 只能靠上层超时重发（xDLMS 自己的重传/应用层重试）要点：Type 1 把"可靠性"完全交给上层。它适合"发了就走、丢了再说"的轻量交互；要可靠就得上 Type 2（第 44 篇）或 Type 3（第 45 篇）。
示例 5：与 SN / LN 访问的关系（工程视角）
无论 Type 1/2/3，LLC 之上是同样的 xDLMS 服务（GET/SET/ACTION）。区别只在"LLC 怎么传"：
LN 访问：按 logical_name + attribute_index 寻址，套在 LLC PDU 里 SN 访问：按 short name（x + 偏移）寻址，同样套在 LLC PDU 里 Type 1 只负责"把这一 PDU 以 UI 帧发出去、不确认"示例 6：何时该选 Type 1 而不是 Type 2/3
| 你的需求 | 选 |
|---|---|
| 周期广播时钟/费率、丢了无所谓 | Type 1（本篇） |
| 一问一答的关键抄读、要可靠按序 | Type 2（第 44 篇） |
| 单笔请求要确认、但不想建链开销 | Type 3（第 45 篇） |
示例 7：DSAP / SSAP 与 UI 帧结构（工程示意，非本类原文逐字）
Type 1 的 UI PDU 在 802.2 里典型封装：
| DSAP (1B) | SSAP (1B) | Control=UI (1B) | [SNAP 5B 可选] | Information (≤ UI 上限) |- DSAP = 目的服务访问点（谁收）；SSAP = 源服务访问点（谁发）；Control=0x03 表示 UI（无编号信息）。
max_octets_ui_pdu = 128约束的是Information 段上限（原文：“information fields up to … 128 octets”）。
说明：DSAP/SSAP/Control 取值为 802.2 通用知识（非本类蓝皮书逐字），此处帮理解 UI 帧结构；以所用 MAC/LLC 规范为准。
示例 8：Type 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 的真实上限取小。
示例 10：Type 1 与"上层重传"的分工
Type 1 不确认，所以"丢了怎么办"完全由上层决定：
链路层：发 UI，不确认，无重传 应用层(xDLMS)：若超时没收到响应 → 应用层重试 GET/SET这意味着 Type 1 通道上的 xDLMS 超时设置要"宽容"些，否则会把"链路偶丢"放大成"应用层频繁重试风暴"。
示例 11：和 Type 2/3 的配置量对比
| 类 | 属性数 | 有无确认 | 有无窗口 | 适用 |
|---|---|---|---|---|
| 57 Type 1 | 1（max_octets_ui_pdu） | 否 | 否 | 轻量广播 |
| 59 Type 3 | 5 | 是(ACn) | 否 | 单笔确认 |
| 58 Type 2 | 8 | 是(I帧) | 是(k/RW) | 可靠会话 |
| 配置越重越可靠；选型看业务对"可靠/按序/流控"的需求强度。 |
示例 12：误把 Type 1 当"可靠通道"的现场事故
某项目用 Type 1 传关键「remote disconnect」命令，结果 PLC 一次突发噪声把 UI 帧丢了，链路不确认、上层又没配重传 → 跳闸命令石沉大海。教训：关键控制命令别走 Type 1，要么上 Type 2/3，要么在应用层显式加重传+确认。
示例 13：Type 1 能传的就只有 UI
Type 1 操作下，LLC 只处理 UI（无编号信息）一类 PDU；它没有I/S/U 的建链/确认帧。所以 Type 1 “能传的就只有 UI”——所有 xDLMS APDU 都以 UI 帧承载。若业务需要"确认/流控"，那是 Type 2/3 的职责，不是 Type 1 setup 能补的。
示例 14：LN/SN 寻址不影响"选 Type 1 还是 Type 2"
无论 logical_name(LN) 还是 short name(SN) 访问，到了 LLC 层都封装成 UI PDU；max_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、无重传，可靠性只能靠上层；别拿它传"丢了就出大事"的数据。
- 蓝图只有 Def=128，没有 Min/Max：不要自行假设 Min=1、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 setup（class_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 规范为准）。