MCData: following a data session

From an application request to a data session

A Talbahn on-board application needs to transfer data to a trackside counterpart. We consider a loosely coupled connection: the application uses the FRMCS programming interface while FRMCS equipment performs MCData client procedures. A programming interface, or API, enables software calls with defined parameters and feedback.

MCData IP Connectivity, or IPCon, provides service-controlled IP communication in the profile considered. It is more than a reachable network connection: endpoints, permissions and session must match. A session here is the managed communication relationship between the intended partners. [S09, clause 6.2.2]

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

A complete teaching sequence

The application first registers with its local FRMCS integration. This associates the application with approved configuration and a service identity. Network and service readiness are prerequisites, not the result of the first user-data packet sent.

The application then requests a session with a named counterpart and a communication category. That category assigns the exchange to an intended treatment. Client and server functions process establishment. The correct remote application must be integrated and ready to accept. The gateway lesson explains that side in greater detail.

After successful establishment, the integration supplies the defined session and addressing information. The application now sends IP packets. The service uses the established data path; SIP signalling does not carry the entire application data stream. On termination, the session and associated mappings are cleaned up. On failure, the application needs appropriate feedback rather than a permanently misleading “connected” indication. [S09; S42]

Two addressing models

Host-to-Host (H2H) connects two endpoints. Host-to-Network (H2N) connects an endpoint to a data network. The choice describes the required communication relationship; it is not another term for radio access. In the H2H teaching case, the particular train and trackside instance must be identifiable. [S06, clause 6.5.2]

Address mappings can distinguish local application addresses from addresses used on the communication path. Network Address Translation (NAT) performs such address translation. A tunnel encapsulates packets for a defined transmission segment. A capture outside the tunnel may therefore show different addresses from a capture directly at the application. The case file records both views without inventing address values.

A successful session is not yet an application outcome

The remote application may receive data but reject it, for example because the message belongs to the wrong application session. Talbahn therefore checks establishment, data flow and application processing in sequence. The ETCS lesson applies this distinction to communication readiness versus valid train-protection information.

Check your understanding

The session request is accepted and packets are visible at the gateway, but the remote application does not process them. Which three mappings do you check?

Model answer

Check assignment to the correct remote application, session and address mapping, and the application-level association. Packets at the gateway prove neither delivery to the right process nor a valid application message.

What to remember

An MCData session links service states to a data path. Application readiness, service readiness and application success remain distinguishable.

Your Talbahn case file

Document registration, establishment, transfer and termination. Add an observation on both the application and service sides for each.