Network connection unmanned aerial vehicle identification method

Abstract

The invention discloses a network connection unmanned aerial vehicle identification method, and relates to the technical field of unmanned aerial vehicle prevention and control. The method comprises the following steps: acquiring a user plane data stream at a base station side in a cellular communication network; performing protocol analysis on the user plane data stream, and extracting inner-layer communication feature information packaged in a tunnel protocol; based on the inner-layer communication feature information, judging whether the user plane data flow is matched with a preset unmanned aerial vehicle service identifier feature or not; if yes, performing secondary verification by combining the flow behavior characteristics of the user plane data flow with a preset unmanned aerial vehicle communication behavior model; and when the flow behavior characteristics meet the unmanned aerial vehicle communication behavior model, determining that the user plane data flow corresponds to the network connection unmanned aerial vehicle. Through a dual verification mechanism of high-level service feature matching and bottom-level flow behavior secondary verification, accurate and real-time identification of the networked unmanned aerial vehicle is realized, an identification blind area of a traditional physical detection means in a cellular network environment is effectively made up, and the method can be widely applied to scenes of low-altitude security and protection, key infrastructure protection and the like.

Description

Technical Field

[0001] This application relates to the field of drone control technology, specifically to a method for identifying connected drones based on cellular network user plane traffic analysis. It is particularly suitable for real-time and accurate identification of connected drones accessing the public network via SIM cards in 4G / 5G / 6G mobile communication environments, and can be widely used in scenarios such as low-altitude security, border monitoring, and protection of critical infrastructure. Background Technology

[0002] In recent years, with the popularization of cellular communication networks and the development of Internet of Things (IoT) technology, cellular-connected UAVs have gradually become the mainstream of industry applications. These UAVs, through built-in 4G / 5G / 6G communication modules and SIM cards, directly access the operator's cellular network, replacing traditional remote control links to achieve beyond-line-of-sight flight control and real-time high-definition video transmission. Their advantages include long communication distance, strong anti-interference capabilities, and support for cross-base station handover. They have already been deployed on a large scale in fields such as power line inspection, emergency communication, and logistics delivery.

[0003] However, the high degree of concealment and wide operating range of connected drones also bring serious security risks. Unauthorized users can use connected drones to carry out illegal activities such as reconnaissance of restricted areas and delivery of hazardous materials, threatening critical national infrastructure and public safety. Because connected drone communication is fully integrated into the cellular network user plane, traditional drone control systems that rely on radio frequency signal detection, radar reflection, or optical identification cannot effectively detect their presence, creating a security vulnerability that is "invisible and unmanageable."

[0004] Although operator base stations can collect complete user plane data (such as GTP-U data packets), existing network analysis systems are mainly used for QoS assurance or billing, lacking dedicated identification capabilities for drone services. Existing technical solutions mostly focus on non-networked drones, leaving the identification of networked drones a blank slate.

[0005] Therefore, there is an urgent need for a method that can automatically, in real time, and accurately identify connected drones from the massive user plane traffic of operator base stations to support the construction of a new generation of low-altitude security system. Summary of the Invention

[0006] The purpose of this application is to provide a method for identifying connected drones. Based on user plane data from operator base stations, it uses a dual verification mechanism that combines layered parsing with high-level business feature matching and low-level traffic behavior secondary verification to achieve accurate and real-time identification of connected drones.

[0007] The above-mentioned objective of this application is achieved through the following technical solution:

[0008] A method for identifying connected drones, the method comprising:

[0009] Acquire user plane data streams from the base station side in a cellular communication network;

[0010] The user plane data stream is parsed to extract the inner communication feature information encapsulated in the tunnel protocol;

[0011] Based on the inner-layer communication feature information, determine whether the user plane data stream matches the preset UAV service identifier features;

[0012] If a match is found, a secondary verification is performed by combining the traffic behavior characteristics of the user plane data stream with the preset UAV communication behavior model.

[0013] When the traffic behavior characteristics satisfy the UAV communication behavior model, the user plane data stream is confirmed to correspond to a connected UAV.

[0014] Preferably, the step of performing protocol parsing on the user plane data stream and extracting the inner communication feature information encapsulated in the tunnel protocol includes:

[0015] The link layer, network layer, and transport layer protocols of the user plane data stream are analyzed sequentially.

[0016] When the transport layer protocol is detected as UDP and the port number is 2152, it is determined that a GTP tunnel exists.

[0017] Parse the GTP protocol header to obtain the inner IP data packets it carries;

[0018] Parse the inner IP data packet to obtain the inner communication feature information, wherein the inner communication feature information includes the inner source IP address, the inner destination IP address, the inner transport layer protocol type, the inner source port, and the inner destination port.

[0019] Preferably, the step of parsing the user plane data stream and extracting the inner communication feature information encapsulated in the tunnel protocol further includes:

[0020] If the inner transport layer protocol type is UDP or TCP, then the application layer protocol type is identified based on the inner port, and the application layer data packets carried by the inner transport layer are parsed according to the application layer protocol type to obtain the application layer feature information contained in the inner communication feature information, wherein...

[0021] When the inner port is 53, the application layer data packet is resolved according to the DNS protocol to extract the DNS Name information.

[0022] When the inner port is 80, the application layer data packet is parsed according to the HTTP protocol to extract the request URI information.

[0023] When the inner port is 443, the application layer data packet is parsed according to the TLS protocol to extract SNI information.

[0024] The extracted DNS Name information, URI information, or SNI information are the application layer feature information.

[0025] Preferably, determining whether the user plane data stream matches a preset UAV service identifier feature based on the inner layer communication feature information includes:

[0026] A flow identifier key is constructed based on the inner source IP address, inner destination IP address, inner source port, and inner destination port of the inner communication feature information.

[0027] Search for or create a stream record corresponding to the stream identifier key in a preset stream information container;

[0028] Write the application layer feature information from the extracted inner layer communication feature information into the stream record;

[0029] Check whether the application layer feature information matches any string in the preloaded UAV service string feature container;

[0030] If a match is found, the user plane data stream is determined to initially conform to the characteristics of drone service identification, and the payload information in the stream record is inserted into the preset suspected drone container.

[0031] Preferably, the UAV service string feature container is preloaded when the connected UAV identification program is started. The UAV service string feature container contains domain names, API paths and / or TLS hostnames related to the cloud platforms, flight control services and / or video backhaul services of mainstream connected UAV manufacturers.

[0032] Preferably, the secondary verification, which combines the traffic behavior characteristics of the user plane data stream with a preset UAV communication behavior model, includes:

[0033] For user plane data streams that are preliminarily determined to meet the characteristics of UAV business identification, their uplink and downlink traffic are accumulated separately according to the data stream transmission direction.

[0034] Record the duration of the user plane data stream from its first occurrence;

[0035] When the duration reaches or exceeds a set time window, it is determined whether the cumulative uplink traffic of the user plane data stream is greater than or equal to the uplink traffic threshold and whether the cumulative downlink traffic is greater than or equal to the downlink traffic threshold. The set time window is a configurable minimum observation period required to determine traffic behavior.

[0036] Preferably, the UAV communication behavior model is set based on the typical business mode of connected UAVs, wherein the uplink traffic threshold is significantly greater than the downlink traffic threshold, so as to reflect the asymmetric communication characteristics of connected UAVs, which are mainly video uploading and secondarily command issuing.

[0037] Preferably, the process of parsing the user plane data stream according to the protocol further includes the following direction determination step:

[0038] Pre-build IP containers for core network devices;

[0039] The outer source IP or outer destination IP of the user plane data stream is matched with the container to obtain a direction determination result. This direction determination result is used for accurate classification of uplink / downlink traffic in traffic statistics.

[0040] If the outer source IP exists in the IP container of the core network device, then the user plane data stream is determined to be in the uplink direction.

[0041] If the outer destination IP exists in the IP container of the core network device, then the user plane data flow is determined to be in the downlink direction.

[0042] Preferably, confirming that the user plane data stream corresponds to a connected UAV when the traffic behavior characteristics satisfy the UAV communication behavior model includes:

[0043] When the traffic behavior characteristics satisfy the UAV communication behavior model, check whether the flow record corresponding to the user plane data flow already exists in the suspected UAV container.

[0044] If so, the payload information in the stream record corresponding to the user plane data stream is removed from the suspected drone container, and the payload information in the stream record corresponding to the user plane data stream is inserted into the preset confirmed drone container.

[0045] The payload information is output as the identification result of the connected drone, wherein the payload information is used to trigger alarms, report to the regulatory platform and / or link with the countermeasure system.

[0046] Preferably, the user plane data stream originates from the user plane interface data packets of a 4G / 5G / 6G cellular network base station.

[0047] Compared with existing technologies, the networked drone identification method of this application has the following advantages:

[0048] 1. For the first time, the path identification of connected drones based solely on user plane data from operator base stations has been achieved without contact with wireless air interface signals, fundamentally solving the technical problem of "not being able to see or manage" connected drones;

[0049] 2. A dual verification mechanism that combines high-level business feature matching with low-level traffic behavior secondary verification is adopted, which significantly improves the accuracy and robustness of identification.

[0050] 3. It is entirely software-based and can be directly deployed on the operator's existing DPI platform, core network bypass probe or MEC edge server, reusing existing user plane traffic mirroring. There is no need to deploy dedicated detection equipment such as radar and spectrum analyzers in the airspace, which greatly reduces the construction and operation and maintenance costs of the low-altitude security system.

[0051] 4. It adopts a streaming processing method to parse data packets one by one, supports online identification, and can promptly detect and report connected drones in flight, meeting the stringent timeliness requirements of security scenarios such as emergency response and real-time protection of key areas;

[0052] 5. The UAV business string feature container and UAV communication behavior model parameters both support dynamic loading and remote configuration. When new connected UAV products are launched or communication protocols are upgraded, only the feature library needs to be updated or the model adjusted, without the need to reconstruct the system, demonstrating good adaptability and long-term evolution capabilities. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a flowchart illustrating a networked drone identification method according to an embodiment of this application;

[0055] Figure 2 This is a flowchart illustrating the networked drone identification method in a specific example of this application;

[0056] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0057] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. The system embodiments described below are merely illustrative. For example, the division of units and modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or modules can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, and can be electrical, mechanical, or other forms.

[0059] In addition, each functional unit in the various embodiments of this application can be integrated into a single processor, or each unit can be a separate device, or two or more units can be integrated into a single device; each functional unit in the various embodiments of this application can be implemented in hardware or in the form of hardware plus software functional units.

[0060] Those skilled in the art will understand that all or part of the steps of the following method embodiments can be implemented by program instructions and related hardware. The aforementioned program instructions can be stored in a computer-readable storage medium. When the program instructions are executed, they perform the steps of the following method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0061] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "a plurality of" or "several" means two or more, unless otherwise explicitly specified.

[0062] In cellular communication networks (4G / 5G / 6G), the data processed by operator base stations is clearly divided into two main categories: control plane and user plane. User plane data carries the actual service content (such as internet access, video, remote control, etc.) between the terminal (e.g., mobile phone, connected drone) and the external network. Its typical structure is a multi-layered encapsulated IP-based data packet, with the protocol stack from bottom to top as follows:

[0063] MAC → VLAN (optional) → Outer IP → UDP → GTP → Inner IP → Inner TCP / UDP / ICMP → Application Layer Data.

[0064] Because of the GTP-U (GPRS Tunneling Protocol-User Plane) tunnel, the user's actual communication is encapsulated within the "inner IP" and its upper-layer protocols, while the outer IP is only used for transmission routing between the base station and core network equipment. Therefore, to identify the service behavior of a specific terminal (such as a connected drone), it is necessary to penetrate the GTP tunnel and reconstruct its inner communication content.

[0065] Furthermore, communication in the user plane can be aggregated into logical "flows" based on the inner source IP, destination IP, source port, and destination port quadruple. Each flow represents an independent end-to-end session; for example, WeChat messages, video uploads, or flight control commands each correspond to different flows.

[0066] Based on this, this application addresses the issue that when connected drones access cellular networks via SIM cards, their communication becomes completely integrated into user plane traffic, rendering traditional airspace detection methods ineffective. It directly starts with user plane data from the base station side, using deep protocol parsing to penetrate the GTP tunnel and extract high-level service characteristics (such as domain names, URIs, and SNIs) of the inner layer flow. Building upon this, and considering the unique behavioral patterns of connected drones, such as asymmetric uplink and downlink traffic and continuous stable transmission, a dual identification mechanism of feature matching initial screening and traffic behavior verification is constructed. This enables high-precision, real-time, and scalable software-based identification of connected drones without relying on wireless signals. This solution fully utilizes existing operator network data resources without requiring additional hardware deployment, filling a key technological gap in current low-altitude security systems in cellular connected scenarios.

[0067] like Figure 1 As shown in the figure, this application provides a method for identifying networked drones, which may include the following steps:

[0068] S1, acquire the user plane data stream on the base station side of the cellular communication network;

[0069] To identify connected drones based on user plane data from carrier base stations, it is first necessary to collect user plane traffic in real time from 4G / 5G / 6G cellular network base stations (eNodeB / gNodeB) or their associated core network interfaces (such as S1U, SGi, N3, or N6). These data packets are typically raw Ethernet frames or IP data streams obtained through port mirroring, optical splitters, or DPI probes, containing all communication content between all terminals (including connected drones) and external networks. By acquiring user plane data streams from the base station side of the cellular communication network, a raw data foundation is provided for subsequent protocol parsing and feature extraction, ensuring that the identification covers all communication behaviors of connected drones transmitted through the cellular network.

[0070] S2 performs protocol parsing on the user plane data stream and extracts the inner communication feature information encapsulated in the tunnel protocol;

[0071] Because cellular networks use a tunneling mechanism to transmit user data, the actual communication content is encapsulated inside the GTP tunnel. Therefore, after obtaining the user plane data stream from the operator's base station, in order to accurately identify the connected drone from the raw user plane data collected by the cellular network base station, it is necessary to first perform layer-by-layer protocol parsing on the data packets to penetrate the tunnel encapsulation of the operator's network and restore the actual communication information between the terminal (i.e., the drone) and the remote server.

[0072] S3, based on the inner layer communication feature information, determines whether the user plane data stream matches the preset UAV service identifier features;

[0073] By comparing the extracted inner-layer communication feature information with a pre-loaded drone service string feature container, if any feature in the inner-layer communication feature information matches, the data packet is determined to "preliminarily match" the drone service features, thereby filtering out suspected drones, achieving efficient initial screening, quickly locating potential drone communications from massive ordinary user traffic, and significantly narrowing the verification scope.

[0074] S4. If a match is found, a second verification is performed by combining the traffic behavior characteristics of the user plane data stream with the preset UAV communication behavior model.

[0075] To avoid false alarms (such as ordinary users accidentally visiting drone-related websites), further behavioral verification is performed on "suspected" flows. The traffic behavior characteristics of the flow are continuously tracked and matched with the preset drone communication behavior model to achieve secondary verification. In this way, the instantaneous or atypical access is filtered through behavioral modeling, which significantly improves the identification accuracy and suppresses false alarms.

[0076] Specifically, the drone communication behavior model is designed based on the typical asymmetric communication mode of networked drones, which is "primarily video uploading and secondarily command issuance".

[0077] S5. When the traffic behavior characteristics meet the UAV communication behavior model, confirm that the user plane data stream corresponds to the connected UAV.

[0078] Once the traffic behavior characteristics of the user plane data stream are verified by the preset UAV communication behavior model, it is officially confirmed that the communication stream comes from the connected UAV, completing the closed loop from "suspicious" to "confirmed", outputting a reliable identification result, and supporting low-altitude safety decision-making and response.

[0079] In summary, the connected drone identification method in the above embodiments first obtains the original user plane data stream from the cellular network base station side; then, it extracts the inner communication features by passing through the tunnel encapsulation through protocol parsing; based on these features, it matches them with a preset drone service identifier feature library to achieve preliminary screening; if the match is successful, it further combines the traffic behavior of the data packet with a preset drone communication behavior model for secondary verification; only when the behavioral features meet the model conditions is it finally confirmed as a connected drone. This process adopts a two-stage mechanism of preliminary screening + verification, balancing efficiency and accuracy.

[0080] This embodiment uses user plane data from operator base stations and employs a dual verification mechanism that combines layered parsing with high-level business feature matching and low-level traffic behavior secondary verification to achieve accurate and real-time identification of connected drones.

[0081] In one embodiment, step S2, which involves parsing the user plane data stream to extract the inner communication feature information encapsulated in the tunnel protocol, may include the following steps:

[0082] 1. Sequentially analyze the link layer, network layer, and transport layer protocols of the user plane data stream;

[0083] In order to extract the inner communication feature information encapsulated in the tunneling protocol, the link layer, network layer and transport layer protocols of the user plane data stream are first parsed in sequence to locate and confirm whether a GTP-U (GPRS Tunnelling Protocol-User Plane) tunnel exists. This is the standard encapsulation method for carrying user data in 4G / 5G / 6G networks.

[0084] Specifically, for the link layer, the MAC address is parsed to determine the data frame type; for the network layer (outer IP), the transmission path information between the base station and the core network equipment is obtained (e.g., the source IP is the base station IP, and the destination IP is the core network PGW / UPF IP); for the transport layer, the upper layer protocol type is identified (usually UDP), and the source port and destination port are read.

[0085] 2. When the transport layer protocol is detected as UDP and the port number is 2152, it is determined that a GTP tunnel exists;

[0086] According to the 3GPP standard, the GTP-U protocol consistently uses UDP port 2152 as the destination port (sometimes the source port is also 2152). Therefore, port 2152 is a key identifier for GTP user plane traffic, and the specific judgment logic is as follows:

[0087] If the transport layer protocol is not UDP, then non-GTP traffic is skipped.

[0088] If the UDP destination port is not equal to 2152, it is non-user plane tunnel traffic (which may be ordinary Internet UDP service), so skip it.

[0089] The packet is considered to belong to the cellular user plane GTP tunnel only if the protocol is UDP and the port is 2152, and then proceeds to the next step of parsing.

[0090] This step can efficiently filter irrelevant traffic, avoid invalid deep parsing, and improve system throughput.

[0091] 3. Parse the GTP protocol header to obtain the inner IP data packets it carries;

[0092] The purpose of a GTP tunnel is to transmit user data transparently. The inner IP packets completely preserve the terminal's actual network behavior and are the only reliable source for identifying the service type. Therefore, when the existence of a GTP tunnel is determined, the GTP protocol header needs to be further parsed to extract the GTP payload. This payload is the inner IP data packet, representing the original communication between the UAV terminal (UE) and the external server.

[0093] 4. Parse the inner IP data packets to obtain inner communication characteristic information, which includes the inner source IP address, inner destination IP address, inner transport layer protocol type, inner source port, and inner destination port.

[0094] The detailed analysis is as follows:

[0095] Inner source IP address: The private or public IP address assigned to the drone terminal in the core network;

[0096] Inner destination IP address: The server IP address accessed by the drone (such as the manufacturer's cloud platform).

[0097] Inner source port: A random local port on the drone;

[0098] Inner destination port: well-known server ports (such as 80, 443, 53, etc.).

[0099] The above four-tuples constitute the FlowKey, which is used to aggregate all data packets of the same session; the inner port further indicates the upper-layer application type (such as 443→HTTPS / TLS), providing an entry point for subsequent application layer feature extraction (such as SNI).

[0100] In this embodiment, by sequentially parsing the link layer (such as Ethernet), network layer (outer IP), and transport layer (UDP) of the user plane data stream, when the UDP port is detected as 2152 (the standard GTP-U port), a GTP tunnel is determined to exist. Then, the GTP protocol header is parsed, the outer encapsulation is stripped, and the inner IP data packet is obtained. Finally, the inner IP packet header is parsed to extract the inner source / destination IP, protocol type, and source / destination port, forming an inner quadruple. This process realizes the restoration from the original data packet to the actual communication flow identifier, accurately restoring the real communication relationship between the UAV terminal and the cloud platform, providing a basic identifier for subsequent flow state management and feature matching. The determination of port 2152 ensures that only valid GTP traffic is processed, improving processing efficiency.

[0101] In one embodiment, parsing the user plane data stream to extract the inner communication feature information encapsulated in the tunnel protocol may further include the following steps:

[0102] 5. If the inner transport layer protocol type is UDP or TCP, then the application layer protocol type is identified based on the inner port, and the application layer data packets carried by the inner transport layer are parsed according to the application layer protocol type to obtain the application layer feature information contained in the inner communication feature information.

[0103] When the inner port is 53, the application layer data packets are resolved according to the DNS protocol to extract the DNS Name information.

[0104] When the inner port is 80, the application layer data packet is parsed according to the HTTP protocol to extract the request URI information.

[0105] When the inner port is 443, the application layer data packets are parsed according to the TLS protocol to extract SNI information.

[0106] The extracted DNS Name, URI, or SNI information are application layer feature information.

[0107] After completing the GTP tunnel decapsulation and obtaining the inner IP data packets, this embodiment introduces an application layer semantic feature extraction mechanism to further improve recognition accuracy. This mechanism uses the inner transport layer port number as a clue to selectively parse higher-layer protocols, thereby obtaining application layer feature information with clear business orientation. The specific process is as follows:

[0108] 1. Determine the type of the inner transport layer protocol.

[0109] Most internet applications (including drone control and video transmission) are built on TCP or UDP. Other protocols (such as ICMP) usually do not carry service identification information and can be ignored. Therefore, first check whether the transport layer protocol carried by the inner IP data packet is TCP or UDP.

[0110] 2. Identify the application layer protocol type based on the inner port.

[0111] Protocol inference is performed by leveraging the strong correlation between well-known ports and typical applications:

[0112] Port 53 → DNS (Domain Name System);

[0113] Port 80 → HTTP (Hypertext Transfer Protocol);

[0114] Port 443 → TLS / HTTPS (Transport Layer Security).

[0115] This "port → protocol" mapping is a common practice in network traffic analysis, balancing efficiency and accuracy.

[0116] 3. Classify and parse application layer data packets to extract structured features.

[0117] For different protocols, a dedicated parser is executed to extract key fields:

[0118] When the inner port is 53 (DNS):

[0119] Parse DNS query messages;

[0120] Extract the DNS Name (i.e., the requested domain name);

[0121] This domain name directly reflects the manufacturer's cloud platform or service that the drone is trying to connect to.

[0122] When the inner port is 80 (HTTP):

[0123] Parse the HTTP request line;

[0124] Extract the URI (Uniform Resource Identifier), such as / api / v1 / telemetry, / control / uav_stream;

[0125] URI paths typically contain business function semantics, which can accurately identify operations such as flight control and status reporting.

[0126] When the inner port is 443 (TLS / HTTPS):

[0127] Parse the ClientHello message during the TLS handshake phase;

[0128] Extract the SNI (Server Name Indication) extended fields, such as skydio-pilot.net;

[0129] Although HTTPS content is encrypted, SNI is transmitted in plaintext and can still expose the identity of the target server.

[0130] The above parsing only needs to process the initial few packets of the data stream (such as DNS lookup, HTTP header, TLS handshake), without decrypting the entire session, which complies with privacy compliance requirements.

[0131] 4. Use the extracted results as application layer feature information.

[0132] The obtained DNS Name, URI, and SNI are uniformly classified as application layer feature information, serving as an important component of inner-layer communication feature information. These features have high business relevance and low forgery cost, making them key criteria for distinguishing networked drones from ordinary users.

[0133] In this embodiment, after obtaining the inner transport layer protocol (TCP / UDP), the upper-layer application protocol is identified based on the port number: port 53 corresponds to DNS, port 80 to HTTP, and port 443 to TLS. Accordingly, the corresponding protocol resolver is invoked to extract the DNS query domain name, HTTP request URI, and SNI field from the TLS handshake. Compared to coarse-grained methods that rely solely on IP or port, this high-level semantic information has a clear business orientation and can be directly associated with the services of a specific drone manufacturer, significantly improving recognition accuracy. A "port-triggered resolution" strategy is adopted, performing deep resolution only on specific ports, avoiding expensive DPI (Deep Packet Inspection) on all traffic and ensuring system real-time performance. Even with the widespread adoption of HTTPS, hostname information can still be obtained through SNI, ensuring that recognition capabilities are not rendered ineffective by encryption.

[0134] It should be noted that in this embodiment, when the inner port is a value other than 53, 80 and 443, the port identifier can be recorded and the application layer feature information is not extracted.

[0135] In one embodiment, determining whether a user plane data stream matches a preset UAV service identifier feature based on inner-layer communication feature information may include the following steps:

[0136] 1. Construct a flow identifier key based on the inner source IP address, inner destination IP address, inner source port, and inner destination port of the inner communication feature information;

[0137] When a single drone performs flight control or video transmission tasks, it typically sends multiple data packets within a continuous session. These packets need to be merged into the same logical stream for processing. The four fields—inner source IP address, inner destination IP address, inner source port, and inner destination port—constitute the standard "quadruple" in network communication, which can uniquely identify an end-to-end transmission session (i.e., a "stream").

[0138] 2. Search for or create a stream record corresponding to the stream identifier key in the preset stream information container;

[0139] A flow information container (such as a flow map) is an in-memory key-value storage structure (such as a hash table) used to maintain the state of all active flows.

[0140] If the flow identifier key corresponding to the four-tuple already exists in the flow information container, it means that the data of the flow already exists. Then, retrieve the flow record FLOW_VALUE corresponding to the flow identifier (FLOW_VALUE is a structure space that stores the payload information, DNS name information, URI information, SNI information, traffic statistics information, etc. built in the previous order).

[0141] If the flow information container does not have the flow identifier key corresponding to the four-tuple, a new flow record FLOW_VALUE is created and its fields (such as timestamp, flow counter, feature buffer, etc.) are initialized.

[0142] The stream processing in this step supports high concurrency and low latency stream state management, making it suitable for real-time processing scenarios with tens of thousands of streams per second.

[0143] 3. Write the application layer feature information from the extracted inner layer communication feature information into the stream record;

[0144] Once a stream record corresponding to the stream identifier key is found or created, the application layer features extracted from the current data stream (such as DNS domain name, HTTP URI, TLS SNI) are appended to or updated to the corresponding fields of the stream record.

[0145] It should be noted that some features (such as SNI) only appear once at the beginning of the connection, so they need to be persistently stored once the parsing is successful for subsequent matching.

[0146] 4. Check whether the application layer feature information matches any string in the preloaded UAV business string feature container;

[0147] The DNS Name, URI, and SNI fields in the flow record are precisely matched with the UAV service string feature container (such as Character Map, i.e., UAV service string feature container). As long as any field matches any string in the feature library, it is considered to "preliminarily conform to the UAV service identifier feature".

[0148] 5. If a match is found, the user plane data stream is determined to initially conform to the characteristics of the drone business identifier, and the payload information in the stream record is inserted into the preset suspected drone container.

[0149] If the drone service string features are successfully matched, the payload information associated with the stream record (such as terminal IP, base station ID, timestamp, feature summary, etc.) is added to a special "suspected drone container" (such as SuspectUavInfo).

[0150] It should be noted that the payload information, as the carrier for subsequent secondary verification and result output, may not contain the original user data, but only metadata and identification criteria.

[0151] This embodiment utilizes an inner quadruple to construct a unique flow identifier key (KEY), and searches for or creates the corresponding flow record (FLOW_VALUE) in a flow information container (such as a hash table FlowMap). The extracted application-layer features are written into this flow record and matched against a pre-loaded UAV service string feature container. If a match is found, the payload information of that flow is added to a suspected UAV container and marked as a target to be verified. This process achieves flow-level state tracking and feature aggregation, supports feature accumulation across data packets, and isolates the initial screening results from ordinary flows through a suspected UAV container mechanism, providing input for secondary verification and avoiding the direct output of unreliable alarms.

[0152] In one embodiment, the drone service string feature container is preloaded when the connected drone identification program is started. The drone service string feature container contains domain names, API paths, and / or TLS hostnames related to the cloud platforms, flight control services, and / or video backhaul services of mainstream connected drone manufacturers.

[0153] Specifically, the drone business string feature container is loaded into memory all at once when the recognition program starts. Its content includes cloud platform domain names, control API paths, TLS hostnames, and other information from major manufacturers. The data in this container serves as the matching basis, reflecting the communication characteristics of mainstream connected drones currently on the market.

[0154] This embodiment ensures the timeliness and coverage of feature matching, avoids runtime I / O latency by loading at startup, improves real-time processing performance, and allows the content in the feature container to be dynamically updated with the vendor ecosystem, maintaining the long-term effectiveness of the system.

[0155] In one embodiment, secondary verification by combining the traffic behavior characteristics of the user plane data stream with a preset UAV communication behavior model may include the following steps:

[0156] 1. For user plane data streams that are preliminarily determined to meet the characteristics of UAV business identification, their uplink and downlink traffic are accumulated separately according to the data stream transmission direction;

[0157] A large number of devices in a network may use similar protocols or ports, making it easy to misidentify based solely on static characteristics (i.e., drone service identifiers). Therefore, a dynamic traffic behavior model is introduced, utilizing the unique uplink / downlink asymmetry of drone communication (typically, uplink video / telemetry data volume is large, while downlink control command volume is small but continuous) and communication continuity for secondary confirmation, thereby improving the accuracy of drone identification and reducing false alarms.

[0158] Therefore, when performing secondary verification by combining the traffic behavior characteristics of user plane data streams with a pre-defined UAV communication behavior model, firstly, for user plane data streams that are initially determined to conform to the UAV service identification characteristics, their uplink and downlink traffic are accumulated separately according to the data stream transmission direction.

[0159] Uplink traffic: Terminal (drone) → Network (e.g., flight controller uploading video, location, sensor data);

[0160] Downlink traffic: Network → Terminal (e.g., ground station issuing control commands, flight route updates);

[0161] Traffic accumulation is typically measured in bytes or bits and is continuously added within the observation window.

[0162] 2. Record the duration of the user plane data stream from its first appearance;

[0163] While accumulating traffic, it is necessary to start timing from the first time the data stream is detected and record the duration of the data stream to determine whether the minimum observation period is met, so as to avoid misjudging instantaneous bursts of traffic.

[0164] 3. When the duration reaches or exceeds the set time window, determine whether the cumulative uplink traffic of the user plane data stream is greater than or equal to the uplink traffic threshold, and whether the cumulative downlink traffic is greater than or equal to the downlink traffic threshold. The set time window is a configurable minimum observation period required to determine traffic behavior.

[0165] Specifically, in this embodiment, the set time window is 5s~60s, for example 10s, 30s (configurable). This time window means that at least this long observation time is required before a judgment is made.

[0166] The uplink traffic threshold can be set to ≥5MB (reflecting video backhaul);

[0167] The downlink traffic threshold can be set to ≥100KB (reflecting continuous control commands).

[0168] Only when all three of the following conditions are met will it be ultimately determined to be network-connected drone communication:

[0169] 1. Preliminary feature (drone business identifier feature) matching;

[0170] 2. The duration of the current user plane data stream is greater than or equal to the set time window;

[0171] 3. The current user plane data stream has an uplink flow rate greater than or equal to the uplink threshold and a downlink flow rate greater than or equal to the downlink threshold.

[0172] In this embodiment, for user plane data streams marked as "suspected drones," their uplink and downlink traffic is continuously counted based on the determined data stream transmission direction, and the duration from the first occurrence is recorded. Only when the duration is ≥ a set time window (e.g., 15 seconds) is the cumulative uplink / downlink traffic checked to see if it exceeds a preset threshold. This mechanism ensures that a sufficiently long observation period is taken before making a judgment, avoiding interference from instantaneous traffic.

[0173] This embodiment introduces a time dimension constraint to effectively filter out ordinary users who briefly access drone-related services (such as webpage redirects and APP caching), significantly reducing the false alarm rate; the traffic threshold judgment is based on the idea of ​​traffic behavior modeling to enhance the robustness of recognition.

[0174] In one embodiment, the drone communication behavior model is set based on the typical business mode of connected drones, wherein the uplink traffic threshold is significantly greater than the downlink traffic threshold to reflect the asymmetric communication characteristics of connected drones, which are mainly video uploads and secondarily command issuances.

[0175] Specifically, based on the typical business model of connected drones (such as high-definition video transmission + low-frequency command issuance), the uplink traffic threshold is set to be much higher than the downlink threshold (e.g., 5MB uplink, 100KB downlink). This asymmetric model accurately depicts the "uplink-centric, downlink-secondary" communication nature of drones, significantly differentiating it from ordinary user traffic (usually downlink traffic is larger or symmetrical), thus forming a strong distinguishability; this behavioral characteristic is difficult to forge, enhancing the ability to resist malicious evasion.

[0176] In one embodiment, the process of parsing the user plane data stream according to the protocol may further include the following direction determination step:

[0177] Pre-build IP containers for core network devices;

[0178] The outer source IP or outer destination IP of the user plane data stream is matched with the container to obtain the direction determination result. The direction determination result is used for accurate classification of uplink / downlink traffic in traffic statistics.

[0179] If the outer source IP exists in the IP container of the core network device, then the user plane data stream is determined to be in the uplink direction.

[0180] If the outer destination IP exists in the IP container of the core network device, then the user plane data flow is determined to be in the downlink direction.

[0181] To correctly classify and aggregate the uplink and downlink traffic of user plane data streams, it is first necessary to determine the transmission direction of the user plane data stream. The specific process is as follows:

[0182] First, during system initialization, core network device IP containers are constructed based on device operating parameters;

[0183] Then, when parsing each user plane data stream, its outer source / destination IP is compared with the IP container of the core network device: if the outer source IP is in the container, it means that the data comes from the base station to the core network → uplink (drone → cloud); if the outer destination IP is in the container, it is downlink (cloud → drone).

[0184] The user plane data flow direction determination process in this embodiment can ensure the accuracy of uplink and downlink traffic statistics, which is a prerequisite for the effectiveness of the traffic behavior model. It utilizes prior knowledge of the operator's network topology to achieve efficient direction identification without relying on complex session reconstruction.

[0185] In one embodiment, when the traffic behavior characteristics meet the UAV communication behavior model, confirming that the user plane data stream corresponds to the connected UAV may include the following steps:

[0186] When the traffic behavior characteristics meet the UAV communication behavior model, check whether the flow record corresponding to the user plane data flow already exists in the suspected UAV container.

[0187] If so, remove the payload information in the stream record corresponding to the user plane data stream from the suspected drone container, and insert the payload information in the stream record corresponding to the user plane data stream into the preset confirmed drone container.

[0188] The payload information is output as the identification result of the connected drone. The payload information is used to trigger alarms, report to the regulatory platform and / or link with the countermeasure system.

[0189] In this embodiment, after the traffic behavior verification passes, it is checked whether the flow is already in the suspected drone container. If so, its payload information is removed from the suspected drone container and inserted into the confirmed drone container (such as ComfiredUavInfo) to complete the state transition. This ensures that the same data flow will not be confirmed or misjudged multiple times, and guarantees that the system has only one unique state (suspected / confirmed / non-drone) for each flow. At the same time, it enables timely clearing of the suspected cache to prevent memory leaks. Subsequently, the payload information is output as the final identification result, which is used to trigger alarms, report to the monitoring platform, or link with countermeasures (such as radio interference).

[0190] In one embodiment, the user plane data stream originates from the GTP-U interface of a 4G / 5G / 6G cellular network base station.

[0191] The GTP-U interface of 4G / 5G / 6G base stations is the standard bearer for current cellular-connected drone communication. GTP-U encapsulates all user data and is the only legitimate entry point for obtaining inner-layer communication content. This embodiment focuses on mainstream application scenarios, enhancing the relevance and feasibility of the solution.

[0192] It should be noted that the source of user plane data streams can also be extended to other tunneling protocols (such as SRv6).

[0193] like Figure 2 As shown, in order to better understand the working principle of the networked drone identification method of this application, the following is a complete flowchart illustrating the networked drone identification method:

[0194] 1. Parse the MAC layer from the input data stream to obtain the protocol indication for the next layer;

[0195] 2. If the result obtained in step 1 is a VLAN indication, then resolve the VLAN and obtain the next layer indication;

[0196] 3. If the instruction obtained in step 1 or step 2 is from the IP layer, then parse it according to the IP layer to obtain the outer source IP, the outer destination IP, and the instruction of the next layer protocol; if the instruction obtained in step 1 or step 2 is not from the IP layer, then do not continue processing.

[0197] 4. Perform direction detection on the data stream. The IP in the container CoreIP (core network device IP container) represents the IP of the core network device (the container CoreIP is constructed by the system during initialization based on the device's operating parameters). The specific matching algorithm is as follows: if the outer source IP exists in the container CoreIP, it means that the message is uplink; if the outer destination IP exists in the container CoreIP, it means that the message is downlink.

[0198] 5. If step 3 yields a UDP indication, continue with UDP parsing to obtain the source and destination ports of the UDP protocol layer; if step 3 yields a non-UDP indication, do not continue processing.

[0199] 6. Check if the value of the source port or destination port in step 4 is equal to the dedicated port 2152 of the base station user plane GTP data. If so, continue the subsequent parsing; otherwise, do not continue processing.

[0200] 7. Continue parsing the data according to the GTP protocol and provide the parsing address for the next layer of data;

[0201] 8. Continue parsing the data according to the IP layer protocol to obtain the inner source IP of GTP, the inner destination IP of GTP, and the lower layer protocol indication; construct the user-side payload information based on the data flow direction and the parsed content.

[0202] 9. As instructed in step 7, if it is UDP or TCP, continue with the subsequent processing; otherwise, do not continue processing.

[0203] 10. Following the instructions in step 8, parse the UDP or TCP protocol to obtain the GTP inner source PORT and GTP inner destination PORT;

[0204] 11. Based on the results of step 9, continue with the specific application protocol parsing:

[0205] If the inner PORT is 53, then it is resolved according to the DNS protocol, and the DNS Name information is obtained;

[0206] If the inner PORT is 80, then it is parsed according to the HTTP protocol, and the URI information is obtained;

[0207] If the inner PORT contains 443, it is parsed according to the TLS protocol, and the SNI information is obtained.

[0208] 12. Based on the GTP inner source IP, GTP inner destination IP, GTP inner source PORT, and GTP inner destination PORT of the message, construct a combined KEY and search for it in the Flow Map container (the Flow Map is a container that stores KEY-VALUEs of flow information). If not found, create a FLOW_VALUE and insert the KEY and FLOW_VALUE values ​​into the Flow Map container. If found, it means that the data of this flow already exists, so retrieve the corresponding FLOW_VALUE value. FLOW_VALUE is a structure space that stores the payload information, DNS Name information, URI information, SNI information, traffic statistics information, etc. constructed in the previous step.

[0209] 13. Check if any of the DNS Name, URI, and SNI information on FLOW_VALUE has a value. If a value exists, search in the pre-set string feature container Character Map (this container is loaded when the software system starts, and its content is the address information that various drones need to access). If found, it means that the stream data is related to drone business. Based on the already matched direction information, insert the payload information on FLOW_VALUE into the suspected drone container SuspectUavInfo.

[0210] 14. Continue performing traffic statistics on the FLOW_VALUE stream information. Based on the message direction, calculate the cumulative uplink and downlink traffic on this stream, as well as the stream duration. Check if the set model values ​​are met (time t, uplink traffic threshold ul_limit, downlink traffic threshold dl_limit, indicating that within time t, the uplink and downlink traffic must reach the set threshold values. The model principle is based on the objective situation of unequal uplink and downlink traffic when connected drones transmit data through 4G / 5G / 6G networks). If the current stream meets the traffic model settings, check if the payload information on FLOW_VALUE is already in the suspected drone container SuspectUavInfo. If it already exists, delete the payload information from the suspected drone container SuspectUavInfo and insert the payload information into the confirmed drone container ComfiredUavInfo. Thus, drone information is accurately and in real-time captured through a combined strategy.

[0211] 15. Continue processing the next data stream to identify new drone information.

[0212] like Figure 3As shown, this application embodiment also provides an electronic device 3, which may include:

[0213] The system includes a memory 301, a processor 302, and a computer program 303 stored in the memory 301 and executable on the processor 302. The memory 301 and the processor 302 communicate with each other via a bus 304. When the processor 302 executes the computer program 303, it implements the steps of the networked drone identification method as described in the above-described method embodiments of this application.

[0214] Specifically, electronic device 3 can be an intelligent device with memory and processor, such as an industrial control computer, PC, or smart mobile terminal, or a computer component with memory and processor, such as a CPU or GPU. In this embodiment, electronic device 3 is a drone control device or its control component.

[0215] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the networked drone identification method according to any one of the first objectives of this application.

[0216] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0217] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0218] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0219] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for identifying a connected unmanned aerial vehicle, characterized in that, The method comprises: acquiring a user plane data stream on a base station side in a cellular communication network; performing protocol analysis on the user plane data stream to extract inner layer communication characteristic information encapsulated in a tunnel protocol; based on the inner layer communication characteristic information, judging whether the user plane data stream matches a preset unmanned aerial vehicle service identification characteristic; if matching, combining traffic behavior characteristics of the user plane data stream with a preset unmanned aerial vehicle communication behavior model for secondary verification; when the traffic behavior characteristics satisfy the unmanned aerial vehicle communication behavior model, confirming that the user plane data stream corresponds to a network-connected unmanned aerial vehicle. 2.The method of claim 1, wherein, The protocol analysis on the user plane data stream to extract the inner layer communication characteristic information encapsulated in the tunnel protocol comprises: sequentially analyzing link layer, network layer and transport layer protocols of the user plane data stream; when detecting that the transport layer protocol is UDP and the port number is 2152, determining that a GTP tunnel exists; analyzing a GTP protocol header to acquire an inner layer IP data packet carried thereby; analyzing the inner layer IP data packet to obtain the inner layer communication characteristic information, wherein the inner layer communication characteristic information comprises an inner layer source IP address, an inner layer destination IP address, an inner layer transport layer protocol type, an inner layer source port and an inner layer destination port. 3.The method of claim 2, wherein, The protocol analysis on the user plane data stream to extract the inner layer communication characteristic information encapsulated in the tunnel protocol further comprises: if the inner layer transport layer protocol type is UDP or TCP, identifying an application layer protocol type according to an inner layer port, and classifying and analyzing an application layer data packet carried by the inner layer transport layer according to the application layer protocol type to obtain application layer characteristic information included in the inner layer communication characteristic information, wherein, when the inner layer port is 53, analyzing the application layer data packet according to a DNS protocol to extract DNS Name information, when the inner layer port is 80, analyzing the application layer data packet according to an HTTP protocol to extract request URI information, when the inner layer port is 443, analyzing the application layer data packet according to a TLS protocol to extract SNI information, the extracted DNS Name information, URI information or SNI information is the application layer characteristic information. 4.The method of claim 3, wherein, The judgment based on the inner layer communication characteristic information whether the user plane data stream matches a preset unmanned aerial vehicle service identification characteristic comprises: constructing a flow identification key based on an inner layer source IP address, an inner layer destination IP address, an inner layer source port and an inner layer destination port of the inner layer communication characteristic information; finding or creating a flow record corresponding to the flow identification key in a preset flow information container; writing application layer characteristic information in the extracted inner layer communication characteristic information into the flow record; checking whether the application layer characteristic information matches any string in a preloaded unmanned aerial vehicle service string characteristic container; if matching, determining that the user plane data stream preliminarily conforms to the unmanned aerial vehicle service identification characteristic, and inserting payload information in the flow record into a preset suspected unmanned aerial vehicle container. 5.The method of claim 4, wherein, The UAV service string feature container is preloaded when the network-connected UAV identification program is started, and the UAV service string feature container contains domain names, API paths, and / or TLS hostnames related to mainstream network-connected UAV manufacturer cloud platforms, flight control services, and / or video backhaul services. 6.The method of claim 1, wherein, The secondary verification of the traffic behavior feature of the user plane data stream against the preset UAV communication behavior model includes: For a user plane data stream that preliminarily meets the UAV service identification feature, the uplink traffic and downlink traffic of the user plane data stream are respectively accumulated according to the data stream transmission direction; The duration of the user plane data stream since the first appearance is recorded; When the duration reaches or exceeds a set time window, it is determined whether the accumulated uplink traffic of the user plane data stream is greater than or equal to an uplink traffic threshold, and whether the accumulated downlink traffic is greater than or equal to a downlink traffic threshold, wherein the set time window is a configurable minimum observation period required for traffic behavior judgment. 7.The method of claim 6, wherein, The UAV communication behavior model is set based on the typical service mode of network-connected UAVs, wherein the uplink traffic threshold is significantly greater than the downlink traffic threshold to reflect the communication asymmetric characteristics of network-connected UAVs, which mainly upload videos and secondarily issue instructions. 8.The method of claim 6, wherein, In the process of protocol analysis of the user plane data stream, the following direction determination steps are also included: A core network device IP container is pre-constructed; The outer source IP or outer destination IP of the user plane data stream is matched with the container to obtain a direction determination result, which is used for accurate classification of uplink / downlink traffic in traffic statistics, wherein If the outer source IP exists in the core network device IP container, the user plane data stream is determined to be in the uplink direction, If the outer destination IP exists in the core network device IP container, the user plane data stream is determined to be in the downlink direction. 9.The method of claim 4, wherein, When the traffic behavior feature meets the UAV communication behavior model, the user plane data stream corresponding to the network-connected UAV is confirmed, including: When the traffic behavior feature meets the UAV communication behavior model, it is checked whether the flow record corresponding to the user plane data stream already exists in the suspected UAV container; If so, the payload information in the flow record corresponding to the user plane data stream is removed from the suspected UAV container, and the payload information in the flow record corresponding to the user plane data stream is inserted into the preset confirmed UAV container; The payload information is output as the network-connected UAV identification result, wherein the payload information is used to trigger an alarm, report to a regulatory platform, and / or interact with a countermeasures system.

10. The method of claim 1-9, wherein, The user plane data stream is derived from user plane interface data packets of 4G / 5G / 6G cellular network base stations.

Images