Revocation of UAS-related authorization and security information

Abstract

To provide security related to UAV / UAV-C authorization and pairing for a UAS.SOLUTION: Apparatuses, methods, and systems for handling security aspects for UASs in 3GPP networks are disclosed. One apparatus (1100) comprises a transceiver (1125) that receives (1305) a revocation indication message from a mobile communications network, and a processor (1105) that deletes (1310) UAS-related authorization and security information corresponding to a UAVID. The transceiver (1125) further transmits (1315) a revocation acknowledgement message to the mobile communication network.SELECTED DRAWING: Figure 1

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 unmanned aerial vehicle controllers (“UAV-Cs”) and unmanned aerial vehicles (“UAVs”). Such networks may also support various unmanned aerial system (“UAS”) services. For example, a UAS service supplier (“USS”) and / or UAS traffic management system (“UTM”) may provide authentication and authorization services for UAVs and / or UAV-Cs. UAV USS authentication and authorization (“UUAA”) is a procedure that ensures that a UAV (or UAV-C) can be authenticated and authorized by a 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 UAVs / UAV-Cs for UASs, for example, in 3GPP networks, 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 acknowledgement from the UE in response 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 with the USS / UTM related to the UAV and / or UAV-C.

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

[0009] [Figure 1] 1 is a schematic block diagram illustrating one 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 of FIG. 2A. [Figure 3A] FIG. 10 illustrates one embodiment of another procedure for UUAA revocation. [Figure 3B] FIG. 3B is a diagram showing a continuation of the procedure of FIG. 3A. [Figure 4A] FIG. 1 illustrates 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 of FIG. 4A. [Figure 5A] FIG. 1 illustrates 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 of 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 of FIG. 6A. [Figure 6C] FIG. 6C is a diagram showing a continuation of the procedure of 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 of FIG. 7A. [Figure 7C] FIG. 7B is a diagram showing a continuation of the procedure of FIG. 7A. [Figure 8A] FIG. 1 illustrates 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 of FIG. 8A. [Figure 8C] FIG. 8C is a diagram showing a continuation of the procedure of 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 of 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 of 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. 10 is a flow chart illustrating one embodiment of a second method for handling security aspects for a UAS in a 3GPP network. [Figure 15] FIG. 10 is a flowchart illustrating one embodiment of a third method for handling security aspects for a UAS in a 3GPP network. DETAILED DESCRIPTION OF THE INVENTION

[0010] As will be appreciated by those 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 a hardware circuit comprising 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 mediums 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 (a non-exhaustive list) of storage devices would include an electrical connection having one or more electrical 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 disc 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 languages ​​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 instances, 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," "an embodiment," or similar language 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, appearances of the phrases "in one embodiment" or "in an embodiment" and similar language do not necessarily all refer to the same embodiment, but mean "one or more, but not all, embodiments" unless otherwise specified. The terms "including," "comprising," and "having," and variations thereof, mean "including but not limited to," unless otherwise specified. Enumerated listings of items do not imply that any or all of the items are mutually exclusive unless otherwise specified. Additionally, the articles "a," "an," and "the" refer to "one or more" unless otherwise specified.

[0018] As used herein, a list with the conjunction "and / or" includes any single item in the list or combination of items in the list. For example, a list of A, B, and / or C includes A only, B only, C only, A and B together, B and C together, A and C together, or A, B, and C together. As used herein, a list using the phrase "one or more of" includes any single item in the list or combination of items in the list. For example, one or more of A, B, and C includes A only, B only, C only, A and B together, B and C together, A and C together, or A, B, and C together. As used herein, "one of" includes only one of any single item in the list. For example, "one of A, B, and C" includes A only, B only, or C only, and excludes A, B, and C together. 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 A only, B only, C only, 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, can be implemented by code that can be 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 on 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 running 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 comprises 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 occur 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, although it is understood that these do not 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 wait or monitoring periods of unspecified duration between enumerated 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 executes a combination of dedicated hardware and code.

[0025] The description of an element in each figure may refer to the element 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 for a UAS. In some embodiments, these methods may be implemented using computer code embedded on a computer-readable medium. In some embodiments, an 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 methods 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] A UAV is only allowed to perform USS / UTM and UUAA after the UAV (i.e., including the UE) has successfully completed primary authentication. The UUAA procedure can be triggered by the AMF when the UAV registers with 5GS. Alternatively, UUAA can 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 PDU session establishment request). The UAV is authenticated based on its CAA-Level UAV ID and the credentials associated with the CAA-Level UAV ID. The authentication message is contained 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 UAS security information in a UUAA authorization payload to the UAV.

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

[0031] However, the authentication, authorization, and pairing aspects related to existing UAVs supported by 3GPP networks are incomplete, as described in the following sub-problems: This disclosure addresses 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 UAS. If authorization information and security context are not released after UAS authentication or authorization revocation (or C2 pairing revocation), the UAV / UAV-C may reuse an old security context, and services may fail due to a mismatch in security information between the UAV / UAV-C and the USS.

[0033] Problem 2 - Inability to provide UAS-NF routing information to the USS / UTM 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, how the USS / UTM identifies the correct UAS-NF to handle UAS communications related to the UAV in 5GS has not yet been defined.

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

[0035] To solve the above-mentioned problems, various solutions are disclosed on how aviation authorities grant requests by proving that a UAV is authorized to perform a UAV operation, and how authorization for a UAV is revoked when necessary. Similarly, solutions are disclosed on how a UAV can be associated with a UAV controller (i.e., a networked or non-networked UAV-C) within a 3GPP core network, and how a 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 with a UAS, according to an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a UAV 106 and a UAV-C, which may include instances of the remote unit 105, a radio access network (“RAN”) 120 (e.g., an NG-RAN), and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communications network. The RAN 120 may be comprised of at least one base unit 121 with which the remote unit 105 communicates using a wireless communications link 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 communication 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 party that operates the UAV 106 (e.g., via the UAV-C 108) and typically requests permission to fly. The UAV 106 and the UAV-C 108 may each be a UE within the wireless communications 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 complies with a fifth-generation ("5G") cellular system specified in 3rd Generation Partnership Project ("3GPP") specifications. For example, the RAN 120 may be a Next Generation Radio Access Network ("NG-RAN"), which 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 complies with an LTE system specified in the 3GPP specifications. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication network, such as a Worldwide Interoperability for Microwave Access ("WiMAX") or IEEE 802.16 family standard network, among other networks. This disclosure is not intended to be limited to any particular wireless communication 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 game 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. Furthermore, 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 termination 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. Furthermore, the UL and DL communication signals may be carried over wireless communication links 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). Note 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 a 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 a 4G / LTE system, 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 access terminals, access points, bases, base stations, Node Bs (“NBs”), evolved Node Bs (abbreviated as eNodeBs or “eNBs” and also referred to as evolved Universal Terrestrial Radio Access Network (“E-UTRAN”) Node Bs), 5G / NR Node Bs (“gNBs”), Home Node Bs, relay nodes, RAN nodes, or any other terminology 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 the mobile core network 140 via the RAN 120.

[0047] The base unit 121 may serve multiple remote units 105 within a serving area, e.g., a cell or cell sector, via wireless communication link 123. The base unit 121 may communicate directly with one or more of the remote units 105 via communication signals. Generally, the base unit 121 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or space domains. Furthermore, the DL communication signals may be carried over 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 an 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. While a particular number and types of network functions are depicted in FIG. 1 , those skilled in the art will recognize that any number and types 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) UAVs 106 with UAV-Cs 108, where each UAV 106 provides its identity to the USS / UTM 157, which then authorizes 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 provided by NEF 146. UAS-NF 147 is supported by NEF 146 (or by both the NEF and Service Capabilities Exposure Function (“SCEF”)—denoted “NEF / SCEF”) and is 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, position reporting, and QoS / traffic filtering control 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 the UAV / UAV-C with the corresponding USS / UTM on behalf of the 3GPP network, such as the UAV Flight Enablement Subsystem (“UFES”), the NEF 146, or another suitable NF within the 3GPP network. In some embodiments, a dedicated NEF 146 may be deployed to provide only UAS-NF functionality, i.e., support UAS-specific features / APIs and NEF features / APIs specified in the capability exposure towards the USS / UTM 157.

[0053] In a 5G architecture, the UPF 141 is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting data networks ("DNs"). 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, allowing NFs to identify appropriate services from each other and communicate with each other via application programming interfaces (“APIs”)), a Network Publishing Function (“NEF”) (which is 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 AMF 143 may act as an authentication server and / or authentication proxy, thereby enabling the AMF 143 to authenticate the remote unit 105. In particular 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, etc. In yet other examples, network slices may be deployed for particular application services, vertical services, particular use cases, etc.

[0057] A network slice instance may be identified by a single network slice selection assistance information (“S-NSSAI”), while 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 their support is assumed.

[0058] In various embodiments, the remote unit 105 (e.g., part of a UAV) receives an indication of UUAA revocation (alternatively, UAS pairing and / or C2 connection revocation or UAV-UAV-C pairing authorization revocation) from the AMF 143 and / or SMF 145 in one of the N1 messages (e.g., a PDU session release command), where the remote unit 105 may receive pairing revocation information / notification with the C2 type, CAA-Level UAV ID, and UAV-C ID in one 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) 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 cancellation 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 a Pairing Authorization Request indication or a Flight Authorization Request indication along 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] While FIG. 1 depicts components of a 5G RAN and a 5G core network, the described embodiments for addressing 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 portion of the PGW ("PGW-C") or SGW+PGW-C and / or the MME, the UPF 141 could be mapped to the user plane portion 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 operations are primarily 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 within 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 revocation, 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 an 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 the 3GPP NF following the authorization revocation procedure. Applicable 3GPP NFs include the AMF 143, SMF 145, NEF 146, and UAS-NF 147 (which represents the 3GPP UAS network function for supporting aerial functionality related to UAV identification and tracking and for supporting remote identification), or any NF that coordinates UAS procedures within a 3GPP network.

[0068] The first solution considers the following two scenarios for the revocation and deletion / removal of UAS-related information in the UE (i.e., UAV / UAV-C) and the 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. Note that USS UAV authorization / authentication ("UUAA") may alternatively be referred to as UAS authentication and authorization ("UAA").

[0069] 2A-2B show an exemplary procedure 200 for UUAA revocation and removal of related security information in a UAV / UAV-C and 3GPP NFs (such as AMF, SMF, UDM, and NEF / UAS-NF) according to an embodiment of the first solution. Procedure 200 includes a UE 201 (e.g., an embodiment of a UAV's aerial UE and remote unit 105), an AMF 203 (e.g., an embodiment of AMF 143), an SMF 205 (e.g., an embodiment of SMF 145), a UDM 207 (e.g., an embodiment of UDM / UDR 149), a UAS-NF 209 (e.g., an embodiment of UAS-NF 147), and a USS / UTM server 211 (e.g., an embodiment of USS / UTM 157). In some embodiments, 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, NEF, or another suitable NF within the 3GPP network.

[0070] Starting with FIG. 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 a 3GPP UAV ID (e.g., a 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 using the received 3GPP UAV ID and setting the NF type 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 has subscribed to be notified of UUAA revocations, 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 revocation request / notification, 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, 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 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 an 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 cancellation 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 cancellation 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, SMF 205 sends a PDU session release command including the PDU session ID and CAA-Level UAV ID with the cause set as "UUAA authorization cancellation" to AMF 203. AMF 203 forwards the received PDU session release command including the PDU session ID, cause "UUAA cancellation" to UE 201 (i.e., UAV / UAV-C) (see messaging 225).

[0077] In step 4d, the UE 201 (i.e., the 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 to the UE 201 (i.e., UAV / UAV-C) with a UUAA revocation indication and a CAA-Level UAV ID (see messaging 229). The AMF 203 may delete the UUAA context to be revoked in this phase or later.

[0079] Continuing with reference to Figure 2B, in step 6, after receiving the UUAA revocation instruction, UE201 (i.e., UAV / UAV-C) deletes (see block 231) 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 Figure 2B depicts UE201 (i.e., UAV) removing / deleting locally stored UAS authorization information after receiving the UUAA revocation instruction from AMF203 in step 5, in other embodiments, UE201 (i.e., UAV) may delete locally stored UAV-related information immediately after step 4c after receiving the UUAA revocation instruction during 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 to 11 may be skipped. Note that if 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 unnecessary 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" accompanied by 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, 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, UDM207 (and / or the co-located UDR) sends a UAV AA Status Acknowledgement message to AMF203 (i.e., this may be a Nudm Service Operation message) containing the 3GPP UAV ID and the received CAA-Level UAV ID (see messaging 239). In an alternative embodiment, UDM207 (and / or the co-located UDR) sends a UUAA Status Acknowledgement message to AMF203 with the above content.

[0084] In step 9, AMF203 deletes all locally stored (i.e., available and not previously deleted) UAV-related information for CAA-Level UAV IDs and 3GPP UAV IDs, such as authorization information (tokens), UUAA authentication and authorization status information, lifespan, and security information (see block 241). Although FIG. 2B depicts AMF203 deleting the locally stored UAV-related information after receiving the UAV AA (aka UUAA) acknowledgement message, in other embodiments, AMF203 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 UAS-NF209 (i.e., in step 10).

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

[0086] In step 10, the AMF 203 sends a UUAA revocation response / acknowledgement message to the UAS-NF 209 (see messaging 243). As depicted, the revocation response / acknowledgement message may include the 3GPP UAV ID, the CAA-Level UAV ID, and the UUAA revoked indication / success indication. Alternatively, the UUAA revocation 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 revocation response / acknowledgement message to the UAS-NF 209 (i.e., if the message type implicitly indicates that a revocation has occurred), the AMF 203 does not need to also send the UUAA revoked indication / success indication in the revocation response / acknowledgement message.

[0087] In one alternative embodiment, if SMF 205 receives 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 to consider 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, if received from the AMF 203, the UAS-NF 209 sends a UUAA revoked indication / success indication to the USS / UTM server 211. 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). While 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 UE 201 (i.e., the UAV) was removed / deleted by UAS-NF 209 immediately after a previous step, e.g., after sending a UUAA revocation request to AMF 203 and / or SMF 205, UAS-NF 209 does not need to do anything other than consider the UUAA revocation successful after receiving a UUAA revocation acknowledgment from AMF 203 and / or SMF 205. Thus, in this alternative embodiment, step 11 is skipped because UAS-NF 209 is not expected to send a UAA revocation response / acknowledgment message to USS / UTM server 211. Alternatively, UAS-NF 209 may send a UUAA revocation acknowledgment to USS / UTM server 211 immediately after deleting the locally stored UAV-related information for the UE and / or after 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 revocation procedure 200 shown in Figures 2A-2B described above is also applicable to EPS with adaptations such as using an MME instead of the AMF 203, an SGW+PGW-C instead of the SMF 205, and an HSS / AuC instead of the UDM 207. In an EPS deployment, the UAS-NF 209 may be replaced by another 3GPP NF / UFES that can perform the role of the UAS-NF 209 or as a UAS control function within the 3GPP network. The 3GPP NF / UFES may be a standalone network function or may be a service provided by the SCEF+NEF in EPS instead of the NEF in 5GS.

[0092] 3A-3B show a first variant procedure 300 for UUAA revocation according to an embodiment of the first solution. Procedure 300 involves UE 201, AMF 203, SMF 205, UDM 207, UAS-NF 209, and USS / UTM server 211. In some embodiments, UAS-NF 209 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 within the 3GPP network. The steps of 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, for example 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 along with the CAA-Level UAV ID (see messaging 305). The UAS-NF 209 removes locally stored UAV-related information (if any) associated with 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, AMF 203 determines whether there is an active PDU session corresponding to the identified UAV (i.e., related to UE 201) (see block 307). If there is an active PDU session, AMF 203 decides to request a PDU session release.

[0097] In conditional step 4b, if there is a related 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. Here, SMF205 sends the CAA-Level UAV ID to UE201 (i.e., UAV) along with a UUAA revocation indication in a PDU session release command, in which 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, AMF203 further enables UUAA revocation by UE201 (i.e., UAV) using a UE Configuration Update procedure (see messaging 311). Here, AMF203 sends the CAA-Level UAV ID together with the UUAA revocation indication to UE201 (i.e., UAV) in a UE Configuration Update Command. Alternatively, based on network policy, AMF203 may trigger a network-initiated deregistration process by sending the CAA-Level UAV ID together with the UUAA revocation indication to UE201 (i.e., UAV) in a Deregistration Request message.

[0099] In step 6, after receiving the UUAA revocation instruction, the UE 201 (i.e., 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, UE 201 (i.e., UAV) further sends a UE Configuration Update Complete message to AMF 203 (see messaging 315). Here, the UE Configuration Update Complete message includes a UUAA revocation acknowledgment along with the CAA-Level UAV ID. Alternatively, if UE 201 (i.e., UAV) receives a UUAA revocation indication in a registration request message, UE 201 (i.e., UAV) sends a deregistration accept message to AMF 203 including the UUAA revocation acknowledgment along with the CAA-Level UAV ID. Alternatively, if UE 201 (i.e., UAV) receives a UUAA revocation indication in a PDU session release command, UE 201 (i.e., UAV) sends a PDU session release acknowledgment message including the UUAA revocation acknowledgment to SMF 205 along with the CAA-Level UAV ID.

[0101] In step 8, after receiving the UUAA revocation acknowledgement and the CAA-Level UAV ID, AMF203 deletes the locally stored UAS authorization and security information corresponding to the CAA-Level UAV ID (see block 317). Although Figure 3B depicts AMF203 deleting the locally stored UAV-related information after receiving the UUAA revocation acknowledgement message, in other embodiments, AMF203 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 UAS-NF209 (i.e., see step 9). Alternatively, after receiving the UUAA revocation acknowledgement and the CAA-Level UAV ID, SMF205 may consider the UUAA revocation successful and step 9 may be skipped.

[0102] In step 9, AMF 203 further sends a UUAA cancellation acknowledgement message to UAS-NF 209 with a success indication, the GPSI, and the CAA-Level UAV ID (see messaging 319). After receiving the UUAA cancellation acknowledgement, UAS-NF 209 removes any 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 revocation 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). 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., a UAV and / or UAV-C), an AMF 203, an SMF 205, and a UAS-NF 209. The procedure 400 involves the UE 401 (which may be an embodiment of a remote unit 105, a UAV 106, and / or a UAV-C 108, for example), an AMF 203, an SMF 205, a UDM 207, a UAS-NF 209, and a USS / UTM server 211. Note 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, 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, NEF, or another suitable NF within the 3GPP network.

[0106] 4A , 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 request to the UAS-NF 209 (see messaging 405). Alternatively, the USS / UTM server 211 may send the 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,” “UAV-UAVC C2,” or “TPAE C2.”

[0107] To better illustrate possible messages within procedure 400, FIG. 4A shows the message 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, UAS-NF 209 sends a Nudm_UECM_Get request message to UDM 207, where the Nudm_UECM_Get request message 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 UDM 207 in a Nudm_UECM_Get response message (see messaging 407), where it is assumed that UDM 207 identifies SMF 205 as the serving SMF.

[0109] In step 2b, the UAS-NF 209 sends the received pairing / C2 revocation request / notification message to the serving SMF 205 (see messaging 409), where the pairing / C2 revocation 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 a 3GPP UAV ID (e.g., GPSI) and a revocation C2 type indicating either “USS / UTM C2,” “UAV-UAVC C2,” or “TPAE C2.” The revocation C2 type may be in a 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, 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, 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 revocation request / notification message with a revocation C2 type, the SMF 205 checks whether there is an active PDU session corresponding to the indicated revocation 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—if available—the pairing information (pairing authorization information, paired UAV and UAV-C IDs, etc.) stored locally for the UE 401 (i.e., UAV / UAV-C) corresponding to that CAA-Level UAV ID, and update the UAV pairing status information accordingly (e.g., the pairing status can change from “pairing allowed” to “pairing authorization requested / pairing not allowed”).

[0113] In step 4a, SMF205 sends a PDU session release command to AMF203 containing the PDU session ID and the 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, SMF205 sends a PDU session release command to AMF203 containing the PDU session ID and the 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, AMF 203 forwards a PDU Session Release command to 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 the cause as "pairing cancellation", the UE401 (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 pairing of the UAV and UAV-C indicated in the cancellation information.

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

[0118] 4B , in step 6, the UE 401 (i.e., the 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., the 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 the locally stored pairing information (such as pairing permission information and paired UAV and UAV-C IDs) for the UE401 (i.e., UAV / UAV-C) corresponding to that CAA-Level UAV ID, if available, and updates the UAV pairing status information accordingly (e.g., pairing status can change from "pairing allowed" to "pairing permission requested / pairing not allowed") (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 associated with 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, AMF203 further sends a PDU session release acknowledgement message to SMF205 with the 3GPP UAV ID, the received pairing cancellation acknowledgement indication / success indication, and the CAA-Level UAV ID (see messaging 423). Alternatively, AMF203 sends a PDU session release acknowledgement message to SMF205 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 (such as pairing authorization information and paired UAV and UAV-C IDs) for the UE 401 (i.e., UAV / UAV-C) corresponding to that CAA-Level UAV ID, and updates the UAV pairing status information accordingly (e.g., the pairing status can change from “pairing authorized” to “pairing authorization requested / pairing not authorized”). In addition, the SMF 205 sends a pairing cancellation acknowledgement / acknowledgement to the UAS-NF 209 with the received 3GPP UAV ID, a success indication, and the CAA-Level UAV ID (see messaging 425).

[0123] Alternatively, after receiving the C2 revocation acknowledgement indication, the SMF deletes any 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"). 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] To better illustrate the possible messages within procedure 400, the message is shown in FIG. 4A as "Pairing / C2 Revocation Response / Acknowledgement." Such a message 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 along 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, if any, stored locally for the corresponding UAV ID. Alternatively, the UAS-NF forwards the received C2 cancellation response / acknowledgement message to the USS / UTM server 211 along 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 the pairing cancellation response / acknowledgement message to the USS / UTM server 211 while already in step 2b. 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 such as using an MME instead of the AMF 203, an SGW+PGW-C instead of the SMF 205, and an HSS / AuC instead of the UDM 207. In an EPS deployment, the UAS-NF 209 may be replaced by another 3GPP NF / UFES that can perform the role of the UAS-NF 209 or as a UAS control function within the 3GPP network. The 3GPP NF / UFES may be a standalone network function or may be a service provided by the SCEF+NEF in EPS instead of the 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 that handles the UAV / UAV-C (or holds 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. 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 / revoke) request at a later time. Procedure 500 involves a UE 201 (e.g., embodied in a UAV), an AMF 203, a UDM / UDR 501 (e.g., which may be an embodiment of 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 the corresponding USS / UTM on behalf of the 3GPP network, such as a UFES, a NEF, or another suitable NF within 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, AMF 203 provides the CAA-Level UAV ID to 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, AMF 203 sends a UAS AA request to 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 successful primary authentication with the air payload, which then causes the SMF to send the above-mentioned 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 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 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 re-authenticate and re-authorize the UE 201 (i.e., the UAV) or perform 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) (identified in the locally stored 3GPP NF routing information) to the UAS-NF 209 by including the 3GPP UAV ID (i.e., GPSI), the CAA-Level UAV ID, and a cause indicating “UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change” (see messaging 521).

[0139] In conditional step 9, after receiving the UAS re-authentication / authentication request, UAS-NF 209 forwards the UAS re-authentication request to Serving AMF 203 (and / or 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., UAS-NF 209 retrieves the UE / UUAA context corresponding to the CAA-Level UAV ID and / or 3GPP UAV ID). If UAS-NF 209 does not have locally stored Serving AMF / SMF information for UE 201 (i.e., UAV), a Nudm_UECM_Get request / response service operation may be used to fetch the Serving AMF / SMF information for UE 201 (i.e., 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, the 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 the case of pairing re-authorization, the UAS re-authentication request may also include a target pairing ID (e.g., new UAV-C information and / or Third Party Accreditation Authority ("TPAE") information, etc.). Alternatively, in the 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 / authentication request, AMF203 (and / or SMF) triggers to perform UUAA or pairing authorization (or re-authorization) (see block 527). Alternatively, the SMF sends the received UAS re-authentication / authentication request to the serving AMF203 together 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 a cause value with "UAS AA / C2 re-authentication or pairing re-authorization / authorization or UAV-C change".

[0143] In step 12, AMF203 sends a NAS MM transport message to UE201 (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 a pairing authorization indication is received in step 13b with authorization data and a cause value indicating "Pairing / C2 Authorized," the UE 201 (i.e., UAV) updates its locally stored pairing authorization information with the received new authorization (or re-authorization) information and performs PDU session establishment / modification. Procedure 500 ends. While FIGS. 5A-5B depict a UE embodied in a UAV and are described in the above description, 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) can 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 can 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 such as using an MME instead of the AMF 203, using an SGW+PGW-C instead of the SMF, and using an HSS / AuC instead of the UDM 207. In an EPS deployment, the UAS-NF 209 may be replaced by another 3GPP NF / UFES that can perform the role of the UAS-NF 209 or as a UAS control function within the 3GPP network. The 3GPP NF / UFES may be a standalone network function or may be a service provided by the SCEF+NEF in EPS instead of the 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. The 3GPP NFs (i.e., AMF and SMF) receive session security information from the USS / UTM (via the UAS-NF / NEF / UFES) after successful pairing authentication, and send 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 such as using an MME instead of the AMF 203, using an SGW+PGW-C instead of an SMF, and using an HSS / AuC instead of a UDM / UDR. In an EPS deployment, the UAS-NF may be replaced by another 3GPP NF / UFES that can perform the role of the UAS-NF or of a UAS control function within the 3GPP network. The 3GPP NF / UFES may be a standalone network function or may be a service provided by the SCEF+NEF in EPS instead of the NEF in 5GS.

[0151] 6A-6C illustrate a procedure 600 for UAV and UAV-C pairing / association authorization on the control plane and related security setup according to a third solution. As depicted, 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 the 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, NEF, or another suitable NF within the 3GPP network. The steps of procedure 600 are described as follows:

[0152] Starting with Figure 6A, it is assumed as a prerequisite that UAV603 and UAV-C601 are registered with the 3GPP network (see blocks 611 and 613) and that both UAV603 and UAV-C601 have successfully performed UAS authentication and authorization (see blocks 615 and 617) with USS / UTM server 211. Although Figure 6A illustrates that UAV-C601's 3GPP registration and PDU session establishment occurs before UAV603's 3GPP registration and PDU session establishment, UAV603 may register and / or establish a PDU session before UAV-C601 - or both registration and / or PDU session establishment may occur in parallel / simultaneously. Similarly, while 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 601 may be connected to USS / UTM server 211 over the Internet rather than a 3GPP network as shown.

[0153] In step 1, UAV603 sends a PDU session establishment request to AMF / SEAF605 along with pairing authorization request information (see messaging 619), where the pairing authorization request information includes a UAV ID, a target UAV-C ID, a UAS ID, a UAV authorization token, and a UAS security information identifier (i.e., an 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, UAV 603 also transmits a pairing request indication. Note that throughout the description of the third solution, information transmitted as "pairing permission request information" may also be transmitted as part of a UAV operation request / payload. Similarly, throughout the description of the third solution, information transmitted as "pairing permission response information" may also be transmitted as part of a UAV operation response information and / or a 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 to be 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, 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 along 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. Furthermore, the SMF 205 sends a pairing authorization request to the UAS-NF 209, where the request includes the UAV ID, target UAV-C ID, UAS ID, UAV authorization token, UAV IP address (i.e., set by the SMF for the PDU session), and 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 along 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, said 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 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 to verify it (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, the UAV ID, the UAV-C ID, the UAS ID, the 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] Continuing to refer to FIG. 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, 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 / SEAF 605 locally stores the UAV ID and UAV-C ID in addition to the corresponding 3GPP UAV ID of the UAV 603 along with the pairing permission status and UAS ID (see block 641).

[0170] In step 13, the AMF / SEAF 605 sends an Nsmf_PDUSession_CreateSMContext request message containing a pairing request indication with the UAV ID and UAV-C ID to the SMF 205 with a "pairing allowed successful" indication (see messaging 643). In addition, this message may also include the UAV-C IP address if 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 response message includes a pairing authorization success indication and a pairing indication with the UAV ID and UAV-C ID (see messaging 647).

[0173] In the above alternative case, after step 11, upon receiving the pairing authorization response / pairing authorization accept message, SMF 205 locally stores the UAV ID, UAV-C ID, pairing authorization status information, PDU session ID, and UAV and UAV-C IP addresses. Furthermore, SMF 205 performs N4 session setup for the paired UAV 603 and UAV-C 601. In addition, SMF 205 sends an Nsmf_PDUSession_CreateSMContext response (alternatively, a PDU session establishment response) to AMF / SEAF 605 (see messaging 647), which includes the pairing authorization success indication, session security information, UAS ID, and pairing indication received along 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 exemplary procedure 700 for C2 / pairing authorization on the user plane by a 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 the pairing authorization result 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 the 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 the 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 corresponding USSs / UTMs on behalf of the 3GPP network, such as a UFES, NEF, or another suitable NF within the 3GPP network.

[0178] 7A-7C depict the UAV as connecting to the USS / UTM server 211 through a 3GPP network separate from that used by the UAV-C, in other embodiments, the UAV and UAV-C connect to the USS / UTM server 211 through 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 procedure 700 are described as follows:

[0179] 7A, it is assumed as a prerequisite that UE 701 (i.e., embodied as a UAV) and UE 711 (i.e., embodied as a UAV-C) perform primary authentication and UUAA with USS / UTM server 211 (see blocks 715 and 717). Furthermore, UE 701 (i.e., UAV) and UE 711 (i.e., UAV-C) have established PDU sessions with USS / UTM server 211, and therefore, when C2 or UAV / UAV-C pairing is requested, UE 701 (i.e., UAV) and even UE 711 (i.e., UAV-C) can perform pairing authorization with USS / UTM server 211 over the established PDU session (i.e., over the established user plane connection) (see blocks 719, 721, and 723). Although FIG. 7A illustrates that the 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 / simultaneously. 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 / simultaneously for both devices.

[0181] The USS / UTM server 211 still needs to inform the 3GPP network (e.g., UAS-NF705 / 707 and / or AMF / SMF703 / 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 UE701 (i.e., UAV) and UE711 (i.e., UAV-C).

[0182] In step 1, the UE 701 (i.e., the UAV) sends a PDU session establishment request to the AMF / SMF#1 703 (see messaging 725), which includes 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 jointly indicate the UAV and UAV-C pair. In some embodiments, the USS / UTM server 211 may provide the UAS ID to the UE 701 (i.e., the UAV) at any time during UUAA or pre-configuration (if any), even before pairing authorization occurs.

[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, which includes 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 to USS / UTM server 211 (see messaging 731), 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 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., the 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 message 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, 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., UAV) (see messaging 745). Furthermore, 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 via the UAS-NF#1 705 in a C2 Pairing Acknowledgement message (see messaging 747).

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

[0195] Referring to the right side of Figure 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 a device trigger based on the fourth solution (described in further detail below) to trigger a 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 stores the pairing permission status locally (see messaging 755), for example based on the information received in step (b).

[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] Continuing to refer to Figure 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). Furthermore, 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, the pairing complete message including the UAV IP address (see messaging 767).

[0204] Referring now 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, the pairing complete message including 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 in order to enable UAS services.

[0207] It is assumed that the UAV and UAV-C have already successfully registered with the USS / UTM (and have UAS authorization and security information provided by the USS / UTM). The UAV shall include pairing authorization request information, including the CAA-level UAV ID, UAV-C ID, authorization token, UAS ID, and security context ID, in a PDU session establishment request message to the SMF along with the UAV operation request. The SMF can then send the UAV operation request along with the received pairing authorization request information to the UFES, which forwards it to the USS / UTM. The UAV operation request procedure 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 can be pre-configured on the UAV with the provision of a CAA-level UAV ID (outside the scope of 3GPP) as a prerequisite.

[0209] 8A-8B depict an exemplary procedure 800 for UAV and UAV-C pairing authorization and session security setup according to a first variant of the third solution. As depicted, 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 and corresponding (e.g., co-located) Security Anchor Function (“SEAF”) depicted as a combined node “AMF / SEAF” 805, an SMF 205, 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 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, NEF, or another suitable NF within the 3GPP network. The steps of procedure 800 are as follows:

[0210] Starting with FIG. 8A, as a prerequisite, 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 USS / UTM server 211 and established a PDU session with USS / UTM server 211 (see blocks 815 and 817). While FIG. 6A illustrates that UAV-C 601's 3GPP registration and PDU session establishment occurs before UAV 603's 3GPP registration and PDU session establishment, UAV 603 may register and / or establish a PDU session before UAV-C 601—or both registration and / or PDU session establishment may occur in parallel / simultaneously. Similarly, while 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 USS / UTM server 211 over the internet or another data network outside the 3GPP network.

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

[0212] In step 2, after receiving the PDU session establishment request with the pairing authorization request information, the 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, the AMF / SEAF805 considers this check successful and performs step 3. However, if the 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, the AMF / SEAF805 triggers UUAA and / or sets an "authorization information mismatch indication" as described in the fourth solution.

[0213] In step 3, the AMF / SEAF 805 sends an Nsmf_PDUSession_CreateSMContext request to the SMF 205 with the received pairing authorization request information, including the 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 operation 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," SMF205 sends a PDU session establishment reject message to AMF / SEAF805 in an N1SM container, and AMF / SEAF805 sends the 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 action 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-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 USS / UTM server 211 (see messaging 833), the response message including 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] Continuing to refer to FIG. 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 response message 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 together with the received pairing authorization response information, and this response message includes a success indication, UAV ID, UAV-C ID, 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 UAV-C 801 use the received session security information to set up a secure connection between the UAV 803 and UAV-C 801 for the C2 connection (see block 851). The procedure 800 ends.

[0228] 9A-9B depict an exemplary procedure 900 for UAV and UAV-C pairing permission revocation according to a second variation 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 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 within 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), said message including 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, SMF 205 checks whether there is an active PDU session corresponding to the CAA-Level UAV ID indicated together with the UAV-C ID. If there is an active PDU session, 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 UAV-C ID. Alternatively, after receiving the pairing cancellation notification, SMF205 may further delete 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), and this command message includes pairing cancellation information including the PDU session ID, the preferred cause value, and the CAA-Level UAV ID and UAV-C ID.

[0235] In step 5, after receiving the PDU session release command together with the pairing revocation information, the UE201 (i.e., UAV) 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, AMF203 deletes the locally stored pairing information (such as pairing permission information and paired UAV and UAV-C IDs, if available) for UE201 (i.e., UAV) corresponding to its CAA-Level UAV ID. Furthermore, AMF203 sends a PDU session release acknowledgement message to SMF205 with the GPSI, the received pairing cancellation 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). 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 in accordance with an embodiment of the fourth solution. 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 “SMS-SC”) 1003, an AMF and / or SMF (denoted 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, 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, NEF, or another suitable NF within 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-10B, 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 procedure 1000 are as follows:

[0244] 10A, in step 1, the USS / UTM server 211 determines that the UE 1001 (i.e., the UAV / UAV-C device) needs to be triggered (see block 1011). If the USS / UTM server 211 does not have contact details for the NEF and / or UAS-NF 209 (also known as the NEF), it discovers and selects an 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 previously done) 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 a pairing authorization request indication is sent)), 3GPP UAV ID} (see messaging 1013). To illustrate the different possibilities, the accompanying service operation may be a UAS-NF service operation (i.e., using the "Nuasnf" service operation prefix), a NEF service operation (i.e., using the "Nuasnf" service operation prefix), a NEF service operation (i.e., using the "Nuasnf" service operation prefix), a 3GPP Application Function ("AF") service operation (i.e., using the "Naf" service operation prefix), or another 3GPP NF service operation (i.e., using the "N3gppnf" service operation prefix, or using any other service operation 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 trigger requests and that the USS / UTM server 211 has not exceeded its 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. Otherwise, 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 invoke 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 the 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 (also known as the 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 to step 6.

[0250] In step 6, the UAS-NF209 calls Nudm_UECM_Get(SUPI,SMS) to retrieve the 5G SMS function ("SMSF") ID of the UE1001 (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 policy (possibly dependent on the visited PLMN ("VPLMN") ID) may influence 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, acting as an MTC interworking function ("MTC-IWF"), sends a Submit Trigger message (i.e., including GPSI, SUPI, USS / UTM identifier, trigger reference number, validity period, priority, SMSF serving node ID (if available, these were obtained from the UDM in step 7), SMS application port ID, UAS trigger payload (received UAS payload), and trigger instruction parameters) to the SMS-SC 1003.

[0253] If the UAS-NF 209 indicates that an "absent 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 SMS submission 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 the 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 later 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, in accordance with an embodiment of the present 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 device(s) 1115 and the output device(s) 1120 are combined into a single device, such as a touchscreen. In some embodiments, the user equipment device 1100 may not include the input device(s) 1115 and / or the output device(s) 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 device(s) 1115 and / or the output device(s) 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 capable of operating over an unlicensed spectrum. Furthermore, the transceiver 1125 may comprise multiple UE panels supporting one or more beams. Additionally, 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 sends 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 the 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 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. 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, 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, memory 1110 stores data related to location-aware beam selection and / or mobile operation. For example, memory 1110 may store various parameters, panel / beam configurations, resource allocations, policies, and the like, as described above. In some embodiments, memory 1110 also stores program code and related data, such as an operating system or other controller algorithms, running on 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] Output device(s) 1120, in one embodiment, is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device(s) 1120 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device(s) 1120 may include, without limitation, a liquid crystal display ("LCD"), a light-emitting diode ("LED") display, an organic LED ("OLED") display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another non-limiting example, output device(s) 1120 may include a wearable display that is separate from but communicatively coupled to the rest of user equipment device 1100, such as a smartwatch, smart glasses, a head-up display, or the like. Furthermore, output device(s) 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(s) 1120 include one or more speakers for generating sound. For example, the output device(s) 1120 may generate audible alerts or notifications (e.g., beeps or chimes). In some embodiments, the output device(s) 1120 include one or more haptic devices for generating vibrations, movements, or other haptic feedback. In some embodiments, all or a portion of the output device(s) 1120 may be integrated with the input device(s) 1115. For example, the input device(s) 1115 and the output device(s) 1120 may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device(s) 1120 may be located near the input device(s) 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 and receive messages, data, and other signals. For example, the processor 1105 may selectively activate the transceiver 1125 (or portions 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 the UL transmissions 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 communication network over a licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communication network over an unlicensed radio spectrum.

[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 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 onto a single chip along 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 touchscreen. In some embodiments, the network appliance 1200 may not include the input device(s) 1215 and / or the output device(s) 1220. In various embodiments, the network appliance 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 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 those skilled 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, network device 1200 is a RAN node (e.g., gNB) that communicates with one or more UEs as described herein. In such embodiments, processor 1205 controls network device 1200 to perform the RAN behavior described above. When operating as a RAN node, processor 1205 may include an application processor (also referred to as a “main processor”) that manages application domain and operating system (“OS”) functions, and a baseband processor (also referred to as a “baseband radio processor”) that manages radio functions.

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

[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 instruction 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 the 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 the UAS pairing (e.g., UAV / UAV-C pairing or 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 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 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”).

[0289] In some embodiments, sending the revocation indication to the UE includes sending a PDU session modify 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 that includes 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 the contents of the pairing authorization response in 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, processor 1205 controls apparatus 1200 to perform the UAS-NF behaviors described above. In some embodiments, transceiver 1225 (i.e., supporting network interface 1245) receives a UUAA request from the first NF (e.g., from the AMF and / or SMF), the UUAA request including 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 message exchanges related to the UAV and / or UAV-C with the USS / UTM (e.g., UUAA and C2 pairing relationship 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, after receiving the revocation message, the processor 1205 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 cancellation 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 cancellation message to the SMF includes sending one or more of the CAA-level UAV ID, the 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 indicating re-authentication of the UE, and D) combinations thereof. In such embodiments, the processor 1205 forwards (via the transceiver 1225) 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 the first NF (e.g., the AMF), and the processor, in response to verifying that the UE is authorized to request pairing authorization, forwards the pairing authorization request to the USS / UTM (via the transceiver 1225). 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 transceiver 1225 further receives a pairing authorization response from the USS / UTM and forwards the pairing authorization response to the first NF (e.g., the 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 a volatile computer storage medium. For example, memory 1210 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 1210 includes a non-volatile computer storage medium. For example, memory 1210 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 1210 includes both volatile and non-volatile computer storage 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, running on device 1200.

[0304] The input device(s) 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(s) 1215 may be integrated with the output device(s) 1220, for example, as a touch screen or similar touch-sensitive display. In some embodiments, the input device(s) 1215 include 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(s) 1215 include two or more different devices, such as a keyboard and a touch panel.

[0305] Output device(s) 1220, in one embodiment, is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device(s) 1220 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device(s) 1220 may include, but are not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another non-limiting example, output device(s) 1220 may include a wearable display that is separate from but communicatively coupled to the rest of network apparatus 1200, such as a smartwatch, smart glasses, a head-up display, or the like. Furthermore, 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, output device(s) 1220 include one or more speakers for generating sound. For example, output device(s) 1220 may generate audible alerts or notifications (e.g., beeps or chimes). In some embodiments, output device(s) 1220 include one or more haptic devices for generating vibrations, movement, or other haptic feedback. In some embodiments, all or a portion of output device(s) 1220 may be integrated with input device(s) 1215. For example, input device(s) 1215 and output device(s) 1220 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device(s) 1220 may be located near 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 public land mobile network ("PLMN") and / or network functions within 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 types of transmitters and receivers.

[0308] 13 illustrates one embodiment of a method 1300 for handling security aspects for a UAS in a 3GPP network in accordance with embodiments of the present disclosure. In various embodiments, method 1300 is performed by a communication device within 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, method 1300 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

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

[0310] 14 illustrates one embodiment of a method 1400 for handling security aspects for a UAS in a 3GPP network in accordance with embodiments of the present disclosure. In various embodiments, 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, method 1400 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

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

[0312] 15 illustrates one embodiment of a method 1500 for handling security aspects for a UAS in a 3GPP network, according to embodiments of the present disclosure. In various embodiments, method 1500 is performed by a network function within a communications network, such as NEF 146, UAS-NF 147, UAS-NF 209, UAS-NF#1 705, UAS-NF#2 707, and / or network device 1200, as described above. In some embodiments, method 1500 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, 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 with the USS / UTM (e.g., UUAA and UAV / UAV-C pairing authorization). 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 within 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. 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 sends 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 within 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. 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 the 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 a 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 the 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, described above. Alternatively, in the case of EPS, the network entity may be implemented by the control plane portion of a PGW / SMF+PGW-C and / or for an MME. The second apparatus includes a processor and a transceiver configured to receive a revocation message (e.g., a UUAA revocation or UAS pairing revocation message) including a UAV ID and to send a revocation indication to a UE in response to the revocation message. The processor deletes a UAS context corresponding to the revocation message, and the transceiver receives a revocation acknowledgment 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 instruction 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 the 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 the UUAA / pairing cancellation request.

[0325] In some embodiments, the cancellation message cancels the UAS pairing (e.g., UAV / UAV-C pairing or C2 association) corresponding to the UAV ID. In such embodiments, sending the cancellation 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 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 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”).

[0327] In some embodiments, sending the revocation indication to the UE includes sending a PDU session modify 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 the contents of the pairing authorization response in 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 a 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 the 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. Alternatively, in the case of EPS, the network entity may be implemented by the control plane portion 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 corresponding to the revocation message and receiving a revocation acknowledgment from the UE.

[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 instruction 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 the 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 the 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 the UUAA / pairing cancellation request.

[0335] In some embodiments, the cancellation message cancels the UAS pairing (e.g., UAV / UAV-C pairing or C2 association) corresponding to the UAV ID. In such embodiments, sending the cancellation 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 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 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”).

[0337] In some embodiments, sending the cancellation indication to the UE includes sending a PDU session modify 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 embodiments, 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 a 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 device 1200, described above. The third apparatus comprises a processor and a transceiver (i.e., supporting a network interface) that receives 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 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 with the USS / UTM (e.g., UUAA and UAV / UAV-C pairing authorization).

[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 cancellation 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 cancellation message to the SMF includes sending one or more of the CAA-level UAV ID, the 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 indicating re-authentication of the UE, and D) combinations 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 for 5GS, or to the MME and / or SMF+PGW-C for EPS).

[0349] In some embodiments, the transceiver receives a pairing authorization request from the first NF (e.g., AMF), and the processor, in response to verifying that the UE is authorized to request pairing authorization, forwards the pairing authorization request to the USS / UTM (via the transceiver). 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 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 a 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., an 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) a 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 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.

[0351] In some embodiments, a third method includes receiving a revocation message (e.g., UUAA revocation or pairing revocation) from a USS / UTM, where the revocation message includes a UAV ID (e.g., a CAA-level UAV ID), and sending the revocation message to a first NF (e.g., to an AMF / SMF in the case of 5GS or to an 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 at 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 cancellation 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 cancellation message to the SMF includes sending one or more of the CAA-level UAV ID, the 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., an 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., an 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 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 701 UE 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" 711 UE 800 Procedures 801 UAV-C 803 UAV 805 Combined Node "AMF / SEAF" 900 steps 1000 steps 1001UE 1003 Short Message Service ("SMS") Service Center ("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 Device 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. 1. A method of communication device in an unmanned aerial system ("UAS"), comprising: receiving a revocation instruction message from a mobile communications network; deleting UAS-related authorization and security information corresponding to the UAV ID; sending a revocation acknowledgement message to the mobile communications network; A method comprising:

2. The UAV ID includes a CAA-level UAV ID; The UAS-related authorization and security information: UUAA results, Pairing / C2 permission results, UUAA permission information, security keys, token, lifespan, Pairing information, Pairing permission result, C2 association information, C2 association permission results, UAS security information, session security key material, a session security token, and A combination of these 10. The method of claim 1, comprising one or more of:

3. The cancellation instruction message cancels the UUAA for the UAV ID; 2. The method of claim 1, wherein the step of deleting UAS-related authorization and security information comprises deleting authorization information and security context received after a successful UUAA.

4. The cancellation instruction message cancels the UAS pairing corresponding to the UAV ID; The method of claim 1 , wherein the step of deleting UAS-related authorization and security information includes deleting pairing authorization information and session security information received after a successful UAS pairing procedure between the UAV and the UAV-C.

5. 1. A method in a communications network, comprising: receiving a revocation message including the UAV ID; sending a cancellation indication to the UE in response to the cancellation message; deleting a UAS context corresponding to the revocation message; receiving a cancellation acknowledgement from the UE; A method comprising:

6. The cancellation instruction message includes a UUAA cancellation message that cancels the UUAA for the UAV ID; sending the cancellation indication includes sending a UE Configuration Update ("UCU") command to the UE; The step of deleting the UAS context includes deleting one or more of authorization information and a security context received after a successful UUAA; The UAV ID includes one or more of a network-level UAV ID (i.e., 3GPP UAV ID / SUPI / GPSI) and a CAA-level UAV ID; The method determining whether an active data connection corresponds to a UUAA / pairing cancellation message; releasing the active data connection in response to determining that the active data connection corresponds to a UUAA / pairing cancellation request; The method of claim 5 further comprising:

7. The revocation message revoks the UAS pairing corresponding to the UAV ID; the step of sending the cancellation instruction includes the step of sending a PDU session release command; The method of claim 5, wherein the step of deleting the UAS context includes deleting one or more of pairing authorization information and session security information received after a successful UAS pairing procedure between the UAV and the UAV-C.

8. The revocation message includes a pairing update message for the UAV ID; the pairing update message includes new pairing permission information, and one or more of a UAV-C ID and a cause value “UAV-C Exchange”; sending the cancellation indication to the UE includes sending a PDU session modification command; The method of claim 5 , further comprising updating the UAS pairing corresponding to the UAV ID based on the new pairing permission information.

9. The UAS context UUAA results, Pairing / C2 permission results, UUAA permission information, security keys, token, lifespan, Pairing information, Pairing permission result, C2 association information, C2 association permission results, UAS security information, session security key material, a session security token, and A combination of these 6. The method of claim 5, comprising one or more of:

10. receiving a re-authentication request message from the UAS-NF, the re-authentication request message comprising: Network-level UAV ID; CAA-level UAV ID and a cause value indicating re-authentication of the UE; and sending a NAS message to the UE, the NAS message comprising: UAV ID request; an indication indicating that re-authentication of the UE is required; Including steps and The method of claim 5 further comprising:

11. 1. A method in a communications network, comprising: receiving a UUAA request from a first NF, the UUAA request including one or more of a network-level UAV ID, a subscription permanent identifier, and a CAA-level UAV ID; Associating the subscription permanent identifier with a CAA-level UAV ID and a network-level UAV ID; sending a second UUAA request to the USS / UTM, the second UUAA request including routing information for a network function that handles UAV and / or UAV-C related message exchanges with the USS / UTM; A method comprising:

12. receiving a cancellation message from the USS / UTM, the cancellation message including a UAV ID; sending the revocation message to the first NF; receiving a response message from the first NF, the response message including the UAV ID and a revocation success indication; deleting any UAS-related information and UAV ID stored locally for the UAV after receiving the revocation message; triggering a UAS authentication status update in the USS / UTM; The method of claim 11 further comprising:

13. The revocation message includes a pairing update message for the UAV ID; the pairing update message includes one or more of a UAV-C ID, new pairing permission information, and a cause value “UAV-C Exchange”; 13. The method of claim 12, wherein the step of sending the revocation message to the first NF includes sending the pairing update message to a serving network function corresponding to the UAV ID.

14. the first NF comprises one of an AMF and an SMF; The cancellation message includes a UUAA cancellation message that cancels a UUAA for the UAV ID when the first NF is the AMF; The UAV ID includes at least one of a network-level UAV ID and a CAA-level UAV ID; The cancellation message cancels a UAS pairing corresponding to the UAV ID when the first NF is the SMF; The method of claim 12, wherein 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 of the UAV.

15. receiving a re-authentication request message from the USS / UTM, the re-authentication request message comprising: Network-level UAV ID; CAA-level UAV ID and A cause value that indicates re-authentication of the UE and and forwarding the re-authentication request message to a first NF; 12. The method of claim 11, further comprising:

Images