public static IntPtr EncodeHDLCrequest(byte addressSize,

ushort clntID,
ushort serverID,
ushort devAddr,
byte windowRx,
byte windowTx,
ushort infoFieldLenRx,
ushort infoFieldLenTx,
byte serviceClass,
ushort linkBufSz,
ENCODED_AXDR apduData,
byte frameType,
byte[] rrr,
byte[] sss)
Return Type
IntPtr : IntPtr.zero or valid pointer. If valid pointer, it can be converted to
ENCODED_PRIMARY_APDU structure. The structure includes the number of blocks available in the
structure. Only I-frame type expects more than 1 block. The structure also include individual blocks
data with length field. If the “application layer packet size” + “LLC header” length is more than the
HDLC information size sent, the function shall encode the information in multiple blocks.
Arguments

Slno Argument Description

1 addressSize Number of bytes used for addressing the server. Possible values
are 1, 2 or 4. When a value of 1 is specified, the destination
address (server-address) contains only 1 byte which contains the
Upper HDLC address of the meter. This can be used for point-
to-point communication. In case of a multi-drop scenario (daisy
chained meters), the address must also specify the lower HDLC
or device-address to identify which physical device is being
addressed. This can use a 2-byte or a 4-byte destination address.
In case of a 2-byte address, the server address has 1-byte Upper
HDLC address and 1-byte Lower HDLC address. In case of 4-
byte addressing, the server-address contains 2-bytes Upper and
2- bytes Lower HDLC addresses. Example: 1
2 clntID Client id for current association. This is the ID of DLMS client.
The client-ID is used by the server to determine which
association in the addressed Logical-device is to be activated. A
value of 16 (0x10) is predefined by the DLMS standard to
specify a Public Access client. Any DLMS server must
provide at least one Public-Access association. Other Client IDs
supported shall be obtained from meter manufacturer or from
respective project/companion specification. Example: 16
3 serverID Upper HDLC address of the server. This identifies which
Logical-device in the addressed-meter is being queried. Any
DLMS server will provide at least one Logical device with an
address of 1, which indicates the Management Logical device
Example: 1
4 devAddr Lower HDLC address of the server. This is the physical-device
address of the meter. Please note that a physical device can
contain multiple logical devices identified by unique
Upper HDLC addresses In turn, each Logical device can support
multiple associations (with different object lists and access-
rights) defined by unique client-IDs Example : 0
5 windowRx Number of windows receive. This identifies the number of
segmented frames that can be received at a go by this client,
before requiring to send a RR (Request-Ready)
handshake. The DLMS default value is 1. Example: 1
6 windowTx Number of windows transmit. This identifies the number of
segmented frames that can be transmitted at a go by this client,
before requiring a RR (Request-Ready) handshake from the
server. The DLMS default value is 1. Example: 1
7 infoFieldLenRx Information field length receive. This defines the size of the
Info-field part of a received DLMS frame. The info-field is the
carrier of all COSEM data destined to be processed by the upper
Layers. The DLMS default value is 128. Example: 128
8 infoFieldLenTx Information field length transmit. This defines the size of the
Info-field part of a transmitted DLMS frame. The info-field is
the carrier of all COSEM data destined to be processed by the
upper Layers. The DLMS default value is 128. Example: 128
9 serviceClass Shall set 1 for I frame.

10 linkBufSz HDLC/ IP wrapper buffer size. This is the maximum number of

bytes which needs to be buffered in link layer for both
transmission as well as reception. User should set this value
judiciously depending on server's Maximum APDU/block size
transmit/receive. A recommended value can be Maximum
Transmit/Receive APDU size(in case of HDLC HDLC protocol
overhead 17 bytes also shall be added to APDU size to calculate
LinkBufSize). Example: 1024
11 apduData Application layer data along with LLC header shall pass here.
This argument is only applicable to I-frame. Application layer
frame (AARQ, Get Request, Set Request, Action request, ..etc)
with LLC header (0xE6, 0xE6, 0x00) shall pass here along with
number pf bytes.
Ex: E6 E6 00 C0 01 C1 00 08 00 00 01 00 00 FF 02 00, Length
=16.
12 frameType Type of frame to encode. Supported values are.
0: I Frame (AARQ, Get, Set, Action requests)
1: RR Frame
2: SNRM frame
3: DISC frame
13 rrr N( R ), Receive sequence number

14 sss N( S ), Send sequence number

public static IntPtr DecodeHDLCrequest(ENCODED_PRIMARY_APDU apduData,

byte addressSize,
ushort clntID,
ushort serverID,
ushort devAddr,
byte windowRx,
byte windowTx,
ushort infoFieldLenRx,
ushort infoFieldLenTx,
uint cosemBufSize,
byte[] rrr,
byte[] sss)
Return Type
IntPtr : IntPtr.zero or valid pointer. If valid pointer, it can be converted to
ENCODED_PRIMARY_APDU structure. The structure shall tell you the number of blocks available
in the structure. Only 1 block expected on return. The structure also include individual blocks with
length field. Data in the buffer on index 0 indicate type of frame. 1- RR frame, 2- I Frame, 3- UA
frame, 4 – Partial I frame.
In case of complete I-frame segments, full application layer data shall return with LLC header. 1 st byte
shall be 2, indicate I frame. Followed by LLC header and application layer data.
Eg: 02 E6 E7 00 C4 01 C1 00 0F 01, Length = 10.
In case of partial I frame, buffer shall return the type as 4 followed by receive and sent sequence
numbers.
Eg: 04 00 00
In case of UA frame, buffer shall return the type as 3 followed by negotiated information size send (2
bytes), negotiated information size receive (2 byte), Negotiated window size receive (1 byte),
Negotiated window size sent (1 byte)
Eg: 03 01 00 01 00 01 01
In case of RR frame, buffer shall the return type as 1 followed by receive sequence number and sent
sequence number.
Arguments

Slno Argument Description

1 apduData User have to pass the complete response PDU to decode, in this
structure. If the response in received in different HDLC
segments then full response need to be stored in "apduData"
array pointer with each element in the array pointing to different
block data in the order of sequence number. The total number of
blocks need to be stored in "blockCount" element. Partial block
input shall return partial data response.
2 addressSize Number of bytes used for addressing the server. Possible values
are 1, 2 or 4. When a value of 1 is specified, the destination
address (server-address) contains only 1 byte which contains the
Upper HDLC address of the meter. This can be used for point-
to-point communication. In case of a multi-drop scenario (daisy
chained meters), the address must also specify the lower HDLC
or device-address to identify which physical device is being
addressed. This can use a 2-byte or a 4-byte destination address.
In case of a 2-byte address, the server address has 1-byte Upper
HDLC address and 1-byte Lower HDLC address. In case of 4-
byte addressing, the server-address contains 2-bytes Upper and
2- bytes Lower HDLC addresses. Example: 1

3 clntID Client id for current association. This is the ID of DLMS client.

The client-ID is used by the server to determine which
association in the addressed Logical-device is to be activated. A
value of 16 (0x10) is predefined by the DLMS standard to
specify a Public Access client. Any DLMS server must
provide at least one Public-Access association. Other Client IDs
supported shall be obtained from meter manufacturer or from
respective project/companion specification. Example: 16
4 serverID Upper HDLC address of the server. This identifies which
Logical-device in the addressed-meter is being queried. Any
DLMS server will provide at least one Logical device with an
address of 1, which indicates the Management Logical device
Example: 1
5 devAddr Lower HDLC address of the server. This is the physical-device
address of the meter. Please note that a physical device can
 contain multiple logical devices identified by unique
Upper HDLC addresses In turn, each Logical device can support
multiple associations (with different object lists and access-
rights) defined by unique client-IDs Example : 0
6 windowRx Number of windows receive. This identifies the number of
segmented frames that can be received at a go by this client,
before requiring to send a RR (Request-Ready)
handshake. The DLMS default value is 1. Example: 1
7 windowTx Number of windows transmit. This identifies the number of
segmented frames that can be transmitted at a go by this client,
before requiring a RR (Request-Ready) handshake from the
server. The DLMS default value is 1. Example: 1
8 infoFieldLenRx Information field length receive. This defines the size of the
Info-field part of a received DLMS frame. The info-field is the
carrier of all COSEM data destined to be processed by the upper
Layers. The DLMS default value is 128. Example: 128
9 infoFieldLenTx Information field length transmit. This defines the size of the
Info-field part of a transmitted DLMS frame. The info-field is
the carrier of all COSEM data destined to be processed by the
upper Layers. The DLMS default value is 128. Example: 128
10 serviceClass Shall set 1 for I frame.

11 cosemBufSize Application size buffer size. This is the maximum number of

bytes which needs to be buffered in application layer for both
transmission as well as reception. User should set this value
judiciously depending on server's Maximum APDU. A
recommended value can be Maximum Transmit/Receive APDU
size. Example: 1024
12 rrr N( R ), Receive sequence number

13 sss N( S ), Send sequence number

Call Sequence
1. EncodeHDLCrequest() to generate SNRM
2. DecodeHDLCrequest() to decode UA frame. Return NULL for DM frame.
3. EncodeHDLCrequest() to encode AARQ request.
4. DecodeHDLCrequest() to decode AARE response and extract application layer frame + LLC
Header. Remove 1st 4 byte and decode application layer frame. This step may repeat if the
packet received with segmentation
5. EncodeHDLCrequest() to encode Get request.
6. DecodeHDLCrequest() to decode Get response and extract application layer frame + LLC
Header. Remove 1st 4 byte and decode application layer frame. This step may repeat if the
packet received with segmentation.
7. EncodeHDLCrequest() to sent DISC frame.
8. DecodeHDLCrequest() to decode UA response. Return NULL for DM frame.