ANSI C12.

18-2005

AMERICAN NATIONAL STANDARD

PROTOCOL SPECIFICATION
FOR
ANSI TYPE 2 OPTICAL PORT

Accredited Standard Committee on Electricity Metering, C12

Accredited by

American National Standards Institute

Approved May 2, 2006

 ANSI C12.18 – 2005

American National Standards Institute, Inc.

Approval of an American National Standard requires verification by ANSI that the requirements
for due process, consensus, and other criteria for approval have been met by the standards
developer.

Consensus is established when, in the judgment of the ANSI Board of Standards Review,
substantial agreement has been reached by directly and materially affected interests. Substantial
agreement means much more than a simple majority, but not necessarily unanimity. Consensus
requires that all views and objections be considered, and that a concerted effort be made toward
their resolution.

The use of American National Standards is completely voluntary; their existence does not in any
respect preclude anyone, whether he has approved the standards or not, from manufacturing,
marketing, purchasing, or using products, processes, or procedures not conforming to the
standards.

The American National Standards Institute does not develop standards and will in no
circumstances give an interpretation of any American National Standard. Moreover, no person
shall have the right or authority to issue an interpretation of an American National Standard in
the name of the American National Standards Institute. Requests for interpretations should be
addressed to the secretariat or sponsor whose name appears on the title page of this standard.

CAUTION NOTICE: This American National Standard may be revised or withdrawn at any
time. The procedures of the American National Standards Institute require that action be taken
periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National
Standards may receive current information on all standards by calling or writing the American
National Standards Institute.

Published by

National Electrical Manufacturers Association

1300 N. 17th Street, Rosslyn, Virginia 22209

Copyright © 2005 National Electrical Manufacturers Association

All rights including translation into other languages, reserved under the Universal Copyright
Convention, the Berne Convention for the Protection of Literary and Artistic Works, and the
International and Pan American Copyright Conventions.

No part of this publication may be reproduced in any

i
 ANSI C12.18 – 2005

form, in an electronic retrieval system or otherwise,

without prior written permission of the publisher.

Printed in the United States of America

ii
 ANSI C12.18 – 2005

TABLE OF CONTENTS
1. SCOPE................................................................................................................................. 1
2. REFERENCES ................................................................................................................... 1
3. DEFINITIONS AND SYNTAX .......................................................................................... 1
3.1. DEFINITIONS....................................................................................................................... 1
3.1.1. C12.18 Client ............................................................................................................ 1
3.1.2. C12.18 Device .......................................................................................................... 1
3.1.3. Point-to-point Communications.............................................................................. 2
3.1.4. Table........................................................................................................................... 2
3.2. DOCUMENT SYNTAX ....................................................................................................... 2
4. PROTOCOL DETAILS...................................................................................................... 3
4.1. ORDER OF TRANSMISSION ............................................................................................. 3
4.2. LAYER 7—APPLICATION LAYER ..................................................................................... 4
4.2.1. Data Structure........................................................................................................... 4
4.2.2. Protocol Specifications for Electric Metering (PSEM) ........................................ 4
4.3. LAYER 6—PRESENTATION LAYER ............................................................................... 21
4.4. LAYER 5—SESSION LAYER.......................................................................................... 21
4.5. LAYER 4—TRANSPORT LAYER .................................................................................... 22
4.6. LAYER 3—NETWORK LAYER ....................................................................................... 22
4.7. LAYER 2—DATA LINK LAYER ....................................................................................... 22
4.7.1. Basic Data ............................................................................................................... 22
4.7.2. Packet ...................................................................................................................... 23
4.7.3. Duplicate packets ................................................................................................... 24
4.7.4. CRC selection ......................................................................................................... 25
4.7.5. Acknowledgment .................................................................................................... 25
4.7.6. Retransmission ....................................................................................................... 25
4.7.7. Time-out................................................................................................................... 25
4.7.8. Delays ...................................................................................................................... 26
4.8. LAYER-1—PHYSICAL LAYER........................................................................................ 27
4.8.1. Physical.................................................................................................................... 27
4.8.2. Basic Data ............................................................................................................... 28
4.8.3. Light Levels ............................................................................................................. 28
5. COMPLIANCE.................................................................................................................. 30
ANNEX A - COMMUNICATION EXAMPLE (LAYER 7 AND LAYER 2) ......................... 32
ANNEX B - PACKET TRANSMISSION EXAMPLE ............................................................ 34
ANNEX C - SERVICE SEQUENCE STATE CONTROL..................................................... 36
ANNEX D - COMPATIBILITY.................................................................................................. 39
D.1 BACKWARD COMPATIBILITY WITH PREVIOUS VERSIONS OF THE STANDARD................... 39
D.2 FORWARD COMPATIBILITY WITH NEXT VERSIONS OF THE STANDARD ............................ 39
ANNEX E - HISTORICAL BACKGROUND .......................................................................... 41

iii
 ANSI C12.18 – 2005

E.1 FOREWORD OF C12.18-1996 AND C12.18-1996 (R2002).......................................... 41

iv
 ANSI C12.18 – 2005

Foreword

(This foreword is not part of American National Standard for Protocol Specification for ANSI
Type 2 Optical Port, ANSI C12.18-2005.)

This American National Standard provides an open-platform communications protocol for two-
way communication with a metering device through an ANSI Type 2 Optical Port. The protocol
is written to conform to the OSI seven-layer stack.

Long-time readers of ANSI C12.18 will discover many editing changes to this version of the
Standard. The Working Group chose to improve the clarity of the text as an aid to the reader
while retaining the Normative elements in the manner of previous publications.

The 2005 revision of this Standard was considered in the context of the so-called “protocol suite”
of ANSI standards: C12.18, C12.19, C12.21 and C12.22 (draft). Changes made were included
only after assuring that existing devices implementing C12.18 would continue to remain
compatible with the 2005 revision.

This revision has corrected an error in the original standard: the impossibility of using index-
count for table access. Other concepts addressed include compliance, backward and forward
compatibility, the use of reserved fields, the Identification Service, packet size and the toggle bit.
Finally, some alignment with the draft C12.22 standard was performed to meet the goal of
producing a coherent suite of protocol standards.

Suggestions for improvement to this Standard are welcome. They should be sent to:

National Electrical Manufacturers Association

Vice President of Engineering
1300 North 17th Street
Suite 1847
Rosslyn, VA 22209

This Standard was processed and approved for submittal to ANSI by Accredited Standards
Committee for Electricity Metering C12. At the time the committee approved this Standard, the
C12 Committee had the following members:

Tom Nelson, Chairman

Paul Orr, Secretary

Michael Anderson
Ed Beroset
Ron Breschini
Curt Crittenden
David Ellis
Cruz Gomez
Bob Hughes

v
 ANSI C12.18 – 2005

Lawrence Kotewa
Francis Marta
John McEvoy
Herman Millican
James Mining
Avygdor Moise
Tim Morgan
Roy Moxley
D. Young Nguyen
Lauren Pananen
Aaron Snyder
Richard Tucker
Scott Weikel

Working Group 4 of Subcommittee 17 that developed the Standard consisted of:

Aaron Snyder, Chairman

Peter Martin, Vice Chairman
Norbert Balko, Editor

Michael Anderson
Ed Beroset
Martin Burns
Janice Jennings
Lawrence Kotewa
Robert McMichael
Avygdor Moise
Vuong Nguyen
Terry Penn
Bin Qiu
Richard Tucker
Michel Veillette
Virginia Zinkowski

vi
 ANSI C12.18 – 2005

Protocol Specification for ANSI Type 2 Optical Port

1. Scope

This Standard details the criteria required for communications between a C12.18 Device and a
C12.18 Client via an optical port. The C12.18 Client may be a handheld reader, a portable
computer, a master station system or some other electronic communications device.

This Standard provides details for a complete implementation of an OSI 7-layer model.

The protocol specified in this document was designed to transport data in Table format. The
Table definitions are in ANSI C12.19 Utility Industry End Device Data Tables.

2. References

ANSI C12.19, Utility Industry End Device Data Tables

ANSI C12.21, Protocol Specification for Telephone Modem Communication

ISO/IEC 646 (1991), Information Technology - ISO 7-Bit Coded Character Set For Information
Interchange

ISO/IEC 7498-1 (1994), Information Technology - Open Systems Interconnection - Basic

Reference Model: The Basic Model

ISO/IEC 8825-1 (2002), Information Technology - ASN.1 Encoding Rules: Specification Of

Basic Encoding Rules (BER), Canonical Encoding Rules (CER) And Distinguished Encoding
Rules (DER)

ISO/IEC 13239 (2002), Information Technology - Telecommunications And Information

Exchange Between Systems - High-Level Data Link Control (HDLC) Procedures

3. Definitions and Syntax

3.1. Definitions

For the purposes of this Standard, the following definitions are made:

3.1.1. C12.18 Client

An electronic communication apparatus that attaches to the ANSI Type 2 Optical Port of a
C12.18 Device and implements communication according to the protocol specification of this
Standard.

3.1.2. C12.18 Device

1
 ANSI C12.18 – 2005

An electronic communication apparatus that implements an ANSI Type 2 Optical Port for
communication according to the protocol specification of this Standard.

3.1.3. Point-to-point Communications

Point-to-point communications is defined as communication between two devices through a

single optical interface.

3.1.4. Table

Functionally related data elements, grouped together into a single data structure for transport as
defined by ANSI C12.19.

3.2. Document Syntax

Describing data definitions is usually accomplished within the confines of a given language and
the grammar rules of that language. Since the data definitions embodied within this Standard are
meant to be independent of specific language and, hopefully, capable of being implemented
within the confines of any language, a method for describing the data definitions must be
developed. A modified form of the Backus-Naur Form (BNF) will serve as the basis for building
the descriptions used to construct the data definitions.

The modified form of BNF has the following definitions:

Symbol Meaning

<> A string contained inside angle brackets is called a non-terminal. That is, while it
may be viewed as a single unit, it can and should be redefined as consisting of one
(1) or more simpler elements.

::= This symbol is read as “is defined as.” The non-terminal which occurs on the left
hand side (LHS) of this symbol consists of the elements (non-terminals, terminals,
or a combination of the two) found on the right hand side (RHS). A line
containing an LHS, ::=, and an RHS is known as a production rule.

| The vertical bar is an “OR” symbol. The OR symbol always occurs on the right
hand side of a production where the left hand side can be defined in more than
one way. The OR bar separates valid alternative right hand sides.

[] A symbol enclosed in square brackets is optional. The production is valid

whether or not it is included.
*
The superscript asterisk is known as the Kleene star. A symbol followed by the
Kleene star may occur zero (0) or more times without violating the grammar.
+
The superscript plus sign is known as the Kleene cross. A symbol followed by
the Kleene cross must occur one (1) or more times.

2
 ANSI C12.18 – 2005

+n
A symbol followed by the Kleene cross and any number “n” represents “n”
occurrences of the symbol.

{} The curly braces are used to enclose comments within the descriptions.
Comments have no impact on the productions.

4. Protocol Details

Following the guidelines established by the OSI seven-layer model, the protocol described in this
Standard provides three (3) functions:

1) Establishment and modification of the communication channel

2) Transport of information to and from the C12.18 Device
3) Orderly closure of the communication channel when communications are complete

Three (3) layers are used to provide these communication capabilities. These are the Physical,
Data Link and Application layers.

With the default conditions established by this Standard, the communication channel is
considered always available once the physical connection has been completed. The required
Identification Service is used to obtain the protocol version and revision in use by the C12.18
Device. Certain communication parameters may be modified through the use of the Negotiate
Service in the Application Layer. The Negotiate Service is optional and, if not implemented in
the C12.18 Device or not used during actual communications, the communication channel
parameters shall remain at the default settings specified by this Standard. Device implementers
are strongly encouraged to implement this service.

Once the C12.18 Device identification and communication parameters have been established, the
Application Layer provides Logon, Security and Logoff services for session activation, access
control and deactivation, Read and Write services for issuing data transmission requests, a
Terminate service for shutdown of the communication channel, and a response structure that
provides information regarding the success or failure of the service requests.

An example of a typical communications session would consist of the following services with
appropriate responses, in the order listed: Identification, Negotiate, Logon, Security, Reads or
Writes, Logoff and Terminate. Note that this brief example does not detail the packet structure
or other aspects of the protocol. Annex and Annex B contain examples with more detail.

4.1. Order of Transmission

Within the syntax definitions, multiple parameters shall be transmitted in the order as shown,
from left to right.

3
 ANSI C12.18 – 2005

Service parameters in all layers within the protocol definition are transmitted most significant
byte first. The order of transmission of data field parameters within Tables is dictated by the
Table structure.

Bytes are transmitted in frames. Each frame consists of a start bit, followed by <byte>, and
ending with a stop bit. The start bit is transmitted first.

Bits within each byte are transmitted least significant bit first.
<byte> ::= {An eight-bit quantity.}
<msbyte> ::= <byte> {most significant byte}
<lsbyte> ::= <byte> {least significant byte}
<word24> ::= <msbyte><byte><lsbyte>
<word16> ::= <msbyte><lsbyte>

4.2. Layer 7—Application Layer

The Application Layer provides the set of services and data structures required to support C12.18
Devices for purposes of configuration, programming and information retrieval.

4.2.1. Data Structure

This protocol shall transport Table structures as defined in ANSI C12.19.

4.2.2. Protocol Specifications for Electric Metering (PSEM)

This Standard defines nine (9) Protocol Specifications for Electric Metering (PSEM) services.
Each service consists of a request and a response. Each of these requests and responses is
described in the following service sections.

<requests> ::= <ident> | {Identification Service request}

<read> | {Read Service request}
<write> | {Write Service request}
<logon> | {Logon Service request}
<security> | {Security Service request}
<logoff> | {Logoff Service request}
<negotiate> | {Negotiate Service request}
<wait> | {Wait Service request}
<terminate> {Terminate Service request}

<responses> ::= <ident-r> | {Identification Service response}

<read-r> | {Read Service response}
<write-r> | {Write Service response}
<logon-r> | {Logon Service response}
<security-r> | {Security Service response}
<logoff-r> | {Logoff Service response}
<negotiate-r> | {Negotiate Service response}
<wait-r> | {Wait Service response}
<terminate-r> {Terminate Service response}

4.2.2.1. Request Codes

4
 ANSI C12.18 – 2005

PSEM requests always include a one-byte request code. Code numbers are represented in
hexadecimal format as follows:

00H-1FH Codes shall not be used to avoid confusion with response codes

20H-7FH Codes in this range signify request codes

80H-FFH Codes shall be reserved for protocol extensions

4.2.2.2. Response Codes

PSEM responses always include a one-byte response code. These codes are listed below in a
suggested order of priority. When more than one response code is capable of indicating the error
response condition of a C12.18 Device or a C12.18 Client, the response code having the highest
priority (from left to right) is as follows:

<nok> ::= <sns>|<isss>|<iar>|<isc>|<onp>|<bsy>|<dlk>|<dnr>|<rno>|<err>

For example, if Standard Table 05 of a C12.18 Device is read-only and it is encoded in non-
volatile memory then a Write service request to Table 05 would fail. The C12.18 Device may
consider the following codes as suitable responses: <err> to indicate an error condition or <dlk>
to indicate that the data is locked in memory and cannot be changed, <iar> to indicate that the
action requested was not appropriate for this device design or <isc> to indicate that the table
access permission are “read-only” under the current security policy. The correct response would
be <iar> as it is the highest priority among <iar>, <isc>, <dlk> and <err>. However, if there is a
mechanism for providing write access to Table 05, then <iar> should not be considered.
Therefore, the response code becomes <isc>.

Responses:

<ok> ::= 00H {Acknowledge

Application Layer response
indicating no problems, request
accepted.}

<err> ::= 01H {Error

This Application Layer error code
is used to indicate rejection of
the received service request. The
reason for the rejection is not
provided.}

<sns> ::= 02H {Service Not Supported

This Application Layer error
response will be sent to the device
when the requested service is not
supported. This error indicates
that the message was valid, but the
request could not be honored.}

<isc> ::= 03H {Insufficient Security Clearance

5
 ANSI C12.18 – 2005

This Application Layer error

indicates that the current
authorization level is insufficient
to complete the request.}

<onp> ::= 04H {Operation Not Possible

This Application Layer error will
be sent to the device which
requested an action that is not
possible. This error indicates
that the message was valid, but the
message could not be processed.
Covers conditions such as: invalid
length, invalid offset}

<iar> ::= 05H {Inappropriate Action Requested

This Application Layer error
indicates that the action requested
was inappropriate. Covers
conditions such as write request to
a read-only table or an invalid
table id.}

<bsy> ::= 06H {Device Busy

This Application Layer error
indicates that the request was not
acted upon because the device was
busy doing something else. The
operation may be retried at a later
time with success, as the data may
then be ready for transportation
during this active communication.}

<dnr> ::= 07H {Data Not Ready

This Application Layer error
indicates that request was
unsuccessful because the requested
data is not ready to be accessed.}

<dlk> ::= 08H {Data Locked

This Application Layer error
indicates that the request was
unsuccessful because the data
cannot be accessed.}

<rno> ::= 09H {Renegotiate Request

This Application Layer error
indicates that the responding
device wishes to return to the ID
or Base State and renegotiate
communication parameters.}

<isss> ::= 0AH {Invalid Service Sequence State

This Application Layer error
indicates that the request is not
accepted at the current service
sequence state. For more

6
 ANSI C12.18 – 2005

information on service sequence

states, see Annex C, Service
Sequence State Control.}

0BH-1FH {Undefined response codes.}

20H-7FH {Codes shall not be used to avoid confusion with request codes.}

80H-FFH {Codes shall be reserved for protocol extensions.}

4.2.2.3. Identification Service

The Identification Service shall be the first service issued upon C12.18 Device power-up,
following a PSEM Terminate Service response, or Channel Traffic Time-out, and returns the
version and revision of the protocol where the version is positioned left of the decimal indicating
a major change and the revision is positioned right of the decimal indicating a minor change. It
may also return a device class or device identity. Since this service is always issued prior to the
Negotiate Service, the size of the returned response shall never exceed the default packet size.

The Identification Service is a required service.

The Identification Service shall be initiated only by a C12.18 Client.

Request:

<ident> ::= 20H

Response:

The responses <isss>, <bsy>, and <err> indicate a problem with the received service request.

The response <ok> indicates the Identification Service request was accepted and the version and
revision are included in the response. Implementers shall ensure that the response fits within a
single 64-byte packet.

<ident-r> ::= <isss> | <bsy> | <err> |

<ok><std><ver><rev><feature>*<end-of-list>

<std> ::= <byte> {Code identifying reference

Standard. The codes are defined as
follows:
00H = ANSI C12.18
01H = Reserved
02H = ANSI C12.21
03H = ANSI C12.22
04H - FFH = Reserved
A C12.18 Device shall return 00H.}

<ver> ::= <byte> {Referenced Standard version

number. Previous versions shall be
Version 1. This version shall be
Version 2.}

7
 ANSI C12.18 – 2005

<rev> ::= <byte> {Referenced Standard revision

number. This value shall be zero
(0).}

<feature> ::= <device-class> | <device-identity>

{Features available.}

<end-of-list> ::= 00H {End of list indicator.}

<device-class> ::= 06H <universal-id>

{A Universal Identifier that
uniquely identifies a C12.19 Device
Class object for early detection of
the device class as per
MANUFACTURER as defined in Table 00
of ANSI C12.19-1997 or the
DEVICE_CLASS as defined by Version
2 of ANSI C12.19. The C12.19 Device
Class shall be supplied when the
C12.19 Device Table 00,
GEN_CONFIG_TBL, is readable
immediately following the Logon
Service. When C12.19 Device Class
is provided, it shall not be
preceded by features with codes
that are less than 06H.}

<universal-id> ::= <absolute-uid-element> | <relative-uid-element>

{The C12.19 Device Class encoded as
an absolute or relative registered
universal object identifier.}

<absolute-uid-element> ::= 06H <uid-length><absolute-uid>

{The absolute encoding of the
C12.19 Device Class; e.g.,
1.2.840.10066.0.<relative-uid>,
encoded as described in ISO/IEC
8825-1 (2002), Basic Encoding Rules
(BER). The last 4 bytes of this
identifier shall be identical to
the values delivered in the C12.19
Table elements MANUFACTURER as
defined in Table 00 of ANSI C12.19-
1997 or the DEVICE_CLASS as defined
by Version 2 of ANSI C12.19.}

<relative-uid-element> ::= 0DH <uid-length><relative-uid>

{The relative encoding of the
C12.19 Device Class relative to the
universal identifier
1.2.840.10066.0, encoded as
described in ISO/IEC 8825-1 (2002),
Basic Encoding Rules (BER). The
<uid-length> shall range between 00H
to 04H resulting in up to 4 bytes
being transmitted. These 4 bytes

8
 ANSI C12.18 – 2005

shall be identical to the C12.19

Table elements MANUFACTURER as
defined in Table 00 of ANSI C12.19-
1997 or the DEVICE_CLASS as defined
by Version 2 of ANSI C12.19, with
assumed 00H trailing pad.}

<uid-length> ::= <byte> {Length of number of bytes that

follow. This value shall range
between 00H to 7FH.}

<absolute-uid> ::= <byte>+ {Absolute object identifier encoded

as described in ISO/IEC 8825-1
(2002), Basic Encoding Rules (BER).
The size of this field shall not
exceed 127 bytes.}

<relative-uid> ::= <byte>+ {Relative object identifier encoded

as described in ISO/IEC 8825-1
(2002), Basic Encoding Rules (BER).
The size of this field shall not
exceed 4 bytes.}

<device-identity> ::= 07H <identity-length><identity>

{An Identifier that uniquely
identifies a C12.19 Device in the
application space of the C12.19
Device. This provides for early
detection of the device
identification element as per
IDENTIFICATION of Table 05,
DEVICE_IDENT_TBL, or DEVICE_ID
found in Table 06 of ANSI C12.19.
The C12.19 <device-identity>
feature shall be supplied when the
C12.19 Device Table 05 or Table 06
are readable immediately following
the Logon Service. When C12.19
Device identification is provided,
it shall not be preceded by
features with codes that are less
than 07H.}

<identity-length>::= <byte> {Length of number of bytes that

follow in <identity>. This value
shall range between 00H to 7FH.}

<identity> ::= <char-format><identification>

{Provides for disclosure of the
C12.19 Device identification.}

<char-format> ::= <byte> {The character encoding format of

the bytes which make up
<identification>. Its
interpretation shall be according
to the relevant ANSI C12.19
Standard data model referenced by

9
 ANSI C12.18 – 2005

the C12.19 registered Device Class

feature <device-class>. When the
<device-class> feature is not
supplied in this <ident> response,
the value of <char-format> shall be
set to 01H, and <identification>
shall be encoded according to ISO
7-bit coded character set for
information interchange, per
ISO/IEC 646 (1991).}

<identification> ::= <byte>* {The C12.19 Device identification

string encoded and transmitted
according to <char-format>. If the
C12.19 Device ID_FORM in Table 00
is set to BCD, then the BCD digits
shall be transmitted as their text
equivalent also encoded as per
char-format>.

For example, assuming that the

C12.19 Device
GEN_CONFIG_TBL.ID_FORM is BCD and
the Device
GEN_CONFIG_TBL.CHAR_FORMAT is ISO 7
bit ASCII, as per ISO/IEC 646
(1991), then the BCD digits 00H 01H
02H 03H 0AH 04H 0DH 05H 06H 07H shall
be transmitted as the character
sequence “123-4.567”. The C12.19
application shall logically pad
this string with trailing spaces as
needed to fill the identification
field width of the C12.19 Device.}

4.2.2.4. Read Service

The Read Service is used to transfer Table data to the requesting device and shall be initiated
only during a session that was successfully established using the Logon Service.

At least one (1) form of the Read Service is required to be supported by a C12.18 Device.

Request:

The Read Service request supports both complete and partial Table transfers. The retrieval of a
portion of a Table is possible through the use of both index/element-count and offset/octet-count
methods. The complete rule set for using these methods is enumerated in Sections 4.2.2.12,
Partial Table Access Using the Index/element-count Method, and 4.2.2.14, Partial Table Access
Using the Offset/octet-count Method, respectively.

Codes 30H–39H, 3EH and 3FH are the Read Service request codes. Request code 30H specifies a
complete Table transfer. Request codes 31H through 39H specify a partial Table transfer using 1

10
 ANSI C12.18 – 2005

to 9 indices. Request code 3EH specifies a default Table transfer. Request code 3FH specifies a
partial Table transfer using the offset/octet-count method.

<read> ::= <full-read> | <pread-index> | <pread-offset> |

<pread-default>

<full-read> ::= 30H <tableid>

<pread-index> ::= <read-index-type><tableid><index>+<element-count>

<read-index-type> ::= 31H | {1 <index> included in request}

32H | {2 <index> included in request}
33H | {3 <index> included in request}
34H | {4 <index> included in request}
35H | {5 <index> included in request}
36H | {6 <index> included in request}
37H | {7 <index> included in request}
38H | {8 <index> included in request}
39H {9 <index> included in request}

<pread-default> ::= 3EH {Transfer default Table as defined

by the C12.19 Device.}

<pread-offset> ::= 3FH <tableid><offset><octet-count>

<tableid> ::= <word16> {Table identifier as defined in

ANSI C12.19.}

<offset> ::= <word24> {Offset into data Table in bytes.

Offset 0000H is the offset to the
first table element of the Table
selected by <tableid>.}

<index> ::= <word16> {Index value used to locate start

of data. Index 0000H is the index of
the first Table element of the
Table selected by <tableid>.}

<element-count> ::= <word16> {Number of Table elements to read

starting at the requested index.}

<octet-count> ::= <word16> {Length of Table data requested

starting at Table <offset>, in
bytes.}

Response:

Responses of type <nok> indicate a problem with the received Read Service request.

The response <ok> indicates the Read Service was accepted and the data is part of the response.

<read-r> ::= <nok> |

<ok><table-data>

<table-data> ::= <count><data><cksum>

11
 ANSI C12.18 – 2005

<count> ::= <word16> {Length of <data> returned, in

bytes.}

<data> ::= <byte>* {The returned Table data including

the optional pending header as per
ANSI C12.19, when requested.}

<cksum> ::= <byte> {2's compliment checksum computed

only on the <data> portion of
<table-data>. The checksum is
computed by summing the bytes
(ignoring overflow) and negating
the result.}

4.2.2.5. Write Service

The Write Service is issued to transfer Table data to the target device and shall be initiated
during a session that was successfully established using the Logon Service.

The Write Service is an optional service.

Request:

The Write Service request allows both complete and partial Table transfers. The modification of
a portion of a Table is possible through the use of both index/element-count and offset/octet-
count methods. The complete rule set for using these methods is enumerated in Sections
4.2.2.12 and 4.2.2.14, respectively.

Codes 40H–49H and 4FH are the Write Service request codes. Request code 40H specifies a
complete Table transfer. Request codes 41H through 49H specify a partial Table transfer using 1
to 9 indices. Request code 4FH specifies a partial Table transfer using the offset/octet-count
method.

<write> ::= <full-write> | <pwrite-index> | <pwrite-offset>

<full-write> ::= 40H <tableid><table-data>

<pwrite-index> ::= <write-index-type><tableid><index>+<table-data>

<write-index-type> ::= 41H | {1 <index> included in request}

42H | {2 <index> included in request}
43H | {3 <index> included in request}
44H | {4 <index> included in request}
45H | {5 <index> included in request}
46H | {6 <index> included in request}
47H | {7 <index> included in request}
48H | {8 <index> included in request}
49H {9 <index> included in request}

<pwrite-offset> ::= 4FH <tableid><offset><table-data>

12
 ANSI C12.18 – 2005

<tableid> ::= <word16> {Table identifier, as defined in

ANSI Standard C12.19.}

<offset> ::= <word24> {Offset into data Table, in bytes.

Offset 0000H is the offset to the
first element of the Table selected
by <tableid>.}

<index> ::= <word16> {Index value used to locate start

of data. Index 0000H is the index of
the first element of the Table
selected by <tableid>.}
<table-data> ::= <count><data><cksum>

<count> ::= <word16> {Length of <data> to be written, in

bytes. This includes the optional
pending header length as defined by
ANSI C12.19.}

<data> ::= <byte>* {The Table data elements including

the optional pending header as per
ANSI C12.19, when requested.}

<cksum> ::= <byte> {2's compliment checksum computed

only on the <data> portion of
<table-data>. The checksum is
computed by summing the bytes
(ignoring overflow) and negating
the result.}

Response:

Responses of type <nok> indicate a problem with the received Write Service request.

The response <ok> indicates the Write Service was successfully completed and the data was
successfully transmitted to the requesting device.

<write-r> ::= <nok> |

<ok>

4.2.2.6. Logon Service

The Logon Service establishes a session without establishing access permissions.

The Logon Service is a required service.

The Logon Service shall be initiated only by a C12.18 Client.

Request:

The <user-id> parameter is a code, optionally stored by the C12.18 Device, indicating the
identity of the operator requesting the creation of a session. The <user-id> may be inserted in

13
 ANSI C12.18 – 2005

the Event and History Logs as defined in ANSI C12.19. The <user> field provides the name of
the operator requesting the access to the device.

The Logon Service has the following format:

<logon> ::= 50H <user-id><user>

<user-id> ::= <word16> {User identification code. This

field is transferred to USER_ID in
Procedure 18 of C12.19.}

<user> ::= <byte>+10 {10 bytes containing user

identification}

Response:

The responses <isss>, <iar>, <bsy> and <err> indicate a problem with the received Logon
Service request.

The response <ok> indicates the Logon Service was successfully completed and the session was
established.

<logon-r> ::= <isss> | <iar> | <bsy> | <err> |

<ok>

4.2.2.7. Security Service

The Security Service is provided for setting access permissions and shall be initiated only during
a session that was successfully established using the Logon Service.

The Security Service is an optional service.

The Security Service shall be initiated only by a C12.18 Client.

Request:

A password is used as a means to select access permissions. This service request shall only be
sent during a session. If the password tables are supported by the C12.18 Device, the
<password> field, will be compared with the PASSWORD elements of SECURITY_TBL (Table
42) of ANSI C12.19. The number of bytes validated shall be 20 or the value of the element
PASSWORD_LEN found in ACT_SECURITY_LIMITING_TBL (Table 41), whichever is
smaller.

<security> ::= 51H <password>

<password> ::= <byte>+20 {20-byte field containing password}

14
 ANSI C12.18 – 2005

Response:

The responses <sns>, <isss>, <bsy> and <err> indicate a problem with the received Security
Service request.

The response <ok> indicates the Security Service was successfully completed and the access
permissions associated with the password were granted.

<security-r> ::= <sns> | <isss> | <bsy> | <err> |

<ok>

4.2.2.8. Logoff Service

The Logoff Service provides for an orderly shutdown of the session established by the Logon
Service.

The Logoff Service is a required service.

Request:

Following a Logoff Service request, the communication channel will retain the parameters
previously established.

<logoff> ::= 52H

Response:

The responses <isss>, <bsy>, and <err> indicate a problem with the received Logoff Service
request.

The response <ok> indicates the acceptance of the Logoff Service and the cessation of the
session established by the Logon Service.

<logoff-r> ::= <isss> | <bsy> | <err> |

<ok>

4.2.2.9. Negotiate Service

The Negotiate Service provides the mechanism for reconfiguring the communication channel for
communication parameters differing from the default values specified in this Standard.

The Negotiate Service is an optional service. The Negotiate Service shall be issued only after the
Identification Service and before the Logon Service. The negotiated parameters shall remain in
effect until re-negotiated or the communication channel is closed.

The Negotiate Service shall be initiated only by a C12.18 Client.

Request:

15
 ANSI C12.18 – 2005

<negotiate> ::= <baud-rate-selector><packet-size><nbr-packets>

<baud-rate>*

<baud-rate-selector>::=
60H | {No <baud rate> included in
request. Stay at default baud rate}
61H | {1 <baud rate> included in request}
62H | {2 <baud rate> included in request}
63H | {3 <baud rate> included in request}
64H | {4 <baud rate> included in request}
65H | {5 <baud rate> included in request}
66H | {6 <baud rate> included in request}
67H | {7 <baud rate> included in request}
68H | {8 <baud rate> included in request}
69H | {9 <baud rate> included in request}
6AH | {10 <baud rate> included in
request}
6BH {11 <baud rate> included in
request}

<packet-size> ::= <word16> {Maximum packet size supported, in

bytes. This value shall be in the
range of 64 - 8192 bytes,
inclusive.}

<nbr-packets> ::= <byte> {Maximum number of packets this

layer is able to reassemble into an
upper layer data structure at one
time. The value zero (0) is
reserved for future standard
extension.}

<baud-rate> ::= 00H | {Externally defined}

01H | {300 baud}
02H | {600 baud}
03H | {1200 baud}
04H | {2400 baud}
05H | {4800 baud}
06H | {9600 baud}
07H | {14400 baud}
08H | {19200 baud}
09H | {28800 baud}
0AH | {57600 baud}
0BH | {38400 baud}
0CH | {115200 baud}
0DH | {128000 baud}
0EH {256000 baud}
0FH – FFH {reserved}

Response:

The responses <sns>, <isss>, <bsy> and <err> indicate a problem with the received Negotiate
Service request and that the communication channel will maintain its current settings.

16
 ANSI C12.18 – 2005

The response <ok> indicates the Negotiate Service request was accepted and all new settings
now apply to both devices. The data following the <ok> indicates the new settings. If the target
cannot accept the Negotiate Service request baud rates, the original baud rate will be echoed in
the response.

<negotiate-r> ::= <sns> | <isss> | <bsy> | <err> |

<ok><packet-size><nbr-packets><baud-rate>

4.2.2.10.Wait Service

The Wait Service is used by either of the communicating devices to maintain an established
communication channel during idle periods, thus preventing automatic termination. The Wait
Service temporarily extends the channel traffic time-out to the <time> specified in the request
upon acknowledgement of the Wait Service request. The channel traffic time-out will be reset to
the default value once the next PSEM Request or PSEM Response is received by the target of
this service.

The Wait Service is an optional service.

Request:

<wait> ::= 70H <time>

<time> ::= <byte> {Suggested wait period in seconds.

The value 0 does not affect the
channel settings.}

Response:

The responses <sns>, <isss>, <bsy>, and <err> indicate a problem with the received Wait
Service request and time-out is not extended.

The response <ok> indicates the service request was accepted and the time-out is extended to the
value requested.

<wait-r> ::= <sns> | <isss> | <bsy> | <err> |

<ok>

4.2.2.11.Terminate Service

The Terminate Service provides for an immediate cessation of the communication channel and
aborts an open session, and implicitly invokes the Logoff Service.

The Terminate Service is an optional service.

Request:

The Terminate Service may be used to terminate either partially or fully established
communication channels for reasons such a excessive errors, security issues, internal error

17
 ANSI C12.18 – 2005

conditions, end of session, or other reasons as set by the device manufacturer. When the
Terminate Service is invoked within an open session, any or all session-oriented transactions
may be lost or may be rolled back to values that existed at the start of session.

<terminate> ::= 21H

Response:

The responses <sns> and <err> indicates a problem with the received Terminate Service request
and the channel remains open.

The response <ok> indicates the service request was accepted and the channel will return to
default settings as stated in Section 4.7.1.1, Default Settings, upon receipt of a positive
acknowledgment.

<terminate-r> ::= <sns> | <err> |

<ok>

4.2.2.12.Partial Table Access Using the Index/element-count Method

1. An index sets up a start of selection into a Table object relative to the beginning of the
Table, where PACKED RECORD, BIT FIELD, SET, ARRAY, STRING, IF and CASE are
defined in ANSI C12.19, as follows:

• Each member of a PACKED RECORD gets a unique number.

• The positional number of the first element of a PACKED RECORD is assigned the
value zero (0).

• The positional number of subsequent elements in the same PACKED RECORD is

incremented by one (1) for each subsequent element in the PACKED RECORD.

• Each sub element of a BIT FIELD is assigned a unique positional number.

• The positional number of the first sub element of a BIT FIELD is assigned the value
zero (0).

• The positional number of subsequent sub elements in the same BIT FIELD is
incremented by one (1) for each subsequent sub element in the BIT FIELD,
independent of the bit range assigned to the sub element.

• Positional numbers are assigned independently of any IF or CASE statements that may
be present inside PACKED RECORDs or BIT FIELDs, as if the elements or sub-
elements where not enclosed within any IF or SWITCH statements.

• For non-final elements one level of index is appended to the index of the parent’s
element index for use in selections.

18
 ANSI C12.18 – 2005

• Selection of Boolean members within a SET are referenced in the same manner as
members of a single dimensional array.

• For elements of an ARRAY one level of index is appended to the index of the array’s
element for each dimension (as per BNF.dim) for use in selections into entries of the
ARRAY.

2. Selection based on an index method using <element-count> equal to one (1) will deliver
the whole selected element.

3. For the purpose of binary transmission, <index>+ cannot select into a sub-element or final
elements that are not atomic, with the exception of SETs, where the first octet selected for
transmission is that computed by integer division of the atomic index number requested by
8, and the number of elements is the number of bits requested.

4. For the purpose of transmission, an indexed selection into a non-existing element shall
result in an "Inappropriate Action Requested" error. However, it is allowed to append zeros
at the end of an <index>+ to indicate the desired access level of an indexed selection within
the Table element hierarchy.

5. When <element-count> is greater than one (1), the application shall return up to <element-
count> elements at the same or lower hierarchical level of the <index>+ used to initiate the
request traversing all element types serially.

6. When <element-count> is greater than the number of elements available for transmission,
the number of elements transmitted will be limited to the maximum number elements
available at the same or lower hierarchical level of the <index>+ used to initiated the
request..

7. The number of numeric segments that make up the <index>+ defines the initial hierarchical
level for element serialization and for <element-count> interpretation.

8. As a part of a Read Service request, <element-count> equal to zero (0) shall be interpreted
as ALL data starting from the <index>+ to the end of the Table requested.

9. As a part of a response, <count> equal to zero (0) shall be interpreted as NO data was
received.

10. As a part of a Write Service request, <count> shall correctly represent the actual number of
bytes to be written, including the optional pending header, at the hierarchical level of the
selection start <index>+.

11. As a part of a Read Service request, <element-count> represents the maximum number of
elements requested.

19
 ANSI C12.18 – 2005

12. Any element excluded from the data stream through the use of the IF or CASE conditional
statements shall not be a candidate for transmission and not be counted.

13. Any element excluded from the data stream through the use of zero-length ARRAYs,
SETs, STRINGs, BINARYs shall not be a candidate for transmission and not be counted.

14. Any element whose size is zero (0) shall not be a candidate for transmission and not be
counted.

15. The <element-count> counts elements and not octets.

16. If the respondent application does not support the transmission elements at the requested
index level, or the respondent application cannot deliver the element requested from an
ARRAY the respondent application shall assert the error condition "Inappropriate Action
Requested". The requester may then attempt a retry of the Read or Write Service request on
an <index>+ of an element that is higher or lower in hierarchy relative to the <index>+ of
the failed attempt.

4.2.2.13.Index Count Access Method Examples

The following are examples for the use of the Index/Element-Count method to select data.

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

4.2.2.14.Partial Table Access Using the Offset/octet-count Method

1. An <offset> sets up a start of selection into a Table object relative to the beginning of the
Table.

20
 ANSI C12.18 – 2005

2. An <offset> zero (0) is the octet offset to the first octet of the first element in the Table as
prescribed by the object data type and the value of DATA_ORDER, found in the
GEN_CONFIG_TBL (Table 00).

3. When <count> is greater than one (1), the application shall return no more than <count>
octets from <offset> used to initiate the request traversing all element types serially, where
each element will be transferred according to its type and the value of DATA_ORDER,
found in the GEN_CONFIG_TBL (Table 00).

4. When <count> is greater than the number of octets available for transmission, the number
of octets transmitted will be limited to the maximum number octets available. The response
<count> shall be adjusted to reflect the actual number of octets transferred in the response.

5. As a part of a request, <count> equal to zero (0) shall be interpreted as ALL data starting
from the <offset> to the end of the Table requested.

6. As a part of a response, <count> equal to zero (0) shall be interpreted as NO data was
received.

7. As a part of a Write Service request, <count> shall correctly represent the actual number of
octets requested to be written starting at the Table offset requested including the optional
pending header.

8. As a part of a Read Service request, <octet-count> represents the maximum number of

octets.

9. Elements that are not present in the Table by virtue of them being excluded from the data
stream through the use of zero-length ARRAYs, SETs, STRINGs, BINARYs or BCDs
shall not be candidates for transmission and not be counted.

10. Any element whose size is zero (0) shall not be a candidate for transmission and not be
counted.

11. The octet counter counts octets and not elements.

12. If the respondent application does not support the transmission of octets at the requested
offset, the respondent application shall assert the error condition "Inappropriate Action
Requested”.

4.3. Layer 6—Presentation Layer

Null layer. The C12.18 Device will not provide queuing capabilities for service requests.

4.4. Layer 5—Session Layer

21
 ANSI C12.18 – 2005

Null layer. Communications between devices over the optical port communications path will be
connection oriented and consist of a single session. A session is defined to begin with the
acceptance of the Logon Service and terminates with the acceptance of either the Logoff Service
or the Terminate Service.

4.5. Layer 4—Transport Layer

Null layer.

4.6. Layer 3—Network Layer

Null layer.

4.7. Layer 2—Data Link Layer

Services of upper layers are transported in one (1) or many packets. Each packet is variable in
length but cannot exceed a maximum packet size. The maximum packet size has a default value
when the communication channel is opened. The maximum packet size can be changed through
the use of the Negotiate Service.

For each packet received, a positive or negative acknowledgment is sent by the target device.
This acknowledgment consists of a single byte transmitted outside of the packet structure. If the
requester does not receive an acknowledgment before the Response Time-out, or a negative
acknowledgment is received, the same packet is re-transmitted up to three (3) times. After the
third retry attempt, the requester should assume termination has occurred.

4.7.1. Basic Data

Communication channel settings are specified below. The baud rate, number of packets, and
packet size each have a default setting which applies at the initiation of communication. These
settings may be changed through the Negotiate Service. Negotiated channel settings will return
to defaults as a result of the terminate service or Channel Traffic Time-out.

DATA FORMAT: 8 data bits, 1 start bit, 1 stop bit, no parity

DATA TYPE: Asynchronous, serial bit (start-stop), half duplex
DATA POLARITY: LED on, start bit, space, logical zero (0)
LED off, stop bit, mark, logical one (1), quiescent state
DATA RATE: The maximum transmitting speed shall be at least 9600
baud. Selection codes have been arranged for the
following baud rates: 300, 600, 1200, 2400, 4800, 9600,
14400, 19200, 28800, 38400, 57600, 115200, 128000,
256000 or externally defined. Additional selection codes
have been reserved for future assignment.
NUMBER OF PACKETS: At least one (1) packet is required although more are
negotiable.
PACKET SIZE: Default packet size is 64 bytes, although a larger size can
be negotiated.
CHANNEL TRAFFIC TIME-OUT: 6 seconds

22
 ANSI C12.18 – 2005

INTER-CHARACTER TIME-OUT: 500 milliseconds

RESPONSE TIME-OUT: 2 seconds
TURN-AROUND DELAY: 175 microseconds

In the event of a collision (C12.18 Client and C12.18 Device are transmitting at the same time),
the C12.18 Device shall cease transmission and wait for the transmission from the C12.18 Client.

4.7.1.1. Default Settings

DATA RATE: 9600 baud

NUMBER OF PACKETS: 1
PACKET SIZE: 64 bytes

4.7.2. Packet

<packet> ::= <stp><identity><ctrl><seq-nbr><length><data><crc>

<stp> ::= EEH {Start of packet character.}

<identity> ::= <byte> {C12.19 Device (end device, table

driven communication card, etc.)
identity. It identifies the C12.19
Device in both the request and
response packets.

The individual C12.19 Device

identities must be in the range 00H
to FEH and can be specified by PSEM
identify field in Global Parameters
Table (Table 92) of ANSI C12.21-
1999.

The value FFH is reserved for ANSI

C12.21 calling party use. It shall
not be used by this protocol.

The C12.19 Device shall use its own

identity byte or 00H in the response
when addressed with an identity
other than 00H; otherwise, the
response identity byte shall be
00H.}

<ctrl> ::= <byte> {Control field.

Bit 7. If true (01H) then this
packet is part of a multiple packet
transmission.

Bit 6. If true (01H), then this

packet is the first packet of a
multiple packet transmission, and
Bit 7 shall also be true.

23
 ANSI C12.18 – 2005

Bit 5. Represents a toggle bit to

reject duplicate packets. This bit
shall be toggled for each new
packet sent. Retransmitted packets
keep the same state as the original
packet sent. It should be noted
that the initial state of the
toggle bit is not specified and
could initially be either zero (0)
or one (1).

Bits 4 to 2, Reserved. The bits

shall be set to zero (0) by the
transmitter.

Bit 0 to 1: DATA_FORMAT
0 = C12.18 or C12.21
1 = C12.22
2 = Reserved
3 = Reserved

C12.18 Compliant implementations

shall set Bits 0 and 1 to zero
(0).}

<seq-nbr> ::= <byte> {Number that is decremented by one

(1) for each new packet sent. The
first packet in a multiple packet
transmission shall have a <seq-nbr>
equal to the total number of
packets minus one (1). A value of
zero (0) in this field indicates
that this packet is the last packet
of a multiple packet transmission.
If only one (1) packet in a
transmission, this field shall be
set to zero (0), and Bit 7 and Bit
6 shall be set to zero (0).}

<length> ::= <word16> {Number of bytes of data in

packet.}

<data> ::= <byte>* {<length> number of bytes of actual

packet data. This value is limited
by the maximum packet size minus
the packet overhead of 8 bytes.
This value can never exceed 8183.}

<crc> ::= <lsbyte><msbyte> {CCITT CRC standard polynomial X16 +

X12 + X5 + 1.}

4.7.3. Duplicate packets

A duplicate packet is defined as a packet whose identity, toggle bit and valid CRC are identical
to those of the immediate previous packet. If a duplicate packet is received by the target device,
the device shall disregard the duplicate packet and return an <ack>. Upon entry into Base State,

24
 ANSI C12.18 – 2005

the toggle bit in the first packet may assume any state and the duplicate packet rejection
mechanism shall be suppressed until receipt of the first valid packet while in Base State.

4.7.4. CRC selection

The CRC selected for implementation is the CCITT CRC standard polynomial X16 + X12 + X5 +
1. The method for calculation and insertion is the HDLC standard per ISO/IEC 13239 (2002)
Annex A.

In the PSEM frame, there is no opening flag as referenced in ISO/IEC 13239 (2002) Annex A.
The PSEM start of packet character EEH is included in the CRC calculation. The result of the
CRC calculation shall be transmitted least significant byte first per the ISO/IEC 13239 (2002)
Annex A.

4.7.5. Acknowledgment

A positive or negative acknowledgment is used by the communicating devices to indicate either

acceptance or rejection of a single packet.

An <ack> shall be issued by the receiving device to the transmitting device for each valid packet
received.

<ack> ::= 06H

A <nak> shall be issued by the receiving device to the transmitting device for each packet
received that:
(1) begins with <stp>, and
(2) must be followed by five (5) additional bytes followed by <length> bytes
followed by two (2) additional bytes, and
(3) is completely received without any intervening inter-character time-outs, and
(4) contains some other error.

<nak> ::= 15H

4.7.6. Retransmission

The same packet shall be transmitted if a <nak> is received, an invalid character is received, or
the acknowledge time-out elapses. After three (3) consecutive retries, automatic termination
shall occur.

If a duplicate packet is received by the target, the target shall disregard the duplicate packet and
return an <ack>.

4.7.7. Time-out

4.7.7.1. Channel Traffic Time-out

25
 ANSI C12.18 – 2005

The C12.18 Device shall terminate communications after waiting some period of time for a valid
PSEM Request or PSEM Response. This period of time, defined as the default Channel Traffic
Time-out, shall be six (6) seconds. It may be temporarily modified by the Wait Service.
Termination of communication due to Channel Traffic Time-out has the same effect of a
successful invocation of the Terminate Service.

4.7.7.2. Inter-character Time-out

The recipient of the packet shall handle the case when the end of a packet is lost. Inter-character
Time-out is defined as the minimum amount of time the recipient shall wait between bytes
within a packet when receiving data over the communication channel. The recipient shall wait at
least this amount of time before it ceases to wait for the remaining bytes of the packet and sends
a <nak>. The Inter-character Time-out shall be 500 milliseconds.

4.7.7.3. Response Time-out

The sender of the packet shall handle the condition where the <ack> or <nak> is lost. Response
Time-out is defined as the minimum amount of time the sender shall wait after a packet is sent to
receive an <ack> or <nak> over the communication channel. If this amount of time elapses, the
sender shall send the packet again, unless the retry attempts counter has reached its maximum
allowed value. The Response Time-out shall be two (2) seconds.

4.7.8. Delays

4.7.8.1. Turn-around Delay

The Turn-around Delay is the minimum delay the recipient must wait after receiving a packet
and before sending a positive or negative acknowledge. The Turn-around Delay shall be 175
microseconds.

26
 ANSI C12.18 – 2005

4.8. Layer-1—Physical Layer

4.8.1. Physical

.205
DIA., TRANSMITTER TRANSMISSION PATH
.175
.205
DIA., RECEIVER TRANSMISSION PATH
.175

.160 MIN.

OPTICAL
REFERENCE
PLANE
.835
.825 C
L
OPTICAL
PATH

C .244/.280 SYMMETRICAL MOUNTING

L SURFACE
.992
DIA.
.984

1.55 DIA. MIN CLEARANCE

FOR MATING DEVICE

FRONT VIEW SIDE VIEW

Notes:
1. All dimensions in inches
2. Not to scale

Figure 4-1: External View ANSI Type 2 Optical Port

27
 ANSI C12.18 – 2005

5.21
DIA., TRANSMITTER TRANSMISSION PATH
4.45
5.21
DIA., RECEIVER TRANSMISSION PATH
4.45

4.06 MIN.

OPTICAL
REFERENCE
PLANE
21.21
20.96 C
L
OPTICAL
PATH

C 6.20/7.11 SYMMETRICAL MOUNTING

L SURFACE
25.20
DIA.
24.99

39.37 DIA. MIN. CLEARANCE

FOR MATING DEVICE

FRONT VIEW SIDE VIEW

Notes:
1. All dimensions in mm.
2. Not to scale

Figure 4-2: External View ANSI Type 2 Optical Port

4.8.2. Basic Data

The Physical Layer data setting is specified below.

DATA POLARITY: LED on, start bit, space, logical zero (0)
LED off, stop bit, mark, logical one (1), quiescent state

4.8.3. Light Levels

4.8.3.1. Optical Characteristics

The wavelength of the radiated signals in both directions is between 800 nm and 1,000 nm
(infrared).

4.8.3.2. Transmitter Characteristics

28
 ANSI C12.18 – 2005

With reference to Figure 4-3: Test Arrangement for the Transmitter, the transmitter in the C12.18
Device generates a signal with a radiation strength Eø/T over a defined circular reference surface
(optically active area) of diameter d1. The test receiver is on the optical axis of the transmitter at
a distance d2 from the optical reference plane on the C12.18 Device.

The following limiting values apply:

The reference temperature is 23°C (±2°C).

d1 = 5 mm (± 1 mm)

Both conditions shall be met:

ON Condition OFF Condition

d2 = 10 mm (± 1 mm) 250 <Eø/T <7500 µW/cm2 Eø/T <10 µW/cm2
d2 = 25 mm (± 1 mm) 85 <Eø/T <7500 µW/cm2 Eø/T <10 µW/cm2

Optical axis of the transmitter

d1
Test Receiver

Transmitted Beam

d2
Optical Reference Plane
(Surface of metering device optical port)

Transmitter in the
metering device

Figure 4-3: Test Arrangement for the Transmitter

4.8.3.3. Receiver Characteristics

With reference to Figure 4-4: Test Arrangement for the Receiver, a test transmitter, located on
the optical axis, and positioned at a distance d2 from the optical reference plane of the C12.18

29
 ANSI C12.18 – 2005

Device, generates a signal with a radiation strength Eø/R over a defined circular reference surface
(optically active area) with a diameter d1 at the optical reference plane. The receiver shall
respond to test signals as follows:

The reference temperature is 23°C (±2°C).

d1 = 5 mm (± 1 mm)

Both conditions shall be met:

ON Condition OFF Condition

d2 = 10 mm (± 1 mm) 1000<Eø/R <7500 µW/cm2 Eø/T <10 µW/cm2
d2 = 25 mm (± 1 mm) 1000 <Eø/R <7500 µW/cm2 Eø/T <10 µW/cm2

Optical axis of the receiver

Test Transmitter

Transmitted Beam
d2
Optical Reference Plane
(Surface of metering device optical port)

Receiver in the
metering device

d1

Figure 4-4: Test Arrangement for the Receiver

4.8.3.4. Environmental Lighting Condition

The optical path (data transmission) shall not be affected by surrounding light with an intensity
of up to 16,000 lux (light composition comparable with daylight, including fluorescent light).

5. COMPLIANCE

A C12.18 Device is considered to be in compliance with this Standard if all of the following
conditions are met:

30
 ANSI C12.18 – 2005

1. The C12.18 Device shall:

− accept and act upon all service requests as defined in Section 4.2, Layer 7 -
Application Layer;
− respond with a <sns> if a requested service is optional and it is not supported;
− minimally support Identification, Logon, Logoff and at least one (1) form of
Read.

Any service defined in this Standard, when implemented, shall comply with the C12.18
service description.

2. Section 4.7, Layer 2 - Data Link Layer, must be adhered to in its entirety.

3. The C12.18 Device is compliant with this Standard if zero (0) features (<feature>) are
supported in the Identification Service.

4. The physical dimensions defined in Section 4.8.1, Physical, shall be met.

5. The light levels defined in Section 4.8.3, Light Levels, shall be met.

31
 ANSI C12.18 – 2005

ANNEX A - Communication Example (Layer 7 and Layer 2)

INFORMATIVE

Figure A-1: Communication Example, shows an example of a communications session between

a C12.18 Client (handheld) and a C12.18 Device (meter) in which a table is read. ANNEX B -
Packet Transmission Example, Figure B-1: Packet Transmission Example, shows the actual
packet data transmission of this example.

32
 ANSI C12.18 – 2005

INDEX
C12.18 CLIENT (HANDHELD) C12.18 DEVICE (METER)
AND
CHANNEL
LAYER 7 LAYER 2 LAYER 2 LAYER 7
DIRECTION

IDENTIFICATION REQUEST OUT PACKET 1 1 Æ

Å 2 ACK IDENTIFICATION REQUEST IN

Å 3 PACKET 1 IDENTIFICATION RESPONSE OUT

IDENTIFICATION RESPONSE IN ACK 4 Æ

NEGOTIATE REQUEST OUT PACKET 1 5 Æ

Å 6 ACK NEGOTIATE REQUEST IN

Å 7 PACKET 1 NEGOTIATE RESPONSE OUT

NEGOTIATE RESONSE IN ACK 8 Æ

LOGON REQUEST OUT PACKET 1 9 Æ

Å 10 ACK LOGON REQUEST IN

Å 11 PACKET 1 LOGON RESPONSE OUT

LOGON RESPONSE IN ACK 12 Æ

SECURITY REQUEST OUT PACKET 1 13 Æ

Å 14 ACK SECURITY REQUEST IN

Å 15 PACKET 1 SECURITY RESPONSE OUT

SECURITY RESPONSE IN ACK 16 Æ

READ REQUEST OUT PACKET 1 17 Æ

Å 18 ACK READ REQUEST IN

Å 19 PACKET 1 READ RESPONSE OUT

ACK 20 Æ
Å 21 PACKET 2
ACK 22 Æ
Å 23 PACKET 3
READ RESPONSE IN ACK 24 Æ

LOGOFF REQUEST OUT PACKET 1 25 Æ

Å 26 ACK LOGOFF REQUEST IN

Å 27 PACKET 1 LOGOFF RESPONSE OUT

LOGOFF RESPONSE IN ACK 28 Æ

TERMINATE REQUEST OUT PACKET 1 29 Æ

Å 30 ACK TERMINATE REQUEST IN

Å 31 PACKET 1 TERMINATE RESPONSE OUT

TERMINATE RESPONSE IN ACK 32 Æ

Figure A-1: Communication Example

33
 ANSI C12.18 – 2005

ANNEX B - Packet Transmission Example

INFORMATIVE

Figure B-1: Packet Transmission Example, shows the actual packet data being transmitted in
Figure A-1: Communication Example, in ANNEX A - COMMUNICATION EXAMPLE
(LAYER 7 AND LAYER 2). Numbers 1) – 32) refer to the numbers in Figure A-1:
Communication Example. All values are specified in hexadecimal format. The following
arbitrary information was used.

<std> = 00

<ver> = 02

<rev> = 00

<packet-size> = 0040 (64 bytes)

<nbr-packets> = 04 (4 packets)

<baud-rate> = 08 (19200 baud)

<user-id> = 1111

<user> = 01 02 03 04 05 06 07 08 09 0A

<password> = 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14

<table-id> = 0000

<offset> = 000010

<count> = 0096 (150 bytes)

<data> = 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24
25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36
37 38 39 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E
4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72
73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96

34
 ANSI C12.18 – 2005

1) Æ EE 00 00 00 0001 20 13 10
2) Å 06
3) Å EE 00 00 00 0005 00 00 02 00 00 C6 B5
4) Æ 06
5) Æ EE 00 20 00 0005 61 0040 04 08 8A 5F
6) Å 06
7) Å EE 00 20 00 0005 00 0040 04 08 7D F5
8) Æ 06
9) Æ EE 00 00 00 000D 50 1111 0102030405060708090A CA 33
10) Å 06
11) Å EE 00 00 00 0001 00 11 31
12) Æ 06
13) Æ EE 00 20 00 0015 51
0102030405060708090A0B0C0D0E0F1011121314 86 27
14) Å 06
15) Å EE 00 20 00 0001 00 80 51
16) Æ 06
17) Æ EE 00 00 00 0008 3F 0000 000010 0096 B0 7F
18) Å 06
19) Å EE 00 C0 02 0038 00 0096
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C
1D1E1F202122232425262728292A2B2C2D2E2F303132333435 BA 8E
20) Æ 06
21) Å EE 00 A0 01 0038
363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F5051
52535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D
F0 47
22) Æ 06
23) Å EE 00 80 00 002A
6E6F707172737475767778797A7B7C7D7E7F80818283848586878889
8A8B8C8D8E8F90919293949596 C3 BD B1
24) Æ 06
25) Æ EE 00 20 00 0001 52 17 20
26) Å 06
27) Å EE 00 20 00 0001 00 80 51
28) Æ 06
29) Æ EE 00 00 00 0001 21 9A 01
Figure B-1: Packet Transmission Example

35
 ANSI C12.18 – 2005

ANNEX C - Service Sequence State Control

INFORMATIVE

PSEM communications is defined as a series of “Service Sequence States.” The use of each
service may be restricted to one (1) or more states. Specific services also cause transitions
between states. The transition is implemented upon positive acknowledgement of the service.
The recognized states include.

a) Base State—This is the state at which communication begins. At this point the
default data transmission parameters apply.
b) ID State—Once the C12.18 Device has been identified, this is the state that is entered.
c) Session State—When a successful logon has been completed, this is the state
achieved.

The relationship between PSEM services and service sequence states is:

Identification Service requests are accepted at the Base State only. Acceptance of an
Identification Service response <ok> transitions communications to the ID State. The
Identification Service cannot originate from the C12.18 Device.

Wait Service requests are accepted in the ID and Session States. Acceptance of these requests do
not result in any sequence state changes. The Wait Service can originate from either end of the
communication channel.

Negotiate Service requests are accepted in the ID State only. Acceptance of these requests do
not result in any sequence state changes. Negotiated services are not implemented until after
acceptance. The Negotiate Service cannot originate from the C12.18 Device.

Logon Service requests are accepted at the ID State only. Acceptance of a Logon Service
request, <ok> transitions communications to the session state. This service cannot originate
from the C12.18 Device.

Security Service requests are accepted at the Session State only. Acceptance of these requests do
not result in any sequence state changes. The Security Service cannot originate from the C12.18
Device.

Read and Write Service requests are accepted in the Session State only. Acceptance of these
requests do not result in any sequence state changes. These services can originate from either the
C12.18 Device or the C12.18 Client.

Logoff Service requests are accepted at the Session State only. Acceptance of a Logoff Service
request, <ok> transitions communications to the ID State. This service can originate from either
the C12.18 Device or the C12.18 Client.

36
 ANSI C12.18 – 2005

Terminate Service requests are accepted at the ID and Session States. Acceptance of a
Terminate Service request, <ok> transitions communications to the Base State. This service can
originate from either the C12.18 Device or the C12.18 Client.

37
 ANSI C12.18 – 2005

Base state

Identification

ID state

Negotiate

Wait

Terminate

Logon

Session state
Read

Write

Security

Wait

Terminate

Logoff

Figure C-1: Communication State Diagram

38
 ANSI C12.18 – 2005

ANNEX D - Compatibility

INFORMATIVE

1996 2005

2 1

1996 2005

Figure D-1: C12.18 Device Compatibility Diagram

Key:
Path 1 (solid line):
Path 2 (dashed line) :
Backward compatible for the Reader; Forward compatible for
the Device.
Forward compatible for the Reader; Backward compatible for
the Device.

D.1 Backward compatibility with previous versions of the Standard

Any future revision of this Standard shall be backward compatible with the previous two (2)
revisions of the Standard as defined by the 5-year ANSI revision cycle requirement.

D.2 Forward compatibility with next versions of the Standard

39
 ANSI C12.18 – 2005

The following forward compatibility criteria shall be used when extending this standard:

1. The following forward compatibility criteria shall be used when extending this Standard.
Services may be:
1. defined as new;
2. omitted;
3. required where it had been optional;
4. optional where it had been required.

For cases 2 and 4, the response code <sns> shall be generated for any service that is not
supported.

For case 3, the response code <sns> shall not be generated for any required service.

Example of case 4:

Assume that the Security Service was originally defined as follows:

4.2.2.7 Security Service

The Security Service is identical to that in C12.18-1996, except that it is now

optional.

Also assume that ANSI Standard C12.18-1996 states:

…
<security> ::= 51H <password>
…
The response <ok> indicates the security service was successfully completed and
the access permissions associated with the password were granted.

<security-r> ::= <err> |

<bsy> |
<isss> |
<ok>

It is clear that the change fails to allow for the response code <sns> (Service Not
Supported), then any implementation of <security> may respond with <security-r> if and
only if there is a condition that can successfully generate an <ok> response for a given
<security> request. If there is no possibility for the <security> service to operate or be
made to operate correctly for this device then the <sns> shall be generated.

This enable this Standard to extend another or be modified consistently where some
required services in one revision or referenced standard become inoperative or optional in
other.

2. No tables, procedures or data types shall be introduced or modified by this Standard. These
items are to be instead proposed for ANSI C12.19.

40
 ANSI C12.18 – 2005

ANNEX E - Historical Background

INFORMATIVE

E.1 Foreword of C12.18-1996 and C12.18-1996 (R2002)

(This foreword is not part of American National Standard for Protocol Specification for ANSI
Type 2 Optical Port, ANSI C12.18-1995.)

This American National Standard provides an open platform communications protocol for two-
way communication with an electronic metering device or an electromechanical metering device
with an added electronic board. The communications is specified to pass through an ANSI Type
2 Optical Port. The protocol is written to conform to the OSI seven-layer stack.

Suggestions for improvement to this standard are welcome. They should be sent to:

National Electrical Manufacturers Association

Vice President of Engineering
1300 North 17th Street
Suite 1847
Rosslyn, VA 22209

This standard was processed and approved for submittal to ANSI by Accredited Standards
Committee for Electricity Metering, C12. At the time the committee approved this standard, the
C12 Committee had the following members:

R.S. Turgel, Chairman

Christopher F. Merther, Secretary

Cruz Gomez
H. Jones
Lauren Pananen
Timothy Vahlstrom
Clark Smith
James Mining
Joe Blackmer
John McEvoy
Dan McAuliff
Herman Millican
Tom Drew
Ray Stevens
Francis Marta
James Schlatter
John Lauletta

41
 ANSI C12.18 – 2005

Warren Germer
Edmund Hoffman
Ahn Mai
Ralph Fahmy

Subcommittee 17 that developed the standard consisted of:

Lynnda K. Ell, Chairwomen

John Lauletta, Vice Chairman
Michael Anderson
Ellen Edge
Lynnda Ell
Bill Gibson
Bruce Johnson
Larry Kotewa
Tempe Lampe
Avy Moise
Terry Penn
Wes Ray
Clark Smith
Chris Stanfield
George Stephens
Paul Taylor
Kurt Wiechert
Michel Veillette

42