ISO/TS 16460:2016

Intelligent transport systems - Communications access for land mobiles (CALM) - Communication protocol messages for global usage

ISO/TS 16460:2016 specifies the following: - the Localized Message (LM) format: an NPDU of a networking and transport layer protocol that does not support routing of a packet through a network; - the Service Advertisement Message (SAM): an APDU to be transported in for example, an LM; - the Service Response Message (SRM): an APDU acknowledging a SAM that offered a service based on an ITS application class[8] to be transported in for example, an LM; - the related basic requirements for procedures. Specifications are partly done by normative references to IEEE 1609.3TM-2016.

Systèmes de transport intelligents — Accès aux communications des services mobiles terrestres (CALM) — Messages de protocole de communication pour une utilisation globale

General Information

• Status: Withdrawn
• Publication Date: 14-Aug-2016
• Withdrawal Date: 14-Aug-2016
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 16 - Communications
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 20-Apr-2021
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 16460:2021 - Intelligent transport systems - Localized communications - Communication protocol messages for global usage
• Effective Date: 08-May-2020

Standards Content (Sample)

TECHNICAL ISO/TS
SPECIFICATION 16460
First edition
2016-09-01
Intelligent transport systems —
Communications access for land
mobiles (CALM) — Communication
protocol messages for global usage
Systèmes intelligents de transport — Accès aux communications
des services mobiles terrestres (CALM) — Messages de protocole de
communication pour une utilisation globale
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Localized communications messages . 2
5.1 Purpose . 2
5.2 Localized message protocol . 3
5.3 Message formats . 3
5.4 Networking features. 4
5.4.1 Subtype values . 4
5.4.2 Networking feature 0 . 5
5.4.3 Networking feature 1 . 5
5.4.4 Networking feature 2 . 6
5.4.5 N-Extensions . 7
5.4.6 TPID values . 7
5.5 Transport features . 8
5.5.1 Transport feature 0 . 8
5.5.2 Transport feature 1 . 9
5.5.3 Transport feature 2 .10
5.5.4 T-Extensions.11
5.5.5 ITS port numbers .11
5.6 Procedures .11
6 Service advertisement messages .11
6.1 Purpose .11
6.2 Unique identifiers .12
6.2.1 ITS-AID/PSID .12
6.2.2 ITS-PN .12
6.3 Service advertisement protocol .13
6.4 Service advertisement message .13
6.4.1 Messages .13
6.4.2 Message structure .13
6.4.3 Message header .14
6.4.4 Message body .16
6.5 Service response message .21
6.5.1 Message structure .21
6.5.2 Message header .22
6.5.3 Message body .22
6.6 Count N .26
6.7 Procedures .26
6.7.1 General.26
6.7.2 Privately allocated channels .26
6.8 Secured messages .27
7 Structure of extension elements .28
Annex A (normative) ASN.1 modules .30
Bibliography .43
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
iv © ISO 2016 – All rights reserved

Introduction
This document is a member of the set of International Standards for communications access for land
[2]
mobiles (CALM). An introduction to this set of International Standards is provided in ISO 21217.
Localized communications, i.e. communications without networking through a cloud, and service
advertisement are essential protocol functionalities in Cooperative Intelligent Transport Systems
(C-ITS). ISO and IEEE developed protocols with similar functionality, i.e. the
[6]
— ISO Fast Networking & Transport Protocol (FNTP) standardized in ISO 29281-1,
[13]
— IEEE WAVE Short Message Protocol (WSMP) standardized in IEEE 1609.3,
[5]
— ISO Fast Service Advertisement Protocol (FSAP) standardized in ISO 24102-5, and
[13]
— IEEE WAVE Service Advertisement (WSA) standardized in IEEE 1609.3,
[2]
where ISO considered the architectural context of an ITS station specified in ISO 21217 and IEEE
TM [11]
considered the architectural context of a WAVE device specified in IEEE 1609.0 .
Although initial versions of these protocols from ISO and IEEE are very similar, there are differences
in details of the message formats and the functionality. These differences were identified by the EU/US
[16]
task force HTG 3, from which a recommendation resulted to harmonize the protocols.
The result of harmonization of FNTP with WSMP, and of FSAP with WSA is presented in this document,
distinguishing interoperability modes and enhanced features only specified in this document. The next
revisions of ISO 24102-5, ISO 29281-1 and IEEE 1609.3, and the new standards from other SDOs can
align their message specifications with the protocol message elements specified in this document in
order to achieve global interoperability of equipment designed for different architectures.
TECHNICAL SPECIFICATION ISO/TS 16460:2016(E)
Intelligent transport systems — Communications access
for land mobiles (CALM) — Communication protocol
messages for global usage
1 Scope
This document specifies the following:
— the Localized Message (LM) format: an NPDU of a networking and transport layer protocol that
does not support routing of a packet through a network;
— the Service Advertisement Message (SAM): an APDU to be transported in for example, an LM;
— the Service Response Message (SRM): an APDU acknowledging a SAM that offered a service based
[8]
on an ITS application class to be transported in for example, an LM;
— the related basic requirements for procedures.
TM
Specifications are partly done by normative references to IEEE 1609.3 -2016.
NOTE These message format specifications and basic procedures need to be complemented by complete
[2]
procedures and SAP specifications according to the context of usage, i.e. an ITS station specified in ISO 21217,
TM[11]
or a WAVE device specified in IEEE 1609.0 or any other context.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER)
TM
IEEE 1609.3 -2016, Standard for Wireless Access in Vehicular Environments (WAVE) — Networking
Services
3 Terms and definitions
No terms and definitions are defined in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
4 Abbreviated terms
CIP communication interface parameter
C-ITS cooperative ITS
FNTP fast networking & transport protocol
FSAP fast service advertisement protocol
HTG harmonization task group
IPv6 internet protocol version 6
ITS intelligent transport systems
ITS-AID its application identifier
LM localized message
MAC medium access control
NPDU network protocol data unit
OSI open system interconnection
PSID provider service identifier
RX CIP receiver CIP
SAM service advertisement message
SAP service access point
SRM service response message
TPID transport protocol identifier
TX CIP transmitter CIP
VANET vehicular ad hoc network
WAVE wireless access in vehicular environment
WSA WAVE service advertisement
WSMP WAVE short message protocol
5 Localized communications messages
5.1 Purpose
Localized communications is used to communicate with nearby peer stations, e.g. ITS station units or
WAVE devices. These stations are uniquely identified with an OSI data link layer address, typically by
the Medium Access Control (MAC) address. Networking in the sense of IP networking, where stations
route packets to other nodes through a network (cloud), is not supported. Nevertheless multi-hopping
can be performed in different ways, e.g.
— N-hop broadcast or N-hop multicast, which requires careful means to avoid flooding of the
communication channel;
2 © ISO 2016 – All rights reserved

[2]
— dedicated forwarding performed at higher layers, e.g. at the ITS-S facilities layer of an ITS station ;
this is a feature useful for geo-dissemination of information;
which creates so-called “Vehicular Ad hoc NETworks” (VANETs). Routing of packets through a network
in ITS will use the Internet protocol version 6 (IPv6).
5.2 Localized message protocol
As this document does not specify a specific localized communications protocol but just the structure
of messages of such protocols and related basic requirements, a hypothetical localized communications
protocol with the name “Localized Message Protocol” is used to simplify reading of the document.
5.3 Message formats
Figure 1 illustrates the basic format of the Localized Message (LM). Unaligned packet encoding rules
(UPER) applied to the ASN.1 type LMnpdu defined in A.2.1 results in the intended binary presentation
of this LM format.
Figure 1 — General format of the LM NPDU
TM
NOTE 1 In Figure 1, the “TPID” field (specified in IEEE 1609.3 -2016 as a one-octet unsigned integer field
completely allocated in the WSMP-N-Header) is split into a “Feature selector” field of the “N-Header” and a
“T-Extensions flag” field of the “T-Header” (according to the general rules of the OSI model). However, the two
presentations result in identical binary presentations.
The LM consists of three parts:
— “N-Header”
— a 4-bit unsigned integer “Subtype” number in the range of 0 to 15 indicating a networking
related feature;
— a 1-bit “N-Extensions flag”;
— a 3-bit unsigned integer “Version” number in the range of 0 to 7 indicating the version of the
localized message protocol. In case a receiver does not support the version, the received packet
TM
cannot be processed. The first version number used is three as specified in IEEE 1609.3 -2016;
[13]
NOTE 2 The format presented in Figure 1 is such that WAVE devices implementing version 2 of WSMP
can identify LMs as WSMP messages with version number 3 or higher.
— a networking related feature specified in 5.4 and selected by the value contained in the field
“Subtype”;
— “N-Extensions” being present if the “N-Extensions flag” is set to ‘1’b;
— a 7-bit unsigned integer in the range of 0 to 127, the “Transport Protocol Identifier (TPID)
feature selector”, indicating content in the “T-Header”.
— “T-Header”
— a 1-bit “TPID - T-Extensions flag”;
— a transport related feature specified in 5.5 and selected by the TPID feature selector value
contained in the “N-Header”;
— “T-Extensions” being present if the “T-Extension flag” is set to ‘1’b;
— a one or two octet field indicating the number of octets contained in “User data”.
— Body
— the “User data”.
The distinction of “N-Header” (networking related features) and “T-Header” (transport related features)
is in support of the ITS-S networking and transport layer that combines OSI layers 3 and 4 as illustrated
[2]
in ISO 21217.
The field “Length of User data” has a length of one or two octets dependent on the value contained in it:
— one octet size: Values from 0 to 127. The most significant bit is always set to zero. Presented as 0x00
(=0) to 0xEF (=127); i.e. the remaining 7 bits contain an unsigned integer number.
— two octet size: Values from 128 to 16383. The most significant bit of the first octet is always set to
one and the second most significant bit of the first octet is always set to zero. Presented as 0x8080
(=128) to 0xBFFF (=16383); i.e. the remaining 14 bits contain an unsigned integer number.
NOTE 3 This presentation results from the unaligned packed encoding rules applied to ASN.1 types of
unconstraint variable length.
5.4 Networking features
5.4.1 Subtype values
Networking features are identified by a subtype value. Subtype values are presented in Table 1.
Table 1 — Subtype values
N-Extensions Networking related
Subtype N-Extensions Remark
flag features
0 ‘0’b Not present Null-Networking Mandatory feature specified in
TM
IEEE 1609.3 -2016. Format
‘1’b Present
described in 5.4.2.
1 ‘0’b Not present ITS station-internal Format specified in 5.4.3.
forwarding
‘1’b Present
2 ‘0’b Not present N-hop forwarding Format specified in 5.4.4.
‘1’b Present
3 ‘0’b Not present Geo-forwarding Reserved. Not specified in this
document.
‘1’b Present
4–7 ‘0’b Not present Reserved for ISO Allows for further four
networking features.
‘1’b Present
8–15 ‘0’b Not present Reserved for IEEE Allows for further eight
networking features.
‘1’b Present
N-Extensions and related basic procedures shall be as specified in 5.4.5.
New networking features can be specified and linked to so far reserved subtype values at a later stage
without breaking backward compatibility.
NOTE Updates of N-Extensions will be published in the ISO/TS 16460 folder of the ISO standards
maintenance portal at http://standards.iso.org/iso/ts/16460.
4 © ISO 2016 – All rights reserved

5.4.2 Networking feature 0
Subtype 0 selects the “Null-Networking” feature introduced in 5.4.1.
NOTE Procedures on how to use this feature in the context of an ITS station unit, or a WAVE device or any
other context are outside the scope of this document.
The “Null-Networking” feature with Subtype 0 is the uppermost simple feature, as it requires only
processing of the TPID feature selector field specified in 5.6. Figure 2 presents the N-Header format for
Subtype 0 with N-Extensions being absent.
Figure 2 — N-Header for Subtype 0 without N-Extensions
Figure 3 presents the N-Header format for Subtype 0 with N-Extensions being present.
Figure 3 — N-Header for Subtype 0 with N-Extensions
N-Extensions and related basic procedures shall be as specified in 5.4.5.
5.4.3 Networking feature 1
Subtype 1 selects the “ITS Station-Internal Forwarding” feature introduced in 5.4.1.
NOTE Procedures on how to use this feature in the context of an ITS station unit, or a WAVE device, or any
other context are outside the scope of this document.
[3]
ITS station-internal forwarding is a feature applicable in ITS stations compliant with ISO 21218 (Link-
[4]
ID) and ISO 24102-1 (ITS-SCU-ID). It is used to forward packets between router units and host units
that are part of the same station/device. The field “Direction” contains an unsigned integer number with
the two possible values “0” (“from host to router”) and “255” (“from router to host”). The field “Counter”
contains a one octet unsigned integer cyclic packet counter being unique in the unit that forwards a
packet. Figure 4 presents the N-Header format for Subtype 1 with N-Extensions being absent.
Figure 4 — N-Header for Subtype 1 without N-Extensions
Figure 5 presents the N-Header format for Subtype 1 with N-Extensions being present.
Figure 5 — N-Header for Subtype 1 with N-Extensions
N-Extensions and related basic procedures shall be as specified in 5.4.5.
5.4.4 Networking feature 2
Subtype 2 select the “N-hop Forwarding” feature introduced in 5.4.1.
NOTE Procedures on how to use this feature in the context of an ITS station unit, or a WAVE device, or any
other context are outside the scope of this document.
N-hop forwarding is a feature that allows extending the communication range for information
dissemination (MAC broadcast or multicast mode) beyond the next directly reachable neighbour
stations. It uses parameters that allow avoiding flooding of the communication channel. Figure 6
presents the N-Header format for Subtype 2 with N-Extensions being absent.
Figure 6 — N-Header for Subtype 2 without N-Extensions
The 22-bit Message ID is generated from a random number generator and is unique within the N-hop
communication range with a “high” likelihood. In case of duplicate Message ID values, forwarding might
not be performed correctly in a station.
The 2-bit unsigned integer Hop Count indicates to a receiver whether a forwarding shall be performed
or not. If Hop Count equals zero, forwarding is prohibited. Prior to forwarding of a packet, the Hop
Count shall be decremented by one. Consequently, a maximum of four hops is possible.
Forwarding shall be performed also if the TPID value contained in the received message is not supported
or reserved.
Figure 7 presents the N-Header format for Subtype 2 with N-Extensions being present.
Figure 7 — N-Header for Subtype 2 with N-Extensions
N-Extensions and related procedures shall be as specified in 5.4.5.
6 © ISO 2016 – All rights reserved

5.4.5 N-Extensions
The structure of the N-Extensions is specified in Clause 7. Extension elements presented in Table 2 may
be used in the “N-Extensions” field.
Table 2 — N-Extensions elements
Element ID Element type (ASN.1) Element name
TXpower80211
c-TxPowerUsed80211 = 4 Transmit Power Used (specified in
TM
IEEE 1609.3 -2016)
c-ChannelNumber80211 = 15 ChannelNumber80211 802.11 Channel Number used
TM
(specified in IEEE 1609.3 -2016)
DataRate80211
c-DataRate80211 = 16 802.11 Data Rate used (specified
TM
in IEEE 1609.3 -2016)
TXcip
c-LMtxCip = 80 Communication Interface transmit
parameters
RXcip
c-LMrxCip = 81 Communication Interface receive
parameters (RX-CIP)
LMchannelBusyRatio
c-LMchannelBusyRatio = 82 Channel Busy Ratio
The “Transmit Power Used” element is optionally included in the LM N-Header for use by the LM
TM [10]
recipient; see also IEEE 802.11 .
The “Channel Number” element is optionally included in the LM N-Header for use by the LM recipient;
TM [10]
see also IEEE 802.11 .
The “Data Rate” element is optionally included in the LM N-Header for use by the LM recipient; see also
TM [10]
IEEE 802.11 .
The “TX CIP” element is optionally included in the LM N-Header indicating Communication Interface
Parameter (CIP) settings used by the transmitter of the LM.
The “RX CIP” element is optionally included in the LM N-Header used with Subtype 1 indicating
Communication Interface Parameter (CIP) settings of the ITS-SCU that received the LM from a peer
station.
The “Channel Busy Ratio” element is a one octet unsigned integer optionally included in the LM
N-Header reporting the observed channel busy ratio in percent (0 % up to 100 % in steps of 0,5 %). The
integer values 201 to 255 indicate “unknown ratio”.
5.4.6 TPID values
Table 3 — TPID values
TPID
Transport related
T-Extensions Remark
Feature T-Extensions
feature
selector flag
0 ‘0’b Not present Information Mandatory feature specified in
TM
dissemination IEEE 1609.3 -2016. Format
‘1’b Present
described in 5.5.1
1 ‘0’b Not present General session mode Format specified in 5.5.2
‘1’b Present
2 ‘0’b Not present LPP mode Format specified in 5.5.3
‘1’b Present
Table 3 (continued)
TPID
Transport related
T-Extensions Remark
Feature T-Extensions
feature
selector flag
3–10 ‘0’b Not present Reserved for ISO Allows for further 8 transport
features.
‘1’b Present
11–127 ‘0’b Not present Reserved for IEEE Allows for further 117 transport
features
‘1’b Present
New transport features can be specified and linked to so far reserved TPID feature selector values at a
later stage without breaking backward compatibility.
5.5 Transport features
5.5.1 Transport feature 0
The TPID feature selector 0 selects the “Information Dissemination” feature specified in 5.4.6.
Figure 8 presents the T-Header for TPID = 1, i.e. with T-Extensions being present.
Figure 8 — TPID 1 — Information dissemination with T-Extensions
The T-header consists of four parts:
— a 1-bit “T-Extensions flag” (LSB of TPID) set to ‘1’b;
— a variable length “Destination Address” field containing an ITS Application Identifier (ITS-AID)
[8]
specified in ISO/TS 17419, identifying the upper layer entity (referred to as ITS-S application
[2]
process in ISO 21217 ) in the receiver for which the message is intended;
— a variable length “T-Extensions” field with the structure specified in Clause 7 and content details
specified in 5.5.4;
— a variable length field indicating the length of the User data.
TM
NOTE PSID specified in IEEE 1609.3 -2016 and ITS-AID share a common number space; see 6.2.1.
If no T-Extensions are needed, the T-Extensions flag is set to ‘0’b. The corresponding T-Header is
presented in Figure 9.
Figure 9 — TPID 0 — Information dissemination without T-Extensions
8 © ISO 2016 – All rights reserved

Feature 0 is designed for information dissemination (typically combined with MAC broadcast or MAC
multicast).
A receiver shall first check the T-Extensions and shall perform related procedures, if supported. Then
the receiver shall forward the data contained in the message (optionally together with information
contained in T-Extensions) to the recipient(s) identified by the Destination Address.
NOTE 1 If the Destination Address is not identifying a known upper layer entity, the receiver cannot further
process the message.
NOTE 2 Procedures on how to use this feature in the context of an ITS station unit, or a WAVE device, or any
other context are outside the scope of this document.
5.5.2 Transport feature 1
The TPID feature selector 1 selects the “General Session Mode” feature specified in 5.4.6.
Figure 10 presents the T-Header for TPID = 3, i.e. with T-Extensions being present.
Figure 10 — TPID 3 — General purpose session support transport feature with T-Extensions
The T-Header consists of five parts:
— a 1-bit “T-Extensions flag” (LSB of TPID) set to ‘1’b;
— a two octet ITS port number in the “Source Address” field identifying the address of the upper layer
entity in the transmitter;
— a two octet ITS port number in the “Destination Address” field identifying the address of the upper
layer entity in the receiver;
— a variable length “T-Extensions” field with the structure specified in Clause 7 and content details
specified in 5.5.4;
— a variable length field indicating the length of the User data.
If no T-Extensions are needed, the T-Extensions flag is set to ‘0’b. The corresponding T-Header is
presented in Figure 11.
Figure 11 — TPID 2 — General purpose session support transport feature without T-Extensions
Feature 1 is designed for sessions, e.g. when a reply is expected. Note that also groupcast transmissions
with no expected reply can use this TPID.
A receiver shall first check the T-Extensions and shall perform related procedures, if supported. Then
the receiver shall forward the data contained in the message (optionally together with information
contained in T-Extensions) to the recipient(s) identified by the ITS port number contained in the
Destination Address field.
NOTE 1 If the Destination Address ITS port number is not identifying a known upper layer entity, the receiver
cannot further process the message.
The ITS port number contained in the Source Address field typically is used in the Destination Address
field of replies to the transmitter.
NOTE 2 Procedures on how to use this feature in the context of an ITS station unit, or a WAVE device, or any
other context are outside the scope of this document.
5.5.3 Transport feature 2
The TPID feature selector 2 selects the “LPP” feature specified in 5.4.6. LPP is the “Local Port Protocol”
[15]
standardized in ARIB STD-T88.
Figure 12 presents the T-Header for TPID = 5, i.e. with T-Extensions being present.
Figure 12 — TPID 5 — LPP feature with T-Extensions
The T-Header consists of six parts:
— a 1-bit “T-Extensions flag” (LSB of TPID) set to ‘1’b;
— a two octet ITS port number in the “Source Address” field identifying the address of the upper layer
entity in the transmitter;
— a two octet ITS port number in the “Destination Address” field identifying the address of the upper
layer entity in the receiver;
[15]
— the “LPP Header” specified in ARIB STD-T88;
— a variable length “T-Extensions” field with the structure specified in Clause 7 and content details
specified in 5.5.4;
— a variable length field indicating the length of the User data.
If no T-Extensions are needed, the T-Extensions flag is set to ‘0’b. The corresponding T-Header is
presented in Figure 13.
Figure 13 — TPID 4 - LPP feature without T-Extensions
NOTE 1 If the Destination Address ITS port number is not identifying a known upper layer entity, the receiver
cannot further process the message.
10 © ISO 2016 – All rights reserved

NOTE 2 Procedures on how to use this feature in the context of an ITS station unit, or a WAVE device, or any
other context are outside the scope of this document.
5.5.4 T-Extensions
The structure of the T-Extensions is specified in Clause 7. Extension elements presented in Table 4 may
be used in the “T-Extensions” field.
Table 4 — T-Extensions elements
Element ID Element type Element name
LMpacketID
c-LMpacketID = 83 Packet Identifier
The “Packet Identifier” element is optionally included in the LM T-Header to identify uniquely a specific
packet in a sequence of packets from a specific transmitter.
NOTE Updates of T-Extensions will be published in the ISO/TS 16460 folder of the ISO standards maintenance
portal at http://standards.iso.org/iso/ts/16460.
5.5.5 ITS port numbers
ITS port numbers are unsigned integer numbers of ASN.1 type PortNumber in the range 0 to 65535,
i.e. contained in two octets. Details of ITS port numbers usage and management are presented in
[8]
ISO/TS 17419.
5.6 Procedures
A receiver shall first inspect the Version field specified in 5.2. If the presented version is supported by
the implementation, then the receiver shall inspect the subtype field specified in 5.2 and in 5.4.1.
NOTE 1 If the presented version is not supported in a given implementation, the message cannot be processed.
If the presented subtype is supported by the implementation, then the related procedure shall be
performed as specified in 5.4.2 to 5.4.4.
NOTE 2 If a received subtype value is pointing to NoSubtypeProcessing, i.e. not supported in a given
implementation, the message cannot be processed.
Upon successful processing of the subtype procedure, the receiver shall inspect the TPID feature
selector field specified in 5.2 and in 5.4.6.
If the transport feature identified by the number contained in the TPID feature selector field is
implemented in the receiver, the respective procedure shall be executed as specified in 5.5.1 to 5.5.3.
NOTE 3 If a received TPID value is pointing to NoTpidProcessing, i.e. not supported in a given
implementation, the T-Header part of the message cannot be processed.
Optional features, or features defined by implementation, may become normative mandatory features
in other standards using the specifications of this document as a basis.
NOTE 4 Further procedures can be specified in standards that use this message format.
6 Service advertisement messages
6.1 Purpose
Service advertisement is used to inform peer stations, e.g. ITS station units or WAVE devices, about
accessible ITS services (“push service advertisement”). ITS services are provided by means of ITS
[2]
applications; see ISO 21217. ITS applications are identified by globally unique ITS Applications
[8]
Identifiers (ITS-AID) specified in ISO/TS 17419.
[2]
NOTE 1 In the context of an ITS station specified in ISO 21217, service advertisement is performed according
[5]
to the Fast Service Advertisement Protocol (FSAP) specified in ISO 24102-5. In the context of a WAVE device
TM [11]
specified in IEEE 1609.0 , service advertisement is performed according to the WAVE Service Advertisement
[13]
(WSA) protocol specified in IEEE 1609.3.
[13]
NOTE 2 IEEE WAVE uses globally unique Provider Service Identifiers (PSID) specified in IEEE 1609.3 and
TM[14]
IEEE 1609.12 to identify ITS applications. ITS-AID and PSID share a common number space.
ITS services typically are provided in sessions. However, an ITS service can also be an information
dissemination service.
The service advertisement distinguishes at least the following roles:
a) Service Advertisement Manager:
— Server management,
Transmission of SAMs and reception of SRMs
— Client management,
Reception of SAMs, transmission of SRMs;
b) Service Provider:
Provision of ITS services,
c) Service User:
Consumption of ITS services.
6.2 Unique identifiers
6.2.1 ITS-AID/PSID
[8]
ITS-AID is specified in ISO 17419 as an unsigned integer. ITS-AID shares a common number space
[13]
with IEEE PSID; see IEEE 1609.3. ITS-AID and PSID are synonyms. The purposes of ITS-AID is
[8]
specified in ISO/TS 17419; ITS-AID may be used at the OSI transport layer to identify a destination as,
for example, specified in 5.5.1.
ITS-AID values are assigned to:
[13]
— WAVE Service Advertisement (WSA) specified in IEEE 1609.3;
[5]
— Fast Service Advertisement Protocol (FSAP) specified in ISO 24102-5.
[17]
NOTE The assigned numbers are presented at the ISO Standards Maintenance Portal.
6.2.2 ITS-PN
[8]
ITS port numbers (ITS-PNs) are two octet unsigned integer numbers specified in ISO/TS 17419.
ITS-PN may be used at the OSI transport layer to identify source and destination of a message as e.g.,
[8]
specified in 5.5.2. For some ITS-PNs, acronyms are introduced in ISO/TS 17419, e.g. the acronym
PORT_SAM for the well-known ITS-PN = 1 identifying the service advertisement protocol (i.e. used by
[5]
FSAP in ISO 24102-5 ).
The well-known ITS-PN PORT_SAM is used to identify the service advertisement protocol that is
receiving broadcast service advertisement messages (SAM).
12 © ISO 2016 – All rights reserved

A dynamically assigned ITS-PN PORT_DYN_SAM is used to identify the service advertisement protocol
that is receiving unicast service advertisement messages (SAM). The dynamic assignment is done in the
service user station that is transmitting SRMs.
A dynamically assigned ITS-PN (PORT_DYN_SRM) is used to identify the service advertisement
protocol that is receiving SRMs. The dynamic assignment is done in the service advertiser station that
is transmitting SAMs.
6.3 Service advertisement protocol
As this document does not specify a specific service advertisement protocol but just the structure of
service advertisement messages and related basic requirements, a hypothetical service advertisement
protocol with the name “Service Advertisement Protocol” is used to simplify reading of the document.
6.4 Service advertisement message
6.4.1 Messages
This document specifies two messages, i.e.
— Service Advertisement Message (SAM) of ASN.1 type Sam specified in A.2.2;
— Service Response Message (SRM) of ASN.1 type Srm specified in A.2.2.
SAM is used to advertise services provided by ITS applications or by ITS application classes specified
[8]
in ISO/TS 17419. ITS application classes are unique only with a defined context. The SRM provides
the context to an ITS application class advertised in a SAM, i.e. it acknowledges a SAM. Such an
acknowledgement is not applicable for advertised ITS applications. The SRM is also used to indicate
interest in an offered service that requires usage of a privately allocated communication channel.
TM
NOTE SRM is not supported in IEEE 1609.3 -2016.
6.4.2 Message structure
Figure 14 illustrates the basic format of the Service Advertisement Message (SAM). Unaligned packet
encoding rules (UPER) applied to the ASN.1 type Sam defined in A.2.2 results in the intended binary
presentation of this SAM format.
Figure 14 — General format of the SAM
The SAM consists of two parts:
a) SAM header specified in 6.4.3:
1) “Version”: a 4-bit unsigned integer number indicating the version of the service advertisement
protocol specified in 6.4.3.1. The smallest allowed number is 3; this is the initial version number
TM
specified in IEEE 1609.3 -2016;
2) “Option Selector”: a 4-bit field indicating presence or absence of optional fields:
— Bit 3 = ‘1’b: “SAM Extensions” field is present;
— Bit 2 = ‘1’b: “Service Info Segment” field is present;
— Bit 1 = ‘1’b: “Channel Info Segment” field is present;
— Bit 0 = ‘1’b: “IPv6 Routing Advertisement” field is present;
3) SAM identification specified in 6.4.3.2:
— “SAM-ID”: a 4-bit unsigned integer number field allowing to distinguish up to 16 different
SAMs announced by the same station (same advertiser);
— “SAM-Count”: a 4-bit unsigned integer number field indicating the actual content status of
the SAM indicated by the previous field.
4) An optionally present “SAM Extensions” field specified in 6.4.3.3; see also Bit 3 above.
b) SAM body specified in 6.4.4:
1) an optionally present “Service Info Segment” field specified in 6.4.4.2; see also Bit 2 above;
2) an optionally present “Channel Info Segment” field specified in 6.4.4.3; see also Bit 1 above;
3) an optionally present “IPv6 Routing Advertisement” field specified in 6.4.4.4; see also Bit 0 above.
6.4.3 Message header
6.4.3.1 Protocol version
The protocol version is presented as a 4-bit unsigned integer number of ASN.1 type RsvAdvPrtVersion
specified in A.2.2.
6.4.3.2 SAM-ID and SAM-Count
SAM-ID and SAM-Count are used to
— distinguish different service advertisements (SAM-ID) presented by the same Service Advertiser, and
— identify a change of content of the indicated SAM (SAM-Count).
See ASN.1 type SrvAdvChangeCount specified in A.2.2.
Up to 16 different SAMs (SAM-ID = 0 up to SAM-ID = 15) presented by the same Service Advertiser can
be distinguished. The Service Advertiser shall select values in a unique way. SAM-ID is of ASN.1 type
SrvAdvID.
SAM-Count is a cyclic counter of ASN.1 type SrvAdvContentCount. For every value of SAM-ID, a
separate SAM-Count shall be maintained. Upon first transmission of a new SAM, SAM-Count shall be set
to zero. Upon every change of content of a SAM, this number shall be incremented by one. SAM-Count
shall wrap around from 15 to zero. A change of content of a SAM may be either
— changing details of already advertised services,
— adding new services, or
— discontinuing provision and advertisement of services.
Discontinuing provision and advertisement of services may finally result in an empty SAM, i.e. a SAM
that consists only of a header.
...