Improved unmanned aerial vehicle (UAV) management

Abstract

The present disclosure is related to network nodes and methods for improved UAV management A method at a first network node for UAV management comprises: determining whether or not a User Equipment (UE) is a UAV above ground; and triggering one or more operations for managing the UE in response to determining that the UE is a UAV above ground.

Description

[0001] IMPROVED UNMANNED AERIAL VEHICLE (UAV) MANAGEMENT

[0002] Technical Field

[0003] The present disclosure is related to the field of telecommunications, and in particular, to network nodes and methods for improved unmanned aerial vehicle (UAV) management.

[0004] Background

[0005] Unmanned Aircraft or Uncrewed Aircraft (UA), also known as drone, technology has significantly evolved in the last decade, and UA manufacturers have been providing affordable solutions to consumers. Such evolution has opened the opportunity for many enterprises to consider employing UA to support their operations. The growth potential of commercial UA is expected to increase, with the ability to control the UA from a control room instead of a standard Ground Control Station (GCS) connected using short-range communication. The true potential for commercial UA can only be realized by Beyond Visual Line of Sight (BVLOS, sometimes referred to simply as Beyond Line of Sight), but most of these operations cannot be conducted safely with unlicensed spectrum.

[0006] Due to the Increasing number of UA operations, regulators recognize that most UA should be electronically identifiable for safety and security reasons. However, rogue drones might ignore or circumvent regulations, and therefore the identification of UA is particularly needed to identify and defense against rogue drones, in order to prevent unauthorized operations in restricted airspace, to address suspicious operations near sensitive facilities, and to increase airspace awareness. During the past few years, citizens and law enforcement have been concerned that UA were flying in unauthorized areas or they were infringing upon individual privacy; therefore, regulators and operators needed a mechanism to be able to detect and manage a UA (e.g., in term of the radio resources allocated thereto). In order to address those concerns, a real time ability to identify UA in the local airspace is needed at any time. In later phases, such identification can support the basic functionalities for coordination of UA flights in Unmanned Aircraft System (UAS) Traffic Management (UTM); approving flights and collision avoidance; plans ahead of each flight and avoiding conflicting flight plans allowing for modification

[0007] Summary

[0008] Differentiating rogue drones using cellular network resources from legitimate (or registered) users (e.g., mobile phones, drones, or the like) to shut down its specific resources is currently not possible. For example, in a scenario shown in Fig. 1, both a registered (and therefore, legitimate) drone 100 and a rogue drone 101 are present in a big public event in which a lot of users participate with their User Equipments (UEs) 120 such as mobile phones. During such a big public event, a no-fly zone can be installed with few exemptions for dedicated drones. Any rogue drone (e.g., the rogue drone 101) entering the no-fly zone should be identified and its resources should be shut down to force the drone into its save-landing maneuver by the responsible security authorities (e.g., as the “shield” shown in Fig. 1). Legitimate drones (e.g., the registered drone 100) and visitors of the event (e.g., the users / UEs 120) should not be affected.

[0009] A measure against rogue drones operated over Wi-Fi is jamming the Wi-Fi spectrum. However, this is not an option for drones operated over cellular networks. Switching off a whole cell to cut connectivity is undesired as this terminates legitimate services as well and causes very unsatisfied users, if not even panic, due to the loss of connectivity.

[0010] The 3rdGeneration Partnership Project (3 GPP) feature Minimization of Drive Test (MDT), introduced in Release 10, enables the collection of field measurements from the user equipment (UE) with the aim to reduce the need for dedicated drive tests to operate and maintain the network. This feature cannot be used to differentiate between a rogue drone and legitimate users, as the collection of the respective data would require user consent, which is hard to collect. Further, missing user consent is not a valid indicator to consider users as rogue users. Otherwise, this would force everybody in consenting, as not consenting would result in resource withdrawal.

[0011] Another hurdle to shutdown drones is the separation of Radio Access Network (RAN) and user identity information for privacy reasons. This makes it impossible to match radio resources to the users and shutdown these selected resources even when a rogue drone was already detected.

[0012] To address or at least partially alleviate one or more of the above issues, some embodiments of the present disclosure are provided.

[0013] According to a first aspect of the present disclosure, a method at a first network node for UAV management is provided. The method comprises: determining whether or not a UE is a UAV above ground; and triggering one or more operations for managing the UE in response to determining that the UE is a UAV above ground. Further, some other embodiments of the first aspect are described below in the Detailed Description.

[0014] According to a second aspect of the present disclosure, a first network node is provided. The first network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the first network node to: determine whether or not a UE is a UAV above ground; and trigger one or more operations for managing the UE in response to determining that the UE is a UAV above ground. In some embodiments, the instructions, when executed by the processor, cause the first network node to further perform any of the methods of the first aspect.

[0015] According to a third aspect of the present disclosure, a method at a second network node for facilitating a first network node in Unmanned Aerial Vehicle (UAV) management is provided. The method comprises: providing the first network node with one or more radio fingerprints to enable the first network node to determine whether or not a User Equipment (UE) is a UAV above ground based on at least the one or more radio fingerprints and a set of radio measurement data associated with the UE. Further, some other embodiments of the third aspect are described below in the Detailed Description.

[0016] According to a fourth aspect of the present disclosure, a second network node is provided. The second network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the second network node to: provide a first network node with one or more radio fingerprints to enable the first network node to determine whether or not a UE is a UAV above ground based on at least the one or more radio fingerprints and a set of radio measurement data associated with the UE. In some embodiments, the instructions, when executed by the processor, cause the second network node to further perform any of the methods of the third aspect.

[0017] According to a fifth aspect of the present disclosure, a computer program comprising instructions is provided. The instructions, when executed by at least one processor, cause the at least one processor to carry out any of the methods of any of the first aspect and the third aspect.

[0018] According to a sixth aspect of the present disclosure, a carrier containing the computer program of the fifth aspect is provided. In some embodiments, the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0019] According to a seventh aspect of the present disclosure, a telecommunication system is provided. The telecommunication system comprises: one or more first network nodes of the second aspect; and one or more second network nodes of the fourth aspect.

[0020] With some embodiments of the present disclosure, operators and / or security authorities (or other legally entitled organizations) can identify / detect rogue drones (for example, by using the Drone Detection & Defense Service (DDDS) 110 that will be described in detail below), and protect events and / or facilities (e.g., festivals, football games, airports, or military facilities) from the identified rogue drones, for example, by disconnecting the rogue drones from its remote pilots and forcing the rogue drones to land (for example, by using the DDDS 110 that will be described in detail below).

[0021] Further, with the solutions in some embodiments of the present disclosure, the identification of and protection against rogue drones can be implemented by using legitimate information on hand, such as, Received Signal Strength Indicator (RSSI) and / or Reference Signal Received Power (RSSP) for handover. In other words, unlike the MDT, no additional user consent is required, and therefore information can be easily extracted and acted on in line with privacy regulations.

[0022] Brief Description of the Drawings

[0023] The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and therefore are not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings.

[0024] Fig. l is a diagram illustrating an exemplary scenario in which improved UAV management is applicable according to an embodiment of the present disclosure.

[0025] Fig. 2 is a diagram illustrating an exemplary system for improved UAV management according to an embodiment of the present disclosure.

[0026] Fig. 3 is a flow chart illustrating an exemplary method for improved UAV management according to an embodiment of the present disclosure.

[0027] Fig. 4 is a flow chart illustrating an exemplary method at a first network node for UAV management according to an embodiment of the present disclosure.

[0028] Fig. 5 is a flow chart illustrating an exemplary method at a second network node for facilitating a first network node in UAV management according to an embodiment of the present disclosure.

[0029] Fig. 6 schematically shows an embodiment of an arrangement which may be used in network nodes according to an embodiment of the present disclosure.

[0030] Detailed Description

[0031] Hereinafter, the present disclosure is described with reference to embodiments shown in the attached drawings. However, it is to be understood that those descriptions are just provided for illustrative purpose, rather than limiting the present disclosure. Further, in the following, descriptions of known structures and techniques are omitted so as not to unnecessarily obscure the concept of the present disclosure.

[0032] Those skilled in the art will appreciate that the term “exemplary” is used herein to mean “illustrative,” or “serving as an example,” and is not intended to imply that a particular embodiment is preferred over another or that a particular feature is essential. Likewise, the terms “first” and “second,” and similar terms, are used simply to distinguish one particular instance of an item or feature from another, and do not indicate a particular order or arrangement, unless the context clearly indicates otherwise. Further, the term “step,” as used herein, is meant to be synonymous with “operation” or “action.” Any description herein of a sequence of steps does not imply that these operations must be carried out in a particular order, or even that these operations are carried out in any order at all, unless the context or the details of the described operation clearly indicates otherwise.

[0033] Conditional language used herein, such as "can," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and / or states. Thus, such conditional language is not generally intended to imply that features, elements and / or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and / or states are included or are to be performed in any particular embodiment. Also, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list. Further, the term "each," as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term "each" is applied.

[0034] The term “based on” is to be read as “based at least in part on.” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment.” The term “another embodiment” is to be read as “at least one other embodiment.” Other definitions, explicit and implicit, may be included below. In addition, language such as the phrase "at least one of X, Y and Z," unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof.

[0035] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limitation of example embodiments. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and / or “including”, when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. It will be also understood that the terms “connect(s),” “connecting”, “connected”, etc. when used herein, just mean that there is an electrical or communicative connection between two elements and they can be connected either directly or indirectly, unless explicitly stated to the contrary.

[0036] Of course, the present disclosure may be carried out in other specific ways than those set forth herein without departing from the scope and essential characteristics of the disclosure. One or more of the specific processes discussed below may be carried out in any electronic device comprising one or more appropriately configured processing circuits, which may in some embodiments be embodied in one or more application-specific integrated circuits (ASICs). In some embodiments, these processing circuits may comprise one or more microprocessors, microcontrollers, and / or digital signal processors programmed with appropriate software and / or firmware to carry out one or more of the operations described above, or variants thereof. In some embodiments, these processing circuits may comprise customized hardware to carry out one or more of the functions described above. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

[0037] Although multiple embodiments of the present disclosure will be illustrated in the accompanying Drawings and described in the following Detailed Description, it should be understood that the disclosure is not limited to the disclosed embodiments, but instead is also capable of numerous rearrangements, modifications, and substitutions without departing from the present disclosure that as will be set forth and defined within the claims.

[0038] Further, please note that although the following description of some embodiments of the present disclosure is given in the context of the Open RAN (O-RAN) architecture, the present disclosure is not limited thereto. In fact, as long as UAV management is involved, the inventive concept of the present disclosure may be applicable to any appropriate communication architecture, for example, to Global System for Mobile Communications (GSM) / General Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Time Division - Synchronous CDMA (TD-SCDMA), CDMA2000, Worldwide Interoperability for Microwave Access (WiMAX), Wireless Fidelity (Wi-Fi), Long Term Evolution (LTE), 5thGeneration New Radio (5GNR), 6G, etc. Therefore, one skilled in the arts could readily understand that the terms used herein may also refer to their equivalents in any other infrastructure. For example, the term “UE” used herein may refer (but not limited) to a terminal device, a mobile device, a mobile terminal, a mobile station, a user device, a user terminal, a wireless device, a wireless terminal, an Internet of Things (loT) device, a vehicle, a drone, a UAV, or any other equivalents. For another example, the term “network node” used herein may refer (but not limited) to a Baseband Unit (BBU), a base station, a base transceiver station, an access point, a hot spot, a NodeB (NB), an evolved NodeB (eNB), a gNB, a network element, a network node, a network function, an access network (AN) node, a core network (CN) node, a Service Management and Orchestration (SMO) node, an application server, an application function, or any other equivalents. rApps are software applications defined by O-RAN to automate RAN management and optimization by control loops with a time scale of one second and longer. These applications enable service management and orchestration (SMO). xApps (extended Apps) are software applications within the O-RAN architecture to implement specific functions in near-real time.

[0039] As mentioned earlier, differentiating rogue drones using cellular network resources from legitimate users to shut down its specific resources is currently not possible, or at least not possible without additional user consent which is difficult (if not impossible) to obtain in practical.

[0040] Therefore, to address or at least partially alleviate one or more of the above issues, some embodiments of the present disclosure are provided.

[0041] In some embodiments, a Rogue Drone Detection and Defense functionality is provided, which allows responsible security forces to identify drones and shut them down by disconnecting them from the wireless / radio network. In some embodiments, in an additional process, legitimate drones could be registered to be exempted from such counter measures.

[0042] Fig. 2 is a diagram illustrating an exemplary system 20 for improved UAV management according to an embodiment of the present disclosure. As shown in Fig. 2, to detect a rogue drone and disconnect it, data from multiple sources may be combined. For example, each UE (e.g., the UEs 120, the Registered Drone 100, or the Rogue Drone 101) may report its measured Received Signal Strength Indicators (RS Sis) or, depending on RAN configuration, Reference Signal Received Power (RSRP) values towards the RAN / baseband unit (BBU) (e.g., the BBU 210-1 in CSP 1 200-1 and / or the BBU 210-2 in CSP 2 200-2) to enable handover. In some embodiments, the BBU(s) can report these indicators to the Access and Mobility Management Function (AMF) in 5G stand-alone (SA) (e.g., the Core 220-1 and / or the Core 220-2), to the Mobility Management Entity (MME) in 4G and 5G non-stand-alone (NSA) (e.g., the Core 220-1 and / or the Core 220-2), or to the Service Management and Orchestration (SMO) component (e.g., the SMO 230-1 and / or the SMO 230-2), which is defined by O-RAN. Within the SMO component the reports may be collected via rApps / xApps (e.g., the xApps 231-1, xApps 231-2, rApps 233-1, and / or rApps 233-2) and exposed by the communication service provider (CSP) (e.g., the CSP 1 200-1, the CSP 2 200-2, and / or other CSPs 200-3) via an exposure platform (e.g., the Service Exposure Platform 240-1 and / or the Service Exposure Platform 240-2).

[0043] In some embodiments, the core is able to uniquely identify the subscription associated with the drone. This is because, in RAN, things are rather “anonymous”. In some embodiments, only the core has the information required to decide if a drone is pre-registered “friendly” and only the core can de-tach a rogue drone. Measurements can be used to figure out “this is likely a rogue drone” but then the core together with RAN need to determine which subscriber the measurements belong to, in order to allow detaching that subscriber. However, the present disclosure is not limited thereto.

[0044] In some embodiments, Device Analytics (DA) (e.g., DA 250-1, DA 250-2, or DA 250-3) is a software as a service (SaaS) solution to measure the wireless connectivity performance from any mobile device. The results may be sent to a cloud database and analytics can be performed on this data, which can range from monitoring to optimizing. In the scenario shown in Fig. 2, DA may provide prerecord RSSI / RSRP of the serving and neighboring cells as fingerprints.

[0045] In some embodiments, the fingerprints may show what signals a drone that is flying above ground is expected to see and report. In some embodiments, measurement results may be considered to be distinguishable for the position (geolocation and altitude, or a 3D geographical position). In some embodiments, drones can be identified by validating RSSI / RSRP reports against these fingerprints. In some embodiments, because measurements of different devices may yield different values, e.g., due to different antenna properties, a matching procedure of prerecorded data and live results can be used.

[0046] In some embodiments, a single RSSI / RSRP fingerprint may comprise a set of multiple RSSI / RSRP values associated with multiple cells, respectively, such that a drone can be located based on its measured RSSI / RSRP values, for example, by comparing the set of measured values with the sets of pre-recorded values associated with specific locations.

[0047] In some embodiments, the data from DA can be applied differently. One option may be that the DA may be accessed by the CSP, which may perform the detection itself and expose the results (e.g., whether a suspicious drone is detected), and the results may be aggregated over multiple CSPs by a separate functionality (e.g., the Application Programming Interface (API) composition and Aggregation block 260, or aggregator 260 for short). Another option may be that the CSP may expose the RSSI / RSRP information directly and the aggregator may compare the data against the DA fingerprints. However, the present disclosure is not limited thereto, and other options are also possible.

[0048] As shown in Fig. 2, UEs including UEs 120, a registered drone 100, and a rogue drone 101 may be connected to multiple networks, e.g., the networks associated with multiple CSPs 200-1 and 200-2. Further, there may also be some other networks associated with the same or different CSPs, such as, other CSPs 200-3. As shown in Fig. 2, the SMOs 230-1 and 230-2 may be implemented by Intelligent Automation Platforms (IAPS). However, the present disclosure is not limited thereto. In some embodiments, a BBU (e.g., the BBU 210-1 and / or the BBU 210-2) may report information (e.g., RSSI / RSRP reports for handover, which may be collected from active devices, such as, the registered done 100 and / or the rogue drone 101) to the SMO. Further, the information of DA (e.g., the fingerprints) can be delivered to various nodes in the system, which perform the identification task. For example, the core 220-1 may retrieve the fingerprints associated with CSP 1 200-1 from the DA 250-1, for example, directly or via the Service Exposure Platform 240-1.

[0049] In some embodiments, CSPs may offer information via exposure platforms and the information can be aggregated and offered towards a dedicated drone detection & defense service (e.g., the DDDS 110). Further, although only one RAN is operated by one CSP as shown in Fig. 2, the present disclosure is not limited thereto. In some other embodiments, one CSP can also operate multiple RANs.

[0050] In some embodiments, fingerprints stored at a DA may be CSP-specific, RAN-specific, or non-CSP-specific. For example, a fingerprint at a DA may be used for identifying UAVs served by multiple CSPs. For another example, a fingerprint at a DA may be used for identifying UAVs served by a single CSP only. For yet another example, a fingerprint at a DA may be used for identifying UAVs served by a single RAN only.

[0051] Further, although the DAs 250 are shown in Fig. 2 as being separately located from other entities and run on the “Cloud” (e.g., the public Internet), the present disclosure is not limited thereto. In some embodiments, the DAs 250 may be running at an “API Aggregator” and potentially also close to the corresponding Core (e.g., EDA for CSP 1 250-1 running close to CSP 1 Core 220-1). In some embodiments, the DA 250 may be Application Servers.

[0052] Fig. 3 is a flow chart illustrating an exemplary method for improved UAV management according to an embodiment of the present disclosure. The method shown in Fig. 3 may be performed by one or more nodes shown in Fig. 2. For example, the step S310 and step S320 may be performed by the aggregator 260, the step S330 may be performed by the security authority (the “shield”), and the step S350 may be performed by the corresponding CSP (e.g., the CSP 1 200-1) or some network node thereof (e.g., the BBU 210-1 or the core 220-1 or the SMO 230-1). For another example, the step S310 through S350 may be performed by a same entity, such as, the security authority or the CSP.

[0053] Fig. 3 visualizes the decision process. As shown in Fig. 3, the method may be triggered by a new RSSI / RSRP report (e.g., a report initiated by the UE 120, the registered drone 100, the rogue drone 101 or the like). At step S310, the indicators (e.g., RSSI / RSRP) may be compared with the pre-recorded fingerprints, which may be obtained from the DA 250. If the RSSI / RSRP indicates a regular user (Branch “No” from step S310), i.e., the UE is not above ground, no further action is taken as shown at step S340. Otherwise (Branch “Yes” from step S310), a drone is detected and may be compared against a database 300 of registered drones. If the drone is registered (Branch “Yes” from step S320), no further action is taken as shown at step S340. If the drone is not registered (Branch “No” from step S320), it may be reported to the respective security authorities and the method may proceed to step S330 where various processes may be performed to confirm a threat, e.g., visual localization and assessment. After threat confirmation (Branch “Yes” from step S330), the resources of the drone may be cut at step S350. Otherwise (Branch “No” from step S330), no further action is taken as shown at step S340.

[0054] With the embodiments described above, operators and / or security authorities (or other legally entitled organizations) can identify / detect rogue drones (for example, by using the Drone Detection & Defense Service (DDDS) 110), and protect events and / or facilities (e.g., festivals, football games, airports, or military facilities) from the identified rogue drones, for example, by disconnecting the rogue drones from its remote pilots and forcing the rogue drones to land (for example, by using the DDDS 110).

[0055] Further, with the solutions in some embodiments of the present disclosure, the identification of and protection against rogue drones can be implemented by using legitimate information on hand, such as, Received Signal Strength Indicator (RSSI) and / or Reference Signal Received Power (RSSP) for handover. In other words, unlike the MDT, no additional user consent is required, and therefore information can be easily extracted and acted on in line with privacy regulations.

[0056] In some embodiments, information from various sources, e.g., BBU and Core, can be combined. In some embodiments, measurements (e.g., RSSI, RSRP, or the like) about current serving cell and neighbor cells may be passed from RAN to Core. Therefore, they can be intercepted at either or both of the locations.

[0057] In some embodiments, the information (e.g., the RSSI / RSRP reports, RSSI / RSRP fingerprint data, and / or the detection results) may be aggregated over multiple CSPs. Such combination allows to extract information and act on it in line with privacy regulations. Further, the process of comparing RSSI / RSRP against pre-recorded fingerprint data may allow feature extraction.

[0058] Fig. 4 is a flow chart of an exemplary method 400 at a first network node for UAV management according to an embodiment of the present disclosure. The method 400 may be performed at a network node (e.g., the BBU 210, the Core 220, the SMO 230, the aggregator 260, and / or the DDDS 110 shown in Fig. 2) for improved UAV management. The method 400 may comprise steps S410 and S420. However, the present disclosure is not limited thereto. In some other embodiments, the method 400 may comprise more steps, less steps, different steps, or any combination thereof. Further the steps of the method 400 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 400 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 400 may be combined into a single step.

[0059] The method 400 may begin at step S410 where the first network node may determine whether or not a UE is a UAV above ground.

[0060] At step S420, the first network node may trigger one or more operations for managing the UE in response to determining that the UE is a UAV above ground.

[0061] In some embodiments, before the determining whether or not a UE is a UAV above ground, the method 400 may further comprise: obtaining a set of radio measurement data associated with the UE; and obtaining one or more radio fingerprints. In some embodiments, whether or not the UE is a UAV above ground may be determined based on at least the set of radio measurement data and the one or more radio fingerprints. In some embodiments, the set of radio measurement data may comprise at least one of: one or more Received Signal Strength Indicators (RSSIs), which are associated with one or more cells, respectively; and one or more Reference Signal Received Powers (RSRPs), which are associated with one or more cells, respectively. In some embodiments, the set of radio measurement data (e.g., the one or more RSSIs, the one or more RSRPs, or the like) may be generated by measurements at the UE, measurements at one or more RAN nodes, or measurements partially at the UE and partially at one or more RAN nodes.

[0062] In some embodiments, the set of radio measurement data may be also used for enabling UE handover. In some embodiments, the set of radio measurement data may be obtained from at least one of: the UE; a Radio Access Network (RAN) node (e.g., a Baseband Unit (BBU)); a Core Network (CN) node; and a Service Management and Orchestration (SMO) node. In some embodiments, the set of radio measurement data may be obtained via a service exposure platform, which is located in a Communication Service Provider (CSP) domain in which the RAN node, the CN node, and / or the SMO node are located.

[0063] In some embodiments, a radio fingerprint may comprise a set of radio measurement data that is expected to be observed by a UE at an associated 3-Dimentional (3D) geographical position. In some embodiments, the one or more radio fingerprints may be obtained from one or more servers for collecting measurements of wireless connectivity performance for UEs. In some embodiments, a radio fingerprint may be used for distinguishing UAVs from other types of UEs. In some embodiments, a radio fingerprint may be one of a per multiple CSP radio fingerprint, a per single CSP radio fingerprint, a per multiple RAN radio fingerprint, and a per single RAN radio fingerprint. In some embodiments, the determining whether or not the UE is a UAV above ground may comprise: comparing the radio measurement data in the set against the corresponding expected radio measurement data in the one or more radio fingerprints to determine the altitude of the UE; and determining whether or not the UE is a UAV above ground based on at least the altitude of the UE. In some embodiments, the determining whether or not the UE is a UAV above ground based on at least the altitude of the UE may comprise at least one of determining that the UE is a UAV above ground in response to determining that the altitude of the UE is higher than or equal to a threshold; and determining that the UE is not a UAV above ground in response to determining that the altitude of the UE is lower than a threshold. In some embodiments, the determining whether or not the UE is a UAV above ground may be performed by other techniques such as Artificial Intelligence (AI) / Machine Learning (ML) or tree-based algorithms.

[0064] In some embodiments, the determining whether or not a UE is a UAV above ground may comprise: obtaining, from a CSP, an indication indicating whether or not the UE is a UAV above ground.

[0065] In some embodiments, before the triggering one or more operations for managing the UE, the method 400 may further comprise at least one of: determining whether or not the UE is a registered UAV; determining whether or not the UE is allowed to fly in a geographical space; and determining whether or not the UE is able to perform a threat. In some embodiments, the triggering one or more operations for managing the UE may comprise at least one of: reporting, to another network node, that the UE is a suspicious UAV in response to determining at least one of that the UE is not a registered UAV and that the UE is not allowed to fly in a geographical space; and triggering a CSP, by which the UE is served, to disconnect the UE in response to determining at least one of that the UE is not a registered UAV, that the UE is not allowed to fly in a geographical space, and that the UE is able to perform a threat; and triggering the UE to land on the ground in response to determining at least one of that the UE is not a registered UAV, that the UE is not allowed to fly in a geographical space, and that the UE is able to perform a threat.

[0066] In some embodiments, the determining whether or not the UE is a registered UAV may comprise: comparing the UE against a set of registered drones. In some embodiments, the determining whether or not the UE is a registered UAV may further comprise at least one of: determining that the UE is a registered UAV in response to determining the UE is in the set; and determining that the UE is not a registered UAV in response to determining the UE is not in the set. In some embodiments, the determining whether or not the UE is able to perform a threat may be based on at least one of: visual localization and assessment, and electromagnetic waves (e.g., radar, lidar, or the like). In some embodiments, the first network node may be at least one of: a RAN node; a CN node; an SMO node; and an application server that is located outside of a CSP’s domain.

[0067] Fig. 5 is a flow chart of an exemplary method 500 at a second network node for facilitating a first network node in UAV management according to an embodiment of the present disclosure. The method 500 may be performed at a network node (e.g., the DA 250 shown in Fig. 2) for improved UAV management. The method 500 may comprise a step S510. However, the present disclosure is not limited thereto. In some other embodiments, the method 500 may comprise more steps, different steps, or any combination thereof. Further the steps of the method 500 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 500 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 500 may be combined into a single step.

[0068] The method 500 may begin at step S510 where the second network node may provide the first network node with one or more radio fingerprints to enable the first network node to determine whether or not a User Equipment (UE) is a UAV above ground based on at least the one or more radio fingerprints and a set of radio measurement data associated with the UE.

[0069] In some embodiments, a radio fingerprint may comprise a set of radio measurement data that is expected to be observed by a UE at an associated 3D geographical position. In some embodiments, a server for collecting measurements of wireless connectivity performance for UEs may be hosted by the second network node. In some embodiments, a radio fingerprint may be used for differentiating UAVs from other types of UEs. In some embodiments, a radio fingerprint may be one of: a per multiple CSP radio fingerprint, a per single CSP radio fingerprint, a per multiple RAN radio fingerprint, and a per single RAN radio fingerprint.

[0070] Fig. 6 schematically shows an embodiment of an arrangement which may be used in network nodes according to an embodiment of the present disclosure. Comprised in the arrangement 600 are a processing unit 606, e.g., with a Digital Signal Processor (DSP) or a Central Processing Unit (CPU). The processing unit 606 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 600 may also comprise an input unit 602 for receiving signals from other entities, and an output unit 604 for providing signal(s) to other entities. The input unit 602 and the output unit 604 may be arranged as an integrated entity or as separate entities.

[0071] Furthermore, the arrangement 600 may comprise at least one computer program product 608 in the form of a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and / or a hard drive. The computer program product 608 comprises a computer program 610, which comprises code / computer readable instructions, which when executed by the processing unit 606 in the arrangement 600 causes the arrangement 600 and / or the network nodes in which it is comprised to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 2 through Fig. 5 or any other variant.

[0072] The computer program 610 may be configured as a computer program code structured in computer program modules 610A and 610B. Hence, in an exemplifying embodiment when the arrangement 600 is used in a first network node for UAV management, the code in the computer program of the arrangement 600 includes a module 610A configured to determine whether or not a UE is a UAV above ground; and a module 610B configured to trigger one or more operations for managing the UE in response to determining that the UE is a UAV above ground.

[0073] Additionally or alternatively, the computer program 610 may be configured as a computer program code structured in a computer program module 610C. Hence, in an exemplifying embodiment when the arrangement 600 is used in a second network node for facilitating a first network node in UAV management, the code in the computer program of the arrangement 600 includes a module 610C configured to provide the first network node with one or more radio fingerprints to enable the first network node to determine whether or not a UE is a UAV above ground based on at least the one or more radio fingerprints and a set of radio measurement data associated with the UE.

[0074] The computer program modules could essentially perform the actions of the flow illustrated in Fig. 2 through Fig. 5, to emulate the network nodes. In other words, when the different computer program modules are executed in the processing unit 606, they may correspond to different modules in the network nodes.

[0075] Although the code means in the embodiments disclosed above in conjunction with Fig. 6 are implemented as computer program modules which when executed in the processing unit causes the arrangement to perform the actions described above in conjunction with the figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

[0076] The processor may be a single CPU (Central processing unit), but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and / or related chips sets and / or special purpose microprocessors such as Application Specific Integrated Circuit (ASICs). The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-access memory (RAM), a Read-Only Memory (ROM), or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the network nodes.

[0077] The present disclosure is described above with reference to the embodiments thereof.

[0078] However, those embodiments are provided just for illustrative purpose, rather than limiting the present disclosure. The scope of the disclosure is defined by the attached claims as well as equivalents thereof. Those skilled in the art can make various alternations and modifications without departing from the scope of the disclosure, which all fall into the scope of the disclosure.

Claims

ClaimsWhat is claimed is:

1. A method (400) at a first network node (110, 210, 220, 230, 260) for Unmanned Aerial Vehicle (UAV) management, the method (400) comprising: determining (S410) whether or not a User Equipment (UE) is a UAV above ground; and triggering (S420) one or more operations for managing the UE in response to determining that the UE is a UAV above ground.

2. The method (400) of claim 1, wherein before the determining (S410) whether or not a UE is a UAV above ground, the method (400) further comprises: obtaining a set of radio measurement data associated with the UE; and obtaining one or more radio fingerprints, wherein whether or not the UE is a UAV above ground is determined based on at least the set of radio measurement data and the one or more radio fingerprints.

3. The method (400) of claim 2, wherein the set of radio measurement data comprises at least one of:- one or more Received Signal Strength Indicators (RS Sis), which are associated with one or more cells, respectively; and- one or more Reference Signal Received Powers (RSRPs), which are associated with one or more cells, respectively.

4. The method (400) of claim 2 or 3, wherein the set of radio measurement data is also used for enabling UE handover.

5. The method (400) of any of claims 2 to 4, wherein the set of radio measurement data is obtained from at least one of:- the UE;- a Radio Access Network (RAN) node;- a Core Network (CN) node; and- a Service Management and Orchestration (SMO) node.

6. The method (400) of claim 5, wherein the set of radio measurement data is obtained via a service exposure platform, which is located in a Communication Service Provider (CSP) domain in which the RAN node, the CN node, and / or the SMO node are located.

7. The method (400) of any of claims 2 to 6, wherein a radio fingerprint comprises a set of radio measurement data that is expected to be observed by a UE at an associated 3-Dimentional (3D) geographical position.

8. The method (400) of any of claims 2 to 7, wherein the one or more radio fingerprints are obtained from one or more servers for collecting measurements of wireless connectivity performance for UEs.

9. The method (400) of any of claims 2 to 8, wherein a radio fingerprint is used for differentiating UAVs from other types of UEs.

10. The method (400) of any of claims 2 to 9, wherein a radio fingerprint is one of:- a per multiple CSP radio fingerprint;- a per single CSP radio fingerprint;- a per multiple RAN radio fingerprint; and- a per single RAN radio fingerprint.

11. The method (400) of any of claims 2 to 10, wherein the determining (S410) whether or not the UE is a UAV above ground comprises: comparing the radio measurement data in the set against the corresponding expected radio measurement data in the one or more radio fingerprints to determine the altitude of the UE; and determining whether or not the UE is a UAV above ground based on at least the altitude of the UE.

12. The method (400) of claim 11, wherein the determining whether or not the UE is a UAV above ground based on at least the altitude of the UE comprises at least one of: determining that the UE is a UAV above ground in response to determining that the altitude of the UE is higher than or equal to a threshold; and determining that the UE is not a UAV above ground in response to determining that the altitude of the UE is lower than a threshold.

13. The method (400) of claim 1, wherein the determining (S410) whether or not a UE is a UAV above ground comprises:obtaining, from a CSP, an indication indicating whether or not the UE is a UAV above ground.

14. The method (400) of any of claims 1 to 13, wherein before the triggering (S420) one or more operations for managing the UE, the method (400) further comprises at least one of: determining whether or not the UE is a registered UAV; determining whether or not the UE is allowed to fly in a geographical space; and determining whether or not the UE is able to perform a threat.

15. The method (400) of any of claims 1 to 14, wherein the triggering (S420) one or more operations for managing the UE comprises at least one of: reporting, to another network node, that the UE is a suspicious UAV in response to determining at least one of that the UE is not a registered UAV and that the UE is not allowed to fly in a geographical space; and triggering a CSP, by which the UE is served, to disconnect the UE in response to determining at least one of that the UE is not a registered UAV, that the UE is not allowed to fly in a geographical space, and that the UE is able to perform a threat; and triggering the UE to land on the ground in response to determining at least one of that the UE is not a registered UAV, that the UE is not allowed to fly in a geographical space, and that the UE is able to perform a threat.

16. The method (400) of claim 14 or 15, wherein the determining whether or not the UE is a registered UAV comprises: comparing the UE against a set of registered drones, wherein the determining whether or not the UE is a registered UAV further comprises at least one of: determining that the UE is a registered UAV in response to determining the UE is in the set; and determining that the UE is not a registered UAV in response to determining the UE is not in the set.

17. The method (400) of any of claims 14 to 16, wherein the determining whether or not the UE is able to perform a threat is based on at least one of:- visual localization and assessment; and- electromagnetic waves.

18. The method (400) of any of claims 1 to 17, wherein the first network node (110, 210, 220, 230, 260) is at least one of:- a RAN node (210);- a CN node (220);- an SMO node (230); and- an application server that is located outside of a CSP’s domain (110, 260).

19. A first network node (110, 210, 220, 230, 260, 600) comprising: a processor (606); a memory (608) storing instructions which, when executed by the processor (606), cause the first network node (110, 210, 220, 230, 260, 600) to: determine whether or not a User Equipment (UE) is a UAV above ground; and trigger one or more operations for managing the UE in response to determining that the UE is a UAV above ground.

20. The first network node (110, 210, 220, 230, 260, 600) of claim 18, wherein the instructions, when executed by the processor (606), cause the first network node (110, 210, 220, 230, 260, 600) to further perform any of the methods (400) of claims 2 to 18.

21. A method (500) at a second network node (250) for facilitating a first network node (110, 210, 220, 230, 260) in Unmanned Aerial Vehicle (UAV) management, the method (500) comprising: providing (S510) the first network node (110, 210, 220, 230, 260) with one or more radio fingerprints to enable the first network node (110, 210, 220, 230, 260) to determine whether or not a User Equipment (UE) is a UAV above ground based on at least the one or more radio fingerprints and a set of radio measurement data associated with the UE.

22. The method (500) of claim 21, wherein a radio fingerprint comprises a set of radio measurement data that is expected to be observed by a UE at an associated 3-Dimentional (3D) geographical position.

23. The method (500) of claim 21 or 22, wherein a server for collecting measurements of wireless connectivity performance for UEs is hosted by the second network node (250).

24. The method (500) of any of claims 21 to 23, wherein a radio fingerprint is used for differentiating UAVs from other types of UEs.

25. The method (500) of any of claims 21 to 24, wherein a radio fingerprint is one of:- a per multiple CSP radio fingerprint;- a per single CSP radio fingerprint;- a per multiple RAN radio fingerprint; and- a per single RAN radio fingerprint.

26. A second network node comprising: a processor(606); a memory (608) storing instructions which, when executed by the processor, cause the second network node to: provide a first network node with one or more radio fingerprints to enable the first network node to determine whether or not a User Equipment (UE) is a UAV above ground based on at least the one or more radio fingerprints and a set of radio measurement data associated with the UE.

27. The second network node of claim 26, wherein the instructions, when executed by the processor, cause the second network node to further perform any of the methods (500) of claims 22 to 25.

28. A computer program comprising instructions which, when executed by at least one processor, cause the at least one processor to carry out the method (400, 500) of any of claims 1 to 18 and 21 to 25.

29. A carrier containing the computer program of claim 28, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

30. A telecommunication system comprising: one or more first network nodes of claim 19 or 20; and one or more second network nodes of claim 26 or 27.

Images