An Approach to Designing Critical Railway Voice Communication

Abstract

The digitalization of railways allows for improvements in service reliability, safety, security, and predictability. It relies on stable connections and innovative services. This paper presents an approach to designing critical railway voice communication applications, which follows the principles of a service-oriented architecture. Security-related functions, such as user data management and policy management that can be reused by different railway applications, are identified and designed as services. Common features, such as role management and presence, location, invite-a-user messaging, assured voice communications, and multiuser talker control, are also designed as services. The resources relevant to each service are defined and their unique identifiers are organized in tree structures. Moreover, the supported methods are described. Use cases illustrate the use of the services’ Application Programming Interfaces (APIs) in critical voice communication applications. The common application logic is modeled using call-state models, which present the application and network views. The models are formally described and it is proven mathematically that they exhibit equivalent behavior. The service API’s performance is studied through emulation to evaluate the injected latency.

1. Introduction

Railways are expected to provide highly reliable, safe, secure, robust, and predictable services. The digitalization of the rail industry can meet this unique set of demands by enabling innovative solutions that optimize operational efficiency and enhance the customer experience. The digitalization of railways relies on stable, reliable, and critical connectivity. Communication solutions for the complex needs of rail operations and infrastructure include connected trains and trackside connectivity, enabling improved onboard monitoring systems and more efficient maintenance.

The International Union of Railways (UIC) established a framework called the Future Railway Mobile Communications System (FRMCS), which was intended to replace the railways’ legacy communication system known as GSM-R. The transition from the GSM-R to the FRMCS, which is based on fifth-generation (5G) mobile technology, will modernize railway services; improve performance, reliability, and security; maximize capacity using critical broadband, and provide a seamless passenger experience. Technologies that will drive the transition to the FRMCS include the Internet of Things, sensor technologies for environmental perception, automated interruption detection, Artificial Intelligence-based automated train control that allows for driverless train movements at an optimal distance, and intelligent solutions for proactive maintenance.

The FRMCS standardization process has been initiated by the UIC. Basic FRMCS standardization documents are the User Requirement Specifications [1], FRMCS Use Cases [2], and the Study of System Architecture [3], which was developed by the European Telecommunications Standard Institute (ETSI).

In [1], a set of technology-independent FRMCS user requirements were defined in the form of individual voice, video, and data applications with railway-specific requirements for latency, bandwidth, and reliability. FRMCS applications should provide intuitive human–machine interfaces and support machine-to-machine communications for the exchange of information and performance of tasks. There are also requirements for the mitigation of the risk of miscommunications and the prevention of unauthorized access.

The applications are classified as communication types and support types. Critical applications are essential for train control and signaling or trackside surveying and maintenance; performance applications are used for the improvement of railway operations such as telemetry, monitoring, and control of non-critical infrastructure; business applications support railway business operations, e.g., Internet access for passengers, video streaming, and other infotainment use cases. Critical communication applications are required for automatic train control, automatic train protection, emergency calls, shunting, and banking operations. Critical communications use 3GPP mission-critical voice, video, and data services and rely on reliable and resilient network connectivity.

The authors of [2], discuss use cases related to the applications listed in [1]. The use cases capture the users’ (devices or humans) particular goals and interactions with the system, without considering the internal system implementation details. Each use case specifies a different way to interact with the system and defines the expected behavior.

In [3], based on an analysis of the FRMCS user requirements, a description of the system’s logical architecture is provided and key deployment and border-crossing scenarios are derived. The document also focuses on the possible technical realization of the FRMCS system. The logical architecture describes the system in the form of functional blocks and the reference points between them, whereas the technical realization describes alternatives for building the system using 3GPP or other body blocks.

As the FRMCS user requirements and use cases only specify the need to provide secure and reliable communication applications, the technical details of FRMCS applications are not considered and are implementation-dependent. The main goal of the paper is to formulate an approach to the design of FRMCS critical voice applications, which is a more technologically acceptable option and is independent of a specific implementation or proprietary solution. In contrast with this goal, various platform-dependent proprietary solutions are not open sourced or available to the wider application developer community. To the best of our knowledge, there is no published research on railway-specific, and in particular, FRMCS-specific services, likely because this is a highly competitive market. The proposed approach facilitates the sharing and modification of Application Programming Interfaces (APIs), which allows them to improve over time and be tailored to specific needs.

The rest of the paper is organized as follows. Section 2 discusses the related works. Section 3 presents the identified common functions that can be used as service bricks in application design. Section 4 describes the REST APIs for services that are used by FRMCS support-type applications. Use cases illustrating the logic of FRMCS critical voice communication applications that make use of FRMCS support applications, as well as the verification of the application logic, are discussed in Section 5. The verification of the approach is provided in Section 6. A discussion of some API performance metrics with a focus on the injected latency is provided in Section 7. Section 8 considers the pros and cons of the proposed approach. The conclusion summarizes the contribution.

2. Related Work

The requirements of the FRMCS for better connectivity, data rates, encryption, and availability, as well as low latency, can be met by 5G radio technology known as New Radio, which appears to be a critical enabler for FRMCS. In [4], the authors evaluate the performance of existing technologies that support off-net communications in the FRMCS. In [5], the authors describe a protocol-based prototype and discuss their results, which demonstrate the key performance indicators of 4G and 5G for critical FRMCS communications. The 5G New Radio latency of critical control communications performance for industrial systems is studied in [6]. The results of the trials, which investigated the signal propagation of the ultra-high-frequency spectrum dedicated to FRMCS, are presented in [7]. The FRMCS’ capacity for satellite communications is evaluated in [8].

Railway communication applications require extended coverage, especially in tunnels and mountainous areas with highly ridged reliefs, and 5G New Radio provides advanced features such as beamforming and Integrated Access and Backhaul (IAB). The use of the IAB technique for traffic transmission in densified networks is illustrated in [9]. Beamforming allows for the increase in the signal strength for particular users for more efficient data transfer and reduces interference. IAB uses the same frequencies as the device it serves to allow for multi-hop backhauling. Direct device-to-device (D2D) communications are also supported by 5G New Radio. D2D traffic does not go through the network nodes. D2D communications benefit the proximity gain, including increased spectral efficiency, higher data rates, increased capacity, lower latency, and power efficiency. The New Radio sidelink capabilities to support vehicle-to-vehicle communications are discussed in [10]. Critical communication and performance applications are expected to use intensive mission-critical (MC) services specified by 3GPP that required low setup and transfer latency, high reliability and availability, group communication, accurate positioning, prioritization, pre-emption handling, extended coverage, and strong security [11].

The latency of 5G is projected to be up to 1 millisecond, which is 200 times faster than 4G, the connectivity reliability is projected to be 99.999%, and the maximum data speeds are projected to be 10 Gbps. Due to the low latency and ultra-high reliability of 5G communications, MC services can offer functionality beyond traditional Push-to-Talk services, including group chat, accurate positioning, prioritization, and emergency handling. In [12], the authors evaluate the capabilities of 5G New Radio to support mission-critical services that require efficient group communications, traffic prioritization, and accurate positioning.

Group applications are used in one-to-many and many-to-many communications. In 5G, mission-critical services allow for group configuration, the identification of group members, the provision of group status data, and a mechanism for authorizing membership or affiliation. In railways, mission-critical group communications allow for connectivity between train drivers, controllers of the train, and infrastructure managers, allowing for multi-train voice communications between drivers and ground users in various use cases such as train control, banking, or shunting. The accuracy of positioning in representative simulation scenarios in 5G networks is evaluated in [13].

Information about the train’s velocity, acceleration, and displacement can be provided by 5G positioning. This allows for the building of digital track maps to improve railway safety and efficiency. The digital track map combined with a variety of sensors, which gather critical train positioning data, can produce continuous and accurate positioning information for controllers and drivers. High-precision positioning allows supervision that ensures the permitted speeds and movements of the trains. The accurate positioning of trains is also required for passenger information systems, proactive maintenance, and resource management. A discussion on the capabilities of 5G mechanisms for accessibility differentiation to maintain mission-critical services is provided in [14].

The prioritization of mission-critical communications is vital for railway applications, whose disruption or failure could cause collisions, train derailments, and human casualties. Prioritization is based on the context of communications, the type of application, and the user’s functional identities [2]. It requires the FRMCS to determine the behavior of the device in the case of multiple communications competing for the user’s attention. The prioritization rules should handle incoming and outgoing communications by enabling, disabling, or holding them. The prioritization function allows for concurrent communications and the user’s choice to accept, reject or hold communications. The prioritization of 5G traffic determines the quality of service (QoS) of the services in use based on the QoS Class Identifier (QCI). Using 5G Access Class Baring (ACB), emergency calls are treated with high-priority access and low-priority calls may be rejected temporarily. The Allocation and Retention Priority (ARP) is used in congestion scenarios.

Emergency railway communication scenarios include public train emergency services with a limited/local impact (e.g., on a train or platform) and they are used to warn about potentially hazardous situations. These services provide emergency help points, where calls can be placed to report an emergency. An emergency situation requires an immediate response and 5G low-latency and highly reliable communications can expand the precision of response teams. The 5G mission-critical services provide a location-based mechanism for triggering/canceling an emergency alert upon entering/leaving a predefined area [11].

Strong security is one of the essential requirements for critical communication applications. Railway digitalization introduces threats to security, reliability, and costs. Connected users, train control systems, signaling systems, and trackside infrastructure are all potentially at risk. The control systems are built on open platforms, where train control can be accessed remotely via public networks and, consequently, they are vulnerable to cyber-attacks. MC railway communications can be the object of attacks such as denial-of-service or man-in-the middle attacks or snuffing. An advanced cybersecurity solution for railway systems should include constant monitoring, provisioning of full visibility, and prompt addressing of potential threats. A systematic review of cybersecurity challenges and approaches to railway infrastructure is provided in [15]. Key operational metrics to evaluate cybersecurity in critical railway infrastructure are identified and evaluated through simulations in [16]. In [17], the authors propose an approach for combined security and safety risk assessment in railway systems. Based on specific security requirements, a security framework tailored to the needs of railways is proposed in [18]. In [19], a multilayered approach to encrypting audio signals in secure voice communications is presented.

According to [1], critical communication applications in railways require authorization for both the application and the communication. The aim of communication authorization is to avoid communication disruptions, maintain communication privacy, and reduce the network load. It is based on the communication context, user’s functional identity, time frame, location, network identifier, and other context-based criteria. Application authorization requires the railway operator to configure the communication rules to control access to the application.

It is envisaged that FRMCS applications will embrace 5G capabilities by using a radio access network, core network functionality, MC services, and railway-specific support services. FRMCS applications can be deployed on the cloud, whether centralized or distributed at the network edge by utilizing Multi-access Edge Computing (MEC) technology. The deployment of MEC for the control of multi-train communications is studied in [20]. A MEC-based computational model for user traffic offloading for high-speed railways that considers the impact of handovers is proposed in [21]. By applying the principles of Software-Defined Networking (SDN) and Network Function Virtualization (NFV), FRMCS critical communication and performance applications may run as virtual machines on the same virtualized platform as virtualized core network functions and support-type FRMCS applications. The application of SDN and NFV principles in railways networks is discussed in [22], where the authors propose an improved SDN failure recovery mechanism and describe service orchestration systems that can be deployed in the railway track infrastructure. A framework that applies the Software-Defined Networking principles tailored to railway communications is proposed in [23].

Table 1. Summary of related work.

Subjects	Aspects	References
	Specifications	[1,2,3]
	Operational rules	[24,25,26,27]
FRMCS	5G New Radio	[4,5,6,7,8,9,10]
	Cloudification	[20,21,22,23]
	Cybersecurity	[16,17,18,19]
	5G Mission critical services	[11,12,13,14,15]
Services and applications	Service components	[28,29,30,31,32,33]
	Mathematical formalisms	[34,35,36,37]

summarizes the related work organized by subject and related aspects.

Current research has a service-oriented approach to the design of FRMCS critical voice communication applications. Service-Oriented Architecture (SOA) is a widely adopted architectural principle that is centered around services. A comprehensive analysis of business processes in SOA is provided in [34].

In the proposed approach, the FRMCS critical support applications are designed as services that may be reused in different FRMCS critical voice communication applications. The service design is based on the Representational State Transfer (REST) architectural style. REST Application Programming Interfaces (APIs) are lightweight, relying on Hypertext Transfer Protocol (HTTP); technology-independent; scalable; and flexible due to the client–server separation.

The novelty of the current research can be summarized as follows:

• Based on the specified FRMCS user requirements, security-related functions that are not explicitly specified but are used in different FMCS applications are identified and synthesized as reusable microservices.
• Common features, such as role management, presence, location, invite-a-user messaging, assured voice communications, and multiuser talker control, are also designed as services. RESTful APIs are defined, and the use of designed services is illustrated through message flows.
• The feasibility of services is illustrated by modeling the communication state from both the application and FRMCS points of view and the models are formally verified.
• The API performance is evaluated in terms of the injected latency.

3. Reusable Functionality Related to Security Services

3.1. Management of FRMCS User and Application Data

According to [3], FRMCS applications require an enhanced level of security. FRMCS security covers functionality to protect services and security functions, including identification and authentication, authorization, key management, and secure data transmission. The implementation aspects of the encryption mechanisms based on identifiers, credentials, cryptographic keys, and encryption algorithms have been standardized to a very limited extent in 5G.

The logic of FRMCS applications, including security functions, is based on the functional identity, which defines the user’s functional role on a specific train, engine, station, or control center. An FRMCS user may be a human or a device. The user’s functional identity describes the user’s role in communications as a calling or called party. It is used to route the call based on function or identity, rather than user subscription. In addition to humans, some FRMCS devices such as public announcement machines also have functional identities that reference where the device is used.

The following functional roles are defined [1]. The network operator has the responsibility for the proper operation of the FRMCS network. A controller is a person who coordinates all train-related operations, such as supervising, monitoring, analyzing, as well as controlling train movements. Different functional identities are defined for the controllers, e.g., infrastructure manager controller, railway undertaking controller, power supply controller, and signaler, among others. An entitled controller is a controller responsible for safe train movements within a defined geographic area. A train driver is a person who is authorized to drive different types of trains, including route locomotives, shunting locomotives, work trains, passenger trains, freight trains, and others, in a safe, responsible, and autonomous manner. Train staff are onboard the train and they are not train drivers, e.g., security staff, conductors, catering staff, and so on. A group of people who safely move the trains between platforms and yards is called a shunting team. Trackside staff include workers who are shunting and/or maintenance workers. A ground user is not on the train but can access the network via a stationary or wireless connection. A public emergency operator is responsible for answering emergency calls from the public. Personal staff other than train drivers, train staff, trackside staff, or controllers who are employed by the railways are regarded as railway staff.

In order to use FRMCS applications, the user needs to be registered in the system with one or more functional identities. User credentials are stored as a part of the user profile. The FRMCS role management and presence application allows for user login/logout, functional identity registration/deregistration, and the submission of identities.

The use of FRMCS applications, as well as access to voice and data communications, are configurable. Access to applications and communications is based on the user’s identity. The network operator defines FRMCS applications that could be used by a given functional identity. Only authorized applications are presented to the FRMCS user depending on his/her user profile, registered identity(ies), and the context. A network operator authorizes the communication in order to avoid disruptions or interruptions to users (e.g., drivers during train movement). The permission or denial of voice and data communications is also based on functional identities related to the user, user identity, equipment functional identities, and subscriber identity.

Multiuser talker control is an FRMCS application for multiparty voice communications that restricts the number of simultaneous talkers based on the identities and applications of the involved users. The number of simultaneous talkers, initial talker permissions, and priorities are configurable as part of the application data.

Arbitration between simultaneous communications competing for the same user’s attention is another FRMCS application that relies on data configured to the application.

According to [3], it is the FRMCS Service Server that stores the user profile application data and performs service-level registration and deregistration, whereas the FRMCS Mobile Gateway is responsible for the authorization of applications, which is represented through the FRMCS Mobile Application Client.

To unify the access to FRMCS data from different applications, the functionality of FRMCS data management can be synthesized as RESTful microservices. The microservices’ design principles are described in Section 4.

3.2. Policy-Based Railway Communications

To ensure reliable, safe, secure, and deterministic services under all conditions, even in cases of malfunctions related to infrastructure or train delays and cancelations, railway operations must follow certain rules [24]. Among others, the operational rules include the provisioning of information about train movements (e.g., the active tracking of train movements and the reporting of the location coordination, capacity restrictions, etc.) and the traceability of information and decisions (e.g., traffic control, corridor coordination, movement priority between trains, traffic diversion, and others). The control of infrastructure facilities on the railway network follows the rules established for their use. There are also rules for maintaining network availability, e.g., rules governing the troubleshooting of trains and rules to restore the infrastructure in the case of a train derailment or breakdown or urgent trackside repairs. The management of downgraded and emergency situations is also subject to rules, which aim to restore normal operation as quickly as possible, as well as alert and continuously inform responders. An approach to designing operational rules for a railway interlocking system is proposed in [25]. A methodology for the verification of the interlocking system according to international signaling rules is presented in [26]. The authors of [27] present a method for the optimization of operational rules for heavy-haul trains.

The use of FRMCS critical communication and performance applications is also based on rules. In the case of simultaneous connections that compete for user attention, an arbitration function is needed. Multiuser talker control functionality is required for multiparty voice communications to mitigate the risk of miscommunications, e.g., for emergency communications, shunting communications, banking communications, and communications between trackside workers. Functions for arbitration between competing communications and multiuser talker control are defined as a key component of critical railway applications [1].

The functions for application authorization, communication authorization, arbitration, and multiuser talker control are based on predefined policies. The policies outline the operational criteria and are configured by the railway operator. In order to manage (create/update/retrieve/delete) the policy information, control access to it, and request a policy evaluation, a policy service is needed.

The proposed policy API is described in the next section.

4. FRMCS Common Functions as RESTful Service Blocks

Any physical or logical object in REST is represented as a resource that is regarded as a service building block. Each REST resource is uniquely identified and addressable by its Uniform Resource Identifier (URI). Resource manipulation is achieved through its representations (data, metadata, and hypermedia links), which allows for the modification of the resource state. Resource state manipulation is typically based on HTTP GET/POST/PUT/DELETE methods.

4.1. Policy API

The policy service supports two types of APIs: provisioning and evaluation. The service allows the railway operator to manage the policy information, i.e., to create, update, or delete policy domains and rules, as well as control access to it. The policy service also allows other policy-based FRMCS applications and services to request an evaluation of policies. The policy service contains the logical views of the policy engine and rule database. The policy API’s definitions conform to the Policy Core Information Model [38] and Policy Core Information Model’s (PIMC) extension [39].

The policy service’s API facilitates the interaction between the clients and the policy-enabled applications such as application authorization, communication authorization, arbitration, and multiuser talker control.

Following the REST principles, two types of resources are defined for the policy service, namely resources representing the rules of the different policy domains and resources representing the requests for policy evaluations. The FRMCS policy rules are grouped into policy domains. Four policy domains are defined; however, the operator can other domains. The application authorization domain contains rules that are used to authorize FRMCS application usage (e.g., rules based on the user’s identity, user’s functional identity, subscriber identity, selected underlying network, time frame, and other context-related data). The communication authorization domain contains rules that are used to permit or deny communication, which are primarily based on the user’s functional identities and location. The arbitration domain contains rules used to perform arbitration between communications competing for the same user’s attention and these rules are based on the type of application, type of device, and functional identities. The talker control domain contains rules that are used in multiparty voice calls to grant permission to talk.

The structure of the URIs of the policy service resources is shown in Figure 1.

The policyDomains resource represents the defined railway policy domains. The GET method applied to this resource retrieves the list of policy domains and the POST method creates a new policy domain.

The appAuthorizationDomain resource, commAuthorizationDomain resource, arbitrationDomain resource, and talkerControlDomain resource represent the defined policy domains for application authorization, communication authorization, arbitration, and multiuser talker control, respectively. Each resource that represents a policy domain contains rules for the specific railway domain and supports the GET method, which retrieves the list of rules from the domain, and the POST method, which is used to create a new rule in the respective domain. The resources that represent the policy domains are the containers for the individual rules of the given domain.

The {appAuthorizationRuleID} resource, {commAuthorizationRuleID} resource, {arbitrationRuleID} resource, and {talkerControlRuleID} resource represent the individual rules in the respective policy domain. The GET method applied to the resource representing an individual policy rule retrieves information on the specific rule, the PUT method updates information about the rule, and the HTTP DELETE method deletes the rule.

The resources that represent requests for policy evaluations are grouped according to the policy domain. The policyEvaluationRequests resource represents a container for all requests for policy evaluations, which are further subdivided into four groups. This resource supports the HTTP GET method, which retrieves the list of groups of policy evaluation requests.

The appAuthPolicyEvalRequests resource is a container for all policy evaluation requests for application authorization. The commAuthPolicyEvalRequests resource is a container for all policy evaluation requests for communication authorization. The arbitrationPolicyEvalRequests resource contains all policy evaluation requests for arbitration and the talkerControlPolicyEvalRequests resource contains all policy evaluation requests for multiuser talker control. These resources support the HTTP GET method, which retrieves the list of all policy evaluation requests for the respective group, and the HTTP POST method, which creates a resource representing the policy evaluation requests of the respective group.

The {appAuthPolicyEvalRequestID} resource, {commAuthPolicyEvalRequestID} resource, {arbitrationPolicyEvalRequestID} resource, and {talkerControlPolicyEvalRequestID} resource represent the individual policy evaluation requests of the respective group. These resources support the GET, PUT, and DELETE methods, which retrieve/update/delete information about a specific request. The subscription resources represent subscriptions for notifications about policy evaluation requests.

The data model defines the data structures used in the resource representations. Each rule is represented by “If Condition then Action” semantics associated with a policy. The rule condition may be represented either by sub-conditions in the Disjunctive Normal Form (DNF) or the Conjunctive Normal Form (CNF). In the DNF, the rule condition is an ORed set of ANDed conditions, whereas in the CNF, it is an ANDed set of ORed conditions. Each condition can be negated or unnegated. The actions specified in the policy rule are to be executed only if the rule condition is evaluated as true.

4.2. FRMCS Data Management API

FRMCS data management can be designed as three microservices of the FRMCS applications, namely:

• the Functional Identity Profile Management (FIPM) service;
• the User Profile Management (UPM) service;
• the Application Data Management (ADM) service.

The functional identity profile defines the responsibilities of the functional identity, its priority, and the applications that can be used. The FIPM service allows the network operator to configure and modify data for different FRMCS functional entities. The service clients can retrieve information about the profiles of the functional identities. It is also used by the service client to subscribe to notifications about functional entity data changes, modify the subscription, or unsubscribe from notifications about functional entity data changes. In the case of an active subscription, the FIPM service sends a notification based on the subscribed data modification.

Figure 2 depicts the structure of the URIs of the FIPM service resources.

The FIProfiles resource is a container for the functional identity profiles. It supports the GET method, which retrieves the list of functional identity profiles. An individual functional identity profile is represented by the {FIPprofileID} resource and the GET method retrieves information about the specific functional identity.

The FIProfileSubscriptions resource represents subscriptions to notifications about changes to the functional identity profiles. The POST method is used to create a new subscription and the GET method is used to retrieve the list of active subscriptions. The {FIProfileSubscriptionID} resource represents an individual subscription to notifications about changes to the functional identity profiles and it supports the GET/PUT/DELETE methods to retrieve/modify/delete information about existing subscriptions.

The user profile contains the user credentials used for user authentication and the assigned functional identity(ies) that can be registered by the user. The UPM service is used by the FRMCS applications to retrieve the user profile data. The service allows for subscriptions to notifications about changes to the user profiles. Figure 3 depicts the structure of the URIs of the UPM service resources.

The UserProfiles resource is a container for resources representing the user profiles. It supports the HTTP GET method, which is used to retrieve the list of user profiles. The {UserProfileID} resource represents an individual user profile and supports the HTTP GET method to retrieve information about the user profile. The subscription-related resources define the subscriptions to notifications about changes to user data profiles.

The application profile contains application-specific data. The ADM service is used by FRMCS applications to retrieve information about configured application data. Subscriptions to notifications about application data changes are also supported. Figure 4 depicts the structure of the URIs of the ADM service resources.

The AppProfiles resource is a container for resources and represents the application profiles. The GET method is used to retrieve the list of application profiles. The {AppProfileID} resource represents an individual application profile. Information about an existing application profile can be retrieved using the GET method. The AppProfileSubscriptions resource and {AppProfileSubscriptionID} resource represent all subscriptions and an individual subscription to notifications about changes to application profiles, respectively. Using the HTTP method, the list of existing subscriptions can be retrieved; a subscription can be created, modified, or deleted; and information about an existing subscription can be retrieved.

4.3. FRMCS Critical Support Application API

FRMCS critical voice communication applications use the following critical support applications [1]:

• Role management and presence;
• Invite-a-user messaging;
• Location services;
• Authorization of application;
• Authorization of communication;
• Arbitration;
• Quality of Service (QoS) class negotiation;
• Assured voice communication;
• Multiuser talker control.

Some of the critical support applications, such as application authorization, communication authorization, and arbitration, can use the API of the role management and presence application to retrieve the registered identities, the FIPM API and UPM API to access the identity profiles, and the policy API to evaluate the respective policy rules.

Other critical support applications, such as role management and presence, invite-a-user messaging, multiuser talker control, assured voice communication, and QoS class negotiation applications, need to use a client part on the FRMCS device and a server part on the FRMCS server.

The role management and presence functionality is used to register/deregister one or more users’ functional identity(ies) and their presence statuses. Figure 5 shows the structure of the resource URIs related to the role management and presence service, where the presence status describes the context in which the functional identity is presented. More details on the role management and presence service can be found in [28].

Each user device (ueID) is uniquely identified. Some user devices have a functional number/identity (ueFNID) that indicates where the device is used. To be reachable, each user has to register their unique functional number (userID) and one or more functional identities (userFID). The registration and presence status are attributes of the resources and represent individual identities. The subscription resources represent existing subscriptions to notifications about changes to the registration or presence status of the respective identity. The registered identifications and current presence information allow/disallow the use of critical communication applications.

User devices can provide periodic location information to the location service. The user’s location can be delivered to other applications such as critical communication applications. Location information may also be provided by external systems such as interlocking systems, balises, automatic train control, and others. The MEC location service can be used to provide location-related information to FRMCS applications [29]. The railway operator can define specific zones to actively track the FRMCS user’s location. The MEC location service can support location information about specific FRMCS devices currently served by the radio nodes associated with the FRMCS server, location information about all registered FRMCS users, a list of FRMCS registered devices in a particular railway area, and information about devices entering or leaving a particular area. The location information is used by critical communication applications upon communication establishment and routing.

The use of critical communication applications has to be authorized. Upon the successful registration of an FRMCS user and their functional identity(ies), the role management and presence application retrieves the respective functional identity profile(s) and initiates the applicable FRMCS application(s). The authorization of an application can be based on policies, e.g., the time frame, the location of the FRMCS device, and other context-based criteria. Hence, the application authorization application may use the location service to retrieve the device location, the role management and presence service to retrieve the registered presence status, and the policy service to evaluate the application authorization rules.

Communication authorization is required to prevent unauthorized communications and avoid user distractions or disruptions. The communication authorization application can use the role management and presence API to retrieve the registered identities of the call parties and FIPM and UPM services to access the respective profiles. Based on this information, the communication authorization application can request the policy service to evaluate the respective rules and decide whether or not to allow the establishment of communication.

The arbitration function determines the behavior of the FRMCS in the case of multiple communications competing for the user’s attention. Based on the arbitration rules, the system determines whether to automatically establish a new outgoing call, put the established one(s) on hold, or reject the new call. For incoming calls, the arbitration rules postulate whether the system should automatically enable or disable the presentation of ongoing calls and hold calls for which the presentation is disabled, or present an option to the user to hold, merge, leave, reconnect, or terminate the ongoing call. The arbitration application can use the policy service to perform the arbitration based on the defined arbitration rules and registered identities.

The 5G telecom operator may configure railway-specific network slices to meet the diverse FRMCS application requirements for low latency, enhanced coverage, and high capacity. Radio Access Network slices configure the QCI, ACB, and ARP [30]. Dedicated core networks allow multiple core network segments to share the same physical network, enabling the differentiation of railway services. However, in extreme situations, it may be necessary to negotiate the QoS parameters, e.g., in the case of train derailments or if users need higher-resolution video streams or higher bandwidth. The QoS class negotiation function allows the assignment of specific QoS classes to communications applications, e.g., the prioritization of critical communications and pre-emption of already assigned network resources if required.

The URI structure of resources related to the QoS class negotiation function is shown in Figure 6.

The resource qosClassAllocations is used to represent a list of the application’s QoS class allocations. The HTTP GET method retrieves information about the list of an individual application’s QoS class allocations and the HTTP POST method is used to request the registration of a QoS class allocation with the QoS class negotiation service. The {qosClassAllocationID} resource is used to represent a QoS class allocation instance. The HTTP GET method retrieves information about the resource, the PUT method updates information about the resource, and the DELETE method is used to unregister from the QoS class negotiation service.

More details about the QoS class negotiation service can be found in [31].

In railway operations such as shunting and banking, the interruption or disruption of voice communication can put users at risk. For these types of communications, the system must monitor the QoS of the communication link and indicate when the link is broken or degraded. Figure 7 shows the URI structure of resources related to assured voice communications.

To activate the assured voice communication function, the critical application creates a new resource that represents the assured voice communication (assuredVoiceCommunicationID) by applying the POST method on the resource that represents all assured voice communications (assuredVoiceCommunications). The critical application subscribes to notifications related to link quality. In the case of QoS disruptions, the assured voice communication service notifies the application, which activates link monitoring.

More details about the assured voice communication service can be found in [32].

The invite-a-user messaging application allows an authorized user to invite another user(s) to join the ongoing voice call. A user of this application can be any FRMCS user involved in a call. The feature is required when users with ongoing voice communication, e.g., shunting team members, need to join another user, e.g., a controller. Upon application triggering, the FRMCS system automatically routes the invitation to the desired user(s). The status of the invitation (e.g., pending, rejected) is presented to the inviting user. The invitation is presented to the receiving user(s), along with the inviting user’s functional identity, location, and description of the incoming call. A user receiving the invitation who is not involved in another call can accept the invitation and join the ongoing call, and in this case, all users involved are notified about the new call participant(s). A user receiving an invitation who is already involved in another call has the choice to leave or terminate the current call and connect to the incoming call related to the invitation or merge the two calls. A user can reject or ignore the invitation and the inviting user is notified. An FRMCS user involved in a call can use the Invite-a-user messaging (IUM) service to invite another FRMCS user to join the ongoing call.

Figure 8 depicts the structure of the resource URIs of the IUM service.

Table 2. IUM service resources and methods.

Resource Name	Resource URI	HTTP Methods	Description
All invitations to join a call	/invitationsToJoin	GET POST	Retrieves the list of all invitations to users to join an ongoing call. Creates a new invitation to join a call
Individual invitation to join a call	/invitationsToJoin/invitationToJoinID	GET	Retrieves information about a specific invitation
A list of subscriptions to notifications about the invitation status	/invitationSubscriptions	GET POST	Retrieves the list of active subscriptions to notifications about the invitation status Creates a new subscription
Individual subscription to notifications about the invitation status	/invitationSubscriptions/invitationSubscriptionID	GET PUT DELETE	Retrieves information about a specific subscriptionUpdates information about a specific subscription Deletes the existing subscription

provides an overview of the defined resources supported by the IUM service and the applicable HTTP methods.

The service clients communicate with the IUM service over the service API to invite users to join an existing ongoing call and receive information about the invitation status. The IUM API supports both invitation requests and subscriptions.

Another feature of critical voice communications is multiuser talker control. This function allows for the control and restriction of simultaneous talkers’ numbers, the configuration of the initial prioritization and permission to talk, the ability to request permission to talk, and the granting/revoking of permission to talk by an entitled call participant. The functionality of multiuser talker control can also be synthesized as a Multiuser Talker Control (MUTC) service.

Figure 9 shows the overall communications between entities involved in multiuser voice communication for three use cases. The first use case is related to the change in the number of simultaneous talkers, where the MUTC service can revoke the permission to talk in case the number of active talkers is higher than the allowed number. The second use case illustrates an automatic permission decision made by the MUTC service. In the third use case, the entitled call participant makes the decision about the permission to talk.

Figure 10 shows the URI structure of resources related to multiuser talker control.

The resources represent calls with active multiuser talker control and subscriptions for notifications about requests to talk and the need to select talkers.

More information about the MUTC service can be found in [33].

The support applications designed as RESTful services can be used as service bricks that constitute the logic of critical communication applications. Section 3 presents some use cases that illustrate the use of defined services in critical voice communication applications.

5. Use Cases of Critical Voice Communication Applications

The train driver switches on his/her handheld device. The device attaches to the FRMCS network at the telecommunication level and is reachable based on its subscriber identity. All the applications included in the subscriber profile initialize and are ready to be used. The train driver’s handheld device logs into the FRMCS on the application level. The use of handheld devices requires the registration of the user’s login and functional identity(ies). The train driver initiates a login dialogue that confirms their credentials. After the successful registration of the train driver, they are identified by the FRMCS and their device is reachable through the user identity and device subscriber address. The train driver registers one or more of their functional identities and, thereafter, their device is accessible through their functional identity(ies). The identity registration is carried out by applying the HTTP PUT method to the respective resource related to the role management and presence function. Assuming that it is a normal situation, e.g., the network is not congested, all applications associated with the registered functional identity(ies) are authorized to be used.

The train is on its journey. The train driver’s device periodically reports its location and its location information can also be provided to external systems.

Figure 11 illustrates the services interaction flow for the initial registration of the device and user.

A fire suddenly breaks out on a train. The train driver stops the train and uses a critical voice application to initiate a call to the controller responsible for the traffic in the respective geographical area. The communication authorization application retrieves the call party locations and requests an authorization decision from the policy service, which provides the calling party’s functional identities and locations. The call is established and the QoS resources are assigned according to the configured application requirements. The connection between the train driver and the train controller is established. Due to the critical nature of the established connection, the assured voice communication application is activated. The application requests connectivity monitoring from the assured voice communication service and subscribes to notifications related to link-quality disruptions. During the communication, the assured voice communication service periodically sends notifications if the link quality is intact or notifies the application about link-quality degradation using the address provided by the application in the subscription request.

Figure 12 shows the procedures for communication authorization and assurance.

A passenger evacuation begins and the fire brigade arrives in order to extinguish the fire. Calls are established between some of the firemen and the controller responsible for the train on fire and the establishment of each call is accompanied by an application and communication authorization. The MUTC application is activated and a controller in the role of an entitled call participant makes a decision about permission to talk. To use the multiuser talker control function, the MUTC application submits a request to the multiuser talker control and subscribes to MUTC service notifications about the request to talk and the need to select users to talk. The MUTC service retrieves the application data from the ADM service. A request to talk is indicated by a call participant to the MUTC application and the MUTC service is notified. The MUTC service submits a request to the policy service to decide how to proceed. The policy service can grant/revoke/reject the permission to talk if the number of simultaneous talkers is not maximal or delegate the talker selection to the controller as the entitled call participant. The MUTC application is notified about the decision and indicates the outcome of the request to the associated call parties about the grant/rejection to talk.

Each of the simultaneous calls has requirements for high bandwidth and the resources available for the slice dedicated to emergencies may be insufficient. The controller decides to focus on one of the video calls and the controller’s critical communication application activates the QoS class negotiation application. The QoS class negotiation application retrieves the user profile from the UPM service and requests a dynamic upgrade of the QoS class of the respective video call from the QoS negotiation service by providing information about the video call’s prioritization and other relevant information. The QoS class negotiation application subscribes to notifications related to the updated QoS class and receives notifications about such events.

Figure 13 illustrates the flow of multiuser talker control and dynamic QoS class negotiation.

During the call, a railway staff member who is not at the location of the fire makes a call to the same controller. The railway staff member is presented with their functional identity. The arbitration application is activated to retrieve the location and functional identity profile of the railway staff member from the location service and the FIPM service, as well as the arbitration requests between competing communications from the policy service, providing information about the functional identities of the controller and the railway staff member. The policy service decides to automatically reject the call for the railway staff member. The controller needs to receive more information from the train conductor and sends a message to the conductor to join the ongoing call. The IUM application is activated. The communication is authorized based on the controller’s and train conductor’s functional identities, as well as the conductor’s location. The arbitration application allows the outgoing competing communication also based on a predefined policy.

Figure 14 illustrates the arbitration between competing communications and invite-a-user messaging.

6. Verification of the Critical Voice Application Design

To verify the application design, models illustrating the views of the critical communication application and the network on the state of the voice call are synthesized.

Figure 15 shows the state model of the originating leg supported by the critical application.

In the null state, there is no call attempt. In the CommAuthorization state, the FRMCS network checks the authority/ability of the party to place a voice call to the called party with the given properties, e.g., based on the calling and called parties’ functional identity user profiles and locations. In the active state, the call leg connection to the calling party exists. It is a composite state that encompasses the setup, established, assured, arbitration, and QoSClassNegotiation substates. In the setup substate, the call leg connection to the called party is built. In the established substate, the call is established. In the assured state, link-quality supervision is activated. In the QoSClassNegotiation substate, the application waits for a response to its request to dynamically set the QCI of the ongoing connection. In the arbitration substate, there is a new incoming call and the application waits for the decision from the FRMCS about the further treatment of the new incoming call. In the release state, the call is released but information about the call can be received for some time afterward and the resource representing the assured voice call is later deleted.

Figure 16 shows the originating leg state model supported by the network. In the Null&AuthorizedCallAttempt state, there is no call, the calling party’s right to make a call is checked, and the destination number is received. In the analyzing state, the collected information is analyzed and/or translated and the routing address and call type are determined. In the CallRouting state, the routing address and call type are interpreted, a path is selected, and the call is routed. In the ringing state, the call processing continues for the called party and an indication is expected that the called party has answered. In the connected state, the connection between the calling party and the called party is established and call data are collected. In the releasing state, the resources assigned to the call are released.

Both models must run as parallel processes and their communication must be synchronized so that the processes exhibit equivalent behavior. Bisimilarity is a well-established and powerful proof technique that is usually referred to as a behavioral equivalence for processes. It is defined as the union of all bisimulation relations on terms as pairs [35]. The most common notation used to study bisimilarity is the Labelled Transition System (LTS), which is essentially a labeled directed graph.

To verify the models representing the critical application and network views on the call state, both models are formally described as LTSs. An LTS is a quadruple consisting of a set of states, a set of inputs, a set of transitions, and an initial state [36]. In the following definitions, the notations in brackets represent short notations for the names of states and inputs.

Definition 1.

Let L^app = (S^app, I^app, T^app, s₀^app) denote a Labeled Transition System that formally describes the critical application’s view on the call state, where:

S^app = {Null [s₁^a], CommAuthorization [s₂^a], Active.Setup [s₃^a], Active.Established [s₄^a], Active.Assured [s₅^a], Active.QoSClassNegotiation [s₆^a], Active.Arbitration [s₇^a], Released [s₈^a]},

I^app = {CallAttempt [i₁^a], AuthorizedComm [i₂^a], UnauthorizedComm [i₃^a], Abandon [i₄^a], NoAnswer [i₅^a], Busy [i₆^a], Answer [i₇^a], AssuredCommRes [i₈^a], SubscriptionRes [i₉^a], TimerQosExpiry [i₁₀^a], SetQoS [i₁₁^a], QoSCalssRes [i₁₂^a], CallWaiting [i₁₃^a], ArbitrationRes [i₁₄^a], NotifyLinkQuality [i₁₅^a], CallEnded [i₁₆^a], Disconnect [i₁₇^a], TimerRelExpiry [i₁₈^a]},

T^app = {(s₁^a i₁^a s₂^a), (s₂^a i₂^a s₃^a), (s₁^a i₃^a s₁^a), (s₃^a i₄^a s₁^a), (s₃^a i₅^a s₁^a), (s₃^a i₆^a s₁^a), (s₃^a i₇^a s₄^a), (s₄^a i₈^a s₅^a), (s₅^a i₉^a s₅^a), (s₅^a i₁₀^a s₅^a), (s₅^a i₁₁^a s₆^a), (s₆^a i₁₂^a s₅^a), (s₅^a i₁₃ s₇^a), (s₇^a i₁₄^a s₅^a), (s₅^a i₁₅^a s₈^a), (s₅^a i₁₆^a s₈^a), (s₅^a i₁₇^a s₈^a), (s₈^a i₁₈^a s₁^a)},

s₀^app = Null [s₁^a].

Definition 2.

Let L^net = (S^net, I^net, T^net, s₀^net) denote a Labelled Transition System that formally describes the FRMCS view on the state of the originating call leg, where:

S^net = {Null&AuthorizedCallAttempt [s₁ⁿ], Analyzing [s₂ⁿ], CallRouting [s₃ⁿ], Ringing [s₄ⁿ], Connected [s₅ⁿ], Releasing [s₆ⁿ]};

I^net = {CollectedInfo [i₁ⁿ], AddressAnalyzed [i₂ⁿ], InvalidInfo [i₃ⁿ], Busy [i₄ⁿ], Abandon [i₅ⁿ], CallRouted [i₆ⁿ], NoAnswer [i₇ⁿ], Answer [i₈ⁿ], AssuredCommReq [i₉ⁿ], SubscriptionReq [i₁₀ⁿ], IncomingCall [i₁₁ⁿ], AcceptCall [i₁₂ⁿ], RejectCall [i₁₃ⁿ], QoSCallReq [i₁₄ⁿ], QCIRes [i₁₅ⁿ], QoSEvent [i₁₆ⁿ], Disconnect [i₁₇ⁿ], Release [i₁₈ⁿ], Released [i₁₉ⁿ]};

T^net = {(s₁ⁿ i₁ⁿ s₂ⁿ), (s₂ⁿ i₂ⁿ s₃ⁿ), (s₂ⁿ i₃ⁿ s₁ⁿ), (s₃ⁿ i₄ⁿ s₁ⁿ), (s₃ⁿ i₅ⁿ s₁ⁿ), (s₃ⁿ i₆ⁿ s₄ⁿ), (s₄ⁿ i₇ⁿ s₁ⁿ), (s₄ⁿ i₅ⁿ s₁ⁿ), (s₄ⁿ i₈ⁿ s₅ⁿ), (s₅ⁿ i₉ⁿ s₅ⁿ), (s₅ⁿ i₁₀ⁿ s₅ⁿ), (s₅ⁿ i₁₁ⁿ s₅ⁿ), (s₅ⁿ i₁₂ⁿ s₅ⁿ), (s₅ⁿ i₁₃ⁿ s₅ⁿ), (s₅ⁿ i₁₄ⁿ s₅ⁿ), (s₅ⁿ i₁₅ⁿ s₅ⁿ), (s₅ⁿ i₁₆ⁿ s₅ⁿ), (s₅ⁿ i₁₇ⁿ s₆ⁿ), (s₅ⁿ i₁₈ⁿ s₆ⁿ), (s₆ⁿ i₁₉ⁿ s₁ⁿ)};

s₀^net = Null&AuthorizedCallAttempt [s₁ⁿ].

The synchronized behavior of concurrent processes can be proven using the concept of weak bisimulation [37]. The existence of bisimulation, which denotes equivalent behavior, is proved by identifying a binary relationship R ⊆ S^app × S^net between the states of the Labeled Transition Systems that describe the state models. Specifically, for each pair of states (s_i^a, s_jⁿ) in R, there must be corresponding transitions that terminate in another pair of states (s_k^a, s_mⁿ) in R. In weak bisimulation, internal transitions are treated as invisible moves.

Proposition .

L^app and L^net have a weak bisimulation relationship.

Proof. 

Let R = {(s₁^a, s₁ⁿ), (s₅^a, s₅ⁿ)}.

The following bijective function between the pair of states in R can be identified:

• Upon a call attempt, the critical application does not authorize the communication and the call is terminated: ∀ (s₁^a i₁^a s₂^a) ∧ (s₂^a i₃^a s₁^a) ∃ (s₁ⁿ i₁ⁿ s₂ⁿ) ∧ (s₂ⁿ i₃ⁿ s₁ⁿ).
• Upon a call attempt, the critical application authorizes the communication, the call is routed, and the calling party abandons the call: ∀ (s₁^a i₁^a s₂^a) ∧ (s₂^a i₂^a s₃^a) ∧ (s₃^a i₄^a s₁^a), ∃ (s₁ⁿ i₁ⁿ s₂ⁿ) ∧ (s₂ⁿ i₂ⁿ s₃ⁿ) ∧ (s₃ⁿ i₅ⁿ s₁ⁿ) ∨ (s₁ⁿ i₁ⁿ s₂ⁿ) ∧ (s₂ⁿ i₂ⁿ s₃ⁿ) ∧ (s₃ⁿ i₆ⁿ s₄ⁿ) ∧ (s₄ⁿ i₅ⁿ s₁ⁿ).
• Upon a call attempt, the critical application authorizes the communication, the call is routed, and the called party is busy: ∀ (s₁^a i₁^a s₂^a) ∧ (s₂^a i₂^a s₃^a) ∧ (s₃^a i₅^a s₁^a) ∃ (s₁ⁿ i₁ⁿ s₂ⁿ) ∧ (s₂ⁿ i₂ⁿ s₃ⁿ) ∧ (s₃ⁿ i₄ⁿ s₁ⁿ).
• Upon a call attempt, the critical application authorizes the communication, the call is routed, and the called party does not answer: ∀ (s₁^a i₁^a s₂^a) ∧ (s₂^a i₂^a s₃^a) ∧ (s₃^a i₆^a s₁^a) ∃ (s₁ⁿ i₁ⁿ s₂ⁿ) ∧ (s₂ⁿ i₂ⁿ s₃ⁿ) ∧ (s₃ⁿ i₆ⁿ s₄ⁿ) ∧ (s₄ⁿ i₇ⁿ s₁ⁿ).
• Upon a call attempt, the critical application authorizes the communication, the call is routed, and the called party answers, communication is assured, and the call participants are periodically informed that the link quality is intact: ∀ (s₁^a i₁^a s₂^a) ∧ (s₂^a i₂^a s₃^a) ∧ (s₃^a i₇^a s₄^a) ∧ (s₄^a i₈^a s₅^a) ∧ (s₅^a i₉^a s₅^a) ∧ (s₅^a i₁₀^a s₅^a) ∃ (s₁ⁿ i₁ⁿ s₂ⁿ) ∧ (s₂ⁿ i₂ⁿ s₃ⁿ) ∧ (s₃ⁿ i₆ⁿ s₄ⁿ) ∧ (s₄ⁿ i₈ⁿ s₅ⁿ) ∧ (s₅ⁿ i₉ⁿ s₅ⁿ) ∧ (s₅ⁿ i₁₀ⁿ s₅ⁿ).
• During the ongoing call, the calling party negotiates a new QoS class: ∀ (s₅^a i₁₁^a s₆^a), (s₆^a i₁₂^a s₅^a) ∃ (s₅ⁿ i₁₄ⁿ s₅ⁿ) ∧ (s₅ⁿ i₁₅ⁿ s₅ⁿ).
• During the ongoing call, the calling party initiates a new call and an arbitration takes place: ∀ (s₅^a i₁₃ s₇^a) ∧ (s₇^a i₁₄^a s₅^a) ∃ (s₅ⁿ i₁₁ⁿ s₅ⁿ) ∧s₅ⁿ i₁₂ⁿ s₅ⁿ) ∨ (s₅ⁿ i₁₁ⁿ s₅ⁿ) ∧ (s₅ⁿ i₁₃ⁿ s₅ⁿ).
• During the ongoing call, the link quality degrades and the calling party disconnects the call: ∀ (s₅^a i₁₅^a s₈^a) ∧ (s₈^a i₁₈^a s₁^a) ∃ (s₅ⁿ i₁₆ⁿ s₅ⁿ) ∧ (s₅ⁿ i₁₈ⁿ s₆ⁿ) ∧ (s₆ⁿ i₁₉ⁿ s₁ⁿ).
• The call is terminated by the calling or called party: ∀ (s₅^a i₁₇^a s₈^a) ∧ (s₈^a i₁₈^a s₁^a) ∨ (s₅^a i₁₆^a s₈^a) ∧ (s₈^a i₁₈^a s₁^a) ∃ (s₅ⁿ i₁₈ⁿ s₆ⁿ) ∧ (s₆ⁿ i₁₉ⁿ s₁ⁿ) ∨(s₅ⁿ i₁₇ⁿ s₆ⁿ) ∧ (s₆ⁿ i₁₉ⁿ s₁ⁿ).

Therefore, R is a bisimulation relationship and L^app and L^net exhibit equivalent behavior. Tt is proven that both models, which depict the state of voice communication in an FRMCS application and the network, are synchronized. □

7. Evaluation of API Latency

An experiment is set up to evaluate the latency injected by the RESTful API of the FRMCS support applications. The experiment setup includes the development of the client and server components. The client component, implemented in Java, consists of multi-thread clients that generate HTTP POST requests. These requests include an experimental header with the local client time in nanoseconds and a body containing JSON (JavaScript Object Notation) description of the request data. The server component consists of two Docker instances, one for the REST endpoint and the Cassandra client, and the other for the Cassandra server, providing a lightweight virtualized storage service. The server rewrites the experimental header in the response, allowing the client to measure the time elapsed between the request submission and the arrival of the response. The UML deployment diagram that illustrates the experimental setup is shown in Figure 17.

The generated traffic consists of 20,000 requests/responses. In Figure 18 and Figure 19, the fifth and seventeenth latency series are presented, each consisting of one thousand message couples. Since they are time series of latency values, it is relatively difficult to directly estimate the limits of the prevalent group of latency values. Therefore, probability density functions (PDF) may be helpful. These depict, in bins of sub-millisecond width, the probability of observing the respective latency values. The numerical results are presented in Figure 20 and Figure 21.

As can be observed in Figure 20 and Figure 21, the average injected latency is centered around 2 milliseconds. However, about four percent of the latency top values are well over two milliseconds. Moreover, using the NoSQL storage in a single node configuration, and eventually migrating to a cluster, provides a foundation for an increase in both the average and peak values. Consequently, latency as a key performance indicator remains a challenge.

8. Discussion and Limitations

One of this paper’s contributions is the identification of user data management and policy management functionalities as essential components of security-oriented user requirements. Rather than implementing these functionalities repeatedly in each FRMCS application, which would require evaluating predefined rules and accessing data specific to different users, functional identities, and applications, we extracted and synthesized these functionalities as microservices that can be used by other FRMCS services and applications.

Based on the user requirements specified in [1], FRMCS applications that are used by other FRMCS applications, namely role management and presence, location, invite-a-user messaging, assured voice communications, and multiuser talker control, are also defined as separate services and each one may run its process and manage its storage.

The proposed approach offers the main advantage of decoupling from existing proprietary solutions. It features the well-known advantages of service-based architecture such as scalability, fault isolation, technology agnostics, easy deployment, improved data security, and flexibility. The synthesized services are easy to virtualize and cloudify, allowing them to evolve, operate, and be deployed independently.

Along with the advantages, there are a few disadvantages that need to be considered. Deploying and running cloud services on virtualized infrastructure requires costs for security and maintenance support. Any changes to a service API will result in changes to applications that use the API. As each service has its own log files, troubleshooting may be a challenge. Finally, integrating services with different levels of internal complexity may also be difficult.

9. Conclusions

Critical voice communications in railways are required between train drivers, controllers, shunting teams, and other railway staff members. These types of communications must be authorized based on the user’s functional identity, context, and location and assured with a guaranteed quality of service. Arbitration needs to be applied for simultaneous communications competing for the same user’s attention. A user involved in a call should be able to invite another user to join the ongoing call. Multiuser communications also require talker control. These functions can be implemented as reusable service bricks, which can be configured with application-specific data.

This paper presents an approach to designing FRMCS critical voice communication applications that follows the principles of the REST architectural style. Common functionalities required by FRMCS applications, such as FRMCS data management and policy management, are identified and designed as services. Functions, such as role management and presence, assured voice communications, invite-a-user messaging, and multiuser talker control, are also designed as RESTful services. The relevant resources for each service are defined and their unique identifiers are organized in a tree structure. Use cases illustrate the use of the synthesized service APIs in critical voice applications. The common application logic is modeled using call-state models, which present the application and network views. The models are formally described and it is mathematically proven that they exhibit equivalent behavior. The service API’s performance is studied through emulation to evaluate the induced latency. The average latency is about 2 milliseconds, which is acceptable for mission-critical services.

The specification of the synthesized services requires data model definition, which takes the form of a REST API and defines the necessary information exchanged in communications. In future work, we plan to refine the data types and structures used in the APIs of the synthesized services.

The synthesized APIs are easy to implement as they rely on HTTP and provide a uniform interface. Because REST APIs are stateless at the server side, each request can be processed independently. Resource data can be represented in different formats but the use of the JSON format makes the data more compact. Additionally, REST decouples the client from the server, providing another level of flexibility.