IEC62056-53-2 中文

1、附录A（规范性附录）面向连接的基于HDLC三层模型A.1 引言 COSEM应用层仅是包含COSEM特定的服务组件、扩展的DLMS应用服务组件(xDLMS-ASE)的协议层。 该应用层可以使用各种不同的低层协议完成通信功能，一个完整的协议栈（包括应用层）称之为通信模型（参见第4章）。 通信模型的特征取决于：· 低层协议层；· 应用层中应用控制服务组件（ACSE）类型（面向连接或无连接）。 COSEM制定的第一个标准化的通信模型是一个面向连接的、基于HDLC的三层模型，该模型由三个协议层组成：· COSEM应用层，其应用层中包含面向连接的ACSE，在本部分中定义；&#

2、183; 数据链路层，基于ISO/IEC 13239 HDLC协议，在 IEC 62056-46中定义；· 物理接口层，在IEC 62056-42中定义。A.2 基于HDLC的数据链路层 综述 为了构建本通信模型，从 HDLC标准ISO/IEC 13239中选择下列内容：· 非平衡连接模式的数据链路层操作 在COSEM中，主站对应于客户应用，从站仍是从站。）；· 两通道交替数据传输；· 选择HDLC类过程是UNC (非平衡操作正常响应模式类)，采用UI帧扩展；· 帧格式类型3；· 非要素透明帧格式。 在非平衡连接模式数据链路操作中，要

3、涉及两个或多个站，主站通过发送命令帧负责组织数据流和处理不可恢复的数据链路级出错情况，从站通过发送响应帧来响应主站的命令。 为了提供组播、广播以及从服务器到客户机的非请求信息传送功能，过程的UNC类的基本命令和响应集采用不计数信息（UI）帧进行扩展，以支持无连接的数据通信服务。使用非平衡连接模式数据链路操作意味着客户机和服务器侧的数据链路层的HDLC帧集和状态机不相同。A.2.1 基于HDLC的数据链路层服务 基于HDLC的数据链路层提供的服务包括：· 数据链路层连接管理；· 面向连接的数据通信（I帧）；· 无连接的数据通信（UI帧）。A.2.1.1 客户机侧的服

4、务图A.1概括了COSEM客户机应用层面向连接的基于HDLC三层通信模型中数据链路层服务。 图A.1 客户机COSEM应用层使用的数据链路服务对某些服务，对应于应用层（ASO）服务调用和支撑数据链路层服务调用之间的通信是直接的（例如，COSEM-OPEN.request服务调用直接意味着调用DLCONNECT.request服务）。对其它服务，不能建立这种直接的服务映射。A.2.1.2 服务器侧的服务图A.2概括了COSEM服务器应用层使用面向连接的基于HDLC的三层通信模型中数据链路层的服务。图A.2 服务器COSEM应用层使用的数据链路服务 与客户机类似，对某些服务，应用层（ASO）服务调

5、用和支撑数据链路层服务调用之间的通信是直接的，对其它服务，不能被建立这种直接的服务映射。 为了支持从服务器到客户机透明的长数据传送，服务器侧规定了本地的DLDATA.confirm服务。A.2.1.3 面向连接的基于HDLC三层模型的特殊组件A.2.1.3.1 支持应用连接的特别特征 在COSEM环境中，一个AA完全由客户机和服务器应用进程使用的一对低层SAPs所标识，换而言之，在应用连接和支持该AA的低层连接之间存在着一一对应的关系。 在基于HDLC的CO三层模型中，每个AA都与一个支撑数据链路层连接相对应，建立一个AA意味着建立一个客户机和服务器数据链路层之间的连接。请求建立此连接的地址信

6、息包含在COSEM-OPEN的Protocol_Connection_Parameters服务参数中，此信息包括下列数据：Server_Lower_MAC_Address, (COSEM物理设备地址)Server_Upper_MAC_Address, (COSEM逻辑设备地址)Client_MAC_Address,Server_LLC_Address,Client_LLC_Address 任何一个服务器（目的站）的地址参数都可以包含特殊的地址(ALL_STATION，NO_STATION，等等)，此外，此模型在建立连接时还要遵循下列规则：· COSEM-OPEN.request服务的

7、User_Information服务参数（参见6.5.1.2）要插入到SNRM HDLC帧的“用户数据子字段”中，在建立数据链路连接时发送。在服务器侧，如果接收到SNRM帧包含“用户数据子字段”，则此字段的内容应通过COSEM-OPEN.indication服务的user_information服务参数（参见6.6.1.2）传送给服务器的应用进程。· 如果客户机应用层采用无确认的COSEM-OPEN.request 服务调用(参照6.5.1.2)发送一个AARQ帧，则该帧应采用UI（不计数的信息）类型的HDLC帧来发送 。在COSEM中，通常通过断开低层连接来断开应用连接，参照6.5

8、.2。在面向连接的基于HDLC的三层模型中，调用COSEM-RELEASE.request服务原语将导致相应的HDLC连接的断开，数据链路层使用DISC命令帧并且UA/DM响应HDLC帧（参见IEC 62056-46）。对于AA的正常或异常断开，要遵循以下附加规则：· 在COSEM-RELEASE.request服务中出现User_Information服务参数时（参见6.5.2.2），它应插入到DISC HDLC帧的“用户数据子字段”中，在断开数据链路连接时发送，如果被服务器接收到的DISC帧包含“用户数据子字段”， 则此字段的内容应通过COSEMRELEASE.indicatio

9、n服务的user_information服务参数（参见6.6.1.2）传送给服务器的应用进程。· 在COSEM-RELEASE.response服务中出现User_Information服务参数时（参见6.6.2.2），它应插入到UA或DM HDLC帧的“用户数据子字段”中发送，用于响应DISC帧。如果客户机接收到的UA或DISC帧包含“用户数据子字段”， 则此字段的内容应通过COSEM-RELEASE.confirm服务的user_information服务参数（参见6.5.2.3）传送给客户机的应用进程。· COSEM-ABORT.indication 服务的诊断参数(

10、参见 6.5.2.4和6.6.2.3)可包含一个不计数信息的发送状态参数，这个参数指示当物理层异常终止指示时刻，数据链路层是否还有待发的不计数信息报文（UI），此参数的类型和值是本地发出的，它不在本部分范围之内。A.2.1.3.2 数据通信服务的特别特征 在本模型中数据通信服务没有特别特征/服务参数，对数据通信服务，COSEM应用层是完全透明的。 确认的数据通信服务（GET/SET/ACTION Read/Write)调用在数据链路层采用I帧传送，另一方面，无确认的数据通信服务调用采用UI帧传送。因此，无确认服务的编码形式应放入一个HDLC帧中。A.2.1.3.3 EventNotificat

11、ion服务的特别特征 在数据链路层EventNotification APDU 采用HDLC UI 帧传送，因此，与数据通信服务类似，本服务的编码形式也应放入一个HDLC帧中。传送EventNotification APDU的HDLC UI帧的源和目的地址总是相同的。源地址是管理逻辑设备（必选的）的HDLC地址（保留的HDLC地址为0x01），目的地址总是客户机管理应用进程的HDLC地址（保留的HDLC地址为0x01）。 非平衡的HDLC模型不允许采用实时的、非请求的方式发送一个协议数据单元，因此，在本模型中，通过调用客户机应用层的Trigger_EventNotification_sendi

12、ng服务原语来明确请求发送一个EventNotification帧（参见6.5.4.2）。一旦调用该服务，客户机将发送一个空的UI帧，并使P/F位设为TRUE，允许服务器数据链路层发送事件通告帧，服务器数据链路层发送未觉的Event-Notification-Request APDU作为UI帧，并利用EventNotification.indication向客户机应用进行指示，至此，事件通告过程完成。(规范性附录)xDLMS应用服务组件B.1 引言 COSEM方法的主要目的在于向商业领域为计量设备和系统提供面向COSEM接口对象的模型，同时保持对现有的DLMS标准向后的兼容性。为达到这些目的，

13、COSEM对DLMS进行了发展，在保持完全遵循DLMS标准的同时，COSEM可通过COSEM接口对象提供更多计量方面特定的意图。 COSEM应用层的xDLMS服务组件基于IEC 61334-4-41制定的DLMS规范。B.2 DLMS一致性 COSEM 数据交换会话总是从建立应用连接开始，建立应用连接总是由客户机启动。在建立连接期间，借助xDLMS-Initiate服务，用于访问COSEM接口对象的属性和方法的DLMS服务在客户机和服务器之间进行协商。如果响应是确认的，则应用连接建立在给定的COSEM应用语境和xDLMS语境中。 另外，COSEM制定了一个新的一致性块规范以扩展有效的DLMS服

14、务数量，见8.5。B.3 COSEM扩展的DLMS 为了制定COSEM规范，对DLMS标准进行一些扩展是必要的。扩展部分定义了增加的功能，而不是对现有功能的修改。扩展部分与现有的DLMS标准不存在冲突。B.3.1 增加的服务 为了能够使用逻辑名对COSEM接口对象的属性和方法进行引用，定义了下列新的服务：· GET用于读取COSEM接口对象属性的值· SET用于设置COSEM接口对象属性的值· ACTION用于调用COSEM接口对象的方法· EventNotification用于从服务器到客户发送一个非请求消息 这些服务已分别在6.5.3和6.6.3.2

15、中定义，相应的APDU在8.6.1中定义。B.3.2 附加的数据类型 增加的数据类型在 8.3中定义。B.3.3 一致性块 为了能够优化COSEM服务器的实现，增加了一个具有扩展功能的一致性块，参见8.5。COSEM一致性块可以通过其标记“Application 31”与DLMS标准的一致性块进行区分。 DLMS应用语境通过该一致性块和修改的xDLMS-Initiate/DLMS-Response服务进行协商。B.3.4 DLMS 版本号 DLMS版本号与xDLMS协议的第一版的版本号一致，都为6。 B.3.5 其它必要的修改 为了阐明客户机和服务器可使用的最大PDU大小的含义，下列修改是必要

16、的。IEC 61334-4-41第61页，表3：DLMS标准COSEM修改请求的最大PDU大小客户机最大可接收的PDU大小DLMS标准COSEM修改协商的最大PDU大小服务器最大可接收的PDU大小IEC 61334-4-41第63页，第5段：DLMS标准COSEM修改建议最大的PDU长度参数，其数据类型为Unsigned16，用于为信息交换的DLMS PDU申请最大的长度（用字节数表示）。在启动请求中申请最大的长度必需足够大，以确保初始错误PDU的传送。客户机最大可接收的PDU长度参数，其数据类型为Unsigned16，包含服务器可以发送的DLMS PDU的最大长度（用字节数表示），客户机应丢

17、弃接收到的超过该最大长度的PDU。该值必需足够大，以确保启动出错PDU的传送。小于10的值被保留，该值为0表示对PDU的大小没有限制。IEC 61334-4-41第63页，最后一段：DLMS标准COSEM修改协商的最大PDU长度参数，其数据类型为Unsigned16，包含信息交换的DLMS PDU的最大长度（用字节数表示），超过该最大长度的PDU应被丢弃。该最大值取请求的最大PDU大小和VDE处理器所支持的最大PDU大小中较小的一个。服务器最大可接收的PDU长度参数，其数据类型为Unsigned16，包含客户机可以发送的DLMS PDU的最大长度（用字节数表示），服务器应丢弃接收到的超过该最大

18、长度的PDU。小于10的值被保留，该值为0表示对PDU的大小没有限制。(资料性附录)AARQ和AARE 编码的示例本附录包含一些AARQ和AARE APDU的示例，这些示例包括各种不同等级的身份验证情况，以及成功和失败的情况。在COSEM中，AARQ和AARE APDU（见8.2）以BER（ISO/IEC 8825）编码。在user-information方面，它们分别包含采用A-XDR编码成为OCTETSTRING的xDLMS Initiate.Request/.Response或DLMS ConfirmedServiceError PDU。C.1 xDLMS-Initiate.reques

19、t PDU编码的示例 首先，是xDLMS-Initiate.request PDU编码的示例，其定义如下：xDLMS-Initiate.request : = SEQUENCEdedicated-key OCTET STRING OPTIONAL,response-allowed BOOLEAN DEFAULT TRUE,proposed-quality-of-service 0 IMPLICIT Integer8 OPTIONAL,proposed-dlms-version-number Unsigned8,proposed-conformance Conformance,client-ma

20、x-receive-pdu-size Unsigned16其中proposed-conformance参数包含客户机请求的COSEM一致性块，见8.5。 假定客户机希望构建下列xDLMS语境的应用连接：· 不加密（可选的dedicated-key不出现）；· response-allowed = TRUE (取缺省值);· 无proposed-quality-of-service（可选的proposed-quality-of-service参数不出现）；· proposed-dlms-version-number为6（xDLMS）；· prop

21、osed-conformance（为LN和SN引用请求所有可能的服务和特别特征）如下：Bit_00Bit_01Bit_02Bit_03Bit_04Bit_05Bit_06Bit_07Bit_08Bit_09Bit_10Bit_11Bit_12Bit_13Bit_14Bit_15Bit_16Bit_17Bit_18Bit_19Bit_20Bit_21Bit_22Bit_23位串值LN00000000011111100001111100 7E 1FSN0001110000000011001000001C 03 20本一致性块中LN的引用的含义为：· 不支持SET的Attibute_0引用

22、 (Bit_08)· 支持优先级管理 (Bit_09)· 支持GET的Attibute_0引用 (Bit_10)· 支持GET服务的块传输 (Bit_11)· 支持SET服务的块传输 (Bit_12)· 支持ACTION服务的块传输 (Bit_13)· 支持多重引用 (Bit_14)· 支持所有的LN服务 (GET, SET, ACTION,EVENT NOTIFICATION) (Bit_19, 20, 22, 23)· 支持选择性访问特征 (Bit_21)本一致性块中SN引用的含义：· 支持所有的SN

23、 服务 (READ, WRITE,· UNCONFIRMED WRITE(信息报告) (Bit_03, 04, 05, 15)· 支持多重引用 (Bit_14)· 支持参数化访。问 (Bit_18)· client-max-receive-pdu-size为1200D = 0x4B0。 对上述参数的xDLMS-Initiate.request PDU一起采用A-XDR规则进行编码：- 对xDLMS-Initiate.request PDU采用A-XDR规则进行编码01 / DLMS PDU中InitiateRequest的编码标记(显式标记)- dedi

24、cated-key组件的编码(OPTIONAL, 不出现)00 / dedicated-key组件的使用标志(FALSE, 不出现)- response-allowed组件的编码(TRUE, 缺省值)00 / response-allowed组件的使用标志(FALSE, default value conveyed)- proposed-quality-of-service组件的编码(OPTIONAL,不出现)00 / proposed-quality-of-service组件的使用标志(FALSE,不出现)- proposed-dlms-version-number组件的编码(Unsigne

25、d8, value=6)06 /Unsigned8类型的数据的A-XDR编码就是它的值- 对Conformance block APPLICATION 31 IMPLICIT BITSTRING (SIZE(24)进行编码5F 1F / APPLICATION 31标记(ASN.1显式标记)的编码04 / 'contents' 字段的长度（八位字节数）的编码（长度=4）00 / 对BITSTRING的最后字节中不使用的比特数进行编码重要说明 为了与现有的实现一致，在采用面向连接的基于HDLC的三层模型时，对Application 31标记的编码采用一个字节(5F)代替两个字节(

26、5F 1F)是可以接受的。LN引用SN引用00 7E 1F /对固定长度的位串值的编码1C 03 20 /对固定长度的位串值的编码- 对client-max-receive-pdu-size组件的编码(Unsigned16, value=0x4B0)04 B0 / Unsigned16的数据的A-XDR编码就是它的值 因此，对上述给定参数的xDLMS-Initiate.request PDU采用A-XDR规则进行编码，产生的八位字节序列为：LN引用SN引用01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 B001 00 00 00 06 5F 1F 04 00 1C

27、 03 20 04 B0该八位字节序列应作为一个OCTET STRING插入到AARQ APDU的user-information字段。C.2 AARQ不使用ACSE安全机制时的编码示例对ACSE的使用，假定客户机期望按下列应用语境建立应用连接：· protocol-version为缺省的ACSE版本；· application-context-name：LN引用SN引用joint-iso-ccitt(2) country(16) country-name(756)identified-organization(5) DLMS-UA(8)applicationcontext

28、(1) context_id(1)joint-iso-ccitt(2) country(16) country-name(756)identified-organization(5) DLMS-UA(8) applicationcontext(1) context_id(2)· 不使用身份验证：mechanism-name和calling-authenticationvalue都不出现；· 不包含implementation-information。 AARQ APDU采用BER编码，对应参数如下：- 对AARQ APDU进行BER编码60 / AARQ APDU (APP

29、LICATION 0, Application)的编码标记1D / AARQ content字段长度的编码(29个八位字节)- 对协议版本没有进行编码，因此认为协议版本为缺省值- application-context-name组件的编码(tagged component 1)A1 / application-context-name组件(1, Context-specific )标记的编码09 / 标记的组件值的长度编码- application-context-name组件(OBJECT IDENTIFIER)的编码06 / 对application-context-name (OBJEC

30、T IDENTIFIER, Universal)选择的编码07 / Object Identifier的值字段的长度的编码(7个八位字节)/ Object Identifier 八位字节标识码的BER编码是一个表示弧形标签的数字包序列，每个数字（最开始的两个除外，这两个数字要合成为一个数字）代表一串八位字节，除最后的八位字节之外，在每个八位字节中使用七位，最高有效位置1，所使用的八位字节数必需是最少的。本示例对象标识码（2,16,756,5,8,1,1）编码的第一个八位字节是最开始的两个数字组合而成的一个数字，遵循的规则为40*First+Second -> 40*2 + 16 = 96

31、 = 0x60。对象标识码的第三个数字(756)需要两个字节：其十六进制的值为0x2F4，二进制表示为00000010 11110100，按照上述规则，第二个八位字节的MSB应置为0，将其MSB移位到第一个八位字节，并把第一个八位字节的MSB置为1，得到的二进制数为10000101 01110100，其十六进制为0x8574。对象标识码的其余每个数字要求编码为一个八位字节，上述标识码的编码结果为60 85 74 05 08 01 01。）值的编码LN引用SN引用60 85 74 05 08 01 0160 85 74 05 08 01 02- user-information字段组件 (tag

32、ged component, 30)的编码BE / user-information字段component (30, Context-specific )的标记的编码10 / 标记的组件值字段的长度的编码- the application-context-name组件 (OCTET STRING)的编码04 / 对user-information (OCTET STRING, Universal)选择的编码0E / OCTET STRING值字段长度的编码(14个八位字节)/ 下面是xDLMS-Initiate.request PDU的八位字节序列LN引用SN引用01 00 00 00 06

33、5F 1F 04 00 00 7E 1F 04 B001 00 00 00 06 5F 1F 04 00 1C 03 20 04 B0 因此，一个具有上述给定参数的AARQ APDU完整编码如下（所有数据都用十六进制表示）：LN引用SN引用AARQ-pdu = 60 1D A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 B0 AARQ-pdu = 60 1D A1 09 06 07 60 85 74 05 08 01 02 BE 10 04 0E 01 00 00 00 06

34、 5F 1F 04 00 1C 03 20 04 B0 C.3 AARQ使用低级身份验证时编码的示例 本编码的示例与C.2示例类似，只有必需进行编码的三个附加字段与上面示例不同，这些字段是：· sender-acse-requirements：指示选用的ACSE功能单元；· mechanism-name：default-COSEM-low-level-security-mechanism-namejoint-iso-ccitt (2) country (16) country-name (756) identified-organization (5) DLMSUA (8)

35、 authentication_mechanism_name (2) mechanism_id (1);· calling-authentication-value：包含口令(假定为“12345678”)的GraphicString。注：这三个字段在user-information-field之前立即编码。- sender-acse-requirements字段组件(tagged component, 10 )的编码8A / acse-requirements 字段component (10, IMPLICIT,Context-specific)标记的编码02 /标记的组件值字段的长

36、度的编码- sender-acse-requirements组件(ACSE-requirements := BIT STRING)的编码07 / BIT STRING最后字节中没有使用的比特数的编码80 /身份验证功能单元(0)的编码注： 比特数的在不同的客户机之间可以不同，但是在COSEM环境中，只有BIT 0置为1时（指示身份验证功能单元是否需要）值得注意。- mechanism-name组件(tagged component 11)的编码8B / mechanism-name组件(component 11, IMPLICIT,Context-specific)的标记的编码07 /标记的组

37、件值字段的长度的编码- 对象标识码值的编码60 85 74 05 08 02 01- calling-authentication-value组件(tagged component 12)的编码AC / mechanism-name组件(component 12, Context-specific)标记的编码0A / 标记的组件值字段的长度的编码- calling-authentication-value组件 (Authentication-information := CHOICE)的编码80 / 对Authentication-information (charstring 0 IMPLI

38、CIT GraphicString)的编码选择08 / Authentication-information值字段长度的编码(8个八位字节)-口令值 (GraphicString “12345678”)的编码31 32 33 34 35 36 37 38因此，一个具有上述给定参数的AARQ APDU的完整的编码如下（所有数据都用十六进制表示）：LN引用SN引用AARQ-pdu = 60 36 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 31 32 33 34 35 36

39、37 38 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 B0 AARQ-pdu = 60 36 A1 09 06 07 60 85 74 05 08 01 02 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 31 32 33 34 35 36 37 38 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 03 20 04 B0 C.4 使用高级身份验证时AARQ编码的示例本编码的示例与C.3的示例类似，只有两个字段的内容不同：· mech

40、anism-name：default-COSEM-high-level-security-mechanism-name；· calling-authentication-value：假定不需要客户机到服务器的呼叫信息。- mechanism-name组件 (tagged component 11)的编码8B / mechanism-name组件(component 11, IMPLICIT, Context-specific)标记的编码07 / 标记的组件值字段的长度的编码- Object Identifier (default-COSEM-high-level-security-m

41、echanism-name)的编码60 85 74 05 08 02 02- calling-authentication-value组件(tagged component 12)的编码AC / mechanism-name组件(component 12, Context-specific)标记的编码02 / 标记的组件值字段的长度的编码- calling-authentication-value组件 (Authentication-information := CHOICE)的编码80 / 对Authentication-information (charstring 0 IMPLICIT

42、GraphicString)选择的编码00 / Authentication-information值字段的长度的编码(0个八位字节)-口令 (GraphicString)的编码/ 由于串是空的，不需要编码因此，一个具有上述给定参数的AARQ APDU的完整的编码如下（所有数据都用十六进制表示）：LN引用SN引用AARQ-pdu = 60 2E A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 02 80 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00

43、7E 1F 04 B0 AARQ-pdu = 60 2E A1 09 06 07 60 85 74 05 08 01 02 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 02 80 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 03 20 04 B0 C.5 AARE APDU编码示例，成功的情况 回忆AARE ADPU的ASN.1规范：AARE-apdu := APPLICATION 1 IMPLICIT SEQUENCEprotocol-version 0 IMPLICIT BIT STRING versio

44、n1 (0) DEFAULT version1,application-context-name 1 Application-context-name,result 2 Association-result,result-source-diagnostic 3 Associate-source-diagnostic,responding-AP-title 4 AP-title OPTIONAL,responding-AE-qualifier 5 AE-qualifier OPTIONAL,responding-AP-invocation-id 6 AP-invocation-identifie

45、r OPTIONAL,responding-AE-invocation-id 7 AE-invocation-identifier OPTIONAL,- 如果仅仅使用内核，下列字段不出现responder-acse-requirements 8 IMPLICIT ACSE-requirements OPTIONAL,- 只有在选用身份验证单元是，下列字段出现mechanism-name 9 IMPLICIT Mechanism-name OPTIONAL,- 只有在选用身份验证单元是，下列字段出现responding-authentication-value 10 EXPLICIT Authe

46、ntication-value OPTIONAL,implementation-information 29 IMPLICIT Implementation-data OPTIONAL,user-information 30 IMPLICIT Association-information OPTIONAL在COSEM中，该APDU采用BER进行编码，user-information包含一个xDLMS-Initiate.response PDU的A-XDR编码（OCTETSTRING）。C.6 xDLMS-Initiate.response PDU编码示例 xDLMS-Initiate.res

47、ponse的规范如下：xDLMS-Initiate.response : = SEQUENCEnegotiated-quality-of-service 0 IMPLICIT Integer8 OPTIONAL,negotiated-dlms-version-number Unsigned8,negotiated-conformance Conformance,server-max-receive-pdu-size Unsigned16,vaa-name ObjectName其中，ObjectName的数据类型为ObjectName := Unsigned16，协商的一致性参数包含服务器支持的

48、xDLMS服务和特征。 假定服务器接受请求的具有下列xDLMS语境的应用连接：· 没有negotiated-quality-of-service (可选的proposed-quality-of-service参数不出现)；· 协商的DLMS版本号为6 (xDLMS);· 接受的xDLMS一致性块（其指示接受的LN引用和SN引用的服务与特别特征）如下：Bit_00Bit_01Bit_02Bit_03Bit_04Bit_05Bit_06Bit_07Bit_08Bit_09Bit_10Bit_11Bit_12Bit_13Bit_14Bit_15Bit_16Bit_17B

49、it_18Bit_19Bit_20Bit_21Bit_22Bit_23位串值LN00000000010100000001111100 50 1FSN0001110000000011001000001C03 20本一致性块中LN引用的含义为：不支持SET的Attibute_0引用 (Bit_08)支持优先级管理 (Bit_09)不支持GET的Attibute_0引用 (Bit_10)支持GET服务的块传输 (Bit_11)不支持SET服务的块传输 (Bit_12)不支持ACTION服务的块传输 (Bit_13)不支持多重引用 (Bit_14)支持所有的LN服务 (GET, SET,ACTION,

50、EVENT NOTIFICATION) (Bit_19, 20, 22, 23)支持选择性访问特征 (Bit_21)本一致性块中SN引用的含义：支持所有的SN 服务 (READ, WRITE,UNCONFIRMED WRITE(信息报告) (Bit_03, 04, 05, 15)支持多重引用 (Bit_14)支持参数化访问 (Bit_18)· server-max-receive-pdu-size为500D = 0x1F4；· vaa-name.LN引用SN引用给该连接赋一个虚设的VAA名返回标准的连接SN的短名(0xFA00) 具有上述参数的xDLMS-Initiate.

51、response PDU的A-XDR编码如下：- xDLMS-Initiate.response PDU的A-XDR编码08 / DLMS PDU选项表中InitiateResponse的标记（显式标记）的编码- negotiated-quality-of-service组件(可选项, 不出现)00 / proposed-quality-of-service组件的使用标记(FALSE, 不出现)- negotiated-dlms-version-number组件的编码(Unsigned8, value=6)06 / 类型为Unsigned8的数据的A-XDR编码就是它的值- 一致性块APPLI

52、CATION 31 IMPLICIT BITSTRING (SIZE(24)的编码5F 1F / APPLICATION 31 标记 (ASN.1 显式标记)的编码04 / 'contents' 字段长度（用八位字节数表示）的编码（4个八位字节）00 / 位串的最后一个八位字节没有使用的比特数的编码/ 固定长度位串值的编码LN引用SN引用00 50 1F 1C 03 20 - server-max-receive-pdu-size组件的编码(Unsigned16, value=0x01F4)01 F4 / 类型为Unsigned16的数据的A-XDR编码就是它的值- VAA-N

53、ame组件的编码 (Unsigned16, 使用LN引用时值=0x0007，使用SN引用时值= FA 00)/ 类型为Unsigned16的数据的A-XDR编码就是它的值LN引用SN引用00 07FA 00 因此，对具有上述给定参数的xDLMS-Initiate.response PDU进行A-XDR编码应产生如下八位字节序列：LN引用SN引用08 00 06 5F 1F 04 00 00 50 1F 01 F4 00 0708 00 06 5F 1F 04 00 1C 03 20 01 F4 FA 00 这个八位字节序列应作为一个OCTET STRING 插入到AARE APDU的user-

54、information 字段。C.7 不使用安全措施或使用低级安全措施时AARE的编码 对ACSE的使用，假定服务器接受按下列应用语境建立应用连接：· protocol-version为缺省的ACSE版本· application-context-name:LN引用SN引用joint-iso-ccitt(2) country(16) country-name(756)identified-organization(5) DLMS-UA(8) applicationcontext(1) context_id(1)joint-iso-ccitt(2) country(16) country-name(756)identified-organization(5) DLMS-UA