用于IP网络的DLMS/COSEM传输层
用于在IP网络上使用的DLMS/COSEM通信配置文件：
基于无连接的UDP的传输层；面向连接的基于TCP的传输层；基于无连接层的传输层。
DLMS/COSEM TL由CoAP、UDP或TCP传输层和一个额外的子层组成，称为包装器。
此外，包装器子层还具有以下功能：
它在UDP/TCP端口上提供了一个额外的寻址能力（wPort）；它提供有关传输数据长度的信息。该功能帮助发送方发送和接收方识别一个完整的APDU的接收，该APDU可以在多个TCP数据包中发送和接收。
DLMS/COSEM AL只侦听一个UDP或TCP端口。另一方面，一个物理设备可以承载多个客户机或服务器AP。包装器子层提供的附加寻址功能允许寻址这些ap。
DLMS/COSEM无连接、基于UDP的传输层
UDP为应用程序提供了一个以最少的协议机制向其他程序发送消息的过程。一方面，该协议是面向事务的，并且不保证交付和重复保护。另一方面，UDP很简单，它增加了最小的开销，而且它非常高效且易于使用。一些著名的互联网应用程序，如SNMP，DHCP，TFTP等。利用这些性能优势，要么是因为某些数据报应用程序不需要可靠，要么是因为应用程序本身确保了所需的可靠性机制。请求/响应类型的应用程序，比如在基于DLMS/COSEM udp的TL上建立的已确认的COSEM应用程序关联，然后调用已确认的xDLMS数据传输服务是这第二类的一个很好的例子。UDP的另一个优点是没有连接，它很容易进行多播和广播。
UDP基本上为IP层提供了一个上层接口，并具有额外的识别能力，即UDP端口号。这允许区分托管在同一物理设备中并通过其IP地址标识的ap。
基于DLMS/COSEM udp的传输层的服务规范
基于DLMS/COSEM udp的TL只提供一个数据传输服务：无连接的udp数据服务。因此，该服务的服务规范对于客户端和服务器TLs都是相同的，如下图所示。
DLMS/COSEM无连接、基于udp的传输层的服务图： 请求和指示（ .request and .indication）服务原语是必需的。本地确认（ local .confirm）服务原语的实现是可选的。
带包装头的xDLMS APDU应适合单个UDP数据报。
UDP-DATA服务（UDP-DATA.request）
原语应提供以下参数：
UDP-DATA.request (
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
Local_wPort、Local_UDP_Port和Local_IP_Addases
表示请求发送数据的设备/ DLMS/COSEM AE的包装端口号、UDP端口号和IP地址参数。
Remote_wPort、Remote_UDP_Port和Remote_IP_Adress参数
表示要传输数据的设备/ DLMS/COSEM AE的包装端口号、UDP端口号和IP地址参数。
Data_Length表示以字节表示的数据参数的长度。
Data 表示数据包含要传输到对等AL的xDLMS APDU。
客户端或服务器DLMS/COSEM AL会调用UDP-DATA.request原语，以请求向单个对等AL发送APDU，或者在多播或广播的情况下，向多个对等AL发送APDU。
此服务原语的接收将使包装器子层将包装器头预固定到接收到的APDU上，然后使用正确形成的WPDU调用UDP子层的SEND（）函数，作为DATA。UDP子层将WPDU传输到对等包装器子层。
UDP-DATA服务（UDP-DATA.indication）
原语应提供以下参数：
UDP-DATA.indication (
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
Local_wPort、Local_UDP_Port和Local_IP_Addases
表示接收数据的设备/ DLMS/COSEM AE的包装端口号、UDP端口号和IP地址参数。
Remote_wPort、Remote_UDP_Port和Remote_IP_Adress参数
表示已发送数据的设备/ DLMS/COSEM AE的包装端口号、UDP端口号和IP地址参数。
Data_Length表示以字节表示的数据参数的长度。
Data 表示数据包含要传输到对等AL的xDLMS APDU。
UDP-DATA.indication原语由基于DLMS/COSEM UDP的TL生成，用于向服务用户DLMS/COSEM AL指示已接收到来自对等层实体的APDU。
如果接收到的消息的Local_UDP_Port和Local_wPort参数都包含有效的端口号，这意味着在接收设备中绑定到给定的端口号，则在UDP子层中有一个DLMS/COSEM AE。否则，所接收到的消息将会被简单地丢弃。
UDP-DATA服务（UDP-DATA.confirm）
原语应提供以下参数：
UDP-DATA.confirm (
Local_wPort,
Remote_wPort,
Local_UDP_Port,
Remote_UDP_Port,
Local_IP_Address,
Remote_IP_Address,
Result
)
Local_wPort、Remote_wPort、Local_UDP_Port、Remote_UDP_Port、Local_IP_Address
和Remote_IP_Address携带与正在确认的相应UDP-DATA.request服务相同的值。
Result 结果参数的值表示基于DLMS/COSEM UDP的TL是否能够发送所请求的UDP数据报（OK）/（NOK）。
UDP-DATA.confirm原语是可选的。如果实现，它将由DLMS/COSEM TL生成，以向服务用户DLMS/COSEM AL确认之前的UDP-DATA.request的结果。它是本地生成的，只指示是否可以发送.request原语中的数据。换句话说，具有Result == OK的UDP-DATA.confirm只表示数据已经发送，并不意味着数据已经（或将）成功发送到目标。
基于DLMS/COSEM UDP的传输层的协议规范
在这个通信配置文件中，包装器子层是一个无状态实体：它唯一的角色是确保使用wPort号码进行源和目标DLMS/COSEM AE识别，并提供osi格式的UDP-DATA.xxx服务调用和SEND（）和接收标准UDP提供的（）接口功能之间的转换。
尽管在基于udp的配置文件中没有必要，但为了在两个TLs中具有相同的包装器协议控制信息——换句话说是包装器头，包装器子层还应在包装器协议数据单元中包含数据长度信息。
包装器协议数据单元（WPDU）
WPDU由两部分组成：
所述包装器标头部分，其中包含所述包装器控制信息；数据部分，包含相应的UDP-DATA.xxx服务调用的DATA参数——一个xDLMS APDU。
注意：APDU的最大长度应该比UDP数据报的最大长度少8个字节。
包装器标头包括四个字段，见上图。每个字段都是一个16位长的无符号整数值（16 bit long unsigned integer）。
Version 版本：携带包装器的版本。其值由DLMS UA控制。当前值为0x0001。 注意，在以后的版本中，包装器头可能有一个不同的结构； Source wPort 源wPort：携带标识已发送的DLMS/COSEM AE的wPort编号； Destination wPort 目的wPort：携带识别接收方DLMS/COSEM AE的wPort编号； Length 数据长度：表示WPDU（xDLMS APDU传输）的Data字段的长度。
基于DLMS/COSEM UDP的传输层协议数据单元
在此配置文件中，WPDU应通过互联网标准STD0006中规定的UDP数据报进行传输。它们应封装WPDU，如下图所示。 从外部的角度来看，DLMS/COSEM无连接的TL PDU是一个普通的UDP数据报：任何DLMS/COSEM特定的元素，包括包装器特定的头，都在UDP数据字段内。因此，可以（重新）使用标准的UDP实现来轻松地实现这个TL。
源和目标UDP端口可以参考本地或远程UDP端口，这取决于数据传输的方向：从发送设备的角度来看，数据报中的源UDP端口对应于Local_UDP_port，但从接收设备的角度来看，数据报中的源UDP端口对应于Remote_UDP_Port服务参数。
面向DLMS/COSEM连接的、基于TCP的传输层
TCP作为一种面向连接的传输协议，包括三个阶段：连接建立、数据交换和连接释放。因此，基于DLMS/COSEM tcp的TL为所有三个阶段的服务用户提供OSIstyle服务：
对于连接建立阶段，TCP连接服务被提供给服务用户TCP连接管理器进程；在数据传输阶段，TCP-DATA服务被提供给服务用户DLMS/COSEM AL；对于连接关闭阶段，TCP断开服务提供给服务用户TCP连接管理器进程；此外，还向服务用户DLMS/COSEM AL提供了TCP中止服务。
面向DLMS/COSEM连接的、基于TCP的TL包含与基于DLMS/COSEM UDP的TL相同的包装器子层。除了将OSI格式的服务转换为TCP函数调用之外，这个包装器还提供了额外的寻址和长度信息。
基于DLMS/COSEM TCP的传输层的服务规范
面向DLMS/COSEM连接、基于tcp的TL在客户端和服务器端提供相同的一组服务，如下图所示。
在此通信配置文件中，在客户端和服务器端提供全套TCP连接管理服务（TCP连接和TCP断开连接）。这也是为了允许服务器启动和释放一个TCP连接。
TCP连接管理服务的服务用户不是DLMS/COSEM AL，而是TCP连接管理器进程。 另外提供一个COSEM-abobrt服务，向DLMS/COSEM AL指示支持的TCP连接中断或断开。 与在基于DLMS/COSEM UDP的TL中一样，TCP-DATA.confirm服务原语也是可选的。但是，TCP-DATA.request服务可以在本地或远程进行确认。
TCP连接服务（TCP-CONNECT.request）
原语应提供如下参数：
TCP-CONNECT.request (
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address
)
Local_TCP_Port和Remote_TCP_Port 分别识别本地和远程TCP端口。
Local_IP_Address和Remote_IP_Address参数
表示请求TCP连接的物理设备和需要建立TCP连接的目标物理设备的IP地址。
服务用户TCP连接管理器进程调用TCP-CONNECT.request原语，以与对等DLMS/COSEM基于TCP的TL建立连接。
TCP连接服务（TCP-CONNECT.indication）
原语应提供以下参数：
TCP-CONNECT.indication (
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address
)
Local_TCP_Port和Remote_TCP_Port 表示要在两者之间建立所请求的TCP连接的两个TCP端口。
Local_IP_Address和Remote_IP_Address 表示参与TCP连接的两个设备的IP地址。
TCP-CONNECT.indication原语是由基于DLMS/COSEM P-TCP的TL在接收TCP包后生成的，向TCP连接管理器进程指示远程设备正在请求新的TCP连接。
TCP连接服务（TCP-CONNECT.response）
原语应提供以下参数：
TCP-CONNECT.response (
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Result
)
Local_TCP_Port和Remote_TCP_Port 表示正在之间建立连接的两个TCP端口。
Local_IP_Addess和Remote_IP_Address 表示参与TCP连接的两个物理设备的IP地址。
Result 表明服务用户TCP连接管理器已接受了所请求的TCP连接。它的值总是成功的。
TCP连接管理器进程会调用TCP-CONNECT.response原语，以向基于DLMS/COSEM的TCP的TL指示先前请求的TCP连接是否已被接受。TCP连接管理器无法拒绝所请求的连接。
TCP连接服务（TCP-CONNECT.confirm）
原语应提供以下参数：
TCP-CONNECT.confirm (
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Result,
Reason_of_Failure
)
Local_TCP_Port和Remote_TCP_Port 表示正在之间建立连接的两个TCP端口。
Local_IP_Address和Remote_IP_Address 表示参与此TCP连接的两个物理设备的IP地址。
Result 表明所请求的TCP连接是否已建立。
请注意，此服务原语通常是远程确认的结果，并且由于TCP连接请求不能被拒绝，因此结果参数应始终表示成功。
但是，当它被局部确认时，结果参数也可能指示失败。
Reason_of_Failure 在上述情况下，故障的原因参数表示故障的原因。
TCP-CONNECT.confirm原语由基于DLMS/COSEM TCP的TL生成，用于向服务用户TCP连接管理器指示处理之前接收到的TCP-CONNECT.request服务调用的结果。
同理 TCP断开服务（request、indication、response、confirm）
同理 TCP中止服务（indication）
TCP-DATA（数据） 服务（TCP-DATA.request）
原语应提供以下参数：
TCP-DATA.request (
Local_wPort,
Remote_wPort,
Local_TCP_Port,
Remote_TCP_Port,
Local_IP_Address,
Remote_IP_Address,
Data_Length,
Data
)
Local_wPort、Local_TCP_Port和Local_IP_Adress参数
表示请求发送数据的设备/ DLMS/COSEM AE的包装端口号、TCP端口号和IP地址参数。
Remote_wPort、Remote_TCP_Port和Remote_IP_Adress参数
表示要传输数据的设备/ DLMS/COSEM AE的包装端口号、TCP端口号和IP地址参数。
Data_Length 表示数据参数的长度，单位为字节。
Data 数据包含要传输到对等AL的xDLMS APDU。
TCP-DATA.request原语由客户端或服务器DLMS/COSEM AL调用，以请求向单个对等应用程序发送APDU。
接收此原语将使包装器子层将包装器特定的字段（Local_wPort、Remote_wPort和Data_Length）预固定到接收到的xDLMS APDU上，然后用正确形成的WPDU调用TCP子层的SEND（）函数，作为DATA。TCP子层应按照STD0007中所述，将WPDU传输到对等TCP子层。
TCP-DATA.indication和confirm 同理UDP-DATA服务
基于DLMS/COSEM TCP的传输层的协议规范
在基于TCP的TL中，包装器子层比在基于UDP的TL中更为复杂。一方面，类似于基于UDP的TL的主要作用也是确保源和目的地DLMS/COSEM AE识别使用wPort编号，并转换OSI-style的TCP-DATA服务原语和从SEND（）和接收标准TCP提供的（）接口功能。另一方面，基于TCP的TL中的包装器子层也有一个任务来帮助服务用户DLMS/COSEM ALs交换完整的APDU。
TCP是一种“流式”协议，这意味着它不保留数据边界。这意味着即使发送/接收的字节数实际小于请求发送/接收的字节数，TCP子层的SEND（）和RECEIVE（）函数调用也会成功返回。包装器子层的责任是知道必须发送/接收多少数据，跟踪实际发送/接收了多少数据，并重复该操作，直到传输完整的APDU。
因此，基于TCP的DLMS/COSEM TL中的包装器子层并不是一个无状态的实体：它正在执行上面描述的跟踪-重新尝试过程，以使TCP的“流”性质对服务用户DLMS/COSEM AL透明。
包装器协议数据单元（WPDU） 与UPD同理
基于DLMS/COSEM TCP的传输层协议数据单元
wpdu以一个或多个TCP数据包进行传输。TCP数据包在STD0007中指定，并将WPDU的一部分封装在其数据字段中，如下图所示。在TCP数据包中只有WPDU的一部分的原因是已经提到的TCP的“流”性质。
TCP数据包格式图： 从外部的角度来看，基于DLMS/COSEM TCP的TL PDU是一个普通的TCP包：任何COSEM特定的元素，包括第一个TCP包中的特定于包装器的头，都在包的数据字段内。
源和目标TCP端口可以参考本地或远程TCP端口，这取决于数据传输的方向（即，从发送方设备的角度来看，TCP包中的源TCP端口对应于Local_TCP_Port，但从接收方设备的角度来看，数据报的源TCP端口对应于Remote_TCP_Port服务参数）。
TCP connection
TCP连接的建立是通过使用所谓的“三方握手”过程来执行的。这是由一个TCP调用主动打开而启动的，并由另一个TCP响应，该TCP已经被称为被动打开，因此处于侦听状态。
TCP连接的建立将由TCP-CONNECT.request服务调用来启动。尽管此服务——作为所有的DLMS/COSEM TL服务——是由包装器子层提供给服务用户实体的，但TCP连接是在两个（本地和远程）TCP子层之间建立的。包装器在此过程中的作用只是将TCP连接服务原语（请求、指示、响应和确认）——(.request, .indication, .response and .confirm)转换为TCP函数调用。
从服务用户的角度来看，只有TCP连接服务基元是可见的：根据此，TCP连接建立如下图所示。 如STD0007中所述，TCP连接是使用三方握手机制建立起来的。这需要如上所示的三次消息交换，并保证双方都知道对方已经准备好传输，而且双方都是同步的：初始序列号达成一致。
允许客户端和服务器端TCP连接管理器进程来启动TCP连接。为了建立联系，其中一个扮演发起者的角色，另一个扮演应答者的角色。
为了能够响应，响应者必须在接收到第一个SYN数据包之前执行一个“被动”打开。为此，它必须联系本地操作系统（OS），以表明它已经准备好接受传入的连接请求。作为此联系的结果，操作系统为该连接的端点分配了一个TCP端口号，并保留了未来连接所需的资源——但没有发送任何消息。
注意：在DLMS/COSEM传输层中，实现会强制操作系统将请求的TCP / UDP端口号分配给连接的本地端点。
在基于DLMS/COSEM TCP的TL的情况下，包装器子层在系统初始化过程中自动启动这个被动打开。换句话说，由于这个被动打开是包装器子层的责任，因此不向外部实体提供任何服务来启动被动打开。
由于客户端和服务器端TCP连接管理器进程都被允许扮演“响应器”应用程序的角色，因此双方的TL应在系统初始化过程中执行被动打开。
TCP disconnection
通过调用TCP-DISCONNECT.request原语，客户端或服务器端管理TCP连接管理器进程启动。这个请求被“包装器”转换为对TCP接口的 CLOSE ()函数调用。
TCP发送一个fin段（fin segment），它由对等TCP确认。
同时，通过包装器，生成TCP-DISCONNECT.indication原语，并通知用户TCP连接管理器，该连接正在关闭。为了释放连接，连接管理器会使用TCP-DISCONNECT.response原语进行响应。TCP包装器调用CLOSE函数，TCP发送它的fin段（fin segment）。同时，TCP包装器表示使用TCP-ABORT.indication原语关闭到DLMS/COSEM AL的TCP连接。
在请求方，TCP发送一个确认，并在对等方接收到此确认后删除TCP连接。同时，包装器生成TCP-DISCONNECT.confirm原语，通知连接管理器进程已接受断开连接请求。类似于对等方，通过COSEM-ABORT.indication原语也将TCP断开连接通知给DLMS/COSEM AL。
TCP connection abort
基于DLMS/COSEM TCP的TL表示在TCP-ABORT.indication原语的帮助下，到DLMS/COSEM AL的支持TCP连接中断或断开。请注意，这是提供给DLMS/COSEM AL的唯一TCP连接管理服务。
当TCP连接管理器进程断开TCP连接时——正常断开的情况——或者当TCP断开以非请求的方式发生时，例如TCP子层检测到不可解决的错误或物理连接关闭时，将调用服务。
此服务的目的是通知DLMS/COSEM AL关于TCP连接被中断的情况，以便它可以释放所有现有的AAs。
基于DLMS/COSEM CoAP的传输层
此子条款指定了基于DLMS/COSEM CoAP的通信配置文件（DLMS/COSEM_on_CoAP）的无连接的DLMS/COSEM CoAP传输层（DLMS/COSEM CoAP TL），用于通过基于IP（或有能力的）网络交换DLMS/COSEM应用程序消息。
受约束的应用协议（CoAP）是由IETF核心工作组定义的一个专门的互联网应用协议。CoAP专门设计用于资源受限的设备，用于在非受限或受限的互联网通信网络（如低功耗、有损网络）上的通信。CoAP旨在提供高效的数据传输能力，同时也能满足专门的需求，如可靠性、多播支持、非常低的开销、效率和简单性。
基于CoAP的DLMS/COSEM CoAP TL提供了不可靠和可靠的运输服务。不可靠的交换服务支持多播和广播。DLMS/COSEM CoAP TL为服务用户DLMS/COSEM AL提供 OSI-style 的服务。
DLMS/COSEM CoAP TL由CoAP请求/响应层及其在RFC 7252中指定的底层CoAP消息传递层组成。DLMS/COSEM CoAP TL嵌入了RFC 7959指定的CoAP块传输机制。此外，它还包括一个DLMS/COSEM CoAP包装器层，该层为DLMS/COSEM AL提供了OSI-style的DLMS/COSEM CoAP-DATA服务原语。DLMS/COSEM CoAP TL嵌入了一个运行在IPv4或IPv6网络层之上的标准UDP传输层。
当DLMS/COSEM AL使用DLMS/COSEM CoAP TL进行通信时，DLMS/COSEM AL将作为互联网标准序列化和安全标准运行。见下图。
DLMS/COSEM CoAP传输协议层图示：
DLMS/COSEM CoAP传输层的结构
DLMS/COSEM AL通过CoAP包装器及其使用CoAP POST方法绑定到CoAP请求/响应层。
DLMS/COSEM CoAP TL提供不可靠的运输服务。不可靠的DLMS/COSEM CoAP传输服务利用不可确认（NON）CoAP消息，而可靠的DLMS/COSEM CoAP TL服务利用可确认（CON）CoAP消息和CoAP消息传递层提供的重试机制。
CoAP包装器层提供了以下功能：
OSI-style 的数据服务原语通过与CoAP请求/响应层操作的交互作用到DLMS/COSEM AL，以使用CoAP POST方法；DLMS/COSEM服务接入点寻址能力，从而允许多个DLMS/COSEM AEs驻留在一个物理设备的同一CoAP客户端和服务器端点上； 注意：出于效率的原因，以及寻址的简单性，我们希望允许为驻留在同一物理设备上的多个DLMS/COSEM AEs共享相同的UDP套接字和相同的CoAP客户端和服务器端点。
CoAP包装层实现了在有状态CoAP消息传递和CoAP协议层之上提供 OSI-Style 数据服务所需的有状态操作。 CoAP包装器层的数据服务原语的数据字段携带一个APDU。
CoAP-DATA服务（ CoAP-DATA.request ）
原语应提供以下参数：
CoAP-DATA.request (
Transport_Mode,
Local_SAP,
Remote_SAP,
Local_IP_address [Optional Use],
Local_Port [Optional Use],
Remote_IP_address,
Remote_Port,
Remote_Path [Optional Use],
Response_Mode,
Request_ID [Optional Use],
Data_Length,
Data
)
Transport_Mode参数
传输模式表示APDU是作为可靠的CoAP传输操作的可CoAP确认消息（传输模式设置为“可靠”），
还是作为不可靠的CoAP传输操作的不确认消息（传输模式设置为“不可靠”）；
Local_SAP参数
表示本地DLMS/COSEM AE的SAP；
Remote_SAP参数
表示远程DLMS/COSEM AE的SAP；
Local_IP_address和Local_Port参数
本地地址和本地端口表示发送的DLMS/COSEM CoAP TL的CoAP端点；
Remote_IP_address和Remote_Port参数
表示接收DLMS/COSEM CoAP TL的CoAP端点；
Remote_Path参数
表示接收的DLMS/COSEM CoAP TL对等点的Uri路径。如果将响应模式设置为“响应”，则不应忽略远程路径；
Response_Mode参数
响应_模式指示是否期望返回一个DLMS/COSEM响应APDU。它取值：“确认”、“未确认”、“回应”。
Rebest_ID参数
标识特定的数据请求操作。
Request_ID将以潜在的CoAP-DATA.confirm原语返回，
指示DLMS/COSEM CoAP TL成功或未能传输Data参数中给出的APDU。
请求ID是在已发送多个携带请求的APDU和DLMS/COSEM CoAP TL确认的情况下，
支持按APDU返回DLMS/COSEM CoAP TL确认。
以下内容适用：
- 如果Resed_ID未指定，则Resed_ID在由DLMS/COSEM CoAP TL实现生成的潜在CoAP-DATA.confirm原语中未指定；
- 如果传输模式设置为不可靠，并且DLMS/COSEM CoAP TL实现不支持此操作模式的CoAP-DATA.confirm原语，则Resuest_ID可能未指定；
- 如果DLMS/COSEM CoAP TL服务不支持CoAP-DATA.confirm原语，则CoAP包装器将忽略指定的Resqest_ID标识符。
Data_Length参数
表示数据参数的长度，单位为字节；
Data参数
数据包含要传输到接收端DLMS/COSEM AL的APDU。
CoAP-DATA服务 （CoAP-DATA.indication） 同理
CoAP-DATA服务 （CoAP-DATA.confirm） 同理
DLMS/COSEM CoAP传输层的协议规范
DLMS/COSEM CoAP TL为服务用户DLMS/COSEM AL提供OSI类型的服务。它包括以下内容：
可将 OSI-style 的CoAP-DATA服务转换为CoAP请求/响应函数调用的DLMS/COSEM CoAP包装器层。它是一个有状态的实体，它在有状态的CoAP请求/响应层和OSI服务层之间进行中介。CoAP包装器实现了DLMS/COSEM CoAP TL确认的可靠的DLMS/COSEM CoAP TL；使用RFC 7252中指定的特性的选定子集的CoAP协议层。对于块级传输，它使用RFC 7959中指定的特性的一个子集；在RFC 768中指定的UDP图层。
只有DLMS/COSEM COAP包装器层是DLMS/COSEM特定的。因此，为了在DLMS/COSEM CoAP TL协议栈中实现CoAP层和UDP层，可以使用标准的CoAP和UDP协议层实现。
DLMS/COSEM CoAP TL协议数据单元（CoAP-PDU）
描述DLMS/COSEM CoAP TL协议数据单元（CoAP-PDU）以及DLMS CoAP包装层与CoAP请求/响应层的耦合。
DLMS/COSEM CoAP TL PDU是一个UDP数据报，它携带一个CoAP消息作为其有效负载。CoAP消息携带CoAP报头和DLMS/COSEM CoAP包装器PDU（CWPDU）。CWPDU携带DLMS/COSEM APDU作为其有效载荷，以及DLMS/COSEM CoAP TL控制信息。
CWPDU作为CoAP请求（POST方法）或CoAP消息中的CoAP响应被携带。CWPDU可能是空的，在这种情况下，它作为空的响应负载携带在CoAP消息中。
除了携带DLMS、在DLMS/COSEM CoAP TL对等体之间交换的CoAP消息外，还有一些其他的CoAP消息：
携带CoAP错误响应的CoAP消息；CoAP确认消息（在传输服务运行可靠的情况下）；交换CoAP重置消息，以支持CoAP协议层操作。
为了高效和可靠的传输服务操作，如果可能，以CoPDU或CoAP错误响应的形式携带在CoAP确认消息中。CWPDU在CoAP请求/响应协议层的CoAP请求/响应上下文中的CoAP端点之间传输。CoAP令牌在CoAP协议级别上标识CoAP请求/响应上下文。
受约束的应用程序协议（CoAP）
CoAP包装器作为CoAP应用程序层实例运行。
本节描述并指定了与由CoAP包装器操作确定的DLMS/COSEM CoAP协议层操作相关的各个方面。
CoAP消息以简单的二进制格式进行编码。消息由一个固定大小的4字节头，一个0-8字节的可变长度标记值，0个或更多的TLV编码选项后面跟有效负载组成。 一个非空的CWPDU在CoAP消息中作为有效负载被携带。
CoAP消息头字段 固定大小的4字节CoAP消息报头的“类型”和“代码”字段一起表示CoAP消息类型。
CoAP标题类型字段 RFC 7252指定的CoAP报头类型字段（2位）值为：
Type = CON (0) 用于携带请求或响应的可确认消息；Type = NON (1) 对于包含请求或响应的不可确认消息；Type = ACK (2) 用于CoAP确认消息（可能嵌入附加响应）；Type = RST (3) 为CoAP重置消息。
覆盖头类型字段使用 CoAP包装器并不直接操作CoAP报头类型字段，它是由CoAP协议实现根据所发出的消息的类型来设置的。
对于要在新的原始CoAP请求/响应上下文中发送的任何给定的CWPDU或错误响应，CoAP包装层应指定CoAP请求/响应上下文是否应使用可靠或不可靠的CoAP消息传递层。
由可靠的DLMS/COSEM CoAP TL交换的CWPDU或错误响应应使用可靠的CoAP消息传递层。CWPDU或错误响应被携带在CON或ACK类型的CoAP消息中。是在类型CON还是ACK中携带，由CoAP消息传递层决定。
由不可靠的DLMS/COSEM CoAP TL交换的CWPDU应使用不可靠的CoAP消息层，并由CoAP消息层以NON类型的CoAP消息的形式携带。
CoAP头代码字段 CoAP头代码字段（8位）值分为以下几类：
Class（0）——携带请求方法代码；Class（2）——执行成功响应代码；Class（4）——携带CoAP客户端错误响应代码；Class（5）——携带复合服务器错误响应代码。
代码字段被格式化为3位类字段（c.），然后是5位代码详细信息字段（dd），以指定每个类中的子代码。
精彩链接
您阅读本篇文章共花了：
发表评论