DLMS/COSEM UDP-based Transport Layer DLMS/COSEM Application Layer a the UDP-based profile IP and lower layers DLMS/COSEM TCP-based Transport Layer COSEM Application Process DLMS/COSEM Ap
Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 60050-300,
IEC TR 62051 and IEC TR 62051-1 apply as well as the following:
3.1.1 application process an element within a real open system which performs the information processing for a particular application
Application entities refer to system-independent activities that are offered as application services to the application agent These services consist of a collection of application service elements that collectively manage all or part of the communication functions within an application process.
Abbreviations
APDU Application Layer Protocol Data Unit
COSEM COmpanion Specification for Energy Metering
DHCP Dynamic Host Configuration Protocol
DLMS Device Language Message Sepcification
COSEM_on_IP The TCP-UDP/IP based COSEM communication profile
IANA Internet Assigned Numbers Authority
PAR Positive Acknowledgement with Retransmission
SNMP Simple Network Management Protocol
TFTP Trivial File Transfer Protocol
WPDU Wrapper Protocol Data Unit
In the DLMS/COSEM_on_IP profiles, the DLMS/COSEM Application Layer utilizes the services of Transport Layers, which in turn rely on the Internet Protocol (IP) network layer to facilitate communication with other nodes within the abstract IP network.
The DLMS/COSEM Application Layer (AL) functions as an Internet standard application protocol, similar to widely recognized protocols such as HTTP, FTP, and SNMP It is designed to coexist with other Internet application protocols, as illustrated in Figure 1.
Figure 1 – DLMS/COSEM as a standard Internet application protocol
For DLMS/COSEM, the following port numbers have been registered by the IANA See http://www.iana.org/assignments/port-numbers
• dlms/cosem 4059/TCP DLMS/COSEM
• dlms/cosem 4059/UDP DLMS/COSEM
The DLMS/COSEM Application Layer (AL), as defined in IEC 62056-5-3, utilizes OSI-style services, necessitating the introduction of a wrapper between the UDP/TCP layers and the DLMS/COSEM AL Consequently, the DLMS/COSEM Transport Layers (TLs) are composed of a wrapper sublayer along with the UDP or TCP Transport Layer.
Files WEB pages COSEM interface model Application / Data models e.g FTP e.g HTTP DLMS/COSEM AL
Internet Transport Layer (UDP or TCP)
IEC 62056-9-7:2013, Electricity metering data exchange – the DLMS/COSEM suite –
Part 9-7: Communication profile for TCP-UDP/IP networks
STD 0006, User Datagram Protocol Edited by Jon Postel, August 1980 Available from: http://www.faqs.org/rfcs/std/std6.html
STD 0007, Transmission Control Protocol Edited by Jon Postel, September 1981 Available from: http://www.faqs.org/rfcs/std/std7.html
NOTE See also Bibliography for other related Internet RFCs
For the purposes of this document, the terms and definitions given in IEC 60050-300,
IEC TR 62051 and IEC TR 62051-1 apply as well as the following:
3.1.1 application process an element within a real open system which performs the information processing for a particular application
Application entities refer to system-independent activities that are offered as application services to the application agent These services consist of a collection of application service elements that collectively manage the communication aspects of an application process.
APDU Application Layer Protocol Data Unit
COSEM COmpanion Specification for Energy Metering
DHCP Dynamic Host Configuration Protocol
DLMS Device Language Message Sepcification
COSEM_on_IP The TCP-UDP/IP based COSEM communication profile
IANA Internet Assigned Numbers Authority
PAR Positive Acknowledgement with Retransmission
SNMP Simple Network Management Protocol
TFTP Trivial File Transfer Protocol
WPDU Wrapper Protocol Data Unit
In the DLMS/COSEM_on_IP profiles, the DLMS/COSEM Application Layer utilizes services from transport layers that, in turn, rely on the Internet Protocol (IP) network layer for communication with other nodes within the abstract IP network.
The DLMS/COSEM Application Layer functions as an Internet standard application protocol, similar to HTTP, FTP, or SNMP, and can coexist with other Internet application protocols, as illustrated in Figure 1.
Figure 1 – DLMS/COSEM as a standard Internet application protocol
For DLMS/COSEM, the following port numbers have been registered by the IANA See http://www.iana.org/assignments/port-numbers
• dlms/cosem 4059/TCP DLMS/COSEM
• dlms/cosem 4059/UDP DLMS/COSEM
The DLMS/COSEM Application Layer (AL), as defined in IEC 62056-5-3, utilizes OSI-style services, necessitating the introduction of a wrapper between the UDP/TCP layers and the DLMS/COSEM AL Consequently, the DLMS/COSEM Transport Layers (TLs) are composed of a wrapper sublayer along with the UDP or TCP Transport Layer.
Files WEB pages COSEM interface model Application / Data models e.g FTP e.g HTTP DLMS/COSEM AL
Internet Transport Layer (UDP or TCP)
Convergence / Adaptation Layer wrapper sublayer is a lightweight, nearly state-less entity: its main function is to adapt the
OSI-style service set, provided by the DLMS/COSEM TL, to UDP or TCP function calls and vice versa
In addition, the wrapper sublayer has the following functions:
• it provides an additional addressing capability (wPort) on top of the UDP/TCP port;
The article discusses the significance of data length in the transmission process, highlighting how this feature enables the sender to transmit and the receiver to identify the successful reception of a complete APDU, which can be divided across multiple TCP packets.
As specified in IEC 62056-9-7:2013, Clause 6, the DLMS/COSEM AL is listening only on one
In accordance with IEC 62056-6-2:2013, section 4.7, a DLMS/COSEM physical device can support multiple client application processes (APs) or server logical devices The wrapper sublayer enhances addressing capabilities, enabling the identification of these APs effectively.
The structure of the DLMS/COSEM TL and their place in COSEM_on_IP is shown in Figure 2
Figure 2 – Transport layers of the DLMS/COSEM_on_IP profile
The service user of both the UDP-DATA and the TCP-DATA services is the DLMS/COSEM
The TCP Connection Manager Process serves as the service user for the TCP-CONNECT and TCP-DISCONNECT services Additionally, the DLMS/COSEM TCP-based Transport Layer offers a TCP-ABORT service to the DLMS/COSEM Application Layer.
5 The DLMS/COSEM connection-less, UDP-based transport layer
General
The DLMS/COSEM connection-less TL is based on the User Datagram Protocol (UDP) as specified in STD 0006
DLMS/COSEM UDP-based Transport Layer
DLMS/COSEM connectionless transport services
UDP-DATA.req/.ind/(.cnf)
SEND, RECEIVE a) the UDP-based profile
DLMS/COSEM TCP-based Transport Layer
DLMS/COSEM connection-oriented transport services TCP-DATA.req/.ind/(.cnf)
TCP function calls active/passive OPEN, SEND, RECEIVE b) the TCP-based profile
T CP -C O N N E C T se rvi ce s T CP -DI S C O NNE C T s er vic es
UDP is a lightweight protocol that enables application programs to send messages with minimal overhead, making it efficient and easy to use While it is transaction-oriented and does not guarantee delivery or duplicate protection, its simplicity allows various Internet applications, such as SNMP, DHCP, and TFTP, to leverage its performance benefits Some applications do not require reliability, while others implement their own reliability mechanisms A notable example is the confirmed COSEM application association on the DLMS/COSEM UDP-based transport layer, which utilizes confirmed xDLMS data transfer services Additionally, UDP's connectionless nature facilitates easy multi- and broadcasting capabilities.
UDP serves as an upper interface to the IP layer, incorporating an identification feature through the UDP port number This capability enables the differentiation of applications hosted on the same physical device, which are identified by their IP addresses.
NOTE The addressing/identification scheme for the COSEM_on_IP profiles is defined in IEC 62056-9-7:2013, Clause 6.
Service specification for the DLMS/COSEM UDP-based transport layer
General
The DLMS/COSEM UDP-based Transport Layer (TL) offers a connection-less data transfer service known as the UDP-DATA service As a result, the service specifications for both the client and server Transport Layers are identical, as illustrated in Figure 3.
The request and indication service primitives are mandatory The implementation of the local confirm service primitive is optional
The xDLMS APDU, when prefixed with the wrapper header, must be contained within a single UDP datagram The wrapper sublayer operates as a lightweight and nearly stateless component, primarily designed to facilitate adaptation.
OSI-style service set, provided by the DLMS/COSEM TL, to UDP or TCP function calls and vice versa
In addition, the wrapper sublayer has the following functions:
• it provides an additional addressing capability (wPort) on top of the UDP/TCP port;
The article discusses the significance of data length in the transmission process, highlighting how it enables the sender to transmit and the receiver to identify the successful reception of a complete APDU, which can be divided across multiple TCP packets.
As specified in IEC 62056-9-7:2013, Clause 6, the DLMS/COSEM AL is listening only on one
In accordance with IEC 62056-6-2:2013, section 4.7, a DLMS/COSEM physical device can support multiple client application processes (APs) or server logical devices The wrapper sublayer enhances addressing capabilities, enabling the identification of these APs effectively.
The structure of the DLMS/COSEM TL and their place in COSEM_on_IP is shown in Figure 2
Figure 2 – Transport layers of the DLMS/COSEM_on_IP profile
The service user of both the UDP-DATA and the TCP-DATA services is the DLMS/COSEM
The TCP Connection Manager Process serves as the user for the TCP-CONNECT and TCP-DISCONNECT services Additionally, the DLMS/COSEM TCP-based Transport Layer offers a TCP-ABORT service to the DLMS/COSEM Application Layer.
5 The DLMS/COSEM connection-less, UDP-based transport layer
The DLMS/COSEM connection-less TL is based on the User Datagram Protocol (UDP) as specified in STD 0006
DLMS/COSEM UDP-based Transport Layer
DLMS/COSEM connectionless transport services
UDP-DATA.req/.ind/(.cnf)
SEND, RECEIVE a) the UDP-based profile
DLMS/COSEM TCP-based Transport Layer
DLMS/COSEM connection-oriented transport services TCP-DATA.req/.ind/(.cnf)
TCP function calls active/passive OPEN,
SEND, RECEIVE b) the TCP-based profile
T CP -C O N N E C T se rvi ce s T CP -DI S C O NNE C T s er vic es
UDP is a lightweight protocol that enables application programs to send messages with minimal overhead, making it efficient and easy to use While it is transaction-oriented and does not guarantee delivery or duplicate protection, its simplicity allows several Internet applications, such as SNMP, DHCP, and TFTP, to leverage its performance benefits Some applications do not require reliability, while others implement their own reliability mechanisms A notable example is the confirmed COSEM application association on the DLMS/COSEM UDP-based transport layer, which utilizes confirmed xDLMS data transfer services Additionally, UDP's connectionless nature facilitates easy multi- and broadcasting capabilities.
UDP serves as an upper interface to the IP layer, incorporating an identification feature through the UDP port number This capability enables the differentiation of access points (APs) that reside on the same physical device and are identified by their IP addresses.
NOTE The addressing/identification scheme for the COSEM_on_IP profiles is defined in IEC 62056-9-7:2013, Clause 6
5.2 Service specification for the DLMS/COSEM UDP-based transport layer 5.2.1 General
The DLMS/COSEM UDP-based Transport Layer (TL) exclusively offers a connection-less data transfer service known as the UDP-DATA service As a result, the service specifications for both the client and server Transport Layers are identical, as illustrated in Figure 3.
The request and indication service primitives are mandatory The implementation of the local confirm service primitive is optional
The xDLMS APDU pre-fixed with the wrapper header shall fit in a single UDP datagram
Figure 3 – Services of the DLMS/COSEM connection-less, UDP-based transport layer
The UDP-DATA service
This primitive is the service request primitive for the connection-less mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address, Remote_IP_Address, Data_Length,
The Local_wPort, Local_UDP_Port and Local_IP_Address parameters indicate wrapper Port number, UDP Port number and IP Address parameters belonging to the device /
DLMS/COSEM AE requesting to send the Data The Remote_wPort, Remote_UDP_Port and
Remote_IP_Address parameters indicate the wrapper Port number, UDP Port number and IP
Address parameters belonging to the device / DLMS/COSEM AE to which the Data is to be transmitted
IP Lower layers: Data link and Physical
DLMS/COSEM Client Application Layer
DLMS/COSEM UDP-based Transport Layer
UDP -D AT A re q UDP -D AT A cn f UDP -D AT A in d
IP Lower layers: Data link and Physical
DLMS/COSEM UDP-based Transport Layer
DLMS/COSEM Server Application Layer
UDP -D AT A cn f UDP -D AT A in d
The Data_Length parameter indicates the length of the Data parameter in bytes
The Data parameter contains the xDLMS APDU to be transferred to the peer AL
The UDP-DATA.request primitive is invoked by either the client or the server DLMS/COSEM
AL to request sending an APDU to a single peer AL, or, in the case of multi- or broadcasting, to multiple peer ALs
The reception of the service primitive prompts the wrapper sublayer to attach the wrapper header to the received APDU and subsequently invoke the SEND() function of the UDP sublayer with the correctly formatted WPDU as DATA The UDP sublayer will then transmit the WPDU to the corresponding peer wrapper sublayer, following the guidelines outlined in STD 0006.
This primitive is the service indication primitive for the connection-less mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address, Remote_IP_Address, Data_Length,
The parameters Local_wPort, Local_UDP_Port, and Local_IP_Address represent the wrapper port number, UDP port number, and IP address of the device or DLMS/COSEM Application Entity (AE) receiving the data Conversely, the parameters Remote_wPort, Remote_UDP_Port, and Remote_IP_Address denote the wrapper port number, UDP port number, and IP address of the device or AE that has transmitted the data.
The Data_Length parameter indicates the length of the Data parameter in bytes
The Data parameter contains the xDLMS APDU received from the peer AL
The UDP-DATA.indication primitive is produced by the DLMS/COSEM UDP-based Transport Layer to notify the DLMS/COSEM Application Layer service user that an Application Protocol Data Unit (APDU) has been received from the peer layer entity.
The primitive is created upon receiving a UDP Datagram by the UDP sublayer, provided that the Local_UDP_Port and Local_wPort parameters contain valid port numbers This indicates that a DLMS/COSEM Application Entity (AE) is bound to the specified port numbers on the receiving device If the port numbers are invalid, the received message will be discarded.
Figure 3 – Services of the DLMS/COSEM connection-less, UDP-based transport layer
This primitive is the service request primitive for the connection-less mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Remote_wPort, Local_UDP_Port,
Remote_UDP_Port, Local_IP_Address,
Remote_IP_Address, Data_Length,
The Local_wPort, Local_UDP_Port and Local_IP_Address parameters indicate wrapper Port number, UDP Port number and IP Address parameters belonging to the device /
DLMS/COSEM AE requesting to send the Data The Remote_wPort, Remote_UDP_Port and
Remote_IP_Address parameters indicate the wrapper Port number, UDP Port number and IP
Address parameters belonging to the device / DLMS/COSEM AE to which the Data is to be transmitted
IP Lower layers: Data link and Physical
DLMS/COSEM Client Application Layer
DLMS/COSEM UDP-based Transport Layer
UDP -D AT A re q UDP -D AT A cn f UDP -D AT A in d
IP Lower layers: Data link and Physical
DLMS/COSEM UDP-based Transport Layer
DLMS/COSEM Server Application Layer
UDP -D AT A cn f UDP -D AT A in d
The Data_Length parameter indicates the length of the Data parameter in bytes
The Data parameter contains the xDLMS APDU to be transferred to the peer AL
The UDP-DATA.request primitive is invoked by either the client or the server DLMS/COSEM
AL to request sending an APDU to a single peer AL, or, in the case of multi- or broadcasting, to multiple peer ALs
The reception of the service primitive prompts the wrapper sublayer to prepend the wrapper header to the received APDU, subsequently invoking the SEND() function of the UDP sublayer with the correctly formatted WPDU as DATA The UDP sublayer then transmits the WPDU to the corresponding peer wrapper sublayer, as outlined in STD 0006.
This primitive is the service indication primitive for the connection-less mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address, Remote_IP_Address, Data_Length,
The parameters Local_wPort, Local_UDP_Port, and Local_IP_Address represent the wrapper port number, UDP port number, and IP address of the device or DLMS/COSEM Application Entity (AE) receiving the data Conversely, the parameters Remote_wPort, Remote_UDP_Port, and Remote_IP_Address denote the wrapper port number, UDP port number, and IP address of the device or AE that has transmitted the data.
The Data_Length parameter indicates the length of the Data parameter in bytes
The Data parameter contains the xDLMS APDU received from the peer AL
The UDP-DATA.indication primitive is produced by the DLMS/COSEM UDP-based Transport Layer to notify the DLMS/COSEM Application Layer that an Application Protocol Data Unit (APDU) has been received from the peer layer entity.
The primitive is created upon receiving a UDP Datagram by the UDP sublayer, provided that both the Local_UDP_Port and Local_wPort parameters contain valid port numbers This indicates that a DLMS/COSEM Application Entity (AE) is associated with the specified port numbers on the receiving device If the port numbers are invalid, the received message will be discarded.
This primitive is the optional service confirm primitive for connection-less mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address, Remote_IP_Address, Result
The Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address and Remote_IP_Address parameters carry the same values as the corresponding UDP-
DATA.request service being confirmed
The value of the Result parameter indicates whether the DLMS/COSEM UDP-based TL was able to send the requested UDP Datagram (OK) or not (NOK)
The UDP-DATA.confirm primitive is optional If implemented, it is generated by the
DLMS/COSEM TL to confirm to the service user DLMS/COSEM AL the result of the previous
The UDP-DATA.request is generated locally to indicate the potential for sending data in the request primitive A subsequent UDP-DATA.confirm with a Result of OK signifies that the data has been sent, but it does not guarantee successful delivery to the intended destination.
Protocol specification for the DLMS/COSEM UDP-based transport layer
General
As it is shown in Figure 2, the DLMS/COSEM UDP-based TL includes the Internet Standard
UDP layer, as specified in Internet Standard STD 0006, and the DLMS/COSEM-specific light- weight wrapper sublayer
The wrapper sublayer in this communication profile functions as a stateless entity, primarily responsible for ensuring the identification of source and destination DLMS/COSEM Application Entities (AEs) through wPort numbers, as well as facilitating the conversion between OSI-style UDP-DATA.xxx service invocations.
SEND() and RECEIVE() interface functions provided by the standard UDP
To ensure consistency in the wrapper protocol control information across both transport layers, the wrapper sublayer must include the Data Length information in the wrapper protocol data unit, even though this is not required in the UDP-based profile.
The wrapper protocol data unit (WPDU)
The WPDU consists of two parts:
• the wrapper header part, containing the wrapper control information; and
• the data part, containing the DATA parameter – an xDLMS APDU – of the corresponding UDP-DATA.xxx service invocation
The wrapper header includes four fields, see Figure 4 Each field is a 16 bit long unsigned integer value
The version of the wrapper, currently set to 0x0001, is governed by the DLMS UA It's important to note that future versions may feature a different structure for the wrapper header.
• Source wPort: carries the wPort number identifying the sending DLMS/COSEM AE;
• Destination wPort: carries the wPort number identifying the receiving DLMS/COSEM AE;
• Data length: indicates the length of the DATA field of the WPDU (the xDLMS APDU transported)
NOTE The maximum length of the APDU should be eight bytes less than the maximum length of the UDP datagram
Figure 4 – The wrapper protocol data unit (WPDU)
The DLMS/COSEM UDP-based transport layer protocol data unit
In this profile, WPDUs shall be transmitted in UDP Datagrams, specified in Internet Standard STD 0006 They shall encapsulate the WPDU, as shown in Figure 5
Figure 5 – The DLMS/COSEM connection-less, UDP-based transport layer PDU (UDP-PDU)
Source wPort, 2 bytes Destination wPort: 2 bytes
Wrapper control information Data field
Source UDP Port, 2 bytes Destination UDP Port: 2 bytes UDP Length: 2 bytes
UDP protocol control information Data field of the UDP PDU (WPDU)
This primitive is the optional service confirm primitive for connection-less mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_UDP_Port, Remote_UDP_Port,
Local_IP_Address, Remote_IP_Address,
The Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address and Remote_IP_Address parameters carry the same values as the corresponding UDP-
DATA.request service being confirmed
The value of the Result parameter indicates whether the DLMS/COSEM UDP-based TL was able to send the requested UDP Datagram (OK) or not (NOK)
The UDP-DATA.confirm primitive is optional If implemented, it is generated by the
DLMS/COSEM TL to confirm to the service user DLMS/COSEM AL the result of the previous
The UDP-DATA.request is generated locally to indicate the potential for sending data in the request primitive A UDP-DATA.confirm with a Result of OK signifies that the data has been sent, but it does not guarantee successful delivery to the intended destination.
5.3 Protocol specification for the DLMS/COSEM UDP-based transport layer
As it is shown in Figure 2, the DLMS/COSEM UDP-based TL includes the Internet Standard
UDP layer, as specified in Internet Standard STD 0006, and the DLMS/COSEM-specific light- weight wrapper sublayer
The wrapper sublayer in this communication profile functions as a stateless entity, primarily responsible for ensuring the identification of source and destination DLMS/COSEM Application Entities (AEs) through wPort numbers, as well as facilitating the conversion between OSI-style UDP-DATA.xxx service invocations.
SEND() and RECEIVE() interface functions provided by the standard UDP
To ensure consistency in the wrapper protocol control information across both transport layers, the wrapper sublayer must include the Data Length information in the wrapper protocol data unit, even though it is not required in the UDP-based profile.
5.3.2 The wrapper protocol data unit (WPDU)
The WPDU consists of two parts:
• the wrapper header part, containing the wrapper control information; and
• the data part, containing the DATA parameter – an xDLMS APDU – of the corresponding UDP-DATA.xxx service invocation
The wrapper header includes four fields, see Figure 4 Each field is a 16 bit long unsigned integer value
The version of the wrapper, currently set to 0x0001, is governed by the DLMS UA It is important to note that future versions may feature a different structure for the wrapper header.
• Source wPort: carries the wPort number identifying the sending DLMS/COSEM AE;
• Destination wPort: carries the wPort number identifying the receiving DLMS/COSEM AE;
• Data length: indicates the length of the DATA field of the WPDU (the xDLMS APDU transported)
NOTE The maximum length of the APDU should be eight bytes less than the maximum length of the UDP datagram
Figure 4 – The wrapper protocol data unit (WPDU)
5.3.3 The DLMS/COSEM UDP-based transport layer protocol data unit
In this profile, WPDUs shall be transmitted in UDP Datagrams, specified in Internet Standard STD 0006 They shall encapsulate the WPDU, as shown in Figure 5
Figure 5 – The DLMS/COSEM connection-less, UDP-based transport layer PDU (UDP-PDU)
Source wPort, 2 bytes Destination wPort: 2 bytes
Wrapper control information Data field
Source UDP Port, 2 bytes Destination UDP Port: 2 bytes UDP Length: 2 bytes
UDP protocol control information Data field of the UDP PDU (WPDU)
From the external point of view, the DLMS/COSEM connection-less TL PDU is an ordinary
The UDP Datagram encapsulates all DLMS/COSEM specific elements, including the wrapper-specific header, within the UDP Data field This design allows for the straightforward reuse of standard UDP implementations to effectively implement this transport layer.
The Source and Destination UDP ports can represent either local or remote ports based on the data transfer direction For the sending device, the Source UDP port in a Datagram aligns with the Local_UDP_port, while for the receiving device, it corresponds to the remote port.
Remote_UDP_Port service parameter
The UDP specification allows for the source UDP Port and Checksum fields to be filled with real data optionally, where a zero value indicates that these fields are not utilized However, in the DLMS/COSEM_on_IP profile, it is mandatory to always populate the source UDP Port field with the actual source UDP port number.
Reserved wrapper port numbers (wPorts)
Reserved wPort Numbers are specified in Table 1:
Table 1 – Reserved wrapper port numbers in the UDP-based DLMS/COSEM TL
Open for client SAP assignment 0x02…0x0F
Open for server SAP assignment 0x0010,,,0x007E
Protocol state machine
The wrapper sublayer in this profile operates in a stateless manner, meaning that all protocol-related matters, including the protocol state machine, adhere to the rules outlined in the Internet standards.
Standard STD 0006 The only supplementary rule is concerning discarding inappropriate messages: messages with an invalid destination wPort number – meaning that there is no
DLMS/COSEM AE in the receiving device bound to this wPort number – shall be discarded by the wrapper sublayer
6 The DLMS/COSEM connection-oriented, TCP-based transport layer
General
The DLMS/COSEM connection-oriented transport layer utilizes the Transmission Control Protocol (TCP), which is an end-to-end reliable protocol This reliability is achieved through a conceptual "virtual circuit" that employs a specific method.
PAR, or Positive Acknowledgement with Retransmission, ensures reliable data delivery by incorporating error detection and re-transmission of data packets after an acknowledgement time-out This protocol effectively addresses issues related to lost, delayed, duplicated, or erroneous data packets Additionally, TCP enhances communication with its efficient flow control mechanism and supports full-duplex operation.
TCP is a connection-oriented transfer protocol that consists of three key phases: connection establishment, data exchange, and connection release The DLMS/COSEM TCP-based transport layer offers OSI-style services to service users throughout all these phases.
• for the connection establishment phase, the TCP-CONNECT service is provided to the service user TCP connection manager process;
• for the data transfer phase, the TCP-DATA service is provided to the service user DLMS/COSEM AL;
• for the connection closing phase, the TCP-DISCONNECT service is provided to the service user TCP connection manager process;
• in addition, a TCP-ABORT service is provided to the service user DLMS/COSEM AL
The DLMS/COSEM connection-oriented, TCP-based transport layer features a wrapper sublayer identical to that of the UDP-based transport layer This wrapper not only converts OSI-style services into TCP function calls but also includes essential addressing and length information.
The DLMS/COSEM connection-oriented transport layer is defined through its services and protocols, utilizing a TCP-based framework Annex A details the conversion process between OSI-style services and TCP function calls.
Service specification for the DLMS/COSEM TCP-based transport layer
General
The DLMS/COSEM connection-oriented, TCP-based TL provides the same set of services both at the client and at the server sides, as it is shown in Figure 6
From the external point of view, the DLMS/COSEM connection-less TL PDU is an ordinary
The UDP Datagram encapsulates all DLMS/COSEM specific elements, including the wrapper-specific header, within the UDP Data field This design allows for the straightforward reuse of standard UDP implementations to effectively facilitate this transport layer.
The Source and Destination UDP ports can represent either local or remote ports based on the data transfer direction For the sending device, the Source UDP port in a Datagram aligns with the Local_UDP_port, while for the receiving device, it corresponds to the remote port.
Remote_UDP_Port service parameter
The UDP specification allows for the source UDP Port and Checksum fields to be filled with real data optionally, where a zero value indicates that the fields are not used However, in the DLMS/COSEM_on_IP profile, it is mandatory to always populate the source UDP Port field with the actual source UDP port number.
5.3.4 Reserved wrapper port numbers (wPorts)
Reserved wPort Numbers are specified in Table 1:
Table 1 – Reserved wrapper port numbers in the UDP-based DLMS/COSEM TL
Open for client SAP assignment 0x02…0x0F
Open for server SAP assignment 0x0010,,,0x007E
The wrapper sublayer in this profile operates in a stateless manner, meaning that all protocol-related matters, including the protocol state machine, adhere to the rules outlined in the Internet standards.
Standard STD 0006 The only supplementary rule is concerning discarding inappropriate messages: messages with an invalid destination wPort number – meaning that there is no
DLMS/COSEM AE in the receiving device bound to this wPort number – shall be discarded by the wrapper sublayer
6 The DLMS/COSEM connection-oriented, TCP-based transport layer
The DLMS/COSEM connection-oriented transport layer utilizes the Transmission Control Protocol (TCP), which is an end-to-end reliable protocol This reliability is achieved through a conceptual "virtual circuit" that employs a specific method.
PAR, or Positive Acknowledgement with Retransmission, ensures reliable data delivery by incorporating error detection and re-transmission of data packets after an acknowledgement time-out This protocol effectively addresses issues related to lost, delayed, duplicated, or erroneous data packets Additionally, TCP enhances communication with its efficient flow control mechanism and supports full-duplex operation.
TCP is a connection-oriented transfer protocol that consists of three key phases: connection establishment, data exchange, and connection release The DLMS/COSEM TCP-based transport layer offers OSI-style services to service users throughout all these phases.
• for the connection establishment phase, the TCP-CONNECT service is provided to the service user TCP connection manager process;
• for the data transfer phase, the TCP-DATA service is provided to the service user DLMS/COSEM AL;
• for the connection closing phase, the TCP-DISCONNECT service is provided to the service user TCP connection manager process;
• in addition, a TCP-ABORT service is provided to the service user DLMS/COSEM AL
The DLMS/COSEM connection-oriented, TCP-based transport layer features a wrapper sublayer identical to that of the UDP-based transport layer This wrapper not only converts OSI-style services into TCP function calls but also includes essential addressing and length information.
The DLMS/COSEM connection-oriented transport layer utilizes TCP and is defined through specific services and protocols Annex A details the conversion process between OSI-style services and TCP function calls.
6.2 Service specification for the DLMS/COSEM TCP-based transport layer 6.2.1 General
The DLMS/COSEM connection-oriented, TCP-based TL provides the same set of services both at the client and at the server sides, as it is shown in Figure 6
Figure 6 – Services of the DLMS/COSEM connection-oriented,TCP-based transport layer
This communication profile outlines the complete set of service primitives for TCP connection management, including TCP-CONNECT and TCP-DISCONNECT, available for both client and server sides This functionality enables the server to initiate and terminate TCP connections effectively.
NOTE Application association establishment is performed by the client AE
The TCP connection management services are utilized by the TCP connection manager process rather than the DLMS/COSEM Application Layer (AL) While the details of this process are not covered in this companion specification, the DLMS/COSEM AL outlines specific requirements related to it, as referenced in IEC 62056-9-7:2013, section 9.1.
An additional COSEM-ABORT service is provided to indicate to the DLMS/COSEM AL the disruption or disconnection of the supporting TCP connection
In the TCP-based DLMS/COSEM protocol, the TCP-DATA.confirm service primitive is optional, while the TCP-DATA.request service can be confirmed either locally or remotely.
The TCP-CONNECT service
This primitive is the service request primitive for the connection establishment service
Semantics of the service primitive
IP Lower layers: Data link and Physical
DLMS/COSEM Client Application Layer
T CP -C O N N E C T r eq/ c nf in d/ r es T CP -D IS C ON N E C T r eq / cn f i nd / res
DLMS/COSEM TCP-based Transport Layer
T CP -A B OR T in d T CP -D A T A re q T CP -D A T A c nf T CP -D A T A in d
COSEM Server Application Process TCP Connection Manager
T CP -D IS C ON N E C T r eq / cn f i nd / res T CP -C O N N E C T r eq/ c nf in d/ r es
IP Lower layers: Data link and Physical
DLMS/COSEM TCP-based Transport Layer
DLMS/COSEM Server Application Layer
T CP -D A T A c nf T CP -D A T A in d T CP -A B OR T in d
The primitive shall provide parameters as follows:
Remote_TCP_Port, Local_IP_Address, Remote_IP_Address
) The Local_TCP_Port and Remote_TCP_Port parameters identify the local and remote TCP ports respectively The Local_IP_Address and Remote_IP_Address parameters indicate the
IP Address of the physical device requesting the TCP connection and of the target physical device, to which the TCP connection requested is to be established
The TCP-CONNECT.request primitive is invoked by the service user TCP connection manager process to establish a connection with the peer DLMS/COSEM TCP-based TL
This primitive is the service indication primitive for the connection establishment service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Remote_TCP_Port, Local_IP_Address, Remote_IP_Address
The Local_TCP_Port and Remote_TCP_Port parameters specify the TCP ports for establishing a connection, while the Local_IP_Address and Remote_IP_Address parameters represent the IP addresses of the devices involved in the TCP connection.
The TCP-CONNECT.indication primitive is triggered by the DLMS/COSEM TCP-based TL upon receiving a TCP packet, signaling to the TCP connection manager that a remote device is initiating a new TCP connection.
This primitive is the service response primitive for the connection establishment service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port,
Figure 6 – Services of the DLMS/COSEM connection-oriented,TCP-based transport layer
This communication profile outlines the complete set of service primitives for TCP connection management services, including TCP-CONNECT and TCP-DISCONNECT, available on both the client and server sides This enables the server to initiate and terminate TCP connections as well.
NOTE Application association establishment is performed by the client AE
The TCP connection management services are utilized by the TCP connection manager process rather than the DLMS/COSEM Application Layer (AL) While the details of this process are not covered in this companion specification, the DLMS/COSEM AL does impose certain requirements related to it, as outlined in IEC 62056-9-7:2013, section 9.1.
An additional COSEM-ABORT service is provided to indicate to the DLMS/COSEM AL the disruption or disconnection of the supporting TCP connection
In the TCP-based DLMS/COSEM protocol, the TCP-DATA.confirm service primitive is optional, while the TCP-DATA.request service can be confirmed either locally or remotely.
This primitive is the service request primitive for the connection establishment service
Semantics of the service primitive
IP Lower layers: Data link and Physical
DLMS/COSEM Client Application Layer
T CP -C O N N E C T r eq/ c nf in d/ r es T CP -D IS C ON N E C T r eq / cn f i nd / res
DLMS/COSEM TCP-based Transport Layer
T CP -A B OR T in d T CP -D A T A re q T CP -D A T A c nf T CP -D A T A in d
COSEM Server Application Process TCP Connection Manager
T CP -D IS C ON N E C T r eq / cn f i nd / res T CP -C O N N E C T r eq/ c nf in d/ r es
IP Lower layers: Data link and Physical
DLMS/COSEM TCP-based Transport Layer
DLMS/COSEM Server Application Layer
T CP -D A T A c nf T CP -D A T A in d T CP -A B OR T in d
The primitive shall provide parameters as follows:
Remote_TCP_Port, Local_IP_Address, Remote_IP_Address
) The Local_TCP_Port and Remote_TCP_Port parameters identify the local and remote TCP ports respectively The Local_IP_Address and Remote_IP_Address parameters indicate the
IP Address of the physical device requesting the TCP connection and of the target physical device, to which the TCP connection requested is to be established
The TCP-CONNECT.request primitive is invoked by the service user TCP connection manager process to establish a connection with the peer DLMS/COSEM TCP-based TL
This primitive is the service indication primitive for the connection establishment service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Remote_TCP_Port, Local_IP_Address, Remote_IP_Address
The Local_TCP_Port and Remote_TCP_Port parameters specify the TCP ports for establishing a connection, while the Local_IP_Address and Remote_IP_Address parameters identify the IP addresses of the devices involved in the TCP connection.
The TCP-CONNECT.indication primitive is triggered by the DLMS/COSEM TCP-based transport layer upon receiving a TCP packet, signaling to the TCP connection manager that a remote device is attempting to establish a new TCP connection.
This primitive is the service response primitive for the connection establishment service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port,
Local_IP_Address, Remote_IP_Address, Result
The Local_TCP_Port and Remote_TCP_Port parameters define the two TCP ports involved in establishing a connection, while the Local_IP_Address and Remote_IP_Address parameters specify the IP addresses of the physical devices engaged in the TCP connection.
The Result parameter indicates that the service user TCP connection manager has accepted the requested TCP connection Its value is always SUCCESS
The TCP-CONNECT.response primitive is used by the TCP connection manager to inform the DLMS/COSEM TCP-based TL about the acceptance of a previously requested TCP connection It is important to note that the TCP connection manager does not have the ability to reject a connection request.
This primitive is the service confirm primitive for the connection establishment service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Result,
The Local_TCP_Port and Remote_TCP_Port parameters define the two TCP ports involved in the connection, while the Local_IP_Address and Remote_IP_Address parameters specify the IP addresses of the physical devices engaged in this TCP connection.
The Result parameter indicates whether the requested TCP connection is established or not
Note, that this service primitive is normally the result of a remote confirmation – and as a TCP connection request cannot be rejected, the Result parameter shall always indicate SUCCESS
However, the Result parameter may also indicate FAILURE, when it is locally confirmed In this case the Reason_of_Failure parameter indicates the reason for the failure
The TCP-CONNECT.confirm primitive is generated by the DLMS/COSEM TCP-based TL to indicate to the service user TCP connection manager process the result of a TCP-
CONNECT.request service invocation received previously.
The TCP-DISCONNECT service
This primitive is the service request primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address )
The service parameters identify the TCP connection to be terminated, with the Local_TCP_Port and Local_IP_Address specifying the local port and IP address of the requesting device and application, while the Remote_IP_Address and Remote_TCP_Port indicate the remote device and application involved in the connection.
The TCP-DISCONNECT.request primitive is invoked by the service user TCP connection manager process to request the disconnection of an existing TCP connection
This primitive is the service indication primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Reason
The parameters Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, and Remote_IP_Address define the TCP connection that is either being released by the peer device or has been aborted.
The Reason parameter determines the cause of a TCP disconnection, indicating whether it was initiated by a peer device's request (Reason == REMOTE_REQ) or triggered locally due to an event that necessitates the disconnection (Reason = ABORT).
The DLMS/COSEM Transport layer can provide additional insights into the reasons for an ABORT through layer management services, although these services are not covered by this International Standard.
Local_IP_Address, Remote_IP_Address,
The Local_TCP_Port and Remote_TCP_Port parameters define the TCP ports involved in the connection, while the Local_IP_Address and Remote_IP_Address parameters specify the IP addresses of the two devices engaged in the TCP connection.
The Result parameter indicates that the service user TCP connection manager has accepted the requested TCP connection Its value is always SUCCESS
The TCP-CONNECT.response primitive is used by the TCP connection manager to inform the DLMS/COSEM TCP-based TL about the acceptance of a previously requested TCP connection It is important to note that the TCP connection manager does not have the ability to reject a connection request.
This primitive is the service confirm primitive for the connection establishment service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port,
Local_IP_Address, Remote_IP_Address,
The Local_TCP_Port and Remote_TCP_Port parameters define the two TCP ports involved in the connection, while the Local_IP_Address and Remote_IP_Address parameters specify the IP addresses of the physical devices engaged in this TCP connection.
The Result parameter indicates whether the requested TCP connection is established or not
Note, that this service primitive is normally the result of a remote confirmation – and as a TCP connection request cannot be rejected, the Result parameter shall always indicate SUCCESS
However, the Result parameter may also indicate FAILURE, when it is locally confirmed In this case the Reason_of_Failure parameter indicates the reason for the failure
The TCP-CONNECT.confirm primitive is generated by the DLMS/COSEM TCP-based TL to indicate to the service user TCP connection manager process the result of a TCP-
CONNECT.request service invocation received previously
6.2.3 The TCP-DISCONNECT service 6.2.3.1 TCP-DISCONNECT.request
This primitive is the service request primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address )
The service parameters identify the TCP connection to be released, including the Local_TCP_Port and Local_IP_Address, which represent the local TCP port and IP address of the requesting device and application Additionally, the Remote_IP_Address and Remote_TCP_Port parameters pertain to the remote device and application involved in the connection.
The TCP-DISCONNECT.request primitive is invoked by the service user TCP connection manager process to request the disconnection of an existing TCP connection
This primitive is the service indication primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Reason
The parameters Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, and Remote_IP_Address define the TCP connection that is either being released by the peer device or has been aborted.
The Reason parameter specifies the cause of the service invocation, indicating whether a TCP disconnection was requested by a peer device (Reason == REMOTE_REQ) or initiated locally due to an event that necessitates the disconnection (Reason = ABORT).
The DLMS/COSEM Transport layer can provide additional insights into the reasons for an ABORT through layer management services, although these services are not covered by this International Standard.
The TCP-DISCONNECT.indication primitive is issued by the DLMS/COSEM TCP-based Transport Layer to notify the TCP connection manager that a peer entity has requested to disconnect an active TCP connection This primitive also serves to signal a non-solicited disconnection, such as when the physical connection is interrupted.
This primitive is the service response primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Result
) The Local_TCP_Port and Remote_TCP_Port parameters identify the two TCP ports between which the TCP connection has to be disconnected The Local_IP_Address and
Remote_IP_Address parameters indicate the IP addresses of the two physical devices participating in the TCP connection to be disconnected
The Result parameter indicates that the service user TCP connection manager process has accepted to disconnect the TCP connection referenced The value of this parameter is always
The TCP-DISCONNECT.response primitive is invoked by the TCP connection manager process to indicate to the DLMS/COSEM TCP-based TL whether the previously requested
TCP disconnection is accepted Note that the TCP connection manager process cannot reject the requested disconnection This service primitive is invoked only if the corresponding TCP-
DISCONNECT.indication service indicated a remotely initiated disconnection request (Reason
This primitive is the service confirm primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Result,
The Local_TCP_Port and Remote_TCP_Port parameters specify the two TCP ports involved in the disconnection of a TCP connection Meanwhile, the Local_IP_Address and Remote_IP_Address parameters represent the IP addresses of the two physical devices that are part of the TCP connection to be terminated.
The Result parameter signifies the success of the referenced TCP connection disconnection Typically, this service primitive is triggered by a remote confirmation, and since a TCP disconnection request cannot be denied, the Result parameter consistently holds the value of SUCCESS.
However, the Result parameter may also indicate FAILURE, when it is locally confirmed In this case the Reason_of_Failure parameter indicates the reason of the failure
The TCP-DISCONNECT.confirm primitive is used by the DLMS/COSEM TCP-based Transport Layer to inform the TCP connection manager about the outcome of a prior TCP-DISCONNECT.request service call.
The TCP-ABORT service
This primitive is the service indication primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
The Local_TCP_Port and Remote_TCP_Port parameters specify the two TCP ports involved in the aborted connection, while the Local_IP_Address and Remote_IP_Address parameters represent the IP addresses of the two physical devices that were part of the terminated TCP connection.
The Reason parameter indicates the reason of the TCP abort This parameter is optional
The TCP-ABORT.indication primitive is produced by the DLMS/COSEM TCP-based Transport Layer to inform the DLMS/COSEM Application Layer of an unsolicited interruption in the supporting TCP connection.
Upon receiving this indication, the DLMS/COSEM Application Layer (AL) will terminate all Active Associations (AAs) associated with the TCP connection and notify the COSEM Application Protocol (AP) through the COSEM-ABORT.indication service primitive, as outlined in IEC 62056-5-3:2013, section 6.4.
The TCP-DISCONNECT.indication primitive is generated by the DLMS/COSEM TCP-based Transport Layer (TL) to notify the TCP connection manager process that the peer entity has requested to disconnect an existing TCP connection This primitive also serves to indicate a non-solicited disconnection, such as when the physical connection is interrupted.
This primitive is the service response primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port,
Local_IP_Address, Remote_IP_Address,
The Local_TCP_Port and Remote_TCP_Port parameters identify the two TCP ports between which the TCP connection has to be disconnected The Local_IP_Address and
Remote_IP_Address parameters indicate the IP addresses of the two physical devices participating in the TCP connection to be disconnected
The Result parameter indicates that the service user TCP connection manager process has accepted to disconnect the TCP connection referenced The value of this parameter is always
The TCP-DISCONNECT.response primitive is invoked by the TCP connection manager process to indicate to the DLMS/COSEM TCP-based TL whether the previously requested
TCP disconnection is accepted Note that the TCP connection manager process cannot reject the requested disconnection This service primitive is invoked only if the corresponding TCP-
DISCONNECT.indication service indicated a remotely initiated disconnection request (Reason
This primitive is the service confirm primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port,
Local_IP_Address, Remote_IP_Address,
The Local_TCP_Port and Remote_TCP_Port parameters specify the TCP ports involved in the disconnection of a TCP connection, while the Local_IP_Address and Remote_IP_Address parameters represent the IP addresses of the two physical devices engaged in that connection.
The Result parameter signifies the success of the referenced TCP connection disconnection Typically, this service primitive is triggered by a remote confirmation, and since a TCP disconnection request cannot be denied, the Result parameter consistently holds the value of SUCCESS.
However, the Result parameter may also indicate FAILURE, when it is locally confirmed In this case the Reason_of_Failure parameter indicates the reason of the failure
The TCP-DISCONNECT.confirm primitive is used by the DLMS/COSEM TCP-based Transport Layer to inform the TCP connection manager about the outcome of a prior TCP-DISCONNECT.request service invocation.
6.2.4 The TCP-ABORT service 6.2.4.1 TCP-ABORT.indication
This primitive is the service indication primitive for the connection termination service
Semantics of the service primitive
The primitive shall provide parameters as follows:
The Local_TCP_Port and Remote_TCP_Port parameters specify the two TCP ports involved in the aborted connection, while the Local_IP_Address and Remote_IP_Address parameters represent the IP addresses of the two physical devices that were part of the terminated TCP connection.
The Reason parameter indicates the reason of the TCP abort This parameter is optional
The TCP-ABORT.indication primitive is produced by the DLMS/COSEM TCP-based Transport Layer to inform the DLMS/COSEM Application Layer service user about an unsolicited interruption of the underlying TCP connection.
Upon receiving this indication, the DLMS/COSEM Application Layer (AL) will terminate all Active Associations (AAs) established through the TCP connection and notify the COSEM Application Protocol (AP) using the COSEM-ABORT.indication service primitive, as outlined in IEC 62056-5-3:2013, section 6.4.
The TCP-DATA service
This primitive is the service request primitive for the connection mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Data_Length,
The parameters Local_wPort, Local_TCP_Port, and Local_IP_Address specify the wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM Application Entity (AE) that is requesting data transmission Conversely, the parameters Remote_wPort, Remote_TCP_Port, and Remote_IP_Address denote the corresponding wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM AE that will receive the data.
The Data_Length parameter indicates the length of the Data parameter in bytes
The Data parameter contains the xDLMS APDU to be transferred to the peer AL
The TCP-DATA.request primitive is invoked by either the client or the server DLMS/COSEM
AL to request sending an APDU to a single peer application
The reception of this primitive will prompt the wrapper sublayer to pre-fix the wrapper-specific fields (Local_wPort, Remote_wPort, and Data_Length) to the received xDLMS APDU Subsequently, it will invoke the SEND() function of the TCP sublayer with the correctly formatted WPDU as DATA The TCP sublayer will then transmit the WPDU to the peer TCP sublayer, following the guidelines outlined in STD 0007.
This primitive is the service indication primitive for the connection mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Data_Length,
The parameters Local_wPort, Local_TCP_Port, and Local_IP_Address represent the wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM Application Entity (AE) receiving the data Conversely, the Remote_wPort, Remote_TCP_Port, and Remote_IP_Address parameters denote the corresponding wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM AE that has transmitted the data Additionally, the Data_Length parameter specifies the size of the data in bytes.
The Data parameter contains the xDLMS APDU received from the peer AL
The TCP-DATA.indication primitive is produced by the DLMS/COSEM Transport Layer (TL) to notify the DLMS/COSEM Application Layer (AL) of the receipt of an xDLMS Application Protocol Data Unit (APDU) from a remote device This indication occurs after a complete APDU is received through one or more TCP packets, provided that the Local_TCP_Port and Local_wPort parameters in the TCP packets contain valid port numbers This validation ensures that a DLMS/COSEM Application Entity (AE) is present in the receiving device and bound to the specified port numbers; otherwise, the received message is discarded.
This primitive is the optional service confirm primitive for the connection mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
This primitive is the service request primitive for the connection mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_TCP_Port, Remote_TCP_Port,
Local_IP_Address, Remote_IP_Address,
The parameters Local_wPort, Local_TCP_Port, and Local_IP_Address represent the wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM Application Entity (AE) that is requesting data transmission Conversely, the parameters Remote_wPort, Remote_TCP_Port, and Remote_IP_Address denote the wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM AE that will receive the data.
The Data_Length parameter indicates the length of the Data parameter in bytes
The Data parameter contains the xDLMS APDU to be transferred to the peer AL
The TCP-DATA.request primitive is invoked by either the client or the server DLMS/COSEM
AL to request sending an APDU to a single peer application
The reception of this primitive will prompt the wrapper sublayer to pre-fix the wrapper-specific fields (Local_wPort, Remote_wPort, and Data_Length) to the received xDLMS APDU Subsequently, it will invoke the SEND() function of the TCP sublayer with the correctly formatted WPDU as DATA The TCP sublayer will then transmit the WPDU to the peer TCP sublayer, following the guidelines outlined in STD 0007.
This primitive is the service indication primitive for the connection mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Data_Length,
The parameters Local_wPort, Local_TCP_Port, and Local_IP_Address represent the wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM Application Entity (AE) receiving the data Conversely, the Remote_wPort, Remote_TCP_Port, and Remote_IP_Address parameters denote the wrapper port number, TCP port number, and IP address of the device or DLMS/COSEM AE that has transmitted the data Additionally, the Data_Length parameter specifies the length of the data in bytes.
The Data parameter contains the xDLMS APDU received from the peer AL
The TCP-DATA.indication primitive is produced by the DLMS/COSEM Transport Layer (TL) to notify the DLMS/COSEM Application Layer (AL) of the receipt of an xDLMS Application Protocol Data Unit (APDU) from a remote device This indication occurs after a complete APDU is received, which may be split across multiple TCP packets, provided that the Local_TCP_Port and Local_wPort parameters in the TCP packets contain valid port numbers This validation ensures that there is a corresponding DLMS/COSEM Application Entity (AE) in the receiving device associated with those port numbers; otherwise, the received message will be discarded.
This primitive is the optional service confirm primitive for the connection mode data transfer service
Semantics of the service primitive
The primitive shall provide parameters as follows:
Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Confirmation_Type, Result
) The Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address and Remote_IP_Address parameters carry the same values as the corresponding TCP-
DATA.request service being confirmed
The Confirmation_Type parameter indicates whether the confirmation service is a LOCAL or a
The Result parameter reflects the outcome of the preceding TCP-DATA.request service, with possible values of OK or NOK, which are interpreted based on the implementation of the confirm primitive as detailed in section 6.3.5.4.
The TCP-DATA.confirm primitive is optional If implemented, it is generated by the
DLMS/COSEM TL to confirm to the service user DLMS/COSEM AL the result of the execution of the previous request primitive.