Good afternoon everyone.
Uh, here in the room and online I'm not Tony grey.
Uh, he's unfortunately not available, so I stepped in for him and I'm moderating this
session now. Welcome everyone.
My name is Javed Ludwig. I'm the TCCA chair of the technical forum.
And we will go briefly through the round and I will ask everyone to introduce themselves
and to start with the first statement about our topic we will speak about beyond
standardisation.
So how do we get this into a reality for adoption when we have a standard,
what do we need to do to get really a product into the market into every level.
So first I would like to start with you, Adrian.
Yes, uh, good afternoon, ladies and gentlemen, I'm Adrian S Grace,
the Chief Technical Officer with Etsy, and I also play a role in the management of 3GPP.
So from the panellists here, I'm the one guy who spends 100% of his time working with
standards. So as you can imagine, I'm very biassed in
favour of standards. Uh, if it's not standard,
if it's not standardised, don't buy it is is what I would say to you,
but um now, in all seriousness, I mean this is a subject where.
And in particularly in this industry, we've seen sort of a progression over time from um
Bespoke non-standardized products through to standardised products and now we're getting to
the stage where we have standardised products on large scale.
So this what I think my role finishes at standards production,
so it's not for me to deploy them.
That's what these clever people do.
My job is to make sure that the standards we deliver actually meet the needs of these people
and their customers. OK, thank you.
My name, my name is Giancarlo Santini. I'm the head of technology and operations of
Mexin. Basically Mexink is the first secure MBNO in
Latin America where we implemented MCX services for for the government and,
and, and private institutions as well.
And yeah, uh, well, once the standards are released and we have all the products in place
now it's time to get that into adoption for the from the customers and that's a challenge.
And uh I, I, I was, uh, I, I was actually discussing about,
yes, we have the standards, the technical ones, but beyond that,
we need to get uh Uh, more sensitivity from the regulators where also we implement the
national standards to get, uh, the customer, uh, uh, you know,
get, uh, to know what the actual standards are and how to apply that and how the business
model, which is also key, how to develop this business model for,
for, for this kind of services so that that will be one of the of the of the topics.
OK, thank you. Yes, my name is Nina.
I'm from the Norwegian Directorate for Civil Protection.
I'm Deputy head of the Department for Emergency communications.
We own the NerdNET, which is a nationwide tetra network in Norway.
We also are as everyone else, looking at how to approach the
future 4G and 5G, and with all the promises that come with that.
I'm also a member of the board of TCCA and I'm
very much in favour of standards.
We cannot, we can't live without them actually, but I don't think
it's enough to have a standard.
It does not give us the product we need necessarily, so we also need that that
the industry.
Our developed products and services to fulfil the user needs and uh
I understand that uh that we all have to, to cooperate in order to get there.
OK, thank you Paul. Yeah, thank you, Harold.
Uh, Paul Steinberg, uh, senior vice president of technology with Motorola Solutions.
Harold, thank you for stepping in for Tony, uh, last minute,
so, uh, this is a super important topic.
Um, like Adrian, I actually have a foot in both camps, so I,
uh, our standards, our 3 GPP standards team reports to me,
so standards are very important, and we do a lot of work on them,
but by the same token, productization of those standards, as Nina said,
that's where the tricky part comes in.
Standards are this wide and what really matters can be this wide,
but sometimes there's a little bit over here that um that standards didn't contemplate,
so we get this cycle.
Um, I think, I think it's a super important time to talk about this now for a couple
reasons. One is.
It's in a we're in a multi-technology world that we've never been in to this degree.
I mean, before there was Tetra and how do we get all the pieces of Tetra to communicate,
but now we're talking 4G and 5G and different flavours of those private and public and so
getting all of those harmonised together so that they work together so that in the end
users don't see a difference, um, you know, whether regardless of what's actually carrying
the bits for them, that to me is the super important part we'll not get there without
standards. OK, thank you.
If you set standards, you're, you're, you're done when a standard is done.
We have, we are talking about mission criticity standards.
Mission critic is 3 GPP standards here now, uh.
Many people would agree that the standards are ready, but when is the standard ready?
Is it ever ready?
Uh, it, it can be ready, but it's never finished, if that's what you mean.
I mean, it's, it's unusual that the first publication of a standard has a level of
maturity that's acceptable, uh, but you have to start somewhere.
So you have this then this iterative process of, um, standard availability,
first products in the market, feedback loops, maybe you do proofs of concept trials along the
way. But that feedback loop is incredibly important
that you know sometimes it takes 4 or 5 editions of a standard before you get to a
level of maturity and I mean arguably it will never be mature if it isn't deployed,
so you cannot have maturity without deployment is my point.
mission critical standards mature already, or do they need to be proven?
I would argue that tetra is a mature standard, a very good mature standard because it's been
around for. Decades, but because of that, you have that
level of maturity and you see the benefit of having that maturity.
But you know, when you're moving into highly complex advanced communications,
of course it's never going to be mature from day one.
We know that. And but you always have the early adopter,
the first to market, who, you know, fortunately they, they debunk things for you and the the
late adopters tend to benefit from from what the early adopters have done and It's then a
commercial arrangement between the supplier and the customer about,
you know, when you first deploy, are you prepared to go with an early product knowing
that there will be this frequent upgrade?
You know, what matters is that you can upgrade, so you wouldn't want to be an early adopter of
a standard that has no evolution, which is why I think that the choice of industry to move
into 5G was a very wise one, because that evolution is there for for years.
To come and where do you see the mission critical broadband standards to be?
Are they mature enough to start implementation, or I mean they're being implemented.
So by definition, yes, I don't think I don't think manufacturers would ramp up and start
producing products, which is a hugely expensive process.
Why would they do that if they had doubt in the suitability of the standard?
It wouldn't happen. OK.
Good, good. Then I would like to ask the two guys from
industry, when do you decide to start implementing a standard?
I said it's written, and it's becoming mature.
When is the point in time where you say now we have a version which is mature enough that we
start investing and develop a product and implementing it.
I know you never will be like that.
Convinced that everything is ready because this is uh as as as mentioned this is an iterative
process right it will be getting proof so you need to make a bet on what will be the the best
uh you know, moment to to do it. I think the best moment to do it is when you
identify a clear need on the market and and that the current standard fits on that need.
I think that that that would be the the the initial movement that you need to do.
And, and again this is an iterative process not only in the standards but also in the product
definition and the product evolution.
You, you will have several releases until you get uh comfortable and again,
and I, I, I agree you're not gonna be totally sure that this is uh ready in terms of product
until you have deployed and you got, you have feedback from from the customer.
So I think the best moment to do it is when you identify the actual need of the of the market,
OK. Yeah, yeah, I agree, not a lot to add.
I think, I think it starts with the customers, um, you know,
understanding, trying to anticipate what they're going to need and trying to anticipate,
you know, how they need it delivered, but I think the other part is,
uh, if you think about mission critical push to talk, we've been implementing that for probably
a decade. uh, it's been in the process for quite some
time. A lot of the the learnings that have gone into
that. Have actually matriculated into our standards
contributions. I mean, that's what's informed what's gone into
standards and then you know now we're to the point now where they are,
you know, they are rapidly seeing deployment in many of our customers' environments now that
feedback loop that Adrian talked about is starting to happen,
so we're starting to see some things that aren't quite right,
um, whether it's, you know, functionality or missing features or you know something doesn't
work exactly like we thought.
Um, we're doing this, you know, this this dance with the carriers who are oftentimes the host
of the underlying service, so working through the business models there,
um, so now I think we're very much we've gone beyond a ready standard available.
We're in the maturation phase of the standards and the good news is we're seeing a lot of our
users start to more proactively engage and pull, and that's gonna speed the process.
OK, good. I want to ask you as a user, when do you expect
something to be available in a product? If you see a standard a version which is
available, do you want the product to buy immediately?
Do you have time to wait until you buy the product, or do you think some standards may be
too early to be?
Purchased as a product.
I think it's it's a complex question.
We have a timing issue in.
In our industry, I would say when we first start hearing about the
possibilities and the standards, we of course we also want it,
but. Uh we are, uh, for public safety communication,
we are depending on state budgets, uh, with long decision processes and,
uh, very risk adverse decision makers.
Uh, they don't want to be the front runners. They don't want to have any problems in their
projects. They want to buy something that they know it
works and it should be delivered on time.
Um, and, um.
I think that um.
Especially in the times where we are now, where everything is moving faster and faster and and
uh and you see the technology development on the consumer side,
how fast that's going.
You want to have the same possibilities also for mission critical.
Um, But it's um.
From my experience, it's uh.
It takes time and and It's like Paul said, the standard is this big,
we need this and maybe we need something here as well.
And maybe everything is ready, but this little bit, which actually is a very niche thing.
Uh, it's not delivered before you actually buy it.
And I think there is There's something with the timing that we are facing,
especially now with the new technology.
You said that governments are usually the processes take long.
They are not very happy with taking too much risks.
So if everyone is waiting, I mean who will start to buy something in the end I think that
that's a real issue and And that's probably
also something governments have to look into how to come on this train that's moving faster
and to be in a position where you can follow the technology development as it advances.
Looking back, I've seen in Tetra with the Insystem interface to connect Tetrays.
The standards have been ready for 15 years maybe now.
And then it took 10 years until we really saw the first implementations of it and now we have
a few interconnected networks.
How can we avoid this situation that everyone is waiting for the other to do something?
There are plenty of standards that have never been implemented.
I don't see a problem with that personally. I think.
The role of standards bodies is to enable industry to innovate.
So it's important to understand that we don't standardise products.
We standardise interfaces.
So it's not a standards bodies's role to actually define a product specification.
What we what we do is prevent present. Enable us to industry who can take those
components and assemble them in different ways to make products for their customers.
So you know, if we were to have one single implementation, maybe we could write these
specifications in a different way, but then you totally stifle innovation and and we don't want
to do that. But I think if we jump into a parallel universe,
it's interesting looking at sort of product maturity and Just the simple case of where we
are with electric vehicles today. Would you have bought an electric car 5 years
ago? Would you buy an electric car today?
Or do you still think you should wait another 2 or 3 years before you buy your electric car?
And it depends, you know, we we we probably have all have different views on that,
you know. Personally, I wouldn't have bought an electric
car 5 years ago because I didn't think they were mature enough.
Others will argue that's nonsense. They're perfectly mature.
Get out there and buy one.
And I think you know your customers all have that same different level of understanding
about what maturity actually means, especially with electric cars.
I think there's a wide field for standardisation for the charging stations and
actually I think that's another good point though, because Would it have been right to
have standardised the charging station and the connector from day one?
If you'd have done that, you'd have probably stifled innovation.
So I think with such a fast moving market, you needed to have that space where industry sort
of evolved, and we saw the benefit of different approaches to charging,
and and maybe now they're coming around to a consensus view that says this is the best way
to approach charging and the best connector to have.
But Yeah, you, you can't always standardise from day one because you will then limit
innovation if you're not careful, I agree, I agree, and,
and, and going back to to to the who who's gonna do the first movement,
who's gonna do the first step, it's quite complicated sometimes the role of the industry
is also making this decision easier to the customer having a new innovative.
Not only technologies but maybe even business models that they can you know uh decrease the
risk on doing that as, as, as Nina mentioned the problem is the budget and sometimes risking
the budget for something that might seem not that mature it's,
it's complicated so in that sense the industry supporting the customers to go in for that
first step is key.
I, I, I mean, for example, uh, some, some of us have done that with our customers,
you know, implementing as a service, not going to sell the whole infrastructure which may may
be really, uh, not cost effective considering that the,
the, the, the people perceive the standard is not there,
but you can do this first movement as an industry to make it easier to to to them.
So you would say you do the first move, or do you expect the customers to put the money on
the table and then you start implementing it? Well, you know.
My experience, we did it the first time. It was quite difficult to get the the the
people moving towards broadband because they feel it's not mature enough so we did the first
movement like, hey, I will make available a service for you without any kind of infra
investment, no cap. investments I will put it available for you so
you test it you you you you you have a sense of how it works and we have feedback in in return
so we can improve this this this will be uh the cycle that will help us to to to set the
standard out there.
So how is it in Motorola you expect the customers to make the first step?
Yeah, it's it's a great question, and I hope you all can hear me.
All I hear is blah blah blah.
So it's good. OK, so back to a point Nina made earlier about
about the the acumen of the users and the the the care that they take in adopting these
technologies because they literally are betting life and limb on these technologies.
So trust is super important. So the, the first step toward adopting anything
new. Whether it's standardised or not is establish
the trust with the users that it's going to do for them what they needed to do reliably and
predictably, and the bar is always, it can't do less than what they have today if they don't,
if we can't replace what they have today, it's almost guaranteed to be a non-starter.
So I think that's the first bar the way I look at the world we're in now and how we get there,
um, I think if all we do is we just replace Tetra with broadband as the next voice system.
We'll have missed the opportunity dramatically. There's no,
there's no point in doing that. We have a great voice system today.
The promise of broadband is video and data and multimedia and all of these things that we all
hear plenty of advertisements from on the telly.
So I think, I think the aiming point for adoption of those technologies should be there.
And I think part of establishing the trust and the way we get there is we have to build a
cautious bridge between the two so that, so that users can adopt either technology as they
need to. On their terms, uh, when it serves them the
best and the bridges are in the network that's the interworking and the inter you know,
the interconnectivity between the technologies, the bridge can be at the device level as well
devices that are intelligent enough to actually span networks choose the network that's
relevant. So I think we as industry, you know,
need to work with our users to understand what are the right bridges to build in,
what are the right ways to help them affect the adoption of the technology.
And to convince their users and develop the trust of the users as we go,
so that, that to me is a key role that we have to play.
And as Nina said earlier, the world isn't flat in that regard.
Not every market thinks of that the same way, so we have to kind of work with our users to
try to integrate a common point of view on that. OK, so,
so Nina, how do you see this? I mean, if, if your preferred supplier comes to
you and says, trust me, I'm your supplier.
Give me your money and I will make you a very good product.
Is this convincing for you?
But first I want to commend to Adrian. I bought a Tesla 5 years ago and uh and I I
hope they never let others into their charging stations, which they probably will do but
but that's me for mission critical services you cannot
allow. Non-standardized solution.
It's not a dynamic market.
If the government are doing investments, it's probably going to last for years.
And if you then go in with something that's not on the standard and the standard development
path, you are in a lock-in situation, but you don't want to be there.
Maybe I don't think the industry wants us to be there either.
It might be tempting.
To try to to to get that and to look to get some lock-in effects,
but I think all knows that in, in the long time run that's not a good idea that we have to have
uh um.
We need to have a ecosystem that works that is based on open standards and that works
together and regarding the bridges, yeah, it's also a relevant
question because in the new world.
There are so many players.
There are the value chain is so long and it all has to work,
as you say. It has to be trusted.
It's not only the network. It's not only the terminal radio terminal,
it's the software, it's the operating system, it's the application on it.
It's the whole chain and if that's not.
I mean, I would not advise anyone to go on pre-stands on those things
when you're supposed to provide mission critical service.
I think I think it's a really great point you make, and I'll even go so far as to say.
It's impossible with the ecosystem that we're exposing to you now for any company to provide
you everything, um, certainly not best in class everything, so it would be irresponsible of a
company such as Motorola to not afford you a standard solution where you can actually tap
into innovation from different components of of of industry.
So I think you make an excellent point that innovation is the key component that you need
standards to help you enable.
I have the feeling that we are not discussing the benefit of a standard or not.
I mean, as I see it here, everyone is convinced that standard solutions are the way to go.
We don't have to argue against standard solutions, but I would like to ask the audience
online and in the room, do you have any, any comments or any questions?
I know we have a microphone.
Can you please state your name and your affiliation?
Hello, my name is Stephen Mayer.
I'm from Astrid, Belgium, public safety operator.
I'm sorry for my voice. I'm shouted too much the last days,
but, um, as Adrian said, the standards were written and they're there.
I have no doubt about that. There are a lot of documents to read,
uh, too much, in fact, but, uh, standards also provide optional features,
optional implementations.
And while one manufacturer is choosing one option, the other might choose the other option.
So my question is, if I look back at Tetra for the last 20 years,
we had an interoperability programme that was running.
So my question is, is interoperability also foreseen in this MCX era,
or are people just saying a standard is good enough and you don't need interoperability?
Mm OK. So, so may I maybe, maybe rephrase the question
is how do the manufacturers decide which options to implement and which options not to
implement and is there any discussion between manufacturers that you implement the same
options so that the users can really use these options across your products.
This is an iterative iterative uh process at the end you implement the the base of the
standard but uh.
Listening to the customers key, making proof of concepts there you will get some valuable
feedback and and getting back with that with that feedback,
then you can decide if you implement or if the market is actually willing to have those uh
options or not.
Eventually you will be doing that however first uh is listening to the customer voice and
seeing what is really and actually valuable to them.
OK, so you're going to Steve me ask him what he wants.
Well I I I mean it's basically uh an exercise where you see feedback from different players
even even uh talking to other manufacturers and seeing what what they are doing uh plus the
customer voice so it's just a part of uh of of of the.
Has anybody ask you Nina what you want?
I want to actually answer that question with
with TCCIA's role because that's what we can provide is a meeting place where users
and operators and the industry can meet and discuss and I
think what we have seen in the last years is that there is the need.
For this meeting places and also I saw from the From the
master classes yesterday that the critical broadband master classes were pretty full and
very good discussions and so I think that's something TCCA really
has to provide for the members a platform for these discussions.
Stephen pointed out, it works quite well with Tetra for when you started 2 years ago.
And maybe we need to repeat this now with broadband as well.
Do you want to add something? Yeah, I think, I think it's been said.
I think, I think there's absolutely a role for interoperability testing and verification.
I think Nina said it well. I think that's a value that TCCA can bring.
I think it's important for that to be an objective body as opposed to,
you know, a particular, you know, industry component, if you will.
Excuse me, so I think TCCA does that well.
Um, I think the other, the other dimension I would add is,
um, as Giancarlo said, there's, you know, we integrate the,
the desires of our users and build a base product.
I mean, that's the starting point, and then we look and decide,
you know, where there's efficacy and desire and need across the other markets where sometimes
it gets tricky is when you have two adjacent markets that want to enter work.
And they have different standards or they have different feature sets that they want to enter
work. So that's a place where I think we, we need to
do a better job that communication among our user groups to try to arrive at that true base
interworking set of capabilities. OK.
Any other questions or comments?
I, I, I can also check online. You can type your comments,
but I have not really received anything so far, but any,
any questions? Yes.
Uh oh, I think I'm too close to the speaker, so I apologise in advance because this is not my
field at all, but I'm here for something else. This question is specifically for Nina.
You mentioned that the government is typically risk averse when it comes to procuring
different products and services until it has either reached a maturity level that risk
averse leaders are comfortable with.
What is the analysis to determine.
That that maturity level has been reached for those risk averse leaders.
Sorry, we cannot really hear very well here. Maybe you can come here and I'll
navigate around. Can you hear me here?
You hear it well, but we don't hear with the loudspeakers.
Speak closer to the microphone. Just come, come closer to the microphone.
Can you hear me now? Everyone can hear me now.
Hi.
So I'm actually a non-technical person, so I hope this question makes sense,
but Nina, you said something that really struck me, and that was that the government,
uh, leaders are risk averse in their decision making.
And so they want to make sure that there's efficacy proven maturity with the standards.
Is there some type of analysis that you apply to make sure that you're comfortable with the
maturity of the standards and that there's efficacy before you actually make the decision
to move forward?
I think I can at least have a little bit of a go on this,
but because it, it's back to the standards of maturity question really,
and, and there are formal things that we do to ensure that a standard is mature.
One is to validate the standard itself because it might be that two very well recognised
vendors implement the same standard in different ways because the standard has been
incorrectly written, it's ambiguous, so we have an iterative process that makes sure by having
you. Competitors in the same room validating the
standard through a sort of interoperability testing, plug test type activity,
and that helps to build the confidence that says we know this standard is interoperable
because we've had half a dozen manufacturers bring their products,
they've connected them together and they do interoperate and where we've found bugs we've
fixed them through a plug test type environment and I think that's important that we have this
continued sort of validation.
Um, by having formal testing, there is another step we can,
we can take as well, which is to write um formal test descriptions for how products
should behave. This is a mainstream activity,
at least in 3GPP for the radio interfaces, so that we can use automated testing.
Make sure that products do behave as intended. So if you're trying to convince governments
that the standards are mature, there is sort of factual evidence you can put on the table and
say we've had these proof of concepts, we've had these interoperability tests,
and the results of these tests show.
90% pass rate, which is the activity that you run Harold answer your question I think you
asked what governments do, what can they do, and
I think that the governments also need to make sure that they have good contracts.
That this is covered in the contracts and that it's not only standardised when you buy it,
but over the time as the development goes and so also when you are
replacing it so so. And I think that will become more important in
the future for for the good contracts to make sure that you have the tool that
you need to to to oversee what you are getting.
You OK? Any other questions, comments?
I think one other important issue is that what I see in standardisation there's a strong
industry representation writing the standards, but uh users are not very well represented.
How can we get more users into the process so that they can really express their
expectations for the standards so that we don't write standards which are not implemented in
the end? any ideas how how we can do this?
How do we engage better not only in standardisation also what Stephen mentioned if
we in TCCA have a platform to agree what to implement, uh,
I think the big issue is that users usually don't have a lot of resources and time to
contribute to this.
Any ideas how we can overcome this?
Engaging engaging the customers that we have governments agencies,
uh, into the test and validation process proof of concepts are key here and,
and going back to to Paul's point on confidence, if they are confident enough in the products
in the brand and and in the industry, they will be open to test new things.
We need them to to engage them into the the the proof of concepts and and validation.
That's key. I think that is the best way to get them
engaged on this, but isn't it not important to engage them earlier,
not after you have implemented it already. Yeah, exactly,
exactly. You need to do it in the proper time when
defining the product implementation of the standards, and how can we do this?
How can we engage them early and also help them.
Not to spend too much time and resources to get, get to convince the resources that is a
really interesting question and that is when, when, when,
when the confidence on the manufacturers comes because because because you need a a good base
of your customers willing to test and you need to push them to,
to test this. It's it's a kind of balance, uh,
a fine balance that you need to do on that. I don't know.
OK, I think there's a bit of a difference between a customer and a user though,
and, and sometimes it's hard to determine who the actual user is.
I mean, in, in this particular case in Norway, is is the user the Norwegian government,
or is it the policeman that's on the street using the the network?
And and you might get different answers to questions depending who you ask.
So somehow you need to have some sort of aggregation of of the the overall users'
requirements. And I think this is a relatively simple case in
public safety. If you look at, say, health authorities,
you have an enormous.
Uh, different number of users throughout the system.
So you know it's if you expect all of those to come to a standards body and express their
opinions, it's probably not even going to be helpful, so you need you need consolidated user
requirements and and and it's not necessarily a straightforward thing to do that.
OK. Any any views?
any ideas?
What what would you like to have from industry or standardisation organisations to help
you to get more involved?
Um, It's firstly, I think that in the
future it's rightly as you say who's the user and who's the customer,
and I think this will be even in the future will be more diverse,
I think because Tetra was It's pretty, you know, it's handmade for its use
and when we get into the new ecosystem with data and IT and
everything, there will be more devices, more users owning those devices.
But through lots of different contracts.
So how to get one view on on what the users need?
I don't know if it's possible. I still think that what TCCA can can bring to
both users and industries, this platform for at least
discussing and maybe sort out what is the most important.
And then the other which I also think is very interesting.
Can you ask the user? Can you actually ask the user from what they
need and do they know that because it's new technology and we don't really know how that
technology will be used when we see autonomous vehicles, for example,
also being used in mission critical situation which will come,
I'm sure. Uh, so what, what are those, those needs?
I think we Um, but I think it's really important, really,
really important questions. If, if we go in the road where the user needs
for mission critical services are the same as actually the rest of the market because.
It's so critical for everyone.
Then the gap is less, uh, but I'm not maybe someone something that we
will get there eventually, but.
I don't know how that timeline looks like, and it doesn't solve the problems that we have in
the next 4567 years.
You want to add something? Yeah, I think, I think a couple of points Nina
made I think are really important. um, so I think you know what we see in general
is that you know user driven standards are the best.
I think that's clear no matter what industry.
That's not always possible here. I mean to do that you would have to be
technical experts, and that's what you rely on us to do,
right? So I understand.
um, but back to the excellent point you made is if you think about the canvas that we have to
paint on and the colour palette that we have today with broadband.
It's so much more diverse. It almost feels like voices almost like uh
charcoal, and we're now we're talking about the full spectrum.
So to your point about users not being able to tell you what they want,
of course they can't they don't know what's possible.
They don't know the the art of the possible. So what we try to do and we when we perhaps
need to engage more perhaps with the the TCCA and the users group,
we do customer research so we have, and these aren't engineers,
these are ethnographers and these are human factors engineers that.
Do the best that we can, we try to live a day in the life with the user and and as we like to
say they may not be able to tell you what they want or need,
but if you watch them the right way, they'll show you and so that's the job of these people
is to help understand.
How do you marry art possible with real user needs um when you're not talking about people
that are technology designers and then you know getting you into the process more proactively
so that you guide the standardisation process to get from that unmet need to a standard that
can realise it. OK.
Any questions, comments, trouble?
Hi, excuse me, can you hear me, Mr. Panel?
All of you? Yeah, fantastic.
Uh, for the others, Dave Chatterley, Motorola Solutions, longtime involvement in Etsy,
3GPP and that stuff.
So put your minds back 25 years ago to the early days of Tetra.
Tetra became what it was, a mobile radio system suitable for public safety for users
because several governments sent representatives along to drive the standard,
the direction it was intended to go in.
Tetra didn't start as a public safety standard. It got pushed in that direction.
The UK, the Netherlands, the Belgians, some governments like that pushed us in that
direction. With 3 GPP standards, we're having the same.
We have the UK, we have BDBOS in Germany, we have FirstNet,
we have the police of the Netherlands.
They're all in there and they are the people interpreting and representing the user needs.
Now the one thing that we did when we started Tetra was we ran some pilot systems.
The manufacturers brought out early solutions which may have been mainly standard
compliant in some cases maybe there were shortcuts, and they were put in the hands of
the users and it was getting these pilots running to see how the interpretation of what
we thought the users needed worked.
I'm not seeing quite the same adoption of pilots in the same way in the MC world,
so my question to the panel really is, should we have a couple of concentrated pilots,
and I wonder who would like to adopt them and run with them to give that feedback into the
standards of the implementation community.
You mean some kind of rapid prototyping and Pretty much yes,
and get it into the hands of the users and some of the tetra pilots were so successful that
they didn't actually want to take the old radios out anymore and didn't want to give the
tetra radios back. That's what I think you need to get to here.
I think I think that's a very good point.
Everyone who has been following this discussion this discussion the last 10 years,
we know that it's it's been a lot of good work to actually get the
requirements into the 3GP standards and and there are projects coming up,
but it is very technology oriented and I think it's hard for the users to get grip of what it
is, so I think.
I think it's a very valid point.
What we have done in Norway is that we have a solution that looks like a future
solution that will actually connect to the Tetra network,
but it will not be mission critical. So you can hear more about that tomorrow.
If you're here, but it, it, it's actually what we are thinking that how much we learn and how
much the users learn because they can touch it and see what it is about.
Well, are you developing any pilot systems for users to play around?
Yeah, definitely, and I think one of the great things about the technology and the rapid
change that we see today is the friction or the effort to create a reasonable pilot is actually
much less than it used to be.
I mean, there's so much enablement out there that we can build upon.
So yeah, it might be a smartphone, and what we found out is a smartphone is not really the
right look and feel for most users, but it's an OK facsimile for people to get some experience
with it, so. Yeah, I think definitely a lot of pilots.
I mean, if you think about mission critical Bush to talk,
that's eminently pilot today as is video. OK, but,
but ESN is not your pilot for what's that ESN network is not your pilot.
No, we don't try to do a pilot with a with a system that's trying to go production a bad
combination. You any plans for pilots or?
Well, we are running some of them, but I, I, I, I agree it's,
it's like, uh, just testing some pilots without compromising the current production systems.
So yeah, that's, that's part of the, of the things that we use to validate,
uh, some ideas and yeah we're running some, some of them.
OK, thank you.
I think we have reached the end of our panel.
Uh, thank you everyone for joining.
I think maybe the key message, uh.
User involvement in writing standards, getting standards, user involvement in deciding what to
implement from the standards, I think that's and implement actually implement the standards.
OK, thank you very much.