Interoperability is a journey, not a destination.
You probably heard this phrase many times, for sure in our posts. Sometimes we hear things, but the true meaning of words doesn’t necessarily register. So let’s say it again. Interoperability is a journey, not a destination. What does this mean?
Achieving interoperability is not a one-time event. Interoperability testing is an ongoing process – you can’t test once and say “I’m done. I’m interoperable”. Interoperability testing is a part of your ongoing product lifecycle – as long as you develop a product, you have to test it for interoperability.
Softil understands the value of interoperability testing firsthand. Ever since we built the first implementation of the open international standard for IP Communications about 30 years ago (it was ITU-T H.323, an original IP videoconferencing standard), we started participating in the interoperability testing – IMTC InterOps, IMS Forum plugfest, SIP Forum SipIt and so on. As an early adapter and developer of a solution for the 3GPP mission-critical communication standard, MCX, we continued our interoperability testing journey participating in the inaugural ETSI MCPTT Plugtest in 2017, and we have not missed a single plugtest since then.
Why is interoperability testing so important when it comes to open standards? There are two main considerations here.
First, as new products are developed, interoperability is not given. Even when you are sure you are following the standard, the implementation of the new feature might not be correct. Dedicated interoperability testing event, such as ETSI plugtest, offers a unique opportunity to test with many different implementations following the same standard, including by your competitors. The event becomes a sort of testing lab that would be either too costly or simply impossible to build on your own.
Second, the standard itself is not perfect. Interoperability testing allows to identify issues with the standard, whether bugs or features that are not defined correctly, too ambiguous, or impossible to implement. In such a case the input from the interoperability testing event becomes an essential element of making standards better, improving them.
It was interesting to get back to ETSI 7 years and 10 plugtests later :). This was the 4th FRMCS plugtest, so the primary focus of testing was a bit more narrow, covering mostly the railways-related features. Of course, all the MCX basics were still exercised as you can’t make a railway emergency call unless you are registered with an MCX server, obtained your configuration information, group information, security keys. However, Functional Alias, Multi-talker, ad-hoc group call, railway emergency call, IP Connectivity were the primary objects of the interoperability testing.
FRMCS (Future Railway Mobile Communication System) is an up-and-coming standard developed by UIC that is intended to replace the aging GSM-R communication technology used by railways today. 3GPP MCX over 5G is a cornerstone of the FRMCS, providing all basic communication capabilities with appropriate security, priority and preemption running over 5G networks. Starting with 3GPP release 15, railways-specific features, such as Functional Alias had been gradually added to the MCX specification to ensure that FRMCS railways communications will be on par with GSM-R capability upon initial deployment. Hence dedicated FRMCS testing at the MCX plugtest to ensure all required railway communication features are fully interoperable and will be ready for the prime time.
Softil’s team had a productive week of testing, being able to test many scenarios with the majority of the MCX servers participating in the event. We also participated in two observer demonstrations, showing two different types of ad-hoc group calls over the 5G network – location-triggered and criteria-triggered – together with Alea, Crosscall, Eviden, MCLabs, and Teltronic.
Interoperability is a journey. FRMCS Plugtest #4 is down, many more to go. Until the next plugtest…
