ANSI C12.

18-2006
American National Standard
Protocol Specification for ANSI
Type 2 Optical Port
ANSI C12.18-2006
Revision of ANSI C12.18-1996
American National Standard
Protocol Specification for ANSI Type 2 Optical Port
Secretariat:
National Electrical Manufacturers Association
Approved May 2, 2006
American National Standards Institute, Inc.
ANSI C12.18-2006
NOTICE AND DISCLAIMER
The information in this publication was considered technically sound by the consensus of
persons engaged in the development and approval of the document at the time it was
developed. Consensus does not necessarily mean that there is unanimous agreement among
every person participating in the development of this document.
NEMA standards and guideline publications, of which the document contained herein is one,
are developed through a voluntary consensus standards development process. This process
brings together volunteers and/or seeks out the views of persons who have an interest in the
topic covered by this publication. While NEMA administers the process and establishes rules to
promote fairness in the development of consensus, it does not write the document and it does
not independently test, evaluate, or verify the accuracy or completeness of any information or
the soundness of any judgments contained in its standards and guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature
whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly
resulting from the publication, use of, application, or reliance on this document. NEMA disclaims
and makes no guaranty or warranty, express or implied, as to the accuracy or completeness of
any information published herein, and disclaims and makes no warranty that the information in
this document will fulfill any of your particular purposes or needs. NEMA does not undertake to
guarantee the performance of any individual manufacturer or seller’s products or services by
virtue of this standard or guide.
In publishing and making this document available, NEMA is not undertaking to render
professional or other services for or on behalf of any person or entity, nor is NEMA undertaking
to perform any duty owed by any person or entity to someone else. Anyone using this document
should rely on his or her own independent judgment or, as appropriate, seek the advice of a
competent professional in determining the exercise of reasonable care in any given
circumstances. Information and other standards on the topic covered by this publication may be
available from other sources, which the user may wish to consult for additional views or
information not covered by this publication.
NEMA has no power, nor does it undertake to police or enforce compliance with the contents of
this document. NEMA does not certify, test, or inspect products, designs, or installations for
safety or health purposes. Any certification or other statement of compliance with any health or
safety–related information in this document shall not be attributable to NEMA and is solely the
responsibility of the certifier or maker of the statement.
ANSI C12.18-2006

i
AMERICAN
NATIONAL
STANDARD
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 North 17th Street, Rosslyn, VA 22209
© Copyright 2006 by National Electrical Manufacturers Association
All rights reserved 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 form, in an electronic retrieval system or
otherwise, without the prior written permission of the publisher.
Printed in the United States of America

ii
ANSI C12.18-2006

This page intentionally left blank.

ANSI C12.18-2006

iii
Contents
Page
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 ..................................................................................1
3.1.4 Table ...........................................................................................................................2
3.2 Document Syntax ...........................................................................................................2
4 Protocol Details .................................................................................................................2
4.1 Order of Transmission ....................................................................................................3
4.2 Layer 7—Application Layer ............................................................................................3
4.2.1 Data Structure .............................................................................................................3
4.2.2 Protocol Specifications for Electric Metering ...............................................................3
4.2.2.1 Request Codes.............................................................................................................4
4.2.2.2 Response Codes..........................................................................................................4
4.2.2.3 Identification Service ....................................................................................................6
4.2.2.4 Read Service ................................................................................................................9
4.2.2.5 Write Service ..............................................................................................................11
4.2.2.6 Logon Service.............................................................................................................12
4.2.2.7 Security Service..........................................................................................................13
4.2.2.8 Logoff Service.............................................................................................................13
4.2.2.9 Negotiate Service .......................................................................................................14
4.2.2.10 Wait Service ...............................................................................................................15
4.2.2.11 Terminate Service ......................................................................................................15
4.2.2.12 Partial Table Access Using the Index/element-count Method ...................................16
4.2.2.13 Index Count Access Method Examples .....................................................................17
4.2.2.14 Partial Table Access Using the Offset/octet-count Method........................................18
4.3 Layer 6—Presentation Layer .............................................................................................19
4.4 Layer 5—Session Layer ...................................................................................................19
4.5 Layer 4—Transport Layer .................................................................................................19
4.6 Layer 3—Network Layer ...................................................................................................19
4.7 Layer 2—Data Link Layer ..................................................................................................19
4.7.1 Basic Data .....................................................................................................................19
4.7.1.1 Default Settings ..........................................................................................................20
4.7.2 Packet ..........................................................................................................................20
4.7.3 Duplicate packets ...........................................................................................................21
4.7.4 CRC selection ................................................................................................................22
4.7.5 Acknowledgment ............................................................................................................22
4.7.6 Retransmission ...............................................................................................................22
4.7.7 Time-out ....................................................................................................................22
4.7.7.1 Channel Traffic Time-out............................................................................................22
4.7.7.2 Inter-character Time-out.............................................................................................22
4.7.7.3 Response Time-out ....................................................................................................23
4.7.8 Delays ...........................................................................................................................23
4.7.8.1 Turn-around Delay......................................................................................................23
4.8 Layer-1—Physical Layer ................................................................................................23
4.8.1 Physical .......................................................................................................................23
4.8.2 Basic Data ...................................................................................................................24
4.8.3 Light Levels ..................................................................................................................24
4.8.3.1 Optical Characteristics ...............................................................................................24
4.8.3.2 Transmitter Characteristics ........................................................................................24

ANSI C12.18-2006
Iv

4.8.3.3 Receiver Characteristics ............................................................................................25

4.8.3.4 Environmental Lighting Condition...............................................................................26
5 Compliance .........................................................................................................................26
Annex A - Communication Example (Layer 7 and Layer 2) ...................................................27
Annex B - Packet Transmission
Example...................................................................................................29
Annex C - Service Sequence State
Control................................................................................................31
Annex D –
Compatibility..............................................................................................................................33
D.1 Backward compatibility with previous versions of the Standard ........................................33
D.2 Forward compatibility with next versions of the Standard .................................................33
Annex E - Historical Background ..............................................................................................35
E.1 Foreword of C12.18-1996 and C12.18-1996 (R2002) .......................................................35
ANSI C12.18-2006

v
Foreword (This Foreword is not part of American National Standard C12.18-2006.)
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 2006 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 1752
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
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
ANSI C12.18-2006
vi
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

1
AMERICAN NATIONAL STANDARD ANSI C12.18-2006
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 masterstation 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
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 asingle optical interface.

3.1.4. Table
Functionally related data elements, grouped together into a single data structure for
transport asdefined 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 aremeant to be independent of specific language and, hopefully,
capable of being implementedwithin the confines of any language, a method for
describing the data definitions must bedeveloped. A modified form of the Backus-
Naur Form (BNF) will serve as the basis for buildingthe 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
itmay 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
lefthand 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
thanone 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.

+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 isconsidered 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
cannel 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, theApplication Layer provides Logon, Security and Logoff services for
session activation, accesscontrol and deactivation, Read and Write services for issuing
data transmission requests, aTerminate 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 orWrites, Logoff and Terminate. Note that this brief example
does not detail the packet structureor 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.
Service parameters in all layers within the protocol definition are transmitted most
significantbyte first. The order of transmission of data field parameters within Tables is
dictated by theTable structure.

Bytes are transmitted in frames. Each frame consists of a start bit, followed by <byte>,
andending 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

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 {AcknowledgeApplication Layer
response indicating no problems, request accepted.}
<err> ::= 01H {Error This Application Layer error
codeis used to indicate rejection of the received service
request. Thereason for the rejection is not provided.}

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

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
therequest could not be honored.}

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

Application Layer error indicates that the current
authorization level is insufficientto complete the
request.}

<onp> ::= 04H {Operation Not PossibleThis Application Layer

error willbe sent to the device whichrequested an
action that is notpossible. This error indicatesthat
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 invalidtable id.}

<bsy> ::= 06H {Device BusyThis 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 ReadyThis 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 RequestThis Application Layer error
indicates that the responding device wishes to
return to the IDor 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 information on service sequenc estates, see
Annex C, ServiceSequence 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 indicatinga
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 andrevision are included in the response. Implementers shall ensure that the
response fits within asingle 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 asfollows:
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 versión number. Previous
versions shall be Version 1. This version shall be
Version 2.}

<rev> ::= <byte> {Referenced Standard revisionnumber. 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 thatuniquely identifies a
C12.19 DeviceClass 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 Version2 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 LogonService. When C12.19
Device Classis 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 asan 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/IEC8825-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 theC12.19 Device Class
relative to the universal identifier1.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
shall be identical to the C12.19 Table elements
MANUFACTURER asdefined in Table 00 of
ANSI C12.19-1997 or the DEVICE_CLASS as
definedby Version 2 of ANSI C12.19, with
assumed 00H trailing pad.}

<uid-length> ::= <byte>

{Length of number of bytes that follow. This
value shall rangebetween 00Hto 7FH.}

<absolute-uid> ::= <byte>

{Absolute object identifier encodedas described in
ISO/IEC 8825-1(2002), Basic Encoding Rules
(BER).The size of this field shall notexceed 127
bytes.}

<relative-uid> ::= <byte>

{Relative object identifier encodedas described in
ISO/IEC 8825-1(2002), Basic Encoding Rules
(BER).The size of this field shall notexceed 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_IDfound 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 byfeatures with codes that are less
than 07H.}

<identity-length>::= <byte>
{Length of number of bytes thatfollow in
<identity>. This valueshall range between 00Hto
7FH.}

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

{Provides for disclosure of theC12.19 Device
identification.}

<char-format> ::= <byte>

{The character encoding format of the bytes
which make up<identification>. Its interpretation
shall be accordingto the relevant ANSI C12.19
Standard data model referenced by the C12.19
registered Device Classfeature <device-class>.
When the<device-class> feature is not supplied in
this <ident> response, the value of <char-format>
shall beset to 01H
, and <identification>shall be encoded according
to ISO7-bit coded character set forinformation
interchange, perISO/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 perchar-
format>. For example, assuming that the C12.19
DeviceGEN_CONFIG_TBL.ID_FORM is BCD
and the
DeviceGEN_CONFIG_TBL.CHAR_FORMAT
is ISO 7bit 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 carácter sequence “123-4.567”. The C12.19
 application shall logically pad this string with
trailing spaces asneeded 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 aportion 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 acomplete Table transfer. Request codes 31H through 39H specify a
partial Table transfer using 1 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}
33 H| {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 definedby the C12.19 Device.}

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

<tableid> ::= <word16> {Table identifier as defined inANSI C12.19.}

<offset> ::= <word24> {Offset into data Table in bytes.Offset 0000H is the
offset to thefirst table element of the Tableselected by <tableid>.}

<index> ::= <word16> {Index value used to locate startof data. Index 0000H
is the index ofthe first Table element of theTable selected by
<tableid>.}

<element-count> ::= <word16> {Number of Table elements to readstarting at the

requested index.}

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

<offset>, inbytes.}

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>

<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 computedonly 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 acomplete 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-countmethod.

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

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

C12.19.}

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

the offset to thefirst element of the Table selectedby <tableid>.}

<index> ::= <word16> {Index value used to locate startof data. Index 0000H is the
index ofthe first element of the Tableselected by <tableid>.}

<table-data> ::= <count><data><cksum><count> ::= <word16> {Length of <data> to

be written, inbytes. This includes the optionalpending header length as defined
byANSI C12.19.}

<data> ::= <byte> {The Table data elements includingthe optional pending
header as perANSI C12.19, when requested.}

<cksum> ::= <byte> {2's compliment checksum computedonly on the <data> portion
of<table-data>. The checksum iscomputed by summing the bytes(ignoring overflow)
and negatingthe 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 wassuccessfully 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 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. Thisfield 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 besent 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 (Table42) 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), which ever is smaller.
<security> ::= 51H <password>

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

Response:
The responses <sns>, <isss>, <bsy> and <err> indicate a problem with the received
SecurityService 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
LogonService.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
Servicerequest.The response <ok> indicates the acceptance of the Logoff Service and
the cessation of thesession 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 ineffect until re-negotiated or the communication
channel is closed.The Negotiate Service shall be initiated only by a C12.18 Client.
Request:
<negotiate> ::= <baud-rate-selector><packet-size><nbr-packets><baud-rate>

<baud-rate-selector>::= 60H| {No <baud rate> included inrequest. 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 inrequest}
6BH{11 <baud rate> included inrequest}

<packet-size> ::= <word16> {Maximum packet size supported, inbytes. This

value shall be in therange of 64 - 8192 bytes,inclusive.}

<nbr-packets> ::= <byte> {Maximum number of packets thislayer is able to

reassemble into anupper layer data structure at onetime. The value zero (0) isreserved
for future standardextension.}

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

01H| {300 baud}
02H| {600 baud}
03H | {1200 baud}
04H| {2400 baud}
05H| {4800 baud}
06 H| {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
NegotiateService request and that the communication channel will maintain its current
settings
The response <ok> indicates the Negotiate Service request was accepted and all new
settingsnow apply to both devices. The data following the <ok> indicates the new
settings. If the targetcannot accept the Negotiate Service request baud rates, the original
baud rate will be echoed inthe 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 WaitService 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
WaitService 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 conditions, end of session, or other reasons as set by the device manufacturer.
When theTerminate 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 requestand the channel remains open.The response <ok> indicates the service
request was accepted and the channel will return todefault 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
theTable, where PACKED RECORD, BIT FIELD, SET, ARRAY, STRING, IF and
CASE aredefined 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
valuezero (0).

•The positional number of subsequent sub elements in the same BIT FIELD
isincremented 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’selement index for use in selections.

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

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

2.
Selection based on an index method using <element-count> equal to one (1) will
deliverthe 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
zero sat 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 therequest 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 element savailable at the same or lower hierarchical level of the <index>used
to initiated therequest..

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
interpretedas 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
wasreceived.

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 theselection start <index>.

11.
As a part of a Read Service request, <element-count> represents the maximum
number of elements requested.
12.
Any element excluded from the data stream through the use of the IF or CASE
conditionalstatements 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
becounted.

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

16.
If the respondent application does not support the transmission elements at the
requestedindex level, or the respondent application cannot deliver the element
requested from anARRAY the respondent application shall assert the error condition
"Inappropriate ActionRequested". The requester may then attempt a retry of the Read
or Write Service request onan <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

Ejemplo 1 Ejemplo 2 Ejemplo 3 Ejemplo 4

<index> = 1.0 <index> = 1, <index> = 1.2.0, <index> = 1.2,
<element- <element- <element- <element-
count> = 2 count> = 2 count> =4 count> = 4
or<index> = 1.0, or<index> =
<element- 1.2.0, <element-
count> =4 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
theTable

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, whereeach 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
numberof 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
startingfrom 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
wasreceived.

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 optionalpending 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
datastream 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
becounted.

11.
The octet counter counts octets and not elements.

12.
If the respondent application does not support the transmission of octets at the
requestedoffset, the respondent application shall assert the error condition
"Inappropriate ActionRequested”.

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

Null layer. Communications between devices over the optical port communications
path will beconnection oriented and consist of a single session. A session is defined to
begin with theacceptance 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 inlength but cannot exceed a maximum packet size. The maximum packet
size has a default valuewhen the communication channel is opened. The maximum
packet size can be changed throughthe 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
therequester does not receive an acknowledgment before the Response Time-out, or a
negativeacknowledgment is received, the same packet is re-transmitted up to three (3)
times. After thethird 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, andpacket size each have a default setting which applies at the initiation of
communication. Thesesettings may be changed through the Negotiate Service.
Negotiated channel settings will returnto 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 dúplex

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 9600baud.

Selection codes have been arranged for thefollowing baud rates: 300, 600, 1200, 2400,
4800, 9600,14400, 19200, 28800, 38400, 57600, 115200, 128000,256000 or
externally defined. Additional selection codeshave been reserved for future
assignment.

NUMBER OF PACKETS: At least one (1) packet is required although more

arenegotiable.PACKET SIZE: Default packet size is 64 bytes, although a larger size
canbe negotiated.

CHANNEL TRAFFIC TIME-OUT: 6 seconds

INTER-CHARACTER TIME-OUT: 500 milliseconds

RESPONSE TIME-OUT: 2 seconds

TURN-AROUND DELAY: 175 microsecondsIn 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: 1PACKET 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, tabledriven communication

card, etc.) identity. It identifies the C12.19 Device in both the request andresponse
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 ParametersTable (Table 92) of
ANSI C12.21-1999.The value FFH is reserved for ANSIC12.21 calling party use. It
shall not be used by this protocol.The C12.19 Device shall use its ownidentity byte or
00H in the response when addressed with an identity other than 00H ; otherwise,
theresponse identity byte shall be 00 H.}

<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 amultiple
packet transmission, and Bit 7 shall also be true.
Bit 5. Represents a toggle bit toreject duplicate packets. This bit
shall be toggled for each newpacket sent. Retransmitted
packetskeep the same state as the originalpacket 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 bitsshall be set to zero (0) by the
transmitter.Bit 0 to 1: DATA_FORMAT0 = C12.18 or C12.211
= C12.222 = Reserved3 = Reserved C12.18 Compliant
implementation sshall 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 packettransmission
shall have a <seq-nbr>equal to the total number of packets minus
one (1). A value of zero (0) in this field indicatesthat this packet is
the last packetof a multiple packet transmission.If only one (1)
packet in atransmission, this field shall beset to zero (0), and Bit 7
and Bit6 shall be set to zero (0).}

<length> ::= <word16> {Number of bytes of data inpacket.}

<data> ::= <byte> {<length> number of bytes of actualpacket data. This value is
limitedby the maximum packet size minusthe 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
identicalto 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, the toggle bit in the first packet may assume any state and
the duplicate packet rejectionmechanism 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 theCRC 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 packetreceived.

<ack> ::= 06H

A <nak> shall be issued by the receiving device to the transmitting device for each
packetreceived that:

(1) begins with <stp>, and

(2) must be followed by five (5) additional bytes followed by <length>
bytesfollowed 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
The C12.18 Device shall terminate communications after waiting some period of time
for a validPSEM Request or PSEM Response. This period of time, defined as the
default Channel TrafficTime-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 asuccessful 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-
characterTime-out is defined as the minimum amount of time the recipient shall wait
between byteswithin a packet when receiving data over the communication channel.
The recipient shall wait atleast this amount of time before it ceases to wait for the
remaining bytes of the packet and sendsa <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.
ResponseTime-out is defined as the minimum amount of time the sender shall wait
after a packet is sent toreceive an <ack> or <nak> over the communication channel. If
this amount of time elapses, thesender shall send the packet again, unless the retry
attempts counter has reached its maximumallowed 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
packetand before sending a positive or negative acknowledge.
The Turn-around Delay shall be 175microseconds.

4.8. Layer-1—Physical Layer

4.8.1. Physical
Falta

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

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>)
aresupported 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.

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

INFORMATIVE
Figure A-1: Communication Example, shows an example of a communications
session betweena 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 actualpacket data transmission of this
example.
 Ejemplo de comunicaciones

ANNEX B - Packet Transmission Example

INFORMATIVE
Figure B-1: Packet Transmission Example, shows the actual packet data being
transmitted inFigure 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 followingarbitrary 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 1213 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 1213 14
15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 2425 26 27 28 29 2A 2B 2C 2D 2E
2F 30 31 32 33 34 35 3637 38 39 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E4F
50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 6061 62 63 64 65 66 67 68 69 6A
6B 6C 6D 6E 6F 70 71 7273 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83
8485 86 87 88 89 90 91 92 93 94 95 96

1) -> EE 00 00 00 00 01 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

510102030405060708090A0B0C0D0E0F1011121314 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
00960102030405060708090A0B0C0D0E0F1011121314151617181
91A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132
333435 BA 8E
20) -> 06

21) -> EE 00 A0 01
0038363738393A3B3C3D3E3F404142434445464748494A4B4C4D
4E4F505152535455565758595A5B5C5D5E5F60616263646566676
8696A6B6C6DF0 47
22) <- 06
23) <- EE 00 80 00
002A6E6F707172737475767778797A7B7C7D7E7F8081828384858
68788898A8B8C8D8E8F90919293949596 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

Figure B-1: Packet Transmission Example

ANNEX C - Service Sequence State Control

INFORMATIVE

PSEM communications is defined as a series of “Service Sequence States.”

The use of eachservice may be restricted to one (1) or more states.
Specific services also cause transitionsbetween 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
thedefault 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
stateachieved.

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 donot result in any sequence state changes.
The Wait Service can originate from either end of thecommunication
channel.Negotiate Service requests are accepted in the ID State only.
Acceptance of these requests donot result in any sequence state changes.

Negotiated services are not implemented until afteracceptance. The

Negotiate Service cannot originate from the C12.18 Device.

Logon Service requests are accepted at the ID State only. Acceptance of a

Logon Servicerequest, <ok> transitions communications to the session
state. This service cannot originatefrom the C12.18 Device.

Security Service requests are accepted at the Session State only.

Acceptance of these requests donot result in any sequence state changes.
The Security Service cannot originate from the C12.18Device.

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

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

Terminate Service requests are accepted at the ID and Session States. Acceptance of
aTerminate Service request, <ok> transitions communications to the Base State. This
service canoriginate from either the C12.18 Device or the C12.18 Client.
 Figure C-1: Communication State Diagram

ANNEX D – Compatibility
INFORMATIVE
Figure D-1: C12.18 Device Compatibility Diagram

Key:
Path 1 (solid line): Backward compatible for the Reader; Forward
compatible forthe Device.
Path 2 (dashed line) : Forward compatible for the Reader; Backward
compatible forthe 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

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 notsupported.

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 andthe 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 NotSupported), then any implementation of <security> may
respond with <security-r> if andonly 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 bemade to
operate correctly for this device then the <sns> shall be generated.
This enable this Standard to extend another or be modified consistently
where somerequired services in one revision or referenced standard become
inoperative or optional inother.

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.