Iec 62056-4-7-2015.Pdf

IEC 62056 4 7 Edition 1 0 201 5 05 INTERNATIONAL STANDARD NORME INTERNATIONALE Electricity metering data exchange – The DLMS/COSEM suite – Part 4 7 DLMS/COSEM transport layer for IP networks Échange d[.]

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 handle the communication aspects of 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 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 operate alongside 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)

The Convergence/Adaptation Layer wrapper sublayer is a lightweight and nearly stateless component that primarily serves to adapt the OSI-style service set offered by the DLMS/COSEM Transport Layer to function calls for UDP or TCP, 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.

According to IEC 62056-9-7:2013, Clause 6, the DLMS/COSEM Application Layer (AL) operates on a single UDP or TCP port In contrast, IEC 62056-6-2:2013, Section 4.7, states that 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.

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 1 0

The DLMS/COSEM connection-less TL is based on the User Datagram Protocol (UDP) as specified in STD 0006

DLMS/COSEM U DP-based Transport Layer

COSEM appl i cati on l ayer servi ces

DLMS/COSEM conn ecti onl ess transport servi ces UDP-DATA.req/ i nd/( cnf)

UDP fun cti on cal l s SEND, RECEI VE a) the UDP-based profile

DLMS/COSEM TCP-based Transport Layer

COSEM appl i cati on layer servi ces

DLMS/COSEM connecti on-ori ented transport servi ces TCP-DATA req/ i nd/( cnf)

TCP functi on cal l s acti ve/passi ve OPEN, SEND, RECEI VE b) the TCP-based profile

TC P- C O N N E C T se rv ic es TC P -D IS C O N N EC T se rv ic 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 offers 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:201 3, Clause 6.

Service specification for the DLMS/COSEM UDP-based transport layer 1 1

General 1 1

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 1 2

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:

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) that is requesting data transmission 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 DLMS/COSEM AE designated to receive the data.

IP Lower layers: Data link and Ph ysical

DLMS/COSEM Client Application Layer

DLMS/COSEM UDP-based Transport Layer

U D P -D A TA r eq U D P -D AT A c nf U D P -D A TA in d

IP Lower l ayers: Data li nk and Ph ysical

DLMS/COSEM UDP-based Transport Layer

DLMS/COSEM Server Applicati on Layer

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

Upon receiving this service primitive, the wrapper sublayer will prepend 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, as outlined in STD 0006.

This primitive is the service indication primitive for the connection-less mode data transfer service

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 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 bound to the specified port numbers on the receiving device If the parameters are invalid, the received message will be discarded.

This primitive is the optional service confirm primitive for connection-less mode data transfer service

Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address, Remote_IP_Address, Result

The parameters Local_wPort, Remote_wPort, Local_UDP_Port, Remote_UDP_Port, Local_IP_Address, and Remote_IP_Address retain the same values as those in 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 an optional feature generated by the DLMS/COSEM Transport Layer to inform the service user, DLMS/COSEM Application Layer, about the outcome of the previous UDP-DATA.request This confirmation is locally produced and solely indicates whether the data in the request was sent successfully Specifically, an 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 1 4

General 1 4

The DLMS/COSEM UDP-based Transport Layer (TL) incorporates the Internet Standard UDP layer, as outlined in Internet Standard STD 0006, along with a specialized lightweight wrapper sublayer tailored for DLMS/COSEM.

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 Additionally, it facilitates the conversion between OSI-style UDP-DATA.xxx service invocations and the standard UDP interface functions, SEND() and RECEIVE().

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) 1 4

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 1 6 bit long unsigned integer value

The version of the wrapper is indicated by the value controlled by the DLMS UA, currently set at 0x0001 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)

The DLMS/COSEM UDP-based transport layer protocol data unit 1 5

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)

The DLMS/COSEM connection-less TL PDU functions as a standard UDP Datagram, with all DLMS/COSEM specific elements, including the wrapper-specific header, contained 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_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.

Reserved wrapper port numbers (wPorts) 1 6

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

0x1 1 … 0xFF Server side reserved addresses

Open for server SAP assignment 0x001 0,,,0x007E

Protocol state machine 1 6

The wrapper sublayer in this profile operates in a stateless manner, adhering to the governing rules outlined in Internet Standard STD 0006 for all protocol-related issues, including the protocol state machine An additional rule specifies that messages with an invalid destination wPort number, indicating the absence of a DLMS/COSEM Application Entity (AE) bound to that wPort number in the receiving device, must be discarded by the wrapper sublayer.

6 The DLMS/COSEM connection-oriented, TCP-based transport layer

General 1 6

The DLMS/COSEM connection-oriented transport layer utilizes the Transmission Control Protocol (TCP), which is a reliable end-to-end protocol TCP ensures data reliability through a virtual circuit and employs Positive Acknowledgement with Retransmission (PAR) to guarantee acknowledged data delivery, error detection, and data retransmission after time-outs This protocol effectively manages lost, delayed, duplicated, or erroneous data packets while also providing efficient flow control and full-duplex operation.

TCP is a connection-oriented transfer protocol that consists of three key phases: connection establishment, data exchange, and connection release As a result, 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.

Service specification for the DLMS/COSEM TCP-based transport layer 1 7

General 1 7

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 services, including TCP-CONNECT and TCP-DISCONNECT, available on both the 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, not by the DLMS/COSEM Application Layer (AL) While the details of this process are beyond the scope of 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-DATA service, similar to the DLMS/COSEM UDP-based transport layer, the TCP-DATA.confirm service primitive is optional However, the TCP-DATA.request service can be confirmed either locally or remotely.

The TCP-CONNECT service 1 8

This primitive is the service request primitive for the connection establishment service

I P Lower layers: Data link and Ph ysical

DLMS/COSEM Client Applicati on Layer

TC P -C O N N E C T re q/ c nf i nd /.r es TC P -D IS C O N N E C T re q/ c nf in d/ r es DLMS/COSEM TCP-based Transport Layer

COSEM Client Appli cation Process

TC P -A B O R T in d TC P -D A TA r eq TC P -D A TA c nf TC P -D A TA in d

COSEM Server Application Process TCP Connection Manager

TC P -D IS C O N N E C T re q/ c nf in d/ r es TC P -C O N N E C T re q/ c nf i nd /.r es

I P Lower layers: Data link and Ph ysi cal

DLMS/COSEM TCP-based Transport Layer

DLMS/COSEM Server Application Layer

TC P -D A TA c nf TC P -D A TA in d TC P -A B O R T in d

Local_TCP_Port, 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 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

Local_TCP_Port, Remote_TCP_Port,

Local_IP_Address, Remote_IP_Address, Result

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 capability to reject a connection request.

This primitive is the service confirm primitive for the connection establishment service.

Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Result,

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 this TCP connection.

The Result parameter signifies the establishment status of a requested TCP connection Typically, this service primitive stems from a remote confirmation, and since a TCP connection request cannot be denied, the Result parameter will always reflect 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 produced by the DLMS/COSEM TCP-based Transport Layer to inform the TCP connection manager about the outcome of a previously received TCP-CONNECT.request service invocation.

The TCP-DISCONNECT service

This primitive is the service request primitive for the connection termination service

The service parameters identify the TCP connection that needs to be released, including the Local_TCP_Port and Local_IP_Address, which specify the local TCP port and IP address of the requesting device and application Additionally, the Remote_IP_Address and Remote_TCP_Port parameters 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

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

Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Result

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 indicates that the service user TCP connection manager process has accepted to disconnect the TCP connection referenced The value of this parameter is always SUCCESS.

The TCP-DISCONNECT.response primitive is used by the TCP connection manager process to confirm the acceptance of a previously requested TCP disconnection to the DLMS/COSEM TCP-based TL It is important to note that the TCP connection manager process does not have the ability to reject the disconnection request This service primitive is only invoked in response to a TCP-DISCONNECT.indication service that indicates a disconnection request initiated remotely.

This primitive is the service confirm primitive for the connection termination service

Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Result,

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 denote 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 call.

The TCP-ABORT service

This primitive is the service indication primitive for the connection termination service

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 Use

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 will terminate all Active Associations established through the TCP connection and notify the COSEM Application Protocol using the COSEM-ABORT.indication service primitive, as referenced 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

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 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 will receive the data.

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 prompts the wrapper sublayer to pre-fix the wrapper-specific fields (Local_wPort, Remote_wPort, and Data_Length) to the received xDLMS APDU Subsequently, it invokes the SEND() function of the TCP sublayer with the correctly formatted WPDU as DATA The TCP sublayer then transmits 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

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

Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, Remote_IP_Address, Confirmation_Type, Result

The parameters Local_wPort, Remote_wPort, Local_TCP_Port, Remote_TCP_Port, Local_IP_Address, and Remote_IP_Address hold identical values to those in the confirmed TCP-DATA.request service.

The Confirmation_Type parameter indicates whether the confirmation service is a LOCAL or a REMOTE confirmation

The Result parameter reflects the outcome of the preceding TCP-DATA.request service, with possible values of OK or NOK, which are defined by the implementation of the confirm primitive as outlined in section 6.3.5.4.

The TCP-DATA.confirm primitive is an optional feature that, when implemented, is produced by the DLMS/COSEM Transport Layer (TL) to confirm the outcome of the preceding request primitive to the service user, DLMS/COSEM Application Layer (AL).

Protocol specification for the DLMS/COSEM TCP-based transport layer

General

The DLMS/COSEM CO, TCP-based TL incorporates the standard TCP layer as defined in STD 0007, along with a specific wrapper sublayer tailored for DLMS/COSEM, as illustrated in Figure 2.

In TCP-based transport layers, the wrapper sublayer is more intricate compared to its UDP-based counterpart Its primary function, like that of the UDP-based transport layer, is to facilitate the identification of source and destination DLMS/COSEM Application Entities (AEs) through wPort numbers Additionally, it converts OSI-style TCP-DATA service primitives to the SEND() and RECEIVE() interface functions defined by standard TCP Furthermore, the TCP-based wrapper sublayer assists DLMS/COSEM Application Layer (AL) service users in exchanging complete Application Protocol Data Units (APDUs).

TCP is a streaming protocol that does not maintain data boundaries, which means that the SEND() and RECEIVE() function calls may succeed even if the actual bytes sent or received are fewer than requested It is the wrapper sublayer's responsibility to track the amount of data sent and received, ensuring that the complete APDU is transmitted by repeating the operation as necessary.

The wrapper sublayer in the TCP-based DLMS/COSEM transport layer is not a stateless entity; it actively performs track-keeping and implements a retry procedure to ensure reliable communication.

“streaming” nature of the TCP transparent to the service user DLMS/COSEM AL.

The wrapper protocol data unit (WPDU)

The wrapper protocol data unit is as it is specified in 5.3.2.

The DLMS/COSEM TCP-based transport layer protocol data unit

WPDUs are transmitted in one or more TCP packets The TCP Packet is specified in STD

The TCP packet contains only a portion of the WPDU in its Data Field, as illustrated in Figure 7 This partial inclusion is due to the inherent "streaming" nature of TCP.

Source TCP Port Destination TCP Port

Sequence Number Acknowledgement Number Data

Data (part of the WPDU)

…Data (part of the WPDU)…

Figure 7 – The TCP packet format

The DLMS/COSEM TCP-based TL PDU appears as a standard TCP packet from an external perspective, with all DLMS/COSEM specific components, including the wrapper-specific header, contained within the packet's Data field.

The source and destination TCP ports can represent either local or remote ports, depending on the data transfer direction From the sender's perspective, the source TCP port in a TCP packet is the Local_TCP_port, while from the receiver's viewpoint, the source TCP port of a datagram corresponds to the Remote_TCP_Port service parameter.

Reserved wrapper port numbers

Reserved wPort Numbers are specified in Table 1

Definition of the procedures

The initiation of a TCP connection begins with the invocation of the TCP-CONNECT.request service This service, like all DLMS/COSEM TL services, is offered to the service user entity by the wrapper sublayer However, the actual TCP connection is established between the local and remote TCP sublayers The wrapper's role in this process is to convert the TCP-CONNECT service primitives—such as request, indication, response, and confirm—into corresponding TCP function calls.

From the perspective of the service user, only the TCP-CONNECT service primitives are observable, indicating that the establishment of a TCP connection occurs as illustrated in Figure 8.

The establishment of a TCP connection relies on a three-way handshake mechanism, as outlined in STD 0007 This process involves three message exchanges, ensuring that both parties are prepared to transmit data and that their initial sequence numbers are synchronized.

In a TCP connection, both the client and server can initiate the connection, with one acting as the initiator and the other as the responder to establish the link.

To effectively respond to incoming connection requests, a responder must initiate a 'passive' opening by notifying the local operating system (OS) of its readiness This process involves the OS assigning a TCP port number to the connection endpoint and reserving the necessary resources for future connections, although no outgoing message is transmitted at this stage.

In the DLMS/COSEM Transport layer, the implementation requires the operating system to allocate the specified TCP/UDP port number to the local endpoint of the connection.

In the DLMS/COSEM TCP-based transport layer, the wrapper sublayer autonomously initiates a passive opening during system initialization This means that the responsibility for the passive opening lies solely with the wrapper sublayer, and no external service is required to trigger this process.

During system initialization, both the client and server side TCP connection managers act as "Responder" applications, allowing the TLS on each side to perform a passive opening.

More details about TCP connection establishment are provided in Clause A.1

The TCP is disconnected using the TCP-DISCONNECT service, as shown in Figure 9

The TCP disconnection process can be initiated by either the client or the server-side TCP connection manager through the TCP-DISCONNECT.request primitive, which is then converted by the "wrapper" into a CLOSE() function call to the TCP interface.

The TCP sends a fin segment, which is acknowledged by the peer TCP

TCP employs an enhanced 3-way handshake for connection termination, effectively addressing issues of potential duplication and delays caused by the unreliable IP layer For further details on this process, refer to STD 0007.

The TCP-DISCONNECT.indication primitive is generated by the wrapper to notify the TCP connection manager that the connection is closing In response, the connection manager sends a TCP-DISCONNECT.response primitive to gracefully release the connection The TCP wrapper then invokes the CLOSE function, prompting the TCP to transmit its FIN segment Concurrently, the TCP wrapper informs the DLMS/COSEM Application Layer Management Service (AL) of the connection closure using the TCP-ABORT.indication primitive.

When a TCP connection is terminated, the requesting side sends an acknowledgement, which prompts the peer to delete the connection Concurrently, the wrapper generates the TCP-DISCONNECT.confirm primitive to notify the connection manager process of the accepted disconnection request Additionally, the TCP disconnection is communicated to the DLMS/COSEM Application Layer using the COSEM-ABORT.indication primitive For further information on TCP disconnection, refer to Clause A.2.

The DLMS/COSEM TCP-based TL signals the disruption or disconnection of the TCP connection to the DLMS/COSEM AL through the TCP-ABORT.indication primitive This is the sole TCP connection management service available for the DLMS/COSEM AL.

The service is triggered when the TCP connection is either gracefully disconnected by the TCP connection manager or when an unsolicited disconnection occurs, such as when the TCP sublayer identifies a non-resolvable error or the physical connection is terminated.

The purpose of this service is to inform the DLMS/COSEM AL about the disruption of the TCP connection, so that it could release all existing AAs

6.3.5.4 Data transfer using the TCP-DATA service

Once a TCP connection is established, it enables reliable data transfer, a process that involves complex mechanisms like Positive Acknowledgement with Retransmission (PAR) and flow control through sliding windows, as outlined in STD 0007 However, the DLMS/COSEM TCP-based TL layer focuses solely on providing the TCP-DATA service for data transfer, as illustrated in Figure 1.

The use of the TCP-DATA service is the same both on the client and at the server side

Figure 1 0 – Data transfer using the DLMS/COSEM TCP-based transport layer

Transport layer and TCP connection establishment

As specified in STD 0007, a TCP connection is established by calling the OPEN function This function can be called in active or passive manner

According to the TCP connection state diagram (see Figure A.1 ) a passive OPEN takes the caller device to the LISTEN state, waiting for a connection request from any remote TCP and port

Figure A.1 – TCP connection state diagram

An active OPEN call makes the TCP to establish the connection to a remote TCP

The TCP connection is established through a process known as the "Three-way handshake." This procedure begins when one TCP initiates an active OPEN, which is then responded to by another TCP that has already performed a passive OPEN and is in the LISTEN state.

The message sequence and the state transitions corresponding to that message exchange for this “three-way handshake” procedure are shown in Figure A.2

LAST ACK begin anything / reset activ e O PEN / sy n SEND / sy n syn / ack

CLOSE passive OPEN syn / s yn + a ck reset ack syn + ac k / a ck fin / ack

CLOSE / timeout / reset ack / timeout after 2 segment lifetimes ack /

CLO SE / fi n CLOSE/ fin fin / ack ack / fin / ack fin-ack / ack

NOTE In the case of the DLMS/COSEM transport layer, the TCP user protocol layer is the wrapper sublayer

Figure A.2 – MSC and state transitions for establishing a transport layer and TCP connection

This process, consisting of three messages, establishes the TCP connection and

The synchronization of initial sequence numbers on both sides ensures that each party is prepared to transmit data and is aware of the other's readiness This mechanism is effectively designed to function even when two TCP connections initiate the synchronization process simultaneously.

Sequence numbers are essential components of TCP packets, playing a crucial role in ensuring reliable data transfer For additional information on sequence numbers and other TCP-related topics, please consult STD 0007.

Closing a transport layer and a TCP connection

Closing a TCP connection is done by calling the CLOSE function, generally when there is no more data to be sent

Upon the invocation of the TCP-DISCONNECT.request service primitive by the TCP connection manager process, the wrapper sublayer invokes the CLOSE function of the TCP sublayer

The TCP connection operates in full duplex mode, allowing the other side to continue sending data even after the CLOSE function is invoked Consequently, the TCP-based transport can still receive data and forward it to the DLMS/COSEM Application Layer until it is notified that the other side has also closed the connection Once this notification is received, the system generates the COSEM-ABORT.indication primitive, leading to the release of all Application Associations (AAs).

The message sequence chart and the state transitions corresponding to a successful TCP connection release are shown in Figure A.3

TCP is in LISTEN state

TCP is in SYN SENT state syn syn + ack

TCP is in ESTABLISHED state

TCP is in SYN RECVD state ack

No TCP Connection is established ( both TCPs are in CLOSED state )

LAST ACK begin anything / reset activ e O PEN / sy n SEND / syn syn / ack

NOTE In the case of the DLMS/COSEM TL, the TCP user protocol layer is the wrapper sublayer

Figure A.3 – MSC and state transitions for closing a transport layer and TCP connection

TCP connection abort

STD 0007 lacks a defined standard function for signaling an unexpected abort at the TCP level Nevertheless, TCP user entities can identify such occurrences by utilizing the STATUS() function to poll the TCP status, as illustrated in Figure A.4.

Figure A.4 – Polling the TCP sublayer for TCP abort indication

TCP is in CLOSE WAIT state

TCP is in FIN WAIT-1 state fin fin

TCP is in TIME WAIT state ack

TCP is in ESTABLISHED state ack CLOSE

TCP is in FIN WAIT-2 state

TCP is in LAST ACK state

TCP is in CLOSED state

TCP is in CLOSED state signal received fin

No TCP Connection is established

LAST ACK begin anything / reset activ e O PEN / sy n SEND / syn syn / ack

Data transfer using the TCP-DATA service

To send an APDU to a peer, the DLMS/COSEM Application Layer (AL) utilizes the TCP-DATA.request primitive of the DLMS/COSEM TCP-based Transport Layer (TL) Upon receiving a complete APDU, the DLMS/COSEM AL is notified through the TCP-DATA.indication primitive, allowing the AL to perceive the TL as if it transports the entire APDU seamlessly.

TCP is a streaming protocol that does not maintain data boundaries, which means an Application Protocol Data Unit (APDU) may not be transmitted in a single TCP packet To address this, the wrapper sublayer in the DLMS/COSEM TCP-based Transport Layer is responsible for concealing the streaming characteristics of the TCP sublayer.

The wrapper sublayer effectively facilitates the transmission of data by allowing an AL entity to send an APDU of 992 bytes through the DLMS/COSEM TCP-based transport layer.

NOTE Both the client and server side ALs can be either sender or receiver

It invokes the TCP-DATA.request service with this APDU as the DATA service parameter as shown in Figure A.5

Figure A.5 – Sending an APDU in three TCP packets

Upon receiving the service invocation, the wrapper sublayer creates the WPDU by adding a wrapper header (WH) that includes the local and remote wPort numbers along with the APDU length It then invokes the SEND() function of the TCP sublayer to transmit the WPDU, which has a total length of 1,000 bytes, consisting of 8 bytes for the wrapper header.

The SEND() function returns the number of bytes sent or a negative value indicating an error Assuming no errors occur, the SEND() function successfully returns a positive value.

476 This number is the number of bytes sent This also illustrates the meaning of the

The "streaming" nature of TCP allows the SEND() function to return successfully even if fewer bytes are sent than requested This return value indicates to the wrapper that the entire WPDU has not been transmitted Consequently, the wrapper invokes the SEND() function again with the remaining portion of the WPDU, continuing this process until the complete WPDU is successfully sent.

As already mentioned in 6.3.5.4, depending on the implementation, the successful return of the SEND() function may even not mean that something has been really sent to the network

The protocol implementation may simply buffer the data, potentially delaying transmission to adhere to protocol conventions or manage network traffic algorithms.

The wrapper sublayer is responsible for assembling the complete APDU before calling the TCP-DATA.indication primitive, utilizing the length bytes from the WPDU header It continues to make RECEIVE() calls until the total number of bytes specified in the WPDU header is received, as illustrated in Figure A.6.

The asynchronous nature of the RECEIVE() function in TCP communications allows the receiver to call it even while a TCP packet is still being received or when no characters have been received since the last call This does not result in erroneous reception; rather, it simply increases the number of RECEIVE() calls needed to obtain the complete message.

It is important to note that a single SEND() call may result in multiple TCP packets being sent However, this does not cause any issues with message reception, as the receiver will eventually receive the entire message.

Figure A.6 – Receiving the message in several packets

The SEND() and RECEIVE() calls are exclusively internal to the DLMS/COSEM Transport Layer (TL) The DLMS/COSEM Application Layer (AL) utilizes TCP-DATA services, ensuring reliable data transfer while maintaining the integrity of the Application Protocol Data Units (APDUs).

COSEM transport layer, state machine, 1 6

COSEM transport layer, TCP based, protocol specification, 26 COSEM transport layer, UDP based, 1 0

COSEM transport layer, UDP based, protocol specification, 1 4 Data length, 1 0, 1 5

DLMS/COSEM transport layer, TCP based,

DLMS/COSEM transport layer, TCP based, 1 6 service specification, 1 7 DLMS/COSEM transport layer, UDP based, service specification, 1 1 Error detection, 1 7 fin segment, 29

Multi- and broadcasting using UDP, 1 3

Source UDP, 1 6 Source wPort, 1 5 TCP Connected, 30 TCP connection, 27 TCP connection abort, 29, 34 TCP connection closing, 1 7, 33 TCP connection establishment, 1 7, 32 TCP connection manager process, 1 0, 1 8 TCP data communication, 1 7

TCP disconnection, 28 TCP packets, 27 TCP-ABORT service, 23 TCP-ABORT.indication, 23 TCP-CONNECT, 1 8

The Transmission Control Protocol (TCP) is essential for establishing reliable connections in network communications Key components include the TCP-CONNECT, which involves confirmation, indication, request, and response processes Additionally, TCP-DATA services facilitate data transmission, with corresponding confirm, indication, and request functions The TCP-DISCONNECT services manage the termination of connections, ensuring proper confirmation and response A critical aspect of TCP is the three-way handshake, which establishes a secure connection before data transfer begins In contrast, UDP datagrams offer a simpler, connectionless alternative for data transmission.

UDP-DATA service, 1 1 UDP-DATA.confirm, 1 4 UDP-DATA.indication, 1 3 UDP-DATA.request, 1 2 User Datagram Protocol, 7, 1 0 Valid wPort numbers, 1 3, 25 Virtual circuit, 1 6

Wrapper, 9 Wrapper header, 1 4 Wrapper protocol data unit, 1 4, 26 Wrapper sublayer, 9, 1 4, 26 Wrapper sublayer, state transition diagram,

RFC 0768, User Datagram Protocol (Also: IETF STD0006) August 1 980 Available from: http://www.ietf.org/rfc/rfc768.txt

RFC 0791 , Internet Protocol (Also: IETF STD 0005) Edited by J Postel, September 1 981 Available from http://www.ietf.org/rfc/rfc791 txt

RFC 0792, Internet Control Message Protocol (Also: IETF STD 0005), Edited by J Postel, September 1 981 Available from http://www.ietf.org/rfc/rfc792.txt

RFC 0793, Transmission Control Protocol (Also: IETF STD 0005) Edited by J Postel, September 1 981 Available from http://www.ietf.org/rfc/rfc793.txt

RFC 091 9, Broadcasting Internet Datagrams (Also: IETF STD 0005) Edited by J Mogul, October 1 984 Available from http://www.ietf.org/rfc/rfc91 9.txt

RFC 0922, Broadcasting Internet datagrams in the presence of subnets (Also: IETF STD

0005) Edited by J Mogul, October 1 984 Available from http://www.ietf.org/rfc/rfc922.txt

RFC 0950, Internet Standard Subnetting Procedure (Also: IETF STD 0005) Edited by J Mogul, J Postel August 1 985 Available from http://www.ietf.org/rfc/rfc950.txt

RFC 1 1 1 2, Host extensions for IP multicasting (Also: IETF STD 0005) Edited by S Deering August 1 989 Available from http://www.ietf.org/rfc/rfc1 1 1 2.txt

RFC 2460, Internet Protocol, Version 6 (IPv6) Specification Edited by S Deering and R Hinden December 1 998 Available from: http://www.ietf.org/rfc/rfc2460.txt

RFC 351 3, Internet Protocol Version 6 (IPv6) Addressing Architecture Edited by R Hinden S Deering, April 2003 Available from: http://www.ietf.org/rfc/rfc351 3.txt

3 Termes, définitions et abréviations 46 3.1 Termes et définitions 46 3.2 Abréviations 46

5 Couche transport DLMS/COSEM sans connexion basée sur UDP 50 5.1 Généralités 50 5.2 Spécification de service pour la couche transport DLMS/COSEM basée sur

The article discusses the User Datagram Protocol (UDP) and its specifications, including general information and services related to UDP-DATA It details the protocol specification for the DLMS/COSEM transport layer based on UDP, covering general aspects, the protocol data unit of the envelope (WPDU), and the transport layer protocol data unit for DLMS/COSEM over UDP Additionally, it addresses reserved envelope port numbers (wPorts) and includes a protocol state diagram.

6 Couche transport DLMS/COSEM, orientée connexion, basée sur TCP 57 6.1 Généralités 57 6.2 Spécification de service pour la couche transport DLMS/COSEM basée sur

The article discusses the Transmission Control Protocol (TCP) and its various services, including TCP-CONNECT, TCP-DISCONNECT, TCP-ABORT, and TCP-DATA It outlines the specifications for the DLMS/COSEM transport layer protocol based on TCP, detailing general information, the protocol data unit of the envelope (WPDU), and the transport layer data unit Additionally, it covers reserved port numbers and the definition of procedures related to TCP An informative annex provides guidance on converting OSI model transport layer services to and from TCP function calls, including establishing and closing transport layer connections, abandoning TCP connections, and transferring data using the TCP-DATA service The article concludes with an index and bibliography for further reference.

DLMS/COSEM serves as a standard Internet application protocol, facilitating efficient communication in smart metering systems The transport layers of the DLMS/COSEM_on_IP profile enhance data transmission, ensuring reliable connectivity Additionally, the connectionless transport services of DLMS/COSEM provide flexibility and efficiency in data handling, optimizing performance in various applications.

Tiêu đề	IEC 62056-4-7:2015 - DLMS/COSEM Transport Layer for IP Networks
Trường học	Unknown
Chuyên ngành	Electrical Engineering
Thể loại	Standards Document
Năm xuất bản	2015
Thành phố	Geneva

Định dạng
Số trang	84
Dung lượng	2,47 MB