Revocation of UAS related authorization and security information

Abstract

An apparatus, method, and system for handling security aspects for a UAS in a 3GPP network are disclosed. An apparatus (1100) includes a transceiver (1125) that receives (1305) a revocation indication message from a mobile communication network and a processor (1105) that deletes (1310) UAS-related authorization and security information corresponding to a UAV ID. The transceiver (1125) further transmits (1315) a revocation acknowledgement message to the mobile communication network.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 135,511, filed January 8, 2021 on behalf of Sheeba Backia Mary Baskaran, Andreas Kunz, and Dimitrios Karampatsis, entitled "UAV / UAV-C AUTHORIZATION AND PAIRING RELATED SECURITY ASPECTS HANDLING FOR UAS," which is incorporated herein by reference.

[0002] The subject matter disclosed herein relates generally to wireless communications, and more specifically, to handling security aspects related to UAV / UAV-C authorization and pairing for UAS, for example, in networks compliant with 3rd Generation Partnership Project ("3GPP®") standards. [Background technology]

[0003] In some embodiments, a wireless network conforming to the 3GPP family of cellular communications standards supports connectivity between an unmanned aerial vehicle controller ("UAV-C") and an unmanned aerial vehicle ("UAV"). Such a network may also support various unmanned aerial vehicle system ("UAS") services. For example, a UAS service supplier ("USS") and / or a UAS traffic management system ("UTM") may provide authentication and authorization services for the UAV and / or UAV-C. UAV USS authentication and authorization ("UUAA") is a procedure that ensures that a UAV (or UAV-C) can be authenticated and authorized by the USS before connectivity for UAS services is enabled. Summary of the Invention [Problem to be solved by the invention]

[0004] Disclosed are procedures for handling security aspects related to authentication, authorization, and pairing of UAV / UAV-C for UAS, for example, in a 3GPP network, which may be implemented by an apparatus, a system, a method, or a computer program product. [Means for solving the problem]

[0005] One method for a user equipment ("UE") to handle security aspects for a UAS in a 3GPP network includes receiving a revocation indication message from a mobile communications network and deleting authorization and security information related to a UAS corresponding to a UAV identifier ("ID"). The first method includes sending a revocation acknowledgement message to the mobile communications network.

[0006] One method for a network entity (e.g., an Access and Mobility Management Function ("AMF") and / or a Session Management Function ("SMF")) to handle security aspects for a UAS in a 3GPP network includes receiving a revocation message including a UAV ID and sending a revocation indication to the UE in response to the revocation message. The method includes deleting a UAS context and receiving a revocation acknowledgment from the UE, corresponding to the revocation message.

[0007] One method of a UAS network function for handling security aspects for a UAS in a 3GPP network includes receiving a UUAA request from a first network entity (e.g., AMF / SMF), where the UUAA request includes one or more of a network-level UAV ID, a subscription permanent identifier ("SUPI"), and a Civil Aviation Authority ("CAA")-level UAV ID. The method includes associating the subscription permanent identifier with the CAA-level UAV ID and the network-level UAV ID, and sending a second UUAA request to a USS and / or UTM, where the second UUAA request includes routing information for a network function that handles message exchanges related to the UAV and / or UAV-C with the USS / UTM.

[0008] A more particular description of the embodiments briefly described above will be made by reference to specific embodiments which are illustrated in the accompanying drawings, with the understanding that these drawings depict only certain embodiments and are not to be considered limiting in scope as such, it being understood that the embodiments have been described and explained with added specificity and detail through the use of the accompanying drawings. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for handling security aspects for a UAS in a 3GPP network. [Figure 2A] FIG. 1 illustrates one embodiment of a procedure for removal of security information related to UUAA revocation at a UAV / UAV-C and a 3GPP Network Function (“NF”). [Figure 2B] FIG. 2B is a diagram showing a continuation of the procedure in FIG. 2A. [Figure 3A] A diagram illustrating one embodiment of another procedure for UUAA revocation. [Figure 3B] FIG. 3B is a diagram showing a continuation of the procedure in FIG. 3A. [Figure 4A] A diagram illustrating one embodiment of a procedure for UAV and UAV-C pairing revocation based authorization and session security information deletion. [Figure 4B] FIG. 4B is a diagram showing a continuation of the procedure in FIG. 4A. [Figure 5A] A diagram illustrating one embodiment of a procedure for UAS re-authentication and authorization / pairing re-authorization. [Figure 5B] FIG. 5B is a diagram showing a continuation of the procedure in FIG. 5A. [Figure 6A] FIG. 1 illustrates one embodiment of a procedure for UAV and UAV-C Pairing / Association Authorization. [Figure 6B] FIG. 6B is a diagram showing a continuation of the procedure in FIG. 6A. [Figure 6C] FIG. 6C is a diagram showing a continuation of the procedure in FIG. 6B. [Figure 7A] FIG. 1 illustrates one embodiment of a procedure for command and control (“C2”) and / or UAS pairing authorization. [Figure 7B] FIG. 7B is a diagram showing a continuation of the procedure in FIG. 7A. [Figure 7C] FIG. 7B is a diagram showing a continuation of the procedure in FIG. 7A. [Figure 8A] A diagram illustrating one embodiment of a procedure for UAV and UAV-C pairing authorization and session security setup. [Figure 8B] FIG. 8B is a diagram showing a continuation of the procedure in FIG. 8A. [Figure 8C] FIG. 8C is a diagram showing a continuation of the procedure in FIG. 8B. [Figure 9A] FIG. 1 illustrates one embodiment of a procedure for UAV and UAV-C pairing authorization revocation. [Figure 9B] FIG. 9B is a diagram showing a continuation of the procedure in FIG. 9A. [Figure 10A] FIG. 1 illustrates one embodiment of a procedure for USS / UTM Triggered PDU session establishment. [Figure 10B] FIG. 10B is a diagram showing a continuation of the procedure in FIG. 10A. [Figure 11] FIG. 1 is a block diagram illustrating one embodiment of a user equipment device that may be used to handle security aspects for a UAS in a 3GPP network. [Figure 12] FIG. 1 is a block diagram illustrating one embodiment of a network equipment device that may be used to handle security aspects for a UAS in a 3GPP network. [Figure 13] FIG. 2 is a flow chart diagram illustrating one embodiment of a first method for handling security aspects for a UAS in a 3GPP network. [Figure 14] FIG. 2 is a flow chart diagram illustrating one embodiment of a second method for handling security aspects for a UAS in a 3GPP network. [Figure 15] FIG. 11 is a flow chart diagram illustrating one embodiment of a third method for handling security aspects for a UAS in a 3GPP network. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] As will be appreciated by one skilled in the art, aspects of these embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects.

[0011] For example, the disclosed embodiments may be implemented as hardware circuitry including custom very large scale integrated ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as 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, programmable logic devices, or the like. 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.

[0012] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transitory, and / or non-transmittable. The storage devices may not embody signals. In some embodiments, the storage devices employ only signals to access the code.

[0013] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device that stores the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0014] More specific examples (non-exhaustive list) of storage devices would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0015] The code for carrying out the operations of the embodiments may be any number of lines of code and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, or the like, and traditional procedural programming languages ​​such as the "C" programming language or the like, and / or machine code such as assembly language. The code may run entirely on the user's computer, partially on the user's computer, as a stand-alone 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"), wireless LAN ("WLAN"), or wide area network ("WAN"), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider ("ISP").

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

[0017] References throughout this specification to "one embodiment," "embodiment," or similar phrases mean that a particular feature, structure, or characteristic described with respect to that embodiment is included in at least one embodiment. Thus, throughout this specification, all occurrences of the phrases "in one embodiment" or "in an embodiment" and similar phrases do not necessarily refer to the same embodiment, but mean "one or more, but not all, embodiments," unless otherwise noted. The terms "including," "comprising," "having," and variations thereof mean "including, but not limited to," unless otherwise noted. Enumerated listings of items do not imply that any or all of the items are mutually exclusive, unless otherwise noted. Additionally, the articles "a," "an," and "the" in the original English text refer to "one or more," unless otherwise noted.

[0018] As used herein, a list with the conjunction "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B and / or C includes only A, only B, only C, a combination of B with A, a combination of B with C, a combination of A with C, or a combination of A, B and C. As used herein, a list using the phrase "one or more of" includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A with B, a combination of B with C, a combination of A with C, or a combination of A, B, and C. As used herein, "one of" includes only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C" includes only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof" includes only A, only B, only C, the combination of A and B, the combination of B and C, the combination of A and C, or the combination of A, B, and C.

[0019] Aspects of these embodiments are described below with reference to schematic flowchart illustrations and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowchart illustrations and / or schematic block diagrams, and combinations of blocks in the schematic flowchart illustrations and / or schematic block diagrams, may be implemented by code that is provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate machine instructions that, when executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / activities specified in the flowchart illustrations and / or block diagrams.

[0020] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture that includes instructions that implement the functions / acts specified in the flowchart illustrations and / or block diagrams.

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

[0022] The call flow diagrams, flowchart diagrams, and / or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods and program products according to various embodiments. In this regard, each block in the flowchart diagrams and / or block diagrams may represent a module, segment, or portion of code, which contains one or more executable instructions of code for implementing the specified logical function(s).

[0023] It should also be noted that in some alternative implementations, the functions noted in the blocks may be performed out of the order shown. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods may be contemplated that are equivalent in function, logic, or effect to one or more blocks of the illustrated diagrams, or portions thereof.

[0024] Various arrow and line types may be employed in the call flow diagrams, flowchart diagrams, and / or block diagrams, but it is understood that these are not intended to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiments. For example, arrows may indicate waiting or monitoring periods of unspecified duration between recited steps of the depicted embodiments. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or a combination of dedicated hardware and code.

[0025] Descriptions of elements in each figure may refer to the elements in subsequent figures. Like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0026] Generally, this disclosure describes systems, methods, and apparatus for handling security aspects related to UAV / UAV-C authorization and pairing to a UAS. In some embodiments, these methods may be performed using computer code embedded on a computer readable medium. In some embodiments, the apparatus or system may include a computer readable medium containing computer readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of the solutions described below.

[0027] UAV USS Authentication and Authorization ("UUAA") is a procedure that ensures that a UAV can be authenticated and authorized by a USS before connectivity to UAS services is enabled. UUAA is performed between the UAV and the USS.

[0028] The UAV is allowed to perform USS / UTM and UUAA only after the UAV (i.e., including the UE) has successfully completed the primary authentication. The UUAA procedure may be triggered by the AMF when the UAV registers to 5GS. Alternatively, UUAA may be triggered by the SMF during the PDU session establishment procedure.

[0029] The AMF or SMF triggers the UUAA procedure when the UAV has an Aerial UE subscription and when the UAV requests access to a UAS service (e.g., by providing the UAV's CAA-Level UAV ID in a registration request or a PDU session establishment request). The UAV is authenticated based on the CAA-Level UAV ID and the credentials associated with the CAA-Level UAV ID. The authentication message is included in a transparent container and conveyed between the UAV and the USS via the 3GPP UAS Network Function (hereinafter referred to as "UAS-NF"). Upon successful completion of the UUAA procedure, the USS can send the UAS security information in a UUAA authorization payload to the UAV.

[0030] The UUAA procedure may be triggered by the USS for reauthentication if the USS had previously authenticated the UAV. At any time after the initial registration, the USS or the AMF (when the networking supports UUAA during registration) may initiate a reauthentication procedure for the UAV.

[0031] However, authentication, authorization, and pairing aspects related to existing UAVs supported by 3GPP networks are incomplete, as described in the following sub-problems: In this disclosure, we address the following challenges related to UAV / UAV-Controller (UAV-C) authentication / authorization and pairing authorization (or re-authorization).

[0032] Issue 1 - Lack of authorization information and security context release after UAS authentication / pairing authorization revocation. How the corresponding authorization information and / or security context is released after authorization revocation is not defined in the 5G system for the UAS. If the authorization information and security context are not released after UAS authentication or authorization revocation (or C2 pairing revocation), the old security context may be reused in the UAV / UAV-C, and the service may fail due to security information mismatch between the UAV / UAV-C and the USS.

[0033] Problem 2 - Failure to provide the USS / UTM with UAS-NF routing information to support re-authorization. During re-authorization, the USS / UTM may need to contact the correct UAS-NF through which the UAV was previously authenticated and / or authorized to send the re-authorization request. However, it is not yet defined how the USS / UTM identifies the correct UAS-NF to handle UAS communications related to the UAV in 5GS.

[0034] Issue 3 - Lack of security aspects related to pairing. The pairing procedure of the UAV and UAV-C is incomplete by not illustrating on what information the 5GS decides to activate a PDU session related to command and control ("C2") between the UAV and UAV-C, and by not clarifying how security of the C2 session is set up.

[0035] To solve the above problems, various solutions are disclosed on how the aviation authorities grant the request by proving that the UAV is authorized to perform the UAV operation, and how the authorization of the UAV is revoked when necessary. Similarly, solutions are disclosed on how the UAV can be associated with a UAV controller (i.e., a networked or non-networked UAV-C) in the 3GPP core network, and how the corresponding UAV / UAV-C pairing revocation is performed to release the connection between the UAV and the UAV-C.

[0036] 1 illustrates a wireless communication system 100 for supporting handling of security aspects related to UAV / UAV-C authorization and pairing to a UAS, according to an embodiment of the disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a UAV 106 and a UAV-C that may include instances of the remote unit 105, a radio access network ("RAN") 120 (e.g., NG-RAN), and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may be comprised of at least one base unit 121 with which the remote unit 105 communicates using wireless communication links 123. Although a particular number of remote units 105, base units 121, wireless communication links 123, RANs 120, and mobile core networks 140 are depicted in FIG. 1, those skilled in the art will recognize that any number of remote units 105, base units 121, wireless communication links 123, RANs 120, and mobile core networks 140 may be included in the wireless communications system 100.

[0037] The unmanned aerial system ("UAS") 101 includes an unmanned aerial vehicle ("UAV") 106, e.g., a "drone," and a UAV controller (denoted "UAV-C") 108. The UAS operator 103 is the one who operates the UAV 106 (e.g., via the UAV-C 108) and is typically the one who requests permission to fly. The UAV 106 and the UAV-C 108 may each be a UE in the wireless communication system 100 and / or may include an instance of a remote unit 105. As such, the UAV 106 may communicate with an access network (e.g., the RAN 120) to access services provided by the mobile core network 140.

[0038] In some embodiments, the UE communicates with one or more UAV traffic management ("UTM") functions via a network connection with the mobile core network 140. As described below, the UAV 106 and / or UAV-C 108 may establish a PDU session (or similar data connection) with the mobile core network 140 using the RAN 120. The mobile core network 140 then relays traffic between the UE and the packet data network 150 using the PDU session. In some embodiments, the UAV-C 108 may establish a connection with a UTM function where the connection is not established through the mobile core network 140.

[0039] In one implementation, the RAN 120 is compliant with a fifth generation ("5G") cellular system as specified in the 3rd Generation Partnership Project ("3GPP") specifications. For example, the RAN 120 may be a Next Generation Radio Access Network ("NG-RAN") that implements a New Radio ("NR") radio access technology ("RAT") and / or a Long Term Evolution ("LTE") RAT. In another example, the RAN 120 may include a non-3GPP RAT (e.g., Wi-Fi or an Institute of Electrical and Electronics Engineers ("IEEE") 802.11 family compliant WLAN). In another implementation, the RAN 120 is compliant with an LTE system as specified in the 3GPP specifications. However, more generally, the wireless communication system 100 may implement a number of other open or proprietary communication networks, such as Worldwide Interoperability for Microwave Access ("WiMAX") or a network of the IEEE 802.16 family of standards, among other networks. This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0040] In one embodiment, the remote unit 105 may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant ("PDA"), a tablet computer, a smartphone, a smart television (e.g., a television connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a gaming console, a security system (including security cameras), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), or the like. In some embodiments, the remote unit 105 includes a wearable device such as a smart watch, a fitness band, an optical head mounted display, or the like. Additionally, the remote unit 105 may be referred to as a UE, a subscriber unit, a mobile, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit ("WTRU"), a device, or by other terms used in the art. In various embodiments, the remote unit 105 includes a subscriber ID and / or identification module ("SIM") and mobile equipment ("ME") that provides mobile terminated functions (e.g., radio transmission, handover, voice encoding and decoding, error detection and correction, signaling, and access to the SIM). In some embodiments, the remote unit 105 includes terminal equipment ("TE") and / or may be embedded in an appliance or device (e.g., a computing device as described above).

[0041] The remote units 105 may communicate directly with one or more base units 121 in the RAN 120 via uplink ("UL") and downlink ("DL") communication signals. Additionally, the UL and DL communication signals may be carried over wireless communication link 123. In various embodiments, the UL communication signals may include one or more uplink channels, such as a physical uplink control channel ("PUCCH") and / or a physical uplink shared channel ("PUSCH"), while the DL communication signals may include one or more downlink channels, such as a physical downlink control channel ("PDCCH") and / or a physical downlink shared channel ("PDSCH"). Here, the RAN 120 is an intermediate network that provides the remote units 105 with access to the mobile core network 140.

[0042] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection with the mobile core network 140. For example, an application 107 (e.g., a web browser, a media client, a telephone and / or a Voice over Internet Protocol (VoIP) application) in the remote unit 105 may trigger the remote unit 105 to establish a protocol data unit ("PDU") session (or other data connection) with the mobile core network 140 via the RAN 120. The mobile core network 140 then relays traffic between the remote unit 105 and the application server 151 in the packet data network 150 using the PDU session. The PDU session represents a logical connection between the remote unit 105 and the user plane function ("UPF") 141.

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

[0044] In the context of 5G systems ("5GS"), the term "PDU session" refers to a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between the remote unit 105 and a particular data network ("DN") through the UPF 141. A PDU session supports one or more Quality of Service ("QoS") flows. In some embodiments, there may be a one-to-one mapping between QoS flows and QoS profiles, such that all packets belonging to a particular QoS flow have the same 5G QoS Identifier ("5QI").

[0045] In the context of 4G / LTE systems, such as the Evolved Packet System ("EPS"), a Packet Data Network ("PDN") connection (also referred to as an EPS session) provides E2E UP connectivity between a remote unit and the PDN. The PDN connectivity procedure establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and a Packet Gateway ("PGW", not shown) in the mobile core network 140. In some embodiments, there may be a one-to-one mapping between EPS bearers and QoS profiles, such that all packets belonging to a particular EPS bearer have the same QoS Class Identifier ("QCI").

[0046] The base units 121 may be distributed over a geographic region. In some embodiments, the base units 121 may also be referred to as an access terminal, an access point, a base, a base station, a Node B ("NB"), an evolved Node B (abbreviated as eNodeB or "eNB" and also referred to as an evolved Universal Terrestrial Radio Access Network ("E-UTRAN") Node B), a 5G / NR Node B ("gNB"), a Home Node B, a relay node, a RAN node, or any other term used in the art. The base units 121 are generally part of a RAN, such as the RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base units 121. These and other elements of a radio access network are not illustrated, but are generally familiar to those skilled in the art. The base units 121 connect to a mobile core network 140 via the RAN 120.

[0047] The base unit 121 may serve multiple remote units 105 in a serving area, e.g., a cell or a cell sector, via wireless communication link 123. The base unit 121 may directly communicate with one or more of the remote units 105 via communication signals. In general, the 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 on the wireless communication link 123. The wireless communication link 123 may be any suitable carrier in a licensed or unlicensed radio spectrum. The wireless communication link 123 facilitates communication between one or more of the remote units 105 and / or one or more of the base units 121. It should be noted that during NR operation in an unlicensed spectrum (referred to as "NR-U"), the base unit 121 and the remote units 105 communicate over an unlicensed (i.e., shared) radio spectrum.

[0048] In one embodiment, the mobile core network 140 is a 5G core network ("5GC") or evolved packet core ("EPC"), which may be coupled to a packet data network 150, such as the Internet and private data networks, among other data networks. The remote units 105 may have a subscription or other account with the mobile core network 140. In various embodiments, each mobile core network 140 belongs to a single mobile network operator ("MNO") and / or public land mobile network ("PLMN"). This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0049] The mobile core network 140 includes several network functions ("NFs"). As depicted, the mobile core network 140 includes at least one UPF 141. The mobile core network 140 also includes multiple control plane ("CP") functions, including, but not limited to, an access and mobility management function ("AMF") 143, a session management function ("SMF") 145, a UAS network function ("UAS-NF") 147, a unified data management function ("UDM"), and a user data repository ("UDR"), that serve the RAN 120. In some embodiments, the UDM is co-located with the UDR, depicted as a combined entity "UDM / UDR" 149. Although a particular number and type of network functions are depicted in FIG. 1, one skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140.

[0050] To support UAS operations and related security aspects, the mobile core network 140 may also include a UAS-NF 147 for interacting with a UAS Service Supplier ("USS") system and / or a UAS Traffic Management ("UTM") system (shown as a combined node "USS / UTM" 157). The USS / UTM 157, in one embodiment, provides a set of overlapping USSs that assist the UAS operator 103 in executing safe, compliant operations. Services may include flight plan collision avoidance, remote identification, and / or the like. In another embodiment, the USS / UTM 157 may be used to associate (i.e., pair) the UAVs 106 with the UAV-C 108, where each UAV 106 provides its identity to the USS / UTM 157, which grants the request. The USS / UTM 157 may be located outside the mobile core network and may interact with core network functions such as the UAS-NF 147 via the NEF 146.

[0051] Although depicted as a standalone network function, in alternative deployments of system 100, UAS-NF 147 may be implemented as a service offered by NEF 146. UAS-NF 147 is supported by NEF 146 (or by both NEF and Service Capabilities Exposure Function ("SCEF") - denoted as "NEF / SCEF") and used for external exposure of services to the USS. In some embodiments, UAS-NF 147 uses existing NEF / SCEF exposed services for UAV authentication / authorization, UAV flight authorization, UAV / UAV-C pairing authorization and related revocation, for position reporting, and control of QoS / traffic filtering for command and control ("C2") communications.

[0052] Also, note that the UAS-NF 147 may be replaced with another 3GPP NF that handles UAS operational message exchanges related to UAVs / UAV-Cs with the corresponding USS / UTM on behalf of the 3GPP network, such as the UAV Flight Enablement Subsystem ("UFES"), NEF 146, or another suitable NF in the 3GPP network. In some embodiments, a dedicated NEF 146 may be deployed to provide UAS-NF functionality only, i.e., supporting UAS-specific features / APIs and NEF features / APIs specified in the capability exposure towards the USS / UTM 157.

[0053] The UPF 141 is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting data networks ("DNs") in the 5G architecture. The AMF 143 is responsible for termination of non-access stratum ("NAS") signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. The SMF 145 is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) Internet Protocol ("IP") address allocation and management, DL data notification, and traffic steering configuration of the UPF 141 for proper traffic routing.

[0054] The UDM is responsible for generating authentication and key agreement ("AKA") credentials, handling user identification, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to service many network functions. For example, the UDR can store subscription data, policy related data, subscriber related data that is allowed to be exposed to third-party applications, and the like.

[0055] In various embodiments, the mobile core network 140 may also include a Network Repository Function ("NRF") (which provides registration and discovery of Network Function ("NF") services, enabling NFs to identify appropriate services from each other and communicate with each other via application programming interfaces ("APIs")), a Network Publishing Function ("NEF") (responsible for making network data and resources easily accessible to customers and network partners), an Authentication Server Function ("AUSF"), or other NFs defined for 5GC. When present, the AUSF may act as an authentication server and / or authentication proxy, thereby enabling the AMF 143 to authenticate the remote unit 105. In certain embodiments, the mobile core network 140 may include an authentication, authorization, and accounting ("AAA") server.

[0056] 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 particular network slice. Here, a "network slice" refers to a portion of the mobile core network 140 optimized for a particular traffic type or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband ("eMBB") services. As another example, one or more network slices may be optimized for ultra-reliable low-latency communication ("URLLC") services. In other examples, network slices may be optimized for machine type communication ("MTC") services, massive MTC ("mMTC") services, Internet of Things ("IoT") services. In yet other examples, network slices may be deployed for particular application services, vertical services, particular use cases, and the like.

[0057] A network slice instance may be identified by a single network slice selection assistance information ("S-NSSAI"), whereas a set of network slices that the remote unit 105 is authorized to use is identified by a network slice selection assistance information ("NSSAI"), where "NSSAI" refers to a vector value that includes one or more S-NSSAI values. In some embodiments, various network slices may include separate instances of network functions, such as the SMF 145 and the UPF 141. In some embodiments, different network slices may share some common network functions, such as the AMF 143. Different network slices are not shown in FIG. 1 for ease of illustration, although support for them is envisioned.

[0058] In various embodiments, the remote unit 105 (e.g., part of a UAV) receives an indication of UUAA cancellation (alternatively, UAS pairing and / or C2 connection cancellation or UAV-UAV-C pairing authorization cancellation) from the AMF 143 and / or SMF 145 in any of the N1 messages (e.g., PDU session release command), where the remote unit 105 may receive pairing cancellation information / notification with the C2 type, CAA-Level UAV ID, and UAV-C ID in any of the N1 messages.

[0059] After receiving the UUAA revocation, the removal unit 105 (e.g., UAV 106) releases (e.g., removes and / or deletes) locally stored UAS authentication and authorization information (e.g., received from USS / UTM 157 after successful UUAA), such as the UUAA result, UAS security information (e.g., security keys), UUAA lifetime, UAS / UAV authorization information (token or any UUAA authorization information) and UAS ID.

[0060] After receiving the C2 / pairing authorization revocation, the Remote Unit 105 (e.g., UAV 106) releases (e.g., deletes / removes) the locally stored C2 / pairing authorization information and session security information, pairing authorization results, etc. (e.g., received from USS / UTM 157 after successful UAV-UAV-C pairing authorization). In response, the Remote Unit 105 sends a UAA revocation acknowledgement or a pairing revocation acknowledgement to the AMF 143 and / or SMF 145.

[0061] The remote unit 105 sends a C2 / pairing required indication to the AMF 143 and / or SMF 145 in a PDU session establishment request message or any N1 message. In some embodiments, the remote unit 105 may receive the session security information, pairing success indication, CAA-Level-UAV ID, UAV-C ID, and UAS ID in a PDU session establishment accept message or any N1 message from the AMF 143 and / or SMF 145. In some embodiments, the remote unit 105 receives a UAS authentication / authorization ("UAS AA") request indication or pairing authorization request indication or flight authorization request indication with a cause value (e.g., the cause value may include information regarding UAS AA / C2 reauthentication / UAV-C change / pairing authorization) from the AMF 143 and / or SMF 145.

[0062] Although FIG. 1 depicts components of a 5G RAN and a 5G core network, the described embodiments for handling security aspects for UAS in 3GPP networks apply to other types of communication networks and RATs, including IEEE 802.11 variants, Global System for Mobile Communications ("GSM", i.e., 2G digital cellular network), General Packet Radio Service ("GPRS"), Universal Mobile Telecommunications System ("UMTS"), LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, and the like.

[0063] Furthermore, in LTE variants where the mobile core network 140 is the EPC, the depicted network functions may be replaced with appropriate EPC entities such as a mobility management entity ("MME"), a serving gateway ("SGW"), a PGW, a home subscriber server ("HSS"), an authentication center ("AuC"), etc. For example, the AMF 143 could be mapped to the MME, the SMF 145 could be mapped to the control plane part of the PGW ("PGW-C") or SGW+PGW-C and / or the MME, the UPF 141 could be mapped to the user plane part of the SGW and PGW ("PGW-U"), the NEF could be mapped to the SCEF+NEF, the UAS-NF could be mapped to the UAS-NF / SCEF+NEF, the UDM / UDR 149 could be mapped to the HSS / AuC, etc.

[0064] In the following description, the term "gNB" is used for base station / base unit, but this can be replaced with any other radio access node, e.g., RAN node, ng-eNB, eNB, base station ("BS"), access point ("AP"), etc. Additionally, the term "UE" is used for mobile station / remote unit, but this can be replaced with any other remote device, e.g., remote unit, MS, ME, etc. Furthermore, the operation is mainly described in the context of 5G NR. However, the solutions described below are equally applicable to other mobile communication systems for handling security aspects for UAS in 3GPP networks.

[0065] This disclosure proposes the following features related to UAS security (authentication, authorization (or re-authorization), UAS-NF discovery, revocation, and session security setup) as listed in the following solutions: a. According to a first solution embodiment, UAV / UAV-C authentication and security information is removed upon USS UAV Authentication and Authorization ("UUAA") revocation and pairing / C2 revocation. b. According to an embodiment of the second solution, 3GPP NF / UAS-NF routing and re-authorization is supported. c. According to a third solution embodiment, C2 pairing authorization and session security setup is supported. d. According to an embodiment of the fourth solution, USS / UTM triggered PDU session establishment is supported.

[0066] NOTE: In all embodiments, a 3GPP network function ("3GPP NF") that supports aerial functionality related to UAV identification and tracking by sending and receiving UAS-related message exchanges with a USS / UTM, and that supports remote identification, UUAA, pairing authorization and related cancellations, may be referred to as a UAS-NF. In the following description, the term "UAS-NF" is used for the 3GPP NF described above, but can be replaced accordingly with any other 3GPP NF that supports UAS functionality, such as a NEF, SCEF+NEF, UFES, or Unmanned Aircraft System Control / Management / Interworking Function ("UASC / M / I / F") (or other NF that coordinates UAS procedures between the 3GPP network and an external USS / UTM).

[0067] The first solution focuses on removing the authorization information and / or UAS security context stored in the UAV / UAV-C and 3GPP NF following the authorization revocation procedure. Applicable 3GPP NFs include the AMF 143, SMF 145, NEF 146, and UAS-NF 147 (representing the 3GPP UAS network function for supporting aerial functionality related to UAV identification and tracking and for supporting remote identification), or any NF coordinating UAS procedures within a 3GPP network).

[0068] The first solution considers two scenarios for revocation and deletion / removal of UAS-related information in the UE (i.e., UAV / UAV-C) and 3GPP NF: The first scenario (i.e., Scenario A) is UUAA revocation, and the second scenario (i.e., Scenario B) is UAS pairing revocation (i.e., UAV-UAV-C pairing authorization revocation). As used herein, "UAS pairing" refers to UAV / UAV-C pairing, C2 pairing, and / or C2 association. It should be noted that USS UAV Authorization / Authentication ("UUAA") may alternatively be referred to as UAS Authentication and Authorization ("UAA").

[0069] 2A-2B show an example procedure 200 for UUAA revocation and removal of related security information in a UAV / UAV-C and 3GPP NF (such as AMF, SMF, UDM and NEF / UAS-NF) according to an embodiment of the first solution. The procedure 200 includes a UE 201 (e.g., an embodiment of the UAV's aerial UE and remote unit 105), an AMF 203 (e.g., an embodiment of the AMF 143), an SMF 205 (e.g., an embodiment of the SMF 145), a UDM 207 (e.g., an embodiment of the UDM / UDR 149), a UAS-NF 209 (e.g., an embodiment of the UAS-NF 147), and a USS / UTM server 211 (e.g., an embodiment of the USS / UTM 157). In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAV / UAV-C related UAS operational message exchanges with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps of procedure 200 are as follows:

[0070] 2A, in step 1, when the USS / UTM server 211 decides to cancel the UUAA, it sends a UUAA cancellation request to the UAS-NF 209 (see messaging 215), where the UUAA cancellation request includes at least the 3GPP UAV ID (e.g., a General Public Subscription Identifier ("GPSI")) and a CAA-Level UAV ID.

[0071] In step 2, the UAS-NF 209 retrieves the UUAA context associated with the 3GPP UAV ID and the CAA-Level UAV ID. For example, in step 2a, the UAS-NF 209 sends a Nudm_UECM_Get Request message to the UDM 207 with the received 3GPP UAV ID and with the NF type set to "AMF". Alternatively, the UAS-NF 209 may fetch a (locally stored) SUPI corresponding to the received 3GPP UAV ID and send a Nudm_UECM_Get Request message to the UDM, the request including the SUPI and with the NF type set as "AMF". In step 2b, the UAS-NF 209 receives the serving AMF information corresponding to the 3GPP UAV ID (or SUPI) from the UDM 207, i.e., in a Nudm_UECM_Get Response message (see messaging 217).

[0072] In step 3, the UAS-NF 209 forwards the received UUAA revocation request message to the Serving AMF 203 (see messaging 219), which includes the 3GPP UAV ID / SUPI and the CAA-Level UAV ID in a transparent container. Alternatively, if the AMF 203 subscribes to be notified of UUAA revocation, the UAS-NF 209 sends a UUAA revocation notification message to the Serving AMF 203. The UAS-NF 209 may delete the UUAA context related to the UUAA revocation request at this phase or later.

[0073] In step 4a, after receiving the UUAA cancellation request / notification, the AMF 203 checks whether there is an active PDU session corresponding to the indicated 3GPP UAV ID / CAA-Level UAV ID (see block 221). If there is an active PDU session, the AMF 203 performs steps 4b to 4d to release the active PDU session corresponding to the indicated 3GPP UAV ID / CAA-Level UAV ID. Otherwise, if there is no active PDU session for the UE 201 (i.e., UAV), steps 4b to 4d may be skipped.

[0074] In step 4b, the AMF 203 sends the UUAA cancellation indication and the 3GPP UAV ID / SUPI / CAA-Level UAV ID together with the PDU session release request to the SMF 205, for example in a Nsmf_PDUSessionUpdateSM context request message (see messaging 223). Alternatively, the UAS-NF 209 may send the UUAA cancellation message to the serving SMF (i.e., SMF 205). The SMF 205 updates / deletes the locally stored UAV related information / UAA status information corresponding to the received 3GPP UAV ID / SUPI / CAA-Level UAV ID.

[0075] In an alternative embodiment, the UUAA cancel request may be sent directly from the UAS-NF 209 to the SMF 205. After receiving such a request, the SMF 205 may trigger a PDU session release. Note that if the UUAA cancel request is sent directly from the UAS-NF 209 to the SMF 205, steps 4a and 4b above are not necessary and may therefore be skipped.

[0076] In step 4c, after receiving the UUAA cancellation indication, the SMF 205 sends a PDU session release command including the PDU session ID and CAA-Level UAV ID with cause set as "UUAA authorization cancellation" to the AMF 203. The AMF 203 forwards the received PDU session release command including the PDU session ID, cause "UUAA cancellation" to the UE 201 (i.e., UAV / UAV-C) (see messaging 225).

[0077] In step 4d, the UE 201 (i.e., UAV / UAV-C) performs a PDU session release by sending a PDU session release acknowledgement and a UUAA cancellation acknowledgement indication to the SMF 205 via the AMF 203, similar to existing systems described, for example, in 3GPP Technical Specification ("TS") 23.502 (see messaging 227). If the SMF 205 considers the UUAA cancellation successful after receiving the UUAA cancellation acknowledgement indication, steps 5-11 may be skipped.

[0078] In step 5, in response to receiving a UUAA revocation request / notification from the USS / UTM server 211 via the UAS-NF 209, the AMF 203 sends a UE Configuration Update ("UCU") command with a UUAA revocation indication and a CAA-Level UAV ID to the UE 201 (i.e., UAV / UAV-C) (see messaging 229). The AMF 203 may delete the UUAA context that is being revoked during this phase or later.

[0079] 2B, in step 6, after receiving the UUAA revocation indication, the UE 201 (i.e., UAV / UAV-C) deletes (see block 231) the locally stored UAS authorization information (i.e., UUAA related authorization data) and all UAS security context related information (e.g., keys, tokens, lifetime, pairing information, pairing security information, etc.) related to the CAA-Level UAV ID (i.e., received and stored after the successful UUAA should have been deleted earlier). Although FIG. 2B depicts the UE 201 (i.e., UAV) removing / deleting the locally stored UAS authorization information after receiving the UUAA revocation indication from the AMF 203 in step 5, in other embodiments, the UE 201 (i.e., UAV) may delete the locally stored UAV related information immediately after step 4c after receiving the UUAA revocation indication during the PDU session release.

[0080] In step 7, after the successful release of all UAS authorization and security information, UE201 (i.e., UAV / UAV-C) sends a UE Configuration Update ("UCU") Complete message to AMF203 with a UUAA revocation acknowledgement indication and a CAA-Level UAV ID (see messaging 233). Alternatively, if AMF203 deleted the UUAA context to be revoked in step 5, after receiving in step 7 with the UUAA revocation acknowledgement indication and the CAA-Level UAV ID, AMF203 may consider the UUAA revocation successful and steps 8-11 may be skipped. It should be noted that when UE201 (i.e., UAV) receives a UUAA revocation indication in step 4c and sends a UUAA revocation acknowledgement in step 4d, steps 5 and 7 are not necessary and may therefore be skipped.

[0081] In step 8a, AMF203 sends a UAV Authentication and Authorization ("UAV AA") status notification message to UDM207 (i.e., this may be a Nudm service operation message) with a "UUAA Cancelled Indication" with the 3GPP UAV ID (e.g., GPSI) and CAA-Level UAV ID (see messaging 235). In an alternative embodiment, AMF203 sends a UUAA status notification message to UDM207 (and / or a co-located UDR) with the above content.

[0082] In step 8b, the UDM 207 (and / or the co-located UDR) updates the UAV subscription data with the UAS authentication status information (i.e., UUAA revocation) and removes the CAA-Level UAV ID associated with the 3GPP UAV ID for the SUPI (see block 237).

[0083] In step 8c, UDM 207 (and / or the co-located UDR) sends a UAV AA Status Acknowledgement message to AMF 203 (i.e., this may be a Nudm Service Operation message) including the 3GPP UAV ID and the received CAA-Level UAV ID (see messaging 239). In an alternative embodiment, UDM 207 (and / or the co-located UDR) sends a UUAA Status Acknowledgement message to AMF 203 with the above content.

[0084] In step 9, the AMF 203 deletes all locally stored (i.e., available and not previously deleted) UAV-related information for the CAA-Level UAV ID and the 3GPP UAV ID, such as authorization information (tokens), UUAA authentication and authorization status information, lifespan, security information, etc. (see block 241). Although FIG. 2B depicts the AMF 203 deleting the locally stored UAV-related information after receiving the UAV AA (aka UUAA) acknowledgement message, in other embodiments, the AMF 203 may delete the locally stored UAV-related information immediately after receiving the UUAA revocation request in step 3. Alternatively, the locally stored UAV-related information may be deleted after sending an acknowledgement to the UAS-NF 209 (i.e., in step 10).

[0085] In one alternative embodiment, if the UUAA context for the UE 201 (i.e., UAV) was deleted by the AMF 203 in the previous step while sending the UUAA cancellation request to the UE 201 (i.e., UAV), after receiving the UUAA cancellation acknowledgement from the UE 201, the AMF 203 does not need to do anything other than deem the UUAA cancellation successful in response to receiving the UUAA cancellation acknowledgement from the UE 201. Thus, in this alternative embodiment, steps 8a, 8b, and 8c would be skipped. In a further embodiment, the AMF 203 is not expected to send a UUAA cancellation response / acknowledgement message to the UAS-NF 209.

[0086] In step 10, the AMF 203 sends a UUAA cancellation response / acknowledgement message to the UAS-NF 209 (see messaging 243). As depicted, the cancellation response / acknowledgement message may include the 3GPP UAV ID, the CAA-Level UAV ID, and the UUAA cancelled indication / success indication. Alternatively, the UUAA cancellation response / acknowledgement message name may be written in any message name (e.g., using any Naf_Auth_Notification or in any NEF service operation message). Alternatively, if the AMF 203 sends only the cancellation response / acknowledgement message to the UAS-NF 209 (i.e., if the message type implicitly indicates that cancellation has occurred), the AMF 203 does not need to also send the UUAA cancelled indication / success indication in the cancellation response / acknowledgement message.

[0087] In an alternative embodiment, if SMF 205 received the UUAA cancellation request directly from UAS-NF 209, step 10 may be performed by SMF 205 after receiving a UUAA cancellation acknowledgement from UE 201. In a further alternative embodiment, SMF 205 is not expected to need to do anything in response to the UUAA cancellation acknowledgement from UE 201 other than considering the UUAA cancellation successful. Thus, in this alternative embodiment, step 10 is skipped as SMF 205 is not expected to send a UUAA cancellation response / acknowledgement message to UAS-NF 209.

[0088] In step 11, the UAS-NF 209 sends the received UUAA revocation response / acknowledgement message to the USS / UTM server 211 (see messaging 245). Alternatively, the UAS-NF 209 sends a UUAA revoked indication / success indication to the USS / UTM server 211 if received from the AMF 203. After receiving the UUAA revoked indication, the UAS-NF 209 deletes any UAS-related information (i.e., UUAA context) and any UAV identifiers stored locally for the UE 201 (i.e., UAV / UAV-C). Although FIG. 2B depicts the UAS-NF 209 deleting the locally stored UAV-related information after receiving the UAV AA (aka, UUAA) acknowledgement message, in other embodiments, the UAS-NF 209 may delete the locally stored UAV-related information (i.e., UUAA-related authorization data / UUAA context) immediately after receiving the UUAA revocation request in step 2. Alternatively, the locally stored UAV-related information may be deleted after sending an acknowledgement to the USS / UTM server 211 (i.e., in step 12).

[0089] In an alternative embodiment, if the locally stored UAV-related information for the UE 201 (i.e., the UAV) is removed / deleted by the UAS-NF 209 immediately after a previous step, e.g., sending a UUAA revocation request to the AMF 203 and / or SMF 205, the UAS-NF 209 does not need to do anything other than consider the UUAA revocation successful after receiving a UUAA revocation acknowledgement from the AMF 203 and / or SMF 205. Thus, in this alternative embodiment, step 11 is skipped since the UAS-NF 209 is not expected to send a UAA revocation response / acknowledgement message to the USS / UTM server 211. Alternatively, the UAS-NF 209 may send a UUAA revocation acknowledgement to the USS / UTM server 211 immediately after deleting the locally stored UAV-related information for the UE and / or sending a revocation request to the AMF / SMF.

[0090] In step 12, after receiving the UUAA cancelled / success indication, the USS / UTM server 211 updates the UAS authentication and authorization information status and deletes the relevant security information stored locally for the UAV corresponding to its CAA-Level UAV ID (see block 247). Procedure 200 ends.

[0091] Applicability to EPS: The UUAA cancellation procedure 200 shown in Figures 2A-2B described above is also applicable to EPS with the adaptations of using MME instead of AMF 203, using SGW+PGW-C instead of SMF 205, and using HSS / AuC instead of UDM 207. In EPS deployment, UAS-NF 209 may be replaced by another 3GPP NF / UFES that can perform the role of UAS-NF 209 or as a UAS control function in the 3GPP network. The 3GPP NF / UFES may be a standalone network function or a service provided by SCEF+NEF in EPS instead of NEF in 5GS.

[0092] 3A-3B show a first variant procedure 300 of UUAA revocation according to an embodiment of the first solution. The procedure 300 involves the UE 201, the AMF 203, the SMF 205, the UDM 207, the UAS-NF 209, and the USS / UTM server 211. In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAV / UAV-C related UAS operational message exchange with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps of the procedure 300 are as follows:

[0093] 3A, in step 1, the USS / UTM server 211 determines to revoke the UUAA corresponding to a UAV identified by a CAA-Level UAV-ID and sends a UUAA revocation notification including the GPSI and CAA-Level UAV ID to the corresponding UAS-NF 209 using a service action message (see messaging 301). In some embodiments, the UAS-NF 209 is subscribed to the USS / UTM server 211 to receive notifications related to UAV authentication and authorization.

[0094] In step 2, the UAS-NF 209 fetches the Serving AMF ID corresponding to the GPSI of the UAV from the UDM 207, e.g. by invoking a Nudm_UECM_Get request / response message according to TS 23.502, section 5.2.3.2.4 (see messaging 303), where it is assumed that the GPSI corresponds to the UE 205 (i.e. embodied in the UAV).

[0095] In step 3, the UAS-NF 209 sends the received UUAA revocation notification message to the AMF 203 with the CAA-Level UAV ID (see Messaging 305). The UAS-NF 209 removes locally stored UAV-related information (if any) related to the CAA-Level UAV ID (i.e., UUAA-related authorization data). In some embodiments, the AMF 203 is subscribed to the UAS-NF 209 to receive notifications related to UAV authentication and authorization.

[0096] In step 4a, after receiving the UUAA revocation notification, the AMF 203 determines whether there is an active PDU session corresponding to the identified UAV (i.e., related to the UE 201) (see block 307). If there is an active PDU session, the AMF 203 decides to request a PDU session release.

[0097] In conditional step 4b, if there is an associated active PDU session corresponding to the UAV, AMF203 and / or SMF205 initiate a PDU session release procedure (see block 309), for example based on 3GPP TS 23.502, section 4.3.4. Upon PDU session release, SMF205 further enables UUAA revocation by UE201 (i.e., UAV) using the PDU session release procedure. Now, SMF205 sends the CAA-Level UAV ID with UUAA revocation indication to UE201 (i.e., UAV) in a PDU session release command, where step 5 is skipped and step 6 is performed. Furthermore, SMF205 may delete locally stored UAV-related information (i.e., UUAA-related authorization data / UUAA context).

[0098] In step 5, the AMF 203 further enables UUAA revocation by the UE 201 (i.e., UAV) using a UE Configuration Update procedure (see messaging 311). Here, the AMF 203 sends the CAA-Level UAV ID together with the UUAA revocation indication to the UE 201 (i.e., UAV) in a UE Configuration Update Command. Alternatively, based on a network policy, the AMF 203 may trigger a network-initiated deregistration process by sending the CAA-Level UAV ID together with the UUAA revocation indication to the UE 201 (i.e., UAV) in a deregistration request message.

[0099] In step 6, after receiving the UUAA revocation instruction, the UE 201 (i.e., the UAV) deletes all UAS authorizations (i.e., UUAA-related authorization data) and security information stored locally corresponding to its CAA-Level UAV ID (see block 313).

[0100] Continuing to refer to FIG. 3B, in step 7, the UE 201 (i.e., UAV) further sends a UE Configuration Update Complete message to the AMF 203 (see messaging 315). Here, the UE Configuration Update Complete message includes a UUAA revocation acknowledgement with the CAA-Level UAV ID. Alternatively, if the UE 201 (i.e., UAV) receives a UUAA revocation indication in a registration request message, the UE 201 (i.e., UAV) sends a deregistration accept message to the AMF 203 including a UUAA revocation acknowledgement with the CAA-Level UAV ID. Alternatively, if the UE 201 (i.e., UAV) receives a UUAA revocation indication in a PDU session release command, the UE 201 (i.e., UAV) sends a PDU session release acknowledgement message including a UUAA revocation acknowledgement to the SMF 205 with the CAA-Level UAV ID.

[0101] In step 8, after receiving the UUAA revocation acknowledgement and the CAA-Level UAV ID, the AMF 203 deletes the locally stored UAS authorization and security information corresponding to the CAA-Level UAV ID (see block 317). Although FIG. 3B depicts the AMF 203 deleting the locally stored UAV-related information after receiving the UUAA revocation acknowledgement message, in other embodiments, the AMF 203 may delete the locally stored UAV-related information immediately after sending the UUAA revocation indication in step 5. Alternatively, the locally stored UAV-related information may be deleted after sending the UUAA revocation acknowledgement to the UAS-NF 209 (i.e., see step 9). Alternatively, after receiving the UUAA revocation acknowledgement and the CAA-Level UAV ID, the SMF 205 may consider the UUAA revocation successful and step 9 may be skipped.

[0102] In step 9, the AMF 203 further sends a UUAA revocation acknowledgement message to the UAS-NF 209 with a success indication, the GPSI and the CAA-Level UAV ID (see messaging 319). After receiving the UUAA revocation acknowledgement, the UAS-NF 209 removes the locally stored UAV-related information (if any) associated with the CAA-Level UAV ID (i.e., if the UUAA-related authorization data was not deleted in step 3).

[0103] In step 10, the UAS-NF 209 further sends a received UUAA cancellation acknowledgement message along with the received success indication, GPSI and CAA-Level UAV ID to the USS / UTM server 211 (see messaging 321). Alternatively, steps 10 and 11 may be performed immediately after step 3.

[0104] In step 11, after receiving the UUAA revocation acknowledgement message containing the success indication, GPSI, and CAA-Level UAV ID, the USS / UTM server 211 updates the UAS authentication status and related information stored locally for the UAV (i.e., UE 201) (see messaging 323). The procedure 300 ends.

[0105] 4A-4B show a procedure 400 for UAV and UAV-C pairing revocation based authorization and session security information deletion in a UE 401 (i.e., UAV and / or UAV-C), AMF 203, SMF 205, and UAS-NF 209. The procedure 400 involves the UE 401 (which may be an embodiment of a remote unit 105, UAV 106, and / or UAV-C 108, for example), AMF 203, SMF 205, UDM 207, UAS-NF 209, and USS / UTM server 211. It should be noted that the UAS-NF depicted in FIGS. 4A-4B is a 3GPP NF, such as a UFES / NEF / UAS-NF / any NF in the 3GPP network that handles UAS operational message exchanges related to the UAV / UAV-C with a corresponding USS / UTM on behalf of the 3GPP network. In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAS operational message exchanges related to UAVs / UAV-Cs with corresponding USSs / UTMs on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps of procedure 400 are as follows:

[0106] 4A, in step 1, when the USS / UTM server 211 decides to cancel the UAV / UAV-C pairing (also referred to as C2 pairing or C2 association), the USS / UTM server 211 sends a pairing cancellation request to the UAS-NF 209 (see messaging 405). Alternatively, the USS / UTM server 211 may send a pairing cancellation notification, for example, when the UAS-NF 209 is subscribed to the USS / UTM server 211 to receive notifications related to UAS pairing. Alternatively, when the USS / UTM server 211 decides to cancel any C2 connection for the UAV, the USS / UTM server 211 sends a C2 cancellation request (or notification) to the 3GPP NF with the 3GPP UAV ID (e.g., GPSI) and a cancellation C2 type indicating either "USS / UTM C2" or "UAV-UAVC C2" or "TPAE C2".

[0107] To better illustrate possible messages within procedure 400, in FIG. 4A the message is shown as a “Pairing / C2 Revocation Request / Notification.” Such a message may be, for example, a Pairing Revocation Request message, a Pairing Revocation Notification message, a C2 Revocation Request message, or a C2 Revocation Notification message. In the depicted embodiment, the Pairing / C2 Revocation Request / Notification message includes a 3GPP UAV ID (e.g., GPSI), a CAA-Level UAV ID, and a UAV-C ID (or UAV-C address).

[0108] In step 2a, the UAS-NF 209 sends a Nudm_UECM_Get request message to the UDM 207, which includes the 3GPP UAV ID (e.g., GPSI / SUPI), the NF type as “SMF”, and receives the serving SMF information corresponding to the SUPI (or other 3GPP UAV ID) from the UDM 207 in a Nudm_UECM_Get response message (see messaging 407). Here, it is assumed that the UDM 207 identifies the SMF 205 as the serving SMF.

[0109] In step 2b, the UAS-NF 209 sends the received Pairing / C2 Cancellation Request / Notification message to the Serving SMF 205 (see Messaging 409), where the Pairing / C2 Cancellation Request / Notification message includes one or more of the 3GPP UAV ID, the UAV-C ID, the SUPI, the CAA-Level UAV ID, and combinations thereof.

[0110] Alternatively, the UAS-NF 209 sends the received C2 revocation request / notification to the SMF 205, where the C2 revocation request / notification includes the 3GPP UAV ID (e.g., GPSI) and a revocation C2 type indicating either "USS / UTM C2" or "UAV-UAVC C2" or "TPAE C2". The revocation C2 type can be in the format (target C2 type, value) that can include information, for example, "Revocation C2 Type: (USS / UTM C2, USS / UTM Address / ID) or (UAVC C2, UAVC Address / ID) or (TPAE C2, TPAE Address / ID)". Furthermore, the UAS-NF 209 sends a pairing revocation response / acknowledgement message to the USS / UTM server 211. In one embodiment, the UAS-NF 209 sends the pairing revocation response / acknowledgement message immediately after receiving the pairing / C2 revocation request / notification message. In another embodiment, the UAS-NF 209 waits to send the pairing cancellation response / acknowledgement message until it receives a response from the SMF 205.

[0111] In step 3, after receiving the pairing / C2 revocation request / notification, the SMF 205 checks whether there is an active PDU session corresponding to the indicated SUPI for its 3GPP UAV ID / CAA-Level UAV ID with UAV-C ID. If there is an active PDU session, the SMF 205 performs a PDU session release procedure for the associated PDU session ID (see block 411), e.g. using the existing procedures of 3GPP TS 23.502, clause 4.3.4.3, with the following new adaptations:

[0112] Alternatively, after receiving a C2 cancellation request / notification message with cancellation C2 type, the SMF 205 checks whether there is an active PDU session corresponding to the indicated cancellation C2 type for the corresponding 3GPP UAV ID / CAA-Level UAV ID. If there is an active PDU session, the SMF performs a PDU session release procedure for the associated PDU session ID using the existing procedures of TS 23.502, clause 4.3.4.3 with the following new adaptations: Alternatively, the SMF 205 may delete the locally stored pairing information (pairing authorization information, paired UAV and UAV-C IDs, etc.) for the UE 401 (i.e., UAV / UAV-C) corresponding to that CAA-Level UAV ID--if available--and update the UAV pairing status information accordingly (e.g., pairing status can change from "pairing authorized" to "pairing authorization request / pairing not authorized").

[0113] In step 4a, SMF 205 sends a PDU session release command to AMF 203 containing the PDU session ID, and cause as "Pairing / C2 Cancellation" (as the new adaptation) and the 2-tuple cancellation information as "CAA-Level UAV ID, UAV-C ID" (see messaging 413). Alternatively, SMF 205 sends a PDU session release command to AMF 203 containing the PDU session ID, cause value as "Pairing / C2 Cancellation" (as the new adaptation) and cancellation information indicating the C2 type (as "USS / UTM C2" or "UAV-UAVC C2" or "TPAE C2").

[0114] It should be noted that the revocation information received from the USS / UTM server 211 may be a revocation C2 type in the format (target C2 type, value), which may include information such as "Revocation C2 type: (USS / UTM C2, USS / UTM address) or (UAVC C2, UAVC address) or (TPAE C2, TPAE address)".

[0115] In step 4b, the AMF 203 forwards a PDU Session Release command to the UE 401 (i.e., UAV and / or UAV-C) (see messaging 415) containing the PDU Session ID and (as a new adaptation) the cause as "Pairing / C2 Cancellation" and the 2-tuple Cancellation Information as "CAA-Level UAV ID, UAV-C ID". Alternatively, if the cause value is "C2 Cancellation", the Cancellation Information indicates the C2 type ("USS / UTM C2" or "UAV-UAVC C2" or "TPAE C2").

[0116] In step 5, after receiving the PDU session release command with cause as “pairing cancellation”, the UE 401 (i.e., UAV / UAV-C) deletes the pairing authorization information (token, lifetime, identifier, or any related information) and associated session security information stored locally for the UAV and UAV-C pairing indicated in the cancellation information.

[0117] Alternatively, after receiving the PDU session release command with cause as "C2 revocation", the UE401 (i.e., UAV / UAV-C) deletes the locally stored C2 authorization information (token, lifetime, identifier, or any related information) and associated session security information for the corresponding revocation type indicated in the revocation information.

[0118] Continuing to refer to Figure 4B, in step 6, the UE 401 (i.e., UAV / UAV-C) sends a PDU session release acknowledgement message to the AMF 203 by including a pairing cancellation acknowledgement indication and a CAA-Level UAV ID (see messaging 419). Alternatively, the UE 401 (i.e., UAV / UAV-C) sends a PDU session release acknowledgement message to the AMF 203 by including a C2 cancellation acknowledgement indication, a C2 type, and a CAA-Level UAV ID.

[0119] In step 7, after receiving the pairing cancellation acknowledgement indication, AMF203 deletes--if available--the locally stored pairing information (such as pairing authorization information and paired UAV and UAV-C IDs) for the UE401 (i.e., UAV / UAV-C) corresponding to that CAA-Level UAV ID and updates the UAV pairing status information accordingly (e.g., pairing status may change from "pairing authorized" to "pairing authorization requested / pairing not authorized") (see messaging 421).

[0120] Alternatively, after receiving the C2 revocation acknowledgement indication, AMF203 deletes the locally stored C2 authorization information corresponding to the C2 revocation type for the UAV related to that CAA-Level UAV ID and updates the C2 authorization status information accordingly (e.g., changing the “USS / UTM C2” or “UAV-UAVC C2” or “TPAE C2” status from “C2 Authorized” to “C2 Authorization Requested / C2 Not Authorized”).

[0121] In step 8, AMF 203 further sends a PDU session release acknowledgement message to SMF 205 with the 3GPP UAV ID, the received pairing cancellation acknowledgement indication / success indication, and the CAA-Level UAV ID (see messaging 423). Alternatively, AMF 203 sends a PDU session release acknowledgement message to SMF 205 with the 3GPP UAV ID, the received C2 cancellation acknowledgement indication / success indication, the C2 type, and the CAA-Level UAV ID.

[0122] In step 9, after receiving the pairing cancellation acknowledgement indication, the SMF 205 deletes--if available--the locally stored pairing information for the UE 401 (i.e., UAV / UAV-C) corresponding to that CAA-Level UAV ID (such as pairing authorization information and paired UAV and UAV-C IDs) and updates the UAV pairing status information accordingly (e.g., pairing status can change from "pairing authorized" to "pairing authorization requested / pairing not authorized"). In addition, the SMF 205 sends a pairing cancellation response / acknowledgement to the UAS-NF 209 with the received 3GPP UAV ID, success indication, and CAA-Level UAV ID (see messaging 425).

[0123] Alternatively, after receiving the C2 revocation acknowledgement indication, the SMF deletes the locally stored C2 authorization information corresponding to the C2 revocation type for the UAV related to that CAA-Level UAV ID and updates the C2 authorization status information accordingly (e.g., changes the "USS / UTM C2" or "UAV-UAVC C2" or "TPAE C2" status from "C2 Authorized" to "C2 Authorization Requested / C2 Not Authorized"). The SMF further sends a C2 revocation response / acknowledgement to the 3GPP NF with the 3GPP UAV ID, the success indication, the received C2 type, and the CAA-Level UAV ID.

[0124] 4A shows the messages as "Pairing / C2 Revocation Response / Acknowledgement" to better illustrate possible messages within procedure 400. Such messages may be, for example, a pairing revocation response message, a pairing revocation acknowledgement message, a C2 revocation response message, or a C2 revocation acknowledgement message.

[0125] In step 10, the UAS-NF 209 forwards the received pairing cancellation response / acknowledgement message to the USS / UTM server 211 with the received success indication, 3GPP UAV ID and CAA-Level UAV ID (see messaging 427). In addition, the UAS-NF 209 deletes the pairing authentication information stored locally for the corresponding UAV ID, if any. Alternatively, the UAS-NF forwards the received C2 cancellation response / acknowledgement message to the USS / UTM server 211 with the received success indication, C2 type, 3GPP UAV ID and CAA-Level UAV ID. Alternatively, step 10 is skipped if the UAS-NF 209 sends a pairing cancellation response / acknowledgement message to the USS / UTM server 211 while already in step 2b. The procedure 400 ends.

[0126] Applicability to EPS: The UAS / C2 pairing cancellation procedure 400 shown in Figures 4A-4B and described in this section may be applicable to EPS with adaptations of using MME instead of AMF 203, SGW+PGW-C instead of SMF 205, and HSS / AuC instead of UDM 207. In EPS deployment, UAS-NF 209 may be replaced by another 3GPP NF / UFES that can perform the role of UAS-NF 209 or as a UAS control function in the 3GPP network. The 3GPP NF / UFES may be a standalone network function or a service provided by SCEF+NEF in EPS instead of NEF in 5GS.

[0127] The second solution focuses on two key aspects: (i) USS / UTM initiated authorization / re-authorization and (ii) providing 3GPP NF routing information (e.g., UFES routing information) by the 3GPP NF to the USS / UTM during UAS authentication / authorization (UAS AA / UAA / UUAA) procedures to facilitate the USS / UTM to reach the appropriate 3GPP NF handling the UAV / UAV-C (or holding UAV / UAV-C related UAS information) during re-authorization or for USS / UTM initiated procedures such as UUAA revocation, pairing authorization revocation, pairing authorization update, etc.

[0128] 5A-5B show a procedure 500 for a UAS-NF to provide 3GPP routing information to a USS / UTM during a UUAA procedure according to an embodiment of the second solution. The procedure 500 may be used by the USS / UTM to send a UAV / UAV-C related UAS re-authentication and authorization or pairing authorization (or re-authentication / revocation) request at a later time. The procedure 500 involves a UE 201 (e.g., embodied in a UAV), an AMF 203, a UDM / UDR 501 (e.g., may be an embodiment of a UDM / UDR 149), a UAS-NF 209, and a USS / UTM server 211. In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAV / UAV-C related UAS operational message exchanges with a corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps involved in procedure 500 are described as follows:

[0129] 5A, in step 1, the UE 201 (i.e., UAV) performs a primary authentication with the 3GPP 5G network (see block 505). Following successful primary authentication, the UE 201 (i.e., UAV) is requested to provide its UAV ID to initiate a UAA (i.e., UUAA), and the UAV provides its CAA-Level UAV ID (see messaging 507).

[0130] In step 2, after successful primary authentication, the AMF 203 provides the CAA-Level UAV ID to the UDM 207 and fetches the UE's subscription information (e.g., UE / UAV aerial subscription) and the 3GPP UAV ID associated with the SUPI (see messaging 509). Further, based on the UE subscription information, the AMF 203 sends a UAS AA request to the UAS-NF 209, where the UAS AA request includes the SUPI, the 3GPP UAV ID (i.e., GPSI), and the CAA-Level UAV ID along with other information.

[0131] Alternatively, the UE 201 sends a PDU session establishment request to the SMF (via the AMF) after a successful primary authentication with the air payload, which then causes the SMF to send the above UAS AA request including, for example, the SUPI, the 3GPP UAV ID, and the CAA-Level UAV ID along with other information to the UAS-NF 209. Alternatively, the UAS AA request shown in step 2 may also include the AMF ID and / or the SMF ID.

[0132] In step 3, the UAS-NF 209 stores the received SUPI along with the received CAA-Level UAV ID and the 3GPP UAV ID. Furthermore, the UAS-NF 209 sends a UAS AA request (i.e., a UUAA request) to the USS / UTM server 211 by including 3GPP NF routing information (i.e., UFES / UAS-NF routing information, such as a fully qualified domain name ("FQDN") or IP address or ID of the UFES / UAS-NF that uniquely identifies a 3GPP NF located within the 3GPP network that handles UAV / UAV-C related message exchanges (i.e., messages related to UUAA, pairing, etc.) with the corresponding external USS / UTM) (see messaging 511).

[0133] Alternatively, if the UAS-NF 209 does not receive the 3GPP UAV ID, it fetches the 3GPP UAV ID / GPSI from the UDM / UDR 503 by providing the SUPI. The UAS-NF 209 may construct the 3GPP UAV ID by using the GPSI and the 3GPP NF address / routing information. Alternatively, the UAS-NF 209 stores the received AMF ID / SMF ID.

[0134] In step 4, the USS / UTM server 211 performs UUAA together with the UE 201 (i.e., UAV) and the UAV-C (see block 513). After the UUAA procedure is successful, the UE 201 (i.e., UAV) and the USS / UTM server 211 establish a connection on the 3GPP network.

[0135] In step 5, the USS / UTM server 211 locally stores the CAA-Level UAV ID and the 3GPP UAV ID (e.g., GPSI) along with the corresponding 3GPP NF routing information received in step 3 (see block 515).

[0136] In step 6, the USS / UTM server 211 may optionally perform any UAA revocation or pairing authorization and revocation when necessary (see block 517).

[0137] In step 7, if the USS / UTM server 211 decides to perform re-authentication and re-authorization of the UE 201 (i.e., the UAV) or pairing re-authorization for the UAV / UAV-C pair, the USS / UTM server 211 may send a re-authentication (i.e., re-UUAA) or pairing re-authorization / authorization request (alternatively, a UUAA revocation or pairing revocation request) using locally stored 3GPP NF routing information corresponding to the CAA-Level UAV ID and / or 3GPP UAV ID (see block 519).

[0138] Continuing to refer to FIG. 5B, in step 8, the USS / UTM Server 211 sends a UAS re-authentication / authorization request (i.e., UUAA re-authentication request) (as identified in the locally stored 3GPP NF routing information) to the UAS-NF 209 (see messaging 521) by including the 3GPP UAV ID (i.e., GPSI), CAA-Level UAV ID, and a cause indicating “UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change”.

[0139] In conditional step 9, after receiving the UAS re-authentication / authentication request, the UAS-NF 209 forwards the UAS re-authentication request to the Serving AMF 203 (and / or the Serving SMF) using the locally stored Serving AMF identity and / or Serving SMF identity corresponding to the CAA-Level UAV ID and / or 3GPP UAV ID (i.e., the UAS-NF 209 retrieves the UE / UUAA context corresponding to the CAA-Level UAV ID and / or 3GPP UAV ID). If the UAS-NF 209 does not have locally stored Serving AMF / SMF information for the UE 201 (i.e., the UAV), a Nudm_UECM_Get request / response service operation may be used to fetch the Serving AMF / SMF information for the UE 201 (i.e., the UAV) (see messaging 523).

[0140] In step 10, the UAS-NF 209 sends the received UAS re-authentication / authorization request to the Serving AMF 203 (and / or Serving SMF) with the 3GPP UAV ID, CAA-Level UAV ID, and a cause value with "UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change" (see messaging 525). Alternatively, the UAS re-authentication request may also include re-authorization data, and in case of pairing re-authorization, the UAS re-authentication request may also include the target pairing ID (e.g., new UAV-C information and / or Third Party Accreditation Authority ("TPAE") information, etc.). Alternatively, in case of pairing re-authorization, the message name may be "Pairing Re-Authorization" or "Pairing Update Request".

[0141] In step 11, after receiving the UAS re-authentication / authorization request, the AMF 203 (and / or the SMF) triggers to perform UUAA or pairing authorization (or re-authorization) (see block 527). Alternatively, the SMF sends the received UAS re-authentication / authorization request to the Serving AMF 203 with the 3GPP UAV ID, CAA-Level UAV ID, re-authorization data, and a cause value with "UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change".

[0142] Alternatively, the SMF initiates the PDU session modification procedure by sending the received UAS re-authentication / authorization request to the Serving AMF 203 with the 3GPP UAV ID, CAA-Level UAV ID, re-authorization data, and cause value with "UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change".

[0143] In step 12, the AMF 203 sends a NAS MM transport message to the UE 201 (i.e., UAV) and / or UAV-C by including a UAV ID request, a UAS AA request indication, slice information, and a cause value indicating “UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change” (see messaging 529).

[0144] Alternatively, AMF203 sends a PDU session modification message to UE201 (i.e., UAV) with a pairing authorization (or pairing re-authorization) indication, the received re-authorization data, and a cause value indicating "UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change".

[0145] In step 13a, if a UAS AA request indication is received, the UE 201 (i.e., UAV) and / or UAV-C performs UUAA with the USS / UTM server 211 on the 3GPP network (see block 531). Alternatively, in step 13b, the UE 201 performs PDU session modification if a pairing re-authorization indication is received with re-authorization data and a cause value indicating "UAS AA / C2 re-authentication or pairing re-authorization or UAV-C change" (see block 533).

[0146] Alternatively, if in step 13b a pairing authorization indication is received with authorization data and a cause value indicating "Pairing / C2 Authorized", the UE 201 (i.e., UAV) updates the locally stored pairing authorization information with the received new authorization (or re-authorization) information and performs the PDU session establishment / modification. The procedure 500 ends. Although Figures 5A-5B depict a UE embodied in a UAV and are described in the above description, the procedure 500 may also be implemented using a UE embodied in a UAV-C. In such an embodiment, the various IDs exchanged may be specific to the UAV-C.

[0147] Alternative option for UAS-NF discovery: The NEF (e.g., NEF 146) may store the 3GPP UAV ID and the corresponding 3GPP NF routing information (i.e., the address, e.g., FQDN or IP address, of the UAS-NF 209 or UFES) after step 2. Then, in step 8, if the NEF receives any request message (e.g., a revocation or re-authorization request for any UAV / UAV-C) from the USS / UTM Server 211 with the 3GPP UAV ID, the NEF fetches the locally stored 3GPP NF routing information for the corresponding 3GPP UAV ID, which routes / sends the received request message to the corresponding UAS-NF 209 for processing the UAS-related request message for the UAV / UAV-C. Alternatively, the UAS-NF 209 may send the 3GPP NF routing information to the USS / UTM Server 211 in any UAV-related message exchange.

[0148] Applicability to EPS: The re-authorization procedure 500 shown in Figures 5A-5B and described in this section may be applicable to EPS with adaptations of using MME instead of AMF 203, using SGW+PGW-C instead of SMF, and using HSS / AuC instead of UDM 207. In EPS deployment, UAS-NF 209 may be replaced by another 3GPP NF / UFES that can perform the role of UAS-NF 209 or as a UAS control function in the 3GPP network. The 3GPP NF / UFES may be a standalone network function or may be a service provided by SCEF+NEF in EPS instead of NEF in 5GS.

[0149] The third solution describes a control plane based UAV / UAV-C pairing / association authorization method in subsection A, and a user plane based UAV / UAV-C pairing / association authorization method in subsection B. The third solution focuses on: a. Verification of the pairing authorization status stored locally in the 3GPP network by the AMF (or any 3GPP NF) before invoking an authorization request (i.e., a pairing authorization request) to the UAV / UAV-C with the USS / UTM. b. Verification of pairing authorization status / information stored locally in the 3GPP network by the SMF before establishing a PDU session (pairing-based C2 communication) to the UAV / UAV-C in response to a received PDU session establishment request. c. 3GPP NFs (i.e., AMF and SMF) receiving session security information from the USS / UTM (via UAS-NF / NEF / UFES) after successful pairing authentication, and sending the received session security information to the UAV / UAV-C (in a PDU session establishment accept message).

[0150] Applicability to EPS: The pairing authorization procedure shown in Figures 6A-6C and 7A-7C and described in this section may be applicable to EPS with adaptations of using MME instead of AMF 203, using SGW+PGW-C instead of SMF, and using HSS / AuC instead of UDM / UDR. In EPS deployment, UAS-NF may be replaced by another 3GPP NF / UFES that can perform the role of UAS-NF or as UAS control function in 3GPP network. 3GPP NF / UFES may be a standalone network function or may be a service provided by SCEF+NEF in EPS instead of NEF in 5GS.

[0151] 6A-6C show a procedure 600 for UAV and UAV-C pairing / association authorization on the control plane and related security setup according to the third solution. As depicted, the procedure 600 involves a UAV-C 601 (i.e., an embodiment of a UAV-C 108 including a UE), a UAV 603 (i.e., an embodiment of a UAV 106 including a UE), an AMF and corresponding (e.g., co-located) Security Anchor Function ("SEAF") depicted as a combined node "AMF / SEAF" 605, the SMF 205, the UAS-NF 209, and a USS / UTM server 211. In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAS operational message exchanges related to the UAV / UAV-C with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps of the procedure 600 are described as follows:

[0152] Starting with Figure 6A, it is assumed as a prerequisite that UAV 603 and UAV-C 601 are registered in the 3GPP network (see blocks 611 and 613) and that both UAV 603 and UAV-C 601 have successfully performed UAS authentication and authorization with USS / UTM server 211 (see blocks 615 and 617). Although Figure 6A illustrates that 3GPP registration and PDU session establishment of UAV-C 601 occurs before 3GPP registration and PDU session establishment of UAV 603, UAV 603 may register and / or establish a PDU session before UAV-C 601--or registration and / or PDU session establishment may both occur in parallel / simultaneously. 6A illustrates UAS authentication and authorization of UAV-C 601 occurring before UAS authentication and authorization of UAV 603, the authorization / authorization of UAV 603 may occur before the authorization / authorization of UAV-C 601--or UAS authentication and authorization may occur in parallel / simultaneously for both devices. Alternatively, UAV-C 601 may be connected to the USS / UTM server 211 over the Internet, rather than over a 3GPP network as shown.

[0153] In step 1, UAV603 sends a PDU session establishment request to AMF / SEAF605 with pairing authorization request information (see messaging 619), where the pairing authorization request information includes UAV ID, target UAV-C ID, UAS ID, UAV authorization token, and UAS security information identifier (i.e., the identifier received during UAS authentication from USS / UTM server 211 to uniquely identify the UAS security information established between UAV603 and USS / UTM server 211).

[0154] Alternatively, in step 1, the UAV 603 also sends a pairing request indication. It should be noted that throughout the description of the third solution, the information sent as "pairing permission request information" may also be sent as part of the UAV operation request / payload. Similarly, throughout the description of the third solution, the information sent as "pairing permission response information" may also be sent as part of the UAV operation response information and / or the UAV operation accept message.

[0155] In step 2, after receiving the pairing request indication, AMF / SEAF605 checks whether the UAV-ID is authorized to request pairing authorization, for example, based on the received pairing authorization request information and the locally stored UAS authentication and authorization results, authorization information (token) and UAV-C ID (if available) (see block 621). If both the received pairing authorization request information and the locally stored information match, AMF / SEAF605 considers this check successful.

[0156] Alternatively, if the check is not successful (i.e., if the received pairing authorization request information does not match the locally stored information), AMF / SEAF605 sends a failure message to UAV603, for example in a PDU session establishment failure response.

[0157] In step 3, the AMF / SEAF 605 sends a pairing authorization request to the UAS-NF 209 (see Messaging 623). Alternatively, the AMF / SEAF 605 forwards the received PDU session establishment request to the SMF 205 with a pairing request indication and pairing authorization request information, where the pairing authorization request information includes the UAV ID, the target UAV-C ID, the UAS ID, the UAV authorization token, and the UAS security information identifier (i.e., the identifier received during UAS authentication from the USS / UTM server 211 to uniquely identify the UAS security information established between the UAV 603 and the USS / UTM server 211).

[0158] After receiving the pairing request indication, the SMF 205 checks whether the UAV-ID is authorized to request pairing authorization, for example, based on the received pairing authorization request information and the locally stored UAS authentication and authorization results, authorization information (token) and UAV-C ID (if available). If the received pairing authorization request information matches the locally stored information, the SMF 205 considers this check successful. Further, the SMF 205 sends a pairing authorization request to the UAS-NF 209, where the request includes the UAV ID, the target UAV-C ID, the UAS ID, the UAV authorization token, the UAV IP address (i.e., set by the SMF for the PDU session), and the UAS security information identifier.

[0159] Alternatively, if the check is not successful (i.e., if the received pairing authorization request information does not match the locally stored information), the SMF205 sends a failure message to the UAV603 via the AMF / SEAF605, for example in a PDU session establishment failure response.

[0160] In step 4, the UAS-NF 209 sends the received pairing authorization request to the USS / UTM server 211, said request including the UAV ID, the target UAV-C ID, the UAS ID, the UAV authorization token, the UAV IP address, and the UAS security information identifier (see messaging 625).

[0161] 6B, in step 5, the USS / UTM server 211 verifies the information received in the received pairing authorization request with the locally stored information, and if the verification is successful, the USS / UTM server 211 decides to perform pairing for the UAV 603 (see block 627). Alternatively, if the UAV-C 601 is a non-network connected UAV-C (i.e., a UAV-C connected to the USS / UTM server 211 using a connection outside the 3GPP network), steps 6-8 are skipped and only step 9 is performed.

[0162] In step 6, the USS / UTM server 211 sends a pairing authorization request (e.g., via a 3GPP network or over the Internet) to the UAV-C 601, identified by the UAV-C ID, the request including the UAV ID, the UAV-C ID, and the UAS ID (see messaging 629).

[0163] In step 7, in response, UAV-C 601 sends a pairing authorization response message to the USS / UTM server 211, the response message including the UAV-C ID, UAS ID, UAV-C IP address, and UAV-C authorization token (see messaging 631).

[0164] In step 8, the USS / UTM server 211 checks the received information, such as the UAV-C ID, UAS ID, and UAV-C authorization token received in the pairing authorization response message against locally stored information for verification (see block 633). If the received authorization information matches the locally stored information, the USS / UTM server 211 considers the UAV-C pairing authorization successful.

[0165] In step 9, the USS / UTM server 211 sends a pairing authorization acknowledgement message (alternatively, a pairing authorization complete or pairing authorization notification message) to the UAV-C 601, the message including a pairing success indication, UAV ID, UAV-C ID, UAS ID, UAV IP address, and session security information (i.e., key material or token for setting up session security) (see messaging 635).

[0166] In step 10, the USS / UTM server 211 further sends a pairing authorization response message (alternatively, a pairing authorization accept message) to the UAS-NF 209 in response to receiving the pairing authorization request message (e.g., step 4) (see messaging 637). The pairing authorization response / accept message includes a pairing success indication, the UAV ID, the UAV-C ID, the UAS ID, the UAV-C IP address, and session security information (i.e., key material or token for setting up session security).

[0167] 6C, in step 11, the UAS-NF 209 sends the received pairing authorization response / acceptance message to the AMF / SEAF 605 (see messaging 639), where the pairing authorization response / acceptance message includes a pairing success indication, the UAV ID, the UAV-C ID, the UAS ID, the UAV-C IP address, and session security information (i.e., key material or token for setting up session security).

[0168] Alternatively, the UAS-NF 209 sends the received pairing authorization response / acceptance message to the SMF 205. Again, the pairing authorization response / acceptance message includes a pairing success indication, the UAV ID, the UAV-C ID, the UAS ID, the UAV-C IP address, and session security information (i.e., key material or token for setting up session security). In this alternative case, the procedure 600 is modified to skip steps 12-14 and perform the alternative steps described below for step 15.

[0169] In step 12, the AMF / SEAF605 locally stores the UAV ID and UAV-C ID in addition to the corresponding 3GPP UAV ID of the UAV603 along with the pairing permission status and the UAS ID (see block 641).

[0170] In step 13, the AMF / SEAF 605 sends a Nsmf_PDUSession_CreateSMContext request message containing a pairing request indication with the UAV ID and the UAV-C ID to the SMF 205 with a "pairing allowed successful" indication (see messaging 643). In addition, this message may also contain the UAV-C IP address if it was received from the USS / UTM server 211.

[0171] In step 14, the SMF 205 locally stores the UAV ID, UAV-C ID, pairing permission status information, PDU session ID, and UAV IP address and UAV-C IP address, and performs N4 session setup for the paired UAV 603 and UAV-C 601 (see block 645).

[0172] In step 15, the SMF 205 sends a Nsmf_PDUSession_CreateSMContext response message to the AMF / SEAF 605, which includes a pairing authorization success indication and a pairing indication with the UAV ID and UAV-C ID (see messaging 647).

[0173] In the alternative case described above, after step 11, upon receiving the pairing authorization response / pairing authorization accept message, the SMF 205 locally stores the UAV ID, the UAV-C ID, the pairing authorization status information, the PDU session ID, and the UAV and UAV-C IP addresses. Furthermore, the SMF 205 performs an N4 session setup for the paired UAV 603 and UAV-C 601. In addition, the SMF 205 sends a Nsmf_PDUSession_CreateSMContext response (alternatively, a PDU session establishment response) to the AMF / SEAF 605 (see messaging 647) including the pairing authorization success indication, session security information, UAS ID, and pairing indication received with the UAV ID and UAV-C ID.

[0174] In step 16, the AMF / SEAF 605 sends a PDU session establishment accept message to the UAV 603 over the N1 interface (see messaging 649), where the PDU session establishment accept message includes a pairing authorization success indication, a UAV ID, a UAV-C ID, a UAS ID, and session security information.

[0175] In step 17, the UAV 603 and UAV-C 601 use the received session security information to set up a secure session between the UAV 603 and UAV-C 601 for the C2 connection over the established PDU session (see block 651). The procedure 600 ends.

[0176] 7A-7C show an example procedure 700 for C2 / pairing authorization on the user plane by the USS / UTM and result notification according to an embodiment of the third solution. This section describes UAV / UAV-C pairing authorization on the user plane and describes pairing authorization results provided to the 3GPP network by the USS / UTM via the UAS-NF.

[0177] As depicted, procedure 700 involves a UE 701 (e.g., an embodiment of a remote unit 105 included within a UAV 106), a UE 711 (e.g., an embodiment of a remote unit 105 included within a UAV-C 108), a first AMF and / or SMF serving the UE 701 (depicted as a combined node "AMF / SMF#1" 703), a first UAS-NF serving the UE 701 (depicted as "UAS-NF#1" 705), a second UAS-NF serving the UE 701 (depicted as "UAS-NF#2" 707), a second AMF and / or SMF serving the UE 711 (depicted as a combined node "AMF / SMF#2" 709), and a USS / UTM server 211. In some embodiments, UAS-NFs 705 and 707 may be replaced with another 3GPP NF that handles UAS operational message exchanges related to UAVs / UAV-Cs with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, NEF, or another suitable NF in the 3GPP network.

[0178] Although in Figures 7A-7C the UAV is depicted as connecting to the USS / UTM server 211 via a separate 3GPP network than that used by the UAV-C, in other embodiments the UAV and UAV-C connect to the USS / UTM server 211 via the same 3GPP network. In such embodiments, the AMF / SMF#1 703 and the AMF / SMF#2 709 are the same entity, as are the UAS-NF#1 705 and the UAS-NF#2 707. In yet another embodiment, the UAV-C (i.e., of the UE 711) is a "non-network attached" UAV-C, and the UAV-C connects to the USS / UTM server 211 using a connection outside of the 3GPP network. The steps involved in the procedure 700 are described as follows:

[0179] 7A, it is assumed as a prerequisite that the UE 701 (i.e., embodied in a UAV) and the UE 711 (i.e., embodied in a UAV-C) perform primary authentication and UUAA with the USS / UTM server 211 (see blocks 715 and 717). Furthermore, the UE 701 (i.e., UAV) and the UE 711 (i.e., UAV-C) have an established PDU session with the USS / UTM server 211, and thus when C2 or UAV / UAV-C pairing is requested, the UE 701 (i.e., UAV) and also the UE 711 (i.e., UAV-C) can perform pairing authorization with the USS / UTM server 211 on the established PDU session (i.e., on the established user plane connection) (see blocks 719, 721, and 723). Although FIG. 7A illustrates that primary authentication, PDU session establishment, and UAS authentication and authorization of UE701 occur before the corresponding procedures of UE711, UAV603 may register and / or establish a PDU session before UAV-C601--or registration and / or PDU session establishment may both occur in parallel / simultaneously.

[0180] Although Figure 7A illustrates that primary authentication of UE 701 occurs before primary authentication of UE 711, UE 711 may perform primary authentication of UE 701--or both primary authentications may occur in parallel / simultaneous. Similarly, although Figure 7A illustrates that UAS authentication and PDU session establishment of UE 701 occurs before UAS authentication and PDU session establishment of UE 711, UAS authentication and PDU session establishment of UE 711 may occur before UAS authentication and PDU session establishment of UE 701--or UAS authentication and authorization may occur in parallel / simultaneous for both devices.

[0181] The USS / UTM server 211 still needs to inform the 3GPP network (e.g., UAS-NF 705 / 707 and / or AMF / SMF 703 / 709) regarding the result of the UAV / UAV-C pairing authorization so that the 3GPP network can take the UAV / UAV-C pairing authorization result into account before accepting any related (i.e., pairing or C2 related) PDU session establishment request from the UAV / UAV-C or accepting any C2 connection / traffic routing between UE 701 (i.e., UAV) and UE 711 (i.e., UAV-C).

[0182] In step 1, the UE 701 (i.e., UAV) sends a PDU session establishment request to the AMF / SMF#1 703 (see messaging 725), including a C2 / pairing request indication, a UAV ID, a UAV-C ID, a UAS ID, and an authorization token. In an alternative, a PDU session modification request may be sent in step 1. The UAS ID may be an identifier assigned by the USS / UTM server 211 (e.g., after successful UAV-UAV-C pairing authorization) to indicate the UAV and UAV-C pair in combination. In some embodiments, the USS / UTM server 211 may provide the UAS ID to the UE 701 (i.e., UAV) at any time during UUAA or pre-configuration (if any), even before pairing authorization is performed.

[0183] In step 2, AMF / SMF#1 703 checks the locally stored pairing authorization status using the received UAV ID (see block 727). If the pairing authorization status with "success indication" and "session security information" is stored locally and the received authorization token matches the locally stored authorization information (e.g., token), PDU session establishment is performed (see steps 8-10). However, if there is no locally stored pairing authorization status in AMF / SMF#1 703--or if the pairing authorization status indicates "failed or required", AMF / SMF#1 703 performs the C2 / pairing authorization procedure including steps 3-7.

[0184] In step 3, AMF / SMF#1 703 sends a C2 / pairing information request to UAS-NF#1 705 (see messaging 729), the request including the received UAV ID, authorization token, UAV-C ID, and UAS ID.

[0185] In step 4, UAS-NF#1 705 sends the received C2 / pairing information request (see messaging 731) to the USS / UTM server 211, said request including the received UAV ID, authorization token, UAV-C ID, UAS ID, and 3GPP UAV ID / GPSI. The received C2 / pairing information request triggers the USS / UTM server 211 to retrieve and / or obtain information for the UAV-C identified in the C2 / pairing information request (e.g., UAV-C IP address).

[0186] Note that if the UE 711 (i.e., UAV-C) has already performed steps 1-10 similar to the UE 701 (i.e., UAV), the USS / UTM server 211 can provide the UAV-C IP address to the UAS-NF#1 705 in step 6 (see block 733). Alternatively (option 1), for a UE 711 (i.e., UAV-C) that is not connected to the USS / UTM server 211 via a 3GPP network, the UAV-C IP address becomes available to the USS / UTM server 211 immediately after UAS authentication and pairing authorization is performed over an Internet connection (i.e., outside the 3GPP network).

[0187] Alternatively (option 2), the USS / UTM server 211 may trigger a network-initiated PDU session establishment for C2 after successful pairing authorization on the user plane (within PDU session 1) (see block 735).

[0188] Alternatively (option 3), if the USS / UTM server 211 finds that the UE 711 (i.e., UAV-C) is not connected / active with the USS / UTM server 211, the USS / UTM server 211 may perform a device trigger (see block 737) to perform a network-initiated PDU session establishment (as described below in the fourth solution) with C2 in step 5. In this case, steps a-i are performed.

[0189] 7B, in step 5, the USS / UTM server 211 checks the locally stored C2 / pairing status and result information (see messaging 739). If the pairing authorization result is available and is successful (i.e., UE 701 (i.e., UAV) and UE 711 (i.e., UAV-C) have already performed pairing authorization on the user plane as described in the prerequisites), the USS / UTM server 211 performs step 6.

[0190] In step 6, the USS / UTM server 211 sends a C2 pairing response / notification message to UAS-NF#1 705, which includes the 3GPP UAV ID (i.e., GPSI), UAV ID, pairing authorization success indication, UAV-C IP address (if available), and session security information (see messaging 741).

[0191] In step 7, UAS-NF#1 705 forwards the received C2 pairing response / notification message to AMF / SMF#1 703, which includes the 3GPP UAV ID (i.e., GPSI), UAV ID, pairing authorization success indication, UAV-C IP address (if available), and session security information (see Messaging 743).

[0192] In step 8, the AMF / SMF#1 703 performs a PDU session establishment procedure, i.e., involving UPF allocation and IP address allocation for the UE 701 (i.e., the UAV) (see messaging 745). Furthermore, the AMF / SMF#1 703 locally stores the UAV ID, the corresponding GPSI and UAV ID address, and the UAV-C IP address (if received).

[0193] In step 9, if the AMF / SMF#1 703 has not provided the USS / UTM Server 211 with a static IP address for the UE 701 (i.e., the UAV) (i.e., in steps 3-4), the AMF / SMF#1 703, after IP address allocation, sends the UAV IP address to the USS / UTM Server 211 in a C2 pairing acknowledgement message via UAS-NF#1 705 (see messaging 747).

[0194] In step 10, the AMF / SMF#1 703 sends a PDU session establishment accept message to the UE 701 (i.e., UAV) with the session security information and pairing authorization success indication (see messaging 749). The AMF / SMF#1 703 also locally updates and stores the pairing authorization status with the pairing authorization success indication and pairing information by the UE 701 (i.e., UAV) and their IP addresses corresponding to the UAV-C ID, UAV ID and 3GPP UAV ID.

[0195] Referring to the right side of FIG. 7B, in step (a), the USS / UTM server 211 sends a C2 / pairing notification request message to UAS-NF#2 707, which includes the 3GPP UAV-C ID (i.e., GPSI), UAV-C ID, UAV ID, UAS ID, pairing authorization request indication / pairing authorized indication, and session security information (see messaging 751).

[0196] In step (b), UAS-NF#2 707 performs device triggering based on the fourth solution (described in further detail below) to trigger network-initiated PDU session establishment for the dedicated C2. UAS-NF#2 707 sends the received C2 / pairing notification request message to AMF / SMF#2 709, which includes the 3GPP UAV-C ID (i.e., GPSI), UAV-C ID, UAV ID, UAS ID, pairing authorization request indication / pairing authorized indication, and session security information (see messaging 753).

[0197] In step (c), AMF / SMF#2 709 locally stores the pairing permission status based on, for example, the information received in step (b) (see messaging 755).

[0198] In step (d), AMF / SMF#2 709 receives a PDU session establishment request from UE 711 (i.e., UAV-C), which message includes a C2 / pairing request indication, UAV-C ID, authorization token, UAV ID and UAS ID (see messaging 757).

[0199] In step (e), AMF / SMF#2 709 checks whether the corresponding pairing authorization status is stored locally for the received UAV-C ID (see block 759). If the pairing authorization status with "success indication" and "session security information" is stored locally and the received authorization token matches the locally stored authorization information (e.g., token), AMF / SMF#2 709 performs step (f).

[0200] 7C, in step (f), the AMF / SMF#2 709 performs a PDU session establishment procedure, i.e., involving UPF allocation and IP address allocation for the UE 711 (i.e., UAV-C) (see block 761). Additionally, the AMF / SMF#2 709 locally stores the UAV ID, the corresponding GPSI, and UAV ID address, and the UAV-C IP address received in step (d).

[0201] In step (g), the AMF / SMF#2 709 sends a PDU session establishment accept message to the UE 711 (i.e., UAV-C) with session security information and a pairing authorization success indication (see messaging 763).

[0202] In step (h), AMF / SMF#2 709 sends a C2 pairing acknowledgement message to the USS / UTM server 211 via UAS-NF#2 707, which message includes the UAV-C ID, the 3GPP UAV-C ID, and the UAV-C IP address (see messaging 765).

[0203] In step (i), the USS / UTM server 211 sends a C2 pairing complete message to the AMF / SMF#2 709 via the UAS-NF#2 707, said pairing complete message including the UAV IP address (see messaging 767).

[0204] Now referring to the left side of FIG. 7C, in step 11, the USS / UTM server 211 sends a C2 pairing complete message to the AMF / SMF#1 703 via the UAS-NF#1 705, which includes the GPSI, UAV ID and UAV-C IP address of the UE 701 (i.e., the UAV) (see messaging 769).

[0205] In step 12, the UE 701 (i.e., UAV) and the UE 711 (i.e., UAV-C) use the received session security information to set up a secure session between the UE 701 (i.e., UAV) and the UE 711 (i.e., UAV-C) for the C2 connection (see block 771). The procedure 700 ends.

[0206] According to a first variant of the third solution, authorization of the UAV and UAV-C pairing may be performed by the USS / UTM (after successful primary authentication and during / after successful UAS authentication) when the UAV initiates a PDU session establishment to establish a C2 connection with the UAV-C to enable UAS services.

[0207] It is assumed that the UAV and UAV-C have already successfully performed UAS registration to the USS / UTM (having UAS authorization and security information provided by the USS / UTM). The UAV shall include pairing authorization request information, including the UAV-C ID, authorization token, UAS ID, and security context ID in addition to the CAA-level UAV ID, in a PDU session establishment request message to the SMF together with the UAV operation request, and the SMF can send the UAV operation request together with the received pairing authorization request information to the UFES, which forwards it to the USS / UTM. The procedure for the UAV operation request can be based on the agreement from SA2 23.754.

[0208] After receiving the pairing authorization request information along with the UAV operation request, the USS / UTM can trigger the next UAV and UAV-C pairing authorization and session security setup procedure. Pairing authorization may also be called C2 association authorization. In this solution, UAV-C information (i.e., UAV-C ID) that the UAV can use to form a UAS is considered available in the USS and may be pre-deployed in the UAV along with the provision of CAA-level UAV ID (outside the scope of 3GPP) as a prerequisite.

[0209] 8A-8B depict an exemplary procedure 800 of UAV and UAV-C pairing authorization and session security setup according to a first variation of the third solution. As depicted, the procedure 800 involves a UAV-C 801 (i.e., an embodiment of a UAV-C 108 including a UE), a UAV 803 (i.e., an embodiment of a UAV 106 including a UE), an AMF depicted as a combined node "AMF / SEAF" 805 and a corresponding (e.g., co-located) Security Anchor Function ("SEAF"), the SMF 205, the UAS-NF 209, and a USS / UTM server 211. In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAS operational message exchanges related to the UAV / UAV-C with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps of the procedure 800 are as follows:

[0210] Starting with Figure 8A, as prerequisites, UAV 803 and UAV-C 801 are registered with the 3GPP network (see blocks 811 and 813), and both UAV 803 and UAV-C 801 have successfully performed UAS authentication and authorization (e.g., UUAA) with the USS / UTM server 211 and established a PDU session with the USS / UTM server 211 (see blocks 815 and 817). Although Figure 6A illustrates that the 3GPP registration and PDU session establishment of UAV-C 601 occurs before the 3GPP registration and PDU session establishment of UAV 603, UAV 603 may register and / or establish a PDU session before UAV-C 601--or registration and / or PDU session establishment may both occur in parallel / simultaneously. Similarly, although Figure 6A illustrates UAS authentication and authorization of UAV-C 601 occurring before UAS authentication and authorization of UAV 603, authorization / authorization of UAV 603 may occur before authorization / authorization of UAV-C 601--or UAS authentication and authorization may occur in parallel / simultaneously for both devices. Alternatively, UAV-C 801 may be connected to the USS / UTM server 211 over the Internet or another data network outside the 3GPP network.

[0211] In step 1, UAV 803 sends a PDU session establishment request to AMF / SEAF 805 with pairing authorization request information (see messaging 819). The pairing authorization request information includes UAV ID, target UAV-C ID, UAS ID, UAV authorization token (i.e., received during UUAA success from USS / UTM server 211), and UAS security context / information identifier (i.e., received during UUAA success from USS / UTM server 211 to uniquely identify the UAS security context established between UAV 803 and USS / UTM server 211).

[0212] In step 2, after receiving the PDU session establishment request with the pairing authorization request information, AMF / SEAF805 checks whether the UAV-ID is authorized to request pairing authorization based on, for example, the locally stored UAS authentication and authorization result, the authorization information (i.e., token), and the UAV-C ID (if available) (see block 821). If the received pairing authorization request information matches the locally stored information, AMF / SEAF805 considers this check successful and executes step 3. However, if AMF / SEAF805 does not find the UAS authentication result, or if the locally stored authentication result or the authorization information does not match the received authorization information, AMF / SEAF805 triggers UUAA and / or sets "authorization information mismatch indication" as described in the fourth solution.

[0213] In step 3, the AMF / SEAF 805 sends a Nsmf_PDUSession_CreateSMContext request to the SMF 205 with the received pairing authorization request information, including UAV ID, target UAV-C ID, UAS ID, UAV authorization token, and UAS security information identifier (see messaging 823). If an authorization mismatch is identified, an "authorization information mismatch indication" is also sent.

[0214] 8B , in step 4, SMF205 sends the received pairing authorization request (e.g., in a Service Action message) to UAS-NF209 (see messaging 825), where the request includes the UAV ID, target UAV-C ID, UAS ID, UAV authorization token, and UAS security information identifier along with the GPSI and UAV IP address of UAV803. If SMF205 receives an "authorization information mismatch indication", it sends a PDU session establishment reject message to AMF / SEAF805 in an N1SM container, and AMF / SEAF805 sends a PDU session establishment reject message to the UE of UAV803.

[0215] In step 5, the UAS-NF 209 sends the received pairing authorization request (e.g., in a service operation message) to the USS / UTM server 211 (see messaging 827), said request including the UAV ID, target UAV-C ID, UAS ID, UAV authorization token, UAS security information identifier along with the UAV GPSI and UAV IP address.

[0216] In step 6, the USS / UTM server 211 verifies the information received in the received pairing authorization request with the locally stored information (see block 829). If the verification is successful, the USS / UTM server 211 decides to authorize pairing for the UAV 803. Optionally, if the UAV-C 801 is connected to the USS / UTM server 211 over the Internet, steps 7 to 10 may be skipped and only step 10 is performed.

[0217] In step 7, the USS / UTM server 211 sends a pairing authorization request (e.g., via a 3GPP network or over the Internet) (see messaging 831) to the UAV-C 801, identified by the UAV-C ID, the request including the UAV ID, the UAV-C ID, and the UAS ID.

[0218] In step 8, in response, UAV-C 801 sends a pairing authorization response message to the USS / UTM server 211 (see messaging 833), which response message includes the UAV-C ID, UAS ID, UAV-C IP address, and UAV-C authorization token.

[0219] In step 9, the USS / UTM server 211 verifies the information received in the pairing authorization response message, such as the UAV-C ID, UAS ID, and UAV-C authorization token, for example against locally stored information (see block 835). If the received authorization information matches the locally stored information, the USS / UTM server 211 considers the UAV-C pairing authorization successful.

[0220] In step 10, the USS / UTM server 211 sends a pairing authorization acknowledgement / pairing authorization notification message to the UAV-C 801 (see messaging 837), which includes a pairing success indication, the UAV ID, the UAV-C ID, the UAS ID, session security information (i.e., key material or token for setting up session security), and the UAV IP address.

[0221] 8C, in step 11, the USS / UTM server 211 further sends a pairing authorization response / acceptance message to the UAS-NF 209 in response to the pairing authorization request (i.e., received in step 5) (see messaging 839), where the pairing authorization response / pairing message includes a pairing success indication, the UAV ID, the UAV-C ID, the UAS ID, session security information, the GPSI of the UAV-C 801, and the UAV-C IP address.

[0222] In step 12, the UAS-NF 209 sends the received pairing authorization response message to the SMF 205 (see messaging 841), which includes a pairing success indication, the UAV ID, the UAV-C ID, the UAS ID, session security information, the GPSI of the UAV, and the UAV-C IP address.

[0223] In step 13, the SMF 205 locally stores the information received in the pairing authorization response as part of the pairing authorization status information. Additionally, the SMF 205 performs an N4 session setup for the authorized pair of UAV 803 and UAV-C 801 (see block 843).

[0224] In step 14, the SMF 205 sends a Nsmf_PDUSession_CreateSMContext response to the AMF / SEAF 805 along with the received pairing authorization response information, and the response message includes a success indication, the UAV ID, the UAV-C ID, the UAS ID, and session security information (see Messaging 845).

[0225] In step 15, the AMF / SEAF805 optionally stores the UAV ID and UAV-C ID along with the pairing permission status and the UAS ID (see block 847).

[0226] In step 16, the AMF / SEAF 805 sends a PDU session establishment accept message to the UAV 803 over the N1 interface (see messaging 849), where the PDU session establishment accept message includes the received pairing authorization response information, which includes a success indication, a UAV ID, a UAV-C ID, a UAS ID, and session security information.

[0227] In step 17, the UAV 803 and the UAV-C 801 use the received session security information to set up a secure connection between the UAV 803 and the UAV-C 801 for the C2 connection (see block 851). The procedure 800 ends.

[0228] 9A-9B depict an example procedure 900 of UAV and UAV-C pairing permission revocation according to a second modification of the third solution. The procedure 900 involves the UE 201, the AMF 203, the SMF 205, the UDM 207, the UAS-NF 209, and the USS / UTM server 211. In some embodiments, the UAS-NF 209 may be replaced with another 3GPP NF that handles UAV / UAV-C related UAS operational message exchanges with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF in the 3GPP network. The steps of the procedure 900 are as follows:

[0229] Starting with FIG. 9A, in step 1, when the USS / UTM server 211 decides to cancel the UAV / UAV-C pairing (also called C2 pairing or C2 association), the USS / UTM server 211 sends a pairing cancellation notification message to the UAS-NF 209 (see messaging 901), which includes the GPSI of the UE 201, the CAA-Level UAV ID of the UE 201, and the UAV-C ID.

[0230] In step 2a, the UAS-NF 209 fetches the serving SMF information corresponding to the received GPSI using the Nudm_UECM_Get request / response service operation (see messaging 903), where it is assumed that the serving SMF information identifies the SMF 205.

[0231] In step 2b, the UAS-NF 209 sends the received pairing cancellation notification message to the Serving SMF 205 (see messaging 905), which includes the GPSI, CAA-Level UAV ID, and UAV-C ID. Alternatively, the UAS-NF 209 sends a pairing cancellation acknowledgement to the USS / UTM server 211 along with the GPSI and CAA-Level UAV ID.

[0232] In step 3, after receiving the pairing cancellation notification, the SMF 205 checks whether there is an active PDU session corresponding to the indicated CAA-Level UAV ID together with the UAV-C ID. If there is an active PDU session, the SMF 205 performs a PDU session release procedure for the associated PDU session ID (see block 907), e.g. using the existing procedures of TS 23.502, clause 4.3.4.3 with the adaptations mentioned below.

[0233] In step 4a, based on the received pairing cancellation notification, SMF205 sends a PDU session release command to AMF203 (see messaging 909), where the command message includes the PDU session ID with an appropriate cause value, and includes pairing cancellation information including the CAA-Level UAV ID and the UAV-C ID. Alternatively, after receiving the pairing cancellation notification, SMF205 may further delete the locally stored pairing information (such as pairing authorization information and paired UAV and UAV-C IDs) -- if available -- for UE201 (i.e., UAV) corresponding to its CAA-Level UAV ID.

[0234] In step 4b, AMF203 forwards a PDU session release command to UE201 (i.e., UAV) (see messaging 911), where this command message includes the PDU session ID, the preferred cause value, and pairing cancellation information including the CAA-Level UAV ID and the UAV-C ID.

[0235] In step 5, after the UE201 (i.e., UAV) receives the PDU session release command together with the pairing revocation information, it deletes the locally stored pairing authorization information (e.g., token, lifetime, identifier, or any relationship information) and associated security information for the UAV and UAV-C pairing indicated in the pairing revocation information (see block 913).

[0236] Continuing to refer to FIG. 9B, in step 6, the UE 201 (i.e., the UAV) sends a PDU Session Release Acknowledgement message to the AMF 203 (see messaging 915), for example including a pairing cancellation acknowledgement / success indication and a CAA-Level UAV ID.

[0237] In step 7, the AMF 203 deletes the locally stored pairing information (such as pairing authorization information and paired UAV and UAV-C IDs, if available) for the UE 201 (i.e., UAV) corresponding to its CAA-Level UAV ID. Further, the AMF 203 sends a PDU session release acknowledgement message to the SMF 205 with the GPSI, the received pairing cancel acknowledgement indication / success indication, and the CAA-Level UAV ID (see messaging 917).

[0238] In step 8, after receiving the pairing cancellation acknowledgement indication, SMF205 deletes the locally stored pairing information (such as pairing permission information and paired UAV and UAV-C IDs) for UE201 (i.e., UAV) corresponding to its CAA-Level UAV ID, if available (i.e., if not deleted in step 4) (see block 919).

[0239] In step 9, the SMF 205 sends a pairing cancellation acknowledgement to the UAS-NF 209 (see messaging 921), the acknowledgement message including the received GPSI, a success indication, and the CAA-Level UAV ID.

[0240] In step 10, the UAS-NF 209 forwards the received pairing cancellation acknowledgment along with the received success indication, GPSI, and CAA-Level UAV ID to the USS / UTM Server 211 (i.e., if not sent in step 2) (see messaging 923). The procedure 900 ends.

[0241] The fourth solution describes how a UAV or UAV-C in inactive mode can be triggered (by a device trigger) to activate a network-initiated PDU session establishment when necessary in connection with UAS authentication and authorization (e.g., UUAA) or pairing authorization as deemed necessary by the USS / UTM.

[0242] 10A-10B show an example procedure 1000 for USS / UTM triggered PDU session establishment for an authorized pairing connection / UAA related to C2 according to an embodiment of the fourth solution. The procedure 1000 involves a UE 1001 (which may be, for example, an embodiment of a remote unit 105, a UAV 106 and / or a UAV-C 108), a short message service ("SMS") service center (denoted as "SMS-SC") 1003, an AMF and / or SMF (depicted as a combined node "AMF / SMF" 1005) serving the UE 1001, a UDM 207, a UAS-NF 209, and a USS / UTM server 211. In some embodiments, UAS-NF209 may be replaced with another 3GPP NF that handles UAS operational message exchanges related to UAVs / UAV-Cs with the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, NEF, or another suitable NF in the 3GPP network.

[0243] The USS / UTM server 211 may call a Nuasnf_Trigger service, an Nnef_Trigger service, or an N3gppnf_Trigger service (e.g., a Nufes_Trigger service), or a Naf_Trigger service to request the network to send an application trigger to the UAV and / or UAV-C. Although the NEF is not depicted in Figures 10A-B, in some embodiments, the UAS-NF 209 and the USS / UTM server 211 communicate via the NEF, as described in more detail below. The steps of the procedure 1000 are as follows:

[0244] Starting with FIG. 10A, in step 1, the USS / UTM server 211 determines that the UE 1001 (i.e., a UAV / UAV-C device) needs to be triggered (see block 1011). If the USS / UTM server 211 does not have contact details of the NEF and / or UAS-NF 209 (aka NEF), it discovers and selects a NEF / UAS-NF service. Alternatively, the USS / UTM server 211 may use the 3GPP NF routing information (i.e., the 3GPP NF routing information received from the UAS-NF 209 and stored in the UUAA if done previously) to send in step 2.

[0245] In step 2, the USS / UTM server 211 invokes the Nuasnf_Trigger_Delivery request service (alternatively, the N3gppnf_Trigger service, e.g., the Nnef / Nufes_Trigger service) with a UAS payload containing {(UUAA request / pairing authorization request indication), CAA-Level UAV ID, UAV-C ID (applicable when pairing authorization request indication is sent)), 3GPP UAV ID} (see messaging 1013). To illustrate the different possibilities, the associated service action may be a UAS-NF service action (i.e., using the "Nuasnf" service action prefix), a NEF service action (i.e., using the "Nuasnf" service action prefix), a NEF service action (i.e., using the "Nuasnf" service action prefix), a 3GPP Application Function ("AF") service action (i.e., using the "Naf" service action prefix), or another 3GPP NF service action (i.e., using the "N3gppnf" service action prefix, or using any other service action prefix defined in the 3GPP standards).

[0246] In step 3, the UAS-NF 209 (aka NEF) checks that the USS / UTM server 211 is authorized to send the trigger request and that the USS / UTM server 211 has not exceeded the trigger submission quota or rate on Nuasnf / Nnef / N3gppnf / Naf (see block 1015). If this check fails, the UAS-NF 209 (aka NEF) sends a Nuasnf / Nnef / N3gppnf / Naf_Trigger_Delivery response with a cause value indicating the reason for the failed condition and the flow stops at this step. If not, the flow continues with step 4.

[0247] In step 4, when the USS / UTM server 211 is authorized to trigger the UE 1001 (i.e., the UAV / UAV-C device), the UAS-NF 209 may call the Nudm_SDM_Get service operation (i.e., including parameter identifier translation, GPSI and USS / UTM identifier) ​​to resolve the GPSI to a SUPI (see messaging 1017).

[0248] In step 5, the UDM 207 may invoke the Nudr_DM_Query service to retrieve a list of USS / UTMs that are allowed to trigger the UE 1001, and based on the UDM policy, determines which identifier (SUPI or Mobile Station Integrated Services Digital Network Number ("MSISDN")) should be used to trigger the UE 1001. The UDM 207 provides a Nudm_SDM_Get response (i.e., including parameters, SUPI, and--optionally--MSISDN) (see Messaging 1019).

[0249] If the USS / UTM server 211 is not allowed to send trigger messages to this UE 1001 or if there is no valid subscription information for this user, the UAS-NF 209 (aka NEF) sends a Nuasnf / Nnef / N3gppnf / Naf_Trigger_Delivery response with a cause value indicating the reason for the failed condition and the flow stops at this step. Otherwise, the flow continues with step 6.

[0250] In step 6, the UAS-NF 209 calls Nudm_UECM_Get(SUPI, SMS) to retrieve the 5G SMS function ("SMSF") ID of the UE 1001 (see Messaging 1021).

[0251] In step 7, the UDM 207 may invoke the Nudr_DM_Query service to retrieve the UE SMSF ID. The UDM 207 provides a Nudm_UECM_Get response with the corresponding UE SMSF ID (see messaging 1023). UDM policies (possibly dependent on the Visited PLMN ("VPLMN") ID) may affect which serving node ID is returned. The UAS-NF 209 defines the received ID as a UAS payload (see messaging 1025).

[0252] 10B, in step 8, the UAS-NF 209 selects a preferred SMS service center (SMS-SC) 1003 based on the configured information (see messaging 1027). The UAS-NF 209 acts as an MTC Interworking Function ("MTC-IWF") and sends a Submit Trigger (i.e., including GPSI, SUPI, USS / UTM identifier, trigger reference number, validity period, priority, SMSF serving node ID (if available, these are obtained from the UDM in step 7), SMS application port ID, UAS trigger payload (received UAS payload), trigger instruction parameters) message to the SMS-SC 1003.

[0253] If the UAS-NF 209 indicates that a "missed subscriber" has been received from the UDM 207, the SMS-SC 1003 does not submit the message, but directly stores it and requests the UDM 207 to send routing information for session management ("SM") and add the SMS-SC address to the message waiting list.

[0254] In step 9, the SMS-SC 1003 sends a submit trigger confirmation message to the UAS-NF 209 to confirm that the submission of the SMS has been accepted by the SMS-SC 1003 (see messaging 1029).

[0255] In step 10, the UAS-NF 209 (aka NEF) sends a Nuasnf / Nnef / M3gppnf / Naf_Trigger_Delivery response to the USS / UTM server 211 to indicate whether the device trigger request has been accepted for delivery to the UE 1001 (see messaging 1031).

[0256] In step 11, the SMS-SC 1003 performs a Mobile Terminated ("MT") SMS delivery to the UE 1001 (see block 1033).

[0257] In step 12, if the message delivery fails (either directly or when the trigger message validity period expires) or if the message delivery is successful, the SMS-SC 1003 sends a message delivery report (i.e., including cause code, trigger reference number, and USS / UTM identifier) ​​to the UAS-NF 209 (see Messaging 1035).

[0258] In step 13, the UAS-NF 209 (aka NEF) provides a Nuasnf / Nnef / N3gppnf / Naf_Trigger_Delivery Notify message to the USS / UTM Server 211 (see messaging 1037) with a delivery report indicating the trigger delivery result (e.g., success, unknown, or failure, and the reason for failure). The UAS-NF 209 (aka NEF) generates the necessary Charging Data Record ("CDR") information including the GPSI and USS / UTM identifiers.

[0259] In step 14, in response to the received device trigger, the UE 1001 may take a specific action, taking into account the contents of the trigger payload (see block 1039). This action typically involves initiating immediate or subsequent communication with the USS / UTM server 211. The procedure 1000 ends.

[0260] 11 illustrates a user equipment device 1100 that may be used to handle security aspects for a UAS in a 3GPP network, according to an embodiment of the disclosure. In various embodiments, the user equipment device 1100 is used to implement one or more of the solutions described above. The user equipment device 1100 may be an embodiment of the remote unit 105 and / or the UE 201, described above. Additionally, the user equipment device 1100 may comprise a processor 1105, a memory 1110, an input device 1115, an output device 1120, and a transceiver 1125.

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

[0262] As depicted, 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 operable on an unlicensed spectrum. Additionally, the transceiver 1125 may comprise 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. As will be appreciated by those skilled in the art, other network interfaces 1140 may also be supported.

[0263] The processor 1105, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing 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 the memory 1110 to perform the methods and routines described herein. The processor 1105 is communicatively coupled to the memory 1110, the input device 1115, the output device 1120, and the transceiver 1125.

[0264] In various embodiments, the processor 1105 controls the user equipment device 1100 to implement the UE behaviors described above. In some embodiments, the processor 1105 may include an application processor (also referred to as a “main processor”) that manages application areas and operating system (“OS”) functions, and a baseband processor (also referred to as a “baseband radio processor”) that manages radio functions.

[0265] In various embodiments, the transceiver 1125 receives a revocation indication message from the mobile communications network (e.g., from the SMF via the AMF, or from the AMF in the case of 5GS, or from the MME / SMF+PGW-C in the case of EPS). The processor 1105 deletes the UAS-related authorization and security information corresponding to the UAV ID, and transmits a revocation acknowledgement message to the mobile communications network (e.g., via the transceiver 1125).

[0266] In some embodiments, the UAV ID includes at least a CAA-level UAV ID. In some embodiments, the UAS related authorization and security information includes one or more of A) UUAA results, B) pairing / C2 authorization results, C) UUAA authorization information, D) security keys, E) tokens, F) lifetimes, G) pairing information, H) pairing authorization results, I) C2 association information, J) C2 association authorization results, K) UAS security information, L) session security key material, M) session security tokens, and N) combinations thereof.

[0267] In some embodiments, based on the revocation instruction message, the processor 1105 revokes the UUAA for the UAV ID or requests an upper layer (i.e., application layer) to revoke the UUAA for the UAV ID. In such embodiments, deleting the UAS-related authorization and security information includes deleting authorization information and security context received after the successful UUAA.

[0268] In some embodiments, based on the revocation instruction message, the processor 1105 revokes the UAS pairing authorization (e.g., UAV / UAV-C pairing and / or C2 pairing / association) corresponding to the UAV ID or requests an upper layer (i.e., application layer) to revoke the UAS pairing authorization corresponding to the UAV ID. In such embodiments, deleting the UAS relationship authorization and security information includes deleting UAS pairing authorization information and session security information received after a successful UAS pairing procedure, for example, between the UAV and the UAV-C. As used herein, "UAS pairing" refers to UAV / UAV-C pairing, C2 pairing, and / or C2 association.

[0269] In some embodiments, the UAS pairing procedure includes sending a pairing authorization request and receiving a pairing success indication including session security information, where the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS.

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

[0271] In some embodiments, the memory 1110 stores data related to location-aware beam selection and / or mobile operations. For example, the memory 1110 may store various parameters, panel / beam configurations, resource allocations, policies, and the like, as described above. In some embodiments, the memory 1110 also stores program code and related data, such as an operating system or other controller algorithms operating on the device 1100.

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

[0273] The output device 1120, in one embodiment, is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1120 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 1120 may include, without limitation, a liquid crystal display ("LCD"), a light emitting diode ("LED") display, an organic LED ("OLED") display, a projector, or a similar display device capable of outputting images, text, or the like to a user. As another, non-limiting example, the output device 1120 may include a wearable display that is separate from, but communicatively coupled to, the remainder of the user equipment device 1100, such as a smart watch, smart glasses, a head-up display, or the like. Additionally, the output device 1120 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0274] In some embodiments, the output device 1120 comprises one or more speakers for generating sound. For example, the output device 1120 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 1120 includes one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion 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 touch screen or similar touch-sensitive display. In other embodiments, the output device 1120 may be located near the input device 1115.

[0275] The transceiver 1125 communicates with one or more network functions of a mobile communications 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 activate the transceiver 1125 (or a portion thereof) at particular times to transmit and receive messages.

[0276] The transceiver 1125 includes at least one transmitter 1130 and at least one receiver 1135. The one or more transmitters 1130 may be used to provide UL communication signals to the base unit 121, such as UL transmissions as described herein. Similarly, the 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 illustrated, 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 communications network over a licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communications network over an unlicensed radio spectrum.

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

[0278] In various embodiments, one or more transmitters 1130 and / or one or more receivers 1135 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-chip, an application specific integrated circuit ("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 into a single chip with any number of transmitters 1130 and / or receivers 1135. In such embodiments, the transmitters 1130 and receivers 1135 may be logically configured as a transceiver 1125 using one or more common control signals, or as modular transmitters 1130 and receivers 1135 implemented within the same hardware chip or multi-chip module.

[0279] 12 illustrates a network device 1200 that may be used to handle security aspects for a UAS in a 3GPP network in accordance with an embodiment of the present disclosure. In one embodiment, the network device 1200 may be an implementation of a serving network function in a mobile network, such as AMF 143, SMF 145, AMF 203, SMF 205, AMF / SEAF 605, AMF / SMF#1 703, AMF / SMF#2 707, AMF / SEAF 805, and / or AMF / SMF 1005. In another embodiment, the network device 1200 may be an implementation of a network function that handles UAV and / or UAV-C related UAS operational message exchanges with a corresponding USS / UTM on behalf of a 3GPP network, such as the NEF 146, UAS-NF 147, UAS-NF 209, UAS-NF#1 705, UAS-NF#2 707, NEF+SCEF, UFES, and / or another suitable NF in the 3GPP network. Further, the network device 1200 may comprise a processor 1205, a memory 1210, an input device 1215, an output device 1220, and a transceiver 1225.

[0280] In some embodiments, the input device(s) 1215 and the output device(s) 1220 are combined into a single device, such as a touch screen. In some embodiments, the network device 1200 may not include the input device(s) 1215 and / or the output device(s) 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(s) 1215 and / or the output device(s) 1220.

[0281] As depicted, the transceiver 1225 includes at least one transmitter 1230 and at least one receiver 1235, where 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 an 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 appreciated by one of ordinary skill in the art, other network interfaces 1240 may also be supported.

[0282] The processor 1205, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 1205 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or 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.

[0283] In various embodiments, the network device 1200 is a RAN node (e.g., gNB) that communicates with one or more UEs as described herein. In such embodiments, the processor 1205 controls the network device 1200 to perform the RAN behaviors described above. When operating as a RAN node, the processor 1205 may include an application processor (also referred to as a “main processor”) that manages application domains and operating system (“OS”) functions, and a baseband processor (also referred to as a “baseband radio processor”) that manages radio functions.

[0284] In various embodiments, the processor 1205 controls the apparatus 1200 to perform the AMF and / or SMF behaviors described above. In some embodiments, the transceiver 1225 receives (e.g., via the network interface 1245) a revocation message (e.g., a UUAA revocation or UAS pairing revocation message) including the UAV ID and transmits a revocation indication to the UE in response to the revocation message. The processor 1205 deletes a UAS context (i.e., a UE context) corresponding to the revocation message, and the transceiver 1225 receives a revocation acknowledgment from the UE. In various embodiments, the UAS context includes information related to the UUAA or C2 pairing of the UE.

[0285] In some embodiments, the cancellation message includes a UUAA cancellation message that cancels the UUAA for the UAV ID. In such embodiments, sending the cancellation indication includes sending a UCU command to the UE, deleting the UAS context includes deleting one or more of authorization information and security context received after successful UUAA, and the UAV ID includes one or more of a network-level UAV ID (i.e., 3GPP UAV ID, SUPI, and / or GPSI) and a CAA-level UAV ID.

[0286] In some embodiments, the processor 1205 determines whether an active data connection (i.e., a 5G PDU session or a 4G PDN connection) corresponds to the UUAA / pairing cancellation message (e.g., using a network-level UAV ID or a CAA-level UAV ID) and releases the active data connection in response to determining that the active data connection corresponds to the UUAA / pairing cancellation request.

[0287] In some embodiments, the revocation message cancels a UAS pairing (e.g., a UAV / UAV-C pairing or a C2 association) corresponding to the UAV ID. In such embodiments, sending the revocation indication includes sending a PDU session release command, and deleting the UAS context includes deleting one or more of A) pairing (or C2 association) authorization information, B) session security information received after a successful UAS pairing procedure between the UAV and the UAV-C, and C) combinations thereof. As used herein, "UAS pairing" refers to a UAV / UAV-C pairing, a C2 pairing, and / or a C2 association.

[0288] In some embodiments, the revocation message includes a pairing update message for the UAV ID. For example, the revocation instruction message may be a UAV / UAV-C pairing update for the UAV ID or a C2 pairing / association update for the UAV ID. In such an embodiment, the pairing update message includes one or more of A) the UAV-C ID, B) new pairing permission information, and C) a cause value "UAV-C exchange" (or "UAV-C change").

[0289] In some embodiments, sending the revocation indication to the UE includes sending a PDU session modification command. In one embodiment, the processor updates the UAS pairing corresponding to the UAV ID based on the new pairing authorization information. In another embodiment, the processor uses the new pairing authorization information to update one or more of A) pairing (or C2) authorization information, B) C2 association authorization information, C) session security information received after a successful UAS pairing procedure between the UAV and UAV-C, and D) combinations thereof.

[0290] In some embodiments, the UAS context includes one or more of A) UUAA result, B) pairing / C2 authorization result, C) UUAA authorization information, D) security keys, E) tokens, F) lifetime, G) pairing information, H) pairing authorization result, I) C2 association information, J) C2 association authorization result, K) UAS security information, L) session security key material, M) session security token, and N) combinations thereof.

[0291] In some embodiments, the transceiver 1225 receives a re-authentication request message from the UAS-NF, the re-authentication request message including one or more of A) a network-level UAV ID (e.g., GPSI), B) a CAA-level UAV ID, C) a cause value indicating re-authentication of the UE, and D) combinations thereof. In such embodiments, the transceiver 1225 transmits a NAS message--to the UE--including the UAV ID request and an indication indicating that re-authentication of the UE is required.

[0292] In some embodiments, the transceiver 1225 receives a pairing authorization request from the UE and forwards the pairing authorization request to the UAS-NF in response to verifying that the UE is authorized to request pairing authorization, where the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS, and D) combinations thereof.

[0293] In such an embodiment, the transceiver 1225 receives a pairing authorization response from the UAS-NF, stores contents of the pairing authorization response in a local memory, and transmits the contents of the pairing authorization response to the UE, where the contents of the pairing authorization response include one or more of A) a pairing success indication, B) pairing authorization information (or C2 authorization information), C) session security information, and D) combinations thereof.

[0294] In various embodiments, the processor 1205 controls the apparatus 1200 to perform the UAS-NF behaviors described above. In some embodiments, the transceiver 1225 (i.e., supporting the network interface 1245) receives a UUAA request from the first NF (e.g., from the AMF and / or SMF), where the UUAA request includes one or more of a network-level UAV ID (i.e., UAV ID and / or GPSI), a subscription permanent identifier (i.e., SUPI), and a CAA-level UAV ID.

[0295] The processor 1205 associates (stores) the subscription permanent identifier with the CAA-level UAV ID and the network-level UAV ID (i.e., 3GPP UAV ID and / or GPSI). In one embodiment, if the network-level UAV ID is not received in the UUAA request, the processor 1205 fetches the network-level UAV ID (e.g., GPSI) from the UDM / UDR by providing the SUPI. The processor 1205 controls the transceiver 1225 to send a second UUAA request to the USS / UTM, where the second UUAA request includes routing information for a network function that handles UAV and / or UAV-C related message exchanges with the USS / UTM (e.g., UUAA and C2 pairing related message exchanges).

[0296] In some embodiments, the transceiver 1225 receives a revocation message (e.g., UUAA revocation or pairing revocation) from the USS / UTM, the revocation message including the UAV ID (e.g., CAA-level UAV ID), and the processor 1205 transmits the revocation message (via the transceiver 1225) to the first NF (e.g., to the AMF / SMF in the case of 5GS or to the MME / SMF+PGW-C in the case of EPS). In such embodiments, the transceiver 1225 may also receive a response message from the first NF, the response message including the UAV ID and a revocation success indication. In some embodiments, the processor 1205, after receiving the revocation message, deletes any UAS-related information (e.g., UAS context) and UAV ID stored locally for the UAV, and triggers a UAS authentication status update in the USS / UTM (e.g., by sending a revocation response message) in response to receiving the revocation success indication.

[0297] In some embodiments, the revocation message includes a pairing update message for the UAV ID. For example, the revocation message may be a UAV / UAV-C pairing update for the UAV ID or a C2 association update for the UAV ID. In such embodiments, the pairing update message includes one or more of A) the UAV-C ID, B) new pairing permission information, and C) a cause value “UAV-C Exchange” (or “UAV-C Change”). In some embodiments, sending the revocation message to the first NF includes sending a pairing update message to a serving network function (e.g., serving AMF / SMF) corresponding to the UAV ID.

[0298] In some embodiments, the first NF includes an AMF, and the cancellation message includes a UUAA cancellation message that cancels the UUAA for the UAV ID, and the UAV ID includes one or more of a network-level UAV ID (e.g., a 3GPP UAV ID, a SUPI and / or a GPSI) and a CAA-level UAV ID.

[0299] In some embodiments, the first NF includes an SMF, and the revocation message revoks a UAS pairing (e.g., a UAV / UAV-C pairing or a C2 association) corresponding to the UAV ID. In such embodiments, sending the revocation message to the SMF includes sending one or more of a CAA-level UAV ID, a UAV-C ID, and a subscriber ID (e.g., a SUPI and / or GPSI) of the UAV.

[0300] In some embodiments, the transceiver 1225 receives a re-authentication request message from the USS / UTM, where the re-authentication request message includes one or more of: A) a network-level UAV ID (e.g., GPSI), B) a CAA-level UAV ID, C) a cause value that indicates re-authentication of the UE, and D) a combination thereof. In such embodiments, the processor 1205 (via the transceiver 1225) forwards the re-authentication request message to the first NF (e.g., to the AMF and / or SMF for 5GS, or to the MME and / or SMF+PGW-C for EPS).

[0301] In some embodiments, the transceiver 1225 receives a pairing authorization request from a first NF (e.g., AMF), and the processor forwards the pairing authorization request to the USS / UTM (via the transceiver 1225) in response to verifying that the UE is authorized to request pairing authorization. In such embodiments, the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS, and D) combinations thereof. Furthermore, the transceiver 1225 further receives a pairing authorization response from the USS / UTM and forwards the pairing authorization response to the first NF (e.g., AMF) (via the transceiver 1225). In such embodiments, the pairing authorization response includes one or more of A) a pairing success indication, B) pairing authorization information (or C2 association authorization information), and C) session security information, and D) combinations thereof.

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

[0303] In some embodiments, memory 1210 stores data related to location-aware beam selection and / or mobile operation. For example, memory 1210 may store parameters, configurations, resource allocations, policies, and the like, as described above. In some embodiments, memory 1210 also stores program code and related data, such as an operating system or other controller algorithms operating on device 1200.

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

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

[0306] In some embodiments, the output device(s) 1220 include one or more speakers for generating sound. For example, the output device(s) 1220 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device(s) 1220 include one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the output device(s) 1220 may be integrated with the input device(s) 1215. For example, the input device(s) 1215 and the output device(s) 1220 may form a touch screen or similar touch-sensitive display. In other embodiments, the output device(s) 1220 may be located near the input device(s) 1215.

[0307] The transceiver 1225 includes at least one transmitter 1230 and at least one receiver 1235. The one or more transmitters 1230 may be used to communicate with a UE, as described herein. Similarly, the one or more receivers 1235 may be used to communicate with a network function in a public land mobile network ("PLMN") and / or a RAN, as described herein. Although only one transmitter 1230 and one receiver 1235 are illustrated, 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.

[0308] 13 illustrates one embodiment of a method 1300 for handling security aspects for a UAS in a 3GPP network in accordance with an embodiment of the disclosure. In various embodiments, the method 1300 is performed by a communication device in a UAS, such as remote unit 105, UAV 106, UAV-C 108, UE 201, UE 401, UAV-C 601, UAV 603, UE 701, UE 711, UAV-C 801, UAV 803, UE 1001, and / or user equipment device 1100, as described above. In some embodiments, the method 1300 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0309] The method 1300 starts by receiving 1305 a revocation indication message from the mobile communication network (e.g., from the SMF / AMF or from the MME / PGW-C / SMF+PGW-C). The method 1300 includes deleting 1310 UAS-related authorization and security information corresponding to the UAV ID. The first method includes sending 1315 a revocation acknowledgement message to the mobile communication network. The method 1300 ends.

[0310] 14 illustrates one embodiment of a method 1400 for handling security aspects for a UAS in a 3GPP network according to an embodiment of the disclosure. In various embodiments, the method 1400 is performed by a network entity, such as AMF 143, SMF 145, AMF 203, SMF 205, AMF / SEAF 605, AMF / SMF#1 703, AMF / SMF#2 707, AMF / SEAF 805, AMF / SMF 1005, and / or network device 1200, as described above. In some embodiments, the method 1400 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0311] The method 1400 begins by receiving 1405 a revocation message (e.g., UUAA revocation or UAS pairing revocation) including a UAV ID. The method 1400 includes sending 1410 a revocation indication to the UE in response to the revocation message. The method 1400 includes deleting 1415 a UAS context corresponding to the revocation message. The method 1400 includes receiving 1420 a revocation acknowledgement from the UE. The method 1400 ends.

[0312] 15 illustrates one embodiment of a method 1500 for handling security aspects for a UAS in a 3GPP network in accordance with an embodiment of the disclosure. In various embodiments, the method 1500 is performed by a network function in a communications network, such as the NEF 146, the UAS-NF 147, the UAS-NF 209, the UAS-NF#1 705, the UAS-NF#2 707, and / or the network device 1200, as described above. In some embodiments, the method 1500 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like.

[0313] Method 1500 starts by receiving 1505 a UUAA request from a first NF (e.g., AMF / SMF), the UUAA request including one or more of a network-level UAV ID, a subscription permanent identifier (e.g., SUPI), and a CAA-level UAV ID. Method 1500 associates 1510 the subscription permanent identifier with the CAA-level UAV ID and the network-level UAV ID (e.g., 3GPP UAV ID / GPSI). Method 1500 includes sending 1515 a second UUAA request to the USS / UTM, the second UUAA request including routing information for a network function that handles UAV and UAV-C message exchanges (e.g., UUAA and UAV / UAV-C pairing authorization) with the USS / UTM. Method 1500 ends.

[0314] Disclosed herein is a first apparatus for handling security aspects for a UAS in a 3GPP network according to an embodiment of the present disclosure. The first apparatus may be implemented by a communication device in a UAS, such as a remote unit 105, a UAV 106, a UAV-C 108, a UE 201, a UE 401, a UAV-C 601, a UAV 603, a UE 701, a UE 711, a UAV-C 801, a UAV 803, a UE 1001, and / or a user equipment device 1100, described above. The first apparatus includes a transceiver that receives a revocation indication message from a mobile communication network (e.g., from an SMF via an AMF, or from an AMF in the case of 5GS, or from an MME / SMF+PGW-C in the case of EPS). A processor deletes UAS-related authorization and security information corresponding to the UAV ID, and transmits a revocation acknowledgement message to the mobile communication network (e.g., via the transceiver).

[0315] In some embodiments, the UAV ID includes at least a CAA-level UAV ID. In some embodiments, the UAS related authorization and security information includes one or more of A) UUAA results, B) pairing / C2 authorization results, C) UUAA authorization information, D) security keys, E) tokens, F) lifetimes, G) pairing information, H) pairing authorization results, I) C2 association information, J) C2 association authorization results, K) UAS security information, L) session security key material, M) session security tokens, and N) combinations thereof.

[0316] In some embodiments, the revocation instruction message revokes the UUAA for the UAV ID. In such embodiments, deleting the UAS-related authorization and security information includes deleting authorization information and security context received after a successful UUAA. In some embodiments, the revocation instruction message revokes the UAS pairing (e.g., UAV / UAV-C pairing and / or C2 pairing / association) corresponding to the UAV ID. In such embodiments, deleting the UAS-related authorization and security information includes deleting UAS pairing authorization information and session security information received after a successful UAS pairing procedure, for example, between the UAV and UAV-C.

[0317] In some embodiments, the UAS pairing procedure includes sending a pairing authorization request and receiving a pairing success indication including session security information, where the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS.

[0318] Disclosed herein is a first method for handling security aspects for a UAS in a 3GPP network according to an embodiment of the present disclosure. The first method may be implemented by a communication device in a UAS, such as a remote unit 105, a UAV 106, a UAV-C 108, a UE 201, a UE 401, a UAV-C 601, a UAV 603, a UE 701, a UE 711, a UAV-C 801, a UAV 803, a UE 1001, and / or a user equipment device 1100, described above. The first method includes receiving a revocation indication message from a mobile communication network (e.g., from an SMF via an AMF, or from an AMF in the case of 5GS, or from an MME / SMF+PGW-C in the case of EPS), and deleting UAS-related authorization and security information corresponding to a UAV ID. The first method includes sending a revocation acknowledgement message to the mobile communication network.

[0319] In some embodiments, the UAV ID includes at least a CAA-level UAV ID. In some embodiments, the UAS related authorization and security information includes one or more of A) UUAA results, B) pairing / C2 authorization results, C) UUAA authorization information, D) security keys, E) tokens, F) lifetimes, G) pairing information, H) pairing authorization results, I) C2 association information, J) C2 association authorization results, K) UAS security information, L) session security key material, M) session security tokens, and N) combinations thereof.

[0320] In some embodiments, the revocation instruction message revokes the UUAA for the UAV ID. In such embodiments, deleting the UAS-related authorization and security information includes deleting authorization information and security context received after a successful UUAA. In some embodiments, the revocation instruction message revokes the UAS pairing (e.g., UAV / UAV-C pairing and / or C2 pairing / association) corresponding to the UAV ID. In such embodiments, deleting the UAS-related authorization and security information includes deleting UAS pairing authorization information and session security information received after a successful UAS pairing procedure, for example, between the UAV and UAV-C.

[0321] In some embodiments, the UAS pairing procedure includes sending a pairing authorization request and receiving a pairing success indication including session security information, where the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS.

[0322] Disclosed herein is a second apparatus for handling security aspects for UAS in a 3GPP network according to an embodiment of the present disclosure. The second apparatus may be implemented by a network entity, such as AMF143, SMF145, AMF203, SMF205, AMF / SEAF605, AMF / SMF#1 703, AMF / SMF#2 707, AMF / SEAF805, AMF / SMF1005, and / or network device 1200, described above. Alternatively, in case of EPS, the network entity may be implemented by a control plane part of a PGW / SMF+PGW-C and / or for an MME. The second apparatus comprises a processor and a transceiver for receiving a revocation message (e.g., a UUAA revocation or UAS pairing revocation message) including a UAV ID and sending a revocation indication to the UE in response to the revocation message. The processor deletes a UAS context corresponding to the revocation message, and the transceiver receives a revocation acknowledgement from the UE.

[0323] In some embodiments, the cancellation message includes a UUAA cancellation message that cancels the UUAA for the UAV ID. In such embodiments, sending the cancellation indication includes sending a UCU command to the UE, deleting the UAS context includes deleting one or more of authorization information and security context received after successful UUAA, and the UAV ID includes one or more of a network-level UAV ID (i.e., 3GPP UAV ID, SUPI, and / or GPSI) and a CAA-level UAV ID.

[0324] In some embodiments, the processor determines whether an active data connection (i.e., a 5G PDU session or a 4G PDN connection) corresponds to the UUAA / pairing cancellation message (e.g., using a network-level UAV ID or a CAA-level UAV ID) and releases the active data connection in response to determining that the active data connection corresponds to a UUAA / pairing cancellation request.

[0325] In some embodiments, the revocation message cancels a UAS pairing (e.g., a UAV / UAV-C pairing or a C2 association) corresponding to the UAV ID. In such embodiments, sending the revocation indication includes sending a PDU session release command, and deleting the UAS context includes deleting one or more of A) pairing (or C2 association) authorization information, B) session security information received after a successful UAS pairing procedure between the UAV and the UAV-C, and C) combinations thereof.

[0326] In some embodiments, the revocation message includes a pairing update message for the UAV ID. For example, the revocation instruction message may be a UAV / UAV-C pairing update for the UAV ID or a C2 pairing / association update for the UAV ID. In such an embodiment, the pairing update message includes one or more of A) the UAV-C ID, B) new pairing permission information, and C) a cause value "UAV-C exchange" (or "UAV-C change").

[0327] In some embodiments, sending the revocation indication to the UE includes sending a PDU session modification command. In one embodiment, the processor updates the UAS pairing corresponding to the UAV ID based on the new pairing authorization information. In another embodiment, the processor uses the new pairing authorization information to update one or more of A) pairing (or C2) authorization information, B) C2 association authorization information, C) session security information received after a successful UAS pairing procedure between the UAV and UAV-C, and D) combinations thereof.

[0328] In some embodiments, the UAS context includes one or more of A) UUAA result, B) pairing / C2 authorization result, C) UUAA authorization information, D) security keys, E) tokens, F) lifetime, G) pairing information, H) pairing authorization result, I) C2 association information, J) C2 association authorization result, K) UAS security information, L) session security key material, M) session security token, and N) combinations thereof.

[0329] In some embodiments, the transceiver receives a re-authentication request message from the UAS-NF, the re-authentication request message including one or more of A) a network-level UAV ID (e.g., GPSI), B) a CAA-level UAV ID, C) a cause value indicating re-authentication of the UE, and D) combinations thereof. In such embodiments, the transceiver transmits a NAS message--to the UE--including the UAV ID request and an indication indicating that re-authentication of the UE is required.

[0330] In some embodiments, the transceiver receives a pairing authorization request from the UE and forwards the pairing authorization request to the UAS-NF in response to verifying that the UE is authorized to request pairing authorization, where the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS, and D) combinations thereof.

[0331] In such an embodiment, the transceiver receives a pairing authorization response from the UAS-NF, stores contents of the pairing authorization response in a local memory, and transmits the contents of the pairing authorization response to the UE, where the contents of the pairing authorization response include one or more of A) a pairing success indication, B) pairing authorization information (or C2 authorization information), C) session security information, and D) combinations thereof.

[0332] Disclosed herein is a second method for handling security aspects for UAS in a 3GPP network according to an embodiment of the present disclosure. The second apparatus may be executed by a network entity, such as AMF143, SMF145, AMF203, SMF205, AMF / SEAF605, AMF / SMF#1 703, AMF / SMF#2 707, AMF / SEAF805, AMF / SMF1005, and / or network apparatus 1200, described above. Alternatively, in case of EPS, the network entity may be implemented by the control plane part of the PGW and / or for the MME. The second method includes receiving a revocation message (e.g., UAVA revocation or UAS pairing revocation) including a UAV ID, and sending a revocation indication to the UE in response to the revocation message. The second method includes deleting a UAS context and receiving a revocation acknowledgement from the UE, corresponding to the revocation message.

[0333] In some embodiments, the cancellation message includes a UUAA cancellation message that cancels the UUAA for the UAV ID. In such embodiments, sending the cancellation indication includes sending a UCU command to the UE, deleting the UAS context includes deleting one or more of authorization information and security context received after successful UUAA, and the UAV ID includes one or more of a network-level UAV ID (i.e., 3GPP UAV ID, SUPI, and / or GPSI) and a CAA-level UAV ID.

[0334] In some embodiments, the second method includes determining whether an active data connection (i.e., a 5G PDU session or a 4G PDN connection) corresponds to a UUAA / pairing cancellation message (e.g., using a network-level UAV ID or a CAA-level UAV ID), and releasing the active data connection in response to determining that the active data connection corresponds to a UUAA / pairing cancellation request.

[0335] In some embodiments, the revocation message cancels a UAS pairing (e.g., a UAV / UAV-C pairing or a C2 association) corresponding to the UAV ID. In such embodiments, sending the revocation indication includes sending a PDU session release command, and deleting the UAS context includes deleting one or more of A) pairing (or C2 association) authorization information, B) session security information received after a successful UAS pairing procedure between the UAV and the UAV-C, and C) combinations thereof.

[0336] In some embodiments, the revocation message includes a pairing update message for the UAV ID. For example, the revocation instruction message may be a UAV / UAV-C pairing update for the UAV ID or a C2 pairing / association update for the UAV ID. In such an embodiment, the pairing update message includes one or more of A) the UAV-C ID, B) new pairing permission information, and C) a cause value "UAV-C exchange" (or "UAV-C change").

[0337] In some embodiments, sending the revocation indication to the UE includes sending a PDU session modification command. In one embodiment, the second method includes the network entity updating the UAS pairing corresponding to the UAV ID based on the new pairing authorization information. In another embodiment, the second method includes the network entity using the new pairing authorization information to update one or more of A) pairing (or C2) authorization information, B) C2 association authorization information, C) session security information received after a successful UAS pairing procedure between the UAV and UAV-C, and D) combinations thereof.

[0338] In some embodiments, the UAS context includes one or more of A) UUAA result, B) pairing / C2 authorization result, C) UUAA authorization information, D) security keys, E) tokens, F) lifetime, G) pairing information, H) pairing authorization result, I) C2 association information, J) C2 association authorization result, K) UAS security information, L) session security key material, M) session security token, and N) combinations thereof.

[0339] In some embodiments, the second method further includes receiving a re-authentication request message from the UAS-NF, the re-authentication request message including one or more of A) a network-level UAV ID (e.g., GPSI), B) a CAA-level UAV ID, C) a cause value indicating re-authentication of the UE, and D) combinations thereof. In such embodiments, the second method includes sending a NAS message to the UE including the UAV ID request and an indication indicating that re-authentication of the UE is required.

[0340] In some embodiments, the second method further includes receiving a pairing authorization request from the UE and forwarding the pairing authorization request to the UAS-NF in response to verifying that the UE is authorized to request pairing authorization, where the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS, and D) combinations thereof.

[0341] In such an embodiment, the second method further includes receiving a pairing authorization response from the UAS-NF, storing content of the pairing authorization response in a local memory, and transmitting the content of the pairing authorization response to the UE, where the content of the pairing authorization response includes one or more of A) a pairing success indication, B) pairing authorization information (or C2 authorization information), C) session security information, and D) combinations thereof.

[0342] Disclosed herein is a third apparatus for handling security aspects for UAS in a 3GPP network according to an embodiment of the present disclosure. The third apparatus may be implemented by a network function in a communication network, such as the NEF 146, the UAS-NF 147, the UAS-NF 209, the UAS-NF#1 705, the UAS-NF#2 707, and / or the network apparatus 1200 described above. The third apparatus comprises a processor and a transceiver (i.e., supporting a network interface) for receiving a UUAA request from a first NF (e.g., from an AMF and / or an SMF), where the UUAA authorization request includes one or more of a network-level UAV ID (i.e., a UAV ID and / or a GPSI), a subscription permanent identifier (i.e., a SUPI), and a CAA-level UAV ID.

[0343] The processor associates (stores) the subscription permanent identifier with the CAA-level UAV ID and the network-level UAV ID (i.e., 3GPP UAV ID and / or GPSI). In one embodiment, if the third device does not receive the network-level UAV ID, the processor fetches the network-level UAV ID (e.g., GPSI) from the UDM / UDR by providing the SUPI. The processor controls the transceiver to send a second UUAA request to the USS / UTM, where the second UUAA request includes routing information for a network function that handles UAV and / or UAV-C related message exchanges (e.g., UUAA and UAV / UAV-C pairing authorization) with the USS / UTM.

[0344] In some embodiments, the transceiver receives a revocation message (e.g., UUAA revocation or pairing revocation) from the USS / UTM, the revocation message including the UAV ID (e.g., CAA-level UAV ID), and the processor transmits the revocation message (via the transceiver) to the first NF (e.g., to the AMF / SMF in the case of 5GS or to the MME / SMF+PGW-C in the case of EPS). In such embodiments, the transceiver may also receive a response message from the first NF, the response message including the UAV ID and a revocation success indication. In some embodiments, after receiving the revocation message, the processor deletes any UAS-related information (e.g., UAS context) and UAV ID stored locally for the UAV, and triggers a UAS authentication status update in the USS / UTM (e.g., by sending a revocation response message) in response to receiving the revocation success indication.

[0345] In some embodiments, the revocation message includes a pairing update message for the UAV ID. For example, the revocation message may be a UAV / UAV-C pairing update for the UAV ID or a C2 association update for the UAV ID. In such embodiments, the pairing update message includes one or more of A) the UAV-C ID, B) new pairing permission information, and C) a cause value “UAV-C Exchange” (or “UAV-C Change”). In some embodiments, sending the revocation message to the first NF includes sending a pairing update message to a serving network function (e.g., serving AMF / SMF) corresponding to the UAV ID.

[0346] In some embodiments, the first NF includes an AMF, and the cancellation message includes a UUAA cancellation message that cancels the UUAA for the UAV ID, and the UAV ID includes one or more of a network-level UAV ID (e.g., a 3GPP UAV ID, a SUPI and / or a GPSI) and a CAA-level UAV ID.

[0347] In some embodiments, the first NF includes an SMF, and the revocation message revoks a UAS pairing (e.g., a UAV / UAV-C pairing or a C2 association) corresponding to the UAV ID. In such embodiments, sending the revocation message to the SMF includes sending one or more of a CAA-level UAV ID, a UAV-C ID, and a subscriber ID (e.g., a SUPI and / or GPSI) of the UAV.

[0348] In some embodiments, the transceiver receives a re-authentication request message from the USS / UTM, where the re-authentication request message includes one or more of: A) a network-level UAV ID (e.g., GPSI), B) a CAA-level UAV ID, C) a cause value that indicates re-authentication of the UE, and D) a combination thereof. In such embodiments, the processor forwards (via the transceiver) the re-authentication request message to the first NF (e.g., to the AMF and / or SMF in the case of 5GS, or to the MME and / or SMF+PGW-C in the case of EPS).

[0349] In some embodiments, the transceiver receives a pairing authorization request from a first NF (e.g., AMF), and the processor forwards the pairing authorization request to the USS / UTM (via the transceiver) in response to verifying that the UE is authorized to request pairing authorization. In such embodiments, the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS, and D) combinations thereof. Furthermore, the transceiver further receives a pairing authorization response from the USS / UTM and forwards the pairing authorization response to the first NF (e.g., AMF) (via the transceiver). In such embodiments, the pairing authorization response includes one or more of A) a pairing success indication, B) pairing authorization information (or C2 association authorization information), and C) session security information, and D) combinations thereof.

[0350] Disclosed herein is a third method for handling security aspects for UAS in a 3GPP network according to an embodiment of the present disclosure. The third method may be performed by a network function in a communication network, such as the NEF 146, the UAS-NF 147, the UAS-NF 209, the UAS-NF#1 705, the UAS-NF#2 707, and / or the network device 1200, described above. The third method includes receiving a UUAA request from a first NF (e.g., AMF / SMF), where the UUAA request includes one or more of a network-level UAV ID, a subscription permanent identifier (e.g., SUPI), and a CAA-level UAV ID. A third method includes associating (and storing) the subscription permanent identifier with a CAA-level UAV ID and a network-level UAV ID (e.g., 3GPP UAV ID / GPSI) and sending a second UUAA request to the USS / UTM, the second UUAA request including routing information to a network function that handles UAV and / or UAV-C related message exchanges (e.g., UUAA and UAV / UAV-C pairing authorization) with the USS / UTM.

[0351] In some embodiments, the third method includes receiving a revocation message (e.g., UUAA revocation or pairing revocation) from the USS / UTM, where the revocation message includes a UAV ID (e.g., CAA-level UAV ID), and sending the revocation message to the first NF (e.g., to the AMF / SMF in the case of 5GS, or to the MME / SMF+PGW-C in the case of EPS). In such embodiments, the third method also includes receiving a response message from the first NF, where the response message includes the UAV ID and a revocation success indication. In some embodiments, the third method includes deleting any UAS-related information (e.g., UAS context) and UAV ID stored locally for the UAV in response to receiving the revocation message, and triggering a UAS authentication status update in the USS / UTM (e.g., by sending a revocation response message) in response to receiving the revocation success indication.

[0352] In some embodiments, the revocation message includes a pairing update message for the UAV ID. For example, the revocation message may be a UAV / UAV-C pairing update for the UAV ID or a C2 association update for the UAV ID. In such embodiments, the pairing update message includes one or more of A) the UAV-C ID, B) new pairing permission information, and C) a cause value “UAV-C Exchange” (or “UAV-C Change”). In some embodiments, sending the revocation message to the first NF includes sending a pairing update message to a serving network function (e.g., serving AMF / SMF) corresponding to the UAV ID.

[0353] In some embodiments, the first NF includes an AMF, and the cancellation message includes a UUAA cancellation message that cancels the UUAA for the UAV ID, and the UAV ID includes one or more of a network-level UAV ID (e.g., a 3GPP UAV ID, a SUPI and / or a GPSI) and a CAA-level UAV ID.

[0354] In some embodiments, the first NF includes an SMF, and the revocation message revoks a UAS pairing (e.g., a UAV / UAV-C pairing or a C2 association) corresponding to the UAV ID. In such embodiments, sending the revocation message to the SMF includes sending one or more of a CAA-level UAV ID, a UAV-C ID, and a subscriber ID (e.g., a SUPI and / or GPSI) of the UAV.

[0355] In some embodiments, the third method includes receiving a re-authentication request message from the USS / UTM, where the re-authentication request message includes one or more of A) a network-level UAV ID (e.g., GPSI), B) a CAA-level UAV ID, C) a cause value that indicates re-authentication of the UE, and D) combinations thereof. In such embodiments, the third method includes forwarding the re-authentication request message to the first NF (e.g., to the AMF and / or SMF for 5GS, or to the MME and / or SMF+PGW-C for EPS).

[0356] In some embodiments, the third method includes receiving a pairing authorization request from a first NF (e.g., AMF) and forwarding the pairing authorization request to a USS / UTM in response to verifying that the UE is authorized to request pairing authorization. In such embodiments, the pairing authorization request includes one or more of A) a first ID belonging to the UAV, B) a second ID belonging to the UAV-C, and C) a third ID belonging to the UAS, and D) combinations thereof. Further, the third method includes receiving a pairing authorization response from the USS / UTM and forwarding the pairing authorization response to the first NF (e.g., AMF). In such embodiments, the pairing authorization response includes one or more of A) a pairing success indication, B) pairing authorization information (or C2 association authorization information), and C) session security information, and D) combinations thereof.

[0357] The embodiments may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0358] 100 Wireless communication system 101 Unmanned Aircraft Systems ("UAS") 103 UAS Operator 105 Remote Unit 106 Unmanned Aerial Vehicle (“UAV”) 108 UAV Controller ("UAV-C") 120 Radio Access Network ("RAN") 121 Base Unit 123 Wireless Communication Links 140 Mobile Core Network 141 User Plane Function ("UPF") 143 Mobility Management Function ("AMF") 145 Session Management Facility ("SMF") 146 NEF 147 UAS Network Functions ("UAS-NF") 149 Combined entity "UDM / UDR" 150 Packet Data Network 151 Application Server 157 Combined Node "USS / UTM" 200 Steps 201UE 203 AMF 205 SMF 207 UDM 209 UAS-NF 211 USS / UTM Server 215 Messaging 217 Messaging 300 First transformation procedure 400 Steps 401UE 500 steps 503 UDM / UDR 600 steps 601 UAV-C 603 UAV 605 Combined Node "AMF / SEAF" 700 steps 701UE 703 Combined node "AMF / SMF#1" 705 First UAS-NF ("UAS-NF#1") 707 Second UAS-NF ("UAS-NF#2") 709 Combined Node "AMF / SMF#2" 711UE 800 Procedures 801 UAV-C 803 UAV 805 Combined Node "AMF / SEAF" 900 Steps 1000 steps 1001UE 1003 Short Message Service ("SMS") Service Centre ("SMS-SC") 1005 Node "AMF / SMF" 1100 User equipment device 1105 Processor 1110 Memory 1115 Input Devices 1120 Output Device 1125 Transceiver 1130 Transmitter 1135 Receiver 1140 Network Interface 1145 Application Interface 1200 Network Equipment 1205 Processor 1210 Memory 1215 Input Devices 1220 output device 1225 Transceiver 1230 Transmitter 1235 Receiver 1240 Network Interface 1245 Application Interface 1300 methods 1400 methods 1500 ways

Claims

1. A user equipment ("UE") for wireless communications, comprising: At least one memory; a UE coupled to the at least one memory; receiving a cancellation instruction message from a mobile communications network; Deleting unmanned aerial system ("UAS") related authorization and security information corresponding to an unmanned aerial vehicle ("UAV") identifier ("ID"); and sending a revocation acknowledgement message to the mobile communications network; At least one processor configured to cause The UE includes:

2. the UAV ID comprises a Civil Aviation Authority ("CAA") level UAV ID; The UAS-related authorization and security information: UAV USS Certification and Authorization ("UUAA") Results; Command and control ("C2") authorization results; UUAA permission information, Security keys, token, lifespan, Pairing information, Pairing permission result, C2 association information, C2 association permission result, UAS Security Information, Session security key material, A session security token, or Combinations of these 2. The UE of claim 1, comprising one or more of:

3. The revocation instruction message revokes a UAV USS authentication and authorization ("UUAA") for the UAV ID; The UE of claim 1, wherein, to delete the UAS-related authorization and security information, the at least one processor is configured to cause the UE to delete a UUAA context including authorization information and security context received after successful UUAA.

4. The cancellation instruction message cancels the UAS pairing corresponding to the UAV ID; The at least one processor may further include a processor for transmitting a plurality of packets to the UE. performing a UAS pairing procedure between the UAV and a UAV controller ("UAV-C"); receiving at least one of pairing authorization information and session security information based on successful completion of the UAS pairing procedure; configured to cause 2. The UE of claim 1, wherein, to delete the UAS-related authorization and security information, the at least one processor is configured to cause the UE to delete the at least one of the pairing authorization information and the session security information.

5. To perform the UAS pairing procedure, the at least one processor is configured to cause the UE to: A first ID belonging to the UAV; and A second ID belonging to said UAV-C sending a pairing permission request including: receiving a pairing success indication including the session security information; The UE of claim 4, configured to:

6. A processor for wireless communications, comprising: a processor coupled to at least one memory; receiving a cancellation instruction message from a mobile communications network; Deleting unmanned aerial system ("UAS") related authorization and security information corresponding to an unmanned aerial vehicle ("UAV") identifier ("ID"); and sending a revocation acknowledgement message to the mobile communications network; At least one controller configured to cause A processor including 7. The UAV ID comprises a Civil Aviation Authority ("CAA") level UAV ID, The UAS-related authorization and security information: UAV USS Certification and Authorization ("UUAA") Results; Command and control ("C2") authorization results; UUAA permission information, Security keys, token, lifespan, Pairing information, Pairing permission result, C2 association information, C2 association permission result, UAS Security Information, Session security key material, A session security token, or Combinations of these 7. The processor of claim 6, comprising one or more of:

8. The revocation instruction message revoking a UAV USS authentication and authorization ("UUAA") for the UAV ID; The processor of claim 6, wherein to delete the UAS-related authorization and security information, the at least one controller is configured to cause the processor to delete a UUAA context including authorization information and security context received after a successful UUAA.

9. The cancellation instruction message cancels a UAS pairing corresponding to the UAV ID, The at least one controller may further include a processor configured to: performing a UAS pairing procedure between the UAV and a UAV controller ("UAV-C"); receiving pairing authorization information and session security information based on successful completion of the UAS pairing procedure; configured to cause 7. The processor of claim 6, wherein to delete the UAS-related authorization and security information, the at least one controller is configured to cause the processor to delete the pairing authorization information and the session security information.

10. To perform the UAS pairing procedure, the at least one controller is configured to cause the processor to: A first ID belonging to the UAV; and A second ID belonging to said UAV-C sending a pairing permission request including: receiving a pairing success indication including the session security information; The processor of claim 9 , configured to:

11. A network device for wireless communications, comprising: At least one memory; a network device coupled to the at least one memory; receiving a revocation message including an unmanned aerial vehicle ("UAV") identifier ("ID"); sending a revocation indication to a user equipment ("UE") in response to the revocation message; deleting an unmanned aircraft system ("UAS") context corresponding to the revocation message; and receiving a cancellation acknowledgement from the UE; At least one processor configured to cause A network device comprising:

12. the revocation instruction message includes a UUAA revocation message that revokes a UAV USS authentication and authorization ("UUAA") for the UAV ID; 12. The network device of claim 11, wherein to send the cancellation indication, the at least one processor is configured to cause the network device to send a UE Configuration Update ("UCU") command to the UE.

13. To delete the UAS context, the at least one processor is configured to cause the network device to delete one or more of authorization information and security context received after a successful UAV USS Authentication and Authorization ("UUAA") procedure; 12. The network device of claim 11, wherein the UAV ID includes one or more of a General Public Subscription Identifier ("GPSI") and a Civil Aviation Authority ("CAA") level UAV ID.

14. The at least one processor, in the network device, determining whether an active data connection corresponds to the cancellation message; releasing the active data connection in response to determining that the active data connection corresponds to the cancellation request; The network device of claim 11 , further configured to:

15. The revocation message revoks the UAS pairing corresponding to the UAV ID; The network device of claim 11 , wherein to send the cancellation indication, the at least one processor is configured to cause the network device to send a PDU session release command.

16. The at least one processor, in the network device, performing a UAS pairing procedure between the UAV and a UAV controller ("UAV-C"); receiving one or more of pairing authorization information and session security information based on successful completion of the UAS pairing procedure; configured to cause 12. The network device of claim 11, wherein to delete the UAS context, the at least one processor is configured to cause the network device to delete the one or more of the pairing authorization information and the session security information.

17. The revocation message includes a pairing update message for the UAV ID; the pairing update message includes new pairing permission information, as well as one or more of a UAV Controller ("UAV-C") ID and a cause value "UAV-C Exchange"; To send the cancellation indication to the UE, the at least one processor is configured to cause the network device to send a protocol data unit ("PDU") session modification command; The network device of claim 11 , wherein the at least one processor is further configured to cause the network device to update a UAS pairing corresponding to the UAV ID based on the new pairing permission information.

18. The UAS context UAV USS Certification and Authorization ("UUAA") Results; Command and control ("C2") authorization results; UUAA permission information, Security keys, token, lifespan, Pairing information, Pairing permission result, C2 association information, C2 association permission result, UAS Security Information, Session security key material, A session security token, or Combinations of these 12. The network device of claim 11, comprising one or more of:

19. The at least one processor, in the network device, receiving a re-authentication request message from a UAS Network Function ("UAS-NF"), the re-authentication request message comprising: A network level UAV ID; and Civil Aviation Authority ("CAA") level UAV ID; a cause value indicating re-authentication of the UE; receiving the sending a non-access stratum ("NAS") message to the UE, the NAS message comprising: UAV ID request; an indication indicating that re-authentication of the UE is required; Including, transmitting The network device of claim 11 , further configured to:

20. A method performed by a network function, comprising: receiving a revocation message including an unmanned aerial vehicle ("UAV") identifier ("ID"); sending a revocation indication to a user equipment ("UE") in response to the revocation message; deleting an unmanned aircraft system ("UAS") context corresponding to the revocation message; receiving a cancellation acknowledgement from the UE; The method includes:

Images