SIST-TS ETSI/TS 103 765-3 V1.1.1:2026

• Abstract:

  The present document specifies the interfaces of the On-Board FRMCS enabling either interaction with On-Board applications or with FRMCS entities outside the train. The present document also specifies the On-Board Multipath Function and a set of procedures the On-Board FRMCS will need to conform to.

• Status: Not Published
• Public Enquiry End Date: 30-Sep-2025
• ICS: 33.060.01 - Radiocommunications in general
• ICS: 45.020 - Railway engineering in general
• Technical Committee: MOC - Mobile Communications
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 22-Oct-2026
• Due Date: 27-Dec-2026
• Ref Project: ETSI TS 103 765-3 V1.1.0 (2025-11) - Rail Telecommunications (RT); Future Railway Mobile Communication System (FRMCS); Building Blocks and Functions; Part 3: Train On-Board functions and interfaces

SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 is an ETSI Technical Specification for Rail Telecommunications and the Future Railway Mobile Communication System (FRMCS). It specifies the train on-board FRMCS interfaces, the On-Board Multipath Function, and the procedures the on-board system follows when it interacts with on-board applications and FRMCS entities outside the train. For engineers and integrators, it is the document to use for on-board FRMCS behaviour at startup, shutdown, domain transition, application binding, session handling, notifications, and logging.

What does SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 specify?

SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 specifies the on-board FRMCS reference points and the behaviour expected from the on-board system at those interfaces. It focuses on the interfaces needed for application interaction, profile handling, multipath support, and operational procedures inside the train.

The document is organized into these main parts:

• Scope and references
• Terms, symbols and abbreviations
• On-Board FRMCS reference points
• On-Board FRMCS general requirements
• On-Board Multipath Function
• On-Board FRMCS procedures
• Endpoint procedures for registrations, sessions, notifications, versions and keepalive

The scope also makes clear that the document covers interaction with on-board applications and with FRMCS entities outside the train, and that it specifies the procedures the on-board FRMCS must conform to. The reference-point material is aligned with the external reference points defined in the UIC FRMCS SRS.

What are the key requirements of SIST-TS ETSI/TS 103 765-3 V1.1.1:2026?

Reference points and profile handling

SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 treats the OB App reference point as the main application-facing interface, but the detailed OB interface behaviour is given in UIC FRMCS FFFIS-7950 and in clause 7.3. That matters because application registration, session control, notifications and status queries are all driven through that interface model.

The FS part of the on-board system is limited to the functionality needed to obtain the FRMCS Railway On-Board Profile (FROP) and the FRMCS On-Board Application Profile (FOAP). In practice, this is where the on-board system gets startup application data, credentials, certificate state and other profile information needed for operation.

For SIM profile management, the document delegates the function to individual On-Board FRMCS Radio Modules using the GSMA Remote SIM Provisioning architecture. For TLS certificates, it requires revocation checking with OCSP or OCSP stapling, and automated certificate lifecycle management with ACME or EST. This means implementers must support both certificate status checking and automated renewal or enrollment methods.

Radio modules, location and secure storage

An On-Board FRMCS Radio Module shall comply with the UE-capability and radio-characteristics parts named in the document. The practical effect is that the on-board radio module is not a generic modem - it must fit the FRMCS radio and capability framework used by the rest of the system.

For location and positioning, the on-board system shall include a GNSS receiver, and that receiver shall process signals from at least two satellite constellations. The system shall also be able to obtain CellID information from each radio module. This gives the on-board platform multiple location sources for train positioning and network-related functions.

For profile storage, the on-board FRMCS shall have a secure enclave, such as a tamper-resistant secure hardware component or equivalent protection. The enclave shall store credentials and IMS/SIP Core credentials for supported Loose-Coupled Applications, and the long-term keys shall remain protected inside it. In practice, this separates sensitive subscription material from normal application storage.

Multipath and operational procedures

If the on-board FRMCS supports FRMCS Multipath, it shall implement the Multipath Client and follow the related procedures from Part 1. This is important for trains that need resilient or multi-path communications during operation.

The FRMCS Start of Operation procedure covers power-up to FRMCS Domain availability. It includes radio module selection, radio registration, Multipath discovery, retrieval of Startup Applications, MC Client IP assignment, optional Multipath data path selection, transport path establishment, and notification to Tight-Coupled Applications. The reader should treat this as the startup sequence that brings the train-side communication environment into service.

The FRMCS Close of Operation procedure covers planned disconnect from the FRMCS system. It includes upcoming deregistration notification, a deregistration timer, release of ongoing communications, MC Client teardown, application-context clearance, Multipath cleanup if needed, and radio-module deregistration. This is the shutdown sequence for cleanly leaving the network.

Domain transitions and application categories

The document gives detailed procedures for Inter-FRMCS Domain Transition using two On-Board FRMCS Radio Modules and for GSM-R to FRMCS transition. It uses application types I, II, III and IV to decide whether the on-board system migrates service users, re-registers them, preserves sessions, or re-establishes home-routed paths.

These procedures matter because they define how service continuity, session recovery and application notifications are handled when the train moves between domains. For example, the text distinguishes cases with open sessions, no open session, domain-of-applicability checks, and the special handling needed for Type IV applications.

Endpoint behaviour and logging

Clause 7.3 defines how the on-board system behaves on the /registrations, /sessions, /notifications, /versions and /keepalive endpoints. It covers application registration and deregistration, session creation and termination, incoming SIP INVITE handling, notification subscriptions, version reporting and keepalive responses.

The logging rule is also important in practice: the on-board FRMCS shall log endpoint invocations that lead to HTTP 400, 401, 403 or 404 responses, and it shall log all /sessions invocations. Logged records must include UTC ISO 8601 timestamp, source IP, OBAPP Application Tuple, HTTP method, endpoint, status code, and sessionId for session endpoints, while excluding credentials and passwords.

What terms does SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 define?

• OBAPP Application Context - the context stored by the On-Board FRMCS for one application instance between registration and deregistration.
• OBAPP Application Tuple - the application identity tuple made of appCategory, staticId and couplingMode.
• service continuity - the capability of the FRMCS system to maintain communication at an acceptable level during Inter-FRMCS-Domain Transition.
• Serving FRMCS Transport/Service Domain - the FRMCS domain that is currently carrying the communication of Type I applications.
• Target FRMCS Transport/Service Domain - the FRMCS domain selected as the destination for network transition.
• Serving On-Board FRMCS Radio Module - the radio module currently carrying active communication services for applications with service-continuity requirements.
• Target On-Board FRMCS Radio Module - the radio module intended to attach to the target FRMCS transport domain during domain transition.

Who uses SIST-TS ETSI/TS 103 765-3 V1.1.1:2026?

SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 is used by rail telecom engineers, train on-board system integrators, FRMCS radio-module suppliers, and developers of on-board applications. It is also relevant to railway operators, quality managers, and test labs that need to verify startup, transition, session, notification and logging behaviour.

In practice, these users consult it for interface design, profile handling, application binding, migration between domains, certificate handling, and conformance testing of on-board FRMCS behaviour.

Which standards are used with SIST-TS ETSI/TS 103 765-3 V1.1.1:2026?

Reference	What it contributes
ETSI TS 103 765-1	Transport Stratum rules, including Multipath Client and transport-path procedures
ETSI TS 103 765-2	Service Stratum procedures for MC user registration, migration, deauthorization, session setup and release
ETSI TS 103 765-5	UE capabilities and on-board radio-module requirements
ETSI TS 103 793	FRMCS radio characteristics for the on-board radio modules
UIC FFFIS-7950 (V2.1.0)	OB reference point behaviour, endpoint syntax, JSON payloads and HTTP status handling
IETF RFC 6960 and RFC 9654	OCSP revocation checking and OCSP nonce support
IETF RFC 6066 and RFC 6961	TLS revocation-status extensions and stapling support
IETF RFC 8555 and RFC 7030	Automated certificate management and enrollment
ETSI TS 133 180	MC service security and MC User ID scope information
ETSI TS 124 282	MCData signalling control and SDS procedures
ISO 8601	UTC timestamp format for logging

What does the SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 document contain?

SIST-TS ETSI/TS 103 765-3 V1.1.1:2026 contains a reference-point diagram, profile-management requirements, radio and location requirements, and a secure-storage model for on-board credentials. It also contains detailed step-by-step procedures for startup, shutdown, inter-domain transition, GSM-R to FRMCS migration, session handling, notification streams, and endpoint queries.

The document includes a table that maps MCData IPcon response cases to the ErrorCause values used in openSessionFinalAnswerNotif. It also includes procedure text for SSE notification delivery, JSON payload handling, HTTP response codes, and logging rules used for design, implementation, integration testing and conformance checks.

Draft ETSI TS 103 765-3 V1.0.0 (2025-07)

TECHNICAL SPECIFICATION
Rail Telecommunications (RT);
Future Railway Mobile Communication System (FRMCS);
Building Blocks and Functions;
Part 3: Train On-Board functions and interfaces

2 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)

Reference
DTS/RT-0085
Keywords
FRMCS, interface, protocol, railways
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 On-Board FRMCS reference points . 9
4.1 Background . 9
4.2 OB . 9
App
4.3 FS . 9
OMR
4.3.1 Introduction. 9
4.3.2 Profiles management. 9
4.4 OB . 10
ANT
4.5 OB . 10
OM
5 On-Board FRMCS general requirements . 10
5.1 On-Board FRMCS Radio Modules . 10
5.2 Location and positioning . 10
5.2.1 Generalities . 10
5.2.2 Functional requirements . 10
5.3 Profile Storage . 11
6 On-Board Multipath Function . 11
7 On-Board FRMCS procedures . 11
7.1 General procedures . 11
7.1.1 FRMCS Start of Operation . 11
7.1.2 FRMCS Close of Operation . 12
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio Modules . 13
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure . 13
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications. 14
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open session . 14
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open session . 15
7.1.3.3 Inter-FRMCS Domain transition: Type II applications . 16
7.1.3.3.1 Inter-FRMCS Domain transition: Type II applications entering the Domain of applicability . 16
7.1.3.3.2 Inter-FRMCS Domain transition: Type II applications entering a FRMCS Domain which is
not in the Domain of applicability . 16
7.1.3.4 Inter-FRMCS Domain transition: Type IV applications . 17
7.1.4 GSM-R to FRMCS transition . 17
7.1.4.1 GSM-R to FRMCS transition procedure . 17
7.1.4.2 GSM-R to FRMCS transition: Type I or Type III applications. 18
7.1.4.3 GSM-R to FRMCS transition: Type II applications entering the Domain of applicability . 18
7.1.4.4 GSM-R to FRMCS transition: Type IV applications . 18
7.2 Procedures not associated with a reference point . 18
7.2.1 MC Client IP assignment procedure . 18
7.2.2 MC Client readiness procedure . 18
7.2.3 MC Client readiness for network transition procedure . 19
7.2.4 MC Client teardown procedure . 20
7.2.5 OB Application Context clearance procedure . 20
APP
7.2.6 Ongoing communication release procedure . 21
ETSI
4 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
7.2.7 Logging . 21
7.3 Procedures associated with OB endpoints . 21
APP
7.3.0 Introduction. 21
7.3.1 /registrations endpoint procedures . 22
7.3.1.1 Application registration procedure . 22
7.3.1.2 Application-initiated deregistration procedure . 22
7.3.2 /sessions endpoint procedures . 22
7.3.2.1 On-Board-FRMCS-initiated session initiation procedure . 22
7.3.2.2 On-Board-FRMCS-initiated session termination procedure . 24
7.3.2.3 On-Board-FRMCS-terminated incoming session invite procedure . 24
7.3.2.4 On-Board-FRMCS-terminated incoming session response procedure . 25
7.3.2.5 On-Board-FRMCS-terminated session termination procedure . 26
7.3.2.6 Information query on ongoing sessions for an application. 26
7.3.2.7 Information query on a specific ongoing session for an application . 26
7.3.3 /notifications endpoint procedures . 26
7.3.3.1 Procedure for opening the notification event stream . 26
7.3.3.2 Procedure upon subscription to a channel . 27
7.3.3.3 Procedure upon unsubscription from all channels . 27
7.3.3.4 Procedure upon unsubscription from a channel . 27
7.3.3.5 Procedure of notification to an application over a channel . 27
7.3.3.6 Procedure upon subscription to location reporting channel . 28
7.3.3.7 Procedure to list subscriptions of an application . 28
7.3.3.8 Procedure to unsubscribe an application from a specific subscription . 28
7.3.4 /versions endpoint procedure . 28
7.3.5 /keepalive endpoint procedure . 28
History . 29

ETSI
5 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Railway Telecommunications (RT)
and is now submitted for the combined Public Enquiry and Vote phase of the ETSI Standardisation Request deliverable
Approval Procedure (SRdAP).
The present document is part 3 of a multi-part deliverable covering Building Blocks and Functions for the Future
Railway Mobile Communication System (FRMCS), as identified below:
Part 1: "Transport Stratum";
Part 2: "Service Stratum";
Part 3: "Train On-Board functions and interfaces";
Part 4: "Trackside functions and interfaces";
Part 5: "User Equipment (UE) capabilities".
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 in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
1 Scope
The present document specifies the interfaces of the On-Board FRMCS enabling either interaction with On-Board
applications or with FRMCS entities outside the train. The present document also specifies the On-Board Multipath
Function and a set of procedures the On-Board FRMCS will need to conform to.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 765-1: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 1: Transport Stratum".
[2] ETSI TS 103 765-2: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 2: Service Stratum".
[3] ETSI TS 103 765-5: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 5: User Equipment (UE) capabilities".
[4] ETSI TS 103 793: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Radio Characteristics".
[5] UIC FFFIS-7950 (V2.1.0): "FRMCS FFFIS Form Fit Functional Interface Specification".
[6] IETF RFC 6960: "X.509 Internet Public Key Infrastructure, Online Certificate Status
Protocol - OCSP".
[7] IETF RFC 9654: "Online Certificate Status Protocol (OCSP) Nonce Extension".
[8] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[9] IETF RFC 6961: "The Transport Layer Security (TLS) Multiple Certificate Status Request
Extension".
[10] IETF RFC 8555: "Automated Certificate Management Environment (ACME)".
[11] IETF RFC 7030: "Enrollment over Secure Transport".
[12] ETSI TS 133 180 (V18.1.0): "LTE; Security of the Mission Critical (MC) service (3GPP
TS 33.180 version 18.1.0 Release 18)".
[13] ETSI TS 124 282 (V18.10.0): "LTE; Mission Critical Data (MCData) signalling control; Protocol
specification (3GPP TS 24.282 version 18.10.0 Release 18)".
[14] ISO 8601 (2019): "Date and time — Representations for information interchange".
ETSI
7 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] UIC FRMCS SRS: "FRMCS System Requirements Specification".
[i.2] ETSI TR 103 791: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Terminology for FRMCS specifications".
[i.3] GSMA™ SGP.21 V3.1: "RSP Architecture".
[i.4] GSMA™ SGP.22 V3.1: "RSP Technical Specification".
[i.5] ETSI TS 124 229 (V18.7.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; 5G; IP multimedia call control
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);
Stage 3 (3GPP TS 24.229 version 18.7.0 Release 18)".
[i.6] ETSI TS 103 764: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); System Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TR 103 791 [i.2] and the following apply:
OBAPP Application Context: context maintained by the On-Board FRMCS for an application instance (identified by
the OBAPP Application Tuple), in between registration and de-registration
OBAPP Application Tuple: tuple of appCategory, staticId, couplingMode
NOTE: As specified in UIC FRMCS FFFIS-7950 [5], clause 9.10.1.
service continuity: capability of the FRMCS system to maintain the communication service for the user in an
acceptable level during the Inter-FRMCS-Domain Transition
Serving FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is currently carrying/serving
the communications of applications of Type I (IM interoperable applications)
NOTE: In the Inter-FRMCS-Transport-Domain transition procedure, this is the FRMCS Transport/Service
Domain before the transition takes place.
Serving On-Board FRMCS Radio Module: On-Board FRMCS Radio Module carrying in the Serving FRMCS
Transport Domain at least the active communication services for applications of Type I (IM interoperable applications)
with service continuity requirement
Target FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is the target of network
transition for applications of Type I (IM interoperable applications)
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
FRMCS Domain becomes the Serving FRMCS Domain.
ETSI
8 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
Target On-Board FRMCS Radio Module: On-Board FRMCS Radio Module which is intended to be attached to the
Target FRMCS Transport Domain following the FRMCS domain transition
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
On-Board FRMCS Radio Module becomes the Serving On-Board FRMCS Radio Module in the new
FRMCS Domain.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACME Automated Certificate Management Environment
API Application Programming Interface
CellID Cell IDentifier
EST Enrollment over Secure Transport
FA Functional Alias
FCOP FRMCS Close of OPeration
FFFIS Form Fit Functional Interface Specification
FOAP FRMCS On-Board Application Profile
FRMCS Future Railway Mobile Communication System
FROP FRMCS Railway On-Board Profile
FSOP FRMCS Start of OPeration
GNSS Global Navigation Satellite System
GSMA GSM Association
GSM-R Global System for Mobile Communications - Railway
HSM Hardware Security Module
HTTP Hyper Text Transfer Protocol
ID Identity
IdM Identity Management
IETF Internet Engineering Task Force
IFDT Inter FRMCS Domain Transition
IFSDT Inter-FRMCS Service Domain Transition
IM Infrastrcuture Manager
IMS IP Multimedia Subsystem
IP Internet Protocol
ISO International Organisation for Standardisation
JSON JavaScript Object Notation
MC Mission Critical
NTT Network Transition Trigger
OCSP Online Certificate Status Protocol
PLMN Public Land Mobile Network
RFC Request For Comments
RSP Remote SIM Provisioning
SDS Short Data Service
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SRS System Requirment Specification
SSE Server Sent Events
TLS Transport Layer Security
TPM Trusted Platform Module
UIC International Union of Railways
UTC Coordinated Universal Time
ETSI
9 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
4 On-Board FRMCS reference points
4.1 Background
This clause covers the external reference points of the On-Board FRMCS (see Figure 4.1-1) as defined in UIC FRMCS
SRS [i.1].
OB FS
OM OMR
Application(s) On-Board FRMCS
OB
ANT
OB
APP
Figure 4.1-1: On-Board FRMCS external reference points
4.2 OB
App
The on-board communication system will interact with several on-board applications. Due to this, the interface OB
APP
has to ensure the proper handling and management of the interconnected applications and grant access to the
communication services provided taking into account the priority and quality of service profile requested by those
applications.
The OB reference point is fully specified in UIC FRMCS FFFIS [5]. The behaviour expected from the On-Board
APP
FRMCS in relation with the OB is specified in clause 7.3.
APP
4.3 FS
OMR
4.3.1 Introduction
The present document only covers a subset of FS functionality defined in UIC FRMCS SRS [i.1], namely those for
OMR
the purpose of obtaining FRMCS Railway On-Board Profile (FROP) and FRMCS On-Board Application Profile
(FOAP).
4.3.2 Profiles management
The FS enables profiles management in FRMCS for the On-Board FRMCS across three essential functionalities:
OMR
• SIM profile management.
• TLS certificates management.
• Management of other profile information.
For SIM profile management, the functionalities are delegated to individual On-Board FRMCS Radio Modules using
the GSMA Remote SIM Provisioning architecture (see GSMA SGP.21 [i.3] and GSMA SGP.22 [i.4]), as specified in
ETSI TS 103 765-5 [3], clause 4.1.2.
ETSI
10 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
For TLS certificates management, the On-Board FRMCS shall support:
• For certificates revocation checking:
- The Online Certificate Status Protocol (OCSP) with extensions as specified in IETF RFC 6960 [6] and
IETF RFC 9654 [7].
- OCSP stapling as specified in IETF RFC 6066 [8] and IETF RFC 6961 [9].
• For automated certificate lifecycle management, one of the following protocols:
- Automated Certificate Management Environment (ACME), as specified in IETF RFC 8555 [10].
- Enrollment over Secure Transport (EST), as specified in IETF RFC 7030 [11].
NOTE: For automated certificate lifecycle management, the choice of protocols reflects that different railway
organizations can have different approaches on this matter.
For management of other profile information, the On-Board FRMCS need to implement a MCData client with support
for establishment of MCData IPcon connectivity and MCData Short Data Service.
The MCData client for FS within the On-Board FRMCS shall:
OMR
• Support the MCData client general procedures for SDS as specified in ETSI TS 124 282 [13], clauses 9.2.1.2
and 9.2.1.3.
• Support the MCData client terminating procedures for Standalone SDS using signalling control plane as
specified in ETSI 124 282 [13], clause 9.2.2.2.2.
4.4 OB
ANT
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
ANT
4.5 OB
OM
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
OM
5 On-Board FRMCS general requirements
5.1 On-Board FRMCS Radio Modules
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 765-5 [3], clause 4.
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 793 [4], clauses 4 and 6.
5.2 Location and positioning
5.2.1 Generalities
The On-Board FRMCS is expected to provide location information based on three possible sources: cellular network,
GNSS and external sources. Obtaining information from external sources is out of scope of the present document.
5.2.2 Functional requirements
The On-Board FRMCS shall be equipped with a GNSS receiver.
The GNSS receiver of the On-Board FRMCS shall be able to receive at least two satellite constellations.
ETSI
11 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
The On-Board FRMCS shall be able to obtain CellID information from each of its On-Board FRMCS Radio Modules.
NOTE: The present document does not specify the criteria to select one CellID among several different ones
received by the On-Board FRMCS Radio Modules.
5.3 Profile Storage
The support of Loose-Coupled Applications by an On-Board FRMCS and the distribution of functionalities between the
MC Clients within the On-Board FRMCS on the one hand and the On-Board FRMCS Radio Module(s) on the other
hand imply that the On-Board FRMCS has to store and manage sensitive information (such as credentials) that would
traditionally be stored within a SIM card.
The On-Board FRMCS shall be equipped with a secure enclave, i.e. a tamper resistant secure hardware component
(e.g. TPM, HSM) or equivalent storage protection mechanisms.
NOTE 1: The present document does not specify specific requirements on the implementation of the secure
enclave.
The On-Board FRMCS shall store at least the following elements in the secure enclave:
• Credentials associated with each MC User ID required by supported On-Board Loose-Coupled Applications.
• IMS/SIP Core credentials associated with each MC User ID required by supported On-Board Loose-Coupled
Applications.
NOTE 2: The Voice Application Service or other Tight-Coupled Applications are expected to be equipped with
their own secure profile storage capabilities.
The credentials shall be integrity protected within the On-Board FRMCS secure enclave. The long-term key(s) of the
subscription credential(s) shall be confidentiality protected within the On-Board FRMCS secure enclave. The long-term
key(s) of the subscription credential(s) shall never be available in the clear outside of the secure enclave. The
authentication algorithm(s) that make use of the subscription credentials shall always be executed within the secure
enclave.
6 On-Board Multipath Function
An On-Board FRMCS supporting FRMCS Multipath shall:
• Implement a Multipath Client as specified in ETSI TS 103 765-1 [1], clause 5.3.5.
• Comply with the procedures related to the Multipath Client as specified in ETSI TS 103 765-1 [1],
clause 5.3.7.
7 On-Board FRMCS procedures
7.1 General procedures
7.1.1 FRMCS Start of Operation
The FRMCS Start of Operation (FSOP) procedure is supporting the transition of On-Board FRMCS operational mode
from the train power-up until the moment On-Board FRMCS is in FRMCS Domain availability state. The procedure
describes the expected behaviour from On-Board FRMCS and FRMCS Domain upon power-up of the train and the
attempt from an On-Board FRMCS to acquire the FRMCS Domain.
Pre-requisite: The On-Board FRMCS knows the FRMCS Transport Domain to connect to.
ETSI
12 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
The following steps are undertaken:
1) The On-Board FRMCS shall select one or more On-Board FRMCS Radio Modules. The mechanism for
selection is not specified in the present document.
2) For each On-Board FRMCS Radio Module selected at the previous step, the On-Board FRMCS shall execute
the On-Board FRMCS Radio Module registration to the FRMCS Transport Domain procedure as specified in
ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall select one On-Board FRMCS Radio Module amongst the On-Board FRMCS
Radio Modules selected at step 2 to use for FRMCS Multipath discovery.
4) The On-Board FRMCS shall execute the FRMCS Multipath discovery procedure as specified in ETSI
TS 103 765-1 [1], clause 5.3.7.1 with the On-Board FRMCS Radio Module selected at the previous step.
5) The On-Board FRMCS shall retrieve from the FRMCS Railway On-Board Profile the list of Startup
Applications and their associated parameters. The mechanism for retrieval of the information from the
FRMCS Railway On-Board Profile is not specified in the present document.
6) For each Loose-Coupled Application identified at the previous step, the On-Board FRMCS shall execute the
MC Client IP assignment procedure as specified in clause 7.2.1 of the present document and assign it to a MC
Client. The mechanism for selection of a MC Client to assign is not specified in the present document.
7) For each Loose-Coupled Application identified at the previous step, if the FRMCS Multipath discovery
(step 5) was successful and if FRMCS Multipath is enabled according to the FRMCS Railway On-Board
Profile (step 6), the On-Board FRMCS shall execute the FRMCS Multipath data path selection procedure as
specified in ETSI TS 103 765-1 [1], clause 5.3.7.2 with the FRMCS Multipath parameters obtained at step 6.
8) The On-Board FRMCS shall execute the Transport path establishment for Mission Critical signalling
procedure as specified in ETSI TS 103 765-1 [1], clause 6.2.
9) For each Tight-Coupled Application identified at step 6 and in Locally Bound state, the On-Board FRMCS
shall notify the application of the availability of the FRMCS Transport Domain by sending a notification of
type ftdAvlNotif on the notification event stream associated with the application as specified in clause 7.3.3.5
of the present document.
10) For each Loose-Coupled Application identified at step 6, the MC Client assigned to the application at step 7
should execute the MC Client readiness procedure as specified in clause 7.2.2.
NOTE: The timely execution of the procedure at step 11 would allow a faster session establishment time. It is left
to implementation as to when the On-Board FRMCS executes the procedure.
7.1.2 FRMCS Close of Operation
The FRMCS Close of Operation (FCOP) procedure describes the expected behaviour of On-Board FRMCS and
FRMCS Domain upon attempt by an On-Board FRMCS to disconnect from the FRMCS System.
The following steps are undertaken:
1) For each application in Locally Bound state:
a) the On-Board FRMCS shall notify the application of its upcoming deregistration from the On-Board
FRMCS by sending a notification of type upcomingDeregistration on the notification event stream
associated with the application as specified in clause 7.3.3.5; and
b) the On-Board FRMCS shall start a deregistration timer, T_DEREGISTRATION_TIMER, allowing the
applications to take actions (e.g. for cleaning up their contexts).
2) At the expiry of the T_DEREGISTRATION_TIMER:
a) For a Loose-Coupled Application:
i) The On-Board FRMCS shall perform for each ongoing session the ongoing communication release
as specified in clause 7.2.6.
ETSI
13 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
ii) The On-Board FRMCS shall execute the MC Client teardown procedure as specified in
clause 7.2.4.
Application Context clearance procedure as
iii) The On-Board FRMCS shall perform the OBAPP
specified in clause 7.2.5.
b) For a Tight-Coupled Application:
i) The On-Board FRMCS shall perform the OB Application Context clearance procedure as
APP
specified in clause 7.2.5.
3) If a FRMCS Multipath control link is established, the On-Board FRMCS shall execute the Multipath Control
Protocol cleanup procedure as specified in ETSI TS 103 765-1 [1], clause 5.3.7.6.
4) For each On-Board FRMCS Radio Module, the On-Board FRMCS shall execute the On-Board Radio Module
deregistration to the FRMCS Transport Domain procedure as specified in ETSI TS 103 765-1 [1], clause 6.3.
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio
Modules
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure
Precondition:
• The On-Board FRMCS has received a Network Transition Trigger (NTT) indicating the Target FRMCS
Transport Domain (identified by a PLMN ID).
• The On-Board FRMCS has selected a Target On-Board FRMCS Radio Module.
• The Target On-Board FRMCS Radio Module is different from the Serving On-Board FRMCS Radio Module
and does not carry any other communication which requires service continuity.
The following steps are undertaken:
1) For each ongoing communication carried by the Target On-Board FRMCS Radio Module, the On-Board
FRMCS shall perform the ongoing communication release as specified in clause 7.2.6.
2) The On-Board FRMCS shall perform the registration of the Target On-Board FRMCS Radio Module in the
Target FRMCS Transport Domain as specified in ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall perform transport path establishment on the Target On-Board FRMCS Radio
Module to enable MC signaling towards the Target FRMCS Service Domain as specified in ETSI
TS 103 765-1 [1], clause 6.2.
NOTE 1: In the case of IFDT with dual On-Board FRMCS Radio Modules, during the transition, the On-Board
FRMCS can still maintain a transport path on the Serving On-Board FRMCS Radio Module towards the
Serving FRMCS Domain (e.g. for the purpose MC signalling that allows the proper release of an ongoing
communication in Serving FRMCS Service Domain during the transition - see step 4b).
NOTE 2: If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS
also needs in the following step a transport path towards the Home FRMCS Service Domain (e.g. for the
purpose of the HTTP exchanges with primary IdM server).
4) For each Loose-Coupled Application in Locally Bound state and identified as Type I or III in the FRMCS
Railway On-Board Profile:
a) If the application has no open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.1.
b) If the application has an open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.2.
ETSI
14 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
5) For each Loose-Coupled Application in Locally Bound state and identified as Type II in the FRMCS Railway
On-Board Profile:
a) If the On-Board FRMCS is entering a FRMCS Domain within the Domain of applicability of the
application, the On-Board FRMCS shall perform the procedure identified in clause 7.1.3.3.1.
b) If the On-Board FRMCS is entering a FRMCS Domain which is not in the Domain of applicability of the
application, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.3.2.
6) For each Loose-Coupled Application in Locally Bound state and identified as Type IV in the FRMCS Railway
On-Board Profile, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.4.
7) For each Tight-Coupled Application in Locally Bound state, the On-Board FRMCS shall notify the application
of the availability of the Target FRMCS Transport Domain on the notification event stream associated with the
application as specified in clause 7.3.3.5. The JSON structure being passed is of type "ftdAvlNotif" (as
specified in FRMCS FFFIS-7950 [5], clause 9.11.1.11) filled as follows:
i) The ftdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
iii) The FrmcsDomain field shall be set to the PLMN ID representing the Target FRMCS Transport Domain.
NOTE 3: The On-Board FRMCS needs to uniquely associate a Target FRMCS Service Domain to a Target
FRMCS Transport Domain (PLMN ID) for the network transition points.
NOTE 4: On-Board Tight-Coupled Application will need to uniquely associate a Target FRMCS Service Domain
to a Target FRMCS Transport Domain (PLMN ID) for the network transition points. This is however out
of scope of the present document and left to the discretion of the implementers of these applications.
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has no open session, the following steps are undertaken:
1) One of the following cases is performed depending on whether the Target FRMCS service Domain is the
Home FRMCS Service Domain or a Foreign FRMCS Service Domain:
a) If the Target FRMCS Service Domain is a Foreign FRMCS Service Domain, the On-Board FRMCS
shall perform the "MC Service User migration" procedure between Serving FRMCS Service Domain and
Target FRMCS Service Domain as specified in ETSI TS 103 765-2 [2], clause 6.4.1, using the MC
credentials and IMS credentials retrieved from the FRMCS Railway On-Board Application.
b) If the Target FRMCS Service Domain is the Home FRMCS Service Domain, the On-Board FRMCS
shall perform "MC User registration" in Home FRMCS Service Domain (see ETSI TS 103 765-2 [2],
clause 6.1).
If the step is unsuccessful, it shall be repeated every T_RETRY_MCUSR_MIG seconds for a maximum of
N_RETRY_MCUSR_MIG times before it can be considered as a failure in step 4.
2) If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS shall
perform "Migrated MC Service User deauthorization" in Serving FRMCS Service Domain (see ETSI
TS 103 765-2 [2], clause 6.4.2).
NOTE: This procedure is performed on the same MC User ID which was serving the application in the Serving
FRMCS Service Domain before the transition.
ETSI
15 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
3) If step 1 is successful, the On-Board FRMCS shall notify the application of the availability of the FRMCS
Service Domain on the notification event stream associated with the application as specified in clause 7.3.3.5.
The JSON structure being passed is of type "fsdAvlNotifData" (as specified in FRMCS FFFIS-7950 [5],
clause 9.11.1.12) filled as follows:
i) The fsdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
4) If step 1 failed, the On-Board FRMCS shall notify the application of the unavailability of the Target FRMCS
Service Domain on the notification event stream associated with the application as specified in clause 7.3.3.5.
The JSON structure being passed is of type "fsdAvlNotifData" (as specified in FRMCS FFFIS-7950 [5],
clause 9.11.1.12) filled as follows:
i) The fsdAVL field shall be set to FALSE.
ii) The nwTransition field shall be set to TRUE.
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has at least one open session, the following steps are
undertaken:
1) If the FRMCS Railway On-board Profile for the Loose-Coupled Application does not include the
"IFSDT_Dual_MCID" p
...

Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)

TECHNICAL SPECIFICATION
Rail Telecommunications (RT);
Future Railway Mobile Communication System (FRMCS);
Building Blocks and Functions;
Part 3: Train On-Board functions and interfaces

2 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)

Reference
DTS/RT-0085
Keywords
FRMCS, interface, protocol, railways
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 On-Board FRMCS reference points . 9
4.1 Background . 9
4.2 OB . 9
App
4.3 FS . 9
OMR
4.3.1 Introduction. 9
4.3.2 Profiles management. 9
4.4 OB . 10
ANT
4.5 OB . 10
OM
5 On-Board FRMCS general requirements . 10
5.1 On-Board FRMCS Radio Modules . 10
5.2 Location and positioning . 10
5.2.1 Generalities . 10
5.2.2 Functional requirements . 11
5.3 Profile Storage . 11
6 On-Board Multipath Function . 11
7 On-Board FRMCS procedures . 12
7.1 General procedures . 12
7.1.1 FRMCS Start of Operation . 12
7.1.2 FRMCS Close of Operation . 12
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio Modules . 13
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure . 13
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications. 15
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open session . 15
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open session . 15
7.1.3.3 Inter-FRMCS Domain transition: Type II applications . 16
7.1.3.3.1 Inter-FRMCS Domain transition: Type II applications entering the Domain of applicability . 16
7.1.3.3.2 Inter-FRMCS Domain transition: Type II applications entering a FRMCS Domain which is
not in the Domain of applicability . 17
7.1.3.4 Inter-FRMCS Domain transition: Type IV applications . 17
7.1.4 GSM-R to FRMCS transition . 17
7.1.4.1 GSM-R to FRMCS transition procedure . 17
7.1.4.2 GSM-R to FRMCS transition: Type I or Type III applications. 18
7.1.4.3 GSM-R to FRMCS transition: Type II applications entering the Domain of applicability . 18
7.1.4.4 GSM-R to FRMCS transition: Type IV applications . 18
7.2 Procedures not associated with a reference point . 19
7.2.1 MC Client IP assignment procedure . 19
7.2.2 MC Client readiness procedure . 19
7.2.3 MC Client readiness for network transition procedure . 19
7.2.4 MC Client teardown procedure . 20
7.2.5 OB Application Context clearance procedure . 21
APP
7.2.6 Ongoing communication release procedure . 21
ETSI
4 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
7.2.7 Logging . 21
7.3 Procedures associated with OB endpoints . 22
APP
7.3.0 Introduction. 22
7.3.1 /registrations endpoint procedures . 22
7.3.1.1 Application registration procedure . 22
7.3.1.2 Application-initiated deregistration procedure . 23
7.3.2 /sessions endpoint procedures . 23
7.3.2.1 On-Board-FRMCS-initiated session initiation procedure . 23
7.3.2.2 On-Board-FRMCS-initiated session termination procedure . 24
7.3.2.3 On-Board-FRMCS-terminated incoming session invite procedure . 25
7.3.2.4 On-Board-FRMCS-terminated incoming session response procedure . 26
7.3.2.5 On-Board-FRMCS-terminated session termination procedure . 26
7.3.2.6 Information query on ongoing sessions for an application. 26
7.3.2.7 Information query on a specific ongoing session for an application . 26
7.3.3 /notifications endpoint procedures . 27
7.3.3.1 Procedure for opening the notification event stream . 27
7.3.3.2 Procedure upon subscription to a channel . 27
7.3.3.3 Procedure upon unsubscription from all channels . 28
7.3.3.4 Procedure upon unsubscription from a channel . 28
7.3.3.5 Procedure of notification to an application over a channel . 28
7.3.3.6 Procedure upon subscription to location reporting channel . 28
7.3.3.7 Procedure to list subscriptions of an application . 29
7.3.3.8 Procedure to unsubscribe an application from a specific subscription . 29
7.3.4 /versions endpoint procedure . 29
7.3.5 /keepalive endpoint procedure . 29
History . 30

ETSI
5 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This final draft Technical Specification (TS) has been produced by ETSI Technical Committee Railway
Telecommunications (RT), and is now submitted for the Vote phase of the ETSI Standardisation Request deliverable
Approval Procedure (SRdAP).
The present document is part 3 of a multi-part deliverable covering Building Blocks and Functions for the Future
Railway Mobile Communication System (FRMCS), as identified below:
Part 1: "Transport Stratum";
Part 2: "Service Stratum";
Part 3: "Train On-Board functions and interfaces";
Part 4: "Trackside functions and interfaces";
Part 5: "User Equipment (UE) capabilities".
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 in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
1 Scope
The present document specifies the interfaces of the On-Board FRMCS enabling either interaction with On-Board
applications or with FRMCS entities outside the train. The present document also specifies the On-Board Multipath
Function and a set of procedures the On-Board FRMCS will need to conform to.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 765-1: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 1: Transport Stratum".
[2] ETSI TS 103 765-2: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 2: Service Stratum".
[3] ETSI TS 103 765-5: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 5: User Equipment (UE) capabilities".
[4] ETSI TS 103 793: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Radio Characteristics".
[5] UIC FFFIS-7950 (V2.1.0): "FRMCS FFFIS Form Fit Functional Interface Specification".
[6] IETF RFC 6960: "X.509 Internet Public Key Infrastructure, Online Certificate Status
Protocol - OCSP".
[7] IETF RFC 9654: "Online Certificate Status Protocol (OCSP) Nonce Extension".
[8] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[9] IETF RFC 6961: "The Transport Layer Security (TLS) Multiple Certificate Status Request
Extension".
[10] IETF RFC 8555: "Automated Certificate Management Environment (ACME)".
[11] IETF RFC 7030: "Enrollment over Secure Transport".
[12] ETSI TS 133 180 (V18.1.0): "LTE; Security of the Mission Critical (MC) service (3GPP
TS 33.180 version 18.1.0 Release 18)".
[13] ETSI TS 124 282 (V18.10.0): "LTE; Mission Critical Data (MCData) signalling control; Protocol
specification (3GPP TS 24.282 version 18.10.0 Release 18)".
[14] ISO 8601 (2019): "Date and time — Representations for information interchange".
ETSI
7 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] UIC FRMCS SRS: "FRMCS System Requirements Specification".
[i.2] ETSI TR 103 791: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Terminology for FRMCS specifications".
[i.3] GSMA™ SGP.21 V3.1: "RSP Architecture".
[i.4] GSMA™ SGP.22 V3.1: "RSP Technical Specification".
[i.5] ETSI TS 124 229 (V18.7.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; 5G; IP multimedia call control
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);
Stage 3 (3GPP TS 24.229 version 18.7.0 Release 18)".
[i.6] ETSI TS 103 764: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); System Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TR 103 791 [i.2] and the following apply:
OBAPP Application Context: context maintained by the On-Board FRMCS for an application instance (identified by
the OBAPP Application Tuple), in between registration and de-registration
OBAPP Application Tuple: tuple of appCategory, staticId, couplingMode
NOTE: As specified in UIC FRMCS FFFIS-7950 [5], clause 9.10.1.
service continuity: capability of the FRMCS system to maintain the communication service for the user in an
acceptable level during the Inter-FRMCS-Domain Transition
Serving FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is currently carrying/serving
the communications of applications of Type I (IM interoperable applications)
NOTE: In the Inter-FRMCS-Transport-Domain transition procedure, this is the FRMCS Transport/Service
Domain before the transition takes place.
Serving On-Board FRMCS Radio Module: On-Board FRMCS Radio Module carrying in the Serving FRMCS
Transport Domain at least the active communication services for applications of Type I (IM interoperable applications)
with service continuity requirement
Target FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is the target of network
transition for applications of Type I (IM interoperable applications)
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
FRMCS Domain becomes the Serving FRMCS Domain.
ETSI
8 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
Target On-Board FRMCS Radio Module: On-Board FRMCS Radio Module which is intended to be attached to the
Target FRMCS Transport Domain following the FRMCS domain transition
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
On-Board FRMCS Radio Module becomes the Serving On-Board FRMCS Radio Module in the new
FRMCS Domain.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACME Automated Certificate Management Environment
API Application Programming Interface
CellID Cell IDentifier
EST Enrollment over Secure Transport
FA Functional Alias
FCOP FRMCS Close of OPeration
FFFIS Form Fit Functional Interface Specification
FOAP FRMCS On-Board Application Profile
FRMCS Future Railway Mobile Communication System
FROP FRMCS Railway On-Board Profile
FSOP FRMCS Start of OPeration
GNSS Global Navigation Satellite System
GSMA GSM Association
GSM-R Global System for Mobile Communications - Railway
HSM Hardware Security Module
HTTP Hyper Text Transfer Protocol
ID Identity
IdM Identity Management
IETF Internet Engineering Task Force
IFDT Inter FRMCS Domain Transition
IFSDT Inter-FRMCS Service Domain Transition
IM Infrastrcuture Manager
IMS IP Multimedia Subsystem
IP Internet Protocol
ISO International Organisation for Standardisation
JSON JavaScript Object Notation
MC Mission Critical
NTT Network Transition Trigger
OCSP Online Certificate Status Protocol
PLMN Public Land Mobile Network
RFC Request For Comments
RSP Remote SIM Provisioning
SDS Short Data Service
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SRS System Requirement Specification
SSE Server Sent Events
TLS Transport Layer Security
TPM Trusted Platform Module
UIC International Union of Railways
UTC Coordinated Universal Time
ETSI
9 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
4 On-Board FRMCS reference points
4.1 Background
This clause covers the external reference points of the On-Board FRMCS (see Figure 4.1-1) as defined in UIC FRMCS
SRS [i.1].
OB FS
OM OMR
Application(s) On-Board FRMCS
OB
ANT
OB
APP
Figure 4.1-1: On-Board FRMCS external reference points
4.2 OB
App
The on-board communication system will interact with several on-board applications. Due to this, the interface OB
APP
has to ensure the proper handling and management of the interconnected applications and grant access to the
communication services provided taking into account the priority and quality of service profile requested by those
applications.
The OB reference point is fully specified in UIC FRMCS FFFIS [5]. The behaviour expected from the On-Board
APP
FRMCS in relation with the OB is specified in clause 7.3.
APP
4.3 FS
OMR
4.3.1 Introduction
The present document only covers a subset of FS functionality defined in UIC FRMCS SRS [i.1], namely those for
OMR
the purpose of obtaining FRMCS Railway On-Board Profile (FROP) and FRMCS On-Board Application Profile
(FOAP).
4.3.2 Profiles management
The FS enables profiles management in FRMCS for the On-Board FRMCS across three essential functionalities:
OMR
• SIM profile management.
• TLS certificates management.
• Management of other profile information.
For SIM profile management, the functionalities are delegated to individual On-Board FRMCS Radio Modules using
the GSMA Remote SIM Provisioning architecture (see GSMA SGP.21 [i.3] and GSMA SGP.22 [i.4]), as specified in
ETSI TS 103 765-5 [3], clause 4.1.2.
ETSI
10 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
For TLS certificates management, the On-Board FRMCS shall support:
• For certificates revocation checking:
- The Online Certificate Status Protocol (OCSP) with extensions as specified in IETF RFC 6960 [6] and
IETF RFC 9654 [7].
- OCSP stapling as specified in IETF RFC 6066 [8] and IETF RFC 6961 [9].
• For automated certificate lifecycle management, one of the following protocols:
- Automated Certificate Management Environment (ACME), as specified in IETF RFC 8555 [10].
- Enrollment over Secure Transport (EST), as specified in IETF RFC 7030 [11].
NOTE: For automated certificate lifecycle management, the choice of protocols reflects that different railway
organizations can have different approaches on this matter.
For management of other profile information, the On-Board FRMCS need to implement a MCData client with support
for establishment of MCData IPcon connectivity and MCData Short Data Service.
The MCData client for FS within the On-Board FRMCS shall:
OMR
• Support the MCData client general procedures for SDS as specified in ETSI TS 124 282 [13], clauses 9.2.1.2
and 9.2.1.3.
• Support the MCData client terminating procedures for Standalone SDS using signalling control plane as
specified in ETSI 124 282 [13], clause 9.2.2.2.2.
4.4 OB
ANT
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
ANT
4.5 OB
OM
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
OM
5 On-Board FRMCS general requirements
5.1 On-Board FRMCS Radio Modules
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 765-5 [3], clause 4.
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 793 [4], clauses 4 and 6.
5.2 Location and positioning
5.2.1 Generalities
The On-Board FRMCS is expected to provide location information based on three possible sources: cellular network,
GNSS and external sources. Obtaining information from external sources is out of scope of the present document.
ETSI
11 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
5.2.2 Functional requirements
The On-Board FRMCS shall be equipped with a GNSS receiver.
The GNSS receiver of the On-Board FRMCS shall be capable of receiving and processing signals from at least two
satellite constellations.
The On-Board FRMCS shall be able to obtain CellID information from each of its On-Board FRMCS Radio Modules.
NOTE: The present document does not specify the criteria to select one CellID among several different ones
received by the On-Board FRMCS Radio Modules.
5.3 Profile Storage
The support of Loose-Coupled Applications by an On-Board FRMCS and the distribution of functionalities between the
MC Clients within the On-Board FRMCS on the one hand and the On-Board FRMCS Radio Module(s) on the other
hand imply that the On-Board FRMCS has to store and manage sensitive information (such as credentials) that would
traditionally be stored within a SIM card.
The On-Board FRMCS shall be equipped with a secure enclave, i.e. a tamper resistant secure hardware component
(e.g. TPM, HSM) or equivalent storage protection mechanisms.
NOTE 1: The present document does not specify specific requirements on the implementation of the secure
enclave.
The On-Board FRMCS shall store at least the following elements in the secure enclave:
• Credentials associated with each MC User ID required by supported On-Board Loose-Coupled Applications.
• IMS/SIP Core credentials associated with each MC User ID required by supported On-Board Loose-Coupled
Applications.
NOTE 2: The Voice Application Service or other Tight-Coupled Applications are expected to be equipped with
their own secure profile storage capabilities.
The credentials shall be integrity protected within the On-Board FRMCS secure enclave. The long-term key(s) of the
subscription credential(s) shall be confidentiality protected within the On-Board FRMCS secure enclave. The long-term
key(s) of the subscription credential(s) shall never be available in the clear outside of the secure enclave. The
authentication algorithm(s) that make use of the subscription credentials shall always be executed within the secure
enclave.
6 On-Board Multipath Function
An On-Board FRMCS supporting FRMCS Multipath shall:
• Implement a Multipath Client as specified in ETSI TS 103 765-1 [1], clause 5.3.5.
• Comply with the procedures related to the Multipath Client as specified in ETSI TS 103 765-1 [1],
clause 5.3.7.
ETSI
12 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
7 On-Board FRMCS procedures
7.1 General procedures
7.1.1 FRMCS Start of Operation
The FRMCS Start of Operation (FSOP) procedure is supporting the transition of On-Board FRMCS operational mode
from the train power-up until the moment On-Board FRMCS is in FRMCS Domain availability state. The procedure
describes the expected behaviour from On-Board FRMCS and FRMCS Domain upon power-up of the train and the
attempt from an On-Board FRMCS to acquire the FRMCS Domain.
Pre-requisite: The On-Board FRMCS knows the FRMCS Transport Domain to connect to.
The following steps are undertaken:
1) The On-Board FRMCS shall select one or more On-Board FRMCS Radio Modules. The mechanism for
selection is not specified in the present document.
2) For each On-Board FRMCS Radio Module selected at the previous step, the On-Board FRMCS shall execute
the On-Board FRMCS Radio Module registration to the FRMCS Transport Domain procedure as specified in
ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall select one On-Board FRMCS Radio Module amongst the On-Board FRMCS
Radio Modules selected at step 2 to use for FRMCS Multipath discovery.
4) The On-Board FRMCS shall execute the FRMCS Multipath discovery procedure as specified in ETSI
TS 103 765-1 [1], clause 5.3.7.1 with the On-Board FRMCS Radio Module selected at the previous step.
5) The On-Board FRMCS shall retrieve from the FRMCS Railway On-Board Profile the list of Startup
Applications and their associated parameters. The mechanism for retrieval of the information from the
FRMCS Railway On-Board Profile is not specified in the present document.
6) For each Loose-Coupled Application identified at the previous step, the On-Board FRMCS shall execute the
MC Client IP assignment procedure as specified in clause 7.2.1 of the present document and assign it to a MC
Client. The mechanism for selection of a MC Client to assign is not specified in the present document.
7) For each Loose-Coupled Application identified at the previous step, if the FRMCS Multipath discovery
(step 4) was successful and if FRMCS Multipath is enabled according to the FRMCS Railway On-Board
Profile (step 5), the On-Board FRMCS shall execute the FRMCS Multipath data path selection procedure as
specified in ETSI TS 103 765-1 [1], clause 5.3.7.2 with the FRMCS Multipath parameters obtained at step 5.
8) The On-Board FRMCS shall execute the Transport path establishment for Mission Critical signalling
procedure as specified in ETSI TS 103 765-1 [1], clause 6.2.
9) For each Tight-Coupled Application identified at step 5 and in Locally Bound state, the On-Board FRMCS
shall notify the application of the availability of the FRMCS Transport Domain by sending a notification of
type ftdAvlNotif on the notification event stream associated with the application as specified in clause 7.3.3.5
of the present document.
10) For each Loose-Coupled Application identified at step 5, the MC Client assigned to the application at step 6
should execute the MC Client readiness procedure as specified in clause 7.2.2.
NOTE: The timely execution of the procedure at step 11 would allow a faster session establishment time. It is left
to implementation as to when the On-Board FRMCS executes the procedure.
7.1.2 FRMCS Close of Operation
The FRMCS Close of Operation (FCOP) procedure describes the expected behaviour of On-Board FRMCS and
FRMCS Domain upon attempt by an On-Board FRMCS to disconnect from the FRMCS System.
ETSI
13 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
The following steps are undertaken:
1) For each application in Locally Bound state:
a) the On-Board FRMCS shall notify the application of its upcoming deregistration from the On-Board
FRMCS by sending a notification of type upcomingDeregistration on the notification event stream
associated with the application as specified in clause 7.3.3.5; and
b) the On-Board FRMCS shall start a deregistration timer, T_DEREGISTRATION_TIMER, allowing the
applications to take actions (e.g. for cleaning up their contexts).
2) At the expiry of the T_DEREGISTRATION_TIMER:
a) For a Loose-Coupled Application:
i) The On-Board FRMCS shall perform for each ongoing session the ongoing communication release
as specified in clause 7.2.6.
ii) The On-Board FRMCS shall execute the MC Client teardown procedure as specified in
clause 7.2.4.
iii) The On-Board FRMCS shall perform the OB Application Context clearance procedure as
APP
specified in clause 7.2.5.
b) For a Tight-Coupled Application:
i) The On-Board FRMCS shall perform the OB Application Context clearance procedure as
APP
specified in clause 7.2.5.
3) If a FRMCS Multipath control link is established, the On-Board FRMCS shall execute the Multipath Control
Protocol cleanup procedure as specified in ETSI TS 103 765-1 [1], clause 5.3.7.6.
4) For each On-Board FRMCS Radio Module, the On-Board FRMCS shall execute the On-Board Radio Module
deregistration to the FRMCS Transport Domain procedure as specified in ETSI TS 103 765-1 [1], clause 6.3.
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio
Modules
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure
Precondition:
• The On-Board FRMCS has received a Network Transition Trigger (NTT) indicating the Target FRMCS
Transport Domain (identified by a PLMN ID).
• The On-Board FRMCS has selected a Target On-Board FRMCS Radio Module.
• The Target On-Board FRMCS Radio Module is different from the Serving On-Board FRMCS Radio Module
and does not carry any other communication which requires service continuity.
The following steps are undertaken:
1) For each ongoing communication carried by the Target On-Board FRMCS Radio Module, the On-Board
FRMCS shall perform the ongoing communication release as specified in clause 7.2.6.
2) The On-Board FRMCS shall perform the registration of the Target On-Board FRMCS Radio Module in the
Target FRMCS Transport Domain as specified in ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall perform transport path establishment on the Target On-Board FRMCS Radio
Module to enable MC signaling towards the Target FRMCS Service Domain as specified in ETSI
TS 103 765-1 [1], clause 6.2.
ETSI
14 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
NOTE 1: In the case of IFDT with dual On-Board FRMCS Radio Modules, during the transition, the On-Board
FRMCS can still maintain a transport path on the Serving On-Board FRMCS Radio Module towards the
Serving FRMCS Domain (e.g. for the purpose MC signalling that allows the proper release of an ongoing
communication in Serving FRMCS Service Domain during the transition - see step 4b).
NOTE 2: If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS
also needs in the following step a transport path towards the Home FRMCS Service Domain (e.g. for the
purpose of the HTTP exchanges with primary IdM server).
4) For each Loose-Coupled Application in Locally Bound state and identified as Type I or III in the FRMCS
Railway On-Board Profile:
a) If the application has no open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.1.
b) If the application has an open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.2.
5) For each Loose-Coupled Application in Locally Bound state and identified as Type II in the FRMCS Railway
On-Board Profile:
a) If the On-Board FRMCS is entering a FRMCS Domain within the Domain of applicability of the
application, the On-Board FRMCS shall perform the procedure identified in clause 7.1.3.3.1.
b) If the On-Board FRMCS is entering a FRMCS Domain which is not in the Domain of applicability of the
application, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.3.2.
6) For each Loose-Coupled Application in Locally Bound state and identified as Type IV in the FRMCS Railway
On-Board Profile, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.4.
7) For each Tight-Coupled Application in Locally Bound state, the On-Board FRMCS shall notify the application
of the availability of the Target FRMCS Transport Domain on the notification event stream associated with the
application as specified in clause 7.3.3.5. The JSON structure being passed is of type "ftdAvlNotif" (as
specified in FRMCS FFFIS-7950 [5], clause 9.11.1.11) filled as follows:
i) The ftdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
iii) The FrmcsDomain field shall be set to the PLMN ID representing the Target FRMCS Transport Domain.
NOTE 3: The On-Board FRMCS needs to uniquely associate a Target FRMCS Service Domain to a Target
FRMCS Transport Domain (PLMN ID) for the network transition points.
NOTE 4: On-Board Tight-Coupled Application will need to uniquely associate a Target FRMCS Service Domain
to a Target FRMCS Transport Domain (PLMN ID) for the network transition points. This is however out
of scope of the present document and left to the discretion of the implementers of these applications.
ETSI
15 Final draft ETSI TS 103 765-3 V1.1.0 (2025-11)
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has no open session, the following steps are undertaken:
1) One of the following cases is performed depending on whether the Target FRMCS service Domain is the
Home FRMCS Service Domain or a Foreign FRMCS Service Domain:
a) If the Target FRMCS Service Domain is a Foreign FRMCS Service Domain, the On-Board FRMCS
shall perform the "MC Service User migration" procedure between Serving FRMCS Service Domain and
Target FRMCS Service Domain as specified in ETSI TS 103 765-2 [2], clause 6.4.1, using the MC
credentials and IMS credentials retrieved from the FRMCS Railway On-Board Application.
b) If the Target FRMCS Service Domain is the Home FRMCS Service Domain, the On-Board FRMCS
shall perform "MC User registration" in Home FRMCS Service Domain (see ETSI TS 103 765-2 [2],
clause 6.1).
If the step is unsuccessful, it shall be repeated every T_RETRY_MCUSR_MIG seconds for a maximum of
N_RETRY_MCUSR_MIG times before it can be considered as a failure in step 4.
2) If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS shall
perform "Migrated MC Service User deauthorization" in Serving FRMCS Service Domain (see ETSI
TS 103 765-2 [2], clause 6.4.2).
NOTE: This procedure is performed on the same MC User ID which was serving the application in the Serving
FRMCS Service Domain before the transition.
3) If step 1 is successful, the On-Board FRMCS shall notify the application of the availability of the FRMCS
Service Domain on the notification event stream associated with the application as specified in clause 7.3.3.5.
The JSON structure being passed is of type "fsdAvlNotifData" (as specified in FRMCS FFFIS-7950 [5],
clause 9.11.1.12) filled as follows:
i) The fsdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
4) If step 1 failed, the On-Board FRMCS shall notify the application of the unavailability of the Target FRMCS
Service Domain on the notification event stream associated with the application as specified in clause 7.3.3.5.
The JSON structure being passed is of type "fsdAvlNotifData" (as specified in FRMCS FFFIS-7950 [5],
clause 9.11.1.12) filled as follows:
i) The fsdAVL field shall be set to FALSE.
ii) The nwTransition field shall be set to TRUE.
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has at least one open session, the following steps are
under
...

ETSI TS 103 765-3 V1.1.1 (2026-01)

TECHNICAL SPECIFICATION
Rail Telecommunications (RT);
Future Railway Mobile Communication System (FRMCS);
Building Blocks and Functions;
Part 3: Train On-Board functions and interfaces

2 ETSI TS 103 765-3 V1.1.1 (2026-01)

Reference
DTS/RT-0085
Keywords
FRMCS, interface, protocol, railways
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2026.
All rights reserved.
ETSI
3 ETSI TS 103 765-3 V1.1.1 (2026-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 On-Board FRMCS reference points . 9
4.1 Background . 9
4.2 OB . 9
App
4.3 FS . 9
OMR
4.3.1 Introduction. 9
4.3.2 Profiles management. 9
4.4 OB . 10
ANT
4.5 OB . 10
OM
5 On-Board FRMCS general requirements . 10
5.1 On-Board FRMCS Radio Modules . 10
5.2 Location and positioning . 10
5.2.1 Generalities . 10
5.2.2 Functional requirements . 11
5.3 Profile Storage . 11
6 On-Board Multipath Function . 11
7 On-Board FRMCS procedures . 12
7.1 General procedures . 12
7.1.1 FRMCS Start of Operation . 12
7.1.2 FRMCS Close of Operation . 12
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio Modules . 13
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure . 13
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications. 15
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open session . 15
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open session . 15
7.1.3.3 Inter-FRMCS Domain transition: Type II applications . 16
7.1.3.3.1 Inter-FRMCS Domain transition: Type II applications entering the Domain of applicability . 16
7.1.3.3.2 Inter-FRMCS Domain transition: Type II applications entering a FRMCS Domain which is
not in the Domain of applicability . 17
7.1.3.4 Inter-FRMCS Domain transition: Type IV applications . 17
7.1.4 GSM-R to FRMCS transition . 17
7.1.4.1 GSM-R to FRMCS transition procedure . 17
7.1.4.2 GSM-R to FRMCS transition: Type I or Type III applications. 18
7.1.4.3 GSM-R to FRMCS transition: Type II applications entering the Domain of applicability . 18
7.1.4.4 GSM-R to FRMCS transition: Type IV applications . 18
7.2 Procedures not associated with a reference point . 19
7.2.1 MC Client IP assignment procedure . 19
7.2.2 MC Client readiness procedure . 19
7.2.3 MC Client readiness for network transition procedure . 19
7.2.4 MC Client teardown procedure . 20
7.2.5 OB Application Context clearance procedure . 21
APP
7.2.6 Ongoing communication release procedure . 21
ETSI
4 ETSI TS 103 765-3 V1.1.1 (2026-01)
7.2.7 Logging . 21
7.3 Procedures associated with OB endpoints . 22
APP
7.3.0 Introduction. 22
7.3.1 /registrations endpoint procedures . 22
7.3.1.1 Application registration procedure . 22
7.3.1.2 Application-initiated deregistration procedure . 23
7.3.2 /sessions endpoint procedures . 23
7.3.2.1 On-Board-FRMCS-initiated session initiation procedure . 23
7.3.2.2 On-Board-FRMCS-initiated session termination procedure . 24
7.3.2.3 On-Board-FRMCS-terminated incoming session invite procedure . 25
7.3.2.4 On-Board-FRMCS-terminated incoming session response procedure . 26
7.3.2.5 On-Board-FRMCS-terminated session termination procedure . 26
7.3.2.6 Information query on ongoing sessions for an application. 26
7.3.2.7 Information query on a specific ongoing session for an application . 26
7.3.3 /notifications endpoint procedures . 27
7.3.3.1 Procedure for opening the notification event stream . 27
7.3.3.2 Procedure upon subscription to a channel . 27
7.3.3.3 Procedure upon unsubscription from all channels . 28
7.3.3.4 Procedure upon unsubscription from a channel . 28
7.3.3.5 Procedure of notification to an application over a channel . 28
7.3.3.6 Procedure upon subscription to location reporting channel . 28
7.3.3.7 Procedure to list subscriptions of an application . 29
7.3.3.8 Procedure to unsubscribe an application from a specific subscription . 29
7.3.4 /versions endpoint procedure . 29
7.3.5 /keepalive endpoint procedure . 29
History . 30

ETSI
5 ETSI TS 103 765-3 V1.1.1 (2026-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Railway Telecommunications
(RT).
The present document is part 3 of a multi-part deliverable covering Building Blocks and Functions for the Future
Railway Mobile Communication System (FRMCS), as identified below:
Part 1: "Transport Stratum";
Part 2: "Service Stratum";
Part 3: "Train On-Board functions and interfaces";
Part 4: "Trackside functions and interfaces";
Part 5: "User Equipment (UE) capabilities".
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 in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TS 103 765-3 V1.1.1 (2026-01)
1 Scope
The present document specifies the interfaces of the On-Board FRMCS enabling either interaction with On-Board
applications or with FRMCS entities outside the train. The present document also specifies the On-Board Multipath
Function and a set of procedures the On-Board FRMCS will need to conform to.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 765-1: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 1: Transport Stratum".
[2] ETSI TS 103 765-2: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 2: Service Stratum".
[3] ETSI TS 103 765-5: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 5: User Equipment (UE) capabilities".
[4] ETSI TS 103 793: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Radio Characteristics".
[5] UIC FFFIS-7950 (V2.1.0): "FRMCS FFFIS Form Fit Functional Interface Specification".
[6] IETF RFC 6960: "X.509 Internet Public Key Infrastructure, Online Certificate Status
Protocol - OCSP".
[7] IETF RFC 9654: "Online Certificate Status Protocol (OCSP) Nonce Extension".
[8] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[9] IETF RFC 6961: "The Transport Layer Security (TLS) Multiple Certificate Status Request
Extension".
[10] IETF RFC 8555: "Automated Certificate Management Environment (ACME)".
[11] IETF RFC 7030: "Enrollment over Secure Transport".
[12] ETSI TS 133 180 (V18.1.0): "LTE; Security of the Mission Critical (MC) service (3GPP
TS 33.180 version 18.1.0 Release 18)".
[13] ETSI TS 124 282 (V18.10.0): "LTE; Mission Critical Data (MCData) signalling control; Protocol
specification (3GPP TS 24.282 version 18.10.0 Release 18)".
[14] ISO 8601 (2019): "Date and time — Representations for information interchange".
ETSI
7 ETSI TS 103 765-3 V1.1.1 (2026-01)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] UIC FRMCS SRS: "FRMCS System Requirements Specification".
[i.2] ETSI TR 103 791: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Terminology for FRMCS specifications".
[i.3] GSMA™ SGP.21 V3.1: "RSP Architecture".
[i.4] GSMA™ SGP.22 V3.1: "RSP Technical Specification".
[i.5] ETSI TS 124 229 (V18.7.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; 5G; IP multimedia call control
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);
Stage 3 (3GPP TS 24.229 version 18.7.0 Release 18)".
[i.6] ETSI TS 103 764: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); System Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TR 103 791 [i.2] and the following apply:
OBAPP Application Context: context maintained by the On-Board FRMCS for an application instance (identified by
the OBAPP Application Tuple), in between registration and de-registration
OBAPP Application Tuple: tuple of appCategory, staticId, couplingMode
NOTE: As specified in UIC FRMCS FFFIS-7950 [5], clause 9.10.1.
service continuity: capability of the FRMCS system to maintain the communication service for the user in an
acceptable level during the Inter-FRMCS-Domain Transition
Serving FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is currently carrying/serving
the communications of applications of Type I (IM interoperable applications)
NOTE: In the Inter-FRMCS-Transport-Domain transition procedure, this is the FRMCS Transport/Service
Domain before the transition takes place.
Serving On-Board FRMCS Radio Module: On-Board FRMCS Radio Module carrying in the Serving FRMCS
Transport Domain at least the active communication services for applications of Type I (IM interoperable applications)
with service continuity requirement
Target FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is the target of network
transition for applications of Type I (IM interoperable applications)
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
FRMCS Domain becomes the Serving FRMCS Domain.
ETSI
8 ETSI TS 103 765-3 V1.1.1 (2026-01)
Target On-Board FRMCS Radio Module: On-Board FRMCS Radio Module which is intended to be attached to the
Target FRMCS Transport Domain following the FRMCS domain transition
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
On-Board FRMCS Radio Module becomes the Serving On-Board FRMCS Radio Module in the new
FRMCS Domain.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACME Automated Certificate Management Environment
API Application Programming Interface
CellID Cell IDentifier
EST Enrollment over Secure Transport
FA Functional Alias
FCOP FRMCS Close of OPeration
FFFIS Form Fit Functional Interface Specification
FOAP FRMCS On-Board Application Profile
FRMCS Future Railway Mobile Communication System
FROP FRMCS Railway On-Board Profile
FSOP FRMCS Start of OPeration
GNSS Global Navigation Satellite System
GSMA GSM Association
GSM-R Global System for Mobile Communications - Railway
HSM Hardware Security Module
HTTP Hyper Text Transfer Protocol
ID Identity
IdM Identity Management
IETF Internet Engineering Task Force
IFDT Inter FRMCS Domain Transition
IFSDT Inter-FRMCS Service Domain Transition
IM Infrastrcuture Manager
IMS IP Multimedia Subsystem
IP Internet Protocol
ISO International Organisation for Standardisation
JSON JavaScript Object Notation
MC Mission Critical
NTT Network Transition Trigger
OCSP Online Certificate Status Protocol
PLMN Public Land Mobile Network
RFC Request For Comments
RSP Remote SIM Provisioning
SDS Short Data Service
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SRS System Requirement Specification
SSE Server Sent Events
TLS Transport Layer Security
TPM Trusted Platform Module
UIC International Union of Railways
UTC Coordinated Universal Time
ETSI
9 ETSI TS 103 765-3 V1.1.1 (2026-01)
4 On-Board FRMCS reference points
4.1 Background
This clause covers the external reference points of the On-Board FRMCS (see Figure 4.1-1) as defined in UIC FRMCS
SRS [i.1].
OB FS
OM OMR
Application(s) On-Board FRMCS
OB
ANT
OB
APP
Figure 4.1-1: On-Board FRMCS external reference points
4.2 OB
App
The on-board communication system will interact with several on-board applications. Due to this, the interface OB
APP
has to ensure the proper handling and management of the interconnected applications and grant access to the
communication services provided taking into account the priority and quality of service profile requested by those
applications.
The OB reference point is fully specified in UIC FRMCS FFFIS [5]. The behaviour expected from the On-Board
APP
FRMCS in relation with the OB is specified in clause 7.3.
APP
4.3 FS
OMR
4.3.1 Introduction
The present document only covers a subset of FS functionality defined in UIC FRMCS SRS [i.1], namely those for
OMR
the purpose of obtaining FRMCS Railway On-Board Profile (FROP) and FRMCS On-Board Application Profile
(FOAP).
4.3.2 Profiles management
The FS enables profiles management in FRMCS for the On-Board FRMCS across three essential functionalities:
OMR
• SIM profile management.
• TLS certificates management.
• Management of other profile information.
For SIM profile management, the functionalities are delegated to individual On-Board FRMCS Radio Modules using
the GSMA Remote SIM Provisioning architecture (see GSMA SGP.21 [i.3] and GSMA SGP.22 [i.4]), as specified in
ETSI TS 103 765-5 [3], clause 4.1.2.
ETSI
10 ETSI TS 103 765-3 V1.1.1 (2026-01)
For TLS certificates management, the On-Board FRMCS shall support:
• For certificates revocation checking:
- The Online Certificate Status Protocol (OCSP) with extensions as specified in IETF RFC 6960 [6] and
IETF RFC 9654 [7].
- OCSP stapling as specified in IETF RFC 6066 [8] and IETF RFC 6961 [9].
• For automated certificate lifecycle management, one of the following protocols:
- Automated Certificate Management Environment (ACME), as specified in IETF RFC 8555 [10].
- Enrollment over Secure Transport (EST), as specified in IETF RFC 7030 [11].
NOTE: For automated certificate lifecycle management, the choice of protocols reflects that different railway
organizations can have different approaches on this matter.
For management of other profile information, the On-Board FRMCS need to implement a MCData client with support
for establishment of MCData IPcon connectivity and MCData Short Data Service.
The MCData client for FS within the On-Board FRMCS shall:
OMR
• Support the MCData client general procedures for SDS as specified in ETSI TS 124 282 [13], clauses 9.2.1.2
and 9.2.1.3.
• Support the MCData client terminating procedures for Standalone SDS using signalling control plane as
specified in ETSI 124 282 [13], clause 9.2.2.2.2.
4.4 OB
ANT
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
ANT
4.5 OB
OM
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
OM
5 On-Board FRMCS general requirements
5.1 On-Board FRMCS Radio Modules
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 765-5 [3], clause 4.
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 793 [4], clauses 4 and 6.
5.2 Location and positioning
5.2.1 Generalities
The On-Board FRMCS is expected to provide location information based on three possible sources: cellular network,
GNSS and external sources. Obtaining information from external sources is out of scope of the present document.
ETSI
11 ETSI TS 103 765-3 V1.1.1 (2026-01)
5.2.2 Functional requirements
The On-Board FRMCS shall be equipped with a GNSS receiver.
The GNSS receiver of the On-Board FRMCS shall be capable of receiving and processing signals from at least two
satellite constellations.
The On-Board FRMCS shall be able to obtain CellID information from each of its On-Board FRMCS Radio Modules.
NOTE: The present document does not specify the criteria to select one CellID among several different ones
received by the On-Board FRMCS Radio Modules.
5.3 Profile Storage
The support of Loose-Coupled Applications by an On-Board FRMCS and the distribution of functionalities between the
MC Clients within the On-Board FRMCS on the one hand and the On-Board FRMCS Radio Module(s) on the other
hand imply that the On-Board FRMCS has to store and manage sensitive information (such as credentials) that would
traditionally be stored within a SIM card.
The On-Board FRMCS shall be equipped with a secure enclave, i.e. a tamper resistant secure hardware component
(e.g. TPM, HSM) or equivalent storage protection mechanisms.
NOTE 1: The present document does not specify specific requirements on the implementation of the secure
enclave.
The On-Board FRMCS shall store at least the following elements in the secure enclave:
• Credentials associated with each MC User ID required by supported On-Board Loose-Coupled Applications.
• IMS/SIP Core credentials associated with each MC User ID required by supported On-Board Loose-Coupled
Applications.
NOTE 2: The Voice Application Service or other Tight-Coupled Applications are expected to be equipped with
their own secure profile storage capabilities.
The credentials shall be integrity protected within the On-Board FRMCS secure enclave. The long-term key(s) of the
subscription credential(s) shall be confidentiality protected within the On-Board FRMCS secure enclave. The long-term
key(s) of the subscription credential(s) shall never be available in the clear outside of the secure enclave. The
authentication algorithm(s) that make use of the subscription credentials shall always be executed within the secure
enclave.
6 On-Board Multipath Function
An On-Board FRMCS supporting FRMCS Multipath shall:
• Implement a Multipath Client as specified in ETSI TS 103 765-1 [1], clause 5.3.5.
• Comply with the procedures related to the Multipath Client as specified in ETSI TS 103 765-1 [1],
clause 5.3.7.
ETSI
12 ETSI TS 103 765-3 V1.1.1 (2026-01)
7 On-Board FRMCS procedures
7.1 General procedures
7.1.1 FRMCS Start of Operation
The FRMCS Start of Operation (FSOP) procedure is supporting the transition of On-Board FRMCS operational mode
from the train power-up until the moment On-Board FRMCS is in FRMCS Domain availability state. The procedure
describes the expected behaviour from On-Board FRMCS and FRMCS Domain upon power-up of the train and the
attempt from an On-Board FRMCS to acquire the FRMCS Domain.
Pre-requisite: The On-Board FRMCS knows the FRMCS Transport Domain to connect to.
The following steps are undertaken:
1) The On-Board FRMCS shall select one or more On-Board FRMCS Radio Modules. The mechanism for
selection is not specified in the present document.
2) For each On-Board FRMCS Radio Module selected at the previous step, the On-Board FRMCS shall execute
the On-Board FRMCS Radio Module registration to the FRMCS Transport Domain procedure as specified in
ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall select one On-Board FRMCS Radio Module amongst the On-Board FRMCS
Radio Modules selected at step 2 to use for FRMCS Multipath discovery.
4) The On-Board FRMCS shall execute the FRMCS Multipath discovery procedure as specified in ETSI
TS 103 765-1 [1], clause 5.3.7.1 with the On-Board FRMCS Radio Module selected at the previous step.
5) The On-Board FRMCS shall retrieve from the FRMCS Railway On-Board Profile the list of Startup
Applications and their associated parameters. The mechanism for retrieval of the information from the
FRMCS Railway On-Board Profile is not specified in the present document.
6) For each Loose-Coupled Application identified at the previous step, the On-Board FRMCS shall execute the
MC Client IP assignment procedure as specified in clause 7.2.1 of the present document and assign it to a MC
Client. The mechanism for selection of a MC Client to assign is not specified in the present document.
7) For each Loose-Coupled Application identified at the previous step, if the FRMCS Multipath discovery
(step 4) was successful and if FRMCS Multipath is enabled according to the FRMCS Railway On-Board
Profile (step 5), the On-Board FRMCS shall execute the FRMCS Multipath data path selection procedure as
specified in ETSI TS 103 765-1 [1], clause 5.3.7.2 with the FRMCS Multipath parameters obtained at step 5.
8) The On-Board FRMCS shall execute the Transport path establishment for Mission Critical signalling
procedure as specified in ETSI TS 103 765-1 [1], clause 6.2.
9) For each Tight-Coupled Application identified at step 5 and in Locally Bound state, the On-Board FRMCS
shall notify the application of the availability of the FRMCS Transport Domain by sending a notification of
type ftdAvlNotif on the notification event stream associated with the application as specified in clause 7.3.3.5
of the present document.
10) For each Loose-Coupled Application identified at step 5, the MC Client assigned to the application at step 6
should execute the MC Client readiness procedure as specified in clause 7.2.2.
NOTE: The timely execution of the procedure at step 11 would allow a faster session establishment time. It is left
to implementation as to when the On-Board FRMCS executes the procedure.
7.1.2 FRMCS Close of Operation
The FRMCS Close of Operation (FCOP) procedure describes the expected behaviour of On-Board FRMCS and
FRMCS Domain upon attempt by an On-Board FRMCS to disconnect from the FRMCS System.
ETSI
13 ETSI TS 103 765-3 V1.1.1 (2026-01)
The following steps are undertaken:
1) For each application in Locally Bound state:
a) the On-Board FRMCS shall notify the application of its upcoming deregistration from the On-Board
FRMCS by sending a notification of type upcomingDeregistration on the notification event stream
associated with the application as specified in clause 7.3.3.5; and
b) the On-Board FRMCS shall start a deregistration timer, T_DEREGISTRATION_TIMER, allowing the
applications to take actions (e.g. for cleaning up their contexts).
2) At the expiry of the T_DEREGISTRATION_TIMER:
a) For a Loose-Coupled Application:
i) The On-Board FRMCS shall perform for each ongoing session the ongoing communication release
as specified in clause 7.2.6.
ii) The On-Board FRMCS shall execute the MC Client teardown procedure as specified in
clause 7.2.4.
iii) The On-Board FRMCS shall perform the OB Application Context clearance procedure as
APP
specified in clause 7.2.5.
b) For a Tight-Coupled Application:
i) The On-Board FRMCS shall perform the OB Application Context clearance procedure as
APP
specified in clause 7.2.5.
3) If a FRMCS Multipath control link is established, the On-Board FRMCS shall execute the Multipath Control
Protocol cleanup procedure as specified in ETSI TS 103 765-1 [1], clause 5.3.7.6.
4) For each On-Board FRMCS Radio Module, the On-Board FRMCS shall execute the On-Board Radio Module
deregistration to the FRMCS Transport Domain procedure as specified in ETSI TS 103 765-1 [1], clause 6.3.
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio
Modules
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure
Precondition:
• The On-Board FRMCS has received a Network Transition Trigger (NTT) indicating the Target FRMCS
Transport Domain (identified by a PLMN ID).
• The On-Board FRMCS has selected a Target On-Board FRMCS Radio Module.
• The Target On-Board FRMCS Radio Module is different from the Serving On-Board FRMCS Radio Module
and does not carry any other communication which requires service continuity.
The following steps are undertaken:
1) For each ongoing communication carried by the Target On-Board FRMCS Radio Module, the On-Board
FRMCS shall perform the ongoing communication release as specified in clause 7.2.6.
2) The On-Board FRMCS shall perform the registration of the Target On-Board FRMCS Radio Module in the
Target FRMCS Transport Domain as specified in ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall perform transport path establishment on the Target On-Board FRMCS Radio
Module to enable MC signaling towards the Target FRMCS Service Domain as specified in ETSI
TS 103 765-1 [1], clause 6.2.
ETSI
14 ETSI TS 103 765-3 V1.1.1 (2026-01)
NOTE 1: In the case of IFDT with dual On-Board FRMCS Radio Modules, during the transition, the On-Board
FRMCS can still maintain a transport path on the Serving On-Board FRMCS Radio Module towards the
Serving FRMCS Domain (e.g. for the purpose MC signalling that allows the proper release of an ongoing
communication in Serving FRMCS Service Domain during the transition - see step 4b).
NOTE 2: If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS
also needs in the following step a transport path towards the Home FRMCS Service Domain (e.g. for the
purpose of the HTTP exchanges with primary IdM server).
4) For each Loose-Coupled Application in Locally Bound state and identified as Type I or III in the FRMCS
Railway On-Board Profile:
a) If the application has no open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.1.
b) If the application has an open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.2.
5) For each Loose-Coupled Application in Locally Bound state and identified as Type II in the FRMCS Railway
On-Board Profile:
a) If the On-Board FRMCS is entering a FRMCS Domain within the Domain of applicability of the
application, the On-Board FRMCS shall perform the procedure identified in clause 7.1.3.3.1.
b) If the On-Board FRMCS is entering a FRMCS Domain which is not in the Domain of applicability of the
application, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.3.2.
6) For each Loose-Coupled Application in Locally Bound state and identified as Type IV in the FRMCS Railway
On-Board Profile, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.4.
7) For each Tight-Coupled Application in Locally Bound state, the On-Board FRMCS shall notify the application
of the availability of the Target FRMCS Transport Domain on the notification event stream associated with the
application as specified in clause 7.3.3.5. The JSON structure being passed is of type "ftdAvlNotif" (as
specified in FRMCS FFFIS-7950 [5], clause 9.11.1.11) filled as follows:
i) The ftdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
iii) The FrmcsDomain field shall be set to the PLMN ID representing the Target FRMCS Transport Domain.
NOTE 3: The On-Board FRMCS needs to uniquely associate a Target FRMCS Service Domain to a Target
FRMCS Transport Domain (PLMN ID) for the network transition points.
NOTE 4: On-Board Tight-Coupled Application will need to uniquely associate a Target FRMCS Service Domain
to a Target FRMCS Transport Domain (PLMN ID) for the network transition points. This is however out
of scope of the present document and left to the discretion of the implementers of these applications.
ETSI
15 ETSI TS 103 765-3 V1.1.1 (2026-01)
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has no open session, the following steps are undertaken:
1) One of the following cases is performed depending on whether the Target FRMCS service Domain is the
Home FRMCS Service Domain or a Foreign FRMCS Service Domain:
a) If the Target FRMCS Service Domain is a Foreign FRMCS Service Domain, the On-Board FRMCS
shall perform the "MC Service User migration" procedure between Serving FRMCS Service Domain and
Target FRMCS Service Domain as specified in ETSI TS 103 765-2 [2], clause 6.4.1, using the MC
credentials and IMS credentials retrieved from the FRMCS Railway On-Board Application.
b) If the Target FRMCS Service Domain is the Home FRMCS Service Domain, the On-Board FRMCS
shall perform "MC User registration" in Home FRMCS Service Domain (see ETSI TS 103 765-2 [2],
clause 6.1).
If the step is unsuccessful, it shall be repeated every T_RETRY_MCUSR_MIG seconds for a maximum of
N_RETRY_MCUSR_MIG times before it can be considered as a failure in step 4.
2) If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS shall
perform "Migrated MC Service User deauthorization" in Serving FRMCS Service Domain (see ETSI
TS 103 765-2 [2], clause 6.4.2).
NOTE: This procedure is performed on the same MC User ID which was serving the application in the Serving
FRMCS Service Domain before the transition.
3) If step 1 is successful, the On-Board FRMCS shall notify the application of the availability of the FRMCS
Service Domain on the notification event stream associated with the application as specified in clause 7.3.3.5.
The JSON structure being passed is of type "fsdAvlNotifData" (as specified in FRMCS FFFIS-7950 [5],
clause 9.11.1.12) filled as follows:
i) The fsdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
4) If step 1 failed, the On-Board FRMCS shall notify the application of the unavailability of the Target FRMCS
Service Domain on the notification event stream associated with the application as specified in clause 7.3.3.5.
The JSON structure being passed is of type "fsdAvlNotifData" (as specified in FRMCS FFFIS-7950 [5],
clause 9.11.1.12) filled as follows:
i) The fsdAVL field shall be set to FALSE.
ii) The nwTransition field shall be set to TRUE.
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has at least one open session, the following steps are
undertaken:
1) If the FRMCS Railway On-board Profile for the Loose-Coupled Application does not include the
"IFSDT_Dual_MCID" parameter:
a) The On-Board FRMCS shall perform the "MCData IPcon release" procedure as specified in ETSI
TS 103 765-2 [2], clause 6.2.2.5 for the open sessions in the Serving FRMCS Service Domain.
...

SLOVENSKI STANDARD
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
01-september-2025
Železniške telekomunikacije (RT) - Prihodnji sistem radijskih komunikacij za
železnice (FRMCS) - Gradniki in funkcionalnosti - 3. del: Funkcionalnosti in
vmesniki na vlaku
Rail Telecommunications (RT) - Future Railway Mobile Communication System
(FRMCS) - Building Blocks and Functions - Part 3: Train On-Board functions and
interfaces
Ta slovenski standard je istoveten z: ETSI TS 103 765-3 V1.0.0 (2025-07)
ICS:
33.060.01 Radijske komunikacije na Radiocommunications in
splošno general
45.020 Železniška tehnika na Railway engineering in
splošno general
oSIST-TS ETSI/prTS 103 765-3 en
V1.0.0:2025
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025

oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
Draft ETSI TS 103 765-3 V1.0.0 (2025-07)

TECHNICAL SPECIFICATION
Rail Telecommunications (RT);
Future Railway Mobile Communication System (FRMCS);
Building Blocks and Functions;
Part 3: Train On-Board functions and interfaces

oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
2 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)

Reference
DTS/RT-0085
Keywords
FRMCS, interface, protocol, railways
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
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 ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
3 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 On-Board FRMCS reference points . 9
4.1 Background . 9
4.2 OB . 9
App
4.3 FS . 9
OMR
4.3.1 Introduction. 9
4.3.2 Profiles management. 9
4.4 OB . 10
ANT
4.5 OB . 10
OM
5 On-Board FRMCS general requirements . 10
5.1 On-Board FRMCS Radio Modules . 10
5.2 Location and positioning . 10
5.2.1 Generalities . 10
5.2.2 Functional requirements . 10
5.3 Profile Storage . 11
6 On-Board Multipath Function . 11
7 On-Board FRMCS procedures . 11
7.1 General procedures . 11
7.1.1 FRMCS Start of Operation . 11
7.1.2 FRMCS Close of Operation . 12
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio Modules . 13
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure . 13
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications. 14
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open session . 14
7.1.3.2.2 Inter-FRMCS Domain transition: Type I or Type III applications with an open session . 15
7.1.3.3 Inter-FRMCS Domain transition: Type II applications . 16
7.1.3.3.1 Inter-FRMCS Domain transition: Type II applications entering the Domain of applicability . 16
7.1.3.3.2 Inter-FRMCS Domain transition: Type II applications entering a FRMCS Domain which is
not in the Domain of applicability . 16
7.1.3.4 Inter-FRMCS Domain transition: Type IV applications . 17
7.1.4 GSM-R to FRMCS transition . 17
7.1.4.1 GSM-R to FRMCS transition procedure . 17
7.1.4.2 GSM-R to FRMCS transition: Type I or Type III applications. 18
7.1.4.3 GSM-R to FRMCS transition: Type II applications entering the Domain of applicability . 18
7.1.4.4 GSM-R to FRMCS transition: Type IV applications . 18
7.2 Procedures not associated with a reference point . 18
7.2.1 MC Client IP assignment procedure . 18
7.2.2 MC Client readiness procedure . 18
7.2.3 MC Client readiness for network transition procedure . 19
7.2.4 MC Client teardown procedure . 20
7.2.5 OB Application Context clearance procedure . 20
APP
7.2.6 Ongoing communication release procedure . 21
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
4 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
7.2.7 Logging . 21
7.3 Procedures associated with OB endpoints . 21
APP
7.3.0 Introduction. 21
7.3.1 /registrations endpoint procedures . 22
7.3.1.1 Application registration procedure . 22
7.3.1.2 Application-initiated deregistration procedure . 22
7.3.2 /sessions endpoint procedures . 22
7.3.2.1 On-Board-FRMCS-initiated session initiation procedure . 22
7.3.2.2 On-Board-FRMCS-initiated session termination procedure . 24
7.3.2.3 On-Board-FRMCS-terminated incoming session invite procedure . 24
7.3.2.4 On-Board-FRMCS-terminated incoming session response procedure . 25
7.3.2.5 On-Board-FRMCS-terminated session termination procedure . 26
7.3.2.6 Information query on ongoing sessions for an application. 26
7.3.2.7 Information query on a specific ongoing session for an application . 26
7.3.3 /notifications endpoint procedures . 26
7.3.3.1 Procedure for opening the notification event stream . 26
7.3.3.2 Procedure upon subscription to a channel . 27
7.3.3.3 Procedure upon unsubscription from all channels . 27
7.3.3.4 Procedure upon unsubscription from a channel . 27
7.3.3.5 Procedure of notification to an application over a channel . 27
7.3.3.6 Procedure upon subscription to location reporting channel . 28
7.3.3.7 Procedure to list subscriptions of an application . 28
7.3.3.8 Procedure to unsubscribe an application from a specific subscription . 28
7.3.4 /versions endpoint procedure . 28
7.3.5 /keepalive endpoint procedure . 28
History . 29

ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
5 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Railway Telecommunications (RT)
and is now submitted for the combined Public Enquiry and Vote phase of the ETSI Standardisation Request deliverable
Approval Procedure (SRdAP).
The present document is part 3 of a multi-part deliverable covering Building Blocks and Functions for the Future
Railway Mobile Communication System (FRMCS), as identified below:
Part 1: "Transport Stratum";
Part 2: "Service Stratum";
Part 3: "Train On-Board functions and interfaces";
Part 4: "Trackside functions and interfaces";
Part 5: "User Equipment (UE) capabilities".
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 in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
6 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
1 Scope
The present document specifies the interfaces of the On-Board FRMCS enabling either interaction with On-Board
applications or with FRMCS entities outside the train. The present document also specifies the On-Board Multipath
Function and a set of procedures the On-Board FRMCS will need to conform to.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 765-1: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 1: Transport Stratum".
[2] ETSI TS 103 765-2: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 2: Service Stratum".
[3] ETSI TS 103 765-5: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Building Blocks and Functions; Part 5: User Equipment (UE) capabilities".
[4] ETSI TS 103 793: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Radio Characteristics".
[5] UIC FFFIS-7950 (V2.1.0): "FRMCS FFFIS Form Fit Functional Interface Specification".
[6] IETF RFC 6960: "X.509 Internet Public Key Infrastructure, Online Certificate Status
Protocol - OCSP".
[7] IETF RFC 9654: "Online Certificate Status Protocol (OCSP) Nonce Extension".
[8] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[9] IETF RFC 6961: "The Transport Layer Security (TLS) Multiple Certificate Status Request
Extension".
[10] IETF RFC 8555: "Automated Certificate Management Environment (ACME)".
[11] IETF RFC 7030: "Enrollment over Secure Transport".
[12] ETSI TS 133 180 (V18.1.0): "LTE; Security of the Mission Critical (MC) service (3GPP
TS 33.180 version 18.1.0 Release 18)".
[13] ETSI TS 124 282 (V18.10.0): "LTE; Mission Critical Data (MCData) signalling control; Protocol
specification (3GPP TS 24.282 version 18.10.0 Release 18)".
[14] ISO 8601 (2019): "Date and time — Representations for information interchange".
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
7 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] UIC FRMCS SRS: "FRMCS System Requirements Specification".
[i.2] ETSI TR 103 791: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); Terminology for FRMCS specifications".
[i.3] GSMA™ SGP.21 V3.1: "RSP Architecture".
[i.4] GSMA™ SGP.22 V3.1: "RSP Technical Specification".
[i.5] ETSI TS 124 229 (V18.7.0): "Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS); LTE; 5G; IP multimedia call control
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);
Stage 3 (3GPP TS 24.229 version 18.7.0 Release 18)".
[i.6] ETSI TS 103 764: "Rail Telecommunications (RT); Future Railway Mobile Communication
System (FRMCS); System Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TR 103 791 [i.2] and the following apply:
OBAPP Application Context: context maintained by the On-Board FRMCS for an application instance (identified by
the OBAPP Application Tuple), in between registration and de-registration
OBAPP Application Tuple: tuple of appCategory, staticId, couplingMode
NOTE: As specified in UIC FRMCS FFFIS-7950 [5], clause 9.10.1.
service continuity: capability of the FRMCS system to maintain the communication service for the user in an
acceptable level during the Inter-FRMCS-Domain Transition
Serving FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is currently carrying/serving
the communications of applications of Type I (IM interoperable applications)
NOTE: In the Inter-FRMCS-Transport-Domain transition procedure, this is the FRMCS Transport/Service
Domain before the transition takes place.
Serving On-Board FRMCS Radio Module: On-Board FRMCS Radio Module carrying in the Serving FRMCS
Transport Domain at least the active communication services for applications of Type I (IM interoperable applications)
with service continuity requirement
Target FRMCS Transport/Service Domain: FRMCS Transport/Service Domain which is the target of network
transition for applications of Type I (IM interoperable applications)
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
FRMCS Domain becomes the Serving FRMCS Domain.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
8 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
Target On-Board FRMCS Radio Module: On-Board FRMCS Radio Module which is intended to be attached to the
Target FRMCS Transport Domain following the FRMCS domain transition
NOTE: At the completion of network transition (from GSM-R or from a previous FRMCS Domain), the Target
On-Board FRMCS Radio Module becomes the Serving On-Board FRMCS Radio Module in the new
FRMCS Domain.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACME Automated Certificate Management Environment
API Application Programming Interface
CellID Cell IDentifier
EST Enrollment over Secure Transport
FA Functional Alias
FCOP FRMCS Close of OPeration
FFFIS Form Fit Functional Interface Specification
FOAP FRMCS On-Board Application Profile
FRMCS Future Railway Mobile Communication System
FROP FRMCS Railway On-Board Profile
FSOP FRMCS Start of OPeration
GNSS Global Navigation Satellite System
GSMA GSM Association
GSM-R Global System for Mobile Communications - Railway
HSM Hardware Security Module
HTTP Hyper Text Transfer Protocol
ID Identity
IdM Identity Management
IETF Internet Engineering Task Force
IFDT Inter FRMCS Domain Transition
IFSDT Inter-FRMCS Service Domain Transition
IM Infrastrcuture Manager
IMS IP Multimedia Subsystem
IP Internet Protocol
ISO International Organisation for Standardisation
JSON JavaScript Object Notation
MC Mission Critical
NTT Network Transition Trigger
OCSP Online Certificate Status Protocol
PLMN Public Land Mobile Network
RFC Request For Comments
RSP Remote SIM Provisioning
SDS Short Data Service
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SRS System Requirment Specification
SSE Server Sent Events
TLS Transport Layer Security
TPM Trusted Platform Module
UIC International Union of Railways
UTC Coordinated Universal Time
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
9 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
4 On-Board FRMCS reference points
4.1 Background
This clause covers the external reference points of the On-Board FRMCS (see Figure 4.1-1) as defined in UIC FRMCS
SRS [i.1].
OB FS
OM OMR
Application(s) On-Board FRMCS
OB
ANT
OB
APP
Figure 4.1-1: On-Board FRMCS external reference points
4.2 OB
App
The on-board communication system will interact with several on-board applications. Due to this, the interface OB
APP
has to ensure the proper handling and management of the interconnected applications and grant access to the
communication services provided taking into account the priority and quality of service profile requested by those
applications.
The OB reference point is fully specified in UIC FRMCS FFFIS [5]. The behaviour expected from the On-Board
APP
FRMCS in relation with the OB is specified in clause 7.3.
APP
4.3 FS
OMR
4.3.1 Introduction
The present document only covers a subset of FS functionality defined in UIC FRMCS SRS [i.1], namely those for
OMR
the purpose of obtaining FRMCS Railway On-Board Profile (FROP) and FRMCS On-Board Application Profile
(FOAP).
4.3.2 Profiles management
The FS enables profiles management in FRMCS for the On-Board FRMCS across three essential functionalities:
OMR
• SIM profile management.
• TLS certificates management.
• Management of other profile information.
For SIM profile management, the functionalities are delegated to individual On-Board FRMCS Radio Modules using
the GSMA Remote SIM Provisioning architecture (see GSMA SGP.21 [i.3] and GSMA SGP.22 [i.4]), as specified in
ETSI TS 103 765-5 [3], clause 4.1.2.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
10 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
For TLS certificates management, the On-Board FRMCS shall support:
• For certificates revocation checking:
- The Online Certificate Status Protocol (OCSP) with extensions as specified in IETF RFC 6960 [6] and
IETF RFC 9654 [7].
- OCSP stapling as specified in IETF RFC 6066 [8] and IETF RFC 6961 [9].
• For automated certificate lifecycle management, one of the following protocols:
- Automated Certificate Management Environment (ACME), as specified in IETF RFC 8555 [10].
- Enrollment over Secure Transport (EST), as specified in IETF RFC 7030 [11].
NOTE: For automated certificate lifecycle management, the choice of protocols reflects that different railway
organizations can have different approaches on this matter.
For management of other profile information, the On-Board FRMCS need to implement a MCData client with support
for establishment of MCData IPcon connectivity and MCData Short Data Service.
The MCData client for FS within the On-Board FRMCS shall:
OMR
• Support the MCData client general procedures for SDS as specified in ETSI TS 124 282 [13], clauses 9.2.1.2
and 9.2.1.3.
• Support the MCData client terminating procedures for Standalone SDS using signalling control plane as
specified in ETSI 124 282 [13], clause 9.2.2.2.2.
4.4 OB
ANT
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
ANT
4.5 OB
OM
The present document does not specify the OB reference point or its use within an On-Board FRMCS.
OM
5 On-Board FRMCS general requirements
5.1 On-Board FRMCS Radio Modules
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 765-5 [3], clause 4.
An On-Board FRMCS Radio Module shall comply with ETSI TS 103 793 [4], clauses 4 and 6.
5.2 Location and positioning
5.2.1 Generalities
The On-Board FRMCS is expected to provide location information based on three possible sources: cellular network,
GNSS and external sources. Obtaining information from external sources is out of scope of the present document.
5.2.2 Functional requirements
The On-Board FRMCS shall be equipped with a GNSS receiver.
The GNSS receiver of the On-Board FRMCS shall be able to receive at least two satellite constellations.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
11 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
The On-Board FRMCS shall be able to obtain CellID information from each of its On-Board FRMCS Radio Modules.
NOTE: The present document does not specify the criteria to select one CellID among several different ones
received by the On-Board FRMCS Radio Modules.
5.3 Profile Storage
The support of Loose-Coupled Applications by an On-Board FRMCS and the distribution of functionalities between the
MC Clients within the On-Board FRMCS on the one hand and the On-Board FRMCS Radio Module(s) on the other
hand imply that the On-Board FRMCS has to store and manage sensitive information (such as credentials) that would
traditionally be stored within a SIM card.
The On-Board FRMCS shall be equipped with a secure enclave, i.e. a tamper resistant secure hardware component
(e.g. TPM, HSM) or equivalent storage protection mechanisms.
NOTE 1: The present document does not specify specific requirements on the implementation of the secure
enclave.
The On-Board FRMCS shall store at least the following elements in the secure enclave:
• Credentials associated with each MC User ID required by supported On-Board Loose-Coupled Applications.
• IMS/SIP Core credentials associated with each MC User ID required by supported On-Board Loose-Coupled
Applications.
NOTE 2: The Voice Application Service or other Tight-Coupled Applications are expected to be equipped with
their own secure profile storage capabilities.
The credentials shall be integrity protected within the On-Board FRMCS secure enclave. The long-term key(s) of the
subscription credential(s) shall be confidentiality protected within the On-Board FRMCS secure enclave. The long-term
key(s) of the subscription credential(s) shall never be available in the clear outside of the secure enclave. The
authentication algorithm(s) that make use of the subscription credentials shall always be executed within the secure
enclave.
6 On-Board Multipath Function
An On-Board FRMCS supporting FRMCS Multipath shall:
• Implement a Multipath Client as specified in ETSI TS 103 765-1 [1], clause 5.3.5.
• Comply with the procedures related to the Multipath Client as specified in ETSI TS 103 765-1 [1],
clause 5.3.7.
7 On-Board FRMCS procedures
7.1 General procedures
7.1.1 FRMCS Start of Operation
The FRMCS Start of Operation (FSOP) procedure is supporting the transition of On-Board FRMCS operational mode
from the train power-up until the moment On-Board FRMCS is in FRMCS Domain availability state. The procedure
describes the expected behaviour from On-Board FRMCS and FRMCS Domain upon power-up of the train and the
attempt from an On-Board FRMCS to acquire the FRMCS Domain.
Pre-requisite: The On-Board FRMCS knows the FRMCS Transport Domain to connect to.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
12 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
The following steps are undertaken:
1) The On-Board FRMCS shall select one or more On-Board FRMCS Radio Modules. The mechanism for
selection is not specified in the present document.
2) For each On-Board FRMCS Radio Module selected at the previous step, the On-Board FRMCS shall execute
the On-Board FRMCS Radio Module registration to the FRMCS Transport Domain procedure as specified in
ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall select one On-Board FRMCS Radio Module amongst the On-Board FRMCS
Radio Modules selected at step 2 to use for FRMCS Multipath discovery.
4) The On-Board FRMCS shall execute the FRMCS Multipath discovery procedure as specified in ETSI
TS 103 765-1 [1], clause 5.3.7.1 with the On-Board FRMCS Radio Module selected at the previous step.
5) The On-Board FRMCS shall retrieve from the FRMCS Railway On-Board Profile the list of Startup
Applications and their associated parameters. The mechanism for retrieval of the information from the
FRMCS Railway On-Board Profile is not specified in the present document.
6) For each Loose-Coupled Application identified at the previous step, the On-Board FRMCS shall execute the
MC Client IP assignment procedure as specified in clause 7.2.1 of the present document and assign it to a MC
Client. The mechanism for selection of a MC Client to assign is not specified in the present document.
7) For each Loose-Coupled Application identified at the previous step, if the FRMCS Multipath discovery
(step 5) was successful and if FRMCS Multipath is enabled according to the FRMCS Railway On-Board
Profile (step 6), the On-Board FRMCS shall execute the FRMCS Multipath data path selection procedure as
specified in ETSI TS 103 765-1 [1], clause 5.3.7.2 with the FRMCS Multipath parameters obtained at step 6.
8) The On-Board FRMCS shall execute the Transport path establishment for Mission Critical signalling
procedure as specified in ETSI TS 103 765-1 [1], clause 6.2.
9) For each Tight-Coupled Application identified at step 6 and in Locally Bound state, the On-Board FRMCS
shall notify the application of the availability of the FRMCS Transport Domain by sending a notification of
type ftdAvlNotif on the notification event stream associated with the application as specified in clause 7.3.3.5
of the present document.
10) For each Loose-Coupled Application identified at step 6, the MC Client assigned to the application at step 7
should execute the MC Client readiness procedure as specified in clause 7.2.2.
NOTE: The timely execution of the procedure at step 11 would allow a faster session establishment time. It is left
to implementation as to when the On-Board FRMCS executes the procedure.
7.1.2 FRMCS Close of Operation
The FRMCS Close of Operation (FCOP) procedure describes the expected behaviour of On-Board FRMCS and
FRMCS Domain upon attempt by an On-Board FRMCS to disconnect from the FRMCS System.
The following steps are undertaken:
1) For each application in Locally Bound state:
a) the On-Board FRMCS shall notify the application of its upcoming deregistration from the On-Board
FRMCS by sending a notification of type upcomingDeregistration on the notification event stream
associated with the application as specified in clause 7.3.3.5; and
b) the On-Board FRMCS shall start a deregistration timer, T_DEREGISTRATION_TIMER, allowing the
applications to take actions (e.g. for cleaning up their contexts).
2) At the expiry of the T_DEREGISTRATION_TIMER:
a) For a Loose-Coupled Application:
i) The On-Board FRMCS shall perform for each ongoing session the ongoing communication release
as specified in clause 7.2.6.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
13 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
ii) The On-Board FRMCS shall execute the MC Client teardown procedure as specified in
clause 7.2.4.
Application Context clearance procedure as
iii) The On-Board FRMCS shall perform the OBAPP
specified in clause 7.2.5.
b) For a Tight-Coupled Application:
i) The On-Board FRMCS shall perform the OB Application Context clearance procedure as
APP
specified in clause 7.2.5.
3) If a FRMCS Multipath control link is established, the On-Board FRMCS shall execute the Multipath Control
Protocol cleanup procedure as specified in ETSI TS 103 765-1 [1], clause 5.3.7.6.
4) For each On-Board FRMCS Radio Module, the On-Board FRMCS shall execute the On-Board Radio Module
deregistration to the FRMCS Transport Domain procedure as specified in ETSI TS 103 765-1 [1], clause 6.3.
7.1.3 Inter-FRMCS Domain Transition using two On-Board FRMCS Radio
Modules
7.1.3.1 Inter-FRMCS Domain Transition (IFDT) procedure
Precondition:
• The On-Board FRMCS has received a Network Transition Trigger (NTT) indicating the Target FRMCS
Transport Domain (identified by a PLMN ID).
• The On-Board FRMCS has selected a Target On-Board FRMCS Radio Module.
• The Target On-Board FRMCS Radio Module is different from the Serving On-Board FRMCS Radio Module
and does not carry any other communication which requires service continuity.
The following steps are undertaken:
1) For each ongoing communication carried by the Target On-Board FRMCS Radio Module, the On-Board
FRMCS shall perform the ongoing communication release as specified in clause 7.2.6.
2) The On-Board FRMCS shall perform the registration of the Target On-Board FRMCS Radio Module in the
Target FRMCS Transport Domain as specified in ETSI TS 103 765-1 [1], clause 6.1.
3) The On-Board FRMCS shall perform transport path establishment on the Target On-Board FRMCS Radio
Module to enable MC signaling towards the Target FRMCS Service Domain as specified in ETSI
TS 103 765-1 [1], clause 6.2.
NOTE 1: In the case of IFDT with dual On-Board FRMCS Radio Modules, during the transition, the On-Board
FRMCS can still maintain a transport path on the Serving On-Board FRMCS Radio Module towards the
Serving FRMCS Domain (e.g. for the purpose MC signalling that allows the proper release of an ongoing
communication in Serving FRMCS Service Domain during the transition - see step 4b).
NOTE 2: If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS
also needs in the following step a transport path towards the Home FRMCS Service Domain (e.g. for the
purpose of the HTTP exchanges with primary IdM server).
4) For each Loose-Coupled Application in Locally Bound state and identified as Type I or III in the FRMCS
Railway On-Board Profile:
a) If the application has no open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.1.
b) If the application has an open session, the On-Board FRMCS shall execute the procedure identified in
clause 7.1.3.2.2.
ETSI
oSIST-TS ETSI/prTS 103 765-3 V1.0.0:2025
14 Draft ETSI TS 103 765-3 V1.0.0 (2025-07)
5) For each Loose-Coupled Application in Locally Bound state and identified as Type II in the FRMCS Railway
On-Board Profile:
a) If the On-Board FRMCS is entering a FRMCS Domain within the Domain of applicability of the
application, the On-Board FRMCS shall perform the procedure identified in clause 7.1.3.3.1.
b) If the On-Board FRMCS is entering a FRMCS Domain which is not in the Domain of applicability of the
application, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.3.2.
6) For each Loose-Coupled Application in Locally Bound state and identified as Type IV in the FRMCS Railway
On-Board Profile, the On-Board FRMCS shall execute the procedure identified in clause 7.1.3.4.
7) For each Tight-Coupled Application in Locally Bound state, the On-Board FRMCS shall notify the application
of the availability of the Target FRMCS Transport Domain on the notification event stream associated with the
application as specified in clause 7.3.3.5. The JSON structure being passed is of type "ftdAvlNotif" (as
specified in FRMCS FFFIS-7950 [5], clause 9.11.1.11) filled as follows:
i) The ftdAVL field shall be set to TRUE.
ii) The nwTransition field shall be set to TRUE.
iii) The FrmcsDomain field shall be set to the PLMN ID representing the Target FRMCS Transport Domain.
NOTE 3: The On-Board FRMCS needs to uniquely associate a Target FRMCS Service Domain to a Target
FRMCS Transport Domain (PLMN ID) for the network transition points.
NOTE 4: On-Board Tight-Coupled Application will need to uniquely associate a Target FRMCS Service Domain
to a Target FRMCS Transport Domain (PLMN ID) for the network transition points. This is however out
of scope of the present document and left to the discretion of the implementers of these applications.
7.1.3.2 Inter-FRMCS Domain transition: Type I or Type III applications
7.1.3.2.1 Inter-FRMCS Domain transition: Type I or Type III applications with no open
session
For each Loose-Coupled Application in Locally Bound state and identified as interoperable in any FRMCS Domain in
the FRMCS Railway On-Board Profile, if the application has no open session, the following steps are undertaken:
1) One of the following cases is performed depending on whether the Target FRMCS service Domain is the
Home FRMCS Service Domain or a Foreign FRMCS Service Domain:
a) If the Target FRMCS Service Domain is a Foreign FRMCS Service Domain, the On-Board FRMCS
shall perform the "MC Service User migration" procedure between Serving FRMCS Service Domain and
Target FRMCS Service Domain as specified in ETSI TS 103 765-2 [2], clause 6.4.1, using the MC
credentials and IMS credentials retrieved from the FRMCS Railway On-Board Application.
b) If the Target FRMCS Service Domain is the Home FRMCS Service Domain, the On-Board FRMCS
shall perform "MC User registration" in Home FRMCS Service Domain (see ETSI TS 103 765-2 [2],
clause 6.1).
If the step is unsuccessful, it shall be repeated every T_RETRY_MCUSR_MIG seconds for a maximum of
N_RETRY_MCUSR_MIG times before it can be considered as a failure in step 4.
2) If the Serving FRMCS Service Domain is not the Home FRMCS Service Domain, the On-Board FRMCS shall
perform "Migrated MC Service User deauthorization" in Serving FRMCS Service Domain (see ETSI
TS 103 765-2 [2], clause 6.4.2).
NOTE: This procedure is performed on the same MC User ID which was serv
...