Protocol Specification For Interfacing To Data Communication Networks

1
1
2
3
4
5
6 ANSI Std C12.22-200x
7
8
9
10
11
12
13
14
15
16 Protocol Specification for
17 Interfacing to Data Communication Networks
18
19
20
21
22
23
24
25
26
27
28
29 Copyright © 1997 by the National Electrical Manufacturers Association
30 1300 North 17th Street, Suite 1847
31 Rosslyn, VA 22209, USA
32 All rights reserved
33
34
35
36
37
38 This is an unapproved draft of a proposed ANSI Standard, subject to change.
39 Permission is hereby granted for ANSI Standards Committee participants to
40 reproduce this document for purposes of ANSI standardization activities. Use
41 of information contained in this unapproved draft is at your own risk.
42
43
44
45
46
47
48
49 Modified May 10, 2005
50
51 Standard Version 0.0
52
2
53
54 Table of contents
55
56
571 Introduction...............................................................5
582 Scope......................................................................5
593 References.................................................................6
60 4 Normative...............................................................6
61 5 Others..................................................................6
626 Definitions and syntax.....................................................6
63 7 Definitions.............................................................6
64 8 Document syntax........................................................12
65 9 Table syntax...........................................................13
6610 Reference topology.......................................................13
6711 C12.22 Node to C12.22 Network Segment details............................15
68 12 C12.22 Node to C12.22 Network Segment Reference.......................15
69 13 Data order............................................................15
70 14 Layer 7 - Application layer...........................................17
71 15 Data Structure - Utility Industry Data Tables........................17
72 16 Protocol Specification for Electric Metering (PSEM)..................17
73 17 Request Codes.......................................................18
74 18 Response Codes......................................................18
75 19 Time-out ...........................................................21
76 20 Session Time-out..................................................21
77 21 Application Layer Response Time-out...............................21
78 22 Services ...........................................................22
79 23 Identification service............................................22
80 24 Read Service......................................................25
81 25 Write Service.....................................................27
82 26 Logon Service.....................................................28
83 27 Security Service..................................................30
84 28 Logoff Service....................................................30
85 29 Terminate Service.................................................32
86 30 Disconnect Service................................................34
87 31 Wait Service......................................................36
88 32 Registration Service..............................................37
89 33 De-registration Service...........................................41
90 34 Resolve Service...................................................41
91 35 Trace Service.....................................................42
92 36 Service sequence state control......................................43
93 37 Partial Table access using index/element-count Method...............45
94 38 Partial Table access using offset/octet-count method................47
95 39 Extended PSEM (EPSEM)................................................49
96 40 Association control – Association Control Service Element (ACSE).....51
97 41 Application Context Element (A1H)...................................51
98 42 Called AP Title Element (A2H).......................................52
99 43 Calling AP Title Element (A6H)......................................52
100 44 Universal Identifier (06H)..........................................52
101 45 Relative Universal Identifier (0DH).................................52
102 46 Calling Application Entity Qualifier Element (A7H)..................53
103 47 Mechanism Name Element (ABH)........................................54
104 48 Authentication Value Element (ACH)..................................54
105 49 Called Invocation ID Elements (A4H).................................58
106 50 Calling Invocation ID Elements (A8H)................................59
107 51 Application Data Element (BEH)......................................61
108 52 Length fields encoding..............................................62
3 - II -
4
109 53 Universal Identifiers encoding......................................62
110 54 Use of sub-branches of a register ApTitle ..........................64
111 55 C12.22 Security mechanism...........................................66
112 56 Application segmentation sub-layer...................................68
113 57 APDU Segmentation...................................................69
114 58 The segmentation algorithm..........................................69
115 59 The reassembly algorithm............................................71
116 60 Layer 6 - Presentation layer..........................................72
117 61 Layer 5 - Session layer...............................................72
118 62 Layer 4 - Transport layer.............................................72
119 63 Layer 3 - Network layer...............................................72
120 64 Layer 2 - Data link layer.............................................73
121 65 Layer 1 - Physical layer..............................................73
12266 Protocol details C12.22 device to C12.22 communication module interface .74
123 67 Interface Architecture................................................74
124 68 Interface Diagram.....................................................74
125 69 Implementation guidelines.............................................75
126 70 Layer 7 - Application layer...........................................77
127 71 Layer 6 - Presentation layer..........................................77
128 72 Layer 5 - Session layer...............................................77
129 73 Layer 4 - Transport layer.............................................77
130 74 Negotiate service....................................................77
131 75 Get configuration service............................................79
132 76 Link control service.................................................82
133 77 Send message service (74H, 77 H).....................................83
134 78 Get status service...................................................85
135 79 Get registration status service......................................86
136 80 Time sequence diagram................................................87
137 81 Service sequence state...............................................90
138 82 Layer 3 - Network layer...............................................91
139 83 Layer 2 - Data link layer.............................................91
140 84 Basic data information...............................................92
141 85 Fixed Settings......................................................92
142 86 Variable Settings...................................................92
143 87 Packet definition....................................................92
144 88 CRC selection........................................................94
145 89 Acknowledgment.......................................................95
146 90 Retry attempts.......................................................95
147 91 Timeouts.............................................................95
148 92 Traffic Time-out....................................................95
149 93 Inter-Character Time-out............................................95
150 94 Response Time-out...................................................96
151 95 Turn around delay....................................................96
152 96 Duplicate packets....................................................96
153 97 Transparency.........................................................96
154 98 Supervision of the communications link...............................96
155 99 Local routing........................................................97
156 100 Service sequence state..............................................98
157 101 Layer 1 - Physical layer............................................100
158 102 Signal definition..................................................100
159 103 Electrical properties of connection................................100
160 104 Mechanical and environmental properties............................101
161 105 Supervision of the communications link.............................101
162106 Local Port communication protocol details..............................102
163 107 Protocol definition................................................102
164 108 Layer 7 - Application layer........................................102
5 - III -
6
165 109 Layer 6 - Presentation layer.......................................102
166 110 Layer 5 - Session layer............................................102
167 111 Layer 4 - Transport layer..........................................102
168 112 Layer 3 - Network layer............................................103
169 113 Layer 2 - Data link layer..........................................103
170 114 Layer 1 - Physical layer...........................................103
171 115 C12.22 Local Port communication using a C12.18 optical port.........103
172 116 Establishment of ANSI C12.18 protocol compatibility mode...........104
173 117 Establishment of ANSI C12.22 protocol compatibility mode...........104
174118 Backward compatibility.................................................106
175ANNEX A - Relays...........................................................107
176ANNEX B - Routing Examples ................................................111
177ANNEX C: Modifications and extensions to C12.19- 1997......................113
178 ANNEX C1 - DECADE 12: Network control tables............................114
179 TABLE 120 Dimension network table......................................114
180 TABLE 121 Actual network table.........................................117
181 TABLE 122 Interface control table......................................119
182 TABLE 123 Exception report table.......................................122
183 TABLE 124 Filtering rules table........................................124
184 TABLE 125 Interface status table.......................................126
185 TABLE 126 Registration table...........................................130
186 TABLE 127 Network statistics table.....................................132
187 ANNEX C2 - DECADE 130: Relay control tables.............................134
188 TABLE 130 Dimension relay table........................................134
189 TABLE 131 Actual relay table...........................................136
190 TABLE 132 Registration list table......................................137
191 TABLE 133 Static Routing table.........................................141
192 TABLE 134 Host notification table......................................143
193 TABLE 135 Master relay assignment table................................145
194 TABLE 136 Dynamic Routing report table.................................146
195 ANNEX C3 - TABLE 07 - Universal ID pattern description..................147
196 ANNEX C4 - TABLE 07 - Procedure initiate table..........................149
197 PROCEDURE 23 Register..................................................149
198 PROCEDURE 24 De-register...............................................149
199 PROCEDURE 25 Network Interface control.................................150
200 PROCEDURE 26 Exception report..........................................151
201 ANNEX C5 - Key table (Table 46).........................................152
202Annex D - Universal Identifier.............................................153
203ANNEX E - One way devices..................................................155
204ANNEX F - APDU Response Timeout Algorithm..................................158
205ANNEX G - Communication example ...........................................160
206ANNEX H - ANSI C12.22 application layer over TCP/IP (UNIX implementation)..161
207ANNEX I - CRC examples.....................................................163
208ANNEX J – DES/CDC and DESede/CDC ..........................................165
209Annex K - Implementation guideline.........................................178
210Annex L – Implementation Use Cases.........................................182
211Annex M – Protocol Modelling...............................................191
212Annex N - Translator functionalities.......................................200
213Annex O - Translator functionalities.......................................202
214Annex P – Objectives.......................................................204
7 - IV -
8
215
2161 Introduction
217Initially, communications with electronic metering devices consisted of
218transporting memory data via proprietary protocols, which were unique to each
219manufacturer. The desire for interoperability and support for multiple
220manufacturers by reading and programming systems created a need for
221standardization of data formats and transport protocols.
222
223The first step was to standardize data formats. Internal data was abstracted
224as a set of tables. A set of standard table contents and formats were defined
225in the “Utility Industry End Device Data Tables” (ANSI C12.19).
226
227In the ”Protocol Specification for ANSI Type 2 Optical Port” (ANSI C12.18)
228Standard, a point-to-point protocol was developed to transport table data over
229an optical connection. This protocol included an application language called
230Protocol Specification for Electric Metering (PSEM) that allowed applications
231to read and write tables. ANSI C12.21 was then developed to allow metering
232devices to use PSEM to transport tables over telephone modems.
233
234This document extends the ANSI C12.18, ANSI C12.19 and the “Protocol
235Specification for Telephone Modem Communication” (ANSI C12.21) standards to
236allow transport of Table data over any networking communications system.
237
238In addition, this Standard describes an optionally exposed point-to-point
239interface between a C12.22 Device, e.g. a meter, and, a C12.22 Communications
240module, e.g. a network adaptor, designed to attach to “any” network.
241
2422 Scope
243This document defines interfaces between ANSI C12.19 devices and network
244protocols.
245
246The following was accomplished by:
247
2481. Defining a datagram that may convey ANSI C12.19 data tables through any
249 network.
250
251 This was accomplished by:
252 • Assuming that the data source is a ANSI C12.19 data tables.
253 • Defining the application layer services (Language).
254 • Defining a layer 7 (Application) Datagram to encapsulate requests and
255 responses. This Datagram is delivered to lower layers of C12.22 for
256 delivery to any network.
257
2582. Providing a full stack definition for interfacing an end device to a
259 “Network Communication Module”.
260
261 This was accomplished by:
262 • Defining the physical interface requirements between the end device and
263 the “Network Communication Module”.
264 • Defining the interface lower layers; 4 (network), 3 (transport), 2 (data
265 link) and 1 (physical).
266
2673. Providing any necessary extensions/modifications to implement translation
268 services between an ANSI C12.19 data representation and any data
9 - V -
10
269 representation model.
270
271 This is accomplished by:
272 • Defining layer 7 (C12.22 Application) to Layer 7 (Any Application)
273 translation mechanism (services and tables).
274
2753 References
276(NOTE Review this section just before publication to adjust dates)
2774 Normative
278ANSI C12.18-1996 Protocol Specification for ANSI Type 2 Optical Port.
279
280ANSI C12.19-1997 Utility Industry End Device Data Tables.
281
282ANSI C12.21-1999 Protocol Specification for Telephone Modem Communication.
283
284ISO 7498/1-1994, OSI Reference Model
285
286ISO 3309-1993(E), Information technology - Telecommunications and
287 information exchange between systems - High-level data
288 link control (HDLC) procedures - Frame Structure, Annex A
289 Explanatory Notes On Implementation of the Frame Checking
290 Sequence
291
292ANSI Std X3.92-1981, Data Encryption Algorithm
293
294ISO 8824-1-1997, Information technology – Abstract Syntax Notation One
295 (ASN.1): Specification of basic notation
296
297ISO 8824-2-1997, Information technology - Abstract Syntax Notation One
298 (ASN.1): Information Object Specification
299
300ISO 8824-3-1997, Information technology - Abstract Syntax Notation One
301 (ASN.1): Constraint specification
302
303ISO 8824-4-1997, Information technology – Abstract Syntax Notation One
304 (ASN.1): Parameterization of ASN.1 specifications
305
306ISO 8825-1-1997, Information technology – ASN.1 encoding rules:
307 Specification of Basic Encoding Rules (BER), Canonical
308 Encoding Rules (CER) and Distinguished Encoding Rules
309 (DER)
310
311T1.667-1999 ANSI T1.667-2002 Intelligent Network (Revision of T1.667-
312 1999): May, 2002.
3135 Others
314Add Dictionary reference
315
3166 Definitions and syntax
3177 Definitions
318For the purposes of this document, the following definitions and terms are
319used.
320
11 - VI -
12
321Absolute UID: Absolute encoding of a UID according to “Encoding of an
322 object identifier value” clause in ISO/IEC 10035-1.
323ACSE Association Control Service Element encoded per
324 “Connectionless protocol for the association control
325 service element: Protocol specification”, ISO/IEC 10035-
326 1. Connectionless ACSE defines the Datagram encapsulation
327 protocol used in this Standard.APDU Segment: An
328 Application Protocol Data Unit that is constructed using
329 C12.22 Segmentation as the process of breaking a C12.22
330 Datagram into smaller units before transmission, see
331 C12.22 Datagram Segmentation and Reassembly.
332
333Application Association: See Association.
334
335Application context: A set of service elements and supporting information used
336 on the Application Association. It includes a description
337 of the relationships and dependencies of the C12.22
338 Application service elements, and a description of the
339 logical structure of information to be exchanged between
340 co-operating Application Entities.
341
342Application Entity: The system-independent application activities that are
343 made available as application services to the application
344 agent; e.g., a set of application service elements that
345 together perform all or part of the communication aspects
346 of an application process. [T1.667-1999] ANSI T1.667.
347
348Application Entity Title: The Reference Models CCITT Rec. X.650 and ISO 7498-
349 3, provide an application-entity title that is composed
350 of an application-process title and an application-entity
351 qualifier. The ACSE protocol provides for the transfer
352 of an application-entity title value by the transfer of
353 its component values. The Network layer provides binding
354 between Application Entity Titles (ApTitle) and Network
355 Entity Titles.
356
357Application Process: See Application Entity.
358
359Application Protocol Data Unit (APDU): The Application Protocol Data Unit
360 (APDU) is a Datagram that is transferred error-free
361 between network nodes. The C12.22 standard encodes APDUs
362 using ACSE to carry EPSEM services and C12.19 payloads
363 between C12.22 Nodes.
364
365ApTitle: In addition to the addressing constructs (transport
366 address and possibly session and presentation selectors),
367 the communicating application entities have names -
368 application-entity titles (AeTitle). These are carried
369 by ACSE as two fields - the Application-process titles
370 (ApTitle) and the application-entity qualifier
371 (AeQualifier). The AeTitle is compound, and the ApTitle
372 consists of all but the last element, which is the
373 AeQualifier.
374
375C12.22 ApTitles may be encoded absolutely using the <universal-id-element> or
376 relatively using the <relative-uid-element>. Relative
13 - VII -
14
377 UIDs shall unique only within the context of an ANSI
378 C12.22 Network, C12.22 Network Segment or inside C12.22
379 Nodes. C12.22 Relays, C12.22 Communication Modules or
380 C12.22 Transport Layers shall map Relative UIDs to other
381 Relative UIDs or Absolute UIDs to ensure the uniqueness
382 of the ApTitle within the context of any network, a
383 C12.22 Network or a C12.22 Network Segment as needed.
384
385Association: A cooperative relationship among peer (utilizing the same
386 protocol) Application Entities which enables the
387 communication of information and the coordination of
388 their joint operation for an instance of communication.
389 This relationship may be formed by the transfer of
390 application protocol control information during the
391 establishment of a connection, or transitionally, during
392 a single invocation through connectionless service.
393 Associations can also be predefined and longstanding.
394 This Standard provides for Application Entities that
395 communicate interactively using connectionless
396 communication, and it provides for state information that
397 is shared between them for the duration of the
398 communication.
399
400Bit: A Binary Digit. The unit of information of a
401 computational quantity that can take on one of two
402 values, such as false and true or 0 and 1. A bit is said
403 to be "set" if its value is true or 1, and "reset" or
404 "clear" if its value is false or 0. One speaks of setting
405 and clearing bits. To toggle or "invert" a bit is to
406 change it, either from 0 to 1 or from 1 to 0. (Reference:
407 Computing Dictionary).
408
409BER Basic Encoding Rules as defined by ISO/IEC 8825-1.
410 Methods used to identify and encode data elements for
411 transport.
412
413Byte: A group of 8 bits of data. When expressed in this
414 Standard, bit 0 is the least significant bit and it is
415 written at the right-most position of a bit sequence. Bit
416 7 is the most signification bit and it is written at the
417 left-most position of the bit sequence. The actual bit-
418 signal transmission sequence and bits polarity, which
419 represents 1’s or 0’s, is determined by the
420 characteristics of the appropriate OSI Physical Layer
421 used to transmit the byte.
422
423Calling ApTitle: The Calling ApTitle is encoded as an Absolute UID or
424 Relative UID. It uniquely identifies the initiator of an
425 ACSE C12.22 Message.
426
427Called ApTitle: The Called ApTitle is encoded as an Absolute UID or
428 Relative UID. It uniquely identifies the target of an
429 ACSE C12.22 Message.
430C12.19 Device Class A Relative UID that uniquely identifies a C12.19 Device
431 Table set as per the MANUFACTURER field as defined in
15 - VIII -
16
432 Table 0 of ANSI C12.19-1997 or the END_DEVICE_CLASS field
433 as defined by version 2 of ANSI C12.19.
434
435C12.22 Application An Application Entity that implements a set of services
436 and procedures as defined in this Standard permitting one
437 or more well-defined devices (C12.22 Host, C12.22 Relay,
438 C12.22 Device, C12.22 Communication Module, etc.) to
439 interact within the framework of a C12.22 Network. It may
440 also contain C12.19 Tables.
441
442C12.22 Authentication Host: A C12.22 Host that is an authoritative
443 administrative host for a registering C12.22 Node in the
444 C12.22 Master Relay domain. The C12.22 Authentication
445 Host may be embedded inside a C12.22 Master Relay or it
446 may be a separate C12.22 Node on the network. There may
447 be one or more C12.22 Authentication Hosts operating
448 under the domain of a single C12.22 Master Relay.
449 Registration with C12.22 Master Relays can only succeed
450 if at least one C12.22 Authentication Host accepts
451 registration on behalf of a C12.22 Node by a C12.22
452 Master Relay. (MOVE TO APPROPRIATE SECTION)
453
454C12.22 Client: A C12.22 Node which initiates a Logon service request for
455 the purpose of establishing a session with a C12.22
456 Server.
457
458C12.22 Communication Module: Hardware module that attaches a C12.22 Device to
459 a C12.22 Network Segment. A communication module can be
460 physically located inside or outside the C12.22 Device
461 enclosure. However, it is physically and logically
462 distinct from the C12.22 Device. The interface between
463 the C12.22 Communication Module and the C12.22 Device is
464 completely defined by this Standard. The combination of a
465 C12.22 Device and a C12.22 Communication module
466 constitute a C12.22 Node. If a C12.22 Communication
467 Module which also contain its own Tables, it is also a
468 C12.22 Node.
469
470C12.22 Device: A module that hosts C12.22 Application(s) and provides at
471 least one Interface to a C12.22 Communication Module.
472
473C12.22 Gateway: A C12.22 Node that translates the ANSI Standard C12.22
474 protocol to/from other protocols. Gateways are required
475 when a C12.22 Node needs to communicate with non-C12.22
476 Nodes. C12.22 Gateways can be attached directly to the
477 non-C12.22 Devices or they can provide their translation
478 services through any network segment.
479
480C12.22 Host: A C12.22 Node that may be a C12.22 Authentication Host or
481 C12.22 Notification Host or both.
482
483C12.22 Master Relay: A C12.22 Relay that operates at the top of a hierarchy of
484 relays. It provides registration services of all devices
485 in its domain. It is also responsible for issuing
486 registration service queries to C12.22 Authentication
487 Hosts and de-registration service requests and
17 - IX -
18
488 notifications to C12.22 Notification Hosts when
489 registering a C12.22 Node. A C12.22 Master Relay can also
490 act as a C12.22 Host.
491
492C12.22 Message: Any notice, service request, service response or device
493 status sent from one C12.22 Node to another C12.22 Node
494 for the purpose of communication across a C12.22 Network.
495 The detailed encoding of C12.22 Messages is defined by
496 the appropriate encoding rules of the OSI Layer from
497 which they are issued.
498
499C12.22 Network: A C12.22 communication infrastructure that is composed of
500 C12.22 Network Segments interconnected together using
501 C12.22 Relays. A C12.22 Network shall include at least
502 one C12.22 Master Relay.
503
504C12.22 Network Segment: A collection of C12.22 Nodes that can communicate with
505 each other without forwarding messages through a C12.22
506 Relay. A C12.22 Network Segment may be either a LAN
507 (Local Area Network) or a WAN (Wide Area Network) and may
508 include bridges or routers.
509
510C12.22 Node: A point on the network that attaches to a C12.22 Network
511 Segment. C12.22 Nodes contains one or more C12.22
512 Applications. Each C12.22 Node shall have a unique
513 ApTitle on a C12.22 Network.
514
515C12.22 Notification Host: A C12.22 Host, which contains an application that
516 needs to be notified when C12.22 Nodes are registered for
517 the first time or de-registered. Each C12.22 Notification
518 Host may add the registered C12.22 Node to its active
519 client list for subsequent processing by the C12.22 Host
520 application.
521
522C12.22 Relay: A C12.22 Node that provides address resolution, Datagram
523 segmentation and optionally message forwarding services
524 to the other C12.22 Nodes. Address resolution services
525 consists of mapping Layer 7 addresses (ApTitle) to lower
526 layer addresses (Network Entity Title).
527
528C12.22 Datagram Segmentation and Reassembly: The process of breaking a C12.22
529 Datagram into smaller units before transmission and then
530 reassembling it into the proper order at the receiving
531 C12.22 Node. C12.22 Datagrams are made smaller
532 specifically because of specified packet size
533 restrictions in a given path across a channel. In the
534 ANSI Standard C12.22, segmentation and reassembly is
535 performed in the Application Segmentation Sub-layer at
536 both ends. The transport protocol determines the size of
537 the smallest maximum Protocol Data Unit (PDU) supported
538 by the underlying C12.22 Network Segment for the purpose
539 of transmission to the target C12.22 Node.
540
541C12.22 Server: A C12.22 Node which is a recipient of a Logon service
542 request from a C12.22 Client for the purpose of
543 establishing a session with that client.
19 - X -
20
544
545Channel A single path for transmitting signals, usually in
546 distinction from other parallel paths. Multiple channels
547 may coexist on the same physical media.
548 The term channel may signify either a one-way path,
549 providing transmission in one direction only, or a two-
550 way path, providing transmission in two directions.
551
552Connection: A logical and physical binding between two or more users
553 of a service.
554
555Datagram: A self-contained, independent entity of application data
556 carrying sufficient information to be routed from the
557 source Application Layer to the destination Application
558 Layer. This Standard encapsulates each Datagram as one
559 or more ACSE PDUs.
560
561EPSEM: Extended PSEM; Extended structures and services enabling
562 transportation of multiple requests and responses at the
563 same time. There are also provisions for response
564 control and end device class. EPSEM messages are
565 encapsulated within ACSE PDUs.
566
567Fragment. See APDU Segment.
568
569Interface: The C12.22 Device hardware components used to manifest a
570 C12.22 Node on a C12.22 Network Segment.
571
572Local Port: A physical interface that is directly attached to the
573 C12.22 Node; or, a physical interface that is located in
574 the immediate vicinity of the C12.22 Node and attached to
575 it by means of a dedicated short signal path (e.g.
576 cable). The main purpose of the Local Port is to provide
577 direct access to the application process of the C12.22
578 Node. The C12.22 Node application process may redirect
579 C12.22 Messages that originate from a Local Port to other
580 Local Ports or other C12.22 Node interfaces. Similarly,
581 the C12.22 Node application process may redirect incoming
582 C12.22 Messages to Local Ports. The C12.22 Communication
583 Module interface of a C12.22 Device is not a Local Port.
584 All Local Ports of a C12.22 Node shall access to the same
585 C12.22 Application. The physical Local Port
586 characteristics (OSI Layer 1) are not defined by this
587 Standard; however, the Data Link through Application
588 Layers (Layers 2-7) is fully defined by this Standard.
589
590Other Device: Devices that do not implement the ANSI Standard C12.22
591 protocol.
592
593PSEM: Protocol Specification for Electric Metering Application
594 language as originally defined by ANSI C12.18-1996 and
595 extended by ANSI standard C12.21 and in this Standard.
596
597Relative UID: Relative encoding of a UID according to “Encoding of a
598 relative object identifier value” in ISO/IEC 10035-1. The
599 Relative UID is a subset of an Absolute UID, e.g. the
21 - XI -
22
600 absolute object identifier 2.100.3.8571.3.2 contains the
601 relative object identifiers 8571.3.2.
602
603Reliable Transfer To be defined
604
605Segment In the context of a C12.22 Network, a C12.22 Network
606 Segment. In the context of a C12.22 APDU, an APDU
607 Segment.
608
609Segmentation: See C12.22 Datagram Segmentation and Reassembly.
610
611Session: Session manages the setting up and taking down of the
612 connection between two communicating C12.22 Nodes. A
613 connection is maintained while the two C12.22 Nodes are
614 communicating back and forth in a conversation or session
615 of some duration. Some connections and sessions last only
616 long enough to send a message in one direction. However,
617 other sessions may last longer, usually with one or both
618 of the communicating parties able to terminate it.
619
620Transaction A unit of interaction that occurs individually and
621 coherently.
622
623UID Universal Identifiers (UIDs) are universally unique
624 identifiers that are encoded using BER. A UID may be
625 formulated as an Absolute UID or a Relative UID and can
626 be used to specify C12.22 object identifiers such as
627 Calling ApTitle, Called ApTitle.
628
6298 Document syntax
630Document syntax is identical to that described in ANSI C12.18.
631
632Describing data definitions is usually accomplished within the confines of a
633given language and the grammar rules of that language. Since the data
634definitions embodied within this document are meant to be independent of
635specific language and, hopefully, capable of being implemented within the
636confines of any language, a method for describing the data definitions must be
637developed. A modified form of the Backus-Naur Form (BNF) serves as the basis
638for building the descriptions used to construct the data definitions.
639
640The modified form of BNF has the following definitions:
641
642Symbol Meaning
643
644< > A string contained inside angle brackets is called a non-terminal. That
645 is, while it may be viewed as a single unit it can and should be
646 redefined as consisting of one or more simpler elements.
647
648::= This symbol is read as “is defined as.” The non-terminal which occurs
649 on the left hand side (LHS) of this symbol consists of the elements
650 (non-terminals, terminals, or a combination of the two) found on the
651 right hand side (RHS). A line containing an LHS, ::=, and an RHS is
652 known as a production rule.
653
23 - XII -
24
654| The vertical bar is an “OR” symbol. The OR symbol always occurs on the
655 right hand side of a production where the left hand side can be defined
656 in more than one way. The OR bar separates valid alternative right hand
657 sides.
658
659[ ] A symbol enclosed in square brackets is optional. The production is
660 valid whether or not it is included.
661
662* The superscript asterisk is known as the Kleene star. A symbol followed
663 by the Kleene star may occur zero or more times without violating the
664 grammar.
665
666+ The superscript plus sign is known as the Kleene cross. A symbol
667 followed by the Kleene cross must occur one or more times.
668
669+n A symbol followed by the Kleene cross and any number “n” represents “n”
670 occurrences of the symbol.
671
672{ } The curly braces are used to enclose comments within the descriptions.
673 Comments have no impact on the productions.
674
6759 Table syntax
676Table document form syntax is identical to that described in ANSI C12.19.
677
67810 Reference topology
679
680The Figure below describes the C12.22 Network and protocol topology within
681which C12.22 Nodes are expected to operate.
682
683This network topology accommodates interconnections among C12.22 Nodes that
684can be located on the same or on different networks. C12.22 Messages are
685forwarded between C12.22 Network Segments using C12.22 Relays.
686
687The network topology also accommodates C12.22 Gateways that translate the
688C12.22 protocol to other protocols. C12.22 Devices and non-C12.22 Devices may
689be collocated on the same C12.22 Network Segment and optionally provide C12.22
690Gateway functionality.
691
692The interface between a C12.22 Device and C12.22 Communication Module(s) is
693fully defined in this Standard. However, the Standard general definition of
694the interface of a C12.22 Node to a C12.22 Network Segment is limited to the
695Application, Presentation and Session Layers only (layers 7-5). The interface
696between a C12.22 Device and a C12.22 Communication Module (Layers 1-4) is
697shown in the Figure using triple lines.
698
699This Standard defines components of a C12.22 Network. Each component is
700defined with enough flexibility to allow multiple components to be
701incorporated into one physical device.
702
703In the case that a C12.22 Node is connected to more than one C12.22 Network
704Segment, communication through those segments shall be to the same C12.22
705Application(s). Access to the C12.22 Node through a Local Port shall also be
706to the same C12.22 Application(s).
707
25 - XIII -
26
708When a Local Port is attached to a C12.22 Device, this port provides access to
709the C12.22 Application(s) of this C12.22 Device and may optionally provide
710access to the attached C12.22 Communication Modules. Similarly, when a Local
711Port is attached to a C12.22 Communication Module, this port provides access
712to the C12.22 Application(s) of this C12.22 Communication Module and may
713optionally provide access to the attached C12.22 Device.
714
715
C12.22 Other
Local Port Device Device
C12.22 C12.22 Other C12.22

C12.22 Master C12.22 C12.22
Host Node Device Comm Module
Relay Gateway Gateway
C12.22 Network Segment

C12.22
Comm Module Local Port
C12.22
C12.22 Relay Device
C12.22 C12.22 C12.22 C12.22

Comm Module Node Comm Module Comm Module

C12.22
C12.22 Node
Relay
716
717 Figure 1: Reference topology
718
27 - XIV -
28
719
72011 C12.22 Node to C12.22 Network Segment details
721
72212 C12.22 Node to C12.22 Network Segment Reference
723The following diagram shows a C12.22 Node that is attached to a C12.22 Network
724Segment. It also shows relay and gateway interface requirements needed to
725access remote networks (C12.22 Relay) and the translation services that may
726exists in these networks (C12.22 Gateway).
727
(1)
C12.22 Node C12.22 Relay and/or C12.22 Gateway
(2) (4) (8)
Layer 7 Layer 7 Layer 7
through 5 through 5 through 5
C12.19 Tables C12.19 Tables Other

(6)
C12.22 PSEM C12.22 PSEM gateway application
EPSEM / ACSE EPSEM / ACSE application
(3) (5) (9)

Layers Layers Layers
4 through 1 4 through 1 4 through 1
To
To To C12.22 Network
(7)
C12.22 Network C12.22 Network relay Segment or any
Segment Segment application LAN or WAN
C12.22 Network Segment C12.22 Network Segment or any LAN or WAN

728
729
730 Figure 2: C12.22 Reference network model
731
732Annotations:
733
7341. C12.22 Node attached to a C12.22 Network Segment
7352. C12.22 Application communicating using C12.19 Tables, C12.22 PSEM language
736 and EPSEM/ACSE encapsulation
7373. Layers 4 through 1 interfacing a C12.22 Application to an unspecified
738 native network infrastructure (e.g. TCP-IP/Ethernet, …)
7394. C12.22 Application of a C12.22 Gateway(6)
7405. Layers 4 through 1 of a C12.22 Relay
7416. C12.22 Gateway performing translation of the C12.22 Application to and from
742 an other application
7437. C12.22 Relay performing layer 4 through 1 translation
7448. Other application of a C12.22 Gateway
7459. Remote (other) network interface side of a C12.22 Gateway and /or C12.22
746 Relay
747
74813 Data order
749The data order is identical to that defined in ANSI C12.18 and ANSI C12.19.
750
751Within the syntax definitions, multiple parameters shall be encoded in the
752order as shown, from left to right.
753
29 - XV -
30
754Parameters in all layers within the protocol definition are encoded most
755significant byte first. The order of data fields within tables is dictated by
756ANSI C12.19.
757
758
759<word24> ::= <msbyte> <byte> <lsbyte>
760<word16> ::= <msbyte> <lsbyte>
761
762<msbyte> ::= <byte> {most significant byte}
763<lsbyte> ::= <byte> {least significant byte}
764
765<byte> ::= <bit0> <bit1> <bit2> <bit3> <bit4> <bit5> <bit6> <bit7>
31 - XVI -
32
766
76714 Layer 7 - Application layer
768The application layer provides a minimal set of services and data structures
769required to support end devices for purposes of configuration, programming and
770information retrieval in a networked environment.
771
772This layer is composed of the following four nested components:
773• ANSI C12.19 Table data structure
774• PSEM as defined in this section
775• EPSEM as defined in this section
776• ACSE association control as defined by IEC 8650 and presented in this
777 section
778
779 15 Data Structure - Utility Industry Data Tables
780
781The data structure transported by this protocol shall be compatible with the
782Utility Industry Data Tables as defined in ANSI C12.19.
783
784 16 Protocol Specification for Electric Metering (PSEM)
785
786This standard defines thirteen PSEM services. Each service description
787consists of a request and a response. Each of these requests and responses is
788described in following sections.
789
790<requests> ::= <ident> | {* Identification Service request}
791 <read> | { Read Service request}
792 <write> | { Write Service request}
793 <logon> | {* Logon Service request}
794 <security> | { Security Service request}
795 <logoff> | {* Logoff Service request}
796 <terminate> {* Terminate Service request }
797 <disconnect> {* Disconnect Service request }
798 <wait> | {* Wait Service request}
799 <register> | {** Registration Service request}
800 <de-register> | {** De-registration Service request}
801 <resolve> | {** Resolve Service request}
802 <trace> {** Trace Service request}
803
804
805<responses> ::= <ident_r> | {* Identification Service response}
806 <read_r> | { Read Service response}
807 <write_r> | { Write Service response}
808 <logon_r> | {* Logon Service response}
809 <security_r> | { Security Service response}
810 <logoff_r> | {* Logoff Service response}
811 <terminate_r> {* Terminate Service response}
812 <disconnect_r> {* Disconnect Service response}
813 <wait_r> | {* Wait Service response}
814 <register_r> | {** Registration Service response}
815 <de-register_r> | {** De-registration Service
816 response}
817 <resolve_r> | {** Resolve Service response}
818 <trace_r> {** Trace Service response}
819
820Notes:
33 - XVII -
34
821* Definition or content revised from ANSI C12.18 and/or ANSI C12.21
822** New in ANSI C12.22
823
82417 Request Codes
825
826PSEM requests always include a one-byte request code. Code numbers are
827assigned as follows:
828
82900H-1FH Codes shall not be used to avoid confusion with response codes
83020H-7FH Codes are available for use within ANSI C12 protocols
83180H-FFH Codes shall be reserved for protocol extensions
832
83318 Response Codes
834
835PSEM responses always include a one byte response code. These codes are
836listed below in a suggested order of priority. They represent an extension to
837the response codes available in ANSI C12.18 and ANSI C12.21. When more than
838one response code is capable of indicating the error response condition of a
839C12.22 Node, the response code having the highest priority (from left to
840right) may be provided as follows:In addition of response codes defined in
841ANSI C12.18, ANSI C12.22 supports the following codes. When there are multiple
842potential error response codes, precedence is given by the order in which they
843are listed in the <nok> definition, from left to right:
844
845<nok> ::= <err>|<sns>|<isss>|<iar>|<sme>|<isc>|<onp>|<iar>|<bsy>|
846 <dnr>|<dlk>|<dnr>|
847 <rno>|<isss>|<sme>|<uat>|<netr>|<nett>|<rqtl>|<rstl>|
848 <netr>|<sgns>|<sgnp> |
849 <rqtl> | <rstl><err>
850
851For example, if a C12.22 Device with a C12.22 Application that contain ANSI
852C12.19 Tables; and Table 5 of this device is read-only and it is encoded in
853non-volatile memory then a Write Service request to Table 5 would fail. The
854C12.22 Device may consider the following codes as suitable responses: <err> to
855indicate an error condition or <dlk> to indicate that the data is locked in
856memory and cannot be changed, <iar> to indicate that the action requested was
857not appropriate for this device design or <isc> to indicate that the table
858access permission are “read-only” under the current security policy. The
859correct response would be <iar> as it is the highest priority among <iar>,
860<isc>, <dlk> and <err>. However, if there is a mechanism for providing write
861access to Table 5, then <iar> should not be considered. Therefore, the
862response code becomes <isc>.
863
864Responses
865
866<ok> ::= 00H {Acknowledge
867 No problems, request accepted.}
868
869<err> ::= 01H {Error
870 This code is used to indicate rejection of
871 the received service request. The reason
872 for the rejection is not provided.}
873
874<sns> ::= 02H {Service Not Supported
35 - XVIII -
36
875 This application level error response will
876 be sent to the device when the requested
877 service is not supported. This error
878 indicates that the message was valid, but
879 the request could not be honored.}
880
881<isc> ::= 03H {Insufficient Security Clearance
882 This application level error indicates
883 that the current authorization level is
884 insufficient to complete the request.}
885
886<onp> ::= 04H {Operation Not Possible
887 This application level error will be sent
888 to the device which requested an action
889 that is not possible. This error
890 indicates that the message was valid, but
891 the message could not be processed.
892 Covers conditions such as: Invalid Length,
893 Invalid Offset}
894
895<iar> ::= 05H {Inappropriate Action Requested
897 that the action requested was
898 inappropriate. Covers conditions such as
899 write request to a read only table or an
900 invalid table id.}
901
902<bsy> ::= 06H {Device Busy
904 that the request was not acted upon
905 because the device was busy doing
906 something else. The operation may be
907 retried at a later time with success, as
908 the data may then be ready for
909 transportation during this active
910 communication.}
911
912<dnr> ::= 07H {Data Not Ready
914 that request was unsuccessful because the
915 requested data is not ready to be
916 accessed.}
917
918<dlk> ::= 08H {Data Locked
920 that the request was unsuccessful because
921 the data cannot be accessed.}
922
923<rno> ::= 09H {Renegotiate Request
925 that the responding device wishes to
926 return to the ID or base state and re-
927 negotiate communication parameters.}
928
929<isss> ::= 0AH {Invalid Service Sequence State
37 - XIX -
38
931 that the request is not accepted at the
932 current service sequence state. For more
933 information on service sequence states,
934 see Annex D.}
935
936<sme> ::= 0BH {Security Mechanism Error
937 This application level error will be
938 returned when security mechanism error is
939 detected. This code cover errors like
940 security mechanism not supported and
941 invalid encryption key.
942
943<uat> ::= 0CH {Unknown Application Title
945 returned by a C12.22 Relay or the target
946 node when an unknown or invalid Called
947 APTitle is received.}
948
949<nett> ::= 0DH {Network Time-out
951 returned when a network time-out is
952 detected.}
953
954<netr> ::= 0EH {Network Not Reachable
956 returned when a node is not reachable.}
957
958<sgns> ::= 0FH {Segmentation Not Supported
960 returned when Segmentation is required to
961 transport either the request or the
962 response and the Segmentation is not
963 supported.}
964
965<sgnp> ::= 10H {Segmentation Not possible
967 returned when Segmentation is required to
968 transport either the request or the
969 response and the Segmentation is not
970 possible.}
971
972<rqtl> ::= 0FH <max_request_size> {Request Too Large
974 returned when the request size is too
975 large.}
976
977 <max_request_size> ::= <word32> {Maximum request size in bytes allows by
978 the target device.}
979
980<rstl> ::= 10H <max_response_size>
981 {Response Too Large
983 returned when the response size of a
984 request is too large.}
39 - XX -
40
985
986 <max_response_size> ::= <word32> {Maximum response size in bytes
987 allows by the target device.}
988
989
990 11H-1FH {Codes are currently undefined, but are
991 available for use within optical port
992 protocol}
993
994 20H-7FH {Codes shall not be used to avoid
995 confusion with request codes}
996
997 80H-FFH {Codes shall be reserved for protocol
998 extensions}
999
100019 Time-out
1001
100220 Session Time-out
1003
1004Each session established with a C12.22 Server shall be monitored by the C12.22
1005Server and shut down when the session becomes inactive. An inactive session is
1006one which does not receive EPSEM messages from the C12.22 Client. An EPSEM
1007message may be a request or a response.
1008
1009The session-idle time-out value is set by the Logon request and it can be
1010temporarily modified for the next request through the use of the Wait service.
1011
1012The session time-out interval starts upon transmission by the C12.22 Server of
1013an <ok> response to a Logon request that was issued by the C12.22 Client. The
1014timer restarts upon transmission or reception of any byte of an <acse-pdu> on
1015the C12.22 Server side during a session.
1016
1017The time-out timer stops when the session ends for any reason.
1018
1019When multiple concurrent sessions are supported, the session time-out for each
1020session is set independently by the Logon service that established the
1021session.
1022
102321 Application Layer Response Time-out
1024
1025The application layer response timeout is used by a C12.22 Node that issues
1026service requests to another C12.22 Node and needs to know how long to wait for
1027responses.
1028
1029A non-recoverable Application Layer Response Timeout shall terminate the
1030associated session if one exists. A non-recoverable Application Layer
1031Response Timeout is the last one, for implementations which allow retries, or
1032the first one in implementations which do not.
1033
1034An example timeout algorithm is described in Annex F “APDU Response Timeout
1035Algorithm”.
41 - XXI -
42
1036
103722 Services
1038
103923 Identification service
1040
1041This service is used to obtain information about end device functionality. The
1042service returns a code identifying the reference standard, the version and
1043revision of the reference standard implemented, and an optional feature list.
1044
1045Identify Request
1046
1047<ident> ::= 20H
1048
1049Identify Response
1050
1051The responses <err>, <bsy>, and <isss> indicate a problem with the received
1052service request. The response <ok> indicates the identification service
1053request was accepted and the standard, version, revision and optional feature
1054list are included in the response.
1055
1056<ident_r> ::= <err> |
1057 <bsy> |
1058 <isss> |
1059 <ok> <std> <ver> <rev> <feature>* <end_of_list>
1060
1061<std> ::= <byte> {Code identifying reference standard. The
1062 codes are defined as follows:
1063 00H = ANSI C12.18
1064 01H = Reserved
1065 02H = ANSI C12.21
1066 03H = ANSI C12.22
1067 04H-FFH = Reserved
1068
1069 This value shall be 03H.
1070 }
1071
1072<ver> ::= <byte> {Binary representation of the referenced
1073 standard version number to the left of the
1074 decimal point. This value shall be 01H.}
1075
1076<rev> ::= <byte> {Binary representation of the referenced
1077 standard version number to the right of
1078 the decimal point. This value shall be
1079 00H.}
1080
1081<feature> ::= <security_mechanism> | {Features available}
1082 <session_ctrl> |
1083 <device_class> |
1084 <device_identity>
1085
1086<end_of_list> ::= 00H {End of list indicator.}
1087
1088<security_mechanism> ::= 04H <universal-id>
43 - XXII -
44
1089 {Present in the feature list only if the
1090 end device supports one or more security
1091 mechanisms. This feature element contains
1092 the universal id of the security mechanism
1093 supported. See the <mechanisms-name-
1094 element> in the “Association control –
1095 Association Control Service Element
1096 (ACSE)” section for more information.}
1097
1098<session_ctrl> ::= 05H <byte> {Bit 0 to 6:NBR_SESSION_SUPPORTED
1099 If greater than zero, the end device
1100 supports session-based communication. A
1101 session starts by the reception of the
1102 Logon service and ends by the reception of
1103 the Logoff service or the detection of a
1104 session time out.
1105
1106 Bit 7: SESSIONLESS_SUPPORTED
1107 If true, the end device supports the use
1108 of the read and write services outside a
1109 session.
1110
1111 By default, when <session_ctrl> field is
1112 not included in the identification
1113 response, one session and sessionless
1114 operations are supported.}
1115
1116<device_class> ::= 06H <universal_id> {A Universal Identifier that
1117 uniquely identifies a C12.19 Device Class
1118 object for early detection of the device
1119 class as per MANUFACTURER as defined in
1120 Table 0 of ANSI C12.19-1997 or the
1121 END_DEVICE_CLASS as defined by version 2
1122 of ANSI C12.19. When C12.19 Device Class
1123 is provided it shall not preceded features
1124 with codes that are less than 06H.}
1125
1126<universal_id> ::= <relative_uid_element> |
1127 <absolute_uid_element>
1128 {The C12.19 Device Class encoded as an
1129 absolute or relative registered universal
1130 object identifier.
1131
1132<absolute_uid_element> ::= 06H <uid_length> <absolute_uid>
1133 {The absolute encoding of the C12.19
1134 Device Class. E.g.
1135 1.2.840.10066.0.<relative_uid>, encoded as
1136 described in ISO 8825-1-1997, Basic
1137 Encoding Rules (BER). The last four bytes
1138 of this identifier shall be identical to
1139 the values delivered in the C12.19 Table
1140 elements MANUFACTURER as defined in Table
1141 0 of ANSI C12.19-1997 or the
1142 END_DEVICE_CLASS as defined by version 2
1143 of ANSI C12.19.}
1144
45 - XXIII -
46
1145<relative_uid_element> ::= 0DH <uid_length> <relative_uid>
1146 {The relative encoding of the C12.19
1147 Device Class relative to the universal
1148 identifier 1.2.840.10066.0, encoded as
1149 described in ISO 8825-1-1997, Basic
1150 Encoding Rules (BER). The <uid_length>
1151 shall range between to 00H to 04H
1152 resulting in up to four bytes being
1153 transmitted. These four bytes shall be
1154 identical to the C12.19 Table elements
1155 MANUFACTURER as defined in Table 0 of ANSI
1156 C12.19-1997 or the END_DEVICE_CLASS as
1157 defined by version 2 of ANSI C12.19, with
1158 assumed 00H trailing pad.}
1159
1160<uid_length> ::= <byte> {Length of number of bytes
1161 that follow. This value shall range
1162 between 00H to 7FH}
1163
1164<absolute_uid> ::= <byte>+ {Absolute object identifier
1165 encoded as described in ISO 8825-1-1997
1166 [BER]. The size of this field shall not
1167 exceed 127 bytes.}
1168
1169<relative_uid> ::= <byte>+ {Relative object identifier
1170 encoded as described in ISO 8825-1-1997
1171 [BER]. The size of this field shall not
1172 exceed 4 bytes.}
1173
1174<device_identity> ::= 07H <identity_length><identity>
1175 {An Identifier that uniquely identifies a
1176 C12.19 Device in the application space of
1177 the C12.19 Device. This provides for early
1178 detection of the device identification
1179 element as per IDENTIFICATION of Table 5,
1180 DEVICE_IDENT_TBL, or DEVICE_ID found in
1181 Table 6 of ANSI C12.19. The C12.19
1182 <device_identity> feature shall be
1183 supplied when the C12.19 Device’s Table 5
1184 or Table 6, are readable immediately
1185 following the <logon> service. When C12.19
1186 Device Identification is provided it shall
1187 not preceded features with codes that are
1188 less than 07H.}
1189
1190<identity_length>::= <byte> {Length of number of bytes that follow in
1191 <identity>. This value shall range between
1192 00H to 7FH}
1193
1194<identity> ::= <char_format><identification>
1195 {Provides for early (pre-logon) disclosure
1196 of the C12.19 Device identification.}
1197
1198<char_format> ::= <byte> The character encoding format
1199 of the bytes which make up
1200 <identification>. Its interpretation shall
47 - XXIV -
48
1201 be according to the relevant ANSI C12.19
1202 Standard data model referenced by the
1203 C12.19 registered Device Class feature
1204 <device_class>. When the <device_class>
1205 feature was not supplied in this <ident>
1206 response, the value of <char_format> shall
1207 be set to 01H, and <identification> shall
1208 be encoded according to ISO 7-bit coded
1209 character set for information interchange,
1210 per ISO/IEC 646: 1991.
1211
1212<identification> ::= <byte>* {The C12.19 Device
1213 identification string encoded and
1214 transmitted according to <char_format>. If
1215 the C12.19 Device’s ID_FORM in table 0, is
1216 set to BCD then the BCD digits shall be
1217 transmitted as their text equivalent also
1218 encoded as per char_format>.
1219
1220 E.g. Assuming that the C12.19 Device’s
1221 GEN_CONFIG_TBL.ID_FORM is BCD and the
1222 Device’s GEN_CONFIG_TBL.CHAR_FORMAT is ISO
1223 7 bit ASCII, as per ISO/IEC 646: 1991),
1224 then the BCD digits 00H 01H 02H 03H 0AH 04H
1225 0DH 05H 06H 07H shall be transmitted as the
1226 character sequence “123-4.567”. The C12.19
1227 application shall logically pad this
1228 string with trailing spaces, as needed, to
1229 fill the identification field width of the
1230 C12.19 Device.}
1231
123224 Read Service
1233
1234The read service is identical to that in C12.18 and ANSI C12.21 with the
1235inclusion of additional error response codes defined by this Standard.
1236
1237The read service is used to cause a transfer of Table data to the requesting
1238device.
1239
1240Request:
1241
1242The read request allows both complete and partial Table transfers. The
1243retrieval of a portion of a Table is possible through the use of both
1244index/element-count and offset/octet-count methods. The complete rule set for
1245using these methods is enumerated in 4.2.2.12 and 4.2.2.14 respectively.
1246
1247Request codes 30–39, 3E and 3F give access to all possible methods used for
1248Table transfer. Request code 30 specifies a complete Table transfer. Request
1249codes 31 through 39 specify a partial table transfer using 1 to 9 indices.
1250Request code 3E specifies a default Table transfer. Request code 3F specifies
1251a partial table transfer using the offset/octet-count method.
1252
1253<read> ::= <full_read> | <pread_index> | <pread_offset> |
1254 <pread_default>
1255
1256<full_read> ::= 30H <tableid>
49 - XXV -
50
1257
1258<pread_index> ::= <3jH> <tableid> <index>+ <element-count>
1259
1260<3jH> ::= 31H | { 1 <index> included in request }
1261 32H | { 2 <index> included in request }
1268 39H { 9 <index> included in request }
1269
1270<pread_default> ::= 3EH {Transfer default table}
1271
1272<pread_offset> ::= 3FH <tableid> <offset> <octet-count>
1273
1274<tableid> ::= <word16> {Table identifier as defined in ANSI
1275 C12.19.}
1276
1277<offset> ::= <word24> {Offset into data table in bytes. Offset
1278 0000H is the offset to the first table
1279 element of the table selected by
1280 <tableid>.}
1281
1282<index> ::= <word16> {Index value used to locate start of data.
1283 Index 0000H+ is the index of the first
1284 table element of the table selected by
1285 <tableid>.}
1286
1287<element-count> ::= <word16> {Number of elements to read starting at
1288 the requested index.}
1289
1290<octet-count> ::= <word16> {Length of table data requested starting
1291 at <offset>, in bytes }
1292
1293Response:
1294
1295Responses of type <nok> indicate a problem with the received service request.
1296
1297The response <ok> indicates the read service was accepted and the data is part
1298of the response.
1299
1300<read_r> ::= <nok> | <ok> <table_data>
1301
1302<table_data> ::= <count> <data> <cksum>
1303
1304< count> ::= <word16> { Length of <data> returned, in bytes }
1305
1306
1307<data> ::= <byte>+ {The returned table data including the
1308 optional pending header as per ANSI
1309 Standard C12.19, when requested. }
1310
1311<cksum> ::= <byte> { 2's compliment checksum computed only on
1312 the <data> portion of <table_data>. The
51 - XXVI -
52
1313 checksum is computed by summing the bytes
1314 (ignoring overflow) and negating the
1315 result. }
1316
131725 Write Service
1318
1319The write service is identical to that in C12.18 and ANSI C12.21 with the
1321
1322The write service is issued to transfer table data to the target device.
1323
1324Request:
1325
1326The write request allows both complete and partial table transfers. The
1327modification of a portion of a table is possible through the use of both
1328index/element-count and offset/octet-count methods. The complete rule set for
1329using these methods is enumerated in 6.3.2.6 and 6.3.2.7 respectively.
1330
1331Request codes 40–49 and 4F give access to all possible methods used for table
1332transfer. Request code 40 specifies a complete table transfer. Request codes
133341 through 49 specify a partial table transfer using 1 to 9 indices. Request
1334code 4F specifies a partial table transfer using the offset/octet-count
1335method.
1336
1337<write> ::= <full_write> | <pwrite_index> | <pwrite_offset>
1338
1339<full_write> ::= 40H <tableid> <table_data>
1340
1341<pwrite_index> ::= <4jH> <tableid> <index>+ <table_data>
1342
1343<4jH> ::= 41H | { 1 <index> included in request }
1351 49H { 9 <index> included in request }
1352
1353<pwrite_offset> ::= 4FH <tableid> <offset> <table_data>
1354
1355<tableid> ::= <word16> { Table identifier as defined in ANSI
1356 Standard C12.19 }
1357
1358<offset> ::= <word24> { Offset into data table in bytes. Offset
1359 0000H is the offset to the first element
1360 of the table selected by <tableid>. }
1361
1362<index> ::= <word16> { Index value used to locate start of
1363 data. Index 0000H+ is the index of the
1364 first element of the table selected by
1365 <tableid>.}
53 - XXVII -
54
1366<table_data> ::= <count> <data> <cksum>
1367
1368<count> ::= <word16> { Length of <data> to be written, in
1369 bytes. This includes the optional pending
1370 header length as defined by ANSI C12.19. }
1371
1372<data> ::= <byte>+ {The table data elements including the
1373 optional pending header as per ANSI
1374 Standard C12.19 when requested. }
1375
1376<cksum> ::= <byte> { 2's compliment checksum computed only on
1377 the <data> portion of <table_data>. The
1378 checksum is computed by summing the bytes
1379 (ignoring overflow) and negating the
1380 result. }
1381
1382Response:
1383
1384Responses of type <nok> indicate a problem with the received service request.
1385
1386The response <ok> indicates the write service was successfully completed and
1387the data was successfully transmitted to the device.
1388
1389<write_r> ::= <nok> | <ok>
1390
139126 Logon Service
1392
1393Logon service establishes a session without establishing access permissions.
1394It provides for immediate transfer to the session state from the idle state. A
1395peer-to-peer association shall be established.
1396
1397Request:
1398
1399The <user_id> parameter is a code, optionally stored by the C12.22 Node,
1400indicating a supplied identity of the operator requesting the creation of a
1401session. The <user_id> may be inserted in the Event and History Logs of the
1402C12.19 tables Standard referenced in Section 3.0, References, when supported
1403by the metering device. The <user> field provides the name of the operator
1404requesting the access to the C12.22 Node and may be recorded in the Utility
1405Information Table (Table 06).
1406
1407The logon service has the following format:
1408
1409<logon> ::= 50H <user_id> <user> <req_session_idle_timeout>
1410
1411<user_id> ::= <word16> {User identification code}
1412
1413<user> ::= <byte>+10 {10 bytes containing user identification}
1414
1415<req_session_idle_timeout> ::= <word16> {The desired number of seconds a
1416 session may be idle on the C12.22 Server
1417 side before the C12.22 Server may
1418 terminate the session.}
1419Response:
1420
55 - XXVIII -
56
1421All responses other than <ok> indicate a problem with the received service
1422request and the session and the association shall not be established. The
1423C12.22 Node shall remain in the idle state.
1424
1425All error responses (including those that are not listed below or extensions
1426on those covered by <nok>) shall be generically interpreted as an indication
1427to the application not to issue another Logon request without first addressing
1428the cause of the indicated error condition.
1429
1430<logon_r> ::= <ok> <resp_session_idle_timeout> |
1431 <nok> { Response code or error codes as per
1432 Section 6.3.2.2, Response Codes.}
1433
1434<resp_session_idle_timeout> ::= <word16> {The number of seconds a session may
1435 be idle on the C12.22 Server before the
1436 C12.22 Server may terminate the session.
1437 This value shall be less than or equal to
1438 <req_session_idle_timeout>.}
1439
1440The following responses shall have the following implication to the
1441application:
1442
1443<ok> The successful initiation of the session.
1444 This is an indication to the application
1445 that the service request was accepted and
1446 the C12.22 Node started all session
1447 related processing. The association
1448 between the peer C12.22 Node was
1449 established.
1450MERGE with the global response code.
1451
1452<err> The condition which cased this error is
1453 not described by this Standard.
1454
1455<sns> This service is not supported.
1456
1457<iar> This is an indication to the application
1458 that this service request is invalid at
1459 the current operating state of the C12.22
1460 Node.
1461
1462<bsy> This is an indication to the application
1463 to re-issue this request at a later time
1464 as the C12.22 Node is busy.
1465
1466<isss> The is an indication to the application
1467 not to re-issue this request at this time
1468 as there is a service sequence state
1469 problem or an order of operations problem.
1470
1471<uat> The application shall assume that the
1472 association with the Called Ap-Title was
1473 terminated.
1474
57 - XXIX -
58
1475<nett> The application shall assume that the
1477 terminated.
1478
1479<netr> The application shall assume that the
1481 terminated.
1482
1483<sgns> This is an indication to the application
1484 to resolve this conflict with the
1485 Negotiate service.
1486
1487<sgnp> This is an indication to the application
1490
149127 Security Service
1492
1493NOTE: Maintain in sync with ANSI C12.18 and C12.21
1494The security service is identical to that in C12.18 and ANSI C12.21 with the
1496
1497The security service is provided for setting access permissions.
1498
1499Note that sending passwords as clear text (unencrypted) over the network is a
1500security concern. Available encryption services are described in the C12.22
1501Security Mechanism section (Section 6.3.3.14).
1502
1503Request:
1504
1505A password is used as a means to select access permissions. This service
1506request may only be sent during a session. The <password> field will be
1507compared with those in the password table of the table specifications
1508referenced in Clause 2, References, if the password tables are supported by
1509the metering device.
1510
1511<security> ::= 51H <password>
1512
1513<password> ::= <byte> +20 {20 byte field containing password}
1514
1515Response:
1516
1517The responses <err> <bsy>, and <isss> indicate a problem with the received
1518service request.
1519
1520The response <ok> indicates the security service was successfully completed
1521and the access permissions associated with the password were granted.
1522
1523<security_r> ::= <err> | <bsy> | <isss> | <sns> | <ok>
1524
1525
152628 Logoff Service
1527
1528The Logoff service provides for an orderly termination of the session that was
1529established by the Logon service. It provides for immediate transfer to the
1530idle state from the session state. The peer-to-peer association shall
59 - XXX -
60
1531terminate and all previously negotiated settings shall reset to their default
1532idle-state values.
1533
1534The physical layer signaling parameters of the C12.22 Node shall not be
1535affected by this service.
1536
1537
1538Request:
1539
1540<logoff> ::= 52H
1541
1542Response:
1543
1545request and the session and the association shall retain the settings
1546negotiated prior to the issuance of the Logoff service request unless
1547otherwise specifically indicated by the error code.
1548
1551to the application not to issue another Logoff request without first
1552addressing the cause of the indicated error condition.
1553
1554When a response other than <ok> is understood to be an indication other than
1555the severance of the communication path or association, the application may
1556issue any valid session state service request or choose to terminate the
1557association or it may let the association time-out to force the session to be
1558aborted.
1559
1560<logoff_r> ::= <ok> | <nok> {Response code or error codes as per
1562
1563
1565application:
1566
1567<ok> The successful termination of the session.
1570 the C12.22 Node completed all session
1571 related processing before terminating the
1572 session then it reset its communication
1573 parameters to their default settings and
1574 entered the idle state. The association
1575 between the peer C12.22 Nodes was
1576 terminated.
1577
1578MERGE common definition with the global response code.
1581
1582<sns> This service is not supported. This error
1583 response shall not be issued by any C12.22
1584 Node in the session state.
1585
61 - XXXI -
62
1586<isc> This service is not allowed at the current
1587 security level.
1588
1592 Nodes.
1593
1597
1602
1605 terminated.
1606
1609 terminated.
1610
1613 terminated.
1614
1618
1622
162329 Terminate Service
1624
1625The Terminate service provides for an orderly abortion of the session that was
1626established by the Logon service. It provides for immediate transfer to the
1627idle state from the session state. The peer-to-peer association shall
1628terminate and all previously negotiated settings shall reset to their default
1629idle-state values.
1630
1631This application-level service shall be used to terminate a session for
1632reasons such as excessive errors, security issues, internal error conditions,
1633a need to abort session, or other reasons.
1634
1635The physical layer signaling parameters of the C12.22 Node shall not be
1636affected by this service.
1637
1638Request:
1639
1640<terminate> ::= 21H
1641
63 - XXXII -
64
1642
1643Response:
1644
1646request and the session and the association shall retain the settings
1647negotiated prior to the issuance of the Terminate service request.
1648
1651to the application not to issue another Terminate request without first
1653
1654When a not <ok> response is understood to be an indication other than the
1655severance of the communication path or association, the application may issue
1656any valid session state service request or choose to terminate the association
1657or it may let the association time-out to force the session to be aborted.
1658
1659<terminate_r> ::= <ok> | <nok> {Response code or error codes as per
1661
1662
1664application:
1665
1666<ok> The successful abortion of the session.
1669 the C12.22 Node and aborted all session
1670 related processing then it terminated the
1671 session, reset its communication
1672 parameters to their default settings and
1673 entered the idle state. The association
1674 between the peer C12.22 Nodes was
1675 terminated.
1677
1680
1681<sns> This service is not supported. This error
1682 response shall not be issued by any C12.22
1683 Node in the session state.
1684
1687
1691 Node.
1692
1696
65 - XXXIII -
66
1697<isss> This is an indication to the application
1701
1704 terminated.
1705
1708 terminated.
1709
1712 terminated.
1713
1717
1721
172230 Disconnect Service
1723
1724This services is used to remove a C12.22 Node from the C12.22 Network Segment.
1725
1726The Disconnect service, when issued within a session, provides for an orderly
1727abortion of the session that was established by the Logon service. It is
1728functionally equivalent to Terminate service request that is followed by a
1729transition to the off-line state.
1730
1731When received in the idle state it shall cause the C12.22 Node to enter the
1732off-line state.
1733
1734All peer-to-peer associations across the interface of the C12.22 Node on the
1735C12.22 Network segment that processed this request shall terminate. The C12.22
1736Node’s settings shall reset to their default off-line state values for the
1737that C12.22 Network Segment.
1738
1739The physical layer signaling parameters of the C12.22 Node may be affected by
1740this service.
1741
1742For this service request to be successful the initiator shall have write
1743access permission to Procedure 25 NETWORK_INTERFACE_CONTROL_PROC.
1744
1745Request:
1746
1747<disconnect> ::= 22H
1748
1749
1750Response:
1751
67 - XXXIV -
68
1753request and the physical layer signaling parameters, session and the
1754association shall retain the settings negotiated prior to the issuance of the
1755Disconnect service request.
1756
1759to the application not to issue another Disconnect request without first
1761
1762When a not <ok> response is understood to be an indication other than the
1763severance of the communication path or association, the application may issue
1764any valid service request or choose to terminate the association or it may let
1765the association time-out to force a session to be aborted.
1766
1767<disconnect_r> ::= <ok> | <nok> { Response code or error codes as per
1769
1770
1772application:
1773
1774<ok> If the C12.22 Node was in the session
1775 state then this is an indication of the
1776 successful abortion of the session. This
1777 is also an indication that the C12.22 Node
1778 aborted all session related processing;
1779 the C12.22 Node removed itself from the
1780 C12.22 Network Segment (by de-asserting
1781 the appropriate physical layer signals),
1782 entered the off-line state and reset its
1783 communication parameters to their default
1784 settings. The association between the peer
1785 C12.22 Nodes was terminated and all other
1786 associations that share the same interface
1787 on the C12.22 Node network segment which
1788 processed this response were also
1789 terminated.
1791
1792<err> The condition which caused this error is
1794
1795<sns> This service is not supported.
1796
1799
1800<onp> This is an indication to the application
1801 that this service is not possible under
1802 current C12.22 Node configuration.
1803
1807 Node.
69 - XXXV -
70
1808
1812
1817
1820 terminated.
1821
1824 terminated.
1825
1828 terminated.
1829
1833
1837
183831 Wait Service
1839
1840The wait service is used to maintain an established session during idle
1841periods thus preventing automatic termination. This service temporarily
1842extends the session time-out to the <time> specified in the request upon
1843acknowledgement of the wait service request. The session time-out will be
1844reset to the default value once the next valid service is received by this
1845target.
1846
1847
1848Request:
1849
1850<wait> ::= 70H <time>
1851<time> ::= <byte> {Requested wait period in seconds.}
1852
1853Response:
1854
1855The responses <err>, <sns>, <bsy>, and <isss> indicate a problem with the
1856received service request and session time-out is not extended.
1857
1858The response <ok> indicates the service request was accepted and the session
1859time-out is extended to the value requested.
1860
1861<wait_r> ::= <err> |
1862 <sns> |
1863 <bsy> |
71 - XXXVI -
72
1864 <isss> |
1865 <ok>
1866
186732 Registration Service
1868
1869The Registration service is used to add and maintain (“keep-alive”) routing-
1870tables entries of C12.22 Rrelays. To be part of a C12.22 Network, a C12.22
1871Node shall send a Registration service request to one of the C12.22 Master
1872relays. This service is carried in an ACSE application data unit <acse_pdu>
1873with the Calling ApTitle set to the ApTitle of the registering C12.22 Node and
1874the Called ApTitle set to the ApTitle of the Master Relay. This service
1875carries the node type, the node class, serial number, registration lifetime
1876parameters and an optional native address of the registering node. The native
1877address is used only by the neighbor relay to send messages back to this node
1878and it is ignored by all others nodes.
1879
1880The Master Relay shall send a copy of each registration received to all C12.22
1881Notification hosts and all Authentication hosts that need to be notified. In
1882this case, the registration service is sent with the Calling ApTitle set to
1883the ApTitle of the Master Relay and the Called ApTitle set, in turn, to the
1884ApTitle of each C12.22 Host notified.
1885
1886Registration request (27H)
1887
1888<register> ::= 27H <node-type> <connection-type> <device-class>
1889 <ap-title> <serial-number> <address-length>
1890 <native-address> <registration-period>
1891
1892<device-type> ::= <byte> {An identification of the C12.22 Node’s
1893 Attributes. These values may be set to
1894 advertise the capabilities of this C12.22
1895 Node and to assist C12.22 Master Relay in
1896 the decision making for the successful
1897 completion of all communication with other
1898 C12.22 Nodes that participate in the
1899 registration process.
1900
1901 Bit 0 to 5: NODE_TYPE as per
1902 INTERFACE_STATUS_TBL.NODE_TYPE_BFLD.
1903
1904 Bit 0: RELAY
1905 When set to 1 it is an indication whether
1906 this C12.22 Node is a C12.22 Relay. All
1907 C12.22 Relays shall set this bit to 1.
1908
1909 Bit 1: MASTER_RELAY
1911 this C12.22 Node is a C12.22 Master Relay.
1912 All C12.22 Master Relays shall set this
1913 bit to 1.
1914
1915 Bit 2: HOST
1917 this C12.22 Node is a C12.22 Host. A Host
1918 is an un-embedded application process that
73 - XXXVII -
74
1919 runs on a computer. A non host is a C12.22
1920 embedded application.
1921
1922 Bit 3: NOTIFICATION_HOST
1924 this C12.22 Node is a C12.22 Notification
1925 Host. All C12.22 Notification Hosts shall
1926 set this bit to 1, if they wish the C12.22
1927 Master Relay to add them to their list of
1928 Notification Hosts or issue notifications
1929 to this C12.22 Node when other C12.22
1930 Nodes register with the servicing C12.22
1931 Master Relay (See <called-ap-title>).
1932 Note: This does not preclude static
1933 registration; however notifications may
1934 not be received until the C12.22 Master
1935 relay registers this C12.22 Node as a
1936 C12.22 Notification Host.
1937
1938 Bit 4: AUTHENTICATION_HOST
1940 this C12.22 Node is a C12.22
1941 Authentication Host. All C12.22
1942 Authentication Hosts shall set this bit to
1943 1, if they wish the C12.22 Master Relay to
1944 add them to their list of Authentication
1945 Hosts or issue registration requests to
1946 this C12.22 Node when other C12.22 Nodes
1947 register with the servicing C12.22 Master
1948 Relay (See <called-ap-title>). Note: This
1949 does not preclude static registration;
1950 however notifications may not be received
1951 until the C12.22 Master relay registers
1952 this C12.22 Node as a C12.22
1953 Authentication Host.
1954
1955 Bit 5: END_DEVICE
1957 this C12.22 Node is a C19.22 End Device,
1958 i.e. it has metrological sensors and
1959 C12.19 Tables.
1960
1961 Bit 6: BROADCAST_AND_MULTICAST
1962 When set to 1 it is an indication that
1963 this C12.22 Node accepts broadcast and
1964 multicast messages.
1965
1966 Bit 7: Is reserved and shall be set to
1967 zero.
1968
1969<connection-type> ::= <byte> {An indication of the type of connection
1970 requested and the core capability related
1971 to this C12.22 Node in regard to its
1972 connection to the C12.22 Network Segment.
1973
75 - XXXVIII -
76
1974 Bits 0..5: Are reserved and shall be set
1975 to 0.
1976
1977 Bit 6: CONNECTION
1978 This bit is set to 1 if the local network
1979 segment uses a connection oriented
1980 protocol.
1981 This bit is set to 0 if the local network
1982 segment uses a connectionless oriented
1983 protocol.
1984
1985 Bit 7: ACCEPT_CONNECTION
1986 This bit is set to 1 when the local
1987 network segment uses a connection oriented
1988 protocol (Bit 6 set to 1) and the
1989 registering node accepts connections.}
1990
1991<device-class> ::= <byte><byte><byte<byte> {A list of encoding of sub-
1992 identifiers expressed as the four bytes
1993 containing the MANUFARTURER_ID as defined
1994 in Table 0 of ANSI C12.19-1997 or the
1995 END_DEVICE_CLASS as defined by ANSI
1996 C12.19-200x and registered to NEMA.
1997
1998 This is subset of the Relative Object
1999 Identifier defined in ISO/IEC 8825-1:
2000 1998/Amd.1: 1999 (E) and expressed by the
2001 <relative-uid-element>) follows:
2002
2003 The leading Relative Object Identifier
2004 introducer, 0DH, and length fields are not
2005 present in the Table 0 element. The length
2006 is assumed to be 4. Then each sub-
2007 identifier is represented as a series of
2008 (one or more) bytes. Bit 7 of each byte
2009 indicates shall be clear to zero when it
2010 is the last member in the series. Bit 7 of
2011 each preceding octets in the series is set
2012 one. Bits 6-0 of the byte in the series
2013 collectively encode the sub-identifier
2014 concatenated to form an unsigned binary
2015 number whose most significant bit is bit 6
2016 of the first octet and whose least
2017 significant bit is bit 0 of the last
2018 octet. The sub-identifier are be encoded
2019 in the fewest possible bytes such that the
2020 leading octet of the sub-identifier will
2021 not have bit 7 set to one.
2022
2023 For example if the value reported by
2024 MANUFARTURER_ID is “TEMP”, representing
2025 the relative object identifier 84.69.77.80
2026 it is encoded as 54H 45H 4DH 50H. It shall
2027 be interpreted as a Relative UID encoding
2028 of 0DH 04H 54H 45H 4DH 50H.
77 - XXXIX -
78
2029
2030 Similarly when the value reported by
2031 END_DEVICE_CLASS is 8571.3.2 or encoded as
2032 C2H 7BH 03H 02H it is interpreted as a
2033 Relative UID encoding of 0DH 04H C2H 7BH
2034 03H 02H.}
2035
2036<ap-title> ::= <universal-id-element> | <relative-uid_element>
2037 {ApTitle of the C12.22 Node to be
2038 registered. The field is optional and when
2039 not provided, its length is set to zero,
2040 implying that the ApTitle shall be
2041 automatically obtained from an
2042 authoritative proxy Relay.}
2043
2044<serial-number> ::= <universal-id-element> | <relative-uid_element>
2045 {Unique serial number assigned to this
2046 C12.22 Device by its owner and provided
2047 for registration authentication. The field
2048 is optional and when not provided, its
2049 length is set to zero.}
2050
2051<address-length> ::= <byte> {Number of bytes in <return-address>.}
2052
2053<native-address> ::= <byte>+ {Native address to use to forward messages
2054 to this node. This field is optional if
2055 lower layers of the protocol already
2056 provide it.
2057 When defined for a specific protocol
2058 stack, this field can be subdivided in
2059 sub-fields to provide address type and
2060 address data to facilitate address
2061 resolution.}
2062
2063<registration-period> ::= <word24> {Maximum period in seconds desired by the
2064 C12.22 Node to elapse between successive
2065 re-registration requests (keep-
2066 registration–alive}. The value 0 implies
2067 that a re-registration life-timer is not
2068 supplied by the registering node.}
2069
2070Registration response
2071
2072The response <ok> indicates that this ApTitles <universal-id-element> have
2073been registered and routing tables have been updated. The response <nok>
2074indicates that the some or all registrations were rejected for some reason by
2075the Master Relay. The Calling ApTitle shall be set to the ApTitle of the
2076Master Relay which responded.
2077
2078<register_r> ::= <nok> |
2079 <ok> <reg-ap-title> <reg-delay> <reg-period> <reg-info>
2080
2081<reg-ap-title> ::= <universal-id-element> | <relative-uid_element>
79 - XL -
80
2082 {Registered ApTitle to be used by the
2083 C12.22 Node for future communication on
2084 this route.}
2085
2086<reg-delay> ::= <word16> {Maximum delay in seconds that the device
2087 should wait before registering after a
2088 power up. A value of 3600 seconds shall be
2089 used as a default if this value cannot be
2090 retained. The actual delay used to re-
2091 register shall be a random value between 0
2092 and this value.}
2093
2094<reg-period> ::= <word24> {Maximum period in seconds allowed to
2095 elapse between successive re-registration
2096 requests (keep-registration–alive). The
2097 device is automatically un-registered when
2098 this limit is reach. The value 0 implies
2099 that a re-registration is not required,
2100 the registration is static.}
2101
2102<reg-info> ::= <byte> {Bit 0: DIRECT_MESSAGING_AVAILABLE
2103 Indicates whether direct messaging is
2104 available and provides performance benefit
2105 on this network segment.
2106 0 = Use message forwarding only.
2107 1 = Direct messaging is the preferred
2108 delivery method.}
2109
211033 De-registration Service
2111
2112The de-registration service is used to remove routing tables entries of C12.22
2113Relays, Master Relays and provide service discontinuation to all of the C12.22
2114Master Relay authentication and notification hosts.
2115
2116De-registration request
2117
2118<de-register> ::= 24H <ap-title> {Request to process all the <ap-title>s
2119 supplied. until the list is exhausted}
2120De-registration response
2121
2122<de-register_r> ::= <ok> <ap-title> |
2123 <nok>
2124
2125The response <ok> indicates that the identified <ap-title> was de-registered
2126and routing tables have been updated. The response <nok> indicates that de-
2127registration was rejected for identified <ap-title>.
2128
212934 Resolve Service
2130
2131This service is used to retrieve the native network address of a C12.22 node.
2132This native address is used to communicate directly with other C12.22 nodes on
2133the local area network. The Resolve request contains the ApTitle of the C12.22
2134node for which native address is requested. This request is carried in an ACSE
2135application data unit <acse_pdu> with the Calling ApTitle set to the ApTitle
2136of requesting node and the Called ApTitle set to the ApTitle of the of
2137requested relay.
81 - XLI -
82
2138
2139On network segments capable of broadcast, this service can also be used to
2140retrieve native addresses of C12.22 relays. A node that wants to retrieve the
2141list of local relays shall initiate a resolve request with the called ApTitle
2142absent. The requested Aptitle included in the request <ap-title> can have the
2143following values:
2144
2145• When the master relay Aptitle is pre-configured in the requesting node, the
2146 <called-aptitle-element> is set to this value. Every relay capable of
2147 forwarding information to this ApTitle shall return a Resolve response with
2148 its own ApTitle set as Calling ApTitle and its local address set as <local-
2149 address>.
2150• When the master relay Aptitle is auto-assigned , the requested ApTitle
2151 length is set to zero. Every relay that has Master relay Auto-ApTitle
2152 Assignment capability shall return a Resolve response with its own ApTitle
2153 set as Calling ApTitle and its local address set as <local-address>.
2154
2155When responses arrive from more than one relay, the node as the option to
2156register through one of these relays or multiple relays. By registering with
2157multiple relays, the nodes increase its chances to be located and be serviced.
2158A different ApTitle or sub-branch of the same Aptitle shall be used to
2159register to each relay. It’s the responsibility of the node that registers to
2160multiple relay to maintain each route to not become obsolete.
2161
2162Resolve request
2163
2164<resolve> ::= 25H <ap-title>
2165 {ApTitle of the requested C12.22 node.}
2166
2167Resolve response
2168
2169<resolve_r> ::= <uap> | <ok> <local-address-length> <local-address>
2170
2171<local-address-length> ::= <byte> {Length of <local-address> in bytes.}
2172
2173<local-address> ::= <byte>+ {Local address of the requested ApTitle}
2174
2175The resolve <uap> is returned when the caller's ApTitle is unknown by the
2176requested relay. The response <ok> indicates that the ApTitle has been found
2177and its local address is returned.
2178
217935 Trace Service
2180
2181This service is used to retrieve the list of relays capable of forwarding
2182C12.22 messages to a target C12.22 node. This service is carried in an ACSE
2183application data unit <acse_pdu> with the Calling ApTitle set to the ApTitle
2184of the node that have requested the trace and the Called ApTitle set to the
2185ApTitle of the node traced .
2186
2187Each time a relay receives this request, it adds its own ApTitle to the list
2188or relays stored in the Application Data Element, <application-data-element>
2189then it forwards it to the next relay. When the trace request reach the relay
2190that have the target node as neighbor (the node whose ApTitle matches the
2191Called ApTitle), this relay shall include its ApTitle in the list, replace
2192the service code by a <ok> response code, set the Called ApTitle to the
83 - XLII -
84
2193APTitle of target node, set its own ApTilte as Calling ApTitle and return this
2194information.
2195
2196It is important to note the a trace service is not processed by the terminal
2197nodes and doesn’t need to be implemented by these end nodes.
2198
2199Trace request
2200
2201<trace> ::= 26H <ap-title>*
2202
2203Trace response
2204
2205The response <nok> is returned when this request cannot be serviced. In this
2206case, the response contains a list ApTitles of all relays traversed up to the
2207point of failure (i.e. the last ApTitle is the ApTitle of the relay has
2208perform the rejection). The response <ok> indicates that the trace was
2209successful and the response contains all relays used to forward this
2210information.
2211
2212<trace_r> ::= <nok> <ap-title>* |
2213 <ok> <ap-title>*
2214 {ApTitle of relays used to forward this
2215 service.}
2216
221736 Service sequence state control
2218
2219In a networking environment, the C12.22 Nodes may support one or multiple
2220association at the same time. Any association may be session oriented or
2221sessionless. For each association supported, the C12.22 Nodes shall conform to
2222the following state:
2223
2224Off-line State: Normal state upon C12.22 Node power-up. This is also the
2225 state upon completion of a Terminate or a Link Control
2226 interface-disable service request. An off-line state
2227 implies that the C12.22 Node is not present on the C12.22
2228 Network Segment that services that node.
2229
2230Idle State: Normal state upon an active or passive open of a network
2231 connection. A passive open implies that the C12.22 Node
2232 is ready to accept transaction from the network. An
2233 active open implies that the C12.22 Node is ready to
2234 initiate transaction to a peer C12.22 Node across the
2235 network.
2236
2237Sessionless State: State while processing transaction without entering the
2238 session state.
2239
2240Session State: State achieved after a logon service has been accepted.
2241
2242
2243The relationship between PSEM services and service sequence states is:
2244
2245Identification: This service request is accepted at the idle state only.
2246 Upon completion, the application returns to the idle
2247 state.
2248
85 - XLIII -
86
2249Wait: Wait service request is accepted in session states only.
2250 Acceptance of this request does NOT result in any
2251 sequence state changes.
2252
2253Logon: This service request is accepted at the idle state only.
2254 Acceptance of this request result in a transition to the
2255 session state. This service is optional and not
2256 implemented when NBR_SESSION_SUPPORTED returned by the
2257 Identification Service is set to 0.
2258
2259Security: This service request is accepted at the session state
2260 only. Acceptance of this request does NOT result in any
2261 sequence state changes.
2262
2263Read and write: These requests are accepted in session state when
2264 NBR_SESSION_SUPPORTED, returned by the Identification
2265 Service, is greater than zero. In this case, acceptances
2266 of these requests do NOT result in any sequence state
2267 changes.
2268
2269 They are also supported in sessionless state when the
2270 SESSIONLESS_SUPPORTED, returned by the Identification
2271 Service, is set to TRUE. In this case, the application
2272 returns to the idle state.
2273
2274Logoff: This service request is accepted at the session state
2275 only. Acceptance of this request result; in a transition
2276 to the idle state. This service is optional; however it
2277 shall be supported if the Logon service is also
2278 supported. The Logoff service is a request to initiate a
2279 normal session termination. This may be used by C12.22
2280 Nodes to complete session related data processing
2281 following the successful termination of the session.
2282
2283
2284Terminate: This service request is accepted at the session state
2285 only. Acceptance of this request results in a transition
2286 to the idle state. This service is optional; however it
2287 shall be supported if the Logon service is also
2288 supported. The Terminate service is an abnormal Logoff
2289 service. Upon completion the C12.22 Node returns the idle
2290 state.
2291
2292Disconnect: This optional service request is accepted in any state.
2293 When received in the session state it shall perform a
2294 Terminate service then disconnect from the C12.22
2295 Network. Upon completion the C12.22 Node returns the off-
2296 line state.
2297
87 - XLIV -
88
Read, Write, Identification , Register,
Deregister, Resolve, or Trace
Disconnect response sent Sessionless
State
Link Control (interface enable)
Read, Write, Identification , Register,
Deregister, Resolve, Disconnect or Trace request
received
Off-line Idle
State State
Logon service
Disconnect service, Link Session Read, Write, Wait, Security,

Control (interface State Identification, Register,
disable), power-off. Deregister, Resolve or Trace
Logoff , Terminate, service
or <Session Time Out>
Disconnect service or
Disconnect from lower layer
2298
2299
2300 Figure 2. C12.22 Host Application layer state diagram
2301
230237 Partial Table access using index/element-count Method
2303
2304NOTE: BNF fields like <count> need to be updated and maintain in sync with 18
2305and 21
2306
23071. An index sets up a start of selection into a table object relative to the
2308 beginning of the table as follows:
2309
2310 • Each member of a PACKED RECORD gets a unique number.
2311
2312 • The positional number of the first element of a PACKED RECORD is
2313 assigned the value zero.
2314
2315 • The positional number of subsequent elements in the same PACKED RECORD
2316 is incremented by one for each subsequent element in the PACKED RECORD.
2317
2318 • Each sub element of a BIT FIELD is assigned a unique positional number.
2319
2320 • The positional number of the first sub element of a BIT FIELD is
2321 assigned the value zero.
2322
2323 • The positional number of subsequent sub elements in the same BIT FIELD
2324 is incremented by one for each subsequent sub element in the BIT FIELD,
2325 independent of the bit range assigned to the sub element.
2326
2327 • Positional numbers are assigned independently of any IF or CASE
2328 statements that may be present inside PACKED RECORDs or BIT FIELDs, as
2329 if the elements or sub-elements where not enclosed within any IF or
2330 SWITCH statements.
89 - XLV -
90
2331
2332 • For non final elements one level of index is appended to the index of
2333 the parent’s element index for use in selections.
2334
2335 • Selection to Boolean members within a SET are reference like array
2336 members of a single dimensional array.
2337
2338 • For elements of an ARRAY one level of index is appended to the index of
2339 the array’s element for each dimension (as per BNF.dim) for use in
2340 selections into entries of the ARRAY.
2341
23422. Selection based on an index method using element count=1 will deliver the
2343 whole selected element.
2344
23453. For the purpose of binary transmission, index cannot select into a sub-
2346 element or final elements that are not atomic, with the exception of SETs,
2347 where the first octet selected for transmission is that computed by
2348 integer division of the atomic index number requested by eight (8), and
2349 the number of elements is the number of bits requested
2350
23514. For the purpose of transmission, an index selection into a non-existing
2352 element shall result in an "Inappropriate Action Requested" error.
2353 However, it is allowed to append zeros at the end of an index to indicate
2354 the desired access level of an index selection within the table element
2355 hierarchy.
2356
23575. When element-count > 1, the application shall return up to element-count
2358 elements at the same or higher hierarchical level of the index used to
2359 initiated the request traversing all element types serially.
2360
23616. When element-count > (number of elements available for transmission), the
2362 number of elements transmitted will be limited to the maximum number
2363 elements available at the same or higher hierarchical level of the index
2364 used to initiated the request. The response element-count shall be
2365 adjusted to reflect the actual number of elements transferred in the
2366 response.
2367
23687. The number of numeric segments that make up the index defines the initial
2369 hierarchical level for element-serialization and for element-count
2370 interpretation.
2371
23728. For the purpose of transmission, as a part of a request, element-count = 0
2373 shall be interpreted as all data to be written or all data requested.
2374
23759. For the purpose of transmission, as a part of a response, element-count =
2376 0 shall be interpreted as no data was written, or no data was received.
2377
237810. For the purpose of transmission, as a part of a write request, element-
2379 count shall correctly represent the actual number of elements requested to
2380 be written, at the hierarchical level of the selection start index.
2381
238211. For the purpose of transmission, as a part of a read request, element-
2383 count represents the maximum number of elements requested.
2384
91 - XLVI -
92
238512. For the purpose of transmission, the counter shall not count elements that
2386 are not present in the table by virtue of the elements being excluded from
2387 the data stream through the use of the IF or CASE conditional statements
2388
2390 are not present in the table by virtue of them being excluded from the
2391 data stream through the use of zero length arrays, sets, strings, binaries
2392 or bcd.
2393
239414. Generally, for the purpose of transmission, any element whose size is zero
2395 shall not be a candidate for transmission and not be counted.
2396
239715. The element-count counts elements and not octets.
2398
239916. If the respondent application does not support the transmission elements
2400 at the requested index level, or the respondent application cannot deliver
2401 the element requested from an ARRAY the respondent application shall
2402 assert the error condition "Inappropriate Action Requested". The requester
2403 may then attempt a retry of the read/write request on an index of an
2404 element that is higher or lower in hierarchy relative to the index of the
2405 failed attempt.
2406
2407Index Count Access Method Examples
2408
2409The following are examples for the use of the Index/Element-Count method to
2410select data.
2411
Examples 1 Examples 2 Examples 3 Examples 4
Index = 1.0 Index = 1, Index = 1.2.0, Index = 1.2,
Element-Count = 2 Element-Count = 2 Element-Count = 4 Element-Count = 4
or or
Index = 1.0, Index = 1.2.0,
Element-Count = 4 Element-Count = 5
0 0 0 0
1.0 (Selected) 1.0 (Selected) 1.0 1.0
1.1 (Selected) 1.1 (Selected) 1.1 1.1
1.2 1.2 (Selected) 1.2 (Selected) 1.2 (Selected)
2 2 (Selected) 2 (Selected) 2 (Selected)
3.0 3.0 3.0 (Selected) 3.0 (Selected)
3.1.0 3.1.0 3.1.0 (Selected) 3.1.0 (Selected)
3.1.1 3.1.1 3.1.1 3.1.1 (Selected)
3.2 3.2 3.2 3.2
4 4 4 4
2412
241338 Partial Table access using offset/octet-count method
2414
24151. An offset sets up a start of selection into a table object relative to the
2416 beginning of the table.
2417
24182. Offset zero (0) is the octet offset to the first octet of the first object
2419 in the table as prescribed by the object data type and the value of
2420 DATA_ORDER, found in the GEN_CONFIG_TBL (Table 00).
2421
24223. When count > 1, the application shall return up to <count> octets from
2423 offset used to initiate the request traversing all element types serially,
2424 where each element will be transferred according to its type and the value
2425 of DATA_ORDER, found in the GEN_CONFIG_TBL (Table 00).
2426
93 - XLVII -
94
24274. When count > (number of octets available for transmission), the number of
2428 octets transmitted will be limited to the maximum number octets available.
2429 The response count shall be adjusted to reflect the actual number of
2430 octets transferred in the response.
2431
24325. For the purpose of transmission, as a part of a request, count = 0 shall
2433 be interpreted as all data to be written or all data requested.
2434
24356. For the purpose of transmission, as a part of a response, count = 0 shall
2436 be interpreted as no data was written, or no data was received.
2437
24387. For the purpose of transmission, as a part of a write request, octet count
2439 shall correctly represent the actual number of octets requested to be
2440 written starting at the table offset requested.
2441
24428. For the purpose of transmission, as a part of a read request, count
2443 represents the maximum number of octets requested.
2444
2446 are not present in the table by virtue of them being excluded from the
2447 data stream through the use of zero length arrays, sets, strings, binaries
2448 or bcd.
2449
245010. Generally, for the purpose of transmission, any element whose size is zero
2451 shall not be a candidate for transmission and not be counted.
2452
245311. The octet counter counts octets and not elements.
2454
245512. If the respondent application does not support the transmission octets at
2456 the requested offset if the respondent application shall assert the error
2457 condition "Inappropriate Action Requested.
2458
95 - XLVIII -
96
2459 39 Extended PSEM (EPSEM)
2460
2461The EPSEM structure and services extends PSEM. The extended structure enables
2462transportation of multiple requests and responses at the same time. It also
2463provides response control and end device class.
2464
2465<epsem> ::= <epsem-control> [<ed_class>] <epsem-data>+ | 00H
2466
2467<epsem-control> ::= <byte> {Datagram control field.
2468 Bit 6 to 7: APPLICATION_SPECEFIC_TAG
2469 Shall be equal to 2 (Bit 7=1, bit 6=0).
2470
2471 Bit 5: Reserved, shall be set to 0.
2472
2473 Bit 4: ED_CLASS_INCLUDED
2474 When set to true, <ed_class> is included
2475 in this <acse-pdu>. ed_class> shall be
2476 included in all unsolicited messages and
2477 one-way messages.
2478
2479 Bit 2 to 3: Reserved
2480
2481 Bit 0 to 1: RESPONSE_CONTROL
2482 Used by request messages to control the
2483 return of corresponding responses.
2484 0 = Always respond
2485 1 = Respond on exception
2486 2 = Never respond
2487
2488 RESPONSE_CONTROL shall be set to 2 by all
2489 one-way C12.22 Nodes.}
2490
2491<ed_class> ::= <byte><byte><byte><byte> { END_DEVICE_CLASS
2492 END_DEVICE_CLASS exactly as encoded in the
2493 General Configuration Table (Table 0) of
2494 ANSI C12.19 (Version 2.0) or the
2495 MANUFACTURER code as defined in the
2496 General Configuration Table (Table 0) of
2497 ANSI C12.19-1997 (Version 1.0). }
2498
2499<epsem-data> ::= <service-length> <req-res>
2500
2501<service-length> ::= <byte>+ {Length of <req-res> field, encoded as
2502 defined by the ISO 8825-1-1997 “Basic
2503 Encoding Rules”. When <service-length> is
2504 zero then it signifies the end of the
2505 <epsem-data> list.}
2506
2507<req-res> ::= <request> | <response>
2508 {PSEM request or response as defined in
2509 the previous section.}
2510
2511<seg-data> ::= <byte><app-data-length> The <app-data> content used to
2512 transmit an application sub-layer <acse-
2513 apdu> segment. For more details see
97 - XLIX -
98
2514 algorithm details in Section 6.3.4
2515 Application segmentation sub-layer.
99 - L -
100
2516
2517
2518 40 Association control – Association Control Service Element (ACSE)
2519
2520EPSEM relies on the use of ACSE (ISO 8650-1-1995) to convey association and
2521security parameters. This includes the application context <application-
2522context-element>, application process titles of called and calling process
2523<called-aptitle-element > and <calling-ap-title >, authentication information
2524if a secure transaction is required <mechanism-name-element > and
2525<authentication-value-element >.
2526
2527The following syntax represents a conformant subset of those fields defined in
2528the ACSE standards for the services used.
2529
2530<acse-pdu> ::= 60H
2531 <elements-length>
2532 <elements>
2533
2534<elements-length> ::= <byte>+ {Length of <elements>, encoded as defined
2535 by the ISO 8825-1-1997 “Basic Encoding
2536 Rules”}
2537
2538<elements> ::= [ <application-context-element> ]
2539 [ <called-aptitle-element> ]
2540 [ <calling-aptitle-element> ]
2541 [ <calling-entity-qualifier-element> ]
2542 [ <mechanism-name-element> ]
2543 [ <authentication-value-element> ]
2544 [ <called-apinvocation-id-element> ]
2545 <calling-apinvocation-id-element>
2546 <user-information-element>
2547
254841 Application Context Element (A1H)
2549
2550The Application Context Element <app-context-element> is used to uniquely
2551identify the ANSI C12.22 application from any other application layer that use
2552ACSE. This uniqueness is guaranteed by the use of a registered Universal
2553Identifier. Although if this element is required by ACSE, this specification
2554allows messages that do not include the Universal Identifier. This can be done
2555for efficiency reasons; only on network segments dedicated to the ANSI C12.22
2556application (C12.22 AMR homogeneous network), and must be reinserted when
2557relayed to a heterogeneous application network.
2558
2559<application-context-element> ::= A1H <app-context-length> <app-context>
2560
2561<app-context-length> ::= <byte>+ {Length of <app-context>, encoded as
2563 Encoding Rules”}
2564
2565<app-context> ::= <universal-id-element>
2566 {Object identifier representing this
2567 application layer (ANSI C12.22). This
2568 value must be set to 1.2.840.10066 and
2569 encoded as:
2570 A2 06 2A 86 48 CE 52 02H.}
101 - LI -
102
2571
257242 Called AP Title Element (A2H)
2573
2574The Called AP Title Element <called-ap-title> uniquely identifies the target
2575of an ACSE message. This uniqueness is guaranteed by the use of a absolute or
2576relative Universal Identifier. Relative Universal Identifiers are derived from
2577the ANSI C12.22 ApTitle branch (2.16.840.1.114223).
2578
2579<called-aptitle-element> ::= A2H <called-aptitle-length> <called-aptitle>
2580
2581<called-aptitle-length> ::= <byte>+ {Length of <called-aptitle> encoded as
2584
2585<called-aptitle> ::= <universal-id-element> | <relative-uid-element>
2586
258743 Calling AP Title Element (A6H)
2588
2589The Calling AP Title Element <calling-ap-title> uniquely identifies the
2590initiator of an ACSE message. This uniqueness is guaranteed by the use of a
2591absolute or relative Universal Identifier. When relative then it is derived
2592from the ANSI C12.22 ApTitle branch (2.16.840.1.114223).
2593
2594<calling-aptitle-element> ::= A6H <calling-aptitle-length> <calling-aptitle>
2595
2596<calling-aptitle-length> ::= <byte>+ {Length of <calling-aptitle> encoded as
2599
2600<calling-aptitle> ::= <universal-id-element> | <relative-uid-element>
2601
260244 Universal Identifier (06H)
2603
2604A Universal Identifier <universal-id> uniquely identifies a network address,
2605application layer, or security mechanism. (See the “Universal Identifiers
2606encoding” section for more information.)
2607
2608<universal-id-element> ::= 06H <universal-id-length> <universal-id>
2609
2610<universal-id-length> ::= <byte>+ {Length of <universal-id>, encoded as
2613
2614<universal-id> ::= <byte>+ {Object identifier encoded as described in
2615 ISO 8825-1-1997 [BER]}
2616
261745 Relative Universal Identifier (0DH)
2618
2619For efficiency reason, Relative Universal Identifiers <relative-uid-element>
2620 can be used to identify network addresses.
2621 Relative UIDs are unique only within ANSI
2622 C12.22 nodes.
2623
2624<relative-uid-element> ::= 0DH <relative-uid-length> <relative-
2625 uid>
103 - LII -
104
2626
2627<relative-uid-length> ::= <byte>+ {Length of <relative-uid>, encoded as
2630
2631<relative-uid> ::= <byte>+ {Relative object identifier encoded as
2632 described in ISO 8825-1-1997 [BER].}
2633
263446 Calling Application Entity Qualifier Element (A7H)
2635
2636The <calling-entity-qualifier-element> is used to qualify the information
2637transferred from the application entity.
2638
2639<calling-entity-qualifier-element> ::= A7H <calling-ae-qualifier-length>
2640 <calling-ae-qualifier>
2641 {The calling application entity qualifier.
2642 When the target device does not support
2643 this type of element qualification it will
2644 ignore it with no error. The initiator of
2645 the service can identify if the target
2646 supports this element by the presence of
2647 this element in the response.}
2648
2649
2650<calling-ae-qualifier-length> ::= <byte>+
2651 {Length of <calling-ae-qualifier>, encoded
2652 as defined by the ISO 8825-1-1997 “Basic
2654
2655<calling-ae-qualifier> ::= 82H <ae-qualifier-length> <ae-qualifier-value>
2656
2657<ae-qualifier-length> ::= <byte>+ {Length of <ae-qualifier-value>, encoded
2658 as defined by the ISO 8825-1-1997 “Basic
2661<ae-qualifier-value> ::= <byte>+ {Application entity qualifier value:
2662 Bit 0 : TEST
2663 Messages tagged with the calling
2664 application entity value bit 0 set to 1.
2665 The called node shall either ignore this
2666 flag (if it does not support the test
2667 feature). Otherwise it shall process the
2668 test message in such a manner that it does
2669 not affect the operation or the end state
2670 of the called node; then it shall include
2671 a <calling-entity-qualifier-element> in
2672 its response <acse-apdu> with bit 0 set to
2673 1 (response <acse-pdu> is a test response,
2674 thus acknowledging the fact that it
2675 supports tests).
2676
2677 Bit 1 : URGENT
2678 Messages tagged with the calling
2679 application entity value bit 1 set to 1
2680 are expected to be forwarded by all C12.22
105 - LIII -
106
2681 relays and acted by the called C12.22 node
2682 urgently (high priority).
2683
2684 Bit 2: NOTIFICATION
2685 When set to true, the <acse-pdu> contain
2686 services that shall be interpreted as
2687 notification of information issue by the
2688 initiator of this message. All unsolicited
2689 notification shall also include the
2690 <epsem>’s <ed_class>, i.e. <epsem-
2691 control>’s ED_CLASS_INCLUDED bit shall be
2692 set to true. When NOTIFICATION is set to
2693 true it is an indication that the
2694 information supplied in the <acse-pdu>’s
2695 <user-information-element> is about the
2696 calling C12.22 Node using the operating
2697 model indicated by provided <ed_class>.
2698 When NOTIFICATION is cleared to zero that
2699 this is information for the called C12.22
2700 Node.
2701
2702 Bit 3 to 7: Reserved.
2703 }
2704
270547 Mechanism Name Element (ABH)
2706
2707The Mechanism Name Element <mechanism-name-element> uniquely identifies the
2708security mechanism used in the containing <acse-pdu>. This uniqueness is
2709guaranteed by the use of a registered Universal Identifier. This element
2710identifies the format of the Authentication Value Element <authentication-
2711value-element> and Application Data Element <app-data> and security algorithms
2712involved. This element is optional and when not included, the default security
2713mechanism defined by this document applies. (Refer to the “C12.22 Security
2714mechanism” section for more details.)
2715
2716<mechanism-name-element> ::= ABH <mechanism-name-length> <mechanism-name>
2717
2718<mechanism-name-length> ::= <byte>+ {Length of <mechanism-id> encoded as
2721
2722<mechanism-name> ::= <universal-id> {Object identifier representing the
2723 security mechanism used.}
2724
272548 Authentication Value Element (ACH)
2726
2727The Authentication Value Element <authentication-value-element> is used to
2728carry encryption and authentication parameters. This element is optional, and
2729when not included or when it contains an <auth-value-c1221-0> <app-data> is
2730transmitted unencrypted <mac> and <padding> is not included.
2731
2732When Authentication Value Element this element is included, the <acse-pdu> is
2733either encrypted (when the <message-authentication-token> is not present) or
2734authenticated (when the <message-authentication-token> is present). At any
107 - LIV -
108
2735time, theThe requester can may change isits access rightrights, in session-
2736less requests, by also including the <user-element> in the <auth-value-c1222>.
2737
2738<authentication-value-element> ::= ACH <auth-value-length>
2739 <auth-value-c1221-0>|<auth-value-c1222>|
2740 <auth-value-other>
2741
2742<auth-value-length> ::= <byte>+ {Length of <auth-value> encoded as defined
2744 Rules”}
2745
2746<auth-value-c1222auth-data> ::= {Authentication encoding when using
2747 the ANSI C12.22 native mechanism name is
2748 1.2.840.10066.2.1}.
2749 [ <key-id-element> ]
2750 [ <iv-element> ]
2751 [ <user-element> ]
2752 [ <message-authentication-token> ]
2753
2754<key-id-element> ::= A0H <key-id-length> <key-id>
2755
2756<key-id-length> ::= <byte>+ {Length of <key-id> encoded as defined by
2757 the ISO 8825-1-1997 “Basic Encoding
2758 Rules”}
2759
2760<iv-element> ::= A1H <iv-length> <iv>
2761
2762<iv-length> ::= <byte>+ {Length of <iv> encoded as defined by the
2763 ISO 8825-1-1997 “Basic Encoding Rules”}
2764
2765<key-id> ::= <byte> {Identifies the key used to encrypt and
2766 decrypt the information. This value is
2767 matched with an entry in the KEY_ENTRIES
2768 array located in the Security table (Table
2769 45, KEY_TBL or Table 46, EXTENDED_KEY_TBL)
2770 of the target C12.22 Node. This element is
2771 optional and when not provided, <key-id> 0
2772 shall be used.
2773
2774 The <key-id> may be different in each
2775 C12.22 Message transmitted. The <key-id>
2776 used in a request may be different than
2777 the <key-id> used in the response
2778 message.}
2779
2780<iv> ::= <byte>+ {Initialization vector used to encrypt and
2781 decrypt the information. The length of
2782 this field can be either 4 or 8 bytes.
2783 When only 4 bytes are provided, these are
2784 duplicated to produce the 8 bytes
2785 required. During session session-less
2786 communication, both authenticated or and
2787 encrypted requests/responses must include
2788 an <iv> element. This element carrycarries
2789 the randomly generated number used to
109 - LV -
110
2790 encrypt or authenticate the <acse-pdu>. No
2791 relationship are is implied between the
2792 <iv> included in the request and the
2793 associated response.
2794
2795 For session oriented communication, only
2796 the Logon request and the Logon response
2797 carry an <iv> element. Any subsequent
2798 requests and responses within a session
2799 use the <iv> initially received during the
2800 login service pre-incremented by 1. This
2801 technique is used to provide playback
2802 rejection of messages exchanged after the
2803 initial login service. Duplicate or
2804 messing messages are detected using the
2805 <calling-apinvocation-id-element> and the
2806 <iv> used is adjusted accordingly.}
2807
2808
2809<user-element> ::= A2H [ <user-mac> ] <user-id> <password>
2810 {This element is optional and shall be
2811 used only in session-less
2812 transactiontransactions to modify access
2813 privileges. This element is decrypted
2814 independently of the <user-information>.}
2815
2816<user-mac> ::= <word16> {This An optional message authentication
2817 code . This is a CRC used for decryption
2818 validation. This CRC that applies to the
2819 remainder of the <user-element> that
2820 includesand it spans the clear-text
2821 elements <user-id> and <password>. This
2822 CRC uses the same algorithm as ANSI
2823 C12.18-1996, HDLC implementation of the
2824 polynomial X16 + X12 + X5 + 1}
2825
2826<user-id> ::= <word16> {User identification code}
2827
2828<password> ::= <byte>+ {20 byte field containing password}
2829
2830<messages-authentication-element> ::= A3H <auth-token-length> <msg-auth-token>
2831
2832<auth-token-length> ::= <byte> {Length of <auth-token> encoded as defined
2834 Rules”. This field is set to 8.}
2835
2836<msg-auth-token> ::= 0xAA 0x55 <app-data-header> <app-data-mac> <app-data-
2837 random-header> 0x00000000
2838 {This field contains an encrypted token
2839 composed of a constant check code (0xAA
2840 0x55) follows by the first 4 bytes of the
2841 <app-data>, follows by the <app-data> CRC
2842 as defined by the <mac> element. This
2843 information is used to authenticate the
111 - LVI -
112
2844 initiator and to verify that the <app-
2845 data> received was not altered.}
2846
2847<app-data-mac> ::= <word16> {CRC of the <epsem> as defined by the
2848 <mac> element.}concatenation of <app-data-
2849 random-header> and <app-data>. Since the
2850 <app-data-random-header> is encrypted, it
2851 is impossible to determine this CRC
2852 strictly based on the content of the <app-
2853 data>.}
2854
2855<app-data-random-header> ::= <byte><byte><byte><byte> {First 4Four
2856 bytes of the random values. These bytes
2857 are prefixed to <app-data>.}> before
2858 performing the CRC calculation that makes
2859 up <app-data-mac>. The receiver of this
2860 C12.22 Message may reject or ignore it if
2861 the <app-data-random-header> is not
2862 changing between two successive
2863 transmissions from a same source and
2864 target ApTitle pair (association).}
2865
2866<auth-value-c1221-0> ::= <auth_length> <auth_request> | <auth_response>
2867 {Authentication encoding when using the
2868 ANSI C12.22 compatibility mode for ANSI
2869 C12.21 Authentication Service (53H)
2870 selected by mechanism name
2871 1.2.840.10066.2.0.
2872 This ANSI C12.21 compatible authentication
2873 mechanism element shall only be issue in
2874 conjunction with a Logon service request,
2875 a Logon Service response or an
2876 Identification Service response. This
2877 element is used to provide a two-way
2878 authentication with playback rejection
2879 during a session. The contents of the
2880 <auth_request> and <auth_response> fields
2881 are a function of the authentication
2882 algorithm used. This algorithm is
2883 identical to ANSI C12.21 Encryption
2884 Algorithm 00H.}
2885
2886
2887<auth_length> ::= {Length of <auth_request> or
2888 <auth_response> field encoded as defined
2890 Rules”. This value shall not be greater
2891 than 255.}
2892
2893<auth_request> ::= <byte>* {In conjunction with a Logon Service
2894 request it is the information used to
2895 authenticate the sender of this <acse-pdu>
2896 according to the authentication protocol
2897 of ANSI C12.21. This field is encoded as
2898 <auth_request> per ANNEX H of ANSI
2899 C12.21.}
113 - LVII -
114
2900
2901<auth_response> ::= <byte>* {In conjunction with a Logon Service
2902 response it is the information used to
2903 authenticate the responder of the Logon
2904 according to the authentication protocol
2905 of ANSI C12.21. The length of this field
2906 shall be set to zero if the Logon request
2907 returns an error. When the Logon response
2908 is <ok> it is also an indication that the
2909 authentication was successful. When
2910 associated with a Logon Service response,
2911 the field is encoded as <auth_response>
2912 per ANNEX H of ANSI C12.21.
2913
2914 In conjunction with an Identification
2915 Service response, it is the ANSI C12.21
2916 ticket value to be used by the
2917 authentication algorithm in conjunction
2918 with a Logon Service request which
2919 follows. When associated with an
2920 Identification Service response, the field
2921 is encoded as <ticket> per ANNEX H of ANSI
2922 C12.21.}
2923
2924<auth-value-other> ::= <byte>* {Authentication encoding when using a ANSI
2925 C12.22 registered mechanism name
2926 identifier 1.2.840.10066.2.n, (where n >
2927 1).
2928
2929
293049 Called Invocation ID Elements (A4H)
2931
2932The Called Invocation ID element <called-apinvocation-id-element> provides the
2933called entity Application Layer with information about another (past) APDU
2934segment which is related to this APDU segment. The information provided is
2935the <segment-seq-number> originally supplied by the called C12.22 Node in the
2936<calling-apinvocation-id-element>. A likely user of this service may be an
2937entity which was requested to respond on exception, or a C12.22 Relay which
2938responds with a <nok> code as a result of a request that could not be
2939processed to completion. It can also optionally be provided in an <ok>
2940response to identify the APDU which was the trigger of this response.
2941
2942The <calling-apinvocation-id-element> shall be placed before the <user-
2943information-element>.
2944
2945<called-apinvocation-id-element> ::= A4H <assoc-seg-id-length> <assoc-seg-id>
2946
2947 {The <called-apinvocation-id-element> is
2948 associated with the recipient of this
2949 APDU. It uniquely binds this APDU to
2950 another APDU that was sent originally by
2951 the Application Layer of the recipient of
2952 this ACSE message. The uniqueness of the
2953 binding is established by matching the
2954 called and calling ApTitles of this APDU
2955 with the members of the <assoc-seg-id>.
115 - LVIII -
116
2956 The actual encoding rules of <assoc-seg-
2957 id> are identical to those of <seg-id> of
2958 <calling-apinvocation-id-element>.}
2959
2960<assoc-seg-id-length> ::= <byte>+ {Length of <assoc-seg-id> encoded as
2963
2964<assoc-seg-id> ::= <assoc-segment-seq-number> [<assoc-segment-byte-offset>
2965 <assoc-apdu-size>]
2966 {It conveys association information about
2967 an APDU that was originally issued by the
2968 called entity Application Layer>.
2969
2970 The presence of the optional <assoc-
2971 segment-byte-offset> is to provide
2972 granularity in the information made
2973 available to the target application. When
2974 present it is an indication that the
2975 referenced APDU was one segment of a
2976 multiple-segment transmission of a larger
2977 APDU.
2978
2979<assoc-segment-sequence-number> ::= <word16> {A number that was initially
2980 created by the called Application Layer in
2981 a previous transmission to this C12.22
2982 Host Application Layer at using
2983 called/calling ApTitle pair.}
2984
2985<assoc-segment-byte-offset> ::= byte | word16 | word24 { It is the
2986 associated segment offset in bytes
2987 relative to the beginning of the fully
2988 assembled Datagram.}
2989
2990<apdu-size> ::= byte | word16 | word24 { It shall be the size of the fully
2991 assembled APDU, <acse-pdu>, bytes.
2992
2993 The data encoding format of the <apdu-
2994 size> and <segment-byte-offset> shall be
2995 identical.}
2996
2997
299850 Calling Invocation ID Elements (A8H)
2999
3000The Calling Invocation ID elements <calling-apinvocation-id-element> provides
3001for duplicate APDU rejection and APDU Segmentation at the Application
3002Segmentation sub layer. APDU Segmentation is required when the underlying
3003network layer does not provide a delivery mechanism with sufficient capability
3004to handle large APDUs.
3005
3006The <calling-apinvocation-id-element> shall be placed before the <user-
3007information-element>.
3008
3009<calling-apinvocation-id-element> ::= A8H <seg-id-length> <seg-id>
3010 {The <calling-apinvocation-id-element> is
3011 associated with the originator of an ACSE
117 - LIX -
118
3012 message and it uniquely binds an <acse-
3013 pdu> Fragment to the fully assembled
3014 <acse-pdu> that was sent by the
3015 Application Layer of the originator of
3016 this ACSE message. The binding is
3017 temporary and it shall last only for the
3018 duration of the duplicate datagram
3019 recognition period.}
3020
3021<seg-id-length> ::= <byte>+ {Length of <seg-id> encoded as defined by
3022 the ISO 8825-1-1997 “Basic Encoding
3023 Rules”}
3024
3025<seg-id> ::= <segment-seq-number> [<segment-byte-offset> <apdu-size>]
3026 { It conveys information about the
3027 datagram containing it and the <user-data>
3028 content of <user-information-element>.
3029
3030 If the <segment-byte-offset> and <apdu-
3031 size> are present then the APDU is one
3032 segment of a multiple-segment
3033 transmission, which needs to be assembled
3034 by the Application segmentation sub Layer;
3035 otherwise, the segment represents a fully
3036 assembled Datagram and shall be forwarded
3037 immediately to the Application Layer
3038 process.
3039
3040 The Application Layer shall use only the
3041 <seg-sequence-number> element to tag its
3042 datagrams.}
3043
3044<segment-sequence-number> ::= <word16> {A number that is initially created
3045 by the Application Layer.
3046
3047 The Application Layer shall supply a <seg-
3048 sequence-number> upon construction of an
3049 initial <acse-pdu>; and it shall use this
3050 element to reject Application Layer
3051 duplicate APDUs. The <seg-sequence-number>
3052 is randomly selected during C12.22 Node’s
3053 initialization then it gets changed each
3054 time a new un-segmented APDU is created by
3055 the Application Layer. The Application
3056 segmentation sub-layer retains and
3057 propagates the Application Layer supplied
3058 value each time an APDU is segmented. This
3059 value shall not repeat within one
3060 minute.}}
3061
3062<segment-byte-offset> ::= byte | word16 | word24 { It is the segment
3063 offset in bytes relative to the beginning
3064 of the fully assembled Datagram. Segment
3065 offset zero points to the value 60H of the
3066 APDU header and it cannot exceed the size
3067 of the fully assembled Datagram - 1, when
119 - LX -
120
3068 measured in bytes. The absence of
3069 <segment-byte-offset> and <apdu-size>
3070 element-pair shall be interpreted by the
3071 Application sub-layer Layer as having
3072 received a fully assembled Datagram.
3073
3074 The data encoding format of the <segment-
3075 byte-offset> and <apdu-size> shall be
3076 identical.}}
3077
3078<apdu-size> ::= byte | word16 | word24 { It shall be the size of the fully
3079 assembled APDU, <acse-pdu>, when measured
3080 in bytes. This value shall be present when
3081 a <segment-byte-offset> is provided and it
3082 shall be identical in value to all related
3083 segments, and set to the size of the fully
3084 assembled <acse-pdu> (value of <elements-
3085 length> + 1 + size of <elements-length>).
3086
3087 The data encoding format of the <apdu-
3088 size> and <segment-byte-offset> shall be
3089 identical.}
3090
309151 Application Data Element (BEH)
3092
3093The Application Data Element <user-information> is used to carry one or
3094multiple PSEM requests or responses, or application sub-layer segments.
3095
3096<user-information-element> ::= BEH <app-data-length> <app-data>
3097
3098<app-data-length> ::= <byte>+ {Length of <app-data> encoded as defined
3100 Rules”}
3101
3102<app-data> ::= [<mac>] <epsem> [<padding>] |
3103 <seg-data>
3104
3105<mac> ::= <word16> {The message authentication code is
3106 inserted when <app-data> is encrypted.
3107 This code is a CRC which along with the
3108 <service-length>, <count> and <cksum> are
3109 used for decryption validation. This CRC
3110 applies to the remainder of the <app-data>
3111 that includes <epsem> and the optional
3112 <padding>. This CRC uses the same
3113 algorithm as ANSI C12.18-1996, HDLC
3114 implementation of the polynomial X 16 + X12
3115 + X5 + 1}
3116
3117<padding> ::= <byte>* {One or more bytes added to the end of the
3118 <epsem> message to facilitate message
3119 segmentation and size as required by the
3120 encryption algorithm. The first byte of
3121 padding must be 0 to identify the end of
3122 the requests and responses list <epsem-
121 - LXI -
122
3123 data>*. The other padding bytes can be set
3124 to any random pattern.}
3125
312652 Length fields encoding
3127
3128As defined in the previous section, all length fields are encoded using the
3129ISO 8825-1-1997 “Basic encoding rules”. This encoding is defined as follow:
3130
3131For values between 0 and 127, length fields are encoded using the short form.
3132This form consists of a single byte representing the length of the subsequent
3133message in octets.
3134
3135For values greater than 127, length fields are encoded using the long form.
3136This form consists of one byte with bit 7 set to one and bits 0 to 6 set to
3137the number of additional octets, which follow. Additional octets represent the
3138length encoded with most significant octet appearing first.
3139
3140Examples:
3141Short form: 2CH represent a length of 2CH or 44
3142Long form: 82H 01H 26H represent a length 0126H or 294
3143Long form: 81H 80 represent a length of 80H or 128
3144
314553 Universal Identifiers encoding
3146
3147This specification uses Universal Identifiers to represent the <context-id>
3148and the <universal-id> contained in both the <calling-aptitle> and <called-
3149aptitle>. A Universal Identifier is a list of values externally represented as
3150follow:
3151
3152 value1 .value2. … .valuen. … .valuem
3153
3154To guaranty the uniqueness of this identifier over all possible applications,
3155the leading (left most) n values are obtained from an official registration
3156body like the International Organization for Standardization (ISO). Any values
3157following (branches of) this unique prefix (root) can be assigned locally by
3158the owner of this prefix.
3159
3160Universal identifier is encoded using the Basic Encoding Rules (BER) (IEC
3161standard 8825) object identifier encoding. This encoding is defined as follow:
3162
3163• The first octet has value 40 x value1 + value2. (This is unambiguous, since
3164 value1 is limited to values 0, 1, and 2; value2 is limited to the range 0
3165 to 39)
3166• The following octets, if any, encode value3, …, valuen. Each value is
3167 encoded base 128, most significant digit first, with as few digits as
3168 possible, and the most significant bit of each octet except the last in the
3169 value's encoding set to one.
3170
3171For efficiency, it is possible to encode Universal Identifier as relative to
3172the official ANSI C12 root. In that case, only the branch of ANSI C12 root
3173(2.16.840.1.114223) is included in the Calling or Called ApTitle.
3174
3175By example:
3176Calling ApTile = 2.16.840.1.114223.156.5454
123 - LXII -
124
3177Absolute ApTitle encoding = A2 0D A2 0B 60 86 48 01 86 FC 2F 81 1C AA 4E
3178Relative ApTitle encoding = A2 06 0D 04 81 1C AA 4E
3179
125 - LXIII -
126
3180
318154 Use of sub-branches of a register ApTitle
3182
3183Any sub-branch of the registered root ApTitle can be used to communicate with
3184the node, which registered that root under controlled conditions. All sub-
3185branches are assumed to be registered and managed by the root ApTitle holder
3186as long as the root ApTile is registered. There are three sub-branch
3187categories supported by the Standard
3188
31891. Assigned sub-branch: Those sub-branches whose function and numeric values
3190 are assigned by the standard. Sub-branches 0 to 15 are
3191 reserved for this purpose.
31922. Reserved sub-branch: Those sub-branches whose function and numeric values
3193 are assigned by the vendor application of the node.
3194 Sub-branches 16 to 31 are reserved for this purpose.
31953. Dynamic sub-branch: Those sub-branches that are assigned dynamically by
3196 the node. Sub-branches starting at 32 are reserved for
3197 this purpose
3198
3199When a device received a message targeted to an unsupported sub-branch, the
3200node shall return an <uat> Unknown Aptitle error response.
3201
3202
3203Sub-branches are used for the efficient facilitation of the following:
3204
3205Access to Interfaces and Local Ports
3206
3207Reserved sub-branched were assigned by the Standard to access the C12.22
3208devices’ local ports and C12.22 communication modules’ interfaces. These
3209values are pre-assigned as follows:
3210
Branch Description
relay-ap-title.0 or Defined for broadcast and multicast addressing as
relay-ap-title.0.group defined by Annex D.
registered-ap-title.1 These sub-branches provide access to C12.22
or communication module tables of a C12.22 node. The
registered-ap- default communication module assigned sub-branch is
title.1.interface .1, other communication modules may be accessed
using sub-branches .1.x, where x =1,2… n, is the
communication module interface number; and x = 0 is
the default communication module interface.
For example, if registered-ap-title is set to
“2.16.8040.1.114223.69.987”, the default interface
can be accessed using the ApTitle
“2.16.8040.1.114223.69.987.1” and the second
interface can be accessed using the ApTitle
“2.16.8040.1.114223.69.987.1.2”.
registered-ap-title.2 These sub-branches provide access to the
or application entity of a device attached to a local
registered-ap- port. The default local port assigned sub-branch is
title.2.local-port .2, other local ports may be accessed using sub-
branches .2.x, where x =1,2… n, is the local port
number; and x = 0 is the default local port (e.g.
ANSI Type II connector).
For example, if registered-ap-title is set to
127 - LXIV -
128
“2.16.8040.1.114223.69.987”, the default local port
can be accessed using either the ApTitle
“2.16.8040.1.114223.69.987.2” or
“2.16.8040.1.114223.69.987.2.0”.
3211
3212
3213Mailbox
3214
3215Reserved sub-branched were assigned by the Standard to identify common
3216mailbox. These values are pre-assigned as follows:
3217
Branch Description
registered-ap-title or Default mailbox
registered-ap-title.3.0
registered-ap-title.3.1 Notification mailbox
Provides a mechanism for the transmission of
messages tagged as information C12.22 node.
registered-ap-title.3.2 Alarm mailbox
Provides a mechanism for the transmission of alarm
messages about the values or states of a C12.22
node.
3218
3219Multiple associations
3220
3221The use of sub-branch also facilitates the management of concurrent
3222associations from the same targets and initiators. Both the initiator and the
3223target nodes sharing an association may assign a un-reserved sub-branch for
3224their ApTitle. In this case, the initiator assigns a sub-branch of its calling
3225ApTitle then it uses the target’s root ApTitle as the called ApTitle. The
3226target may respond with its called ApTille or assign a new sub-branch for its
3227called ApTitle for subsequent exchanges.
3228
3229Example of multiple session that use sub-branches:
3230
Process Action Calling ApTitle/Sub-Branch Called ApTitle/Sub-Branch Session
1 Logon (1) 208.20.50.69 208.20.30 1
1 Ok(1) 208.20.30.81 208.20.50.69 1 (Started)
1 Read (1) 208.20.50.69 208.20.30.81 1
2 Logon(2) 208.20.50.47 208.20.30 2
1 Data(1) 208.20.30.81 208.20.50.69 1
2 Ok(2) 208.20.30.75 208.20.50.47 2 (Started)
1 Read(1) 208.20.50.69 208.20.30.81 1
1 Data(1) 208.20.30.81 208.20.50. 69 1
2 Read(2) 208.20.50.47 208.20.30.75 2
2 Data(2) 208.20.30.75 208.20.50.47 2
2 Logoff(2) 208.20.50.47 208.20.30.75 2
1 Logoff(1) 208.20.50.69 208.20.30.81 1
2 Ok(2) 208.20.30.75 208.20.50.47 2 (End)
1 Ok(2) 208.20.30.81 208.20.50.69 1 (End)
1 Read(1) 208.20.50.102 208.20.30.0 (comm. Module) N.A.
1 Data(1) 208.20.30.0.2 208.20.50.102 N.A.
3231
3232
3233Proxy server
3234
3235A C12.22 Relay can also act as a proxy server for C12.22 nodes that are
3236clustered on the same local network segment of the relay. This service is
3237initiated by any node when it sends a <acse-pdu> to the proxy relay without
3238including its own calling ApTitle element in the <acse-pdu>. The relay can
129 - LXV -
130
3239either reject this message by returning <onp> or it can dynamically assign one
3240of its dynamic sub-branches as the calling ApTitle then forward the resulting
3241<acse-pdu> to its destination. Messages that are directed to that dynamically
3242assigned sub-branch are forwarded by the relay to the corresponding clustered
3243node.
3244
3245Dynamically assigned sub-branches shall remain assigned to the same node for
3246the duration of the connection (in a connected environment) or a limited time
3247(in a connection-less environment) before it is returned to the available sub-
3248branches. The choice of this timing value is left to the relay developer.
3249
3250
325155 C12.22 Security mechanism
3252
3253This section defines the security mechanisms used when the Mechanism Name
3254Element <mechanism-name> is set to a value that is well-known to ANSI C12.22.
3255This is the case when an ACSE message explicitly includes a Mechanism Name
3256Element <mechanism-name> as follows:
3257 • set to 1.2.840.10066.2.0 1.2.840.10066.2.0 for ANSI C12.22
3258 compatibility mode with ANSI C12.21 Authentication algorithm 00H
3259 according to ANSI Std X3.92-1981: Data Encryption Algorithm and ANSI Std
3260 C12.21 APPENDIX H – Data Encryption Standard; or
3261 • 1.2.840.10066.2.1 for ANSI C12.22 native mechanism as defined in this
3262 document; or
3263 • noneor when no <mechanism-name> is provided and the Application Context
3264 Element <app-context-element> is set to 1.2.840.10066.
3265
3266Security modes (1.2.840.10066.2.1)
3267
3268The C12.22 Security mechanism support transport of messages in plain text,
3269authenticated or encrypted.
3270
3271When no Authentication Value Element <authentication-value-element> is
3272present, the <app-data> is transmitted unencrypted with no <mac> and
3273<padding> inserted.
3274
3275When the Authentication Value Element <authentication-value-element> is
3276present and the <messages-authentication-element> is not present, the <app-
3277data> is transmitted encrypted and a <mac> in inserted. Padding <padding> can
3278also be inserted to set the length on the encrypted data <app-data> to a
3279multiple of 8 octets. The first padding byte shall be set to 0 to identify the
3280end of the requests and responses list <epsem-data>*.
3281
3282When both the <authentication-value element> and the <messages-authentication-
3283element> are present, the message is authenticated and the <app-data> is
3284transmitted unencrypted with no <mac> and <padding> inserted.
3285
3286Rules for responses (1.2.840.10066.2.1)
3287
3288As a rule, the target of a session less request always responds using the mode
3289(plain text, authenticated or encrypted) as requested unless it has been
3290configured to reject it.
3291
3292During a session, the target always returns responses using the mode used by
3293the initial Logon request unless it has been configured to reject it. The
3294security mode can not be modified during a session.
131 - LXVI -
132
3295
3296Key id (1.2.840.10066.2.1)
3297
3298The key used to encrypt the information is identified by the <key-id-element>.
3299This element is optional and when not provided, key id 0 is used. The key also
3300define the algorithm to use to decrypt the information. Finally the
3301initialization vector is provided by the <iv-element>. Implementation examples
3302that use these three parts of information to produce a cipher text is provided
3303in “ANNEX I – DES/CBC and DESede/CBC”.
3304
3305User id and password (1.2.840.10066.2.1)
3306
3307During sessionless transaction, it is possible to establish access privileges
3308by providing a user id and a password. These parameters are transported
3309encrypted in the <user-element>.
3310
3311Initial vector (1.2.840.10066.2.1)
3312
3313The only constraint on the value of the initialization vector <iv> is to be
3314always be different for the life of the C12.22 node. Within a session
3315(Following a logon response up to the next logoff response inclusive) no <iv>
3316is transmitted. Each side shall use the initialization vector received during
3317the logon service by the other end. This <iv> is incremented before each new
3318datagram transmitted.
3319
Requestor Target
Logon request
(included <iv> set to
0x2159A3C72159A3C7)
Request accepted
(use included <iv> =
0x2159A3C72159A3C7)
Logon response sent
(included <iv> set to
0x43508E3443508E34)
Logon response accepted
(use included <iv> =
0x2159A3C72159A3C8)
Next request sent (no <iv> provided)
Request accepted (use iv
0x43508E3443508E35)
Next response sent (no <iv> provided)
Response accepted (use iv
0x2159A3C72159A3C9)
Next request sent (no <iv> provided)
Request accepted (use iv
0x43508E3443508E36)
…
3320
3321Encrypted communication example (1.2.840.10066.2.1)
3322
3323The following example show a message log of an encrypted communication where
3324the <user-element> is included only during the Logon service.
3325
Requestor Target
133 - LXVII -
134
Logon request
60 43 A8 02 00 0B AC 23 A0 01 01 A1
04 41 B4 EE 6D A2 18 76 E0 74 78 5D
87 F1 C9 7C 76 92 55 D5 CB 8C 13 56
88 BE 63 45 EA E4 50 BE 18 A3 4F 50
ED BF 93 01 A1 77 2B 84 5F 4F 87 76
7D 0A 4F F1 23 66 AA C9 0E
Logon response
60 19 A8 02 00 0B AC 09 A0 01 01 A1
04 41 B4 EE 6D BE 08 17 29 9B DF 0C
E1 40 9F
Read request
60 13 A8 02 00 0C AC 03 A0 01 01 BE
08 6C A4 5B 52 76 A2 5B 2B
Read response
60 2B A8 02 00 0C AC 03 A0 01 01 BE
20 A3 FC AC 76 8D A4 1D 2D 4F 8F 10
64 07 A9 F4 51 30 11 D4 66 82 FE E4
CD 95 82 39 87 67 47 E3 F3
Read request
60 13 A8 02 00 0D AC 03 A0 01 01 BE
08 6C A4 5B 52 76 A2 5B 2B
Read response
60 2B A8 02 00 0D AC 03 A0 01 01 BE
20 A3 FC AC 76 8D A4 1D 2D 4F 8F 10
64 07 A9 F4 51 30 11 D4 66 82 FE E4
CD 95 82 39 87 67 47 E3 F3
Logoff request
60 13 A8 02 00 0E AC 03 A0 01 01 BE
08 5A 00 57 FD 16 6F BC CF
Logoff response
60 13 A8 02 00 0E AC 03 A0 01 01 BE
3326
3327Authenticated communication example (1.2.840.10066.2.1)
3328
3329The following example show a message log of an authenticated communication
3330where the <user-element> is included only during the Logon service.
3331
3332Will be provided during the editing phase.
3333
3334Authenticated communication example (1.2.840.10066.2.0)
3335
3336Will be provided during the editing phase.
3337
3338
3339 56 Application segmentation sub-layer
3340
3341This sub-layer is responsible for the segmentation and reassemble of C12.22
3342Messages which exceed the transport layer maximum size limit. When
3343segmentation is supported it shall be accomplished through the construction of
3344sufficient number of C12.22 Segments each shall contain a fragment of the
3345original <asce-pdu> in a manner that facilitates the effective transmission of
3346the un-fragmented <acse-pdu> to the next C12.22 Node on the path to the target
3347C12.22 Node. The detailed implementation algorithm for APDU Segmentation is
3348described in the following sub-sections.
135 - LXVIII -
136
3349
3350The Application segmentation sub-layer shall also be responsible for the re-
3351assembly of all C12.22 Segments received from the Transport Layer prior to
3352delivery to the Application Layer.
3353
3354It is a requirement than the delivery of C12.22 Messages cannot fail because
3355of their size. C12.22 Relays and C12.22 Communication Modules shall,
3356therefore, segment or re-segment C12.22 Messages received to adjust their
3357sizes to meet the limits imposed by the next (output) Transport Layer. All
3358Transport Layer shall at least support the transport of 64 bytes Segment.
3359
3360C12.22 Relays or C12.22 Communication Modules may reassemble APDU Segments to
3361optimize the overall performance of the C12.22 Network. Lower layers’ flow
3362control and on-the-fly fragmentation shall be implemented as needed to avoid
3363buffer overruns.
3364
3365It is permissible for a C12.22 Node Application Layer to reject a request
3366because its size or its related response size. In these cases, the C12.22 Node
3367returns the error message <rqtl> or <rptl>. However, it is not allowed for a
3368C12.22 Node to reject a C12.22 Message because of the pre-negotiated size of
3369the received segments. The size of each segment transmitted by a C12.22 Node
3370is controlled by this node but shall not exceed the capability of the
3371transport layer used. For example, in the case of C12.22 Device attached to a
3372C12.22 Communication Module, this maximum segment size is negotiated through
3373the use of the Negotiate service.
3374
337557 APDU Segmentation
3376
3377APDUs as defined by <acse-pdu> are used to request services and transfer
3378payloads. APDUs are delivered to the lower layers in the OSI stack for
3379encapsulation, address resolution and subsequent transmission to its
3380destination through the Transport Layer. In general, the Application Layer
3381does not have knowledge (nor should it have any such knowledge) of network
3382segment size and transmission constraints and similarly the Application
3383segmentation sub-layer does not have any knowledge of the limits that may be
3384imposed by the remote Application Layer or remote Application segmentation
3385sub-layer.
3386
3387
3388The following subsections detail the APDU Segmentation algorithm, and error
3389exception reporting algorithm. Conforming implementations may optimize or
3390alter these algorithms as long as they adhere to the production rules
3391expressed by this standard.
3392
339358 The segmentation algorithm
3394
3395This sub-section assumes that the Application segmentation sub-layer is
3396capable of segmentation, and it can fragment an APDU into appropriately sized
3397segments for transmission.
3398
3399Under the above assumption, if a C12.22 Node’s Transport Layer interface
3400cannot transmit a C12.22 Datagram due to imposed limits of Datagram size the
3401Application segmentation sub-layer shall proceed and fragment the APDU as
3402follows:
3403
137 - LXIX -
138
34041. If the <acse-pdu> being fragmented is a not product of an earlier
3405 segmentation (by virtue the absence of the <calling-apinvocation-id-
3406 element>’s fields <segment-byte-offset> and <apdu-size>) then perform the
3407 following steps in this order:
3408• Copy the entire un-segmented <acse-pdu> into a datagram capture buffer, to
3409 be place as a new user information element <user-information-element>. This
3410 includes all the <acse-pdu> components: the byte 60H, <elements-length> and
3411 <elements> unaltered.
3412• Split the captured data buffer into smaller non-overlapping fragments that
3413 are suitable (size-wise) for inclusion into the newly generated <acse-pdu>
3414 segments.
3415• For each fragment of the datagram capture buffer build a new <acse-pdu> by
3416 placing a datagram capture buffer fragment into the <user-information-
3417 element>’s <app-data> and setting the <app-data-length> to the size of the
3418 datagram capture buffer corresponding fragment in bytes.
3419• Create the following fields ahead of the <user-information-element>:
3420 o <called-ap-title> derived from the un-segmented <acse-pdu>.
3421 o <calling-ap-title> derived from the un-segmented <acse-pdu>.
3422 o <calling-entity-qualifier-element> derived from the un-segmented
3423 <acse-pdu>.
3424 o <calling-apinvocation-id-element> then within the <calling-
3425 apinvocation-id-element:
3426  Set the <seg-id>’s <seg-sequence-number> to the <seg-
3427 sequence-number> previously extracted from the fully
3428 assemble APDU, as all related segments shall have the same
3429 <seg-sequence-number>.
3430  Set the <seg-id>’s <segment-byte-offset> to the fragment’s
3431 byte offset relative to the beginning of the datagram
3432 capture buffer.
3433  Set the <seg-id>’s <apdu-size> to the size of the fully
3434 assembled <acse-pdu> as stored in the datagram capture
3435 buffer, including all the <acse-pdu> components such as the
3436 byte 60H, <elements-length> and all unaltered <elements>.
3437  Set the data type (word length in bytes) of the <segment-
3438 byte-offset> by subtracting the field size of <seg-sequence-
3439 number> from the value of <seg-id-length> then dividing the
3440 result by 2. The value 1, 2 or 3 shall be obtained
3441 representing <byte>, <word16>, and <word24> respectively.
3442• Append the previously constructed <user-information-element>, to the end of
3443 the <acse-pdu>.
3444• Update the <acse-pdu>’s <elements-length>.
3445• Finish the sending the fragments to its Transport Layer.
3446
34472. If the <acse-pdu> being fragmented is a product of a previous segmentation
3448 (by virtue the presence of the <calling-apinvocation-id-element>’s fields
3449 <seg-sequence-number>, <segment-byte-offset> and <apdu-size>) then
3450• Copy all the <acse-pdu>’s <elements> excluding the element <user-
3451 information-element> to the target <acse-pdu> construction area.
3452• Copy the segment’s <app-data> portion from the <acse-pdu>’s <user-
3453 information-element> into a datagram capture buffer, to be place as a new
3454 user information element <user-information-element>.
3455• Split the captured datagram buffer into smaller non-overlapping fragments
3456 that are suitable (size-wise) for inclusion into the newly generated <acse-
3457 pdu> segments.
3458• Adjust all length and offset fields in each of the resulting <acse-pdu>
3459 segments. Specifically adjust each
139 - LXX -
140
3460 o<user-information-element>’s <app-data-length> to the length of
3461 the newly reduced data fragment in bytes.
3462 o <seg-id>’s <segment-byte-offset> being the fragment’s revised
3463 <app-data> location in the fully-assembled <acse-pdu> as
3464 originally delivered by its Application Layer. This new segment
3465 offset can be computed by adding the <acse-pdu>’s <segment-byte-
3466 offset>, which is being segmented, to the byte offset of the new
3467 segment’s <app-data> relative to the beginning of the <app-data>
3468 portion in the datagram capture buffer.
3469• Update the <acse-pdu>’s <elements-length>.
3470• Finish the sending the fragments to the Transport Layer.
3471
APDU Segment 1
<tag> <content length>
Un-segmented APDU Segmentation Buffer
<tag> <content length> 0 0x60 0x81F7
0 0 3
0x60 0x8203E4
...
4 0xA8 0x06 0x1234
0x0000 0x03E8 247 bytes
...
...
(0x81F7)
996 bytes 49 0xBE 0x81C8 APDU Segment 3
199 (0x8203E4) 199 50
200 200 <tag> <content length>
0
content
200 bytes 0x60 0x8202EC
(0x81C8)
4
content
...
0xA8 0x02 0x1234
299 299 249 0xA8 0x06 0x1234
300 300 1000 bytes 0x012C 0x03E8 748 bytes
(0x03E8)
...
(0x8202EC)
51 0xBE 0x8202C6
52
...
700 bytes
content
(0x8202C6)
offset 300
(0x012C)
999 999
<user-information-element>::= 0xBE <app-data-length> <app-data> 751
<calling-apinvocation-id-element>::=0xA8 <seg-id-length> <segment-seq-number> [<segment-byte-offset> <apdu-size>]

3472
3473
3474 Un-segmented APDU segmentation and re-assembly algorithm
3475
347659 The reassembly algorithm
3477
3478This sub-section assumes that the Application segmentation sub-layer layer is
3479capable of reassembly, and it can assemble all APDU fragments received from
3480its Transport Layer, into the original <acse-pdu> then deliver it to the
3481Application Layer.
3482
3483Assuming the above, when the datagram is received from the Transport Layer is
3484a segment of a fragmented <acse-pdu> (by virtue the presence of the <calling-
3485apinvocation-id-element>’s fields <seg-sequence-number>, <segment-byte-offset>
3486and <apdu-size>) the Application segmentation sub-layer shall reassemble the
3487APDU before delivering it to the C12.22 Application Layer. Reassembly is not
3488required for strictly forwarding functions, such as C12.22 Relays. However,
3489any C12.22 Relay may choose, at its option, to perform full or partial APDU
3490reassembly based on their system’s requirements and knowledge.
3491
141 - LXXI -
142
3492The reassembly algorithm is outlined below:
3493
34941. Allocate an <acse-pdu> re-assembly buffer that is capable of holding the
3495 APDU <seg-id>’s <apdu-size> in bytes. This field is found in the <calling-
3496 apinvocation-id-element> elements.
34972. For each segment received copy the <app-data> portion of the <user-
3498 information-element> into the buffer at the offset specified by the <seg-
3499 id>’s <segment-byte-offset> of the <calling-apinvocation-id-element> up to
3500 length specified in the <user-information-element>’s <app-data-length> in
3501 bytes.
35023. Repeat step 2 above until all segments have been received. All segments
3503 were received when the <acse-pdu> re-assembly buffer contains no gaps or
3504 the duplicate packet recognition period expires.
35054. If all segments were received with no gaps in the user data then forward
3506 the re-assembled buffer to its Application Layer for processing.
35075. If a full re-assembly cannot be completed due to missing segments, then
3508 discard all related segments silently.
3509
APDU Segment 3 APDU Segment 3-1
<tag> <content length> <tag> <content length>
0 0x60 0x8202EC 0 0x60 0x82015C

4 4 APDU Segment 3-2
...
...
<tag> <content length>

0xA8 0x06 0x1234 0xA8 0x06 0x1234
0x012C 0x03E8 0x012C 0x03E8 348 bytes 0 0x60 0x8201C0
748 bytes
...
...
(0x8202EC) (0x82015C)
4
51
0xBE 0x8202C6 51 0xBE 0x82012C
...
52 52 0xA8 0x06 0x1234
content
300 bytes 0x0258 0x03E8

(0x82012C) 448 bytes
700 bytes
...
offset 300 (0x8201C0)
(0x8202C6)
51 0xBE 0x820190
content
351 351
352 offset 300
52
(0x012C)
content
400 bytes
(0x820190)
offset 600
751 451
<user-information-element>::= 0xBE <app-data-length> <app-data>
<calling-apinvocation-id-element> ::=0xA8 <seg-id-length> <segment-seq-number> [<segment-byte-offset> <apdu-size>]

3510
3511
3512Segmented APDU re-segmentation and partial assembly algorithm
3513
3514
351560 Layer 6 - Presentation layer
3516Not defined by this standard, open to any network protocol.
3517
351861 Layer 5 - Session layer
3520
352162 Layer 4 - Transport layer
3523
352463 Layer 3 - Network layer
143 - LXXII -
144
3526
352764 Layer 2 - Data link layer
3529
353065 Layer 1 - Physical layer
3532
145 - LXXIII -
146
3533
353466 Protocol details C12.22 device to C12.22 communication module interface
353567 Interface Architecture
3536
3537This section describes the interface (Physical, Data link, Transport and
3538Application layers) between a C12.22 Device and a C12.22 Communication module.
3539The intent of this architecture is to allow the creation of C12.22 devices
3540that can reside on any type of network. This architecture also allows
3541development of communication modules that can interface any C12.22 device to
3542specific networks.
3543
3544In this model, all of the services that are normally provided by a single
3545application entity are split between two physically and logically distinct
3546modules, the C12.22 communication module and the C12.22 device. The
3547responsibility of each has been divided as follows:
3548
3549C12.22 Communication module
3550
3551• Implementation of layers 1 through 6 of the target network;
3552• Implementation of the Register service (Start-up and keep-alive service
3553 sequences) for C12.22 devices with one or more interfaces to C12.22
3554 Communication Modules; (TO REVIEW if MULTI_INTERFCACE_FLAG is removed)
3555• Implementation of the Resolve service (Direct messaging vs. Message
3556 forwarding services).
3557• Forwarding <acse-pdu> ApTitle from the network to C12.22 Device (or its
3558 other C12.22 Communication Modules).
3559
3560C12.22 Device
3561
3562• Implementation of the PSEM Login, Logoff, Security, Read and Write
3563 services;
3564• Encryption and Authentication;
3565• Application layer <acse-pdu> segmentation and reassembly;
3566• Application layer addressing.
3567• Application layer <acse-pdu> processing or forwarding.
3568• C12.22 Communication Module control and management services.
3569
357068 Interface Diagram
3571
3572The following block diagram shows the minimal and optional layers and services
3573supported by a C12.22 device that is connected to a C12.22 communication
3574module via a point-to-point interface.
3575
147 - LXXIV -
148
C12.22 Device C12.22 Communication module
(1) (1)
Application Application
Layer 7 Layer 7
(4)
C12.19 Tables [C12.19 Tables]
C12.22 PSEM C12.22 PSEM
EPSEM / ACSE EPSEM / ACSE
(2) (2) (3)
Layers Layers Layers
6 through 1 6 through 1 6 through 1
C12.22 Layer 4 C12.22 Layer 4 Target network
C12.22 Layer 2 C12.22 Layer 2 Interface
C12.22 Layer 1 C12.22 Layer 1
C12.22 device to C12.22 communication module interface(5) n (n >= 1) Any LAN/WAN/MAN

3576
3577
3578 Figure 2: C12.22 Communication module implementation model
3579
3580Annotations:
35811. Application Layer managed using C12.19 data tables, C12.22 PSEM language
3582 and ACSE /EPSEM encapsulation
35832. C12.22 Layers 6 through 1 used for communication and control messages
3584 exchanged between the C12.22 device and the C12.22 communication module, as
3585 described in this section.
35863. Corresponding layers 6 through 1 of the target network.
35874. Optional content and services.
35885. n is the C12.22 local interface number assigned to the C12.22
3589 Communication Module. The number of interfaces (n) zero, one or greater
3590 than one.
3591
3592
359369 Implementation guidelines
3594
3595C12.22 Communication module
3596
3597The C12.22 communication module shall minimally be able to:
3598• Implements layers 1-6 services as defined in this Standard;
3599• Initiates a Negotiate service to maximize packet sizes at startup;
3600• Optionally Initiates a Get configuration service at startup and upon
3601 receipt of Link Control service requests when the RELAOD_CONFIG_FLAG is set
3602 to true;
3603• Process and honor all configuration control directives received by the “Get
3604 Configuration Service”.
3605• Emit empty packets as prescribed for line supervision, to transition the
3606 attached C12.22 Device into the “Comm module present State”;
3607• Implement layers 1 and 2 on the C12.22 device interface side;
3608• Implement layers 1 to 6 on the network side.
3609• By default, forward all datagrams from the network side to the local
3610 interface side.
3611• By default, forward datagrams from the local interface side to the network
3612 side that not addressed to it.
3613• Intercept and process (may reject) the Send service <acse-pdu> ApTitles
3614 that are addressed to it through its local interface.
149 - LXXV -
150
3615• Recognize and perform Layer 2 local routing in support of data-link packet
3616 forwarding to the other attached C12.22 Communication modules.
3617• Recognize and correctly register the C12.22 Device using single or multiple
3618 interfaces ApTitle as needed.
3619• Recognize any ApTitle having its root ApTitle.<any-interface>.0.<interface-
3620 number> as its own ApTitle, where <interface-number> is the interface
3621 number assigned to this C12.22 Communication device.
3622 (TO REVIEW if MULTI_INTERFCACE_FLAG is removed)
3623
3624The C12.22 communication module can optionally implement its own table set
3625(Table 0 and any other tables as needed by its application). This table set
3626can be accessed from the network side by using the ANSI C12.22 protocol. In
3627this case, the communication module does not need to be registered. It is
3628accessed using the C12.22 device “<ap-title>.0 [.<interface-number>]”, which
3629is a sub-branch of any of the registered ApTiles for the attached C12.22
3630Device. When the C12.22 Device connects to more than one network (as indicated
3631by the Get Configuration Service <control> MULTI_INTERFACE bit = 1) then the
3632module needs to append the <interface-number> to the <aptile> which it
3633registers. As such it will be access using the C12.22 device “<ap-
3634title>.<interface-number>.0 [.<interface-number>]”, which is a sub-branch of
3635any of the registered ApTiles for the attached C12.22 Device.
3636(TO REVIEW if MULTI_INTERFCACE_FLAG is removed)
3637
3638This table set can also be accessed through the C12.22 device local port. In
3639this case, the called ApTitle shall be set to “.0[.<interface_number>]”, which
3640in turn will be forwarded by the C12.22 device to the C12.22 communication
3641module, on the requested interface.
3642
3643C12.22 interfaces are numbered sequentially from one to the number of
3644interface supported. For example, the second interface can be accessed using
3645the called ApTitle “<ap-title>.0.2”. The special C12.22 ApTitle “<ap-title>.0”
3646shall be interpreted when received by the C12.22 device as the “default C12.22
3647communication module interface”; and when received by the C12.22 communication
3648module as “this C12.22 communication module”.
3649
3650C12.22 Device
3651
3652The C12.22 Device shall minimally be able to:
3653• Implement the Negotiate, Get configuration, Link control and Send services
3654 as defined by this Standard;
3655• Initiate a Link Ctrl service as needed (e.g. after updates to Network
3656 tables) after the negotiate service; and
3657• Provide routing of APDUs from and to the C12.22 Device’s local access port,
3658 if one is available, to and from any C12.22 communication module, that is
3659 attached to it;
3660
3661In addition the C12.22 Device may be able to:
3662
3663• Provide a communication path from the local access port to any node on the
3664 LAN/WAN side of its C12.22 communication modules (optional capability
3665 subject to the C12.22 application <acse-pdu> forwarding restrictions);
3666• Provide a communication path from the LAN/WAN of any of its C12.22
3667 communication modules to any C12.22 communication module, that are attached
3668 to it (optional capability subject to the C12.22 application <acse-pdu>
3669 forwarding restrictions);
3670• Manage and control its network interfaces and C12.22 Communication Modules.
151 - LXXVI -
152
3671• Provide Network Tables is support of the management and operation of all of
3672 its network interfaces, attached C12.22 Communication Modules, local ports
3673 and services.
3674• Provide Network and interface-state information using its Network Tables.
3675• Accept and optionally process or reject APDUs arriving from any C12.22
3676 Communication Module using the Send service.
3677• Provide routing of APDUs from and to the C12.22 Device’s local interfaces,
3678 if any are available, to and from any C12.22 communication module attached
3679 to them.
3680
368170 Layer 7 - Application layer
3682Same as section 6.3 (Layer 7 – Application layer).
3683
368471 Layer 6 - Presentation layer
3685Null layer
3686
368772 Layer 5 - Session layer
3688Null layer
3689
369073 Layer 4 - Transport layer
3691For the purposes of enhanced clarity, the Negotiate service defined in layer 7
3692of ANSI C12.18 was moved to Layer 4 in this Standard. In addition, five
3693services were added to facilitate setup, management and communication with one
3694or more C12.22 communication modules. The transport layer services are defined
3695below.
3696
3697<tls-requests> ::= <tls-negotiate> | {Negotiate request}
3698 <tls-get-config> | {Get configuration request}
3699 <tls-link-control> | {Link control request}
3700 <tls-send-message> | {Send message request}
3701 <tls-get-status> | {Get status request}
3702 <tls-get-reg-status> {Get registration status request}
3703
3704<tls-responses> ::= <tls-negotiate-r> | {Negotiate response}
3705 <tls-get-config-r> | {Get configuration response}
3706 <tls-link-control-r> | {Link control response}
3707 <tls-send-message-r> | {Send message response}
3708 <tls-get-status-r> | {Get status response}
3709 <tls-get-reg-status-r>| {Get registration status
3710 response}
3711
3712 74 Negotiate service
3713
3714This service is initiated by the communication module after detection of the
3715presence of an attached C12.22 device.
3716
3717Request
3718<tls-negotiate> ::= <6jH><rec-packet-size><rec-nbr-packet>
3719 <baud-rates> <rec-nbr-of-channels>
3720
3721<6jH> ::= 60H | {No <baud rate> included in request. S-tay
3722 at default baud rate}
3723 61H | {1 <baud rate> included in request}
153 - LXXVII -
154
3732 6AH | {10 <baud rate> included in request}
3733 6BH | {11 <baud rate> included in request}
3734
3735<rec-packet-size> ::= <word16> {Maximum packet size in bytes that can be
3736 received by the C12.22 Communication
3737 module. This value shall not be greater
3738 than 8192 bytes.}
3739
3740<rec-nbr_packet> ::= <byte> {Maximum number of packets the C12.22
3741 Communication module is able to reassemble
3742 into an upper layer data structure at one
3743 time.}
3744
3745<baud-rates> ::= <baud_rate>* {List of baud rate supported by the C12.22
3746 Communication module. If the C12.22 Device
3747 cannot select one of these baud rates, the
3748 original baud rate is echoed in the
3749 response.}
3750
3751<baud_rate> ::= 00H | {Reserved}
3752 01H | {300 baud}
3753 02H | {600 baud}
3754 03H | {1200 baud}
3755 04H | {2400 baud}
3756 05H | {4800 baud}
3757 06H | {9600 baud}
3758 07H | {14400 baud}
3759 08H | {19200 baud}
3760 09H | {28800 baud}
3761 0AH | {57600 baud}
3762 OBH | {38400 baud}
3763 OCH | {115200 baud}
3764 ODH | [128000 baud}
3765 OEH {256000 baud}
3766 {0FH – FFH reserved}
3767
3768<rec-nbr-of-channels> ::= <byte> {The maximum number of concurrent channels
3769 supported in reception by the C12.22
3770 Communication module.}
3771
3772Response:
3773
3774The responses <err>, <sns>, <bsy>, and <isss> indicate a problem with the
3775received service request and the C12.22 Communication channel retains its
3776current settings.
3777
3778The response <ok> indicates the service request was accepted and the new
3779settings now apply.
155 - LXXVIII -
156
3780
3781<tls-negotiate_r> := <err> | <sns> | <bsy> | <isss> |
3782 <ok><trs-packet_size><trs-nbr_packet>
3783 <negotiated-baud-rate><trs-nbr_of_channel>
3784 <interface-number>
3785
3786
3787<trs-packet-size> ::= <word16> {Maximum packet size in bytes that can be
3788 received by the attached C12.22 Device.
3789 This value shall not be greater than 8192
3790 bytes.}
3791
3792<trs-nbr_packet> ::= <byte> {Maximum number of packets the attached
3793 C12.22 Device is able to reassemble into
3794 an upper layer data structure at one
3795 time.}
3796
3797<negotiated-baud-rate> ::= <baud_rate> {Baud rate to use for
3798 future communication on this interface.}
3799
3800<rec-nbr-of-channels> ::= <byte> {The maximum number of concurrent channels
3801 supported in reception by the C12.22
3802 Device.}
3803
3804<interface-number> ::= <byte> {The interface number assigned to this
3805 C12.22 Communication module.}
3806
3807
3808 75 Get configuration service
3809
3810This service is used solely by a C12.22 Communication Module to request its
3811configuration information from the C12.22 Device of which it is attached. In
3812this context, this C12.22 Device is also referred to within as the local
3813C12.22 Device. This service is initiated by the C12.22 Communication Module as
3814needed, any time after it detects the presence of the C12.22 device. The
3815information carried by this service is the same as that found in the Interface
3816control Table (Table 122).
3817
3818Request:
3819
3820<tls-get-config> ::= 72H
3821
3822
3823Response:
3824
3825The response <ok> indicate that the request have been accepted and the C12.22
3826Communication module configuration follows, in the response.
3827
3828<tls-get-config-r> ::= <sns> | <err> |
3829 <ok> <control> <interface-status> <node-type>
3830 <device-class> <esn>
3831 <native-address-len> <native-address>
3832 <broadcast-address-len> <broadcast-address>
3833 <relay-native-address-len> <relay-native-address>
3834 <node-ap-title>
3835 <master-relay-aptitle>
157 - LXXIX -
158
3836 [ <nbr-of-retry> <response-timeout> ]
3837
3838
3839<control> ::= <word16> {This is a bit-field that provides
3840 information and directives to the C12.22
3841 Communication Module about its expected
3842 operation. The control bits are defined as
3843 follows:
3844
3845 Bit 0: PASSTHROUGH_MODE
3846 This is a directive to the C12.22
3847 Communication Module regarding the
3848 forwarding to the C12.22 Device of
3849 messages that originate from the network
3850 side and that are addressed to the C12.22
3851 Communication Module.
3852
3853 The value 0 (false) indicates that the
3854 C12.22 Communication Module is required to
3855 forward to the C12.22 Device all messages
3856 even if they are addressed directly to the
3857 C12.22 Communication Module and regardless
3858 of whether it has the capability to
3859 process them. This is the default
3860 operating mode of any C12.22 Communication
3861 Module start-up.
3862
3863 The value 1 (true) indicates that the
3864 C12.22 Communication Module is permitted
3865 to intercept and process messages that
3866 are addressed directly to it if it has the
3867 capability to recognize them and process
3868 them. If it does not have such a
3869 capability, the C12.22 Communication
3870 module shall forward the messages to the
3871 C12.22 Devices across the local interface,
3872 according to the default behavior at
3873 start-up.
3874
3875 Bbit 1..15: RESERVED.}
3876
3877<interface-status> ::= <byte> {As defined by the Link
3878 control service. This filed is used by the
3879 C12.22 Device to configure its interface
3880 without issuing a Link control service
3881 after each power up.}
3882
3883<node-type> ::= <byte> {Node type as defined by the Registration
3884 service.}
3885
3886<device-class> ::= <byte>+ {C12.19 Device Class of the C12.22 Device.
3887 Four bytes containing the MANUFACTURER ID
3888 as defined in Table 0 of ANSI C12.19-1997
3889 or the registered END_DEVICE_CLASS as
3890 defined by ANSI C12.19-200x.}
3891
159 - LXXX -
160
3892<esn> ::= <absolute-uid-element> | <relative-uid-element>
3893 {A unique electronic serial number (ESN)
3894 that is assigned to a C12.22 device by its
3895 owner (or operator). The use of an ESN is
3896 optional and when not provided, the length
3897 of this element is set to zero.}
3898
3899<native-address-len> ::= <byte> {Number of bytes in <native-address>. This
3900 length is set to zero when this value is
3901 not configurable.
3902
3903<native-address> ::= <byte>+ {Native address assigned to the
3904 communication module.}
3905
3906<broadcast-address-len>::= <byte> {Number of bytes in <broadcast-address>.
3907 This length is set to zero when this value
3908 is not configurable.
3909
3910<broadcast-address> ::= <byte>+ {Broadcast address assigned to the
3911 communication module.}
3912<relay-native-address-len>::= <byte>
3913 {Number of bytes in <relay-native-
3914 address>. When the length of this element
3915 is zero then the nearest relay address is
3916 resolved and assigned by the communication
3917 module. When the length of this element is
3918 not zero then the communication module
3919 shall use this value as it’s new nearest
3920 relay address until such time that it is
3921 re-assigned by the C12.22 device.}
3922
3923<relay-native-address> ::= <byte>+ {Native address of the nearest relay used
3924 to maintain registration of this node.}
3925
3926<node-ap-title> ::= <absolute-uid-element> | <relative-uid-element>
3927 {The ApTitle of the C12.22 node to be
3928 registered with a master relay. When the
3929 length of this element is zero then the
3930 node’s ApTitle will be dynamically
3931 assigned.}
3932
3933<master-relay-aptitle> ::= <absolute-uid-element> | <relative-
3934 uid-element>
3935 {The ApTitle of the master relay used to
3936 register this device. When the length of
3937 this element is zero then the master
3938 relay’s ApTitle will be dynamically
3939 assigned.}
3940
3941<nbr-of-retry> ::= <byte> {Defines the number of times a request is
3942 sent if the response is not received
3943 within a <response-timeout>.}
3944
3945<response-timeout> ::= <word16> {Controls the number of seconds a C12.22
3946 Client has to wait for a response of a
161 - LXXXI -
162
3947 request before failing or sending
3948 retries.}
3949
3950
3951 76 Link control service
3952
3953This service is used by a C12.22 device to control a C12.22 communication
3954module. A C12.22 communication module shall never initiate this service.
3955
3956Request:
3957
3958<tls-link-control> ::= 73H <interface-ctrl>
3959
3960<interface-ctrl> ::= <byte> {Bit 0 to 1: INTERFACE_CTRL
3961 0 = Maintain current state
3962 1 = Enable this interface
3963 2 = Disable this interface
3964 3 = Reset this interface
3965
3966 Bit 2 to 3: AUTO_REGISTRATION_CTRL
3968 1 = Disable auto-registration
3969 2 = Enable auto-registration
3970 3 = Force one-time registration now then
3971 return previous state.
3972
3973 Bit 4 to 5: DIRECT_MESSAGING_CTRL
3975 1 = Enable direct communication
3976 with target nodes on the
3977 same network segment
3978 2 = Disable direct communication
3979 with target nodes on the
3980 same network segment
3981
3982 Bit 6: RESET_STATISTIC_FLAG
3983 false = Maintain current state
3984 true = Reset all statistics and counters
3985
3986 Bit 7: RELOAD_CONFIG_FLAG
3987 false = Maintain current state
3988 true = Initiate a Get configuration
3989 service to retrieve new configuration.}
3990
3991Response:
3992
3993The responses <ok> indicates that the request have been processed
3994successfully.
3995
3996<tls-link-control-r> ::= <sns> |
3997 <ok> <interface-status> <ap-title>
3998
3999
4000<interface-status> ::= <byte> {Bit 0: INTERFACE_FLAG
4001 This bit is set to true when the physical
4002 interface is enabled.
163 - LXXXII -
164
4003
4004 Bit 1: AUTO_REGISTRATION_FLAG
4005 This bit is set to true when C12.22
4006 Communication Module automatically
4007 registers the C12.22 Device on this
4008 interface.
4009
4010 Bit 2: DIRECT_MESSAGING_FLAG
4011 This bit is set to true when direct
4012 messaging is in use on this interface.
4013
4014 Bit 3..7: Reserved.}
4015
4016<ap-title> ::= <absolute-uid-element> | <relative-uid-element>
4017 {ApTitle registered on this interface.
4018 Required to be present (length different
4019 than zero) only when INTERFACE_CTRL is set
4020 to a value different than zero.}
4021
4022 77 Send message service (74H, 77 H)
4023
4024
4025This service is used by a C12.22 Device to send messages through an attached
4026C12.22 Communication Module or by the C12.22 communication module to transfer
4027each message received for C12.22 Device. This service carries the <acse-pdu>
4028(generated by two-way-devices) or <short-pdu>s (generated by one-way devices)
4029to be sent and the native address of the target or the initiator.
4030
4031Request:
4032
4033<tls-send-message> ::= <tls-send-acse-message> | <tls-send-short-message>
4034 { The service request, address and payload
4035 to be transmitted to and from a C12.22
4036 Communication Module across the Data Link
4037 as described in Section 7.9, “Layer 2 –
4038 Data Link”. }
4039
4040<tls-send-acse-message> ::= 74H <address-lgn> <address> <acse-pdu>
4041 {The message format of a send service
4042 request that carries an <acse-pdu>s as its
4043 payload data. It is the message format
4044 used by all two-way devices. This message
4045 format is the only one supported on all
4046 C12.22 Nodes on any C12.22 Network
4047 Segment.}
4048
4049<tls-send-short-message> ::= 77H <address-lgn> <address> <short-pdu>
4050 {The message format of a send service
4051 request that carries <short-pdu>s as its
4052 payload data. It is the message format
4053 used by some one-way devices to reduce the
4054 message size. This message format is
4055 recognized only by one-way designated
4056 native network segments and by one-way
4057 message enabled C12.22 Communication
165 - LXXXIII -
166
4058 Modules. It is the responsibility of
4059 C12.22 Communication Module to map the
4060 <short-pdu> to an <acse-pdu> upon delivery
4061 to its C12.22 Network Segment.}
4062
4063<address-lgn> ::= <byte> {Number of bytes in <address>.}
4064
4065<address> ::= <byte>+ {When issued by the C12.22 Communication
4066 module, the native address represents the
4067 source of the <acse-pdu> or the <short-
4068 pdu> on the local network segment. The
4069 C12.22 Communication Module shall always
4070 provide the native address.
4071
4072 When issued by the C12.22 Device Transport
4073 Layer, the native address represents the
4074 target node on the local network segment
4075 for this <acse-pdu> or <short-pdu>. This
4076 field is optional and when not provided,
4077 <address-lgn> is set to zero (00H).
4078
4079 Three methods are available to send
4080 information.
4081
4082 Directed message: when the <native-
4083 address> is provided, the C12.22
4084 Communication Module sends the <acse-pdu>
4085 or <short-pdu> to the specified address.
4086
4087 Direct messaging: when the <native-
4088 address> is not provided and
4089 DIRECT_MESSAGING_FLAG is set to false, the
4090 C12.22 Communication Module sends the
4091 <acse-pdu> to one of its nearest relay
4092 based on a default or internal routing
4093 table (C12.22 Communication Modules shall
4094 not transmit <short-pdu>s onto the C12.22
4095 Network).
4096
4097 Message forwarding: when the <native-
4098 address> is not provided and
4099 DIRECT_MESSAGING_FLAG is set to true, the
4100 C12.22 Communication Module shall use the
4101 <called-aptitle> of the <acse-pdu> or
4102 <short-pdu> to resolve the native address
4103 where to send this message.}
4104
4105
4106Response:
4107
4108The responses <nett>, <netr> indicate a problem during the transmission of
4109this message and can be returned only when this service is initiated by the
4110C12.22 device. The response <ok> indicates that the message have been
4111transmitted succesfully. . Responses may be expected only following a <tls-
4112send-acse-message> service request. Responses shall not be expected following
4113a <tls-send-short-message> service request
167 - LXXXIV -
168
4114
4115<tls-send-message-r>::= <tls-send-acse-message-r> | <tls-send-short-message-r>
4116
4117<tls-send-acse-message-r> ::= <nett> | <netr> | <ok>
4118
4119<tls-send-short-message-r> ::= {short messages do not expect responses.}
4120
4121
4122
4123 78 Get status service
4124
4125This service is used by a C12.22 device to retrieve information from a
4126communication module. The C12.22 communication module shall not initiate this
4127service request. The information carried by this service is the same as that
4128found in the Interface status Table (Table 125).
4129
4130Request:
4131
4132<tls-get-status> ::= 75H <status-ctrl>
4133
4134<status-ctrl> ::= <byte> {Control the information returned by this
4135 service.
4136 0 = Interface info and statistics
4137 1 = Interface info only
4138 2 = Statistics only
4139 3 = Statistics changed since last request}
4140
4141Response:
4142
4143The response <ok> is returned by the communication module with the available
4144information.
4145
4146<tls-get-status-r> ::= <err> |
4147 <ok>[<interface-info>]<statistics>*
4148
4149
4150<interface-info> ::= <interface-name-len>
4151 <interface-name>
4152 <interface-status>
4153
4154<interface-name-len> ::= <byte> {Number of bytes in <interface-name>.}
4155
4156<interface-name>::= <byte>+ {Textual description of the interface in 8
4157 bits ASCII format. For example an Ethernet
4158 interface that is attached to C12.22
4159 interface may be expressed as “Ethernet”.}
4160
4161<interface-status> ::= <byte> {As described by the Link control
4162 service.}
4163
4164
4165<statistics> ::= <statistic code> <statistic-value>
4166
4167<statistic-code> ::= <word16> {This code identify the associated
4168 <statistic-value>. The list of standard
169 - LXXXV -
170
4169 codes available is defined in the Network
4170 statistics table (Table 125).}
4171
4172<statistic-value> ::= <int48> {Statistic returned.}
4173
4174
4175 79 Get registration status service
4176
4177This service is used by a C12.22 device to get registration information from a
4178communication module. The information carried by this service is the same as
4179that found in the Registration Table (Table 126).
4180
4181Request:
4182
4183<tls-get-reg-status> ::= 76H
4184
4185
4186Response:
4187
4188The response <ok> is returned by the communication module with the available
4189information.
4190
4191<tls-get-reg-status-r> ::= <err> |
4192 <ok>
4193 <relay-native-address-len> <relay-native-address>
4194 <master-relay-aptitle> <node-ap-title>
4195 <reg-delay> <reg-period> <reg-count-down>
4196
4197
4198
4199<relay-native-address-len> ::= <byte> {Number of bytes in <relay-native-
4200 address>.}
4201
4202<relay-native-address>::= <byte>* {Native address of the nearest relay used
4203 to maintain registration of this node.}
4204<master-relay-aptitle> ::= <absolute-uid-element> | <relative-
4205 uid-element>
4206 {ApTitle of the master relay used to
4207 register this device.}
4208
4209<node-ap-title> ::= <absolute-uid-element> | <relative-uid-element>
4210 {ApTitle used to register this C12.22
4211 device through this interface.}
4212
4213<reg-delay> ::= <word16> {Maximum delay in second that the device
4214 should wait before registering after a
4215 power up.}
4216
4217<reg-period> ::= <word16> {Maximum period allows between two message
4218 received from the local relay. The device
4219 automatically register when this limit is
4220 reach.}
4221
4222<reg-count-down> ::= <word16> {The amount of time in minutes left before
4223 the registration period expired.}
171 - LXXXVI -
172
4224
4225 80 Time sequence diagram
4226
4227Negotiate
4228The following diagram shows messages exchanged between a C12.22 device and a
4229C12.22 communication module at startup.
4230
Device Comm Module Relay Device Information exchanged
Negotiate < Packet size, Number of packets, Baud rate,

Number of channel
> Packet size, Number of packets, Baud rate
Number of channel, Interface number
4231
4232Get Configuration
4233The following diagram shows messages exchanged when the C12.22 Communication
4234module retrieve its configuration from the C12.22 Device.
4235
[Link control]
< RELAOD_CONFIG_FLAG = true
> Interface status
Get config < None
> Node type, Device class, [ESN], [Native address]
[Broadcast address] , [Relay native address], [Node
ApTitle], [Master relay ApTitle]
4236
4237Link control (Enable network-side interface)
4238The following diagram shows the messages required for enabling a C12.22
4239communication module interface on the network side. It is important to note
4240that the use of the resolve service is optional and not needed if the
4241communication module already knows the native address of its nearest relay.
4242When the communication module supports multiple routes, the Resolve and
4243Register services are used multiple times to register each route. A different
4244ApTitle shall be used for each route.
4245
Link control > INTERFACE_CTRL = 1
[ Resolve ] > [Master relay ApTitle]

< Relay native address
> Node type, Connection type, Device class, [ApTitle],
Register [ESN], Native address, Registration period
< Node ApTitle, Registration delay, Registration period,
Direct messaging flag
< Interface status, Node ApTitle
…
Register (Keep live)
Same as previous Register
4246
4247
4248Link control (Disable network-side interface)
4249The following diagram shows the messages required for disabling a C12.22
4250interface.
173 - LXXXVII -
174
4251
Link control > INTERFACE_CTRL = 2
[Deregister] > Node ApTitle

< status
< Interface status
4252
4253Link control (Auto registration, Direct messaging or Reset statistic ctrl)
4254The following diagram shows the messages required for disabling a C12.22
4255interface.
Link control > INTERFACE_CTRL = 0,

AUTO_REGISTRATION_CTRL,
DIRECT_MASSAGING_CTRL,
RESET_STATISTIC_FLAG,
RELAOD_CONFIG_FLAG
< INTERFACE_FLAG,
AUTO_REGISTRATION_FLAG,
DIRECT_MESSAGING_FLAG
4256
4257Send message (Directed message)
4258The following diagram shows the messages exchanged when a service is generated
4259by a C12.22 device and Directed message is used.
4260
Send > Native address, ACSE pdu
Target network
send service > ACSE pdu
< status
4261
4262Send message (Direct messaging)
4263The following diagram shows the messages exchanged when a service is generated
4264by a C12.22 device and Direct messages is used.
4265
Send > ACSE pdu
[ Resolve ] > ApTitle

< Native address
Target network
< status
4266
4267Send message (Message forwarding)
4268The following diagram shows service sent though a C12.22 communication module.
4269
175 - LXXXVIII -
176
Send message > ACSE pdu
Target network
> status
Target network
4270
4271Send message (Message received)
4272The following diagram shows the messages exchanged when a service is received
4273by a C12.22 device.
4274
< ACSE pdu
Send < Native address, ACSE pdu

> status
4275
4276Get Status
4277The following diagram shows the execution of a Get status service.
4278
Get Status < Status ctrl

> Interface name, Interface status
(Statistic code/Statistic value)*
4279
4280Get Registration Status
4281The following diagram shows the execution of a Get status service.
4282
Get Reg Status > None

< Relay native address, Master relay ApTitle,
Node ApTitle, Registration delay, Registration period,
Registration countdown
4283
177 - LXXXIX -
178
4284
4285
4286 81 Service sequence state
4287
4288This layer is defined as a series of “Service Sequence States, valid states
4289include:
4290
4291TO DO – Replace State name
4292Comm module
4293disconnected
4294state: Initial state entered after power up or re-entered after
4295 layer 2 has detected a lack of activities with the
4296 communication module. In this state, the interface may be
4297 used as a C12.22 Local port. Refers to the C12.22 Local
4298 access port section for the definition of the service
4299 sequence state used in that case.
4300
4301Comm. Module present State:
4302 State entered after the detection of a communication
4303 module by layer 2.
4304
4305On network State: State entered after the communication module has reported
4306 that the interface is enabled (INTERFACE_FLAG set to
4307 true).
4308
4309The relationship between services and service sequence states is:
4310
4311Negotiate: This service is accepted at the “Local access” state
4312 only.
4313
4314Get configuration: This service is accepted at any state.
4315
4316Link control: This service is accepted at both the “Comm module
4317 present” and “On network” states. This service is used to
4318 move between these two states based on the value of
4319 INTERFACE_CTRL field.
4320
4321Send message: This service can be accepted at the “Local access” state
4322 to locally access the device and at the “On network”
4323 state to send and receive messages to or through the
4324 communication module.
4325
4326Get status: This service is accepted both in the “Comm module
4327 present” and “On network” states.
4328
4329Get registration status:
4330This service is accepted at both the “Comm module present” and “On network”
4331 states.
4332
4333TO DO - Create a different state diagram for the C12.22 Device
179 - XC -
180
Power up
Comm module
disconnected
state
- Negotiate
Exit of the Active state - Get configuration
reported by layer 2 - Get status
Active state
reported by layer 2 - Get registration status
Comm module - Link control
present State (INTERFACE_CTRL = 0)
- Link control - Link control

(INTERFACE_CTRL = 1,3) (INTERFACE_CTRL = 2,3)
- Send message
Interface time-out / On network - Get status
Layer 2 connection lost State - Get registration status
- Get configuration
- Link control
(INTERFACE_CTRL = 2)
4334
4335 Figure 3. Network layer state diagram
4336
433782 Layer 3 - Network layer
4338Null layer
4339
434083 Layer 2 - Data link layer
4341
4342This layer is used only for communication between the end device and the
4343network communication module. For the purposes of enhanced clarity, the
4344Negotiate service have been re-categorized in this layer. However, no syntax
4345or protocol changes are required by this standard for this service.
4346
4347The datagrams of upper layers are transported in one or more packets. Each
4348packet is variable in length but cannot exceed a maximum packet size. The
4349maximum packet size has a default value when the communication link is opened.
4350The maximum packet size and number of packets can be changed through the use
4351of the negotiate service.
4352
4353The end device may support transfer of multiple datagrams at the same time.
4354To accomplish this, a different channel number is associated for each
4355simultaneous datagram transmitted. Based on this identifier, the other end can
4356reassemble each fragment (packet) with the right datagram.
4357
4358For each packet received, the target sends a positive or an optional negative
4359acknowledgment. This acknowledgment consists of a single byte transmitted
4360outside of the packet structure or inside a packet structure if requested by
4361the TRANSPARENCY flag. If the requester does not receive an acknowledgment
4362before the Response Timeout, or a negative acknowledgment is received, the
4363same packet is re-transmitted up to the current maximum number of negotiated
181 - XCI -
182
4364retry attempts. After the final retry attempt, the requester should assume
4365that the communication link is down and try to reestablish it.
4366
4367This layer also supports line supervision by the transmission of empty packets
4368to avoid traffic time-out. An empty packet is defined as a <packet> without
4369the <reason-code> and <data> fields.
4370
4371
4372 84 Basic data information
4373
4374Communication link settings are specified below.
4375
437685 Fixed Settings
4377
DATA FORMAT 8 data bits, 1 start bit, 1 stop bit, no parity
DATA TYPE Asynchronous, serial bit (start - stop), full
duplex
DATA POLARITY Start bit, space, logical 0
Stop bit, mark, logical 1, quiescent state
Bit order Bits within each byte are transmitted least
significant bit first with the least significant
bit identified as bit 0 and most significant bit
as bit 7.
TRAFFIC TIMEOUT 6 seconds
INTER-CHARACTER TIMEOUT 500 milliseconds
RESPONSE TIMEOUT 2 seconds
RETRY ATTEMPTS 3
4378
437986 Variable Settings
4380
4381Default settings apply at the initiation of communication. These settings may
4382be changed through the Negotiate service. Communication link settings will
4383return to defaults as a result of a traffic time-out.
4384
Setting Default Value Changed by
DATA RATE 9600 baud Negotiate
NUMBER OF PACKETS 1 Negotiate
PACKET SIZE 64 bytes Negotiate
4385
4386 87 Packet definition
4387
4388<packet> ::= <stp> <identity> <ctrl> <seq_nbr> <length> <data> <crc>
4389
4390<stp> ::= EEH {Start of packet character.}
4391
4392<identity> ::= <byte> {Identity.
4393 Bits 3 to 7: LOCAL_ADDRESS_NUMBER
4394 This field is used to facilitate routing
4395 of information between a local port and
4396 the local C12.22 Communication modules.
4397 This field can be set to the following
4398 values:
4399 0 = C12.22 Device
183 - XCII -
184
4400 1 =
Local Port 0 (Default)
4401 2 =
Local Port 1 (Alternate)
4402 3 =
Interface 0 (Default WAN)
4403 4 =
Interface 1 (Alternate WAN)
4404 5 =
Interface 2
4405 (Default POT modem)
4406 6 = Interface 3
4407 (Alternate POT modem)
4408 7 to 12 = Reserved
4409 13 to 28 = Manufacturer defined
4410 29 = Invalid (to avoid <stp>)
4411 30 to 31 = Reserved for future
4412 extension of this field
4413
4414 Bits 0 to 2: CHANNEL NUMBER
4415
4416 Bits 0 to 2: CHANNEL NUMBER
4417 This field allows simultaneous transfer of
4418 multiple segmented <acse-pdu>. A different
4419 number is assigned dynamically by the
4420 C12.22 Device or by the C12.22
4421 Communication module for each <acse-pdu>
4422 message transferred simultaneously.}
4423
4424<ctrl> ::= <byte> {Control field.
4425 Bit 7: MULTI_PACKET_TRANSMISSION
4426 If true (1H) then this packet is part of a
4427 multiple packet transmission.
4428
4429 Bit 6: FIRST_PACKET
4430 If true (1H) then this packet is the first
4431 packet of a multiple packet transmission.
4432 (MULTI_PACKET_TRANSMISSION, bit-7, is also
4433 set to 1) otherwise this bit shall be set
4434 to 0.
4435
4436 Bit 5: TOGGLE_BIT
4437 Represents a toggle bit to reject
4438 duplicate packets. This bit is toggled for
4439 each new packet sent. Retransmitted
4440 packets keep the same state as the
4441 original packet sent. After a traffic
4442 time-out the state of the toggle bit may
4443 be re-initialized, thus it is assumed to
4444 be indeterminate.
4445
4446 Bit 4: TRANSPARENCY
4447 If true, this packet uses the transparency
4448 mechanism as described in the
4449 “Transparency” section. Also the target
4450 shall respond with an ACK or optional NACK
4451 inside the packet structure as described
4452 in the “Acknowledgment” section.
4453
4454 Bits 2 to 3: ACKNOWLEGMENT
185 - XCIII -
186
4455 Used to acknowledge the reception of a
4456 valid on invalid packet. Acknowledgment
4457 and response data can be sent together in
4458 the same packet or as two consecutive
4459 packets.
4460 0 = Acknowledged data packet
4461 1 = Ack optionally piggyback an optional
4462 acknowledged data packet
4463 2 = Nack optionally piggyback an optional
4464 acknowledged data packet
4465 3 = Unacknowledged data packet
4466
4467 A possible use of option 3 is when a one-
4468 way device send blurts which don’t require
4469 acknowledgments. In this context, the
4470 C12.22 Device shall be the originator of
4471 all messages. This is an indication to the
4472 C12.22 Communication Module to disable the
4473 ACK/NAK packet handshake for one-way
4474 devices. The C12.22 Communication Module
4475 shall operate at its default settings as
4476 listed in Sections 7.9.1.1 and 7.9.2.1
4477 unless the Negotiate Service was
4478 successful in changing the default
4479 settings.
4480
4481 Bit 0 to 1: DATA_FORMAT
4482 0 = C12.18 or C12.21 Device
4483 1 = C12.22 Device
4484 2 = Invalid (to avoid <stp>)
4485
4486 3 = Reserved }
4487
4488<seq_nbr> ::= <byte> {Number that is decremented by one for
4489 each new packet sent. The first packet in
4490 a multiple packet transmission shall have
4491 a <seq_nbr> equal to the total number of
4492 packets minus one. A value of zero in this
4493 field indicates that this packet is the
4494 last packet of a multiple packet
4495 transmission. If only one packet is in a
4496 transmission, this field shall be set to
4497 zero.}
4498
4499<length> ::= <word16> {Number of bytes of <data> in packet.}
4500
4501<data> ::= <byte>+ {<length> number of bytes of actual packet
4502 data. This value is limited by the maximum
4503 packet size minus the packet overhead.
4504 This value can never exceed 8183.}
4505
4506<crc> ::= <word16> {HDLC implementation of the polynomial X16
4507 + X12 + X5 + 1}
4508
4509 88 CRC selection
187 - XCIV -
188
4510
4511The CRC selected for implementation is the polynomial X16 + X12 + X5 + 1. The
4512method for calculation and insertion is the HDLC standard per ISO 3309-1993(E)
4513Annex A “EXPLANATORY NOTES ON IMPLEMENTATION OF THE FRAME CHECKING SEQUENCE”.
4514
4515In the PSEM frame, there is no opening flag as referenced in ISO 3309-1993(E)
4516Annex A. The PSEM start of packet character EE is included in the CRC
4517calculation. The result of the CRC calculation shall be transmitted least
4518significant byte first per the ISO 3309 Annex. See Annex D for examples of
4519computation and coding.
4520
4521 89 Acknowledgment
4522
4523A positive or negative acknowledgment is used by the communicating devices to
4524indicate either acceptance or rejection of a packet.
4525
4526An <ack> is issued by the receiving device to the transmitting device for each
4527packet received that meets the constraints established by this section.
4528
4529<ack> ::= 06H | <packet>
4530
4531An optional <nak> is issued by the receiving device to the transmitting device
4532for each packet received that does not meet the constraints established by
4533this section. A <nak> shall only be issued by the receiving device to the
4534transmitting device for each corrupt packet addressed to the receiving device.
4535If the <identity> field of the packet is not received or does not match that
4536of the receiving device, the receiving device should not respond at all.
4537Examples of problems with received packets indicated by a <nak> response
4538include CRC errors, packet structure errors, incorrect bit patterns and
4539missing characters.
4540
4541<nak> ::= 15H | <packet>
4542
4543 90 Retry attempts
4544
4545The same packet shall be retransmitted if a <nak> is received, or the response
4546time-out occurs.
4547
4548After the failure of the final retry attempt, the communication link is
4549considered down and the network communication module have to reestablish it by
4550sending an optional Negotiate service and a Link Setup service. The retry
4551scheme used by the network communication module is not defined in this
4552document and is let to the manufacturer’s discretion.
4553
4554 91 Timeouts
4555
455692 Traffic Time-out
4557
4558The end device will consider the communications link down after waiting some
4559period of time for a valid packet or acknowledgment. This period of time, is
4560defined as the traffic time-out.
4561
456293 Inter-Character Time-out
4563
189 - XCV -
190
4564The recipient of the packet must handle the case when the end of a packet is
4565lost. Inter-character time-out is defined as the minimum amount of time the
4566recipient shall wait between characters within a packet when receiving data
4567over the communication link. The recipient shall wait at least this amount of
4568time before it ceases to wait for the remainder of the packet and sends a
4569<nak>. This time-out is not used when the NO_NACK option is negotiated
4570successfully by the Link setup service.
4571
457294 Response Time-out
4573
4574The sender of the packet must handle the case when the acknowledgment or
4575negative acknowledgment is lost. Response time-out is defined as the minimum
4576amount of time the sender shall wait after a packet is sent to receive an
4577acknowledgment over the communication link. If this amount of time elapses,
4578the sender will send the packet again.
4579
4580 95 Turn around delay
4581
4582The turn around delay is the minimum delay the recipient must wait after
4583receiving a packet and before sending a positive or negative acknowledgement.
4584
4585
4586 96 Duplicate packets
4587
4588A duplicate packet is defined as a packet whose identity, toggle bit and valid
4589CRC are identical to those of the immediate previous packet. If a duplicate
4590packet is received by the target device, the target should disregard the
4591duplicate packet and return an <ack>. At the start of session, the toggle bit
4592in the first packet may assume either state.
4593
4594 97 Transparency
4595
4596The "Basic Transparency" method is requested by the TRANSPARENCY bit in the
4597<ctrl> byte.. This method replaces any occurrence of the Start of Packet by a
4598two octets escape sequence.
4599
4600After CRC computation, the transmitter shall replace any occurrence of the
4601Start of Packet or Escape flag found inside the packet by a two octet sequence
4602consisting of the Escape flag and the original octet with bit 5 complemented.
4603Prior to CRC computation, the receiver removes every occurrence of the Escape
4604flag and invert bit 6 of the following octet.
4605
4606Therefore, the following replacement shall result.
4607
4608 Transmitted Received
4609 1BH -> 1BH 3BH 1BH 5BH -> 1BH
4610 EEH -> 1BH CEH 1BH CEH -> EEH
4611
4612 98 Supervision of the communications link
4613
4614The communications module is assumed to continually poll the end device using
4615the “EMPTY PACKET” service. Any message transported in either direction that
4616is confirmed by an acknowledgement can be accepted to reset the traffic timer.
4617If the timer times out, the link can enter the “Disconnected state”. The End
191 - XCVI -
192
4618device, at its option, can activate a reset of the communications module (and
4619perhaps itself) to re-establish the link and re-enter the “Connected state”.
4620
4621The end device has the responsibility to supervise the communications module
4622for proper performance on all communications levels. The method for concluding
4623a communications module malfunction is at the discretion of the manufacturer.
4624Upon determination that the communications module is in an “insane” state or
4625needs resetting for any reason, the end device may perform a reset of the
4626communications module by dropping the RESET line for greater than 50msec and
4627less than 5 sec.
4628
4629 99 Local routing
4630
4631The LOCAL_ADDRESS_NUMBER field defined in the <identity> byte is used to
4632facilitate routing of <acse-pdu> among Local Ports and C12.22 Communication
4633modules. Layer 2 local routing shall be implemented by all C12.22 Devices to
4634facilitate C12.22 Communication Module setup and diagnostics. It is highly
4635recommended that this service be used by C12.22 Communication Modules to route
4636<acse-pdu> received from one interface and targeting a different interface or
4637Local Port as defined by the “Use of sub-branches of register ApTitle”
4638section, subsection “Access to Interface and Local Ports”.
4639
4640General Considerations
4641
4642• Each packet send by a device attached to a local port or a C12.22
4643 Communication Module has its LOCAL_ADDRESS_NUMBER set to the desired
4644 destination.
4645• Each packet received by a C12.22 Device with the LOCAL_ADDRESS_NUMBER field
4646 set to non-zero is forward to the requested destination. Because routed
4647 packets exist outside the context of a session on the device doing the
4648 routing, packet size for routed packets must not exceed the default layer 2
4649 maximum size set by this standard (64 bytes) to avoid re-segmentation by
4650 the C12.22 Device.
4651• Each packet received by a C12.22 Device with the LOCAL_ADDRESS_NUMBER field
4652 set to zero is intended for that device. Such packets may therefore be
4653 larger than 64 bytes if a larger size has been successfully negotiated via
4654 the protocol.
4655
4656Routing rules for C12.22 Device
4657
4658For the purposes of this section, the word “port” is intended to mean either a
4659Local Port of a C12.22 Device or a C12.22 Communications Module interface to a
4660C12.22 Device. The routing rules are applied only after the packet has been
4661verified to be valid and non-duplicate. The LOCAL_ADDRESS_NUMBER refers to a
4662destination port.
4663When the C12.22Device receives a packet which has the LOCAL_ADDRESS_NUMBER
4664equal to zero, it means that the packet is for this C12.22 Device, so such
4665packets should be ACK’d and passed up to the upper layers of this C12.22
4666Device for processing.
4667
4668If the C12.22 Device receives a packet with a LOCAL_ADDRESS_NUMBER equal to
4669some nonzero port number, the Device shall apply the following rules, in this
4670order:
4671
193 - XCVII -
194
46721. If the destination port is busy (i.e. a packet has been sent to that port
4673 but has not yet been ACK’d), silently discard the packet.
46742. If the destination port does not exist or it is already known to the C12.22
4675 Device that no C12.22 Communications Module is attached to that port, ACK
4676 the packet and then either discard it or optionally pass it up to higher
4677 layers so that an appropriate Application Layer error response may be
4678 returned
46793. Send an ACK to the source port and then modify the packet, replacing the
4680 LOCAL_ADDRESS_NUMBER in the packet with the source port number.
4681 Recalculate the CRC and forward this packet to the destination port.
4682
4683Routing rules for C12.22 Communication Modules
4684
4685For the purposes of this section, the word “port” is intended to mean either a
4686Local Port of a C12.22 Device or a C12.22 Communications Module interface to a
4687C12.22 Device. The routing rules are applied only after the packet has been
4688verified to be valid and non-duplicate.
4689
4690When the C12.22 Communication Module receives a packet which has the
4691LOCAL_ADDRESS_NUMBER equal to zero, it means that the packet is for this
4692C12.22 Communication Module, so such packets should be ACK’d and passed up to
4693the upper layers of this C12.22 Communication Module for processing.
4694
4695If the C12.22 Communication Module receives a packet which has a
4696LOCAL_ADDRESS_NUMBER other than zero, this LOCAL_ADDRESS_NUMBER signifies
4697where the response (if any) should be sent. The C12.22 Communcation Module
4698should ACK the packet and pass the packet contents, including the
4699LOCAL_ADDRESS_NUMBER, up to the upper layers of this C12.22 Communication
4700Module for processing.
4701
4702
4703 100 Service sequence state
4704
4705Data link layer communications is defined as a series of “Service Sequence
4706States”.
4707
4708Valid states include:
4709
4710Disconnected State: State enters after power up or upon communication link
4711 drop detection. All parameters defined in the Variable
4712 Settings section return to their defaults.
4713
4714Connected State: State establishes upon detection of a valid message
4715 transfer. The Negotiate service and the Link Setup are
4716 the only layer 2 services supported. They can be
4717 requested in any order at any time.
4718
195 - XCVIII -
196
Not detected Connected
State
Reset
Detected
Traffic
timeout
Any valid
traffic
Disconnected
State
Break
detected Active State
Reset
Any valid traffic

4719
4720 Figure 5. Link Layer State Diagram
197 - XCIX -
198
4721
4722101 Layer 1 - Physical layer
4723
4724This physical layer is defined for the External interface between the C12.22
4725Device and the external network communication modules. An Internal interface
4726is not defined by this Standard but should provide the services defined by
4727this section.
4728
4729 102 Signal definition
4730
Signal # Signal Description C12.22 Device C12.22 Comm. Module
DTE DCE
1 RxD Receive Data Input Output
2 TxD Transmit Data Output Input
3 RESET Module Reset Output Input
5 VPLUS C12.22 Comm. Module power supply Output Input

6 GND Ground/Common
4731
4732
4733 103 Electrical properties of connection
4734
4735The following properties are required for the interface lines:
4736
4737 • Each side of the interface shall provide a pull-down resistor to common
4738 on its input (Signal #1 for the C12.22 Device, Signal #2 for the C12.22
4739 Communication Module). This pull-down enables supervision of the signal
4740 line and enables detection of a mated connection on that line. All
4741 transmitters output an idle logical 1, positive voltage, so that
4742 connection can be detected.
4743• VPLUS may provide power to the C12.22 Communication Module. If VPLUS does
4744 provide power, a C12.22 Device is expected to provide up to 1.5 W with a
4745 voltage range of 6-12V.
4746• If a C12.22 Device does not provide power to VPLUS, it shall be left
4747 disconnected allowing a compliant external power supply to drive VPLUS for
4748 the attached C12.22 Communication Module.
4749• The RESET is the means for the C12.22 Device to reset the C12.22
4750 Communication Module. The RESET signal should be active low with a pulse
4751 of 50 ms or greater.
4752• Voltage input high >2.5V, logical 1
4753• Voltage input low level <=0.8V, logical 0
4754• Idle voltage of link is logical 1.
4755• Maximum output voltage shall be less than or equal to the supplied VPLUS
4756 voltage or 12V when VPLUS is not present.
4757• Source impedance of output lines shall be <= 1K Ohms
4758• Input impedance of input lines shall be >= 100K Ohms
4759• Data Rate
4760 o Minimum of 300 bits / sec
4761 o Nominal of 9600 bits / sec (default)
4762 o Maximum of 1 Mbits / sec
4763• All signals shall meet ANSI C37.90.1-2002 requirements.
4764• The C12.22 Device or C12.22 Communication Module should provide line
4765 isolation on any and all physical wire and plug pins exiting from under the
4766 meter cover. The insulation must be rated to ANSI C12.1-2001 insulation
199 - C -
200
4767 2.5kV test requirements between all voltage and current carrying parts and
4768 all other metallic parts.
4769• All C12.22 Device or C12.22 Communication Module wires, plugs, contacts and
4770 metallic parts exiting the meter cover shall meet electrostatic discharge
4771 (ESD) testing to 10kV.
4772• All C12.22 Device or C12.22 Communication Module wires, plugs, contacts and
4773 metallic parts exiting the meter cover shall meet ANSI C62.41-2002 for
4774 voltage and current carrying parts.
4775• Maximum connection length is 1 meter at up to 1 Mbits / sec.
4776
4777 104 Mechanical and environmental properties
4778
4779This section defines connectors for the physical layer of C12.22 interface
4780between a C12.22 Device and a C12.22 Communication Module when this connection
4781is exposed externally (see definition of External Interface) on the respective
4782parts.
4783
4784This specification assumes that the environmental protection and strain relief
4785is integrated into the enclosure containing the connector. Modular plug
4786cabling is used to connect from a C12.22 Device to a C12.22 Communications
4787Module that will each contain a modular jack for termination. Below are
4788typical parts for the C12.22 Device and C12.22 Communications Module.
4789Equivalent parts are acceptable.
4790
4791Connector for C12.22 Device: RJ11 Jack (typical part AMP520250-2)
4792Connector for C12.22 Communications Module: RJ11 Jack (typical part
4793AMP520250-2)
4794
RJ11 Jack Front View Cable Plug View
Pin 1
1 2 3 - 5 6
4795
4796
4797 Figure 6: Jack and Cable Plug Wiring Diagram
4798
4799Figure 6 shows the mapping of the signals defined in 7.10.1 to the pins in the 6-pin RJ11 jack and plug.
4800
4801 105 Supervision of the communications link
4802
4803Either the communications module or the end device can detect the other by the
4804presence of a marking signal (logical 1) on the corresponding transmit or
4805receive data line. By detecting the “break” condition (continuous logical 0)
4806disconnection can be determined.
201 - CI -
202
4807106 Local Port communication protocol details
4808
4809This section defines the protocol stack used by C12.22 Local Ports.
4810
4811107 Protocol definition
4812
4813 108 Layer 7 - Application layer
4814
4815As defined in section 6.3 (Layer 7 – Application layer).
4816
4817To access a C12.22 Node or one of its interfaces through a Local Port, a
4818C12.22 Node that is attached through the Local Port does not have to include
4819the <calling-aptitle-element> and <called-aptitle-element> in <acse-pdu>s
4820transmitted. The data link LOCAL_ADDRESS_NUMBER is used as described in
4821section 7.9.10 (Local routing).
4822
4823Optionally, an interface may be used as a proxy to send messages over the
4824C12.22 Network as defined in section 6.3.3.13 (Use of sub-branches of a
4825register ApTitle). In this case, both the <called-aptitle-element> of the
4826targeted C12.22 Node and the LOCAL_ADDRESS_NUMBER of the interface used to
4827send this message are provided.
4828
4829 109 Layer 6 - Presentation layer
4830
4831Null layer
4832
4833
4834 110 Layer 5 - Session layer
4835
4836Null layer
4837
4838
4839 111 Layer 4 - Transport layer
4840
4841The Local Port shall operate as ANSI C12.22 device. As such, layer 4 shall
4842operate as per Section 7, “Protocol details of a C12.22 device to C12.22
4843communication module interface”. Also, the only service supported in Layer 4
4844shall be the <tls-negotiate> and the <tls-send-message>.
4845
4846The state diagram of this layer used in this context differs from the one
4847defined in section 7.7.0.8. For point-to-point communication, the following
4848states are defined:
4849
4850Base state: This is the state at which communication begins. At this
4851 point the default data transmission parameters apply.
4852
4853Negotiated state: At this state, the parameters negotiated by the Negotiate
4854 service apply.
4855
4856The relationship between services and service sequence states is:
4857
4858Negotiate: This service is accepted at the “Base state” state only. The successful
4859 completion of this service (Including the transmission of the response)
4860 transitions communications to the Negotiated state. This service can’t be
203 - CII -
204
4861 used to negotiate the <rec-packet-size> and <rec-nbr-packet> when
4862 communication with an interface,
4863
4864Send message: This service can be accepted at “Base state” state and “Negotiated state” to
4865 send and receive Layer 7 messages.
4866
4867
Base state
Send message service
Traffic timeout
Too many reties Negotiate service
Layer 7 Disconnect service
Negotiated
state Send message service
4868
4869
4870 Figure 4, Transport layer state diagram
4871 112 Layer 3 - Network layer
4872
4873Null layer
4874
4875 113 Layer 2 - Data link layer
4876
4877As defined in section 7.9 (Layer 2 - Data link layer).
4878
4879Timeouts are fixed for each type of communication link; these timeouts are
4880defined as follows:
4881
Local Port timeouts Interface Optical port Modem
TRAFFIC TIMEOUT 6 seconds 6 seconds 30 seconds
INTER-CHARACTER TIMEOUT 500 500 1 second
milliseconds milliseconds
RESPONSE TIMEOUT 2 seconds 2 seconds 4 seconds
TURN-AROUND DELAY Unspecified 175 Unspecified
microseconds
4882
4883 114 Layer 1 - Physical layer
4884
4885The physical layer is not defined in this document.
4886
4887
4888115 C12.22 Local Port communication using a C12.18 optical port
4889
4890Some C12.22 Nodes may implement a Local Port (see detailed definition of Local
4891Port) of the form and type defined in ANSI C12.18. Under this condition a two
4892possibilities are considered:
4893
4894The Local Port (such as ANSI type II attached to an End Device) supports both
4895the ANSI C12.22 Standard and ANSI C12.18 Standard. As such, this section
4896describes a methodology of a “smart” C12.18 Device (e.g. hand held reader), to
205 - CIII -
206
4897determine that the Local Port supports the C12.22 communication protocol, and
4898then choose to communicate using ANSI C12.18 or ANSI C12.22 at its option.
4899The Local Port supports only the ANSI C12.22 communication. As such, the
4900C12.22 reader can only communicate (no option) using the C12.22 standard
4901communication protocol.
4902
4903(Another possible implementation of a C12.22 Node is one that has an optical
4904port but does not support C12.22 over the optical port. This possibility is
4905not considered in this section.)
4906
4907When communicating in ANSI C12.18 compatibility mode, the optical port shall
4908operate as ANSI C12.18 device. As such, all physical, data link and
4909application layer services shall comply with ANSI C12.18.
4910When communicating in ANSI C12.22 compatibility mode, the optical Local Port
4911shall operate as defined in section 8.1 and Layer 1 (physical layer of the
4912optical port) shall operate according to ANSI C12.18 Physical Layer
4913requirements.
4914
4915 116 Establishment of ANSI C12.18 protocol compatibility mode
4916
4917The C12.22 communications protocol standard provides optional optical port
4918compatibility with C12.18.
4919
4920Any C12.18 compatible reading device desiring to successfully connect to a
4921C12.22 Local Port, shall set bit 0 in DATA_FORMAT of the <ctrl> byte to 0 in
4922each transmitted <packet>. This control bit is found in the <packet> defined
4923in communication module Section 7.9.2, “Packet definition”.
4924
4925Consequently, the C12.22 Node (having a Local Port) shall also set bit 0 in
4926DATA_FORMAT of the <ctrl> byte in each transmitted <packet> to 0 then enter
4927C12.18 compatibility mode, if supported. If the C12.18 compatibility mode is
4928not supported by the Local Port, the C12.22 Node (having a Local Port) shall
4929either “not acknowledge” any incoming <packet> having DATA_FORMAT bit 0 set
4930to 0 or respond with a <nak>. If the Local Port (of the C12.22 Node) does
4931support C12.18 communication, it shall communicate according with ANSI C12.18
4932protocol definition thereafter.
4933
4934The actual protocol implementation type may be confirmed by the reader by
4935inspecting the <std> field returned being zero in the <ident_r> service
4936response from the optical port.
4937
4938 117 Establishment of ANSI C12.22 protocol compatibility mode
4939
4940The C12.22 communications protocol standard provides optional optical port
4941compatibility with C12.22.
4942Any C12.22 compatible reading device, desiring to successfully connect to a
4943C12.22 Local Port, shall set bit 0 in DATA_FORMAT of the <ctrl> byte to 1 in
4944each transmitted <packet>. This control bit is found in the <packet> defined
4945in communication module Section 7.9.2, “Packet definition”.
4946
4947Consequently, the C12.22 Node (having a Local Port) shall also set bit 0 in
4948DATA_FORMAT of the <ctrl> byte in each transmitted <packet> to 1 and then
4949enter C12.22 compatibility mode. The C12.22 Nodes shall communicate
4950according with ANSI C12.22 protocol definition thereafter, as described in
4951this document.
4952
207 - CIV -
208
4953The actual protocol implementation type may be confirmed by the reader by
4954inspecting the <std> field returned being three in the <ident_r> service
4955response from the optical port.
209 - CV -
210
4956118 Backward compatibility
4957Backward compatibility of C12.22 with C12.18 and C12.21 is in relation to
4958layer 7 services, service parameters, datagram data format and transmission
4959order.
4960
4961C12.22 is backward compatible with C12.18 and C12.21 at the application layer.
4962The C12.22 application layer datagram is formatted in a way which enable
4963C12.18 or C12.21 compliant devices and gateways to recognize the C12.22
4964application datagrams (and services) so that they can take one of the
4965following actions:
4966
4967• reject the datagram or;
4968• strip the C12.22 additional information to yield a C12.18 or C12.21
4969 compliant datagram in its original form or;
4970• strip the C12.22 additional information to yield a C12.18 or C12.21
4971 equivalent datagram for the purpose of interpretation or translation into
4972 other protocol.
4973
211 - CVI -
212
4974
4975ANNEX A - Relays
4976
4977NORMATIVE
4978
4979Description
4980
4981C12.22 relay provides two basic services: address resolution and messages
4982forwarding.
4983
4984C12.22 message forwarding is an optional service and implemented only if the
4985lower layers does not already provide routing (Heterogeneous network).
4986Message fowarding is considered less desirable than using lower layer routing
4987since it allows only transmission of C12.22 messages. This service is accessed
4988by simply sending an <acse-pdu> to a relay with an called ApTitle different
4989that the relay ApTitle. The relay will automatically forward this message to
4990the next relay or next relay on this route.
4991
4992Address resolution is used to map C12.22 ApTitle to the corresponding native
4993address. Two ways are provided to access this service, the first method
4994consist of using a Resolve request with the target ApTiTle as parameter. The
4995resolve response contains the native address of the requested node if this
4996node reside on the same network segment. Future communication with this node
4997can be accomplished by addressing this node with its native address. The
4998second technique consist of simply sending a message to the relay with a
4999called ApTitle different that the relay ApTitle. In this case the relay does
5000the address resolution and forwards the information to the target node.
5001
5002
5003Hierarchical topology
5004
5005C12.22 relay services are used between heterogeneous network segment for
5006forwarding C12.22 traffic. Source and destination addresses of each C12.22
5007message are provided respectively by the Calling ApTitle and Called ApTitle as
5008defined in the ACSE application data unit <acse-pdu>. For each message
5009received, the relay extracts the Called ApTitle and compares it to ApTitles
5010contained in its routing tables. If a match is found, the relay forwards this
5011message to the next relay or the final node associated with the Called
5012ApTitle.
5013
5014Routing tables update dynamically upon a successful Registration Service
5015service, <register>. This service is initiated by the nodes at installation
5016time and is to be repeated periodically within a time interval that is shorter
5017than that published during the registration process, <reg-time-out>. Routing
5018tables can also contain static routes that are configured manually. Relays are
5019organized in a hierarchical structure where a master relay contains routing
5020information to all accessible devices in the hierarchy and a list of
5021notification hosts. Other relays maintain only routing information of devices
5022under them.
5023
5024Is it important to note that relays are also nodes on the C12.22 network, as
5025such they must be registered.
5026
5027Master Relays
5028
213 - CVII -
214
5029A C12.22 master relay contains in its routing table all C12.22 nodes
5030registered for a specific C12.22 service provider. Master relays have some
5031specific responsibilities compared to normal C12.22 relays:
5032• Master relays are responsible for sending registration notification to
5033 notification and authentication hosts that are listed in their host tables
5034 (see Registration notification).
5035• Master relays are the target of all registration service.
5036• Master relays shall not use default route entries in their routing tables.
5037
5038Registration Notification
5039
5040Master relays shall maintain a list of C12.22 host ApTitles that need to
5041receive registration notifications. C12.22 master relays shall forward a copy
5042of each registration services received to the C12.22 hosts listed in its hosts
5043notification tables. A notification is a <register> service with the Calling
5044ApTitle set to the ApTitle of the master relay,the Called ApTitle set to the
5045ApTitle of the host and the ACSE Application Data Unit <acse-pdu> containing
5046the list of the nodes associated with this notification.
5047
5048Registration Algorithm Details
5049
5050The following steps summarize the algorithm used for routing a registration
5051service.
5052
50531. Node with UID Px.Ny attaches to a C12.22 LAN.
50542. Node Px.Ny sends a registration request <register> to one or more relays on
5055 the LAN.
50563. All relays receiving the <register> request forward it to higher relay(s)
5057 in the hierarchy until a master relay is reached or return an error
5058 response as appropriate.
50594. The master relay deletes any duplicate registration service requests it
5060 received.
50615. The master relay forwards a copy of the registration request to each host
5062 that needs to be notified, in accordance with its hosts’ registration
5063 notification table. A master relay can also act as an authentication host,
5064 so its ApTitle may appear in the hosts’ authentication and registration
5065 notification table.
50666. The master relay monitors the responses from all of the hosts that were
5067 notified for a minimum of one <register_r> with an <ok> response code from
5068 an authentication host.
50697. If one or more authentication host respond with an <ok>, the master relay
5070 sends an <ok> registration response to the registering node by one of the
5071 possible (preferably the shortest) routes. Otherwise it replies with a
5072 <nok> and does not add the registering node to the relay’s routing tables.
50738. If a notification host, that is known to the master relay does not respond
5074 the master relay shall cache the notification request for the non-
5075 responding host and it shall retry to notify that host periodically until
5076 the notification host acknowledges (with an <ok> or a <nok>) the
5077 registration notification request or until the registered node gets de-
5078 registered, whichever occurs first.
5079
5080Node Auto-ApTitle Assignment
5081
5082A node that wants to get an ApTitle assigned to it dynamically shall initiate
5083a registration request with the calling ApTitle absent. This registration
5084requests includes all the required parameters except that the registering
215 - CVIII -
216
5085ApTitle length is set to zero, also the Native address and device Serial
5086number normally optional shall be provided for validation.
5087
5088The Relay that receives this message has two options:
5089
5090• In the first scheme the relay directly assigns one of its sub-branches to
5091 this device. The relay modify the register request to add the assigned
5092 ApTitle as calling ApTitle and registered ApTitle and forward the resulting
5093 message to the master relay. The master relay processes this message like
5094 any other resister request it receives.
5095• The second option consists of forwarding this request based on the rules
5096 described in the proxy server section. The master relay then passes this
5097 information to all authentication hosts, the authentication host that
5098 accepts the registration is responsible for the assignment of new ApTitle
5099 that is included in the registration response. This response is then
5100 forward back to the registering node.
5101
5102In either cases the registering node retrieve its new Aptitle in the
5103registration response.
5104
5105Master relay Auto-ApTitle Assignment
5106
5107A node that wants to get an master ApTitle assigned to it dynamically shall
5108initiate a registration request with the called ApTitle absent. A relay that
5109receives this request has two options:
5110
5111• It can reject it by sending back an <sns> error message.
5112• In second case, the relay modifies the register request to add the called
5113 Aptitle. The ApTitle used can be constant programmed in this relay or based
5114 on the device Serial number and native address received.
5115
5116The auto discovery of nearest relays (presented in the Resolve service
5117section) together with the Node Auto-ApTitle Assignment and the Master relay
5118Auto-ApTitle Assignment can be used to automate the installation of a new
5119C12.22 node.
5120
5121Obsolete routes
5122
5123One way for a C12.22 node to be removed from the network is to sent a De-
5124registration service request. This service request is sent to the master relay
5125that originally received the Registration service. Relay shall remove all
5126routing information for the requested node only when an <ok> response is
5127return by the master relay.
5128
5129Relays shall also remove routing information of C12.22 node that did not
5130communicate or did not register within the <reg-time-out> period, following
5131master relay notification by the relay.
5132
5133Following the removal of a node, a master relay shall notify all hosts
5134associated with this node about this removal.
5135
5136Multiple routes
5137
5138In some network topologies messages can propagate through many paths (multiple
5139relays). A C12.22 node has the option to register to one or multiple of the
5140available paths. For each path, the node shall register with a different
217 - CIX -
218
5141ApTitle or a different sub-branch of the same ApTitle. It’s the responsibility
5142of the node to maintain the registration of each path to not become obsolete.
5143A client that wants to communicate with a device registered through multiple
5144routes can select the route used by each transmission by using the
5145corresponding ApTitle.
5146
5147
5148Application layer supervision
5149
5150It is assume that C12.22 ACSE APDUs are transferred through reliable
5151communication links. This means that each request sent out results shall
5152result in a corresponding response carrying either an expected result or an
5153error code. A C12.22 relay that provide application layer supervision shall
5154generate a <nok> response to the Calling ApTitle upon discovery of network
5155delivery failure.
5156
5157Application layer timeout
5158
5159An application layer at its option may apply a timeout, this time out is not
5160specify by this standard.
5161
5162Routing
5163
5164All routes to nodes are stored in the relay’s routing tables. Each of the
5165routing tables contains ApTitleMask / FwdAddress pairs. An ApTitleMask is
5166represented as dot delimited numeric or ‘*’ strings as shown below.
5167
ApTitleMask Description
2.16.840.1.114223.1.234 Represents the ApTitleMask for node
2.16.840.1.114223.1.234
2.16.840.1.114223.1.* Represents the mask for any node whose ApTitle
starts with 2.16.840.1.114223.1
* Represents any node.
5168
5169When searching for a forwarding address, the routing tables are parsed
5170sequentially until a match is found or the end of the table is reached. When a
5171match is found and the destination address is another relay then the ACSE APDU
5172is forwarded to that relay. If the destination is a C12.22 node (e.g. an end
5173device) then the ACSE APDU is delivered to that node directly on the local
5174area network.
5175
5176The following steps summarize the algorithm used for routing any C12.22
5177messages.
5178
51791. Arbitrary node on the network wants to send a message to node Px.Ny
51802. A C12.22 message is sent to one of the local relays with Px.Ny as Called
5181 ApTitle, with interface Ax to node Px.Ny.
51823. Local relay searches for Px.Ny in its routine table and, if found it
5183 forwards the message to it via interface Ay.
51844. If no route is available to forward or deliver this message an <nok> is
5185 returned.
5186
219 - CX -
220
5187ANNEX B - Routing Examples
5188
5189Informative
5190
5191The diagram below shows an example of relays and the routing tables associated
5192to each of them. In this diagram, each routing table contains the following
5193information:
5194
5195• the node type;
5196• the ApTitle of this node represented as “Pn.Nn” where Pn is the Service
5197 Provider code and Nn is the Subscriber code assigned to this node. For
5198 example, ApTitle 2.16.840.1.114223.55.234 represent Service Provider
5199 2.16.840.1.114223.55 Subscriber code 234;
5200• the native address of the next node where to forward messages for this
5201 ApTitle;
5202
Routing table Master Relay P1 Routing table Relay 2
Node type ApTitle Route Node type ApTitle Route
Node P1.N1 A3 Neighbor node P1.N4 B3
Node P1.N2 A3 Node P1.N5 B2
Node P1.N4 A2 Node P1.N6 B2
Node P1.N5 A2 Neighbor relay P1.N9 B2
Node P1.N6 A2 * A1
Neighbor node P1.N3 A4
Neighbor relay P1.N7 A3
Neighbor relay P1.N8 A2 Master relay P1
Relay P1.N9 A2 P1.N10 Routing table Relay 3
Node type ApTitle Route
Network A A1 Neighbor node P1.N5 D2
A2 Neighbor node P1.N6 D3
Routing table Relay 1 * B1
Node type ApTitle Route Relay 2
Neighbor node P1.N1 C2 P1.N8
Neighbor node P1.N2 C3
B1 Network B
* A1
A3 B2
Relay 1 Relay 3
P1.N7 P1.N9
Network C C1 D1 Network D
C2 C3 A4 B3 D2 D3
C12.22 C12.22 C12.22 C12.22 C12.22 C12.22
End Device 1 End Device 2 Host 1 End Device 3 End Device 4 End Device 5
P1.N1 P1.N2 P1.N3 P1.N4 P1.N5 P1.N6
5203
5204Relays shared by multiple Service Providers
5205
5206Each Provider of C12.22 services maintains its own hierarchy of relays. To
5207allow sharing of relays between Service Providers, ApTitles are broken into
5208two parts. The first part identifies the Service Provider responsible of this
5209device and the second part identifies a Subscriber Code that makes the entire
5210ApTitle unique. As shown in the following diagram, relays can take advantage
5211of the ApTitle structure to route C12.22 messages.
5212
221 - CXI -
222
Routing table Relay 2 Routing table Relay 4
Master relay P1 Neighbor node P2.N2 C2
Master relay P2
Neighbor node P1.N1 B2 Neighbor node P1.N3 C3
P1.N5 P2.N6
Neighbor node P2.N1 B3 Neighbor node P2.N3 C4
Neighbor node P1.N2 B4 Network A A1 A2 P1.* A1
P1.* A1 A3 A4 P2.* A2
P2.* A2
* A2 Relay 2 Relay 4
P1.N4 P2.N5
Network B B1 C1 Network C
B2 B3 B4 C2 C3 C4
C12.22 C12.22 C12.22 C12.22 C12.22 C12.22
End Device 1 End Device 2 End Device 3 End Device 4 End Device 5 End Device 6
P1.N1 P2.N1 P1.N2 P2.N2 P1.N3 P2.N3
5213
223 - CXII -
224
5214
5215ANNEX C: Modifications and extensions to C12.19- 1997
5216
5217NORMATIVE
5218
5219This Annex describes:
5220C1- New Decade 12, Network Control Tables, which are not currently in
5221 C12.19-1997.
5222C2- New Decade 13, Relay Control Tables, which are not currently in
5223 C12.19-1997.
5224C3- Addition of Universal ID pattern description
5225C4- Addition of network registration and interface control procedures to
5226 Table 07, Procedure Initiate Table
5227C5- Deprecating table 45 and introduction of table 46.
5228
5229
225 - CXIII -
226
5230ANNEX C1 - DECADE 12: Network control tables
5231
5232This decade contains tables associated with the use of an ANSI C12.22 network
5233access.
5234
5235 TABLE 120 Dimension network table
5236
5237Table 120 Data Description
5238
5239DIM_NETWORK_TBL (Table 120) specifies the maximum dimensional values for this
5240decade.
5241
5242TYPE DIM_NETWORK_BFLD = BIT FIELD OF UINT8
5243 TIME_STAMP_ENABLE_FLAG : BOOL(0);
5244 PROG_NATIVE_ADDRESS : BOOL(1);
5245 PROG_BROADCAST_ADDRESS : BOOL(2);
5246 STATIC_RELAY : BOOL(3);
5247 STATIC_APTITLE : BOOL(4);
5248 STATIC_MASTER_RELAY : BOOL(5);
5249 CLIENT_RESPONSE_CTRL : BOOL(6);
5250 FILLER : FILL(7..7);
5251END;
5252
5253TYPE DIM_NETWORK_RCD = PACKED RECORD
5254 CONTROL : DIM_NETWORK_BFLD;
5255
5256 NBR_INTERFACES : UINT8;
5257 NBR_REGISTRATIONS : UINT8;
5258 NBR_FILTERING_RULES : UINT16;
5259 NBR_EXCEPTION_HOSTS : UINT16;
5260 NBR_EXCEPTION_EVENTS : UINT16;
5261 NBR_STATISTICS : UINT16;
5262 NBR_MULTICAST_ADDRESSES : UINT8;
5263
5264 NATIVE_ADDRESS_LEN : UINT8;
5265 FILTERING_EXP_LEN : UINT8;
5266END;
5267
5268TABLE DIM_NETWORK_TBL = DIM_NETWORK_RCD;
5269
5270Identifier Value Definition
5271
5272DIM_NETWORK_BFLD
5273 TIME_STAMP_ENABLE_FLAG FALSE Network statistic table (Table 125)
5274 does not contains time-related
5275 information.
5276 TRUE Network statistic table
5277 (Table 125) contains time-related
5278 information.
5279
5280 PROG_NATIVE_ADDRESS FALSE Interfaces native addresses can not
5281 be set.
5282 TRUE Interfaces native
5283 addresses can be set in the
5284 Interface control table (Table 122).
227 - CXIV -
228
5285
5286 PROG_BROADCAST_ADDRESS FALSE Interfaces broadcast addresses can
5287 not be set.
5288 TRUE Interfaces broadcast
5291
5292 STATIC_RELAY FALSE Local relays native addresses can
5293 not be set.
5294 TRUE Local relays native
5297
5298 STATIC_APTITLE FALSE This C12.22 device can not be
5299 programmed with a static ApTitle.
5300 TRUE This C12.22 device can
5301 be programmed with a static ApTitle.
5302
5303 STATIC_MASTER_RELAY FALSE The associated master relay can not
5304 be programmed with a static ApTitle.
5305 TRUE The associated master
5306 relay can be programmed with a
5307 static ApTitle.
5308
5309 CLIENT_RESPONSE_CTRL FALSE The Interface control table (Table
5310 122) is not capable to provide
5311 Client response control parameters.
5312 TRUE The Interface control
5313 table (Table 122) is capable to
5314 provide Client response control
5315 parameters.
5316
5317DIM_NETWORK_RCD
5318 NBR_INTERFACES 0..255 Maximum number of network interfaces
5319 supported by this node.
5320
5321 NBR_REGISTRATIONS 0..255 Maximum number of concurrent
5322 registrations supported by this
5323 node. Each registration provide a
5324 independent route to a C12.22
5325 network.
5326
5327 NBR_FILTERING_RULES 0..65535 Maximum number of filtering rules
5328 supported in the Interface control
5329 table (Table 122).
5330
5331 NBR_EXCEPTION_HOSTS 0..65535 Maximum number of exception hosts
5332 supported in the Exception report
5334
5335 NBR_EXCEPTION_EVENTS 0..65535 Maximum number of events supported
5336 for each entry in the Exception
5337 report table (Table 124).
5338
229 - CXV -
230
5339 NBR_STATISTICS 0..65535 Maximum number of statistics
5340 supported in the Interface control
5342
5343 NBR_MULTICAST_ADDRESSES 0..255 Maximum number multicast addresses.
5344
5345 NATIVE_ADDRESS_LEN 0..255 Maximum length of a native address
5347
5348 FILTERING_EXP_LEN 0..255 Maximum number of characters used as
5349 parameter for each filtering
5350 condition in the Interface control
5352
231 - CXVI -
232
5353
5354 TABLE 121 Actual network table
5355
5357
5358ACT_NETWORK_TBL (Table 121) specifies the actual dimensional values for this
5359decade.
5360
5361TABLE ACT_NETWORK_TBL = DIM_NETWORK_RCD;
5362
5364
5365DIM_NETWORK_BFLD
5366 TIME_STAMP_ENABLE_FLAG FALSE Network statistic table (Table 125)
5367 does not contains time-related
5368 information.
5369 TRUE Network statistic table (Table 125)
5370 contains time-related information.
5371
5372 PROG_NATIVE_ADDRESS FALSE Interfaces native addresses are not
5373 configurable.
5374 TRUE Interfaces native
5375 addresses are set in the Interface
5376 control table (Table 122).
5377
5378 PROG_BROADCAST_ADDRESS FALSE Interfaces broadcast addresses are
5380 TRUE Interfaces broadcast
5383
5384 STATIC_RELAY FALSE Local relays native addresses are
5386 TRUE Local relays native
5389
5390 STATIC_APTITLE FALSE This C12.22 device is not programmed
5391 with a static ApTitle.
5392 TRUE This C12.22 device is
5394
5395 STATIC_MASTER_RELAY FALSE The associated master relay is not
5397 TRUE The associated master
5398 relay is programmed with a static
5399 ApTitle.
5400
5401 CLIENT_RESPONSE_CTRL FALSE The Interface control table (Table
5402 122) do not provide Client response
5403 control parameters.
5404 TRUE The Interface control
5405 table (Table 122) provides Client
5406 response control parameters.
5407
5408DIM_NETWORK_RCD
233 - CXVII -
234
5409 NBR_INTERFACES 0..255 Actual number of network interfaces
5411
5412 NBR_REGISTRATIONS 0..65535 Actual number of concurrent routes
5413 supported in this node.
5414
5415 NBR_FILTERING_RULES 0..65535 Actual number of filtering rules
5416 available in the Interface control
5418
5419 NBR_EXCEPTION_HOSTS 0..65535 Actual number of exception hosts
5420 type available in the Exception
5422
5423 NBR_EXCEPTION_EVENTS 0..65535 Actual number of events supported
5424 for each entry in the Exception
5426
5427 NBR_STATISTICS 0..65535 Actual number of statistics
5428 supported by the Interface control
5430
5431 NBR_MULTICAST_ADDRESSES 0..255 Actual number multicast addresses.
5432
5433 NATIVE_ADDRESS_LEN 0..255 Actual length of a native address
5435
5436 FILTERING_EXP_LEN 0..255 Actual number of characters in a
5437 filtering expression used in the
5439
5440each identification service.
5441
235 - CXVIII -
236
5442 TABLE 122 Interface control table
5443
5445
5446INTERFACE_CTRL_TBL (Table 122) contains the configuration of each interface
5447supported by this node.
5448
5449TYPE INTERFACE_CTRL_ENTRY_RCD = PACKED RECORD
5450 IF ACT_NETWORK_TBL.PROG_NATIVE_ADDRESS THEN
5451 NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
5452 END;
5453 IF ACT_NETWORK_TBL.PROG_BROADCAST_ADDRESS THEN
5454 BROADCAST_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
5455 END;
5456 IF ACT_NETWORK_TBL.STATIC_RELAY THEN
5457 RELAY_NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
5458 END;
5459 IF ACT_NETWORK_TBL.STATIC_APTITLE THEN
5460 NODE_APTITLE : BINARY(20);
5461 END;
5462 IF ACT_NETWORK_TBL.STATIC_MASTER_RELAY THEN
5463 MASTER_RELAY_APTITLE : BINARY(20);
5464 END;
5465 IF ACT_NETWORK_TBL.CLIENT_NODE_SETUP THEN
5466 NBR_OF_RETRY : UINT8;
5467 RESPONSE_TIMEOUT : UINT16;
5468 END;
5469END;
5470
5471TYPE INTERFACE_CTRL_RCD = PACKED RECORD
5472 IF NOT ACT_NETWORK_TBL.STATIC_APTITLE THEN
5473 ELECTRONIC_SERIAL_NUMBER: BINARY(20);
5474 END;
5475 INTERFACE_ENTRIES : ARRAY[ACT_NETWORK_TBL.NBR_INTERFACES]
5476 OF INTERFACE_CTRL_ENTRY_RCD;
5477 MCAST_ADDRESSES : ARRAY[NBR_MULTICAST_ADDRESSES] OF BINARY(20);
5478END;
5479
5480TABLE INTERFACE_CTRL_TBL = INTERFACE_CTRL_RCD;
5481
5482
5484
5485INTERFACE_CTRL_ENTRY_RCD
5486 NATIVE_ADDRESS Native address assigned to this
5487 interface. This address can be pre-
5488 configured or dynamically received
5489 from the communication module. See
5490 the “Get communication module
5491 information” service for more
5492 detail.
5493
5494 BROADCAST_ADDRESS Native address used to broadcast
5495 messages on the local network
5496 segment. This address can be pre-
5497 configured or dynamically received
237 - CXIX -
238
5498 from the communication module. See
5499 the “Get communication module
5500 information” service for more
5501 detail.
5502
5503 RELAY_NATIVE_ADDRESS Native address used to access the
5504 relay on this route for the node
5505 local network segment. When not
5506 provide, this field can be pre-
5507 configured or assigned automatically
5508 by the <resolve> service
5509
5510 NODE_APTITLE Relative or absolute object
5511 identifier assigned to this node.
5512 This value can be pre-configured or
5513 dynamically assigned to this node.
5514 This field id encoded as <universal-
5515 id-element> or <relative-uid-
5516 element>.
5517
5518 MASTER_RELAY_APTITLE Relative or absolute object
5519 identifier assigned to the master
5520 responsible of this node. This value
5521 can be pre-configured or dynamically
5522 assigned to this node. This field is
5523 encoded as <universal-id-element> or
5524 <relative-uid-element>.
5525
5526 NBR_OF_RETRIES The number of retries defines the
5527 number of time a request is sent if
5528 the response is n ot received within
5529 a RESPONSE_TIMEOUT.
5530
5531 RESPONSE_TIMEOUT This parameter controls the number
5532 of seconds a C12.22 Client has to
5533 wait for a response of a request
5534 before failing or sending retries.
5535
5536INTERFACE_CTRL_RCD
5537 ELECTRONIC_SERIAL_NUMBER Universal identifier used by the
5538 node ApTitle and master relay
5539 Aptitle auto assignment algorithms.
5540 This identifier is optional and
5541 required only if the ROUTE_APTITLE
5542 and MASTER_RELAY_APTITLE are not
5543 pre-configured.
5544
5545 INTERFACE_ENTRIES Array containing the configuration
5546 information for each interfaces
5548
5549 MCAST_ADDRESSES Array of Relative object identifier.
5550 This field is encoded as a
5551 <relative-uid-element> supported by
5552 this node. The value of 0 is
5553 reserved for unused.
239 - CXX -
240
5554
241 - CXXI -
242
5555 TABLE 123 Exception report table
5556
5558
5559EXCEPTION_REPORT_TBL (Table 124) is used to configure exception messages that
5560can be sent by this node.
5561
5562TYPE EXCEPTION_REPORT_ENTRY_RCD = PACKED RECORD
5563 APTITLE_NOTIFY : BINARY(20);
5564 MAX_NUMBER_OF_RETRIES: UINT8;
5565 RETRY_DELAY : UINT16;
5566 EXCLUSION_PERIOD : UINT16;
5567 EVENT_REPORTED : ARRAY[ACT_NETWORK_TBL.NBR_EXCEPTION_EVENTS]
5568 OF TABLE_IDB_BFLD;
5569END;
5570
5571TYPE EXCEPTION_REPORT_RCD = PACKED RECORD
5572 EXCEPTION_REPORT : ARRAY[ACT_NETWORK_TBL.NBR_EXCEPTION_HOSTS]
5573 OF EXCEPTION_REPORT_ENTRY_RCD;
5574END;
5575
5576TABLE EXCEPTION_REPORT_TBL = EXCEPTION_REPORT_RCD;
5577
5579
5580TABLE_IDB_BFLD
5581 TBL_PROC_NBR 0..2047 Event code that trigger this
5582 exception report. For standard event
5583 codes, refer to Annex C “History &
5584 Event Log Codes” of ANSI C12.19-1997
5585 and Annex Annex E5 “History & Event
5586 Log Codes” of ANSI C12.21-19xx.
5587
5588 STD_VS_MFG_FLAG FALSE Event number is standard defined.
5589 TRUE Event number is manufacturer
5590 defined.
5591
5592 SELECTOR Not Used.
5593
5594EXCEPTION_REPORT_ENTRY_RCD
5595 APTITLE_NOTIFY Called ApTitle for reporting
5596 exceptions that are generated for
5597 the associated events.
5598
5599 MAX_NUMBER_OF_RETRIES Maximum numbers of times the node
5600 attempts to report an exception.
5601 This process stop after the
5602 reception by the node of an <ok>
5603 response.
5604 0 Unconfirmed exception report.
5605 RESPONSE_CONTROL defined in <epsem-
5606 control> shall be set to two “Never
5607 respond”.
5608 1..255 Confirmed exception report.
243 - CXXII -
244
5609 RESPONSE_CONTROL defined in <epsem-
5610 control> shall be set to zero
5611 “Always respond”.
5612
5613 RETRY_DELAY 0..65535 Minimum period in minutes between
5614 two consecutive retry attempt for
5615 the same event.
5616
5617 EXCLUSION_PERIOD 0..65535 Minimum period in minutes before
5618 initiating a consecutive report for
5619 the same event.
5620
5621 EVENT_REPORTED List of events reported to the
5622 associated ApTitle.
5623
5624EXCEPTION_REPORT_RCD
5625 EXCEPTION_REPORT Array containing a list of ApTitle
5626 where to send exception reports for
5627 the associated events.
245 - CXXIII -
246
5628 TABLE 124 Filtering rules table
5629
5631
5632FILTERING_RULES_TBL (Table 124) contains a collection of rules used to filter
5633traffic across interfaces. A filtering rule may define actions taken based on
5634information matched such as interface identifier, ApTitle, native address,
5635electronic serial number and data flow. The filtering rules allow use pattern
5636matching as described in ANNEX B3 -Universal ID pattern description.
5637
5638TYPE FILTERING_CONDITION_BFLD = BIT FIELD OF UINT16
5639 ACTION_RULE : UINT(0..3);
5640 LABEL : UINT(4..7);
5641 DIRECTION : UINT(8..11);
5642 CONDITION : UINT(12..15);
5643END;
5644
5645TYPE FILTERING_RULES_ENTRY_RCD = PACKED RECORD
5646 CONDITION : FILTERING_CONDITION_BFLD;
5647 PATTERN : STRING(ACT_NETWORK_TBL.FILTERING_EXP_LEN);
5648END;
5649
5650TYPE RULES_PER_INTERFACE_RCD = PACKED RECORD
5651 FILTERING_RULES : ARRAY[ACT_NETWORK_TBL.NBR_FILTERING_RULES]
5652 OF FILTERING_RULES_ENTRY_RCD;
5653END;
5654
5655TYPE FILTERING_RULES_RCD = PACKED RECORD
5656 RULES_PER_INTERFACE : ARRAY[ACT_NETWORK_TBL.NBR_INTERFACES]
5657 OF RULES_PER_INTERFACE_RCD;
5658END;
5659
5660TABLE FILTERING_RULES_TBL = FILTERING_RULES_RCD;
5661
5663
5664FILTERING_CONDITION_BFLD
5665 ACTION_RULE Defines the action taken after
5666 evaluating this rule.
5667 0 IGNORE, Rule not defined. It is
5668 ignored.
5669
5670 1 REJECT, Reject immediately if the
5671 associated condition match.
5672 2 DENY, Mark as reject if the
5673 associated condition match, can be
5674 allowed by an other rule.
5675 3 ALLOW, Accept message immediately if
5676 the associated condition match.
5677 4 GOTO, Continue processing at label,
5678 5 COND, Continue processing at label
5679 immediately if the associated
5680 condition match.
5681
5682 LABEL Label used by the option 4 and 5 of
5683 the ACTION field.
247 - CXXIV -
248
5684 0 “”, No label
5685 1..15 LABEL 1 to LABEL 15
5686
5687 DIRECTION Only messages corresponding to this
5688 selection are tested for the
5689 associated condition.
5690 0 Not applicable, don’t care
5691 1 Any <apdu> received by this
5692 interface
5693 2 Any <apdu> transmitted from this
5694 interface
5695 3 <apdu> transmitted from this
5696 interface directly to a destination
5697 on the same network segment (Not
5698 through a relay).
5699 4 <apdu> transmitted from this
5700 interface to a destination using a
5701 relay
5702 5..15 Reserved
5703
5704 CONDITION 0 All <apdu>, ignores patthern.
5705 1 <apdu> with matching calling or
5706 called ApTitle pattern
5707 2 <apdu> with matching calling ApTitle
5708 3 Matching called ApTitle pattern
5709 4 <apdu> with matching source or
5710 destination native address pattern
5711 5 <apdu> with matching source native
5712 address pattern
5713 6 <apdu> with matching destination
5714 native address pattern
5715 7 <registration> request with matching
5716 <serial-number> pattern
5717 8..15 Reserved
5718
5719FILTERING_RULES_ENTRY_RCD
5720 CONDITION See FILTERING_CONDITION_BFLD above.
5721
5722 PATTERN Matching pattern that is applied
5723 subject to the CONDITION field.
5724
5725RULES_PER_INTERFACE_RCD
5726 FILTERING_RULES See FILTERING_RULES_ENTRY_RCD above.
5727
5728FILTERING_RULES_RCD
5729 RULES_PER_INTERFACE See RULES_PER_INTERFACE_RCD above.
5730
249 - CXXV -
250
5731 TABLE 125 Interface status table
5732
5734
5735INTERFACE_STATUS_TBL (Table 125) contains status and information about each
5736interface supported by the node.
5737
5738TYPE INTERFACE_STATE_BFLD = BIT FIELD OF UINT8
5739 INTERFACE_ENABLE_FLAG : BOOL(0);
5740 AUTO_REGISTRATION_FLAG : BOOL(1);
5741 LISTEN_ENABLE_FLAG : BOOL(1);
5742 DIRECT_MESSAGING_FLAG : BOOL(2);
5744END;
5745
5746TYPE NODE_TYPE_BFLD = BIT FIELD OF UINT8
5747 RELAY_FLAG : BOOL(0);
5748 MASTER_RELAY_FLAG : BOOL(1);
5749 HOST_FLAG : BOOL(2);
5750 NOTIFICATION_HOST_FLAG : BOOL(3);
5751 AUTHENTICATION_HOST_FLAG : BOOL(4);
5752 END_DEVICE_FLAG : BOOL(5);
5753 RESERVED : FILL(6..7);
5754END;
5755
5756TYPE INTERFACE_STATUS_ENTRY_RCD = PACKED RECORD
5757 INTERFACE_NAME : STRING(20);
5758 INTERFACE_STATE : INTERFACE_STATE_BFLD;
5759 NODE_TYPE : NODE_TYPE_BFLD;
5760 IF ACT_NETWORK_TBL.TIME_STAMP_ENABLE_FLAG THEN
5761 INTERFACE_ON_TIME : LTIME_DATE;
5762 INTERFACE_OFF_TIME : LTIME_DATE;
5763 LAST_STAT_RESET_TIME : LTIME_DATE;
5764 LAST_ACCESS_TIME : LTIME_DATE;
5765 END;
5766END;
5767
5768TYPE INTERFACE_STATUS_RCD = PACKED RECORD
5769 INTERFACE_STATUS : ARRAY[ACT_NETWORK_TBL.NBR_INTERFACES]
5770 OF INTERFACE_STATUS_ENTRY_RCD;
5771END;
5772
5773TABLE INTERFACE_STATUS_TBL = INTERFACE_STATUS_RCD;
5774
5776
5777INTERFACE_STATE_BFLD
5778 INTERFACE_ENABLE_FLAG FALSE This interface is deactivated and
5779 does not accept and send messages.
5780 TRUE This interface is functional and
5781 accept and send messages.
5782
5783 AUTO_REGISTRATION_FLAG FALSE The C12.22 Communication Module
5784 attached to this interface do not
5785 register this C12.22 Node on the
5786 C12.22 Network.
251 - CXXVI -
252
5787 TRUE The C12.22 Communication Module
5788 attached to this interface register
5789 this C12.22 Node on the C12.22
5790 Network.
5791
5792 LISTEN_ENABLE_FLAG FALSE The node do not accept remotely
5793 enable services.
5794 TRUE The node accept remotely enable
5795 services.
5796
5797 DIRECT_MESSAGING_FLAG FALSE All messages sent through this
5798 interface is sent to a relays.
5799 TRUE For all messages sent through this
5800 interface, the node always try to
5801 resolve the native addresses. If the
5802 native address is available, all
5803 subsequence exchanges are done
5804 directly with the target node.
5805
5806NODE_TYPE_BFLD Identification of the type of the
5807 C12.22 Node exposed through this
5808 interface.
5809
5810 RELAY_FLAG An indication whether this C12.22
5811 Node is a C12.22 Relay.
5812
5813 FALSE The C12.22 Node is not a C12.22
5814 Relay. When the C12.22 Node is also
5815 a C12.22 Master Relay, it will not
5816 act as a C12.22 Relay. i.e. It will
5817 take on C12.22 Master Relay
5818 Responsibilities only and not act as
5819 a simple C12.22 Relay.
5820 TRUE The C12.22 Node is a C12.22 Relay.
5821 When the C12.22 Node is also a
5822 C12.22 Master Relay, it will also
5824 take on C12.22 Relay routing
5825 responsibilities of a simple C12.22
5826 Relay.
5827
5828
5829 MASTER_RELAY_FLAG An indication whether this C12.22
5830 Node is a C12.22 Master Relay.
5831
5833 Master Relay.
5834
5835 TRUE The C12.22 Node is a C12.22 Master
5836 Relay.
5837
5838 HOST_FLAG An indication whether this C12.22
5839 Node is a C12.22 Host. A Host is an
5840 un-embedded application process that
5841 runs on a computer. A non host is a
5842 C12.22 embedded application.
253 - CXXVII -
254
5843
5845 Host.
5846
5847 TRUE The C12.22 Node is a C12.22 Host.
5848
5849 NOTIFICATION_HOST_FLAG An indication whether this C12.22
5850 Node is a C12.22 Notification Host.
5851
5853 Notification Host.
5854
5855 TRUE The C12.22 Node is a C12.22
5857
5858 AUTHENTICATION_HOST_FLAG FLAG An indication whether this C12.22
5859 Node is a C12.22 Authentication
5860 Host.
5861
5864
5867
5868 END_DEVICE_FLAG An indication whether this C12.22
5869 Node is a C19.22 End Device, i.e. it
5870 has metrological sensors and C12.19
5871 Tables.
5872
5873 FALSE The C12.22 Node is not a C12.19 End
5874 Device.
5875
5876 TRUE The C12.22 Node is a C12.19 End
5877 Device.
5878
5879INTERFACE_STATUS_ENTRY_RCD
5880 INTERFACE_NAME This field contains a textual
5881 description of technology used by
5882 this interface. This description can
5883 be pre-configured or dynamically
5884 received from the communication
5885 module. See the “Get communication
5886 module information” service for more
5887 detail.
5888
5889 INTERFACE_STATE See INTERFACE_STATE_BFLD defined
5890 above.
5891
5892 NODE_TYPE See NODE_TYPE_BFLD defined above.
5893
5894 INTERFACE_ON_TIME Last time the interface has been
5895 enabled.
5896
5897 INTERFACE_OFF_TIME Last time the interface has been
5898 disabled.
255 - CXXVIII -
256
5899
5900 LAST_STAT_RESET_TIME Last time the statistic has been
5901 reset.
5902
5903 LAST_ACCESS_TIME Last time the interface has received
5904 or transmitted messages.
5905
5906INTERFACE_STATUS_RCD
5907 INTERFACE_STATUS Array containing information for
5908 each of the interface supported by
5909 this node.
5910
257 - CXXIX -
258
5911 TABLE 126 Registration table
5912
5914
5915REGISTRATION_TBL (Table 123) contains the information and configuration
5916required to register and maintain registrations for one or multiple routes.
5917
5918TYPE REGISTRATION_ENTRY_RCD = PACKED RECORD
5919 INTERFACE_ID : UINT8;
5920 RELAY_NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
5921 MASTER_RELAY_APTITLE : BINARY(20);
5923 REGISTRATION_DELAY : UINT16;
5924 REGISTRATION_PERIOD : UINT16;
5925 REGISTRATION_COUNT_DOWN : UINT16;
5926END;
5927
5928TYPE REGISTRATION_STATUS_RCD = PACKED RECORD
5929 REGISTRATION : ARRAY[ACT_NETWORK_TBL.NBR_REGISTRATIONS]
5930 OF REGISTRATION_ENTRY_RCD;
5931END;
5932
5933TABLE REGISTRATION_STATUS_TBL = REGISTRATION_STATUS_RCD;
5934
5936
5937REGISTRATION_ENTRY_RCD
5938 RELAY_NATIVE_ADDRESS Native address used to access the
5939 relay on this route for the node
5940 local network segment. This field
5941 can be pre-configured or assigned
5942 automatically by the <resolve>
5943 service.
5944
5945 INTERFACE_ID 0..255 The physical interface number used
5946 to register this route. This ID is
5947 an index in the INTERFACE_ENTRIES
5948 array of the Interface control table
5949 (Table 122).
5950
5951 MASTER_RELAY_APTITLE Relative or absolute object
5952 identifier assigned to the master
5953 responsible of this node.
5954
5955 NODE_APTITLE Relative or absolute object
5956 identifier assigned to this node.
5957
5958
5959 REGISTRATION_DELAY 0..65535 Random delays in seconds between
5960 each power up and automatically
5961 generating a registration service.
5962 This function is disable when this
5963 field is set to zero.
5964
5965
259 - CXXX -
260
5966 REGISTRATION_PERIOD 0..65535 Maximum registration lifetime in
5967 minutes. The node needs to re-
5968 register itself before this period
5969 lapse.
5970
5971 REGISTRATION_COUNT_DOWN 0..65535 The amount of time in minutes left
5972 before the registration period
5973 expired.
5974
5975REGISTRATION_RCD
5976 REGISTRATION Array that contain the registration
5977 information for this node. This
5978 array contain more that one entry
5979 only if this node support multiple-
5980 route, see multiple route in the
5981 relay section for more information.
261 - CXXXI -
262
5982 TABLE 127 Network statistics table
5983
5985
5986NETWORK_STATISTICS_TBL (Table 127) statistics each interface supported by the
5987node.
5988
5989TYPE NETWORK_STATISTICS_ENTRY_RCD = PACKED RECORD
5991 STATISTIC_ID : TABLE_IDB_BFLD;
5992 VALUE : INT48;
5993END;
5994
5995TYPE NETWORK_STATISTICS_RCD = PACKED RECORD
5996 STATISTICS : ARRAY[ACT_NETWORK_TBL.NBR_STATISTICS]
5997 OF NETWORK_STATISTICS_ENTRY_RCD;
5998END;
5999
6000TABLE NETWORK_STATISTICS_TBL = NETWORK_STATISTICS_RCD;
6001
6003
6004TABLE_IDB_BFLD
6005 TBL_PROC_NBR Identify the statistic reported.
6006 When the associated STD_VS_MFG_FLAG
6007 is set to FALSE, this field is
6008 defined as follows:
6009 0 No statistic reported
6010 1 Number of octets sent
6011 2 Number of octets received
6012 3 Number of <apdu> sent
6013 4 Number of <apdu> received
6014 5 Number of <apdu> forwarded
6015 6 Number of <apdu> dropped
6016 7 Number of transmission errors
6017 8 Number of reception errors
6018 9 Number of collisions
6019 10 Number of messages overruns
6020 11 Number of framing errors
6021 12 Number of checksum errors
6022 13 Number of active connections
6023 14 Number of connection timeouts
6024 15 Number of signal carriers lost
6025 16 Signal strength (0-100%)
6026 17 Signal strength (DB)
6027 18 Number of registrations sent
6028 19 Number of registrations received
6029 20 Number of registrations denials
6030 (received but rejected)
6031 21 Number of registrations failed
6032 (issued but rejected or lost)
6033 22 Number of de-registration requested
6034 23..2047 Reserved
6035
6036 STD_VS_MFG_FLAG FALSE The statistic is standard defined.
263 - CXXXII -
264
6037 TRUE The statistic is manufacturer
6038 defined.
6039
6040 SELECTOR Not Used.
6041
6042NETWORK_STATICTICS_ENTRY_RCD
6043 INTERFACE_ID 0..255 The physical interface number used
6044 to register this route. This ID is
6045 an index in the INTERFACE_ENTRIES
6046 array of the Interface control table
6047 (Table 122).
6048
6049 STATISTIC_ID See TABLE_IDB_BFLD defined above.
6050
6051 VALUE Statistic reported.
6052
6053NETWORK_STATICTICS_RCD
6054 STATISTICS Array containing a series of
6055 statistic. Each entry contains an
6056 identifier and an associated value.
6057
6058
265 - CXXXIII -
266
6059ANNEX C2 - DECADE 130: Relay control tables
6060
6061This decade contains tables associated with the management of a C12.22 Relay.
6062
6063 TABLE 130 Dimension relay table
6064
6066
6067DIM_RELAY_TBL (Table 130) specifies the maximum dimensional values for this
6068decade.
6069
6070TYPE RELAY_CONFIGURATION_BFLD = BIT FIELD OF UINT8
6071 ASSIGN_APTILE_LOCALLY : BOOL(0);
6073END;
6074
6075TYPE DIM_RELAY_RCD = PACKED RECORD
6076 RELAY_CONFIGURATION : RELAY_CONFIGURATION_BFLD;
6077 NBR_REGISTRATION_ENTRIES : UINT32;
6078 NBR_STATIC_ROUTING_ENTRIES : UINT16;
6079 NBR_ASSIGNED_MASTER_RELAY : UINT16;
6080 NBR_HOSTS : UINT16;
6081 NATIVE_ADDRESS_LEN : UINT8;
6082END;
6083
6084TABLE 130 DIM_RELAY_TBL = DIM_RELAY_RCD;
6085
6086
6088
6089RELAY_CONFIGURATION_BFLD
6090 ASSIGN_APTILE_LOCALLY Any C12.22 Relay may act to provide
6091 ApTitles that are derived from its
6092 registered C12.22 Node ApTitle to
6093 C12.22 Nodes in its domain which do
6094 not register themselves with a
6095 C12.22 Master Relay.
6096 FALSE This relay does not support
6097 assignment of ApTitle locally.
6098 TRUE This relay does support assignment
6099 of ApTitle locally.
6100DIM_RELAY_RCD
6101 NBR_REGISTRATION_ENTRIES 0..4294967295
6102 Maximum number of nodes that can
6103 register to this relay.
6104
6105 NBR_STATIC_ROUTING_ENTRIES
6106 0.. 65535 Maximum number of static routing
6107 rules supported by this relay.
6108
6109 NBR_ASSIGNED_MASTER_RELAY
6110 0..65535 Maximum number of different C12.22
6111 Master Relays that can be
6112 automatically assigned by this
6113 relay.
267 - CXXXIV -
268
6114
6115 NBR_HOSTS 0..65535 Maximum number of C12.22
6116 Authentication Hosts and C12.22
6117 Notification Hosts that can be
6118 serviced by this C12.22 Master Relay
6119 .
6120
6121 NATIVE_ADDRESS_LEN 0..255 Maximum length of native addresses
269 - CXXXV -
270
6123
6124 TABLE 131 Actual relay table
6125
6127
6128ACT_RELAY_TBL (Table 131) specifies the actual dimensional values for this
6129decade.
6130
6131TABLE 131 ACT_RELAY_TBL = DIM_RELAY_RCD;
6132
6134
6135RELAY_CONFIGURATION_BFLD
6136 ASSIGN_APTILE_LOCALLY Any C12.22 Relay may act to provide
6137 ApTitles that are derived from its
6138 registered C12.22 Node ApTitle to
6139 C12.22 Nodes in its domain which do
6140 not register themselves with a
6141 C12.22 Master Relay.
6142 FALSE This relay does not assigns ApTitle
6143 locally.
6144 TRUE This relay assigns ApTitle locally.
6145DIM_RELAY_RCD
6146 NBR_REGISTRATION_ENTRIES 0..4294967295
6147 Actual number of nodes that can
6148 register to this relay.
6149
6150 NBR_STATIC_ROUTING_ENTRIES
6151 0.. 65535 Actual number of routing rules
6152 supported by this relay.
6153
6154 NBR_ASSIGNED_MASTER_RELAY
6155 0..65535 Actual number of different master
6156 relays that can be automatically
6157 assigned by this relay.
6158
6159 NBR_HOSTS 0..65535 Actual number of authentication and
6160 notification hosts that can be
6161 notify by this master relay.
6162
6163 NATIVE_ADDRESS_LEN 0..255 Actual length of native addresses
6165
271 - CXXXVI -
272
6166
6167
6168 TABLE 132 Registration list table
6169
6171
6172REGISTRATION_LIST_TBL (Table 132) is used to access registration information
6173of a C12.22 Relay. Entries in this table are added upon successful new
6174Registration of a C12.22 Node. Entries are removed for each De-registration
6175service received for a C12.22 Node or for a C12.22 Node for which the
6176REGISTRATION_TIME_OUT timer expired. To forward a C12.22 Message, a C12.22
6177Relay shall first attempt to find an entry in this table. If no match was
6178found, the C12.22 Relay attempts to forward the C12.22 Messaged as per static
6179routing information located in the Static Routing table (Table 133).
6180
6181TYPE NODE_QUALIFIER_BFLD = BIT FIELD OF UINT8
6182 RELAY_FLAG : BOOL(0);
6183 MASTER_RELAY_FLAG : BOOL(1);
6184 HOST_FLAG : BOOL(2);
6185 NOTIFICATION_HOST_FLAG : BOOL(3);
6186 AUTHENTICATION_HOST_FLAG : BOOL(4);
6187 END_DEVICE_FLAG : BOOL(5);
6188 NEIGHBOR_FLAG : BOOL(6);
6189 APTITLE_ASSIGNED_FLAG : BOOL(7);
6190END;
6191
6192TYPE REGISTRATION_LIST_ENTRY_RCD = PACKED RECORD
6194 NODE_NATIVE_ADDRESS : STRING[(ACT_RELAY_TBL.NATIVE_ADDRESS_LEN);
6195 INTERFACE : UINT8;
6196 NODE_QUALIFIER : NODE_QUALIFIER_BFLD;
6197 NODE_CLASS : BINARY(4);
6198 ELECTRONIC_SERIAL_NUMBER : BINARY(20);
6199 ASSIGNED_MASTER_RELAY : BINARY(20);
6200 REGISTRATION_TIME_OUT : UINT16;
6201 REGISTRATION_COUNT_DOWN : UINT16;
6202 MESSAGES_SENT : UINT48;
6203 MESSAGES_RECEIVED : UINT48;
6204END;
6205
6206TYPE REGISTRATION_LIST_RCD = PACKED RECORD
6207 REGISTRATIONS : ARRAY[ACT_RELAY_TBL.NBR_REGISTRATION_ENTRIES]
6208 OF REGISTRATION_LIST_ENTRY_RCD;
6209END;
6210
6211TABLE 132 REGISTRATION_LIST_TBL = REGISTRATION_LIST_RCD;
6212
6214
6215NODE_QUALIFIER_BFLD
6216 RELAY_FLAG An indication whether this C12.22
6217 Node is a C12.22 Relay.
6218
6220 Relay. When the C12.22 Node is also
6221 a C12.22 Master Relay, it will not
273 - CXXXVII -
274
6223 take on C12.22 Master Relay
6224 Responsibilities only and not act as
6225 a simple C12.22 Relay.
6226 TRUE The C12.22 Node is a C12.22 Relay.
6227 When the C12.22 Node is also a
6228 C12.22 Master Relay, it will also
6230 take on C12.22 Relay routing
6231 responsibilities of a simple C12.22
6232 Relay.
6233
6234
6235 MASTER_RELAY_FLAG An indication whether this C12.22
6236 Node is a C12.22 Master Relay.
6237
6239 Master Relay.
6240
6241 TRUE The C12.22 Node is a C12.22 Master
6242 Relay.
6243
6244 HOST_FLAG An indication whether this C12.22
6245 Node is a C12.22 Host. A Host is an
6246 un-embedded application process that
6247 runs on a computer. A non host is a
6248 C12.22 embedded application.
6249
6251 Host.
6252
6253 TRUE The C12.22 Node is a C12.22 Host.
6254
6255 NOTIFICATION_HOST_FLAG An indication whether this C12.22
6256 Node is a C12.22 Notification Host.
6257
6260
6263
6264 AUTHENTICATION_HOST_FLAG FLAG An indication whether this C12.22
6265 Node is a C12.22 Authentication
6266 Host.
6267
6270
6273
6274 END_DEVICE_FLAG An indication whether this C12.22
6275 Node is a C19.22 End Device, i.e. it
6276 has metrological sensors and C12.19
6277 Tables.
275 - CXXXVIII -
276
6278
6279 FALSE The C12.22 Node is not a C12.19 End
6280 Device.
6281
6282 TRUE The C12.22 Node is a C12.19 End
6283 Device.
6284 NEIGHBOR_FLAG FALSE The node do not reside on the same
6285 network segment of the relay.
6286 TRUE The node resides on the same network
6287 segment of the relay.
6288
6289 APTITLE_ASSIGNED_FLAG FALSE The node use a statically assigned
6290 ApTitle.
6291 TRUE The node ApTitle have been
6292 dynamically assigned by this relay.
6293
6294REGISTRATION_LIST_ENTRY_RCD
6295 NODE_APTITLE ApTitle of a C12.22 node encoded as
6296 <universal-id-element> or <relative-
6297 uid-element>.
6298
6299 NODE_NATIVE_ADDRESS Native address used to access this
6300 node.
6301
6302 INTERFACE Interface ID used to access this
6303 node. This ID can be used as an
6304 index in the INTERFACE_ENTRIES array
6305 in the Network control table (Table
6306 122)
6307
6308 NODE_QUALIFIER See NODE_QUALIFIER_BFLD defined
6309 above.
6310
6311 NODE_CLASS Four bytes containing the
6312 MANUFARTURER field as defined in
6313 Table 0 of ANSI C12.19-1997 or the
6314 END_DEVICE_CLASS as defined by the
6315 revised ANSI C12.19.
6316
6317 ELECTRONIC_SERIAL_NUMBER Universal identifier used by the
6318 auto ApTitle assignment algorithm.
6319
6320 ASSIGNED_MASTER_RELAY ApTitle of the master relay
6321 responsible of this node encoded as
6322 <universal-id-element> or <relative-
6323 uid-element>.
6324
6325 REGISTRATION_TIME_OUT 0..65535 Time out value in minute received in
6326 the last registration request.
6327
6328 REGISTRATION_COUNT_DOWN 0..65535 Count down in minute before removing
6329 this entry. This value is reset to
6330 the COUNT_DOWN at each new C12.22
6331 Message forwarded from this C12.22
6332 Node.
6333
277 - CXXXIX -
278
6334 MESSAGES_SENT Number of messages forwarded to this
6335 node since its installation (initial
6336 registration).
6337
6338 MESSAGES_RECEIVED Number of messages forwarded from
6339 this node since its installation
6340 (initial registration).
6341
6342REGISTRATION_LIST_RCD
6343 REGISTRATIONS Array containing information each
6344 C12.22 Node registered to this
6345 C12.22 Relay.
279 - CXL -
280
6346
6347 TABLE 133 Static Routing table
6348
6350
6351STATIC_ROUTING_TBL (Table 133) is used by C12.22 Relays which support static
6352routing to multiple C12.22 Master Relays. When a C12.22 Message is received by
6353a C12.22 Relay, it first tries to locate the destination C12.22 Node (using
6354the message’s called ApTitle field) in its Registration list table (Table
6355132). If this ApTitle is not found and a single C12.22 Master Relay is
6356supported, it forward this message to one of the routes defined in the
6357Registration table (Table 132). If multiple C12.22 Master Relay forwarding is
6358supported, the routing table (Table 133) is used to identify which route to
6359use to forward this message.
6360
6361TYPE ROUTING_TABLE_ENTRY_RCD = PACKED RECORD
6362 APTITLE_PATTERN : STRING(30);
6363 NATIVE_ADDRESS : STRING(ACT_RELAY_TBL.NATIVE_ADDRESS_LEN);
6365END;
6366
6367TYPE ROUTING_TABLE_RCD = PACKED RECORD
6368 ROUTING_TABLE : ARRAY[ACT_RELAY_TBL.NBR_STATIC_ROUTING_ENTRIES]
6369 OF ROUTING_TABLE_ENTRY_RCD;
6370END;
6371
6372TABLE 133 STATIC_ROUTING_TBL = ROUTING_TABLE_RCD;
6373
6375
6376ROUTING_TABLE_ENTRY_RCD
6377 APTITLE_PATTERN Each entry contains ApTitle patterns
6378 that are associated with forwarding
6379 interfaces. An ApTitle pattern is
6380 represented as dot delimited numeric
6381 or ‘*’ strings as shown below (for
6382 more details see ANNEX C3 on
6383 “Universal ID pattern description”).
6384
ApTitleMask Description
2.16.840.1.234 Represents the
ApTitle pattern for
node 2.16.840.1.234.
2.16.840.1.* Represents the
pattern for any
C12.22 Node whose
ApTitle begins with
2.16.840.1 and is
followed by any sub
branch derived from
of this ApTitle.
* Represents any
C12.22 Node (matches
anything).
6385
6386 When searching for a forwarding
6387 C12.22 Node’s address, the routing
281 - CXLI -
282
6388 tables are parsed sequentially from
6389 low array indices toward higher
6390 indices until a match is found or
6391 until the end of a table is reached.
6392 When a match is found and the C12.22
6393 Node’s destination address is
6394 reachable through another enabled
6395 interface (of this relay) to another
6396 remote C12.22 Relay then the C12.22
6397 Message may be forwarded to that
6398 relay. If the destination is a
6399 C12.22 Node (e.g. a C12.19 End
6400 Device) then the C12.22 Message may
6401 be delivered to that node directly
6402 on the local network segment, thus
6403 completing the delivery of the
6404 message.
6405
6406 INTERFACE_ID Interface number used to forward
6407 C12.22 Messages to C12.22 Nodes
6408 having an ApTitle which matches the
6409 associated pattern
6410 (APTITLE_PATTERN).
6411
6412 NATIVE_ADDRESS Native address of the C12.22
6413 forwarding Node on a C12.22 Network
6414 Segment that is attached to this
6415 C12.22 Relay.
6416
6417
6418ROUTING_TABLE_RCD
6419 ROUTING_TABLE An array containing a collection of
6420 static ApTitle pattern and
6421 corresponding destination used to
6422 forward messages. All entries are
6423 evaluated sequentially, from index 0
6424 to index NBR_STATIC_ROUTING_ENTRY-1,
6425 the search stop at the first pattern
6426 that matches, thus resulting in the
6427 C12.22 Message being forwarded to
6428 the corresponding destination.
283 - CXLII -
284
6429
6430 TABLE 134 Host notification table
6431
6433
6434HOST_NOTIFICATION_TBL (Table 134) contains the list of authentication and
6435notification hosts.
6436
6437TYPE HOST_NOTIFICATION_ENTRY_BFLD = BIT FIELD OF UINT16
6438 HOST_TYPE : UINT(0..1) ;
6439 PENDING_NOTIFICATION : UINT(2..15) ;
6440END;
6441
6442TYPE HOST_NOTIFICATION_ENTRY_RCD = PACKED RECORD
6443 HOST_APTITLE : ARRAY[20] OF UINT8;
6444 HOST_TYPE : INTERFACE_STATUS_TBL.NODE_TYPE_BFLD;
6445 NBR_PENDING_NOTIFICATION : UINT16 ;
6446END;
6447
6448TYPE HOST_NOTIFICATION_RCD = PACKED RECORD
6449 NOTIFICATION_RETRY_INTERVAL: UINT16;
6450 NOTIFICATION_TIME_OUT : UINT16;
6451 NOTIFICATION_HOSTS : ARRAY[ACT_RELAY_TBL.NBR_HOSTS]
6452 OF HOST_NOTIFICATION_ENTRY_RCD;
6453END;
6454
6455TABLE 134 HOST_NOTIFICATION_TBL = HOST_NOTIFICATION_RCD;
6456
6458
6459HOST_NOTIFICATION_ENTRY_RCD
6460 HOST_APTITLE ApTitle of an authentication or
6461 notification hosts.
6462
6463 HOST_TYPE Defines if this host is used to
6464 authenticate registration and de-
6465 registration or need only to be
6466 notified for each registration
6467 received (when
6468 AUTHENTICATION_HOST_FLAG or
6469 NOTIFICATION_HOST_FLAG flags are set
6470 to TRUE). See
6471 INTERFACE_STATUS_TBL.NODE_TYPE_BFLD
6472 for more details).
6473
6474 NBR_PENDING_NOTIFICATION 0..65535 Number of notification pending
6475 because this host is not available.
6476
6477HOST_NOTIFICATION_RCD
6478 NOTIFICATION_RETRY_INTERVAL Minimum period between notification
6479 retry attempts. Zero means that the
6480 C12.22 Relay will not attempt to re-
6481 send notifications to a non
6482 responsive host. Non zero value will
6483 cause the C12.22 Relay to wait for
6484 the stated value in minutes before
285 - CXLIII -
286
6485 retrying to notify a non responsive
6486 host. This applies only to C12.22
6487 Notification or Authentication
6488 Hosts.
6489 NOTIFICATION_RETRY Minimum period between each retries
6490 to notify a host. Zero means that
6491 the relay will not retry to send
6492 notifications and wait for the
6493 corresponding hosts to connect
6494 before sending the pending
6495 notifications.
6496
6497 NOTIFICATION_TIME_OUT Number of minutes after which a
6498 pending notification can be deleted
6499 and not sent to the corresponding
6500 host. Zero means never delete.
6501
6502 NOTIFICATION_EXCLUSION Minimum period before reporting two
6503 consecutive notification of the same
6504 C12.22 Host.
6505
6506 NOTIFICATION_HOSTS Array containing a list of C12.22
6507 Authentication and Notification
6508 Hosts.
287 - CXLIV -
288
6509
6510 TABLE 135 Master relay assignment table
6511
6513
6514MASTER_RELAY_ASSIGMENT_TBL (Table 135) is used to define the ApTitle of the
6515C12.22 Master Relays that shall be assigned to C12.22 Nodes based on their
6516registration-time provided serial number pattern. See the “Master relay auto
6517assignment” section for more detail.
6518
6519TYPE ASSIGNEMENT_ENTRY_RCD = PACKED RECORD
6520 SERIAL_NUMBER_PATTERN : STRING(30);
6521 MASTER_RELAY_ASSIGNED : STRING(30);
6522END;
6523
6524TYPE MASTER_RELAY_ASSIGNEMENT_RCD = PACKED RECORD
6525 MASTER_RELAYS : ARRAY[ACT_RELAY_TBL.NBR_ASSIGNED_MASTER_RELAY]
6526 OF ASSIGNEMENT_ENTRY_RCD;
6527END;
6528
6529TABLE 135 MASTER_RELAY_ASSIGMENT_TBL = MASTER_RELAY_ASSIGNEMENT_RCD;
6530
6532
6533ASSIGNEMENT_ENTRY_RCD
6534 SERIAL_NUMBER_PATTERN The serial number received is
6535 compared to each of these patterns.
6536 The search stops at the first match
6537 and the corresponding master relay
6538 ApTitle assigned. This pattern is
6539 constructed following the rules
6540 defined in the “Universal ID pattern
6541 description” section.
6542
6543 MASTER_RELAY_ASSIGNED ApTitle of the C12.22 Master Relay
6544 assigned.
6545
6546MASTER_RELAY_ASSIGNEMENT_RCD
6547 MASTER_RELAYS List of serial number pattern and
6548 corresponding C12.22 Master Relay
6549 ApTitle to assign. All entries are
6550 evaluated sequentially, from index 0
6551 to index NBR_ASSIGNED_MASTER_RELAY-
6552 1, the search stop at the first
6553 pattern that match and the
6554 corresponding master relay ApTitle
6555 is assigned.
6556
289 - CXLV -
290
6557TABLE 136 Dynamic Routing report table
6558
6560
6561DYNAMIC_ROUTING_REPORT_TBL (Table 136) is used by C12.22 Relays to report
6562their dynamic routing patterns that are dynamically derived from actual
6563traffic patterns and registration. Is intended use of for diagnostic reports.
6564
6565TABLE 136 DYNAMIC_ROUTING_REPORT_TBL = STATIC_ROUTING_TBL.ROUTING_TABLE_RCD;
291 - CXLVI -
292
6566
6567ANNEX C3 - TABLE 07 - Universal ID pattern description
6568
6569Patterns are used in this decade to select ApTitles and Serial numbers. This
6570section describes how these patterns are construct and evaluated.
6571
6572 n Universal ID segment value expressed
6573 as a decimal number (e.g. “123”).
6574
6575 . The (dot) is the Universal ID
6576 segment delimiter. Example:
6577 “2.20.30” is an Universal ID with
6578 three segments 2, 20, and 30.
6579
6580 * Match zero or more branches of the
6581 Universal ID. Example: “2.20.*”
6582 match “2.20.2” and “2.20.3.45”.
6583
6584 [ ] Delimits and groups a range of
6585 Universal ID patters, using the “-“
6586 (minus) as a range indicator and the
6587 “,” (comma) as a range alternatives
6588 separator. Example: “2.20.[1-10,40-
6589 50,100].*” will match the universal
6590 ID “2.20.1.*” through “2.20.10.*”,
6591 “2.20.40.*” through “2.40.50.*” and
6592 “2.20.100.*”.
6593
6594 ! Reverse the sense result of this
6595 mask (interpreted as “not”)
6596 immediately on the group or
6597 Universal ID element on its right.
6598 The reversal operator applies only
6599 to the next segment. This option can
6600 be used with the range delimiter
6601 introduced above. Example: “2.20.!
6602 30.100” will reverse the sense of
6603 the “30” and match any universal ID
6604 which starts with “2.20” and ends
6605 with 100 and does not have 30 in its
6606 third segment. Similarly “2.20.!
6607 (30.100)” will reverse the sense of
6608 the “30.100” and match any universal
6609 ID which starts with “2.20” and does
6610 not end with “30.100”.
6611
6612 ( ) Groups Universal ID patters.
6613 Example: “2.20.[1-10,40-50,100].*”
6614 will match the universal ID
6615 “2.20.1.*” through “2.20.10.*”,
6616 “2.20.40.*” through “2.40.50.*” and
6617 “2.20.100.*”. Within a group one can
6618 introduce the “|” (vertical bar) to
6619 introduce Universal ID group
6620 alternatives. The alternatives are
293 - CXLVII -
294
6621 processes from left to right until a
6622 match is found. Groups may be
6623 nested.
6624 ? Match this branch of the Universal
6625 ID. Example: “2.20.?” match “2.20.2”
6626 but not “2.20.3.45”.
6627
6628 pattern{n} Match exactly n repetitions of a
6629 pattern, where n is a decimal
6630 number. A pattern is any of the
6631 Universal ID constructors described
6632 above. Example: “2.20.*.10” will
6633 match anything starting with “2.20”
6634 and ending with “.10”, whereas
6635 “2.20(.?){3}.10” will match anything
6636 that starts with “2.20” followed by
6637 any three segments then ending with
6638 “.10”.
6639
6640 pattern{n,m} Match exactly n repetitions of
6641 a pattern, where n is a decimal
6642 number. A pattern is any of the
6643 Universal ID constructors described
6644 above. Example: “2.20.*.10” will
6645 match anything starting with “2.20”
6646 and ending with “.10”, whereas
6647 “2.20(.?){1,3}.10” will match
6648 anything that starts with “2.20”
6649 followed by any one to three
6650 segments then ending with “.10”.
295 - CXLVIII -
296
6651ANNEX C4 - TABLE 07 - Procedure initiate table
6652
6653This Annex describes procedures associated with the Network Control Tables
6654(Decade 10).
6655
6656 PROCEDURE 23 Register
6657
6658The Registration service is used to add and maintain (“keep-alive”) routing
6659information of C12.22 relays. To be part of C12.22 network, a node shall send
6660a registration service to one of the C12.22 relays. This procedure, typically
6661used on the local port (ANSI C12.18), is used to initiate this process.
6662
6663TYPE REGISTER_RESPONSE_RCD = PACKED RECORD
6664 RESPONSE_CODE : UINT8;
6665END;
6666
6667PROCEDURE 23 REGISTER_PROC
6668 RESPONSE = REGISTER_RESPONSE_RCD;
6669
6671
6672RESPONSE_CODE_RCD
6673 RESPONSE_CODE 0..31 PSEM response code received when
6674 executing the C12.22 register
6675 service.
6676
6677
6678 PROCEDURE 24 De-register
6679
6680The de-registration service is used to remove routing information in C12.22
6681relays. This procedure, typically used on the local port (ANSI C12.18), is
6682used to initiate this process.
6683
6684PROCEDURE 24 DEREGISTER_PROC
6685 RESPONSE = REGISTER_PROC.REGISTER_RESPONSE_RCD;
297 - CXLIX -
298
6686
6687 PROCEDURE 25 Network Interface control
6688
6689This procedure is used to invoke an operation on a specific network interface.
6690
6691TYPE INTERFACE_CONTROL_RESQUEST_BFLD = BIT FIELD OF UINT8
6692 INTERFACE_CTRL : UINT(0..1);
6693 LISTEN_CTRL : UINT (2..3);
6694 AUTO_REGISTRATION_CTRL : UINT (2..3);
6695 DIRECT_MESSAGING_CTRL : UINT (4..5);
6696 RESET_STATICTICS_FLAG : BOOL(6);
6697 ALL_INTERFACES_FLAG : BOOL(7);
6698END;
6699
6700TYPE INTERFACE_CONTROL_RESQUEST_RCD = PACKED RECORD
6702 INTERFACE_CONTROL : INTERFACE_CONTROL_RESQUEST_BFLD;
6703END;
6704
6705PROCEDURE 25 NETWORK_INTERFACE_CONTROL_PROC
6706 REQUEST = INTERFACE_CONTROL_RESQUEST_RCD;
6707
6709
6710INTERFACE_CONTROL_RESQUEST_BFLD
6711 INTERFACE_CTRL Activate or deactivate the selected
6712 network interface communication
6713 hardware.
6714 0 Maintain current state
6715 1 Enable this interface
6716 2 Disable this interface
6717 3 Reset interface
6718
6719 AUTO_REGISTRATION_CTRL Control if the C12.22 communication
6720 module register this one on the
6721 C12.22 Network.
6723 1 Disable auto-registration
6724 2 Enable auto-registration
6725 3 Force one-time registration now then
6726 returns previous state.
6727
6728 LISTEN_CTRL Enable or disable interface server
6729 services.
6731 1 Start monitoring for remotely
6732 initiated services on this interface
6733 2 Stop monitoring for remotely
6734 initiated services on this interface
6735 3 Reserved
6736
6737 DIRECT_MESSAGING_CTRL Enable or disable direct addressing
6738 of nodes on same network segment.
299 - CL -
300
6740 1 Enable direct communication with
6741 target nodes on the same network
6742 segment.
6743 2 Disable direct communication with
6744 target nodes on the same network
6745 segment.
6746 3 Reserved
6747
6748 RESET_STATICTICS_FLAG FALSE Do not reset statistics available
6749 from the Interface Status table
6750 (Table 125)
6751 TRUE Reset statistics available from the
6752 Interface Status table (Table 125)
6753
6754 ALL_INTERFACES_FLAG FALSE Only the interface specified by the
6755 INTERFACE_ID field is affected.
6756 TRUE All interfaces supported by the node
6757 is affected.
6758
6759INTERFACE_CONTROL_RESQUEST_RCD
6760 INTERFACE_ID 0..255 Interface number assigned to each
6761 network interface available for this
6762 node.
6763
6764 INTERFACE_CONTROL See INTERFACE_CONTROL_RESQUEST_BFLD
6765 defined above.
6766
6767
6768 PROCEDURE 26 Exception report
6769
6770This procedure is used by an ANSI C12.22 node to report an exception.
6771
6772TYPE EXCEPTION_REPORT_REQUEST_RCD = PACKED RECORD
6773 EXCEPTION : EXCEPTION_REPORT_TBL.TABLE_IDB_BFLD;
6774END;
6775
6776PROCEDURE 26 EXCEPTION_REPORT_PROC
6777 REQUEST = EXCEPTION_REPORT_REQUEST_RCD;
6778
6780
6781EXCEPTION_REPORT_REQUEST_RCD
6782 EXCEPTION Exception code reported, see
6783 EXCEPTION_REPORT_TBL.TABLE_IDB_BFLD.
6784
301 - CLI -
302
6785
6786ANNEX C5 - Key table (Table 46)
6787
6789
6790KEY_TBL (Table 46) is intended to replace table 45 to store authentication and
6791encryption keys.
6792
6793Note: Although it may be possible to read the EXTENDED_KEY_TBL (Table 46), the
6794values reported (read back) are not defined.
6795
6796TYPE EXTENDED_KEY_ENTRY_RCD = PACKED RECORD
6797 KEY_ID : UINT8;
6798 CIPHER_CODE : UINT8;
6799 KEY_LENGTH : UINT8;
6800 KEY : ARRAY [ ACT_SECURITY_LIMITING_TBL.KEY_LEN] OF UINT8;
6801END;
6802
6803TYPE KEY_RCD = PACKED RECORD
6804 KEY_ENTRIES : ARRAY[ACT_SECURITY_LIMITING_TBL.NBR_KEYS]
6805 OF EXTENDED_KEY_ENTRY_RCD;
6806END;
6807
6808TABLE 46 EXTENDED_KEY_TBL = EXTENDED_KEY_RCD;
6809
6811
6812KEY_ENTRY_RCD
6813 KEY_ID 0..255 Key selector used to match a
6814 selection for a key that is provided
6815 by the communication protocol
6816 against a KEY entry in this table.
6817
6818 CIPHER_CODE A cipher code used to encrypt or
6819 decrypt tables.
6820 0 DES
6821 1 DESede
6822 2..255 Resereved
6823
6824 KEY_LENTH 0..255 The number of octets used in this
6825 KEY entry.
6826
6827 KEY Key to be applied in the
6828 authentication and/or encryption
6829 processes.
6830
6831KEY_RCD
6832 KEY_ENTRIES Array of keys used to establish
6833 authentication and/or encryption.
6834
6835
303 - CLII -
304
6836
6837Annex D - Universal Identifier
6838
6839NORMATIVE
6840
6841ANSI C12.19/22 make use of the ISO Universal Identifier to uniquely identify
6842objects. These objects are registers under two branches. The first one used
6843for ANSI C12.19 and related standards to uniquely identify component of the
6844protocol and EDL and TDL.
6845
6846 { iso (1) member-body(2) usa (840) C12.19 standard(10066) }
6847
6848The second one for uniquely identifying communicating organizations in ANSI
6849C12 messaging. Specifically, this branch is used for Application Titles
6850(ApTitle), calling and called Aptitle when relative object identifiers are
6851used for this field.
6852
6853 { joint-iso-ccitt(2) country(16) us (840) organization(1) }
6854
6855The following table summarizes the list of objects actually defined:
6856
Use Universal identifier
ANSI C12.19 End device class 1.2.840.10066.0.<end device class id>
ANSI C12.22 Application context 1.2.840.10066
(Reserve for future context) 1.2.840.10066.1
ANSI C12.22 Mechanism name for 1.2.840.10066.2.0
compatibility with ANSI C12.21
Authentication Service algorithm
00H.
ANSI C12.22 native Mechanism name 1.2.840.10066.2.10
Name
ANSI C12.22 ApTitles 2.16.840.1.114223.<service provider
id>.<node id>
or any other registered OID.
ANSI C12.22 ApTitles 2.16.840.1.114223.[<service provider
Broadcast id>[.<node id>].]0
ANSI C12.22 ApTitles: Multicast 2.16.840.1.114223.[<service provider
id>[.<node id>].]0.xxx
6857
6858
6859ANSI C12.19 End device class
6860
6861Each organization that wants to create a new ANSI C12 end device shall
6862register to get an End device class Universal Identifier. This identifier can
6863be use for one or multiple end device type that share the same data structure
6864(EDL and TDL). This identifier is used by upstream device to understand
6865incoming data structures.
6866
6867Class will be assigned on a first come first serve basis. The first 128 End
6868device class id are reserved for registration of one way devices. Desired
6869class Ids may also be requested and assigned if available. A request for a
6870class ID requires the attached form filled out and signed by an authorised
6871agent of the organization desiring registry.
305 - CLIII -
306
6872
6873Also submitted with the form are a simple ASCII text TDL file (as defined in
6874ANSI C12.19-200x) and an optional EDL if desired. For one-way devices, EDL and
6875TDL shall include enough information to completely describe any unsolicited
6876messages that the meter might generate. For two-way devices, no specific
6877information is required to be included in the EDL and TDL. NEMA will make all
6878registered EDL/TDL publicly available through an Internet web site for
6879retrieval upon need by client applications or other users.
6880
6881ANSI C12.22 ApTitles
6882
6883Each organization that wants to deploy ANSI C12.22 nodes shall register for a
6884Universal Identifier. Under this registered branch, each organization can
6885assigns a unique Aptitle for each node installed on the network. There is no
6886limit of the number of node assigned under the same branch.
6887
6888For use in ACSE messages, this id forms the local root of the application
6889object identification for either a client or server in the C12.22
6890heterogeneous network. This object id is used by C12.22 network to propagate
6891messages from source to destination over any network architecture.
6892
6893Multicast addressing
6894
6895Multicast addressing is similar to broadcast except that it can be assumed
6896that some communications process has a distribution list (found in network
6897table 122 Interface Control Table) and only routes the message to certain
6898recipients. These recipients, knowledgeable about their membership in the
6899multicast group can respond to such a message as if directly addressed to
6900them.
6901
6902Broadcast and multicast messages shall be targeted to one C12.22 network
6903segment. A C12.22 relay may forward broadcast and multicast messages to other
6904network segments according to its internal configuration.
6905
6906A broadcast is addressed to 2.16.840.1.114223.[<service provider id>[.<node
6907id>].]0. A multicast is addressed to 2.16.840.1.114223.[<service provider
6908id>[.<node id>].]000.xxx where xxx is a specific multicast address. Xxx can be
6909any relative branch of an objectID. Note that routers and relays may want to
6910optimize the distribution of such messaging.
6911
6912Registration
6913
6914To register an ANSI C12.19 End device class or a ANSI C12.22 ApTitles, an
6915organization shall contact NEMA …
307 - CLIV -
308
6916
6917ANNEX E - One way devices
6918
6919NORMATIVE
6920
6921One way C12.22 Node fall into two categories:
6922
6923 1. Issuers of ACSE unsolicited messages to the C12.22 Network; or
6924 2. Issuers of BLURTs (short messages) to a C12.22 Communication Module or a
6925 BLURT-only capable native network.
6926
6927A C12.22 Network shall only process ACSE encapsulated messages. One way
6928devices may not send <short-pdu> on a C12.22 Network. When a C12.22 Node is
6929implemented as a C12.22 Device and a C12.22 Communication Module then the
6930C12.22 Communication module may be configured to process ACSE messages or
6931short messages. It is then the responsibility of the C12.22 Communication
6932Module to map the short messages into proper ACSE encapsulated messages before
6933presenting the messages to the C12.22 Network.
6934
6935One way C12.22 Nodes shall encode their data for transmission as a PSEM Write
6936Service request, <write>, while setting bit 2, NOTIFICATION, of the <ae-
6937qualifier-value> to 1. This is an indication to the called C12.22 Node that
6938the information provided is about the calling C12.22 Node. Also they shall set
6939the <epsem-control> bits in the RESPONSE_CONTROL to 2, requesting the target
6940not to respond.
6941
6942A C12.22 Communication Module that attaches to a one-way short-message-
6943emitting C12.22 Device shall set bit 2, NOTIFICATION, of the <ae-qualifier-
6944value> to 1 on behalf of the one-way C12.22 Device to assure the correct
6945interpretation of the information provided by the C12.22 Device.
6946
6947One-way short-message-emitting devices may only provide up to two-level
6948relative calling ApTitle (.sub-branch-1.sub-branch-2) or none (00H). It is the
6949responsibility of the first C12.22 Relay (receiving the ACSE message from the
6950C12.22 Host for transmission on the C12.22 Network) or the C12.22
6951Communication Module (connecting a C12.22 Device to a C12.22 Network) to
6952extend relative calling ApTitle for proper location of the initiator of the
6953message on the C12.22 Network.
6954
6955A typical example transmitted by a one way device using ANSI C12.22 have the
6956following ACSE datagram format:
6957
695860 36 <acse-pdu>
6959 A1 07 Application context
6960 A2 05 2A 86 48 CE 52 1.2.840.10066
6961 A2 05 <called-aptitle-element>
6962 0D 03 <relative-uid-element>
6963 17 A1 21 Called ApTitle
6964 A6 05 <calling-aptitle-element>
6965 0D 03 <relative-uid-element>
6966 17 A3 54 Calling ApTitle (.23.4564)
6967 A7 03 <calling-entity-qualifier-
6968 element>
6969 82 01 <calling-ae-qualifier>
6970 04 Notification about calling device
309 - CLV -
310
6971 A8 01 <calling-apinvocation-id-element>
6972 02 Invocation ID
6973 BE 0F <user-information-element>
6974 92 EPSEM control
6975 14 00 00 00 END_DEVICE_CLASS 20
6976 40 PSEM Full Table Write request
6977 00 03 Table ID
6978 00 04 Table count
6979 01 02 03 04 Table data
6980 F6 Negated checksum over table data
6981
6982The ACSE datagram format above may be considered to have too much overhead for
6983some technologies used by one way devices. For this reason a stripped down
6984shorter (BLURT) message format is provided as an alternative. This format has
6985been designed to be mapped to an <acse-pdu>.
6986
6987<short-pdu> ::= <short-calling-ApTitle> <short-device-class> <psem-write-
6988 request>
6989
6990<short-calling-ApTitle> ::= <byte>+ | 00H {The calling ApTitle is a two
6991 level relative universal to
6992 the locally register root
6993 Aptitle representing the
6994 ApTitle and encoded without
6995 tag and length. The value 00H
6996 is the null ApTitle, which is
6997 an indication to receiver of
6998 this message to fully resolve
6999 the called ApTitle.
7000
7001
7002<short-device-class> ::= <byte>+ {The device class is a single
7003 level universal ID
7004 representing the C12.22 Host
7005 model and encoded without tag
7006 and length. This universal ID
7007 shall be registered as a
7008 “one-way” device class
7009 derived from the root class:
7010 1.2.840.10066.0.<short-
7011 device-class>
7012
7013
7014<psem-write-request> :: <write> {As defined in by the PSEM
7015 write service request in this
7016 Standard. It is the
7017 responsibility of the C12.22
7018 Communication Module or
7019 C12.22 Node, which translates
7020 the <short-pdu> to an <acse-
7021 pdu>, to set bit 2,
7022 NOTIFICATION, of the <ae-
7023 qualifier-value> to 1 as an
7024 indication to the called
7025 C12.22 Node that the
7026 information provided by the
311 - CLVI -
312
7027 write service request is
7028 about the calling C12.22
7029 Node.}
7030
7031
7032For example, the previous example can be encoded as follow using this format:
7033
703417 A3 54 Calling ApTitle
703514 Device class
703640 PSEM Full Table Write request
703700 03 Table ID
703800 04 Table count
703901 02 03 04 Table data
7040F6 Checksum
7041
313 - CLVII -
314
7042ANNEX F - APDU Response Timeout Algorithm
7043
7044INFORMATIVE
7045
7046The “Application Response Timeout” is used by a C12.22 Node that issues EPSEM
7047requests to another C12.22 Node and needs to how long to wait for responses.
7048This annex illustrates one possible behavior that an implementer may use in a
7049client application to deal with dynamically changing network latency.
7050
7051This algorithm is applicable both to session and session-less transactions.
7052
7053In this example we set the initial value of the APDU response timeout is to 30
7054seconds and the number of retries to 3. Ideally the number of retry attempts
7055when multiplied by the default time out interval length should be set to at
7056least one fifth of the C12.22 session timeout value.
7057
7058The time out value should be reset to its initial value each time a new
7059session or session-less association is created. Upon timeout the C12.22 Node
7060may attempt one or more transmissions of the failing request, the number of
7061retries is set to an application provided value and can be programmed in the
7062INTERFACE_CTRL_TBL when implemented.
7063
7064
7065Each time an Application Layer <acse-pdu> response is received, the response
7066time out duration may be re-calculated and revised to a value that is two
7067times the average response time of previous three responses that were received
7068(use the time out value for responses that were not received in this
7069calculation).
7070
7071Each time an Application Layer APDU response is not received, within the
7072anticipated time interval, the latest timeout interval shall be increased by a
7073factor of 2, and then a duplicate Application Layer APDU shall be transmitted
7074as shown below.
7075
Steps Response interval (seconds) Response timeout (seconds)
1 30 (Example of a initial value)
2 15 25 = 2 * (30 + 30 + 15) / 3
3 18 21 = 2 * (30 + 15 + 18) / 3
4 12 15 = 2 * (15 + 18 + 12) / 3
5 30 - fail 30 = 2 * 15
5.1 20 - retry 1 21 = 2 * (12 + 30 + 20) / 3
6 6 19 = 2 * (30 + 20 + 6) / 3
7 25 17 = 2 * (20 + 6 + 25) / 3
7076
7077The retransmission process may be performed up to 3 times. If after 3 re-
7078transmission attempts the Application Layer does not receive a valid APDU
7079response and the calculated time out is less than the default time out value,
7080the time out value shall be set to the default time out and up to three more
7081transmission attempts shall be done.
7082
7083If after 3 consecutive re-transmission attempts, with a time out value that is
7084greater than the default time out value, the Application Layer does not
7085receive a valid APDU response an application timeout shall occur and the
7086Application Layer shall return <nett> to its Application Process.
7087
315 - CLVIII -
316
7088The <nett> error response shall be placed in the <epsem>’s <response> member
7089of the <acse-pdu>’s <user-data-element>. The <acse-pdu>’s <called-aptitle-
7090element> in the response shall be set to the value found in the <calling-
7091aptitle-element> of the original request; and the <acse-pdu>’s <calling-
7092aptitle-element> in the response shall be set to the <called-aptitle-element>
7093value found in the original request. All other fields, such as <calling-
7094entity-qualifier-element> shall be replicated in the <nett> response.
7095
7096If the C12.22 Node is the originator of the request, then the request shall be
7097aborted upon receipt of a <nett> error by the Application Process and
7098terminate its session (if any).
7099
7100If the C12.22 Node is not the originator of the service request (i.e. it is a
7101C12.22 Relay) then it shall not participate in this algorithm.
317 - CLIX -
318
7102
7103ANNEX G - Communication example
7104
7105INFORMATIVE
7106
7107The following example illustrates an exchange of C12.22 datagrams:
7108
7109Logon request
7110
711160 32 <aareq>
7112 A1 04 <context>
7113 2B 87 67 01 “1.3.999.1”
7114 A2 0B <called-aptitle>
7115 A2 09 <destination-id>
7116 60 86 48 02 E0 39 8D C8 DE “2.16.840.1.12345.222222”
7117 A6 08 <calling-aptitle>
7118 A2 06 <source-id>
7119 60 86 48 02 E0 39 “2.16.840.1.12345”
7120 AC 08 <authentication-value>
7121 00 00 00 00 00 00 00 00 <auth-data>
7122 BE 0F <user-data>
7123 80 <epsem-control>
7124 0E 02 <service_length> <invocation_id>
7125 50 <logon>
7126 11 11 <user_id>
7127 01 02 03 04 05 06 07 08 09 0A <user>
7128
7129Logon response
7130
713161 10 <aares>
7132 A1 04 <context>
7133 2B 87 67 01 “1.3.999.1”
7134 A2 01 00 <association-result>
7135 A3 01 00 <result-source-diagnostic>
7136 BE 03 <user-data>
7137 00 <epsem-control>
7138 02 02 <service_length> <invocation_id>
7139 00 <ok>
319 - CLX -
320
7140
7141ANNEX H - ANSI C12.22 application layer over TCP/IP (UNIX implementation)
7142
7143INFORMATIVE
7144
7145This annex is provided as an example of implementing the ANSI C12.22
7146application layer over a transport layer different that the one presented in
7147section 7. We have chosen TCP/IP for its popularity and its dominance in the
7148telecommunication industry. This protocol is suitable for transferring ANSI
7149C12.22 information between back office elements.
7150
7151This example shows the client side of an ANSI C12.22 over TCP/IP link. The
7152client represent a program that want to communicate with the end device, the
7153server side can be either an ANSI C12.22 relay or ANSI C12.22 end device.
7154Before been able to send or receive messages, the client must establish a
7155connection with the TCP CONNECT service. After the connection is established
7156the application can sent and receives C12.22 datagrams using the TCP SEND and
7157RECV services.
7158
7159Following is a C code example that shows the basic steeps necessary for a
7160client to connect and transfer ANSI C12.22 datagrams over TCP/IP.
7161
7162#include <stdio.h>
7163#include <netdb.h>
7164#include <sys/socket.h>
7165
7166void error(char *);
7167
7168int main(int argc, const char **argv)
7169{
7170 unsigned char read_table_0_request[] =
7171{
7172 0x60, 0x20, // ACSE tag and length
7173 0xA2, 0x0A, // Called Aptitle tag and length
7174 0xA2, 0x08, // Universal Identifier tag and length
7175 0x2A, 0x86, 0x48, 0xCE, 0x52, 0x03, 0x01, 0x43,
7176 0xA6, 0x0A, // Calling Aptitle tag and length
7177 0xA2, 0x08, // Universal Identifier tag and length
7178 0x2A, 0x86, 0x48, 0xCE, 0x52, 0x03, 0x01, 0x06,
7179 0xBE, 0x06, // Application Data tag and length
7180 0x80, // EPSEM control byte
7181 0x04, // EPSEM length
7182 0x02, // Invoke ID
7183 0x30, // Table Read request code
7184 0x00, 0x00 // Table 0
7185};
7186
7187 unsigned char response[255];
7188 int sockfd, response_length, i;
7189 struct sockaddr_in address;
7190 unsigned long addr;
7191
7192 if (argc != 3)
7193 error("usage: <program-name> <server-ip> <server-port>\n");
7194
7195 if ((int) (addr = inet_addr(argv[1])) == -1)
7196 error("Error in function: inet_addr()\n");
7197
7198 if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1)
7199 error("Error in function: socket()\n");
7200
7201 address.sin_family = AF_INET;
7202 address.sin_port = htons((unsigned short) atol(argv[2]));
7203 address.sin_addr.S_un.S_addr = addr;
7204 memset((void *) &address.sin_zero, 0, (size_t) 8);
321 - CLXI -
322
7205
7206 if (connect(sockfd, (struct sockaddr *) &address, sizeof(struct sockaddr)) == -1)
7207 error("Error in function: connect()\n");
7208
7209 if (send(sockfd, read_table_0_request, sizeof(read_table_0_request), 0) == -1)
7210 error("Error in function: send()\n");
7211
7212 if ((response_length = recv(sockfd, response, sizeof(response), 0)) == -1)
7213 error("Error in function: recv()\n");
7214
7215 for (i=0; i < response_length; i++)
7216 printf(" %02X", response[i]);
7217 printf("\n");
7218
7219 close(sockfd);
7220 return 0;
7221}
7222
7223void error(char *message)
7224{
7225 printf(message);
7226 exit(1);
7227}
7228
323 - CLXII -
324
7229ANNEX I - CRC examples
7230INFORMATIVE
7231
7232Trace
7233
7234This example shows the actual bit manipulations performed in calculation of
7235the frame check sequence (CRC) for an example PSEM packet in compliance with
7236ANSI C12.18 and this document.In order to be in compliance with the CRC
7237calculations, the bit ordering shall be consistent with this example.
7238
7239packet without crc = ee 00 00 00 00 01 20
7240 = 11101110 00000000 00000000 00000000 00000000 00000001 00100000 00000000 00000000
7241LSBit First 01110111 00000000 00000000 00000000 00000000 10000000 00000100 00000000 00000000
7242XOR FF 11111111 11111111
7243
7244Start Tx = 10001000 11111111 00000000 00000000 00000000 10000000 00000100 00000000 00000000
7245Apply P(x) 10001000 00010000 1
7246 00000000 11101111 10000000 00000000 00000000 10000000 00000100 00000000 00000000
7247Apply P(x) 10001000 00010000 1
7248 00000000 01100111 10010000 10000000 00000000 10000000 00000100 00000000 00000000
7249Apply P(x) 1000100 00001000 01
7250 00000000 00100011 10011000 11000000 00000000 10000000 00000100 00000000 00000000
7251Apply P(x) 100010 00000100 001
7252 00000000 00000001 10011100 11100000 00000000 10000000 00000100 00000000 00000000
7253Apply P(x) 1 00010000 00100001
7254 00000000 00000000 10001100 11000001 00000000 10000000 00000100 00000000 00000000
7255Apply P(x) 10001000 00010000 1
7256 00000000 00000000 00000100 11010001 10000000 10000000 00000100 00000000 00000000
7257Apply P(x) 100 01000000 100001
7258 00000000 00000000 00000000 10010001 00000100 10000000 00000100 00000000 00000000
7259Apply P(x) 10001000 00010000 1
7260 00000000 00000000 00000000 00011001 00010100 10000000 00000100 00000000 00000000
7261Apply P(x) 10001 00000010 0001
7262 00000000 00000000 00000000 00001000 00010110 10000000 00000100 00000000 00000000
7263Apply P(x) 1000 10000001 00001
7264 00000000 00000000 00000000 00000000 10010111 10000000 00000100 00000000 00000000
7265Apply P(x) 10001000 00010000 1
7266 00000000 00000000 00000000 00000000 00011111 10000000 10000100 00000000 00000000
7267Apply P(x) 10001 00000010 0001
7268 00000000 00000000 00000000 00000000 00001110 00001010 10010100 00000000 00000000
7269Apply P(x) 1000 10000001 00001
7270 00000000 00000000 00000000 00000000 00000110 10001011 10011100 00000000 00000000
7271Apply P(x) 100 01000000 100001
7272 00000000 00000000 00000000 00000000 00000010 11001011 00011000 00000000 00000000
7273Apply P(x) 10 00100000 0100001
7274 00000000 00000000 00000000 00000000 00000000 11101011 01011010 00000000 00000000
7275Apply P(x) 10001000 00010000 1
7276 00000000 00000000 00000000 00000000 00000000 01100011 01001010 10000000 00000000
7277Apply P(x) 1000100 00001000 01
7278 00000000 00000000 00000000 00000000 00000000 00100111 01000010 11000000 00000000
7279Apply P(x) 100010 00000100 001
7280 00000000 00000000 00000000 00000000 00000000 00000101 01000110 11100000 00000000
7281Apply P(x) 100 01000000 100001
7282 00000000 00000000 00000000 00000000 00000000 00000001 00000110 01100100 00000000
7283Apply P(x) 1 00010000 00100001
7284 00000000 00000000 00000000 00000000 00000000 00000000 00010110 01000101 00000000
7285Apply P(x) 10001 00000010 0001
7286 00000000 00000000 00000000 00000000 00000000 00000000 00000111 01000111 00010000
7287Apply P(x) 100 01000000 100001
7288 00000000 00000000 00000000 00000000 00000000 00000000 00000011 00000111 10010100
7289Apply P(x) 10 00100000 0100001
7290 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00100111 11010110
7291Apply P(x) 1 00010000 00100001
7292 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00110111 11110111
7293XOR FF 11001000 00001000
7294MSBit First 00010011 00010000
7295crc = 1310
325 - CLXIII -
326
7296
7297C Code Example
7298
7299The following is an example of C code which calculates the <crc> field in a
7300manner compliant with C12.22 layer 2. This code is provided as an example
7301only.
7302
7304
7305unsigned short crc16(unsigned char octet, unsigned short crc);
7306unsigned short crc(int size, unsigned char *packet);
7307
7308
7309unsigned short crc16(unsigned char octet, unsigned short crc)
7310{
7311 int i;
7312
7313 for (i = 8; i; i--)
7314 {
7315 if (crc & 0x0001)
7316 {
7317 crc >>= 1;
7318 if (octet & 0x01)
7319 crc |= 0x8000;
7320 crc = crc ^ 0x8408; /* 0x1021 inverted = 1000 0100 0000 1000 */
7321 octet >>= 1;
7322 }
7323 else
7324 {
7325 crc >>= 1;
7326 if (octet & 0x01)
7327 crc |= 0x8000;
7328 octet >>= 1;
7329 }
7330 }
7331
7332 return crc;
7333}
7334
7335unsigned short crc(int size, unsigned char *packet)
7336{
7337 int i;
7338 unsigned short crc;
7339
7340 crc = (~packet[1] << 8) | (~packet[0] & 0xFF);
7341
7342 for (i=2 ; i<size; i++)
7343 crc = crc16(packet[i], crc);
7344
7345 crc = crc16(0x00, crc);
7346 crc = crc16(0x00, crc);
7347 crc = ~crc;
7348 crc = crc >> 8 | crc << 8;
7349
7350 return crc;
7351}
7352
7353int main()
7354{
7355 unsigned char packet[] = { 0xEE, 0x00, 0x00, 0x00, 0x00, 0x01, 0x20 };
7356
7357 printf("Crc = %04x \n", crc(sizeof(packet), packet));
7358 return 0;
7359}
7360
327 - CLXIV -
328
7361
7362ANNEX J – DES/CDC and DESede/CDC
7363
7364INFORMATIVE
7365
7366This annex contains a description of the encryption algorithms required to
7367implement the ANSI C12.22 security mechanism. These algorithms or ciphers are
7368called Data Encryption Standard with Cipher Block Chaining (DES/CBC) and
7369Triple DES with Cipher Block Chaining (DESede/CBC).
7370
7371Data Encryption Standard - DES
7372
7373The first step to understand the ANSI C12.22 security mechanism is to
7374understand the Data Encryption Standard or DES. DES is a block cipher that
7375can encrypt and decrypt 8 bytes of information at one time. Encryption is
7376controlled by a symmetrical key of 56 bits. Symmetrical key means that both
7377side of a transaction must have the same key to be able to encrypt and decrypt
7378successfully a piece of information. DES Keys are store as 8 octets quantities
7379where bits 1 to 7 of each byte contains valid key information. Bit 0 (least
7380significant bit) is not used by the cipher and must be set to an odd parity.
7381If you are not already familiar with DES, a complete description of this
7382algorithm is presented later in this annex. The following is an example of a
7383DES encryption:
7384
Plain text = CD 38 F8 1F 80 FE 23 0E
Key = CD 38 F8 1F 80 FE 23 0E
Cipher text = 38 DB C6 70 9A 66 FF B2
7385
7386DESede
7387
7388DESede consists of applying DES three times on the same information. This way,
7389key length is extended to 24 bytes that make it harder to crack. The first
7390step of DESede consists of encrypting a plain text with the first 8 bytes of
7391the key. The result is after decrypted with the next 8 bytes of the key. The
7392last step consists of encrypting again the result with the last 8 bytes of the
7393key. Per example:
7394
Plain text = CD 38 F8 1F 80 FE 23 0E
Key = CD 38 F8 1F 80 FE 23 0E EC B3 79 2C D0 46 C4 32 7A DC
F2 0E 29 31 76 75
DES encryption = 38 DB C6 70 9A 66 FF B2
DES decryption = 2B B4 AA F1 95 DD D9 CC
DES encryption = 41 A6 16 B9 C3 BC 78 F4 = DESede
7395
7396CBC
7397
7398Both DES and DESede are capable of encrypting and decrypting only 8 bytes of
7399information. To encrypt and decrypt variable size messages, a technique called
7400cipher block chaining or CBC is used. For encryption, this technique consists
7401of the following steps:
7402
74031. Add the necessary padding to the plain text to adjust its length to a
7404 multiple of 8 octets.
74052. Exclusive or (XOR) the first 8 octets of plain text (P1) with the
7406 Initialization Vector (IV) to produce (X1).
329 - CLXV -
330
74073. Encrypt the value (X1) to produce the first 8 octets of cipher text (C1).
74084. XOR the next 8 octetsof plain text (P2) with the first 8 octets of cipher
7409 text (C1) to produce (X2).
74105. Encrypt the value (X2) to produce the next 8 octets of cipher text (C2).
74116. Continue this process until the end of the plain text (Pn)
7412
Key IV P1 P2 Pn
XOR XOR … XOR
X1 X2 Xn
Encrypt Encrypt Encrypt
7413 C1 C2 Cn
7414
7415
7416For decryption, this technique consists of the following steps:
74171. Decrypt the first 8 octets of cipher text (C1) to produce (X1).
74182. XOR the value (X1) with the Initialization Vector (IV) to produce the first
7419 8 bytes of plain text (P1).
74203. Decrypt the next 8 octets of cipher text (C2) to produce (X2).
74214. XOR the value (X2) with the first 8 octets of cipher text (C1) to produce
7422 the next 8 octets of plain text (P2).
74235. Continue this process until the end of the cipher text (Cn)
7424
IV Key C1 C2 Cn
Decrypt Decrypt Decrypt
X1 X2 Xn
XOR XOR … XOR
7425 P1 P2 Pn
7426
7427In this document, plain text represents <app-data> unencrypted, the
7428initialization vector represents the <iv>, and the cipher text represents
7429<app-data> encrypted.
7430
7431Legal Issues
7432
7433Cryptographic devices implementing this standard may be covered by U.S. and
7434foreign patents issued to the International Business Machines Corporation.
7435However(IBM). However, IBM has granted nonexclusive, royalty-free licenses
7436under the patents to make, use and sell apparatus, which complies with the
7437standard. The terms, conditions, and scope of the license are set out in
7438notices published in the May 13, 1975 and August 31, 1976 issues of the
7439Official Gazette of the United States Patent and Trademark Office (9434 O"G"
7440452 and 949 O.G. 1717).
7441
331 - CLXVI -
332
7442DES Implementation
7443
7444The DES algorithm, adopted by the U.S. government in 1977, is a block cipher
7445that transforms 64-bit data blocks under a 56-bit secret key, by means of
7446permutation and substitution. The following is a description of how to use the
7447DES algorithm to encrypt one 64-bit block.
7448
7449Step 1
7450
7451Get a 64-bit key.
7452
7453Step 2
7454
7455Perform the following permutation on the 64-bit key. The most significant bit
7456of each byte is discarded, reducing the key to 56 bits. Bit 1 of the permuted
7457block is bit 57 of the original key, bit 2 is bit 49, and so on with bit 56
7458being bit 4 of the original key.
7459
746057 49 41 33 25 17 9 1 58 50 42 34 26 18
746110 2 59 51 43 35 27 19 11 3 60 52 44 36
746263 55 47 39 31 23 15 7 62 54 46 38 30 22
746314 6 61 53 45 37 29 21 13 5 28 20 12 4
7464
7465Split the permuted key into two halves. The first 28 bits are called C[0] and
7466the last 28 bits are called D[0].
7467
7468Start with i = 1.
7469
7470Step 3, 4
7471
7472Perform one or two circular left shifts on both C[i-1] and D[i-1] to get C[i]
7473and D[i], respectively. The number of shifts per iteration is given in the
7474table below.
7475
7476Iteration # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
7477Left Shifts 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1
7478
7479Step 5
7480
7481Permute the concatenation C[i]D[i] as indicated below. This will yield K[i],
7482which is 48 bits long.
7483
748414 17 11 24 1 5 3 28 15 6 21 10
748523 19 12 4 26 8 16 7 27 20 13 2
748641 52 31 37 47 55 30 40 51 45 33 48
748744 49 39 56 34 53 46 42 50 36 29 32
7488
7489Loop back to Step 3 until K[16] has been calculated.
7490
7491Step 6
7492
7493Get a 64-bit data block. If the block is shorter than 64 bits, it should be
7494padded as appropriate for the application.
7495
7496Step 7
7497
333 - CLXVII -
334
7498Perform the following permutation on the data block.
7499
750058 50 42 34 26 18 10 2 60 52 44 36 28 20 12 4
750162 54 46 38 30 22 14 6 64 56 48 40 32 24 16 8
750257 49 41 33 25 17 9 1 59 51 43 35 27 19 11 3
750361 53 45 37 29 21 13 5 63 55 47 39 31 23 15 7
7504
7505Split the block into two halves. The first 32 bits are called L[0], and the
7506last 32 bits are called R[0].
7507
7508Start with i = 1.
7509
7510Step 8
7511
7512Expand the 32-bit R[i-1] into 48 bits according to the bit-selection function
7513below.
7514
751532 1 2 3 4 5 4 5 6 7 8 9
7516 8 9 10 11 12 13 12 13 14 15 16 17
751716 17 18 19 20 21 20 21 22 23 24 25
751824 25 26 27 28 29 28 29 30 31 32 1
7519
7520Step 9
7521
7522Exclusive-or E(R[i-1]) with K[i].
7523
7524Step 10
7525
7526Break E(R[i-1]) xor K[i] into eight 6-bit blocks. Bits 1-6 are B[1], bits 7-12
7527are B[2], and so on with bits 43-48 being B[8].
7528
7529Substitute the values found in the S-boxes for all B[j]. Start with j = 1. All
7530values in the S-boxes should be considered 4 bits wide. Take the 1st and 6th
7531bits of B[j] together as a 2-bit value indicating the row in S[j]. Take the
75322nd through 5th bits of B[j] together as a 4-bit value indicating the column
7533in S[j].
7534
7535S[1]
753614 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
7537 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
7538 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
753915 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
7540
7541S[2]
754215 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
7543 3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
7544 0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
754513 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
7546
7547S[3]
754810 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
754913 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
755013 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
7551 1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12
7552
7553S[4]
335 - CLXVIII -
336
7554 7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
755513 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
755610 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
7557 3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
7558
7559S[5]
7560 2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
756114 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
7562 4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
756311 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
7564
7565S[6]
756612 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
756710 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
7568 9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
7569 4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
7570
7571S[7]
7572 4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
757313 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
7574 1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
7575 6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
7576
7577S[8]
757813 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
7579 1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
7580 7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
7581 2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
7582
7583Step 11
7584
7585Permute the concatenation of B[1] through B[8] as indicated below.
7586
758716 7 20 21 29 12 28 17
7588 1 15 23 26 5 18 31 10
7589 2 8 24 14 32 27 3 9
759019 13 30 6 22 11 4 25
7591
7592Step 12
7593
7594Exclusive-or the resulting value with L[i-1]. Thus, all together, your R[i] =
7595L[i-1] xor P(S[1](B[1])...S[8](B[8])), where B[j] is a 6-bit block of E(R[i-
75961]) xor K[i].
7597
7598Step 13
7599
7600L[i] = R[i-1].
7601
7602Loop back to Step 8 until K[16] has been applied.
7603
7604Step 14
7605
7606Perform the following permutation on the block R[16]L[16].
7607
760840 8 48 16 56 24 64 32 39 7 47 15 55 23 63 31
760938 6 46 14 54 22 62 30 37 5 45 13 53 21 61 29
337 - CLXIX -
338
761036 4 44 12 52 20 60 28 35 3 43 11 51 19 59 27
761134 2 42 10 50 18 58 26 33 1 41 9 49 17 57 25
7612
7613To decrypt, use the same process, but just use the keys K[i] in reverse order.
7614That is, instead of applying K[1] for the first iteration, apply K[16], and
7615then K[15] for the second, on down to K[1].
7616
339 - CLXX -
340
7617
7618DES Code Example
7619
7620The following is an example of C code that encrypts a data block of 64 bits
7621using a key of 56 bits. This code is provided as an example only, and is not
7622required for compliance with the Data Encryption Standard.
7623
7625#include <stdlib.h>
7626typedef unsigned char uint8;
7627
7628static uint8 perm1[56] = {
7629 57, 49, 41, 33, 25, 17, 9, 1, 58, 50, 42, 34, 26, 18,
7630 10, 2, 59, 51, 43, 35, 27, 19, 11, 3, 60, 52, 44, 36,
7631 63, 55, 47, 39, 31, 23, 15, 7, 62, 54, 46, 38, 30, 22,
7632 14, 6, 61, 53, 45, 37, 29, 21, 13, 5, 28, 20, 12, 4
7633};
7634
7636 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
7637 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 1,
7638 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43,
7639 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 29
7640};
7641
7643 14, 17, 11, 24, 1, 5, 3, 28, 15, 6, 21, 10, 23, 19, 12, 4,
7644 26, 8, 16, 7, 27, 20, 13, 2, 41, 52, 31, 37, 47, 55, 30, 40,
7645 51, 45, 33, 48, 44, 49, 39, 56, 34, 53, 46, 42, 50, 36, 29, 32
7646};
7647
7649 58, 50, 42, 34, 26, 18, 10, 2, 60, 52, 44, 36, 28, 20, 12, 4,
7650 62, 54, 46, 38, 30, 22, 14, 6, 64, 56, 48, 40, 32, 24, 16, 8,
7651 57, 49, 41, 33, 25, 17, 9, 1, 59, 51, 43, 35, 27, 19, 11, 3,
7652 61, 53, 45, 37, 29, 21, 13, 5, 63, 55, 47, 39, 31, 23, 15, 7,
7653};
7654
7656 32, 1, 2, 3, 4, 5, 4, 5, 6, 7, 8, 9, 8, 9, 10, 11,
7657 12, 13, 12, 13, 14, 15, 16, 17, 16, 17, 18, 19, 20, 21, 20, 21,
7658 22, 23, 24, 25, 24, 25, 26, 27, 28, 29, 28, 29, 30, 31, 32, 1,
7659};
7660
7662 16, 7, 20, 21, 29, 12, 28, 17, 1, 15, 23, 26, 5, 18, 31, 10,
7663 2, 8, 24, 14, 32, 27, 3, 9, 19, 13, 30, 6, 22, 11, 4, 25,
7664};
7665
7667 40, 8, 48, 16, 56, 24, 64, 32, 39, 7, 47, 15, 55, 23, 63, 31,
7668 38, 6, 46, 14, 54, 22, 62, 30, 37, 5, 45, 13, 53, 21, 61, 29,
7669 36, 4, 44, 12, 52, 20, 60, 28, 35, 3, 43, 11, 51, 19, 59, 27,
7670 34, 2, 42, 10, 50, 18, 58, 26, 33, 1, 41, 9, 49, 17, 57, 25,
7671};
7672
7673static uint8 sboxes[8][64] = {
7674{
7675 14,4,13,1,2,15,11,8,3,10,6,12,5,9,0,7,0,15,7,4,14,2,13,1,10,6,12,11,9,5,3,8,
7676 4,1,14,8,13,6,2,11,15,12,9,7,3,10,5,0,15,12,8,2,4,9,1,7,5,11,3,14,10,0,6,13,
7677},{
7678 15,1,8,14,6,11,3,4,9,7,2,13,12,0,5,10,3,13,4,7,15,2,8,14,12,0,1,10,6,9,11,5,
7679 0,14,7,11,10,4,13,1,5,8,12,6,9,3,2,15,13,8,10,1,3,15,4,2,11,6,7,12,0,5,14,9,
7680},{
7681 10,0,9,14,6,3,15,5,1,13,12,7,11,4,2,8,13,7,0,9,3,4,6,10,2,8,5,14,12,11,15,1,
7682 13,6,4,9,8,15,3,0,11,1,2,12,5,10,14,7,1,10,13,0,6,9,8,7,4,15,14,3,11,5,2,12,
7683},{
7684 7,13,14,3,0,6,9,10,1,2,8,5,11,12,4,15,13,8,11,5,6,15,0,3,4,7,2,12,1,10,14,9,
7685 10,6,9,0,12,11,7,13,15,1,3,14,5,2,8,4,3,15,0,6,10,1,13,8,9,4,5,11,12,7,2,14,
7686},{
341 - CLXXI -
342
7687 2,12,4,1,7,10,11,6,8,5,3,15,13,0,14,9,14,11,2,12,4,7,13,1,5,0,15,10,3,9,8,6,
7688 4,2,1,11,10,13,7,8,15,9,12,5,6,3,0,14,11,8,12,7,1,14,2,13,6,15,0,9,10,4,5,3,
7689},{
7690 12,1,10,15,9,2,6,8,0,13,3,4,14,7,5,11,10,15,4,2,7,12,9,5,6,1,13,14,0,11,3,8,
7691 9,14,15,5,2,8,12,3,7,0,4,10,1,13,11,6,4,3,2,12,9,5,15,10,11,14,1,7,6,0,8,13,
7692},{
7693 4,11,2,14,15,0,8,13,3,12,9,7,5,10,6,1,13,0,11,7,4,9,1,10,14,3,5,12,2,15,8,6,
7694 1,4,11,13,12,3,7,14,10,15,6,8,0,5,9,2,6,11,13,8,1,4,10,7,9,5,0,15,14,2,3,12,
7695},{
7696 13,2,8,4,6,15,11,1,10,9,3,14,5,0,12,7,1,15,13,8,10,3,7,4,12,5,6,11,0,14,9,2,
7697 7,11,4,1,9,12,14,2,0,6,10,13,15,3,5,8,2,1,14,7,4,10,8,13,15,12,9,0,3,5,6,11,
7698}};
7699
7700static uint8 keys[16][48];
7701
7702/**************************************************************************/
7703void Permutation(uint8 *dst, uint8 *src, uint8 lgn, uint8 *perm_table)
7704{
7705 uint8 tmp[64];
7706
7707 if (src == NULL)
7708 {
7709 src = tmp;
7710 memcpy(src, dst, 64);
7711 }
7712
7713 for (; lgn > 0; lgn--, dst++, perm_table++)
7714 *dst = src[*perm_table - 1];
7715}
7716
7717/**************************************************************************/
7718void Xor(uint8 *dst, uint8 *src, uint8 lgn)
7719{
7720 for (; lgn > 0; lgn--, dst++, src++)
7721 *dst ^= *src;
7722}
7723
7724/**************************************************************************/
7725void Copy(uint8 *dst, uint8 *src, uint8 lgn)
7726{
7727 for (; lgn > 0; lgn--, dst++, src++)
7728 *dst = *src;
7729}
7730
7731/**************************************************************************/
7732void SBoxes(uint8 *dst, uint8 *src, uint8 *sbox)
7733{
7734 int i;
7735
7736 i = src[4];
7737 i |= src[3] << 1;
7738 i |= src[2] << 2;
7739 i |= src[1] << 3;
7740 i |= src[5] << 4;
7741 i |= src[0] << 5;
7742
7743 i = sbox[i];
7744
7745 dst[3] = i & 1;
7746 dst[2] = i >> 1 & 1;
7747 dst[1] = i >> 2 & 1;
7748 dst[0] = i >> 3 & 1;
7749}
7750
7751/**************************************************************************/
7752void Des(uint8 *_key, uint8 *_data, int _encrypt)
7753{
7754 uint8 key[64], data[64], right[48];
7755 int i, j;
7756
7757 Permutation(key, _key, 56, perm1);
7758
343 - CLXXII -
344
7759 for (i = 1; i <= 16; i++)
7760 {
7761 Permutation(key, NULL, 56, perm2);
7762
7763 if (i != 1 && i != 2 && i != 9 && i != 16)
7764 Permutation(key, NULL, 56, perm2);
7765
7766 Permutation(keys[_encrypt ? i - 1 : 16 - i], key, 48, perm3);
7767 }
7768
7769 Permutation(data, _data, 64, perm4);
7770
7771 for (i = 1; i <= 16; i++)
7772 {
7773 Permutation(right, data + 32, 48, perm5);
7774 Xor(right, keys[i - 1], 48);
7775
7776 for (j = 0; j < 8; j++)
7777 SBoxes(right + 4 * j, right + 6 * j, sboxes[j]);
7778
7779 Permutation(right, NULL, 32, perm6);
7780 Xor(right, data, 32);
7781 Copy(data, data + 32, 32);
7782 Copy(data + 32, right, 32);
7783 }
7784
7785 Copy(_data, data + 32, 32);
7786 Copy(_data + 32, data, 32);
7787 Permutation(_data, NULL, 64, perm7);
7788}
7789
345 - CLXXIII -
346
7790
7791DES Trace Example
7792
7793This example shows the bit manipulations performed in each step in compliance
7794with the Data Encryption Standard.
7795
7796Initialize keys
7797 Step 1: Key = 1100110100111000111110000001111110000000111111100010001100001110
7798 Step 2: Permutation = 00110101001001010110011000101110100010101001101011111110
7799 Step 3: Rotation = 01101010010010101100110001001101000101010011010111111101
7800 Step 5: keys[1] = 010001101011000010010011010000111001110101101111
7801 Step 3: Rotation = 11010100100101011001100010001010001010100110101111111011
7802 Step 5: keys[2] = 110010000110001100100101011111001101011101011010
7803 Step 3: Rotation = 10101001001010110011000100010100010101001101011111110111
7804 Step 4: Rotation = 01010010010101100110001000111000101010011010111111101110
7805 Step 5: keys[3] = 100000011001111100011001100111011111010001101010
7806 Step 3: Rotation = 10100100101011001100010001100001010100110101111111011101
7807 Step 4: Rotation = 01001001010110011000100011010010101001101011111110111010
7808 Step 5: keys[4] = 010001010011001011100011111011001111111001100000
7809 ...
7810 Skipping keys[5] to keys[15]
7811 ...
7812 Step 3: Rotation = 00110101001001010110011000101110100010101001101011111110
7813 Step 5: keys[16] = 101000100100110101101000111111101110111001001010
7814
7815Process data block
7816 Step 6: Data = 1100110100111000111110000001111110000000111111100010001100001110
7819 Step 9: Xor = 010111000001101110011110000101100110001000111111
7820 Step 10: SBoxes = 10110011000011110010010111111011
7821Step 11: Permutation = 11001010110100100111111011001011
7822 Step 12: Xor = 11101111111111001101011110000010
7823 Step 13: Copy = 0011010101100110101011111110100011101111111111001101011110000010
7825 Step 9: Xor = 101111011001110011011100000101100010101101011111
7826 Step 10: SBoxes = 01110110111101000010111010100010
7828 Step 12: Xor = 01100001010001010011100001110111
7829 Step 13: Copy = 1110111111111100110101111000001001100001010001010011100001110111
7831 Step 9: Xor = 001100011011010100010011000000101111011111000100
7832 Step 10: SBoxes = 10111001110001110010101001101000
7834 Step 12: Xor = 01110111000001011000000000000000
7835 Step 13: Copy = 0110000101000101001110000111011101110111000001011000000000000000
7837 Step 9: Xor = 011111111101101011101000001011001111111001100000
7838 Step 10: SBoxes = 10001110100111000111010111100111
7840 Step 12: Xor = 00000101110110110000010110001110
7841 Step 13: Copy = 0111011100000101100000000000000000000101110110110000010110001110
7842 ...
7843 Skipping round 5 to 15
7844 ...
7846 Step 9: Xor = 110010001001101000111010010101001001000111100111
7847 Step 10: SBoxes = 11001111100000101111011101110111
7849 Step 12: Xor = 01101110110110110110010001000010
7850 Step 13: Copy = 1101011011101001010100111111011001101110110110110110010001000010
7851 Step 14: Result = 0011100011011011110001100111000010011010011001101111111110110010
347 - CLXXIV -
348
7852
7853CBC Code Example
7854
7855The following is an example of C code that encrypts and decrypts messages of
7856variable length, however message length must be a multiple of 8 bytes. These
7857procedures can be used for both DES/CBC or DESede/CBC depending of the key
7858length provided (8 bytes for DES and 24 bytes for DESede). This code is
7859provided as an example only, and is not required for compliance with the
7860either DES/CBC or DESede/CBC.
7861
7862static uint8 des_iv[64] = {
7863 0,0,1,1,1,0,1,0,0,1,1,1,1,1,0,1,1,1,1,0,0,0,1,0,0,0,1,1,1,0,0,0,
7864 0,0,1,1,1,0,1,0,0,1,1,1,1,1,0,1,1,1,1,0,0,0,1,0,0,0,1,1,1,0,0,0
7865};
7866
7867static uint8 des_key[64] = {
7868 0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,1,0,0,0,0,0,1,0,0,
7869 0,0,0,0,0,1,0,1,0,0,0,0,0,1,1,0,0,0,0,0,0,1,1,1,0,0,0,0,1,0,0,0
7870};
7871
7872static uint8 des_ede_iv[64] = {
7873 0,1,1,1,0,0,0,1,0,1,1,1,1,1,0,1,1,1,1,0,0,0,1,0,0,0,1,1,1,0,0,0,
7874 0,1,1,1,0,0,0,1,0,1,1,1,1,1,0,1,1,1,1,0,0,0,1,0,0,0,1,1,1,0,0,0
7875};
7876
7877static uint8 des_ede_key[192] = {
7878 0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,1,0,0,0,0,0,1,0,0,
7879 0,0,0,0,0,1,0,1,0,0,0,0,0,1,1,0,0,0,0,0,0,1,1,1,0,0,0,0,1,0,0,0,
7880 0,0,0,0,1,0,0,1,0,0,0,0,1,0,1,0,0,0,0,0,1,0,1,1,0,0,0,0,1,1,0,0,
7881 0,0,0,0,1,1,0,1,0,0,0,0,1,1,1,0,0,0,0,0,1,1,1,1,0,0,0,1,0,0,0,0,
7882 0,0,0,1,0,0,0,1,0,0,0,1,0,0,1,0,0,0,0,1,0,0,1,1,0,0,0,1,0,1,0,0,
7883 0,0,0,1,0,1,0,1,0,0,0,1,0,1,1,0,0,0,0,1,0,1,1,1,0,0,0,1,1,0,0,0
7884};
7885
7886static uint8 data[192] = {
7887 0,1,1,1,1,1,0,1,0,1,0,1,1,0,0,0,1,0,0,0,0,0,0,0,0,0,1,0,0,1,1,1,
7888 0,0,0,0,0,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
7889 0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,1,0,0,0,1,0,0,1,0,0,0,0,0,
7890 0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,1,0,0,1,0,0,0,1,0,0,0,0,0,
7891 0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,
7892 0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,0,0,1,0,0
7893};
7894
7895/**************************************************************************/
7896void CbcEncrypt(uint8 *data, int data_length, uint8 *key, int key_length, uint8 *iv)
7897{
7898 int lgn = data_length;
7899
7900 while (data_length > 0)
7901 {
7902 if (data_length == lgn)
7903 Xor(data, iv, 64);
7904 else
7905 Xor(data, data-64, 64);
7906
7907 Des(key, data, 1);
7908 if (key_length == 192)
7909 {
7910 Des(key+64, data, 0);
7911 Des(key+128, data, 1);
7912 }
7913 data += 64;
7914 data_length -= 64;
7915 }
7916}
349 - CLXXV -
350
7917
7918/**************************************************************************/
7919void CbcDecrypt(uint8 *data, int data_length, uint8 *key, int key_length, uint8 *iv)
7920{
7921 data += data_length - 64;
7922
7923 while (data_length > 0)
7924 {
7925 if (key_length == 192)
7926 {
7927 Des(key+128, data, 0);
7928 Des(key+64, data, 1);
7929 }
7930 Des(key, data, 0);
7931
7932 if (data_length > 64)
7933 Xor(data, data-64, 64);
7934 else
7935 Xor(data, iv, 64);
7936
7937 data_length -= 64;
7938 data -= 64;
7939 }
7940}
7941
7942/**************************************************************************/
7943void Print(char *text, uint8 *data, int data_length)
7944{
7945 int i, byte;
7946
7947 printf(text);
7948
7949 for (i=0, byte=0; i<data_length; i++)
7950 {
7951 byte <<= 1;
7952 byte |= data[i];
7953 if ((i % 8) == 7)
7954 {
7955 printf("%02X", byte);
7956 byte = 0;
7957 }
7958 }
7959
7960 printf("\n");
7961}
7962
7963/**************************************************************************/
7964int main()
7965{
7966 Print("Key: ", des_key, sizeof(des_key));
7967 Print("IV: ", des_iv, sizeof(des_iv));
7968 Print("Plain text: ", data, sizeof(data));
7969 CbcEncrypt(data, sizeof(data), des_key, sizeof(des_key), des_iv);
7970 Print("Encrypted text: ", data, sizeof(data));
7971 CbcDecrypt(data, sizeof(data), des_key, sizeof(des_key), des_iv);
7973
7974 Print("\nKey: ", des_ede_key, sizeof(des_ede_key));
7975 Print("IV: ", des_ede_iv, sizeof(des_ede_iv));
7977 CbcEncrypt(data, sizeof(data), des_ede_key, sizeof(des_ede_key), des_ede_iv);
7978 Print("Encrypted text: ", data, sizeof(data));
7979 CbcDecrypt(data, sizeof(data), des_ede_key, sizeof(des_ede_key), des_ede_iv);
7981 return 0;
7982}
351 - CLXXVI -
352
7983
7984CBC Trace Example
7985
7986DES/CBC
7987
7988Following is an example of a read table 0 request encrypted with DES/CBC.
7989
7990Read request 60 2D A2 0A A2 08 2A 86 48 CE 52 03
7991 16 06 A6 0A A2 08 2A 86 48 CE 52 03
7992 16 7D AC 09 A1 01 02 A2 04 39 86 F5
7993 1C BE 08 40 C5 36 70 8C F6 00 EB
7994Where
799560 2D = ACSE code, length
7996 A2 0A = Called code, length
7997 A2 08 2A8648CE52031606 = Called Aptitle UID
7998 A6 0A = Calling Aptitle code, length
7999 A2 08 2A8648CE5203167D = Calling Aptitle UID
8000 AC 09 = Authentication value code, length
8001 A1 01 02 = Key id code, length, value
8002 A2 04 3986F51C = Initialization vector code, length, value
8003 BE 08 = Application data code, length
8004 40C536708CF600EB = Application data encrypted
8005
8006Key = 8F39AEB8FA9041AF
8007IV = 3986F51C3986F51C
8008Plain text = 3AA9800403300000
8009Cipher text = 40C536708CF600EB
8010
8011DESede/CBC
8012
8013This next example represent the same read request encrypted this time with
8014DESede/CBC.
8015
8016Write request 60 2D A2 0A A2 08 2A 86 48 CE 52 03
8017 16 06 A6 0A A2 08 2A 86 48 CE 52 03
8018 16 7D AC 09 A1 01 02 A2 04 39 86 F6
8019 9E BE 08 E1 02 CD 4D 81 29 D6 43
8020Where
802160 2D = ACSE code, length
8022 A2 0A = Called code, length
8023 A2 08 2A8648CE52031606 = Called Aptitle UID
8024 A6 0A = Calling Aptitle code, length
8025 A2 08 2A8648CE5203167D = Calling Aptitle UID
8026 AC 09 = Authentication value code, length
8027 A1 01 02 = Key id code, length, value
8028 A2 04 33986F69E = Initialization vector code, length, value
8029 BE 08 = Application data code, length
8030 E102CD4D8129D643 = Application data encrypted
8031
8032Key = E59B4741A7D4067EAB84BA62C49153A1AA29A0E1E6DE3653
8033IV = 3986F69E3986F69E
8034Plain text = 32E4800404300000
8035Encrypted text = E102CD4D8129D643
353 - CLXXVII -
354
8036Annex K - Implementation guideline
8037
8038INFORMATIVE
8039
8040
8041Overview
8042
8043This informative annex introduces the issues pertaining to the actual
8044implementation of the C12.22 standard normative sections. The annex contains
8045the following parts:
8046 Implementation issues,
8047 Implementation use cases, and,
8048 Rationales
8049
8050The issues discussed in next section describe those implementation decisions
8051observed by early implementers of this standard that will aid in the
8052accomplishment of interoperable implementations.
8053The Use Cases describe the application scenarios to which C12.22 was
8054anticipated to support. These use cases make use of UMLi Use Case diagrams,
8055and, sequence diagrams to illustrate the critical steps required to implement
8056them.
8057
8058Rationales describe some of the considerations that were used in steering the
8059design of the standard. Some of these rationales are philosophical, old wives
8060tales, and other folklore.
8061
8062Implementation issues
8063
8064The issues in this section are those currently observed in the application of
8065the normative parts of document. At the time of document completion, these may
8066remain as part of the implementation guideline, or may result in explicit
8067modifications or clarifications in the normative parts of the standard.
8068
8069Transparency
8070
8071It is highly recommended that implementers of the layer 2 services of C12.22
8072use and support the Transparency function (section 7.7.9). This allows both
8073ends of the link to use the start of packet character (0EE hex) as a
8074synchronization byte since it can only exist as the start of frame and not as
8075a part of a valid packet. Failure to support this function could cause delays
8076in resynchronization in the event of data link error.
8077
8078Segmentation
8079
8080Segmentation support is not usually part of an application layer. It was
8081incorporated into the application layer of the standard to support deployed
8082networks which incorporate no such feature. It is intended to be implemented
8083as a sublayer of the Application Layer with an interface to the lower layers.
8084Implicit within the standard are the following pieces of information that the
8085Segmentation part of the Application Layer must "know":
8086
80871. Maximum size of underlying datagram supported
80882. How to send error messages <sgns> and <sgnp> either "up" to the application
8089 layer or "down" to the lower layers of the network (and ultimately to the
8090 distant end.)
355 - CLXXVIII -
356
80913. The maximum size of an available reassembly buffer.
8092
8093It should be understood that both the maximum sizes could be dynamic.
8094TODO: How are segment sizes negotiated? What is the minimum reassembly
8095buffer size?
8096When multiple segments are received, the Application Layer Session Timeout
8097timer starts when the first APDU is received and is stopped when the complete
8098APDU is either reassembled or an error message is sent to the underlying
8099network layer. For this reason, implementers may want to support larger
8100session timeouts for networks on which this segmentation is provided.
8101TODO: Explain Application Layer Session Timeout timer use in sessionless
8102communications as reassembly timer?
8103
8104Interfacing to arbitrary lower layers
8105
8106The implementation of a compliant C12.22 node requires that the standard
8107services are transported over an underlying network. While any network is
8108intended to be supported, some facts about C12.22 should help the implementer
8109determine whether a given network will have sufficient performance to work.
8110While the sections below refer to a communications module, they are applicable
8111to C12.22 nodes with integrated communications module functions since the
8112distant node might have a communications module.
8113For example, what happens to an outstanding request when a communications
8114module link disappears spontaneously? How is the application notified that
8115this occurred and what is the syntax of such a notification?
8116
8117Data Rate
8118
8119The data rate specified for the case of a communications module interface is
81209600 bits per second, and while a network layer with a lower speed could be
8121supported, a large rate mismatch would require buffering, since there is no
8122flow control specified for the communications module. The inter-character
8123timeout is specified as 500 milliseconds, so network data rates less than 2
8124bits per second would absolutely require buffering within the communications
8125module.
8126
8127Packet Size
8128
8129The default maximum packet size specified for the communications module is 64
8130bytes. While the network could support sizes larger or smaller than this,
8131networks in which the packet size is fixed are usually more efficient when
8132using packet sizes that are near the maximum payload size for the network.
8133For example, if an RF (radio frequency) network had a fixed packet size of 200
8134bytes with six bytes being network overhead, (e.g. addressing, checksums,
8135etc.) then a packet size of 194 would provide a more efficient use of
8136bandwidth, as long as the C12.22 data being transferred is longer than 194
8137bytes.
8138TODO: Add use case for Trace service.
8139
8140Sequence Numbering
8141
8142The APDU sequence numbering is defined within the standard as " A number that
8143is randomly selected during node’s initialization then incremented each time a
8144new APDU is sent. This value shall not repeat within one minute." In the case
8145that a node sends an APDU and then is reset, as by a power fail, it is
8146important for the node to avoid sending a new APDU with a previously used
357 - CLXXIX -
358
8147sequence number. Because of this, it is recommended that the node store the
8148last sequence number used if possible so that it may check to assure that the
8149difference between the new random number generated and the last sequence
8150number used is sufficient to reduce the likelihood of duplication.
8151TODO: Describe how the sequence numbers are used for duplicate APDU rejection.
8152
8153Duplicate apdu rejection and invocationID elements
8154
8155Section 6.3.3.8 describes the use of invocationID to accomplish duplicate apdu
8156rejection. What is the basis of recognizing a “duplicate”. Is it per
8157association, per session, per channel? Is it the whole apdu, the ApTitle pair
8158and invokeID? What about duplicate segments vs. duplicate entire apdus?
8159
8160GetCfg response and registration
8161
8162It is not clear if the ESN that is passed is that of the communications
8163module, the c12.22 device, the end device, or all. When the serial number is
8164placed in the registration service, what serial number is it?
8165
8166Use of Padding
8167
8168In 6.3.3.9 <padding> needs to state when padding may be included (anytime?
8169when encryption present?). If padding is present, is a terminating 0 required
8170for EPSEM_DATA since the padding is required to start with 0?
8171
8172Use of A4 and A8 tags
8173
8174Use of A4 and A8 need more description. Do you need to have A8 in requests,
8175and, A4 in responses.
8176
8177Can a relay discard ACSE tags it doesn’t recognize
8178
8179If the client and server are using ACSE services that intermediate relays
8180don’t understand, is it the relays responsibility to pass all tags forward? If
8181not, then no tags not explicitly mentioned can be used.
8182
8183Initialization Vector usage
8184
8185Should IV be in every packet? Or can sender and receiver auto-increment?
8186
8187Generation of NETWORK_INTERFACE_CONTROL_PROC procedure on network table change
8188
8189It is the responsibility of the client application to invoke the
8190NETWORK_INTERFACE_CONTROL_PROC procedure. This should cause the end device to
8191notify the appropriate communications module that significant change has
8192occurred.
8193
8194How does a data link negotiate up from C12.18 to C12.22
8195
8196In order for two devices to agree on whether they are using C12.18 or C12.22
8197to communicate there needs to be some explicit method to follow. For example,
8198a local optical port may support only C12.18. How does a C12.22 aware handheld
8199device determine how to communicate over this link?
8200Is there an explicit mechanism to negotiate between C12.18 and C12.22 when one
8201end of a communication seeks to use one frame format and the other end seeks
359 - CLXXX -
360
8202to use another? Is the frame format permanent, or on a message to message
8203basis?
8204
8205Service-length in EPSEM is ambiguous
8206
8207Service-length (see 6.3.3.9) in EPSEM is a little ambiguous. Do you need a 0
8208if only one PDU? BNF doesn't show optional multiple packets and when 0 length
8209is needed.
8210
361 - CLXXXI -
362
8211Annex L – Implementation Use Cases
8212
8213INFORMATIVE
8214
8215In order to ensure a robust standard, it is important to consider the uses
8216that the standard may be applied to. Such use-cases can sanity test the
8217standard in anticipated usage scenarios. Problems in implementing the use case
8218or in conceptually implementing the use case helps to refine the standard and
8219increase its fit to the application that inspired it.
8220
8221The use cases in this contribution briefly summarize some of the means by
8222which meters and communications modules might be installed and configured.
8223Use Cases are an established means of illustrating and specifying the behavior
8224of complex systems. In this section, Use Case’s will be presented for
8225application scenarios for C12.22.
8226
8227The use case itself is described in a text narrative. This narrative is
8228accompanied by a description of the actors, classes, and other common
8229parameters of the use case such as starting and ending conditions.
8230Beyond the simple statement version of an application scenario, it is possible
8231to describe with some detail the boundaries of its requirement. In addition,
8232it is useful to illustrate the operation of the function as well as describe
8233the unique participants in the realization of the function. This elaboration
8234is loosely termed a “scenario”. Modelers have found some useful diagrams and
8235methods of describing scenarios for these applications, termed “Use Cases”.
8236Out of these use cases are extracted the functional requirements of the
8237product or technology.
8238
8239The use case an be illustrated by two principal diagrams –
8240 1. Use case describes the association of actors, participants in a Use Case
8241 (which may also be part of other use cases), and the specific Use
8242 Case(s) illustrated.
8243 2. Time sequence diagram illustrates how the actors and classes can
8244 interact to implement the scenario.
8245
8246Use case terminology and definitions
8247
8248Actors
8249Classes
8250Objects
8251Use Case
8252Sequence Diagram
8253
8254Use Case template
8255
8256Use Case detail
8257
8258The use case is described textually with a summary of key descriptions. The
8259outline of the description is presented below:
8260Use case name:
8261 Name of Use Case.
8262Description:
8263 A paragraph(s) describing the scenario illustrated by this Use Case.
8264Actors:
8265 What are the actors that participate in the Use Case?
363 - CLXXXII -
364
8266Classes:
8267 What classes are necessary to either exchange or be exchanged within
8268 messages that implement the Use Case?
8269Performance Goals:
8270 What relevant performance goals are required for the proper performance
8271 of the Use Case?
8272Preconditions:
8273 What conditions are expected to exist prior to the start of the Use
8274 Case?
8275Begins When:
8276 What starts or triggers the performance of this Use Case?
8277Ends When:
8278 When is the Use Case finished?
8279Exceptions:
8280 What exceptional outcomes are there besides the normal one expected for
8281 a successful performance of the Use Case?
8282PostConditions:
8283 What is the state of “the system” after the use case has been completed?
8284SecurityConsiderations:
8285 What security considerations must be satisfied in implementing the use
8286 case?
8287Traceability:
8288 If this use case references other works or documents, the references are
8289 placed here.
8290
8291Symbols in Use Case Diagrams
8292
8293The Use Case Diagram presents in “iconic” (i.e. simple symbols) form the users
8294and other participants in Use Cases. The diagram, illustrated below, contains
8295the following components:
8296
Symbol Name Description
Package A rectangle that groups related use cases.
Actor A stick figure that represents one of the

participants in the Use Case. An actor may be a
user, a computer, or even a program or process. The
principal choice of what should be an actor is an
external participant in the use case.
Use Case A horizontal oval that represents a single Use Case
Association A line connecting an Actor with a Use Case. All the

Actors participating in a specific Use Case will
have a line connecting it with the Use Case symbol.
8297
8298Symbols in Sequence Diagrams
8299
8300The Sequence Diagram, or Time Sequence Diagram, illustrates the dynamic flow
8301of interactions between the major components of the system as time increases
8302from top to bottom. The following table describes the symbols used in the
8303sequence diagram:
8304
365 - CLXXXIII -
366
Symbol Name Description
Class A rectangle defines a concrete piece of
behavior/function. For example an end device.
Actor A stick figure that represents one of the participants
in the Use Case. For example, the customer.
Message A line connecting an Actor or Class represents a
message from one to another. The arrow end indicates
the direction of the message. For example, ReadTable
8305
8306Common actors and classes used in the Use Case descriptions
8307
8308Actors
8309
8310MeterReader
8311MeterVendor
8312CommunicationsModuleVendor
8313Installer
8314Customer
8315UtilityClient
8316
8317Classes
8318
8319Meter
8320CommunicationsModule
8321Relay
8322MasterRelay
8323
8324
8325TODO: ***Need to address the difference between the generic classes of end
8326device, for example, and the use of specific instances such as a “meter” in
8327the use cases which follow.
8328
8329Installation and configuration use cases
8330
8331The use cases in this section deal with the installation and configuration of
8332end devices and communications modules under varying circumstances.
8333
8334Use case name:
8335 Plug and Play
8336Description:
8337 An unconfigured meter and an unconfigured communications module are
8338 installed on a network with broadcast capability. Each component has a
8339 globally unique ESN embedded. The node is powered up and registers on
8340 the network and is assigned its ApTitle.
8341Actors:
8342 Installer, UtilityClient
8343Classes:
8344 C1222Device, CommunicationsModule, Relay, MasterRelay
8345Performance Goals:
8346 A C12.22 device with no individual configuration can successfully
8347 register with the communications network.
8348Preconditions:
8349 Installer has C12.22 devices and communications modules with unique
8350 serial numbers and default configurations for the network on which they
367 - CLXXXIV -
368
8351 are to be installed. Relays and master relays and authentication hosts
8352 are pre-configured with the necessary relationships.
8353Begins When:
8354 Installer installs device(s)
8355Ends When:
8356 Configuration of networked C12.22 node is complete
8357Exceptions:
8358 Failure?
8359PostConditions:
8360 Device is configured and able to participate in applications messaging
8361SecurityConsiderations:
8362 It is assumed that physical security is ensured by physical sealing of
8363 the end device / communications module assembly by the authorized
8364 installer.
8365Traceability:
8366 C12.22
8367
8368Plug and Play Use Case
Installer
Plug And Play
UtilityClient
8369
369 - CLXXXV -
370
8370
8371Plug And Play Sequence Diagram
8372
: UtilityClient : AuthenticationHost : MasterRelay : Relay : Installer
: C1222Device 1: Install()
: CommunicationsModule 2: Install()
3: InstalledNewC1222Device( endDeviceEID, commModuleEID )

4: Identification()
5: IdentifyResponse( resultCode, std, features, version )
6: Negotiate()
7: NegotiateResponse()
8: GetConfig()
9: GetConfigResponse()
10: LinkControl( interfaceCtrl, registrationCtrl, directMessagingCtrl, resetStatisticsCtrl, reloadCfgCtrl, numberOfChannel )
11: Registration( nativeAddress, serialNumber, nodeClass, apTitle, nodeType, registrationTimeOut )
12: Registration( registrationTimeOut, nodeType, nodeClass, apTitle, serialNumber, nativeAddress )
13: Registration( nativeAddress, serialNumber, nodeClass, apTitle, nodeType, registrationTimeOut )
14: RegistrationResponse( status, apTitle )

17: LinkControlResponse( numberOfChannel, registrationFlag, interfaceEna, apTitle, directMessagingFlag )
8373
8374
8375Plug and Play Messaging Details
8376
Msg# From To Description/Notes
Installer EndDevice Install end device
Installer CommunicationsModule Install communications
module
Installer UtilityClient Notify of installation of
C12.22 device and electronic
Ids of EndDevice and
CommunicationsModule
CommunicationsModule EndDevice Identification
EndDevice CommunicationsModule IdentifyResponse
CommunicationsModule EndDevice Negotiate
EndDevice CommunicationsModule NegotiateResponse
CommunicationsModule EndDevice GetConfig
EndDevice CommunicationsModule GetCongfigResponse
EndDevice CommunicationsModule LinkControl – turns link
on,registration request on,
sets broadcast ApTitle
CommunicationsModule Relay Registration – contains
serial number of EndDevice
and CommunicationsModule?,
nativeAddress of
CommunicationsModule
371 - CLXXXVI -
372
(assumes that the network
comm. Module is on has
automatic native address
assignment), the default
ApTitle is “not present”,
length of 0
Relay MasterRelay Forward registration request
MasterRelay UtilityClient Forward registration request
UtilityClient MasterRelay registration response
--Assigns ApTitle
MasterRelay Relay Forward registration
response
Relay CommunicationsModule Forward registration
response
CommunicationsModule EndDevice LinkControl response with
new ApTitle
8377
8378
8379Non-broadcast
8380
8381An unconfigured meter and an unconfigured communications module are installed
8382on a network without broadcast capability. Each component has a globally
8383unique ESN embedded. In addition, the communications module has a default
8384destination address embedded in it. The node is powered up and registers on
8385the network and is assigned its ApTitle.
8386
8387Factory preconfigured CM and meter
8388
8389Preconfigured communications modules / end device assemblies are delivered to
8390a job site. They are installed physically and turned on. It is expected that
8391they can successfully register with the network and obtain additional
8392configuration without manual intervention.
8393
8394Reconfiguring Factory preconfigured CM
8395
8396Communications modules and meter assemblies are in utility company warehouse
8397as per the previous use case; due to corporate merger and / or change of
8398communications channel supplier (e.g. cellular service provider) the modules
8399are to be reconfigured at installation time as each unit is installed." This
8400might seem like a trivial case, but if we're using the "master relay" scheme
8401and have added a static list of meter+comm module mappings to their system
8402database already, the traffic between the CM and the end device, or between
8403the CM and the network, might be different if it includes something like
8404previous CM native address and current CM native address.
8405
8406Separate installation
8407
8408A communications module is installed on a network. An end device is installed
8409at a later time. The combined communications node registers on the network and
8410are assigned its ApTitle.
8411
8412Communications module add
8413
373 - CLXXXVII -
374
8414An end device is installed and operating – perhaps being read via an optical
8415port. At some future time, a communications module is installed and powered
8416up. The network automatically configures and brings the node online.
8417
8418Communications module change
8419
8420A working node has the communications module replaced. At some future time, a
8421new communications module is installed and powered up. The network
8422automatically configures and brings the node online.
8423
8424Access through end device and communications module connections
8425
8426Access WAN through optical port
8427
8428It is desired to connect locally using an optical port to reach one of
8429possibly several WAN or LANs attached to the C12.22 node. A connected tool
8430must be able to distinguish message destinations for the end device, one of
8431the communications modules, and messages destined for the WAN. For example, a
8432field service tool retrieves initialization information for a specific
8433customer site through the connections provided to the network.
8434
8435Access communications module from optical port
8436
8437The optical port provides a uesful means to configure connected end devices
8438and communications modules. A field service tool is used to initialize the
8439communications modules configuration parameters when not available from the
8440C12.22 device.
8441
8442Access communications module from other communications module
8443
8444At telephone modem is connection to an C12.22 device is used to tailor the
8445operation of other communications module ports on this C12.22 node.
8446
8447Supervisory control
8448
8449Load management is exercised in three ways, each of which may use one-way or
8450two-way communication: direct, local, and distributed.
8451
8452Local direct load control
8453
8454Local control is exercised unilaterally by the energy customer, responsive to
8455static utility parameters and to customer objectives and parameters which may
8456be either static or dynamic. Consider a summer example. A commercial building
8457energy management system exercises local control of its HVAC system when, in
8458response to a time-of-use energy rate that changes seasonally, the HVAC system
8459"pre-cools" building temperature a few degrees before the mid-day peak price
8460period, and lets the temperature gradually rise during the afternoon. This
8461uses less energy during the peak price period than fixing the temperature at a
8462single set point. Consumption is obtained as load profile data or time of use
8463binning.
8464
8465Direct load control
8466
8467Direct control is any control that is exercised unilaterally by the utility.
8468The control information to be provided includes a start time, a randomization
8469period, a stop time, and a requester description, etc…. A message is sent to
375 - CLXXXVIII -
376
8470all customers involved in the service. The message provides all information
8471even if there are multiple parts to the message, that is, atomically, to
8472enable the load control signal to implemented by shedding, duty cycling, or
8473continuously variable capacity control over energy consuming appliances.
8474
8475Distributed control
8476
8477Distributed control is exercised by the energy customer in response to action
8478by the utility at the time of, or in anticipation of, the need for control.
8479Dynamic energy pricing is a clear example. One hour or one day in advance, the
8480utility signals the energy customer that energy prices will be higher than
8481expected. The customer or his equipment makes his own decision about how to
8482respond, if at all. Distributed control requires that end devices other than
8483meters be able to receive the pricing and scheduling signals.
8484
8485Communication Module Context
8486
8487Scenario: Talk to Communication Module from the Network
8488This facilitates access to services or data of communication modules that are
8489attached to a device, using the device node’s ApTitle.
8490
8491Test mode context
8492
8493Scenario: Diagnostic Development
8494
8495Test the end-to-end communications on a live network without altering the
8496operation of the node. Test messages are useful in demonstration, validation
8497and diagnosis of network operation on live networks.
8498
8499Application Context
8500
8501Scenario: The C12.19 application
8502Be able to send and receive data from a C12.22 node over the network.
8503
8504Supervisory control
8505
8506Scenario: Load control, Load management, Process Control
8507Delivery of mission critical messages in real time to the application layer.
8508
8509Exception report
8510
8511Scenario: Load control, Load management, Process Control. SCADA
8512Provides a mechanism for the transmission of urgent informative messages about
8513the values or states of a C12.22 node. Such messages are likely trigger
8514supervisory control messages from a control application.
8515
8516Notification
8517
8518Scenario: Exchange, Energy Statistic reports, Monitoring applications
8519Provides a mechanism for the transmission of non-urgent informative messages
8520about the values or states of a C12.22 node.
8521
8522Rationales
8523
8524This section summarizes some of the rationale behind what might otherwise be
8525non-obvious drivers for the details of the standard.
377 - CLXXXIX -
378
8526
379 - CXC -
380
8527Annex M – Protocol Modelling
8528INFORMATIVE
8529
8530Communication protocols, like the one defined by this standard are complex
8531creations. Arguably, the measure of success of a protocol standard is not
8532whether it can work, but whether it cannot fail. It is usually impossible to
8533exhaustively check a real implementation of a protocol under every
8534circumstance, and the checking of real implementations is anyway outside the
8535domain of a standards making body. Our concern is to verify that the protocol
8536specification itself is correct in the abstract, and that is why modelling is
8537a useful concept.
8538An architectural model of a building gives a very useful sense of what a real
8539building might look like even though the materials and scale are very
8540different. The reason that architectural models are used is to allow for the
8541the checking of some abstract concepts (e.g. the aesthetic appeal of a
8542building) without going to the expense and trouble of building a real version.
8543Similarly, the reason that a protocol model is created is to allow for the
8544checking of some abstract concepts (e.g. Absense of deadlocks) without going
8545to the expense and trouble of building a real version. Also, there are
8546circumstances under which the models can be tested, e.g. an earthquake
8547simulation for a skyscraper model, which are simply not possible to perform on
8548the real version.
8549
8550SPIN
8551
8552The tool I have used to model parts of the C12.22 protocol is called SPIN.
8553SPIN is a model checker which is freely available ( http://spinroot.com/ ) and
8554widely used and respected. In 2002, SPIN was recognized by the ACM
8555(Association for Computing Machinery) with a prestigious Software System
8556Award. Previous awards have been given for systems such as UNIX, Postscript,
8557and TCP/IP. The main author of the tool, Gerard J. Holzmann, has written two
8558books which may be of use and interest to standards committee members. The
8559first is now out of print, but available in many libraries. It is Design and
8560Validation of Computer Protocols and was published in 1990. The second is The
8561Spin Model Checker: Primer and Reference Manual which has just been published
8562(2004) and is available through Amazon.com and other book sources. Both are
8563well written and well worth the money.
8564
8565SPIN Basics
8566
8567The name SPIN was originally chosen as an acronym for Simple PROMELA
8568Interpreter. PROMELA, in turn, was an acronym for PROcess MEta LAnguage. The
8569details of exactly how the tool works are described in detail in the books and
8570on the web site mentioned, but from the point of view of a user who wishes to
8571model a protocol, the steps are as follows:
8572create an abstract model in PROMELA (a language not unlike C)
8573run debugging runs in SPIN to see how the model reacts
8574adjust (if necessary) the model
8575perform a verification run of SPIN
8576
8577Initial SPIN Model for C12.22 Layer 2 Routing
8578
8579The original model for the Layer 2 Routing concept from our January 2004
8580meeting looked like this in English:
8581The corresponding PROMELA model is:
381 - CXCI -
382
8582
8583/* layer2routing */
8584/*
8585 * This spin model does a check of certain aspects of the
8586layer 2 routing
8587 * algorithm that has been proposed for C12.22.
8588 *
8589 * written on 27 January 2004 by Ed Beroset
8590 */
8591
8592mtype { data, ack, nak };
8593
8594chan port[3] = [0] of { mtype, byte };
8595
8596proctype CM(chan localport) /* communications module */
8597{
8598 mtype type; /* the message type */
8599 byte dest; /* the destination address in data packet */
8600 bool busy; /* the CM is awaiting an ACK */
8601 do
8602 :: localport?ack(dest) ->
8603 busy = false;
8604 :: localport?nak(dest)-> /* assume this is last NAK */
8605 busy = false;
8606 :: localport?data(dest) ->
8607 localport!ack,dest; /* ACK this data */
8608 :: !busy ->
8609 if
8610 :: localport!data,0 -> /* talk to the end device */
8611 busy = true;
8612 :: localport!data,1 -> /* talk to port 1 */
8613 busy = true;
8615 busy = true;
8617 busy = true;
8618 :: skip;
8619 fi;
8620 od
8621}
8622
8623proctype ED(chan cm1, cm2, opt) /* end device */
8624{
8625 mtype type;
8626 byte dest;
8627 bool cm1busy, cm2busy, optbusy;
8628
8629 do
8630 :: cm1?ack(dest) ->
8631 cm1busy = false;
8632 :: cm1?nak(dest); /* just ignore for now */
8633 :: cm1?data(dest) ->
8634 if
8635 :: (dest == 0) -> /* it is for me */
8636 cm1!ack,0;
8637 :: (dest == 1) -> /* for port 1 */
383 - CXCII -
384
8638
8639 cm1!ack,0;
8640 cm1!data,1;
8641 cm1busy = true;
8642 :: (dest == 2) -> /* for port 2 */
8643 cm1!ack,0;
8644 cm2!data,1;
8646 :: (dest == 3) -> /* for port 3 */
8647 cm1!ack,0;
8648 opt!data,1;
8649 optbusy = true;
8650 :: else /* silently drop messages for invalid ports */
8651 fi;
8652 :: cm2?ack(dest) ->
8654 :: cm2?nak(dset); /* just ignore for now */
8656 if
8657 :: (dest == 0) -> /* it is for me */
8658 cm2!ack,0;
8659 :: (dest == 1) -> /* for port 1 */
8660 cm2!ack,0;
8661 cm1!data,1;
8663 :: (dest == 2) -> /* for port 2 */
8664 cm2!ack,0;
8665 cm2!data,1;
8667 :: (dest == 3) -> /* for port 3 */
8668 cm2!ack,0;
8669 opt!data,1;
8672 fi;
8673 :: opt?ack(dest) ->
8674 optbusy = false;
8675 :: opt?nak(dest); /* just ignore for now */
8676 :: opt?data(dest) ->
8677 if
8678 :: (dest == 0) -> /* it is for me */
8679 opt!ack,0;
8680 :: (dest == 1) -> /* for port 1 */
8681 opt!ack,0;
8682 cm1!data,1;
8684 :: (dest == 2) -> /* for port 2 */
8685 opt!ack,0;
8686 cm2!data,1;
8688 :: (dest == 3) -> /* for port 3 */
8689 opt!ack,0;
8690 opt!data,1;
8693 fi;
385 - CXCIII -
386
8694 od
8695}
8696
8697init
8698{
8699 atomic {
8700 run CM(port[0]);
8703 run ED(port[0], port[1], port[2]);
8704 }
8705}
8706
8707The first random run of this model ran fine until step 536:
8708
8709
387 - CXCIV -
388
389 - CXCV -
390
8711The problem was not immediately obvious, but required some study to discern.
8712Observe that in step 543, data is sent from the C12.22 Device 0 (ED0 on the
8713far right) to the Comm Module with address 1 (CM1, far left). Just after
8714that, device 2 (CM2, second vertical line from left) sends a request to device
87151 via device 0 (step 547). Third, device 3 (CM3, second vertical line from
8716right) also sends a request to device 1 via device 0 (step 552). The original
8717rules did not take into account the fact that a data packet had already been
8718sent to device 1. The result is that the C12.22 Device 0 (ED0 on the far
8719right) is awaiting an ACK back from device 1 (CM1), and hence has that port
8720marked as “busy” but it also has further data to send from device 3. If it
8721sends the data, the result would be that both CM1 and ED0 would be waiting for
8722an ACK from the other end – an illegal state.
391 - CXCVI -
392
8723We can solve this problem by changing the model slightly. If we add the
8724condition that if the destination port is busy, we send a NAK to the source
8725port. Only the ED process is changed, so only that source code for the model
8726is shown:
8727
8728proctype ED(chan cm1, cm2, opt) /* end device */
8729{
8730 mtype type;
8731 byte dest;
8732 bool cm1busy, cm2busy, optbusy;
8733
8734 do
8735 :: cm1?ack(dest) ->
8737 :: cm1?nak(dest);
8738 /* for model, assume this is last NAK and give up */
8740 if
8741 :: (dest == 0) -> /* it is for me */
8742 cm1!ack,0;
8743 :: (dest == 1) -> /* for port 1 */
8744 if
8745 :: cm1busy ->
8746 cm1!nak,0;
8747 :: else
8748 cm1!ack,0;
8749 cm1!data,1;
8751 fi;
8752 :: (dest == 2) -> /* for port 2 */
8753 if
8754 :: cm2busy ->
8755 cm1!nak,0;
8756 :: else
8757 cm1!ack,0;
8758 cm2!data,1;
8760 fi;
8761 :: (dest == 3) -> /* for port 3 */
8762 if
8763 :: optbusy ->
8764 cm1!nak,0;
8765 :: else
8766 cm1!ack,0;
8767 opt!data,1;
8769 fi;
8771 fi;
8772... and so on for the other ports
8773
8774The resulting trace for this model looks like this:
393 - CXCVII -
394
8775
8776As we can see, while this works, there are a number of retries that can occur
8777in the situation we were trying to address. In real devices, the retries
8778would typically come right after the failed attempt – potentially before the
8779port clears (i.e. before the busy device sends the ACK). For that reason, a
8780better strategy is to buy some time by simply silently dropping the packet.
8781Using this method, the device that sends the second packet must wait until the
8782retry timeout expires, which is likely to have been enough time for the busy
8783device to have cleared. That code is here:
8784
8786 if
8787 :: (dest == 0) -> /* it is for me */
8788 cm1!ack,0;
8789 :: (dest == 1) -> /* for port 1 */
8790 if
8791 :: cm1busy ->
8792 skip; /* silently drop */
8793 :: else
8794 cm1!ack,0;
8795 cm1!data,1;
8797 fi;
8798...etc.
8799
8800SPIN also allows us to do far more than just running a model with sample data.
8801The point to using SPIN, is validation of the protocol. We want to make sure
8802that the protocol always works, under all circumstances. For example, in the
395 - CXCVIII -
396
8803absence of any channel errors, we would like to make sure that whenever the
8804Comm Module (CM) receives an ACK, it is in response to a packet that was
8805actually sent. In other words, we'd like to assure that we aren't getting
8806spurious ACKs due to a flaw in the protocol definition. Conversely, we also
8807want to make sure that whenever we send a data packet, that we aren't already
8808busy (i.e. awaiting an ACK for the last data packet sent.) We can check both
8809of those by adding asserts:
8810
8811
8812proctype CM(chan localport) /* communications module */
8813{
8814 mtype type; /* the message type */
8815 byte dest; /* the destination address in data packet */
8816 bool busy; /* the CM is awaiting an ACK */
8817 do
8818 :: localport?ack(dest) ->
8819 assert(busy);
8820 busy = false;
8821 :: localport?nak(dest)-> /* assume this is last NAK */
8822 busy = false;
8823 :: localport?data(dest) ->
8824 assert(!busy);
8825 localport!ack,dest; /* ACK this data */
8826...etc.
8827
8828
8829The result of running a verification run with these asserts shows us that, in
8830fact, the top assertion is violated. There is still something wrong with the
8831model, and possibly with the protocol itself. In order to assure a robust
8832protocol definition, we need to find out which it is and correct it. SPIN is
8833a useful tool which can help us do just that.
397 - CXCIX -
398
8834Annex N - Translator functionalities
8835
8836INFORMATIVE
8837
8838Sample Network Calculations
8839
8840These sample estimates and calculations are offered to assist an engineering
8841effort required to implement C12.22.
8842
8843Packet Size and Overhead
8844
8845This section describes the minimum and maximum packet sizes (layer 2) and the
8846ramifications of these numbers on any device which implements C12.22. The
8847minimum packet size is 64 bytes (section 7.9.1.2 Variable Settings). Although
8848this setting pertains solely to the interface between the Communications
8849Module and the end device, it is relevant to any implementation (i.e. even
8850those without a separate Communications Module) because the distant end might
8851have a Communications Module. The maximum receive size that can be negotiated
8852is 8192 bytes (rec-packet-size in 7.7.0.1 Negotiate Service) but the actual
8853maximum data size is 8183 (data size specified in 7.9.2 Packet Definition).
8854The difference is due to the packet overhead of 8 bytes, which is included in
8855the maximum receive size but excluded from the data size.
8856
8857Worst Case
8858
8859If data of size 8192 byte is transmitted to the distant end, it may be that at
8860some point (or several points) within the network, the data is sliced into 64-
8861byte packets. Because the packet overhead is 8 bytes, the number of packets
8862is 8192/(64-8) = 8192/56 = 146 full packets (64 bytes = 8 bytes overhead + 56
8863data bytes) and one with 24 bytes (8 bytes overhead + 16 data bytes). This
8864represent a worst-case overhead of 147*8/8192 = 14.3%. The total number of
8865bytes transmitted is 8192+147*8 = 9368.
8866
8867Timing Considerations Due to Data Link Packet Size
8868
8869Because this link starts at a minimum of 9600 bps (section 7.9.1.2 Variable
8870Settings) and we know that the link has a number of packets set to 1 (section
88717.9.1.2 Variable Settings) and we know that there are ten bits per byte, we
8872can use this data to find out the actual maximum data size that can be
8873delivered with a non-negotiated (i.e. all default) system.
8874The session timeout (6.3.2.3 Session Time Out) defaults to 30 seconds. A
8875minimum network of communicating devices would consist of two nodes and no
8876intermediaries. If we assume that only one node contains a Communications
8877Module, we can calculate how much data can be transmitted during that 30-
8878second interval.
8879
8880Full Packet End-to-end Timing Lower Bound
8881
8882At the data link layer, a full packet contains 56 data bytes with 8 bytes of
8883overhead as previously mentioned. Just counting communications times and
8884assuming zero latency, we can calculate the time it takes for one full packet
8885to get to the distant end.
8886Each 64 byte packet takes 64 bytes * 10 bytes per bit / 9600 bits per second =
888766.7 ms.
399 - CC -
400
8888Each correctly received packet also requires an ACK to be returned after an
8889(unspecified) turn around delay. We approximate the turn around delay as
8890zero, so the time for one successful packet is 66.7 ms + 1.04ms = 67.7 ms.
8891Assuming zero processing time, the Communications Module can forward its data
8892immediately.
8893We get a lower bound for the time if we additionally assume that network
8894transmission speed is infinite (i.e. it takes no time to send data).
8895In 30 seconds, then, we can send 30 sec * 960 bytes/sec = 28800 bytes. At 65
8896bytes per packet (64 bytes in a packet + 1 byte ACK), this is 443 full packets
8897and five bytes left over. These five leftover bytes cannot be sent, since
8898packet overhead is 8 bytes. At 56 data bytes per packet, this translates to
889924808 data bytes. Note that this is data link data bytes and not Application
8900Layer data bytes.
8901
8902Application Layer Mapping
8903
8904Analysis of the overhead of the Application Layer is a little less
8905straightforward. This is because there are a number of optional elements in
8906the <acse-pdu> (see 6.3.3. Association Control Service Element (ACSE)). For
8907this analysis, a minimal apdu is assumed to be as follows:
890860h <elements-length><called-aptitle-element><calling-aptitle-
8909element><calling-apinvocation-id-element><user-information-element>
8910
Element Size
60h 1
<elements-length> 3
<called-aptitle-element> 7
<calling-aptitle-element> 7
<calling-apinvocation-id-element> 7
<user-information-element> 4 + data size
8911
8912The sum of these is 29 bytes of overhead plus the size of the data, so the
8913maximum size of data would be 24808-31 = 24777 bytes which could take 30
8914seconds.
8915
401 - CCI -
402
8916Annex O - Translator functionalities
8917
8918INFORMATIVE
8919
8920Table Protocol: A Communication protocol, which is C12.19 aware and can
8921 read or write Table Variables, using the C12.19
8922 prescribed methods.
8923
8924Table Object: A table variable or group of variables that can be
8925 accessed using a single Read or Write request using the
8926 Table offset/count, index/count or full table access
8927 method.
8928
8929Native Protocol: A communication protocol, which may be cognizant or not
8930 designed for the transportation of C12.19 Tables.
8931
8932Native Object: A simple or composite data parcel that is requested by,
8933 or delivered to, a communication device that uses a
8934 Native protocol.
8935
8936Object Mapping: The identification, collation and translation of Table
8937 Objects to/from Native Objects.
8938
8939Table Column: A collection of related Table Objects which occupy the
8940 same index or offset of a multi-dimensional array or an
8941 array whose elements are made of records or bit-fields.
8942
8943Column Interleaved Mapping: The collation of Table Columns from different
8944 arrays into a single array whose elements are composed of
8945 the collated Tables Objects at the associated column
8946 indices.
8947
8948List Mapping: The act of extracting Table Objects from a list of
8949 objects, such as History Log, Event Log, Demand Profiles,
8950 etc. In such a manner that the collection of objects
8951 collated is governed by the list maintenance pointers and
8952 not the Table Object position in the list.
8953
8954Procedure Mapping: The act of mapping a method of the Native Protocol into a
8955 C12.19 procedure invocation.
8956
8957Object Name: A name or a tag, which when exposed realizes a Native
8958 Object in the Native Protocol.
8959
8960Objective
8961
8962Describe the methodology for dynamic and static identification and mapping of
8963Native Objects to and from Table Objects. The methodology is be defined using
8964terms, data structures and access methods, that are available in a C12.19
8965aware protocols. No assumption was made regarding the nature of the Native
8966Protocol. Therefore, there is no requirement for the translation being loss-
8967less.
8968
8969Recommendations:
8970
403 - CCII -
404
8971• Assume that all Native Protocols access methods can be mapped to simple
8972 Read (Get) or Write (Put) methods. Methods such as Execute, Create and
8973 Delete are not to be considered.
8974
8975• Data type conversions and scaling shall be performed implicitly where
8976 necessary.
8977
8978Proposed Minimum Translation Support Requirements:
8979
8980• Translate requests (methods): Put|Get.
8981
8982• Translate request parameters: Defined by the request.
8983
8984• Map object identifiers: Defined by the requested transaction.
8985
8986• Translate object formats: To/From Native Protocol.
8987
8988• Native Protocol side requests/responses have the following translation
8989 table entry: <method> <parameter>* <data-description>*
8990
8991• This shall lead to the definition of an Object Name.
8992
8993• Table Protocol side translation entries have the following fields:
8994 Method (read|write)
8995 Object Name
8996 Object Qualifier (derived from <parameters>)
8997 <table-object-descriptor>
8998where
8999
9000<table-object-descriptor> ::= <data-source>
9001 <table-instance>
9002 <table-ID>
9003 <table-variable-ID>
9004 [<object-mapping>]
9005
9006<object-mapping> ::= <direct-access> |
9007 <list-access> |
9008 <column> |
9009 <interleaved-column>
9010
9011• C12.22 does not define the translation table entries for the Native
9012 Protocol.
9013
405 - CCIII -
406
9014
9015Annex P – Objectives
9016
9017Sub-addressing, notification, test and supervisory control requirements
9018
9019
Description Supported Must be (1)
Must be
by the implemented understood
standard
Support of regular delivery Yes Yes Yes
Support of test messages Yes No Yes
Support of urgent message - jump Yes No No
the queue
Support of message with alarm Yes No No
attribute
Support of device attached to Yes No Yes
local ports addressing
Support of comm module interfaces Yes No Yes
addressing
9020
9021 1. The information must be recognized but its functionality doesn’t
9022 necessarily need to be implemented.
9023
9024
407 - CCIV -
408
409i UML reference

Protocol Specification For Interfacing To Data Communication Networks

Uploaded by

Copyright:

Available Formats

Protocol Specification For Interfacing To Data Communication Networks

Uploaded by

Document Information

Original Title

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

Protocol Specification For Interfacing To Data Communication Networks

Uploaded by

Copyright:

Available Formats

1

C12.22 C12.22 Other C12.22

C12.22 Network Segment

C12.22 C12.22 C12.22 C12.22

C12.22 Network Segment

C12.22 Network Segment

C12.19 Tables C12.19 Tables Other

(3) (5) (9)

C12.22 Network Segment C12.22 Network Segment or any LAN or WAN

Disconnect service, Link Session Read, Write, Wait, Security,

<user-information-element>::= 0xBE <app-data-length> <app-data> 751

<calling-apinvocation-id-element>::=0xA8 <seg-id-length> <segment-seq-number> [<segment-byte-offset> <apdu-size>]

0 0x60 0x8202EC 0 0x60 0x82015C

<tag> <content length>

300 bytes 0x0258 0x03E8

<user-information-element>::= 0xBE <app-data-length> <app-data>

<calling-apinvocation-id-element> ::=0xA8 <seg-id-length> <segment-seq-number> [<segment-byte-offset> <apdu-size>]

C12.22 device to C12.22 communication module interface(5) n (n >= 1) Any LAN/WAN/MAN

Negotiate < Packet size, Number of packets, Baud rate,

Link control > INTERFACE_CTRL = 1

[ Resolve ] > [Master relay ApTitle]

< Interface status, Node ApTitle

Link control > INTERFACE_CTRL = 2

[Deregister] > Node ApTitle

Link control > INTERFACE_CTRL = 0,

Send > Native address, ACSE pdu

Send > ACSE pdu

[ Resolve ] > ApTitle

Send message > ACSE pdu

< ACSE pdu

Send < Native address, ACSE pdu

Get Status < Status ctrl

Get Reg Status > None

- Link control - Link control

Any valid traffic

5 VPLUS C12.22 Comm. Module power supply Output Input

XOR XOR … XOR

Encrypt Encrypt Encrypt

Decrypt Decrypt Decrypt

XOR XOR … XOR

Actor A stick figure that represents one of the

Association A line connecting an Actor with a Use Case. All the

Plug And Play

3: InstalledNewC1222Device( endDeviceEID, commModuleEID )

16: RegistrationResponse( status, apTitle )

You might also like