企业官网建设流程全解析

DLMS/COSEM 蓝皮书解读（四十四）：ISO/IEC 8802-2 LLC Type 2 setup（class_id = 58）—— 面向连接的可靠 LLC：窗口 + 重传 + 四定时器全配齐

系列说明：本系列基于 DLMS UA《Blue Book（蓝皮书）第 16 版 · 第 2 部分》，一个接口类一篇。第 43 篇ISO/IEC 8802-2 LLC Type 1 setup(57) 讲了最轻的"无连接、不确认"LLC，只有一个max_octets_ui_pdu。本篇（class_id = 58）升级到Type 2 —— 面向连接、确认式传输：要建链、要按序、要流控、要重传，所以配置项一下子变成 8 个。

上篇回顾：第 43 篇的 Type 1 把可靠性全甩给上层——发了就走、丢了不管。但抄表里有"一问一答不能丢、还得按序"的关键对话。这类需求就得 Type 2：用 I 帧 + 确认 + 滑动窗口保证可靠。本篇就是把这套可靠机制的所有旋钮列出来的对象。

0. 为什么需要这个类 —— 当"发了就走"不够用时

Type 2 LLC 提供面向连接的可靠传输：发送方发 I 帧，接收方回确认；窗口限制"能压多少未确认帧"；定时器管"等多久没确认就重传"。这正好补上 Type 1 缺的"可靠性 + 流控"。

在 DLMS 的某些用 ISO/IEC 8802-2 LLC 的 profile 里，关键会话（如建档、参数下发、大块数据读出）走 Type 2，普通广播走 Type 1。没有Type 2 setup对象，这些"可靠旋钮"就没法标准化配置。

蓝皮书原文（ISO/IEC 8802-2 LLC Type 2 setup, Overview）：
“An instance of the ‘ISO/IEC 8802-2 LLC Type 2 setup’ IC holds the parameters necessary to set up the ISO/IEC 8802-2 LLC layer in Type 2 operation.”

8 个属性分两类：窗口/尺寸类（k、RW、N1、N2）和定时器类（acknowledgement / p-bit / reject / busy-state）。下面逐个对照原文。

1. 类蓝图

ISO/IEC 8802-2 LLC Type 2 setup 0…n class_id = 58, version = 0

Specific methods（m/o）：ISO/IEC 8802-2 LLC Type 2 setup该类无方法。

说明：蓝图里只显式给了transmit_window_size_k/receive_window_size_rw的 Min=1、Max=127、Def=1，以及max_octets_i_pdu_n1的 Def=128；max_number_transmissions_n2与四个定时器未列 Min/Max/Def，取值以 ISO/IEC 8802-2 与所用 MAC 规范为准。

2. 属性逐条解读

2.1 logical_name

蓝皮书原文：“Identifies the ‘ISO/IEC 8802-2 LLC Type 2 setup’ object instance.”

示例 OBIS：0.0.27.1.0.255（非蓝皮书原文，实际以设备对象列表为准）。

2.2 transmit_window_size_k（static, unsigned, 1…127, 默认 1）

蓝皮书原文：“The transmit window size (k) shall be a data link connection parameter that can never exceed 127. It shall denote the maximum number of sequentially numbered I PDUs that the sending LLC may have outstanding (i.e., unacknowledged). The value of k is the maximum number by which the sending LLC send state variable V(S) can exceed the N® of the last received I PDU.”

• k =发送窗口：发送方"已发出但未确认"的 I 帧最多多少。上限 127。
• 默认 1 → 退化为"停等(stop-and-wait)"：发一帧、等到确认再发下一帧。增大 k 可流水线、提升吞吐（受接收方 RW 约束）。

2.3 receive_window_size_rw（static, unsigned, 1…127, 默认 1）

蓝皮书原文：“The receive window size (RW) shall be a data link connection parameter that can never exceed 127. It shall denote the maximum number of unacknowledged sequentially numbered I PDUs that the local LLC allows the remote LLC to have outstanding. It is transmitted in the information field of XID … and applies to the XID sender. The XID receiver shall set its transmit window (k) to a value less than or equal to the receive window of the XID sender to avoid overrunning the XID sender.”

• RW =接收窗口：本端允许对端"未确认"的 I 帧最多多少。
• 关键约束：XID 握手时本端把自己的 RW 告诉对端；对端必须把它的 k 设 ≤ 本端 RW，否则会冲垮本端缓冲（overrun）。

2.4 max_octets_i_pdu_n1（static, long-unsigned, 默认 128）

蓝皮书原文：“N1 is a data link connection parameter that denotes the maximum number of octets in an I PDU. Refer to the various MAC descriptions to determine the precise value of N1 for a given medium access method. LLC itself places no restrictions on the value of N1. However, in the interest of having a value of N1 that all users of Type 2 LLC may depend upon, all MACs shall at least be capable of accommodating I PDUs with information fields up to an including 128 octets in length.”

• N1 = I 帧最大字节数。与第 43 篇 Type 1 的 UI PDU 同理：LLC 不限制，但 MAC 至少支持 128 信息段（互操作下限），默认 128。

2.5 max_number_transmissions_n2（static, unsigned，无 Min/Max/Def）

蓝皮书原文：“N2 is a data link connection parameter that indicates the maximum number of times that a PDU is sent following the running out of the acknowledgment timer, the P-bit timer, the reject timer, or the busy-state timer.”

• N2 = 某个定时器超时后，PDU最多重传几次。耗尽仍未确认 → 连接被认为失败（上报断链）。

2.6 acknowledgement_timer（static, long-unsigned，单位 秒）

蓝皮书原文：“The acknowledgment timer is a data link connection parameter that shall define the time interval during which the LLC shall expect to receive an acknowledgment to one or more outstanding I PDUs or an expected response PDU to a sent unnumbered command PDU. The unit is seconds.”

• 等"对已发 I 帧 / 无编号命令的响应"的确认，超时即触发按 N2 重传。

2.7 p_bit_timer（static, long-unsigned，单位 秒）

蓝皮书原文：“The P-bit timer is a data link connection parameter that shall define the time interval during which the LLC shall expect to receive a PDU with the F bit set to ‘1’ in response to a sent Type 2 command with the P bit set to ‘1’. The unit is seconds.”

• 发带P 位=1的 Type 2 命令后，等对方回F 位=1的 PDU；超时按 N2 重传。

2.8 reject_timer（static, long-unsigned，单位 秒）

蓝皮书原文：“The reject timer is a data link connection parameter that shall define the time interval during which the LLC shall expect to receive a reply to a sent REJ PDU. The unit is seconds.”

• 发REJ（拒绝/请求重传）后，等待对方补发被拒帧的回复；超时按 N2 重传。

2.9 busy_state_timer（static, long-unsigned，单位 秒）

蓝皮书原文：“The busy-state timer is a data link connection parameter that shall define the timer interval during which the LLC shall wait for an indication of the clearance of a busy condition at the other LLC. The unit is seconds.”

• 对端进入 busy 后，本端等多久等它"解除忙"的指示；超时按 N2 重传。

3. 方法：无

蓝皮书原文（Specific methods m/o）：该类 methods 列为空——ISO/IEC 8802-2 LLC Type 2 setup没有方法。

Type 2 的"建链/断链/重传"由 LLC 状态机按这些参数自动跑，不需要对象暴露方法；配置好 8 个参数即可。

4. 【实战举例】

示例 1：窗口协商（k ≤ RW）

本端 RW = 4 → 在 XID 里告诉对端"我最多收 4 个未确认" 对端 据此设 k = 4（必须 ≤ 4） → 对端可连续发 4 个 I 帧再等确认（流水线）

若对端硬设 k=8 而本端 RW=4 → 本端缓冲会被冲垮（原文 overrun 警告）。

示例 2：stop-and-wait（默认 k=RW=1）

发 I[ N(S)=1 ] → 等确认 收到 RR[ N(R)=2 ] → 发 I[ N(S)=2 ] → …

默认配置下 Type 2 退化成"一发一确认"，最稳但吞吐最低。低速链路常用。

示例 3：定时器超时 → 重传（工程示意）

发 I[ N(S)=5 ]，启动 acknowledgement_timer（如 2s） 2s 内没收到含 N(R)>5 的确认 → 按 max_number_transmissions_n2 重传（如 N2=3，最多重发 3 次） 3 次仍无确认 → 连接失败，上报断链

说明：2s、N2=3 为示意（非蓝皮书原文规定值），实际以设备/网络规划为准。

示例 4：P/F 握手（p_bit_timer）

主站发 Type 2 命令 P=1（如请求状态） 启动 p_bit_timer，等对端回 F=1 对端回 RR/F=1（或带数据的 I/F=1）→ p_bit_timer 停 超时 → 按 N2 重传带 P=1 的命令

示例 5：REJ 触发 reject_timer

本端收到乱序（丢了 N(S)=5，先到 6） → 发 REJ(5)，启动 reject_timer，要对方重传 5 及之后 对方重传 5,6,… → 收到后 reject_timer 停 超时 → 按 N2 重传 REJ

示例 6：busy 流控（busy_state_timer）

对端缓冲满 → 发 RNR（receive not ready，busy） 本端 启动 busy_state_timer，暂停发 I 帧 对端缓冲腾出 → 发 RR（ready）→ busy_state_timer 停，恢复发送 超时 → 按 N2 重传/探活

示例 7：N1 与分段（与第 43 篇一致）

max_octets_i_pdu_n1 = 128→ 单个 I 帧信息段最多 128 字节。大 APDU（如长Profile generic读出）要么上层分段，要么确认 MAC 支持更大的 N1 再调大。

示例 8：四定时器单位都是"秒"

所有定时器数据类型long-unsigned、单位秒——配置时别填成毫秒。比如想等 1.5 秒应填 1 或 2（整数秒），不能填 1500。

示例 9：XID 交换协商 RW（工程示意）

Type 2 建链靠 XID 帧交换参数。典型：

主站 发 XID(带本端 RW=4) → server server 回 XID(带本端 RW=4) 双方各自把对端 RW 作为自己 k 的上限 → 都设 k=4

原文：“XID receiver shall set its transmit window (k) to a value ≤ the receive window of the XID sender”。

示例 10：窗口内注射的"流水线"收益（工程示意）

k=RW=1：发 1 等 1，吞吐 ≈ 1 帧/RTT。
k=RW=4：可连发 4 帧再等确认，吞吐 ≈ 4 帧/RTT（信道利用率高）。
高 RTT 链路（如 PLC）把 k 调大收益明显；但要两端 RW 都撑得住缓冲。

示例 11：acknowledgement_timer 超时但数据其实到了（工程示意）

偶发乱序导致确认晚到，定时器先超 → 按 N2 重传。对端收到重复 I 帧应按序号丢弃重复、回最新 N®。好实现能扛"假超时"，但 N2 太小会把"一次抖动"判成失败。

示例 12：busy 期间还能发吗

对端 RNR（busy）期间，本端应暂停发 I 帧，只发带 P 的探活（RR/P）等 busy_state_timer / 收到 RR（ready）再恢复。强行发会加剧对端缓冲溢出。

示例 13：与 Type 1/3 的"可靠度阶梯"

• Type 1：发了就走（最不可靠，最轻）
• Type 3：单笔 ACn 确认（中等可靠，无建链）
• Type 2：I 帧序列确认 + 窗口流控（最可靠，最重）
  按业务选档，别用 Type 2 做广播（浪费）、别用 Type 1 做跳闸（危险）。

5. 工程上容易踩的坑

1. k 必须 ≤ 对端 RW：XID 协商后，发送窗口上限由接收方 RW 决定；设大了一方会缓冲溢出（overrun）。
2. k / RW 上限都是 127：不能设 0（Min=1），也不能超 127。
3. N1 默认 128 是互操作下限：和第 43 篇 UI PDU 同理，真正上限看 MAC；调大前确认 MAC 支持。
4. 四个定时器单位都是秒、且是 long-unsigned：别填毫秒；超时值的合适范围看网络时延（PLC 时延大，秒级才合理）。
5. N2 耗尽 = 连接失败：重传次数用尽仍无确认，Type 2 会判链路失败；排"莫名断链"先看 N2 配太小还是信道太差。
6. 默认 k=RW=1 是 stop-and-wait：吞吐低，高时延/高带宽链路应调大窗口，但要两端协商一致。
7. Type 2 无方法：建链/断链/重传全自动；别找"reset"之类动作，没有。
8. Type 1/2/3 是三种操作，不能混用：要可靠按序用本篇(Type 2)；要轻量用 57；要确认但不建链用 59。

6. 小结 & 下期预告

本篇要点：

1. ISO/IEC 8802-2 LLC Type 2 setup(58) 配置Type 2 = 面向连接、确认式LLC，共 8 个静态属性、无方法；
2. 窗口类：发送窗口 k（1~127，默认 1）、接收窗口 RW（1~127，默认 1，须 ≥ 对端 k）、I 帧最大字节 N1（默认 128）、最大重传 N2；
3. 定时器类（均long-unsigned、单位秒）：acknowledgement / p-bit / reject / busy-state四个，超时均按 N2 重传；
4. N1 的 128 与第 43 篇同理是互操作下限，真正上限看 MAC。

下一篇（第 45 篇）：ISO/IEC 8802-2 LLC Type 3 setup（class_id = 59）—— Type 3 = 确认无连接：用 ACn 命令/应答 PDU，配置 N3（ACn 最大字节）、N4（最大重传），以及 T1/T2/T3 三个时间变量（且支持"无穷大 = 全 1"）。它是 Type 1 与 Type 2 之间的"折中档"。

参考资料：DLMS UA《Blue Book Ed.16 Part 2 – COSEM interface classes》，ISO/IEC 8802-2 LLC Type 2 setup(class_id = 58, version = 0) 章节；文中属性、数据类型、Short name 偏移、Min/Max/Def、引文均与原文一致；示例中的取值、秒数、握手时序为帮助理解而构造（标注"示例/非蓝皮书原文"，实际以设备对象列表及所用 MAC 规范为准）。