Design · 3.10
Planning and demonstrating interworking
Time: about 11–14 minutes including the task; estimate
Guiding question: How can the claim “GSM-R and FRMCS work together” be bounded reliably?
Learning objective: You create an IWF function matrix with meaningful evidence levels.
Prerequisites: Previous lessons through 3.9, particularly the case file developed there.
The demonstration becomes a procurement question
In the trial from 2.20, Niko, Lea and Amir hear one another. Talbahn wants to use this to decide on mixed operation. It must know which functions were observed and which conditions the trial did not cover.
The IWF mediates the expressly intended functions between FRMCS and GSM-R. For assessment, these functions are considered individually. A shared “done” status would conceal, for example, that media transmission works while role mapping has not yet been demonstrated.
Four evidence states
For each function, Talbahn distinguishes:
- Requirement assigned: A specific expected requirement has been identified with its source and scope.
- Implementation documented: A named product version describes support.
- Tested in a named combination: A traceable result exists for particular devices, networks, configurations and scenarios.
- Accepted for the project: The responsible party accepts the evidence against agreed criteria and addresses remaining deviations.
The final state is a project decision. It does not follow automatically from a successful technical test. Similarly, a failed test may concern implementation without invalidating the requirement itself.
A deliberately incomplete example matrix
These entries are fictional learning states, not product assessments.
| Function | Requirement | Implementation | Test combination | Project acceptance |
|---|---|---|---|---|
| Speech in both directions | Assigned | Documented | Tested in the pilot | Accepted for pilot scope |
| Functional addressing | Assigned | Documented | Role-change test missing | Open |
| Group change | Assigned | Partial scope documented | Not tested | Open |
| Priority and emergency function | Assigned | Claimed, supporting evidence missing | Load case missing | Open |
| Callback after interruption | Still to be clarified | Open | Not testable | Open |
“Not testable” in the last row means the expected behaviour has not yet been defined clearly enough. It does not mean callback is technically impossible.
The matrix reveals why the voice trial does not yet support a prioritised mixed group call. Talbahn adds a priority-mapping test under load and clarifies the callback case. For the role change, it links the IWF row to an extension of TB-REQ-017; its original scope was limited to one FRMCS service domain.
Do not silently extend the boundaries
A test in one direction does not automatically substantiate the reverse direction. A combination of two suppliers does not substantiate a third implementation. A software update may also change mediation behaviour.
Talbahn therefore records versions, configurations, group types, permissions and failure conditions with the result. It deliberately distinguishes “not supported”, “not tested” and “test failed”. These statements lead to different actions.
Check your understanding
A supplier replaces “implementation documented” with “standardised” in the matrix and wants to omit the test. Explain your response and name a next step.
Model answer
A standardised function is not yet a documented implementation in the offered product. Even a documented implementation does not prove interaction with the other side. First I request the product version and supported scope, then the agreed test in the specific combination. The requirement and the missing evidence remain separately visible in the matrix.
What to remember
Standardisation, implementation, testing and acceptance answer different questions.
Your Talbahn case file
Continue the function matrix with four separate evidence states. Link every open function to a next decision or test.
Your progress is stored in this browser on this device.