UAS Authentication and Security Establishment

Abstract

An apparatus (1200) includes a transceiver (1225) for transmitting an authentication request message from a user equipment ("UE") to a UAS service supplier ("USS") / UAS traffic management ("UTM") from a first network function of a mobile wireless communications network, the UE comprising at least one of an unmanned aerial vehicle ("UAV") and a UAV controller ("UAV-C"). The transceiver (1225) receives an authentication response message from the USS / UTM at the first network function, the authentication response message comprising a UAS identifier and a UAS security context, the UAS security context comprising a UAS root key and a UAS root key identifier.

Description

[Technical Field]

[0001] Cross-reference of related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 062,286, titled "APPARATUSES, METHODS, AND SYSTEMS FOR UAS COMMAND AND CONTROL SECURITY SETUP AND MANAGEMENT IN 3GPP NETWORKS," filed on 6 August 2020 by Sheeba Backia Mary Baskaran et al., which is incorporated herein by reference.

[0002] The subject matter disclosed herein generally relates to wireless communications, and more specifically to UAS authentication and security establishment. [Background technology]

[0003] In some wireless communication systems, user equipment devices ("UE") can connect to fifth-generation ("5G") core networks (i.e., "5GC") within a public switched telephone network ("PLMN"). In a wireless network, an unmanned aerial vehicle system ("UAS") may include unmanned aerial vehicles ("UAV"), UAV controllers ("UAV-C"), UAS service suppliers ("USS"), and UAS traffic management ("UTM") functions that communicate via the wireless communication system. [Overview of the Initiative] [Means for solving the problem]

[0004] Procedures for UAS authentication and security establishment are disclosed. These procedures may be implemented by devices, systems, methods, and / or computer program products.

[0005] One method of a network function in a mobile communications network (e.g., UCFS, UAS NF, NEF) includes the step of sending an authentication request message from a user device ("UE") to a UAS service supplier ("USS") / UAS traffic management ("UTM") from a first network function of a mobile wireless communications network, the UE comprising at least one of an unmanned aerial vehicle ("UAV") and a UAV controller ("UAV-C"). In some embodiments, the method includes the step of receiving an authentication response message from the USS / UTM to the first network function, the UAS security context comprising a UAS identifier and a UAS security context comprising a UAS root key and a UAS root key identifier.

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

[0007] One method of a user equipment device ("UE") (e.g., UAV, UAV-C) includes the step of sending a command and control ("C2") pairing request from a first user equipment ("UE") device to the network function of a mobile wireless communication network for establishing secure communication between the first UE device and the second UE device, the C2 pairing request comprising at least one of the following: an identifier for the first UE device, an identifier for the second UE device, an identifier for an unmanned aerial vehicle system ("UAS") comprising the first UE device and the second UE device, security capability information for the first UE device, a UAS authentication token, a nonce, a UAS security information identifier, a UAS root key, and a UAS session key identifier.

[0008] In one embodiment, the method includes receiving a C2 pairing response from a network function, which comprises at least one of a success indicator, a UAS session key identifier, a UAS session key, UAS security information, a selected security algorithm, and the address of a second UE device. In one embodiment, the method includes deriving a second UAS session key using a locally stored UAS root key, deriving a second UAS session key identifier using the second UAS session key, verifying that the UAS session key identifier received in the C2 pairing response matches the second UAS session key identifier, deriving at least one security key to secure communication between the first UE device and the second UE device based on the UAS session key, and establishing secure communication with the second UE device using the at least one security key.

[0009] A more detailed description of the embodiments briefly outlined above will be made with reference to specific embodiments shown in the accompanying drawings. While it should be understood that these drawings only illustrate a few embodiments and should therefore not be considered limiting in scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings. [Brief explanation of the drawing]

[0010] [Figure 1] This is a schematic block diagram showing one embodiment of a wireless communication system for UAS authentication and security establishment. [Figure 2] This is a signal flow diagram illustrating one embodiment of the procedure for UAS authentication and key establishment. [Figure 3] This is a signal flow diagram illustrating one embodiment of the procedure for C2 security mode commands. [Figure 4a] This diagram shows the first option in the UAS key hierarchy. [Figure 4b] This diagram shows the second option in the UAS key hierarchy. [Figure 5] This is a signal flow diagram showing the first option for the procedure for setting up command and control security between a UAV and a UAV-C. [Figure 6] This is a signal flow diagram showing a second option for the procedure for setting up command and control security between a UAV and a UAV-C. [Figure 7] A signal flow diagram illustrating one embodiment of the procedure for command and control security setup between a UAV and a TPAE. [Figure 8a] This is a signal flow diagram illustrating one embodiment of the procedure for UAS authentication based on SEAL. [Figure 8b] This is a signal flow diagram illustrating one embodiment of the procedure for UAS key management based on SEAL. [Figure 9] This figure shows an embodiment of a UAS key hierarchy based on AKMA. [Figure 10] This is a signal flow diagram illustrating one embodiment of the procedure for generating a UAS key based on AKMA for establishing C2 security. [Figure 11] This is a block diagram showing one embodiment of a user device that can be used for UAS authentication and security establishment. [Figure 12] This is a block diagram showing one embodiment of a network device that may be used for UAS authentication and security establishment. [Figure 13] This is a flowchart illustrating one embodiment of a method for UAS authentication and security establishment. [Figure 14] This is a flowchart illustrating one embodiment of a method for UAS authentication and security establishment. [Figure 15] This is a flowchart illustrating one embodiment of a method for UAS authentication and security establishment. [Modes for carrying out the invention]

[0011] As will be understood by those skilled in the art, embodiments of the model can be embodied as a system, apparatus, method, or program product. Accordingly, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments that combine software and hardware aspects.

[0012] For example, the disclosed embodiments may be implemented as hardware circuits comprising custom very large-scale integrated ("VLSI") circuits or commercially available semiconductors such as gate arrays, logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, or programmable logic devices. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0013] 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, hereafter referred to as code. The storage device may be tangible, non-temporary, and / or non-transmitting. The storage device does not have to embody signals. In some embodiments, the storage device utilizes only signals for accessing the code.

[0014] Any combination of one or more computer-readable media may be used. A computer-readable media may be a computer-readable storage medium. A computer-readable storage medium may be a storage device that stores code. A storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination thereof.

[0015] More specific examples of storage devices (a non-exclusive list) include electrical connections with one or more wires, portable computer diskettes, hard disks, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM") or flash memory, portable compact disk 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 may be any tangible medium that can contain or store a program for use by or related to an instruction execution system, apparatus, or device.

[0016] The code for performing the actions for the embodiments may be of any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, and C++, and traditional procedural programming languages ​​such as the “C” programming language, and / or machine languages ​​such as assembly language. The code may run entirely on the user’s computer, partially on the user’s computer, as a standalone 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 scenario, the remote computer may be connected to the user’s computer through any type of network, including a local area network (“LAN”), a wireless LAN (“WLAN”), or a wide area network (“WAN”), or the connection may be to an external computer (for example, via the Internet using an Internet Service Provider (“ISP”)).

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

[0018] Throughout this specification, any reference to “one embodiment,” “a certain embodiment,” or similar expression means that the specific features, structure, or characteristics described in relation to the embodiment are included in at least one embodiment. Thus, throughout this specification, any occurrence of the phrases “in one embodiment,” “in a certain embodiment,” and similar expressions may, but not necessarily, all refer to the same embodiment and, unless otherwise explicitly stated, mean “one or more embodiments, but not all.” The terms “include,” “equip,” “have,” and variations thereof mean “include, but not limited to,” unless otherwise explicitly stated. An enumerated list of items does not imply that any or all of those items are mutually exclusive unless otherwise explicitly stated. The terms “a,” “an,” and “the” also mean “one or more,” unless otherwise explicitly stated.

[0019] As used herein, an enumeration using the conjunction "and / or" includes any single item in the enumeration or any combination of items in the enumeration. For example, the enumeration A, B, and / or C includes A only, B only, C only, 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, an enumeration using the term "one or more of" includes any single item in the enumeration or any combination of items in the enumeration. For example, one or more A, B, and C includes A only, B only, C only, 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, an enumeration using the term "one of" includes only one of any single items in the enumeration. For example, "one of A, B, and C" includes A only, B only, or C only, and does not include a combination of A, B, and C. As used herein, “members selected from the group consisting of A, B, and C” includes only one of A, B, or C, and does not include any combination of A, B, and C. As used herein, “members selected from the group consisting of A, B, and C and any combination thereof” includes A only, B only, C only, 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.

[0020] The aspects of the embodiments are described below with reference to schematic flowcharts and / or schematic block diagrams of the methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block in the schematic flowcharts and / or schematic block diagrams, as well as combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. Since this code can be provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device to produce a machine, instructions executed via the processor of the computer or other programmable data processing device create means for implementing the functions / activities specified in the flowcharts and / or block diagrams.

[0021] Code can also be stored in a memory device, which can instruct a computer, other programmable data processing device, or other device to function in a particular way. Thus, instructions stored in a memory device produce a manufactured article containing instructions that implement the functions / activities specified in a flowchart and / or block diagram.

[0022] Code can also be loaded onto a computer, another programmable data processing device, or another device to produce a process that runs on the computer, such that a series of action steps are performed on the computer, so that the code running on the computer or another programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagrams.

[0023] The flowcharts and / or block diagrams in the drawings illustrate the architecture, function, and operation of possible implementations of devices, systems, methods, and program products in various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code containing one or more executable instructions of code for implementing a specified logical function.

[0024] It should also be noted that in some alternative implementations, the functions described in a block may exist in a different order than those described in the drawing. For example, depending on the functions involved, two blocks shown consecutively may actually be executed substantially simultaneously, or in some cases, the blocks may be executed in reverse order. Other steps and methods can be conceived that are equivalent in function, logic, or effect to one or more blocks or parts of the drawing shown.

[0025] Various types of arrows and lines may be used in flowcharts and / or block diagrams, but they are understood to limit the scope of the corresponding embodiment. In fact, some arrows and other connectors may be used only to indicate the logical flow of the illustrated embodiment. For example, an arrow may indicate a waiting or monitoring period of an unspecified length between enumerated steps of the illustrated embodiment. It should also be noted that each block in a block diagram and / or flowchart, as well as combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and code that performs a specified function or action.

[0026] The descriptions of elements in each figure may refer to elements in preceding drawings. Similar numbers refer to similar elements in all drawings, including alternative embodiments of similar elements.

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

[0028] In one embodiment, a 3GPP® system supports UAS, providing ubiquitous coverage, seamless mobility, high reliability, and, more importantly, greater security and safety for UAV communications, which are controlled by various parties such as UAV-C, UAS service suppliers / UAS traffic management ("USS / UTM") and / or third-party authorized entities ("TPAE"). In some embodiments, conventional 5G systems do not support UAS operation (e.g., command and control ("C2") signaling over the 5G infrastructure between UAVs and controlling parties such as UAV-C, USS / UTM, and TPAE), and therefore lack the security features available to protect UAS communications.

[0029] The measures proposed in this disclosure provide a C2 security establishment procedure to improve overall UAS security in 5G systems by supporting data protection (e.g., confidentiality, integrity, and replay) for C2 signaling transmitted to UAVs by UAV-C, USS / UTM, and / or TPAE.

[0030] Figure 1 shows a wireless communication system 100 for UAS authentication and security establishment according to an embodiment of the present disclosure. 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 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. While a specific number of remote units 105, 3GPP access networks 120, cellular base units 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140 are shown in Figure 1, those skilled in the art will recognize that any number of remote units 105, 3GPP access networks 120, cellular base units 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140 may be included in the wireless communication system 100.

[0031] In one implementation, RAN120 conforms to a 5G system as defined in the Third Generation Partnership Project ("3GPP") specifications. For example, RAN120 may be an NG-RAN and implement an NR RAT and / or an LTE RAT. In another example, RAN120 may be an NG-RAN and implement an NR RAT and / or an LTE RAT. In yet another example, RAN120 may include a non-3GPP RAT (e.g., Wi-Fi® or an IEEE 802.11 compliant WLAN). In yet another implementation, RAN120 conforms to an LTE system as defined in the 3GPP specifications. However, more generally, the wireless communication system 100 may implement any other open or proprietary communication network, among others, such as Worldwide Interoperability for Microwave Access ("WiMAX") or the IEEE 802.16 standards. This disclosure is not limited to any particular wireless communication system architecture or protocol implementation.

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

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

[0034] The remote unit 105 may communicate directly with one or more cellular base units 121 in the 3GPP access network 120 via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the 3GPP communication link 123. Similarly, the remote unit 105 may communicate with one or more access points 131 in the non-3GPP access network 130 via UL and DL communication signals carried over the non-3GPP communication link 133. Here, the access networks 120 and 130 are intermediate networks that provide the remote unit 105 with access to the mobile core network 140.

[0035] In some embodiments, the remote unit 105 communicates with a remote host (for example, in data network 150 or in data network 160) via a network connection with the mobile core network 140. For example, an application 107 of the remote unit 105 (for example, a web browser, media client, telephone, and / or Voice over Internet Protocol ("VoIP") application) may cause the remote unit 105 to establish a protocol data unit ("PDU") session (or other data connection) with the mobile core network 140 via the 5G-RAN 115 (i.e., via the 3GPP access network 120 and / or non-3GPP network 130). The mobile core network 140 then uses the PDU session to relay traffic between the remote unit 105 and the remote host. The PDU session represents a logical connection between the remote unit 105 and the user plane function ("UPF") 141.

[0036] To establish a PDU session (or PDN connection), the remote unit 105 must register with the mobile core network 140 (also referred to as "connecting to the mobile core network" in the context of a fourth-generation ("4G") system). Note that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. Thus, the remote unit 105 may have at least one PDU session for communicating with the packet data network 150. In addition or alternatively, the remote unit 105 may have at least one PDU session for communicating with the packet data network 160. The remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0037] In the context of a 5G system ("5GS"), the term "PDU session" refers to a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between a remote unit 105 and a specific data network ("DN") via UPF 131. A PDU session supports one or more quality of service ("QoS") flows. In some embodiments, there may be a one-to-one correspondence between QoS flows and QoS profiles, so that all packets belonging to a particular QoS flow have the same 5G QoS identifier ("5QI").

[0038] In the context of 4G / LTE systems such as Evolutionary Packet Systems ("EPS"), a Packet Data Network ("PDN") connection (also called an EPS session) provides an end-to-end (E2E) up-to-end (UP) connection between the remote unit and the PDN. The PDN connection procedure establishes a tunnel between the EPS bearer, i.e., the remote unit 105, and a packet gateway ("PGW", not shown) in the mobile core network 130. In some embodiments, there is a one-to-one correspondence between the EPS bearer and the QoS profile, so that all packets belonging to a particular EPS bearer have the same QoS class identifier ("QCI").

[0039] As will be explained in more detail below, the remote unit 105 may use the 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, the remote unit 105 uses the first data connection to register with the second mobile core network 140.

[0040] The cellular base units 121 may be distributed across geographical areas. In some embodiments, the cellular base units 121 may also be referred to as access terminals, bases, base stations, 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 nodes, devices, or by any other terminology used in the art. The cellular base units 121 are generally part of a radio access network ("RAN"), such as a 3GPP access network 120, which may include one or more controllers communicatively coupled to one or more corresponding cellular base 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. The cellular base units 121 connect to the mobile core network 140 via the 3GPP access network 120.

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

[0042] The non-3GPP access network 130 may be distributed across geographical areas. Each non-3GPP access network 130 may serve a number of remote units 105 within its serving area. Access points 131 within the non-3GPP access network 130 may communicate directly with one or more remote units 105 by receiving UL communication signals and transmitting DL communication signals to serve the remote units 105 in the temporal, frequency, and / or spatial domains. Both DL and UL communication signals are carried over the non-3GPP communication link 133. The 3GPP communication link 123 and the non-3GPP communication link 133 may utilize different frequencies and / or different communication protocols. In various embodiments, access points 131 may communicate using the unlicensed radio spectrum. As will be described in more detail herein, the mobile core network 140 may serve the remote units 105 via the non-3GPP access network 130.

[0043] In some embodiments, the non-3GPP access network 130 connects to the mobile core network 140 via a coordinating entity 135. The coordinating entity 135 facilitates coordination between the non-3GPP access network 130 and the mobile core network 140. The coordinating entity 135 supports connections via the "N2" and "N3" interfaces. As illustrated, both the 3GPP access network 120 and the coordinating entity 135 communicate with the AMF 143 using the "N2" interface. The 3GPP access network 120 and the coordinating entity 135 also communicate with the UPF 141 using the "N3" interface. Although illustrated as being outside the mobile core network 140, in other embodiments, the coordinating entity 135 may be part of the core network. Although illustrated as being outside the non-3GPP RAN 130, in other embodiments, the coordinating entity 135 may be part of the non-3GPP RAN 130.

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

[0045] In some embodiments, the UAV 106 and / or UAV-C controller 108 communicate with the UAV Flight Activation Subsystem ("UFES") / UAS Network Function ("UAS-NF") / Network Exposure Function ("NEF") 155 (collectively referred to as UFES 155 for brevity) and / or USS / UTM 157 function via a network connection to the mobile core network 140. In one embodiment, the UAS Network Function is supported by the NEF and used for external opening of services 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 associated revocation, and for QoS / traffic filtering control for location reporting and C2 communications. In one embodiment, the USS / UTM 157 provides a set of duplicate USSs to assist the UAV 106 operator 102 in performing safe and compliant operations. Services may include flight plan collision avoidance, remote identification, and other similar functions.

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

[0047] 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. Such a deployment of the non-3GPP AN is referred to as a “trusted non-3GPP access network.” The non-3GPP access network 130 is considered “trusted” when operated by a 3GPP operator or trusted partner and supports several security features, such as strong air interface coding. In contrast, a deployment of the non-3GPP AN 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 cooperative entity 135 deployed in the trusted non-3GPP access network 130 may be referred to herein as a Trusted Network Gateway Function (“TNGF”). A cooperative entity 135 deployed in an untrusted non-3GPP access network 130 may be referred to herein as a non-3GPP cooperative function ("N3IWF"). Although illustrated as part of the non-3GPP access network 130, in some embodiments the N3IWF may be part of a mobile core network 140 or located within a data network 150.

[0048] 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 a private data network, among other data networks. The remote unit 105 may have a contract 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 limited to any particular wireless communication system architecture or protocol implementation.

[0049] The mobile core network 140 includes several network functions ("NF"). As shown in the diagram, the mobile core network 140 includes at least one UPF ("UPF") 141. The mobile core network 140 also includes several control plane functions, including, but not limited to, an access and mobility management function ("AMF") 143, a session management function ("SMF") 145, a policy control function ("PCF") 146, an authentication server function ("AUSF") 147, an integrated data management ("UDM"), and an integrated data repository ("UDR") function that serve the 5G-RAN 115.

[0050] In a 5G architecture, UPF141 is responsible for packet routing and forwarding, packet inspection, QoS processing, and external PDU sessions for interconnecting data networks ("DNs"). AMF143 is responsible for NAS signaling termination, NAS encryption and integrity protection, registration management, connectivity management, mobility management, access authentication and authorization, and security context management. SMF145 is responsible for session management (i.e., session establishment, correction, and release), remote unit (i.e., UE) IP address allocation and management, DL data notification, and UPF traffic steering configuration for proper traffic routing.

[0051] PCF146 is responsible for the integrated policy framework, provides policy rules to the CP function, and accesses subscriber information for policy decisions in the UDR. AUSF147 functions as the authentication server.

[0052] The UDM is responsible for generating authentication and key agreement ("AKA") credentials, processing user identification, granting access, and managing contracts. The UDR is a repository of contractor information and may be used to serve a number of network functions. For example, the UDR may store contract data, policy-related data, and contractor-related data that are permitted to be released to third-party applications, etc. In some embodiments, the UDM occupies the same location as the UDR and is illustrated as a composite entity "UDM / UDR"149.

[0053] In various embodiments, the mobile core network 140 may also include a network exposure function ("NEF") (which is responsible for making network data and resources easily accessible to customers and network partners, for example, via one or more APIs), a network repository function ("NRF") (which performs NF service registration and discovery, enabling NFs to identify appropriate services from one another 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 also include an authentication, authorization, and billing ("AAA") server.

[0054] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, with each mobile data connection utilizing a specific network slice. Here, “network slice” refers to a portion of the mobile core network 140 optimized for a particular traffic type or communication service. Network instances may be identified by S-NSSAI, but the set of network slices authorized for use by the remote unit 105 is identified by NSSAI. In some embodiments, different 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. Different network slices are not shown in Figure 1 for simplicity of illustration, but their support is assumed.

[0055] While a specific number and type of network functions are illustrated in Figure 1, those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140. Furthermore, if the mobile core network 140 includes an EPC, the illustrated network functions may be replaced with appropriate EPC entities such as MME, S-GW, P-GW, HSS, etc.

[0056] Figure 1 illustrates the components of a 5G RAN and 5G core network, but the described embodiments for using pseudonyms for access authentication via non-3GPP access are applicable to other types of communication networks and RATs, including variations of IEEE 802.11, GSM, GPRS, UMTS, LTE, CDMA2000, Bluetooth, ZigBee, Sigfoxx, etc. For example, in a 4G / LTE variation involving an EPC, the AMF143 may be associated with the MME, the SMF may be associated with the control plane portion of the PGW and / or the MME, the UPF141 may be associated with the SGW and the user plane portion of the PGW, and the UDM / UDR149 may be associated with the HSS, and so on.

[0057] As illustrated, the remote unit 105 (e.g., UE) may connect to the mobile core network (e.g., the 5G mobile communication network) via two types of access: (1) via the 3GPP access network 120, and (2) via the non-3GPP access network 130. The first type of access (e.g., the 3GPP access network 120) uses a type of wireless communication defined by 3GPP (e.g., NG-RAN), and the second type of access (e.g., the non-3GPP access network 130) uses a type of wireless communication not defined by 3GPP (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.

[0058] To address the issue of securing UAS communications over the 5G system described above, this disclosure proposes a strategy to enable overall UAS security in a 5G system by providing a C2 security establishment procedure to support data protection (e.g., confidentiality, integrity, and replay) for C2 signaling transmitted to UAVs by UAV-C, USS / UTM, and / or TPAE.

[0059] In one embodiment, the 3GPP system supports UAS, providing ubiquitous coverage, seamless mobility, high reliability, and enhanced security and safety. For example, a 5G system can be used to enable UAS remote identification and line-of-sight tracking scenarios, and only approved UAS may be permitted to operate.

[0060] In some embodiments, security is critical to the deployment of secure UAS systems, such as protecting the confidentiality of identification information, protecting against spoofing attacks, providing different levels of integrity and privacy protection for different connections, and ensuring non-repudiation of data exchange at the signaling and data, application layers. It is necessary to provide measures to ensure an overall robust system that can meet the demands of stakeholders, such as regulators and network operators, who require consideration of the security aspects of the UAS system.

[0061] In some embodiments, the following architectural requirements and assumptions are considered for UAS connectivity, identification, and tracking. In one embodiment, the 3GPP system enables the UTM 157 to associate the UAV 106 and UAV controller 108 and identify them for both 3GPP network-connected and non-3GPP network-connected UAV controllers 108.

[0062] In one embodiment, each UAS 101 consists of one UAV controller 108 and one UAV 106. The UTM 157 may include a set of functions defined outside the 3GPP system and subject to specific regional requirements. The connection for command and control of the UAV 106 may be a connection between the UAV 106 and, mutually exclusive, the UAV controller 108, TPAE, or UTM 157.

[0063] In one embodiment, CAA-level UAV identification information may be assigned to UAV106 and networked UAV-C108, depending on their function in the aviation field (e.g., USS157) or in USS / UTM157. This assigned identification information may be used for remote identification and tracking. In one embodiment, a 3GPP UAV ID is used by the 3GPP system to identify UAV106.

[0064] With respect to network-connected UAV controllers 108 and non-network-connected UAV controllers 108, in one embodiment, pairing between UAV 106 and UAV controller 108 for use of UAV3 or UAV5 reference point may be at least approved, or even authenticated. Approval / authentication of pairing is approved by the USS / UTM, not by the 3GPP system, when performed. The 3GPP system enables such approval process. The results of such approval / authentication are communicated to the MNO to enable the USS / UTM 157 to establish a connection between UAV 106 and UAV controller 108. In one embodiment, UAV 106 is approved to connect to USS 157 via UAV9 reference point based on existing MNO policies and is permitted to establish a connection with a data network name ("DNN") to exchange traffic with USS 157 without USS approval.

[0065] In one embodiment, the subject matter disclosed herein proposes measures for establishing a C2 security context and protecting C2 (Application Data) traffic transported between UAV106 and various parties such as UAV-C108, UTM / USS157, and TPAE.

[0066] Generally, this disclosure focuses on UAS authentication and key management and C2 security setup procedures. For UAS authentication and key management, a UAS control function ("UCF"), separately called the UAS Management Function ("UASMF") / UAS Network Function ("UASNF"), is introduced, which operates in the 3GPP network on behalf of the UTM / USS to perform UAS-based control and management operations. In one embodiment, the UAS Network Function is supported by an NEF and used for external opening of services to the USS. The UASNF utilizes existing NEF / SCEF exposure services for UAS / UAV authentication / authorization, UAV flight authorization, UAV-UAVC pairing authorization, and associated revocation, and for QoS / traffic filtering control for location reporting and C2 communications. Note that the UCF may be related to and equivalent to UFES155 and UASAF / UASNF, as defined, for example, in TR23.754. Accordingly, this disclosure uses the common term UFES155 for the remainder of this disclosure, and all new features and operations described herein with respect to UFES155 are applicable to the new 3GPP network function UCF.

[0067] In one embodiment, the USS / UTM157 provides C2 support information to other network functions ("NFs") within the 3GPP network (e.g., UCF / UFES / UASNF / AMF / SMF, etc.) to assist in the selection of an appropriate UAV3 interface (e.g., intraPLMN UAV3 or interPLMN UAV3). The C2 support information may include a UAV3 type indicator and a UAV-C serving PLMN ID.

[0068] In one embodiment, the USS / UTM157 assigns an identifier to the UAS during successful UAS authentication and provides the identifier to the UAV106 and / or UAV-C108 via the 3GPP NF. As used herein, the UAS ID can uniquely identify the pair of UAV106 and UAV-C108 forming the UAS101. In one embodiment, it should be noted that the use of the UAS ID described herein is applicable to any ID assigned for the pairing function of the UAV106 and UAV-C108.

[0069] In one embodiment, during successful UAS authentication (e.g., application or EAP-based authentication), in one embodiment, key K is obtained from a pre-configured Long-Term Credential. UAS A root key is derived (for example, a root key for deriving other security keys for protecting UAS-related data). In a further embodiment, during successful UAS authentication, an authorization token is derived to allow USS / UTM157 or UFES155 to authorize the association of UAV C2 with UAV-C108. Inputs used in the authorization token may include the UAS ID, UAV-CAA-level ID, UAV-C ID, nonce, and timestamp.

[0070] In one embodiment, the authorization token is assigned an expiration time / lifetime to define the length of time during which the use of the authorization token by the UAV106 for association or acquisition of any service from the UTM / USS157 can be successful. In some embodiments, after successful UAS authentication between the UAV106 and the UTM / USS157, a C2 security mode command procedure is proposed to set up a C2 security context for the UAV106 with the UFES155 or UTM / USS157.

[0071] In one embodiment, key K UAS A UAS key hierarchy (for example, UAS root key) that includes KUAS-Sess (For example, UAS / C2 session key), CCEK (for example, command control encryption key), and CCIK (for example, command control integrity key) are proposed to enable UAS security.

[0072] Regarding the C2 security setup procedure, a session key is established for the confidentiality of C2 (application data), as well as for integrity protection in the following scenarios: between UAV106 and UAV-C108 via the UAV3 interface, between UAV106 and TPAE via the UAV4 interface, and between UAV106 and UFES / UTM / USS via the UAV9 interface.

[0073] This disclosure also describes alternative approaches to support SEAL-based authentication and key management for enabling UAS communication with 5G systems, as well as UAS security management based on Authentication and Key Management for Applications ("AKMA").

[0074] In one embodiment, the UAS authentication and key agreement procedure between UAV106, UAV-C108, and USS / UTM157 is described, along with how the C2 security context is established in the USS / UTM157 for UAV communication. The embodiment also describes how the same procedure may be supported in an Evolutionary Packet System ("EPS") 4G network. The UAS authentication procedure 200 shown in Figure 2 is described in the following steps.

[0075] In one embodiment, in steps 1 and 2 (see blocks 202 and 204), as a prerequisite, UAV106 is registered with USS / UTM157 by the operator of UAS102 using any method outside the scope of the 3GPP operator. UAV106 registers with the 5G network by performing primary authentication, for example, as specified in TS33.501. In one embodiment, AMF143 decides to trigger UAS authentication and send a UAS authentication required indicator in the registration acceptance message, based on the contract information of UAV106 retrieved from UDM / UDR149.

[0076] In step 3, in one embodiment (see messaging 206-226), when UAV106 receives a “UAS authentication required” indicator from AMF143, it initiates and performs UAS authentication with USS / UTM157 via 5G network control plane functions (e.g., AMF143, SMF145, UFES155, etc.). The procedure 200 defined herein defines, in one embodiment, UAS authentication-related request / response information exchanged between UAV106 and USS / UTM157, so that the information can be carried via either an application-based authentication protocol or an EAP-based authentication protocol at the NAS layer. UAS authentication messages can be sent over the NAS connection, and both their confidentiality and integrity are protected using 5G NAS security.

[0077] In step 3a, in one embodiment (see messaging 206), UAV 106 sends a UAS authentication request message that includes a CAA-level UAV ID along with USS routing information (for example, the USS routing information may be pre-configured on UAV 106 by USS 157 in step 1, or may be part of the CAA-level UAV ID), flight path data, and a target CAV-C ID (for example, for forming a UAS).

[0078] In step 3b, in one embodiment (see block 208), if AMF143 receives a CAA-level UAV ID along with USS routing information, AMF143 locally stores the CAA-level UAV ID along with the USS routing information. In step 3c, in one embodiment (see messaging 210), based on the USS routing information, AMF143 forwards the UAS authentication request message to UFES155 (for example, either directly or via SMF145). Alternatively, in one embodiment, based on the USS routing information, AMF143 may also forward the UAS authentication request message to USS / UTM157 (for example, either directly or via UFES155).

[0079] In step 3d, in one embodiment (see messaging 212), UFES155 locally stores the CAA level UAV ID and, if received, forwards the received UAS authentication request message to USS / UTM157. In step 3e, in one embodiment (see messaging 214), USS / UTM157 performs an authentication method-specific message exchange with UAV106 (e.g., application-based authentication or EAP-based authentication) to authenticate UAV106 and prove to UAV106 that it is genuine.

[0080] In step 3f, in one embodiment (see block 216), if the USS / UTM157 performs a successful authentication, it verifies the pre-configured CAA-level UAV ID and assigns a new CAA-level UAV ID to UAV106 if it is provided by UAV106 or based on the UAV contract. Furthermore, in one embodiment, if the UAV-C ID is received from UAV106 in the authentication request, the USS / UTM157 verifies whether, based on UAV106 and / or the UAS contract, UAV106 is authorized to associate with the UAV-C ID to form UAS101.

[0081] In one embodiment, if the verification of the association between the UAV ID and the UAV-C ID is successful, the USS / UTM157 assigns a UAS ID to uniquely identify the UAS101 formed by the UAV106 and UAV-C108. In one embodiment, after each successful UAS authentication of any UAV106 or UAV-C108, the USS / UTM157 locally stores the IDs of the UAV106 and UAV-C106, and the serving network information of the UAV106 and UAV-C108 (e.g., SN ID / serving PLMN ID and home PLMN ID).

[0082] Furthermore, in one embodiment, the USS / UTM157 determines whether UAV-C108 has recently been UAS certified based on UAS contracts, activity reports, and certification status information (e.g., UAS status records) available in the USS / UTM157. If the certification status records for UAV-C108 in the USS / UTM157 indicate that it has recently been certified, in one embodiment, the USS / UTM157 generates C2 support information for UAV-C108 based on the serving network identifier of UAV-C108. The C2 support information information element ("IE") may include the UAV-C ID, the UAV3 type indicator (e.g., intraPLMN UAV3 / interPLMN UAV3), and the UAV-C serving network ID.

[0083] If UAS authentication is successful, in one embodiment, the USS / UTM157 retrieves the UAS root key K from the long-term credentials stored in the UAV / UAS contract information within the USS / UTM157. UAS Generates K UAS The ID can be derived by USS / UTM157 simply 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.

[0084] In one embodiment, USS / UTM157 further generates an approval token using inputs such as CAA level UAV ID, UAV-C ID, UAS ID, and K UAS USS / UTM157 also assigns the lifespan (e.g., valid period or duration) of the approval token to be used by the 3GPP network to approve UAV106 during the C2 security setup for UAV communication.

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

[0086] In step 3g, in one embodiment (see Messaging 218), in response to a successful UAS authentication, USS / UTM157 sends a UAS authentication response message to UFES155. The UAS authentication response message may include a success indication, CAA level UAV ID, UAS ID, C2 support information, an approval token, and a UAS security context including K UAS ID and key K UAS .

[0087] ]>In step 3h, in one embodiment (see Block 220), UFES155 receives the UAS authentication response message and locally stores the received CAA level UAV ID, UAS ID, C2 support information (e.g., UVA-C ID, UAV3 type indicator (intra-PLMN UAV3 / inter-PLMN UAV3) and UAV-C serving network ID), approval token, and UAS security context (K UAS ID, K UAS ) as part of the UAS information (or UAS security context) for UAV106.

[0088] In step 3i, in one embodiment (see messaging 222), UFES155 sends the received UAS authentication response message to AMF143. The UAS authentication response message includes a success indicator, CAA level UAV ID, UAS ID, C2 support information, authorization token, and UAS security context (K UAS ID, K UAS ) includes.

[0089] In step 3j, in one embodiment (see messaging 224), AMF143 receives the received CAA-level UAV ID, UAS ID, C2 support information (e.g., UVA-C ID, UAV3 type indicator (intraPLMN UAV3 / interPLMN UAV3) and UAV-C serving network ID), authorization token, and UAS security context (K UAS ID, K UAS ) is stored locally as part of the UAS information (or UAS security context) for UAV106.

[0090] In one embodiment, AMF143 further sends a UAS authentication response message to UAV106. The UAS authentication response message includes a success indicator, CAA level UAV ID, UAS ID, authorization token, and UAS security context (K UAS (Includes ID)

[0091] In one embodiment, the AMF143 initiates a C2 connection via the UAV3 interface for communication between UAV106 and UAV-C108, using locally stored C2 association information.

[0092] In step 3k, in one embodiment (see block 226), when UAV106 receives a UAV authentication response message and a “success indicator”, UAV106, like USS / UTM157, uses the long-term credentials pre-configured in UAV106 in step 1 and the ID received in the UAS authentication response message (for example, as in step 3f) to establish the UAS security context (K UAS ID, K UAS ) generates.

[0093] In one embodiment, UAV106 uses locally generated K UAS The ID is received in step 3j. UAS Verify if it matches the ID. Locally generated K UAS ID and received K UAS If both IDs match, in one embodiment, UAV106 considers UAS authentication to be successful and receives the CAA level UAV ID, UAS ID, authorization token, and UAS security context (K UAS The ID) is the most recently derived K UAS It is stored locally as part of the UAS security context. In one embodiment, UAV106 is K UAS Using ID K UAS To uniquely identify it.

[0094] In one embodiment, to support the derivation of the UAS root key and the generation of C2 support information during the UAS-specific PDU session establishment procedure, the USS / UTM157 may execute step 3f when a UAV operation request (instead of an authentication request) is received from the UFES155 in step 3d. In this embodiment, step 3f as described above may be executed, and the USS / UTM157 sends the information transmitted in step 3g to the UFES155 in a UAV operation response message (instead of transmitting it in the UAS authentication response). In one embodiment, the UAV operation response includes a success indicator, a CAA level UAV ID, a UAS ID, C2 support information, an authorization token, and a UAS security context (K UAS ID, K UAS ) includes.

[0095] In step 4a, in one embodiment (see messaging 228), UAV106 initiates a C2 security setup procedure with USS / UTM157 to establish C2 session security between UAV106 and USS / UTM157. The UAS / C2 security setup procedure is transmitted via a NAS connection protected with NAS security and / or via an RRC connection.

[0096] In one embodiment, UAV106 sends a C2 security establishment request message to AMF143 in the NAS container. In one embodiment, the C2 security establishment request message includes routing information, UAS ID, authorization token, Nonce_1, security capability, and K UAS Include the UAV ID along with the ID (for example, the CAA-level UAV ID).

[0097] In step 4b, in one embodiment (see messaging 230), AMF143 decrypts the NAS container and forwards the received C2 security establishment request message to UFES155. In step 4c, in one embodiment (see messaging 232), UFES155 forwards the C2 security establishment request message to USS / UTM157.

[0098] In step 4d, in one embodiment (see block 234 and messaging 236), the USS / UTM157 uses locally stored UAS security context information associated with the UAS ID to K UAS Verify the ID, UAS ID, and authorization token. In one embodiment, K UAS If the UAS security context associated with the ID is available, the USS / UTM157 generates Nonce_2 and the locally stored UAS root key (K UAS ) from C2 session key (K UAS_Sess Derive ). ·K UAS_SESS =KDF(K UAS (UAS ID, CAA level UAV ID, Nonce1, Nonce2) ·K UAS_SESS ID:Hash(K UAS_Sess ) ·CCEK=KDF(K UAS_Sess (UAS ID, encryption algorithm ID, C2 type ID) ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0099] In one embodiment, the USS / UTM157 uses K to uniquely identify the UAS session key. UAS_SessThe ID (for example, 16 bits long) is further derived. In one embodiment, the USS / UTM157 selects an encryption algorithm and an integrity algorithm for C2 protection based on the local configuration and UAV security capabilities. Furthermore, in one embodiment, the USS / UTM157 selects the security algorithms (encryption and integrity), Nonce_2, K UAS_Sess ID, and K UAS_Sess The key is provided to UFES155 in the C2 security establishment response message to UFES155.

[0100] In step 4e, in one embodiment (see block 238), UFES155 receives the K along with the UAS security context information. UAS_Sess ID and K UAS_Sess The key is stored locally. In one embodiment, the UFES155 further sends the received C2 security establishment response message to the AMF143, and the C2 security establishment response message contains the selected security algorithm (encryption and integrity), Nonce_2, and K UAS_Sess Includes ID.

[0101] In step 4f, in one embodiment (see messaging 240), AMF143 sends the received C2 security establishment response message to UAV106, and the C2 security establishment response message contains the selected security algorithm (encryption and integrity), Nonce_2, and K UAS_Sess Includes ID.

[0102] In one embodiment, in step 4g (see messaging 242), when UAV106 receives Nonce_2, it receives the locally stored UAS root key (K UAS ) from C2 session key (K UAS_Sess ) generates. UAV106 further checks whether C2 session security is synchronized with USS / UTM157, like USS / UTM157, K UAS_SessAn ID is generated. In one embodiment, if it is found that the C2 session key and ID are synchronized, UAV106 determines that the UAS session key setup was successful. In one embodiment, UAV106 locally stores the received selected security algorithms (encryption and integrity) and Nonce_2.

[0103] In step 4h, in one embodiment (see messaging 244), UAV106 sends a C2 security establishment complete message to USS / UTM157, which is a new K UAS_Sess The key is used to encrypt and ensure integrity at the C2 application level (for example, using the CCEK and CCIK derived above). In one embodiment, step 4h may be transmitted either over the NAS connection or using user plane signaling. In one embodiment, depending on the deployment scenario of operator 102, the UAS / C2 security setup procedure may optionally be performed between UAV 106 and UFES 155 instead, where UFES 155 is used in place of USS / UTM 157 in steps 4a-4h as described above.

[0104] In one alternative embodiment, the UAS / C2 security setup between the UAV106 and the USS / UTM157 may be performed using the C2 security mode command procedure shown in Figure 3. In one embodiment, steps 1-6 in Figure 3 may be performed to set up security between the UAV106 and the USS / UTM157 instead of steps 4a-4h shown in Figure 2.

[0105] In step 1, in one embodiment (see block 302), the UFES155 and / or USS / UTM157 store the UAS root key after successful UAS authentication, which is derived and stored as described in step 4d of Figure 2 above. In one embodiment, the UFES155 and / or USS / UTM157 further generate Nonce_1 for use as input in the derivation of the session key.

[0106] In one embodiment, UFES155 and / or USS / UTM157 use the UAS session security key (K UAS_Sess ) and session key identifier (K UAS_Sess The ID is derived as follows: ·K UAS_Sess =KDF(K UAS (UAS ID, CAA level UAV ID, Nonce 1) ·K UAS_Sess ID:Hash(K UAS_Sess ) ·CCEK=KDF(K UAS_Sess (UAS ID, encryption algorithm ID, C2 type ID) ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0107] In one embodiment, the UFES155 and / or USS / UTM157 transmit a C2 security mode command message to the UAV106 (for example, via the 3GPP network function AMF143, UFES155, etc.). In one embodiment, the C2 security mode command message includes the UAS ID, Nonce_1, selected encryption and integrity protection algorithm identifier, K UAS ID and / or K UAS_Sess The ID is included. In one embodiment, the integrity of the C2 security mode command message is protected using a newly derived CCIK and a selected integrity algorithm.

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

[0109] In step 3, in one embodiment (see block 308), the UAV 106 receives the K UAS K stored locally using the ID UAS The ID is verified, and if they match, the UAV106 derives the UAS session key and UAS session key ID using the received Nonce_1, as defined in step 1 above, similar to the UFES155 and / or USS / UTM157. In one embodiment, the UAV106 further derives the newly derived K UAS_Sess K received the ID UAS_Sess The UAV106 verifies whether the ID matches, and if they do, it derives the CCEK and CCIK from the newly derived UAS session key, as defined in step 1 above, similar to the UFES155 and / or USS / UTM157. In such embodiments, the UAV106 uses the newly derived CCIK to verify the integrity of the received C2 security mode command message, and if the integrity verification is successful, the UAV106 performs step 4.

[0110] In step 4, in one embodiment (see messaging 310 and 312), the UAV 106 sends a C2 security mode completion message to the UFES 155 and / or USS / UTM 157 either directly or via a 3GPP network function 301 (e.g., AMF 143, UFES 155, etc.), and the 3GPP NF 301 forwards the received C2 security mode completion message to the USS / UTM 157. In one embodiment, the C2 security mode completion message is marked with "Success Indicator" and a newly derived K UAS_Sess The ID is included as proof of possession of the correct session key.

[0111] In step 5, in one embodiment (see block 314), UFES155 and / or USS / UTM157 receive a C2 security mode completion message, K UAS_Sess Using CCEK and CCIK based on this, the received message is decrypted / decoded and its integrity verified. "Success indicator" means that UAV106 has set up session security and K UAS_Sess This demonstrates that the ID serves as proof of possession of the correct session key.

[0112] In step 6, in one embodiment (see messaging 316), the UAV106 and UFES155 and / or USS / UTM157 use CCEK and CCIK to protect C2 communication data (C2 application data / signaling) for the lifetime of the UAS key or UAS session key.

[0113] Regarding the UAS key hierarchy, two options are illustrated as shown in Figures 4a and 4b, both of which can be implemented and used for UAS security. The UAS key hierarchy shown here is the UAS key (K UAS ), UAS session key (K UAS_SESS ) and UAS / C2 protection keys (e.g., CCEK for confidentiality / encryption and CCIK for integrity protection).

[0114] The various layers of the key are as follows: • Long-term Credentials 402: These are credentials prepared in UAV106 and form the security root for C2 application layer data. Depending on the UAS deployment scenario, the credentials may include a symmetric key or a public / private key pair. Alternatively, UAV106 and its corresponding UAV-C108 within UAS101 are prepared using the same UAS long-term credentials, which causes UAV106 and UAV-C108 to derive the same UAS root key after UAS authentication. ·K UAS 404: This is a root key (e.g., a 256-bit key) shared between UAV106 and UTM / USS157, and may also be shared with UAV-C108, TPAE, and UAS control functions / UFES155 within a 3GPP network, communicating using C2 via UAV3, UAV4, and UAV9 interfaces. This can be updated by performing authentication signaling again using long-term credentials. K UAS_Sess To generate the next layer of the key, a nonce is exchanged between the UAV106 and the UTM / USS155. UAS This can be maintained even when UAV106 does not have an active C2 communication session. UAS The ID is K UAS It can be used for identification. ·K UAS_Sess 406: This is the session key (e.g., a 256-bit key) which is the root of the actual security context used (or at least in the process of being established) to protect the transfer of C2 data between UAV106 and UTM / USS155, between UAV106 and UAV-C108, and between UAV106 and TPAE. The actual key used in the confidentiality and integrity algorithms is K UAS_Sess It can be directly derived from 16-bit K UAS_Sess The ID is K UAS_Sess It can be used for identification. • CCEK408 and CCIK410: C2 encryption keys (CCPEK) and C2 integrity keys (CCPIK) (e.g., 256-bit keys) are used, along with selected confidentiality and integrity algorithms, respectively, to protect C2 application data. UAS_Sess Derived from the key, K UAS_SessIt will be automatically updated whenever it changes.

[0115] Note that in one embodiment, the UAS root key may be derived by UAV106 and UAV-C108. In the case of UAV-C108, in one embodiment, the UAS root key may be provided by USS / UTM157 as an alternative. On the network side, in one embodiment, the UAS root key may be derived during successful UAS authentication by USS / UTM157 or UFES155. The UAS session key may be derived by UAV106, UAV-C108, USS / UTM157, UFES155, and TPAE (as shown in Figures 4a and 4b). In the case of TPAE, in one embodiment, the UAS session key may be provided by UFES155 as an alternative. The CCIK and CCEK may be derived by UAV106, UAV-C108, USS / UTM157, UFES155, TPAE, etc. for C2 protection. Alternatively, in the case of TPAE, UFES155 may provide the corresponding CCEK and CCIK.

[0116] K UAS From K UAS-sess In one embodiment, when calculating, the following parameters are used to form the input S to the key derivation function ("KDF"). FC=XXXX ·P0=Nonce_1 L0 = length of Nonce_1 (i.e., 0x00 0x10) ·P1=Nonce_2 L1 = length of Nonce_2 (i.e., 0x00 0x10) P2 = UAS ID L2 = Length of UAS ID P3 = UAV ID (e.g., CAA level UAV ID) L3 = Length of UAV ID

[0117] In one embodiment, the input key is a 256-bit K UAS This is the C2-specific K for UAV3, UAV4, and UAV9.UAS-sess For the derivation of , in one embodiment, the following inputs are also used in addition to the above inputs. · P4 = C2 type code (i.e., for indicating UAS C2, or USS C2, or TPAE C2) · L4 = Length of C2 type code (i.e., for indicating UAS C2, or USS C2, or TPAE C2)

[0118] K UAS-sess When calculating CCIK or CCEK from , in one embodiment, the following parameters are used to form the input S to the KDF. · FC = XXXX · P0 = 0x00 if CCEK is derived or 0x01 if CCIK is derived · L0 = Length of P0 (i.e., 0x00 0x01) · P1 = Algorithm identification information · L1 = Length of algorithm identification information (i.e., 0x00 0x01) · P2 = C2 type code (i.e., for indicating UAS C2, or USS C2, or TPAE C2) · L2 = Length of C2 type code (i.e., for indicating UAS C2, or USS C2, or TPAE C2)

[0119] In one embodiment, the algorithm identification information is set as described in TS33.501. In one embodiment, the input key is the 256 - bit K UAS-sess which is. For an algorithm key of length n bits where n is 256 or less, the lower 256 - bit n bits of the KDF output are used as the algorithm key.

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

[0121] [Table 1]

[0122] In one embodiment, the UAS authentication and key establishment procedure described in Figure 2 and the C2 security mode command procedure described in Figure 3 are applicable to EPS / 4G as described in the specified steps given above, with the following differences: Instead of using AMF143, EPS / 4G involves a Mobility Management Entity ("MME"), and instead of UDM149, a Home Subscriber Service ("HSS") / Authentication Center ("AuC") is involved in the description of Figure 2 and the related steps. Furthermore, in Figure 2, in one embodiment, EPS / 4G authentication is performed before UAS authentication (instead of primary authentication). In one embodiment, as described in Figure 3 and the associated steps, the MME and UFES155 are involved as 3GPP network functions. The key derivation and hierarchy illustrated in Figures 4a and 4b are also applicable to EPS / 4G.

[0123] One embodiment of the proposed measures concerns establishing C2 security between UAV106 and parties such as UAV-C108, TPAE, and UTM / USS157 (e.g., regulatory authorities, network operators, etc., involved in UAS). In one embodiment, security can be established for UAV106 with various trusted parties (USS / UTM157, UAV-C108, TPAE, etc.) to enable secure command and control communications for safe and secure UAV flight operations.

[0124] In one embodiment, there are three scenarios in which security needs to be set up between the UAV104 and a trusted party, as listed below. • Security setup between UAV106 and USS / UTM157 (for example, for C2 protection via the UAV9 interface) • Security setup between UAV106 and UAV-C108 (for example, for C2 protection via the UAV3 interface) • Security setup between UAV106 and TPAE (for example, for C2 protection via the UAV4 interface)

[0125] Compared to Embodiment 1 described above, which explained how security is set up between the UAV106 and the UTM / USS157, the embodiments described below describe the security setup between the UAV106, the UAV-C108, and the TPAE.

[0126] In one embodiment, a new network function is introduced. This is a UAS control function ("UCF"), also known as the UAS management function ("UASMF"), which functions in place of UTM / USS157 to perform UAS-based control and management operations in a 3GPGP network. UCF / UASMF is related to and may be equivalent to UFES155 and UAS AF, as defined, for example, in TR23.754. For readability, this disclosure uses the common term UFES155. Therefore, all new features and operations described herein with respect to UFES155 are applicable to the new 3GPP network function UCF.

[0127] Figure 5 shows a signal flow diagram for Procedure 500, which covers the first option for command and control security setup between UAV106 and UAV-C108.

[0128] As shown in Step 1, in one embodiment (see Messaging 502), UAV 106 sends a C2 security association request message to UFES 155 (or any 3GPP NF that manages / controls UAS communications) either directly (e.g., direct communication using bidirectional query / response communication) or indirectly via another 3GPP NF 501, e.g., UFES, UASMF, UASNF, NEF. In one embodiment, the C2 security association request message includes the 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_SessThis includes the ID, UAV security capabilities, e.g., (security algorithm identifier) ​​and Nonce_1. Alternatively, in one embodiment, UAV106 and / or UAV-C108 can transmit step 1 to UFES155 or USS / UTM157. Thus, in such an embodiment, USS / UTM157 is involved instead of UFES155 in the following steps of this procedure.

[0129] In step 2, in one embodiment (see block 504), when the UFES / 3GPP NF501 receives a C2 security association request message, it retrieves the locally stored UAS / C2 security context from the received K UAS ID / K UAS_Sess Use the ID.

[0130] In one embodiment, UFES155 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 the match is successful, UFES155 checks whether "C2 association information" is stored locally for the UAV ID in order to determine whether the corresponding, related, or paired UAV-C108 is available for UAS communication, to know the location of the UAV-C108 (e.g., based on the serving network information of the UAV-C), and to confirm whether the UAV-C108 has already been authenticated (e.g., by contacting the UDM / HSS either directly or via AMF / MME, optionally). Based on the authentication result, if UAV-C108 is already registered on the network and UAS authenticated, UFES155 forwards the C2 security association request to UAV-C108 (for example, directly (if UAV-C108 is in the same PLMN) or indirectly (if UAV-C108 is in a different PLMN)).

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

[0132] In step 4, in one embodiment (see messaging 508), the UFES155 forwards a C2 security association request message to the UAV-C108 and provides the UAS root key and / or the UAS session key to the UAV-C108. The C2 security association request message may include a UAV ID (e.g., CAA UAV ID), UAV-C ID, UAS ID, UAS approval token, UAV security capabilities, K UAS ID / K UAS_Sess ID, and Nonce_1.

[0133] In one embodiment, sending K UAS / K UAS_Sess to the UAV-C108 can be skipped if the UAV-C108 can derive the same UAS root key as the UAV106 after successfully authenticating the UAS with the USS / UTM157. Otherwise, K UAS / K UAS_Sess may need to be provided to the UAV-C108 by the UFES155 during the pairing / association of the UAV106 and the UAV-C108 to make the same UAS root key available at the UAV-C108.

[0134] In an alternative embodiment, step 4 can be sent from the UAV-C108 to the UFES155 or the USS / UTM157 to pair or associate the UAV-C108 with the UAV106. In this case, step 5 may be performed, and then step 4 is sent by the UAV-C108 to the UFES155 or the USS / UTM157.

[0135] In one embodiment, in step 5 (see block 510), UAV-C108 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 successful, UAV-C108, like UAV106, K UAS (For example, from what is available in local memory derived after UAS authentication, or what is received from UFES155) UAS-Sess To derive the key, we generate Nonce_2. ·K UAS_Sess =KDF(K UAS (UAS ID, CAA level UAV ID, Nonce_1, Nonce_2) ·K UAS_Sess ID:Hash(K UAS_Sess ) ·CCEK=KDF(K UAS_Sess (UAS ID, encryption algorithm ID, C2 type ID) ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0136] Alternatively, in one embodiment, the UAV-C108 is transmitted from the UFES155 to K UAS K instead of the key UAS_Sess When the key is received, the UAV-C108 will send the key. UAS_Sess By deriving the CCEK key and CCIK key from the key, the received K for C2 encryption and integrity protection UAS_Sess Use the key.

[0137] In a further embodiment, when UAV-C108 receives UAV security capabilities, UAV-C108 selects an encryption algorithm and an integrity algorithm based on its inherent capabilities and UAV security capabilities.

[0138] In one embodiment, in step 6 (see messaging 512), the UAV-C108 sends a success indicator, UAS ID, K UAS_Sess A C2 security association response message is sent to UFES155, including the ID, the selected encryption and integrity algorithm ID, Nonce_2, and the address (e.g., MAC). The C2 security association response message may be integrity-protected using the selected security algorithm and the newly derived CCIK. In one alternative embodiment, the C2 security association response message may be sent to UAV-C108 by UFES155 or USS / UTM157 if the C2 association request is received from UAV-C108 in step 4.

[0139] In one embodiment, in step 7 (see messaging 514), UFES155 forwards the C2 security association response message to UAV106. In step 8a, in one embodiment, UAV106 receives the locally stored K UAS From the key to K UAS-Sess The received Nonce_2 is used to derive the key. Furthermore, in one embodiment, UAV106, K UAS-Sess The ID is derived, and the received K UAS-Sess A newly derived K using the ID UAS-Sess The ID is verified. If they match, UAV106 considers the security setup successful and the newly derived K UAS-Sess The CCEK and CCIK are derived from the key. Furthermore, in one embodiment, UAV106 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 a successful set of C2 security between UAV106 and UAV-C108. The key derivation is as follows: ·K UAS_Sess =KDF(K UAS (UAS ID, CAA level UAV ID, Nonce_1, Nonce_2) ·K UAS_SessID:Hash(K UAS_Sess ) ·CCEK=KDF(K UAS_Sess (UAS ID, encryption algorithm ID, C2 type ID) ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0140] As step 8b, in one embodiment (see messaging 518), UAV106 and UAV-C108 exchange C2 application data protected using CCEK and CCIK.

[0141] Figure 6 shows a signal flow diagram for Procedure 600, which covers a second option for command and control security setup between UAV106 and UAV-C108.

[0142] In steps 1a to 1b, in one embodiment (see messaging 602 and 604), UAV-C108 is registered with PLMN and successfully performs UAS authentication with USS / UTM157. In steps 2a to 2b, in one embodiment (see messaging 606 and 608), UAV106 is registered with PLMN and successfully performs UAS authentication with USS / UTM157. In one embodiment, UAV106 has a UAS root key (K UAS ), UAS ID, K UAS The ID and authorization token are stored as part of the UAS security context.

[0143] In step 2c, in one embodiment (see messaging 610), the UAV106 and UFES155 (e.g., UFES, UASMF, UASNF, NEF) or USS / UTM157 have successfully performed the security setup, and (as described and shown with reference to Figure 3) K UAS-Sess A key is used to establish C2 security between the UAV106 and the UFES155 or USS / UTM157.

[0144] In step 3a, in one embodiment (see messaging 612), the 3GPP network function (AMF143 / UFES155 for 5G networks, or MME / UFES for 4G networks) determines to associate a C2 connection and C2 security setup between UAV106 and UAV-C108. In such an embodiment, 3GPP NF601 sends a C2 / UAS association request message to UAV-C108 on behalf of UAV106. The UAS association request message includes the UAV ID, UAV security capability, authorization token, UAS ID, and K UAS It may include an ID.

[0145] In step 3b, in one embodiment (see messaging 614), UAV-C108 sends a C2 security context setup request message to USS / UTM155. The C2 security context setup request message contains the received UAV ID, authorization token, UAS ID, and K UAS It may include an ID.

[0146] In step 3c, in one embodiment (see block 616), the USS / UTM155 uses locally stored UAS security information, identified using the UAS ID, to receive the UAV ID, authorization token, UAS ID, and K UAS The IDs are verified, and if they match, the USS / UTM155 provides the UAS root key / UAS session key to the UAV-C108.

[0147] In step 3d, in one embodiment (see messaging 618), the USS / UTM155, in the C2 security context setup response message, includes the UAS ID, K UAS ID, nons, K UAS Key / K UAS_Sess The key is sent to the UAV-C108. In step 3e, in one embodiment (see block 620), the UAV-C108 receives the K UAS ID, nons, KUAS Key / K UAS_Sess The key is the UAS context information received from UFES155 (e.g., UAV ID, UAV security capability, authorization token, UAS ID, K UAS It is stored locally in memory along with the ID. When the UAV-C108 receives the UAS root key, in one embodiment the UAV-C108 derives the UAS session key and C2 security key (CCEK, CCIK) as follows: ·K UAS_Sess =KDF(K UAS (UAS ID, CAA level UAV ID, noncode) ·K UAS_Sess ID:Hash(K UAS_Sess ) ·CCEK=KDF(K UAS_Sess (UAS ID, encryption algorithm ID, C2 type ID) ·CCIK=KDF(K UAS_Sess (UAS ID, Integrity Algorithm ID, C2 Type ID)

[0148] In one embodiment, the UAV-C108 selects an encryption algorithm and an integrity protection algorithm based on its inherent security capabilities and the UAV's security capabilities. In one embodiment, if the UAV-C108 receives only the UAS session key, the UAV-C108 derives the CCEK and CCIK from the received UAS session key as shown above.

[0149] In step 3f, in one embodiment (see messaging 622), UAV-C108 sends a C2 / UAS association response message to UFES155 along with a success indicator. In one embodiment, in step 3g (see messaging 624), UAV-C108 also sends a C2 association notification to UAV106, and the C2 association notification message is K UAS ID, UAV-C ID, selected security algorithm ID, K UAS_SessThis includes the ID and MAC address. The C2 association notification can be protected for integrity using the newly derived session key.

[0150] In step 3h, in one embodiment, UAV106 and UAV-C108 successfully establish C2 security via the UAV3 interface, and all C2 application data is protected using the newly derived CCEK and CCIK.

[0151] Figure 7 shows the signal flow diagram for Procedure 700, which pertains to the command and control security setup between UAV106 and TPAE701.

[0152] In one embodiment, as an option, TPAE701 can establish a C2 security setup with UAV106 using the procedure shown in Figure 6 by performing steps 3b through 3e to initiate a secure connection via the UAV4 interface, with TPAE replacing UAV-C operation.

[0153] This embodiment describes how TPAE701 establishes a C2 security setup with UAV106 to protect the exchange of C2 applications in UAV control. The security setup procedure between UAV106 and TPAE701 is shown in Figure 7.

[0154] In steps 1-3 (see messaging 702-706), in one embodiment, UAV106 has successfully registered with the 3GPP network and has successfully authenticated with USS / UTM157. In such an embodiment, UAV106 has begun updating remote identification and tracking information to USS / UTM157, which is stored in UDM149 / HSS via UFES155 (e.g., UFES / UASNF / NEF).

[0155] In step 4, in one embodiment (see messaging 708), if TPAE 701 decides to exchange command and control with any UAV 106, it will exchange a C2 security context (e.g., UAV security capability / selected security algorithm ID (encryption and integrity protection algorithms), UAS ID, K UAS_Sess It is decided to retrieve / CCEK and CCIK from UFES155 and / or USS / UTM157.

[0156] In such embodiments, TPAE701 sends a UAV query to UFES155 (for example, either directly or via USS / UTM157) and / or USS / UTM157. The UAV query may include a UAV ID, a UAS ID, and a C2 security information request indication.

[0157] In step 5, in one embodiment (see block 710), the UFES155 and / or UTM / USS157 retrieve C2 security information from its local memory based on the UAV ID. Depending on the operator's implementation, in one embodiment, the UFES155 and / or USS / UTM157 may decide to use a common UAS session key or to derive a TPAE C2-specific UAS session key (as shown in Figure 4a with respect to the UAS key hierarchy). In one embodiment, the UAV C2 security information includes UAV security capabilities such as encryption and integrity algorithms, and a session key for protecting C2 data messages.

[0158] In step 6, in one embodiment (see messaging 712), UFES155 (e.g., either directly or via USS / UTM157) and / or USS / UTM157 send a UAV response to TPAE701, and 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 algorithms), UAS ID, K UAS_Sess Includes / CCEK and CCIK.

[0159] In step 7, in one embodiment (see block 714), if TPAE701 receives the selected security algorithm and C2 security keys (CCEK and CCIK), it locally stores the received C2 security information along with the UAV ID. Alternatively, in one embodiment, TPAE701 stores K UAS_Sess When a key is received, TPAE701 derives CCEK and CCIK as follows: ·CCEK=KDF(K UAS_Sess (UAS ID / UAV ID, encryption algorithm ID, C2 type ID = "TPAE C2 value") ·CCIK=KDF(K UAS_Sess , UAS ID / UAV ID, Integrity Algorithm ID, C2 Type ID = "TPAE C2 value")

[0160] In one embodiment, when TPAE701 receives UAV security capabilities, TPAE701 selects encryption and integrity algorithms for C2 protection based on its own security capabilities and the received UAV security capabilities.

[0161] In step 8a, in one embodiment (see messaging 716), TPAE 701 notifies UAV 106 by sending an integrity-protected C2 security setup notification message along with the selected algorithm, TPAE C2 start indicator, and MAC. In step 8b, in one embodiment (see messaging 718), TPAE 701 uses the received C2 security key and the selected security algorithm to protect the C2 application data to be sent to UAV 106.

[0162] Another embodiment of the measures disclosed herein concerns authentication and key management of UAV106 and UAV-C108 based on the Service Enabler Architecture Layer ("SEAL") for secure UAS C2 operation. Figure 8a shows SEAL-based Vertical Application Layer ("VAL") user authentication for UAV106 and UAV-C108 in UAS101.

[0163] In step 1, in one embodiment (see messaging 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 may be involved in the SEAL-based UAS authentication procedure.

[0164] In one embodiment, in step 2 (see messaging 804), VAL UE801 (e.g., UAV106 / UAV-C108) sends an OpenID connection authentication request to SIM-S803 (e.g., USS / UTM157). The request may include an indication of the authentication method supported by the UE (e.g., UAV106 / UAV-C108).

[0165] In one embodiment, in step 3 (see messaging 806), user authentication is performed between VAL UE801 (e.g., UAV106 / UAV-C108) and SIM-S803 (e.g., USS / UTM157). In such an embodiment, the primary credentials 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 and authentication and authorization methods it supports.

[0166] In one embodiment, in step 4 (see messaging 808), SIM-S803 (e.g., USS / UTM157) sends an OpenID connection authentication response containing an authorization code to the UE (e.g., UAV106 / UAV-C108). The authorization code may be derived using the UAS ID and UAV CAA level ID assigned by USS / UTM157. In step 5, in one embodiment (see messaging 810), VAL UE801 sends an OpenID connection token request to SIM-S803, passing the authorization code.

[0167] In one embodiment, in step 6 (see messaging 814), SIM-S803 (e.g., USS / UTM157) sends an OpenID connection token response to VAL UE801 (e.g., UAV106 / UAV-C108) which includes an ID token and an access token (each uniquely identifying a 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, respectively (see block 812).

[0168] In one embodiment, an ID token is consumed by the UAV106 / UAV-C108 to personalize the VAL client for the VAL user, and an access token is used by the UAV106 / UAV-C108 to communicate and authorize the VAL user's identification information to the VAL server and VAL service.

[0169] Figure 8b illustrates a SEAL-based key management procedure for establishing UAS security key / UAS session security. In one embodiment, a SEAL key management client 821 ("SKM-C") and a SEAL key management server 823 ("SKM-S") are involved in the SEAL-based key management procedure.

[0170] In step 1, in one embodiment (see block 822), the SKM-C821 (e.g., UAV106 / UAV-C108) establishes a direct HTTPS connection to the SKM-S823 (e.g., USS / UTM157). In some embodiments, steps 2 and 3 are within this secure connection.

[0171] In step 2, in one embodiment (see messaging 824), SKM-C821 sends a SEAL KM request message to SKM-S823 that includes a UAV ID, a UAV-C ID, and a UAS access token.

[0172] In step 3, in one embodiment (see messaging 826), SKM-S823 approves the request and, if valid, the UAS ID-specific K UAS / K UAS_Sess Key, K UAS ID / K UAS_Sess Send a SEAL KM response message containing the requested key material (or error code) with the ID and UAS ID.

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

[0174] Another embodiment of the measures disclosed herein relates to UAS authentication and key management based on Authentication and Key Management for Applications ("AKMA").

[0175] This embodiment describes how a UAS root key may be derived from an AKMA key in a 3GPP network and provided to the UFES155 to enable C2 communication security. The remaining uses of the UAS root key, such as the derivation and use of the UAS session key and C2 security key, may be the same as those described in Embodiments 1, 2, and 3.

[0176] In one embodiment, Figure 9 shows the UAS root key (K UAS ) is available in AUSF of the 3GPP network after a successful UAS authentication and authorization procedure. AKMA This shows how it can be derived from the key.

[0177] K AKMA From K UAS When deriving this, the following parameters are used to form the input S to the KDF. FC=XXX P0 = AF_ID / UFES ID L0 = AF_ID / UFES ID length P1 = UAS ID L1 = Length of UAS ID

[0178] In one embodiment, the input key is K AKMA Let it be so.

[0179] In one embodiment, Figure 10 shows a procedure 1000 used by the UFES / UASMF155 to directly request a C2 application function-specific AKMA key from the 5GC when the UFES / UASMF155 is located within the operator's network. In one embodiment, the UE801 and UFES155 need to know whether they will use AKMA before communication between the UE801 (e.g., UAV106 / UAV-C108) and the UFES155 (instead of the USS / UTM157 and TPAE701) can be initiated. This knowledge may be implicit to the C2 application on the UE801 and UFES155 (instead of the USS / UTM157 and TPAE701).

[0180] As a prerequisite (see messaging 1002 and 1004), in one embodiment, UE801 performs primary authentication and establishes the AKMA anchor key K_AKMA with AAnF803. In a further embodiment, UE801 performs UAS authentication and authorization with USS / UTM157.

[0181] In one embodiment, in step 1 (see messaging 1006 and 1008), when UE801 (e.g., UAV106 / UAV-C108) initiates communication with UFES155, it uses the A-KID (K by AUSF and UE) derived in the application session establishment request message. AUSF It shall include the AKMA key identifier derived from [the specified source].

[0182] In step 2, in one embodiment (see messaging 1010), if UFES155 does not have an active 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 an AKMA application key for UE801. UFES155 also includes its own identification information (UFES ID) and UAS ID in the request, which should be linked in the derivation of the UAS root key. In one embodiment, the AAnF 803 authorizes UFES155. In some embodiments, the AAnF 803 checks whether it can provide services to UFES155 based on local policies configured by the AAnF 803, or based on authorization information or policies provided by the NEF / NRF using UFES155. If successful, in one embodiment, the following steps are performed. Otherwise, the AAnF 803 rejects the steps.

[0183] In one embodiment, AAnF803 verifies whether the subscriber is authorized to use AKMA due to the presence of the AKMA anchor key K_AKMA received from AUSF. In some embodiments, AAnF803 verifies the UAS application key (K UAS If you have ), it is K UAS It responds to UFES155 using. If it does not have it, AAnF803 will use the UE-specific K that it identifies by A-KID. AKMA It is possible to check whether a key is present. In a further embodiment, K AKMA If available in AAnF803, AAnF803 proceeds to step 3. In various embodiments, K AKMA If it is not available, the AAnF803 proceeds to step 4 and sends an error response.

[0184] In one embodiment, in step 3 (see block 1012), AAnF803 is K AKMA From UAS application key (K UAS ) is derived. In one embodiment, K UASThe key derivation is performed using the key derivation function ("KDF") specified in TS33.220. UAS is K UAS =KDF(K AKMA The UFES ID is calculated as UFES ID, UAS ID, and the UFES ID is constructed as UFES ID = FQDN of UFES || Ua* / C2 security protocol identifier. The Ua* / C2 security protocol identifier may be specified as the Ua security protocol identifier in Appendix H of TS33.220. UAS The key used for the derivation is K AKMA That is the case.

[0185] In step 4, in one embodiment (see messaging 1014), AAnF803, K UAS And a Naanf_AKMA_UASKey response is sent to UFES155 at the end of its lifespan. In step 5, in one embodiment (see block 1016), UFES155 derives the CCEK and CCIK either directly from the UAS root key or from the UAS session key (for example, the UAS session key is derived from the UAS root key). The derivation of the UAS session key and the C2 security keys (CCEK and CCIK) can be done based on the embodiments described above.

[0186] In step 6, in one embodiment (see messaging 1018), UFES155 responds to the application session establishment request to UE801 using a UAS session key ID corresponding to a UAS session key derived from the UAS root key. C2 security can be set up using an AKMA-based UAS key.

[0187] Figure 11 shows a user device 1100 that may be used for UAS authentication and security establishment according to embodiments of the present disclosure. In various embodiments, the user device 1100 is used to implement one or more of the measures described above. The user device 1100 may be one embodiment of the remote unit 105, UE205, UAV106, and / or UAV-C108 described above. Furthermore, the user device 1100 may include a processor 1105, memory 1110, input device 1115, output device 1120, and transceiver 1125.

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

[0189] As illustrated, the transceiver 1125 includes at least one transmitter 1130 and at least one receiver 1135. In some embodiments, the transceiver 1125 communicates with one or more cells (or wireless coverage areas) supported by one or more base units 121. In various embodiments, the transceiver 1125 is capable of operating on the unlicensed spectrum. Furthermore, the transceiver 1125 may include multiple UE panels supporting one or more beams. In addition, the transceiver 1125 may support at least one network interface 1140 and / or application interface 1145. The application interface 1145 may support one or more APIs. The 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.

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

[0191] In various embodiments, the processor 1105 and transceiver 1125 control the user equipment device 1100 to implement the behavior of the UE described above. For example, the UE may include a UAV 106 and / or UAV-C108, which includes a transceiver 1125 that transmits a command and control ("C2") pairing request from a first user equipment ("UE") device to the network function of a mobile wireless communication network for establishing secure communication between the first UE device and the second UE device, the C2 pairing request comprising at least one of the identifier of the first UE device, the identifier of the second UE device, the identifier of the unmanned aerial vehicle system ("UAS") comprising the first UE device and the second UE device, 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.

[0192] In one embodiment, the transceiver 1125 receives a C2 pairing response from the network function, which 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 the address of a second UE device.

[0193] In one embodiment, the processor 1105 derives a second UAS session key using a locally stored UAS root key, derives a second UAS session key identifier using the second UAS session key, 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 to secure communication between the first UE device and the second UE device based on the UAS session key, and establishes secure communication with the second UE device using at least one security key.

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

[0195] In one embodiment, upon receiving an authentication response message with a success indication, the 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, UAS identifier, and long-term credentials for the UAV identifier. In one embodiment, the processor 1105 uses the UAS security context to establish a secure connection with the USS / UTM.

[0196] In one embodiment, memory 1110 is a computer-readable storage medium. In some embodiments, memory 1110 includes a volatile computer storage medium. 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 a non-volatile computer storage medium. 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 mediums.

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

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

[0199] In one embodiment, the output device 1120 is designed to output visual, audible, 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 the 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 the user. Another, but not limited, example of the output device 1120 may include a wearable display, such as a smartwatch, smart glasses, or a head-up display, that is separate from the rest of the user equipment device 1100 but communicatively coupled to it. Furthermore, the output device 1120 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, or vehicle dashboard.

[0200] In some embodiments, the output device 1120 includes one or more speakers for producing sound. For example, the output device 1120 may produce an audible warning or notification (e.g., a beep or chime). In some embodiments, the output device 1120 includes one or more haptic devices for producing vibration, movement, or other tactile feedback. In some embodiments, all or part of the output device 1120 may be integrated with the input device 1115. For example, the input device 1115 and the output device 1120 may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device 1120 may be located near the input device 1115.

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

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

[0203] In some embodiments, a first transmitter / receiver pair used to communicate with a mobile communications network over the licensed radio spectrum and a second transmitter / receiver pair used to communicate with the mobile communications network over the unlicensed radio spectrum may be synthesized into a single transceiver unit, for example, a single chip that performs functions for use with both the licensed and unlicensed radio spectrums. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, several transceivers 1125, transmitters 1130, and receivers 1135 may be implemented as physically separate components that access shared hardware and / or software resources, such as a network interface 1140.

[0204] 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, system-on-chip, ASIC, or other type of hardware component. 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 / circuits, may be integrated with any number of transmitters 1130 and / or receivers 1135 into a single chip. In such embodiments, the transmitters 1130 and receivers 1135 may be logically configured as transceivers 1125 using one or more common control signals, or as modular transmitters 1130 and receivers 1135 implemented on the same hardware chip or multi-chip module.

[0205] FIG. 12 shows a network device 1200 that can be used for UAS authentication and security establishment according to an embodiment of the present disclosure. In one embodiment, the network device 1200 can be an implementation form of a RAN node, such as the base unit 121, RAN node 210, or gNB described above. Further, the base network device 1200 can include a processor 1205, a memory 1210, an input device 1215, an output device 1220, and a transceiver 1225.

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

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

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

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

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

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

[0212] In one embodiment, the processor 1205 verifies at least one parameter in the network function based on an unmanned aerial system ("UAS") security context stored locally in the network function, and the UAS comprises a first UE device and a second UE device. In one embodiment, the transceiver 1225, in response to the successful verification of at least one parameter, sends a C2 pairing request from the network function to the UAS service supplier ("USS") / UAS traffic management ("UTM"), the network function receives a C2 pairing response from the USS / UTM, and sends the C2 pairing response from the network function to the first UE device to establish secure communication.

[0213] 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 in the first network function, and in response to the successful matching, determines the C2 pairing information stored locally in the network function to determine whether the UAV and / or UAV-C is available for UAS communication, the location of the UAV and / or UAV-C, and whether the UAV and / or UAV-C is authenticated.

[0214] In one embodiment, memory 1210 is a computer-readable storage medium. In some embodiments, memory 1210 includes a volatile computer storage medium. 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 a non-volatile computer storage medium. 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 mediums.

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

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

[0217] In one embodiment, the output device 1220 is designed to output visual, audible, 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, LED display, OLED display, projector, or similar display device capable of outputting images, text, etc., to a user. Another, but not limited, example, the output device 1220 may include a wearable display, such as a smartwatch, smart glasses, or head-up display, that is separate from the rest of the network device 1200 but communicatively coupled to it. Furthermore, the output device 1220 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, or vehicle dashboard.

[0218] In some embodiments, the output device 1220 includes one or more speakers for producing sound. For example, the output device 1220 may produce an audible warning or notification (e.g., a beep or chime). In some embodiments, the output device 1220 includes one or more haptic devices for producing vibration, movement, or other tactile 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.

[0219] The transceiver 1225 includes at least a transmitter 1230 and at least one receiver 1235. One or more transmitters 1230 may be used to communicate with a UE as described herein. Similarly, one or more receivers 1235 may 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 shown, the network device 1200 may have any suitable number of transmitters 1230 and receivers 1235. Furthermore, the transmitters 1230 and receivers 1235 may be any suitable type of transmitter and receiver.

[0220] Figure 13 is a flowchart of Method 1300 for UAS authentication and security establishment. Method 1300 may be performed by network functions such as UFES 155, 3GPP network functions, and / or network equipment devices 1200. In some embodiments, Method 1300 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0221] In one embodiment, Method 1300 includes the step (1305) of sending an authentication request message from a user device ("UE") to a UAS service supplier ("USS") / UAS traffic management ("UTM") from a first network function of a mobile wireless communication network, wherein the UE comprises at least one of an unmanned aerial vehicle ("UAV") and a UAV controller ("UAV-C"). In a further embodiment, Method 1300 includes the step (1310) of receiving an authentication response message from the USS / UTM in the first network function, comprising a UAS identifier and a UAS security context, wherein the UAS security context comprises a UAS root key and a UAS root key identifier. Method 1300 then terminates.

[0222] Figure 14 is a flowchart of Method 1400 for UAS authentication and security establishment. Method 1400 may be performed by network functions such as UFES 155, UCF, 3GPP network functions, and / or network equipment devices 1200. In some embodiments, Method 1400 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

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

[0224] In one embodiment, Method 1400 includes the step (1410) of a network function verifying at least one parameter based on an unmanned aerial system ("UAS") security context stored locally in the network function, wherein the UAS comprises a first UE device and a second UE device. In one embodiment, Method 1400 includes the step (1415) of sending a C2 pairing request from the network function to a UAS service supplier ("USS") / UAS traffic management ("UTM") in response to the successful verification of at least one parameter.

[0225] In one embodiment, method 1400 includes the step (1420) of receiving a C2 pairing response from the USS / UTM in the network function. In one embodiment, method 1400 includes the step (1425) of transmitting the C2 pairing response from the network function to the first UE device to establish secure communication. Method 1400 then terminates.

[0226] Figure 15 is a flowchart of Method 1500 for UAS authentication and security establishment. Method 1500 can be performed 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 performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

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

[0228] In one embodiment, method 1500 includes a step (1520) of receiving, from a network function, a C2 pairing response comprising 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 of a second UE device.

[0229] In one embodiment, method 1500 includes a step (1515) of 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. In one embodiment, method 1500 includes a step (1520) of verifying that the second UAS session key identifier matches the UAS session key identifier received in the C2 pairing response.

[0230] In one embodiment, method 1500 includes a step (1525) of deriving at least one security key for securing communication between a first UE device and a second UE device based on the UAS session key. In one embodiment, method 1500 includes a step (1530) of establishing secure communication with the second UE device using the at least one security key. Method 1500 ends.

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

[0232] In one embodiment, the first device includes a transceiver that transmits an authentication request message from a user device ("UE") to a UAS service supplier ("USS") / UAS traffic management ("UTM") from a first network function of a mobile wireless communication network, the UE comprising at least one of an unmanned aerial vehicle ("UAV") and a UAV controller ("UAV-C"). In some embodiments, the transceiver receives an authentication response message from the USS / UTM in the first network function, comprising a UAS identifier and a UAS security context, the UAS security context comprising a UAS root key and a UAS root key identifier.

[0233] In one embodiment, the authentication response message further comprises at least one of the following: an authentication success indicator, a UAV identifier, command and control ("C2") support information, and an authorization token. In one embodiment, the first device includes a processor that, in a first network function, locally stores the authentication success indicator, the received UAV identifier, the UAS identifier, the C2 support information, the authorization token, and the UAS security context.

[0234] In one embodiment, the C2 support 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 the first network function to the Access and Mobility Management Function ("AMF") of the mobile wireless communication network.

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

[0236] A first method for UAS authentication and security establishment is disclosed. The first method may be performed by a network function, such as UFES155, 3GPP network function, and / or network equipment device 1200. In some embodiments, the first method may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0237] In one embodiment, the first method includes sending an authentication request message from a user device ("UE") to a UAS service supplier ("USS") / UAS traffic management ("UTM") from a first network function of a mobile wireless communication network, wherein the UE comprises at least one of an unmanned aerial vehicle ("UAV") and a UAV controller ("UAV-C"). In some embodiments, the first method includes receiving an authentication response message from the USS / UTM to the first network function, wherein the UAS security context comprises a UAS root key and a UAS root key identifier.

[0238] In one embodiment, the authentication response message further comprises at least one of the following: an authentication success indicator, a UAV identifier, command and control ("C2") support information, and an authorization token. In one embodiment, the first method includes the step of locally storing the authentication success indicator, the received UAV identifier, the UAS identifier, the C2 support information, the authorization token, and the UAS security context in a first network function.

[0239] In one embodiment, the C2 support information comprises 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 the step of sending an received authentication response message from a first network function to the Access and Mobility Management Function ("AMF") of a mobile wireless communication network.

[0240] In one embodiment, the first method includes the steps of receiving an authentication request message from an Access and Mobility Management Function ("AMF") of a mobile wireless communication network, wherein the authentication request message comprises a UAV identifier; storing the UAV identifier locally in the first network function; and transmitting the authentication request message to the USS / UTM in response to the receipt of the authentication request message.

[0241] A second device for UAS authentication and security establishment is disclosed. The second device may include network functions such as UFES155, UCF, 3GPP network functions, and / or network equipment 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.

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

[0243] In one embodiment, the second device includes a processor in the network function that verifies at least one parameter based on an unmanned aerial system ("UAS") security context stored locally in the network function, and the UAS comprises a first UE device and a second UE device. In one embodiment, the transceiver, in response to the successful verification of at least one parameter, sends a C2 pairing request from the network function to a UAS service supplier ("USS") / UAS traffic management ("UTM"), the network function receives a C2 pairing response from the USS / UTM, and sends the C2 pairing response from the network function to the first UE device to establish secure communication.

[0244] In one embodiment, the first UE device comprises an unmanned aerial vehicle ("UAV"), the second UE device comprises a UAV controller ("UAV-C"), the first UE device comprises the UAV-C, and the second UE device comprises the UAV. In one embodiment, the C2 pairing request comprises at least one of the following: a UAV identifier, a UAV-C identifier, a UAS identifier, security capability information for the UAV, a UAS authorization token, a nonce, a UAS security information identifier, a UAS root key, and a UAS session key identifier.

[0245] 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 in the first network function, and in response to the successful matching, determines the C2 pairing information stored locally in the network function to determine whether the UAV and / or UAV-C is available for UAS communication, the location of the UAV and / or UAV-C, and whether the UAV and / or UAV-C is authenticated.

[0246] In one embodiment, the C2 pairing response comprises at least one of the following: a success indicator, a UAS session key, a UAS session key identifier, UAS security information, a selected security algorithm, and the address of the UAV-C.

[0247] A second method for UAS authentication and security establishment is disclosed. The second method may be performed by a network function such as UFES155, UCF, UASNF, 3GPP network function, and / or network equipment device 1200. In some embodiments, the second method may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

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

[0249] In one embodiment, the second method includes the step of a network function verifying at least one parameter based on an unmanned aerial system ("UAS") security context stored locally in the network function, wherein the UAS comprises a first UE device and a second UE device. In one embodiment, the second method includes the steps of sending a C2 pairing request from the network function to a UAS service supplier ("USS") / UAS traffic management ("UTM") in response to the successful verification of at least one parameter, receiving a C2 pairing response from the USS / UTM in the network function, and sending the C2 pairing response from the network function to the first UE device to establish secure communication.

[0250] In one embodiment, the first UE device comprises an unmanned aerial vehicle ("UAV"), the second UE device comprises a UAV controller ("UAV-C"), the first UE device comprises the UAV-C, and the second UE device comprises the UAV. In one embodiment, the C2 pairing request comprises at least one of the following: 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.

[0251] In one embodiment, the second method includes the steps of 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 in the first network function, and in response to the successful matching, determining the C2 pairing information stored locally in the network function to determine whether the UAV and / or UAV-C is available for UAS communication, the location of the UAV and / or UAV-C, and whether the UAV and / or UAV-C is authenticated.

[0252] In one embodiment, the C2 pairing response comprises at least one of the following: a success indicator, a UAS session key, a UAS session key identifier, UAS security information, a selected security algorithm, and the address of the UAV-C.

[0253] A third device for UAS authentication and security establishment is disclosed. The third device may include UEs such as UAV106, UAV-C108, remote unit 105, and / or user equipment device 1100. 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.

[0254] In one embodiment, the third device includes a transceiver that transmits a command and control ("C2") pairing request from a first user equipment ("UE") device to the network function of a mobile wireless communication network for establishing secure communication between the first UE device and the second UE device, the C2 pairing request comprising at least one of the following: an identifier for the first UE device, an identifier for the second UE device, an identifier for an unmanned aerial vehicle system ("UAS") comprising the first UE device and the second UE device, 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.

[0255] In one embodiment, the transceiver receives a C2 pairing response from the network function, which 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 the address of a second UE device.

[0256] In one embodiment, the third device includes a processor which derives a second UAS session key using a locally stored UAS root key, 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 to secure communication between the first UE device and the second UE device based on the UAS session key, and establishes secure communication with the second UE device using at least one security key.

[0257] 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 comprising at least one or more of the following: a success indicator, a UAV identifier, a UAS identifier, a UAV-C identifier, an authorization token, and a UAS security context.

[0258] In one embodiment, upon 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 long-term credentials for the UAV, 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.

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

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

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

[0262] In one embodiment, the third method includes the steps of: deriving a second UAS session key using a locally stored UAS root key; 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 for securing communication between the first UE device and the second UE device based on the UAS session key; and establishing secure communication with the second UE device using the at least one security key.

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

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

[0265] Embodiments may be practiced in other specific forms. The embodiments described should be considered in all respects as illustrative and not restrictive. Accordingly, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All modifications within the intent and equivalence of the claims shall be incorporated within that scope. [Explanation of Symbols]

[0266] 101 UAS 102 UAS Operator 105 Remote Unit 106 UAV 108 UAV-C 107 Apps 115 RAN 120 3GPP Access Networks 121 Cellular Base Unit 123 3GPP communication link 130 Non-3GPP Access Networks 131 Access Point 133 Non-3GPP communication links 135 Collaborative Entities 140 Mobile Networks 141 UPF 143 AMF 145 SMF 147 PCF 148 AUSF 149 UDM / UDR 150 Data Networks 155 UFES / UAS NF / NEF 157 USS / UTM 160 Data Networks 301 3GPP NF 501 3GPP NF 601 3GPP Network 603 TPAE 701 TPAE 801 VALUE 803 SIM-S 821 SKM Client 823 SKM Server 1100 User equipment 1105 Processor 1110 memory 1115 Input Devices 1120 Output Device 1125 Transceiver 1130 Transmitter 1135 Receiver 1140 Network Interface 1145 Application Interface 1200 Network Devices 1205 Processor 1210 memory 1215 Input Devices 1220 Output Device 1225 Transceiver 1230 Transmitter 1235 Receiver 1240 Network Interfaces 1245 Application Interface

Claims

1. At least one memory, An apparatus comprising at least one processor coupled to at least one memory, wherein the at least one processor is provided to the apparatus, From the first network function of the mobile wireless communication network, a user device ("UE") sends an authentication request message to the UAS service supplier ("USS") / UAS traffic management ("UTM") indicating that authentication is being requested from the UE, and the UE comprises at least one of an unmanned aerial vehicle ("UAV") and a UAV controller ("UAV-C"), and transmits the message. In the first network function described above, an authentication response message comprising a UAS identifier, a CAA level UAV ID, and a UAS security context is received from the USS / UTM. A device configured to perform the following action.

2. The apparatus according to claim 1, wherein the authentication response message further comprises at least one of the following: an authentication success indicator, an identifier for the UAV, command and control ("C2") support information, and an authorization token.

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

4. The apparatus according to claim 2, wherein the C2 support information comprises at least one of the UAV-C identifier, the UAV3 type indicator, and the UAV-C serving network identifier.

5. The apparatus according to claim 2, wherein the at least one processor is configured to cause the apparatus to transmit the received authentication response message from the first network function to the access and mobility management function ("AMF") of the mobile wireless communication network.

6. The at least one processor in the device Receiving the authentication request message from the access and mobility management function ("AMF") of the mobile wireless communication network, wherein the authentication request message includes the identifier of the UAV, The first network function includes locally storing the identifier of the UAV, In response to receiving the aforementioned authentication request message, the authentication request message is sent to the USS / UTM. The apparatus according to claim 1, configured to perform the following.

Images