M/270 - Road transport telematics

This document gives guidelines for the development of multi-operator/multi-service interoperable
public surface (including subways) transport fare management systems (IFMSs) on a national and
international level.
This document is applicable to bodies in public transport and related services which agree that their
systems need to interoperate.
This document defines a conceptual framework which is independent of organizational and physical
implementation. Any reference within this document to organizational or physical implementation is
purely informative.
This document defines a reference functional architecture for IFMSs and establishes the requirements
that are relevant for ensuring interoperability between several actors in the context of the use of
electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as:
— management of media,
— management of applications,
— management of products,
— security management, and
— certification, registration, and identification.
This document defines the following main elements:
— identification of the different sets of functions in relation to the overall IFMS and services and media
from non-transport systems which interact with fare management systems;
— a generic model of an IFMS describing the logical and functional architecture and the interfaces
within the system, with other IFMSs and with services and media from non-transport systems;
— use cases describing the interactions and data flows between the different sets of functions;
— security requirements.
In its annexes, this document provides a framework for mobility platforms that integrate fare
management and travel information for inter- and multimodal travel (see Annex A). It also elaborates
on specific subjects covered in document and offers some national examples with regard to IFMS
implementations (see Annex B, Annex C, Annex D and Annex E).
This document does not define:
— the technical aspects of the interface between the medium and the medium access device;
— the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the medium and the medium access device are proposed by other
standardization committees.
— the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).

This Technical Specification establishes the method of referencing used within a TPEG data-stream to allow a service provider to signal availability of the same service on another bearer channel or similar service data from another service. TPEG is a byte-oriented stream format, which may be carried on almost any digital bearer with an appropriate adaptation layer. TPEG messages are delivered from service providers to end-users, and are used to transfer application data from the database of a service provider to a user’s equipment. The protocol is structured in a layered manner and employs a general purpose framing system which is adaptable and extensible, and which carries frames of variable length. This has been designed with the capability of explicit frame length identification at nearly all levels, giving greater flexibility and integrity, and permitting the modification of the protocol and the addition of new features without disturbing the operation of earlier client decoder models.

ISO/TS 18234-2:2013 establishes the method of referencing used within a TPEG data-stream to allow a service provider to signal availability of the same service on another bearer channel or similar service data from another service.

This document gives guidelines for the development of multi-operator/multi-service interoperable
public surface (including subways) transport fare management systems (IFMSs) on a national and
international level.
This document is applicable to bodies in public transport and related services which agree that their
systems need to interoperate.
This document defines a conceptual framework which is independent of organizational and physical
implementation. Any reference within this document to organizational or physical implementation is
purely informative.
This document defines a reference functional architecture for IFMSs and establishes the requirements
that are relevant for ensuring interoperability between several actors in the context of the use of
electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as:
— management of media,
— management of applications,
— management of products,
— security management, and
— certification, registration, and identification.
This document defines the following main elements:
— identification of the different sets of functions in relation to the overall IFMS and services and media
from non-transport systems which interact with fare management systems;
— a generic model of an IFMS describing the logical and functional architecture and the interfaces
within the system, with other IFMSs and with services and media from non-transport systems;
— use cases describing the interactions and data flows between the different sets of functions;
— security requirements.
In its annexes, this document provides a framework for mobility platforms that integrate fare
management and travel information for inter- and multimodal travel (see Annex A). It also elaborates
on specific subjects covered in document and offers some national examples with regard to IFMS
implementations (see Annex B, Annex C, Annex D and Annex E).
This document does not define:
— the technical aspects of the interface between the medium and the medium access device;
— the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the medium and the medium access device are proposed by other
standardization committees.
— the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).

This document establishes a method of encrypting certain elements of the ALERT-C coded data carried in the RDS-TMC type 8A data group, such that without application by a terminal or receiver of an appropriate key, the information conveyed is virtually worthless. Before a terminal is able to decrypt the data, the terminal requires two "keys". The first is given in confidence by the service provider to terminal manufacturers with whom they have a commercial relationship; the second is broadcast t in the "Encryption Administration Group," which is also a type 8A group. This International Standard explains the purpose of the two keys and how often and when the transmitted key may be changed. Before an individual terminal may present decrypted messages to the end-user, it must have been activated to do so. Activation requires that a PIN code be entered. The PIN code controls access rights to each service and subscription period, allowing both lifetime and term business models to co-exist. The International Standard also describes the considerations for service providers wishing to introduce an encrypted RDS-TMC service, migrating from either a "free-to-air" service based on public "Location Tables" or a commercial service based on a proprietary Location Table. Finally, "hooks" have been left in the bit allocation of the type 8A group to allow extension of encryption to other RDS-TMC services.

This Technical Specification establishes the method of location referencing used by TPEG applications such as TPEG-RTM or TPEG-PTI. TPEG applications are specified to contain all the information required by a client TPEG decoder (i.e. both location referencing and event information), to present all the information intended for the end-user when it was originated by the service provider. The term "application" is used in TPEG specifications to describe specific applications, which are at the highest layer of the ISO/OSI protocol stack (ISO/IEC 7498-1). Each TPEG application (e.g. TPEG-RTM) is assigned a unique number that is called the Application IDentification (AID). In this respect TPEG-Loc is not an application, but it is an essential constituent part of an application. Location referencing requires a service provider to give an impression or image to the human end-user of where an event has taken place. This cannot be done easily because the human end-user may or may not be familiar with the location. TPEG-Loc has the added challenge of attempting to be as language independent as possible. This is achieved by the use of TPEG-Loc tables (essentially word oriented data object dictionaries). TPEG-Loc also provides location data in a machine-readable form that allows a "thick" client such as a navigation system to map-match, on-the-fly, to locate the event being described onto a digital map display.

This document establishes the XML encoding of the method of the Public Transport Information application. The Public Transport Information Application is intended to cover all modes of public (ie collective) transport as well as inter-urban and intra-urban travel. The application itself is designed to allow the efficient and language independent transmission of public transport information either directly to an end-user, be it the public or another service provider, such as broadcasters, service operators or other information disseminating points or centres for onward transmission. TPEG-PTI aims at describing "legs" of a journey also described as "rides" by other methodologies. However, it is important to note that TPEG-PTI is not limited to describing single services, because it also allows the more general description of route, service and area wide problems. Public (or collective) transport information is usually consumed in one of four principle ways, and in TPEG-PTI these are labelled views, they are somewhat an analogue to: Leader board information as used at stations or terminals A report on the state of a network The description of an individual service As a news flash report While the elements needed to produce information for any one of these four "views" are largely germane across the presentations, the end-user focus of TPEG applications is seen as useful to be able to mimic presentations, to which end-users are accustomed. TPEG-PTI views are intended to present information to end-users in a way that they are accustomed. TPEG-PTI messages can therefore group data elements to present one of the following views: Incident Report View Station/Terminal View Route View Individual Service View.

This Technical Specification describes the Public Transport In formation (PTI) Application, which is intended to cover all modes of public (i.e. collective) transport as well as inter-urban and intra-urban travel. The application is designed to allow the efficient and language independent delivery of public transport information directly from service provider to end-users. The term "application" is used in TPEG specifications to de scribe specific applications, such as in this case the public transport information application, which comprises three information containers: the message management container, the application event container and the TPEG-location container. The first two containers are fully described herein and the TPEG-location container is described in CEN ISO/TS 18234-6. Each TPEG Application (e.g. TPEG-PTI) is assigned a unique number that is called the Application IDentification (AID). An AID is defined whenever a new application is developed. The AID is used within the TPEG-Service and Network Information Application (CEN ISO/TS 18234-3) to indicate how to process TPEG content and allows routing of data to an appropriate Application decoder. AID = 0002 (hex) is assigned to the TPEG-PTI application, described in this specification. The TPEG-PTI application aims at describing "legs" of a journey also described as "rides" by other methodologies. However, it is important to note that TPEG-P TI is not limited to describing single services, because it also allows the more general description of route, service and area-wide problems. Public (or collective) transport information is usually consumed in one of four principle ways as follows : Leader board information as used at stations or terminals; A report on the state of a network; The description of an individual service; As a news flash report. The elements needed to provide information for any one of the four end-user presentation modes are largely the same. The end-user focus of TPEG applications makes it useful to be able to mimic presentations, to which end-users are accustomed, for example a railway station indicator board. TPEG-PTI messages can therefore group data elements to present one of the following end-user presentation modes: Incident message report; Station/terminal information.

This document establishes the XML encoding of the method of the Road Traffic Message application. The TPEG-RTM Application is intended to convey information to road users. The information provided relates to event and some status information on the road network and on associated infrastructure affecting a road journey. For example, limited information about abnormal operation of links in the network may be included, such as ferries, lifting-bridges, etc. The TPEG-RTM Application has the broad objective to allow the generation of Traffic and Travel Information (TTI) messages, for delivery to the end-user by one or more bearers. A hierarchical methodology has been developed to allow the creation of messages from a set of TPEG-RTM tables, which are essentially word-oriented and cover most needs. These TPEG-RTM tables (essentially word-oriented data object dictionaries) comprise a wide ranging ability to describe a TTI event and some status information, introducing new precision in a number of areas such as "Vehicle types", "Positional information on the carriageway" and "Diversion routing advice". It is vital, for further understanding of this document, to have more than a passing understanding of the TPEG-RTM binary specification which describes, among other things, in a step-by step approach: Message Management, Level One Classes and how they are structured, hierarchically to provide a full Road Traffic Message together with the TPEG Location Referencing system.

This document establishes the method of delivering Road Traffic Messages within a TPEG service. The TPEG-RTM application is designed to allow the efficient and language independent delivery of road information directly from service provider to end- users. The information provided relates to event and some status information on the road network and on associated infrastructure affecting a road journey. For example, limited information about abnormal operation of links in the network may be included, such as ferries, liftingbridges, etc. The term "application" is used in TPEG specifications to describe specific applications, such as in this case the Road Traffic Message application, which comprises three information containers: the Message Management Container, the Application Event Container and the TPEG-Location Container. The first two Containers are fully described herein and the TPEG-Location Container is described in CEN ISO/TS 18234-6. Each TPEG application (e.g. TPEG-RTM) is assigned a unique number that is called the application identification (AID). An AID is defined whenever a new application is developed. The AID is used within the TPEG-Service and Network Information Application (CEN ISO/TS 18234-3) to indicate how to process TPEG content and allows routing of data to an appropriate application decoder. AID = 0001 is assigned to the TPEG-Road Traffic Message application, described in this specification. A hierarchical methodology has been developed to allow the creation of messages from a set of TPEG-RTM tables, which are essentially word oriented and cover most needs. Many o f the TTI descriptive words, in the TPEG-RTM tables, were obtained from the DATEX dictionary (ENV 13106), which embodies European TTI knowledge of the last ten years or more, including a deconstruct of the phrase oriented RDS-TMC events list (EN IS O 14819-2). These TPEG-RTM tables (essentially word oriented data object dictionaries) comprise a wide ranging ability to describe a TTI event and some status information, introducing new precision in a number of areas such as "vehicle types", "positional information on the carriageway" and "diversion routing advice".

This specification will describe the general use of XML technology as applied to TPEG applications and establish a method of top level container to encapsulate messages with an additional layer of message management required by internet servers and clients to ensure best bandwidth utilisation. tpegML will allow individual application messages (eg TPEG-RTM and TPEG-PTI) to be packaged for delivery as files or objects (rather than as byte streams).

This document establishes the XML encoding of the method of Location Referencing used by TPEG applications. TPEG applications contain the information required by a client TPEG decoder (i.e. both Location Referencing and event information), to present all the information intended for the end-user when it was originated by the service provider. Location Referencing requires a service provider to give an impression or image, to the human end-user, of where an event has taken place. This cannot be done easily because the human end-user may or may not be familiar with the location. tpeg-loc has the added challenge of attempting to be as language independent as possible. This is achieved by the use of tpeg-loc tables (essentially word-oriented data object dictionaries). tpeg-loc is the recommended Location Referencing system for TPEG. It provides location data in a machine readable form that allows a "thick" client such as a navigation system to map-match, on-the-fly, to locate the event being described onto a digital map display. However, it is possible to additionally use other location methods, such as the 'Link-id' method by suitably modifying the tpegML.dtd to include the relevant lines, e.g.: %link-idML; It is vital, for further understanding of this document, to have more than a passing understanding of the tpeg-loc binary specification which describes, among other things, in a step-by step approach: point, link and area definitions, and how they are structured to provide a full Location Referencing system.

ISO TS 18234-6:2006 establishes the method of location referencing used by TPEG applications such as TPEG-RTM or TPEG-PTI.
TPEG applications are specified to contain all the information required by a client TPEG-decoder (i.e. both location referencing and event information), to present all the information intended for the end-user when it was originated by the service provider.

ISO TS 18234-4:2006 establishes the method of delivering Road Traffic Messages within a TPEG service. The TPEG-RTM application is designed to allow the efficient and language independent delivery of road information directly from service provider to end-users. The information provided relates to event and some status information on the road network and on associated infrastructure affecting a road journey. For example, limited information about abnormal operation of links in the network may be included, such as ferries, lifting-bridges, etc.

ISO TS 18234-5:2006 describes the Public Transport Information (PTI) application, which is intended to cover all modes of public (i.e. collective) transport as well as inter-urban and intra-urban travel. The application is designed to allow the efficient and language independent delivery of public transport information directly from service provider to end-users.

ISO/TS 24530-4:2006 establishes the XML encoding of the method of the Public Transport Information application.
The Public Transport Information application is intended to cover all modes of public (i.e. collective) transport as well as inter-urban and intra-urban travel. The application itself is designed to allow the efficient and language-independent transmission of public transport information either directly to an end-user, be it the public or another service provider, such as broadcasters, service operators or other information disseminating points, or to centres for onward transmission.

ISO/TS 24530-3:2006 establishes the XML encoding of the method of the Road Traffic Message application.

ISO 14819-6:2006 establishes a method of encrypting certain elements of the ALERT-C coded data carried in the RDS-TMC type 8A data group, such that without application by a terminal or receiver of an appropriate keys, the information conveyed is virtually worthless.
Before a terminal is able to decrypt the data, the terminal requires two "keys". The first is given in confidence by the service provider to terminal manufacturers with whom they have a commercial relationship; the second is broadcast in the "Encryption Administration Group," which is also a type 8A group. This specification explains the purpose of the two keys and how often and when the transmitted key may be changed.
Before an individual terminal may present decrypted messages to the end-user, it must have been activated to do so. Activation requires that a PIN code be entered. The PIN code controls access rights to each service and subscription period, allowing both lifetime and term business models to co-exist.
The specification also describes the considerations for service providers wishing to introduce an encrypted RDS-TMC service, migrating from either a "free-to-air" service based on public "Location Tables" or a commercial service based on a proprietary Location Table.
Finally, "hooks" have been left in the bit allocation of the type 8A group to allow extension of encryption to other RDS-TMC services.

ISO/TS 24530-1:2006 establishes the top-level "containers" for TPEG messages in XML and the common data types that are used by tpegML applications (e.g. tpeg-ptiML). Inherently, tpegML is designed to "map" the TPEG binary (ISO/TS 18234 series), however, additional tags are provided to create a message and message set structure to facilitate internet file delivery.

ISO/TS 24530-2:2006 establishes the XML encoding of the method of Location Referencing used by TPEG applications.
TPEG applications contain the information required by a client TPEG decoder (i.e. both Location Referencing and event information), to present all the information intended for the end-user when it was originated by the service provider.
Location Referencing requires a service provider to give an impression or image, to the human end-user, of where an event has taken place. This cannot be done easily because the human end-user may or may not be familiar with the location. tpeg-loc has the added challenge of attempting to be as language independent as possible. This is achieved by the use of tpeg-loc tables (essentially word-oriented data object dictionaries).

This part of ISO 24014 provides the basis for the development of multi-operator/multi-service
Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a
national and international level.
This part of ISO 24014 is applicable to bodies in public transport and related services which agree that
their systems need to interoperate.
While this part of ISO 24014 does not imply that existing interoperable fare management systems need
to be changed, it applies so far as it is practically possible to extensions of these.
This part of ISO 24014 covers the definition of a conceptual framework which is independent
of organisational and physical implementation. Any reference within this part of ISO 24014 to
organisational or physical implementation is purely informative.
The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and
to identify the requirements that are relevant to ensure interoperability between several actors in the
context of the use of electronic tickets.
The IFMS includes all the functions involved in the fare management process such as
— management of application,
— management of products,
— security management, and
— certification, registration, and identification.
This part of ISO 24014 defines the following main elements:
— identification of the different set of functions in relation to the overall fare management system;
— a generic model of IFMS describing the logical and functional architecture and the interfaces within
the system and with other IFMSs;
— use cases describing the interactions and data flows between the different set of functions;
— security requirements.
This part of ISO 24014 excludes consideration of the following:
— the physical medium and its management;
— the technical aspects of the interface between the medium and the medium access device;
— the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other
standardization committees.
— the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).

This standard provides the basis for the development of multi-operator/multi-service Interoperable Public Transport Fare Management Systems (IFM).
The objective of this standard is to define a reference functional architecture for IFM systems and to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets.
The IFM system includes all the functions involved in the fare management process such as
-   Management of Application
-   Management of Products (dissemination, acquisition, use, collection and clearing of product data)
-   Security management  (data security, privacy scheme)
-   Customer Management (customer relationship management, )
-   inspection / enforcement
-   reporting and monitoring
The work will benefit from the architecture work done in the Road Toll Collection (TC278/WG1) and other domains e.g. :
-   ENV ISO 14904 "RTTT-Automatic Fee Collection-Interface specification for Clearing between Operators"
-   proposed ENV ISO 17573 "RTTT Electronic Fee Collection, System architecture for vehicle related transport services"
-   existing international data security standards
-   ENV 12896 "RTTT- Reference data model" (Transmodel).
The media, the media issuing and the interface between the media and the acceptance device as well as the financial dimension of fare management systems are not in the scope of this standard.
Part 1 of the standard describes the following main elements:
-   Identification of the different functional entities in relation to the overall fare management system.
-   Definition of a generic model of IFM system describing the logical and functional architecture and the interfaces within the system and with other IFM systems.
-   Use cases describing the interactions and data flows between the different functional entities.
-   Description of security requirements.
Part 2 of the standard provides the messages between the Entities of the IFM System

ISO 24014-1:2015 provides the basis for the development of multi-operator/multi-service Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a national and international level.
ISO 24014-1:2015 is applicable to bodies in public transport and related services which agree that their systems need to interoperate.
While ISO 24014-1:2015 does not imply that existing interoperable fare management systems need to be changed, it applies so far as it is practically possible to extensions of these.
ISO 24014-1:2015 covers the definition of a conceptual framework which is independent of organisational and physical implementation. Any reference within this part of ISO 24014 to organisational or physical implementation is purely informative.
The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets.
The IFMS includes all the functions involved in the fare management process such as
- management of application,
- management of products,
- security management, and
- certification, registration, and identification.
This part of ISO 24014 defines the following main elements:
- identification of the different set of functions in relation to the overall fare management system;
- a generic model of IFMS describing the logical and functional architecture and the interfaces within the system and with other IFMSs;
- use cases describing the interactions and data flows between the different set of functions;
- security requirements.
ISO 24014-1:2015 excludes consideration of the following:
- the physical medium and its management;
- the technical aspects of the interface between the medium and the medium access device;
- the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other standardization committees.
? the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).

ISO 24014-1:2007 provides the basis for the development of multi-operator/multi-service Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a national and international level.
ISO 24014-1:2007 is applicable to bodies in public transport and related services which agree that their systems need to interoperate.
While ISO 24014-1:2007 does not imply that existing interoperable fare management systems need to be changed, it applies, so far as it is practically possible, to extensions of these.
ISO 24014-1:2007 covers the definition of a conceptual framework, which is independent of organisational and physical implementation. Any reference within ISO 24014-1:2007 to organisational or physical implementation is purely informative.
The objective of ISO 24014-1:2007 is to define a reference functional architecture for IFMSs and to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as
management of Application;
management of Products;
security management;
certification, registration and identification.
ISO 24014-1:2007 defines the following main elements:
identification of the different functional entities in relation to the overall fare management system;
a generic model of IFMS describing the logical and functional architecture and the interfaces within the system and with other IFMSs;
use cases describing the interactions and data flows between the different functional entities;
security requirements.
ISO 24014-1:2007 excludes consideration of
the physical medium and its management;
the technical aspects of the interface between the medium and the medium access device;
the data exchanges between the medium and the medium access device, which are proposed by other standardisation committees;
the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).

This Technical Specification provides an introduction and index to the initial set of TPEG applications and specifications. It allows the indexing of new applications as they are added to the TPEG applications family, by defining their Application Identification (AID). As such developments occur, this Technical Specification will be updated to indicate the latest status and the interworking of the various TPEG specifications. It shall be issued as a new editorial-version every time a new issue of any other specification is issued.

This Technical Specification establishes the method of referencing used within a TPEG data-stream to allow a service provider to signal availability of the same service on another bearer channel or similar service data from another service. TPEG is a byte-oriented stream format, which maybe carried on almost any digital bearer with an appropriate adaptation layer. TPEG messages are delivered from service providers to end-users, and are used to transfer application data from the database of a service provider to a user's equipment. The protocol is structured in a layered manner and employs a general purpose framing system which is adaptable and extensible, and which carries frames of variable length. This has been designed with the capability of explicit frame length identification at nearly all levels, giving greater flexibility and integrity, and permitting the modification of the protocol and the addition of new features without disturbing the operation of earlier client decoder models.

ISO TS 18234-1:2006 provides an introduction and index to the initial set of TPEG applications and specifications. It allows the indexing of new applications as they are added to the TPEG applications family, by defining their Application Identification (AID).
As such developments occur, ISO TS 18234-1:2006 will be updated to indicate the latest status and the interworking of the various TPEG specifications. It will be issued as a new editorial version every time a new issue of any other specification is issued.

ISO TS 18234-2:2006 establishes the method of referencing used within a TPEG data stream to allow a service provider to signal availability of the same service on another bearer channel or similar service data from another service.
TPEG is a byte-oriented stream format, which may be carried on almost any digital bearer with an appropriate adaptation layer. TPEG messages are delivered from service providers to end-users, and are used to transfer application data from the database of a service provider to a user's equipment.
The protocol is structured in a layered manner and employs a general purpose framing system which is adaptable and extensible, and which carries frames of variable length. This has been designed with the capability of explicit frame length identification at nearly all levels, giving greater flexibility and integrity, and permitting the modification of the protocol and the addition of new features without disturbing the operation of earlier client decoder models.

For many years, consumers, law enforcement agencies and insurers have been confronted with an ever-increasing number of vehicle thefts, both genuine thefts and insurance frauds, as well as the growing problem of increasing violence and threats against vehicle drivers.
Manufacturers have and will continue to introduce after-theft systems that will enable the police to recover stolen vehicles. Different techniques are being used for that purpose. This document refers to them by the generic name of After-Theft Systems for Vehicle Recovery (ATSVR).
Standards for Automatic Vehicle Identification (AVI) and Automatic Equipment Identification (AEI) are being developed by CEN/TC 278, WG 12 in parallel with EN ISO 14814. This ATSVR standard does not prejudice that work and does not seek to establish parameters for future AVI/AEI standards. DSRC and AVI standards are seen as basic technology blocks for types of short-range ATSVR systems.
Certain specialised terms and definitions have been used in writing the ATSVR standards.  This preliminary document aims to provide the preliminary framework of ATSVR concepts and definitions for the purpose of following ones. It will therefore:
-   define the concepts and global architecture models for ATSVR and the appropriate terminology;
-   identify the various elements that may comprise an ATSVR.
The events and associated information that are relevant to the situation prior to the registration of the theft are relevant to the total process, but may be subject to the laws of individual countries. Such events and associated information may be described in the standards to give clarity to the technical processes identified, which obviously does not presume on the prevailing legal conditions.

For many years, consumers, law enforcement agencies and insurers have been confronted with an ever-increasing number of vehicle thefts, both genuine thefts and insurance frauds, as well as the growing problem of increasing violence and threats against vehicle drivers.
Manufacturers have and will continue to introduce after-theft systems that will enable the police to recover stolen vehicles. Different techniques are being used for that purpose. This document refers to them by the generic name of After-Theft Systems for Vehicle Recovery (ATSVR).
Standards for Automatic Vehicle Identification (AVI) and Automatic Equipment Identification (AEI) are being developed by CEN/TC 278, WG 12 in parallel with EN ISO 14814. This ATSVR standard does not prejudice that work and does not seek to establish parameters for future AVI/AEI standards. DSRC and AVI standards are seen as basic technology blocks for types of short-range ATSVR systems.
Certain specialised terms and definitions have been used in writing the ATSVR standards.  This preliminary document aims to provide the preliminary framework of ATSVR concepts and definitions for the purpose of following ones. It will therefore:
-   define the concepts and global architecture models for ATSVR and the appropriate terminology;
-   identify the various elements that may comprise an ATSVR.
The events and associated information that are relevant to the situation prior to the registration of the theft are relevant to the total process, but may be subject to the laws of individual countries. Such events and associated information may be described in the standards to give clarity to the technical processes identified, which obviously does not presume on the prevailing legal conditions.

This Technical Specification establishes the method of delivering service and network information within a TPEG service. The TPEG-SNI application is designed to allow the efficient and language independent delivery of information about the availability of the same service on another bearer channel or similar service data from another service provider, directly from service provider to end-users. The term "application" is used in TPEG specifications to describe specific applications, which are at the highest layer of the ISO/OSI protocol stack (ISO/IEC 7498-1). Each TPEG application (e.g. TPEG-RTM) is assigned a unique number that is called the Application IDentification (AID). An AID is defined whenever a new application is developed. The AID is used within the TPEG-Service and Network Information Application (this document) to indicate how to process TPEG content and allows routing of data to an appropriate application decoder. AID = 0000 is assigned to the TPEG-SNI application, described in this specification. A number of tables of information are described, which provide comprehensive options for describing services, their timing, content, geographical coverage, etc. In all TPEG streams it is mandatory to deliver to so-called GST. Additionally it is possible to signal linkage of content between different bearers and services.

ISO TS 18234-3:2006 establishes the method of delivering Service and Network Information (SNI) within a TPEG service. The TPEG-SNI Application is designed to allow the efficient and language independent delivery of information about the availability of the same service on another bearer channel or similar service data from another service provider, directly from service provider to end-users.