Good afternoon, everyone.
Welcome to my presentation. My name is Hare Ludwig.
I'm the chairman of the TCCA technical forum, and part of my work is,
uh, also to, to, to make this interworking or try to make this interworking happen.
So I will speak about interworking between current narrowband systems like Tetrays,
P25 systems, GSMR systems, and the MCX broadband system.
Why do we need this into working?
Given that You have an aeroen system currently. You have,
for example, a Tetra system, P25 system, or LMR system.
With your users, um.
They work on this system and in the future you want to use a broadband system.
So if you're clever, you build in parallel to your narrowband system,
a broadband system and put this broadband system into operation,
optimise it so that it is really working well, and you have maybe some new users on your
broadband system. And once the broadband system is rolled out,
up running, and the quality is acceptable to the users,
you will start to move the users to the broadband system.
Again, if you're clever, you're not moving all your users at the same time to the broadband
system. This may be a very high risk.
Some countries have tried to do this and unfortunately have failed.
So the better way is to move them group by group or region by region to the broadband
system. But this will result in the situation that some
of your users are on the broadband system and some of your users are on the narrowband system.
And if you want those users to be able to talk with each other,
you need to connect these two systems.
So you need a connection between the narrowband system and the broadband system.
How can we do this connection?
Fortunately, uh, this was taken up by standardisation.
So we have a standard for this connection.
And there was a kind of work split. So in this picture you can see how you connect
on the left side the broadband system, and on the right side the different other technologies
to which you can connect, for example, to Tetra systems or GSMR systems for the railways or the
P25 systems or other LMR and mobile radio systems.
And there's a kind of work split in the standardisation.
That for the £3 side of this interface, um, £3 has built the standard,
has written the standard.
So part of the £3 mission critic standards is this interworking function,
this IWF interface.
And for the other side of the interface, we have different organisations working on
that part of the standardisation.
In the case of Tetra Systems and GSMR systems, this is Etsy.
Etsy is writing a standard with the IWF interworking function for Tetra and also have
started work for the GSMR interworking.
And 80 TIA in the United States have worked on the interworking function for
P25 systems and for LMR systems.
Status of this work is that for the tetra interworking function,
this is almost finalised, so it's expected during the summer that this standard will be
published. GSMR they have started with a study item,
so it will take a little bit longer to have this finalised,
and P25 and LMR systems is also mostly finalised by now.
You can see one important difference between P25 and Tetra systems.
For P25 systems, they have defined the ISSI interface on the right side of the interworking
function. For Tetra, they haven't defined an interface
into the Tetra system.
They consider the interworking function as part of the tetra system,
and this will be an important difference. We will come to this later.
For those who want to dig into the standards and to read a little bit more technical
background, I've listed here the uh relevant3QPP standards.
Which are describing parts of this interworking function interface.
This is the left side to the broadband system.
And it's basically defining three different reference points or interfaces,
the IWF1.
Which is the interfacing into the MCPTT service for the voice service,
the IWF2, which is interfacing into the MC data server for the short data
messages for the status messages, and the IWF3 interface or reference point,
which is connected to the group management server in the broadband system for uh
managing group information across the two different systems.
So these are reference points, not necessarily different hardware interfaces,
so this can go over the same hardware interface, but functionally,
these are 3 different interfaces.
The functionality which can go across these interworking functions is voice group
calls, uh, voice private calls. This is the functionality which is defined in
the standard. So we have to be careful.
You have to implement this in the products according to the standard,
and if you, if you implement everything, you have everything.
If you implement only parts of the possible functionality from the standards,
then you will have only limited functionality or this IWF interface.
But voice group calls, voice private calls are supported by the standard with the different
modes, the pre-arranged mode and the chat mode.
Uh, the flow control, which is the PTD arbitration management in the
broadband system, and the commencement mode, this can be manual or automatic,
like if you have to pick up the call or if it's automatically put through.
The IWF also supports the emergency group calls and emergency private calls.
It supports the group regrouping.
It supports the group affiliation across the systems, the two different systems.
It supports sending and receiving status messages across the systems and short data
messages across the systems, location information, emergency alerts.
End to end encrypted speech and data.
And the transport of the key management messages.
So if you want to change your security key, all of those messages can be transferred via this
IWF interface.
So that's the supported functionality in terms of services.
What this interworking function does, um, it's converting the protocols because I have a
different protocol. I have the MCX protocol on the broadband side
and I have another protocol on the tetra side. So it's converting the protocols.
It needs to do some recoding of the speech because there are different codecs in the tetra
system or in the P25 system.
And in the broadband system, so the voice needs to be transcoded.
It does identity translation.
I have a different numbering and naming scheme in the narrowen system.
Compared to the broadband system.
It does group management or it has to do group management.
So if you want to bring group management information across from one system to the other
system, you can combine groups. You can give this group information to the
other systems so that both systems have some knowledge of what kind of members the group has
or what kind of groups are existing.
And for the security, it would allow also end to end encryption to bring end to end
encryption across, so that you have a true end to end encryption,
or you can. Terminate the end to end encryption of one
system in this interworking function and then build up into an encryption of the other domain
in this interworking function.
If you do it that way that you terminate end to end encryption in the interworking function
gateway, it's not end to end encryption in the strictly sense of the word anymore,
but this may be acceptable if this gateway, secured the gateway is in a secure location.
It may be acceptable to terminate.
And an encryption, maybe not for all users, but, but for some users.
Is one example I've On this slide I show you how this is done for the tetra
interworking. So on the left side we have the mission critic
broadband system. The system.
The mission critical servers, the LTE system, and the mission critical device,
the UE. On the right side, we have the Tetra system
with the Tetra MS, the mobile station, the Tetra radio.
They are connected with these three interfaces, the IWF 123 for voice,
for data and for the group management information.
And as I said, for the tetra interworking standard, it is considered that this
interworking functionality sits in the tetra system.
For P25, it's connected via the ISSI, but this is not done in the in the Tetra standard.
The work split is, as I said, £3 takes care about the left side,
the IWF interface, and tetra on the tetra side, Etsy is standardising how this
tetra IWF function needs to look like and what this function should do.
Um, There are no changes necessary in the device and in the radio.
For a Tetra radio, the broadband system looks like another Tetra system connected via
ISI. It's not really connected via ISI, but it looks
like connected via the ISI interface.
And for the broadband, the M6 device, the Tetra system looks like another broadband system
connected to the, to the MCX system.
King So easy, let's implement it.
There's one issue which we discovered already earlier.
I call it the chicken egg problem.
What will be first? Do you have a product and then we will have
customers buying this interworking function product, or do we have customers who place an
order for this interworking function, then you start developing this product?
Um, this can result in a very long endless situation.
If you look back for the Tetra ISI for the Tetra Insystem interface,
it took almost 10 years from standard ready to realising the implementation of the
ISI. We may face a similar issue with the IWF now
because nobody wants to do the first move.
The big issue with IWF is we don't have the time to wait because IWF will be used only for
a limited time when you need to do the transition from your narrowband system to the
broadband system, and this will happen soon, but it will only happen for a very
short time or a short time as possible because Most of the operators do not want to operate
two different systems at the same time. I mean,
they have twice the costs, so they want to reduce this time.
And what we need to do is to, to make this IWF happen quite fast,
quite quickly. This problem was identified.
It was really realised last year at the CCW when we had a masterclass about
this interworking function.
And almost I think all the attendees agreed that we have this chicken egg problems,
so we need to do something to Move this a little bit forward and not that everyone,
the, the, the customer and the, the vendor are waiting for the others to do the first step.
So TCCA organised an IWF workshop in January 2022.
And we presented the case, we presented what we see as the issue.
Uh, we ask for statements from all users, operators, vendors of TM6 server vendors of the
Tetras system during this workshop.
And uh afterwards we also agreed to do this in a more formal way,
so we created a questionnaire, sent this out, and then collected all the answers,
which gives us now a little picture of how fast we need the IWF,
how long this IWF will be needed, and what kind of functionality should go across the IWF.
And from this workshop on, we agreed also to continue with a task force.
We had one task force meeting in March 2022.
Where the answers to all these questions were presented.
Um We discussed possible solutions, so as I said, the main issue with the
IWF is that it's part of the Tetras system, which also means that the vendor of the Tetra
system has to implement the IWF interface.
And if this vendor of your Tetra system doesn't want to implement it,
you have a problem because then you cannot use the IWF.
So we have also tried to identify possible ways to overcome this issue or ways
forward. Uh, it was also clearly stated by, uh,
I think the majority of the task force members that they want to go for a standardised
solution, so they are not interested in a proprietary connection of the broadband and the
narrowband system.
Um, What's currently being done is a service overview will be
written describing what kind of services this IWF should support,
and the plan is that after the summer they will be sent out a request for information to the
vendors and ask what their roadmaps are, what their plans are,
if they can support this IWF functionality.
Good Briefly, to show you the possible options we
identified.
So the first option is, uh, I called it the native IWF.
So this is really the implementation of the IWF standard.
The Tetra infrastructure manufacturer implements the IWF and then you can connect to
the MC server of another vendor.
If this is compliant to the standard, this will work.
If the vendor of the Tetra system doesn't want to implement the IWF.
Or this is the preferred solution for everyone.
If the vendor doesn't want to implement it, there's another possible option.
That a third party vendor, another vendor implements a so-called IWF ISI
box, which connects on one hand to the standardised IWF interface,
and on the other hand to the standardised ISI interface.
This is not how the Tetra IWF is written in the standard, but this is a possible way how you
can connect these two systems in a standardised way.
So this could be an option.
If the vendor of the Tetra system doesn't want to implement this IWF.
Third possibility is to connect the tetra system via a proprietary API.
All the Tetra systems have a proprietary API which allows connection to other systems like
to command control systems, recording systems, whatever.
Uh, a third party vendor can take this proprietary interface and convert it to the
IWF. This can be an option, but it's not standard
based, so this will be proprietary connection and uh many users and operators are not happy
to follow this route. And the 4th option, this is what some Tetra.
Infrastructure vendors are proposing is to implement a proprietary connection to their own
MCX server, which means you will have not only a proprietary connection,
but also some proprietary parts in the MCX server which may lock you into this vendor for
a long time. And it was clear that at least most of the
members in this task force do not want to go this route.
So these are the possible options we have identified and we also said that we will try to
go for the first option. If this is not possible,
maybe for the second option, and we will see with the RFI what responses we will get,
what commitment the vendors of Tetra Systems and MCX systems can make to
implement this IWF interface.
A little bit about the timeline, which is a result of the questionnaire we have sent out,
uh, different countries have different timelines, but this,
I'll try to summarise what is the time frame for most of them.
So for the next 12 years, most of them are in the concept phase,
so they want to uh work out how they connect the systems,
how they, how to manage this migration phase from narrow bands to broadband.
Some of them will already start this transition phase early,
others will start this transition phase later, but most of them will start with this in 23
years. And in this phase, they really need the IWF to
connect the narrow band with the broadband system.
Um, then, At some point in time this transition will be completed,
so maybe Tetras systems are switched off and you don't need this IWF anymore,
and this will also start in a few years' time, but other countries may have this
later. So the face where you need the IWRF is
something between 2024 and maybe 2029, 2030, 29,
2030. Um, there's another issue which came up in the
task force is for the international connectivity.
We may also need this IWF.
Currently there are 3 Detro systems connected via ISI.
If those 3 countries move to broadband, they can connect broadband interconnection.
But what happens if they are not transiting to broadband at the same speed?
So if one country moves from tetra to broadband, but the others stay with tetra,
they lose the connectivity between the systems. So in this case,
also some kind of IWF is needed or can be used to connect the systems during this
transition phase in different countries at different speeds.
Hm Um There is some progress in IWF, um, as you probably know,
Etsy is doing uh plug tests for the mission critical ecosystem,
MCX pl tests, and the last one in November last year, the first time we allowed in
this block test to test the IWF as well.
Uh, the Tetris standard for IWF was not ready last year.
It's still not ready, but we made this disclaimer that this IWF can be tested on
the basis of a draught standard, and this was accepted by these vendors who wanted to test
this, and we had a few vendors participating in this IWF plug test.
Uh, Eriksson, Nemachand and Dusta from the Mission critical broadband server side.
And uh Rohill electronic with the Tetras system and Nemagen and valid 8 together with the
P25 gateway and the P25 simulator.
So this was the first step towards verifying validating the IWF.
Um, the next MCX block test number 7 is planned for November this year,
and again IWF will be in scope, and this time we will have the published finalised standard
for Tetra at least.
And then uh we can do really the first uh IWF verification of the
implementations. OK If you're interested in
participating in this interworking task force, please contact me.
You have my contact details here.
I think it's open for all TCCA members, non TCCA members.
I need to ask if it's allowed that you participate, but I will,
if there are people wanting to contribute, I don't think that should be a big,
big issue. OK, this brings me to the end of my
presentations. Are there any questions?
OK. Thank you, Petrevelulu from Finnish Transport
Infrastructure Agency.
So, um, in your pictures on the MCX side, it was always,
uh, one server.
Uh, now, uh, in, in many national projects they, they start to add more MCX
servers. So will this complicate even further this
implementation of I IWF for Tetra?
Mm, could be.
I think from the standard point of view, it, it should not make any difference how many MCX
servers you connect to the Tetras system. It's just a matter how you implement the IWF on
your tetras system. If this implementation is capable and
connecting to different MCX servers.
So it's an implementation issue, but the standard allows connection to several servers.
No Any other questions?
Two questions here.
Thank you. Uh, during your tests, have you experienced any
latency between the two systems, between the tetra system and the the broadband system,
because that was a really big issue between the tetra and the analogue rating system.
In the blood test, uh, the results are not disclosed, uh,
and it was a remote black test, so there was nobody really able to observe the delay.
I'm sure there is a delay, uh, which may be acceptable for this transition period if
you have um um.
have duplex communication, so one pressing PTT speaking and the others are listening,
then this delay is not of a big issue, yeah, if it's not too long the delay,
yeah. But Delays, there will be delays when you
connect with different systems, there will be delays.
I think there was another question from, from this gen gentleman.
I don't know. Did, did you have a question?
No, sorry, yeah.
It's a question on the They keep you busy. They are questioning first rows,
last row. Hi, Harold, you are this is Bauers.
I'm the, I'm with the company Rohill.
Uh, you are a consultant, so you are also advising government organisations,
I expect, yes, if, if they are harrowing me, yes.
So how can a tetra network operator challenge let's say the manufacturer to open up
the IWF interface to have an equal level playing field,
so to to purchase an MCX surface or product, how do you have any idea how
those manufacturers can be challenged?
That that's a very good question, but also a very difficult question to answer.
I don't have a good suggestion on how to do this.
I mean, it's negotiation. It's maybe putting some money on the table,
but maybe the most efficient way to do this is to cooperate with other users of Tetra
systems. So if if one Tetra user goes to the vendor,
it may be difficult. If 10 users go to this vendor,
it may be easier to convince this vendor to implement this IWF.
And it's very similar cities in, in, in MCX broadband more and more that cooperation is
really, really important.
Even big countries have not much negotiating power towards really big companies,
really big corporations, so.
Cooperating amongst organisations in the country between different countries,
I think it's really important, it's really key, only this,
this is the way forward to, to really move things in the,
in the right direction.
No You Any other questions?
Mhm Maybe just the final information if you're interested in a little bit more details about
this IWF, there is a focus forum tomorrow at 12:30 exactly about this IWF
topic, and this will be a very interactive session, so there will be a lot of
possibilities for you also to put your inputs, to ask your questions,
to work on this topic a little bit in more detail.
And maybe we are able to identify ways forward to, to really get this as a standard-based
implementation because as I said, this is the preferred option for everyone.
Everyone wants to have standard-based implementation of IWF.
Nobody really, nobody from the user or operator side wants to have proprietary solutions.
OK, I think we are almost at the end of the time.
If there are no more questions, then thank you everyone.
And hope you enjoyed the show for the remaining of the day.
Thank you.