DLMS协议——信息安全及应用层服务规范（三）

一、General block transfer (GBT) 总块传输

GBT机制可用于以块的形式传输任何-短或长的xDLMS APDU。使用GBT，块由通用块传输APDU携带，而不是特定于服务的“带数据锁”APDU。

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

• 双向块传输是指当一方发送块时，另一方不仅确认接收到的块，而且如果有块要发送，也可以在仍在接收块时发送；
  注：当需要向两个方向传输长服务参数时，双向块传输非常有用。
• 流媒体意味着一方可以发送多个区块，而不承认另一方的每个区块；
• 丢失块恢复意味着如果接收到未确认发送的块，则可以再次发送。如果使用流，则在每个流窗口的末尾发生丢失的块恢复。

GBT机制支持以下用例：
（1）客户端确认的短请求导致服务器的长响应：请求可以使用或不使用GBT发送。如果它是使用GBT发送的，那么客户端可能会在交换启动时发布其首选的GBT窗口大小。服务器使用GBT进行响应；

（2）客户端长期确认的请求：客户端使用GBT发送请求，服务器使用GBT发送响应，无论响应的长度是多少；

（3）客户端长期未确认的请求：客户端使用GBT发送请求；

（4）服务器长时间主动确认请求：服务器发送请求，客户端使用GBT发送响应；

（5）服务器长期未经请求的未经确认的请求：服务器使用GBT发送请求。

二、DLMS/COSEM中的信息安全

DLMS服务器的资源——COSEM对象属性和方法——可以由应用程序关联中的DLMS客户端访问。

在AA建立期间，客户端和服务器必须识别自己。服务器还可能要求客户机的用户标识自己。此外，服务器可能要求客户端对自己进行身份验证，而客户端也可能要求服务器对自己进行身份验证。

一旦建立了AA，xDLMS服务就可以用于访问COSEM对象的属性和方法，这取决于安全上下文和访问权限。

携带服务原语的xDLMS APDUs可以受到加密保护。所需的保护将由安全上下文和访问权限来决定。为了支持第三方和服务器之间的端到端安全性，这些第三方还可以使用客户端作为代理来访问服务器的资源。

此外，由xDLMS APDUs所携带的COSEM数据也可以被加密保护；

由于这些安全机制应用于应用程序进程/应用程序层级别，因此它们可以用于所有DLMS/COSEM通信配置文件中。

识别和认证

识别

DLMS/COSEM AEs被绑定到支持AL的协议层中的服务接入点（SAPs）上。这些SAP存在于AA中携带xDLMS APDUs的PDUs中。

客户端用户识别机制使服务器能够区分客户端上的不同用户，这些用户可能是操作员或第三方，以记录他们访问该设备的活动。

身份验证机制

认证机制确定了通信实体在AA建立期间用于验证自己的协议。

有三种不同的身份验证机制，具有不同的身份验证安全级别：

• 无安全性（最低级别安全性）身份验证；

无安全（最低级别安全）身份验证的目的是允许客户机从服务器检索一些基本信息。此身份验证机制不需要任何身份验证；客户端可以访问安全上下文中的COSEM对象属性和方法，以及给定AA中存在的访问权限。

• 低级安全（LLS）身份验证；

在这种情况下，服务器要求客户端通过提供服务器已知的密码进行身份验证。密码由当前建模要建立的SN的“关联SN/LN”对象持有。“关联SN/LN”对象提供了更改秘密的方法。

如果所提供的密码被接受，则可以建立AA，否则将被拒绝。

COSEM-OPEN服务支持LLS认证，如下所示：
（1）客户端使用COSEM-OPEN.request服务原语向服务器发送一个“密码”（一个密码）；
（2）服务器会检查这个“秘密”是否正确；
（3）如果是，则客户端将经过身份验证，并可以建立AA。从这一刻起，协商后的上下文就会是有效的；
（4）如果没有，AA将被拒绝；
（5）建立AA的结果应由服务器使用COSEM-OPEN.response服务原语和诊断信息发送回。

• 高级安全（HLS）身份验证。

在这种情况下，客户端和服务器都必须成功地验证自己才能建立AA。HLS身份验证是一个四遍进程（four-pass process），由COSEM-OPEN服务和“关联SN/LN”接口类的reply_to_HLS_authentication方法支持：

Pass 1:客户端向服务器发送一个“challenge”CtoS，并根据认证机制传输额外的信息；
Pass 2:服务器向客户端传输一个“challenge”StoC，并根据身份验证机制传输额外的信息；
如果StoC与CtoS相同，客户应拒绝它，并中止AA的建立流程。

Pass 3:客户端根据对给定AA有效的HLS认证机制的规则处理StoC和附加信息，并将结果发送给服务器。服务器将检查f（StoC）是否是正确处理的结果，如果是，它将接受客户端的身份验证；
Pass 4:然后，服务器根据对给定AA有效的HLS身份验证机制的规则，处理CtoS和附加信息，并将结果发送给客户端。客户端将检查f（CtoS）是否是正确处理的结果，如果是，它将接受服务器的身份验证。

COSEM Pass 1和Pass 2由COSEM-OPEN服务支持。

在Pass 2之后，如果提议的应用上下文和xDLMS上下文是可接受的，服务器使用协商的应用上下文授予对当前“关联SN/LN”对象的方法reply_to_HLS_authentication的访问权限。

Pass 3和Pass 4由“关联SN/LN”对象(s)的方法reply_to_HLS_authentication支持。如果Pass 3和4都成功执行，那么通过应用程序上下文和xDLMS上下文协商建立AA。

消息认证码

消息认证码（MAC）提供了真实性和完整性的保证。MAC是数据上的加密校验和，用于保证数据没有更改或被更改，并且MAC是由预期的方（发送方）计算出来的。通常，MAC在共享密钥的双方之间使用，以验证双方之间交换的信息。

消息身份验证代码(MACs)图

MAC（MAC）根据数据(K)计算MAC1）。然后保存或传输M1和MAC1。在以后的时间里，通过将检索到的或接收到的数据标记为M2，并使用相同的键(K)计算MAC（MAC2）来检查检索到的或接收到的数据的真实性。如果检索到或接收到的MAC（MAC1）与新计算的MAC（MAC2）相同，则可以假定检索到或接收到的数据（M2）与原始数据（M1）（即，M1 = M2)相同。验证方也知道发送方是谁，因为没有人知道钥匙（key）。

通常，MAC用于检测在MAC的初始生成和对接收到的MAC的验证之间发生的数据修改。它们不会检测到在最初生成MAC之前发生的错误。

对于DLMS/COSEM，应使用GMAC算法。

GCM功能

组成GCM的两个功能称为验证加密和验证解密；参见下图。

经过身份验证的加密功能会对机密数据进行加密，并在机密数据和任何额外的非机密数据上计算一个身份验证标签。经过验证的解密功能根据标签的验证情况对机密数据进行解密。

当输入被限制为非机密数据时，GCM的结果变体被称为GMAC。对于GMAC，验证加密和解密功能成为在非机密数据上生成和验证验证标签的功能。

最后，如果不需要身份验证，则经过身份验证的加密功能会对机密数据进行加密，但不会计算身份验证标签。认证解密功能对机密数据进行解密，但不计算和验证认证标签。

a)认证加密功能-给定选择一个块密码密钥EK-有三个输入字符串：

• 明文，记为P；
• 附加身份验证数据（AAD），记为A；
• 一个初始化向量（IV）表示为IV。

明文和AAD是GCM保护的两类数据。GCM保护明文和AAD的真实性；GCM还保护明文的机密性，而AAD则保持清晰。
IV本质上是一个nonce，即在指定的（安全）上下文中唯一的值，它决定了对要保护的输入数据调用经过身份验证的加密函数。

经过认证的加密功能的输入字符串的位长应满足以下要求：

P、A和IV的位长度均为8的倍数，因此这些值是字节字符串。

有两个输出：

• 一个密文，表示为C，其位长与明文P相同；
• 身份验证标签，简称T。

b)经过认证的解密功能-给定选择一个块密码密钥EK-有四个输入字符串：

• 初始化向量，记为IV；
• 密码文本，用C表示；
• 附加的身份验证数据（AAD），记为A；
• 认证标签，标记为T。

输出的是以下内容之一：

• 对应于密文C的明文P，或者
• 一个特殊的错误代码表示为失败。

输出P表示T是IV、A、C的正确认证标签，否则输出为FAIL。

保护xDLMS APDUs

当AP调用与COSEM对象属性或方法相关的xDLMS服务原语时，服务参数将包括“
（ Security_Options ）安全选项”参数。该参数通知AL要使用的密码APDU类型、应用的保护，并包括必要的安全材料。AL首先构建与服务原语对应的APDU，然后构建加密的APDU。

当AL从远程合作伙伴收到加密的APDU时，它会破译它并恢复原始的未加密APDU。当此操作成功完成后，它将调用适当的属性服务文件。附加的服务参数包括安全状态（Security_Status）和保护元素（Protection_Element）参数，这些参数通知AP使用的加密APDU类型，已验证和删除的保护，可能包括安全材料。

对COSEM对象属性和/或方法的访问权限可能需要经过身份验证，加密和/或签名的xDLMS APDU。因此，始终允许具有比安全策略要求的更多的保护的 APDU。保护低于安全策略和访问权限要求的 APDU 将被拒绝。

在此上下文中，更多的保护意味着在 xDLMS APDU 上应用的保护种类比安全策略请求的保护种类更多：例如，安全策略要求对所有 APDU 进行身份验证，但访问权限要求对 APDU 进行加密和身份验证，即更高的保护。

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

保护 COSEM 数据

应用于xDLMS APDU的密码算法也可以应用于COSEM数据，即属性值和方法调用/返回参数。这是通过“数据保护”接口类的实例间接访问其他 COSEM 对象的属性和/或方法来实现的。

要保护的数据列表、所需的保护和保护参数由“数据保护”对象确定。

“数据保护”（Data protection）对象允许在读取或写入属性列表或调用 COSEM 对象的方法时应用或删除保护。要应用/删除的保护可能包括身份验证、加密和数字签名的任意组合。

承载服务调用以访问“数据保护”对象的属性和方法的 APDU 根据现行安全策略和“数据保护”对象的访问权限的要求受到保护。

COSEM-OPEN service参数——专用密钥

专用键元素是有条件的。只有当Application_Context_Name参数使用密码指示应用程序上下文时，它才会出现。专用密钥用于在已建立的AA内交换的xDLMS APDU的专用密码。

当专用密钥不存在时，则不必保护xDLMS初始请求APDU。

当该专用密钥存在时，xDLMS初始请求APDU应受到保护，即至少使用AES-GCM算法、全局单播加密密钥和验证密钥（如果使用）进行验证和加密。此外，如果安全政策要求，还应进行数字签名。

当专用密钥不存在时，xDLMS初始请求APDU应得到与上述方法相同的保护，但必须通过在其用户信息字段中包含受保护的xDLMS初始请求来保护RLRQ APDU。

三、DLMS/COSEM 应用层服务规范

服务基元和参数

通常，层（或子层）的服务是它在下一个较高层（或子层）中为用户提供的功能。为了提供服务，层在其从下一个较低层获得的服务上构建其功能。下图说明了服务层次结构的这一概念，并显示了两个对应的 N 个用户及其关联的 N 层对等协议实体之间的关系。

服务是通过描述 N 层用户和 N 层之间的信息流来指定的。这种信息流由离散的瞬时事件所驱动，这是提供服务的特征。每个事件都包括通过与 N 用户关联的 N 层服务接入点将服务原语从一层传递到另一层。服务原语传达提供特定服务所需的信息。这些服务基元是一种抽象，因为它们仅指定提供的服务，而不是提供服务的方式。服务的此定义独立于任何特定的接口实现。

通过描述表征每个服务的服务基元和参数来指定服务。服务可以具有一个或多个相关原语，这些原语构成与特定服务相关的活动。每个服务原语可以具有零个或多个参数，用于传达提供服务所需的信息。基元有四种泛型类型：

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

图112所示的时序图说明了基元类型之间的可能关系。该图还指示基元类型的逻辑关系。在时间较早出现并在关系图中通过虚线连接的基元类型是后续基元类型的逻辑前因。

The ACTION service（操作服务） 示例

操作服务使用LN引用。它可以以已确认或未确认的方式调用。它的函数是调用一个或多个COSEM对象方法。它包括两个阶段：

• 在第一阶段，客户端发送要调用的方法的引用，需要用方法调用参数；
• 在第二阶段，调用方法后，服务器返回结果和调用方法生成的返回参数，如果有的话。

如果方法调用参数太长，无法适合于单个请求，则它们将以多个请求的形式发送（阻止从客户端到服务器的传输）。如果结果和返回参数太长，无法适应单个响应，则它们将以多个响应的形式返回（从服务器到客户端的块传输）。

操作服务的服务参数：

Invoke_Id参数标识了服务调用的实例。

Priority优先级参数表示与服务调用实例关联的优先级级别：正常（FALSE）或高（TRUE）。

Service_Class参数表示服务是已确认还是未确认。此参数的处理取决于通信配置文件。

Request_Type参数的使用如下表所示。
操作服务请求和响应类型：

COSEM_Method_Descriptor参数引用了一个COSEM对象方法。如果存在Request_Type == NORMAL, FIRST-BLOCK, WITH-LIST and WITH-LIST-AND-FIRST-BLOCK。它是一个复合参数：

• （COSEM_Class_Id，COSEM_Object_Instance_Id）双态明确地引用了一个且只有一个COSEM对象实例；
• COSEM_Method_Id标识了被引用的COSEM对象的一个方法。

ACTION-REQUEST-NORMAL 或 ACTION-REQUEST-FIRST-BLOCK service 原语应包含单个COSEM方法描述符。ACTION-REQUEST-WITH-LIST 或 ACTION-REQUEST-WITH-LIST-AND-FIRST-BLOCK 应包含COSEM方法描述符列表；其数量受服务器最大接收大小的限制：所有COSEM方法引用以及方法调用参数的（部分）应适合单个APDU。

方法调用参数参数参数包含了调用所引用的方法所需的参数。

• 如果 Request_Type == NORMAL，Method_Invocation_Parameter（方法调用）参数是可选的；
• 如果 Request_Type == WITH-LIST ，则服务原语应包含Method_Invocation_Parameters（方法调用）参数的列表。方法调用参数的数量和顺序应与COSEM_Method_Descriptor-s的参数相同。如果调用任何方法不需要额外的参数，它仍然存在，但应为空数据。

如果COSEM方法描述符(s)和方法调用参数(s)的编码形式不适合单个APDU，则可以使用特定服务或通用块传输机制以块形式传输。

如果使用了特定于服务的块传输机制，则DataBlock_SA参数携带块传输控制信息和原始数据：

• Last_Block元素指示当前块是否是最后一个（TRUE）/（false）；
• Block_Number元素携带实际发送的块的数量；
• Raw_Data元素携带方法调用参数的一部分。

当Response_Type == NORMAL, or WITH-LIST.时，Action_Response参数出现在 .response原语中。它们的数量和顺序应与COSEM方法描述符相同。它由两个元素组成：

• the Result parameter（结果参数）。它包含调用成功或未能调用所引用的方法的原因（操作结果）；
• the Response_Parameter(s)响应参数(s)。每个响应参数应包含调用方法后返回的数据，或返回参数失败的原因（Data-Access-Result（数据访问-结果））。如果调用任何一种方法没有返回参数，则应返回空数据。

如果响应不适合于单个APDU，则可以使用特定的服务或通用的块传输机制进行块传输。

如果使用特定于服务的块传输机制，则DataBlock_SA参数携带块传输控制信息和原始数据：

• Last_Block元素指示当前块是否是最后一个（TRUE）\（false）；

• Block_Number元素携带实际发送的块的数量；

• Raw_Data元素包含部分响应：

  • 如果调用了单一方法，Raw_Data会携带结果，如果有，则携带“响应参数（Response_Parameters）”；
    注意：如果没有返回响应参数，则响应应为动作-响应异常（ACTION -RESPONSE-NORMAL.）类型。
  • 如果调用了一个方法列表，那么Raw_Data将携带一部分 Action_Response-s列表和可选数据。

ACTION-REQUEST-NEXT service 原语中的Block_Number参数应正确携带从服务器接收到的最新数据块数。

ACTION-RESPONSE-NEXT service 原语中的Block_Number参数应正确携带从客户端接收到的最新数据块数。

ACTION 服务原语的可能逻辑序列如图 112 所示：

• 对于成功确认的行动，第 a 项）;
• 对于未经确认的行动 ，项目 d）;
• 由于本地错误项 c） 而导致尝试失败。

在第一阶段，客户端 AP 调用 ACTION.request 原语来调用服务器 AP 的一个或多个 COSEM 对象的一个或多个方法。如果 COSEM 方法描述符和方法调用参数的完整列表适合单个 APDU，则根据需要使用 Request_Type == NORMAL 或 WITH -LIST 调用 .request 原语。否则，它会使用 Request_Type == FIRST-BLOCK 或 WITH-LIST-AND-FIRST-BLOCK 调用，然后使用 Request_Type == ONE-BLOCK，最后使用 LAST-BLOCK。收到 .request 原语后，客户端 AL 会构建适用于Request_Type的操作请求 APDU 并将其发送到服务器。

ACTION.indication原语由服务器 AL 在收到 Action -Request APDU 时生成。

在方法调用参数的块传输期间，服务器 AP 使用 Request_Type == NEXT 调用 ACTION.response 原语，直到接收最后一个块。

ACTION.confirm 原语由客户端 AL 在收到 Action -Response APDU 时生成。

传输完所有方法调用参数后，服务器将调用引用的 COSEM 对象的方法，第二阶段开始。

如果完整的响应适合单个 APDU，则服务器 AP 会根据需要使用 Response_Type == NORMAL 或 WITH -LIST 调用 ACTION.response 原语。否则，会用 Response_Type == ONE-BLOCK 调用，最后用 LAST -BLOCK 调用。收到 .response 原语后，服务器 AL 会构建适用于Response_Type的动作-响应 APDU，并将其发送到客户端。

ACTION.confirm 原语由客户端 AL 生成，用于指示接收操作响应（Action - Response） APDU。

在返回参数的块传输期间，客户端 AP 使用 Request_Type == NEXT 调用 .request 原语，直到收到最后一个块。

The ACSE services and APDUs （ACSE 服务和 APDU）

ACSE 功能单元、服务和服务参数

功能单元用于在关联建立期间协商 ACSE 用户要求。定义了五个功能单元：

• 内核功能单元;
• 认证功能单元;
• ASO上下文协商功能单元;（ASO-context 与 Application context 相同）；
• 上级协商功能单元；
• 嵌套关联功能单元。

DLMS/COSEM AL 仅使用内核和身份验证功能单元。

AARQ 和 AARE APDU 的acse-requirements参数用于选择关联的功能单元。

通常，AARQ APDU 的每个字段的值由 COSEM OPEN.request 服务原语的参数确定。类似地， AARE 的每个字段都由 COSEM-OPEN.response 原语确定。

AARQ 和 AARE APDU 的字段指定如下：

• protocol-version-协议版本：DLMS/COSEM AL 使用默认值版本 1；

• application-context-name-应用程序上下文名称；

• called-, calling- and responding- titles, qualifiers and invocation-identifiers-被叫、呼唤和响应的标题、限定符和调用标识符：这些可选字段承载 COSEM -OPEN 服务相应参数的值。有关详细信息；

• implementation-information 实现信息：DLMS/COSEM AL 不使用此字段；

• user-information 用户信息：在 AARQ APDU 中，它携带一个 xDLMS InitiateRequest APDU，其中包含 COSEM -OPEN.request service 原语的Proposed_xDLMS_Context参数元素。在 AARE APDU 中，它携带一个 xDLMS InitiateResponse APDU，保存 Negotiated_xDLMS_Context 参数的元素，或者一个 xDLMS confirmedServiceError APDU，保存 COSEM -OPEN.response 服务原语的xDLMS_Initiate_Error参数的元素；

• sender- and responder-acse-requirements 发送方和响应方 ACSE 要求：此字段用于选择 AARQ / AARE 的可选功能单元。在 COSEM 中，仅使用身份验证功能单元。如果存在，它带有位字符串 { 身份验证 （0） } 的值。位组：选择功能单元；

• mechanism-name 机制名称；

• calling- and responding- authentication-value 调用和响应身份验证值；

• result 结果：此字段的值由 COSEM AP（接受器）或 DLMS/COSEM AL （ACPM） 确定，如下所述。它用于确定 COSEM-OPEN 的结果参数的值；

  • 如果 AARQ APDU 被 ACPM 拒绝（即 COSEM -OPEN.指示原语不是由 DLMS/COSEM AL 发布的），则值“拒绝（永久）”或“拒绝（瞬态）”由 ACPM 分配；
  • 否则，该值由 COSEM -OPEN.response APDU 的结果参数确定。

• result-source-diagnostic 结果源诊断：此字段包含“结果源”值和“诊断”值。它用于确定 COSEM -OPEN 的 Failure_Type 参数的值。

  • Result-source value 结果源值：如果 AARQ 被 ACPM 拒绝（即 DLMS/COSEM AL 不发布 COSEM -OPEN.INDICATION 原语），ACPM 将分配值“ACSE 服务提供商”。否则，ACPM 将分配值“ACSE 服务 - 用户”；
  • Diagnostic value 诊断值：如果 AARQ 被 ACPM 拒绝，则由 ACPM 分配适当的值。否则，该值由 COSEM OPEN.response 原语的 Failure_Type 参数确定。如果诊断参数未包含在 .response 原语中，ACPM 将分配值“null”。

下面指定了 RLRQ / RLRE APDU 的参数 – 在调用 COSEM-RELEASE 服务时使用参数 Use_RLRQ_RLRE == TRUE 时使用。

• reason 原因：携带指定的适当值；
• user-information 用户信息：如果存在，它带有一个xDLMS InitiateRequest / InitiateResponse APDU，分别包含COSEM-RELEASE.request / .response服务原语的Propo sed_xDLMS_Context / Negotiated_x DLMS_Context参数的元素。

四、Protocol for application association release( 应用程序关联发布协议)

概述

现有 AA 可以正常或非正常释放。正常释放由客户端 AP 启动。当 AP 发生意外事件（例如检测到物理断开连接）时，将发生非正常释放。

正常释放应用程序关联

DLMS/COSEM 提供了两种机制来释放 AA：

• 通过断开AL的支持协议层；
• 通过使用 ACSE A-Release服务。

第一种机制应在AL的支持协议层面向连接的所有配置文件中受支持。

例子：
基于 HDLC 的 3 层面向连接的配置文件。

要以这种方式释放 AA，COSEM -RELEASE 服务应在 Use_RLRQ_RLRE 参数不存在或 FALSE 的情况下调用。断开支持协议层的连接应释放在该支持协议层连接上构建的所有 AA。

第二种机制可用于在不断开支持协议层的情况下释放 AA。当支持协议层无连接时，所有配置文件都应支持它。当支持协议层是面向连接的，但连接不受AL管理，或者由于其他应用程序可能使用它而断开支持协议层不切实际，或者当需要保护COSEM -RELEASE服务时，也可以使用它。这是释放未经证实的 AA 的唯一方法。

要以这种方式释放 AA，应使用 Use_RLRQ_RLRE 参数 = TRUE 调用 COSEM -RELEASE 服务。如 9.3.3 中所述，COSEM-RELEASE 服务可以通过分别在 RLRQ / RLRE APDU 的用户信息字段中包含加密的 xDLMS InitiateRequest / InitiateResponse 来保护，从而防止潜在的拒绝服务攻击。

使用 ACSE A -RELEASE 服务释放 AA 的示例如图 117 所示。

希望使用 A -RELEASE 服务释放 AA 的客户端 AP 应使用 Use_RLRQ_RLRE == TRUE 调用 COSEM RELEASE.request 服务原语。客户机 CF 进入关联发布挂起状态。然后，它构造一个 RLRQ APDU 并将其发送到服务器。如果要发布的 AA 已使用加密上下文建立，则 RLRQ APDU 的用户信息字段可能包含加密的 xDLMS InitiateRequest APDU。请参阅 9.3.3.

当服务器 AL CF 收到 RLRQ APDU 时，它会首先检查用户信息字段是否包含加密的 xDLMS InitiateRequest APDU。如果是这样，它会尝试破译它。如果成功，它将生成 ASSOCIATION RELEASE PENDING 状态，并生成一个 COSEM -RELEASE.indication 原语，Use_RLRQ_RLRE == TRUE。否则，它会以静默方式丢弃 RLRQ APDU 并保持在关联状态。

服务器 AP 调用 .response 原语来指示是否接受 AA 的释放，但前提是确认要释放的 AA。请注意，服务器 AP 无法拒绝释放请求。在收到 .response 原语后，服务器 AL CF 构造一个 RLRE APDU 并将其发送到客户端。如果 RLRQ APDU 包含加密的 xDLMS i nititateRequest APDU，则 RLRE ADU 应包含加密的 xDLMS InitiateResponse APDU。服务器 AL CF 返回到空闲状态。

.confirm 原语由客户端 AL CF 在接收 RLRE APDU 时生成。支持协议层不会断开连接。客户机 AL CF 返回到空闲状态。

如果收到的 RLRE APDU 包含加密的 xDLMS InitiateResponse APDU，但无法破译，则 RLRE APDU 应丢弃。留给政府来应对这种情况。

图 118 给出了通过断开相应的下层连接来正常释放已确认的 AA 的示例。

希望释放不使用 A -RELEASE 服务的 AA 的客户端 AP 调用 COSEM RELEASE.request 原语，Use_RLRQ_RLRE == FALSE 或不存在。客户机 AL CF 进入“关联发布挂起”状态。

在 RLRQ 服务是必需的通信配置文件中，调用不带 Use_RLRQ_RLRE 或 Use_RLRQ_RLRE = = FALSE 的 .request 原语可能会导致错误：.request 应在本地进行负面确认。客户机 AL CF 返回到空闲状态。

当客户机 AL CF 收到 .request 原语时，它会向服务器发送 XX -DISCONNECT.request 原语。

当服务器 AL CF 收到 XX-DISCONNECT.request 原语时，CF 将进入 ASSOCATION RELEASE PENDING 状态。COSEM -RELEASE.indication 原语由服务器 AL CF 生成，Use_RLRQ_RLRE == FALSE 或不存在。

COSEM-RELEASE.response 原语由服务器 AP 调用，以指示是否接受 AA 的版本。请注意，服务器 AP 无法拒绝释放请求。收到此原语后，服务器 AL CF 向 clie nt 发送 XX -DISCONNECT.response 原语并返回到空闲状态。

COSEM-RELEASE.confirm原语由客户端AL在xx断开连接时生成。确认原语。支持的协议层已断开。客户端AL CF返回到IDLE状态。

应用程序关联的非正常释放

各种事件可能会导致 AA 的非正常释放：检测任何较低层连接（包括物理连接）的断开连接、消除本地错误等。

在 COSEM ABORT 服务的帮助下，向 COSEM AP 指示 AA 的非正常释放（中止）。此服务的诊断参数指示非正常 AA 版本的原因。AA 的非正常释放不是选择性的：如果发生这种情况，所有现有关联（除了预先建立的关联）都将中止。

图 119 显示了由于检测到物理断开连接而中止 AA 的消息序列图。

五、Protocol for the data transfer services（数据传输服务的协议）

服务和选项的协商——一致性块

一致性块允许客户端和服务器使用相同的 DLMS/COSEM 协议，但支持不同的功能来协商一组兼容的功能，以便它们可以通信。它由 COSEM -OPEN 服务的DLMS_Conformance参数承载。

在DLMS/COSEM中，没有任何服务或选项是强制性的：要使用的服务或选项通过COSEM-OPEN服务（xDLMS InitiateRequest APDU的提议一致性参数和xDLMS InitiateResponse APDU的协商一致性参数）进行协商。已实现的服务应完全符合其规范。如果协商的一致性块中不存在服务或选项，则客户端不应请求该服务或选项。

已确认和未确认的 xDLMS 服务调用

客户端的服务调用

通常，xDLMS 服务可以以已确认或未确认的方式调用。
服务原语的时间顺序对应于：图112见上

• 图 112 项 a） 在确认服务调用的情况下;和
• 图 112 项 d） 在未经确认的服务调用的情况下。

需要访问 COSEM 对象的属性或方法的客户端 AP 调用相应的 .request 服务原语。客户端 AL 构造与 .request 原语对应的 APDU 并将其发送到服务器。

收到 .indication 原语后，服务器 AP 检查是否可以提供服务（有效性、客户端访问权限、可用性等）。如果可以，它会在本地应用相应的“真实”对象上所需的服务。在确认服务的情况下，服务器 AP 调用相应的 .response 原语。服务器 AL 构造与 .response 原语对应的 APDU 并将其发送到客户端。客户端 AL 生成 .confirm 原语。

如果服务器 AL 无法处理已确认的服务请求（例如，在没有先建立 AA 的情况下收到请求，或者请求在其他方面是错误的），则服务器 AL 要么被丢弃，要么在可能的情况下，服务器 AL 使用确认的服务错误 APDU 进行响应，或者在实现时使用 ExceptionResponse APDU 进行响应。这些 APDU 可能包含有关无法处理请求的原因的诊断信息。它们在 9.5 中定义。

在已确认的 AA 中，可以以已确认或未确认的方式调用 xDLMS 服务。

在未经确认的 AA 中，xDLMS 服务只能以未经确认的方式调用。这样，就可以避免在多广播和/或广播的情况下由于潜在的多种响应而导致的冲突。

在未经确认的服务的情况下，可以使用三种不同类型的目标地址：单播、组播或广播。根据目标地址类型，接收站应以不同的方式处理传入的 APDUS，如下所示：

• 具有 COSEM 逻辑设备单个地址的 XX-APDU。如果在已建立的 AA 内收到它们，则应将其发送到寻址的 COSEM 逻辑设备，否则应丢弃它们；
• 具有一组 COSEM 逻辑设备的组地址的 XX-APDU。这些应发送到寻址的COSEM逻辑设备组。但是，如果在客户端和寻址的 COSEM 逻辑设备组之间没有建立 AA，则应丢弃接收到的消息；
• 具有广播地址的 XX-APDU 应发送到所有寻址的 COSEM 逻辑设备。但是，如果客户端和全站地址之间没有建立 AA，则应丢弃收到的消息。

注意：
客户端和一组逻辑设备之间的未经确认的 AA-s 使用 COSEM -OPEN 建立具有 Service_Class == 未确认和一组逻辑设备地址（例如广播地址）的服务。

服务器调用服务（未经请求的服务）

服务器可能调用的未经请求的服务包括：

• InformationReport——信息报告；
• EventNotification——事件通知；
• DataNotification——数据通知。

信息报告和事件通知服务只能以一种未经确认的方式被调用。对应的时间序列图为图112项，第d项)。

可以通过三种不同的方式调用数据通知服务：
（1）未确认，支持协议层故障重试;
（2）未确认，缺少支持协议层确认时重试;
（3）已确认，缺少确认时重试。

服务原语的时间顺序对应于：
上述（1）中对应图112的第的d）项；
上述（2）中对应图112的第的b）项；
上述（3）中对应图112的第的a）项；

GBT程序（9.4.6.13.2）

概述：它可以是

• 确认，携带与任何已确认的 xDLMS 服务的服务原语相对应的 APDU;
• 未经确认，将对应于未经请求的服务原语的 APDU 从客户端传送到服务器，或将对应于未经请求的服务请求的 APDU 从服务器传送到客户端。

注意 GBT 通常与 DataNotification 和 Access 服务一起使用。

GBT 过程在客户端和服务器端基本相同。在以下情况下，AL 会调用它：

a） AP 调用服务原语 – .request 或 .response，并且：

• Invocation_Type = COMPLETE or FIRST-PART（完整或第一部分），存在 GBT 参数 BTS 和 BTW;
• 要发送的编码和加密保护的 APDU 太长，无法适应协商的最大 APDU 大小;

b） 从对等方收到 GBT APDU。
GBT程序包括三个子程序：

• （1）发送 GBT APDU 流；
• （2）处理GBT APDU；
• （3）检查 RQ 并填充间隙（gaps）；

AL 调用这些子过程。

GBT 过程的模型使用发送队列 SQ 和接收队列 RQ。队列中的每个块 B 都有一个块号 BN、一个标志 LastBlock L B 和一个有效负载 BlockData BD（可能为空）。队列按 BN 排序。

SQ 在处理 AP 调用的服务原语后由 AL 填充，即：

• 建立APDU；
• 按照保护参数的规定应用加密保护;
• 将受保护的 APDU 拆分为块。

对于所有服务原语，可以按照图 113 和图 139 中的 9.3.5 和 9.4.6.13 中的规定使用部分服务调用。但是，这对GBT协议没有影响。服务Invocation_Type可以是完整的、第一部分、一部分或最后一部分（COMPLETE, FIRST-PART, ONE-PART or LAST-PART）。每个服务调用都会向 SQ 添加一个或多个块。每次添加新块时，块编号 BN 都会递增。

SQ 中的块由发送 GBT APDU 流子过程发送。

RQ 由处理 GBT APDU 子过程填充。RQ 中的空白 - 在确认GBT程序的情况下 - 由Check RQ和填充空白子程序填补。

已确认的GBT程序

确认的 GBT 过程可能由本地服务调用或从对等方接收 GBT APDU 触发。

由服务调用触发的已确认 GBT 过程

当 AP 调用服务原语并且需要 GBT 时 – AL 将块填充到 SQ 并调用发送 GBT APDU 流子过程;见9.4.6.13.4。发送 GBT 流的最后一个块后，控制权将返回给 AL。

然后，AL 侦听来自对等方的 APDU。

在客户端，如果在特定于实现的超时内未收到 APDU，则客户端 AL 认为收到的流已完成，并调用检查 RQ 和填充间隙子过程。

收到 APDU 后，AL 会检查它是否为 GBT APDU。（注 ： 这是根据收到的 APDU 标签确定的。）

处理收到的 GBT APDU 后，控制权将返回给 AL：

• 如果流尚未完成，则控制权将返回给等待来自对等方的下一个 APDU 的 AL;
• 如果流完成，AL 将调用Check RQ 和填充间隙子（fill gaps）过程。

如果找到间隙（gaps），则控件将返回给再次调用发送 GBT APDU 流子过程的 AL。

如果未找到间隙，则控制权将返回给 AL，并将 RQ 中的块传递进行处理：

• RQ 中的块与先前收到的流的结果连接;
• 验证并删除加密保护;
• APDU 被解码;
• 调用相应的服务原语。

注 : 处理结果可能会导致服务调用 Invocation_TYPE COMPLETE, FIRST-PART, ONE-PART or LAST-PART(完整、第一部分、部分或最后一部分)。

发送 GBT APDU 和处理 GBT APDU / Check RQ 和填充空白子过程由发送方和接收方交替调用，直到 GBT 交换完成。

当 GBT 过程用于传输已确认的客户端-服务器服务时，服务器确认客户端的最后一个块，但客户端不确认服务器的最后一个块。因此：

• 在客户端，当客户端 LB 被 ACKd 并且服务器 LB 已传递给 AL 时，该过程结束（即，来自服务器的所有块都已收到，没有间隙）;
• 在服务器端，当客户端 LB 已确认、服务器 LB 已发送且客户端未启动丢失块 recovery 时，该过程结束。

当 GBT 过程用于传输未经请求的已确认服务（由服务器启动）时，客户端确认服务器的最后一个块，但服务器不确认客户端的最后一个块。因此：

• 在服务器端，当服务器 LB 已发送且客户端 LB 已收到时，该过程结束;
• 在客户端，当服务器 LB 被传递给 AL（即，从服务器收到的所有块都没有间隙）并且客户端 LB 被发送时，该过程结束;
• 如果服务器未收到响应，则可能会重试发送请求。

从对等方接收 GBT APDU 触发的已确认 GBT 程序

如果 GBT 过程尚未启动，并且 AL 收到 GBT APD U，它将调用处理 GBT APDU 子过程;见9.4.6.13.5。从这一点开始，GBT程序开始并如上所述继续。

未经证实的GBT程序

在这种情况下，发送方使用“发送 GBT APDU 流”子过程发送单个流，接收方使用“处理 GBT APDU”子过程接收单个流。

如果使用 GBT 过程传输未经确认的客户端-服务器服务请求，并且无法完成流，则客户端应解决这种情况。

如果使用 GBT 过程传输未经请求、未经确认的请求并且流无法完成，则客户端（在超时后）认为从服务器接收的流已完成，并调用检查 RQ 和填充间隙(Check RQ and fill gaps)子过程。

收到完整流后，AL 调用检查 RQ 并填充间隙子过程.

如果缺少任何块，则不会处理收到的块，并且未确认的GBT程序将结束。

未经确认的GBT程序结束：

• 在发送方，当最后一个块被发送时;
• 在接收方，当收到最后一个区块时;
• 当在 RQ 中发现一个或多个间隙时。

发送GBT APDU流子过程

发送 GBT 流子过程（如图 141 所示）用于已确认和未确认的 GBT 过程。

它将块 B 的序列 S 发送到对等方。当 SQ 中有块时，AL 会调用它，或者由 GBT 过程本身调用它，以确认流中收到的块并从 SQ 发送更多块。