Methods and apparatus for unmanned aircraft system (UAS) identification, binding, and pairing

Abstract

Methods and apparatus for pairing an unmanned aerial vehicle (UAV) with a UAV controller (UAV-C) are described. For example, a UAV having a UAV wireless transmit / receive unit (UAV WTRU) can send a non-access stratum (NAS) request message to an access and mobility management function (AMF), the request message including a pairing request indication and a UAV controller (UAV-C) identification (UAV-C ID). The UAV-C ID can be carried in a pairing request sent to a drone system (UAS) service supplier (USS) / UAS traffic management (UTM) for pairing authorization of the UAV and the UAV-C associated with the UAV-C ID. The UAV can receive a NAS response message from the AMF including a drone system (UAS) identification (UAS ID) indicating that the UAV is paired with the UAV-C, where the UAS ID is specified by the USS / UTM.

Description

[0001] This application is a divisional application of Chinese Invention Patent Application No. 202080066075.3, filed on August 21, 2020, entitled “Methods and Apparatus for Unmanned Aircraft System (UAS) Identification, Binding, and Pairing,” which claims the benefit of U.S. Provisional Application No. 62 / 890,920, filed on August 23, 2019, the contents of which are incorporated by reference herein.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 890,920, filed on August 23, 2019, the contents of which are incorporated by reference herein. BACKGROUND

[0004] The number of unmanned aerial vehicles (UAVs) has grown rapidly in recent years, and applications enabled by UAVs are expanding into a variety of industries. However, today’s unmanned aircraft systems (UASs) (e.g., UAVs and UAV controllers) primarily rely on direct point-to-point communication via the unlicensed industrial, scientific, and medical (ISM) band, which limits the range of operations and the communication is often unreliable, insecure, and low data rate. To fully exploit the potential of UAV applications, cellular technologies such as long term evolution (LTE) and 5G can be leveraged to enable beyond visual line of sight (BVLOS) operations and high performance and reliable communication for UASs. For example, while performing their tasks, UASs connected to a cellular network can involve various types of cellular communications, such as UAS-to-UAS traffic management (UTM) communications, non-payload communications, and / or payload communications. Therefore, to enable such communications in a cellular network, methods and apparatuses are needed to identify, bind, pair, and / or authenticate UASs in a cellular network. SUMMARY

[0005] Methods and apparatuses for pairing an unmanned aerial vehicle (UAV) with a UAV controller (UAV-C) are described herein. For example, a UAV having a UAV wireless transmit / receive unit (UAV WTRU) for cellular communication can send a non-access stratum (NAS) request message to an access and mobility management function (AMF), the request message including a pairing request indication and a UAV controller (UAV-C) identification (UAV-C ID). The UAV-C ID can be carried in a pairing request sent to a drone system (UAS) service supplier (USS) / UAS traffic management (UTM) for pairing authorization of the UAV and the UAV-C associated with the UAV-C ID. The pairing request sent to the USS / UTM for pairing authorization of the UAV and the UAV-C can include the UAV ID and the UAV-C ID. The UAV can receive a NAS response message from the AMF including a drone system (UAS) identification (UAS ID) indicating that the UAV is paired with the UAV-C, where the UAS ID is specified by the USS / UTM. The NAS request message can be a protocol data unit (PDU) session request message and the NAS response message can be a PDU session response message. BRIEF DESCRIPTION OF DRAWINGS

[0006] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein like reference numerals indicate like parts and wherein:

[0007] Figure 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0008] Figure 1B is a system diagram illustrating an example wireless access network (RAN) and an example core network (CN) that can be used within the communications system Figure 1A illustrated in FIG. 1;

[0009] Figure 1C is a system diagram illustrating an example RAN and an example CN that can be used within the communications system Figure 1A illustrated in FIG. 1;

[0010] Figure 1D is a system diagram illustrating another example RAN and another example CN that can be used within the communications system Figure 1A illustrated in FIG. 1;

[0011] Figure 2 is a diagram illustrating an example architecture for supporting drone systems (UAS) for 5G networks;

[0012] Figure 3 is a schematic diagram illustrating an exemplary type of unmanned aerial vehicle (UAV) communication enabled through a cellular network;

[0013] Figure 4 is a schematic diagram illustrating an exemplary UAS interaction with a network and UAS traffic management (UTM) for authorization;

[0014] Figure 5A is a schematic diagram illustrating an exemplary UAS pairing and authorization scenario with a UAV coming online;

[0015] Figure 5B is a schematic diagram illustrating an exemplary UAS pairing and authorization scenario with a UAV-C coming online;

[0016] Figure 5C is a schematic diagram illustrating an exemplary UAS pairing and authorization scenario with a UAV and UAV-C establishing communication;

[0017] Figure 6 is a schematic diagram illustrating an exemplary procedure for UAV controller (UAV-C) assisted UAS pairing;

[0018] Figure 7 is a schematic diagram illustrating an exemplary procedure for subscription-based (bulk) pairing and authorization;

[0019] Figure 8 is a schematic diagram illustrating an exemplary procedure for UAV-C change;

[0020] Figure 9 is a schematic diagram illustrating an exemplary procedure for UAS multi-level authorization driven by 3GPP systems;

[0021] Figure 10 is a schematic diagram illustrating another exemplary procedure for UAS multi-level authorization driven by 3GPP systems;

[0022] Figure 11A is a schematic diagram illustrating an exemplary procedure for multi-level authorization across multiple UTM and / or UAS service suppliers (USS);

[0023] Figure 11B is a schematic diagram illustrating an exemplary procedure for multi-level authorization across multiple UTM and / or UAS service suppliers (USS); Figure 11A ;

[0024] Figure 12A is a schematic diagram illustrating an exemplary procedure for identification, binding, pairing, and authorization on a public land mobile network (PLMN);

[0025] Figure 12B is a schematic diagram illustrating an exemplary procedure for identification, binding, pairing, and authorization on a public land mobile network (PLMN); Figure 12A ; and

[0026] Figure 13FIG. 1 is an illustration of an example process for binding and pairing between a UAV and a UAV-C. DETAILED DESCRIPTION

[0027] Figure 1A is a schematic diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can 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 discrete Fourier transform spread orthogonal frequency division multiplexing (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0028] As Figure 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a station (STA)), can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, unmanned aerial vehicle (UAV), UAV WTRU, UAV UE, unmanned aerial vehicle controller (UAV-C), UAV-C WTRU, UAV-C UE, 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 an automated processing chain environments), consumer electronics, devices operating on a business and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0029] The communication system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0030] The base stations 114a can be part of a RAN 104 that also can include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies. These frequencies can be licensed or unlicensed frequencies. The base stations 114a and / or 114b can be communicatively coupled to one another, for example, via an X2 or other suitable interface.

[0031] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0032] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.

[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

[0037] Figure 1AThe base station 114b in the embodiment can be, for example, a wireless router, Home Node B, Home eNode B, or access point, and can utilize any suitable RAT for facilitating wireless connectivity access by the WTRUs 102c, 102d within a local area. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106. Figure 1A

[0038] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, the CN 106 can be in direct or indirect communication with other Figure 1A RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ NR radio technology, the CN 106 can also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0039] ​The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony. The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 or a different RAT.

[0040] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, Figure 1A The WTRU 102c shown in Figure 1A can be configured to communicate with the base station 114a using a cellular-based radio technology and can be configured to communicate with the base station 114b using an IEEE 802 radio technology.

[0041] Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B The WTRU 102 can include 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0042] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs), any other type of integrated circuit (IC), a state machine, and / or the like. The processor 118 can 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 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. WhileFigure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0044] Although the transmit / receive element 122 is depicted in the WTRU 102 as a single element, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116. Figure 1B

[0045] The transceiver 120 can be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As indicated above, the WTRU 102 can be a multi-mode device. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0046] ​The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can 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 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0048] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0049] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® The peripheral device 138 can include one or more sensors. The sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0050] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference and / or cross- interference by utilizing hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0051] Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116 and can include eNode-Bs 160a, 160b, 160c, although

[0052] The RAN 104 can include eNode-Bs 160a, 160b, 160c, although it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0053] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. Figure 1C

[0054] Figure 1C The CN 106 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0055] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activations / deactivations, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0056] The SGW 164 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0057] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0058] ​CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 110 through the UPF 106a. In another embodiment, the WTRUs 102a, 102b, 102c can be connected to the DN 110 through the UPF 106a and the UPF 106b.

[0059] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such a terminal can (e.g., temporarily or permanently) use a wired communication interface with the communication network.

[0060] In representative embodiments, the other network 112 can be a WLAN.

[0061] A WLAN in Infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that is carried by the DS can be transmitted from the AP. Traffic from STAs that is carried by the DS can be transmitted to the AP. The AP can transmit traffic to the DS and can receive traffic from the DS. The AP can also transmit and receive traffic directly to and from STAs. The AP can coordinate scheduling of wireless distribution of traffic. The AP can also function as a base station of the WLAN.

[0062] When using an 802.11 ac infrastructure mode of operation or similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, a STA (e.g., each STA), including the AP, can listen to the primary channel. If the primary channel is sensed / detected as busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.

[0063] High Throughput (HT) STAs can use 40 MHz wide channels to communicate, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0064] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed by a segment parser that can divide the data into two streams. Each stream can be independently subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0065] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.1 lac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC) such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems that can support multiple channels and channel bandwidths such as 802.11η, 802.1 lac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or limited by a STA from all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, for a STA (e.g., MTC type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide 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 can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (only supporting a 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy even if most of the available frequency band remains idle.

[0067] In the United States, the available frequency bands for 802.11ah to use are 902 MHz to 928 MHz. In Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available to 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0068] Figure 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

[0069] The RAN 104 can include gNBs 180a, 180b, 180c, although the RAN 104 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0070] The WTRUs 102a, 102b, 102c can use transmission associated with scalable numerology to communicate with gNBs 180a, 180b, 180c. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary from different transmissions, from different cells, and / or from different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can use subframe or transmission time interval (TTI) of various or scalable lengths (e.g., containing different quantities of OFDM symbols and / or lasting varying lengths of absolute time) to communicate with gNBs 180a, 180b, 180c.

[0071] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with one or more of gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use signals

[0072] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As Figure 1D As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface.

[0073] Figure 1DThe illustrated CN 106 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0074] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface, and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the WTRU 102a, 102b, 102c registration area, terminating a Non-Access Stratum (NAS) signaling, and / or the like. The AMF 182a, 182b can utilize network slicing in order to customize CN support for WTRUs 102a, 102b, 102c based on the type of services utilized by a WTRU 102a, 102b, 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, and / or the like. The AMF 182a, 182b can provide control plane functionality for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE- A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0075] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and / or the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and / or the like.

[0076] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which can provide WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0077] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a DN 185a, 185b through the UPF 184a, 184b via the N3 interface between the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0078] In view of Figures 1A-1D And Figures 1A-1D In view of the corresponding description of the above, one or more or all of the functions described herein with reference to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or to simulate network and / or WTRU functionality.

[0079] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0080] The one or more emulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The 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 devices to transmit and / or receive data.

[0081] The number of unmanned aerial vehicles (UAVs) has grown rapidly in recent years, and applications enabled by UAVs are expanding into a variety of industries. However, current unmanned aerial systems (UAS) (e.g., UAVs and UAV controllers) primarily rely on direct point-to-point communication via unlicensed industrial, scientific, and medical (ISM) frequency bands, which limits the range of operations and is often unreliable, insecure, and has low data rates. To fully realize the potential of UAV applications, advanced cellular technologies such as LTE and 5G can be used to enable beyond-visual-range (BVLOS) flight operations and high-performance, reliable communication for UAVs.

[0082] The benefits of using cellular networks are obvious. For example, ubiquitous mobile network coverage provides operational range far exceeding the limitations of point-to-point communication using ISM frequencies. The advanced communication capabilities of modern cellular networks (especially 5G networks), such as high bandwidth, low latency, and guaranteed QoS, greatly improve the performance of UAV applications. The advanced security mechanisms of modern cellular networks can address serious security issues involved in managing UAV applications.

[0083] Figure 2 An exemplary architecture 200 for supporting unmanned aerial systems (UAS) in 5G networks is shown, which can be used in conjunction with any other implementation described herein. Figure 2As shown, UAS Traffic Management (UTM) 210 can be a framework for UAS traffic management. The roles and responsibilities of UTM 210, as well as the procedures and protocols applied in UTM 210, may differ between countries. UTM 210 can refer to a set of functions used for authenticating UAVs, authorizing UAS services, managing UAS policies, and controlling UAV traffic in airspace. For example, UTM can be a server that implements such functions for UAVs, UAV-C, and / or UAS. Authorized users or UTM clients 220 can query the identity and metadata of UAVs 202a to 202e and their UAV controllers 203a and 203b via UTM 210. UTM 210 can store data required for operating the UAS. Air traffic control agents can use UTM server 210 to authorize, execute, and / or regulate UAS operations.

[0084] like Figure 2 As shown, the 5G core network 206 may include PCF 281a, SMF 282a, SMF 283a, UPF 284a, 284b, NEF 285a, etc. Figure 2In the illustrated architecture, UASs (e.g., UAVs 202a-202e and / or UAV-C 203a, 203b) can communicate with UTM 210 via a network user plane for identification, authentication, and authorization procedures, and also for other command and control message / data exchanges. 3GPP network functions (such as SMF 283a, PCF 281a, etc.) can also have direct or indirect (e.g., via a network exposure function (NEF 285a)) control interfaces with UTM 210. A UAV can include a WTRU or UAV WTRU for cellular network communication (e.g., 3GPP, 5G, 6G, etc.). In this regard, a WTRU or UAV WTRU can refer to an embedded communication device (e.g., a 3GPP modem / module / chipset capable of 3GPP communication) that enables a UAV to communicate over a cellular network. A WTRU or UAV WTRU can include a SIM or USIM in a device that is subscribed for cellular communication. The terms WTRU, UE, UAV WTRU, UAV UE, WTRU on a UAV, and UE on a UAV can be used interchangeably in this disclosure. Similarly to a UAV, a UAV-C can include a WTRU or UAV-C WTRU for cellular network communication (e.g., 3GPP, 5G, 6G, etc.). In this regard, a WTRU or UAV-C WTRU can refer to an embedded communication device (e.g., a 3GPP module capable of 3GPP communication) that enables a UAV-C to communicate over a cellular network. The terms WTRU, UE, UAV-C WTRU, UAV-C UE, WTRU on a UAV-C, and UE on a UAV-C can be used interchangeably in this disclosure. A UAV WTRU or UAV-C WTRU can include a SIM or USIM in an embedded communication device that is subscribed for cellular communication.

[0085] Example communications for UASs are described herein. Figure 3 An example type of unmanned aerial vehicle (UAV) communication enabled over a cellular network 300 is illustrated, which can be used in conjunction with any other embodiment described herein. As Figure 3 As illustrated, a cellular network connected UAS (e.g., UAV 302 and / or UAV-C 303) can involve various types of cellular communication for performing its tasks: UAS-UTM communication, non-payload communication (i.e., command and control), and payload communication.

[0086] UAS-UTM communication can refer to communication between the UAS and the UTM. Enabling UAS-UTM communication may be necessary for purposes such as identification, authorization, command and control, and law enforcement activities. It can be assumed that a user plane connection is used between the UAS and the UTM, although control plane communication can also be used between the two. UAS can refer to UAV and / or a combination of UAV and UAV-C.

[0087] Non-payload communications may include command and control (C&C or C2) communications. Command and control messages, as well as data exchange, are critical for UAV mission and safety considerations. Some C&C exchanges (e.g., location or flight data reports) may occur between the UAV and the UTM, and between the UAV and its UAV-C. C2 communication may be performed between the UAV and UAV-C based on a PDU session established using a cellular network (e.g., 5G).

[0088] Exemplary types of C&C or C2 communication may include, but are not limited to, those disclosed in Table 1 below:

[0089] Table 1.

[0090]

[0091]

[0092]

[0093] For payload communication, the UAV in the mission can send payload data, such as real-time video or sensor data, to its UAV-C or some application server or storage in the network. Payload communication can typically be heavy in the uplink and light in the downlink.

[0094] 3GPP has identified the use cases and potential requirements for UAS support in its 3GPP specifications. Specifically, the requirements for remote identification and authorization of UAS have been specified in the 3GPP specifications. Additional enhancements to UAS support in 3GPP may include: UAS command and control (C2) communication; unmanned aerial vehicle (UAV) navigation via UAV controller (UAV-C) or via UAS traffic management (UTM); and / or changes to UAV-C during flight missions.

[0095] Figure 4 An exemplary UAS interaction 400 with the network and UAS traffic management (UTM) for authorization is shown, which can be used in conjunction with any other implementation described herein. Figure 4As shown, the UAS 401 can refer to a combination of the UAV 402 (e.g., drone) and the UAV-C 403, and the network can include the RAN 404a, 404b and the CN 406a, 406b. The 3GPP system (e.g., RAN 404a, 404b and CN 406a, 406b) can provide communication capabilities between the UAV 402 and the UAV-C 403, which can communicate through the same or different RAN nodes (e.g., 404a, 404b) and include communication via different PLMNs. The UTM 410 can provide UAS identification and tracking, authorization, enforcement, and regulation of UAS operations, and also store data required for operating the UAS.

[0096] In one embodiment, the UAV and the UAV-C can be paired and identified as a UAS by the 3GPP system and / or the UTM. Specifically, the network can be responsible for the attestation of the WTRU (e.g., UAV WTRU or UAV-C WTRU) 3GPP credentials for initial network access, while the UTM is responsible for the attestation of the UAS credentials for operating the UAS. The network and the UTM can need to be able to associate the UAV and the UAV-C and identify them as a UAS during the authorization process to ensure access to the command and control (C2) communication services, and grant and enforce flight operations for that specific UAS (i.e., UAV and UAV-C pair).

[0097] A given UAV-C can command a fleet of UAVs and be authorized to operate in the context of multiple UASs. For example, the UAV-C can be required to perform a separate authentication and authorization procedure in order to be able to control another UAV (i.e., establish yet another UAS identifier with the network / UTM). Another scenario where the unique UAS identifier establishment can be critical is during a change of UAV-C, where the control of the UAV can switch to a new UAV-C during a flight operation (e.g., due to an emergency). The 3GPP system and the UTM can need to identify the UAV and the new UAV-C pair as another UAS separate from the pair including the UAV and the old UAV-C.

[0098] During the UAS authentication and authorization procedures, it can be assumed that the 3GPP system can provide one or more 3GPP identifiers (e.g., MSISDN, IMEI of the UAV WTRU / UAV-C WTRU) to the UTM, and in return, the UTM can provide the corresponding UAS ID to the network. The UAS ID can also be referred to as a Civil Aviation Authority (CAA) level UAV ID. The 3GPP identifiers used to identify the UAV can also be referred to as 3GPP UAV ID. These various identifiers can be exchanged and authenticated between the WTRU (e.g., UAV WTRU, UAV-C WTRU), the network, and the UTM. The 3GPP system can enable a secure UAS pairing mechanism (e.g., mitigating spoofing attacks on the UAS identity).

[0099] In another embodiment, the airframe identifier (such as the manufacturer serial number, etc., referred to as the UAV ID) and the 3GPP modem identifier (such as the IMSI, referred to herein as the UAV WTRU ID) identified by the 3GPP system and / or the UTM / USS can be combined together or bound for UAVs with removable cellular modems. With these combined or bound identifiers, the flight authorization of the UAS can be achieved by the 3GPP system with the help of the UTM / USS.

[0100] In particular, for ease of operation, flexibility, and economic reasons, the UAV can support a removable cellular modem (e.g., WTRU or UAV WTRU). Furthermore, for deployments in different locations, exchangeable modems and / or exchangeable SIMs / UICCs can be needed. For similar reasons, the UAV-C can employ a similar architecture. For the 3GPP system, the UAV WTRU ID and the UAV-C WTRU ID can remain relevant, while from the perspective of the UTM / USS, the basic identifiers can be the UAV ID and the UAV-C ID. Therefore, there is a need for methods and apparatuses that bind these different identities to enable cross-referencing on both domains (cellular and UTM / USS) and also enable different levels of authorization to lead to flight authorization and possibly additional services.

[0101] The 3GPP system can enable the UAS to send different UAS data to the UTM based on different authentication and authorization levels applied to the UAS. It should be noted that the different authentication and authorization levels can be: initial network access authentication and authorization, UAS identity authentication, UAV flight plan authorization, additional UMT service authentication, such as flight monitoring, collision avoidance services, etc., depending on the regional regulations.

[0102] In another implementation, the UAV, UAV-C, and their associated WTRUs may be certified and / or authorized by multiple UTM / USS. A single UAV flight mission may require support from more than one UTM / USS. One reason for this might be that the UAV flight plan crosses an area not controlled / covered by a single UTM / USS. In this case, the UAV, its controller, and their associated WTRUs need to be identified, certified, and authorized by all relevant UTM / USS before permission to use the flight and 3GPP systems can be granted.

[0103] In another implementation, the exchange of identifiers, authentication, and authorization between UAVs and UAV-Cs can be completed even when they belong to different PLMNs. The 3GPP network may need to support UAVs, and the corresponding UAV-Cs may be connected to different PLMNs simultaneously.

[0104] An implementation scheme for UAV / UAV-C (e.g., UAS) pairing and authorization is described herein.

[0105] Figures 5A-5C Exemplary UAS pairing and authorization scenarios that can be used in conjunction with any other implementation described herein are illustrated. Figures 5A-5C As shown, UAV 502 and UAV-C503 can be paired as a UAS and simultaneously authenticated and authorized by UTM 510. The UAS pairing during the authentication and authorization scenario may include the following stages: (1) WTRU (i.e. UAV WTRU) coming online; (2) UAV-C coming online; and (3) UAV and UAV-C establishing C2 communication.

[0106] Figure 5A An exemplary UAS pairing and authorization scenario where UAV 502 is about to go online is illustrated, which can be used in conjunction with any other implementation described herein. Regarding the first phase (i.e., WTRU or UAV WTRU going online), at step 551, UAV 502 may register on a network such as 5G network 506. At step 552, UAV 502 may authenticate with UTM 510 via network 506 (e.g., using a control plane or user plane path). During this process, UAV 502 may provide an identifier (e.g., UAV-C ID) of the target UAV-C 503 (if available). At step 553, UAV 502 may only receive partial authorization and await final authorization before flying. Final authorization may be conditional upon UAV-C 503 obtaining authorization to guide UAV 502. UAV 502 may not be authorized by network 506 to use C2 communication services until final flight authorization is granted. In this scenario, UAV 502 can remain idle, awaiting final authorization from UTM 510 / network 506 (e.g., asynchronously) via paging, application notification, etc.

[0107] Figure 5B An example UAS pairing and authorization scenario is shown in which the UAV-C 503 is coming online, which can be used in combination with any other embodiment described herein. With respect to the second phase (i.e., UAV-C 503 coming online), at step 554, the UAV-C 503 can be registered on the network 506. At step 555, the UAV-C 503 can authenticate to the UTM 510 via the network 506 (e.g., using a control plane or user plane path). In this process, the UAV-C 503 can provide an identifier of the target UAV 502 (if available), e.g., a UAV WTRU ID. If the target UAV 502 has been temporarily authorized (as described in Figure 5A ), the UAV-C 503 can obtain authorization to operate as part of the process. In this process, the UAV-C 503 can obtain a designated UAS ID (and / or remote ID) in the UTM 510 that identifies the UAV-C 503, UAV 502 pair. The authorized UAS ID can be obtained as part of the authentication and authorization exchange or via a subsequent notification (as below for the UAV 502). At step 556, the UAV 502 can receive a final authorization grant notification indicating the UAS ID and associated UAV-C ID.

[0108] Figure 5C An example UAS pairing and authorization scenario is shown in which the UAV 502 and UAV-C 503 are establishing communication, which can be used in combination with any other embodiment described herein. With respect to the third phase (i.e., UAV 502 and UAV-C 503 establishing C2 communication), at steps 557a, 557b, the UAV 502 and UAV-C 503 can establish a C2 communication path, e.g., using PDU session establishment. The UAS ID in the UAS and optionally the IDs of the peer WTRUs (i.e., UAV WTRU and / or UAV-C WTRU) can be indicated during connection setup. At step 558, the UAV 502 and UAV-C 503 can exchange C2 data traffic.

[0109] It should be noted that the embodiments described in Figures 5A-5C may occur in reverse order, in which the UAV-C 503 can first request authorization for UAS operation. In this case, the UAV-C 503 can perform the steps described in the first phase of Figure 5A , while the UAV 502 can perform the steps described in the second phase of Figure 5B (i.e., by exchanging Figure 5A , Figure 5B the roles of the UAV 502 and UAV-C 503 in . It should also be noted that in the above scenarios, the UAV 502 and UAV-C 503 can be configured to perform the steps described in the first phase of Figure 5A , while the UTM 510 can perform the steps described in the second phase of Figure 5B (i.e., by exchanging Figure 5A , Figure 5B the roles of the UAV 502 and UAV-C 503 in .Figures 5A-5C The steps described in each of the phases in FIG. 6 are not limited to this order sequence, but can be performed or executed in any order to achieve UAV registration / authentication, UAV-C registration / authentication, and / or C2 communication establishment between the UAV 502 and the UAV-C 503.

[0110] Embodiments of UAV-C / UAV assisted UAS pairing are described herein.

[0111] Figure 6 An exemplary procedure 600 for UAV controller (UAV-C) assisted UAS pairing is shown, which can be used in conjunction with any other embodiments described herein. As shown, the UAS (e.g., UAV 602 and UAV-C 603) can be paired with the assistance of the UAV-C during authentication and authorization with the USS / UTM 610. An example of the call flow steps is described herein: Figure 6

[0112] At steps 550a, 550b, the WTRUs (i.e., UAV WTRU and UAV-C WTRU) can both have network registration. Authorization for flight operations of the UAV 602 can be pending authorization of the UAV-C 603 for flight of the UAV 602. As described above, the UAV 602 can perform initial authentication and authorization steps with the network 606 and the UTM 610.

[0113] At steps 651-652, the UAV-C 603 can send an authentication request message to the USS / UTM 610 via the network 606. The message can include its own identity and the identity of the target UAV 602 (if available). The message between the UAV-C 603 and the network 606 can be over the control plane (e.g., NAS signaling such as registration message, service request, general NAS transport message, or new NAS message) or over the user plane transport. In the case of user plane transport, it is assumed that the UAV-C 603 has been authorized to establish a prior data connection (i.e., PDU session is already established).

[0114] At step 653, the USS / UTM 610 can authenticate the UAV-C 603 based on UAS specific credentials (e.g., UAV pilot certificate, owner certificate, etc.) and perform authorization checks based on various UAS parameters such as: submitted flight plan; provided authenticated UAV ID (i.e., flight authorization pending this UAV-C authorization); and / or common authenticated binding parameters (e.g., same owner certificate) presented by the UAV 602 and the UAV-C 603. Upon successful authentication and authorization checks, the USS / UTM 610 can assign and store a unique UAS ID designated to the UAV-C 603 and UAV 602 pair.​

[0115] At step 654, the USS / UTM 610 can send an authentication response message to the UAV-C 603 via the network 606 indicating the result of the authorization, i.e., the identity of the UAS, UAV 602, and UAV-C 603 that have been granted operation authorization. The USS / UTM 610 can also send a separate notification to the network 606 through the appropriate signaling interface (e.g., via NEF) when the authentication and authorization exchange with the USS / UTM 610 is completed at the application layer (e.g., over the user plane N6).

[0116] At step 655, the network 606 can locally set the authorization information (e.g., stored in its respective UAV and UAV-C WTRU context).

[0117] At steps 656a, 656b, the network 606 can forward the result of the UTM authorization to the WTRUs (e.g., UAV-C 603 and UAV 602). For example, at step 656a, the network 606 can send an authorization response message to the UAV-C 603 including the UAS ID specified and additionally / optionally including the associated UAV ID. At step 656b, the network 606 can send an authorization response message to the UAV 602 including the UAS ID specified and additionally / optionally including the associated UAV-C ID.

[0118] At steps 657a, 657b, the UAV 602 and UAV-C 603 can locally store the authorization information (e.g., stored in the WTRU configuration).

[0119] At step 658, the UAV 602 and UAV-C 603 can set up a connection (e.g., PDU session) for C2 communication. The UAV-C 603 and UAV 602 can provide the UAS ID during connection setup. The network 606 can use the UAS ID provided by the UAV-C 603 to distinguish multiple C2 communications that the UAV-C 603 can use when controlling multiple UAVs. Similarly, the UAS ID provided by the UAV 602 can help the network 606 to distinguish two C2 communications that the UAV 602 can have when the UAV control is transferred from one UAV-C 603 to another (as described in the change of UAV-C use case below).

[0120] At step 659, the UAV 602 and UAV-C 603 can exchange C2 data traffic.

[0121] While Figure 6The call flow steps described in FIG. 6 illustrate the case where the UAV 602 is the first entity requesting authorization for UAS operation, but it should be understood that the procedure can be equally applied to the reverse scenario (i.e., by swapping the roles of the UAV 602 and the UAV-C 603 in FIG. 6). Furthermore, the message names used in the call flow are examples, and other signaling or user plane messages can be used to achieve the intended purpose. It should also be noted that Figure 6 the steps described in FIG. 6 are not limited to the sequential order, but can be performed in any order different from the steps described above or in parallel in order to achieve UAV-C / UAV assisted UAS pairing. Figure 6

[0122] Embodiments of subscription-based UAS pairing are described herein.

[0123] Figure 7 An exemplary procedure 700 for subscription-based (bulk) pairing and authorization is shown, which can be used in conjunction with any other embodiment described herein. As shown, the UAS during authentication and authorization can be performed by the USS / UTM 710 based on subscription information. Examples of call flow steps are described herein: Figure 7

[0124] At step 750a, the UAV-1 702a and UAV-2 702b can be registered for authorization for UAS operation suspension. At step 750b, the UAV-C 703 can register on the network and obtain authorization to operate as a UAV controller. The UAV-C 703 can wish to pair with multiple UAVs.

[0125] At step 751, the UAV-C 703 can send a request message to the network 706 to pair with multiple UAVs by including a “UAV fleet control” indication or similar indication. The network 706 can have a list of UAVs (e.g., including UAVs 702a, 702b) associated / stored with the UAV-C subscription.

[0126] ​​At step 752, the network 706 can forward the pairing request to the UAS server / UTM 710, which includes the list of UAVs 702a, 702b to be paired retrieved from the UAV-C subscription information. The network can limit the list of UAVs 702a, 702b to be paired to those currently registered on the network and authorized to operate as UAVs 702a, 702b. For example, identifiers of off-line UAVs can be excluded from the pairing request to the UTM 710. Alternatively or additionally, the list of UAVs associated with the UAV-C can be kept at the UAS server instead of in the 3GPP network. In this case, the network 706 can check from the UAV-C subscription information that the UAV-C 703 is authorized for “bulk pairing” of UAVs 702a, 702b. The network 706 can include a “UAV fleet control” indication instead of the list of UAV pairing requests to the UTM 710. In yet another embodiment, the network 706 can send one or more separate pairing requests for each UAV-C, UAV pair. In this case, the rest of the flow is similar to the UAV-C / UAV assisted pairing, but repeated as many times as there are UAVs to be paired.

[0127] At step 753, the UAS server / UTM 710 can check that the UAV-C 703 is authorized to “bulk pair” with the UAVs 702a, 702b based on the UAV-C and UAV credentials. The UAS server / UTM 710 can pair the UAV-C 703 with each UAV 702a, 702b, specifying a UAS ID for each UAV-C, UAV pair.

[0128] At step 754, the UAS server / UTM 710 can send a pairing response to the network 706 providing a list of UAS ID, UAV ID pairs.

[0129] At step 755, the network 706 can store the pairing information locally (e.g., in its respective UAV and UAV-C WTRU contexts).

[0130] At steps 756a-c, the network 706 can forward the results of the pairing operation to the WTRUs (i.e., the UAV-C WTRU and the UAV WTRUs). For example, at step 756a, the network 706 can send a pairing response message to the UAV-C 703 including a list of UAS ID, UAV ID pairs. At steps 756b and 756c, the network 706 can send a pairing notification message to each of the UAVs 702a, 702b including the specified UAS ID and additionally / optionally the associated UAV-C ID.

[0131] At step 757, the UAV-C 703 can locally store the pairing information (e.g., in a WTRU configuration or WTRU context). The UAVs 702a, 702b can also locally store the pairing information (e.g., in a WTRU configuration or WTRU context).

[0132] At steps 758 and 759, C2 communication between the UAV-C 703 and each UAV 702a, 702b can be established.

[0133] It should be noted that, Figure 7 The steps described in the above are not limited to the sequential order, but can be performed in any order different from the steps described above or performed in order to enable subscription-based UAS pairing.

[0134] Embodiments of UAV-C change are described herein.

[0135] Figure 8 An exemplary procedure 800 of UAV-C change is shown, which can be used in conjunction with any other embodiment described herein. As Figure 8 shown, the UAS pairing update procedure can be performed during the takeover of the UAV 802 control by a new UAV-C (e.g., UAV-C#2 803b). An example of the call flow steps is described herein:

[0136] At step 850, the UAV 802 can be under control of the UAV-C#1 803a. The UAV-C#2 803b can want to take over the control of the UAV 802 (e.g., due to an emergency).

[0137] Steps 850 to 859 are similar to the UAV-C / UAV assisted UAS pairing procedure described above, and thus are not described herein for brevity. In case of the UAV control takeover by the UTM 810, the flow can start with a command from the UTM 810 (at step 854). Once the C2 communication path is established, the UAV-C#2 803b can start sending C2 commands or receiving data from the UAV 802. The UAV 802 can execute the (transient) C2 commands from the UAV-C#1 803a until the C2 communication is established with the UAV-C#2 803b, and / or until the first C2 command is received from the UAV-C#2 803b, to help shorten the control switch-over delay to the minimum.

[0138] At step 860, the network 806 can send a pairing update notification to the UAV 802 and the UAV-C#1 803a to remove their respective UAV / UAV-C#1 pairing information.

[0139] At step 861, the UAV 802 and the UAV-C#1 803a can remove their respective UAV / UAV-C#1 pairing information (e.g., from local configuration). The network 806 can optionally or additionally release the PDU session for C2 communication between the UAV 802 and the UAV-C#1 803a.

[0140] It should be noted that, Figure 8 The steps described in the above are not limited to the sequential order, but can be performed in any order different from the above-described steps or performed in order to achieve the change of UVA-C.

[0141] Embodiments of UAS binding and multi-level authorization are described herein.

[0142] The complete authorization procedure can be done in multiple steps, each step achieving greater functionality, with the last step providing the flight authorization. Generally, the communication-related authorization occurs within the 3GPP system, while the flight-related authorization is pushed by the 3GPP system supporting UTM / USS. To enable a flexible system, the WTRU (i.e., UAV WTRU or UAV-C WTRU) and / or UICC / SIM is assumed to be independent of the UAV or UAV-C. Therefore, the WTRU ID (i.e., UAV WTRU ID or UAV-C WTRU ID) can need to be associated with the corresponding UAV ID or UAV-C ID, and the whole system (including the UAV and UAV-C) can be referred to as UAS and assigned a UAS ID.

[0143] Figure 9 and Figure 10 Exemplary procedures 900, 1000 for UAS multi-level authorization pushed by the 3GPP system are shown, which can be used in combination with any other embodiments described herein. As Figure 9 and Figure 10As shown, UTM / USS 910 can facilitate procedures 900, 1000 for multi-level identification, binding, pairing, and authorization. UAV 902 can include a UAS client 902a and a UAV WTRU 902b. UAV-C 903 can include a UAS client 903a and a UAV WTRU 903b. UAS clients 902a, 902b can include entities (e.g., protocol stacks or layers) that enable UAV WTRU 902b and UAV-C WTRU 903b to communicate with USS / UTM 910. For example, UAS client 902a can provide information elements (e.g., UAV ID) to UAV WTRU 902b to send to USS / UTM 910. UAS client 902a can be part of UAV WTRU 902b (e.g., a UAV WTRU protocol stack or layer) or a separate entity. UAS-C client 903a can be part of UAV-C WTRU 903b (e.g., a UAV-C WTRU protocol stack or layer) or a separate entity. Examples of call flow steps are described herein.

[0144] As shown, at step 951a, UAV WTRU 902b can perform a registration procedure with the network. In addition to regular parameters, UAV WTRU 902b can include WTRU capabilities in the registration request message. This can indicate to the network (e.g., AMF 906) that UAV WTRU 902b is a UAS-capable WTRU. Figure 9

[0145] At step 951b, UAV-C WTRU 903b can perform a registration procedure with the network (e.g., AMF 906) in a similar manner as followed by UAV WTRU 902b. In addition to regular parameters, UAV-C WTRU 903b can include WTRU capabilities in the registration request message. This can indicate to the network (e.g., AMF 906) that UAV-C WTRU 903b is a UAS-capable WTRU.

[0146] It should be noted that the registration procedures of UAV WTRU 902b and UAV-C WTRU 903b can be performed in any order. UAV WTRU 902b or UAV-C WTRU 903b can move to the next step in the overall authorization procedure without waiting for the other WTRU (e.g., UAV-C WTRU 903b or UAV WTRU 902b, respectively) to complete its registration request procedure.

[0147] ​At step 952, at the end of the procedure, the WTRUs (i.e., UAV WTRU 902b, UAV-C WTRU 903b) can implement level 1 authorization (i.e., initial network access authentication and authorization), which allows them to start communicating with the UTM / USS 910 using NAS messages.

[0148] The UAV WTRU 902b, which has implemented level 1 authorization, can then perform binding to associate the UAV WTRU ID with the UAV 902 (i.e., UAV ID) or the UAV 902’s airframe ID. This happens in two steps. In the first step, the USS / UTM 910 can authenticate the UAV ID. Once the UAV ID is authenticated by the USS / UTM 910, the AMF 906 can bind the UAV ID with the UAV WTRU ID that has already been authenticated in the previous WTRU registration procedure. Thus, the UAV ID and the UAV WTRU ID are first separately authenticated by the USS / UTM 910 and the AMF 906, respectively, before being bound together.

[0149] At step 953a, the UAV WTRU 902b can first send a registration request (e.g., NAS request message) with the registration type set to binding request, including the UAV ID and the USS ID (if available). Alternatively or additionally, the binding request can also be conveyed by other types of NAS messages. At this point, the AMF 906 can already know that the UAV WTRU 902b is a legitimate WTRU based on the level 1 authorization described above, but can not know that the UAV is a legitimate UAV.

[0150] The UAV ID can be a manufacturer assigned serial number or a registration number assigned by a central aviation authority (CAA) or its authorized representatives, or other ID that uniquely identifies the UAV airframe.

[0151] When the USS ID is included in the registration request message, it can indicate to the AMF where to forward the binding request. For example, the USS ID can be a destination address such as an IP address, domain name, fully qualified domain name (FQDN), etc. The USS ID can be pre-configured in the UAV by the USS provider. In the case where the UAV 902 wants to perform a flight operation involving multiple USS / UTMs, the UAV WTRU 902b can replace the USS ID with a list of USS IDs. In one alternative or additional embodiment, one of the included USS IDs can be identified as the primary USS along with the list of USS IDs.

[0152] At step 953b, the AMF 906 can forward the binding request to the USS / UTM 910 including the UAV ID. The AMF 906 can also include in the binding request the UAV WTRU ID, such as a generic public subscription identifier (GPSI) (e.g., MSIDN or external identifier), international mobile equipment identity (IMEI), mobile station international subscriber directory number (MSISDN), international mobile subscriber identity (IMSI), etc. If the UAV 902 provided a list of UAS service suppliers (USS) without identifying a primary USS, the AMF 906 can forward the binding request message to each of the USSs included in the list of USSIDs. However, if the UAV 902 also includes a primary USSID in addition to the list of USSIDs, the AMF 906 can only forward the binding request message to the primary USS. In this example, the primary USS can take on the role of forwarding the binding request to the other USSs. The binding response messages are collected in the list of USSIDs before the results of the UAV ID authentication procedure are finally communicated back to the AMF 906.

[0153] At step 954, the USS / UTM 910 can authenticate the UAV ID. This can involve additional signaling between the USS / UTM 910 and the UAV 902, which is handled in a similar manner as a regular registration request.

[0154] At step 955a, the USS / UTM 910 can send a binding response message to the AMF 906 including the results of the UAV ID authentication procedure at the USS / UTM 910. If a primary USS was identified in the corresponding binding request in the list of USSIDs, the binding response from the primary USS to the AMF 906 can include the collective results of the UAV ID authentication procedure at all of the listed USSs. However, if the initial registration request included a list of USSIDs without any primary USSID, the AMF 906 can need to wait for each of the USSs it sent a binding request to in response to the UAV ID authentication procedure results.

[0155] The binding response message can include an indication (e.g., code) indicating the status of the UAV ID authentication procedure. For example, the code or indication can include one or more of the following, but not limited to: ACCEPT, REJECT-USSID, etc.

[0156] At step 955b, the AMF 906 can forward the binding response within a registration accept message (e.g., NAS response message) to the requesting UAV 902.

[0157] At step 955c, the binding procedure can be repeated for the UAV-C 903. The detailed procedure performed at step 955c is similar to the UAV and UAV WTRU binding procedure described above, and therefore is not described herein for the sake of brevity.

[0158] It should be noted that the binding procedure can be performed by the UAV 902 and the UAV-C 903 in any order. At the end of the procedure, the UAV 902 and the UAV-C 903 can achieve level 2 authorization (i.e., binding authorization).

[0159] The UAV WTRU 902b that has achieved binding (with the UAV 902) or level 2 authorization can subsequently perform a pairing procedure to pair the UAV 902 with the UAV-C 903. At the end of the procedure, the UAV 902 and the UAV-C 903 can be associated with each other, considered as a pair, and assigned a UAS ID and / or a remote ID.

[0160] At step 956a, the UAV 902 can first send a registration request to the AMF 906 with the registration type set to UAS pairing request, including the identification of the UAV-C 903 (i.e., UAV-C ID) it seeks to pair with. The UAV-C ID can be pre-configured in the UAV 902 or received from the network or the USS / UTM 910. It can also include the UAV-C WTRU ID (if available). For UAVs with autonomous flight capability (e.g., using UTM navigation), it is envisaged that the provided UAV-C ID can refer to the USS ID / UTM ID (if available). Alternatively or in addition, an indication for autonomous flight, etc. can be provided. The pairing procedure in the case of UAVs with autonomous flight capability can refer to UAV-UTM pairing in the embodiments described herein.

[0161] At step 956b, the AMF 906 can forward the pairing request to the USS / UTM 910 including the UAV ID, the UAV-C ID (if provided by the UAV). Alternatively or in addition, the pairing request can include a sidelink command and control request (SL C2 request) for direct communication between the UAV 902 and the UAV-C 903. Examples of direct communication can include, but are not limited to, Proximity Services (Pro Se) using licensed bands or ISM, WiFi Direct, and D2D.

[0162] At step 957, upon receiving the pairing request, the USS / UTM 910 can retrieve the stored profile of the provided UAV ID and UAV-C ID. Based on the UAV 902 and UAV-C 903 capabilities, allowed pairing list provided by, for example, the operator, etc., the USS / UTM 910 can determine the outcome of the pairing procedure and / or assign a UAS ID to the pair of UAV 902 and UAV-C 903.

[0163] At step 958a, the USS / UTM 910 can send a pairing response message to the AMF 906 including the outcome of the pairing authorization procedure.

[0164] The pairing response message can include a code or indication indicating the status of the UAS pairing procedure. This can include, but is not limited to, one or more of the following: ACCEPT, REJECT-UAV-C capabilities, REJECT-allowed pairing list, and REJECT-corresponding binding not completed. The pairing response message can also include the UAS ID, remote ID, and / or SL C2 response that implicitly indicates that the UAV 902 and UAV-C 903 are paired.

[0165] At step 958b, the AMF 906 can forward the pairing response within a registration accept message (e.g., NAS response message) to both the requesting UAV 902 and the requested UAV-C 903. The registration accept message (or NAS response message) can include the assigned UAS ID and / or remote ID. In one embodiment, the pairing request and response messages can be exchanged with the USS / UTM via the SMF using PDU session establishment request and PDU session establishment accept messages, respectively.

[0166] At step 958c, the binding procedure is alternatively or additionally initiated by the UAV-C. It should be noted that the pairing procedure can be performed by the UAV 902 and UAV-C 903 in any order. The details of the pairing procedure initiated by the UAV-C 903 are similar to those initiated by the UAV 902 and therefore are not described herein for the sake of brevity.

[0167] At the end of this procedure, the UAV 902 and UAV-C 903 can be paired together and as a pair, they can achieve level 3 authorization (i.e., pairing authorization).

[0168] While in the foregoing description, for the sake of Figure 9Not shown, but Level 2 authorization (i.e., binding authorization) and Level 3 authorization (i.e., pairing authorization) can be combined and performed as a single binding and pairing authorization from UAV 902 and / or UAV-C 903. For example, if UAV 902 initiates the binding and pairing process, UAV 902 may send a NAS request message including one or more information elements required for the binding and pairing authorization. For example, UAV 902 may send a NAS request message that may include at least one of the following: a binding request indication, UAV ID, USSID, UAS pairing request indication, UAV-C ID, or UAV-WTRU ID. If UAV-C 903 initiates the binding and pairing process, UAV-C 903 may send a similar NAS request message for the binding and pairing authorization.

[0169] The next step, flight authorization or Level 4 authorization, would allow direct communication to be established between UAV 1002 and UAV-C 1003, enabling UAV 1002 to fly.

[0170] like Figure 10 As shown, at step 1059a, in order to initiate the flight authorization process, UAV-C1003 may send an uplink NAS transport message including a NAS message container to AMF 1006. The NAS message container may include one or more fields, including UAS ID, flight plan, expected mission, and pilot credentials.

[0171] At step 1059b, AMF 1006 may forward the flight authorization request message to USS / UTM 1010, which includes the same elements as those received from UAV-C 1003 in the uplink NAS message.

[0172] At step 1060a, USS / UTM 1010 may send a flight plan authorization request to AMF 1006, including the UAS ID and the requested flight plan. The flight plan may include waypoints from the takeoff point to the landing point, or a series of regularly spaced coordinates along the path that UAV 1002 intends to fly along from the takeoff point to the landing point, and the corresponding times.

[0173] AMF 1006 can check the requested flight plan against a series of network-related parameters, such as available network coverage along the flight path and network load at the corresponding cell along the flight plan.

[0174] At step 1060b, the AMF 1006 can respond to the USS / UTM 1010 with a flight plan authorization response including a flight plan authorization result. Some possible result codes included in the message can include, but are not limited to, ACCEPT, REJECT - network unavailable (flight plan segment), REJECT - network congestion. In case the result code is REJECT, the flight plan authorization response can also include a suggested alternative, including an alternative route that achieves network coverage for the entire flight plan or an alternative time that avoids network congestion.

[0175] At step 1061a, the USS / UTM 1010 can send a flight authorization response including a result code to the UAV-C WTRU 1003b.

[0176] At step 1061b, the AMF 1006 can send the flight authorization response back to the requesting UAV-C 1003 using a downlink NAS transport including a NAS message container. The flight authorization response can also be repeated to the UAV 1002. The message can include a cause code for the rejection response. Successful completion of this procedure can result in the establishment of C2 communication between the UAV 1002 and the UAV-C 1003.

[0177] At step 1062, in another option (e.g., a UAV 1002 using UTM navigation), the flight authorization procedure can also be initiated by the UAV 1002. The details of these steps are similar to those initiated by the UAV-C 1003, and therefore are not described herein for the sake of brevity.

[0178] At the end of this step, the UAV 1002 can be granted a level 4 authorization (i.e., flight authorization) enabling the establishment of direct C2 communication between the UAV 1002 and the UAV-C 1003, thereby facilitating UAV flight.

[0179] It should be noted that the flight authorization or level 4 authorization is valid for the requested flight mission. At the end of the authorized flight mission, the AMF 1006 can terminate the authorization (e.g., locally or via explicit signaling between the WTRUs (e.g., UAV WTRU 1002b and UAV-C WTRU 1003b)) and possibly require the UAV 1002 and the UAV-C 1003 to initiate a flight authorization procedure for a different flight mission.

[0180] At steps 1063a, 1063b, 1064, and 1065a, 1065b, after successfully obtaining the flight authorization or level 4 authorization, the UAV-C 1003 (or UAV 1002) can initiate a request message to request further service authorization, such as network positioning service, weather information, etc. In some cases, these additional services can be authorized by the AMF 1006 with assistance of the UAS service supplier (USS) / UTM 1010. The result code of this authorization is transmitted to the WTRU (e.g., UAV WTRU 1002b or UAV-C WTRU 1003b) via a downlink NAS transport message including a NAS message container.

[0181] Upon successful completion of this procedure, the UAS can obtain level 5 authorization (i.e., additional service authorization) to enable specific network services to support flight operations.

[0182] It should be noted that, Figure 9 and Figure 10 The steps described in FIGS. 10A and 10B are not limited to the sequential order, but can be performed in any order different from the steps described above or performed in order to achieve the multi-level authorization described above.

[0183] In some embodiments, the WTRU (e.g., UAV WTRU or UAV-C WTRU) can be configured to send different levels of UAS data based on different authorization levels. For example, on the condition that the WTRU has received a successful response for WTRU authentication and authorization, it can send a UAS binding request including at least the UAV-C ID and the USSID. On the condition that the WTRU has received a successful UAS binding response, it can send a UAS pairing request including at least the UAV ID (and optionally or additionally including the UAV WTRU ID). On the condition that the WTRU has received a successful UAS pairing response including the UAS ID and / or remote ID, it can send a UAS flight authorization request including at least the UAS ID or remote ID, flight plan, mission profile, and pilot credentials via UL NAS transport. On the condition that the flight plan is successfully authorized, the WTRU can receive a configuration for C2 (and optionally payload) communication.

[0184] In further embodiments, the USSID of the UAS binding request can include a list of USSIDs (including the example scenario of flight plans of more than one USS), or optionally include a primary USSID and a list of secondary USSs. The UAS ID can be a subset or portion of the remote ID, such as from some most significant bit (MSB) to least significant bit (LSB). The UAV-C ID can include the USSID as part of the qualifier (e.g., UAV C id@USSID). Additional services can be authorized from / by the USS / UTM before or after the flight authorization. The UAS entity (UAV or UAV-C) can be able to discover the available counterpart entity (e.g., UAV-C or UAV) after successful authentication and binding but before pairing.

[0185] Embodiments of identification, binding, and authorization with multiple UTM / USS are described herein.

[0186] Figure 11A Figure 11B An example process 1100 for multi-level authorization across multiple UTM and / or UAS service suppliers (USS) is shown, which can be used in conjunction with any other embodiment described herein. As shown, multi-level UAS authorization across multiple USS / UTMs can be performed with two USS / UTMs 1110a, 1110b identified by USSID 1 and USSID 2. An example of the call flow steps is described herein. Figure 11A Figure 11B As shown, multi-level UAS authorization across multiple USS / UTMs can be performed with two USS / UTMs 1110a, 1110b identified by USSID 1 and USSID 2. An example of the call flow steps is described herein.

[0187] Steps 1151a, 1151b, and 1152 can be the same or similar to those described in Figure 9 , and therefore are not described herein for the sake of brevity.

[0188] At steps 1153a, 1153b, 1154, and 1155a, 1155b, the AMF 1106 can send a binding request message to both USS / UTMs 1110a, 1110b (i.e., USSID 1 and USS2). Only when the AMF 1106 receives a binding response from both USS / UTMs 1110a, 1110b can it forward the complete decision to the UAV 1102 along with any applicable decision code. For example, when the UAV 1102 receives a pairing response message with a result code of SUCCESS from each of the requested USS / UTMs 1110a, 1110b, it can proceed to the next step (i.e., pairing).

[0189] ​​In steps 1156a, 1156b, 1157, and 1158a through 1158d, the pairing authorization process may require individual authorization from each USS / UTM 1110a, 1110b listed in the UAV request. In this case, the AMF 1106 may send a pairing request message to one of the USS / UTMs 1110a, 1110b, and, if successful, return a pairing response message with the result code SUCCESS, along with the UAS ID and / or remote ID specified by the USS / UTM. When sending subsequent pairing request messages to the other requested USS / UTMs 1110a, 1110b, the AMF 1106 may include the UAS ID and / or remote ID in the pairing request message.

[0190] In steps 1159a, 1159b, 1160a, 1160b and 1161a, 1161b, when multiple USS / UTMs 1110a, 1110b exist, the flight authorization process may require AMF 1106 to send a flight plan request message individually to each of the USS / UTMs 1110a, 1110b, and then collect responses from them collectively.

[0191] Alternatively, at step 1162, the process may also be initiated by UAV 1102. The details of the steps initiated by UAV 1102 are similar to those initiated by UAV-C 1103, and therefore will not be described here for the sake of brevity.

[0192] At step 1163, when UAV 1102 and UAV-C 1103 receive a flight authorization response message with the cause code set to SUCCESS, a direct link (e.g., a PDU session) for C2 communication can be established between UAV 1102 and UAV-C 1103 via SMF 1 1106a, and a level 4 authorization can be established.

[0193] It should be noted that Figure 11A , Figure 11B The steps described herein are not limited to a specific order, but can be performed or executed in any order different from the steps described above, in order to achieve the multi-level authorization across multiple UTM / USS 1110a and 1110b.

[0194] In some embodiments, the WTRU (e.g., UAV-C WTRU) can be configured to perform multi-level authorization when the UAV belongs to different PLMNs. For example, on the condition that the WTRU has received a successful response for WTRU authentication and authorization, it can send a UAS binding request including at least the UAV-C ID and the USSID. On the condition that the WTRU has received a successful UAS binding response, it can send a UAS pairing request including at least the UAV ID (and optionally the UAV WTRU ID) and the PLMN ID of the network serving the UAV. On the condition that the WTRU has received a successful UAS pairing response including the UAS ID and / or remote ID, it can send a UAS flight authorization request including at least the UAS ID or remote ID, flight plan, mission profile, and pilot credentials via UL NAS transport. On the condition that the flight plan is successfully authorized, the WTRU can receive a configuration for C2 (and optionally payload) communication.

[0195] In further embodiments, the PLMN ID of the network serving the corresponding entity (e.g., UAV-C or UAV) can not be provided by the UAV or UAV-C, in which case the USS / UTM can provide the PLMN ID to the requesting 3GPP network.

[0196] Embodiments of identification, binding, pairing, and authorization across PLMNs are described herein.

[0197] Figure 12A 、 Figure 12B An exemplary procedure 1200 for identification, binding, pairing, and authorization across public land mobile networks (PLMNs) is shown, which can be used in conjunction with any other embodiment described herein. For example, when a UAV 1202 and a UAV-C 1203 belong to different PLMNs, support for identification, binding, pairing, and multi-level authorization across multiple PLMNs can be required. Figure 12A 、 Figure 12B The example shown refers to two AMFs 1206a, 1206b belonging to different PLMNs, where the UAV 1202 and the UAV-C 1203 are connected as AMF1 / SMF1 1206a and AMF2 / SMF2 1206b, respectively. Examples of call flow steps are described herein.

[0198] Steps 1251a, 1251b, and 1252 can be the same or similar to those described in Figure 9 Steps 1251a, 1251b, and 1252 can be the same or similar to those described in

[0199] At steps 1253a, 1253b, 1254, and 1255a-1255c, a binding procedure to bind the UAV ID to the UAV WTRU ID and the UAV-C ID to the UAV-WTRU ID is performed with the respective AMF (i.e., AMF 1 1206a or AMF 2 1206b) of the PLMN to which the UAV WTRU 1202b or the UAV-C 1203 is connected. Depending on the specific case, the UAV ID or the UAV-C ID can be authenticated by the USS / UTM 1210, and then the relevant AMF (i.e., AMF 1 1206a or AMF 2 1206b) can bind the UAV ID to the UAV WTRU ID or the UAV-C ID to the UAV-WTRU ID.

[0200] At steps 1256a, 1256b, 1257, 1258a-1258c, after the binding procedure is completed (i.e., level 2 authorization is achieved), the UAV 1202 or the UAV-C 1203 can initiate a pairing procedure to pair the two entities and identify them as a UAS. In this example, the UAV initiates the pairing procedure by sending a registration request (e.g., a NAS request message) with a registration type set to UAS pairing request and including the requested UAV-C ID. Alternatively or additionally, the UAV 1202 can also include the UAV-C WTRU ID if it is available. The AMF 1 1206a can forward the pairing request to the USS / UTM 1210 for authorization of the pairing of the two entities. Figure 12A 、 Figure 12B In the example shown, the UAV initiates the pairing procedure by sending a registration request (e.g., a NAS request message) with a registration type set to UAS pairing request and including the requested UAV-C ID. Alternatively or additionally, the UAV 1202 can also include the UAV-C WTRU ID if it is available. The AMF 1 1206a can forward the pairing request to the USS / UTM 1210 for authorization of the pairing of the two entities.

[0201] Once the pairing of the UAV 1202 and the UAV-C 1203 is authorized by the USS / UTM 1210, a pairing response message (e.g., a NAS response message) can be sent to the requesting AMF (i.e., AMF 1 1206a, which is responsible for the UAV 1202 in this example) and also to the AMF responsible for the corresponding entity within the UAS (i.e., AMF 2 1206b, which is responsible for the UAV-C 1203 in this example). Each of the AMFs (i.e., AMF 1 1206a and AMF 2 1206b in this example) can then forward the pairing response to the UAV 1202 and the UAV-C 1203, respectively, within a registration accept message.

[0202] At steps 1259a, 1259b, 1260a, 1260b, 1261a, 1261b, and 1262, a flight authorization request can be initiated by the UAV 1202 or the UAV-C 1203. In this example, the UAV 1202 initiates the flight authorization request by sending a registration request (e.g., a NAS request message) with a registration type set to flight authorization request and including the requested UAV-C ID. Alternatively or additionally, the UAV 1202 can also include the UAV-C WTRU ID if it is available. The AMF 1 1206a can forward the flight authorization request to the USS / UTM 1210 for authorization of the flight of the UAV 1202. Figure 12A 、 Figure 12BIn the example shown, UAV-C 1203 initiates the process by sending an uplink NAS transmission message including UAS flight authorization to AMF 2 1206b. This may include the proposed flight plan, pilot credentials, and mission profile. The flight authorization request can be forwarded by AMF 2 1206b to USS / UTM 1210. USS / UTM 1210 can send the flight plan as part of the flight plan authorization request message to the AMF of the PLMN responsible for the UAV (i.e., AMF 1 1206a in this example) and receive the flight plan authorization response in return.

[0203] The USS / UTM 1210 can then send the flight authorization response to two AMF 1206a and 1206b devices, which are then forwarded to UAV 1202 and UAV-C1203 respectively in the NAS downlink transmission message. This may include reason codes such as ACCEPT, REJECT-reason, etc.

[0204] When UAV 1202 and UAV-C 1203 receive a flight authorization response message with the cause code set to SUCCESS, a direct link (e.g., a PDU session) for C2 communication can be established between UAV 1202 and UAV-C 1203 via SMF 1 1206a, and a Level 4 authorization can be established.

[0205] It should be noted that Figure 12A , Figure 12B The steps described herein are not limited to a specific order, but can be performed or executed in any order different from the steps described above in order to achieve the identification, binding, pairing, and authorization across PLMNs described above.

[0206] In some implementations, when the UAV belongs to different PLMNs, the WTRU (e.g., UAV-C WTRU) is configured to perform multi-level authorization. Upon receiving a successful WTRU authentication and authorization response, the WTRU may send a UAS binding request including at least the UAV-CID and USSID. Upon receiving a successful UAS binding response, the WTRU may send a UAS pairing request including at least the UAV ID (and optionally the UAV WTRU ID) and the PLMN ID of the network serving the UAV. Upon receiving a successful UAS pairing response including the UAS ID and / or remote ID, the WTRU may send a UAS flight authorization request via UL NAS transmission including at least the UAS ID or remote ID, flight plan, mission profile, and pilot credentials. Upon successful flight plan authorization, the WTRU may receive configuration for C2 (and optionally payload) communication.

[0207] In further embodiments, the PLMN ID of the network serving the corresponding entity (UAV-C or UAV) can not be provided by the UAV or UAV-C, in which case the USS / UTM can provide the PLMN ID to the requesting 3GPP network.

[0208] Figure 13 An exemplary procedure 1300 for binding and pairing between a UAV and a UAV-C is shown, which can be used in conjunction with any other embodiment described herein. The UAV can comprise a UAV WTRU for cellular communication. The UAV-C can comprise a UAV-C WTRU for cellular communication. At step 1305, the UAV can send a (first) NAS request message to the AMF, the message comprising an authentication and authorization request with a UAV WTRU identity (UAV WTRU ID) and one or more UAV WTRU capabilities for cellular communication. The NAS request message can be sent to the AMF via the UAV WTRU. The one or more UAV WTRU capabilities can comprise one or more indicators indicating that the UAV WTRU is a UAS- capable WTRU. At step 1310, the UAV can receive a (first) NAS response message from the AMF, the message comprising an authentication and authorization response indicating whether the UAV WTRU is authenticated and authorized for network access. The UAV can receive the NAS response message from the AMF via the UAV WTRU.

[0209] At step 1315, the UAV can send a (second) NAS request message to the AMF, the message comprising a binding request indication, a UAV identity (UAV ID), and a USS identity (USSID). Based on the USSID, the UAV ID can be carried by the AMF in a binding request message sent to the USS / UTM for binding authorization of the UAV WTRU and the UAV associated with the UAV ID. The USSID can be a destination address of the NAS request message (i.e., an address of the USS / UTM), such as an IP address, a domain name, a fully qualified domain name (FQDN), etc. The USSID can be pre-configured in the UAV by the USS provider or received from the network. The (second) NAS request message can be sent to the AMF via the UAV WTRU. At step 1320, the UAV can receive a (second) NAS response message from the AMF, the message comprising a binding response indication indicating whether the UAV is bound with the UAV WTRU. The binding response indication can be determined by the USS / UTM and informed to the AMF by the USS / UTM. The (second) NAS response message can be received from the AMF via the UAV WTRU.

[0210] At step 1325, if the binding response indicates that the UAV successfully binds with the UAV WTRU, at step 1330, the UAV can send a (third) NAS request message including the pairing request indication and the UAV-C ID to the AMF. The UAV-C ID can be carried in a pairing request message sent by the AMF to the USS / UTM for pairing authorization of the UAV and the UAV-C associated with the UAV-C ID. The (third) NAS request message can be a PDU session request and sent by the UAV WTRU to the SMF via the AMF. At step 1335, the UAV can receive a (third) NAS response message from the AMF including a UAS ID indicating that the UAV is paired with the UAV-C. The NAS response message can also include a remote ID. The UAS ID can be specified by the USS / UTM and forwarded to the AMF from the USS / UTM when the UAV and UAV-C pair is authorized. The (third) NAS response message can be a PDU session response and received by the UAV WTRU from the SMF via the AMF.

[0211] At step 1340, upon receiving the UAS ID, the UAV can establish a PDU session with the UAV-C via a session management function (SMF) for command and control (C2) communication. The UAV ID can be a manufacturer specified serial number (or airframe ID), and the UAV WTRU ID is a GPSI, MSIDN, IMEI, MSISDN, IMSI, etc. The UAV-C ID can be a manufacturer specified serial number.

[0212] While features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein can be implemented in computer programs, software, or firmware incorporated in computer- readable media for execution by a computer or processor. Examples of computer- readable media include electronic signals (optical, electrical or the like) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, removable floppy disks, RAM, ROM, RAM, 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 in association 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 method for use in a UAV having a Wireless Transmit / Receive Unit (WTRU) for cellular communication, the method comprising: Send a first non-access stratum (NAS) request message to the network node. The first NAS request message includes an initial registration request indication, a UAV identifier (UAV ID), and a UAV system UAS service provider (USS ID). Receive a first NAS response message from the network node indicating that the registration has been accepted; Send a second NAS request message to the network node. The second NAS request message includes pairing information for the UAV and the UAV controller UAV-C paired with the UAV. Sending the second NAS request message is performed after receiving the first NAS response message. Receive a second NAS response message from the network node indicating that the pairing has been accepted; After receiving the second NAS response message indicating that the pairing has been accepted, a request for authorization of command and control C2 communication between the UAV and the UAV-C is sent to the network node; as well as Based on the request for C2 communication authorization, a third NAS response message indicating that the C2 communication authorization is denied is received from the network node.

2. The method according to claim 1, wherein the second NAS request message is a Protocol Data Unit (PDU) session request message and the second NAS response message is a PDU session response message.

3. The method according to claim 1, further comprising: Upon receiving the second NAS response message, a PDU session with the UAV-C is established via a network node that performs the Session Management Function (SMF) for C2 communication.

4. The method of claim 1, wherein the second NAS response message includes a remote identifier.

5. The method of claim 1, wherein the second NAS request message includes a UAV-controller UAV-C identifier UAV-C ID and the UAV-C ID is a serial number specified by the manufacturer.

6. The method according to claim 1, wherein, Based on the USS ID, the UAV ID is carried in a binding request sent to the Unmanned Aerial Vehicle System (UAS) service provider, USS / UAS Traffic Management (UTM), for binding authorization of the UAV WTRU and the UAV associated with the UAV ID; The binding response indication is determined by the USS / UTM; and The sending of the second NAS request message is executed upon receiving the binding response indication.

7. The method of claim 6, wherein the second NAS request message is sent under the condition that the UAV is bound to the UAV WTRU, wherein the second NAS request message includes the UAV-C ID.

8. The method of claim 6, further comprising: Send another NAS request message to the network node, including an authentication and authorization request with a UAV WTRU identifier (UAV WTRU ID) and one or more UAV WTRU capabilities for the cellular communication; as well as Receive from the network node another NAS response message including an authentication and authorization response indicating whether the UAV WTRU is authenticating and authorizing access to the cellular network.

9. The method of claim 8, wherein the UAV ID is a manufacturer-specified serial number and the UAVWTRU ID is an International Mobile Equipment Identity (IMEI).

10. The method of claim 1, wherein the second NAS request message includes a UAV ID associated with the UAV and a UAV-C ID associated with the UAV-C, and wherein the UAS includes the UAV and the UAV-C.

11. An unmanned aerial vehicle (UAV), comprising: UAV Wireless Transmit / Receive Unit (WTRU) for cellular communication; and processor, The UAV WTRU and the processor are configured as follows: Send a first non-access stratum (NAS) request message to the network node. The first NAS request message includes an initial registration request indication, a UAV identifier (UAV ID), and a UAV system UAS service provider (USS ID). Receive a first NAS response message from the network node indicating that the registration has been accepted; Send a second NAS request message to the network node. The second NAS request message includes pairing information for the UAV and the UAV controller UAV-C paired with the UAV. Sending the second NAS request message is performed after receiving the first NAS response message. Receive a second NAS response message from the network node indicating that the pairing has been accepted; Upon receiving the second NAS response message indicating that pairing has been accepted, a request for authorization of command and control C2 communication between the UAV and the UAV-C is sent to the network node; and Receive a third NAS response message from the network node indicating that the C2 communication authorization is denied.

12. The UAV of claim 11, wherein the second NAS request message is a Protocol Data Unit (PDU) session request message and the second NAS response message is a PDU session response message.

13. The UAV of claim 11, wherein the UAV WTRU and the processor are further configured to, upon receiving the second NAS response message, establish a PDU session with the UAV-C via a network node performing a session management function (SMF) for C2 communication.

14. The UAV of claim 11, wherein the second NAS response message includes a remote identifier.

15. The UAV of claim 11, wherein the second NAS request message includes a UAV-controller UAV-C identifier UAV-C ID and the UAV-C ID is a serial number specified by the manufacturer.

16. The UAV according to claim 11, wherein, Based on the USS ID, the UAV ID is carried in a binding request sent to the Unmanned Aerial Vehicle System (UAS) service provider, USS / UAS Traffic Management (UTM), for binding authorization of the UAV WTRU and the UAV associated with the UAV ID; The binding response indication is determined by the USS / UTM; and The sending of the second NAS request message is executed upon receiving the binding response indication.

17. The UAV of claim 16, wherein the second NAS request message is sent under the condition that the UAV is bound to the UAV WTRU, wherein the second NAS request message includes the UAV-C ID.

18. The UAV of claim 16, wherein the UAV WTRU and the processor are further configured as follows: Send another NAS request message to the network node, including an authentication and authorization request with a UAV WTRU identifier (UAV WTRU ID) and one or more UAV WTRU capabilities for the cellular communication; and Receive from the network node another NAS response message including an authentication and authorization response indicating whether the UAV WTRU is authenticating and authorizing access to the cellular network.

19. The UAV of claim 18, wherein the UAV ID is a manufacturer-specified serial number and the UAVWTRU ID is an International Mobile Equipment Identity (IMEI).

20. The UAV of claim 11, wherein the second NAS request message includes a UAV ID associated with the UAV and a UAV-C ID associated with the UAV-C, and wherein the UAS includes the UAV and the UAV-C.

Images