Patent Application
20180253092
The present invention has its application in the telecommunications and engineering sector and relates to unmanned vehicles, especially unmanned aerial vehicles. More specifically, the invention described herein deals with the safe, centralized, viable, and efficient control of unmanned vehicles.
The technology of unmanned aerial vehicles (better known by their acronym in English UAV), also popularly known as drones, has significantly attracted the attention of the media and general public, and the prospect of increased use of drones for civilian applications will be exponential (up to sales figures of 300 million units for 2016).
There is a current regulation on the use of these vehicles, which, among other things, specifies a number of requirements for both piloting, and companies that operate and/or manufacture them. The regulation of drones has responded to the need for establishing a legal framework that allows the development in safe conditions of a technologically cutting-edge and emerging sector. Different regulatory bodies in each country and/or region will be responsible for controlling compliance with these regulations and the control of drone usage. In the case of Spain for example, the State Aviation Safety Agency (AESA), at European level the European Aviation Safety Agency (EASA) and in the United States, the Federal Aviation Administration (FAA).
Hence, for example, in Spain, according to current regulations, drones have been classified into three groups depending on their weight: over 25 kg, under 2 kg and up to 25 kg. It is mandatory for those in the first group to register with the State Aviation Safety Agency (AESA). If the drone does not reach that weight, it does not have to be registered, but each operation or modification should be reported to AESA.
Of course, there are many situations where the drones (or any other type of unmanned vehicles) can undoubtedly serve the public for searches and rescues, environmental monitoring, treatment with hazardous materials, etc., but there is widespread concern about their use in both military and private tasks and the accidents that they might cause. This concern is based on the numerous cases of “hacking” of drones that can allow a third party to appropriate the control of someone else's drone, through unauthorized incursion in the system that controls it.
In addition, there is the concept of “widespread vulnerability” in this robotic aerial vehicle, which refers to another weakness of the UAVs that they share with most devices that somehow establish communications to connect with other devices. The fact is that control algorithms (crucial for this type of machine) are developed in a fundamentally unsafe way. There is simply no systematic way for programmers to detect vulnerabilities once the software programmed is put into operation that runs in any device (car, cash point machines, mobile phones, pacemakers, etc.). Today, in our homes and offices, this weakness is a vulnerability of an average nature as developers can release a patched version of the browser, word processor or operating system (whatever the software component is) whenever they find a security shortfall; while the antivirus and intrusion detection systems can handle many other threats identified previously or not. In the specific case of the upgrading of the control software of an unmanned aerial vehicle it means that most likely, a re-certification of the entire system that controls the aerial vehicle has to be carried out (sensors, communication modules . . . ). Additionally it should be noted that the security upgrades often introduce all sorts of new vulnerabilities.
There is, therefore, a need to provide a solution that allows establishing secure and efficient unmanned vehicle control mechanisms that minimize their vulnerabilities and increase the security of the same.
The present invention establishes safe navigation control mechanisms of unmanned vehicles using new technological systems, which provide continuous technical feasibility to control aerial devices. The key points on which the solution is based are the increase of navigational safety of these vehicles (for example of UAVs), through authentication, authorization and monitoring mechanisms and the solution of the technical vulnerabilities especially in the control communications of the vehicle and in the information generated by it. All this while taking into account existing reference legislation, on the domestic, European and international level.
In this context, the concept of safety in air navigation, is intended to create links between the person who controls the UAV (pilot), the UAV and regulatory or aviation safety control bodies (which in general, herein will be referred to as Aviation Safety Agents ASA) to bestow, to the action and execution of the flight of the UAV, integrity in communications and systems that certify the concession certified by the ASA. For this, the solution proposes implementing under a secure Authentication, Authorization and Accounting (AAA) protocol, in which these three linked actions form a safe mechanism for the airworthiness of the UAVs. Strictly, by definition, the accounting made in the solution are actually contributions of traceability and therefore of real time monitoring of the UAV. The authentication process, in other words the identification of the pilot and the UAV device, will be certified by a centralized control system as well as the flight authorization. All logic verifying control of the UAV must be based on the regulations stipulated by the relevant bodies; therefore, the UAV control system proposed is totally flexible to each of the characteristics and requirements of the flight of the UAV.
These flight characteristics and requirements will be checked against the information received from the UAV, by the control system, which is able to obtain and process position or location information of the UAV both on the surface and in the airspace (an issue considered essential for not only air but also civil safety, and that is directly related to the regulations governing airspace). The downloading process of the information generated by the UAV for navigation control will be a fully automated process by means of a system hosted in the UAV device called Unmanned Aerial System (UAS), which is the functional element of the UAS that is responsible for conducting, among other things, the tasks of the UAV in the proposed control process. For example, it will collect location information (geolocation) and send it to the Centralized Control System of the UAVs (CCSU) normally belonging to an Aviation Safety Agent, for the registration of the air activity and verification of flight permits given. The CCSU is the functional element (which may be physically located on a server, for example, a server of the ASA) which is responsible for performing the tasks of centralized control of the proposed solution. Communication with the ASA (or more specifically with the CCSU), for safety reasons, can be encrypted using cryptographic security protocols of the transport layer (TLS, Transport Layer Security) or Secure Sockets Layer (SSL, the predecessor of TLS) that will provide secure communications by a network, especially Internet.
Once the process of authentication and authorization has been performed, active and passive monitoring of the flight will be carried out making temporary surveys of the aerial vehicle in flight from the CCSU (active) and the possible use of Geo-Fence technology (known mechanisms used to determine and define allowed or restricted airspace) to delineate areas of operation (passive). The latter method of monitoring can be in real time, adding a unique feature of the solution, which is that of being able to modify the limits of the air zone, setting time windows on the flight zones involved in the Geo-Fence. In other words, windows can be set with time zones and/or daily zones indicating the airspace the drone can be used in each zone. These time windows and the designated flight zone in any of them can be established, prior to the flight (e.g. by on-line connection) but they can also be modified with the drone in flight, i.e., they can be modified after the flight authorization.
Therefore, in a first aspect, the present invention proposes a method (procedure) for controlling navigation of an unmanned vehicle (for example, an unmanned aerial vehicle, UAV), wherein the method comprises:
a) establishing a communication between an electronic piloting device of the UAV called ground control station, GCS, and the UAV;
b) if the communication has been successfully established, the UAV receiving from the GCS a request to access the UAV and a GCS identifier;
c) authenticating in the UAV a user of the GCS from at least the user identifier and the GCS identifier received from the GCS (in one or more layer 2 messages of the OSI model) and if authentication has not been successful, denying access to the UAV to the user and terminating the method;
d) receiving in a server called Centralized Control System of UAVs, CCSU (usually belonging to an Aviation Safety Agent), through a mobile communications network, an UAV identifier and the user identifier;
e) authenticating in the CCSU the user and the UAV based at least on their identifiers (checking at least that such identifiers are registered in an Aviation Safety Agent as allowed) and if authentication has been successful, sending a response of successful authentication from the CCSU to the UAV and if authentication has not been successful, ending the method;
f) the CCSU receiving a request for authorization of the UAV, including the characteristics of the flight for which the UAV requests authorization, the CCSU determining if this flight is authorized and if it is authorized, sending a message of authorized flight to the UAV and monitoring the trajectory of the vehicle (in the case of the UAV, of the flight) and if it has not been authorized, ending the method;
g) if during the monitoring of the trajectory of the vehicle (in the case of the UAV, of the flight) a flight condition not allowed by the CCSU occurs (for example, detecting that the UAV enters an unauthorized flight zone), the CCSU sending a message to the UAV refusing (denying) flight authorization.
In a second aspect, the present invention proposes a system for controlling navigation of an unmanned vehicle (for example, an unmanned aerial vehicle, UAV), that comprises:
an electronic device for piloting the UAV called ground control station, GCS that comprises:
The UAV comprises:
The CCSU comprises:
Authenticating the user in the UAV can comprise:
In one embodiment, authenticating the user in the UAV also comprises the following checks:
Also, the age of the user can be calculated based at least on information stored in the database and if the user is a minor, some permitted access times will be applied to it and some specific access zones for minors.
In one embodiment, to record the user as an authorized user, the user must provide other user information and if the user does not provide this, the UAV denies it access (does not register it as an authorized user); this user information may include one of the following parameters: user's full name, postal address, ID number, passport number, date of birth or any other parameter that can be used to identify the real person behind the user. The UAV sends all information about the user to an external database to the network element. In such external database, the UAV can check if user's data is consistent with the data recorded by the user (or by other users) for other services, and if it detects any inconsistencies, it may deny authentication to the user.
Identifier of the GCS may be the Media Access Control (MAC) address or any other identifier such as for example, the IMEI, IMSI or MSIDSN among others.
In one embodiment, communications between the UAV and CCSU can be performed through the mobile communications network and reception in the CCSU the UAV identifier and the user identifier may comprise:
This same element (EIR) can receive the CCSU message that authentication is successful and send it to the UAV.
Monitoring the flight of the UAV may comprise the CCSU collecting from at least one network element of the mobile network (e.g., EIR), information on the position of the UAV (e.g., from which cell it is being served).
In one embodiment, communications between the UAV and GCS are made via a first communications network (e.g., WIFI network) and communications between the GCS and CCSU are made through the mobile communications network, and all communications between UAV and CCSU are through the GCS, so that the GCS receives messages from the UAV destined for the CCSU through the first communications network and the GCS forwards (or reroutes) them to the CCSU through the mobile communications network and vice versa (what it is received from the CCSU destined for the UAV through the mobile communications network, it is rerouted by the GCS to the UAV through the first communications network).
In one embodiment, the communications between the UAV and GCS are made through a first communications network and communications between the UAV and the CCSU are made directly (without intermediation of the GCS) through the mobile communications network.
The UAV identifier can be a unique identifier of the UAV, UAVID, made up by the UAV and that is based on at least one of the following parameters: country of manufacture, the UAV manufacturer, the UAV serial number, a verification code of the UAV and where the user identifier is a unique UVA controller identifier, NAAVI.
Communications between the GCS and the UAV are performed through a communications network (e.g., a WIFI network) and the step of establishing said communications (or in other words, establishing the communications network) comprises:
a1) receiving from the electronic device, a layer 2 message of the OSI model, requesting configuration parameters of the network, where this message includes an identifier of the electronic device (a MAC address for example);
a2) if the device identifier is registered in a database of the UAV as a device identifier with allowed access, assigning the device a set of configuration parameters of the network according to the device identification (for example, depending on an access profile assigned to it depending on the device identifier), said set of network configuration parameters including a network address for the device; if the device identifier is not registered in the database of the UAV as an identifier of a device with access allowed ending the method;
a3) sending a layer 2 message of the OSI model to the device with the configuration parameters of the network assigned to the device. All these messages are layer 2 messages of the OSI model, of the DHCP protocol.
The profile assigned in step a2) may depend on whether the device is infected by a virus and if the antivirus version installed in the device is correct.
The communications network linking the GCS and the UAV can be a WiFi, IEEE 802.15.4, IEEE 802.11, Bluetooth or other type of communications network.
The step of monitoring the flight of the UAV by the CCSU may comprise:
This navigation and position information collected the UAV, may include the mobile network base station serving the UAV.
In one embodiment, the UAV receives from the CCSU the list of authorized base stations of the mobile network, detects the base station that is serving it at each time, and if this base station is not in the list of authorized base stations, it sends a message to the CCSU informing it of this situation.
In one embodiment, if the CCSU determines that this flight is not authorized, the method comprises:
In a third aspect, the present invention proposes an unmanned vehicle (for example, an unmanned aerial vehicle, UAV) (201), comprising:
In a fourth aspect, the present invention proposes a server for control of navigation of an unmanned vehicle (for example, an unmanned aerial vehicle, UAV), comprising:
Finally, in a fifth aspect of the invention a computer program is presented comprising computer executable instructions for implementing the described method, when running on a computer a digital signal processor, an application specific integrated circuit, a microprocessor, a microcontroller or any other form of programmable hardware. Such instructions may be stored on a digital data storage medium.
For a more complete understanding of the invention, its purposes and advantages, the following descriptive report and attached drawings can be referred to.
To complete the description being made and in order to assist in a better understanding of the characteristics of the invention, according to a preferred practical embodiment thereof, that accompanies said description as an integral part thereof, there is a set of drawings wherein, by way of illustration and not restrictively, the following has been represented:
The present invention proposes a safe control system of unmanned vehicles (devices) and in particular, of unmanned aerial vehicles, UAVs. Based on the communications used for centralized and online control of unmanned aerial devices, we can distinguish three types of embodiments:
Out of Band Communications: In this case, communications for control and piloting of the UAV are established by different mechanisms, technologies or network infrastructures than used in communications established for authorization of flights, authentication of the UAV and flight safety. We can distinguish two types depending on how the process of authentication, authorization and accounting is performed, Simultaneous Method or Mobile Operator Method (OBSIM, “Out of Band Simultaneous”) or Spontaneous Method (OBSPO, “Out of Band Spontaneous”).
Communications in Semi-Band: (SBSPO, “Semi-Band Spontaneous”): Communications for monitoring and piloting the UAV are established by the same communications channel as in the flight authorization, authentication of the UAV and Flight Security, i.e., through the flight controller device by means of a WiFi tunnel—GSM/UMTS/LTE-INET-ASA, as it will be explained later. Control and piloting the UAV has its origin in the controller device while communications for authorization, authentication and monitoring are routed through the controller device to the ASA (i.e., the controller device acts as an intermediary for communications between the UAV and ASA). Controller device (also called Ground Control Station, GCS,) means the device that, by radio frequency communications with the UAV, allows the pilot to handle and pilot the UAV.
The following table shows a summary of the analysis of each solution and impact on UAVs devices as well as other elements such as network infrastructures used:
Each of these types of proposals will be explained in more detail below:
This UAV Simultaneous Control method in Out of Band Communications method (OBSIM) can be defined as a safety and control mechanism of unmanned aerial vehicles that reuses the infrastructure of the mobile telephony network (e.g., GSM or any other mobile telephony technology used). This methodology is able to control, manage and trace the flight of the aerial vehicle and the pilot. In this case, the control systems of the mobile network for authentication, authorization and accounting (VLR/HLR/EIR) are directly involved in the UAV authentication, authorization and monitoring process. The Aviation Safety Agent and mobile network systems establish a communications link to make the consultations that certify the process.
The authentication system of the aerial vehicle will be the same as that currently used in mobile devices, this authentication is done with the aerial vehicle identification (IMSI, MSIDN, IMEI, UNAS, UAV ID or any other identifier) and identification is made by the EIR (Equipment Identity Register) which is a system developed for mobile network operators to minimize the risk of fraud. The only exception in this authentication with respect to a mobile device is that for UAVs a unique identifier for the unmanned aerial vehicles is used (and built) called UAVID.
Inside the EIR is a database (DB) in which there is information on the status of the mobile phones (for example, available for using the mobile network, monitored or not available for using the network). Also, there are usually three lists: A “white” list that includes the identification of those mobile devices that are authorized to receive and make calls and optionally a “grey” list that includes identification of those mobile devices that can make and receive calls but that can be monitored to discover the identity of the user (usually using the information stored in the SIM) and a “black” list that includes identifying those mobile devices that are prevented from connecting to the mobile network.
Therefore a query to the EIR determines whether a device is approved or denied service or should be monitored. Once the EIR provides status information of a mobile device to other network nodes (MSC, AuC, HLR, etc.) these may block or not the device that is accessing or already has access to the mobile network. The EIR can offer different types of reports such as: lists of relationship IMEI-IMSI, Notifications (via e-mail, SMS . . . ), Transactions by status of devices, by list and changes of status of the device, Storage of CheckIMEI Detail Records in the Database (per each X attempts to connect, for every change of cells in the GSM network, etc.), regional, national and global black lists . . .
This UAV Spontaneous Control method in Out of Band Communications (OBSPO) can be defined as a UAV control and safety mechanism, consisting of hardware and software elements with intelligence and autonomy capable of establishing communications with the centralized navigation control system (CCSU) of the ASA through mobile communications technologies, while maintaining control of the unmanned aerial vehicle from a station or emitter using different radio frequency communications technologies. In other words, UAV—ASA communications are established using the mobile network like any other network user and therefore using e.g. a GSM/GPRS/UMTS/LTE-INET tunnel. But, the authentication, flight authorization and UAV monitoring is carried out by the ASA without using any system in the mobile network infrastructure (contrary to what occurs in the OBSIM).
Regarding communications for control of the UAV flight, in this case, two types can be distinguished:
This method of UAV Spontaneous Control in semi-band communications can be defined as a UAV security and control mechanism consisting of hardware and software elements with intelligence and autonomy able to establish communications with the centralized navigation control system (CCSU) using the same communications technology with which the control of the aerial vehicle is executed, i.e., both UAV remote control by the pilot communications and the flight control and monitoring process, will be made establishing connections via the same technology. The most common case is the use of WiFi technology for the establishment of the pilot-UAV connections (any other type of communications technology can be used) either for control of direction or height of the flight and for reception of images in the event the UAV device incorporates digital visual media that can provide images during the flight. Likewise, the WiFi device that controls the pilot (the GCS) will need to be connected to the Internet via mobile communications technology (or any other) for routing or readdressing connections received from the UAV destined for the ASA.
To carry out the proposed solution (in any of the previously discussed embodiments), due to the characteristics of the same, the incorporation of additional components (hardware and software) in the unmanned vehicle control becomes necessary. Therefore, the UAV should have additional communication capabilities (connectivity with mobile networks, and in some cases with Internet) and geographic positioning capabilities, for which it will need the following modules:
The following functions are also incorporated in the main control system of the aerial vehicle, which will articulate additional processes as preferable requirements when implementing the proposed solutions. To perform these functions, the corresponding functional elements will be necessary (software components) in the UAV:
All communications between the device and the UAV for this authentication, may be by means of layer 2 messages of the OSI model; or in other words, the authentication expounded can be done in layer 2 (link layer) of the OSI model. The identifier of the GCS may be the Media Access Address or MAC or any other identifier such as for example, the IMEI, IMSI or MSIDSN among others.
When the user registers the first time or whenever a change in the user's data occurs (in the user and password control table) and, optionally, whenever the user wants to access the UAV, information is sent to the user (this can be done by the UAV) to an external data base globally (for the management and control of users worldwide), which can be a synchronization table of users globally (SyN_USERID_WORLD).
This authentication system provides information for the authentication, authorization and monitoring process, i.e. for validation by third parties (Aviation Safety Agency) of the flight of the UAV as well as establishing a unique link with the controller device as mentioned above. This protocol is described in the patent application
In the proposed solution, the following identifiers can be used:
One of the key elements of the proposed solution is the Centralized Control System of UAVs, CCSU. This functional element is responsible for authentication, authorization and monitoring of air activity of the UAV device (or a set of them), so among other things, it will be equipped with the necessary capacities to establish secure connections with the UAVS to perform these tasks. The CCSU should be able to determine at all times the integrity, situation, flight status of the UAV together with identification of the person responsible for the flight of the UAV. As indicated, three main functions performed by this system can be distinguished:
Authentication: The process by which the CCSU is able to identify the UAV device, including its characteristics for air navigation, such as weight, flight range, maximum height of flight, communications technology to record the start of the activity of a UAV . . . Information will be provided by the UAV to the CCSU, to request verification (authentication) of UAV device identity and of the individual who will pilot it remotely or the person responsible for the flight. To perform this authentication process it will be necessary to have two identifiers of each of the identities to be verified, the UAV device identifier (UAVID) and UAV pilot identifier (NAAVI). This is not the only authentication done in the proposed solution, but rather there are at least two types of authentication, one done by the UAV of the pilot (which would be UNAS and will be explained later on) and another, mentioned in this paragraph, done by the CCSU of the UAV and of the pilot.
Authorization: The process by which the CCSU is able to authorize the flight of the UAV according to the characteristics for air navigation, either weight, flight range, maximum height of flight or communications technology, etc., in order to record the start of the activity of a UAV. The authorization process shall verify, once detected and authenticated the identity of UAV (UAVID) and the pilot of the UAV (NAAVI), whether there are the necessary and sufficient requirements for the execution of a controlled and safe flight ratified by CCSU of the Aviation Safety Agent.
Two flight authorization sequences can be distinguished:
Monitoring: The UAV monitoring process is the supervision and surveillance of the UAV and the administration of notifications to determine the status in real time of the UAV that has started a flight or not. Two types of monitoring can be distinguished depending on reactive capacity of the UAV:
Apart from these 3 functions, the CCSU will perform the functions of air navigation information or, in other words, the CCSU will be able to collect information from other authorities or third-party systems to be forwarded to the UAV that request it, for all applications that may have a positive impact on the control of the UAV. These may be among others: Design of Airspace, Air Corridors, Weather Conditions (air mass movement, etc.), Management of air congestion, Forecast elevations of land, route planning and route changes . . . This information will be sent from the CCSU to the UAV (and this may redirect it to the pilot) or it can be directly sent to the pilot.
The operation of centralized control process (also called safe control process) of the present invention for each of the solutions (embodiments) proposed will be now explained in detail. During the explanation, all the points involved in the process will be shown (in communications, piloting commands, authentication, authorization and monitoring . . . ).
The starting point for all cases will be the initialization or start-up of the UAV, and therefore the initialization of the system the latter incorporates, called UAS (Unmanned Aerial System). This system by means of the subsystem that integrates the communications and geolocation modules, with the main UAV system, will check the availability of each. For example, the following initial sequence will be executed prior to the flight authorization:
1. Verification of piloting control antenna: This action initially corresponds to the UAS of each manufacturer, as it is understood that without it, a flight cannot be made unless it is configured for automatic navigation. Generally speaking, not only the antenna but also the whole communications module that allows piloting is verified. These communications will normally be WPAN communications (Wireless Personal Area Network) but any technology can be used, such as low speed (“Low Speed Ratio”, IEEE 802.15.4), high speed (“High Speed Ratio”, IEEE 802.11), Bluetooth data link or any other type of communications technology.
The system that manages the status of modules of additional communications, that is the UAS, will also record the status of the control antenna and whatever technology (WiFi, C-band, Bluetooth, etc . . . ) checking the possibilities of connectivity that the technology has and so take into account the state of the same to establish communications not directly related to the piloting commands of the UAV.
If navigation is automatic, the flight would be made exclusively following the criterion of GPS coordinates obtained via the GPS module and consequently would pass to the next verification step of the GPS.
The FPV unit can also be checked (comprising for example a front, a rear and a mobile camera, the video transmission module . . . ) and stabilizer module (comprising various sensors providing information on flight, such as gyroscopes, accelerometers SONAR-SODAR, thermal or pressure sensors, magnetometers . . . ). The UAS also has a module for external adapters such as USB or SD (secure digital cards) which can also be verified.
2. Verification of GPS geolocation module: These actions correspond to the subsystem responsible for the integration of additional modules. As it is a receiving device, the status of GPS satellite signals will be checked to then geolocate the UAV, recording the surface position prior to the start of the flight.
3. Verification of mobile communications module: This action also corresponds to the subsystem responsible for the integration of additional modules with the main system of the UAV. It will check the status of the available mobile technology (GSM, GPRS, UMTS, LTE or whatever corresponds) in the place where the flight will start. This mobile communications establishment verification is aimed at subsequently determining the safe control method of the UAV (e.g., OBSIM, OBSPO or SBSPO) since depending on the mobile communications module status, UAV authentication, flight authorization and air navigation monitoring, can be carried out by one or another means, depending on the software and hardware characteristics of the UAV.
Notably, the subsystem may or may not be integrated by the manufacturer of UAVs in the main system that controls the UAV original hardware and that under the specifications of the solution and therefore of the regulatory body, will be able to check the status of the mobile communications and GPS modules.
Once these initial checks have been made, the authentication, authorization and monitoring of the UAV flight will be executed. This process will be done differently for each of the possible embodiments (based on the communications used for centralized control of the unmanned aerial devices) as explained above. Of course, all processes will be executed according to the rules approved by the ASA for the defined characteristics of the flight (range, height of the flight, etc.), in short, those certified in the license enabled for the UAV. The operation of the proposed solution for each of the embodiments discussed above is described below.
The following explains in more detail the functional description of the process of Security Control of UAV proposed in this invention under the out of band simultaneous communications method called OBSIM.
If for communication between the client device (the device that wants to take control of the UAV, that is, the device the pilot is going to use to control the UAV also called Ground Control Station, GCS) and the UAV, a technology that implies the establishment of a network is used (for example, WiFi technology), the secure dynamic host configuration protocol (SDHCP) will be used to provide the client device with configuration parameters of the network securely. In the rare case that establishing a network is not necessary, the client device is linked to the UAV without using this protocol. This protocol, in the initial configuration of the unmanned aerial vehicle, is disabled until the first communication is made.
Once it has established the first communication between the client device and the UAV for the initial configuration, the SDHCP is automatically enabled and this will record the information from the client device and will automatically add it to the DB like a device with authorized access. In an alternative embodiment, this information (of authorized access devices) is added to the database by a system administrator and, therefore, this initial SDHCP configuration in the UAV will not be made by the client device.
Once the aerial vehicle is configured, whenever this or any other device wants to access the control of the UAV (and it is necessary to establish a communication network such as WIFI) it will have to pass the SDHCP mechanism.
As shown in
In the event that the identifier of the client device was in the table of registered devices (and it is not in the table of devices with access denied, if this table exists), the SDHCP server would see in the table which network configuration parameters correspond to it and would send them (or would send the device a group of possible values of parameters and the device would choose which ones it prefers in this group of possible values). In one embodiment, this process is done by assigning an access profile to the client device, obtained from the database according to the identifier of said device and assigning the device a set of network configuration parameters based on the access profile assigned to it, said set of network configuration parameters including a network address for the device, where said network address belongs to a range of network addresses available for the device that depends on the access profile assigned to it. Therefore, these profiles will determine the network address available to the client device and therefore their communication capacities. More details on the operation of SDHCP mechanism are described in patent application PCT/ES2015/070422.
The client devices can be computers, tablets, PCs, mobile phones, smartphones, laptops and generally any computer electronic equipment or device that can connect to a communications network. In one embodiment, the identifier used in the database to indicate which device has access to the network is at least the MAC address of the device. However, in other embodiments, other parameters may be used to identify the client device such as, for example, the IMEI, IMSI or MSIDSN.
Once the link has been established and activated from the device (200) and the UAV (201) (using the SDHCP protocol if it has been necessary to use this protocol to establish the communications link between the client device and the UAV because the client device used for example a WIFI network to connect to the UAV), the authentication process will take place in the universal authentication (UNAS) module. During the initial configuration of the proposed system (when the user first logs on), the first requirement is the creation of the user network access authentication identifier or NAAVI, which identifies the user (the pilot), and is used to establish the link (association) between the user (100), client device (200) and UAV (201).
The universal authentication module (UNAS) stores in a database all information of potential users of the UAV, which includes at least the NAAVI identification of the user and a password for that user. Normally, additionally another type of information is included such as date of birth, personal identification number (ID number or similar), e-mail address, among others. In addition, the link between the NAAVI identification of the user and the device (or devices) that the user is going to use is made. That is, the identification of the device or devices (GCSs) said user is going to use appears for each user identifier (NAAVI). All these data (including the link) can be entered manually in the UAV by a system administrator or provided by the user in communication with the UAV during its initial configuration. Even the link can be made automatically by the UNAS of the UAV, during the initial configuration, linking the user to the device that the user is accessing in this initial configuration. It is necessary to add the user in the UNAS module (or more particularly, in the UNAS database module called NAAVI module), because if the user is not created it will not be allowed access to the UAV.
Once the user is configured in the UNAS module, the user will also be linked to the SIM card, eSIM or any other virtual card that uses the UAV for mobile communications, and if user authentication is positive and it has access to the UAV, this access information will be sent together with the configuration parameters (including for example, the IMSI or the MSISDN) of the SIM card, eSIM or any other virtual means, to the air control bodies or ASAs (EASA, EASA, FEE, etc.).
As indicated, the NAAVI user identifier, links not only the password but also other data that allow identifying the identity of the actual person who is really behind that user (date of birth, personal identification number (ID card or similar), e-mail address . . . ). All this data, used by the user for this and other services, may appear in a global user synchronization table (SyN_USERID_WORLD). Therefore, as part of the initial authentication process, the user identifier and the user data provided can be tracked in these global tables, obtaining the actual person behind that username and detecting any inconsistencies in the data, which may be indicative of fraud. In this case, registration of that user would not be allowed or, in other words, authentication would be negative. That is, as part of the authentication, it can be checked that the user is who they claim to be.
After carrying out the initial configuration, each time a user wants to gain control of the UAV (once the SDHCP mechanism has been passed if necessary) authentication of it will be made in the UAV (specifically in the UNAS module).
When the UAV receives from a client device a piloting request message (or other words, for control or access to the UAV), once the SDHCP has been passed if it is necessary (because if the SDHCP denies access, a communication between the client device and the UAV cannot be established and, therefore, cannot send a control request message), the UAV will request user identification (NAAVI) from who is accessing and their password. In an alternative embodiment, this information may be already included in the access request message so it will not be necessary to ask the user for it. When the user sends its identification and the password, the UNAS module of the UAV will check whether the user (identification) is registered in the database (NAAVI module) and whether the password provided is correct. If any of these checks are negative, the process will not continue, it will determine that authentication has not been successful and, therefore, the user will be denied access.
In one embodiment, there is a table with denied user identifiers and the first thing done is to check whether the identifier of said user is in the table, and if so, the authentication is deemed unsuccessful and the process will not continue.
These messages exchanged between the UAV and the client device (GCS) (for example the piloting request) may be 2 layer messages of the OSI model.
Then it checks the link between the user and the device it is accessing. For this, the UAV checks that the device (100) that is being used, is registered in the corresponding database (of the UNAS module) as linked to the user who is requesting control of the UAV (or in other words, access to UAV). If the user is not linked to the device for which it has requested access, the authentication process will not continue and it cannot access. If the user is linked to the device, the authentication process will continue. If there are no further steps in the authentication process, it will have been successful and the user will be given access to the UAV.
In an alternative embodiment, authentication may be more complex and include more stages. For example, it can be checked if the date and time of access is allowed for the user (the module NAAVI will include information on the date and time allowed for each user for this) and/or it can be checked whether the user has fully or partially restricted (in these zones) access due to security policies or depending on a profile that is assigned to it (e.g., quarantine, parental control . . . ). These and other possibilities for additional authentication are described in patent application PCT/ES2015/070421.
UAVs not using WiFi technology (or other technology that requires the establishment of a network) to communicate with the controller device, do not need to apply the SDHCP protocol as no network is established. This can happen in automated flights since no control of the UAV is required during the flight if the parameters are configured prior to the flight and, therefore, there is no need to establish a communication network between pilot and UAV. However, UNAS authentication will always be applied to manage the user (regardless of whether SDHCP was previously used to communicate or not).
As it has been explained so far, in the first initial configuration, the SDHCP and UNAS safety parameters of access to the UAV are configured among other things. When the user wants to access the UAV to make it fly, in addition to passing the security checks of the SDHCP (if necessary) and UNAS, it will have to proceed to requesting the flight authorization. The diagram shown in
The next step is that the base station sends the UAV and user identification used, to the network nodes of the mobile network. Said mobile network can be of any type, for example, GSM, GPRS, UMTS, LTE, 5G, 6G, etc. For the GSM network, the network elements that can receive identification of the UAV (through the MSC node) are the HLR (205), VLR (206), AuC (204) that check the data of the SIM card, eSIM or other virtual card, as well as the user (NAAVI). In other words, these nodes carry out a standard authentication of a mobile device, but also use pilot identifiers (NAAVI) to identify the identity and integrity of the pilot. That is, these nodes make a normal mobile network authentication (as to any other mobile telephone in the mobile network) of the SIM the UAV has; but also they can have a database linking the values of the IMSI, MSIDSN with the user identifier (NAAVI) and in addition to make a normal authentication, they can check that said link is correct. The equipment identity register database (EIR) (207) also receives these parameters and records and checks the registration number of the UAV (UAVID). That is, the EIR verifies the identity of the UAV (which will play the role of the IMEI of the mobiles); each UAV must be registered in the EIR database, if a UAV is not registered in this DB it cannot fly as, the EIR would not grant access and it could not request flight authorization. In addition to authenticating the mobile service and authenticating the equipment and user in the mobile network, it is also authenticated in the Aviation Safety Agent, ASA,
The ASA (260) has registered each and every one of the UAVs that are authorized. This record includes three sub-records or sub-databases, which are:
The EIR will send the information it has of the UAV, to the CCSU in the ASA, so that the information can be checked against the authentication record of the ASA. If the authentication process is successful, the CCSU will send the notification to the UAV to continue the process with the authorization to fly, in which the ASA will verify the flight conditions for the UAV requesting authorization. This information will be checked against the flight authorization database, which records flight privileges, characteristics of the UAV, restricted or demarcated flight zones or any other condition or requirement defined by the ASA. If this second verification is positive, the CCSU will send a message to the UAV (via the mobile network) authorizing the flight.
After this, in the first communication ASA-UAV (via the mobile network), ASA will provide all ranges of base stations (i.e., a list of identifiers of base stations or cells) of the area of influence of the UAV (the zone where the flight of said UAV is authorized), that we can say are the “authorized” base stations. If for example the UAV belongs to the Region of Madrid, it will only have flight authorization in this Region, except for the perimeter of government buildings, military bases and/or any other protected building. When the UAV needs to fly in a zone that does not belong to the initial zone it has permission for (such as outside its autonomous region), it will be communicated to the ASA and this may authorize or deny the flight.
When the UAV already has flight authorization and is ready to fly. The UAV by means of its mobile communications module will detect the base station it is serving at all times (for example, the base station it receives with the most power). To detect the serving base station, the UAV will follow the known procedure for any normal mobile telephone. As the UAV moves location, it can change the base station it is connected to (is serving). For the first serving base station and each time it changes serving base station, the UAV will check if this BTS is in the list of “authorized” BTSs. If it is not, the UAV will notify the ASA and if the ASA sees that it is a station in the vicinity of which it does not have permission to fly (for example, because the UAV has moved to a base station that is close to the perimeter of a government building, military base and/or any other building that it does not have permission to fly over), the flight will be denied in said airspace. In this situation, the UAV will remain parked in the place where it is or will return to its origin. Normally, to prevent the user (pilot) from ignoring the denial of the flight, at the time the UAV receives the message from the ASA denying the flight, the UAV will stop or return to origin, regardless of the orders of the pilot (i.e., the UAV will ignore the pilot's instructions if they are contrary to this order received from ASA (from the CCSU)).
In general, flight information is automatically sent to the ASA (either periodically, when the base station is changed or in the vicinity of an unauthorized zone), and the ASA could change the status of the UAV to monitored flight or to non-authorization of flight.
An example of the type of parameters received by the UAV, from the base station (e.g., a BTS) that it detects, is set forth in the following table.
The following explains in more detail the functional description of the process of Security Control of UAV proposed in this invention under the out of band spontaneous communications method called OBSPO. This method is characterized by establishing communications with Centralized Control Systems of UAVs by means of data connections using the mobile communications module (GSM, GPRS, EDGE, UMTS, HSDPA, LTE., etc.) integrated in the UAS and that will provide the connectivity to the UAV with Internet and consequently with the CCSU.
Once the UAS and the system incorporating the GCS (Ground Control System) have started, the control process will begin with the first communications (300) for establishing the UAV-Pilot link for manual piloting of the aerial vehicle (using the different systems provided by the UAV manufacturer).
In this method, the SDHCP mechanism (if for communication between the controller device and the UAS is necessary to establish a communication network) and the UNAS authentication mechanism, described for the previous embodiment, will also be used. During the initial configuration, the SDHCP and UNAS safety parameters for accessing the UAV will be configured and whenever the user wants to establish a communication network with the UAV or wants to access it, the controls defined in SDHCP and UNAS will be applied. The operation of such mechanisms, described for the OBSIM method also applies to this method.
The various systems of communications between the pilot and the UAV, are distinguished by the different radio frequency communications technologies used (WiFi, Bluetooth Data Link, FHSS, or any other . . . ). The type of technology used for these communications (to establish the manual control links between the pilot and the UAV) does not form part of the object of this invention and poses no prerequisite or condition affecting the OBSPO safe control method.
UAV normally incorporate a digital video camera with the corresponding FPV transmission module. Video transmission (301) to the FPV display device, housed in the GCS (although sometimes the display device may be external), can be by high-speed radio frequency. Like the communications for manual piloting of the UAV, these communications are independent of the solution or OBSPO method.
When the UAS has been initialized, the location module (GPS in the example of the figure although any other known geo-location system can be used) will allow the UAV to position itself geographically because it receives signals from global positioning satellites (GPS) (302). The information will be collected by the UAS for later use by the CCSU, responsible for analysing the positioning data for the various control functions.
Once the identifier of the UAV (UAVID) has been built by the UAS and the pilot identifier stored (NAAVI) (303) in the UAS, the UAV will establish communications (304) with the CCSU (which may belong to a certified operator such as the company TECTECO), specifically with the Authentication Agent, so that the UAV and pilot information are checked against the records of the ASA (305). As explained above, the information that is linked to each user identifier (pilot), allows verifying (in external global databases) the real identity of the pilot, i.e. it allows guaranteeing the integrity of the pilot of the UAV, verifying that the individual is who he says.
If the authentication process is successful, the CCSU will send the notification to the UAV to continue the process with the flight authorization (306), in which the ASA will verify flight conditions for the UAV requesting authorization. This information is crosschecked with the databases of records flight privileges, characteristics of UAV, restricted or confined areas of flight or any other condition or requirement defined by the ASA (307). Compliance with the requirements means that the UAV has sufficient privileges to start flying and thus the process of active and passive monitoring of the UAV (308) will begin in which the exchange of information relating to the conditions of the flight, pilot, UAV, UAS, GCS, or any other element involved in the flight, can be analysed by the CCSU. Events and activity records stipulated by the legal conditions of the ASA will be stored in the DB of the CCSU designed for this purpose (309). In certain embodiments (which, for example, use the OBSIM method) as part of this active monitoring, the UAV can tell the CCSU which base station it is connected to (is serving).
The following explains in more detail the functional description of the process of Safe Control of UAV proposed in the present invention under the semi-band spontaneous communications method called SBSPO. This method is characterized by establishing communications with Centralized Control Systems of UAVs (CCSU) by means of data connections using the mobile communications module (GSM, GPRS, EDGE, UMTS, HSDPA, LTE or any other mobile technology used) incorporated in the user device (GCS) or FPV device.
Once the UAS and the system incorporating the GCS (Ground Control System) have started, the control process will begin with the first communications (400) for establishing the UAV-Pilot link for manual piloting of the aerial vehicle by the different systems provided by the UAV manufacturer.
In this method, the SDHCP mechanism (if for communication between the controller device and the UAS it is necessary to establish a communications network) and the UNAS authentication mechanism, described for OBSIM embodiment, will also be used. During the initial configuration the SDHCP and UNAS safety parameters for accessing the UAV will be configured and whenever the user wants to establish a communication network with the UAV or wants to access it, the controls defined in SDHCP and UNAS will be applied. The operation of such mechanisms, described for the OBSIM method also applies to this method.
The various systems of communications between the pilot and the UAV, are distinguished by the different radio frequency communications technologies used (WiFi, Bluetooth Data Link, FHSS, or any other . . . ). The type of technology used for these communications does not form part of the object of this invention and poses no prerequisite or condition affecting the SBSPO safe control method.
Video transmission (401) to the FPV display device, housed in the GCS (although sometimes the display device may be external), can be by high-speed radio frequency. For the specific case of this solution, the communication channels used to establish the manual control links or communication with the GCS may be the same as those that establish the data connections with the CCSU. This is possible because the GCS incorporates a mobile technology communications module via which connections of exclusive data of the safe control process of the UAV (403) can be routed/readdressed/tunnelled. That is, the GCS is used as an intermediary between the UAV and the CCSU, so that although the UAV does not have access to the mobile network, it can communicate with the CCSU. For this, the messages received by the GCS by the UAV (via for example a WiFi or Bluetooth network) destined for the CCSU, the GCS transmits them to the CCSU using the mobile network and vice versa, thus establishing a communication tunnel between the UAV and the CCSU. The GCS can do this routing of connections it receives from the UAV to the CCSU (and vice versa), by NAT forwarding (Network Address Translation), i.e., translating the private IP address of the communications network between the UAV and the GCS (which has been assigned using the SDHCP protocol) to the public IP address used in the mobile network that communicates the GCS and the CCSU. Having obtained such end-to-end connectivity between the UAV and the CCSU, this SBSPO method is similar to those that use direct communication between UAV and CCSU (such as OBSPO).
When the UAS has been initialized, the location module (GPS in the example of the figure although any other known geo-location system can be used) will allow the UAV to position itself geographically because it receives signals from global positioning satellites (GPS) (402) satellites. The information will be collected by the UAS for later use by the CCSU, responsible for analysing the positioning data for the various control functions.
The identifier of the UAV (UAVID) will be built in the UAS (404) while the pilot identifier (NAAVI) (405) will be validated and duly recorded in the system, which incorporates the UAV, of the previously described UNAS authentication. The UAV can establish communications with the CCSU thanks to the re-routing (tunnelling) of connections in the GCS (406), specifically first with the authentication agent of the ASA, so that the information of the UAV and pilot are checked against the ASA records (407).
If the authentication process in the CCSU is successful, the CCSU will send the notification to the UAV, tunnelling communications by the GCS, to continue the process with the flight authorization (408), in which the ASA will verify flight conditions for the UAV which requests authorization. This information is crosschecked with the databases of records flight privileges, characteristics of UAV, restricted or confined areas of flight or any other condition or requirement defined by the ASA (409). Compliance with the requirements means that the UAV has sufficient privileges to start flying and thus the process of active and/or passive monitoring of the UAV (410) will begin in which the exchange of information relating to the conditions of the flight, pilot, UAV, UAS, GCS, or any other element involved in the flight, can be analysed by the CCSU. Events and activity records stipulated by the legal conditions of the ASA will be stored in the DB of the CCSU designed for this purpose (411).
Having explained the operation of the safe control process of the present invention for each of the embodiments (communications options) proposed, the process carried out in the Centralized Control System of UAVs, CCSU, will be explained in greater detail, and the relationship between the different flows of information to be stored and collated; this will help to get a better idea of the functioning of the overall system. For this,
One of the first actions carried out in the control process of the UAV is the construction by the UAV (or more specifically by the UAS) of the identifier of the UAV, called UAVID (600). Additionally, the UAV will have registered the unique user identifier or controller, called NAAVI (601). The UAV will send these identifiers to the CCSU (603) through the different communications methods (OBSPO, OBSPO and SBSPO) for verification regarding the user/controller/pilot of the UAV and identification of the UAV previously registered when prosecuting the flight licence in the ASA. In the event that the OBSIM method is used, the EIR will send to the CCSU authentication agent, the identifiers registered in the mobile services provider network (604). Subsequently the CCSU authentication agent looks up in the database of the licences registered by the ASA (605) in which the characteristics of the UAV and privileges of the user/controller of the UAV have been registered. After verifying the identity of the UAV device and User/Controller, the CCSU authentication agent sends a response directly to the UAV (OBSPO and SMSPO option) or to the EIR (OBSIM option) indicating whether the authentication process has been successful (606).
The next step in the process is the flight authorization. For this, the UAS sends a flight authorization request (607) to the CCSU authorization agent (who has all the information on the characteristics and permissions for each UAV). In the OBSIM case, the authorization request is sent directly from the UAV to CCSU using the mobile network (during the process the CCSU may have to consult the EIR, if there is any data that needs identification of the UAV that is stored in the EIR).
The CCSU, will collate the information with records from the database of licences processed by the ASA (608) in which flight conditions have been stipulated based on the characteristics of the UAV, legal air navigation conditions and whatever the requirements of the flight to be made. In addition, the authorization agent of the CCSU will make a query in the database that has registered the exclusive flight zones (609) for each user/controller/pilot and those restricted to any type of flight. Additionally, the conditions of the flight will be checked with the conditions at that time of other flights that are being monitored to avoid potential conflicts in the airspace (610). The information with the characteristics of the flight authorization will be sent to UAV (611) by the UAS to be able to process flight information. In the authorization process, the flight may be also denied due to other safety reasons registered in the DB (Database) of events of the CCSU, such as publication of static image and dynamic image contents, theft or loss of the UAV, modification of the preloaded GPS map, altered weight of the aerial vehicle, modification UAVID or NAAVI or any other requirements and conditions set by the ASA.
Once the authorization process is completed, i.e. the conditions for the start of flight are met, the process of active and/or passive monitoring will start. The active monitoring process is the one in which the UAS sends the information temporarily of the flight to the monitoring agent of the CCSU (612), while the passive monitoring process (613) uses surveys programmed to determine the status of the UAV, from the monitoring agent of the CCSU (in OBSPO and SMSPO methods) or from the own infrastructure of the mobile technology services provider (OBSIM methods). All information collected by the monitoring agent of the CCSU or by the network operator is registered in the DB of flight events and information of flights made by the UAV (614). It should be noted that the information is processed by the CCSU (615) and further decisions may be made in real time such as the denial of a previously authorized flight, changing authorized flight zones, etc. That is, if during the monitoring process the UAV enters an area that is classified in the database as not allowed, the CCSU will send a denial of authorization to the UAV. In this situation, the UAV will remain parked in the place where it is or return to its origin.
The present invention therefore proposes a methodology (mechanism) of safe control of unmanned aerial vehicles based on authentication, authorization and monitoring of UAVs. Currently, there are no methods to establish safe and efficient control mechanisms of Unmanned Aerial Vehicles, in the way the proposed solution does and that meet the recently approved legislation by the various agencies of air navigation control to minimize their vulnerabilities and increase their safety. The main technical advantages of the proposed methodology are, among others:
Although the present invention, in most embodiments, has been described for application in unmanned aerial vehicles (with permitted and restricted air zones), that is only an application example. The mechanism described in the present invention is also applicable to other types of unmanned aerial or remotely manned vehicles, such as unmanned road vehicles or maritime vehicles (in that case, instead of air zones we would speak of land or maritime zones respectively) or of any other kind.
Note that in this text, the term “comprises” and its derivations (such as “comprising”, etc.) should not be understood in a sense of exclusion, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc.
Some preferred embodiments of the invention are described in the dependent claims, which are included below.
Having sufficiently described the nature of the invention and the way it can be carried out in practice, it should be noted that there is the possibility that the different parts can be manufactured in a variety of materials, sizes and shapes and may also allow for the introduction in its constitution and procedure, those variations that practice recommends, as long as the same do not alter the fundamental principle of the present invention.
The description and drawings merely illustrate the principles of the invention. Therefore, it should be noted that those skilled in the art may conceive various provisions which, even if not explicitly described or shown herein, represent the principles of the invention and are included within its scope. In addition, all examples described herein are provided primarily for pedagogical reasons to help the reader understand the principles of the invention and the concepts contributed by the inventor(s) to improve the technique and should be considered as non-limiting with respect to such examples and conditions described specifically. Furthermore, all the foregoing in this document related with the principles, aspects and embodiments of the invention, and specific examples thereof, cover equivalents thereof.
Although the present invention has been described with reference to specific embodiments, those skilled in the art should understand that the foregoing and various other changes, omissions and additions in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the following claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/ES2015/070655 | 9/9/2015 | WO | 00 |
