ISO/TC 204/WG 10 - Traveller information systems

This document describes the “public transport information service” (PTS) application, which is intended to cover all modes of public (i.e. collective) transport, both for inter-urban and intra-urban travel. The PTS application is designed to allow the efficient and language-independent delivery of public transport information directly from a service provider to end-users. The PTS application design is based on three main use cases. — Provision of alert information: an alert is a warning that indicates an emergency situation. This case is specifically relevant for broadcast/push mode, for major deviations or disruptions which are relevant for a large number of travellers. A dedicated alert request is also defined and can be used if a backchannel is available. — Timetable information, both scheduled and real time: this information is in some cases relevant for broadcast, e.g. in case of large events for the transport modalities to/from the event site. A dedicated timetable request is also defined and can be used if a backchannel is available. — Individual requests for trip information (backchannel is required). The PTS application focuses on providing core information regarding public transport in order to ensure the compactness of the TPEG application. Specific information as provided in typical public transport apps (e.g. fare information) is not in the scope of this document.

This document specifies a graphic data dictionary (GDD), a system of standardized codes for existing road traffic signs and pictograms used to deliver traffic and traveller information (TTI). The coding system can be used in the formation of messages within intelligent transport systems (ITS).

This document defines the TPEG Weather (WEA) application for reporting weather information for travellers. It provides general weather-related information to all travellers and is not limited to a specific mode of transportation. This application does not provide specific weather-related safety warnings to drivers; these are provided as safety related messages as part of the TPEG2-TEC application (ISO 21219-15). The WEA application provides weather-related forecasts and status information over multiple time periods and for multiple, possibly linked, geographical areas. NOTE The presentation of the information is dependent on the specific human-machine interface (HMI) of the receiving device. Therefore, this document does not define any prerequisites for the HMI of the device. This document contains examples to help explain how some typical weather reports can be signalled (see Annex C) and suggested translations between WEA table codes and WMO SYNOP weather observation codes (see Annex D).

This document specifies the "traffic event compact" (TEC) TPEG application. The TEC application has been specifically designed to support information about traffic events (e.g. road works, traffic jams). A specific form of traffic event is local hazard warnings which, being safety-related messages, are sent with high priority to warn a driver of unexpected dangerous situations (e.g. black-ice, accident beyond curves, obstacles on road, etc.). Generally, the TEC application is designed to allow receivers to: — ensure travel safety for the driver; — enable the calculation of alternative routes; — avoid delays (e.g. traffic jams); — warn the driver of obstructions on route; and — provide the driver with information on infrastructural problems (e.g. closed petrol stations, non-functioning emergency telephones).

This document specifies the method for delivering service and network information within a TPEG service. The TPEG-SNI application is designed to allow the efficient, 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. A number of tables of information are described in this document which provide comprehensive options for describing services, their timing, content, geographical coverage, etc. In all TPEG streams, it is mandatory to deliver the so-called guide to the service table (GST). Additionally, it is possible to signal linkage of content between different bearers and services.

This document defines the TPEG Speed information (SPI) application for reporting speed information for travellers. Speed limits are usually indicated to the driver through roadside signs. Drivers who are aware of the speed limit at all times are more likely to drive safely, which improves road safety. Most speed limit signs are static and remain unchanged for years and are thus available through navigation system map databases. However, there is an increasing number of variable message signs, temporary signing (e.g. for road works) and also changed speed limits which are not yet reflected in the map databases. With the TPEG-SPI application, speed limit information is offered in an accurate way so that different lanes and different vehicle types can be differentiated. TPEG-SPI also allows the drivers to be aware of the current allowed (maximum) speed, by delivering timely information about the current position and values of speed limits to the navigation or driver assistance systems. These data are seen as informational and are intended to be encoded in a compact way to minimize bandwidth consumption. TPEG2-SPI supports direct and indirect speed limits. Direct speed limits are used for signs showing a maximum speed at which a vehicle is allowed to travel. Such speed limit signs can be static or dynamic. Indirect speed limits refer to the speed of other road users. It is primarily the vehicle in front of the own vehicle that is used as a reference.

This document specifies the TPEG fuel price information and availability (FPI) application. The FPI application has been specifically designed to support information from fuel stations, such as 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 for end users of a TPEG service: a) cost savings to the driver through improved ease of access to price information; b) potentially significant cost savings for fleet operators through improved ease of access to price information; 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 becomes more common, and more vehicles begin to use them (e.g. biofuels, hydrogen, etc.), drivers will be better informed about availability of fuelling stations. The TPEG FPI application (as an add-on service component next to traffic information, for example) is laid out to support large numbers of fuel stations and fuel prices with only modest bandwidth requirements The application described in this document (TPEG2-FPI) is not appropriate for cases where the objective is to inform electric vehicles of the location of charging stations and the availability of charging points. In such cases, the TPEG application TPEG2-EMI (electro mobility information) is chosen. This is because while TPEG2-FPI (the application described in this document) contains rudimentary support for electric charging stations, a TISA investigation revealed that a simple extension/differentiation of TPEG2-FPI is insufficient for addressing the evolving market needs of the electric vehicle market. Hence, a separate TPEG application has been created to serve the information needs of electric vehicles and their operators: TPEG2-EMI, specified in ISO/TS 21219-25.

This document specifies the TPEG parking information (PKI) application which has been designed to deliver parking information to a variety of receivers using a number of different channels, particularly digital broadcasting and internet technologies. Parking information can be presented to the user in many different ways, including text, voice or graphics. Today, traffic congestion has become a serious problem in urban areas. Some traffic congestion is attributed to drivers searching for parking spaces. Timely provision of parking information can help to ease traffic congestion. Furthermore, parking information is valuable for visitors, particularly when it can be used to signal where a temporary parking facility is established for a special event.

This document defines the TPEG conditional access information (CAI) application. It allows the protection of the content of a TPEG service from unauthorized access. It further supports the management of subscriber information (e.g. control words and entitlement control message, ECM) on client devices in order to setup, prolong or revoke a subscription on a given client device. The CAI application defines: — the logical channel for the transmission of the additional CAI, and — how the CAI is linked and synchronized to the scrambled content. This document is related to conditional access applied on the service component level. It can be integrated into different conditional access systems. NOTE The basic concept behind the CAI application is to transport CAI in separate TPEG service components of a dedicated application type and to define a service and network information (SNI) table that contains the link between scrambled content and related CAI.

This document defines an index to the complete set of TPEG Generation 2 toolkit components and applications. New applications are enumerated with an application identification (AID) as they are added to the TPEG applications family. NOTE 1 This document will be updated when new applications occur in order to indicate the latest status and the inter-working of the various TPEG specifications. This document will be revised as a new edition every time a new issue of any other specification is issued. NOTE 2 Preliminary AIDs are allocated and managed by TISA and are listed at Reference.

The ALERT-C protocol is designed to provide mostly event-oriented road end-user information messages. This document specifies the messages which are presented to the user in accordance with a set of general requirements. It defines the message structure and content and its presentation to the end-user. The message management component of this document describes the message management functions of RDS-TMC. The ALERT-C protocol distinguishes between user messages and system messages. User messages are those potentially made known to the end-user, as defined in Clause 5. System messages are of use only to the RDS-TMC terminal, for message management purposes. RDS-TMC information comprises both ?system information' and ?user messages'. System information relates to the TMC service and details the parameters that the terminal needs to be able to find, identify and decode the TMC information. System information is transmitted in type 3A groups and in type 8A groups. User messages contain the details of the traffic events; these may use one or more type 8A groups. Most messages may be transmitted using a single type 8A group, however messages with more detail (e.g. diversion advice) may use up to a total of five, type 8A groups. The transmission component of this document conveys the messages over-air. The ALERT-C protocol, used by RDS-TMC, has the fundamental approach of aiming to code most messages entirely within a single RDS group. The ALERT-C Event List, which contains all event descriptions, is described in ISO 14819‑2.

ISO 14819-1 describes the ALERT-C protocol concept and message structure used to achieve densely coded messages to be carried in the RDS-TMC feature. This document specifies the `Events List' to be used in coding those messages.

This document specifies location referencing rules to address the specific requirements of Traffic Message Channel (TMC) systems, which use abbreviated coding formats to provide traffic and travel information (TTI) messages over mobile bearers (e.g. GMS, DAB) or via exchange protocols like DATEX II. In particular, the rules address the Radio Data System-Traffic Message Channel (RDS-TMC), a means of providing digitally-coded TTI to travellers using a silent data channel on FM radio stations, based on the ALERT-C protocol.

This document reports examples of ASN.1 codes based on ISO 14823-1[1], which specifies a graphic data dictionary (GDD) including the ASN.1 coding rule for GDD. NOTE Some of the ASN.1 codes described in this document are re-formatted based on ISO 14813-6. [1] To be published.

This document specifies the TPEG application Traffic Flow and Prediction (TFP). It has been specifically designed to provide information to a variety of receivers using different channels, including in the first instance digital broadcasting and Internet technologies. Traffic flow and prediction messages are intended for in-car applications and can also be presented directly to the user by textual, voice and graphical output devices. TFP is status oriented, i.e. the transmitted information continuously updates the receiver's knowledge for a dedicated road network. In particular the traffic states are delivered any time and for all road sections of the network, even when there are no abnormal traffic situations. Generally, TFP focuses on the following requirements: — provides dynamic navigation systems with up-to-date traffic state information; — ensures travel safety for the driver; — enables the calculation of alternative routes; — avoids delays (e.g. traffic jams); — lowers traffic load on over-saturated parts of the network; — keeps the driver informed about current and upcoming traffic; — compact and efficient coding of the traffic information.

This document specifies rules for the creation and extending of TPEG application UML models. The rules are intended to ensure that TPEG application UML models can be interpreted unambiguously for conversion to physical format representations. TPEG application UML models that are defined according to these rules can be used for automatic generation of TPEG standards and for automatic generation of TPEG application physical format descriptions. This document also specifies the preferred structure of TPEG application specifications. The TPEG abstract data types and the set of TPEG tables of common use are specified in the annexes.

TPEG applications are modelled in UML to provide an application description that is independent of a physical format representation. By separating semantics from application description, applications can easily be developed at a functional level. Different physical format representations can be generated following a well defined set of rules on how to convert UML classes to different physical formats. This document specifies the rules for converting UML models of TPEG application to the TPEG binary format. It contains the binary format definition of the abstract data types defined in ISO 21219-2. Rules for converting compound data types are also defined.

This document specifies the rules for converting TPEG application UML models to the tpegML format description. It contains the XML format definition of the abstract data types defined in ISO 21219-2. Rules for converting compound data types are also defined.

This document establishes a method of conveying data for a wide range of applications that require the efficient transmission of point to multi-point data over potentially unreliable broadcast channels. It is also suitable for point-to-point and multicast applications and may easily be encapsulated in Internet Protocol. This document describes the basic capabilities of the generation 2 TPEG (TPEG2) for providing a multiplex of TPEG Services and applications. Together with the definitions of the general TPEG UML modelling rules and the particular physical TPEG representations for TPEG-binary streams (TISA: TPEG UML Conversion Rules) and tpegML files (TISA Specification: TPEG UML Conversion Rules), it replaces the former documents TPEG-INV and TPEG-SSF.

This document adds a basic toolkit definition to the ISO 21219 series specifying the Message Management Container (MMC) which is used by all TPEG applications to provide information about the handling of messages on the TPEG client side. The MMC holds administrative information allowing a decoder to handle the message appropriately. This information is not aimed at the end user. The MMC is a toolkit and not a stand-alone application but is included by TPEG applications.

This document defines the application for Vigilance Location Information (VLI). Vigilance messages are intended for in-car applications to inform drivers when they should pay extra attention to their driving behaviour because of dangerous road stretches, traffic enforcement cameras or other hazardous locations, requiring increased driver vigilance. The warnings can be presented visually, audibly, or with the spoken voice, or as a combination of all three. The presentation of such messages to the drivers allows them to drive relaxed, in the knowledge that they will be warned when necessary. The situation where a vigilance message makes sense can be very different. For example speed cameras are usually placed in areas where vigilance is required; the information about those locations promote safe driving and also more safety for other road users and outside traffic participants. Another example for areas requiring high driver attention are roads close-by a school. The information can be categorized in two ways: Fixed or mobile locations: — Fixed locations refer to locations which are fixed of nature, such as the presence of known accident black-spots. — Mobile locations refer to locations which are transient in nature, such as the presence of a mobile speed camera. Spot locations or zones: — Spot locations refer to single points on a road network where the warning is located, with an indication of which direction of traffic is affected by the vigilance information. — Zones refer to stretches of road network which represent a continuous area of warning affecting only one traffic direction. The local regulations regarding the signalling of speed measurement systems, e.g. fixed speed cameras, or mobile speed radar locations can vary depending on the country or region. The signalling of speed measurement systems is encouraged by local authorities in certain markets whereas it can be punishable by law in other markets.

ISO/TS 21219-21:2018 defines a method of using geographic location referencing (GLR) that can be used by relevant TPEG applications. The GLR type is defined in this document. It is used for defining geographic location references (points, polylines, and geographical areas). The GLR method is intended to be one of the methods that can be transported inside a TPEG-location referencing container (TPEG-LRC) for those TPEG applications providing information for primarily geographical locations (e.g. weather). The GLR specification is kept basic and compact on purpose, such that it can also be employed advantageously in non-navigation devices for simple TPEG services such as weather information, safety alerts, etc. As such, the GLR location referencing method is intended to be complementary to map-related location referencing methods, where the focus rather is on the referencing of man-made artefacts such as roads and highways. The scope of GLR is limited to geographic locations on the Earth's surface for the above-mentioned rationale.

ISO/TS 21219-7:2017 establishes the method of signalling the specific location referencing used by all TPEG2 applications that require detailed location information to be delivered to client devices such as TPEG2-TEC. The TPEG2-location referencing container (TPEG2-LRC) is described and shows how it is used to signal which specific location referencing method is in use for a particular TPEG message. It is able to handle location referencing methods that are external to the present ISO series and the internal location referencing methods defined as parts of this series.

ISO/TS 21219-22:2017 specifies the logical data format of OpenLRTM location references and general requirements of the method in Clause 6 and defines the structure of the TPEG toolkit for OpenLR location referencing (OLR) in Clauses 7, 8 and 9. The toolkit is intended to be used in the TPEG location referencing container (TPEG-LRC). OpenLR? has been designed for the use case of transferring traffic information from a centre to in-vehicle systems, built-in or used as an add-on (PND, smart phone). The information transferred can consist of the current traffic situation at a certain location, a traffic forecast or special alerts. The corresponding locations are roads, a list of connected roads, points of interest, or areas. In order to transmit location information from a sending to a receiving side, the OpenLRTM method defines rules for generating map-independent location references, that is, the actual location references are generated dynamically not requiring use of pre-defined location references.

ISO/TS 21219-24:2017 defines the LTE encryption mechanism for TPEG Service Data Frames. It has been specifically designed for use with Business to Business (B2B) business models. The objective of this document is to provide a simple to use, yet effective Conditional Access mechanism for TPEG including encryption for use with both broadcast and/or point-to-point delivery. For both service providers and device manufacturers, a standardized conditional access mechanism is beneficial to avoid a proliferation of proprietary methods with multiplied implementation effort and lead times.

ISO/TS 21219-25:2017 defines the TPEG application electromobility charging infrastructure (EMI). It has been specifically designed to support information about charging infrastructure for electric vehicles (not just cars), the location of e-charging points and their suitability for the respective vehicle (e.g. connector type, charging modality). As electric vehicles will occupy a "charging space" for a longer period of time, information on availability/waiting time and reservation options are highly relevant for a user of an electric vehicle to optimally plan his route/trip and are therefore also accounted for. The standardized delivery, through a TPEG technology, of information on charging infrastructures has the following benefits to an end user of this TPEG service: a) Identifying suitable charging units for his vehicle, thus preventing unnecessary driving around to find a fitting unit (also has environmental benefits). b) Verifying the real-time availability of charging units. c) Being able to plan ahead and reserve a spot in a charging park and thus optimize the planning of his trip. d) Being able to select a financially attractive charging point in a charging park the operator of which has billing agreements with the user's electromobility provider. In addition to these end-user benefits, also electromobility providers and charging park operators benefit from a standardized TPEG format as it allows an easier harmonization of the electromobility charging infrastructure information with the data formats used for the exchange of information between management systems of electromobility providers and charge park operators and according specifications (e.g. Open Charge Alliance[1], eMobility ICT Interoperability Innovation (eMI3)[2], etc.). The TPEG application electromobility charging infrastructure, as add-on service component next to, for example traffic information, is laid out to support large numbers of charge parks with only modest bandwidth requirements. [1] http://www.openchargealliance.org/ [2] http://emi3group.com/

ISO/TS 21219-23: 2016 describes new mobility services like car sharing, car rental or park and ride as well as the integration of different transport modes by multimodal or off-board navigation are gaining increasing importance. Furthermore, the cooperative management of the transport infrastructure requires the provision of precise information and guidance on dedicated routes from a central knowledge base to a traveller's mobile device. Such use cases are addressed by the TPEG application defined in this document. The Road and Multimodal Routes (RMR) application enables the service provision for road routes as well as multimodal routes including more than one transport mode and parking. For example, an optimal multimodal route may include a drive by car to a train station with parking facility, a train connection to a station nearby the destination and a local public transport ride from the train station to the traveller's destination. The standardized delivery, via TPEG technology, of routing information has some potential benefits for the users of an RMR TPEG service, for instance: - Enabling of specialized routing services like scenic routing or Eco routing; - The best use of the overall transport network, i.e. not only the road network; - Cost and time savings to traveller; - Harmonization of in-car navigation and traffic management, e.g. routing advices by variable message signs; - Personalized service provisioning, i.e. information services considering the specific characteristics of a user. Some of the use cases above, in particular personalized service, may require a Peer-to-Peer (P2P) communication while others may apply a broadcast communication approach, e.g. city routing.

ISO/TS 18234-1:2013 provides an introduction and index to the complete set of TPEG Generation 1 toolkit components and applications. It allows the indexing of new applications as they are added to the TPEG applications family, by defining their Application Identification (AID).

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.

ISO/TS 18234-9:2013 defines the TPEG application Traffic Event Compact (TEC). It has been specifically designed to support information about traffic events, e.g. road works, traffic jams. A specific form of traffic event are local hazard warnings, which as safety-related messages, are sent with high priority to assist a driver in encountering dangerous situations (e.g. black-ice, accident behind curves, obstacles on road) unexpectedly.

ISO/TS 18234-7:2013 specifies the TPEG Parking Information Application (PKI) which is designed to deliver parking information to a variety of receivers using a number of different channels, foremost digital broadcasting and internet technologies. Parking information may be presented to the user in many different ways including textually, voiced and graphically using standard formats.

ISO 18234-10:2013 contains the definition of the TPEG Conditional Access Information (CAI) application. It enables dedicated conditional access data, such as management messages (e.g. Control Words and Entitlement Control Messages) to be delivered to recipient client devices. This TPEG application is designed for a service provider to: establish setup, prolongation or revocation of services to a specific client device, using a limited capacity unidirectional broadcast channel and without recourse to service-client handshaking. This TPEG application defines: the logical channel, for the transmission of the additional CA information (CAI); how the CAI is linked and synchronized to the scrambled content.

ISO/TS 18234-11:2013 establishes the method of signalling the specific location referencing used by all TPEG1 applications that require detailed location information to be delivered to client devices such as TPEG1-RTM, TPEG1-PTI, TPEG1-TEC or TPEG1-PKI. The TPEG1-Location Referencing Container (TPEG1-LRC) is described as well as how it is used to signal which specific location referencing method is in use for a particular TPEG Message. It is able to handle Location Referencing methods that are external to the present ISO series and the internal location referencing method (TPEG1-LOC) defined in Part 6 of this series.

ISO/TS 18234-3:2013 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.

ISO/TS 18234-8:2012 establishes a method for delivering Congestion and Travel Time Messages within a TPEG service.

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

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-3:2006 establishes the XML encoding of the method of the Road Traffic Message application.

ISO14823:2017 specifies a graphic data dictionary, a system of standardized codes for existing road traffic signs and pictograms used to deliver Traffic and Traveller Information (TTI). The coding system can be used in the formation of messages within intelligent transport systems.

ISO/TS 21219-16:2016 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.

ISO/TS 21219-19:2016 defines the TPEG Weather (WEA) application for reporting weather information for travellers. It provides general weather-related information to all travellers and is not limited to a specific mode of transportation. This application does not provide specific weather-related safety warnings to drivers; these are provided as Safety Related Messages as part of the TPEG2-TEC application. The WEA application provides weather-related forecasts and status information over multiple time periods and for multiple, possibly linked, geographical areas. NOTE The presentation of the information is dependent of the specific HMI of the receiving device. ISO/TS 21219-19 :2016, therefore, does not define any prerequisites for the HMI of the device.

ISO/TS 21219-15:2016 specifies the TPEG application: Traffic Event Compact (TEC). The TEC application has been specifically designed to support information about traffic events (e.g. road works, traffic jams). A specific form of traffic events are local hazard warnings which, being safety-related messages, are sent with high priority to warn a driver that may encounter dangerous situations (e.g. black-ice, accident beyond curves, obstacles on road, etc.) unexpectedly. Generally, the Traffic Event Compact application is designed to allow receivers to - ensure travel safety for the driver, - enable the calculation of alternative routes, - avoid delays (e.g. traffic jams), - warn the driver of obstructions on route, and - provide the driver with information on infrastructural problems (e.g. closed petrol stations, non-functioning emergency telephones).

ISO/TS 21219-14:2016 specifies the TPEG Parking Information application which has been designed to deliver parking information to a variety of receivers using a number of different channels, foremost of course are digital broadcasting and Internet technologies. Parking information may be presented to the user in many different ways, including text, voice, or graphics. Today, traffic congestion has become a serious problem in urban areas. Some traffic congestion is attributed to drivers searching for parking spaces. Therefore, timely provision of parking information could help ease traffic congestion. Furthermore, parking information would be valuable for the visitor, particularly when it could be used to signal where a temporary parking facility is established for a special occasion.

ISO/TS 21219-10:2016 defines the TPEG Conditional Access Information (CAI) application. It allows to protect the content of a TPEG service from unauthorized access. It further supports the management of subscriber information (e.g. Control Words and ECM) on the client devices in order to setup, prolong or revoke a subscription on a given client device. The application defines - the logical channel, for the transmission of the additional CA information (CAI), and - how the CAI is linked and synchronized to the scrambled content. ISO/TS 21219-10:2016 is related to conditional access applied on service component level. It is open for an integration of different conditional access systems. NOTE The basic concept behind the CAI application is to transport CAI in separate TPEG service components of a dedicated application type and to define an SNI table that contains the link between scrambled content and related CAI.

ISO/TS 21219-1:2016 defines an index to the complete set of TPEG Generation 2 toolkit components and applications. New applications are enumerated with an Application Identification (AID) as they are added to the TPEG applications family. ISO/TS 21219-1:2016 will be updated when such developments occur, to indicate the latest status and the inter-working 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. Preliminary AIDs are allocated and managed by TISA and are listed on the TISA homepage www.tisa.org.

ISO/TS 21219-9:2016 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. NOTE 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.