ISO/TS 21219-16:2016

TECHNICAL ISO/TS
SPECIFICATION 21219-16
First edition
2016-09-01
Intelligent transport systems — Traffic
and travel information via transport
protocol exports group, generation 2
(TPEG2) —
Part 16:
Fuel price information and availability
(TPEG2-FPI)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 16: Disponibilité et informations sur le prix du carburant
(TPEG2-FPI)
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 2
5 Application specific constraints . 3
5.1 Application identification . 3
5.2 Version number signalling . 3
5.3 Ordered Components . 3
5.4 Extension . 4
5.5 TPEG Service Component Frame. 4
6 FPI Structure . 4
6.1 General . 4
6.2 FPI Structuring concepts . 4
6.2.1 Design . 4
6.2.2 Factoring out definitions . 5
6.2.3 Transmission of tables of information . 6
6.2.4 MMC usage and FPI message combinations. 7
6.3 FPI Message structure . 9
6.3.1 General. 9
6.3.2 FuelingDefinitions .11
6.3.3 StationFuelingInformation .12
6.3.4 Station Extra Information .13
6.3.5 Station Site Information .14
6.3.6 Station Location Information .14
7 FPI Message components .16
7.1 FPIMessage.16
7.2 FPIapplicationContainerTemplate .17
7.3 FuelingDefinitions .17
7.4 MessageManagement .18
7.5 StationExtraInfoCluster .18
7.6 StationExtraInformation .19
7.7 StationFuelingInfoCluster .20
7.8 StationMapLocationCluster .21
7.9 StationNavLocationAlongRoadCluster .21
7.10 StationPOILocationCluster .22
7.11 StationSiteInfo .22
7.12 StationSiteInfoCluster .23
7.13 GeographicCoverageLocation .24
7.14 MessageManagementContainerLink.24
7.15 MMCMasterMessageLink .24
7.16 MMCMessagePartLink .24
7.17 StationEntryLocation .24
7.18 StationMapLocation.24
7.19 RoadLocation .24
7.20 StationExitLocation .24
8 FPI Datatypes .25
8.1 FuelDeliveryRestrictionType .25
8.2 FuelTypeInformation.25
8.3 FuelTypePrice .25
8.4 StationContactInformation .26
8.5 POILinkType .26
8.6 SizeRestrictions .26
8.7 StationBrandAndRating .27
8.8 StationFuelingInformation .27
8.9 StationMapLocationInfo .28
8.10 StationLocationVectorInfo .28
8.11 StationPOILocationInfo .29
8.12 WGS84coordinate .29
9 FPI Tables .30
9.1 Introduction of FPI Tables .30
9.2 fpi001:DeliveryUnitType .30
9.3 fpi003:FuelKindType .30
9.4 fpi004:PaymentMethodType .31
9.5 fpi005:FuelServicePolicyType .32
9.6 fpi006:AssociatedServiceType .32
9.7 fpi007:SpatialResolution .32
9.8 fpi008:FuelBrand .33
9.9 fpi009:AltFuelBrand .38
Annex A (normative) TPEG application, TPEG-Binary Representation .39
Annex B (normative) TPEG application, TPEG-ML Representation .52
Bibliography .62
iv © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2):
— Part 1: Introduction, numbering and versions [Technical Specification]
— Part 2: UML modelling rules [Technical Specification]
— Part 3: UML to binary conversion rules [Technical Specification]
— Part 4: UML to XML conversion rules [Technical Specification]
— Part 5: Service framework [Technical Specification]
— Part 6: Message management container [Technical Specification]
— Part 9: Service and network information [Technical Specification]
— Part 10: Conditional access information [Technical Specification]
— Part 14: Parking information [Technical Specification]
— Part 15: Traffic event compact [Technical Specification]
— Part 16: Fuel price information and availability application [Technical Specification]
— Part 18: Traffic flow and prediction application [Technical Specification]
— Part 19: Weather information [Technical Specification]
— The following Parts are planned:
— Part 7: Location referencing container [Technical Specification]
— Part 11: Universal location reference [Technical Specification]
— Part 21: Geographic location referencing [Technical Specification]
— Part 22: OpenLR location referencing [Technical Specification]
— Part 23: Road and multimodal routes application [Technical Specification]
— Part 24: Light encryption [Technical Specification]
— Part 25: Electromobility information [Technical Specification]
vi © ISO 2016 – All rights reserved

Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the Syntax,
Semantics and Framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application, for Road Traffic Messages.
Subsequently, in March 1999, CEN TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this committee continued development work.
Further parts were developed to make the initial set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the Service and Network Information
Application, used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
Public Transport Information Application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information, was
issued as ISO/TS 18234-6 to be used in association with the other applications parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former Forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
Applications Working Group.
It was about this time that the (then) new Unified Modeling Language (UML) was seen as having major
advantages for the development of new TPEG Applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realised
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen; especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based; this has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of rules
that contain the modelling strategy covered in ISO/TS 21219-2, ISO/TS 21219-3, ISO/TS 21219-4 and
the conversion to two current physical formats: binary and XML; others could be added in the future.
TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word
document file, to minimise drafting errors, that forms the annex for each physical format.
TPEG2 has a three container conceptual structure: Message Management (ISO/TS 21219-6), Application
(many Parts) and Location Referencing (ISO/TS 21219-7). This structure has flexible capability and can
accommodate many differing use cases that have been proposed within the TTI sector and wider for
hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the Location Referencing Container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR
(ISO/TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC
(ISO/TS 21219-6), TPEG2-LRC (ISO/TS 21219-7);
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10);
— Location referencing: TPEG2-ULR (ISO/TS 21219-11), TPEG2-GLR (ISO/TS 21219-21), TPEG2-OLR
(ISO/TS 21219-22);
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO/TS 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, whilst not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This Technical Specification is based on the TISA specification technical/editorial version reference:
SP12009/2.0/002
viii © ISO 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 21219-16:2016(E)
Intelligent transport systems — Traffic and travel
information via transport protocol exports group,
generation 2 (TPEG2) —
Part 16:
Fuel price information and availability (TPEG2-FPI)
1 Scope
This Technical Specification specifies the TPEG application: Fuel price information and availability
(FPI). The FPI application has been specifically designed to support information of fuel stations, their
location, fuel types offered and fuel pricing and availability information.
The standardized delivery, via TPEG technology, of fuel price information has the following benefits to
end users of a TPEG service:
a) cost savings to driver, through improved ease of access to price information;
b) improved ease of access to price information that may lead to significant cost savings for fleet
operators;
c) environmental benefits from drivers not having to drive around to find the cheapest fuel prices;
d) safety improvements for highways authorities, as drivers are less likely to run out of fuel if they are
well informed of local availability and prices;
e) as availability of new fuels become more common and more vehicles use them (e.g. biofuels,
hydrogen, etc.), drivers will be better informed about availability of fuelling stations.
The TPEG application Fuel price information and availability, as add-on service component next to, for
example, traffic information, is laid out to support large numbers of fuel stations and fuel prices with
only modest bandwidth requirements.
When the objective is to inform electric vehicles on the location of charging stations and the availability
of charging points, the TPEG application TPEG2-EMI (Electro Mobility Information) shall be chosen.
TPEG2-FPI contains rudimentary support for electric charging stations. However, a TISA investigation
revealed that a simple extension/differentiation of TPEG2-FPI would not be sufficient to address the
evolving market needs of the electric vehicle market. Hence, a separate TPEG application was created to
serve the information needs of Electric Vehicles and their operators: TPEG2-EMI.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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.
ISO 17572-2, Intelligent transport systems (ITS) — Location referencing for geographic databases —
Part 2: Pre-coded location references (pre-coded profile)
ISO/TS 18234-11, Intelligent transport systems — Traffic and Travel Information (TTI) via transport
protocol experts group, generation 1 (TPEG1) binary data format — Part 11: Location Referencing
Container (TPEG1-LRC)
ISO/TS 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol expert group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO/TS 21219-2, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol expert group, generation 2 (TPEG2) — Part 2: UML modelling rules
ISO/TS 21219-3, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol expert group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules
ISO/TS 21219-4, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol expert group, generation 2 (TPEG2) — Part 4: UML to XML conversion rules
ISO/TS 21219-5, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol expert group, generation 2 (TPEG2) — Part 5: Service framework (TPEG2-SFW)
ISO/TS 21219-6, Intelligent transport systems — Traffic and travel information via transport protocol
expert group, generation 2 (TPEG2) — Part 6: Message management container (TPEG2-MMC)
ISO/TS 21219-7, Intelligent transport systems — Traffic and travel information via transport protocol
expert group, generation 2 (TPEG2) — Part 7: Location referencing container (TPEG2-LRC)
ISO/TS 21219-9, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
fuel station
facility which sells fuel and lubricants for motor vehicles
Note 1 to entry: The most common fuels sold are petrol (gasoline in U.S. and Canada) or diesel fuel. Alternate
names in use for such a facility are gas station, fuelling station, filling station, service station, petrol station,
garage, gasbar, petrol pump or petrol bunk.
4 Abbreviated terms
ACID Application and Content Identifier
ADC Application Data Container
CEN Comité Européen de Normalisation
EBU European Broadcasting Union
LRC Location Reference Container
FPI Fuel price information and availability
MMC Message Management Container
POI Point of Interest
2 © ISO 2016 – All rights reserved

SFW TPEG Service Framework: Modelling and Conversion Rules
SNI Service and Network Information
TFP Traffic Flow and Prediction
TISA Traveller Information Services Association
TMC Traffic Message Channel
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modeling Language
5 Application specific constraints
5.1 Application identification
The word “application” is used in this Technical Specification to describe specific subsets of the TPEG
structure. An application defines a limited vocabulary for certain type of messages, for example,
parking information or road traffic information. Each TPEG application is assigned a unique number
called the Application IDentification (AID). An AID is defined whenever a new application is developed
and these are all listed in ISO/TS 21219-1.
The application identification number is used within the TPEG2-SNI application ISO/TS 21219-9 to
indicate how to process TPEG content and facilitates the routing of information to the appropriate
application decoder.
5.2 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions may have an impact on client devices.
The version numbering principle is defined in ISO/TS 21219-1.
Table 1 shows the current version numbers for signalling FPI within the SNI application ISO/TS 21219-9.
Table 1 — Current version numbers for signalling of FPI
Major version number 2
Minor version number 0
5.3 Ordered Components
TPEG2-FPI requires a fixed order of TPEG components. The order for the FPI message component is
shown in Figure 1; the first component shall be the Message Management Container (MMC). This shall
be the only component if the message is a cancellation message. Otherwise, the MMC component shall
be followed by one or more Application Data Container component(s) which includes the application-
specific information.
Figure 1 — Composition of TPEG messages
NB: The FPI design centres around the large commonality of information elements, notably for fuel
types, (pricing structure: currency, resolution of price information; delivery units) and the relatively
slow refresh rate of this information and the expected large volume of FPI information. To give an
example of the expected volume, in the USA, approximately 200 000 fuel stations are in operation and,
for example, in a radius of 50 km around New York City, one can find approximately 5 000 fuel stations.
Consideration of these aspects has guided the design of FPI.
Consequently, the design of the application data container is such that it can contain information for
multiple fuel stations at once. The top-level Location Referencing Container of an FPI message shall
contain a ”Geographic Coverage Area” to indicate the geographic region of interest of the message’s
content, for receiver geographic filtering purposes. The individual locations of fuel stations are
contained in specialized versions of the Application Data Container, as geographic “markers” within
this Geographic Coverage Location (see Clause 6 for details). This concept is similar as in TFP, where
congested sections of a road are indicated with linear markers with respect to a top-level linear location.
5.4 Extension
The requirement of a fixed component order does not affect the extension of FPI. Future application
extensions may insert new components or may replace existing components by new ones without
losing backward compatibility. That means, an FPI decoder shall be able to detect and skip unknown
components.
5.5 TPEG Service Component Frame
FPI makes use of the “Service Component Frame with dataCRC and messageCount” according to
ISO/TS 21219-5.
6 FPI Structure
6.1 General
In this clause, the main structure of FPI and capabilities are defined.
The FPI design centres around the large commonality of information elements, notably for fuel types,
pricing structure (currency, resolution of price information; delivery units), the relatively slow refresh
rate of this information and the expected large volume of FPI information.
6.2 FPI Structuring concepts
6.2.1 Design
In FPI, for purposes of transmission efficiency, common elements of fuel information are factored
out using standard Relational Database theory concepts (the so-called normal forms). Prominently,
this is applied for fuel type and pricing structure information (“fuelingDefinitions” in this Technical
4 © ISO 2016 – All rights reserved

Specification). Furthermore, all information is transmitted as tables of information, each under control
of a MMC component for validity and update management.
These concepts are described in the following subclauses.
6.2.2 Factoring out definitions
In general, an approach to factor out definitions is more efficient under the following conditions:
a) information is of a composite nature;
b) parts of the information are not the same worldwide (otherwise, a TPEG table would suffice) or
more than 255 options exists or are likely to exist (the cardinality of a TPEG table is limited to 255
entries);
c) the amount of duplication in the transmission otherwise needed would significantly affect
transmission efficiency.
For FPI, this applies to the fuel names, type and pricing and to fuel brands. Typically, for these data
elements, a large number of combinations exist worldwide. Moreover, over time, new types or names
may come into existence. Nonetheless, for an individual service provider, only a few combinations are
of interest.
Under these conditions, it is advantageous to transmit a separate table with fuel type and pricing
structure definitions. Information for a particular fuel station can refer to this item then with a
reference (the Table Key and Fuel Type Key) rather than duplicating the complete definition every time
a fuel station needs to list a price for a particular fuel type with a specific pricing structure.
Table 2 shows a sample from a table for a US-based service provider (e.g. for California). Here, the local
fuel names such as “Unleaded”, “Premium” or even “H ” are used. Delivery units are (US) Gallons for
liquid fuels or kg for Hydrogen, and prices are given in US Dollars with a two decimal digit accuracy [e.g.
$ 1,34 per (US) Gallon].
Table 2 — Sample table with fueling definitions for the USA
Table Key (AreaID_Key=01, fuelingDefinitionsID_Key=01)
Currency unit US Dollar
Fuel Type Key Fuel name Fuel type Delivery unit Price Resolution
0 “Unleaded” Unleaded petrol Gallon 2 digits
1 “Premium” high octane unleaded petrol Gallon 2 digits
2 “Diesel” Diesel Gallon 2 digits
3 “H “ Hydrogen kg 2 digits
4 CNG CNG gge 2 digits
In Table 2, a line item represents one fuelingDefinition. The field fuel type and delivery unit can be each
represented through a standard TPEG table construct as less than 254 variations are expected. The fuel
name is obviously represented with a short string and the price resolution with a tiny unsigned integer.
Table 3 shows a sample from a table for a Dutch-based service provider. Here, local names such as “euro-
95” and “super-98” are used. Delivery units are now in litres and prices are in Euro, with a price display
resolution of 3 digits (e.g. € 1,349 per litre).
Table 3 — Table with fuelling definitions for the Netherlands
Table Key (AreaID_Key=31, fuelingDefinitionsID_Key=1)
Currency unit Euro
Fuel Type Key Fuel name Fuel type Delivery unit Price Resolution
0 “Euro-95” Unleaded petrol Litre 3 digits
1 “Super-98” high octane unleaded petrol Litre 3 digits
2 “Diesel” Diesel Litre 3 digits
Thus, for every fuel station carrying unleaded, only the Item Key of the line item needs to be transmitted
to indicate the fuel type meant, rather than the complete definition with the four fields (fuel name, fuel
type, delivery unit, pricing resolution). With several thousand fuel prices to be transmitted in dense
urban regions, such a mechanism leads to a significant reduction in bandwidth need for a specific
repetition rate. This mechanism is used both for fuel type and pricing structure, as for (local) fuel
brands. Many fuel stations may have these information items in common.
6.2.3 Transmission of tables of information
A service provider, transmitting fuel price information and availability, needs to be able to provide
a TPEG client with a large volume of data at a relatively low transmission bandwidth. This makes it
challenging to apply the typical TPEG concept that a single TPEG message equates with a single content
item, in this case, a fuel station. The total volume of data per fuel station may easily exceed a hundred
bytes. However, clients without any pre-existing information (e.g. transit users) still must be able to
have useable data in a short amount of time (~10 min to ~20 min). Some form of transmission at high
repetition rates for minimum content, augmented with low repetition rate for additional detailed
content is required.
Clustering of (partial) content. The design direction taken for FPI is to allow service providers to
arrange their transmissions flexibly, depending on the volume of data to be transmitted and the
available bandwidth. That is, the unit of control (a TPEG message) is separated from the unit of content
(Fuel Station). Instead, a TPEG message can contain partial content for a cluster of stations (e.g. station
locations, or fuelling information) or complete content for a single fuel station.
A large bandwidth service provider with fewer fuel stations to transmit information for may provide
the following lay-out of TPEG FPI messages (all messages include the standard MMC component and, for
receiver geographic filtering, a LocationReferencingContainer indicating the geographic coverage area).
— TPEG FPI message, variant A: Fuel definitions (FPI Component: fuelingDefinitions)
— TPEG FPI message, variant B: Station Information for a cluster of 1 station
(FPI components: StationFuelingInfoCluster,
StationExtraInfoCluster, StationSiteInfoCluster and
StationMapLocationCluster).
Both message variants are transmitted at a high repetition rate.
Conversely, a small bandwidth service provider (with more fuel stations to transmit information
for) can capitalize on the fact that most of the fuel station information is rather static, (location, site
information, etc.).
Thus, a small bandwidth service provider may utilize the following lay-out of TPEG FPI messages.
High repetition rate messages (with standard inclusion of the MMC component and, for receiver
geographic filtering, a LocationReferencingContainer indicating the geographic coverage area).
6 © ISO 2016 – All rights reserved

— TPEG FPI message, variant 1: Fuel definitions (FPI Component: fuelingDefinitions)
— TPEG FPI message, variant 2: Station Information for a cluster of N1 stations
(FPI components: StationFuelingInfoCluster)
— TPEG FPI message, variant 3: Station Information for a cluster of N2 stations
(FPI components: StationPOILocationCluster)
Low repetition rate messages (with standard inclusion of the MMC component and, for receiver
geographic filtering, a LocationReferencingContainer indicating the geographic coverage area).
— TPEG FPI message, variant 4: Station Information for a cluster of N stations
(FPI components: StationSiteInfoCluster)
— TPEG FPI message, variant 5: Station Information for a cluster of M1 < N stations
(FPI components: StationNavLocationCluster)
— TPEG FPI message, variant 6: Station Information for a cluster of M2 < N stations
(FPI components: StationExtraInfoCluster)
In this case, a low bandwidth service provider can tailor the repetition rate and content of message
variants to its local situation and demands. Transit users, without any pre-existing information,
are quickly served with the high repetition messages containing the basic location and fuel price
information. Commuter users may build up over time the complete fuel station database, including
detailed site and location information.
Receivers will link the content tables together based on the unique identification of a fuel station, i.e. the
triplet (areaID_Key, stationID_Key) and the fuel definition table (areaID_Key,fuelingDefinitionsID_Key).
NOTE This relational database technology is well known. For utmost clarity, in this Technical Specification,
the identifiers used as table keys have been given the suffix “_Key”.
6.2.4 MMC usage and FPI message combinations
FPI can make use of both monolithic and multi-part message management for transmission of the fuel
station and fuelling definition tables (see ISO/TS 21219-6). The unit of content update shall always be
an individual message in case of monolithic message management, or a message part in case of a multi-
part message.
In case of a choice (for example, in a TPEG profile) for monolithic message management, then each
FPI table (represented by the top-level applicationInformation components) may be transmitted in a
separate message or, alternatively, several applicationInformation components may be transmitted
together in a single message. The choice largely depends on the desirable repetition rates for these
components. Components with an equal repetition rate can advantageously be combined in a single
message.
With monolithic message management, each message shall have a unique message ID to distinguish it
from other messages. If at least one information element changes for any of the contained fuel stations,
then the versionID of the message shall be increased.
In case of a choi
...