UAS authentication and security establishment

Abstract

Devices, methods, and systems are disclosed for UAS authentication and security establishment. One device includes a transceiver that sends, from a first network function of a mobile wireless communication network to a UAS service supplier (“USS”) / UAS traffic management (“UTM”), an authentication request message from a user equipment (“UE”), the UE including at least one of a drone (“UAV”) and a UAV controller (“UAV-C”). The transceiver receives, at the first network function from the USS / UTM, an authentication response message, the authentication response message including a UAS identifier and a UAS security context.

Description

[0001] Cross-reference of related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 062,286, filed August 6, 2020, entitled “Apparatus, methods, and systems for UAS command and control security setup and management in 3GPP networks,” which is incorporated herein by reference. Technical Field

[0003] The topics discussed in this article broadly relate to wireless communication, and more specifically, to UAS authentication and security establishment. Background Technology

[0004] In some wireless communication systems, user equipment (“UE”) can connect to the fifth-generation (“5G”) core network (“5GC”) in a public terrestrial mobile network (“PLMN”). In a wireless network, an unmanned aerial vehicle (“UAS”) system can include unmanned aerial vehicles (“UAVs”) communicating via the wireless communication system, a UAV controller (“UAV-C”), a UAS service provider (“USS”), and UAS traffic management (“UTM”) functions. Summary of the Invention

[0005] A process for UAS authentication and security establishment is disclosed. This process can be implemented by devices, systems, methods, and / or computer program products.

[0006] A method for a network function (e.g., UCFS, UAS NF, NEF) in a mobile communication network includes sending an authentication request message from a user equipment (“UE”) to a UAS service provider (“USS”) / UAS traffic management (“UTM”) from a first network function of the mobile wireless communication network. The UE includes at least one of a drone (“UAV”) and a UAV controller (“UAV-C”). In some embodiments, the method includes receiving an authentication response message from the USS / UTM at the first network function. The authentication response message includes a UAS identifier and a UAS security context, the UAS security context including a UAS root key and a UAS root key identifier.

[0007] Another method for network functions (e.g., UCFS, UCF) includes receiving a command and control (“C2”) pairing request from a first user equipment (“UE”) device at a network function of a mobile wireless communication network. The C2 pairing request includes at least one parameter for establishing secure communication between the first UE device and a second UE device. In one embodiment, the method includes verifying at least one parameter at a network function based on a locally stored unmanned aerial system (“UAS”) security context at the network function, the UAS including the first and second UE devices. In one embodiment, a second method includes, in response to successful verification of at least one parameter, sending a C2 pairing request from the network function to a UAS service provider (“USS”) / UAS traffic management (“UTM”); receiving a C2 pairing response from the USS / UTM at the network function; and sending the C2 pairing response from the network function to the first UE device to establish secure communication.

[0008] A method of a user equipment device (“UE”) (e.g., UAV, UAV-C) includes sending a command and control (“C2”) pairing request from a first user equipment device (“UE”) to a network function of a mobile wireless communication network to establish secure communication between the first UE device and a second UE device. The C2 pairing request includes at least one of an identifier for the first UE device, an identifier for the second UE device, an identifier for an unmanned aerial vehicle system (“UAS”) including the first and second UE devices, security capability information for the first UE device, a UAS authorization token, a nonce, a UAS security information identifier, a UAS root key, and a UAS session key identifier.

[0009] In one embodiment, the method includes receiving a C2 pairing response from a network function, the C2 pairing response including at least one of a success indicator, a UAS session key identifier, a UAS session key, UAS security information, a selected security algorithm, and an address for a second UE device. In another embodiment, the method includes deriving a second UAS session key using a locally stored UAS root key and deriving a second UAS session key identifier using the second UAS session key; verifying that the second UAS session key identifier matches the UAS session key identifier received in the C2 pairing response; deriving at least one security key based on the UAS session key for protecting communication between the first and second UE devices; and establishing secure communication with the second UE device using the at least one security key. Attached Figure Description

[0010] A more detailed description of the embodiments briefly described above will be presented by referring to the specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only some embodiments and are therefore not intended to be limiting; the embodiments will be described and illustrated with additional features and details using the drawings, wherein:

[0011] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system used for UAS authentication and security establishment;

[0012] Figure 2 This is a signal flow diagram illustrating one embodiment of the process used for UAS authentication and key establishment;

[0013] Figure 3 This is a signal flow diagram illustrating one embodiment of the process used for C2 safe mode commands;

[0014] Figure 4a depicts the first option of the UAS key hierarchy;

[0015] Figure 4b depicts the second option of the UAS key level;

[0016] Figure 5 This is a signal flow diagram illustrating the first option of the process for setting up command and control safety between UAV and UAV-C;

[0017] Figure 6 This is a signal flow diagram illustrating the second option of the process for setting up command and control safety settings between UAV and UAV-C;

[0018] Figure 7 This is a signal flow diagram illustrating one embodiment of the process for setting up command and control security between a UAV and a TPAE;

[0019] Figure 8a is a signal flow diagram illustrating one embodiment of the process for SEAL-based UAS authentication;

[0020] Figure 8b is a signal flow diagram illustrating one embodiment of the process for SEAL-based UAS key management;

[0021] Figure 9 An example of an AKMA-based UAS key hierarchy is described;

[0022] Figure 10 This is a signal flow diagram illustrating one embodiment of the AKMA-based UAS key generation process for C2 security establishment;

[0023] Figure 11 This is a block diagram illustrating one embodiment of a user equipment device that can be used for UAS authentication and security establishment;

[0024] Figure 12 This is a block diagram illustrating one embodiment of a network device that can be used for UAS authentication and security establishment;

[0025] Figure 13 This is a flowchart illustrating one embodiment of a method for UAS authentication and security establishment;

[0026] Figure 14 This is a flowchart illustrating an embodiment of a method for UAS authentication and security establishment; and

[0027] Figure 15 This is a flowchart illustrating one embodiment of a method for UAS authentication and security establishment. Detailed Implementation

[0028] Those skilled in the art will understand that aspects of the embodiments can be embodied as a system, device, method, or program product. Therefore, embodiments can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects.

[0029] For example, the disclosed embodiments can be implemented as hardware circuitry, including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, processes, or functions.

[0030] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In certain embodiments, the storage device uses only signals to access the code.

[0031] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, microelectromechanical, or semiconductor systems, devices, or apparatuses, or any suitable combination of the foregoing.

[0032] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store programs for use by or in conjunction with an instruction execution system, device, or apparatus.

[0033] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, etc., and traditional procedural programming languages ​​such as the "C" programming language, etc., and / or machine languages ​​such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network including a local area network ("LAN"), a wireless LAN ("WLAN"), or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet using an Internet service provider ("ISP").

[0034] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. In the following description, numerous specific details, such as programming examples, software modules, user selection, online transactions, database queries, database structures, hardware modules, hardware circuits, and hardware chips, are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0035] Throughout this specification, references to "an embodiment," "embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Therefore, the phrases "in an embodiment," "in an embodiment," and similar language appearing throughout this specification may not necessarily refer to the same embodiment, but rather to "one or more, but not all, embodiments," unless otherwise expressly stated. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless otherwise expressly stated. Unless otherwise expressly stated, the list of enumerated items does not imply that any or all items are mutually exclusive. Unless otherwise expressly stated, the terms "a / an" and "the" also refer to "one or more."

[0036] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of” includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C, excluding combinations of A, B, and C. As used herein, “a member selected from a group consisting of A, B, and C” includes one and only one of A, B, or C, excluding combinations of A, B, and C. As used herein, “members selected from a group consisting of A, B, and C, and combinations thereof” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0037] The following describes aspects of embodiments with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to embodiments. It should be understood that each block in the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that instructions executable via the processor of the computer or other programmable data processing apparatus create a manner for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0038] The code may also be stored in a storage device that can instruct a computer, other programmable data processing equipment or other devices to function in a particular manner, causing the instructions stored in the storage device to produce an article of art, including instructions that implement the functions / actions specified in the diagrams and / or block diagrams.

[0039] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0040] The flowcharts and / or block diagrams in the illustrations depict the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this regard, each box in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0041] It should also be noted that in some alternative implementations, the functions mentioned in the boxes may not be performed in the order shown in the figures. For example, two boxes shown consecutively may actually be performed substantially simultaneously, or these boxes may sometimes be performed in reverse order, depending on the functions involved. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated diagrams are conceivable.

[0042] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not intended to limit the scope of the corresponding embodiments. In practice, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumerated steps of a depicted embodiment. It should also be noted that each box in a block diagram and / or flowchart, and combinations of boxes in block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware, or a combination of dedicated hardware and code, performing the specified function or action.

[0043] The description of the elements in each figure can be referenced to the elements in the accompanying drawings. In all figures, similar numbers refer to similar elements, including alternative embodiments of similar elements.

[0044] Generally, this disclosure describes systems, methods, and apparatuses for UAS authentication, authorization, and security establishment. In some embodiments, the methods can be executed using computer code embedded in a computationally readable medium. In some embodiments, the apparatus or system may include a computer-readable medium containing computer-readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of the solution described below.

[0045] In one embodiment, the 3GPP system supports UAS, thereby providing ubiquitous coverage, seamless mobility, high reliability, and, importantly, enhanced security for UAV communications, which are controlled by multiple parties such as UAV-C, UAS service provider / UAS traffic management (“USS / UTM”), and / or a third-party authorized entity (“TPAE”). In some embodiments, conventional 5G systems do not support UAS operations on 5G infrastructure (e.g., command and control (“C2”) signaling between the UAV and control parties such as UAV-C, USS / UTM, and TPA E), and therefore no security features are available to protect UAS communications.

[0046] The solutions proposed in this disclosure provide a C2 secure establishment process to support data protection (e.g., confidentiality, integrity, and replay) of C2 signaling sent from UAV-C, USS / UTM, and / or TPAE to UAV, thereby enhancing overall UAS security in 5G systems.

[0047] Figure 1 A wireless communication system 100 for UAS authentication and security establishment according to embodiments of the present disclosure is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a fifth-generation radio access network (“5G-RAN”) 115, a mobile core network 140, a UAV gateway 109, and a UAS 101. The 5G-RAN 115 and the mobile core network 140 form a mobile communication network. The 5G-RAN 115 may consist of a 3GPP access network 120 including at least one cellular base station unit 121 and / or a non-3GPP access network 130 including at least one access point 131. The remote unit 105 communicates with the 3GPP access network 120 using a 3GPP communication link 123 and / or communicates with the non-3GPP access network 130 using a non-3GPP communication link 133. Although Figure 1 The text depicts a specific number of remote units 105, 3GPP access networks 120, cellular base station units 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140. However, those skilled in the art will recognize that the wireless communication system 100 may include any number of remote units 105, 3GPP access networks 120, cellular base station units 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140.

[0048] In one implementation, RAN 120 conforms to the 5G system specified in the 3rd Generation Partnership Project (“3GPP”) specifications. For example, RAN 120 may be an NG-RAN implementing NR RAT and / or LTE RAT. In another instance, RAN 120 may include a non-3GPP RAT (e.g., Or an IEEE 802.11 series compliant WLAN. In another embodiment, RAN 120 conforms to the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement other open or proprietary communication protocols, such as Global Microwave Access Interoperability (“WiMAX”) or the IEEE 802.16 series standards and other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0049] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., TVs connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including surveillance cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 includes wearable devices such as smartwatches, fitness trackers, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as UE, subscriber unit, mobile station, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or other terms used in the art. In various embodiments, remote unit 105 includes a subscriber identity and / or identification module (“SIM”) and a mobile device (“ME”) that provides mobile terminal functions (e.g., radio transmission, handover, voice encoding and decoding, error detection and correction, signaling, and SIM access). In some embodiments, the remote unit 105 may include a terminal device (“TE”) and / or be embedded in an electrical appliance or apparatus (e.g., a computing device as described above).

[0050] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., TVs connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including surveillance cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 may include wearable devices such as smartwatches, fitness trackers, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as UE, subscriber unit, mobile station, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or other terms used in the art.

[0051] Remote unit 105 can communicate directly with one or more cellular base station units 121 in 3GPP access network 120 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, UL and DL communication signals can be carried via 3GPP communication link 123. Similarly, remote unit 105 can communicate with one or more access points 131 in non-3GPP access network 130 via UL and DL communication signals carried via non-3GPP communication link 133. Here, access networks 120 and 130 are intermediate networks providing remote unit 105 with access to mobile core network 140.

[0052] In some embodiments, remote unit 105 communicates with a remote host (e.g., in data network 150 or data network 160) via a network connection to mobile core network 140. For example, an application 107 in remote unit 105 (e.g., a web browser, media client, telephone, and / or Voice over Internet Protocol (“VoIP”) application) can trigger remote unit 105 to establish a Protocol Data Unit (“PDU”) session (or other data connection) with mobile core network 140 via 5G-RAN 115 (i.e., via 3GPP access network 120 and / or non-3GPP network 130). Mobile core network 140 then uses the PDU session to relay traffic between remote unit 105 and the remote host. The PDU session represents a logical connection between remote unit 105 and User Plane Function (“UPF”) 141.

[0053] To establish a PDU session (or PDN connection), remote unit 105 must register with mobile core network 140 (also referred to as "connecting to mobile core network" in the context of fourth-generation ("4G") systems). It should be noted that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 140. Therefore, remote unit 105 may have at least one PDU session for communicating with packet data network 150. Alternatively, remote unit 105 may have at least one PDU session for communicating with packet data network 160. Remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0054] In a 5G system (“5GS”) context, the term “PDU session” refers to a data connection that provides an end-to-end (“E2E”) user plane (“UP”) connection between the remote unit 105 and a specific data network (“DN”) via the UPF131. A PDU session supports one or more Quality of Service (“QoS”) streams. In some embodiments, there may be a one-to-one mapping between QoS streams and QoS profiles, such that all packets belonging to a particular QoS stream have the same 5G QoS identifier (“5QI”).

[0055] In scenarios such as Evolved Packet System (“EPS”) 4G / LTE systems, a Packet Data Network (“PDN”) connection (also known as an EPS session) provides an end-to-end (E2E) connection between the remote unit and the PDN. The PDN connection process establishes an EPS bearer, which is a tunnel between the remote unit 105 and the packet gateway (“PGW”, not shown) in the mobile core network 130. In some embodiments, there may be a one-to-one mapping between the EPS bearer and a QoS profile, such that all packets belonging to a particular EPS bearer have the same QoS Class Identifier (“QCI”).

[0056] As described in more detail below, remote unit 105 may use a first data connection (e.g., a PDU session) established with the first mobile core network 130 to establish a second data connection (e.g., part of a second PDU session) with the second mobile core network 140. When establishing a data connection (e.g., a PDU session) with the second mobile core network 140, remote unit 105 registers with the second mobile core network 140 using the first data connection.

[0057] Cellular base station unit 121 may be distributed across a geographical area. In some embodiments, cellular base station unit 121 may also be referred to as an access terminal, base station, Node-B (“NB”), evolved Node-B (abbreviated as eNodeB or “eNB”, also known as Evolved Universal Terrestrial Radio Access Network (“E-UTRAN”) Node-B), 5G / NR Node-B (“gNB”), home Node-B, relay node, apparatus, or any other term used in the art. Cellular base station unit 121 is typically part of a radio access network (“RAN”) such as 3GPP access network 120, which includes one or more controllers communicatively coupled to one or more corresponding cellular base station units 121. These and other elements of the radio access network are not shown but are generally well known to those skilled in the art. Cellular base station unit 121 is connected to mobile core network 140 via 3GPP access network 120.

[0058] Cellular base station unit 121 can serve multiple remote units 105 within a service area (e.g., a cell or cell sector) via 3GPP wireless communication link 123. Cellular base station unit 121 can directly communicate with one or more of the remote units 105 via communication signals. Generally, cellular base station unit 121 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried via 3GPP communication link 123. 3GPP communication link 123 can be any suitable carrier in licensed or unlicensed radio spectrum. 3GPP communication link 123 facilitates communication between one or more remote units 105 and / or one or more cellular base station units 121. It should be noted that during NR operation on unlicensed spectrum (referred to as "NR-U"), base station unit 121 and remote units 105 communicate via unlicensed (i.e., shared) radio spectrum.

[0059] Non-3GPP access network 130 can be distributed across a geographical area. Each non-3GPP access network 130 can serve multiple remote units 105 within a service area. Access point 131 in non-3GPP access network 130 can communicate directly with one or more remote units 105 by receiving UL communication signals and transmitting DL communication signals to serve remote units 105 in the time, frequency, and / or spatial domains. Both UL and DL communication signals are carried via non-3GPP communication link 133. 3GPP communication link 123 and non-3GPP communication link 133 can employ different frequencies and / or different communication protocols. In various embodiments, access point 131 can communicate using unlicensed radio spectrum. Mobile core network 140 can provide services to remote units 105 via non-3GPP access network 130, as described in more detail herein.

[0060] In some embodiments, non-3GPP access network 130 is connected to mobile core network 140 via interoperability entity 135. Interoperability entity 135 provides interoperability between non-3GPP access network 130 and mobile core network 140. Interoperability entity 135 supports connectivity via “N2” and “N3” interfaces. As depicted, both 3GPP access network 120 and interoperability entity 135 use the “N2” interface to communicate with AMF 143. 3GPP access network 120 and interoperability entity 135 also use the “N3” interface to communicate with UPF 141. Although depicted outside of mobile core network 140, in other embodiments, interoperability entity 135 may be part of the core network. Although depicted outside of non-3GPP RAN 130, in other embodiments, interoperability entity 135 may be part of non-3GPP RAN 130.

[0061] In one embodiment, UAS 101 includes components, networks, hardware, software, etc., for unmanned aircraft operation between UAV 106 (e.g., a drone) and UAV controller 108. UAV 106 may refer to an aircraft without a human pilot, crew, or passengers remotely controlled using UAV controller 108. UAV controller 108 may refer to a device configured to wirelessly transmit commands to UAV 106, for example, via mobile core network 140, access networks 120, 130, etc., for controlling the UAV, such as its speed, direction, orientation, etc. UAS operator 102 may be a person operating UAV 106 (e.g., via UAV controller 108) and typically requesting flight authorization. UAV 106 and UAV controller 108 may each be a UE in wireless communication system 100 and / or may include an instance of remote unit 105. Therefore, UAV 106 and / or UAV controller 108 may communicate with access network 120 to access services provided by mobile core network 140.

[0062] In some embodiments, UAV 106 and / or UAV-C controller 108 communicate with the UAV Flight Enablement Subsystem (“UFES”) / UAS Network Function (“UAS-NF”) / Network Exposure Function (“NEF”) 155 (collectively referred to herein as UFES 155) and / or USS / UTM 157 via a network connection to the mobile core network 140. In one embodiment, the UAS Network Function is supported by the NEF and is used to expose services externally to the USS. The UAS-NF utilizes existing NEF / SCEF exposure services for UAV / UAS authentication / authorization, UAV flight authorization, UAV-UAV-C pairing authorization and related revocation; QoS / traffic filtering for location reporting and control of C2 communications. In one embodiment, the USS / UTM 157 provides a set of overlapping USS to assist UAV 106 operator 102 in safe and compliant operations. Services may include resolving flight plan conflicts, remote identification, etc.

[0063] In one embodiment, UAV 106 and / or UAV controller 108 may use RAN 115 to establish a PDU session (or similar data connection) with mobile core network 140. Mobile core network 140 may then use the PDU session to relay traffic between UAV 106 and UAV controller 108 and packet data network 150.

[0064] In some embodiments, the non-3GPP access network 130 may be controlled by the operator of the mobile core network 140 and may have direct access to the mobile core network 140. This type of non-3GPP AN deployment is referred to as a “trusted non-3GPP access network”. When the non-3GPP access network 130 is operated by a 3GPP operator or a trusted partner, it is considered “trusted” and supports certain security features, such as strong air interface encryption. Conversely, a non-3GPP AN deployment that is not controlled by the operator (or trusted partner) of the mobile core network 140, does not have direct access to the mobile core network 140, or does not support certain security features is referred to as an “untrusted” non-3GPP access network. The interoperability entity 135 deployed in the trusted non-3GPP access network 130 may be referred to herein as a Trusted Network Gateway Function (“TNGF”). The interoperability entity 135 deployed in the untrusted non-3GPP access network 130 may be referred to herein as a Non-3GPP Interoperability Function (“N3IWF”). Although depicted as part of a non-3GPP access network 130, in some embodiments, the N3IWF may be part of a mobile core network 140 or may be located in a data network 150.

[0065] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which may be coupled to a data network 150, such as the Internet and private data networks, as well as other data networks. The remote unit 105 may have a subscription or other account with the mobile core network 140. Each mobile core network 140 belongs to a single Public Land Mobile Network (“PLMN”). This disclosure is not intended to be limited to any particular implementation of a wireless communication system architecture or protocol.

[0066] The mobile core network 140 includes several network functions (“NFs”). As depicted, the mobile core network 140 includes at least one UPF (“UPF”) 141. The mobile core network 140 also includes multiple control plane functions, including but not limited to Access and Mobility Management Functions (“AMF”) 143, Session Management Functions (“SMF”) 145, Policy Control Functions (“PCF”) 146, Authentication Server Functions (“AUSF”) 147, Unified Data Management (“UDM”) and Unified Data Repository Functions (“UDR”) serving 5G-RAN 115.

[0067] In the 5G architecture, UPF 141 is responsible for packet routing and forwarding, packet inspection, QoS processing, and external PDU sessions for interconnecting data networks (“DN”). AMF 143 is responsible for NAS termination signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. SMF 145 is responsible for session management (i.e., session establishment, modification, and release), remote unit (i.e., UE) IP address allocation and management, DL data notification, and UPF traffic steering configuration to achieve appropriate traffic routing.

[0068] PCF 146 is responsible for unifying the policy framework, thereby providing policy rules for CP functions and accessing subscription information for policy decisions in UDR. AUSF 147 acts as an authentication server.

[0069] The UDM is responsible for generating authentication and key negotiation (“AKA”) credentials, user identification processing, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to serve various network functions. For example, the UDR can store subscription data, policy-related data, subscriber-related data that can be exposed to third-party applications, etc. In some embodiments, the UDM and UDR are located in the same location and are described as a combined entity “UDM / UDR”149.

[0070] In various embodiments, the mobile core network 140 may also include a network exposure function (“NEF”) (which enables customers and network partners to easily access network data and resources, for example, via one or more APIs), a network repository function (“NRF”) (which provides NF service registration and discovery, enabling NFs to recognize appropriate services from each other and communicate with each other via application programming interfaces (“APIs”), or other NFs defined for 5GC. In some embodiments, the mobile core network 140 may include an authentication, authorization, and accounting (“AAA”) server.

[0071] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection uses a specific network slice. Here, "network slice" refers to a portion of the mobile core network 140 optimized for a specific traffic type or communication service. Network instances may be identified by S-NSSAI, while authorized remote units 105 are identified by NSSAI for a set of network slices they use. In some embodiments, various network slices may include separate instances of network functions, such as SMF and UPF 141. In some embodiments, different network slices may share some common network functions, such as AMF 143. For ease of illustration, Figure 1 The output does not show different network slices, but it is assumed that they support different network slices.

[0072] Despite Figure 1 While a specific number and type of network functions are depicted, those skilled in the art will recognize that the mobile core network 140 may include any number and type of network functions. Furthermore, in the case where the mobile core network 140 includes an EPC, the depicted network functions may be replaced with appropriate EPC entities (such as MME, S-GW, P-GW, HSS, etc.).

[0073] Although Figure 1 The described components of the 5G RAN and 5G core network, but the embodiments used for access authentication using pseudonyms on non-3GPP access are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth, ZigBee, Sigfoxx, etc. For example, in 4G / LTE variants involving EPC, AMF 143 can be mapped to MME, SMF to the control plane portion of PGW and / or MME, UPF 141 can be mapped to SGW and user plane portion of PGW, UDM / UDR 149 can be mapped to HSS, etc.

[0074] As depicted, a remote unit 105 (e.g., a UE) can connect to a mobile core network (e.g., a 5G mobile communication network) via two types of access: (1) via a 3GPP access network 120 and (2) via a non-3GPP access network 130. The first type of access (e.g., the 3GPP access network 120) uses 3GPP-defined types of wireless communication (e.g., NG-RAN), while the second type of access (e.g., the non-3GPP access network 130) uses non-3GPP-defined types of wireless communication (e.g., WLAN). 5G-RAN 115 refers to any type of 5G access network that can provide access to the mobile core network 140, including the 3GPP access network 120 and the non-3GPP access network 130.

[0075] To address the aforementioned issues of protecting UAS communications through 5G systems, the solution proposed in this disclosure provides a C2 secure establishment process to support data protection (e.g., confidentiality, integrity, and replay) of C2 signaling sent from UAV-C, USS / UTM, and / or TPAE to UAV, thereby achieving overall UAS security in 5G systems.

[0076] In one embodiment, a 3GPP system supports User-Agent Systems (UAS), providing ubiquitous coverage, seamless mobility, high reliability, and enhanced security. For example, a 5G system can be used to enable remote identification and tracking of UASs outside of line-of-sight scenarios, and can allow only authorized UAS operations.

[0077] In some embodiments, security is critical to supporting the deployment of secure UAS systems. This includes aspects such as identity confidentiality, prevention of spoofing attacks, different integrity and privacy protection levels across different connections, signaling and data, and non-repudiation of data exchange at the application layer. Solutions are needed to ensure a robust overall system that meets the needs of stakeholders (e.g., regulatory bodies, network operators), which requires consideration of the security aspects of the UAS system.

[0078] In some embodiments, the following architectural requirements and assumptions are considered for UAS connectivity, identification, and tracking. In one embodiment, the 3GPP system should enable the UTM 157 to associate the UAV 106 and the UAV controller 108, and to identify both the 3GPP-networked UAV controller 108 and the non-3GPP-networked UAV controller 108.

[0079] In one embodiment, each UAS 101 consists of a UAV controller 108 and a UAV 106. UTM 157 may include a set of functions defined outside the 3GPP system and subject to specific region requirements. Connections for commanding and controlling UAV 106 may be mutually exclusive between UAV 106 and UAV controller 108, or TPAE, or UTM 157.

[0080] In one embodiment, a CAA-level UAV identifier is assigned to UAV 106 via a function in the aerospace domain (e.g., USS 157) or via a function in USS / UTM 157, and a CAA-level UAV identifier can also be assigned to networked UAV-C 108. This assigned identifier can be used for remote identification and tracking. In one embodiment, the 3GPP system uses the 3GPP UAV ID to identify UAV 106.

[0081] In one embodiment, for both networked and non-networked UAV controllers 108, at least authorization, or even authentication, can be granted between UAV 106 and UAV controller 108 for UAV3 or UAV5 reference points. When executed, pairing authorization / authentication is granted by the USS / UTM, not by the 3GPP system. The 3GPP system implements this authorization process. The MNO is aware of the result of this authorization / authentication so that the USS / UTM 157 can establish a connection between UAV 106 and UAV controller 108. In one embodiment, UAV 106 is authorized to connect to USS 157 via UAV9 reference point based on existing MNO policies and is permitted to establish a connection with the data network name (“DNN”) to exchange traffic with USS 157 without USS authorization.

[0082] In one embodiment, the subject matter disclosed herein proposes a solution for establishing a C2 security context and protecting C2 (application data) traffic carried between UAV 106 and various parties such as UAV-C 108, UTM / USS 157, TPAE, etc.

[0083] Generally, this disclosure focuses on UAS authentication and key management, as well as the C2 security setup process. For UAS authentication and key management, a UAS control function (“UCF”), also known as a UAS management function (“UASMF”) / UAS network function (“UASNF”), is introduced, which performs UAS-based control and management operations on behalf of the UTM / USS in a 3GPP network. In one embodiment, the UAS network function is supported by the NEF and used to expose services externally to the USS. The UASNF utilizes existing NEF / SCEF exposure services for UAS / UAV authentication / authorization, UAV flight authorization, UAV-UAVC pairing authorization and related revocation; QoS / traffic filtering for location reporting and control of C2 communications. It should be noted that the UCF can be associated with and equivalent to UFES 155 and UAS AF / UASNF, for example, as defined in TR 23.754. Therefore, the general term UFES155 will be used in the remainder of this disclosure, and all new features and operations of UFES 155 described in this disclosure are applicable to the new 3GPP network function UCF.

[0084] In one embodiment, the USS / UTM 157 provides C2 assistance information to other network functions (“NFs”) in the 3GPP network (such as UCF / UFES / UASNF / AMF / SMF) to assist in the selection of the appropriate UAV3 interface (e.g., intra-PLMN UAV3 or inter-PLMN UAV3). The C2 assistance information may include a UAV3 type indicator and a UAV-C service PLMN ID.

[0085] In one embodiment, the USS / UTM 157 assigns an identifier to the UAS during successful UAS authentication and provides identifiers to UAV 106 and / or UAV-C 108 via the 3GPP NF. As used herein, the UAS ID can uniquely identify the UAV 106 and UAV-C 108 pair forming UAS 101. It should be noted that in one embodiment, the UAS ID described in this disclosure uses any ID suitable for assigning to the pairing functionality of UAV 106 and UAV-C 108.

[0086] In one embodiment, during successful UAS authentication (e.g., application-based or EAP-based authentication), in one embodiment, key K is derived from pre-configured long-term credentials. UAS(For example, a root key used to derive other security keys for UAS-related data protection). In other embodiments, during successful UAS authentication, an authorization token is exported to enable the USS / UTM157 or UFES155 to authorize the association between UAV C2 and UAV-C 108. Inputs used in the authorization token may include the UAS ID, UAV-CAA level ID, UAV-C ID, a random number, and a timestamp.

[0087] In one embodiment, an expiration / lifetime is assigned to the authorization token to define the duration for which UAV 106 can successfully associate with or obtain any service from UTM / USS 157 using the authorization token. In some embodiments, following successful UAS authentication between UAV 106 and UTM / USS 157, a C2 security mode command procedure is proposed to establish a C2 security context between UAV 106 and UFES 155 or UTM / USS 157.

[0088] In one embodiment, the proposal includes key K. UAS (e.g., UAS root key), K UAS-Sess A hierarchy of UAS keys (e.g., UAS / C2 session key), CCEK (e.g., command and control encryption key), and CCIK (e.g., command and control integrity key) to achieve UAS security.

[0089] Regarding the C2 security setup process, session keys are established for C2 (application data) confidentiality and integrity protection in the following scenarios: between UAV 106 and UAV-C 108 via the UAV3 interface, between UAV 106 and TPAE via the UAV4 interface, and between UAV 106 and UFES / UTM / USS via the UAV9 interface.

[0090] This disclosure also describes alternative solutions that support SEAL-based authentication and key management for communication between the UAS and 5G systems, as well as application-based authentication and key management (“AKMA”) for UAS security management.

[0091] In one embodiment, the UAS authentication and key negotiation process between UAV 106 and UAV-C 108 and USS / UTM 157 is described, along with an explanation of how to establish a C2 security context for UAV communication in USS / UTM 157. The embodiment also describes how the same process can be supported in an Evolved Packet System (“EPS”) 4G network. The following steps are described... Figure 2 The UAS authentication process 200 is shown in the figure.

[0092] In one embodiment, at steps 1 and 2 (see boxes 202 and 204), as a prerequisite, the UAS 102 operator registers UAV 106 with USS / UTM157 using any method outside the 3GPP operator scope. UAV 106 registers with the 5G network by performing primary authentication, for example, as specified in TS 33.501. In one embodiment, based on UAV 106 subscription information extracted from UDM / UDR 149, AMF 143 determines to trigger UAS authentication and sends a UAS authentication requirement indicator in the registration acceptance message.

[0093] In step 3, in one embodiment (see messaging 206-226), when UAV 106 receives a "UAS authentication required" indication from AMF 143, it initiates and performs UAS authentication using USS / UTM 157 via a 5G network control plane function (e.g., AMF 143, SMF 145, UFES 155, etc.). In one embodiment, procedure 200 defined herein specifies the UAS authentication-related request / response information exchanged between UAV 106 and USS / UTM 157, and thus this information can be carried via an application-based authentication protocol in the NAS layer or via an EAP-based authentication protocol. The UAS authentication message can be sent via a NAS connection that uses 5G NAS security to protect confidentiality and integrity.

[0094] At step 3a, in one embodiment (see message passing 206), UAV 106 sends a UAS authentication request message, which includes a CAA-level UAV ID with USS routing information (e.g., the USS routing information may be pre-configured in UAV 106 by USS 157 in step 1, or may be part of a CAA-level UAV ID), flight path data, and target CAV-C ID (e.g., to form a UAS).

[0095] At step 3b, in one embodiment (see box 208), if AMF 143 receives a CAA-level UAV ID with USS routing information, AMF 143 locally stores the CAA-level UAV ID with USS routing information. At step 3c, in one embodiment (see messaging 210), based on the USS routing information, AMF 143 forwards the UAS authentication request message to UFES 155 (e.g., directly or via SMF 145). Alternatively, in one embodiment, based on the USS routing information, AMF 143 may also forward the UAS authentication request message to USS / UTM 157 (e.g., directly or via UFES 155).

[0096] At step 3d, in one embodiment (see message passing 212), UFES 155 locally stores a CAA-level UAVID (if received) and forwards the received UAS authentication request message to USS / UTM 157. At step 3e, in one embodiment (see message passing 214), USS / UTM 157 performs an authentication method-specific message exchange with UAV 106 (e.g., application-based authentication or EAP-based authentication) to authenticate UAV 106 and to authenticate itself to UAV 106.

[0097] At step 3f, in one embodiment (see box 216), the USS / UTM 157 verifies the pre-configured CAA-level UAV ID (if provided by UAV 106 or based on a UAV subscription) after successful authentication and assigns a new CAA-level UAV ID to UAV 106. Furthermore, in one embodiment, if a UAV-C ID is received from UAV 106 in the authentication request, the USS / UTM 157 verifies whether UAV 106 is authorized to associate with the UAV-C ID to form UAS 101 based on UAV 106 and / or a UAS subscription.

[0098] In one embodiment, if the association verification between the UAV ID and UAV-C ID is successful, the USS / UTM 157 assigns a UASID to uniquely identify UAS 101 formed by UAV 106 and UAV-C108. In one embodiment, the USS / UTM 157 locally stores the IDs of UAV 106 and UAV-C 106, and the service network information (e.g., SN ID / service PLMNID and primary PLMN ID) of UAV 106 and UAV-C 108 after each successful UAS authentication of any UAV 106 or UAV-C108.

[0099] Furthermore, in one embodiment, the USS / UTM 157 checks whether UAV-C108 has recently been UAS authenticated based on UAS subscriptions, activity reports, and authentication status information (e.g., UAS status records) available in the USS / UTM 157. In one embodiment, if the UAV-C 108 authentication status record in the USS / UTM 157 indicates that it has recently been authenticated, the USS / UTM 157 generates C2 auxiliary information for UAV 106 based on the service network identifier of UAV-C 108. The C2 auxiliary information element (“IE”) may include the UAV-C ID, the UAV3 type indicator (e.g., intra-PLMN UAV3 / inter-PLMN UAV3), and the UAV-C service network ID.

[0100] In one embodiment, if UAS authentication is successful, the USS / UTM 157 generates the UAS root key K based on the long-term credentials stored in the UAV / UAS subscription information in the USS / UTM 157. UAS K UAS The ID can be easily derived from the USS / UTM 157 by generating a hash of the UAS root key using the UAS ID / CAA-level UAV ID. UAS The ID is used to uniquely identify the UAS root key in USS / UTM157.

[0101] In one embodiment, the USS / UTM 157 further uses, for example, CAA-level UAV ID, UAV-C ID, UAS ID, and K... UAS The input generates an authorization token. USS / UTM 157 also assigns a lifetime (e.g., validity period or duration) to the authorization token, which will be used by the 3GPP network to authorize UAVs during the establishment of C2 security for UAV communications 106.

[0102] In one embodiment, K UAS ID is generated as follows: K UAS ID:Hash(K UAS ||CAA-level UAV ID||UAS ID). Used to generate K UAS The hash function for the ID can be any hash function, such as SHA-2, SHA-3, etc.

[0103] In step 3g, in one embodiment (see message passing 218), in response to successful UAS authentication, the USS / UTM 157 sends a UAS authentication response message to the UFES 155. The UAS authentication response message may include a success indication, CAA-level UAVID, UAS ID, C2 assistance information, authorization token, and other information including K. UAS ID and key K UAS The UAS security context.

[0104] At step 3h, in one embodiment (see box 220), the UFES 155 receives the UAS authentication response message and locally stores the received CAA-level UAV ID, UAS ID, C2 auxiliary information (e.g., UAV-C ID, UAV3 type indicator (intra-PLMN UAV3 / inter-PLMN UAV3) and UAV-C service network ID), authorization token, and UAS security context (K). UAS ID, K UAS This is part of the UAS information (or UAS security context) of UAV 106.

[0105] In step 3i, in one embodiment (see message passing 222), UFES 155 sends the received UAS authentication response message to AMF 143. The UAS authentication response message includes a success indication, CAA-level UAV ID, UAS ID, C2 assistance information, authorization token, and UAS security context (K). UAS ID, K UAS ).

[0106] At step 3j, in one embodiment (see message passing 224), the AMF 143 locally stores the received CAA-level UAV ID, UAS ID, C2 auxiliary information (e.g., UAV-CID, UAV3 type indicator (intra-PLMN UAV3 / inter-PLMN UAV3) and UAV-C service network ID), authorization token, and UAS security context (K). UAS ID, K UAS This is part of the UAS information (or UAS security context) of UAV106.

[0107] In one embodiment, AMF 143 further sends a UAS authentication response message to UAV 106. The UAS authentication response message includes a success indication, CAA-level UAV ID, UAS ID, authorization token, and UAS security context (K). UAS ID).

[0108] In one embodiment, AMF 143 uses locally stored C2 association information and initiates a C2 connection via the UAV3 interface for communication between UAV 106 and UAV-C 108.

[0109] At step 3k, in one embodiment (see box 226), UAV 106 receives a UAV authentication response message, and upon receiving a "success indication," similar to USS / UTM 157, UAV 106 generates a UAS security context (K) based on the long-term credentials pre-configured in UAV 106 in step 1 and using the ID received in the UAS authentication response message (e.g., as in step 3f). UAS ID, K UAS ).

[0110] In one embodiment, UAV 106 verifies the locally generated K. UAS Is the ID the same as the K received in step 3j? UAS ID matching. In one embodiment, if the locally generated K... UAS ID and received K UASIf the IDs match, UAV 106 considers UAS authentication successful and locally stores the CAA-level UAV ID, UAS ID, authorization token, and UAS security context (K). UAS ID) and the most recently exported K UAS This is part of the UAS security context. In one embodiment, UAV 106 uses K... UAS ID is used to uniquely identify K UAS .

[0111] In one embodiment, to support UAS root key derivation and C2 auxiliary information generation during the UAS-specific PDU session establishment process, the USS / UTM 157 may perform step 3f when a UAV operation request (instead of an authentication request) is received from the UFES 155 in step 3d. Then, in one embodiment, step 3f may be performed, and the USS / UTM 157 sends the information sent in step 3g in a UAV operation response message (instead of in a UAS authentication response) to the UFES 155. In one embodiment, the UAS operation response includes a success indication, a CAA-level UAV ID, a UAS ID, C2 auxiliary information, an authorization token, and a UAS security context (K). UAS ID, K UAS ).

[0112] At step 4a, in one embodiment (see message 228), UAV 106 initiates a C2 security setup procedure with USS / UTM 157 to establish a secure C2 session between UAV 106 and USS / UTM 157. The UAS / C2 security setup procedure is sent via a NAS connection protected by NAS security and / or via an RRC connection.

[0113] In one embodiment, UAV 106 sends a C2 security establishment request message to AMF 143 within the NAS container. In one embodiment, the C2 security establishment request message includes a UAV ID with routing information (e.g., a CAA-level UAV ID), UASID, authorization token, Nonce_1, security capabilities, and K. UAS ID.

[0114] At step 4b, in one embodiment (see message 230), AMF 143 decrypts the NAS container and forwards the received C2 secure establishment request message to UFES 155. At step 4c, in one embodiment (see message 232), UFES 155 forwards the C2 secure establishment request message to USS / UTM 157.

[0115] In step 4d, in one embodiment (see box 234 and messaging 236), the USS / UTM 157 verifies K using locally stored UAS security context information associated with the UAS ID. UAS ID, UAS ID, and authorization token. In one embodiment, if with K... UAS If the UAS security context associated with the ID is available, then USS / UTM 157 generates Nonce_2 and retrieves it from the locally stored UAS root key (K). UAS Export C2 session key (K) UAS_Sess ), as shown below:

[0116] ·K UAS_Sess =KDF(K UAS UAS ID, CAA-level UAV ID, Nonce1, Nonce2)

[0117] ·K UAS_Sess ID:Hash(K UAS_Sess )

[0118] ·CCEK=KDF(K UAS_Sess (UAS ID, Encryption Algorithm ID, C2 Type ID)

[0119] ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0120] In one embodiment, USS / UTM 157 further derives K UAS_Sess An ID (e.g., 16 bits long) is used to uniquely identify the UAS session key. In one embodiment, the USS / UTM 157 selects the encryption and integrity algorithms for C2 protection based on local configuration and UAV security capabilities. Furthermore, in one embodiment, the USS / UTM 157 provides the selected security algorithm (encryption and integrity), Nonce_2, and K to the UFES155 in the C2 secure establishment response message. UAS_Sess ID and UFES155 K UAS_Sess Key.

[0121] In one embodiment, at step 4e (see box 238), the UFES 155 locally stores the received K UAS_Sess ID and K UAS_Sess The key and UAS security context information. In one embodiment, the UFES 155 further sends the received C2 security establishment response message to the AMF143, wherein the C2 security establishment response message includes the selected security algorithm (encryption and integrity), Nonce_2, and K. UAS_Sess ID.

[0122] At step 4f, in one embodiment (see message passing 240), AMF 143 sends the received C2 secure establishment response message to UAV 106, wherein the C2 secure establishment response message includes the selected security algorithm (encryption and integrity), Nonce_2, and K. UAS_Sess ID.

[0123] In one embodiment, at step 4g (see message passing 242), similar to USS / UTM157, UAV 106, upon receiving Nonce_2, retrieves the locally stored UAS root key (K) UAS Generate C2 session key (K) UAS_Sess Similar to USS / UTM157, UAV 106 further generates K. UAS_Sess The ID is used to check if the C2 session security is synchronized with the USS / UTM 157. In one embodiment, if the C2 session key and ID are found to be synchronized, the UAV 106 detects that the UAS session key has been successfully set. In one embodiment, the UAV 106 locally stores the received selected security algorithm (encryption and integrity) and Nonce_2.

[0124] In step 4h, in one embodiment (see message passing 244), UAV 106 sends a C2 security establishment complete message to USS / UTM 157, which uses a new K at the C2 application layer. UAS_Sess The key is encrypted and protected for integrity (e.g., using the CCEK and CCIK derived above). In one embodiment, step 4h can be sent over the NAS connection or using user plane signaling. In one embodiment, based on the deployment scenario of operator 102, as an option, the UAS / C2 security setup process can be performed alternately between UAV 106 and UFES 155, wherein UFES 155 is used instead of USS / UTM 157 in steps 4a to 4h above.

[0125] In an alternative embodiment, the following can be used: Figure 3 The C2 security mode command procedure shown executes the UAS / C2 security settings between UAV 106 and USS / UTM 157. In one embodiment, instead of Figure 2 Steps 4a to 4h shown can be performed. Figure 3 Steps 1 through 6 are used to establish security between UAV 106 and USS / UTM 157.

[0126] In step 1, in one embodiment (see box 302), after successful UAS authentication, the UFES 155 and / or USS / UTM 157 contain the UAS root key, which is as described above. Figure 2 The export and storage described in step 4d. In one embodiment, UFES 155 and / or USS / UTM157 further generate Nonce_1 to be used as input in session key derivation.

[0127] In one embodiment, UFES 155 and / or USS / UTM 157 derive the UAS session security key (K) as follows. UAS_Sess ) and session key identifier (K UAS-Sess ID):

[0128] ·K UAS_Sess =KDF(K UAS UAS ID, CAA-level UAV ID, Nonce1)

[0129] ·K UAS_Sess ID:Hash(K UAS_Sess )

[0130] ·CCEK=KDF(K UAS_Sess (UAS ID, Encryption Algorithm ID, C2 Type ID)

[0131] ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0132] In one embodiment, UFES 155 and / or USS / UTM 157 send a C2 security mode command message to UAV 106 (e.g., via 3GPP network function AMF 143, UFES 155, etc.). In one embodiment, the C2 security mode command message includes UAS ID, Nonce_1, the identifier of the selected encryption and integrity protection algorithm, and K. UAS ID and / or K UAS_Sess ID. In one embodiment, the C2 security mode command message uses a newly derived CCIK and the selected integrity algorithm for integrity protection.

[0133] In step 2, in one embodiment (see messages 304 and 306), 3GPP NF301 receives a C2 security mode command message and forwards the received C2 security mode command message to UAV 106.

[0134] In step 3, in one embodiment (see box 308), UAV 106 uses the received K UAS ID verification local storage KUAS The UAV 106 uses the received Nonce_1 to derive the UAS session key and UAS session ID, similar to the UFES 155 and / or USS / UTM 157 specified in step 1 above, if the two match. In one embodiment, the UAV 106 further verifies the newly derived K. UAS_Sess Does the ID match the received K? UAS-Sess If the IDs match, and if they do, UAV 106 derives the CCEK and CCIK from the newly derived UAS session key, similar to the UFES 155 and / or USS / UTM 157 specified in step 1 above. In this embodiment, UAV 106 uses the newly derived CCIK to verify the integrity of the received C2 security mode command message, and if the integrity verification is successful, UAV 106 proceeds to step 4.

[0135] In step 4, in one embodiment (see messaging 310 and 312), UAV 106 sends a C2 security mode completion message directly or via 3GPP network function 301 (e.g., AMF 143, UFES 155, etc.) to UFES 155 and / or USS / UTM 157, wherein 3GPP NF 301 forwards the received C2 security mode completion message to USS / UTM 157. In one embodiment, the C2 security mode completion message includes a "success indication" and a newly derived K. UAS_Sess The ID serves as proof of ownership of the correct session key.

[0136] At step 5, in one embodiment (see box 314), UFES 155 and / or USS / UTM 157 receive a C2 security mode completion message and use K-based... UAS_Sess The CCEK and CCIK interpret / decrypt and verify the integrity of received messages. A "success indication" shows that the UAV 106 has established a secure session, and K... UAS_Sess The ID serves as proof of having the correct session key.

[0137] At step 6, in one embodiment (see message 316), UAV 106 and UFES 155 and / or USS / UTM 157 use CCEK and CCIK to protect C2 communication data (C2 application data / signaling) until the lifetime of the UAS key or UAS session key.

[0138] Regarding the UAS key hierarchy, as shown in Figures 4a and 4b, two options are depicted, both of which can be implemented and used for UAS security. The UAS key hierarchy shown here includes... Figure 2 and Figure 3The UAS key (K) described in the process shown is UAS ), UAS session key (K UAS_Sess ) and UAS / C2 protection keys (e.g., CCEK for confidentiality protection / encryption and CCIK for integrity protection).

[0139] The different key layers are as follows:

[0140] • Long-term credentials 402: These are credentials provided at UAV 106 and form the root of C2 application layer data security. Credentials can include symmetric keys or public / private key pairs, depending on the UAS deployment scenario.

[0141] Alternatively, UAV 106 and its corresponding UAV-C 108 in UAS 101 are equipped with the same UAS long-term credentials, which allows UAV 106 and UAV-C 108 to export the same UAV root key after UAS authentication.

[0142] ·K UAS 404: This is the root key (e.g., a 256-bit key) shared between UAV 106 and UTM / USS 157, and can also be shared with UAV-C 108, TPAE, and UAS control functions / UFES 155 in 3GPP networks, enabling communication via C2 through UAV3, UAV 4, and UAV 9 interfaces. It can be refreshed by rerunning the authentication signaling using long-term credentials. To generate K... UAS-Sess (Next-level key) exchanges random numbers between UAV 106 and UTM / USS 155. This ensures that K remains active even when there is no active C2 communication session on UAV 106. UAS K UAS ID can be used to identify K UAS .

[0143] ·K UAS-sess 406: This is a session key (e.g., a 256-bit key) that is the root of the actual security context being used (or at least during the establishment process) to protect C2 data transfers between UAV 106 and UTM / USS 155, between UAV 106 and UAV-C108, and between UAV 106 and TPAE. The actual key used in the confidentiality and integrity algorithms can be obtained directly from K. UAS-sess Exported from [source]. 16-bit K UAS-Sess ID can be used to identify K UAS-sess .

[0144] • CCEK 408 and CCIK 410: C2 encryption key (CCPEK) and C2 integrity key (CCPIK) (e.g., 256-bit keys) are used together with the selected confidentiality and integrity algorithms to protect C2 application data. They are derived from K UAS-sess Key export, and each time K is changed... UAS-Sess It refreshes automatically.

[0145] It should be noted that in one embodiment, the UAS root key can be derived from UAV 106 and UAV-C 108. For UAV-C108, in one embodiment, alternatively, the UAS root key can be provided by USS / UTM 157. On the network side, in one embodiment, the UAS root key can be derived during successful UAS authentication via USS / UTM 157 or UFES 155. The UAS session key can be derived from UAV 106, UAV-C 108, USS / UTM 157, UFES 155, and TPAE (as shown in Figures 4a and 4b). For TPAE, alternatively, in one embodiment, the UAS session key can be provided by UFES 155. CCIK and CCEK can be derived from UAV106, UAV-C108, USS / UTM 157, UFES 155, TPAE, etc., for C2 protection. Alternatively, for TPAE, UFES 155 can provide corresponding CCEK and CCIK.

[0146] In one embodiment, when from K UAS Calculate K UAS-sess When using this method, the following parameters should be used to form the input S of the key derivation function (“KDF”):

[0147] ·FC=XXXX

[0148] ·P0=Nonce_1

[0149] • L0 = the length of Nonce_1 (i.e., 0x00 0x10)

[0150] P1 = Nonce_2

[0151] • L1 = the length of Nonce_2 (i.e., 0x00 0x10)

[0152] P2 = UAS ID

[0153] L2 = Length of UAS ID

[0154] P3 = UAV ID (Instance CAA-level UAV ID)

[0155] L3 = Length of UAV ID

[0156] In one embodiment, the input key is a 256-bit K. UAS In one embodiment, for C2-specific K used in UAV3, UAV4, and UAV9 UAS-sess In addition to the above inputs, the following inputs are also used for derivation.

[0157] P4 = C2 type code (i.e., indicating whether it is UAS C2, USS C2, or TPAE C2)

[0158] • L4 = Length of the C2 type code (i.e., indicating whether it is UAS C2, USS C2, or TPAE C2)

[0159] In one embodiment, when from K UAS-sess When calculating CCIK or CCEK, the following parameters should be used to form the input S of the KDF:

[0160] ·FC=XXXX

[0161] • If CCEK is exported, then P0 = 0x00, or if CCIK is exported, then P0 = 0x01.

[0162] • The length of L0 = P0 (i.e., 0x00 0x01)

[0163] P1 = Algorithm identifier

[0164] L1 = Length of the algorithm identifier (i.e., 0x00 0x01)

[0165] P2 = C2 type code (i.e., indicating whether it is UAS C2, USS C2, or TPAE C2)

[0166] • L2 = Length of the C2 type code (i.e., indicating whether it is UAS C2, USS C2, or TPAE C2)

[0167] In one embodiment, as described in TS 33.501, an algorithm identifier is set. In one embodiment, the input key is a 256-bit K... UAS-sess In one embodiment, for an algorithm key of length n bits, where n is less than or equal to 256, the n least significant bits out of the 256 bits output by the KDF are used as the algorithm key.

[0168] In one embodiment, the C2 type code can be used to ensure cryptographic separation between C2 application data security for UAV-UAV-C pairs, UAV-USS / UTM pairs, and UAV-TPAE pairs. In one embodiment, the C2 type code can be used as input in UAS session key derivation or as input along with application data during confidentiality and integrity protection. Examples of C2 type identification elements are shown in the table below:

[0169] C2 Type Identification Elements value UAS / UAV-C C2 0x01 USS / UTM C2 0x02 TPAE C2 0x03

[0170] Table 1. C2 Type Differentiation Elements

[0171] In one embodiment, Figure 2 The UAS authentication and key establishment process described in the document and Figure 3 The C2 security mode command procedure described herein applies to EPS / 4G, and as specified in the steps above, has the following changes:

[0172] • Instead of AMF 143, the Mobility Management Entity (“MME”) participates in EPS / 4G, and instead of UDM 149, the Home Subscriber Service (“HSS”) / Certification Authority (“AuC”) participates in... Figure 2 And a description of the relevant steps. Furthermore, in Figure 2 In one embodiment, EPS / 4G authentication (instead of primary authentication) is performed prior to UAS authentication.

[0173] ·exist Figure 3 In the description of related steps, in one embodiment, the MME and UFES 155 are involved as 3GPP network functions.

[0174] The key derivation and hierarchy depicted in Figures 4a and 4b also apply to EPS / 4G.

[0175] One embodiment of the proposed solution involves establishing C2 security between UAV 106 and parties such as UAV-C108, TPAE, and UTM / USS157 (e.g., regulatory agencies, network operators participating in the UAS). In one embodiment, security can be established for UAV 106 with various trusted parties (such as USS / UTM 1557, UAV-C 108, TPAE) to enable secure command and control communications for safe and reliable UAV flight operations.

[0176] In one embodiment, there are three scenarios where security needs to be established between UAV 104 and the trusted party, as listed below:

[0177] • Security settings between UAV 106 and USS / UTM 157 (e.g., C2 protection via UAV9 interface)

[0178] • Security settings between UAV 106 and UAV-C 108 (e.g., C2 protection via UAV3 interface)

[0179] • Security settings between UAV 106 and TPAE (e.g., C2 protection via UAV4 interface)

[0180] Compared to Embodiment 1 described above, which describes how to establish security between UAV 106 and UTM / USS 157, the embodiments described below describe the establishment of security between UAV 106 and UAV-C 108 and TPAE.

[0181] In one embodiment, a new network function—the UAS Control Function (“UCF”), also known as the UAS Management Function (“UASMF”)—is introduced, which performs UAS-based control and management operations on behalf of the UTM / USS157 in a 3GPP network. The UCF / UASMF can be associated with and equivalent to UFES 155 and UAS AF, for example, as defined in TR 23.754. For ease of reading, this disclosure will use the general term UFES 155. Therefore, all new features and operations described in this disclosure for UFES 155 apply to the new 3GPP network function UCF.

[0182] Figure 5 This is a diagram illustrating the signal flow diagram of process 500 for the first option of command and control safety settings involving UAV 106 and UAV-C 108.

[0183] As shown in step 1, in one embodiment (see message passing 502), UAV 106 directly (e.g., via direct communication using bidirectional query / response communication) or indirectly through other 3GPP NF 501 (e.g., UFES, UASMF, UASNF, NEF) sends a C2 security association request message to UFES 155 (or any 3GPP NF managing / controlling UAS communication). In one embodiment, the C2 security association request message includes UAV ID (e.g., CAA UAV ID), UAV-C ID, UAS ID (e.g., received during successful UAS authentication), UAS authorization token (e.g., received during successful UAS authentication), K UAS ID / K UAS_SessID, UAV security capabilities (e.g., security algorithm identifier), and Nonce_1. Alternatively, in one embodiment, UAV 106 and / or UAV-C 108 may send step 1 to UFES 155 or USS / UTM 157. Therefore, in this embodiment, the following steps in this process involve USS / UTM 157 instead of UFES 155.

[0184] In step 2, in one embodiment (see box 504), when the UFES / 3GPP NF 501 receives the C2 security association request message, it uses the received K... UAS ID / K UAS_Sess Use the ID to extract the local storage UAS / C2 security context.

[0185] In one embodiment, UFES 155 verifies the received UAV ID, UAS ID, and authorization token using locally stored information (e.g., CAA-level UAV ID, UAS ID, and authorization token). If a match is found, UFES 155 checks if “C2 association information” for the UAV ID is stored locally to determine if the corresponding, associated, or paired UAV-C 108 is available for UAS communication; learns the location of UAV-C 108 (e.g., UAV-C-based service network information); and checks if UAV-C 108 has been authenticated (e.g., optionally by contacting UDM / HSS directly or via AMF / MME). Based on the authentication result, if UAV-C 108 has registered to the network and the UAS has been authenticated, UFES 155 forwards the C2 security association request to UAV-C 108 (e.g., directly (if UAV-C 108 is located in the same PLMN) or indirectly (if UAV-C 108 is located in another PLMN)).

[0186] In step 3, in one embodiment (see box 506), if UAV-C 108 is registered with the PLMN and it has not yet been authenticated by the UAS, or if UAV-C 108 has not yet registered, the network performs a network-initiated PDU session establishment to initiate registration and UAV authentication.

[0187] In step 4, in one embodiment (see message passing 508), UFES 155 forwards the C2 security association request message and provides the UAV-C 108 with the UAS root key and / or UAS session key. The C2 security association request message may include the UAV ID (e.g., CAA UAV ID), UAV-C ID, UAS ID, UAV authorization token, UAV security capabilities, and K... UAS ID / K UAS_SessID and Nonce_1.

[0188] In one embodiment, if UAV-C 108 can export the same UAS root key as UAV 106 after successful UAS authentication via USS / UTM 157, then sending the K key to UAV-C 108 can be skipped. UAS / K UAS_Sess Otherwise, during pairing / association of UAV106 and UAV-C 108, UFES 155 may need to use K... UAS / K UAS_Sess Provided to UAV-C 108 to achieve the same UAS root key availability at UAV-C 108.

[0189] In an alternative embodiment, step 4 can be sent from UAV-C 108 to UFES 155 or USS / UTM 157 to pair or associate UAV-C 108 with UAV 106. In this case, step 5 can be performed and then UAV-C 108 sends step 4 to UFES 155 or USS / UTM 157.

[0190] In one embodiment, at step 5 (see box 510), the UAV-C 108 verifies the received UAV ID, UAS ID, and authorization token using locally stored information (e.g., CAA-level UAV ID, UAS ID, and authorization token), and if a match is found, the UAV-C 108 generates a Nonce_2 to retrieve the data from K. UAS Export K UAS-Sess The key (e.g., a key exported after UAS authentication that is available in local storage or received from UFES 155), similar to UAV 106, is as follows:

[0191] ·K UAS_Sess =KDF(K UAS UAS ID, CAA-level UAV ID, Nonce_1, Nonce_2)

[0192] ·K UAS_Sess ID:Hash(K UAS_Sess )

[0193] ·CCEK=KDF(K UAS_Sess (UAS ID, Encryption Algorithm ID, C2 Type ID)

[0194] ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0195] Alternatively, in one embodiment, if UAV-C 108 receives K from UFES 155 UAS-Sess Key instead of K UAS The key, then UAV-C 108 via K UAS-Sess Key export CCEK and CCIK keys to use the received K UAS-Sess The key is C2 encrypted and protected for integrity.

[0196] In other embodiments, if UAV-C 108 receives UAV security capabilities, UAV-C 108 selects an encryption algorithm and an integrity algorithm based on its own capabilities and the UAV security capabilities.

[0197] In one embodiment, at step 6 (see message passing 512), UAV-C 108 sends a C2 security association response message to UFES 155, which includes a success indication, UAS ID, and K. UAS-Sess The C2 security association response message includes the ID, the selected encryption and integrity algorithm ID, the Nonce_2, and the address (e.g., MAC). The C2 security association response message can be integrity protected using the selected security algorithm and the newly derived CCIK. In an alternative embodiment, if a C2 association request is received from UAV-C108 in step 4, a C2 security association response message can be sent to UAV-C108 by UFES 155 or USS / UTM 157.

[0198] In one embodiment, at step 7 (see message passing 514), UFES 155 forwards the C2 security association response message to UAV 106. At step 8a, in one embodiment, UAV 106 uses the received Nonce_2 to retrieve the K from its locally stored memory. UAS Key export K UAS-Sess Key. Furthermore, in one embodiment, the UAV 106 derives K. UAS-Sess ID and use the received K UAS-Sess ID verification of newly exported K UAS-Sess If the two match, the UAV 106 considers the security setup successful and retrieves the newly exported K. UAS-Sess The CCEK and CCIK are derived using the key. Furthermore, in one embodiment, UAV 106 uses the CCIK to verify the integrity of the received C2 security association response message by checking the received MAC. Successful MAC verification also confirms the successful establishment of C2 security between UAV 106 and UAV-C 108. The key derivation is as follows:

[0199] ·K UAS_Sess =KDF(K UASUAS ID, CAA-level UAV ID, Nonce_1, Nonce_2)

[0200] ·K UAS_Sess ID:Hash(K UAS_Sess )

[0201] ·CCEK=KDF(K UAS_Sess (UAS ID, Encryption Algorithm ID, C2 Type ID)

[0202] ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0203] At step 8b, in one embodiment (see Message Passing 518), UAV 106 and UAV-C 108 exchange C2 application data protected by CCEK and CCIK.

[0204] Figure 6 This is a diagram illustrating the signal flow diagram of process 600 for the second option of command and control safety settings involving UAV 106 and UAV-C 108.

[0205] In steps 1a to 1b, in one embodiment (see messages 602 and 604), UAV-C 108 registers with the PLMN and has successfully performed UAS authentication using the USS / UTM 157. In steps 2a to 2b, in one embodiment (see messages 606 and 608), UAV-C 106 registers with the PLMN and has successfully performed UAS authentication using the USS / UTM 157. In one embodiment, UAV 106 holds the UAS root key (K). UAS ), UAS ID, K UAS ID and authorization token are part of the UAS security context.

[0206] At step 2c, in one embodiment (see message passing 610), UAV 106 and UFES 155 (e.g., UFES, UASMF, UASNF, NEF) or USS / UTM 157 have successfully performed security form setup, and K is used. UAS-Sess The key establishes C2 security between UAV 106 and UFES 155 or USS / UTM 157 (see reference). Figure 3 (Description and illustration).

[0207] At step 3a, in one embodiment (see message 612), a 3GPP network function (AMF 143 / UFES 155 in the case of a 5G network, or MME / UFES in the case of a 4G network) determines to associate the C2 connection and C2 security settings between UAV 106 and UAV-C 108. In this embodiment, 3GPP NF 601 sends a C2 / UAS association request message to UAV-C 108 on behalf of UAV 106. The UAS association request message may include the UAV ID, UAV security capabilities, authorization token, UASID, and K. UAS ID.

[0208] In step 3b, in one embodiment (see Message Passing 614), UAV-C 108 sends a C2 Security Context Setting Request message to USS / UTM 155. The C2 Security Context Setting Request message may include the received UAV ID, authorization token, UAS ID, and K. UAS ID.

[0209] In step 3c, in one embodiment (see box 616), the USS / UTM 155 verifies the received UAS ID, authorization token, UAS ID, and K using locally stored UAS security information. UAS The UAS security information is identified using the UAS ID, and if the two match, the USS / UTM 155 provides the UAS root key / UAS session key to the UAV-C 108.

[0210] In step 3d, in one embodiment (see Message Passing 618), the USS / UTM 155 sends the UAS ID, K... to the UAV-C 108 in a C2 security context setting response message. UAS ID, random number, K UAS Key / K UAS _ Sess Key. In step 3e, in one embodiment (see box 620), the UAV-C 108 will receive the key. UAS ID, random number, K UAS Key / K UAS _ Sess The key and UAS context information received from the UFES 155 (e.g., UAV ID, UAV security capabilities, authorization token, UAS ID, K) UAS The UAV-C 108 and the C2 security key (CCEK, CCIK) are stored locally in its memory. In one embodiment, if the UAV-C 108 receives the UAS root key, the UAV-C 108 derives the UAS session key and the C2 security key (CCEK, CCIK) as follows:

[0211] ·K UAS_Sess =KDF(K UAS UAS ID, CAA-level UAV ID, Nonce

[0212] ·K UAS_Sess ID:Hash(K UAS_Sess )

[0213] ·CCEK=KDF(K UAS_Sess (UAS ID, Encryption Algorithm ID, C2 Type ID)

[0214] ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0215] In one embodiment, the UAV-C 108 selects the encryption algorithm and integrity protection algorithm based on its own security capabilities and the security capabilities of the UAV. In one embodiment, if the UAV-C 108 only receives the UAS session key, the UAV-C 108 derives the CCEK and CCIK from the received UAS session key as shown above.

[0216] At step 3f, in one embodiment (see message 622), UAV-C 108 sends a C2 / UAS association response message along with a success indication to UFES 155. In one embodiment, at step 3g (see message 624), UAV-C 108 also sends a C2 association notification to UAV 106, wherein the C2 association notification message includes K... UAS ID, UAV-C ID, selected security algorithm ID, K UAS_Sess ID and MAC. C2 associated notifications can be protected for integrity using the newly exported session key.

[0217] In step 3h, in one embodiment, UAV 106 and UAV-C 108 successfully establish C2 security through the UAV3 interface and protect all C2 application data using the newly exported CCEK and CCIK.

[0218] Figure 7 This is a diagram illustrating the signal flow diagram of process 700 involving command and control safety settings between UAV 106 and TPAE 701.

[0219] In one embodiment, as an option, the TPAE 701 can use steps 3b to 3e to initiate a secure connection via the UAV4 interface. Figure 6 The process shown establishes a C2 security setting with UAV 106, where TPAE replaces UAV-C operation.

[0220] This embodiment describes how TPAE 701 establishes C2 security settings with UAV 106 to protect C2 application exchanges in UAV control. The security setup process between UAV 106 and TPAE 701 is as follows: Figure 7 As shown.

[0221] At steps 1 to 3 (see messages 702 to 706), in one embodiment, UAV 106 successfully registers with the 3GPP network and successfully undergoes UAV authentication via USS / UTM 157. In this embodiment, UAV 106 begins updating its remote identification and tracking information to USS / UTM 155, which is stored in UDM 149 / HSS via UFES 155 (e.g., UFES / UASNF / NEF).

[0222] At step 4, in one embodiment (see message passing 708), if TPAE 701 determines that it is exchanging commands and control with any UAV 106, it determines to extract the C2 security context (e.g., UAV security capabilities / selected security algorithm ID (encryption and integrity protection algorithm), UAS ID, K) from UFES 155 and / or USS / UTM 157. UAS _Sess / CCCEK and CCIK).

[0223] In this embodiment, TPAE 701 sends a UAV query to UFES 155 (e.g., directly or via USS / UTM 157) and / or USS / UTM 157. The UAV query may include UAV ID, UAS ID, and C2 security information request indication.

[0224] At step 5, in one embodiment (see box 710), the UFES 155 and / or UTM / USS 157 retrieve C2 security information from their local storage based on the UAV ID. Depending on the operator's implementation, in one embodiment, the UFES 155 and / or USS / UTM 157 may determine whether to use a public UAS session key or derive a TPAE C2-specific UAS session key (as shown in Figure 4a regarding the UAS key hierarchy). In one embodiment, the UAV C2 security information includes UAV security capabilities such as encryption and integrity algorithms, session keys protecting C2 data messages, etc.

[0225] At step 6, in one embodiment (see message passing 712), UFES 155 (e.g., directly or via USS / UTM 157) and / or USS / UTM 157 sends a UAV response to TPAE 701, wherein the UAV response message includes the UAV ID and C2 security information. In one embodiment, the C2 security information includes the UAV security capability / selected security algorithm ID (e.g., encryption and integrity protection algorithm), UAS ID, K... UAS _Sess / CCCEK and CCIK.

[0226] In step 7, in one embodiment (see box 714), if TPAE 701 receives the selected security algorithm and C2 security keys (CCEK and CCIK), then TPAE 701 locally stores the received C2 security information and UAV ID. Alternatively, in one embodiment, if TPAE 701 receives K... UAS_Sess The key is then used to derive CCEK and CCIK from TPAE 701 as follows:

[0227] ·CCEK=KDF(K UAS_Sess UAS ID / UAV ID, Encryption Algorithm ID, C2 Type ID = 'TPAE C2 value')

[0228] ·CCIK=KDF(K UAS_Sess UAS ID / UAV ID, Integrity Algorithm ID, C2 Type ID = 'TPAE C2 value').

[0229] In one embodiment, if TPAE 701 receives UAV security capabilities, TPAE 701 selects encryption and integrity algorithms for C2 protection based on its own security capabilities and the received UAV security capabilities.

[0230] At step 8a, in one embodiment (see message 716), TPAE 701 notifies UAV 106 of an integrity-protected C2 security setup notification message having the selected algorithm, TPAE C2 start indication, and MAC. At step 8b, in one embodiment (see message 718), TPAE 701 uses the received C2 security key and the selected security algorithm to protect C2 application data sent to UAV 106.

[0231] Another embodiment of the solution disclosed herein relates to UAV106 and UAV-C 108 authentication and key management based on a service enablement architecture layer (“SEAL”) for secure UAS C2 operations. Figure 8a illustrates SEAL-based vertical application layer (“VAL”) user authentication for UAV 106 and UAV-C 108 in UAS 101.

[0232] At step 1, in one embodiment (see message passing 802), VAL UE 801 (e.g., UAV 106 / UAV-C 108) establishes a secure tunnel with SIM-S 803 (e.g., USS / UTM 157). In one embodiment, the (“SIM-C”) SEAL identity management client 801 and the (“SIM-S”) SEAL identity management server 803 can participate in the SEAL-based UAS authentication process.

[0233] In one embodiment, at step 2 (see message passing 804), VAL UE 801 (e.g., UAV 106 / UAV-C 108) sends an OpenID connection authentication request to SIM-S 803 (e.g., USS / UTM 157). The request may include an indication of the authentication method supported by the UE (e.g., UAV 106 / UAV-C 108).

[0234] In one embodiment, at step 3 (see message passing 806), user authentication is performed between VAL UE 801 (e.g., UAV 106 / UAV-C 108) and SIM-S 803 (e.g., USS / UTM 157). In this embodiment, the primary credentials used for user authentication (e.g., biometrics, secureID, OTP, username / password, etc.) are based on the VAL service provider policy. The method chosen by the VAL service provider for authentication and authorization may depend on the vertical services supported by the method and the authentication and authorization methods themselves.

[0235] In one embodiment, at step 4 (see message 808), SIM-S 803 (e.g., USS / UTM 157) sends an OpenID connection authentication response containing an authorization code to the UE (e.g., UAV 106 / UAV-C 108). The authorization code can be derived using the UAS ID and UAV CAA-level ID assigned by the USS / UTM 157. At step 5, in one embodiment (see message 810), VAL UE 801 sends an OpenID connection token request to SIM-S 803, thereby transmitting the authorization code.

[0236] In one embodiment, at step 6 (see message passing 814), SIM-S 803 (e.g., USS / UTM 157) sends an OpenID connection token response to VAL UE 801 (e.g., UAV 106 / UAV-C 108), the OpenID connection token response containing an ID token and an access token (each uniquely identifying the user of the VAL service). The access token can be derived using the UAS ID and CAA-level UAV ID / UAV-C ID as inputs (see box 812).

[0237] In one embodiment, UAV 106 / UAV-C 108 uses ID tokens to personalize the VAL client of the VAL user, and UAV 106 / UAV-C 108 uses access tokens to transmit and authorize the VAL user's identity to the VAL server and VAL service.

[0238] Figure 8b illustrates a SEAL-based key management process for establishing UAS security keys / UAS session security. In one embodiment, the (“SKM-C”) SEAL key management client 821 and the (“SKM-S”) SEAL key management server 823 involve a SEAL-based key management process.

[0239] At step 1, in one embodiment (see box 822), SKM-C 821 (e.g., UAV 106 / UAV-C 108) establishes a direct HTTPS connection with SKM-S 823 (e.g., USS / UTM 157). In some embodiments, steps 2 and 3 are performed within this secure connection.

[0240] In step 2, in one embodiment (see message passing 824), SKM-C 821 sends a SEAL KM request message to SKM-S 823, including UAV ID, UAV-C ID and UAS access token.

[0241] In step 3, in one embodiment (see message passing 826), SKM-S 823 authorizes the request and, if valid, sends a SEAL KM response message containing the requested key material (or error code), the key material including a UAS ID-specific key. UAS / K UAS_Sess Key, K UAS ID / K UAS_Sess ID and UAS ID.

[0242] As a result of the success of this process, in one embodiment, the VAL UE or VAL server has securely obtained service-specific key material for use within the VAL system (UAS application).

[0243] In one embodiment, another embodiment of the solution disclosed herein relates to UAS authentication and key management based on application-based authentication and key management (“AKMA”).

[0244] This embodiment describes how the UAS root key can be derived from the AKMA key at a 3GPP network and provided to the UFES 155 to achieve C2 communication security. The remaining uses of the UAS root key (e.g., the derivation and use of the UAS session key and the C2 security key) can be the same as described in embodiments 1, 2 and 3.

[0245] In one embodiment, Figure 9 This demonstrates how, following a successful UAS authentication and authorization process, K can be obtained from the AUSF available in a 3GPP network. AKMA Key Derivation UAS Root Key (K) UAS ).

[0246] When from K AKMA Export K UAS When doing so, the following parameters should be used to form the input S of the KDF:

[0247] ·FC = XXX;

[0248] P0 = AF_ID / UFES ID;

[0249] L0 = AF_ID / length of UFES ID;

[0250] P1 = UAS ID;

[0251] L1 = Length of UAS ID

[0252] In one embodiment, the input key should be K. AKMA .

[0253] In one embodiment, Figure 10 This illustrates a process 1000 where the UFES / UASMF 155 requests a C2 application function-specific AKMA key directly from the 5GC when the UFES / UASMF 155 is located in an operator network. In one embodiment, before communication between the UE 801 (e.g., UAV 106 / UAV-C108) and the UFES 155 (representing USS / UTM 157 and TPAE 701) can begin, the UE 801 and UFES 155 need to know whether AKMA is used. This knowledge may be implicit in the C2 applications on the UE 801 and UFES 155 (e.g., representing USS / UTM 157 and TPAE 701).

[0254] As a prerequisite (see Message Passing 1002 and 1004), in one embodiment, UE 801 performs primary authentication and establishes an AKMA anchor key K_AKMA with AAnF 803. In other embodiments, UE 801 performs UAS authentication and authorization using USS / UTM 157.

[0255] In one embodiment, at step 1 (see messages 1006 and 1008), when UE 801 (e.g., UAV106 / UAV-C 108) initiates communication with UFES 155, it should include the derived A-KID (AKMA key identifier - obtained by AUSF and UE from K) in the application session establishment request message. AUSF Export).

[0256] At step 2, in one embodiment (see message 1010), if the UFES 155 does not have an activity context associated with the A-KID, the AF sends a Naanf_AKMA_UASKey request along with the A-KID to the AKMA anchor function (“AAnF”) 803 to request the AKMA application key for the UE 801. The UFES 155 also includes its identifier (UFESID) in the request and the UAS ID to be bound in the UAS root key derivation. In one embodiment, the AAnF 803 authorizes the UFES 155. In some embodiments, the AAnF 803 checks whether it can provide services to the UFES 155 based on a configured local policy or based on authorization information or policies provided by the NEF / NRF using the UFES 155. In one embodiment, if successful, the following procedure is performed. Otherwise, the AAnF 803 rejects the procedure.

[0257] In one embodiment, AAnF 803 checks whether the subscriber is authorized to use AKMA by having an AKMA anchor key K_AKMA that has already been received from AUSF. In some embodiments, if AAnF 803 possesses the UAS application key (K_AKMA), UAS If ), then it uses K. UAS Respond to UFES 155. If not, AAnF 803 can check if it has a UE-specific K identified by A-KID. AKMA Key. In other embodiments, if K AKMA If it is available in AAnF 803, then AAnF 803 continues to step 3. In various embodiments, if K AKMA If unavailable, AAnF 803 continues to step 4 and sends an error response.

[0258] In one embodiment, at step 3 (see box 1012), AAnF 803 from KAKMA Export UAS application key (K) UAS In one embodiment, key deduction is performed using the key deduction function (“KDF”) specified in TS 33.220. UAS Calculated as K UAS =KDF(K AKMA The UFES ID and UAS ID are used to derive K. The UFES ID is constructed as follows: UFES ID = UFES || FQDN of the Ua* / C2 security protocol identifier. The Ua* / C2 security protocol identifier can be specified as the Ua security protocol identifier in Appendix H of TS 33.220. UAS The key is K AKMA .

[0259] In step 4, in one embodiment (see message passing 1014), AAnF 803 will have K UAS The Naanf_AKMA_UASKey response with validity period is sent to UFES 155. At step 5, in one embodiment (see box 1016), UFES 155 derives the CCEK and CCIK directly from the UAS root key or from the UAS session key (e.g., where the UAS session key is derived from the UAS root key). The UAS session key derivation and the C2 security key (CCEK and CCIK) derivation can be based on the embodiments previously described above.

[0260] In step 6, in one embodiment (see message 1018), the UFES 155 responds to the application session establishment request of the UE 801 using a UAS session key ID corresponding to the UAS session key derived from the UAS root key. C2 security can be set using an AKMA-based UAS key.

[0261] Figure 11 User equipment device 1100, which can be used for UAS authentication and security establishment according to embodiments of the present disclosure, is depicted. In various embodiments, user equipment device 1100 is used to implement one or more of the solutions described above. User equipment device 1100 may be an embodiment of the remote unit 105, UE 205, UAV 106, and / or UAV-C 108 described above. Furthermore, user equipment device 1100 may include processor 1105, memory 1110, input device 1115, output device 1120, and transceiver 1125.

[0262] In some embodiments, input device 1115 and output device 1120 are combined into a single device, such as a touchscreen. In some embodiments, user equipment device 1100 may not include any input device 1115 and / or output device 1120. In various embodiments, user equipment device 1100 may include one or more of processor 1105, memory 1110, and transceiver 1125, and may not include input device 1115 and / or output device 1120.

[0263] As depicted, transceiver 1125 includes at least one transmitter 1130 and at least one receiver 1135. In some embodiments, transceiver 1125 communicates with one or more cells (or radio coverage areas) supported by one or more base station units 121. In various embodiments, transceiver 1125 may operate on unlicensed spectrum. Furthermore, transceiver 1125 may include multiple UE panels supporting one or more beams. Additionally, transceiver 1125 may support at least one network interface 1140 and / or application interface 1145. Application interface 1145 may support one or more APIs. Network interface 1140 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 1140 may be supported, as will be understood by those skilled in the art.

[0264] In one embodiment, processor 1105 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 1105 may be a microcontroller, microprocessor, central control unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 1105 executes instructions stored in memory 1110 to perform the methods and routines described herein. Processor 1105 is communicatively coupled to memory 1110, input device 1115, output device 1120, and transceiver 1125. In some embodiments, processor 1105 may include an application processor (also referred to as a “main processor”) that manages application domain and operating system (“OS”) functions, and a baseband processor (also referred to as a “baseband radio processor”) that manages radio functions.

[0265] In various embodiments, processor 1105 and transceiver 1125 control user equipment device 1100 to implement the UE behavior described above. For example, the UE may include UAV 106 and / or UAV-C 108, which includes transceiver 1125 that sends command and control ("C2") pairing requests from a first user equipment ("UE") device to a network function of a mobile wireless communication network to establish secure communication between the first UE device and a second UE device. The C2 pairing request includes at least one of an identifier for the first UE device, an identifier for the second UE device, an identifier for an unmanned aerial vehicle system ("UAS") including the first and second UE devices, security capability information for the first UE device, a UAS authorization token, a random number, a UAS security information identifier, a UAS root key, and a UAS session key identifier.

[0266] In one embodiment, transceiver 1125 receives a C2 pairing response from a network function, the C2 pairing response including at least one of a success indicator, a UAS session key identifier, a UAS session key, UAS security information, a selected security algorithm, and an address for a second UE device.

[0267] In one embodiment, processor 1105 uses a locally stored UAS root key to derive a second UAS session key and uses the second UAS session key to derive a second UAS session key identifier; verifies that the second UAS session key identifier matches the UAS session key identifier received in the C2 pairing response; derives at least one security key for protecting communication between the first and second UE devices based on the UAS session key; and establishes secure communication with the second UE device using the at least one security key.

[0268] In one embodiment, transceiver 1125 further receives an authentication response message from a second network function of the mobile wireless communication network, the authentication response message including at least one or more of a success indication, a UAV identifier, a UAS identifier, a UAV-C identifier, an authorization token, and a UAS security context.

[0269] In one embodiment, in response to receiving an authentication response message with a success indication, processor 1105 locally stores the UAV identifier, UAS identifier, UAV-C identifier, authorization token, and received UAS security context, and generates a UAS security context using the UAV's long-term credentials, the UAS identifier, and the UAV identifier. In one embodiment, processor 1105 uses the UAS security context to establish a secure connection with the USS / UTM.

[0270] In one embodiment, memory 1110 is a computer-readable storage medium. In some embodiments, memory 1110 includes volatile computer storage media. For example, memory 1110 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 1110 includes non-volatile computer storage media. For example, memory 1110 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 1110 includes both volatile and non-volatile computer storage media.

[0271] In some embodiments, memory 1110 stores data related to UAS authentication and security establishment. For example, as described above, memory 1110 may store various parameters, panel / beam configurations, resource allocations, policies, etc. In some embodiments, memory 1110 also stores program code and related data, such as operating systems or other controller algorithms operating on user equipment device 1100.

[0272] In one embodiment, input device 1115 may include any known computer input device, including a touch panel, button, keyboard, stylus, microphone, etc. In some embodiments, input device 1115 may be integrated with output device 1120, such as as a touchscreen or similar touch-sensitive display. In some embodiments, input device 1115 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 1115 includes two or more different devices, such as a keyboard and a touch panel.

[0273] In one embodiment, the output device 1120 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1120 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 1120 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc., to a user. As another non-limiting example, the output device 1120 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., that is separate from but communicatively coupled to the rest of the user device device 1100. Furthermore, the output device 1120 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0274] In some embodiments, output device 1120 includes one or more speakers for generating sound. For example, output device 1120 may generate an audible alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 1120 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 1120 may be integrated with input device 1115. For example, input device 1115 and output device 1120 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 1120 may be located near input device 1115.

[0275] Transceiver 1125 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 1125 operates under the control of processor 1105 to transmit and receive messages, data, and other signals. For example, processor 1105 may selectively activate transceiver 1125 (or a portion thereof) at specific times to send and receive messages.

[0276] Transceiver 1125 includes at least a transmitter 1130 and at least one receiver 1135. One or more transmitters 1130 can be used to provide UL communication signals to base station unit 121, such as UL transmissions described herein. Similarly, one or more receivers 1135 can be used to receive DL communication signals from base station unit 121, as described herein. Although only one transmitter 1130 and one receiver 1135 are described, user equipment device 1100 can have any suitable number of transmitters 1130 and receivers 1135. Furthermore, transmitters 1130 and receivers 1135 can be of any suitable type. In one embodiment, transceiver 1125 includes a first transmitter / receiver pair for communicating with a mobile communication network via licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via unlicensed radio spectrum.

[0277] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network via licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for both licensed and unlicensed radio spectrum. In one embodiment, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, certain transceivers 1125, transmitters 1130, and receivers 1135 may be implemented as physically separate components accessing shared hardware resources and / or software resources (such as, for example, network interface 1140).

[0278] In various embodiments, one or more transmitters 1130 and / or one or more receivers 1135 may be implemented and / or integrated into a single hardware component such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other types of hardware components. In some embodiments, one or more transmitters 1130 and / or one or more receivers 1135 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as a network interface 1140 or other hardware components / circuit may be integrated with any number of transmitters 1130 and / or receivers 1135 into a single chip. In this embodiment, transmitters 1130 and receivers 1135 may be logically configured as transceivers 1125 using one or more common control signals, or logically configured as modular transmitters 1130 and receivers 1135 implemented in the same hardware chip or in a multi-chip module.

[0279] Figure 12 A network device 1200, which can be used for UAS authentication and security establishment according to embodiments of the present disclosure, is depicted. In one embodiment, the network device 1200 may be an implementation of a RAN node, such as the base station unit 121, RAN node 210, or gNB described above. Furthermore, the basic network device 1200 may include a processor 1205, a memory 1210, an input device 1215, an output device 1220, and a transceiver 1225.

[0280] In some embodiments, input device 1215 and output device 1220 are combined into a single device, such as a touchscreen. In some embodiments, network device 1200 may not include any input device 1215 and / or output device 1220. In various embodiments, network device 1200 may include one or more of processor 1205, memory 1210, and transceiver 1225, and may not include input device 1215 and / or output device 1220.

[0281] As depicted, transceiver 1225 includes at least one transmitter 1230 and at least one receiver 1235. Here, transceiver 1225 communicates with one or more remote units 105. Additionally, transceiver 1225 may support at least one network interface 1240 and / or application interface 1245. Application interface 1245 may support one or more APIs. Network interface 1240 may support 3GPP reference points such as Uu, N1, N2, and N3. Other network interfaces 1240 may be supported, as will be understood by those skilled in the art.

[0282] In one embodiment, processor 1205 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 1205 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, processor 1205 executes instructions stored in memory 1210 to perform the methods and routines described herein. Processor 1205 is communicatively coupled to memory 1210, input device 1215, output device 1220, and transceiver 1225. In some embodiments, processor 805 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0283] In various embodiments, network device 1200 is a UFES or other 3GPP NF (e.g., UAS NF) as described above. In this embodiment, transceiver 1225 sends an authentication request message from a user equipment ("UE") to a UAS service provider ("USS") / UAS traffic management ("UTM") from a first network function of the mobile wireless communication network. The UE includes at least one of a drone ("UAV") and a UAV controller ("UAV-C"). In some embodiments, transceiver 1225 receives an authentication response message from the USS / UTM at the first network function. The authentication response message includes a UAS identifier and a UAS security context, the UAS security context including a UAS root key and a UAS root key identifier.

[0284] In one embodiment, transceiver 1225 transmits a received authentication response message from a first network function to the Access and Mobility Management Function (“AMF”) of the mobile wireless communication network. In another embodiment, transceiver 1225 receives an authentication request message from the AMF of the mobile wireless communication network, the authentication request message including an identifier of a UAV, and processor 1205 locally stores the UAV identifier at the first network function, wherein the transceiver transmits the authentication request message to the USS / UTM in response to receiving the authentication request message.

[0285] In various embodiments, network device 1200 is a UFES, UCF, or other 3GPP NF as described above. In this embodiment, transceiver 1225 receives a command and control ("C2") pairing request from a first user equipment ("UE") device at the network function of the mobile wireless communication network. The C2 pairing request includes at least one parameter for establishing secure communication between the first UE device and the second UE device.

[0286] In one embodiment, processor 1205 verifies at least one parameter at the network function based on a local storage of a UAV system (“UAS”) security context at the network function, the UAS including first and second UE devices. In one embodiment, transceiver 1225, in response to successful verification of at least one parameter, sends a C2 pairing request from the network function to the UAS service provider (“USS”) / UAS traffic management (“UTM”); receives a C2 pairing response from the USS / UTM at the network function; and sends a C2 pairing response from the network function to the first UE device to establish secure communication.

[0287] In one embodiment, the processor 1205 verifies that the received UAV identifier, UAS identifier, and UAS authorization token match the corresponding UAV identifier, UAS identifier, and UAS authorization token stored locally at the first network function, and in response to a successful match, determines the C2 pairing information stored locally at the network function to check: whether the UAV and / or UAV-C can be used for UAS communication, the location of the UAV and / or UAV-C, and whether the UAV and / or UAV-C is authenticated.

[0288] In one embodiment, memory 1210 is a computer-readable storage medium. In some embodiments, memory 1210 includes volatile computer storage media. For example, memory 1210 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 1210 includes non-volatile computer storage media. For example, memory 1210 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 1210 includes both volatile and non-volatile computer storage media.

[0289] In some embodiments, memory 1210 stores data related to UAS authentication and security establishment. For example, as described above, memory 1210 may store parameters, configurations, resource allocations, policies, etc. In some embodiments, memory 1210 also stores program code and related data, such as operating systems or other controller algorithms operating on network device 1200.

[0290] In one embodiment, input device 1215 may include any known computer input device, including a touch panel, button, keyboard, stylus, microphone, etc. In some embodiments, input device 1215 may be integrated with output device 1220, such as as a touchscreen or similar touch-sensitive display. In some embodiments, input device 1215 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 1215 includes two or more different devices, such as a keyboard and a touch panel.

[0291] In one embodiment, the output device 1220 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1220 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 1220 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc., to a user. As another non-limiting example, the output device 1220 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., which is separate from but communicatively coupled to the rest of the network device 1200. Furthermore, the output device 1220 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0292] In some embodiments, the output device 1220 includes one or more speakers for generating sound. For example, the output device 1220 may generate an audible alarm or notification (e.g., a beep or ringtone). In some embodiments, the output device 1220 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of the output device 1220 may be integrated with the input device 1215. For example, the input device 1215 and the output device 1220 may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device 1220 may be located near the input device 1215.

[0293] Transceiver 1225 includes at least a transmitter 1230 and at least one receiver 1235. One or more transmitters 1230 can be used to communicate with a UE, as described herein. Similarly, one or more receivers 1235 can be used to communicate with network functions in an NPN, PLMN, and / or RAN, as described herein. Although only one transmitter 1230 and one receiver 1235 are described, network device 1200 can have any suitable number of transmitters 1230 and receivers 1235. Furthermore, transmitters 1230 and receivers 1235 can be of any suitable type.

[0294] Figure 13 This is a flowchart of method 1300 for UAS authentication and security establishment. Method 1300 can be executed by network functions such as UFES155, 3GPP network functions, and / or network devices 1200. In some embodiments, method 1300 can be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0295] In one embodiment, method 1300 includes sending an authentication request message 1305 from a user equipment (“UE”) to a UAS service provider (“USS”) / UAS traffic management (“UTM”) from a first network function of a mobile wireless communication network. The UE includes at least one of a drone (“UAV”) and a UAV controller (“UAV-C”). In other embodiments, method 1300 includes receiving an authentication response message 1310 from the USS / UTM at the first network function. The authentication response message includes a UAS identifier and a UAS security context, the UAS security context including a UAS root key and a UAS root key identifier. Method 1300 ends.

[0296] Figure 14 This is a flowchart of method 1400 for UAS authentication and security establishment. Method 1400 can be executed by network functions such as UFES155, UCF, 3GPP network functions, and / or network functions of network device 1200. In some embodiments, method 1400 can be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0297] In one embodiment, method 1400 includes receiving a command and control ("C2") pairing request 1405 from a first user equipment ("UE") device at a network function of a mobile wireless communication network, the C2 pairing request including at least one parameter for establishing secure communication between the first UE device and a second UE device.

[0298] In one embodiment, method 1400 includes verifying at least one parameter 1410 at a network function based on a local storage of a UAV system (“UAS”) security context at the network function, the UAS including first and second UE devices. In one embodiment, method 1400 includes sending a pairing request 1415C2 from the network function to a UAS service provider (“USS”) / UAS traffic management (“UTM”) in response to successful verification of at least one parameter.

[0299] In one embodiment, method 1400 includes receiving a 1420C2 pairing response from the USS / UTM at the network function. In one embodiment, method 1400 includes sending a 1425C2 pairing response from the network function to the first UE device to establish secure communication. Method 1400 ends.

[0300] Figure 15 This is a flowchart of method 1500 for UAS authentication and security establishment. Method 1500 can be executed by a UE such as UAV 106, UAV-C 108, remote unit 105, and / or user equipment device 1100. In some embodiments, method 1500 can be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0301] In one embodiment, method 1500 includes sending a 1505 command and control (“C2”) pairing request from a first user equipment (“UE”) device to a network function of a mobile wireless communication network to establish secure communication between the first UE device and a second UE device.

[0302] In one embodiment, method 1500 includes receiving a 1510C2 pairing response from a network function, the C2 pairing response including at least one of a success indicator, a UAS session key identifier, a UAS session key, UAS security information, a selected security algorithm, and an address for a second UE device.

[0303] In one embodiment, method 1500 includes deriving a second UAS session key 1515 using a locally stored UAS root key and deriving a second UAS session key identifier using the second UAS session key. In another embodiment, method 1500 includes verifying 1520 that the second UAS session key identifier matches a UAS session key identifier received in a C2 pairing response.

[0304] In one embodiment, method 1500 includes deriving 1525 a security key based on the UAS session key for protecting communication between the first and second UE devices. In another embodiment, method 1500 includes establishing 1530 secure communication with the second UE device using the at least one security key. Method 1500 ends.

[0305] A first device for UAS authentication and security establishment is disclosed. The first device may include network functions such as UFES 155, 3GPP network functions, and / or network device 1200. In some embodiments, the first device may include a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0306] In one embodiment, the first device includes a transceiver that sends an authentication request message from a user equipment (“UE”) to a UAS service provider (“USS”) / UAS traffic management (“UTM”) from a first network function of the mobile wireless communication network. The UE includes at least one of a drone (“UAV”) and a UAV controller (“UAV-C”). In some embodiments, the transceiver receives an authentication response message from the USS / UTM at the first network function. The authentication response message includes a UAS identifier and a UAS security context, the UAS security context including a UAS root key and a UAS root key identifier.

[0307] In one embodiment, the authentication response message further includes at least one of authentication success indication, UAV identifier, command and control (“C2”) assistance information, and authorization token. In one embodiment, the first device includes a processor that locally stores authentication success, received UAV identifier, UAS identifier, C2 assistance information, authorization token, and UAS security context at a first network function.

[0308] In one embodiment, the C2 auxiliary information includes at least one of a UAV-C identifier, a UAV3 type indicator, and a UAV-C serving network identifier. In one embodiment, the transceiver transmits the received authentication response message from a first network function to the Access and Mobility Management Function (“AMF”) of the mobile wireless communication network.

[0309] In one embodiment, the transceiver receives an authentication request message from the Access and Mobility Management Function (“AMF”) of a mobile wireless communication network. The authentication request message includes an identifier of a UAV, and the processor locally stores the UAV identifier at a first network function, wherein the transceiver sends an authentication request message to the USS / UTM in response to receiving the authentication request message.

[0310] A first method for UAS authentication and security establishment is disclosed. The first method can be executed by a network function such as UFES 155, 3GPP network functions, and / or network functions of network device 1200. In some embodiments, the first method can be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0311] In one embodiment, the first method includes sending an authentication request message from a user equipment (“UE”) to a UAS service provider (“USS”) / UAS traffic management (“UTM”) from a first network function of a mobile wireless communication network. The UE includes at least one of a drone (“UAV”) and a UAV controller (“UAV-C”). In some embodiments, the first method includes receiving an authentication response message from the USS / UTM at the first network function. The authentication response message includes a UAS identifier and a UAS security context, the UAS security context including a UAS root key and a UAS root key identifier.

[0312] In one embodiment, the authentication response message further includes at least one of authentication success indication, UAV identifier, command and control (“C2”) assistance information, and authorization token. In one embodiment, the first method includes locally storing authentication success, received UAV identifier, UAS identifier, C2 assistance information, authorization token, and UAS security context at a first network function.

[0313] In one embodiment, the C2 auxiliary information includes at least one of a UAV-C identifier, a UAV3 type indicator, and a UAV-C serving network identifier. In one embodiment, the first method includes sending a received authentication response message from a first network function to an Access and Mobility Management Function (“AMF”) of a mobile wireless communication network.

[0314] In one embodiment, the first method includes receiving an authentication request message from an access and mobility management function (“AMF”) of a mobile wireless communication network, the authentication request message including an identifier of a UAV; locally storing the UAV identifier at a first network function; and sending an authentication request message to a USS / UTM in response to receiving the authentication request message.

[0315] A second device for UAS authentication and security establishment is disclosed. The second device may include network functions such as UFES 155, UCF, 3GPP network functions, and / or network device 1200. In some embodiments, the second device includes a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0316] In one embodiment, the second device includes a transceiver that receives a command and control ("C2") pairing request from a first user equipment ("UE") device at a network function of a mobile wireless communication network. The C2 pairing request includes at least one parameter for establishing secure communication between the first UE device and the second UE device.

[0317] In one embodiment, the second device includes a processor that verifies at least one parameter at a network function based on a local storage of a UAV system (“UAS”) security context at the network function, the UAS including first and second UE devices. In one embodiment, the transceiver, in response to successful verification of at least one parameter, sends a C2 pairing request from the network function to the UAS service provider (“USS”) / UAS traffic management (“UTM”); receives a C2 pairing response from the USS / UTM at the network function; and sends a C2 pairing response from the network function to the first UE device to establish secure communication.

[0318] In one embodiment, the first UE device includes a drone (“UAV”) and the second UE device includes a UAV controller (“UAV-C”), and the first UE device includes UAV-C and the second UE device includes a UAV. In one embodiment, the C2 pairing request includes at least one of a UAV identifier, a UAV-C identifier, a UAS identifier, UAV security capability information, a UAS authorization token, a random number, a UAS security information identifier, a UAS root key, and a UAS session key identifier.

[0319] In one embodiment, the processor verifies that the received UAV identifier, UAS identifier, and UAS authorization token match the corresponding UAV identifier, UAS identifier, and UAS authorization token stored locally at the first network function, and in response to a successful match, determines the C2 pairing information stored locally at the network function to check: whether the UAV and / or UAV-C can be used for UAS communication, the location of the UAV and / or UAV-C, and whether the UAV and / or UAV-C is authenticated.

[0320] In one embodiment, the C2 pairing response includes at least one of a success indicator, a UAS session key, a UAS session key identifier, UAS security information, a selected security algorithm, and an address for UAV-C.

[0321] A second method for UAS authentication and security establishment is disclosed. This second method can be executed by network functions such as UFES 155, UCF, UASNF, 3GPP network functions, and / or network functions of network device 1200. In some embodiments, the second method can be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0322] In one embodiment, the second method includes receiving a command and control ("C2") pairing request from a first user equipment ("UE") device at a network function of a mobile wireless communication network, the C2 pairing request including at least one parameter for establishing secure communication between the first UE device and the second UE device.

[0323] In one embodiment, the second method includes verifying at least one parameter at a network function based on a local security context of an unmanned aerial system (“UAS”) stored at the network function, the UAS including first and second UE devices. In one embodiment, the second method includes, in response to successful verification of at least one parameter, sending a C2 pairing request from the network function to a UAS service provider (“USS”) / UAS traffic management (“UTM”); receiving a C2 pairing response from the USS / UTM at the network function; and sending a C2 pairing response from the network function to the first UE device to establish secure communication.

[0324] In one embodiment, the first UE device includes a drone (“UAV”) and the second UE device includes a UAV controller (“UAV-C”), and the first UE device includes UAV-C and the second UE device includes a UAV. In one embodiment, the C2 pairing request includes at least one of a UAV identifier, a UAV-C identifier, a UAS identifier, UAV security capability information, a UAS authorization token, a UAS root key, and a UAS session key identifier.

[0325] In one embodiment, the second method includes verifying that the received UAV identifier, UAS identifier, and UAS authorization token match the corresponding UAV identifier, UAS identifier, and UAS authorization token stored locally at the first network function, and in response to a successful match, determining C2 pairing information stored locally at the network function to check: whether the UAV and / or UAV-C can be used for UAS communication, the location of the UAV and / or UAV-C, and whether the UAV and / or UAV-C is authenticated.

[0326] In one embodiment, the C2 pairing response includes at least one of a success indicator, a UAS session key, a UAS session key identifier, UAS security information, a selected security algorithm, and an address for UAV-C.

[0327] A third device for UAS authentication and security establishment is disclosed. The third device may include a UE, such as UAV106, UAV-C108, remote unit105, and / or user equipment device1100. In some embodiments, the third device may include a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0328] In one embodiment, the third device includes a transceiver that sends a command and control ("C2") pairing request from a first user equipment ("UE") device to a network function of a mobile wireless communication network to establish secure communication between the first UE device and a second UE device. The C2 pairing request includes at least one of an identifier for the first UE device, an identifier for the second UE device, an identifier for an unmanned aerial vehicle system ("UAS") including the first and second UE devices, security capability information for the first UE device, a UAS authorization token, a random number, a UAS security information identifier, a UAS root key, and a UAS session key identifier.

[0329] In one embodiment, the transceiver receives a C2 pairing response from a network function. The C2 pairing response includes at least one of a success indicator, a UAS session key identifier, a UAS session key, UAS security information, a selected security algorithm, and an address for a second UE device.

[0330] In one embodiment, the third device includes a processor that derives a second UAS session key using a locally stored UAS root key and derives a second UAS session key identifier using the second UAS session key; verifies that the second UAS session key identifier matches a UAS session key identifier received in a C2 pairing response; derives at least one security key based on the UAS session key for protecting communication between the first and second UE devices; and establishes secure communication with the second UE device using the at least one security key.

[0331] In one embodiment, the transceiver further receives an authentication response message from a second network function of the mobile wireless communication network. The authentication response message includes at least one or more of the following: a success indication, a UAV identifier, a UAS identifier, a UAV-C identifier, an authorization token, and a UAS security context.

[0332] In one embodiment, in response to receiving an authentication response message with a success indication, the processor locally stores the UAV identifier, UAS identifier, UAV-C identifier, authorization token, and received UAS security context, and generates a UAS security context using the UAV's long-term credentials, the UAS identifier, and the UAV identifier. In one embodiment, the processor uses the UAS security context to establish a secure connection with the USS / UTM.

[0333] A third method for UAS authentication and security establishment is disclosed. This third method can be executed by a UE such as UAV 106, UAV-C 108, remote unit 105, and / or user equipment device 1100. In some embodiments, the third method can be executed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0334] In one embodiment, the third method includes sending a command and control ("C2") pairing request from a first user equipment ("UE") device to a network function of a mobile wireless communication network to establish secure communication between the first UE device and a second UE device. The C2 pairing request includes at least one of an identifier for the first UE device, an identifier for the second UE device, an identifier for an unmanned aerial vehicle system ("UAS") including the first and second UE devices, security capability information for the first UE device, a UAS authorization token, a UAS root key, and a UAS session key identifier.

[0335] In one embodiment, the third method includes receiving a C2 pairing response from a network function, the C2 pairing response including at least one of a success indicator, a UAS session key identifier, a UAS session key, UAS security information, a selected security algorithm, and an address for a second UE device.

[0336] In one embodiment, the third method includes deriving a second UAS session key using a locally stored UAS root key and deriving a second UAS session key identifier using the second UAS session key; verifying that the second UAS session key identifier matches a UAS session key identifier received in a C2 pairing response; deriving at least one security key based on the UAS session key for protecting communication between the first and second UE devices; and establishing secure communication with the second UE device using the at least one security key.

[0337] In one embodiment, the third method includes receiving an authentication response message from a second network function of a mobile wireless communication network, the authentication response message including at least one or more of a success indication, a UAV identifier, a UAS identifier, a UAV-C identifier, an authorization token, and a UAS security context.

[0338] In one embodiment, in response to receiving an authentication response message with a success indication, the third method includes locally storing a UAV identifier, a UAS identifier, a UAV-C identifier, an authorization token, and a received UAS security context, and generating a UAS security context using the UAV's long-term credentials, the UAS identifier, and the UAV identifier. In one embodiment, the third method includes using the UAS security context to establish a secure connection with the USS / UTM.

[0339] The embodiments may be practiced in other specific forms. The described embodiments are to be regarded in all respects as illustrative only and not restrictive. Therefore, the scope of the invention is indicated by the appended claims, and not by the foregoing description. All variations within the meaning and equivalents of the claims are to be included within their scope.

Claims

1. A device for wireless communication, including a first network function, the device comprising: At least one memory; as well as At least one processor, coupled to the at least one memory and configured to cause the device to: The first network function sends an authentication request message from a user equipment (UE) to the unmanned aerial vehicle (UAS) service provider (USS / UAS Traffic Management UTM), wherein the UE includes at least one of a drone (UAV) and a UAV controller (UAV-C), and the authentication request message includes a Civil Aviation Administration of China (CAA) level UAV identifier associated with a UAS root key identifier. as well as At the first network function, an authentication response message is received from the USS / UTM. The authentication response message includes a UAS identifier and a UAS security context, wherein the UAS security context includes a UAS root key and a UAS root key identifier.

2. The device according to claim 1, wherein, The authentication response message further includes at least one of the following: authentication success indication, the identifier of the UAV, command and control C2 auxiliary information, and authorization token.

3. The device according to claim 2, wherein, The at least one processor is configured to cause the device to locally store the authentication success, the received UAV identifier, the UAS identifier, the C2 assistance information, the authorization token, and the UAS security context at the first network function.

4. The device according to claim 2, wherein, The C2 auxiliary information includes at least one of the UAV-C identifier, UAV3 type indicator, and UAV-C service network identifier.

5. The device according to claim 2, wherein, The at least one processor is configured to cause the device to send the received authentication response message from the first network function to the Access and Mobility Management Function (AMF).

6. The device according to claim 1, wherein, The at least one processor is configured to cause the device to: The authentication request message is received from the Access and Mobility Management Function (AMF), and the authentication request message includes the identifier of the UAV; The UAV identifier is stored locally at the first network function; and In response to receiving the authentication request message, the authentication request message is sent to the USS / UTM.

Images