DLMS Green Book
Uploaded by
stephenmunyiwamichaDLMS Green Book
Uploaded by
stephenmunyiwamicha 文章
DLMS Green Book 学习笔记
发表于 2022/04/19 • 更新于 2025/01/15
作者 Kai 293 分钟阅读
文章内容
s1 Scope
s3 Terms, definitions and abbreviations and symbols
s3.1 General DLMS/COSEM definitions
s4 Information exchange in DLMS/COSEM
s4.1 General
s4.2 Communication model
s4.3 Naming and addressing
s4.3.3 Addressing
s4.3.4 System title
s4.3.5 Logical Device Name
s4.4 Connection oriented operation
s4.5 Application associations
s4.5.2 Application context
s4.5.3 Authentication
s4.5.4 xDLMS context
s4.5.5 Security context
s4.5.6 Access rights
s4.6 Messaging patterns
s4.8 Communication profiles
s4.9 Model of a DLMS/COSEM system
s4.10 Model of DLMS servers
s4.11 Model of a DLMS client
s4.12 Interoperability and interconnectivity in DLMS/COSEM
s4.13 Ensuring interconnectivity: the protocol identification service
s4.14 System integration and installation
s5 Physical layer services and procedures for connection-oriented asynchronous data exchange
s5.1 Overview
s5.2 Service specification
s5.2.1 List of services
s5.2.2 Use of the physical layer services
s5.2.3 Service definitions
s5.3 Protocol specification
s5.3.1 Physical layer protocol data unit
s5.3.2 Transmission order and characteristics
s5.3.3 Physical layer operation – description of the procedures
s5.3.3.1 General
s5.3.3.2 Setting up a physical connection
s5.3.3.3 The Identification service
s5.3.3.4 Data transfer
s5.3.3.5 Disconnection of an existing physical connection
s5.4 example: PhL service primitives and Hayes commands
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.2.3 The DLMS/COSEM connection-less, UDP-based transport layer
s7.2.3.3.2 The wrapper protocol data unit (WPDU)
s7.2.4 The DLMS/COSEM connection-oriented, TCP-based transport layer
sTCP-CONNECT
sTCP-DISCONNECT
sTCP-ABORT
sTCP-DATA
s7.2.4.3 Protocol specification for the DLMS/COSEM TCP-based transport layer
s7.2.4.3.5 Definition of the procedures
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
s7.2.5.4 Data transfer using the TCP-DATA service
s7.3 The DLMS/COSEM CoAP based transport layer
s7.3.2 Overview
s7.3.3 Structure of the DLMS/COSEM CoAP transport layer
s7.3.3.2 Identification and addressing
s7.3.3.2.2 DLMS/COSEM AL identification within the CoAP transport layer
sDLMS/COSEM CoAP transport layer SAPs
s7.3.4 Service specification for the DLMS/COSEM CoAP transport layer
s7.3.4.2 The DLMS/COSEM CoAP-DATA service primitives
s7.3.4.2.1 CoAP-DATA.request
s7.3.4.2.2 CoAP-DATA.indication
s7.3.4.2.2 CoAP-DATA.confirm
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)
s7.3.5.3 The DLMS/COSEM CoAP Wrapper Protocol Data Unit (CWPDU)
s7.3.5.4 The Constrained Application Protocol (CoAP)
s7.3.5.4.2 The CoAP Message
s7.3.5.4.3 CoAP retransmission and response piggybacking
s7.3.5.4.5 CoAP Block Transfer
s7.3.5.5 Error Handling
s7.3.5.5.2 CoAP protocol layers
s7.3.5.5.3 CoAP wrapper layer
s7.3.5.5.4 Propagation of errors through CoAP wrapper layer
s7.3.5.6 DLMS/COSEM CoAP TL confirmations
s7.3.5.7 CoAP wrapper state machine
s7.3.5.7.2 CoAP DLMS/COSEM wrapper request/response context
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
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
s7.3.6.4 Unreliable DLMS/COSEM CoAP TL operation
s7.3.6.5 DLMS/COSEM CoAP Block Transfer operation
s7.3.6.6 DLMS GBT operation over DLMS/COSEM CoAP TL
s8 Data Link Layer using the HDLC protocol
s8.1 Overview
s8.1.2 Structure of the data link layer
s8.1.3 Specification method
s8.2 Service specification
s8.2.2 Setting up the data link connection: the DL-CONNECT and MA-CONNECT services
s8.2.2.2 DL-CONNECT.request and MA-CONNECT.request
s8.2.2.3 DL-CONNECT.indication and MA-CONNECT.indication
s8.2.2.4 DL-CONNECT.response and MA-CONNECT.response
s8.2.2.5 DL-CONNECT.confirm and MA-CONNECT.confirm
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
s8.2.3.3 DL-DISCONNECT.indication and MA-DISCONNECT.indication
s8.2.3.4 DL-DISCONNECT.response and MA-DISCONNECT.response
s8.2.3.5 DL-DISCONNECT.confirm and MA-DISCONNECT.confirm
s8.2.4 Data transfer: the DL-DATA and MA-DATA services
s8.2.4.2 DL-DATA.request and MA-DATA.request
s8.2.4.3 DL-DATA.indication and MA-DATA.indication
s8.2.4.4 DL-DATA.confirm and MA-DATA.confirm
s8.2.5 Physical layer services used by the MAC sublayer
s8.2.5.4 Data transfer
s8.3 Protocol specification for the LLC sublayer
s8.3.2 LLC PDU format
s8.3.3 State transition tables for the LLC sublayer
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
s8.4.2 MAC addressing
s8.4.2.2 Address field structure
s8.4.2.3 Reserved special HDLC addresses
s8.4.2.4 Handling special addresses
s8.4.2.5 Handling inopportune address lengths in the server
s8.4.3 Command and response frames
s8.4.4 Elements of the procedures
s8.4.4.2 Transmission considerations
s8.4.4.3 HDLC channel states
s8.4.5 HDLC channel operation – Description of the procedures
s8.4.5.2 Data station characteristics
s8.4.5.3 Procedures for setting up and disconnecting the data link
s8.4.5.4 Procedures for data exchange
s8.4.5.5 Exception recovery
s8.4.5.6 Time-outs and other MAC sublayer parameters
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
s8.5.2 Fast frame check sequence (FCS) implementation
s8.5.3 16-bit FCS computation method
s8.6 Data link layer management services
s9 DLMS/COSEM application layer
s9.1 DLMS/COSEM application layer main features
s9.1.2 DLMS/COSEM application layer structure
s9.1.3 The Association Control Service Element, ACSE
s9.1.4 The xDLMS application service element
s9.1.4.2 The xDLMS initiate service
s9.1.4.3 COSEM object related xDLMS services
s9.1.4.3.2 xDLMS services used by the client with LN referencing
s9.1.4.3.3 xDLMS services used by the client with SN referencing
s9.1.4.3.4 Unsolicited services
s9.1.4.3.5 Selective access
s9.1.4.3.6 Multiple references
s9.1.4.3.7 Attribute_0 referencing
s9.1.4.4 Additional mechanisms
s9.1.4.4.2 Referencing methods and service mapping
s9.1.4.4.3 Identification of service invocations: the Invoke_Id parameter
s9.1.4.4.4 Priority handling
s9.1.4.4.5 Transferring long messages
s9.1.4.4.6 Composable xDLMS messages
s9.1.4.4.7 Compression and decompression
s9.1.4.4.8 General protection
s9.1.4.4.9 General block transfer (GBT)
s9.1.4.5 Additional data types
s9.1.4.6 xDLMS version number
s9.1.4.7 xDLMS conformance block
s9.1.4.8 Maximum PDU size
s9.1.5 Layer management services
s9.1.6 Summary of DLMS/COSEM application layer services
s9.1.7 DLMS/COSEM application layer protocols
s9.2 Information security in DLMS/COSEM
s9.2.2 The DLMS/COSEM security concept
s9.2.2.2 Identification and authentication
s9.2.2.2.1 Identification
s9.2.2.2.2 Authentication mechanisms
s9.2.2.3 Security context
s9.2.2.4 Access rights
s9.2.2.5 Application layer message security
s9.2.2.6 COSEM data security
s9.2.3 Cryptographic algorithms
s9.2.3.2 Hash function
s9.2.3.3 Symmetric key algorithms
s9.2.3.3.2 Encryption and decryption
s9.2.3.3.3 Advanced Encryption Standard
s9.2.3.3.4 Encryption Modes of Operation
s9.2.3.3.5 Message Authentication Code
s9.2.3.3.6 Key wrapping
s9.2.3.3.7 Galois/Counter Mode
s9.2.3.3.8 AES key wrap
s9.2.3.4 Public key algorithms
s9.2.3.4.2 Elliptic curve cryptography
s9.2.3.4.3 Data conversions
s9.2.3.4.4 Digital signature
s9.2.3.4.5 Elliptic curve digital signature (ECDSA)
s9.2.3.4.6 Key agreement
s9.2.3.5 Random number generation
s9.2.3.6 Compression
s9.2.3.7 Security suite
s9.2.4 Cryptographic keys – overview
s9.2.5 Key used with symmetric key algorithms
s9.2.5.1 Symmetric keys types
s9.2.5.2 Key information with general-ciphering APDU and data protection
s9.2.5.3 Key identification
s9.2.5.4 Key wrapping
s9.2.5.5 Key agreement
s9.2.5.6 Symmetric key cryptoperiods
s9.2.6 Keys used with public key algorithms
s9.2.6.2 Key pair generation
s9.2.6.3 Public key certificates and infrastructure
s9.2.6.3.2 Trust model
s9.2.6.3.3 PKI architecture – informative
s9.2.6.4 Certificate and certificate extension profile
s9.2.6.4.2 The X.509 v3 Certificate
s9.2.6.5 Suite B end entity certificate types to be supported by DLMS servers
s9.2.6.6 Management of certificates
s9.2.6.6.2 Provisioning servers with trust anchors
s9.2.6.6.3 Provisioning the server with further CA certificates
s9.2.6.6.4 Security personalisation of the server
s9.2.6.6.5 Provisioning servers with certificates of clients and third parties
s9.2.6.6.6 Provisioning clients and third parties with certificates of servers
s9.2.6.6.7 Certificate removal from the server
s9.2.7 Applying cryptographic protection
s9.2.7.2 Protecting xDLMS APDUs
s9.2.7.2.2 Security policy and access rights values
s9.2.7.2.3 Ciphered xDLMS APDUs
s9.2.7.2.4 Encryption, authentication and compression
s9.2.7.2.5 Digital signature
s9.2.7.3 Multi-layer protection by multiple parties
s9.2.7.4 HLS authentication mechanisms
s9.2.7.5 Protecting COSEM data
s9.3 DLMS/COSEM application layer service specification
s9.3.1 Service primitives and parameters
s9.3.2 The COSEM-OPEN service
s9.3.2.3 Use
s9.3.3 The COSEM-RELEASE service
s9.3.4 The COSEM-ABORT service
s9.3.5 Protection and general block transfer parameters
s9.3.6 The GET service
s9.3.7 The SET service
s9.3.8 The ACTION service
s9.3.9 The ACCESS service
9.3.9.1 Overview – Main features
9.3.9.1.5 Self-descriptive responses
9.3.9.1.6 Failure management
9.3.9.1.7 Time stamp as a service parameter
9.3.9.1.8 Presence of data in service primitives
s9.3.9.2 Service specification
s9.3.10 The DataNotification service
s9.3.11 The EventNotification service
s9.3.12 The TriggerEventNotificationSending service
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
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
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
s9.4.2.2 Registered COSEM names
s9.4.3 APDU encoding rules
s9.4.3.1 Encoding of the ACSE APDUs
s9.4.3.2 Encoding of the xDLMS APDUs
s9.4.3.3 XML
s9.4.4 Protocol for application association establishment
s9.4.4.1 Protocol for the establishment of confirmed application associations
s9.4.4.2 Repeated COSEM-OPEN service invocations
s9.4.4.3 Establishment of unconfirmed application associations
s9.4.4.4 Pre-established application associations
s9.4.5 Protocol for application association release
s9.4.6 Protocol for the data transfer services
s9.4.6.1 Negotiation of services and options – the conformance block
s9.4.6.2 Confirmed and unconfirmed xDLMS service invocations
s9.4.6.3 Protocol for the GET service
s9.4.6.4 Protocol for the SET service
s9.4.6.5 Protocol for the ACTION service
s9.4.6.6 Protocol for the ACCESS service
s9.4.6.7 Protocol of the DataNotification service
s9.4.6.8 Protocol for the EventNotification service
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
s9.4.6.13 Protocol of general block transfer mechanism
s9.4.6.13.2 The GBT procedure
s9.4.6.13.3 GBT procedure state variables
s9.4.6.13.7 GBT protocol examples
s9.4.6.13.8 Aborting the GBT procedure
s9.4.6.14 Protocol of exception mechanism
s9.5 Abstract syntax of COSEM PDUs
s9.6 COSEM PDU XML schema
s10 Using the DLMS/COSEM application layer in various communications profiles
s10.1 Communication profile specific elements
s10.2 The 3-layer, connection-oriented, HDLC based ommunication profile
s10.2.2 The structure of the profile
s10.2.3 Identification and addressing scheme
s10.2.4 Supporting protocol layer services and service mapping
s10.2.5 Communication profile specific service parameters of the DLMS/COSEM AL services
s10.2.6 Specific considerations / constraints
s10.2.6.1 Confirmed and unconfirmed AAs and data transfer service invocations, frame
types used
s10.2.6.2 Correspondence between AAs and data link layer connections, releasing AAs
s10.2.6.3 Service parameters of the COSEM-OPEN / -RELEASE / -ABORT services
s10.2.6.4 EventNotification service and protocol
s10.2.6.5 Transporting long messages
s10.2.6.6 Supporting multi-drop configurations
s10.3 The TCP-UDP/IP based communication profiles (COSEM_on_IP)
s10.3.6 Specific considerations / constraints
s10.3.6.6 Transporting long messages
s10.3.6.7 Allowing COSEM servers to establish the TCP connection
s10.4 The CoAP based communication profile (DLMS/COSEM_on_CoAP)
s10.4.3 Identification and addressing
s10.4.4 Supporting layer services and service mapping
s10.4.6 Specific considerations / constraints
s10.8 LPWAN profile
s10.9 Wi-SUN profile
s10.10 Gateway protocol
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
s14.4.3 Get-response with Profile generic null-data compressed encoding example
s14.4.4 Get-response with Profile generic compact-array encoding example
s14.4.5 Get-response with Profile generic null-data and delta-value encoding example
s1 Scope
1. 建模 : 包括设备的 接口模型 和数据识别规则;在 blue book 中定义
2. 消息 : 这涵盖了将接口模型 映射 到协议数据单元(APDU)的服务，以及这个 APDU 的 编码 。在本
中定义
green book
3. 传输 : 通过通信通道 传输消息 。在本 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 entities, )之间的通信进行
application processes( APs ) AEs
建模。AE 代表 AP 的 通信功能 。
AP 中可能有 多组 OSI 通信功能，因此 一个 可以用 多种 AP 来表示（比如一个 AP 可以使用 HDLC-
AEs
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 可以不对应 logical device。 每个 绑定一个
, client AP AP
Service Access Point( )，
SAP 位于 application layer( )层。也就是说 SAP 用于区分基于同一个
SAP AL
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
固定 字节 长，前 3 字节厂家 ID，和逻辑设备名相同，后面的 5 字节，应为 0-
8
999,999,999,999(0x0-0xE8D4A50FFF)
交换方式（见 10.4.3.3）：
通信配置注册过程
在明确建立 AA 的情况下，在 AA 建立期间使用 服务;
COSEM-OPEN
通过在“ ”对象写入 client_system_title 属性和读取的 server_system_title 属
Security setup
性。适用于预连接 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 )是一个客户端 和一个服务端 间的 逻辑连接 。可以使用 ACSE 服
AE AE
务建立，也可以是预连接的
一个 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
通信配置文件指定了 和建模 Application Process (AP) 的
DLMS/COSEM AL 数据模型 如何由较低
COSEM
的通信媒体特定协议层支持。
通信配置文件包括许多 协议层 。 每一层都有不同的任务并为其上层 提供服务 并使用其支持协议层
的服务。 客户端和服务器 使用最高协议层的服务，即
COSEM AP 的服务。 这是唯
DLMS/COSEM AL
一包含 COSEM 特定元素( )的协议层； 见 9.1.4。 任何能够提供 DLMS/COSEM AL 所需服
xDLMS ASE
务的层都可以支持它。 较低层的数量和类型取决于所使用的通信媒体。
s4.9 Model of a DLMS/COSEM system
设备被建模为 一组逻辑设备 ，托管在 单个物理设备 中。 每个逻辑设备代表一个服务器 AP，并对 设备
功能 的一个 子集 进行建模，这些功能子集可以通过其通信接口看到。使用 COSEM 对象对各种功能
进行建模。
数据采集系统 被建模为 一组客户端ap ，可以由 一个或多个物理设备 托管。每个客户端 AP 可能有 不同 的
角色和访问权限，由设备授予。
公共客户端 和 管理逻辑设备 APs 有一个特殊的角色，它们应该一直存在。
0x10 0x01
s4.10 Model of DLMS servers
IP based profiles:
由 DLMS/COSEM Transport layer( )支持，该 TL 由 internet TCP 或 UDP 层和一个包
DLMS/COSEM AL TL
装器(wrapper)组成。 包装器 的主要作用是适应 风格 的服务集，该服务集由 DLMS/COSEM TL 在
OSI
TCP 和 UDP 函数调用 之间 提供。它还为逻辑设备提供寻址，将它们 绑定 到一个称为包装器端口的
SAP 。 管理逻辑设备 总是绑定到包装器端口 。最后， 包装器 提供有关 APDU 传输 长度的信息 ，
0x01
以帮助对等端识别 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
客户端模型
使用 HDLC 或 IP-based TLs 提供的服务， 由 决定 使用哪种。
DLMS/COSEM AL AP
与服务器端不同，客户端的 HDLC 层提供的寻址只有 一个级别 ，即每个应用程序流程(AP)的服
务接入点(SAP)的级别。(也就是没有物理地址级别，见 ，原语参数中客户端地址只有一
8.4.2
个字节，就是 SAP 地址)
客户端 AP 和服务器端 AP 由各自的 识别，因此，客户端和服务器端 AP 之间的 可以由 一对
SAP 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 的数据传输服务（ .request /.indicat）
PH-DATA ；它绕过了其他协议层。建议在所有可以访
问 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 的 ASCII 值（大写）为 79，则二进制
O K
值 ，而 K 的二进制值为
01001111 。剩下的就是追加同步位。假设传输数据时首
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 发送 指令 ）–以与对等 PhL 实体建立物理连接。5.4 中给出了智能 Hayes 调制解调器
AT
情况下的这些动作的例子。
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
字节——PH-DATA 服务的 Data 参数——在传输前应以一个开始位和一个停止位完成。产生的
PHSDU
帧应该从起始位开始传输，首先是最低有效位，最低有效位标识为位 0，最高有效位标识为位 7。
s5.3.3 Physical layer operation – description of the procedures
s5.3.3.1 General
连接的建立和释放由 物理连接管理器 管理。任何希望使用 DLMS/COSEM 协议的 应在请求连接
AP 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 原语类似–取决于 物理连接类型 和使用的 调制解调器 ，并可能以 自主
方式 或由 本身 完成(该过程不需要 Physical connection manager process 参与)。
PhL
当主叫和被叫设备的 完成建立 （或 不建立 ）所需的物理连接时，它们使用
PhL PH-CONNECT.confirm
（主叫方）和 （被叫方）基元将结果通知服务用户实体。
PH-CONNECT.indicat
s5.3.3.3 The Identification service
用于客户端读取协议栈识别信息
可选的 识别服务 是一种 应用层面 （特别注意，应用层面）的服务。它的目的是让客户获得关于服务
器中实现的 协议栈 的信息。因此，它不使用整个协议栈；识别信息在 客户端 和 服务器 之间使AP AP
用 数据 服务 直接交换。如果在 多播 配置中使用了一个以上的服务器，客户端能够识别 每个
PhL data
服务器中的协议栈。
该服务在 后 CONNECTED 状态才能调用
PH-CONNECT
只能由 客户端 发起请求
IDENTIFY.request 请求识别信息
IDENTIFY.response IDENTIFY.response 消息由 服务器 调用，携带识别请求的 结果 ：
AP
协议标准
版本
修订信息
错误信息
在客户端，这是一个 IDENTIFY.confirm 原语。
IDENTIFY.request 包含 一个或三个 字节。为了保持一致性，它的发送应受到数据链路层的 时间
APDU
限制 （帧间和响应超时）。
当收到这 第一个字符 时，PhL 进入 “ 识别中 “状态，等待更多的字节或帧间超时(意味着消息的结
束)。
identify 识别阶段 过程：
如果在收到三个以上的字节之前检测到 消息结束 条件( 超时也算 结束标志)，PhL 将收到的 APDU
视为 APDU。它使用 PH-DATA.indicaton 原语将收到的字节发送到 （物理连接
IDENTIFY.request
管理器） ，并返回到 “ 等待接收 “状态，允许解决最终的错误。
AP
跳过 identify 识别阶段 ，直接进入 数据传输阶段 ：
另一方面，如果在收到 第四个 传入字节之前没有检测到 消息结束 的条件（因为
IDENTIFY.request 最大就是 3 字节，收到第 4 个字节还没有结束标志，说明就不是
IDENTIFY.request 了，同时要保证正确的数据 PDU 长度是大于 3 字节的） ，PhL 认为识别过程
已经结束，并进入 “ 数据传输 “状态。传入的字节应使用 PH-DATA.indicaton 服务发送至服务用
户的上层协议层。在 3 层的 CO、HDLC 的 COSEM 配置文件中，这是 MAC 子层。在这种连接
中，PhL 不能返回 到 识别阶段 。
有参数 Destination_process 表示数据发到哪一层去，默认为 NULL 表示发给物理层管理 AP，
PhL
进入数据传输模式后为其他值表示发给 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 发送 .request，物理层 PhL
PH-CONNECT
向 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 ：
收到来自服务器（计费设备）的 或其他（例如 NAK）报文后，将生成带有相应
ACK 2 Z 2 CR LF
结果参数的 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 只监听 一个 或 端口 。另一方面，如 4.9 和 DLMS UA 1000-1 所示， 一个物理设
AL UDP TCP
备 可能承载 多个 客户端或服务器 。包装器子层提供的 附加寻址 功能允许寻址这些 。
ap ap
包装 子层具有以下功能:
wrapper
它在 UDP/TCP 端口上提供了一个 额外的寻址 能力( );
wPort
它提供有关数据 传输长度 的信息。这个特性可以帮助发送方和接收方识别一个 完整的 APDU 的接
收，它可以在 多个 包 中发送和接收
TCP
的用户是 TCP Connection Manager Process，就是说
TCP-CONNECT and TCP-DISCONNECT services
TCP 连接和释放不是 AL 管理的，由专门的管理进程管的，当然 AL 也要了解 TCP 当前的连接状
态。
s7.2.3 The DLMS/COSEM connection-less, UDP-based transport layer
无连接 ，可实现 多播广播 ； 开销小
缺点： 不可靠 （可以由上层实现可靠，当然 DLMS AL 层不会这么做，但是 CoAP 协议是个例子，
基于 UDP 实现了可靠传输），无重复发送保护
.request 和.indication 服务原语是必需的。本地的.confirm 服务原语的实现是可选的。
Console
UDP-DATA.request
(
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length, Data
)
Console
UDP-DATA.indication
(
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
Console
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)
始终为 0x0001
version:
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
Console
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
Console
TCP-DISCONNECT.request
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address
)
TCP-DISCONNECT.request 用于断开请求
Console
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 )
Console
TCP-DISCONNECT.response
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Result
)
TCP 连接管理进程 不能拒绝 TCP 断开请求，表示远程断开 Reason == REMOTE_REQ
Console
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
Console
TCP-ABORT.indication
(
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Reason
)
由基于 DLMS/COSEM TCP 的 生成，用于向服务用户
TL 表示支持 TCP 连接的 非请求
DLMS/COSEM AL
中断 。
当收到此指示时， 应释放所有使用此 TCP 连接建立的 ，并应使用
DLMS/COSEM AL AAs COSEM-
服务原语向 COSEM AP 表明这一点。
ABORT.indivation
sTCP-DATA
Console
TCP-DATA.request
(
Local_wPort,
Remote_wPort,
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
Data 是 APDU
Console
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 生成，用于向服务用户 DLMS/COSEM 指示已从远
TL AL
程设备收到 xDLMS 。如果携带 APDU 的 TCP 数据包中的 Local_TCP_Port 和 Local_wPort 参数
APDU
都包含 有效的端口号 ，即接收设备中存在一个与给定端口号绑定的 DLMS/COSEM AE，则在基于
DLMS/COSEM TCP 的 TL 接收完整的 （在 一个或多个 TCP 数据包中）后生成。否则，收到的消息
APDU
将被直接丢弃。
TCP-DATA.indication 需要在接收完完整包并解包后交给 AL,Data 是 APDU
Console
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-DISCONNECT.request 来启动该过程。
TCP
TCP connection abort
基于 DLMS/COSEM TCP 的 在 TL 原语的帮助下指示支持 连接 到
TCP-ABORT.indication TCP
DLMS/COSEM 的 中断或断开 。 请注意，这是提供给 DLMS/COSEM AL 的 唯一 TCP 连接管理服务
AL
(其他服务都是提供给 TCP 连接管理进程的)。
当 连接 被 连接管理器进程 断开时调用该服务（ 优雅断开 的情况），或者当 TCP 断开以 非请求
TCP TCP
方式 发生时，例如 TCP 子层 检测 到不可解决的 错误 或 物理连接 被 关闭 。
前文 TCP-ABORT 一节提到 TCP-ABORT 不是非请求中断才生成吗?为什么请求中断也
TODO:
会生成
该服务的目的是 通知 DLMS/COSEM AL TCP 连接 中断 ，以便它可以 释放 所有现有的 。 AA
Data transfer using the TCP-DATA service
可选 原语表示 TCP-DATA 结果 。请求原语之前调用，这是 OK 或 NOK。然而，这
TCP-DATA.confirm
个结果的含义取决于实现。当.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
层 通过 request 原语发送一个 992 字节的 APDU ， Wrapper层 加上 8字节 的头，第一次发送 1000
AL
字节，实际一包发出去 476 字节，还剩 524 字节，以此类推 直到发完 ，向 AL 层回复 confirm 原
语。该过程由 Wrapper 层控制。
层接收到完整的 wrapper 头+APDU 后，解开 wrapper 头，将 APDU 放在
Wrapper TCP-DATA.ind 原
语中发送给 AL 层。
s7.3 The DLMS/COSEM CoAP based transport layer
s7.3.2 Overview
受限应用协议 (Constrained Application Protocol, ) 是由 IETF 核心工作组定义的专用互联网应
CoAP
用协议。 CoAP 专为在 资源受限 的设备中使用而设计，用于通过非受限或受限的互联网通信网络
（例如， 低功耗 、 有损网络 ）进行通信。 CoAP 旨在提供高效的数据传输能力，同时满足 可靠性 、
多播支持 、 极低开销 、 效率 和 简单性 等特殊要求。
基于 CoAP 的 提供 不可靠 和 可靠 的传输服务(CoAP 原来是属于 应用层 的，这里
DLMS/COSEM CoAP TL
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-DATA)传递给
CoAP / OSI
，以实现
DLMS/COSEM AL 方法 的使用CoAP POST
DLMS/COSEM 服务接入点 寻址 功能，从而允许 多个 DLMS/COSEM
SAP 驻留在物理设备的同一 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 的应用）提供服务，用 区分(CoAP 类似 URIPath
于 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 层有错误导致调用发送函
数失败，视为失败)，用于失败的情况，由 本地 返回给 wrapper 层错误信息， 本地
CoAP client
层 返回给 AL 层 confirm 原语
wrapper
s7.3.4.2 The DLMS/COSEM CoAP-DATA service primitives
s7.3.4.2.1 CoAP-DATA.request
Console
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协议提供的不可靠传输模式主要还是在广播的
时候用的
： CoAP
Remote_Path 。Response_Mode 为“RESPONSE”忽略该参数
Uri-Path
：表示是否期望返回 DLMS/COSEM 响应 APDU。影响CWPDU中的 。它取
Response_Mode 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 被设置为 ，并且 DLMS/COSEM CoAP TL 实现 不支持 这种
UNRELIABLE
操作模式的 CoAP-DATA.confirm 原语，那么 Request_ID 可以不被指定。
如果 DLMS/COSEM CoAP TL 服务 不支持 CoAP-DATA. 原语，CoAP wrapper 将 忽略 指
confirm
定的 Request_ID 标识。
使用场景：
发送 请求 （单播或多播广播）：
DLMS/COSEM
指定为对方 Uri-Path
Remote_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
Console
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
Console
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
)
：本地 DLMS/COSEM AE 的 SAP
Local_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 是一个 数据报 ，携带 CoAP消息 作为其 有效载荷 。该 CoAP 消息携带
UDP
头 和 DLMS/COSEM CoAP Wrapper PDU（ CWPDU ）。CWPDU 携带 DLMS/COSEM
CoAP 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 ( )：通知对方的 wrapper 层是否应该期望收到对方的 AL
WRM
层响应，(为 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消息以简单的 二进制格式 编码。消息由一个固定大小的 字节头 、一个 可变长 度的 Token值 (0-
4
8 字节)、 个或多个 编码 的选项(可选地)和 负载 组成。
0 tlv
一个 非空的 作为 有效负载 在 CoAP 消息中携带。
CWPDU
本节其实就是介绍标准 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 的 响应
三种响应模式见上述文章
客户端错误和服务器 错误响应代码 由 协议层 或 包装器 根据错误条件 填充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 路径，默认是 dlms
: CoAP uri
Content-Format ：允许的传输格式，和 HTTP 类似，可以不指定，因为默认都是
application/octet-stream
Block1 and ：在 RFC 7959 中新增的两个 option，用于表示分块传输，见
Block2
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 的可能性， 会 延时发送 ，直到本地 wrapper 层收到 AL 层的
piggybacking ACK
数据并打包成 CWPDU 或超时，再发送 附带或不附带数据 的 。要是超时的话这个 CWPDU 单独发 ACK
送，不附带在这个 ACK 中
7.3.5.4.3.2 CoAP Retransmission Parameters
中的可靠 CoAP 消息传递层使用许多参数来控制 RFC 7252 定义的 CoAP 重传
DLMS/COSEM CoAP TL
算法。这些参数在 CoAP setup interface class 类中指定
ack_timeout
需确认消息的最小初始 ACK 超时
是在
initial_ack_timeout 和 ack_timeout ack_timeout x ack_random_factor 之间 随机选择 的
值。
是可靠的 CoAP 消息层的 初始重传延迟 。
initial_ack_timeout
ack_random_factor
用于申请初始 ACK 超时随机性的随机因子。
max_retransmit
需确认消息的最大重传次数。
delay_ack_timeout
消息传递层在 返回确认 之前 等待 应用层返回响应的时间（以毫秒为单位），piggybacking
CoAP
相关的，防止太久不回 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 协议层实体根据 RFC 7252 和 RFC 7959
CoAP 消息层 /
自动生成 的 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 携带)时返回错误
这种错误响应可能有助于诊断，也可能有助于主动纠正措施。通常，当传入的请求由于 语法错
误 而无法提供服务时，将返回 客户端错误 (类似 HTTP 状态码里的 4xx 表示客户端错误，5xx
CoAP
表示服务器错误，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
包装器请求/响应上下文 （见 7.3.5.7）对于在本地发起的 CoAP 请求/响应上下文中传送的任何 未
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-DATA.confirm 原语（结果为 “
CoAP “）和与 CoAP-
NOT OK
DATA.request 原语中的 APDU 提供的 Request_ID 相匹配的 来传达相关 APDU 的 交付
Request_ID
失败 。参见 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 提供的 APDU。(服务端 AL 层无
Transport_Mode = RELIABLE
需响应，客户端 AL 也不会收到传输层给它的确认，但传输层自己要保证发送成功，包括超时
重发和失败重发。
注意，CoAP 层只会在未收到 ACK 时重发，对于 wrapper 层 CWPDU 未收到的情况需
要 wrapper 层自己重发
可靠传输不是靠 CoAP 的 ACK 吗，为什么还要单独再搞个 wrapper 层的确认 更
TODO:
新：DLMS/COSEM TL 层的可靠传输，属于整一层的，CoAP 的 ACK 也是 wrapper 层用
于判断传输成功的一种依据。比如还有明明收到了 ACK 但没收到对方 wrapper 层的
响应，就要由 wrapper 层自己重发，来保证可靠传输
过程：
1. 在 的 CoAP-DATA.request 原语中提供给 CoAP 包装器的
Response_Mode = UNCONFIRMED
APDU 应由 CoAP 包装器在 包装器响应模式 (WRM)设置为 1 的 CWPDU 中的新本地发起
CoAP
CoAP 请求/响应上下文中传输（ )（WRM 见 7.3.5.2，关于 CWPDU 的定义）
WRM = 1 。 这指
示接收 CoAP 包装器 不要等待 返回 DLMS AL 响应或 DLMS AP 响应；
2. 接收 CoAP 包装器应在将接收到的嵌入的 APDU 成功交付给 DLMS AL 时，当通过 可靠 CoAP
消息传递层 在 的 CWPDU 中接收到 APDU 时， 返回 一个 空的
WRM = 1 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 模式。
服务器等待模式 ：接收 CoAP 层传来的非空且需 AL 层回复（WRM=0）消
Server Waiting Mode
息，发给 AL 层后， 等待 AL 层回复 CoAP-DATA.req 消息
服务 ：接收到 CoAP 层传来的非空且无需 AL 层回复(WRM=1)消息，发给 AL 层后直接结
Serving
束，进入 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 层传来的非空且 需 层回复 （WRM=0）消息，发给 AL 层后， 等待 AL 层回复 CoAP-
AL
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
块传输，用于 APDU 大于 MTU 但小于 receiver_max_pdu_size 的情况，主要是用于让 IP 层无
CoAP
需再分片，属于 CoAP 标准中的一部分。
对于 UNRELIABLE 服务，图 58 中的 Transport_Mode 替换为 UNRELIABLE ，CoAP type 替换为 NON
s7.3.6.6 DLMS GBT operation over DLMS/COSEM CoAP TL
分块，区别于 CoAP 块传输，属于 DLMS/COSEM AL 层实现的分块传输，在某些方面优于
DLMS GBT
CoAP 块传输。
是不是就只是用来交换 GBT 参数的，此时直接发出去应该 data 是个空
TODO:FIRST-PART
的也行 更新：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： 无连接承认响应服务 。
类型 的 LLC 无连接 服务中规定了一种静态帧格式，并支持运行网络协议。有关 传输层网络协议 通
1
常是使用服务类型 1 方式。
类型 的 LLC 面向连接 服务支持 可靠数据传输 ，运用于 不需要 调用网络层和传输层协议的局域网环
2
境。(相当于把 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 程序模式为 - 非平衡正常响应模式(Normal response mode, NRM)模式 - 使用 UI
UNC
帧扩展；
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-
服务原语 透明地传输 到“真实”服务提供者 MAC 子层或从“真实”服务提供者 MAC 子层接
CONNECT.xxx
收。
由于客户端和服务器端 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
Console
DL-CONNECT.request
(
Destination_MSAP,
Source_MSAP,
User_Information
)
MA-CONNECT.request
(
Destination_MSAP,
Source_MSAP,
User_Information
)
和 Source_MSAP: 标识要建立的 引用数据链路层连接 。
Destination_MSAP
User_Information：为 可选配置 。其内容的规范不属于本技术报告的范围。
服务用户层调用 DL-CONNECT.request 原语，LLC 层接收后调用 MA-CONNECT.request 原语发给 MAC
层，MAC 层发送格式化后的 帧 (Set Normal Response Mode (a HDLC frame type,HDLC 协议的一
SNRM
部分))
s8.2.2.3 DL-CONNECT.indication and MA-CONNECT.indication
Console
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
Console
DL-CONNECT.response
(
Destination_MSAP,
Source_MSAP,
Result,
User_Information
)
MA-CONNECT.response
(
Destination_MSAP,
Source_MSAP,
Result,
User_Information
)
Result 指示提议的连接 是否可以被接受 ，以及 是否应该发送响应帧 。它可以有以下值之一:
Result == 这意味着接收到的连接请求 可以 被服务用户层 接受 。MAC 层收到后发送 帧
OK UA
Result == 。这意味着接收到的连接请求 不能 被服务用户层 接受 ;（如果链路层收到第二个
NOK
连接请求，但同时只能有一个，即使服务用户层接受，连接也不能建立），MAC 层收到后发送
DM 帧
Result == 。这意味着不应发送对 DL-CONNECT.indication 的响应。MAC 层收到
NO-RESPONSE
MA-CONNECT.response 后不发送任何帧
s8.2.2.5 DL-CONNECT.confirm and MA-CONNECT.confirm
Console
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
Console
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
不能拒绝该服务，结果仅表明指定的 DL connection 是否存在
service user layer
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 的资源足够大（比如缓冲区），所以调用原语时不
client: I-COMPLETE and UI;(
需要分包，直接用完整的)
server: I-COMPLETE, I-FIRST-FRAGMENT, I-FRAGMENT, ILAST-FRAGMENT, and UI
收到调用后，LLC 层组装 ，其中包括 LSDU (the two LLC addresses and the
LLC specific fields
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）
物理层 断开 会通过 原语 通知 MAC 层
PH-ABORT.indication
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
表示传输还未结束， 表示结束。类似于 OSI 模型中 IP 层分片标记，当应用层给了一个
0
很大的包，需要 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 帧格式 (参见 8.4.1.1)包含两个地址字段: 目的地址 和 源地址 。根据数据 传
type 3
输的方向 ，客户端地址和服务器地址 都可以 是目的地址或源地址。
client address：总是 1 字节，不能扩展
server address：只允许 1，2，4 字节
upperHDLC address： (在物理设备内的一个单独的可寻址的逻辑实体)
Logical Device
lowerHDLC address： ，用于标识物理设备(如果是点对点的对其值不做
Physical Device
要求，如果是多点接入则必须指定)
s8.4.2.3 Reserved special HDLC addresses
MAC 层中 HDLC addresses 的含义
客户端地址、服务端地址（分为低地址逻辑地址部分和高地址物理设备部分）：
每个字节的 LSB 用于标识是否有后续字节，所以 不计入 实际字节的表示，也就是一个字
节就 个有效位 。1111 1111 表示一个字节，后续无字节，然后把 LSB 去掉就是 1111 111，
7
前面补 0 就是 0111 1111，一个字节最大就能表示 。如果要表示 ,就是，0000 0x7F 0xFF
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)
is the send sequence number N(S)，发送帧号
SSS
从链路建立开始，帧序号就总是递增的，因为范围是 0-7 所以会有回绕。
P/F ： 表示
is the poll/final bit P poll bit ，表示是否交出 发送权 ，一般需要响应的请求的最后一
帧会置为 TRUE
帧 ，Information transfer command and response
I
信息传递
字段， ：自身发送帧的 序号
SSS N(S)
字段， ：期望接收到的下一帧的 序号 ，表明对方的
RRR N(R) 序号的帧已被正确接N(R)-1
收。
发送接收最大 长度默认为128字节，最大 2030 字节
information field
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
为一个八位字节。 次站应通过在第一个响应机会时发送 响应来确认 SNRM 命令的接受。 UA
在接受该命令后，从站发送和接收状态变量应设置为零。
此命令执行后，原来由 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
当连续标记保持条件持续一段系统特定的时间( Tidle) 时，数据链路通道进入空闲状态。
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
主站发 ，从站回 响应，并进入 NDM。如果已经处于断开模式 NDM，将发送 响
DISC UA DM
应。
超时重发和 Setting up the data link 相同
s8.4.5.4 Procedures for data exchange
收到 MA-DATA.request 调用后，发送 帧 ，只能在 下发送。若 Frame_type == UI，则发送
I NRM 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
，见 8.4.2.3
CALLING Physical Device address
允许服务端发起物理连接请求，以便自己能上报数据（8.4.5.4.7那些数据）
客户端需要发送 为服务端配置模式，其中 Lower MAC Address 的值应该为
SNRM 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 序：
Plaintext
↙ - 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
位的 FCS 计算参考 RFC 1662
16
大致思路见：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 之间 传输数据的服务,见 9.1.4
APs
Control Function (CF)元素指定 服务 如何调用
ASO 、 和 支持协议层 的服务的 适当服务
ACSE xDLMS ASE
原语 。见 9.4.1。
客户端和服务器 DLMS/COSEM 都可能包含其他可选的应用程序协议组件。
ASO
当 服务器 使用 引用 时， 可选的 Client SN_Mapper ASE 出现在 客户端
SN 中。它使用 LN 和 SN 引
AL ASO
用提供服务之间的 映射 。见 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 服务，可以在单个客户端和单个服务器之间建立；
使用 COSEM-OPEN 服务，可以在单个客户端和多个服务器见建立，只有
unconfirmed AAs
客户端发送，服务端不回应。（多播，广播）
可能预先存在。 不使用 COSEM-OPEN 服务。 客户端必须知道服务器
pre-established AAs
支持的上下文。 预先建立的 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 ASE 的一部分，而是放在了
xDLMS xDLMS
的 COSEM-OPEN 服务中，具体携带在 AARQ 和 AARE 中，这也是为了利用 ACSE 服务在建立
ACSE
连接阶段顺便协商好 xDLMS 上下文，减少通信次数。
s9.1.4.3 COSEM object related xDLMS services
与 COSEM 对象相关的 xDLMS 服务用于访问 COSEM 对象属性和方法 。
COSEM 对象有两种引用方式：
Logical Name (LN) referencing
Short Name (SN) referencing
客户端ASO 总是使用带有 LN引用 的 xDLMS ASE 。 服务器ASO 可以使用带有 LN引用 的 xDLMS ASE ，也
可以使用带有 SN引用 的 xDLMS ASE，或者 两者都使用
相关的服务可以是：
：客户端请求
requested / solicited
还可将其分为两类(见 9.4.6.2):
confirmed: 在这种情况下，服务器提供对请求的响应;
unconfirmed:在这种情况下，服务器不提供对请求的响应。
unsolicited: 由服务器端发起，无需请求
如来自服务器的 的
unsolicited(见 9.3.10):
DataNotification
confirmed:在这种情况下，客户端提供一个 响应 来确认收到了 unsolicited 的
DataNotification
在这种情况下，客户端不会对 unsolicited 的 DataNotification 提供响应
unconfirmed:
附加服务 -不是基于 IEC 61334-4-41:1996 规定的 DLMS 服务-而是:
使用 LN 引用访问 COSEM 对象属性和方法的 、 、 和 ; GET SET ACTION ACCESS
服务器用于向客户端推送数据的 服务;
DataNotification
服务端使用 服务通知客户端服务器发生的事件。
EventNotification
IEC 61334-4-41:1996 规定的是早期的 DLMS，后面有扩充的叫做 xDLMS，多了很多重要
的东西
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的
参数，比如 ACCESS 总是支持这个特性
multiple-references
s9.1.4.3.7 Attribute_0 referencing
、 和 ACCESS 服务有一个特殊功能，即
GET SET 引用。 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
在 的情况下， 引用方法 在 AA 建立阶段通过 COSEM 应用上下文进行 协商 。在 AA 成
confirmed AAs
立期间 不得改变 。在给定的 AA 中使用 LN 或 SN 服务是独占的。
在 and
unconfirmed AAs 的情况下，客户端 AL 需要 提前知道 服务器支持的 引用方
pre-established
法。
s9.1.4.4.3 Identification of service invocations: the Invoke_Id parameter
在 client/server 模型中，请求由客户机发送，响应由服务器发送。允许客户端在接收到对前一个
请求的响应之前发送 多个请求 ，前提是 较低层允许 这样做。
需要用 来 标识 数据包，这样客户端才能判断响应是 对应 哪个请求的
Invoke_Id
在 ACCESS 和 服务(参见 9.3.9 和 9.3.10)中，使用
DataNotification 参数来 代替 Long-Invoke-Id
Invoke_Id 参数。
服务 不包含 Invoke_Id 参数。
EventNotification
此功能仅在 引用 时可用 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
特定于服务的块传输 只能一包一包顺序传，不支持流式传输，不支持恢复丢失块。加密是加一个
，而不是整个 APDU（根据协议原文所述这会带来更多的性能消耗，这个我持怀疑态度，分
block
块后加密和全部加密后再分块应该不会有明显的性能差距）。数字签名不可用（数字签名只能保护
完整 APDU,不支持分块保护）。
相反， 机制 可以与任何 xDLMS APDU 一起使用，包括 通用密码和通用签名 。它提供 双向块传
GBT 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 机制可用于块内传输任何长或短 。在 GBT 中，块由 通用块传输 携带，而不是
xDLMS APDU 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
6
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 中规定的 标准 和 IEC 61334-4-41:1996 中规定
ACSE
的 DLMS标准 ，并扩展了 DLMS/COSEM。
s9.2 Information security in DLMS/COSEM
安全概念 security concept，见 9.2.2;
DLMS/COSEM
选择的加密算法，见 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 被绑定到支持 AL 的 协议层 中的服务接入点(
AEs 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
服务器要求 客户端 通过提供服务器知道的密码来 证明自己 。该密码是由当前持有的
“ ”对象建模的 AA 来建立的。“Association SN / LN”对象提供了更改密码
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 还能验证 真实性 ，即使内容被篡改因为没有密钥也无法生成 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)，一个用于经过身份验证的加密函数，另
一个用于经过身份验证的解密函数。
当密钥建立时，对应的 复位为 0; IC
使用 认证加密 功能后，对应的 IC 加 。如果 IC 已达到 最大值 ，任何进一步调用认证加密函
1
数将 返回错误 ，且 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
身份验证标记的 位长 是一个安全参数。在安全套件 0、1 和 2 中，其值应为 96 位。
t
s9.2.3.3.8 AES key wrap
对于封装密钥数据，DLMS/COSEM 选择了 中指定的 AES 密钥封装算法。该算法旨在包装
RFC 3394
或加密关键数据。它对 位块 进行操作。在 wrap 之前，关键数据被解析为 个 位 的块, 至少为
64 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:
1. Initialize variables
Console
Set A = IV, an initial value (see 2.2.3)
For i = 1 to n { R[i] = P[i]; }
1. Calculate intermediate values.
Console
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)
1. Output the results.
Console
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:
1. Initialize variables.
Console
Set A = C[0]
For i = 1 to n
R[i] = C[i]
1. Compute intermediate values.
Console
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)
1. Output results.
Console
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)，并应是:
对于安全套件 和 ,128 位(16 位):len(KEK) = ;
0 1 128
对于安全套件 ,256 位(32 位):len(KEK) = 。
2 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)组成，满足下列方程:
2 3
y = x + ax + b
曲线的形状由 a 和 b 两个参数决定
NIST 推荐使用椭圆曲线
s9.2.3.4.3 Data conversions
本节描述了数据转换原语，用于在用于指定公钥算法的不同数据类型之间进行转换：八位字节串
(OS)、位串 (BS)、整数 (I)、字段元素 (FE) 和椭圆曲线点 （ECP）
。 DLMS/COSEM 使用八位组字符串
来表示公钥算法的元素，并使用这些数据类型与八位组字符串之间的转换原语。 长度为 d 的 八位
字节串 被编码为
Md–1 Md–2 … M0 A-XDR OCTET STRING ，其中最左边的八位字节 Md–1 对应于八
位字节串的编码值的第一个八位位组
Conversion between Bit Strings and Octet Strings (BS2OS)
位串转换为八位串的数据转换原语称为位串到八位串转换原语，或称 BS2OS。它以位字符串
作为输入，输出八位字符串。长度为 l 的字节串 应该转换为长度为 bl−1bl−2 … b0 d = ⌈l/8⌉
的八位字符串 。Md−1Md−2 … M0
位串在内存中的编码非常密集。每个位只 占用一位 存储空间，整个位串的开销由一个
小常数限定。但是，与访问向量或字符串的元素相比，访问位串中的位要慢。如果
性能是最重要的问题，最好使用字符串来存储布尔值集，即使它们占用更多空间。
位串和八位字节串的区别就是位串的位长 不需要是 的倍数 ，而可以是任意值，转换的 8
时候需要 补足 的倍数 8
转换器在左边 填充足够的零 ，使位数为 8的倍数 ，然后将其分解为八位。
for 0 ≤ i < d–1 , let the octet Mi = b8i+7b8i+6 … b8i, ;
the leftmost octet Md–1 shall have its leftmost 8d–l bits set to zero; 最左边的 OS 字节需要包
含位串最左边填 0 部分
its rightmost 8–(8d–l) bits shall be bl–1bl–2 … b8d–8.
Conversion between Octet Strings and Bit Strings (OS2BS)
和上面相反
最左一字节的最左位必须是 0
Conversion between Integers and Octet Strings (I2OS)
输入为 非负整数 ，预期长度 ，需要满足
x d 256
d
> x
每个整数的位用一个字节表示：
x = xd−1 ⋅ 256
d−1
+ xd−2 ⋅ 256
d−2
+ ⋯ + x1 ⋅ 256 + x0 ;
where 0 ≤ xi < 256 for 0 ≤ i ≤ d − 1 ;
Mi = xi , for 0 ≤ i ≤ d − 1 .
正好是二进制0b100000000，1在8位，这样的话0-7位就表示 ，通过
256 x0 让8-15位
x1 ⋅ 256
表示 x1
例：十进制1234，转为OS为 0 ⋅ 256
3
+ 0 ⋅ 256
2 1
+ 4 ⋅ 256 结果为0x000004D2。
+ 210
其实就是把数字转换为16进制数用 表示 HEX
Conversion between Octet Strings and Integers (OS2I)
和上面相反
0 字节的 OS 输出整数 0
Conversion between Field Elements and Octet Strings (FE2OS)
将 字段元素 转换为八位字符串的数据转换原语称为字段元素到八位字符串转换原语，或
。它接受一个 字段元素 作为 输入 ，并 输出 相应的 八位字符串 。应用 I2OS 转换原语，参
FE2OS
数 将域元素
l 转换为长度为
x ∈ Fp 的八位字符串
d = ⌈log256 p⌉ ，其中 Md−1Md−2 … M0
F E2OS(x) = I 2OS(x, l)
Conversion between Octet Strings and Field Elements (OS2FE)
与上面相反
OS2F E(x) = OS2I (x) mod p
是什么，FE2OS 不懂 更新：域元素应该就是某个域范围内的一个
TODO:Field Elements
值，比如域为0-9999，这个值可能就是3456。 ，log25645768865 = 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 = [log256 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 ”接口类的方法支持;见 DLMS UA 1000-1 Part
Security setup
2 Ed.15:2021, 4.4.7.
双方从 域参数 d中生成一个 临时密钥对 。双方 交换临时公钥 ，然后使用
(domain parameters)
域参数 、 各自的临时私钥 和 对方的临时公钥 计算 共享密钥 。 密钥材料 Z (secret keying
是使用 9.2.3.4.6.5 中指定的 密钥派生函数
material) 从 共享密 (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 派生出对
称加密密钥。
这种表示方式表示 U 方和 V 方都使用
C(2e, 0s) 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 方的公私钥是 的，而 V 方是 的
ephemeral 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 下应该小于 ，或在 SHA-384 下小于 。
2
64 128
2
函数所需参数：
共享秘密(shared secret)，byte string
Z
OtherInput
keydatalen 一个整数，表示要生成的 密钥材料 的 长度 (以 位 为单位):安全套件 为 1 128
位，安全套件 为 位; 2 256
OtherInfo 等于下列串联的位字符串
AlgorithmI D∥P artyU I nf o∥P artyV I nf o∥SuppP ubI nf o∥SuppP rivI nf o
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
安全套件确定可用于各种密码原语的 密码算法集 和 密钥长度 。
安全套件 (见表 27)基于NSA suite B，包括用于`身份验证、加密、密钥协议、数字签名
DLMS/COSEM
和哈希的加密算法
s9.2.4 Cryptographic keys – overview
密钥作用：
明文到密文的转换;
密文到明文的转换;
验证码(MAC)的计算和验证;
密钥包装 wrapping;
应用和验证数字签名;
密钥协商。
s9.2.5 Key used with symmetric key algorithms
对称密钥的使用
s9.2.5.1 Symmetric keys types
对称密钥的分类：
按目的分类
用于加密其他对称加密密钥，又称 master key
key encrypting key (KEK)
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 标识公钥和密钥算法
Console
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 相关
Console
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)用证书（ 算法，One-Pass Diffie-Hellman C(1e, 1s)
ECDH
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
为服务器提供 信任锚 ，需要再设备 正常运行前 导入 证书 或 直接信任的CA公钥 。可以有
Root-CA,Sub-CA
多个信任锚
信任锚的部署或替换是 带外操作 ，out of band ( ) OOB
信任锚证书和其他证书 存储在一起
TODO: 这个是否有安全问题，比如 windows 有专门的受信任根证书区域，每个分类都有
专属区域。 更新:见下句
可以 导出 ，不能 导入或删除 ，解释了上面的安全问题，是有防篡改保护的
直接信任的 CA 公钥不能导出
s9.2.6.6.3 Provisioning the server with further CA certificates
为服务器提供 进一步的 证书 （应该是 Sub-CA，非信任锚）
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. 客户端 向 发送 ，该消息封装了调用 generate_certificate_request 方法得到的返回参
CA CSR
数。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
保护 参见 9.2.7.2;
xDLMS APDUs
处理 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 的
access_rights_list access_mode 元素决定了访问类型并规定了密码保
护。它是一个 enum 数据类型。
对 对象 属性 和/或 方法 的 访问权
COSEM 可能要求对 xDLMS APDUs 进行 认证、加密
Access rights
和/或 签名 。为此，只允许保护程度 超过或等于安全策略 要求的 APDUs。保护程度
security policy
低于安全策略和访问权限要求 的 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
在 消息保护 的情况下，要保护的信息是 。在 COSEM 数据保护 的情况下，需要保护的信
xDLMS APDU
息是 数据 ，即
COSEM data 属性值 或 方法调用 返回参数 。
COSEM /
The security header
SH = SC||I C
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
：请求原语从 N-用户传递到 N-层以请求启动服务；
REQUEST
：指示原语从 N-层传递给 N-用户，以指示对 N-用户重要的内部 N-层事件。 该事
INDICATION
件可能逻辑上与远程服务请求有关，也可能是 N-层内部的事件引起的；
：响应原语从 N-用户传递到 N-层，以完成先前由指示原语调用的过程。
RESPONSE
：确认原语从 N-层传递给 N-用户，以传达一个或多个相关的先前服务请求的结果。
CONFIRM
原语参数含义：
字段 说明
M 该参数对基元是强制性的。
U 该参数为用户选项，可根据 ASE 用户的动态使用情况提供或不提供。
S 该参数从其他 S 参数中选择，作为服务器 ASE 环境的内部响应。
C 该参数取决于其他参数或 ASE 用户环境。
(–) 该参数从不存在。
= M、U、S 或 C 代码后面的 “(=)” 代码表示该参数在语义上等同于表中左侧服务基元中的参数。
（重要）命名规则
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-
中的 xDLMS InitiateResponse APDU 中
information
xDLMS_Initiate_Error
服务端不接受 Proposed_xDLMS_Context 建议后回复。包含在 AARE APDU 中的 user-
中的 xDLMS confirmedServiceError APDU 中
information
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
调用它的方式（ 参数）决定了它是否使用 ACSE 的
Use_RLRQ_RLRE 服务。 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 下层连接以 非请求
的方式 关闭 。
此类事件的起因可以是一个 外部事件 (例如物理线路断线)，或者在一些配置文件中出现的一个 支持
协议层连接管理器 ( 层管理 ，非 COSEM AP)的动作，当支持的协议层连接不是由 DLMS/COSEM AL
AP AP
管理时。这将导致 COSEM AP 中止 任何现有的 AA，除了在服务器端预连接 AA。
s9.3.5 Protection and general block transfer parameters
：可选，仅用于在 AL 和 AP 之间传递 加密 或 相关信息。
Additional_Service_Parameters 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 过大的情况
在接收端时，AL 需要判断是否可以划分 PART，比如，因为 GBT 是
Partial service invocations
流的形式传输，接收到的包都是按照字节分割的，所以接收端 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
数据的 结构体 ，填充在 区域，没权限的或访问出错的回 null-data
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 是一个 格式 的参数，其内部的值已经是编完码的了，因为 Data 编解码
octet-string
是业务层蓝皮书的部分，需要 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
响应不能分包
的情况，同 GET，需要 SET 请求包含有 全部公开属性
COSEM_Object_Attribute_Id == 0 ( Attribute_0 )
的 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，
回 ACTION.response，ACTION.confirm 由 AL 发送给 client AP,都是可以是分包的。直到收
server 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)。
可以将其看成是各种 服务的进阶整合版，GET/ SET/ ACTION-WITH-LIST 服务请求可以只
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
（位 0-23）用于识别服务调用的实例；
long-invoke-id
自描述（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 情况
带选择性访问参数，不能用于 Attribute_0 情况
Access_Request_Set_With_Selection
处理 response 时优先判断 result，如果 result 失败直接丢弃 data。
具体服务用法见文档。
s9.3.10 The DataNotification service
数据推送
服务类型：unsolicited 未经请求
确认类型：unconfirmed 无需确认 或 confirmed 需确认
request 支持分块传输（GBT）
成功标志：
服务类型：收到 Data-Notification-Confirm xDLMS APDU
Confirmed
Unconfirmed 服务类型：收到支持层确认或支持层不返回失败
服务原语通信模型：Figure 112 a), b) and d).
TODO: 这里的 d 是什么情况，按照描述，Unconfirmed 也需要支持层响应。解答：就是
9.4.6.7中描述的 case 1: unconfirmed方式下支持层回复失败重试的情况，若支持层不响
应，则默认为成功。
s9.3.11 The EventNotification service
的 unconfirmed 的服务
unsolicited
request 支持分块传输
可选，如果 没有 相应的 ，则包含全部识别信息(标识发送者和目的AP，
Application_Addresses: AA
也就是允许没有 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 中的 (见 9.3.2)参数用于选择功能模块启用
acse-requirements
见文中 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 原语（Service_Class == Confirmed），client （control
COSEM-OPEN.request CF
function）进入 状态（见 9.4.1），
ASSOCIATION PENDING
然后， 在 CF 和 的帮助下 组装 包含从 AP 接收的 COSEM-OPEN.request 原语参数
xDLMS ASE ACSE
的 ，并将其 发送 到服务器。
AARQ APDU
xDLMS ASE 是 InitiateRequest APDU 打包器（只和 xDLMS 相关，就是 AARQ 中的 user-
information ）， 是 AARQ APDU 打包器（ACSE 中的
ACSE 和 Kernel authentication
functional 相关的参数,见 9.4.2.1）
服务器 AL 的 将收到的 AARQ APDU 提供给
CF ACSE , ACSE 提取 ACSE 相关参数，然后将 控制权 交
还给 CF。
然后， 将 AARQ APDU 的用户信息参数的内容（携带 xDLMS InitiateRequest APDU）传递给
CF
,xDLMS ASE 检索此 APDU 的参数，然后将 控制权 交还给 CF。
xDLMS ASE
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-
服务，见 9.3.3)
RELEASE
使用 ACSE A-Release 服务
Use_RLRQ_RLRE参数为 （就是使用 ACSE 的
TRUE 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
应该是指 with-list 服务最小支持的数量。
limited to one. TODO:
不支持组合多种块传输机制(比如 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 端发起：
在 的 AAs 中
confirmed
可以以 confirmed or unconfirmed 的方式调用 xDLMS 服务。
在 的 AAs 中
unconfirmed
只能以 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 的 编解码 ，同时可以对 进行分块 ，也就是 service-Data
specific block transfer 的基础。其中分块可以是 按字节 不按逻辑分，也可以 按逻辑 分(每块都能自解
析)。这样的话服务端就可以 分段生成回复 ，对于已经发送的块可以释放内存， 减少内存占用
假设需要响应的结果是一系列字节： , , ,…., 。服务器可在收到请求后生成完整的响
B1 B2 B3 BN
应，也可动态生成（即时生成）。
服务特定分块发送接收流程：
第一个响应的 DataBlock_G(见 9.3.7)：
Last_Block == FALSE;
Block_Number == 1;
Result (Raw_Data) == the first K bytes of the encoded data: B1, B2, B3,…., BK .
其中起始 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
不支持 service-specific block transfer，见 9.4.6.1，一致性块不包含该功能，就是
ACCESS
不支持，所以文中只给了 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 块传输总结 ：
， ，用于本地 AL 和 AP 通信时的分包，在 GBT 和加密中才需要
1. Partial service invocations 9.3.5
使用，按逻辑分包，非字节分包。猜测因为 GBT 或通用加密是流式的，AL 和 AP 通信时必须
使用完整的服务原语，所以接收时可能需要由 AL 判断是否已经接收到 AP 可以识别的一部分
并可以向 AP 发送了，不过这个判断的条件还不太明确。
2. service-specific block transfer，9.3.5，用于远程 AP 间通信，由每种 xDLMS 服务自行定义。
，用于远程 AL 间通信，由 AP 提供窗口和流参数，但如果没有参数会不
3. general block transfer
会也触发 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 层的 部分服务调用 (9.3.5)，这个 GBT 是针对 APDU
partial service invocations
的，两者没有直接关系
原语参数：
用于 AP 指示 AL 是否可以用 流方式 (窗口)发送，（窗口的意思
Block_Transfer_Streaming ( BTS ):
就是每发若干个包确认一次，结合 BTW 若为 0，表示无需确认，若为 1，表示 1 个包确认一
次）
Block_Transfer_Window ( )：用于 AP 指示 AL 最大流窗口大小 ，但最终由 AL 决定，AL 可以设
BTW
置的很小用于传输丢失包。
unconfirmed services 固定 Block_Transfer_Streaming 为 ，以及 Block_Transfer_Window 为
FALSE
0 .类似 UDP，可以尽可能的发，无需对方 AL 层确认
GBT APDU 字段：
the last-block ( ) ：是(LB = TRUE(1))否最后一包
LB
streaming( STR ) :对于一个窗口，在过程中(STR = TRUE(1))还是已结束(STR = FALSE(0)，一个窗
口内的 最后一包 )。如果是已结束，需要 对方 回个 确认 ，这个确认是对这个窗口的，如果是完
整 APDU 的最后一包则 不回 ( 最后一个窗口不确认 )
TODO:怎么判断收全了 更新：通过发送权思路，就是谁是主动方，谁负责报文的送达
确认，这里接受方是主动方，如果没收全，会在超时时重发请求，发送端无需保证
自己的报文送达
window ：发送该 APDU 的一方的 接收窗口大小 ，发送 unconfirmed services 时为 0
block-number ( )： BN序号 ，第一个为 1
block
TODO: 具体什么时候开始重新计数 更新：应该是last-block的时候，也就是一个完整
的APDU发送完成后
： 被确认 块号，最后一个 连续的 被确认的块的 块号 （这个
block-number-acknowledged ( BNA )
块之前的所有块也要已经被确认。这个是用于指示对方发送的块的确认，表明自己已确认）
block-data ( ):数据域，xDLMS APDU 的一部分
BD
s9.4.6.13.2 The GBT procedure
NOTE: GBT is often used with the DataNotification and Access services.
Send Queue SQ： :发送队列，对于 block :每收到 调用原语 ，(和 partial service invocations 无关，
AP
不管 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 修改）
其中 Wself 有默认值，是不是不需要 AP 提供，也可以有默认值 更新：有默认值的
TODO:
参数不需要 AP 提供也能使用，初始值就是默认值
子过程：
9.4.6.13.4 Send GBT APDU stream
Confirmed GBT stream send
AP 调用原语参数 要大于 0，SQ 为空时填充一个空的 block,NextBN 递增
BTW
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
调用原语参数 要等于 0
AP BTW
全部发完就清空 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
明确提到了 GET
parameters. The client AL sends the request in a Get-Request-Normal APDU
相关原语可以携带 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 终止条件：
1. 收到专用于终止命令的 GBT APDU： LB = 1, STR = FALSE, BN = 0 and BNA = 0;
2. 开始新的 GBT 过程。收到 BN = 1 and BNA = 0;
3. 收到 GBT 服务以外的 APDU
4. 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
提供服务给 AL
Data Link SAP-s
客户端：只要定义客户端 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-DISCONNECT 也是由 AL 管理的，用于 AL 在收到 COSEM-OPEN.request 调用时开
DL-CONNECT
启 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 总是使用 帧 携带，包括 Unconfirmed 的 APDU 也是，
I
此时服务端必须通过 xDLMS InitiateRequest APDU 的 （见 9.4.2.1）或 Invoke-Id-
response-allowed
And-Priority / Long-Invoke-Id-And-Priority 的 bit（用于指示是否为 confirmed 见 381
service-class
页）判断请求是否是 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，一旦断开， 所有 都会断开，必须通过 RLRQ/RLRE 有选择的断开。还有 UDP 是 无连接 的，
AA
不能通过断开支持层连接 断开 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 合理分块后可以不用 层 再根据 MTU 分片 了，AL 也支持引用层的分
IP
块传输，根据对方 AL 层支持的接收大小 receiver_max_pdu_size
通信配置里好像没用到 UDP 支持广播的特性，可能是 UDP 广播只能在
TODO:TCP/UDP IP
本地局域网中进行，不能跨路由器进行的原因
s10.4.3 Identification and addressing
：
CoAP URI Uri-Host + Uri-Port + Uri-Path
发送端 AL 需要知道对方的 和 SAP，由于 CoAP 封装了 UDP，所以 不需要 知道 地址和端
CoAP URI 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).
原语需要包含对端的 地址 和端口，如果 IP 是 静态 的，那可以 静态绑定 到
CoAP-DATA ip system
。如果是 动态 的，需要动态更新绑定，可以通过服务端 ip 变更自动推送实现
title
当客户端 AL 收到服务端上报 data 时，如果是动态 ip，客户端可以根据 system title 确认身份。
s10.4.4 Supporting layer services and service mapping
s10.4.6 Specific considerations / constraints
不能传 confirmed 消息,Reliable 可靠 CoAP 传输层配置不能传输广播消息
unconfirmed AA
CoAP 传输层无连接，不能通过断开传输层连接断开 AA,只能通过 RLRQ/RLRE 断开
s10.8 LPWAN profile
什么是 LPWAN？ LPWAN 技术有哪些？
(低功耗广域网)，也称为 LPWA 或 LPN，是一种用于物联网(例如，以电池为电源的传感器)
LPWAN
的类型，这是一种能够以低比特率进行远距离通信的无线网络。LPWAN 可以同时满足覆盖和续航
的要求。以最小的功耗提供最长的距离覆盖是 LPWAN 最大的技术优势。
是物联网领域的一项新兴技术，支持广域网中低功耗设备的蜂窝数据连接。它也称为
NB-IoT
低功耗广域网(LPWAN)。NB-IoT 支持设备有效连接，待机时间长，对网络连接要求高。据
称，NB-IoT 设备的电池续航时间可以提高到至少 10 年。
作为物联网的一种应用场景。它具有超可靠和低延迟的特点。eMTC 主要应用在设备之
eMTC
间的通信需求上。
是一项专有技术， Semtech 为其提供芯片。Lora 技术改变了以往在传输距离和功耗之间
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)的 IPv6 无线网状网络，专为关键基
IEEE 802.15.4
础设施项目设计。每个个人区域网络(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:
Console
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，解压时为上条记录的值加上递增
量
技术
C++ DAO database
本文由作者按照 CC BY 4.0 进行授权
相关文章
2022/03/08
DLMS/COSEM Blue Book 学习笔记
s4.1 基本概念 s4.1.2 Referencing methods logical names (LN referencing):The reference for an attribute is: class_id,
value of the logical_name attribute, attribute_index.The reference for a method is...
2022/03/08
C++ 实现的DAO(数据访问对象模式)
本文将会介绍如何使用 C++实现设计模式中的 DAO(数据访问对象模式) DAO 介绍 什么是 DAO 在计算机软件中，数
据访问对象（data access object，DAO）是为某种类型的数据库或其他持久性机制提供一个抽象接口的对象。…
2021/08/04
使用PlantUML绘制类图
本文基于 vscode 的 PlantUML 插件绘制类图。 类的 UML 表示 使用 UML 表示一个类，主要由三部分组成。类名、
属性、方法。其中属性和方法的访问修饰符用 - 、# 、+ 表示 private、protected、public。 如图所示，表示A类…
上一篇 下一篇
《Operating Systems: Three Easy Pieces》学习 Orangepi4 维护指南
笔记(七) 调度：比例份额
1 个表情
👍1
1 条评论 – 由 giscus 提供支持 最早 最新
© 2025 Kai. 保留部分权利。
浙ICP备20006745号-2，本站由 Jekyll 生成，采用 Chirpy 主题。
You might also like
- Silo - Tips - Dlms Cosem Architecture and ProtocolsNo ratings yetSilo - Tips - Dlms Cosem Architecture and Protocols101 pages
- IEC 62056 DLMS COSEM Workshop Part 6 Protocol100% (1)IEC 62056 DLMS COSEM Workshop Part 6 Protocol59 pages
- GE Grid Solutions: Technical Manual Monitoring & Recording IEDNo ratings yetGE Grid Solutions: Technical Manual Monitoring & Recording IED169 pages
- TSM 1.0 - User Manual - Excerpt TERRANOVA Smart Metering LibrariesNo ratings yetTSM 1.0 - User Manual - Excerpt TERRANOVA Smart Metering Libraries37 pages
- Security in DLMS A White Paper by The DLMS User AssociationNo ratings yetSecurity in DLMS A White Paper by The DLMS User Association20 pages
- DLMS - COSEM (IEC 62056) Source Code Products and SolutionsNo ratings yetDLMS - COSEM (IEC 62056) Source Code Products and Solutions6 pages
- Secure DLMS/COSEM Communication For Next Generation Advanced Metering InfrastructureNo ratings yetSecure DLMS/COSEM Communication For Next Generation Advanced Metering Infrastructure7 pages
- Design Key Management System For DLMS/COSEM Standard-Based Smart MeteringNo ratings yetDesign Key Management System For DLMS/COSEM Standard-Based Smart Metering5 pages
- Are Examples For Information Exchange AvailableNo ratings yetAre Examples For Information Exchange Available5 pages
- Disclosure To Promote The Right To InformationNo ratings yetDisclosure To Promote The Right To Information42 pages
- Practice: Modelling An E-Meter Using IEC 62056 DLMS/COSEMNo ratings yetPractice: Modelling An E-Meter Using IEC 62056 DLMS/COSEM11 pages
- Dokumen - Tips Dlmscosem Conformance Testing Figure 1 Dlmscosem Conformance Testing ProcessNo ratings yetDokumen - Tips Dlmscosem Conformance Testing Figure 1 Dlmscosem Conformance Testing Process44 pages
- Protocolo EM920 IEC 62056-21 Hfudsvdfvbkdb VNo ratings yetProtocolo EM920 IEC 62056-21 Hfudsvdfvbkdb V15 pages
- Implementing DLMS Client and Server Protocols in Meters, IED's, MRI's and Meter Reading Applications - An Overview - Gopalakrishnanprasanth100% (1)Implementing DLMS Client and Server Protocols in Meters, IED's, MRI's and Meter Reading Applications - An Overview - Gopalakrishnanprasanth7 pages
- Footprint Naming Convention - Surface Mount 3749778No ratings yetFootprint Naming Convention - Surface Mount 37497782 pages
- SICOM3005A Serial Port Server Web Operation Manual - V1.1No ratings yetSICOM3005A Serial Port Server Web Operation Manual - V1.174 pages
- Communicating With An Energy Meter Using Iec 62056 Through TCP - IpNo ratings yetCommunicating With An Energy Meter Using Iec 62056 Through TCP - Ip7 pages
- Electricity Metering Equipment (A.C.) - Particular Requirements - Part 22: Static Meters For Active Energy (Classes 0,2 S and 0,5 S)No ratings yetElectricity Metering Equipment (A.C.) - Particular Requirements - Part 22: Static Meters For Active Energy (Classes 0,2 S and 0,5 S)19 pages
- Recommendation For Block Cipher Modes of Operation - Galois Counter Mode (GCM) and GMAC (NIST SP800-38D) - Morris DworkinNo ratings yetRecommendation For Block Cipher Modes of Operation - Galois Counter Mode (GCM) and GMAC (NIST SP800-38D) - Morris Dworkin39 pages
- Security-Framework-in-DLMS-Whitepaper_2024No ratings yetSecurity-Framework-in-DLMS-Whitepaper_202422 pages
- (PETA 2015) 137006169 Robby Iswanto P PDFNo ratings yet(PETA 2015) 137006169 Robby Iswanto P PDF9 pages
- Practical Load Balancing Ride the Performance Tiger 1st Edition Peter Membrey - Download the ebook and start exploring right away100% (3)Practical Load Balancing Ride the Performance Tiger 1st Edition Peter Membrey - Download the ebook and start exploring right away47 pages
- Ccna 2 V7 Modules 10 - 13: L2 Security and Wlans Exam AnswersNo ratings yetCcna 2 V7 Modules 10 - 13: L2 Security and Wlans Exam Answers38 pages
- 5.2.1.7 Lab - Viewing The Switch MAC Address TableNo ratings yet5.2.1.7 Lab - Viewing The Switch MAC Address Table4 pages
- EPS Release 1 IOT Attach Detach Call FlowsNo ratings yetEPS Release 1 IOT Attach Detach Call Flows5 pages
- Interoperability and Vulnerabilities in VOIP Protocol (SIP, H.323)No ratings yetInteroperability and Vulnerabilities in VOIP Protocol (SIP, H.323)7 pages
- Data Communications and Networking 2 Lab Prelim AnswersNo ratings yetData Communications and Networking 2 Lab Prelim Answers4 pages
- DWR 956 (D Link) - Manual - tcm94 309334No ratings yetDWR 956 (D Link) - Manual - tcm94 30933472 pages
- The Art of Computer Networking 1st Edition Russell Bradfordinstant download100% (1)The Art of Computer Networking 1st Edition Russell Bradfordinstant download50 pages
- 7.3.2.6 Packet Tracer - Pinging and Tracing To Test The PathNo ratings yet7.3.2.6 Packet Tracer - Pinging and Tracing To Test The Path4 pages
- Teldat Dm704-I Configuration MonitoringNo ratings yetTeldat Dm704-I Configuration Monitoring238 pages
- Introduction of Classful IP AddressingNo ratings yetIntroduction of Classful IP Addressing10 pages
