Green Book 7ed

OILY'S _3E' ASS3CiatiCAL C.OSEM Archilisokre.airodi Protocols.
Sererpth Ecitiari
9. COSEM application layer
9+1 Overview
9.1.1 COSEM application layer structure
The stnuclure of the client anO server COSEM appLication layers is Shown in Figure ea
COSEM client COSEM serer

App li=t PirePt.eSS. AppriCaDOE) PrOCE=S•S
COSEAlcimaf A. srvires
• COMM 0,11010 1154 PIrmied4"
FilegurrPoinv tit
aillifriW4:130 ILWO:0 91wr i Mow
00:SElleserver aw,icatorr tror
60SE la GOWN 1L56
_• •_
•
Sane! corrtrol n.nctran
Slow
:-; ACSE
d
RICIPPAIng reiw inewor•
5:10W 'Y MTN $41EFIM Arm"

.a•Er ffeAl
Wier Foamed Ws*. DITper Od ors
IRMI LAN
•
r•ue 601 - The 301.4:13.te 01 Pe COSEPA ACIPFCARIrk layreft

The main oomporient of the COSEM AL is the COSEM Application Service Object It orevides
services to its WAee user_ the COSDA Appkaken NOCAM. arid oSeS $eevices paivitled the. supporing
ewes layer- II 11)11filattilifiree irrlaindatOry COrnpOrkentS both on the client end on the server side:
▪ tie at Control Serwce Elerneril• ACSE;
■ the extended MIAS Application Se-ohm Element, RDLIVIS_ASE:.
• the Control Function, CF.
On the olieril side, there is a fOUrth, optional element, called the SN.-MAPPER ASE.
The task of ACSE rs to estatihsh_ maintain_ arid release application associations. For Ili purposes
of DIMS•COSEIA connection oriented '(CO} communication profiles. the Co ACSE. Wecified in
ISOplEC 116451 and 1SOilEC 8650-1 is used_
The task of the xVIIIIS_ASE i5 to provide data transler s er CcS between COSEM API. It is based on
the. DAIS standard, ilEC 61 3.4-4-11.1. It has been extent liket lot DILM&ICOSEM: see 9_1.2_3_1. Trhfr
main objective of 111_141S+COSEM is to provide a titisthess domain oriented interlace object model for
metering devices and systems while keeping backward compatibility th the DIMS standard. To meet
these objectives, IEPLILMOSEIA FnctvcreS evolvtion of DL_Ful5. Remaining. Wily •omplianl lu the
DIMS standard. OILMS;COSEM provides a more metering specific view of the meter through the
CCISEPA inter lace objects_
DIMS UA 1000-1 Clause I specifies two referencing metes to attributes and methods of COSEM
interlace titijecIS Itar use in QCISELI serer t$: IN and SN reigrenCing. 'TherefOre,. an the ..er -kter side,
two distinct xEPLIMS service sells are specified: one eiclusivety for IN relerencing and the other
exthisivoly l SN roferoirliting_ II can be considered Mal there are timio dirlerervt •i[DIFAS_ASEs.: coo
providing services. for IN referencing and the other for SN referencing The server AL may incrude
one. the Mho or both xlIDAS_AS.Es_
131-11$ User fia5ocia1fon 2009-t2-22 I DIMS UA 1000-2 Ed_ 7.0 I

e comfthE1297-zeogDuas MI( ASSCICLan•Xl
DLMS Llsei. Assooa.-.ion, COSEM Archileclura and Firatocc1s. Seventh Edition
The O F plernenl specifier how the A$0 services invoke the apprDpria'.e service primitives Df the
AC SE, the xDLIMS_ASE and the services of the supporting layer.
NOTE elipth 'hi clignii and 1110 scrryqr CQSEIYI ASO rnlY gthqr. cWi¢n3l Qpplicaliqn prgliOccil c4mpPri4nl$.
The colional SN _MAPPER ASE i$ present in the client side AL A$1:1, when the server uses SN
referencing. It prowides mapping loelwoon services using IN and SN referencing. See also 9.3.17'.
The LOSE All AL Fierlorms also some iunctions e1

he 051 presentation layer:
• AP1:111,)5 in BER
RnOCeding 1111.13 ACSE
• encoding 11-he xDLMS APDIJs carrying the data transi'er services in A-XDR {I EC 61334-6).
9.1.2 COSEIVI application layer services

9.1.2i ASO services
The services required by. or prOVilial or the oosEm client and server APs at the logical inlerfa.ces
with the respeclive 00$0.1 AL, using CO PrOcedures, fall into three calegories:
• Ppplication asscdiation establishment arKI release;

- data translef;
• layer management,
9.1.2.2 Services provJcJed for appl I cation a.ssociation esla.blialunent and release
The services provided lor Ihe establishrnwt and 'cleric of AM. are the lollowing:
• COSElidl-OPN:
• COSEP.I-RELEASE;
• CCISELI - ABORT.
The COSEIVI OPEN service is used to establish AAs. 11. is based on the ACSE A ASSOCIATE
- -
service. 11 causes the shit DI use DI an AA by those ASE procedures identified by 1he va lue of the
Application_Context_. Name, Security_fylechanIsm_Na.me and •x117ILIAS context parameters. AAs may
be established in dna rent wayS:
• COnfirmed AAS 9.1e established via a messa;ka exchange - 1.15ing 1he COSEM -OPEll Service - between
the client and the server to negotiate the contexts. Confirmed Ms can be established between a single
client and a single server;
• Unconfirmed AAs are established via a message sent using The COSEM-OPEN aentice - torn the
-
client 10 the sewer. using the parameters M Ina contexts supposed 10 be used by IF server.
Uncerifirmed AAs can be established between a client and one per multiple servers;
• pie-established AAs may pre-exist, In this case, the COSEM-OFEN service is not used. A pre-
established AA can be confirmed or unconlirmed.
The COSEM-F1ELEA6E service is .LISKI to release AAs. If wocessful, ii causes the completion cf
the use of the AA without loss of intormation in transit (graceful release). In some communication
profiles - for example in the TOP-UDRAP based profile - the COSELI-RELEASE serwice is based
on the ACSE A.RELEASE SINTVieft. In some other communication prof des - for exampha in lho 3•
layer, CO, 1-11;11.C-based profile - there is a one-to-ins relalionship between a c.arlfirrriecl AA and the
supporting protocol layer connection. Therefore, AAs can be released simply . 14 disconnecting tne
corresponding supporling toyer connection. Pre - established AAs cannot be teleased.
The COSEM ABORT service causes the abnormal release of an AA with the possible loss of
-
in1ormation in 1ransi1. It does nol rely on the AC.S. A ABOFIT service. -
The COSEM-OPEN service is specified in 9.3.2, the COSEPI-RELEASE service in 9.3.3 and the
COSEIVI-ABORT MorViCB in 9.3.4.
DLMS User Associalion 2.0139-1. 2-22 DLMS UA 1000-2 Ed. 7.0 114;.310.
COM1VE 1907.2131:9 DLLIS User X-Dri
DLNIS User Assccialion, COSEM Architecture and Proioacds,. Gewen1h
9.1.2.3 Services provided for data transfer

9.1.2.3.1 The xDL MS application service element
As mentioned in 9.1.1, xDLMS includes some extensions lo the DLMS standard, IEC. 6134-4-41.
Those c xl.anstons delpno aria atl- lunctionality: existing funchoria.illy is riot modified. They WO made in
such a way, that there i3 n0 COniligll with the ex iatinq DLMS standard and 01:1mprise the* 1Q1lewing:
• additional service;
• additional data bps*:
• new DLMS version number:.
• new corriormance block:
• clarlipcation Lhe meaning .01 Lhe POU Sire_
The additional services are OET, SET, ACTION and EventNotilication. They allow to feterence
alltibutas and methods 4)1 COSEM interlace objects using ILK referencing. See 9.1.2.3.5 and
The additional data Eyries are spindled in 9.5.
The new DLMS wersion number, corresponding la the first WfIrsion Q1 the xl:PIJAS ASE i $_
The new xCILMS conformance block enables optimised DLIMS;GOSEM server implementations with
extended lunctianality_ it can be distiniguished !tom the DL ConlarmanCe block by its lag
"Application 31". See 9.4.6.1 and 9.5.
For services using SN rels reilcirig. new ve.riarits of the Varia.bleAccess_Specification service
parameter, the Flead.respcinse and the ViIrjle_response services hove been added to support
selective access and block beef' slier_
To clarify the meaning at the maximum PDU size usable by the client and the server, the
modlifications shown In Table 12 have been made. The xaLMS-in Mate service- uses theso names for
ID DU 5.i.Ze5.
Taltie 12 — Clarification of the moaning or PEW size For DLAISCOSEM
Will: new
Page 161. Table 3 of MC 61231-1-11:

Prcipo5e-el rillaAloDU Size CI fin: Mix Pleoerve 1 5 DU 5IZ43
rtEIgGaIR100 M. PIZH_I 6 12113 .erwer Mar Flirg@hre POLL' 81ze
Naga tp3 52" paragraph of I EC I$1314.1.41:
The Prop:mond Laic PCIU Size par or !ype The spent Max Receive- PDU Size parameter, cd Iype
IlJa610r141015. propi}ses a maAinurn lanai expressed In LInEKInec115. contains ihe 'maximum Eanglthi linllaraG59-11irl bytes
dynes rat the exchanged WAS PUI)i 'Iris irelue IV a DLIYIS PIDU 'Mat the lamer raaV ssni:I. Trus cben1 will
proposed in are laltiale inequeel Imes! 13B large enough 40 discard en51 received PIRIla that are longer Man 1hle rna.lirrairri
alwavi aefrypi the Irilliate Error 4PIDU tralernission lehalh. Thit salve flint be IEVile erieugh lo alwa.rs permit the
AA.FtE AP DU 1rOn3niission.
Valves below 12 are reserued. The valued indicates Ihol the
rhgra is no limit gn the PDU size.
P sap It paragraph of 'n613344-11:

Tho KlopueliatoKI Max RDL.J$Lcw pRrarnglgr- of lypa Itio Sordwg Max Rociiivo FOU SiIiil pararricror, DI time
11.114.1pgig 1 5. Writliklas a maximum length iirIcprlit$PRO In Unirg 'led le, contains !hp maximum kingth. empresse4;1 In triebits
lay fee for the exchanged DENS N0' A PO.Lr trim Is hag 8 DLMS PDLIfirlElt the 011eirld rosy( send. The serger will
longer lhaft lino mar:imp:1 !enough will be discarded. This !Amend any received P12111. that are longer Man this maximum
rnamirnorn length le cairriputed as !he minimum e11he length
Proposed Max PDU Sue and the maximum PEILI FAZE Value's below 12 aro reserued. The value 0 indicates Mai the
thin bhe VDE•hancller may support. Munn is no krrsil on ihip 12 1:111,1 Lima.
9.1.2.3.2 Clierrtisorver and non-clientOserver typo services

xCILMS data transfer services are related lo attributes and methods of COSEM interface objects,
specified in DLMS UA 101:1U-1, and provide the interlace between the COSEM application model and
the commtmicalion protocols_
DLIVIS User Aesiodiallign 120Q9-12-22 DLIAS UA 1000-2 Ed. 7.0 simo

17; CoOpyrIfihl "i197-2CCID100. 0 8 LEFer XI-SSO:a9t11;e1
DIMS User Associate.% imp ArCIPMICL172 PrIANZOk5. Se Edition
When 1he WPM! USC5 relmencing, attributes and methods of 1;;OSEIA interface 'Meg'5 ere
mapped to DIMS PIE variables. The rnappiriri Es held by the Associat•cri SH interlace objectisli.
For accessing atEribuies and methods_ chenriserwer Ewe services are used: the citenl reque -s15
services and the server oroidides therm
There it also an unstilictIed. non - Chenbserver type service_ INS tervieei requested by the Siemer.
upon all occurrence 01 an evert, to intim the client of the value 01 one or more attributes, as
thpugh they had been reaLss'ed by the client_ It iS arF uncdrihrrned SiMibriCe_
9_1_2_3_3 ReterenO ingl rhelhed5 and SierviCe mapping

A SpeCitied in 9.1.1. [here are two se'.s available_ one lar LN and One ler SN
reiarencing
On the clieril side. in order to handle the dirleTerr - e'e . e MeIhrXIS Irarrtiparefrby 101 the AP_ the
AL provides only one service set. using LN referen4.-_ing Using a unique. standardized service sell
between COSEM client irlidPs and the communication protocol - hdrrpg the partpculasilies 01 COSEM
servers using differere referencing methods - al.kyits. to speedy an App zation Programming
Interface, API. This PS an explicitly spec'' eo interlaZze etcretibOrrelirig ServrCe Set for
application Ruiningan a green computing envifonmern rfor example 1firrnclows. umx, etcli Usin
this = public - API specification. client applications can be developed vwithout knowledge about
ciarticularilies of a given server_
On the server side, either sec' irSeg IN referencing or services using SN relereliCgrig or 1)0119
kind of services can be pre vided_
In case of cOrairrried Afrks. the referencing method and the sere set to be used Es negotiated
during 1.he AA establishmen: phase via Ehe COSE141 applicalion corrierl. see 9_4.2.2.2. and Hie
COnlOrManee bh>ck. see 9 4 .5 I It shall riot c-range during the klehrrie of the AA established. Using
LN ar SN services. wain a giver AA rs eXCiusWe.
In ease of unconfirmed and pre established AAs. the client AL - s eipecled to know the remixing
-
reel hod and the tervite set Supported by the server_
When the server use LN referencing. the seniices are both side_ When the server
does not use LN referencing. a mapping between Client S .• • ier side services takes place_
A.s explained in 9.1.1_ if the server uses SN referencing -- 6 rnagli:Img i perlormed by the Client
SN J.rAPPES ASE_ See also 9.3.17.
9_11_2..3_4 Confirmed and unconfirmed serViCeS

Wan- confirmed AAs_ clientiterver type data transfer services can be irrpOked in a confirmed or
unconfirmed manner. Within unconfirmed AA-5. Dti-ent server type data transfer services may be
invoked in an unconfirmed manner °city. See also 9_4_6_2.
9_11_2_3_5 COSEill client. server lype services

COSEM clienVserver type data transfer se leas for LN referencing are the rollowing.
• the GET service_ used EO read the Value of one ix more alITERMSOICCISE.101irledade ObjedIS_ See 9_311I
▪ the SET service_ used tow-its the value of one or more affrixnes of COSEhll iderface objects_ see 9.3.7:
• the ACTION service. used !D invoke one or more methods of COSEM. interlace olzljecM. Irrhidkkg
methods may inlcdy sercling service paia -wers and retusi-rwv data_ see 93 g
COSEM client:server type data transfer 5.enrices fof SN referencing are the Iclicoritg:
•••
the Read seneice, lased to read the value cg ore or more atInbulesor 10 irnroke one 9r rhOre rhethOth aA
COMM interlace ObreCIS *hen retuth paLarhelerS. U ry a rlMltn servo s% See 93_121
• the Write service_ used to write re value of one or rrrare attributescr lo PMPOr1.111 1:111101 rilOre MethditS. Of
CI:15CM interface objects 'when no rettrn pararreler% ere opecledII is a confirmed 5enriGe- See 93_13_
the LinconfirrheciWite senesce. used o rr4e tne wake of ore or more alinburleS of 10 "Wake Cele or rriare
methOliSo C.CrSeml Vrterface cteects. Xis all indOrii-rned servioa. See 93_14.
DLMS User Asscciaton I 2003-12-22 Dl UA 1000-2 Ed_ 7.0

Ccorerir 1 9•?--20 & 1),_145 Use. AsEecairet
1 116610
DLMS User Association, COSEM Architecture and Protocols. Seventh Edition
9.1.2.3.6 Services for event notification

To support event notification. COSEM also provides non client/server type, unsolicited services:
▪ with IN referencing the EventNotification service, see 9.3.9:

• with SN referencing, the InformationReport service, see 9.3.15.
9.1.2.3.7 Identifying service invocations the Invoke Id parameter
In the client/server model, requests are sent by the client and responses are sent by the server. The
client is allowed to send several requests before receiving the response to the previous ones.
Therefore — to be able to identify which response corresponds to each request — it is necessary to
include a reference in the request,
The Invoke Id parameter is used for this purpose. The value of this parameter is assigned by the
client so that each request carries a different Invoke_Id, The server shall copy the Invoke Id into
the corresponding response.
The EventNotification service — being a non-client/server type service — does not contain the
Invoke Id parameter.
This feature is available only with LN referencing.

9.1.2.3.8 Priority of service invocations: the Priority parameter
For data transfer services using LN referencing, two priority levels are available: normal (FALSE)
and high (TRUE). This feature allows receiving a response to a new request before the response to
a previous request is completed.
Normally, the server serves incoming service requests in the order of reception (FIFS, First In. First
Served). However, a request with the priority parameter set to HIGH is served before the previous
requests with priority NORMAL. The response carries the same priority flag as that of the
corresponding request. Managing priority is a negotiable feature; see 9.4.6.1.
NOTE 1 As service invocations are identified with an Invoke_Id, services with the same priority can be served in any
order_
NOTE 2 If the feature is not supported. requests with HIGH priority shall be served with NORMAL priority.
Th is feature is not available with services using SN referencing. The server treats the services on a
FIFS basis.
9.1.2.3.9 Selective access
In the case of some COSEM interface classes, selective access to attributes is available, meaning
that either the whole attribute. or a selected portion of it can be accessed. For this purpose, access
selectors and parameters are specified as part of the specification of the relevant attributes.
To use this possibility, attribute-related services can be invoked with these access selection
parameters_ In the case of LN referencing. this feature is called Selective access; see 9.3_6 and
9.3.7. It is a negotiable feature; see 9.4.6.1. In the case of SN referencing, this feature is called
Parameterized access: see 9.3.12. 9.3.13 and 9.3.14. It is a negotiable feature; see 9.4.6.1.
9.1.2.3.10 Multiple references

In a data transfer service invocation. if is possible to reference one or several attributes resp.
methods. Using multiple references is a negotiable feature. See 9.4.6.1,
9.1.2.3.11 Attribute . 0 referencing

With the GET and SET services, a special feature, Attribute 0 referencing is available, By
convention, attributes of COSEM interface objects are numbered from 1 to n. where Attribute_1 is
the logical name of the COSEM interface object. Attribute_0 has a special meaning: it references all
attributes with positive index (public attributes). The use of Attribute_0 referencing with the GET
service is explained in 9.3.6 and with the SET service in 9.3.7.
NOTE As specified in DLMS UA 1000.1 sub•clause 4.1.1. manufacturers may add proprietary methods and/or attributes
to any object. using negative numbers.
Attribute_0 referencing is a negotiable feature. see 9.4.6.1.
1 DLMS User Association 2009.12-22 DLMS UA 1000-2 Ed. 7.0 I

CI Copyright 1997-2009 DLMS User Association
117/310
DLMS User Association. COSEM Architecture and Protocols. Seventh Edition
9.1.2.3.12 Transferring long service parameters

The data transfer services are carried by the APOUs. exchanged between the peer ALs, in an
encoded form. In some cases, the data may be longer then the Client Server Max Receive PDU
Size negotiated. To transfer such 'tong' data. two transporting mechanisms are available:
a) long data transfer using the AL block transfer protocol. This mechanism can be used with any
confirmed client/server type services. It is a negotiable feature. see 9.4.6.1,
b) long data transfer in a transparent manner to the AL. This feature can be used when the
supporting layer(s) provide(s) segmentation: see 10.
NOTE There is no mechanism within AL block transler for re-sending or requesting a missing Of corrupt block. Such
a mechanism may or may not be a feature of Pang data transfer managed transparently by the supporting layers,
9.1.2.4 Layer management services

Layer management services have local importance only. Therefore, specification of these services
is not within the scope of this companion specification. The specific SetMapperTable service is
defined in 9.3.16.
9.1.2.5 Summary of COSEM application layer services

A summary of the services available at the top of the COSEM AL is shown in Figure 61. Layer
management services are not shown. Although the service primitives are different on the client and
server side, the APDLis are the same. The abstract syntax of the ACSE and COSEM APOUs is
specified in 9.5.
COSEM client COSEM server

application process application process
A
COS EM-ABO RT. ind
en
COSEM- RELE ASE. in d
Cr
nt
COSEM-OPEN, ind
COSEM- O PE N res
L.6
COS EM- ABO RT. ind
C E o
0 as
z eTs
L.0
C L.0 ry ti Cg
ci cc N
uJ
0)
z L.0 al
Cr) as
O NI Lu c
I- LLI
0
Application layer
Z`Z.r uest
ZZ- response
EventNotification
NOTE XX and ZZ refer to clienUserver type data transfer services. These services may be different on the client side
and the server side, if the server does not use LN relerencIng. See 9.3.1 T
Figure 61 — Summary of COSEM AL services
9.1.3 COSEM application layer protocols

The COSEM AL protocols specify the procedures for information transfer for AA control and
authentication using connection-oriented ACSE procedures, and for data transfer between COSEM
clients and servers using xDLMS procedures. Therefore. the AL protocol is based on the ACSE and
DLMS User Association 2009.12-22 DLMS LA 1000 2 Ed. 7.0 - 118.1310

rE) Copyright 1997-2009 DLMS User Association
DLMS User Association. COSEM Architecture and Prolocds. Seventh Edition
the DLMS protocols, as specified in ISO/IEC 8650-1 and in IEC 61334-4-41 — with the extensions
for DLMS/COSEM — respectively. The procedures are defined in terms of:
• the interactions between peer ACSE and xDLMS protocol machines through the use of services of the
supporting protocol layer:
• the interactions between the ACSE and xDLMS protocol machines and their service user:
• the abstract syntax of the APOUs using ASN.1 as specified in ISOlIEC 8824_
The COSEM AL protocols are specified in 9.4.
9.2 Information security in DLMS/COSEM

Acknowledgement
This clause is based on parts of MST documents. Reprinted courtesy of the National Institute of
Standards and Technology, Technology Administration, U.S. Department of Commerce. Not
copyrightable in the United States.
9.2.1 Definitions
9.2.1.1
confidentiality
preserving authorized restrictions on information access and disclosure, including means for
protecting personal privacy and proprietary information. A loss of confidentiality is the unauthorized
disclosure of information [FIPS PUB 199]
9.2.1.2
integrity
guarding against improper information modification or destruction, and includes ensuring
information non-repudiation and authenticity. A loss of integrity is the unauthorized modification or
destruction of information [PIPS PUB 199]
9.2.2 Introduction
Confidentiality and integrity are among the key requirements when open systems connect to public
media. With the increase of computational power. the requirements for strong cryptographic
methods also increase. DLMS/COSEM provides two main information security features for
accessing and transporting data:
• data access security controls access to the data held by a DLMSICOSEM server, see 9.2.3:
• data transport security allows the sending party to apply cryptographic protection to the xDLMS APDUs
sent to ensure confidentiality and integrity. This requires ciphered ADPUs. The receiving party can
remove or check this protection; see 9.2.4.
These information security features are provided partly by the COSEM AL, partly by COSEM
objects:
• upon AA establishment, two contexts are negotiated using the ACSE services: the application context
and the authentication context. The application context determines whether ciphered APDUs can be
used or not. The authentication context determines the level of data access security. The ACSE APDUs
are not cryptographically protected;
NOTE The user-information field of the ACSE APOUs may be cryptographically protected.
• once an AA is successfully established, COSEM services can be used to access attributes and methods
of COSEM objects, depending on the access rights valid in the given association. These services are
carried by xDLMS APDUs, which may be cryptographically protected: authenticated, encrypted, or both,
depending on the security policy in force. The cryptographic protection is applied, removed or checked
by the COSEM AL. The COSEM AP of the sending party informs, via service parameters, the COSEM
AL about the protection to be applied to the APDU to be sent. The COSEM AL of the receiving party
informs the COSEM AP about the protection that has been applied to the APDU received_
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 119;310

© Copyright 1997.2009 DLMS User Association
DLMS User Association., COSEM Architecture and Protocols. Seventh Edition
The message security methods described in this document have been selected from the standards
specified by KIST and the IETF.
For an overview of cryptography, see 15.
9.2.3 Data access security

9.2.3.1 Overview
Data access security concerns role based access to data in a DLMS/COSEM device.
It is managed by the Association LN / Association SN objects. Each COSEM server i.e. a logical
device may support AAs with various clients, each having a different role, and with this, different
access rights. Each AA is identified with a pair of lower layer addresses. Each Association object
provides a list of objects visible in that particular AA and the access rights to their attributes and
methods.
To be able to access data. the client must be properly authenticated. Upon AA establishment, an
authentication context is negotiated between the client and the server. This specifies the required
authentication of the peers, and, where needed. the security algorithm to verify the authentication_
Three data access security levels are provided
• Lowest level security (no security);

• Low Level Security (LLS):
• High Level Security (HLS).
9.2.3.2 Lowest level security (no security)

The purpose of lowest level security is to allow the client to retrieve some basic information. This
authentication context does not require any peer authentication: it allows direct access to the data
in the server, within the access rights available in the given AA,
9.2.3.3 Low Level Security (LLS)

The purpose of Low Level Security is to allow the authentication of clients by verifying the password
supplied_ The server is not authenticated. This authentication context is typically used when the
communication channel offers adequate security to avoid eavesdropping and message (password)
replay.
The client has to supply the correct password during the process of AA establishment. If the
password is OK, the AA is established and the client can access data within the access rights
available in the given AA. Otherwise, the AA is not established.
The LLS authentication process is supported by the COSEM-OPEN service of the COSEM AL — see
9.3.2 — and it is as follows:
• the client transmits a "secret" (for example a password) to the server, by using the
"Calling _Authentication _Value" parameter of the COSEM-OPEN request service primitive
• the server checks if the -secret" received corresponds to the client identification;
• if yes, the client is authenticated and the AA can be established. If no, the AA is rejected.
• the result with diagnostic information is sent back by the server using the COSEM-OPEN.response
service primitive.
The association objects provide a method/attribute to change the 'secret - ; see DLMS UA 1000-1
4.4.1, 4.4.2.
The authentication process with LLS is shown on the left side of Figure 62.
9.2.3.4 High Level Security (HLS)
The purpose of High Level Security is to allow mutual authentication of the client and the server
participating in an association_ This authentication context is typically used when the
communication channel offers no intrinsic security and precautions have to be taken against
eavesdroppers and against message (password) replay.
HLS requires that both the client and the server mutually authenticate each other. This is a 4-pass
process, involving the exchange of challenges during AA establishment, which is followed by
DLMS User Association 2009-12-22 I DLMS UA 1000-2 Ed. 7.0 0 120/310
0 Copyright 1997-2009 DLMS User Association
exchanging the results of processing these challenges, using cryptographic methods_ If the
authentication takes place. the client can proceed to access data within the access rights available
in the given AA, and it accepts data coming from the server. Otherwise, the AA is not established,
The HLS authentication process is supported by the COSEM-OPEN service — see 9.3.2— and by the
Association LN SN objects as follows:
Pass1: The client transmits a 'challenge - CtoS — for example. a random string — to the server:
Pass2: The server transmits a 'challenge - StoC — for example, a random string — to the client;
The length of the challenges shall be 8 to 64 octets.
Pass3: The client processes StoC according to the rules of the HLS authentication mechanism
negotiated:
• in the case of HLS authentication_mechanism id(2). the method of processing the challenge is
secret — for example encrypting with a secret key— which is the FILS secret known by both the client
and the server;
• in the case of HLS authentication_mechanism_id(3), the client right concatenates StoC received
during Pass2 with the HLS secret, known by both the client and the server, and generates a digest
using the MD5 algorithm: see RFC 1321:
• in the case of HLS authentication_mechanism_id(4), the process is the same. but the client
generates a digest using the SHA-1 algorithm; see RFS PUB 180-1;
• in the case of HLS authentication_mechanism_id(5), an authentication tag is calculated using
GMAC. see 9.2.4.8.4.
The result — f(StoC) — is sent back to the server_ The server checks if f(StoC) is the result of correct
processing and — if so — it accepts the authentication at the client.
Pass4: If the client is authenticated, the server processes CtoS in the same way as described in
Pass3. The result — f(CtoS) — is sent back to the client. The client checks if f(CtoS) is the
result of the correct processing and — if so — it accepts the authentication of the server.
The authentication process with HLS is shown on the right side of Figure 62.
High level
Low level security CID. C_ SID. C..
security
CID SID
Client Server Ghent Server
Assn. request (SID. CID, PW) Assn. request (SID, CID. CtoS)
71.
►
PW Assn. resp. (CID. SID. StoC. Acc
Assn. resp (CID. SID, Ace Rej)
II OK?
tii I 6.1
M.
F(StoC)
irk iw I
f(StoC) =
M.
1{CtoSi OK?
11
M
OK?
Assn_ release request (SID. CID) M.

1.1
Assn. release response (CID. SID)'
I I I Assn. release request {SID. CID) I
I I I Assn. release response (CID. SID) I
CID: Client address_ SID: Server address. PW: Password. 0K s h ared secret.
Clio& client challenge ro server. StoC: server challenge to client
Figure 62 — LLS and HLS authentication
DLMS User Association 2009-12-22 DLMS UA 1000 2 Ed. 7.0 - 121/310

Copynght 1997-2009 DLMS User Association
Pass1 is supported by the COSEM-OPEN.request service primitive of the client AL. The parameter
"Security Mechanism_Name" carries the identifier of the HLS mechanism, and the parameter
"Calling_Authentication_Value" carries the challenge CtoS.
Pass2 is supported by the COSEM-OPEN.response service primitive of the server AL. The
parameter "Security_Mechanism_Name" carries the identifier of the HLS mechanism, and the
parameter "Responding_Authentication_Value" carries the challenge StoC.
After Pass2, the AA is formally established. but the access of the client is restricted to the method
"reply to HLS_authentication" of the current "Association" object.
Pass3 and Pass4 are supported by the method reply_to_HLS_authentication of the association
object(s), see DLMS UA 1000-1 clause 4.4.1 and 4.4.2. If both passes are successfully executed,
then full access is granted according to the current AA. Otherwise. either the client or the server
aborts the AA.
In addition, the Association SN f LN object provides the method to change the HLS 'secret":
change_HLS_secret.
REMARX After the client has issued the change_HLS_seoret - or change_LLS_secret - method, it expects a
response from the server acknowledging that the secret has been changed. It is possible that the server transmits the
acknowledgement, but due to communication problems. ihe acknowledgement is not received at the client side. Therefore,
the client does not know if the secret has been changed or not. For simplicity reasons, the server does not offer any
special support for this case: +.e. it is left to the client to cope with this situation.
9.2.4 Data transport security

9.2.4.1 Applying, removing or checking the protection: ciphering and deciphering
For data transport security, cryptographic protection can be applied before sending an xDLMS
APDU — as determined by the security policy, see 9.2.4,3 then removed or checked after the
—
reception of an APDU.
NOTE 1 ACSE APDUs are not cryptographically protected, but their user-information field may be cryptographically
protected.
NOTE 2 Cryptographic protection of data in storage is out of the scope of this companion specification
Applying the protection is achieved by ciphering. Deciphering removes or checks the protection,
restoring the original xDLMS APDU. Ciphering and deciphering is performed by the COSEM AL as
shown in Figure 63.
When a COSEM service request or response primitive is invoked by the client or the server AP
respectively, the service parameters include the Security_Options parameter, This parameter
informs the AL on the requested security to be applied on the xDLMS APDU carrying the service
primitive, and it may identify elements of the security material to be used.
Similarly, a COSEM service indication or confirm primitive includes a Security Status parameter.
This parameter informs the AP on the security that was applied on the xDLMS APDU carrying the
service primitive, and it may include information on the elements of the security materials used. The
authentication tag, if any, is also passed.
For COSEM service definitions, see 9.3.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 122:310

Copyright 1997.2009 DLMS User Association
COSEM Client Application Process COSEM Server Application Process
COSEM Client Application Layer COSEM Server Application Layer
ACSE ••
. . xOLMS ASE ACSE xDLMS ASE
Security ciphering • Security Ciphering

context Deciphering context Deciphering
o
cu g
T 9.-}
Q. ci 7a
,— E
c, ix 2.
:5 < di <
iii —P ?y c),
.c 0 _c
_ x a. x
re
c c
m c.
Lower protocol layers Lower protocol layers
A A
Figure 63— Data transport security in DLMS. COSEM
9.2.4.2 Security context

The security context defines security attributes relevant for the ciphering ; deciphering process:
• the security policy in force, determining the kind of protection to be applied_ See 9_2_4_3:
• the security suite, specifying the security algorithm(s). See 9,2.4,4;
• the security material relevant for the given security suite, including elements like block cipher keys,
authentication keys. initialization vectors etc. See 9.2.4.5.
9.2.4.3 Security policy

The following security policies are specified:
• security is not imposed;

• all messages are authenticated;
• all messages are encrypted;
• all messages are authenticated and encrypted.
DL MS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 II 123/310

® Copyright 1997-2009 DLMS User Association
DLMS User Association, COSEM Architecture and Protocols, Seventh Edition
The security policy is held by the security_policy attribute of the Security setup object, see DLMS
UA 1000-1 4.4.5.
Authenticated access may be required selectively: certain attributes and methods may be
accessible only by using authenticated messages. This is indicated by the access mode to each
attribute and method. see DLMS UA 1000-1 4.4,1 and 4.4.2 respectively_ Therefore, authenticated
xDLMS APDUs may be used — within a ciphered application context — even when the security policy
in effect does not require that all messages be authenticated_
Note that if authenticated access is required, but the application context is not a ciphered one, the
attributes and methods requiring authentication cannot be accessed. If the client attempts to send a
ciphered APDU in an unciphered application context, then the server application layer shall reject it.
In the case of SN referencing, the response shall be ConfirmedServiceError APDU. carrying the tag
of the rejected APDU. In the case of LN referencing, the response shall be an ExceptionResponse
APDU.
On the other hand, encryption applies generally for all messages within a given AA: if the security
policy requires that all messages shall be encrypted. then all APDUs shall be encrypted — and
additionally they may be authenticated.
When the security policy requires that all messages shall be authenticated and encrypted, then only
APDUs that are both encrypted and authenticated can be used.
Messages protected by higher security then what the security policy requires are always allowed
(provided that the application context negotiated allows them).
9.2.4.4 Security suite

A security suite determines the cryptographic algorithm{ s) used for message security. A security
suite is identified with a Security Suite ID; see Table 13. Currently. one security suite is specified,
the Galois/Counter Mode (GCM) with AES•128. in this security suite, global keys see 9.2.4.7.3.3— —
are protected during transportation using the AES- 128 key wrap algorithm.
NOTE Other security suites may be added later.
Table 13 — Security suites

Security Suite Id Authentication algorithm Encryption algorithm Key transport method
Key wrapping using

0 AES•GCM•128 AES-GCM- 128
AES 128 key wrap
All other reserved -
9.2.4.5 Security material

The elements of the security material are the following:
• a block cipher key, denoted LK;

• an authentication key, denoted AK;
• an initialization vector, denoted
The elements depend on the security suite. For AES-GCM-128, they are defined in 9.2.4.8.
9.2,4.6 Ciphered xDLMS APOUs

Ciphered xDLMS APDUs can be used in a ciphered COSEM application context only. A ciphered
APDU is always an octet string.
NOTE In a ciphered COSEM application context, unciphered APDUs may also be used .
The structure of the ciphered APDU depends on the kind of ciphering applied; see Figure 64:
• if the APDU is authenticated only, it contains the APDU tag, the length field, the security header field, the
original APDU and the authentication tag;
• if the APDU is encrypted only. it contains the APDU tag, the length field, the security header field, and
the encrypted DLMS APDU;
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 124.310

i Copyright 1997.2009 DLMS User Association
ALMS User Association. COSEM Architecture and Protocols. Seventh Edition
• if the APDU is both authenticated and encrypted, it contains the APDU tag, the length field. the security
header field. the encrypted APDU and the authentication tag.
Security context
xDLMS APDU Ciphering Ciphered xDLMS APDU
Authenticated APDU Tag Len SH xDLMS APR]
Encrypted
Encrypted APDU Tag Len sm-
xDLMS APDU
Encrypted
Authenticated and encrypted APDU Tag Len MI
)30;_liAS AP
Figure 64 - Ciphered xDLMS APOUs

The APDU tag identifies the type of the APDU: see 9.5.
The length field specifies the length of the octet-string (including the security header, the
unencrypted or encrypted xDLMS APDU protected and the authentication tag).
The Security Header, SH, includes the Security Control field, SC right concatenated with the Frame
Counter. FC.
The Security Control field is shown in Table 14, where:
• Bit 3...0: Security_Suite_Id. see 9.2.4.4;

• Bit 4: "A" subfield: indicates that the APDU is authenticated;
• Bit 5: "E" subfield: indicates that the APDU is encrypted:
• Bit 6: Key_set subfield 0 = Unicast:
1 = Broadcast, see 9.2.4.7.2;
• Bit 7: Reserved. must be set to 0
Table 14 - Security control field
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3...0
Reserved. set to 0 Key_set E A Security_Suite_Id
The Frame Counter is an internal counter maintained by the sending and receiving parties_
Finally. 7 is the authentication tag. calculated by the authentication algorithm.
9.2.4.7 Cryptographic keys

9.2.4.7.1 General
A cryptographic key is a parameter used in conjunction with a cryptographic algorithm that
determines its operation in such a way that an entity with knowledge of the key can reproduce or
reverse the operation. whi l e an entity without knowledge of the key cannot For the purposes of
DLMS.COSEM, examples of operations include:
• the transformation of plaintext data into ciphertext data:

• the transformation of ciphertext data into plaintext data:
• the computation of an authentication code from data;
• the verification of an authentication code from data and a received authentication code.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 125/310 I

IDLMS User Association. COSEM Architecture and Protocols. Seventh Edition
9.2.4.7.2 Key types

Various key types are defined. They are identified according to their classification, their
cryptographic function, their use and their scope.
By their classification, a distinction is made between:
• symmetric keys. A symmetric key is a single cryptographic key that is used with a secret (symmetric) key
algorithm. For an overview of symmetric key algorithms, see 15.3:
• public and private keys. used with public key cryptographic algorithms. For an overview of asymmetric
key algorithms, see 15_4.
For symmetric keys, a distinction is made between:
• Symmetric authentication keys. used with symmetric key algorithms to provide assurance of the integrity
and source of messages:
▪ Symmetric data encryption keys. used with symmetric key algorithms to apply confidentiality protection
to information; and
• Symmetric key wrapping keys. used to encrypt other keys using symmetric key algorithms. Key wrapping
keys are also known as key encrypting keys (KEK).
By their use. a distinction is made between:
• unicast keys. used to secure unicast communication between two peers;

• broadcast keys. used to secure broadcast communication between a DLMS/COSEM client and several
DLMS/COSEM servers.
NOTE In DLMS/COSEM, broadcast can be initialed by the client only
By their scope, a distinction is made between dedicated keys and global keys. Mese terms are
DLMS/COSEM specific:
• a dedicated key is a ciphering key that may be used to cipher xDLMS APDUs from the establishment of
an AA between a client and a server until the AA is released. Therefore. its lifetime is the same as the
lifetime of the AA. It is delivered during AA establishment and used in subsequent transmissions within
the same AA.
NOTE When the AA is released the dedicated key should be destroyed by the server as well as by the client.
• a global key is a ciphering key that may be (re-).used to cipher xDLMS APDUs, exchanged between the
same client and server, in more than instance of the AA_
The following (symmetric) encryption keys may be available: global unicast key, global broadcast
key, dedicated unicast key.
A (symmetric) authentication key is always a global key that can be used in unicast and broadcast
messages.
Additional, security suite specific rules may apply. See also Table 15.
9.2.4.7.3 Key management

NOTE This sub-clause provides general guidelines that should be 'viewed to ensure a secure implementation. The
management of the security system, including the security keys is the responsibility of the system operator.
9.2.4.7.3.1 System architectures

For the purposes of this section, two general system architectures are considered:
• the COSEM client is the central DCS. exchanging data directly with COSEM servers:
• the COSEM client is a concentrator, exchanging data on the one hand with COSEM servers, and on the
other hand with the central DCS.
NOTE In this case, the concentrator may or may not be a COSEM server at the same time. The central DCS may
or may not be a COSEM client_
For generation and distribution of symmetric keys, see NIST SP 800-57 8.1..5.2
DLMS User Association 2009-12.22 DLMS UA 1000-2 Ed. 7.0 12./311D

G. Copyright 1997-2009 DLMS User Association
DLMS User Association. CCSEM Architecture and Protocols, Seventh Edition
9.2.4.7.3.2 Master key

A master key shall be present in each COSEM server logical device configured in the system_ This
key is used for wrapping global keys. see 9.2.4.7.3.3.
NOTE The way of generating and installing the master key is out of the scope of this companion specification.
A secure mechanism must be in place to ensure that the central data DCS knows the master key of
each COSEM server logical device participating in the system_
NOTE The specification of such a mechanism is out of the scope of this companion specification.
The concentrators, if they are present in the system, shall not know the master keys_
NOTE For security reasons, the lifetime of the master key should be limited. The way to replace the master keys is out
of the scope of this companion specification_ For guidance. see NIST SP 800-57 clause 8.2.3, Key change function.
9.2.4.7.3.3 Global keys

Before ciphering can be used. global keys have to be generated and delivered to the COSEM
logical devices participating in the system.
Global keys shall be generated by the central DC&

NOTE The way to generate the global keys is outside the scope of this companion specification. For security reasons,
their lifetime should be limited. Additional. security algorithm specific limitations may apply.
For delivery, global keys shall be wrapped using the AES-1128 key wrap algorithm — see RFC 3394—
arid the master key.
When the system works without (a) concentrator(s), the global keys shall be delivered by the central
DCS invoking the global_key_transfer method of the Security setup interface object in the COSEM
server with the wrapped global key as a parameter; see DLMS UA 1000-1 4.4.5.
When the system works with (a) concentrator(s), the global keys shall be delivered — wrapped by
the master key — to the concentrator. The global_key_transfer method of the Security setup
interface object in the COSEM server shall be invoked then by the concentrator with the wrapped
global key as a parameter. For details. see DLMS UA 1000-1 4.4.5.
In any case, the global key is wrapped by the master key.

NOTE The concentrator should not know the master keys. therefore it should not be able to wrap f unwrap global keys
The global keys shall also be made available by the central DCS to the concentrator(s), if present,
in a secure way.
NOTE The specification of such a process is out of the scope of this companion specification_
9.2.4.7.3.4 Dedicated keys

When the system works without (a) concentrator(s), dedicated keys shall be generated by the
central DCS. When the system works with (a) concentrator(s). dedicated keys shall be generated by
the concentrators.
For delivery, they shall be included in the dedicated-key field of the xDLMS InitiateRequest APDU,
carried by the user-information field of the AARQ APDU. The xDLMS InitiateRequest APDU shall be
authenticated and encrypted using the AES-GCM-128 algorithm, the global unicast encryption key
and — if in use, see 9.2.4.8,3.4.4 — the authentication key. Likewise, the xDLMS InitiateResponse
APDU, carried by the user-information field of the AARE APDU shall be also encrypted and
authenticated the same way.
NOTE The AARO and the AARE APDUs themselves are neither encrypted_ nor authenticated_ but their user-information
field may be cryptographically protected.
The various cryptographic key types, together with their use and their management are summarized
in Table 15.
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0 127/310

' Copyright 1997-2009 DLMS User Association
Table 15 — Cryptographic keys and their management
Key type Use Generation Delivery Location

Symmetric keys
Key Encryption
Central DCS and
Master key Key (XEX} for Not specified Not specified
COSEM server
global keys
Wrapped with master key,
Global encryption invocation of Central DCS and
Global unicast
of unicast Central DOS global_key_transfer Concentrator) and
encryption key
xDLMS APOUs method by the central DOS COSEM server
or the concentrator
Wrapped with master key,
Global encryption invocation of Central DOS (and
Global broadcast
of broadcast Central DOS global .key,iransfer Concentrator) and
encryption key
xOLMS APOUs method 1y the central DC$ COSEM server
or the concentrator
Wrapped with master key.
Authentication key Authentication al
invocation of Central DCS (and
Central DCS global_key_transfer Concentrator) and
(Global) xOLMS APDLI's
method by the central DCS COSEM server
or the concentrator
Transported as part of the
xEILMS I ni iiateRequest
Genital DCS (or
Dedicated APDU. which is encrypted
Dedicated COncentrater) and
encryption at Central DCS or and authenticated using the
tunicast) COSEM server
unicast xDLMS Concentrator AES-GCM-128 algorithm,
encr yption ke y (during the liletime
APPUs the global unicast
Of !he AA)
encryption key and the
authentication key
NOTE if ahernatives are given, the first alternative is valid for systems not using concentrators and the second
alternative for systems using concentrators.
9.2.4.8 The GaloislCounter Mode of Operation (GCM)

9.2.4.8.1 Introduction
NOTE The following text is taken from NISI SP 800•38D Clause 3.
Galois/Counter Mode (GCM) is an algorithm for authenticated encryption with associated dela.
GCM is constructed from an approved symmetric key block cipher with a block size of 128 bits.
such as the Advanced Encryption Standard (AES) algorithm, see FIPS PUB 197. Thus, GCM is a
mode of operation of the AES algorithm.
Gail provides assurance of the confidentiality of data using a variation of the Counter mode of
operation for encryption.
GCM provides assurance of the authenticity of the confidential data (up to about 64 gigabytes per
invocation) using a universal hash function that is defined over a binary Galois (i.e.. finite) field.
GCM can also provide authentication assurance for additional data (of practically unlimited length
per invocation) that is not encrypted.
If the GCM input is restricted to data that is not to be encrypted. the resulting specialization of
GCM, called GMAC, is simply an authentication mode on the input data.
GCM provides stronger authentication assurance than a (non-cryptographic) checksum or error

detecting code; in particular. GCM can detect both 1) accidental modifications of the data and 2)
intentional, unauthorized modifications.
In DLIvIS/COSEM, it is also possible to use GCM to provide confidentiality only: in this case, the
authentication tags are simply not computed and checked.
For more information, see NIST SP 800-38D.
DLMS User Association 12009 12 22

- - DLMS UA 1000-2 Ed. 7.0 128/310
Copyright 1997-2009 DLMS User Association
9.2.4.8.2 Definitions, abbreviations, symbols and notation relevant for the Galois/Counter
mode
Term I Symbol Meaning
Abbreviation
Additional A The input data to the authenticated encryption function that is authenticated but
authenticated data not encrypted. It is also known as Associated Data .
(AAD)
Authenticated The function of GCM in which the ciphertext is decrypted into the plaintext, and
decryption the authenticity of the ciphertext and the AAD are verified.
Authenticated The function of GC0.11 in which the plaintext is encrypted into the ciphertext, and
encryption an authentication tag is generated on the AAD and the ciphertext.
Authentication key AK Part of the AAD.
Block cipher A parameterized family of permutations on bit strings of a fixed length; the
parameter that determines the permutation is a bit string called the key.
Ciphertext C The encrypted form of the plaintext.
EK The block cipher key.

Fixed field In the deterministic construction of !Vs, the field that identifies the device or
context for the instance of the authenticated encryption function.
FC Frame counter_
Fresh For a newly generated key, the property of being unequal to any previously used
key.
GCM Galnis/Counter Mode.
Initialization vector iv A nonce that is associated with an invocation of authenticated encryption on a

particular plaintext and AAD.
Invocation field In the deterministic construction of Pis, the field that identifies the sets of inputs
to the authenticated encryption function in a particular device or context. For the
purposes of this companion specification, the invocation field is the frame
counter.
Key The parameter of the block cipher that determines the selection of the forward
cipher function from the family of permutations.
KEK Key encryption key
fen(X) The bit length of the bit string X.

LEN(X) The octet length 01 the octet string X.
Nonce A value that is used only once within a specified context
Plaintext P The input data to the authenticated encryption function that is both
authenticated and encrypted.
SC Security control byte.
SH Security header; concatenation of the security control byte SC and the frame
counter FC: SH = SC II FC.
Svs T - System title; A unique identifier of the system.
Authentication tag T A cryptographic checksum on data that is designed to reveal both accidental
errors and the intentional modification of the data.
t The bit length of the authentication tag.

NOTE This is the same as len(T)
X II le Concatenation of two strings. X and Y.
9.2.4.8.3 Elements of GCM

9.2.4.8.3.1 Block cipher and keys
For the purposes of this companion specification, the AES encryption standard has been selected.
GCM uses the forward cipher function; it does not employ the inverse cipher function.
GCM uses a single key, the block cipher key (the key, for short). Its size shall be 128 bits. In
DLMS/COSEM, for additional security, an authentication key is also specified. It is part of the

© Copyright 1997-2009 DLMS User Association
additional authenticated data. AAD. The block cipher key is denoted EK and the authentication key
is denoted .4K.
9.2.4.8.3.2 GCM functions

NOTE The following is based an NIST SP 800-38D 5.2.
9.2.4.8.3.2. General
The two functions that comprise GCM are called authenticated encryption and authenticated
decryption_ The authenticated encryption function encrypts the confidential data and computes an
authentication tag on both the confidential data and any additional. non-confidential data. The
authenticated decryption function decrypts the confidential data, contingent on the verification of the
tag.
When the input is restricted to non-confidential data, the resulting variant of GCM is called GMAC.
For GMAC, the authenticated encryption and decryption functions become the functions for
generating and verifying an authentication tag on the non-confidential data
Finally, if authentication is not required. the authenticated encryption function encrypts the
confidential data, but the authentication tag is not computed. The authenticated decryption function
decrypts the confidential data, but no authentication tag is computed and verified.
9.2.4.8.3.2.2 Authenticated encryption — input and output data

NOTE The following texl is based on NIST SP 900 38D 5.2.1.1 and RFC 4106 2.1.
-
The authenticated encryption operation has four inputs, each of which shall be an octet string:
• a plaintext, denoted P;
• additional authenticated data (AAD), denoted A. It shall include — together with other elements — the
authentication key, denoted AK.
• a secret block cipher key denoted
• an initialization vector denoted IV.
The plaintext and the AAD are the two categories of data that GCM protects. GCM protects the
authenticity of the plaintext and the AAD; GCM also protects the confidentiality of the plaintext,
while the AAD is left in the clear.
The IV is essentially a nonce, i,e, a value that is unique within the specified (security) context,
which determines an invocation of the authenticated encryption function on the input data to be
protected. See 9,2.4,8.3.4,5.
There are two outputs:
• a ciphertext. denoted C whose length is exactly that of the plaintext P;

• an authentication tag, denoted T-
9.2.4.8.3,2.3 Authenticated decryption — input and output data
The authenticated decryption operation has five inputs:
• the secret block cipher key. denoted EK;

• the initialization vector, denoted iv;
• the ciphertext, denoted C;
• the additional authenticated data (PAD), denoted A;
• the authentication tag, denoted I
The output is one of the following:
• the plaintext P that corresponds to the ciphertext C. 01

• a special error code, denoted FAIL in this document.
The output P indicates that T is the correct authentication tag for IV, A, and C; otherwise. the output
is FAIL.
The authenticated encryption and authenticated decryption functions, their inputs and outputs, as
well as the structure of the secured APDUs are shown in Figure 65 below.
DLMS User Association 2009-12-22 I DLMS UA 1000-2 Ed. TO 11 130/310

0 Copyright 1997-2009 DLMS Use Association
DLMS User Association. COSEM Architecture and Protocols, Seventh Edition
Security
Control
Mir
Authentication
SC-A MD =gyp II AK II APDU
only
Encryption only SC-E t MD = nut
Authenticated
SC-AE AAD = SC-AE II AK Fail
encryption
A
EK
Iv
Sys-T FC
C T
Ciphered APDU: Authentication only
Tag Len SC-A FC 7.2.r

Ciphered APDU: Encryption only
Tag Len SC-S FC Ciphertext AAD = null

a
Ciphered APDU: Encryption + Authentication

Tag Len SC-AE FC Ciphertext AAD SC - AE II AK
A = AAD IV = Initialization vector

Additional Authenticated Data (Associated data) AK =Authentication key P = Plaintext
contain: C = Ciphertext SC = Security control byte:
- Authentication only: SC-A II AK II xDLMS APDU: SC-A: Authentication only
- Encryption only: Null SC-E: Encryption only
- Authenticated encryption: SC-AE DAK SC-AE: Authenticated
encryption
EK = Encryption key Six T = System title
-
FC = Frame counter T = Authentication tag
Figure 65 - Cryptographic protection of xDLMS APDUs using GCM

9.2.4.8.3.3 The security header with GCM
The security header shall be as specified in 9.2.4.6, with security_suite_id = 0 and with the
appropriate values of the Key_set. E and A sub-fields.
9.2.4.8.3.4 GCM parameters and data elements

9.2.4.8.3.4.1 Length of the authentication tag
The bit length of the authentication tag, denoted t. is a security parameter. Its value shall be 96 bits.
9.2.4.8.3.4.2 Pfaintext and additional authenticated data

The plaintext, denoted P and the additional authenticated data. denoted A depend on the kind of
protection. They are shown in Table 16. where SC is the security control byte. AK is the
authentication key and M is the message. i.e. the xDLMS APDU to be protected.
The bit lengths of the P and A shall meet the following requirements:
• len(P) < 2 39 .256;

• len(A)< 2"-1;
• the bit lengths of P and A shall all be multiples of 8. so that these values are octet strings.
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0 131.1310

Copynght 1997-2009 ❑ LMS User Association
Table 16 - Plaintext and additional authenticated data
Security control, SC Security P A
E field A field
0 0 None
0 1 Authenticated only —
SC II AK it M
1 0 Encrypted only M
1 1 Encrypted and authenticated M SC II AK
9.2.4.8.3.4.3 The block cipher key, 1-r.K

The size of the block cipher key, denoted EK shall be 128 bits (16 octets): len(EK = 128.
The key shall be generated uniformly at random. or close to uniformly at random, i.e., so that each
possible key is (nearly) equally likely to be generated. Consequently. the key will be fresh, i.e.,
unequal to any previous key. with high probability. The key shall be secret and shall be used
exclusively for GC1v1 with the chosen block cipher AES. Additional requirements on the
establishment and management of keys are discussed in NIST SP 800-38D 8.1.
9.2,4,8.3.4,4 The authentication key, AK

Although not required by GCM, an authentication key. denoted ,4K is specified for additional
security in DLMS/COSEM. For its length and its generation. the same rules apply as for the
encryption key_ The authentication key shall be part of the additional authenticated data AAD. If an
authentication key has been transferred, it must be used. until a null authentication key is
transferred_
9.2.4.8.3.4.5 The initialization vector, IV

For the construction of the initialization vector. iv. deterministic construction as specified in NISI
SP 800-38D 8_2.1 shall be used
In the deterministic construction, the IV is the concatenation of two fields, called the fixed field and
the invocation field. The fixed field shall identify the physical device, or, more generally, the
(security) context for the instance of the authenticated encryption function. The invocation field shall
identify the sets of inputs to the authenticated encryption function in that particular device.
For any given key, no two distinct physical devices shall share the same fixed field, and no two
distinct sets of inputs to any single device shall share the same invocation field.
The length of the IV shall be 96 bits (t2 octets): len(110 = 96. Within this
• the leading (i.e. the leftmost) 64 bits (8 octets) shall hold the fixed field. It shall contain the system title,
see 9.2.4.8.3.4.6;
• the trailing (i.e. the rightmost) 32 bits shall hold the invocation field: see 9.2.4.8.3.4.7.
The bit length of the fixed field limits the number of distinct physical devices that can implement the
authenticated encryption function for the given key to 2 64 . The bit length of the invocation field limits
the number of invocations of the authenticated encryption function to 2 32 with any given input sets
without violating the uniqueness requirement.
9.2_4.8.3_4_6 System title

Each physical device in the system. including the meters, the concentrators when used, and the
DCS shall be uniquely identified with its system title. The system title denoted as Sys - T shall be
constructed as follows:
• its length shall be 8 octets;

• the leading (i.e.. the 3 leftmost) octets shall hold the three-letter manufacturer ID 26 . This is the same as
used in the leading octets of the Logical Device Name of server logical devices.
25 Administered by the DLMS UA acting as a registration aultioritr the same as the one used in the LON.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 I 132/310

© Copyright 19V-2409 DLMS User Association
DLMS User Association, COSEM Architecture and Protocols_ Seventh Edition
NOTE Man ufaclurers of COSEM clients, i.e. concentrators and data collection systems should also obtain their
3-letter ID from the DLMS UA,
• the trailing (i.e. the 5 rightmost) octets. together with the manufacturer ID. shall ensure the uniqueness of
the system title.
NOTE These 5 OClelS can be derived for example from the last twelve clips at the manufacturing number, up to
999 999 999 999_ This vaiue converts to oxE8D4A5OFFF_ Values above this. up to OxFFFFFFFFFF (decimal value
1 099 511 627 775) can also be used. but these values cannot be mapped to the last 12 digits al the manufacturing
number.
Project specific companion specifications may specify a different structure for the system title, but in
any case, the system title must be 8 octets long if necessary, right padded to 8 octets and must
— —
be unique. The details shall be specified by the naming authority designated as such for the project.
Before the message security algorithms can be used — this requires a ciphered application context —
the peers have to exchange system titles. The following possibilities are available:
• when the S-FSK PLC profile is used, system titles are exchanged during the registration process using
the CIASE protocol; see 10_4_5;
• in all communication profiles, system titles are exchanged during AA establishment using the COSEM-
OPEN service, see 9.3_2, carried the AARQ AARE APDUs:
NOTE If the system titles sent I received during AA establishment are not the same as the ones exchanged during
the CIASE registration process, the AA should be rejected.
• by writing the client_system_title attribute and by reading the server_system_title attribute of Security
setup objects, see DLMS OA 1000.1 4.4.5.
NOTE For broadcast communication, only the COSEM client has to send II to the COSEM server .
9.2.4.8.3.4.7 The invocation field

The invocation field shall be an integer counter (frame counter).
9.2.4.8.3.5 Example
The following example illustrates the process of creating ciphered xDLMS APDUs when applying
authentication only, encryption only and authenticated encryption.
Table 17 - Example for ciphered APDUs
LEN Len
A Contents IX.li (X)
bytes bits
Security
material
Security suite Gcm-Aes--128
T 404D4D0000BC614E(here, the five Last octets contain

System Title 8 64
5."-' the manufacturing number in hexa).
Frame Counter FC 01234567 4 32
Initialization S•s-T II FC
IV 12 96
Vector 44404000003C614E01234567
Block cipher key

EK 000102030405060708090A0e0c0o0zer 16 128
(global)
Authentication
AK DODID2O3D4D5D6D7D8D9DADBDCDDDEDF 16 128
Key
Authenticated
Security applied Authentication Encryption
encryption
Security control SC-.A SC-E SC-AE 1 8

byte (with SC
unicast key) = 20 3 1J
SH = SC-A II FC SH = SC-E II Fe SH = Se-AE II FC

Securit y header SH
1001234567 2001234567 30-0123456: 5 40
_... .

Copyright 1997 - 2009 DLMS User Association
IDI_MS User Association, COSEM Architecture and Protocols. Seventh Edition
LEN Len
X Contents PO (x)
bytes bits
I Authenticated
Inputs Authentication Encryption
encryption
xDLMS APDU to coo i060408000001o00orro200
APDU 13 104
be protected (Get-request. attribute 2 of the Clock object)
cadl°4°008000001 c001000003000001
Plaintext P Null
c000rro2co 0000FF0200
13 104
Associated data A SC 11 AK il APDU SC II AK

100001D2030'10506
Associated Data D7D8D9DADEMCDDOE
A -A - 30 24 0
- Authentication OrCOOl0000080000
010004FT0200
Associated Data
A-E - - - 0 0
-Encryption
Associated Data 3000011)2D3D4D5D6

- Authenticated A -AE - - D7D8O9DADBDCODDE 17 136
encryption op'
Outputs Authentication Encryption

encryption
411312FF935A4756 411312FF935A4756
Ciphertext C NULL
6827C467BC 6827C4678C
13 104
Authentication 06725D910F9221132 708250314E4A77C3F

T -
CCO568613 12 96
tag 63877516
The complete TAG II LEN II SH U

TAG II LEN II VI 11 C
TAG II LEN II $11 ii r - -
Ciphered APDU APDU 11 T II T
C81n441234567c0
Authenticated 0100000800000100
32 256
APDU 00FF020006725091 -
0E92210263877516
C812200123456741
Encrypted APOU - 1312er435A47s668 - 20 160
27c4Vec
Authenticated C81E300123456741
13I2FF 935A4 75648
and encrypted 27C467BC,C).825Cn 32 256
APDU E4A.77C3FCCO563363
9.2.4.6.4 High Level Security peer authentication with GMAC

(authentication_mechanism_id(5)
NOTE See also 9.2.3.4.

In the case of authentication_mechanism_id(S), the process is the following:
• Pass 1 and Pass 2 shall be the same as described in 9.2.3,4;

• in Pass 3 and 4, instead of the HLS secret (held by the Association LN / Association SN objects), the
global unicast encryption key, and the authentication key (if in use) are used. These are transferred to
the server using the global_key_transfer method of the Security setup class, see DLMS UA 1000-1
4.4.5;
• in Pass 3, the client processes StoC. The authentication tag T is calculated using GMAC on SC II AK II
StoC. The result f(StoC) = SC II FC II T is sent back to the server. The server checks if f(StoC) is the
result of correct processing and — if correct — accepts the authentication of the client;
• in Pass 4: If the client is authenticated, the server processes CtoS in the same way as described in
Pass 3. The authentication tag T is calculated using GMAC on sc II AK II CtoS. The result f(CtoS) = SC 11
FC IL T is sent back to the server. The client checks if f(CtoS) is the result of the correct processing and —
if correct accepts the authentication of the server.

—
An example is shown in Table 18 below.
Table 18 - FILS example with GMAC
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 13211310

Copynght 1997-2009 DLMS Usef Association
Security material X Contents UNIX) ieuirX)

bytes bits
Security suite GC14-AES-12B
4D4O4D0000BC614E
System Title Sys T - (herea t he five last octets contain a 64
the manufacturing number in hexa)
Sys-T 11 PC
Initialization Vector IV 12 95
4D4D400000BC614e01234561
Block cipher Hey (global) EK 000102030405060708090A0B000DOEOF 15 126

AuthentiCatiOn Kin AK Dcon201D405n6D7D8D9DADBocoDDEDF 18 128
Security control SC 10 1 s
etoS 4B35366956616759 '1(56iVagY" El 64
StoC 50367752411/2323146 "P6wR.321r^ 8 64
T (SC il AK il ClOS) FE1466AFB3DBCD4F9389E2B7 12 96
Kt* 1041234567FE1466APB3DBCD4P9389E297 17 136
T (SC il AK II SIOC) 1A52FE7DD3E72748913CLE213 12 96
f(St0C) 10012345671;452fE7DD3E72740973C1E28 17 136
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed, 7.0 II 135/310

(5 Copyright 1997-2009 DLMS User Association
9.3 COSEM application layer service specification

9.3.1 Service primitives and parameters
In general, the services of a layer (or sublayer) are the capabilities it offers to a user in the next
higher layer (or sublayer). In order to provide its service. a layer builds its functions on the services
it requires from the next lower layer. Figure 66 illustrates this notion of service hierarchy and shows
the relationship of the two correspondent N-users and their associated N-layer peer protocol
entities.
Service provider
Service user Service user
Request
▪ Indication
■ Response
Confirm -41
Figure 66 — Service primitives

Services are specified by describing the information flow between the N-user and the IN-layer. This
information flow is modeled by discrete, instantaneous events, which characterize the provision of a
service. Each event consists of passing a service primitive from one layer to the other through an N-
layer service access point associated with an N-user. Service primitives convey the information
required in providing a particular service. These service primitives are an abstraction in that they
specify only the service provided rather than the means by which the service is provided. This
definition of service is independent of any particular interface implementation.
Services are specif i ed by describing the service primitives and parameters that characterize each
service. A service may have one or more related primitives that constitute the activity that is related
to the particular service. Each service primitive may have zero or more parameters that convey the
information required to provide the service. Primitives are of four generic types:
• REQUEST: The request primitive is passed from the N-user to the N-layer to request that a service be
initiated.
• INDICATION. The indication primitive is passed from the N-layer to the N-user to indicate an internal N-
layer event that is significant to the N-user. This event may be logically related to a remote service
request, or may be caused by an event internal to the N-layer:
• RESPONSE: The response primitive is passed from the N-user to the N-layer to complete a procedure
previously invoked by an indication primitive:
• CONFIRM: The confirm primitive is passed from the N-layer to the N-user to convey the results of one or
more associated previous service request(s)_
Possible relationships among primitive types are illustrated by the time-sequence diagrams shown
in Figure 67. The figure also indicates the logical relationship of the primitive types. Primitive types
that occur earlier in time and are connected by dotted lines in the diagrams are the logical
antecedents of subsequent primitive types.

Cs Copyright 1997-2009 DLMS User Association
a) b)
Request • — to- Request

I► Indication I► Indication
Response
Confirm - 4— • • Confirm 4
-
c) d)
Request
Request
• -lb- Indication
Confirm -41—•
e)
Indication - 41 — IP- Indication
f)
Request Indication -4
Figure 67 -Time sequence diagrams

The service parameters of the COSEM AL service primitives are presented in a tabular format. Each
table consists of two to five columns describing the service primitives and their parameters. In each
table, one parameter — or a part of it — is listed on each line. In the appropriate service primitive
columns, a code is used to specify the type of usage of the parameter. The codes used are listed in
Table 19.
Some parameters may contain sub-parameters, These are indicated by labelling of the parameters
as M, U, S or C. and indenting all sub-parameters under the parameter_ Presence of the sub-
parameters is always dependent on the presence of the parameter that they appear under. For
example. an optional parameter may have sub-parameters: if the parameter is not supplied, then no
sub-parameters may be supplied.
DLMS User Association 12009.12-22 DLMS UA 1000-2 Ed, 7.0 137/310

© Copyright 1997-2009 ALMS User Association
Table 19 - Codes for AL service parameters
M The parameter is mandatory for the primitive.
U The parameter is a user option, and may or may not he provided depending on dynamic usage by the
ASE user.
S The parameter is selected among other S-parameters as internal response of the server ASE
environment.
C The parameter is conditional upon other parameters or the environment of the ASE user
il — i' The parameter is never present

m The ' (,,) - code following one of the M. 1.1, S or C codes indicates that the parameter is semantically
equivalent to the parameter in the service primitive to its immediate left in the table. For instance, an
" M l=y - code in the indication service primitive column and an 'IA' in the _request service primitive
column means that the parameter in the _indication primitive is semantically equivalent to the one in
the .request primitive.
Throughout this standard, the following rules are observed regarding the naming of terms:
• the name of ACSE services and the data transfer services using LN referencing is written in uppercase.
Examples are: COSEM-OPEN, GET;
• the name of the data transfer services using SN referencing is written in title case. Examples are: Read,
Write;
• camel notation is used in the following cases: EventNotification, TriggerEventNotificationSending,
UnconfirmedWrite, Information Report;
• the types of the LN service primitives may be mentioned in two alternative forms. Examples:
"GET.request service primitive of Request_Type == NORMAL" or "GET-REQUEST-NORMAL service
primitive";
• service parameter name elements are capitalized and joined with an underscore to signify a single entity:
Examples are Protocol Connection Parameters and COSEM Attribute Descriptor;
• when the same parameter may occur several times. this is indicated by repeating the parameter in curly
brackets. Example: Data ( Data );
• in the data transfer service specifications, parameters used with block transfer only are shown in bold.
Example: DataBlock_G:
• direct reference to a service parameter uses the capitalized form, while indirect (non-specific) reference
uses the small caps without underscore joining. A direct reference example is: "The
COSEM Attribute ... Descriptor parameter references a COSEM object attribute." An indirect (non-
specific) reference example is: "A GET•REOUEST-NORMAL service primitive contains a single COSEM
attribute descriptor";
• the names of COSEM data transfer APDUs using LN referencing are capitalized and joined with a dash
to signify a single entity. Example Get•Request-Normal;
• the names of COSEM data transfer APDUs using SN referencing use the camel notation. Example:
ReadRequest.
9.3.2 The COSEM-OPEN service

Note The description has been amended to cover the new data transport security features. The order of the service
parameters has been aligned with the order of the fields of the AARQ AARE ARDUs,
Function
The function of the COSEM - OPEN service is to establish an AA between peer COSEM APs. It uses
the A - ASSOCIATE service of the ACSE. The COSEM - OPEN service provides only the framework
for transporting this information. To provide and verify that information is the job of the appropriate
COSEM AP.
Semantics of the service primitives
The COSEM-OPEN service primitives shall provide parameters as shown in Table 20,
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 I 138/310

Table 20 - Service parameters of the COSEM-OPEN service primitives
.request indication .response _confirm
Protocol_Connection_Parameters M M (.) M M (.)
ACSE_Protocolyersion U U (.) U L1 (=)
Application_Context_Name Li /41 (-) M M (-)

Called_AP_Title U U (=)
Called_AE_Oualifier U U(=) - -
Galled_AP_Invocation_Identifier U U IC-) -
Called AE_Invocationidentifier U U (=) - -
Calling_AP_Tille C C (=) - -
Calling_AE_Qualifier U U (=) - -
Calling_AP invocation_Identifier U U (-) - -
Calling AE_Invocation_Identifier U U (=) - -
Local_Or_Remote - - M
Result M M
Faiture_Type - - IV M
Responding_AP_Title - - C C (=)
Responding_AE_Quaiiher U U (.)
Responding_AP_Invocation_Identitier - - U U (=)
Responding AE_Invocation_Identifier - - U U (-)
ACSE_Requirements U U (=} U U (•)
Security_Mechanism_Name C C (=) C C (=)
Calling_Authentication_Value C C IC-) - -
Responding_Authentication_Value - - C C (.)
Irnplementation_Information U U (=) LI U (=)

Propased_xDLMS_Conlext 164 PA (=) - -
Dedicated_Key C CM - -
Proposed[I,LMS_Version_Nomber LI LI (=)
Proposed_DLMS_Conformance M PA (=) - -
ciient_Max_Receive_PDU_Size /41 LI (-) - -
Negotiated_xDILMS_Context - - S S (.=.)
Negotiated_DLMS_Version_Nornber - - M YI (-)
Negotiated_DLMS_Conformance - - M M (=.)
Server_Max_Receive_PDU_Size - - M M (-)
VAA_Narne Iv1 M (m)

XDLMS_Initiate_Error S S (=)
User_Information U C (=I -
Service_Class M hi 1=) _ _
The service parameters of the COSEM-OPEN.request service primitive except the

Protocol Connection_Parameters, the User_Information parameter and - depending on the
communication profile - the Service -Class parameter are carried by the fields of the AARC APDU
sent by the client.
The service parameters of the COSEM-OPEN.response service primitive, except the

Protocol_Connection_Parameters is carried by the fields of the AARE APDU sent by the server.
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0 II 139/310

The A-ASSOCIATE service and the AARQ and AARE APDtJs are specified in 9.4.2. Encoding
examples are given in 11.
The Protocol_Connection_Parameters parameter is mandatory. It contains all information necessary

to use the layers of the communication profile, including the communication profile (protocol)
identifier and the addresses required. It identifies the participants of the AA. The elements of this
parameter are passed to the entities managing lower layer connections and to the lower layers as
appropriate.
The ACSE Protocol Version parameter is optional. If present, the default value shall be used.
The Application_Context_Name parameter is mandatory. In the request primitive, it holds the value
proposed by the client In the response primitive. it holds the same value or the value supported by the
server.
The Calling_AP_Title parameter is conditional. When the Application_Context_Name indicates an

application context using ciphering, it shall carry the client system title specified in 9.2.4.8.3.4.6.
The use of the Called _

AP_Title. Called_AE_Oualifier, Called_APAP_Invocation
Invocation
Called AE Invocation Identifier. Calling_AE_Quadifier, Calling_AP_Invocation
_Identifier and Calling_AE_Invocationidentifier parameters is optional. Their use is not specified in
this companion specification.
The Local_or_Remote parameter is mandatory. It indicates the origin of the COSEM-OPEN confirm
primitive. It is set to Remote if the primitive has been generated following the reception of an AARE
APDU from the server. It is set to Local if the primitive has been locally generated.
The Result parameter is mandatory. In the case of remote confirmation, it indicates whether the
Server accepted the proposed AA or not. In the case of local confirmation, it indicates whether the
client side protocol stack accepted the request or not.
The Failure_type parameter is mandatory. In the case of remote confirmation, it carries the
information provided by the server. In the case of local and negative confirmation, it indicates the
reason for the failure.
The use of the Responding_AP_Title parameter is conditional. When the Application Context Name
parameter indicates an application context using ciphering, it shall carry the server system title
specified in 9.2.4.8.3.4.6.
The use of the Responding_AE_Qualifier. Responding_AP_Invocation_Identifier and Responding

AE_Invocation _Identifier parameters is optional. Their use is not specified in this companion
specification.
The ACSE_Requirements parameter is optional. It is used to select the optional authentication

functional unit of the A-Associate service for the association. See 9.4.2.1.
The presence of the AOSE _requirements parameter depends on the security mechanism used:
• in the case of Lowest Levet security, it shall not be present: only the Kernel functional unit is used:
• in the case of Low Level security (LLS) it shall be present in the .request primitive and it may be present
in the .response service primitive;
• in the case of High Level Security 1HLS), it shall be present both in the .request and the .response
service primitives.
The Security_Mechanism_Name parameter is conditional. It is present only, if the authentication
functional unit has been selected. If present. the .request primitive holds the value proposed by the
client and the .response primitive holds the value required by the server, i.e. the one to be used by the
client.
The Calling_Authentication_Value parameter and the Responding_Authentication_Value parameters

are conditional. They are present only. if the authentication functional unit has been selected. They hold
the client authentication value / server authentication value respectively, appropriate for the
Security_pechanisrn_Name.
DLMS User Association I 2009-12-22 DLMS UA 1000-2 Ed. 7.0 140,1310

C Copyright 1997-2009 DLMS User Association
00.4S User Association. COSEM Architecture and Protocols. Seventh Edition
The Implementation_Information parameter is optional. Its use is not specified in this companion
specification_
The Proposed_xDLMS_Context parameter holds the elements of the proposed xDLMS context carried
by the xDLMS InitiateRequest APDU, placed in the user-information field of the AARQ APDU.
The Dedicated_Key element is conditional. It may be present only, when the

Application_Context_Name parameter indicates an application context using ciphering. The
dedicated key is used for dedicated ciphering of xDLMS APDUs exchanged within the AA
established .
When the dedicated key is present. the xDLMS InitiateRequest APDU shall be authenticated and
encrypted using the AES-GCM-128 algorithm. the global unicast encryption key and the
authentication key (if in use). The xDLMS InitiateRequest APDU shall be ciphered the same way,
when the dedicated key is not present. but it is necessary to protect the RLRQ APDU by including
the ciphered xDLMS InitiateRequest in its user-information field. See 9.3.3,
The Proposecl_DLMS_Version_Nurnber element holds the proposed DLMS version number. See
9.1.2.3.1.
The Proposed_DLMS_Conformance element holds the proposed conformance block. See 9.4.6.1.
The Glient_Max_Receive PDU Size element holds the maximum length of the xDLMS APDUs the
client can receive. See Table 12.
If the xDLMS context proposed by the client is acceptable for the server, then the response service
primitive shall contain the Negotiated_xDLMS Context parameter. It holds the elements of the
negotiated xDLMS context, carried by the xDLMS InitiateResponse APDU. placed in the user-
information field of the AARE APDU. If the xDLMS InitiateRequest APDU has been ciphered, the
xDLMS InitiateResponse APDU shall be also ciphered the same way.
The Negotiated_DLMS_Version_Number element holds the negotiated DLMS version number. See
9,1.2.3.1,
The Negotiated_DLMS_Conformance element holds the negotiated conformance block. See 9.4 6.1.
The Server_Max_Receive_PDU_Size element carries the maximum length of the xDLMS APDUs
the server can receive. See Table 12.
The VAA_name element carries the dummy value of 0x0007 in the case of LN referencing, and the
base_name of the current Association object. OxFA00. in the case of SN referencing.
If the xDLMS context proposed by the client is not acceptable for the server, then the response
service primitive shall carry the xDLMS_Initiate_ Error parameter_ It is carried by the
ConfirmedServiceError APDU, with appropriate diagnostic elements, placed in the user-information
field of the AARE APDU.
The User_Information parameter is optional. If present, it shall be passed on to the supporting

layer, provided it is capable to carry it. The indication primitive shall then contain the user-specific
information carried by the supporting lower protocol layer(s). See 10.
The Service_Class parameter is mandatory. It indicates whether the service shall be invoked in a
confirmed or in an unconfirmed manner. The handling of this parameter may depend on the
communication profile. See 10.
Use
A possible logical sequence of the COSEM-OPEN service primitives is illustrated in Figure 67:
▪ for confirmed AA — successful or unsuccessful — establishment. item a);

• for unconfirmed AA establishment, item b);
• in the case of a pre-established AA or an unsuccessful attempt due to a local error. item c).

ID Copyright 1997-2009 ❑ LNIS User Association
The .request primitive is invoked by the client AP to request the establishment of a confirmed or an
unconfirmed AA with a server AP 2 Upon the reception of the request invocation, the AL constructs
.
and sends an AARO APDU to the server.

The .indication primitive is generated by the server AL when a correctly formatted AARO APDU is
received.
The .response primitive is invoked by the server AP to indicate to the AL whether the proposed AA
is accepted or not. It is invoked only if the proposed AA is confirmed. The AL constructs then an
AARE APDU and sends it to its peer, containing the service parameters received tram the AP.
The .confirm primitive is generated by the client AL to indicate to the client AP whether the AA
requested previously is accepted or not:
• remotely, when an AARE APDU is received:

• locally, if the requested AA already exists; this includes pre-established AAs:
• locally, if the corresponding _request primitive has been invoked with Service Class == Unconfirmed;
• locally, it the requested AA is not allowed;
• locally, if an error is detected: missing or not correct parameters. failure during the establishment of the
requested lower layer connections, missing physical connection. etc.
The protocol for establishing an AA is specified in 9,4.4_ Communication profile specific rules are
specified in in 10,
9.3.3 The COSEM-RELEASE service

Nola The descriplion has been amended to bailer align with i he A-Release service and to allow the user- inlorrnation
field of the RLRQ I RLRE to carry a ciphered xDLMS InitiateRequest f InitiateResponse APDU. to secure the COSEM-
RELEASE service.
Function
The function of the COSEM-RELEASE service is to gracefully release an existing AA. Depending on
the way it is invoked. it uses the A-RELEASE service of the ACSE or not.
Semantics of the service primitives
The COSEM-RELEASE service primitives shall provide parameters as shown in Table 21
Table 21 - Service parameters of the COSEM-RELEASE service primitives
.request indication .response .confIrrn

Use RLRQ RLRE U CH C(z)
Reason U U H U U (•)
Proposed_xDLMS_Context C C (w) - -
Negotiated_xDLMS_Context - - C C (=}
Local Or Remote - - - M
Result M M
Failure_Type - C
User_Information U C (=) U C (,)
The Use_RLRCI_RLRE parameter in the .request primitive is optional. If present, its value may be
FALSE (default) or TRUE. It indicates whether the ACSE A-RELEASE service — involving an RLRQ
RLRE APDU exchange — should be used or not. The A-RELEASE service and the RLRQ 1 RLRE
APDUs are specified in 0.4.2. The Use_RLRO_RLRE parameter in the .response primitive is
conditional. If it was present in the _indication primitive and its value was TRUE, it shall also be
present and its value shall be TRUE. Otherwise. it shall not be present or its value shall be FALSE.
If the value of the Use_RLRO_RLRE parameter is FALSE, then the AA can be released by
disconnecting the supporting layer of the AL.
27 Before the invocation of the COS E M.OPEN.request primitive. the physical layers must he connected. Depending on the
communication profile, the invocation of this primitive may also imply the connection of other lower layers.
DLMS User Association 2009-12-22 DLMS LEA 1000-2 Ed. 7.0 142/310
C Copyright 1997-2009 DLMS User Association
DLMS User Association. COSEM Architecture and Protocols. Seventh EditIon
The Reason parameter is optional. It may be present only f the value of the Use_RLRQ_RLRE is
TRUE. It is carried by the reason field of the RLRO J RLRE APDU respectively.
When used on the .request primitive, this parameter identifies the general ley& of urgency of the
request. It takes one of the following symbolic values:
• normal:
• urgent (not available in DLMS/COSEM); or
• user defined.
When used on the _response primitive, this parameter identifies information about why the acceptor
accepted or rejected the release request. Note, that in DLMS/COSEM the server cannot reject the
release request. It takes one of the following symbolic values:
• normal;
• not finished: or
• user defined_
NOTE The value "not finished' may he used on the .response primitive when the acceptor is forced to release the
association but wishes to give a warning that it has additional information to send or receive.
The Proposed_xDLMS _ Context parameter is conditional. It is present only if the value of the
Use_RLRQ RLRE is TRUE and the AA to be released has been established with an application
context using ciphering. This option allows securing the COSEM-RELEASE service. and avoiding
thereby a denial-of-service attack that may be carried out by unauthorized releasing of the AA.
In the _request primitive. the Proposed_xDLMS_Context parameter shall be the same as in the
COSEM-OPEN.request service primitive, having established the AA to be released. It is carried by
the xDLMS InitiateRequest APDU. authenticated and encrypted the same way as in the AAR() and
placed in the user-information field of the RLRQ APDU.
If the xDLMS InitiateRequest APDU can be successfully deciphered, then the response primitive shall
carry the same Negotiated_xDLMS_Context parameter as in the COSEM-OPEN,response primitive. It is
carried by the xDLMS InitiateResponse APDU. authenticated and encrypted the same way as in the
AARE and placed in the user-information field of the RLRE APDU.
Otherwise, the RLRQ APDU is silently discarded.
The Local_or_Remote parameter is mandatory. It indicates the origin of the COSEM-

REI„FASE.confirm primitive.
It is set to Remote if either:
• a RLRE APDU has been received from the server: or

• a disconnect confirmation service primitive has been received.
It is set to Local if the primitive has been locally generated_
The Result parameter is mandatory. In the .response primitive. it indicates whether the server AP
can accept the request to release the AA or not. As servers cannot refuse such requests. its value
should normally be SUCCESS unless the AA referenced does not exist.
The Failure_Type parameter is conditional. It is present if Result == ERROR. In this case, it

indicates the reason for the failure. It is a locally generated parameter on the client side.
The User_Information parameter in the .request primitive is optional. If present, it is passed to the
supporting layer, provided it is able to carry it. The .indication primitive contains then the user-
specific information carried by the supporting lower protocol layer(s). Similarly, it is optional in the
.response primitive. If present, it is passed to the supporting layer. In the .confirm primitive, it may
be present only when the service is remotely confirmed. It contains then the user-specific
information carried by the supporting lower protocol layer(s).
The specification of the content of the User_information parameter is not within the scope of this
companion specification. See also 10.
DLMS User Association 2009-12-22 I DLMS UA 1000-2 Ed. 7.0 1431310

DLMS User Association, COSEN1 Architecture and Protocols. Seventh Edition
Use
A possible logical sequence of the COSEM-RELEASE service primitives is illustrated in Figure 67:
• for successful release of a confirmed AA . item a):

• for release of an unconfirmed AA , item b): and
• for an unsuccessful attempt due to a local error item c).
The use of the COSEM-RELEASE service depends on the value of the Use RLRQ RLRE
parameter. When it is invoked with Use_RLRO_FILIRE == TRUE, the service is based on the ACSE
A-RELEASE service. Otherwise. the invocation of the service leads to the disconnection of the
supporting layer.
The .request primitive is invoked by the client AP to request the release of a confirmed or an
unconfirmed AA with a server AP. Upon the reception of the request invocation with
Use_RLRO_RLRE == TRUE. the AL constructs and sends an RLRO APDU to the server.
Otherwise, it sends an XX•DISCONNECT.request primitive (where XX is the supporting lower
protocol layer).
The indication primitive is generated by the server AL if
• a. RLRQ APDU is received. If a deciphering error occurs. the RLRQ APDU is silently discarded (no
.imdication primitive is generated); or
• an XX-DISCONNECT.request is received.
The .response primitive is invoked by the server AP. but only if the AA to be released is confirmed.
Note, that the server AP cannot refuse this request. Upon the reception of the .response service
primitive the server AL :
• sends a RLRE APDU. if the Use RLRO RLRE parameter is TRUE: or

• sends an XX-DISCONNECT.response otherwise.
The .confirm primitive is generated by the client AL to indicate to the client AP whether the
requested release of the AA is accepted or not:
• remotely, when an XX-DISCONNECT.cnf primitive is received. The supporting layer is disconnected: or

• remotely, when a RLRE APDU is received. The supporting layer is not disconnected; or
• locally, upon the expiry of a time-out on waiting for an RLRE APDU: or
• locally, when an RLRQ APDU to release an unconfirmed AA is sent out; or
• locally, when a local error is detected: missing or not correct parameters, or communication failure at
lower protocol layer level etc.
If the RLRE APDU received contains a ciphered xDLMS InitiateResponse APDU but it cannot be
deciphered, then the RLRE APDU shall be discarded. It is left to the client to cope with the
situation.
The protocol for releasing an AA is specified in 9.4.5. Communication profile specific rules are
specified in 10. See also 9.4.2.
9.3.4 The COSEM-ABORT service

Function
The function of the COSEM-ABORT service is to indicate an unsolicited disconnection of the

supporting layer.
Semantics
The COSEM-ABORT service primitives shall provide parameters as shown in Table 22.
Table 22 — Service parameters of the COSEM-ABORT service primitives
.indication

DLMS User Association_ COSEM Architecture and Protocols. Seventh Edition
Diagnostics U
The Diagnostics parameter is optional. It shall indicate the possible reason for the disconnection.
and may carry lower protocol layer dependent information as well. Specification of the contents of
this parameter is not within the scope of this companion specification.
Use
The COSEM-ABORT.indication primitive is locally generated both on the client and on the server
side to indicate to the COSEM AP that a lower layer connection closed in a non-solicited manner.
The origin of such an event can be an external event (for example the physical line is broken), or an
action of a supporting layer connection manager AP. present in some profiles, when the supporting
layer connection is not managed by the COSEM AL. This shall cause the COSEM APs to abort any
existing AAs. except the pre-established ones on the server side.
The protocol for the COSEM-ABORT service is specified in 9_4_5_3.
9.3.5 Security parameters

When ciphering is used. the COSEM data transfer services carry additional security parameters, as
shown in Table 23. These parameters are common for all services.
Table 23— Security parameters
.request .irldiceitIon .response .confirm

Security_Options C C —
Security_Status — i C —
Service parameters depending on the kind of

service:
...
-GET, SET. ACTION: --. -.• -.
-Read. Write. UnconfirmedWrite
Authentication_Tag — C —
NOTE The service primitives available depend on the kind of the service.
The Security_Options parameter is conditional. It shall contain the following information:
• the security control field; see Table 14;

• whether global or dedicated ciphering shall be used (this information determines the tag of the ciphered
APDU).
NOTE The .request and .response service primitives should use the same security suite and the same kind of
ciphering (global cr dedicated),
The Security_Status parameter is conditional_ It shall contain the following information:
• the security control field;

• whether global or dedicated ciphering has been used (this information is derived from the tag of the
ciphered APDU).
The Authentication Tag parameter is conditional. It is present only, if the APDU has been
authenticated or authenticated and encrypted. It carries the authentication tag calculated using the
given security suite and keys.

ti Copyright 1997-2009 DUOS User Association
9.3.6 The GET service

NOTE The following specification of the services using LN referencing haS been amended for a coherent presentation
with that of the services using SN referencing. There are no technical changes introduced.
Function
The GET service is used with LN referencing. It can be invoked in a confirmed or unconfirmed
manner. Its function is to read the value of one or more COSEM interface object attributes. The
result can be delivered in a single response or - it it is too long to fit in a single response - in
multiple responses, with block transfer.
Semantics
The GET service primitives shall provide parameters as shown n Table 24.
Table 24 - Service parameters of the GET service

.request indication .response .confirm
Invoke_Id M M (m) M {.) M {la
Priority M M (-) M {-) M H

Service Class M kii (-) -
Request_Type phi NI (.) - -
U MM2 =MM
COSEM_Attribute_Descriplor C Co - -
{ COSEM_Attributo_Descriptor }
COSEM_Class_Id FAH
COSEM_Objectinstance_ld M (-)
COSEM_Object_Attribute_ld M (-)
Access_$electien_Parameters U (.)
Access Selector M (-)
Accessyarameters M (-)
Bloek_Number C c (-) - -
Response_Type - - M M {.)
Result - - M MH
Get_Dala__Result Get_Data_Result 1 _ S S(-)
-
Data S s (.)
Data_Access_Result S s (.E)
DeteBlock_G - - S SH
Last_Block M M {-)
Block_Number M M {-)
Result M hit (-)
Raw Data S s (-)
Data_Access_Result S S(-)
NOTE For security parameters, see Table 23.
The Invoke_Id parameter identifies the instance of the service invocation.
The Priority parameter indicates the priority level associated to the instance of the service
invocation: normal (FALSE) or high (TRUE).
The Service_Class parameter indicates whether the service is confirmed or unconfirmed. The
handling of this parameter depends on the communication profile. See 10.
The use of the Request_Type and Response_Type parameters is shown in Table 25.
DLMS User Association 1 2009-1 2-22 I DLMS UA 1000-2 Ed. 7.0 11 146/310
© Copyright 1997-2009 DLMS Use Association
Table 25 — GET service request and response types
Request type Response type
The value of a single attribute is NORMAL The complete result is delivered.

NORMAL requested. ONE-BLOCK One block of the result is delivered.
ONE-BLOCK As above.
NEXT The next data block is requested_ The last block of the result is
LAST-BLOCK detivered.
The value of a. list of attributes is WITH-LIST The complete result is delivered-
WITH-LIST ,i requested_
ONE-BLOCK As above.
NOTE The same Response_Type may be present more than once, to show the possible responses to each
kind of request-
equest
The COSEM_Attribute Descriptor parameter references a COSEM object attribute. It is present
when Request Type == NORMAL or WITH-LIST. It is a composite parameter:
• the ( COSEMSlass_ld, COSEM_Object_Instance_ld ) doublet non-ambiguously references one and

only one COSEM object instance;
• the COSEM_Object_Attribute_ld element identifies the attribute(s) of the object instance.
COSEM_Object_Attribute_ld == 0 references all public attributes of the object (attribute_O feature, see
9.1.2.3.10);
• the Access Selection_Parameters is present only when COSEM Object_Attribute Id 1= 0 and if
selective access to the given attribute is available: see 9.1.2.3.9. The Access Selector and
Access_Parameters sub-parameters are defined in the COSEM interface object definitions, see DLMS
UA 1000-1.
A GET-REQUEST-NORMAL service primitive contains a single COSEM attribute descriptor. A GET-
REQUEST-WITH-LIST service primitive contains a list of COSEM attribute descriptors; their number
is limited by the server-max-receive-pdu-size: a GET.request service primitive shall always fit in a
single APDU.
The Block_Number parameter is used in the GET-REQUEST-NEXT service primitive. It carries the
number of the latest data block received correctly.
If the encoded form of the response fits in a single APDU, the Result is of type Get_Data_Result:
• the Data choice carries the value of the attribute at the time of access; or
• the Data Access Result choice carries the reason for the read to fail for this attribute.
A GET-RESPONSE-NORMAL service primitive carries a single Get Data Result parameter. A
GET-RESPONSE-WITH-LIST service primitive carries a list of Get Data Result parameters; their
number and order shall be the same as that of the COSEM Attribute Descriptor parameters in the
request.
If COSEM_Object_Attribute_ld == 0 (Attribute_0), the Data shall be a structure containing the value

of all public attributes in the order of their appearance in the given object specification. For
attributes to which no access right is granted within the given AA, or which cannot be accessed for
any other reason, null-data shall be returned.
If the encoded form of the response does not fit in a single APDU, it can be transported in date
blocks. The Result is of type DataBlock G. It carries block transfer control information and raw-
data:
• the Last_Block element indicates whether the current block is the last one (TRUE) or not (FALSE):
• the Block_Number element carries the number of the actual block sent.
• the (inner) Result element carries either Raw Data or Data Access Result. Within this:
• if the value of a single attribute was requested, Raw_Data carries a part of the value of the attribute
(Data);
NOTE If the Data cannot be delivered, the response should be GET-RESPONSE-NORMAL with
Data_Access_Result_
L ILMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0

Copyright 1997-2009 DIMS User Association
147/310
• if the value of a list of attributes was requested. Raw_Data carries a part of the list of
Get_Data_Results, either Data or Data_Access_Result for each attribute:
• if the raw data cannot be delivered. Data_Access_Result shall carry the reason. For error cases. see
9.4.6.3.
Use
A possible logical sequence of the GET service primitives is illustrated in Figure 67:
• for a successful confirmed GET, item a):

• for an unconfirmed GET item d): and
• for an unsuccessful attempt due to a local error item
The GET.request primitive is invoked by the client AP to read the value of one or all attributes of
one or more COSEM objects of the server AR The first request shall be always of Request_Type
NORMAL or WITH-LIST_ A GET-REQUEST-NEXT service primitive is invoked only when the
server could not deliver the complete data in a single response, i.e. following the reception of a
_confirm primitive of Response_Type ONE-BLOCK_ Upon the reception of the _request primitive,
the client AL builds the Get-Request APDU appropriate for the request type and sends it to the
server.
The GET.indication primitive is generated by the server AL upon the reception of a Get-Request
APDU.
The GET response primitive is invoked by the server AP. if Service__Class == Confirmed, to send a
response to an .indication primitive received. If the complete data requested fits in a single APDU,
the .response primitive is invoked with Response_Type == NORMAL or WITH-LIST as appropriate.
Otherwise, it is invoked with Response_ Type == ONE-BLOCK and finally with LAST-BLOCK.
The GET.confirm primitive is generated by the client AL to indicate the reception of a Get-Response
APDU
The protocol for the GET service is specified in 9.4.6.3.
9.3.7 The SET service

Function
The SET service is used with LN referencing. It can be invoked in a confirmed or unconfirmed
manner. Its function is to write the value of one or more COSEM interface object attributes. The
data to be written can be sent in a single request or - if it is too long to fit in a single request - in
multiple requests, with block transfer.
Semantics
The SET service primitives shall provide parameters as shown in Table 26.
Table 26 - Service parameters of the SET service

Invoke Id M M {.) M cm) M (w)
Priority M M (=.) M (.{ M(=)
Service_Class M M (-) - -
Request_Type M M (.) - -
0 7 77D7 7
0 MMM MM
COSEM_Adribute_Descriptor - -
II
f COSEMAttrilcute_Descriptor I
COSEM_Class_Id
111
COSEM_Ob)ect_instance_id
II
COSEM_Object_Attribute_id
II
Access Selection Parameters

I!
Access_Selector
II
Acess_Pararneters
111
DLMS User Association 1 2009-12-22 DLMS UA 1000-2 Ed. 7.0 I 148/310

Copyright 1997-2009 DLIviS User ASSOCiation
Data {Data I C C {=l
022 2
0 2 2 2
7 7 7 7
DataBlock_SA - -
Last_Block
Block_Number
Raw_Data
Response_Type - - M M (-)
Result { Result } - G C (=)
Block_Number - - G C (=)
NOTE For security parameters. see Table 23.
The Invoke_Id parameter identifies the instance of the service invocation.
The Service Class parameter indicates whether the service is confirmed or unconfirmed. The
handling of this parameter depends on the communication profile, See 10.
The use of the Request_Type and Response Type parameters is shown in Table 27.
Table 27 - SET service request and response types

The reference of a single attribute

NORMAL and the complete data to be written NORMAL The result is delivered.
is sent.
The reference of a single attribute

FIRST-BLOCK and the first block of the data to be
written is sent. The correct reception of the block is
ACK-BLOCK
acknowledged.
One block of the data to be written is
ONE BLOCK
sent.
The cor r ect reception of the last
LAST-BLOCK block is acknowledged and the result
The It block of the data to be is delivered.
LAST-BLOCK
written is sent. The correct reception of the last
LAST-BLOCK-
block is acknowledged and the list of
WITH LIST
-
results is delivered.
The reference of a list of attributes

WITH-LIST and the complete data to be written WITH-LIST The list of results is delivered,
is sent.
FIRST- The reference of a list of attributes
The correct reception at the block is
BLOCK-WITH- and the first block of data to be ACK-BLOCK
acknowledged.
LIST written is sent.
NOTE The same Response_Type may be present me e than once, to show the possible responses to each
request.
The COSEM_Attribute_Descriptor parameter references a COSEM object attribute. It is present

when Request_Type == NORMAL, FIRST-BLOCK, WITH-LIST and FIRST-BLOCK-WITH-LIST. It is
a composite parameter:
• the ( COSEM_Classid. COSEM_Object Instance_ld ) doublet non-ambiguously references one and

only one COSEM object instance:
• the COSEM_Object_Attribute_ld identifies the attribute(s) of the object instance.
COSEM_Object_Attribute Id == 0 references all pubhic attributes of the object (attribute_0 feature. see
9.1.2.3.10):
• the Access_Selection_Parameters is present only when COSEM_Object_Attribute_ld != 0 and if
selective access to the given attribute is available; see 9.1.2.3.9. The Access_Selector and the
Access_Parameters sub-parameters are defined in the COSEM interface object definitions; DLMS UA
1000-1.
1 DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0

149/310
A SET-REQUEST-NORMAL or SET-REQUEST-WITH-FIRST-BLOCK service primitive contains a

single COSEM attribute descriptor. A SET-REQUEST-WITH-LIST or a SET-REQUEST-FIRST-
BLOCK-WITH-LIST service primitive contains a fist of COSEM attribute descriptors; their number is
limited by the server-max-receive-pdu-size! all COSEM attribute descriptors together with a (part
—
of) the data to be written shall fit in a single APDU_

—
The Data parameter contains the data necessary to write the value of the attributes referenced, The
number and the order of the Data parameters shall be the same as that of the
COSEM_Attribute_Descriptor parameters.
If COSEM_Object_Attribute_ld == 0 (Attribute_0), the Data sent shall be a structure, containing, for

each public attribute, in the order of their appearance in the given object specification, either a
value or null-data, meaning that the given attribute need not be set.
If the encoded form of the Data parameter does not fit in a single APDU, it can be transported in
blocks. The DataBlock_SA parameter carries block transfer control information and raw-data:
• the Last_Block element indicates whether the current block is the last one (TRUE) or not (FALSE);
• the Block_Number element carries the number of the actual block sent:
• the Raw_Data element carries a part of the data to be written_
The Result parameters are present in the .response primitive when Response ._Type 1= ACK-
BLOCK. Their number and order shall be the same as that of the COSEM_Attribute_Descriptor
parameters in the request. Each Result shall contain either the success to write or a reason for
failing to write the attribute referenced (Data_Access_Result). When in the .request primitive
COSEM_Object_Attribute_ld == 0 (Attribute_0), the Result shall carry a list of results, either the
success to write or a reason for failing to write the attribute (Data_Access Result), for each public
attribute. in the order of their appearance in the given object specification.
The Block Number parameter shall be present when Response_Type == ACK-BLOCK. LAST-
BLOCK, or LAST-BLOCK-WITH-LIST. It carries the number of the latest data block received
correctly.
Use
A possible logical sequence of the SET service primitives is illustrated in Gren Book Figure 67:
• for a successful confirmed SET. item a):

• for an unconfirmed SET item d): and
The SET request primitive is invoked by the client AP to write the value of one or all attributes of
one or more COSEM objects of the server AP. If the complete data to be sent fits in a single APDU,
the .request primitive shall be invoked with Request_Type == NORMAL or WITH-LIST as
appropriate_ Otherwise. it shall be invoked with Request . Type == FIRST-BLOCK or FIRST-BLOCK-
WITH-LIST, then with Request_Type == ONE-BLOCK and finally with LAST-BLOCK as appropriate.
Upon the reception of the .request primitive, the client AL builds the Set-Request APDU appropriate
for the Request_Type and sends it to the server.
The SET.indication primitive is generated by the server AL upon the reception of a Set-Request
APDU,
The SET.response primitive is invoked by the server AP, if Service_Class == Confirmed. to send a
response to an indication primitive received_ If the data were sent in a single APDU, the _response
primitive is invoked with Response._Type e= NORMAL or WITH-LIST as appropriate_ Otherwise. it is
invoked with Response_Type == ACK-BLOCK, and finally with LAST-BLOCK or LAST-BLOCK-
WITH-LIST as appropriate.
The SET confirm primitive is generated by the client AL to indicate the reception of a Set-Response
APIDU.
The protocol for the SET service is specified in 9.4.6.4.

9.3.8 The ACTION service

Function
The ACTION service is used with LN referencing. It can be invoked in a confirmed or unconfirmed
manner. Its function is to invoke one or more COSEM interface objects methods. It comprises two
•
phases:
• in the first phase, the client sends the reference(s) of the method(s) 10 be invoked, with the method
invocation parameters necessary;
• in the second phase, after invoking the methods, the server sends back the result and the return
parameters generated by the invocation of the method{s), if arty.
If the method invocation parameters are too long to fit in a single request. they are sent in multiple
requests (block transfer from the client to the server). If the result and the return parameters are too
long to fit in a single response, they are returned in multiple responses (block transfer from the
•
server to the client.)
Semantics
The ACTION service primitives shall provide parameters as shown in Table 28.
Tabte 28 - Service parameters of the ACTION service

_request .indication .response .confirm
Invake_ld M M (-) M (m) M (-)

Priority M M (-) M (,) M (=)
Sarvice_Class M M (=) - -
Request_Type M Mm - -
L)72
COS E M Method Descriptor C (=) - -

{ COS EM_Method_Descriptor }
COSEM_Class_Id M (=)
COSEM_Object_Instance _id M (=)
2
COSEM_Object_Method_lcl M (-)
Method Invocation_Parameters U U (-)
f Method_lnvocation_Parameters 1
Response_Type -- M (=-)
22 D
Action_Response I Action_Response } - -
II
Result
II
Response_Parameters
111
Data
11
or)
tr)
Data_Access_Result
II
ccataBtook_SA
L}MMM
IF
II
22
2 2 2
2 Z
Last_Block
II
7 II
Block_Number
II
RavcData
IF
It
Block Number C C (=) G C (m)
NOTE For security parameters. see Table 23.
The Invoke_ld parameter identifies the instance of the service invocation,
The Service_Class parameter indicates whether the service is confirmed or unconfirmed. The
handling of this parameter depends on the communication profile. See 10.
The use of the Request_Type and Response_Type parameters is shown in Table 29.

Table 29 — ACTION service request and response types
The result and the complete return

NORMAL.
The reference of a single method parameter are sent-
NORMAL and the complete method invocation
parameter is sent. One block of the result and of the
ONE-BLOCK
return parameter is sent.
ONE-BLOCK As above_
NEXT The next data block is requested.
The last block of the result(S) and of
LAST-BLOCK
the return parameter(s) is sent.
The reference of a single method

FIRST-BLOCK and the first block of the method
invocation parameters is sent. The correct reception of the block is
NEXT
acknowledged.
One block of the method invocation
ONE-BLOCK
parameters is sent.
The last black of the method NORMAL As above

LAST-BLOCK
invocation parameters is sent. ONE-BLOCK As above.
The complete list of results and

WITH-LIST
The reference of a list of methods return parameters is sent.
WITH-LIST and the complete list 01 method
invocation parameters is sent.
ONE-BLOCK See above.
WITH-LIST- The reference of a list of methods

The Correct reception of the block is
AND-FIRST- and the first bled( at the method NEXT
acknowledged.
BLOCK invocation parameters is sent.
NOTE The same Response_Type may be present more than once, to show the possible responses to each
request.
The COSEM_Method_Descriptor parameter references a COSEM object method. It is present if

Request_Type == NORMAL. FIRST-BLOCK, WITH-LIST and WITH-LIST-AND-FIRST-BLOCK. It is
a composite parameter:
• the ( COSEM Glass Id, COSEM_Object_Instance_Id ) doublet non-ambiguously references one and
only one COSEM object instance:
• the COSEM_Method_Id identifies one method of the COSEM object referenced.
An ACTION-REQUEST-NORMAL or ACTION-REQUEST-FIRST-BLOCK service primitive shall
contain a single COSEM method descriptor. An ACTION-REQUEST-WITH-LIST or ACTION-
REQUEST-WITH-LIST-AND-FIRST-BLOCK service primitive shall contain a list of COSEM method
descriptors: their number is limited by the server-max-receive-pdu-size: all COSEM method
references together with a (part of) the method invocation parameters — shall fit in a single APDI..1.
—
The Method_Invocation_Parameter parameter carries the parameter(s) necessary for the invocation of
the methoci(s), referenced. If the invocation of any of the methods does not require additional
parameters, it shall be nevertheless present, but it shall be null data.
• if Request—Type == NORMAL. the Method Invocation_Parameter parameter is optional:

.
• if Request_Type == WITH-LIST, the service primitive shall contain a list of method invocation
parameters (or null data). The number and the order of the method invocation parameters shall be the
same as that of the COSEM attribute descriptors.
If the encoded form of the COSEM method descriptor(s) and method invocation parameter(s) does
not fit in a single AMU. it can be transported in blocks. The DataBlock_SA parameter carries block
transfer control information and raw-data:

Copyright 1997-2009 DINS User Association
• the Block Number element carries the number of the actual block sent;
• the Raw_Data element carries a part of the method invocation parameters.
The Action_Response parameters are present in the .response primitive when Response_Type
NORMAL. or WITH-LIST. Their number and the order shall be the same as that of the of COSEM
method descriptors. It consists of two elements:
• the Result parameter. It contains either the success to invoke or a reason for failing to invoke the method
referenced (Action-Result);
• the Response_Parameter(s)_ Each response parameter shall contain either the Data returned as a result
of invoking the method, or a reason for returning the parameters to Fail (Data-Access-Result)_ If the
invocation of any of the methods does not return parameters, null data shall be returned_
If the response does not fit in a single APDU. it can be transported in blocks. The DataBlock_SA
parameter carries block transfer control information and raw-data:
• the Block_Number element carries the number of the actual block sent:
• the Raw_Data element carries a part of the response:
• if a single method was invoked. Raw_Data carries the result and the Response_Parameters if
any;
NOTE If no Response_Parameters are returned_ the response should be of type ACTION-RESPONSE-
NORMAL
• if a fist of methods was invoked, Raw_Data carries a part of the list of Action_Responses and
optional data.
The Block_Number parameter in an ACTION-REQUEST-NEXT service primitive shall carry the
number of the latest data block received from the server correctly.
The Block_Number parameter in an ACTION-RESPONSE-NEXT service primitive shall carry the

number of the latest data block received from the client correctly.
Use
A possible logical sequence of the ACTION service primitives is illustrated in Figure 07:
• for a successful confirmed ACTION, item a);

• for an unconfirmed ACTION item d): and
In the first phase. the ACTION.request primitive is invoked by the client AP to invoke one or more
methods of one or more COSEM interface obiects of the server AP. If the complete list of COSEM
method descriptors and method invocation parameters fits in a single APDU. the .request primitive
is invoked with Request Type == NORMAL or WITH-LIST as appropriate. Otherwise, it is invoked
with Request_Type == FIRST-BLOCK or WITH-LIST-AND-FIRST-BLOCK as appropriate. then with
Request_Type == ONE-BLOCK and finally with LAST-BLOCK. Upon the reception of the .request
primitive. the client AL builds the Action-Request APDU appropriate for the Request_Type and
sends it to the server.
The ACTION.indication primitive is generated by the server AL upon the reception of an Action-
Request APDU.
During the block transfer of the method invocation parameters, the server AP invokes the
ACTION.response primitive with Request_Type NEXT until the last block is received.
The ACTION.confirm primitive is generated by the client AL upon the reception of an Action-
Response APDU.
Once all method invocation parameters are transferred, the server invokes the methods of COSEM
interface objects referenced, and the second phase commences_
If the complete response fits in a single APDU. the ACTION.response primitive is invoked by the
server AP with Response_Type == NORMAL or WITH-LIST as appropriate. Otherwise. it is invoked
DLMS User Association 12009-12-22 1 DLMS UA 1000-2 Ed. 7.0 153.'310

ALMS User Association, COSEM Architecture and Protocols. Seventh Edition
with Response_Type == ONE-BLOCK and finally with LAST-BLOCK. Upon the reception of the
.response primitive, the server AL builds the Action-Response APDU appropriate for the
Response_Type and sends it to the client.
The ACTION confirm primitive is generated by the client AL to indicate the reception of an Action-
Response APDLJ.
During the block transfer of the return parameters. the client AP invokes the .request primitive with
Request Type == NEXT until the last block is received.
The protocol for the ACTION service is specified in 9.4.6_5_
9.3.9 The EventNotification service

Function
The EventNotification service is an unsolicited, non-client/server type service. It is requested by the

server, upon the occurrence of an event, in order to inform the client of the value of an attribute, as
though it had been requested by the COSEM. It is an unconfirmed service.
Semantics
The EventNotification service primitives shall provide parameters as shown in Table 30.
Table 30 - Service parameters of the EventNotification service primitives
.request .Indication
Time U U (=)
Application Addresses U Lit-)
COSEM. Attribute__ Descriptor M M
COSEM_Class_ld M M (.11
COSEM_Object_Insiance_id M M (-)
GOSEM_Object_Altribute_ld M
Attribute Value M M
The optional T i me parameter indicates the time at which the EventNotification,request service
primitive was issued.
The Application Addresses parameter is optional. It is present only when the EventNotification
service is invoked outside of an established AA. In this case, it contains all protocol specific
parameters required to identify the sender and destination APs.
When the .request primitive does not contain the optional Application_Addresses parameter, default
addresses shall be used. that of the the server management logical device and the client
management AP. Both APs are always present and in any protocol profile, they are bound to
known, pre-defined addresses.
The (COSEM_Classid, COSEM_Object_Instance_Id, COSEM._Obiect_Attributeid) triplet

references non-ambiguously one and only one attribute of a COSEM interface object instance.
The Attribute_Value parameter carries the value of this attribute. More information about the
notified event may be obtained by interrogating this COSElvt interface object.
Use
A possible logical sequence of the EventNotification service primitives is illustrated in Figure 67 f)

and g).
The .request primitive is invoked by the server AP to send the value of a COSEM interface object
attribute to the remote client AP. Upon the reception of the .request primitive. the Server AL builds
the EventNotificationRequestAPDU.
DLMS User Association 2009-12-22 I DLMS UA 1000-2 Ed. 7.0 154/310

In some cases, the supporting lower layer protocol(s) do (does) not allow sending a protocol data
unit in a real, unsolicited manner. In these cases, the client has to explicitly solicit sending an
EventNotification frame, by invoking the Trigger_EventNotification_Sending service primitive.
The EventNatification.inclication primitive is generated by the client AL upon the reception of an

EventNotificationRequestAPDU.
The protocol for the EventNotification service is specified in 9.4.6.6.
9.3.10 The TriggerEventNotificationSending service

Function
The function of the TriggerEventNotificationSending service is to trigger the server by the client to
send the frame carrying the EventNotification.request APDU.
NOTE This service is necessary in the case of protocols, when the server is not able to send a real non-solicited
EventNotifidation_request APDU-
Semantics
The TriggerEventNotificationSending_request service primitive shall provide parameters as shown in Table

31.
Table 31 — Service parameters of the TriggerEventNotificationSending.request service primitive
.request
Protocol_Parameters M
The Protocol_Parameters parameter contains all lower protocol layer dependent information, which
is required for triggering the server to send out an eventually pending frame containing an
EventNotification.request APDU. This information includes the protocol identifier, and all the
required lower layer parameters.
Use
Upon the reception of a TriggerEventNotificationSending.request service invocation from the client

AP, the client AL shall invoke the corresponding supporting layer service to send a trigger message
to the server.
9.3.11 Variable access specification

Variable Access Specification is a parameter of the xDLMS Read / Write / UncenfirmedWrite
InformationRepart _request / .indication service primitives. Its variants are shown in Table 32:
• Variable_Name identifies a DLMS named variable;

• Parameterized_Access provides the capability to transport additional parameters;
• Block_Number_Access transports a block number;
• Read Data Block_Access transports block transfer control information and raw data;
• Write Data Block Access transports block transfer control information.
The use of the different variants depends on the service and it is described in the respective SN
service specifications.
DLMS User Association 12009-12-22 1DLMS UA 1000-2 Ed. 7.0 II 155/310

Table 32 - Variable Access Specification
Read Write Unconfirmed Information

Variable_Access_Specification
.request .request Write.request Report
kind_Ot_Access M M M M
Var4able_Name S S S M
Detailed Access Not used in DIMS COSEM
Parameterizeci_Access S S S _
Variable_Na me M M M
Selector U U U
Parameter U U U
Block_Nurnber_Access S - -
Block__Number M
Read_Data_Block_Access S
I_ ast_Block M
Block Number M
Raw_ Data M
WrIteDataBlockAccess - S - -
Last_Block M
Block_Number M
9.3.12 The Read service

Function
The Read service is used with SN referencing. It is a confirmed service. Its functions are:
• to read the value of one or more COSEM interface object attributes. In this case, the encoded form of the
.request service primitive shall fit in a single APDU. The result can be delivered in a single response, or —
if it is too long to fit in a single response in multiple responses, with block transfer:
—
• to invoke one or more COSEM interface object methods, when return parameters are expected_ In this
case, if either the .request (including the method references and the method invocation parameters) or
the _response service primitive (including the results and return parameters) is too long to fit in a single
APDU, then block transfer with multiple requests andior responses can be used.
The Read service is specified in IEC 61334-4-41 clause 10.4 and Annex A_ For completeness and
for consistency with the specification of services using LN referencing, the specification is
reproduced here, together with the extensions made for DLMS./COSEM.
Semantics
The Read service primitives shall provide service parameters as shown in Table 33.
Table 33 - Service parameters of 1he Read service
_request .indication .response .confirm

2'Lact:2DD
Variable_Access_Specification M {=)
( Variable_Access_Specification }
Variable_Name S WI
Parameterirecl_Access S =}( _ _
Variable_Name M (.}
Selector U 1,-)
Parameter U (-)
Gr) 2 2 2
Read_Data_Block_Access S f=ll
Last_Block MH
Block_Number M (-}
Raw_Data PA 1(=}
Block_Number_Access S S (-}
Block Number M PA i(w),

t) Copyright 1997-2009 DLMS User Association
.request indication _response .confirm
Result (+) S S (,)
Read_Result { Read_Result } - - M M (=)

Data S S (=)
Data_Access_Error S S (-)
02220
0 2 2 2 0
Data_Block_Result
II
LaSL__Block
II
Block_Number
II
Flaw_Data.
II
Block_Number
II
Result (-) - S S (-}
Error_Type M M (0
NOTE For security parameters, see Table 23
The use of the different variants of the Variable-Access-Specification service parameter of the
Read.request service primitive and the different choices of the Read. response primitive are shown
in Table 34.
Table 34 - Use of the Variable Access_Specitication variants and the Read.response choices
Read.requeat Varlable_Access_SpecificatIon Read response CHOICE
Delivers the value of the

Data {Data}
artribute(s) referenced.
Data_Access_Error Provides the reason for the
Variable Name References a list' of COSEM
(Data_Access_Error) read to fail.
(Variable_Name) object attributes.
Delivers block transfer control
_ _
DataBlockResuli information and one block of
raw data.
Data {Data)
References a list' of COSEM
object attributes to be read -
Data Access Error
-
(Data_Access_Error}
(Data_A
As above.
selectively.
Data_Block_Result
Delivers the method
Parameterized Access invocation return parameters.
{Parameterized _ Access} Data (Data) NOTE If parameters are
References a list' of COSEM returned, this implies that the
object methods, with method method invocation succeeded.
invocation parameters.
Data_Access_Error C Provides the reason for the
(Data_Access_Error) method invocation to fail.
Data_Block_Result As above.
Carries block transfer control
information and one part of
Read_Data_Black_ Carries the number of the
encoded form of the COSEM Block_Number
Access latest data block received.
method references and
method invocation parameters.
Carries the number of the
Blockfiumber_Access DatajEllock_Resull As above.
latest data block received.
NOTE The same Read.Response choice may be present more than once, to show the possible responses to
each request.
' A list may have one or more elements.
The Read.request service primitive may have one or more Variable_Access_Specification

parameters.
• the Variable_Name variant is used to reference a complete COSEM object attribute to be read The
request may include one or more variable names;
• the Parameterized Access variant is used either:
DLMS User Association /2009-12-22 DLMS UA 1000-2 Ed. 7.0 157/310

0. Copyright 1997.2009 DLMS User Association
• to reference a COSEM object attribute to be read selectively. In this case, the Variable_Name
element references the COSEM object attribute. the Selector and the Parameter elements carry the
access selector and the access parameters respectively as specified in the attribute specification; or
• to reference a COSEM object method to be invoked. In this case. the Variable_Name element
references the method. the Selector element is zero and the Parameter element carries the method
invocation parameters (if any) or null data;
• the request may include one or more parameterized access parameters;
NOTE With this, the Read service can transport intormation in both directions. just like the ACTION service used
with LW referencing: method invocation parameters from the client lo the server and return parameters from the
server to the client.
• the Read_Data_Block_Access variant is used when one or more COSEM object methods are
invoked and the encoded form of the request does not fit in a single APDU. The request may
include a single Read_Data_BlocK_Access parameter. It carries block transfer control
information and raw data:
• the Last_Block element indicates if the given block is the last one (TRUE) or not (FALSE);
• the Block Number element carry the number of the actual block sent:
• the Raw Data element carries a part of the encoded form of the list of
Variable Access . Specification parameters (as it would be used without block transfer) including the
method references and the method invocation parameters. Here, only the variants Variable. Name
and Parameterized Access are allowed_
• the Block _Number Access variant is used when the server uses block transfer to send a long
response, to confirm the reception of a data block and to request the next data block. The
request may include a single Block_Number_Access parameter. It carries the number of the
latest data block received correctly.
The Result (+) parameter indicates that the requested service has succeeded.
Without block transfer, the .response 1 .confirm service primitives contain one or more Read Result
parameters. Their number and order shall be the same as that of the Variable Name /
Parameterized_Access parameters in the .request .indication primitives.
If the Read service is used to read attribute(s). then:
• the Data choice is taken to carry the value of the attribute at the time of access:
• the Data_Access_Error is taken to carry the reason for the read to fail for this attribute.
If the Read service is used to invoke method(s), then:
* the Data choice is taken to carry the return parameters (if data are returned, this implies that the method
invocation succeeded);
NOTE If there are no return parameters. Data should be null data. However, if no return data are expected, the
Write service should be used to invoke methods.
• the Data_Access_Error choice is taken to carry the reason for the method invocation to fail for this
method .
In the case of block transfer. the _response I .confirm primitive contains a single Read_Result
parameter_ The Data_Block_Result choice is taken to carry one block of the response:
• the Last_Block element indicates whether the given block is the last one (TRUE) or not (FALSE);
• the Block_Number element shall carry the number of the block sent:
▪ the Raw_Data element contains a part of the encoded form of the list of Read_Ftesutts_
If the data block cannot be provided, then the .response primitive shall carry a single Result
parameter using the Data_Access_Error choice, carrying an appropriate error message: for
example (14) data-block-unavailable.
If the block number in the request is not the one expected. or if the next block cannot be delivered,
then the Read.response service primitive shall be returned with a single Read_Result parameter,
with the choice Data_Access_Error, carrying an appropriate code. for example (19) data-block-
number-invalid.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 158 310
ID Copyright 1997-2009 DLMS User Association
The Block_Number choice is taken when the Read service is used to invoke one or more methods
and the request is sent in several blocks, to confirm the correct reception of a data block and to ask
for the next block. It carries the number of the latest block received.
The Result (—) parameter indicates that the service previously requested failed. The Error_Type
parameter provides the reason for failure. In this case, the server shall send back a
ConfirmedServiceError APDU instead of a ReadResponse APDU.
Use
A possible logical sequence of the Read service primitives is illustrated in Figure 67 item a).
The Read.request primitive is invoked following the invocation of a GET or ACTION .request
primitive by the client AP and mapping this to a Read.request primitive by the SN_MAPPER ASE.
The client AL builds then the ReadRequest APDU and sends it to the server. For LN 1 SN service
mapping, see 9.4.6_6_
The Read.indication primitive is generated by the server AL upon the reception of a ReadRequest
APDU.
The Read.response primitive is invoked by the server AP in order to send a response to a

previously received Read.indication primitive. The server AL builds then the ReadResponse APDU
and sends it to the client.
The Read_confirm primitive is generated by the client AL following the reception of a ReadResponse
APDU. It is mapped then back to a GET or ACTION .confirm primitive by the SN_MAPPER ASE and
the GET or ACTION _confirm primitive is generated.
The protocol of the Read service is specified in 9.4.6.6.
9.3.13 The Write service

Function
The Write service is used with SN referencing. It is a confirmed service. Its functions are:
• to write the value of one or more COSEM interface object attributes;

• to invoke one or more COSEM interface object methods when no return parameters are expected.
In both cases, if the encoded form of the .request service primitive does not fit in a single APDU,
then it can be sent in several requests with block transfer_ The _response service primitive shall
always fit in a single APDU.
The Write service is specified in IEC 61334-4-41 clause 10_5 and Annex A. For completeness and
for consistency with the specification of services using LN referencing, the specification is
reproduced here, together with the extensions made for DLMS/COSEM.
Semantics
The Write service primitives shall provide service parameters as shown in Table 35.
Table 35 - Service parameters of the Write service
.request _Indication .response _confirm
Variable Access_Spe-cification M 164 (e)

I Variable_Access_Specification I
Variable_Narne S S (-)
Pararneterized_Access 5 S (m)
Variable_ Nam e M M (=-)

Selector M hi i=11
Parameter M 'A (.)
Write_Data_Block_Access S S;-)
Last_Block 1.11 M H
DLMS User Association 2009-12-22 DLMS L1A 1000-2 Ed. 7.0 159/310
Copyright 1997-2009DLMS User Association
Block_Number IA t41 {0
Data I Data ) PA #A (-) - -
Result (+) - - S S (=)
tf)uracirl.
Write_Result 1 Write_Result ) - - SH
Successs S (=)
❑ ata_Access_Error S H
Block_Number S ( =)
Result (-) S S (=)

Error_Type M M (.)
Write.request service primitive and the different choices of the Write.response primitive are shown
in Table 36. The use of the Data service parameter is also explained.
Table 36 - Use of the Vanable_Access_Specification variants and the Write.response choices
Wrlte.request Varlable_Access_SpecilicatIon WrIte.response CHOICE
References a list' of COSEM Indicates that the attribute

object attributes. Success {Success) referenced could be
Variable_Name The Data service parameter successfully written.
(Varlable_Name) carries the data to be written
Or the method invocation Data_Access_Error Provides the reason for the
parameter(s). {Data_Access_Error) write to fall..
References a a list' of Success {Success}

COSEM object attributes 10
Pararneter[zed Access be written selectively_
1Parameterized_ACCOSS} _
Data Access Error As above.
The Data service parameter {Data_Access_Error)
carries the data to be written.
Carries block transfer control
information_
The Data service parameter
carries raw-data. including
the encoded form of the list. Carnes ihe number of the
Write_Data_Block_Access Block_Number
of COSEM object attribute or West data block received.
method references, and the
list of data to be written or the
list of method invocation
parameters.
NOTE The same WrIte.Response choice may be present more than once, to show the possible responses to
each request.
1 A list may have one or more elements.
The Write.request service primitive may have one or more Variable Access Specification
parameters
• the Variable_Name variant is used to reference a complete COSEM object attribute to be written or
COSEM object method to be invoked. The request may include one or more variable names;
• the Parameterized_Access variant is used to reference a COSEM object attribute to be written
selectively. In this case. the Variable_Name element references the COSEM object attribute. the
Selector and the Parameter elements carry the access selector and the access parameters respectively
as specified in the attribute specification. The request may include one or more Parameterized_Access
parameters;
The Data service parameter carries the value(s) to be written to the attribute(s), or the method
invocation parameter{s) of the method(s) to be invoked. The number and the order of the Data
parameters shall be the same as that of the Variable Access_Specification parameters.
If the Write.request service primitive does not fit into a s i ngle APDU, block transfer may be used. In
this case:
• the Write_Data_Block_Access variant of the Variable_Access_Specification carries block transfer control

information:
0 Copyright 1997-2009 DLMS User Asscir; anon
DUOS User Association. COSEM Architecture and Protocols. Seventh Edition
• the Last_Block element indicates whether the given block is the last one (TRUE) or not (FALSE);
• the Block_Number element carry the number of the actual block sent;
• the Data parameter carries one part of the list of the attribute references and the list of data to be written,
or one part of the list of method references and the list of method invocation parameters.
• The request includes a single Write_Data_Blcok_Access and a single Data parameter.
The Result (+) parameter indicates that the service requested has succeeded.
The _response l .confirm service primitives contain a list of Write_Result parameters. Their number
and order shall be the same as that of the Variable_Name Parameterized_Access parameters in
the .request _indication service primitives_
Without block transfer, and with block transfer after receiving the last block:
• when the Write service is used to write attribute(s), each element carries either the success of the write
access (Success) or a reason for the write to fail for this variable (Data._ Access__ Error);
• when the Write service is used to invoke method(s), each element carries either the success of the
method invocation access (Success) or a reason for the method invocation to fail for this variable
( Data_Access_Error)_
The Block_Number choice is used during block transfer to confirm the correct reception of a data
block and to ask for the next block_ It carries the number of the latest block received_
If the block-number in the request is not the one expected. or if the block could not be received
correctly. then the Write.response service primitive shall be returned with a single Write_Result
parameter, with the choice Data_Access_Error, carrying an appropriate code, for example (19)
data-block-number-Invalid
The Result (—) parameter indicates that the service requested has tailed. The Error_Type parameter
provides the reason for failure. In this case. the server shall send back a ConfirmedServiceError
APDU instead of a WriteResponse APDU.
Use
A possible logical sequence of the Write service primitives is illustrated in Figure 67 item a).
The Write.request primitive is invoked following the invocation of a SET or ACTION .request
primitive by the client AP and mapping this to a Write.request primitive by the SN_MAPPER ASE.
The client AL builds then the WriteRequest APDU and sends it to the server. For LN / SN service
mapping, see 9.4.6.8.
The Write.indication primitive is generated by the server AL upon the reception of a WriteRequest
APDU.
The Write.response primitive is invoked by the server AF' in order to send a response to a
previously received Write.indication primitive. The server AL builds then the VVriteResponse APDU
and sends it to the client.
The Write.confirm primitive is generated by the client AL following the reception of a WriteResponse
APDU_ It is mapped then back to a SET or ACTION _confirm primitive by the SN MAPPER ASE and
the SET or ACTION _confirm primitive is generated.
The protocol of the Write service is specified in 9.4.6.8.
9.3.14 The UnconfirmedWrite service

Function
The UnconfirmedWrite service is used with SN referencing. It is an unconfirmed service. Its

functions are :
• to write the value of one or more COSEM object attributes:

• to invoke one or more COSEM interface object method when no return parameters are expected.
The UnconfirmedWrite.request service primitive shall always fit in a single APDU.
© Copyright 1997-20D9 MIAS User Association
The UnconfirmedWrite service is specified in IEC 61334-4-41 clause 10.6 and Annex A. For
completeness and for consistency with the specification of services using LN referencing, the
specification is reproduced here, together with the extensions made for DLIvISICOSElvl.
Semantics
The UnconfirmedWrite service primitives shall provide service parameters as shown in Table 37.
Table 37 — Service parameters of the UnconfirrnedWrite service
_request indication
2 of) 0 2 2 2
Variable_Access_Specification M(.)
1 Variable_Access_Specification I
Variable_Name S (-)
Parameterized_Access S (-)
Variabte_Name M (-)
SeleCiOr M (=-)
Parameter M (z)
Data ( Data) M MH
Unconfirmed\Nrite,request service primitive is shown in Table 38. The use of the Data service
parameter is also explained.
Tabte 38 - Use of the Vanable_Access_Specification variants
UnconfirmedWrite,request Varlabla_Access_Specification
References a COSEM object attribute,
Variable_Name
(Variable.Name} The Data service parameter carries the data to be
written or the method invocation parameter(s).
References a COSEM objeC1 attribute with selective

access.
Paramelerized_Access iParameterized_Access)
The Data service parameter carries the data to be
written.
The UnconfirmedWrite.request service primitive may have one or more

Variable_Access_Specification parameters.
9 the Variable_Name variant is used to reference a complete COSEM object attribute to be written or
COSEM object method to be invoked;
• the Pararneterized_Access variant is used to reference a COSEM object attribute to be written
selectively. In this case. the Variable_Name element references the COSEM object attribute, the
Selector and the Parameter elements carry the access selector and the access parameters respectively
as specified in the attribute specification.
The Data service parameter carries the value(s) to be written to the attribute(s), or the method
invocation pararneter(s) of the method(s) to be invoked. The number and the order of the Data
parameters shall be the same as that of the Variable_Access_Specification parameters.
Use
A possible logical sequence of the Write service primitives is illustrated in Figure 67 item el).
The UnconfirmedWrite.request primitive is invoked following the invocation of a SET or ACTION

.request primitive with Service Class =. Unconfirmed by the client AP and mapping this to an
UnconfirmedWrite.request primitive by the SN_MAPPER ASE. The client AL builds then the
UnconfirmedWriteRequest APDU and sends it to the server.
The UnconfirmedWrite.indication primitive is generated by the server AL upon the reception of a

WriteRequest APDU.
The protocol of the UnconfirmedWrite service is specified in 9 4 6 9.

❑
Copyaght 1997-21)09 DLMS User Association
9.3.15 The InformationReport service

Function
The InformationReport service is an unsolicited, non-client/server type service. It is requested by a

server using SN referencing, upon the occurrence of an event, in order to inform the client of the
value of one or more DLMS named variables — mapped to COSEM interface object attributes — as
though they had been requested by the client. It is an unconfirmed service.
The InformationReport service is specified in IEC 61334-4-41 10.7 and Annex A. For completeness
and for consistency with the specification of services using LN referencing, the specification of the
InformationReport service is reproduced here, together with the extensions made for
❑ LMS/COSEM_
Semantics
The InformationReport service primitives shall provide parameters as shown in Table 39.
Table 39 — Service parameters of the InformationReport service
.request indication
Current_Time M M (.)
Variable_Access_Specitication M M (-)
( Variable_Access_Specitication }
Variable_Name M M (m)
Data ( Data } M h1(=)
The Current_Time parameter indicates the time at which the InformationReport.request service
primitive was issued.
The Variable_Access_Specification parameter of choice Variable_Name specifies one or more

DLMS named variables — mapped to COSEM interface object attributes — the value of which is sent
by the server.
The Data parameter carries the value of the DLMS named variable(s), in the same order as the
order of the Variable_Access_Specification parameter(s).
The protocol for the InformationReport service is specified in 9_4_6_10.
9.3.16 Client side layer management services: the

SetMapperTable.request
Function
The function of the SetMapperTable service is to manage the client SN_MAPPER ASE.
Semantics
There is only one primitive, the .request primitive. It shall provide parameters as follows:
Table 40 - Service parameters at the SetMapperTable.request service primitives
_request
Mapoing_Table M
The Mapping_table parameter is mandatory. It contains the contents of the attribute "object_list" for
the requested server and AA. The structure of the content is defined in DLMS UA 1000-1.

i1D Copyright 1997-2009 DLMS User Association
Use
The SetMapperahle.request service is invoked by the client AP to provide mapping information to

the client SN MAPPER ASE. This service does not cause any data transmission between the client
and the server. The client AP uses this service primitive. in order to enhance the efficiency of the
mapping process if SN referencing is used.
9.3.17 Summary of services and LN/SN data transfer service mapping

The following tables provide a sk.imrnary 01 the COSEM application layer services .
Table 41 — Summary of ACSE services
Client side Server side
COSEM-OPEN.request COSEM-OPEN.indication
COSEM-OPEN,confirm COSEM-OPEN response

COSENI , RELEASE.request COSEM-RELEASE. indication
COSENI•R E LEASEconfirm COSEM-RELEASE.response
COSEM-ABORT`-indication
I COSEM-ABORT.indication
Table 42 — Summary of xDLMS services for LN referencing
Client aide Server side

GET request GET.indication
GET.confirm GET.response
SET.request SET.indication
SET.contirm SET.response
ACTION request ACTiON.indication
ACTION confirm ACTION.response
EventNotification.indication EventNolification.reouest
Trigger_EveniNotilication_Sending.request —
Table 43 — Summary of xDLMS services for SN referencing
Client side Server side

Read.request Read.indication
Read.confirrn Read.response
Write.request Writeindication
Write.confirm Write. response

UncontirmeclWritesequest UnconfirmedWriteindication
InformationReport.indication informationReport.request
When the server uses SN referencing, a mapping between the service primitives using LN
referencing and SN referencing takes place on the client side. This mapping is specified in clauses
9.4.6.7 : 9.4.6.8. 9.4.6_9 and 9.4.6.10.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 1 1641310

9.4 COSEM application layer protocol specification

9.4.1 The control function
9.4.1.1 State definitions of the client side control function
Figure 68 shows the state machine for the client side CF. see Figure 60.
Trigger_EventNotitcation_sertzlivieq
EventNotikationind
INACTIVE
OP EN,req
ASSOCIATION
PENDING
/ABORT.Ind
JOPEN.cnt(OK) ASSOCIATED RELEASE.req
GE-r.req
SET.req ..`SET.enf
ACTION.req /ACTION.cnt
lEventNolificarion.ind
NOTE On the state diagrams at the client and server CF. the following conventions are used:
- service primitives with no -/' character as first character are 'stimulants': the invocation of these primitives is the
origin of the state transition;
- service primitives with an "r character as first character are 'outputs": the generation of these primitives is done on
the state transition path.
Figure 68 - Partial state machine for the client side oontrol function
The state definitions of the client CF - and of the AL including the CF — are as follows:
INACTIVE In this state, the CF has no activity at all: it neither provides services to the AP nor uses services of the
supporting protocol layer.
IDLE This is the state at the CF when there is no AA existing, being released, or being established
Nevertheless, some data exchange between the client and server - if the physical channel is already
established - is possible. The CF can handle the Even1Notification service.
NOTE State transitions between the INACTFVE and IDLE states are controlled outside of the protocol_
For example, it can be considered that the CF makes the state transition from INACTIVE to IDLE by
being instantiated and bound on the top of the supporting protocol layer. The opposite transition may
happen by deleting the given instance of the CF_
ASSOCIATION The CF leaves the IDLE state and enters this state when the AP requests the establishment of an AA by
PENDING invoking the COSEM-OPEN.request primitive tOPEN.req). The CF may exit this state and enter either
the ASSOCIATED state Of return to the IDLE state, and generates the COSEM-OPEN.conlirm primitive,
(IOPEN.cnf(OK)) or (LOPEN.cnt{NOK)), depending on the result of the association request. The CF also
exits this state and returns to the IDLE state with generating the COSEM-ABORT, indication primitive
(IADORT.ind).
ASSOCIATED The CF enters this state when the AA has been successfully established. The client/server type data
" Note, that it is the state machine for the AL: lower layer connections, including the physical connection, are not taken into account. On
the other hand, physical connection establishment is done outside of the protocol_
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 I 165/310
el Copyright 1997-2009 DLMS User Association
DENS User Association. COSEM Architecture and Protocols. Seventh Edition
services are available in this state, and the EventNotification service can be handled. The CF remains in
this state until the AP requests the release of the AA by invoking the COSEM-RELEASE-request
primitive (RELEASE_req). The CF also exits this state and returns to the IDLE state with generating the
COSEM-ABORT.indication primitive (:ABORT Ind)- -
ASSOCIATION The CF leaves the ASSOCIATED state and enters this state when the AP requests the release of the AA
RELEASE by invoking the COSEM-RELEASE.request primitive (RELEASE.req), The CF remains in this stale.
PENDING wailing for the response to tres request from the server_ As the server is not allowed to refuse a release
request. after exiting this state, the CF always enters the IDLE state. The CF may exit this state by
generating the COSEM RELEASE. confirm primitive Wowing the reception of a response Form the server
-
or by generating it locally CRELEASE.crit). The CF also exits this state and returns to the IDLE state
with generating the COSEM-ABORT.indication primitive (IABORT.ind).
9.4.1.2 State definitions of the server side control function

Figure 69 shows the state machine for the server side CF. see Figure 60.
INACTIVE EvemNob .hcamn.mq

or
Inforrnalron Report req
IDLE
ABORT and
OPEN tr,$(0k)
iFtELEASE.End
ASSOCiATED
GET.res (READ.iriel READ .res

isET.ind sET.res rWRiTE.ini WRITE .re$
.+ACTION.ints ACTON.teS rUNCONetRIvtee WFuTe.ind
EventNctification.req Inform ationReport.req
or
Figure 69 — Partial state machine for the server side control function
INACTIVE In this state, the CF has no activity at all it neither provides services to the AP nor uses services of the
supporting protocol layer_
IDLE This is the state of the CF when there is no AA existing, being released, or being established
Nevertheless. some data exchange between the client and server - if the physical channel is already
established - is possible. The CF can handle the EventNotification / InformationReporl services.
ASSOCIATION The CF leaves the IDLE stale and enters this state when the client requests the establishment of an AA,
PENDING and the server AL generates the COSEM-OPEN-indication primitive (10PEN.ind). The CF may exit this
slate and enter either the ASSOCIATED state or return to the IDLE state, depending on the result of the
association request, and invokes the COSEM•OPEN.respoose primitive. VOPEN.res(Ok)l or
tiOPEN.res(NOK)0. The CF also exits this state and returns to the IDLE state with generating the
COSEM-ABORT.indication primitive VABORT.ind).
ASSOCIATED The CF enters this state when the AA has been successfully established_ The clientiserver type data
services are available in this state, and the EventNotification J InformationReport services can be
handled. The CF remains in this state until the client requests the release of the AA. and the server AL
generates the COSEM-RELEASEind primitive URELEASE.ind)_ The CF also exits this stale and returns
to the IDLE state with generating the COSEM-ABORT.indication primitive VABORT.ind).
ASSOCIATION The CF leaves the ASSOCIATED stale and enters this state when the client request the release of an
RELEASE AA, and the server AP receives the COSEM•RELEASE.indication primitive (iFIELEASE.ind). The CF
PENDING remains in this state. waiting that the AP accepts the release request. As the server is not allowed lo
refuse a release request. alter exiting this state. the CF always enters the IDLE state. The CF may exit
this state when the AP accepts the release of the AA_ and invokes the COSEM•RELEASE.response
primitive (RELEASE.res). The CF also exits this state and returns to the IDLE state with generating the
DLMS User Association 2009 - 12 - 22 I DLMS UA 1000-2 Ed, 7.0 11 166/310

COSEM-ARORT.indicatior primitive cABORT_Hd).
9.4.2 The ACSE services and APDUs

9.4.2.1 ACSE functional units, services and service parameters
The COSEM AL ACSE is based on the connection-oriented ACSE. as specified in ISO/IEC 8649
and ISO/IEC 8650-1.
Functional units are used to negotiate ACSE user requirements during association establishment.
Three functional units are defined:
• Kernel functional unit;
• Authentication functional unit; and
• Application Context Negotiation functional unit-
The COSEM AL uses only the Kernel and the Authentication functional unit.
The acse-requirements parameters of the AARQ and AARE APDUs are used to select the functional
units for the association.
The Kernel functional unit is always available. It is the default functional unit. To be included, the
Authentication functional unit shall be explicitly requested on the AARQ APDU and accepted on the
AARE APDU.
The selection of the Authentication functional unit supports additional parameters on the AARQ and
AARE APDUs. The Authentication functional unit does not affect the elements of procedure. Table
44 shows the services and parameters associated with the ACSE functional units, as used by the
COSEM AL. The abstract syntax of the ACSE APDUs is specified in 9.5.
Tabie 44 - ACSE functional units. services and service parameters
Functional Service APDU parameter Presence

Unit
Kernel A-ASSOCIATE AAR() protocol-version

application-context-name
called-AP•title
DD D, D DDC11
called-AE-qualifier
called-AP-invocation-identifier
called-AE-invocation-identifier
calling-AP-title
calling-AE-qualifier
calling-AP-invocation-identifier
calling-AE-invocation-identifier
implementation-Information
user-information 21
(carrying an xDLMS-Initiate.request APDU)
dedicated-key
response-allowed
proposed-quality-of-service
proposed-dims-version-number
proposed-conformance
client-max-receive-pdu-size
OM2 2 D DDOM
AARE protocol-version
application-context-name
result
result-Source-diagnostic
responding-AP-title
responding-AE-qualifier
responding-AP-invocation.idenlifier
responding-AE-invocation-identifier
implementation-information
user-information 21
DLMS User Association 2009-12-22 DLMS LIA 1000-2 Ed. 7.0 167/310
DLMS User Association, COSEM Architecture and Protocols. Seventh edition
Functional Service APDU parameter Presence

Unit
(carrying an xDLMS-initiate-response AMU) S
negotiated-quality-ot-service U
negotiated•dlins-version-number M
negotiated-conformance M
server-max-receive-pOu-size M
vaa-name M
(or carrying a ConfirmedServiceError APDU} S
A-RELEASE FILRO reason U
user-information U
RLRE reason U
user•information U
Authentication A-ASSOCIATE AARQ sender-acse-requirements U
mechanism-name U
calling-authentication-value U
AARE responder•acse-requirements U
mechanism-name U
responding-authentication-value U
NOTE 1 0: Presence is an ACPM {COSEM Application layer) option.
NOTE 2) According to ISO/IEC 8649. the user-intormation parameter is optional. However, in the COSEtvl
environment it is mandatory in the AARO , AARE APIDUs.
In general, the value of each parameter of the AARQ APDU is determined by the parameters of the
COSEM-OPEN.request service primitive. Similarly, the value if each parameter of the AARE i5
determined by the COSEM-OPEN.response primitive. The COSEM-OPEN service is specified in
9.3.2.
The AARO❑ and AARE APDU parameters are specified below_ Managing these parameters is
specified in 9_4.4.1.
• protocol-version: the COSEM AL uses the default value. For details, see ISO/IEC 8650-1:
• application-context-name: COSEM application context names are specified in 9_4_2.2,2:
• called-, calling- and responding- titles, qualifiers and invocation-identifiers: these optional fields
carry the value of the respective parameters of the COSEM-OPEN service_ For details, see ISO/IEC
8650-1;
• implementation-information: this parameter is not used by the COSEM AL. For details, see ISO/IEC
8650-1;
• user-information: in the AARQ APDU, it carries an xDLMS InitiateRequest APDU holding the elements
of the Proposed_xDLMS_Context parameter of the COSEM-OPEN,request service primitive. in the
AARE APDU, it carries an xDLMS InitiateResponse APDU. holding the elements of the
Negotiated_xDLIMS_Context parameter. or an xDLMS ConfirmedServiceError APDU, holding the
elements of the xDLMS_Iniliate_Error parameter of the COSEM-OPEN. response service pimitive.
• sender- and responder-acse-requirements: this parameter is used to select the optional functional
units of the AARQ / AARE. In COSEM. only the Authentication functional unit is used. When present, it
carries the value of BIT STRING { authentication (0) ). Bit set: authentication module selected;
• mechanism-name: COSEM authentication mechanism names are specified in 9.4.2,2.3;
• calling - and responding- authentication-value: see 9,2.3:
• result: the value of this parameter is determined by the COSEM AP {acceptor) or the COSEM AL
(ACPM) as specified below. It is used to determine the value of the Result parameter of the COSEM-
OPEN.confirm primitive:
• if the AARQ APDU is rejected by the ACPM (i.e. the COSEM-OPEN-indication primitive is not issued
by the COSEM AL), the value "rejected {permanent" or - rejected (transient)" is assigned by the
ACPM;
• otherwise, the value is determined by the Result parameter of the COSEM-OPEN.response APDU:
• result-source-diagnostic: this parameter contains both the Result source value and the Diagnostic value.
It is used to determine the value of the Failure_Type parameter of the COSEM-OPEN.confirm primitive:

• Result-source value: if the AARQ is rejected by the ACPM, (i.e. the COSEM-OPEN.inclication
primitive is not issued by the COSEM AL) the ACPM assigns the value -ACSE service-provider,
Otherwise, the ACPM assigns the value "ACSE service-user";
• Diagnostic value: If the AARQ is rejected by the ACPM, the appropriate value is assigned by the
ACPM. Otherwise, the value is determined by the Failure Type parameter of the COSEM-
OPEN.response primitive. If the Diagnostic parameter is not included in the .response primitive, the
ACPM assigns the value "nulr.
The parameters of the RLRC 1 RLRE APDUs — used when the COSEM-RELEASE service (see
9_3.3) is invoked with the parameter Use RLRO_RLRE == TRUE — are specified below.
• reason: carries the appropriate value as specified in 9.3.3;

▪ user-information: if present, it carries an xDLMS InitiateRequest 1 InitiateResponse APDU, holding the
elements of the Proposecl_xDLMS_Context 1 Negotiated_XDLMS_Context parameter of the COSEM-
RELEASE.reguest f .response service primitive respectively_ See 9.3.3.
9.4.2.2 Registered COSEM names

9.4.2.2.1 General
Within an OSI environment, many different types of network objects must be identified with globally
unambiguous names. These network objects include abstract syntaxes, transfer syntaxes.
application contexts, authentication mechanism names, etc. Names for these objects in most eases
are assigned by the committee developing the particular basic ISO standard or by implementers'
workshops, and should be registered. For DLMS/COSEM, these object names are assigned by the
DLMS User Association, and are specified below.
The decision no. 1999_01846 of OFCOM, Switzerland, attributes the following prefix for object
identifiers specified by the DLMS User Association_
joint iso ccitt(2) country(16) country name(756) identified organisation(5) DLMS UA(8)
- - - - -
For DLMS/COSEM, object identifiers are specified for naming the following items:
• COSEM application context names;

• COSEM authentication mechanism names_
9.4.2.2.2 The COSEM application context
In order to effectively exchange information within an AA, the pair of AE-invocations shall be
mutually aware of, and follow a common set of rules that govern the exchange. This common set of
rules is called the application context of the AA. The application context that applies to an AA is
determined during its establishment 29 . The following methods may be used:
• identifying a pre-existing application context definition;

• transferring an actual description of the application context.
In the COSEM environment, it is intended that an application context pre-exists and it is referenced
by its name during the establishment of an AA. The application context name is specified as
OBJECT IDENTIFIER ASN.1 type. COSEM identifies the application context name by the following
object identifier value:
COSEM_Application_Context_Narne ::-
{joint-iso-ccitt(2) country(16} country-name(756) identified-organisation(5) DLMS-UA(8) application-context(1)
context_id(x))
The meaning of this general COSEM application contexts is:
2g An AA has only one application context. However, the set at rules that make up the application context of an AA may contain rules for
alteration of that set of rules during the lifetime of the AA.

• there are two ASEs present within the AE invocation, the ACSE and the xDLMS ASE;
• the xDLMS_ASE is as it is specified in IEC 61334-4-41 31:1 ;
• the transfer syntax is A-XDR.
The specific context_ids and the use of ciphered and unciphered APDUs is shown in Table 45
below:
Table 45 - Use of ciphered / unciphered APDUs
Application context name context_id Unciphered Ciphered

ADPUs APDUs
Logical_Name_Referencing_tio_Ciphering ::m context_id(1) Yes No
$hort_Neme _Fleterencing_No_Ciphering ::z context_id(2) Yes No
Logicaifiarne_Heterenon_With_Ciphering ::. context_id(3) Yes Yes

Short_Name_Reterencinia_With_Ciphering := context_id(4) Yes Yes
In order to successfully establish an AA, the application-context-name parameter 0 the AARQ and
AARE APDUs should carry one of the "valid" names. The client proposes an application context
name using the Application_Context_Name parameter of the COSEM-OPEN.request primitive. The
server may return any value; either the value proposed or the value it supports.
9.4.2.2.3 The COSEM authentication mechanism name

Authentication of the client, the server or both is one of the security aspects addressed by the
DLMS/COSEM specification. Three authentication security levels are specified:
• no authentication (lowest level) security:

• low level, password based authentication security (LLS) identifying only the client:
• high level, four-pass authentication security (HLS) identifying both the client and the server.
COSEM identifies the authentication mechanisms by the following general object identifier value:
COSEM_AuthenticationiAlechanism_Name ::=
(joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8)
aulhenticatIon_mechanism_name(2) mechanism_id(x))
The value of the mechanism_id element selects one of the security mechanisms specified:
COSEM_lowest_level_securily_mechanism_name ::= mechanism_id(0)

COSEM_tow_tevel_security_mechanism_name ::= mechanism_id(1)
COSEM_high_levei_security_mechanism_name ::= mechanism_id(2)
COSEM_high_level_seourity_meohanism_name_using_MD5 ::= mechanism_id(3)
COSEM_high_Ievel_security_mechanism_name_using_SHA-1 ::= mechan i sm_id(4)
COSEM_High_Level_Security_klechanisrh_Name_Using_GMAC ::= mechanism_id(5)
NOTE With mechanism_id(2), the method of processing the challenge is secret.
When the Authentication Mechanism_Name is present in the COSEM-OPEN service, the

authentication functional unit of the A-RELEASE service shall be selected. The process of LLS and
HLS authentication is described in 9.2.3 and 9.2.4.8.4.
9.4.3 APDU encoding rules

The ACSE APDUs shall be encoded in BEF1 (ISO/IEC 8825). The user information parameter of -
these APDUs shall carry the xDLMS InitiateReguest InitiateResponse ContirrnedServiceError

APDU as appropriate, encoded in A-XDR, and then encoding the resulting OCTET STRING in BE R_
Examples for AARCUAARE APDU encoding are given in 11 and in 12.
1° With the COSEM extensions to DLMS, see 9.1.2.3.1

' Copyright 1997-2009 DLMS User Association
9.4.4 Protocol for application association establishment

9.4.4.1 Protocol for the establishment of confirmed application associations
AA establishment using the A-Associate service of the ACSE is the key element of COSEM
interoperability. The participants of an AA are:
• a client AP. proposing AAs; and

• a server AP 2r accepting them or not.
Figure 70 gives the MSC for the case, when:
• the COSEM-OPEN.request primitive requests a confirmed AA:

• the connection of the supporting lower layers is required for the establishment of this AA_
A client AP that desires to establish a confirmed AA. invokes the COSEM-OPEN.request primitive of
the ASO with Service_Class == Confirmed. The response-allowed parameter of the xDLMS
InitiateRequest APDU is set to TRUE. The client AL waits for an AARE APDU, prior to generating
the .confirm primitive. with a positive — or negative — result.
The client CF enters the ASSOCIATION PENDING state_ It examines then the
Protocol_Connection_Parameters parameter_ If this indicates that the establishment of the
supporting layer connection is required, it establishes the connection 32 The CF assembles then —.
with the help of the xDLMS ASE and the ACSE — the AARQ APDU containing the parameters of the
COSEM-OPEN.request primitive received from the AP and sends it to the server.
The CF of the server AL gives the AARQ APDU received to the ACSE. It extracts the ACSE related
parameters then gives back the control to the CF. The CF passes then the contents of the user-
information parameter of the AARQ APDU — carrying an xDLMS InitiateRequest APDU — to the
xDLMS_ASE. it retrieves the parameters of this APDU. then gives back the control to the CF. The
CF generates the COSEM-OPEN.indication to the server AP with the parameters received APDU 33
and enters the - ASSOCIATION PENDING' state.
NOTE The ASEs only extract the parameters: their interpretation and the decision whether the proposed AA can be
accepted or not is the job of the server AP.
To support multicast and broadcast services. an AA can also be established between a client AP and a group of server APs.
ax
The PH layer must be connected before the COSEM-OPEN ser=e is invoked_
Some service parameters of the COSEM-OPEN.indication primitive (address information. User_Inforrnation) do not come
from the AAXO but from the supporting layer frame carrying the AARO APOLII. In some communication profiles. the
Service_Glass parameter of the GOSEM•OPEN service is linked to the frame type of the supporting layer. In some other
communication profiles. it is linked to the response-allowed field of the xDLMS•Initiate.request AFOUL See also 10.
DLMS User Association 2009-12-22 1 DLMS UA 1000-2 Ed. 7.0 171/310

Client Client Server Server

Client Client Client AL supporting supporting AL Server Server Server
AP AL CF AL ACSE x DLMS Protocol Protocol xaMS AL ACSE AL CF AP
ASE Layer (XX) Layer {XX) ASE
Physical connection is established {outside the protocol)
Client AL CF is in Server AL CF is in
IDLE State IDLE State
COSEM-
OPEN.req" Establishing
the Supporting
Client AL CF is in
Layer
ASSOCIATION PENDING State
connection
XX-CONNECT,req _EatabliShing
► XX.CONNECT ind
Lower raVe " 111
connections 4 Xx-CONNECT res
XX CONNECT.cnt
The Supporting Layer connection is established

iDLMS-Initiate
Budd InniateRequest7
initiateRequest APDU APDU
A-ASSOCIATE req
AARO APDU Build AARO APDU
X X- DATA.req (AARO)
XX-DATA.ind (AARO) ►
AARO APDL1
Extract A•ASSOC1ATE Inc
parameters
A ASSOCIATE And
indiateRequest APDU
•
Extract InilialeRequest
APOU parameters i xDLIVIS•lnitiate Ind
tOSEM-OPEN.ind
Server Al_ CF is in
ASSOCIATION PENDING stale
COSEM-OPEN res
iDLMS Initiate res

Build inolateResponse
APDU InitiateResponse APDU
A-ASSOCIATE res
.4F--
BuIPC1 AARE APDU
AARE APDU
Server AL CF is in
ASSOCIATED state
XX DATA req (AARE)

XXiDATA Ind (AARE)
AARE APDU
Set Application Context

A- SSOCIATE.cril
InmateRes nse APDU
Set DLMS Context
xDLMS-Initiate cnt
Client AL CF is in
ASSOCIATED stale
The requested AA is successlully established

C • EMOPEN.cnf (OK)
Figure 70 — MSC for successful AA establishment preceded by a successful lower layer connection establishment

Gil Copyright 1997-2009 DLMS User Association
The server AP parses the fields of the AARO APDU as described below.
Fields of the Kernel functional unit:
• application-context-name: it carries the COSEM_Application_Context_Narne the client proposes for the

association:
• calling-AP-title; when the proposed application context uses ciphering, it shall carry the client system
title;
NOTE If a client system title has already been sent during a registration process, like in the S-FSK PLC profile. the
calling-AP-title held should carry the same system title. Otherwise, the AA should be rejected and appropriate
diagnostic information should be sent_
Fields of the authentication functional unit (when present):
• sender-acse-requirements:
• if is not present or it is present but bit 0 = 0, then the authentication functional unit is not selected. Any
following fields of the authentication functional unit may be ignored;
• if present and bit 0 = 1 then the authentication functional unit is selected.
• mechanism-name: it carries the COSEM_Authentication_Mechanism_Name the client proposes for the
association;
• calling-authentication-value: it carries the authentication value generated by the client.
If the value of the mechanism-name or the calling-authentication-value fields are not acceptable
then the proposed AA shall be refused.
When the parsing of the fields of the Kernel and the authentication functional unit is completed, the
server continues with parsing the parameters of the xDLMS InitiateRequest APDU. carried by the
user-information field of the AARQ:
• dedicated-key: it carries the dedicated key to be used in the AA being established:

• response-allowed: If the proposed AA is confirmed, the value of this parameter is TRUE (default), the
server shall send back an AARE APDU. Otherwise, the server shall not respond. See also 10.
a) proposed-dlms-version-number, see 9.1.2.3.17
b) proposed-conformance, see 9.4.6.1:
c) client-max-receive-pdu-size, see 9_1_2_3_1_
If all elements of the proposed AA are acceptable. the server AP invokes the COSEM-
OPEN.response service primitive with the following parameters:
• Application Context_Name: the same as the one proposed:

• Responding-AP-title: if the negotiated application context uses ciphering. it shall carry the server system
title.
NOTE If a server system title has already been sent during a registration process. like in the case of the S-FSK
PLC profile, the Responding_AP_Title parameter should carry the same system title. Otherwise, the AA should be
aborted by the client.
• Result: accepted;
• Failure Type: Result-source: acse-service-user; Diagnostic; null;
• User_Information: an xDLMS InitiateResponse APDU carrying the elements of the negotiated xDLMS
context.
The CF assembles the AARE APDU — with the help of the xDLMS ASE and the ACSE — and sends
it to the client AL via the supporting lower layer protocols. and enters the ASSOCIATED state. The
proposed AA is established now. the server is able to receive xDLMS data transfer service
request(s) — both confirmed and unconfirmed — and to send responses to confirmed service
requests within this AA.
At the client side, the parameters of the AARE APDU received are extracted with the help of the
ACSE and the xDLMS ASE, and passed to the client AP via the COSEM-OPEN.confirm service
primitive. At the same time, the client AL enters the 'ASSOCIATED' state_ The AA is established
now with the application context and xDLMS context negotiated.

© Copyright 1997-20,09 DLMS User Association
ALMS User Association, COSEM Architecture and Protocols, Seventh Edition
If the application context proposed by the client is not acceptable or the authentication of the client
is not successful, the COSEM-OPEN. response primitive is invoked with the following parameters:
• Application Context_Name: the same as the one proposed. or the one supported by the server;
• Result: rejected-permanent or rejected-transient:
• Faiiure_Type: Result-source: acse-service-user: Diagnostic: an appropriate value;
• User_Information: an xDLMS InitiateResponse APDU with the parameters of the xDLMS context
supported by the server.
If the application context proposed by the client is acceptable and the authentication of the client is
successful but the xDLMS context cannot be accepted, the COSEM-OPEN.response primitive shall
be invoked with the following parameters:
• Application Context_Narne: the same as the one proposed:

• Result: rejected-permanent or rejected-transient:
• Failure_Type: Result-source: acse-service-user: Diagnostic no-reason-given:
• User Information: an xDLMS ConfirmedServiceError APDU, indicating the reason for not accepting the
proposed xDLMS context.
In these two cases, upon the invocation of the .response primitive, the CF assembles and sends the
AARE APDU to the client via the supporting lower layer protocols, The proposed AA is not
established, the server CF returns to the IDLE state.
At the client side, the parameters of the AARE APDU received are extracted with the help of the
ACSE and the xDLMS_ASE, and passed to the client AP via the COSEM-OPEN.confirm primitive.
The proposed AA is not established, the client CF returns to the IDLE slate.
The server ACSE may not be capable of supporting the requested association, for example if the
AARQ syntax or the ACSE protocol version are not acceptable_ In this situation, it returns a
COSEM-OPEN_response primitive to the client with an appropriate Result parameter_ The Result
Source parameter is appropriately assigned the symbolic value of "ACSE service-provider". The
COSEM-OPEN_inclication primitive is not issued_ The association is not established,
9.4.4.2 Repeated COSEM-OPEN service invocations

If a COSEM-OPEN.request primitive is invoked by the client AP referring to an already established
AA, then the AL is locally and negatively confirmed this request with the reason that the requested
AA already exists. Note, that this is always the case for pre-established AAs_ See 9_4.4.4.
If, nevertheless, a server AL receives an AARQ APDU referencing to an already existing AA, it
simply discards this AARQ. or, if it is implemented, it may also respond with the optional
ExceptionResponse APDU.
9.4.4.3 Establishment of unconfirmed application associations

A client AP that desires to establish an unconfirmed AA. invokes the COSEM-OPEN.request
primitive of the ASO with Service_Class == Unconfirmed. The response-allowed parameter of the
xDLMS InitiateRequest APDU. carried by the user-information parameter of the AAR() is set to
FALSE. The client AL does not wait any response from the server: the .confirm primitive is locally
generated. Otherwise the procedure is the same as in the case of the establishment of confirmed
AAs.
As the establishment of unconfirmed AAs does not require the server AP to respond to the
association request coming from the client, in some cases — for example in the case of one-way
communications or broadcasting — the establishment of unconfirmed AA is the only possibility.
After the establishment of an unconfirmed AA. xDLMS data transfer services using LN referencing
can be invoked only in an unconfirmed mariner, until the association is released_ With SN
referencing, only the UnconfirmedWrite service can be used.
DLMS User Association 2009.12-22 DLMS UA 1000-2 Ed. 7,0 174/310

Copyrighl 1997-2009 DLMS User Association
DLNAS User Association. COSEM Architecture and Protocols. Seventh Edition
9.4.4.4 Pre-established application associations

The purpose of pre-established AAs is to simplify data exchange. The AA establishment and
release phases (phases 1 and 3 on Figure 4), using the COSEM-OPEN and COSEM-RELEASE
services are eliminated and only data transfer services are used 34 _
This standard does not specify how to establish such AAs: it can be considered, that this has
already been done. Pre-established AAs can be considered to exist from the moment the lower
layers are able to transmit APDUs between the client and the server.
A pre-established AA can be either confirmed or unconfirmed (depending on the way it has been
pre-established).
A pre-established AA cannot be released.
9.4.5 Protocol for application association release

9.4.5.1 Overview
An existing AA can be released gracefully or non-gracefully Graceful release is initiated by the
client AR Non-graceful release takes place when an event unexpected by the AP occurs, for
example a physical disconnection is detected.
9.4.5.2 Graceful release of an application association

DLMS;COSEIvl provides two mechanisms to release AAs:
• by disconnecting the supporting layer of the AL;

• by using the ACSE A-Release service.
The first mechanism shall be supported in all profiles where the supporting layer of the AL is
connection oriented.
NOTE An example is the 3-layer, I-IDLC based, connection oriented protrie_
To release an AA this way. the COSEM-RELEASE service shall be invoked with the
Use_RLRQ_RLRE parameter not present or FALSE. Disconnecting the supporting layer shall
release all AAs built on that supporting layer connection,
The second mechanism can be used to release an AA without disconnecting the supporting layer. It
shall be supported in all profiles when the supporting layer is connectionless. It may be also used
when the supporting layer is connection-oriented but the connection is not managed by the AL, or
disconnection of the supporting layer is not practical because other applications may use it, or when
there is a need to secure the COSEM-RELEASE service. It is the only way to release unconfirmed
AAs
To release an AA in this way. the COSEM-RELEASE service shall be invoked with the
Use_RLRQ_RLRE parameter = TRUE. As specified in 9_3.3, the COSEM-RELEASE service can be
secured by including a ciphered xDLMS InitiateRequest / Initiate Response in the user-information
field of the RLRO r RLRE APDUs respectively, thus preventing a potential denial of service attack.
An example for releasing an AA using the ACSE A-RELEASE service is shown in Figure 71.
A client AP that desires to release an AA using the A-RELEASE service. shall invoke the COSEM-
RELEASE.request service primitive with Use_RLRQ_RLRE == TRUE. The client CF enters the
ASSOCIATION RELEASE PENDING state. It constructs then an RLRO APDU and sends it to the
server. If the AA to be released has been established with a ciphered context, then the user
information field of the fRLRQ APDU may contain a ciphered xDLMS InitiateRequest APDU. See
9.3.3.
When the server AL CF receives the RLRQ APDU, it checks first if the user-information field
contains a ciphered xDLMS InitiateRequest APDU. If so. it tries to decipher it. If this is successful, it
NOTE As for all AAs, the logical devices must contain an Association LN SN interlace object for the pre-established
associations, too.
DLMS User Association 2009.12-22 1 DLMS UA 1000-2 Ed. TO 175/31C

enters the ASSOCIATION RELEASE PENDING state and generates a COSEM-RELEASE.indicatidn

primitive with Use RLRQ RLRE TRUE Otherwise, it silently discards the RLRQ APDU and
stays in the ASSOCIATED state.
The .response primitive is invoked by the server AP to indicate if the release of the AA is accepted
or not, but only if the AA to be r eleased is confirmed. Note, that the server AP cannot refuse a
release request. Upon the reception of the .response primitive the server AL CF constructs a R LRE
APDU and sends it to the client, If the RLRQ APDU contained a ciphered xDLMS InititateRequest
APDU then the RLRE ADU shall contain a ciphered xDLMS InitiateResponse APDU. The server AL
CF returns to the IDLE state.
The .confirm primitive is generated by the client AL CF when the RLRE APDU is received. The
supporting layer is not disconnected. The client AL CF returns to the IDLE state.
If the RLRE APDU received contains a ciphered xDLMS InitiateResponse APDU but it cannot be
deciphered, then the RLRE APDU shall be discarded. It is left to the client to cope with the
situation.
Client Server
Client Client supporting supporting Server Server
AP AL CF Protocol Protocol AL CF AP
Layer (XX) Layer (XX)
Client and Server ALs are in ASSOCIATED slate. Lower Layer corinectionts} are established
COSEM-RELEASE,req
Use RLRO_RLFtE RUE
Client AL CF is in ASSOCIATION
RELEASE PENDING state
XX-DATA. ind (RLRQ)
Server AL CF is in ASSOCIATION
COSEM-RELEASE.ind
Use RLRQ RLRE = TRUE
COSEM RELEASE.res
-
Use RLRQ RLRE TRUE

XX-DATA.req (RLRE)
XX-DATA irid (RLRE --
....
COSEM-RELEASE.enf --- S erver AL CF is In

IDLE state
Use_FILF1O_RLRE = TRUE
The AA is released. Lower Layer connections) are rim:inflected
Figure 71 — Graceful AA release using the A-RELEASE service

Figure 72 gives an example of graceful releasing a confirmed AA by disconnecting the
corresponding lower layer connection.
A client AP that desires to release an AA not using the A-RELEASE service, invokes the COSEM-
RELEASE.request primitive with Use_RLRQ_RLRE == FALSE or not present. The client AL CF
enters the ASSOCATION RELEASE PENDING state.
In communication profiles where the RLRQ service is mandatory, invoking the _request primitive
with no Use_FILRCURLRE or with Llse_RLAQ_RLIRE == FALSE may lead to an error; the .request
shall be locally and negatively confirmed. The client AL CF returns to the IDLE state .
DLMS User Association 2009-12-22 DLMS UA -1000-2 Ed. 7.0 176/310

When the client AL CF receives the .request primitive, it sends an XX-DISCONNECT.request

primitive to the server_
When the server AL CF receives the XX-DISCCNNECT.request primitive, the CF enters the
ASSOCATION RELEASE PENDING state. The COSEM-RELEASE.indication primitive is generated
by the server AL CF with Use_RLRCLRLRE == FALSE or not present.
The COSEM-RELEASE-response primitive is invoked by the server AP to indicate if the release of

the AA is accepted or not Note, that the server AP cannot refuse a release request_ Upon the
reception of this primitive, the server AL CF sends an XX-DISCONNECT.response primitive to the
client and returns to the IDLE state.
The COSEM-RELEASE.confirm primitive is generated by the client AL when the XX-

DISCONNECT.confirm primitive is received. The supporting layer is disconnected. The client AL CF
returns to the IDLE state.
Client Server
Layer (XX) Layer (XX}
Client and Server ALs are in ASSOCIATED slate. Lower Layer connection(s) are established
COSEM-RELEASE.req
Client AL CF is in ASSOCIATION
RELEASE PENDING stale
XX-DISCONNECT.req
____----- KX-DISCONNECT.ind
Server AL CF is in ASSOCIATION
COSEM-RELEASE.ind
COSEM-FtELEASE.res
4
XX-DISCONNECT.res
XX-DISCONNECT.cn1 —
—
COSEM-RELEASE.cnf Server AL CF is in
■ IDLE state
Client Supporting Server Supporting

Layer connection is Layer connection is
DISCONNECTED DISCONNECTED
Client AL CF is in
!OLE state
The M is reteased. Lower Layer connection(s) are disconnected
Figure 72 — Graceful AA release by disconnecting the supporting layer
9.4.5.3 Non-graceful release of an application association

Various events may result in a non-graceful release of an AA: detection of the disconnection of any
lower layer connection (including the physical connection). detecting a local error. etc.
Non-graceful release - abort - of an AA is indicated to the COSEM AP with the help of the COSEM-
ABORT service_ The Diagnostics parameter of this service indicates the reason for the non-graceful
AA release. The non-graceful release of AA is not selective: if it happens, all the existing
association(s) - except the pre-estabisihed ones - shall be aborted.
Figure 73 shows the message sequence chart for aborting the AA. due to the detection of a physical
disconnection.
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0

Cooynght 1997-2009 DLMS User Association
I 177/310
Cflertt Merit Server Server

Client application sicporling Mena Server supporting application Server
application Iayar protocol PhPica] Channel physical protocol layer application
process corttrof layer layer layer layer control process
function POCII (XX) Isinction
Meal and server application layers are in ASSOCIATED slate. lower layer connection(s) are established
Physical
connetton
beaks
xx , XX-
DISCONNECT DLSCONN EC1
COSEM- ind COSEM-
ABORT ind — ,_ ABORtind
pr011x:Ol layer COnneCtioebls} are aborted
CI lent Server
layer GF 's in IDLE layer CF is in leg;.
state state
The application assoclabon is non-gracefully released!

I 1_7
I I I i I 1 1
as
Figure 73 — Aborting an AA following a PH-ABORT.indication
9.4.6 Protocol for the data transfer services

9.4.6.1 Negotiation of services and options — the conformance block
The conformance block allows clients and servers using the same DLMS/COSEM protocol, but
supporting different capabilities to negotiate a compatible set of capabilities so that they can
communicate. It is carried by the DLMS_Conformance parameter of the COSEM-OPEN service.
In DLMS/COSEM none of the services or options are mandatory: the ones to be used are
negotiated via the COSEM-OPEN service (the proposed-conformance parameter of the xDLMS
InitiateRequest APDU and the negotiated-conformance parameter of the xDLMS InitiateResponse
APDU). An implemented service shall be fully conform to its specification. If a service or option is
not present in the negotiated conformance block, it may not be requested by the client.
The xDLMS conformance block can be distinguished from the DLMS conformance block specified in
IEC 61334-4-41 by its tag: APPLICATION 31. It is shown in Table 46.
Table 46 — xDLMS Conformance block
Conformance Reserved LN referencing SN referencing

block bit
a x
1 x
2 x
3 read
4 write
5 unconfirmed-write
6 x
7 It
8 attribute0-supported-with-set
9 priority-mgmt-supported
10 anribute0-supported-with-get
11 block-transfer-with get-or-read
- block-transfer-with-get-or-read
12 block-transfer-with-set-or-write block-transfer-with-set-or-write
'The release of an AA may require internal communication between the ASEs of the CF. These are not shown on the figures.
I DLMS User Association 12009-12-22 Copyright 1997-2009 eLMS User Association

DLMS UA 1000-2 Ed. 7.0 1 178'310
Conformance
Reserved LN referencing SN referencing
block bit
13 block-transfer-with-action
14 multiple-references multiple-references
15 information-report
/6 x
17 x
/8 parameterized-access
19 get
20 set
21 selective-access
22 event-notification
23 action
9.4.6.2 Confirmed and unconfirmed service invocations

In general, data transfer services may be invoked in a confirmed or an unconfirmed manner. The
time sequence of the service primitives corresponds to:
• Figure 67 item a) in case of confirmed service invocations; and

• Figure 67 item d) in case of unconfirmed service invocations.
A client AP that desires to access an attribute or a method of a COSEM interface object, invokes
the appropriate .request service primitive. The client AL constructs the APDU corresponding to the
.request primitive and sends it to the server.
The server AP, upon the receipt of the .indication primitive, checks whether the service can be
provided or not (validity, client access rights, availability, etc.). If everything is OK, it locally applies
the service required on the corresponding "real" object. In the case of confirmed services, the
server AP invokes the appropriate .response primitive. The server AL constructs the APDU
corresponding to the .response primitive and sends it to the server. The client AL generates the
.confirm primitive.
If a confirmed service request cannot be processed by the server AL — for example the request has
been received without establishing an AA first, or the request is otherwise erroneous — it is either
discarded, or when possible, the server AL responds with a ConfirmedServiceError APDU, or, when
implemented, with an ExceptionResponse APDU. These APOUs may contain diagnostic information
about the reason of not being able to process the request. They are defined in 9.5.
Within confirmed AAs, clientiserver type data transfer services can be invoked in a confirmed or
unconfirmed manner.
Within unconfirmed AA-s, client/server type data transfer services may be invoked in an
unconfirmed manner only. With this, collisions due to potential multiple responses in the case of
multioasting and/or broadcasting can be avoided.
In the case of unconfirmed services, three different kinds of destination addresses are possible:
individual, group or broadcast. Depending on the destination address type, the receiving station
shall handle incoming APDUS differently, as follows:
• XX-APDUs with an individual address of a COSEM logical device. If they are received within an
established AA they shall be sent to the COSEM logical device addressed, otherwise they shall be
discarded;
▪ XX-APDUs with a group address of a group of COSEM logical devices. These shall be sent to the group
of COSEM logical devices addressed. However. the message received shall be discarded if there is no
AA established between a client and the group of COSEM logical devices addressed;

DIMS User Association. COSEM Architecture and Protocols. Seventh Edition
. XX-APDUs with the broadcast address shall be sent to all COSEM logical devices addressed. However.
the message received shall be discarded if there is no AA established between a client and the All-
station address.
NOTE Unconfirmed AA-s between a client and a group of logical devices are established with a COSEM-OPEN
service with Service Class == Unconfirmed and a group of logical device addresses (for example broadcast addressl.
9.4.6.3 Protocol for the GET service

When the client AP desires to read the value of one Or more COSEM interface object attributes, it
uses the GET service.
As explained in 9.3.6, the encoded form of the request shall ahirays fit in a single APDU.
On the other hand, the result may be too long to tit in a single APDU. In this case. block transfer
may be used. It is negotiated via bit 11 of the conformance block, see 9.4.6.1.
NOTE The supporting layer may also provide a mechanism for trariSlerring long messages.
The GET service primitive types and the corresponding APDUls are shown in Table 47.
Table 47 - GET sery ce types and APDUs
GET .req .1 .ind Request APDU Response APDU GET .res , .cni
Get-Response-Normal NORMAL
NORMAL Get-Request-Normal Gel.Response-With-Datablock
ONE-BLOCK
with Last-Block - FALSE
Get-Response-With-Oalablock
ONE-BLOCK
with Last-Block t= FALSE
NEXT Get-Request-Next
Get-Response-With-Dalablock '
LAST-BLOCK
with Last-Block m TRUE
Gel-Response-With-List WITH-LIST
WITH-LIST Get-Request-With-List Gel-Response-With-Datablock
ONE-BLOCK
with Last-Block FALSE
Figure 74 shows the MSC for a confirmed GET service in the case of success. without block
transfer.
Chen/ Server
Chem Ghent supporting sivrorting
AP Pd. OF Protocol Proracoll
Layer Layer CADO
Cieni and Server Ats in ASSOCIATED Ade. Loper Layer connacaorls) established
GET.req NORMAL •
{ LN Reference) xx.oATA.reg
(Get- Request-Normal) XX- DATA.wd 1,
{ Gel - Request-Nora()
♦ XX- DATitreq
XX-DATA.ind 4 (Get-Resp-Noinal)
GET cnt NORMAL (Get-Flesp-Normal)
(Success, Data)
Figure 74 - MSC of the GET service

Figure 75 shows the MSC of a confirmed GET service in the case of success, with the result
returned in three blocks.

.1=t Copyright 19-97 2009oLMS
- User Association
Client Server
Chen! ateril supporting supporting Server Server
AP AL CF PoXocol Protocol AL CF AP
Layer (XX) Layer Ng
Client and Server ALs in ASSOCIATED slate, Lower Layer oonnection(s) established
GET.req NORMAL
(LN Reference) XX-DATA.req
(Gel-Request-Normal) >0X-DATA.ind GET.Ind NORMAL
(Get-Request-Normal) (LN Reference)
GET,res ONE-BLOCK
L XX-DATA,req ILAST=FALSE,Block #1,
XX-DATA.ind
GET.cnf ONE-BLOCK ■ (Get-Resp-With-
(Get-Resp-With- raw-data)
Datablock)
ILAST=FALSE,Block #1, Dataialock)
raw•data)
GET. NEXT
(Block #1) XX-DATA.req
(Get-Request-Next) — — -4, >0‹-DATA.ind
r.FT 119.11 NEXT
(Get-Request-Next)
(Block #1)
GET.res ONE-BLOCK
XX-DATA.req 1LAST=FALSE, Block #2
XX-DATA_ind —
411 (uet-ries-p-vvitn- raw-data)
GET.chf ONE-BLOCK (Get-Resp-With- Datablock)
LAST=FALSE, Block #2, Databkx*)
raw-data)
GET. NEXT
(Block #2) XX-DATA.r
(Get-Request-Next) XX-DATAInd
(Get-Request-Next] GE-Lind NEXT
(Block #2)
GET.res LAST-BLOCK
X74-DATAreq 4(LAST=TRUE, Block #3,
XX-DATA.ind ..._
4 (Get-Resp-With- ra•cfata)
GET.cnf LAST-BLOCK 4 (Get-Resp•With- Datable(*)
LAST.TRUE, Block #3. Daiabfock)
raw-data)
Figure 75— MSC of the GET service with block transfer

The GET.request primitive is invoked with Request Type NORMAL or WITH-LIST as
appropriate. As in this case the data to be returned is too long to fit in a single APDU, the server AP
sends it in blocks. First, the data is encoded, as if it would fit into a single APDU:
• if the value of a single attribute was requested, only the type and value shall be encoded (Data);
NOTE If the Data cannot be delivered, the response should be of type GET-NORMAL with Data_Access_Result.
• if the value of a list of attributes was requested, then the list of results shall be encoded: for each
attribute, either Data or Data_Access_Result.
The result is a series of bytes, B 1 B2, B3,...., ,
NOTE The server may generate the complete response upon the receipt of the first GET.indication primitive or
dynamically (on the fly).
The server AP assembles then a DataBlock G structure:
• Last_Block .. FALSE:
• Block_Number ... 1;
• Result (Raw_Data) . the first K bytes of the encoded data B 1 . 132, B3, BK.
NOTE It is recommended to start the numbering of the blocks from 1.

The server AP invokes then the GET-RESPONSE-ONE-BLOCK service primitive with
Response_Type == ONE-BLOCK carrying this DataBlock-G structure.
Upon the reception of the response primitive, the server AL builds a Get-Response-With-Datablcck
APDU carrying the parameters of the .response primitive and sends it to the client.
Upon the reception of this APDU, the client AL generates a .confirm primitive with Response_Type
== ONE-BLOCK. The client AP is informed now that the response is provided in several blocks. It
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 I 181/310

CI Copyright 1997-2009 DIMS User Association
IJLMS User Association. COSEM Architecture and Protocols. Seventh Edition
stores the data block received (B 1 , 62, BO, then acknowledges its reception and asks for the
next one by invoking a GET-REQUEST-NEXT service primitive. The block number shall be the
same as the block number of the data block received_ The client AL builds a Get-Request-Next
APDU and sends it to the server.
When the server AL invokes the GET.indication primitive with Request Type == NEXT. the server
AP prepares and sends the next data block, including BK.1, BK.?. BK,.3„ B L , with block-number ==
2. This exchange of sending data blocks and acknowtedgements continues until the last data block,
carrying BM, BM+2, BN is sent. The last GET.response primitive is invoked with
Response_Type == LAST-BLOCK: in the DataBlock-G structure Last Block == TRUE. This last data
block is not acknowledged by the client.
Throughout the whole procedure, the Invoke_Id and the Priority parameters shall be the same in
each primitive.
If during a long data transfer the server receives another service request. it is served according to
the priority rules and the priority management settings (Conformance block bit 9).
If any error occurs during the long data transfer. the transfer is aborted. The error cases are.
a) The server is not able to provide the next block of data for any reason. In this case. the server
AP shall invoke a GET-RESPONSE-LAST-BLOCK service primitive_ The Result parameter shall
contain a DataBlock G structure with:
• Last_Block == TRUE;
• Block_Number == number of the block confirmed by the client +1;
• Result == Data Access_Result, indicating the reason of the failure.
b) The Block_Number parameter in a GET-REQUEST-NEXT service primitive is not equal to the
number of the previous block sent by the server. The server interprets this, as if the client would
like to abort the ongoing transfer. In this case. the server AP shall invoke a GET-RESPONSE-
LAST-BLOCK service primitive. The Result parameter shall contain a DataBlock G structure
with:
• Last_Block TRUE;
• Block_Number == equal to the block number received from the client:
• Result == Data-Access-Result. long-get-aborted.
c) The server may receive a Get-Request-Next APD{J when no long data transfer is in progress_ In
this case, the server AP shall invoke a GET-RESPONSE-LAST-BLOCK service primitive. The
Result parameter shall contain a DataBlock_G structure with:
• Last-block == TRUE;
• Block-Number == equal to the block number received from the client;
• Result == Data-Access-Result, no-long-get-in-progress.
d) The block number sent by the server is not equal to the next in sequence. In this case. the client
shall abort the block transfer (see case b).
If, in the error cases above, the server is not able to invoke a GET RESPONSE LAST BLOCK
- - -
service primitive for any reason, it shall invoke a GET-RESPONSE-NORMAL service primitive, with
the Data-Access-Result parameter indicating the reason of the failure. The server shall send a Get-
Response-Normal APDU.
The MSC for error case b). long get aborted is shown in Figure 76
DLMS User Association 20G9-12-22 DLMS UA 1000-2 Ed. 7.0 182:310

:: Copyright 1997-2009 OLMS User Association
Client Serer
Client Client supporting supporting Sarver Sewer
Client and Server ALs in ASSOCIATED state, Lower Layer connecike(s) established
GET.req NORMAL I,.

{LN Reierence) XX.DATA req
(Get-Request-Norrnal) XX-DATA.ind GET.ind NORMAL
{Get-Request-Normal) (LN Reference)
GET.res ONE-BLOCK
XX.DATA.req ILAST=FALSE,B1cck #1-
>DC-DATA_ ind ,
(Gel-Resp-With-
GET.cnt ONE-BLOCK — raw-data!
(Get-Resp-Wrib- Dalablar..k)
1LAST•FALSE.Block 41- Datablock)
raw-dotal
GET.req NEXT
(Block r3) 30C , DATA.req
(Get-Request Next) —— >0C-OATA.ind
11. GE1.ind NEXT
(Gel-Request-Next)
(Block #3)
GET.res ONE-BLOCK
XX-DATA.req "n(LAST.TRIIE, Block 43,
XX- DATA_ ind {Get-Resp-wirti-
GET.cnt ONE - BLOCK Data-Access-Result =
fGet - Resp - Wrrh- Datablock)
—(LAST=TRUE. Block 43. long-get-aborted}
Catablock)
Data-Access-Result
long- get.aboned)
Figure 76 — MSC of the GET service with block transfer, long GET aborted
9.4.6.4 Protocol for the SET service

When the client AP desires to write the value of one or more COSEM interface object attributes, it
uses the SET service.
As explained in 9_3,7, the encoded form of the request may fit in a single request or not In this
latter case, block transfer may be used. It is negotiated via bit 12 of the conformance block, see
9.4.6.1.
NOTE The supporting layer may also provide a mechanism for transferring long messages.
The SET service primitive types and the corresponding APDUs are shown in Table 48.
Table 48 — SET service types and APDUs
SET .req 1 .ind Request APDU Response APDU SET .res r .cnf
NORMAL Set-Request-Normal Set-Response-Normal NORMAL
Set-Request-With-First-
FIRST-BLOCK Datablock
Last-Block = FALSE
Set-Response-Datablock ACK-BLOCK
Set-Request-With-Datablock
ONE-BLOCK
Last-Block = FALSE
LAST-BLOCK
Set-Request-With-Databkock
LAST-BLOCK Set-Response-Last-Datablock LAST BLOCK
TRUE
i WITH-LIST
WITH-LIST Set-Request-With-List Set-Response-With-List WITH-LIST
FIRST-BLOCK- Set-Request-With-List-And-With-
Set-Response-Datablock ACK-BLOCK
WITH-LIST First-Datablock

Copyright t997-2009 DINS Use Association
Figure 77 shows the MSG of a confirmed SET service, in the case of success. without block
transfer.
Chem Server
AP AL CF Protocol Proknol AL CF AP
Layer (XX) Layer ()C()
Reference, eta) XX-DATA.req

{Se!-Request-Normal) Xx- DATA.ind
(Set-Reouest-Norrndl ► SET Ind NORMAL
(LN Reference. Data) F.
SET.res NORMAL,
XX-DATA.req (Success)
XX-DATAind (Set - Reap - NOttnal)
SET.cnf NORMAL (Set-Resp- Normal)
(Success)
1
Figure 77 — MSC of the SET service
Figure 79 shows the MSC of a confirmed SET service in the case of success, with the request sent
in three blocks.
Chen] r Server
Client Client 80pp:eft stAPPonIN Server $erve r
AP AL CF PrOt0004 Protocol AL CF AP
Layer (XX) layer Pa)
1
Client and Seeger Als In ASSOCIATED stele. Low Layer connection(s) established
SET. F1RST•SLOCK
Last. L XX , DATA.
eouest-With • first• XX DATA..otx1
Block #1, raw-data) SET Ind FIRST-BLOCK
Datablock) Request iirst
Ostablock) ( • -77., Last. L
Block #1, raw-data)
SET.res ACK-BLOCK
XX•DaT.A.req (Block Cl)
XX•CATA.Ind ----- iSer•Pesp•Daiahlocio
SET.crif ACK-BLOCK ▪ (Sel-ftesp-Datablock)
Oc #1)
SET re ONE•BLOCK
hock #2, XX-DATA.
eduest• th- — ----- XX.-DATAirx1
raw-data)
oatabkock) ( I• equest•Wilh-
Datablock) . AL E, Block 1/2,
raw•darai
SET.res ACK-BLOCK
XX-DATA.r
XX-DATA.ind — (SET-Resp-Delablock)
(Set • Rasp •Oatablock)
xx.DATA.req
(Sel-Request-With- ——— X74-DATA.thel
(Sel-Request-Willi- SET.incl LAST-BLOCK
Datablock)
Databknk) T.TPUE, Block Ia.
raw-dala)
SET.tes LAST-BLOCK
xx.DATA req (Result, Block #3)
XX-DATA ?net -4- ----- f 4 (Sel-Resp-Last-
SET.enf LAST•BLOCK 4 (5e!-Reap Last-
fit Datablock)
(Result, Black 03) Datablock)
Figure 78 — MSC of the SET service with block transfer
As in this case the data to be sent is too long to fit in a single APDU. the client AP sends it in
blocks. First, the data is encoded as if it would fit in a single APDU. The result is a series of bytes,
B1. B2, B2,....,
NOTE The client may generate the complete request (131, B2, 133,.....13,,) in one step or dynamically (on the fly).
The client AP assembles then a DataBlock_SA structure:
• Last Black FALSE:

• Block_Nurnber == 1:
• Raw_Data == the first K bytes of the encoded data: B 1 , B2. B2 BK.

Copyright 1U97-2009 DLMS User Association
The client AP invokes then the SET-REQUEST-FIRST-BLOCK or SET-REQUEST-FIRST-BLOCK-

WITH-LIST service primitive as appropriate, carrying the attribute reference(s) and this DataBlock-
SA structure.
Upon the reception of the .request primitive. the client AL builds the appropriate Set-Request APDLJ
carrying the parameters of the _request primitive and sends it to the server.
The server stores the data block received, then acknowledges its reception and asks for the next
one by invoking a SET_response primitive with Response_Type == ACK-BLOCK and with the same
block number as the number of the block received.
To send the next data block carrying BK +1 , BK+2. BK-3, BL, the client AP invokes a SET-
REQUEST-ONE-BLOCK service primitive. This exchange of sending data blocks and
acknowledgements continues until the last data block carrying BM. BM.,, Bm + 2 „ BN is sent, by
invoking a SET-REQUEST-LAST-BLOCK service primitive with Last Block == TRUE.
When these primitives are invoked. the client AL builds a Set-Request-With-Datablock APDU,
carrying a DataBlock_SA structure and sends these APDUs to the server.
When the server AP receives the last datablock. it invokes a SET-RESPONSE-LAST-BLOCK or

SET-RESPONSE-LAST-BLOCK-WITH-LIST service primitive as appropriate. The Result parameter
carries the result of the complete SET service invocation. The Block Number parameter confirms
the reception of the last block.
Throughout the whole procedure, the Invoke_Id and the Priority parameters shall be the same in
each primitive.
If during a long data transfer the server receives another service request, it is served according to
If any error occurs during the long data transfer, the transfer is aborted. The error cases are:
a) The server is not able to handle the data block received, for any reason. In this case, the server
AP shall invoke a SET-RESPONSE-LAST-BLOCK or SET-RESPONSE-LAST-BLOCK-WITH-
LIST service primitive as appropriate. The Result parameter indicates the reason for aborting
the transfer;
b) The Block Number parameter in a SET-REQUEST-ONE-BLOCK service primitive is not equal to

the block number expected by the server (last received + 1). The server interprets this as if the
client would like to abort the ongoing transfer. In this case, the server AP shall invoke a SET-
RESPONSE-LAST-BLOCK or SET-RESPONSE-LAST-BLOCK-WITH-LIST service primitive as
appropriate with the Result parameter Data_Access_Result == long-set-aborted;
c) The server may receive a Set-Request-With-Datablock APDU when no long data transfer is in
progress. In this case. the server AP shall invoke invoke a SET-RESPONSE-LAST-BLOCK
service primitive with the Result parameter Data Access_Result == no-long-set-in-progress.
If, in the error cases above, for any reason the server is not able to invoke a SET-RESPONSE-
LAST-BLOCK service primitive, it invokes a SET-RESPONSE-NORMAL service primitive with the
Data-Access-Result parameter indicating the reason of the failure.
9.4.6.5 Protocol for the ACTION service

When the client AP desires to invoke one or more COSEM interface objects methods, it uses the
ACTION service. As explained in 9.3.8, the ACTION service comprises two phases.
If the method references and method invocation parameters or the return parameters do not fit in a
single APDU, block transfer may be used from the client to the server and/or from the server to the
client respectively. It is negotiated via bit 13 of the conformance block, see 9.4.6.1.
NOTE The supporting layer may also provide a mechanism for transferring long messages_
The ACTION service primitive types and the corresponding APDUs are shown in Table 49.
DLMS User Association 12009- 12-22 I DLMS IJA 1000-2 Ed. 7.0 I 185/310
Table 49 — ACTION service types and APDUs
SET .req 1 .Ind Request APDU Response APDU SET .res i .cnf
Action-Response-Normal NORMAL
NORMAL Action-Request-Normal
Action-Response-With-Pblock ONE-BLOCK
NEXT Action-Request-Nerl- Pblock
Action-Response-With-Pblock LAST-BLOCK
Action-Request-WO-First-
Fl RST-BLOCK
Pblock Action-Response-Next.Pblock NEXT
ONE-BLOCK Action-Request-With-Pblock
Action Response Normal
- - NORMAL
LAST-BLOCK Action-Request-With-Pblock
Action-Response-With-List WITH-LIST
WITH-LIST Action-Request-With-List
WITH-LIST-AND- Action-Request-With-List-And-
Action- Response-Next-Pblock NEXT
FIRST-BLOCK With-Firs1-Pblock
Figure 79 illustrates the MSC of a confirmed ACTION service in the case of success. without block
transfer.
Clieni Sarver
Clipn/ Client Sop3Ortirso supeorting
AP AL CF Protocol Protocol
Client and Server Ms in ASSOCIATEDstate. Low Layer connections) established
ACTION req NORMAL

(LN Rot, rev . paearn XX-DATA_
XX-CATAind
-- —--
— ACTION.ind NORMAL
;Action-Requesl-Normal
• Inv. alarm)
ACTION res NORMAL

XX DATA rti (Success, Haium
XX.DA7 Amid ilon•Resp Normal)
ACTION.i rid NORMAL A eilon-Pesp.Normal) 4 ------ Param
,
Qucoess. Fialurn
Pararn
I i —1 i_ i i i I
Figure 79 — MSC of the ACTION service
The ACTION service can transport data in both directions:
• in the first phase, the client sends the ACTION.request with the method invocation parameters for the
method(s) referenced and the server acknowledges them. The process is essentially the same, as in the
case of the SET service;
• in the second phase, the server sends the ACTION.response with the result of invoking the method(s)
and the return parameters. The process Is essentially the same as in the case of the GET service.
Throughout the whole procedure. the Invoke_Id and the Priority parameters shall be the same in
each primitive.
If during a long data transfer the server receives another service request. it is served according to
Figure 80 illustrates the MSC in the case, when block transfer takes place in both directions_
If any error occurs during the long data transfer. the transfer shall be aborted. Error cases are the
same as in the case of the GET and SET services.

Crierrt Server
LW' POC) Layer (XX)
client and Server ALs in ASSOCIATED stile, Lower Layer connection(s) estabished
ACT1ON.req FIRST-
BLOCK,
(LN Rel.. LAST=FALSE XX-DATAreq
XX-DATAind ACTION.ind FIRST-
Block #1. raw-data) (Aclion-R11.
equst•Wh
(Acton-RequsWih BLOCK,
First-Pbkw*)
First-Pblock) (LN Ref., LAST-FALSE:-
Block#1,raw-dt)
ACTION res NEXT
XX- DATAreq (Block #1)
XX-DATA.ind (Action-Resp-Next-
hiP
(Acton-RespNx Pialook)
(Block #1) Pbicck)
ACTiON.req ONE- I
BLOCK,
(LAST=FALSE, Block # XX-DATA req
XX•DATA ACTION.ind ONE-
raw-data) (Acton-Request-With-
(Action-Request-With- B LOCK.
Pbcck)
Pblock) (LAST-FALSE : Block #2r
raw-data)
_ AGTION.res NEXT
NY-DATA reel (Block 02)
XX-DATA.ind liflotion•Resp•Nert•
21r-Tinkl klrYT
(Action-Resp-Next- POlock)
(Block #2) Pbook)
ACTION.req LAST-
BLOCK
).(LAST=RE,Block#3 XX-DATA rag
)(X-DATA,ind ACTION.ind LAST-
raw-data) (Action-Request-With- "
(Action-RequEst-With- BLOCK
PlAcck)
Pblock (LAST-TRUE. Block #3.
raw-data)
ACTION,requesi completed in twee blocks
1
ACTION.res ONE -
BLOCK
DATAIOCI ART.Fdl SF RIna, k
ACTION.cnt ONE- ]X€-DATA.ind
BLOCK 4- ----- (.1..1.7.11.....1 el*. • I 11.11
raw- data)
(Anon-Rasp-WM- Mock)
1LAST-FALSE, Block #1, Pltiock)
raw-data)
ACTION.req NEXT
(Block #1) XX- DATA.rea
( Action - Request- Next XX-DATA.ind
(Ackori-Requast-Next- ACT ION.ind NEXT
Pblock) (Block #1)
%rick)
ACTION.res LAST-
BLOCK
X)(-DATArea ar(L.AST.TRUE, Block #2,
ACTION.cnt LAST- XX-DATA.ind .
411 (Ael on•Resp•With• raw-data)
BLOCK (Action-Resp-Wilh- Pblock)
41(..A ocK #2,
2 PLock)
raw-data)
ACTION response completed in boa blocks.
Figure 80 — MSC of the ACTION service with block transfer
9.4.6.6 Protocol for the EventNotification service

Upon invocation of the EventNotification.request service, the Server AL builds an
EventNotificationRequest APDU. The possibilities to send out this APDU depend on the
communication profile and the connection status of the lower layers. Therefore, the protocol of the
EventNotification service is further discussed in 10.
In any case, in order to send the value(s) of attribute(s) to the client, without the client requesting it:
• the server uses the EventNotification.request service primitive;

• upon the invocation of this primitive. the server AL builds an EventNolificatioriRequest APDU;
• this APDLI is carried by the supporting layer service at the first opportunity to the client. The service type
and the availability of this first opportunity depends on the communications profile used;
• upon the reception of the EventNotificationRequest APDU, the client AL generates an
EventNotification-indication primitive 36 to the COSEM client AP;
• by default, event notifications are sent from the management logical device (server) to the management
AP (client).
36 At the client side, it is always EventNofification.indication, independently of Lhe referencing scheme (LN or SN) used by the server.
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7M 11 07131 o

Copyright 1997 -2009 DLMS Use Association
9.4.6.7 Protocol for the Read service

As explained in 9.3.12. the Read service is used when the server uses SN referencing, either to
read (a) COSEM interface object attribule(s), or to invoke (a) method(s) when return parameters are
expected:
• in the first case. the GET.request service primitives are mapped to Read.request primitives and the
Read-confirm primitives are mapped to GET,confirm primitives_ The mapping and the corresponding SN
APDUs is shown in Table 50:
• in the second case, the ACTION.request service primitives are mapped to Read.request primitives and
the Read.response primitives are mapped to ACTION.response primitives. The mapping and the
corresponding SN APDUs is shown in Table 51.
NOTE In the mapping tables below, the following notation is used:

▪ for LN services, only the request and response types are shown without service parameters :
▪ for SN services. the name of the service primitive is followed by the service parameters in brackets. Service
parameter name elements are capitalized and joined with an underscore to signify a single entity. Parameters that
may be repeated are shown in curly brackets. The choices that can be taken for the Vanable_Access_Specificalion
parameter are listed following the symbol Alternatives are separated by the vertical bar - I - .
• for SN APDUs, the name of the APDU is followed by the symbol ":7. - and the fields in brackets. The field name
elements are not capitalized and are pined with a dash 10 signify a single entity. Fields that may be repeated are
Shown in curly brackets. Alternatives are separated by ihe vertical bar
Table 50 - Mapping between the GET and the Read serv i ce
From GET.request of To Read.requesi SN APDU

type
NORMAL Read.request ReedRequest : -
(Variable_Access_Specificaliori) (variable nameI parameterized•access)
Variable_Access_Specification -
Variable_Name I Parameterized Access;

NEXT Read.request ReadRequest !:.
(Variable_Acces_Specification) (block-number access)

-
Variable_Access_Specitication ■
Block_Number_Aocess;
WITH-LIST Read.request ReadRequest :: -
(Viariable_Access_SpocificationD ((variable-name I parameterized-access))

Variable_Access_Specification -
Variable_Name I Parameterized_Access:
To GET.confirm of type SN APDU From Read.response
NORMAL ReadResponse ::- Read.response

(data I data-access-error) (Data I Data_Access_Error)
ONE-BLOCK ReadResponse ::- Read.response (Data Block_Result)
Idala-block result)
- with Last . Block .. FALSE
LAST BLOCK
- ReadResponse ::• Read.response (Dala_Block_Result)
(data black result)
- - with Last_Block TRUE-
WITH LIST
- ReadResponse ::= Read.response
((data I data-access- error)} ({Data I Data_Access_Error))
Table 51 - Mapping between the ACTION and the Read service
From ACTION.request of To Read.request SN APDU

type
NORMAL Read.request ReadRequest
(Variable_ . Access ._Specifrcalion) (parameterized-access)
Parameterized Access:
with
Variable Name = method reference.
Selector = 9,
Parameter = method invocation parameter
or null-data
NEXT Read.request ReadRequest :: =
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0 11 188/310

From ACTION.requesit of I To Read.request SN APDU

type
(Variable_Access_Soecitioation) (block-number-access)
Variable_Acces _ Specification =
Block_Number_Access:
FIRST-BLOCK Read.request ReadRequest ::=

(Variable_Access_Specification) (read-data-block-access)
Variable Acces_Specification =
Read_Data_Block_Access;
with
Last_Block
= FALSE,
Block_Number
umber
N = 1,
Raw_Data = one part of the method
reference(s) and method invocation
parameter
ONE -BLOCK Read.request ReadRequest .:=

(Variable_Access_Specification) tread-data-block-access)
Variable Acces_Specification =
Read_Da-ta_Block_Access;
with
= FALSE,
Last_Block
Block _N
umber = next number,
Number
Raw_Data 3. as above
LAST-BLOCK Read.request ReadRequest ::-

(Variable_Access_Specification) (read-data-block-access)
Variabie_Acces_Specification =
Read_Data_Block_Access;
with
Last Block = TRUE,
Block_Number = next number,
Raw Data = as above
WITH-LIST Read.request ReadRequest ::.

((Variable_Access_Specification)) ((parameterized access])
-
Variable Access Specification =

Parameterized Access:
with
Variabie_Name = method reference,
Selector = 0,
Parameter = method invocation parameter
or null-data
WITH-LIST-AND-FIRST- Read-request ReadRequest 1:=

BLOCK (Variable_Access_Specification) (read-data-block-access)
Variable Acces_Soecification .
Read_Da-ta_Block_Access:
with
Last Block = FALSE,
Block Number = 1,
Raw Data = as above
To ACTION.conflrm SN AMU From ReadResponse
NORMAL ReadResponse :==. Read-response (Read_Result)

(data I data-access-error) Read Result =
Data I Data_Access_Errar;
ONE-BLOCK ReadResponse :: Read-response (Read_Result)

(data-block-result) Read Result = Data Block_Result;
with Last_Block = FALSE
LAST-BLOCK
1 ReadResponse ::=
(data-block-result)
Read.response (Read_Resull)
Read result = Data Block_Result;
with Last_Block = TRUE
NEXT ReadResponse ::= Read.confirm (Read_Result)

(block-number) Read_Result = Block_Number;
WITH-LIST ReadResponse ::= Read_response ((Read_Result))

((data I data-access-error-1) Read Result
Data iData_Access_Error;

Gopynght 1997-2009 DLMS User Association
Figure 81 shows the MSC of a Read service used to read the value of a single attribute.
Client Client Sewer

CLierlt AL CF suPPortrfg supporting Server Server
AP with SN Protocol Protocol AL CF AP
Mapper Layer OM Layer OM
Client and Server ALs in ASSOCIATED state. Lower Layer connection(s) established
GET.FCCI NORMAL
Fief XX-DATA req
(ReadRequesi XX-DATAind
(ReadRequesl Readind
{Vanable-Narnel}
IVanable-Narrie hi ISN Ref. h
Read.res
XX -DATA .req access, Data)
XX-DATA.ine — — — — — — 4r (ReadRespo.nse (Data))
GET.onf NORMAL d esponse (Darall
41-1;7717
(Success. Dais)
Figure 81 — MSC of the Read service used for reading an attribute

Figure 82 shows the MSC of a Read service used to invoke a single method.
Chen! Server
Cliertl Client supporting supporting Server Server
AP AL CF Peciocot INCrOCOI AL CF AP
Layer (XX) Layer (XX}
Clrenl and Server ALs In ASSOCIATED stale. Lower Layer connecilart(s I °slab' isled
ACTICN.req NORMAL
(LN Ref.. Inv Pararn XX-DATA req
(ReadRequesi XX.DATA. ux:1
IReadFlequesi Real:Lino
(Raramelnzed•Accesco
IPararneinted.Access11. 1SN Pei Inv Para],
Read .reS (Success.

XX DATA.req Red urn Pararn.)
XY - DATAirvd 4 0ReadResixrnse (Data))
ACTION.cril NORMAL " (ReadResoo nse {Data})
(Success. Return
I
=-
Figure 82 — MSC of the Read service used for invoking a method
Figure 83 shows the MSC of a Read service for reading a single attribute, with the result returned in three
blocks.
The process of preparing and transporting the long data is essentially the same as in the case of
the GET and ACTION service_
• if the Read service is used to read the value of (a) COSEM object attribute(s), the Raw_Data element of
the Data_Block_Result construct carries one part of the list of Read_Result(s);
• if the Read service is used to invoke (a) COSEM object method(s) and long method invocation
parameters have to be sent, the Raw_Data element of the Read_Data_Block_Access construct carries
one part of the method reference(s) and method invocation parameter(s),. If long method invocation
responses are returned, the Raw_Data element of the Data_Block_Result construct carries one part of
the method invocation response(s).
if an error occurs. the server should return a Read.response service primitive with
Data Access Error carrying an appropriate diagnostic information; for example data-block-number-
invalid.

Client Client Server

Client AL CF supporting suPPQrtin9 Senrer Server
AP with SN Protocol Protocol AL CF AP
Mapper Layer (XX) Layer (XX)
Chant and Server ALs in ASSOCIATED state. Lower Layer connedion(s) established
GET.req NORMAL
{LN Reference) )(X.DATkreq
(ReadRequest (Variable — — )10(-DATA.ree
(ReaciRewast {Variable- P" Read.ind
Name))
Name)) I SN Reference)
Pead.res
XX-OATA.reu -4C
(Las1=FALSE_ Block #1.
M-DATA incl
GET:enf ONE-BLOCK mvg-ciala)
(ReadRasporLte (Data-5 s ;
LAST=FALSE, Block #1, (Data.Bkx:k.Resullij
raw-dale)
GET,req NEXT
{Block #11 XX-IDATA_req
11, KX-DATA ind
(ReadRequest
(ReadRequesi Rear:Lind
iBlock-Number-Access))
(Blook.Nurriber.Acoess) (Block -#1)
Read. res
)0(-DATA req Lasl•FALSE. Block #2.
XN-DATA ind tHeadResponse
GET.Qnf ONE-BLOCK Ar 4- raw-dab)
(ReadResponse (Data-Bieck-Result11
LAST=FALSE, Block #2. (flata-mock-Rezai))
raw-dale)
GET.req (NEXT, I,
Block #2) XX-DATA_req
Dr ______ KX-DATAAnd
IFleaoRequesr — -0- P Read_incl
(Block-Nurnber-Aocess)) iReadReiues1
[Block-Nurntier-Accessil (Block12)
Pead.res,
XX-DATA.req ▪ (Last-.TRUE. Block p3.
xx_chaLTA.Ind 1RoadResponse
GET.cnf LAST-BLOCK -"t LReadResponse raw-dalal
4{LAS7-1- PrUE. clock *5, Data -Block-Resultij
{Dale-Block-Result»
raw-data)
r
Figure 83 - MSC of the Read Service used for reading an attribute_ with block transfer
9.4.6.8 Protocol for the Write service

As explained in 9.3.13, the Write service is used when the server uses SN referencing, either to
write (a) COSEM object attribute(s). or to invoke (a) method(s) when no return parameters are
expected:
• in the first case. the SET. request service primitives are mapped to Write.request primitives and the
Write - confirm primitives to SET.confirrn primitives_ The mapping and the corresponding SN APDUs are
shown in Table 52;
• in the second case, the ACTION. request service primitives are mapped to Writeseouest primitives and
the Write response primitives to ACTION.confirm primitives. The mapping and the corresponding SN
APDUs are shown in Table 53.
Table 52 - Mapping between the SET and the Write service
From SET.request To Write.request SN APDU

of type
NORMAL Write.reQuest WriteRequest ::= (variable-name I
(Variable_Access_Specitication, Data) parameterized-access, data)
Variable_Access Specification
Variable Name I Parameterized Access:
FIRST BLOCK
- Write.request Writeflequest ::
(Variable_Access_Specification. Data) (write-data-block-access, data)
Variable Access Specific-attion
Write_Da-ta_Bloc-k_Access;
with
Last Block = FALSE.
Black Number = 1.
Data = raw-data. carrying the encoded form
of the attribute reference(s) and write data.
ONE-BLOCK Write - request Writellequest ::=

(Variable_Access_Specification, Data) (write-data-block-access, data)
Variable_Access_Specification ,

OLMS User Association, COSEM Architecture and Protocols. Seventh Edition
From SET.request To Write.request SN APDU

of type
Write_Data_Block_Access;
with
Last Block = FALSE,
Block_Number --- next number.
Data = as above
LAST-BLOCK Write.request WriteRequest ::=

(Variable_Access_Specificalion, Data) (write-data - block-access, data)
Variable Access_Specification -
Write_Dita
_Bloc_A ccess;
with
Last Block = TRUE.
Block_Number = next number.
Data = as above
WITH-LIST Writesequest WriteRequest ::.
({Variable_Access_Specification), (Data)) ((variable-name I parameterized-access},
Variable_kcceS Specification -
{data})
Variable_Nanne I Parameterited_Access:
FIRST-BLOCK-WITH- Writesequest WriteRequest ::-
LIST (Variable_Access_Specilicalion, Data) (write-data-block-access, data)
Variable Access Specification =
with
Last_Block . FALSE.
Block_Number = 1
Data =as above
To SET.contirm of type SN APDU From Writo.resporiSO
NORMAL WriteResponse ;:= Writesesponse (Write_Result)
(success I data-access-error) Write_Result =
Success I Data_Access_Error:
ACK-BLOCK WriteResponse ::= (block-number) Wrile.response (Write_Result)
Write_Result = Block_Nurnber;
LAST-BLOCK WriteResponse ::= Write.response (Write_Result)
(success I data-access-error) Write_Result =
Success I Data
WITH-UST WriteFtesponse ::- Write.response ({Write_Result))
((success 1 data-access -error)) Write Result -
Success I Data Access Error;

LAST-BLOCK-WITH-LIST WriteResponse ::= Write response((Write_Resull))
((success I data -access-error }) Write_Result =
Success I Data_Access_Error;
Table 53 — Mapping between the ACTION and the Write service

From ACTION.request To Write.request SN APDU
of type
NORMAL Writesequest WriteRequest
(Variable_Access_Specilic-ation, Data) (variable-name, data
Variable Name;
Data method invocation parameters or
-
null-data
FIRST-BLOCK Write.request WriteRequest ::--
(Variable_Access_Specification. Data) [write-data-block-access. data)
Write_DataBlock_Access;
with
Last_Block = FALSE.
Block_Number = 1,
Data = raw-data, carrying the encoded
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7,0 192/310


of type
form of the method reference(s) and
method invocation parameters;
ONE-BLOCK Write.request WriteRequest ::=

(Variable_Access_Specification, Data) (write- data -block- access, data)
Variable_Access_Specilication =
with
Last_Block ,. FALSE,
Block_Number . next number,
Data = as above
LAST-BLOCK Write.request WriteRequest ::-

(Variable_Access_Specification. Data) (write-data-block-access, data)
with
LaSt_Block = TRUE,
Btock_Number = next number,
Data = as above
WITH-LIST Write.request WriteRequest ::-

{(Variable_Access_Specification}, (Data)) ({variable-name), {data})
Variable_Acces_Specification =
Variable_Name;
Data = method invocation parameters or
null data
WITH-LIST-AND-FIRST- Write.request Write Request :-.=

BLOCK {Variable_Access_Specification, Data) (write-data-block-access, data)
Variable_Access_Specification =
with
Last_Block .- FALSE,
Block_Number = 1.
Data - as with first block
To ACTION.confirm SN APDU From WrIte.response

NORMAL WriteResponse ::. Write.response (Write_Result)
{success I data-access-error) Write_Result
Success I Data_Access_Error
NEXT WriteResponse ::= (block-number) Write. response (Block_Number)

To ACTION.00nfirm SN APOU From WrIteseSpOrISO
WITH-LIST WriteResponse ::. Write. response ((Write_Result))
((success I data-access-error)) Write_Result =
Success I Data Access Error
I - -
Client Client Server

Client AL CF supporting supporting Server Server
AP with SN Proto col Protocol AL CF AP
MaPPIK Layer 000 Layer (M)
Dent and Server ALs in ASSOCIATED state. Lower Layer coonectioNs) established
SET.reg NORMAL ,
(LN Re_ Data} "" XX-DATA.req

(WnteRecakest 71 ---- — P XX-DATA_ ind
(WriteRequest
)
Writeind
1Vanable-Narner Detail (SN Ref., Data
(► ariable-Name. Data))
Writeses
XX-DATA.req (Success1
70C•DATAmd (WnteResponse
SET clot NORMAL (WriteResponse
4 (Success1)
Ill ISucon,s11
1
Figure 84 - MSC of the Write service used for writing an attribute
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0 [ 193/310

▪▪
Figure 84 shows the MSC of a Write service used to write the value of a single attribute, in the case
of success.
Figure 85 shows the MSC of a Write service used to invoke a single method_ in the case of success.
Client Server
Client Client suppochnrg supporINV Server Server
AP AL CF Protocol Protocol At CF AP
Layer 1)00 Layer (XK)
Client and Server ALs in ASSOCIATED state, Lome/ Layer eerineceents) es ablishol
ACTION.req NORMAL
(LN hnv, Pararn
• XX-DATA req
(Write Request )a-DATA.ind
---
(Yeriable-Narne. Data)) IWrneftecelest

lVanable-Name. Data II iSN Ref.. kw. Pararn
write res
KX-DATA.req • L5uccessS
XX - DATA Ind .4_ WinteResporise
ACTION cnf INFORMAL WriteResponse 'Success 1 r
Success) iS-uccessr
Figure 85 - MSC of the Write service used for invoking a method

Figure 86 shows the MSC of a Write service for writing a single attribute with the result returned in
three blocks.
The process of preparing and transporting the long data is essentially the same as in the case of
the SET and ACTION service:
If an error occurs, the server should return a Write.response service primitive with the
Data_Access_Error carrying an appropriate diagnostic information for example data-block - number-
invalid.
Client Server
Client Client SuPPorlin9 supporbnct Server
AP AL CF Protocol Prot:x04] AP
Layer tXX) Layer [XX)
Client and Server ALs in ASSOCIATED slate. Loser Layer ccchnectiorqs} established
SErnsq FIRST-BLOCK,
(LN Ref., LAST.FALSE.' XX-DATA req
11) Xx-OATA,rnd
Block MI., raw-Oalao (writer:mow --- --
P Wrhe,led (Last•FAL SE
(WriTe-Data-Block. lWrileRequest
prilnle.Dataalock- Bieck Ai raw idarai
Access. Datail
Acr-ess. Dalai!
Write re5
XX-DATA.reo Oick #1 1
XX-DATA.ind ----- (WrIleBeSOCckSe
SET cnf ACK-BLOCK 1 IWnteRspor
'Block #11
(Bloch-Number(l
(Eunck-Nurnoen)
SET.req ONE-BLOCK
(LAST=FALSE. Block oir- XX-DATA req
)WriteRequest XX-DATA_Ild
raw- data Si ▪ Write.rrd tLast=FALSE.,
1W rite-Data-Block- (WriteRequest
(Waite-Data-Bieck- Black 12. raw-data). m`.
Access. Data))
Access. Data))
Wnte res
xx-DATA req I
4 (Mock 42)
XX-DATA.ind {WriteResconse
SET.cnt ACK-BLOCK 4 {writeBesporme
ft (Ellock-Nurnber))
(Block 121 (Block - Nurnberg )
SET req LAST-BLOCK

(LAST.TRIJE, Book it3" XX, DATA.req
{WriteRqus XX-DATA. )rxi
raw-data) • Write.Ind tlast=TRUE,
(Write-Data-Dec.)4: (W nIeRequest
(Write -Data -BIWA- Bleck 13. raw-data}
Access. NW)
Accw.s. Wino)
Write.res
XX-DATAisci • (Success)
*C-DATA req 4 (WriteResconse
SET cnf LAST-BLOCK (WnteResponse
4 (tires)}
(Result Block 43) (Success,.)
1 1
Figure 86- MSC of the Write Service used for writing an attribute, with block transfer

Copyright 1997-2oo9 ca_NIS User Association
DLMS User Association. COSElvt Architecture and Protocols. Seventh Edition
9.4.6.9 Protocol for the UnconfirmedWrite service

This service may be invoked only when an AA has already been established. Depending on the
communication profile. the APDU corresponding to the request may be transported using the
connection-oriented or connectionless data services of the supporting protocol layer.
As explained in 9.3.14, the UnconfirmedWrite service may be used either to write (a) COSEM object
attribute(s), or to invoke (a) method(s) when no return parameters are expected:
• in the first case. the SET.request service primitives are mapped to UnconfirmedWrite.request primitives.
The mapping and the corresponding SN APDUs are shown in Table 54:
• in the second case. the ACTION.request service primitives are mapped to UnconfirmedWrite.request
primitives_ The mapping and the corresponding SN APDUs are shown in Table 55_
Table 54 - Mapping between the SET and the UnconfirmedWrite service
From SET.request To UnconfirmedWrite.request SN APDU
of type
NORMAL UnconfirmedWrite_request UnconfirrneclWriteRequest ::=

(Variable_Access_Specification, Data) (variable-name 1 parameterized-access,
Variable_Access_Specification = data)
Vanable_Name I Parameterized_Access;
WITH-LIST UnconfirmedWrite.request UnconfirmedWrrieRequesi ::=

(Wariabie_Access Speed-manor* Metal) ((variable-name I parameterized-access},
Variable_Acces_Specificatk)n = (data))
Variable_Name I Parameterized_Access:
Table 55 - Mapping between the ACTION and the UnconfirmedWrite service

of type
NORMAL Unconf[rmedWnte.requesl UnconfirrnedWnleFlequest ::=

( Variable_Access_Specification, Data) (variable-name, data)
Variable_Name:
Data = method invocation parameters or
null data
WITH-LIST UnconflrmedWrite_ request UnconfirmedWriteRequest ---

C(Variabie_Access_Specificalionl, (Data]) ((variable-name), {data})
Variable_Acces_Specification =
Variable_Name:
Data = as above
Figure 87 shows the MSC of a Write service used to write the value of a single attribute, in the case
of success.
Client Olen' Server

Client AL CF s ✓ pportiv supprzteg Server server
AP with SN Protocol Protocol AL CF
LAM MCI Layer POO
Client and Server ALs in ASSOCIATED state. Lower Layer conneclice(s) esLablished
SET.req NORMAL )
)U-DATA.req
(Unconfirmed XX-DATAind
(LN Ref.. Data:
WriteRecrues1 (Unctwirmeo
WrileRequest riteAnd
IVanable-Name. Dataji
(Variable-Name. DAM (SN Ref., Data)
Figure 87 — MSC of the Unconfirmed Write service used for writing an attribute
DLMS User Association 12009 - 12 - 22 DLMS UA 1000-2 Ed. 7.0 11 195/310

9.4.6.10 Protocol for the InformationReport service

The protocol for the InformationReport service, specified 9.3.15 in is essentially the same as that of
the EventNotification service, 9.4.6.6.
As, unlike the EventNotification service. the InformationReport service does not contain the optional
Application_Addresses parameter, the information report is always sent by the Server Management
Logical Device to the Client Management AP.
Upon invocation of the InformationRepart.request service. the server AP builds an

InformationReportRequest APDU. This APDU is sent from the SAP of the management logical
device to the SAP of the client management device, using data services of the lower layers, in a
non-solicited manner, at the first available opportunity.
The possibilities to send out this APDU depend on the communication profile and the connection
status of the lower layers. Therefore, the protocol of the InformationReport service is further
discussed in 10.
The InformationReport service may carry several attribute names and their contents. On the other
hand, the EventNotification service specified in 9.3.9 contains only one attribute reference.
Therefore, when the InforrnationFieportRequest APDU contains more than one attribute, it must be
mapped to several EventNotification,ind services, as shown in Table 56.
Table 56— Mapping between the EventNotification and InformationReport services
EventNoliticsrtion,ind (ono or more) IrdorrnationReporliod
Time (optional) Curren)-time (optional)

COSEM_Class Id, Variable_NametVariable_ Name}
CiOSEM_Object_instanceld,
COSEM_Object_Attribute _Id _
Attribute_Value Data {Data}

4) Copyright 1997-2009 DAIS User Association
1 -
9.5 Abstract syntax of ACSE and COSEM APDUs

The abstract sysntax of COSEM APDUs is specified in this clause using ASN.1. See IS011EC 8824.
COSEMpdu DEFINITIONS :: BEGIN
CI-PDU ::= CHOICE
pingPequestPDU (251 PingRequestPDU,

pingResponsePDU [26] PingResponsePDU.
reserved [27]
registerPDO [28] RegisterPDU,
discoverPDO [29) DiscoverPDU,
discoverReportPOU [30] DiscoverReportPDU,
repeaterCal1PDU [311 RepeaterCal1PDU,
clearAlarmPOU [57] ClearAlarmPDU
- CI-PDU tags are above 24, corresponding to the last unciphered DLMS APDU specified in
- IEC 61334-4-41.
xDLMS-APDU CHOICE
{
-- standardised xOLMS pdus used in DLMS/COSEM
-- standardized DLMS pdus
-- with no ciphering
initiateRequest [1] IMPLICIT InitiateRequest,

readReguest [5] IMPLICIT ReadReguest,
writeReguest [6] IMPLICIT WriteRequest,
initiateResponse [8] IMPLICIT InitiateResponse,

readResponse [12] IMPLICIT ReadResponse„
writeResponse [13] IMPLICIT WriteResponse,
confirmedServiceErrar [14] ConfirmedServiceError,
unconfirmedWriteRequest [22] IMPLICIT UnconfirmedWriteReguest,

informationReportRequest [24] IMPLICIT InformationReportReguest,
-- The APDU tag of each ciphered xDLMS APDU indicates the type of the unciphered APDIT and whether
-- global or dedicated key is used. The type of the key is carried by the security header, and after
-- removing the encryption and/or verifying the authentication tag, the original APDU with its APDU
-- tag is restored. Therefore, the APDU tags of the ciphered APDUs carry redundant information, but
-- they are retained for consistency.
- - with global ciphering
glo-initiateRequest [33] IMPLICIT OCTET STRING,

glo-readRequest 1371 IMPLICIT OCTET STRING,
glc-writeRequest [38] IMPLICIT OCTET STRING,
glo-initiateResponse 140] IMPLICIT OCTET STRING,

glo-readResponse [44] IMPLICIT OCTET STRING,
glo-writeResponse [45] IMPLICIT OCTET STRING,
glo-confirmedServiceErrar [46] IMPLICIT OCTET STRING,
gio-unconfirmedWriteRequest [54] IMPLICIT OCTET STRING,

glo-informationReportRequest [56] IMPLICIT OCTET STRING,
-- with dedicated ciphering
-- not used in DLMS/COSEM

ded-initiateRequest [65] IMPLICIT OCTET STRING,
ded-readRequest (69] IMPLICIT OCTET STRING,
ded-writeRequest PO] IMPLICIT OCTET STRING,
-- not used in DLMS/COSEM

ded-initiateResponse [72] IMPLICIT OCTET STRING,
ded-readResponse 176] IMPLICIT OCTET STRING,
ded-writeResponse 177] IMPLICIT OCTET STRING,
ded-confirmedServiceError [78] IMPLICIT OCTET STRING,
DLMS User Association 1209.12-22 DLMS UA 1000-2 Ed. TO 197/310

ded-unconfirmedNriteRequest [Rf] IMPLICIT OCTET STRING,

ded-informationReportRequest [8B] IMPLICIT OCTET STRING.
-- the four ACSE APD-Us

aarq AARQ-apdu,
aare AARE-apdu,
rlrq RLRQ-apdu, -- OPTIONAL
rlre RLRE-apdu OPTIONAL
-- XMAS APOUs used with LN referencing

-- with no ciphering
get-request (192j IMPLICIT GET-Request,

set-request (193] IMPLICIT SET-Request,
event-notification-request [194: IMPLICIT EVENT-NOTIFICATION-Request,
action-request r19.5 IMPLICIT ACTION-Request.
get-response (196 IMPLICIT GET-Response,

set-response (19 -+ IMPLICIT SET-Response,
action-response [199] IMPLICIT ACTICN-Response,
-- with global ciphering
glo-get-request [20C IMPLICIT OCTET STRING,

910-sec-request [201 IMPLICIT OCTET STRING,
glo-event-notification-request [202, OCTET STRING,
glo-action-request [203] IMPLICIT OCTET STRING,
glo-get-response (2041 IMPLICIT OCTET STRING,

glo-set-response (205' IMPLICIT OCTET STRING,
glo-action-response (20'6 IMPLICIT OCTET STRING,
-- with dedicated ciphering
ded-get-request (208] IMPLICIT OCTET STRING.

ded-set-request (2091 DWLICIT OCTET STRING,
ded-event-notification-request 1210) IMPLICIT OCTET STRING,
ded-actIonRequest (211] ILLICIT OCTET STRING,
ded-get-response (212] IMPLICIT OCTET STRING,

ded-set-response [2131 IMPLICIT OCTET STRING.
ded-action-response [2151 IMPLICIT OCTET STRING
-- the exception response pdu
exception-response [216] IMPLICIT ExceptionResponse
-- reserved (2301 -- OxE6

-- reserved (231) -- OxEl

DIMS User Association. COSEM Architecture and Protocols. Seventh Edition
AARQ-apdu [APPLICATION 0] IMPLICIT SEQUENCE
-- [APPLICATION 0] == [ 60H ] = ( 96 j
protocol-version [0] IMPLICIT BIT STRING tversionl (0)1 DEFAULT iversion11,

application-context-name Application-context-name,
called-AP-title [2] AP-title OPTIONAL,
called-AE-qualifier 131 AE-qualifier OPTIONAL.
called-AP-invocation-id AP-invocation-identifier OPTIONAL,
called-AE-invocation-id [5] AE-invocation-identifier OPTIONAL,
calling-AP-title [6] AP-title OPTIONAL,
calling-AE-qualifier 171 AE-qualifier OPTIONAL.
calling-AP-invocation-id 181 AP-invocation-identifier OPTIONAL,
calling-AE-invocation-id [ 9] AE-invocation-identifier OPTIONAL,
The following field shall not be present if only the kernel is used.
sender-acse-requirements [10] IMPLICIT AC2E-requirements OPTIONAL.
-- The following field shall only be present if the authentication functional unit is selected-
mechanism-name [II] IMPLICIT Mechanism-name OPTIONAL,
-- The following field shall only be present if the authentication functional unit is selected.
calling-authentication-value [12] EXPLICIT Authentication-value OPTIONAL,
implementation-information [29] IMPLICIT Implementation-data OPTIONAL,
user-information 1301 EXPLICIT Association- information OPTIONAL
-- The user-information field shall carry an InitiiteReguest APDU encoded in A-XDR, and then
-- encoding the resulting OCTET STRING in BER.
AARE-apdu z! [APPLICATION 1] IMPLICIT SEQUENCE
-- [APPLICATION 1] -- [ 61E [ 47 j
protocol-version ]n] IMPLICIT MT ETRMING [version' (O DEFAULT luersionlj,

application-context-name 111 Application-context-name,
result [21 Association-result,
result-source-diagnostic ]31 Associate-source-diagnostic,
responding-AP-title [4] AP-title or- T=1AL,
responding-AE-qualifier [5] AE-qualifier OPTIONAL,
responding-AP-invocation-id 1 61 AP-invocation-identifier OPTIONAL,
responding-AE-invocation-id 171 AE-invocation-identifier OPTIONAL,
-- The following field shall not be present if only the kernel is used.
responder-acse-requirements [81 IMPLICIT ACSE-requirements OPTIONAL,
mechanism-name [9] nomicrr Mechanism-name OPTIONAL,
responding-authentication-value [10] EXPLICIT Authentication - value OPTIONAL,
user-information (30] Explacm Association-information OPTIONAL
-- The user-information field shall carry either an Iniriatelkesponse tor, when the proposed xOLMS
-- context is not accepted by the server, a ConfirnedServiceError) APDU encoded in A-XDR, and then
-- encoding the resulting C.CTET STP'N 4 HER_ '
RLRQ-apdu ::= [APPLICATION 2] IMPLICIT SEQUENCE
- - [APPLICATION 2j == [ 62d I = [ xa 1
reason [0] IMPLICIT Release-request-reason OPTIONAL,
user-information EXPLICIT Association - information. OPTIONAL
RLRE-apdu ;;= [APPLICATION 3] IMPLICIT SEQUENCE
-- [APPLICATION 3] == [ 63R 1 =
reason 101 IMPLICIT Release-response-reason OPTIONAL

user-information [301 EXPLICIT Association-information OPTIONAL
-- The user-information field of the RLRQ / RLRE APDU may carry an InitiateRequest APDU encoded in
- A-7S0R, and then encoding the resulting OCTET STRING in 6ER, when the AA to be released uses
-- ciphering.
DLMS User Association 2009-12-22 DLMS LJA 1000-2 Ed. 7_0 199/310
ALMS User Association, COSEM Architecture and Protocols, Seventh Edition
-- types used in the fields of the ACSE AKA's. in the order of their occurrence
Application-context-name ::= OBJECT romarETER

AP-title ::.. OCTET Immo
AE-qualifier ::= octEr STEM
AP-invocation-identifier ::= TOTEM
AE-invocation-identifier ::= TEISSEEE
AC5E-requirements ::= BIT STRING tauthentication(0))
Mechanism-name ::= OBJECT IDENTIFIER
Authentication-value ::= COO=
CharStrit-57 [CO IMPLICIT GraphicString,

bitstring [1) IMPLICIT BIT STRING,
external [2) I)WLICIT EXTERNAL.
other [3] IMPLICIT SEQUENCE
other-mechanism-name Mechanism-name,
other-mechanism-value AMT 1>iT21SE ET other-mechanism-name
Implementation-data ::= araphicStang
Association-information ::- OCTET STRING
AssoCiatiOn-result :NTS=
accepted
rejected-permanent
rejected-transient
Associate-source-diagnostic :: ■ CSOICK
.105e-service-user [1! TETE=
null
no-reason-given
application-context-name-not-supported
authentication-mechanism-name-not-recognised
authentication-mechanism-name-required
authentication-failure
authentication-required
acae-service-provider
null
no - season - given
no-common-acse-version
Release-request-reason rwiscER
normal ( 0 ),
urgent (1),
user-defined (30)
Release-response-reason ::= INTEGER
normal (0),
not-finiahed (1),
user-defined (30)

DLMS User Association. GOSEM Architecture and Protocols. Seventh Edition
-- Useful types
Integer8 ::= INTEGER(-128.-123)

Integer16 ::= INTEGER(-32768.-32767)
Integer32 INTEGEtt(2147403648_2147483647)
Integer64 ::= INTEGER(-92233720360547758011-9223372036054775007)
Unsigned8 ::= INTEGER(0..255
UnsignedI6 1;= INTEGER(4_65535)
Unsigned32 T:= INTEGER(4,.4294967295)
Unsigned54 INTEGER(0-18446744073709551615)
CIASE APDUs
PingReguestPDU ;; SEQUENCE
{
system-title-server Zys=am-Title
PingResponsePDU ::- SEQUENCE
system-title-serv; System-Title
RegisterPDU ::= SEQUENCE

{
active-initiator-system-title System-Title,
list-of-correspondence Correspondence-List
DiscoverPDU ::= mom=

response-probability INTEGER(0..100),
allowed-time-slots INTEGER(0-.32767),
-- see IBC 61334-5-1 for the value .f mAX_INITIA1_CREDIT
DiscoverReport-initial-credit INTEGER(D—MAX_INITIAL_CREDIT),
ICEgnalCredit INTECER(0..1)
DiscoverReportPDU ::m sumonies

-- the first one of this list is the system-title of the reporting system
system-title-list. System-Title-List,
-- alarm-descriptor of the reporting system

alarm-descriptor Alarm-Descriptor OPTIONAL
RepeaterCal1PDU ::= SEQUENCE
max-adr-mac INTEGER “)-.4095),

nb-Tslot-for-new INTEGER .=;..255),
reception-threshold INTEGER ;r_,"..2E 1 DEFAULT =04
ClearAlarmPDU ;:= CHOICE
-- clears a single alarm in all servers

alarm-descriptor [0] Alarm-Descriptor,
-- clears a list of alarms in all servers

alarm-descriptor-list [11 Alarm-Descriptor-List,
- - clears a common list of alarms specified in the list of servers specified

alarm-descriptor-list-and-server-list [2] SEQUENCE
server-id-list System-Title- List,

alarm-descriptor-list Alarm-Descriptor-List
-- clears one alarm specified in each server specified

alarm-descriptor-by-server-list [3] Alarm-Descriptor-By-Server-List
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7,0 201/310

DENS User Associabon, COSEM Architecture and Protocols, Seventh Edition
-- Useful types used with the S-FSK PLC profile
- SYSTEM - TITLE - SIZE shall be specified by the naming authority

System-Title ::= OCTET STRING (STZEiSYSTEM-TITLE-SIZE))
System - Title - List SEQUENCE 01 system-Title
MAC-address ::= INTSGORM-4095)
Correspondence ::m =WINCE
new-system-title System-Title,
mac-address MAC-address
1
Correspondence-Liar. SEQUENCE OF Correspondence
Alarm- ❑ escriptrn INTEGER (0..2550
Alarm-Descriptov-L.:3 SEQUENCE OF Alarm-Descriptor
Alarm - DesCriptOr - By - Server :: - SEQUENCE
server-id System-Title,
alarm-descriptor Alarm-Descriptor
Alarm-Descriptor-By-Server-List ::. SEQUENCE OF Alarm-Descriptor-By-Server
-- The following has only local si.gr.L.:e on the client side.
CIASELooalError:: ■ ENUMUATIO
Other (0).
Discover-probability-out-of-range (1).
Discover-initial-credit-out-of-range (2),
DiscoverReport-list-too-long (3).
Register-list-too-Long (4).
rMluaICredic-out-of-range (5).
Ping no response
- - (6),
PIng-system-title-nok (7)
DLMS User Association 2009-12-22 DLMS LEA 1000-2 Ed. 7.0 202/310
(1) Copynght 1997-2009 DIMS User Association
- xDLMS AP00-s used during Association establishmen:
InitiateReguest ::= SEQUENCE
-- shall not be encoded in DLMS without ciphering

dedicated key - OCTET STRING OPTIONAL,
response-allowed BOOLEAN DEFAULT TRUE,
proposed-quality-of-service [0] IMPLICIT Integera OPTIONAL,
proposed-dims-version-number UnsignedE',
proposed-conformance Conformance -- Shall be encoded in BER
client -max-receive-pdu-size 0nsigned16
1
-- In DLMS/COSEM„ the quality-of-service parameter is not used. Any value shall be accepted.
-- The Conformance ' 4 .1d e a il he encoded in BER. See IEE 61334-6 Example 1.
InitiateResponL -. :: SEQUENCE
negotiated-quality-of-service [0] IMPLICIT Integer8 OPTIONAL,

negotiated -dlms-version-number Unsigned8,
negotiated-conformance Conformance, -- Shall be encoded in BER
server-max-receive-pdu-size Unsigned16,
vaa-name ObjectName
-- In the case of LN referencing, the value of the vaa-name is 0x0007

-- In the case of SN referencing, the value of the vaa-name is the base name of the
-- Current Association object, 0xFA00
-- Conformance Block
-- SIZE constrained BIT STRING is extension of AsN.1 notation
Conformance ::• [APPLICATION 31] IMPLICIT NI? grErEa
-- the bit is set when the corresponding service or functionality is available

reserved-zero (0),
reserved-one (1),
reserved-two (2),
read (3),
write (4),
unconfirmed-write (5),
reserved-six (6),
reserved-seven (7),
attribute0-supported-with-set (8),
priority-mgmt-supported (9),
attribute0-supported-with-get (10),
block-transfer-with-get-or-read (11),
block-transfer-with-set-or-write [12),
block-transfer-with-action (13),
multiple-references (14),
information-report (15],
reserved-sixteen (161,
reserved-seventeen (171,
parameterized-access (181,
get (191.
set (20),
selective-access (21),
event-notification (22),
action (23)
l(SIZE(24))
ObjectName ::= Integer16

-- for named variable objects (short names), the last three bits shall be set to 000;
- fer vaa - name objects, the last three bits shall be set to 111.

0 Copyright 1997-2009 DIMS User Association
DLMS User Association, GOSEM Architecture and Protocols, Seventh Edition
-- The Confirmed ServiceError APDU is used only with the InitiateRequest, ReadRequest and
- WriteRequest APDUs when the request fails, to provide diagnostic information.
ConfirnedServiceError ::= CWT.=

1
-- tag 0 is reserved
-- In DLMS/COSEM only in itiateEror, read and write are relevant
initiateError [11 ServiceError,

getStatus [21 ServiceError,
getNameLis [3] ServiceError,
getVariableAttribute [4] ServiceError,
read 151 ServiceError,
write [61 ServiceError,
getDataSetAttribute (7) ServiceError,
getitAttribute (8] ServiceError,
changeScope [9] ServiceError,
start (10 ServiceError,
stop [11 ServiceError,
resume [12 ServiceError,
makeUsable (13 ServiceError,
initiateLoad (14 ServiceError.
loadSegment [15 ServiceError,
terminateLoad (16 ServiceError,
initiateUpLoad (17 ServiceError.
uploadSegment (18 ServiceError.
terminateUpLoad (19 ServiceError
ServiceError ::• CROICA
application-reference [01 IMPLICIT SKUNCRATED

1
-- DIMS provider Only
other (0),
time elapsed
- (1). -- time out since request sent
application-unreachable (2). -- peer AEi not reachable
application-reference-invalid (3), -- addressing trouble
application-context-unsupported (4), -- application-context incompatibility
provider-communication-error (5), -- error at the local or distant equipment
deciphering-error (6) -- err , , 1., tected by the deciphering function
1,
hardware-resource IMPLICIT ENUMERATED

1
- VDE hardware troubles
Other
memory-unavailable
processor-resource-unavailable
mass-storage-unavailable
other - resource - unavailable
ude-state-error 12] ERPLIC/T ENUMERATED
- - Error source description

other
no-dims-context
loading-data-set
status-nochange
status-inoperable
service (3, IMPLICIT ENUMERATED

1
-- service handling troubles
other (0),
pdu-size (1), -- pdu too Long
service-unsupported (2) -- as defined in the conformance block
DLMS User Association 2009.12-22 DLMS UA 1000-2 Ed. 7M I 204/310

definition [4] IMPLICIT ENUMERATED
-- object hound troubles in a service

other (0) •
object-undefined (1), -- object not defined at the VDE
object-class-inconsistent (2), -- class of object incompatible with asked service
object-attribute-inconsistent (3) -- object attributes are inconsistent
1,
access [5] IMPLICIT ENUMERATED
-- object access error

other (01,
scope-of-access-violated (1), -- access denied through authorisation reason
object-access-violated (2), -- access incompatible with object attribute
hardware-fault (31, -- access fail for hardware reason
object-unavailable ;41 V108 hands object for unavailable
initiate MI IMPLICIT ENUMERATED
-- initiate service error

other (0),
dims-version-too-low (11, -- proposed DLMS version too low
incompatible-conformance 521, -- proposed service not sufficient
pdu-size-too-short (31. -- proposed PDU size too short
refused-by-the-VDE-Handler (4) -- vaa creation impossible or not allowed
load-data-set [7] IMPLICIT ENUMERATED
-- data set load services error

other (01
primitive-out-of-sequence (1). -- according to the DataSet loading state
transitions
not-loadable (2), -- loadable attribute set to FALSE
dataset-size-too-Large (31, -- evaluated Data Set size too large
not-awaited-segment (41, -- proposed segment not awaited
interpretation-failure (51. -- segment interpretation error
storage-failure (6), -- segment storage error
data-set-not-ready (71 -- Data Set not in correct state for uploading
-- change-scope [0] rmPtrcIT ENUMERATED
Cask IMPLICIT ENUMERATED
TI services error
other (01,
no-remote-control (11, -- Remote Control parameter set to FALSE
ti-stopped (2), -- TI in stopped state
ti-running (3), -- TI in running state
ti-unusable (4) -- TI in unsable state
-- other [1C: IMPLICIT ENUMERATED
ALMS User Association 2009-12-22 DLMS UA 1000-2 Ed_ 7.0 205/310

C-ocynont 1 R97 -21:109 DLMS User Association
-- COMM APDOs using short name referencing
ReadRequest ;:= SEQUENCE OF 'iariable-Access-Specification
ReadResponse SEQUENCE OF CHOICE
data :ata,
data-access-error INPI.ICIT Data-Access-Result,
data block result
- - [2] init./CI'? Data - Block - Result,
block number
- [3] IMPLICIT Unsigned16
WriteRequest ::= SEQUENCE
variable-access-specificatic::. SEQUENCE OF Variable Access Specification,

- -
list-of-data SEQUENCE OF Data
WriteResponse ::= SEQUENCE OF CHOICE
success IMPLICIT NULL,

data access error
- - imPLICIT Data Access Result,
- -
block-number A'ned16
UnCOnfirmedWritOReql,10$t !:- SEQUENCE
variable-access-specification SEQUENCE OF Variable-Access-Specification,

list - of - data SEQUENCE OF Data
InformstionReportRequest 1: , SEQUENCE
current-time SeneralizedTime OPTIONAL,

variable-access-specificati oc SEQUENCE OF Va:'labje Access Specification,
-
list-of-data SEQUENCE OF Data
COSEM APOUs using logical name referencing
Get-Request :; ■ CHOICE
get-request-normal [1: IMPLICIT Get-Request-Normal,

get-request-next (2! IMPLICIT Get-Request-Next,
get-request-with-list (3; IMPLICIT Get-Request-With-List
Get-Request-Normal 1: - SEQUENCE
invoke-id-and-priority Invoke-Id-And-Priority,
cosem-attribute-descriptor Cosem-Attribute-Descriptor,
access-selection Selective-Access-Descriptor OPTIONAL
Get-Request-Next ::= SEQUENCE
block-number Onsigned32
Get-Request-With-List 1: SEQUENCE
invoke-id-and-priority Tnvoke-Id-And-Priority,
attribute-descriptor-list SEQUENCE OF Cosem-Attribute-Descriptor-With-Selection
Get-Response ::= CHOICE
get-response-normal lit IMPLICIT Get-Response-Normal,

get-response-with-datablock (21 IMPLICIT Get-Response-With-Datablock,
get-response-with-list [3] IMPLICIT Get-Response-With-List
Get-Response-Normal ::. SEQUENCE
result Get-Data-Result
I DLMS User Association 2009-12.22 DLMS UA 1000-2 Ed. 7.0

2061310
Get-Response-With-Datablock SEQUENCE
result DataBlock-G
Get-Response-With-List ::= SEQUENCE
invoke-id-and-priority 1. _.,-:nd-Priority,
result SEQUENCE OF Get - Data - Result
Set-Request ::= comae

set-request-normal [1] I! LICIT Set-Request-Normal,
set-request-with-first-datablock [2] IMPLICIT Set-Request-With-First-Datablook,
set-reqvest-mith-datablock [3] IMPLICIT Set-Request-With-Datablock,
set-request-with-list [4] IMPLICIT Set-Request-With-List,
set-request-with-list-and-first-dat ablock [51 IMPLICIT Set-Request-With-List-And-First-Datablock
Set-Request-Normal SEQUENCE
access-selection Selective-Access-Descriptor OPTIONAL,
value Data
Set-Request-With-First-DatabIock :: SEQUENCE
access-seiection Selective-Access-Descriptor OPTIONAL,
datablock DataBLock-SA
Set-Request-With-Datablcck ::= SEQUENCE
datablock DataBlock-SA
Set-Request-With-List SEQUENCE
attribute-descriptor-list SEQUENCE OF Cosem-Attribute-Descriptor-With-Selection,
value-list SEQUENCE OF Data
Set-Request-With-List-And-First-Datablock SEQUENCE
1
attribute-descriptor-list SEQUENCE OF Cosem-Attribute-Descriptor-With-Selection,
datablock Da:aBlocK-SA
Set-Response ::= CHOICE
set-response-normal 11: IMPLICIT Set-Response-Normal,

set-response-datablock 12: IMPLICIT Set-Response-Datablock,
set-response-last-datablock 13: IMPLICIT Set-Response-Last-Datablock,
set-response-last-datablock-with-list IMPLICIT Set-Response-Last-Datablock-With-List,
set-response-with-list [5: IMPLICIT Set-Response-With-List
Set-Response-Normal :;= SEQUENCE
result Data-Access-Result
Set-Response-Datablock ::- SEQUENCE
block-number Unsigned32

Copyright 1997 - 2009 DLMS User- Association
Set-Response-Last-DaLablock :: SEQUENCE
result Data-ACCeSS-R e sult,
Set-Response-Last-Datablock-With-List ::= SEQUENCE
result SEQUENCE OF Data-Access-Result,
Set-Response-With-List ::= SEQUENCE
Invoke-id-and-priority !nvoke-td-And-Priority,
result SEQUENCE OF Data-Access-Result
Action--Request ::= C210/01
action-request-normal 11 IlMLICIT Action-Request-Normal,

action-request-next-pblock 21 IMPLICIT Action-Request-Next-Phlock,
action-request-with-list 3] IMPLICIT Action Request Witb List,
- - -
action-request-with-first-pblock 4] IMPLICIT Action-Request-With-Pirst-Phlock,

action-request-with-list-and-first-pblock 5) IMPLICIT Action-Request-With-List-And-First-Phlock,
action-request-with-pblock 6] IMPLICIT Action-Request-With-Phlock
Action-Request-Normal ::- mums=

cosem-method-descriptor Cosem-Method-Descriptor,
method-invocation-parameters Data OPTIONAL
Action-Request-Next-Pblock ::• SEQUENCE

{
Action-Request-With-List ::. SEQUENCE
cosem-method-descriptor-list SEQUENCE OF Cosem-Method-Descriptor,
method-invocation-parameters. SEQUENCE Cr Data
Action-Request-With-First-Pblock ::m SEQUENCE
invoke-id-and-priority Invoke--Id-And-Priority,
cosem-method-descriptor Cosem-Method-Descriptor,
pblock DataBlock-SA
Action-Request-With-List-And-First-pblock ::= SEQUENCE
cosem-method-descriptor-list SIM= Of Cosem-Method-Descriptor,
pblock Datanock-SA
Action-Request-With-Phlock ::m SWIM=
pblock DataBlock-SA
Action-Response ::= CMOICZ
action-response-normal [1] IMPLICIT Action-Response-Normal,

action-response-with-pblock [2] IMPLICIT Action-Response-With-Pblock,
action-response-with-list [31 IMPLICIT Action-Response-With-List,
action-response-next-W.-oak [4] IMPLICIT Action-Response-Next-Pblock
DUNES User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 1208/3101

Action-Response-Normal ::. SEQUENCE
single-response Action-Response-With-Optional-Data
Action-Response-With-Pblock ::= SEQUENCE

{
pblock DataBlock-SA
Action-Response-With-List ::= SEQUENCE
list-of-responses swam= OF Action-Response-With-Optional-Data
Action-Response-Next-Pblock ::= SEQUENCE

{
invoke-id-and-priority Invoke-id-And-Priority,
EventNotificationRequest ::= SEQUENCE
time OC222 STAMM oettomAL,

attribute-value Data
ExceptionResponse ::= SEQUENCE
state-error ',Ali IMPLICIT ENUMERATED
service-not-allowed (1),
service-unknown (2)
ir
service-error [1] ZNPLIC/T ENUMERATED
operation-not-possible (1),
service-not-supported (2),
other-reason (3)
1

0 Copyright 1997-20[19 DLMS User Associat.cn
-- Types used in the xOLMS data transfer services
Variable-Access-Specification ::= CHOICE
variable-name [21 IMPLICIT ObjectName,

-- detailed-access (31 is not used in DLMS/COSEM
parameterized-access [4] IMPLICIT Parameterized-Access,
block-number-access [5: IMPLICIT Block-Number-Access,
read-data-block-access [6: IMPLICIT Read-Data-Block-Access,
write-data-block-ac ,:e5s IMPLICIT Write-Data-Block-Access
Varameterired - RCCeS -: SEQUENCE

{
variable-name ObjectName,
selector Unsigneda,
parameter Data
Block - Number-Access : SEQUENCE
Read-Data-Block-Access 11 SEQUENCE
last-block BOOLEAN.
block-number
raw-data OCTET STRING
write-Data-Black-Access SEQUENCE
last-block DOOL.E.AN.
block-number
Data !:. CHOICE
null-data [0] IMPLICIT NULL,

array (1] IMPLICIT sEQuENCE or data,
structure [2] IMPLICIT SEQUENCE OF Data,
boolean (3] IMPLICIT BOOLEAN.
bit-string [4] IMPLICIT BIT STRING,
double-long [51 IMPLICIT
double-long-unsigned (6] IMPLICIT Unsigned:_,
floating-point (7) IMPLICIT OCTET STRINGISIZE(4)) ,
octet-string (91 IMPLICIT OCTET STRING,
visible-string [10 IMPLICIT VisibleString,
bcd [13 IMPLICIT IntegerS,
integer (15 IMPLICIT IntegerS,
long [16 IMPLICIT Integer16,
unsigned [17 IMPLICIT UnsignedB,
long-unsigned [18 IMPLICIT Unsigned16,
compact-array (19 IMPLICIT =WINCE
contents-description TypeDescription,
array-contents (1] IMPLICIT OCTET STRING
long64 [201 IMPLICIT Integer64,

long64-unsigned (211 IMPLICIT Unsigned64,
en um 1221 IMPLICIT
float32 (231 IMPLICIT OCTET STRING .SIZE.(4),
float64 (241 IMPLICIT OCTET STRING (SIZE401),
date_time [251 IMPLICIT OCTET STRING (SIZE{12)).,
date [261 IMPLICIT OCTET STRING {SI2E(5)).
tine [271 IMPLICIT OCTET STRING ,STZE(4)),
dont-care [255] IMPLICIT NULL

() Copyright 1997-2009 DLMS User Association
-- The following TvpeCescrintion relates to the c:::: - nact-array data Type
TypeDescription ;= CHOICE
{
null data
- [0] IMPLICIT NULL,
array [1] IMPLICIT SEQUENCE
number-of-elements Unsigned/6,
type-description TypeDesoription
1,
structure [2] IMPLICIT SEQUENCE OF TypeDescription F
boolean 13] IMPLICIT NULL,
bit-string 14] IMPLICIT NULL.
double-long 15] IMPLICIT NULL,
double-long-unsigned [6] min= NULL,
floating-point [7] IMPLICIT NULL,
octet - string [9] IMPLICIT NULL,
visible-string [10] IMPLICIT NULL,
bad [13] IMPLICIT NULL,
integer [15] IMPLICIT NULL,
long (16] IMPLICIT NULL,
unsigned [17] IMPLICIT NULL,
long-unsigned [18] IMPLICIT NULL.
long64 [20] IMPLICIT NULL.
long64-un5igned [21] IMPLICIT NULL,
enum [22] IMPLICIT NULL,
float32 [23] IMPLICIT NULL,
float64 [24] IMPLICIT NULL,
date_time [25] IMPLICIT MULL,
date [26] IMPLICIT NULL,
time [27] IMPLICIT NULL,
dont-care [25 ] IMPLICIT NULL
Data-Access-Result :: ENUMERATED
[
success (0),
hardware-fault (1),
temporary-failure (2),
read-write-denied (3),
abject-undefined (4),
object-class-inconsistent (9),
object-unavailable (11),
type-unmatched (12),
scope-of-access-violated (13),
data-block-unavailable (14),
long-get-aborted (15),
no-long-get-in-progress (16),
long-set-aborted (17),
no-long-set-in-progress (18),
data-block-number-invalid (19),
other-reason (250)
Action-Result ::= ENUMERATED
success (0).
hardware-fault (1),
temporary-failure (2),
read-write-denied (3),
object-undefined (4),
object-class-inconsistent (9).
abject-unavailable (11),
type-unmatched (12),
scope-of-access-violated (13),
data-block-unavailable (14),
long-action-aborted (15),
no-long-action-in-progress (16),
other-reason (250)
DLMS User Association 2009-12-22 1DLMS UA 1000-2 Ed. 7.0 11 211/310

-- SIZE constrained BIT STRING is extension of ASN.1 notation
Invoke-Id-And-Priority :!= BIT STRING
invoke-id-zero (CO,
invoke-id-one (1),
invoke-id-two (21,
invoke-id-three (3)r
reserved-four Lfl,
reserved-five (5),
service class {6), -- 0 • 'Unconfirmed, I • Confirmed
priority {7) -- 0 .• normal, 1 • high
)(S/ZE(8))
-- Alternative use of Invoke-Id-And-Priority

-- Invoke-Id-And-Priority :: Unsigned8
Cosem-Attribute-Descriptor :. MUMS=
class-id Cosem-Class-Id,
instance-id Cosem-Object-Instance-Id,
attribute-id Cosem-Object-Attribute -Id
Cosem-Method-Descriptor :: SEQUENCE
class-id Cosem-Class-2d,
instance-id Cosem-abject-Instance-Id,
method-id Cosem-Object-Method-Id
Cosem-Class-Id :: ■ Unsignedl6
Cosem-Object-Instance-Id ::= OCTET STRIMO(SIZEI61)
Cosam-Object-Attribute-Id ::= IntegerS
Cossm-Object-Method-Id ::=
Selective-Access-Descriptor lt ■ SEQUENCE
access-selector Unsigned8,
access-parameters Data
Cosem-Attribute-Descriptor-With-Selection ::= SEQUENCE
coaem-attribute-descriptor Cosem-Attribute-Descriptor,
access-selection Selective-Access-Descriptor OPTIONAL
Get-Data-Result it.• CND=

data (0) Data,
data-access-result [1] IMPLICIT Data-Access-Result
Data Block Resu lt

- - SEQUENCE Jsed in ReadResponse with block transfer
last-block ROOLMAN,
block-number
D at a Elo c k- G SEQUENCE - G •• DataElock for the GET-response
last-block BOOLEAN,
block-number :nsigned32,
result CHOICE
{
raw-data [0) IMPLICIT OCTET STRING,
data-access-result fl! IMPLICIT Data-Access-Result

DAIS User Association, COSEM Architecture and Protocols, Seventh Edition
DataBlock - *A :: ■ SEQUENCE -- SA ■■ DataBlock for the SET-request, ACTION-request and ACTION-response
last-block BOOLEAN
block-number Unsiigned32,
Action-Response-With-Optional-Data ..- SEQUENCE
result Action-Fiesu -..te

return-parameters Get-Data-Result OPTIONAL
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7M 213/310

DUOS User Association, COSEM Architecture and Protocols. Seventh Edition
10. Using the COSEM application layer in various

communications profiles
10.1 Communication profile specific elements

10.1.1 General
As explained in 4, the COSEM interface model for energy metering equipment, specified in DLMS
UA 1000-1 has been designed for use with a variety of communication profiles for exchanging data
over various communication media. As shown in Figure 3. in each such profile. the application layer
is the COSEM AL. providing the xDLMS services to access attributes and methods of COSEM
objects. For each communication profile, the following elements must be specified:
• the targeted communication environments;

• the structure of the profile (the set of protocol layers):
• the identification/addressing scheme:
• mapping of the COSEM AL services to the service set provided and used by the supporting layer;
• communication profile specific parameters of the COSEM AL services:
• other specific considerations/constraints for using certain services within a given profile.
10.1.2 Targeted communication environments

This part identifies the communication environments, for which the given communication profile is
specified.
10.1.3 The structure of the profile

This part specifies the protocol layers included in the given profile.
10.1.4 Identification and addressing scheme

This part describes the identification and addressing schemes specific for the profile.
As described in DLMS UA 1000.1 Clause 4.1.7, metering equipment are modeled in COSEM as
physical devices, containing one or mare logical devices. In the COSEM client/server type model,
data exchange takes place within AM, between a COSEM client AP and a COSEM Logical Device,
playing the role of a server AP,
To be able to establish the required AA and then exchanging data with the help of the supporting
lower layer protocols, the client- and server APs must be identified and addressed, according to the
rules of a communication profile. At least the following elements need to be identified/addressed:
• physical devices hosting clients and servers;

• client- and server APs;
The client- and server APs need also to identify the AAs.
10.1.5 Supporting sayer services and service mapping

This part specifies the service mapping between the services requested by the COSEM AL and the
services provided by its supporting layer.
In each communication profile. the COSEM AL provides the same set of services to the client- and
server APs. However, the supporting protocol layer in the various profiles provides a different set of
services to the service user AL
The service mapping specifies how the AL is using the services of its supporting layer to provide
ACSE and xDLMS services to its service user. For this purpose generally MSCs are used showing
the sequence of the events following a service invocation by the COSEM AP.

Copynghi 1997-2009 DLMS User Association
10.1.6 Communication profile specific parameters of the COSEM AL

services
In COSEM. only the COSEM-OPEN service has communication profile specific parameters. Their
values and use are defined as part of the communication profile specification.
10.1.7 Specific considerations 1 constraints using certain services

within a given profile
The availability and the protocol of some of the services may depend on the communication profile.
These elements are specified as part of the communication profile specification.
10.2 The 3-layer, connection-oriented, HDLC-based

communication profile
The 3-layer, CO. HDLC-based profile is suitable for local data exchange with metering equipment
via direct connection, or remote data exchange via the PSTN or GSM networks_
10.2.2 The structure of the profile

This profile is based on a three-layer (collapsed) 051 protocol architecture:
• the COSEM AL. specified in Clause 9:

• the data link layer based on the HDLC standard. specified in Clause 8:
• the physical layer: specified in Clause 5. The use of the PhL for the purposes of direct local data
exchange using an optical port or a current loop physical interface is specified in Clause 6.

The HDLC-based data link layer provides services to the COSEM AL at Data Link SAP-s. also
called as the Data Link- or HDLC addresses.
On the client side, only the client AP needs to be identified. The addressing of the physical device
hosting the client AF's is done by the PhL (for example by using phone numbers).
On the server side. several physical devices may share a common physical line (multidrop
configuration). In the case of direct connection this may be a current loop as specified in IEC
62056-21. In the case of remote connection several physical devices may share a single telephone
line. Therefore both the physical devices and the logical devices hosted by the physical devices
need to be identified. This is done using the HDLC addressing mechanism as described in Clause
8.4.2:
• physical devices are identified by their lower HDLC address:

• logical devices within a physical device are identified by their upper HDLC address:
• a COSEM AA is identified by a doublet. containing the identifiers of the two APs participating in the
AA.
For example, an AA between Client 01 (HDLC address T 16) and Server 2 in Host Device 02
(HDLC address = 2392) is identified by the doublet (16. 2392). Here. "23 - is the upper HDLC
address and "92" is the lower HDLC address_ All values are hexadecimal_ This scheme ensures that
a particular COSEM AP (client or server) may support more than one AA simultaneously without
ambiguity_ See Figure 85.
DLMS User Association 2009.12-22 DLMS UA 1000-2 Ed. 7.0 215/310

HOST Device Of for Servers HOST Device 02 for Serve's

HOS TDeAce for Chem;
co
Approzifion
lorocativa
and Ey
COSEM
Acohorton
Layer
A
Profvcod Laws
of me IM AC
tuned peNie
Figure 88 — Identificafioniaddressing scheme in the 3-layer, CO, HDLC-based communication profile
10.2.4 Supporting layer services and service mapping

In this profile, the supporting layer of the COSEM AL is the HDLC based data link layer. It provides
services for:
• data link layer connection management;

• connection-oriented data transfer;
• connection-less data transfer.
Figure 89 summarizes the data link layer services provided for and used by the COSEM AL.
The DL-DATA.conlirm primitive on the server side is available to support transporting long
messages from the server to the client in a transparent manner to the AL. See 10.2.6.5.
In some cases, the correspondence between an AL (ASO) service invocation and the supporting
data link layer service invocation is straightforward. For example, invocation of a GET,request
primitive directly implies the invocation of a DL-DATA.request primitive.
In some other cases a direct service mapping cannot be established. For example, the invocation of
a COSEM-OPEN.request primitive with Service_Class == Confirmed involves a series of actions,
starting with the establishment of the lower layer connection with the help of the DL-CONNECT
service, and then sending out the AARQ APDU via this newly established connection using a DL-
DATA.request service. Examples for service mapping are given in 9.4.
Client side application layer Server side application layer
I
1
D•DISCONNECT. cri f
PL- DISCONINEC T. ind

CL-CONNECT. ind
DL-CONNECT.CrIf
DL-DATA. req
g
DL-DATA...e n!
0
z
S
0,
O
6 a 2
a
oliem side data Iir1k aye' Server side data fink layer
Figure 89 — Summary of data link layer services
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 216.'310

(D. Copyright 1997-2009 DLMS User Assoaation
10.2.5 Communication profile specific service parameters of the

COSEM AL services
Only the COSEM-OPEN service has communication profile specific parameters. the
Protocol_Connection Parameters parameter. This contains the following data:
• Protocol (Profile) Identifier 3-Layer. connection-oriented. HDLC-based:

• Server Lower MAC_Address (COSEM Physical Device Address):
• Server_Upper_MAC_Address (COSEM Logical Device Address);
• Client_MAC_Address:
• Server LLC_Address:
• Client LLC_Address
Any server (destination) address parameter may contain special addresses (All-station, No-station.
etc.). For more information, see Clause 8.
10.2.6 Specific considerations / constraints

10.2.6.1 Confirmed and unconfirmed AAs and data transfer service invocations,
frame types used
Table 57 summarizes the rules for establishing confirmed and unconfirmed AAs, the type of data
transfer services available in such AAs and the HDLG frame types that carry the APDU-s. This table
clearly shows one of the specific features of this profile: the Service_Class parameter of service
invocations is linked to the frame type of the supporting layer:
• if the COSEM-OPEN service — see 92.2 — is invoked with Service_Class == Confirmed, then the AARQ
APDU is carried by an 1" frame. On the other hand, if it is invoked with Service Class == Unconfirmed, it
is carried by a - ur frame. Therefore. in this profile. the response-allowed parameter of the xDLMS
InitiateRequest APDU has no significance. See also 9.4.41:
• similarly, if a data transfer service .request primitive is invoked with Service_Class == Confirmed. then
the corresponding APDU is transported by an 1' frame. If it is invoked with
Service_class == Unconfirmed. then the corresponding APDU is carried by a "Ul - frame. Consequently,
bit 6 of the Invoke-Id-And-Priority field — see 9.5 — is not relevant in this profile.
Table 57 — Application associations and data exchange in the 3-layer. CO. HDLC-based profile
Application association establishment Data exchange
Protocol
COSEM-OPEN Type of
connection Use Service class Use
service class established AA
parameters
11 Connect data
link layer Confirmed - I' frame
2/ Exchange
Confirmed AAROiAARE Confirmed
Id' HOLC APDU-s

transported in T Unconfirmed - UI' frame
LLC and MAC frames
addresses
Confirmed (not _
allowed)
Send AARQ in a
Unconfirmed Unconfirmed '
`Ur frame
Unconfirmed - Ul" frame
10.2.6.2 Correspondence between AAs and data link layer connections. releasing
AAs
in this profile, a confirmed AA is bound to a supporting data link layer connection , in a one-to-one
basis. Consequently:
• establishing a confirmed AA implies the establishment of a connection between the client and server
data link layers:
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 11 217:310

Copyright 1997-2009 DLMS User AssocLation
• a confirmed AA in this profile can be non-ambiguously reteased by disconnecting the corresponding data
link layer connection.
On the other hand, in this profile establishing an unconfirmed AA does not need any lower layer
connection: consequently, once established, unconfirmed AAs with servers not supporting the
ACSE A-RELEASE service (see 9_3.3 and 9_4_5) cannot be released.
10.2.6.3 Service parameters of the COSEM-OPEN / -RELEASE / -ABORT services

Thanks to the possibility to transparently transport higher layer related information within the SNRIVI
and DISC HDLC frames. this profile allows the use of the optional "User Information' parameter of
the COSEM-OPEN — see 9.3.2— and COSEM-RELEASE see 9.3.3 — services:
• the User_Information parameter of a COSEM-OPEN.request primitive. if present, is inserted into the

"User data subfield" of the SNRM frame. sent during the data link connection establishment;
• if the SNRM frame received by the server contains a "User data subfield", its contents is passed to the
server AP via the User_Information parameter of the COSEM-OPEN.indication primitive:
• the User Information parameter of a COSEM-RELEASE request primitive. if present, is inserted into the
"User data subfield" of the DISC frame, sent during disconnecting the data link connection:
• if the DISC frame received by the server contains a "User data subfield". its contents is passed to the
server AP via the User_Information parameter of the COSEM-RELEASE.indication primitive:
• the User_Information parameter of the COSEM-RELEASE response primitive. if present. is inserted into
the "User data subfield" of the UA or HDLC frame, sent in response to the DISC frame:
• if the UA or DM frame received by the client contains "User data subfield", its contents is passed to the
client AP via the User_Information parameter of the COSEM-RELEASE.confirm primitive.
In addition, for the COSEM-ABORT.indication service. the following rule applies:
• the Diagnostics parameter of the COSEM-ABORT.indication primitive — see 9.3.4 — may contain an
unnumbered send status parameter. This parameter indicates whether, at the moment of the physical
abort indication, the data link layer has or does not have a pending Unnumbered Information message
(UI). The type and the value of this parameter is a local issue, thus it is not within the scope of this
companion specification. See also 8.2.3.3.
10.2.6.4 EventNotification service and protocol
This sub-clause describes the communication profile specific elements of the protocol of the
EventNotification service, see 9.4.6.6.
In this profile, an event is reported always by the server management logical device (mandatory,
reserved upper HDLC address Ox01) to the client management AP (mandatory, reserved HDLC
address Ox101.
The EventNotificationRequest APDU is sent using cennectionless data services. using an UI frame,
at the first opportunity. i.e, when the server side data link layer receives the right to talk. The APDU
shall fit into a single HDLC frame. To be able to send out the APDIU, a physical connection between
the physical device hosting the server and a client device must exist, and the server side data link
layer needs to receive the token from the client side data link layer.
If there is a data link connection between the client and the server when the event occurs, the
server side data link layer may send out the PDU — carrying the EventNotificationRequest APDU —
following the reception of an I, a UI or an RR frame from the client. See 8.4.5.4.7.
Figure 90 shows the procedure in the case. when there is no physical connection when the event
occurs (but this connection to a client device can be established).
NOTE Physical connection cannot be established when the server has only a local interface for example an optical port
as defined in IEC 62056-21) and the FiFILI, running the client application is not connected, or the server has a PSTN
interface. but the telephone line is not available. Handling such cases is implementation specific.

© Copyright 1997-2009 MAAS User Association
Cheri Server
Caere Server Server
physical Client man- Server man-
SuppOrtakt Cheri Server trgirlerilra aPPbOlK:a
connection agement aggrieve connection
protocol PhYstcal physical protocol Toyer
and protocol application applicabon and protocol
Hien/Ai:2ton process LaYer sara Larg Lai(' POROOI
pmcess idenliftcation
{XX) km1E:Jon
manager manger
Ne physical camactim r& estabhSeped betvraeo the SONO, and client devices
1 1 1
Event po be holifted) ts detscled
PH-COENECT_ Iq
Ffirocal conned:or
"1-1- v v! eslablithirect PH-CDNINECT.cri
rl 11.
EirerdNeat- PH -
Di.- cation rag CONN
EST OK
DATAreo
♦
MU iS peticrula
Protocol-Ide7tification recl
PrOLOCO1- Micah:ores
Profile-1Di Trl9Per-Everq
parameler5 Notification_
Soofroc-reo DL-CIATA.req sendrig an erript). U I frame
0.--
4
EvoritNoefi-
cation locl
1X-1:1ATAircl
4—
4 _------
Sen.:Inc !he *icing PCIU
Figure 90 - Example: EventNotificaten triggered by the client

The first step is to establish this physical connection 37 . If successful, this is reported at both sides
to the physical connection manager process. At the server side, this indicates to the AP that the
EventNotification.request service can be invoked now. When it is done, the server AL builds an
EventNotificationRequestAPDU and invokes the connectionless DL-DATA.request primitive of the
data link layer with the data parameter carrying the APDU. However, the data link layer may not be
able to send this APDU, thus it is stored in the data link layer, waiting to be sent (pending).
When the client detects a successful physical connection establishment - and as there is no other
reason to receive an incoming call - it supposes that this call is originated by a server intending to
send the EventNotificationRequestAPOU.
At this moment, the client may not know the protocol stack used by the calling server. Therefore, it
has to identify it first using the optional protocol identification service described in Clause 5. This is
shown as a "Protocol-Identificationsequest" - - Protocol-Identificationsesponse" message exchange
in Figure 90. Following this, the client is able to instantiate the right protocol stack.
The client AP invokes then the Trigger EventNotification Sending -request primitive (see 9.3.10).
Upon invocation of this primitive, the AL invokes the connectionless DL-DATA.request primitive of
the data link layer with empty data. and the data link layer sends out an empty UI frame with the PIT
bit set to TRUE, giving the permission to the server side data link layer to send the pending PDU.
When the client AL receives an EventNotificationHequestAPDU, it generates the EventNotification

indication primitive. The client is notified now about the event, the sequence is completed.
10.2.6.5 Transporting long messages

In this profile, the data link layer provides a method for transporting long messages in a transparent
manner for the AL. This is described in 8.4.5.4.5. See also 9.1.2.3.12.
As transparent long data transfer is specified only for the direction from the server to the client, the
server side supporting protocol layer provides special services for this purpose to the server AL. As
these services are specific to the supporting protocol layer. no specific AL services and protocols
are specified for this purpose. When the supporting protocol layer supports transparent long data
transfer, the server side AL implementation may be able to manage these services.
37 This physical connection establishment is done outside of the protocol stack.
l DLMS User Association 2009-12-22

DLMS UA 1000-2 Ed. 7.0 219/310
10.2.6.6 Supporting multi-drop configurations

A multi-drop arrangement is after used allowing a data collection system to exchange data with
multiple physical metering equipment using a shared communication resource like a telephone
modem. Various physical arrangements are available. like a star, daisy chain or a bus topology.
These arrangements can be modeled with a logical bus. to which the metering equipment and the
shared resource are connected, see Figure 91.
daisy-chained
CEM
CEMs
GEM 2
PSTN
PSTN
CEM = COSEM Energy Meter
Figure 91 — Multi-drop configuration and its model

As collision on the bus must be avoided, but a protocol controlling access to the shared resource is
not available, access to the bus must be controlled by external rules. In most oases, a Master-Slave
arrangement is used. where the metering equipment are the Slaves. Slave devices have no right to
send messages without first receiving an explicit permission from the Master.
In DLMS/COSEM, data exchange takes place based on the Client/Server model_ Physical devices
are modeled as a set of logical devices, acting as servers. providing responses to requests.
Obviously, the Master Station of a multi-drop configuration is located at the other end of the
communication channel and it acts as the client, sending requests and expecting responses.
Figure 92 - Master/ Slave operation on the mulls drop bus

-
The client may send requests at the same time to multiple servers, if no response is expected
(multi-cast or broadcast). If the client expects a response. it must send the request to a single
server, giving also the right to talk_ It has to wait then for the response before it may send a request
to another server and with this, giving the right to talk_ Arbitration of access to the common bus is
thus controlled in a time-multiplexing fashion.
Messages tram the client to the servers must contain addressing information. In this profile. it is
ensured by using HDLC addresses. If a multi - drop arrangement is used, the HDLC address is split
to two parts: the lower HDLC address to address physical devices and the upper HDLC address to
address logical devices within the physical device. Both the lower and the upper address may
contain a broadcast address. For details, see 8.4.2.
To be able reporting events. a server may initiate a connection to the client. using the non-
client/server type Eventflotification InformationReport services_ As events in several or all meters
connected 10 a multidrop may occur simultaneously - for example in the case of a power failure -
they may initiate a call to the client simultaneously. For such cases_ two problems have to be
handled:
• collision on the logical bus: For the reasons explained above. several physical devices may try to access
the shared resource (for example sending AT commands to the modem) simultaneously. Such situations
must be handled by the manufacturers:
• identification of the originator of the event report: this is possible by using the CALLING Physical Device
Address. as described in Clause 8.4.5.4.8.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 220 , 310
Copyright 1997-2009 eLMS User Associat
10.3 The TCP-UDPIIP based communication profiles

(COSEM_on_113)
The TCP-UDINIP based profiles are suitable for remote data exchange with metering equipment via
IP enabled Networks (for example Internet), using various communication networks, such as Local
Area Networks or public- or private Wide Area Networks.
10.3.2 The structure of the profile(s)

The COSEM TCP-UDP/IP based communication profiles consist of five protocol layers:
• the COSEM Application layer, specified in Clause 9,

• the COSEM Transport layer, specified in Clause 7;
• a network Layer: the Internet Protocol (IPv4), specified in the Internet standard STD0005;
• a data link layer: any data link protocol supporting fPv4 (PPP, Ethernet, etc.);
• a physical layer: any PhL supported by the data link layer chosen_
The COSEM AL uses the services of one of the TLs (TCP or UDP) via a wrapper, which, in their
turn, use the services of the IPv4 network layer to communicate with other nodes connected to this
abstract network. The COSEM AL in this environment can be considered as another Internet
standard application protocol, which may co-exist with other Internet application protocols, like FTP,
I-ITTP etc. See Figure 25.
The TCP-UDINIP layers are implemented on a wide variety of real networks, which, just with the
help of this IP Network abstraction, can be seamlessly interconnected to form Intra- and Internets
using any set of lower layers supporting the Internet Protocol.
Chcr =Va.,
leziance
WEB
Fles
COSIEN Irewlawr Oassos dried iernereatken aystern
Pag )
M~uparplosIN, GOMM "warble Layer

- •hr Cenilearn-Ipar CSO.r. dX.1.13,
-mialftlim ru•mv alawl•kna 4CM TCP
FTP HTTP
Corrriadicm
PAM Frir-ildxr Arpacimi0, GOdIn>151.-ripi Manager
Gummi !DUOS ) ElanwitiAME )
:L.
Wrapper
Transport
Transrriszien Protecols: TCP R RFC 793 land UDP RFC 768 )
kismet Protocol (1Pv4,. RFC Arl

passim IF ane An Etemet ARP
4.1;11,' over ATM
ppP { RFC 2225 FIFC 826 ) IP and ARP on IEEE 802
Networks
( RFC 1661, II ATM signaling ainsort Transdnisiqn of iP Da warns
RFC 1042 )
IP aiiier ATM over Ethernet Networks
DIME' Li* RFC 1756 ) ( RFC 894 )
PPP in MK-We IEEE 802_2 LLG

framing ATM
(FIFC 1662) MAC
Ethernet
PhySleet (?,
eii / ATM Physical Layer LL
Z ATM Ethernet 802.3, Token Ring,

o Serial Line
Figure 93 — Examples for lower-layer protocols in the TCP-UDPIP based profile(s}
DLMS User Association 12009 12 22 - - I DLMS UA 1000-2 Ed. 7.0 I 221/31 0

Below the IP layer, a range of lower layers can be used One of the reasons of the success of the
Internet protocols is just their federating force_ Practically any data networks, including Wide Area
Networks such as GPRS, ISDN, ATM and Frame Relay, circuit switched PSTN and GSM networks
(dial-up IP), as well as Local Area Networks, such as Ethernet. Wireless LAN, Token Ring. FDDI.
Bluetooth, etc. support TCP-UDR/IP networking. Figure 93 shows a set of examples - far from
being-complete - for such communication networks and for the lower layer protocols used in these
networks. Using the TCP-UDP/IP profile. COSEM can be used practically on any existing
communication network.

Although real-world devices even in the Internet environment are connected to real-world physical
networks, at a higher abstraction (and protocol) level it can be considered as if these devices would
be connected to a virtual - iP - network_ On this virtual network. each device has a unique address,
called IP address. which non-ambiguously identifies the device on this network,
Any device connected to this virtual IP network can send message(s) to any other connected
device(s) using only the IP Address to designate the destination device. without being concerned
about the complexity of the whole physical network. Specific characteristics - the data transmission
medium, the media access strategy, and the specific data-link addressing / identification scheme -
of the particular physical network(s) participating in the route between the source and the
destination device are hidden for the sender device. These elements are handled by intermediate
network devices, called routers.
Therefore, in the TCP-UDPIIP based profiles COSEM physical devices are non-ambiguously
identified by their network - IP - address_
The identification of COSEM client AP and server APs requires an additional address,
Both TCP and UDP provide additional addressing capability al the transport level, called port, to
distinguish between applications. The AL is listening only on one TCP or UDP port for exchanging
messages between any client and server APs. As in a single physical device several client or server
APs may be present, an additional addressing capability is needed_ This is provided by the wrapper
sublayer. see Clause 7. The wrapper provides an identifier - wPort - similar to the TCP or UDP port
numbers, but on the top of these layers. A particular COSEM client AP and/or a particular COSEM
logical device in the same physical device can be thus identified by its wPort number.
In summary, in the TCP-UDP/IP based profiles the following identification rules apply:
• COSEM physical devices are identified by their IP address;

• the COSEM AL is listening only on one UDP or TCP port. See 7.2;
• COSEM logical devices and client APs within their respective host physical devices are identified by their
wPort numbers. Reserved wPort numbers are specified in Clause 7;
• lower layer addresses (SAP-s) are not considered (hidden):
COSEM AAs are identified by the identifiers of the two end-points as described above. Figure 94 shows an
example.
AAs established between the client AP_01 and Logical Device 01 in Host device 01 (AA 1) and
Logical Device 02 in Host Device_02 (AA2) respectively are identified by:
M 1: ( 163.187.45.19, T_N, 31 ) ( 163.187.45.36, T M, 527 ) )

AA 2: ( 163.187.45.19, T N, 31 ) (163.187.45.78, T M, 3013 )1
NOTE 1 "1"_N and T_M means the TOP port used for DLMS/COSEM in the client host device and the server host devices
respectively. For the assigned port numbers, see 7_2_
NOTE 2 In these two AA-s the client side end-point identifiers are the same. However, the server side end-point identifiers
are different, so the two AAs are identified unambiguously and therefore they can be used simultaneously_
DLMS User Association 20M-12-22 DLMS UA 1000-2 Ed. 7.0 222/310

© Copyright 1997-2009 DLMS User Associatlon
COSEM
Host device for Clients HasetDeviee_01 for Servers Ficsrclevice_02 for Servers
App icatcrl
COSEM
Client
COSEM
Client
Processes
are the
Server 01
(.. SFr,'
akiver_a2
ICOSEso
Server
Oi
_ Server
02
Server_
Ur3
COSgM
1-00mor
_
AP 01 AP O2 Ap,dcabon Oesnee01 I Den= ,623.
(CO5-Eli (COMM (0050.1
Layer (0001 - Kcal _ Logical _
Derr* 01) Dence02) Devite_03P
sv Ian Sat JOU 527 NM 3014 527 3013 3074

wrapper
hi PA PA IM
Pavlova' TCP U1)1. TCP UDP
Layers of the 4.10
TCR UDIMP 183.187.45.36 163.187.45.78
prarie
IP IP
Data Link Low Data Link Layer

Physker Layer Pipyaicei Layer Physkar Layer
Network
Figure 94 — Identification addressing scheme in the TCP-UDP IP based profile(s)
10.3.4 Supporting layer services and service mapping

As specified in Clause 7, the COSEM TCP TL provides the following services to its service users:
• Connection management services. provided for the TOP connection manager AP:
• TCP-CONNECT.request, indication, .response, .confirm:
• TOP-DISCONNECT.request. indication. .response. confirm
• Data exchange services. provided for the COSEM AL: these services can be used only when the TCP
connection is established:
• TCP-DATA - .request..indication. (. confirm)
The TCP TL also provides a TOP-ABORT service to the service user COSEM AL to indicate the
disconnection/disruption of the TOP layer connection.
The UDP TL provides only one service to the service user COSEM AL: a connection-less, unreliable
data delivery service.
• UDP-DATA - _request, indication. (.confirm)
NOTE A TCP.confirm UDP .confirm service primitive is optionally available.
Figure 95 summarizes these services.
For connection management. the COSEM TCP TL provides the full set of the TCP-CONNECT and
TCP-DISCONNECT services. both at the client- and at the server sides. The purpose of this is to
allow also the server to establish and release TCP connections. See also 10.3.6.7. As in all COSEM
profiles, AA establishment and release is initiated by the client AP in these profiles as well.
The user of these services is not the COSEM AL. but the TOP Connection Manager AP. This
process is implementation dependent. therefore it is out of the scope of this companion
specification. The only requirements with regard to this process are:
• the TCP connection manager process shall be able to establish the supporting TCP connection without
the intervention of the COSEM client- or server AP(s):
• the COSEM client- and server APs must be able to retrieve the TOP and IP portion of the
Protocol parameter from the TCP connection manager before sending /
receiving a COSEM-OPEN.request / indication.
DLMS User Association 2009.12-22 DLMS UA 1000-2 Ed, TO 223/310

V Copyright 1997-2009 DLMS User Association
TCP Connection
COSEM Application Process
Manager
A
TCP-CONINECT. crdi Ari d
COSEM Application Layer
TC P-ABORT. Ind
0
TC P- CONNECT. req i res
5
0
z
TCP•DATA. req
0
0
O.
0
t
COSEM TCP UDP transport layers
Figure 95 — Summary of TCP UDP layer services
For data exchange. both the client- and the server ALs use the complete set of the service
primitives provided by the COSEM TCP-UDP TLS_
The correspondence between an AL (ASO} service invocation and the supporting COSEM TCP-
UDP layer service invocation is given in Clause 7.
10.3.5 Communication profile specific service parameters of the

COSEM AL services
Only the COSEM-OPEN service has communication profile specific parameters, the
Protocol_Connection_Parameters parameter. This contains the following data:
Protocol (Profile) Identifier TCP/IP or UDPlIP:

• Server_HP Address COSEM Physical Device Address:
• Server_TCP_or_UDP_Port The TCP or UDP port used for DLMS.'COSEM, see 7.2:
• Server_wrapper_Port COSEM Logical Device Address;
• Client_IP_Address COSEM Client's Physical Device Address:
• Client TCPor_UDP_Port, The TCP or UDP port used for DLMS/COSEM. see 7.2:
• Client wrapper_Port COSEM application process (type) identifier
Any server address parameter may contain special addresses (All-station, No-station. etc...). For
more information. see Clause 7.
10.3.6 Specific considerations I constraints

• Confirmed and unconfirmed AAs and data transfer service invocations. packet types used
Table 58 shows the rules for establishing confirmed and unconfirmed AAs. the type of data transfer
services available in such AAs and the TL packet types used for carrying APDU-s. In this table,
grey areas represent cases. which are out of the normal operating conditions: either not allowed or
have no useful purpose. According to these:
• it is not allowed to establish an unconfirmed AA using the TCP/IP protocol. It is prevented by the Client
AL, which locally and negatively confirms COSEM-OPEN.request primitive invocations trying to do that;
• it is not allowed to request an xDLMS service in a confirmed way (Service_Class = Confirmed) within an
unconfirmed AA. established on the top of the UDP layer. This is also prevented by the Client AL.
Servers. receiving such APDUs shall simply discard them. or. shall send back a ConfirmedServiceError
APDU or. if the feature is implemented. send back the optional Exception Response APDU.
DLMS User Association 2309-12-22 DLMS UA 1000-2 Ed. 7.0 224.'310

Table 58 — Application associations and data exchange in the TCP-UIDR IF' based profile
Type of
Protocol
COSEM-OPEN established
co nnection Use Service class Use
service class application
parameters
association
if Connect TCP
layer Confirmed TCP packet
2/ Exchange
Confirmed AAFIO/AARE Confirmed
id: TCPIIP
APDU-s
TCP port transported in Unconfirmed TCP packet
numbers. TCP packets
IP addresses
liMMIRIW
.
Local negative
Unconfirmed None
confirmation
Exchange
Confirmed UDP datagram
AARWAARE
Confirmed APDU-s Confirmed
Id LIDP/IP transported in fl Unconfirmed UDP datagram
UDP datagrams
LJDP port
numbers. Confirmed
IP addresses (not allowed)
Send AARQ in a
Unconfirmed Unconfirmed -.
UDP datagram
Unconfirmed UDP datagram
In the TCP-UDP/IP based profiles, the Service_Class parameter of the COSEM-OPEN service is
linked to the response-allowed parameter of the xDLMS InitiateRequest APDU. it the COSEM-
OPEN service is invoked with Service Class == Confirmed, the response-allowed parameter shall
be set to TRUE. The server is expected to respond. If it is invoked with Service_Class ==
Unconfirmed, the response-allowed parameter shall be set to FALSE. The server shall not send
back a response.
The Service_Class parameter of the GET. SET and ACTION services is linked to bit 6 of the
Invoke Id And-Priority byte_ If the service is invoked with Service Class = Confirmed, bit 6 shall be
set to 1, otherwise it shall be set to 0.
10.3.6.1 Releasing application associations: using RLRGVRLRE is mandatory

In the TCP-UOP:IP based profile, using the A - RELEASE services of the ACSE — by invoking the
COSEM - Release.request primitive with Use RLRQ RE TRUE — is mandatory for the following
reasons:
• according to the identification I addressing scheme used in this profile, an AA is identified by two triplets,
including the IP Address, the TCP (or UDP) port number and the wPort number. In other words, all AAs
within this profile are established using only one TCP (or UDP) port. This means, that disconnecting the
TCP connection this way of releasing AA must also be supported) would release all AAs established.
Using the FILRQ/RLRE APDU-s allows to release confirmed AAs in a selective way;
• it is allowed to establish both confirmed and unconfirmed AAs on the connectionless UDP TL. The only
way to release such associations is the use of the RLRO/FILRE services.
NOTE In fact r using the FILRO/RLRE APDU-s is specified as optional only to keep backward compatibility with the
third edition of the Green Book (2002), which did not include this possibility.
10.3.6.2 Service parameters of the COSEM-OPEN -RELEASE - ABORT services

The optional User_l nformation parameters of the COSEM-OPEN -RELEASE services are not
supported in this communication profile.
10.3.6.3 xDLMS client/server type services

No specific features 1 constraints apply related to the use of client: server type services.
DLMS User Association 2009-12-22 DLMS UA 1000 2 Ed. 7.0 - 225/310 I

10.3.6.4 The EventNotificalion Service and the TriggerEventNotificationSending

service
This sub-clause describes the communication profile specific elements of the protocol of the
EventNotification service, see 9.4.6.6.
As in this profile both the TCP and UDP profile allows sending data in an unsolicited manner, the
Trigger_EventNotification_Sending service is not used
The EventNotificationRequestAPDU may be sent either using the connectionless data services of
the COSEM UDP-based TL or by the connection-oriented data services of the COSEM TCP-based
TL. In this case. a TCP connection has to be built first by the TCP Connection Manager process.
The optional Application Addresses parameter is present only when the EventNotification_request
service is invoked outside of an established AA.

The data field of the wrapper layer shall always carry a complete xDLMS APDU. If the APDU is to
long to be accomodated, then application layer block transfer can be used.
10.3.6.6 Multi-drop configuration

Among many other possibilities, the TCP-UDP , IP communication can be used over serial
connection links, like the PSTN_ In this case. the data link layer protocol to be used is the PPP
(Point-to-Point) protocol_
However, multi-drop configurations in this profile are not supported, because the necessary
addressing mechanisms are not available with PPP. Therefore, a mechanism of avoiding a collision
on the logical bus would not be not available.
10.3.6.7 Allowing COSEM servers to establish the TCP connection

In OLMS/COSEM, supporting layer connections are generally established during AA establishment
following the invocation of the COSEM-OPEN.request primitive by the client AP (the PhL connection
must be already established before invoking the COSEM-OPEN.request primitive). Therefore linking
the process of establishing an AA and connecting the supporting layer is just natural,
However, in some cases it would be useful if the server could also initiate the connection of the
TCP layer. This is particularly interesting in the TCP-UDP/IP based profile, when the server does
not have a public lip address. In this case. as the Client does not "see" the physical device hosting
the server(s), it is not able to establish the required TCP layer connection.
In order to allow the server to establish the TCP layer connection. the lull set of service primitives of
the TCP-CONNECT service is available both on the client and the server side.
NOTE These services are used by the TCP connection manager, not by the AL.
10.3.6.8 The COSEM TCP-UDPIIP profile and real-world IP networks

Clause 7 and 9 specify all COSEM-specific elements necessary to use COSEM over the Internet,
using the COSEM TCP-UDP/IP based profile.
On real Internet networks, there are other elements, which need to be considered. For example, in
this companion specification it is specified. that physical devices hosting COSEM APs are identified
with an IP address, but it is not specified. how to obtain such an IP address. As these elements are
not specific to COSEM, they are not in the scope of this companion specification.
1 DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7_0

ig Copyright 1997-2009 DLMS User Association
226/310
10.4 The S-FSK PLC profile

10.4.1 Terms and definitions relevant for the S-FSK PLC profile
10.4.1.1
initiator
user-element of a client System Management Application Entity (SMAE). It uses the CIASE and
xDLMS ASE and it is identified by its system title [IEC 61334-4-511 3.8.1 modified]
10.4.1.2
active initiator
initiator, which issues or has last issued a CIASE Register request when the server is in the
unconfigured state [IEC 61334-4-511 3.9.1]
10.4.1.3
new system
server system, which is in the unconfigured state: its MAC address equals "NEW-address" [IEC
61334-4-511 3.9.3]
10.4.1.4
new system title
system-title of a new system [IEC 61334-4-511 3.9.4]
NOTE This is the system title of a system, which is in the new state_
10.4.1.5
registered system
server system, which has an individual, valid MAC address (therefore, different from ''NEW
Address", see IEC 61334-5-1: Medium Access Control) [IEC 61334-4-511 3.9.5]
10.4.1.6
reporting system
server system. which issues a DiscoveriReport [lEC 61334-4-511 3.9.6 modified]
10.4.1.7
sub-slot
the time needed to transmit two bytes by the physical layer
NOTE Timeslots are divided to sub-slots in the RepeaterCall made of the physical layer.
10.4.1 .8
timeslot
the time needed to transmit a physical frame
NOTE As specified in IEC 61334-5-1 clause 3.3.1, a physical frame comprises 2 bytes preamble, 2 bytes start subframe
delimiter, 38 bytes FSDU and 3 bytes pause.
10.4.2 Abbreviations relevant for the S-FSK PLC profile

Abbreviation Explanation
CI ASE Configuration Initiation Application Service Element
CI-PDU CIASE PDU
DA Destination Address
MPDU MAC Protocol Data Unit
NS Number of subfrarnes {S-FSK MAC sublayer)
ROR Reply Data on Request /used in IEC 61334-4-321
SA Source Address
SDN Send Data Non-acknowledged (used in IEC 61334-4-32)
SMAE Systems Management Application Entity
SMAP Systems Management Application Process
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 227/31 D


The DLMS.'COSEM S-FSK PLC communication profile is intended for remote data exchange over
the low voltage electricity supply network between data concentrators located in MV/LV substations
and meters connected to the LV network.
From the PLC medium point of view, the concentrator(s) take(s) the role of the initiator(s), while the
meters take the role of responders.
From the application process point of view. the concentrator(s) take(s) the role of COSEM Client(s)
while the (logical devices of) meters take the role of COSEM servers.
10.4.4 Reference model

NOTE This clause is partly based on EC 61334-4 , 1. clause 3.
10.4.4.1 Introduction
The reference model of the DLMS/COSEM S-FSK PLC communication profile is shown in Figure 96.
It is based on a simplified or collapsed three-layer OSI architecture. The layers are the physical
— —
layer. the data link layer and the application layer. The data link layer is split to the MAC sublayer
and the LLC sublayer.
10.4.4.2 The physical layer (PhL)

The PhL provides the interface between the equipment and the physical transmission medium that
is the distribution network. It transports binary information from the source to the destination.
The PhL in this profile is as specified in IEC 61334-5-1 clause 3. It provides the following services
to its service user MAC sublayer
• P-Data services to transfer MPDIJs to (a) peer MAC sublayer entity(ies) using the LV distribution network
as the transport medium:
• P-Sync services to allow the MAC sublayer entity to ask for a new synchronization and to be informed of
a change in the synchronization state of the PL. These services are used locally by the MAC sublayer.
See IEC 61334-5-1 clause 3.4.
10.4.4.3 The data link layer

10.4.4.3.1 General
The data link layer consists of two sublayers: the Medium Access Control (MAC) and the Logical
Link Control (LLC) sublayer.
The MAC sublayer handles access to the physical medium and provides physical device
addressing. The decision to access the medium is made by the initiator, directly for its own MAC
sublayer. or indirectly for other MAC sublayers that are requested to transmit a response to a
request sent previously by the initiator.
The LLC sublayer controls the logical links.

COSEM Application Process

System Management Application Process ISMAP) DLMS UR Blue Book'
A A
I IEC 62056-b1. IEC 62056-62 with amendments
■
Configuration Initiabon ASE
System Management COSEM Application layer
(WEE)
Appkicahnn Entity ACSE and xDLMS ASE
4 DLMS UA Green Book I 4 rr
(SMAE) DLMS UA Green Book
IEC 61334-4-511 with
EC 61334-5,1 IEC 62056-53 with amendments
arnendrnefts
■ A ■
ACSE and xDLMS APDUs
el-POLls
carried by
carried by
connectionless DL-Data and DL-Reply services or
connectionless DL-pats services
connection oriented DL-Data services
V It
I
Data link [err
Credit
management
M A- S ync i net
F-
Connechonless LLC sublayer
IEC 61334-4-32
r
MR-Data services
.0 based LLC sublayer (CO r Cl..)
DLMS UA Green Book
IEC 62056-46
SO/IEC 8902-2 Class I over t-IDLC)
Phy-Ask ForRepeaterCall S-FSK MAC sub-layer

IEC 61334-5-1 clause 4
A A
P-Data services P-Sync services
I
S-FSK Physical layer
■
IEC 61334-5-i clause 3
Figure 96 — The DLMS!COSEM S-FSK PLC communication profile
There are two LLC sublayer alternatives available:
• the connectionless LLC sublayer, as specified in IEC 61334-4-32;

• the LLC sublayer using the HDLC based data link layer. as specified in 81 IEC 62056-46,
10.4.4.3.2 The MAC sublayer
The MAC sublayer of the DLMS COSEM S-FSK PLC communication profile is as specified in IEC
61334-5-1 clause 4. It provides the following services to its service user LLC sublayer:
• the MA-Data services_ These services allow the LLC sublayer entity to exchange LLC data units with
peer LLC sublayer entities. See IEC 61334-5-1 4.1.3.1:
• the MA-Sync-indication service. This allows the SMAE entity to be informed of the synchronization and
configuration status of the device. See IEC 61334.5-1 4.1.3.2.
10.4.4.3.3 The connectionless LLC sublayer
The connectionless LLC sublayer is as specified in IEC 61334-4-32. It is derived from ISO/IEC
8802-2 — similar to Class III operation — and it performs the following functions:
• addressing of application entities within the equipment:

• sending data with no acknowledgement (SON):
• requesting data with reply (RDR).
It provides the following services:

© Copyright 1997-2009 DLMS User Asocial on
• DL-Data services for transporting CI-PDUs. ACSE APDUs and client-server type xDLMS APOUs;
• DL-Reply services for asking the remote LLC sublayer entity to send a previously prepared LSDU;
• DL-Update-Reply services to prepare the LSDUs to be transferred using the DL-Reply services.
For more, see IEC 61334-4-32 clause 2.1
10.4.4.3.4 The HDLC based LLC sublayer

The HDLC based LLC sublayer is as specified in 8,
As explained in 8.1.2. this sublayer can also be divided to two sublayers:
• the LLC sublayer based on ISCHEC 8802-2. Here, it is used in an extended Class I operation. The only
role of this sublayer is to select the COSEM Application layer by using a specific LLC address. The LLC
services are provided by the HDLC based MAC sublayer:
• the MAC sublayer. based on the HDLC protocol. It provides addressing of application entities within the
equipment.
NOTE In this profile, there are 1wo MAC sublayers. The HDLC MAC sublayer provides reliable LLC dale transport and
segmentation. The Medium Access Control functionality is provided by the S-FSK MAC sublayer specified in 10.4.4.3.2.
The HDLC based LLC sublayer provides the following services:
• DL-Connect services to connect and to disconnect the data link layer:

• connectionless DL-Data services for transporting CI-PDUs. ACSE APDUs and xDLMS APDUs;
• connection oriented DL-Data services for transporting ACSE APDUs and xDLMS APDUs. These
services provide reliable data transport and support segmentation to carry long messages. in a
transparent manner for the application layer.
10.4.4.3.5 Co existence of the connectionless and the HDLC based LLC sublayers
-
The frames of the connectionless LLC sublayer and the HDLC based LLC sublayer can be
distinguished from each other as shown in Figure 97. This allows systems using the two profiles to
co-exist on the same network.
Con 1001 field DSAP address Iwo SSAP address field
LSB
IEC 61034.4-32
1CCC:110000 DDDDDDOD 55555555
LLC 'rune header: MSB = 1
.04
Flag 7E
7E Frame formal
11.4
LSB
IEC 62056-46
0 1 1 1 1 1 1 0 1 0 1 0 SLLL LLLLLLLL
Data link layer header: MSS
Legend:
C: Command subtield
CiR: Command I response bit
0000: Oualilier subfield
DODODDDD: Destination address
55555555: Source address
S: Segmentation
L: Length
Figure 97 - Co-existence of the connectionless and the HDLC based LLC sublayers
10.4.4.4 The application layer (AL)

The application layer is the COSEM Application layer as specified in 9. It provides services to the
COSEM application process (AP) and uses the services of the connectionless or the HDLC based
LLC sublayer.
DLMS User Association 2009-12-22 DLMS UA 1000.2 Ed. 7.0 230/310

C, Copyright 1997-2009 DLMS User Association
10.4.4.5 The application process (AP)

On the server side, the COSEM device- and object model - as specified in DLMS UA 1000-1 -
applies. Each logical device represents an AP.
The client side APs make use of the resources of the server side AP. A physical device may host
one or more client APs.
10.4.5 The Configuration Initiation Application Service Element (CIASE)

NOTE This clause is based on IEC 61334-4-511 and constitutes an extension to it.
One of the activities of systems management is open system initialisation and / or modification. This
is provided by the Configuration Initiation ASE (CIASE). It is specified in IEC 61334-4-511 with the
extensions specified below.
10.4.5.1 Overview
The CIASE services are the fotlowing:
• the Discover service;

• the Register service;
• the PING service;
• the RepeaterCall service; and
• the ClearAlarm service.
The three latter services, together with the Intelligent Search Initiator process specified in 10.4.5.7,
constitute upper compatible functional extensions to IEC 61334-4-511.
The CIASE uses the ccnnectionless DL-Data services of the LLC sublayer.
10.4.5.2 The Discover service

NOTE In this document. the description of the CIASE services follows the presentation style used for the COSEM
services.
The Discover serv i ce is used to discover new systems or systems, which are in alarm state. It is
specified in IEC 61334-4-511 7.1. The Discover service primitives shall provide the parameters as
shown in Table 59.
Table 59 - Service parameters of the Discover service primitives
Discover DiscoverReport

Argument M M (=) - -
Flesponse_Probability M M (.)
Allowed_Time_Slots IA M (-)
DiscoverReport_Initial_Credit M M (-)
IC_Equal_Credit M M (.) -
Result (+) S S (-,)

System_Title 1System_Title) - - M M {-)
Alarm_Descriptar C C (-)
Result (-) S S (-)
Argument_Error(s) - - M M (.)
NOTE This table is included here for completeness and to correct some editorial errors in IEC
61334-4-511 7.1. For the description of the service parameters, see the clause referenced here.
10.4.5.3 The Register service

The Register service is used to perform system configuration. It assigns a MAC address to a new
system identified by its system title. It is specified in IEC 61334-4-511 7.2. The Register service
primitives shall provide the parameters as shown in Table 60.

ULNAS User Association, COSEM Architecture and Protocols. Seventh Edition
Table 60 - Service parameters of the Register service primitives
.request indication
Argument
Active_lnitiatcr_System_Title M M (,)
List_Of_Correspandence M M (-)
New_System_Titie M M (=)
MAC_Address M M (m)
Result (+) S S
Result (-) S S
Argurnent_Erter(s) M M (k)
NOTE This table is included here for completeness. For the
description of the service parameters. see IEC 61354-4-511 7.2.
NOTE 1 It a server in NEW state receives a correct Register service with its own server system title in it. 3t Will be
registered, even if it did not receive a Discover service before.
NOTE 2 Only those servers in the NEW state can be registered.
10.4.5.4 The Ping Service

Function
The Ping service is used to check that a server system already registered is still present on the
network_ It also allows verifying that the right physical device is linked to the right MAC address. It
also allows preventing the time_oul_not addressed timer to expire.
The process begins with a Ping.request service primitive issued by the active initiator. The service
contains the system title of the physical device pinged, The PingRequest CI-PDU is carried by a DL-
Data.request service primitive and it is sent to the MAC address assigned to this system and to the
server CIASE L-SAP.
if the system title carried by the Ping,indicatiOn Service primitive is equal to the system title of the
server, the server shall respond with a Ping.response service primitive, carrying the system title of
the server. It is sent to the initiator CIASE L-SAP.
Semantics
The PING service primitives shall provide parameters as shown in Table 61.
Table 61 - Service parameters of the PING service primitives

-request Indication _response _confirm
Argument M M (m-) - _
Systern_Title_Server
Result (+) - - S S (-)
System_Title_Server M (-)
M
Result (-) - - S S
Argument_Error(s) M M (=)
The System_Title_Server service parameter allows identifying a physical device concerned by the
Ping service. The destination MAC address in the DL-Data.request service primitive is equal to the
MAC address that has been assigned to this system using the Register service.
The Pingsesponse service primitive returns with Result (+) if the Ping.request service has
succeeded, i.e. the system title of the physical device at the given MAC address is equal to the
"System_Title_Server" carried by the Ping.request service primitive.
Otherwise, no response is sent by the server
DLMS User Association 2009-12-22 I DLMS L1A 1000.2 Ed. 7.0 232:310
cg Copyright 1997-2009 DLMS User Association
Use - Client side
The Ping.request service primitive is issued by the active initiator.
If the 'System_Title_Server" service parameter is not valid, a local confirmation is sent immediately
with a negative result indicating the problem encountered (Ping - system - title-nok).
Otherwise, the CIASE forms a DL-Data.request PDU containing a PingRequest CI-PDU that carries
the System_Title_Server requested_ It is sent to the physical device concerned by the request.
Once the transmission of the PingRequest CI-PDU is over. the CIASE waits for a DL-Clataindication
service primitive containing a PingResponse CI-PDU from the physical device pinged. during the
necessary time that depends on the initial credit of the request.
If the CIASE receives a DL-Data.indication service primitive containing a PingResponse CI-PDU

before this delay is over, it sends to the initiator a confirmation with a positive result, containing the
service parameter returned by the server system.
If no DL-DATA.indication service primitive is received, the CASE sends to the initiator a

confirmation with a negative result pointing out the absence of an answer (Ping-no-response).
Use - Server side
On the reception of a DL-Data.indication service primitive containing a PingRequest CI-PDU, the

CIASE checks that the System_Title_Server service parameter is correct and that it is equal to its
own system title.
If so. it invokes a PingResponse service primitive that includes its system title. The Ping Response
CI -PDU is carried by a DL-Data request service primitive.
If the service parameter of the Ping.indication service primitive is not correct. no response is sent.
Finally, if the System_Title_Server service parameter in the Ping.indication service primitive is

correct, but not equal to the system title of the physical device, no response is sent.
10.4.5.5 The RepeaterCall service

Function
The purpose of the RepeaterCall service is to adapt the repeater status of server systems
depending on the topology of the electrical network. It allows the automatic configuration of the
repeater status on the whole network.
In the FlepeaterCall mode. the client and the servers transmit short frames - two bytes long each -
and measure the level of the signal to determine if a server system should be a repeater or not.
Semantics
The RepeaterCall service primitives shall provide parameters as shown in Table 62.
Table 62 - Service parameters of the RepeaterCall service primitives
. request . indication
Arguments
Max_Adr_MAG M
Nb_Tslot_For_New U
Reception_Threshold M
Result (+) S S
Result (-) S S
Argument_Error(s) M
The Max_Adr_MAC service parameter allows calculating the number of timeslots used in the
RepeaterCall mode by the physical layer of the server systems registered to an initiator. It
corresponds to the largest server system MAC address that is stored by the initiator.
NOTE The largest allowable server MAC addresses is 3071 (E1FF). as the range COO...DFF is reserved for initiator, as
specified in IEC 61334-5-1 4.3.7.7.1.
The value of Nb_Tslot is calculated from this information:
Nb _Tsiot =LMaxAdrMax121j+1
where L.v i means the floor of x. the nearest integer x.
Example 1
Max_Adr_MAC = 20 (20 servers on the network}
Nb_Tslot =L2012 1 j 4r 1 = 1
NID_Tslot = 1, with 1 sub-tirneslot for the concentrator and 20 sub-iimeslols f*r the servers_
Example 2
Max_Adr_MAC = 21 (21 servers en the network)
Nb _Tsirot ,121121j+1 =2
Nb_Tslot = 2:
- 1 times/at with 1 sub-tirneslol for the concentrator and 20 sub timeslots tar 20 servers
-
1 tirnesiot wilh 1 sub-tirneslai for one server.
The Nb_Tslot _for_New service parameter defines the number of timeslots used in the RepeaterCall
mode by the physical layer of the server systems in NEW state. If the value of this service
parameter is 0 (or not present) then the systems in NEW state are not allowed to participate in ihe
Repeater Call process
The maximum number of timeslots used by the physical layer is equal 10 the sum of ihe number of
timeslots for the server systems registered and the number of timeslots for the server systems in
NEW state.
The Reception_Threshold service parameter defines the threshold of the signal level in dE31.N,
necessary to validate a physical pattern in a Sub_Tslot when the physical layer is in the
RepeaterCall mode
The Result (-+-) service parameter (positive result) indicates that the requested service has
succeeded.
The Result (—) service parameter (negative result) indicates that the requested service has failed.
The "Arguments Error" indicates that at least one argument has a wrong value.
Use — Client side
The RepeaterCall service of the CIASE is invoked by the SMAP.
If any of the arguments is not valid, a confirmation is sent immediately with a negative result
indicating the problem encountered.
Otherwise, the CIASE forms a DL-Data.request service primitive containing a RepeaterCall CI-PDU
carrying the parameters requested_ This request is sent to all server systems.
A positive confirmation is passed to the CIASE upon the reception of a DL-Data.cnf(+).
When this confirmation is received, the CIASE sends the Phy_AskForRepeaterCall.request primitive
allowing the activation of the RepeaterCall mode of the physical layer. The parameters of this
primitive are the following:
• Sub_Tslot position: on the client (initiator) side its value is 0;

• Reception_Threshold.
NOTE On the client side, the Reception_Threshold parameter has no significance_
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0

1 234'310
DLMS User Assodation, COSEM Architecture and Protocols. Seventh Edition
Use - server side
On the server side. on the reception of a DL- ❑ataindication service primitive containing a
RepeaterCall CI-PDU, the CIASE verifies that the service parameters are correct.
If this is the case, it sends the Phy_AskForRepeaterCall_request primitive to activate the

RepeaterCall mode of the physical layer. The parameters of this primitive are the following:
• Sub_Tslot position: A number expressed on two octets. between 0 and 65 535. The value 0 is reserved
for the configuration of the client (concentrator). The other values are available for the configuration of
server systems;
In the case of server systems registered by a concentrator. Sub-Tslot takes the value of the local MAC
address of the server system. between 1 and Max_Adr_MAC. For the server systems not registered.
Sub_Tslot takes a random value between Max_Adr_ MAC and Max_Adr_MAC -•- (Nb_Tslot_For_Nlew
21).
NOTE Max_Adr_MAC and Nb_Tslot_For_New are the service parameters of the FiepeaterCallsequest service.
• Reception Threshold: This represents the signa? level in dBpV. The default value is 104_
If the response to this request is negative, the command is cancelled. The following cases lead to a
failure:
• the state of the physical layer is not correct (there is no physical synchronization):
• the repeater status is never_repeater;
• the parameters are incorrect.
The participation of the servers in the repeater call process and the effect of the process on their
repeater status depend on the repeater management variable (attribute 10 of the S-FSK Phy&MAC
setup object) and the signal level heard:
• servers configured as never repeater do not participate: they do not transmit during their sub-timeslot
and their repeater status (attribute 11 of the S-FSK Phy&MC setup object) is not affected:
• servers configured as always repeater participate: they transmit during their timeslot but their
repeater status is not affected;
• servers configured as dynamic repeater participate: they transmit during their sub-timeslot, if they have
not heard a signal before from the client or from any servers. which is above the reception threshold. If
during the whole repeater call process_ a server does not hear a signal from the client or from other
servers, which is above the reception threshold, then its repeater status will be TRUE: the server will
repeat all frames. If a server hears a signal from the client or from other servers, which is above the
reception threshold. then its repeater status will be FALSE: the server won't repeat any frames.
NOTE If each server configured as dynamic repeater hears a signal, which is above the reception threshold. this
means that they are all close to a client, and no repetition is needed_ Sar none of them will become a repeater_
10.4.5.6 The ClearAlarm service

Function
The ClearAlarm service allows clearing the alarm state in (a) server system(s), in a point-to-point or
in a broadcast mode.
Semantics
The ClearAlarm service primitives shall provide parameters as shown in Table 63.

Table 63 - Service parameters of the ClearAlarm service primitives
_request .indication
Arguments
Alarm_Descriptor S S (-)
Alarm_Descriptor (Alarm_Descriptor) S S (=)
Alarm_Descriptor_List_And_Server_List S S (=)
System_Title (System_Titlel M M (m)
Alarm_Descriptor (Alarm_Descriptor) M M (-)
Alarm_Descriptor_By_Server (Alarrn_Descriptor_By_Serveri S S (-)
Systern_Tifle M M (-)
Alarrn_Descriptur 41.4 M (-)
Result (+) S S
Result (•) S S
Arguments Error M M
This service provides four different possibilities:
• the Alarm_Descriptor choice allows clearing a single alarm in all server systems_ The value of the
Alarm_Descriptor parameter identifies the alarm to be cleared:
• the Alarm_Descriptor {Alarm_Descriptor} choice allows clearing a list of alarms in all server systems.
The value of the Alarm_Descriptor { Alarm_Descriptor} parameter identities the list of alarms to be
cleared;
• the Alarm_Descriptor_List_And_Server_List choice allows clearing a common list of alarms specified in
the list of server systems specified_ The System_Title {System_Title} parameter identifies the list of
server systems in which the alarms have to be cleared. The value of the Alarm_Descriptor
Alarm_Descriptor) parameter identifies the fist of alarms to be cleared;
• the Alarm Descriptor By Server (Alarm_Descriptor_By_Serverl choice allows clearing one alarm
specified in each server specified. The Systern_Title parameter identifies the server system in which the
alarm has to be cleared. The value of the Alarm_Descriptor parameter identifies the alarm to be cleared.
NOTE As specified in IEC 61334.4.511 6-2_2, alarm descriptors should be specified in companion specifications.
The Result (+) argument (positive result) indicates that the requested service has succeeded.
The Result (-) argument (negative result) indicates that the requested service has failed.
The "Argument Error(s)" indicates that at least one argument has a wrong value.
Use
The ClearAlarrn CIASE service is invoked by the initiator.
If any of the service parameters is not valid, a confirmation is sent immediately with a negative
result indicating the problem encountered.
Otherwise, the CIASE forms a DL-Data.request service primitive containing a ClearAlarm CI-PDU
containing the parameters requested. This request is sent to the server system(s) concerned by the
request. A positive confirmation is sent upon the reception of a DL-Data_cnf(+) service primitive.
On the server side, on the reception of a DL-Dataindication service primitive containing a

ClearAlarm CI-PDU, the CIASE verifies that the arguments are correct. If this is the case, it clears
the alarm corresponding to the list of alarms. Otherwise. the service is ignored.
10.4.5.7 The Intelligent Search Initiator process

10.4.5.7.1 Introduction
The objective of the Intelligent Search Initiator process is to improve plug&play installation of server
systems, by ensuring that each server system is registered by the correct initiator.
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7,0 236131117

When a new server system is placed on the network, it will be discovered and registered by the first
initiator it hears talking. It remains registered by that initiator as long as it keeps receiving correct
frames (the time out not_ addressed timer does not expire). If there is cross-talk on the network,
the server system may be registered by the wrong initiator, i_e_ one, which is "heard' by the server
system due to cross-talk
When the Intelligent Search Initiator process is implemented in the server system, it is capable to
establish a list of all initiators it can "hear. and to lock on the initiator with the best signal level.
10.4.5.7.2 Operation
10.4.5.7.2_1 Flow chart
The intelligent search initiator process comprises two phases:
• the Search Initiator phase

• the Check initiator phase.
The Intelligent Search Initiator process is shown in Figure 98. See also Figure 99 showing the
complete discovery and registration process.
10.4.5.7.2.2 Process parameters

The Intelligent Search Initiator process is characterized by two parameters:
• The search_initiator_tirne_out, defining the duration of the Search Initiator Phase_ This timeout is also
used during the Check Initiator Phase, see 10.4.5.7.2.4:
The Search Initiator Phase must be long enough to allow the server systems to hear all the initiators
around them and, when needed. to let sufficient time to start all the initiators by the central station.
However, this time must not be too long either. so that the discovery phase could be executed correctly.
The recommended value for this timeout is 10 minutes;
• The search initiator threshold. defining the minimum signal level allowing a fast synchronization.
The value of the search initiator_threshold must be chosen so that the server systems next to an
initiator lock on it immediately. but the server systems a bit further away (maybe on an other
network) do only lock on it after the search_initiator_time_out timer expires_ The default value is 98
dl3uV_

cC Copynght 1997-20;1'9 OLMS User Associaton
▪▪
NEW and UNLOCKED

mac adlretss - NEW
4
auks Moor = isystern_tille = O. chenl_rnas = G. L SAP =
ifilljalorrnacaddress = NOBODY
Save isetaul! va.tAs

SET syrtchronizabonconlemalFoolimeoul = 3- 5 s
SET repealer status never repeater
Server system does nal repeal and answer In any frames
LegeDEL
Valid frame SI_ laresnekl - searchindetorthreshold
raceme& Ho Slime OW Sean:m initiator brie Out
Yes
lr
START Sl_tme_Out
1.4erronze {Signal 19rg1. inNator_maC_OOKIres0
Signal level
SI_Ihreseeld No
Yee. Desync hroni ze
FAN SyrchrONWelese Search
Irrililtot
Phase
V
SI we out
rogureir .
LOOK On iriirla iwith Wronged! lignal No
RESTORE clePags syncivorhumpon corthrmaitelorne_out

RESTORE cielzsel repealer slake Va.i.d frame
START SyrYclvonizalYan ccinennalion lerne_Ourl received"'
START lime Owl frame nor QI
Yes
V
RESTART SI lime our
■
NOV old LOCKED
mac ..dress • NEW
active 'malty • 1Sydleni Trek • a Cheat. mac • valid. L SAP • Cl
llyriOlvOzenbOo_iedged - TRUE
ashator_macaddraea • client _mac
I STOP al 4rners runriaig
START limeOultne101dreede0
•
V Check
filt hier
Valid frame lei eneed 7 Phi**
Na
T Vas
$1 Br 4 Out
RESTART Si km out
eisreol Vas
No
Regis[erecl ,
IVs
V
Yea
lime wt
STOP SI hme al ndl adZires;ed
flu:plea? Yes
•
RE G ISTERED and LOCKED No
maic_adyess vabd
drifivojNiedee
[evetem_litle ctlieo_mac = yam_ L . _SAP =
Maw omecaddress cipent_rrac
syrolvevizaborijockad TRUE
START Imo art_red ecleleessed
NOTE A valid frame is a frame in which either the source or the destination address is an initiator address, and
otherwise correct.
Figure 98 - Intelligent Search Initiator process flow chart
10.4.5.7.2.3 Search Initiator Phase

Initially, the server system is in the NEW and UNLOCKED state waiting to receive a valid frame.
For the Search Initiator Phase, the synchronization_confirmation_time_out shall be reduced to 3-5
s- Otherwise, a server system would remain synchronized too long on a bad frame_
DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 238./310

DIMS User Association, COSEM Architecture and Protocols, Seventh Edition
During this phase, a server system must never repeat any frames. This is because if repetition was
allowed. it would have to repeat all frames, not only the frames from the closest initiator, and so the
other server systems next to it would listen to frames from a bad initiator with a strong signal level.
Therefore, the Intelligent Search Initiator algorithm can only be efficient if all the server systems on
a network have the algorithm implemented (otherwise, other server systems could repeat frames
and foul the signal level)
Far the same reasons. a server system must never transmit any frames during the Search Initiator
Phase:
• it should not answer to a Discover request (It should be desynchronized before, except if the signal level
is good enough to allow fast synchronization. But in this case. the server system is not in the Search
Initiator Phase anymore but in the Check Initiator Phase.):
• it should not answer to a Register request either;
• and in particular, it should not answer any ACSE or xDLMS service requests (this is obvious because the
server system is in the NEW state).
Notice that as soon as a server system becomes locked, it can repeat frames since it will only
accept frames from the good initiator, (It is even advised that it repeats frames, since it will shorten
the Search Initiator Phase for the other server systems).
Each time that the server system receives a frame. it checks the signal level and the MAC
addresses in it:
• if none of the MAC addresses — source or destination — is an initiator MAC address. the frame is
considered as invalid: the server system immediately desynchronizes in order to listen to another frame:
• if one of the MAC addresses is an initiator MAC address. and the signal level is good enough (signal
level > search_initiator_threshold — see 10.4.5.7.2,2) the server system locks on that initiator. This is
called Fast Synchronization. This occurs when the server system is next to an initi ator or to a server
system that is already registered to that initiator. The server system enters the Check Initiator Phase;
• if one of the MAC addresses is an initiator MAC address but the signal level is not good enough (signal
level < search_initiator_threshold), the server system memorizes the signal level and the MAC address,
then desynchronizes immediately in order to listen to another frame;
• when the search_initiator time_out expires, the server system locks to the initiator having provided the
best signal level.
At this point:
• the default values of the synchronization_confirmationtime_out and the repeater status are restored:
• the synchronization confirmation_time_out and the time_out_frame_not_OK timers are initialised;
• the search initiator time out is restarted.
The server is in the NEW and LOCKED state and enters the Check Initiator Phase_
I 0.4.5.7.2.4 Check Initiator Phase

-
Once the server system is locked, it can be discovered and registered. The process is the following:
• the time_out_not_addressed timer is started:

• the server waits then to be discovered and registered;
• the searchinitiator_time_out timer is restarted each time a valid frame is received:
• when the server system is registered (valid frame carrying a Register CI-PDU received):
• the search_initiator time_out timer is stopped;
• the active_initiator variable is set:
• if either the search initiatortime_out or the time out_not_addressed timer expires. it means that the
server system did not receive a frame from or to its initiator for a long time: all timers are stopped then
and the server system returns to the initial state: NEW and UNLOCKED.
1 a4.5. 72.5 Remarks
The Intelligent Search Initiator process has to be used cautiously. If a server system hears a frame
with a wrong MAC address. it will lock on it and won't unlock until the search_initiator_time_out is
over. It is advised not to change the initiator MAC address of a concentrator unless it can be made
sure that all the server systems on the network are in the unconfigurecl state: NEW and
UNLOCKED.
I DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0

© Copyright 1997-2009 DLMS User Associalion
2391310
DLMS User Associaton, COSEM Architecture and Protocols, Seventh Edition
10.4.5.8 The Discovery and Registration process

The Discovery and Registration process. including the Intelligent Search Initiator process. is
summarized in Figure 99.
NOTE The state transitions caused by writing the mac-address and initiator-mac-address variables are not shown_
NEW and UNLOCKED
mac address = NEW
active iritialor • •
Isystern ties = t1. cienl_esec L-SAP = Di
indicter mac address= NO-113DY Sitireeput
Of
time NA ncr addressed
timer expired
freeligeni Searth Initiator process
gourd rmtsator
STOP 21110119m
41
NEW and LOCKED
rnacarkees = NEW
actieeretatot -
15.01em_elle • a cletn_mac • valid. L-SAP • Of
Citcover and Register
syncrwanizatdon_hocked • TRUE
isynclocked = deiaul FALSE)
ireazaceinacaddrese cherkinac
START St wne
Dscover a nd Register START timeoulnotadcaessed
[sync IocIse0 - default TRUE]
reset new not synchronized

Cksoovei and Regrshw !valid dieni_rnacli
resell new nat . synchtcozed resetnewnot_tyncnremzed
• NOBODY) WRITE {invalid client _ meol
sr.:wo-IR:aeon _baled - FALSE
e r
REGISTERED and UNLOCKED REGISTERED and LOCKED
riL3C re$.S veld mac actress • void
aclue !mato.. stave„ veleta' •
{system tide • valid. chant mac • void. L SAP • valid, {system tele -• valid, chant mac • L -SAP • venal
einceckkeee • NO-ROGY tededremecaddrese •cdetd_tdric
synceldnicabod_llecked • FALSE synchrerazaiion_looked. TRUE
START thmecel_not_addressecl START tene_ocknot_addessed
th. 4
WRITE
Valid barn* reCONed Valid itarne received
wove-pave., iixikod • TRUE
Time DA not addressed brier expend

time out_eol_addreSSed rimer eivied
br
0f
reset n ror synchronized
reset . new net syncnronaed
INO-BODYI [NO BODY}
ibA
FORGOTTEN
STOP al 7.m-us
Sljime_out seasultInliox
Figure 99 - The Discovery and Registration process

The process is the following.
Initially. the server is in the NEW and UNLOCKED (UNCONFIGURED) state. In this state:
• mac address = NEW:

• active_initiator: default value, with all three elements set to 0:
o system title = octet string of Os:
O (clientirnac address = NO-BODY:
• L -SAP selector = 0:
• initiator mac address = NO-BODY .
The default value of the synchronization_locked variable is as specified in the companion

specification:

C Copyright 19-97-2009 INNS User Association
FALSE: the value of initiator_mac_address variable is always NO-BODY;

2. TRUE: the value of the initiator_mac_address variable follows the value of the
(client _)mac_address element of the active_initiator variable;
3. The Intelligent Search Initiator process is used. In this case, the value of the
search_initiator_time_out variable shall be different from G. The server moves from the NEW
and UNLOCKED state to the NEW and LOCKED state at the end of the Search Initiator
Phase.
NOTE This third possibility is an extension to IEC 61334-4-511.
When a server is installed. it has to be discovered and registered
In case 1). upon the reception of a valid Register CIASE PDU the server moves to the
REGISTERED and UNLOCKED state:
• the mac_address variable is set to the value allocated by the initiator:

• the elements of the active_initiator variable are set to the values contained in the Register CIASE PDU
and the DL-Data.indication LLC PDU:
• system_title: system title of the initiator;
• (client_)MAC_address: MAC address of the initiator:
• L-SAP_selector: the L-SAP used by the initiator:
• the initiator_MAC_address remains at NO-BODY;
• the synchronization_ _locked variable remains at FALSE:
• the time out not addressed timer is started.
In case 2), upon the reception of a valid Register CIASE PDU. the server moves to the
REGISTERED and LOCKED state:
• the mac address variable is set to the value allocated by the initiator;
• the elements of the active initiator variable are set to the values contained in the Register CIASE PDU
and the DL-Dataindication LLC PDU:
• system_title: system title of the initiator:
• (client _)mac_address: MAC address of the initiator:
• L-SAP_selector: the L-SAP used by the initiator;
• the initiator_MAC_address is updated to be equal to the (client_)MAC_address element of the
active initiator:
• the synchronization_locked attribute remains at TRUE;
• the time_out_not_addressed timer is started.
In case 3), the server searches first for the initiator providing the strongest signal; see Figure 98. At
the end of Search Initiator Phase, the search_initiator_time_out is re-started, the
time_out_not_addressed timer is started, and the server locks on the initiator chosen:
• the (server jrnac_address variable is still at NO-BODY (server is in NEW state);

• the synchronization_locked variable is set to TRUE:
• the (client_)MAC_address element of the active_initiator variable takes the MAC address of the initiator
chosen. The other elements of the active_initiator variable remain at their default value;
• the initiator_MAC_address is updated to be equal to the (client_)MAC_address element of the
active_initiator variable.
The server is in the NEW and LOCKED state and enters the Check Initiator Phase.
The server can only be registered by the initiator chosen. This takes place exactly as in case 2). If
the server is not registered before either the search_initiator_time_out or the
time out not addressed timer expires. it returns to the NEW and UNLOCKED state. All timers are
stopped.
In the REGISTERED state, the server may receive frames addressed to it and respond to them. The
tirne_out_not_addressed timer is restarted with each frame addressed to the server .
The server may also move from the REGISTERED and UNLOCKED state to the REGISTERED and
LOCKED state and vice versa by writing the value of the synchronization_locked variable.

0 Copyright 1997-2009 OLMS User Association
* < 242 > Q IV:. Ct A T T
0
The server may leave the REGISTERED state either:
1) by the expiration of the time_out_not_addressed timeout: or

2) by writing the reset_new_not_synchronized variable.
In case 1), the server becomes "FORGOTTEN: it loses its MAC address and its active initiator: the
mac_address, the initiator_mac_address and the active_initiator variables are all reset. The server
returns to the NEW and UNLOCKED state.
In case 2) the server checks first the value of the client mac address submitted as a parameter of
the reset new not synchronized request:
• if the value is not equal to a valid client address. or the pre-defined NO-BODY address. the writing is
refused;
• if the value is NO-BODY, it has the same effect as the expiration of the lime out not addressed timer:
the server returns to the NEW and UNLOCKED stale;
• if the value is a valid client address. then the value of the synchronization locked variable is checked:
• if it is FALSE -the server is in the REGISTERED and UNLOCKED state - the writing is refused;
• if it is TRUE - the server is in the REGISTERED and LOCKED state - the (client_)mac_address
element of the active initiator variable is set to the value submitted. the system_title and the L-
SAP_selector elements are reset to 0. The initiator_mac_address variable is also set to the value
submitted. The time_out_not_addressed timer is stopped. The server returns to the NEW and
LOCKED state, where it waits to be registered again by the initiator it has been reset to.
When the server leaves the REGISTERED state. all AAs are aborted.
If a power failure occurs. it is managed as follows:
■ if the server is in the NEW and UNLOCKED state. it will stay there when the power returns;
• if the server is in the Search Initiator Phase. then it moves back to the NEW and UNLOCKED state when
the power returns. The search_initiator_time_out timer is stopped and all data concerning the initiators
heard so far (signal level and MAC address) are lost:
• if the server is in the NEW and LOCKED state. it will stay there when the power returns. The
search_initiator_time_out and the time_out_nal_addressed timers are restarted:
• if the server is in the REGISTERED (LOCKED or UNLOCKED) state. it will stay there when the power
returns. The time_out_not_addressed timer is restarted. The Application Associations open before the
power failure are locally re-established.
10.4.5.9 Abstract and transfer syntax

As specified in IEC 61334-4-511 7.3,1, the CIASE uses the ASN.1 abstract syntax. The transfer
syntax is A-XDR.
10.4.6 Addressing
10.4.6.1 General
In the DLMS COSEM S-FSK PLC profile. two levels of addresses are defined:
■ at the MAC sublayer that processes MAC addresses to access an LLC entity;
• at the LLC sublayer that processes LLC addresses to access application entities.
10.4.6.2 IEC 61334-5-1 MAC addresses

A physical client or server - initiator or responder - system may be accessed using a MAC address
specific to the system or by using one of the group MAC addresses.

3-iRMPLA-Mg, - FSMNI2M
Mg.Lk• - tYbt,5&-f-1411ED. 21traWat.',3!
id. -L:15
iftop-1.0-0.pre3.el....rpm es El 2020-12-08 Datatxt SUBOLconi_the.pr....zip S The Princess Di....torrent " Shaw all X
ATM PEI *Ca < 243 / 310 > CI Q ••■ A A T T
Table 64 — MAC addresses
Address Value Reference

NO-BODY 000 IEC 61334-4-1 4.3.2.6,
IEC 61334-5-1 4.3.7.5.1
Local MAC 001...FIMA-1 IEC 61334-4-1 4.3.2.5
Initiator FIMA...LIMA IEC 61334-4-1 4.3.2.4

MAC group address LIMA + 1...FFB
FFC IEC 61334-4-1 4.3.2.1,
All-configured
IEC 61334-5-1 4.3.7.5.2
IEC 61334-4-1 4.3.2.2,
NEW FFE
IEC 61334-5-1 4.2.3.2
FFF IEC 61334-4-1 4.3.2.3,
All Physical
IEC 61334-5-1 4.3.7.5.3
NOTE MAC addresses are expressed on 12 bits.
FIMA = First initiator MAC address, COO
LIMA = Last initiator MAC address: DFF
10.4.6.3 Reserved special LLC addresses

NOTE This clause is based on IEC 61334-4-1 clause 4.4.
10.4.6.3.1 General
Each application process within the physical device is bound to a data link layer address t
consists of the doublet {MAC-address, L-SAP}. The following LLC addresses (L-SAPs)
specified:
• All-L-SAP: designates the group consisting of all L-SAPs actively serviced by the underlying MAC layE
(with its specified MAC address);
• system management L-SAP (M-L-SAP): there is only one M-L-SAP in a physical system;
• initiator L-SAP (l-L-SAP): These are defined in a specific range;
• individual LLC addresses: These are defined in a specific range;
• CIASE L-SAP (C-L-SAP).
10.4.6.3.2 Reserved addresses for the IEC 61334 4 32 LLC sublayer - -
The reserved LLC addresses for the IEC 61334-4-32 LLC sublayer on the client side and the ser
side are shown in Table 65 and Table 66 respectively.
Table 65 — Reserved IEC 61334-4-32 LLC addresses on the client side
Address L-SAP Meaning
OxOO No-station
M-L-SAP Client management process. The CIASE is also bound to this

Ox01
I-L-SAP address.
Ox10 Public client (lowest security level)
Table 66 — Reserved IEC 61334-4-32 LLC addresses on the server side
Ox00 I-L-SAP CIASE
Ox01 M-L-SAP Management logical device
Ox02...0x0F Reserved for future use

OxFF Alt-L-SAP _ All-station (Broadcast)
10.4.6.3.3 Reserved addresses for the HDLC based LLC sublayer

The reserved LLC addresses for the HDLC based LLC sublayer on the client side and the ser
side are shown in Table 67 and Table 68 respectively.


javascript;
iftop-1.0-0.pre3.el....rpm n El 2020-12-08 Datatxt n SUBDLcom_the.pf....zip Et The Princess Di...torrent n Shaw all X

PEI .=-7F7 * < 244 /310 > Q 1"4: Q 1a ► 4' .AATTT,
Table 67 — Reserved HDLC based LLC addresses on the client side
Ox00 No-station
M-L-SAP Client management process. The CEASE is also bound to this
Ox01
I-L-SAP address.
Ox10 Public client
Table 68— Reserved HDLC based LLC addresses on the server side
One byte Two bytes address Meaning

address
Ox00 Ox0000 No-Station. The CIASE is also bound to this address.
Ox01 Ox0001 Management logical device
0x02...0x0F Ox0002...0x000F Reserved for future use

Ox7E Ox3FFE Calling physical address, not used in the S-FSK HDLC based
profile.
Ox7F Ox3FFF All-station iBroadeast)
10.4.6.4 Source and destination APs and addresses of CI-PDUs

The Source and destination APs and addresses of CI-PDU requests are show in Table 69.
Table 69 — Source and Destination APs and addresses of Cl -PDUs
Destina lion
CI-PDU Source AP MAC SA MAC DA D-L-SAP S-L-SAP
AP
FFF Ox00 Ox01
Discover Initiator AIISMAE Initiator
All-Physical CIASE CIASE
NEW FFE 2 FEE S

All-Physical Ox00
DiscoverReport Manager AIISMAE or individual OxFD
CIASE
server MAC or Initiator
FFF Ox00 Ox01

Register Initiator AIISMAE Initiator
All-Physical CIASE CIASE 4
000 Ox01
PingRequest Initiator Individual Initiator Individual
CIASE CIASE 4
001 Ox00
PingResponse Individual Initiator Individual Initiator
CIASE 4 CIASE
FFF Ox00 Ox01

RepeaterCall Initiator AIISMAE Initiator
All-Physical CIASE CIASE '
FFF Ox00 0)(01

ClearAlarm Initiator AIISMAE Initiator
All-Physical CIASE CIASE 4
II Could be a different value

21 FFE if the server is in the NEW state. Individual MAC address if the server is in ALARM state.
31If the reporting system list feature is used, then the Destination Address is All-Physical. Otherwise, it is the
Initiator address.
`1 Could be different value, but must be the same as in the Discover CI-POU.
NOTES
In the MAC frame, the order of the addresses is Source Address — Destination Address.
In the IEC 61334-4-32 LLC frame, the order of the addresses is Destination Address — Source Address.
In the HDLC frame, the order of the addresses is Destination Address — Source Address.

Copyright 1997 2009 DLMS User Association
-
OLMS User Association, COSEM Architecture and Protocols, Seventh Edition
iftop-1.0-0.pre3.el....rpm M 2020-12-08 Dataal es 3 SUBDLcom_the.pr....zip V The Princess Di....torrent " Shaw all X
e: < 245 / 310 > g 4. A AT TT/ 4 * 0
10.4.7 Specific considerations / constraints for the IEC 61334-4-32 LLC

sublayer based profile
10.4.7.1 Establishing application associations
AAs can only be established with server systems properly registered by the initiator. The MSC
the discovery and registration process is shown in Figure 100.
Client CNent Client Client Client Server Server Server Server Server
SMAP CIASE LW layer MAC layer Phy layer Phy layer MAC layer LW layer CASE SMAP
D4covectsa
wra req
(Casccwe, POUr
-P
MA Datuaq
P Datareq
P-Data and
In.
P.Data_cni MA-Datand
01.-Data we
MA-Oaia_crt iDisco ,e, POU1
..,
Di Oata o4 —'.. Discover Ind
DL-Oatared Discover too

IDtscovarRaport -0—
POLO
PAP - DatalPq
P-Data req
P , Data_nd
tX - Omaind MA-Data. Ind P-DalacnI
fent4ove4Mpart ▪ MA-Data cnt
POUT
Discavet.cri a- DL-Data
4
Reglatermq
O1.-Datarea
pliegertar PDIS).
MA-Dal teal
P Omaraq
P-Data_ ncl
P Oaracnt ▪ MA-Data
DL-Dataind
a
PIPrOadacnt ( Register
ODD)
DL-Oala-c4 ▪ Register. ird
CF at 1-0 Serer Cartigtrahon A.SE a n Reg.:tared dare
Figure 100 — MSC for the discovery and registration process

The MSC for the establishment of a confirmed AA establishment is shown in Figure 101.


javascript;
iftop-1.0-0.pre3.el....rpm e Q 2020-12-08 Datatct n ¢ SUBDLcom_thepr. . n 3 The Princess Di....torrent n Show all X

.=.7E7 * < 246 / 310 ) Q 14. Q « 4. A .0 T -r• 0 * 0
ULMS User Association, COSEM Architecture and Protocols, Seventh Edition

Client awn! Client Saver Server Server
Application Application Application Applicator
LLC layer MAC layer Phy layer Phy layer MAC layer LLC layer
Process layer layer Process
MAC SAP 11 Alive male. 1.1Z SAP artve state
COSEM-OPEN
rEq
P- ElLtlata/ecr
EAARO)
am-oEda/m
P-DavErfft
OL-Data
MA-Eramxt4
i/AR0! COSEM-OPEN
DL-lkeacit
CoSEm-OPEN
E1L-Patar.1
Ne6
MARE)
MA-DaLt.ena
P-Datareq
MA•Deland • POMaxot
' DLCale 1.114-13NW
COSEMOPEN iAARE1
cer
PL-ofa. rent
rhs ,equestwi M successetry estak*sherl
Figure 101 — MSC for successful confirmed AA establishment
10.4.7.2 Application association types, confirmed and unconfirmed xDLMS services

Table 58 shows the rules for establishing confirmed and unconfirmed AAs. In this table, grey areas
represent cases, which are out of the normal operating conditions: either not allowed or have no
useful purpose. According to these:
• it is not allowed to request an xDLMS service in a confirmed way (Service_Class = Confirmed) within an
unconfirmed AA. This is prevented by the Client AL. Servers receiving such APDUs shall simply discard
them, or shall send back a ConfirmedServiceError APDU or — if the feature is implemented — send back
the optional ExceptionResponse APDU.
In this profile, the Service_Class parameter of the COSEM-OPEN service is linked to the response-
allowed parameter of the xDLMS InitiateRequest APDU. If the COSEM-OPEN service is invoked
with Service_Class == Confirmed, the response-allowed parameter shall be set to TRUE. The
server is expected to respond. If it is invoked with Service_Class == Unconfirmed, the response-
allowed parameter shall be set to FALSE. The server shall not send back a response.
The Service_Class parameter of the GET, SET and ACTION services is linked to bit 6 of the
Invoke_Id_And-Priority byte. If the service is invoked with Service_Class = Confirmed, bit 6 shall be
set to 1, otherwise it shall be set to 0.
Table 70 — Application associations and data exchange in the S FSK PLC profile using the connectionless LLC sublayer
-
Protocol
COSEM-OPEN Type of
connection Service class Use
service class established AA
parameters
Exchange 01-Data
AARO/AARE Confirmed
services
APDU-s
Confirmed Confirmed
transported by
DL-Data
id. 01-Data Unconfirmed
services
services
LLC addresses,
MAC addresses Confirmed
Send AAFIQ
(not allowed)
transported by
Unconfirmed Unconfirmed
01-Data
01-Data
services Unconfirmed
services

OLMS User Association. COSEM Architecture and Protocols, Seventh Edition
2020-12 ,08 Datatct es 3 suBDLcom_the.pr....zip V The Princess Di....torrent " Shaw all X
tr < 247 0, A T T 1 6 O f1 .

No specific features constraints apply related to the use of client/server type services.
The MSC is essentially the same as for establishing confirmed AAs, except that instead of
COSEM-OPEN service primitives, the appropriate xDLMS service primitives are used.
10.4.7.4 Releasing application associations

As the LLC sublayer supporting the COSEM Application layer is connectionless, the COSE
Release service may be invoked with the Use_RLRQ_RLRE option = TRUE to release an AA.
To secure the RLRQ APDU against denial-of-service attacks — executed by unauthorized releas
of the AA — the user-information field of the RLRQ APDU may contain the xDLMS InitiateRequ
APDU. authenticated and encrypted using the AES-GCM-128 algorithm, the global unit
encryption key and the authentication key (the same as in the AARQ APDU).
The MSC for releasing an AA is shown in Figure 102.
Client Clam Server Server

Chest Client Client Server Server Server
Application Application Application Application
Process layer Layer Process
Figure 102— MSC for releasing an Application Association
10.4.7.5 Service parameters of the COSEM-OPEN / -RELEASE / -ABORT services

The optional User_Information parameters of the COSEM-OPEN - RELEASE services are
supported in this communication profile.
10.4.7.6 The EventNotificalion service and the TriggerEventNotificationSending

service
The EventNotification (LN referencing) / InformationReport (SN referencing) services are suppor
by the DL-Update-Reply and DL-Reply services of the LLC sublayer:
• in the case of LN referencing. the EventNotificationReguestAPDU shall be placed into the LLC sublayi
using the DL-Update-Reply.request service;
• in the case of SN referencing, the InformationReportReguest APDU shall be placed Into the LLC
sublayer using the DL-Update-Reply.request service;
• these APDUs are available then for any client until they are cleared by placing an empty APDU.
The length of the APDUS shall not exceed the limitation imposed by the LLC i MAC sublayers.
The MSC for an EventNotification service is shown in Figure 103.

© Copyright 1997-2009 ULMS User Association
DLMS User Association. GOSEM Architecture and Protocols. Seventh Edition
pre3. el....rpm El 2020-12-08 Dataal " suBDLcom_the.pr....zip •••• V The Princess D....torrent •••• Shaw all X
r_i. * < 248 3:0 0, A T. T 11_04

Client Client Client Server Server Sewer
Applicator
Application Appkcation Application
Process layer layer Process
I/AC SAP it Petrie slab= LLC SAP it./Swe stale
Placing the LliDLI este seal in ne LLC layer
entNetihrabon
PL-Lipdate_iiely a ' rN •
- req_
OLLithale_relir
meths
•••
Another service cases the serve, earerrii
D•Ilara_req
rt
01.410.1-d
MAJaithierri
• es.
OL-Itharzeif
DL-5.b
Reply.in0
The okra is rotfied thou the avelablity of an L-SCU and requests that 4 i5
Trialer_Erent
hlkulisapt
roe
DL-Repyne•
MAtheltheil
- ev-
MA-Daiatent
PAA-DatArtil
LIP, retiree
The APOLI Wang the evert a sumenvidely ireislerved
Figure 103 — MSC for an EventNotification service

In the S-FSK profile, the IEC 61334-4-32 LLC sublayer imposes a limitation on the length of the
APDU that can be transported. For transporting long messages, application layer block transfer is
available.
10.4.7.8 Broadcasting
Broadcast messages can be sent by the data concentrator, acting as a client, to servers using
broadcast addresses.
10.4.8 Specific considerations / constraints for the HDLC LLC sublayer

based profile
10.4.8.1 Establishing application associations
Application Associations can only be established with server systems, which have been properly
registered by the initiator.
The MSC for the discovery and registration process is shown in Figure 104.
DLMS User Association 2009 12 22 DLMS UA 1000-2 Ed. 7.0 248/310

O Copyright 1997 - 2009 DLMS User Association
iftop-1.0-0.pre3.el....rpm M 2020-12-08 Datatct n suBDLcom_the.pr....zip V The Princess D....torrent n Shaw all X

71 * < 249 / 310 > Rik 4...AAT TT/ f 7 A 0
Ghent Server
Clare m1 Client Sarre, Server Server
HDLC based HDLC based
SMAP CASE MAC Layer MAC layer CIASE SMAP
LLC Layer LLC Layer
Discover_req
1.•
KNIX4rA•Mll)
14.
MA-DATAneq IUD
lan-OAT aro NI(
OL-DATA Intl
(Oil:cave, Pal.
12.coveLind
4.,
DL-DATArom
tOiice•rensei FON
re
1.1101-DAEkreq
M4DATAi4de,11
134,DATAirri
CE4SCOverRnt.1 MU)
Dualower.rof
DL-OATAnq
Indeele, FON
ALA-DATAmo
LIA-RATAind CLA)
DATA Ind
LR1.2414, P011(
Regist,ind
CF cars Server Ce-eprakereheio, AM in Fhesomed Mae
I I I
Figure 104 — MSC for the Discovery and Registration process
The MSC for the establishment of a confirmed AA establishment is shown in the upper part
Figure 105.
Ghent GliQnt Ghent Sew, Server Server

Cikerl Sorrel
Application Application H DLC based HDLC based Application Application
MAC layer MAC layer
Process layer LLC layer LLC layer Payer Process
RiAc SAP .1 Ades Slate, LLC SAP r Aare SLUe
COSEJA-OPEN.mq
OL-CONNECUN
PAP.-OATArefi (5.1111A WA-OATA. ,.:1(SHR447
MA-DT:xi1AI 11A-DATA-req IGAI
el -CO.F_CT ay.
DiAIATA.reg (AARO1 .,
MA-LMTA-reg irAnArAind
DL-OATArd .IAAR0(
COSEM-OPER..i
COSELI-OPEN.res
OLDATA_Re 4+NREi
1114DATAintl Ill MA.OATA.rea ih
OL-DATA. (AARE) •
GOSE111,005110
CF of the Sener ASOn Assam., Eastasneo &ate
COSEAGELreq
01.-DATA/4.4 (GE 1, deo)
1.1A-DATAreq MA-DATA:xi Ill
•r4..-DATlurd (C.ET-re,,
GOSEM.T.
nrICIFIA-GET.F.
Ly._ rArea fGET ad)
IAA-DATA..xi II) IIA-DATAreq
0!-E(ATA.1.1 PE T- , 44/
COSEIFGET
r.
'
Figure 105 — MSC for successful confirmed AA establishment and the GET service
10.4.8.2 Application association types, confirmed and unconfirmed xDLMS servic

10.2.6.1 applies.

The MSC for a COSEM GET.request service — preceded with the establishment of an AA — is she
in lower part of Figure 105.

iftop-1.0-0.pre3.el....rpm El 2020-12-08 Dataal es 3 suBDLcom_the.pr....zip V The Princess a...torrent es Shaw all X

* < 250 / 310 > C/ 14. Q 671 4. A I T T -t3 Qs
10.4.8.4 Correspondence between AAs and data link layer connections, releasing
AAs
10.2.6.2 applies.
10.4.8.5 Service parameters of the COSEM-OPEN/ -RELEASE/ -ABORT services

10.2.6.3 applies.
10.4.8.6 The EventNotification service and protocol

10.2.6.4 applies. except that the EventNotificationRequestAPDU can be sent only when the server
is registered and synchronized with the initiator.

10.2.6.5 applies.
10.4.8.8 Broadcasting
Broadcast messages can be sent by the data concentrator, acting as a client, to servers using
broadcast addresses.

Cr Copyright 1997-2009 DLMS User Association
❑ LMS User Association, COSEM Architecture and Protocols, Seventh Edition

javascript.
iftop-1.0-0.pre3.el....rpm M 2020-12-08 Datatxt " SUBDLcom_the.pr....zip " 2- The Princess Oi....torrent " Shaw all X
< 251 Q 14 :: A ." T T £ 0
11. AARQ and AARE encoding examples
11.1 General
This chapter contains examples of encoding the AARQ and AARE APDUs. in cases of using varic
levels of authentication and in cases of success and failure
In COSEM. the AARQ, AARE. RLRQ and RLRE APDUs — see 9.4 .2 — shall be encoded in E
(ISO/IEC 8825). The user-information f i eld of the AARQ and AARE APDUs contains the xDL
Initiate Request / InitiateResponse or ConfirmedServiceError APDUs respectively, encoded in
XDR as OCTET STRING.
11.2 Encoding of the xDLMS InitiateRequest / InitiateRespon5

APDU
The xDLMS InitiateRequest / InitiateResponse ADPUs are specified as follows:
InitiateRequest ::= SEQUENCE
shalt not be encoded in DLMS without ciphering

dedicated - key OCTET STRING OPTIONAL,
response-allowed BOOLEAN DEFAULT TRUE,
proposed-quality-of-service IMPLICIT integer. OPTIONAL,
proposed-dims-version-number Unsigned8,
proposed-conformance Conformance,
client-max - receives nt: size UnsignedlE
InitiateResponse ::. SEQUENCE
negotiated-quality-of-service IMPLICIT Integer- OPTIONAL,

negotiated -dims-version-number UnsignedB,
negotiated-conformance Conformance,
server-max-receive-pdu-size Unsignedlfi,
vaa-name ObjectName
The xDLMS InitiateRequest and InitiateResponse APDUs are encoded in A-XDR and they
inserted in the user-information field of the AARQ / AARE APDU respectively.
In the examples below, the following values are used:
■ dedicated key: not present: no ciphering is used:

▪ response-allowed: TRUE (default value):
• proposed-quality-of-service and negotiated-quality-of-service: not present (no1 used in DLMS/GOSEM
• proposed-conformance and negotiated-conformance: see below;
• proposed-dims-version-number and negotiated-dims-version-number = 6;
■ client-max-receive-pdu-size: 1200 D = Ox04BO:
• server-max-receive-pdu-size: 500 D = Ox01 F4;
• vaa-name in the case of LN referencing: the dummy value Ox0007:
• vaa-name in the case of SN referencing: the base_name of the current Association SN object, OxFAO(
• The proposed-conformance and the negotiated-conformance elements carry the proposed conforman
block and the negotiated conformance block respectively. The values of these examples, for LN
referencing and SN referencing respectively, are shown in Table 71.

C) Copyright 1997-2009 DLMS User Association

javascript;
iftop-1.0-0.pre3.el....rpm 2020-12-C8 Data txt SUBDLcom_the.pr ..zip ••••• 2 The Princess Di....torrent Shaw MI X
.=-7F7 < 252 / 310 ) Q of ::Q ot 4 ,4AATITT, +I0 a 0
Table 71 - Conformance block
Conformance ::= [APPLICATION 31]

LN referencing SN referencing
IMPLICIT BIT STRING (SIZE(24)1
1
-- the hit is set when the
Used
corresponding service or Proposed Negotiated Proposed Negotiated
with
functionality is available
reserved-zero (0), o a a a
reserved-one (1), o a a a
reserved-two (2), 0 0 0 0
read (3), SN 0 0 1 1
write (4), SN 0 0 1 1
unconfirmed-write (5), SN o a 1 1
reserved-six (6), 0 0 0 0
reserved - seven (7), 0 0 0 0

attribute0-supported-with-set (8), LN o o o a
priority-mgmt-supported (9), LN 1 1 a o
attribute0-supported-with-get (100, LN 1 a o a
block-transfer-with-get-or-read (11), LN 1 1 0 0
block-transfer-with-set-or-write (12), LN 1 o o a
block-transfer-with-action (13), LN 1 0 0 a
LS N /
multiple-references (14), 1 0 1 1
LS
information-report (15), SN o o 1 1
reserved-sixteen (16), 0 a 0 0
reserved-seventeen (17), 0 0 0 0
parameterized-access (18), SN o o 1 1
get (19), LN 1 1 0 0
set (20), LN 1 1 0 0
selective - access (21), LN 1 1 a a

event-notification (22), LN 1 1 0 0
action (23) LN 1 1 o o
Value of the bit string 00 7E IF 00 50 IF IC 03 20 1C 03 20

iftop-1.0-0.pre3.el....rpm M 2020-12-08 Dataal ■•• SUBDLcom_the.pr....zip " V The Pnncess a...torrent " Shaw MI X
* < 253 / :;10 :: A.AT TT/ ID a . 0
With these parameters, the A-XDR encoding of the xDLMS InitiateRequest APDU is the following
Table 72 — A-XDR encoding the xDLMS InitiateRequest APDU
-- A-XDR encoding the xDLN InitiateRequest APDU LN referencing SN referencir

// encoding of the tag of the DLMS APD0 CHOICE DI G1
(InitiateReguest)
-- encoding of the dedicated-key component (OCTET

STRING OPTIONAL)
// usage flag(FALSE, not present) 00 00
-- encoding of the response - allowed component (BOOLEAN

DEFAULT TRUE)
/i usage f lag (FALSE, default value TRON conveyed) 00 013
-- encoding of the proposed - quality-of-service

component (10/ IMPLICIT Integera OPTIONAL)
// usage flag(FALSE, not present) 00 00
-- encoding of the proposed dims version-number

- -
component (Unsigned6)
// value= 6, the encoding of an Unsigned8 is its value 06 06
-- encoding of the proposed-conformance component

(Conformance, (APPLICATION 31) IMPLICIT BIT STRING
(SIZE(24)) '
// encoding of the [APPLICATION 31] tag (Asm.1 explicit OF IF OF 1F
tag) 2
// encoding of the length of the 'contents' field in 04 04

octet (4)
// encoding of the number of unused bits in the final 00 DO
octet of the BIT STRING i0)
// encoding of the fixed length BIT STRING value 00 7E 1F 1C 03 20
-- encoding of the client-max-receive-pdu-size

II value = 0x0420, the encoding of an Unsigned16 is its 04 20 04 20

value
-- resulting octet-string, to be inserted in the user- 01 00 00 00 06 01 00 00 00 06
information field of the AARQ APDU 5F IF 04 00 00 5F IF 04 00 1C
7E IF 04 BO 03 20 04 BO
' As specified in IEC 61334-6, Annex C, Examples 1 and 2, the proposed-conformance element
of the KOLMS InitiateRequest APDU and the negotiated-conformance element of the xULSM
InitiateResponse APDU are encoded in BEA. That's why the length of the bit-string and the
number of the unused bits areencoded.
2 For encoding of identifier octets, see ISO/IEC 8825 Ed.3.0:2002, Clause 8.1.2. For
compliance with existing implementations, encoding of the [Application 31] t ag on one byte
(5F) instead of two bytes (5F 1F) is accepted when the 3-layer, connection - oriented, HDLC-
based profile is used.

54MY5A4a, 9A-Olcifil3gEU350n
rAtz*, Auggia ttmtv, 3ztvla, mihr-ACOZ!
javascript;
El 2020-12-08 Dataal es 3 suBDLcom_the.pr....zip V The Princess Di....torrent Shaw MI X

WI* * < 254 ri Q 1r4 NR A AT."±"T„, d ,0 A 0
The A-XDR encoding of the xDLMS InitiateResponse APDU is the fo l lowing:
Table 73 —A-XDR encoding the xDLMS InitiateResponse APDU
-- A-XDR encoding the xDLMS InitiateResponse ADM' LN referencing SN referencing
Ii encoding of the tag of the DLMS APDLi CHOICE LE CO

(InitiateResponse)
-- encoding of the negotiated-quality-of-service

component ([O] IMPLICIT Integer8 OPTIONAL)
iv usage flag(FALSE, not present) 00 00

-- encoding of the negotiated-dims-version-number
component (lnsigned8)
// value = 6, the encoding of an Unsigned8 is its value 06 06
--encoding of the negotiated-conformance component

(Conformance, [APPLICATION 31] IMPLICIT BIT STRING
(SIZE(24))
I/ encoding of the [APPLICATION 31] tag (ASN.I explicit 5F IF 5F IF

tag)
// encoding of the length of the 'contents' field in 04 04
octet (4)
/1 encoding of the number of unused bits in the final 00 00
octet of the BIT STRING (0)
// encoding of the fixed length BIT STRING value 00 50 IF 1C 03 20
--encoding of the server-max-receive-pdu-size

// value = Ox01F4, the encoding of an Unsignedl6 is its 01 F4 01 F4
value
-- encoding of the VAA-Name component (ObjectName,

Int egerI 6)
II value=0x0007 for LN and OxFAOO for SN referencing; 00 07 FA 00

the encoding of a value constrained Integerlfi is its
value
-- resulting octet-string, to be inserted in the user- 08 00 06 5F 1F 08 DO 06 5F OF

information field of the AARE RPM' 04 00 00 50 IF 04 DO IC 03 20
01 F4 DO 07 01 F4 FA 00

Copyright 1997 -2009 DLMS User Asso c iation
iftop-1.0-0.pre3.el....rpm El 2020-12-08 Datatct ^ suBDLcom_the.pr....zip V The Princess Di...torrent " Shaw MI X

*&,16 < 255 /310 > =4 Hot F Y A AT Ira -0 * 0
11.3 Specification of the AARQ and AARE APDU

The AARQ and the AARE APIDUs are specified as follows:
AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE
[APPLICATION 01 == 60H 1 = 96 1
protocol-version [0] IMPLICIT BIT STRING [versionl (0)1 DEFAULT {versionl

application-context-name [1] Application-context-name,
called-AP-title (2] AP-title OPTIONAL,
called-AE-qualifier [3] AE-qualifier OPTIONAL,
called-AP-invocation-id [4] AP-invocation-identifier OPTIONAL,
called-AE-invocation-id [6] AE-invocation-identifier OPTIONAL,
calling-AP-title [6] AP-title OPTIONAL,
calling-AE-qualifier [7] AE-qualifier OPTIONAL,
calling -AP - invocation- id [8] AP-invocation-identifier OPTIONAL,
calling-AE-invocation-id [9] AE-invocation-identifier OPTIONAL,
sender-acse-requirements [10] IMPLICIT ACSE-requirements OPTIONAL,
The following field shall only be present if the authentication functional unit is selected.
mechanism-name [111 IMPLICIT Mechanism- name OPTIONAL,
calling-authentication-value 112] EXPLICIT Authentication-value OPTIONAL,

implementation-information (291 IMPLICIT Implementation-data OPTIONAL,
user-information [30] EXPLICIT Association-information OPTIONAL
- - The user-information field shall carry an InitiateRequest APDU encoded in A-XDR, and then
- - encoding the resulting OCTET STRING in BER_
AARE-apdu ::= [APPLICATION 1] IMPLICIT SEQUENCE
[APPLICATION 11 61H [ 97 1
protocol-version [0] IMPLICIT BIT STRING (versionl (0)) DEFAULT {versionl

application-context-name [1] Application-context-name,
result [2] Association-result,
result-source-diagnostic [3] Associate-source-diagnostic,
responding-AP-title (4) AP-title OPTIONAL,
responding-AE-qualifier [5] AE-qualifier OPTIONAL,
responding-AP-invocation-id (6] AP-invocation-identifier OPTIONAL,
responding-AE-invocation-id 17] AE-invocation-identifier OPTIONAL,
responder-acse-requirements [8] IMPLICIT ACSE-requirements OPTIONAL,
mechanism-name (9] IMPLICIT Mechanism-name OPTIONAL,
responding-authentication-value 110] EXPLICIT Authentication-value OPTIONAL,
user-information [30] EXPLICIT Association-information OPTIONAL
- - The user-information field shall carry either an InitiateResponse (or, when the proposed xOLMS
- - context is not accepted by the server, a ConfirmedServiceError) APDU encoded in A-XDR, and they
- - encoding the resulting OCTET STRING in BER.

" 2020 - 12 - 08Datalxt " suBDLcom_the.pr....zip V The Princess Di...torrent ^ Shaw ,II X
< 25.5 0, R A T. "±"T„, d .0 A et;
11.4 Data for the examples

In these examples:
• the protocol-version is the default ACSE version:

• the value of the application-context-name:
in the case of LN referencing, with no ciphering: 2, 16, 756, 5, 8, 1, 1;
in the case of SN referencing, with no ciphering: 2, 16, 756, 5, 8, 1. 2;
• the optional called-AP-title, called-AE-qualifier, called-AP-invocation-id, called-AE-invocation-id, calling-
AP-title, calling-AE-qualifier. calling-AP-invocation-id. calling-AE-invocation-id fields of the AARO. and
the responding-AP-title, responding-AE-qualifier. responding-AP-invocation-id. responding-AE-
invocation-id, of the AARE are not present:
• the value of the mechanism-name:
o in the case of low-level-security: 2, 16, 756, 5, 8, 2, 1;
O in the case of high-level-security (5): 2. 16. 756. 5, 8, 2, 5;
• the calling-authentication-value:
O in the case of low-level-security is 12345678 (encoded as 31 32 33 34 35 36 37 38);
in the case of high-level security, (challenge CtoS) is K56iVagY (encoded as
4B 35 36 69 56 61 67 59);
■ the responding authentication-value (challenge StoC) is P6wRJ21 F (encoded as
50 36 77 52 4A 32 31 46);
• the optional implementation-information field in the AARQ and AARE APDUs is not present;
• the user-information field carries the xDLMS InitiateRequest / InitiateResponse APDUs as shown above.
The application-context-name and the (authentication) mechanism-name OBJECT IDENTIFIERS
are encoded as follows:
• BER Encoding for OBJECT IDENTIFIER is a packed sequence of numbers representing the arc labels.
Each number - except the first two. which are combined into one - is represented as a series of octets,
with 7 bits being used from each octet and the most significant bit is set to 1 in all but the last octet. The
fewest possible number of octets must be used:
• in the case of the application context name LN referencing with no ciphering the arc labels of the object
identifier are (2, 16, 756, 5, 8, 1. 1);
• the first octet of the encoding is the combination of the first two numbers into a single number,
following the rule of 40*Eirst+Second 40*2 + 16 = 96 = 0x60;
• the third number of the Object Identifier (756) requires two octets: its hexadecimal value is 0x02F4,
which is 00000010 11110100, but following the above rule. the MSB of the second octet shall be set
to 0, thus you should shift this MSB into the first octet, and to set the MSB of the first octet to 1,
which gives binary 10000101 01110100. which is 0x8574;
each remaining numbers of the Object Identifier required to be encoded on one octet;
• this results in the encoding 60 85 74 05 08 01 01.
■ similarly, in the case of application context name SN referencing with no ciphering the BER encoding is
60 85 74 05 08 01 02;
• in the case of mechanism name low-level-security. the BER encoding is 60 85 74 05 08 02 01:
▪ in the case of mechanism name high-level-security (5), the BER encoding is 60 85 74 05 08 02 05.
11.5 Encoding of the AARQ APDU

Here, six different cases are shown:
■ LN referencing with no ciphering, no security, LLS and HLS:

• SN referencing with no ciphering. no security, LLS and HLS
The encoding is shown in Table 74.

DLMS User Association. COSEM Arthdeclure and Reloads, Seventh Edition
javascript;
iftop-1.0-0.pre3.e I....rpm El 2020-12-08 Datatxt ,••• SIADLcom_the.pr...zip ••••• s The Princess Di....torrent Shaw all X
E] * < 257 / 310 >
<1 R * ••■ A A T 37- r
Table 74 - DER enCeiSeg the AARQ APDU
-- WM encoding the AARQ APD0 LM referencing SM referencing
60 66C_ 1 LEA Rif no Res_ 1 LLB MA
/., encoding of the tag of the AARQ AMU [(APPLICATION 01, Application) 60 60
II encoding of the length of the AAPQ's content's field ID 10
34 3 36 36
-- protocol-version field ((Oh MKPETerf BIT EERIER I vers3onl (al 1
DEFAULT ( versioni ,
/.., no encoding, thus it is considered mrth its DAPAULr value
-- encodin g the fields of the Kernel

-- appilcaLlun-context-uame field flit. Application-context-cane,
OBJECT IDENTIFIER)
II encoding of the tag 1111, Context-specific) Al Al

li encoding of the length of the tagged component's value field 09 09
/1 encoding of the choice for application-context-name (0B.Tree 06 06
IDENTIFIER, Universal)
11 encoding of the Length of the Object 'dent et' n xn , ue field 07 07
/I encoding of the value of the Object Identifier 00 85 74 05 08 al 01 GC BS 74 05 08 01 0:
-- seep,'ing the fields of the autheoticatinn functional Ilnif
--ender-arse - requirements field Mel, AC5E-requirements. BIT SIRING

1 authentication ID) 1 I
/1 encoding of the tag of the acse-requirements field 6101, IMPLICIT,

BA BA BA 8A
Context-specific)
/.., encoding of the length of the tagged component's value field 02 02 02 02
II encoding of the number of unused bits in the last byte of the BET - 07 07 - 07 07
STMIMG
II encoding of the authentication functional unit (01

NOTE The number of bits coded may vary from client to client. but CD BD - BC
within the COSEM environment, only hit 0 net to 1 ;indicating the
requirement of the authentication functional unit) is to be respected.
... m echanism-name field .7(11), IMPZICf. .echanism-name ORJECT
IDENTIFIER)

e Copyright1997-2009 Dims liner Association
-- BEE omoding the AARQ AEDU LB referencing 06 referencing
1.• ■ 66. 114 ALM no men- 110 ILLS

/1 encoding of the tag ffil. IMPLICIT. Context - rPeCifc7 es 00 es Bs
..9 encoding of the length of the nagged component's value field 07 07 07 07
II encoding of the value of the O&M? IDINTINTSR: 00 05 74 60 05 74 60 05 74 60 85 -
• 100-level-30earlEy-Meenania.-nerve ill. - 05 OA 01 05 CB 02 05 09 02 05 OA i
- 01 OS 01 05
high-level-security-mech .. i se-none 151
-- railing-authentication-value field l(121, Authentication-.aloe

CMOME)
// &needing of the tag ffl21, xxot2020, cearer, - apecinc, AC AC AC AC
II , q... no of the length of the tagged component's value field OA OA - DA OA
II .., .ng of the choice for Authentication-v•1u• fel• . string (01 BO BO - 80 BC

iMpLacrr GraphlaStringl
/1 ,.: :4 the length of the AuthentlCatien-velve'a value field t8 OS 06 - Ii 4

OeteL , 1
/1 encoding the call I ng-aut Rent) ea L 10n -Ve lue : 31 32 33 48 35 36 31 32 33 4B 35 :

• In the case of LLB. the value of the P aaaaaa d - 12940678 - • 34 35 36 69 56 62 - 34 35 36 69 56 i
• in the use of 1113, the valu• of eh aaaaa g• Cto9 •75610.0. 3 1 38 67 59 37 39 67 59
-- encoding the um.. -information field component (Associeti on-

iorormetion, °MP 0705101
II 'kneading t h• tag 11301, Content -specific, Constructed) BI SE BE BE BE BE
II encoding of the length of the tagged component's value field 10 10 10 10 10 10
II encoding the choice for user-information fOCTST STROBE, Unlversoll 04 04 04 04 04 04

// encoding of the length Of the OCTET STRING'S value- field (24 octets) OE OE 00 OE OE
/1 user-informationt MANS InitlateBeguest 00017 91 00 00 00 OE SF IF 04 91 00 00 00 06 50 IF 04
00 00 7E IF 04 BO 00 IC 03 20 04 DO
DLMS User Association 12009-12.22 I DLMS UA 1000-2 Ed. 7.0 I 258/310

Copyright 1997-211:419 MAAS User ASSOOMMI
iftop-1.0-0.pre3.el....rpm 0 M 2020-12-08 Data.txt •••• •••• 2- The Princess Di....torrent " Shaw all X
* &.17 < 258 / 310 > .-",;(7::Q 61 « T TT./ IM o6 0
-- WA encoding she WO APIA] LM rmfmomocinq OM reforommi q

no SW. ELI no eon • LLS au
/1 encoding of the tag renr, IMPLICIT, Context-specific, IS II es as
II encoding of the length of tt- ' . .z.d componenr's value field 07 07 01 07
II encoding of the vain, of the PORJRC? fneivirfsit: so es re 60 IS 14 60 es 74 60 85 -

• taw-level-81,Curity-meChanLs - r., - , 119, 05 09 02 OS 98 02 05 09 02 05 08 f
high - level - necurity
01 05 01 05
, - nerhanine - nano 151
-- calling-auch.ntiration- ,afte field (fill, Authentication -valve
CROICS)
1/ encoding of the tag (1121. EMPLIelr, conteog-opoOif10 AC AC - AC AC
/,' encoding of the length of the togged compooent'S seise 01.414 OA OA - OA OA
dd encoding of the choice for Authentication-valve (chartering (01 - 80 BO - 80 BO

IMMO', atMOIC"'"1"
I! enCoding of the length of the AothenticatIOn-valuee valve field (4 -
08 OA - DB I
octets)
.,,, encoding the calling-Authentication-value; 31 32 33 48 30 36 31 32 3] 4B 35 :
• In the Cane of LLS, the value el the P ...... d '12345678' - 31 35 06 69 56 62 - 34 35 36 69 56 1
• Ln the use of HIS, the value of challenge CtoB .1(36iVae. 37 38 6 7 59 37 38 67 59
-- -.radio.; 1... , ,,-, ,,, •7,, ntlon field coopanene fAssociation-

lotarmdcioo, OCTET STRING
// encoding ch-. •..J !... ,, Context-specific, Constructed, BE BE BE BE BE BE
11 encoding of the length of the tagged con, '' s value field IO 10 IC 10 10 10
di encoding the choice for user-InforoatIon (OCTET smithz. Unf 1., 04 04 04 04 04 04

1/ encoding of the length of the OCTET ETRINO'S value field (14 octets) OB OE OE OE 00 t
11 veer-information: 800810 InitiaCeRegueat APOU 01 00 00 00 os 5r It 04 02 no 00 00 06 5r 1r 04
00 00 7E if 04 BO 00 is 03 20 04 BC
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 I 254/310 I

40 Copyright 1907-24309 I1U..45 User Asscciahon
Table 75 —The complete AARQ APDU
LN referencing with no ciphering, 60 ID Al 09 06 07 60 85 74 05 00 01 01 BE 10 04

lowest level security; OE 01 00 00 00 06 5F 1F 04 OG 00 7E 1F 04 BO
60 36 Al 09 06 07 60 85 74 05 08 01 01 BA 02 07
LN referencing with no ciphering, 80 BB 07 60 85 74 05 08 02 01 AC OA 80 08 31 32
low level security; 33 34 35 36 37 38 BF 10 04 OE 01 00 00 00 06 5F
1F 04 00 00 7E IF 04 BO
60 36 Al 09 06 07 60 85 74 05 08 01 01 SA 02 07
LN referencing with no ciphering, 80 88 07 60 85 74 05 08 02 05 AC OA 80 08 48 35
high level. security; 36 69 56 61 67 59 BE L0 04 OE 01 00 00 00 06 5F
1F 04 00 00 7E IF 04 BD
SN referencing with no ciphering, 60 1D Al 09 06 07 60 85 74 05 08 01 02 BE 10 04
lowest level security; OE 01 00 00 00 06 5F LF 04 00 10 03 20 04 BO
60 36 Al 09 06 07 60 85 74 05 08 01 02 BA 02 07
SN referencing with no ciphering, 80 8B 07 60 85 74 05 08 02 01 AC OA BO 08 31 32
low level security; 33 34 35 36 37 38 BE 10 04 OE 01 00 00 00 06 5F
IF 04 00 1C 03 20 04 60
60 36 Al 09 06 07 60 85 74 05 08 01 02 8A 02 07
SN referencing with no ciphering, 80 BB 07 60 85 74 05 08 02 05 AC OA 80 08 4B 35
high le ,. . 1 secur ity 36 69 56 61 67 59 BE 10 04 OE 01 00 00 00 06 5E
lE 04 00 IC 03 20 04 BO
11.6 Encoding of the AARE APDU

Here_ six different cases are shown:
• LN referencing with no ciphering. no security or LLS. successful establishment of the AA;

• LN referencing with no ciphering, no security or LLS, failure because the proposed application-
context-name does not fit the application context-name supported by the server (failure case 1):
-
• when the meter uses LN referencing. SN referencing is proposed;

• when the meter uses SN referencing. LN referencing is proposed;
• LN referencing with no ciphering, no security or LLS, failure because the proposed-dlms-version-
IM—____
" El 2020-12-08 Data.txt " SIAIDLcorn_the.pr....zip " 2- The Princess Ce....torrent " Show Al X
14 1: Q oe A I T T r d a7 i 0
Table 75 — The complete AARQ APDU
LN referencing with no ciphering, 60 10 Al 09 06 07 60 85 74 05 08 01 01 BE 10 04

lowest level security; OE 01 00 00 00 06 5F LF 04 00 00 7E LF 04 BO
60 36 Al 09 06 07 60 85 74 05 08 01 01 BA 02 07
IF 04 00 00 7E IF 04 BO
60 36 Al 09 06 07 60 85 74 05 08 01 01 BA 02 07
high level security; 36 69 56 61 67 59 BE 10 04 OE 01 00 00 00 06 5F
1F 04 00 00 7E 1F 04 BO
SN referencing with no ciphering, 60 10 Al 09 06 07 60 85 74 05 08 01 02 BE 10 04

lowest level security; OE 01 00 00 00 06 5F 1F 04 00 10 03 20 04 00
60 36 Al 09 06 07 60 85 74 05 08 01 02 88 02 07
SN referencing with no ciphering, 80 88 07 60 85 74 05 08 02 01 AC OA 80 08 31 32
IF 04 00 IC 03 20 04 BO
60 35 Al 09 06 07 60 85 74 05 08 01 02 8A 02 07
58 referencing with no ciphering, 80 BES 07 60 85 74 05 08 02 05 AC OA 80 08 48 35
high level security 36 69 56 61 67 59 BE 10 04 OE 01 00 00 00 06 5F
1F 04 00 lc 03 20 04 BO
11.6 Encoding of the AARE APDU

Here, six different cases are shown:
• LN referencing with no ciphering, no security or LLS, successful establishment of the AA;

▪ LN referencing with no ciphering, no security or LLS, failure because the proposed application-
context-name does not fit the application-context-name supported by the server (failure case 1):
• when the meter uses LN referencing, SN referencing is proposed;
• when the meter uses SN referencing, LN referencing is proposed;
• LN referencing with no ciphering, no security or LLS, failure because the proposed-dims-version-
number is too low; (failure case 2)
• LN referencing with no ciphering, HLS, successful establishment of the AA;
• SN referencing with no ciphering, no security or LLS, successful establishment of the AA;
• SN referencing with no ciphering, HLS, successful establishment of the AA;
The encoding is shown in Table 76.

TAN. 7R —RFD annrrilr. the. LAM Argil 1

javascript;
iftop-1.0-0.pre3.el....rpm 0, El 2020-12-08 Dataal n SLIBDLcom_the.pr....zip V The Princess Di....torrent ••••■ ShawMI X

T PEI .=-70 * < 260 / 310 > 4 CI R 4 4. *A T 1D * 0
DLMS User Rcsnciation, COSEM Architecture and Protocols, Seventh Edition
Table 76 — 9E9 encoding the AARE ARM)

-- BRA encoding the AARE ARCM LE referencing SA referencing
No mec./LIS No sec.iLLS Co nec./LLS ELLS No nec./LLS BLS

SOCeStS failure 1 failure 2 AUCCiliA ■ soon... sauce,.
il encoding of the tag for the AARE RPM liAPPLICAITON
61 61
II. Application,
fl encoding of the length of the AARE'S content's field 29 27 IF I 42 29 42
-- protocol-Veraida field ((01. ximmicrr BIT STRING .'

version; (01 1 =FAULT } version]
// no encoding. thus cc is considered with its DEVAULT

vial.
-- application-context-name field fill. Application -

context-name, 011JECT lommrszER?
1/ encoding of the Lag ((11, Coolest-specific) AI Al
// encoding of the length of the tagged component's

09 09
value field
// encoding the choice for application-context-name

06 DE
(OBJECT IDENTSIIIA, Universal)
If encoding of the length of the Object Identifier's

07 07
value field
If encoding of the value of the Object Identifier:

60 85 14 05
NOTE when the proposed application-context does not 08 01 01
fit the application-context supported by the server, 60 85 74 05 60 85 74 05 80 95 74 05 ED 85 79 05 60 85 74 0!
yr
the server may respond etch the application-context 00 01 01 OS 01 01 08 01 01 Cl Cl 02 08 01 02
name proposed or the application-context-name 60 85 74 05
supported. 08 01 02
-- result field 1121, Associarion-result, INTECEIL,
II encoding of the tag (121, Context - specifici A2 A2
Yi encoding of the length of the togged component's

03 03
value field
// encoding of the choice for the result fIRT16,2,

02 02
Universal?
/1 encoding of the length of the result's value field 01 01
II encoding of the value of the Result,

I/ success: 0, accepted 00 01 01 00 00 00
Ii failure case 1 and 2: 1, rejected-permanent
DLMS User Association 12009-12-22 I DLMS UA 1000 - 2 Ed. 7.0 1 2601310

Copynglutog7-2009 WAS User Asscaarbon
-- MA .,coding Oho WAS 8280 LW reforeacimq 01 reroceocLoo
Yo moc./LLi No men./LLB NO sec./LLB ELS No sec./LLB BLS

socce• ■ failure. 1 failure 2 INUCCOAS MUCCOS ■ AIICess ■
-- result-source-diagnostic field ((if, Annotidio -

source-diagnostit, CBOSCE1
// encoding of the tag ff71, Contest-specificf A3 A3

05 05
value field
// encoding of the tag for the acne - service-user CHOICE

Al Al
HP
// encoding of the Length of the cogged OOmpOOOOCZ

03 03
value field
t/ encoding Of the cholet for assoclate-souLCe-

dlagnost1cs (INTEGER, Unlversdli 02 02
0/ encoding of the length of the value fleld 01 01
// encoding of the value:
- 0VCC000, nO btOurlty end 443. 0, no dlagnoStIcS

provided;
- [allure I. 2, application-Conies[-nave not
00 02 01 OE 00 00
SuppOr[ed.,
• 'allure 2; I, no-reeson-liven.
• OUCCO57, 813 security (51. 14, authentication
required;
--Encoding the ilEids of ch. amiLEEESisoition A1E4E1015E1

snit
-- responder-arse-requireseses field (flij. ImPLITST,
005E - requirenencs. SIN SSEIES f authencicarion (OP 1 0
1/ encoding of the tag of the OCee . eeggic- eoCOL3 field

(241. INPLICIP, Coniesr-specific)
ac. - 81
/0 encoding of the length of the tagged component's

02 02
value field.
// encoding of the number of unused bits in the last

07 07
byte of the SIT STRING
// encoding of the authentication functional unit 100 Cl 80
-- • . . , e field ((91, IMPLICIT, Mechenlso - name

OS EL. ➢ENTIFTEA)
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 1 2610310

0 Copyright 1997-2909 DINS User &soca.
iftop-1.0-0.pre3.el....rpm El 2020-12-08 Dataal •••• suBDLcom_the.pr....zip ••• V The Princess a...torrent ^ Shaw all X
- EU ?7W * i&,S5 < 261 / 310 > CI :: CZ, R R «-+ A AT 7,'T 0 0 di a • -
-- BEN encoding the AARE APOU LE reforemciog SE referencing

No m.o./LLB No m.o./ILA 10 ■ oo./LLB BLS No ■ or./LLM BLS
moo... t tailor. 2 AnMeall M. G.. knee...
-- resuit-source - diagnostic field 1(3), Asnociute -

snarce-ellagnoRtAc r CHOICE)
I/ encoding of the tag ff3j, Context-speci fie). A1 13
// encoding of She length of the tagged component's

05 05
value field
// enCOdlng of She too for the scow - service-user CHOICE

Al Al
(1)
1/ encoding of the length or the togged cooponent's 03 07
velum field
!i encoding of the choice for associate-source-
02 02
diagnostics 'INTEGER, universal).
/1 encoding of the length of the value field el 01
// encoding of the value:
- success, no security and km. 0, no dtbO408[1cs
proulded$
- 'allure 1: 2, application-context-Dome not 00 02 01 00 00 OE
supported'
• Collura 2; 1, no-reason-given.
• success. BLS security t51 . 14. authentication
required;
-- Seceding the field. et the an ttttt Icarian 1 Si
matt
-- .,,,,,,d,,-,,,, • • : . • . field )(8l. IMPLICIT,
ACSE-regolremehr.. BIT STRING authentleatIon (R) • J
// encoding of Ito - A4 .-., - r, acse-reguirenents field

88 BB
118/. IMPLICIT, Content - specific)
1/ encoding of the length of the tagged component's
02 02
value field.
// encoding of the number of unused bits In the last -
03 07
byte of the BIT ETEINV
/I encoding of the authentication functional next 10) BO BO
mechanism-name field
-- (( 41 , IMPLICIT. Nechanssm-name
OBJECT IDENTIFIER;
DLMS User Association 12009-12-22 DLMS UA 1000-2 Ed. 7.0 I 261/310 1

Copyrthl 1997-2009 niMS User Assca.gbon
DLMS User Associalion, COSEM Architecture and Protocols, Seventh Edition
-- BEM encoding the AARE AFDC, Le referencing Se refereociog

NO s.c./LLE no . ►../ILS No ■ o.c./Ica BLS No ■ ec./LLE ULS
50CC•7111 failure 1 failure 2 0001:410• SLICGIS• 040055 ■
" ....dine Of the tag (191, IMPLICIT, Context- 89 89

specific)
// encoding of the length of the Lagged component's - CO 00
value field
// encoding the value of the object identifier. 60 05 74 05 60 85 74 O.
- high-level-security-mechanism-name 15) Cl 02 05 08 02 05
-- responding-authentication-value field ((101,

EXPLICIT, Authentication-value CM0FCE)
// encoding of the tag (1101. Context - specific) AA AA

- 0A DA
value field
// encoding of the choice for Authentication-value
80 BO
(Charsring. /01 EstrEmorr GraphicString)
/1 encoding of the length of the Authentication-

DB DE
inform at ion's v.01410 field (8 octets!
/1 encoding of the value of the challenge StoC 50 34 17 52 50 36 T, 52

... 1.6wRJ21F ... gm 02 31 46 4h 32 31 96
-- encoding the user-information field component

(Association-information. OCTET BTNINE)
// encoding the tag for the user-information field
component ([347), Canrert-specific, Comstrycred) BE BE BE CC BE BE

10 10 06 10 10 10
value field
// encoding of the choice for user-information fOCIEf
04 04 04 04 04 04
STRING, UnlVerSAI;
// encoding of the length of the OCTET STRING's value
OE OE D4 OE OE OE
field
1/ failure case 1: soLms-isitiatenesponse; 08 00 06 sr 00 00 os sr of ol os 01 as 00 06 SF co Si SF 06 06 00 06 51
IF na 00 00 IF 04 00 90 1F 04 00 00 IF 04 00 LC IF 04 00 It
// failure case 2: confirmedservicsetror 11141).
SO IF 01 F4 50 IF 01 F4 50 /F 01 F4 03 20 01 F4 03 20 01 F.
, n 1 tiatekrtC , Elf, Sersiceniror, initiate 16], dims-
version-too-low iii! 00 07 00 07 00 07 FA 00 FA 00
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 I 262raio I

rg) Copyright 1997-2009 DOAS User Association
ni MS t ispr Association. CCISFM Arc-hit/4/1n m anti Prntncnls. SAvianth Frii1inn

javascript;
iftop-1.0-0.pre3.el....rpm n 2020-12-08 Data.txt n SIADLconi_the.pr....zip The Princess Di...torrent es Shaw all X

*:;...7.17. 262 /310 > R ► v• A# T ••
-- SIR /mewling . Lb. AARE APOU LN referaneioq Si [Afar...1w
We a...ILLS No ....ILLS Ma sec. /LEA BLS Na ■ ec./LLS BLS

!dec.. failure 1. tailor. 2 Ana... succas ■ vac...
1/ encoding Of the tag (M. INFLICIT. Context- S9

89
specific)
/I encoding of the length of the tagged component's Cl 07
value field
/I encoding the value of the object identifier: 60 85 74 05 _ 60 85 74 0!
- high-level - security-mechanism-none (5) 08 02 05 08 02 05
-- responding-authentication-value field (110),

EXPLICIT, Authentication - value CHOICE)
/) encoding of the tag 11100. Content-specific) AA

1/ encoding of the length of the tagged component's - -
0A OA
value field
// encoding of the choice for Authentication - value 8D 80
(charstrine [U1 IMPLICIT Graphic5fringi
// encoding of the length of the Authentication-

08 08
information's liaise field es octets)
// encoding of the value of the challenge stet 56 36 77 52 50 36 77 52

... P6sR./21F"- 4A 32 31 if 50 32 31 40
-- encoding the user-information field component

(Assaciatior-informacion, OCTET ETRINU)
// encoding the tag for the uner-informarion field
BE BE BE BE BE BE
component ((30i, Context-specific, Constrocted)

10 (0 Of 10 10 10
value field
// encoding Of the choice ter user-information (OCTET

04 04 04 04 04 04
STRING, Universal)
// encoding of the length of the OCTET STRING's value
OE OE 04 OE OE OE
field
II failure case 1, x01445-InItiateResponse; OS 00 06 OF 00 00 06 OF OE 01 06 01 08 00 06 OF 08 00 06 5F 08 00 06 51
1/ failure case 2: ContIrmedServIceError ([14]). IF 04 00 00 IF 0 4 0 0 00 IF 04 00 00 IF 04 OD LC IF 04 00 n
InitiateError [1], CerviceErrof, initiate 461, dies- 50 IF 01 r4 50 IF 01 14 50 IF 01 F4 03 20 01 F4 03 20 01 F.
version-toe-low IL)) 00 07 00 07 OD 07 FA 00 FA 00
DUASUserAssodMion 12001-12-22 I DLMS UA 1000-2 Ed. 7.0 1 262/310

Copynghi 1997-2009 0(005 User AssopLabon
Table 77 — The complete AARE APDU
LN referencing with no ciphering, no 61 29 Al 09 06 07 60 85 74 05 08 01 01 A2 03 02

security or LLS, successful 01 00 A3 05 Al 03 02 01 00 BE 10 04 OE 08 00 06
establishment of the AA 5F IF 04 00 00 50 IF 01 F4 00 07
LN referencing with no ciphering, no 61 29 Al 09 06 07 60 85 74 05 08 01 OL A2 03 02

security or LLS, failure because the 01 DI A3 05 Al 03 02 01 02 BE 10 04 OE 08 00 06
proposed application-context-name does 5F 1F 04 00 00 50 IF 01 F4 00 07 or
not fit the application-context-name 61 29 Al 09 06 07 60 85 74 05 08 01 02 A2 03 02
supported by the server (failure case 01 01 A3 05 Al 03 02 01 02 BE 10 04 06 08 00 06
11: 5F IF 04 00 00 50 IF 01 F4 00 07
LN referencing with no ciphering, no 61 IF Al 09 06 07 60 85 74 05 08 01 01 A2 03 02
security or LLS, failure because the 01 DI A3 05 Al 03 02 01 01 BE 06 04 04 OE 01 06
pr opo sed - dints - versi on - number is too low; 01
( failure case 2)
61 42 Al 09 06 07 60 85 74 05 08 01 01 A2 03 02
01 00 A3 05 Al 03 02 01 DE 88 02 07 80 89 07 60
LN referencing with no ciphering, high 4A 32
85 74 05 08 02 05 AA OA 80 08 50 36 77 52
level security;
31 46 BE 10 04 OE 08 00 06 5F 1F 04 00 00 50 1F
01 F4 00 07
61 29 Al 09 05 07 60 85 74 05 08 01 02 A2 03 02
SN referencing with no ciphering, lowest
01 DO A3 05 AI 03 02 01 00 BE 10 04 OE 08 00 06
level security;
5F IF 04 00 10 03 20 01 F4 FA 00
61 42 Al 09 06 07 60 85 74 05 08 01 02 A2 03 02
01 DO A3 05 Al 03 02 01 OE 88 02 07 80 89 07 60
SN referencing with no ciphering, high
85 74 05 08 02 05 AA OA 80 08 50 36 77 52 4A 32
level security
31 46 BE 10 04 OE 08 00 06 5F 1F 04 00 1C 03 20
01 F4 FA 00
iftop-1.0-0.pre3.el....rpm es El 2020-12-CS Data txt 9 . SUBDLcom_the.pr ..zip 1.2 The Princess Di....torrent Shaw all X
E] * 263 /310 > 0 * 0
Table 77 — The complete AARE APDU
LN referencing with no ciphering, no 61 29 A] 09 06 07 60 85 74 05 08 01 01 A2 03 02

security or LLS, successful 01 00 A3 05 Al 03 02 01 00 BE 10 04 OE 08 00 06
establishment of the AA 5F IF 04 00 00 50 1F 01 F4 00 07
LN referencing with no ciphering, no 61 29 Al 09 06 07 60 85 74 05 08 01 01 A2 03 02

security or LLS, failure because the 01 D1 A3 05 Al 03 02 01 02 BE 10 04 of 08 00 06
proposed application-context-name does 5F it 04 00 00 50 IF 01 F4 00 07 or
not fit the application - context - name 61 29 Al 09 06 07 60 85 74 05 08 01 02 A2 03 02
supported by the server (failure case 01 01 A3 05 Al 03 02 01 02 BE 10 04 OE 08 00 06
1): SF IF 04 00 00 50 IF 01 F4 00 07
LN referencing with no ciphering, no 61 IF Al 09 06 07 60 85 74 05 08 01 01 A2 03 02
security or LLS, failure because the 01 01 A3 05 Al 03 02 01 01 BE 06 04 04 OE 01 06
proposed-dlms-version-number is too low; 01
(failure case 2)
61 42 Al 09 06 07 60 85 74 05 DB 01 01 A2 03 02
01 00 A3 05 Al 03 02 01 OE 88 02 07 80 89 07 60
LN referencing with no ciphering, high
85 74 05 08 02 05 AA OA 80 08 50 36 77 52 4A 32
Level security;
31 46 BE 10 04 OE 08 00 06 51 IF 04 00 00 50 1F
01 F4 00 07
61 29 Al 09 06 07 60 85 74 05 08 01 02 A2 03 02
SN referencing with no ciphering, lowest
01 DO A3 05 Al 03 02 01 00 BE 10 04 OE 08 00 06
level security;
5F IF 04 00 10 03 20 01 F4 FA DO
61 42 Al 09 06 07 60 85 74 05 06 01 02 A2 03 02
01 00 A3 05 Al 03 02 Cl DE 88 02 07 80 89 07 60
SN referencing with no ciphering, high
85 74 05 08 02 05 AA CA 80 08 50 36 77 52 4A 32
level security
31 46 BE 10 04 OE 08 OD 06 51 IF 04 00 IC 03 20
01 F4 FA 00

O Copyright 1997-2009 DLMS User Association
iftop-1.0-0.pre3.el....rpm El 2020-12-08 Dataal es 3 SUBDLcom_the.pr....zip V The Princess a...torrent es Shaw MI X

A T ÷
-- 0_0%
12. Encoding examples: AARQ and AARE APDUs

using a ciphered application context
NOTE The System Title is the same in each example. In the reality. the System Title in the request and in the respo
APDUs should be different. as they are originated by different systems.
12.1 A-XDR encoding of the xDLMS InitiateRequest APDU,

carrying a dedicated key
In this example:
• the value of the dedicated key is 00112233445566778899AABBCCDDEEFF;

• the value of the Conformance block is 007E1 F;
• the value of the client-max-receive-pdu-size is 1200 bytes (0x0480).
Table 78 — A-XDR encoding of the xDLMS InitiateRequest APDU
// encoding ci =he tag :f the ::MS APDU CHOICE (InitiateRequest•
-- encoding of the dedicated-key component (OCTET STRING OPTIONAL;
// usage flag (TRUE, present) 01

// length of the OCTET STRING 10
// contents of the OCTET STRING 0011223344556677
0899AABBCCODEEFF
-- encoding of the response - allowed component (BOOLEAN DEFAULT TRUE)
II usage flag (FALSE, default value TRUE conveyed) 00

-- encoding of the proposed-quality-of-service component ([U]
IMPLICIT Integer8 OPTIONAL)
// usage flag (FALSE, not present) 00
-- encoding of the proposed-dims-version - number component
(Unsigned8)
// value = 6; the A-XIIR encoding of an Unsigned8 is its value 06

-- encoding of the proposed - conformance component (Conformance,
(APPLICATION 311 IMPLICIT BIT STRING (SIZE(24)) -
/I encoding of the DAP= - N tag (ASN.1 explicit tag) - 5F1F
/1 encoding of the length of the 'contents' field in octet (4) 04
IIencoding of the number of unused bits in the final octet of the 00

BIT STRING (0)
I/ encoding of the fixed length BIT STRING value 007E1F

-- encoding of the client-max-receive-pdu-size component
(Unsigned16)
// value = Ox04B0, the encoding of an Unsignedl6 is its value 0450
-- resulting octet-string 0101100011223344

55 667 78899AABBCC
DDEEFF0000065F1F
0400007E1F0450
1 As specified in IEC 61334 - 6, Annex C, Examples 1 and 2, the proposed - conformance

element of the xDLMS InitiateRequest APDU and the negotiated-conformance element of the
xDLSM InitiateResponse APDU are encoded in BER. That's why the length of the bit-string
and the number of the unused bits are encoded _
2 For encoding of identifier octets, see ISO/IEC 8825 Ed.3.0:2002, Clause 8.1.2. For
compliance with existing implementations, encoding of the (Application 31] tag on one
byte (5F) instead of two bytes (5F 1F) is accepted when the 3-layer, connection-
oriented, HDLC-based profile is used.

3M.E*A-itOR, %-nTaidgMDS1
Armia ttmllx 3m=n -af,
" 2020-12-08 Dataal " suBDLcom_the.pr....zip •••• V The Princess a...torrent " Shaw all X
* i=j714' < 265 /310 >
12.2 Authenticated encryption of the xDLMS InitiateRequest

APDU
Table 79 - Authenticated encryption of the xDLMS InitiateRequest APDU
LEN(X) Ien(X)
X Contents
bytes bits
Security material
Security suite Gc14-AEs-128
4D4D4D000013ic614E
System Title Sys-T (here, the five last octets contain the 8 64
manufacturing number in hexa)
Sys-T11 FC
Initialization Vector IV 12 96
404 D4D000013C614E01234567
Block cipher key

EK 000102030405060708090A0B0C0D0E0F 16 128
(global)
Authentication Key AK DOD1D2D3D4D5D6D7D8D9DADBDCDDDEDF 16 128
Security applied Authenticated encryption
Security control byte SC-AE

SC
(with unicast key) 30 1 8
SH = SC-AE II FC
Security header SH 5 40
3001234567
Inputs I
xDLMS APDU to be 01011000112233445566778899AABBCC

APDU 31 188
protected DDEEFF0000065F1F0400007E1F04e0
01011000112233445566778899AAB8CC
Plaintext P 31 188
DDEEFF0000065F1F0400007E1F04130
SC I I AK
Associated data A 17 136
30000102030405060708D90ADB0000DE0F
Outputs
801302PF8A78741330414CE025842534
Ciphertext C 0280300477206066175305221LBE68
31 188
Authentication tag T 41DB204D39EE6FDB8E356855 12 96

TAG II LEN II SR Il C Il T
The complete 21303001239567801302FF8A874133b

114CED25134253402806004 -,720606Bl7 50 400
ciphered APDU
550522118E6841013204039EE6F0138E 35
6855
12.3 The AARQ APDU

In this example, the following values are used:
• Application-Context-Name: Logical_Name_Referencing_With_Ciphering;
• Calling-AP-Title (carries the System Ttitle): 4D4D4D0000BC614E;
• Mechanism-Name: COSEM_Low_Level_Security;
• Calling-Authentication-Value: 12345678
Table 80 - BER encoding of the AARQ APDU

El 2020-12-08 Databct " suBDLcom_the.pr....zip •••• V The Princess a...torrent ". Shaw MI X
* < 266 0, In: Ct A # T T T 1 111 44. £
// encoding of the tag of the AARQ APDU ((APPLICATION 0],

60
Application)
/1 encoding of the length of the AARQ's contents field (102

66
octets)
-- protocol-version field (101, IMPLICIT BIT STRING ( version 1
(0) ) DEFAULT ( version( I
,/,' no encoding, thus it is considered with its DEFAULT value
-- encoding of the fields of the Kernel

-- application-context-name field Urn Application-context-
name, OBJECT IDENTIFIER)
/1 encoding of the tag ([1], Context-specific) Al
1/ encoding of the length of the tagged component's value field 09

// encoding of the choice for application-context-name (OBJECT
06
// encoding of the Length of the Object Identifier's value

07
field
// encoding of the value of the Object Identifier 60857405080103
-- encoding of the calling-AP-title field
II encoding of the tag [6], Context-specific) AS
// encoding of the length of the tagged component's value field OA
Il encoding of the type ([4], Universal, Octetstring type) 04

II encoding of the Length of the calling-AP-title-field 08
// encoding of the value 4D4D4000008C614E
-- encoding of the fields of the authentication functional unit
-- sender-acre- requirements field ([10], AcsE-requirements, BIT
STRING { authentication (0) / )
II encoding of the tag of the acse-requirements field ([10],
8A
IMPLICIT, Context-specific)
// encoding of the length of the tagged component's value field 02

// encoding of the number of unused bits in the last byte of 07
the BIT STRING
II encoding of the authentication functional unit (0)
NOTE The number of bits coded may vary from client to client,
but within the COSEM environment, only bit ❑ set to 1 80
(indicating the requirement of the authentication functional
unit) is to be respected.
-- mechanism-name field MI], IMPLICIT Mechanism-name OBJECT
IDENTIFIER)
/I encoding of the tag [11], IMPLICIT, Context-specific) 8B
// encoding of the length of the tagged component's value field (:)
// encoding of the value of the DEJECT IDENTIFIER:
60857405080201
- low-level-security-mechanis e -narre,
-- calling-authentication-value field ([12), Authentication-
value CHOICE)
// encoding of the tag ([12], EXPLICIT, Context-specific) AC
11 encoding of the length of the tagged component's value field OA
/1 encoding of the choice for Authentication-value (charstring

80
10J IMPLICIT GraphicString)
// encoding of the length of the Authentication-value's value
❑8
field (8 octets)
// encoding the calling-authentication-value (123456781 3132333435363738
-- encoding the user-information field component (Association-
information, OCTET STRING)

iftop-1.0-0. pre3. El 2020-12-08 Dataal " SIJ BDLcom_the.pr....zip •••• V The Princess a...torrent es ShawMI X
ES3 e=767 * < 267 / 310 > ,C:13..4:::(1 RI! 4.4.AATTT, 6
// encoding of the tag ,301, Context-specific, Constructed) BE
Ii encoding of the length of the tagged component's value field 34
// encoding of the choice for user-information (OCTET STRING,

04
Universal)
1/ encoding of the length of the OCTET STRING's value field (32

32
octets)
-- ciphered xDLMS InitiateRequeSt APDU

2130300123456780
1302FF8A78741330
414CED25B42534D2
80E0047720606017
5BD52211BE6B41DB
204039EE6FD88E35
6855
12.4 A-XDR encoding of the xDLMS InitiateResponse APDU

In this example:
• the value of the Conformance block is 00701 F;

• the value of the server-max-receive-pdu-size is 1024 bytes (0x0400).
Table 81 — A XDR encoding of the xDLMS InitiateResponse APDU
-
// encoding of the tag of the DLMS APDU CHOICE OB

[InitiateResponse)
-- encoding of the negotiated-quality-of-service component (IC]

IMPLICIT Integer8 OPTIONAL)
// usage flag 41#142, not present) 00
--encoding of the negotiated-dims-version-number component
(Unsigned81
// value - 6, the A-XDR encoding of an Unsigned8 is its value 06

--encoding of the negotiated-conformance component
(Conformance, [APPLICATION 31J IMPLICIT BIT STRING (SIZE(241)
// encoding of the [APPLICATION 31] tag (ASH./ explicit tag) 5F1F
1/ encoding of the length of the 'contents' field in octet (4) 04

// encoding of the number of unused bits in the final Octet of 00
the BIT STRING [0)
// encoding of the fixed length BIT STRING value 00701F
--encoding of the server-max-receive-pda-s ze component

(Unsigned16)
// value = 0x0400, the encoding of an Unsigned16 is its value 0400
-- encoding of the VAR - Name component (ObjectName, Integer16)
1/ value=0x00 07; the encoding of a value constrained Integer 1 6 0007

is its value
-- resulting octet-string, to be inserted in the user- 0800065E1E040000

information field of the AARE APDU 7c1F04000001

" El 2020-12-CS Data txt SUBDLcom_the.pr ..zip •••• 1.2 The Princess 01....torrent Shaw MI X
* 4S5 < 268 / 310 > CZ CI R 4 .4 rir A 1 T ÷
- T ra 0
12.5 Authenticated encryption of the xDLMS InitiateResponsc

APDU
Table 82 — Authenticated encryption of the xDLMS IniliateResoonse APDU
LEN(X) len(X)
X Contents
bytes bits
Security material
Security suite GCM - AES - 128
4D4D4D00008C614E
System Title Sys-T (here, the five last octets contain the 8 64
manufacturing number in hexa)
Sys - T II FC
Initialization Vector IV
4D4D4D0000BC614E01234567 12 96
Block cipher key

EK 000102030405060708090A0BOCO00E0F 16 128
(global)
Authentication Key AK DOD1D2D3D4D50607D8D9DADEDCDDDEDF 16 128
Security applied Authenticated encryption
Security control byte SC -AE

SC
(with unicast key} 30 1 8
SH = SC-AE II FC
Security header SH
3001234567 5 40
Inputs
xDLMS APDU to be
APDU 0800065E1F0400007C1F04000007 14 112
protected
Piaintext P 0800065F1F0400007c1F04000007 14 112
SC II AK
Associated data A 17 136
30130D1e2D3o4D5D6D7D8D9DADBDCDDDEDF
Outputs
Ciphertext C 891214A0845E475714383F658C19 14 112
Authentication tag T 745CA235906525E4F3E1C893 12 96
TAG II LEN II SH II C II T
The complete 281F3001234567891214A0815E475714
33 264
Ciphered APDU 383F65BC19745CA235906525E4F3E1C8
93

er El 2020-12-08 Databct er sueoLcom_the.pr....zip V The Princess a...torrent ^ Shaw MI X

* < 269 NR A ... T T- T
12.6 The AARE APDU

Table 83 — BER encoding of the AARE APDU
-- HER encoding of the AARE APDU
II encoding of the tag for the AARE APDU ((APPLICATION I], 61

Application)
// encoding of the length of the AARE's content's field (72
48
octets)
-- protocol-version field ((01, IMPLICIT BIT STRING ( version]
(0) , DEFAULT ( versionl ,
II no encoding, thus it is considered with its DEFAULT value
-- encoding of the fields of the Kernel

-- application-context-name field ((II, Application-context-
name, OBJECT IDENTIFIER)
// encoding of the tag ([1], Context-specific) Al

/1 encoding of the choice for application-context-name (OBJECT
06
1/ encoding of the length of the Object Identifier's value field 07
// encoding of the value of the Object Identifier:
NOTE when the proposed application-context does not fit the
application-context supported by the server, the server may 60857405080103
respond with the application-context name proposed or the
application-context-name supported .
-- result field ((21, Association-result, INTEGERJ
1/ encoding of the tag ([2], Context-specific) A2

// encoding of the choice for the result (INTEGER, Universal) 02
// encoding of the length of the result's value field 01
// encoding of the value of the Result: 0, accepted CO
--result-source-diagnostic field ([31, Associate-source-
diagnostic, CHOICE)
..1,i encoding of the tag ([3], Context-specific) A3
// encoding of the tag for the acre-service-user CHOICE (1) Al
// encoding of the choice for associate-source-diagnostics
02
(INTEGER, Universal)
// encoding of the length of the value field 01
// encoding of the value (0, no diagnostics provided) 00
-- encoding of the responding-AP-title field
1/ encoding of the tag ([4], Context-specific) Al

// encoding of the length of the tagged component's value field OA
// encoding of the type ([4], Universal, Octetstring type) 04
II encoding of the length of the calling-AP-title-field 08

// encoding the value 4D4D4D0000BC614E

tiD Copyright 1997-2009 DLMS User Association
" 2020-12-08 Dataal " SLIBDLcom_the.pr....zip •••• V The Princess Di....torrent ••••■ Shaw MI X
13E11 C 7l8 * < 270 /310 > Q Cl Q R 4AATTT „.• d fI .
-- HER encoding of the AARE APRS]

-- encoding of the fields of the authentication functional unit
-- In this example the Authentication functional unit is not
-- present; it is not necessary in the case of LLS, but if it is
-- present it is also acceptable.
// encoding of the tag ([30], Context-specific, Constructed) BE
/1 encoding of the length of the tagged component's value field 23
/1 encoding of the choice for user-information (OCTET STRING,

04
Universal)
// encoding of the length of the OCTET STRING'S value field 21
-- ciphered xOLMS In/tiateResponse APDU 281F300123456789

1214A0845E475714
383F65BC19745CA2
35906525E4F3E1C8
93
12.7 The RLRQ APDU (carrying a ciphered xDLSM

InitiateRequest ADPU)
Table 84 BER encoding of the RLRQ APDU
-- HER encoding of the RLRQ APDU
/1 encoding of the tag of the RLRQ APOU [[APPLICATION 2], 62

Application)
// encoding of the length of the RLRQ's contents field 39
-- reason field
// encoding of the tag ([0], IMPLICIT] 80
/I encoding of the length of the tagged component's value field 01
II encoding of the value (0, normal) 00

// encoding of the tag ([30], Context-specific, Constructed) BE

04
Universal)
II encoding of the length of the OCTET STRING'S value field (14
32
octets)
// user-information: 24.OLMS InitiateRequest APDU 2130300123456780
1302FF8A7874133D
414CE02504253402
8000047720606017
5BD522 1 1BE6841DB
204039EE6FD88E35
6855

pre3. a El 2020-12-08 Dataal a 3 SIJ BDLcom_the.pr....zip a V The Princess Di...torrent a Shaw MI X

* ( 271 > A F T
12.8 The RLRE APDU (carrying a ciphered xDLSM

InitiateResponse ADPU)
Table 85 — BER ebcoding of the RLRE APDU
-- HER encoding of the RLRE EMI

// encoding of the tag of the RLRE APOU ['APPLICATION 3], 62
Application)
// encoding of the length of the RLRE's contents field 28
-- reason field
1/ encoding the tag 1[[0], IMPLICIT] 80
// encoding of the value 10, normal) 00
-- encoding the user-information field component (Association -
// encoding of the tag [130], Context-specific, Constructed) BE


04
Universal)
// encoding of the length of the OCTET STRING'S value field (14
21
octets)
/I user-information: xOLES InitiateResponse APDU 281E300123456289
1214A0845E475714
383E655C19745C52
35906525E4F3E1C8
93

8t Copyright 1997-2009 DLMS User Association

io,..r0t7IIMMEMMEMMEMMI
iftop-1.0-0.pre3.ei...rpm " El 2020-12-08 Dalatul " SUBDLcom_the.pr....zip •••• V The Princess Di...foment es Shaw ,II X
13E11 * < 272 / 310 > 0 * 0
13. S-FSK PLC encoding examples
13.1 CI-PDUs, ACSE APDUs and xDLMS APDUs carried by

MAC frames using the IEC 61334-4-32 LLC sublayer
In these examples, the following communication sequence is shown, when the DLMS/COSEM
S-FSK PLC profile is used with the IEC 61334-4-32 LLC sublayer:
• the initiator Discovers, then Registers a new server system;

• the initiator establishes an AA;
• it reads the time attribute of the Clock object (once and 13 times, to show block transfer);
• the initiator Pings a server;
• the initiator sends a RepeaterCall service.
In these examples: SYSTEM-TITLE-SIZE = 6.
The traces have been taken from a protocol analyser. The contents of the MAC frame
explained. The MAC frame is shown between the brackets 0 following the "02 xx 50" header z
followed by 00 00 (final field, normally a frame check). The Pad fields are not shown.
Server in the NEW state with one alarm (Meter New): MAC frame carrying a
Discover CI-PDU
17:15:35:645 ===> Discover.Request(MAC:COO/FEE Ic:7 Dc:0 LLC:0/1) (Prob:100

NbTslot:10 CreditReponse:0 ICequalCredit:0)
Hex: 02 11 50 ( FC CO OF FF 11 90 00 01 10 64 00 OA 00 00 00 00
Explanation:
FC // Credit fields: 1111 1100 IC = 7, CC = 7, DC = 0

CO OF FE // MAC addresses: SA = COO (Initiator), DA = FFF (All-
Physical)
11 // Pad length
90 // Control byte 1001 0000, DL-Data.request
00 01 // L-SAPs: DA - 00 (CIASE server), SA SAP - 01 (CIASE client)
1D // DiscoverRequest PDU
64 // response-probability = 100
00 OA // allowed-time-slots - 10
00 // DiscoverReport-initial_credit - 00
00 // ICEqualCredit = 00
MAC frame carrying a DiscoverReport CI-PDU
17:15:40:441 <== Alarm.Report(MAC:FFE/FFE Ic:O Dc:0 LLC:FD/0) SN: 040890000(

Hex: 02 15 50 ( 00 FF EF FF OD 90 FD 00 1E 01 04 08 90 00 00 01 01 01 ) 00 00
-- Explanation:
00 II Credit fields
FF EF FE // MAC addresses: SA = FFE (NEW), DA address FFF
OD // Pad length
90 // DL-Data.request
FD 00 // L-SAPS: DA = FD, SA = 00
lE // DiscoverReport CI-PDU
01 // SEQUENCE OF 1
04 08 90 00 00 01 // System-Title
01 // Alarm-Descriptor presence flag
01 // Alarm-Descriptor

iftop-1.0-0.pre3.el....rpm 0, El 2020-12-03 Dataal " 3 SUBDLcom_the.pr....zip •••• V The Princess Di....torrent Shaw MI X
CM ?Jw * < 2r *AATT -rj 0D06 A 0
Register service: MAC frame carrying a Register CI-PDU
17:15:41:129 ===> Register(MAC:COO/FFF Ic:7 Dc:0 LLC:O/1) (AddrMAC: 0x3 SN:

040890000001 )
Hex: 02 1B 50 ( FC CO OF FF 07 90 00 01 1C 04 08 99 00 00 01 01 04 08 90 00 00
01 CO 03 ) 00 00
- - Explanation:
FC // Credit fields: 1111 1100 IC = 7, CC = 7, DC = 0

CO OF FE // MAC addressees: SA = COO, DA = FFF
07 // Pad length
00 Cl /1 L-SAPS: DA = 00, SA = 01
1C // RegisterRequest CI-PDU
04 08 99 00 00 01 /1 active-initiator-system-title
01 // SEQUENCE OF 1
04 08 90 00 00 01 // new-system-title
00 03 // mac-address 0x03
Server in registered state with an alarm: MAC frame carrying a DiscoverRequest

CI-PDU
17:17:02:973 ===> Discover.Request(MAC:COO/FFF Ic:7 Dc:0 LLC:0/1) (Prob:100

NbTslot:10 CreditReponse:0 ICequalCredit:0)
Hex: 02 11 50 ( FC CO OF FF 11 90 00 01 1D 64 00 OA 00 00 ) 00 00
- - Explanation:
FC // Credit fields: 1111 1100 IC = 7, CC - 7, DC = 0

CO OF FF // MAC addresses: SA = COO, DA = FFF
11 II Pad length
00 01 // L-SAPS: DA = 00, SA = 01
1D // DiscoverRequest C1-PDU
64 II response-probability = 100
00 OA // allowed-time-slots 10
00 // DiscoverReport-Initial-Credit 00
00 // ICEqualCredit 0
Response: MAC frame carrying a DiscoverResponse CI-PDU
17:17:07:316 <== Alarm.Report(MAC:003/FFF Ic:0 Dc:0 LLC:FD/0) SN:

040890000001
Hex: 02 15 50 ( 00 00 3F FF OD 90 FD 00 lE 01 04 08 90 00 00 01 01 82 ) 00 00
-- Explanation:
00 // Credit fields
00 3F FF // MAC addresses: SA = 003, DA = FFF
OD // Pad length
FD CO /1 L-SAPs: DA = FD, SA = 00
lE // DiscoverReport CI-PDU
01 // SEQUENCE OF 1
04 08 90 00 00 OI // System-Title
01 // alarm-descriptor presence flag
82 // alarm-descriptor


Ova..iPt; 1 1 -
iftop-1.0-0.pre3.el....rpm " 2020-12-08 Dataal " suBDLcorri_the.pr....np V The Princess a...torrent es Shaw MI X
* < 274 > Q .4.4 N A T T
Open association on the Logical device LsapDest=0x01 and Client R/W

LsapSrc=0x02: MAC frame carrying an AARQ APDU
17:28:52:691 ===> AARQ.Request(MAC:C00/003 Ic:4 Dc:0 LLC:1/2)

Hex: 02 43 50 ( 90 CO 00 03 03 90 01 02 60 36 Al 09 06 07 60 85 74 05 08 01 0
8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC OA 80 08 31 32 33 34 35 36 37 38 BE
04 OE 01 00 00 00 06 5F 1F 04 00 1C IA 20 00 EF ) 00 00
--Explanation:
90 // Credit fields
CO 00 03 // MAC addresses: SA = COO, DA = 003
03 // Pad length
01 02 // L-SAPs: DA - 0x01, SA - 0x02
60 36 // AARQ APDU
Al 09 06 07 60 85 74 05 08 01 02 // application-context-name
8A 02 07 80 // acse-requirements
8B 07 60 85 74 05 08 02 01 1/ mechanism-name
AC OA 80 08 31 32 33 34 35 36 37 38 /1 calling-authentication-
value
BE 10 04 OE 01 00 00 00 06 5F IF 04 00 1C 1A 20 00 EF
// user-information xDLMS InititateRequest
Response: MAAC frame carrying an AARE APDU
17:28:54:191 <=== AARE.Response(MAC:003/C00 Ic:4 Dc:0 LLC:2/1)

Hex: 02 37 50 ( 90 00 3C 00 OF 90 02 01 61 29 Al 09 06 07 60 85 74 05 08 01 02
A2 03 02 01 00 A3 05 Al 03 02 01 00 BE 10 04 OE 08 00 06 5F 1F 04 00 1C lA 20
EF FA 00 00 ) 00 00
- - Explanation:
90 // Credit fields
00 3C 00 // MAC addresses: SA = 003, DA = COO
OF // Pad length
02 01 L-SAPs: DA = 0x02, SA = OxOl
61 29 // AARE APDU
A2 03 02 01 00 // result
A3 05 Al 03 02 01 00 // result-source-diagnostic
BE 10 04 OE 08 00 06 5F 1F 04 00 1C lA 20 00 EF FA 00 00
// user-information xDLMS-InititateResponse
Read date and time current (1 short name)
17:35:16:082 ===> Read.Request[1](7304) (MAC:C00/003 Ic:3 Dc:O LLC:l/2)

Hex: 02 10 50 ( 6C CO 00 03 12 90 01 02 05 01 02 1C 88 ) 00 00
- - Explanation:
6C // Credit fields
CO 00 03 // MAC addresses
12 // Pad length
01 02 // L-SAPs
05 01 // ReadRequest
02 1C 88 // Variable-Name 1C88
17:35:16:832 <== Read.Response[1] (MAC:003/C00 Ic:3 Dc:O LLC:2/1) ObjACMM:

OxIC88 (7304) 112009/06/22 FF 17:35:15:FF 8000 FF1

C. Copyright 1997-2009 DLMS User Association

javasuiptj .
iftop-1.0-0.pre3.el....rpm " 2020-12-C8 Dan txt SUBDLcomthe.pr " .2 The Princess 01....torrent Shaw all X
MI .,=10 * < 275 > 0, .4:, A F T T T ta 0 W. rk 0
Hex: 02 1C 50 ( 6C 00 3C 00 06 90 02 01 OC 01 00 09 OC 07 D9 06 16 FF 11 23 OF
FF 80 00 FF ) CO 00
- - Explanation:
6C // Credit fields
00 3C 00 // MAC addresses
06 // Pad length
02 01 // L-SAPs
OC 01 // ReadResponse
00 // Success
09 OC 07 D9 06 16 FF 11 23 OF FF 80 00 FF // value of the attribute
Read date and time current (13 short name, to provoke block transfer):
17:36:38:406 ===> Read.Request[131(7304) (MAC:C00/003 Ic:0 Dc:0 LLC:1/2)

ObjACMM: Ox1C88 (7304) 1 Ox1C88 (7304) 1 Ox1C88 (7304) 1 Ox1C88 (7304) I Ox1C88
(7304) 1 0x1C88 (7304) 1 Ox1C88 (7304) 1 Ox1C88 (7304) 1 Ox1C88 (7304) 1 Ox1C88
(7304) 1 0x1C88 (7304) 1 Ox1C88 (7304) I 0x1C88 (7304) I
Hex: 02 34 50 ( 00 CO 00 03 12 90 01 02 05 OD 02 1C 88 02 1C 88 02 1C 88 02 1C
88 02 1C 88 02 1C 88 02 IC 88 02 1C 88 02 le 88 02 1C 88 02 1C 88 02 1C 88 02 1C
88 ) 00 00
--Explanation:
00 // Credit fields
CO CO 03 // MAC addresses
12 // Pad length
90 /1 DL-Data.request
01 02 // L-SAPs
05 CD // Read 13 Variable-Access-Specification
02 1C 88 // variable-name 1C 88
02 1C 88 02 1C 88 02 1C 88 02 1C 88 02 1C 88 02 1C 88
02 1C 88 02 le 88 02 1C 88 02 IC 88 02 1C 88 02 1C 88
17:36:39:609 <== Read.Response DataBlock_DLMS(MAC:003/C00 Ic:0 Dc:0 LLC:2/1)

LastBlock:0 Plock:1
Hex: 02 91 50 ( 00 00 3C 00 21 90 02 01 DC 01 02 00 00 01 81 7E OD 00 09 OC 07
D9 06 16 FF 11 24 25 FF 80 00 FF 00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF 00
09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF 00 09 OC 07 D9 06 16 FF 11 24 25 FF 80
00 FF 00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF 00 09 OC 07 D9 06 16 FF 11 29
25 FF 80 00 FF 00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF 00 09 OC 07 D9 06 16
FF 11 24 25 FF 80 00 FF 00 09 OC 07 D9 ) 00 00
--Explanation:
00 // Credit fields
21 // Pad length
02 01 // L-SAPs
OC 01 02 // ReadResponse data-block-result
00 // last-block = FALSE
00 01 // block-number 00 01
81 7E //raw-data octet-string of 126 bytes
OD // 13 results
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
// first result success, attribute value
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
// second result success, attribute value
00 09 OC 07 D9 06 16 FF 11 24 25 FE 80 00 FF

- -FRibgE,B3ZM TWATILIS
rarz*, Auggz tt.at31, szvv -ifu,
iftop-1.0-D.pre3.el....rpm es El 2020-12-CS Data txt SUBDLcom_the.pr ..zip " The Princess Oi....torrent Shaw MI X
CM a * 27E N R A .ATTT; 0_04 Ake -
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 // end of the first block
17:36:40:047 ===> ReadNextBlock.Request[1] (MAC:C00/003 Ic:0 Dc:0 LLC:1/2)

Block:1
Hex: 02 10 50 ( 00 CO 00 03 12 90 01 02 05 01 05 00 01 ) 00 00
00 // Credit fields
12 // pad length
90 II DL-Data.request
01 02 // L-SAPs
05 01 05 // ReadRequest, variable-access-specification, block-number-
/1 access
00 01 // block-number 00 01
17:36:40:797 <== Read.Response DataBlock_DLMS(MAC:003/C00 Ic:0 Dc:0 LLC:2/1)

LastBlock:1 Block:2
Hex: 02 58 50 ( 00 00 3C 00 12 90 02 01 OC 01 02 01 00 02 46 06 16 FF 11 24 2
FF 80 00 FF 00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF 00 09 OC 07 D9 06 16
11 24 25 FF 80 DO FF 00 09 DC 07 D9 06 16 FF 11 24 25 FF 80 00 FF 00 09 OC 07
06 16 FE 11 24 25 FE 80 00 FF ) 00 00
-- Explanation:
00 // Credit fields
12 II Pad length
02 01 // L-SAPs
OC 01 02 // ReadResponse data-block-result
01 // last-block = TRUE
00 02 // block-number = 00 02
46 // octet-string of 70 bytes
06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FE 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
00 09 OC 07 D9 06 16 FF 11 24 25 FF 80 00 FF
Ping service: MAC frame carrying a PirigRequest CI-PDU
17:38:43;633 ==.> Pinq.Request(MAC:C00/003 Ic:0 Dc:0 LLC:0/1 ISN: 04 08 90 00

01)
Hex: 02 12 50 ( 00 CO 00 03 10 90 00 01 19 04 08 90 00 00 01 ) 00 00
-- Explanation:
00 // Credit fields
10 // Pad length
90 //DL-Data-request
00 01 // L-SAPs
19 II PingRequest CI-PDU
04 08 90 00 00 01 // System-Title


javasuiptj .
iftop-1.0-0.pre3.el....rpm es El 2020-12-CS Dan txt SUBDLcom_the.pr " .2 The Princess 01....torrent Shaw all X
=EJ < 277 /310 1"4::: (1 Hi, 42- .AAT 0 A0
Response: MAC frame carrying a PingResponse CI-PDU
17:38:44:383 <=== Ping.Response(MAC:0O3/C00 Ic:0 Dc:0 LLC:1/0 ISN: 04 08 90 00

00 01)
Hex: 02 12 50 ( 00 ❑ 0 3C 00 10 90 01 00 lA 04 08 90 00 00 01 ) 00 00
Explanation:
00 // Credit fields
10 // Pad length
90 // DL-Data.reguest
01 00 // L-SAPs
lA // PingResponse CI-PDU
04 08 90 00 00 01 // System-Title
RepeaterCall service
17:38:54:727 ===> RepeaterCall(MAC:C00/FFF Ic:7 Dc:0 LLC:0/1) Max_Adr_MAC:

0x63 Nb_Tslot_For_NEW: 0
Hex: 02 10 50 ( FC CO OF FF 12 90 00 01 1F 00 63 00 00 ) 00 00
Explanation:
FC // Credit fields
CO OF FE // MAC addresses: SA = COO, DA = FFF
12 // Pad length
00 01 // L-SAPs: DA = 00, SA = 01
1F // RepeaterCall CI-PDU
00 63 // MaxAdrMac 0x63
00 // Nb_Tslot_For_New = ❑
GO // Reception-Threshold default value
13.2 CI-PDUs, ACSE APDUs and xDLMS APDUs carried by

MAC frames using the HDLC based LLC sublayer
In these examples, the following communication sequence is shown. when the DLMS/COSEM
S-FSK PLC profile is used with the HDLC based LLG sublayer:
• the initiator Discovers, then Registers a new server system:

• it connects the HDLC based LLC sublayer and establishes an AA;
■ it reads the time attribute of the Clock object;
• it releases the AA by disconnecting the HDLC based LLC sublayer.
In these examples: SYSTEM-TITLE-SIZE = 8.
-- The following trace is a spy frame of a chip implementing IEC 61334-5-1.
2009-05-14 16:04:53.922686 IEC61334-5-1-SPY [SPY-SUBFRAME] LEN=55

SO/N0=7928/164 S1/NI=4654/374 THR=27 MET=4 SYN=0 RGAIN=2 P_SW_LEN=38
-- Spy frame carrying a Phy frame. The Spy frame is not part of this companion
specification.
0000 02 35 BO F8 1E A4 00 2E 12 76 01 1B 00 04 02 00
0010 00 6C 6C 00 CO IF FF 05 7E A0 13 CE FF CD 13 61
0020 D5 E6 E6 00 1D 64 00 14 00 00 2C 66 7E 00 00 00
0030 00 00 32 9B EA 6E 10
DLMS User Association 2009 12 22 DLMS UA 1000 - 2 Ed. 7.0 0 277/310

iftop-1.0-0.pre3.el....rpm El 2020-12-08 Dataal es 3 suBDLcom_the.pr....zip V The Princess Di....torrent Shaw MI X

?JO * < 278 / 310 > CI Q R *A 1 T±"Tir ra -0 * 0
- - Explanation:
02 II STX
35 // length
BO /1 Spy subframe
F8 IE A4 00 2E 12 76 01 1H 00 04 02 // Spy data
-- here follows the 38 bytes Phy frame, carrying the MAC frame
00 00 6C 6C 00 CO 1F FF 05 7E AO 13 CE FF CD 13
61 D5 E6 E6 00 ID 64 00 14 00 00 2C 66 7E 00 00
00 00 00 32 9B EA
-- end of Phy frame
6E 10 // spy frame check field
Discover service: MAC frame carrying a Discover CI-PDU
- - For the MAC frame format, see IEC 61334-4-32 Clause 4.2.2
0000 6C 6C 00 CO IF FF 05 7E AO 13 CE FF CD 13 61 D5
0010 E6 E6 00 10 64 00 14 00 00 2C 66 7E 00 00 00 00
0020 00 32 9B EA
- - Explanation:
6C 6C // NS field, number of MAC subframes is I

00 // Credit fields, IC = 0, CC = 0, DC = 0
CO 1F FF // MAC addreses: SA = C01, Initiator, DA = FFF
// All-Physical
05 // Pad length
7E // HDLC frame flag
AO 13 /1 Frame type and length
CE FF CD // MAC addresses: DA = 0x677F, upper HDLC address 0x67, lower HDLC
address = All-station, SA = 0x66
13 // UI frame
61 D5 // HDLC HCS
E6 E6 00 // DLMS/COSEM LLC addresses
10 // Discover CI-PDU
64 // response-probability = 100
00 14 // allowed-time-slots = 20
00 // DiscoverReport-initial-credit = 0
00 // ICEqualCredit
2C 66 // HDLC FCS
00 00 00 00 00 // padding
32 9B EA II MAC FCS
- - From here on, only the MAC frames are shown and explained
Response: MAC frame carrying a DiscoverReport CI-PDU
0000 6C 6C 00 FF EC 01 00 7E AO 18 CD CE 23 13 BB 18
0010 E6 E7 00 1E 01 49 53 4B 05 00 00 00 01 00 83 01
0020 7E 38 CD OF
-- Explanation:
6C 6C // NS field, number of MAC subframes is 1

FF EC 01 // MAC addresses: SA = FFE (NEW), DA = C01, Initiator
00 II Pad length
AO 18 // Frame type and length

" El 2020-12-CS Data txt SUBDLcom_the.pr ..zrp " The Pnricess 01....torrent ShawMI X
ITU ?J'W * < 279 / > A F T7+- 0_0 Ei
CD CE 23 // DA = Ox66, SA = 0x6711, Ox11 is the lower HDLC address of

the system sending the DiscoverReport
13 // UI frame
BB 18 HDLC HCS
- DiscoverReport CI-PDU
1E // DiscoverReport CI-PDU tag 130]
01 // Sequence of 1
49 53 4B 05 00 00 00 01 // system-title-server
00 // Presence flag of the alarm-descriptor, not present
B3 01 // HDLC FCS
38 CD OF // MAC FCS
Register service: MAC frame carrying a Register CI-PDU
0000 3A 3A 00 CO IF FF IB 7E A0 21 CE FF CD 13 38 17
0010 E6 E6 00 IC FE FE FE FE FE FE FE FE 01 49 53 4B
0020 05 00 00 00 01 00 10 0C E6 7E 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 54 F2 23
-- Explanation:
3A 3A // NS field, number of MAC subframes is 2

CO 1F FE // MAC addresses: SA = C01, Initiator, DA = FFF, All-Physical
1B // Pad length, 27 bytes
CE FF CD II DA = Ox677F, upper HDLC address All-station, SA = 66
13 // UI frame
38 17 // HDLC HCS
1C // Register CI-PDU tag
FE FE FE FE FE FE FE FE // active-initiator-system-title
01 // sequence of 1
49 53 4B 05 00 00 00 01 // system-title-server
00 10 // MAC-address
OC E6 // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 // padding
54 F2 23 // MAC FCS
Establishment of a data link layer connection: MAC frame carrying an SNRM HDLC
frame
0000 6C 6C 00 CO 10 10 10 7E AO 08 02 23 C9 93 E4 43
0010 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 3F 96 Fl
-- Explanation:
6C 6C II NS field, number of MAC subframes is 1

00 // Credit fields, IC - 0, CC - 0, DC - 0
CO 10 10 // MAC addresses: SA = C01, Initiator, DA = 010, Individual
10 II Pad length
02 23 C9 // DA = Ox0111, SA = 0x64
93 //SNRM frame

DL MS User Association, COSEM Architecture and Protocols, Seventh Edition
iftop-1.0-0.pre3.el....rpm es El 2020-12-08 Dataal es 3 SUBDLcom_the.pr....zip V The Princess Di....torrent Shaw MI X

TS .=-J * _T.T7 C 200 • 0, 1: Ct A,T TT; Ea PI 1 ei
E4 43 // HDLC FCS
7E // // HDLC frame flag
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /7 padding
3F 96 Fl // MAC FCS
Response: MAC frame carrying a HDLC UA frame
0000 3A 3A 00 01 OC 01 1D 7E AO 1F C9 02 23 73 134 96
0010 81 80 12 05 01 7E 06 01 7E 07 04 00 00 00 01 08
0020 04 00 00 00 01 5F 75 7E 00 00 00 00 00 00 OD 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 72 3D 01
-- Explanation:

01 OC 01 // MAC addresses: SA - 010, Individual, DA - C01, Initiator
1D // pad length
AO 1F // Frame type and length
C9 02 23 // SA = 0x64, DA = Ox0111
73 // UA frame
B4 96 // HDLC HCS
81 80 12 05 01 7E 06 01 7E 07 04 00 00 00 01 08
04 00 00 00 01 // information field
5F 75 // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 // padding
72 3D 01 //MAC FCS
Establishment of an AA: MAC frame carrying an AARQ APDU
0000 56 56 00 CO 10 10 1B 7E A0 45 02 23 C9 10 21 48
0010 E6 E6 00 60 36 Al 09 06 07 60 85 74 05 08 01 01
0020 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC OA 80
0030 08 31 32 33 34 35 36 37 38 BE 10 04 OE 01 OD DO
0040 00 06 5F 1F 04 00 00 7E 1F FF FF 83 D7 7E 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 9B FF 67
-- Explanation:
56 56 // NS field, number of MAC subframes is 3

CO 10 10 // MAC addresses SA = C01, Initiator, DA = 010, Individual
18 // Pad length
02 23 C9 // DA = Ox0111, SA = 0x64
10 // I frame
21 48 // HDLC HCS
E6 E6 00 // LLC addresses
60 36 // AARQ APDU
Al 09 06 07 60
85 74 05 08 01 01 // application-context-name
8A 02 07 80 //
acse-requirements
813 07 60 05 08 02 01 // mechanism-name
85 74
AC 0A 80 08 31
32 33 34 35 36 37 38 // calling-authentication-
value
BE 10 04 OE 01 00 00 00 06 5F IF 04 00 00 7E 1F FF FF
// user-information xDLMS-Inititate.request

C) Copyright 1997-2009 DLMS User Association
iftop-1.0-D.pre3.el....rpm es El 2020-12-CS Data txt SUBDLcom_the.pr " The Princess Oi....torrent Shaw MI X
Q A T -+- 7 1 CI 0 wi a 0 '
83 D7 // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
9B FF 67
Response: MAC frame carrying an AARE APDU
0000 3A 3A 00 01 OC 01 03 7E AO 39 C9 02 23 30 22 BD
0010 E6 E7 CO 61 2A Al 09 06 07 60 85 74 05 08 01 01
0020 A2 03 02 01 00 A3 05 Al 03 02 01 00 BE 11 04 OF
0030 08 01 00 06 5F 1E 04 00 00 7C 1F 04 00 00 07 19
0040 4A 7E 00 00 00 10 E9 9A
-- Explanation:
3A 3A
// NS field, number of MAC subframes is 2
00 //
Credit fields, IC - 0, CC - 0, DC - 0
01 01 II MAC addresses: SA = 010 Individual, DA = 010, Initiator
DC
03 II
pad length
7E //
HDLC frame flag
A0 39 // Frame type and length
C9 02 23 // SA = 0x64, DA = Ox0111
30 // HDLC I frame
22 BD // HDLC [-ICS
61 2A // AARE APDU
A2 03 02 01 00 // result
A3 05 Al 03 02 01 00 // result-source-diagnostic
BE 11 04 OF 08 01 00 06 5F IF 04 00 00 7C 1F 04 00 00 07
// user-information xDLMS-Inititate.response
19 4A // HDLC FCS
00 00 00 // pad
10 E9 9A // MAC FCS
Get-request-normal APDU
0000 3A 3A DO CO 10 10 22 7E AO lA 02 23 C9 32 AF 55
0010 E6 E6 00 CO 01 40 00 08 00 00 01 00 00 FF 02 00
0020 EA DD 7E 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 C2 2B 4A
-- Explanation:
3A 3A// NS field, number of MAC subframes is 2

00 //Credit fields, IC - 0, CC - 0, DC = 0
CO 1010 // MAC addresses: SA = C01, Initiator, DA = 010, Individual
22 //pad length
AO lA // Frame type and length
02 23 C9 // DA = Ox0111, SA = 0x64
32 // HDLC I frame
AF 55 // HDLC HCS
CO 01 40 00 08 00 00 01 00 00 FF 02 00 // Get-request-normal APDU
EA DO // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 as 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

f Copyright 1997-2009 DLMS User Association

javw..ipt711
iftop-1.0-0.pre3.el....rpm es El 2020-12-CS Data txt SUBDLcom_the.pr ..zip " .2 The Princess Oi....torrent Shaw MI X
PEI .=-7D < 2a2 • 0, !V; 1: R A # T T d Ea ik 0 -
00 00 // PAD
C2 2B 4A // MAC FCS
Get-response-normal APDU
0000 3A 3A 00 01 OC 01 1D 7E AO 1F C9 02 23 52 3F A6
0010 E6 E7 00 C4 01 40 00 09 OC 07 D2 01 07 01 01 23
0020 lA 00 FF C4 00 80 EC 7E 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DD 00
0040 00 00 00 00 00 Cl 62 A6
-- Explanation:

00 // Credit fields, IC = 0, CC - 0, DC = 0
01 OC 01 // MAC addresses: SA = 010 Individual, DA 010, Initiator
1D / Pad length
C9 02 23 // SA = 0x64, DA = Ox0111
52 // HDLC I frame
3F A6 // HDLC HCS
Get-response-normal APDU
C4 01 40 00 09 OC 07 D2 01 07 01 01 23 lA 00 FF C4 00
80 EC // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
Cl 62 A6 II MAC FCS
Releasing the AA: MAC frame carrying a HDLC DISC frame
0000 6C 6C 00 CO 10 10 10 7E AO 08 02 23 C9 53 E8 85
0010 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 OD 00
0020 00 B9 A4 CD
6C 6C // NS field, number of MAC subframes is 1

CO 10 10 // MAC addresses: SA = C01, Initiator, DA 010, Individual
10 // pad length
02 23 C9 II DA = 0x0111, SA - 0x64
53 // HDLC DISC frame
E8 85 // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // pad
B9 A4 CD // MAC FCS
Response: MAC frame carrying a HDLC UA frame
0000 3A 3A 00 01 OC 01 1D 7E AO 1F C9 02 23 73 134 96
0010 81 80 12 05 01 7E 06 01 7E 07 04 00 00 00 01 08
0020 04 00 00 00 01 5F 75 7E 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 72 3D 01
00
01 OC 01 // MAC addresses: SA = 010 Individual, DA = 010, Initiator
1D II Pad length

C) Copyright 1997 - 2009 DLMS User Association
iftop-1.0-0.pre3.el....rpm El 2020-12-CS Data txt SUBDLcom_the.pr " .2 The Princess 01....torrent ShawMI X
- EU ?Jai *c_:,zr4 < 283 / 310 > =-Q 84::: (1 Hot 4...A AT -0 A 0

C9 02 23 // SA = 0x64, DA = Ox0111
73 // HDLC UA frame
B4 96 // HDLC HCS
// Information field
81 80 12 05 01 7E 06 01 7E 07 04 00 00 00 01 08 04 00 00 00 01
5F 75 // HDLC FCS
00 00 00 00 00 00 00 00 00 00 00 00 00 OD 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 // pad
72 30 01 // MAC FCS
13.3 Clear Alarm examples

In these examples, SYSTEM-TITLE-SIZE = 6.
Example 1: Clearing a single alarm in all servers
39 // tag for ClearAlarm, [57]

00 // Choice 0, Alarm-descriptor
00 // Alarm-Descriptor, fixed length unsigned integer
Example 2: Clearing a list of alarms in all servers
39 // tag for ClearAlarm, [57]

01 // CHOICE 1, alarm-descriptor-list, SEQUENCE OF Alarm-Descriptor
01 // Number of elements in the SEQUENCE OF
00 // Contents field: Alarm-Descriptor, fixed length unsigned integer
Example 3: Clearing a list of alarms in some servers
39 / tag for ClearAlarm, (57)

02 // CHOICE 2, SEQUENCE Alarm-Descriptor-List-And-Server-List
01 // server-id-list, number of elements in the SEQUENCE OF System-Title
040967000001 // System-title, fixed length octet-string
01 II alarm descriptor-list, number of elements in the SEQUENCE OF Alar,-
-
Descriptor
00 // Alarm-Descriptor, fixed length unsigned integer
Example 4: Clearing a different alarm in each different server
39 II tag for ClearAlarm, [57]

03 II CHOICE 3, alarm-descriptor-by-server-list
01 // SEQUENCE OF Alarm-Descriptor-By-Server
040967000001 // First element of the SEQUENCE: System-Title
00 // Second element of the SEQUENCE: Alarm-Descriptor

iftop-1.0-0.pre3.el....rpm es El 2020-12-08 Dataal es 3 suBDLcom_the.pr....zip V The Princess Di....torrent ShawMI X

6 .=-7E7 < 284 / 310 > nci «« A 1 T T 1 d -7 s 0
14. Data transfer service examples

The following tables show examples for data exchange using xDLMS services using LN referenc
(left column) and SN referencing (right column).
Table 86 — The objects used in the examples

Object 1:
- Class: Data
- Logical name: 0000800000FF
- Short name of value attribute: 0100
- Value: octet string of 50 elements
- 01020304050607080910111213141516
- 17181920212223242526272829303132
- 33343536373839404142434445464748
- 4950
Object 2:
- Class: Data
- Logical name: 000080010OFF
- Short name of value attribute: 0110
- Value: visible string of 3 elements 303030
In the case of block transfer, the negotiated APDU size is 40 bytes.
Nota bene: What is negotiated is the APDU size not the block size! Therefore, the block size is smaller than the AF
size.

javascript;
iftop-1.0-0.pre3.el....rpm El 2020-12-08 Datatxt " SUBDLcom_the.pr....zip •••• V The Princess D....torrent es ShawMI X
TU ▪
PS ?J'W * < 285 / 310 2 :: Q R R 4 ,0A T T 0
Table B7 - Example Reading the value of a single annbule without block transfer
C00151 0501
000100005000001. <02<0 020100
.CetRequest. . Readlieque. 0ty • 8001•

, C.M30q960tlior6d1> 4Vaxiable04.e V010e- • 0000 . 1 ,
<inualcoldAndPrtority Yalue-•81• /. 4/9eadnquw.
, Actr/hutepeserloco,.
. ClassId V414..0001• /0
, inssencold Yatue-•000080000091• /,
khAttityleId V41.4- • 02• /,
, /Attribute044cripter0
KiGetReque4thormal ,
, ./04, RequO4BB
040191 0001
00 00
0032 0932
0102070409060 7 000910111211141516 01020304050407000910111203141516
171919202E2223242524272829303132 17181920212223242526272929303032
13341536373039404142434445464740 333415363 7 3039404742434445464 7 48
4150 4950
KGetnesponse, iwidnesp0044 OrY' •0290•

kGetnesponsenorm01, . 00[40
‹Invoko1dAnarlority Value••111• 10 40ctotString Yalu4•.01020304050607000910111213141516
ceesuIt0 07181420212223242520272929307132
kData0 13347596313039404142434445464740
<0c1•eStrinoVa1w..01020304050607030410111213141514 4950• /a
171111920212223242526272021303172 "bat..
33343530199039404142414445404740 4 /00000sponse ,
4950• /0
. /Date.
4/Result.
, /Gethesponsenormels
4/Getliesponse ,
Table BB - Example; Reading the value of a list of attributes wilhout Nook transfer
200351 0502
02 020]N
00010000806000FF02.00 020110
O0010000000100500290
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 1 285/310 I

45 Copyright 1907-2909 f1U..45 User Asscciahon
DLMS User Acsnciation. COSEM Architecture and Protocols, Seventh Edition
‹ Iteddllequeftt Qty= • 0002 •

<CetRequestWi[hLiat. . VariablenaseValue=•0100 .
<Ins, akeIdAndPriority Value- • 81" /0 • 0110 •cValib0NMeV10-
< 9.ttributenescrlptorList Qty= •0002 • , /neadlreeqpet0
, _AttributeDeacriptorWithSelection.
<Atcritnaenesc.riptor>
<01assId ValLie=•0002•
, Instance Id Value=•0000000000ff• I ,
, Attr.UputeId 0a4tio- . 52•
,c/.4ttri5utenescriptor ,
.0_0itrIbuteDesrriptorMithSelection=
[Rttrlbutenescr,ptor67ith6e1.tron,
cAtrrihurenescr1pror0
[ClassId ,24.lue=•0001• />
CInstanceId Value..•00008001000F' /.
<artributeid vallie."02•
< /AttributeDescriptor ,
,/_AttyibuLeDescriptorMithSelection,
, /Attributenescriptort.ist ,
</GetRqusin,
</GetRequesL.
C40381 0002
02 00
00 0932
O032 01020304050607000910112203141516
01020304050607080910111213141516 111819202122232425262728293031.32
17181920212223242526272029303132 33343536373519404142434445464748
33343536373830104142434445464740 4950
4950 00
00 0503
0203 303030
303030
.41tealinespohse Oty-•0002•
cGetResponse. <Data>
<OataeseonsenichLisc , ‹OCt0t0S.= ,00 V.100- . 01020304050607000910111213140516
.crovolteidAndPriority Value-•81• /0 1.7161920202223242526272829003132
. Result Qty= - 0402 - 33343536373939404142434445464740
< 0500. 4950. fa
‹OctetScrin4VaItie=.01020304050607080910111213141516 c/pacs0
17101920212223242526272029303132 < Data>
33343536313839404142434445464148 Nigib1¢StrIng
4950• I, < Amu.,
.q/ReadResponse.
[ Data]
cVlsibleString Value."303030•
▪ /Date ,
t/ResulL.
, iGetBespohsenithList ,
.q0etRespons.. ,
Table 89 - Example: Reachng the value of a single altbute with black transfer
00018/ <501
000100008000006T0260 52010<
DLMS User Association 120.39-12.22 I DLMS UA 1000-2 Ed. 7.0 1 286/310 1

C Copyright 1997 -20139 outs User Assomahon
TRZP EZ4.. T-UffrARRAM

uvA-4, tnaMiEs -
V.A17N, MihrAEBOLI
iftop-1.0-0.pre3.el....rpm " 2020-12-08 Data.txt " SUBDLconi_the.pr....zip " 2- The Princess Di....torrent Shaw all X
TU * -7.7 < 286 / 310 > I4 Q 0
steadteguest Qty.•9002•
sGetReguesttithList> cVariabIeNameValue= . 8I00 . />
stneakeIdend2giorityValue- . 81' ‹ YatiabIeHame Value-'0110" I>
settributeoescriptorList Qty- .0002• s/ReadRegnest>
<_AttributeDescriptorWithSelections
<AttribOtebencriptora
sClassIdValne=.0001. 1 ,
<InstanceId Volue= .0000800000FF"
e Atttibuteld Value-'02' is
siAttrlbuteDescriptor ,
, i_AttriboteDescriptorNithSelections
. _AttribUtenesoriptorWith1elections
satttibuteDescriptor>
<Classld Value=•0001 .
<InstanceId Value...0000800100FP' /0
gAttributeldValue-•02. io
ciAttributeDescriptors
s1_asggibntebeserIptormIthseleetion.
, ittirlbutegrescrIptorlast>
</GetilequestNithList,
,/Get Requests
C40381 0502
02 00
00 0432
O932 0102030405060/000910111213141516
01020309650607080910111213141516 17181920212223242526212024303132
17100920212221242526272829303132 33341536043819404142431445444448
33343531313039404142434445464141 4450
050 00
00 0003
O503 303030
303630
. ReadResponse 013-•0002• >
<0.etResposas . 0atas
<GetkeSpOn9eNithList7. <70cte100ring VaLue-'01028104050501000410111213141.516
, InvokeIdAndPrlority Vaise-•81• F. 11181120212223242526272029303102
[Result Oty= . 0402 . a 33343530313839404142434445464740
[Data, 4450' fa
sOctetStrIng VoLue='01020104050607080410111213141516 < /Datas
11101920212223242526272129301132 ,Datas
13143536113814404142434445464148 <Visible$tring Valve+.301030• I>
4950 • Yo < /Data>
</Data, ,ateadllesponses
<Data>
sgisIbleString Value."303030. 1>
</Data,
CiResuLt)
siGettegpongewithuist>
s/cettesponge,
Table 89— Example: Reacing the value d a single abriale with block transfer
100101 0501
00010000800000FF0200 020100
DIMS User Association 12009-12-22 I DLMS UA 1000 2 Ed. 7.0 1 286/310

-
O Cap9nglit1092-2001 MIAS User Assemahan
3MIEP, iPkg -FRIZg 5E3Zti TafrrWiiiia

5 M3312%1E, rt...41tt, IH1. 7,_*ItreAWrg!
ELMS User Association. COSEM Architecture and Protocols. Seventh Edition
‹Get/equests <ReadReq.est Oty= . 0101 .

.,Getteguestilormal swagiablerame value - '0100. fa
.tIOVOkeIdAnotPtletIty Malue=•81• Fs e /R.atIROgutSt>
. AttributeDescriptors
sClassId Value-"0001. /,
sInstanceld Value=•0000800000FF• 1<
‹ AttributeId Value='02' is
</AttribUtebesctiptor ,
siGettequesttonnal ,
./GetReouests
C40201 scot
00 02
00000001 CO
00 FOOL
In 21
093201028104050507000410/11213 C1000932010203040506070809101112
141510111019202022232425262728 131415101/1019202122232925262728
29
<0.e[ReSponses
<CetResponsemithDataBlocks <PeadResponse Oty=•0001•
</nvokeIdAndPriority is <Da[aaLocAResult ,
S tegall> skastelock Value-.00• I>
, LastEilock Value= • 00 • /s <81OckNomber Vaise= • 0001• is
<Block/Cumber Value... 00000001' /7. ,RamData Value.."0100093281020304D5060701309101112
4Pesults 13141516171814202122232425262720
cRawData Yalue=•09320102030405060 -708691.011121314 29' 1>
15161112E9202122232425262720' /s 5/DataBlock/esolts
</Result, </eesdRespon.e ,
.cfNesuits
. /GetResponsemithbataDlocts // 33 bytes of ram-data contains number of data, success, data
s/Gettesponge> II type, length and 29 bytes of data.
II 10 bytes el raw-data ChAtAiRS data type, length and 28 bytes If 51 II AS the rem-date contains the dAtA excelled exactly as without //
data. Note that Data is encoded, not Get-Data-result. block transfer. the number of results is encoded because the
II teadtesponse is a SDIODICE OF CSOME.
100281 0501
00000001 050001
seettequest> .[ReadRequest giy-.6001.

sGetReggestForNextDataBlock , selocktumberAccess ,
, Invoke/dAndPriority VaLue='11' fa <BlockNomber Yaloe= . 0001 . /›.
selacktueber value- . 00000001 . /' , i01OckNumberAcoes.s>
siGetRequestforNextDataBlock , . /Rentiliequest ,
, c/GetReques,
540251 0501
01 02
00000002 01
00 0002
15
29301132133415353131104041424344 10313233343535313834404142434445
454647484950 464 ,104950
scetResponse , steadtegeonse ,
DLMS User Association 12009- 12.22 I DLMS UA 1000-2 Ed. 7.0 1 287/310
▪ Copyright 1997 -2009 DUNS User Asscashan
iftop-1.0-0.pre3.el....rpm " 2020-12-08 Data.txt " SUBDLconi_the.pr....zrp " 2- The Princess °I....torrent " Shaw all X
e * < 287 / 310 -1, CA I4 R - A >< r r / -0 0
, GetRequesta , ReadRequest PLY= •

<Getnegnestnoonals cgariablettame Os
, InvokeIdAndPriority Value= • EIL . </RdittRequest,
, AttrihsteDescriptora
<Class/d valne-•000 /s
. IestanceEd Valne= • 0000800000/7 • /.
<AttributeId Value=•02• I.
</Attribntehescripton>
< /GetReguesttiormal.
4/GetRequesta
C40201 0001
so 02
00000001 CO
00 0001
Is 21
0'4320/020304050607080510111213 01000932010203040505070909101112
141516171019212122232425262728 13141516171019202122232425262723
29
c04.[00050030a
, GetResponsemithDataBIocka 4ReadResponse Qty='0001•
fInvokeInAndPrsority Sraluea'81 . <nataninctResnit,
<Result. <Lastislock value.•00• Jr
. LastBlock Value= . 00 . I= [Block/dumber Vaine= -. 47001• I>
CBlocnuaber Valuem00000001• cRanData Value"010, 909320102010405060701309101112
<Result> 13141516171815202122232425262728
<00w14t0 Value="09320102010405060708051011121114 29" f>
151617101920212223242526272B• is ./DataglockResults,
</Result, </ReadResponse ,
,
/Result.
5/GetResponsemithDataBincka i/ 33 bytes of ram-data contains number of data, success, data
</CetResponses type. length end 29 bytes of data.
// 10 bytes ot raw - data contains data type. length and 20 bytes .f/ of di As the ram-data contains the data encoded exactly as withaut
data. Note that Data is encoded, not Get-Data-result. block transfer, the number of results is encoded because the
// Readhesponse is a SESIMICE OF CEOICE.
000201 0501
00000001 050001
, GetReopeS, , <ReadRerpest Qty- • 0001 •

<GetRequeStFOrNextDataDIOOka -<0.10CkNurberAOCeSS>
, InvokeIdAndPriority VaLuea•91• 10 <OlockNuuber VaLue=•0001 . I>
451ackPlumber value-"00000001. it < /p/ocklaanberAceess>
< /GetReguestrorMextDataRlock , </ReadRegnest >
4/GetReques,
C40291 0001
01 02
00000002 01
00 0002
16 15
29303132333435363738354041424344 303132333035363 -23809404142434445
404647404950 4647484950
<0etResponse , cneadReSpOnSe Qtym•000l• a
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 1 287/310 1

C Copyright 1997 -2009 DLPAS. User Asseciahon
DLMS User Asswiation, COSEM Architecture and Protocols, Seventh Edition
<GetReSponSemiGhDatalatocka . DataBincEleaulta
,/nyokordAndPriority VaLue=•81• /0 4Lastalock Value=•01• I>
,Result) , SIOeldInaber vatoe - •0002• /0-
‹ ,astOlook Value- • 0I • I , <RanData Va1ue • 30311233143536371839404142414445
COlockNuaher Valuea•00000002• /0. 4047404060• /0
50,54190 </DatagloekResult ,
, Raw➢ ata 0000oe-• 29303/32333435363738194041424344 < /ReadAeSponsea
454647404550• /0
< /ReSa1ta // APDLI length 28 bytes, 21 bytes of raw-data castles the
,/ReSutta I/ remaining part of data requested.
O/GetRespnesewtthnataBlect,
e/Gethesportse ,
II ARM length 32 bytes. 22 bytes or raw - date terries the

Il remaining part of data requested.
Table 90- Example: Reading the value of a list of attributes with blodi transfer
000211 002
0/ 0.40100
00010000600000ET0200 020110
0001.00008001001F0200
AReddiligoeaL Ocr- '0002 .
4GetRequestellthList , v.i....oloo• it
4InvolieidAndPrlerity Va1or••11• /7. <tiarlab:eNa.• Yelse..0110•
chccribetedesertotortist Qty-•0002• AfReadReque0ta-
, _AttrIbuteCesarlptorWlth8electlen7
4Attribute0sscriptor ,
50145515 Valae- • 0001 •
, InetanceId kralue..000010000OFF.
‹ Attribote/d Value••02• I ,
e fAttribelte0*Seript0t ,
, i_httributeDescriptorkithSelectien ,
.,_AttriboteDeauniptorNithSoloetion ,
, AttributeDescriptora
011assId Value••0001• I.
< InttanCOId vat..•0000800100Fe•
‹ AttributeId Valuem•02 . it
cfactributeoescrlptor ,
[/_AttributeDesCrintOrMithSalection3
</AttributeDencriprorList ,
, /Getseguestmithcist,
</GetRovuest.
040261 0101
CZ
0000,3001 CO
DIMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 1 288/310
DLMS User Assnciation. COSEM Architecture and Protocols, Seventh Edition

pwasuipt,
El 2020 - 12 - 08 Data.txt es SIADLconi_the.pr ..zip es 2- The Princess Di....torrent Shaw all X

PS ?J'W • < 288 / 310 R It 4 .4A T"±—r,
4GetResponsewichletaB/ocks cgetaDlotkReaultv
4/nyoke/dAndPriority VaLue=•81• /, 41-astblock Value= . 01• /s
<Result , , blackinasber value-•0002 . /a
4LastBlock Value= • 01* aRawData YaLuea • 30311233343536171839401142134915
49lockliumber Value= . 00000002" I , 4541484950• /s
4Desultv 4,Pasa8loelatesolt.
4RawDatavalue- • 29303/12333935363738354091424344 . /Fteadhesponsea
454547981950 . /,
4/IteSUlt, // MOO length 28 bytes, 21 bytes of raw-data ...See the
r/Resultv If remaining part of data requested.
4/GetResponsewithBetaDlacks
•QCetResponse.
// APOU length 12 bytes, 22 bytes or raw-data carries the
// remaintrto Dart of data requested.
Table90 - ExarnOe,ReadmIhe value 01 a hstolattnbutes .1htgoatransfer

C00381 0:'.
02 0
000100901000009E0200
0001000080010081,0200
✓fleadAeS,Jeat 0[W-'0002• a
.cGetRequestWlthLista <,,,eriebletierm Velue••0100'
4InvokeldAnderiorlty Velur- . 81• /. 5Vasieblellsae Value- . 8110 . I ,
cAttri.batebescriptori.let Ory-.0002• 4/peeditequest.
, _AttributebescriptorWithSelection.
4Attributebrsoriptora
4Clasald yeiwe- • 0001 •
41nstancetd Val...0000800000ff. (5
4AttriaatrIst Valse..•02• /n
</Piccributellestriptor,
, /_AttributeDescriptoritithSeleetIona
<_AttributepescriptorWithSolectioh.
rAttributeDeecriptors
, ClassId Vslue-.0001• fr
4InStanceId Valee=•000080010OFF . /v
.cattributeId VaIne.•02•
4fAttrlbutepescriptor>
4/_3ttributenescriptOrartl,Selectionv
</A, ributenescriptorLint,
,./Getsequestaithr..lsr,
4/Getrrequest.
140201 9101
SC az
00060001 00
CHAS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 I 288/310

40 Copyright 1997-2909 I3LMS User Assccishon
DLMS User Assnciation. COSEM Architecture and Protocols, Seventh Edition
00 000/
LE 21
02000932010203040506070809101112 02000932010203049506070009101112
1374151617181920212223242526 13111516171815202222232425262 , 28
29
, Gethesponsea
4GetResponsewith9stainoek. <Readllesponse Qty-•0001•
canrokeidAndPriority VaLue=•01• 413ataThlockResults
<Result,. Ciast810et Value-•00.
41,aat9lack Value-•00• /v 4810e0Nalber Valac.•0001• /s
[11lockNumber Yalue= -. 00000001 . /s [Rawasta Yalue= . 020009320102010435090701409101112
< Result> 1314h5117131KO212223242526212H
cRaa➢ata Va1Uea•02000932010203090506070809101112 25• /a.
1314151517181920212223242526 . / 7- 4,DataRlotkResult,
c/Result] ✓/Readhespossea
4/Result,
4/GetResponsewith9ataBlock. // 33 bytes of raw-data contains the number of results and part
ViGetResponse , // of the data The first one is success, octet - string of 32
// elements: the first 24 bytes fit in.
// 30 bytes of raw-data Contains the number of results and part
// of the data. The first on is success, octet-string of 32
// elements; the first 26 bytes fit in.
100241 0501
00000001 05
O001
4GetRecmest>
4GetRegue5tForNextDataB/otka 4ReadRegueat Oty=•0001• a
‹ InvoiefdAndPriority VaLue= . 81• I, 401ockNumberAccesss
415104k.umber Value - "00000000` <alockPlumber value-•0001• /a
</GetRequestroritexthatai1locka -c/Eilookieueberaccessa
4/GetRequestv 4/Read-Request,
140201 GC01.
01 02
00000002 01
00 0002
LE ID
27292930111231143536173839904192 10313233393535373815404142439445
43444546474845500001103303030 4547484950000.503303030
40e[Retponsev 41teedamsponse gty=•0001• >

4GetResponsewithErataBIocks 40ataBLockResultv
rravokeIdAndarrority I, <LastIlloek Value...Dr . I>
<Resukt , calookesebet value..•0002• /.
4IastBloct Value= - 01 - /s [RawData Valne= -. 3031323334353633303 941741429 34445,
cEloc&Number Value ,. 00000092• /a 4647484950000103303030 . /]
<Result, cfustamilockiiesolta
4RawData Valne= . 27282930313233343536173839404 142 4/ReadResponse.
4344459647904950000A03303030 .
< /Result, // The Aenn is 34 bytes. It contains the second and last block.
4/Result , // 27 bytes of raw-data contemns the remaining 21 bytes of the
4/GetResponsewithBata83ock, // First result and the six bytes of the second result: success, /3
</netRespanse, visible string of 3 elenents
/./ 30 bytes ofraw-data contains the remaining 24

DLMS User Association 12009-12.22 I DLMS UA 1000-2 Ed. 7.0 1 289'310
C Copyright 1997-20419 DLMS User Associatior
ift0p-1.0-0.pf03.01.....Tprn " 2020-12-08 Data.tXt SIJEIDL0Gril_the.pr Zip ••• 2- The Princess Di torrent " Shaw all X
* < 289 /310 >
00 COOL
IE 21
02000932010203040506070009101112 02000932010203040506070009101112
1314151617231920212223242526 13141516171819202022272425262/25
29
91oth08p0nse>
[GetnesposseeithDotaCock. sileadResponsa 111, = • 0901 •
< InvokeIdAnderiority VaLue= . 31 . / 0 < Datal3LockResult0
4Retuit› la
CLastRlsok Valne- 9 00 .
[LastBlock Yalta- • A • / 3 [Blockliumber Value- • 001 . />
4/3-lociditusber Value= . 00000001• 4Raw44ata Value= . 02000932010203040504070809101112
[Result] L30411161710192021022324292E2720
‹Rawliata Value- . 02000932010203040506090809101112 29 . 2,
1314151617101920212223242526• I. [19/atalllockResult.
< /Result> [flkeadAesponme>
c/ReSuLt0
< /GetRespOnsewithDataigiock. 1/ 33 bytes of ram-date contains the number of results and part
C/GetResponse7 // of the data The first one is success, octet-string of 32
elements; the first 24 bytes fit in.
II 10 bytes of raw-data containS the number of results and part
// of the data. The first one is success, octet-string of 32
// elements; the first 26 bytes fit In.
000261 O501
01000=1 05
0001
[GetRequest,
[GetRequestForNextDataBlock , [ReadRequest Qty= . 0001 .
‹InvokeIdAridPriority YaLne4 - 01 . IS cOlokausberc a
[Olocktiumber ealue- . 00000001 . I> [Cocksumber value- 5 0001 • /<
</GeLBequestForblextpataillack, < 71310tkRumberAcceSs ,
</CetReouest› , /ReadRequest›
040201 OCOL
01 02
00000002 01
O0 0002
11 10
27202930313233343536373039404142 10313233343536171819404142434445
4344454647484550001003303030 4647404550000A03303030
coetResponse. sReadOesponse Qty - . 0001 . >
4GetResponsewithDataBlock. 4DataHlockResults
</nyakeldAndPriority VaLuo- . 91• /. 51-astalsek Valu,..01 .
<Result. [61ockNymber Value- • 0002 . 2>
< LastBlock Valne= . 121 . /a <RamDate Value 30313233343536373839404142434445
[RlockNumber Value' 06000002• /1. 46474840500013003303030 .
< Result , </OatafilookResult.
<RawData Value=•27202930313233343536373839404142 4/Read:Response.
4344454647424950000603303030 . /.
c/ReSUlts. // The MOO is 34 bytes. It contains the second and Last block.
</Result. 1/ 21 bytes of raw-data contains the remaining 21 bytes of the
< /GetResponsewithOataRlock] First result and the six bytes of the second result: success, //
eiGetResponse, visible string of 3 elements
I. 27 bites of ra.-data conoair, fo.4 2; t
DLMS User Association 12009.12-22 DLMS UA 1000-2 Ed. 7.0 2e9t3lo

first result and it alto contains the sin

//result: success, visible string of 3 elecer.t.
Table 91 —Example, Writing Me value or a single attribute vOthout block traoster

21010/
O0010000000040CF0200
0932 020150
01024304050607080910111213141516 O1
17181420212223242526272829333132 0332
33343536373039404142434445404740 01020304050607080910111203141516
4950 17181420212223242526272829303132
33313510373039404142434445464745
,SetRequest] 4950
[SotRequesttiornall ,
<InvokeIdAudPriority Value- . 81 . I> 41friteReguest.
[kttributeDescriptor] ‹ListOEVariableAccessftecification Qty . 0901 .
[ClassId Value-•0001• I, [variabiebiame maluc- . 0100 •
< InstanCeldValue="0000800000ff - /. [ftistOEVariabieAccestSpecificatium.
[AttributeId ea1ue= 4 02 4 /. [List0fDeta Qty= . 0000 .
[/AttributeCiescrIptor. [Octet5tring ealuo- . 01020304050697080910111213141516
W oluts 171815202122232425262521120303132
40ctetString Value- . 01020304050107080910111213141516 33343536373839404142434445464743
17101920212223242526272829303132 4950 • />
33143530353939401142434445464748 <11.1stO0Oata,
4950 . 4/WriteRegmesta
.4/Value ,
< /SetRequestMorsal.
, /SetRequest ,
250101 01301
00 00
0SetResponse , AfriteResponse aty= . 0001 .
tgetaespoesemormal> <SucCes/0
[InvokeIdAridPriority VaLue=•21• /0 4/1friteRelpenSe0
<Result Value='Success' /u
</SetReSPOnSeNOrmal°
4/SetReSpOnSe0
DIMS User Association 12009-12.22 I DLMS IJA 1000 2 Ed. 7.0 1

- 290/310 I
Copyright 1997-2109 outs Liserr Assoc abon
iftop-1.0-0.pre3.el....rpm " El 2020-12-08 Data.txt SUBDLconi_the.pr....zip " 2- The Princess °I....torrent " Shaw all X
- EU ?7W < 290 / 310 ) 4 R R 4 21, A ! T 7," T *
first result and it also contains the Six bytes Of the second
//result: success visible string of 3 elements.
Table 91 - Example:Writing the value 04 a Single attribute without block hanger

210181
O0010000800000F70200
0932 020100
01020304050607080910111213141516 01
17141920212223242524272829303132 0932
33343536373819404142434445464140 01020104050207002910111213141512
4450 17181420212223242526272829303132
33343536373019464142434445464748
cSetReqUeSt , 4950
cset0equestmormal,
< InvokeIdAndPriarity W1100= 2 31" /2 . WriteRequest.
,AttribateDeseriptur, cListOEVariableAccesaSpecificatian Qty - '0501'
t class1d Value...0001 • , variabienme value ..°0100 . /,
< InstanCeld Value- . 0000800000FF . Is ‹ fLiatOntariableAtce.58pecificatiaa>
,Attribute/d Value= 02' /5 clist0E0ata 4qty- . 0001 .
5/61011buteDescriptor , .0ctet9tring value- . 01020304050607000910111213141516
,Value. 17101929212223242526272229303132
, ectetString Value= . 0102030405060700091011121314151-6 33343532373839404142434445464748
12181920212223242526222829303132 4950 . / f
33343536323839404142434445464248 -cf11sc0f0at.>
4950 . /v t iWriteRaqueut.
4/values
, ./86c0equestMormalp•
, /SetRequests
C50181 00.01
00 Is
, 2stResponses WriteResponse aty= . 0001 .
,5etaesponseotormals /0 <Suces
< Invok.IdAnciPtlotity Value—•81• /1 < /kritellespooses
. Result Value= . 8nccess . / 5
</Set 9eSPO 0 SeUc,r.Sn'
</SetReSpOnSes

e Copyright 1997-2909 DLMS User Association
Table 92 - Example: Writing the value of a Nat of aliributas without block transfer
010491 0602
02 020100
00010000000000M200 020110
O0010000000100170200 03
02 0932
9931 01020304050402000910111213141516
❑1010304950607080910111213141516 13141970212223240524227929103132
17141.920272223242526272029303132 33343536323039404042434445464244
3334153637 30394041424 )4 445464740 4950
4552! OA03
0003 303030
303139
O tricallecipmics
cSatfieguest. cL1ntOrVariab1eAcces6SpecIfication Oty..0902.
,setaeouestaormatelthclaIS .YertableName Value-'0190' I>
< InvokeldAnarioricy Value••31" <Variable/law Va1ue•.0119. />
OtteributeDe.criptorLiat Oty..0002 . , /1.1.0EVar.101eAcc4s43p9c1ficationa
<_AtirlbliCepe0CrIPM4101.54.M[lon. 51440 ,252224 220-'0002 .
<At[ribut.Drocrip[or , <Cc-M.3[ring Val....0020104550007000910111213141516
<Clasold Yalu. 0 01• I. 17101920212223242526272029303132
cinataneld 01047-.000080000017 . I, 113435/01 , 1939404142414445406746
<A[eributeId Velge• . 02 . 4959 ./s
</AttributoDescriptor , 4V1.115148tring Yalue••392030• /s
. ./_,M[rIbUteCeSCrip[OrNithSelec[lon. .fLteT0f 04ta.
len s .., mcitvesquast,
tAttributeDescriptor
<C144sid Valde- • 0001 •
<Inetenceld Val.•.0000600100FF• Sc
0,[tributeld Val.... .02* JO
</Accributeilesoriptor ,
, /_AteributeDeacrip[orMi[hSelecelons
4/AteributoDescrip[orList ,
.VM1UeLiS1
, 002atString 04lue.w01020304050607000910111213141518
17181920212223242526272029301132
11341516121809404142414445464/48
4950 2 I,
cV1611,1aStrin9 V41ua , •301030. /5
./ValueLint,
</SecileouestKornallitchLisc,
.c/setsequest,
050591 0502
02 00
00 00
00
t WriteResponse 000 ,- 0002 - s
<setaespapse> <Succes. /7
.5etResporeae9ithList. , SuCted5 1,
cInvoke/dAndPriarity VaLue= . 31. 2 (> < /WriteResponses
.Result Oty- . 5402' >
DLMS User Association 12009.12.22 I DLMS UA 1000-2 Ed. 7.0 I nirsio I

Copyright 19972009 DLMS User Association
iftcp-1.0-D.pre3.e I...rpm M 2020 - 12-CS Data txt SUBOLcon_the.pr ..zip " to- The Princess Di.....torrent Show all X
TU PS ?[0 *LI= < 291 /310 ) / R R 4. ••• AAT --
± T, 0
Table 92 - Example - Wrmng the value of a list at attributes without black transfer
010401
02 C.
00010000000000880200 O2.11:.„
000100008001001T0200 52
02 0932
0032 00020904060607.08001011121314116
01020304050607030910111213141516 17192120212223242526272929303132
17181920212223242526272829303132 33343536573839404142434445464748
33113536371039404142434445464749 4950
4950 01103
11301 303030
303030
<Opitelkeimeots
C940649.4400 ctim0081/ariabLekccassSpecIfLcation 0i5•.0002•
.8400401.3001100m8101010140 5 KvAr10010N44,0 04100 ■ • 0100 . / 5
4InyokoldAndOrtority Value..81. .0arlablotim0o 041oes•31111. /.
attritioceDescriptorLiot 01E1.•0002• 4 < /LtotOrY4rfabloAccoomSpecificat0004
<-8tirlbOtemeocrlmor010150108C1on4 c00stefData03z5 - '0002'
cAtextbuteDescrliptora 40e0et9t0109 VoLuo.•01020304050607000910111211141510
402.4.10 Valuo••0001• /s 17181120212223242526272829303132
< 1ristanceId Woe..•00008000000F . ire 3034153631383940414240444546474e
cAceributeId Valuo•"02. 4950. Is
< /AttributoDoscriptor 0, 141bleString Va1ue••303030• /0
ALAttxtbkmeDescripcorlI1[h5elecciona , atetafeata ,
. _AttrIbuteDeocrlptorN1ChSelectlona .4/Write0equests
O ittributeDomcriptors
O0loos00 valde-'0001• /0
.cInotericold 0.1u.. 00008001008F• /0
Oiter1hute/d VaItie••02• 1,
, /Actributopeseriptora
.0_,AL8xibuCeDoecr1ptOrkIth8e14ittons
4attributrDeocriptocLi.sts
g[y-•0002• a
.3cto[String 04100..01020304050607080910111213141516
17181920212223242526272829303132
11143536171809404142434440464748
4950.
=v1sihleStrino Irodue=•303030• /0
. 15e0geoueothormalinthtiots
<isetilecruetts
000001 0002
02 00
00 00
00
.Writenesponse
<Set Response , cSocCO3.3
[SetReSpenseKithL1Sta , Surcess
,InvoteIdAndPriority Value-'B1' . /MrIteResponse.
<Result qty- - 0002'
DIMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 I 291/310 1

45 Copyright 19e7 -2009 titUS User Asscciation
. _Pateditee,311e.ult Value-'Success . 1>

, DataAccessResalt VaLue=•Success• / 0
4/0e 1.0
< /SetPesponse.ithLnst>
[/Set Response ,
Table 93 - Exainde: Meng the value of a single attribute with deck transfer
000231
00015000850001000200 G7
00 GO
00000001 0001
15 01
39320102030405040708091011121314 0310
1516171419 010200009109370[020.3010506070009
101112131415161718192021222324
.SetRequest>
,$erlt.q,,tWithrir,Oat.G.4100. Aititelteguegt>
, InvokeIdAnciPriority Value- . 81 . /a , Liot0EvariableAcceasspecification Qty - • 0002 • >
. AttrlbuteDescriptor> edriteDetaDlockAccets>
[Clag5/d /0 ilagt111pck
, luscancerd value- • 0008000000Y • ..c01ocktfumber value-•0001" /a
. 02 . /> ,AtribueIdYalv= ./WriteDataBlockAccest>
, ,Attrihnteftesrlptor> C(Li9LCIEVariableliccessSpecification ,
.4.Dat.315100k> <6ist0E0ata 0ty-•0001• s
< LastBlock Valne= • 05 • 0000e00tring VALue= • 01020100010912010203040506070809
22loc&Number Va1ne...00000001• (1 L01112131415161711102021222124'. / 7
, 0,eOsta value-•09520102030405060708091011121314 </LiGtOfDdt.>
1516171819. is . /Nriteliequast>
, alataBlock>
</SetRequestilithFirstDataglock , // 31 bytes of octet-string contains ran-data: the sequerce of
e/StRouest› II Varlable-access-Specification, the sequence of Oats, the type,
// length and the first 24 bytes to be written.
// 21 bytes of rat-data contain the type, length and the first 19
/I bytes of data to he Wtitt@rt.
000281 O001
❑ 0000001 U2
0001
<540Getpe.5S.>
., SetResponseForDataBlock> MfriteResponse Qty='0002 .
ctovo'ReIdAnciPriority value-•01. chlockmumber Value-•0001 . />
, 81acktiumben Value..00000001• I , < /kriteResponses
< /SeCRespanseForDataBIock>
.qletkesponse7
010181 0601
01 07
00000002 51
10 0002
20212223242526272029303132333435 01
303730394541424344454647404955 090A
25262728293031323334353631383940
<SetRequeSt> 41424344454647484950
,SetRegnestWithDataBlock›
DLMS User Association 12009-12.22 I DLMS UA 1000-2 Ed. 7.0 1 292/310

Copyright 1997 -2009 of User Assocaohon
" 2020-12-08 Data.txt " SUIDLcom_the.pr ..zip •••• 2- The Princess Di....torrent Shaw all X
TU * < 292 /310 > ▪ -0 0
. DataAccessResult Value=•Success . I>

S _DataAccessResnit VaLue='Success ..
</Result.,
</SetResponseNithEist.
./SetEtesponse>
Table 93 - Example: Writing the value of asingle attribute with block transfer
C10281 0001
0001000080000MT0200 07
00 00
00000001 0001
15 01
09. 3201021}30 ,105060i48091011121314 091F
1516171819 O10201000109320102153040506079809
101112131415161718142021222324
<Set Request>
,SetReguestelithEirstbatahlocits O triteitegwesta
,invoke7dAndrrlorlty value-'01" is ,tistofvoriableAccessspeclfication Qty - '0001'
‘ AttributeDescriptor. , WriteDataBlockAccess>
,Class/d Value...'000/' /> , lastalock Value-'00' />
, Instancerd volue. , 0000800000FT• /5 , elockeueber value- . 0001•
, ArtributeId Valne="02 . I> </WriteDatalUurkAccessa.
.41.tribetene.SCriet.r7 </List0EYariableAccessSpecificatior, ,
, Dataelock> <ListOtpata Qt.y., 0001 .
, LastBlock Value-•00• /. o 0ctetString Vatue-•01020100010912010201040504010809
CEloc&Numher Value 00000001• P. 101112131415161710192021222324' /5
< Kaw0ate value- . 09520102030405060708091011121314 </List0f0ataa.
1516171819. 25 %/WriteRequest ,
, /DataBlock7
., /aetRequesth/thrirstOataalocha. // 31 bytes of octet-string contains raw-data: the sequence of
c/SetReq,est , // Variable-Access-Specification, the sequence of data, the type,
if length and the first 24 bytes to be written.
// 21 bytes of ran-data contain the type, length and the st 19.
// bytes of data to be written.
050281 09.01
00000001 02
0001
csetResponse ,
< SethespenseForDataBleck , ,WriteResponse aty= . 0001 .
L Invoke.IdAndPrioritV value-.81 ,P is teloormueber Yalve-.0001. , />
< 13lockNumber Value=•00000001• /. . /WriteResponsea
< /SetResponseForBataBIocka
•c/Setaesponsea
U10381 0601
01 07
00060002 01
IF 0002
20212223242526272829303132333435 01
363730394041424344454647404950 091A
25262728293031323334353631383940
sSetReguest> 41424144454647484950
,SetReguestWithDataBlock7
DLMS User Association 12009-12-22 I DLMS UA 1000-2 Ed. 7.0 292r310 1

C Copyright 1997 -2009 DIJAS. User Associshan
DLMS User Accrriation, COSEM Architecture and Protocols, Seventh Edition
c/nvoke/dAndPriority Vatue= . 81• /> sWriteReguestr

, Datafasck , <List0EVariableAccessRpecification Qty=•0001* 7
[Laa,010Ck Value-"01• , WriteDataSLockaccessa
< 12.1.ockliuraher Value-..00000002.. is . LaatIllock VaLue-•01• is
, RayData Value=•20212223242526272029303132333435 , BlockNomiser Value= . 0002. />
363738304041424344454687404950• /a 42write0atablocMccessa
< 10ataBlocaa .‘/ListOfVerlableAccessEpecificatiorta
e /SetReguestWithpataRlock , cList0f0ata Qty=•0001•
., /SetReguesta , OctetStringValue-•2526272829.3011321134351137188940
41424344854447484050. /•
/2 11 hytea of raw-data contains the remaining 21 byte, of the
// data to he written. ., Ar rIteRequest
2 ■ TN. &POO is 15 bytes. 26 bytes of octet-string contains ran-
i/ date: Lhe rmealning 24 bytes of data co be written.
0503810000000002 000100
cSetReseonse. .afritePesponse 9tyn - 0001. a

cSetRemponseForLeatDetablocka tSuccese ir
< InuokeIdAnderlority Valu • 81 . ta .KIKrIteReepoese ,
cReault ValiteanSuccese. /a
011ockNumber Valuen•00000002• I>
./SecResponseForLascOateBloch.
'''S• 00 ponsea
Table 94 - Example: Wolff ng the value of a Itsi of attributes with block transfer
010501 0601
02 07
000100008000001T0200 00
00010000Boa100rr0200 0001
00 01
00000001 091E
OA 02020100320110020932010201040506
02093201020304050607 0709091011121314151iI.7181.92021
4Setitegueata ( WriteReguent ,
., SetReguestWlthListAndhitheirstilatablocka •aistOfVeriableAccessSpecIficetion Qty-"0001. a
. inyoterdAndPriority Value , •81• rWriteoetaglocrAccoesa
chttriburenener1etorList qty....0002. a 4tastnloch Value...00 . / 7
,, attributeDescrlptorwithSelectIona ., elocamumber value-.0001. /5
cAttributenoscriptora ./writeuatabiorsAccessa
‘Claanid Value-'0301' /3 caintOEVariableAccess5pecificatina,
4instanceid value.•0000800000vF. /a < Lista:goats gty..•0001•
0,ttributeId Value=•02 . is .DctetString Value= • 02020100020110020912020203040506
</AtcributeDescripter, 070005101112131415181718192321'
, /AtLxibuteDescriptoraithSelection5 “Listafbata,
, _At,r:17,,ED.Encrip,urWi,!-.2electiOn? s/WriteRequest ,
The APTU le 40 bytes. 31 bytes or octet-string contains raw-

DLM S Association 12009.12-22 DLMS UA 1000-2 Ed. 7.0 293/310
C Copyript 1997-2009 DLMS Lfser Associabon
DLMS User Accnciation. COSEM Architecture and Protocols, Seventh Edition
iftop - 1.0 -0.pre3.el....rpm " El 2020 - 12 - 08 Data.txt es SUBDLconi_the.pr ..zip es 2- The Princess Di....torrent Shaw all X
/30 * < 293 / 310 4 Q R it •. A T T oh A 0
rfnvokefdAndPriority Value- - 81 . rWriteRequeot7

Mataillock0 shistnEVariableAccess5pecification Qty= . 0901 .
rLasthlork Walue- • 01 • / 7 O friteitateSlackAccessa
shlockieursher Value-•00000002• /a <Lastillock VaLue- 9 01 ° Is
shawData 7a1ue-8 202/0223242526272029303132333435 , 19foehhoeber Va1oe-.0002• /,
367738399041424314154607484950. , /erite0ata111ockAccessa
r/Datahlook. </LiscOfeariableAceessSoecification>
✓/SetReguestWishilataBlock. .Livc0f0aca Qty-.0001.
, /SetReouesta tOctetatrind Value-.25262728293031323334353637303940
41424144454447404950• /•
// 31 bytes of pea-data contains the remaining 21 bytes of the </LimitOfnata ,
I/ data to be wri.ctert. •t/IfeateRequest
/1 The 4000 0s 35 bytes. 26 bytes of octet-string contains res-

/I data: the remaining 24 b tea of data to be written.
0503810000000002 000100
csethesponse , o triteRespoose Oty.•0001•

.SotheaponseForLaschataBlocka .[SUCCOB. /0
, IesOkeIdAhdFribr1Ly value•'91 . < /hrtteReepObSe ,
c Result 0alue."Sueeess• /5
chloctNueber Value.•00000002. /a
< /SecPesponseForLastOecaBlocha
c/Setliesponsea
Table 94— Exinvie: Wang lbo value of *list at *aribulos With block banstar
c10501 040/
02 07
000100000000001F0200 00
000/000000010011, 0200 0001
00 01
00000001 091F
Oh 02020100020110024932010203040506
02093201020304050607 070$09101112131415161.710192021
e Sethequest , ewriteRequest5.
, SetkequestelthListAndeithEirstOstablocka .cListefeariableaccesalreclfication Qty- 4 0001"
.cttmaiteldandPriority /. ehritoUetaBlockAcceasa
eAttributegenoriptortiat Otys•0002 . 0 etastalock Yaluee . 00 . /0
, _AttrIbuteDeserlptorelthSelectIons , Olocaliumber value., 0001• /a
.tAttributeDoseriptora r/WritebatahlockAccess›
MlassId Value - - SOOT - h casstOrbartableAccesnSpecefication0
-cinstanceId ealue-.•0000800000FE• /a ciastafoata Qty-"0007" a
rAttributeId Walne..02 . / 0 rOctetString Value= . 02020100020110020912010203040508
</ACtributellescriptor> 07013001.01112131415101718182021 - /7
< /_attribureoescrIptorwtthselectlen, raistOrUata,
<_AttributeDescriptoreichSelection> r/KriteRegwest.
✓AttributeDescriptor,
<ziassrd Value-"000I" I. If flle 81.041 is 40 bytes 1 bytes of octet-string contains raw-
DLMS User Association 12009-12-22 I DLMS UA 1000 - 2 Ed. 7.0 I mom
Copyright 1397-2909 IlLAILS User Asscaahoo
rinstanceId Value= • 0000800100FF . /. // deter the number and the mine of objects to be written, the
rAttributeId Yalue= . 02 . /> if number of data to be written and the first 21 bytes of the
rfAttribute0ascriptor7 // first data to be written.
0_8ittributehesorlptorMithSelection.
r/Attributetiescriptorlists
Matablock›
<Lastfelock Value- . 00• /0
r8lockNumber Value= . 00000001• /0
<Sestina Value4.0209320102030405.0007• /7
r/DataBlocka
r/SetReguestitethhestAndWithFirsthatablock,
r/SetReguest7
// The APBU is ha bytes. It contains the two attribute
// descriptors and 10 bytes of ram - data containing the type and
I/ length of the first data and the first 7 bytes to be written.
050281 07101
❑ 00041001 02
0101
rsetResporise,
rSethesponseForhataBlock. Otiriteliesponse Orty= - 0001 . .
rInvokeIdAndfriority Value= 91 - h rEilockNumber Value-'0001 .' / 0
<01acktlamber 0alue- .00000001 . Is r/ffriteReSporssea
r/SetReseonseForDemaBlock.
r/SetResporines
0103131 0001
00 07
00000002 00
IF 0002
48091011121314151617101920212223 01
242526272829301132319475363738 091F
22232425262728293031323334353037
, setRogyest, 3039404142434445464741949500703
<SetnegoestWithpataBlock>
rInvokeIdAndiPriority Value= . 81 . h rWritelkerpiests
Matahlock7 rtistOEVariablekecessSpecification 0rty-•0001• C
<LastEilook Value- • 00 • ./a rWriteDataBlockAccese>
rBlockNumber Value= . 00000002• /0 rlastalock Value= . 00 . / 0
<Pei/Data 0alue-'00091011121311151617101920212223 rRlockNumber Value-' ❑ 102" /s
242526272029303172333435363730• /a r/Wrim005t5000okAetess›
r/DataBlocks raistOfVariableAccessSpecification.
r/SetReguestMithinataRIock7 clist0E0ata Otys . 0001 . 7
riSetRequest0 000tetStrlsgVaLuev . 2223242526277829303.1323334353637
1830411414244444546474849500/03 - / 0
// The AVE1 is 40 bytes_ 31 bytes of raw-data contain the second c/1.1st0Enataa
// part of data to be written. .c/writetteopest,
/1 The hieDU is 40 bytes. 31 bytes of octet-string contains rave-
l/ data: the second 29 bytes of the first data to be wr1tten and
II the data type and length of the second data to be written. The
// value follows in the next block.
C5028100000002 0001
02
DIMS User Association 1 2009-12.22 I DLMS UA 1000-2 Ed. 7.0 1 294/310 I

Copyright 1997-2009 outs User Associislim

javascript;
iftop-1.0-0.pre3.el....rpm El 2020-72-08 Data.txt SUBDLcorn_the.pr ..zip n 2- The Princess °I....torrent n Shaw all X
-7Ar < 294 /310 CA I4 A A I T 11 -0 Eil a •
, InstanceId Vaine="000080010OFF . I , II dm,: the number and the name of objects to be written. the
<AttributeId Va/ue= . 02' / 0 // number of data to he written and the first 2E bytes of the
<fl8ttributeOescripCom2 // first data to be written.
, LAttributeDescriptorMithSelection ,
, ./AttributenescriptorLista
4DatabIock2
, LastBlock Value-•50. 1<
<13loc&Number Va1ue=•00000001• /4
[Pashata Va1ue- . 02091201020304050607 . / 7
, /DataBlOoka
</SetReguestBlithListAndifithFirstnatablock ,
.4/5etRqUSt0
// The APDU is 40 bytes. It contains the two attribute

// descriptors and 10 bytes of raw-data containing the type and
I., length of the first data and the first 7 bytes to be written.
150281 0901
00000001 02
0001
, setResponse2
, SetResponseForDataBlock , 4WriteResp0nse Qty='0001' ,
,InvokeIdAndPriority Value='81 . 11 cRlockaurber Value='0001' /a
, slockmumber 9alue-, 00090001. /2 c/aritenesponse ,
[iSetRespenSerorDataBlock>
4/SetResponse4
C10701 0601
00 07
06000002 00
IF 0092
08091011121314151617001920212223 in
242526212829351132313435163038 011F
22232425262720203011323134351637
.48e-thegyest› 303140414243444546474049500003
, SetRequestWithDataBlock0
.InvokeIdAriPriority VaLue='01' /0 ‹WriteReguest ,
,batabEock> ctistOEVoriableAccessSpecification Qty-'0501• 2
, LastBlock Valne- . 00• /0 , WxiteDataBlockAccess>
<BlocicHuraber Value= . 00000002• ), <LastBlock Value= . 00 . / 0
,Rawbeta Valne-..00511911121.314151617191120212223 <OLocktioaber Value- . 0002 . / 2
242526202021303132333435363930• /0 </Write0ata01120kAccess>
</DataBlock , , nist0fliariableArressSpecification0
<T5stRequestWithData0/ock7 <ListnEhata Oti,.•000• 2
ciSetRegaest , .0etetStrinq Vakue-•2223242526272829300132113435363')
303940414243444546474849500503• /4
// The A1490 is 49 bytes_ 31 bytes of raw-data contain the second </ListOEDataa
I/ part of data to be written. c/Nrite0agmest4
// The AP00 is 40 bytes_ 31 bytes of octet-string contains raw-
If data, the second 29 bytes of the first data to be written and
11 the data type and length of the second data to be written. ThE
II value follows in the next block..
n020100000002 01201
02
DLMS User Association 12009-12-22 I DLMS DA 1000-2 Ed. 7.0

C Copynght 1997-2009 I11/.45. User Assomalion
1 2941310
cletnerapOnse , 0002
< SetResponseForDataBlock0
<trivolcoIdAndPriority Value-'91" 1 , .0friteResponse Qty-`0001" 7
, B1oold4amber valne=•50050002• , 910ekNurber Value-•0002• /4
< /SetResponsePorDataBIock , </WriteResponse4
</Sethesponse ,
110251 0691
01 07
00000003 Cl
0003
14404142434445464748495000011030 01
10 0103
303030
, SetRequeSt ,
[SetRegnestWithDataBlock> 4WriteRequesta
cineokeIdaad9riority 0.0-0e." 81. 1< ctistnevariableAecessSpecification Qty-"0001'
‹ natahlock, oftltepataslociAccess2
,LastBlock Valne= . 01' JO .,LasrBlock Value - 01' /a
chlocidiumber Value ■ - 09500003. 17 4BlockNuaber Value. - 0003w 10
,RawData 2a1ue ■ °39404442434445464748415008033030 </wrItemataislock0ncess0
35 . to < /ListOEVariableAccess5pecification ,
, /DataBlock7 clist0E0ata Oty . 0001 .
, /SetileguestRathDataBlock , ‘4)ctetString Value-•303030 .
./Set Request , -c/LiStOEDate ,-
tiWriteReopest ,
// The 00003 is 26 bytes. 17 bytes of raw-data cantata the third II part
Of the first data and the second data to be written. // The APOU is 12 bytes. 3 bytes of octet-String contains raw-data: th
value of the second attribute_
C50401 01202
02 00
00 00
a0
00000003 .mritenesponse Qty-•0002• ,
, success
, SetResponse , cSeccess /,
<$ethesponserorLast0atailochWithList , .K/Vriteaesponse ,
< InvokeldAnd9riority Value-.81• /4
[Result Cty= . 0002•
. _bataftccess0esult VaLoe ,'Successw /4
, _Dat000Ce5SReSal1 Value=.5occess. /4
[/Result ,
<RlockNumber Value-'00000001' /5
< /set0esponseForLastoataslockwithiast0
0/SetResponse,
DIMS User Association 12009-12.22 I DLMS IJA 1000-2 Ed. 7.0 1 295/310 I
Copyright 1997-2(M9 outs User Assoraahon
ni MS liner Asconiation. CORFM Architantnra and Prntn•ols. Savanth Frlitinn

javascript; AM_
iftop-1.0-0.pre3.el....rpm El 2020-12-08 Data.txt ••••• SUBDLconi_the.pr....zip •••• The Princess Di....torrent •••• Shaw all X
< 295 310 > '-. C114::: (1 Rot* .A./T TT/ 6 7 * 0
eSetResponse> 0002
<SetReaponserorDataBlock5
itnv.keIdAndPrierity Value- . 0l' /7 Afritetespoose Qty- • 0001 •
, BlaCknunber Value= . 00000602* Y5 -0, 1oeltNumber Value=• 9102 • is
</SetnesponseParDataBLocks , /WriteRespanse,
, i5etfteapense ,
C1038I 060 1
01 07
00000003 CI
11 0003
3440414243444546474444500503300
30 6903
303030
<5000eque055
<SetRequestWithDataBlock , 4WriteRequest ,
CfnvokeIdAndPriorrty Val0e....01. I, , tistOEVariableAccess$pecthcatxon Qty..ouel .
cwaitaitataslackAcceasa
[LastBlock Valne='01' eLastRiock Valne= . 01'
‹ BlockNumber Value."00000003• [blocklineter Va1ue ■ '0003'
<nawo0revalne ■ •3940414243444546474849500A033030 .c/writeuatacanckAccess,
30• is ‹ aistOEVariableAccessSpecifi.matinn5
, /DataBlock, cLiaL009.ata Rt9 ..0001.
</setnequestwithontaBInck› ...303030•
voctesringalu is
./SetRequest. -caistOED.R .t.>
./WriLeRegees,
// The APDU is 26 bytes. 07 bytes of raw-data contain She third // part
of the first data and the Second data to be written. // The APOU is 12 bytes. 3 bytes of octet-string contains raw-data; th
value of the second attribute
C50401 0202
02 00
00 CO
00
00000003 [writeResponse Qty 7
-, Sottesa
cSetResponses cSoccess /,
,SeckomponserartastPatalllockWithtiat> [ DrriteOeSPOnS.›
, InvokeIdAndPrintity Value= 011 • /.
rResuIt Cty= . 0002 .
._bacaAcconsCesult Value-'Success' I>
<_DetaAccessResult Valoe- • 50eces • /5.
< /Result7
‹BlockNumber Ua1ne■ ^00000003. /7
</SecnesponseForEast0acaBlockW1thList ,
, ./SetRspone
DLMS User Association 12009.12-22 I DLMS UA 1000-2 Ed. 7.0 1 295/31°

15. Overview of cryptography (Informative)

NOTE This clause is provided as a brief introduction to the cryptography toots selected More information can be found
in the documents referenced.
15.1 General
NOTE The following text is quoted from NISI SP 800-21 3.1
Cryptography is a branch of mathematics that is based an the transformation of data and can be
used to provide several security services: confidentiality. data integrity. authentication, authorization
and non-repudiation. Cryptography relies upon two basic components: an algorithm (01
cryptographic methodology) and a key. The algorithm is a mathematical function, and the key is a
parameter used in the transformation.
A cryptographic algorithm and key are used to apply cryptographic protection to data (e.g., encrypt
the data or generate a digital signature) and to remove or check the protection (e.g., decrypt the
encrypted data or verity the digital signature). There are three basic types of approved
cryptographic algorithms: cryptographic hash functions. symmetric key algorithms and asymmetric
key algorithms:
■ cryptographic hash functions do not require keys (although they can be used in a mode in which keys
are used). A hash function is often used as a component of an algorithm to provide a security service.
See 15.2;
• symmetric algorithms (often called secret key algorithms) use a single key to both apply the protection
and to remove or check the protection. See 15.3:
■ asymmetric algorithms (often called public key algorithms) use two keys (i.e.. a key pair): a public key
and a private key that are mathematically related to each other. see 15.4.
In order to use cryptography. cryptographic keys must be "in place", i.e., keys must be established
for parties using cryptography.
fit r
iftop-1.0-O.0r93.91....rpm ^ El 2020-12-CS Data txt SUBDLcom_the.pr ..zip ••••• .2 The Princess 01....torrent Shaw all X
f: f : : Et A ." T T 1 6 :)Q 0
15. Overview of cryptography (Informative)

NOTE This clause is provided as a brief introduction to the cryptography tools selected. More information can be found
in the documents referenced.
15.1 General
NOTE The following text is quoted from NIST SP 800-21 3.1,
Cryptography is a branch of mathematics that is based on the transformation of data and can be
used to provide several security services: confidentiality, data integrity. authentication, authorization
and non-repudiation. Cryptography relies upon two basic components: an algorithm Or
cryptographic methodology) and a key. The algorithm is a mathematical function, and the key is a
parameter used in the transformation.
A cryptographic algorithm and key are used to apply cryptographic protection to data (e.g., encrypt
the data or generate a digital signature) and to remove or check the protection (e.g., decrypt the
encrypted data or verity the digital signature). There are three basic types of approved
cryptographic algorithms: cryptographic hash functions. symmetric key algorithms and asymmetric
key algorithms:
■ cryptographic hash functions do not require keys (although they can be used in a mode in which keys
are used). A hash function is often used as a component of an algorithm to provide a security service.
See 15.2;
• symmetric algorithms (often called secret key algorithms) use a single key to both apply the protection
and to remove or check the protection. See 15.3:
• asymmetric algorithms Soften called public key algorithms) use two keys (i,e., a key pair): a public key
and a private key that are mathematically related to each other, see 15.4.
In order to use cryptography. cryptographic keys must be "in place", i.e., keys must be established
for parties using cryptography.
15.2 Hash functions

NOTE The following text is quoted from NIST SP 800-21 sub-clause 3.2.
A hash function produces a short representation of a longer message. A good hash function is a
one-way function: it is easy to compute the hash value from a particular input: however, backing up
the process from the hash value back to the input is extremely difficult. With a good hash function, it
is also extremely difficult to find two specific inputs that produce the same hash value. Because of
these characteristics, hash functions are often used to determine whether or not data has changed.
A hash function takes an input of arbitrary length and outputs a fixed length value. Common names
for the output of a hash function include hash value and message digest. Figure 106 depicts the use
of a hash function.
A hash value (H1) is computed on data (M1). M1 and H1 are then saved or transmitted. At a later
time, the correctness of the retrieved or received data is checked by labelling the received data as
M2 (rather than M1) and computing a new hash value (H2) on the received value. If the newly
computed hash value (H2) is equal to the retrieved or received hash value (H1), then it can be
assumed that the retrieved or received data (M2) is the same as the original data (M1) (i.e.. Mt =
M2).

Copyright 1997.2009 OLMS User Association

javascript;
iftcp-1.0-0.pre3.el....rpm El 2020-12-08 Data txt SUBOLcom_the.pr ••••• 1.2 The Princess D....torrent •", Shaw all X
* < 0, f=t A # T T
Generation Verification
Hash . *Fil Hash -p H9

M1 m2-0 Function
Function
Compare
Figure 106 — Hash function
15.3 Symmetric key algorithms

15.3.1 General
Symmetric key algorithms (often called secret key algorithms) use a single key to both apply
protection and to remove or check the protection. For example, the key used to encrypt data is a
used to decrypt the encrypted data. This key must be kept secret if the data is to retain
cryptographic protection. Symmetric algorithms are used to provide confidentiality via encryption
an assurance of authenticity or integrity via authentication, or are used during key establishment.
Keys used for one purpose shall not be used for other purposes. (See NISI SP 800-57).
15.3.2 Encryption and decryption

NOTE The following text is quoted from NIST SP 800.21 sub-clause 3_3_1_
Encryption is used to provide confidentiality for data. The data to be protected is called plaint(
Encryption transforms the data into ciphertext. Ciphertext can be transformed back into plaint
using decryption. The approved algorithms for encryption and decryption algorithms are:
Advanced Encryption Standard (AES) and the Triple Data Encryption Algorithm (TDEA), TDEA
based on the Data Encryption Standard (DES), which is no longer approved for FedE
Government use except as a component of TDEA. Each of these algorithms operates on blot
(chunks) of data during an encryption or decryption operation. For this reason, these algorithms
commonly referred to as block cipher algorithms.
Plaintext data can be recovered from ciphertext only by using the same key that was used
encrypt the data. Unauthorized recipients of the ciphertext who know the cryptographic algoril
but do not have the correct key should not be able to decrypt the ciphertext. However, anyone v
has the key and the cryptographic algorithm can easily decrypt the ciphertext and obtain the orig
plaintext data.
Figure 107 depicts the encryption and decryption processes. The plaintext (p) and a key (K)
used by the encryption process to produce the ciphertext (C). To decrypt. the ciphertext (C) and
same key (K) are used by the decryption process to recover the plaintext (P).

0 Copyright 1997.2009 DLMS User Association
%,92-FUMEESOn
tawia. -
iftarACM!
iftcp-1.0-0.pre3.el....rpm es El 2020-12-08 Datatxt es SUBDLcom_the.pr....zip V The Princess Di....torrent Shaw all X

7F7 * < 298 / 310 > CI 671 I., F 4. AATTT * 0
Encryption Decryption
HG C
Figure 107 — Encryption and decryption

With symmetric key block cipher algorithms, the same plaintext block and key will always produce
the same ciphertext block. This property does not provide acceptable security. Therefore,
cryptographic modes of operation have been defined to address this problem (see 15.3.4).
15.3.3 Advanced Encryption Standard (AES)

NOTE The following text is quoted from NIST SP 800-21 sub-clause 3.3.1.3.
The Advanced Encryption Standard (AES) was developed as a replacement for DES and is the
preferred algorithm for new products. AES is specified in FIPS PUB 197. AES encrypts and
decrypts data in 128-bit blocks, using 128, 192 or 256 bit keys. All three key sizes are adequate.
NOTE The following text is quoted from RFC 5084.
AES offers a combination of security, performance, efficiency, ease of implementation, and
flexibility. Specifically, the algorithm performs well in both hardware and software across a wide
range of computing environments. Also, the very low memory requirements of the algorithm make it
very well suited for restricted-space environments.
15.3.4 Encryption Modes of Operation

NOTE The following text is quoted from NIST SP 800-21 sub-clause 3.3.1.4.
With a symmetric key block cipher algorithm, the same plaintext block will always encrypt to the
same ciphertext block when the same symmetric key is used. If the multiple blocks in a typical
message (data stream) are encrypted separately, an adversary could easily substitute individual
blocks, possibly without detection. Furthermore, certain kinds of data patterns in the plaintext, such
as repeated blocks, would be apparent in the ciphertext.
Cryptographic modes of operation have been defined to address this problem by combining the
basic cryptographic algorithm with variable initialization values (commonly known as initialization
vectors) and feedback rules for the information derived from the cryptographic operation.
NIST SP 800-38D specifies the Galois/Counter Mode (GCM), an algorithm for authenticated
encryption with associated data, and its specialization, GMAC, for generating a message
authentication code (MAC) on data that is not encrypted. GCM and GMAC are modes of operation
for an underlying approved symmetric key block cipher. See 9.2.4.8.
15.3.5 Message Authentication Code

15.3.5.1 General
NOTE The following text is quoted from NIST SP 800-21 sub-clause 3.3.2.
Message Authentication Codes (MACs) provide an assurance of authenticity and integrity. A MAC is
a cryptographic checksum on the data that is used to provide assurance that the data has not
changed or been altered and that the MAC was computed by the expected party (the sender).
Typically, MACs are used between two parties that share a secret key to authenticate information
exchanged between those parties.
Figure 108 depicts the use of message authentication codes (MACs).

5) Copyright 1997.2009 DLMS user Association

javascript;
iftop-1.0-0.pre3.el....rpm n El 2020-12-08 Datatxt es SUBDLcom_the.pr....zip E. The Princess Di...torrent n Shaw MI X

:=7F7 lk e a < 299 / 310 > E H .A#T7,- T, 6 7 *
MAC Generation MAC Verification

K K
I I
Generate —• MA C, Generate —111AC
MAC MAC i
2
I
*MAC,
Figure 108 - Message Authentication Codes (MACs)

A MAC (MAC1) is computed on data (M1) using a key (K). M1 and MAC1 are then saved
transmitted. At a later time, the authenticity of the retrieved or received data is checked by label
the retrieved or received data as M2 and computing a MAC (MAC2) on it using the same key (K)
the retrieved or received MAC (MAC1) is the same as the newly computed MAC (MAC2), then it (
be assumed that the retrieved or received data (M2) is the same as the original data (M1) (i.e.,
M2). The verifying party also knows who the sending party is because no one else knows the k(
Typically, MACs are used to detect data modifications that occur between the initial generation
the MAC and the verification of the received MAC. They do not detect errors that occur before
MAC is originally generated.
Message integrity is frequently provided using non-cryptographic techniques known as e

detection codes. However, these codes can be altered by an adversary to the adversary's ben(
The use of an approved cryptographic mechanism, such as a MAC, addresses this problem. Thal
the integrity provided by a MAC is based on the assumption that it is not possible to generat
MAC without knowing the cryptographic key. An adversary without knowledge of the key will
unable to modify data and then generate an authentic MAC on the modified data. It is theref
crucial that MAC keys be kept secret.
Two types of algorithms for computing a MAC have been approved for Federal government u
MAC algorithms that are based on block cipher algorithms, and MAC algorithms that are based
hash functions.
15.3.5.2 The Keyed-Hash Message Authentication Code (HMAC)

NOTE The following text is quoted from FIPS PUB 198.
The Keyed-Hash Message Authentication Code (HMAC) uses a cryptographic hash function
conjunction with a secret key. HMAC shall be used in combination with an approved cryptogr4
hash function. HMAC uses a secret key for the calculation and verification of the MACs. For detz
see FIPS PUB 198.
15.3.6 Key establishment

Symmetric key algorithms may be used to wrap (i.e., encrypt) keying material using a key-wrapp
key (also known as a key encrypting key). The wrapped keying material can then be stored
transmitted securely. Unwrapping the keying material requires the use of the same key-wrapp
key that was used during the original wrapping process.
Key wrapping differs from simple encryption in that the wrapping process includes an integ
feature. During the unwrapping process, this integrity feature detects accidental or intentio
modifications to the wrapped keying material.

iftop-1.0-0.pre3.el....rpm es El 2020-12-08 Datatxt es SLIBDLcom_the.pr....zip It The Princess Di....torrent " Shaw MI X

* C_:'7Zr4 < 390 / 310 > :: « A1 T * 0
15.4 Asymmetric key algorithms

15.4.1 Introduction
The use of asymmetric key algorithms for DLMS/COSEM is under consideration.
Asymmetric algorithms (often called public key algorithms) use two keys: a public key and a private
key, which are mathematically related to each other. The public key may be made public; the
private key must remain secret if the data is to retain its cryptographic protection. Even though
there is a relationship between the two keys, the private key cannot be determined from the public
key. Which key to be used to apply versus remove or check the protection depends on the service
to be provided. For example, a digital signature is computed using a private key_ and the signature
is verified using the public key; for those algorithms also capable of encryption 38 the encryption is ,
performed using the public key, and the decryption is performed using the private key.
Asymmetric algorithms are used primarily as data integrity, authentication, and non-repudiation
mechanisms (i.e., digital signatures), and for key establishment.
Some asymmetric algorithms use domain parameters, which are additional values necessary for the
operation of the cryptographic algorithm. These values are mathematically related to each other.
Domain parameters are usually public and are used by a community of users for a substantial
period of time.
The secure use of asymmetric algorithms requires that users obtain certain assurances:
• assurance of domain parameter validity provides confidence that the domain parameters are
mathematically correct;
• assurance of public key validity provides confidence that the public key appears to be a suitable key; and
• assurance of private key possession provides confidence that the party that is supposedly the owner of
the private key really has the key.
Some asymmetric algorithms may be used for multiple purposes (e.g., for both digital signatures
and key establishment). Keys used for one purpose shall not be used for other purposes.
15.4.2 Digital signatures

A digital signature is an electronic analogue of a written signature that can be used in proving to the
recipient or a third party that the message was signed by the originator la property known as non-
repudiation). Digital signatures may also be generated for stored data and programs so that the
integrity of the data and programs may be verified at a later time.
Digital signatures authenticate the integrity of the signed data and the identity of the signatory. A
digital signature is represented in a computer as a string of bits and is computed using a digital
signature algorithm that provides the capability to generate and verify signatures. Signature
generation uses a private key to generate a digital signature. Signature verification uses the public
key that corresponds to, but is not the same as, the private key to verify the signature. Each
signatory possesses a private and public key pair. Signature generation can be performed only by
the possessor of the signatory's private key. However, anyone can verify the signature by
employing the signatory's public key. The security of a digital signature system is dependent on
maintaining the secrecy of a signatory's private key. Therefore, users must guard against the
unauthorized acquisition of their private keys.
Not all public key algorithms are capable of multiple functions, e.g., generating digital signatures and encryption.

iftcp-1.0-0.pre3.el....rpm es El 2020-12-08 Datatxt " SUBDLcom_the.pr....zip " R The Princess Di....torrent Shaw all X
* < 301 1310 > 9 Q A# T T * 0
15.4.3 Key establishment

Two types of asymmetric key (i.e., public key) establishment are defined: key transport and 1
agreement. Approved key establishment schemes are specified in NIST SP 800 -
Recommendation on Key Establishment Schemes.
Key transport is the distribution of a key (and other keying material) from one party to another pa
The transported key is created by the sending party. The keying material is encrypted by
sending party and decrypted by the receiving party. The sending party encrypts the keying mate
using the receiving party's public key; the receiving party decrypts the received keying mate
using the associated private key.
Key agreement is the participation by both parties (i.e., the sending and receiving parties) in
creation of shared keying material. Each party has either one or two key pairs 39, and the public ki
are made known to the other party. The key pairs are used to compute a shared secret 4° val
which is then used with other information to derive keying material using a key derivation functi
Typically, a hash function (see ) is used during the key derivation process.
39 A key pair consists of a private key and its associated public key.
4° The shared secret is never transmitted from one party to the other.
DLMS User Association 2009-12-22 DLMS UA 1000 - 2 Ed. 7.0 30113


4 ,c, ipt:
iftop-1.0-0.pre3.el...rpm " El 2020-12-08 Data txt " SUBOLcorn_the.pr " The Princess a...torrent " Show MI X
TR ., j0 *i&Z < 392 / 310 > Q IR ••■ AATTT B -0 4 0 -
Bibliography
IEC 60050 300, International Electrotechnica! Vocabulary — Revision of Chapter 301, 302, 303 — Electrical
-
measurements and measuring instruments - Chapter 311: General terms relating to measurements Chapter
312: General terms relating to electrical measurements - Chapter 313: Types of electrical measuring
instrument - Chapter 314: Specific terms according to the type of instrument
IEC 62051:1999, Electricity metering — Glossary of terms
IEC/TR 62051-1:2004, Electricity metering — Data exchange for meter reading, tariff and load control —
Glossary of Terms - Part 1, Terms related to data exchange with metering equipment using DLMS/COSEM
IEC 62056 41:1998, Electricity metering — Data exchange for meter reading, tariff and load control — Part 41:
-
Data exchange using wide area networks: Public switched telephone network (PSTN) with LINK-i- protocol
IEC/TS 62056 51:1998, Electricity metering — Data exchange for meter reading, tariff and load control — Part
-
51: Application layer protocols
IEC/TS 62056 52:1998, Electricity metering — Data exchange for meter reading, tariff and load control — Part
-
52: Communication protocols management distribution line message specification (DLMS) server
ISO/IEC 9545:1994, Information technology - Open Systems Interconnection — Application layer structure
ISO/IEC 10731:1994, Information technology - Open Systems Interconnection - Basic Reference Mode! -
Conventions for the definition of OSI services
ISO 2110:1989, Information technology — Data communication — 25-pole DTE/DCE interface connector and
contact number assignments
ITU T V.24:1996, List of definitions for interchange circuits between data terminal equipment (DTE) and data
-
circuit-terminating equipment (DCE)
ITU T V.25:1996, Automatic answering equipment and general procedures for automatic calling equipment
-
on the general switched telephone network
ITU T V,25bis:1996, Synchronous and asynchronous automatic dialling procedures on switched networks
-
ITU T V.28:1993, Electrical characteristics for unbalanced double-current interchange circuits

-
ITU T X.211:1995, Information technology — Open Systems Interconnection — Physical service definition
-
IEEE 802.1 ae;2006, IEEE Standard for Local and metropolitan area networks Media Access
Control (MAC) Security
IEEE 802.15.4:2006, Information technology — Telecommunications and information exchange

between systems — Local and metropolitan area networks — Specific requirements — Part 15.4:
Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications
The Galois/Counter Mode of Operation (GCM)
David A. McGrew, Cisco Systems, Inc. 170, West Tasman Drive, San Jose, CA 95032,
mcgrew@cisco.com
John Viega, Secure Software, 4100 Lafayette Center Drive, Suite 100. Chantilly, VA 20151,
viega@securesoftware.com
May 31, 2005
RFC 0791 Internet Protocol

-
Author: J. Pastel
Date: Sep-01-1981
Also: STD0005
CP Copyright 1997.2009 DLMS User Association

javascript;
iftop-1.0-0.pre3.el....rpm El 2020-12-08 Datatxt SIADLcorri_the.pr....zip w The Princess Di....torrent Show all X

*-717. < 303 / 310 > Q Q 8 ► . AATT--r, 0_00 *0
Updated by: RFC1349

Obsoletes: RFC0760
RFC 0792 - Internet Control Message Protocol

Author: J. Postel
Date: Sep-01-1981
Also: STD0005
Updated by: RFC0950
Obsoletes: RFC0777
RFC 0793 - Transmission Control Protocol

Author: J. Postel
Date: Sep-01-1981
Also: STD0007
Updated by: RFC3168
RFC 0826 - Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit
Ethernet address for transmission on Ethernet hardware
Author: D.C. Plummer
Date: Nov-01-1982
Also: STD0037
RFC 0894 - Standard for the transmission of IP datagrams over Ethernet networks
Author: C. Hornig
Date: Apr-01-1984
Also: STD0041
RFC 0919 - Broadcasting Internet Datagrams

Author: J.C, Mogul
Date: Oct-01-1984
Also: STD0005
RFC 0922 - Broadcasting Internet datagrams in the presence of subnets

Author: J.C. Mogul
Date: Oct-01-1984
Also: STD0005
RFC 0950 - Internet Standard Subnetting Procedure

Authors, J.C. Mogul, J, Poste!
Date: Aug-01-1985
Also: STD0005
Updates: RFC0792
RFC 1042 - Standard for the transmission of IP datagrams over IEEE 602 networks
Authors: J. Pastel, J.K. Reynolds
Date: Feb-01-1988
Also: STD0043
Obsoletes: RFC0948
RFC 1112 - Host extensions for IP multicasting

Author: S. E. Deering
Date: Aug-01-1989
Also: STD0005
Updated by: RFC2236
Obsoletes: RFC0968, RFC1054
RFC 2104:2004, HMAC: Keyed-Hashing for Message Authentication
RFC 3268:2002, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Secu
(TLS)
RFC 4106:2005, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Paylc
(ESP)
CP Copyright 1997-2009 DINS User Association
" I 2020-12-08 Datatxt n SIADLcorri_the.pr....zip •• a" The Princess Di....torrent " Shaw MI X
=7E.7
: * ItM < 304 / 310 > Q„ Hik **A AT -1, - r j Doi% A ei
RFC 4308:2005, Cryptographic Suites for IPsec

RFC 4835:2007, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload
(ESP) and Authentication Header (AH)
RFC 0768 User Datagram Protocol
-
Author: J. Poste!
Date: Aug-28-1980
Also: STD0006

@ Copyright 1997.2009 DLMS User Association
iftop-1.0-0.pre3.el....rpm ■••• Q 2020-12-08 Datatct " SUBOLcom_thepr.,.# I The Princess Di....torrent Shaw all X
CM ?7W * < =c5 -0 7 A ,T I/ 6-0 II A ct
Index
16-bit FCS computation method 107 Application association, non-graceful release
3-layer, connection-oriented, HDLC based profile . 215 Application association, pre-established 20,
AA, confirmed 114 Application association, release 175,
M, pre-established 114 Application association, unconfirmed
AA, unconfirmed 114 Application context
AARQ and AARE encoding examples 251 Application context name 114, 140, 168, 169,
A-ASSOCIATE service 114, 138 Application Control Service Element
Abort sequence 94 Application layer
Abstract syntax 119, 242 Application process
Abstract syntax, COSEM APDUs 197 Application process identification
Access right 120 Application Programming Interface
Access_Selection_Parameters 147. 149 Application_Addresses parameter
ACSE functional units 167 A-RELEASE
ACSE procedures 118 A-RELEASE service 114,
ACSE protocol version 140, 174 ASN.1
ACSE requirements 168 Association 1.14
ACSE services and APDUs 167 Association SN
ACTION service 116, 151, 185 Attribute
ACTION.confirm 153, 154 Attribute _O referencing
ACTION.indication 153 Authenticated decryption
ACTION.request 153 Authenticated encryption 128,
ACTION.response 153 Authentication 118, 124, 296,
Action-Request 153 Authentication context
ACTION-REQUEST-FIRST-BLOCK 152, 186, 189, 192 Authentication key 124, 129, 131, 132,
ACTION-REQUEST-LAST-BLOCK 152, 186, 189. 193 Authentication mechanism name 114,
ACTION-REQUEST-NEXT 152, 186, 188 Authentication tag 122, 124, 125, 129, 130, 131, 134,
Action-Request-Next-Pblock 186 Authentication value
Action-Request-Normal 186 authentication mechanism id(5)
ACTION-REQUEST-NORMAL 152, 186, 188, 192, 195 Authenticity
ACTION-REQUEST-ONE-BLOCK 152, 186, 189, 193 Authorization
Action-Request-Wrth-First-Pblock 186 Automatic
Action-Request-With-list 186 A-XDR encoding 35,
ACTION-REQUEST-WITH-LIST 152, 186, 189, 193, 195 BER encoding
ACTION-REQUEST-WITH-LIST-AND-FIRST-BLOCK152, 186, Block cipher
189, 193 Block cipher algorithm
Action-Request-With-List-And-With-Erist-Pbtodc 186 Block cipher key 124, 129, 130,
Action - Request-With-Pblock 186 Block_Number 147, 150, 153, 158, 161, 181,
Action-Response 153, 154 Block_Number Access 155, 157,
ACTION-RESPONSE-LAST-BLOCK 152, 186, 189 Broadcast 126,
ACTION-RESPONSE-NEXT 152, 186, 189, 193 Broadcasting 248,
Action-Response-Next-Pblock 186 Busy
Action-Response-Normal 186 Calling authentication value 120, 122,
ACTION-RESPONSE-NORMAL 152, 186, 189, 193 CALLING Physical Device Address 89,
ACTION-RESPONSE-ONE-BLOCK 152, 186 Central DCS
ACTION-RESPONSE-ONE-ONE-BLOCK . 189 Challenge
Action-Response-With-List 186 Check Initiator Phase 237, 239,
ACTION-RESPONSE-WITH-LIST 152, 186, 189, 193 CIASE L-SAP
Action-Response-With-Pblock 186 Ciphered ADPUs
Active HDLC channel state 94 Ciphered xDLMS APDU
Active initiator 227, 233 Ciphertext 125, 129, 130,
active OPEN 66 ClearAlarm
Additional authenticated data 130, 131 ClearAlarm service
Additional data 128 Client 18,
Address lengths, inopportune 90 Client management process
Addressing capability (wPort) 48 Client management process address
Advanced Encryption Standard 128, 297, 298 Client side layer management services
AES-128 key wrap algorithm 124, 127 Client SN_MAPPER
AL service, non-client/server type 116 Client system title
AL services, AA establishment and release 114 client/server paradigm
AL services, client/sewer type 116 Client LLC Address
AL services, data transfer 115 Client_MAC_Address
AL, management services 163 Client_Max_Receive_PDU_Size
ALARM state -244 client system title
Alarm Descriptor 236 client-max-receive-pdu-size
All Physical 243 Collision
All-configured 243 Command/response frame rejection
All-L-SAP 243 Communication environment
All-station (Broadcast) address 62, 89 Communication profile
Always repeater 235 Communication profile specific parameters
Application association 20, 113, 142 Communication profile structure
Application association, confirmed 171 Concentrator 126,
Application association, establishment 171. 245, 248 Confidentiality 119, 126, 296,
Application association, graceful release 175 Configuration Initiation Application Service Element

iftop-1.0-0.pre3.el....rpm es El 2020-12-03 Dataal es 3 SUBDLcom_the.pr....zip V The Princess Di....torrent Shaw all X

A T 0 f& 4 0
ConfirmedServiceError 124, 159, 161, 179 Digital signature 300

Conformance block 116, 178 Direct local connection 42
Conformance testing 26 Direct local data exchange 42
Connection less 19 DISC command 97
Connection-oriented 19 DISC frame 79, 92
Control field 87 Discover service 231
Control function 113, 165 DiscoverReport 231
Copyright 7 DL-CONNECT service 73
COSEM AL 23, 215 DL-Connect services 230
COSEM AL, ASO services 114 DL-CONNECT.confirrn 76
COSEM AL, layer management services 118 DL-CONNECT. indication 75
COSEM AL, protocol specification 118 DL-CONNECT.request 74
COSEM AL, service specification 136 DL-CONNECT.response 75
COSEM AL, services 114 DL-DATA service 81
COSEM AL, structure 113 DL-Data services 230
COSEM application context 116, 124 DL-Data services, connectionless 230
COSEM application context name 169 DL-Data services, connection-oriented 230
COSEM application layer 47, 113 DL-DATA.confirrn 84
COSEM application layer, protocol specification 165 DL-DATA.i nd icati on 83
COSEM Authentication mechanism name 170 DL-DATA.request 82
COSEM client/server type services 116 DL-DISCONNECT service 77
COSEM Glossary of Terms 12 DL-DISCONNECT.confirm 80
COSEM interlace classes 22 DL-DI SOON N ECT.i nd ication 79
COSEM interface object 113. 115 DL-DISCONNECT.request 78
COSEM logical device address 217 DL-DISCONNECT.response 80
COSEM physical device address 217 DL-GET_VALUE.confirrn 111
COSEM transport layer 23, 47 DL-GET_VALLI E.requ est 111
COSEM transport layer, state machine 53 DL-INITIALIZE.confirm 111
COSEM transport layer, TCP based 53 DL-INITIALIZE. request 110
COSEM transport layer, TCP based, protocol specification .. 61 DL-LM_EVENT. indi cation 112
COSEM transport layer, TCP based, service specification 54 DLMS conformance 141
COSEM transport layer, UDP based 48 DLMS version number 141
COSEM transport layer, UDP based, protocol specification ..51 DLMS/COSEM based client 23
COSEM transport layer, UDP based, service specification ...49 DLMS/COSEM conformance test process 12
COSEM Application COntext Name 169 DL-Reply services 230
COSEM_Attribute_Descriptor 147, 149 DL-SET_VALUE.confirrn 112
COS EM_Au thentication_Mechanism_Narne 170 DL-SET_VALUE.request 112
COSEM_Class_Id 147, 149, 152 DL-Update-Reply services 230
COS EM_Method_Descriptor 152 DM frame 92
COSEM_Method_ld 152 DM response 92, 95. 97, 104
COSEM_Object_Attribute_ld 147, 149 Dynamic repeater 235
COSEM_Objectinstance_ld 147, 149, 152 Eavesdropping 120
COSEM_on_IP 221 Encryption 124, 297
COSEM-ABORT service 114, 144 Error detection 53
COSEM-OPEN service 114, 121, 138 Ethernet 23, 24, 221, 222, 303
COSEM-OPEN service invocations, repeated 174 Ethernet LAN 24
COSEM-RELEASE service 114, 142 Event notification 117
Counter mode 128 EventNotitication service 117, 154, 247, 250
Cross-talk 237 EventNotitication service, 3-layer, CO, HDLC based profile 218
Cryptographic keys 125 EventNotitication service, TCP-UDP/IP based profile 226
Cryptography 296 Exception Response 124, 179, 246
Data access security 119 Failuretype 140
Data collection system ............................. Fast Frame Check Sequence (FCS) Implementation 107
Data Communication Equipment 27 Fast Synchronization 237, 239
Data integrity 296, 300 FCS calculation 107
Data length 48, 52 FCS error 93, 105
Data link connection, disconnecting 77 FCS table generator 109
Data link connection, setting up 73 fin segment 64
Data link layer 23, 46, 228 Fixed field 132
Data link layer using HDLC 71 Flag field 87
Data link layer, management services 110 Flow control 53
Data link, disconnection 97 FORGOTTEN 242
Data Terminal Equipment 27 Format type sub-field 87
Data transfer 81 Forward cipher function 129
Data transfer services, protocol 178 Frame Check Sequence (FCS) 88
Data transport security 119 Frame counter 125
Data_Access_Error 158, 161 Frame format field 87
Data_Access_Result 150 Frame length sub-field 87
Data_Length 50 Frame reject response (FRMR) 93
DataBtock_G 147, 181,182 FRMR response 93, 105
DataBlock_SA 150, 152, 184 FTP 23
Decryption 297 Full-duplex 53
Dedicated key 126, 127, 141 Galois/Counter Mode 124, 128, 298
Denial-of-service attack 143, 247 GET service 116, 146, 180
Destination address 87, 90 GET-confirm 148
Destination wPort 52 GET.inclication 148
Deterministic construction 132 GET.request 148

iftop-1.0-0.pre3.el....rpm M 2020-12-08 Dataal es 3 SUBDLcom_the.pr....zip V The Princess Di....torrent Shaw all X

* 3:D7 Q Q A ...*T 6 a3 a * •
GET.response 148 Intelligent Search Initiator process 231,

Get_Data_Result 147 Intel-connectivity
Get-Request ..148 interface model
Get-Request-Next 180 Inter-frame time-out
GET-REQUEST-NEXT 147, 180, 182, 188 Internet Protocol
Get-Request-Normal 180 Inter-octet time-out
GET-REQUEST-NORMAL 147, 180, 188 Interoperability
Get-Request-With-List 180 Intrinsic security
GET-REQUEST-WITH-LIST 147, 180, 188 Invalid Frame
Get-Response 148 Invocation field 129, 132,
GET-RESPONSE-LAST-BLOCK 147, 180, 188 Invoke Id 146, 149, 151, 182, 185,
Get-Response-Normal 180 Invoke Id parameter
GET-RESPONSE-NORMAL 147, 180, 188 IPv4 network
GET-RESPONSE-ONE-BLOCK 147, 180, 181, 188 Key agreement
Get - Response - With-Databtodc 180 Key encrypting keys
Get - Response - With-List 180 Key establishment 299,
GET-RESPONSE-WITH-LIST 147, 180. 188 Key management
Global key 126, 127 Key transport. .
Global unicast encryption key 134 Key wrapping key 126,
global_key_transfer 127 Key_set 125,
GPRS 222 Keyed-Hash Message Authentication Code
Half-duplex 27 Last_Block . 147, 150, 153, 158, 161, 181,
Hash value 296 LLC addresses
Hayes commands 37 LLC PDU format
HCS error 105 LLC sublayer.. 71,
HDLC address 82 LLC sublayer. connectionless
HDLC address field structure 88 LLC sublayer, HDLC based
HDLC addresses, special and reserved 89 LLC sublayer, protocol specification
HDLC based data link layer 229 LLC sublayer, state transition table
HDLC channel operation 95 LN referencing
HDLC channel states 94 LN/SN data transfer service mapping
HDLC extended addressing 88 Local_IP_Address
HDLC frame 87 Local_or_Remote 140,
HDLC frame formal type 3 71, 87 Lecal_TCP_Port
HDLC non-operational modes 95 Local_UDP_Part
HDLC operational modes 95 Lccal_wPort
HDLC parameter negotiation 95 Logical device 21,
HDLC protocol 230 Logical Link Control
HDLC, CALLING device physical address 103 Logical Name
HDLC, command and response frames 91 Logical name referencing
HDLC, elements of the procedures 93 Long messages 248,
HDLC, exception recovery 104 Long service parameters
HDLC, exchange of information frames 98 Low level security
HDLC, exchanging data 97 Lower HDLC address
HDLC, selected repertoire 91 Lowest level security
HDLC, sequence number.. 98 MAC addresses
HDLC, translerring long MSDUs from the server to the client99 MAC addressing
Header Check Sequence (HCS) 88 MAC MU
High level security 120, 134 MAC sublayer 71,
HIS secret 134 MAC sublayer, data communication
HTTP 23 MAC sublayer, physical layer services used by
I frame, command and response 91 MAC sublayer, protocol specification
I_COMPLETE 83, 97 MAC sublayer, state transition diagram
l_FIRST_FRAGMENT 83. 98, 99 MA-CONNECT service
(_FRAGMENT 83, 98. 99 MA-CONNECT.conlirm
I_LAST_FRAGMENT 83. 98. 99 MA-CONNECTindicat on
Identification and addressing scheme 214, 215 MA-CONNECT.request
Identification protocol specification 35 MA-CONNECT.response
Identification service 34, 219 MA-DATA service
I DEN TIFY.request 34 MA-Data services
I DE NTI FY. response 34 MA-DATA.confirm
Identifying service invocations 117 MA-DATA.indication
Idle HDLC channel state 95 MA-DATA.request
IDLE sub-state 65 MA-DISCONNECT service
IEC 1107 26 MA-DISCONNECT.confirm
Implementation information 141, 168 MA-DISCONNECT.indication
Inactivity time-out 105 MA-D1SCONNECT.request
I lo rmation field 88 MA-DISCONNECT.response
Info rmationReport service 117, 163, 196 Management logical device
In fo rmationReportrequest 196 Management logical device address 62
I nto rmationReportRequest 196 Manufacturer ID
Initial credit 233 Manufacturing number
Initialization vector 124, 129, 130, 132. 298 Master key
Initiator 63, 227, 228, 243 Master( Slave operation on the multi-drop bus
Initiator L-SAP 243 MA-Sync.indication
Integrity 119, 297 Max_Adr MAC
Intellectual Property Rights 7 MAX_NB_OF_RETRIES 95, 97,

iftop-1.0-0.pre3.el....rpm es El 2020-12-08 Dataal SUBDLcom_the.pr....zip V The Princess Di...torrent " Shaw all X
*i&Z < 308 /310 > ir 4. A .0 T -0 A 0
Maximum information field length 106 Physical layer, protocol specification 32

MAXIMUM_INFORMATION_FIELD_LENGTH 96 Physical layer, service definitions 29
M-Bus 25 Physical layer, service specification 28
MD5 algorithm 121 Physical link, disconnecting 85
Mechanism name 168 Physical link, setting up 84
Medium Access Control 228 Ping Service 232
Message Authentication Code 298 PING service 231
Message digest 296 Ping-no-response 233
Message integrity 126, 299 Ping-system-title-nok 233
Message replay 120 Plaintexl 125, 129, 130, 131, 297
Message source 126 Point to multipoint 27
Messaging 12 Point to point 27
Meter installation 26 Poll/final bit 91
METERING HDLC protocol 42 Port number 23
Method 12 Positive Acknowledgement with Retransmission 53, 65
Migration 26 Pre-established application association 142
Mode C 26 Presentation layer 114
Mode of Operation 298 Priority 146, 149, 151, 182, 185, 186
Modelling 12 Priority parameter 117
Multi- and broadcasting using HDLC 100 Private key 126, 300
Multi- and broadcasting using UDP 50 Profile specific service parameters 217
Multi-drop configuration, 3-layer, CO, HDLC based profile-.220 Programming mode 43
Multi-drop configuration, TCP-UDPIIP based profile 226 proposed-conformance 173
Multiple references 117 proposed-dims-version-number.. 173
N(S) sequence error 105 Protocol connection parameters 140
Nb_Tslot_For_New 234 Protocol identification service 21
Never repeater 235 Protocol mode E 42
NEW 243 Protocol mode E, flow diagram 44
NEW and LOCKED state 239, 241, 242 Protocol version 168
NEW and UNLOCKED state 238. 239, 240, 242 Protocol_Conneclion_Parameters 217, 224
New system 227 P-Sync 228
New system title 227 Public client 26, 89
NISI 119 Public client address 62
No TCP Connection 65 Public key 126, 300
NO-BODY 240, 243 Raw_Data 147, 150, 153, 158, 184
Non-basic frame format transparency .71 Read service 116, 156, 188
Nonce 129, 130 Read. confirm 159
Non-repudiation 296, 300 R ead. ndicati on 159
No-station address 62, 89 Read. requ est 159
NRM 93 Read. respon se 159
NRM, Normal Response Mode .97 Read_Data_Block_Access 155, 157, 158
Object model 18 Readout mode 43
Order of bit and octet transmission .94 ReadRequest 159, 188
OS1-s tyle services ReadResponse 159, 188, 189
P/F bit 90 Real-world IP networks 226
Pa ram eterized_Access 155, 157, 160, 162 Reason 169
Passive opening .63 Receive not ready 92
P-Data services 228 Receive ready 92
PH Data transfer services 28 Reception Threshold 234
PH Layer management services 28 Reference model 228
PH-ABORT 28 Referencing method 113
PH-ABORT service 31 Register service 231
PH-AB ORT. conf rm 31, 46 REGISTERED and LOCKED state 241
PH-ABORT.indication 31, 41, 46 REGISTERED and UNLOCKED state 241
PH-ABORT.request 31, 46 Registered COSEM names 169
PH-ABORT.request izonffun 41 REGISTERED state 241, 242
PH-CONNECT 28 Registered system 227
PH-CONNECT service 29 Remote_IP_Address 50
PH-CONNECT.confirrn 30, 38, 46 Remote_TCP_Port 55
PH-CONNECT.indication 29, 39, 46 Remote UDP Port 50
PH-CONNECT.request 29, 37, 46 Remote_wPort 50
PH-DATA 28 Repeater status 233, 235, 239
PH-DATA service 30 RepeaterCall 231
PH-DATA. indicatio n 31 RepeaterCall service.. 233
PH-DATA. mill ue st 30 reply to HLS authentication 122
PH-DATA.request / indication 40 Reporting system 227
PhL connection establishment/release services 28 Request_Type 146, 149, 151
PH-Layer service primitives 37, 46 Reserved wrapper port numbers 53, 62
Phyiscal layer, data communications 37 reset_new_not_synchronized 242
Physical connection, setting up 33 Responder 63, 228
Physical device 21 Responding-AP-title 173
Physical layer 23, 45, 215, 228 Response time-out 104
Physical layer operation, procedures 32 Response time-out (TO_WAIT_RESP) 105
Physical layer Protocol Data Unit 32 Response_Type 146, 149
Physical layer services 27, 28 response-allowed 171, 173, 174
Physical layer services, message exchanges 37 Response-allowed 246
Physical layer, disconnection 37 Result 140, 168, 181

Cr Copyright 1997.2009 DLMS User Association
5=gtHAAi*E, %41 -FaagE,E

5E*, Auggia tt...41m3m/Tar, p_IhrAerta!
M 2020-12-08 Dataal es 3 SUBDLcom_the.pr...2ip ••• V The Princess a...torrent " Shaw all X
PEI .,767 < 309 ( -3:0 > 0, A 1' T T 1 6 =0 1R 41 0
DLMS User Association, GOSEM Architecture and Protocols, Seventh Edition
Result H 159, 161 SN_MAPPER ASE 159, 161,

Result (+) 158.161 SNRM command 95,
Result Source-Diagnostic 168 SNRM frame 75, 92,
Revision History 8 Source address 87
RLRE APDU 142 Source UDP
RLR0 APOU 142 Source wPort
RNR frame 92 Special addresses
RR frame 92, 102, 104 StarVslop transmission
Search Initiator Phase 237, 238, 242 Sub_Tslot position
search_initiator_threshold 237 Sub-slot
search_initiator_time_out 237 Supporting layer services
Secret 120 Supporting layer services and service mapping
Secret key 121 Symmetric key
Security attributes 123 Symmetric key algorithm
Security context 123 Symmetric key block cipher
Security control 125, 131, 145 Synchronization
Security header 124, 125, 131 synchronization locked
Security material 122 System integration
Security mechanism name 122, 140 System title
Security policy 123 System_Title_Server
Security setup 127 TCP Connected
Security suite 124 TCP connection
Security_Options 122, 145 TCP connection abort 64
Security_Status 122, 145 TCP connection closing 53
Segmentation 99, 230 TCP connection establishment 53
Segmentation bit 87, 99 TCP connection establishment by the server
Selective access 117 TCP connection manager process 48
SEND() function 50 TCP data communication
SEND/RECEIVE state 65 TCP disconnection
Sender ACSE requirements 173 TCP packets .
Sequence numbers 66, 91 TCP-ABORT service
Server 18, 228 TCP-ABORT.indication
Server system title 173 TCP-CONNECT
Serve r_LLC_Address 217 TCP-CONNECT.confirm
Server_Max_Receive PDU Size 141 TCP-CONNECT.indication
server_system_title 133 TOP-CONNECT.request.
Service Access Point 23 TCP-CONNECT.response
Service mapping 216 TCP-DATA service 59
Service_Class 146, 149, 151, 246 TCP-DATA services
Service_Class == Unconfirmed 142 TCP-DATA.confirm
Service_Class parameter 141 TCP-DATA indicatio n
Set normal response mode 92 TCP-DATA.request
SET service 116, 148, 183 TCP-DISCONNECT services
SET.conf inn 150 TCP-DISCONNECT.confirm
SET.indication 150 TCP-DISCONNECT.indication
SET.request 150 TCP-DISCONNECT.request
SET.response 150 TCP-DISCONNECT.response
SetMapperTablesseques1 163 TCP-UDP/IP based communication profile
Set-Request 150 Three-way handshake 63
SET-REQUEST-FIRST-BLOCK 149, 183, 191 lime out not addressed
SET-REQUEST-FIRST-BLOCK-WITH-LIST149, 150, 183, 192 Timeslot
SET-REQUEST-LAST-BLOCK 149, 183, 192 Transfer syntax
Set-Request-Normal 183 Transmission Control Protocol 47
SET-REQUEST-NORMAL 149, 150, 183, 191, 195 Transmission order and characteristics
SET-REQUEST-ONE-BLOCK 149, 183, 191 Transparency
Set-Hequest-With-Datablock 183 Transporting
SET-REQUEST-WITH-FIRST-BLOCK 150 Transporting long messages, 3-layer, CO, I-IDLC based prc
Set-Request-With-First-Datablock 183
Set-Request-With-List 183 Transporting long messages. TCP-UDP/IP based profile ...
SET-REQUEST-WITH-LIST 149, 150, 183, 192, 195 Trigger EventNotification Sending service
Set-Request-With-List-And-MM-First-Datablock 183 TnggerEventNotificationSending
Set-Response 150 TriggerEventNotificationSending service
SET-RESPONSE-ACK-BLOCK ..... ,,,,, ..... ....149, 183, 192 Two-way aftemate data transfer 71
Set-Response-Datablock 183 UA frame 76
SET-RESPONSE-LAST-BLOCK 149, 183, 192 UA response 92, 95, 97,
SET - RESPONSE-LAST- BLOCK -WITH-LIST 149, 183, 192 UDP Datagram
Set-Response-Last-Datablock 183 UDP-DATA service
Set-Response-Normal _183 UDP-DATA.confirm
SET-RESPONSE-NORMAL 149, 183, 192 UDP-DATA.indication
Set-Response-With-List 183 UDP-DATA.request
SET-RESPONSE-WITH-LIST 149, 183, 192 Ul frame 90, 98, 100, 101,
Setting up the data link 95 UI frame, sending from the server to the client
5-FSK PLC environment 133 UNC basic repertoire
SHA-1 algorithm 121 UncontirrnedWrite service 116, 161,
Short Name 113 UnconfirmedWrite.indication
Short name referencing 21 UnconfirmedWrite.request
SN referencing 116 UnconfirmedWriteRequest

Q Copyright 1997.2009 DLMS User Association

jevascript;
El 2020-12-03 Dataal es 3 SUBDLcom_the.pr....zip V The Princess Di....torrent " Shaw all X

Q.4;i:Ct A.ATTT./ 6 7 4 i 0
Unicast 126 Wrapper 48

Unnumbered information (UI) command and response 93 Wrapper header 52
Upper HDLC address 88 Wrapper port 23
User Datagram Protocol 47, 48 Wrapper protocol data unit 51, 61
User information 141, 169 Wrapper sublayer 4-8, 51, 61, 222
User Information 168 Wrapper sublayer, slate transition diagram 65
V(R) 93 Write service 116, 159, 191
V(S) 93 Write. confi rrn 161
Valid wPort numbers 51 Write. i nd icat on 161
Variable Access Specification 155 Write-request 161
Variable_Access_Specification 157 Write.response 161
Variable_Name 155, 157, 160, 162 Write Data Block Access 155, 160
Variable-Access - Specification 157, 160, 162 WriteRegu est 161, 191
Virtual circuit 53 WriteRespon se 161, 192
Wide Area Network 222 xDLMS context 114
Window size 106 xDLMS InitiateRequest 127
Window size considerations 99 xDLMS InitiateResponse 127
WINDOW_SIZE 96 xDLMS procedures 118
wPort 222 xDLMS service element 20
wPort number 225 xDLMS_ASE 18,113
DLMS User Association [2009-12-22 DLMS UA 1000-2 Ed. 7.0 0 310/310

rg) Copyright 1997.2009 DLMS User Association
%42-FaA7E,E5On
Aumia Mlitaaere.!
iftop-1.0-0.pre3.el....rpm M 2020-12-08 Dataal SUBDLcom_the.pr....zip V The Princess Di....torrent Shaw all X

Green Book 7ed

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Green Book 7ed

Uploaded by

Copyright:

Available Formats

OILY'S _3E' ASS3CiatiCAL C.OSEM Archilisokre.airodi Protocols.

9. COSEM application layer

COSEM client COSEM serer

5:10W 'Y MTN $41EFIM Arm"

r•ue 601 - The 301.4:13.te 01 Pe COSEPA ACIPFCARIrk layreft

131-11$ User fia5ocia1fon 2009-t2-22 I DIMS UA 1000-2 Ed_ 7.0 I

The LOSE All AL Fierlorms also some iunctions e1

9.1.2 COSEIVI application layer services

• Ppplication asscdiation establishment arKI release;

in1ormation in 1ransi1. It does nol rely on the AC.S. A ABOFIT service. -

9.1.2.3 Services provided for data transfer

The additional data Eyries are spindled in 9.5.

Taltie 12 — Clarification of the moaning or PEW size For DLAISCOSEM

Page 161. Table 3 of MC 61231-1-11:

rtEIgGaIR100 M. PIZH_I 6 12113 .erwer Mar Flirg@hre POLL' 81ze

Naga tp3 52" paragraph of I EC I$1314.1.41:

P sap It paragraph of 'n613344-11:

9.1.2.3.2 Clierrtisorver and non-clientOserver typo services

DLIVIS User Aesiodiallign 120Q9-12-22 DLIAS UA 1000-2 Ed. 7.0 simo

9_1_2_3_3 ReterenO ingl rhelhed5 and SierviCe mapping

reel hod and the tervite set Supported by the server_

9_11_2..3_4 Confirmed and unconfirmed serViCeS

9_11_2_3_5 COSEill client. server lype services

DLMS User Asscciaton I 2003-12-22 Dl UA 1000-2 Ed_ 7.0

9.1.2.3.6 Services for event notification

▪ with IN referencing the EventNotification service, see 9.3.9:

This feature is available only with LN referencing.

9.1.2.3.10 Multiple references

9.1.2.3.11 Attribute . 0 referencing

1 DLMS User Association 2009.12-22 DLMS UA 1000-2 Ed. 7.0 I

9.1.2.3.12 Transferring long service parameters

9.1.2.4 Layer management services

9.1.2.5 Summary of COSEM application layer services

COSEM client COSEM server

Figure 61 — Summary of COSEM AL services

9.1.3 COSEM application layer protocols

DLMS User Association 2009.12-22 DLMS LA 1000 2 Ed. 7.0 - 118.1310

9.2 Information security in DLMS/COSEM

DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 119;310

For an overview of cryptography, see 15.

9.2.3 Data access security

• Lowest level security (no security);

9.2.3.2 Lowest level security (no security)

9.2.3.3 Low Level Security (LLS)

Client Server Ghent Server

Assn_ release request (SID. CID) M.

I I I Assn. release request {SID. CID) I

I I I Assn. release response (CID. SID) I

Figure 62 — LLS and HLS authentication

DLMS User Association 2009-12-22 DLMS UA 1000 2 Ed. 7.0 - 121/310

9.2.4 Data transport security

For COSEM service definitions, see 9.3.

DLMS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 122:310

COSEM Client Application Process COSEM Server Application Process

COSEM Client Application Layer COSEM Server Application Layer

Security ciphering • Security Ciphering

Lower protocol layers Lower protocol layers

Figure 63— Data transport security in DLMS. COSEM

9.2.4.2 Security context

9.2.4.3 Security policy

• security is not imposed;

DL MS User Association 2009-12-22 DLMS UA 1000-2 Ed. 7.0 II 123/310

9.2.4.4 Security suite

Table 13 — Security suites