SIST-TP CLC/TR 50501-2:2012

SLOVENSKI STANDARD
01-oktober-2012
äHOH]QLãNHQDSUDYH9R]QDVUHGVWYD0HGVHERMQDNRPXQLNDFLMDPHGQDSUDYDPL
QDåHOH]QLãNLKYR]LOLKDOLPHGQMLPLLQSURJRYQLPLQDSUDYDPLGHO7HKQLþQD
YVHELQDVWDQGDUGL]DFLMVNHJDGHODQDSRGURþMXPHGVHERMQHNRPXQLNDFLMH
Railway applications - Rolling stock - Intercommunication between vehicles and
train/wayside - Part 2: Technical contents of standardization work in the field of
intercommunication
Bahnanwendungen - Interkommunikation zwischen Fahrzeugen und Fahrweg - Teil 2:
Technischer Inhalt der Normung auf dem Gebiet der Interkommunikation
Applications ferroviaires - Matériel roulant - Communications entre véhicules et
communications sol/train - Partie 2: Contenu technique du travail de normalisation dans
le domaine de la communication
Ta slovenski standard je istoveten z: CLC/TR 50501-2:2012
ICS:
35.240.01 Uporabniške rešitve Application of information
informacijske tehnike in technology in general
tehnologije na splošno
45.060.01 Železniška vozila na splošno Railway rolling stock in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT
CLC/TR 50501-2
RAPPORT TECHNIQUE
August 2012
TECHNISCHER BERICHT
ICS 35.240.60; 45.020
English version
Railway applications -
Rolling stock -
Intercommunication between vehicles and train/wayside -
Part 2: Technical contents of standardization work in the field of
intercommunication
Applications ferroviaires -  Bahnanwendungen -
Matériel roulant - Interkommunikation zwischen Fahrzeugen
Communications entre véhicules et und Fahrweg -
communications sol/train - Teil 2: Technischer Inhalt der Normung
Partie 2: Contenu technique du travail de auf dem Gebiet der Interkommunikation
normalisation dans le domaine de la
communication
This Technical Report was approved by CENELEC on 2012-02-13.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus,
the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Management Centre: Avenue Marnix 17, B - 1000 Brussels

© 2012 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. CLC/TR 50501-2:2012 E

Contents
Page
Foreword . 3
1 Scope . 4
2 Normative references . 4
3 Terms and definitions . 4
4 Summary of results of works carried out by WG14 . 5
4.1 Proposal for a standard “reference architecture” for vehicle intercommunication . 5
4.2 Methods for functional modelling . 5
4.3 Requirements for a “Functional addressing” feature . 5
4.4 Requirements for a central data dictionary/repository . 6
5 Data from other related activities . 7
5.1 From Integrail FP6 research project . 7
5.2 From Modtrain FP6 research project . 9
6 Data from the sector organisations . 10
6.1 UIC Leaflet 556 [BIB 2.]: functional addressing for the UIC train bus . 10
6.2 UIC GSM-R functional addressing . 11
6.3 Codification specified in TSI operation . 17
6.4 Telematic applications TSIs . 17
6.5 Existing “Railway” identifiers and codes . 20
7 Scope for standardisation topics supporting “Functional addressing” . 26
7.1 Introduction . 26
7.2 Scope . 26
8 Proposed structure for Functional Addressing standardisation documents . 27
8.1 Introduction . 27
8.2 Part 1 – Functional addressing: Requirements . 27
8.3 Part 2 – Definition of an URI scheme for identification of vehicle functions. 27
8.4 Part 3- URI resolution guidelines . 29
8.5 Part 4 - Elementary identifiers . 30
9 Overlaps between IEC/TC9/WG43 & WG46 and CLC/SC9XB/WG14 . 30
9.1 IEC TC9 WG43 scope . 30
9.2 IEC TC9 WG46 scope . 31
9.3 IEC TC9 WG43 – list of the documents in preparation . 31
9.4 IEC TC9 WG46 – list of the documents in preparation . 31
Bibliography . 32
Tables
Table 1 - Function codes and function descriptions . 13
Table 2 - Internationally defined short codes . 14
Table 3 - Function code field format for CT=5 . 15

- 3 - CLC/TR 50501-2:2012
Foreword
This document (CLC/TR 50501-2:2012) has been prepared by CLC/SC 9XB "Electromechanical material on
board rolling stock", of CLC/TC 9X, "Electrical and electronic applications for railways".
It provides information asked for by resolutions 33/03 and 34/04 of SC9XB.

Rev. Status Date Author Modified Modification description
(sub)clause
number
V1 First draft 2008/07/16 G. Demars
V2 Second 2008/10/15 G. Demars Intro, 4.1; Updates, and corrections
draft Annex A following comments of S.
Ingenhorst
V3 Third draft 2009/11/16 G. Demars All Incorporation of information
collected from InteGRail
project, and sector
organisations
V4.1 Fourth draft 2009/12/11 G. Demars 4.4 Update after WG14 meeting #21
V4.2  G. Demars 6.2 Addition § functional open
coupling
V4.3 Working 2010/01/29 G.Demars various Remarks on remaining actions
version
V4.4 Final 2010/05/12 JL Profizi 6.4 Inserted Mr Demars paragraphs
V4 draft on telematics in 6.4
Submitted to WG14 approval
V4.5 Final 2011/08/18 JL Profizi 10 Re-shaping of the bibliography
version as Clause 10 and references
marked in yellow in the text .

1 Scope
The scope of this Technical Report is to summarize all available data on standardization work in the field of
Intercommunication including
1. the results of work of WG B14 carried out so far,
2. data from other related activities such as the research projects MODTRAIN and INTEGRAIL,
3. data from the sector organisation TMP.
NOTE “TMP”, Technical Management Platform, is one of the structures created by the rail representatives associations in order to
express common views on TSI open issues or standardization work programs (not active anymore).
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
CLC/TR 50501-1:2007, Railway applications - Rolling stock - Intercommunication between vehicles and
train/wayside - Part 1: Data dictionary and rules for functional standardisation
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
consist
train set
rake of coaches
single vehicle or a group of vehicles which are not separated during normal operation.
Note 1 to entry: A consist contains no, one or several consist networks.
assembly of vehicles (may be reduced to a single vehicle), which are permanently coupled while in service,
and fitted with a “vehicle communication system”, linking the devices, and providing one interface with the
train level (such a communication system may be a vehicle bus, spanning over all the vehicle of the consist).
Note 2 to entry: A physical consist which is not capable of data communication with other consist or ground installation is not in the
scope of the Reference Architecture. A consist is described by a set of static properties (as in UIC Leaflet 556 [BIB 2.])
3.2
entity
anything of interest (such as a person, material object, place or process) within a given domain of
discourse.
Note 1 to entry: An entity class is a stereotyped class used to model long-lived information that may be persistent. An entity is said
complex when it can be described by at least two other entities. Otherwise, it is called a simple entity or primitive
3.3
functional requirement
an action that the target system is able to perform
3.4
functional specification
specification of functions performed by the entities in a given application, in a manner that is independent of
the technology adopted to implement the specified functions

- 5 - CLC/TR 50501-2:2012
3.5
train
assembly of coupled consists (may be reduced to a single consist), configured for autonomous operation on
the railway system. and in use for an operational mission; the train is a dynamic object, identified with a “train
running number”, active only during its operational mission
4 Summary of results of works carried out by WG14
The main results of works carried out by WG14 so far, are documented in CLC/TR 50501-1, and are
summarised below:
4.1 Proposal for a standard “reference architecture” for vehicle intercommunication
Functions which are in the scope of this series of standards are supported by distributed applications.
Functional standardisation activities are supported by production of functional models.
The elaboration of a functional model for a specific function of the railway system, belonging to categories
STD2 and STD3 defined in the global scope of WG14, shall use a “reference architecture”.
The purpose of this Reference Architecture is to support the standardisation of the communication
procedures between vehicles and train/wayside.
To provide a common understanding among the standardisation working groups, this reference architecture
includes
• a list of the interacting entities which are considered in the reference architecture
o rolling stock entities: train, vehicles, devices,
o external entities interacting with rolling stock entities
o interfaces considered in the reference architecture because they are “interoperability
relevant”
4.2 Methods for functional modelling
The functional modelling framework which is described is derived from MODTRAIN European project results.
This framework is intended to provide a “common language” for the experts involved functional
standardisation of “communication” rail vehicle functions with interoperability constraints (i.e in the scope of
further standardisation works).
4.3 Requirements for a “Functional addressing” feature
Functional addressing was identified as an important issue in CLC/TR 50501-1:2007, 4.3, 4.5.4, and 5.4.2.
Annex B is dedicated to functional addressing in GSM-R and UIC leaflet 556. Is to be noted that GSM-R
consider “functional addressing” as one of the main “railway specific feature” which has been added to the
standard GSM communication system.
Requirements relative to functional addressing, already given in CLC/TR 50501-1, are
• a functional addressing scheme should be provided, which permits entities to be identified by a
“name”, used as a “functional address”, representative of their functional roles rather than by
“numbers” tied to the interface equipment they are using;
• use of functional addressing will include identifying on-train functions and other users performing
particular roles such as train driver, passenger, train conductor, etc.;

NOTE  Communications protocols not belonging to the “application levels”, which are using functional addresses, and are necessary for
the implementation of communications systems, should be specified (independently of the various functional models) in STD4, as these
communication systems are to be shared by several user functions. These protocols should be chosen among existing open industry
standards.
An important concept within the Reference Functional Architecture (defined in CLC/TR 50501-1) is dealing
with how a functional element is accessed in the railway vehicle dynamic environment. Railway vehicles are
mobile, and communicate with ground stations using wireless communication, which implies the existence of
a ground based communication infrastructure.
Reaching a functional element implies the use of communication path. It is then necessary to associate to
each relevant element:
• its identification, or name;
• its location, or address;
• and a route leading to this address.
The name shall not be bound to the address until a specific mapping process takes place. This mapping
takes all its relevance in the railway transport context, where mobility may imply address changes over time.
The information exchange infrastructure shall guarantee:
• geographic independence: an entity and its functions are reachable independently of vehicle
location;
• function binding: an entity and its functions are made available (published) in the communication
network as soon as a communication path is available;
• function discovery: a specific function of a specific entity may be discoverable upon request from a
potential user (a client);
4.4 Requirements for a central data dictionary/repository
The data dictionary is a central component necessary for development of consistent families of functional
standards such as STD2 and STD3. Its purpose, related to the scope of WG14, is
• to document elements pertinent to the functional areas and essential for interoperability,
• to allow the reuse of element among functional areas, and
• to facilitate data interchange.
Main elements types are
• model elements,
• data elements,
• messages.
Data dictionary handles metadata which provide full definition of data elements, along with their essential
attributes at conceptual level. In this context, data are limited to basic information elements, which are
necessary to define standard messages required for interoperability, and handled on the interfaces of the
communicating entities.
The central “data dictionary/model repository” shall be managed and operated by a single authority.

- 7 - CLC/TR 50501-2:2012
5 Data from other related activities
5.1 From Integrail FP6 research project
5.1.1 Introduction
Discussions took place with representatives of InteGRail subproject ICOM. Among the subjects considered
by ICOM as “candidates for standardisation”, the one which is in the scope of WG 14 is “functional
addressing”, used to provide interoperability for rail vehicle applications using communications.
5.1.2 Functional addressing relevant documents from INTEGRAIL
5.1.2.1 Introduction
In InteGRail project (IGR), the topic is addressed in several documents. Integrail documents provided to
WG14 are
• IGR-I-BTG-112-03 Train Onboard Addressing.doc [BIB 3.],
• IGR-D-BTG-111-11 Trainwide Communication.doc [BIB 4.],
• IGR-I-ALS-292-01 Concept for Symbolic Addressing in ICOM.ppt [BIB 5.],
• IGR-I-SIE-259-01 5.3.4 Symbolic Addressing in ICOM [BIB 6.],
• IGR-I-INR-033-01 Train to ground addressing scenario.ppt [BIB 7.],
• IGR-I-ALS-240-02 ICOM general approach for addressing trains.doc [BIB 8.].
5.1.2.2 Train on board addressing
Document reference: IGR-I-BTG-112-03 [BIB 3.]
Summary provided in the referenced document: This document defines an overall addressing scheme for the
on board train devices supporting the integration of TCMSs inside the IGRIS architecture.
Targets of the addressing scheme are the definition of the rules, how distributed resources of the TCMS can
be identified, and the basis for the communication protocols which shall provide access to these resources.
Clause 2 in this IGR document is dedicated to “Addressing” (52 pages):
• Subclause 2.2 is dedicated to “functional addressing” (22 pages);
• Subclause 2.3 is dedicated Network addressing;
• Subclause 2.5 is dedicated to address resolution.
Relevant requirements are found in the following paragraphs of this document:
• Subclause 2.1, Hierarchical addressing scheme;
• Subclause 2.2, Functional addressing:
o Subclause 2.2.1, Basic concept;
o Subclause 2.2.2, IPTCS Universal resource identifier;

o Subclause 2.2.3, IPT-URI Direct Identifier;
o Subclause 2.2.4, IPT-URI Range Identifier;
o Subclause 2.2.5, IP-Train Directory.
• Subclause 2.3.6, Multicast addressing;
• Subclause 2.5.2, IP-Train Directory.
5.1.2.3 Trainwide Communication Subsystem (Deliverable: D3.3)
IGR-D-BTG-111-11 [BIB 4.] (04 April 2008).
Summary provided in the document: The goal is a proposal for a system with high bandwidth supported data
types, network topology, addressing, service, security and middleware aspects based on the main
operational scenarios for communication and the evaluated state of the art for communication systems in
embedded networks, automation and railway.
5.1.2.4 ICOM Symbolic Addressing
Reference: IGR-I-ALS-292-01 [BIB 5.].
This introductive document, “ICOM Symbolic Addressing”, is describing the concepts, and defined which
related items need to be standardised
Summary: Applications use “abstract names” for addressing, instead of network addresses (IP address for
IGR). “Symbolic address” is a name to identify an entity involved in interactions between applications. The
term “functional address” is used when the addressed entity is characterised as a function. ICOM resolves
(translates) symbolic addresses.
What to standardise? - Rule sets (for given railway contexts, providing for extension), Generic guidelines and
patterns (formats, address resolution handling)
Symbolic address format:
• basic requirements: human readable, part for network, part for application level;
• URI syntax.
Symbolic @ rules set definition:
• applicable URI schemes;
• rules to avoid address ambiguity;
• often linked to underlying physical address.
Symbolic address resolution: reliance on standard technologies: Internet offers standard and open
addressing technologies (Domain Name System)
Dynamicity in train: coupling /uncoupling, configuration changes, consists vs train addresses:
• static consist addresses: need to access individual device by maintainer companies;
• dynamic train addresses: operations applications need to access “functional leader”.
An other document on the subject, named “Symbolic Addressing in ICOM”, address the issue of “rules set”.

- 9 - CLC/TR 50501-2:2012
5.1.2.5 Symbolic addressing in ICOM: ICOM symbolic addressing rule set
IGR-I-SIE-259-01 [BIB 6.] (18/02/2008).
Citation from the introduction paragraph of this document:
ICOM has to provide communication services between many applications located on the ground and inside
trains. The communication on ground mainly uses Internet technology whereas on trains an Ethernet IP
technology is applied. In order to make addressing between these applications less complicate with the
provision of dynamically changed physical addresses, a symbolic addressing concept and rule set are
introduced.
As a logical consequence, the functional addressing schema for inter-application communication on the train,
introduced in UIC 556 [3] and enhanced in the specification of the train wide communication subsystem [1],
is getting a wider scope in the context of ICOM, which has to handle the functional addressing on board and
on ground [5].
The set of symbolic addressing rules proposes ICOM URI schemas based on widely used internet
addressing and additional symbolic function names to make use of a consistent functional addressing
schema in ICOM on train wide communication [1], on train to ground [6] and on ground communication.
2 requirements in this document, about the construction of domain names.
5.2 From Modtrain FP6 research project
5.2.1 Functional modelling process
Function modelling process specified in CLC/TR 50501-1 is partially derived from the one used in
MODTRAIN/MODCONTROL.
5.2.2 FRS “Trainwide communication“
MODTRAIN/MODCONTROL, main focus is on communications internal to a vehicle (or a consist), while
WG14 focus is also on the external communications. The FRS about “Trainwide communication” [BIB 9.] is a
relevant input.
5.2.3 “Functional open coupling” concept
This concept was introduced in MODTRAIN research project, and related definitions and requirements
described the MODTRAIN/EUCOUPLER document “functional open coupling, SNCF, Release 1 - 16 Feb.
2005” [BIB 10.]
In that context “coupling” is linked to the capability, for a set of two (or more) coupled trainsets, to be
operated by a single driver located inside the train configuration which is resulting from the coupling. It is to
be noted that several drivers may be present during the preparation phase of the coupling process, before
the “functional coupling” phase.
“Functional coupling” is performed following the mechanical, pneumatic and electrical coupling phases.
In that context, “openness” means the ability to preserve the coupling capability at train level, within a fleet
where all trainsets complies with the specified “open coupling interface”, even after functional evolutions
occurring in some trainsets in the fleet, and/or after modifications are made in the trainset internal structure
(for instance, to take care of obsolescence,.).

Following text is a non-exhaustive list of “Functional Open Coupling” (FOC) requirements, more or less
related to functional addressing concept:
• a separate “coupling interface” specification shall be produced for each function which is to be
managed through the FOC interface,
• in operation, “functional coupling” shall be performed independently for each function,
• each public train function shall be identified by a name, this name being registered in a public
Central Repository, ensuring uniqueness in a given public domain (such as a set of fleets),
• each “private” function shall be identified by a name, this name being registered in a private
repository, ensuring uniqueness in the corresponding private domain,
• on the FOC interface, and for each train function, train level communications shall be managed by a
specific “referent”, identified by the name of the function. This “referent” is the then only access point
in the trainset for the function,
• on the FOC interface, each function is seen as a set of elementary services. Each service shall be
identified by a name.
From “outside” a given trainset, a service can be identified by an URI (compliant with RFC 3986 [BIB 11.])
where the following elements should be used:
• a “train number” (as defined in the TSI OPE);
• a reference to a trainset within the train formation (TBD);
• a function name (in the “Query” component, as defined in RFC 3986 [BIB 11.]);
• a service name (in the “fragment” component, as defined in RFC 3986 [BIB 11.]).
6 Data from the sector organisations
6.1 UIC Leaflet 556 [BIB 2.]: functional addressing for the UIC train bus
In the UIC 556 Leaflet, functional addressing concept is based on a user view of a train architecture,
considering the actual train composition, this means the vehicles present in the train with their special
properties”. Functional address resolution (into device addresses) may change when the train composition
change (addition or removal of vehicles).
For independence of internal vehicle structure, information shall be exchanged between functions. This
provides for “a clear interface between the train bus node and the vehicle internal structure”. All considered
functions, are given function addresses, which is made in UIC Leaflet 556 by numbering functions in a
standard way. A function is identified by 2 digits, 1 to 21 being presently allocated. Number 22 to 99 are
reserved (see [BIB 2.]).
Vehicles are identified by their “UIC address”, corresponding to the vehicle sequence established after UIC
inauguration. A functional address is then by defined by two numbers: a UIC address (or a group), and a
function address. Functional addresses for source and target are included in E-telegram messages.

- 11 - CLC/TR 50501-2:2012
Beside the UIC-address of a vehicle, there are two more addressing methods:

• collective addresses: Group of vehicles defined by the vehicle properties (UIC LL 556, 5.5.2);

• group addresses: freely selected and arranged group of vehicles independent from their property
(UIC LL 556 5.5.3). Therefore the characterisation of the group members is done by the vehicle
identification numbers (ID).
This functional addressing scheme is established after the so-called “UIC inauguration”, and may change
after each new inauguration.
This leaflet 556 specifies the following function addresses for the UIC international obligatory applications:
01Cab, 02train control, 03 Traction unit control04Traction unit auxiliary operation, 05 Drive, 06 Brakes
07 Power supply, 08 Data radio/radio modem, 09Diagnostics, 10 Doors, 11 Lighting, 12Public address,
13 Heating and air conditioning equipment, 14Passenger information, passenger service ,
15 Train bus nodes (UIC-Mapping-Server), 16 Distance/speed measurement, 17 Train protection,
18 Sanitary equipment, 19 Cab display, 20 Tilting equipment, 21Train bus nodes (general services)22-99
Reserves.
6.2 UIC GSM-R functional addressing
6.2.1 Introduction
Functional addressing is the GSM-R feature that allows calling users by their functional number, where
functional numbers identify both functions and applications. See [BIB 30.]
From a logical point of view EIRENE system [BIB 12.] can be seen as a set of applications/functions running
over a number of physical terminations. Every application/function makes use of a basic telecommunication
service (bearer service or teleservice). One physical termination can be either a mobile terminal or a support
of a mobile terminal. A Functional Number identifies the user's function rather than the number of its
terminal; for instance a certain functional number identifies the driver of a certain train and not the number of
the phone of the cab radio installed in the locomotive.
This feature guarantees the independence of the number known to the user from the physical terminal used
to answer.
It has to be noted the CCS ERTMS L2 is using the GSM-R network, but does not use the “functional
addressing” of GSM-R. However, there is in GSM-R EIRENE specification [BIB 13.], a “short Dialling code”
which is used to route a call “to most appropriate ERTMS/ETCS RBC”.(note that a short code is not formally
an “EIRENE functional number”, but it is also relevant to functional addressing concept.).
6.2.2 GSM-R EIRENE addressing plan
GSM-R addressing plan, for EIRENE functional number, identify three “rolling stock” objects:
• “train”, a dynamic object identified by the “train running number”, which is “alive” only during a
specific mission;
• “engine”, a static object, identified by the “engine number”, derived from the UIC ID;
• “coach”, a static object, identified by the “coach number”, derived from the UIC ID.
Each kind of object has its own syntax for the functional address, defined by the field CT (for a train, CT=2,
an engine, CT=3, a coach, CT=4).
“Function addresses” are also standard, and coded by 2 digits (but not always like in LL556).

EXAMPLE A dispatcher, equipped with a GSM-R terminal, needs to send a text message to be seen by
passenger of a given coach identified by its coach number. This person may not know in which train the
coach is. He/she then make a phone data call, by dialling: 4 61 (Function 61 being
“displayed passenger information unit”).
This call is received by a cab radio, the target functional number is also transmitted, to allow the cab radio to
route the message, to the coach display, (via the appropriate train bus, after translation of the UIC GSM-R
address into UIC LL556 address, with a difficulty for the coach number which has not the same coding).
GSM-R functional addressing is flexible and extensible:
• different categories of functional number are possible in particular for train level (dynamic
identification), vehicle level (permanent identification), groups, operational entities chosen depending
on the location…;
• a GSM-R functional number is mapped to a GSM-R telephone number (MSISDN) by explicit
registration and deregistration operations;
• inside the train, each device could also make a “registration” through the cab radio.

The function codes used in association with the train function number (CT=2), Engine function number
(CT=3) and coach function number (CT=4) shall conform to Table 1. (M).

- 13 - CLC/TR 50501-2:2012
Table 1 - Function codes and function descriptions
Function code Function description
00 Spare alarm
01 Leading driver
02 – 05 Other drivers
06 Fax
07 Intercom
08 Public address
09 Reserved for international use
10 Chief conductor
11 Second conductor
12 Third conductor
13 Fourth conductor
14 – 19 Reserved for international use (train crew)
20 Catering staff chief
21 – 29 Reserved for international use (catering staff)
30 Railway security services chief
31 – 39 Reserved for international use (security services)
40 ERTMS/ETCS
41-49 Reserved for international use (ERTMS/ETCS)
50 Train-borne recorder
51 Diagnostics
52 Train data bus
53 Train location system
54-59 Reserved for international applications for on train
equipment
60 Pre-recorded passenger info
61 Displayed passenger information unit
62 – 69 Reserved for international use (passenger services)
70 – 79 Reserved for international use
80 – 99 Reserved for national use
NOTE  The above Table 1 is "Table 9A-1: Function Code field for CT=2, 3 and
4" in EIRENE System Requirements Specification, Version 15, May 2006 [BIB
12].
6.2.3 Use of short dialling codes
For certain functions, standardised short codes shall be implemented for mobile originated calls. (M)
Each short dialling code shall consist of four digits. (M)
Short dialling codes shall start with the first digit equal to 1 (ie CT=1). (M)
The short dialling codes can be defined on a national basis, but it is essential that certain codes be used on
an international basis in order to achieve interoperability. These codes shall be as given in Table 2. (M)

Table 2 - Internationally defined short codes
Code Description
10(00-99) Reserved for national use
11(00-19) Reserved for national use
112X Not used
NOTE  112 reserved for public emergency.
11(30-99) Reserved for national use
a
12XX Route to most appropriate primary controller
a
13XX Route to most appropriate secondary controller
a
14XX Route to most appropriate power supply controller
a
15XX Route to most appropriate ERTMS/ETCS RBC
1612 High priority call confirmations including railway
emergency calls (see section 13)
b
16YY Reserved for international use
1700 Driver Safety Device
17(01-99) Reserved for international use
18(00-99) Reserved for national use
19(00-99) Reserved for national use
a
XX may be used to provide supplementary location information within
a cell. Where no additional information is available the default value
shall be 00.
b
YY is not 12.
NOTE  The above Table 2 is "Table 9-10: Internationally defined short
codes" in EIRENE System Requirements Specification, Version 15,

May 2006 [BIB 12].
6.2.4 Use of group addresses
Standardisation of UIC group addresses is required to provide interoperability between the fixed railway
networks within the GSM-R network. (M)
The group address consists of a Service Area (5 digits) and a Function Code (3 digits) and has a Call Type 5
(see Table 9-1). (M)
The Service area shall be defined on a national basis. (M)
In network boundary areas, the service area shall be allocated on a bilateral basis. (M)
Function codes shall be defined within the framework given in Table 3 on an international basis. (M).

- 15 - CLC/TR 50501-2:2012
Table 3 - Function code field format for CT=5
FC Function description
1xx Reserved for national use
200 “All trains group” in the context of call other drivers in the same area
(5.3.3)
2xx Reserved for national use
299 Train groups: Emergency call
3xx Reserved for national use
4xx Reserved for national use
500 Shunting groups: Default group
501 – 529 Shunting groups: Dedicated shunting groups
530 Station and security staff: Default group
53x Station and security staff: Reserved for international use
539 Station and security staff: Emergency call
54x Reserved for international use
55x Reserved for international use
560 Trackside maintenance groups: Default group
56x Trackside maintenance groups: Reserved for international use
569 Trackside maintenance groups: Emergency call
570 Controller groups: Default group
57x Controller groups: Reserved for international use
579 Controller groups: Emergency call
580 Reserved for international use
59x Reserved for international use
599 Shunting groups: Emergency call
6xx Reserved for national use
7xx Reserved for national use
8xx Reserved for national use
9xx Reserved for national use
0xx Reserved for national use
NOTE  The above Table 3 is " Table 9-8: Function Code field format for CT=5" in
EIRENE System Requirements Specification, Version 15, May 2006 [BIB 12].

6.2.5 ETSI TS 102610 [BIB 14.]
This ETSI document, published by the ETSI Technical Committee - Railway Telecommunication, defines
some data elements to be used by GSM operations on railways.
Its title is: Usage of the User to User Information Element for GSM Operation on Railways.
It is indirectly referred to by the TSIs Control Command, through the references in their Annex A to the
mandatory EIRENE specifications (GSM-R).
It described some data elements related to interoperability.

If some of them are related to the functional addressing schemes, others have used by the management of
railways operations (but not for ETCS), and then are in the scope of WG B14 (transmission of alerts, of train
position, confirmation of reception of safety related calls)
Its introduction is: The User to User Signalling Supplementary Service is widely used in the operation of
GSM for Railways (GSM-R). The applications “Presentation of Functional Numbers” [2], [3] and
“Confirmation of High Priority Calls” [4], [5] have been specified, implemented and tested in the framework of
national GSM-R schemes. In defining layouts for the new features DSD Alarm Notification and Alerting
Dispatcher care has been taken to ensure that existing implementations are not compromised or invalidated
when laying out a framework for flexible further extension. For any such further extension, therefore, it is
mandatory to define the use of UUIE in these various applications to avoid interoperability issues in the
future.
Its definition of “functional number” is: functional number: The full number used within the functional
addressing scheme to contact an end user/system by function or role rather than by a specific item of radio
equipment or user subscription.
Each information element is identified by an integer “tag”.
The following “information elements” for international use are described:
• presentation of functional number tag. This tag can is be included in any allowed call control
message where it is required to transfer the FN of the sending party to the other party in the call;
• confirmation of high priority calls tags. The procedure for the confirmation of a high priority call is
used by the mobiles involved in the call and also by the network device that is responsible for
collecting the confirmation messages;
• enhanced presentation of functional number. In some situations it has been identified that presenting
only the FN of a subscriber may not provide sufficient information for the other party/parties in the
call. A tag has therefore been defined which allows for presentation of three further pieces of
information, all of which are optional;
• presentation of text strings. If an application requires to send plain text in a UUIE then this tag shall
be used. This tag contains the plain text preceded by the alphabet indicator;
• transfer of train position. The UIC ad-hoc working group on enhanced Location Dependent
Addressing (eLDA) has defined a mechanism for transferring the location of a train (possibility to use
GPS information) to the fixed GSM-R infra-structure during call setup. This mechanism was originally
devised so that a call might be routed with greater precision than is possible with the basic cell-
based routing specified within EIRENE, but it also finds uses in providing a very precise static
indication of a train’s position, such as when indicating a DSD alarm condition;
• notification DSD alarm condition. When a driver becomes incapacitated it is important to notify the
responsible dispatcher, identified by a specific “short dialling code”, of the situation so that the
necessary steps to ensure safety can be taken;
• notification of request to alert a dispatcher. At times during a shunting group call it is required to
request that a dispatcher that had previously left the call rejoin the call to respond to a query from a
member of the call.
6.2.6 EIRENE and railway identification codes for coaches
FRS 7, list of definitions, and SRS 15, list of definitions, page 21:
Coach number: A number assigned to an item of rolling stock on a permanent basis. The coach number
may form a component of a functional number used to address users/systems on an item of rolling stock.
SRS 15, 9.5.3 (Structure of National EIRENE Number, 2) User Identifier Number (UIN)), Page 93: Coach
Number (CN): a unique number given to a coach (which is not a tractive unit) to identify it permanently. The
UIC has introduced a uniform identification marking for passenger rolling stock [UIC 438-1]. In order to call a
particular coach it shall be possible to call a number associated with the vehicle marking. The total vehicle
marking consists of 12 digits. The actual number of the coach is denoted by seven digits (positions 5 to 11 of
the complete vehicle marking), which shall be used as the CN. In order to prevent duplication of numbering,
as each railway is free to allocate the coach number leading to number uniqueness per country only, the
owning or registering railway code should be added as the first digits.

- 17 - CLC/TR 50501-2:2012
6.3 Codification specified in TSI operation
Annex on codification of railways identifiers:
There are identifiers for
• railways Actors (RU, IM, service companies, customers, ),
• locations (stations, .),
• objects (trains, vehicles.).
This topic is partly addressed by the TSI Telematics (TAF and TAP) for the definition of “references files”.
6.4 Telematic applications TSIs
6.4.1 Introduction
They are two Technical Specifications for Interoperability regarding Telematic applications:
• the Technical Specification for Interoperability regarding Telematic Applications for Freight (TAF
TSI), which has entered into force on the 18th of January 2006. [BIB 15.];
• the Technical Specification for Interoperability regarding Telematic Applications for passenger trains
(TAP TSI) which is, at time of writing, in the final drafting stage [BIB 16.].
The two related Essential requirements, according to the Interoperability Directive 2008/57/EC, are
reproduced below:
Essential Requirement 2.7.1 of Annex III to Directive 2008/57/EC:
‘The Essential requirements for telematic applications guarantee a minimum quality of Service for
Passengers and Carriers of goods, particularly in terms of technical compatibility.
Steps must be taken to ensure
• that the databases, software and data communication protocols are developed in a manner allowing
maximum data interchange between different applications and operators, excluding confidential
commercial data,
• easy access to the information, for users.’
NOTE  One objective in the SC9XB/WG14 scope of work is to produce standards supporting interoperability in communications in the
framework of Telematic applications involving rail vehicles. The proposed standardisation for “functional addressing” is important to
meet the above requirement “easy access to the information”, in particular in the dynamic environment of moving railway vehicles and
trains with variable composition.
For that purpose, GSM-R and “UIC Trainbus” have already introduced the usage of functional addresses in
their communication standard.
Essential Requirement 2.7.2 of Annex III to D
...