ISO/IEC 24730-1:2014

Information technology — Real-time locating systems (RTLS) — Part 1: Application programming interface (API)

ISO/IEC 24730-1:2014 enables software applications to utilize a real-time locating system (RTLS) infrastructure to locate assets with RTLS transmitters attached to them. It defines a boundary across which application software uses facilities of programming languages to collect information contained in RTLS tag blinks received by the RTLS infrastructure.

Technologies de l'information — Systèmes de localisation en temps réel (RTLS) — Partie 1: Interface de programmation d'application (API)

General Information

• Status: Published
• Publication Date: 09-Feb-2014
• ICS: 35.040 - Information coding
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31/WG 4 - Radio communications
• Current Stage: 9093 - International Standard confirmed
• Completion Date: 01-Apr-2020

Relations

• Revises: ISO/IEC 24730-1:2006 - Information technology — Real-time locating systems (RTLS) — Part 1: Application program interface (API)
• Effective Date: 28-May-2011

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 24730-1
Second edition
2014-02-15
Information technology — Real-time
locating systems (RTLS) —
Part 1:
Application programming interface
(API)
Technologies de l’information — Systèmes de localisation en temps
réel (RTLS) —
Partie 1: Interface de programmation d’application (API)
Reference number
ISO/IEC 24730-1:2014(E)
©
ISO/IEC 2014

---------------------- Page: 1 ----------------------
ISO/IEC 24730-1:2014(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2014 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 24730-1:2014(E)

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
5 The service . 2
5.1 Purpose . 2
5.2 Specification summary . 3
5.3 Message stream configuration . 4
5.4 Security . 4
5.5 Purpose . 4
5.6 Language independence . 4
5.7 Architecture . 4
5.8 SLMP messages . 4
5.9 Simple Location Message Format over HTTP .13
Bibliography .17
© ISO/IEC 2014 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 24730-1:2014(E)

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 24730-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
This second edition cancels and replaces the first edition (ISO/IEC 24730-1:2006), which has been
technically revised.
ISO/IEC 24730 consists of the following parts, under the general title Information technology — Real time
locating systems (RTLS):
— Part 1: Application programming interface (API)
— Part 2: Direct Sequence Spread Spectrum (DSSS) 2,4 GHz air interface protocol
— Part 21: Direct Sequence Spread Spectrum (DSSS) 2,4 GHz air interface protocol: Transmitters operating
with a single spread code and employing a DBPSK data encoding and BPSK spreading scheme
— Part 22: Direct Sequence Spread Spectrum (DSSS) 2,4 GHz air interface protocol: Transmitters operating
with multiple spread codes and employing a QPSK data encoding and Walsh offset QPSK (WOQPSK)
spreading scheme
— Part 5: Chirp spread spectrum (CSS) at 2,4 GHz air interface
— Part 61: Low rate pulse repetition frequency Ultra Wide Band (UWB) air interface
— Part 62: High rate pulse repetition frequency Ultra Wide Band (UWB) air interface
iv © ISO/IEC 2014 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 24730-1:2014(E)

Introduction
ISO/IEC 24730 defines several air interface protocols and a single Application Programming Interface
(API) for Real Time Locating Systems (RTLS) for use in asset management and is intended to allow for
compatibility and to encourage interoperability of products for the growing RTLS market.
This part of ISO/IEC 24730, the RTLS Application Programming Interface, establishes a technical
standard for Real Time Locating Systems. To be fully compliant with ISO/IEC 24730, Real Time Locating
Systems (RTLS) shall comply with this part of ISO/IEC 24730 and at least one air interface protocol
defined in ISO/IEC 24730.
Real Time Locating Systems are wireless systems with the ability to locate the position of an item
anywhere in a defined space (local/campus, wide area/regional, global) at a point in time that is, or is
close to, real time. Position is derived by measurements of the physical properties of the radio link.
Conceptually there are four classifications of RTLS:
— Locating an asset via satellite - requires line-of-sight - accuracy to 10 meters
— Locating an asset in a controlled area, e.g., warehouse, campus, airport - area of interest is
instrumented - accuracy to 3 meters
— Locating an asset in a more confined area - area of interest is instrumented - accuracy to tens of
centimetres
— Locating an asset over a terrestrial area using terrestrial mounted receivers over a wide area, cell
phone towers for example – accuracy 200 meters
With a further two methods of locating an object which are really RFID rather than RTLS:
— Locating an asset by virtue of the fact that the asset has passed point A at a certain time and has not
passed point B
— Locating an asset by virtue of providing a homing signal whereby a person with a handheld can find
an asset
Method of location is through identification and location, generally through multi-lateration, of various
types
— Time of Flight Ranging Systems
— Amplitude Triangulation
— Time Difference of Arrival (TDOA)
— Cellular Triangulation
— Satellite Multi-lateration
— Angle of Arrival
The location information of an asset may further be enhanced with information on its spatial orientation.
This part of ISO/IEC 24730 defines an application programming interface (API) needed for utilizing an
RTLS system.
An API is a boundary across which application software uses facilities of programming languages to
invoke services. These facilities may include procedures or operations, shared data objects and resolution
of identifiers. A wide range of services may be required at an API to support applications. Different
methods may be appropriate for documenting API specifications for different types of services.
© ISO/IEC 2014 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 24730-1:2014(E)

The information flow across the API boundary is defined by the syntax and semantics of a particular
programming language, such that the user of that language may access the services provided by the
application platform on the other side of the boundary. This implies the specification of a mapping of
the functions being made available by the application platform into the syntax and semantics of the
programming language. An API specification documents a service and/or service access method that is
available at an interface between the application and an application platform.
This API describes the RTLS service and its access methods, to enable client applications to interface
with the RTLS system. This RTLS service is the minimum service that shall be provided by a RTLS
system to be API compatible with this standard.
This part of ISO/IEC 24730 uses a “full stop” as the decimal point separator since an API file is being
created with an output in a .csv file format which uses the comma to separate values.
vi © ISO/IEC 2014 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 24730-1:2014(E)
Information technology — Real-time locating systems
(RTLS) —
Part 1:
Application programming interface (API)
1 Scope
This part of ISO/IEC 24730 enables software applications to utilize an RTLS infrastructure to locate
assets with RTLS transmitters attached to them. It defines a boundary across which application software
uses facilities of programming languages to collect information contained in RTLS tag blinks received
by the RTLS infrastructure.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 15963, Information technology — Radio frequency identification for item management — Unique
identification for RF tags
ISO/IEC 19762 (all parts), Information technology — Automatic identification and data capture (AIDC)
techniques — Harmonized vocabulary
IEEE Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48™)
IEEE Guidelines for 64-bit Global Identifier (EUI-64™) Registration Authority
Extensible Markup Language (XML) 1.0, (Third Edition), W3C Recommendation, World Wide Web
1)
Consortium (W3C), 4 February 2004
SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C Recommendation, World Wide Web
2)
Consortium (W3C), 27 April 2007
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 (all parts), and the
following apply
3.1
field
element of a data record in which information is stored, which may contain one or more properties of a
tag blink
3.2
XML tag
marker that qualifies content in a XML document
1) http://www.w3.org/TR/REC-xml/
2) http://www.w3.org/TR/2007/REC-soap12-part1-20070427/
© ISO/IEC 2014 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC 24730-1:2014(E)

3.3
persistent connection
network connection between a server and a client that is kept open for several application level message
exchanges, or request call, even after sending application level error responses
3.4
tag status
mandatory fields within a Locate message not including the and fields
4 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviated terms given in ISO/IEC 19762 (all parts)
and the following apply.
API Application Programming Interface
ASCII American Standard Code for Information Interchange
CR ASCII Carriage Return
EUI Extended Unique Identifier
JMS Java Messaging Service
HTTP HyperText Transfer Protocol
HTTPS HTTP Secure Protocol
LF ASCII Line Feed
OUI Organizationally Unique Identifier
REST Representational State Transfer
RTLS Real Time Locating System
S-HTTP Secure HTTP Protocol
SLMF Simple Location Message Format
SLMP Simple Location Message Protocol
SOAP Simple Object Access Protocol
SSL Secure Sockets Layer
TDOA Time Difference Of Arrival
TCP/IP Transmission Control Protocol / Internet Protocol
XML eXtensible Markup Language
XSD XML Schema Definition
5 The service
5.1 Purpose
The purpose of the RTLS software API is to provide a simple minimal interface that facilitates adoption
and can be implemented easily on both the RTLS system and the application. The purpose is also to
2 © ISO/IEC 2014 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 24730-1:2014(E)

allow fast transfer of messages to any client that connects to the RTLS system. In addition, the message
flow should be human-readable and easy to interpret.
The API is to be supported by a device of minimal functionality, which is a ‘collection and forwarding
device’, with no persistency or database required.
The device can provide rate filtering and location smoothing capabilities, but these functions are not
required by the proposed API because the API can operate before or after this type of pre-processing.
5.2 Specification summary
The RTLS software service shall be a ‘Text over Socket’ connection, such that a TCP/IP client can connect
and receive a real-time stream of RTLS messages.
The messages are separated by to facilitate console display. The field format is comma-
separated.
The ‘Text over Socket’ protocol is the minimal mandatory compliance. If additional transport protocols
3)
are implemented such as HTTP and JMS, then either Text or XML formats shall be used. If REST or
4)
SOAP is implemented, then an XML format is used. The Text format includes comma-separated fields,
while the XML format includes ‘abbreviated’ XML tags. Both formats are described within this part of
ISO/IEC 24730.
REST, SOAP and higher functionality services are not mandatory because they tend to limit the message
rate.
A goal of this part of ISO/IEC 24730 is to easily support 3,000 messages per second or more. Although in
many applications a rate of 3,000 messages per second may not be needed, the RTLS minimal API shall
support it because an actual tag deployment with 3,000 tags blinking at 1 Hz may easily produce that
message rate. When rate filtering is involved, and/or the IT systems and software are tuned to handle
high rates, REST, SOAP and other transports may provide additional functionality. As indicated, the
comma-separated Text format shall be considered when supporting high data rates because the format
is non-verbose and allows transports to operate at medium to high rates.
This API or protocol is referred to as ‘Simple Location Message Protocol’, or ‘SLMP’. The mandatory
comma-separated format is referred to as ‘Simple Location Message Format’, or ‘SLMF’. For specific
transports, ‘SLMF-Sockets’ is the TCP/IP compatible mandatory interface/API of SLMP, while, for
example, SLMF-HTTP is an optional interface/API when supporting HTTP as a simple RTLS REST service.
As indicated above, an SLMP implementation may optionally include an XML format.
A client application connects to the RTLS using a TCP/IP connection. The RTLS system responds with a
stream of messages that stops only when the client connection is closed.
The RTLS system shall send keep-alive massages if the line is silent for long periods of time. This part
of ISO/IEC 24730 does not prescribe a particular keep-alive interval, but rather leaves this decision to
the RTLS system vendor (see clause 5.7.3). The Client App shall attempt a reconnect periodically if the
Socket connection to the RTLS system is lost.
The RTLS system provides the API via a minimal device that collects message from readers, calculates
locations, and forwards messages. This device is not required to have persistency and does not need
to keep historical data or state of last tag during the active session. Thus, this API does not provide
tag status, but rather only tag events. Tag status is left to the application to handle in the context of a
business aware database, or for a higher level API not in this scope.
The API herein defined shall support multiple concurrent client connections.
3) Extensible Markup Language (XML) 1.0, (Third Edition), W3C Recommendation, World Wide Web Consortium
(W3C), 4 February 2004. (http://www.w3.org/TR/REC-xml/)
4) SOAP Version 1.2 Part0: Primer, W3C Recommendation, World Wide Web Consortium (W3C), 24 June 2003,
(http://www.w3.org/TR/2003/REC-soap12-part0-20030624/)
© ISO/IEC 2014 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC 24730-1:2014(E)

5.3 Message stream configuration
This part of ISO/IEC 24730 does not prescribe specific methods for filtering the output message stream
produced by the RTLS system; however, an RTLS system vendor may implement filtering on a data
collection and forwarding device if desired while still complying with this part of ISO/IEC 24730. For
example, the vendor could implement a client-side subscription method that passes filter definitions to
the RTLS system. The RTLS system could then use the filter definitions to limit message stream output
to clients. Alternatively, a vendor could implement server-side configuration of filter definitions that
apply to all client connections.
5.4 Security
Security protocols regarding RTLS message exchange are intentionally excluded from this part of
ISO/IEC 24730 because security can be addressed using existing security standards and technologies
at the communication layer based on preferences and policies of individual customers. For example, in
the case of a TCP/IP connection SSH is a security protocol that is easy to implement and is considered
compliant with this standard. Likewise, security protocols such as HTTPS and S-HTTP are security
protocols that may be implemented on top of this part of ISO/IEC 24730.
5.5 Purpose
The API herein defined provides a standard mechanism for client application to access location-enriched
tag blinks from an RTLS system.
5.6 Language independence
The API herein defined specifies a software language-independent interface to the RTLS Service. It
does so by using an industry standard protocol, Text over Socket (TCP/IP), to communicate to the RTLS
service.
5.7 Architecture
Figure 1 describes the API message exchanges between a client application and the RTLS System. The
24730-1 API shall allow multiple client connections, thus it keeps TCP/IP connection state per client.
Figure 1 — Architecture of SLMP
5.8 SLMP messages
This clause describes messages that are used within this part of ISO/IEC 24730. Each message type
includes a set of fields, which the RTLS vendor shall implement in accordance with the definitions provided
herein. All field values and XML tag names that are explicitly defined in this part of ISO/IEC 24730 are
case sensitive.
4 © ISO/IEC 2014 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 24730-1:2014(E)

5.8.1 Data types
Data types described in this clause pertain to fields that are associated with messages defined within
this part of ISO/IEC 24730. For the Locate message, an RTLS vendor may optionally include extension
fields that are not described within this part of ISO/IEC 24730. For such fields, the vendor may choose
data types of their choice.
DateTime
This data type represents a date time format as defined in ISO 8601: YYYY-MM-DDThh:mm:ss-hh:mm
Year in the form YYYY-MM-DD
Month in the form YYYY-MM-DD
Day in the form YYYY-MM-DD
T indicates “Time will follow”
Hours in the form hh:mm:ss
Minutes hh:mm:ss
Seconds hh:mm:ss
Plus or minus UTC offset in hours and minutes (-hh:mm or +hh:mm)
Example: 2010-11-24T09:07:04-08:00  //for PST time zone
Note that a fraction with up to one-tenth millisecond (.0001 seconds) accuracy may be added to the
lowest order time element in the representation. For example, to denote “14 hours, 30, minutes, and
12.359 seconds”, represent it as “14:30:12.359”.
Double
This data type represents a floating-point format that includes an encoded optional decimal point, and
may be expressed with or without the exponent and mantissa. Examples include: 2345.334, -98.7, 1.0,
4, 0.0, 0.5, 9.87+E8.
The range for a field of type ‘Double’ is 1.7E–308 to 1.7E+308, and the maximum string length is 256
characters.
HexBinary
This data type represents structured or unstructured data that can be expressed in hexadecimal format,
where each byte is a binary octet. The high order nibble is expressed as the first (leftmost) nibble within
an octet, and each HexBinary string shall contain an even number of nibbles.
The maximum field length for a field of type ‘HexBinary’ is 256 bytes.
Integer
This data type represents numbers that can be written without a fractional or decimal component, and
fall within the set {., −2, −1, 0, 1, 2, .}.
The range for a field of type ‘Integer’ is − 2,147,483,648 to 2,147,483,647.
String
This data type represents a set of ASCII characters, limited to the following characters:
A, B, C, D, E, F, G, H, I, J, K, L, M, N ,O, P, Q, R, S, T, U, V, W, X, Y, Z, a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t,
u, v, w, x, y, z, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, space, !, (, ), [, ], *, #, $, %, &, +, -, _, ., /, ?, =
The maximum field length for a field of type ‘String’ is 256 characters.
© ISO/IEC 2014 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO/IEC 24730-1:2014(E)

5.8.2 Header Message
The RTLS system sends a single Header message when a client application establishes a connection to it.
Fields Sequence:
,SLMF,,,
Fields:
Appliance_ID (Mandatory)
XML Tag:
Data Type: String
Restriction: 1 to 10 characters
Represents the RTLS system or appliance that produces the Locate messages.
SLMF_version (Mandatory)
XML Tag:
Data Type: String
Restriction: 1 to 10 characters
Version of the SLMF implementation, assigned by this part of ISO/IEC 24730. The SLMF version for this
version of this part of ISO/IEC 24730 is 1.0.
SLMF_vendor_version (Mandatory)
XML Tag:
Data Type: String
Restriction: 1 to 10 characters
Vendor version of the SLMF implementation, which is used when a vendor provides one or more non-
default formats associated with Locate messages. If vendor version is not used, this field shall remain
empty.
Greeting (Mandatory)
XML Tag:
Data Type: String
Restriction: 1 to 256 characters
Message is defined by the RTLS vendor, which can represent a greeting.
Example:
MyAppl,SLMF,1.0,1.3,Welcome to the RTLS Text Stream interface.
5.8.3 Field Definition Message
Field Definition messages are sent immediately after the Header message and represent fields that are
used within Locate messages sent by the RTLS system. Locate messages include mandatory and optional
fields with definitions that shall be adhered to when these fields are implemented by the RTLS system
vendor.
Fields Sequence:
6 © ISO/IEC 2014 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC 24730-1:2014(E)

FieldDefinition,,
Fields:
Name (Required)
XML Tag:
Data Type: String
Restriction: 1 to 256 characters
The name of the data field that is associated with one or more Locate messages. If the field is explicitly
defined within clause 5.8, then the value for within the Field Definition message shall match
the name of the field defined within clause 5.8. When XML is used, the field name shall match the XML
tag specified within clause 5.8.
Type (Required)
XML Tag:
Data Type: String
Restriction: 1 to 256 characters
The data type associated with the field. If the field is defined within clause 5.8, then the value for
within the Field Definition message shall match the data type associated with the related field
within clause 5.8.
Example:
FieldDefinition,Source,String
5.8.4 Locate Message Definition Message
Locate Message Definition messages are sent immediately after the Field Definition messages. One
Locate Message Definition message shall be defined for each unique , pair.
Fields Sequence:
LocateMessageDefinition,,,,,,…
Fields:
Source
XML Tag:
Data Type: String
Restriction: 1 to 64 characters
Field Definition:  FieldDefinition,Source,String
Source typically represents a particular location technology or product line. For example, if an RTLS
system produces Locate messages that are derived from Product Line A and Product Line B, the RTLS
system vendor may specify a source value for each of the two product lines. Source values are defined by
RTLS system vendors; however, the RTLS system vendor may provide a method that allows customers to
optionally map alternative source values of their choice. This part of ISO/IEC 24730 does not prescribe a
specific source value mapping method; this is left to each RTLS system vendor to decide.
© ISO/IEC 2014 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO/IEC 24730-1:2014(E)

Format (Mandatory)
XML Tag:
Data Type: String
Restriction: 1 to 64 characters
Field Definition:  FieldDefinition,Format,String
Format represents the set of fields contained in the Locate message. If a Locate message contains non-
mandatory fields, the format and source field combination shall be used by the client application to
determine how to parse the message; otherwise, the Format value shall be “DFT” indicating that only
mandatory fields are contained within the Locate message. Format values other than “DFT” are defined
by RTLS system vendors.
Field Names (Mandatory)
See clause 5.8.6 for names of fields that pertain to Locate messages. An RTLS vendor may specify their
own field names for extension fields that are not explicitly defined within clause 5.8.6.
LocateMessageDefinition,,,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp,Ext1,E
xt2, Ext3,…
Examples:
LocateMessageDefinition,MySourceA,DFT,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp
LocateMessageDefinition,MySourceB,DFT,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp
LocateMessageDefinition,MySourceB,S,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp,Algorithm >
LocateMessageDefinition,MySourceB,T,Tag_ID_Format,Tag_ID,X,Y,Z,Battery,Timestamp,Data
5.8.5 Keep-Alive Message
The RTLS system may optionally include configuration that causes a keep-alive message to be sent if the
elapsed time since the previous Locate message exceeds a specified duration. The Keep-Alive message
is also sent each time the API client establishes a connection with the RTLS system.
Fields Sequence:
KeepAlive,
Fields:
Period (Required)
XML Tag:
Data Type: Integer
Restriction: 1 to 3600 characters
Time duration, in seconds, that triggers a Keep-Alive message when the line is silent. This value is set
within the RTLS system.
Example:
KeepAlive,60
8 © ISO/IEC 2014 – All rights reserved

---------------------- Page: 14 ----------------------
ISO/IEC 24730-1:2014(E)

5.8.6 Locate Message
An RTLS tag event is typically expressed as a Locate message containing mandatory fields, plus any
number of optional fields that are also referred to as “extensions”. RTLS system vendors
...