S02P00- Networks v2.1.

1 (2020-12)

S02- Onboard Architecture

specification
Part00- Networks and Protocols

Published S02P00- Networks v2.1.1 (2020-12) 1/29

 Information Technology for Public Transport (ITxPT)
Rue Sainte-Marie 6, B-1080 Brussels | Belgium
Tel +32 (0)2 673 61 00 | Fax +32 (0)2 660 10 72
info@itxpt.org | www.itxpt.org
International non-profit making association (AISBL) incorporated by
Royal Decree and the Belgian Ministry of Justice under Belgian law
WL22/16.729 on 4th May 2016.

Important notice

The present document can be downloaded from

https://wiki.itxpt.org/index.php?title=ITxPT_Technical_Specifications.

The present document may be made available in electronic versions and/or in print. The
content of any electronic and/or print versions of the present document shall not be
modified without the prior written authorization of ITxPT. In case of any existing or
perceived difference in contents between such versions and/or in print, the prevailing
version of an ITxPT deliverable is the one made publicly available in PDF format at
https://wiki.itxpt.org.

Users of the present document should be aware that the document may be subject to
revision or change of status. Information on the current status of this and other ITxPT
documents is available at https://wiki.itxpt.org/index.php?title=Releases.

If you find errors in the present document, please send your comment to the technical
support https://itxpt.org/membership/contact-us.

Copyright Notification

All rights reserved. This document has been produced and approved by ITxPT and
represents the views of those members who participated.

The content of the PDF version shall not be modified. The copyright and the foregoing
restriction extend to reproduction in all media.

Users of the present document should be aware that the document may be subject to
revision or change of status. Information on the current status of this and other ITxPT
documents is available at wiki.txpt.org

© ITxPT 2020
All rights reserved.

Published S02P00- Networks v2.1.1 (2020-12) 2/29

Preface
This Specification has been produced by ITxPT Technical Committee. It is based on
ITxPT Working Groups outcomes, implementation and labeling experience feedbacks.
This document is part 0 of the ITxPT S02 specification dedicated to Onboard
Architecture. This S02 specification is split into:
- S02-P00: Network and Protocols (this document)
- S02-P01: Inventory service
- S02-P02: Time service
- S02-P03: GNSSLocation service
- S02-P04: FMStoIP service
- S02-P05: VEHICLEtoIP service
- S02-P06: AVMS service
- S02-P07: APC service
- S02-P08: MADT service
- S02-P09: MQTT Broker service

Mandatory requirements
Some technical requirements are mandatory to comply with ITxPT architecture. Such
technical requirements are the minimum features to implement ITxPT architecture
and ensure interoperability at technical level.
This Mandatory icon indicates these mandatory technical requirements in

M the document. Note that mandatory requirements can apply when

optional feature are implemented.

Be aware!
Each operational implementation may request optional requirements to fulfil its
functional design beyond the minimum mandatory technical requirements.

Modal verbs terminology

In the present document "shall", "shall not", "should", "should not", "may", "need not",
"will", "will not", "can" and "cannot" are to be interpreted as described below.
"must" and "must not" are NOT allowed in ITxPT deliverables except when used in
direct citation.
In order to be able to claim compliance with an ITXPT deliverable, the user needs to
be able to identify the requirements that are obligatory. The user also needs to be
able to distinguish these requirements from other provisions where there is a certain
freedom of choice.
This clause is clearly stating the verbal form that shall be used to express a particular
kind of provision, i.e. a requirement, a recommendation or a permission.

Published S02P00- Networks v2.1.1 (2020-12) 3/29

In the first column of tables T1 to T4 the verbal form that shall be used to express each
kind of provision is given. The equivalent expressions given in the second column may
be used only in exceptional cases when the form given in the first column cannot be
used for linguistic reasons
NOTE: Only singular forms are shown.
The verbal forms shown in Table T1 shall be used to indicate requirements strictly to
be followed in order to conform to the standard and from which no deviation is
permitted. For example, the requirements to be followed may relate to values, actions,
features to be supported and/or used or presence/absence or optional elements.

Verbal form Equivalent expressions used in exceptional cases1

shall is to
is required to
it is required that
has to
only ... is permitted
it is necessary
shall not is not allowed [permitted] [acceptable] [permissible]
is required to be not
is required that ... be not
is not to be
Table T1 - Requirement

The verbal forms shown in Table T2 shall be used to indicate that among several
possibilities one is recommended as particularly suitable, without mentioning or
excluding others, or that a certain course of action is preferred but not necessarily
required, or that (in the negative form) a certain possibility or course of action is
deprecated but not prohibited. For example, the recommendations may relate to
values, actions, features to be supported and/or used or presence/absence or optional
elements.

Verbal form Equivalent expressions used in exceptional cases1

should it is recommended that
ought to
should not should not it is not recommended that
ought not to
Table T2 - Recommendation

The verbal forms shown in Table T3 shall be used to indicate what is permitted by the
ITXPT deliverable, which can be values, actions, support and /or use of features or
presence/absence of optional elements.

Verbal form Equivalent expressions used in exceptional cases1

may is permitted

1
"exceptional cases" means where the use of verbal form would change the meaning
of the sentence or make it difficult to understand.

Published S02P00- Networks v2.1.1 (2020-12) 4/29

 is allowed
is permissible
may not it is not required that
no ... is required
Table T3 - Permission

The verbal forms shown in Table T4 shall be used for statements of possibility and
capability, whether material, physical or causal.

Verbal form Equivalent expressions used in exceptional cases1

can be able to
there is a possibility of
it is possible to
cannot be unable to
there is no possibility of
it is not possible to
Table T4 - Possibility and capability

The verbal forms shown in Table T5 shall be used to indicate behaviour of equipment
or sub-systems outside the scope of the ITXPT deliverable in which they appear. For
example, in an ITXPT deliverable specifying the requirements of terminal equipment,
these forms shall be used to describe the expected behaviour of the network to
which the terminal is connected.

Verbal form Equivalent expressions

will -
will not -
Table T5 - Inevitability

Published S02P00- Networks v2.1.1 (2020-12) 5/29

CONTENT
Preface .................................................................................................................................................................................. 3
Mandatory requirements ......................................................................................................................................... 3
Modal verbs terminology .......................................................................................................................................... 3
1 Onboard Architecture Overview................................................................................................................ 8
1.1 Terminology .................................................................................................................................................... 8
1.2 Definition .......................................................................................................................................................... 8
1.3 IP Networks ..................................................................................................................................................... 8
Onboard Backbone IP Network (mandatory) .....................................................................9
Onboard Passenger IP Network (optional) .........................................................................10
Onboard Convoy IP network (optional).................................................................................10
1.4 Generic ITxPT onboard architecture ............................................................................................... 11
1.5 Embedded services ................................................................................................................................... 11
1.6 Hardware ......................................................................................................................................................... 12
1.7 Network address map for IPv4 .......................................................................................................... 12
Address assignment .......................................................................................................................... 12
DHCP server ............................................................................................................................................ 12
1.8 On Board to back-office IP communications .......................................................................... 12
Wireless communications compatible with IP ................................................................ 13
Wireless communication non compatible with IP ........................................................ 13
2 ITxPT onboard protocols overview ..........................................................................................................14
2.1 Service discovery protocol ....................................................................................................................14
DNS-SD.......................................................................................................................................................14
Publishing services using DNS-SD ...........................................................................................14
2.2 Data exchange protocols ...................................................................................................................... 18
Service through _itxpt_socket TCP .......................................................................................... 18
Service through _ itxpt _multicast UDP ................................................................................ 18
Service through http ......................................................................................................................... 18
Service through MQTT .....................................................................................................................24
3 ITxPT Services synthesis ................................................................................................................................ 27
History ................................................................................................................................................................................ 29

Published S02P00- Networks v2.1.1 (2020-12) 6/29

Tables list
Table 1- Class A, B or C subnets ..................................................................................................................................... 12
Table 2 – SRV record convention naming .............................................................................................................. 15
Table 3 – TXT record attributes list .............................................................................................................................. 17
Table 4 -ITxPT services overview (P01 to P09) ..................................................................................................... 27

Figures list
Figure 1- IP networks ............................................................................................................................................................. 9
Figure 2- Onboard Convoy IP network ...................................................................................................................... 11
Figure 3- MQTT client-broker ......................................................................................................................................... 25
Figure 4- Local and central broker ............................................................................................................................ 25
Figure 5- Pub/Sub pattern...............................................................................................................................................26

Published S02P00- Networks v2.1.1 (2020-12) 7/29

 1 Onboard Architecture Overview
1.1 Terminology
Following terms are used to identify the different parts composing the architecture:
• ITxPT compliant module: it consists in embedded hardware module
supporting managed power supply, Ethernet network interface and hosting
services. It can be a software module in case of virtualization.
• ITxPT compliant service: it consists in software service supporting ITxPT
technologies. This service provides interfaces to exchange data through the IP
network.
• ITxPT compliant application: it consists in piece of software hosted by ITxPT
compliant module and using ITxPT services.
• ITxPT compliant onboard architecture: it consists in onboard architecture
including a minimum set of mandatory modules and network features.
• ITxPT compliant onboard platform: it consists in ITxPT compliant onboard
architecture hosting a minimum set of ITxPT services and able to host ITxPT
compliant applications.

1.2 Definition
The Onboard architecture hosts embedded modules and services, allowing data and
resources sharing.
Service Oriented Architecture (SOA) enables to simply organize and use shared and
distributed data.
ITxPT specifies technical interfaces, then it is up to PTO and PTA to define the
functional scope of their implementation.
Services should be seen as transverse features delivering data, hosted by modules, to
be used by applications across the Onboard Backbone IP Network.

1.3 IP Networks
The Onboard architecture is composed of the following networks as described in
Figure 1 below:
- Onboard Backbone IP Network (mandatory): this is the key network of the

M architecture connecting modules together to allow connectivity between

applications inside the vehicle.
- Onboard Passenger IP Network (optional): this network allows passenger to
have a connection on Onboard Backbone IP Network trough “personal modules”
(mobile phone, notebook, tablet or other personal modules) and to access to
information available on ITxPT architecture
- Onboard Convoy IP network (optional): this network allows compliance of
ITxPT architecture with modularity concept for PT vehicles (like tramway vehicles,
buses convoy or bus with trailer for example) in order to connect Onboard
Backbone IP Networks of several vehicles in case of modularity need (tramway,
vehicle with trailer…).

Published S02P00- Networks v2.1.1 (2020-12) 8/29

 The architecture is designed using standardized and powerful internet technology
protocols and components.
Installation requirements (wiring, connectors, antenna, installation blocks, etc.) for this
Onboard architecture are described in S01- Installation Requirements Specification.

Figure 1- IP networks

Note: depending on vehicle type, the vehicle interface to Onboard Backbone IP

Network is FMStoIP (bus and coach) and/or VEHICLEtoIP.

Onboard Backbone IP Network (mandatory)

M Each vehicle shall have its own private IP network called “Onboard Backbone IP
Network” to interconnect modules and to allow connectivity between applications
inside the vehicle. This IP network allows modules to exchange data between them at
vehicle level and to communicate with one or more backoffice IP networks through
the same module called “Vehicle Communication Gateway”.
Modules on this network should be physically connected over IP media. For specific
retrofit cases, wireless connections can be evaluated on a case-by-case basis (e.g.
secure Wi-Fi).
Installation requirements (wiring, connectors, antenna, installation blocks, etc.) for this
IP network is described in S01-ITxPT Installation Requirements page and compliant
with TS13149-8.

Published S02P00- Networks v2.1.1 (2020-12) 9/29

 Onboard Passenger IP Network (optional)
This optional network allows passenger to have a connection on Onboard Backbone
IP Network trough “personal modules” (mobile phone, notebook, tablet or other
personal modules) based on dedicated ITxPT compliant modules.
For example, this network is mainly used for giving to passenger updated information
about the on-going travel and extra information for disabled people (if available).
This network uses wireless IP solutions (e.g. Wi-Fi) to connect personal modules to
personal modules gateway.
Because of network security issue, the segregation of the IP networks shall be
ensured. The Onboard Passenger IP Network shall be configured with relevant and
up-to-date security protocols recommended by security experts (e.g.: DMZ, VLAN,
proxies, NAT…).
Components expected to be connected on “Onboard Passenger IP Network” are the
following:
• Onboard wireless access point(s) (dedicated)
• Passenger modules (mobile phone, notebook, tablet or other personal
modules)
• Vehicle stop point systems without backoffice connection may use this
connection to update and synchronize their information while vehicles are at
the vehicle stop point

Onboard Convoy IP network (optional)

This optional network allows compliance of ITxPT architecture with modularity
concept for PT vehicles.
When different vehicles are linked between them for modularity concept (like
tramway vehicles, buses convoy or bus with trailer for example), a private IP network
called “Onboard Convoy IP Network” allows vehicles in a modular convoy to exchange
operating data between them.
This network shall use IP medium for connection between vehicles. Router
functionalities between “Onboard Backbone IP Network” and “Onboard Convoy IP
Network” shall be included.
On this network, the “module inventory” is available as described below. However not
all services can be reached from this network.
Typically, the master vehicle (the first one in the convoy) synchronizes module
inventory from all vehicles within the convoy. Some modules and services can be
shared between the vehicles in the convoy like MADT (see S02-P08) or AVMS (see S02-
P06).
When vehicles are connected, the VEHICLEtoIP service has to indicate “convoy mode”
and has to report what Physical VIN’s were found in the convoy and in which order.
VEHICLEtoIP service shall also give information about master and slave mode. These
requirements have to be considered by vehicles manufacturers.

Published S02P00- Networks v2.1.1 (2020-12) 10/29

This concept requires two Ethernet ports in the Vehicle Communication Gateway
dedicated to the onboard Convoy IP network:

• one port for the front side

• one for the rear side
(or one port in the gateway together with an Ethernet switch).
Figure 2 describes the “Onboard Convoy IP Network” in a modular vehicle convoy and
shows modules and other networks interfaces:

Figure 2- Onboard Convoy IP network

Note: In this diagram, a modular Manufacturer Network appears. This additional

network appears here only to identify that manufacturer CANs shall be
interconnected in a modular vehicle convoy. This link is the responsibility of the
vehicle manufacturer.
All “Vehicle Communication Gateways” of each vehicle that are part of the modular
vehicle convoy shall be allowed to connect on this “Onboard Convoy IP Network”.

1.4 Generic ITxPT onboard architecture

There is not only one single definition of an ITxPT onboard architecture. Depending on
implementation and integration choices (modules, application, service…), onboard
architecture compliant with ITxPT can take various shapes and forms.
For this reason, an ITxPT generic compliant architecture is specified. It includes
mandatory modules and services, as defined in S01- ITxPT Vehicle Installation
Requirements specifications.

1.5 Embedded services

The following embedded services are detailed in this specification.
• Module Inventory
• Time
• GNSS Location
• FMStoIP
• VEHICLEtoIP
• Advanced Vehicle Monitoring System - AVMS
• Automatic Passenger Counting - APC

Published S02P00- Networks v2.1.1 (2020-12) 11/29

 • Multi-Application Driver Terminal - MADT
• MQTT Broker

1.6 Hardware
Each module connected on the Onboard Backbone IP Network shall be equipped
with a standard physical Ethernet interface. The detailed specification of wiring and
connectors is described in S01- ITxPT Vehicle Installation Requirements specifications.

1.7 Network address map for IPv4

For onboard IP networks using IPv4, address assignment should respect the private
address map described in the RFC1918. Depending on the size of the network, class A,
B or C subnets may be implemented, as summarised in the table below.

RFC1918 IP address number classful description largest CIDR host

name range of block (subnet id
addresses mask) size
24-bit 10.0.0.0 – 16,777,216 single class A 10.0.0.0/8 24
block 10.255.255.255 (255.0.0.0) bits
20-bit 172.16.0.0 – 1,048,576 16 contiguous class Bs 172.16.0.0/12 20
block 172.31.255.255 (255.240.0.0) bits
16-bit 192.168.0.0 – 65,536 256 contiguous class 192.168.0.0/16 16
block 192.168.255.255 Cs (255.255.0.0) bits
Table 1- Class A, B or C subnets

In vehicle onboard context, the 256 contiguous class C space is sufficient for most
architecture needs. This covers the respective needs of each of the three onboard IP
networks (backbone IP network, passenger IP network, convoy IP network). Other
classes may be considered in case of specific needs.
The defined IP address range is 192.168.x.0 to 192.168.x.255, where x could be defined at
the time of implementation.

Address assignment
All modules shall support address assignment by static address assignment and
dynamic address assignment (dhcp) as configured by the end-user. Static and
dynamic address assignment shall be implemented/supported as described in TS
13149-7:2019 “Manual assignment” and “DHCP assignment” (“Self assignment” and
“Mixed assignment” are optional).

DHCP server
Any module that supports a DHCP server shall follow TS 13149-7:2019 “DHCP
assignment”.

1.8 On Board to back-office IP communications

In order to allow exchanges between “Onboard IP Networks” and "Back-office IP
networks", router functionalities shall be included and configured with relevant and

Published S02P00- Networks v2.1.1 (2020-12) 12/29

up-to-date security protocols recommended by security experts, allowing to
communicate with this vehicle.
Two use-cases are considered:
- Public network: if “public” IP carriers (e.g. Internet connections) are used from
the vehicle to access the Back Office, VPN tunnelling shall be used.
- Private network: using a dedicated private APN from mobile operator

Wireless communications compatible with IP

These allow communications between “Onboard IP Networks” and "Back-office IP
networks" with several compatible IP wireless media.
This feature allows modules connected to “Onboard Backbone IP Network” to
communicate with backoffice modules and/or others “Vehicle Communication
Gateways”.
Examples of current IP communications technologies are:

• Long range
• Mobile Phone technologies (GPRS, EDGE, UMTS, 3G, 4G)
• WCDMA
• WiMAX
• Short range
• Wi-Fi
• Bluetooth

Wireless communication non compatible with IP

It may provide gateway functionalities between “Onboard IP Networks” and Back-
office Networks with wireless connection non compatible with IP. This type of
communications is out of ITxPT scope.
Even though TETRA (TErrestrial Trunked RAdio) communication medium is out of
ITxPT scope, it can be deployed and used for PT (mainly for big urban networks). As
such, it is not excluded from an IT architecture.

Published S02P00- Networks v2.1.1 (2020-12) 13/29

 2 ITxPT onboard protocols overview

M 2.1 Service discovery protocol

DNS-SD
This chapter describes DNS Service Discovery (DNS-SD) which is the underlying
technology used for the publication and discovery of services on the Onboard IP
Network.
This protocol is compliant with TS13149-7.
DNS-SD is defined in RFC 6763. It uses standard DNS programming interfaces, servers,
and packet formats (PTR, SRV and TXT records).
DNS-SD is recommended to be used with mDNS. DNS-SD is supported by mDNS but
does not require it. mDNS is defined in RFC 6762.
A summary of the main attributes for a service specification will be described.

Each published service on the Onboard Backbone IP Network should be unique.

However, redundancies are allowed if requested by the implementation (e.g. GNSS
location service can be published by two modules for security backup in case of
service disruption). In that case, the fields “priority” and “weight” in SRV records can be
used for priority management.
The minimum set of network features allowing to setup and use ITxPT services
(according to DNS-SD functionalities) are:
• Publish service
Allow to declare service with its name, associated with some attributes like URL
entry name, used port number and supported protocol.

• Update service
Allow to update information about a declared service.
Updating a service is accomplished by first making sure the old information is
discarded. Then, if the service is updated, it has to be publish again with the new
attributes.
• Browse service
Allow to access to the list of available services.

Some tools to browse ITxPT architecture and services are described in ITxPT tools
page.

Publishing services using DNS-SD

ITxPT specification to publish IP services is based on and complies with TS13149 part-7
and RFC 6763.
The DNS-SD name of a service should communicate both the what and how of a
service.
The purpose of the SRV record is to give the location of a service. And the TXT record
gives additional information about the service. These DNS records are published
through multicast DNS (mDNS).

Published S02P00- Networks v2.1.1 (2020-12) 14/29

 SRV record naming convention
The SRV record consists of the following attributes:

<UniqueIdentifier>_<Name>._<Type>._<Protocol>.<Domain>
TTL class SRV priority weight port target

Note: underscore is used as separator between UniqueIdentifier and Name. It shall

not be used in UniqueIdentifier and Name.
Table 2 – SRV record convention naming below defines each field of the SRV records:

Field Definition Value (example)

UniqueIdentifier Network unique identifier to avoid conflicts 979924c0-b5a9
with ambiguous names.
It can be an arbitrary distinct number, the
host name, the serial number, etc.
It shall not content the character “_”

Name Functional (application) description of the avms

service
Type Application protocol name (can be itxpt_http
itxpt_http, sntp…)
Protocol the transport protocol name of the service tcp
(tcp or udp)
Domain domain name for which this record is valid local
TTL standard DNS time to live field 120
Class standard DNS class field (always “IN” for IN
Internet)
“SRV” SRV
Priority priority of the target host, lower value 0 (configurable)
means more preferred
Weight relative weight for records with same 0 (configurable)
priority, higher = more preferred
Port TCP or UDP port on which the service is to 8000
be found
Target canonical hostname of machine providing [hostname]
the service
Table 2 – SRV record convention naming
The service convention naming consists of several fields following the established
convention for SRV records:

• all fields shall not include spaces or tabs

• service name, type, protocol fields start with an underscore “_”
• no more than fourteen characters shall be used (not counting the mandatory
underscore for the related fields).
• for ITxPT service type, only lower-case letters, digits, and hyphens shall be used
(and each field shall begin and end with lower-case letter or digit).
• _<protocol> field shall be _tcp or _udp (no other value possible)
As an example, the following value can be implemented for AVMS service:

Published S02P00- Networks v2.1.1 (2020-12) 15/29

 979924c0-b5a9_avms._itxpt_http._tcp.local 120 IN SRV 0 0 8000 [hostname]

TXT record
For providing more information (e.g. multicast address for multicast services or
versions of different services) the TXT records are used.

<UniqueIdentifier>_<service name>._<type>._<protocol>.<domain> TTL

class TXT “name=value”

Table 3 below shows the exhaustive list of attributes currently specified in the services
of each S02 part. Any additional or other attributes can be implemented for specific
services (e.g. module location, characteristics...).
Relevant attributes shall be implemented according to services specification from
each S02 part.

Attribute Name Mandatory Type Description Example

/ optional
txtvers Mandatory integ Recommended key txtvers=1
er for version of TXT
record, default 1
version Mandatory string Version of the version=2.1.1
related ITxPT
specification release
for this service
swvers Optional string Version of the swvers=1.3.4
supplier’s
implementation of
this service
type Mandatory string Short name of type=VCG
module type
multicast Mandatory string Multicast address, multicast=
for where the data is 239.255.42.22
multicast provided
service
serialnumber Mandatory string Serial number of serialnumber=
the module. SN0123456789
model Mandatory string The model of the model=newmodule
module.
manufacturer Mandatory string The manufacturer manufacturer=
of the module modulemanufacturer
macaddress Mandatory string The MAC address of macaddress=
the module as HEX, CF:DA:98:63:9D:F6
with “:” separating
the bytes
softwareversion Mandatory string The software softwareversion =v1.2.3
version installed on
the module
hardwareversion Mandatory string The hardware hardwareversion=
version of the revision D
module.
path Mandatory string The URL to be path=avms/
for http appended to the
service hostname and port

Published S02P00- Networks v2.1.1 (2020-12) 16/29

Attribute Name Mandatory Type Description Example
/ optional
from the SRV record
for a HTTP-request
submodules Optional boole When set to true, submodules=true
an the page residing at
path shall contain
inventory-
information of
submodules not
reachable from the
IP network (external
devices like RS485
displays etc).
status Mandatory integ A non-negative integer status=0
er that contains the last
error detected during
selftest, the value zero
means no error.
xstatus Optional hexstr Detailed module xstatus=
ing status C000000000C0FFFF
brand Mandatory string Brand of the broker brand=mosquitto
proto Mandatory string Protocol versions proto=3.1.1
supported
topic Mandatory string Root topic structure topic=app/

services Mandatory string Available list of services=

(only for services inventory;avms;
module
inventory
service)
operations Mandatory string Available list of operations=runmonitoring;
(only for operations plannedpattern
each
service
supporting
operations)
sntp-host Optional string IP address of SNTP sntp-host=241.524.125.253
server (if not the
host of time service)
timezone Optional string Local offset : timezone=UTC+01:30
UTC+HH:MM
Table 3 – TXT record attributes list

Changing srv- and txt-record values

The values present in srv- and txt-records tables in this specification are examples.
Any client application should read the values from the srv- and txt-records and use
those values. If the system and the client application would work identically with
different values than those provided, then they can be changed. If there could be a
difference, then the value should remain as suggested.
As an example some of the http services have port=80 in the specification. This port is
not (necessarily) available on an Android based system; setting e.g. port=12345 is

Published S02P00- Networks v2.1.1 (2020-12) 17/29

allowed. Similarly “path=yourownplace/” is allowed; the reason it is in txt-record is so it
can be changed at need.
That said, there is currently no compliance test for clients. We recommend having the
suggested values as the default unless this is not possible, and to communicate
deviations from suggested values clearly.

2.2 Data exchange protocols

Service through _itxpt_socket TCP
Services declared as “_itxpt_socket” shall implement TCP transport protocol. Standard
socket is considered as low-level interface to have access to ITxPT services. To use
service through “low level” interface service type name shall be “_itxpt_socket”.
Regarding specificities of MADT service, the use of JSON format is applied.

Service through _ itxpt _multicast UDP

Services declared as “_itxpt_multicast” shall implement UDP transport protocol. The
use of XML format is mandatory to exchange data on IP network multicast-based
services.
The default address for “_itxpt_multicast” shall be 239.255.42.21 All multicast services
have to announce the address using the multicast attribute in the TXT record.
Port number is defined for each service.
Client shall get UDP message listening multicast address. Related delivery cycle is
defined for each multicast service.
Such multicast services will contain additional information in their TXT records
including mandatory multicast attribute.

Service through http

Data model & data type

Services declared as “_itxpt_http” shall implement TCP transport protocol. The use of
structured data that can be validated (xml, json, etc) is mandatory to exchange data
on IP network for http-based services.
In case of needing low level data format (binary or hexadecimal), the transmitted data
shall be encapsulated in the structured data, not sent on its own.
Example:
<data>F35237C403501FFF</data>
ITxPT uses a number of standard W3C XML, SIRI and Transmodel data types.
Identifiers should be defined during the implementation in a common agreement
between providers of the service producer and the service consumer.
Note: examples of AVMS terms and definitions are available on ITxPT documentation
centre in dedicated Transmodel page

Published S02P00- Networks v2.1.1 (2020-12) 18/29

 Http headers
This section contains general recommendations for http headers in itxpt http services.
The specification for each service may specify a different/stricter handling. There is no
intent to modify RFC 7230/7231, only to set an ITxPT convention for usage within the
scope of the applicable RFCs.

2.2.3.2.1 Content-Type
Setting Content-Type header is not required of the clients, and the service should
accept requests both without and with Content-Type set, and the request shall be
processed as if content-type was not set.
It is recommended for the clients to set Content-Type. It is strongly recommended
that the service sets Content-Type in replies.
Content-Type application/xml, application/json should be used; text/xml and text/json
implies the content will be read by humans, which is not the case for the ITxPT http
services.

2.2.3.2.2 Content-Length
Setting Content-Length header is not required of the clients, and the service should
accept requests both without and with Content-Length set and do a best-effort
attempt to process the request. Only if that fails may a response code 411 Length
Required be sent.
It is strongly recommended that both clients and services set Content-Length.

2.2.3.2.3 Accept
Accept header is not required of the clients, and the service should accept requests
both without and with Accept set, and the request shall be processed as if accept
header was not set.
However it is still recommended for the clients to set the correct accept header. For
preferred content types to use, see Content-Type above.

Data exchange
To use service through “high level” interface service type shall be “_itxpt_http”.
It uses http commands get and post to access data.
This is one of the recommended service types to be used on ITxPT architecture.
The transport protocol shall be tcp.
There are three kinds of requests:
- Subscription request
Standard HTTP “post” method allows requesting a subscription. XML contents
will be automatically sent through HTTP “post” method at the reply address.
- Unsubscription request
Standard HTTP “post” method allows to cancel a subscription. XML contents
will be automatically sent through HTTP “post” method at the reply address.
- Asynchronous request (optional)

Published S02P00- Networks v2.1.1 (2020-12) 19/29

 Standard HTTP “get”, or “post” methods allow to access data content, XML
result will be sent back to the consumer application.

2.2.3.3.1 Subscription/Unsubscription Request

In this case, the client sends an initial subscription request to the “_itxpt_http”
interface, using POST method, for each required operation name, and gives an _http
access point for the later service message distribution.
Afterwards the service will POST contents to http client access point, starting with an
initial sending at client subscription. After, the next POST will be sent event triggered
at a change of a data element within the dataset according to the predefined
distribution rules described for each service.
The path used for the subscription and unsubscription requests is described in each
related service content specification.
An unsubscription request could be sent by the client if necessary.
Subscriptions are linked to http client reply access point. A new subscription request
for an existing subscriber (e.g. client application restart without clean termination) will
not define a new subscription, but rather will update the current state of the initial
subscription.
Subscribe request message:
<SubscribeRequest>
<Client-IP-Address> Address </Client-IP-Address>
<ReplyPort> Port </ReplyPort>
<ReplyPath> Path </ReplyPath>
<arguments>
<argument name=”xxx” value=”xxx” />
<argument name=”xxx” value=”xxx” />
</arguments>
</SubscribeRequest>
Unsubscribe request message:
<UnsubscribeRequest>
<Client-IP-Address> Address </Client-IP-Address>
<ReplyPort> Port </ReplyPort>
<ReplyPath> Path </ReplyPath>
</UnsubscribeRequest>
Answer message to subscribe and unsubscribe:
<SubscribeResponse>
<Active> true / false </Active>
</SubscribeResponse>

Published S02P00- Networks v2.1.1 (2020-12) 20/29

Delivery messages to subscriber:
Delivery message is described in related service content specification.
Generic subscription and unsubscription example:

Client Service

POST /service/operationpath HTTP/1.1

<?xml version="1.0" encoding="UTF-8"?>
<SubscribeRequest>
<Client-IP-Address>169.254.1.37</Client-IP-Address>
<ReplyPort>1698</ReplyPort>
<ReplyPath>/ReplyPath/1</ReplyPath>
</SubscribeRequest>

HTTP/1.0 200 OK
Date: Mon, 7 Oct 2019 13:52:09 GMT
Content-Type: application/xml
Content-Length: 109
<?xml version="1.0" encoding="UTF-8"?>
<SubscribeResponse>
<Active>true</Active>
</SubscribeResponse>

POST /HTTP/1.0 200 OK

Date: Mon, 7 Oct 2019 13:52:09 GMT
Content-Type: application/xml
Content-Length: 346
<?xml version="1.0" encoding="UTF-8"?>
<ServiceDelivery version=”1.1a”>
<Service>
…
…
</Service>
</ServiceDelivery>

HTTP/1.0 200 OK
Date: Mon, 7 Oct 2019 13:52:09 GMT
Content-Type: application/xml
Content-Length: 0

Client Service

POST /service/operationpath HTTP/1.1

<?xml version="1.0" encoding="UTF-8"?>
<UnsubscribeRequest>
<Client-IP-Address>169.254.1.37</Client-IP-Address>
<ReplyPort>1698</ReplyPort>
<ReplyPath>/ReplyPath/1</ReplyPath>
</UnsubscribeRequest>

HTTP/1.0 200 OK
Date: Mon, 7 Oct 2019 13:52:09 GMT
Content-Type: application/xml
Content-Length: 109
<?xml version="1.0" encoding="UTF-8"?>
<SubscribeResponse>
<Active>false</Active>
</SubscribeResponse>

2.2.3.3.2 Asynchronous Request

In this case, the client application uses an http “get” method for a service to the
“_itxpt_http” interface, and the service returns an XML answer with the associated
service message.
Standard HTTP “post” method should be used in case service request includes xml
body.
The timing of the asynchronous request is under the responsibility of the client
application.
Asynchronous request message:

Published S02P00- Networks v2.1.1 (2020-12) 21/29

By using the “get” http method without parameter at the URL of the respective
operation, there is no message in the request body.
By using the “post” http method (e.g. FMStoIP), the message is passed through the
request body.
Answer message:
Delivery message is described in related service content specification.

Http response codes

Note: The scope of 2.1.1 update is “no implementation impact”. To allow for this,
this section on response code shall be regarded as a
recommendation/guideline for 2.1.1 implementation and compliance test. It will
probably become mandatory in the next revision of the spec.
If the request has been successful a 2XX http response code is expected in the reply. If
the client receives a 2XX code it shall be able to assume things have gone well and not
enter any error handling code. If the request has been unsuccessful, we expect an
error http response code, which is usually one of the codes below.

Response code Description

200 OK Request accepted, response contains result.
This is a general-purpose response code
that can be returned from any request. For
GET requests, the requested resource or
data is in the response body. For PUT or
DELETE requests, the request was
successful and information about the result
(such as new resource identifiers, or
changes in resource status) can be found in
the response body.
201 CREATED This response code is returned from PUT or
POST and indicates that a new resource was
created successfully. The response body
might for example contain information
about a new resource, or validation
information (for example, when an asset is
updated).
400 BAD REQUEST The request was not valid. This code is
returned when the server has attempted to
process the request, but some aspect of the
request is not valid, for example an
incorrectly formatted resource or an
attempt to deploy an invalid event project

Published S02P00- Networks v2.1.1 (2020-12) 22/29

 to the event runtime. Information about the
request is provided in the response body
and includes an error code and error
message.
404 NOT FOUND Indicates that the targeted resource does
not exist. This might be because the URI is
malformed, or the resource has been
deleted.
405 METHOD NOT ALLOWED Returned when the targeted resource does
not support the requested HTTP method;
for example, the functions resource only
allows GET operations.
406 NOT ACCEPTABLE The data format requested in the Accept
header or accept parameter is not
supported by the targeted resource. That is,
the client has requested that data is
returned in a particular format, but the
server is unable to return data in that
format.
409 CONFLICT Indicates that a conflicting change has been
detected during an attempt to modify a
resource. The response body provides
further information.
415 UNSUPPORTED MEDIA TYPE The data format of the request body,
specified in the Content-Type header, is
unsupported by the targeted resource.
500 INTERNAL SERVER ERROR An internal error occurred in the
server/service. This might indicate a
problem with the request or might indicate
a problem in the server/service side code.
Error information can be found in the
response body.
This is a general list of response codes that are (most) likely to be needed by itxpt http
services. This list may be extended or restricted by the specification of each service.
Some of the response codes above are only applicable if a Technical Specification
requires a stricter handling than what is outlined in these general
Other response codes are allowed when appropriate/needed. See RFC 7231 for a list of
all specified response codes.

2.2.3.4.1 Populating the response body

For all error responses it is recommended that further information about the error is
included. The content is not standardized, but the expectation is that a developer
should be able to look at the response and understand what caused the error.

Published S02P00- Networks v2.1.1 (2020-12) 23/29

For 2XX responses (and potentially others) that does not include a body response (e.g.
fmstoip addpng) it is recommended that the body is used to indicate the result of the
operation and the current state of the service. This is intended as human-readable
information to be used during development or later QA/debug activities.

2.2.3.4.2 Partially successful requests

For requests that are partially successful (step 1 ok, step 2 fail; resource X created,
resource Y fail) the best outcome is if the state can be rolled back to what it was
before request processing started and an error response code returned. (Note that it
is not sufficient to just reverse any successful action. E.g. if on an addpng(X, Y) X is ok
and Y fail, removepng(x) will not restore the state, as X may have been in the
subscribe list prior to the addpng(X...) operation.
If rollback is not possible, then the service shall return the response code that is the
most useful to client application. If this is not clear, an error response code shall be
preferred.
This does not apply to requests where the partial success is clearly understood from
the TS-required response. E.g. if FMS frames A, B and C is requested and only A and B
can be returned, this is obvious from the response. A 200 OK code with A and B is the
expected response.

Service through MQTT

The use of JSON format is recommended to exchange data on IP network for mqtt
based services.
Note: the implementation of MQTT protocol shall not create supervision mechanism
that could limit ITxPT plug and play mechanisms: new ITxPT services do not have to
be approved by any other IT Module to be published on ITxPT architecture.

Description & Use-Cases

The Message Queuing Telemetry Transport - MQTT protocol is a protocol designed for
the asynchronous transfer of small packets of data. The current version is officially
approved as OASIS standard as well as ISO/IEC 20922:2016 standard, MQTT 3.1.1.
MQTT uses a pub/sub pattern that decouples clients from who is sending and who is
receiving. Clients do not know the existence of each other, because of a third
component: the broker. A broker filters all incoming messages and distributes them.
This makes it more scalable than a traditional client-server approach. The publisher
and subscriber only need to know hostname/IP and port of the broker that in an ITxPT
based platform is announced over DNS-SD.

Architecture & Transport Protocol

A MQTT client can be a publisher or a subscriber, and it can be any device from a
micro controller to a full spec server. All it needs is to run a MQTT library and connect
to a broker, so it can be any device that has a TCP/IP stack and can speak MQTT.
The MQTT broker is the heart of the pub/sub environment, and is responsible for
receiving all messages, filtering, deciding who is interested and sending. It handles

Published S02P00- Networks v2.1.1 (2020-12) 24/29

sessions with subscriptions and missed messages, as well as the authentication and
the authorization of clients.

Figure 3- MQTT client-broker

Connection is done through clients that initiate connection to broker, where broker
accepts. Connections are open if the client does not disconnect or loses connection.

2.2.4.2.1 Local and central MQTT broker

The local broker is the heart of pub/sub pattern on each vehicle, and is responsible for
receiving, handling and sending messages from and to clients. It can also be
responsible for bridging messages to a central MQTT broker.
The central broker is responsible for receiving, handling and sending messages from
and to all local brokers in vehicles that are part of a fleet or operator.

Figure 4- Local and central broker

2.2.4.2.2 Publish and subscribe messages

The broker performs topic-based filtering of messages, where each message shall
contain a topic which will be used by the broker to forward the message to interested

Published S02P00- Networks v2.1.1 (2020-12) 25/29

clients with a payload. The payload contains the actual data transmit in byte format
and can be structured differently. This is up to the sender. The broker will read the
publish, acknowledge if needed and process it to determine which clients have
subscribed. Clients send subscribe message to broker to receive and contains a list of
subscriptions. Each subscription is a pair of topics and QoS level.
MQTT has 3 QoS levels related to delivery of messages.
• 0 – at most once (fire and forget)
• 1 – at least once (guaranteed delivery at least once)
• 2 – exactly once (guaranteed only once)

Publication can also be done using a “retain” flag, that ensures that new subscribers
will receive the last published message.

Figure 5- Pub/Sub pattern

Published S02P00- Networks v2.1.1 (2020-12) 26/29

3 ITxPT Services synthesis
On-board module types are listed and mapped in S01 with the related mandatory services detailed in S02 specifications.
The SRV record of all ITxPT services Operation is listed below with default/example values filled in.

<UniqueIdentifier>_<Name>._<Type>._<Protocol>.<Domain>
TTL class SRV priority weight port target

Field Part 01 Part 02 Part 03 Part 04 Part 05 Part 06

Module Inventory Time GNSS location FMStoIP Service VEHICLE to IP AVMS
Service Service Service Service Service
UniqueIdentifier [UniqueIdentifier] [UniqueIdentifier] [UniqueIdentifier] [UniqueIdentifier] [UniqueIdentifier] [UniqueIdentifier]
Name inventory time gnsslocation fmstoip vehicletoip avms
Type itxpt_socket sntp itxpt_multicast itxpt_multicast itxpt_multicast itxpt_http
or
itxpt_http
Protocol tcp udp udp udp udp tcp
Domain local local local local local local
TTL 120 120 120 120 120 120
class IN IN IN IN IN IN
“SRV” SRV SRV SRV SRV SRV SRV
priority 0 0 0 0 0 0
weight 0 0 0 0 0 0
port 9 (for socket) 123 14005 15015 15030 8000
or
80 (for http)
target [hostname] [hostname] [hostname] [hostname] [hostname] [hostname]
mandatory optional optional optional Optional optional
M

Table 4 -ITxPT services overview (P01 to P09)

S02P00- Networks v2.1.1 (2020-12) 27/29

 Field Part 07 Part 08 Part 09
APC MADT MQTT broker
Service Service Service
UniqueIdentifier [UniqueIdentifier] [UniqueIdentifier] [UniqueIdentifier]
Name apc madt mqtt-broker
Type itxpt_http itxpt_socket mqtt
Protocol tcp tcp tcp
Domain local local local
TTL 120 120 120
class IN IN IN
“SRV” SRV SRV SRV
priority 0 0 0
weight 0 0 0
port 9000 25000 1883
target [hostname] [hostname] [hostname]
optional optional optional

S02P00- Networks v2.1.1 (2020-12) 28/29

History

Document history
V1.0.0 December 2015 Publication
v2.0.0 September 2018 • Previous section “3 – Hardware” moved into 1. sub-section
of 1
• New harmonised structure for service description
• Introduction of new APC Service: section 3.7 (source: ITxPT
WG#7)
• Introduction of new and updated MADT service: section 3.8
(source: EBSF_2)
• Introduction of new MQTT broker Service: section 3.9
(source ITxPT WG#6)
v2.0.1 November 2018 Corrective update:
• Re-alignment of data type
V2.1.0 July 2019 • S02 Split into parts
• Alignment with TS13149
• Clarification
v2.1.1 October 2020 Some additions (no required implementation impact):
• Section about changing srv- and txt-record values
• New sections on http headers and http response
codes
• Various minor clarifications

S02P00- Networks v2.1.1 (2020-12) 29/29