SIST-TP CLC/TR 50501-2:2012

Railway applications - Rolling stock - Intercommunication between vehicles and train/wayside - Part 2: Technical contents of standardization work in the field of intercommunication

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.

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

Železniške naprave - Vozna sredstva - Medsebojna komunikacija med napravami na železniških vozilih ali med njimi in progovnimi napravami - 2. del: Tehnična vsebina standardizacijskega dela na področju medsebojne komunikacije

Področje uporabe tega tehničnega poročila je povzeti vse razpoložljive podatke o standardizacijskem delu na področju medsebojne komunikacije, vključno z 1. rezultati dela, ki ga je do zdaj opravila WG B14, 2. podatki drugih s tem povezanih dejavnosti, kot sta raziskovalna projekta MODTRAIN in INTEGRAIL, 3. podatki sektorske organizacije TMP.

General Information

• Status: Published
• Publication Date: 10-Sep-2012
• ICS: 35.240.60 - IT applications in transport
• ICS: 45.060.01 - Railway rolling stock in general
• Technical Committee: ŽEN - Electrical applications for railways
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 30-Aug-2012
• Due Date: 04-Nov-2012
• Completion Date: 11-Sep-2012
• Ref Project: CLC/TR 50501-2:2012 - Railway applications - Rolling stock - Intercommunication between vehicles and train/wayside - Part 2: Technical contents of standardization work in the field of intercommunication

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TP CLC/TR 50501-2:2012
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
SIST-TP CLC/TR 50501-2:2012 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TP CLC/TR 50501-2:2012

---------------------- Page: 2 ----------------------

SIST-TP CLC/TR 50501-2:2012

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

---------------------- Page: 3 ----------------------

SIST-TP CLC/TR 50501-2:2012
CLC/TR 50501-2:2012 - 2 –

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

---------------------- Page: 4 ----------------------

SIST-TP CLC/TR 50501-2:2012
- 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 .

---------------------- Page: 5 ----------------------

SIST-TP CLC/TR 50501-2:2012
CLC/TR 50501-2:2012 - 4 –

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

---------------------- Page: 6 ----------------------

SIST-TP CLC/TR 50501-2:2012
- 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.;

---------------------- Page: 7 ----------------------

SIST-TP CLC/TR 50501-2:2012
CLC/TR 50501-2:2012 - 6 –
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.

---------------------- Page: 8 ----------------------

SIST-TP CLC/TR 50501-2:2012
- 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;

---------------------- Page: 9 ----------------------

SIST-TP CLC/TR 50501-2:2012
CLC/TR 50501-2:2012 - 8 –
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”.

---------------------- Page: 10 ----------------------

SIST-TP CLC/TR 50501-2:2012
- 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,.).

---------------------- Page: 11 ----------------------

SIST-TP CLC/TR 50501-2:2012
CLC/TR 50501-2:2012 - 10 –
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.

---------------------- Page: 12 ----------------------

SIST-TP CLC/TR 50501-2:2012
- 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
...