Gokul Srinivasan is the Technical Director at Robots Expert, a key player in research programmes such as 5G Drones and Gulf of Finland
What is the potential for 5G in UAS traffic management (UTM)?
I think 5G at the moment is going through the “trough of disillusionment” for UTM applications. We all know 5G is great. From a speed perspective 5G is phenomenal for terrestrial applications. But drones fly at 100 or 200 metres and from our experience the idea that 5G can solve beyond line of sight (BVLOS) problems and enable BVLOS missions is something of a myth.
To support BVLOS operations, 5G should have a low-band spectrum – 800 or 900 megahertz. But at that low-band spectrum you do not get the advantage of 5G, which is the speed. An 800-megahertz channel cannot, for example, support transmitting light detection and ranging (LIDAR) data in real time; one minute of LIDAR data can be anywhere around five to six gigabytes and if you want to transfer that at edge level, in real time or near real time, that’s not going to happen over a low bandwidth.
To get high bandwidth you need a higher frequency: five or ten gigahertz. But the problem with these higher frequencies is that they work at shorter range; they do not have the coverage required. With 5G, you have three options: coverage, latency and bandwidth. You pick any two. You don’t get all three.
But you don’t need all of that for UTM, do you? All you need really is reliable position reporting and identification. You can do that with 4G.
For UTM, you could use 2G or 3G. The data you are transmitting is PNT – positioning, navigation and timing – and maybe some vital characteristics such as battery power usage and your next waypoints, similar to automatic dependent surveillance-broadcast (ADS-B) coverage.
Companies like INVOLI have successfully developed trackers which work on 2G or 3G quite successfully. We are now looking at a combination of different network capabilities – 2G, 3G, 4G and 5G – to see how the UTM service can be deployed.
But to piggyback on 5G and UTM alone, it’s going to take a lot more effort.
And 5G has not been deployed at scale, nor has it been deployed for aerial applications yet. Many helicopter pilots use a software system called ForeFlight on their tablet which has a 4G connection. They fly at a pretty decent altitude and they’re able to get connectivity; they cannot do the same thing with 5G because there’s no connectivity.
Once 5G is fully rolled out we will be able to see what may be possible. In theory, the higher you go, the more mobile base stations you can reach but that’s only valid to a certain point because the antennas in the towers don’t usually face up, they face down. So, unless you perform some antenna beamforming on the base station – which may be possible with 5G because of its improved beamforming capabilities – it not going to support both aerial and terrestrial. There must be a trade-off between the two at some point.
Can we talk a little bit about Gulf of Finland (GOF) One – what did you learn from that, from a UTM perspective?
We learnt many lessons from GOF, especially in the flight across the Baltic Sea which required a change of mobile network operator on the cross-border flights showing that acceptable connectivity on 4G for PNT use was possible up to ca 800 meters of altitude. We were able to solidify the U-space architecture; we were able to validate the SORA method and provide feedback to the SORA committee on what worked and what didn’t. The Civil Aviation Administration derived value from seeing us implement some of the regulations it had introduced.
From the UTM perspective we also learnt lessons about the “safety bubble” you have to create when you have a drone in the air, in regard to the accuracy of positioning reports. This showed a difference between a position report from the telemetry versus positioning sources such as ADS-B due to time-lag and positioning source differences. A single target would show up as several ‘blips’ on the moving map. Sometimes a drone had to be re-directed in-flight to get to areas of better connectivity, which meant we had to establish a bubble around the drone to take account of the inability to always fully follow a pre-determined path. This is extremely critical when it comes to tactical and strategic deconfliction methods and developing drone corridors and separation versus segregation.
When do you think we will have the technology and the procedures for accurate tactical deconfliction of drone flights?
Theoretically, the technology already exists. We know what to do and how to do it. Simulations have validated some of these tactical and strategic deconfliction methods and we have performed evasive manoeuvres. But can this technology be realistically rolled out in the production phase? That is a big question.
Testing, evaluation, verification and validation – those are the four buzzwords, but in reality the way it works is testing, testing and more testing. Have we performed enough tests to validate that the probability of a malfunction is acceptable for the mission type at hand? We are not there yet. We are still in the early stages. There have been few opportunities to accurately validate some of these use cases.
So where are we in the technology readiness level (TRL) development timeline?
There’s no one-size-fits-all. The US Federal Aviation Administration (FAA) and NASA have been trialling many different pilot projects with many UTM and drone operators. That’s been fairly successful but it’s not at a maturity level where they can go to the public and say: “Here’s a technology, it’s reliable, it’s safe and you can start using it.” We are not there yet.
We have to embrace the failures, learn lessons from them, make improvements and move on. In terms of moving from TRL 1 (basic principles observed) to TRL 9 (actual system proven in an operational environment) I would say some initiatives are between TRL 5 and 7. In Europe, U-space is proceeding at a fairly decent rate; but we’re still a few years away from seeing actual deconfliction procedures being accepted by regulators.
What are the immediate challenges?
The immediate challenges relate to enabling Urban Air Mobility (UAM) in practice. One of the necessary tools will be a GIS (Geographic Information Systems) platform which can be used to bring UTM providers, municipalities, drone operators and air navigation service providers (ANSPs) together around the same picture and the same digital twin of the urban area.
We need a system that you can not only visualise but also use artificial intelligence to do much of the processing of policies and operational data, thereby automating many of the functions. We are also writing a guidebook, a kind of cookbook for cities who want to implement UAM projects as part of a productive commercial deployment. What are the things that they will require? Who are the entities they need to have on board? What architecture is needed?
We have at least four other projects involving urban air mobility, drones and manned aviation, testing tactical and strategic deconfliction methods, trying to understand the integration between UTM and ATM. The next three years is going to be incredibly interesting, challenging and busy.
We are not UTM providers. Much of our job is to make sure that UTM systems being deployed are solving real-world problems and are compatible with existing systems. We look at the overall ATM architecture and advise on what sort of integration to UTM would work best. If a company wants to integrate the UTM and ATM systems in a way that mean a substantial change to the existing ATM system we would at the moment advise against it. Integrating UTM can only take place if there is no detrimental impact on the existing ATM system.
Many UTM service suppliers are struggling to develop a viable business case for UTM – is it possible to make money out of initial UTM services?
UTM operators can make money if there is a mass deployment of drones that benefit from it but I don’t see how and when this is going to happen. Or we could change the business model so UTM developers and service suppliers could charge not just by the number of drone operators and missions but length of flight.
If a forest survey company uses a drone for forest ortophotography over large areas and a daily mission lasts six hours that equates to six hours of UTM data usage. That could lead to some business innovation, especially since such flights may need to interact with manned aviation.
So far there has been little discussion about what business models will be used, who pays what and to whom, how much and how often. I think we are in really early stages of UTM. But I also think there is a disconnect between the UTM technical development groups and the UTM marketing and sales teams.
| “User compliance is going to be one of the big hurdles initially, and the only way to get around it is to design the user experience with drone operator glasses on. In clear text this means, that U-space services need to add value to the drone community from the start.” – Jonas Stjernberg, Partner and SVP Robots Expert |
Some companies are offering UTM as part of fleet management programmes.
When we put the words “fleet management” and “UTM” in the same sentence we have to be extremely careful. Though these two services might look similar, their function and forms are completely different. UTM has way more liabilities than fleet management. Fleet management tools are allowed to have interactions at a firmware level so they can have direct conversations with the flight controller and the autopilot. But UTM should not be having those conversations. The C2 link between the UTM and the aircraft should strictly be informative and not command-oriented. At no point can the UTM system send or issue an auto land command to the drone, whereas a fleet management is authorised to do that. I think it’s important to highlight the difference between these two because sometimes they are used interchangeably, which is not the best approach.
I’m still not sure where the dividing line between UTM and drone operations starts and ends – especially when it comes to alerts on the use of emergency helicopters in drone operating areas.
This is where we have to examine U-space more closely. Before U-space, everything was the responsibility of drone operators; they had to ensure communication with the drone, they had to follow the regulations and they had to be clear they were not endangering human beings, animals, buildings, birds, whatever. All of that is still the responsibility of the drone operator. If an emergency service helicopter flying at low altitude enters the picture an alert is issued to turn the drone operating airspace into a no-fly or restricted zone. It is up to drone operators to make sure that they see the alert and follow it.
But it is up to the UTM system to make sure that the operator sees the alert. There must be an alert which the operator can see via the human machine interface (HMI) so when operator looks at their drone system (or at a separate airspace map) they are also looking at the geo-intelligence of that region which is a part of UTM.
The UTM system is responsible for making sure that the operator knows if it is safe to fly or not, if there’s a windmill, or a helicopter flying or this area is dedicated to glider flights. I would not expect the drone operator to know how to read VFR charts and understand the nomenclatures. It’s up to the UTM service provider to ensure that the drone operator is well informed.
We’re talking about the UTM system linking to supplemental data providers and these guys are going to be charging for their services. How will this be paid for?
UTM operators will need a broad range of data, some of which they will be able to obtain from ANSPs and some which will need to be acquired on the free market.
It is maybe difficult to obtain and if you want to buy this data for a single country once year it could cost significant amounts of money. All this makes it difficult for a UTM service provider to be clear when they will reach break-even.
There are also wide variances in the quality of the data which need to be addressed.
For example, the common altitude reference system (CARS) programme being developed by Eurocontrol and SESAR is one such programme. A drone typically uses the barometric pressure to determine how high it is flying but it also uses algorithms on board such as extended Kalman filter to use data from GPS, GNSS, GLONASS signals to understand the altitude. But the tolerance value of this data is very controversial, with different reference systems – above ground level, above mean sea level, for example – being used. So, a group of experts is working on this common altitude reference system based on digital terrain model.
