ISO 16460:2021
(Main)Intelligent transport systems — Localized communications — Communication protocol messages for global usage
Intelligent transport systems — Localized communications — Communication protocol messages for global usage
This document specifies: — the Localized Message (LM) format: an NPDU of a networking & 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 an LM, for example; — the Service Response Message (SRM): an APDU acknowledging a SAM that offered a service based on an ITS application class[2] to be transported in an LM, for example; — related basic requirements for procedures. Specifications are partly done by normative references to IEEE 1609.3(TM)-2016. NOTE These message format specifications and basic procedures need to be complemented by complete procedures and SAP specifications according to the context of usage, i.e. an ITS station specified in ISO 21217, or a WAVE device specified in IEEE 1609.0[13] or any other context.
Systèmes de transport intelligents — Communications localisées — Messages de protocole de communication pour une utilisation globale
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 16460
First edition
2021-04
Intelligent transport systems —
Localized communications —
Communication protocol messages for
global usage
Systèmes de transport intelligents — Communications localisées —
Messages de protocole de communication pour une utilisation globale
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 1
5 Localized communications messages . 3
5.1 Purpose . 3
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 .12
6.1 Purpose .12
6.2 Unique identifiers .12
6.2.1 ITS-AID/PSID .12
6.2.2 ITS port numbers (ITS-PNs) .13
6.3 Service advertisement protocol .13
6.4 Service advertisement message (SAM) .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 (SRM) .22
6.5.1 Message structure .22
6.5.2 Message header .23
6.5.3 Message body .23
6.6 Count N .27
6.7 Procedures .27
6.7.1 General.27
6.7.2 Privately allocated channels .27
6.8 Secured messages .28
7 Structure of extension elements .29
Annex A (normative) ASN.1 modules .31
Bibliography .45
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/d irectives).
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/p atents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
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/f oreword. html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces the first edition (ISO/TS 16460:2016), which has been technically
revised.
The main changes compared to the previous edition are as follows:
— editorial improvements;
— editorial corrections.
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/m embers. html.
iv © ISO 2021 – All rights reserved
Introduction
This document belongs to a set of International Standards for Intelligent Transport Systems (ITS) and
Cooperative ITS (C-ITS). An introduction to this set of International Standards is provided in ISO 21217.
Localized communications, i.e. communications without networking through nodes, and service
advertisement are essential protocol functionalities in C-ITS. ISO and IEEE developed protocols with
similar functionality, i.e. the
— ISO Fast Networking & Transport Protocol (FNTP) standardized in ISO 29281-1;
[15]
— IEEE WAVE Short Message Protocol (WSMP) standardized in IEEE 1609.3 ,
— ISO Fast Service Advertisement Protocol (FSAP) standardized in ISO 24102-5,
[15]
— IEEE WAVE Service Advertisement (WSA) standardized in IEEE 1609.3 ,
where ISO considered the architectural context of an ITS station specified in ISO 21217:2014, and IEEE
[13]
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
[20]
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 specified in this document.
With reference to this document, the initial editions of ISO 29281-1 and IEEE 1609.3 were revised, and
ISO 24102-5 was converted into EN ISO 22418, enabling global interoperability of equipment designed
for different architectures. Finally, ETSI developed EN 302 890-1 (a further service announcement
protocol profile) with reference to the previous edition of this document, i.e. ISO/TS 16460:2016.
INTERNATIONAL STANDARD ISO 16460:2021(E)
Intelligent transport systems — Localized communications
— Communication protocol messages for global usage
1 Scope
This document specifies:
— the Localized Message (LM) format: an NPDU of a networking & 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 an LM, for example;
— the Service Response Message (SRM): an APDU acknowledging a SAM that offered a service based
[2]
on an ITS application class to be transported in an LM, for example;
— related basic requirements for procedures.
Specifications are partly made by normative references to IEEE 1609.3(TM)-2016.
NOTE These message format specifications and basic procedures need to be complemented by complete
procedures and SAP specifications according to the context of usage, i.e. an ITS station specified in ISO 21217, or
[13]
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
IEEE 1609.3(TM)-2016: Standard for Wireless Access in Vehicular Environments (WAVE) — Networking
Services
3 Terms and definitions
No terms and definitions are listed in this document.
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 http:// www .electropedia .org/
4 Symbols and abbreviated terms
CIP communication interface parameter
C-ITS cooperative ITS
DNS domain name server
EIRP effective isotropic radiated power
ESAP ETSI Service Announcement Protocol
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
ITS-PN ITS port number
LM localized message
LPP Local Port Protocol
MAC medium access control
NPDU network protocol data unit
OER octet encoding rules
OSI open system interconnection
PSID provider service identifier
RX CIP receiver CIP
SAM service advertisement message
SAM-ID SAM identifier
SAM-Count SAM change of content identifier
SAP service access point
SRM service response message
TCP transmission control protocol
TPID transport protocol identifier
TX CIP transmitter CIP
UPER unaligned packet encoding rules
VANET vehicular ad-hoc network
WAVE wireless access in vehicular environment
WSA WAVE service advertisement
WSMP WAVE short message protocol
2 © ISO 2021 – All rights reserved
5 Localized communications messages
5.1 Purpose
Localized communication 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 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;
[4]
— 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 create 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 LM. Unaligned packet encoding rules UPER applied to the
ASN.1 type LMnpdu defined in A.2.1 result in the intended binary presentation of this LM format.
NOTE In Figure 1 the "TPID" field (specified in IEEE 1609.3(TM)-2016 as a 1-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.
Figure 1 — General format of the LM NPDU
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 cannot be processed. The first version number used is three in accordance with
IEEE 1609.3(TM):2016.
NOTE 1 The format presented in Figure 1 is such that WAVE devices implementing version 2 of
[15]
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 " 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 line with the OSI layers 3 and 4; these two OSI layers constitute the ITS-S networking & transport
layer as illustrated 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 through 127. The most significant bit is always set to zero. Presentation
as 0x00 (=0) through 0xEF (=127), i.e. the remaining 7 bits contain an unsigned integer number.
— Two octet size: Values from 128 through 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.
Presentation as 0x8080 (=128) through 0xBFFF (=16383), i.e. the remaining 14 bits contain an
unsigned integer number.
NOTE 2 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
Subtype N-Extensions N-Extensions Networking related fea- Remark
flag tures
0 '0'b Not present Null-Networking Mandatory feature specified in
IEEE 1609.3(TM)-2016. Format
'1'b Present
specified in 5.4.2.
1 '0'b Not present ITS station-internal forwarding Format specified in 5.4.3.
'1'b Present
2 '0'b Not present N-hop forwarding Format specified in 5.4.4.
'1'b Present
4 © ISO 2021 – All rights reserved
Table 1 (continued)
Subtype N-Extensions N-Extensions Networking related fea- Remark
flag tures
3 '0'b Not present Geo-forwarding Reserved. Not specified in this
version of the 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.
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.
ITS station-internal forwarding is a feature applicable in ITS stations conformant with ISO 21218 (Link-
ID) and ISO 24102-4 (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 1-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
NOTE In Figure 5, unlike in the presentation in Figure 1, subtype-specific elements (i.e. "Original
N-Header") are allocated between "N-Extensions" and "TPID - Feature Selector". This is to simplify processing
at the receiver side.
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 flooding of the communication channel to be avoided. 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 the 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.
6 © ISO 2021 – All rights reserved
Forwarding shall be performed also if the TPID value contained in the received message is not supported
or is 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.
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
IEEE 1609.3(TM)-2016).
ChannelNumber80211
c-ChannelNumber80211 = 15 802.11 Channel Number used (specified in
IEEE 1609.3(TM)-2016).
DataRate80211
c-DataRate80211 = 16 802.11 Data Rate used (specified in
IEEE 1609.3(TM)-2016).
TXcip
c-LMtxCip = 80 Communication Interface transmit pa-
rameters.
RXcip
c-LMrxCip = 81 Communication Interface receive param-
eters (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
[12]
recipient; see also IEEE Std 802.11 .
The "Channel Number" element is optionally included in the LM N-Header for use by the LM recipient;
[12]
see also IEEE Std 802.11 .
The "Data Rate" element is optionally included in the LM N-Header for use by the LM recipient; see also
[12]
IEEE Std 802.11 .
The "TX CIP" element is optionally included in the LM N-Header indicating 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 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 through 255 indicate "unknown ratio".
5.4.6 TPID values
Table 3 provides a summary of TPID values.
Table 3 — TPID values
TPID T-Extensions Transport related feature Remark
Feature T-Extensions
selector flag
0 '0'b Not present Information dissemination Mandatory feature specified in
IEEE 1609.3(TM)-2016. Format spec-
'1'b Present
ified 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
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-AID specified in ISO 17419 identifying
the upper layer entity (referred to as ITS-S application 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.
NOTE PSID specified in IEEE 1609.3(TM)-2016 and ITS-AID share a common number space; see 6.2.1. In the
given context, PSID and ITS-AID are presented with the same ASN.1 type.
If no T-Extensions are needed, the T-Extensions flag is set to '0'b. The corresponding T-Header is
presented in Figure 9.
8 © ISO 2021 – All rights reserved
Figure 9 — TPID 0 — Information dissemination without T-Extensions
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 2-octet ITS port number in the "Source Address" field identifying the address of the upper layer
entity in the transmitter;
— a 2-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 when a reply is expected, for example. Note that groupcast
transmissions with no expected reply can also 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 is typically 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"
[18]
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 one bit "T-Extensions flag" (LSB of TPID) set to '1'b;
— a 2-octet ITS port number in the "Source Address" field identifying the address of the upper layer
entity in the transmitter;
— a 2-octet ITS port number in the "Destination Address" field identifying the address of the upper
layer entity in the receiver;
[18]
— 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.
10 © ISO 2021 – All rights reserved
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.
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.
Composed of
— TPmessageID,
— TPfragmentID,
— TPnoFragments.
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. TPmessageID is used to uniquely distinguish
different messages. TPfragmentID (1 ≤ TPfragmentID ≤ TPnoFragments) identifies the number of the
given fragment out of the total number TPnoFragments of the message.
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 ISO 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, for example ITS station units or WAVE devices,
about accessible ITS services ("push service advertisement"). ITS services are provided by means of
ITS applications; see ISO 21217. ITS applications are identified by globally unique ITS-AID specified in
ISO 17419.
NOTE 1 In the context of an ITS station specified in ISO 21217, service advertisement is performed
[13]
according to the FSAP specified in ISO 22418. In the context of a WAVE device specified in IEEE 1609.0 ,
service advertisement is performed according to the WAVE Service Advertisement (WSA) protocol specified in
IEEE 1609.3(TM)-2016.
[17]
NOTE 2 IEEE WAVE uses globally unique PSIDs specified in IEEE 1609.3(TM)-2016 and IEEE 1609.12 to
identify ITS applications. ITS-AID and PSID share a common number space.
ITS services are typically 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
ITS-AID is specified in ISO 17419 as an unsigned integer. ITS-AID shares a common number space with
IEEE PSID, see IEEE 1609.3(TM)-2016. ITS-AID and PSID are synonyms; in the given context they are
presented by the same ASN.1 type. The purposes of ITS-AID are specified in ISO 17419; ITS-AID may be
used at the OSI transport layer to identify a destination, as specified in 5.5.1, for example.
12 © ISO 2021 – All rights reserved
ITS-AID values for service advertisement protocols (applications) are assigned to:
— WAVE Service Advertisement (WSA) specified in IEEE 1609.3(TM)-2016;
— Fast Service Advertisement Protocol (FSAP) specified in ISO 22418;
[19]
— ETSI Service Announcement Protocol (ESAP) specified in ETSI EN 302 890-1 ;
NOTE Assigned PSID numbers are presented at https:// standards .ieee .org/ products -services/ regauth/
psid/ public .html, and at http:// its -standards .info/ ITS %20Registries/ ISO17419/ ITSaidRegistry .html. PSID and
ITS-AID share a common number space.
6.2.2 ITS port numbers (ITS-PNs)
ITS-PNs are 2-octet unsigned Integer numbers specified in ISO 17419. ITS-PN is defined for usage at the
[9]
OSI transport layer by the "Fast Networking & Transport Protocol" to identify source and destination
of a message, as specified in 5.5.2, for example. For some ITS-PNs, acronyms are introduced in ISO 17419,
e.g. the acronym PORT_SAM for the well-known ITS-PN = 1 identifying the service advertisement
protocol (i.e. used by FSAP in ISO 22418).
The well-known ITS-PN PORT_SAM is used to identify the service advertisement protocol that is
receiving broadcast service advertisement messages SAM.
A dynamically assigned ITS-PN PORT_DYN_SAM is used to identify the service advertisement protocol
that is receiving unicast SAMs. The dynamic assignment is performed 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 performed 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 SAP with the name
"Service Advertisement Protocol" is used to simplify reading of the document.
6.4 Service advertisement message (SAM)
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
in ISO 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. The SRM is also used
to indicate interest in an offered service that requires usage of a privately allocated communication
channel.
NOTE SRM is not supported in IEEE 1609.3(TM)-2016.
6.4.2 Message structure
Figure 14 illustrates the basic format of the 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
used in IEEE 1609.3(TM)-2016 and ISO 22418.
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),
14 © ISO 2021 – All rights reserved
---
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...