Trackside Gateway and trackside integration

The data path needs trackside integration

The on-board application from 2.9 has a counterpart in the infrastructure. That counterpart should not need to implement radio-modem functions. The FRMCS Trackside Gateway provides trackside application integration. TSAPP names the corresponding application reference point. The gateway is neither automatically a dispatcher terminal nor the Radio Block Centre of an ETCS application. [S42, clauses 4–6]

First consider a loosely coupled data application. Its application process remains outside the communication function. The gateway side performs the associated MC service client procedures and connects API states to service states. A physical server may host several logical functions; interface responsibility does not change.

Registration, profile and session state

The trackside application registers with its integration. This creates an application context: a mapping between the registered application, its parameters and ongoing activities. A Railway Trackside Profile supplies the intended configuration relationships. Application registration does not automatically mean that service registration has fully succeeded.

For an outgoing session, the application supplies, among other information, the desired counterpart and communication category. The gateway uses the relevant mappings for the MCData request. For an incoming session, the local remote application is notified and can accept or reject the proposed establishment. Actual procedures depend on the selected edition and coupling type. [S42, clauses 6.2–6.3]

Open diagram at full size (SVG, new tab) G13

Check control and data forwarding together

For data, a successful session must be associated with the correct local application address. Routing determines the forwarding path; NAT performs the defined address translation. The gateway must therefore not be drawn merely as a “cable connection to the control centre”. It maintains states and mappings relevant to the complete path.

For example, Talbahn restarts the remote application. A surviving old context cannot simply be treated as new readiness. The integration must perform the intended registration, cleanup and notification procedures. Diagnosis therefore records old and new contexts and ongoing sessions separately.

Coupling makes a difference

With tight coupling, MCX client functions reside in the application. The loosely coupled data explanation cannot be transferred unchanged to every voice application. For driver and controller voice profiles, the course follows explicitly identified SRS rules. The next lesson develops the dispatcher example.

Check your understanding

After a restart, the application reports “registered”, but an incoming data session fails. Which boundaries do you investigate before replacing the radio module?

Model answer

Check application context and profile, service readiness, notification and acceptance of the incoming session, and mapping to the local data endpoint. TSAPP registration is not automatically complete MCData readiness. Transport observations are needed to justify a transport hypothesis.

What to remember

The Trackside Gateway connects application integration with communication states. Its responsibilities differ from those of a workstation, application and GSM-R interworking.

Your Talbahn case file

Draw application, TSAPP, gateway client functions and service platform for the loosely coupled data case. Mark control and data separately.