Date: 2025-04-18
ISO/DIS 6029-3:2026(en)
ISO/TC 204/SC /WG 17
Secretariat: ANSI
Intelligent transport systems — Seamless positioning for multimodal transportation in ITS stations — Part 3: Data fusion dataset exchange interfaces on nomadic devices
Élément introductif — Élément central — Partie 3: Titre de la partie
Copyright notice
This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.
Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO's member body in the country of the requester:
[Indicate the full address, telephone number, fax number, telex number, and electronic mail address, as appropriate, of the Copyright Manager of the ISO member body responsible for the secretariat of the TC or SC within the framework of which the working document has been prepared.]
Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
Contents Page
4 Symbols and abbreviated terms 2
5.1.1 Positioning use cases in multiplex spaces 4
5.2 Positioning data assistance framework 4
5.2.1 Data flows in the positioning data assistance framework 5
5.2.2 Multiplex environments and application scenarios 6
5.3 Scalability and extensibility 7
5.3.3 Key features supporting scalability and extensibility 7
5.3.4 Challenges and considerations 8
6.1.2 Environmental and sensor limitations 10
6.1.3 Data validation and integrity check requirements 10
6.2 Positioning data request and response message 10
6.2.1 Position assistance request (PAR) message 10
6.2.2 Sensor-specific limitations and and ITS-assisted mitigation strategies 11
6.2.3 Network-level risks and mitigation strategies 13
6.2.4 Error mitigation strategy 13
6.3 Data format and secure transmission protocol 14
6.3.3 Guidelines for selecting a secure transport protocol 14
6.3.4 Data field-level validation and integrity check 15
6.3.5 Validation mechanisms 15
6.4 Multi-layered data integrity, trust verification, and validation 16
6.4.2 Multi-level validation framework 16
6.4.3 Positioning data authentication mechanisms 16
6.4.4 Secure transmission and storage 17
6.5 Requirements and sensors 17
6.5.2 Requirements and sensors 17
6.5.3 Standardized data format (ISO 6029-2 Compliance) 18
6.5.4 Common dataset transformation 18
6.5.5 Common dataset undergoes multi-layered validation 19
6.6 Accuracy and reliability in sensing data transmission 19
6.6.2 Error factors affecting positioning accuracy 19
6.6.3 Confidence-based accuracy assessment 20
6.6.4 Reliability of sensing data transmission 20
6.7 Authentication in data exchange 21
6.7.1 Objectives of authentication 21
6.7.2 Authentication mechanisms 21
6.7.3 Secure communication protocols 22
6.7.4 Certificate management 22
6.7.5 Alignment with ITS standards 22
6.7.6 Implementation considerations 22
7 Error handling and recovery 23
7.2.1 Sensor-specific errors: 23
7.4 Sensor consistency checks 24
7.4.1 Cross-sensor validation (B.3.1) 24
7.4.2 Error detection through consistency checks 24
7.4.3 Integration with Annex B 25
7.5.1 Accuracy and latency metrics 25
7.6 Integration with Annex B 25
Annex A (Informative example: Wi-Fi triangulation) 27
A.1 Example: Wi-Fi triangulation for indoor positioning 27
A.1.2 Required data (JSON format) 27
A.2 Error handling and recovery scenarios 29
A.2.1 GNSS signal loss fallback mechanism 29
A.2.2 Multi-sensor validation for redundancy 29
A.3 Secure authentication and data exchange 29
A.3.1 PKI-based positioning data authentication 29
A.3.2 Data transmission security 29
Annex B (Informative example: Reference tables) 31
B.1 Reference data structures 31
B.2 Accuracy and reliability metrics 34
B.2.1 Importance of accuracy and reliability 34
B.2.2 Latency & data transmission thresholds 35
B.2.3 Timestamp integrity checks 35
B.2.4 Cryptographic verification (ETSI TS 102 941 compliance) 35
B.3 Sensor fusion processes and best practices 35
B.3.1 Multi-sensor data fusion 35
B.3.2 Confidence weighting for sensors 36
B.3.3 Error handling in sensor fusion 36
B.3.4 Best practices for sensor fusion 36
B.3.5 Best practices for sensor fusion example use case: Mulit-sensor navigation 36
B.3.6 Challenges and mitigation 37
B.4 Supplementary data validation processes 37
B.4.1 Checksum validation for data integrity 37
B.4.2 Error logging and reporting 38
B.4.3 Positioning data consistency thresholds 38
B.4.4 Real-time data correction mechanisms 38
B.4.5 Integration with Annex A processes 38
B.4.6 Practical guidelines for implementers 38
B.4.7 Alignment with standards 39
Annex C (Implementation guidelines) 40
C.2.1 Standardized data formats: 40
C.2.3 Data interoperability 40
C.3 Key implementation steps 41
C.3.4 Testing and validation 42
C.4.1 Objectives of testing 42
C.4.2 Real-world testing criteria 43
C.4.4 Security & integrity tests 43
C.4.5 Continuous monitoring 44
C.5.1 System performance monitoring 44
C.5.2 Automated error handling 44
C.5.3 Feedback integration and continuous learning 44
C.5.4 Incorporation of emerging technologies 44
C.5.5 Documentation updates 45
C.5.6 Metrics for improvement 45
C.7 Error handling and recovery mechanisms 45
C.8 Interoperability with other standards 45
D.1 Error sources and mitigation 47
D.2 Latency and accuracy target value 47
D.3 Sensor capability matrix 47
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.
Annex A 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).
Annex B 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).
Annex C Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
Annex D For an explanation of the voluntary nature of standards, 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 www.iso.org/iso/foreword.html.
Annex E This document was prepared by Technical Committee ISO/TC 204, Intelligent Transport Systems (ITS), Working Group WG 17, Nomadic Devices in ITS Systems.
Annex F Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html.
Introduction
Positioning systems in Intelligent Transport Systems (ITS) must provide reliable and accurate data across diverse environments, particularly in multiplex scenarios where indoor and outdoor boundaries are indistinct. This challenge was first identified in ISO/TR 6029-1:2024, which established the fundamental concepts of seamless positioning and use cases across multiple transportation modes.
ISO 6029-2:2024 further extended these concepts by defining the standardized dataset required for accurate location determination across different ITS domains, including vehicle-based stations (V-ITS-S), infrastructure-based stations (R-ITS-S), and nomadic personal devices (P-ITS-S). Specifically, ISO 6029-2 provides a structured methodology for sensor data fusion, outlining how GNSS, Wi-Fi, IMU, LiDAR, and other sensor modalities contribute to robust positioning.
Building upon these foundations, this document specifies the concrete implementation of data exchange interfaces that enable sensor fusion across ITS domains. The primary goal is to ensure that positioning data generated from different ITS stations can be securely transmitted, verified, and integrated into a unified location framework, reducing dependency on a single sensor type and mitigating the impact of signal obstructions. By leveraging the dataset structures and standardization mechanisms defined in ISO 6029-2, this document ensures compatibility and interoperability between nomadic devices and other ITS stations.
Figure 1 illustrates how the standardized PVT data from ISO 6029-2 is transmitted through the interfaces defined in ISO 6029-3, allowing nomadic devices to retrieve validated location estimates from nearby V-ITS-S or R-ITS-S stations.
The core concept of this document is enabling Nomadic Devices to utilize confirmed PVT data from Vehicle ITS Stations (V-ITS-S) and Roadside ITS Stations (R-ITS-S). These ITS stations, equipped with accurate positioning systems, provide authenticated PVT data, which the Nomadic Device can use to determine its own location when internal sensors are unavailable or unreliable. By calculating relative distances and directions to these ITS stations, the Nomadic Device can accurately estimate its position.
As illustrated in Figure 1, a Nomadic Device that cannot determine its location independently communicates with nearby ITS stations to retrieve their authenticated positioning data. For example, a Nomadic Device may determine that it is located 3 meters north of a V-ITS-S. Using the V-ITS-S's confirmed positioning coordinates as a reference, the Nomadic Device calculates its own coordinates. This approach ensures consistent and accurate positioning in environments such as urban canyons, tunnels, or multiplex areas like shopping malls and underground parking facilities.
The architecture outlined in this document builds on the foundational concepts defined in ISO/TR 6029-1 and ISO 6029-2, emphasizing cross-domain data integration and the effective utilization of confirmed PVT data for seamless positioning.
Figure 1 Position Estimation Using Authenticated PVT Data from Nearby ITS Domains
Key
1 The figure depicts how a Nomadic Device interacts with nearby ITS domains, such as RSUs (Roadside Units), V-ITS-S, and R-ITS-S, to retrieve and integrate authenticated PVT data for seamless positioning
2 Confirmed coordinates from ITS stations act as reference points for estimating the Nomadic Device's location, ensuring reliability and accuracy
Figure 1 — Position estimation using authenticated PVT data from nearby ITS domains
ISO 6029 consists of the following parts, under the general title Intelligent transport systems – Seamless positioning for multimodal transportation in ITS stations:
— Part 1: General information and use case definition
— Part 2: Nomadic & mobile device dataset for positioning data fusion
— Part 3: Data fusion dataset exchange interfaces on nomadic devices
Intelligent transport systems — Seamless positioning for multimodal transportation in ITS stations — Part 3: Data fusion dataset exchange interfaces on nomadic devices
1.0 Scope
This document specifies procedures and data exchange format interface(s) between sensor fusion actors in P-ITS-S (nomadic device), V-ITS-S, R-ITS-S and C-ITS-S for seamless positioning by nomadic device.
This document defines the process for coordinating and sharing PVT datasets among ITS components, including P-ITS-S, V-ITS-S, R-ITS-S, and C-ITS-S, for each specific use case.
This document does not provide data security and authentication protocols.
2.0 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/TR 6029‑1:2024, Intelligent transport systems — Seamless positioning for multimodal transportation in ITS stations — Part 1: General information and use case definition
ISO 21217, Intelligent transport systems — Station and communication architecture
ISO/TS 21184, Cooperative intelligent transport systems (C-ITS) — Global transport data management (GTDM) framework
ISO 13400‑2:2019, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 2: Transport protocol and network layer services
ISO 17423:2018, Intelligent transport systems — Cooperative systems — Application requirements and objectives
3.0 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TR 6029-1, ISO 21217, ISO/TS 21184, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
cross-domain positioning
the process of determining a position using data from multiple ITS domains, such as Nomadic Devices (P-ITS-S), Vehicles (V-ITS-S), and Infrastructure (R-ITS-S).
Note 1 to entry: This process allows seamless positioning in multiplex environments, especially when standalone sensors or GNSS data are insufficient.
3.2
multiplex environment
an environment where the boundaries between indoor and outdoor areas are interconnected or indistinct, requiring positioning systems to operate seamlessly across both contexts.
Example: shopping malls, underground parking areas connected to urban streets.
3.3
positioning data authentication
the process of verifying the accuracy and reliability of positioning data exchanged between ITS domains. This ensures PVT data used in cross-domain positioning is trustworthy and secure.
3.4
position assistance data
PAD
external data provided to enhance or correct the accuracy of position estimation, typically sourced from GNSS corrections, sensor data, or other ITS devices, to improve the reliability and precision of location determination systems.
3.5
position assistance request
PAR
a request sent by a positioning system (P-ITS-S) to external sources (ie, V-ITS-S, R-ITS-S) for assistance in improving the accuracy of position estimation, typically by providing data such as GNSS corrections, sensor inputs, or other relevant positioning information
3.6
position data assistance framework
PDAF
a structure which facilitates the exchange of position assistance data between devices and external sources, such as ITS stations, to improve the accuracy and reliability of position estimation
3.7
reliability score
an evaluation metric that indicates how consistent and accurate the data source or system is, based on the frequency of errors and the stability of the data provided
3.8
confidence level
the degree of certainty that a specific estimate or prediction is accurate, indicating the result matches the actual value
3.9
trust score
a composite score that assesses the reliability of data based on multiple factors such as source reliability, timestamp freshness, and signature validity, providing an overall evaluation of the data’s trustworthiness
4.0 Symbols and abbreviated terms
4.1 Symbols
— | empty table cell or feature undefined |
4.1.1 Abbreviated terms
AES | advanced encryption standard |
API | application programming interfaces |
ASN.1 | abstract syntax notation one |
BLE | bluetooth low energy |
CBOR | concise binary object representation |
CEP | circular error probable |
CR | common repository |
CRL | certificate revocation list |
FLV | field-level validation |
GNSS | global navigation satellite system |
GPS | global positioning system |
GTDM | global transport data management |
HMAC | hash-based message authentication code |
HTTP | hypertext transfer protocol |
IMU | inertial measurement unit |
IP | internet protocol |
ITS | intelligent transport system |
JSON | JavaScript object notation |
JWT | JSON web token |
MQTT | message queuing telemetry transport |
ND | nomadic device |
PAD | position assistance data |
PAR | position assistance request |
PDAF | positioning data assistance framework |
PKI | public key infrastructure |
PVT | position, velocity, time |
QoS | quality of service |
R-ITS-S | roadside intelligent transport system station |
RSSI | received signal strength indicator |
TLS | transport layer security |
UDP | user datagram protocol |
UUID | universal unique identifier |
UWB | ultra-wide band |
V-ITS-S | vehicle intelligent transport system station |
V2X Wi-Fi | vehicle-to-everything communication wireless fidelity |
5.0 System architecture
5.1 Overview
Intelligent Transport Systems (ITS) require a robust and adaptable positioning framework to ensure reliable and seamless location tracking across diverse environments.
ISO/TR 6029-1 provides the fundamental concept of seamless positioning, while ISO 6029-2 specifies the structured methodology for sensor fusion and common dataset formats to support interoperability among different positioning technologies.
Building upon these foundations, this document defines the system architecture for leveraging external positioning data when a nomadic device (P-ITS-S) experiences events such as sensor failures, signal obstructions, or insufficient sensor availability.
This system architecture introduces the positioning data assistance framework (PDAF), which enables P-ITS-S to request and receive external positioning data from other ITS domains (V-ITS-S, R-ITS-S, and other P-ITS-S) to maintain accurate location estimates.
This system architecture ensures that nomadic devices can continuously estimate their location even when they are unable to do so independently.
5.1.1 Positioning use cases in multiplex spaces
In highly dynamic ITS environments, multiple positioning sources must be utilized to ensure accuracy. Common use cases include:
— Indoor navigation: Switching from GNSS-based positioning to Wi-Fi AP or UWB-based positioning when entering a building or tunnel.
— Urban canyons: GNSS multipath effects are mitigated using Wi-Fi RSSI-based triangulation.
Note: An urban canyon is a place where the street is flanked by buildings on both sides creating a canyon-like environment. In urban canyon environments, the GNSS multipath effect causes difficulties in positioning.
— Low visibility conditions: LiDAR and UWB provide alternative positioning when optical sensors (i.e. vision sensor) fail.
— Multiplex environments: In scenarios where vehicles and infrastructure communicate dynamically, multiple position sources (GNSS, Wi-Fi, UWB, IMU, and LiDAR) are integrated to enhance resilience against signal loss and multipath effects. This is particularly crucial in multi-layered urban landscapes and enclosed transport hubs (e.g., subway, multi-level parking facilities).
5.2 Positioning data assistance framework
The positioning data assistance framework (PDAF) is designed to:
— Detect sensor failures or positioning performance degradation in a P-ITS-S.
— Request external assistance from available ITS stations.
— Validate and authenticate alternative positioning data using ISO 6029-2's Common Dataset format.
— Securely transmit and integrate external data into the P-ITS-S location processing system.
The overall architecture is illustrated in Figure 2, which details the flow of data within the framework.
Figure 2 — PDAF and data exchange with ITS domains
5.2.1 Data flows in the positioning data assistance framework
The positioning data assistance framework (PDAF) process follows these key steps:
1. Sensor failure detection:
— The P-ITS-S continuously monitors GNSS availability, IMU drift, and Wi-Fi signal strength.
— If positioning degradation is detected, the device triggers a Position Assistance Request (PAR).
2. Request handling and data retrieval:
— The PDAF queries nearby ITS stations (V-ITS-S, R-ITS-S, and other P-ITS-S devices) to obtain positioning data.
— The ITS station that receives the PDAF query responds with positioning data, reliability scores, and confidence levels.
3. Data validation:
— The received positioning data shall be checksum verified according to ISO 6029-2, 6.4.5.
— A trustworthiness evaluation shall be performed using confidence scoring algorithms. (6.3.5)
4. Position computation and application:
— The best match external position estimate is selected.
— The updated position is applied to the P-ITS-S position applications.
— The P-ITS-S resumes normal operation using externally validated data.
Figure 2 describes how a nomadic device (P-ITS-S) can maintain its positioning accuracy even when it cannot rely on its own onboard sensors (GNSS, IMU, Wi-Fi, etc.). The process follows the positioning data assistance framework (PDAF) to retrieve, validate, and apply external positioning data
| Step 1: Failure detection (P-ITS-S) | ||
| — GNSS signal lost (e.g., tunnel, underground parking, urban canyon) | ||
| — IMU drift too high (e.g., long travel without GNSS correction) | ||
| — No Wi-Fi AP coverage (e.g., open rural area with no connectivity) | ||
| Step 2: Request external positioning assistance (ITS PDAF) | ||
| — ITS Positioning data assistance framework (PDAF) is activated: | ||
| — P-ITS-S queries nearby ITS stations (V-ITS-S, R-ITS-S, and other P-ITS-S devices) | ||
| — The system collects available positioning data from external sources | ||
| — Data reliability and trust scores are calculated. | ||
| — The framework computes an estimated position for P-ITS-S based on trusted sources. | ||
| Step 3: External ITS positioning data sources | ||
| — Vehicle ITS station (V-ITS-S) | ||
| — Provides high-precision GNSS (RTK) corrections | ||
| — Shares vehicle motion data to assist in nomadic device positioning. | ||
| — Enables crowd-sourced positioning when multiple vehicles report similar locations. | ||
| — Roadside ITS station (R-ITS-S) | ||
| — Offers infrastructure-based GNSS corrections. | ||
| — Uses UWB (Ultra-Wideband) for high-accuracy short-range positioning. | ||
| — Integrates with smart road sensors and traffic data for location reference. | ||
| — Other P-ITS-S devices | ||
| — Uses Peer-to-Peer Position Exchange to estimate relative position. | ||
| — Employs Bluetooth & Wi-Fi Direct to share location data in real-time | ||
| Step 4: Data validation & transmission (ISO 6029-2 common dataset) | ||
| — The collected external positioning data is validated using: | ||
| — Standardized position data format (as defined in ISO 6029-2). | ||
| — Timestamp & Confidence Score Calculation. | ||
| — Source Authentication & Data Security (PKI-based). | ||
| — The validated data is securely transmitted via: | ||
| — MQTT (Message Queuing Telemetry Transport) | ||
| — HTTPS Secure Transmission | ||
| Step 5: Position update & restoration (P-ITS-S) | ||
| — nomadic device (P-ITS-S) successfully restores its position using: | ||
| — External GNSS alternative data | ||
| — Confidence-scored positioning data | ||
| — Securely verified ITS data exchange | ||
| Seamless positioning is maintained, allowing the device to function as if GNSS had never been lost. | ||
5.2.2 Multiplex environments and application scenarios
a) Indoor/ outdoor transition:
— Evaluates GNSS signal quality, Wi-Fi AP data, and Bluetooth/UWB signals to distinguish between indoor and outdoor environments.
— Example: In a shopping mall, Wi-Fi-based triangulation is used to determine the device's floor and position.
b) Dynamic environments:
— Urban canyons or tunnels with GNSS signal degradation rely on R-ITS-S or collaborative P-ITS-S data for accurate positioning.
c) Historical context integration:
— Example: After exiting a vehicle, nomadic device references the vehicle’s last confirmed position and adjusts based on subsequent movement.
5.3 Scalability and extensibility
This document architecture is designed to accommodate evolving transportation needs by supporting scalable and extensible systems. This section outlines how architecture ensures adaptability to new technologies, sensors, and data requirements while maintaining interoperability with existing standards.
5.3.1 Scalability
— Sensor integration:
— The system can accommodate additional sensors, such as ultra-wideband (UWB), environmental sensors, and other future technologies.
— Example: Integration of UWB for precise indoor positioning alongside existing GNSS, Wi-Fi, and IMU data.
— Infrastructure expansion:
— The framework supports scalability in infrastructure, allowing more Roadside ITS Stations (R-ITS-S) and Vehicle ITS Stations (V-ITS-S) to be added without disrupting existing operations.
— Example: A city adding 100 new R-ITS-S units to support a smart city initiative.
— Data volume handling:
— The architecture is built to handle increasing data volumes as more devices and sensors are integrated into the system.
— Example: A single P-ITS-S device processing data from 10+ sensors simultaneously.
5.3.2 Extensibility
The architecture's extensibility ensures that new technologies and data formats can be integrated seamlessly:
— Common dataset standardization:
— The system uses a standardized common dataset format, ensuring that new data fields (e.g., additional confidence metrics) can be incorporated without requiring major changes to the core framework.
— Example: Adding a new "signal stability" field to the existing common dataset.
— Interoperability with emerging standards:
— The system is designed to align with evolving standards, such as AI-enhanced data fusion and next-generation communication protocols like 5G.
— Example: Leveraging 5G for faster data exchange between P-ITS-S and R-ITS-S.
— Dynamic configuration:
— Devices can dynamically adapt to different configurations, such as switching between GNSS and Wi-Fi positioning based on environmental conditions.
— Example: A P-ITS-S device automatically prioritizing LiDAR data in dense urban environments.
5.3.3 Key features supporting scalability and extensibility
— Modular design:
— Components such as sensor modules and data exchange protocols are modular, enabling easy upgrades and replacements
— Future-proofing:
— The architecture is built with flexibility to incorporate future technologies, minimizing the risk of obsolescence.
— Backward compatibility:
— The system ensures compatibility with legacy ITS devices and data formats, facilitating smooth transitions during upgrades.
5.3.4 Challenges and considerations
— Performance optimization:
— Increasing the number of sensors or data sources may impact processing time and network bandwidth.
— Mitigation: Use of advanced data compression techniques and edge computing.
— Future-proofing:
— Aligning with future standards may require additional effort in certification and validation processes.
— Mitigation: Regular updates to certification processes and compliance with established standards such as ISO 21217.
Figure 3 — Scalability and extensibility framework
6.0 Data exchange interface
6.1 Purpose and objectives
To ensure seamless positioning across indoor and outdoor environments, the integration of GNSS, Wi-Fi, IMU, and other sensors is essential. The standardized data exchange interfaces defined in this document facilitate multi-sensor collaboration, robust validation, and interoperability, enabling accurate and reliable positioning even in challenging environments.
The data exchange interface in this document defines how a Nomadic Device (P-ITS-S) requests and processes positioning assistance from external ITS stations (V-ITS-S, R-ITS-S, and other P-ITS-S devices).
This interface ensures seamless communication between ITS entities, enabling the Positioning data assistance framework (PDAF) to provide accurate and reliable location data when P-ITS-S experiences sensor failures, communication loss, or degraded GNSS signals*
The exchange process follows the principles established in ISO 6029-2, ensuring compatibility with standardized position, velocity, and time (PVT) datasets, and enabling multi-sensor fusion for accurate positioning.
Key aspects of this data exchange mechanism include:
— Structured request and response messages, ensuring consistent and interpretable data exchange between P-ITS-S and ITS stations.
— Secure communication protocols (MQTT with TLS 1.3, HTTPS with JWT authentication) to prevent unauthorized access and data manipulation.
— Data validation mechanisms, including cryptographic PKI-based authentication, checksum verification, and confidence scoring to ensure reliability and trustworthiness.
— Support for multiple positioning data sources, including GNSS, RTK, Wi-Fi AP triangulation, Bluetooth beacons, and UWB-based positioning for seamless indoor-outdoor transition.
This chapter provides a detailed explanation of the position assistance request (PAR) and position assistance data (PAD) message formats, the communication protocols used for transmission, and the security mechanisms employed to ensure data integrity. The response to PAR is replaced by position data collected.
For a structured overview of the key features, message structure, and message format used in the data exchange process, refer to Sections 6.1.1 - 6.1.3.
6.1.1 Key features
a) Accuracy and reliability:
— Positioning data must be precise and consistent, especially in environments where GNSS signals are weak or unavailable, such as tunnels, urban canyons, or parking garages.
— Validation mechanisms (e.g., checksum, confidence, and timestamp synchronization) ensure the integrity of exchanged data.
b) Seamless indoor-outdoor transitions:
— Data exchange interfaces support positioning across environments with varying signal availability by leveraging multiple sensors (GNSS, Wi-Fi, IMU, LiDAR, Vision).
— Example:
— Transitioning from outdoor GNSS-based positioning to indoor Wi-Fi triangulation with minimal loss in accuracy.
c) Interoperability across ITS stations:
— Standardized interfaces enable effective communication between nomadic devices (P-ITS-S), vehicle-mounted stations (V-ITS-S), and fixed roadside stations (R-ITS-S).
— Example:
— R-ITS-S provides pre-registered Wi-Fi AP coordinates for indoor positioning to P-ITS-S devices.
6.1.2 Environmental and sensor limitations
— Environmental limitations:
— GNSS signals may be unavailable or weak in certain scenarios:
— Indoor environments: GNSS signals degrade significantly, requiring fallback to Wi-Fi AP or Vision-based systems.
— Urban canyons: Multi-path effects can reduce GNSS accuracy, necessitating data fusion with IMU or LiDAR.
— Example: A P-ITS-S device uses Wi-Fi triangulation in a shopping mall where GNSS signals are obstructed.
— Sensor limitations:
— Individual sensor reliability may vary:
— IMU: Susceptible to drift over time.
— Wi-Fi: Affected by signal interference or sparse AP density.
— GNSS: Impacted by signal blockage or atmospheric disturbances.
— Mitigation:
— Sensor data fusion reduces individual sensor weaknesses by combining complementary inputs.
6.1.3 Data validation and integrity check requirements
— Checksum validation:
— All exchanged data packets include a checksum to ensure integrity during transmission.
— Example: GNSS data transmitted from V-ITS-S to P-ITS-S includes a checksum field for verification.
— Confidence metrics:
— Each dataset includes a confidence level to indicate the reliability of the positioning information.
— Example: Wi-Fi triangulation outputs a confidence score based on the number of APs and their signal strength.
— Timestamp synchronization:
— Data from multiple sensors are aligned using ISO 8601-compliant timestamps to avoid latency-induced errors.
— Example: Fusion of GNSS and IMU data is performed within a synchronized time window.
6.2 Positioning data request and response message
The P-ITS-S initiates a position assistance request (PAR) message when it detects sensor failures or positioning degradation.
Neighboring ITS stations that received the PAR message respond with position assistance data (PAD) message, structured according to the ISO 6029-2 common dataset format.
6.2.1 Position assistance request (PAR) message
The P-ITS-S sends a PAR message to nearby ITS stations, containing:
— Device ID (P-ITS-S Identifier)
— Current location (optional)
— Detected sensor failures (GNSS signal loss, IMU drift, etc.)
— Requested positioning data types (GNSS, Wi-Fi, RTK, UWB, etc.)
— Timestamp and digital signature
— Example of a PAR message in JSON
{ "deviceId": "PITS-123456", "currentLocation": { "latitude": null, "longitude": null, "accuracy": null }, "sensorFailures": ["GNSS_Lost", "IMU_Drift"], "requestedDataTypes": ["GNSS", "WiFi_AP", "RTK"], "timestamp": "2025-01-30T12:34:56Z", "signature": "base64_encoded_signature" } |
6.2.2 Sensor-specific limitations and and ITS-assisted mitigation strategies
Each sensor type used in positioning systems has inherent limitations that can affect accuracy, reliability, or availability of data. These limitations must be understood to design robust and seamless positioning solutions.
Nomadic Devices (P-ITS-S) rely on multiple onboard sensors to determine their position. However, each sensor has inherent limitations that can impact positioning accuracy in certain environments.
To mitigate these challenges, positioning data assistance framework (PDAF) in this document allows P-ITS-S to request external data from ITS stations (V-ITS-S, R-ITS-S, or nearby P-ITS-S devices).
This section outlines the limitations of each sensor type and the corresponding positioning assistance strategies.
a) GNSS (Global Navigation Satellite System)
— Limitations:
— Canyon & tunnel issues: GNSS signals are blocked or reflected in tunnels, underpasses, and dense urban areas
— Multipath interference: Satellite signals reflect off buildings, causing position errors.
— High latency in cold start: GNSS may take several seconds to acquire a lock after signal loss.
— Mitigation via positioning assistance:
— RTK correction from V-ITS-S: Nearby vehicles with RTK GNSS can provide differential corrections
— R-ITS-S GNSS reference: Roadside stations transmit stable GNSS reference data to assist positioning
— Crowd-sourced positioning data: Other P-ITS-S devices with stable GNSS data share their location for relative positioning
b) IMU (Inertial measurement unit)
— Limitations:
— Drift over time: IMU-based positioning accumulates errors over time without external correction
— No absolute positioning: IMU provides relative movement but lacks absolute location reference.
— High sensitivity to calibration: Incorrect calibration can lead to significant drift errors
— Mitigation via positioning assistance:
— Fusion with GNSS data: IMU data is periodically corrected using GNSS signals from V-ITS-S or R-ITS-S.
— Vehicle sensor integration: If a P-ITS-S is inside a vehicle, V-ITS-S can provide wheel speed and acceleration data for improved accuracy
— AI-based IMU drift correction: Machine learning models applied to large datasets from multiple ITS stations improve drift compensation
— Constraints
— Drift Accumulation: IMU-based dead reckoning accumulates errors over time.
— Correction Methods: Requires periodic correction via GNSS or external signals.
c) Wi-Fi access points (AP):
— Limitations:
— Limited coverage: Wi-Fi AP-based positioning is unavailable in open rural areas
— Dynamic AP environment: Public Wi-Fi APs frequently change locations, reducing reliability
— Variability: Position accuracy depends on AP density and signal strength fluctuations
— Mitigation via positioning assistance:
— Hybrid GNSS-Wi-Fi positioning: P-ITS-S uses GNSS when available and switches to Wi-Fi positioning indoors
— AP database from R-ITS-S: Roadside infrastructure provides an updated list of active Wi-Fi APs for accurate positioning
— BLE and Wi-Fi direct from other P-ITS-S: Peer-to-peer (P2P) device communication enables real-time location sharing.
d) LiDAR (Light detection and ranging) & vison-based sensors
— Limitations:
— Weather sensitivity: Fog, rain, and dust reduce LiDAR performance.
— Overhead: Processing LiDAR point clouds is resource-intensive..
— Dependence on known environments: LiDAR localization works best when pre-mapped environmental data is available
— Mitigation via positioning assistance:
— Cloud-based mapping from R-ITS-S: Roadside stations store real-time 3D environmental data for LiDAR corrections.
— Vision-LiDAR fusion from V-ITS-S: Vehicles share processed LiDAR and camera data with P-ITS-S for scene understanding.
— UWB support for indoor positioning: When LiDAR is ineffective, UWB (Ultra-Wideband) positioning from R-ITS-S can serve as a fallback
e) Cellular & UWB-based positioning
— Limitations:
— Cellular tower triangulation: Highly dependent on network density and signal strength
— UWB range constraints: Effective only within short-range environments (e.g., 10-50 m indoors).
— Mitigation via positioning assistance:
— 5G RTK assistance from R-ITS-S: High-precision 5G-based positioning data assists P-ITS-S
— UWB integration with infrastructure: Smart infrastructure supports seamless transition between GNSS and UWB-based positioning
— Multi-sensor fusion from nearby devices: Combining UWB with GNSS and IMU from other P-ITS-S improves accuracy
f) Odometer
— Limitations:
— Cumulative error in long distances: Odometer-based dead reckoning accumulates errors over extended distances if not corrected
— Surface & tire slip impact: Tire slippage, changes in road surface conditions, or uneven terrain affect accuracy
— No absolute positioning reference: The odometer provides only relative distance traveled, requiring external data for absolute positioning
— Mitigation via positioning assistance:
— GNSS-based distance calibration: Periodic GNSS updates from V-ITS-S or R-ITS-S correct accumulated errors
— Sensor fusion with IMU & GNSS: Combining odometer readings with IMU motion data and GNSS improves accuracy.
— Vehicle sensor integration from V-ITS-S: Vehicles equipped with wheel encoders and advanced traction control systems provide real-time corrected distance data.
— Crowd-sourced odometer correction: P-ITS-S devices inside vehicles share odometer-based distance data, improving error correction through comparative analysis.
— Constraints
— Independent of IMU: While both track movement, odometer measures wheel rotations.
— Error factors: Terrain type and tire wear affect accuracy.
— Correction methods: Kalman filtering with GNSS data improves reliability.
6.2.3 Network-level risks and mitigation strategies
a) Network delays:
— Cause: Latency in transmitting PVT data impacts real-time usage.
— Mitigation: Implement QoS protocols like MQTT with priority streaming.
b) Packet loss:
— Cause: Unstable connections or overloaded networks.
— Mitigation: Retransmission policies and redundancy mechanisms.
c) Data synchronization errors:
— Cause: Timestamp mismatches between sensors during data fusion.
— Mitigation: Use ISO 8601-compliant synchronized timestamps
6.2.4 Error mitigation strategy
Table 1 — Error mitigation strategy
Error cause | Impact | Mitigation strategy |
GNSS multi-path | Position shifts in urban areas | Combining with IMU or vision systems |
Sparse Wi-Fi APs | Reduced indoor positioning accuracy | Increase AP density or fallback to IMU |
Sensor drift (IMU) | Cumulative error over time | GNSS-based recalibration |
Network latency | Real-time delays | Use QoS-based communication protocols |
Timestamp mismatch | Data fusion errors | Synchronize using ISO 8601-compliant time |
6.3 Data format and secure transmission protocol
6.3.1 Overview
To ensure seamless interoperability between ITS stations, the positioning data exchanged between P-ITS-S, V-ITS-S, and R-ITS-S must adhere to a standardized format and be transmitted securely.
This section defines the data format structure based on ISO 6029-2 and outlines the secure transmission protocols (MQTT, HTTPS, PKI-based encryption) used to protect data integrity.
6.3.2 PAD format
Position assistance data (PAD) messages exchanged between ITS entities follow the ISO 6029-2 common dataset structure, ensuring compatibility across different communication interfaces.
Supported data encoding formats:
— JSON: Used for high-level ITS applications and cloud-based data exchange.
— ASN.1 (Abstract syntax notation one): Optimized for low-latency and binary-efficient encoding in V2X communications.
Example of a PAD message in JSON format
{ "sourceId": "VITS-789456", "positionData": { "latitude": 37.7749, "longitude": -122.4194, "altitude": 12.5, "accuracy": 2.3, "confidenceScore": 95 }, "dataSources": ["GNSS", "RTK"], "timestamp": "2025-01-30T12:34:58Z", "trustScore": 4.8, "signature": "base64_encoded_signature" } |
6.3.3 Guidelines for selecting a secure transport protocol
To protect data integrity, ensure authentication, and prevent malicious data injection or spoofing attacks, this document recommends the use of secure communication protocols for Position Assistance Data Exchange:
— MQTT over TLS 1.3
— Message Integrity & Authentication: Each message is signed using PKI-based authentication.
— QoS Level 2 (Exactly once): Ensures reliable data exchange with ITS stations.
— Session encryption: Uses TLS 1.3 with Perfect Forward Secrecy (PFS) for securing all transmissions.
— HTTPS with JWT Authentication
— Mutual TLS (mTLS): Requires bidirectional authentication between P-ITS-S and ITS servers.
— JSON web token (JWT) authentication: Ensures only authorized devices can request and receive positioning data.
— End-to-end encryption: All HTTPS transmissions are encrypted to protect positioning data against interception.
6.3.4 Data field-level validation and integrity check
Validation mechanisms ensure that data exchanged between ITS stations is accurate, reliable, and consistent. These mechanisms include:
To ensure the reliability of transmitted positioning data, data field-level validation (FLV) is performed on each PAD message.
Each data on a PAD message is verified for format compliance, value range, and logical consistency before integration.
Table 2 — Field-level validation criteria
Field | Validation criteria |
Latitude, Longitude | Must be within valid geographic range (-90 to +90, -180 to +180) |
Altitude | Must be a positive number (or null for unknown) |
Accuracy | Must be > 0 and within expected device error range |
Timestamp | Must be UTC-formatted and within 30s of request time |
Confidence score | Must be between 0-100 % |
6.3.5 Validation mechanisms
In addition to field-level validation (FLV), positioning data undergoes multi-level integrity checks:
— Checksum and hash validation
— SHA-256 Hashing: Verifies the integrity of transmitted data.
— Digital signatures: All messages are cryptographically signed using PKI (Public Key Infrastructure).
— Confidence scoring algorithm
Each PAD message is assigned a confidence score (0-100 %), evaluating:
— Source reliability: GNSS RTK > Wi-Fi AP > Crowd-sourced Data
— Timestamp freshness: Older data has lower confidence.
— Message authentication status: Verified messages receive a higher score.
Example of a PAD message in JSON format:
Confidence score = (Source reliability * 0.5) + (Timestamp freshness * 0.3) + (Signature validity * 0.2) |
6.4 Multi-layered data integrity, trust verification, and validation
6.4.1 Overview
To ensure the authenticity, integrity, and trustworthiness of exchanged positioning data, this document defines multiple layers of validation mechanisms.
6.4.2 Multi-level validation framework
Positioning data validation follows a three-layered verification process:
— Field-level validation (FLV)
— Ensures each data field conforms to the expected format, value constraints, and logical consistency
— Field validation rules are applied before processing PAD messages
— Refer to Section 6.3.4 for detailed validation criteria
— Cryptographic data integrity checks
— SHA-256 hashing** applied to transmitted messages to ensure data integrity
— Public key infrastructure (PKI) based digital signatures for authentication
— Example:
SHA-256 Hash = SHA256(SourceID + PositionData + Timestamp) Digital Signature = Sign(SHA-256 Hash, Private Key) |
— Confidence-Based Positioning Data Trust Score
Each position assistance data (PAD) message is assigned a confidence score (0-100 %), considering:
— Source reliability (e.g., GNSS RTK > Wi-Fi AP > Crowd-sourced data)
— Timestamp freshness (Older data has lower confidence)
— Authentication status (Digitally signed and verified messages receive higher trust)
— Example Trust score calculation formula:
Trust score = (Source reliability * 0.5) + (Timestamp freshness * 0.3) + (Signature validity * 0.2) |
6.4.3 Positioning data authentication mechanisms
To prevent unauthorized access, this document mandates PKI-based authentication for all positioning data assistance (PDAF) messages.
— PKI digital signature validation
— Each ITS station (P-ITS-S, V-ITS-S, R-ITS-S) is issued a unique cryptographic key pair.
— Sent messages are digitally signed using private keys.
— Receiving stations verify message authenticity using public keys.
— JSON web token (JWT) authentication
— Each P-ITS-S device must authenticate using JWT tokens to request external positioning assistance.
— Example JWT payload for a positioning request (JSON):
{ "deviceId": "PITS-123456", "permissions": ["Position_Assistance"], "issuedAt": "2025-01-30T12:34:56Z", "signature": "base64_encoded_signature" } |
6.4.4 Secure transmission and storage
All validated positioning data must be securely transmitted and stored using encryption mechanisms:
— Secure transmission protocols
— MQTT with TLS 1.3: Prevents unauthorized interception.
— HTTPS with mutual TLS (mTLS): Ensures both sender and receiver authentication.
— End-to-end encryption: All transmitted messages must be encrypted using AES-256.
— Secure data storage
— Blockchain-based immutable logging (Optional): Stores positioning records securely for post-event verification.
— Zero trust security model: Only authenticated and authorized entities can access stored positioning data.
6.5 Requirements and sensors
6.5.1 Overview
The standardized data format defined in this document ensures interoperability between Nomadic Devices (P-ITS-S) and ITS stations (V-ITS-S, R-ITS-S).
This section outlines the required data structures, sensor specifications, and transformation processes necessary for accurate and secure positioning.
6.5.2 Requirements and sensors
This document specifies the **minimum sensor requirements for P-ITS-S to support positioning data assistance framework (PDAF).
Table 3 — P-ITS-S to support positioning data assistance framework (PDAF)
Sensor type | Function in positioning | Limitation | Assistance strategy |
GNSS | Primary positioning source | Signal loss in tunnels, urban canyons | RTK correction from V-ITS-S, fallback to IMU |
IMU | Motion estimation (Dead Reckoning) | Drift over time | GNSS correction, fusion with Odometer |
Odometer | Distance traveled measurement | Tire slip affects accuracy | Vehicle data fusion (V-ITS-S) |
Wi-Fi AP RSSI | | Indoor positioning | Limited coverage, signal variability | R-ITS-S assisted AP positioning |
LiDAR / Vision | High-precision object detection | Affected by weather conditions | Data fusion with external sensors |
UWB (Ultra-Wideband) | Short-range positioning | Range limitations | Integration with smart infrastructure |
The P-ITS-S must be capable of sensor fusion, utilizing multiple positioning data sources to maintain accurate location estimation under degraded conditions.
6.5.3 Standardized data format (ISO 6029-2 Compliance)
The data exchanged between P-ITS-S and ITS stations must adhere to ISO 6029-2’s common dataset format, ensuring structured and secure communication.
The standardized format supports multiple encoding options (JSON for high-level applications, ASN.1 for low-latency systems).
Example PAD message in JSON format:
{ "sourceId": "VITS-789456", "positionData": { "latitude": 37.7749, "longitude": -122.4194, "altitude": 12.5, "accuracy": 2.3, "confidenceScore": 95 }, "dataSources": ["GNSS", "RTK"], "timestamp": "2025-01-30T12:34:58Z", "trustScore": 4.8, "signature": "base64_encoded_signature" } |
6.5.4 Common dataset transformation
Since different sensors provide positioning data in various formats, a common dataset transformation process is required to unify data representation.
— Example: Wi-Fi triangulation for indoor positioning
— Input: RSSI (Received Signal Strength Indicator) measurements from multiple Wi-Fi Access Points (APs).
— Transformation process: Convert signal strength to distance estimates using path loss models.
— Output: Estimated latitude/longitude in the ISO 6029-2 Common Dataset format.
— Example Wi-Fi triangulation transformation workflow:
| 1) P-ITS-S collects RSSI data from nearby Wi-Fi APs. |
| 2) Signal strength converted into approximate distances using path loss model. |
| 3) Trilateration algorithm calculates estimated position. |
| 4) Position data formatted into ISO 6029-2 compliant message. |
| 5) Validated position transmitted to P-ITS-S navigation system. |
This transformation process enables seamless integration of non-GNSS positioning methods into a standardized dataset.
6.5.5 Common dataset undergoes multi-layered validation
To ensure data consistency across different positioning methods, the common dataset undergoes multi-layered validation(A.1):
— Example: Wi-Fi triangulation for indoor positioning
— Uses standardized format conversions between JSON, ASN.1, and CBOR.
— Data structure normalization ensures seamless integration.
6.6 Accuracy and reliability in sensing data transmission
Ensuring accuracy and reliability in sensing data transmission is essential for nomadic devices (P-ITS-S) to receive high-quality positioning assistance.
This section defines error sources, mitigation strategies, and validation processes to improve the accuracy and trustworthiness of transmitted sensing data.
6.6.1 Overview
Accuracy and reliability are critical for ensuring the seamless operation of ITS applications. This section defines the methods and strategies to enhance these parameters in positioning data transmission.
The key focus areas include:
— Error factors in GNSS, IMU, Wi-Fi, and LiDAR-based positioning
— Correction mechanisms and confidence scoring
— Data transmission reliability (packet loss, latency, and security measures)
6.6.2 Error factors affecting positioning accuracy
Several factors impact the accuracy of positioning data transmission, including environmental conditions, hardware limitations, and transmission errors.
Table 4 — Error factors for position accuracy
Sensor type | Function in positioning | Limitation | Assistance strategy |
GNSS multipath interference | Position deviation (5-50 m) | Urban canyon reflections | RTK correction, multi-constellation GNSS |
IMU drift | Accumulated error over time | Long-duration dead reckoning | Periodic GNSS updates, AI-based drift compensation |
Wi-Fi RSSI variability | Fluctuating position estimates | Indoor positioning with weak signals | AP database calibration, confidence weighting |
LiDAR occlusion | Position loss in blocked areas | Fog, heavy rain affecting sensors | Sensor fusion with alternative inputs |
Transmission packet Loss | Data corruption, incomplete positioning | Unstable network in V2X communication | FEC (Forward Error Correction), QoS management |
Each error source requires specific correction mechanisms to improve the reliability of sensing data.
6.6.3 Confidence-based accuracy assessment
To quantify the accuracy and reliability of received sensing data, a confidence score (0-100 %) is assigned.
— Confidence score calculation factors
— Sensor type reliability: (e.g., GNSS RTK > LiDAR > Wi-Fi Triangulation)
— Data freshness: Older data has lower trust
— Authentication validity: PKI-verified data receives a higher score
— Multi-sensor fusion consistency: Data validated across multiple sensors gains priority.
Example Trust score formula:
Trust score = (Sensor reliability * 0.5) + (Timestamp freshness * 0.3) + (Authentication validity * 0.2) |
6.6.4 Reliability of sensing data transmission
Ensuring high-reliability data transmission is critical for accurate positioning assistance.
— Secure & loss-resistant communication protocols
— MQTT (TLS 1.3, QoS Level 2): Guarantees exactly once delivery for positioning data.
— HTTPS with mutual TLS (mTLS): Ensures end-to-end encryption and authentication
— Latency management
— Edge computing optimization: Processing positioning data closer to the source reduces transmission delays.
— Prioritized data streaming: High-confidence data is given transmission priority.
— Error correction mechanisms
— FEC (Forward error correction): Reduces impact of packet loss in real-time data transmission.
— Redundant data transmission: Positioning data may be transmitted via multiple channels (Wi-Fi + Cellular + V2X)to prevent information loss.
6.7 Authentication in data exchange
6.7.1 Objectives of authentication
Authentication in data exchange is crucial for ensuring trust, integrity, and interoperability between ITS entities. The objectives include:
— Device authorization: Verifying that the requesting device (e.g., P-ITS-S) is authorized to access and exchange positioning data.
— Data provider validation: Ensuring that the source of the data (e.g., V-ITS-S, R-ITS-S) is trustworthy.
— Data integrity: Guaranteeing that data has not been altered or tampered with during transmission.
— Seamless positioning assistance: Providing continuous, verified positioning data when standalone sensors fail
6.7.2 Authentication mechanisms
Several authentication mechanisms are employed to ensure secure communication between ITS stations:
a) Certificate-based authentication:
Authentication in data exchange is crucial for ensuring trust, integrity, and interoperability between ITS entities. The objectives include:
— Device registration: A requesting device submits a certificate request to a trusted certificate authority (CA).
— Certificate issuance: The CA verifies the request and issues an X.509 certificate.
— Validation: Devices validate certificates before initiating data exchange.
— Example certificate format (ASN.1):
Certificate ::= SEQUENCE { deviceID PrintableString, issuer PrintableString, validFrom UTCTime, validTo UTCTime, publicKey BIT STRING } |
b) Token-based authentication
For session-based validation, JSON web tokens (JWT) are utilized. The flow is as follows:
| 1) | A trusted ITS authority issues a JWT token to the requesting device. |
| 2) | The token is attached to all subsequent data requests for authentication. |
| 3) | The receiving station verifies the JWT signature before processing the request. |
— Example JWT format payload:
{ "deviceId": "PITS-123456", "permissions": ["Position_Assistance"], "issuedAt": "2025-01-30T12:34:56Z", "signature": "base64_encoded_signature" } |
6.7.3 Secure communication protocols
To protect data integrity and prevent spoofing, this document mandates secure communication using:
— TLS 1.3 encryption: Ensures secure data transmission over HTTP and MQTT.
— IPSec (Internet protocol security): Provides security for point-to-point data exchanges.
— MQTT over TLS: Secures lightweight messaging between ITS devices.
— DTLS (Datagram TLS): Supports UDP-based secure communications in V2X environments.
6.7.4 Certificate management
Certificates must comply with the ITS PKI framework. The following security mechanisms are implemented:
— Certificate details: Includes device ID, validity period, and cryptographic key.
— Revocation handling: Devices must periodically check for revoked certificates using:
— Certificate revocation lists (CRL)
— Online certificate status protocol (OCSP)
— Key rotation: Periodic renewal of cryptographic keys to mitigate security risks.
6.7.5 Alignment with ITS standards
This authentication framework aligns with the following ITS security standards:
— ISO 21217: ITS station architecture: Defines secure communication roles
— ISO 21177: ITS station services for secure session established and authentication between trusted devices
— ISO/TS 21184: Global transport data management (GTDM): Provides data security guidelines
— ISO/TS 21185: Communication profiles for secure connections between trusted devices
— ETSI TS 102 941: Security mechanisms for ITS communication: Ensures PKI-based authentication for vehicle-to-vehicle and vehicle-to-infrastructure communication.
— ISO 15118: Secure EV charging communication: Explores interoperability with electric vehicle charging infrastructure.
6.7.6 Implementation considerations
— Performance optimization: Reducing latency in cryptographic operations.
— Scalability: Ensuring support for large-scale ITS deployments.
— Interoperability: Aligning with evolving security frameworks such as blockchain-based authentication.
By implementing these authentication mechanisms, ITS stations can ensure a robust and secure data exchange framework, enhancing trust in positioning data and improving the reliability of seamless positioning in smart mobility environments.
7.0 Error handling and recovery
7.1 Recovery mechanisms
To ensure system robustness, the following strategies are implemented:
— GNSS loss handling: Wi-Fi and UWB-based fallback mechanisms.
— IMU drift correction: Adaptive Kalman filter adjustments.
— Network disconnection: Automatic data retransmission using MQTT QoS 2.
7.1.1 Common error scenarios
ITS positioning errors can arise from various sources, broadly categorized as sensor-specific errors and communication errors.(B.2.1)
7.1.2 Sensor-specific errors :
Table 5 — Sensor-specific errors
Error type | Description | Mitigation strategy |
GNSS multipath | Signal reflections in urban areas cause inaccurate position estimates. | Use multi-constellation GNSS with RTK corrections. |
IMU drift | Gradual deviation in sensor data due to accumulated error over time. | Apply AI-based drift correction and GNSS recalibration. |
Wi-Fi RSSI variability | Signal fluctuations affect positioning accuracy in indoor environments. | Use pre-registered Wi-Fi AP databases and confidence-weighted fusion. |
LiDAR occlusion | Blocked LiDAR signals in tunnels or dense environments reduce accuracy. | Complement with alternative sensors like IMU and GNSS. |
7.1.3 Communication errors
Table 6 — Communication errors
Error type | Description | Mitigation strategy |
Network latency | Delayed data transmission affects real-time positioning. | Implement edge computing and 5G ultra-low latency networks. |
Packet loss | Data packets lost in transmission cause incomplete positioning updates. | Use forward error correction (FEC) and redundancy techniques. |
Message format errors | Incorrectly encoded messages (e.g., JSON or ASN.1 issues). | Apply strict schema validation before processing data. |
7.2 Recovery mechanisms
To ensure system resilience, the following recovery mechanisms are implemented (B.3.1):
7.2.1 Retry logic
— Exponential backoff Algorithm: Failed data requests are retried with increasing delay intervals (e.g., 1s, 2s, 4s, 8s).
— HTTP/HTTPS Request Retries: If a request fails, the system retries up to five times before switching to an alternative data source.
— MQTT QoS Level 2: Ensures exactly-once delivery for critical positioning updates.
7.2.2 Fallback mechanisms
Fallback mechanisms provide alternative data sources during primary system failures:
— R-ITS-S or V-ITS-S as Backup Data Sources: If GNSS data is unavailable, Wi-Fi-based positioning from R-ITS-S is used.
— Sensor Substitution: If an IMU sensor fails, data is supplemented with an odometer and GNSS-based dead reckoning.
7.2.3 Real-time monitoring
Real-time monitoring ensures proactive detection and mitigation of issues (B.4.2):
— Continuous Sensor Health Checks: Devices report operational status, and failures trigger alerts.
— Dashboard Integration: Displays real-time system performance and error metrics.
7.3 Sensor consistency checks
To maintain accuracy, data is cross-validated across multiple sensors.
7.3.1 Cross-sensor validation (B.3.1)
Table 7 — Cross-sensor validation
Sensor | Comparison parameter | Validation criteria |
GNSS compared to IMU | Speed and heading consistency | Variance ≤ 2 % over 5-second intervals |
Wi-Fi compared to GNSS | Altitude estimation | Difference ≤ 1,5 meters |
LiDAR compared to Vision | Object detection match | Confidence score ≥ 90 % |
7.3.2 Error detection through consistency checks
— Example: If GNSS reports an altitude of 55,5 m and Wi-Fi AP data suggests 54,0 m, the system applies weighted averaging for a corrected estimate.
7.3.3 Integration with Annex B
— Annex B provides sensor-specific accuracy benchmarks and validation methods.
7.4 Performance monitoring
Ongoing performance evaluation ensures adherence to predefined reliability metrics.
7.4.1 Accuracy and latency metrics
Table 8 — Accuracy target value
Metric | Target value |
GNSS position accuracy (B.2.1) | ≤ 5 meters |
Data transmission latency (B.2.2) | ≤ 100 ms |
Data availability (C.4.2) | ≥ 99,9 % uptime |
7.4.2 Reporting and alerts
— Proactive alerts: System triggers warnings when positioning accuracy falls below threshold.
— Automated reports: Periodic performance summaries highlight key reliability trends.
7.5 Integration with Annex B
The success of these error handling and recovery mechanisms depends on structured reference metrics from Annex B. Integration points include:
— B.2.1 Error sources and mitigation: Classification of error types and best practices.
— B.2.3 Accuracy and reliability metrics: Validation thresholds for data consistency.
— B.3 Sensor fusion and best practices: Multi-sensor fusion guidelines for robustness.
(Informative example: Wi-Fi triangulation)- Example: Wi-Fi triangulation for indoor positioning
Wi-Fi-based triangulation is a widely used technique for indoor positioning, especially when GNSS signals are unavailable. This example describes the integration of Wi-Fi AP-based positioning, BLE (Bluetooth Low Energy), and UWB (Ultra-Wideband) to improve accuracy and reliability.
- Transition scenario
When a vehicle moves from an outdoor to an indoor environment, its positioning system must switch from GNSS-based positioning to Wi-Fi AP and BLE/UWB triangulation-based positioning. This transition is crucial for maintaining positioning accuracy, especially for nomadic devices (P-ITS-S).
— Outdoor → Indoor transition: When GNSS signals degrade, the system switches to Wi-Fi/BLE/UWB positioning.
— Multiple positioning sources: Uses GNSS (if available), IMU, Wi-Fi RSSI, BLE beacons, and UWB to determine the most reliable position.
- Required data (JSON format)
The system requires a dataset that includes access point (AP) details, BLE beacons, and UWB anchor nodes. The structure includes:
{ "sourceId": "PITS-12345", "positioningData": { "wifi": [ {"mac": "A1:B2:C3:D4:E5:F6", "floorLevel": 3, "rssi": -65, "timestamp": "2025-01-30T12:30:00Z", "reliability": 0.8}, {"mac": "A2:B3:C4:D5:E6:F7", "floorLevel": 3, "rssi": -70, "timestamp": "2025-01-30T12:30:00Z", "reliability": 0.75} ], "ble": [ {"uuid": "550e8400-e29b-41d4-a716-446655440000", "rssi": -60, "accuracy": 1.2}, {"uuid": "660e8400-e29b-41d4-a716-446655440111", "rssi": -68, "accuracy": 1.5} ], "uwb": [ {"anchorId": "UWB-001", "distance": 2.3, "confidence": 0.9}, {"anchorId": "UWB-002", "distance": 3.1, "confidence": 0.85} ] }, "timestamp": "2025-01-30T12:30:00Z" } |
- Position calculation
To determine an accurate indoor position, the system applies the following:
— Wi-Fi RSSI distance estimation: Converts RSSI values into approximate distances using path loss models.
— BLE/UWB trilateration: Uses three or more BLE beacons or UWB anchors to estimate position.
— Sensor fusion with IMU: Combines data from accelerometers and gyroscopes for movement correction.
— Example Wi-Fi signal strength to distance conversion (Path loss model)
Distance = 10 ^ ((Reference RSSI - Measured RSSI) / (10 * Path Loss Exponent)) |
— Example BLE/UWB trilateration calculation
(x, y) = Weighted Average (BLE + UWB distances) |
- Example output
Once the system processes Wi-Fi, BLE, and UWB data, it outputs a fused position in JSON format:
{ "position": { "latitude": 37.7749, "longitude": -122.4194, "altitude": 12.5, "accuracy": 1.2, "confidenceScore": 95 }, "source": "Wi-Fi + BLE + UWB Fusion", "timestamp": "2025-01-30T12:34:00Z" } |
- Key considerations
To improve indoor positioning accuracy, the system should:
— Apply weighted filtering: Prioritize Wi-Fi, BLE, or UWB data based on reliability.
— Implement AP database validation: Verify Wi-Fi AP positions to avoid spoofing.
— Use cryptographic verification (X.509): Authenticate positioning sources for security.
— Ensure real-time recalibration: Adjust position estimates dynamically based on movement data.
By integrating Wi-Fi, BLE, and UWB with sensor fusion, this approach enhances indoor positioning accuracy beyond traditional Wi-Fi-only methods.
- Error handling and recovery scenarios
- GNSS signal loss fallback mechanism
- Error handling and recovery scenarios
— If GNSS is lost (e.g., tunnel, underground parking), Wi-Fi triangulation and IMU-based dead reckoning are activated.
— The system requests external positioning data from nearby V-ITS-S or R-ITS-S stations.
- Multi-sensor validation for redundancy
— Cross-checking GNSS, Wi-Fi, and LiDAR ensures consistency.
— Example: If GNSS suggests altitude 50,5 m, but Wi-Fi AP data estimates 49,8 m, the system applies a weighted average.
- Secure authentication and data exchange
- PKI-based positioning data authentication
- Secure authentication and data exchange
To ensure reliable and secure data exchange in ITS environments, PKI-based authentication is used for positioning data validation. Below are real-world examples of authentication in action:
— Use Case: Secure position assistance request
— P-ITS-S (Nomadic device) requests position assistance from an R-ITS-S (Roadside ITS station).
— The R-ITS-S verifies the requester's identity and provides validated positioning data.
— The exchange is secured using PKI-based certificates and digital signatures.
— Example workflow
① Device authentication: The requesting P-ITS-S device presents a signed authentication token.
② Position assistance Request: The device sends a request to the nearest R-ITS-S station.
③ Response validation: The R-ITS-S signs the response with its private key and provides location data.
④ Verification: The P-ITS-S verifies the response using the public key from the PKI infrastructure.
— Each message is digitally signed using PKI (Public key infrastructure) to prevent spoofing.
— Example JWT-Based authentication request:
{ "deviceId": "PITS-123456", "permissions": ["Position_Assistance"], "issuedAt": "2025-01-30T12:34:56Z", "signature": "base64_encoded_signature" } |
- Data transmission security
— MQTT over TLS 1.3: Ensures reliable positioning data exchange.
— Mutual TLS (mTLS) Authentication: Verifies data integrity.
By integrating Wi-Fi, BLE, and UWB with sensor fusion, this approach enhances indoor positioning accuracy beyond traditional Wi-Fi-only methods and ensures interoperability with external positioning data sources.
(Informative example: Reference tables)- Reference data structures
This section defines the standardized formats for positioning data, ensuring consistency across ITS implementations.
- GNSS data
GNSS data serves as the primary source of positioning information for ITS applications. It provides latitude, longitude, and optional altitude values, along with confidence levels and timestamp synchronization.
Table B.1 — GNSS data
Field | Description | Example value | Note |
Latitude | Geographic latitude in degrees | 37.3825 | WGS-84 format |
Longitude | Geographic longitude in degrees | -127.1215 | WGS-84 format |
Altitude | Height above sea level in meters. | 10.5 | Derived using GNSS satellites |
Timestamp | Positional accuracy confidence level. | 2025-01-25T08:31:45Z | ISO 8601 format |
Confidence | ISO 8601 format | 95 % | Calculated using CEP (Circular Error Probable) |
Checksum | Verification code for data integrity. | 0x5F4C8A3B | SHA-256 applied to GNSS data fields |
— GNSS data structure (JSON example)
{ "sourceId": "PITS-12345", "position": { "latitude": 37.7749, "longitude": -122.4194, "altitude": 12.5, "accuracy": 1.2, "timestamp": "2025-01-30T12:34:00Z" }, "checksum": "abc123xyz456" } |
- Wi-Fi AP data
Wi-Fi access points (APs) provide supplementary positioning data, especially in indoor environments. Pre-registered GPS coordinates of APs are used for triangulation.
Table B.2 — Wi-Fi AP data
Field | Description | Example value | Notes |
MAC Address | Unique identifier for the Wi-Fi AP | 00:1A:2B:3C:4D:5E | IEEE 802 format |
Latitude | Geographic latitude of the AP | 37.3827 | Pre-registered GPS coordinates |
Longitude | Geographic longitude of the AP | -127.1218 | Pre-registered GPS coordinates |
Altitude | Height above sea level (if available). | 15.0 | Optional if floor-level information is provided. |
Floor Level | Pre-registered building floor level for the AP. | 5 | Indicates the AP's floor location (e.g., "5th Floor"). |
Signal Strength | Received Signal Strength Indicator (RSSI) | -65 dBm | Used to calculate distance to the AP |
Timestamp | Time of RSSI measurement | 2025-01-25T08:31:45 | Synchronized with GNSS or NTP. |
Confidence | Accuracy confidence of AP location | 98 % | Based on calibration data |
Checksum | Verification code for data integrity | 0x6B3F9D2A | SHA-256 applied to Wi-Fi data fields |
— Wi-Fi AP Data Structure (JSON Example)
WiFiPositioningData ::= SEQUENCE { macAddress PrintableString, floorLevel INTEGER, rssi INTEGER, timestamp UTCTime } |
- Sensor fusion data
Sensor fusion combines multiple data sources (e.g., GNSS, IMU, Wi-Fi) to enhance accuracy and reliability.
Table B.3 — Sensor fusion data
Field | Description | Example value | Notes |
Combined Latitude | Fusion-derived latitude in degrees | 37.7749 | Weighted average from GNSS, Wi-Fi, and IMU. |
Combined Longitude | Fusion-derived longitude in degrees | -122.4194 | Weighted average from GNSS, Wi-Fi, and IMU. |
Combined Altitude | Fusion-derived altitude in meters | 25.0 | Calculated using Wi-Fi floor level or GNSS. |
Floor Level | Fusion-derived building floor level (if available). | 5 | Based on Wi-Fi AP or manual calibration. |
Timestamp | Fusion process completion time | 2025-01-25T08:31:50Z | ISO 8601 format. |
Confidence | Overall fusion accuracy confidence | 99 % | Calculated based on sensor weight and reliability. |
Checksum | Verification code for data integrity | 0x7F4D2B1C | SHA-256 applied to the entire fusion data set. |
— Example (JSON): Sensor fusion data (Multi-sensor)
{ "fusionData": { "latitude": 37.7749, "longitude": -122.4194, "altitude": 25.0, "floorLevel": 5, "timestamp": "2025-01-25T08:31:50Z", "confidence": 99, "checksum": "7F4D2B1C" }, "sourceId": "PITS-67890", "fusionResult": { "primarySource": "GNSS", "secondarySource": "IMU", "confidenceScore": 92.5 }, "timestamp": "2025-01-30T12:34:00Z", "sources": { "GNSS": { "latitude": 37.7748, "longitude": -122.4195, "altitude": 15.0, "confidence": 95 }, "IMU": { "accessPoints": [ { "macAddress": "00:1A:2B:3C:4D:5E", "latitude": 37.7749, "longitude": -122.4194, "signalStrength": -65, "floorLevel": 5, "confidence": 98 } ] } } } |
— Example (ASN.1): Sensor fusion data
SensorFusionData ::= SEQUENCE { sourceId PrintableString, timestamp UTCTime, fusionResult SEQUENCE { primarySource PrintableString, secondarySource PrintableString, confidenceScore INTEGER }, fusionData SEQUENCE { latitude REAL, longitude REAL, altitude REAL, floorLevel INTEGER, confidence INTEGER, checksum PrintableString } } |
NOTE | 1. Combined Latitude, Longitude, Altitude: Fusing GNSS and Wi-Fi data with an IMU-based correction algorithm |
| 2. Checksum: Applying SHA-256 algorithm to ensure data integrity |
Integration Notes
— Alignment with ISO 6029-2:
All data structures and fusion processes adhere to the common dataset transformation approach outlined in ISO 6029-2.
— Relevance to Chapter 6.4:
Sensor validation and timestamp synchronization rely on these reference data structures for accuracy and consistency.
- Accuracy and reliability metrics
- Importance of accuracy and reliability
- Accuracy and reliability metrics
Accuracy and reliability are fundamental metrics in the data exchange processes defined by this document. These metrics ensure that sensor data, fusion outputs, and derived positioning information meet the expected performance criteria in diverse environments. Specific emphasis is placed on:
— Consistency: Ensuring uniformity of data across various sensor types and domains
— Precision: Delivering high-resolution data to support critical positioning decisions
— Integrity: Verifying data authenticity and preventing tampering during transmission.
To ensure data integrity and consistency, checksum mechanisms are implemented across all sensor data transmissions.
— Checksum example
{ "checksum": "d2a57f1c", "validated": true } |
— Validation flow:
1. Data received from sensors.
2. Checksum compared against expected value.
3. If validated, data is processed; otherwise, an error is logged.
Table B.4 — Positioning accuracy benchmarks
Positioning source | Accuracy target |
GNSS (Standard) | ≤ 5 m |
GNSS (RTK) | ≤ 1 m |
Wi-Fi AP | 1-5 m |
UWB | 10-30 cm |
IMU dead reckoning | Dependent on drift |
Odometer | 0,5 - 2 % deviation |
- Latency & data transmission thresholds
Table B.5 — Metrics for accuracy
Metric | Target value |
Data transmission latency | ≤ 100 ms |
Sensor data processing delay | ≤ 50 ms |
Position update interval | ≤ 1 s |
- Timestamp integrity checks
— Time synchronization: Must be within 100 ms drift from UTC.
— Timestamp validation: Each message must contain a monotonic timestamp to prevent replay attacks.
- Cryptographic verification (ETSI TS 102 941 compliance)
— PKI-based authentication for GNSS/Wi-Fi data validation.
— Digital signatures required for critical positioning updates.
— Adaptive sensor weighting: Adjusts weights dynamically based on environmental factors.
- Sensor fusion processes and best practices
- Multi-sensor data fusion
- Sensor fusion processes and best practices
— Kalman filtering (EKF, UKF): Used for combining GNSS, IMU, and Wi-Fi.
— Machine learning-based fusion: AI models for confidence-weighted sensor prioritization.
- Confidence weighting for sensors
Table B.6 — Confidence weighting for sensors
Sensor type | Weighting factor |
GNSS | High (clear view) / Medium (urban) |
IMU | Medium (short-term) / Low (long-term drift) |
Wi-Fi | Medium (stable signal) / Low (high interference) |
UWB | High (short-range, high accuracy) |
Odometer | Medium (short-term) / Low (long-term drift) |
- Error handling in sensor fusion
— Abnormal detection: Identifies sensor drift anomalies (e.g., IMU exceeding 3 % deviation from GNSS reference).
— Weighted position correction: Adjusts final output by discarding outliers and favoring high-confidence sources.
— Redundant sensor cross-validation: Uses multiple sources to validate positioning.
- Best practices for sensor fusion
— Choose sensors strategically:
— Prioritize sensors based on the operating environment (e.g., Wi-Fi for indoor, GNSS for outdoor).
— Error propagation awareness:
Account for cumulative errors in IMU or odometer readings during fusion.
| — Account for cumulative errors in IMU or odometer readings during fusion. |
— Fusion framework design:
— Develop modular frameworks to accommodate future sensors or algorithms
— Data validation:
— Implement real-time validation mechanisms to flag inconsistent data.
— Test in Diverse Scenarios:
— Validate the fusion system across different environments (e.g., urban, rural, indoor)
- Best practices for sensor fusion example use case: Mulit-sensor navigation
— Scenario description:
A vehicle equipped with GNSS, IMU, and Wi-Fi sensors transitions from an outdoor highway to an underground parking garage. The GNSS signal degrades as the vehicle enters the garage, and Wi-Fi and IMU data take precedence.
— Fusion process:
1. GNSS input:
— Latitude: 37.7749, Longitude: -122.4194, Altitude: 15,0 m
— Confidence: 95 %
2. IMU input:
— Motion vector: [2 m/s North, 1 m/s West]
— Orientation: θ = 15° (yaw)
3. Wi-Fi input:
— AP1 (MAC: 00:1A:2B:3C:4D:5E): Floor Level = -1, Signal = -65 dBm
— AP2 (MAC: 00:1A:2B:3C:4D:5F): Floor Level = -1, Signal = -70 dBm
4. Fusion output:
— Final position: Latitude: 37.77492, Longitude: -122.41941
— Altitude: -1 (Garage level)
— Confidence: 98 %.
- Challenges and mitigation
Table B.7 — Challenges and mitigation
Challenge | Mitigation strategy |
Sensor drift (e.g., IMU bias) | Periodic calibration using GNSS or Wi-Fi anchors. |
GNSS signal multipath | Use vision or LiDAR for obstacle-aware positioning. |
Time synchronization errors | Employ high-precision clocks and NTP-based synchronization. |
Computational overheads | Optimize algorithms using edge computing techniques. |
Integration notes
1. Alignment with ISO 6029-2: The described processes align with the data structures and accuracy requirements defined in ISO 6029-2.
2. Modularity: The outlined steps can adapt to new sensor technologies or evolving standards.
3. Interoperability: Use standardized output formats to ensure compatibility across ITS domains.
- Supplementary data validation processes
— Scenario:
— A user exits a vehicle equipped with a V-ITS-S and enters an indoor environment.
— Positioning switches from GNSS to Wi-Fi AP triangulation.
- Checksum validation for data integrity
— SHA-256 hashing for message validation.
— HMAC-SHA256 for secure data transmission.
- Error logging and reporting
— Automated logging for outlier detection.
— Real-time alerts for sensor inconsistencies.
- Positioning data consistency thresholds
Table B.8 — Challenges and mitigation
Validation check | Threshold |
GNSS compared to Wi-Fi discrepancy | ≤ 1,5 m |
IMU compared to GNSS speed mismatch | ≤ 2 % |
UWB compared to GNSS position delta | ≤ 30 cm |
Odometer compared to GNSS speed | ≤ 0,5 % |
- Real-time data correction mechanisms
— Weighted averaging: Used for resolving discrepancies.
— Timestamp validation: Ensures sequential data consistency.
- Integration with Annex A processes
This section provides a bridge between Annex A’s positioning workflows and the supplementary validation processes described here.
— Example use case:
— Scenario: A vehicle transitions from an outdoor environment with GNSS coverage to an indoor parking structure where Wi-Fi is the primary sensor
— Validation steps:
— Verify the last GNSS position against Wi-Fi triangulated coordinates
— Use timestamp checks to ensure temporal consistency.
— Apply signal confidence weighting to prioritize accurate sources.
- Practical guidelines for implementers
— Periodic validation testing:
— Conduct periodic tests to ensure sensors and fusion algorithms remain reliable under changing conditions.
— Redundancy planning:
— Build systems with fallback mechanisms for critical data sources.
— Documentation and training:
— Maintain comprehensive documentation for all validation protocols and train personnel on best practices.
- Alignment with standards
The processes described in this section align with:
— ISO 21217: Ensures interoperability at the ITS station level.
— ISO 21184: GTDM guidelines for secure transport data management
— ISO 19116: Provides definitions for error metrics and validation processes.
(Implementation guidelines)- Purpose
This annex provides practical implementation guidelines for integrating this document positioning assistance within Intelligent Transport Systems (ITS). It includes best practices for secure data exchange, interoperability, testing, and continuous improvement.
- General principles
- Standardized data formats:
- General principles
— All positioning data must conform to ISO 6029-2 Common Dataset format.
— Supported encoding formats: JSON, ASN.1, CBOR.
— Example JSON structure for position data exchange:
{ "sourceId": "PITS-123456", "position": { "latitude": 37.7749, "longitude": -122.4194, "altitude": 12.5, "accuracy": 1.2 }, "timestamp": "2025-01-30T12:34:00Z", "security": { "signature": "base64_encoded_signature" } } |
- Time synchronization
— ITS devices must use coordinated universal time (UTC).
— Recommended time sources: NTP (network time protocol), GNSS time signals.
— Acceptable clock drift: ≤100 ms deviation from UTC.
- Data interoperability
— Systems must support data transformation between JSON, ASN.1, and GTDM (Global Transport Data Management).
— Cross-platform compatibility testing required before deployment.
- Scalability
— Systems must be scalable to handle:
— High sensor density (e.g., urban environments with numerous Wi-Fi APs).
— Increased data volumes as more devices and sensors are added.
— Recommendations:
— Optimize protocols and data transmission to minimize overhead.
— Use adaptive data compression techniques when applicable.
- Interoperability
— Ensure compatibility with other ITS standards, such as:
— ISO 21217: ITS station architecture.
— ISO/TS 21184: Global Transport Data Management (GTDM).
— Interoperability guidelines:
— Use standard communication protocols like MQTT, HTTP, or WebSockets.
— Ensure data formats align with existing ITS ecosystems.
- Data security
a) Authentication & authorization
— PKI-based authentication: All devices must authenticate using X.509 certificates.
— JWT for session-based authentication:
{ "deviceId": "PITS-789123", "permissions": ["Position_Assistance"], "issuedAt": "2025-01-30T12:34:56Z", "signature": "base64_encoded_signature" } |
b) Secure data transmission
— MQTT over TLS 1.3: Ensures reliable data transmission.
— Mutual TLS (mTLS) authentication: Verifies data integrity.
— Data hashing algorithms: SHA-256 for message integrity validation.
- Key implementation steps
- Data collection
- Key implementation steps
— Define device roles (e.g., P-ITS-S, R-ITS-S, V-ITS-S).
— Configure encryption certificates and security policies.
- Data processing
— Sensor fusion
— Combine data from multiple sensors to calculate the most accurate position:
— Use algorithms like Kalman filters or particle filters to mitigate noise and inconsistencies.
— Error handling
— Implement fallback mechanisms when primary sensors fail:
— Switch to IMU-based dead reckoning if GNSS and Wi-Fi data are unavailable.
— Example: Use the last known GNSS position combined with motion data from the IMU.
— Coordinate Transformation
— Standardize all collected data into a GPS-compatible format:
— Convert Wi-Fi RSSI-based data into latitude/longitude coordinates using pre-registered AP data.
— Align all altitude data with the WGS84 standard.
- Data transmission
— MQTT (QoS 2) for real-time PVT data exchange.
— HTTPS (mTLS) for secure API calls.
— ASN.1 serialization for latency-sensitive vehicle-to-vehicle communication.
- Testing and validation
— Accuracy benchmarking: Positioning error ≤5 meters.
— Latency analysis: Transmission delay ≤100 ms.
— Security compliance: PKI and JWT-based authentication verification.
- Testing and validation
- Objectives of testing
- Testing and validation
The testing phase ensures that the system operates reliably, aligns with ISO this document requirements, and performs consistently across various environments.
Key objectives include:
— Accuracy:
— Validate that positioning outputs are within acceptable error margins.
— Reliability:
— Ensure robust performance during GNSS outages or low Wi-Fi coverage.
— Interoperability:
— Confirm compatibility with ISO 6029-2 and other related ITS standards.
- Real-world testing criteria
a) Interoperability testing
— Validate compatibility with ISO 21217 ITS Station Architecture.
— Cross-system data exchange validation using Wi-Fi, GNSS, and BLE/UWB.
b) Latency & accuracy benchmarking
Table C.1 — Latency & accuracy target value
Test type | Target value |
GNSS position accuracy | ≤ 5 meters |
Data transmission latency | ≤ 100 ms |
Data availability | ≥ 99,9 % uptime |
- Testing procedures
— Environmental testing
— Focus:
— Evaluate performance in diverse scenarios, such as:
① GNSS-denied environments (e.g., tunnels, indoor areas).
② Urban environments with multi-path signal interference.
③ Sparse Wi-Fi coverage areas.
— Example:
— Simulate a transition from a vehicle’s V-ITS-S to an indoor P-ITS-S using Wi-Fi triangulation.
— Stress testing
— Focus:
— Assess the system's scalability and reliability under heavy data loads.
— Example:
— Gradually increase the density of Wi-Fi APs and sensor inputs to evaluate the system’s capacity.
— Interoperability Testing
— Focus:
— Ensure seamless data exchange between devices across ITS domains (e.g., P-ITS-S, V-ITS-S, R-ITS-S).
— Example:
— Validate data consistency when switching between protocols like MQTT and HTTPS
- Security & integrity tests
— PKI validation for message signing.
— Real-time anomaly detection for inconsistent sensor fusion data.
- Continuous monitoring
— Monitoring tools:
— Deploy tools for real-time monitoring of accuracy, latency, and confidence metrics.
— User Feedback integration:
— Collect feedback to identify gaps and improve the system.
- Continuous improvement
To maintain system efficiency, ongoing monitoring and iterative improvement mechanisms are implemented. The following methodologies are used:
- System performance monitoring
— Real-time anomaly detection to identify inconsistencies in positioning data.
— Performance analytics dashboards for monitoring signal loss, latency, and device authentication failures.
- Automated error handling
— Dynamic fallback mechanisms: If GNSS positioning is unavailable, the system automatically switches to alternative sources (Wi-Fi, UWB, IMU).
— Self-correcting sensor fusion models that update confidence scores in real-time.
- Feedback integration and continuous learning
— Machine learning-based anomaly detection: Improves system adaptability.
— Automated dataset refinement: Ensures the accuracy of stored positioning data.
- Incorporation of emerging technologies
— New sensors:
— Integrate advanced sensors like ultra-wideband (UWB) or future-generation vision systems to enhance performance.
— Improved algorithms:
— Implement new data fusion and error correction methods as they become available.
— Adaptive protocols:
— Update communication protocols to support higher data volumes and lower latencies.
- Documentation updates
— Version control:
— Maintain a versioned history of all system updates and changes to ensure transparency.
— Compliance checks:
— Verify that updates remain compliant with ISO 6029-2 and related standards.
- Metrics for improvement
— Accuracy metrics:
— Regularly measure and compare the system's positional error against historical benchmarks.
— Reliability metrics:
— Track the frequency of data transmission errors or positioning failures.
— Interoperability metrics:
— Evaluate compatibility with other ITS systems and standards.
- Closing remarks
This document establishes a robust framework for seamless positioning and data exchange across diverse ITS environments. By leveraging the defined mechanisms for sensor integration, data validation, and error handling, implementers can ensure system interoperability, reliability, and accuracy.
Through adherence to this standard, stakeholders can address the growing demands of modern transportation systems, supporting seamless indoor-outdoor transitions and multi-domain data utilization. The principles and guidelines outlined in this document aim to serve as a foundation for consistent and scalable positioning solutions in current and future ITS implementations.
- Error handling and recovery mechanisms
— GNSS signal loss → Switch to Wi-Fi/UWB sensor fusion.
— Network disconnection → Automatic data retransmission via MQTT QoS 2.
— Sensor failure → Cross-sensor validation to prevent reliance on faulty data.
- Interoperability with other standards
— Align with ISO 21217, ETSI TS 102 941, and ISO 13400-2.
— Example use case: Secure data exchange between P-ITS-S and V-ITS-S via MQTT with PKI authentication.
By following these guidelines, ITS deployments can achieve secure, accurate, and high-performance positioning data exchange across various transportation environments.
(Reference tables)- Error sources and mitigation
Table D.1 — Error Sources mitigation
Error type | Impact | Mitigation strategy |
GNSS Multipath | Signal reflections cause position deviation | RTK corrections, multi-constellation GNSS |
IMU Drift | Accumulated error affects dead reckoning | Periodic GNSS updates, AI drift compensation |
Wi-Fi signal variability | Positioning fluctuations in indoor environments | AP database calibration, weighted confidence |
- Latency and accuracy target value
Table D.2 — Latency & accuracy target value
Format | Usage |
JSON | High-level ITS applications |
ASN.1 | V2X low-latency messaging |
CBOR | Optimized for low-bandwidth environments |
- Sensor capability matrix
Table D.3 — Latency & accuracy target value
Sensor | Accuracy | Latency | Best use case |
GNSS | 5 m (RTK: 1 m) | High | Outdoor positioning |
IMU | Drift-dependent | Low | Dead reckoning |
LiDAR | 10 cm | Medium | Urban mapping |
Wi-Fi | 1-5 m | Medium | Indoor positioning |
UWB | 10-30 cm | Low | High-precision localization |
- Validation criteria
— Accuracy benchmark: Positioning data should have ≤5 m deviation in open environments.
— Data integrity checks: All messages must pass PKI-based authentication.
— Interoperability compliance: Devices must align with ISO 21217 and ETSI TS 102 941.
By maintaining these guidelines, this document ensures robust positioning assistance with high accuracy, security, and interoperability across different ITS environments.
Bibliography
[1] ISO/TR 6029‑1:2024, Intelligent transport systems — Seamless positioning for multimodal transportation in ITS stations — Part 1: General information and use case definition
[2] ISO 19116, Geographic information — Positioning services
[3] ISO 23150, Road vehicles — Data communication between sensors and data fusion unit for automated driving functions — Logical interface
[4] ISO 24011:2009, Resilient floor coverings — Specification for plain and decorative linoleum
[5] ISO 17573‑1:2019, Electronic fee collection — System architecture for vehicle-related tolling — Part 1: Reference model
[6] ISO/TR 21724‑1:2020, Intelligent transport systems — Common Transport Service Account Systems — Part 1: Framework and use cases
[7] ISO 13400‑2:2019, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 2: Transport protocol and network layer services
[8] ISO 21217, Intelligent transport systems — Station and communication architecture
[9] ISO/TS 21184, Cooperative intelligent transport systems (C-ITS) — Global transport data management (GTDM) framework
