Protocol Specification For Interfacing To Data Communication Networks

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. Permission is hereby
39 granted for ANSI Standards Committee participants to reproduce this document for purposes of ANSI
40 standardization activities. Use of information contained in this unapproved draft is at your own risk.
41
42
43
44
45
46
47
48 Modified April 22, 2019
49
50 Standard Version 0.0
51
52
53 Table of contents
54
551. Introduction.................................................................................................................................................... 6
562. Scope............................................................................................................................................................. 6
573. References..................................................................................................................................................... 7
58 3.1. Normative............................................................................................................................................. 7
59 3.2. Others................................................................................................................................................... 8
604. Definitions And Syntax................................................................................................................................... 8
61 4.1. Definitions............................................................................................................................................. 8
62 4.2. Document Syntax............................................................................................................................... 12
63 4.3. Table syntax........................................................................................................................................ 13
645. Reference Topology..................................................................................................................................... 13
656. C12.22 Node to C12.22 Network Segment Details......................................................................................15
66 6.1. C12.22 Node to C12.22 Network Segment Reference.......................................................................15
67 6.2. Data order........................................................................................................................................... 15
68 6.3. Layer 7 - Application Layer................................................................................................................. 17
69 6.3.1. Data Structure - Utility Industry Data Tables...................................................................................17
70 6.3.2. Protocol Specification For Electric Metering (PSEM).....................................................................17
71 6.3.2.1. Request Codes......................................................................................................................... 17
72 6.3.2.2. Response Codes...................................................................................................................... 18
73 6.3.2.3. Time-out................................................................................................................................... 20
74 6.3.2.3.1. Session Time-out............................................................................................................... 20
75 6.3.2.3.2. Application Layer Response Time-out...............................................................................21
76 6.3.2.4. Services.................................................................................................................................... 22
77 6.3.2.4.1. Identification Service......................................................................................................... 22
78 6.3.2.4.2. Read Service..................................................................................................................... 24
79 6.3.2.4.3. Write Service..................................................................................................................... 26
80 6.3.2.4.4. Logon Service.................................................................................................................... 27
81 6.3.2.4.5. Security Service................................................................................................................ 28
82 6.3.2.4.6. Logoff Service.................................................................................................................... 28
83 6.3.2.4.7. Terminate Service.............................................................................................................. 29
84 6.3.2.4.8. Disconnect Service............................................................................................................ 30
85 6.3.2.4.9. Wait Service...................................................................................................................... 30
86 6.3.2.4.10. Registration Service........................................................................................................ 31
87 6.3.2.4.11. Deregistration Service...................................................................................................... 34
88 6.3.2.4.12. Resolve Service............................................................................................................... 35
89 6.3.2.4.13. Trace Service................................................................................................................... 35
90 6.3.2.5. Service sequence state control................................................................................................ 36
91 6.3.2.6. Partial Table access using index/element-count Method..........................................................38
92 6.3.2.7. Partial Table access using offset/octet-count method...............................................................40
93 6.3.3. Extended PSEM (EPSEM).............................................................................................................. 41
94 6.3.4. Association Control – Association Control Service Element (ACSE)..............................................42
95 6.3.4.1. Application Context Element (A1H)........................................................................................... 42
96 6.3.4.2. Called AP Title Element (A2H).................................................................................................. 43
97 6.3.4.3. Calling AP Title Element (A6H).................................................................................................. 43
98 6.3.4.4. Universal Identifier (06H).......................................................................................................... 43
99 6.3.4.5. Relative Universal Identifier (0DH)............................................................................................ 43
100 6.3.4.6. Calling Application Entity Qualifier Element (A7 H)...................................................................44
101 6.3.4.7. Mechanism Name Element (AB H)............................................................................................ 45
102 6.3.4.8. Authentication Value Element (ACH)......................................................................................... 45
103 6.3.4.8.1. C12.22 Security Mechanism (1.2.840.10066.2.1).............................................................46
104 6.3.4.8.2. C12.21 Security Mechanism (1.2.840.10066.2.0).............................................................47
105 6.3.4.9. Called Invocation ID Elements (A4H)........................................................................................ 48
106 6.3.4.10. Calling Invocation ID Elements (A8 H).....................................................................................49
107 6.3.4.11. Application Data Element (BE H).............................................................................................. 49
1 - II -
2
108 6.3.4.12. Length Fields Encoding.......................................................................................................... 50
109 6.3.4.13. Universal Identifiers Encoding................................................................................................ 50
110 6.3.4.14. Use of Sub-Branches of a Registered ApTitle........................................................................52
111 6.3.4.15. C12.22 Security Mechanism................................................................................................... 54
112 6.3.4.15.1. C12.22 Security Mechanism (1.2.840.10066.2.1)...........................................................54
113 6.3.4.15.2. C12.21 Security Mechanism (1.2.840.10066.2.0)...........................................................58
114 6.3.5. Application Segmentation Sub-Layer.............................................................................................. 59
115 6.3.5.1. APDU Segmentation................................................................................................................ 59
116 6.3.5.2. APDU Segment........................................................................................................................ 59
117 6.4.0.2.1 Segment Calling Invocation ID Elements (A8H).................................................................59
118 6.3.5.2.1. Segment Application Data Element (BE H).........................................................................60
119 6.3.5.3. The Segmentation and Reassembly......................................................................................... 61
120 6.3.5.3.1. The Segmentation Algorithm............................................................................................. 61
121 6.3.5.3.2. The Reassembly Algorithm................................................................................................ 62
122 6.4. Layer 6 - Presentation Layer............................................................................................................... 63
123 6.5. Layer 5 - Session Layer...................................................................................................................... 63
124 6.6. Layer 4 - Transport Layer.................................................................................................................... 64
125 6.7. Layer 3 - Network Layer...................................................................................................................... 64
126 6.8. Layer 2 - Data link Layer..................................................................................................................... 64
127 6.9. Layer 1 - Physical Layer..................................................................................................................... 64
1287. Protocol Details: C12.22 Device to C12.22 Communication Module Interface............................................65
129 7.1. Interface Architecture.......................................................................................................................... 65
130 7.2. Interface Diagram............................................................................................................................... 65
131 7.3. Implementation Guidelines................................................................................................................. 66
132 7.4. Layer 7 - Application Layer................................................................................................................. 67
133 7.5. Layer 6 - Presentation Layer............................................................................................................... 67
134 7.6. Layer 5 - Session Layer...................................................................................................................... 67
135 7.7. Layer 4 - Transport Layer.................................................................................................................... 67
136 7.7.1. Negotiate Service........................................................................................................................... 68
137 7.7.2. Get Configuration Service.............................................................................................................. 69
138 7.7.3. Link Control Service........................................................................................................................ 72
139 7.7.4. Send Message Service................................................................................................................... 73
140 7.7.5. Get Status Service.......................................................................................................................... 74
141 7.7.6. Get Registration Status Service...................................................................................................... 75
142 7.7.7. Service Time Sequence Diagrams.................................................................................................. 77
143 7.7.8. Service Sequence States................................................................................................................ 81
144 7.8. Layer 3 - Network Layer...................................................................................................................... 82
145 7.9. Layer 2 - Data Link Layer................................................................................................................... 82
146 7.9.1. Basic Data Information................................................................................................................... 83
147 7.9.1.1. Fixed Settings........................................................................................................................... 83
148 7.9.1.2. Variable Settings....................................................................................................................... 83
149 7.9.2. Packet Definition............................................................................................................................. 83
150 7.9.3. CRC Selection................................................................................................................................ 85
151 7.9.4. Acknowledgment............................................................................................................................. 85
152 7.9.5. Retry Attempts................................................................................................................................ 85
153 7.9.6. Timeouts......................................................................................................................................... 86
154 7.9.6.1. Traffic Time-out......................................................................................................................... 86
155 7.9.6.2. Inter-character Time-out........................................................................................................... 86
156 7.9.6.3. Response Time-out................................................................................................................... 86
157 7.9.7. Turn Around Delay.......................................................................................................................... 86
158 7.9.8. Duplicate Packets........................................................................................................................... 86
159 7.9.9. Transparency................................................................................................................................... 86
160 7.9.10. Supervision of the Communications Link......................................................................................86
161 7.9.11. Local Routing................................................................................................................................ 87
162 7.9.12. Service Sequence States.............................................................................................................. 88
163 7.10. Layer 1 - Physical Layer................................................................................................................... 89
164 7.10.1. Signal Definition............................................................................................................................ 89
3 - III -
4
165 7.10.2. Electrical Properties of Connection............................................................................................... 89
166 7.10.3. Mechanical and Environmental Properties...................................................................................89
167 7.10.4. Supervision of the Communications Link......................................................................................90
1688. Local Port Communication Protocol Details................................................................................................. 91
169 8.1. Protocol Definition............................................................................................................................. 91
170 8.1.1. Layer 7 - Application Layer............................................................................................................. 91
171 8.1.2. Layer 6 - Presentation Layer........................................................................................................... 91
172 8.1.3. Layer 5 - Session Layer.................................................................................................................. 91
173 8.1.4. Layer 4 - Transport Layer................................................................................................................ 91
174 8.1.5. Layer 3 - Network Layer.................................................................................................................. 92
175 8.1.6. Layer 2 - Data Link Layer................................................................................................................ 92
176 8.1.7. Layer 1 - Physical Layer................................................................................................................. 92
177 8.2. C12.22 Local Port Communication Using a C12.18 Optical Port.......................................................92
178 8.2.1. Establishment of ANSI C12.18 Protocol Compatibility Mode..........................................................93
179 8.2.2. Establishment of ANSI C12.22 Protocol Compatibility Mode..........................................................93
1809. Backward Compatibility................................................................................................................................ 94
181ANNEX A - Relays............................................................................................................................................ 95
182 A.1 Hierarchical Topology.......................................................................................................................... 95
183 A.2 C12.22 Master Relays......................................................................................................................... 95
184 A.3 Registration Notification...................................................................................................................... 96
185 A.4 Registration Algorithm Details............................................................................................................. 96
186 A.5 C12.22 Node ApTitle Auto-assignment................................................................................................ 96
187 A.6 C12.22 Master Relay ApTitle Auto-assignment...................................................................................97
188 A.7 Obsolete Routes.................................................................................................................................. 97
189 A.8 Multiple Routes.................................................................................................................................... 97
190 A.9 Application Layer Supervision............................................................................................................. 97
191 A.10 Routing.............................................................................................................................................. 97
192ANNEX B - Routing Examples......................................................................................................................... 99
193 B.1 C12.22 Relays With a Single Service Provider...................................................................................99
194 B.2 C12.22 Relays Shared by Multiple Service Providers.........................................................................99
195ANNEX C - Modifications And Extensions to C12.19- 1997...........................................................................101
196 ANNEX C1 - DECADE 12: Node network Control Tables........................................................................102
197 TABLE 120 Dimension Network Table..................................................................................................... 102
198 TABLE 121 Actual Network Table............................................................................................................ 105
199 TABLE 122 Interface Control Table......................................................................................................... 107
200 TABLE 123 Exception Report Table........................................................................................................ 109
201 TABLE 124 Filtering Rules Table............................................................................................................. 111
202 TABLE 125 Interface Status Table........................................................................................................... 113
203 TABLE 126 Registration Status Table...................................................................................................... 116
204 TABLE 127 Network Statistics Table....................................................................................................... 118
205 ANNEX C2 - DECADE 130 - Relay Control Tables..................................................................................120
206 TABLE 130 Dimension Relay Table........................................................................................................ 120
207 TABLE 131 Actual Relay Rable............................................................................................................... 122
208 TABLE 132 Registration List Table.......................................................................................................... 123
209 TABLE 133 Static Routing Table............................................................................................................. 126
210 TABLE 134 Host Notification Table......................................................................................................... 128
211 TABLE 135 Master Relay Assignment Table........................................................................................... 130
212 TABLE 136 Dynamic Routing Report Table............................................................................................ 131
213 ANNEX C3 - Universal ID Pattern Description of ApTitles.......................................................................132
214 ANNEX C4 - Additions to TABLE 07 - Procedure Initiate Table...............................................................133
215 PROCEDURE 23 Register...................................................................................................................... 133
216 PROCEDURE 24 Deregister................................................................................................................... 133
217 PROCEDURE 25 Network Interface Control.......................................................................................... 134
218 PROCEDURE 26 Exception Report........................................................................................................ 135
219 ANNEX C5 - Table 46: Key table)............................................................................................................ 136
220ANNEX D - Universal Identifier...................................................................................................................... 137
221ANNEX E - One-way Devices........................................................................................................................ 139
5 - IV -
6
222ANNEX F - APDU Response Timeout Algorithm............................................................................................ 141
223ANNEX G - Communication Example............................................................................................................ 143
224ANNEX H - ANSI C12.22 Application Layer Over TCP/IP (UNIX Implementation)........................................144
225ANNEX I - CRC Examples............................................................................................................................. 146
226 I.1 Trace................................................................................................................................................... 146
227 I.2 C Code Example................................................................................................................................ 147
228ANNEX J – DES/CDC and DESede/CDC...................................................................................................... 148
229 J.1 Data Encryption Standard - DES....................................................................................................... 148
230 J.2 DESede.............................................................................................................................................. 148
231 J.3 CBC................................................................................................................................................... 148
232 J.4 Legal Issues....................................................................................................................................... 149
233 J.5 DES Implementation.......................................................................................................................... 149
234 J.6 DES Code Example........................................................................................................................... 153
235 J.7 DES Trace Example........................................................................................................................... 156
236 J.8 CBC Code Example........................................................................................................................... 157
237 J.9 CBC Trace Example.......................................................................................................................... 159
238
7 -V-
8
239
2401 Introduction
241Initially, communications with electronic metering devices consisted of transporting memory data via
242proprietary protocols which were unique to each manufacturer. The desire for interoperability and support
243for multiple manufacturers by reading and programming systems created a need for standardization of
244data formats and transport protocols.
245
246The first step was to standardize data formats. Internal data was abstracted as a set of Tables. A set of
247standard Table contents and formats were defined in the “Utility Industry End Device Data Tables” (ANSI
248C12.19).
249
250In the ”Protocol Specification for ANSI Type 2 Optical Port” (ANSI C12.18) Standard, a point-to-point
251protocol was developed to transport table data over an optical connection. This protocol included an
252application language called Protocol Specification for Electric Metering (PSEM) that allowed applications
253to read and write Tables. ANSI C12.21 was then developed to allow metering devices to use PSEM to
254transport Tables over telephone modems.
255
256This Standard extends the ANSI C12.18, ANSI C12.19 and the “Protocol Specification for Telephone
257Modem Communication” (ANSI C12.21) standards to allow transport of Table data over any networking
258communications system.
259
260In addition, this Standard describes an optionally exposed point-to-point interface between a C12.22
261Device, e.g. a meter, and, a C12.22 Communications module, e.g. a network adaptor, designed to attach
262to “any” network.
263
2642 Scope
265This document defines interfaces between ANSI C12.19 devices and network protocols.
266
267Specific goals identified by this committee were:
268
2691. Defining a Datagram that may convey ANSI C12.19 data Tables through any network.
270
271 This was accomplished by:
272  Assuming that the data source is ANSI C12.19 data Tables.
273  Defining the Application Layer services (language).
274  Defining the interface lower layers; layers; 4 (Transport), 3 (Network), 2 (Data Link) and 1
275 (Physical).
276
2772. Providing a full stack definition for interfacing an end device to a “Network Communication Module”.
278
280  Defining the physical interface requirements between the end device and the “Network
281 Communication Module”.
282  Defining the interface lower layers; 4 (network), 3 (transport), 2 (data link) and 1 (physical).
283
2843. Providing a full stack definition for point-to-point communication to
285 be used over local ports such as optical ports, or modems.
286
287 This was accomplished by defining a Layer 4 (Transport Layer) and Layer 2 (Data Link Layer).
288
2894. Providing support for efficient one-way messaging (blurts)
290
292  Defining a compact message format that can be easily transformed to a standard ANSI C12.22
293 Datagram.
9 - VI -
10
294  Assuring that all needed layers defined in this Standard can support one-way messaging
295
2965. Providing network architecture compatible with this protocol.
297
299  Defining different type of nodes such as C12.22 Relay, C12.22 Master Relay, C12.22 Host,
300 C12.22 Authentication Host, C12.22 Notification Host, C12.22 Gateway.
301  Defining the role and responsibilities of each of these C12.22 Nodes.
302
3036. Providing data structure definitions in support of this protocol.
304
306  Defining an ANSI C12.19 Decade to be used by C12.22 Nodes.
307  Defining an ANSI C12.19 Decade to be used by C12.22 Relays.
308  Defining new procedures in support of this protocol.
309  Defining a new table for enhanced security.
310
3113 References
312
313(Review this section just before publication to adjust dates)
314
3154 Normative
316ANSI C12.18-1996 Protocol Specification for ANSI Type 2 Optical Port.
317
318ANSI C12.19-1997 Utility Industry End Device Data Tables.
319
320ANSI C12.21-1999 Protocol Specification for Telephone Modem Communication.
321
322ISO/IEC 7498-1 Information Technology – Open Systems Interconnection – Basic Reference
323 Model: The Basic Model
324
325ISO 3309-1993(E) Information Technology - Telecommunications and information exchange
326 between systems - High-level data link control (HDLC) procedures - Frame
327 Structure, Annex A Explanatory Notes On Implementation of the Frame
328 Checking Sequence
329
330ANSI INCITS 92 Data Encryption Algorithm
331
332ISO/IEC 8824-1-1997 Information technology – Abstract Syntax Notation One (ASN.1):
333 Specification of basic notation
334
335ISO/IEC 8824-2-1997 Information technology - Abstract Syntax Notation One (ASN.1): Information
336 Object Specification
337
338ISO/IEC 8824-3-1997 Information technology - Abstract Syntax Notation One (ASN.1): Constraint
339 specification
340
341ISO/IEC 8824-4-1997 Information technology – Abstract Syntax Notation One (ASN.1):
342 Parameterization of ASN.1 specifications
343
344ISO/IEC 8825-1-1997 Information technology – ASN.1 encoding rules: Specification of Basic
345 Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
346 Encoding Rules (DER)
347
348ISO/IEC 8650 ACSE
11 - VII -
12
349
350ISO/IEC 10035-1 ?
351
352ISO/IEC 646: 1991 ASCII character set
353
354ATIS T1.667-1999 ATIS T1.667-2002 Intelligent Network (Revision of T1.667-1999): May 2002.
3555 Others
356(Add Dictionary reference)
357
3586 Definitions And Syntax
3597 Definitions
360For the purposes of this Standard, the following definitions and terms are used.
361
362Absolute UID: Absolute encoding of a UID according to “Encoding of an object identifier
363 value” clause in ISO/IEC 10035-1.
364ACSE: Association Control Service Element encoded per “Connectionless protocol
365 for the association control service element: Protocol specification”, ISO/IEC
366 10035-1. Connectionless ACSE defines the Datagram encapsulation
367 protocol used in this Standard.
368
369APDU Segment: An Application Protocol Data Unit that is constructed using C12.22
370 Segmentation as the process of breaking a C12.22 Datagram into smaller
371 units before transmission, see “C12.22 Datagram Segmentation and
372 Reassembly”.
373
374Application Association: See “Association”.
375
376Application Context: A set of service elements and supporting information used on the Application
377 Association. It includes a description of the relationships and dependencies
378 of the C12.22 Application service elements, and a description of the logical
379 structure of information to be exchanged between co-operating Application
380 Entities.
381
382Application Entity: The system-independent application activities that are made available as
383 application services to the application agent; e.g., a set of application
384 service elements that together perform all or part of the communication
385 aspects of an application process. [ATIS T1.667-1999].
386
387Application Entity Title: ISO 7498-3, describes an application-entity title that is composed of an
388 application-process title and an application-entity qualifier. The ACSE
389 protocol provides for the transfer of application-entity title values. The
390 Network Layer provides binding between Application Entity Titles (ApTitle)
391 and Network Entity Titles.
392
393Application Process: See “Application Entity”.
394
395Application Protocol Data Unit (APDU): The Application Protocol Data Unit (APDU) is a Datagram that is
396 transferred error-free between network nodes. The C12.22 standard encodes
397 APDUs using ACSE to carry EPSEM services and C12.19 payloads between
398 C12.22 Nodes.
399
400ApTitle: In addition to the addressing constructs (transport address and possibly
401 session and presentation selectors), the communicating application entities
402 have names - application-entity titles (AeTitle). These are carried by ACSE
403 as two fields - the Application-process titles (ApTitle) and the application-
13 - VIII -
14
404 entity qualifier (AeQualifier). The AeTitle is compound, and the ApTitle
405 consists of all but the last element, which is the AeQualifier.
406
407 C12.22 ApTitles may be encoded absolutely using the <universal-id-
408 element> or relatively using the <relative-uid-element>. Relative UIDs shall
409 be unique only within the context of an ANSI C12.22 Network, C12.22
410 Network Segment or inside C12.22 Nodes. C12.22 Relays, C12.22
411 Communication Modules or C12.22 Transport Layers shall map Relative
412 UIDs to other Relative UIDs or Absolute UIDs to ensure the uniqueness of
413 the ApTitle within the context of any network, a C12.22 Network or a C12.22
414 Network Segment as needed.
415
416Association: A cooperative relationship among peer (utilizing the same protocol)
417 Application Entities which enables the communication of information and the
418 coordination of their joint operation for an instance of communication. This
419 relationship may be formed by the transfer of application protocol control
420 information during the establishment of a connection, or transitionally, during
421 a single invocation through a connectionless service. Associations can also
422 be predefined and longstanding.
423 This Standard provides for Application Entities that communicate
424 interactively using connectionless communication, and it provides for state
425 information that is shared between them for the duration of the
426 communication.
427
428Bit: A Binary Digit. The unit of information of a computational quantity that can
429 take on one of two values, such as false and true or 0 and 1. A bit is said to
430 be "set" if its value is true or 1, and "reset" or "clear" if its value is false or 0.
431 One speaks of setting and clearing bits. To toggle or "invert" a bit is to
432 change it, either from 0 to 1 or from 1 to 0. (Reference: Computing
433 Dictionary).
434
435BER: Basic Encoding Rules as defined by ISO/IEC 8825-1, describing methods
436 used to identify and encode data elements for transport.
437
438Byte: A group of 8 bits of data. When expressed in this Standard, bit 0 is the least
439 significant bit and it is written at the right-most position of a bit sequence. Bit
440 7 is the most signification bit and it is written at the left-most position of the
441 bit sequence. The actual bit-signal transmission sequence and bit polarity,
442 which represents ones or zeroes, is determined by the characteristics of the
443 appropriate OSI Physical Layer used to transmit the byte.
444
445Calling ApTitle: The Calling ApTitle is encoded as an Absolute UID or Relative UID. It
446 uniquely identifies the initiator of an ACSE C12.22 Message.
447
448Called ApTitle: The Called ApTitle is encoded as an Absolute UID or Relative UID. It
449 uniquely identifies the target of an ACSE C12.22 Message.
450
451C12.19 Device Class: A Relative UID that uniquely identifies a C12.19 Device Table set per the
452 MANUFACTURER field defined in Table 0 of ANSI C12.19-1997 or the
453 DEVICE_CLASS field defined by version 2 of ANSI C12.19.
454
455C12.22 Application: An Application Entity that implements a set of services and procedures as
456 defined in this Standard permitting one or more well-defined devices
457 (C12.22 Host, C12.22 Relay, C12.22 Device, C12.22 Communication
458 Module, etc.) to interact within the framework of a C12.22 Network. It may
459 also contain C12.19 Tables.
460
15 - IX -
16
461C12.22 Authentication Host: A C12.22 Host that is an authoritative administrative host for a registering
462 C12.22 Node in the C12.22 Master Relay domain. The C12.22
463 Authentication Host may be embedded inside a C12.22 Master Relay or it
464 may be a separate C12.22 Node on the network. There may be one or more
465 C12.22 Authentication Hosts operating under the domain of a single C12.22
466 Master Relay. Registration with C12.22 Master Relays can only succeed if at
467 least one C12.22 Authentication Host accepts registration on behalf of a
468 C12.22 Node by a C12.22 Master Relay. (MOVE TO APPROPRIATE
469 SECTION)
470
471C12.22 Client: A C12.22 Node which initiates a Logon service request for the purpose of
472 establishing a session with a C12.22 Server.
473
474C12.22 Communication Module: Hardware module that attaches a C12.22 Device to a C12.22
475 Network Segment. A C12.22 Communication Module can be physically
476 located inside or outside the C12.22 Device enclosure. However, it is
477 physically and logically distinct from the C12.22 Device. The interface
478 between the C12.22 Communication Module and the C12.22 Device is
479 completely defined by this Standard. The combination of a C12.22 Device
480 and a C12.22 Communication module constitutes a C12.22 Node. If a
481 C12.22 Communication Module contain Tables, it is also a C12.22 Node.
482
483C12.22 Device: A module that hosts C12.22 Application(s) and provides at least one
484 Interface to a C12.22 Communication Module.
485
486C12.22 Gateway: A C12.22 Node that translates the ANSI Standard C12.22 protocol to/from
487 other protocols. Gateways are required when a C12.22 Node needs to
488 communicate with non-C12.22 Nodes. C12.22 Gateways can be attached
489 directly to the non-C12.22 Devices or they can provide their translation
490 services through any network segment.
491
492C12.22 Host: A C12.22 Node that may be a C12.22 Authentication Host or C12.22
493 Notification Host or both. A Host typically runs on a computer instead of
494 within an embedded system (e.g. a meter).
495
496C12.22 Master Relay: A C12.22 Relay that operates at the top of a hierarchy of relays. It provides
497 registration services of all devices in its domain. It is also responsible for
498 issuing registration service queries to C12.22 Authentication Hosts and
499 Deregistration service requests and notifications to C12.22 Notification Hosts
500 when registering a C12.22 Node. A C12.22 Master Relay can also act as a
501 C12.22 Host.
502
503C12.22 Message: Any notice, service request, service response or device status sent from one
504 C12.22 Node to another C12.22 Node for the purpose of communication
505 across a C12.22 Network. The detailed encoding of C12.22 Messages is
506 defined by the appropriate encoding rules of the OSI Layer from which they
507 are issued.
508
509C12.22 Network: A C12.22 communication infrastructure that is composed of C12.22 Network
510 Segments interconnected using C12.22 Relays. A C12.22 Network shall
511 include at least one C12.22 Master Relay.
512
513C12.22 Network Segment: A collection of C12.22 Nodes that can communicate with each other without
514 forwarding messages through a C12.22 Relay. A C12.22 Network Segment
515 may be either a LAN (Local Area Network) or a WAN (Wide Area Network)
516 and may include bridges or routers.
517
17 -X-
18
518C12.22 Node: A point on the network that attaches to a C12.22 Network Segment. C12.22
519 Nodes contain one or more C12.22 Applications. Each C12.22 Node shall
520 have a unique ApTitle on a C12.22 Network.
521
522C12.22 Notification Host: A C12.22 Host, which contains an application that needs to be notified when
523 C12.22 Nodes are registered for the first time or deregistered. Each C12.22
524 Notification Host may add the registered C12.22 Node to its active client list
525 for subsequent processing by the C12.22 Host application.
526
527C12.22 Relay: A C12.22 Node that provides address resolution, Datagram segmentation
528 and optionally message forwarding services to other C12.22 Nodes. Address
529 resolution services consist of mapping Layer 7 addresses (ApTitle) to lower
530 layer addresses (Network Entity Title).
531
532C12.22 Datagram Segmentation and Reassembly: The process of breaking a C12.22 Datagram into
533 smaller units before transmission and then reassembling it into the proper
534 order at the receiving C12.22 Node. C12.22 Datagrams are made smaller
535 specifically because of specified packet size restrictions in a given path
536 across a channel. The transport protocol determines the size of the smallest
537 maximum Protocol Data Unit (PDU) supported by the underlying C12.22
538 Network Segment for the purpose of transmission to the target C12.22 Node.
539
540C12.22 Server: A C12.22 Node that is a recipient of a Logon service request from a C12.22
541 Client for the purpose of establishing a session with that client.
542
543Channel: A single path for transmitting signals, usually in distinction from other parallel
544 paths. Multiple channels may coexist on the same physical media.
545 The term channel may signify either a one-way path, providing transmission
546 in one direction only, or a two-way path, providing transmission in two
547 directions.
548
549Connection: A logical and physical binding between two or more users of a service.
550
551Datagram: A self-contained, independent entity of application data carrying sufficient
552 information to be routed from the source Application Layer to the destination
553 Application Layer. This Standard encapsulates each Datagram as one or
554 more ACSE PDUs.
555
556EPSEM: Extended PSEM; Extended structures and services enabling transportation
557 of multiple requests and responses at the same time. There are also
558 provisions for response control and end device class. EPSEM messages are
559 encapsulated within ACSE PDUs.
560
561Fragment: See “APDU Segment”.
562
563Interface: The C12.22 Device hardware components used to manifest a C12.22 Node
564 on a C12.22 Network Segment.
565
566Local Port: A physical interface that is directly attached to the C12.22 Node; or, a
567 physical interface that is located in the immediate vicinity of the C12.22
568 Node and attached to it by means of a dedicated short signal path (e.g.
569 cable). The main purpose of the Local Port is to provide direct access to the
570 application process of the C12.22 Node. The C12.22 Node application
571 process may redirect C12.22 Messages that originate from a Local Port to
572 other Local Ports or other C12.22 Node interfaces. Similarly, the C12.22
573 Node application process may redirect incoming C12.22 Messages to Local
574 Ports. The C12.22 Communication Module interface of a C12.22 Device is
19 - XI -
20
575 not a Local Port. All Local Ports of a C12.22 Node shall access to the same
576 C12.22 Application. The physical Local Port characteristics (OSI Layer 1) are
577 not defined by this Standard; however, the Data Link through Application
578 Layers (Layers 2-7) is fully defined by this Standard.
579
580Network Entity Titles: ?
581
582Other Device: Devices that do not implement the ANSI C12.22 protocol.
583
584PSEM: Protocol Specification for Electric Metering Application language as
585 originally defined by ANSI C12.18-1996 and extended by ANSI standard
586 C12.21 and in this Standard.
587
588Relative UID: Relative encoding of a UID according to “Encoding of a relative object
589 identifier value” in ISO/IEC 10035-1. The Relative UID is a subset of an
590 Absolute UID, e.g. the absolute object identifier 2.100.3.8571.3.2 contains
591 the relative object identifiers 8571.3.2.
592
593Reliable Transfer: To be defined
594
595Segment: In the context of a C12.22 Network, a C12.22 Network Segment. In the
596 context of a C12.22 APDU, an APDU Segment.
597
598Segmentation: See “C12.22 Datagram Segmentation and Reassembly”.
599
600Session: A connection maintained while the two C12.22 Nodes are communicating
601 back and forth in a conversation of some duration. Managing a session
602 includes setting up and taking down the connection between two
603 communicating C12.22 Nodes. Some connections and sessions last only
604 long enough to send a message in one direction. However, other sessions
605 may last longer, usually with one or both of the communicating parties able
606 to terminate it.
607
608Transaction: A unit of interaction that occurs individually and coherently.
609
610UID: Universal Identifiers (UIDs) are universally unique identifiers that are
611 encoded using BER. A UID may be formulated as an Absolute UID or a
612 Relative UID and can be used to specify C12.22 object identifiers such as
613 Calling ApTitle, Called ApTitle.
614
6158 Document Syntax
616Document syntax is identical to that described in ANSI C12.18.
617
618Describing data definitions is usually accomplished within the confines of a given language and the
619grammar rules of that language. Since the data definitions embodied within this document are meant to
620be independent of specific language and, hopefully, capable of being implemented within the confines of
621any language, a method for describing the data definitions must be developed. A modified form of the
622Backus-Naur Form (BNF) serves as the basis for building the descriptions used to construct the data
623definitions.
624
625The modified form of BNF has the following definitions:
626
627Symbol Meaning
628
629< > A string contained inside angle brackets is called a non-terminal. That is, while it may be viewed
630 as a single unit it can and should be redefined as consisting of one or more simpler elements.
21 - XII -
22
631
632::= This symbol is read as “is defined as.” The non-terminal which occurs on the left hand side
633 (LHS) of this symbol consists of the elements (non-terminals, terminals, or a combination of the
634 two) found on the right hand side (RHS). A line containing an LHS, ::=, and an RHS is known as
635 a production rule.
636
637| The vertical bar is an “OR” symbol. The OR symbol always occurs on the right hand side of a
638 production where the left hand side can be defined in more than one way. The OR bar separates
639 valid alternative right hand sides.
640
641[ ] A symbol enclosed in square brackets is optional. The production is valid whether or not it is
642 included.
643
644* The superscript asterisk is known as the Kleene star. A symbol followed by the Kleene star may
645 occur zero or more times without violating the grammar.
646
647+ The superscript plus sign is known as the Kleene cross. A symbol followed by the Kleene cross
648 must occur one or more times.
649
650+n A symbol followed by the Kleene cross and any superscript number “n” represents “n”
651 occurrences of the symbol.
652
653{ } The curly braces are used to enclose comments within the descriptions. Comments have no
654 impact on the productions.
655
6569 Table syntax
657Table document form syntax is identical to that described in ANSI C12.19.
658
65910 Reference Topology
660
661Figure 5.1 describes the C12.22 Network and protocol topology within which C12.22 Nodes are expected
662to operate.
663
664This network topology accommodates interconnections among C12.22 Nodes that can be located on the
665same or on different networks. C12.22 Messages are forwarded between C12.22 Network Segments
666using C12.22 Relays.
667
668The network topology also accommodates C12.22 Gateways that translate the C12.22 protocol to other
669protocols. C12.22 Devices and non-C12.22 Devices may be collocated on the same C12.22 Network
670Segment and optionally provide C12.22 Gateway functionality.
671
672The interface between a C12.22 Device and C12.22 Communication Module(s) is fully defined in this
673Standard. However, the Standard general definition of the interface of a C12.22 Node to a C12.22
674Network Segment is limited to the Application, Presentation and Session Layers only (layers 7-5). The
675interface between a C12.22 Device and a C12.22 Communication Module (Layers 1-4) is shown in the
676Figure 5.1 using triple lines.
677
678This Standard defines components of a C12.22 Network. Each component is defined with enough
679flexibility to allow multiple components to be incorporated into one physical device.
680
681In the case that a C12.22 Node is connected to more than one C12.22 Network Segment,
682communication through those segments shall be to the same C12.22 Application(s). Access to the
683C12.22 Node through a Local Port shall also be to the same C12.22 Application(s).
684
23 - XIII -
24
685When a Local Port is attached to a C12.22 Device, this port provides access to the C12.22 Application(s)
686of this C12.22 Device and may optionally provide access to the attached C12.22 Communication
687Modules. Similarly, when a Local Port is attached to a C12.22 Communication Module, this port provides
688access to the C12.22 Application(s) of this C12.22 Communication Module and may optionally provide
689access to the attached C12.22 Device.
690
691
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
692
693 Figure 5.1: Reference topology
694
25 - XIV -
26
695
69611 C12.22 Node to C12.22 Network Segment Details
697
69812 C12.22 Node to C12.22 Network Segment Reference
699The following diagram shows a C12.22 Node that is attached to a C12.22 Network Segment. It also
700shows relay and gateway interface requirements needed to access remote networks (C12.22 Relay) and
701the translation services that may exists in these networks (C12.22 Gateway).
702
(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

703
704
705 Figure 6.1: C12.22 Reference network model
706
707Annotations:
708
7091. C12.22 Node attached to a C12.22 Network Segment
7102. C12.22 Application communicating using C12.19 Tables, C12.22 PSEM language and EPSEM/ACSE
711 encapsulation
7123. Layers 4 through 1 interfacing a C12.22 Application to an unspecified native network infrastructure
713 (e.g. TCP-IP/Ethernet, …)
7144. C12.22 Application of a C12.22 Gateway
7155. Layers 4 through 1 of a C12.22 Relay
7166. C12.22 Gateway performing translation of the C12.22 Application to and from an other application
7177. C12.22 Relay performing layer 4 through 1 translation
7188. Other application of a C12.22 Gateway
7199. Remote (other) network interface side of a C12.22 Gateway and /or C12.22 Relay
720
72113 Data order
722The data order is identical to that defined in ANSI C12.18 and ANSI C12.19.
723
724Within the syntax definitions, multiple parameters shall be encoded in the order as shown, from left to
725right.
726
727Parameters in all layers within the protocol definition are encoded most significant byte first. The order
728of data fields within tables is dictated by ANSI C12.19.
729
730
27 - XV -
28
731 <word24> ::= <msbyte> <byte> <lsbyte>
732 <word16> ::= <msbyte> <lsbyte>
733
734 <msbyte> ::= <byte> {most significant byte}
735 <lsbyte> ::= <byte> {least significant byte}
736
737 <byte> ::= <bit0> <bit1> <bit2> <bit3> <bit4> <bit5> <bit6> <bit7>
29 - XVI -
30
738
73914 Layer 7 - Application Layer
740The Application Layer provides a minimal set of services and data structures required to support end
741devices for purposes of configuration, programming and information retrieval in a networked
742environment.
743
744This layer is composed of the following four nested components:
745 ANSI C12.19 Table data structure
746 PSEM as defined in this section
747 EPSEM as defined in this section
748 ACSE association control as defined by IEC 8650 and presented in this section
749
750 15 Data Structure - Utility Industry Data Tables
751
752The data structure transported by this protocol are Tables as defined in ANSI C12.19.
753
754 16 Protocol Specification For Electric Metering (PSEM)
755
756This standard defines thirteen PSEM services. Each service description consists of a request and a
757response. Each of these requests and responses is described in following sections.
758
759 <requests> ::= <ident> | {* Identification Service request}
760 <read> | { Read Service request}
761 <write> | { Write Service request}
762 <logon> | {* Logon Service request}
763 <security> | { Security Service request}
764 <logoff> | {* Logoff Service request}
765 <terminate> {* Terminate Service request}
766 <disconnect> {* Disconnect Service request}
767 <wait> | {* Wait Service request}
768 <register> | {** Registration Service request}
769 <deregister> | {** Deregistration Service}
770 <resolve> | {** Resolve Service request}
771 <trace> {** Trace Service request}
772
773
774 <responses> ::= <ident-r> | {* Identification Service response}
775 <read-r> | { Read Service response}
776 <write-r> | { Write Service response}
777 <logon-r> | {* Logon Service response}
778 <security-r> | { Security Service response}
779 <logoff-r> | {* Logoff Service response}
780 <terminate-r> {* Terminate Service response}
781 <disconnect-r> {* Disconnect Service response}
782 <wait-r> | {* Wait Service response}
783 <register-r> | {** Registration Service response}
784 <deregister-r> | {** Deregistration Service response}
785 <resolve-r> | {** Resolve Service response}
786 <trace-r> {** Trace Service response}
787
788Notes:
789* Definition or content revised from ANSI C12.18 and/or ANSI C12.21
790** New in ANSI C12.22
791
79217 Request Codes
31 - XVII -
32
793
794PSEM requests always include a one-byte request code. Code numbers are assigned as follows:
795
79600H-1FH Codes shall not be used to avoid confusion with response codes
79720H-7FH Codes are available for use within ANSI C12 protocols
79880H-FFH Codes shall be reserved for protocol extensions
799
80018 Response Codes
801
802PSEM responses always include a one byte response code. These codes are listed below in a suggested
803order of priority. They represent an extension to the response codes available in ANSI C12.18 and ANSI
804C12.21. When more than one response code is capable of indicating the error response condition of a
805C12.22 Node, the response code having the highest priority (from left to right) may be provided as
806follows:
807
808 <nok> ::= <sns>|<isss>|<iar>|<sme>|<isc>|<onp>|<bsy>|<dlk>|<dnr>|
809 <rno>|<uat>|<netr>|<nett>|<rqtl>|<rstl>|<sgnp>|<sgerr>|<err>
810
811For example, if a C12.22 Device with a C12.22 Application that contain ANSI C12.19 Tables; and Table 5
812of this device is read-only and it is encoded in non-volatile memory then a Write Service request to Table
8135 would fail. The C12.22 Device may consider the following codes as suitable responses: <err> to
814indicate an error condition or <dlk> to indicate that the data is locked in memory and cannot be changed,
815<iar> to indicate that the action requested was not appropriate for this device design or <isc> to indicate
816that the table access permission are “read-only” under the current security policy. The correct response
817would be <iar> as it is the highest priority among <iar>, <isc>, <dlk> and <err>. However, if there is a
818mechanism for providing write access to Table 5, then <iar> should not be considered. Therefore, the
819response code becomes <isc>.
820
821Responses
822
823 <ok> ::= 00H {Acknowledge
824 No problems, request accepted.}
825
826 <err> ::= 01H {Error
827 This code is used to indicate rejection of the received
828 service request. The reason for the rejection is not
829 provided.}
830
831 <sns> ::= 02H {Service Not Supported
832 This Application-level error response will be sent to the
833 device when the requested service is not supported.
834 This error indicates that the message was valid, but the
835 request could not be honored. The <sns> error response
836 has special implications in the context of a response to a
837 Logoff, Terminate or Disconnect service request.
838 Specifically, a C12.22 Node in the Session State shall
839 not issue this error, but it is permitted if the C12.22 Node
840 only supports sessionless communication.}
841
842 <isc> ::= 03H {Insufficient Security Clearance
843 This Application-level error indicates that the current
844 authorization level is insufficient to complete the
845 request.}
846
847 <onp> ::= 04H {Operation Not Possible
848 This Application-level error will be sent to the device
849 which requested an action that is not possible. This
33 - XVIII -
34
850 error indicates that the message was valid, but the
851 message could not be processed and covers conditions
852 such as: invalid <length> or invalid <offset>. It can also
853 be issued if the operation is not possible under the
854 current C12.22 Node configuration.}
855
856 <iar> ::= 05H {Inappropriate Action Requested
857 This Application-level error indicates that the action
858 requested was inappropriate. Covers conditions such as
859 a Write Service request to a read-only Table or an
860 invalid Table identifier.}
861
862 <bsy> ::= 06H {Device Busy
863 This Application-level error indicates that the request
864 was not acted upon because the device was busy doing
865 something else. The operation may be retried at a later
866 time with success, as the data may then be ready for
867 transportation during this active communication.}
868
869 <dnr> ::= 07H {Data Not Ready
870 This Application-level error indicates that request was
871 unsuccessful because the requested data is not ready to
872 be accessed.}
873
874 <dlk> ::= 08H {Data Locked
876 was unsuccessful because the data cannot be
877 accessed.}
878
879 <rno> ::= 09H {Renegotiate Request
880 This Application-level error indicates that the responding
881 device wishes to return to the identification or Base
882 State and renegotiate communication parameters.}
883
884 <isss> ::= 0AH {Invalid Service Sequence State
886 cannot be accepted at the current service sequence
887 state. For more information on service sequence states,
888 see Annex D. This is an indication to the C12.22
889 Application not to reissue this request at this time
890 because there is a service sequence state problem or an
891 out-of-order operations problem.}
892
893 <sme> ::= 0BH {Security Mechanism Error
894 This Application-level error may be returned when a
895 security mechanism error is detected. This code covers
896 errors such as a security mechanism not being
897 supported and invalid encryption key.}
898
899 <uat> ::= 0CH {Unknown Application Title
900 This Application-level error may be returned by a
901 C12.22 Relay or the target node when an unknown or
902 invalid <called-ap-title> is received.}
903
904 <nett> ::= 0DH {Network Time-out
906 Network Time-out is detected.}
35 - XIX -
36
907
908 <netr> ::= 0EH {Network Not Reachable
910 node is not reachable.}
911
912 <rqtl> ::= 0FH <max-request-size>
913 {Request Too Large
914 This Application-level error may be returned when the
915 request size is too large.}
916
917 <max-request-size> ::= <word32> {Maximum request size in bytes allowed by the target
918 device.}
919
920 <rstl> ::= 10H <max-response-size>
921 {Response Too Large
922 This Application-level error may be returned when the
923 response size of a response is too large.}
924
925 <max-response-size> ::= <word32> {Maximum response size in bytes allowed by the target
926 device.}
927
928 11H-1FH {Response codes in this range are not defined by this
929 Standard.}
930
931 20H-7FH {These codes shall not be used to avoid confusion with
932 request codes}
933
934 80H-FFH {These codes shall be reserved for protocol extensions}
935
936 <sgnp> ::= 10H {Segmentation not possible
938 C12.22 Node received a segment and does not support
939 the Application Segmentation Sub-Layer.}
940
941 <sgerr> ::= 11H <segment-byte-offset> <apdu-size>
942 {Segmentation error
944 C12.22 Node fail to segment or reassemble an <acse-
945 pdu>.}
946
947 <segment-byte-offset> ::= <byte> | <word16> | <word24>
948 {Offset in bytes relative to the beginning of the fully
949 assembled APDU which the first error was detected.}
950
951 <apdu-size> ::= <byte> | <word16> | <word24>
952 {Size of the fully assembled APDU, <acse-pdu>, in
953 bytes. The data encoding format of the <apdu-size> and
954 <segment-byte-offset> shall be identical.}
955
95619 Time-out
957
95820 Session Time-out
959
960Each session established with a C12.22 Server shall be monitored by the C12.22 Server and shut down
961when the session becomes inactive. An inactive session is one which does not receive EPSEM
962messages from the C12.22 Client within an allowable time period. An EPSEM message may be a
963request or a response.
37 - XX -
38
964
965The Session Time-out value is set by the Logon Service request and can be temporarily modified for the
966next request through the use of the Wait Service.
967
968The Session Time-out interval starts upon transmission by the C12.22 Server of an <ok> response to a
969Logon Service request that was issued by the C12.22 Client. The timer restarts upon transmission or
970reception of any byte of an <acse-pdu> on the C12.22 Server side during a session.
971
972The time-out timer stops when the session ends for any reason.
973
974When multiple concurrent sessions are supported, the Session Time-out for each session is set
975independently by the Logon Service request that established the session.
976
97721 Application Layer Response Time-out
978
979The application layer response timeout is used by a C12.22 Node that issues service requests to another
980C12.22 Node and needs to know how long to wait for responses.
981
982A non-recoverable Application Layer Response Timeout shall terminate the associated session if one
983exists. A non-recoverable Application Layer Response Timeout is the last one, for implementations that
984allow retries, or the first one in implementations that do not.
985
986An example time-out algorithm is described in Annex F APDU Response Timeout Algorithm.
39 - XXI -
40
987
98822 Services
989
99023 Identification Service
991
992This service is used to obtain information about end device functionality. The service returns a code
993identifying the reference standard, the version and revision of the reference standard implemented, and
994an optional feature list.
995
996Request:
997
998 <ident> ::= 20H
999
1000Response:
1001
1002The responses <isss>, <bsy>, and <err> indicate a problem with the received service request. The
1003response <ok> indicates the Identification Service request was accepted and the standard, version,
1004revision and optional feature list are included in the response.
1005
1006 <ident-r> ::= <isss> | <bsy> | <err> |
1007 <ok> <std> <ver> <rev> <feature>* <end-of-list>
1008
1009 <std> ::= <byte> {Code identifying reference standard. The codes are
1010 defined as follows:
1011 00H = ANSI C12.18
1012 01H = Reserved
1013 02H = ANSI C12.21
1014 03H = ANSI C12.22
1015 04H-FFH = Reserved
1016
1017 This value shall be 03H.}
1018
1019 <ver> ::= <byte> {Binary representation of the referenced standard
1020 version number to the left of the decimal point. This
1021 value shall be 01H.}
1022
1023 <rev> ::= <byte> {Binary representation of the referenced standard
1024 version number to the right of the decimal point. This
1025 value shall be 00H.}
1026
1027 <feature> ::= <security-mechanism> |
1028 <session-ctrl> |
1029 <device-class> |
1030 <device-identity> {Features available}
1031
1032 <end-of-list> ::= 00H {End of list indicator.}
1033
1034 <security-mechanism> ::= 04H <universal-id>
1035 {Present in the feature list only if the end device
1036 supports one or more security mechanisms. This feature
1037 element contains the universal id of the security
1038 mechanism supported. See the <mechanisms-name-
1039 element> in section “40 Association Control –
1040 Association Control Service Element (ACSE)“ for more
1041 information.}
1042
1043 <session-ctrl> ::= 05H <byte> {Bit 0 to 6:NBR_SESSION_SUPPORTED
41 - XXII -
42
1044 If greater than zero, the end device supports session-
1045 based communication. A Session starts by the reception
1046 of the Logon Service and ends by the reception of the
1047 Logoff Service or the detection of a Session Time-out.
1048
1049 Bit 7: SESSIONLESS_SUPPORTED
1050 If true, the end device supports the use of the Read and
1051 Write Services outside a session.
1052
1053 By default, when <session-ctrl> field is not included in
1054 the identification response, one session and sessionless
1055 operations are supported.}
1056
1057 <device-class> ::= 06H <universal-id> {A Universal Identifier that uniquely identifies a C12.19
1058 Device Class object for early detection per the value of
1059 the MANUFACTURER element as defined in Table 0 of
1060 ANSI C12.19-1997 or the DEVICE_CLASS element as
1061 defined by version 2 of ANSI C12.19. When <device-
1062 class> is provided it shall be placed before <feature>s
1063 with codes that are greater than 06H.}
1064
1065 <universal-id> ::= <relative-uid-element> | <absolute-uid-element>
1066 {The C12.19 Device Class encoded as an absolute or
1067 relative registered universal object identifier.
1068
1069 <absolute-uid-element> ::= 06H <uid-length> <absolute-uid>
1070 {The absolute encoding of the C12.19 Device Class.
1071 E.g. 1.2.840.10066.0.<relative-uid>, encoded as
1072 described in ISO 8825-1-1997, Basic Encoding Rules
1073 (BER). The last four bytes of this identifier shall be
1074 identical to the values delivered in the C12.19 Table
1075 elements MANUFACTURER as defined in Table 0 of
1076 ANSI C12.19-1997 or the DEVICE_CLASS as defined
1077 by version 2 of ANSI C12.19.}
1078
1079 <relative-uid-element> ::= 0DH <uid-length> <relative-uid>
1080 {The relative encoding of the C12.19 Device Class
1081 relative to the universal identifier 1.2.840.10066.0,
1082 encoded as described in ISO 8825-1-1997, Basic
1083 Encoding Rules (BER). The <uid-length> shall range
1084 between to 00H to 04H resulting in up to four bytes being
1085 transmitted. These four bytes shall be identical to the
1086 C12.19 Table elements MANUFACTURER as defined in
1087 Table 0 of ANSI C12.19-1997 or the DEVICE_CLASS as
1088 defined by version 2 of ANSI C12.19, with assumed 00H
1089 trailing pad.}
1090
1091 <uid-length> ::= <byte> {Length of number of bytes that follow. This value shall
1092 range between 00H to 7FH}
1093
1094 <absolute-uid> ::= <byte>+ {Absolute object identifier encoded as described in ISO
1095 8825-1-1997 [BER]. The size of this field shall not
1096 exceed 127 bytes.}
1097
1098 <relative-uid> ::= <byte>+ {Relative object identifier encoded as described in ISO
1099 8825-1-1997 [BER]. The size of this field shall not
1100 exceed 4 bytes.}
43 - XXIII -
44
1101
1102 <device-identity> ::= 07H <identity-length><identity>
1103 {An Identifier that uniquely identifies a C12.19 Device in
1104 the application space of the C12.19 Device. This
1105 provides for early detection of the device identification
1106 element as per IDENTIFICATION of Table 5,
1107 DEVICE_IDENT_TBL, or DEVICE_ID found in Table 6
1108 of ANSI C12.19. The C12.19 <device-identity> feature
1109 shall be supplied when the C12.19 Device’s Table 5 or
1110 Table 6, are readable immediately following the <logon>
1111 service. When C12.19 Device Identification is provided
1112 it shall not precede <feature>s with codes that are less
1113 than 07H.}
1114
1115 <identity-length> ::= <byte> {Length of number of bytes that follow in <identity>. This
1116 value shall range between 00H to 7FH}
1117
1118 <identity> ::= <char-format><identification>
1119 {Provides for early (pre-logon) disclosure of the C12.19
1120 Device identification.}
1121
1122 <char-format> ::= <byte> {The character encoding format of the bytes which make
1123 up <identification>. Its interpretation shall be according
1124 to the relevant ANSI C12.19 Standard data model
1125 referenced by the C12.19 registered Device Class
1126 feature <device-class>. When the <device-class>
1127 feature was not supplied in this <ident> response, the
1128 value of <char-format> shall be set to 01H, and
1129 <identification> shall be encoded according to ISO 7-bit
1130 coded character set for information interchange, per
1131 ISO/IEC 646: 1991.}
1132
1133 <identification> ::= <byte> * {The C12.19 Device identification string encoded and
1134 transmitted according to <char-format>. If the C12.19
1135 Device’s ID_FORM in table 0, is set to BCD then the
1136 BCD digits shall be transmitted as their text equivalent
1137 also encoded as per <char-format>.
1138
1139 For example, if the C12.19 Device’s
1140 GEN_CONFIG_TBL.ID_FORM is BCD and the device’s
1141 GEN_CONFIG_TBL.CHAR_FORMAT is ISO 7 bit
1142 ASCII, as per ISO/IEC 646: 1991), then the BCD digits
1143 00H 01H 02H 03H 0AH 04H 0DH 05H 06H 07H shall be
1144 transmitted as the character sequence “123-4.567”. The
1145 C12.19 application shall logically pad this string with
1146 trailing spaces, as needed, to fill the identification field
1147 width of the C12.19 Device.}
1148
114924 Read Service
1150
1151The Read Service is identical to that in ANSI C12.18 and ANSI C12.21 with the inclusion of additional
1152error response codes defined by this Standard.
1153
1154The Read Service is used to cause a transfer of Table data to the requesting device.
1155
1156Request:
1157
45 - XXIV -
46
1158The read request allows both complete and partial Table transfers. The retrieval of a portion of a Table is
1159possible through the use of both index/element-count and offset/octet-count methods. The complete rule
1160set for using these methods is enumerated in section “37 Partial Table access using index/element-count
1161Method” and section “38 Partial Table access using offset/octet-count method” respectively.
1162Request codes 30H–39H, 3EH and 3FH give access to all possible methods used for Table transfer.
1163Request code 30H specifies a complete Table transfer. Request codes 31H through 39H specify a partial
1164table transfer using 1 to 9 indices. Request code 3EH specifies a default Table transfer. Request code 3F H
1165specifies a partial table transfer using the offset/octet-count method.
1166
1167 <read> ::= <full-read> | <pread-index> | <pread-offset> | <pread-default>
1168
1169 <full-read> ::= 30H <tableid>
1170
1171 <pread-index> ::= <read-index-type> <tableid> <index>+ <element-count>
1172
1173 <read-index-type> ::= 31H | {1 <index> included in request}
1174 32H | {2 <index> included in request}
1181 39H {9 <index> included in request}
1182
1183 <pread-default> ::= 3EH {Transfer default table}
1184
1185 <pread-offset> ::= 3FH <tableid> <offset> <octet-count>
1186
1187 <tableid> ::= <word16> {Table identifier as defined in ANSI C12.19.}
1188
1189 <offset> ::= <word24> {Offset into data table in bytes. Offset 0000H is the offset
1190 to the first table element of the table selected by
1191 <tableid>.}
1192
1193 <index> ::= <word16> {Index value used to locate start of data. Index 0000H+
1194 is the index of the first table element of the table
1195 selected by <tableid>.}
1196
1197 <element-count> ::= <word16> {Number of elements to read starting at the requested
1198 <index>.}
1199
1200 <octet-count> ::= <word16> {Length of table data requested starting at <offset>, in
1201 bytes}
1202
1203Response:
1204
1205Responses of type <nok> indicate a problem with the received service request.
1206
1207The response <ok> indicates the Read Service was accepted and the <data> is part of the response.
1208
1209 <read-r> ::= <nok> |
1210 <ok> <table-data>
1211
1212 <table-data> ::= <count> <data> <cksum>
1213
1214 <count> ::= <word16> {Length of <data> returned, in bytes}
47 - XXV -
48
1215
1216
1217 <data> ::= <byte>+ {The returned table data including the optional pending
1218 header, according to ANSI C12.19, when requested.}
1219
1220 <cksum> ::= <byte> {2's compliment checksum computed only on the <data>
1221 portion of <table-data>. The checksum is computed by
1222 summing the bytes (ignoring overflow) and negating the
1223 result.}
1224
122525 Write Service
1226
1227The Write Service is identical to that in C12.18 and ANSI C12.21 with the inclusion of additional error
1228response codes defined by this Standard.
1229
1230The Write Service is issued to transfer Table data to the target device.
1231
1232Request:
1233
1234The Write Request allows both complete and partial table transfers. The modification of a portion of a
1235table is possible through the use of both index/element-count and offset/octet-count methods. The
1236complete rule set for using these methods is enumerated in 6.3.2.6 and 6.3.2.7 respectively.
1237
1238Request codes 40H–49H and 4FH give access to all possible methods used for table transfer. Request
1239code 40H specifies a complete table transfer. Request codes 41H through 49H specify a partial table
1240transfer using 1 to 9 indices. Request code 4FH specifies a partial table transfer using the offset/octet-
1241count method.
1242
1243 <write> ::= <full-write> | <pwrite-index> | <pwrite-offset>
1244
1245 <full-write> ::= 40H <tableid> <table-data>
1246
1247 <pwrite-index> ::= <write-index-type> <tableid> <index> + <table-data>
1248
1249 <write-index-type> ::= 41H | {1 <index> included in request}
1257 49H {9 <index> included in request}
1258
1259 <pwrite-offset> ::= 4FH <tableid> <offset> <table-data>
1260
1261 <tableid> ::= <word16> {Table identifier as defined in ANSI Standard C12.19.}
1262
1263 <offset> ::= <word24> {Offset into data table in bytes. Offset 0000H is the offset
1264 to the first element of the table selected by <tableid>.}
1265
1266 <index> ::= <word16> {Index value used to locate start of data. Index 0000H+ is
1267 the index of the first element of the table selected by
1268 <tableid>.}
1269
1270 <table-data> ::= <count> <data> <cksum>
1271
49 - XXVI -
50
1272 <count> ::= <word16> {Length of <data> to be written, in bytes. This includes
1273 the optional pending header length as defined by ANSI
1274 C12.19.}
1275
1276 <data> ::= <byte>+ {The table data elements including the optional pending
1277 header as per ANSI C12.19 when requested.}
1278
1279 <cksum> ::= <byte> {2's compliment checksum computed only on the <data>
1280 portion of <table-data>. The checksum is computed by
1281 summing the bytes (ignoring overflow) and negating the
1282 result.}
1283
1284Response:
1285
1286Responses of type <nok> indicate a problem with the received service request.
1287
1288The response <ok> indicates the Write Service was successfully completed and the data was
1289successfully transmitted to the device.
1290
1291 <write-r> ::= <nok> |
1292 <ok>
1293
129426 Logon Service
1295
1296Logon Service establishes a session without establishing access permissions. It provides for immediate
1297transfer to the session state from the idle state. A peer-to-peer association shall be established.
1298
1299Request:
1300
1301The <user-id> parameter is a code, optionally stored by the C12.22 Node, indicating a supplied identity
1302of the operator requesting the creation of a session. The <user-id> may be inserted in the Event and
1303History Logs of the C12.19 tables Standard referenced in section “3 References”, when supported by the
1304metering device. The <user> field provides the name of the operator requesting the access to the
1305C12.22 Node and may be recorded in the Utility Information Table (Table 06).
1306
1307The Logon Service request has the following format:
1308
1309 <logon> ::= 50H <user-id> <user> <req-session-idle-timeout>
1310
1311 <user-id> ::= <word16> {User identification code}
1312
1313 <user> ::= <byte> +10 {10 bytes containing user identification}
1314
1315 <req-session-idle-timeout> ::= <word16> {The desired number of seconds a session may be idle
1316 on the C12.22 Server side before the C12.22 Server
1317 may terminate the session.}
1318
1319Response:
1320
1321All responses other than <ok> indicate a problem with the received service request and the session and
1322the association shall not be established. The C12.22 Node shall remain in the idle state.
1323
1324All error responses (including those that are not listed below or extensions on those covered by <nok>)
1325shall be generically interpreted as an indication to the application not to issue another Logon request
1326without first addressing the cause of the indicated error condition.
1327The response <ok> indicates that the Session was successfully established.
1328
51 - XXVII -
52
1329 <logon-r> ::= <nok> |
1330 <ok> <resp-session-idle-timeout>
1331
1332 <resp-session-idle-timeout> ::= <word16>
1333 {The number of seconds a session may be idle on the
1334 C12.22 Server before the C12.22 Server may terminate
1335 the Session. This value shall be less than or equal to
1336 <req-session-idle-timeout>.}
1337
133827 Security Service
1339
1340The Security Service is identical to that in C12.18 and ANSI C12.21 with the inclusion of additional error
1341response codes defined by this Standard.
1342
1343The Security Service is provided for setting access permissions.
1344
1345It should be noted that sending passwords as clear text (unencrypted) over the network is a security
1346concern. Available encryption services are described in section “57 C12.22 Security Mechanism”.
1347
1348Request:
1349
1350A password is used as a means to select access permissions. This service request may only be sent
1351during a session. The <password> field will be compared with those in the Security Table (Standard
1352Table 42) defined in ANSI C12.19, if the password tables are supported by the metering device.
1353
1354 <security> ::= 51H <password>
1355
1356 <password> ::= <byte> +20 {20 byte field containing password}
1357
1358Response:
1359
1360The responses <sns>, <isss>, <bsy> and <err> indicate a problem with the received service request.
1361
1362The response <ok> indicates the security service was successfully completed and the access
1363permissions associated with the password were granted.
1364
1365 <security-r> ::= <sns> | <isss> | <bsy> | <err> |
1366 <ok>
1367
136828 Logoff Service
1369
1370The Logoff Service provides for an orderly termination of the session that was established by the Logon
1371Service. It provides for immediate transfer to the idle state from the session state. The peer-to-peer
1372association shall terminate and all previously negotiated settings shall reset to their default idle-state
1373values.
1374
1375The Physical Layer signaling parameters of the C12.22 Node shall not be affected by this service.
1376
1377Request:
1378
1379 <logoff> ::= 52H
1380
1381Response:
1382
1384the association shall retain the settings negotiated prior to the issuance of the Logoff Service request
1385unless otherwise specifically indicated by the error code.
53 - XXVIII -
54
1386
1387All error responses shall be generically interpreted as an indication to the application not to issue another
1388Logoff Service request without first addressing the cause of the indicated error condition.
1389
1390When a response other than <ok> is understood to be an indication other than the severance of the
1391communication path or association, the application may issue any valid session state service request or
1392choose to terminate the association or it may let the Session time-out to force the Session to be aborted.
1393
1394 <logoff-r> ::= <nok> |
1395 <ok> {Response code or error codes as per Section “18
1396 Response Codes”.}
1397
1398The response <ok> indicates the successful termination of the Session. This is an indication to the
1399C12.22 Application that the C12.22 Node completed all session-related processing before terminating the
1400session and that it reset its communication parameters to their default settings and entered the idle state.
1401The Association between the peer C12.22 Nodes was terminated.
1402
140329 Terminate Service
1404
1405The Terminate Service provides for an orderly abortion of the Session that was established by the Logon
1406Service. It provides for transfer to the idle state from the session state. The peer-to-peer Association
1407shall terminate and all previously negotiated settings shall reset to their default idle-state values.
1408
1409This application-level service may be used to terminate a Session for reasons such as excessive errors,
1410security issues, internal error conditions, a need to abort session, or other reasons.
1411
1412The Physical Layer signaling parameters of the C12.22 Node shall not be affected by this service.
1413
1414Request:
1415
1416 <terminate> ::= 21H
1417
1418Response:
1419
1421the association shall retain the settings negotiated prior to the issuance of the Terminate Service request.
1422
1423All error responses shall be generically interpreted as an indication to the application not to issue another
1424Terminate Service request without first addressing the cause of the indicated error condition.
1425
1426When a not <ok> response is understood to be an indication other than the severance of the
1427communication path or association, the application may issue any valid session state service request or
1428choose to terminate the Association or it may let the Session timeout to force the session to be aborted.
1429
1430 <terminate-r> ::= <nok> |
1431 <ok>
1432
1433The request <ok> indicates that the Session was terminated and that the C12.22 Node aborted all
1434session-related processing and that it reset its communication parameters to their default settings and
1435entered the idle state The Association between the peer C12.22 Nodes was terminated.
1436
143730 Disconnect Service
1438
1439The Disconnect Service is used to remove a C12.22 Node from the C12.22 Network Segment.
1440
55 - XXIX -
56
1441The Disconnect Service, when issued within a Session, provides for an orderly abortion of the Session
1442that was established by the Logon Service. It is functionally equivalent to Terminate Service request that
1443is followed by a transition to the off-line state.
1444
1445When received in the idle state it shall cause the C12.22 Node to enter the off-line state.
1446
1447All peer-to-peer Associations across the interface of the C12.22 Node on the C12.22 Network segment
1448that processed this request shall terminate. The C12.22 Node’s settings shall reset to their default off-line
1449state values for that C12.22 Network Segment.
1450
1451The Physical Layer signaling parameters of the C12.22 Node may be affected by this service.
1452
1453For this service request to be successful, the initiator shall have write access permission to Procedure 25
1454NETWORK_INTERFACE_CONTROL_PROC.
1455
1456Request:
1457
1458 <disconnect> ::= 22H
1459
1460
1461Response:
1462
1463All responses other than <ok> indicate a problem with the received service request and the Physical
1464Layer signaling parameters, session and the association shall retain the settings negotiated prior to the
1465issuance of the Disconnect Service request.
1466
1467All error responses shall be generically interpreted as an indication to the C12.22 Application not to issue
1468another Disconnect Service request without first addressing the cause of the indicated error condition.
1469
1470When a <nok> response is understood to be an indication other than the severance of the
1471communication path or association, the C12.22 Application may issue any valid service request or
1472choose to terminate the association or it may let the association time-out to force a session to be
1473aborted.
1474
1475 <disconnect-r> ::= <nok> |
1476 <ok> {Response code or error codes as per Section “18
1477 Response Codes”.}
1478
1479The response <ok> indicates the that Disconnect Service was accepted. If the C12.22 Node was in the
1480session state then this is an indication of the successful abortion of the Session.
1481
1482This is also an indication that the C12.22 Node aborted all Session-related processing, removed itself
1483from the C12.22 Network Segment (by de-asserting the appropriate Physical Layer signals), entered the
1484off-line state and reset its communication parameters to their default settings. The Association between
1485the peer C12.22 Nodes was terminated and all other Associations that share the same Interface on the
1486C12.22 Node network segment that processed this response were also terminated.
1487
148831 Wait Service
1489
1490The Wait Service is used to maintain an established Session during idle periods, thus preventing
1491automatic termination. This service temporarily extends the Session Time-out to the <time> specified in
1492the request upon acknowledgement of the Wait Service request. The Session Time-out will be reset to
1493the default value once the next valid service is received by this target.
1494
1495Request:
1496
1497 <wait> ::= 70H <time>
57 - XXX -
58
1498 <time> ::= <byte> {Requested wait period in seconds. The value zero does
1499 not affect the Channel settings.}
1500
1501Response:
1502
1503The responses <sns>, <isss>, <bsy>, and <err> indicate a problem with the received service request and
1504Session Time-out is not extended.
1505
1506The response <ok> indicates the service request was accepted and the Session Time-out is extended to
1507the value requested.
1508
1509 <wait-r> ::= <sns> | <isss> | <bsy> | <err> |
1510 <ok>
1511
151232 Registration Service
1513
1514The Registration Service is used to add and keep routing-table entries of C12.22 Relays active. To be
1515part of a C12.22 Network, a C12.22 Node shall send a Registration Service request to one of the C12.22
1516Master Relays. This service is carried in an ACSE application data unit <acse-pdu> with the Calling
1517ApTitle set to the ApTitle of the registering C12.22 Node and the Called ApTitle set to the ApTitle of the
1518C12.22 Master Relay. This service carries the node type, the node class, serial number, registration
1519lifetime parameters and an optional native address of the registering node. The native address is used
1520only by the neighbor C12.22 Relay to send messages back to this node and it is ignored by all others
1521nodes.
1522
1523The C12.22 Master Relay shall send a copy of each registration received to all C12.22 Notification Hosts
1524and all C12.22 Authentication Hosts that need to be notified. In this case, the Registration Service is sent
1525with the Calling ApTitle set to the ApTitle of the C12.22 Master Relay and the Called ApTitle set, in turn,
1526to the ApTitle of each C12.22 Host notified.
1527
1528Request:
1529
1530 <register> ::= 27H <node-type> <connection-type> <device-class>
1531 <ap-title> <serial-number> <address-length>
1532 <native-address> <registration-period>
1533
1534 <node-type> ::= <byte> {An identification of the C12.22 Node’s Attributes. These
1535 values may be set to advertise the capabilities of this
1536 C12.22 Node and to assist C12.22 Master Relay in the
1537 decision making for the successful completion of all
1538 communication with other C12.22 Nodes that participate
1539 in the registration process.
1540
1541 Bit 0 to 5: NODE_TYPE as per
1542 INTERFACE_STATUS_TBL.NODE_TYPE_BFLD.
1543
1544 Bit 0: RELAY
1545 When set to 1 it is an indication that this C12.22 Node is
1546 a C12.22 Relay. All C12.22 Relays shall set this bit to 1.
1547
1548 Bit 1: MASTER_RELAY
1550 a C12.22 Master Relay. All C12.22 Master Relays shall
1551 set this bit to 1.
1552
1553 Bit 2: HOST
59 - XXXI -
60
1555 a C12.22 Host.
1556
1557 Bit 3: NOTIFICATION_HOST
1559 a C12.22 Notification Host. All C12.22 Notification Hosts
1560 shall set this bit to 1, if they wish the C12.22 Master
1561 Relay to add them to their list of Notification Hosts or
1562 issue notifications to this C12.22 Node when other
1563 C12.22 Nodes register with the servicing C12.22 Master
1564 Relay (See <called-ap-title>). Note: This does not
1565 preclude static registration; however notifications may
1566 not be received until the C12.22 Master Relay registers
1567 this C12.22 Node as a C12.22 Notification Host.
1568
1569 Bit 4: AUTHENTICATION_HOST
1571 a C12.22 Authentication Host. All C12.22 Authentication
1572 Hosts shall set this bit to 1, if they wish the C12.22
1573 Master Relay to add them to their list of Authentication
1574 Hosts or issue registration requests to this C12.22 Node
1575 when other C12.22 Nodes register with the servicing
1576 C12.22 Master Relay (See <called-ap-title>). Note: This
1577 does not preclude static registration; however
1578 notifications may not be received until the C12.22
1579 Master Relay registers this C12.22 Node as a C12.22
1580 Authentication Host.
1581
1582 Bit 5: END_DEVICE
1584 a C19.22 End Device, i.e. it has metrological sensors
1585 and C12.19 Tables.
1586
1587 Bit 6: BROADCAST_AND_MULTICAST
1588 When set to 1 it is an indication that this C12.22 Node
1589 accepts broadcast and multicast messages.
1590
1591 Bit 7: Is reserved and shall be set to zero.
1592
1593 <connection-type> ::= <byte> {An indication of the type of connection requested and
1594 the core capability related to this C12.22 Node in regard
1595 to its connection to the C12.22 Network Segment.
1596
1597 Bits 0..5: Are reserved and shall be set to 0.
1598
1599 Bit 6: CONNECTION
1600 This bit is set to 1 if the local network segment uses a
1601 connection-oriented protocol.
1602 This bit is set to 0 if the local network segment uses a
1603 connectionless protocol.
1604
1605 Bit 7: ACCEPT_CONNECTION
1606 This bit is set to 1 when the local network segment uses
1607 a connection oriented protocol (Bit 6 set to 1) and the
1608 registering node accepts connections.}
1609
61 - XXXII -
62
1610 <device-class> ::= <byte> +4 {A list of encoding of sub-identifiers expressed as the
1611 four bytes containing the MANUFACTURER_ID as
1612 defined in Table 0 of ANSI C12.19-1997 or the
1613 DEVICE_CLASS as defined by Version 2 of ANSI
1614 C12.19 and registered to NEMA.
1615
1616 This is subset of the Relative Object Identifier defined in
1617 ISO/IEC 8825-1: 1998/Amd.1: 1999 (E) and expressed
1618 by the <relative-uid-element>) follows:
1619
1620 The leading Relative Object Identifier introducer, 0D H,
1621 and length fields are not present in the Table 0 element.
1622 The length is assumed to be 4. Then each sub-identifier
1623 is represented as a series of (one or more) bytes. Bit 7
1624 of each byte indicates shall be clear to zero when it is
1625 the last member in the series. Bit 7 of each preceding
1626 octets in the series is set one. Bits 6-0 of the byte in the
1627 series collectively encode the sub-identifier
1628 concatenated to form an unsigned binary number whose
1629 most significant bit is bit 6 of the first octet and whose
1630 least significant bit is bit 0 of the last octet. The sub-
1631 identifier are be encoded in the fewest possible bytes
1632 such that the leading octet of the sub-identifier will not
1633 have bit 7 set to one.
1634
1635 For example if the value reported by
1636 MANUFARTURER_ID is “TEMP”, representing the
1637 relative object identifier 84.69.77.80 it is encoded as 54 H
1638 45H 4DH 50H. It shall be interpreted as a Relative UID
1639 encoding of 0DH 04H 54H 45H 4DH 50H.
1640
1641 Similarly when the value reported by DEVICE_CLASS is
1642 8571.3.2 or encoded as C2H 7BH 03H 02H it is interpreted
1643 as a Relative UID encoding of 0DH 04H C2H 7BH 03H
1644 02H.}
1645
1646 <ap-title> ::= <universal-id-element> | <relative-uid-element>
1647 {ApTitle of the C12.22 Node to be registered. The field is
1648 optional and when not provided, its length is set to zero,
1649 implying that the ApTitle shall be automatically obtained
1650 from an authoritative proxy Relay.}
1651
1652 <serial-number> ::= <universal-id-element> | <relative-uid-element>
1653 {Unique serial number assigned to this C12.22 Device
1654 by its owner and provided for registration authentication.
1655 The field is optional and when not provided, its length is
1656 set to zero.}
1657
1658 <address-length> ::= <byte> {Number of bytes in <return-address>.}
1659
1660 <native-address> ::= <byte> + {Native address to use to forward messages to this
1661 node. This field is optional if lower layers of the protocol
1662 already provide it.
1663 When defined for a specific protocol stack, this field can
1664 be subdivided in sub-fields to provide address type and
1665 address data to facilitate address resolution.}
1666
63 - XXXIII -
64
1667 <registration-period> ::= <word24> {Maximum period in seconds desired by the C12.22
1668 Node to elapse between successive re-registration
1669 requests (keep-registration-alive). The value 0 implies
1670 that a re-registration life-timer is not supplied by the
1671 registering node.}
1672
1673Response:
1674
1675The response <nok> indicates that the some or all registrations were rejected for some reason by the
1676Master Relay. The Calling ApTitle shall be set to the ApTitle of the Master Relay which responded. The
1677response <ok> indicates that this ApTitles <universal-id-element> have been registered and routing
1678tables have been updated.
1679 <register-r> ::= <nok> |
1680 <ok> <reg-ap-title> <reg-delay> <reg-period> <reg-info>
1681
1682 <reg-ap-title> ::= <universal-id-element> | <relative-uid-element>
1683 {Registered ApTitle to be used by the C12.22 Node for
1684 future communication on this route.}
1685
1686 <reg-delay> ::= <word16> {Maximum delay in seconds that the device should wait
1687 before registering after a power up. A value of 3600
1688 seconds shall be used as a default if this value cannot
1689 be retained. The actual delay used to re-register shall be
1690 a random value between 0 and this value.}
1691
1692 <reg-period> ::= <word24> {Maximum period in seconds allowed to elapse between
1693 successive re-registration requests (keep-registration–
1694 alive). The device is automatically un-registered when
1695 this limit is reached. The value 0 implies that a re-
1696 registration is not required, the registration is static.}
1697
1698 <reg-info> ::= <byte> {Bit 0: DIRECT_MESSAGING_AVAILABLE
1699 Indicates whether direct messaging is available and
1700 provides performance benefit on this network segment.
1701 0 = Use message forwarding only.
1702 1 = Direct messaging is the preferred delivery method.}
1703
170433 Deregistration Service
1705
1706The Deregistration Service is used to remove routing tables entries of C12.22 Relays, Master Relays and
1707provide service discontinuation to all of the C12.22 Master Relay authentication and notification hosts.
1708
1709Request:
1710
1711 <deregister> ::= 24H <ap-title> {Request to process all the <ap-title>s supplied. until the
1712 list is exhausted}
1713Response:
1714
1715The response <nok> indicates that deregistration was rejected for identified <ap-title>. The response
1716<ok> indicates that the identified <ap-title> was deregistered and routing tables have been updated.
1717
1718 <deregister-r> ::= <nok> |
1719 <ok> <ap-title>
1720
172134 Resolve Service
1722
65 - XXXIV -
66
1723The Resolve Service is used to retrieve the native network address of a C12.22 Node. This native
1724address is used to communicate directly with other C12.22 Nodes on the local area network. The
1725Resolve request contains the ApTitle of the C12.22 Node for which native address is requested. This
1726request is carried in an ACSE application data unit <acse-pdu> with the Calling ApTitle set to the ApTitle
1727of requesting node and the Called ApTitle set to the ApTitle of the of requested C12.22 Relay.
1728
1729On network segments capable of broadcast, this service can also be used to retrieve native addresses of
1730C12.22 Relays. A node that wants to retrieve the list of local C12.22 Relays shall initiate a resolve
1731request with the called ApTitle absent. The requested Aptitle included in the request <ap-title> can have
1732the following values:
1733
1734 When the Master Relay Aptitle is pre-configured in the requesting node, the <called-aptitle-element>
1735 is set to this value. Every C12.22 Relay capable of forwarding information to this ApTitle shall return
1736 a Resolve response with its own ApTitle set as Calling ApTitle and its local address set as <local-
1737 address>.
1738 When the Master Relay Aptitle is auto-assigned , the requested ApTitle length is set to zero. Every
1739 C12.22 Relay that has Master Relay ApTitle Auto-Assignment capability shall return a Resolve
1740 response with its own ApTitle set as Calling ApTitle and its local address set as <local-address>.
1741
1742When responses arrive from more than one C12.22 Relay, the node as the option to register through one
1743of these C12.22 Relays or multiple C12.22 Relays. By registering with multiple C12.22 Relays, the nodes
1744increase its chances to be located and be serviced. A different ApTitle or sub-branch of the same Aptitle
1745shall be used to register to each C12.22 Relay. It’s the responsibility of the node that registers to multiple
1746C12.22 Relay to maintain each route to not become obsolete.
1747
1748Request:
1749
1750 <resolve> ::= 25H <ap-title> {ApTitle of the requested C12.22 Node.}
1751
1752Response:
1753
1754The resolve <uap> is returned when the caller's ApTitle is unknown by the requested C12.22 Relay. The
1755response <ok> indicates that the ApTitle has been found and its local address is returned.
1756
1757 <resolve-r> ::= <uap> |
1758 <ok> <local-address-length> <local-address>
1759
1760 <local-address-length> ::= <byte> {Length of <local-address> in bytes.}
1761
1762 <local-address> ::= <byte> + {Local address of the requested ApTitle}
1763
176435 Trace Service
1765
1766The Trace Service is used to retrieve the list of C12.22 Relays capable of forwarding C12.22 Messages
1767to a target C12.22 Node. This service is carried in an ACSE application data unit <acse-pdu> with the
1768Calling ApTitle set to the ApTitle of the node that have requested the trace and the Called ApTitle set to
1769the ApTitle of the node traced .
1770
1771Each time a C12.22 Relay receives this service request, it adds its own ApTitle to the list or C12.22
1772Relays stored in the Application Data Element, <application-data-element> then it forwards it to the next
1773C12.22 Relay. When the trace request reach the C12.22 Relay that have the target node as neighbor
1774(the node whose ApTitle matches the Called ApTitle), this C12.22 Relay shall include its ApTitle in the
1775list, replace the service code by a <ok> response code, set the Called ApTitle to the APTitle of target
1776node, set its own ApTilte as Calling ApTitle and return this information.
1777
1778It is important to note the Trace Service is not processed by the terminal nodes and does not need to be
1779implemented by these end nodes.
67 - XXXV -
68
1780
1781Request:
1782
1783 <trace> ::= 26H <ap-title>*
1784
1785Response:
1786
1787The response <nok> is returned when this request cannot be serviced. In this case, the response
1788contains a list of <ap-title>s of all C12.22 Relays traversed up to the point of failure; i.e., the last <ap-
1789title> is that of the C12.22 Relay rejecting the service request.
1790
1791
1792The response <ok> indicates that the Trace Service was successful and the response contains all C12.22
1793Relays used to forward this information.
1794
1795 <trace-r> ::= <nok> <ap-title>* |
1796 <ok> <ap-title>* {ApTitle of C12.22 Relays used to forward this service.}
1797
179836 Service sequence state control
1799
1800In a networking environment, the C12.22 Nodes may support one or multiple association at the same
1801time. Any association may be session oriented or sessionless. For each association supported, the
1802C12.22 Nodes shall conform to the following state:
1803
1804Off-line State: Normal state upon C12.22 Node power-up. This is also the state upon
1805 completion of a Terminate or a Link Control interface-disable service
1806 request. An Off-line State implies that the C12.22 Node is not present on the
1807 C12.22 Network Segment that services it.
1808
1809Idle State: Normal state upon an active or passive open of a network connection. A
1810 passive open implies that the C12.22 Node is ready to accept transactions
1811 from the network. An active open implies that the C12.22 Node is ready to
1812 initiate transactions to a peer C12.22 Node across the network.
1813
1814Sessionless State: State while processing transaction without entering the Session State.
1815
1816Session State: State achieved after a Logon Service has been accepted.
1817
1818
1819The relationship between PSEM services and service sequence states is:
1820
1821Identification: This service request is accepted at the Idle State only. Upon completion, the
1822 Application returns to the Idle State.
1823
1824Wait: This service request is accepted at the Session State only. Acceptance of
1825 this request does NOT result in any sequence state changes.
1826
1827Logon: This service request is accepted at the Idle State only. Acceptance of this
1828 request results in a transition to the Session State. This service is optional
1829 and not implemented when NBR_SESSION_SUPPORTED returned by the
1830 Identification Service is set to 0.
1831
1832Security: This service request is accepted at the Session Stateonly. Acceptance of this
1833 request does NOT result in any sequence state changes.
1834
1835Read and Write: These requests are accepted in Session Statewhen
1836 NBR_SESSION_SUPPORTED, returned by the Identification Service, is
69 - XXXVI -
70
1837 greater than zero. In this case, acceptances of these requests do NOT result
1838 in any sequence state changes.
1839
1840 They are also supported in Sessionless State when the
1841 SESSIONLESS_SUPPORTED, returned by the Identification Service, is set
1842 to TRUE. In this case, the Application returns to the Idle State.
1843
1844Logoff: This service request is accepted at the Session State only. Acceptance of
1845 this request results in a transition to the Idle State. This service is optional;
1846 however, it shall be supported if the Logon Service is also supported. The
1847 Logoff Service is a request to initiate a normal Session termination. This
1848 may be used by C12.22 Nodes to complete Session-related data processing
1849 following the successful termination of the Session.
1850
1851
1852Terminate: This service request is accepted at the Session State only. Acceptance of
1853 this request results in a transition to the Idle State. This service is optional;
1854 however, it shall be supported if the Logon Service is also supported. The
1855 Terminate Service is an abnormal Logoff Service. Upon completion, the
1856 C12.22 Node returns the Idle State.
1857
1858Disconnect: This optional service request is accepted in any state. When received in the
1859 Session State, an Application shall perform a Terminate Service then
1860 disconnect from the C12.22 Network. Upon completion, the C12.22 Node
1861 returns the Off-line State.
1862
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
1863
1864 Figure 6.2: C12.22 Host Application Layer State Diagram
1865
186637 Partial Table access using index/element-count Method
1867
18681. An index sets up a start of selection into a Table object relative to the beginning of the Table as
1869 follows:
1870
1871  Each member of a PACKED RECORD gets a unique number.
71 - XXXVII -
72
1872  The positional number of the first element of a PACKED RECORD is assigned the value zero.
1873  The positional number of subsequent elements in the same PACKED RECORD is incremented
1874 by one for each subsequent element in the PACKED RECORD.
1875  Each sub element of a BIT FIELD is assigned a unique positional number.
1876  The positional number of the first sub element of a BIT FIELD is assigned the value zero.
1877  The positional number of subsequent sub elements in the same BIT FIELD is incremented by
1878 one for each subsequent sub element in the BIT FIELD, independent of the bit range assigned to
1879 the sub element.
1880  Positional numbers are assigned independently of any IF or CASE statements that may be
1881 present inside PACKED RECORDs or BIT FIELDs, as if the elements or sub-elements where not
1882 enclosed within any IF or SWITCH statements.
1883  For non final elements one level of index is appended to the index of the parent’s element index
1884 for use in selections.
1885  Selection of Boolean members within a SET are referenced in the same manner as members of
1886 a single dimensional array.
1887  For elements of an ARRAY one level of index is appended to the index of the array’s element for
1888 each dimension (as per BNF.dim) for use in selections into entries of the ARRAY.
1889
18902. Selection based on an index method using <element-count> equal to one will deliver the whole
1891 selected element.
1892
18933. For the purpose of binary transmission, <index> + cannot select into a sub-element or final elements
1894 that are not atomic, with the exception of SETs, where the first octet selected for transmission is that
1895 computed by integer division of the atomic index number requested by eight (8), and the number of
1896 elements is the number of bits requested.
1897
18984. For the purpose of transmission, an indexed selection into a non-existing element shall result in an
1899 "Inappropriate Action Requested" error. However, it is allowed to append zeros at the end of an
1900 <index> + to indicate the desired access level of an indexed selection within the Table element
1901 hierarchy.
1902
19035. When <element-count> is greater than one, the application shall return up to <element-count>
1904 elements at the same or lower hierarchical level of the <index> + used to initiate the request
1905 traversing all element types serially.
1906
19076. When <element-count> is greater than the number of elements available for transmission, the
1908 number of elements transmitted will be limited to the maximum number elements available at the
1909 same or lower hierarchical level of the <index> + used to initiated the request..
1910
19117. The number of numeric segments that make up the <index> + defines the initial hierarchical level for
1912 element serialization and for <element-count> interpretation.
1913
19148. As a part of a Read Service request, <element-count> equal to zero shall be interpreted as ALL data
1915 starting from the <index> + to the end of the Table requested.
1916
19179. As a part of a response, <count> equal to zero shall be interpreted as NO data was received.
1918
191910. As a part of a Write Service request, <count> shall correctly represent the actual number of bytes to
1920 be written, including the optional pending header, at the hierarchical level of the selection start
1921 <index> +.
1922
192311. As a part of a Read Service request, <element-count> represents the maximum number of elements
1924 requested.
1925
192612. Any element excluded from the data stream through the use of the IF or CASE conditional
1927 statements shall not be a candidate for transmission and not be counted.
73 - XXXVIII -
74
1928
192913. Any element excluded from the data stream through the use of zero length ARRAYs, SETs,
1930 STRINGs, BINARYs or BCDs shall not be a candidate for transmission and not be counted.
1931
193214. Any element whose size is zero shall not be a candidate for transmission and not be counted.
1933
193415. The <element-count> counts elements and not octets.
1935
193616. If the respondent application does not support the transmission elements at the requested index
1937 level, or the respondent application cannot deliver the element requested from an ARRAY the
1938 respondent application shall assert the error condition "Inappropriate Action Requested". The
1939 requester may then attempt a retry of the Read or Write Service request on an <index> + of an
1940 element that is higher or lower in hierarchy relative to the <index> + of the failed attempt.
1941
1942Index Count Access Method Examples
1943
1944The following are examples for the use of the Index/Element-Count method to select data.
1945
Example 1 Example 2 Example 3 Example 4
<index> = 1.0 <index> = 1, <index> = 1.2.0, <index> = 1.2,
<element-count> = 2 <element-count> = 2 or <element-count> = 4 <element-count> = 4
<index> = 1.0, or
<element-count> = 4 <index> = 1.2.0,
<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
1946
194738 Partial Table access using offset/octet-count method
1948
19491. An <offset> sets up a start of selection into a Table object relative to the beginning of the Table.
1950
19512. <offset> zero (0) is the octet offset to the first octet of the first object in the Table as prescribed by the
1952 object data type and the value of DATA_ORDER, found in the GEN_CONFIG_TBL (Table 00).
1953
19543. When <count> is greater than one, the application shall return no more than <count> octets from
1955 <offset> used to initiate the request traversing all element types serially, where each element will be
1956 transferred according to its type and the value of DATA_ORDER, found in the GEN_CONFIG_TBL
1957 (Table 00).
1958
19594. When <count> is greater than the number of octets available for transmission, the number of octets
1960 transmitted will be limited to the maximum number octets available. The response <count> shall be
1961 adjusted to reflect the actual number of octets transferred in the response.
1962
19635. As a part of a request, <count> equal to zero shall be interpreted as ALL data starting from the
1964 <offset> to the end of the Table requested.
1965
19666. As a part of a response, <count> equal to zero shall be interpreted as NO data was received.
1967
75 - XXXIX -
76
19687. As a part of a Write Service request, <count> shall correctly represent the actual number of octets
1969 requested to be written starting at the Table offset requested including the optional pending header.
1970
19718. As a part of a Read Service request, <count> represents the maximum number of octets requested
1972 including the optional pending header.
1973
19749. Elements that are not present in the Table by virtue of them being excluded from the data stream
1975 through the use of zero length ARRAYs, SETs, STRINGs, BINARYs or BCDs shall not be candidates
1976 for transmission and not be counted.
1977
197810. Any element whose size is zero shall not be a candidate for transmission and not be counted.
1979
198011. The octet counter counts octets and not elements.
1981
198212. If the respondent application does not support the transmission octets at the requested offset if the
1983 respondent application shall assert the error condition "Inappropriate Action Requested”.
77 - XL -
78
1984
1985 39 Extended PSEM (EPSEM)
1986
1987The EPSEM structure and services extends PSEM. The extended structure enables transportation of
1988multiple requests and responses at the same time. It also provides response control and end device
1989class.
1990
1991 <epsem> ::= <epsem-control> [<ed-class>] <epsem-data>+ | 00H
1992
1993 <epsem-control> ::= <byte> {Datagram control field.
1994 Bit 6 to 7: APPLICATION_SPECIFIC_TAG
1995 Shall be equal to 2 (Bit 7=1, bit 6=0).
1996
1997 Bit 5: Reserved, shall be set to 0.
1998
1999 Bit 4: ED_CLASS_INCLUDED
2000 When set to true, <ed-class> is included in this <acse-
2001 pdu>. <ed-class> shall be included in all unsolicited
2002 messages and one-way messages.
2003
2004 Bit 2 to 3: Reserved
2005
2006 Bit 0 to 1: RESPONSE_CONTROL
2007 Used by request messages to control the return of
2008 corresponding responses.
2009 0 = Always respond
2010 1 = Respond on exception
2011 2 = Never respond
2012
2013 RESPONSE_CONTROL shall be set to 2 by all one-way
2014 C12.22 Nodes.}
2015
2016 <ed-class> ::= <byte> +4 {DEVICE_CLASS exactly as encoded in the General
2017 Configuration Table (Table 0) of ANSI C12.19 (Version
2018 2.0) or the MANUFACTURER code as defined in the
2019 General Configuration Table (Table 0) of ANSI C12.19-
2020 1997 (Version 1.0).}
2021
2022 <epsem-data> ::= <service-length> <req-res>
2023
2024 <service-length> ::= <byte> + {Length of <req-res> field, encoded as defined by the
2025 ISO 8825-1-1997. When <service-length> is zero then it
2026 signifies the end of the <epsem-data> list.}
2027
2028 <req-res> ::= <request> | <response>
2029 {PSEM request or response as defined in the previous
2030 section.}
2031
2032 <seg-data> ::= <byte> <app-data-length> The <app-data> content used to transmit an Application
2033 Sub-Layer <acse-pdu> segment. For more details see
2034 algorithm details in section “60 Application
2035 Segmentation Sub-Layer”.
79 - XLI -
80
2036
2037
2038 40 Association Control – Association Control Service Element (ACSE)
2039
2040EPSEM relies on the use of ACSE (ISO 8650-1-1995) to convey association and security parameters.
2041This includes the application context <application-context-element>, application process titles of called
2042and calling process <called-aptitle-element> and <calling-ap-title>, authentication information if a secure
2043transaction is required <mechanism-name-element> and <authentication-value-element>. The encoding
2044of the elements of ACSE is based on ISO 8825-1-1997, although represented herein using a BNF
2045notation. (Need to add additional references for APTitle and AETitle.)
2046
2047The following syntax represents a conformant subset of those fields defined in the ACSE standards for
2048the services used. When required or optional components of ACSE are present they shall appear in the
2049order presented below.
2050
2051 <acse-pdu> ::= 60H
2052 <elements-length>
2053 <elements>
2054
2055 <elements-length> ::= <byte> + {Length of <elements>, encoded as defined by the ISO
2056 8825-1-1997}
2057
2058 <elements> ::= <unsegmented-acse-elements> |
2059 <segmented-acse-elements>
2060
2061 {The <acse-pdu> that make up a fully assembled
2062 application layer data unit.}
2063 <unsegmented-acse-elements> ::=
2064 [ <application-context-element> ]
2065 [ <called-aptitle-element> ]
2066 [ <calling-aptitle-element> ]
2067 [ <calling-entity-qualifier-element> ]
2068 [ <mechanism-name-element> ]
2069 [ <authentication-value-element> ]
2070 [ <called-apinvocation-id-element> ]
2071 <calling-apinvocation-id-element>
2072 <user-information-element>
2073
2074 {The <acse-pdu> that make up a single application sub-
2075 layer data unit segment. For more details see
2076 “Application Segmentation Sub-layer”.}
2077 <segmented-acse-elements> ::=
2078 [ <application-context-element> ]
2079 [ <called-aptitle-element> ]
2080 [ <calling-aptitle-element> ]
2081 [ <calling-entity-qualifier-element> ]
2082 <segment-calling-apinvocation-id-element>
2083 <segment-user-information-element>
2084
208541 Application Context Element (A1H)
2086
2087The Application Context Element <app-context-element> is used to uniquely identify the ANSI C12.22
2088Application from any other Application Layer that use ACSE. This uniqueness is guaranteed by the use of
2089a registered Universal Identifier. This specification allows messages that do not include the Universal
2090Identifier. This can be done for efficiency reasons; only on network segments dedicated to the ANSI
81 - XLII -
82
2091C12.22 application (e.g. a homogeneous C12.22 Network), and must be reinserted when relayed to a
2092heterogeneous application network where ACSE frames of other contexts may be present.
2093
2094 <application-context-element> ::= A1H <app-context-length> <app-context>
2095
2096 <app-context-length> ::= <byte> + {Length of <app-context>, encoded as defined by the
2097 ISO 8825-1-1997}
2098
2099 <app-context> ::= <universal-id-element>
2100 {Object identifier representing this Application Layer
2101 (ANSI C12.22). This value shall be set to 1.2.840.10066
2102 and encoded as:
2103 06 05 2A 86 48 CE 52H.}
2104
210542 Called AP Title Element (A2H)
2106
2107The Called AP Title Element <called-ap-title> uniquely identifies the target of an ACSE message. This
2108uniqueness is guaranteed by the use of a absolute or relative Universal Identifier. Relative Universal
2109Identifiers are derived from the ANSI C12.22 ApTitle branch (2.16.840.1.114223) and are described in
2110section “55 Universal Identifiers Encoding”.
2111
2112 <called-aptitle-element> ::= A2H <called-aptitle-length> <called-aptitle>
2113
2114 <called-aptitle-length> ::= <byte> + {Length of <called-aptitle> encoded as defined
2115 by the ISO 8825-1-1997}
2116
2117 <called-aptitle> ::= <universal-id-element> | <relative-uid-element>
2118
211943 Calling AP Title Element (A6H)
2120
2121The Calling AP Title Element <calling-ap-title> uniquely identifies the initiator of an ACSE message. This
2122uniqueness is guaranteed by the use of a absolute or relative Universal Identifier. When relative then it is
2123derived from the ANSI C12.22 ApTitle branch (2.16.840.1.114223).
2124
2125 <calling-aptitle-element> ::= A6H <calling-aptitle-length> <calling-aptitle>
2126
2127 <calling-aptitle-length> ::= <byte> + {Length of <calling-aptitle> encoded as defined
2128 by the ISO 8825-1-1997}
2129
2130 <calling-aptitle> ::= <universal-id-element> | <relative-uid-element>
2131
213244 Universal Identifier (06H)
2133
2134A Universal Identifier <universal-id> uniquely identifies a network address, Application Layer, or security
2135mechanism. (See section “55 Universal Identifiers Encoding” for more information.)
2136
2137 <universal-id-element> ::= 06H <universal-id-length> <universal-id>
2138
2139 <universal-id-length> ::= <byte> + {Length of <universal-id>, encoded as defined by the
2140 ISO 8825-1-1997}
2141
2142 <universal-id> ::= <byte> + {Object identifier encoded as described in ISO 8825-1-
2143 1997 [BER]}
2144
214545 Relative Universal Identifier (0D H)
2146
83 - XLIII -
84
2147 For efficiency reason, Relative Universal Identifiers <relative-uid-element> can be used to identify
2148 network addresses. Relative UIDs are unique only within
2149 ANSI C12.22 Nodes.
2150
2151 <relative-uid-element> ::= 0DH <relative-uid-length> <relative-uid>
2152
2153 <relative-uid-length> ::= <byte> + {Length of <relative-uid>, encoded as defined by the
2154 ISO 8825-1-1997}
2155
2156 <relative-uid> ::= <byte> + {Relative object identifier encoded as described in ISO
2157 8825-1-1997.}
2158
215946 Calling Application Entity Qualifier Element (A7 H)
2160
2161The <calling-entity-qualifier-element> is an optional element used to qualify the information transferred
2162by the application layer entity.
2163
2164 <calling-entity-qualifier-element> ::= A7H <calling-ae-qualifier-length>
2165 <calling-ae-qualifier>
2166 {The calling application entity qualifier. When the target
2167 device does not support this type of element
2168 qualification it will ignore it with no error. The initiator of
2169 the service can identify if the target supports this
2170 element by the presence of this element in the
2171 response.}
2172
2173
2174 <calling-ae-qualifier-length> ::= <byte> +
2175 {Length of <calling-ae-qualifier>, encoded as defined by
2176 the ISO 8825-1-1997}
2177
2178 <calling-ae-qualifier> ::= 82H <ae-qualifier-length> <ae-qualifier-value>
2179
2180 <ae-qualifier-length> ::= <byte> + {Length of <ae-qualifier-value>, encoded as defined by
2181 the ISO 8825-1-1997}
2182
2183 <ae-qualifier-value> ::= <byte>+ {Application entity qualifier value:
2184 Bit 0 : TEST
2185 Messages tagged with the calling application entity
2186 value bit 0 set to 1. The called C12.22 Node shall ignore
2187 this flag if it does not support the test feature. Otherwise
2188 it shall process the test message in such a manner that
2189 it does not affect the operation or the end state of the
2190 called node; then it shall include a <calling-entity-
2191 qualifier-element> in its response <acse-pdu> with bit 0
2192 set to 1 (response <acse-pdu> is a test response, thus
2193 acknowledging the fact that it supports tests).
2194
2195 Bit 1 : URGENT
2196 Messages tagged with the calling application entity
2197 value bit 1 set to 1 are expected to be forwarded by all
2198 C12.22 Relays and acted upon by the called C12.22
2199 Node urgently (high priority).
2200
2201 Bit 2: NOTIFICATION
2202 When set to true, the <acse-pdu> contains services that
2203 shall be interpreted as notification of information issue
85 - XLIV -
86
2204 by the initiator of this message. All unsolicited
2205 notification shall also include the <epsem>s <ed-class>,
2206 i.e. <epsem-control>s ED_CLASS_INCLUDED bit shall
2207 be set to true. When NOTIFICATION is set to true it is
2208 an indication that the information supplied in the <acse-
2209 pdu>s <user-information-element> is about the calling
2210 C12.22 Node using the operating model indicated by
2211 provided <ed-class>. When NOTIFICATION is cleared
2212 to zero, this is information for the called C12.22 Node.
2213
2214 Bit 3 to 7: Reserved.}
2215
221647 Mechanism Name Element (ABH)
2217
2218The Mechanism Name Element <mechanism-name> uniquely identifies the security mechanism used in
2219the containing <acse-pdu>. This uniqueness is guaranteed by the use of a registered Universal Identifier.
2220This element identifies the format of the Authentication Value Element <authentication-value-element>
2221and Application Data Element <app-data> and security algorithms involved. This element is optional and
2222when not included, the default security mechanism defined by this document applies.
2223(1.2.840.10066.2.1)
2224
2225 <mechanism-name-element> ::= ABH <mechanism-name-length> <mechanism-name>
2226
2227 <mechanism-name-length> ::= <byte> + {Length of <mechanism-id> encoded as defined by the
2228 ISO 8825-1-1997}
2229
2230 <mechanism-name> ::= <universal-id> {Object identifier representing the security mechanism
2231 used.}
2232
223348 Authentication Value Element (ACH)
2234
2235The discussion in this section applies only to any <acse-pdu> identified as following the <mechanism-
2236name> 1.2.840.10066.2.0 and 1.2.840.10066.2.1.
2237
2238The Authentication Value Element <authentication-value-element> is used to carry encryption and
2239authentication parameters. This element is optional, and when not included or when it contains an <auth-
2240value-c1221-0>, <app-data> is transmitted unencrypted (note in this case the fields <mac> and
2241<padding> in <user-information-element> is not included – see section ”53 Application Data Element
2242(BEH)”.
2243
2244The structure and content of the <authentication-value-element> is implied by the value of the
2245<authentication-mechanism-name> identified in the message (either included or default).
2246
2247When <auth-value-c1222>is included, the <acse-pdu> is either encrypted (when the <message-
2248authentication-token> is not present) or authenticated (when the <message-authentication-token> is
2249present). The requester may change its access rights, in session-less requests, by including the <user-
2250element> in the <auth-value-c1222>.
2251
2252Protocol for the exchange of the contents of <authentication-value-element> are described in section “57
2253C12.22 Security Mechanism”. If the default c12.22 <authentication-mechanism-name> is in effect, the
2254following describes the content of the <authentication-value-element> (other <authentication-
2255mechanism-name> values may imply entirely different content for the <authentication-value-element>
2256and the protocols for its usage):
2257
2258 <authentication-value-element> ::= ACH <auth-value-length>
2259 <auth-value-c1221-0> |
87 - XLV -
88
2260 <auth-value-c1222> |
2261 <auth-value-other>
2262
2263 <auth-value-length> ::= <byte> + {Length of <auth-value> encoded as defined by the ISO
2264 8825-1-1997}
2265
226649 C12.22 Security Mechanism (1.2.840.10066.2.1)
2267
2268 <auth-value-c1222> ::= [ <key-id-element> ]
2269 [ <iv-element> ]
2270 [ <user-element> ]
2271 [ <message-authentication-token> ]
2272 {Authentication encoding when using the ANSI C12.22
2273 native mechanism name is 1.2.840.10066.2.1}.
2274
2275 <key-id-element> ::= A0H <key-id-length> <key-id>
2276
2277 <key-id-length> ::= <byte> + {Length of <key-id> encoded as defined by the ISO
2278 8825-1-1997}
2279
2280 <iv-element> ::= A1H <iv-length> <iv>
2281
2282 <iv-length> ::= <byte> + {Length of <iv> encoded as defined by the ISO 8825-1-
2283 1997}
2284
2285 <key-id> ::= <byte> {Identifies the key used to encrypt and decrypt the
2286 information. This value is matched with an entry in the
2287 KEY_ENTRIES array located in the Security Table
2288 (Table 45, KEY_TBL or Table 46,
2289 EXTENDED_KEY_TBL) of the target C12.22 Node. This
2290 element is optional and when not provided, <key-id> 0
2291 shall be used.
2292
2293 The <key-id> may be different in each C12.22 Message
2294 transmitted. The <key-id> used in a request may be
2295 different than the <key-id> used in the response
2296 message.}
2297
2298 <iv> ::= <byte> + {Initialization vector facilitates rejection of recorded and
2299 replayed messages. The length of this field can be either
2300 4 or 8 bytes. When only 4 bytes are provided, these are
2301 duplicated to produce the 8 bytes required. During
2302 session less communication, this element carry the
2303 randomly generated number used to encrypt or
2304 authenticate the <acse-pdu>. No relationship are
2305 implied between the <iv> included in the request and
2306 the associated response.
2307
2308 For session oriented communication, only the Logon
2309 request and the Logon response carry an <iv> element.
2310 Any subsequent requests and responses within a
2311 session use the <iv> initially received during the login
2312 service pre-incremented by 1. This technique is used to
2313 provide playback rejection of messages exchanged after
2314 the initial login service. Duplicate messages are
2315 detected using the <calling-apinvocation-id-element>
2316 and rejected before pre-incrementing the <iv>.}
89 - XLVI -
90
2317
2318
2319 <user-element> ::= A2H <user-mac> <user-id> <password>
2320 {This element is optional and shall be used only in
2321 sessionless transaction to modify access privileges. This
2322 element is decrypted independently of the <user-
2323 information>.}
2324
2325 <user-mac> ::= <word16> {This message authentication code is a CRC used for
2326 decryption validation. This CRC applies to the remainder
2327 of the <user-element> that includes <user-id> and
2328 <password>. This CRC uses the same algorithm as
2329 ANSI C12.18-1996, HDLC implementation of the
2330 polynomial X16 + X12 + X5 + 1}
2331
2332 <user-id> ::= <word16> {User identification code}
2333
2334 <password> ::= <byte> + {20 byte field containing password}
2335
2336 <messages-authentication-element> ::= A3H <auth-token-length> <msg-auth-token>
2337
2338 <auth-token-length> ::= <byte> {Length of <auth-token> encoded as defined by the ISO
2339 8825-1-1997. This field is set to 8.}
2340
2341 <msg-auth-token> ::= <calling-info-mac> <app-data-mac>
2342 <random-header> 00H 00H
2343 {This field is used to authenticate the initiator of this
2344 message and to verify that the <app-data> received was
2345 not altered. Two bytes set to zero are added to pad this
2346 field to 8 bytes.}
2347
2348 <calling-info-mac> ::= <word16> {CRC of the concatenation of <random-header>,
2349 <calling-aptitle>, <calling-ae-qualifier> and the <calling-
2350 apinvocation-id>. Since the <random-header> is
2351 encrypted, it is impossible to determine this CRC strictly
2352 based on <acse-pdu> content. This CRC uses the same
2353 algorithm as ANSI C12.18-1996. It is not required for a
2354 C12.22 Node to validate this CRC for each message
2355 received, however it is required to set this field for each
2356 message sent.}
2357
2358 <app-data-mac> ::= <word16> {CRC of the concatenation of the <random-header> and
2359 the <app-data>. Since the <random-header> is
2360 encrypted, it is impossible to determine this CRC strictly
2361 based on the content of the <app-data>. This CRC uses
2362 the same algorithm as ANSI C12.18-1996.}
2363
2364 <random-header> ::= <word16> {Two bytes of random values.}
2365
2367
2368 <auth-value-c1221-0>::= <auth-length> <auth-request> | <auth-response>
2369 {Authentication encoding when using the ANSI C12.22
2370 compatibility mode for ANSI C12.21 Authentication
2371 Service (53H) selected by mechanism name
2372 1.2.840.10066.2.0.
91 - XLVII -
92
2373 This ANSI C12.21 compatible authentication mechanism
2374 element shall only be issue in conjunction with a Logon
2375 service request, a Logon Service response or an
2376 Identification Service response. This element is used to
2377 provide a two-way authentication with playback rejection
2378 during a session. The contents of the <auth-request>
2379 and <auth-response> fields are a function of the
2380 authentication algorithm used. This algorithm is identical
2381 to ANSI C12.21 Encryption Algorithm 00H.}
2382
2383
2384 <auth-length> ::= <byte> {Length of <auth-request> or <auth-response> field
2385 encoded as defined by the ISO 8825-1-1997. This value
2386 shall not be greater than 255.}
2387
2388 <auth-request> ::= <byte> * {In conjunction with a Logon Service request it is the
2389 information used to authenticate the sender of this
2390 <acse-pdu> according to the authentication protocol of
2391 ANSI C12.21. This field is encoded as <auth-request>
2392 per ANNEX H of ANSI C12.21.}
2393
2394 <auth-response> ::= <byte> * {In conjunction with a Logon Service response it is the
2395 information used to authenticate the responder of the
2396 Logon according to the authentication protocol of ANSI
2397 C12.21. The length of this field shall be set to zero if the
2398 Logon request returns an error. When the Logon
2399 response is <ok> it is also an indication that the
2400 authentication was successful. When associated with a
2401 Logon Service response, the field is encoded as <auth-
2402 response> per ANNEX H of ANSI C12.21.
2403
2404 In conjunction with an Identification Service response, it
2405 is the ANSI C12.21 ticket value to be used by the
2406 authentication algorithm in conjunction with a Logon
2407 Service request which follows. When associated with an
2408 Identification Service response, the field is encoded as
2409 <ticket> per ANNEX H of ANSI C12.21.}
2410
2411 <auth-value-other> ::= <byte>* {Authentication encoding when using a ANSI C12.22
2412 registered mechanism name identifier
2413 1.2.840.10066.2.n, (where n > 1).
2414
2415
241651 Called Invocation ID Elements (A4 H)
2417
2418The Called Invocation ID element <called-apinvocation-id-element> provides the called entity Application
2419Layer with information about another (past) APDU which is related to this APDU. A likely user of this
2420capability may be an entity which was requested to respond on exception, or a C12.22 Relay which
2421responds with a <nok> code as a result of a request that could not be processed to completion. It is also
2422provided in an <ok> response to identify the APDU which was the trigger of this APDU response.
2423
2424The <called-apinvocation-id-element> shall be placed before the <user-information-element>.
2425
2426<called-apinvocation-id-element> ::= A4H <assoc-apdu-id-length> <assoc-apdu-id>
2427
2428 {The <called-apinvocation-id-element> is associated
2429 with the recipient of this APDU. It uniquely binds this
93 - XLVIII -
94
2430 APDU to another APDU that was sent originally by the
2431 Application Layer of the recipient of this ACSE
2432 message. The uniqueness of the binding is established
2433 by matching the called and calling ApTitles of this APDU
2434 with the members of the <assoc-apdu-id>. The actual
2435 encoding rules of <assoc-apdu-id> are identical to those
2436 of <apdu-id> of <calling-apinvocation-id-element>.}
2437
2438 <assoc-apdu-id-length> ::= <byte>+ {Length of <assoc-apdu-id> encoded as defined by the
2439 ISO 8825-1-1997}
2440
2441 <assoc-seg-id> ::= <assoc-apdu-seq-number>
2442 {It conveys association information about an APDU that
2443 was originally issued by the called entity Application
2444 Layer.}
2445
244652 Calling Invocation ID Elements (A8H)
2447
2448The Calling Invocation ID elements <calling-apinvocation-id-element> provides for duplicate APDU
2449rejection and APDU Segmentation at the Application Segmentation Sub-Layer (For further details on
2450segmentation see “60 Application Segmentation Sub-Layer”).
2451
2452The <calling-apinvocation-id-element> shall be placed before the <user-information-element>.
2453
2454 <calling-apinvocation-id-element> ::= A8H <apdu-id-length> <apdu-id>
2455 {The <calling-apinvocation-id-element> is associated
2456 with the originator of an ACSE message that was sent
2457 by the Application Layer of the originator of this ACSE
2458 message. The binding is temporary and it shall last only
2459 for the duration of the duplicate Datagram recognition
2460 period.}
2461
2462 <apdu-id-length> ::= <byte> + {Length of <apdu-id> encoded as defined by the ISO
2463 8825-1-1997}
2464
2465 <apdu-id> ::= <apdu-seq-number>
2466 {Conveys information about the containing Datagram
2467 and the <user-data> content of <user-information-
2468 element>.}
2470 <apdu-sequence-number> ::= <word16>

2471 {A number that is initially created by the Application
2472 Layer.
2473
2474 The Application Layer shall supply a <apdu-sequence-
2475 number> upon construction of an initial <acse-pdu>; and
2476 it shall use this element to reject Application Layer
2477 duplicate APDUs. The <apdu-sequence-number> is
2478 randomly selected during C12.22 Node’s initialization
2479 then it gets changed each time a new un-segmented
2480 APDU is created by the Application Layer. This value
2481 shall not repeat within one minute.}
2482
248353 Application Data Element (BEH)
2484
95 - XLIX -
96
2485The Application Layer Data Element <user-information> is used to carry one or multiple PSEM requests
2486or responses.
2487
2488 <user-information-element> ::= BE H <app-data-length> <app-data>
2489
2490 <app-data-length> ::= <byte> + {Length of <app-data> encoded as defined by the ISO
2491 8825-1-1997}
2492
2493 <app-data> ::= [<mac>] <epsem> [<padding>]
2494
2495 <mac> ::= <word16> {CRC of the concatenation of <epsem> <padding>,
2496 <calling-aptitle>, <calling-ae-qualifier> and <calling-
2497 apinvocation-id>. This field is used for decryption
2498 validation and calling information authentication. This
2499 CRC uses the same algorithm as ANSI C12.18-1996,
2500 HDLC implementation of the polynomial X16 + X12 + X5 +
2501 1}
2502
2503 <padding> ::= <byte>* {One or more bytes added to the end of the <epsem>
2504 message to facilitate message segmentation and size as
2505 required by the encryption algorithm. The first byte of
2506 padding must be 0 to identify the end of the requests
2507 and responses list <epsem-data>*. The other padding
2508 bytes can be set to any random pattern.}
2509
251054 Length Fields Encoding
2511
2512As defined in the previous section, all length fields are encoded using the ISO 8825-1-1997. This
2513encoding is defined as follow:
2514
2515For values between 0 and 127, length fields are encoded using the short form. This form consists of a
2516single byte representing the length of the subsequent message in octets.
2517
2518For values greater than 127, length fields are encoded using the long form. This form consists of one
2519byte with bit 7 set to one and bits 0 to 6 set to the number of additional octets, which follow. Additional
2520octets represent the length encoded with most significant octet appearing first.
2521
2522Examples:
2523Short form: 2CH represent a length of 2CH or 44
2524Long form: 82H 01H 26H represent a length 0126H or 294
2525Long form: 81H 80 represent a length of 80H or 128
2526
252755 Universal Identifiers Encoding
2528
2529This specification uses Universal Identifiers to represent the <context-id> and the <universal-id>
2530contained in both the <calling-aptitle> and <called-aptitle>. A Universal Identifier is a list of values
2531externally represented as follow:
2532
2533 value1 .value2. … .value n. … .valuem
2534
2535To guaranty the uniqueness of this identifier over all possible applications, the leading (left most) n
2536values are obtained from an official registration body like the International Organization for
2537Standardization (ISO). Any values following (branches of) this unique prefix (root) can be assigned
2538locally by the owner of this prefix.
2539
97 -L-
98
2540Universal identifier is encoded using the Basic Encoding Rules (BER) (IEC standard 8825) object
2541identifier encoding. This encoding is defined as follow:
2542
2543 The first octet has value 40 x value1 + value2. (This is unambiguous, since value1 is limited to values
2544 0, 1, and 2; value2 is limited to the range 0 to 39)
2545 The following octets, if any, encode value3, …, valuen. Each value is encoded base 128, most
2546 significant digit first, with as few digits as possible, and the most significant bit of each octet except
2547 the last in the value's encoding set to one.
2548
2549For efficiency, it is possible to encode Universal Identifier as relative to the official ANSI C12 root. In that
2550case, only the branch of ANSI C12 root (2.16.840.1.114223) is included in the Calling or Called ApTitle.
2551
2552Example:
2553Calling ApTile = 2.16.840.1.114223.156.5454
2554Absolute ApTitle encoding = A2 0D A2 0B 60 86 48 01 86 FC 2F 81 1C AA 4E
2555Relative ApTitle encoding = A2 06 0D 04 81 1C AA 4E
2556
99 - LI -
100
2557
255856 Use of Sub-Branches of a Registered ApTitle
2559
2560Any sub-branch of the registered root ApTitle can be used to communicate with the C12.22 Node, which
2561registered that root under controlled conditions. All sub-branches are assumed to be registered and
2562managed by the root ApTitle holder as long as the root ApTile is registered. There are three sub-branch
2563categories supported by the Standard
2564
25651. Assigned Sub-branch: Those sub-branches whose function and numeric values are assigned
2566 by the standard. Sub-branches 0 to 15 are reserved for this purpose.
25672. Reserved Sub-branch: Those sub-branches whose function and numeric values are assigned by
2568 the vendor application of the C12.22 Node. Sub-branches 16 to 31 are
2569 reserved for this purpose.
25703. Dynamic Sub-branch: Those sub-branches that are assigned dynamically by the C12.22 Node.
2571 Sub-branches starting at 32 are reserved for this purpose
2572
2573When a C12.22 Device received a message targeted to an unsupported sub-branch, the node shall
2574return an <uat> Unknown Aptitle error response.
2575
2576
2577Sub-branches are used for the efficient facilitation of the following:
2578
2579Access to Interfaces and Local Ports
2580
2581Reserved Sub-branches were assigned by the Standard to access the C12.22 Devices’ Local Ports and
2582C12.22 Communication Modules’ interfaces. These values are pre-assigned as follows:
2583
Branch Description
relay-ap-title.0 or Defined for broadcast and multicast addressing as defined by Annex
relay-ap-title.0.group D.
registered-ap-title.1 or These sub-branches provide access to C12.22 Communication
registered-ap-title.1.interface Module tables of a C12.22 Node. The default Communication Module
assigned sub-branch is .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.804.1.114223.69.987”, the default interface can be accessed
using the ApTitle “2.16.804.1.114223.69.987.1” and the second
interface can be accessed using the ApTitle
“2.16.804.1.114223.69.987.1.2”.
registered-ap-title.2 or These sub-branches provide access to the application entity of a
registered-ap-title.2.local-port device attached to a Local Port. The default Local Port assigned sub-
branch is .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
“2.16.804.1.114223.69.987”, the default local port can be accessed
using either the ApTitle “2.16.804.1.114223.69.987.2” or
“2.16.804.1.114223.69.987.2.0”.
2584
2585
2586Mailbox
2587
2588Reserved Sub-branches were assigned by the Standard to identify common mailbox. These values are
2589pre-assigned as follows:
101 - LII -
102
2590
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.
2591
2592Multiple Associations
2593
2594The use of sub-branches also facilitates the management of concurrent associations from the same
2595targets and initiators. Both the initiator and the target C12.22 Nodes sharing an association may assign a
2596un-reserved sub-branch for their ApTitle. In this case, the initiator assigns a sub-branch of its calling
2597ApTitle then it uses the target’s root ApTitle as the called ApTitle. The target may respond with its called
2598ApTitle or assign a new sub-branch for its called ApTitle for subsequent exchanges.
2599
2600Example of multiple sessions that use sub-branches:
2601
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.
2602
2603
2604Proxy Server
2605
2606A C12.22 Relay can also act as a proxy server for C12.22 Nodes that are clustered on the same local
2607network segment of the C12.22 Relay. This service is initiated by any C12.22 Node when it sends a
2608<acse-pdu> to the Proxy Relay without including its own calling ApTitle element in the <acse-pdu>. The
2609Relay can either reject this message by returning <onp> or it can dynamically assign one of its dynamic
2610sub-branches as the calling ApTitle then forward the resulting <acse-pdu> to its destination. Messages
2611that are directed to that dynamically assigned sub-branch are forwarded by the C12.22 Relay to the
2612corresponding clustered node.
2613
2614Dynamically assigned sub-branches shall remain assigned to the same C12.22 Node for the duration of
2615the connection (in a connected environment) or a limited time (in a connectionless environment) before it
2616is returned to the available sub-branches. The choice of this timing value is left to the C12.22 Relay
2617developer.
2618
103 - LIII -
104
2619
262057 C12.22 Security Mechanism
2621
2622This section defines the security mechanisms used when the Mechanism Name Element <mechanism-
2623name> is set to a value that is well-known to ANSI C12.22. This is the case when an ACSE message
2624explicitly includes a Mechanism Name Element <mechanism-name> as follows:
2625  1.2.840.10066.2.0 for ANSI C12.22 compatibility mode with ANSI C12.21 Authentication
2626 algorithm 00H according to ANSI Std X3.92-1981: Data Encryption Algorithm and ANSI Std
2627 C12.21 APPENDIX H – Data Encryption Standard; or
2628  1.2.840.10066.2.1 for ANSI C12.22 native mechanism as defined in this document;
2629
2630The ANSI C12.22 native mechanism (1.2.840.10066.2.1) is selected by default when no <mechanism-
2631name> is provided together with the Application Context Element <app-context-element> value set to
26321.2.840.10066.
2633
2635
2636Security Modes
2637
2638The C12.22 Security mechanism support transport of messages in plain text, authenticated or encrypted.
2639
2640When no Authentication Value Element <authentication-value-element> is present, the <app-data> is
2641transmitted unencrypted with neither <mac> nor <padding> inserted.
2642
2643When the Authentication Value Element <authentication-value-element> is present and the <messages-
2644authentication-element> is not present, the <app-data> is transmitted encrypted and a <mac> field is
2645inserted. Padding <padding> can also be inserted to set the length on the encrypted data <app-data> to
2646a multiple of 8 octets. The first padding byte shall be set to 0 to identify the end of the requests and
2647responses list <epsem-data>*.
2648
2649When both the <authentication-value element> and the <messages-authentication-element> are present,
2650the message is authenticated and the <app-data> is transmitted unencrypted with niether <mac> nor and
2651<padding> inserted.
2652
2653Rules For Responses
2654
2655As a rule, the target of a session less request always responds using the mode (plain text, authenticated
2656or encrypted) as requested unless it has been configured to reject it.
2657
2658During a session, the target always returns responses using the mode used by the initial Logon request
2659unless it has been configured to reject it. The security mode can not be modified during a session.
2660
2661Key ID
2662
2663The key used to encrypt the information is identified by the <key-id-element>. This element is optional
2664and when not provided, key id 0 is used. The key also defines the algorithm to use to decrypt the
2665information. Finally the Initialization Vector is provided by the <iv-element>. Implementation examples
2666that use these three parts of information to produce a cipher text is provided in “ANNEX J – DES/CBC
2667and DESede/CBC”.
2668
2669User ID and Password
2670
2671During sessionless transaction, it is possible to establish access privileges by providing a user ID and a
2672password. These parameters are transported encrypted in the <user-element>.
2673
2674Initialization Vector
105 - LIV -
106
2675
2676The only constraint on the value of the Initialization Vector, <iv>, is to be always be different for the life
2677of the C12.22 Node. Within a session (Following a Logon Service Response up to the next Logoff
2678Service Response inclusive), no <iv> is transmitted. Each side shall use the Initialization Vector received
2679during the Logon Service by the other end. This <iv> is incremented before each new Datagram
2680transmitted.
2681
Requestor Target
Logon request
(included <iv> set to 2159A3C7H)
Request accepted
(use <iv> = 2159A3C7H)
Logon response sent
(included <iv> set to 43508E34H)
Logon response accepted
(use <iv> = 2159A3C7H)
Next request sent
(no <iv> provided)
Request accepted
(use iv 43508E35H)
Next response sent
(no <iv> provided)
Response accepted
(use iv 2159A3C8H)
Next request sent
(no <iv> provided)
Request accepted
(use iv 43508E36H)
…
2682
107 - LV -
108
2683The following examples used DES as cipher and 043E4373202D8727 as encryption key.
2684
2685Authenticated session less example
2686
2687This example shows an exchange of authenticated messages where the <user-element> is included in
2688the request.
2689
Requestor (values in hexadecimal) Target (values in hexadecimal)
Read request
60 44 A2 04 0D 02 02 04 A6 05 0D 03
02 A4 7C AC 2A A1 04 42 82 A5 1B A2
18 BE 94 8B 28 8F 30 5D C3 64 DB 37
BB 59 2D 31 CD 56 0B B2 29 6B AB DA
90 A3 08 E6 08 CE DD 63 6B B4 56 A8
02 00 00 BE 05 80 03 30 00 05
Read response
60 3F A6 04 0D 02 02 04 A2 05 0D 03
02 A4 7C AC 10 A1 04 42 82 A5 2B A3
08 A5 C1 A7 FE 56 EF AD E4 A4 02 00
00 BE 1A 80 18 00 00 14 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 80
2690
2691Encrypted session less example
2692
2693This example shows an exchange of encrypted messages where the <user-element> is included in the
2694request.
2695
Read request
60 3D A2 04 0D 02 02 04 A6 05 0D 03
02 A4 7C AC 20 A1 04 42 82 A5 08 A2
18 46 4F 5D 25 E6 4B A7 8E 7A 52 55
DF EB 68 1B 05 D2 7E 5E CC 8A 20 36
19 A8 02 00 01 BE 08 7E B2 0A A1 30
94 B4 F4
Read response
60 3B A6 04 0D 02 02 04 A2 05 0D 03
02 A4 7C AC 06 A1 04 42 82 A5 38 A4
02 00 01 BE 20 4D F4 5F C5 F6 DD C3
B9 88 93 DC 29 42 C6 15 AD E4 17 E6
0C DC C4 5E F6 46 29 E9 DC DA 05 56
45
2696
109 - LVI -
110
2697
2698Authenticated session example
2699
2700This example shows a message log of an authenticated session.
2701
Logon request
60 34 A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 10 A1 04 42 82 A9 C0 A3
08 6B A0 84 8C 1A E9 4A B6 A8 02 00
04 BE 0F 80 0D 50 00 02 20 20 20 20
20 20 20 20 20 20
Logon response
60 28 A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 10 A1 04 42 82 A9 90 A3
08 DC 11 88 3B F2 E4 56 18 A4 02 00
04 BE 03 80 01 00
Security request
60 36 A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 0A A3 08 98 F6 ED CB 2E
A6 BB AD A8 02 00 05 BE 17 80 15 51
4D 69 63 68 65 6C 20 56 65 69 6C 6C
65 74 74 65 20 20 20 20
Security response
60 22 A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 0A A3 08 DF 43 61 FC 4E
A2 D6 FC A4 02 00 05 BE 03 80 01 00
Read request
60 24 A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 0A A3 08 76 2A BB 0F 31
55 60 DF A8 02 00 06 BE 05 80 03 30
00 05
Read response
60 39 A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 0A A3 08 96 48 49 9D 53
22 D7 F8 A4 02 00 06 BE 1A 80 18 00
00 14 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 80
Logoff request
60 22 A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 0A A3 08 57 D3 CA 41 85
FA 9B F8 A8 02 00 07 BE 03 80 01 52
Logoff response
60 22 A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 0A A3 08 39 9E 86 37 56
AE CA 23 A4 02 00 07 BE 03 80 01 00
2702
111 - LVII -
112
2703
2704Encrypted session example
2705
2706This example shows a message log of an encrypted session.
2707
Logon request
60 33 A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 06 A1 04 42 82 A8 77 A8
02 00 00 BE 18 EF FD 3D 20 44 CE A2
11 4F 67 42 F2 09 A3 41 C1 40 21 33
C5 FD 6F 87 7F
Logon response
60 23 A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 06 A1 04 42 82 A8 27 A4
02 00 00 BE 08 65 FD 4D C0 D8 D2 97
B9
Security request
60 35 A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 00 A8 02 00 01 BE 20 9F
9C AD 6B D6 F7 AD 07 40 CA 73 49 88
70 A5 92 38 AC 8B 1A 73 31 B6 54 52
33 7F 9B 91 39 D0 56
Security response
60 1D A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 00 A4 02 00 01 BE 08 26
BF 6F 8B B4 F3 F9 98
Read request
60 1D A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 00 A8 02 00 02 BE 08 06
4A 12 55 64 11 10 D2
Read response
60 35 A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 00 A4 02 00 02 BE 20 70
B3 9E 82 AE B2 24 F5 B7 5C E2 52 98
27 AB 58 EF 34 37 E6 42 EB 0D C6 A3
19 33 67 D9 79 77 F6
Logoff request
60 1D A2 05 0D 03 02 A2 45 A6 04 0D
02 02 20 AC 00 A8 02 00 03 BE 08 2A
38 DF E9 8A F8 66 EE
Logoff response
60 1D A6 05 0D 03 02 A2 45 A2 04 0D
02 02 20 AC 00 A4 02 00 03 BE 08 8D
F1 C7 3A 93 2D BD F8
2708
2710
2711Authenticated communication example
2712
2713Will be provided during the editing phase.
113 - LVIII -
114
2714
2715 60 Application Segmentation Sub-Layer
2716
2717This Application Segmentation Sub-layer is responsible for the segmentation and reassembly of C12.22
2718Messages that exceed the Transport Layer maximum size limit. Segmentation is the process of breaking
2719the C12.22 Message into smaller pieces, and reassembly is the process of putting the smaller pieces
2720back together to reconstruct the original C12.22 Message. Because each APDU Segment must be sent
2721by the Transport Layer independently, each must carry sufficient information to be able to be routed to
2722the target C12.22 Node. The detailed implementation algorithm for APDU Segmentation is described in
2723the following sub-sections.
2724
2725This Standard requires that the delivery of C12.22 Messages cannot fail because of their size. C12.22
2726Relays and C12.22 Communication Modules shall, therefore, segment or re-segment C12.22 Messages
2727received, adjusting their sizes to meet the limits imposed by the next (output) Transport Layer. All
2728Transport Layer shall, at a minimum, support the transport of a 64 byte Segment.
2729
2730A C12.22 Node Application Layer may reject a request because of its size or its related response size (for
2731example, because the assembled C12.22 Message would exceed the memory capacity of the device). In
2732these cases, the C12.22 Node returns the error message <rqtl> or <rptl>.
2733
2734At the Transport Layer, each C12.22 Node has separate responsibilities for transmit and receive. For
2735transmit, each C12.22 Node must assure that APDU Segments it sends do not exceed the capacity of
2736the underlying Transport Layer. In the case of a C12.22 Device attached to a C12.22 Communications
2737Module, this maximum segment size may be negotiated between the two via the Negotiate service. For
2738receive, the C12.22 Node must accept any size APDU Segment that the Transport Layer is capable of
2739carrying, since no end-to-end negotiation is possible.
2740
2741C12.22 Relays or C12.22 Communication Modules may reassemble APDU Segments to optimize the
2742overall performance of the C12.22 Network.
2743
274461 APDU Segmentation
2745
2746APDUs as defined by <acse-pdu> are used to request services and transfer payloads. APDUs are
2747delivered to the lower layers in the OSI stack for encapsulation, address resolution and subsequent
2748transmission to its destination through the Transport Layer. In general, the Application Layer does not
2749have knowledge (nor should it have any such knowledge) of network segment size and transmission
2750constraints and similarly the Application Segmentation Sub-Layer does not have any knowledge of the
2751limits that may be imposed by the remote Application Layer or remote Application Segmentation Sub-
2752Layer.
2753
275462 APDU Segment
2755
2756Each APDU Segment is constructed as an ACSE PDU with the following constraints:
2757  the <application-context-element>, <called-aptitle-element>, <calling-aptitle-element> and
2758 <calling-entity-qualifier-element>, when present in the un-segmented APDU, shall be identically
2759 present in each of the APDU segments.
2760 the <mechanism-name-element>, <authentication-value-element> and <called-apinvocation-id-
2761 element> shall not be present in an APDU segment.
2762 <segment-calling-apinvocation-id-element> and <segment-user-information-element> shall be
2763 constructed as per the “Segment Calling Invocation ID
2764 Elements” and “Segment Application Data Element”
2765 section below.
2766
2767
27686.4.0.2.1 Segment Calling Invocation ID Elements (A8H)
2769
115 - LIX -
116
2770The Calling Invocation ID elements <segment-calling-apinvocation-id-element> provide for duplicate
2771APDU segment rejection and APDU Segmentation at the Application Segmentation Sub-Layer. APDU
2772Segmentation is required when the underlying Network Layer does not provide a delivery mechanism
2773with sufficient capability to handle large APDUs.
2774
2775The < segment-calling-apinvocation-id-element> shall be placed before the <segment-user-information-
2776element>.
2777
2778 <segment-calling-apinvocation-id-element> ::= A8H <seg-id-length> <seg-id>
2779 {The <segment-calling-apinvocation-id-element> is
2780 associated with the originator of an ACSE message and
2781 it uniquely binds an <acse-pdu> segments to the fully
2782 assembled <acse-pdu> that was sent by the Application
2783 Layer of the originator of this ACSE message.}
2784
2785 <seg-id-length> ::= <byte> + {Length of <seg-id> encoded as defined by the ISO
2786 8825-1-1997}
2787
2788 <seg-id> ::= <apdu-seq-number> <segment-byte-offset> <apdu-size>
2789 {Conveys information about the containing Datagram
2790 and the <user-data> content of <user-information-
2791 element>.
2792
2793 The <segment-byte-offset> and <apdu-size> are present
2794 in <seq-id> and absent in <apdu-id> as a distinguishing
2795 factor, to indicate that the APDU is one segment of a
2796 multiple-segment transmission, which needs to be
2797 assembled by the Application Segmentation Sub-Layer.}
2798
2799 The value of the <segment-sequence-number> present
2800 in any segment of one APDU shall be identical to the
2801 value constructed for the un-segmented <acse-pdu>.}
2802
2803 <segment-byte-offset> ::= <byte> | <word16> | <word24>
2804 {It is the segment offset in bytes relative to the
2805 beginning of the fully assembled APDU. Segment offset
2806 zero points to the value 60H of the APDU header and it
2807 cannot exceed the size of the fully assembled APDU - 1,
2808 when measured in bytes.
2809
2810 The data encoding format of the <segment-byte-offset>
2811 and <apdu-size> shall be identical.}
2812
2813 <apdu-size> ::= <byte> | <word16> | <word24>
2814 {This shall be the size of the fully assembled APDU,
2815 <acse-pdu>, when measured in bytes. It shall be
2816 identical in value to all related segments, and set to the
2817 size of the fully assembled <acse-pdu> (value of
2818 <elements-length> + 1 + size of <elements-length>).
2819
2820 The data encoding format of the <apdu-size> and
2821 <segment-byte-offset> shall be identical.}
2822
282363 Segment Application Data Element (BE H)
2824
2825The Application Data Element <segment-user-information> is used to carry one Application Sub-Layer
2826segment.
117 - LX -
118
2827
2828 <segment-user-information-element> ::= BE H <segment-app-data-length> <segment-app-data>
2829
2830 <segment-app-data-length> ::= <byte>+ {Length of <segment-app-data>
2831 encoded as defined by the ISO 8825-1-1997}
2832
2833 <segment-app-data> ::= <byte> + {Segment data bytes.}
2834
283564 The Segmentation and Reassembly
2836
2837The following sub-sections detail the APDU Segmentation Algorithm, and error exception reporting
2838algorithm.
2839
284065 The Segmentation Algorithm
2841
2842When the C12.22 Message exceeds the maximum transmit size of the Transport Layer, the Application
2843Segmentation Sub-Layer shall either return an error (<snp> or <snerr>) to the Application Layer or
2844fragment the APDU. The algorithm for fragmentation is described below; conforming implementations
2845may optimize or alter this algorithm as long as they adhere to the production rules expressed by this
2846Standard.
2847
2848If the <acse-pdu> being fragmented is not the product of an earlier segmentation (by virtue of the
2849absence of the <calling-apinvocation-id-element> fields <segment-byte-offset> and <apdu-size>) then
2850perform the following steps in this order:
2851
28521. Copy the entire un-segmented <acse-pdu> into a Datagram capture buffer, to be place as a new user
2853 information element <user-information-element>. This includes all the <acse-pdu> components: the
2854 byte 60H, <elements-length> and <elements> unaltered.
28552. Split the captured data buffer into smaller non-overlapping fragments that are suitable (size-wise) for
2856 inclusion into the newly generated <acse-pdu>.
28573. For each fragment of the Datagram capture buffer build a new <acse-pdu> by placing a Datagram
2858 capture buffer fragment into the <user-information-element> <app-data> field and setting the <app-
2859 data-length> to the size of the Datagram capture buffer corresponding fragment in bytes.
28604. Create the following fields ahead of the <user-information-element>:
2861  <called-ap-title> derived from the un-segmented <acse-pdu>.
2862  <calling-ap-title> derived from the un-segmented <acse-pdu>.
2863  <calling-entity-qualifier-element> derived from the un-segmented <acse-pdu>.
2864  <calling-apinvocation-id-element> then within the <calling-apinvocation-id-element:
2865  Set the <seg-id>s <seg-sequence-number> to the <seg-sequence-number> previously
2866 extracted from the fully assemble APDU, as all related segments shall have the same <seg-
2867 sequence-number>.
2868  Set the <seg-id>s <segment-byte-offset> to the fragment’s byte offset relative to the
2869 beginning of the Datagram capture buffer.
2870  Set the <seg-id>s <apdu-size> to the size of the fully assembled <acse-pdu> as stored in the
2871 Datagram capture buffer, including all the <acse-pdu> components such as the byte 60 H,
2872 <elements-length> and all unaltered <elements>.
2873  Set the data type (word length in bytes) of the <segment-byte-offset> by subtracting the field
2874 size of <seg-sequence-number> from the value of <seg-id-length> then dividing the result by
2875 2. The value 1, 2 or 3 shall be obtained representing <byte>, <word16>, and <word24>
2876 respectively.
28775. Append the previously constructed <user-information-element>, to the end of the <acse-pdu>.
28786. Update the <acse-pdu>s <elements-length>.
28797. Finish the sending the fragments to its Transport Layer.
2880
119 - LXI -
120
2881If the <acse-pdu> being fragmented is a product of a previous segmentation (by virtue the presence of
2882the <calling-apinvocation-id-element>s fields <seg-sequence-number>, <segment-byte-offset> and
2883<apdu-size>) then:
2884
28851. Copy all the <acse-pdu>s <elements> excluding the element <user-information-element> to the
2886 target <acse-pdu> construction area.
28872. Copy the segment’s <app-data> portion from the <acse-pdu>s <user-information-element> into a
2888 Datagram capture buffer, to be place as a new user information element <user-information-
2889 element>.
28903. Split the captured Datagram buffer into smaller non-overlapping fragments that are suitable (size-
2891 wise) for inclusion into the newly generated <acse-pdu> segments.
28924. Adjust all length and offset fields in each of the resulting <acse-pdu> segments. Specifically adjust
2893 each
2894  <user-information-element>s <app-data-length> to the length of the newly reduced data
2895 fragment in bytes.
2896  <seg-id>s <segment-byte-offset> being the fragment’s revised <app-data> location in the fully-
2897 assembled <acse-pdu> as originally delivered by its Application Layer. This new segment offset
2898 can be computed by adding the <acse-pdu>s <segment-byte-offset>, which is being segmented,
2899 to the byte offset of the new segment’s <app-data> relative to the beginning of the <app-data>
2900 portion in the Datagram capture buffer.
29015. Update the <acse-pdu>s <elements-length>.
29026. Finish the sending the fragments to the Transport Layer.
2903
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 0x60 0x8202EC
content
200 bytes
(0x81C8) 4
content
...
0xA8 0x02 0x1234

299 299 249 0xA8 0x06 0x1234
300 300 1000 bytes 0x012C 0x03E8
(0x03E8) 748 bytes
...
(0x8202EC)
51 0xBE 0x8202C6
52
...
content
700 bytes
(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>]

2904
2905
2906 Figure 6.3: Un-segmented APDU segmentation and re-assembly algorithm
2907
290866 The Reassembly Algorithm
2909
2910This section describes how the Application Segmentation Sub-Layer layer reassembles APDU fragments
2911received from its Transport Layer into larger fragments or the original <acse-pdu> for delivery to the
2912Application Layer.
2913
121 - LXII -
122
2914Reassembly is not required for strictly forwarding functions, such as C12.22 Relays. However, any
2915C12.22 Relay may choose, at its option, to perform full or partial APDU reassembly based on its system’s
2916requirements and knowledge.
2917
2918When the Datagram received from the Transport Layer is a segment of a fragmented <acse-pdu> the
2919Application Segmentation Sub-Layer shall either return an error (<sgnp> or <sgerr>) to the <calling-
2920aptitle-element> (calling entity) or reassemble the APDU before delivering it to the C12.22 Application
2921Layer. The presence of the <calling-apinvocation-id-element>s fields <seg-sequence-number>,
2922<segment-byte-offset>, and <apdu-size>, indicate that the Datagram is a segment of a fragmented
2923<acse-pdu>.
2924
2925The reassembly algorithm is outlined below:
2926
29271. Allocate an <acse-pdu> re-assembly buffer that is capable of holding the APDU <seg-id>s <apdu-
2928 size> in bytes. This field is found in the <calling-apinvocation-id-element> elements.
29292. For each segment received copy the <app-data> portion of the <user-information-element> into the
2930 buffer at the offset specified by the <seg-id>s <segment-byte-offset> of the <calling-apinvocation-id-
2931 element> up to length specified in the <user-information-element>s <app-data-length> in bytes.
29323. Repeat step 2 above until all segments have been received. All segments were received when the
2933 <acse-pdu> re-assembly buffer contains no gaps or the duplicate packet recognition period expires.
29344. If all segments were received with no gaps in the user data then forward the re-assembled buffer to
2935 its Application Layer for processing.
29365. If a full re-assembly cannot be completed due to missing segments, then discard all related
2937 segments silently.
2938
APDU Segment 3 APDU Segment 3-1
<tag> <content length> <tag> <content length>
0 0 0x60 0x82015C
0x60 0x8202EC
4 4 APDU Segment 3-2
...
...
<tag> <content length>

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

(0x82012C) 448 bytes
700 bytes
...
(0x8202C6)
offset 300 (0x8201C0)
content
0xBE 0x820190
351 351 51
offset 300
352 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>]

2939
2940
2941 Figure 6.4: Segmented APDU re-segmentation and partial assembly algorithm
2942
2943
294467 Layer 6 - Presentation Layer
2945Not defined by this standard, open to any network protocol.
2946
294768 Layer 5 - Session Layer
123 - LXIII -
124
2949
295069 Layer 4 - Transport Layer
2952
295370 Layer 3 - Network Layer
2955
295671 Layer 2 - Data link Layer
2958
295972 Layer 1 - Physical Layer
2961
125 - LXIV -
126
2962
296373 Protocol Details: C12.22 Device to C12.22 Communication Module Interface
296474 Interface Architecture
2965
2966This section describes the interface (Physical, Data link, Transport and Application layers) between a
2967C12.22 Device and a C12.22 Communication Module. The intent of this architecture is to allow the
2968creation of C12.22 Devices that can reside on any type of network. This architecture also allows
2969development of C12.22 Communication Modules that can interface any C12.22 Device to specific
2970networks. A C12.22 Device plus a C12.22 Communication Module arranged in this fashion constitutes a
2971C12.22 Node.
2972
2973In this model, all of the services that are normally provided by a single application entity are split
2974between two physically and logically distinct modules, the C12.22 Communication Module and the
2975C12.22 Device. The rolesof each aredivided as follows:
2976
2977C12.22 Communication Module
2978
2979 Implementation of Layers 1 through 6 of the target network
2980 Implementation of the Register Service (Start-up and keep-alive service sequences) for C12.22
2981 Devices with one or more interfaces to C12.22 Communication Modules
2982 Implementation of the Resolve Service (direct messaging vs. message forwarding services)
2983 Forwarding <acse-pdu> ApTitles from the network to a C12.22 Device (or its other C12.22
2984 Communication Modules)
2985
2986C12.22 Device
2987
2988 Implementation of the PSEM Logon, Logoff, Security, Read and Write services
2989 Encryption and Authentication
2990 Application Layer <acse-pdu> segmentation and reassembly
2991 Application Layer addressing
2992 Application Layer <acse-pdu> processing or forwarding
2993 C12.22 Communication Module control and management services
2994
299575 Interface Diagram
2996
2997The block diagram in Figure 7.1, C12.22 Communication Module Implementation Model, shows the
2998minimal and optional layers and services supported by a C12.22 Device that is connected to a C12.22
2999Communication Module via a point-to-point interface.
3000
127 - LXV -
128
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

3001
3002
3003 Figure 7.1: C12.22 Communication Module Implementation Model
3004
3005Annotations:
30061. Application Layer is managed using ANSI C12.19 Tables, ANSI C12.22 PSEM language and
3007 ACSE/EPSEM encapsulation
30082. ANSI C12.22 Layers 6 through 1 used for communication and control messages exchanged between
3009 the C12.22 Device and the C12.22 Communication Module, as described in this section.
30103. Corresponding Layers 6 through 1 of the target network.
30114. Optional content and services.
30125. The number ANSI C12.22 local Interfaces n, may be zero, one or greater than one.
3013
3014
301576 Implementation Guidelines
3016
3017C12.22 Communication Module
3018
3019The C12.22 Communication Module shall minimally be able to:
3020 Implement Layers 1-6 services as defined in this Standard;
3021 Initiate a Negotiate Service to maximize packet sizes at startup;
3022 Optionally initiates a Get Configuration Service at startup and upon receipt of Link Control Service
3023 requests when the RELOAD_CONFIG_FLAG is set to true;
3024 Process and honor all configuration control directives received by the “Get Configuration Service”;
3025 Emit empty packets as prescribed for line supervision in order to transition the attached C12.22
3026 Device into the “Comm Module Present State”;
3027 Implement Layers 1 and 2 on the C12.22 Device interface side;
3028 Implement Layers 1 to 6 on the C12.22 Network Segment side;
3029 By default, forward all Datagrams from the network side to the local Interface side.
3030 By default, forward Datagrams from the local Interface side to the C12.22 Network Segment side that
3031 not addressed to it;
3032 Intercept and process (may reject) the Send Service <acse-pdu> ApTitles that are addressed to it
3033 through its local Interface.
3034 Recognize and perform Layer 2 local routing in support of data-link packet forwarding to the other
3035 attached C12.22 Communication Modules.
3036 Recognize and correctly register the C12.22 Device using single or multiple interfaces ApTitles as
3037 needed;
3038 Recognize any ApTitle having its root ApTitle.0.<interface-number> as its own ApTitle, where
3039 <interface-number> is the interface number assigned to this C12.22 Communication Module.
3040
129 - LXVI -
130
3041The C12.22 Communication Module can optionally implement its own table set (Table 0 and any other
3042tables as needed by its application). This table set can be accessed from the network side by using the
3043ANSI C12.22 protocol. In this case, the C12.22 Communication Module does not need to be registered. It
3044is accessed using the C12.22 Device “<ap-title>.0 [.<interface-number>]”, which is a sub-branch of any
3045of the registered ApTiles for the attached C12.22 Device.
3046
3047This Table set can also be accessed through the C12.22 Device Local Port. In this case, the called
3048ApTitle shall be set to “.2[.local-port]”, which in turn will be forwarded by the C12.22 Device to the C12.22
3049Communication Module on the requested interface.
3050
3051C12.22 Device
3052
3053ANSI C12.22 Interfaces are numbered sequentially from one to the number of Interfaces supported. For
3054example, the second Interface can be accessed using the called ApTitle “<ap-title>.1.x”. The special
3055C12.22 ApTitle “<ap-title>.1” and “<ap-title>.1.0” shall be interpreted when received by the C12.22
3056Device as the “default C12.22 Communication Module interface”; and when received by the C12.22
3057Communication Module as “this C12.22 Communication Module”.
3058
3059The C12.22 Device shall minimally be able to:
3060 Implement the Negotiate, Get Configuration, Link control and Send services as defined by this
3061 Standard;
3062 Initiate a Link Control Service as needed (e.g., after updates to network tables) after the Negotiate
3063 Service;
3064 Provide routing of APDUs between the C12.22 Device Local Port (if one is available) and any
3065 C12.22 Communication Module that is attached to it.
3066
3067In addition the C12.22 Device may be able to:
3068
3069 Provide a communication path from the local access port to any node on the LAN/WAN side of its
3070 C12.22 Communication Modules (optional capability subject to the C12.22 Application <acse-pdu>
3071 forwarding restrictions);
3072 Provide a communication path from the LAN/WAN of any of its C12.22 Communication Modules to
3073 any C12.22 Communication Module, that are attached to it (optional capability subject to the C12.22
3074 Application <acse-pdu> forwarding restrictions);
3075 Manage and control its network interfaces and C12.22 Communication Modules;
3076 Provide network Tables in support of the management and operation of all of its network interfaces,
3077 attached C12.22 Communication Modules, Local Ports and services;
3078 Provide network and interface-state information using its network Tables.
3079 Accept and optionally process or reject APDUs arriving from any C12.22 Communication Module
3080 using the Send Service.
3081 Provide routing of APDUs from and to the C12.22 Device’s local Interfaces, if any are available, to
3082 and from any C12.22 Communication Module attached to them.
3083
308477 Layer 7 - Application Layer
3085Same as section “14 Layer 7 - Application Layer”.
3086
308778 Layer 6 - Presentation Layer
3088Null layer
3089
309079 Layer 5 - Session Layer
3091Null layer
3092
309380 Layer 4 - Transport Layer
131 - LXVII -
132
3094Transport Layer services are defined to facilitate setup, management and communication with one or
3095more C12.22 Communication Modules.
3096
3097For the purposes of enhanced clarity, the Negotiate Service defined in Layer 7 of ANSI C12.18 is
3098presented within this layer of this Standard.
3099
3100 <tls-requests> ::= <tls-negotiate> | {Negotiate Request}
3101 <tls-get-config> | {Get Configuration Request}
3102 <tls-link-control> | {Link Control Request}
3103 <tls-send-message> | {Send Message Request}
3104 <tls-get-status> | {Get Status Request}
3105 <tls-get-reg-status> {Get Registration Status Request}
3106
3107 <tls-responses> ::= <tls-negotiate-r> | {Negotiate Response}
3108 <tls-get-config-r> | {Get Configuration Response}
3109 <tls-link-control-r> | {Link Control Response}
3110 <tls-send-message-r> | {Send Message Response}
3111 <tls-get-status-r> | {Get Status Response}
3112 <tls-get-reg-status-r> {Get Registration Status Resquest}
3113
3114 81 Negotiate Service
3115
3116The Negotiate Service is initiated by the C12.22 Communication Module after detection of the presence
3117of an attached C12.22 Device.
3118
3119Request
3120
3121 <tls-negotiate> ::= <baud-rate-selector><rec-packet-size><rec-nbr-packet>
3122 <baud-rates> <rec-nbr-of-channels>
3123
3124 <baud-rate-selector> ::= 60H | {No <baud rate> included in request. Stay at default
3125 baud rate}
3126 61H | {1 <baud rate> included in request}
3127 62H | {2 <baud rate>s included in request}
3135 6AH | {10 <baud rate>s included in request}
3136 6BH | {11 <baud rate>s included in request}
3137
3138 <rec-packet-size> ::= <word16> {Maximum packet size in bytes that can be received by
3139 the C12.22 Communication Module. This value shall
3140 not be greater than 8192 bytes.}
3141
3142 <rec-nbr-packet> ::= <byte> {Maximum number of packets the C12.22
3143 Communication Module is able to reassemble into an
3144 upper layer data structure at one time.}
3145
3146 <baud-rates> ::= <baud-rate>* {List of baud rates supported by the C12.22
3147 Communication Module. If the C12.22 Device cannot
3148 select one of these baud rates, the original baud rate is
3149 echoed in the response.}
3150
133 - LXVIII -
134
3151 <baud-rate> ::= 00H | {Reserved}
3152 01H | {300 baud}
3153 02H | {600 baud}
3154 03H | {1200 baud}
3155 04H | {2400 baud}
3156 05H | {4800 baud}
3157 06H | {9600 baud}
3158 07H | {14400 baud}
3159 08H | {19200 baud}
3160 09H | {28800 baud}
3161 0AH | {57600 baud}
3162 0BH | {38400 baud}
3163 0CH | {115200 baud}
3164 0DH | [128000 baud}
3165 0EH {256000 baud}
3166 {0FH – FFH reserved}
3167
3168 <rec-nbr-of-channels> ::= <byte> {The maximum number of concurrent channels
3169 supported by the C12.22 Communication Module.}
3170
3171Response
3172
3173The responses <sns>, <isss>, <bsy>, and <err> indicate a problem with the received service request
3174and the C12.22 Communication channel retains its current settings.
3175
3176The response <ok> indicates the service request was accepted and the new settings now apply.
3177
3178 <tls-negotiate-r> := <sns> | <isss> | <bsy> | <err> |
3179 <ok><trs-packet-size><trs-nbr-packet>
3180 <negotiated-baud-rate><trs-nbr-of-channel>
3181 <interface-number>
3182
3183
3184 <trs-packet-size> ::= <word16> {Maximum packet size in bytes that can be received by
3185 the attached C12.22 Device. This value shall not be
3186 greater than 8192 bytes.}
3187
3188 <trs-nbr-packet> ::= <byte> {Maximum number of packets the attached C12.22
3189 Device is able to reassemble into an upper layer data
3190 structure at one time.}
3191
3192 <negotiated-baud-rate> ::= <baud-rate>
3193 {Baud rate to use for future communication on this
3194 interface.}
3195
3196 <rec-nbr-of-channels>::= <byte> {The maximum number of concurrent channels
3197 supported in reception by the C12.22 Device.}
3198
3199 <interface-number> ::= <byte> {The interface number assigned to this C12.22
3200 Communication Module.}
3201
3202
3203 82 Get Configuration Service
3204
3205The Get Configuration Service is used solely by a C12.22 Communication Module to request its
3206configuration information from the C12.22 Device of which it is attached. This service is initiated by the
3207C12.22 Communication Module as needed, any time after it detects the presence of the C12.22 Device.
135 - LXIX -
136
3208The information carried by this service is the same as that found in the Interface Control Table (Table
3209122).
3210
3211Request:
3212
3213 <tls-get-config> ::= 72H
3214
3215
3216Response:
3217
3218The response <err> indicates a problem with the received service request.
3219
3220The response <ok> indicates that the request has been accepted and the C12.22 Communication
3221Module configuration follows in the response.
3222
3223 <tls-get-config-r> ::= <err> |
3224 <ok> <control> <interface-status> <node-type> <device-class> <esn>
3225 <native-address-len> <native-address> <broadcast-address-len>
3226 <broadcast-address> <relay-native-address-len> <relay-native-address>
3227 <node-ap-title> <master-relay-aptitle> [<nbr-of-retry><response-timeout>]
3228
3229 <control> ::= <word16> {This is a bit field that provides information and
3230 directives to the C12.22 Communication Module about
3231 its expected operation. The control bits are defined as
3232 follows:
3233
3234 Bit 0: PASSTHROUGH_MODE
3235 This is a directive to the C12.22 Communication Module
3236 regarding the forwarding to the C12.22 Device of
3237 messages that originate from the network side and that
3238 are addressed to the C12.22 Communication Module.
3239
3240 The value 0 (false) indicates that the C12.22
3241 Communication Module is required to forward to the
3242 C12.22 Device all messages even if they are addressed
3243 directly to the C12.22 Communication Module and
3244 regardless of whether it has the capability to process
3245 them. This is the default operating mode of any C12.22
3246 Communication Module at start-up.
3247
3248 The value 1 (true) indicates that the C12.22
3249 Communication Module is permitted to intercept and
3250 process messages that are addressed directly to it if it
3251 has the capability to recognize them and process them.
3252 If it does not have such a capability, the C12.22
3253 Communication module shall forward the messages to
3254 the C12.22 Devices across the local interface, according
3255 to the default behavior at start-up.
3256
3257 Bits 1..15: RESERVED.}
3258
3259 <interface-status> ::= <byte> {As defined by the Link Control Service. This filed is
3260 used by the C12.22 Device to configure its interface
3261 without issuing a Link Control Service after each power-
3262 up.}
3263
3264 <node-type> ::= <byte> {Node type as defined by the Registration Service.}
137 - LXX -
138
3265
3266 <device-class> ::= <byte> + {C12.19 Device Class of the C12.22 Device. Four bytes
3267 containing the MANUFACTURER ID as defined in Table
3268 0 of ANSI C12.19-1997 or the registered
3269 DEVICE_CLASS as defined by Version 2 of ANSI
3270 C12.19.}
3271
3272 <esn> ::= <absolute-uid-element> | <relative-uid-element>
3273 {A unique electronic serial number (ESN) that is
3274 assigned to a C12.22 Device by its owner (or operator).
3275 The use of an ESN is optional and, when not provided,
3276 the length of this element is set to zero.}
3277
3278 <native-address-len> ::= <byte> {Number of bytes in <native-address>. This length is set
3279 to zero when this value is not configurable.}
3280
3281 <native-address> ::= <byte> + {Native address assigned to the C12.22 Communication
3282 Module.}
3283
3284 <broadcast-address-len> ::= <byte> {Number of bytes in <broadcast-address>. This
3285 length is set to zero when this value is not configurable.
3286
3287 <broadcast-address> ::= <byte> + {Broadcast address assigned to the C12.22
3288 Communication Module.}
3289
3290 <relay-native-address-len> ::= <byte> {Number of bytes in <relay-native-address>. When the
3291 length of this element is zero then the nearest C12.22
3292 Relay address is resolved and assigned by the C12.22
3293 Communication Module. When the length of this
3294 element is not zero then the C12.22 Communication
3295 Module shall use this value as it’s new nearest C12.22
3296 Relay address until such time that it is re-assigned by
3297 the C12.22 Device.}
3298
3299 <relay-native-address> ::= <byte> + {Native address of the nearest C12.22 Relay
3300 used to maintain registration of this node.}
3301
3302 <node-ap-title> ::= <absolute-uid-element> | <relative-uid-element>
3303 {The ApTitle of the C12.22 Node to be registered with a
3304 C12.22 Master Relay. When the length of this element is
3305 zero then the C12.22 Node’s ApTitle will be dynamically
3306 assigned.}
3307
3308 <master-relay-aptitle> ::= <absolute-uid-element> | <relative-uid-element>
3309 {The ApTitle of the C12.22 Master Relay used to register
3310 this C12.22 Device. When the length of this element is
3311 zero then the C12.22 Master Relays’ ApTitle will be
3312 dynamically assigned.}
3313
3314 <nbr-of-retry> ::= <byte> {Defines the number of times a request is sent if the
3315 response is not received within a <response-timeout>.}
3316
3317 <response-timeout> ::= <word16> {Controls the number of seconds this C12.22
3318 Communication Module has to wait for a response of a
3319 request before failing or sending retries.}
3320
3321
139 - LXXI -
140
3322 83 Link Control Service
3323
3324This service is used by a C12.22 Device to control a C12.22 Communication Module. A C12.22
3325Communication Module shall never initiate this service.
3326
3327Request:
3328
3329 <tls-link-control> ::= 73H <interface-ctrl>
3330
3331 <interface-ctrl> ::= <byte> {Bit 0 to 1: INTERFACE_CTRL
3332 0 = Maintain current state
3333 1 = Enable this interface
3334 2 = Disable this interface
3335 3 = Reset this interface
3336
3337 Bit 2 to 3: AUTO_REGISTRATION_CTRL
3339 1 = Disable auto-registration
3340 2 = Enable auto-registration
3341 3 = Force one-time registration now then return
3342 previous state
3343
3344 Bit 4 to 5: DIRECT_MESSAGING_CTRL
3346 1 = Enable direct communication with target nodes
3347 on the same network segment
3348 2 = Disable direct communication with target nodes
3349 on the same network segment
3350
3351 Bit 6: RESET_STATISTIC_FLAG
3352 false = Maintain current state
3353 true = Reset all statistics and counters
3354
3355 Bit 7: RELOAD_CONFIG_FLAG
3356 false = Maintain current state
3357 true = Initiate a Get configuration service to retrieve
3358 new configuration.}
3359
3360Response:
3361
3362The response <sns> indicates a problem with the received service request.
3363
3364The response <ok> indicates that the request has been processed successfully.
3365
3366 <tls-link-control-r> ::= <sns> |
3367 <ok><interface-status><ap-title>
3368
3369
3370 <interface-status> ::= <byte> {Bit 0: INTERFACE_FLAG
3371 This bit is set to true when the physical interface is
3372 enabled.
3373
3374 Bit 1: AUTO_REGISTRATION_FLAG
3375 This bit is set to true when C12.22 Communication
3376 Module automatically registers the C12.22 Device on
3377 this interface.
3378
141 - LXXII -
142
3379 Bit 2: DIRECT_MESSAGING_FLAG
3380 This bit is set to true when direct messaging is in use on
3381 this interface.
3382
3383 Bits 3..7: Reserved.}
3384
3385 <ap-title> ::= <absolute-uid-element> | <relative-uid-element>
3386 {ApTitle registered on this interface. Required to be
3387 present (length different than zero) only when
3388 INTERFACE_CTRL is set to a value different than zero.}
3389
3390 84 Send Message Service
3391
3392The Send Message Service is used by a C12.22 Device to send messages through an attached C12.22
3393Communication Module or by the C12.22 Communication Module to transfer each message received for
3394C12.22 Device. This service carries the <acse-pdu> generated by two-way-devices or <short-pdu>s
3395generated by one-way devices to be sent and the native address of the target or the initiator.
3396
3397Request:
3398
3399 <tls-send-message> ::= <tls-send-acse-message> | <tls-send-short-message>
3400 {The service request, address and payload to be
3401 transmitted to and from a C12.22 Communication
3402 Module across the Data Link as described in section “90
3403 Layer 2 - Data Link Layer”.}
3404
3405 <tls-send-acse-message> ::= 74H <address-lgn> <address> <acse-pdu>
3406 {The message format of a send service request that
3407 carries <acse-pdu>s as its payload data. It is the
3408 message format used by all two-way devices. This
3409 message format is the only one supported on all C12.22
3410 Nodes on any C12.22 Network Segment.}
3411
3412 <tls-send-short-message> ::= 77H <address-lgn> <address> <short-pdu>
3413 {The message format of a send service request that
3414 carries <short-pdu>s as its payload data. It is the
3415 message format used by some one-way devices to
3416 reduce the message size. This message format is
3417 recognized only by one-way designated native network
3418 segments and by one-way message enabled C12.22
3419 Communication Modules. It is the responsibility of
3420 C12.22 Communication Module to map the <short-pdu>
3421 to an <acse-pdu> upon delivery to its C12.22 Network
3422 Segment.}
3423
3424 <address-lgn> ::= <byte> {Number of bytes in <address>.}
3425
3426 <address> ::= <byte> + {When issued by the C12.22 Communication Module,
3427 the native address represents the source of the <acse-
3428 pdu> or the <short-pdu> on the local network segment.
3429 The C12.22 Communication Module shall always
3430 provide the native address.
3431
3432 When issued by the C12.22 Device Transport Layer, the
3433 native address represents the target node on the local
3434 network segment for this <acse-pdu> or <short-pdu>.
143 - LXXIII -
144
3435 This field is optional and when not provided, <address-
3436 lgn> is set to zero (00H).
3437
3438 Three methods are available to send information.
3439
3440 Directed message:
3441 When the <native-address> is provided, the C12.22
3442 Communication Module sends the <acse-pdu> or
3443 <short-pdu> to the specified address.
3444
3445 Direct messaging:
3446 When the <native-address> is not provided and
3447 DIRECT_MESSAGING_FLAG is set to false, the
3448 C12.22 Communication Module sends the <acse-pdu>
3449 to one of its nearest C12.22 Relay based on a default or
3450 internal routing table (C12.22 Communication Modules
3451 shall not transmit <short-pdu>s onto the C12.22
3452 Network).
3453
3454 Message forwarding:
3455 When the <native-address> is not provided and
3456 DIRECT_MESSAGING_FLAG is set to true, the C12.22
3457 Communication Module shall use the <called-aptitle> of
3458 the <acse-pdu> or <short-pdu> to resolve the native
3459 address where to send this message.}
3460
3461Response:
3462
3463The responses <nett> and <netr> indicate a problem during the transmission of this message and can be
3464returned only when this service is requestedby the C12.22 Device.
3465
3466The response <ok> indicates that the message has been transmitted succesfully. Responses may be
3467expected only following a <tls-send-acse-message> service request. Responses shall not be expected
3468following a <tls-send-short-message> service request
3469
3470 <tls-send-message-r> ::= <tls-send-acse-message-r> | <tls-send-short-message-r>
3471
3472 <tls-send-acse-message-r> ::= <nett> | <netr> | <ok>
3473
3474 <tls-send-short-message-r> ::= {Short messages do not expect responses.}
3475
3476 85 Get Status Service
3477
3478The Get Status Service is used by a C12.22 Device to retrieve information from a C12.22
3479Communication Module. The C12.22 Communication Module shall not initiate this service request. The
3480information carried by this service is the same as that found in the Interface Status Table (Table 125).
3481
3482Request:
3483
3484 <tls-get-status> ::= 75H <status-ctrl>
3485
3486 <status-ctrl> ::= <byte> {Control the information returned by this service.
3487 0 = Interface info and statistics
3488 1 = Interface info only
3489 2 = Statistics only
3490 3 = Statistics changed since last request}
3491
145 - LXXIV -
146
3492Response:
3493
3495
3496The response <ok> is returned by the C12.22 Communication Module with the available information.
3497
3498 <tls-get-status-r> ::= <err> |
3499 <ok>[<interface-info>]<statistics>*
3500
3501
3502 <interface-info> ::= <interface-name-len>
3503 <interface-name>
3504 <interface-status>
3505
3506 <interface-name-len> ::= <byte> {Number of bytes in <interface-name>.}
3507
3508 <interface-name> ::= <byte> + {Textual description of the interface in 8-bit ASCII
3509 format. For example an Ethernet interface that is
3510 attached to a C12.22 Interface may be expressed as
3511 “Ethernet”.}
3512
3513 <interface-status> ::= <byte> {As described by the Link Control Service.}
3514
3515
3516 <statistics> ::= <statistic code> <statistic-value>
3517
3518 <statistic-code> ::= <word16> {This code identifies the associated <statistic-value>.
3519 The list of standard codes available is defined in the
3520 Network Statistics Table (Table 125).}
3521
3522 <statistic-value> ::= <int48> {Statistic returned.}
3523
3524 86 Get Registration Status Service
3525
3526The Get Registration Status Service is used by a C12.22 Device to get registration information from a
3527C12.22 Communication Module. The information carried by this service is the same as that found in the
3528Registration Table (Table 126).
3529
3530Request:
3531
3532 <tls-get-reg-status> ::= 76H
3533
3534Response:
3535
3537
3538The response <ok> is returned by the C12.22 Communication Module with the available information.
3539
3540 <tls-get-reg-status-r> ::= <err> |
3541 <ok>
3542 <relay-native-address-len> <relay-native-address>
3543 <master-relay-aptitle> <node-ap-title>
3544 <reg-delay> <reg-period> <reg-count-down>
3545
3546
3547
3548 <relay-native-address-len> ::= <byte> {Number of bytes in <relay-native-address>.}
147 - LXXV -
148
3549
3550 <relay-native-address> ::= <byte> * {Native address of the nearest C12.22 Relay
3551 used to maintain registration of this node.}
3552 <master-relay-aptitle> ::= <absolute-uid-element> | <relative-uid-element>
3553 {ApTitle of the C12.22 Master Relay used to register this
3554 C12.22 Device.}
3555
3556 <node-ap-title> ::= <absolute-uid-element> | <relative-uid-element>
3557 {ApTitle used to register this C12.22 Device through this
3558 interface.}
3559
3560 <reg-delay> ::= <word16> {Maximum delay in seconds that the C12.22
3561 Deviceshould wait before registering after a power-up.}
3562
3563 <reg-period> ::= <word16> {Maximum period allowed between two messages
3564 received from the local C12.22 Relay. The device
3565 automatically registers when this limit is reached.}
3566
3567 <reg-count-down> ::= <word16> {The amount of time in minutes left before the
3568 registration period expires.}
149 - LXXVI -
150
3569
3570 87 Service Time Sequence Diagrams
3571
3572Negotiate
3573The following diagram shows information exchanged between a C12.22 Device and a C12.22
3574Communication Module at startup.
3575
Node Comm. Module Relay Node Information exchanged
Negotiate packet size, number of packets, baud rate(s),
◄—————— number of channels
——————► packet size, number of packets, baud rate
number of channels, interface number
3576
3577Get Configuration
3578The following diagram shows information exchanged when the C12.22 Communication module retrieves
3579its configuration from the C12.22 Device.
3580
[Link control]
——————► RELAOD_CONFIG_FLAG = true
◄—————— Interface status, node ApTitle
Get
Configuration
◄——————
——————► passthrough mode, node type, device class, ESN,
Native address, broadcast address, relay native
address, node ApTitle, master relay ApTitle, [number
of retries, response timeout]
3581
3582(Should this not show some “interface status” flag values as shown below?)
3583
3584Link Control (Enable Network-side Interface)
3585The following diagram shows the information exchanged for enabling a C12.22 Communication Module
3586interface on the network side. It is important to note that the use of the Resolve Service is optional and
3587not needed if the C12.22 Communication Module already knows the native address of its nearest C12.22
3588Relay. When the C12.22 Communication Module supports multiple routes, the Resolve and Register
3589services are used multiple times to register each route. A different ApTitle shall be used for each route.
3590
Link control
——————► INTERFACE_CTRL = 1
[ Resolve ]
——————► [master relay ApTitle]
◄—————— relay native address
Registration
——————► node type, connection type, device class, ApTitle,
serial number, native address, registration period
◄—————— node ApTitle, registration delay, registration period,
direct messaging flag
◄—————— interface status, node ApTitle
Registration (keep-registration-alive)
——————► Same as previous Registration in example
◄—————— Same as previous Registration in example
3591
151 - LXXVII -
152
3592( why isn’t registration shown as optional? Should this not show some “interface status” flag values as
3593shown below?)
3594
3595Link Control (Disable Network-side Interface)
3596The following diagram shows the information exchanged for disabling a C12.22 interface.
3597
Link Control
[Deregistration]
——————► node ApTitle
◄—————— node ApTitle
◄—————— interface status, ApTitle
3598
3599(why is deregistration shown as optional? Should this include the “interface status” flag values as in the
3600following example?)
3601
3602Link Control (Auto Registration, Direct Messaging, Reset Statistic Control or Reload
3603Configuration)
3604The following diagram shows the information exchanged for disabling a C12.22 interface. (Modified
3605information exchanged to match language, but is this the real intent?)
3606
Link Control
AUTO_REGISTRATION_CTRL = 1
DIRECT_MASSAGING_CTRL = 2
RESET_STATISTIC_FLAG = true
RELOAD_CONFIG_FLAG = false
◄—————— INTERFACE_FLAG = false
AUTO_REGISTRATION_FLAG = either
DIRECT_MESSAGING_FLAG = false
3607
3608Send (Directed Message)
3609The following diagram shows the information exchanged when the Send Service is generated by a
3610C12.22 Device and the “Directed Message” option has been invoked.
3611
Send
——————► native address, ACSE pdu or short pdu
Target network
send service
——————— ——————► ACSE pdu or short pdu
◄—————— status
3612
3613Send (Direct Messaging)
3615C12.22 Device and the “Direct Messaging” option has been invoked.
3616
Send
——————► ACSE pdu or short pdu
[ Resolve ]
——————► node ApTitle
153 - LXXVIII -
154
◄—————— native address
——————► ACSE pdu or converted short pdu
3617
3618(description of direct messaging flag value usage in <address> says that the comm module uses its
3619default or internal relay table to route the message, NOT the Resolve Service (a la message forwarding
3620description). This appears to be in conflict with the flag definition in the Link Control Service.)
3621
3622Send (Message Forwarding)
3624C12.22 Device and the “Message Forwarding” option has been invoked.
3625
Send message
Target network
send service
Target network
send service
3626
3627(description of message forwarding flag value usage in <address> says that the comm module uses the
3628pdu to resolve the native address - does this imply invoking the Resolve Service? This appears to be in
3629conflict with the flag definition in the Link Control Service.)
3630
3631Send (Message Received)The following diagram shows the information exchanged when the Send
3632Service is received by a C12.22 Device.
3633
◄——— ACSE pdu
Send
◄—————— native address, ACSE pdu
——————► status
3634
3635Get Status
3636The following diagram shows the information exchanged when the Get Status Service is initiated by a
3637C12.22 Device.
3638
Get Status
◄—————— status ctrl
——————► [interface name], [interface status],
(statistic code/statistic value)*
3639
3640Get Registration Status
3641The following diagram shows the information exchanged when the Get Registration Status Service is
3642initiated by a C12.22 Device.
3643
155 - LXXIX -
156
Get
Registration
Status
——————► none
◄—————— relay native address, master relay ApTitle, node
ApTitle, registration delay, registration period,
registration countdown
3644
157 - LXXX -
158
3645
3646
3647 88 Service Sequence States
3648
3649The Transport Layer is defined as a series of “Service Sequence States. Valid states include:
3650
3651(Replace State name)
3652
3653Comm Module Disconnected State: Initial state entered after power-up or re-entered after Layer 2
3654 has detected a lack of activities with the C12.22 Communication Module. In
3655 this state, the interface may be used as a Local Port. Refers to section “113
3656 Local Port Communication Protocol Details” for the definition of the service
3657 sequence state used in that case.
3658
3659Comm. Module Present State:
3660 State entered after the detection of a C12.22 Communication Module by
3661 Layer 2.
3662
3663On network State: State entered after the C12.22 Communication Module has reported that the
3664 interface is enabled (INTERFACE_FLAG set to true).
3665
3666The relationship between services and service sequence states is:
3667
3668Negotiate: This service is accepted at the “Local access” state only.
3669
3670Get Configuration: This service is accepted at any state.
3671
3672Link Control: This service is accepted at both the Comm Module Present and On Network
3673 states. This service is used to move between these two states based on the
3674 value of INTERFACE_CTRL field.
3675
3676Send Message: This service can be accepted at the “Local access” state to locally access
3677 the device and at the “On network” state to send and receive messages to or
3678 through the C12.22 Communication Module.
3679
3680Get Status: This service is accepted both in the Comm Module Present and On Network
3681 states.
3682
3683Get Registration Status:
3684This service is accepted at both the Comm Module Present and On Network states.
3685
3686(Create a different state diagram for the C12.22 Device)
159 - LXXXI -
160
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)
3687
3688
3689 Figure 7.2: Transport Layer State Diagram
3690
369189 Layer 3 - Network Layer
3692Null layer
3693
369490 Layer 2 - Data Link Layer
3695
3696The Data Link Layer is used only for communication between the C12.22 Device and the C12.22
3697Communication Module.
3698
3699Datagrams of upper layers are transported in one or more packets. Each packet is variable in length but
3700cannot exceed a maximum packet size. The maximum packet size has a default value when the
3701communication link is opened. The maximum packet size and number of packet attributes are changed
3702through the use of the Negotiate Service.
3703
3704The C12.22 Device may support transfer of multiple Datagrams at the same time via interleaving
3705packets. To accomplish this, a different channel number is associated for each simultaneous Datagram
3706transmitted.
3707
3708For each packet received, the target sends a positive or an optional negative acknowledgment. This
3709acknowledgment consists of a single byte transmitted outside of the packet structure or inside a packet
3710structure if requested by the TRANSPARENCY flag. If the requester does not receive an
3711acknowledgment before the Response Timeout, or a negative acknowledgment is received, the same
3712packet is re-transmitted up to the current maximum number of negotiated retry attempts. After the final
3713retry attempt, the requester should assume that the communication link is down and try to reestablish it.
3714
3715The Data Link Layer also supports line supervision by the transmission of empty packets to avoid Traffic
3716Time-out. An empty packet is defined as a <packet> without the <reason-code> and <data> fields.
3717
3718
3719 91 Basic Data Information
161 - LXXXII -
162
3720
3721Communication link settings are specified below.
3722
372392 Fixed Settings
3724
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
3725
372693 Variable Settings
3727
3728Default settings apply at the initiation of communication. These settings may be changed through the
3729Negotiate Service. Communication link settings will return to defaults as a result of a Traffic Time-out.
3730
Setting Default Value Changed by
Data Rate 9600 baud Negotiate Service
Number of Packets 1 Negotiate Service
Packet Size 64 bytes Negotiate Service
3731
3732 94 Packet Definition
3733
3734 <packet> ::= <stp> <identity> <ctrl> <seq-nbr> <length> <data> <crc>
3735
3736 <stp> ::= EEH {Start of packet character.}
3737
3738 <identity> ::= <byte> {Identity.
3739 Bits 3 to 7: LOCAL_ADDRESS_NUMBER
3740 This field is used to facilitate routing of information
3741 between a Local Port and the local C12.22
3742 Communication Modules. This field can be set to the
3743 following values:
3744 0 = C12.22 Device
3745 1 = Local Port 0 (Default)
3746 2 = Local Port 1 (Alternate)
3747 3 = Interface 0 (Default WAN)
3748 4 = Interface 1 (Alternate WAN)
3749 5 = Interface 2(Default POT modem)
3750 6 = Interface 3 (Alternate POT modem)
3751 7 to 12 = Reserved
3752 13 to 28 = Manufacturer defined
3753 29 = Invalid (to avoid <stp>)
3754 30 to 31 = Reserved for future extension of this field
3755
3756 Bits 0 to 2: CHANNEL NUMBER
3757 This field allows simultaneous transfer of multiple
3758 segmented <acse-pdu>. A different number is assigned
3759 dynamically by the C12.22 Device or by the C12.22
163 - LXXXIII -
164
3760 Communication module for each <acse-pdu> message
3761 transferred simultaneously.}
3762
3763 <ctrl> ::= <byte> {Control field.
3764 Bit 7: MULTI_PACKET_TRANSMISSION
3765 If true (1H) then this packet is part of a multiple packet
3766 transmission.
3767
3768 Bit 6: FIRST_PACKET
3769 If true (1H), then this packet is the first packet of a
3770 multiple packet transmission
3771 (MULTI_PACKET_TRANSMISSION, bit-7, is also set to
3772 1), otherwise this bit shall be set to 0.
3773
3774 Bit 5: TOGGLE_BIT
3775 Represents a toggle bit to reject duplicate packets. This
3776 bit is toggled for each new packet sent. Retransmitted
3777 packets keep the same state as the original packet sent.
3778 After a Traffic Time-out, the state of the toggle bit may
3779 be re-initialized; thus, it is assumed to be indeterminate.
3780
3781 Bit 4: TRANSPARENCY
3782 If true, this packet uses the transparency mechanism as
3783 described in section “104 Transparency”. Also the target
3784 shall respond with an ACK or optional NAK inside the
3785 packet structure as described in section “96
3786 Acknowledgment”.
3787
3788 Bits 2 to 3: ACKNOWLEGMENT
3789 Used to acknowledge the reception of a valid or invalid
3790 packet. Acknowledgment and response data can be sent
3791 together in the same packet or as two consecutive
3792 packets.
3793 0 = Acknowledged packet
3794 1 = ACK optionally piggybacked on an optional
3795 acknowledged packet
3796 2 = NAK optionally piggybacked on an optional
3797 acknowledged packet
3798 3 = Unacknowledged packet
3799
3800 A possible use of option 3 is when a one-way device
3801 send blurts which do not require acknowledgments. In
3802 this context, the C12.22 Device shall be the originator of
3803 all messages. This is an indication to the C12.22
3804 Communication Module to disable the ACK/NAK packet
3805 handshake for one-way devices. The C12.22
3806 Communication Module shall operate at its default
3807 settings as listed in sections “92 Fixed Settings” and “93
3808 Variable Settings” unless the Negotiate Service was
3809 successful in changing the default settings.
3810
3811 Bit 0 to 1: DATA_FORMAT
3812 0 = C12.18 or C12.21 Device
3813 1 = C12.22 Device
3814 2 = Invalid (to avoid <stp>)
3815 3 = Reserved}
3816
165 - LXXXIV -
166
3817 <seq-nbr> ::= <byte> {Number that is decremented by one for each new
3818 packet sent. The first packet in a multiple packet
3819 transmission shall have a <seq-nbr> equal to the total
3820 number of packets minus one. A value of zero in this
3821 field indicates that this packet is the last packet of a
3822 multiple packet transmission. If only one packet is in a
3823 transmission, this field shall be set to zero.}
3824
3825 <length> ::= <word16> {Number of bytes of <data> in packet.}
3826
3827 <data> ::= <byte> * {<length> number of bytes of actual packet data. This
3828 value is limited by the maximum packet size minus the
3829 packet overhead. This value can never exceed 8183.}
3830
3831 <crc> ::= <word16> {HDLC implementation of the polynomial X16 + X12 + X5
3832 + 1}
3833
3834 95 CRC Selection
3835
3836The CRC selected for implementation is the polynomial X16 + X12 + X5 + 1. The method for calculation
3837and insertion is the HDLC standard per ISO/IEC 13239 (2002) Annex A.
3838
3839In the PSEM frame, there is no opening flag as referenced in ISO/IEC 13239 (2002) Annex A. The PSEM
3840start of packet character EE is included in the CRC calculation. The result of the CRC calculation shall
3841be transmitted least significant byte first per the ISO/IEC 13239 (2002) Annex. See Annex D for
3842examples of computation and coding.
3843
3844 96 Acknowledgment
3845
3846A positive or negative acknowledgment is used by the communicating devices to indicate either
3847acceptance or rejection of a packet.
3848
3849An <ack> shall be issued by the receiving device to the transmitting device for each valid packet
3850received.
3851
3852 <ack> ::= 06H | <packet>
3853
3854A <nak> shall be issued by the receiving device to the transmitting device for each packet received that
38551. begins with <stp>, and
38562. must be followed by five additional bytes followed by <length> bytes followed by two additional
3857 bytes, and
38583. is completely received without any intervening inter-character time-outs, and
38594. contains some other error.
3860
3861 <nak> ::= 15H | <packet>
3862
3863 97 Retry Attempts
3864
3865The same packet shall be retransmitted if a <nak> is received or the Response Time-out occurs.
3866
3867After the failure of the final retry attempt, the communication link is considered down, and the C12.22
3868Communication Module shall attempt to reestablish the link by repeatedly either sending a Negotiate
3869Service request or Get Configuration Service request until the link is re-established.
3870
3871 98 Timeouts
3872
167 - LXXXV -
168
387399 Traffic Time-out
3874
3875The C12.22 Device will consider the communications link down after waiting some period of time for a
3876valid packet or acknowledgment. This period of time, is defined as the Traffic Time-out.
3877
3878100 Inter-character Time-out
3879
3880The recipient of the packet must handle the case when the end of a packet is lost. Inter-character Time-
3881out is defined as the minimum amount of time the recipient shall wait between characters within a packet
3882when receiving data over the communication link. The recipient shall wait at least this amount of time
3883before it ceases to wait for the remainder of the packet and sends a <nak>. This time-out is not used
3884when the NO_NACK option is negotiated successfully by the Link Control Service.
3885
3886101 Response Time-out
3887
3888The sender of the packet must handle the case when the acknowledgment or negative acknowledgment
3889is lost. Response Time-out is defined as the minimum amount of time the sender shall wait after a packet
3890is sent to receive an acknowledgment over the communication link. If this amount of time elapses, the
3891sender will send the packet again.
3892
3893 102 Turn Around Delay
3894
3895The Turn Around Delay is the minimum delay the recipient must wait after receiving a packet and before
3896sending a positive or negative acknowledgement.
3897
3898 103 Duplicate Packets
3899
3900A duplicate packet is defined as a packet whose identity, toggle bit and valid CRC are identical to those
3901of the immediate previous packet. If a duplicate packet is received by the target device, the target should
3902disregard the duplicate packet and return an <ack>. At the start of session, the toggle bit in the first
3903packet may assume either state.
3904
3905 104 Transparency
3906
3907The "Basic Transparency" method is requested by the TRANSPARENCY bit in the <ctrl> byte. This
3908method replaces any occurrence of the <stp> by a two-octet escape sequence.
3909
3910After CRC computation, the transmitter shall replace any occurrence of the <stp> or 1B H (escape flag as
3911defined in ISO/IEC 13239) found inside the packet by a two-octet sequence consisting of the 1B Hand the
3912original octet with bit 5 complemented. Prior to CRC computation, the receiver removes every
3913occurrence of 1BHand inverts bit 5 of the following octet.
3914
3915Therefore, the following replacement shall result:
3916
3917 Transmitted Received
3918 1BH -> 1BH 3BH 1BH 3BH -> 1BH
3919 EEH -> 1BH CEH 1BH CEH -> EEH
3920
3921 105 Supervision of the Communications Link
3922
3923The C12.22 Communications Module is assumed to continually poll the C12.22 Device using a empty
3924packet (packet without a <data> field). Any message transported in either direction that is confirmed by
3925an acknowledgement can be accepted to reset the traffic timer. If the timer times out, the link can enter
3926the “Disconnected state”. The End device, at its option, can activate a reset of the C12.22
3927Communications Module (and perhaps itself) to re-establish the link and re-enter the “Connected state”.
3928
169 - LXXXVI -
170
3929The C12.22 Device has the responsibility to supervise the C12.22 Communication Module for proper
3930performance on all communications levels. The method for concluding a C12.22 Communication Module
3931malfunction is at the discretion of the manufacturer of the C12.22 Device. Upon determination that the
3932C12.22 Communication Module is in an “insane” state or needs resetting for any reason, the end device
3933may perform a reset of the C12.22 Communication Module by dropping the RESET line for greater than
393450msec and less than 5 sec.
3935
3936 106 Local Routing
3937
3938The LOCAL_ADDRESS_NUMBER field defined in the <identity> byte of the packet is used to facilitate
3939routing of <acse-pdu> among Local Ports and C12.22 Communication Modules. Layer 2 local routing
3940shall be implemented by all C12.22 Devices to facilitate C12.22 Communication Module setup and
3941diagnostics. It is highly recommended that this service be used by C12.22 Communication Modules to
3942route <acse-pdu>s received from one interface and targeting a different interface or Local Port as
3943defined by section “56 Use of Sub-Branches of a Registered ApTitle”, sub-section “Access to Interface
3944and Local Ports”.
3945
3946General Considerations
3947
39481. Each packet sent by a device attached to a Local Port or a C12.22 Communication Module has its
3949 LOCAL_ADDRESS_NUMBER set to the desired destination.
39502. Each packet received by a C12.22 Device with the LOCAL_ADDRESS_NUMBER field set to non-
3951 zero is forward to the requested destination. Because routed packets exist outside the context of a
3952 session on the device doing the routing, packet size for routed packets must not exceed the default
3953 Layer 2 maximum size set by this Standard (64 bytes) to avoid re-segmentation by the C12.22
3954 Device.
39553. Each packet received by a C12.22 Device with the LOCAL_ADDRESS_NUMBER field set to zero is
3956 intended for that device. Such packets may therefore be larger than 64 bytes if a larger size has
3957 been successfully negotiated via the protocol.
3958
3959Routing Rules for C12.22 Devices
3960
3961For the purposes of this section, the word “port” is intended to mean either a Local Port of a C12.22
3962Device or a C12.22 Communications Module interface to a C12.22 Device. The routing rules are applied
3963only after the packet has been verified to be valid and non-duplicate. The LOCAL_ADDRESS_NUMBER
3964refers to a destination port.
3965
3966When the C12.22Device receives a packet which has the LOCAL_ADDRESS_NUMBER equal to zero, it
3967means that the packet is for this C12.22 Device, so such packets should acknowledged (<ack> = 06H)
3968and passed up to the upper layers of this C12.22 Device for processing.
3969
3970If the C12.22 Device receives a packet with a LOCAL_ADDRESS_NUMBER equal to some nonzero port
3971number, the C12.22 Device shall apply the following rules, in this order:
3972
39731. If the destination port is busy (i.e. a packet has been sent to that port but has not yet been
3974 acknowledged by (an <ack> = 06H)), silently discard the packet.
39752. If the destination port does not exist or it is already known to the C12.22 Device that no C12.22
3976 Communications Module is attached to that port, acknowledged by (an <ack> = 06H)the packet and
3977 then either discard it or optionally pass it up to higher layers so that an appropriate Application Layer
3978 error response may be returned
39793. Send an ACK to the source port and then modify the packet, replacing the
3980 LOCAL_ADDRESS_NUMBER in the packet with the source port number. Recalculate the CRC and
3981 forward this packet to the destination port.
3982
3983Routing Rules for C12.22 Communication Modules
3984
171 - LXXXVII -
172
3985For the purposes of this section, the word “port” is intended to mean either a Local Port of a C12.22
3986Device or a C12.22 Communications Module interface to a C12.22 Device. The routing rules are applied
3987only after the packet has been verified to be valid and non-duplicate.
3988
3989When the C12.22 Communication Module receives a packet which has the
3990LOCAL_ADDRESS_NUMBER equal to zero, it means that the packet is for this C12.22 Communication
3991Module, so such packets should be acknowledged (an <ack> = 06H) and passed up to the upper layers of
3992this C12.22 Communication Module for processing.
3993
3994If the C12.22 Communication Module receives a packet which has a LOCAL_ADDRESS_NUMBER other
3995than zero, this LOCAL_ADDRESS_NUMBER signifies where the response (if any) should be sent. The
3996C12.22 Communcation Module should acknowledged (an <ack> = 06H) the packet and pass the packet
3997contents, including the LOCAL_ADDRESS_NUMBER, up to the upper layers of this C12.22
3998Communication Module for processing.
3999
4000 107 Service Sequence States
4001
4002Data Link Layer communications is defined as a series of “Service Sequence States”.
4003
4004Valid states include:
4005
4006Disconnected State: State entered after power-up or upon communication link drop detection. All
4007 parameters defined in section “93 Variable Settings” return to their defaults.
4008
4009Connected State: State established upon detection of a valid message transfer.
Not detected Connected

State
Reset
Detected
Traffic
timeout
Any valid
traffic
Disconnected
State
Break
detected Active State
Reset
Any valid traffic

4010
4011 Figure 7.3: Data Link Layer State Diagram
173 - LXXXVIII -
174
4012
4013108 Layer 1 - Physical Layer
4014
4015The Physical Layer is defined for the Interface between the C12.22 Device and the C12.22
4016Communication Modules.
4017
4018 109 Signal Definition
4019
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 Output Input

supply
6 GND Ground/Common
4020
4021 110 Electrical Properties of Connection
4022
4023The following properties are required for the interface lines:
4024
40251. Each side of the interface shall provide a pull-down resistor to common on its input (Signal #1 for the
4026 C12.22 Device, Signal #2 for the C12.22 Communication Module). This pull-down enables
4027 supervision of the signal line and enables detection of a mated connection on that line. All
4028 transmitters output an idle logical 1, positive voltage, so that connection can be detected.
40292. VPLUS may provide power to the C12.22 Communication Module. If VPLUS does provide power, a
4030 C12.22 Device is expected to provide up to 1.5 W with a voltage range of 6-12V.
40313. If a C12.22 Device does not provide power to VPLUS, it shall be left disconnected allowing a
4032 compliant external power supply to drive VPLUS for the attached C12.22 Communication Module.
40334. The RESET is the means for the C12.22 Device to reset the C12.22 Communication Module. The
4034 RESET signal should be active low with a pulse of 50 ms or greater.
40355. Voltage input high >2.5V, logical 1
40366. Voltage input low level <=0.8V, logical 0
40377. Idle voltage of link is logical 1.
40388. Maximum output voltage shall be less than or equal to the supplied VPLUS voltage or 12V when
4039 VPLUS is not present.
40409. Source impedance of output lines shall be <= 1K Ohms
404110. Input impedance of input lines shall be >= 100K Ohms
404211. Data Rate
4043  Minimum of 300 bits / sec
4044  Nominal of 9600 bits / sec (default)
4045  Maximum of 1 Mbits / sec
404612. All signals shall meet ANSI C37.90.1-2002 requirements.
404713. The C12.22 Device or C12.22 Communication Module should provide line isolation on any and all
4048 physical wire and plug pins exiting from under the meter cover. The insulation must be rated to ANSI
4049 C12.1-2001 insulation 2.5kV test requirements between all voltage and current carrying parts and all
4050 other metallic parts.
405114. All C12.22 Device or C12.22 Communication Module wires, plugs, contacts and metallic parts exiting
4052 the meter cover shall meet electrostatic discharge (ESD) testing to 10kV.
405315. All C12.22 Device or C12.22 Communication Module wires, plugs, contacts and metallic parts exiting
4054 the meter cover shall meet ANSI C62.41-2002 for voltage and current carrying parts.
405516. Maximum connection length is 1 meter at up to 1 Mbits / sec.
4056
4057 111 Mechanical and Environmental Properties
175 - LXXXIX -
176
4058
4059This section defines connectors for the Physical Layer of a C12.22 interface between a C12.22 Device
4060and a C12.22 Communication Module when this connection is exposed externally on the respective
4061parts.
4062
4063This Standard assumes that the environmental protection and strain relief is integrated into the enclosure
4064containing the connector. Modular plug cabling is used to connect from a C12.22 Device to a C12.22
4065Communications Module that will each contain a modular jack for termination. Below are typical parts for
4066the C12.22 Device and C12.22 Communications Module. Equivalent parts are acceptable.
4067
4068Connector for C12.22 Device: RJ11 Jack (typical part AMP520250-2)
4069Connector for C12.22 Communications Module: RJ11 Jack (typical part AMP520250-2)
4070
RJ11 Jack Front View Cable Plug View
Pin 1
1 2 3 - 5 6
4071
4072
4073 Figure 7.4: Jack and Cable Plug Wiring Diagram
4074
4075Figure 7.4 shows the mapping of the signals defined in 7.10.1 to the pins in the 6-pin RJ11 jack and plug.
4076
4077 112 Supervision of the Communications Link
4078
4079Either the C12.22 Communication Module or the C12.22 Device can detect the other by the presence of
4080a marking signal (logical 1) on the corresponding transmit or receive data line. By detecting the “break”
4081condition (continuous logical 0) disconnection can be determined.
177 - XC -
178
4082
4083113 Local Port Communication Protocol Details
4084
4085This section defines the protocol stack used by C12.22 Local Ports.
4086
4087114 Protocol Definition
4088
4089 115 Layer 7 - Application Layer
4090
4091As defined in section “14 Layer 7 - Application Layer”.
4092
4093To access a C12.22 Node or one of its interfaces through a Local Port, a C12.22 Node that is attached
4094through the Local Port does not have to include the <calling-aptitle-element> and <called-aptitle-
4095element> in <acse-pdu>s transmitted. The data link LOCAL_ADDRESS_NUMBER is used as described
4096in section “106 Local Routing”.
4097
4098Optionally, an interface may be used as a proxy to send messages over the C12.22 Network as defined
4099in section “56 Use of Sub-Branches of a Registered ApTitle”. In this case, both the <called-aptitle-
4100element> of the targeted C12.22 Node and the LOCAL_ADDRESS_NUMBER of the interface used to
4101send this message are provided.
4102
4103 116 Layer 6 - Presentation Layer
4104
4105Null layer
4106
4107
4108 117 Layer 5 - Session Layer
4109
4110Null layer
4111
4112
4113 118 Layer 4 - Transport Layer
4114
4115The Local Port shall operate as an ANSI C12.22 Device. As such, Layer 4 shall operate as per section
4116“73 Protocol Details: C12.22 Device to C12.22 Communication Module Interface”. Also, the only
4117services supported in Layer 4 shall be the <tls-negotiate> and the <tls-send-message>.
4118
4119The state diagram of this layer used in this context differs from the one defined in section “88 Service
4120Sequence State”. For point-to-point communication, the following states are defined:
4121
4122Base State: This is the state at which communication begins. At this point the default
4123 data transmission parameters apply.
4124
4125Negotiated State: At this state, the parameters negotiated by the Negotiate Service apply.
4126
4127The relationship between services and service sequence states is:
4128
4129Negotiate: This service is accepted at the Base State only. The successful completion
4130 of this service (including the transmission of the response) transitions
4131 communications to the Negotiated state. This service cannot be used to
4132 negotiate the <rec-packet-size> and <rec-nbr-packet> when communication
4133 with an interface,
4134
4135Send message: This service can be accepted at Base State and Negotiated state to send
4136 and receive Layer 7 messages.
179 - XCI -
180
4137
4138
Base state
Send message service
Traffic timeout
Too many reties Negotiate service
Layer 7 Disconnect service
Negotiated
state Send message service
4139
4140
4141 Figure 8.1: Transport Layer State Diagram
4142
4143 119 Layer 3 - Network Layer
4144
4145Null layer
4146
4147 120 Layer 2 - Data Link Layer
4148
4149As defined in section “90 Layer 2 - Data Link Layer”.
4150
4151Timeouts are fixed for each type of communication link and are defined as follows:
4152
Local Port timeouts Interface Optical port Modem
TRAFFIC TIMEOUT 6 seconds 6 seconds 30 seconds
INTER CHARACTER TIMEOUT 500 milliseconds 500 milliseconds 1 second
RESPONSE TIMEOUT 2 seconds 2 seconds 4 seconds
TURN AROUND DELAY Unspecified 175 microseconds Unspecified
4153
4154 121 Layer 1 - Physical Layer
4155
4156The Physical Layer is not defined in this Standard and is left to the discretion of implementers.
4157
4158122 C12.22 Local Port Communication Using a C12.18 Optical Port
4159
4160Some C12.22 Nodes may implement a Local Port (see definition of Local Port) of the form and type
4161defined in ANSI C12.18. Under this condition two possibilities are considered:
4162
4163The Local Port (such as ANSI Type 2 attached to a C12.22 Device) supports both the ANSI C12.22
4164Standard and ANSI C12.18 Standard. As such, this section describes a methodology of a “smart” C12.18
4165Device (e.g. handheld reader), to determine that the Local Port supports the C12.22 communication
4166protocol, and then choose to communicate using ANSI C12.18 or ANSI C12.22 at its option.
4167The Local Port supports only ANSI C12.22 communication. As such, the C12.22 reader can only
4168communicate (no option) using the C12.22 standard communication protocol.
4169
4170Another possible implementation of a C12.22 Node is one that has an optical port but does not support
4171C12.22 over the optical port. This possibility is not considered in this section.
4172
4173When communicating in ANSI C12.18 compatibility mode, the optical port shall operate as an ANSI
4174C12.18 device. As such, all Physical, Data Link and Application Layer services shall comply with ANSI
4175C12.18.
4176
181 - XCII -
182
4177When communicating in ANSI C12.22 compatibility mode, the optical Local Port shall operate as defined
4178in section “114 Protocol Definition” and Layer 1 (Physical Layer of the optical port) shall operate
4179according to ANSI C12.18 Physical Layer requirements.
4180
4181 123 Establishment of ANSI C12.18 Protocol Compatibility Mode
4182
4183ANSI C12.22 provides optional optical port compatibility with ANSI C12.18.
4184
4185Any C12.18 compatible reading device desiring to successfully connect to a Local Port shall set bit 0 in
4186DATA_FORMAT of the <ctrl> byte to 0 in each transmitted <packet>. This control bit is found in the
4187<packet> defined in section “94 Packet Definition”.
4188
4189Consequently, the C12.22 Node having a Local Port shall also set bit 0 in DATA_FORMAT of the <ctrl>
4190byte in each transmitted <packet> to 0 then enter C12.18 compatibility mode, if supported. If the C12.18
4191compatibility mode is not supported by the Local Port, the C12.22 Node having a Local Port shall either
4192“not acknowledge” any incoming <packet> having DATA_FORMAT bit 0 set to 0 or respond with a <nak>.
4193If the Local Port of the C12.22 Node does support C12.18 communication, it shall communicate
4194according with ANSI C12.18 protocol definition thereafter.
4195
4196The actual protocol implementation type may be confirmed by the reader by inspecting the <std> field
4197returned being zero in the <ident-r> service response from the optical port.
4198
4199 124 Establishment of ANSI C12.22 Protocol Compatibility Mode
4200
4201ANSI C12.22 provides optional optical port compatibility with ANSI C12.22.
4202
4203Any ANSI C12.22 compatible reading device, desiring to successfully connect to a Local Port, shall set
4204bit 0 in DATA_FORMAT of the <ctrl> byte to 1 in each transmitted <packet>. This control bit is found in
4205the <packet> defined in C12.22 Communication Module section “94 Packet Definition”.
4206
4207Consequently, the C12.22 Node having a Local Port shall also set bit 0 in DATA_FORMAT of the <ctrl>
4208byte in each transmitted <packet> to 1 and then enter C12.22 compatibility mode. The C12.22 Nodes
4209shall communicate according with ANSI C12.22 protocol definition thereafter, as described in this
4210Standard.
4211
4212The actual protocol implementation type may be confirmed by the reader by inspecting the <std> field
4213returned being three in the <ident-r> service response from the optical port.
183 - XCIII -
184
4214
4215125 Backward Compatibility
4216Backward compatibility of ANSI C12.22 with ANSI C12.18 and ANSI C12.21 is in relation to Layer 7
4217services, service parameters, Datagram data format and transmission order.
4218
4219ANSI C12.22 is backward compatible with ANSI C12.18 and ANSI C12.21 at the Application Layer. The
4220ANSI C12.22 Application Layer Datagram is formatted in a way which enables ANSI C12.18 or ANSI
4221C12.21 compliant devices and gateways to recognize the ANSI C12.22 Application Layer Datagrams
4222(and services) so that they can take one of the following actions:
4223
4224 reject the datagram; or
4225 strip the ANSI C12.22 additional information to yield a ANSI C12.18 or ANSI C12.21 compliant
4226 datagram in its original form; or
4227 strip the ANSI C12.22 additional information to yield a ANSI C12.18 or ANSI C12.21 equivalent
4228 Datagram for the purpose of interpretation or translation into other protocol.
4229
185 - XCIV -
186
4230
4231ANNEX A - Relays
4232
4233NORMATIVE
4234
4235Description
4236
4237C12.22 Relays provide two basic services: address resolution and message forwarding.
4238
4239C12.22 Message forwarding is an optional service and implemented only if the lower layers do not
4240already provide routing (heterogeneous network). C12.22 Message fowarding is considered less
4241desirable than using lower layer routing since it allows only transmission of C12.22 Messages. This
4242service is accessed by simply sending an <acse-pdu> to a C12.22 Relay with a called ApTitle different
4243than the C12.22 Relay ApTitle. The C12.22 Relay will automatically forward this C12.22 Message to the
4244next C12.22 Relay or next C12.22 Relay on this route.
4245
4246Address resolution is used to map C12.22 ApTitles to the corresponding native address. Two methods
4247are provided to access this service. The first method consists of using a Resolve Service Request with
4248the target ApTiTle as a parameter. The Resolve Service Response contains the native address of the
4249requested C12.22 Node if this C12.22 Node resides on the same C12.22 Network Segment. Future
4250communication with this C12.22 Node can be accomplished by addressing this C12.22 Node with its
4251native address. The second technique consists of simply sending a C12.22 Message to the C12.22 Relay
4252with a called ApTitle different than the C12.22 Relay ApTitle. In this case, the C12.22 Relay performs the
4253address resolution and forwards the information to the target C12.22 Node.
4254
4255A.1 Hierarchical Topology
4256
4257C12.22 Relay services are used between heterogeneous C12.22 Network Segments for forwarding
4258C12.22 traffic. Source and destination addresses of each C12.22 Message are provided respectively by
4259the Calling ApTitle and Called ApTitle as defined in the ACSE application data unit <acse-pdu>. For
4260each C12.22 Message received, the C12.22 Relay extracts the Called ApTitle and compares it to
4261ApTitles contained in its routing tables. If a match is found, the C12.22 Relay forwards this message to
4262the next C12.22 Relay or the final C12.22 Node associated with the Called ApTitle.
4263
4264Routing tables update dynamically upon a successful completion of the Registration Service. The
4265Registration Service is initiated by C12.22 Nodes at installation time and is to be repeated periodically
4266within a time interval that is shorter than that published during the registration process using <reg-time-
4267out>. Routing tables can also contain static routes that are configured manually. C12.22 Relays are
4268organized in a hierarchical structure where a C12.22 Master Relay contains routing information for all
4269accessible devices in the hierarchy and a list of C12.22 Notification Hosts. Other C12.22 Relays maintain
4270only routing information of C12.22 Nodes under them.
4271
4272Is it important to note that C12.22 Relays are also C12.22 Nodes on the C12.22 Network; as such, they
4273must be registered.
4274
4275A.2 C12.22 Master Relays
4276
4277A C12.22 Master Relay contains in its routing table all C12.22 Nodes registered for a specific C12.22
4278service provider. C12.22 Master Relays have some specific responsibilities compared to normal C12.22
4279Relays:
4280 C12.22 Master Relays are responsible for sending registration notification to C12.22 Notification and
4281 Authentication Hosts that are listed in their host tables (see A.3 Registration Notification).
4282 C12.22 Master Relays are the target of all Registration Service requests.
4283 C12.22 Master Relays shall not use default route entries in their routing tables.
187 - XCV -
188
4284
4285A.3 Registration Notification
4286
4287C12.22 Master Relayshall maintain a list of C12.22 Host ApTitles that need to receive registration
4288notifications. C12.22 Master Relaysshall forward a copy of each registration services received to the
4289C12.22 Hosts listed in its hosts notification tables. A notification is a Registration Service Request
4290<register> with the Calling ApTitle set to the ApTitle of the C12.22 Master Relay, the Called ApTitle set to
4291the ApTitle of the host and the ACSE Application Data Unit <acse-pdu> containing the list of the nodes
4292associated with this notification.
4293
4294A.4 Registration Algorithm Details
4295
4296The following steps summarize the algorithm used for routing a Registration Service request.
4297
42981. C12.22 Node with UID Px.Ny attaches to a C12.22 Network Segment.
42992. C12.22 Node Px.Ny sends a Registration Service Request <register> to one or more C12.22 Relays
4300 on the C12.22 Network Segment.
43013. All C12.22 Relays receiving the Registration Service request forward it to higher C12.22 Relay(s) in
4302 the hierarchy until a C12.22 Master Relay is reached or return an error response as appropriate.
43034. The C12.22 Master Relay deletes any duplicate Registration Service requests it received.
43045. The C12.22 Master Relay forwards a copy of the Registration Service request to each C12.22 Host
4305 that needs to be notified, in accordance with its Host registration notification table. A 12.22 Master
4306 Relay can also act as an C12.22 Authentication Host, so its ApTitle may appear in the hosts’
4307 authentication and registration notification table.
43086. The C12.22 Master Relay monitors the responses from all of the C12.22 Hosts that were notified for
4309 a minimum of one <register-r> with an <ok> response code from a C12.22 Authentication Host.
43107. If one or more C12.22 Authentication Hosts respond with an <ok>, the C12.22 Master Relay sends
4311 an <ok> Registration Service response to the registering C12.22 Node by one of the possible
4312 (preferably the shortest) routes. Otherwise it replies with a <nok> and does not add the registering
4313 C12.22 Node to the C12.22 Relays’ routing tables.
43148. If a C12.22 Notification Host that is known to the C12.22 Master Relay does not respond, the C12.22
4315 Master Relay shall cache the notification request for the non-responding C12.22 Host and it shall
4316 retry to notify that C12.22 Host periodically until the C12.22 Notification Host acknowledges (with an
4317 <ok> or a <nok>) the registration notification request, or until the registered C12.22 Node gets de-
4318 registered, whichever occurs first.
4319
4320A.5 C12.22 Node ApTitle Auto-assignment
4321
4322A C12.22 Node that needs to get an ApTitle assigned to it dynamically shall initiate a Registration
4323Service request with the calling ApTitle absent. This Registration Service request includes all the
4324required parameters, except that the registering ApTitle length is set to zero. Also, the native address and
4325device serial number, normally optional, shall be provided for validation.
4326
4327The C12.22 Relay that receives this C12.22 Message has two options:
4328
4329 In the first scheme, the C12.22 Relay directly assigns one of its sub-branches to this C12.22 Node.
4330 The C12.22 Relay modifies the Registration Service request to add the assigned ApTitle as calling
4331 ApTitle and registered ApTitle and forwards the resulting C12.22 Message to the C12.22 Master
4332 Relay. The C12.22 Master Relay processes this C12.22 Message like any other Registration Service
4333 request it receives.
4334 The second scheme consists of forwarding the Registration Service request based on the rules
4335 described in section “56 Use of Sub-Branches of a Registered ApTitle”, Proxy server sub-section.
4336 The C12.22 Master Relay then multicasts this information to all C12.22 Authentication Hosts in its
4337 domain. If authenticated by a C12.22 Authentication Host, the C12.22 Master Relay assigns an
189 - XCVI -
190
4338 ApTitle that is included in the Registration Service response. This response is then sent back to the
4339 registering C12.22 Node.
4340
4341In either case, the registering C12.22 Node retrieves its new Aptitle from the Registration Service
4342response.
4343
4344A.6 C12.22 Master Relay ApTitle Auto-assignment
4345
4346A C12.22 Node that wants to get an ApTitle assigned to it dynamically shall initiate a Registration Service
4347request with the called ApTitle absent. A C12.22 Relay that receives this request has two options:
4348
4349 It can reject it by sending back an <sns> error message.
4350 The C12.22 Relay modifies the Registration Service request to add the called ApTitle. The ApTitle
4351 used can be a static ApTitle in this C12.22 Relay or based on the C12.22 Node serial number or
4352 native address received.
4353
4354The auto-discovery of nearest C12.22 Relays (presented in section “34 Resolve Service”) together with
4355the C12.22 Node ApTitle Auto-assignment and the C12.22 Master Relay ApTitle Auto-assignment can be
4356used to automate the installation of a new C12.22 Node.
4357
4358A.7 Obsolete Routes
4359
4360A C12.22 Node may request removal from the C12.22 Network by sending a Deregistration Service
4361request. This service request is sent to the C12.22 Master Relay that originally received the Registration
4362Service. The C12.22 Relay shall remove all routing information for the requested C12.22 Node only
4363when an <ok> response is return by the C12.22 Master Relay.
4364
4365C12.22 Relays shall also remove routing information of C12.22 Nodes that did not communicate or did
4366not register within the Registration Time-out period (<registration-period>), following notification of the
4367C12.22 Master Relay by the C12.22 Relay.
4368
4369Following the removal of a C12.22 Node, a C12.22 Master Relay shall notify all C12.22 Hosts associated
4370with this C12.22 Node about this removal.
4371
4372A.8 Multiple Routes
4373
4374In some network topologies, messages can propagate through many paths (multiple C12.22 Relays). A
4375C12.22 Node has the option to register to one or more of the available paths. For each path, the C12.22
4376Node shall register with a different ApTitle or a different sub-branch of the same ApTitle. It is the
4377responsibility of the C12.22 Node to maintain the registration of each path to not become obsolete. A
4378C12.22 Client that wants to communicate with a C12.22 Device registered through multiple routes can
4379select the route used for each transmission by using the corresponding ApTitle.
4380
4381A.9 Application Layer Supervision
4382
4383It is assumed that C12.22 ACSE APDUs are transferred through reliable communication links.Any entity
4384that provides Application Layer supervision shall generate a <nok> response to the Calling ApTitle upon
4385discovery of network delivery failure. This assures that the C12.22 Application always gets a response.
4386
4387A.10 Routing
4388
191 - XCVII -
192
4389All routes to C12.22 Nodes are stored in the C12.22 Relay’s routing tables. Each of the routing tables
4390contains ApTitleMask / FwdAddress pairs. An ApTitleMask is represented as dot-delimited numeric or ‘*’
4391strings as shown below.
4392
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.
4393
4394When searching for a forwarding address, the routing tables are parsed sequentially until a match is
4395found or the end of the table is reached. When a match is found and the destination address is another
4396C12.22 Relay, then the ACSE APDU is forwarded to that C12.22 Relay. If the destination is a C12.22
4397Node, then the ACSE APDU is delivered to that C12.22 Node directly on the local C12.22 Network
4398Segment.
4399
4400The following steps summarize the algorithm used for routing any C12.22 Messages:
4401
44021. Arbitrary C12.22 Node on the network wants to send a C12.22 Message to C12.22 Node Px.Ny
44032. A C12.22 Message is sent to one of the local C12.22 Relays with Px.Ny as Called ApTitle, with
4404 interface Ax to C12.22 Node Px.Ny.
44053. Local C12.22 Relay searches for Px.Ny in its routing table and, if found, it forwards the C12.22
4406 Message to it via interface Ay.
44074. If no route is available to forward or deliver this message, a <nok> is returned.
193 - XCVIII -
194
4408
4409ANNEX B - Routing Examples
4410
4411INFORMATIVE
4412
4413B.1 C12.22 Relays With a Single Service Provider
4414
4415The diagram below shows an example of C12.22 Relays and the routing tables associated to each of
4416them. In this diagram, each routing table contains the following information:
4417
4418 the node type
4419 the ApTitle of this node represented as “Pn.Nn” where Pn is the Service Provider code and Nn is the
4420 Subscriber code assigned to this node. For example, ApTitle 2.16.840.1.114223.55.234 represent
4421 Service Provider 2.16.840.1.114223.55 Subscriber code 234
4422 the native address of the next node where to forward messages for this ApTitle
4423
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
4424
4425 Figure B.1: C12.22 Relays and Routing Tables
4426
4427B.2 C12.22 Relays Shared by Multiple Service Providers
4428
4429Each provider of C12.22 services maintains its own hierarchy of C12.22 Relays. To allow sharing of
4430C12.22 Relays between service providers, ApTitles are broken into two parts. The first part identifies the
4431service provider responsible for this c12.22 Device and the second part identifies a subscriber code that
4432makes the entire ApTitle unique. As shown in Figure B.2, C12.22 Relays can take advantage of the
4433ApTitle structure to route C12.22 Messages.
4434
195 - XCIX -
196
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
4435
4436 Figure B.2: C12.22 Relays and Routing Tables for Multiple Service Providers
197 -C-
198
4437
4438ANNEX C - Modifications And Extensions to C12.19- 1997
4439
4440NORMATIVE
4441
4442This Annex describes:
4443C1- New Decade 12, Network Control Tables, which are not currently in
4444 ANSI C12.19-1997.
4445C2- New Decade 13, Relay Control Tables, which are not currently in
4446 ANSI C12.19-1997.
4447C3- Universal ID pattern description of ApTitles
4448C4- Modified Decade 0, General Configuration Tables - addition of network registration and interface
4449 control procedures to Table 07, Procedure Initiate Table.
4450C5- Modified Decade 4, Security Tables – addition of Table 46, Key Table, which is not currently in
4451 ANSI C12.19-1997.
199 - CI -
200
4452
4453ANNEX C1 - DECADE 12: Node network Control Tables
4454
4455This decade contains tables associated with C12.22 Node access to C12.22 Networks.
4456
4457 TABLE 120 Dimension Network Table
4458
4459Table 120 Data Description
4460
4461DIM_NETWORK_TBL (Table 120) specifies the maximum dimensional values for this decade.
4462
4463TYPE DIM_NETWORK_BFLD = BIT FIELD OF UINT8
4464 TIME_STAMP_ENABLE_FLAG : BOOL(0);
4465 PROG_NATIVE_ADDRESS : BOOL(1);
4466 PROG_BROADCAST_ADDRESS : BOOL(2);
4467 STATIC_RELAY : BOOL(3);
4468 STATIC_APTITLE : BOOL(4);
4469 STATIC_MASTER_RELAY : BOOL(5);
4470 CLIENT_RESPONSE_CTRL : BOOL(6);
4471 FILLER : FILL(7..7);
4472END;
4473
4474TYPE DIM_NETWORK_RCD = PACKED RECORD
4475 CONTROL : DIM_NETWORK_BFLD;
4476
4477 NBR_INTERFACES : UINT8;
4478 NBR_REGISTRATIONS : UINT8;
4479 NBR_FILTERING_RULES : UINT16;
4480 NBR_EXCEPTION_HOSTS : UINT16;
4481 NBR_EXCEPTION_EVENTS : UINT16;
4482 NBR_STATISTICS : UINT16;
4483 NBR_MULTICAST_ADDRESSES : UINT8;
4484
4485 NATIVE_ADDRESS_LEN : UINT8;
4486 FILTERING_EXP_LEN : UINT8;
4487END;
4488
4489TABLE DIM_NETWORK_TBL = DIM_NETWORK_RCD;
4490
4491Identifier Value Definition
4492
4493DIM_NETWORK_BFLD
4494 TIME_STAMP_ENABLE_FLAG
4495 FALSE Network statistics table (Table 125) does not
4496 contain time-related information.
4497 TRUE Network statistics table (Table 125) contains
4498 time-related information.
4499
4500 PROG_NATIVE_ADDRESS FALSE Interface native addresses can not be set in the
4501 Interface control table (Table 122).
4502 TRUE Interface native addresses can be set in the
4504
4505 PROG_BROADCAST_ADDRESS
4506 FALSE Interface broadcast addresses can not be set in
4507 the Interface control table (Table 122).
201 - CII -
202
4508 TRUE Interface broadcast addresses can be set in the
4510
4511 STATIC_RELAY FALSE Local relay native static address cannot be set
4512 in the Interface control table (Table 122).
4513 TRUE Local relay native address can be set in the
4515
4516 STATIC_APTITLE FALSE This C12.22 Node cannot be programmed with
4517 a static ApTitle.
4518 TRUE This C12.22 Node can be programmed with a
4519 static ApTitle.
4520
4521 STATIC_MASTER_RELAY FALSE The association with a C12.22 Master Relay
4522 cannot be programmed with a static ApTitle in
4523 the Interface control table (Table 122).
4524 TRUE The association with a C12.22 Master Relay can
4525 be programmed with a static ApTitle in the
4527
4528 CLIENT_RESPONSE_CTRL FALSE The Interface control table (Table 122) is not
4529 capable of providing client response control
4530 parameters.
4531 TRUE The Interface control table (Table 122) is
4532 capable of providing client response control
4533 parameters.
4534
4535DIM_NETWORK_RCD
4536 NBR_INTERFACES 0..255 Maximum number of network interfaces
4537 supported by this implementation.
4538
4539 NBR_REGISTRATIONS 0..255 Maximum number of concurrent registrations
4540 supported by each node. Each registration
4541 provides an independent route to a C12.22
4542 Network.
4543
4544 NBR_FILTERING_RULES 0..65535 Maximum number of filtering rules supported in
4545 the Filtering rules table (Table 124).
4546
4547 NBR_EXCEPTION_HOSTS 0..65535 Maximum number of exception hosts supported
4548 in the Exception report table (Table 123).
4549
4550 NBR_EXCEPTION_EVENTS 0..65535 Maximum number of events supported for each
4551 entry in the Exception report table (Table 123).
4552
4553 NBR_STATISTICS 0..65535 Maximum number of statistics supported in the
4555
4556 NBR_MULTICAST_ADDRESSES
4557 0..255 Maximum number multicast addresses
4558 supported in the Interface control table (Table
4559 122).
4560
4561 NATIVE_ADDRESS_LEN 0..255 Maximum length of a native address supported
4562 by this implementation.
4563
203 - CIII -
204
4564 FILTERING_EXP_LEN 0..255 Maximum number of characters used as
4565 parameter for each filtering condition in the
4566 Filtering rules table (Table 124).
4567
205 - CIV -
206
4568
4569 TABLE 121 Actual Network Table
4570
4572
4573ACT_NETWORK_TBL (Table 121) specifies the actual dimensional values for this decade.
4574
4575TABLE ACT_NETWORK_TBL = DIM_NETWORK_RCD;
4576
4578
4579DIM_NETWORK_BFLD
4580 TIME_STAMP_ENABLE_FLAG
4581 FALSE Network statistics table (Table 125) does not
4582 contain time-related information.
4583 TRUE Network statistics table (Table 125) contains
4584 time-related information.
4585
4586 PROG_NATIVE_ADDRESS FALSE Interface native addresses are not configurable
4587 in the Interface control table (Table 122).
4588 TRUE Interface native addresses are set in the
4590
4591 PROG_BROADCAST_ADDRESS
4592 FALSE Interface broadcast addresses are not
4593 configurable in the Interface control table (Table
4594 122).
4595 TRUE Interface broadcast addresses are set in the
4597
4598 STATIC_RELAY FALSE Local relay native static address is not
4599 configurable in the Interface control table (Table
4600 122).
4601 TRUE Local relay static native address is set in the
4603
4604 STATIC_APTITLE FALSE This C12.22 Node is not programmed with a
4605 static ApTitle.
4606 TRUE This C12.22 Node is programmed with a static
4607 ApTitle.
4608
4609 STATIC_MASTER_RELAY FALSE The association with a C12.22 Master Relay is
4610 not programmed with a static ApTitle in the
4612 TRUE The associated master relay is programmed
4613 with a static ApTitle in the Interface control table
4614 (Table 122).
4615
4616 CLIENT_RESPONSE_CTRL FALSE The Interface control table (Table 122) does not
4617 provide client response control parameters.
4618 TRUE The Interface control table (Table 122) provides
4619 client response control parameters.
4620
4621DIM_NETWORK_RCD
4622 NBR_INTERFACES 0..255 Actual number of network interfaces supported
4623 by this implementation.
4624
207 - CV -
208
4625 NBR_REGISTRATIONS 0..65535 Actual number of concurrent routes supported.
4626
4627 NBR_FILTERING_RULES 0..65535 Actual number of filtering rules available in the
4628 Filtering rules table (Table 124).
4629
4630 NBR_EXCEPTION_HOSTS 0..65535 Actual number of exception hosts available in
4631 the Exception report table (Table 123).
4632
4633 NBR_EXCEPTION_EVENTS 0..65535 Actual number of events supported for each
4634 entry in the Exception report table (Table 123).
4635
4636 NBR_STATISTICS 0..65535 Actual number of statistics supported by the
4638
4639 NBR_MULTICAST_ADDRESSES
4640 0..255 Actual number of multicast addresses supported
4641 in the Interface control table (Table 122)..
4642
4643 NATIVE_ADDRESS_LEN 0..255 Actual length of a native address supported.
4644
4645 FILTERING_EXP_LEN 0..255 Actual number of characters in a filtering
4646 expression used in the Fileting rules table (Table
4647 124).
209 - CVI -
210
4648
4649 TABLE 122 Interface Control Table
4650
4652
4653INTERFACE_CTRL_TBL (Table 122) contains the configuration of each interface supported by this
4654implementation.
4655
4656TYPE INTERFACE_CTRL_ENTRY_RCD = PACKED RECORD
4657 IF ACT_NETWORK_TBL.PROG_NATIVE_ADDRESS THEN
4658 NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
4659 END;
4660 IF ACT_NETWORK_TBL.PROG_BROADCAST_ADDRESS THEN
4661 BROADCAST_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
4662 END;
4663 IF ACT_NETWORK_TBL.STATIC_RELAY THEN
4664 RELAY_NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
4665 END;
4666 IF ACT_NETWORK_TBL.STATIC_APTITLE THEN
4667 NODE_APTITLE : BINARY(20);
4668 END;
4669 IF ACT_NETWORK_TBL.STATIC_MASTER_RELAY THEN
4670 MASTER_RELAY_APTITLE : BINARY(20);
4671 END;
4672 IF ACT_NETWORK_TBL.CLIENT_RESPONSE_CTRL THEN
4673 NBR_OF_RETRY : UINT8;
4674 RESPONSE_TIMEOUT : UINT16;
4675 END;
4676END;
4677
4678TYPE INTERFACE_CTRL_RCD = PACKED RECORD
4679 IF NOT ACT_NETWORK_TBL.STATIC_APTITLE THEN
4680 ELECTRONIC_SERIAL_NUMBER: BINARY(20);
4681 END;
4682 INTERFACE_ENTRIES : ARRAY[ACT_NETWORK_TBL.NBR_INTERFACES]
4683 OF INTERFACE_CTRL_ENTRY_RCD;
4684 MCAST_ADDRESSES : ARRAY[ACT_NETWORK_TBL.NBR_MULTICAST_ADDRESSES]
4685 OF BINARY(20);
4686END;
4687
4688TABLE INTERFACE_CTRL_TBL = INTERFACE_CTRL_RCD;
4689
4690
4692
4693INTERFACE_CTRL_ENTRY_RCD
4694 NATIVE_ADDRESS Native address assigned to this interface. This
4695 address can be pre-configured or dynamically
4696 received from the C12.22 Communication
4697 Module. See section “82 Get Configuration
4698 Service”.
4699
4700 BROADCAST_ADDRESS Native address used to broadcast messages on
4701 the local C12.22 Network Segment. This
4702 address can be pre-configured or dynamically
4703 received from the C12.22 Communication
211 - CVII -
212
4704 Module. See section “82 Get Configuration
4705 Service”.
4706
4707 RELAY_NATIVE_ADDRESS Native address used to access the relay on this
4708 route for the node local C12.22 Network
4709 Segment. When not provide, this field can be
4710 pre-configured or assigned automatically by the
4711 PSEM <resolve> service
4712
4713 NODE_APTITLE Relative or absolute object identifier assigned to
4714 this node. This value can be pre-configured or
4715 dynamically assigned to this node. This field is
4716 encoded as <universal-id-element> or <relative-
4717 uid-element>.
4718
4719 MASTER_RELAY_APTITLE Relative or absolute object identifier assigned to
4720 the C12.22 Master Relay responsible for this
4721 node. This value can be pre-configured or
4722 dynamically assigned to this node. This field is
4723 encoded as <universal-id-element> or <relative-
4724 uid-element>.
4725
4726 NBR_OF_RETRIES The number of retries defines the number of
4727 times a EPSEM request is repeated if the
4728 EPSEM response is not received within a
4729 RESPONSE_TIMEOUT interval.
4730
4731 RESPONSE_TIMEOUT This parameter controls the number of seconds
4732 a C12.22 Client has to wait for an EPSEM
4733 response to an EPSEM request before failing or
4734 sending retries.
4735
4736INTERFACE_CTRL_RCD
4737 ELECTRONIC_SERIAL_NUMBER Universal identifier used by the C12.12 Node
4738 and C12.22 Master Relay in algorithms for the
4739 auto-assignment of the C12.22 Node’s Aptitle.
4740 This identifier is optional and required only if the
4741 ROUTE_APTITLE and
4742 MASTER_RELAY_APTITLE are not pre-
4743 configured.
4744
4745 INTERFACE_ENTRIES Array containing the configuration information
4746 for each interface supported by this
4747 implementation.
4748
4749 MCAST_ADDRESSES Array of relative object identifiers. This field is
4750 encoded as a <relative-uid-element> supported
4751 by this node. The value of 0 is reserved for
4752 unused.
213 - CVIII -
214
4753
4754 TABLE 123 Exception Report Table
4755
4757
4758EXCEPTION_REPORT_TBL (Table 123) is used to configure exception messages that can be sent by
4759this C12.22 Node to C12.22 Hosts.
4760
4761TYPE EXCEPTION_REPORT_ENTRY_RCD = PACKED RECORD
4762 APTITLE_NOTIFY : BINARY(20);
4763 MAX_NUMBER_OF_RETRIES: UINT8;
4764 RETRY_DELAY : UINT16;
4765 EXCLUSION_PERIOD : UINT16;
4766 EVENT_REPORTED : ARRAY[ACT_NETWORK_TBL.NBR_EXCEPTION_EVENTS]
4767 OF TABLE_IDB_BFLD;
4768END;
4769
4770TYPE EXCEPTION_REPORT_RCD = PACKED RECORD
4771 EXCEPTION_REPORT : ARRAY[ACT_NETWORK_TBL.NBR_EXCEPTION_HOSTS]
4772 OF EXCEPTION_REPORT_ENTRY_RCD;
4773END;
4774
4775TABLE EXCEPTION_REPORT_TBL = EXCEPTION_REPORT_RCD;
4776
4778
4779TABLE_IDB_BFLD
4780 TBL_PROC_NBR 0..2047 Event code that triggers this exception report.
4781 For standard event codes, refer to “History &
4782 Event Log Codes” as defined in ANSI C12.19.
4783
4784 STD_VS_MFG_FLAG FALSE Event number is defined in standard.
4785 TRUE Event number is defined by the manufacturer.
4786
4787 SELECTOR Not Used. Senders shall set this field to 0 (zero).
4788 Receivers shall ignore this field
4789
4790EXCEPTION_REPORT_ENTRY_RCD
4791 APTITLE_NOTIFY Called ApTitle for reporting exceptions that are
4792 generated for the associated events.
4793
4794 MAX_NUMBER_OF_RETRIES Maximum numbers of time the C12.22 Node
4795 shall attempt to report an exception. This
4796 process stops after the reception by the node of
4797 a EPSEM <ok> response.
4798 0 Exception report is unconfirmed.
4799 RESPONSE_CONTROL defined in <epsem-
4800 control> shall be set to 2, “Never respond”.
4801 1..255 Exception report is confirmed.
4802 RESPONSE_CONTROL defined in <epsem-
4803 control> shall be set to 0, “Always respond”.
4804
4805 RETRY_DELAY 0..65535 Minimum interval in minutes between two
4806 consecutive retry attempts for the same event.
4807
4808 EXCLUSION_PERIOD 0..65535 Minimum interval in minutes before initiating a
4809 consecutive report for the same event.
215 - CIX -
216
4810
4811 EVENT_REPORTED List of events reported to the associated ApTitle.
4812
4813EXCEPTION_REPORT_RCD
4814 EXCEPTION_REPORT Array containing a list of ApTitles where to
4815 send exception reports for the associated
4816 events.
217 - CX -
218
4817
4818 TABLE 124 Filtering Rules Table
4819
4821
4822FILTERING_RULES_TBL (Table 124) contains a collection of rules used to filter traffic across interfaces.
4823A filtering rule may define actions taken based on information matched such as interface identifier,
4824ApTitle, native address, electronic serial number and data flow. The filtering rules allow use-pattern
4825matching as described in ANNEX C3, Universal ID pattern description of ApTitles.
4826
4827TYPE FILTERING_CONDITION_BFLD = BIT FIELD OF UINT16
4828 ACTION_RULE : UINT(0..3);
4829 LABEL : UINT(4..7);
4830 DIRECTION : UINT(8..11);
4831 CONDITION : UINT(12..15);
4832END;
4833
4834TYPE FILTERING_RULES_ENTRY_RCD = PACKED RECORD
4835 CONDITION : FILTERING_CONDITION_BFLD;
4836 PATTERN : STRING(ACT_NETWORK_TBL.FILTERING_EXP_LEN);
4837END;
4838
4839TYPE RULES_PER_INTERFACE_RCD = PACKED RECORD
4840 FILTERING_RULES : ARRAY[ACT_NETWORK_TBL.NBR_FILTERING_RULES]
4841 OF FILTERING_RULES_ENTRY_RCD;
4842END;
4843
4844TYPE FILTERING_RULES_RCD = PACKED RECORD
4845 RULES_PER_INTERFACE : ARRAY[ACT_NETWORK_TBL.NBR_INTERFACES]
4846 OF RULES_PER_INTERFACE_RCD;
4847END;
4848
4849TABLE FILTERING_RULES_TBL = FILTERING_RULES_RCD;
4850
4852
4853FILTERING_CONDITION_BFLD
4854 ACTION_RULE Defines the action taken after evaluating this
4855 rule.
4856 0 IGNORE, Take no action, continue with next
4857 rule.
4858
4859 1 REJECT, Reject immediately if the associated
4860 condition matches.
4861 2 DENY, Mark as reject if the associated condition
4862 matches. This condition may be allowed by a
4863 following rule.
4864 3 ALLOW, Accept message immediately if the
4865 associated condition matches.
4866 4 GOTO, Continue processing starting at LABEL,
4867 5 COND, Conditionally continue processing at
4868 LABEL immediately if the associated condition
4869 matches.
4870
4871 LABEL Label used by the options 4 and 5 of the
4872 ACTION_RULE field.
4873 0 No label
219 - CXI -
220
4874 1..15 LABEL 1 to LABEL 15
4875
4876 DIRECTION Only messages corresponding to this selection
4877 are tested for the associated condition.
4878 0 Not applicable, don’t care
4879 1 Any <acse-pdu> received by this interface
4880 2 Any <acse-pdu> transmitted from this interface
4881 3 <acse-pdu> transmitted from this interface
4882 directly to a destination on the same C12.22
4883 Network Segment (Not through a C12.22
4884 Relay).
4885 4 <acse-pdu> transmitted from this interface to a
4886 destination using a C12.22 Relay.
4887 5..15 Reserved
4888
4889 CONDITION 0 The condition is TRUE.
4890 1 Any <acse-pdu> with matching calling or called
4891 ApTitle pattern.
4892 2 Any <acse-pdu> with matching calling ApTitle
4893 pattern.
4894 3 Any <acse-pdu> with matching called ApTitle
4895 pattern.
4896 4 Any <acse-pdu> with matching source or
4897 destination native address pattern.
4898 5 Any <acse-pdu> with matching source native
4899 address pattern.
4900 6 Any <acse-pdu> with matching destination
4901 native address pattern.
4902 7 <registration> request with matching <serial-
4903 number> pattern.
4904 8..15 Reserved. Shall be set to 0 (zero).
4905
4906
4907FILTERING_RULES_ENTRY_RCD
4908 CONDITION See FILTERING_CONDITION_BFLD above.
4909
4910 PATTERN Matching pattern that is applied subject to the
4911 CONDITION field.
4912
4913RULES_PER_INTERFACE_RCD
4914 FILTERING_RULES See FILTERING_RULES_ENTRY_RCD above.
4915
4916FILTERING_RULES_RCD
4917 RULES_PER_INTERFACE See RULES_PER_INTERFACE_RCD above.
221 - CXII -
222
4918
4919 TABLE 125 Interface Status Table
4920
4922
4923INTERFACE_STATUS_TBL (Table 125) contains status and information about each interface supported
4924by the implementation.
4925
4926TYPE INTERFACE_STATE_BFLD = BIT FIELD OF UINT8
4927 INTERFACE_ENABLE_FLAG : BOOL(0);
4928 AUTO_REGISTRATION_FLAG : BOOL(1);
4929 DIRECT_MESSAGING_FLAG : BOOL(2);
4931END;
4932
4933TYPE NODE_TYPE_BFLD = BIT FIELD OF UINT8
4934 RELAY_FLAG : BOOL(0);
4935 MASTER_RELAY_FLAG : BOOL(1);
4936 HOST_FLAG : BOOL(2);
4937 NOTIFICATION_HOST_FLAG : BOOL(3);
4938 AUTHENTICATION_HOST_FLAG : BOOL(4);
4939 END_DEVICE_FLAG : BOOL(5);
4940 RESERVED : FILL(6..7);
4941END;
4942
4943TYPE INTERFACE_STATUS_ENTRY_RCD = PACKED RECORD
4944 INTERFACE_NAME : STRING(20);
4945 INTERFACE_STATE : INTERFACE_STATE_BFLD;
4946 NODE_TYPE : NODE_TYPE_BFLD;
4947 IF ACT_NETWORK_TBL.TIME_STAMP_ENABLE_FLAG THEN
4948 INTERFACE_ON_TIME : LTIME_DATE;
4949 INTERFACE_OFF_TIME : LTIME_DATE;
4950 LAST_STAT_RESET_TIME : LTIME_DATE;
4951 LAST_ACCESS_TIME : LTIME_DATE;
4952 END;
4953END;
4954
4955TYPE INTERFACE_STATUS_RCD = PACKED RECORD
4956 INTERFACE_STATUS : ARRAY[ACT_NETWORK_TBL.NBR_INTERFACES]
4957 OF INTERFACE_STATUS_ENTRY_RCD;
4958END;
4959
4960TABLE INTERFACE_STATUS_TBL = INTERFACE_STATUS_RCD;
4961
4963
4964INTERFACE_STATE_BFLD
4965 INTERFACE_ENABLE_FLAG FALSE This interface is deactivated and does not
4966 accept or send messages.
4967 TRUE This interface is functional and accepts and
4968 sends messages.
4969
4970 AUTO_REGISTRATION_FLAG FALSE The C12.22 Communication Module attached to
4971 this interface does not register this C12.22 Node
4972 on the C12.22 Network.
223 - CXIII -
224
4973 TRUE The C12.22 Communication Module attached to
4974 this interface registers this C12.22 Node on the
4975 C12.22 Network.
4976
4977 DIRECT_MESSAGING_FLAG FALSE All messages sent through this interface are
4978 sent via C12.22 Relays.
4979 TRUE For all messages sent through this interface, the
4980 node always tries to resolve the native
4981 addresses. If the native address is available, all
4982 subsequence exchanges are done directly with
4983 the target C12.22 Node.
4984
4985NODE_TYPE_BFLD Identification of the type of the C12.22 Node
4986 exposed through this interface.
4987
4988 RELAY_FLAG An indication of whether or not this C12.22
4989 Node is a C12.22 Relay.
4990
4991 FALSE The C12.22 Node is not a C12.22 Relay. If the
4992 MASTER_RELAY_FLAG is set to TRUE, the
4993 C12.22 Master Relay will not route C12.22
4994 Messages to other C12.22 Nodes.
4995 TRUE The C12.22 Node is a C12.22 Relay. When
4996 MASTER_RELAY_FLAG is also set to TRUE,
4997 the C12.22 Relay is also a C12.22 Master Relay
4998
4999 MASTER_RELAY_FLAG An indication of whether or not this C12.22
5000 Node is a C12.22 Master Relay.
5001
5002 FALSE The C12.22 Node is not a C12.22 Master Relay.
5003
5004 TRUE The C12.22 Node is a C12.22 Master Relay.
5005
5006 HOST_FLAG An indication of whether or not this C12.22
5007 Node is a C12.22 Host. A Host is an un-
5008 embedded application process that runs on a
5009 computer. A non host is a C12.22 embedded
5010 application.
5011
5012 FALSE The C12.22 Node is not a C12.22 Host.
5013
5014 TRUE The C12.22 Node is a C12.22 Host.
5015
5016 NOTIFICATION_HOST_FLAG An indication of whether or not this C12.22
5017 Node is a C12.22 Notification Host.
5018
5019 FALSE The C12.22 Node is not a C12.22 Notification
5020 Host.
5021
5022 TRUE The C12.22 Node is a C12.22 Notification Host.
5023
5024 AUTHENTICATION_HOST_FLAG FLAG An indication of whether or not this C12.22
5025 Node is a C12.22 Authentication Host.
5026
5027 FALSE The C12.22 Node is not a C12.22 Authentication
5028 Host.
5029
225 - CXIV -
226
5030 TRUE The C12.22 Node is a C12.22 Authentication
5031 Host.
5032
5033 END_DEVICE_FLAG An indication whether this C12.22 Node is a
5034 C19.22 End Device, i.e. it has metrological
5035 sensors and C12.19 Tables.
5036
5037 FALSE The C12.22 Node is not a C12.19 End Device.
5038
5039 TRUE The C12.22 Node is a C12.19 End Device.
5040
5041INTERFACE_STATUS_ENTRY_RCD
5042 INTERFACE_NAME This field contains a textual description of
5043 technology used by this interface. This
5044 description can be pre-configured or
5045 dynamically received from the C12.22
5046 Communication Module. See section “82 Get
5047 Configuration Service”.
5048
5049 INTERFACE_STATE See INTERFACE_STATE_BFLD defined above.
5050
5051 NODE_TYPE See NODE_TYPE_BFLD defined above.
5052
5053 INTERFACE_ON_TIME The last time the interface was enabled.
5054
5055 INTERFACE_OFF_TIME The last time the interface was disabled.
5056
5057 LAST_STAT_RESET_TIME The last time the statistics values were reset.
5058
5059 LAST_ACCESS_TIME The last time the interface received or
5060 transmitted any C12.22 Message.
5061
5062INTERFACE_STATUS_RCD
5063 INTERFACE_STATUS Array containing information for each interface
5064 supported by this implementation.
227 - CXV -
228
5065
5066 TABLE 126 Registration Status Table
5067
5069
5070REGISTRATION_STATUS_TBL (Table 126) contains the information and configuration parameters
5071required to register and maintain registrations for one or more routes.
5072
5073TYPE REGISTRATION_ENTRY_RCD = PACKED RECORD
5074 INTERFACE_ID : UINT8;
5075 RELAY_NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
5076 MASTER_RELAY_APTITLE : BINARY(20);
5078 REGISTRATION_DELAY : UINT16;
5079 REGISTRATION_PERIOD : UINT16;
5080 REGISTRATION_COUNT_DOWN : UINT16;
5081END;
5082
5083TYPE REGISTRATION_STATUS_RCD = PACKED RECORD
5084 REGISTRATION : ARRAY[ACT_NETWORK_TBL.NBR_REGISTRATIONS]
5085 OF REGISTRATION_ENTRY_RCD;
5086END;
5087
5088TABLE REGISTRATION_STATUS_TBL = REGISTRATION_STATUS_RCD;
5089
5091
5092REGISTRATION_ENTRY_RCD
5093 RELAY_NATIVE_ADDRESS Native address used to access the C12.22
5094 Relay on this route for the C12.22 Node’s local
5095 C12.22 Network Segment. This field can be pre-
5096 configured or assigned automatically by the
5097 EPSEM <resolve> service.
5098
5099 INTERFACE_ID 0..255 The physical interface number used to attach
5100 this C12.22 Node through this Interface to a
5101 C12.22 Network Segment. This ID is an index in
5102 the INTERFACE_ENTRIES array of the
5104
5105 MASTER_RELAY_APTITLE Relative or absolute object identifier assigned to
5106 the C12.22 Master Relay responsible for this
5107 C12.22 Node.
5108
5109 NODE_APTITLE Relative or absolute object identifier assigned to
5110 this C12.22 Node.
5111
5112
5113 REGISTRATION_DELAY 0..65535 Maximum random delay, in seconds, between
5114 each power up and the automatic issuance of
5115 the first Registration Service request by the
5116 C12.22 Node. This function is disabled when
5117 this field is set to 0 (zero).
5118
5119 REGISTRATION_PERIOD 0..65535 The maximum duration, in minutes, before the
5120 C12.22 Node’s registration expires. The C12.22
5121 Node needs to reregister itself before this period
229 - CXVI -
230
5122 lapses in order to remain registered. This value
5123 may be lowered through Registration Service
5124 parameters.
5125
5126 REGISTRATION_COUNT_DOWN 0..65535 The amount of time in minutes
5127 left before the registration period expires.
5128
5129REGISTRATION_RCD
5130 REGISTRATION Array that contains the registration information
5131 for this C12.22 Node. This array contains more
5132 than one entry only if this C12.22 Node supports
5133 multiple routes. See Annex A.8, Multiple Routes.
231 - CXVII -
232
5134
5135 TABLE 127 Network Statistics Table
5136
5138
5139NETWORK_STATISTICS_TBL (Table 127) contains statistics for each interface supported by the
5140implementation.
5141
5142TYPE NETWORK_STATISTICS_ENTRY_RCD = PACKED RECORD
5144 STATISTIC_ID : TABLE_IDB_BFLD;
5145 VALUE : INT48;
5146END;
5147
5148TYPE NETWORK_STATISTICS_RCD = PACKED RECORD
5149 STATISTICS : ARRAY[ACT_NETWORK_TBL.NBR_STATISTICS]
5150 OF NETWORK_STATISTICS_ENTRY_RCD;
5151END;
5152
5153TABLE NETWORK_STATISTICS_TBL = NETWORK_STATISTICS_RCD;
5154
5156
5157TABLE_IDB_BFLD
5158 TBL_PROC_NBR Identifies the statistic reported. When the
5159 associated STD_VS_MFG_FLAG is set to
5160 FALSE, this field is defined as follows:
5161 0 No statistic reported
5162 1 Number of octets sent
5163 2 Number of octets received
5164 3 Number of <acse-pdu> sent
5165 4 Number of <acse-pdu> received
5166 5 Number of <acse-pdu> forwarded
5167 6 Number of <acse-pdu> dropped
5168 7 Number of transmission errors
5169 8 Number of reception errors
5170 9 Number of collisions
5171 10 Number of message overruns
5172 11 Number of framing errors
5173 12 Number of checksum errors
5174 13 Number of active Associations
5175 14 Number of Associationstimeouts
5176 15 Number of signal carriers lost
5177 16 Signal strength (0-100%)
5178 17 Signal strength (DB)
5179 18 Number of registrations sent
5180 19 Number of registrations received
5181 20 Number of registration denials (received but
5182 rejected)
5183 21 Number of registrations failed (issued but
5184 rejected or lost)
5185 22 Number of deregistrations requested
5186 23..2047 Reserved
5187
5188 STD_VS_MFG_FLAG FALSE The statistic is defined by this standard.
5189 TRUE The statistic is defined by the manufacturer.
5190
233 - CXVIII -
234
5191 SELECTOR Not Used.
5192
5193NETWORK_STATISTICS_ENTRY_RCD
5194 INTERFACE_ID 0..255 The physical interface number used to register
5195 this C12.22 Node. This ID is an index in the
5196 INTERFACE_ENTRIES array of the Interface
5197 control table (Table 122).
5198
5199 STATISTIC_ID See TABLE_IDB_BFLD defined above.
5200
5201 VALUE Statistic reported.
5202
5203NETWORK_STATISTICS_RCD
5204 STATISTICS Array containing a series of statistics. Each
5205 entry contains an identifier and an associated
5206 value.
235 - CXIX -
236
5207
5208ANNEX C2 - DECADE 130 - Relay Control Tables
5209
5210This decade contains tables associated with the management of a C12.22 Relay.
5211
5212 TABLE 130 Dimension Relay Table
5213
5215
5216DIM_RELAY_TBL (Table 130) specifies the maximum dimensional values for this decade.
5217
5218TYPE RELAY_CONFIGURATION_BFLD = BIT FIELD OF UINT8
5219 ASSIGN_APTILE_LOCALLY : BOOL(0);
5221END;
5222
5223TYPE DIM_RELAY_RCD = PACKED RECORD
5224 RELAY_CONFIGURATION : RELAY_CONFIGURATION_BFLD;
5225 NBR_REGISTRATION_ENTRIES : UINT32;
5226 NBR_STATIC_ROUTING_ENTRIES : UINT16;
5227 NBR_ASSIGNED_MASTER_RELAY : UINT16;
5228 NBR_HOSTS : UINT16;
5229END;
5230
5231TABLE 130 DIM_RELAY_TBL = DIM_RELAY_RCD;
5232
5233
5235
5236RELAY_CONFIGURATION_BFLD
5237 ASSIGN_APTILE_LOCALLY Any C12.22 Relay may act to provide ApTitles
5238 that are derived from its registered C12.22 Node
5239 ApTitle to C12.22 Nodes in its domain which do
5240 not register themselves with a C12.22 Master
5241 Relay.
5242 FALSE This relay does not support assignment of
5243 ApTitles locally.
5244 TRUE This relay does support assignment of ApTitles
5245 locally.
5246DIM_RELAY_RCD
5247 NBR_REGISTRATION_ENTRIES 0..4294967295
5248 Maximum number of C12.22 Node registration
5249 entries that can be contained in the Registration
5250 List Table (Table 132) of this C12.22 Relay.
5252
5253 NBR_STATIC_ROUTING_ENTRIES
5254 0.. 65535 Maximum number of static routing rules
5255 supported by this C12.22 Relay.
5256
5257 NBR_ASSIGNED_MASTER_RELAY
5258 0..65535 Maximum number of different C12.22 Master
5259 Relays that can be automatically assigned by
5260 this C12.22 Relay.
5261
237 - CXX -
238
5262 NBR_HOSTS 0..65535 Maximum number of C12.22 Authentication
5263 Hosts and C12.22 Notification Hosts that can be
5264 serviced by this C12.22 Master Relay .
239 - CXXI -
240
5265
5266 TABLE 131 Actual Relay Rable
5267
5269
5270ACT_RELAY_TBL (Table 131) specifies the actual dimensional values for this decade.
5271
5272TABLE 131 ACT_RELAY_TBL = DIM_RELAY_RCD;
5273
5275
5276RELAY_CONFIGURATION_BFLD
5277 ASSIGN_APTILE_LOCALLY Any C12.22 Relay may act to provide ApTitles
5278 that are derived from its registered C12.22 Node
5279 ApTitle to C12.22 Nodes in its domain which do
5280 not register themselves with a C12.22 Master
5281 Relay.
5282 FALSE This relay does not assign ApTitles locally.
5283 TRUE This relay assigns ApTitles locally.
5284DIM_RELAY_RCD
5285 NBR_REGISTRATION_ENTRIES 0..4294967295
5286 Actual number of C12.22 Node registration
5287 entries contained in the Registration List Table
5288 (Table 132) of this C12.22 Relay
5289
5290 NBR_STATIC_ROUTING_ENTRIES
5291 0.. 65535 Actual number of static routing rules supported
5292 by this C12.22 Relay.
5293
5294 NBR_ASSIGNED_MASTER_RELAY
5295 0..65535 Actual number of different C12.22 Master
5296 Relays that can be automatically assigned by
5297 this C12.22 Relay.
5298
5299 NBR_HOSTS 0..65535 Actual number of C12.22 Authentication Hosts
5300 and C12.22 Notification Hosts that are serviced
5301 by this C12.22 Master Relay.
5302
241 - CXXII -
242
5303
5304
5305 TABLE 132 Registration List Table
5306
5308
5309REGISTRATION_LIST_TBL (Table 132) is used to access the registration information of a C12.22
5310Relay. Entries in this table are added upon successful new registration of C12.22 Nodes. Entries are
5311removed for each de-registration service received for a C12.22 Node or for a C12.22 Node for which the
5312REGISTRATION_TIME_OUT timer has expired. To forward a C12.22 Message, a C12.22 Relay shall
5313first attempt to find an entry in this table. If no match was found, the C12.22 Relay shall attempt to
5314forward the C12.22 Message as per static routing information located in the Static Routing table (Table
5315133).
5316
5317TYPE NODE_QUALIFIER_BFLD = BIT FIELD OF UINT8
5318 RELAY_FLAG : BOOL(0);
5319 MASTER_RELAY_FLAG : BOOL(1);
5320 HOST_FLAG : BOOL(2);
5321 NOTIFICATION_HOST_FLAG : BOOL(3);
5322 AUTHENTICATION_HOST_FLAG : BOOL(4);
5323 END_DEVICE_FLAG : BOOL(5);
5324 NEIGHBOR_FLAG : BOOL(6);
5325 APTITLE_ASSIGNED_FLAG : BOOL(7);
5326END;
5327
5328TYPE REGISTRATION_LIST_ENTRY_RCD = PACKED RECORD
5330 NODE_NATIVE_ADDRESS : STRING(ACT_NETWORK_TBL.NATIVE_ADDRESS_LEN);
5331 INTERFACE : UINT8;
5332 NODE_QUALIFIER : NODE_QUALIFIER_BFLD;
5333 NODE_CLASS : BINARY(4);
5334 ELECTRONIC_SERIAL_NUMBER : BINARY(20);
5335 ASSIGNED_MASTER_RELAY : BINARY(20);
5336 REGISTRATION_TIME_OUT : UINT16;
5337 REGISTRATION_COUNT_DOWN : UINT16;
5338 MESSAGES_SENT : UINT48;
5339 MESSAGES_RECEIVED : UINT48;
5340END;
5341
5342TYPE REGISTRATION_LIST_RCD = PACKED RECORD
5343 REGISTRATIONS : ARRAY[ACT_RELAY_TBL.NBR_REGISTRATION_ENTRIES]
5344 OF REGISTRATION_LIST_ENTRY_RCD;
5345END;
5346
5347TABLE 132 REGISTRATION_LIST_TBL = REGISTRATION_LIST_RCD;
5348
5350
5351NODE_QUALIFIER_BFLD
5352 RELAY_FLAG An indication of whether or not this C12.22
5353 Node is a C12.22 Relay.
5354
5355 FALSE The C12.22 Node is not a C12.22 Relay. If the
5356 MASTER_RELAY_FLAG is set to TRUE, the
5357 C12.22 Master Relay will not route C12.22
5358 Messages to other C12.22 Nodes.
243 - CXXIII -
244
5359 TRUE The C12.22 Node is a C12.22 Relay. When
5360 MASTER_RELAY_FLAG is also set to TRUE,
5361 the C12.22 Relay is also a C12.22 Master Relay
5362
5363 MASTER_RELAY_FLAG An indication of whether or not this C12.22
5364 Node is a C12.22 Master Relay.
5365
5366 FALSE The C12.22 Node is not a C12.22 Master Relay.
5367
5368 TRUE The C12.22 Node is a C12.22 Master Relay.
5369
5370 HOST_FLAG An indication of whether or not this C12.22
5371 Node is a C12.22 Host.
5372
5373 FALSE The C12.22 Node is not a C12.22 Host.
5374
5375 TRUE The C12.22 Node is a C12.22 Host.
5376
5377 NOTIFICATION_HOST_FLAG An indication of whether or not this C12.22
5378 Node is a C12.22 Notification Host.
5379
5380 FALSE The C12.22 Node is not a C12.22 Notification
5381 Host.
5382
5383 TRUE The C12.22 Node is a C12.22 Notification Host.
5384
5385 AUTHENTICATION_HOST_FLAG An indication of whether or not this C12.22
5386 Node is a C12.22 Authentication Host.
5387
5388 FALSE The C12.22 Node is not a C12.22 Authentication
5389 Host.
5390
5391 TRUE The C12.22 Node is a C12.22 Authentication
5392 Host.
5393
5394 END_DEVICE_FLAG An indication of whether or not this C12.22
5395 Node is an ANSI C12.19 End Device, i.e. it has
5396 metrological sensors and C12.19 Tables.
5397
5398 FALSE The C12.22 Node is not an ANSI C12.19 End
5399 Device.
5400
5401 TRUE The C12.22 Node is an ANSI C12.19 End
5402 Device.
5403
5404 NEIGHBOR_FLAG FALSE The C12.22 Node does not reside on the same
5405 C12.22 Network Segment of the C12.22 Relay.
5406 TRUE The C12.22 Node resides on the same C12.22
5407 Network Segment of the C12.22 Relay.
5408
5409 APTITLE_ASSIGNED_FLAG FALSE The C12.22 Node uses a statically assigned
5410 ApTitle.
5411 TRUE The C12.22 Node ApTitle is dynamically
5412 assigned by this C12.22 Relay.
5413
5414REGISTRATION_LIST_ENTRY_RCD
245 - CXXIV -
246
5415 NODE_APTITLE ApTitle of a C12.22 Node encoded as
5416 <universal-id-element> or <relative-uid-
5417 element>.
5418
5419 NODE_NATIVE_ADDRESS Native address used to access this node.
5420
5421 INTERFACE Interface ID used to access this node. This ID
5422 can be used as an index in the
5423 INTERFACE_ENTRIES array in the Network
5424 control table (Table 122)
5425
5426 NODE_QUALIFIER See NODE_QUALIFIER_BFLD defined above.
5427
5428 NODE_CLASS Four bytes containing the MANUFARTURER
5429 field as defined in Table 0 of ANSI C12.19-1997
5430 or the DEVICE_CLASS as defined by the
5431 revised ANSI C12.19.
5432
5433 ELECTRONIC_SERIAL_NUMBER Universal identifier used by the auto ApTitle
5434 assignment algorithm.
5435
5436 ASSIGNED_MASTER_RELAY ApTitle of the master relay responsible of this
5437 node encoded as <universal-id-element> or
5438 <relative-uid-element>.
5439
5440 REGISTRATION_TIME_OUT
5441 0..65535 Time out value in minute received in the last
5442 registration request.
5443
5444 REGISTRATION_COUNT_DOWN
5445 0..65535 Count down in minute before removing this
5446 entry. This value is reset to the COUNT_DOWN
5447 at each new C12.22 Message forwarded from
5448 this C12.22 Node.
5449
5450 MESSAGES_SENT Number of messages forwarded to this node
5451 since its installation (initial registration).
5452
5453 MESSAGES_RECEIVED Number of messages forwarded from this node
5454 since its installation (initial registration).
5455
5456REGISTRATION_LIST_RCD
5457 REGISTRATIONS Array containing information each C12.22 Node
5458 registered to this C12.22 Relay.
247 - CXXV -
248
5459
5460 TABLE 133 Static Routing Table
5461
5463
5464STATIC_ROUTING_TBL (Table 133) is used by C12.22 Relays which support static routing to multiple
5465C12.22 Master Relays. When a C12.22 Message is received by a C12.22 Relay, it first tries to locate the
5466destination C12.22 Node (using the message’s called ApTitle field) in its Registration list table (Table
5467132). If this ApTitle is not found and a single C12.22 Master Relay is supported, it forward this message
5468to one of the routes defined in the Registration table (Table 132). If multiple C12.22 Master Relay
5469forwarding is supported, the routing table (Table 133) is used to identify which route to use to forward this
5470message.
5471
5472TYPE ROUTING_TABLE_ENTRY_RCD = PACKED RECORD
5473 APTITLE_PATTERN : STRING(30);
5474 NATIVE_ADDRESS : STRING(ACT_RELAY_TBL.NATIVE_ADDRESS_LEN);
5476END;
5477
5478TYPE ROUTING_TABLE_RCD = PACKED RECORD
5479 ROUTING_TABLE : ARRAY[ACT_NETWORK_TBL.NBR_STATIC_ROUTING_ENTRIES]
5480 OF ROUTING_TABLE_ENTRY_RCD;
5481END;
5482
5483TABLE 133 STATIC_ROUTING_TBL = ROUTING_TABLE_RCD;
5484
5486
5487ROUTING_TABLE_ENTRY_RCD
5488 APTITLE_PATTERN Each entry contains ApTitle patterns that are
5489 associated with forwarding interfaces. An ApTitle
5490 pattern is represented as dot delimited numeric
5491 or ‘*’ strings as shown below (for more details
5492 see ANNEX C3 on “Universal ID pattern
5493 description”).
5494
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).
5495
5496 When searching for a forwarding C12.22 Node’s
5497 address, the routing tables are parsed
5498 sequentially from low array indices toward
5499 higher indices until a match is found or until the
5500 end of a table is reached.
249 - CXXVI -
250
5501 When a match is found and the C12.22 Node’s
5502 destination address is reachable through
5503 another enabled interface (of this relay) to
5504 another remote C12.22 Relay then the C12.22
5505 Message may be forwarded to that relay. If the
5506 destination is a C12.22 Node (e.g. a C12.19 End
5507 Device) then the C12.22 Message may be
5508 delivered to that node directly on the local
5509 network segment, thus completing the delivery
5510 of the message.
5511
5512 INTERFACE_ID Interface number used to forward C12.22
5513 Messages to C12.22 Nodes having an ApTitle
5514 which matches the associated pattern
5515 (APTITLE_PATTERN).
5516
5517 NATIVE_ADDRESS Native address of the C12.22 forwarding Node
5518 on a C12.22 Network Segment that is attached
5519 to this C12.22 Relay.
5520
5521
5522ROUTING_TABLE_RCD
5523 ROUTING_TABLE An array containing a collection of static ApTitle
5524 pattern and corresponding destination used to
5525 forward messages. All entries are evaluated
5526 sequentially, from index 0 to index
5527 NBR_STATIC_ROUTING_ENTRY-1, the search
5528 stop at the first pattern that matches, thus
5529 resulting in the C12.22 Message being
5530 forwarded to the corresponding destination.
251 - CXXVII -
252
5531
5532 TABLE 134 Host Notification Table
5533
5535
5536HOST_NOTIFICATION_TBL (Table 134) contains the list of authentication and notification hosts.
5537
5538TYPE HOST_NOTIFICATION_ENTRY_RCD = PACKED RECORD
5539 HOST_APTITLE : BINARY(20); HOST_TYPE :
5540INTERFACE_STATUS_TBL.NODE_TYPE_BFLD;
5541 NBR_PENDING_NOTIFICATION : UINT16 ;
5542END;
5543
5544TYPE HOST_NOTIFICATION_RCD = PACKED RECORD
5545 NOTIFICATION_RETRY_INTERVAL : UINT16;
5546 NOTIFICATION_TIME_OUT : UINT16;
5547 NOTIFICATION_HOSTS : ARRAY[ACT_RELAY_TBL.NBR_HOSTS]
5548 OF HOST_NOTIFICATION_ENTRY_RCD;
5549END;
5550
5551TABLE 134 HOST_NOTIFICATION_TBL = HOST_NOTIFICATION_RCD;
5552
5554
5555HOST_NOTIFICATION_ENTRY_RCD
5556 HOST_APTITLE ApTitle of an authentication or notification hosts.
5557
5558 HOST_TYPE Defines if this host is used to authenticate
5559 registration and deregistration or need only to be
5560 notified for each registration received (when
5561 AUTHENTICATION_HOST_FLAG or
5562 NOTIFICATION_HOST_FLAG flags are set to
5563 TRUE). See
5564 INTERFACE_STATUS_TBL.NODE_TYPE_BFL
5565 D for more details).
5566
5567 NBR_PENDING_NOTIFICATION 0..65535 Number of notification pending because this
5568 host is not available.
5569
5570HOST_NOTIFICATION_RCD
5571 NOTIFICATION_RETRY_INTERVAL Minimum period between notification retry
5572 attempts. Zero means that the C12.22 Relay will
5573 not attempt to re-send notifications to a non
5574 responsive host. Non zero value will cause the
5575 C12.22 Relay to wait for the stated value in
5576 minutes before retrying to notify a non
5577 responsive host. This applies only to C12.22
5578 Notification or Authentication Hosts.
5579 NOTIFICATION_RETRY Minimum period between each retries to notify a
5580 host. Zero means that the relay will not retry to
5581 send notifications and wait for the corresponding
5582 hosts to connect before sending the pending
5583 notifications.
5584
5585 NOTIFICATION_TIME_OUT Number of minutes after which a pending
5586 notification can be deleted and not sent to the
5587 corresponding host. Zero means never delete.
253 - CXXVIII -
254
5588
5589 NOTIFICATION_EXCLUSION Minimum period before reporting two
5590 consecutive notification of the same C12.22
5591 Host.
5592
5593 NOTIFICATION_HOSTS Array containing a list of C12.22 Authentication
5594 and Notification Hosts.
255 - CXXIX -
256
5595
5596 TABLE 135 Master Relay Assignment Table
5597
5599
5600MASTER_RELAY_ASSIGMENT_TBL (Table 135) is used to define the ApTitle of the C12.22 Master
5601Relays that shall be assigned to C12.22 Nodes based on their registration-time provided serial number
5602pattern. See section “A.6 C12.22 Master Relay ApTitle Auto-assignment” for more detail.
5603
5604TYPE ASSIGNEMENT_ENTRY_RCD = PACKED RECORD
5605 SERIAL_NUMBER_PATTERN : STRING(30);
5606 MASTER_RELAY_ASSIGNED : STRING(30);
5607END;
5608
5609TYPE MASTER_RELAY_ASSIGNEMENT_RCD = PACKED RECORD
5610 MASTER_RELAYS : ARRAY[ACT_RELAY_TBL.NBR_ASSIGNED_MASTER_RELAY]
5611 OF ASSIGNEMENT_ENTRY_RCD;
5612END;
5613
5614TABLE 135 MASTER_RELAY_ASSIGMENT_TBL = MASTER_RELAY_ASSIGNEMENT_RCD;
5615
5617
5618ASSIGNEMENT_ENTRY_RCD
5619 SERIAL_NUMBER_PATTERN The serial number received is compared to each
5620 of these patterns. The search stops at the first
5621 match and the corresponding master relay
5622 ApTitle assigned. This pattern is constructed
5623 following the rules defined in section “ANNEX
5624 C3 - Universal ID Pattern Description of ApTitles”
5625 .
5626
5627 MASTER_RELAY_ASSIGNED ApTitle of the C12.22 Master Relay assigned.
5628
5629MASTER_RELAY_ASSIGNEMENT_RCD
5630 MASTER_RELAYS List of serial number pattern and corresponding
5631 C12.22 Master Relay ApTitle to assign. All
5632 entries are evaluated sequentially, from index 0
5633 to index NBR_ASSIGNED_MASTER_RELAY-1,
5634 the search stop at the first pattern that match
5635 and the corresponding master relay ApTitle is
5636 assigned.
257 - CXXX -
258
5637
5638 TABLE 136 Dynamic Routing Report Table
5639
5641
5642DYNAMIC_ROUTING_REPORT_TBL (Table 136) is used by C12.22 Relays to report their dynamic
5643routing patterns that are dynamically derived from actual traffic patterns and registration. Is intended use
5644of for diagnostic reports.
5645
5646TABLE 136 DYNAMIC_ROUTING_REPORT_TBL =
5647STATIC_ROUTING_TBL.ROUTING_TABLE_RCD;
259 - CXXXI -
260
5648
5649ANNEX C3 - Universal ID Pattern Description of ApTitles
5650
5651Patterns are used in this decade to select ApTitles and Serial numbers. This section describes how these
5652patterns are construct and evaluated.
5653
5654n Universal ID segment value expressed as a decimal number (e.g. “123”).
5655
5656. The (dot) is the Universal ID segment delimiter. Example: “2.20.30” is an Universal ID
5657 with three segments 2, 20, and 30.
5658
5659* Match zero or more branches of the Universal ID. Example: “2.20.*” match “2.20.2” and
5660 “2.20.3.45”.
5661
5662[ ] Delimits and groups a range of Universal ID patters, using the “-“ (minus) as a range
5663 indicator and the “,” (comma) as a range alternatives separator. Example: “2.20.[1-10,40-
5664 50,100].*” will match the universal ID “2.20.1.*” through “2.20.10.*”, “2.20.40.*” through
5665 “2.40.50.*” and “2.20.100.*”.
5666
5667! Reverse the sense result of this mask (interpreted as “not”) immediately on the group or
5668 Universal ID element on its right. The reversal operator applies only to the next segment.
5669 This option can be used with the range delimiter introduced above. Example: “2.20.!
5670 30.100” will reverse the sense of the “30” and match any universal ID which starts with
5671 “2.20” and ends with 100 and does not have 30 in its third segment. Similarly “2.20.!
5672 (30.100)” will reverse the sense of the “30.100” and match any universal ID which starts
5673 with “2.20” and does not end with “30.100”.
5674
5675( ) Groups Universal ID patters. Example: “2.20.[1-10,40-50,100].*” will match the universal
5676 ID “2.20.1.*” through “2.20.10.*”, “2.20.40.*” through “2.40.50.*” and “2.20.100.*”. Within
5677 a group one can introduce the “|” (vertical bar) to introduce Universal ID group
5678 alternatives. The alternatives are processes from left to right until a match is found.
5679 Groups may be nested.
5680? Match this branch of the Universal ID. Example: “2.20.?” match “2.20.2” but not
5681 “2.20.3.45”.
5682
5683pattern{n} Match exactly n repetitions of a pattern, where n is a decimal number. A pattern is any of
5684 the Universal ID constructors described above. Example: “2.20.*.10” will match anything
5685 starting with “2.20” and ending with “.10”, whereas “2.20(.?){3}.10” will match anything
5686 that starts with “2.20” followed by any three segments then ending with “.10”.
5687
5688pattern{n,m} Match exactly n repetitions of a pattern, where n is a decimal number. A pattern is any of
5689 the Universal ID constructors described above. Example: “2.20.*.10” will match anything
5690 starting with “2.20” and ending with “.10”, whereas “2.20(.?){1,3}.10” will match anything
5691 that starts with “2.20” followed by any one to three segments then ending with “.10”.
261 - CXXXII -
262
5692
5693ANNEX C4 - Additions to TABLE 07 - Procedure Initiate Table
5694
5695This Annex describes procedures associated with the Network Control Tables (Decade 10).
5696
5697 PROCEDURE 23 Register
5698
5699The Registration service is used to add and maintain (“keep-alive”) routing information of C12.22 Relays.
5700To be part of C12.22 Network, a node shall send a registration service to one of the C12.22 Relays. This
5701procedure, typically used on the local port (ANSI C12.18), is used to initiate this process.
5702
5703TYPE REGISTER_RESPONSE_RCD = PACKED RECORD
5704 RESPONSE_CODE : UINT8;
5705END;
5706
5707PROCEDURE 23 REGISTER_PROC
5708 RESPONSE = REGISTER_RESPONSE_RCD;
5709
5711
5712RESPONSE_CODE_RCD
5713 RESPONSE_CODE 0..31 PSEM response code received when executing
5714 the C12.22 register service.
5715
5716 PROCEDURE 24 Deregister
5717
5718The deregistration service is used to remove routing information in C12.22 Relays. This procedure,
5719typically used on the local port (ANSI C12.18), is used to initiate this process.
5720
5721PROCEDURE 24 DEREGISTER_PROC
5722 RESPONSE = REGISTER_PROC.REGISTER_RESPONSE_RCD;
263 - CXXXIII -
264
5723
5724 PROCEDURE 25 Network Interface Control
5725
5726This procedure is used to invoke an operation on a specific network interface.
5727
5728TYPE INTERFACE_CONTROL_RESQUEST_BFLD = BIT FIELD OF UINT8
5729 INTERFACE_CTRL : UINT(0..1);
5730 AUTO_REGISTRATION_CTRL : UINT (2..3);
5731 DIRECT_MESSAGING_CTRL : UINT (4..5);
5732 RESET_STATISTICS_FLAG : BOOL(6);
5733 ALL_INTERFACES_FLAG : BOOL(7);
5734END;
5735
5736TYPE INTERFACE_CONTROL_RESQUEST_RCD = PACKED RECORD
5738 INTERFACE_CONTROL : INTERFACE_CONTROL_RESQUEST_BFLD;
5739END;
5740
5741PROCEDURE 25 NETWORK_INTERFACE_CONTROL_PROC
5742 REQUEST = INTERFACE_CONTROL_RESQUEST_RCD;
5743
5745
5746INTERFACE_CONTROL_RESQUEST_BFLD
5747 INTERFACE_CTRL Activate or deactivate the selected network
5748 interface communication hardware.
5749 0 Maintain current state
5750 1 Enable this interface
5751 2 Disable this interface
5752 3 Reset interface
5753
5754 AUTO_REGISTRATION_CTRL Control if the C12.22 Communication Module
5755 register this one on the C12.22 Network.
5757 1 Disable auto-registration
5758 2 Enable auto-registration
5759 3 Force one-time registration now then returns
5760 previous state.
5761
5762 DIRECT_MESSAGING_CTRL Enable or disable direct addressing of nodes on
5763 same network segment.
5765 1 Enable direct communication with target nodes
5766 on the same network segment.
5767 2 Disable direct communication with target nodes
5768 on the same network segment.
5769 3 Reserved
5770
5771 RESET_STATISTICS_FLAG FALSE Do not reset statistics available from the
5772 Interface Status table (Table 125)
5773 TRUE Reset statistics available from the Interface
5774 Status table (Table 125)
5775
5776 ALL_INTERFACES_FLAG FALSE Only the interface specified by the
5777 INTERFACE_ID field is affected.
5778 TRUE All interfaces supported by the node is affected.
5779
265 - CXXXIV -
266
5780INTERFACE_CONTROL_RESQUEST_RCD
5781 INTERFACE_ID 0..255 Interface number assigned to each network
5782 interface available for this node.
5783
5784 INTERFACE_CONTROL See
5785 INTERFACE_CONTROL_RESQUEST_BFLD
5786 defined above.
5787
5788
5789 PROCEDURE 26 Exception Report
5790
5791This procedure is used by an ANSI C12.22 Node to report an exception.
5792
5793TYPE EXCEPTION_REPORT_REQUEST_RCD = PACKED RECORD
5794 EXCEPTION : EXCEPTION_REPORT_TBL.TABLE_IDB_BFLD;
5795END;
5796
5797PROCEDURE 26 EXCEPTION_REPORT_PROC
5798 REQUEST = EXCEPTION_REPORT_REQUEST_RCD;
5799
5801
5802EXCEPTION_REPORT_REQUEST_RCD
5803 EXCEPTION Exception code reported, see
5804 EXCEPTION_REPORT_TBL.TABLE_IDB_BFL
5805 D.
5806
267 - CXXXV -
268
5807
5808ANNEX C5 - Table 46: Key table)
5809
5811
5812KEY_TBL (Table 46) is intended to replace table 45 to store authentication and encryption keys.
5813
5814Note: Although it may be possible to read the EXTENDED_KEY_TBL (Table 46), the values reported
5815(read back) are not defined.
5816
5817TYPE EXTENDED_KEY_ENTRY_RCD = PACKED RECORD
5818 KEY_ID : UINT8;
5819 CIPHER_CODE : UINT8;
5820 KEY_LENGTH : UINT8;
5821 KEY : ARRAY [ ACT_SECURITY_LIMITING_TBL.KEY_LEN] OF UINT8;
5822END;
5823
5824TYPE KEY_RCD = PACKED RECORD
5825 KEY_ENTRIES : ARRAY[ACT_SECURITY_LIMITING_TBL.NBR_KEYS]
5826 OF EXTENDED_KEY_ENTRY_RCD;
5827END;
5828
5829TABLE 46 EXTENDED_KEY_TBL = EXTENDED_KEY_RCD;
5830
5832
5833KEY_ENTRY_RCD
5834 KEY_ID 0..255 Key selector used to match a selection for a key
5835 that is provided by the communication protocol
5836 against a KEY entry in this table.
5837
5838 CIPHER_CODE A cipher code used to encrypt or decrypt tables.
5839 0 DES
5840 1 DESede
5841 2..255 Resereved
5842
5843 KEY_LENTH 0..255 The number of octets used in this KEY entry.
5844
5845 KEY Key to be applied in the authentication and/or
5846 encryption processes.
5847
5848KEY_RCD
5849 KEY_ENTRIES Array of keys used to establish authentication
5850 and/or encryption.
269 - CXXXVI -
270
5851
5852ANNEX D - Universal Identifier
5853
5854NORMATIVE
5855
5856ANSI C12.19 and C12.22 make use of the ISO Universal Identifier to uniquely identify objects. These
5857Universal Identifiers are registered under two branches. The first one used for ANSI C12.19 and related
5858standards to uniquely identify component of the protocol and EDL and TDL.
5859
5860 { iso (1) member-body (2) usa (840) C12.19 standard(10066) }
5861
5862The second one is used for uniquely identifying communicating organizations in ANSI C12.22
5863messaging,specifically this branch is used for calling and called ApTitle when relative object identifiers
5864are used.
5865
5866 { joint-iso-ccitt(2) country(16) us (840) organization(1) }
5867
5868The following table summarizes the list of objects actually defined:
5869
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 compatibility 1.2.840.10066.2.0
with ANSI C12.21 Authentication Service
algorithm 00H.
ANSI C12.22 native Mechanism Name 1.2.840.10066.2.1
ANSI C12.22 ApTitles 2.16.840.1.114223.<service provider id>.<node id>
or any other registered Universal Identifier.
ANSI C12.22 ApTitles 2.16.840.1.114223.[<service provider id>[.<node
Broadcast id>].]0
ANSI C12.22 ApTitles: Multicast 2.16.840.1.114223.[<service provider id>[.<node
id>].]0.xxx
5870
5871ANSI C12.19 Device class
5872
5873C12.19 Device class identifiers shall be globally unique. To assure this, organizations implementing this
5874Standard can register a Device class Universal Identifier.This identifier can be used for one or multiple
5875end device types that share the same data structure (EDL and TDL). This identifier is used by upstream
5876device to understand incoming data structures.
5877
5878Class will be assigned on a first come first serve basis. The first 128 device class IDs are reserved for
5879registration of one way devices. Desired class IDs may also be requested and assigned if available.
5880
5881Also submitted with the registration request are a simple ASCII text TDL file (as defined in Version 2 of
5882ANSI C12.19) and an optional EDL if desired. For one-way devices, EDL and TDL shall include enough
5883information to completely describe any unsolicited messages that the meter might generate. For two-way
5884devices, no specific information is required to be included in the EDL and TDL. NEMA will make all
5885registered EDL/TDL publicly available through an Internet web site for retrieval upon need by client
5886applications or other users.
5887
5888ANSI C12.22 Node ApTitles
5889
271 - CXXXVII -
272
5890C12.22 Node ApTitles shall be globally unique. To assure this, organizations implementing this Standard
5891can register an ApTitle Universal Identifier. Under this registered branch, each organization can assign a
5892unique ApTitle for each node installed on the network. There is no limit on the number of C12.22 Nodes
5893assigned under the same branch.
5894
5895For use in ACSE messages, this ApTitle forms the local root of the application object identifier for either
5896a client or server in a C12.22 Network. This ApTitle is used by C12.22 Networks to propagate C12.22
5897Messages from source to destination over any network architecture.
5898
5899Multicast addressing
5900
5901Multicast addressing is similar to broadcast except that it can be assumed that some communications
5902process has a distribution list (found in network table 122 Interface Control Table) and only routes the
5903message to certain recipients. These recipients, knowledgeable about their membership in the multicast
5904group can respond to such a message as if directly addressed to them.
5905
5906Broadcast and multicast messages shall be targeted to one C12.22 Network Segment. A C12.22 Relay
5907may forward broadcast and multicast C12.22 Messages to other network segments according to its
5908internal configuration.
5909
5910A broadcast is addressed to 2.16.840.1.114223.[<service provider id>[.<node id>].]0. A multicast is
5911addressed to 2.16.840.1.114223.[<service provider id>[.<node id>].]0.xxx where xxx is a specific
5912multicast address. The specific multicast address can be any relative branch of a Universal Identifier.
5913Note that routers and C12.22 Relays may want to optimize the distribution of such messaging.
5914
5915Registration
5916
5917Organizations interested in registering ANSI C12.19 End device classes or ANSI C12.22 ApTitles, shall
5918contact NEMA.
5919
5920ANNEX E - One-way Devices
5921
5922NORMATIVE
5923
5924One-way C12.22 Nodes fall into two categories:
5925
59261. Issuers of ACSE unsolicited messages to the C12.22 Network; or
59272. Issuers of BLURTs (short messages) to a C12.22 Communication Module or a BLURT-only capable
5928 native network.
5929
5930A C12.22 Network shall only process ACSE encapsulated messages. One way devices may not send
5931<short-pdu> on a C12.22 Network. When a C12.22 Node is implemented as a C12.22 Device and a
5932C12.22 Communication Module then the C12.22 Communication Module may be configured to process
5933ACSE messages or short messages. It is then the responsibility of the C12.22 Communication Module to
5934map the short messages into proper ACSE encapsulated messages before presenting the messages to
5935the C12.22 Network.
5936
5937One way C12.22 Nodes shall encode their data for transmission as a PSEM Write Service request,
5938<write>, while setting bit 2, NOTIFICATION, of the <ae-qualifier-value> to 1. This is an indication to the
5939called C12.22 Node that the information provided is about the calling C12.22 Node. Also they shall set
5940the <epsem-control> bits in the RESPONSE_CONTROL to 2, requesting the target not to respond.
5941
5942A C12.22 Communication Module that attaches to a one-way short-message-emitting C12.22 Device
5943shall set bit 2, NOTIFICATION, of the <ae-qualifier-value> to 1 on behalf of the one-way C12.22 Device
5944to assure the correct interpretation of the information provided by the C12.22 Device.
5945
273 - CXXXVIII -
274
5946One-way short-message-emitting devices may only provide up to two-level relative calling ApTitle (.sub-
5947branch-1.sub-branch-2) or none (00H). It is the responsibility of the first C12.22 Relay (receiving the
5948ACSE message from the C12.22 Host for transmission on the C12.22 Network) or the C12.22
5949Communication Module (connecting a C12.22 Device to a C12.22 Network) to extend relative calling
5950ApTitle for proper location of the initiator of the message on the C12.22 Network.
5951
5952A typical example transmitted by a one-way device using ANSI C12.22 has the following ACSE
5953Datagram format:
5954
595560 36 <acse-pdu>
5956 A1 07 <application-context-element>
5957 06 05 2A 86 48 CE 52 1.2.840.10066
5958 A2 05 <called-aptitle-element>
5959 0D 03 <relative-uid-element>
5960 17 A1 21 <relative-uid>
5961 A6 05 <calling-aptitle-element>
5962 0D 03 <relative-uid-element>
5963 17 A3 54 <relative-uid>
5964 A7 03 <calling-entity-qualifier-element>
5965 82 01 <calling-ae-qualifier>
5966 04 NOTIFICATION = “true”
5967 A8 01 <calling-apinvocation-id-element>
5968 02 <calling-apinvocation-id>
5969 BE 0F <user-information-element>
5970 92 <epsem-control>
5971 14 00 00 00 <ed-class>
5972 40 <full-write>
5973 00 03 <tableid>
5974 00 04 <count>
5975 01 02 03 04 <data>
5976 F6 <cksum>
5977
5978The ACSE Datagram format above may be considered to have too much overhead for some
5979technologies used by one-way devices. For this reason a stripped down shorter (BLURT) message format
5980is provided as an alternative. This format has been designed to be mapped to an <acse-pdu>.
5981
5982 <short-pdu> ::= <short-calling-ApTitle> <short-device-class> <psem-write-request>
5983
5984 <short-calling-ApTitle> ::= <byte>+ | 00H {The calling ApTitle is a two-level
5985 relative universal to the locally register root Aptitle
5986 representing the ApTitle and encoded without tag and
5987 length. The value 00H is the null ApTitle, which is an
5988 indication to receiver of this message to fully resolve the
5989 called ApTitle.}
5990
5991 <short-device-class> ::= <byte>+ {The device class is a single level universal ID
5992 representing the C12.22 Host model and encoded
5993 without tag and length. This universal ID shall be
5994 registered as a one-way device class derived from the
5995 root class: 1.2.840.10066.0.<short-device-class>}
5996
5997 <psem-write-request> ::= <write> {As defined in by the PSEM Write Service request in
5998 this Standard. It is the responsibility of the C12.22
5999 Communication Module or C12.22 Node, which
6000 translates the <short-pdu> to an <acse-pdu>, to set bit
6001 2, NOTIFICATION, of the <ae-qualifier-value> to 1 as
6002 an indication to the called C12.22 Node that the
6003 information provided by the write service request is
6004 about the calling C12.22 Node.}
6005
6006The previous example can be encoded as follow using this format:
6007
275 - CXXXIX -
276
600817 A3 54 <relative-uid>
600914 <ed-class>
601040 <full-write>
601100 03 <tableid>
601200 04 <count>
601301 02 03 04 <data>
6014F6 <cksum>
277 - CXL -
278
6015
6016ANNEX F - APDU Response Timeout Algorithm
6017
6018INFORMATIVE
6019
6020The Application Response Time-out is used by a C12.22 Node that issues EPSEM requests to another
6021C12.22 Node and needs to how long to wait for responses. This annex illustrates one possible behavior
6022that an implementer may use in a client application to deal with dynamically changing network latency.
6023
6024This algorithm is applicable both to session and session-less transactions.
6025
6026In this example we set the initial value of the APDU response timeout to 30 seconds and the number of
6027retries to three. Ideally the number of retry attempts when multiplied by the default time out interval
6028length should be set to at least one fifth of the C12.22 session timeout value.
6029
6030The time-out value should be reset to its initial value each time a new session or session-less association
6031is created. Upon timeout, the C12.22 Node may attempt one or more transmissions of the failing request
6032where the number of retries is set to an application provided value and can be programmed in the
6033INTERFACE_CTRL_TBL when implemented.
6034
6035
6036Each time an Application Layer <acse-pdu> response is received, the response time-out duration may be
6037re-calculated and revised to a value that is two times the average response time of previous three
6038responses that were received (use the time-out value for responses that were not received in this
6039calculation).
6040
6041Each time an Application Layer APDU response is not received within the anticipated time interval, the
6042latest timeout interval shall be increased by a factor of two, and then a duplicate Application Layer APDU
6043shall be transmitted as shown in the table below.
6044
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
6045
6046The retransmission process may be performed up to three times. If after three re-transmission attempts
6047the Application Layer does not receive a valid APDU response and the calculated time-out is less than
6048the default time-out value, the time-out value shall be set to the default time-out and up to three more
6049transmission attempts shall be performed.
6050
6051If after three consecutive re-transmission attempts, where the time-out value is greater than the default
6052time-out value and the Application Layer does not receive a valid APDU response an application timeout
6053shall occur and the Application Layer shall return <nett> to its Application Process.
6054
6055The <nett> error response shall be placed in the <epsem>s <response> member of the <acse-pdu>s
6056<user-data-element>. The <acse-pdu>s <called-aptitle-element> in the response shall be set to the value
6057found in the <calling-aptitle-element> of the original request and the <acse-pdu>s <calling-aptitle-
6058element> in the response shall be set to the <called-aptitle-element> value found in the original request.
6059All other fields, such as <calling-entity-qualifier-element>, shall be replicated in the <nett> response.
279 - CXLI -
280
6060
6061If the C12.22 Node is the originator of the request, then the request shall be aborted upon receipt of a
6062<nett> error by the Application Process and terminate its session (if any).
6063
6064If the C12.22 Node is not the originator of the service request (i.e., it is a C12.22 Relay) then it shall not
6065participate in this algorithm.
281 - CXLII -
282
6066
6067ANNEX G - Communication Example
6068
6069INFORMATIVE
6070
6071The following example illustrates an exchange of C12.22 Datagrams:
6072
6073Logon request:
6074
6075
607660 45 <acse-pdu> opening tag and length
6077 A1 07 <application-context-element>
6078 06 05 2A 86 48 CE 52 “1.2.840.10066” ANSI C12.22
6079 A2 0B <called-aptitle>
6080 A2 09 <destination-id>
6081 60 86 48 02 E0 39 8D C8 DE “2.16.840.1.12345.222222”
6082 A6 08 <calling-aptitle>
6083 A2 06 <source-id>
6084 60 86 48 02 E0 39 “2.16.840.1.12345”
6085 AB 07 <mechanism-name-element>
6086 2A 86 48 CE 52 02 00 “1.2.840.10066.2.0” C12.21 compatibility
6087 AC 09 <authentication-value>
6088 08 <auth-length>
6089 00 00 00 00 00 00 00 00 <auth-request>
6090 BE 0F <user-data>
6091 80 0D <epsem-control><service-length>
6092 50 <logon>
6093 12 34 <user-id>
6094 01 02 03 04 05 06 07 08 09 0A <user>
6095
6096Logon response:
6097
609860 15 <acse-pdu> opening tag and length
6099 A1 06 <application-context-element and length
6100 06 05 2A 86 48 CE 52 “1.2.840.10066” ANSI C12.22
6101 A2 01 00 <association-result>
6102 A3 01 00 <result-source-diagnostic>
6103 BE 03 <user-data>
6104 00 <epsem-control>
6105 02 02 <service-length> <invocation-id>
6106 00 <ok>
283 - CXLIII -
284
6107
6108ANNEX H - ANSI C12.22 Application Layer Over TCP/IP (UNIX Implementation)
6109
6110INFORMATIVE
6111
6112This annex is provided as an example of implementing the ANSI C12.22 Application Layer over a
6113Transport Layer different than the one presented in section “73 Protocol Details: C12.22 Device to
6114C12.22 Communication Module Interface”. We have chosen TCP/IP for its popularity and its dominance
6115in the telecommunication industry. This protocol is suitable for transferring ANSI C12.22 information
6116between back-office elements.
6117
6118This example shows the client side of an ANSI C12.22 over TCP/IP link. The client represents a program
6119that want to communicate with the C12.22 Device, the server side can be either an ANSI C12.22 Relay
6120or ANSI C12.22 Device. Before being able to send or receive messages, the client must establish a
6121connection with the TCP CONNECT service. After the connection is established, the application can send
6122and receive Datagrams using the TCP SEND and RECV services.
6123
6124The following is a C code example that shows the basic steeps necessary for a client to connect and
6125transfer Datagrams over TCP/IP.
6126
6127#include <stdio.h>
6128#include <netdb.h>
6129#include <sys/socket.h>
6130
6131void error(char *);
6132
6133int main(int argc, const char **argv)
6134{
6135 unsigned char read_table_0_request[] =
6136 {
6137 0x60, 0x20, // ACSE tag and length
6138 0xA2, 0x0A, // Called Aptitle tag and length
6139 0xA2, 0x08, // Universal Identifier tag and length
6140 0x2A, 0x86, 0x48, 0xCE, 0x52, 0x03, 0x01, 0x43,
6141 0xA6, 0x0A, // Calling Aptitle tag and length
6142 0xA2, 0x08, // Universal Identifier tag and length
6143 0x2A, 0x86, 0x48, 0xCE, 0x52, 0x03, 0x01, 0x06,
6144 0xBE, 0x06, // Application Data tag and length
6145 0x80, // EPSEM control byte
6146 0x04, // EPSEM length
6147 0x02, // Invoke ID
6148 0x30, // Table Read request code
6149 0x00, 0x00 // Table 0
6150 };
6151
6152 unsigned char response[255];
6153 int sockfd, response_length, i;
6154 struct sockaddr_in address;
6155 unsigned long addr;
6156
6157 if (argc != 3)
6158 error("usage: <program-name> <server-ip> <server-port>\n");
6159
6160 if ((int) (addr = inet_addr(argv[1])) == -1)
6161 error("Error in function: inet_addr()\n");
6162
6163 if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1)
6164 error("Error in function: socket()\n");
6165
6166 address.sin_family = AF_INET;
6167 address.sin_port = htons((unsigned short) atol(argv[2]));
6168 address.sin_addr.S_un.S_addr = addr;
6169 memset((void *) &address.sin_zero, 0, (size_t) 8);
6170
6171 if (connect(sockfd, (struct sockaddr *) &address, sizeof(struct sockaddr)) == -1)
6172 error("Error in function: connect()\n");
285 - CXLIV -
286
6173
6174 if (send(sockfd, read_table_0_request, sizeof(read_table_0_request), 0) == -1)
6175 error("Error in function: send()\n");
6176
6177 if ((response_length = recv(sockfd, response, sizeof(response), 0)) == -1)
6178 error("Error in function: recv()\n");
6179
6180 for (i=0; i < response_length; i++)
6181 printf(" %02X", response[i]);
6182 printf("\n");
6183
6184 close(sockfd);
6185 return 0;
6186}
6187
6188void error(char *message)
6189{
6190 printf(message);
6191 exit(1);
6192}
287 - CXLV -
288
6193
6194ANNEX I - CRC Examples
6195
6196INFORMATIVE
6197
6198I.1 Trace
6199This example shows the actual bit manipulations performed in calculation of the frame check sequence
6200(CRC) for an example PSEM packet in compliance with ANSI C12.18 and this document.In order to be in
6201compliance with the CRC calculations, the bit ordering shall be consistent with this example.
6202
6203packet without crc = ee 00 00 00 00 01 20
6204 = 11101110 00000000 00000000 00000000 00000000 00000001 00100000 00000000 00000000
6205LSBit First 01110111 00000000 00000000 00000000 00000000 10000000 00000100 00000000 00000000
6206XOR FF 11111111 11111111
6207
6208Start Tx = 10001000 11111111 00000000 00000000 00000000 10000000 00000100 00000000 00000000
6209Apply P(x) 10001000 00010000 1
6210 00000000 11101111 10000000 00000000 00000000 10000000 00000100 00000000 00000000
6211Apply P(x) 10001000 00010000 1
6212 00000000 01100111 10010000 10000000 00000000 10000000 00000100 00000000 00000000
6213Apply P(x) 1000100 00001000 01
6214 00000000 00100011 10011000 11000000 00000000 10000000 00000100 00000000 00000000
6215Apply P(x) 100010 00000100 001
6216 00000000 00000001 10011100 11100000 00000000 10000000 00000100 00000000 00000000
6217Apply P(x) 1 00010000 00100001
6218 00000000 00000000 10001100 11000001 00000000 10000000 00000100 00000000 00000000
6219Apply P(x) 10001000 00010000 1
6220 00000000 00000000 00000100 11010001 10000000 10000000 00000100 00000000 00000000
6221Apply P(x) 100 01000000 100001
6222 00000000 00000000 00000000 10010001 00000100 10000000 00000100 00000000 00000000
6223Apply P(x) 10001000 00010000 1
6224 00000000 00000000 00000000 00011001 00010100 10000000 00000100 00000000 00000000
6225Apply P(x) 10001 00000010 0001
6226 00000000 00000000 00000000 00001000 00010110 10000000 00000100 00000000 00000000
6227Apply P(x) 1000 10000001 00001
6228 00000000 00000000 00000000 00000000 10010111 10000000 00000100 00000000 00000000
6229Apply P(x) 10001000 00010000 1
6230 00000000 00000000 00000000 00000000 00011111 10000000 10000100 00000000 00000000
6231Apply P(x) 10001 00000010 0001
6232 00000000 00000000 00000000 00000000 00001110 00001010 10010100 00000000 00000000
6233Apply P(x) 1000 10000001 00001
6234 00000000 00000000 00000000 00000000 00000110 10001011 10011100 00000000 00000000
6235Apply P(x) 100 01000000 100001
6236 00000000 00000000 00000000 00000000 00000010 11001011 00011000 00000000 00000000
6237Apply P(x) 10 00100000 0100001
6238 00000000 00000000 00000000 00000000 00000000 11101011 01011010 00000000 00000000
6239Apply P(x) 10001000 00010000 1
6240 00000000 00000000 00000000 00000000 00000000 01100011 01001010 10000000 00000000
6241Apply P(x) 1000100 00001000 01
6242 00000000 00000000 00000000 00000000 00000000 00100111 01000010 11000000 00000000
6243Apply P(x) 100010 00000100 001
6244 00000000 00000000 00000000 00000000 00000000 00000101 01000110 11100000 00000000
6245Apply P(x) 100 01000000 100001
6246 00000000 00000000 00000000 00000000 00000000 00000001 00000110 01100100 00000000
6247Apply P(x) 1 00010000 00100001
6248 00000000 00000000 00000000 00000000 00000000 00000000 00010110 01000101 00000000
6249Apply P(x) 10001 00000010 0001
6250 00000000 00000000 00000000 00000000 00000000 00000000 00000111 01000111 00010000
6251Apply P(x) 100 01000000 100001
6252 00000000 00000000 00000000 00000000 00000000 00000000 00000011 00000111 10010100
6253Apply P(x) 10 00100000 0100001
6254 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00100111 11010110
6255Apply P(x) 1 00010000 00100001
6256 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00110111 11110111
6257XOR FF 11001000 00001000
6258MSBit First 00010011 00010000
6259crc = 1310
289 - CXLVI -
290
6260
6261I.2 C Code Example
6262
6263The following is an example of C code which calculates the <crc> field in a manner compliant with
6264C12.22 layer 2. This code is provided as an example only.
6265
6267
6268unsigned short crc16(unsigned char octet, unsigned short crc);
6269unsigned short crc(int size, unsigned char *packet);
6270
6271
6272unsigned short crc16(unsigned char octet, unsigned short crc)
6273{
6274 int i;
6275
6276 for (i = 8; i; i--)
6277 {
6278 if (crc & 0x0001)
6279 {
6280 crc >>= 1;
6281 if (octet & 0x01)
6282 crc |= 0x8000;
6283 crc = crc ^ 0x8408; /* 0x1021 inverted = 1000 0100 0000 1000 */
6284 octet >>= 1;
6285 }
6286 else
6287 {
6288 crc >>= 1;
6289 if (octet & 0x01)
6290 crc |= 0x8000;
6291 octet >>= 1;
6292 }
6293 }
6294
6295 return crc;
6296}
6297
6298unsigned short crc(int size, unsigned char *packet)
6299{
6300 int i;
6301 unsigned short crc;
6302
6303 crc = (~packet[1] << 8) | (~packet[0] & 0xFF);
6304
6305 for (i=2 ; i<size; i++)
6306 crc = crc16(packet[i], crc);
6307
6308 crc = crc16(0x00, crc);
6309 crc = crc16(0x00, crc);
6310 crc = ~crc;
6311 crc = crc >> 8 | crc << 8;
6312
6313 return crc;
6314}
6315
6316int main()
6317{
6318 unsigned char packet[] = { 0xEE, 0x00, 0x00, 0x00, 0x00, 0x01, 0x20 };
6319
6320 printf("Crc = %04x \n", crc(sizeof(packet), packet));
6321 return 0;
6322}
6323
291 - CXLVII -
292
6324
6325ANNEX J – DES/CDC and DESede/CDC
6326
6327INFORMATIVE
6328
6329This annex contains a description of the encryption algorithms required to implement the ANSI C12.22
6330security mechanism. These algorithms or ciphers are called Data Encryption Standard with Cipher Block
6331Chaining (DES/CBC) and Triple DES with Cipher Block Chaining (DESede/CBC).
6332
6333J.1 Data Encryption Standard - DES
6334The first step to understand the ANSI C12.22 security mechanism is to understand the Data Encryption
6335Standard or DES. DES is a block cipher that can encrypt and decrypt 8 bytes of information at one time.
6336Encryption is controlled by a symmetrical key of 56 bits. Symmetrical key means that both side of a
6337transaction must have the same key to be able to encrypt and decrypt successfully a piece of
6338information. DES Keys are store as 8 octets quantities where bits 1 to 7 of each byte contains valid key
6339information. Bit 0 (least significant bit) is not used by the cipher and must be set to an odd parity. If you
6340are not already familiar with DES, a complete description of this algorithm is presented later in this
6341annex. The following is an example of a DES encryption:
6342
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
6343
6344J.2 DESede
6345DESede consists of applying DES three times on the same information. This way, key length is extended
6346to 24 bytes that make it harder to crack. The first step of DESede consists of encrypting a plain text with
6347the first 8 bytes of the key. The result is after decrypted with the next 8 bytes of the key. The last step
6348consists of encrypting again the result with the last 8 bytes of the key. Per example:
6349
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
6350
6351J.3 CBC
6352Both DES and DESede are capable of encrypting and decrypting only 8 bytes of information. To encrypt
6353and decrypt variable size messages, a technique called cipher block chaining or CBC is used. For
6354encryption, this technique consists of the following steps:
6355
63561. Add the necessary padding to the plain text to adjust its length to a multiple of 8 octets.
63572. Exclusive or (XOR) the first 8 octets of plain text (P1) with the Initialization Vector (IV) to produce
6358 (X1).
63593. Encrypt the value (X1) to produce the first 8 octets of cipher text (C1).
63604. XOR the next 8 octetsof plain text (P2) with the first 8 octets of cipher text (C1) to produce (X2).
63615. Encrypt the value (X2) to produce the next 8 octets of cipher text (C2).
63626. Continue this process until the end of the plain text (Pn)
6363
293 - CXLVIII -
294
Key IV P1 P2 Pn
XOR XOR … XOR
X1 X2 Xn
Encrypt Encrypt Encrypt
6364 C1 C2 Cn
6365
6366
6367For decryption, this technique consists of the following steps:
63681. Decrypt the first 8 octets of cipher text (C1) to produce (X1).
63692. XOR the value (X1) with the Initialization Vector (IV) to produce the first 8 bytes of plain text (P1).
63703. Decrypt the next 8 octets of cipher text (C2) to produce (X2).
63714. XOR the value (X2) with the first 8 octets of cipher text (C1) to produce the next 8 octets of plain text
6372 (P2).
63735. Continue this process until the end of the cipher text (Cn)
6374
IV Key C1 C2 Cn
Decrypt Decrypt Decrypt
X1 X2 Xn
XOR XOR … XOR
6375 P1 P2 Pn
6376
6377In this document, plain text represents <app-data> unencrypted, the initialization vector represents the
6378<iv>, and the cipher text represents <app-data> encrypted.
6379
6380J.4 Legal Issues
6381Cryptographic devices implementing this standard may be covered by U.S. and foreign patents issued to
6382the International Business Machines Corporation. However(IBM). However, IBM has granted
6383nonexclusive, royalty-free licenses under the patents to make, use and sell apparatus, which complies
6384with the standard. The terms, conditions, and scope of the license are set out in notices published in the
6385May 13, 1975 and August 31, 1976 issues of the Official Gazette of the United States Patent and
6386Trademark Office (9434 O"G" 452 and 949 O.G. 1717).
6387
6388J.5 DES Implementation
6389The DES algorithm, adopted by the U.S. government in 1977, is a block cipher that transforms 64-bit
6390data blocks under a 56-bit secret key, by means of permutation and substitution. The following is a
6391description of how to use the DES algorithm to encrypt one 64-bit block.
6392
6393Step 1
6394
6395Get a 64-bit key.
6396
6397Step 2
295 - CXLIX -
296
6398
6399Perform the following permutation on the 64-bit key. The most significant bit of each byte is discarded,
6400reducing the key to 56 bits. Bit 1 of the permuted block is bit 57 of the original key, bit 2 is bit 49, and so
6401on with bit 56 being bit 4 of the original key.
6402
640357 49 41 33 25 17 9 1 58 50 42 34 26 18
640410 2 59 51 43 35 27 19 11 3 60 52 44 36
640563 55 47 39 31 23 15 7 62 54 46 38 30 22
640614 6 61 53 45 37 29 21 13 5 28 20 12 4
6407
6408Split the permuted key into two halves. The first 28 bits are called C[0] and the last 28 bits are called
6409D[0].
6410
6411Start with i = 1.
6412
6413Step 3, 4
6414
6415Perform one or two circular left shifts on both C[i-1] and D[i-1] to get C[i] and D[i], respectively. The
6416number of shifts per iteration is given in the table below.
6417
6418Iteration # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
6419Left Shifts 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1
6420
6421Step 5
6422
6423Permute the concatenation C[i]D[i] as indicated below. This will yield K[i], which is 48 bits long.
6424
642514 17 11 24 1 5 3 28 15 6 21 10
642623 19 12 4 26 8 16 7 27 20 13 2
642741 52 31 37 47 55 30 40 51 45 33 48
642844 49 39 56 34 53 46 42 50 36 29 32
6429
6430Loop back to Step 3 until K[16] has been calculated.
6431
6432Step 6
6433
6434Get a 64-bit data block. If the block is shorter than 64 bits, it should be padded as appropriate for the
6435application.
6436
6437Step 7
6438
6439Perform the following permutation on the data block.
6440
644158 50 42 34 26 18 10 2 60 52 44 36 28 20 12 4
644262 54 46 38 30 22 14 6 64 56 48 40 32 24 16 8
644357 49 41 33 25 17 9 1 59 51 43 35 27 19 11 3
644461 53 45 37 29 21 13 5 63 55 47 39 31 23 15 7
6445
6446Split the block into two halves. The first 32 bits are called L[0], and the last 32 bits are called R[0].
6447
6448Start with i = 1.
6449
6450Step 8
6451
6452Expand the 32-bit R[i-1] into 48 bits according to the bit-selection function below.
6453
645432 1 2 3 4 5 4 5 6 7 8 9
6455 8 9 10 11 12 13 12 13 14 15 16 17
645616 17 18 19 20 21 20 21 22 23 24 25
645724 25 26 27 28 29 28 29 30 31 32 1
6458
297 - CL -
298
6459Step 9
6460
6461Exclusive-or E(R[i-1]) with K[i].
6462
6463Step 10
6464
6465Break E(R[i-1]) xor K[i] into eight 6-bit blocks. Bits 1-6 are B[1], bits 7-12 are B[2], and so on with bits 43-
646648 being B[8].
6467
6468Substitute the values found in the S-boxes for all B[j]. Start with j = 1. All values in the S-boxes should be
6469considered 4 bits wide. Take the 1st and 6th bits of B[j] together as a 2-bit value indicating the row in S[j].
6470Take the 2nd through 5th bits of B[j] together as a 4-bit value indicating the column in S[j].
6471
6472S[1]
647314 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
6474 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
6475 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
647615 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
6477
6478S[2]
647915 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
6480 3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
6481 0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
648213 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
6483
6484S[3]
648510 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
648613 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
648713 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
6488 1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12
6489
6490S[4]
6491 7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
649213 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
649310 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
6494 3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
6495
6496S[5]
6497 2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
649814 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
6499 4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
650011 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
6501
6502S[6]
650312 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
650410 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
6505 9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
6506 4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
6507
6508S[7]
6509 4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
651013 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
6511 1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
6512 6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
6513
6514S[8]
651513 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
6516 1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
6517 7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
6518 2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
6519
6520Step 11
6521
6522Permute the concatenation of B[1] through B[8] as indicated below.
6523
652416 7 20 21 29 12 28 17
6525 1 15 23 26 5 18 31 10
299 - CLI -
300
6526 2 8 24 14 32 27 3 9
652719 13 30 6 22 11 4 25
6528
6529Step 12
6530
6531Exclusive-or the resulting value with L[i-1]. Thus, all together, your R[i] = L[i-1] xor P(S[1](B[1])...S[8]
6532(B[8])), where B[j] is a 6-bit block of E(R[i-1]) xor K[i].
6533
6534Step 13
6535
6536L[i] = R[i-1].
6537
6538Loop back to Step 8 until K[16] has been applied.
6539
6540Step 14
6541
6542Perform the following permutation on the block R[16]L[16].
6543
654440 8 48 16 56 24 64 32 39 7 47 15 55 23 63 31
654538 6 46 14 54 22 62 30 37 5 45 13 53 21 61 29
654636 4 44 12 52 20 60 28 35 3 43 11 51 19 59 27
654734 2 42 10 50 18 58 26 33 1 41 9 49 17 57 25
6548
6549To decrypt, use the same process, but just use the keys K[i] in reverse order. That is, instead of applying
6550K[1] for the first iteration, apply K[16], and then K[15] for the second, on down to K[1].
6551
301 - CLII -
302
6552
6553J.6 DES Code Example
6554
6555The following is an example of C code that encrypts a data block of 64 bits using a key of 56 bits. This
6556code is provided as an example only, and is not required for compliance with the Data Encryption
6557Standard.
6558
6560#include <stdlib.h>
6561typedef unsigned char uint8;
6562
6563static uint8 perm1[56] = {
6564 57, 49, 41, 33, 25, 17, 9, 1, 58, 50, 42, 34, 26, 18,
6565 10, 2, 59, 51, 43, 35, 27, 19, 11, 3, 60, 52, 44, 36,
6566 63, 55, 47, 39, 31, 23, 15, 7, 62, 54, 46, 38, 30, 22,
6567 14, 6, 61, 53, 45, 37, 29, 21, 13, 5, 28, 20, 12, 4
6568};
6569
6571 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
6572 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 1,
6573 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43,
6574 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 29
6575};
6576
6578 14, 17, 11, 24, 1, 5, 3, 28, 15, 6, 21, 10, 23, 19, 12, 4,
6579 26, 8, 16, 7, 27, 20, 13, 2, 41, 52, 31, 37, 47, 55, 30, 40,
6580 51, 45, 33, 48, 44, 49, 39, 56, 34, 53, 46, 42, 50, 36, 29, 32
6581};
6582
6584 58, 50, 42, 34, 26, 18, 10, 2, 60, 52, 44, 36, 28, 20, 12, 4,
6585 62, 54, 46, 38, 30, 22, 14, 6, 64, 56, 48, 40, 32, 24, 16, 8,
6586 57, 49, 41, 33, 25, 17, 9, 1, 59, 51, 43, 35, 27, 19, 11, 3,
6587 61, 53, 45, 37, 29, 21, 13, 5, 63, 55, 47, 39, 31, 23, 15, 7,
6588};
6589
6591 32, 1, 2, 3, 4, 5, 4, 5, 6, 7, 8, 9, 8, 9, 10, 11,
6592 12, 13, 12, 13, 14, 15, 16, 17, 16, 17, 18, 19, 20, 21, 20, 21,
6593 22, 23, 24, 25, 24, 25, 26, 27, 28, 29, 28, 29, 30, 31, 32, 1,
6594};
6595
6597 16, 7, 20, 21, 29, 12, 28, 17, 1, 15, 23, 26, 5, 18, 31, 10,
6598 2, 8, 24, 14, 32, 27, 3, 9, 19, 13, 30, 6, 22, 11, 4, 25,
6599};
6600
6602 40, 8, 48, 16, 56, 24, 64, 32, 39, 7, 47, 15, 55, 23, 63, 31,
6603 38, 6, 46, 14, 54, 22, 62, 30, 37, 5, 45, 13, 53, 21, 61, 29,
6604 36, 4, 44, 12, 52, 20, 60, 28, 35, 3, 43, 11, 51, 19, 59, 27,
6605 34, 2, 42, 10, 50, 18, 58, 26, 33, 1, 41, 9, 49, 17, 57, 25,
6606};
6607
6608static uint8 sboxes[8][64] = {
6609{
6610 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,
6611 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,
6612},{
6613 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,
6614 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,
6615},{
6616 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,
6617 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,
6618},{
6619 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,
6620 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,
6621},{
303 - CLIII -
304
6622 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,
6623 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,
6624},{
6625 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,
6626 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,
6627},{
6628 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,
6629 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,
6630},{
6631 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,
6632 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,
6633}};
6634
6635static uint8 keys[16][48];
6636
6637/**************************************************************************/
6638void Permutation(uint8 *dst, uint8 *src, uint8 lgn, uint8 *perm_table)
6639{
6640 uint8 tmp[64];
6641
6642 if (src == NULL)
6643 {
6644 src = tmp;
6645 memcpy(src, dst, 64);
6646 }
6647
6648 for (; lgn > 0; lgn--, dst++, perm_table++)
6649 *dst = src[*perm_table - 1];
6650}
6651
6652/**************************************************************************/
6653void Xor(uint8 *dst, uint8 *src, uint8 lgn)
6654{
6655 for (; lgn > 0; lgn--, dst++, src++)
6656 *dst ^= *src;
6657}
6658
6659/**************************************************************************/
6660void Copy(uint8 *dst, uint8 *src, uint8 lgn)
6661{
6662 for (; lgn > 0; lgn--, dst++, src++)
6663 *dst = *src;
6664}
6665
6666/**************************************************************************/
6667void SBoxes(uint8 *dst, uint8 *src, uint8 *sbox)
6668{
6669 int i;
6670
6671 i = src[4];
6672 i |= src[3] << 1;
6673 i |= src[2] << 2;
6674 i |= src[1] << 3;
6675 i |= src[5] << 4;
6676 i |= src[0] << 5;
6677
6678 i = sbox[i];
6679
6680 dst[3] = i & 1;
6681 dst[2] = i >> 1 & 1;
6682 dst[1] = i >> 2 & 1;
6683 dst[0] = i >> 3 & 1;
6684}
6685
6686/**************************************************************************/
6687void Des(uint8 *_key, uint8 *_data, int _encrypt)
6688{
6689 uint8 key[64], data[64], right[48];
6690 int i, j;
6691
6692 Permutation(key, _key, 56, perm1);
6693
305 - CLIV -
306
6694 for (i = 1; i <= 16; i++)
6695 {
6696 Permutation(key, NULL, 56, perm2);
6697
6698 if (i != 1 && i != 2 && i != 9 && i != 16)
6699 Permutation(key, NULL, 56, perm2);
6700
6701 Permutation(keys[_encrypt ? i - 1 : 16 - i], key, 48, perm3);
6702 }
6703
6704 Permutation(data, _data, 64, perm4);
6705
6706 for (i = 1; i <= 16; i++)
6707 {
6708 Permutation(right, data + 32, 48, perm5);
6709 Xor(right, keys[i - 1], 48);
6710
6711 for (j = 0; j < 8; j++)
6712 SBoxes(right + 4 * j, right + 6 * j, sboxes[j]);
6713
6714 Permutation(right, NULL, 32, perm6);
6715 Xor(right, data, 32);
6716 Copy(data, data + 32, 32);
6717 Copy(data + 32, right, 32);
6718 }
6719
6720 Copy(_data, data + 32, 32);
6721 Copy(_data + 32, data, 32);
6722 Permutation(_data, NULL, 64, perm7);
6723}
6724
307 - CLV -
308
6725
6726J.7 DES Trace Example
6727
6728This example shows the bit manipulations performed in each step in compliance with the Data
6729Encryption Standard.
6730
6731Initialize keys
6732 Step 1: Key = 1100110100111000111110000001111110000000111111100010001100001110
6733 Step 2: Permutation = 00110101001001010110011000101110100010101001101011111110
6734 Step 3: Rotation = 01101010010010101100110001001101000101010011010111111101
6735 Step 5: keys[1] = 010001101011000010010011010000111001110101101111
6736 Step 3: Rotation = 11010100100101011001100010001010001010100110101111111011
6737 Step 5: keys[2] = 110010000110001100100101011111001101011101011010
6738 Step 3: Rotation = 10101001001010110011000100010100010101001101011111110111
6739 Step 4: Rotation = 01010010010101100110001000111000101010011010111111101110
6740 Step 5: keys[3] = 100000011001111100011001100111011111010001101010
6741 Step 3: Rotation = 10100100101011001100010001100001010100110101111111011101
6742 Step 4: Rotation = 01001001010110011000100011010010101001101011111110111010
6743 Step 5: keys[4] = 010001010011001011100011111011001111111001100000
6744 ...
6745 Skipping keys[5] to keys[15]
6746 ...
6747 Step 3: Rotation = 00110101001001010110011000101110100010101001101011111110
6748 Step 5: keys[16] = 101000100100110101101000111111101110111001001010
6749
6750Process data block
6751 Step 6: Data = 1100110100111000111110000001111110000000111111100010001100001110
6754 Step 9: Xor = 010111000001101110011110000101100110001000111111
6755 Step 10: SBoxes = 10110011000011110010010111111011
6756Step 11: Permutation = 11001010110100100111111011001011
6757 Step 12: Xor = 11101111111111001101011110000010
6758 Step 13: Copy = 0011010101100110101011111110100011101111111111001101011110000010
6760 Step 9: Xor = 101111011001110011011100000101100010101101011111
6761 Step 10: SBoxes = 01110110111101000010111010100010
6763 Step 12: Xor = 01100001010001010011100001110111
6764 Step 13: Copy = 1110111111111100110101111000001001100001010001010011100001110111
6766 Step 9: Xor = 001100011011010100010011000000101111011111000100
6767 Step 10: SBoxes = 10111001110001110010101001101000
6769 Step 12: Xor = 01110111000001011000000000000000
6770 Step 13: Copy = 0110000101000101001110000111011101110111000001011000000000000000
6772 Step 9: Xor = 011111111101101011101000001011001111111001100000
6773 Step 10: SBoxes = 10001110100111000111010111100111
6775 Step 12: Xor = 00000101110110110000010110001110
6776 Step 13: Copy = 0111011100000101100000000000000000000101110110110000010110001110
6777 ...
6778 Skipping round 5 to 15
6779 ...
6781 Step 9: Xor = 110010001001101000111010010101001001000111100111
6782 Step 10: SBoxes = 11001111100000101111011101110111
6784 Step 12: Xor = 01101110110110110110010001000010
6785 Step 13: Copy = 1101011011101001010100111111011001101110110110110110010001000010
6786 Step 14: Result = 0011100011011011110001100111000010011010011001101111111110110010
309 - CLVI -
310
6787
6788J.8 CBC Code Example
6789
6790The following is an example of C code that encrypts and decrypts messages of variable length, however
6791message length must be a multiple of 8 bytes. These procedures can be used for both DES/CBC or
6792DESede/CBC depending of the key length provided (8 bytes for DES and 24 bytes for DESede). This
6793code is provided as an example only, and is not required for compliance with the either DES/CBC or
6794DESede/CBC.
6795
6796static uint8 des_iv[64] = {
6797 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,
6798 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
6799};
6800
6801static uint8 des_key[64] = {
6802 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,
6803 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
6804};
6805
6806static uint8 des_ede_iv[64] = {
6807 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,
6808 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
6809};
6810
6811static uint8 des_ede_key[192] = {
6812 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,
6813 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,
6814 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,
6815 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,
6816 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,
6817 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
6818};
6819
6820static uint8 data[192] = {
6821 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,
6822 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,
6823 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,
6824 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,
6825 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,
6826 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
6827};
6828
6829/**************************************************************************/
6830void CbcEncrypt(uint8 *data, int data_length, uint8 *key, int key_length, uint8 *iv)
6831{
6832 int lgn = data_length;
6833
6834 while (data_length > 0)
6835 {
6836 if (data_length == lgn)
6837 Xor(data, iv, 64);
6838 else
6839 Xor(data, data-64, 64);
6840
6841 Des(key, data, 1);
6842 if (key_length == 192)
6843 {
6844 Des(key+64, data, 0);
6845 Des(key+128, data, 1);
6846 }
6847 data += 64;
6848 data_length -= 64;
6849 }
6850}
311 - CLVII -
312
6851
6852/**************************************************************************/
6853void CbcDecrypt(uint8 *data, int data_length, uint8 *key, int key_length, uint8 *iv)
6854{
6855 data += data_length - 64;
6856
6857 while (data_length > 0)
6858 {
6859 if (key_length == 192)
6860 {
6861 Des(key+128, data, 0);
6862 Des(key+64, data, 1);
6863 }
6864 Des(key, data, 0);
6865
6866 if (data_length > 64)
6867 Xor(data, data-64, 64);
6868 else
6869 Xor(data, iv, 64);
6870
6871 data_length -= 64;
6872 data -= 64;
6873 }
6874}
6875
6876/**************************************************************************/
6877void Print(char *text, uint8 *data, int data_length)
6878{
6879 int i, byte;
6880
6881 printf(text);
6882
6883 for (i=0, byte=0; i<data_length; i++)
6884 {
6885 byte <<= 1;
6886 byte |= data[i];
6887 if ((i % 8) == 7)
6888 {
6889 printf("%02X", byte);
6890 byte = 0;
6891 }
6892 }
6893
6894 printf("\n");
6895}
6896
6897/**************************************************************************/
6898int main()
6899{
6900 Print("Key: ", des_key, sizeof(des_key));
6901 Print("IV: ", des_iv, sizeof(des_iv));
6902 Print("Plain text: ", data, sizeof(data));
6903 CbcEncrypt(data, sizeof(data), des_key, sizeof(des_key), des_iv);
6904 Print("Encrypted text: ", data, sizeof(data));
6905 CbcDecrypt(data, sizeof(data), des_key, sizeof(des_key), des_iv);
6907
6908 Print("\nKey: ", des_ede_key, sizeof(des_ede_key));
6909 Print("IV: ", des_ede_iv, sizeof(des_ede_iv));
6911 CbcEncrypt(data, sizeof(data), des_ede_key, sizeof(des_ede_key), des_ede_iv);
6912 Print("Encrypted text: ", data, sizeof(data));
6913 CbcDecrypt(data, sizeof(data), des_ede_key, sizeof(des_ede_key), des_ede_iv);
6915 return 0;
6916}
313 - CLVIII -
314
6917
6918J.9 CBC Trace Example
6919
6920DES/CBC
6921
6922Following is an example of a read table 0 request encrypted with DES/CBC.
6923
6924Read request 60 2D A2 0A A2 08 2A 86 48 CE 52 03
6925 16 06 A6 0A A2 08 2A 86 48 CE 52 03
6926 16 7D AC 09 A1 01 02 A2 04 39 86 F5
6927 1C BE 08 40 C5 36 70 8C F6 00 EB
6928Where
692960 2D = ACSE code, length
6930 A2 0A = Called code, length
6931 A2 08 2A8648CE52031606 = Called Aptitle UID
6932 A6 0A = Calling Aptitle code, length
6933 A2 08 2A8648CE5203167D = Calling Aptitle UID
6934 AC 09 = Authentication value code, length
6935 A1 01 02 = Key id code, length, value
6936 A2 04 3986F51C = Initialization vector code, length, value
6937 BE 08 = Application data code, length
6938 40C536708CF600EB = Application data encrypted
6939
6940Key = 8F39AEB8FA9041AF
6941IV = 3986F51C3986F51C
6942Plain text = 3AA9800403300000
6943Cipher text = 40C536708CF600EB
6944
6945DESede/CBC
6946
6947This next example represent the same read request encrypted this time with DESede/CBC.
6948
6949Write request 60 2D A2 0A A2 08 2A 86 48 CE 52 03
6950 16 06 A6 0A A2 08 2A 86 48 CE 52 03
6951 16 7D AC 09 A1 01 02 A2 04 39 86 F6
6952 9E BE 08 E1 02 CD 4D 81 29 D6 43
6953Where
695460 2D = ACSE code, length
6955 A2 0A = Called code, length
6956 A2 08 2A8648CE52031606 = Called Aptitle UID
6957 A6 0A = Calling Aptitle code, length
6958 A2 08 2A8648CE5203167D = Calling Aptitle UID
6959 AC 09 = Authentication value code, length
6960 A1 01 02 = Key id code, length, value
6961 A2 04 33986F69E = Initialization vector code, length, value
6962 BE 08 = Application data code, length
6963 E102CD4D8129D643 = Application data encrypted
6964
6965Key = E59B4741A7D4067EAB84BA62C49153A1AA29A0E1E6DE3653
6966IV = 3986F69E3986F69E
6967Plain text = 32E4800404300000
6968Encrypted text = E102CD4D8129D643
6969
315 - CLIX -
316

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

Read, Write, Identification , Register,

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

2470 <apdu-sequence-number> ::= <word16>

4 0xA8 0x06 0x1234

0xA8 0x02 0x1234

<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>]

<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

- Link control - Link control

Not detected Connected

Any valid traffic

5 VPLUS C12.22 Comm. Module power Output Input

XOR XOR … XOR

Encrypt Encrypt Encrypt

Decrypt Decrypt Decrypt

XOR XOR … XOR

You might also like