Technical details on harmonization of ISO FNTP with IEEE WSMP

12. August 2014


Various proposals on how to harmonize ISO FNTP and IEEE WSMP were provided by ISO TC204 WG16 and ETSI STF 455, see previous news and documents on At the meeting of IEEE 1609.3 WG in San Diego in July 2014, first steps from IEEE to write an own proposal were started. Once these are available, which is expected for the next meeting of IEEE 1609 WG in October, ISO TC204 WG16 will evaluate the proposal from IEEE and continue the process to achieve a harmonized messaging protocol.

These news aim on presenting and discussing proposals and isses related to the messaging protocol. Today the first edition only. Detailed discussions will follow in subsequent news.

Architectural environments

The architectural environments of WSMP and FNTP are the WAVE device (IEEE 1609.0) and the ITS station (ISO 21217). The goal of harmonization is to maintain these architectures and to align the message formats.


Harmonization would allow an ITS station unit to talk to a WAVE device without the need for a dual-protocol stack.

The published version of FNTP (ISO 29281-1), for which a conformance test suite exists

The FNTP PDU consists of a header and a body (payload). The design was for minimum size. Source port and destination port number fields have variable length, a one octet control field selects presence of options.


Advantages of this solution are:

Drawbacks of this solution are:

The published version of WSMP (IEEE 1609.3)

The WSMP PDU consists of a header and a body (payload). The design was for minimum size. Only the destination address field PSID (Provider Service Identifier) is supported. Payload and options are equally treated as WAVE extension elements with the requirement, that the "Payload extension" shall be the last one. Some of the extensions are designed for test purposes. In the "simple" case of broadcast transmisison of the Basic Safety Message (BSM) typically no extensions are needed.


Advantages of this solution are:

Drawbacks of this solution are:

The first harmonized candidate FWNTP

This proposal was prepared as input to and for discussion at the meeting of IEEE 1609 WG in Los Angeles in November 2013. It was identified as a favorite candidate. At the subsequent meeting of ISO TC204 WG16 at San Diego in December 2013, this proposal was confirmed as the favorite candidate.

The FWNTP PDU consists of two headers and a body (payload). The first header follows the WSMP design with 4 reserved bits and a four bit version field, and is extended by a one octet PDU type choice field which selects the second header. The second header contains all details for a given option of the messaging protocol.


Advantages of this solution are:

Drawbacks of this solution are:

The second proposal SNTP from ISO

The second proposal from ISO TC204 WG16 was developed during its May 2014 meeting in Oslo based on several early presentations of a US delegate in the IEEE WG16 meetings. It follows the FWNTP proposal and introduces the distinction of networking issues and transport issues. This proposal is specified in draft ISO 16460. Unfortunately the name SNTP is already used with a different meaning, and thus will be deprecated.

The difference to FWNTP is that one of the four reserved bits in the first header of FWNTP is now used as a selector bit, indiciating presence or absence of the N-extensions (options) in the second header of SNTP, i.e. the Networking Information header. Setting this bit to the value '0'b, SNTP and FWNTP are identical.


Advantages of this solution are:

Drawbacks of this solution are:

The proposal from ETSI STF 455

ETSI STF 455 has evaluated ISO 16460. STF 455 cross-checked also the rules of IEEE RA on assigning Ethertypes. The result was, that IEEE RA requires, or at least recommends, usage of sub-typing. This lead to the following slightly modified version of SNTP.


Advantages of this solution are:

Drawbacks of this solution are:

Harmonization with ETSI

ETSI TC ITS developed a dedicated networking protocol and a dedicated transport protocol for the purpose of geo-dissemination of information. These protocols are named GeoNetworking (GN) and Basic Transport Protocol (BTP). The EU-US task force harmonization groups HTG1 and HTG 3 identified significant problems with usage of GN over the narrow-band IEEE 802.11 channels at 5,9 GHz. The report can be downloaded from the US DOT web and the EC web.

GN uses large headers containing geo-coordinates which are a significant drawback in congested narrow-band channels. GN is neither similar to WSMP, nor to FNTP. It supports source and destination ports, as FNTP does. The geo-information could easily be added as options (extensions) to all of the discussed messaging protocols.

ETSI STF455 proposed a harmonized approach towards an efficient dual-protocol stack (IP and non-IP) by including the GN functionality in SNTP as an optional feature. See white boxes below.


Without global harmonization the implementation of three of four almost identical protocols would be necessary.

Print page