DLMS Green Book学习笔记

发表于 2022/04/19 更新于 2024/08/21

作者 Kai

292 分钟阅读

s1 Scope
s3 Terms, definitions and abbreviations and symbols
- s3.1 General DLMS/COSEM definitions
s4 Information exchange in DLMS/COSEM
s5 Physical layer services and procedures for connection-oriented asynchronous data exchange
s6 Direct Local Connection
- s6.2 METERING HDLC protocol using protocol mode E for direct local data exchange
- s6.3 Physical layer – Introduction
s7 DLMS/COSEM transport layer for IP networks
- s7.2 The TCP-UDP/IP based transport layers
- s7.3 The DLMS/COSEM CoAP based transport layer
s8 Data Link Layer using the HDLC protocol
s9 DLMS/COSEM application layer
s10 Using the DLMS/COSEM application layer in various communications profiles
s11 AARQ and AARE encoding examples
s12 Encoding examples: AARQ and AARE APDUs using a ciphered application context
s13 S-FSK PLC encoding examples
s14 Data transfer service examples
- s14.4 Profile generic IC buffer attribute encoding examples

s1 Scope

建模: 包括设备的接口模型和数据识别规则;在 blue book 中定义
消息: 这涵盖了将接口模型映射到协议数据单元(APDU)的服务，以及这个 APDU 的编码。在本 green book 中定义
传输: 通过通信通道传输消息。在本 green book 中定义

通信模型：

s3 Terms, definitions and abbreviations and symbols

s3.1 General DLMS/COSEM definitions

ACSE APDU：Association Control Service Element (ACSE)标准 A-ASSOCIATE/A-RELEASE 实现的 APDU，AARQ/AARE/RLRQ/RLRE
application association：两个应用实体 AEs 之间的合作关系
application entity,AE: 独立于系统的应用活动，这些活动作为应用服务提供给应用代理，例如，一组应用服务元素，它们共同执行应用程序的所有或部分通信方面。
xDLMS APDU：xDLMS Application Service Element (xDLMS ASE)使用的 APDU

s4 Information exchange in DLMS/COSEM

s4.1 General

The key characteristics of data exchange using DLMS/COSEM are the following:

devices can be accessed by various parties: clients and third parties;
使用 DLMS/COSEM 进行数据交换的主要特点如下:设备可以被各种各方访问:客户端和第三方;
mechanisms to control access to the resources of the device are provided;
提供了控制对设备资源的访问的机制;
these mechanisms are made available by the DLMS/COSEM AL and the COSEM objects ( Association SN / LN object, Security setup object);
这些机制是由 DLMS/COSEM AL 和 COSEM 对象(关联 SN / LN 对象，安全设置对象)提供的;
security and privacy is ensured by applying cryptographical protection to xDLMS messages and to COSEM data;
通过对 xDLMS 消息和 COSEM 数据应用加密保护来确保安全性和私密性;
low overhead and efficiency is ensured by various mechanisms including selective access, compact encoding and compression;
通过各种机制，包括选择性访问、压缩编码和压缩，确保了低开销和效率;
at a site, there may be single or multiple devices.
在一个站点，可能有单个或多个设备。
In the case of multiple devices at a site, a single access point can be made available;
在一个站点有多个设备的情况下，可以提供一个单一的接入点;
data exchange may take place either remotely or locally.
数据交换可以在远程或本地进行。
Depending on the capabilities of the device, local and remote data exchange may be performed simultaneously without interfering with each other;
根据设备的能力，本地和远程数据交换可以在不相互干扰的情况下同时进行;
various communication media can be used on local networks (LN), neighbourhood networks (NN) and wide area networks (WAN).
各种通信媒体可用于局域网(LN)、邻网(NN)和广域网(WAN)。

s4.2 Communication model

application processes(APs)之间的通信通过应用程序实体(application entities,AEs)之间的通信进行建模。AE 代表 AP 的通信功能。

AP 中可能有多组OSI 通信功能，因此一个AP可以用多种AEs来表示（比如一个 AP 可以使用 HDLC-based profile，也可以使用 TCP-IP based profile）。一个 AE 只对应一个 AP（可能两个 AP 都使用 HDLC-based profile，这两个 AE 也是不同的，可以理解为类和对象的关系，基于同一个类的两个对象实例化后是不同的）。一个 AE 包含一组称为 application service elements(ASEs)的通信功能

TODO:AE 的意思还不明确

s4.3 Naming and addressing

一个server AP对应一个logical device,client AP可以不对应 logical device。每个AP绑定一个 Service Access Point(SAP)，SAP位于 application layer(AL)层。也就是说 SAP 用于区分基于同一个 AL 的不同 AP(对服务端也可以说是 logical device).

s4.3.3 Addressing

SAP 用于区分基于同一个 AL 的不同 AP

IDIS 8.1 IDIS Client and Server Architecture
规定一个 COSEM 逻辑设备支持一个预连接客户端(SAP:102)，一个 Public 客户端(SAP:016)，一个 Management 客户端(SAP:001)。

s4.3.4 System title

按单一 DLMS/COSEM 实体唯一，和逻辑设备名不同，一个实体可以有多个逻辑设备(名)，但只能有一个systemtitle,实体中的逻辑设备共享该 systemtitle
固定8字节长，前 3 字节厂家 ID，和逻辑设备名相同，后面的 5 字节，应为 0-999,999,999,999(0x0-0xE8D4A50FFF)

交换方式（见 10.4.3.3）：

通信配置注册过程
在明确建立 AA 的情况下，在 AA 建立期间使用COSEM-OPEN服务;
通过在“Security setup”对象写入 client_system_title 属性和读取的 server_system_title 属性。适用于预连接 AA
加密 APDU 交换，general-ciphering (originator and recipient system title)或 general-glo-ciphering (originator system title).

s4.3.5 Logical Device Name

蓝皮书 part2 4.1.8

s4.4 Connection oriented operation

Phase 1: AA establishment
Phase 2: Message exchange
Phase 3: AA Release

预连接AA不需要 1 和 3

s4.5 Application associations

Application Associations (AAs)是一个客户端AE和一个服务端AE间的逻辑连接。可以使用 ACSE 服务建立，也可以是预连接的

一个 COSEM 逻辑设备可以支持一个或多个 AA，但它们必须是不同的客户端，也就是不允许同一个客户端使用两个以上的 AA 与同一个逻辑设备连接。每个 AA 决定发生信息交换的上下文。

confirmed AA:
confirmed AA由客户端提出并被服务器接受，前提是：
- 客户端用户为服务器所知，见 4.3.6;
- 客户端在 4.5.2 中提出的应用上下文对于服务器来说是可接受的;
- 客户端(见 4.5.3)提出的认证机制对服务器来说是可接受的，认证是成功的;
- xDLMS 上下文的元素参见 4.5.4 可以在客户端和服务器之间成功协商。
unconfirmed AA:
客户端也会提出未经确认的AA，并假设服务器会接受它。 没有协商发生。未确认的 AA 对于从客户端向服务器发送广播消息很有用。

s4.5.2 Application context

应用程序上下文确定：

AL 中存在的一组应用服务元素（Application Service Elements,ASEs）
COSEM 对象属性和方法的引用方式：短名称(SN) 引用或逻辑名称(LN) 引用。另见 9.1.4.3.1
传输语法
是否使用加密

s4.5.3 Authentication

DLMS 中的认证发生在 AA 建立阶段

在confirmed AAs中，客户端(单向认证)或客户端和服务器(双向认证)都可以对对端进行认证。
对于unconfirmed AA，只有客户端可以验证对端。
在预连接AA中，身份验证不可用。

s4.5.4 xDLMS context

xDLMS 上下文确定可以在给定的 AA 中使用的 xDLMS 服务和功能集。见 9.1.4。

additional services, see 9.1.4.3;
additional mechanisms, see 9.1.4.4;
additional data types, see 9.1.4.5;
new DLMS version number, see 9.1.4.6;
new conformance block, see 9.1.4.7;
clarification of the meaning of the PDU size, see 9.1.4.8.

s4.5.5 Security context

当应用程序上下文规定加密时，安全上下文是相关的。它包括安全套件、安全策略、安全密钥和其他安全材料。另见 9.2.2.3。它由“Security setup”对象管理。

s4.5.6 Access rights

访问权限确定客户访问 AA 内的 COSEM 对象属性和方法的权限。访问权限集取决于客户端的角色，并在服务器中预先配置。另见 9.2.2.4。

s4.6 Messaging patterns

在confirmed AA 中：

客户端可以发送确认的服务请求，服务器响应：pull操作
客户端可以发送未经确认的服务请求。服务器没有响应
服务器可以向客户端发送未经请求的服务请求：push操作

note:主动推送的服务可以是 InformationReport（使用 SN 引用）、EventNotification（使用 LN 引用）或 DataNotification（同时使用 SN 和 LN 引用）。

在unconfirmed AA 中：

只有客户端可以发起服务请求，并且只有未确认的请求。服务器无法响应，也无法发起服务请求。

s4.8 Communication profiles

通信配置文件指定了 DLMS/COSEM AL 和建模 Application Process (AP) 的 COSEM 数据模型如何由较低的通信媒体特定协议层支持。

通信配置文件包括许多协议层。每一层都有不同的任务并为其上层提供服务并使用其支持协议层的服务。客户端和服务器 COSEM AP 使用最高协议层的服务，即 DLMS/COSEM AL 的服务。这是唯一包含 COSEM 特定元素(xDLMS ASE)的协议层；见 9.1.4。任何能够提供 DLMS/COSEM AL 所需服务的层都可以支持它。较低层的数量和类型取决于所使用的通信媒体。

s4.9 Model of a DLMS/COSEM system

设备被建模为一组逻辑设备，托管在单个物理设备中。 每个逻辑设备代表一个服务器 AP，并对设备功能的一个子集进行建模，这些功能子集可以通过其通信接口看到。使用 COSEM 对象对各种功能进行建模。

数据采集系统被建模为一组客户端ap，可以由一个或多个物理设备托管。每个客户端 AP 可能有不同的角色和访问权限，由设备授予。

公共客户端0x10和管理逻辑设备0x01APs 有一个特殊的角色，它们应该一直存在。

s4.10 Model of DLMS servers

IP based profiles:

DLMS/COSEM AL由 DLMS/COSEM Transport layer(TL)支持，该 TL 由 internet TCP 或 UDP 层和一个包装器(wrapper)组成。包装器的主要作用是适应OSI风格的服务集，该服务集由 DLMS/COSEM TL 在 TCP 和 UDP 函数调用之间提供。它还为逻辑设备提供寻址，将它们绑定到一个称为包装器端口的SAP。管理逻辑设备总是绑定到包装器端口0x01。最后，包装器提供有关 APDU 传输长度的信息，以帮助对等端识别 APDU 的末端。由于 TCP 的流特性，这是必要的。

如果没有包装器这层，APDU 直接通过 TCP 发出去，由于 TCP 是流式的，APDU 不包含头尾信息，对端不知道是否是个完整的 APDU，无法解析

3-layer,CO,HDLC based profile:

DLMS/COSEM AL 由基于 HDLC 的数据链路层支持。它的主要作用是在对等层之间提供可靠的数据传输。它还以这样一种方式提供逻辑设备的寻址，即每个逻辑设备都绑定到单个 HDLC 地址。管理逻辑设备始终绑定到地址 0x01。为了允许创建一个本地网络，以便通过一个单一的接入点可以到达特定站点的几个物理设备，另一个地址，即物理设备地址也由数据链路层提供。逻辑设备地址被称为高 HDLC 地址，而物理设备地址被称为低 HDLC 地址。另见 8.4.2

s4.11 Model of a DLMS client

客户端模型

DLMS/COSEM AL 使用 HDLC 或 IP-based TLs 提供的服务，由AP决定使用哪种。
与服务器端不同，客户端的 HDLC 层提供的寻址只有一个级别，即每个应用程序流程(AP)的服务接入点(SAP)的级别。(也就是没有物理地址级别，见8.4.2，原语参数中客户端地址只有一个字节，就是 SAP 地址)

客户端 AP 和服务器端 AP 由各自的SAP识别，因此，客户端和服务器端 AP 之间的AA可以由一对客户端和服务器端SAP识别。

s4.12 Interoperability and interconnectivity in DLMS/COSEM

互操作性和互联性

Interoperability：
双方的 COSEM 对象定义相同，都使用 DLMS/COSEM AL 层
interconnectivity：
AEs 互联。如果两个 AEs 使用相同的通信配置文件，则它们是可互联的

s4.13 Ensuring interconnectivity: the protocol identification service

协议识别服务

在 DLMS/COSEM 中，AA 的建立总是由客户端AE发起。然而，在某些情况下，它可能不了解未知服务器设备所使用的协议栈（例如，当服务器启动物理连接建立时）。在这种情况下，客户端 AE 需要获得关于服务器中实现的协议栈的信息。

为此，提供了一种特定的应用级服务：协议识别服务。它是一种可选的应用级服务，允许客户机 AE 在建立物理连接后获得关于服务器中实现的协议栈的信息。5.3.3.3 中规定的协议识别服务直接使用 PhL 的数据传输服务（PH-DATA.request /.indicat）；它绕过了其他协议层。建议在所有可以访问 PhL 的通信配置文件中支持它。

s4.14 System integration and installation

系统集成和安装

DLMS/COSEM 以多种方式支持系统集成。这里描述了一个可能的过程。

如图 7 所示，Public Client(在任何配置文件中绑定到地址0x10)在每个客户端系统中都是必需的。它的主要作用是揭示一个未知的–例如新安装的–设备的结构。这发生在公共客户端和管理逻辑设备之间的强制AA中，没有安全预防措施。一旦知道了结构，就可以使用适当的身份验证机制和 xDLMS 的密码保护来访问数据

当系统中安装了新设备时，可能会向客户端生成事件报告。一旦检测到这一点，客户机就可以检索设备的内部结构，然后向设备发送必要的配置信息(例如关税时间表和特定于安装的参数)。这样，设备就可以使用了

s5 Physical layer services and procedures for connection-oriented asynchronous data exchange

物理层，以及面向连接的异步数据交换程序

s5.1 Overview

通信是点对点或点对多点
至少可以有半双工连接
异步传输 1 位起始位，8 位数据位，无奇偶校验和 1 位停止位(8N1)

串口通信原理
9600 8N1 代表着波特为 9600，8 个数据位，无奇偶校验和 1 个停止位，这一种是较为常用的串行协议配置方法。那么，9600 8N1 的数据包是什么样的呢？举个例子吧！传输 ASCII 字符’O‘和’K‘的设备必须创建两个数据包。O 的 ASCII 值（大写）为 79，则二进制值01001111，而 K 的二进制值为01001011。剩下的就是追加同步位。假设传输数据时首先传输最低位：

s5.2 Service specification

s5.2.1 List of services

建立/发布相关业务 PH-CONNECT, PH-ABORT;
数据传输业务 PH-DATA;
层管理服务
层管理服务由层管理进程使用或为层管理进程提供，层管理进程是AP的一部分。下面给出一些示例:
- PH-INITIALIZE.request / PH-INITIALIZE.confirm;
- PH-GET_VALUE.request / PH-GET_VALUE.confirm
- PH-SET_VALUE.request / PH-SET_VALUE.confirm
- PH-LM_EVENT.indication

s5.2.2 Use of the physical layer services

物理连接建立/释放服务是由物理连接管理器AP使用并为物理连接管理器AP提供的，而不是数据链路层

注意这张图很关键，表明了管理器AP用于管理物理层的关系，包括管理器AP和物理层的原语，链路层和物理层的原语

s5.2.3 Service definitions

PH-CONNECT.request 连接建立服务的服务请求原语
在 DLMS/COSEM 环境中，PH-CONNECT.request 原语的用户是物理连接管理器AP。它被用于建立一个物理连接。收到该基元后，PhL 实体将执行所需的动作–例如拨号（如物理层 PhL 向 modem 发送AT指令）–以与对等 PhL 实体建立物理连接。5.4 中给出了智能 Hayes 调制解调器情况下的这些动作的例子。
PH-CONNECT.indication 连接建立服务的服务指示原语
PH-CONNECT.indication 由 PhL 实体基元生成，用于向服务用户实体指示一个远程设备要求建立物理连接。
PH-CONNECT.confirm 连接建立服务的服务确认原语
PhL 实体用来传递相关联的 PH-CONNECT.request 的结果。如果由于本地错误(例如电话线不可用)而无法建立连接，则是本地生成的。
PH-DATA.request 数据传输服务的服务请求原语
求使用 PhL 传输过程向一个或多个远程 PhL 实体发送数据字节
PH-DATA.indication 数据传输服务的服务指示原语。
向服务用户实体指示有效数据字节的到达
PH-ABORT.request 连接中止服务的服务请求原语
请求原语由服务用户实体 Physical Connection Manager 调用，以请求 PhL 实体终止现有的物理连接
PH-ABORT.confirm 连接中止服务的服务确认原语
PH-ABORT.confirm 原语由 PhL 实体生成，用于向服务用户实体 Physical Connection Manager 确认物理断开尝试的结果
PH-ABORT.indication 连接中止服务的服务指示原语。
原语由 PhL 实体生成，用于通知服务用户实体物理连接已意外终止。

s5.3 Protocol specification

s5.3.1 Physical layer protocol data unit

Physical layer protocol data unit,PHPDU被指定为一个字节。然而，为了传输目的，这个数据字节可能被调制解调器设备扩展(错误检测/校正)或修改(位填充)，这取决于所使用的调制方案。

s5.3.2 Transmission order and characteristics

PHSDU字节——PH-DATA 服务的 Data 参数——在传输前应以一个开始位和一个停止位完成。产生的帧应该从起始位开始传输，首先是最低有效位，最低有效位标识为位 0，最高有效位标识为位 7。

s5.3.3 Physical layer operation – description of the procedures

s5.3.3.1 General

连接的建立和释放由物理连接管理器AP管理。任何希望使用 DLMS/COSEM 协议的AP应在请求连接之前检查PhL的连接状态。如果 PhL 处于非连接状态，它将请求物理连接管理器建立连接

(结合 5.3.3.3 和 5.3.3.4 就是说建立和释放还有识别服务由 AP 来做，这些做完后的数据传输阶段AP 就不管了，通过数据链路层直接调用)

s5.3.3.2 Setting up a physical connection

客户机和服务器设备都可以充当主叫设备，初始化到远程设备(即被叫设备)的物理连接。在这个DLMS/COSEM配置文件中，这些原语的服务用户只能是物理连接管理器进程

在被叫设备端，当检测到物理连接的启动时，需要对连接进行管理：协商、接受或拒绝。这些动作–与执行 PH-CONNECT.request 原语类似–取决于物理连接类型和使用的调制解调器，并可能以自主方式或由PhL本身完成(该过程不需要 Physical connection manager process 参与)。

当主叫和被叫设备的PhL完成建立（或不建立）所需的物理连接时，它们使用PH-CONNECT.confirm（主叫方）和PH-CONNECT.indicat（被叫方）基元将结果通知服务用户实体。

s5.3.3.3 The Identification service

用于客户端读取协议栈识别信息

可选的识别服务是一种应用层面（特别注意，应用层面）的服务。它的目的是让客户获得关于服务器中实现的协议栈的信息。因此，它不使用整个协议栈；识别信息在客户端AP和服务器AP之间使用PhL数据data服务直接交换。如果在多播配置中使用了一个以上的服务器，客户端能够识别每个服务器中的协议栈。

该服务在PH-CONNECT后CONNECTED 状态才能调用

只能由客户端发起请求

IDENTIFY.request 请求识别信息
IDENTIFY.response IDENTIFY.response 消息由服务器AP调用，携带识别请求的结果：
- 协议标准
- 版本
- 修订信息
- 错误信息
在客户端，这是一个 IDENTIFY.confirm 原语。

IDENTIFY.request APDU包含一个或三个字节。为了保持一致性，它的发送应受到数据链路层的时间限制（帧间和响应超时）。

当收到这第一个字符时，PhL 进入 “识别中“状态，等待更多的字节或帧间超时(意味着消息的结束)。

identify识别阶段过程：
如果在收到三个以上的字节之前检测到消息结束条件(超时也算结束标志)，PhL 将收到的 APDU 视为IDENTIFY.request APDU。它使用 PH-DATA.indicaton 原语将收到的字节发送到（物理连接管理器）AP，并返回到 “等待接收“状态，允许解决最终的错误。
跳过 identify识别阶段，直接进入数据传输阶段：
另一方面，如果在收到第四个传入字节之前没有检测到消息结束的条件（因为 IDENTIFY.request 最大就是 3 字节，收到第 4 个字节还没有结束标志，说明就不是 IDENTIFY.request 了，同时要保证正确的数据 PDU 长度是大于 3 字节的），PhL 认为识别过程已经结束，并进入 “数据传输“状态。传入的字节应使用PH-DATA.indicaton服务发送至服务用户的上层协议层。在 3 层的 CO、HDLC 的 COSEM 配置文件中，这是 MAC 子层。在这种连接中，PhL不能返回到识别阶段。

PhL 有参数 Destination_process 表示数据发到哪一层去，默认为 NULL 表示发给物理层管理 AP，进入数据传输模式后为其他值表示发给 MAC 层。

s5.3.3.4 Data transfer

一旦PhL退出识别阶段，它就进入了数据传输阶段，其中PH-DATA.request和PH-DATA.indicative原语完全由上层协议层即数据链路层使用。

在识别阶段AP 是可以通过 PH-DATA 原语向物理层传数据的，进数据传输阶段就不行了

PhL不负责任何数据流控制功能：通过 PH-DATA.request primitive 收到的数据应立即传输，或者–当实施物理数据流控制时–应覆盖之前尚未传输的字节。由于 PH-DATA 服务既不是本地确认，也不是远程确认，因此在后一种情况下，不应发出错误信号。

s5.3.3.5 Disconnection of an existing physical connection

客户端或服务器都可以启动现有物理连接的断开连接。这通过调用 PH-ABORT.request 原语的物理连接管理器 AP 来实现

PH-ABORT.request 的调用者，会收到 PH-ABORT.confirm 作为通知(在本地处理，本地的物理层通知本地的调用 AP（即管理 AP），不外发，断开操作无需通知对方)

对方不会收到任何关于断开的消息，只能通过检测物理连接断开来发现物理通道断开了（如一段时间物理信道无任何数据）。然后物理层生成 PH-ABORT.indication

如果是信道异常导致的断开，双方应该都会收到物理层传来的 PH-ABORT.indication，双方都断开。

s5.4 example: PhL service primitives and Hayes commands

PH-CONNECT:

对于主叫者，physical connection manager AP 向物理层 PhL 发送PH-CONNECT.request，物理层 PhL 向 modem(DCE)发送AT拨号命令，并返回拨号结果，物理层将结果转换为PH-CONNECT.confirm返回给 AP

对于被叫者，AP 会被物理层通知PH-CONNECT.indication表示物理层已连接

PH-DATA:

假设之前建立了与远程 DCE 的连接，并且 DCE 现在处于数据传输模式，那么传递到本地 DCE 的所有数据都将被传输到远程 DCE（不是透明传输，每一层都会对 data 数据做处理，比如添加开始停止位，校验位等）。

PH-ABORT：

在可以终止连接之前，必须首先将调制解调器切换到本地命令模式(从数据传输模式)

s6 Direct Local Connection

本章介绍使用 IEC 62056-21 协议进行本地数据传输(如 hand-held unit (HHU，手持设备) 抄读等)。

注意：DLMS 协议并不强制规定必须使用基于 IEC 62056-21 协议的物理接口，其他如 HDLC、PPP 等协议规定的物理接口也可以使用（比如 PPPoE 使用的以太网规定的双绞线、光纤等）。

s6.2 METERING HDLC protocol using protocol mode E for direct local data exchange

HDLC 协议支持使用 62056-21 规定的 mode E 方式作为其支持层。

s6.3 Physical layer – Introduction

按照第五章描述的物理层模型给出的示例：

PH-CONNECT.request：

一旦使用该连接类型调用了 PH-CONNECT.request 基元，PhL 实体将开始按照上述步骤建立连接。设备地址通过 PhConnType 参数传递。为此，必须指定下层 MAC 地址到设备地址的映射（IEC 62056-21，第 22 项，6.3.14）。请注意，PHCONNECT.request 基元不能由服务器（计费设备）调用。

PH-CONNECT.confirm：

收到来自服务器（计费设备）的 ACK 2 Z 2 CR LF 或其他（例如 NAK）报文后，将生成带有相应结果参数的 PH-CONNECT.confirm 原始信息。

报文：

ACK 2 Z 2 CR LF：计量设备已进入 METERING HDLC 协议模式 E
其他响应：PH-CONNECT.request 失败

PH-CONNECT.indication：

服务器 PH 层确认 METERING HDLC 协议模式 E 后，通过生成 PH-CONNECT.indication 原始信息向 MAC 子层表示。在 HDLC 运行期间，超时等都要遵守 HDLC 规则。

PH-ABORT.request：

PhL 实体中止连接。

注意：BREAK 仅在客户端本地发生，服务器不响应，使用超时。第 8 条定义了 HDLC 的超时。

PH-ABORT.confirm：

由于客户端永远不会收到服务器的响应，因此 PhL 实体必须始终确认 PH-ABORT.request 原始数据。

PH-ABORT.indication：

检测到 BREAK 时，服务器 PhL 实体会将其状态机重置为初始状态，并调用 PH-ABORT.indication 服务来指示连接终止。

s7 DLMS/COSEM transport layer for IP networks

基于 UDP 的无连接传输层;
面向连接的基于 TCP 的传输层;
一个基于无连接 CoAP 的传输层

DLMS/COSEM TL由CoAP、UDP或TCP传输层和一个称为包装器wrapper的额外子层组成

s7.2 The TCP-UDP/IP based transport layers

DLMS/COSEM_on_IP

可以把 DLMS/COSEM AL 视为和 HTTP 一样的网络应用，使用 TCP-UDP 传输层服务

IANA 中注册了 4059/TCP-UDP 端口

DLMS/COSEM AL只监听一个UDP或TCP端口。另一方面，如 4.9 和 DLMS UA 1000-1 所示，一个物理设备可能承载多个客户端或服务器ap。包装器子层提供的附加寻址功能允许寻址这些ap。

包装wrapper子层具有以下功能:

它在 UDP/TCP 端口上提供了一个额外的寻址能力(wPort);
它提供有关数据传输长度的信息。这个特性可以帮助发送方和接收方识别一个完整的APDU的接收，它可以在多个TCP包中发送和接收

TCP-CONNECT and TCP-DISCONNECT services 的用户是 TCP Connection Manager Process，就是说 TCP 连接和释放不是 AL 管理的，由专门的管理进程管的，当然 AL 也要了解 TCP 当前的连接状态。

s7.2.3 The DLMS/COSEM connection-less, UDP-based transport layer

无连接，可实现多播广播；开销小

缺点：不可靠（可以由上层实现可靠，当然 DLMS AL 层不会这么做，但是 CoAP 协议是个例子，基于 UDP 实现了可靠传输），无重复发送保护

.request 和.indication 服务原语是必需的。本地的.confirm 服务原语的实现是可选的。

UDP-DATA.request
(
    Local_wPort,
    Remote_wPort,
    Local_UDP_Port,
    Remote_UDP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Data_Length, Data
)

UDP-DATA.indication
(
    Local_wPort,
    Remote_wPort,
    Local_UDP_Port,
    Remote_UDP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Data_Length,
    Data
)

UDP-DATA.confirm
(
    Local_wPort,
    Remote_wPort,
    Local_UDP_Port,
    Remote_UDP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Result
)

Result参数的值表示基于 DLMS/COSEM UDP 的 TL 是否能够发送请求的 UDP 数据报:能(OK)或不能(NOK)。result 为 OK 只能表示数据已发送，不保证能送达

UDP-DATA.confirm 是可选的

在这个通信配置文件中，包装子层是一个无状态的实体：它的唯一作用是确保使用 wPort 号码的源和目的地 DLMS/COSEM AE 识别，并提供OSI风格的UDP-DATA.xxx服务调用与标准UDP提供的 SEND() 和 RECEIVE() 接口函数之间的转换。

对于 UDP 这种面向数据报而非面向流的协议，包装器中的长度字段并非必要，因为每个 UDP 报文就是完整单一的，不存在分好几包还要拼包拆包处理粘包等操作，但为了和 TCP 兼容还是需要该字段

s7.2.3.3.2 The wrapper protocol data unit (WPDU)

version:始终为 0x0001
source/destination wPort:DLMS/COSEM AE 的端口
Data length:APDU 数据长度

s7.2.4 The DLMS/COSEM connection-oriented, TCP-based transport layer

面向流的，可靠，包括重传、全双工、流控

缺点：端到端，不支持广播和多播

TCP作为一种面向连接的传输协议，涉及到建立连接、交换数据和释放连接三个阶段。因此，基于 TCP 的DLMS/COSEM TL为服务用户提供三个阶段的OSIstyle服务:

在连接建立阶段，将TCP-CONNECT服务提供给服务用户TCP连接管理器进程;
在数据传输阶段，TCP-DATA服务提供给服务用户DLMS/COSEM AL;
在连接关闭阶段，TCP-DISCONNECT服务被提供给服务用户TCP连接管理进程;
此外，一个TCP-ABORT服务被提供给服务用户DLMS/COSEM AL。

TCP连接管理服务的服务用户不是DLMS/COSEM AL，而是TCP连接管理进程。该工艺的规范超出了本技术报告的范围

TCP-DATA可本地或远程确认，UDP-DATA只能本地确认

sTCP-CONNECT

TCP-CONNECT.request
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address
)

TCP-CONNECT.indication
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address
)

TCP-CONNECT.response
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Result
)

TCP-CONNECT.confirm
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Result,
    Reason_of_Failure
)

TCP-CONNECT 由 TCP 连接管理进程和 TCP 层进行交互

TCP 连接管理进程不能拒绝 TCP 连接请求，所以 TCP-CONNECT.response 总是成功的

TCP-CONNECT.confirm 一般来说需要远程确认，如果是本地确认，可能回失败

sTCP-DISCONNECT

TCP-DISCONNECT.request
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address
)

TCP-DISCONNECT.request 用于断开请求

TCP-DISCONNECT.indication
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Reason
)

TCP-DISCONNECT.indication 中Reason参数:

对端设备请求了 TCP 断开(Reason == REMOTE_REQ)
本地检测到 TCP 连接断开(Reason == ABORT)

TCP-DISCONNECT.response
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Result
)

TCP 连接管理进程不能拒绝TCP 断开请求，表示远程断开 Reason == REMOTE_REQ

TCP-DISCONNECT.confirm
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Result,
    Reason_of_Failure
)

同 TCP-CONNECT.confirm

sTCP-ABORT

见 7.2 图 27，TCP-ABORT 是AL层和TL层交互的原语

TCP-ABORT.indication
(
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Reason
)

由基于 DLMS/COSEM TCP 的TL生成，用于向服务用户DLMS/COSEM AL表示支持 TCP 连接的非请求中断。

当收到此指示时，DLMS/COSEM AL应释放所有使用此 TCP 连接建立的AAs，并应使用 COSEM-ABORT.indivation服务原语向 COSEM AP 表明这一点。

sTCP-DATA

TCP-DATA.request
(
    Local_wPort,
    Remote_wPort,
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Data_Length,
    Data
)

Data 是 APDU

TCP-DATA.indication (
    Local_wPort,
    Remote_wPort,
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Data_Length,
    Data
)

TCP-DATA.indication 基元由 DLMS/COSEM TL生成，用于向服务用户 DLMS/COSEM AL指示已从远程设备收到 xDLMS APDU。如果携带 APDU 的 TCP 数据包中的 Local_TCP_Port 和 Local_wPort 参数都包含有效的端口号，即接收设备中存在一个与给定端口号绑定的 DLMS/COSEM AE，则在基于 DLMS/COSEM TCP 的 TL接收完整的APDU（在一个或多个TCP 数据包中）后生成。否则，收到的消息将被直接丢弃。

TCP-DATA.indication 需要在接收完完整包并解包后交给 AL,Data 是 APDU

TCP-DATA.confirm
(
    Local_wPort,
    Remote_wPort,
    Local_TCP_Port,
    Remote_TCP_Port,
    Local_IP_Address,
    Remote_IP_Address,
    Confirmation_Type,
    Result
)

可选的，request 的确认

s7.2.4.3 Protocol specification for the DLMS/COSEM TCP-based transport layer

wrapper 层和 UDP 的不同，因为 TCP 是流式的，需要发送/接收全 APDU，还要处理粘包等

s7.2.4.3.5 Definition of the procedures

wrapper 层透传TCP 连接管理器 AP和TCP 层之间的调用。

TODO:该设计是否合理，wrapper 层又多做了判断操作，直接管理 TCP 层是否更合理

TCP connection

为了能够响应，响应方必须在接收第一个 SYN 包之前执行一个“被动”打开。为此，它必须联系本地操作系统(OS)，以表明它已经准备好接受传入的连接请求。作为这个联系的结果，操作系统分配一个TCP端口号给连接的端点(开启 TCP端口监听)，并为将来的连接保留所需的资源——但是没有发送消息。

TCP disconnection

客户端和服务端TCP连接管理器进程可以通过调用TCP-DISCONNECT.request来启动该过程。

TCP connection abort

基于 DLMS/COSEM TCP 的 TL 在 TCP-ABORT.indication 原语的帮助下指示支持 TCP 连接到 DLMS/COSEM AL 的中断或断开。请注意，这是提供给 DLMS/COSEM AL 的唯一 TCP 连接管理服务(其他服务都是提供给 TCP 连接管理进程的)。

当 TCP 连接被 TCP 连接管理器进程断开时调用该服务（优雅断开的情况），或者当 TCP 断开以非请求方式发生时，例如 TCP 子层检测到不可解决的错误或 物理连接被关闭。

TODO:前文 TCP-ABORT 一节提到 TCP-ABORT 不是非请求中断才生成吗?为什么请求中断也会生成

该服务的目的是通知 DLMS/COSEM AL TCP 连接中断，以便它可以释放所有现有的 AA。

Data transfer using the TCP-DATA service

可选TCP-DATA.confirm原语表示 TCP-DATA结果。请求原语之前调用，这是 OK 或 NOK。然而，这个结果的含义取决于实现。当.confirm 原语被实现为本地确认时，结果 t 表示 DLMS/COSEM TL 是否能够缓冲发送APDU 或发送APDU。当它作为远程确认实现时，结果表明 APDU 是否已成功交付到目的地。

WPDU 由 wrapper 层打包组包解包，TCP 是流式的，不关心字节范围，WPDU 可能被分为好几个 TCP 包发送

s7.2.5 Converting OSI-style TL services to and from RFC-style TCP function calls

s7.2.5.1 Transport layer and TCP connection establishment

s7.2.5.2 Closing a transport layer and a TCP connection

s7.2.5.3 TCP connection abort

通过 TCP Wrapper 层轮询 TCP 层状态

s7.2.5.4 Data transfer using the TCP-DATA service

AL层通过 request 原语发送一个992字节的APDU，Wrapper层加上8字节的头，第一次发送1000字节，实际一包发出去 476 字节，还剩 524 字节，以此类推直到发完，向 AL 层回复 confirm 原语。该过程由 Wrapper 层控制。

Wrapper 层接收到完整的 wrapper 头+APDU 后，解开 wrapper 头，将 APDU 放在TCP-DATA.ind原语中发送给 AL 层。

s7.3 The DLMS/COSEM CoAP based transport layer

s7.3.2 Overview

受限应用协议 (Constrained Application Protocol,CoAP) 是由 IETF 核心工作组定义的专用互联网应用协议。 CoAP 专为在资源受限的设备中使用而设计，用于通过非受限或受限的互联网通信网络（例如，低功耗、有损网络）进行通信。 CoAP 旨在提供高效的数据传输能力，同时满足可靠性、多播支持、极低开销、效率和简单性等特殊要求。

基于 CoAP 的DLMS/COSEM CoAP TL提供不可靠和可靠的传输服务(CoAP 原来是属于应用层的，这里 DLMS 协议里把它做成了传输层，用来给 AL 提供服务)。不可靠的 CoAP 服务支持组播和广播。DLMS/COSEM CoAP TL 为服务用户 DLMS/COSEM AL 提供OSI风格的服务。

整个DLMS/COSEM CoAP TL层包括了 Wrapper 层、CoAP 层、UDP 层，和标准 OSI 模型中的不同

s7.3.3 Structure of the DLMS/COSEM CoAP transport layer

DLMS/COSEM CoAP TL提供不可靠和可靠的运输服务。

不可靠的 DLMS/COSEM CoAP 传输服务使用non-confirmable (NON) CoAP 消息
可靠的 DLMS/COSEM CoAP TL 服务使用confirmable (CON) CoAP 消息，并带有 CoAP 消息层提供的重试机制。

CoAP wrapper层提供的服务：

通过与CoAP请求/响应层操作的交互，将OSI风格的数据服务原语(CoAP-DATA)传递给DLMS/COSEM AL，以实现CoAP POST方法的使用
DLMS/COSEM服务接入点SAP寻址功能，从而允许多个DLMS/COSEM AEs驻留在物理设备的同一个 CoAP 客户机和服务器端点上

s7.3.3.2 Identification and addressing

识别与寻址

默认 5683 端口，同一个物理机里的客户端和服务端可以共用该端口

TODO: 结合 Bluebook 4.9 关于 CoAP 配置的对象

s7.3.3.2.2 DLMS/COSEM AL identification within the CoAP transport layer

一个 CoAP 端口可以为不同的应用（如除了 DLMS 的应用）提供服务，用URIPath区分(CoAP 类似于 HTTP，可以通过 URI 区分接入点)，IANA 规定的默认端口为 5683

默认情况下，DLMS/COSEM AL，无论是 DLMS 客户端 AL 还是 DLMS 服务器 AL，都使用该URI-Path: “dlms”

coap://127.0.0.1:5683/dlms

sDLMS/COSEM CoAP transport layer SAPs

s7.3.4 Service specification for the DLMS/COSEM CoAP transport layer

远程环回确认(积极（传输成功的情况）的 TL 确认，用于可靠传输)，表示报文被远端确认，确认发送给本地 CoAP client，再由本地wrapper层返回给 AL 层 confirm 原语

本地环回确认(消极（失败的情况，比如发生了什么错误）的 TL 确认，用于可靠和不可靠传输，可靠传输中可能是对方超时没回确认，视为失败，不可靠传输中可能是 udp 层有错误导致调用发送函数失败，视为失败)，用于失败的情况，由本地CoAP client返回给 wrapper 层错误信息，本地wrapper层返回给 AL 层 confirm 原语

s7.3.4.2 The DLMS/COSEM CoAP-DATA service primitives

s7.3.4.2.1 CoAP-DATA.request

CoAP-DATA.request
(
    Transport_Mode,
    Local_SAP,
    Remote_SAP,
    Local_IP_address [Optional Use],
    Local_Port [Optional Use],
    Remote_IP_address,
    Remote_Port,
    Remote_Path [Optional Use],
    Response_Mode,
    Request_ID [Optional Use],
    Data_Length,
    Data
)

Transport_Mode: CoAP 传输模式，“RELIABLE”可靠，“UNRELIABLE”不可靠（这里的可靠其实是对于整个DLMS/COSEM传输层来说的，首先由 wrapper 层负责，当然底层还是需要 CoAP 可靠或不可靠模式的支持）,见7.3.5.6。对于CoAP协议提供的不可靠传输模式主要还是在广播的时候用的
Remote_Path： CoAP Uri-Path。Response_Mode 为“RESPONSE”忽略该参数
Response_Mode：表示是否期望返回 DLMS/COSEM 响应 APDU。影响CWPDU中的WRM。它取值:”CONFIRMED“， “UNCONFIRMED“， “RESPONSE“。
Request_ID：标识了特定的数据请求操作。Request_ID 将在可能产生的CoAP-DATA.confirm原语中返回，表明 DLMS/COSEM CoAP TL传送数据参数中给出的 APDU 的成功或失败。见7.3.5.6Request_ID 被指定为支持在已发送多个携带请求的 APDU 且 DLMS/COSEM CoAP TL 确认尚未完成的情况下，以每个APDU 为基础返回 DLMS/COSEM CoAP TL确认(类似于 TCP 的滑动窗口，可以异步确认)。以下情况适用:
- 如果 Request_ID 未被指定，CoAP-DATA.confirm 原语中 Request_ID 也不被指定。
- 如果 Transport_Mode 被设置为UNRELIABLE，并且 DLMS/COSEM CoAP TL 实现不支持这种操作模式的 CoAP-DATA.confirm 原语，那么 Request_ID 可以不被指定。
- 如果 DLMS/COSEM CoAP TL 服务不支持CoAP-DATA.confirm原语，CoAP wrapper 将忽略指定的 Request_ID 标识。

使用场景：

发送DLMS/COSEM请求（单播或多播广播）：
- Remote_Path指定为对方 Uri-Path
- Local_Port and Local_IP_address可选
- Response_Mode：
  - 需确认的请求，使用CONFIRMED
  - 无需确认的请求，使用UNCONFIRMED
  - General Block Transfer(GBT)分块传输的请求,视情况，比如单播或广播，可用CONFIRMED或UNCONFIRMED
发送DLMS/COSEM响应（也为 CoAP-DATA.request，只要是发送就是request，和 AL 层的报文类型无关）：
- Remote_Path不指定
- Local_Port and Local_IP_address需要指定，和请求匹配
- Transport_mode, Local_SAP, Remote_SAP, Remote_IP_address, Remote_Port 需匹配请求
- Response_Mode：
  - 一般为RESPONSE
  - APDU 为 GBT 时，为CONFIRMED，Remote_Path 需指定
    TODO:这不是和上面说的不指定矛盾了吗

s7.3.4.2.2 CoAP-DATA.indication

CoAP-DATA.indication
(
    Transport_Mode,
    Local_SAP,
    Remote_SAP,
    Local_IP_address,
    Local_Port,
    Remote_IP_address,
    Remote_Port,
    Data_Length,
    Data
)

Transport_Mode: CoAP 传输模式，“RELIABLE”可靠，“UNRELIABLE”不可靠

s7.3.4.2.2 CoAP-DATA.confirm

CoAP-DATA.confirm
(
    Local_SAP,
    Remote_SAP,
    Local_IP_address [Optional Use],
    Local_Port [Optional Use],
    Remote_IP_address,
    Remote_Port,
    Request_ID [Optional Use],
    Result
)

Local_SAP：本地 DLMS/COSEM AE 的 SAP
Request_ID：对应的 CoAP-DATA.request 中携带的，如果 request 没有指定就是未定义
Result：“REMOTE OK”表示远端已接收，“NOT OK”表示发送失败

使用场景：

CoAP-DATA.confirm 由 wrapper 层生成

对于不可靠的传输模式，Result 没有“REMOTE OK”远程确认，但可以生成“NOT OK”表示本地错误，对不可靠传输模式该原语是可选的

s7.3.5 Protocol specification of the DLMS/COSEM CoAP transport layer

s7.3.5.2 The DLMS/COSEM CoAP TL Protocol Data Unit (CoAP-PDU)

CoAP-PDU = UDP header + CoAP header + CWPDU(wrapper header + APDU)

DLMS/COSEM CoAP TL PDU是一个UDP数据报，携带CoAP消息作为其有效载荷。该 CoAP 消息携带CoAP头和 DLMS/COSEM CoAP Wrapper PDU（CWPDU）。CWPDU 携带 DLMS/COSEM APDU作为其有效载荷加上 DLMS/COSEM CoAP TL控制信息，。

s7.3.5.3 The DLMS/COSEM CoAP Wrapper Protocol Data Unit (CWPDU)

CWPDU = wrapper header + APDU

DLMS/COSEM CoAP 包装协议数据单元(CWPDU)由一个可选的DLMS/COSEM CoAP wrapper头和它的有效负载APDU组成。

CoAP请求中 CWPDU才包含DLMS/COSEM CoAP wrapper报头。

CoAP响应中 CWPDU不包含DLMS/COSEM CoAP wrapper头，

不同于 TCP 或 UDP，CoAP 是请求响应模型的，所以请求和回应在 DLMS 的 TL 层也是一一对应的（通过 Token 匹配），客户端完全可以知道回应的 wrapper 头中的SAP应该是什么。所以响应中的 wrapper 头可以省略

CoAP 不是流式传输，报文也是完整的，不需要长度信息

The DLMS/COSEM CoAP TL version：TL 版本号，0-15，目前为 0
Reserved bits：保留
The CoAP Wrapper Response Mode (WRM)：通知对方的 wrapper 层是否应该期望收到对方的 AL 层响应，(为 1 时，服务端 wrapper 层就知道不需要等待服务端 AL 层响应，客户端 AL 也不会收到传输层给它的确认，但当启用了传输层可靠传输时，传输层自己要保证发送成功，包括超时重发和失败重发)，见 7.3.5.6
Remote SAP：接收站点的 SAP
Local SAP：发送站点的 SAP

s7.3.5.4 The Constrained Application Protocol (CoAP)

s7.3.5.4.2 The CoAP Message

CoAP 消息以简单的二进制格式编码。消息由一个固定大小的4字节头、一个可变长度的Token值(0-8 字节)、0个或多个tlv编码的选项(可选地)和负载组成。

一个非空的CWPDU作为有效负载在 CoAP 消息中携带。

本节其实就是介绍标准 coap 协议，可以看其他文章，见CoAP 学习笔记（1）CoAP 报文结构

DLMS/COSEM CoAP TL 层只用到了其中的一部分的 code

CoAP Request method codes
在DLMS/COSEM CoAP TL的CoAP消息中使用的请求方法代码如下
Request method Meaning Use
0.02 POST method 发送新的包含 CWPDU 的请求或响应
0.00 空报文 ACK message without piggybacked response 在可靠传输中用于ACKs确认，不带响应
CoAP Success Response codes
Success Response code Meaning Use
2.04 Success (Changed) 对已存在的请求/响应回复包含 CWPDU 的响应

Request	method	Meaning Use
0.02	POST method	发送`新的`包含 CWPDU 的`请求或响应`
0.00	空报文 ACK message without piggybacked response	在可靠传输中用于`ACKs`确认，不带响应

Success Response code	Meaning	Use
2.04	Success (Changed)	对`已存在`的请求/响应回复包含 CWPDU 的`响应`

三种响应模式见上述文章

客户端错误和服务器错误响应代码由CoAP协议层或CoAP包装器根据错误条件填充

Token(可选，TKL 指定是否存在)
令牌用于配置响应和请求
Token Length(TKL 指定)
建议 DLMS/COSEM CoAP TL 实施的 CoAP 请求/响应层使用的令牌长度限制为0-4字节，以平衡令牌传输成本和上下文不匹配的风险，或者当令牌在相同的 CoAP 端点之间重复使用时可能出现的重复检测失败。进一步参考 RFC 7252。
DLMS 服务器的 DLMS/COSEM CoAP TL 的 CoAP 协议层使用的 Token 长度可在CoAP设置对象中指定，见 DLMS UA 1000-1 Part 2 Ed.15:2021, 4.9.8。
Options
Options 也只用到了标准中的一部分,当然没有规定只能用这些，但要保证双方能处理这些选项
- Uri-Path: CoAP uri 路径，默认是 dlms
- Content-Format：允许的传输格式，和 HTTP 类似，可以不指定，因为默认都是application/octet-stream
- Block1 and Block2：在 RFC 7959 中新增的两个 option，用于表示分块传输，见 7.3.5.4.5，另见CoAP 分块传输

s7.3.5.4.3 CoAP retransmission and response piggybacking

当 CWPDU 在可靠的 CoAP 消息层支持的新 CoAP 请求/响应上下文中传输时（即通过可确认的（CON）CoAP 消息），那么，正如 RFC 7252 所规定的，CoAP 消息层将继续重传CoAP 请求消息，直到它被 CoAP 服务器终端确认。这可以是单独的CoAP确认消息ACK的返回形式，也可以是附带CWPDU 或错误响应的piggybacked ACK消息

关于piggybacking 技术：
在双向通信中，每当收到帧时，接收方都会等待，并且不会立即将控制帧（确认或ACK）发送回发送方。
接收方等待，直到其网络层传入下一个数据包。然后，延迟的确认将附加到此传出数据帧。
这种暂时延迟确认以便可以与下一个传出数据帧挂钩的技术称为piggybacking。
优点：提高效率，更好地利用可用信道带宽。
缺点：如果 接收方没有要发送 的内容，则接收器可能会阻塞服务。这可以通过在接收到数据帧时启用计数器（接收器超时）来解决。如果计数结束并且没有要发送的数据帧，则接收方将发送 ACK 控制帧。发送方还会添加一个计数器（发送器超时），如果计数器在没有收到确认的情况下结束，则发送方将假定数据包丢失，然后再次发送帧。
该技术主要是为了减轻网络负担,这个附带内容可以是接收器对于上一帧的回复（如果处理快的话也可以是本次请求的回复），也可以是主动上报等

CoAP 层会考虑使用piggybacking的可能性，ACK会延时发送，直到本地 wrapper 层收到 AL 层的数据并打包成 CWPDU 或超时，再发送附带或不附带数据的ACK。要是超时的话这个 CWPDU 单独发送，不附带在这个 ACK 中

7.3.5.4.3.2 CoAP Retransmission Parameters

DLMS/COSEM CoAP TL 中的可靠 CoAP 消息传递层使用许多参数来控制 RFC 7252 定义的 CoAP 重传算法。这些参数在 CoAP setup interface class 类中指定

ack_timeout
需确认消息的最小初始 ACK 超时
initial_ack_timeout是在ack_timeout和ack_timeout x ack_random_factor之间随机选择的值。
initial_ack_timeout是可靠的 CoAP 消息层的初始重传延迟。
ack_random_factor
用于申请初始 ACK 超时随机性的随机因子。
max_retransmit
需确认消息的最大重传次数。
delay_ack_timeout
CoAP 消息传递层在返回确认之前等待应用层返回响应的时间（以毫秒为单位），piggybacking 相关的，防止太久不回 ACK 触发对方重传
7.3.5.4.3.3 CoAP Congestion Control Parameters

拥塞控制

NSTART
以下任一形式的同时未完成的 CoAP 请求消息的数量：
- 没收到 ACK 的 CON 消息(需确认消息)
- 没收到响应的 NON 消息(无需确认消息)
PROBING_RATE
探测速率
定义一个端点发送到另一个没有响应的端点时不应超过的平均数据速率(字节/秒)。

s7.3.5.4.5 CoAP Block Transfer

见 7.3.5.4.2

第 31 篇：CoAP 分块传输

在 APDU 大于 MTU，且小于 receiver_max_pdu_size 时生效（大于 receiver_max_pdu_size 本身就不合法，AL 或 TL 应该屏蔽该报文）

TODO:为什么是 APDU 大于 MTU，MTU 不是链路层的限制吗，就算要分也是加上 IP 头，UDP 头和 CoAP 头，wrapper 头后的 APDU 的长度作为基准吧

DLMS/COSEM CoAP TL 中的 CoAP 块传输层应按照RFC 7959的建议，在没有不当延迟的情况下完成 CoAP 块传输

s7.3.5.5 Error Handling

s7.3.5.5.2 CoAP protocol layers

CoAP消息层或请求/响应层的错误通过重置消息(名词)或 CoAP 协议层实体根据 RFC 7252 和 RFC 7959自动生成的 CoAP 客户端和服务器错误响应传递给发送的 CoAP 实体

s7.3.5.5.3 CoAP wrapper layer

wrapper层的错误处理，就是从一个 wrapper 层发给另一个 wrapper 层

Unreliable CoAP transport 不可靠传输
一般是多播，在多播情况下 wrapper 将接收到的不能处理的 CWPDU丢弃
TODO:wrapper 层是不是通过 CWPDU 中的客户端 SAP 参数知道是否是多播的更新：有可能，或者是CoAP协议会带这个原语参数通知wrapper层是否是广播多播。然后其实这个丢弃和多播无关，不是多播也会丢弃。因为是不可靠传输，所以不需要 wrapper 层回确认（空报文）或否认
Reliable CoAP transport 可靠传输
接收端 wrapper 层无法处理接收到的 CWPDU(由 CoAP request 携带)时返回错误
这种错误响应可能有助于诊断，也可能有助于主动纠正措施。通常，当传入的请求由于语法错误而无法提供服务时，将返回CoAP客户端错误(类似 HTTP 状态码里的 4xx 表示客户端错误，5xx 表示服务器错误，HTTP 状态码)，而当 CoAP 包装器无法处理明显有效的请求时，将返回CoAP服务器错误

s7.3.5.5.4 Propagation of errors through CoAP wrapper layer

返回到发送端 CoAP 协议层的错误响应应该以所产生的CoAP消息层交付失败（见下）的形式传播到发送端CoAP wrapper层，或者以返回的错误本身的直接形式传播，无论它们是由接收CoAP协议层还是由接收CoAP包装器层产生的。

CoAP 消息层交付失败原因：
- 接收到重置消息
- 放弃 CoAP block transfer 操作
- 可靠 CoAP 消息传递层放弃可靠传输的 CoAP 消息
- CoAP 层错误或 UDP 或 IP 层错误

如果是可靠传输，CWPDU 的交付失败必须从 CoAP 协议层传播到 wrapper 层，以便其酌情通知 AL 层。

s7.3.5.6 DLMS/COSEM CoAP TL confirmations

CoAP包装器请求/响应上下文（见 7.3.5.7）对于在本地发起的 CoAP 请求/响应上下文中传送的任何未完成的 CWPDU（还没有收到 CoAP 响应）保持给定Request_ID的状态，以便 wrapper 层在返回负面（比如有错误发生）或正面（比如传输成功）的 DLMS/COSEM CoAP TL 确认时可以用 CoAP-DATA.confirm 原语向 AL 层返回 Request_ID。

对于不可靠的 DLMS/COSEM CoAP TL，这个是可选的，也就是无需维护维护Request_ID的状态。也只能回复负面的确认（无需正面确认，因为不可靠就是无确认的）

CoAP 传输层错误指示
如果CoAP 包装器从 CoAP 协议层收到在本地发起的 CoAP 请求/响应上下文中传输的 CWPDU 的交付失败指示，则CoAP包装器通过 CoAP-DATA.confirm 原语（结果为 “NOT OK“）和与 CoAP-DATA.request 原语中的 APDU 提供的 Request_ID 相匹配的Request_ID来传达相关 APDU 的交付失败。参见 7.3.5.7.5。
CoAP 传输层确认
支持 DLMS/COSEM CoAP TL 确认，如果接收端的 AL 层不会对这条报文回确认，那这个确认可以由接收端传输层自己生成并回复(AL 层面无需响应，也就不会回响应，但传输层可靠传输层面需要确认)。使用带有 push_operation_method (1) 的无需确认 DataNotification 的可靠数据推送操作需要 DLMS/COSEM CoAP TL 确认。参见 DLMS UA 1000-1 第 2 部分 Ed.15:2021, 4.4.8.2.2.11，就是蓝皮书中的 push_operation_method 为 1 这种情况，需要传输层确认，而无需 AL 层确认，当然确认结果也不用给 AL 层，重发也是传输层自己负责
CoAP 包装层支持 DLMS/COSEM CoAP TL 确认，用于在 CoAPDATA.request 原语中以 Response_Mode = UNCONFIRMED 和 Transport_Mode = RELIABLE 提供的 APDU。(服务端 AL 层无需响应，客户端 AL 也不会收到传输层给它的确认，但传输层自己要保证发送成功，包括超时重发和失败重发。
注意，CoAP 层只会在未收到 ACK 时重发，对于 wrapper 层 CWPDU 未收到的情况需要 wrapper 层自己重发
TODO:可靠传输不是靠 CoAP 的 ACK 吗，为什么还要单独再搞个 wrapper 层的确认更新：DLMS/COSEM TL 层的可靠传输，属于整一层的，CoAP 的 ACK 也是 wrapper 层用于判断传输成功的一种依据。比如还有明明收到了 ACK 但没收到对方 wrapper 层的响应，就要由 wrapper 层自己重发，来保证可靠传输
过程：
1. 在 Response_Mode = UNCONFIRMED 的 CoAP-DATA.request 原语中提供给 CoAP 包装器的 APDU 应由 CoAP 包装器在 CoAP 包装器响应模式(WRM)设置为 1 的 CWPDU 中的新本地发起 CoAP 请求/响应上下文中传输（WRM = 1)（WRM 见 7.3.5.2，关于 CWPDU 的定义）。这指示接收 CoAP 包装器不要等待返回 DLMS AL 响应或 DLMS AP 响应；
2. 接收 CoAP 包装器应在将接收到的嵌入的 APDU 成功交付给 DLMS AL 时，当通过可靠 CoAP 消息传递层在 WRM = 1 的 CWPDU 中接收到 APDU 时，返回一个空的 CWPDU 作为对发送 CoAP 包装器的成功响应实体
3. 对于 WRM = 1 接收到的 CWPDU 的错误处理遵循上面描述的一般错误处理

s7.3.5.7 CoAP wrapper state machine

wrapper 层状态机

空闲Idle：关闭状态，没有关联状态，CoAP 请求/响应层中没有相应的 CoAP 请求/响应上下文
客户端等待模式Client Waiting Mode：接收到 AL 层传来的 CoAP-DATA.req，直到把该 req 处理完,包括等待结果，进入 Idle 模式。
服务器等待模式Server Waiting Mode：接收 CoAP 层传来的非空且需 AL 层回复（WRM=0）消息，发给 AL 层后，等待AL 层回复 CoAP-DATA.req 消息
服务Serving：接收到 CoAP 层传来的非空且无需 AL 层回复(WRM=1)消息，发给 AL 层后直接结束，进入 Idle

s7.3.5.7.2 CoAP DLMS/COSEM wrapper request/response context

在客户端等待模式状态下维护的参数取自 CoAP-DATA.request 服务原语的服务参数(AL 层发来的)

在服务器等待模式和服务状态下维护的参数取自较低的 CoAP 协议层和传入 CWPDU 的 CWPDU 标头(远端客户端发来的)

空闲到客户端等待模式
- 收到 AL 层 CoAP-DATA.request 调用，且 Response_Mode = UNCONFIRMED（UNCONFIRMED无需回应，不可能是回应，只能是请求），CWPDU中的WRM置1
- 收到 AL 层 CoAP-DATA.request 调用，且 Response_Mode = CONFIRMED，且是个请求（没找到对应请求，说明不是回应）
- 收到 AL 层 CoAP-DATA.request 调用，且 Response_Mode = RESPONSE，且是个请求（没找到对应请求，说明不是回应），和GBT相关
空闲到服务器等待模式
收到 CoAP 层传来的非空且需AL层回复（WRM=0）消息，发给 AL 层后，等待AL 层回复 CoAP-DATA.req 消息
服务器等待模式到空闲状态：
在服务器等待模式下收到 AL 层传来的CoAP-DATA.request原语，且该原语中的 Transport_Mode, the Local SAP, the Remote SAP, the Local_IP_address, the Local_port, the Remote_IP_address and the Remote_Port参数与当前wrapper层上下文中的对应
- 收到 AL 层 CoAP-DATA.request 调用，且 Response_Mode = RESPONSE，且是个回应（找的到对应的请求）
- 收到 AL 层 CoAP-DATA.request 调用，且 Response_Mode = CONFIRMED，且是个回应（找的到对应的请求）（GBT 相关）
客户端等待模式到空闲状态
- 收到 CoAP 层失败信息
- 收空(确认)或非空(响应)CWPDU
然后根据情况处理后回给 AL 层
空闲状态到服务状态
接收到 CoAP 层传来的非空且无需 AL 层回复(WRM=1)消息，发给 AL 层后直接结束，进入 Idle（可能还要回个空 CWPDU 给对方 wrapper 层表示确认）

s7.3.5.7.4 CoAP-DATA.request invocation handling

s7.3.5.7.5 Handling of incoming CWPDU or CoAP layer transmission failures

s7.3.5.7.6 Garbage collection

CoAP 相关的缓存清理，和实现相关。

s7.3.6 DLMS/COSEM CoAP TL Data Transfers

s7.3.6.2 General transfer of confirmed DLMS/COSEM AL service requests

s7.3.6.3 Reliable DLMS/COSEM CoAP TL operation

Piggybacked 模式下，ACK 和 response 同时回复，由客户端掌握重发权，没收到 ACK 就重发

separate 模式下，ACK 先发，response 后发，在响应阶段服务端掌握重发权，如果 response 没收到对方 ACK 则重发

TODO:如果是服务端发给客户端的 ACK 丢了呢更新：客户端没收到ACK重发请求

s7.3.6.4 Unreliable DLMS/COSEM CoAP TL operation

s7.3.6.5 DLMS/COSEM CoAP Block Transfer operation

CoAP 块传输，用于 APDU 大于 MTU 但小于 receiver_max_pdu_size 的情况，主要是用于让 IP 层无需再分片，属于 CoAP 标准中的一部分。

对于 UNRELIABLE 服务，图 58 中的 Transport_Mode 替换为UNRELIABLE，CoAP type 替换为NON

s7.3.6.6 DLMS GBT operation over DLMS/COSEM CoAP TL

DLMS GBT 分块，区别于 CoAP 块传输，属于 DLMS/COSEM AL 层实现的分块传输，在某些方面优于 CoAP 块传输。

TODO:FIRST-PART 是不是就只是用来交换 GBT 参数的，此时直接发出去应该 data 是个空的也行更新：22年5月26日已经讨论，这确实是用来请求GBT参数的，这种情况发生在所有GBT参数由AP层管理的情况下。照理说如果AL可以管理这个参数，AL可以不向AP层申请。9.4.6.13.3中Table 96写明了AL有默认参数，而且需要AP提供一个参数用于更新该默认值，也就是官方建议使用AL向AP请求参数的方式。如果AL和AP层合并也可以避免该问题。

TODO:后面是有关GBT的部分

s8 Data Link Layer using the HDLC protocol

s8.1 Overview

本章指定数据链路层为三层，面向连接，基于HDLC，异步通信配置文件。

本规范支持以下通信环境:

点对点和点对多点配置
专用和交换数据传输设施
半双工和全双工连接
异步启动/停止传输，1 个启动位，8 个数据位，无奇偶校验，1 个停止位

s8.1.2 Structure of the data link layer

为了确保面向连接和无连接两种操作模式都有一致的数据链路层服务规范，数据链路层被划分为两个子层:逻辑链路控制(LLC)子层和媒体访问控制(MAC)子层

LLC 层

类型 1：无连接。该方式对信息的发送通常无法保证接收。
类型 2：面向连接。该方式提供了四种服务：连接的建立、确认和承认响应、差错恢复（通过请求重发接收到的错误数据实现）以及滑动窗口（系数：128）。通过改变滑动窗口可以提高数据传输速率。
类型 3：无连接承认响应服务。

类型1的 LLC 无连接服务中规定了一种静态帧格式，并支持运行网络协议。有关传输层网络协议通常是使用服务类型 1 方式。

类型2的 LLC 面向连接服务支持可靠数据传输，运用于不需要调用网络层和传输层协议的局域网环境。(相当于把 TCP 层的事情干了)

MAC 子层（该数据链路层规范的主要部分）基于 ISO/IEC 13239。与原始 HDLC 标准相比，该标准的第二版包括许多增强功能，例如在寻址、错误保护和分段。 第三版采用了一种新的帧格式，可满足电表和类似行业遥测应用中的环境要求。

MAC 子层的主要功能包括数据帧的封装/卸装，帧的寻址和识别，帧的接收与发送，链路的管理，帧的差错控制等。MAC 子层的存在屏蔽了不同物理链路种类的差异性;非常重要的一项功能是仲裁介质的使用权，即规定站点何时可以使用通信介质。实际上，局域网技术中是采用具有冲突检测的载波侦听多路访问（Carrier Sense Multiple Access / Collision Detection，CSMA/CD）这种介质访问方法的。

为本技术报告的目的，已从 HDLC 标准中做出以下选择：

不平衡连接模式数据链路操作(unbalanced connection-mode data link operation)（可能就是主从模型）
由于 DLMS/COSEM 协议属于客户端-服务端(C/S)模型，所以理所应当的选用该主从模型
双向交替数据传输(two-way alternate data transfer, TWA)；（发送权概念，一方发完才交出发送权，只有拥有发送权的一方才能发送）
所选 HDLC 程序模式为 UNC - 非平衡正常响应模式(Normal response mode, NRM)模式 - 使用 UI 帧扩展；
frame format type 3;
非基本帧格式透明度(non-basic frame format transparency)

HDLC的三种操作方式：

正常响应方式 NRM

正常响应方式NRM（Normal Response Mode）一种非平衡数据链路操作方式，有时也称为非平衡正常响应方式。该操作方式使用于面向终端的点到点或一点到多点的链路。在这种操作方式下，传输过程由主节点启动，从节点只有收到主节点某个命令帧后，才能作为响应向主节点传输信息。响应信息可以由一个或多个帧组成，若信息由多个帧组成，则应指出哪一帧是最后一帧。主节点负责管理整个链路，且具有轮询、选择从节点及及向从节点发送命令的权利，同时也负责对超时、重发及各类恢复操作的控制。

本文使用 UI 帧框架扩展了 UNC 类过程的基本命令和响应库，以支持多播和广播以及从服务器到客户端的非请求信息传输。

使用非平衡连接模式数据链路操作意味着客户端和服务器端数据链路层在 HDLC 帧集及其状态机方面是不同的（意思就是客户端和服务端的链路层实现不同）。

异步响应方式 ARM

异步响应方式 ARM（Asynchronous Response Mode）也是一种非平衡数据链路操作方式，与 NRM 不同的是，ARM 下的传输过程由从节点启动。从节点主动发送给主节点的一个或一组帧中可包含有信息，也可以是仅以控制为目的而发的帧。在这种操作方式下，由从节点来控制超时和重发。该方式对采用轮询方式的多节点点链路来说是必不可少的。

异步平衡方式 ABM

异步平衡方式 ABM（Asynchronous Balanced Mode）是一种允许任何节点来启动传输的操作方式。为了提高链路传输效率，节点之间在两个方向上都需要有较高的信息传输量。在这种操作方式下，任何时候任何节点都能启动传输操作，每个节点点即可以作为主节点又可以作为从节点，即每个节点都是组合节点。各个节点都有相同的一组协议，任何节点都可以发送或接受命令，也可以给出应答，并且各节点对差错恢复过程都负有相同的责任。

s8.1.3 Specification method

数据链路层的子层根据服务和协议(services and protocols)进行划分

层间交互原语参数类型：

传输至对端对等层的参数，包含在帧报文中，如地址、控制信息
局部使用的参数
透明传输的参数，收到后本层不处理，直接给下一层

s8.2 Service specification

本节规定了服务用户层使用面向连接的程序对数据链路层要求的服务。

事实上，所有 DL 服务都由 MAC 子层提供：LLC 子层将 DL-CONNECT.xxx 服务原语作为适当的 MA-CONNECT.xxx 服务原语透明地传输到“真实”服务提供者 MAC 子层或从“真实”服务提供者 MAC 子层接收。

由于客户端和服务器端 LLC 和 MAC 子层不同，因此为双方指定了服务原语。

MAC 子层的寻址方案在 8.4.2 中规定。

s8.2.2 Setting up the data link connection: the DL-CONNECT and MA-CONNECT services

数据链路连接的建立只能由客户端请求。因此，DL-CONNECT / MA-CONNECT .request和.confirm原语仅在客户端(主站)提供。另一方面，MA-CONNECT / DL-CONNECT .indication和.response原语仅在服务器(辅助站点)端提供。

在本地检测到错误的情况下，DL-CONNECT / MA-CONNECT .request 原语也可以在本地进行确认。(虚线部分)

s8.2.2.2 DL-CONNECT.request and MA-CONNECT.request

DL-CONNECT.request
(
    Destination_MSAP,
    Source_MSAP,
    User_Information
)

MA-CONNECT.request
(
    Destination_MSAP,
    Source_MSAP,
    User_Information
)

Destination_MSAP 和 Source_MSAP: 标识要建立的引用数据链路层连接。
User_Information：为可选配置。其内容的规范不属于本技术报告的范围。

服务用户层调用 DL-CONNECT.request 原语，LLC 层接收后调用 MA-CONNECT.request 原语发给 MAC 层，MAC 层发送格式化后的SNRM帧(Set Normal Response Mode (a HDLC frame type,HDLC 协议的一部分))

s8.2.2.3 DL-CONNECT.indication and MA-CONNECT.indication

DL-CONNECT.indication
(
    Destination_MSAP,
    Source_MSAP,
    User_Information
)

MA-CONNECT.indication
(
    Destination_MSAP,
    Source_MSAP,
    User_Information
)

和上面的相反，接收 SRNM 转换报文

s8.2.2.4 DL-CONNECT.response and MA-CONNECT.response

DL-CONNECT.response
(
    Destination_MSAP,
    Source_MSAP,
    Result,
    User_Information
)
MA-CONNECT.response
(
    Destination_MSAP,
    Source_MSAP,
    Result,
    User_Information
)

Result 指示提议的连接是否可以被接受，以及是否应该发送响应帧。它可以有以下值之一:

Result == OK这意味着接收到的连接请求可以被服务用户层接受。MAC 层收到后发送UA帧
Result == NOK。这意味着接收到的连接请求不能被服务用户层接受;（如果链路层收到第二个连接请求，但同时只能有一个，即使服务用户层接受，连接也不能建立），MAC 层收到后发送DM帧
Result == NO-RESPONSE。这意味着不应发送对 DL-CONNECT.indication 的响应。MAC 层收到 MA-CONNECT.response 后不发送任何帧

s8.2.2.5 DL-CONNECT.confirm and MA-CONNECT.confirm

DL-CONNECT.confirm
(
    Destination_MSAP,
    Source_MSAP,
    Result,
    User_Information
)

MA-CONNECT.confirm
(
    Destination_MSAP,
    Source_MSAP,
    Result,
    User_Information
)

Result 表示之前调用的 DL-CONNECT / MA-CONNECT.request 服务调用的结果。它可以具有以下值之一：

Result == OK。这意味着远程站接受了连接请求；
Result == NOK-REMOTE。这意味着远程站没有接受连接请求；
Result == NOK-LOCAL。这意味着发生了本地错误，例如服务用户层试图建立一个已经存在的数据链路连接；
Result == NO-RESPONSE。这意味着远程站没有响应连接请求。

s8.2.3 Disconnecting the data link connection: the DL-DISCONNECT and MA-DISCONNECT services

s8.2.3.2 DL-DISCONNECT.request and MA-DISCONNECT.request

同上 8.2.2.2

s8.2.3.3 DL-DISCONNECT.indication and MA-DISCONNECT.indication

DL-DISCONNECT.indication (
    Destination_MSAP,
    Source_MSAP,
    Reason,
    Unnumbered_Send_Status,
    User_Information
)

MA-DISCONNECT.indication (
    Destination_MSAP,
    Source_MSAP,
    Reason,
    Unnumbered_Send_Status,
    User_Information
)

Reason
- Reason == REMOTE：数据链路层收到来自客户端的断开连接请求。这种情况可能只发生在服务器端；
- Reason == LOCAL-DL：出现致命的数据链路连接失败；
- Reason == LOCAL-PHY：出现致命的物理连接故障。后两种情况可能同时发生在客户端和服务器端。
Unnumbered_Send_Status，USS，参数的值指示在 DL-DISCONNECT / MA-DISCONNECT .indication 原语调用的时刻，MAC 子层是否具有 (USS == TRUE) 或不具有 (USS == FALSE) 待处理的 UI 消息。
User_Information 可选

s8.2.3.4 DL-DISCONNECT.response and MA-DISCONNECT.response

service user layer 不能拒绝该服务，结果仅表明指定的 DL connection 是否存在

RESULT == NO-RESPONSE 表明 MAC 不应该发送任何响应

s8.2.3.5 DL-DISCONNECT.confirm and MA-DISCONNECT.confirm

和 response 类似

s8.2.4 Data transfer: the DL-DATA and MA-DATA services

使用 I 帧或 UI 帧

和 DL-DISCONNECT 及 DL-CONNECT 的区别是这个 DL-DATA 不再是透传了，LLC 层需要组 LSDU 作为 data，前面两个 LLC 就是什么也不干，直接把参数和 data 给 MAC 层。

s8.2.4.2 DL-DATA.request and MA-DATA.request

Frame_type：

client: I-COMPLETE and UI;(这里假设了 client 的资源足够大（比如缓冲区），所以调用原语时不需要分包，直接用完整的)
server: I-COMPLETE, I-FIRST-FRAGMENT, I-FRAGMENT, ILAST-FRAGMENT, and UI

收到调用后，LLC 层组装LSDU，其中包括LLC specific fields (the two LLC addresses and the LLC_Quality parameter)，不在 Frame_type == I-FRAGMENT or I-LAST-FRAGMENT 中添加，因为这个是头信息，只要在 I-FIRST-FRAGMENT 和 I-COMPLETE 中添加就行

s8.2.4.3 DL-DATA.indication and MA-DATA.indication

LLC 层要解 LSDU，校验LLC specific fields (the two LLC addresses and the LLC_Quality parameter)

s8.2.4.4 DL-DATA.confirm and MA-DATA.confirm

MAC 层生成，MAC 层判断是否发送成功

Frame_type = I-FIRST-FRAGMENT, I-FRAGMENT or I-LAST-FRAGMENT

s8.2.5 Physical layer services used by the MAC sublayer

物理层配置还有断开不是 MAC 层管的（见5.2.2）

物理层断开会通过PH-ABORT.indication原语通知 MAC 层

s8.2.5.4 Data transfer

PH-DATA.request and .indication 原语

s8.3 Protocol specification for the LLC sublayer

s8.3.2 LLC PDU format

Source_LSAP: 最低位表示 command(0)/response(1)
Control byte: LLC_Quality，保留，固定 0x00

destination LSAP 0xFF用于广播

s8.3.3 State transition tables for the LLC sublayer

区别是 client 端没有 I-FRAGMENT or ILAST-FRAGMENT，就不用判断类型，LSDU 里全部加上 LLC 头就行

s8.4 Protocol specification for the MAC sublayer

s8.4.1 The MAC PDU and the HDLC frame

s8.4.1.1 HDLC frame format type 3

Flag field:固定0x7E，在帧头尾,连续发送时头尾可以互连
Frame format field:
- Format type sub-field (4 bit):固定为 0b1010，十进制为 10 ，表示type3(HDLC frame format type 3)
- the Segmentation bit (S, 1 bit):表示链路层分片时，对应用层的整个包是否传输完成，为 1 表示传输还未结束，0 表示结束。类似于 OSI 模型中 IP 层分片标记，当应用层给了一个很大的包，需要 IP 层来做分片时就会用到该标记，表示这些分片都属于同一个应用包。
- the frame length sub-field (11 bit):除了 flag field 外的长度
Destination and source address fields:见 8.4.2
Control field：控制字段，见 8.4.3
Header check sequence (HCS) field：对头部序列的校验，计算Flag field和HCS之间的部分，如 Frame format + Dest. address + Src. address + Control，不包括后面的信息域和 FCS。当信息域不存在或者为空时，则 HCS 不存在，仅有 FCS
Information field：携带信息域（比如 MSDU）,I and UI 帧可用(其他类型帧可能也有，后面提到了 Disconnect (DISC) command)
Frame check sequence (FCS) field：计算校验，除 flag field 和 FCS

s8.4.2 MAC addressing

s8.4.2.2 Address field structure

HDLC 地址：HDLC 帧格式type 3(参见 8.4.1.1)包含两个地址字段:目的地址和源地址。根据数据传输的方向，客户端地址和服务器地址都可以是目的地址或源地址。

client address：总是 1 字节，不能扩展
server address：只允许 1，2，4 字节
- upper HDLC address：Logical Device(在物理设备内的一个单独的可寻址的逻辑实体)
- lower HDLC address：Physical Device，用于标识物理设备(如果是点对点的对其值不做要求，如果是多点接入则必须指定)

s8.4.2.3 Reserved special HDLC addresses

MAC 层中 HDLC addresses 的含义

客户端地址、服务端地址（分为低地址逻辑地址部分和高地址物理设备部分）：

每个字节的 LSB 用于标识是否有后续字节，所以不计入实际字节的表示，也就是一个字节就7个有效位。1111 1111 表示一个字节，后续无字节，然后把 LSB 去掉就是 1111 111，前面补 0 就是 0111 1111，一个字节最大就能表示0x7F。如果要表示0xFF,就是，0000 0010 1111 1111，去掉无效位（每个字节的 LSB），0000 001 1111 111，合并填 0，就是 0000 0000 1111 1111。对于 4 个字节的情况，分高 upper 地址 2 字节和低 lower 地址 2 字节考虑。

s8.4.2.4 Handling special addresses

源地址不能用 All-station or the Nostation address

s8.4.2.5 Handling inopportune address lengths in the server

对于服务端接收，源地址(就是客户端地址)固定 1 字节，超过 1 字节的帧丢弃（client address 仅允许 1 字节）

对于目的地址长度，有如下要求：

s8.4.3 Command and response frames

RRR is the receive sequence number N(R)，接收帧号

SSS is the send sequence number N(S)，发送帧号

从链路建立开始，帧序号就总是递增的，因为范围是 0-7 所以会有回绕。

P/F is the poll/final bit：P 表示poll bit，表示是否交出发送权，一般需要响应的请求的最后一帧会置为TRUE

I帧，Information transfer command and response
信息传递
- SSS字段，N(S)：自身发送帧的序号
- RRR字段，N(R)：期望接收到的下一帧的序号，表明对方的N(R)-1序号的帧已被正确接收。
发送接收最大information field长度默认为128字节，最大 2030 字节
Receive ready (RR) command and response
- 通知准备好接收 I 帧
- 确认之前收到的 N(R)-1 序号的 I 帧
按照上面 I 帧的描述，I 帧也可以利用 RRR 字段确认对方 I 帧，也可以用 P/F 字段交出发送权，达到和 RR 帧相同的效果，RR 帧可以认为是不带信息的 I 帧。
Receive not ready (RNR) command and response
- 通知未准备好接收 I 帧
- 确认之前收到的 N(R)-1 序号的 I 帧
RNR 接收方应该要知道，N(R)-1 之后的 I 帧发送都是无效的，也不应该再发 I 帧了，要补发 N(R) 及之后的 I 帧。
Set normal response mode (SNRM) command
SNRM 命令应用于将已分配地址的从站置于正常响应模式（NRM），其中所有控制字段的长度应为一个八位字节。次站应通过在第一个响应机会时发送 UA 响应来确认 SNRM 命令的接受。在接受该命令后，从站发送和接收状态变量应设置为零。
此命令执行后，原来由 DL 层管理的未被确认的 I 帧需要交还给更高层管理，是否重新交给 DL 层发送取决于该高层。
TODO:什么是正常响应模式。更新：见 8.4.4
Disconnect (DISC) command
终止之前配置的可操作或初始化模式，从站应进入逻辑断开模式。
TODO:逻辑断开模式和正常断开模式区别？更新：应该是同一个概念，就是 NDM
从站应发 UA 响应表示确认收到
（同 SNRM）此命令执行后，原来由 DL 层管理的未被确认的 I 帧需要交还给更高层管理，是否重新交给 DL 层发送取决于该高层。
可以理解为 SNRM 的逆操作
可能携带 information field。TODO:是否要把该信息交给上层（AL层）?
Unnumbered acknowledge (UA) response
对 SNRM 和 DISC 的响应
可能携带 information field，用于传递 DL 层参数
Disconnected mode (DM) response
报告自身处于 Normal Disconnected Mode(NDM)状态
- 请求主站或其他关联站向自己发送模式设置命令，如切成 NRM
- 响应模式设置请求，报告自己仍处于 NDM
例如，可以通过 SNRM 命令退出 NDM，进入 NRM
Frame reject (FRMR) response
从站报告接收到的帧的错误，该错误不能通过重传相同的解决，且该错误不是由于 FCS 错误引起的：
Unnumbered information (UI) command and response
- command
  发送信息给从站，不影响 V(S)和 V(R)，可以在任何模式（NRM,NDM）下使用
  UI 请求不指定从站响应，可能丢失或重复
  V(S)：Send state Variable
  V(R)：Receive state Variable
  不影响 I 帧或其他帧的序号
- response
  发送信息给主站，不影响 V(S)和 V(R)，可以在任何模式（NRM,NDM）下使用
  可能丢失或重复

s8.4.4 Elements of the procedures

当主备用站点之间建立了物理链路，但没有建立活动的数据链路通道时，客户端和服务器端的 MAC 子层都处于正常断开模式Normal Disconnected Mode(NDM);不传送或不接受任何信息或编号的监控帧。从站功能限制为：

接收与响应 SNRM
接收 UI
发送 UI 响应
收到 DISC 后发送 DM 响应

当 MAC 连接建立后，MAC 层工作在正常响应模式(NRM)。从站(服务器)只有在从主站(客户端)获得明确的许可后才可以开始数据传输。在收到许可(POLL BIT == TRUE)后，从站发起响应传输。响应传输可以由一个或多个帧组成，同时保持活跃的数据链路通道状态(见 8.4.4.3.1)。响应传输的最后一帧应由从站明确表示(FINAL BIT == TRUE)。在最后一帧指示之后，从站应停止发送，直到再次收到主站的明确许可。

s8.4.4.2 Transmission considerations

TODO:透明传输需要查看文档ISO/IEC 13239:2002, 4.3

按照一个字节内低位优先传输，多个字节按照最高有效字节优先，如0x1234，先传0x12

s8.4.4.3 HDLC channel states

Active HDLC channel state
当主站或从站处于传输帧中的一个字节状态时，就是 active 状态，保留有继续传输权
Abort sequence
不适用
Start/stop transmission inter-octet time-out
字节间超时等待状态，接收完一个字节开始等待，直到收到下个字节或超时，超时要结束接收。
Idle HDLC channel state
当连续标记保持条件持续一段系统特定的时间($T_{idle}$)时，数据链路通道进入空闲状态。

s8.4.5 HDLC channel operation – Description of the procedures

选择了非平衡连接模式(unbalanced connection-mode)的数据链路操作。不平衡数据链路包括一个主站和一个或多个从站。数据链路的整体错误恢复最终由主站负责

选择了NRM和NDM模式。

s8.4.5.2 Data station characteristics

主站负责:

设置数据链路，断开数据链路;
发送信息传递、监督和无序号命令;
检查收到的响应。

从站应负责:

检查收到的命令;
根据接收到的指令，发送信息，监督和无序号命令的回复。

s8.4.5.3 Procedures for setting up and disconnecting the data link

Setting up the data link
主站发 SNRM，从站回 UA 表示确认并进入 NRM，回 DM 表示无法进入 NRM
主站未收到回应等待超时重发，直到 MAX_NB_OF_RETRIES 次数停止
HDLC parameter negotiation during the connection phase
SNRM/UA 消息交换不仅可以建立连接，还可以协商一些数据链路参数
- 最大 information field 长度参数，默认 128 字节
  - 发送
  - 接收
- Window size 窗口大小，默认 1，最大 7(因为 SSS 和 RRR 字段只有3个bit位,见 8.4.3.1).
  - 发送
  - 接收
SNRM 中的 Window size – receive 是强制的，UA 中的‘Max_info_field_length– receive’ (0x40), and the ‘Window size – transmit’ (0x07)是强制的
Disconnecting the data link
主站发DISC，从站回UA响应，并进入 NDM。如果已经处于断开模式 NDM，将发送DM响应。
超时重发和 Setting up the data link 相同

s8.4.5.4 Procedures for data exchange

收到 MA-DATA.request 调用后，发送I帧，只能在NRM下发送。若 Frame_type == UI，则发送UI帧，一般用于广播多播，且可以在NRM或NDM状态发送。

Exchange of information frames
主站请求的最后一帧poll bit置 1，表示等待响应，从站响应的最后一帧final bit置位表示发送结束。
8.4.5.4.5 Transferring long MSDUs from the server to the client
服务端资源有限，客户端资源较多，对 dl-data 进行分段，Frame_type == IFIRST-FRAGMENT、I-FRAGMENT、I-LAST-FRAGMENT
8.4.5.4.6 Multi- and broadcasting
对使用UI帧实现多播广播的情况，仅允许客户端发送，服务端不允许
只有 UI(和 DISC)消息可以作为广播或组播消息，此时 UI 帧的Poll bit必须为FALSE,表示无需响应（就是不会把发送权交给从站）
DISC一般用于在通过断开低层连接方式断开AA时发送的命令。
多播广播支持对一个物理设备的多个逻辑设备，或多个物理设备，根据 HDLC 目的地址的 upper 和 lower 字节
8.4.5.4.7 Sending an UI frame from the server to the client
服务端发送 UI 帧的情况
在 HDLC 中因为是主从模型，服务器作为从站没有权利主动上报，需要等客户端作为主站发送任意请求后，因为需要回复，从站获得发送权，再趁机发送该上报 UI 帧，且应在响应的最后一帧前发送
其他情况：
- 客户端发送 RR 帧，P=1
- 客户端发送空的 UI 帧，P=1
8.4.5.4.8 Handling the CALLING device physical address
CALLING Physical Device address，见 8.4.2.3
允许服务端发起物理连接请求，以便自己能上报数据（8.4.5.4.7那些数据）
客户端需要发送SNRM为服务端配置模式，其中 Lower MAC Address 的值应该为CALLING Physical Device Address (0x7E)，表示该报文是给正在寻求发起连接的服务端。
多点 multi-drop 网络中，所有服务端收到后首先判断自身的CALLING DEVICE标志，如为TRUE，表示自己正在寻求发起连接，则接收，如果为 FALSE，则丢弃。（收到 PH-ABORT.indication 物理层断开后应该置为 FALSE）
服务端接收后需要回复UA（确认）或DM（否认），此时源地址的Lower MAC Address字段应为正确的本机 MAC 物理地址，而不是 CALLING Physical Device Address

s8.4.5.5 Exception recovery

Response time-out
响应超时
发送完 poll bit 为 1 的帧后开始计时，收到 final bit 为 0 的帧时刷新计时，收到 final bit 为 1 的帧时结束计时
超时应该重发，当该帧时 I 帧时不应该重发，应该发 RR 帧同步 I 帧序号，确认丢失的是哪帧（TODO:是否同步完再重发 I 帧）
FCS and HCS error
TODO：引用了一些其他标准
有错误帧时，所有的连续帧都应被丢弃。
N(S) sequence error
Command/response frame rejection
FRMR 回应
Busy

s8.4.5.6 Time-outs and other MAC sublayer parameters

Time-out 1: Response time-out (TO_WAIT_RESP)
等待响应超时时间，所有命令和信息帧，客户端参数
TO_WAIT_RESP > RespTime + 2*MaxTxTime
Layer Parameter 1: Maximum number of retries (MAX_NB_OF_RETRIES)
最大超时重发次数
Time-out 2: Inactivity time-out
未向 PhL 发送或接收超时，每次发送或接收时重置。调用DL-LM_EVENT.indication原语，见8.6.2.7。超时应断开 DL 层连接
Time-out 3: Inter-frame time-out
帧间超时，接收端参数，超时未收到下一帧表示已经结束
Maximum information field length
最大 information field 长度，默认 128
Window size
窗口大小，默认 1

s8.4.5.7 State transition diagram for the server MAC sublayer

s8.5 FCS calculation

s8.5.1 Test sequence for the FCS calculation

示例帧： 0x7E 0x03 0x3F 0x5B 0xEC 0x7E

下面是实际传输时的 bit 序：

 ↙ - first bit transmitted           last bit – ↘
01111110 11000000 11111100 1101101000110111 01111110
  flag   address  control         FCS         flag

FCS 的计算考虑了信道上传输的比特顺序
对于 address 字段、control 字段和所有其他字段（包括数据，不包括 FCS），先传输（每个字节的）低位（UART 串口协议遵循此规则）
对于 FCS，最高项的系数（对应于 x15）首先传输。

s8.5.2 Fast frame check sequence (FCS) implementation

16 位的 FCS 计算参考 RFC 1662

大致思路见：https://www.cnblogs.com/Dvelpro/p/10206555.html

s8.5.3 16-bit FCS computation method

s8.6 Data link layer management services

DL-INITIALIZE
初始化 DL 层参数
DL-GET_VALUE
从 DL 层获取一个或多个参数
DL-SET_VALUE
设置 DL 层的一个或多个参数
DL-LM_EVENT
通知 DL 层的事件

s9 DLMS/COSEM application layer

s9.1 DLMS/COSEM application layer main features

s9.1.2 DLMS/COSEM application layer structure

DLMS/COSEM AL 的主要组成部分是应用服务对象Application Service Object(ASO)。它向其服务用户 COSEM Application Process (APs)提供服务，并使用支持协议层提供的服务。它在客户端和服务器端都包含三个必需的组件:

关联控制服务元素，Association Control Service Element，ACSE
扩展 DLMS 应用服务元素 the extended DLMS Application Service Element，xDLMS ASE;
控制功能 the Control Function，CF。
Client SN_Mapper ASE 是客户端专有可选项

xDLMS ASE提供在 COSEM APs之间传输数据的服务,见 9.1.4

Control Function (CF)元素指定ASO服务如何调用ACSE、xDLMS ASE和支持协议层的服务的适当服务原语。见 9.4.1。

客户端和服务器 DLMS/COSEM ASO都可能包含其他可选的应用程序协议组件。

当服务器使用SN引用时，可选的Client SN_Mapper ASE 出现在客户端AL ASO中。它使用 LN 和 SN 引用提供服务之间的映射。见 9.1.5。

DLMS/COSEM AL也执行 OSI 表示层的一些功能:

对ACSE和xDLMS APDUs进行编码和解码，参见 9.4.3;
另外，生成和使用代表ACSE和xDLMS APDUs的XML文档;
用于压缩和解压;
启用、验证和删除密码保护。

s9.1.3 The Association Control Service Element, ACSE

用于面向连接（connection oriented (CO)）通信

有关 AA(application association) 的信息其实可以参看 OSI 模型中的会话层

提供 application association 建立与释放服务：

COSEM-OPEN;
COSEM-OPEN 服务用于建立 AA。它基于 ACSE A-ASSOCIATE 服务。它能使应用程序上下文名称（Application_Context_Name）、安全机制名称（Security_Mechanism_Name）和 xDLMS 上下文参数值所标识的 ASE 程序开始使用 AA。AA 可以通过不同方式建立：
- confirmed AAs使用 COSEM-OPEN 服务，可以在单个客户端和单个服务器之间建立；
- unconfirmed AAs使用 COSEM-OPEN 服务，可以在单个客户端和多个服务器见建立，只有客户端发送，服务端不回应。（多播，广播）
- pre-established AAs 可能预先存在。不使用 COSEM-OPEN 服务。客户端必须知道服务器支持的上下文。预先建立的 AA 类型可以是 confirmed 或 unconfirmed。
COSEM-RELEASE
不丢失信息，优雅释放AAs
- TCP-UDP/IP based profile：基于ACSE A-RELEASE 服务
- 3-layer, CO, HDLC based profile：confirmed AAs直接断开对应协议层连接，Pre-established AAs 无需断开
COSEM-ABORT
异常释放，可能丢失信息，它不依赖于 ACSE A-ABORT 服务

s9.1.4 The xDLMS application service element

为了访问 COSEM 对象的属性和方法，使用了xDLMS ASE的服务

详见 9.1.4.3-9.1.4.8

s9.1.4.2 The xDLMS initiate service

xDLMS 初始化服务，用于建立xDLMS上下文，不过该服务不是 xDLMS ASE 的一部分，而是放在了 ACSE 的 COSEM-OPEN 服务中，具体携带在 AARQ 和 AARE 中，这也是为了利用 ACSE 服务在建立连接阶段顺便协商好 xDLMS 上下文，减少通信次数。

与 COSEM 对象相关的 xDLMS 服务用于访问 COSEM对象属性和方法。

COSEM 对象有两种引用方式：

Logical Name (LN) referencing
Short Name (SN) referencing

客户端ASO总是使用带有LN引用的 xDLMS ASE。服务器ASO可以使用带有LN引用的 xDLMS ASE，也可以使用带有SN引用的 xDLMS ASE，或者两者都使用

s9.1.4.3.2 xDLMS services used by the client with LN referencing

GET9.3.6、SET9.3.7、ACTION9.3.8、ACCESS9.3.9

s9.1.4.3.3 xDLMS services used by the client with SN referencing

Read9.3.14、Write9.3.15、UnconfirmedWrite9.3.16

s9.1.4.3.4 Unsolicited services

非请求(Unsolicited)服务(也可以叫主动上报服务)由服务器根据预定义的条件（如时间表、触发器或事件）启动，向客户端通报一个或多个属性的值，就像客户端已提出请求一样。

LN 有 EventNotification，SN 有 InformationReport，它们共有 DataNotification 服务（主要由 “Push setup” COSEM 对象管理）

s9.1.4.3.5 Selective access

对于某些 COSEM 类，可以对属性进行选择性访问，这意味着可以根据需要访问整个属性或其选定的部分。为此，访问选择器和参数被指定为相关属性规范的一部分。

这是一项可协商的功能；见 9.4.6.1：

在 LN 引用的情况下，这一功能称为选择性访问(Selective access)，见 9.3.6 和 9.3.7。
在 SN 引用情况下，该功能称为参数化访问(Parameterized access), 见 9.3.14, 9.3.15 and 9.3.16

s9.1.4.3.6 Multiple references

在 COSEM 对象相关的服务调用中，可以引用一个或多个命名变量、属性和/或方法，见 9.4.6.1的multiple-references参数，比如 ACCESS 总是支持这个特性

s9.1.4.3.7 Attribute_0 referencing

GET、SET 和 ACCESS 服务有一个特殊功能，即 Attribute_0 引用。

按照惯例，COSEM 对象的属性编号从 1 到 n，其中 Attribute_1 是 COSEM 对象的逻辑名称。

Attribute_0 有一个特殊含义：它引用所有正索引的属性（公共属性）。9.3.6 将解释在 GET 服务中使用 Attribute_0，在 9.3.7 中解释在 SET 服务中使用 Attribute_0，在 9.3.9 中解释在 ACCESS 服务中使用 Attribute_0。

注蓝皮书 4.1.2 中规定，制造商可使用负数向任何对象添加专有方法和/或属性。属性 0 引用是一项可协商的功能，请参阅 9.4.6.1。

s9.1.4.4 Additional mechanisms

与 IEC 61334-4-41:1996 中规定的 DLMS 相比，xDLMS 指定了一些新的机制来提高功能、灵活性和效率。其他机制包括:

使用逻辑名 logical names 进行引用;
识别服务调用;
优先处理;
传输较长的应用信息;
可组合的 xDLMS 消息;
压缩解压;
通用密码保护;
通用块传输 general block transfer(GBT)

下面逐个介绍

s9.1.4.4.2 Referencing methods and service mapping

在confirmed AAs的情况下，引用方法在 AA 建立阶段通过 COSEM 应用上下文进行协商。在 AA 成立期间不得改变。在给定的 AA 中使用 LN 或 SN 服务是独占的。

在unconfirmed and pre-established AAs 的情况下，客户端 AL 需要提前知道服务器支持的引用方法。

s9.1.4.4.3 Identification of service invocations: the Invoke_Id parameter

在 client/server 模型中，请求由客户机发送，响应由服务器发送。允许客户端在接收到对前一个请求的响应之前发送多个请求，前提是较低层允许这样做。

需要用Invoke_Id来标识数据包，这样客户端才能判断响应是对应哪个请求的

在ACCESS和DataNotification服务(参见 9.3.9 和 9.3.10)中，使用Long-Invoke-Id参数来代替Invoke_Id 参数。

EventNotification服务不包含Invoke_Id 参数。

此功能仅在LN引用时可用

s9.1.4.4.4 Priority handling

对于使用LN引用的数据传输服务，有两个优先级可用:normal (FALSE)和high (TRUE)。

服务器不使用先来先服务（FIFS）策略，而是根据优先级处理

此功能仅在LN引用时可用

s9.1.4.4.5 Transferring long messages

xDLMS 服务原语由xDLMS APDUs以编码形式携带。这种编码形式可能比客户端/服务器协商的最大接收PDU长度(Client / Server Max Receive PDU Size, AA 协商时参数，见9.1.4.8 Maximum PDU size)更长

两种方案：

通用块传输(GBT)机制
特定于服务(service-specific)的块传输机制

支持层也会提供传输长消息的方式，也就是分段(Segmentation,见10.2.6.5 Transporting long messages)，当一个较长的 APDU 超过了支持协议层(比如 HDLC 链路层)的单个帧/数据包大小但小于协商的 Client / Server Max Receive PDU Size 时，优先考虑使用支持层提供的分段服务传输整个完整的 APDU 。当其也超出协商的 Client / Server Max Receive PDU Size 时，就必须使用应用层分包解决。

所以 Max Receive PDU size 虽然是应用层参数，也需要考虑支持层的运载能力(和是否支持分段)，而不仅仅只考虑应用层的缓存大小。

特定于服务的块传输机制用于：

使用 LN 引用的 confirmed services:GET、SET、ACTION;
使用 SN 引用的 confirmed services:Read、Write

特定于服务的块传输在以下情况下不可用:

unconfirmed services
unsolicited services (DataNotification, EventNotification and InformationReport)
the ACCESS service

特定于服务的块传输只能一包一包顺序传，不支持流式传输，不支持恢复丢失块。加密是加一个 block，而不是整个 APDU（根据协议原文所述这会带来更多的性能消耗，这个我持怀疑态度，分块后加密和全部加密后再分块应该不会有明显的性能差距）。数字签名不可用（数字签名只能保护完整 APDU,不支持分块保护）。

相反，GBT机制可以与任何 xDLMS APDU 一起使用，包括通用密码和通用签名APDU。它提供双向块传输、流和丢失块恢复。当需要加密保护时，对完整的APDU进行加密保护，然后被保护的 APDU 以块的形式传输，如图 87 所示。

s9.1.4.4.6 Composable xDLMS messages

可组合的 xDLMS 消息

处理 xDLMS 消息的三个重要方面是编码/解码、应用/验证/删除密码保护和块传输，见9.3.5。

可组合 xDLMS 消息的概念将这三个方面分开

一旦 AL 构建了与 AP 调用的服务原语对应的 APDU，就可以使用通用保护机制来应用密码保护。然后产生不受保护或受保护的 APDU ，当长度超过协商的 APDU 长度时，可以采用通用块传输机制(任何 APDU 都能使用，包括 GBT APDU 也能嵌套 GBT APDU)。

s9.1.4.4.7 Compression and decompression

For details, see 9.2.3.6.

s9.1.4.4.8 General protection

此机制可用于对任何 xDLMS APDU 应用密码保护，这允许在客户机和服务器之间或第三方和服务器之间应用多层保护。见 9.2.2.5。

the general-ded-ciphering and the general-glo-ciphering APDUs;
the general-ciphering APDUs;
the general-signing APDU.

s9.1.4.4.9 General block transfer (GBT)

GBT 机制可用于块内传输任何长或短xDLMS APDU。在 GBT 中，块由通用块传输APDU携带，而不是由特定于服务的“with-datablock”APDUs 携带。

GBT 机制支持双向块传输、流传输和丢失块恢复 特性:

双向数据块传输：是指一方在发送数据块时，另一方不仅可以确认收到的数据块，而且如果有数据块要发送，也可以在接收数据块的同时发送；注意双向数据块传输适用于需要双向传输较长服务参数的情况。(TODO:是否有这种情况)
流式传输：是指一方可以发送多个数据块（流式传输），而另一方无需对每个数据块进行确认（只需在适当的时机进行一次回复告知所有已经被正确接收的块，也就是窗口的概念，每次窗口结束才回复一次）；参考 TCP 传输
丢失数据块恢复：是指如果发送的数据块的接收未得到确认，可以再次发送。如果使用流式传输，则在每个流式传输窗口结束时进行丢块恢复。

通用块传输机制的协议在 9.4.6.13 中指定

GBT 机制支持以下用例(GBT 触发条件)：

客户端的短 confirmed 请求导致服务器的长响应：请求可以在使用或不使用 GBT 的情况下发送(因为短，可以不用 GBT)。但如果使用 GBT 发送请求，则客户端可在交换开始时公布其偏好的 GBT 窗口大小。服务器使用 GBT 作出回应；
客户端 confirmed 的长请求：客户端使用 GBT 发送请求，服务器使用 GBT 发送回应，无论回应的长度是多少；
客户端 unconfirmed 的长请求：客户端使用 GBT 发送请求；服务器无需响应。
服务器未主动请求(unsolicited)的长 confirmed 请求：服务器使用 GBT 发送请求，客户端使用 GBT 发送回应；
服务器未主动请求的长 unconfirmed 请求：服务器使用 GBT 发送请求。

s9.1.4.5 Additional data types

s9.1.4.6 xDLMS version number

s9.1.4.7 xDLMS conformance block

xDLMS一致性块支持具有扩展功能的优化的 DLMS 服务实现。它可以通过标记“Application 31”与 DLMS 一致性块区分开来。请参见 9.4.6.1、9.5 和 9.6。

confirmed AAs可以在AA建立期间协商一致性块，unconfirmed and pre-established AAs需要客户端提前知道server 的一致性块。在已建立 AA 的有效期内，该一致性块不得更改

s9.1.4.8 Maximum PDU size

Client Max Receive PDU Size: Unsigned16，必须能满足 AARE APDU 大小（因为 ACSE APDU 都不支持 xDLMS 的服务特定分包或 GBT）; 低于 12 的值被保留，0 表示无限制
Server Max Receive PDU Size: Unsigned16; 低于 12 的值被保留，0 表示无限制

s9.1.5 Layer management services

这些服务的规范不在本技术报告的范围内。

s9.1.6 Summary of DLMS/COSEM application layer services

The DLMS/COSEM AL services are specified in 9.3.
The DLMS/COSEM AL protocol is specified in 9.4.
The abstract syntax of the ACSE and xDLMS APDUs is specified in 9.5.
The XML schema is defined in 9.6.

s9.1.7 DLMS/COSEM application layer protocols

DLMS/COSEM AL协议是基于ISO/IEC 15954:1999中规定的ACSE标准和IEC 61334-4-41:1996中规定的DLMS标准，并扩展了 DLMS/COSEM。

s9.2 Information security in DLMS/COSEM

DLMS/COSEM 安全概念 security concept，见 9.2.2;
选择的加密算法，见 9.2.3;
安全密钥，见 9.2.4、9.2.5、9.2.6;
使用加密算法进行实体认证，xDLMS APDU 保护和 COSEM 数据保护，见 9.2.7。

s9.2.2 The DLMS/COSEM security concept

s9.2.2.2 Identification and authentication

s9.2.2.2.1 Identification

如 4.3.3 所述，DLMS/COSEM AEs被绑定到支持 AL 的协议层中的服务接入点(SAPs)。这些 SAPs 存在于 AA 中包含 xDLMS APDUs 的 PDUs。

客户端用户识别机制使服务器能够区分客户端的不同用户(可能是运营商或第三方)，以记录他们访问设备的活动。也看到 4.3.6。

s9.2.2.2.2 Authentication mechanisms

身份验证机制确定通信实体在 AA 建立期间使用的协议来证明自己。

No security (Lowest Level Security) authentication
无安全性(最低级别安全性)身份验证的目的是允许客户机从服务器检索一些基本信息。这种身份验证机制不需要任何身份验证;客户端可以访问安全上下文中的 COSEM 对象属性和方法，以及给定 AA 中普遍存在的访问权限。
Low Level Security (LLS) authentication
服务器要求客户端通过提供服务器知道的密码来证明自己。该密码是由当前持有的“Association SN / LN”对象建模的 AA 来建立的。“Association SN / LN”对象提供了更改密码的方法。
High Level Security (HLS) authentication
客户端和服务器都必须成功地证明自己（双向认证），以建立一个 AA。
- Pass 1:客户端发送一个“challenge”CtoS 信息，以及根据身份验证机制附加的信息给服务器;
- Pass 2:服务器发送一个“challenge”StoC 信息，以及根据身份验证机制附加的信息给客户端;
  如果 StoC 与 CtoS相同，客户应拒绝并中止AA 建立过程。所以 StoC 与 CtoS 必须是独立生成的且不同的。（为了使这两个值一定不同，应该可以用 systemtitle 作为前缀，再加上随机生成的值）
- Pass 3:客户端根据对给定 AA 有效的 HLS 身份验证机制的规则处理StoC和其他信息，并将结果发送给服务器。服务器检查f(StoC)是否是正确处理的结果，如果是，则接受客户端的身份验证
- Pass 4:服务器根据对给定 AA 有效的 HLS 身份验证机制的规则处理CtoS和附加信息，并将结果发送给客户端。客户端检查f(CtoS)是否是正确处理的结果，如果是，则接受服务器的身份验证。

总结，由服务端先校验客户端合法性，再由客户端校验服务端合法性

pass2后，如果 application context and xDLMS context合法（这两个参数在 pass1 和 2 交换或生成，pass2 后已存在，只不过要到 pass4 全走完才激活），则授予当前”Association SN / LN”对象的reply_to_HLS_authentication方法权限

pass3 和 4 依赖于 reply_to_HLS_authentication

TODO：从 control-function 状态图来看，只要 COSEM-OPEN 服务完成即可认为 AA 建立成功，但这里在 HLS 过程中，还需要完成 pass 3和4，才算 AA 建立完成，有冲突。

s9.2.2.3 Security context

安全套件security suite，确定可用的安全算法，参见 9.2.3.7;
安全策略security policy，确定在 AA 内交换的所有 xDLMS APDUs 的保护类型。可能的安全策略在 9.2.7.2.2 中指定;
安全材料security material，与给定安全算法相关的，包括安全密钥、初始化向量、公钥证书等。由于每个安全算法的安全材料都是特定的，因此在相关条款中详细指定了元素。

s9.2.2.4 Access rights

属性的访问权限包括:no_access、read_only、write_only 或 read_and_write。

方法的访问权限可以是 no_access 或 access。

可以对访问特定的属性或方法的 APDUs 单独配置加密，.request 和.response 也可以

s9.2.2.5 Application layer message security

就是对称加密传输的过程，AA 已经建立的情况下

为了确保端到端消息安全性，第三方必须能够与 DLMS 服务器交换受保护的 xDLMS 服务请求。在这种情况下，客户端充当代理

第三方Third party:
- 感知 DLMS/COSEM，即它可以生成和处理封装了携带 COSEM 对象相关的服务请求和响应的 xDLMS APDUs的消息;
- 它能够对携带请求的 xDLMS APDU 应用自己的保护
  TODO：这个保护是不是不在 DLMS 规定的范围内，比如用 HTTP 传输，TLS 保护。但是接受服务端消息时又写到能够处理 server - client general protected APDU，AA 不是 client 和 server 建立的吗，third party 的密钥是哪里来的，对应9.2.7.3一起
- 它能够验证由服务器和/或客户端应用的保护响应。
The DLMS client
- 作为第三方和服务器之间的中间人broker;
- 根据TP-client消息中包含的信息，为第三方提供适当的AA;
- 验证 TP 有权使用该 AA;验证方法超出了本技术报告的范围。
  这里提到了AA是client和server维护的，和third party无关，但third party可以利用这个AA传递消息
- 它可以验证第三方申请的保护;
- 封装第三方客户端消息到一个通用的受保护的 xDLMS APDU;
- 它可以验证服务器对封装 COSEM 对象相关服务响应或未经请求的服务请求的 APDU 应用的保护;(Push 操作时);
- 它可以对发送到 TP 的受保护的 xDLMS APDU 应用自己的保护。
The server
- 与第三方使用的客户端(预先)建立AA;
- 它可以检查使用 AA 的第三方的身份;
- 一旦客户端和/或第三方应用的保护被服务端成功验证，服务端将提供访问 COSEM 对象属性和方法的权限，这些属性和方法由安全策略和访问权限确定;
- 它应该准备响应——或者，在推送操作的情况下，一个未经请求的服务请求——并应用由传入请求的保护、访问权限和安全策略决定的保护。

s9.2.2.6 COSEM data security

对具体COSEM 对象内属性、方法参数等的保护，与 AL 层整体加密整个 xDLMS APDU 有区别。

s9.2.3 Cryptographic algorithms

散列函数 hash functions
对称加密 symmetric key algorithms
非对称加密 asymmetric key algorithms

s9.2.3.2 Hash function

一个好的哈希函数是单向函数（逆过程很难），且要找到产生相同哈希值的两个特定输入也是极其困难的。

哈希函数接受任意长度的输入，输出固定长度的值。

一般用于校验完整性

在 DLMS/COSEM 中使用哈希算法的目的如下:

数字签名，见 9.2.3.4.4;
密钥协议，见 9.2.3.4.6;
HLS 认证。具体算法与认证机制有关，请参见 9.2.7.4。

s9.2.3.3 Symmetric key algorithms

对称密钥算法在 DLMS/COSEM 中用于以下目的:

使用 HLS 认证机制对通信伙伴进行认证，参见 9.2.7.4;
xDLMS 消息的认证和加密，参见 9.2.7.2;
COSEM 数据认证和加密，参见 9.2.7.5。

s9.2.3.3.2 Encryption and decryption

s9.2.3.3.3 Advanced Encryption Standard

AES 算法，属于分组加密算法

AES 结合了安全性、性能、效率、易于实现和灵活性。具体来说，该算法在各种计算环境的硬件和软件上都有良好的性能。此外，该算法对内存的要求非常低，这使得它非常适合于空间受限的环境。

TODO:内存占用少是不是因为是分组加密，每一块加解密时占用少导致的

s9.2.3.3.4 Encryption Modes of Operation

AES-GCM 可规避相同明文块加密成相同密文块带来的重复特征检测，密文块批量篡改的问题。

s9.2.3.3.5 Message Authentication Code

消息验证码 MAC

MAC 作用与 HASH 函数相似，都可以验证完整性，不同的是 MAC需要密钥而 HASH 不需要密钥。MAC 还能验证真实性，即使内容被篡改因为没有密钥也无法生成 MAC

s9.2.3.3.6 Key wrapping

可以使用对称密钥算法使用密钥封装密钥(也称为密钥加密密钥)来封装(即加密)密钥材料。

master key

见 9.2.3.3.8

s9.2.3.3.7 Galois/Counter Mode

GCM 是 AES 算法的一种运行模式。

加密或认证可选，可以仅加密或仅认证

认证加密函数
- 输入:
  - 密钥，EK
  - 明文，表示为P;
  - 附加认证数据Additional Authenticated Data(AAD)，记为A;
  - 初始化向量initialization vector(IV)表示为IV。
  明文和 AAD 是 GCM 保护的两类数据。GCM 保护了明文和 AAD 的真实性;GCM 还保护明文的机密性，而 AAD 则是透明的（明文加密认证，AAD仅认证）
  长度要求（bit）：
  - len(P) < 2^39-256;
  - len(A) < 2^64-1;
  - 1 <= len(IV) <= 2^64-1.
  P、A、IV 的位长都是8的倍数，所以这些值都是字节串。
- 输出：
  - 一个与明文 P 位长度相同的密文C
  - 一个身份验证标记或标记，简称T
认证解密函数
- 输入：
  - 密钥，EK
  - 密文 C
  - 附加认证数据Additional Authenticated Data(AAD)，记为A;
  - 一个身份验证标记，简称T
- 输出：
  - 一个与密文 C长度相同的明文P
  - 一个特殊的错误代码，在本技术报告中表示为 FAIL
The initialization vector, IV
就是 frame counter，每加密一次加 1,DLMS 协议里是 systemtitle + IC
systemtitle
又称固定字段
64位（8字节）
IC
又称调用字段
32位（4字节）
任意两个物理设备的固定字段不能相同（由systemtitle保证唯一），对同一逻辑设备的任意两次请求的调用字段不能相同（每次请求递增）
固定字段的位长将可以为给定密钥实现验证加密功能的不同物理设备的数量限制为 2^64。调用字段的位长将验证加密功能的调用次数限制为 2^32 输入集而不违反唯一性要求。
每个加密密钥(EK)都有两个相关联的调用计数器(IC)，一个用于经过身份验证的加密函数，另一个用于经过身份验证的解密函数。
- 当密钥建立时，对应的IC复位为 0;
- 使用认证加密功能后，对应的 IC加1。如果 IC 已达到最大值，任何进一步调用认证加密函数将返回错误，且 IC不得增加。
- 使用鉴权解密功能时，验证IC的值。该值必须等于或大于最低可接受值。
  如果被验证的值满足此要求，则使用认证解密功能后，最低可接受值为 已验证的IC值加1 。如果 被验证的值小于 最低可接受值，则验证失败，经过验证的解密功能也会失败。如果被验证的值等于最大值，则经过验证的解密函数将返回一个错误。
  TODO:这里有个问题，如果客户端出现异常，被验证值设置得很大，那不是会很快到达最大值，导致设备不可用
The encryption key, EK
GCM只使用一个密钥，即分组密码密钥。在 DLMS/COSEM 中，这被称为加密密钥，表示为EK。它的大小取决于安全套件(参见 9.2.3.7)，应该是:
- for security suite 0 and 1, 128 bits (16 octets): len(EK) = 128;
- for security suite 2, 256 bits (32 octets): len(EK) = 256;
密钥应该随机均匀生成，或者近似随机均匀生成，即每个可能的密钥生成的概率(几乎)相等。因此，该键将是新的，即，不等于任何以前的键，且概率很高。密钥应该是秘密的，应使用只适用于 GCM 和选定的分组密码 AES。密钥建立和管理的附加要求在 NIST SP 800-38D:2007, 8.1 中进行了讨论。
The authentication key, AK
作为附加认证数据(AAD)的一部分
Length of the authentication tag
身份验证标记的位长t是一个安全参数。在安全套件 0、1 和 2 中，其值应为 96 位。

s9.2.3.3.8 AES key wrap

对于封装密钥数据，DLMS/COSEM 选择了RFC 3394中指定的 AES 密钥封装算法。该算法旨在包装或加密关键数据。它对64位块进行操作。在 wrap 之前，关键数据被解析为n个64位的块,n至少为2。(AES 密钥长度是 128、192、256，所以肯定满足要求)

加密输入密钥加密密钥KEK和明文密钥，明文密钥为n个64bit块，输出(n+1)*64bit长度密文

解密相反。

AES-WRAP algorithm

GB∕T 36624-2018 信息技术安全技术可鉴别的加密机制

概述
AES-WRAP: Advanced Encryption Standard (AES) Key Wrap Algorithm。本文的总结均来自《RFC-3394》。
Any data being wrapped will be referred to as the key data; The key used to do the wrapping will be referred to as the key-encryption key (KEK)。
The term “key data” is used broadly to mean any data being wrapped, but particularly keys, since this is primarily a key wrap algorithm。
A KEK can be a 128-bit key, a 192-bit key, or a 256-bit key。
下面的 key wrap 和 key unwrap 都是 index based 模式的。
IV 分两种：Default 和 Alternative。Default 时， IV = A6A6A6A6A6A6A6A6

key wrap

Inputs: Plaintext, n 64-bit values {P1, P2, …, Pn}, and Key, K (the KEK).
Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, …, Cn}.

Steps:

Initialize variables

  
  Set A = IV, an initial value (see 2.2.3)
  For i = 1 to n      {  R[i] = P[i];  }

Calculate intermediate values.

  For j=0 to 5
    For i=1 to n
      B =    AES(K, A | R[i])
      A =    MSB(64, B) ^ t where t = (n*j)+i
      R[i] = LSB(64, B)

Output the results.

  Set C[0] = A
  For i = 1 to n
    C[i] = R[i]

key unwrap

Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, …, Cn}, and Key, K (the KEK).
Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}.

Steps:

Initialize variables.

  Set A = C[0]
  For i = 1 to n
    R[i] = C[i]

Compute intermediate values.

  For j = 5 to 0
    For i = n to 1
      B =    AES-1(K, (A ^ t) | R[i]) where t = n*j+i
      A =    MSB(64, B)
      R[i] = LSB(64, B)

Output results.

  If A is an appropriate initial value (see 2.2.3)
  Then
    For i = 1 to n
      P[i] = R[i]
  Else
    Return an error

模块W

图中的S是明文64bit块，输入输出等长
说明
AES(K, W) Encrypt W using the AES codebook with key K
AES-1(K, W) Decrypt W using the AES codebook with key K
MSB(j, W) Return the most significant j bits of
LSB(j, W) Return the least significant j bits of W

在 DLMS/COSEM 中，KEK 的大小取决于安全套件(参见 9.2.3.7)，并应是:

对于安全套件0和1,128 位(16 位):len(KEK) = 128;
对于安全套件2,256 位(32 位):len(KEK) = 256。

s9.2.3.4 Public key algorithms

公钥密码系统一般采用难以解决的问题作为算法的基础。RSA 算法是基于非常大的整数的质因数分解。椭圆曲线密码体制(ECC)是基于求解椭圆曲线离散对数问题(ECDLP)的难度。

通信双方认证
xDLMS APDUs 和 COSEM 数据的数字签名
密钥协商key agreement

一些非对称密钥算法可以用于多种目的(例如，用于数字签名和密钥建立)。用于一种目的的密钥不得用于其他目的。(只对公钥有这个要求，不过公私钥一般是一一配对的)

s9.2.3.4.2 Elliptic curve cryptography

椭圆曲线密码学 ECC

素数域上的椭圆曲线由实数(x, y)组成，满足下列方程:

\[y^2=x^3+ax+b\]

曲线的形状由 a 和 b 两个参数决定

NIST 推荐使用椭圆曲线

s9.2.3.4.3 Data conversions

本节描述了数据转换原语，用于在用于指定公钥算法的不同数据类型之间进行转换：八位字节串 (OS)、位串 (BS)、整数 (I)、字段元素 (FE) 和椭圆曲线点（ECP）。 DLMS/COSEM 使用八位组字符串来表示公钥算法的元素，并使用这些数据类型与八位组字符串之间的转换原语。长度为 d 的八位字节串 $M_{d–1}$ $M_{d–2}$ … $M_0$ 被编码为 A-XDR OCTET STRING，其中最左边的八位字节$M_{d–1}$对应于八位字节串的编码值的第一个八位位组

Conversion between Bit Strings and Octet Strings (BS2OS)
位串转换为八位串的数据转换原语称为位串到八位串转换原语，或称 BS2OS。它以位字符串作为输入，输出八位字符串。长度为 l 的字节串$b_{l-1} b_{l-2}…b_{0}$应该转换为长度为$d=⌈l/8⌉$的八位字符串$M_{d-1} M_{d-2}…M_{0}$。
位串在内存中的编码非常密集。每个位只占用一位存储空间，整个位串的开销由一个小常数限定。但是，与访问向量或字符串的元素相比，访问位串中的位要慢。如果性能是最重要的问题，最好使用字符串来存储布尔值集，即使它们占用更多空间。
位串和八位字节串的区别就是位串的位长不需要是8的倍数，而可以是任意值，转换的时候需要补足8的倍数
转换器在左边填充足够的零，使位数为8的倍数，然后将其分解为八位。
- for $0 \le i \lt d – 1$, let the octet $M_i = b_{8i+7} b_{8i+6} … b_{8i},$;
- the leftmost octet $M_{d–1}$ shall have its leftmost $8d – l$ bits set to zero;最左边的 OS 字节需要包含位串最左边填 0 部分
- its rightmost $8 – (8d – l)$ bits shall be $b_{l–1} b_{l–2} … b_{8d–8}$.
Conversion between Octet Strings and Bit Strings (OS2BS)
和上面相反
最左一字节的最左位必须是 0
Conversion between Integers and Octet Strings (I2OS)
输入为非负整数$x$，预期长度$d$，需要满足$256^d \gt x$
每个整数的位用一个字节表示：
- $x = x_{d-1} \cdot 256^{d-1} + x_{d-2} \cdot 256^{d-2} + \cdots + x_1 \cdot 256 + x_0$;
- where $0 ≤ x_i < 256$ for $0 ≤ i ≤ d-1$;
- $M_i = x_i$, for $0 ≤ i ≤ d-1$.
256正好是二进制0b100000000，1在8位，这样的话0-7位就表示$x_0$，通过$x_1 \cdot 256$让8-15位表示$x_1$
例：十进制1234，转为OS为$0 \cdot 256^3+0 \cdot 256^2+4 \cdot 256^1+210$结果为0x000004D2。其实就是把数字转换为16进制数用HEX表示
Conversion between Octet Strings and Integers (OS2I)
和上面相反
0 字节的 OS 输出整数 0
Conversion between Field Elements and Octet Strings (FE2OS)
将字段元素转换为八位字符串的数据转换原语称为字段元素到八位字符串转换原语，或FE2OS。它接受一个字段元素作为输入，并输出相应的八位字符串。应用 I2OS 转换原语，参数$l$将域元素$x \in F_p$转换为长度为$d =⌈\log_{256}p⌉$的八位字符串$M_{d-1} M_{d-2} … M_0$，其中
$FE2OS(x) = I2OS(x,l)$
Conversion between Octet Strings and Field Elements (OS2FE)
与上面相反
$OS2FE(x) = OS2I(x) \mod p$

TODO:Field Elements 是什么，FE2OS 不懂更新：域元素应该就是某个域范围内的一个值，比如域为0-9999，这个值可能就是3456。$log_{256}45768865=3.18098289749$，所以长度就至少是4，结果为0x02BA60A1，其实就是把数字转换为16进制数用HEX表示

s9.2.3.4.4 Digital signature

数字签名是书面签名的电子模拟，可用于向收件人或第三方证明消息是由发信人签名的(这种特性称为不可否认性)。还可以为所存储的数据和程序生成数字签名，以便可以在稍后时间验证数据和程序的完整性

数字签名与 MAC (消息认证码，见s9.2.3.3.5 Message Authentication Code)的区别：

数字签名与 MAC 都是一种认证方式，认证可分为

实体认证
消息认证
- 消息源认证（即消息的来源不是冒充的，来源必须持有密钥）
- 消息完整性（即消息未被恶意篡改）

MAC 只能进行消息认证，因为其基于对称密钥，即至少有两方拥有该密钥，虽然可保证消息的完整性和基本的消息源认证(肯定是由持有密钥的实体发送)，但无法确定该消息一定是某个特定实体发送的（因为每个拥有该密钥的实体都能生成相同的 MAC）。

而数字签名基于非对称密钥，有特定实体独自保有私钥，其他认证方仅有公钥，公钥只能用于验证签名，不能进行生成数字签名操作，所以可以保证数字签名一定是由该实体生成，也就保证了消息一定是该实体发送。

s9.2.3.4.5 Elliptic curve digital signature (ECDSA)

对于 DLMS/COSEM，选择了 FIPS PUB 186-4:2013 中指定的椭圆曲线数字签名(ECDSA)算法。NSA1 提供了一个实现指南。

在 DLMS/COSEM 中使用的椭圆曲线和算法为:
- in the case of Security Suite 1, the elliptic curve P-256 with the SHA-256 hash algorithm;
- in the case of Security Suite 2, the elliptic curve P-384 with the SHA-384 hash algorithm.
签名
- 输入：
  - 要签名的消息 M;
  - 签名者的私钥 d
- 输出：
  - ECDSA signature (r, s) over M.
验签
- 输入：
  - 已签名的消息 M’
  - ECDSA signature (r’,s’)
  - 签名者的公钥 Q

在 DLMS/COSEM 中，应使用纯文本格式：签名 (r, s) 被编码为八位字节串 $R || S$(表示串联，不是逻辑运算符的或)，即作为八位字节串 R = I2OS(r,l) 和 S = I2OS(s,l) 的串联, $l = [\log_{256} n]$。因此，签名具有 2l 个八位字节的固定长度。

s9.2.3.4.6 Key agreement

密钥协商允许两个实体联合计算共享密钥并从中派生密钥材料。

对于 DLMS/COSEM，已从 NIST SP 80056A Rev. 2: 2013 中选择了三种椭圆曲线密钥协商方案

椭圆曲线密钥协商方案：
- the Ephemeral Unified Model C(2e, 0s, ECC CDH) scheme;
  此方案用于 DLMS 客户机和服务器之间就主密钥(master key)、全局加密密钥(global encryption keys)和/或身份验证密钥(authentication key)达成一致。客户端扮演U方角色，服务器扮演V方角色。流程由“Security setup”接口类的方法支持;见 DLMS UA 1000-1 Part 2 Ed.15:2021, 4.4.7.
  双方从域参数(domain parameters) d中生成一个临时密钥对。双方交换临时公钥，然后使用域参数、各自的临时私钥和对方的临时公钥计算共享密钥Z。密钥材料(secret keying material)是使用 9.2.3.4.6.5 中指定的密钥派生函数(key derivation function,KDF)从共享密钥Z和其他输入中派生出来的。()
  域参数是什么
  在密码学中，domain parameters（域参数）是指用于定义某些密码算法的特定参数集合。这些参数在算法的正确性、安全性和互操作性方面起着关键作用。域参数的具体内容根据使用的密码算法类型而有所不同，例如对于椭圆曲线密码学（ECC）和离散对数问题（如 Diffie-Hellman）等算法，域参数各不相同。
  ECC 使用的域参数定义了椭圆曲线的具体形式和操作基数。这些参数包括：
  - 素数 ( p )：定义有限域 ( \mathbb{F}_p )。
  - 椭圆曲线参数 ( a ) 和 ( b )：定义椭圆曲线方程 ( y^2 = x^3 + ax + b )。
  - 基点 ( G )：椭圆曲线上一个固定点，用作所有密钥对的生成点。
  - 阶 ( n )：基点 ( G ) 的阶，即最小正整数，使得 ( nG = O )（点 ( O ) 是椭圆曲线上的无穷远点，或称为零点）。
  - 协因子 ( h )：曲线的阶 ( n ) 与域的阶 ( p ) 之间的关系。
  TODO:密钥材料，密钥派生是什么。
  密钥材料 (Secret Keying Material)
  密钥材料是指用于密码学操作（如加密、解密、签名和验证）的秘密数据。密钥材料包括但不限于以下内容：
  - 对称密钥：用于对称加密算法（如 AES 和 DES）的密钥。
  - 私钥：用于非对称加密算法（如 RSA 和 ECC）的私钥。
  - 会话密钥：在某个会话期间使用的临时密钥，通常由密钥交换协议生成。
  - 共享秘密：如 Diffie-Hellman 密钥交换生成的共享秘密，随后可用于生成对称密钥。
  密钥材料必须保持机密性，以确保其在密码操作中的安全性。如果密钥材料泄露，整个加密系统的安全性可能会被破坏。
  密钥派生函数 (Key Derivation Function, KDF)
  密钥派生函数是一种用于从原始密钥材料（如共享秘密、主密钥或密码）生成一个或多个密钥材料的方法。KDF 的主要目标是将原始密钥材料转换成适合特定用途的密钥材料。
  KDF 通常使用的原始密钥材料包括：
  - 密码：用户输入的密码，可以通过 KDF 生成用于加密的密钥。
  - 共享秘密：如 Diffie-Hellman 密钥交换生成的共享秘密，可通过 KDF 派生出对称加密密钥。
  C(2e, 0s) 这种表示方式表示 U 方和 V 方都使用 ephemeral key pair(ephemeral private key 和 ephemeral public key), 也就是说公私钥是动态生成的。
- the One-Pass Diffie-Hellman C(1e,1s, ECC CDH) scheme;
  和上面的类似，U 方(客户端)使用动态公私钥，V 方(服务端)使用静态公私钥，这种方式相较于第一种方式减少了一次服务端到客户端的通信(因为公钥是静态的，可以用其他方式提供，如设备出厂时就提供)。当然这种方式的安全性可能会不如第一种方式，毕竟密钥固定。
  C(1e, 1s)，表示 U 方的公私钥是 ephemeral 的，而 V 方是 static 的
- the Static Unified Model C(0e, 2s, ECC CDH) scheme.
  和上面的类似，双方都使用静态公私钥，不需要发送公钥，不过 U 还是需要向 V 发送一个 Nonce（number used once，作为 KDF 过程中的动态数据），Nonce 用于计算密钥材料，保证每次生成的密钥材料不同。
Key Derivation Function – The NIST Concatenation KDF
密钥派生函数，用于根据相关信息(Z, OtherInput)生成密钥材料。
Function call: kdf(Z, OtherInput)
实现时需要的一个哈希函数，可能的相关的参数：
- hashlen: 哈希函数的输出长度，用于生成密钥材料块
- max_hash_inputlen: 哈希函数的最大输入长度(单位为 bit，因为输入是一个 bit string)，在 SHA-256 下应该小于 $2^{64}$，或在 SHA-384 下小于 $2^{128}$。
函数所需参数：
- Z 共享秘密(shared secret)，byte string
- OtherInput
  - keydatalen 一个整数，表示要生成的密钥材料的长度(以位为单位):安全套件1为128位，安全套件2为256位;
  - OtherInfo 等于下列串联的位字符串
    $AlgorithmID \lVert PartyUInfo \lVert PartyVInfo \lVert SuppPubInfo \lVert SuppPrivInfo$
    - AlgorithmID bit string，指示如何解析派生的密钥材料,以及派生的密钥材料将用于哪种算法
      GUEK and GAK：AES-GCM-128 / AES-GCM-256.
      KEK：AES-WRAP-128 / AES-WRAP-256
      固定长度7位，如下：
    - PartyUInfo U 方提供的公开信息，用于派生过程，bit string。使用上一节提到的 the Static Unified Model C(0e, 2s, ECC CDH) scheme 方式时，除了公钥信息，还会有一个 Nonce 信息。
    - PartyVInfo V 方提供的公开信息，用于派生过程，bit string
    - SuppPubInfo (Optional),额外的公开信息，DLMS/COSEM 不使用
    - SuppPrivInfo (Optional),额外的非公开信息，DLMS/COSEM 不使用

s9.2.3.5 Random number generation

应提供强随机数生成器(RNG)，以生成 DLMS/COSEM 中使用的各种算法所需的随机数。

s9.2.3.6 Compression

本节其实和加密无关

压缩可应用于 COSEM 数据或 xDLMS APDU。此过程可与对称密钥加密相结合。参见 9.2.7.2.4.7 和 9.2.7.2.4.8。压缩算法应符合 ITU-T V.44：2000 的规定，数据打包方法应符合 ITU-T V.44：2000 附件 B.1 的规定（基于 LZ78 的 LZJH 算法）。选择该算法是为了满足以下要求：

低处理负荷
低内存要求
低延迟

压缩的使用由 9.2.7.2.4 中规定的安全控制字节第 7 位表示。

s9.2.3.7 Security suite

安全套件确定可用于各种密码原语的密码算法集和密钥长度。

DLMS/COSEM安全套件(见表 27)基于NSA suite B，包括用于`身份验证、加密、密钥协议、数字签名和哈希的加密算法

s9.2.4 Cryptographic keys – overview

密钥作用：

明文到密文的转换;
密文到明文的转换;
验证码(MAC)的计算和验证;
密钥包装 wrapping;
应用和验证数字签名;
密钥协商。

s9.2.5 Key used with symmetric key algorithms

对称密钥的使用

s9.2.5.1 Symmetric keys types

对称密钥的分类：

按目的分类
- key encrypting key (KEK)用于加密其他对称加密密钥，又称 master key
- encryption key 用于 AES-GCM 算法的块加密
- authentication key 用于 AES-GCM 算法的 AAD
按生命周期分类
- 打算使用较长时间的静态密钥。在 DLMS/COSEM 中，它们可能是：
  - 一个全局密钥，可用于在相同合作伙伴之间重复建立的多个 AA。全局密钥可以是单播加密密钥（GUEK）、广播加密密钥（GBEK）或认证密钥（GAK）；
  - 在两个合作伙伴之间建立的单个 AA 期间可以重复使用的专用密钥。因此，其生命周期与 AA 的生命周期相同。专用密钥只能是单播加密密钥。
- 临时密钥通常用于一个 AA 内的单个交换。

TODO:InitiateRequest APDU 和 AARQ 是什么关系？答：见 12.3 Table 133 最后，InitiateRequest APDU 是 AARQ 中 user-information 字段的一部分，是可以加密的

专用密钥由 AARQ APDU 中的InitiateRequest APDU携带，这个 InitiateRequest APDU本身要被全局单播加密密钥（GUEK）加密，AARE 中的InitiateResponse APDU也要用相同的方式加密。

AARQ 和 AARE APDUs 本身不受保护。

s9.2.5.2 Key information with general-ciphering APDU and data protection

当 general-ciphering APDU 用于保护 xDLMS APDU 或 COSEM 数据时，发送方不仅要发送加密后的xDLMS APDU / COSEM 数据，同时也要发送密钥的必要信息，该信息已经或将用于加密/解密 xDLMS APDU/COSEM 数据，包括EK、AK、MK等

s9.2.5.3 Key identification

确定的密钥可以是全局单播加密密钥（GUEK）或全局广播加密密钥（GBEK）。在这种情况下，安全控制字节（SC，见s9.2.7.2.4 Encryption, authentication and compression）的密钥设置(Key_Set)位无关紧要，应设置为零。

The Key_Set bit is not relevant and shall be set to 0 when the service-specific dedicated ciphering, the general-ded-ciphering or the general-ciphering APDUs are used.

s9.2.5.4 Key wrapping

可以用 key wrapping 加密的：

the master key, KEK; and/or
the global unicast encryption key GUEK; and/or
the global broadcast encryption key GBEK; and/or
the (global) authentication key, GAK.

“Security setup” 对象的 key_transfer 方法。

s9.2.5.5 Key agreement

可以用 The Ephemeral Unified Model C(2e,0s, ECC CDH) scheme 协商的密钥：

the master key, KEK; and/or
the global unicast encryption key GUEK; and/or
the global broadcast encryption key GBEK; and/or
the (global) authentication key, GAK.

s9.2.5.6 Symmetric key cryptoperiods

对称密钥的加密周期应在项目特定的配套规范中确定。

s9.2.6 Keys used with public key algorithms

非对称加密算法密钥分类：

按目的：数字签名、密钥协商
按生命周期：静态密钥、临时密钥

s9.2.6.2 Key pair generation

由(q, FR, a, b {, domain_parameter_seed}, G, n, h)生成私钥 d 和公钥 Q

s9.2.6.3 Public key certificates and infrastructure

Public Key Infrastructure (PKI)

s9.2.6.3.2 Trust model

DLMS servers 设备制造过程应该预先导入trust anchors信任锚、自己的证书、CA 证书、DLMS clients and third parties 证书。

设备制造导入证书或信任锚属于Out of Band (OOB)带外过程，也就是正规操作以外的过程，正常导入证书应该是通过“Security setup”对象

信任锚见这篇文章，信任锚就是最终信任的那个实体，可以有多个，可以是 root CA，一般操作系统或浏览器预装了可以信赖的 root CA 列表

“Security setup”类提供：

提供关于存储在服务器上的证书的信息的属性;
用于生成服务器密钥对的方法和用于生成服务器上的证书签名请求(CSR)信息的方法,CSR 由客户端代为发送给CA;
导入、导出、移除证书的方法

证书一般都有一个有效期限。但是，颁发给DLMS服务器的证书可能无限期有效。证书到期后，可能需要进行替换。

在服务器使用证书之前，必须对其进行验证。验证包括:

检查证书的语法有效性;
检查证书包含的属性;
检查证书有效期是否未过期;
检查信任锚点的认证路径;
检查证书颁发者的签名

s9.2.6.3.3 PKI architecture – informative

PKI 是一种安全基础设施，它创建和管理公钥证书，以方便使用公钥(即，非对称密钥)加密。

在验证绑定的准确性后，生成并分发公钥证书，以将公钥绑定到其他信息上（证书包含了公钥和部分设备自定义信息，最后加上数字签名）
维护和分发未过期证书的证书状态信息。

Root-CA 提供 PKI 的信任锚点。它为 Sub-CAs 颁发证书，并维护一个证书撤销列表(CRL)。Root-CA 证书策略定义了处理证书颁发的规则
Root-CA 拥有根证书“C(Root)”。Root-CA 的证书是用 Root-CA 的私钥自签名的。Sub-CAs证书也使用 Root-CA私钥签名。
Sub-CA Sub-CA 是为终端实体颁发证书的组织，被 Root-CA 授权
每个 Sub-CA Certificate Policy 证书策略必须遵守 Root-CA Certificate Policy
备存发给终端实体 End entity 的证书清单及证书撤销清单
Sub-CA 拥有证书C(sub-CA)。此证书由 Root-CA 颁发。Sub-CA 的私钥用于签名终端实体 End entity 证书。
End entities
- 数字签名密钥证书C(digitalSignature)，用于数字签名;
- 静态密钥协商密钥证书C(keyAgreement)，用于密钥密钥协商;
- （可选）TLS- certificate C(TLS)，用于在建立 TLS 安全通道之前在 DLMS 客户端和 DLMS 服务器之间进行认证。

s9.2.6.4 Certificate and certificate extension profile

所有证书都应具有为X.509 V3证书指定的结构。

s9.2.6.4.2 The X.509 v3 Certificate

m (mandatory): 强制使用;
o (optional): 可选;
x (do not use): 不要使用.

Certificate：

tbsCertificate 包含主题和颁发者的名称、与主题关联的公钥、有效期和其他相关信息

Version V3 为 2
Serial number 序列号必须为 CA 分配给每个证书的正整数。对于给定 CA 颁发的每个证书，它必须是唯一的。上限20个字节
Issuer and Subject 颁发者字段标识签名和颁发证书的实体。
Common Name 需要是 DLMS/COSEM System title
Validity period 证书有效期
- 开始生效(notBefore)
- 无效时间(notAfter)
DLMS 服务器可以获得无法指定有效过期日期的证书;这样的证书将在设备的整个生命周期内使用
为了表明证书没有明确定义的到期日期，notAfter 应该被分配 99991231235959Z 的 GeneralizedTime 值。

SubjectPublicKeyInfo 标识公钥和密钥算法

SubjectPublicKeyInfo ::= SEQUENCE
{
  Algorithm               AlgorithmIdentifier,
  subjectPublicKey        BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE
{
  algorithm               OBJECT IDENTIFIER,
  parameters              ANY DEFINED BY algorithm OPTIONAL
}

AlgorithmIdentifier 用于识别密钥算法

OBJECT IDENTIFIER：

OID value: 1.2.840.10045.2.1;
OID description: ECDSA and ECDH Public Key.

parameter：

1.2.840.10045.3.1.7：NIST P-256
1.3.132.0.34：NIST P-384

Subject Unique ID 主题唯一 id 可以选择性地用于终端设备证书，而不是服务器证书。

Certificate extensions
- Authority Key Identifier 标识公钥，公钥是和用于签名证书的私钥对应的
- SubjectKeyIdentifier 标识包含特定公钥的证书
- KeyUsage 密钥用途，keyAgreement、digitalSignature 等
- CertificatePolicies 证书策略
- SubjectAltNames 主题备用名称,可以当作 subject 的扩展
- IssuerAltName 签发者备用名称
- Basic constraints 标识本证书所有者是否为 CA
- Extended Key Usage 该证书可作为 TLS 服务器证书使用
- cRLDistributionPoints 标识如何获取 CRL
- Other extensions
signatureAlgorithm 包含 CA 用于签名此证书的签名算法的标识符。和signatureValue相关
1 2 3 4 5 AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER parameters ANY DEFINED BY algorithm OPTIONAL }
- ecdsa-with-SHA256, OID 1.2.840.10045.4.3.2 in the case of security suite 1;
- ecdsa-with-SHA384, OID 1.2.840.10045.4.3.3 in the case of security suite 2;
signatureValue 由ASN.1 DER编码的tbsCertificate生成的数字签名
用于验证 tbsCertificate 的有效性

s9.2.6.5 Suite B end entity certificate types to be supported by DLMS servers

终端设备包含的证书类型

证书必须用 ECDSA 签名，证书中的P-256类型密钥必须用P-256或P-384类型密钥签名，证书中的P-384类型密钥必须用P-384类型密钥签名

Root-CA 自签名证书（信任锚）
Sub-CA 证书
用于 ECDSA 签名生成和验签的证书
Key Establishment(Key agreement)用证书（ECDH算法，One-Pass Diffie-Hellman C(1e, 1s) scheme or with the Static Unified Model C(0e, 2s, ECC CDH) scheme）
TLS 证书

s9.2.6.6 Management of certificates

证书管理

s9.2.6.6.2 Provisioning servers with trust anchors

为服务器提供信任锚，需要再设备正常运行前导入Root-CA,Sub-CA证书或直接信任的CA公钥。可以有多个信任锚

信任锚的部署或替换是带外操作，out of band (OOB)

信任锚证书和其他证书存储在一起

TODO:这个是否有安全问题，比如 windows 有专门的受信任根证书区域，每个分类都有专属区域。更新:见下句

可以导出，不能导入或删除，解释了上面的安全问题，是有防篡改保护的

直接信任的 CA 公钥不能导出

s9.2.6.6.3 Provisioning the server with further CA certificates

为服务器提供进一步的CA证书（应该是 Sub-CA，非信任锚）

“Security setup”对象中的import_certificate方法

导入的 CA 证书需要使用信任锚校验

s9.2.6.6.4 Security personalisation of the server

安全个性化导入非对称密钥：

通过设备商专有方式导入私钥和公钥证书
“Security setup”相关函数产生
1. 客户端调用generate_key_pair方法。方法调用参数指定要生成的特定用途的密钥对:数字签名、密钥协商或 TLS;
2. 客户端调用generate_certificate_request方法。方法调用参数标识生成证书签名请求(CSR)所需的密钥对。返回参数包括 CSR，由新生成的密钥对的私钥签名;
TODO:CSR 还要私钥签名吗，用哪个私钥签名
1. 客户端向CA发送CSR，该消息封装了调用 generate_certificate_request 方法得到的返回参数。CA(如果满足必要条件)颁发证书并将其发送给客户端;
2. 客户端调用import_certificate方法。方法调用参数包含证书。服务器验证证书，如果成功，则将证书上的信息添加到 certificates 属性。如果验证失败，证书将被丢弃。
导入新证书成功后，旧证书将被移除。
使用服务器证书的各方可以通过以下方式获得证书:
- 带外out of band;
- 使用“Security setup”对象的export_certificate方法
- 作为AARE的一部分(在HLS认证期间)

s9.2.6.6.5 Provisioning servers with certificates of clients and third parties

向服务器提供客户端和第三方证书

服务器要验证数字签名，要使用使用静态密钥协商密钥的方案执行密钥协商，或要建立TLS连接，服务器需要对方的适当公钥证书。

如果在制造时已经知道客户端和/或第三方，则制造商可以将其公钥证书注入服务器。

否则，可以使用“Security setup”对象的import_certificate方法为服务器提供客户端和第三方的证书。

s9.2.6.6.6 Provisioning clients and third parties with certificates of servers

向客户端和第三方提供服务器的证书

要验证数字签名，要使用使用静态密钥协商密钥的方案执行密钥协商，或要建立TLS连接，客户端或第三方需要对方的适当公钥证书。

证书可以随服务器一起交付，并插入到客户端/第三方 OOB 中。

或者，客户端或第三方可以使用“Security setup”对象的export_certificate方法从服务器请求证书。方法调用参数标识所请求的证书。

s9.2.6.6.7 Certificate removal from the server

从服务器上删除证书

当属于服务器的证书被删除时，与公钥相关联的私钥也应被销毁。

“Security setup“对象的remove_certificate方法用于删除证书

s9.2.7 Applying cryptographic protection

保护xDLMS APDUs参见 9.2.7.2;
处理 HLS 认证期间的挑战信息challenges，见 9.2.7.4;
保护COSEM data，参见 9.2.7.5。

s9.2.7.2 Protecting xDLMS APDUs

本小节 9.2.7.2 指定了 9.2.3.3 和 9.2.3.4 中指定的加密算法如何用于保护 xDLMS APDUs:

s9.2.7.2.2 Security policy and access rights values

access rights访问权限由“Association LN”的 object_list 属性或“Association SN”对象的 access_rights_list 持有。access_rights 的access_mode元素决定了访问类型并规定了密码保护。它是一个 enum 数据类型。

对 COSEM对象 属性和/或方法的访问权Access rights可能要求对 xDLMS APDUs 进行认证、加密和/或签名。为此，只允许保护程度超过或等于安全策略security policy要求的 APDUs。保护程度低于安全策略和访问权限要求的 APDU 应被拒绝。

在这种情况下，更多的保护是指在 xDLMS APDU 上应用比安全策略所要求的更多种类的保护：例如，安全策略 security policy 要求所有的 APDU 都经过认证，但访问权限 Access rights 要求 APDU 经过加密和认证，即更高的保护。

(access rights 是针对某个对象的特定属性或方法的，security policy 是全局的，所以 access rights 可以比 security policy 更严格，而不能更宽松)

s9.2.7.2.3 Ciphered xDLMS APDUs

加密的xDLMS APDUs只能在加密的应用程序上下文中使用。另一方面，在加密的应用程序上下文中，可以同时使用加密和未加密的 APDUs。

general-ded-ciphering 中的 ded 表示 dedicated 专用的，使用专用密钥，AARQ时协商

general-glo-ciphering 中的 glo 表示 global 全局的，使用全局密钥，比如GUEK

s9.2.7.2.4 Encryption, authentication and compression

在消息保护的情况下，要保护的信息是xDLMS APDU。在 COSEM数据保护的情况下，需要保护的信息是COSEM data数据，即COSEM属性值或方法调用/返回参数。

The security header
$SH = SC || IC$
- Bit 3…0: Security_Suite_Id, see 9.2.3.7;
- Bit 4: “A” subfield: 是否认证
- Bit 5: “E” subfield: 是否加密
- Bit 6: Key_Set subfield: 0 = Unicast, 1 = Broadcast;
- Bit 7: 是否压缩
Plaintext and Additional Authenticated Data
plaintext, P
Additional Authenticated Data, A
security control byte, SC
authentication key, AK
information, I
P是一个关于加密的形参，可以为 I，如果不加密的话就是空的。
根据 SC 的不同，AAD 也会不同
Encryption key and authentication key
Initialization vector
三种加密方式
- Service-specific ciphering xDLMS APDUs
  Service-specific区别于general，可以使用部分变体，不支持压缩
  Len 表示 Len 后信息(SC+IC+ciphertext+auth.Tag) 的长度，后面几种加密方式同理
- The general-glo-ciphering and geneal-ded-ciphering xDLMS APDUs
  支持压缩，可以选择GLO全局密钥或DED独立密钥
- The general-ciphering APDU
  可以用于客户端和服务器之间，也可以用于第三方和服务器之间。这些APDU还携带了所使用密钥的必要信息。
Use of the fields of the ciphering xDLMS APDUs
本节描述不同类型的加密服务保护的内容以及各个字段的意义
Encoding example: global-get-request xDLMS APDU

s9.2.7.2.5 Digital signature

Additional fields 和 content 都被用于计算数字签名。

s9.2.7.3 Multi-layer protection by multiple parties

多重保护一般用于 third party->client->server 模型，即 third party 应用一层，client 应用一层。

server 需要根据请求的保护状态以及 security policy and access rights 要求的保护来保护数据

TODO:很难理解，需要实例。对应9.2.2.5一起

s9.2.7.4 HLS authentication mechanisms

需要提前知道对方的证书和 systemtitle,不知道的话需要传递

见原文示例

s9.2.7.5 Protecting COSEM data

需要保护的数据列表、需要保护的对象和保护参数由“Data protection”对象决定。

s9.3 DLMS/COSEM application layer service specification

s9.3.1 Service primitives and parameters

REQUEST：请求原语从 N-用户传递到 N-层以请求启动服务；
INDICATION：指示原语从 N-层传递给 N-用户，以指示对 N-用户重要的内部 N-层事件。该事件可能逻辑上与远程服务请求有关，也可能是 N-层内部的事件引起的；
RESPONSE：响应原语从 N-用户传递到 N-层，以完成先前由指示原语调用的过程。
CONFIRM：确认原语从 N-层传递给 N-用户，以传达一个或多个相关的先前服务请求的结果。

原语参数含义：

字段	说明
M	该参数对基元是强制性的。
U	该参数为用户选项，可根据 ASE 用户的动态使用情况提供或不提供。
S	该参数从其他 S 参数中选择，作为服务器 ASE 环境的内部响应。
C	该参数取决于其他参数或 ASE 用户环境。
(–)	该参数从不存在。
=	M、U、S 或 C 代码后面的 “(=)” 代码表示该参数在语义上等同于表中左侧服务基元中的参数。例如，`.indication` 服务基元列中的 “M(=)” 代码和 `.request` 服务基元列中的 “M”，表示 `.indication` 基元中的参数在语义上等同于 `.request` 基元中的参数。

（重要）命名规则

s9.3.2 The COSEM-OPEN service

COSEM-OPEN 服务的作用是在对端 COSEM 应用实体(AEs)之间建立 AA。

AA 相关协商后参数，AL 会保存，比如密钥、加密策略、是否使用 GBT、最大接收 PDU 大小等，

使用 ACSE 的 A-ASSOCIATE 服务

Protocol_Connection_Parameters
强制。它包含使用通信配置文件层所必需的所有信息，包括通信配置文件（协议）标识符和所需的地址。它确定了 AA 的参与者。该参数的元素被传递给管理低层连接的实体，并酌情传递给低层。
ACSE_Protocol_Version
可选参数。如果存在，则应使用缺省值。
Application_Context_Name
强制。在请求原语中，它持有客户端提议的值。在响应原语中，它保存相同的值或服务器支持的值。(类似于 TLS 握手中的加密策略，是一个需要协商的值)
见 registered-cosem-names
Called_AP_Title, Called_AE_Qualifier, Called_AP_Invocation _Identifier, Called_AE_Invocation_Identifier
可选。本技术报告不包含
Calling_AP_Title
有条件的。当建议的应用程序上下文和/或建议的HLS认证机制要求使用客户端system title，并且在注册过程中尚未传输时，Calling_AP_Title 应携带客户端 system title。见 4.3.4。
Calling_AE_Qualifier
有条件的。当 Application_Context_Name 为加密的应用上下文Application_Context_Name时，可能携带客户端的公共数字签名密钥证书。
Calling_AP_Invocation_Identifier
可选。本技术报告不包含
Calling_AE_Invocation_Identifier
可选。携带 AA 的客户端用户的标识符。
Local_or_Remote
强制。接收到 AARE APDU 生成的确认就是 Remote,本地确认就是 Local
Result
强制。remote confirmation 下为 AA 是否被接受，local confirmation 下为本地低层协议栈是否接受请求
Failure_Type
强制。在远程确认的情况下，它携带服务器提供的信息。在局部和消极 negative 确认的情况下，表示失败的原因。
Responding_AP_Title
有条件的。当协商的应用程序上下文和/或协商的 HLS 认证机制要求使用服务器 system title，并且在注册过程中尚未转移时，则 Responding_AP_Title 应携带服务器system title。
Responding_AE_Qualifier
有条件的。当 Application_Context_Name 为加密的应用上下文时，可能携带服务器的公共数字签名密钥证书。
Responding_AP_Invocation_Identifier and Responding_AE_Invocation_Identifier
可选
ACSE_Requirements
可选。用于选择认证功能单元。见 9.4.2.1 表格 81。DLMS 中的 ACSE 支持的 Authentication 功能模块（还有一个是 kernel 模块）为 AARQ 添加了一些参数
- Lowest Level Security:无此参数
- LLS：.request 有，.response 可能有
- HLS: .request 和.response 都有
Security_Mechanism_Name
有条件的。携带客户端的推荐值，或服务端的支持值
见 COSEM_Authentication_Mechanism_Name
The Calling_Authentication_Value、the Responding_Authentication_Value
有条件的。两者分别保存客户端和服务端的 Security_Mechanism_Name 的验证值
Implementation_Information
可选的。本技术报告不包含
Proposed_xDLMS_Context
xDLMS_Context 建议值。包含在AARQ APDU 中的user-information中的 xDLMS InitiateRequest APDU 中
Negotiated_xDLMS_Context
服务端接受 Proposed_xDLMS_Context 建议后回复。包含在AARE APDU 中的user-information中的 xDLMS InitiateResponse APDU 中
xDLMS_Initiate_Error
服务端不接受 Proposed_xDLMS_Context 建议后回复。包含在AARE APDU 中的user-information中的 xDLMS confirmedServiceError APDU 中
User_Information
不要将 COSEM-OPEN 服务的User_Information参数与 AARQ / AARE apdu 的user-information字段混淆。
Service_Class
强制的。指示服务是confirmed还是unconfirmed

s9.3.2.3 Use

服务原语通信模型:

confirmed AA – a
unconfirmed AA – b
pre-established AA – c

原语发生在 AP 和 AL 之间，

s9.3.3 The COSEM-RELEASE service

优雅释放已经存在的 AA

调用它的方式（Use_RLRQ_RLRE参数）决定了它是否使用 ACSE 的A-RELEASE服务。

如果 Use_RLRQ_RLRE 为 FALSE，则 AL 层不能使用 A-RELEASE 服务中的RLRQ和RLRE（和 AARQ/AARE 相对，见 9.4.2.1），也就不能使用 RLRQ/RLRE 断链。可以通过断开支持层的方式断链

s9.3.4 The COSEM-ABORT service

指示支持协议层的主动断开,只有 COSEM-ABORT.indication 原语，，对应上图中的e情况

COSEM-ABORT.indication 原语在客户端和服务器端本地生成，以指示 COSEM AP 下层连接以非请求的方式关闭。

此类事件的起因可以是一个外部事件(例如物理线路断线)，或者在一些配置文件中出现的一个支持协议层连接管理器AP(层管理AP，非 COSEM AP)的动作，当支持的协议层连接不是由 DLMS/COSEM AL 管理时。这将导致 COSEM AP中止任何现有的 AA，除了在服务器端预连接 AA。

s9.3.5 Protection and general block transfer parameters

Additional_Service_Parameters ：可选，仅用于在 AL 和 AP 之间传递加密或GBT相关信息。当不使用这两个特性时，必须省略。也就是说在不使用加密或 GBT 时不能启用 Partial service invocations。可以这么理解，如果需要使用 GBT，说明数据很长，所以 AP 需要也需要分段给 AL，TODO:为什么加密也需要？。
- Invocation_Type: 强制，Partial service invocations 时的参数，必须为COMPLETE, FIRST-PART, ONE-PART and LAST-PART
- Security_Options：可选，只有当应用程序上下文是加密的，且 Invocation_Type = COMPLETE 或 FIRST-PART 时才会出现。它决定了 AL 层的加密保护方式。
- General_Block_Transfer_Parameters：可选，仅当使用 GBT 且 Invocation_Type = COMPLETE 或 FIRST-PART 时，它才存在。它提供有关 GBT 流式处理功能的信息：
  - Block_Transfer_Streaming(BTS)：它由 AP 传递给 AL，以指示是否允许 AL 使用 GBT。
  - Block_Transfer_Window(BTW)：表示 GBT 支持的窗口大小，即窗口中可以接收的最大块数。
- Security_Status：可选，由 AL 传递给 AP，只有在应用了加密保护时才会出现。它包含 AL 已验证/删除的保护信息。它可以出现在所有类型的服务调用中。
Service_Parameters：强制，它们包括 xDLMS 服务调用的参数。如果 Invocation_Type != COMPLETE，则仅包括部分服务参数。
Protection_Element：可选，只有 APDU 经过验证或签名后才会出现，由 AL 提供给 AP。

TODO:重要！这里又提到了 Partial service invocations，就是用 FIRST-PART 之类的分包，属于可选的 Additional_Service_Parameters 参数，与 GET 之类的原语的 service-specific block transfer 不一样，和 general block transfer（GBT）又不一样，那这三种分包方式可以同时存在吗更新：1.Partial service invocations 的分包是针对本地 AL 和本地 AP 之间的，可能是用于 AL 接受缓存或 AP 发送缓存不够的情况，需按逻辑切割，不能像 GBT 一样按字节分割。2.service-specific block transfer 是针对本地 AP 和对端 AP 之间的，由 xDLMS 服务特定的分块方式，比如 GET 服务响应时可以用这种分块，用于解决超过 AP 接受或发送缓存的情况 3.GBT 是本地 AL 和对端 AL 之间的，适用于所有 xDLMS APDU，通过分割 APDU 解决 APDU 过大的情况

Partial service invocations在接收端时，AL 需要判断是否可以划分 PART，比如，因为 GBT 是流的形式传输，接收到的包都是按照字节分割的，所以接收端 APDU 需要判断是否可以完整解密、是否可以组成原语（如 ACTION-LIST，见 9.3.8 和 Figure 149，属性列表在前，参数列表在后，需要收全后才能组成原语），然后才能划分 PART。

s9.3.6 The GET service

其功能是读取一个或多个 COSEM 对象属性的值。结果可以在单个响应中交付，或者(如果它太长，不能在单个响应中交付)在多个响应中交付，使用块传输（没有指定是那种类型的块传输）。

两个优先级 normal (FALSE) or high (TRUE).

如果是 Request_Type=NEXT 就不用带 COSEM_Attribute_Descriptor

REQUEST-WITH-LIST 会带多个 COSEM_Attribute_Descriptor，但不能超过 server-max-receive-pdu-size。原则：GET.request服务原语必须包含在单个APDU中,所以不能用分BLOCK方式发请求

整个响应单个 APDU放得下就用 Response_Type == NORMAL or WITH-LIST，放不下就用 Response_Type == ONE-BLOCK，最后一包用 LAST-BLOCK

COSEM_Object_Attribute_Id == 0 (Attribute_0)的情况，表示读取所有的属性，返回一个包含所有数据的结构体，填充在Data区域，没权限的或访问出错的回 null-data

服务原语通信模型:

successful confirmed GET – a
unconfirmed GET – d（TODO:GET不需要返回，意义是什么？）
unsuccessful attempt due to a local error – c

重要：关于编解码，AP 层并不负责对 APDU 的编解码（比如 A-XDR 编码），对于 AL 层原语的调用（如 COSEM-OPEN、GET 等），传递的只是参数（或者叫变量），关于参数的格式和定义就是设计的问题了（可以使用编程语言的基本变量类型或自定义变量类型）。
Table 60中包含了原语的很多参数，但只有部分是需要被包含进最终的APDU中的，所以 AP 编解码本身就解释不通，否则 AL 需要再进行解码再封装，多此一举。其中 Result 中的Data是一个octet-string格式的参数，其内部的值已经是编完码的了，因为 Data 编解码是业务层蓝皮书的部分，需要 AP 来进行，但这里仅仅作为一个 octet-string 类型的变量，和 AP 不对整个 APDU 进行编码的观点不冲突。AL 属于绿皮书范畴，是通信的协议层，APDU 是作为通信载体，应该属于绿皮书范畴，所以需要 AL 层编解码

s9.3.7 The SET service

写入一个或多个 COSEM 对象属性的值。要写入的数据可以在单个请求中发送，或者(如果数据太长，不能在单个请求中发送)在多个请求中使用块传输。(不同于 GET，SET 请求可以分包)

仅 Request_Type == NORMAL, FIRST-BLOCK, WITH-LIST and FIRST-BLOCK-WITH-LIST 携带 COSEM_Attribute_Descriptor

响应不能分包

COSEM_Object_Attribute_Id == 0 (Attribute_0)的情况，同 GET，需要 SET 请求包含有全部公开属性的 Data 值的结构体。Result 将携带一个结果，如果写入了所有属性则为成功，或者只有一个失败原因。

TODO:部分成功的情况呢

服务原语通信模型:

successful confirmed SET – a
unconfirmed SET – d
unsuccessful attempt due to a local error – c

s9.3.8 The ACTION service

调用一个或多个 COSEM 对象方法

请求响应都能分包,需要请求完整发完，响应才开始分包发送结果

第一阶段：client AP 向 AL 发送 ACTION.request，server 的 AL 收到后向 AP 发送 ACTION.indication，server AP 回 ACTION.response，ACTION.confirm 由 AL 发送给 client AP,都是可以是分包的。直到收到完整的请求（LAST-BLOCK 发送后）。

第二阶段：开始执行方法，执行完后返回结果，可以分包

s9.3.9 The ACCESS service

9.3.9.1 Overview – Main features

使用一个.request / .response 访问（access）就能使用 GET / SET / ACTION 的多种服务的组合访问 多个COSEM 对象属性和/或方法，引入它的目的是为了改进 xDLMS 消息传递，同时保持与现有 xDLMS 服务的共存性。在 Eighth Edition, 4th July 2014 版本中引入。

ACCESS 服务是一种使用 LN 引用的统一服务，注意目前不支持 SN 引用。每个请求包含一个请求列表(List-Of-Access-Request-Specification)和相关数据列表(List-Of-Data)。每个响应包含一个返回数据列表(List-Of-Data)和请求结果的列表(List-Of-Access-Response-Specification),用来放 result，如果启用了自描述响应(Self-descriptive)特性，还可以包含一个请求列表(List-Of-Access-Request-Specification)。

可以将其看成是各种 with-list 服务的进阶整合版，GET/ SET/ ACTION-WITH-LIST 服务请求可以只在列表中包含一种请求类型（GET、SET 和/或 ACTION），而 ACCESS 服务请求则可以包含不同的请求类型。这样可以减少交换次数，从而提高效率。

对请求列表的处理具有顺序性，从列表中的第一个请求开始，然后继续处理下一个请求，直至结束。

Data-Notification 和 ACCESS 服务是唯二使用 Long-Invoke-Id-And-Priority(32位) 而不是 Invoke-Id-And-Priority(8位) 的服务。

9.3.9.1.5 Self-descriptive responses

具有自描述响应的特性：不仅包含结果 data，也包含请求参数，可以不依赖于对应的请求直接解析响应。该特性可选。

9.3.9.1.6 Failure management

在 GET/ SET/ ACTION-WITH-LIST 服务中，客户机无法控制其中一个请求失败后的处理情况。与此相反，ACCESS 服务允许客户端控制是否处理列表中失败请求之后的请求。

TODO: 那为什么不给 with-list 服务添加错误处理流程呢。ACCESS 添加错误处理方式的实现是扩展 invoke-id 为 long-invoke-id，并添加 processing-option 位描述错误处理方式，见9.3.9.2 Service specification。

9.3.9.1.7 Time stamp as a service parameter

旧的服务(get/set/action)没有考虑到携带时间戳，现在 access 服务可以带时间戳，表示 .request 和 .response 的调用时间，进一步降低消耗

TODO: 为什么可以降低消耗，原文是This further reduces overhead。也许是可能更精准的控制时间

该字段为可选字段，当不启用时，其为长度为 0 的 OCTET-STRING；启用时，其为 DATA-TIME(长度为 12 的 OCTET-STRING)。response 中的该字段与 request 中的关联，当 request 中不启用该字段时， response 也不能启用；反之，同理。

9.3.9.1.8 Presence of data in service primitives

与旧的服务(GET/SET/ACTION)的重大差异：

GET: 现在请求中也包含 data(虽然是空的)，且响应同时包含 data 和 result(Data-Access-Result)（而不是仅能选择其中一个）
SET: 现在响应同时包含 data(空的) 和 result(Data-Access-Result)（而不是仅有 result）
ACTION: 现在请求中的 data(method-invocation-parameters)将是必选的(原来是可选的)，响应中的 Access-Response-Action 将同时包含方法调用结果(Action-Result)和返回参数结果(Data-Access-Result)，data 必须包含(原来返回参数结果(Data-Access-Result)和 data 是可选的)。

注意当 ACCESS 服务中的 request 或 response 中的字段本身就不需要时可以填为空数据(null-data,00)，如 GET 子服务中的 request 中的 data, SET 子服务中 response 中的 data。

s9.3.9.2 Service specification

long-invoke-id（位 0-23）用于识别服务调用的实例；

自描述（self-descriptive ,位 28）指示服务响应是否不自描述（FALSE）或自描述（TRUE）。当设置为 TRUE 时，Access_Response_Body 参数应包含 Access_Request_Specification 参数；注意 1：Access_Request_List_Of_Data 参数不包含在.response 服务原始数据中。
处理选项（processing-option,位 29）指定在处理列表上的请求失败时该怎么办。当设置为 FALSE 时，处理将继续。当设置为 TRUE 时，处理将中断，即列表上后续失败的那一个请求不应被处理。如 9.3.9.1.2 所述，处理请求列表应从列表上的第一个请求开始，并继续处理下一个直到列表末尾；
服务类（ service-class ,位 30）指示服务调用是否已确认（TRUE）或未确认（FALSE）；注意 2：Service_Class 参数适用于整个服务调用，而不是列表上的个别请求。注意 3：根据通信配置文件，Service_Class 参数还可能决定用于携带 APDU 的帧类型。
优先级（priority,位 31）指示与服务调用实例相关联的优先级级别。它可以是普通（FALSE）或高（TRUE）。注意 4：Priority 参数适用于整个服务调用，而不是列表上的个别请求。

Access_Request_Specification:

Access_Request_Get 不带选择性访问参数
Access_Request_Set 不带选择性访问参数
Access_Request_Action
Access_Request_Get_With_Selection 带选择性访问参数，不能用于 Attribute_0 情况
Access_Request_Set_With_Selection 带选择性访问参数，不能用于 Attribute_0 情况

处理 response 时优先判断 result，如果 result 失败直接丢弃 data。

具体服务用法见文档。

s9.3.10 The DataNotification service

数据推送

服务类型：unsolicited 未经请求, unconfirmed 无需确认或 confirmed 需确认

request 支持分块传输

成功标志：

Confirmed 服务类型：收到 Data-Notification-Confirm xDLMS APDU
Unconfirmed 服务类型：收到支持层确认

服务原语通信模型：Figure 112 a), b) and d).

TODO:这里的 d 是什么情况，按照描述，Unconfirmed 也需要支持层响应

s9.3.11 The EventNotification service

unsolicited 的 unconfirmed 的服务

request 支持分块传输

Application_Addresses:可选，如果没有相应的AA，则包含全部识别信息(标识发送者和目的AP，也就是允许没有 AA 的情况上报)。如果服务端 AP 调用 request 时没有提供该信息，则 AL 组装本服务 PDU 时会使用默认的参数(服务端管理逻辑设备地址：0x01 和客户端管理 AP：0x01)

服务原语通信模型：Figure 112 f), g)

关于为什么这里的 f)和g)是分开的，是因为上报和客户端接收到信息并不是同步的，服务端 AP 上报后，AL 将会保留该内容，等待时机发送给客户端，这两个过程是异步，没有什么关联关系。

s9.3.12 The TriggerEventNotificationSending service

EventNotification 的触发服务，由客户端发起，用于 EventNotification 不能自动触发的情况。

不需要 AA

s9.3.13 Variable access specification

s9.3.14 The Read service

s9.3.15 The Write service

s9.3.16 The UnconfirmedWrite service

s9.3.17 The InformationReport service

s9.3.18 Client side layer management services: the SetMapperTable.request

有关 SN 的跳过

s9.4 DLMS/COSEM application layer protocol specification

s9.4.1 The control function (CF)

s9.4.1.1 State definitions of the client side control function

带/的表示过程，也就是在转换过程中发生的，不带/的表示状态转换触发的起点。(可以这么理解，左右两个 pending 就是中间态，而 IDLE 和 ASSOCIATED 是起始态，从起始触发的就是不带/的)

s9.4.1.2 State definitions of the server side control function

s9.4.2 The ACSE services and APDUs

s9.4.2.1 ACSE functional units, services and service parameters

DLMS/COSEM AL ACSE 基于 IEC 标准中的 connection-oriented ACSE

支持Kernel、Authentication两个功能模块

AARQ 和 AARE 中的acse-requirements(见 9.3.2)参数用于选择功能模块启用

见文中 Table 81

AARQ APDU 由 COSEM-OPEN.request 原语决定，AARE APDU 由 COSEM-OPEN.response 原语决定

各个参数：

TODO:用到的时候补充下

user-information:AARQ APDU 中携带xDLMS InitiateRequest APDU包含 Proposed_xDLMS_Context 参数。AARE APDU 中携带 an xDLMS InitiateResponse APDU 包含 Negotiated_xDLMS_Context 参数

s9.4.2.2 Registered COSEM names

OSI 环境中有非常多种类的网络设备，需要特定的ISO标准网络对象名区分它们。

DLMS/COSEM中使用的对象名：

COSEM_Application_Context_Name
应用上下文参数
{joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) application-context(1) context_id(x)}
其中application-context和context_id的定义：
COSEM_Application_Context_Name 由 COSEM-OPEN.request 中的 Application_Context_Name parameter 携带
COSEM_Authentication_Mechanism_Name
认证机制参数（认证指的是验证身份和数据完整性，原数据会被第三方看到，但不能篡改或伪造）
{joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) authentication_mechanism_name(2) mechanism_id(x)}
其中 authentication_mechanism_name 和 mechanism_id：
COSEM_Authentication_Mechanism_Name 由 COSEM-OPEN.request 中的 Mechanism-name parameter 携带
COSEM_Cryptographic_Algorithm_Id
加密算法参数
{joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) cryptographic-algorithms (3) algorithm_id(x)}
其中cryptographic-algorithms和algorithm_id：

s9.4.3 APDU encoding rules

s9.4.3.1 Encoding of the ACSE APDUs

ACSE APDUs 编码：BER

user-information(xDLMS InitiateRequest APDU)内的内容因为是xDLMS格式的，所以需要用A-XDR编码

s9.4.3.2 Encoding of the xDLMS APDUs

xDLMS APDUs 编码：A-XDR

s9.4.3.3 XML

DataNotification APDU 可以编码为 XML 格式。

s9.4.4 Protocol for application association establishment

s9.4.4.1 Protocol for the establishment of confirmed application associations

client AP 发送COSEM-OPEN.request原语（Service_Class == Confirmed），client CF（control function）进入ASSOCIATION PENDING状态（见 9.4.1），

然后，CF 在 xDLMS ASE 和 ACSE 的帮助下组装包含从 AP 接收的 COSEM-OPEN.request 原语参数的 AARQ APDU，并将其发送到服务器。

xDLMS ASE是 InitiateRequest APDU 打包器（只和 xDLMS 相关，就是 AARQ 中的user-information），ACSE是 AARQ APDU 打包器（ACSE 中的Kernel和authentication functional 相关的参数,见 9.4.2.1）

服务器 AL 的 CF 将收到的 AARQ APDU 提供给 ACSE, ACSE 提取 ACSE 相关参数，然后将控制权交还给 CF。

然后，CF 将 AARQ APDU 的用户信息参数的内容（携带 xDLMS InitiateRequest APDU）传递给 xDLMS ASE,xDLMS ASE 检索此 APDU 的参数，然后将控制权交还给 CF。

CF 使用收到的 APDU 参数生成 COSEM-OPEN.indication 给服务器 AP ，并进入“ASSOCIATION PENDING”状态。

总结：先 xDLMS ASE 层打包，再 ACSE 层打包，得到 AARQ APDU。AARQ APDU 先 ACSE 层解包，再 xDLMS ASE 层解包

IDIS 8.2.2.7 Associations on different communication ports:
一个本地通信端口(IEC 62056-21，红外)同时仅允许打开一个 AA
一个远程通信端口(IP)同时允许打开多个 AA
不同通信端口可以同时分别打开 AA
如果客户端希望同时使用多个通信端口，则必须在每个通信端口分别打开对应的 AA。（比如不能在 IP 通道打开 AA 后用于红外通道的数据通信）
Synchronization of Internal memory access must be handled by the manufacturer.（不太理解，推测是：为了实现上面几条需要的不同通信端口间的内部信息同步有厂家自行实现）

s9.4.4.2 Repeated COSEM-OPEN service invocations

AA 已经存在时，client AP 发的 COSEM-OPEN.request 直接由 client AL 回应确认

server AL 收到和已经存在的 AA 关联的 AARQ APDU 时，可以选择直接忽略，也可以选择返回一个 exception-response APDU（见9.4.6.14）.

s9.4.4.3 Establishment of unconfirmed application associations

Service_Class == Unconfirmed

本地 AL 不等待回应直接回.confirm

一般用于单向通信或广播

无需确认 AA 中只能使用无需确认 xDLMS 数据传输服务

s9.4.4.4 Pre-established application associations

预连接 AA 的目的是简化数据交换。

不需要 COSEM-OPEN 和 COSEM-RELEASE 服务的 AA 建立和释放阶段，只使用数据传输服务。

预连接 AA 在整个电表生命周期内总是存在。逻辑设备包含一个用于预连接 AA 的 Association LN / SN 接口对象。

预连接 AA 可以是 confirmed，也可以是 unconfirmed。预连接 AA 不能释放。

IDIS 8.2.2.3 Pre-established Association:
预连接应用上下文：
max receive pdu_size= 1224 (和 IPv6 MTU 相关)
max send pdu size= 1224
DLMS version nr= 6
Quality of service= not used
Ciphering info= not used
Conformance= SET, ACTION, DATA-NOTIFICATION, GENERAL-BLOCK-TRANSFER, GENERAL-PROTECTION, ACCESS
Application context name= Logical_Name_Referencing_With_Ciphering
Security setup reference= 0-0:43.0.0.255

s9.4.5 Protocol for application association release

优雅 graceful 方式
- 断开 AL 的支持协议层
  前提是面向连接的协议层（HDLC,TCP）
  the COSEM-RELEASE，Use_RLRQ_RLRE参数不存在或为FALSE(就是不使用 ACSE 的A-RELEASE服务，见 9.3.3)
- 使用 ACSE A-Release 服务
  Use_RLRQ_RLRE参数为TRUE（就是使用 ACSE 的A-RELEASE服务），COSEM-RELEASE 服务可以包含加密的xDLMS InitiateRequest / InitiateResponse 在 RLRQ / RLRE APDUs 的user-information参数中，从而防止潜在的拒绝服务攻击(没有保护的话谁都可以断开连接)。
非优雅 Non-graceful 方式
当 AP 发生意外事件(如检测到物理连接中断)时，检测本地错误，等等

s9.4.6 Protocol for the data transfer services

s9.4.6.1 Negotiation of services and options – the conformance block

一致性块，用于协商双方支持的功能

COSEM-OPEN服务中：xDLMS InitiateRequest APDU 中的proposed-conformance参数和 xDLMS InitiateResponse APDU 中的negotiated-conformance

图中提到了只有 get、set、action 可以配置为使用 block-transfer,应该就是 service-specific block transfer，和 9.4.6.6 ACCESS 服务不支持 service-specific block transfer 相符

IDIS 8.2.1 Minimal set of services
至少支持 Logical name services。以下为最小功能支持集：
General-protection (1)
General-block-transfer (2)
Block-transfer-with-get (11)
Block-transfer-with-set (12)
Multiple-references (14)
Data-Notification (16)
Access (17)
Get (19)
Set (20)
Selective-access (21)
Action (23)
For the multiple references services, a minimum of 16 references must be supported by the GET request service and by the ACCESS request service. For the Set and Action service, the minimum is limited to one. TODO: 应该是指 with-list 服务最小支持的数量。
不支持组合多种块传输机制(比如 GBT 嵌套服务特定分包)
Public client(016):
Use Cases
Reading basic device configuration information (e.g. SAP, COSEM logical device name, association, serial nrs, …)
mandatory Services supported by a Server
Block-transfer-with-get
Get
General-block-transfer
Access
Behavior
Accessible via remote communication and via local interface.
No security; i.e. the COSEM client may access the meter with: LOWEST SECURITY ( Logical_Name_Referencing_NoCiphering, Security policy 0, COSEM_lowest_level_security_mechanism_name(0) ), independent of the value of the attribute security_policy of object “security setup”.
Get service only to a limited set of attributes
Must be established by the client using the AARQ service
Closing HDLC (optical): on explicit closure, on timeout, on power-down, or on release request.
Closing remote communication: on explicit closure, on power-down, or on inactivity_time_out (comp. TCP/UDP setup object) or on release request.
Management Client(001)
Use Cases
Management of the device
Retrieving data
Authorized actions in the meter
mandatory Services supported by a Server
Block-transfer-with-get
Block-transfer-with-set
Get
Glo-get
Set
Glo-set
Multiple-references
Selective Access
Action
Glo-action
General-block-transfer
General-protection
Access
Behavior
Mandatory on remote communication and on local port
Supports basic communication from the HES to the meter
Must be established by the client using the AARQ service
HLS (backup LLS)
Closing HDLC (optical): on explicit closure, on timeout, on power-down, or on release request.
Closing remote communication: on explicit closure, on inactivity_time_out (comp. TCP/UDP setup object) or on release request.
Pre established client(102)
Use Cases
All unconfirmed application layer servicese.g.: Broadcasting time, image transfer, TOU tables, load control (scheduled or spontaneous), confirmed and unconfirmed push services
mandatory Services supported by a Server
Set
Glo-set
Glo-action
Action
Data-Notification
General-block-transfer
General-protection
Access
Behavior
Not available on local port
Client suited to support broadcast with encryption and authentication (application context must be completely defined)
Mandatory on remote communication
No LLS, no HLS
Always established (triggered by power-up)
Limited set of access services to a limited set of objects

s9.4.6.2 Confirmed and unconfirmed xDLMS service invocations

我们将 AA 分为 confirmed 和 unconfirmed 方式，将 xDLMS 服务请求也分为 confimed(需要回复) 和 unconfirmed(无需回复) 方式

client 端发起：
- 在confirmed的 AAs 中
  可以以 confirmed or unconfirmed 的方式调用 xDLMS 服务。
- 在unconfirmed的 AAs 中
  只能以 unconfirmed 的方式调用 xDLMS 服务。这样，在多播和/或广播的情况下，由于潜在的多重响应而产生的冲突可以避免。
对于 unconfirmed xDLMS 服务（组播和广播必须使用）的三种目的地址，服务端接收到时的行为：
- 单个地址：如果已建立 AA(无论confirmed还是unconfirmed) 则保留，否则丢弃
- 组播地址：同上
- 广播地址：同上
service 端发起：
unsolicited services：
- InformationReport
  只能以 unconfirmed 方式调用
- EventNotification
  只能以 unconfirmed 方式调用
- DataNotification
  三种执行方式：
  - unconfirmed，支持协议层失败重试;
  - unconfirmed，丢失支持协议层确认重试;
  - confirmed，丢失(应用层)确认重试
  详见 9.4.6.7

如果服务器 AL 无法处理已确认的服务请求（例如，接收请求时未首先建立 AA 或请求有其他错误），服务器 AL 要么丢弃该请求，要么在可能的情况下用confirmedServiceError APDU做出响应(仅用于响应 AARQ 内的InitiateRequest, 以及 SN 服务中的ReadRequest and WriteRequest)，或者在执行时用 ExceptionResponse APDU 做出响应。这些 APDU 可能包含有关无法处理请求原因的诊断信息。它们在 9.5 中定义。

s9.4.6.3 Protocol for the GET service

有多个属性的情况下，每个属性都要回对应的 Data 或 Data_Access_Result

通过conformance block协商在APDU过长时是否使用GBT或service-specific block transfer

结合 9.3.6 对 GET 的说明，AP 负责 Data 的编解码，同时可以对Data进行分块，也就是 service-specific block transfer 的基础。其中分块可以是按字节不按逻辑分，也可以按逻辑分(每块都能自解析)。这样的话服务端就可以分段生成回复，对于已经发送的块可以释放内存，减少内存占用

假设需要响应的结果是一系列字节：$B_1$, $B_2$, $B_3$,…., $B_N$。服务器可在收到请求后生成完整的响应，也可动态生成（即时生成）。

服务特定分块发送接收流程：
第一个响应的 DataBlock_G(见 9.3.7)：
- Last_Block == FALSE;
- Block_Number == 1;
- Result (Raw_Data) == the first K bytes of the encoded data: $B_1$, $B_2$, $B_3$,…., $B_K$.
其中起始 Block_Number 可以任意指定，但推荐为 1。
客户端 AP 继续发送 GET-REQUEST-NEXT 请求,其中Block_Number和上一次接受到的响应相同，也就是 1（可以理解为客户端确认序号，表示 1 已确认，确认被带在请求里，所以最后一包将不再确认）。服务端 AP 收到请求后继续发 Block_Number 为 2 的块
在整个流程中，每次的 Invoke_Id 和 Priority 参数都应相同。
各种错误处理
- a) 如果服务端 AP 无法响应“GET-REQUEST-NEXT”（无论任何原因），服务端 AP 发送 GET-RESPONSE-LAST-BLOCK， DataBlock_G 结构参数为：
  - Last_Block == TRUE;
  - Block_Number == 客户端确认的块序号 +1;
  - Result == Data_Access_Result，表示失败的原因。
- b) 如果客户端发送的 GET-REQUEST-NEXT 的 Block_Number 参数和服务端上一次响应的块序号不同。则视为未确认成功，服务端将其视为客户端否认本次传输，并发送 GET-RESPONSE-LAST-BLOCK， DataBlock_G 结构参数为：
  - Last_Block == TRUE;
  - Block_Number == 客户端发送过来的块序号;
  - Result == Data_Access_Result，long-get-aborted。
- c) 如果服务端在全部响应完毕后收到客户端发送的 GET-REQUEST-NEXT，服务端发送 GET-RESPONSE-LAST-BLOCK， DataBlock_G 结构参数为：
  - Last_Block == TRUE;
  - Block_Number == 客户端发送过来的块序号;
  - Result == Data_Access_Result，no-long-get-in-progress。
- d) 如果服务端响应的 Block_Number 不等于客户端期望的(发送的 Block_Number+1)，客户端阻止本次传输（后续流程见b）。
如果在上述出错情况下，服务器因故无法调用 GET-RESPONSE-LAST-BLOCK 服务基元，则应调用 GET-RESPONSE-NORMAL 服务基元，并使用 DataAccess-Result 参数指明失败原因。服务器应发送 Get-ResponseNormal APDU。

NEXT 请求序号与上一条回应序号不匹配

s9.4.6.4 Protocol for the SET service

支持客户端分块请求

即使分块，每一块的 Invoke_Id 和 Priority 必须是一样的，因为是同一个请求

多了 ACK-BLOCK，用于中间块的接收响应

发送服务特定分块请求：
- SET 发送的 SET-REQUEST-FIRST-BLOCK 或 SET-REQUEST-FIRST-BLOCK-WITH-LIST 中的 DataBlock_SA 与 GET 响应的 DataBlock_G 的参数相同。
- 服务端响应的 ACK-BLOCK 类似于 GET 服务中客户端发送的 GET-REQUEST-NEXT
各种错误处理：
- 服务端因故无法处理收到的数据块。在这种情况下，服务端 AP 应酌情调用 SET-RESPONSE-LAST-BLOCK 或 SET-RESPONSE-LAST-BLOCK-WITH-LIST 服务基元。结果参数表示终止传输的原因；
- 客户端发送的 SET-REQUEST-ONE-BLOCK 请求中的 Block_Number 参数不等于服务端所期望的数据块编号（上一次收到的编号 + 1）。服务端将此理解为客户端希望中止正在进行的传输。在这种情况下，服务器 AP 应根据情况调用 SETRESPONSE-LAST-BLOCK 或 SET-RESPONSE-LAST-BLOCK-WITH-LIST 服务基元，其结果参数 Data_Access_Result == long-set-aborted；
- 当没有更多数据传输时（服务端已收到一整个请求中所有的块），如果服务端收到一个 Set-Request-With-Datablock APDU，服务端 AP 应调用结果参数 Data_Access_Result == no-long-set-in-progress 的 SET-RESPONSE-LAST-BLOCK 服务基元。
如果在上述出错情况下，服务端由于某种原因无法调用 SET-RESPONSE-LASTBLOCK 服务基元，则会调用一个 SET-RESPONSE-NORMAL 服务基元，并使用 DataAccess-Result 参数指明失败原因

s9.4.6.5 Protocol for the ACTION service

请求响应都能分包，请求发完(LAST-BLOCK)，再由响应分包。

第一阶段的请求分包类似于 SET 服务，错误处理也同 SET 服务
第二阶段的响应分包类似于 GET 服务，错误处理也同 GET 服务

s9.4.6.6 Protocol for the ACCESS service

ACCESS 不支持 service-specific block transfer，见 9.4.6.1，一致性块不包含该功能，就是不支持，所以文中只给了 GBT 的例子，

图中的 FIRST 和 LAST 是partial service invocations部分服务调用（FIRST-PART,LAST-PART），不是 service-specific block transfer

TODO:在这个例子中为什么客户端 AL 可以在不知道对方接收窗口的情况下发送 W=3 的 GBT，如果按照 AL 层的 GBT 参数必须由 AP 提供来看应该是错误的更新：图片前有条件说明，Both parties know a priori that the other party supports streaming with window size = 3,已经知道是三个包

有个要注意的是对于GET\SET\ACTION\ACCESS,客户端总是作为主动方，也就是管理重发的角色。服务端发出去的都不需要客户端回确认，超时也不重发

s9.4.6.7 Protocol of the DataNotification service

可以使用partial service invocations

可以使用 GBT

有以下三种重试策略：

unconfirmed Service Class，支持协议层失败重试
AP 向 AL 上报后不计时，等到 AL 回复发送失败(支持协议层错误)时开始计时并在等待一定时间后重发
unconfirmed Service Class，丢失支持协议层确认重试
AP 向 AL 上报后即开始计时，除非 AL 回复成功(支持协议层成功)，否则计时超时就开始下一次重发
confirmed Service Class，丢失(应用层)确认重试
AP 向 AL 上报后即开始计时，除非对方 AP 回复确认(无视支持协议层错误或成功)，否则等计时超时就开始下一次重发

s9.4.6.8 Protocol for the EventNotification service

详见 10

s9.4.6.9 Protocol for the Read service

s9.4.6.10 Protocol for the Write service

s9.4.6.11 Protocol for the UnconfirmedWrite service

s9.4.6.12 Protocol for the InformationReport service

SN 相关的跳过

s9.4.6.13 Protocol of general block transfer mechanism

block transfer块传输总结：

Partial service invocations，9.3.5，用于本地 AL 和 AP 通信时的分包，在 GBT 和加密中才需要使用，按逻辑分包，非字节分包。猜测因为 GBT 或通用加密是流式的，AL 和 AP 通信时必须使用完整的服务原语，所以接收时可能需要由 AL 判断是否已经接收到 AP 可以识别的一部分并可以向 AP 发送了，不过这个判断的条件还不太明确。
service-specific block transfer，9.3.5，用于远程 AP 间通信，由每种 xDLMS 服务自行定义。
general block transfer，用于远程 AL 间通信，由 AP 提供窗口和流参数，但如果没有参数会不会也触发 GBT 有待讨论.AA 握手时 AL 会保存相关参数，见 9.3.2.2 table 54

由 AL 层实现，使用General-Block-Transfer (GBT) xDLMS APDUs传输任意长度APDUs

AL 收到 AP 层.request / .response 服务原语：

打包 APDU
根据 Security_Options 打包加密 APDU
如果大于协商的最大 APDU 大小，使用 GBT 分包

区别于 AP 层的partial service invocations部分服务调用(9.3.5)，这个GBT是针对 APDU 的，两者没有直接关系

原语参数：

Block_Transfer_Streaming (BTS):用于 AP 指示 AL 是否可以用流方式(窗口)发送，（窗口的意思就是每发若干个包确认一次，结合 BTW 若为 0，表示无需确认，若为 1，表示 1 个包确认一次）
Block_Transfer_Window (BTW)：用于 AP 指示 AL最大流窗口大小，但最终由 AL 决定，AL 可以设置的很小用于传输丢失包。

unconfirmed services固定 Block_Transfer_Streaming 为FALSE，以及 Block_Transfer_Window 为0.类似 UDP，可以尽可能的发，无需对方 AL 层确认

GBT APDU 字段：

the last-block (LB) ：是(LB = TRUE(1))否最后一包
streaming(STR) :对于一个窗口，在过程中(STR = TRUE(1))还是已结束(STR = FALSE(0)，一个窗口内的最后一包)。如果是已结束，需要对方回个确认，这个确认是对这个窗口的，如果是完整 APDU 的最后一包则不回(最后一个窗口不确认)
TODO:怎么判断收全了更新：通过发送权思路，就是谁是主动方，谁负责报文的送达确认，这里接受方是主动方，如果没收全，会在超时时重发请求，发送端无需保证自己的报文送达
window：发送该 APDU 的一方的接收窗口大小，发送unconfirmed services时为 0
block-number (BN)：block序号，第一个为 1
TODO:具体什么时候开始重新计数更新：应该是last-block的时候，也就是一个完整的APDU发送完成后
block-number-acknowledged (BNA)：被确认块号，最后一个连续的被确认的块的块号（这个块之前的所有块也要已经被确认。这个是用于指示对方发送的块的确认，表明自己已确认）
block-data (BD):数据域，xDLMS APDU 的一部分

s9.4.6.13.2 The GBT procedure

Send Queue SQ： :发送队列，对于 block :每收到AP调用原语，(和 partial service invocations 无关，不管 Invocation_Type 参数为 COMPLETE, FIRST-PART, ONE-PART or LAST-PART 等)，就分成一个或多个 blocks 放进 SQ 中 :对于 SQ 内 blocks 的发送是个流过程（TODO:意思是不是已经和调用原语无关了更新：与调用原语无关，也就是和 partial service invocations 无关）

Receive Queue RQ :接收队列，对于 block

s9.4.6.13.3 GBT procedure state variables

Gr: 接收到的对方参数
Gs: 发送的自己的参数
BNApeer：自己的发送被对方确认的数量，（被 Gr.BNA 修改）
BNAself：对方的发送被自己确认的数量，（发给对方）
NextBN：自己 SQ 发送队列的下个插入序号，（插入 SQ 时递增）
STRpeer：对方是否支持 GBT 流，（被 Gr.STR 修改）
STRself：自己是否支持 GBT 流，（被本地 AP 修改）
Wpeer：对方接收窗口大小，（被 Gr.W 修改）
Wself：自己接收窗口的大小，（被本地 AP 修改）

TODO:其中 Wself 有默认值，是不是不需要 AP 提供，也可以有默认值更新：有默认值的参数不需要 AP 提供也能使用，初始值就是默认值

子过程：

9.4.6.13.4 Send GBT APDU stream
- Confirmed GBT stream send
  AP 调用原语参数BTW要大于 0，SQ 为空时填充一个空的 block,NextBN 递增
  - 9.4.6.13.4.3.2 Last block management
    最后一包管理。
    - confirmed client-server services
      客户端发送请求，LB=0，直到最后一包，LB=1。此时SQ应该空了，如果收到服务端响应，需要向SQ填充空的确认包，再发送，此时LB=1，如此重复。(如果服务端的 LB=1 这包丢了，就等超时后重复请求，直到收到服务端 LB=1 的包)
      服务端发送LB=0，直到收到客户端LB=1的包（请求发完后以及确认包的LB都为1）且是服务端的最后一包，发送LB=1，服务端等待超时无请求后退出 GBT
    - unsolicited, confirmed service
      该服务类型为需确认的上报
      服务端发送上报 LB=0 直到发送最后一包 LB=1，等待客户端响应 LB=1，如果没有，等待超时后重复上报，直到收到后退出 GBT。
      客户端发送确认和响应都是LB=0，直到收到服务端LB=1且客户端已经发送完最后一包，客户端发送 LB=1，客户端等待超时未接收数据后退出 GBT。
    总结：谁主动发起，谁负责保证 GBT 完成。第一种情况中 client 主动发起，它负责接收到服务端的 LB=1 才能退出，否则要重发。server 端作为被动方如果一段时间没收到数据则自行退出。
  TODO:9.4.6.13.4.3.1 If the SQ is empty, an empty block is added to the SQ and Nex tBN is incremented.为什么要加入空的 block,这个空的好像是确认包更新：9.4.6.13.4.3.2 Last block management中提到了如果客户端把请求的APDU全发完了，那发送队列就空了，这时候还需要对服务端的响应回确认，所以还需要空的block。或者当服务端在接收请求回确认时SQ也是空的，需要填充确认包
  Gs.LB = B.LB, Gs.STR = STRself, Gs.W = Wself, Gs.BN = B.BN, Gs.BNA = BNAself and Gs.BD = B.BD
  每个窗口最后一包以及LB=1时的包的Gs.STR都为0
  被确认后才能从 SQ 删除，最后一包不需要对方确认，所以不能直接从 SQ 中删除。
  TODO:应该什么时候删除，文中也没说，是否是超时
- Unconfirmed GBT send
  AP 调用原语参数BTW要等于 0
  全部发完就清空 SQ，不用确认
9.4.6.13.5 Process GBT APDU sub-procedure
这个过程是接收一个窗口的过程
1. 判断GBT APDU是否被对方拒绝（是不是表明参数不合理）
2. 如果收到的是Gr.BN=1且Gr.BNA=0，表示是初始化包，是由对方发起的GBT过程，需要初始化（是不是就是向AP请求参数）
3. 是否是confirmed service
- 9.4.6.13.5.2 Processing GBT APDUs in a confirmed GBT procedure
  1. 判断合法性后将B放入RQ接收队列
  2. 配置窗口和对方确认序号，Wpeer = Gr.W, BNApeer = Gr.BNA
  3. 清空确认序号之前的SQ发送队列数据(已经确认)
  4. RQ内数量是否等于BTW（BTW是AP给的接收窗口大小上限，相等说明一个窗口满了），是的话说明一个窗口接收结束，否的话说明还有后续block
  5. 判断STRpeer，如果为0表示即使没有到窗口上限，该（流）窗口也结束了，为1表示该窗口还有后续block
  6. （一个窗口结束需要回确认）
  RQ中的报文回给AP，需要调用Check RQ and fill gaps sub-procedure.
- 9.4.6.13.5.3 Processing GBT APDUs in an unconfirmed GBT procedure
  1. 判断合法性后将B放入RQ接收队列
  2. 如果达到RQ上限，则结束（虽然没有窗口的概念，但RQ也有上限，达到上限强制中断）
  3. 如果是最后一包LB=1则结束，如果不是则等待下一包
  如果在结束后收到新的包，将视为overflow，直接丢弃，本次结果回给AP层后，清空RQ，本次GBT结束
9.4.6.13.6 Check RQ and fill gaps
- 9.4.6.13.6.2 Confirmed GBT procedure
  1. RQ为空时全部重传，Wself（接收窗口大小）设置为BTW也就是最大窗口
  2. RQ不为空时检查gaps，为空时表示无需重传，BNAself(己方确认)设置为B.BN(确认最后一包);不为空时表示还有需要重传的，此时Wself应设置为小于等于要重传的第一个gap大小（比如只丢了一个包或者说第一个gap只需要重传一个包，就重传一个包，接收窗口设为1就行，这样只要提供起始序号和窗口大小，对方就知道要补几个包了），开始请求重传。
  gap(缺口)可以理解为一个连续的丢包块
  比如1x2x3√4x5√6√7√
  第一个gap大小就是2，第二个gap大小就是1
- 9.4.6.13.6.3 Unconfirmed GBT procedure
  没有重传机制，没收全就是失败。

s9.4.6.13.7 GBT protocol examples

TODO:图里的 GET.cnf NORMAL(FIRST-PART)是否是一种 AL 向 AP 请求 GBT 参数的机制，前提是 AL 不知道相关的参数，所以 GET.req NORMAL(COMPLETE)其实是个空的报文？结合 9.3.5 Additional service parameters，这个参数是否应该在这个原语里携带。更新：the client AP invokes a GET.request NORMAL service primitive, without additional service parameters. The client AL sends the request in a Get-Request-Normal APDU 明确提到了 GET 相关原语可以携带 Additional service parameters。所以这里就是请求 GBT 参数，因为对方发起了 GBT ，AL 需要 AP 的许可来使用 GBT 发送。

可以只补单个包，此时请求的 W 置 1，BNA 置 3，表示窗口大小变为 1，就是单个确认。然后 BNA 为 3 表示让对方补第 4 个包。

TODO:如果 4、5 两包都丢了，是不是就是先补 4，再补 5，不会两包一起补。更新：如果 4、5 丢了，就 W 置 2，BNA 置 3，可以表示丢了连续的两个包

如果是最后一包 LB=1 的丢了，由客户端请求这一包

TODO:为什么 Action-Request-With-List 收到一半，服务端就可以回 Action-Response-With-List 更新：应该是一个错误，没有收全时是无法回复完整的，这里回个确认（空 BD）比较合理

s9.4.6.13.8 Aborting the GBT procedure

GBT 终止条件：

收到专用于终止命令的 GBT APDU： LB = 1, STR = FALSE, BN = 0 and BNA = 0;
开始新的 GBT 过程。收到 BN = 1 and BNA = 0;
收到 GBT 服务以外的 APDU
confirmed 服务超时未收到确认

无法终止 GBT with unconfirmed DataNotification

s9.4.6.14 Protocol of exception mechanism

exception-response APDU 回应 GET, SET, ACTION and ACCESS services 表示无法处理的错误

TODO:错误是 AL 层直接打包还是 AP 层来通知的更新：结合上下文，是 AL 层生成的

s9.5 Abstract syntax of COSEM PDUs

asn.1 格式描述文档

pdf 格式

s9.6 COSEM PDU XML schema

xml 格式描述文档

s10 Using the DLMS/COSEM application layer in various communications profiles

s10.1 Communication profile specific elements

在 DLMS/COSEM 中，只有COSEM-OPEN服务具有特定的通信配置文件参数。它们的值和用途被定义为通信概要文件规范的一部分。

s10.2 The 3-layer, connection-oriented, HDLC based ommunication profile

s10.2.2 The structure of the profile

应用层：DLMS/COSEM AL，章节 9
链路层：基于 HDLC 标准的，章节 8
物理层：章节 5，光口和本地回环物理接口见章节 6

s10.2.3 Identification and addressing scheme

Data Link SAP-s 提供服务给 AL

客户端：只要定义客户端 AP，物理地址由 PhL 层填充

服务端：因为多点网络寻址的原因，所以目的地址需要物理设备地址加上逻辑设备地址。

例子：Client_01 (HDLC address = 16) and Server 2 in Host Device 02 (HDLC address = 2392)，客户端地址为 16，服务端地址为 2392，23 为 upper 地址，92 为 lower 地址

s10.2.4 Supporting protocol layer services and service mapping

DL 层连接管理
面向连接数据传输
无连接数据传输

DL-CONNECT 和 DL-DISCONNECT 也是由 AL 管理的，用于 AL 在收到 COSEM-OPEN.request 调用时开启 DL 连接，PhL 层的连接是 AP 管理的，不是 DL 层管理的

s10.2.5 Communication profile specific service parameters of the DLMS/COSEM AL services

COSEM-OPEN 携带 Communication profile 的参数

Protocol (Profile) Identifier 3-Layer, connection-oriented, HDLC based;
Server_Lower_MAC_Address (COSEM Physical Device Address);
Server_Upper_MAC_Address (COSEM Logical Device Address);
Client_MAC_Address;
Server_LLC_Address;
Client_LLC_Address.

也就是 HDLC 及 PhL 的地址也是 AP 管理的

s10.2.6 Specific considerations / constraints

s10.2.6.1 Confirmed and unconfirmed AAs and data transfer service invocations, frame types used

Confirmed AARQ 用 I 帧携带

Unconfirmed AARQ 用 UI 帧携带

当通过网关访问服务端时，COSEM APDUs 总是使用I帧携带，包括 Unconfirmed 的 APDU 也是，此时服务端必须通过 xDLMS InitiateRequest APDU 的response-allowed（见 9.4.2.1）或 Invoke-Id-And-Priority / Long-Invoke-Id-And-Priority 的service-class bit（用于指示是否为 confirmed 见 381 页）判断请求是否是 Unconfirmed,

s10.2.6.2 Correspondence between AAs and data link layer connections, releasing AAs

释放AA连接的方式是A-RELEASE服务或断开支持层连接，因为本配置文件不需要任何下层连接，所以断开支持层连接方式不可用，如果 A-RELEASE 服务也不支持，就没有别的方式释放连接

s10.2.6.3 Service parameters of the COSEM-OPEN / -RELEASE / -ABORT services

由于SNRM和DISC可以透明传输高层参数，COSEM-OPEN 和 COSEM-RELEASE 中的User_Information将会可用

s10.2.6.4 EventNotification service and protocol

事件上报时，服务端角色为 Management Logical Device（upper HDLC 地址 0x01）,客户端角色为 Management AP（upper HDLC 地址 0x01）

使用 UI 帧发送，发送机会在 8.4.5.4.7 说明了

当客户端检测到一个成功的物理连接建立——并且没有其他原因接收一个传入的调用——它就假定这个调用是由打算发送事件通知请求 APDU 的服务器发起的。

客户端必须首先使用第 5 章中描述的可选的协议识别服务(protocol identification service)读取通信协议栈

客户端发起 TriggerEventNotificationSending.request 原语，发送 UI 帧交出发送权，此时服务端才能上报

s10.2.6.5 Transporting long messages

HDLC 提供分段(Segmentation)服务来传输长消息，见 8.4.5.4.5

s10.2.6.6 Supporting multi-drop configurations

可以视为逻辑总线

冲突避免一般使用主从模型，由主站控制发送权限

上报时可能多个设备同时上报，需要解决两个问题：

总线上的冲突，冲突在物理层体现，由厂家解决（可以用 CSMA 之类的）
客户端不知道需要上报服务端的物理地址时，目的地址可以使用 CALLING Physical Device Address（只有要上报的客户端才会接受这个地址）

s10.3 The TCP-UDP/IP based communication profiles (COSEM_on_IP)

COSEM 物理设备通过 IP 地址唯一标识，区别于 HDLC 地址。逻辑设备 AP 识别需要额外的地址，由 wrap 层提供，wPort。AL 只监听一个 TCP/UDP 端口。

TCP TL 层提供的服务：

TCP connection manager AP:
- TCP-CONNECT.request, .indication, .response, .confirm;
- TCP-DISCONNECT.request, .indication, .response, .confirm;
DLMS/COSEM AL:
- TCP-DATA .request, .indication, (. confirm).

UDP TL 层提供的服务：

DLMS/COSEM AL:
- UDP-DATA .request, .indication, (.confirm)

TCP 连接的建立是独立于 DLMS/COSEM AP 的。

AP 能够在 COSEM-OPEN 前向 TCP 管理 AP 获取参数

Protocol_Connection_Parameters：

Protocol (Profile) Identifier – TCP/IP or UDP/IP;
Server_IP_Address – COSEM Physical Device Address;
Server_TCP_or_UDP_Port – The TCP or UDP port used for DLMS/COSEM, see 7.2;
Server_Wrapper_Port – COSEM Logical Device Address;
Client_IP_Address – COSEM Client’s Physical Device Address;
Client_TCP_or_UDP_Port – The TCP or UDP port used for DLMS/COSEM, see 7.2;
Client_Wrapper_Port – COSEM application process (type) identifier.

s10.3.6 Specific considerations / constraints

TCP 不支持使用 Unconfirmed AA,因为 TCP 不支持无连接访问，而 Unconfirmed AA 需要支持在不建立支持层连接情况下发送数据。两者矛盾

释放 AA 只能使用 RLRQ/RLRE，不能使用通过断开支持层方式，因为一个 TCP/UDP 端口承载所有AA，一旦断开，所有AA都会断开，必须通过 RLRQ/RLRE 有选择的断开。还有 UDP 是无连接的，不能通过断开支持层连接断开AA

User_Information 不可用

s10.3.6.6 Transporting long messages

wrapper层需要包含完整APDU。如需分块在 AL 层分块。

（就是 AL 调用 wrapper 服务时不支持分块）

s10.3.6.7 Allowing COSEM servers to establish the TCP connection

服务端发起 TCP 连接，长连接模式，适用于服务端没有公开地址可以连接时。

s10.4 The CoAP based communication profile (DLMS/COSEM_on_CoAP)

CoAP 可以提供可靠和不可靠服务

CoAP 支持通过 CoAP block transfer 服务来支持传输长的消息(APDU，类似于 10.2.6.5 Transporting long messages)，按照 MTU 合理分块后可以不用IP层再根据 MTU分片了，AL 也支持引用层的分块传输，根据对方 AL 层支持的接收大小 receiver_max_pdu_size

TODO:TCP/UDP IP 通信配置里好像没用到 UDP 支持广播的特性，可能是 UDP 广播只能在本地局域网中进行，不能跨路由器进行的原因

s10.4.3 Identification and addressing

CoAP URI：Uri-Host + Uri-Port + Uri-Path

发送端 AL 需要知道对方的CoAP URI和 SAP，由于 CoAP 封装了 UDP，所以不需要知道ip地址和端口，可能会动态变化

DLMS AE 通过唯一 systemtitle 标识，通过以下方式交换：(TODO:AE 是什么意思)

在明确建立 AA 的情况下，在 AA 建立期间使用 COSEM-OPEN 服务;
通过在“Security setup”对象写入 client_system_title 属性和读取的 server_system_title 属性。适用于预连接 AA
加密 APDU 交换，general-ciphering (originator and recipient system title)或 general-glo-ciphering (originator system title).

CoAP-DATA 原语需要包含对端的ip地址和端口，如果 IP 是静态的，那可以静态绑定到system title。如果是动态的，需要动态更新绑定，可以通过服务端 ip 变更自动推送实现

当客户端 AL 收到服务端上报 data 时，如果是动态 ip，客户端可以根据 system title 确认身份。

s10.4.4 Supporting layer services and service mapping

s10.4.6 Specific considerations / constraints

unconfirmed AA 不能传 confirmed 消息,Reliable 可靠 CoAP 传输层配置不能传输广播消息

CoAP 传输层无连接，不能通过断开传输层连接断开 AA,只能通过 RLRQ/RLRE 断开

s10.8 LPWAN profile

什么是 LPWAN？ LPWAN 技术有哪些？

LPWAN(低功耗广域网)，也称为 LPWA 或 LPN，是一种用于物联网(例如，以电池为电源的传感器)的类型，这是一种能够以低比特率进行远距离通信的无线网络。LPWAN 可以同时满足覆盖和续航的要求。以最小的功耗提供最长的距离覆盖是 LPWAN 最大的技术优势。

NB-IoT是物联网领域的一项新兴技术，支持广域网中低功耗设备的蜂窝数据连接。它也称为低功耗广域网(LPWAN)。NB-IoT 支持设备有效连接，待机时间长，对网络连接要求高。据称，NB-IoT 设备的电池续航时间可以提高到至少 10 年。
eMTC作为物联网的一种应用场景。它具有超可靠和低延迟的特点。eMTC 主要应用在设备之间的通信需求上。
Lora是一项专有技术， Semtech 为其提供芯片。Lora 技术改变了以往在传输距离和功耗之间的折衷，为用户提供了一个简单的系统，可以实现远距离、长续航、大容量，进而扩展传感器网络。

支持层固定使用了 UDP 和 IPV6

LPWAN 提供了低层加密和 SCHC压缩/解压和分段/重组功能

可以通过 DLMS/COSEM 对象配置 LPWAN 参数

传输层还有 AA 和 UDP 通信配置差不多

绿皮书没有介绍多少东西，基本都源于 RFC 8376，RFC 8724

s10.9 Wi-SUN profile

Wi-SUN Field Area Network (FAN)是一种基于IEEE 802.15.4的 IPv6 无线网状网络，专为关键基础设施项目设计。每个个人区域网络(PAN)被设计成用一个边界路由器支持数千个路由器设备。一个 FAN 可以由多个 pan 组成，允许单个网络扩展到数百万个设备，见图 196。

支持层固定使用了 UDP 和 IPV6，对传输层来说和 UDP profile 类似，wrapper 和 TCP-UDP/IP profile 相同

s10.10 Gateway protocol

Header
- 0xE6:请求（服务端发起 data notification 也算）
- 0xE7:响应
Network ID
目的网络 ID，可以理解为VLAN ID
Address length L
目的物理地址长度
Physical device address
目的物理地址

只有网关设备处理该报文

s11 AARQ and AARE encoding examples

s12 Encoding examples: AARQ and AARE APDUs using a ciphered application context

s13 S-FSK PLC encoding examples

s14 Data transfer service examples

s14.4 Profile generic IC buffer attribute encoding examples

压缩见蓝皮书4.1.6.3

s14.4.3 Get-response with Profile generic null-data compressed encoding example

profile 支持使用空值 null-data 压缩，支持压缩基本类型数据（除数组结构体）

s14.4.4 Get-response with Profile generic compact-array encoding example

使用 compact-array 减少类型描述，也能压缩。

compact-array:

compact-array                      [19]  IMPLICIT   SEQUENCE
{
    contents-description                [0]              TypeDescription,
    array-contents                      [1]   IMPLICIT   OCTET STRING
}

先声明类型，后面的数据就无需类型了，包括结构体和基本类型，后面的数据是 octet string 类型的

s14.4.5 Get-response with Profile generic null-data and delta-value encoding example

使用递增量压缩，如每次递增 0x29，就使用 1F 类型，值为 29，解压时为上条记录的值加上递增量

技术

本文由作者按照 CC BY 4.0 进行授权