Unmanned aerial vehicle authentication and authorization through unmanned aerial vehicle system traffic management via user plane.

Abstract

This invention provides a system and method for unmanned aerial vehicle (UAV) system traffic management (UTM) through UAV certification and approval. [Solution] UAV authentication and authorization may be performed by a third-party service provider (e.g., UTM via the user plane (UP)). The UAV may be configured to transmit a UAV ID to the network. The UAV may receive security information from the network indicating authorization for connection to the third-party service provider. Based on the security information, the UAV may establish a connection to the third-party service provider for communication with the third-party service provider. The security information may include the third-party service provider's signature information and one or more of the following: a subscription ID associated with the UAV, a UAV ID, or the third-party service provider's ID.

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application claims the benefit of U.S. Provisional Application No. 62 / 976,120, filed on February 13, 2020, the content of which is incorporated herein by reference.

Background Art

[0002] Mobile communication using wireless communication has been continuously evolving. The fifth generation can be referred to as 5G. Previous (conventional) generations of mobile communication can be, for example, the fourth generation (4G) long - term evolution (LTE).

Summary of the Invention

[0003] This specification describes systems and methods for authentication and authorization of unmanned aerial vehicles (UAVs) by third-party service providers (e.g., unmanned aerial system traffic management (UTM) via a user plane (UP)). A UAV may be configured to transmit one or more of the following to the network: a UAV identifier (ID), a data network name (DNN), and single network slice selection assistance information (S-NSSAI). The UAV may receive security information from the network indicating authorization for connection to the third-party service provider. Based on the security information, the UAV may establish a connection to the third-party service provider and communicate with the third-party service provider. The security information may include the third-party service provider's signature information and one or more of the following: a subscription identifier (ID) associated with the UAV, a UAV ID, or the third-party service provider's ID. The UAV may transmit its UAV ID to the network in a request message for a communication session. The UAV can receive security information in a response message for a communication session and establish a connection to a third-party service provider through the communication session. For example, the security information may include a token. The token may include signature information associated with the third-party service provider, bound to the UAV ID, a generic public subscription identifier (GPSI), and the identity of the third-party service provider. For example, the security information may include a key bound to the UAV ID and the identity of the third-party service provider.UAVs can send application layer messages to third-party service providers to establish a connection to them using security information.

[0004] A network device can receive a registration request from a wireless transmit / receive unit (WTRU) and, based on the registration request, determine the WTRU's subscription to the UAV's operation. The network device can send the subscription identifier associated with the WTRU to a third-party service provider. The network device can receive security information from the third-party service provider indicating authorization for the connection between the WTRU and the third-party service provider. The network device can send security information to the WTRU. The security information may include one or more of the following: the third-party service provider's signature information, the subscription ID associated with the WTRU, the UAV ID associated with the WTRU, or the third-party service provider's ID. The network device can receive the UAV ID associated with the WTRU from the WTRU in a request message for a communication session. The network device can send security information in a response message for a communication session. For example, the security information may include a token. The token can bind the UAV ID associated with the WTRU, GPSI, and the third-party service provider's ID, and may include the signature information associated with the third-party service provider. For example, the security information may include a key bound to the UAV ID associated with the WTRU and the third-party service provider's ID.

[0005] Third-party service providers can provide unmanned aerial system (UAS) traffic management (UTM). Third-party service providers may include UAS service suppliers (USS). The identity of a third-party service provider may include a fully qualified domain name (FQDN). [Brief explanation of the drawing]

[0006] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This example illustrates UAS interaction between the network and a third-party service provider (e.g., UTM) for authorization purposes. [Figure 3] This document illustrates exemplary interactions and messaging for UAV authentication and authorization by a third-party service provider (e.g., USS / UTM). [Figure 4] This demonstrates exemplary interactions and messaging for UAV authentication and authorization by a third-party service provider (e.g., USS / UTM) using security information (e.g., bootstrap keys). [Figure 5] This illustrates exemplary interactions and / or messaging for UAV authentication and authorization by a third-party service provider using security information such as tokens (e.g., UTM authorization tokens). [Figure 6] This demonstrates exemplary interactions and messaging for UAV authorization by a third-party service provider (e.g., USS / UTM) for additional services (e.g., UTM services). [Figure 7] This demonstrates exemplary interactions and messaging for UAV authorization by a third-party service provider (e.g., USS / UTM) with failure handling for expired or invalid keys. [Figure 8] This document illustrates exemplary interactions and messaging for UAV authorization by a third-party service provider (e.g., USS / UTM) involving failure handling for expired or invalid certificates. [Modes for carrying out the invention]

[0007] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a plurality of access systems that provide content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0008] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

[0009] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node B, eNode B, Home Node B, Home eNode B, gNB, NR Node B, Site Controller, Access Point (AP), Wireless Router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0010] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectra, unlicensed spectra, or a combination of licensed and unlicensed spectra. Cells may provide coverage of radio services to a specific geographic area, which may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, the base station 114a can use multiple-input multiple output (MIMO) technology and utilize multiple transceivers per sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0011] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 may be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0012] More specifically, as described above, the communication system 100 may be a multi-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c within RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0013] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 116 using Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0014] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0015] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technology transmitted to / from multiple types of base stations (e.g., eNBs and gNBs) and / or transmissions.

[0016] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), GSM Evolution (Enhanced Data rates for GSM Evolution (EDGE)), GSM EDGE (GERAN), etc.

[0017] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and any suitable RAT may be used to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d can establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0018] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same RAT or a different RAT as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 that can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) in the TCP / IP Internet protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0020] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which can use cellular-based radio technology, and base station 114b, which can use IEEE 802 radio technology.

[0021] Figure 1B is a system diagram illustrating an example of an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the aforementioned elements, as is consistent with the embodiment.

[0022] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors working with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0023] The transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmitting / receiving element 122 may be a light emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It will be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of radio signals.

[0024] Although the transmitting / receiving element 122 is illustrated as a single element in Figure 1B, the WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0025] The transceiver 120 may be configured to modulate the signal transmitted by the transmitting / receiving element 122 and demodulate the signal received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0026] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in that memory.

[0027] The processor 118 may receive power from the power supply 134 and be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0028] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method, while maintaining consistency with the embodiment.

[0029] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0030] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception)) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., transmission) or downlink (e.g., reception)).

[0031] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0032] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0033] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in UL and / or DL. As shown in Figure 1C, the eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0034] The CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned elements is depicted as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0035] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, as well as for bearer activation / deactivation, and for selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0036] The SGW164 can be connected to each of the eNode B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions such as anchoring the user plane during eNode B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0037] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0038] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0039] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0040] In a typical embodiment, the other network 112 may be a WLAN.

[0041] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with another type of wired / wireless network that carries traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for an STA may reach and be delivered to the STA via the AP. Traffic originating from an STA destined for an outside BSS may be sent to the AP and then delivered to its respective destination. Traffic between STAs within the BSS may be transmitted, for example, via the AP; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

[0042] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some typical embodiments, for example in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time in a given BSS.

[0043] A high-throughput (HT) STA can, for example, form a 40MHz wide channel for communication by using a 40MHz wide channel via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels.

[0044] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to Medium Access Control (MAC).

[0045] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for specific and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0046] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, a large portion of the frequency band may remain idle and could be considered busy, even if it were available.

[0047] In the United States, the available frequency band that can be used by 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0048] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0049] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0050] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0051] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. Non-standalone WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0052] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0053] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although each of the aforementioned elements is depicted as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0054] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b can perform roles such as user authentication for WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0055] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0056] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN113, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0057] CN115 can facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Furthermore, CN115 may provide WTRU102a,102b,102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a,102b,102c may be connected to local data networks (DN) 185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and DN185a,185b.

[0058] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0059] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

[0060] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0061] For example, systems and methods for UAV authentication and authorization by UTM via User Plane (UP) are described herein. USS, USS / UTM, or UTM may be used interchangeably in one or more embodiments described herein.

[0062] A UAV can be authenticated and authorized by a UTM via UP using a key bootstrapped by the network (for example, during the PDU session establishment procedure). For example, a WTRU can send its UAV ID and USS / UTM DNN (for example, in a PDU session establishment request message). The WTRU can receive the network bootstrap key (for example, in a PDU session establishment acceptance message). The key can bind the WTRU identity, UAV identity, and USS / UTM identity (for example, a domain name). The WTRU can perform authentication / authorization by a USS / UTM via UP using the network bootstrap key (for example, using PSK-TLS) and UAV provisioning credentials (for example, UAV ID, UAV certificate). A UAV can be authenticated and authorized by a UTM via UP using a UTM-generated authorization token provided by the network (for example, during the PDU session establishment procedure). For example, a WTRU can send its UAV ID and USS / UTM DNN (e.g., in a PDU session establishment request message). A WTRU can receive a UTM-generated authorization token (e.g., in a PDU session establishment acceptance message). The token can bind WTRU identification information, UAV identification information, and USS / UTM identification information (e.g., domain name). A WTRU can use UAV provisioning credentials (e.g., UAV ID and UAV certificate in the SSL handshake) to send a UTM authorization token during authentication / authorization by USS / UTM via UP.

[0063] Mobile communications (e.g., 3GPP) can support one or more of the following: remote identification and authorization of unmanned aerial vehicles (UAS), command and control (C2) communications, UAV navigation by a UAV Controller (UAV-C) or UAS Traffic Management (UTM), and / or changes to the UAV-C during a flight mission. The WTRU described herein may be a UAV or include a UAV. The WTRU described herein may be a UAV-C or include a UAV-C.

[0064] Figure 2 illustrates an example of UAS interaction between a network for authentication and a third-party service provider (e.g., UTM). A UAS may include, for example, one of a UAV (e.g., a drone) and / or a UAV-C (e.g., as shown in the example in Figure 2), or a combination thereof. A mobile communication system (e.g., 3GPP, or other non-3GPP systems) may provide communication capability between the UAV and UAV-C, which can communicate via the same or different Radio Access Network (RAN) nodes and a public land mobile network (PLMN). The UAV and UAV-C may be connected via the mobile communication system. The UTM may provide, for example, one or more of the following: UAS identification and tracking, authorization, enforcement, coordination of UAS operations, and / or data storage for UAS operations.

[0065] Authentication and authorization (e.g., by a third-party service provider) can be performed using, for example, authentication and authorization procedures (e.g., 3GPP procedures).

[0066] Authentication and authorization procedures may be network slice specific. For example, network slice specific secondary authentication and authorization (NSSAA) (e.g., NSSAA procedure) may be performed. A WTRU may, for example, perform NSSAA via a third-party authorization, authorization, and accounting (AAA) server (e.g., using non-3GPP credentials) for a single network slice selection assistance information (S-NSSAI) within a requested NSSAI subject to NSSAA, following primary authentication, for example, all of them, through the network (e.g., access and mobility management function (AMF)). The network (e.g., AMF) may determine which S-NSSAI requires NSSAA (e.g., NSSAA execution) based on one or more of the following: WTRU capability to perform NSSAA, subscription information, and / or operator policies. An extensible authentication protocol (EAP)-based authentication procedure with the WTRU may be triggered, for example, after the registration procedure for all applicable S-NSSAI. A network (e.g., AMF) can act as an authenticator for EAP authentication between the WTRU and a third-party AAA server. The WTRU can be successfully authenticated for a given S-NSSAI. The S-NSSAI (e.g., involved in the successful authentication) can be added to the authorized NSSAI in the WTRU configuration, for example, via a WTRU configuration update procedure.

[0067] Secondary authentication / authorization may be provided, for example, by a data network (DN)-AAA server during the establishment of a communication session (e.g., a protocol data unit (PDU) session). The WTRU may transmit authentication / authorization information corresponding to DN-specific identification information to the network (e.g., a Session Management Function (SMF)) (e.g., during the PDU session establishment procedure). The network (e.g., the SMF) may decide whether authentication / authorization is performed or requested, for example, based on an SMF policy associated with the DN. Authentication between the WTRU and DN-AAA may be performed, for example, using the EAP protocol (e.g., the SMF can act as the authenticator). The communication session establishment procedure (e.g., the PDU session establishment procedure) may be accepted, for example, if the WTRU is successfully authenticated. For example, if the WTRU is not successfully authenticated, the communication session establishment procedure may be rejected.

[0068] Additional certification / approval of a UAS by a third-party service provider (e.g., UTM) may be enabled by a mobile communications system (e.g., 3GPP system). In some cases, flight operation approval (e.g., final approval) from a third-party service provider (e.g., UTM) may be obtained and / or implemented by a mobile communications system (e.g., 3GPP system).

[0069] A mobile communication system may enable a mobile network operator (MNO) to make a UAS authentication request (e.g., only if appropriate subscription information is available). A mobile communication system may enable a UAS to transmit different UAS data to a third-party service provider (e.g., UTM) based on different authentication and authorization levels applied to the UAS. A mobile communication system may enable a third-party service provider (e.g., UTM) to notify the MNO of the results of the authorization of the operation.

[0070] An MNO can complete the initial certification and approval (e.g., initial certification and approval) of the WTRU's onboard UAV / UAV-C (e.g., based on 3GPP credentials / subscription). An MNO can allow for further checks (e.g., secondary checks) by a third-party service provider such as UTM (e.g., using non-3GPP credentials, e.g., UAV owner certificates and UAV operator certificates) for one or more of the following: UAV / UAV-C certification and approval, flight plan approval, or additional UTM service certification and approval (e.g., flight monitoring, collision avoidance).

[0071] Secondary checks may include, for example, the exchange of one or more certifications and approvals that can meet national regulatory requirements. One or more secondary checks may depend on whether several services (e.g., UTM services, e.g., flight monitoring) are activated. Protocols for additional certifications and approvals may take into account different potential deployments of third-party service providers (e.g., UTM).

[0072] Protocols for UAV authentication and authorization by third-party service providers (e.g., UTMs) can support evolved packet systems (EPS) and / or 5G systems (5GS). Procedures or implementations may be provided for performing one or more of the following: UAV re-authentication / authorization, invalidation of UAV authorization, and / or failure of UAV authentication and authorization.

[0073] The UAV may be equipped with a WTRU (e.g., 3GPP and / or other mobile communication systems) that has UAS communication capabilities. UAV-C communication may be enabled via the WTRU components (e.g., 3GPP and / or other mobile communication systems) and / or other types of communication modules (e.g., using landline communication). The UAV-C may be equipped with a WTRU (e.g., 3GPP and / or other mobile communication systems).

[0074] A WTRU ID (e.g., International Mobile Subscriber Identity (IMSI), or Mobile Station International Subscriber Directory Number (MSISDN)), or GPSI can identify a mobile communications system (e.g., 3GPP) compliant device. The WTRU ID may be used interchangeably with a UAV WTRU ID in one or more examples herein.

[0075] A UAV ID can identify a UAV-enabled device (e.g., a drone). A UAV ID can be an external identifier. A UAV ID may be provided by a UAS service supplier (USS) / UTM. A UAV ID may be assigned, for example, when registered with a local authority (e.g., the Federal Aviation Administration, FAA) or at the time of manufacture (e.g., as a manufacturer serial number such as a PEI). A UAV ID may be provisioned. A UAV ID may be configured for a UAV device (e.g., known by) or learned by the UAV device. A UAV ID may include a Central Aviation Authority (CAA) level UAV ID.

[0076] The UAV WTRU ID can identify the UAV's cellular modem (e.g., IMSI, MSISDN).

[0077] A UAS ID can identify a UAS (e.g., the association between a UAV and a UAV-C). A UAS ID can be assigned by a UAS system (e.g., a system outside of a mobile communications (e.g., 3GPP) network). A UAS ID may include a CAA-level UAV ID.

[0078] Figure 3 illustrates exemplary interactions and messaging for UAV authentication and authorization by a third-party service provider (e.g., USS / UTM). Network entities may include, for example, an Evolved Universal Mobile Communications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) having access connected to a 5G core network (5G core, 5GC) or an Evolved Packet Core (EPC), or Next Generation RAN (NG-RAN) / NR access connected to a 5GC. Access may be provided to the UAV-C (e.g., with a WTRU) via non-3GPP access (e.g., WLAN) connected to the 5GC or EPC.

[0079] The system (e.g., the 3GPP system) may provide key bootstrapping based on key material such as system (e.g., 3GPP) credentials (e.g., bound to UAV and UTM identification information) to third-party service providers such as WTRU and / or USS / UTM (e.g., subject to the WTRU subscription including appropriate authorization for air operations).

[0080] The WTRU can perform UAV authentication and authorization (e.g., via a UTM procedure over the user plane (UP)) using, for example, bootstrap key material and / or UAV provisioning credentials. A third-party service provider (e.g., UTM) can then notify the network of the results of the procedure.

[0081] Successful authentication of a WTRU by a third-party service provider (e.g., UTM) using security information (e.g., bootstrap keys) can verify that the WTRU onboard the UAV has a valid corresponding UAV subscription (e.g., the WTRU onboard the UAV is authorized by the network for aerial operations, according to UAV characteristics).

[0082] Successful authentication and authorization from a third-party service provider (e.g., UTM) can indicate or confirm to the (e.g., 3GPP) network that the UAV (e.g., including an onboard WTRU) (i) has obtained connectivity with the third-party service provider and / or UAV-C, and / or (ii) has the authority to perform C2 communications (e.g., subject to additional service authentication and authorization by the UTM).

[0083] The network (e.g., the 3GPP system) can provide security information (e.g., tokens bound to WTRU and UAV identification information) to the WTRU (e.g., WTRU subscriptions include appropriate authorization for airborne operations). The tokens may be UTM-generated tokens.

[0084] A WTRU can perform UAV authentication and authorization (e.g., via a UTM procedure over the user plane (UP)) using, for example, security information (e.g., tokens such as UTM authorization tokens) and / or credentials provisioned on the UAV. A third-party service provider (e.g., UTM) can notify the network of the results of the UAV authentication and authorization (e.g., via a UTM procedure over the UP).

[0085] Successful authentication of a WTRU by a third-party service provider (e.g., by a UTM using a UTM token) can verify that the WTRU deployed on the UAV has a valid corresponding UAV subscription.

[0086] UAS service connectivity may be provided by the network, for example, based on successful authentication and authorization results from a third-party service provider (e.g., UTM).

[0087] UAV authentication and authorization via UP (e.g., by UTM) may succeed if, for example, the WTRU obtains security information (e.g., valid bootstrap key material or UTM token as described herein) (e.g., the UAV / WTRU may obtain network connectivity for UAS operation based on success). UAV authentication and authorization via UP (e.g., by UTM) may fail if, for example, the WTRU cannot obtain security information (e.g., valid bootstrap key material or UTM token) (e.g., the UAV / WTRU may deny network connectivity for UAS operation based on failure).

[0088] Referring to the diagrams, one or more of the operations may be performed via the user plane (UP), for example, in Figure 3-3, Figure 4-10, and Figure 5-9. A third-party service provider may consist of one or more entities. A third-party service provider may reside in a remote server. The USS and UTM are shown as entities in the same location for brevity, but may be separate in various deployment implementations. In the examples provided in the diagrams, operations are identified by numbers. Unless explicitly indicated or essentially required, there is no requirement for the order of operations. There is no requirement that a procedure perform all operations shown in an example. The diagrams illustrate several examples of many possible exemplary implementations, and fewer, more, or different operations, interactions, messaging, etc., may be implemented in various orders.

[0089] Figure 3 illustrates exemplary interactions and messaging for UAV authentication and authorization by a third-party service provider (e.g., USS / UTM). As shown in Figure 3, in 1, the WTRU (UAV) may perform initial authentication and authorization for network access (e.g., initial authentication and authorization procedure). The WTRU may receive connectivity parameters (e.g., USS / UTM DNN / APN, S-NSSAI) from the third-party service provider (e.g., during the initial authentication and authorization) to establish a connection to the USS / UTM, for example.

[0090] As shown, in section 2, the WTRU can configure connectivity (for example, for UAV authentication and authorization by USS / UTM) by providing parameters such as USS / UTM connectivity parameters (e.g., USS / UTM DNN / APN, S-NSSAI). The network (e.g., SMF) can restrict communication (e.g., only) toward the third-party service provider (e.g., USS / UTM) for the purpose of authentication / authorization messaging (e.g., until the UAV is successfully authenticated / authorized by the third-party service provider).

[0091] A WTRU may receive one or more of the bootstrap key (e.g., shared secret key, master key, UAV application master key (UA-MK)), key identifier (e.g., UA-MK-ID), and / or key lifetime (e.g., from the network, during a procedure such as a communication session establishment procedure). In some examples, a WTRU may obtain key material (e.g., UA-MK and UA-MK-ID) based on commands / instructions from the network (e.g., by performing an operation locally to derive it). A third-party service provider (e.g., USS / UTM) may receive network key material (e.g., one or more of the bootstrap key, key identifier, and / or key lifetime) during a procedure. The network can generate security information (e.g., bootstrap keys used for security-related WTRU-USS / UTM) based on specific credentials or specific key material, such as by deriving a network anchor key or network access key generated based on credentials that can be used to access the network (e.g., derived from 3GPP long-term / private key K or Ki, or from specific key material). The network can generate security information (e.g., bootstrap keys) based on arbitrary parameters (e.g., random numbers). The keys (e.g., bootstrap keys) can be bound to UAV identification information and USS / UTM identification information (e.g., hostname or FQDN). The network can bind additional UAV subscription-related parameters (e.g., one or more UAVs or a UAV category value that may indicate the weight and / or range characteristics of the UAVs, or a UAV class value that may indicate the weight and / or range characteristics of the UAVs). In some cases, a WTRU may receive instructions (e.g., from the network) to perform key derivation, and / or the WTRU may perform key derivation once it receives key material for key derivation (e.g., USS / UTM identification information, and / or counter / nonce).

[0092] In some cases, the WTRU may receive security information (e.g., a token, e.g., an authorization token generated by a USS / UTM) from the network, for example, during a procedure to establish connectivity (e.g., a communication session as described herein). A third-party service provider (e.g., a USS / UTM) may generate security information based on the WTRU identification information (e.g., GPSI) and UAV identification information by binding, for example, the WTRU identification information and UAV identification information (e.g., the WTRU identification information and UAV identification information may be received from the network during a communication session establishment procedure, e.g., a PDU session establishment procedure). The security information (e.g., a token) may include a lifetime. The security information (e.g., a token) may be authenticated (e.g., signed by a third-party service provider to include the third-party service provider's signature information). The security information (e.g., a token) may be encrypted, for example, to preserve the confidentiality of the WTRU identification information and UAV identification information. The WTRU identification information and / or UAV identification information may be included in the security information (e.g., a token). Security information may include identifiers of third-party service providers (e.g., USS / UTM identification information, e.g., hostname, or FQDN).

[0093] As shown, in 3, the WTRU can perform application layer procedures (e.g., via the user plane) for UAV authentication and authorization (e.g., by a third-party service provider such as a UTM).

[0094] The WTRU may send a key identifier (e.g., UA-MK-ID) to a third-party service provider (e.g., USS / UTM) during application layer procedures (e.g., in the initial application session establishment request). The third-party service provider may retrieve the associated UAV application master key (e.g., from local storage) or request it from the network (e.g., by providing the UAV application master key identifier). The WTRU and the third-party service provider may use the shared UAV application master key to perform mutual authentication and / or obtain an application session-specific key (e.g., further derive it) to secure communications (e.g., using the PSK-TLS protocol). The WTRU may perform UAV authentication / authorization with the third-party service provider using UAV credentials (e.g., using a UAV owner certificate over secure communication).

[0095] In some cases, a WTRU can send a token (e.g., a USS / UTM-generated authorization token) to a third-party service provider such as a USS / UTM (e.g., during application layer procedures, such as in an initial application session establishment request). The WTRU and USS / UTM can then perform mutual authentication (e.g., using the SSL client certificate protocol) and / or secure their communication based on their provisioned credentials (e.g., their respective UAV / client and UTM / server certificates).

[0096] As shown, in 3, a third-party service provider (e.g., USS / UTM) may notify the network of the results of the authentication / authorization procedure (e.g., the results of the application layer procedure by the USS / UTM for, for example, UAV authentication and authorization).

[0097] As shown, in steps 4-7, the WTRU may perform additional authentication and authorization procedures using application layer communication for, for example, discovery of the UAV-C and / or association with it (e.g., for UAS operation / C2 communication). The result in step 4 may include the result of pairing with the UAV-C. The result in step 5 may include the result of flight authorization (e.g., UAS operation). Different connectivity with the network (e.g., new connectivity) may be established, or connectivity (e.g., existing connectivity) may be modified to enable C2 communication with the UAV-C and / or USS / UTM, for example. The roles of one or more UAVs and UAV-Cs (e.g., as shown in Figure 3) may be interchangeable (e.g., UAV-C with WTRU).

[0098] UAV authentication and authorization may be provided by a third-party service provider, such as a UTM, using, for example, a bootstrap key based on 3GPP credentials.

[0099] Figure 4 illustrates exemplary interactions and messaging for UAV authentication and authorization by a third-party service provider (e.g., USS / UTM) using security information (e.g., bootstrap keys). In the example shown in Figure 4, UAV authentication and authorization by USS / UTM may be performed, for example, in a call flow, using bootstrap keys based on key material (e.g., 3GPP credentials).

[0100] A WTRU can perform a bootstrap procedure using, for example, control plane (CP) signaling with the network (e.g., PDU session establishment procedure). A WTRU can perform a bootstrap (e.g., bootstrap procedure) using messaging via the user plane (UP). Bootstrap key material may be generated based on 3GPP credentials (e.g., long-term / private key K or Ki provisioned on the SIM card, or access key material) and / or bound to UAV and UTM identification information.

[0101] The WTRU can perform bound UAV / WTRU authentication / authorization using bootstrap key material, for example, by USS / UTM procedures (e.g., using one or more of the 10-19 shown in Figure 4).

[0102] The example shown in Figure 4, using 5GC network functions (NF) (e.g., AMF and SMF), may be applicable to EPC equivalent functions (e.g., MME / PGW-C). Communication between the network and third-party service providers (e.g., USS / UTM) can be implemented through various interfaces in EPC or 5GC deployments. In one example (e.g., for a 5GC implementation), the interface may be implemented via UPF (e.g., using an SMF N4 session) or a network exposure function (NEF). In EPC, this interface may be implemented via a policy and charging rules function (PCRF) (e.g., an Rx interface) or a bootstrapping server function (BSF).

[0103] As shown in Figure 4, in 1, a WTRU (e.g., a UAV) can register with the network. As shown in Figure 4, a WTRU may send a registration request to the network. In a registration request, for example, the WTRU may provide one or more of the following parameters: UAV capabilities (e.g., one or more of the following, including direct stick steering, autonomous flight by UTM, e.g., UAV class / weight, beyond visual line of sight (BVLOS) flight capability, supported control modes), UAV slice information (e.g., UAV-specific slice information such as S-NSSAI, including a specific slice / service type (SST) value, e.g., the value of "UAS"), instructions to request third-party service provider data network name (DNN) information (e.g., USS / UTM DNN information), subscription identifier (e.g., IMS or SUPI), and / or configuration information (e.g., UAV ID).

[0104] As shown, in section 2, the network (e.g., AMF) may check and / or determine that the subscription for UAV operations is approved based on subscription information associated with the WTRU (e.g., from the WTRU subscription). The network (e.g., AMF) may determine that additional UAV certification / approval (e.g., UAV certification / approval by USS / UTM) is performed or required.

[0105] As shown, in section 3, the network (e.g., AMF) can send a registration acceptance message to the WTRU. The message may include, for example, one or more of the following parameters: (a) S-NSSAI (e.g., S-NSSAI specific to UAV operations in authorized NSSAI), and / or (b) a DNN associated with a third-party service provider (e.g., a dedicated USS / UTM DNN that may be used by the WTRU to establish authentication / authorization and / or connectivity with the USS / UTM).

[0106] As shown, in 4, the WTRU may send a request message for a communication session (e.g., a PDU session establishment request message) which may include, for example, one or more of the following parameters: (a) a UAV ID (e.g., hardware ID, PEI) which may contain information about a third-party service provider (e.g., a USS / UTM server), and (b) an S-NSSAI and a DNN associated with the third-party service provider (e.g., a USS / UTM DNN and S-NSSAI as described herein or obtained from the WTRU configuration). One or more of the parameters (e.g., S-NSSAI and / or DNN) may indicate to the network (e.g., SMF or AMF) that the third-party service provider is triggering UAV authentication and authorization to obtain security information used to secure communication between the WTRU and the third-party service provider.

[0107] A network (e.g., SMF) may determine the IP address of a USS / UTM based on, for example, the received UAV ID or local configuration. A network (e.g., SMF) may restrict communication (e.g., only) destined for the IP address of a third-party service provider (e.g., USS / UTM) for authentication / authorization messaging purposes (e.g., until the UAV is successfully authenticated / authorized by the third-party service provider). A WTRU may be authorized to establish other communication sessions (e.g., PDU sessions) using a different S-NSSAI / DNN for other purposes, including one or more of the following: UAV software updates, UAV configuration updates, or UAV certificate updates (e.g., based on network policy).

[0108] As shown, in section 5, a network (e.g., AMF and / or SMF) may generate or derive a UAV application master key (e.g., a new UA-MK) and / or a key identifier UA-MK-ID. The key and / or key identifier may be bound to the UAV ID and identifier of a third-party service provider (e.g., a USS / UTM domain) (e.g., cryptographically). The key may be associated with a lifetime (e.g., assigned), such as the time the key may be valid before it expires. The lifetime of the key may be determined based on network policy. The UA-MK-ID may be generated, for example, to enable USS / UTM to route requests to the appropriate network / NF (e.g., it may be constructed to include serving network / NF routing information, e.g., "random_ID@public_hostname").

[0109] The key is the network master session key (for example, K ASME , K AMF / K SEAF ) or anchor key (K AUSF It can be obtained based on ). NF (e.g., dedicated NF, e.g., authentication server function (AUSF) or BSF) can provide key bootstrapping services. Key bootstrapping services can be invoked by, for example, AMF, SMF, NEF, etc.

[0110] In some cases, the UA-MK can be generated from random numbers.

[0111] As shown, in section 6, the network (e.g., SMF) may initiate a separate session (e.g., a new application session) with a third-party service provider (e.g., USS / UTM) to enable UAV authentication (e.g., UAV authentication by UTM using network key bootstrapping). The network (e.g., SMF) may send a session establishment request message which may include, for example, the WTRU ID (e.g., a General Public Subscription Identifier (GPSI)), the UAV ID, and UAV application master key parameters (e.g., one or more of UA-MK, UA-MK-ID, and / or lifetime). The network (e.g., SMF) may include the current location of the WTRU (e.g., if available). The network (e.g., SMF) may include UAV subscription-related parameters (e.g., one or more of the approved UAV class and / or mission type, etc.) to enable UTM verification of credentials / information provided by the UAV.

[0112] As shown in 7, a third-party service provider (e.g., USS / UTM) may send a session establishment response message which may include one or more of the following: (a) GPSI and UAV IDs, (b) UTM session data (e.g., a USS / UTM-specific transaction ID (UTID), a USS / UTM fully qualified domain name (FQDN) / server IP address to which the WTRU contacts for application layer authentication and authorization procedures), and / or (c) a request (e.g., a WTRU / PDU session) informing the IP address assigned to the communication session.

[0113] As shown, in 8, the network (e.g., SMF) may send a communication session (e.g., PDU session) establishment acceptance message which may include, for example, one or more of the following parameters: (a) instructions for pending authorization by a third-party service provider (e.g., indicating that the WTRU / UAV can be authenticated / authorized by the USS / UTM so that it can use connectivity to UAS-specific operations such as C2 communication), (b) UTM session data, and (c) UAV application master key parameters (e.g., UA-MK, UA-MK-ID, lifetime). In some examples, the network (e.g., SMF) may send key material (e.g., K AMF、 K AUSF、 Nons), and / or WTRU is (e.g., K AMF、 K AUSF This may include instructions for performing key derivation (from). The network (e.g., SMF) may, for example, inform a third-party service provider of the IP address assigned to a communication session (e.g., a PDU session) if requested.

[0114] As shown, in section 9, the WTRU can perform the derivation of the UA-MK and UA-MK-ID, for example, if such instructions are received. The WTRU can perform the key bootstrap procedure using network functions (e.g., BSF) via UP (e.g., if such instructions are received).

[0115] As shown, in 10, the WTRU can initiate the procedure for authentication / authorization of the UAV by the third-party service provider via UP, for example, using an established communication session (e.g., an established PDU session) and / or the third-party service provider's IP address (e.g., obtained from UTM session data or local configuration), if it receives instructions for pending authorization from a third-party service provider. The WTRU can send a request message to the UAV (e.g., an application session request message) which may include, for example, a UA-MK-ID and / or UTID. The UA-MK-ID may be used as pseudo-identification of the UAV associated with (e.g., bound) the onboard WTRU's identification information, which may help protect the privacy of the UAV and WTRU permanent identification information.

[0116] As shown, in 11, a third-party service provider (e.g., USS / UTM) can retrieve (e.g., extract) UAV application session key parameters based on, for example, the UA-MK-ID and / or UTID. The third-party service provider can check the validity of the UA-MK (e.g., the UA-MK is valid if it has not expired based on its lifetime, and invalid if it has expired based on its lifetime).

[0117] As shown, in 12, a third-party service provider (e.g., USS / UTM) can request a new / different key (e.g., a new UAV application master key) from the network if, for example, a new / different key has not been previously received. The third-party service provider can determine the destination (e.g., a serving network / NF destination) based on routing information (e.g., routing information that may be included in the UA-MK-ID). The USS / UTM can send a request message for the key (e.g., a UAV application key request message that may include the UA-MK-ID).

[0118] As shown, in 13, the network (e.g., SMF) may send a response message (e.g., a UAV application key response message). The response message may include parameters, e.g., UAV application master key parameters (e.g., one or more of UA-MK, UA-MK-ID, or lifetime). The network (e.g., SMF) may include the current location of the WTRU (e.g., UAV takeoff location) if the WTRU's current location is available.

[0119] As shown, in 14, the WTRU can perform mutual authentication with third-party service providers (e.g., application layer mutual authentication / key agreement protocol, e.g., transport layer security pre-shared key (TLS-PSK)) using, for example, the UA-MK as a pre-shared key. The UAV application session key (e.g., used for end-to-end secure communication with USS / UTM) can be established based on mutual authentication and key agreement, for example. Successful authentication (e.g., using the UA-MK) can indicate or confirm that the WTRU onboard the UAV has a valid UAV subscription (e.g., the onboard WTRU can be authorized by the network for airborne operations).

[0120] As shown, in 15, the WTRU can perform application-layer UAV authentication and authorization with a third-party service provider (e.g., USS / UTM) using UAV provisioning credentials (e.g., using one or more of the UAV ID or UAV owner / client certificates via established secure communication). Separate authentication and / or key agreement protocols using UA-MK and / or certificates (e.g., as discussed herein) can be combined into a single authentication / key agreement protocol.

[0121] As shown, in section 16, a third-party service provider (e.g., USS / UTM) can notify the network of the results of UAV authentication and authorization. The third-party service provider may provide, for example, one or more of the following parameters, WTRU ID, UA-MK-ID, and / or authentication result / data (e.g., in the UAV authentication and authorization notification message):

[0122] As shown, in 17, the network (e.g., SMF / AMF) can update the WTRU context and / or communication session (e.g., PDU session) based on, for example, the received authorization result / data.

[0123] As shown, in 18, the network may send responses (e.g., UAV authentication and acknowledgment responses) to third-party service providers (e.g., USS / UTM).

[0124] As shown, in 19, a third-party service provider (e.g., USS / UTM) may send a response message (e.g., a UAV application session response message) to the WTRU that may contain the results of the UAV authentication / authorization procedure.

[0125] As indicated, in 20, WTRU / UAVs may be certified / authorized by a third-party service provider (e.g., USS / UTM). WTRUs may perform additional certification and authorization procedures for UAS services (e.g., discovery / pairing with UAV-C and / or C2 communications).

[0126] In one example, a WTRU can perform application layer authentication and authorization using EAP (e.g., EAP-TLS-PSK) with a protocol for carrying authentication for network access (PANA). The WTRU can function as a PANA client (PAC) / EAP peer, and the SMF can function as a PANA authentication agent (PAA) / EAP authenticator, reachable by the WTRU via a UPF that can function as an enforcement point (EP), and by a USS / UTM that can function as an AAA server. The PAA's IP address may be provided to the WTRU, for example, in a PDU session acceptance message, or via the user plane during IP address configuration (e.g., DHCP). In one example, the WTRU may not communicate directly with the USS / UTM (e.g., the AAA server). The WTRU can exchange EAP messages with the PAA (e.g., SMF) via IP (PANA), and the PAA can exchange authentication and authorization messages (e.g., using DIAMETER) with the AAA (e.g., USS / UTM). EAP / PANA authentication / authorization can be successfully completed. For the WTRU to communicate securely with the USS / UTM, a session key (e.g., MSK) may be established with the AAA (e.g., via the PAA).

[0127] UAV authentication and authorization by UTM can be performed, for example, using a UTM authorization token.

[0128] Figure 5 illustrates exemplary interactions and / or messaging for UAV authentication and authorization by a third-party service provider using security information such as a token (e.g., a UTM authorization token). The example shown in Figure 5 illustrates a call flow for UAV authentication and authorization by a third-party service provider using a token (e.g., a UTM authorization token). The third-party service provider may be a provider of UTM. The third-party service provider may include a USS.

[0129] WTRUs can, for example, use control plane signaling with the network (e.g., PDU session establishment procedures) to obtain security information (e.g., UTM authorization tokens) from third-party service providers (e.g., USS / UTM).

[0130] A WTRU can establish a connection to a third-party service provider for communication with that service provider. As shown in Figure 5, the connection may be between the third-party service provider and the WTRU. The WTRU can use security information (e.g., a UTM authorization token) to perform bound UAV / WTRU authentication / authorization by the third-party service provider (e.g., one or more of the dotted rectangular areas 9-14 in Figure 5).

[0131] As shown in Figure 5, in scenario 1, a WTRU (e.g., a UAV) can register with the network. As shown in Figure 5, a WTRU may send a registration request to the network. In a registration request, the WTRU may provide one or more of the following parameters: UAV capabilities (e.g., one or more of the following, including direct stick steering, automated flight by UTM, e.g., UAV class / weight, beyond visual line of sight (BVLOS) flight capability, supported control modes), UAV slice information (e.g., a specific slice / service type (SST) value, such as the value "UAS", e.g., UAV-specific slice information such as S-NSSAI), instructions to request third-party service provider data network name (DNN) information (e.g., USS / UTM DNN information), a subscription identifier (e.g., IMS or SUPI), and / or configuration information (e.g., UAV ID).

[0132] As shown, in section 2, the network (e.g., AMF) may check and / or determine that the subscription for UAV operations is approved based on subscription information associated with the WTRU (e.g., from the WTRU subscription). The network (e.g., AMF) may determine that additional UAV certification / approval (e.g., UAV certification / approval by USS / UTM) is performed or required.

[0133] As shown, in section 3, the network (e.g., AMF) can send a registration acceptance message to the WTRU. The message may include, for example, one or more of the following parameters: (a) S-NSSAI (e.g., S-NSSAI specific to UAV operations in authorized NSSAI), and / or (b) a DNN associated with a third-party service provider (e.g., a dedicated USS / UTM DNN that may be used by the WTRU to establish authentication / authorization and / or connectivity with USS / UTM).

[0134] As shown, in 4, the WTRU may send a request message for a communication session (e.g., a PDU session establishment request message) which may include, for example, one or more of the following parameters: (a) a UAV ID (e.g., hardware ID, PEI) which may contain information about a third-party service provider (e.g., a USS / UTM server), and (b) an S-NSSAI and a DNN associated with the third-party service provider (e.g., a USS / UTM DNN and S-NSSAI as described herein or obtained from the WTRU configuration). One or more of the parameters (e.g., S-NSSAI and / or DNN) may indicate to the network (e.g., SMF or AMF) that the third-party service provider is triggering UAV authentication and authorization to obtain security information used to secure communication between the WTRU and the third-party service provider.

[0135] As shown, in 5, the network (e.g., SMF) may initiate a session with a third-party service provider (e.g., initiating a new session with USS / UTM) to enable authentication of the UAV by UTM using security information (e.g., UTM token) via UP. The network (e.g., SMF) may send a request message for a communication session (e.g., a session establishment request message) to the third-party service provider which may include, for example, a WTRU ID (e.g., a subscription ID such as GPSI) and / or a UAV ID.

[0136] As shown, in section 6, a third-party service provider (e.g., USS / UTM) may generate security information (e.g., a protected authorization token that can be signed and / or encrypted using a JSON web token (JWT) or JSON web encryption (JWE)). The security information may be signed by the third-party service provider (e.g., including the third-party service provider's signature information). The security information may include (e.g., cryptographically bound) a lifetime, e.g., GPSI, UAV ID, third-party service provider ID, and / or lifetime. The lifetime may include a lifetime associated with the security information.

[0137] As shown, in 7, a third-party service provider (e.g., USS / UTM) may send a communication session response message (e.g., a session establishment response message) which may include security information (e.g., a UTM authorization token) that indicates authorization for the connection to the third-party service provider and binds the GPSI, UAV ID, and the identity of the third-party service provider. The message may include, for example, a request for UTM session data and a WTRU IP address (e.g., as described above).

[0138] As shown, in 8, the network (e.g., SMF) can send a response message for a communication session (e.g., a PDU session establishment acceptance message). The response message may include, for example, one or more of the following parameters: (i) instructions for pending authorization by a third-party service provider (e.g., UTM) and / or data (e.g., UTM session data as described above), and / or (ii) security information (e.g., a UTM authorization token) that may indicate authorization for connection to the third-party service provider. The network (e.g., SMF) may, for example, notify the third-party service provider (e.g., USS / UTM) of the IP address assigned to the communication session (e.g., a PDU session) when the IP address assigned to the communication session is requested.

[0139] As shown in Figures 59-14, the WTRU can establish a connection with a third-party service provider (e.g., USS / UTM) based on the security information received for communication with the third-party service provider (e.g., secure communication). As shown in Figure 5, in step 9, the WTRU can use, for example, the established communication session (e.g., established PDU session) and the third-party service provider's IP address (e.g., from UTM session data or local configuration) to initiate authentication / authorization of the UAV by the third-party service provider (e.g., the procedure for authentication / authorization of the UAV by USS / UTM via UP).

[0140] A WTRU can perform mutual authentication with a third-party service provider (e.g., USS / UTM) by presenting certificates (e.g., UAV owner certificate, SSL client certificate) to the third-party service provider. A WTRU can establish a connection to the third-party service provider for communication with it. The WTRU and the third-party service provider can exchange multiple application layer messages (e.g., during an SSL handshake) to establish a secure connection, for example, via HTTP transport.

[0141] The WTRU (for example, during exchange) may provide one or more of the following parameters: UAV ID, UAV credentials (e.g., owner certificate), security information (e.g., UTM authorization token), UAV takeoff weight, mission type, etc. For example, as shown in Figure 5, in 9, the WTRU may send security information (e.g., UTM authorization token) to a third-party service provider in a request message for a UAV application session. Some parameters (e.g., WTRU / UAV identifier and / or UTM authorization token) may be sent after a secure connection is established, for example, to maintain the integrity and confidentiality of the parameters (e.g., for UAV privacy protection, independent of radio layer protection of user data).

[0142] As shown, in 10, a third-party service provider (e.g., USS / UTM) can authenticate a UAV and / or evaluate the validity of security information (e.g., UTM authorization token). Based on the authentication of the UAV and / or evaluation of the validity of the security information, the third-party service provider can determine or confirm that the onboard WTRU has a UAV subscription (e.g., confirm that the onboard WTRU is authorized by the network for airborne operations).

[0143] As shown, in 11, a third-party service provider (e.g., USS / UTM) may notify the network of the results of the UAV authentication and authorization procedure by providing, for example, one or more of the following parameters, WTRU ID, UAV ID, and / or authentication result / data in a UAV authentication and authorization notification message. As shown, in 12, the network (e.g., SMF / AMF) may update the WTRU context and / or communication session (e.g., PDU session) based on the received authorization result / data. In 13, the network may send a UAV authentication and authorization acknowledgment response to the third-party service provider. In 14, the USS / UTM may send a response message for the UAV application session to the WTRU, which may include the results of the UAV authentication / authorization procedure. The response message may include, for example, a different token (e.g., a new authorization token) and an address (e.g., a URL) that can be used to authenticate and authorize the USS / UTM service. As shown, in section 15, the WTRU may perform additional authentication and authorization procedures for UAS services (e.g., discovery of UAV-C and / or C2 communications / pairing with UAV-C and / or C2 communications). The WTRU / UAV may be authenticated / authorized by a third-party service provider (e.g., USS / UTM).

[0144] Authentication and authorization procedures may be performed for UAV / UAV-C discovery and association, as well as C2 communication.

[0145] Figure 6 illustrates exemplary interactions and messaging for UAV authorization by a third-party service provider (e.g., USS / UTM) for additional services (e.g., UTM services). The example shown in Figure 6 illustrates one or more UP-based procedures for additional UTM services, such as UAV-C discovery / association and flight operation authorization.

[0146] The exemplary operation shown in Figure 6 (e.g., exemplary call flow steps) may be invoked, for example, after successful authentication and authorization of the UAV by the USS / UTM (e.g., as shown in one or more examples herein). For example, if the operational state of the UAV is acceptable (e.g., acceptable UAV battery level, latest software, configuration, and maps are installed, etc.), the application layer on the UAV may trigger the next step. The step may be performed, for example, using the same secure application layer session (e.g., the same HTTP session) or a different session, for example, after re-authentication (e.g., using bootstrap key material as described in one or more examples herein). The UAV may be controlled by a UAV-C which can be connected via a system (e.g., via a 3GPP system such as E-UTRAN, NG-RAN, WLAN, or other connectivity).

[0147] As shown in Figure 6, in case 0, the UAV and UAV-C are successfully authenticated / authorized (e.g., by USS / UTM). In case 1, the WTRU can perform the authentication / authorization procedure for pairing the UAV and UAV-C by USS / UTM (e.g., using application layer messages) via the user plane.

[0148] As shown, in 1a, the WTRU may send an authentication / authorization message to the USS / UTM. The message may indicate the discovery of a specific or potential UAV-C or a request for pairing / association with a UAV-C. The message from the WTRU may include matching / filtering information for the desired UAV-C. The matching information may include, for example, one or more of the following elements: (i) a specific UAV-C ID (e.g., hardware ID and / or UAV-C IP address), (ii) UAV pilot identification information and / or UAV operator identification information, and (iii) a wildcard element (e.g., empty UAV-C information) to enable association with a UAV-C authorized to be paired with a UAV (e.g., presenting the same ownership certificate and / or authorizing pairing with any UAV-C that requested a specific UAV).

[0149] As shown, in 1b, the USS / UTM can authorize / enable pairing of a UAV and a UAV-C based on the provided UAV-C matching information. The USS / UTM can, for example, search for an active UAV-C session data record that is (i) available for pairing and (ii) matches the UAV pairing criteria. If the USS / UTM finds a UAV-C session data record, it can assign a UAS ID (e.g., a new UAS ID to associate the UAV with the UAV-C). The USS / UTM can store the UAS ID (e.g., the new UAS ID) in the session data of the UAV and the session data of the UAV-C, for example. The USS / UTM can concatenate the UAV and UAV-C session data records together.

[0150] As shown, in 1c, the USS / UTM can send an authentication / authorization notification message to the SMF. The message may indicate the result of discovery / pairing. The message may include, for example, the WTRU ID, UAV ID, and UAS information if the UAV-C has been discovered / paired. The UAS information may include, for example, one or more of the UAS ID, UAV-CID, and / or UAV-C IP address.

[0151] As shown, in 1d, the SMF can update the WTRU authentication data using UAV pairing acknowledgment data from the USS / UTM. As shown, in 1e, the SMF can send an acknowledgment back to the USS / UTM. As shown, in 1f, the USS / UTM can send authentication / acknowledgment for the discovery / pairing result to the WTRU, for example, via the user plane (including, for example, UAS information if available).

[0152] As shown, in 2, the UAV-C can perform authentication / authorization procedures (e.g., flight / operation of the UAS) via the user plane by the USS / UTM (e.g., using application layer messages).

[0153] As shown, in 2a-2b, the USS / UTM can authenticate / authorize the UAV-C for flight operations based on, for example, UAV-C provided data (e.g., flight plan, pilot credentials, etc.). As shown, in 2c, the USS / UTM can provide the SMF with the result of authorization for the UAV to perform UAS operations. The SMF can update the WTRU authentication data with the UAS operation authorization data from the USS / UTM (e.g., to enable communication with the UAV-C provided IP address). In 2d, the SMF can trigger a PDU session modification procedure. As shown, in 2e, the SMF can send an acknowledgment back to the USS / UTM. In 2f, the USS / UTM can send the authentication / authorization result for discovery / pairing to the UAV-C, for example, via the user plane (including UAS information if available).

[0154] As shown, in 3, the USS / UTM may transmit certification / authorization of UAS flight / operation to the WTRU, for example, via the user plane (including, for example, UAS information if available). As shown, in 4, a UAV may be authorized to communicate with the UAV-C and / or UTM regarding UAS flight / operation.

[0155] UAV re-authentication, authorization invalidation, and authentication / authorization failure processing may be performed.

[0156] Figure 7 illustrates exemplary interactions and messaging for UAV authorization by a third-party service provider (e.g., USS / UTM) with failure handling for expired or invalid keys. Figure 7 shows exemplary scenarios in which UAV authentication and authorization by UTM fails (e.g., when bootstrap key material is invalid or expired, or when UTM is unable to obtain new or different bootstrap key material from the network).

[0157] As shown in Figure 7, in case 0, the WTRU is registered as UAV-enabled and can receive authorization for network access, and for example, can receive authorization for air operations based on UAV subscription authorization.

[0158] As shown, in steps 1-5, the WTRU may establish key material (e.g., key or key ID) derived from 3GPP credentials for use in communication with a third-party service provider (e.g., USS / UTM) during NAS procedures and / or via UP (e.g., as described in one or more examples herein). In step 6, the WTRU may send a request message (e.g., a new application session request message) to the third-party service provider (e.g., including the key ID). In step 7, the third-party service provider may detect that the corresponding key is invalid or expired, or that the third-party service provider is unable to obtain a different key (e.g., a new key) from the network. In step 8, the WTRU may receive a response message indicating failure (e.g., an application session response message). In step 9, the WTRU may establish different key material (e.g., new key material such as key', key ID') derived from 3GPP credentials. The WTRU may perform procedures similar to those shown in steps 1-5. Previously allocated network resources (e.g., PDU sessions) may be released or reused during this procedure. In 10, the WTRU can successfully establish different application sessions (e.g., a new application session with the UTM) using different key materials (e.g., key ', key ID'). The network may be notified of the successful result (e.g., by the UTM). In 11, the UAV may be authenticated and authorized by a third-party service provider.

[0159] Figure 8 illustrates exemplary interactions and messaging for UAV authorization by a third-party service provider (e.g., USS / UTM) with failure handling for expired or invalid certificates. Figure 8 shows an exemplary scenario in which UAV authentication and authorization by a third-party service provider fails (e.g., because the UAV certificate is invalid or expired).

[0160] As shown in Figure 8, in case 0, the WTRU is registered as UAV-enabled and can receive authorization for network access (e.g., normal network access) based on, for example, UAV subscription authorization.

[0161] As shown, in 1, the WTRU can establish key material (e.g., key, key ID) derived from 3GPP credentials for use in communication with a third-party service provider (e.g., during NAS procedures as described in one or more examples herein). As shown, in 2, the WTRU can send an application session request message to the third-party service provider (e.g., including the key ID). In 3, the third-party service provider can evaluate whether the corresponding key is valid. As shown, in 4, the WTRU can perform mutual authentication with the third-party service provider (e.g., using the key). As shown, in 5, the WTRU can initiate UAV authentication by sending UAV credentials (e.g., client certificate for SSL exchange). As shown, in 6, the third-party service provider can detect that the UAV credentials are invalid / expired. The WTRU can receive an appropriate authentication failure message. In 7, the WTRU can receive an application session response message indicating failure. In 8, the third-party service provider can send an authentication / authorization notification failure message to the network. The message may include, for example, the WTRU ID and key ID. As shown, in 9, the network may perform or initiate a procedure to release network resources used for connecting with the third-party service provider. As shown, in 10, the network may confirm receipt of an authentication failure from the third-party service provider. In 11, the UAV may not be authorized for airborne operation by the network / third-party service provider. The UAV may be authorized for airborne operation (for example, subsequently) by successfully completing a procedure with valid UAV credentials (for example, after updating such credentials).

[0162] Methods, processes, apparatus, media for storing instructions, media for storing data, or signals may be described herein by one or more of the following: transmitting a UAV ID to a network; receiving security information from the network indicating authorization for a connection to a third-party service provider; establishing a connection to the third-party service provider for communication with the third-party service provider based on the security information, wherein the security information includes the third-party service provider's signature information and the security information includes at least one of the following: a subscription ID associated with the UAV, a UAV ID, or the third-party service provider's ID; transmitting a UAV ID to a network in a request message for a communication session; receiving security information in a response message for a communication session; establishing a connection to the third-party service provider via a communication session, wherein the security information includes a token, the token binds the UAV ID, GPSI, and the third-party service provider's ID and includes signature information associated with the third-party service provider; and sending an application layer message to the third-party service provider to establish a connection to the third-party service provider using the security information.

[0163] Methods, processes, apparatus, media for storing instructions, media for storing data, or signals include, but are not limited to, receiving a registration request from a WTRU, determining the WTRU's subscription to the operation of a UAV based on the registration request, transmitting a subscription identifier associated with the WTRU to a third-party service provider, receiving security information from the third-party service provider indicating authorization of the connection between the WTRU and the third-party service provider, transmitting security information to the WTRU, wherein the security information includes at least one of the following: the third-party service provider's signature information, the subscription ID associated with the WTRU, the UAV ID associated with the WTRU, or the ID of the third-party service provider, receiving the UAV ID associated with the WTRU from the WTRU in a request message for a communication session, and transmitting security information in a response message for a communication session, wherein the security information includes a token, the token binds the UAV ID associated with the WTRU, GPSI, and the ID of the third-party service provider, and the security information includes signature information associated with the third-party service provider, and the security information includes the UAV ID associated with the WTRU This may be described herein in accordance with one or more of the following: the third-party service provider provides unmanned aerial system (UAS) traffic management, the third-party service provider includes unmanned aerial system (UAS) service suppliers, and the third-party service provider transmits, including a fully qualified domain name (FQDN).

[0164] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transceiver unit (WTRU) associated with a UAV (unmanned aerial vehicle), wherein the WTRU is Includes a processor, the processor is Sending a protocol data unit (PDU) session establishment request message containing a UAV identifier (ID) to a first network function, wherein the UAV ID identifies the UAV, The first network function receives a PDU session establishment acceptance message, the PDU session establishment acceptance message includes UAV (unmanned aerial vehicle) authentication and approval information. Based on the aforementioned UAV authentication and authorization information, establish connection security between the WTRU and the second network entity, WTRU is configured to execute.

2. The WTRU of claim 1, wherein the UAV authentication and authorization information includes UUAA (unmanned aerial system service supplier (USS) authentication and authorization) information associated with the UAV.

3. The WTRU according to claim 1, wherein the UAV authentication and approval information includes identification information associated with the UAV.

4. The WTRU of claim 3, wherein the identification information associated with the UAV includes the UAV ID.

5. The WTRU according to claim 1, wherein the first network function is a session management function (SMF).

6. The WTRU according to claim 1, wherein the PDU session establishment request message includes an indication that the request is for an unmanned aerial system (UAS) service.

7. The WTRU of claim 6, wherein the PDU session establishment acceptance message indicates a response associated with a request to the UAS service.

8. The WTRU according to claim 1, wherein the processor is configured to establish a PDU communication session based on the establishment of UAV authentication and authorization associated with the WTRU.

9. The WTRU according to claim 1, wherein the second network entity provides UAS traffic management.

10. The WTRU of claim 1, wherein the second network entity includes a USS.

11. A method performed by a wireless transceiver unit (WTRU) associated with a UAV (unmanned aerial vehicle), Sending a protocol data unit (PDU) session establishment request message containing a UAV identifier (ID) to a first network function, wherein the UAV ID identifies the UAV, The first network function receives a PDU session establishment acceptance message, the PDU session establishment acceptance message includes UAV (unmanned aerial vehicle) authentication and approval information. Based on the aforementioned UAV authentication and authorization information, establish connection security between the WTRU and the second network entity, A method that includes this.

12. The method of claim 11, wherein the UAV authentication and authorization information includes UUAA (unmanned aerial system service supplier (USS) authentication and authorization) information associated with the UAV.

13. The method of claim 11, wherein the UAV authentication and authorization information includes identification information associated with the UAV.

14. The method of claim 13, wherein the identification information associated with the UAV includes the UAV ID.

15. The method of claim 11, wherein the first network function is a session management function (SMF).

Images