IEC 62055-52:2008

IEC 62055-52
Edition 1.0 2008-05
INTERNATIONAL
STANDARD
Electricity metering – Payment systems –
Part 52: Standard transfer specification (STS) – Physical layer protocol for a two-
way virtual token carrier for direct local connection

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC 62055-52
Edition 1.0 2008-05
INTERNATIONAL
STANDARD
Electricity metering – Payment systems –
Part 52: Standard transfer specification (STS) – Physical layer protocol for a
two-way virtual token carrier for direct local connection

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XA
ICS 35.100.20; 17.220.20; 91.140.50 ISBN 2-8318-9747-5

– 2 – 62055-52 © IEC:2008(E)
CONTENTS
FOREWORD.5
INTRODUCTION.7

1 Scope.9
2 Normative references .9
3 Terms, definitions and abbreviations .10
3.1 Terms and definitions .10
3.2 Abbreviations .10
3.3 Notation and terminology.11
3.4 Numbering conventions .12
4 STS protocol reference model .12
5 POSToTokenCarrierInterface: Physical layer protocol .13
6 TokenCarrierToMeterInterface: Physical layer protocol.13
6.1 TCDU .13
6.1.1 General .13
6.1.2 TokenData.13
6.1.3 AuthenticationResult.14
6.1.4 ValidationResult .14
6.1.5 TokenResult .14
6.2 Physical connection and signal interfaces .14
6.2.1 Interface options.14
6.2.2 Option 1: Optical interface .14
6.2.3 Option 2: Current loop interface.14
6.2.4 Option 3: Voltage interface .14
6.3 Character transmission.14
6.3.1 Transmission type .14
6.3.2 Transmission format .15
6.3.3 Transmission speed.15
6.3.4 Character encoding .15
6.4 Message syntax definitions .17
6.4.1 General .17
6.4.2 IDRequest message .17
6.4.3 IDResponse message.17
6.4.4 ReadCommand message.17
6.4.5 WriteCommand message.18
6.4.6 BreakCommand message .18
6.4.7 ACK: Acknowledge message .18
6.4.8 NAK: NegativeAcknowledge message .18
6.4.9 Data message .18
6.5 Message field definitions .19
6.6 Physical layer protocol functions .21
6.6.1 Server protocol flow diagram .21
6.6.2 IDRequestProcessing function.22
6.6.3 ReadCommandProcessing function .23
6.6.4 WriteCommandProcessing function .24
6.6.5 BreakCommandProcessing function .25

62055-52 © IEC:2008(E) – 3 –
6.6.6 Undefined command processing .26
6.6.7 TokenLockout function.27
6.7 Server timing requirements.27
6.7.1 Inter-message and inter-character timing.27
6.7.2 Transmission error timing .28
6.7.3 Message execution timing .29
6.8 RegisterTable.30
6.8.1 RegisterTable interface class .30
6.8.2 Register interface class .31
6.8.3 Predefined Registers and registerID values .32
6.9 Companion specifications and RegisterTable instantiations.43
7 Maintenance of STS entities and related services.43
7.1 General .43
7.2 RegisterTable maintenance .44
7.3 Register maintenance.44
7.4 tableID maintenance .44
7.5 FOIN maintenance .45
7.6 protocolVersion maintenance .45
7.7 serverStatus maintenance .45
7.8 tokenStatus maintenance .45
7.9 softwareVersion maintenance.45

Annex A (normative) Server state diagrams for request message processing.46

Bibliography.51

Figure 1 – Physical layers of the STS protocol stack.12
Figure 2 – Character transmission format .15
Figure 3– Server protocol flow diagram.21
Figure 4 – Inter-message timing responses.28
Figure 5 –Transmission error timing.29
Figure A.1 – Server state diagram for IDRequestProcessing function.46
Figure A.2 – Server state diagram for ReadCommandProcessing function .47
Figure A.3 – Server state diagram for WriteCommandProcessing function .48
Figure A.4 – Server state diagram for BreakCommandProcessing function .49
Figure A.5 – Server state diagram for undefined command .50

Table 1 – Data elements in the TCDU .13
Table 2 – Bit-encoding of a 7-bit character code .15
Table 3 – Character encoding example of a 14-bit binary number .16
Table 4 – Character encoding example of a 4-digit hexadecimal number .16
Table 5 – Character encoding example of a 4-digit decimal number.17
Table 6 – Message field definitions .19
Table 7 – Request messages supported by the server .22
Table 8 – Response messages supported by the server .22
Table 9 – Functions supported by the server.22

– 4 – 62055-52 © IEC:2008(E)
Table 10 – Server timing requirements to respond to a request message.28
Table 11 – Inter-character timing requirements .28
Table 12 – Transmission error recovery wait period .29
Table 13 – Generic format for RegisterTable.30
Table 14 – Generic format for Register .31
Table 15 – Predefined Registers and registerID values.32
Table 16 – Instance format for ProtocolVersion register .33
Table 17 – Defined protocolVersion values .34
Table 18 – Instance format for TableID register .34
Table 19 – Instance format for ServerStatus register .35
Table 20 – Defined serverStatus values.36
Table 21 – Instance format for SoftwareVersion register .37
Table 22 – Instance format for BinaryTokenEntry register .38
Table 23 – Instance format for TokenStatus register .39
Table 24 – Defined tokenStatus values .40
Table 25 – Instance format for TokenLockoutTimeRemaining register.42
Table 26 – Entities/services requiring maintenance service .44

62055-52 © IEC:2008(E) – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ELECTRICITY METERING –
PAYMENT SYSTEMS –
Part 52: Standard transfer specification (STS) –
Physical layer protocol for a two-way virtual token carrier
for direct local connection
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance
with this International Standard may involve the use of a maintenance service concerning encryption key
management and the stack of protocols on which the present International Standard IEC 62055-41 is based. [See
Clause C.1 of IEC 62055-41.] The IEC takes no position concerning the evidence, validity and scope of this
maintenance service.
The provider of the maintenance service has assured the IEC that he is willing to provide services under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the
statement of the provider of the maintenance service is registered with the IEC. Information may be obtained from
Address: The STS Association, P.O. Box 868, Ferndale 2160, Republic of South Africa.
Tel: +27 11 789 1384
Fax: +27 11 789 1385
Email: email@sts.org.za
Website: http://www.sts.org.za

– 6 – 62055-52 © IEC:2008(E)
International Standard IEC 62055-52 has been prepared by working group 15, of IEC
technical committee 13: Electrical energy measurement, tariff and load control.
IEC 62055-52 is complementary to, and should be read in conjunction with, IEC 62055-41.
The text of this standard is based on the following documents:
FDIS Report on voting
13/1424/FDIS 13/1428/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts of IEC 62055 series, published under the general title Electricity metering –
Payment systems, can be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

62055-52 © IEC:2008(E) – 7 –
INTRODUCTION
The IEC 62055 series covers payment systems, encompassing the customer information
systems, point of sales systems, token carriers, payment meters and the respective interfaces
that exist between these entities. At the time of preparation of this part, IEC 62055 comprised
the following parts, under the general title Electricity metering – Payment systems:
Part 21: Framework for standardization
Part 31: Particular requirements – Static payment meters for active energy (classes 1 and 2)
Part 41: Standard transfer specification(STS) – Application layer protocol for one-way token
carrier systems
Part 51: Standard transfer specification(STS) – Physical layer protocol for one-way numeric
and magnetic card token carriers
Part 52: Standard transfer specification(STS) – Physical layer protocol for a two-way virtual
token carrier for direct local connection
The Part 4x series specifies application layer protocols and the Part 5x series specifies
physical layer protocols.
The protocol in this International Standard is based on the IEC 62056-21 communication
protocol and has been simplified by removing features from the IEC 62056-21 protocol, which
are not required for the current requirements of data exchange between the VTC07 client
device and the payment meter server.
The main design objective in establishing the protocol has been the requirement to reduce the
complexity of the software that is needed to implement this protocol in the payment meter.
This directly relates to a smaller memory size that can be translated into a cost saving or the
ability to include additional software features for a given memory size.
The Standard Transfer Specification (STS) is a secure message protocol that allows
information to be carried between point of sale (POS) equipment and payment meters and it
caters for several message types such as credit, configuration control, display and test
instructions. It further specifies devices and Codes Of Practice that allows for the secure
management (generation, storage, retrieval and transportation) of cryptographic keys used
within the system.
The national electricity utility in South Africa (Eskom) first developed and published the STS
in 1993 and transferred ownership to the STS Association in 1998 for management and
further development.
Prior to the development of the STS, a variety of proprietary payment meters and POS
equipment had been developed, which were however not compatible with each other. This
gave rise to a definite need among the major users to move towards standardized solutions in
addressing operational problems experienced where various types of payment meter and POS
equipment had to be operated simultaneously. The Standard Transfer Specification was
developed that would allow for the application and inter-operability of payment meters and
POS equipment from multiple manufacturers in a payment metering installation.
The TokenCarrier is the physical medium used to transport information from a POS or the
management system to the payment meter, or from the payment meter to the POS or
management system. This part of IEC 62055 specifies a virtual token carrier as embodied in a
direct local connection between a management device client and a payment meter server. It
has been assigned identification code 07 by the STS Association and is also generally
referred to as VTC07. New token carriers can be proposed as new work items through the
National Committees or through the STS Association.
Although the main implementation of the STS is in the electricity supply industry, it inherently
provides for the management of other utility services like water and gas. Future revisions of

– 8 – 62055-52 © IEC:2008(E)
the STS may allow for other token carrier technologies like smart cards and memory keys with
two-way functionality.
The STS Association has established D-type liaison with working group 15 of IEC TC 13 for
the development of standards within the scope of the STS, and is thus responsible for the
maintenance of any such IEC standards that might be developed as a result of this liaison.
The STS Association is also registered with the IEC as a Registration Authority for providing
maintenance services in support of the STS (see Clause C.1 of IEC 62055-41 for more
information).
62055-52 © IEC:2008(E) – 9 –
ELECTRICITY METERING –
PAYMENT SYSTEMS –
Part 52: Standard transfer specification (STS) –
Physical layer protocol for a two-way virtual token carrier
for direct local connection
1 Scope
This part of IEC 62055 specifies a physical layer protocol of the STS for transferring units of
credit and other management information between a client (typically a HHU) and a server (an
STS-compliant electricity payment meter), typically over a direct local connection. It is
complementary to the application layer protocol specified in IEC 62055-41 and should be
used in conjunction with that standard.
This standard is not applicable to payment metering systems employing monetary-based
tokens, complex tariffs and currency-mode accounting functions. It is only intended to support
the STS functionality as defined in IEC 62055-41 and it does not support the additional
functionality required for extended use that includes monetary-based tokens and complex
meter functions such as tariffs, real time clocks and currency-mode accounting. If such
extended use were required in the future, then it would need new work on this part of
IEC 62055 as well as on IEC 62055-41.
It is intended for use across a range of payment meters developed by different manufacturers
and to ensure compatibility between these products and other client devices.
It specifies a client/server communications protocol that:
• transfers STS-compliant tokens from a client device to a payment meter server;
• reads the result from the payment meter after transfer and execution of the token;
• transfers management data from the client device to the payment meter server;
• reads management data from the payment meter server and transfers same to the client
device.
NOTE Although developed for payment systems for electricity, this standard can also be applied to other utility
services, such as water and gas.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
IEC 60050-300, International Electrotechnical Vocabulary – Electrical and electronic
measurements and measuring instruments – Part 311: General terms relating to
measurements – Part 312: General terms relating to electrical measurements – Part 313:
Types of electrical measuring instruments – Part 314: Specific terms according to the type of
instrument
IEC 62051:1999, Electricity metering – Glossary of terms
IEC TR 62055-21:2005, Electricity metering – Payment systems – Part 21: Framework for
standardization
– 10 – 62055-52 © IEC:2008(E)
IEC 62055-31:2005, Electricity metering – Payment systems – Part 31: Particular
requirements – Static payment meters for active energy (classes 1 and 2)
IEC 62055-41, Electricity metering – Payment systems – Part 41: Standard transfer
specification – Application layer protocol for one-way token carrier systems
IEC 62055-51, Electricity metering – Payment systems Part 51: Standard transfer
specification – Physical layer protocol for one-way numeric and magnetic card token carriers
IEC 62056-21:2002, Electricity metering – Data exchange for meter reading, tariff and load
control – Part 21: Direct local data exchange
ISO/IEC 646:1991, Information technology – ISO 7-bit coded character set for information
interchange
STS 101-1, Standard transfer specification (STS) – Interface specification – Physical layer
mechanical and electrical interface for virtual token carriers
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 60050-300,
IEC 62051, IEC 62055-31, IEC 62055-41 apply.
The term ASCII is used throughout the standard, which shall mean the 7-bit coded character
set as defined in ISO/IEC 646.
3.2 Abbreviations
ACK Acknowledge (ASCII code)
APDU ApplicationProtocolDataUnit
ASCII American Standard Code for Information Interchange
BCC Block Check Character
Char Character
CR Carriage Return (ASCII code)
DL Data Length
ETX End Of Text (ASCII code)
FOIN FunctionObjectIdentificationNumber
GPRS General Packet Radio Service
GSM Global System For Mobile Communication
hex hexadecimal
HHU Hand Held Unit
—————————
To be published
62055-52 © IEC:2008(E) – 11 –
ID Identification, Identifier
ISDN Integrated Services Digital Network
ISO International Standards Organisation
LAN Local Area Network
LF Line Feed (ASCII code)
ms milli-second
NAK Negative AcKnowledge (ASCII code)
OSI Open Systems Interconnect
PLC Power Line Carrier
POS PointOfSale
PSTN Public Switched Telephone Network
Ref Reference clause
RID Register IDentifier code
SOH Start Of Header (ASCII code)
STS Standard Transfer Specification
STX Start Of Text (ASCII code)
TCDU TokenCarrierDataUnit
VTC07 VirtualTokenCarrierType07
WAN Wide Area Network
3.3 Notation and terminology
Throughout this standard, the following rules are observed regarding the naming of terms:
• entity names, data element names, function names and process names are treated as
generic object classes and are given names in terms of phrases in which the words are
capitalized and joined without spaces. Examples are: SupplyGroupCode as a data element
name, TokenLockout as a function name and TransferCredit as a process name (see
Note);
• direct (specific) reference to a named class of object uses the capitalized form, while
general (non-specific) reference uses the conventional text, i.e. lower case form with
spaces. An example of a direct reference is: “The SupplyGroupCode is linked to a group of
meters”, while an example of a general reference is: “A supply group code links to a
vending key”;
• attribute names of an object class uses the same convention as for the name of an object
class, except that the first letter is in lower case format;
• object class names are capitalized, while names of attributes of a object class start with
lower case;
• other terms use the generally accepted abbreviated forms like PSTN for Public Switched
Telephone Network.
NOTE The notation used for naming of objects has been aligned with the so called “camel-notation” used in the
common information model (CIM) standards prepared by TC 57, in order to facilitate future harmonization and
integration of payment system standards with the CIM standards.

– 12 – 62055-52 © IEC:2008(E)
3.4 Numbering conventions
In this standard, the representation of numbers in binary strings uses the convention that the
least significant bit is to the right, and the most significant bit is to the left.
Numbering of bit positions start with bit position 0, which corresponds to the least significant
bit of a binary number.
Numbers are generally in decimal format, unless otherwise indicated. Any digit without an
indicator signifies decimal format.
Binary digit values range from 0-1.
Decimal digit values range from 0-9.
Hexadecimal digit values range from 0-9, A-F and are indicated by “hex”.
4 STS protocol reference model

POS METER
Meter Function
Application Application
Objects
Process Process
Companion
Specifications
Key Management
APDU APDU
Application Layer Application Layer
Protocol Protocol
6.1
TCDU TCDU
Physical Layer Physical Layer
6.2
Protocol Protocol
to
6.8
Token Carrier
POS to Token Token Carrier to
IEC  594/08
Carrier Interface Meter Interface

Key:
APDU ApplicationLayerDataUnit; data interface to the application layer protocol
TCDU TokenCarrierDataUnit; data interface to the physical layer protocol
Relevant clause number references in this standard are indicated adjacent to each box

Figure 1 – Physical layers of the STS protocol stack
The STS is a secure data transfer protocol between a POS and a payment meter using a
token carrier as the transfer medium. The application layer protocol deals with tokens,
encryption processes and functions and is specified in IEC 62055-41, while the physical layer
protocol deals with the actual encoding of the token data onto various types of token carriers.
IEC 62055-52
IEC 62055-41
IEC 62055-41
IEC 62055-52
62055-52 © IEC:2008(E) – 13 –
This part of IEC 62055 specifies a physical layer protocol that deals with the actual encoding
of the token data onto a virtual token carrier comprising of a direct local connection between a
client and a server (payment meter) using a serial communications protocol, and operates in
conjunction with the application layer protocol specified in IEC 62055-41(see Figure 1).
Examples of other types of virtual token carriers are: PSTN modem, ISDN modem, GSM
modem, GPRS modem, Radio modem, PLC modem, Infra-red, LAN and WAN connections
and direct local connection, which might be specified in the future in other parts of the
IEC 62055-5x series.
A more complete description of the STS reference model and data flows from the
POSApplicationProcess to the MeterApplicationProcess may be found in Clause 5 of
IEC 62055-41.
The protocol defines a generic write and read message structure that allows for a client to
read data from or write data to a payment meter by reference to a virtual register table as a
logical interface to actual registers or functions. This standard defines a RegisterTable
interface class (see 6.8.1) and a Register interface class (see 6.8.2) for a
MeterFunctionObject, which gets defined in a companion specification. Companion
specifications are not normative to IEC 62055-52 and are administered by the STS
Association (see 6.9).
5 POSToTokenCarrierInterface: Physical layer protocol
The client interface to the virtual token carrier is not defined in detail in this standard, but it
shall generally complement the requirements given in the relevant parts of Clause 6.
In practice, the client device is typically a mobile HHU that connects to the payment meter by
means of a direct local connection, but it is also possible for the connection to be extended to
a remote management system by means of suitable interposing modem devices linked over
any appropriate communications medium. Such extended remote connection is not
specifically covered in this standard, but in essence it simply means an extension of the
physical medium.
6 TokenCarrierToMeterInterface: Physical layer protocol
6.1 TCDU
6.1.1 General
The TCDU is the data interface between the physical layer protocol and the application layer
protocol and comprises the following data elements as given in Table 1.
Table 1 – Data elements in the TCDU
Element Format Reference
TokenData 66-bit binary 6.1.2
AuthenticationResult Boolean 6.1.3
ValidationResult Boolean 6.1.4
TokenResult Boolean 6.1.5
6.1.2 TokenData
This is the 66-bit binary format of the token data as decoded from the TokenCarrier. It is the
same data element as is presented to the TCDU at the POSToTokenCarrierInterface (see
6.4.3 to 6.4.5 of IEC 62055-41).

– 14 – 62055-52 © IEC:2008(E)
6.1.3 AuthenticationResult
This is a status indicator to the physical layer protocol to convey the result from the initial
authentication checks. See also 7.1.3 of IEC 62055-41 for definition of the
AuthenticationResult values.
These data elements are also included in the TokenStatus register (see 6.8.3.7) for access by
the client.
6.1.4 ValidationResult
This is a status indicator to the physical layer protocol to convey the result from the initial
validation checks. See also 7.1.4 of IEC 62055-41 for definition of the ValidationResult
values.
These data elements are also included in the TokenStatus register (see 6.8.3.7) for access by
the client.
6.1.5 TokenResult
This is a status indicator from the MeterApplicationProcess to convey the result after
processing the Token so that the physical layer protocol can take the appropriate action. See
also 7.1.5 of IEC 62055-41 for the definition of the TokenResult values.
These data elements are also included in the TokenStatus register (see 6.8.3.7) for access by
the client.
6.2 Physical connection and signal interfaces
6.2.1 Interface options
The payment meter manufacturer may implement any of the options given in 6.2.2 to 6.2.4,
but the actual implementation shall be agreed between the manufacturer and the utility.
Further options may be given in future revisions to this standard.
6.2.2 Option 1: Optical interface
The physical connection and signal interfaces shall comply with the requirements given in 4.3
of IEC 62056-21.
6.2.3 Option 2: Current loop interface
The physical connection and signal interfaces shall comply with the requirements given in 4.1
of IEC 62056-21.
6.2.4 Option 3: Voltage interface
The physical connection and signal interfaces shall comply with the requirements given in
STS 101-1.
6.3 Character transmission
6.3.1 Transmission type
Asynchronous serial transmission - half duplex.

62055-52 © IEC:2008(E) – 15 –
6.3.2 Transmission format
Start Data data Data Data Data Data Data Parity Stop
bit bit bit bit bit bit bit bit bit bit

0 1 2 3 4 5 6
Bit transmission sequence
Time
IEC  595/08
Figure 2 – Character transmission format
The character transmission format comprises 1 start bit, 7 data bits, 1 even parity bit, and 1
stop bit, as shown in Figure 2.
The bit-encoding of the 7-bit ASCII character is given in Table 2.
Table 2 – Bit-encoding of a 7-bit character code
Bit Value Context
Start bit 0 Signifies the start of a character serial bit stream
Data bit 0 0 – 1 Least significant bit of the character code
Data bit 1 0 – 1 Character code
Data bit 2 0 – 1 Character code
Data bit 3 0 – 1 Character code
Data bit 4 0 – 1 Character code
Data bit 5 0 – 1 Character code
Data bit 6 0 – 1 Most significant bit of the character code
Parity bit 0 If data bits 0 to 6 contain an even number of binary 1’s
1 If data bits 0 to 6 contain an odd number of binary 1’s
Stop bit 1 Signifies the end of a character serial bit stream

6.3.3 Transmission speed
Baud rate = 2 400 bits per second.
The server shall not support Baud rate negotiation or switchover.
6.3.4 Character encoding
The format of application data is defined in specifications applicable to the particular data
element. For the purposes of this standard, all application data elements that are to be
transported over the VTC07 virtual token carrier shall be presented in binary, hexadecimal or
decimal format before character encoding.

– 16 – 62055-52 © IEC:2008(E)
Binary format data shall be encoded as follows:
Binary format data is split into 4-bit nibbles and each nibble is converted into its 7-bit ASCII
representation before transmission. The most significant nibble is transmitted first. During
reception by the client the inverse process is applied to reconstruct the data into its original
format. In the case where the data format is not a whole number of 4-bit nibbles, then the
binary number shall be right justified and padded on the left with leading binary zeros to make
a whole number of nibbles. An example is given in Table 3.
Table 3 – Character encoding example of a 14-bit binary number
Operation Result 7-bit ASCII
Binary number starting value 11001011011110
Split into 4-bit nibbles 11 0010 1101 1110
Padded on the left with zeros to make a 0011 0010 1101 1110
whole number of nibbles
st
1 nibble to convert and transmit 0011 0110011
nd
2 nibble to convert and transmit 0010 0110010
rd
3 nibble to convert and transmit 1101 1000100
th
4 nibble to convert and transmit 1110 1000101

Hexadecimal format data shall be encoded as follows:
Hexadecimal format data is split into hexadecimal digits and each digit is converted into its 7-
bit ASCII representation before transmission. The most significant digit is transmitted first.
During reception by the client the inverse process is applied to reconstruct the data into its
original format. An example is given in Table 4.
Table 4 – Character encoding example of a 4-digit hexadecimal number
Operation Result 7-bit ASCII
Hexadecimal number starting value 12AF
Split into 4 hexadecimal digits 1 2 A F
st
1 digit to convert and transmit 1 0110001
nd
2 digit to convert and transmit 2 0110010
rd
3 digit to convert and transmit A 1000001
th
4 digit to convert and transmit F 1000110

Decimal format data shall be encoded as follows:
Decimal format data is split into decimal digits and each digit is converted into its 7-bit ASCII
representation before transmission. The most significant digit is transmitted first. During
reception by the client the inverse process is applied to reconstruct the data into its original
format. An example is given in Table 5.

62055-52 © IEC:2008(E) – 17 –
Table 5 – Character encoding example of a 4-digit decimal number
Operation Result 7-bit ASCII
Decimal number starting value 3059
Split into 4 decimal digits 3 0 5 9
st
1 digit to convert and transmit 3 0110011
nd
2 digit to convert and transmit 0 0110000
rd
3 digit to convert and transmit 5 0110101
th
4 digit to convert and transmit 9 0111001

6.4 Message syntax definitions
6.4.1 General
The various messages supported are given below. Reference numbers below each field refer
to the listing in 6.5, defining the detailed definition for each field.
Each field represents one or more 7-bit ASCII characters after encoding of the data
(see 6.3.4).
6.4.2 IDRequest message
The client sends the IDRequest message to request the server to produce identification
information that will help the client determine which server type it is dealing with. This is
normally the first message the server receives in a communication session.
/ ? ! CR LF
(1) (2) (3) (4) (5)
See also 6.6.2 for more information on the processing of this message.
6.4.3 IDResponse message
The server sends the IDResponse message to the client in response to receiving the
IDRequest message from the client. The server identifies its payment meter type by sending
the manufacturer code and software version code of the server.
/ M X V CR LF
(1) (22) (6) (7) (4) (5)
See also 6.6.2 for more information on the processing of this message.
6.4.4 ReadCommand message
The client reads a dataset from a particular Register (see 6.8.2) in the payment meter by
sending a ReadCommand to the server.
SOH R STX RID DL ETX BCC
(8) (9) (10) (11) (12) (13) (14)

NOTE BCC is calculated on fields (9) to (13).
See also 6.6.3 for more information on the processing of this message.

– 18 – 62055-52 © IEC:2008(E)
6.4.5 WriteCommand message
The client writes a dataset to a particular Register (see 6.8.2) in the payment meter by
sending a WriteCommand to the server.
SOH W STX RID ( D ) ETX BCC
(8) (15) (10) (11) (16) (17) (18) (13) (14)

NOTE BCC is calculated on fields (15) to (13)
See also 6.6.4 for more information on the processing of this message.
6.4.6 BreakCommand message
The client cancels all previous messages that have not yet
...