Permission for unmanned aerial vehicles

Abstract

Apparatus, systems, and methods for receiving authorization for an unmanned aerial vehicle (UAV) are disclosed. One method (700) includes receiving (705) a first request from an access and mobility management function (143), the first request including an indication to establish user plane resources for unmanned aerial system ("UAS") services for the UAV device (106). The method further includes retrieving (710) subscription information from an integrated data management (149) node, the subscription information indicating that UAV authorization is required by a UAS service subscriber (157) and / or a UAS traffic management (157) server, and sending (715) a second request to a UAS network function (147) initiating UAV authorization.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 137,039, filed on January 13, 2021, for Dimitrios Karampatsis et al., titled "METHOD TO EXCHANGE UAV CREDENTIALS BETWEEN A UAV AND 3GPP NETWORK FOR UAV AUTHORIZATION", which is incorporated herein by reference.

[0002] The subject matter disclosed herein generally relates to wireless communication and, more specifically, to receiving authorization for an unmanned aerial vehicle (UAV) (e.g., from a 3GPP network).

Background Art

[0003] Unmanned Aerial Vehicle System Service Supplier (USS) Unmanned Aerial Vehicle (UAV) Authorization / Authentication (UUAA) can be performed by a 3GPP network, for example, when a UAV registers with the 3GPP network or when a UAV transmits a request to establish a data connection (e.g., a Packet Data Unit (PDU) session) with the 3GPP network. In order for a UAV to request resources for UAV operation from the 3GPP network, the UAV needs to have a pre - flight authorization from an Unmanned Aerial Vehicle System Traffic Management (UTM) system. This approach is cumbersome considering that an Unmanned Aerial Vehicle System (UAS) operator needs to request a flight authorization for the UAV from the UTM before issuing a request for a PDU session with the 3GPP network for UAV operation.

Summary of the Invention

Means for Solving the Problems

[0004] Disclosed are devices, systems, and methods for receiving UAV authorization for an unmanned aerial vehicle ("UAV"). One method includes receiving a first request from an Access and Mobility Management Function ("AMF"), the first request including instructions to establish a user plane resource for an unmanned aerial vehicle system ("UAS") service for a UAV device; retrieving subscription information from an Integrated Data Management Node ("UDM"), the subscription information indicating that UAV authorization is required by a UAS Service Subscriber ("USS") and / or a UAS Traffic Management ("UTM") server; and sending a second request to a UAS Network Function ("UAS-NF") to initiate UAV authorization.

[0005] Another method for receiving UAV authorization for a UAV includes receiving a first request to authenticate the UAV device to a UAS service, determining whether the UAV device has valid UAV authorization by checking a database that stores information on successfully authorized UAVs, determining an external identifier for the UAV device based on a second identifier, and sending a second request to authenticate the UAV device in a UTM system, the second request including the external identifier and the second identifier. This method further includes receiving the UAV authorization result for the UAV device from the UTM system and storing in a database a UAV context indicating that the UAV device is authorized to the UAS service, the UAV context including one or more of the external identifier and the second identifier.

[0006] Another method for receiving UAV authorization for a UAV includes receiving a registration request to establish one or more user plane resources for UAS services for the UAV device, and determining whether the UAV device has valid prior UAV authorization by checking locally stored user equipment ("UE") context. This method further includes initiating a UAV authorization procedure in response to determining that no valid UAV authorization is stored for the UAV device, transmitting a first request to a session management function ("SMF"), the first request including instructions to establish one or more user plane resources for UAS services for the UAV device, receiving UAV authorization for the UAV device from the SMF, the UAV authorization being approved by the UTM system, and transmitting the UAV authorization to the UAV device.

[0007] A more detailed description of the embodiments briefly outlined above is provided by referring to the specific embodiments illustrated in the accompanying drawings. Please understand that these drawings depict only a few embodiments, and this should not be considered limiting in scope. The descriptions and explanations of the embodiments are provided through the use of these drawings, adding specific details and information. [Brief explanation of the drawing]

[0008] [Figure 1] This is a block diagram illustrating one embodiment of a wireless communication system for receiving UAV permission for unmanned aerial vehicles. [Figure 2A] This is a signal flow diagram illustrating one embodiment of a procedure that supports UUAA and / or C2 authorization during PDU session establishment. [Figure 2B] This figure shows the continuation of the procedure in Figure 2A. [Figure 2C] This figure shows the continuation of the procedure in Figures 2A and 2B. [Figure 2D]This figure shows the continuation of the steps in Figures 2A, 2B, and 2C. [Figure 3A] This is a signal flow diagram illustrating one embodiment of the procedure for supporting UUAA during registration. [Figure 3B] This figure shows the continuation of the procedure in Figure 3A. [Figure 3C] This figure shows the continuation of the procedure in Figures 3A and 3B. [Figure 3D] This figure shows the continuation of the steps in Figures 3A, 3B, and 3C. [Figure 4] This is a block diagram illustrating one embodiment of the UAS architecture in a 3GPP system. [Figure 5] A block diagram illustrating one embodiment of a user equipment that may be used to receive UAV authorization for a UAV is shown. [Figure 6] This is a block diagram illustrating one embodiment of a network equipment that may be used to receive UAV authorization for a UAV. [Figure 7] This flowchart illustrates one embodiment of a method for receiving UAV authorization for a UAV. [Figure 8] This flowchart illustrates another embodiment of a method for receiving UAV authorization for a UAV. [Figure 9] This flowchart illustrates yet another embodiment of a method for receiving UAV authorization for a UAV. [Modes for carrying out the invention]

[0009] As those skilled in the art will understand, aspects of these embodiments can be embodied as systems, apparatus, methods, or program products. Accordingly, embodiments can take the form of embodiments that are entirely hardware, embodiments that are entirely software (including firmware, resident software, microcode, etc.), or embodiments that combine aspects of software and hardware.

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

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

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

[0013] More specific examples of storage devices (a non-exclusive list) would include electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM") or flash memory, portable compact disk read-only memory ("CD-ROM"), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store programs used by or in combination with instruction execution systems, apparatus, or devices.

[0014] The code for performing the operation of the embodiment may be of any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, or similar, and conventional procedural programming languages ​​such as the C programming language or similar, and / or machine language such as assembly language. The code may run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or on a computer or server that is completely remote. 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") or a wide area network ("WAN"), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider).

[0015] Furthermore, the features, structures, or characteristics described in the embodiments can 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., in order to provide a complete understanding of the embodiments. However, those skilled in the art will understand that the embodiments can be implemented without one or more of the specific details or using other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not illustrated or described in detail so as not to obscure the aspects of the embodiments.

[0016] References throughout this specification to "one embodiment", "an embodiment", or similar phrases mean that the particular feature, structure, or characteristic described in relation to that embodiment is included in at least one embodiment. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" and similar phrases throughout this specification are not necessarily all referring to the same embodiment, but unless otherwise stated, they mean "one or more, but not all, embodiments". The terms "comprising", "including", "having", and variations thereof mean "including but not limited to" unless otherwise stated. An enumerated listing of items does not imply that any or all of the items are mutually exclusive unless otherwise stated. Also, the English original article words "a", "an", and "the" refer to "one or more" unless otherwise stated.

[0017] As used herein, lists containing the conjunction "and / or" include any single item in the list or any combination of items in the list. For example, the list A, B and / or C 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. As used herein, lists using the phrase "one or more of" include any single item in the list or any combination of items in the list. For example, one or more of A, B, and C 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. As used herein, "one of" includes just one of any single items in the list. For example, "one of A, B, and C" includes A only, B only, or C only, and excludes the combination of A, B, and C. As used herein, “members selected from the group consisting of A, B, and C” includes only one of A, B, or C, and excludes combinations of A, B, and C. As used herein, “members selected from the group consisting of A, B, and C and combinations thereof” includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

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

[0019] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, whereby the instructions stored in the storage device produce a manufactured article including instructions for implementing the functions / acts specified in the flowchart diagrams and / or block diagrams.

[0020] The code may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, generating a computer-implemented process for providing that the code executed on the computer or other programmable apparatus implements the functions / acts specified in the flowchart diagrams and / or block diagrams.

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

[0022] It should also be noted that in some alternative implementations, the functions described within a block may be executed in a different order than that shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or they may sometimes be executed in reverse order depending on the related functionality. Other steps and methods that are equivalent in terms of function, logic, or effect to one or more blocks or parts of the illustrated diagram may be contemplated.

[0023] While various arrow and line types may be employed in flowcharts and / or block diagrams, it is understood that these do not limit the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used solely to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate an unspecified duration of waiting or monitoring between enumerated steps of the depicted embodiment. It should also be noted that each block in a block diagram and / or flowchart, as well as combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and code.

[0024] The descriptions of elements in each figure may refer to the elements in the progress diagram. Similar numbers refer to similar elements in all figures, including alternative embodiments of similar elements.

[0025] Generally, this disclosure describes systems, methods, and apparatus for obtaining UUAA and / or C2 authorizations for unmanned aerial vehicles ("UAVs").

[0026] Disclosed is a solution for exchanging UAV credentials between a UAV and a 3GPP network for UAV authorization. The solution described below discloses how the 3GPP network obtains the parameters necessary to perform UUAA and C2 authorization from the UAV, how UUAA authorization may be enforced at the slice level, how the UAV may request user plane resources for UAV operation without prior flight authorization, and how the UAV knows whether UUAA will be performed during the execution of the registration procedure or the execution of the PDU session establishment procedure.

[0027] Figure 1 shows a wireless communication system 100 according to an embodiment of the present disclosure that supports the exchange of UAV credentials between a UAV and a 3GPP network for UAV authorization. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a UAV 106 and a UAV controller (UAV-C) 108 which may include an instance of the remote unit 105, a radio access network ("RAN") 120 (e.g., NG-RAN), and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. In various embodiments, the RAN 120 includes a base unit 121 with which the remote unit 105 communicates using a wireless communication link 123. Even though a specific number of remote units 105, base units 121, wireless communication links 123, RAN 120, and mobile core networks 140 are depicted in Figure 1, a person skilled in the art will recognize that any number of remote units 105, base units 121, wireless communication links 123, RAN 120, and mobile core networks 140 may be included in the wireless communication system 100.

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

[0029] In some embodiments, the aerial UE (i.e., remote unit 105) communicates with one or more UAV traffic management ("UTM") functions via a network connection to the mobile core network 140. As described below, the UAV 106 and / or UAV controller 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 is configured to use the PDU session to relay traffic between the aerial UE and the packet data network 150.

[0030] In some implementations, RAN120 conforms to the 5G system specified in the 3GPP specification. In other implementations, RAN120 conforms to the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement any other open or proprietary communication network, for example, WiMAX, among others, although other networks are possible and intended in this specification. In particular, this disclosure is not intended to be limited to the implementation of any specific wireless communication system architecture or protocol.

[0031] In one embodiment, the remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smartphones, smart televisions (e.g., Internet-connected televisions), smart appliances (e.g., Internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), or the like. In some embodiments, the remote unit 105 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, or the like. Furthermore, the remote unit 105 may be referred to as a UE, subscriber unit, mobile unit, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transceiver unit ("WTRU"), 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 a mobile device ("ME") that provides mobile termination functions (e.g., radio transmission, handover, voice coding and decoding, error detection and correction, signaling, and access to the SIM). In some embodiments, the remote unit 105 includes a terminal device ("TE") and / or may be embedded in an appliance or device (e.g., a computing device as described above).

[0032] The remote unit 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 a wireless communication link 123. In addition, the UL communication signal may include one or more downlink channels such as a physical uplink control channel ("PUCCH") and / or a physical uplink sharing channel ("PUSCH"), while the DL communication signal may include one or more downlink channels such as a physical downlink control channel ("PDCCH") and / or a physical downlink sharing channel ("PDSCH"). Here, the RAN 120 is an intermediate network that provides the remote unit 105 with access to the mobile core network 140.

[0033] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection to the mobile core network 140. For example, an application 107 (e.g., a UAS application) within the remote unit 105 may trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 via the RAN 120. The mobile core network 140 then uses the PDU session to relay traffic between the remote unit 105 and the application server 151 (e.g., a UAS application-specific server) within the packet data network 150. The PDU session represents a logical connection between the remote unit 105 and the User Plane Function ("UPF") 141.

[0034] 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. Thus, the remote unit 105 may simultaneously have at least one PDU session for communicating with the packet data network 150 and at least one PDU session for communicating with other data networks and / or other communication peers (not shown).

[0035] 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 specific data network ("DN") via 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, so that all packets belonging to a particular QoS flow have the same 5G QoS identifier ("5QI").

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

[0037] The base unit 121 may be distributed and / or located on a geographical area. In some embodiments, the base unit 121 may also be referred to as an access terminal, access point, base station, base station, node B ("NB"), evolved node B (abbreviated as eNodeB or "eNB"), 5G / NR node B ("gNB"), home node B, relay node, RAN node, or any other term used in the art. The base unit 121 is generally part of a radio access network ("RAN") such as a RAN 120, which may include one or more controllers communicably coupled to one or more corresponding base units 121. These and other elements of a radio access network are not exemplified but are generally well known to those skilled in the art. The base unit 121 connects to a mobile core network 140 via the RAN 120.

[0038] The base unit 121 may serve a number of remote units 105 in a serving area, such as a cell or cell sector, via a 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 spatial domains. Furthermore, DL communication signals may be carried over the wireless communication link 123. The wireless communication link 123 may include any suitable carrier in the licensed or unlicensed radio spectrum. The wireless communication link 123 is configured to facilitate communication between one or more of the remote units 105 and / or one or more of the base units 121. Note that during NR operation in the unlicensed spectrum (referred to as “NR-U” operation), the base unit 121 and the remote units 105 communicate over the unlicensed (i.e., shared) radio spectrum.

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

[0040] The mobile core network 140 includes several network functions ("NFs") in some embodiments. As depicted, the mobile core network 140 includes at least one user plane function ("UPF") 141. The mobile core network 140 also includes several 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, an integrated data management function ("UDM"), and a user data repository ("UDR"), which serve the RAN 120. In some embodiments, the UDM is located in the same place as the UDR, which is depicted as a combined entity "UDM / UDR" 149. Although certain numbers and types of network functions are depicted in Figure 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.

[0041] To support the operation of the UAS and the associated security aspects, the mobile core network 140 may also include a UAS-NF 147 for interactively communicating with the UAS Service Supplier ("USS") system and / or the UAS Traffic Management ("UTM") system (indicated as a combined node "USS / UTM" 157). In one embodiment, the USS / UTM 157 provides a set of duplicate USSs to assist the UAS operator 103 in performing secure, standards-compliant operations. Services may include flight planning collision avoidance, remote identification, and / or similar. In another embodiment, the USS / UTM 157 may be used to associate (i.e., pair) UAV 106 with UAV-C 108, where each UAV 106 provides its ID to the USS / UTM 157, and the USS / UTM 157 authorizes the request. The USS / UTM157 is located outside the mobile core network and can interact with core network functions such as the UAS-NF147 via the Network Exposure Function ("NEF") 146.

[0042] Although described as a standalone network function, in an alternative deployment of System 100, UAS-NF147 may be implemented as a service provided by NEF146. UAS-NF147 is supported by NEF146 (or by both NEF and Service Capability Exposure Function ("SCEF") - denoted as "NEF / SCEF") and used for external exposure of services to the USS. In some embodiments, UAS-NF147 uses existing NEF / SCEF exposure services for UAV authentication / authorization, UAV flight authorization, UAV / UAV-C pairing authorization, and related revocation, as well as for position reporting and control of QoS / traffic filtering for command and control ("C2") communications.

[0043] UPF141 is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting data networks ("DNs") in a 5G architecture. AMF143 is responsible for terminating non-access stratum ("NAS") signaling, NAS encryption and integrity protection, registration management, connectivity management, mobility management, access authentication and authorization, and security context management. SMF145 is responsible for session management (i.e., session establishment, correction, and release), Internet Protocol ("IP") address assignment and management for remote units (i.e., UEs), DL data notification, and traffic steering configuration for UPF141 for proper traffic routing.

[0044] The UDM is responsible for generating authentication and key agreement ("AKA") credentials, handling user identification, access permissions, and subscription management. The UDR is a repository of subscriber information and can be used to serve many network functions. For example, a UDR may store subscription data, policy relationship data, subscriber relationship data that is permitted to be exposed to third-party applications, and similar data.

[0045] In various embodiments, the mobile core network 140 may also include a network repository function ("NRF") (which provides registration and discovery of network function ("NF") services, enabling NFs to identify appropriate services from one another and communicate with each other via application programming interfaces ("APIs")), a network exposure 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 AUSF may act as an authentication server and / or authentication proxy, thereby enabling the AMF 143 to authenticate the remote unit 105. In certain embodiments, the mobile core network 140 may include an authentication, authorization, and accounting ("AAA") server.

[0046] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, with each mobile data connection utilizing a specific network slice. Here, “network slice” refers to a portion of the mobile core network 140 optimized for a particular traffic type or communication service. For example, one or more network slices may be optimized for Enhanced Mobile Broadband (eMBB) services. Another example is that one or more network slices may be optimized for Ultra-High Reliability Low Latency Communications (URLLC) services. In yet another example, network slices may be optimized for Machine Type Communications (MTC) services, Massive MTC (mMTC) services, or Internet of Things (IoT) services. In yet another example, network slices may be deployed for specific application services, vertical services, specific use cases, etc.

[0047] A network instance may be identified by single network slice selection support information ("S-NSSAI"), but the set of network slices that the remote unit 105 is permitted to use is identified by network slice selection support information ("NSSAI"), where "NSSAI" refers to a vector value containing one or more S-NSSAI values. In some embodiments, different network slices may include separate instances of network functions such as SMF145 and UPF141. In some embodiments, different network slices may share some common network functions such as AMF143. Different network slices are not shown in Figure 1 for ease of illustration, but their support is assumed.

[0048] Figure 1 depicts the components of a 5G RAN and 5G core network, but the embodiments described apply to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, and similar technologies.

[0049] Furthermore, in LTE variants where the mobile core network 140 is the EPC, the network functions shown can be replaced with appropriate EPC entities such as the Mobility Management Entity ("MME"), Serving Gateway ("SGW"), PDN Gateway ("PGW"), Home Subscriber Server ("HSS"), and Authentication Center ("AuC"). For example, the AMF 143 could be mapped to the MME, the SMF 145 to the control plane portion of the PGW ("PGW-C") and / or to the MME, the UPF 141 to the user plane portion of the SGW and PGW ("PGW-U"), the UDM / UDR 149 to the HSS / AuC, and so on.

[0050] In the following explanation, the term "gNB" is used for base stations, but it can be replaced with any other radio access node, such as RAN node, eNB, base station ("BS"), ng-eNB, gNB, access point ("AP"), etc. In addition, the term "UE" is used for mobile station / remote unit, but it can be replaced with any other remote device, such as remote unit, MS, ME, etc. Furthermore, the operation is described primarily in the context of 5G NR. However, the proposed solutions / methods are equally applicable to other mobile communication systems that support UAS.

[0051] According to the first solution (see, for example, Figures 2A to 2D), UUAA and C2 authorization are supported when establishing a PDU session. The first solution covers at least the following use cases:

[0052] Case 1: UAV 106 requests flight clearance from UTM / USS when UE105 requests a PDU session. UAV106 includes flight information details (i.e., flight path, time, pilot name) within the UAV container in the PDU session establishment request. The flight information details are used by UTM / USS to clear UAV106 for flight. UTM / USS performs a combination of C2 clearance for the PDU session and flight clearance for the UAV flight.

[0053] Case 2: UAV106 does not know whether UUAA is supported by the registration or PDU session establishment request, so UAV106 does not include UAV information in the PDU session establishment request.

[0054] When UAV106 requires data connectivity (e.g., IP connectivity), UAV106 initiates PDU session establishment by following standard procedures defined, for example, in 3GPP TS 23.502. In one embodiment, the UAV may include a CAA-Level UAV ID, flight authorization ID, or flight information details, i.e., Case 1 applies. Alternatively, the UAV may not include UAV information in the PDU session establishment request, i.e., Case 2.

[0055] The SMF (e.g., SMF145) determines whether a PDU session needs to be authorized by the UAS-NF (e.g., UAS-NF155) based on subscription information provided by the UDM / UDR (e.g., UDM / UDR149). The SMF retrieves session management subscription data from the UDM / UDR using the UAV106 subscriber permanent identifier ("SUPI") as the data key.

[0056] Session Management ("SM") subscription data includes whether UUAA and / or C2 authorization is required for each DNN in the S-NSSAI level subscription data. The session management subscription data may include new fields, such as a "UAV Operation" field or "Aerial Services" field, which contain information about whether UUAA or C2 authorization is required for the requested PDU session. In an alternative embodiment, separate fields are specified for UUAA authorization requirements and / or C2 authorization requirements. Table 1 shows an example with both options.

[0057] [Table 1]

[0058] The SMF determines whether UUAA and / or C2 authorization is required. In one embodiment, the SMF may check whether the UAV has valid prior authorization. That is, the SMF checks its internal database or its SM context to determine whether there is valid UUAA or C2 authorization for the UAV. If no valid authorization exists, the SMF145 selects UAS-NF147 to authorize the UAV. That is, the SMF145 can send a "Nuavnf_UAV_Operation" request service action to the UAS-NF147 selected for UUAA and / or C2 authorization.

[0059] In one embodiment, the Nuavnf_UAV_operation request may indicate in the request whether UUAA and / or C2 authorization is required. The request includes information provided by UAV106 within the UAV container (for example, if provided by UAV106). In an alternative embodiment, separate service operation requests are sent to UAS-NF147 (i.e., the Nuavnf_C2_operation request and the Nuavnf_UUAA_request).

[0060] UAS-NF147 may check whether UAV106 has valid prior authorization by checking the CAA-Level UAV ID and / or Flight Authorization ID provided (for example, if provided by the UAV). UAS-NF147 will determine whether UUAA and / or C2 authorization is required for UAV106 by checking whether there is an existing valid UUAA or C2 authorization for this UAV106 in its internal database. If UAV106 did not include a UAV container in the PDU session establishment request, or if UAS-NF147 determines that the information provided by UAV106 is expired, UAS-NF147 will request UAV106 to provide the information necessary to support UUAA or C2 authorization (i.e., provide the CAA-Level UAV ID and / or Flight Authorization ID).

[0061] Therefore, the first solution is to define a new protocol between UAV106 and UAS-NF147 for exchanging UAV relationship information. Communication takes place between UAS-NF147 and UAV106 via AMF (e.g., AMF143). UAS-NF147 sends a request to UAV106 by calling Namf_Communication_NlN2_MessageTransfer to AMF143. The message includes a subscriber permanent identifier ("SUPI") to identify the UE / UAV106 and the UAV payload container.

[0062] The UAV payload container includes protocols used between UAV106 and UAS-NF147 to exchange UAV information. Exemplary protocol messages include, for example, CAA-Level UAV ID requests and / or flight information requests.

[0063] AMF143 extracts UAV information and sends the UAV payload container to the UE (i.e., remote unit 105) in a DL NAS transport message. The DL NAS transport message contains a new type of payload (i.e., UAV payload) identified by the payload container type IE.

[0064] UAV106 determines from the payload container type that the message is a message for a UAV application within UAV106 (i.e., application 107). Based on the UAV protocol message request, UAV106 provides the requested information. UAV106 includes the requested information in the UL NAS transport message, which includes the UAV payload container and the payload container type IE set for the UAV payload received by AMF143. Based on the payload type, AMF143 determines whether the message should be sent to UAS-NF147. AMF143 includes the UAV payload in the Namf_Communication_NlN2_MessageTransfer notification service operation.

[0065] When UAS-NF147 obtains UAV information, it selects UTM / USS157 and initiates the authorization procedure by calling the Naf_UAV_Auth_request service operation. The message includes the CAA-Level UAV ID, 3GPP UAV ID, flight authorization ID, and / or flight information details. The message may be transmitted via NEF146. UTM / USS157 may authorize the request and assign an authorization token. UTM / USS157 may also authorize the flight if flight information details were included. In such cases, UTM / USS157 may assign a flight authorization ID. UTM / USS157 provides the authorization result to UAS-NF147 in a Naf_UAV_Auth response message.

[0066] UAS-NF147 stores the authorization result in its internal database and provides it to SMF 145 in a Nuavnf_UAV_operation response message. The message includes details on whether the UUAA and / or C2 authorization was successful. The message also includes the authorization token or flight authorization ID. SMF145 stores in the SM context that the PDU session ID is authorized for UUAA and / or C2 and provides PDU session acceptance to UAV106. The PDU session acceptance message may include the authorization token or flight authorization ID within the UAV payload.

[0067] It should be noted that the UUAA procedure may be performed either during the registration procedure or during the PDU session establishment procedure. The use of one or the other alternative form may depend on support in the UE / UAV106 or the network. Having two alternative forms may require the UE / UAV106 to be (pre)configured to know which alternative form is supported in the network. In one possible solution, the UE / UAV106 may be configured via a Universal Integrated Circuit Card ("UICC") or Universal Subscriber ID Module ("USIM") provided from a home network (e.g., called HPLMN). However, in the solution proposed herein, the UE / UAV does not need to be configured (or pre-configured).

[0068] The UE / UAV106 does not need to know which UUAA procedures the network supports. The network can request the UE / UAV 106 to provide identity and credentials for UUAA (or C2) authentication. Whether the network initiates a UUAA procedure during the registration procedure or the PDU session establishment procedure depends on the network configuration or preference. For example, subscription data stored in the UDM / UDR149 may contain UUAA-related information in either the access and management subscription parameters or the session management subscription parameters, which will trigger a corresponding UUAA procedure during either the registration procedure or the PDU session establishment procedure. While the above description refers to the UAV106 and its aerial UE, it should be noted that the above solutions also apply to the UAV-C108 and its aerial UE.

[0069] Figures 2A to 2D show an exemplary procedure 200 for UUAA and C2 authorization during PDU session establishment according to an embodiment of the first solution method. Procedure 200 includes UE201 (e.g., an aerial UE and one embodiment of remote unit 105 of a UAV), UAS operator 203 (e.g., one embodiment of UAS operator 103), USS / UTM server 205 (e.g., one embodiment of USS / UTM 157), AMF207 (e.g., one embodiment of AMF143), SMF209 (e.g., one embodiment of SMF145), UDM211 (e.g., one embodiment of UDM / UDR149), UAS-NF213 (e.g., one embodiment of UAS-NF147), and NEF215 (e.g., one embodiment of NEF146). The steps of procedure 200 are as follows:

[0070] Starting from Figure 2A, as a prerequisite, in step 0a, UAS operator 203 registers the UAS (e.g., UAV 106 and UAV controller 108) with a USS provider, e.g., USS / UTM server 205 (see block 221). Here, it is assumed that UAS operator 203 registers UE 201 and the corresponding UAV. USS / UTM server 205 assigns a CAA-Level UAV ID to the UAV (i.e., UE 201).

[0071] As an optional prerequisite, in step 0b, the UAS operator 203 may request flight clearance from its USS provider (i.e., the USS / UTM server 205) (see step 223). The USS / UTM 205 may assign a flight clearance ID to the permitted flight.

[0072] In step 1, the UAS operator 203 configures UE201 (i.e., UAV) with a CAA-Level UAV ID assigned to it (see messaging 225). In one embodiment, the CAA-Level UAV ID may be assigned to UE201 (i.e., UAV) by the USS / UTM server 205 via IP connectivity. In another embodiment, the CAA-Level UAV ID may be assigned to UE201 (i.e., UAV) by the USS / UTM server 205 via NAS signaling.

[0073] In step 2, UAS operator 203 may assign flight information to UE201 (i.e., UAV) (see messaging 227). The flight information may include a flight authorization ID for the authorized flight (for example, if step 0b is performed), or alternatively, flight information details (e.g., flight path information, pilot name, flight time, etc.) if the flight authorization is performed when the PDU session is established (i.e., combined flight authorization and C2 authorization).

[0074] In step 3, based on steps 1 and 2, UE201 (i.e., the UAV) has information regarding the CAA-Level UAV ID, the Flight Authorization ID (which may also include credentials to notify the authorization token), and / or flight information details (see block 229).

[0075] In step 4, UE201 (i.e., the UAV) is triggered (for example, by UAS operator 203) to establish IP connectivity (for example, to begin flight) (see messaging 231).

[0076] In step 5, UE201 (i.e., the UAV) initiates a PDU session establishment request (see messaging 233), the request including a PDU session ID and instructions for either the UAV operation or the request to a special DNN used for the UAV operation. If Case 1 applies (i.e., the UAV requests flight clearance and its aerial UE requests a PDU session), UE 201 may include flight information details in the UAV payload (i.e., for requesting flight clearance) within the PDU session establishment request by step 2. If Case 2 applies (i.e., the UAV does not include UAV information within the PDU session establishment request), UE 201 may not provide the CAA-Level UAV ID and / or flight information details.

[0077] In step 6, the PDU session establishment is received by AMF207. AMF 207 sends an SM context creation request containing instructions for UAV operation to SMF 209 (see messaging 235).

[0078] Continuing to refer to Figure 2B, in step 7, SMF 209 decides to retrieve session management ("SM") subscription data from the UDM / UDR (see block 237).

[0079] In step 8, SMF209 sends a NuDM SDM gct service operation request to UDM 211 requesting SM data for the UAV's subscription permanent identifier ("SUPI") (see messaging 239).

[0080] In step 9, UDM 211 responds with subscription data (see messaging 241). Note that the SM subscription data from the UDM includes UAV operation information, i.e., instructions on whether UUAA and / or C2 authorization are required.

[0081] In step 10, SMF209 responds to AMF207 with an acknowledgment of SM context creation (see messaging 243).

[0082] In step 11, SMF209 determines from the SM subscription data whether the PDU session requires UUAA and / or C2 authorization (see block 245). In one embodiment, SMF209 may check its internal database for whether the provided PDU session ID or SUPI of UE201 (i.e., UAV) has prior UUAA and / or C2 authorization. If authorization does not exist, steps 12 through 28 are performed, and SMF209 selects UAS-NF213 to initiate the authorization procedure.

[0083] In step 12, SMF209 initiates the authorization procedure by sending a Nuavnf_UAV_Operations request (see messaging 247). In one embodiment, this request may include separate instructions on whether UUAA and / or C2 authorization is required. In an alternative embodiment, separate service operation requests are used for UUAA and C2 authorization.

[0084] In step 13, UAS-NF213 determines whether UUAA and / or C2 authorization is required for the UAV (see block 249). In one embodiment, UAS-NF213 may check its internal database to verify whether UE201 (i.e., UAV) has pre-validated UUAA and / or C2 authorization. If no valid authorization is present, or if UE201 (i.e., UAV) has not provided a UAV container, UAS-NF213 requests UE201 (i.e., UAV) to provide the necessary information. If UUAA is required, UAS-NF213 requests UE201 (i.e., UAV) to provide a CAA-Level UAV ID. If C2 authorization is required, UAS-NF213 requests a CAA-Level UAV ID and flight information.

[0085] In step 14, UAS-NF213 sends a request to UE201 (i.e., the UAV) via AMF207 by calling the Namf_Communication_NlN2Messagetransfer service operation (see messaging 251). This request includes a UAV payload container that transmits a protocol requesting the CAA-Level UAV ID and / or flight information.

[0086] In step 15, AMF143 forwards the UAV payload container to UE201 (i.e., the UAV) via a DE NAS transport message (see messaging 253). The DL NAS transport message contains the UAV payload. In one embodiment, the payload type IE of the DL NAS transport message is set to "UAV payload".

[0087] In step 16, UE201 (i.e., the UAV) determines that the information needs to be sent to the corresponding UAV application (see block 255). The UAV application provides the requested information to the NAS layer.

[0088] Continuing to refer to Figure 2C, in step 17, UE201 (for example, the NAS layer within UE201) includes a UAV payload container containing the requested information (i.e., the CAA-Level UAV ID and / or Flight Permission ID or Flight Information Details if the UAV requests flight permission within the PDU session establishment request in accordance with step 2) within the UL NAS transport message (see messaging 257).

[0089] In step 18, AMF207 forwards the UAV payload container to UAS-NF213 in a Namf_Communication_N lN2_messagetransfer notification message (see messaging 259).

[0090] In step 19, UAS-NF213 optionally stores the authorization in its internal database context for successfully authorized UAVs / UEs. UAS-NF213 may check the stored status (for example, based on the SUPI) to determine whether this UE201 (i.e., UAV) has a valid authorization (see block 261). If no valid authorization is stored, UAS-NF213 determines the external identifier of this UAV (for example, the 3GPP UAV ID) to initiate UAS authentication via the USS / UTM server 205. In one embodiment, UAS-NF213 determines the 3GPP UAV ID of UE201 (i.e., UAV) from the SUPI of UE201. In another embodiment, UAS-NF213 determines the 3GPP UAV ID from the CAA-Level UAV ID.

[0091] In step 20, if SUPI is used to obtain the 3GPP UAV ID, UAS-NF213 sends a Nudm_SDM_Get service operation to UDM211 requesting a group identifier translation for SUPI (see messaging 263).

[0092] In step 21, UDM211 provides the 3GPP UAV ID to UAS-NF213 (see messaging 265). In some embodiments, the 3GPP UAV ID may include, and there are other types of identifiers and / or identifiers contemplated herein, a Publicly Available Subscription Identifier (GPSI) (for example, an external identifier used by the 3GPP network to enable third-party identification of UAV106).

[0093] In step 22, UAS-NF213 sends a Naf_UAV_Auth_request service operation to the USS / UTM server 205, including the CAA-Level UAV ID, Flight Permission ID, or Flight Information Details, if provided in step 5 or 17 (see messaging 267). In one embodiment, the request may be sent to the USS / UTM server 205 via NEF215. If the request is sent via NEF215, UAS-NF213 includes the address of the USS / UTM server 205 in the message to NEF215.

[0094] Steps 23 through 28 are conditional and / or optional. For example, step 23 may be initiated in response to the USS / UTM server 205 requiring additional information and / or credentials from UE201 (i.e., the UAV) to authenticate, for example, UAV106. In response to the request for additional information and / or credentials, UE201 provides the additional information and / or credentials as detailed in steps 24 through 28 below. Alternatively, steps 23 through 28 are skipped when the USS / UTM server 205 does not require additional information and / or credentials from UE201 (i.e., the UAV).

[0095] In step 23, if the USS / UTM server 205 requires additional authentication information from the UE201 (i.e., the UAV), the USS / UTM server 205 does so by calling the Naf_UAV_Auth service operation to the UAS-NF213 requesting the additional information, i.e., by sending a Naf_UAV_Auth_Response message (see messaging 269).

[0096] In step 24, UAS-NF213 forwards the request for additional information to AMF207 in the UAV payload within the Namf_Communication_NlN2_Messagetransfer message (see messaging 271). In an alternative embodiment, UAS-NF213 may use a generic Nuavnf_UAV_Operations notification message containing the UAV payload.

[0097] In step 25, AMF207 forwards the UAV payload to UE201 in a DL NAS transport message (see messaging 273).

[0098] In step 26, UE201 (i.e., the UAV) provides the requested information to AMF207, i.e., in the UAV payload within the UL NAS transport message (see messaging 275).

[0099] In step 27, AMF207 forwards the UAV payload container, along with the requested information, to UAS-NF213 in a Namf_Communication_NlN2_messagetransfer notification message (see messaging 277). In an alternative embodiment, the UAV payload may be included in a generic Nuavnf_UAV_Operations notification message.

[0100] Continuing to refer to Figure 2D, in step 28, UAS-NF213 forwards the requested information to the USS / UTM server 205 in Naf_UAV_Auth_request (see messaging 279).

[0101] In step 29, USS / UTM server 205 allows the request (see block 281).

[0102] In step 30, the USS / UTM server 205 determines remote identification and tracking information, including a permission token, or assigns a flight permission ID if Case 1 applies, i.e., no prior flight permission was granted (i.e., step 2 was not performed) (see block 283).

[0103] In step 31, the USS / UTM server 205 sends the Naf_UAV_Auth_response to the UAS-NF213 along with the authorization result, which includes the authorization token and / or flight authorization ID (see messaging 285).

[0104] In step 32, the UAS-NF213 stores the authorization result in its local database (see block 287). The internal database may contain information indicating that a 3GPP UAV identifier or CAA-Level UAV identifier has a valid UUAA or C2 authorization.

[0105] In step 33, UAS-NF213 sends a Nuavnf_UAV_operation response to SMF209 indicating that it has been permitted to establish a PDU session (see messaging 289).

[0106] In step 34, SMF209 stores in the SM context that UE201 and / or PDU session IDs are authorized for UUAA and / or C2 (see block 291).

[0107] In step 35, SMF209 sends a PDU session establishment acceptance message to UE201 (i.e., the UAV). SMF209 sends a Namf_N2N2_message forwarding service operation to AMF207, which includes the PDU session ID and the N1 SM container (see messaging 293). The N1 SM container contains the PDU session acceptance message, which also includes the flight authorization ID in the UAV payload if the USS / UTM server 205 provided the flight authorization ID in step 25.

[0108] In step 36, AMF207 forwards the PDU session acceptance message to UE201 (i.e., the UAV) (see messaging 295). Step 200 is complete.

[0109] According to the second solution (see, for example, Figures 3A to 3D), UUAA is supported during UAV / UE registration. The UAV (i.e., UAV106) registers with the 3GPP network using SIM credentials, as specified, for example, in 3GPP TS23.502. The UAV sends a registration request to the AMF (e.g., AMF143), which may include a list of S-NSSAIs. The AMF retrieves access and mobility subscription data and / or slice selection subscription data to determine whether UUAA is required for the UAV. The access and mobility subscription data includes information indicating whether UUAA is required for each SUPI. In an alternative embodiment, the slice selection subscription data may include information indicating whether UUAA is required for each SUPI and each S-NSSAI level. This is shown in Tables 2A-C.

[0110] [Table 2A]

[0111] [Table 2B]

[0112] [Table 2C]

[0113] In various embodiments, AMF determines whether there is valid pre-UUAA authorization for this UAV by checking the UE context. If there is no valid authorization, AMF selects UAS-NF (i.e., UAS-NF147) and initiates the UUAA procedure by calling a Nuavnf_UAV_operation request indicating that UUAA is required. Alternatively, a specific service operation for UUAA is used. The message includes the SUPI and the current UAV deployment and a list of S-NSSAIs requested if provided by the UAV, and slice selection subscription data indicating that the S-NSSAIs are conditional on UUAA. When AMF determines that UUAA is required, AMF sends a registration acceptance message to the UAV indicating that UUAA is pending.

[0114] The UAS-NF determines whether a UAV requires a UUAA by checking its internal database for a valid UUAA for that UAV. If a UUAA is required for this UAV, the UAS-NF requests that the UAV provide the necessary information to support the UUAA (i.e., provide a CAA-Level UAV ID).

[0115] Next, the protocol defined in the first solution described above may be reused. UAS-NF and UAV exchange information via AMF by utilizing Namf_Communication_NlN2_messagetransfer and DU / UU NAS transport messages.

[0116] When UAS-NF obtains information, it selects a USS / UTM server and initiates the authorization procedure by calling the Naf_UAV_Auth_request service action. The message includes the CAA-Level UAV ID and the 3GPP UAV ID. In one embodiment, if UUAA is performed at the S-NSSAI level, the message also includes a list of S-NSSAIs requested by the UAV.

[0117] The message may be transported via NEF in some embodiments. The USS / UTM server authorizes the request and provides a response to the UAS-NF. If UUAA is performed at the S-NSSAI level, the USS / UTM server provides a list of authorized S-NSSAIs. The UAS-NF stores the authorization results in its local database, i.e., it stores information indicating that the CAA-Level UAV ID and 3GPP UAV ID have valid UUAA. The UAS-NF responds to the AMF with the authorization results included in the Nuavnf_UAV_operation response message. The AMF stores information within the UE context indicating that the UAV has valid UUAA (for example, it stores information indicating that SUPI has valid UUAA).

[0118] If UUAA is performed at the S-NSSAI level, AMF determines the list of permitted S-NSSAIs based on the permitted S-NSSAIs provided by USS / UTM. AMF signals UUAA success and sends a UE configuration update to the UAV, which also includes the list of permitted S-NSSAIs.

[0119] Figures 3A to 3D show Procedure 300 for UAS-NF to obtain necessary information from a UAV according to an embodiment of the second solution. Procedure 300 includes UE201 (e.g., an aerial UE of the UAV and one embodiment of the remote unit 105), UAS operator 203 (e.g., one embodiment of UAS operator 103), USS / UTM server 205 (e.g., one embodiment of USS / UTM 157), AMF207 (e.g., one embodiment of AMF143), SMF209 (e.g., one embodiment of SMF145), UDM211 (e.g., one embodiment of UDM / UDR149), UAS-NF213 (e.g., one embodiment of UAS-NF147), and NEF215 (e.g., one embodiment of NEF146). The steps of Procedure 300 are described as follows:

[0120] Starting from Figure 3A, as a prerequisite, in step 0a, the UAS operator 203 registers the UAS (e.g., UAV106 and UAV controller 108) with the USS provider (e.g., USS / UTM server 205) (see messaging 301). The USS provider (e.g., USS / UTM server 205) assigns a CAA-Level UAV ID to the UAV (i.e., UE201).

[0121] As an optional prerequisite, the UAS operator 203 may request flight permission from its USS provider (i.e., the USS / UTM server 205) (see block 303). The USS / UTM server 205 may assign a flight permission ID to the permitted flight.

[0122] In Step 1, the UAS operator 203 assigns a CAA-Level UAV ID to UE201 (i.e., the UAV) (see messaging 305). Alternatively, the CAA-Level UAV ID may be assigned to UE201 (i.e., the UAV) by a UTM or USS provider (i.e., USS / UTM server 205) via IP connectivity or via NAS signaling.

[0123] In step 2, the UAS operator 203 may configure and transmit flight information to UE201 (i.e., the UAV) (see messaging 307). The flight information may include a flight authorization ID for the authorized flight (for example, if step 0b is performed), or alternatively, it may include UAV aeronautical information (e.g., flight path information, pilot name, flight time, etc.).

[0124] In Step 3, based on Steps 1 and 2, UE201 (i.e., the UAV) has a CAA-Level UAV ID, a Flight Authorization ID, and / or information regarding the UAV aeronautical information (see Block 309).

[0125] In step 4, the UE201 (i.e., the UAV) initiates the initial registration procedure to a 3GPP network (e.g., AMF207) using a standard procedure defined, for example, in 3GPP TS23.502 (see messaging 311). The UE201 (i.e., the UAV) may also include a list of S-NSSAIs in the request.

[0126] In step 5, AMF207 decides to retrieve access, mobility, and slice selection subscription data for the UAV to the SUPI from the UDM / UDR (see block 313).

[0127] In step 6, AMF207 invokes the Nudm_SDM_Get service operation to UDM211 to request access to the UAV's SUPI and mobility and slice selection subscription data (see messaging 315).

[0128] In step 7, UDM211 provides subscription data to AMF207 in response (see messaging 317). The subscription data may indicate whether UUAA is required and / or whether some S-NSSAIs require UUAA. According to the first option, access and mobility subscription data from UDM / UDR indicates per SUPI whether UUAA (or other UAS permission) is required. According to the second option, slice selection subscription data may provide information on whether UAAA (or other UAS permission) is required at the slice level (i.e., per S-NSSAI).

[0129] In step 8, AMF207 determines whether UUAA (or other UAS-related authorization) is required and checks, for example, whether there is a valid UUAA authorization for UE201 (i.e., UAV) by checking the UE context (see block 319). If there is no valid authorization, steps 10 through 22 are performed and AMF207 also selects UAS-NF213 in step 8.

[0130] In step 9, AMF207 sends a registration acceptance to UE201 (i.e., the UAV) indicating that the required UUAA is pending (see messaging 321).

[0131] Continuing to refer to Figure 3B, in step 10, AMF207 initiates a Nuavnf_UAV_Operations request to the selected UAS-NF213 (see messaging 323). This request may include a list of S-NSSAIs requested by UAV106 in step 4, an indication of whether a UUAA is required if the slice selection subscription data indicates that the S-NSSAI is conditional on a UUAA, and a list of requested S-NSSAIs.

[0132] In step 11, UAS-NF213 receives the request. UAS-NF213 determines whether authorization by UTM / USS is required by internally checking, for example, whether UE201 (i.e., UAV) has prior UUAA authorization (see block 325). If prior authorization is not available, UAS-NF213 requests that UE201 (i.e., UAV) provide UAS-NF213 with a CAA-Level UAV ID.

[0133] In step 12, UAS-NF213 sends a request to UE201 (i.e., the UAV) via AMF207 by calling the Namf_Communication_NlN2Messagetransfer service operation (see messaging 327). This request includes a UAV payload container that conveys a protocol requesting the CAA-Level UAV ID.

[0134] In step 13, AMF207 forwards the UAV payload container to UE201 (i.e., the UAV) via a DL NAS transport message (see messaging 329). The DL NAS transport message contains the UAV payload. In some embodiments, the payload type IE of the DL NAS transport message is set to "UAV payload".

[0135] In step 14, UE201 (i.e., the UAV) determines what information needs to be sent to the UAV application (see block 331). The UAV provides the requested information, namely the CAA-level UAV ID.

[0136] In step 15, UE201 (i.e., the UAV) includes a UAV payload container containing the requested information (e.g., CAA-Level UAV ID) within the UL NAS transport message to AMF207 (see messaging 333).

[0137] In step 16, AMF207 forwards the UAV payload container to UAS-NF213 in a Namf_Communication_NlN2_messagetransfer notification message (see messaging 335).

[0138] In step 17, UAS-NF213 determines the external identifier (e.g., 3GPP UAV ID) of the UAV (UE201) from the SUPI of the UAV (see block 337). In one embodiment, UAS-NF213 determines the 3GPP UAV ID from the CAA-Level UAV ID for the UAV.

[0139] In step 18, if the SUPI of UE201 (i.e., the UAV) is used to obtain the 3GPP UAV ID, UAS-NF213 sends a Nudm_SDM_Get service operation to UDM211 requesting a group identifier translation of the SUPI (see messaging 339).

[0140] In step 19, UDM211 provides the 3GPP UAV ID to UAS-NF213 (see messaging 341).

[0141] Continuing to refer to Figure 3C, in step 20, UAS-NF213 sends a Naf_UAV_Auth_request service operation to the USS / UTM server 205, which includes the CAA Level UAV ID and a list of S-NSSAIs provided in step 4, and if the slice-level subscription data indicates that the S-NSSAIs conditioned on UUAA (see messaging 343). In one embodiment, the request may be sent to the USS / UTM server 205 via NEF215. If the request is sent via NEF215, UAS-NF213 includes the address of the USS / UTM server 205 in the message to NEF215.

[0142] Steps 21 through 26 are conditional and / or optional. For example, step 21 may be initiated in response to the USS / UTM server 205 requiring additional information and / or credentials from UE201 (i.e., the UAV) to authenticate, for example, UAV106. In response to the request for additional information and / or credentials, UE201 provides the additional information and / or credentials as detailed in steps 24 through 26 below. Alternatively, steps 21 through 26 are skipped when the USS / UTM server 205 does not require additional information and / or credentials from UE201 (i.e., the UAV).

[0143] In step 21, if the USS / UTM server 205 requires additional authentication information from the UE201 (i.e., the UAV), the USS / UTM server 205 invokes a Naf_UAV_Auth response to the UAS-NF213 requesting the additional information (see messaging 345).

[0144] In step 22, UAS-NF213 forwards the request for additional information to AMF207 in the UAV payload within the Namf_Communication_NlN2_Messagetransfer message (see messaging 347). In an alternative embodiment, the UAV payload may be included in the generic Nuavnf_UAV_Operations notification message.

[0145] In step 23, AMF207 forwards the UAV payload to UE201 (i.e., the UAV) in a NAS transport message (see messaging 349).

[0146] In step 24, UE201 (i.e., the UAV) provides the requested information to AMF207 in the UAV payload within the UL NAS transport message (see messaging 351).

[0147] In step 25, AMF207 forwards the UAV payload, along with the requested information, to UAS-NF213 in a Namf_Communication_NlN2_messagetransfer notification message (see messaging 353). In an alternative embodiment, the UAV payload may be included in a generic Nuavnf_UAV_Operations notification message.

[0148] Continuing to refer to Figure 3D, in step 26, UAS-NF213 places the requested information in Naf_UAV_Auth_response and forwards it to the USS / UTM server 205 (see messaging 355).

[0149] In step 27, USS / UTM server 205 allows the request (see block 357).

[0150] In step 28, USS / UTM205 grants UAV authorization to UAS-NF213 (see messaging 359). The response may include a list of authorized S-NSSAIs, if S-NSSAIs were included in step 20.

[0151] In step 29, the UAS-NF213 stores the authorization result in its local database (see block 361). The UAS-NF213 may internally store that a CAA-Level UAV ID or 3GPP UAV ID is UUAA authorized.

[0152] In step 30, UAS-NF213 responds to AMF207 with a Nuavnf_UAV_Operations message indicating that the UUAA was successful (see messaging 363). This message may include a list of permitted S-NSSAIs if an S-NSSAI was provided in step 22.

[0153] In step 31, AMF207 stores in the UE context that the UUAA was successful and determines a list of permitted S-NSSAIs based on the permitted S-NSSAIs received in step 24 (see block 365).

[0154] In step 32, AMF143 instructs UE201 (i.e., UAV) within the UE configuration update procedure that the UUAA was successful and provides a list of allowed and / or permitted S-NSSAIs based on step 25 (see messaging 367). Procedure 300 is completed.

[0155] Figure 4 shows the network architecture 400 for supporting UAS in a 3GPP system. UAVs and UAV-Cs (or sometimes referred to as UASs) are considered user equipment (UEs) according to the 3GPP definition, implementing additional UAV applications.

[0156] The main elements supporting UAS in a 3GPP system include UAS-NF, UAV, and UAV-C. UAS-NF uses presence reporting information from 3GPP LCS and / or AMF to expose location information about the UAV to UTM (UAS Traffic Management) and / or USS (UAS Service Provider). UAS-NF interfaces with the USS / UTM server for UAV authentication and authorization (e.g., UUAA), allowing the UAV to perform UAV operations over the 3GPP network. UAS-NF may also be involved in C2 authentication / pairing procedures. UAS-NF may receive C2 pairing routing rules from the USS / UTM server 205, for example, via the 3GPP API.

[0157] As shown in Figure 4, in some embodiments, the UAS-NF interacts with the USS / UTM server 205 via the 3GPP API. As described above, the USS / UTM server 205 may invoke the UAS-NF service operation. Although not depicted in Figure 4, the UAS-NF may also interact with the USS / UTM server 205 via the NEF.

[0158] The UAS (including the UAV and UAV-C) establishes user-plane connectivity with the USS / UTM server 255 to provide remote identification and tracking information. The UAS establishes user-plane connectivity between the UAV-C and the UAV for command and control (C2). In some embodiments, a UAV (i.e., UAV#1 415) may establish inter-UAV connectivity (i.e., inter-device communication) with a peer UAV (i.e., UAV#3 417).

[0159] What is required is that the UAS is already registered with the USS provider. In addition, the UAS must have a valid flight permit provided by the USS provider.

[0160] Figure 4 illustrates different implementations of the UAS. In the first implementation, exemplified by UAS#1 405, the UAS may include a UAV (i.e., UAV#1 415) that establishes a connection (e.g., a PDU session) with a first PUMN (i.e., PUMN#1 435) and a network connectivity controller (i.e., UAV-C#1 410) that has a connection (e.g., a PDU session) via a different PUMN (i.e., PUMN#2 440). In the second implementation, exemplified by UAS#2 420, the UAS may include a UAV (i.e., UAV#2 430) that establishes a connection (e.g., a PDU session) with a PUMN (i.e., PUMN#2 440) and a non-network connectivity controller (i.e., UAV-C#2 435) that has a connection outside of any 3GPP network (i.e., UAV-C#2 connects via the Internet 445). The term "Network-attached UAV-C" refers to UAV-C registered with the 3GPP network / PUMN, while "Un-network-attached UAV-C" refers to UAV-C not registered with the 3GPP network / PUMN.

[0161] The UAV establishes a connection to the USS / UTM server 205 for UUAA and / or C2 authentication, as described above with reference to Figures 2A-2D and 3A-3D. After UUAA and C2 authentication (for example, via UASNF#1 465 in PUMN#1 435), UAV#1 415 establishes a user plane connection 480 with the USS / UTM 205 for C2 and / or remote identification and tracking ("RID"). In addition, UAV#1 415 establishes a user plane connection 485 with UAV-C#1 410 for C2. Note that user plane connection 480 is established via UPF#1 460 in PUMN#1 435, and user plane connection 485 is established via UPF#1 460 in PUMN#1 435, and also via UPF#2 470 in PUMN#2 440.

[0162] Similarly, after UUAA and C2 authentication (for example, via UASNF#2 475 in PUMN#2 440), UAV#2 430 establishes a user plane connection 490 with USS / UTM205 for C2 and / or remote identification and tracking ("RID"), and also establishes a user plane connection 495 with UAV-C#2 425 for C2. Note that user plane connection 480 is established via UPF#2 470 in PUMN#2 440, and user plane connection 485 is established via UPF#2 470 in PUMN#2 440, as well as via the internet 445.

[0163] As illustrated, PUMN#1 435 includes a first AMF (i.e., AMF#1) 450 and a first SMF (i.e., SMF#1) 455. AMF#1 establishes a NAS connection with the Aerial UE in UAV#1 415. SMF#1 performs session management functions for UAV#1 415. When performing UUAA and / or C2 authorization, messages between UAV#1 415 and AMF#1 450 go through the N1 interface. When performing UUAA and / or C authorization, messages between AMF#1 450 and SMF#1 455 may use the N1N2 service-based interface. When performing UUAA and / or C2 authorization, messages between AMF#1 450 and UASNF#1 465 -- and messages between SMF#1 455 and UASNF#1 465 -- may use the Nuas service-based interface.

[0164] Figure 5 shows a user equipment device 500 (or “UE device 500”) that may be used to exchange UAV credentials between UAV 106 and a 3GPP network to request UAV authorization, according to embodiments of the present disclosure. In various embodiments, the user equipment device 500 is used to implement one or more of the solutions described above. The user equipment device 500 may be one embodiment of the remote unit 105, UAV 106, UAV-C 108, and / or UE described above. Furthermore, the user equipment device 500 may comprise, among other components, a processor 505, memory 510, an input device 515, an output device 520, and a transceiver 525.

[0165] In some embodiments, the input device 515 and the output device 520 are combined into a single device, such as a touchscreen. In some embodiments, the user equipment 500 may not include the input device 515 and / or the output device 520. In various embodiments, the user equipment 500 may include one or more of the processor 505, memory 510, and transceiver 525, and may not include the input device 515 and / or the output device 520.

[0166] As depicted, the transceiver 525 includes at least one transmitter 530 and at least one receiver 535, where the transceiver 525 communicates with one or more cells supported by one or more base units 121. In addition, the transceiver 525 may support at least one network interface 540 and / or application interface 545. The application interface 545 may support one or more APIs. The network interface 540 may support 3GPP reference points such as Uu, N1, N2, N3, etc. Other network interfaces 540 may also be supported, as will be understood by those skilled in the art.

[0167] In one embodiment, the processor 505 may include any known controller capable of executing computer-readable instructions and / or logical operations. For example, the processor 505 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 505 executes instructions stored in memory 510 to perform the methods and routines described herein. The processor 505 is communicatively coupled to memory 510, input device 515, output device 520, and transceiver 525.

[0168] In various embodiments, the processor 505 controls the user equipment device 500 to implement the behavior of the UE (e.g., UAV 106) according to one or more of the embodiments described above.

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

[0170] In some embodiments, memory 510 stores data related to exchanging UAV credentials between UAV 106 and the 3GPP network for UAV authorization. For example, memory 510 may store various parameters, configurations, policies, and similar items, as described above. In some embodiments, memory 510 also stores program code and related data, such as an operating system or other controller algorithms running on device 500.

[0171] In one embodiment, the input device 515 may include, but is not limited to, 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 515 may be integrated with the output device 520, for example, as a touchscreen or similar touch sensor display. In some embodiments, the input device 515 includes a touchscreen on which text can be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, the input device 515 includes two or more different devices, such as a keyboard and a touch panel.

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

[0173] In some embodiments, the output device 520 comprises one or more speakers for generating sound. For example, the output device 520 may generate an audible warning or notification (e.g., a beep or chime). In some embodiments, the output device 520 includes one or more haptic devices for generating vibration, motion, or other tactile feedback. In some embodiments, all or part of the output device 520 may be integrated with the input device 515. For example, the input device 515 and the output device 520 may form a touchscreen or similar touch sensor display. In other embodiments, the output device 520 may be located near the input device 515.

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

[0175] The transceiver 525 includes at least one transmitter 530 and at least one receiver 535. One or more transmitters 530 may be used to provide UL communication signals to the base unit 50, such as UL transmission as described herein. Similarly, one or more receivers 535 may be used to receive DL communication signals from the base unit 121 as described herein. Although only one transmitter 530 and one receiver 535 are illustrated, the user equipment 500 may have any preferred number of transmitters 530 and receivers 535. Furthermore, the transmitters 530 and receivers 535 may be any preferred type of transmitter and receiver. In one embodiment, the transceiver 525 includes a first transmitter / receiver pair used to communicate with a mobile communication network on the licensed radio spectrum and a second transmitter / receiver pair used to communicate with a mobile communication network on the unlicensed radio spectrum.

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

[0177] In various embodiments, one or more transmitters 530 and / or one or more receivers 535 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, system-on-chip, ASIC, or other type of hardware component. In some embodiments, one or more transmitters 530 and / or one or more receivers 535 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as a network interface 540 or other hardware components / circuits, may be integrated into a single chip together with any number of transmitters 530 and / or receivers 535. In such embodiments, the transmitters 530 and receivers 535 may be logically configured as transceivers 525 using one or more common control signals, or as modular transmitters 530 and receivers 535 implemented within the same hardware chip or multi-chip module.

[0178] Figure 6 shows a network equipment device 600 that, according to embodiments of the present disclosure, may be used to exchange UAV credentials between UAV 106 and a 3GPP network for UAV authorization. The network equipment device 600 may be one embodiment of the AMF 143, SMF 145, UAS-NF 147, UDM / UDR 149, or USS / UTM 157 described above. Furthermore, the base network equipment device 600 may include a processor 605, memory 610, an input device 615, an output device 620, and a transceiver 625. In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touchscreen. In some embodiments, the network equipment device 600 may not include the input device 615 and / or the output device 620. In various embodiments, the network equipment 600 may include one or more of a processor 605, memory 610, and transceiver 625, and may not include an input device 615 and / or an output device 620.

[0179] As depicted, the transceiver 625 includes at least one transmitter 630 and at least one receiver 635, where the transceiver 625 communicates with one or more core network functions, RAN nodes, and / or service platforms. In addition, the transceiver 625 may support at least one network interface 640 and / or application interface 645. The application interface 645 may support one or more APIs, such as the 3GPP API used for communication between UTM / USS and UAS-NF. The network interface 640 may support 3GPP reference points such as N1, N2, N3, etc. Other network interfaces 640 may also be supported, as will be understood by those skilled in the art.

[0180] In one embodiment, the processor 605 may include any known controller capable of executing computer-readable instructions and / or logical operations. For example, the processor 605 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 605 executes instructions stored in memory 610 to perform the methods and routines described herein. The processor 605 is communicatively coupled to memory 610, input device 615, output device 620, and transceiver 625.

[0181] In various embodiments, the network equipment 600 is a UAS-NF147, as described herein. Here, the processor 605 controls the network equipment 600 to perform the behavior of the UAS-NF147 as described above. In other embodiments, the network equipment 600 is an AMF and / or SMF, as described herein. Here, the processor 605 controls the network equipment 600 to perform the behavior of the AMF and / or SMF as described above.

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

[0183] In some embodiments, memory 610 stores data related to exchanging UAV credentials between UAV 106 and the 3GPP network for UAV authorization. For example, memory 610 may store various parameters, configurations, policies, and similar items, as described above. In some embodiments, memory 610 also stores program code and related data, such as an operating system or other controller algorithms running on the network equipment device 600.

[0184] In one embodiment, the input device 615 may include, but is not limited to, 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 615 may be integrated with the output device 620, for example, as a touchscreen or similar touch sensor display. In some embodiments, the input device 615 includes a touchscreen on which text can be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, the input device 615 includes two or more different devices, such as a keyboard and a touch panel.

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

[0186] In some embodiments, the output device 620 comprises one or more speakers for generating sound. For example, the output device 620 may generate an audible warning or notification (e.g., a beep or chime). In some embodiments, the output device 620 includes one or more haptic devices for generating vibration, motion, or other tactile feedback. In some embodiments, all or part of the output device 620 may be integrated with the input device 615. For example, the input device 615 and the output device 620 may form a touchscreen or similar touch sensor display. In other embodiments, the output device 620 may be located near the input device 615.

[0187] The transceiver 625 includes at least one transmitter 630 and at least one receiver 635. One or more sets of transmitters 630 and receivers 635 may be used to communicate with UE 105 as described herein. Similarly, one or more sets of transmitters 630 and receivers 635 may be used to communicate with network functions within PLMN and / or RAN 120 as described herein. Although only one transmitter 630 and one receiver 635 are exemplified, the network equipment device 600 may have any preferred number of transmitters 630 and receivers 635. Furthermore, the transmitters 630 and receivers 635 may be any preferred type of transmitter and receiver.

[0188] Figure 7 is a flowchart of one embodiment of method 700 for receiving UAV authorization for UAV 106. Method 700 may be performed by a network function in a mobile communication network, such as SMF 145 and / or network equipment device 600. In some embodiments, method 700 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0189] Method 700 includes receiving a first request from AMF 143 705. In some embodiments, the request includes instructions to establish a user plane resource for UAS services for UAV device 106.

[0190] Method 700 further includes obtaining subscription information from UDM149 710. The subscription information includes instructions indicating that UAV authorization is required for the USS157 and / or UTM157 servers.

[0191] Method 700 includes sending a second request to UAS-NF147 to initiate UAV authorization 715. Method 700 then terminates.

[0192] Figure 8 is a flowchart of another embodiment of Method 800 for receiving UAV authorization for UAV 106. Method 800 may be performed by a network function within a mobile communications network, such as UAS-NF147 and / or network equipment device 600. In some embodiments, Method 800 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0193] Method 800 includes receiving a first request 805 to authenticate UAV device 106 for UAS services and determining 810 whether UAV device 106 has valid UAV authorization by checking a database that stores information on successfully authorized UAVs. Method 800 further includes determining the external identifier of UAV device 106 based on a second identifier 815. Method 800 also includes sending a second request 820 to authenticate the UAV device in a UTM 157 system, wherein the second request includes the external identifier and the second identifier.

[0194] Method 800 also includes receiving a UAV authorization result for UAV device 106 from the UTM157 system 825, and storing in a database 830 a UAV context indicating that UAV device 106 is authorized for UAS services, wherein the UAV context includes one or more of an external identifier and a second identifier. Method 800 then terminates.

[0195] Figure 9 is a flowchart of another embodiment of method 900 for receiving UAV authorization for UAV 106. Method 900 may be performed by a network function in a mobile communications network, such as AMF 143 and / or network equipment device 600. In some embodiments, method 900 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0196] Method 900 includes receiving a registration request 905 to establish one or more user plane resources for UAS services for UAV device 106, and determining 910 whether UAV device 106 has valid prior UAV authorization by checking locally stored user equipment ("UE") context. Method 900 further includes initiating a UAV authorization procedure 915 in response to determining that no valid UAV authorization is stored for the UAV device, and transmitting a first request 920 to SMF 145, the first request including instructions indicating to establish one or more user plane resources for UAS services for UAV device 106.

[0197] Method 900 further includes receiving a UAV authorization for UAV device 106 from SMF 145 925, the UAV authorization being approved by the UTM 157 system, and transmitting the UAV authorization to UAV device 930 930. Method 900 ends.

[0198] Disclosed herein is a first device for receiving UAV authorization for UAV 106 or 201, according to embodiments of the present disclosure. The first device may be implemented by communication devices within a mobile communication network, such as SMF145, SMF209, and SMF460, as described above. The first device comprises transceivers for communicating with AMF143, AMF207, AMF455, UDM149, UDM211, UAS-NF147, UAS-NF213, UASNF#1 465, UASNF#2 475, USS / UTM server 157, and / or USS / UTM server 205, as described above. The first device further comprises a processor that interacts interactively with and performs various operations with AMF143, AMF207, AMF455, UDM149, UDM211, UAS-NF147, UAS-NF213, UASNF#1 465, UASNF#2 475, USS / UTM server 157, and / or USS / UTM server 205.

[0199] In various embodiments, the processor is configured to receive a first request from AMF143, AMF207, or AMF455, which includes instructions to establish user plane resources for UAS services for UAV devices 106, 201. The processor retrieves subscription information from UDM node 149 or 211, which indicates that UAV authorization is required by the USS and / or UTM servers 157, 205. The processor further sends a second request to UAS-NF147, 213 to initiate UAV authorization.

[0200] In some embodiments, UAV authorization includes command and control ("C2") authorization for UAV devices 106, 201 and / or UUAA for UAV devices 106, 201. In some embodiments, a second request includes an instruction indicating whether the authorization is authorization for C2 operation and / or authorization for UUAA.

[0201] In some embodiments, the first request includes a UAV identifier and / or flight authorization information. In some embodiments, the transceiver receives an authorization response including a UAV authorization token and / or flight authorization identifier. In additional embodiments, the second request to UAS-NF147,213 includes the address of the USS / UTM server 157,205 for authorization, the UAV identifier, and flight authorization information provided by UAV 106,201.

[0202] In some embodiments, subscription information from UDMs 149 and 211 includes session management subscription data. The session management subscription data includes network slice-level data and, for each DNN, includes instructions on whether a request to establish a user plane resource requires UAV authorization from USS / UTM servers 157 and 205.

[0203] In additional embodiments, the processor is configured to determine whether valid UAV authorization information for UAV devices 106, 201 is stored in local memory, and to store in local memory a session management ("SM") context indicating that UAV devices 106, 201 are authorized for UAV operation in response to receiving an authorization response from UAS-NF147, 213. In some embodiments, retrieving subscription information data from UDM149, 211 is done in response to determining that valid UAV authorization information for UAV 106, 201 is not stored in local memory.

[0204] In some embodiments, the authorization response (including, for example, UAV authorization) is included in the UAS payload received from the USS / UTM servers 157, 205 via UAS-NF147, 213. In some embodiments, the UAS payload includes UAV authorization results for UAVs 106, 201 for one or more network slices.

[0205] Disclosed herein is a first method for receiving UAV authorization for UAV 106 or 201 according to embodiments of the present disclosure. The first method may be performed by a communication device in a mobile communication network, such as SMF145, SMF209, and SMF460, which interacts interactively with AMF143, AMF207, AMF455, UDM149, UDM211, UAS-NF147, UAS-NF213, UASNF#1 465, UASNF#2 475, USS / UTM server 157, and / or USS / UTM server 205, as described above.

[0206] The first method, in various embodiments, includes receiving a first request from AMF143, AMF207, or AMF455, the first request including instructions to establish user plane resources for UAS services for UAV devices 106, 201. The first method further includes retrieving subscription information from UDM node 149 or 211, the subscription information indicating that UAV authorization is required by USS and / or UTM servers 157, 205, and sending a second request to UAS-NF147, 213 to initiate UAV authorization.

[0207] In some embodiments, UAV authorization includes command and control ("C2") authorization for UAV devices 106, 201 and / or UUAA for UAV devices 106, 201. In some embodiments, a second request includes an instruction indicating whether the authorization is authorization for C2 operation and / or authorization for UUAA.

[0208] In some embodiments, the first request includes a UAV identifier and / or flight authorization information. In some embodiments, the first method includes receiving an authorization response that includes a UAV authorization token and / or a flight authorization identifier. In additional embodiments, the second request to UAS-NF147, 213, 470 includes the addresses of USS / UTM servers 157, 205 for authorization, the UAV identifier, and flight authorization information provided by UAVs 106, 201.

[0209] In some embodiments, subscription information from UDMs 149 and 211 includes session management subscription data. The session management subscription data includes network slice-level data and, for each DNN, includes instructions on whether a request to establish a user plane resource requires UAV authorization from USS / UTM servers 157 and 205.

[0210] In additional embodiments, the first method further includes determining whether valid UAV authorization information for UAV devices 106, 201 is stored in local memory, and storing in local memory a session management ("SM") context indicating that UAV devices 106, 201 are authorized for UAV operation in response to receiving an authorization response from UAS-NF 147, 213. In some embodiments, retrieving subscription information data from UDM 149, 211 is done in response to determining that valid UAV authorization information for UAV 106, 201 is not stored in local memory.

[0211] In some embodiments, the authorization response (including, for example, UAV authorization) is included in the UAS payload received from the USS / UTM servers 157, 205 via UAS-NF147, 213. In some embodiments, the UAS payload includes UAV authorization results for UAVs 106, 201 for one or more network slices.

[0212] Disclosed herein is a second device for receiving UAV authorization for UAV 106 or 201, according to embodiments of the present disclosure. The second device may be implemented by communication devices within a mobile communication network, such as UAS-NF147, UAS-NF213, and UASNF#1 465, and UASNF#2 475, as described above. The second device comprises transceivers for communicating with AMF143, AMF207, AMF455, SMF145, SMF209, SMF460, UDM149, UDM211, USS / UTM server 157, and / or USS / UTM server 205, as described above. The second device further comprises a processor that interacts interactively with and performs various operations with the AMF143, AMF207, AMF455, SMF145, SMF209, SMF460, UDM149, UDM211, USS / UTM system 157, and / or USS / UTM system 205.

[0213] In various embodiments, the processor is configured to receive a first request to authenticate the unmanned aerial vehicle devices 106, 201 for UAS services and to determine whether the UAV devices 106, 201 have valid UAV authorization by checking a database that stores information on successfully authorized UAVs. The processor is further configured to determine the external identifier of the UAV devices 106, 201 based on a second identifier and to send a second request to authenticate the UAV devices 106, 201 with the USS / UTM system 157, 205, the second request including the external identifier and the second identifier. The processor also receives the UAV authorization result for the UAV devices 106, 201 from the USS / UTM system 157, 205 and stores in the database a UAV context indicating that the UAV devices 106, 201 have been authorized for UAS services. In some embodiments, the UAV context includes the external identifier and / or a second identifier.

[0214] In a further embodiment, the processor is further configured to transmit a first UAV payload container to AMF143, 207, 455, the first UAV payload container including a third request for additional UAV information. The processor receives a second UAV payload container from AMF143, 207, 455, the second UAV payload container including the requested additional UAV information, and forwards the additional UAV information to UAS-NF147, 213. In some embodiments, UAV authorization for UAV devices 106, 201 is further based on the additional UAV information.

[0215] In some embodiments, the second identifier includes a CAA-Level UAV identifier, and the database includes information indicating that the CAA-Level UAV identifier has valid authorization for the UAS service. Here, the processor further determines that the first request does not include a CAA-Level UAV identifier, and the processor sends a third request to retrieve the CAA-Level UAV identifier from UAV devices 106, 201.

[0216] In some embodiments, retrieving the CAA-Level UAV identifier includes transmitting a third request to AMF 143, 207, 455 in response to a determination by the USS / UTM system 157, 205 that UAV devices 106, 201 are not authorized, and receiving the identifier for UAV devices 106, 201 and / or flight information for UAV devices 106, 201 from AMF 143, 207, 455. In some embodiments, the third request requests the identifier for UAV devices 106, 201 and / or flight information for UAV devices 106, 201. In some embodiments, UAV authorization for UAV devices 106, 201 is based on the identifier for UAV devices and / or flight information for UAV devices 106, 201.

[0217] In some embodiments, the second identifier includes a subscription permanent identifier ("SUPI"), and determining the external identifier involves using the SUPI to retrieve the external identifier from UDM nodes 149, 211.

[0218] In some embodiments, the first request is received from SMF145, 209, 460, and the processor further transmits the UAV authorization result to SMF145, 209, 460. In further embodiments, the request for UAV authorization includes UUAA and / or C2 authorization for UAV devices 106, 201.

[0219] Disclosed herein is a second method for receiving UAV authorization for UAV 106 or 201 according to embodiments of the present disclosure. The second method is performed by a communications device in a mobile communications network, such as UAS0NF147, UAS0NF213, and UASNF#1 465, where UASNF#2 475 may interact with AMF143, AMF207, AMF455, SMF145, SMF209, SMF460, UDM149, UDM211, USS / UTM system 157, and / or USS / UTM system 205 as described above.

[0220] A second method, in various embodiments, includes receiving a first request to authenticate UAV devices 106, 201 for UAS services and determining whether UAV devices 106, 201 have valid UAV authorization by checking a database storing information on successfully authorized UAVs. The second method further includes determining an external identifier for UAV devices 106, 201 based on a second identifier and sending a second request to authenticate UAV devices 106, 201 to USS / UTM systems 157, 205, wherein the second request includes the external identifier and the second identifier. The second method also includes receiving the UAV authorization result for UAV devices 106, 201 from USS / UTM systems 157, 205 and storing a UAV context in a database indicating that UAV devices 106, 201 have been authorized for UAS services. In some embodiments, the UAV context includes the external identifier and / or the second identifier.

[0221] In further embodiments, a second method includes transmitting a first UAV payload container to AMF143, 207, 455, the first UAV payload container including a third request for additional UAV information. A second method also includes receiving a second UAV payload container from AMF143, 207, 455, the second UAV payload container including the requested additional UAV information, and forwarding the additional UAV information to UAS-NF147, 213. In some embodiments, UAV authorization for UAV devices 106, 201 is further based on the additional UAV information.

[0222] In some embodiments, the second identifier includes a CAA-Level UAV identifier, and the database includes information indicating that the CAA-Level UAV identifier has valid authorization for the UAS service. Here, the processor further determines that the first request does not include a CAA-Level UAV identifier, and the processor sends a third request to retrieve the CAA-Level UAV identifier from UAV devices 106, 201.

[0223] In some embodiments, retrieving the CAA-Level UAV identifier includes transmitting a third request to AMF 143, 207, 455 in response to a determination by the USS / UTM system 157, 205 that UAV devices 106, 201 are not authorized, and receiving the identifier for UAV devices 106, 201 and / or flight information for UAV devices 106, 201 from AMF 143, 207, 455. In some embodiments, the third request requests the identifier for UAV devices 106, 201 and / or flight information for UAV devices 106, 201. In some embodiments, UAV authorization for UAV devices 106, 201 is based on the identifier for UAV devices and / or flight information for UAV devices 106, 201.

[0224] In some embodiments, the second identifier includes a SUPI, and determining the external identifier involves using the SUPI to retrieve the external identifier from UDM nodes 149 and 211.

[0225] In some embodiments, the first request is received from SMF145, 209, 460, and the processor further transmits the UAV authorization result to SMF145, 209, 460. In further embodiments, the request for UAV authorization includes UUAA and / or C2 authorization for UAV devices 106, 201.

[0226] Disclosed herein is a third device for receiving UAV authorization for UAV 106 or 201, according to embodiments of the present disclosure. The third device may be implemented by communication devices within a mobile communication network, such as AMF143, AMF207, and AMF455, as described above. The first device comprises transceivers for communicating with SMF145, SMF209, SMF460, UDM149, UDM211, UAS-NF147, UAS-NF213, UASNF#1 465, UASNF#2 475, USS / UTM server 157, and / or USS / UTM server 205, as described above. The third device further comprises a processor that interacts with and performs various operations with SMF145, SMF209, SMF460, UDM149, UDM211, UAS-NF147, UAS-NF213, UASNF#1 465, UASNF#2 475, USS / UTM system 157, and / or USS / UTM system 205.

[0227] In various embodiments, the processor is configured to receive registration requests to establish one or more user plane resources for UAS services for UAV devices 106, 201 and to determine whether UAV devices 106, 201 have valid prior UAV authorization by checking locally stored UE contexts. In response to determining that no valid UAV authorization is stored for UAV devices 106, 201, the processor initiates a UAV authorization procedure and sends a first request to SMFs 145, 209, 460, which includes instructions to establish one or more user plane resources for UAS services for UAV devices 106, 201. The processor receives UAV authorization for UAV devices 106, 201 from SMFs 145, 209, 460, receives UAV authorization approved by USS / UTM systems 157, 205 and transmits the UAV authorization to UAV devices 106, 201.

[0228] In some embodiments, the processor further receives a second request from UAS-NF147,213 to provide UAV information for UAV devices 106,201, and transmits a first UAV payload container to UAV devices 106,201, which includes the information request for UAV devices 106,201. The processor also receives a second UAV payload container from UAV devices 106,201, which includes information for UAV devices 106,201 in response to the information request, and forwards the second payload container to UAS-NF147,213. In a further embodiment, the information request includes an identifier request for UAV devices 106, 201 and / or a flight information request for UAV devices 106, 201, and the information for UAV devices 106, 201 in response to the information request includes an identifier for UAV devices 106, 201 and / or flight information for UAV devices 106, 201.

[0229] In an additional embodiment, the processor further receives a third UAV payload container from UAS-NF147,213, which contains a third request for additional authorization information for UAV devices 106,201, and forwards the third UAV payload container to UAV devices 106,201. The processor also receives a fourth UAV payload container from UAV devices 106,201, which contains additional authorization information for UAV devices 106,201 as requested by UAS-NF147,213, and forwards the fourth UAV payload container to UAS-NF147,213.

[0230] Disclosed herein is a third method for receiving UAV authorization for UAV 106 or 201 according to embodiments of the present disclosure. The third method may be performed by communication devices in a mobile communication network, such as AMF143, AMF207, and AMF455, which interact interactively with SMF145, SMF209, SMF460, UDM149, UDM211, UAS-NF147, UAS-NF213, UASNF#1 465, UASNF#2 475, USS / UTM server 157, and / or USS / UTM server 205, as described above.

[0231] In various embodiments, the third method includes receiving a registration request to establish one or more user plane resources for UAS services for UAV devices 106, 201, and determining whether UAV devices 106, 201 have valid prior UAV authorization by checking locally stored UE contexts. The third method further includes initiating a UAV authorization procedure in response to determining that no valid UAV authorization is stored for UAV devices 106, 201, and transmitting a first request to SMFs 145, 209, 460, the first request including instructions to establish one or more user plane resources for UAS services for UAV devices 106, 201. The third method also includes receiving UAV authorization for UAV devices 106, 201 from SMFs 145, 209, 460, receiving UAV authorization approved by USS / UTM systems 157, 205, and transmitting the UAV authorization to UAV devices 106, 201.

[0232] A third method, in some embodiments, further includes receiving a second request from UAS-NF147,213 to provide UAV information for UAV devices 106,201, and transmitting a first UAV payload container to UAV devices 106,201, wherein the first UAV payload container includes an information request for UAV devices 106,201. The third method also includes receiving a second UAV payload container from UAV devices 106,201, wherein the second UAV payload container includes information for UAV devices 106,201 in response to the information request, and forwarding the second payload container to UAS-NF147,213. In a further embodiment, the information request includes an identifier request for UAV devices 106, 201 and / or a flight information request for UAV devices 106, 201, and the information for UAV devices 106, 201 in response to the information request includes an identifier for UAV devices 106, 201 and / or flight information for UAV devices 106, 201.

[0233] In an additional embodiment, the third method further includes receiving a third UAV payload container from UAS-NF147,213, the third UAV payload container including a third request for additional authorization information for UAV devices 106,201, and forwarding the third UAV payload container to UAV devices 106,201. The third method also includes receiving a fourth UAV payload container from UAV devices 106,201, the fourth UAV payload container including additional authorization information for UAV devices 106,201 as requested by UAS-NF147,213, and forwarding the fourth UAV payload container to UAS-NF147,213.

[0234] The embodiments may be carried out in other specific forms. The embodiments described should be considered in all respects to be for illustrative purposes only and not to be limiting. Accordingly, the scope of this disclosure is indicated by the accompanying claims rather than by the foregoing description. All modifications that fall within the meaning and scope of equivalence of claims should be incorporated into the scope of the invention. [Explanation of Symbols]

[0235] 100 Wireless Communication Systems 101 Unmanned Aerial Vehicle Systems ("UAS") 103 UAS Operator 105 Remote Unit 106 Unmanned Aerial Vehicle (“UAV”) 107 applications 108 UAV Controller ("UAV-C") 120 Wireless Access Network ("RAN") 121 Base Unit 123 Wireless communication link 140 Mobile Core Network 141 User Plane Function ("UPF") 143 Mobility Management Function ("AMF") 145 Session Management Function ("SMF") 146 Network publishing function ("NEF") 147 UAS Network Function ("UAS-NF") 149 Combined entities "UDM / UDR" 150 packet data network 151 Application Server 155 UAS-NF 157 Combined Nodes "USS / UTM" 200 steps 201 UE 203 UAS Operator 205 USS / UTM Server 207 AMF 209 SMF 211 UDM 213 UAS-NF 215 NEF 300 steps 400 Network Architectures 405 UAS#1 410 UAV-C#1 415 UAV #1 417 UAV #3 420 UAS#2 425 UAV-C#2 430 UAV #2 435 PUMN #1 440 PUMN #2 445 Internet 450 The First AMF (AMF#1) 455 The first SMF (SMF#1) 460 UPF #1 465 UASNF#1 470 UPF #2 475 UASNF#2 480 User Plane Connection 485 User Plane Connection 490 User Plane Connection 495 User Plane Connection 500 User Equipment ("UE Equipment") 505 Processor 510 memory 515 Input Devices 520 Output Devices 525 Transceiver 530 Transmitter 535 Receiver 540 Network Interfaces 545 Application Interfaces 600 Network Equipment 605 Processor 610 memory 615 Input Devices 625 Transceiver 630 Transmitter 635 Receiver 640 network interfaces 645 Application Interfaces

Claims

1. A method for network functions within a mobile communication network, A step of receiving a first request from an Access and Mobility Management Function ("AMF"), wherein the first request includes an instruction indicating the establishment of a user plane resource for an unmanned aerial vehicle ("UAV") system ("UAS") service for an unmanned aerial vehicle ("UAV") device, A step of retrieving subscription information from an Integrated Data Management Node ("UDM"), wherein the subscription information indicates that UAV authorization is required by a UAS Service Subscriber ("USS") and / or UAS Traffic Management ("UTM") server, The steps include sending a second request to the UAS network function ("UAS-NF") to initiate the UAV authorization, The aforementioned first request includes flight permission information, The method further comprises the step of receiving a permission response which includes one or more of a UAV permission token and / or flight permission identifiers.

2. The method according to claim 1, wherein the UAV authorization includes one or more of command and control ("C2") authorization for the UAV device and UAV USS authorization / authentication ("UUAA") for the UAV device, and the second request includes an instruction indicating whether the authorization is authorization for C2 operation and / or authorization for UUAA.

3. The method according to claim 1, wherein the first request further includes a UAV identifier.

4. The method according to claim 3, wherein the second request to the UAS-NF includes the address of the USS / UTM server for permission, the UAV identifier, and the flight permission information provided by the UAV.

5. The method according to claim 1, wherein the subscription information from the UDM includes session management subscription data, the session management subscription data includes network slice level data, and the session management subscription data includes, for each DNN, an indication of whether a request to establish a user plane resource requires UAV authorization from the USS and / or UTM server.

6. A step of determining whether valid UAV authorization information for the UAV device is stored in local memory, The step of retrieving the subscription information data from the UDM is performed in response to determining that no valid UAV authorization information for the UAV is stored in the local memory, The method according to claim 1, further comprising the step of storing in local memory a session management ("SM") context that instructs the UAV device to be authorized for UAV operation in response to receiving a permission response from the UAS-NF.

7. The method according to claim 1, wherein the authorization response is contained within the UAS payload received from the USS and / or UTM server via the UAS-NF, and the UAS payload includes UAV authorization results for the UAV for one or more network slices.

8. A device within a mobile communication network, Transceiver and, It is a processor, Receiving a first request from the Access and Mobility Management Function ("AMF"), the first request including instructions to establish a user plane resource for unmanned aerial vehicle system ("UAS") services for an unmanned aerial vehicle ("UAV") device, Retrieving subscription information from the Integrated Data Management Node ("UDM"), wherein the subscription information indicates that UAV authorization is required by the UAS Service Subscriber ("USS") and / or UAS Traffic Management ("UTM") server, Sending a second request to the UAS network function ("UAS-NF") to initiate the aforementioned UAV authorization. The processor performing Equipped with, The aforementioned first request includes flight permission information, The device wherein the processor further receives a permission response which includes one or more of the UAV permission token and / or flight permission identifiers.

9. The apparatus according to claim 8, wherein the UAV authorization includes one or more of command and control ("C2") authorization and UAV USS authorization / authentication ("UUAA") for the UAV device, and the second request includes an instruction indicating whether the authorization is authorization for a C2 operation and / or authorization for a UUAA.

10. The apparatus according to claim 8, wherein the first request further includes a UAV identifier.

11. The apparatus according to claim 10, wherein the second request to the UAS-NF includes the address of the USS / UTM server for authorization, the UAV identifier, and the flight authorization information provided by the UAV.

12. The apparatus according to claim 8, wherein the subscription information from the UDM includes session management subscription data, the session management subscription data includes network slice level data, and the session management subscription data includes, for each DNN, an indication of whether a request to establish a user plane resource requires UAV authorization from the USS and / or UTM server.

13. The processor To determine whether valid UAV authorization information for the UAV device is stored in local memory, In response to determining that no valid UAV authorization information for the UAV is stored in the local memory, the subscription information data is retrieved from the UDM. The system stores in local memory a session management ("SM") context that instructs the UAV device to be authorized for UAV operation in response to receiving a permission response from the UAS-NF. The apparatus according to claim 8, further performing the following.

14. The apparatus according to claim 8, wherein the authorization response is contained in a UAS payload received from the USS and / or UTM server via the UAS-NF, and the UAS payload includes UAV authorization results for the UAV for one or more network slices.

15. The apparatus according to claim 8, which implements a session management function ("SMF").

Images