Methods, apparatuses, and systems for command and control (C2) communication setup and update

Abstract

Methods, apparatuses, and systems that can be implemented in a wireless transmit / receive unit (WTRU), an unmanned aerial vehicle (UAV), and / or a UAV-controller (UAV-C) are disclosed. In one representative method, the UAV can switch from a first command and control (C2) communication link between the UAV and a first UAV-C to a second C2 communication link for C2 communications. The method can include determining, by the WTRU, to switch C2 communications from the first C2 communication link to the second C2 communication link based on a C2 switching condition, sending, by the WTRU, a notification to a C2 control entity indicating link information used to determine to switch from the first C2 communication link to the second C2 communication link, receiving, by the WTRU, information indicating the switch from the C2 control entity, and switching, by the WTRU, C2 communications from the first C2 communication link to the second C2 communication link.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 63 / 004,139, filed April 2, 2020; U.S. Provisional Patent Application Serial No. 63 / 063,687, filed August 10, 2020; and U.S. Provisional Patent Application Serial No. 63 / 150,279, filed February 17, 2021, the contents of which are incorporated herein by reference. Technical Field

[0003] The embodiments disclosed herein relate to wireless communication in general, and to methods, apparatus and systems for C2 communication setup and updates, for example. Attached Figure Description

[0004] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. The drawings in this specification are exemplary. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and contemplated. Furthermore, similar reference numerals in the drawings indicate similar elements, and wherein:

[0005] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments;

[0006] Figure 1B This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0007] Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0008] Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0009] Figure 2 This is a diagram illustrating a representative UAS and the interaction with network and Unmanned Aircraft System (UAS) traffic management (UTM) for authorization;

[0010] Figure 3A This is a diagram illustrating a representative procedure for initial C2 communication mode selection based on the USS (UAS service provider) / UTM policy;

[0011] Figure 3B This is a diagram illustrating a representative procedure for C2 communication mode switching based on the USS / UTM strategy;

[0012] Figure 3C This is a diagram illustrating a representative procedure for a C2 communication link with UAV-C settings established using on-demand network connectivity;

[0013] Figure 4 This is a diagram illustrating a representative procedure for a C2 communication link with UAV-C settings, for example, using pre-established network connectivity;

[0014] Figure 5 This is a diagram illustrating, for example, the procedure for updating the C2 communication link triggered by a change in UAV-C;

[0015] Figure 6 This is a diagram illustrating a representative procedure for the revocation of C2 communication authorization for a first UAV-C (e.g., via takeover by a high-priority second UAV-C) in the context of a change in UAV-C;

[0016] Figure 7 This is a diagram illustrating a representative procedure for C2 communication link switching, for example, triggered by a change in UAV-C;

[0017] Figure 8 This is a diagram illustrating a representative procedure for C2 communication involving updates via a new IP address (e.g., to establish a new PDU session);

[0018] Figure 9 This is a diagram illustrating a representative procedure for C2 communication that updates via a new IP address (e.g., using an existing PDU session that can be updated);

[0019] Figure 10 This is a diagram illustrating a representative procedure for C2 communication updated via a new IP address (e.g., where the UTM can notify the UAV-C);

[0020] Figure 11 This is a diagram illustrating a representative procedure for C2 communication updated via a new IP address (e.g., where the UAV can notify the UAV-C).

[0021] Figure 12 This is a diagram illustrating a representative procedure for a C2 communication link with UTM settings established using on-demand network connectivity;

[0022] Figure 13 This is a diagram illustrating a representative procedure for a C2 communication link with UTM settings established using pre-established network connectivity;

[0023] Figure 14This is a flowchart illustrating a representative method for establishing C2 communication between a UAV and a UAV-C, implemented by a WTRU;

[0024] Figure 15 This is a flowchart illustrating a representative method implemented by WTRU to change C2 communication from between UAV and the first UAV-C to between UAV and the second UAVC;

[0025] Figure 16 This is a flowchart illustrating a representative method for managing C2 communication directly established between a UAV and a UAV-C via a first connection, implemented by a WTRU;

[0026] Figure 17 This is a flowchart illustrating a representative method implemented by WTRU for managing C2 communication established between a UAV and a UAV-C or another control entity via a first connection;

[0027] Figure 18 This is a flowchart illustrating a representative method for establishing C2 communication between a UAV and a first UAV-C, implemented by a WTRU;

[0028] Figure 19 This is a flowchart illustrating a representative method implemented by WTRU for switching C2 communication with UAV from a first C2 communication link to UAV-C to a second C2 communication link to UAV-C; and

[0029] Figure 20 This is a flowchart illustrating a representative method implemented by WTRU for switching C2 communication between UAV and UAV-C from a first C2 communication link to a second C2 communication link. Detailed Implementation

[0030] Exemplary network for implementing the implementation scheme

[0031] Certain implementations may be carried out in autonomous and / or semi-autonomous vehicles, robotic vehicles, automobiles, IoT devices, any mobile device, or WTRUs or other communication devices that can then be used in communication networks. The following sections provide a description of some exemplary WTRUs and / or other communication devices and networks in which such WTRUs may be incorporated.

[0032] Figure 1AThis is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

[0034] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or other networks 112). As examples, base stations 114a and 114b may be base transceiver stations (BTS), Node Bs, evolved Node Bs (eNBs), Home Node Bs (HNBs), Home Evolved Node Bs (HeNBs), gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0035] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0036] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via 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.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0037] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0038] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0039] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c enable radio technology such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0040] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0041] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

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

[0043] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0044] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0046] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0047] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0050] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

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

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

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

[0054] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0055] The processor 118 of WTRU 102 is operable to communicate with a variety of peripheral devices 138 to implement the representative embodiments disclosed herein, including, for example, any of the following: one or more accelerometers, one or more gyroscopes, a USB port, other communication interfaces / ports, a display and / or other visual / audio indicators.

[0056] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0057] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0058] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0059] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0060] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] The MME 162 can connect to each of the evolved nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0062] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0063] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0064] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0065] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0066] In a representative implementation, the other network 112 may be a WLAN.

[0067] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0068] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, such as in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0069] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0070] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0071] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0072] WLAN systems supporting multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC-type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

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

[0074] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one implementation scheme. As noted above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0075] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation scheme. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation scheme, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In the implementation scheme, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0076] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with an scalable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0077] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to another RAN (such as evolved Node B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node B 160a, 160b, and 160c. In a non-standalone configuration, evolved Node B 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

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

[0079] Figure 1DThe CN 115 shown may 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. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0080] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c via the N2 interface in RAN 113 and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low-Latency Communication (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, etc. AMF 162 can provide control plane functions for handover between RAN 113 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)).

[0081] SMF 183a and 183b can connect to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 115 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b, and configure traffic routing through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU 102 IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0082] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0083] CN 115 may facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or may communicate with such an IP gateway. Additionally, CN 115 may provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local data networks (DNs) 185a and 185b.

[0084] Given Figures 1A to 1D As described herein, one or more of the functions described with reference to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, Evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0085] 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 may use over-the-air wireless communication to perform tests.

[0086] The one or more simulation 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 simulation 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 simulation devices may be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0087] In some representative implementations, methods, apparatus, and systems for setting up C2 communication links can be implemented, for example, by a WTRU (e.g., an unmanned aerial vehicle (UAV)) using on-demand connectivity setup procedures. For instance, the WTRU can perform UAV authentication and authorization using or via Unmanned Aircraft System (UAS) Traffic Management (UTM) procedures. The WTRU can receive, for example, a UAS identifier (e.g., UAS id) in an authorization message from the UTM. The WTRU can send the UAS id to the network (e.g., a network entity) during the procedures for setting up a PDU session / PDN connection for C2 communication, and / or can receive information / instructions indicating pending UAS associations (e.g., UAS association pending indications) during the procedures. The WTRU can execute procedures for updating PDU session / PDN connections (e.g., network-triggered procedures), and / or can receive information / indications (e.g., a successful C2 communication link setup indication indicating successful C2 communication link setup) and peer UAV controller (UAV-C) Internet Protocol (IP) (e.g., IP address) during the procedure, and / or the WTRU can receive the peer UAV-C IP address in an authorization message from the UTM. The WTRU can participate in and / or communicate (e.g., send and / or receive) C2 communication with the peer UAV-C.

[0088] In some representative implementations, methods, apparatus, and systems for C2 communication link setup can be implemented by the WTRU / UAV using pre-established (e.g., backup) connectivity procedures. The WTRU / UAV can perform UAV authentication and authorization, for example, through or using UTM procedures. The WTRU can send indications / information (e.g., UAV communication indications) to the network (e.g., network entities) during procedures for setting up a PDU session / PDN connection for C2 communication (e.g., a backup PDU session / PDN connection), and / or can receive indications / information (e.g., UAS association pending indications) during the procedures. The WTRU / UAV can execute procedures for updating the PDU session / PDN connection (e.g., network-triggered procedures), and / or can receive indications / information (e.g., successful C2 communication link setup indications), UAS IDs, and / or authorized UAV-C IPs (e.g., IP addresses) during the procedures, and / or the WTRU can receive the UAS ID and peer UAV-C IP address in an authorization message from the UTM. WTRU / UAV can participate in and / or communicate (e.g., send and / or receive) with peer UAV-C's C2 communication.

[0089] In some representative implementations, methods, apparatus, and systems for C2 communication link updates may be implemented by the WTRU (e.g., UAV), for example, due to a UAV-C change procedure. The WTRU / UAV may perform C2 communication with a first UAV-C (e.g., UAV-C#1). This pair of UAVs, UAV-C#1, may be identified as UAS id#1. The WTRU / UAV may perform procedures (e.g., network-triggered procedures) for updating the PDU session / PDN connection to communicate with a second UAV-C (e.g., peer UAV-C#2), and / or may receive information / instructions (e.g., C2 communication link update indication), a new UAS id#2, and / or a new peer UAV-C IP#2 during the procedure, and / or the WTRU may receive UAS id#2 and / or UAV-C IP#2 in an authorization message from the UTM. WTRU / UAV can participate in C2 communication with peer UAV-C#2 (e.g., can communicate with the peer UAV-C).

[0090] In some representative implementations, methods, apparatus, and systems for C2 communication link switching can be implemented by the WTRU / UAV, for example, due to a UAV-C change procedure. The WTRU / UAV can perform C2 communication with a first UAV-C (e.g., UAV-C#1) via a first network connection (e.g., network connection #1). The WTRU / UAV can establish another connection (e.g., a second and / or backup connection #2) for a potential C2 communication link switch to another UAV-C (e.g., a second peer UAV-C#2). The WTRU / UAV can execute procedures (e.g., network-triggered procedures) for updating the PDU session / PDN connection (e.g., for connection #2). The WTRU / UAV may receive information / instructions (e.g., C2 communication link switching indication), the new UAS ID#2, the old UAS ID#1, and / or the new authorized peer UAV-C IP#2 during the procedure, and / or the WTRU may receive the new UAS ID#2, the old UAS ID#1, and / or the UAV-C IP#2 in an authorization message from the UTM. The WTRU / UAV may participate in C2 communication with the new UAV-C (e.g., UAV-C#2) via connection #2 (e.g., communicate with the new UAV-C). The WTRU / UAV may release the old connection (e.g., connection #1) associated with UAS ID#1.

[0091] In some representative implementations, methods, apparatus, and systems for updating network / UTM-assisted C2 communication links (e.g., changing UAV / UAV-C IP addresses) can be implemented.

[0092] In some representative implementations, methods, apparatus, and systems can be used to set up C2 communication links (e.g., for UTM navigation).

[0093] In some representative embodiments, methods, apparatus, and systems can be implemented for switching C2 communication paths from direct communication (e.g., direct link) to network-assisted communication or from network-assisted communication to direct communication (e.g., direct link). For example, a UAV can establish redundant direct / network-assisted C2 connections based on authorization parameters received from a network / USS / UTM (e.g., a network entity).

[0094] In some examples, the UAV may receive QoS threshold parameters from the network / USS / UTM (e.g., a network entity) to monitor direct link quality and may trigger a switch from direct communication to network-assisted communication if or when the direct link quality becomes unacceptable based on those QoS thresholds (e.g., the direct link quality is below the threshold level).

[0095] In some representative embodiments, methods, apparatus, and systems can be implemented for switching C2 communication paths from direct communication (e.g., direct link) or network-assisted communication to UTM navigation communication. For example, during link switching, the UAV may receive instructions (e.g., policies) from the network / USS / UTM (e.g., network entity) regarding how to handle the old connection (e.g., to maintain or release the old connection). The UAV may also receive instructions from the network / USS / UTM (e.g., network entity) regarding the type of C2 communication to use on the new connection (e.g., direct type, network-assisted type, or UTM navigation type).

[0096] Procedures for supporting UAS

[0097] Figure 2 This diagram illustrates a representative UAS 210 and its interactions with the network and UTM 220 for authorization.

[0098] 3GPP has identified use cases and potential requirements for UAS support, including requirements for UAS remote identification and authorization. Additional enhancements to UAS support may include: (1) UAS command and control (C2) communication; (2) unmanned aerial vehicle (UAV) navigation via UAV controller (UAV-C) or via UAS traffic management (UTM); and (3) changes to UAV-C during flight missions. References Figure 2 UAS 210 may refer to a combination of UAV 211 (e.g., a drone) and UAV-C 212. A communication system / network (e.g., a network entity) provides communication capabilities between UAV 211 and UAV-C 212, which can communicate via the same or different RAN nodes and / or via different Public Land Mobile Networks (PLMNs). UAV-C 212 can connect via 3GPP access and / or non-3GPP access. UTM 220 provides UAS identification and / or tracking, authorization, execution, and / or regulation of UAS operations. UTM 220 may store data required / used for operating one or more UAS 210s.

[0099] Multiple C2 communication types (e.g., three types) may include: (1) direct communication (e.g., UAV-C and UAV use direct C2 communication links (e.g., D2D links and / or PC5 links) to communicate with each other); (2) network-assisted communication, e.g., where UAV-C 212 and UAV 211 use unicast C2 communication links over a network (e.g., Uu links and / or WLAN links) to communicate with each other (e.g., unlike direct C2 communication, enabling UAV 211 to fly beyond visual line of sight (BVLOS) is possible through such network-assisted communication); (3) UTM navigation communication, e.g., where UAV 211 with autonomous flight capabilities can fly under the supervision of UTM 220 according to a pre-arranged flight plan (e.g., the C2 communication link between UAV 211 and UTM 220 can be used for flight monitoring, dynamic route updates, and / or occasional navigation).

[0100] The connectivity used to enable C2 traffic exchange (between UAV 211 and UAV-C 212 or UTM 220) may be authorized by the mobile network operator (MNO) under the following conditions: (1) UAV 211 and / or UAV-C 212 have been authorized by the MNO / UTM 220 for flight operations; (2) the association between UAV 211 and UAV-C 212 has been authorized by the UTM 220 (e.g., for a specific flight mission). Specific implementations can be applied to both EPS and 5GS and can achieve / support any of the following: (1) UAV-C 212 in the same PLMN or in a different PLMN than the UAV; (2) UAV-C 212 without WTRU 102; (3) changes to UAV-C 212 (e.g., during active C2 communication, in flight and / or during flight of the UAV, etc.); (4) changes to the IP addresses of UAV 211 and / or UAV-C (e.g., during active C2 communication, in flight and / or during flight of the UAV, etc.); (5) changes to the C2 communication path between UAV211 and UAV-C 212 (e.g., from direct to network-assisted or vice versa); (6) changes to the C2 communication path from UAV-UAV-C (e.g., direct or network-assisted) to UAV-USS / UTM (e.g., UTM navigation, etc.).

[0101] UAV 211 may be equipped with a WTRU 102a (e.g., a 3GPP UE) with UAS communication capabilities. The terms UE / WTRU and UAV are used interchangeably herein. UAV-C communication may be implemented via a 3GPP UE 102b component or another type of communication module (e.g., terrestrial communication). In the case of UAV-C 212 equipped with its own 3GPP UE 102b, the terms UAV-C and UE / WTRU are used interchangeably.

[0102] The UAV / UAV-C ID identifies a device with UAV / UAV-C capabilities (e.g., a drone) and can be an external identifier provided by the UAS service provider (USS) / UTM and / or assigned when registering with a local authority (e.g., the FAA), or a manufacturer serial number provided / known by the UAV device (e.g., a Permanent Device Identifier (PEI) (e.g., IMEI and / or MAC address, etc.)).

[0103] The UAV / UAV-C WTRU id can identify the cellular subscription of the UAV / UAV-C (e.g., International Mobile Subscriber Identity (IMSI) and / or Mobile Station International Subscriber Telephone Number (MSISDN) or Universal Public Subscription Identifier (GPSI), etc.).

[0104] The UAS ID can identify the UAS 210 (e.g., UAV-UAV controller association) and can be assigned by the USS / UTM (e.g., it can be outside the 3GPP network).

[0105] For simplicity, UTM 220 can generally be referred to as an ecosystem outside of 3GPP systems responsible for UAS operational control (e.g., UAV remote identification and / or air traffic control), and the corresponding functions can also be referred to as USS or USS / UTM.

[0106] In some representative implementations, the UAV Control Function (UCF) can be used as a 3GPP network function. The UCF can interact with the UTM / USS, for example, to support UAV-related protocols. Communication between the UAV / UAV-C and the UCF can be relayed via other network functions (e.g., the AMF) using NAS messages or relayed within NAS messages. UAV-related information exchanged between the UAV / UAV-C and the UCF can be placed in a UAV information container and carried in NAS messages. In some implementations, communication between the UAV / UAV-C and the UCF can be performed via user plane communication.

[0107] Representative procedures for network-assisted C2 communication

[0108] As described herein, authorization signaling communication between the WTRU (e.g., UAV 211 and / or UAV-C 212) and the UTM 220 may use user plane (UP) and / or control plane (CP) transmissions and may be established according to certain representative implementations (e.g., during network-assisted UAV authentication and authorization via UTM procedures).

[0109] As described in this document, messages between the UAV / UAV-C and UTM 220 used for C2 communication establishment and / or modification can be exchanged via UP and / or CP. For example, UAS control messages can be carried as UAS containers using NAS transport.

[0110] UAV 211 and UAV-C 212 may be served by different PLMNs, and / or UAV-C 212 may be connected via other connections or other protocols / mechanisms besides 3GPP networks (e.g., terrestrial and / or non-3GPP networks, etc.). Networks / network entities may include or consist of E-UTRAN connected to the 5G core (5GC) and EPC, and / or NG-RAN / NR connected to or composed of network entities connected to the 5GC and these networks.

[0111] Representative protocols for C2 communication links with UAV-C configuration (e.g., for on-demand connectivity).

[0112] Upon receiving an authorization message from the UTM 220 via the peer UAV-C 212 indicating the UAS ID associated with the UAV, or subsequently, the UAV / UAV-C can establish connectivity with the network to enable C2 communication with the UAV-C. The WTRU may send the UAS ID to the network (e.g., network entity, network node, and / or network function) during the procedure for establishing a new PDU session / PDN connection, and may receive messages including indications (e.g., UAS association pending indication) from the network (e.g., network entity, network node, and / or network function) during the procedure. The WTRU may participate in C2 communication with the peer UAV-C 212, for example, upon receiving a success indication (e.g., successful C2 communication link setup indication) and / or the peer UAV-C IP from the network (e.g., network entity, network node, and / or network function) during the procedure for updating the PDU session / PDN connection, or subsequently.

[0113] As disclosed herein, the term “network” is interchangeable with the terms “network entity,” “network node,” and / or “network function.”

[0114] Representative behavior of WTRU / UAV for on-demand connectivity

[0115] In some representative implementations, the WTRU can perform network-assisted UAV authentication and authorization via or using UTM procedures. The WTRU may receive the UAS ID (e.g., UAS association authorization message) in messages from the UTM 220. The WTRU may receive messages directly from the UTM 220 (e.g., via the user plane) and / or via the UCF. The WTRU may send information / instructions (e.g., C2 communication indication) and / or the UAS ID to the network (e.g., network entities, network nodes, and / or network functions) in messages to establish a PDU session / PDN connection, for example, to enable C2 communication. The indication may specify the type of C2 communication (e.g., network-assisted C2 with UAV-C 212 or UTM navigation C2). The WTRU may receive information / instructions (e.g., UAS association pending indication) in messages from the network (e.g., network entities, network nodes, and / or network functions) indicating the successful establishment of the PDU session / PDN connection. The WTRU may receive any of the following in messages from the network: (1) a success indication (e.g., a successful C2 communication link setup indication); (2) the peer UAV-C IP address; (3) the UAV-C id (e.g., PEI and / or MAC address, etc.) (e.g., during a procedure for updating PDU session / PDN connection and / or during a WTRU configuration update (UCU) procedure). Additionally or alternatively, the WTRU may receive any of the following in messages from, for example, from, the UTM 220, etc. (e.g., C2 communication authorization messages): (1) the peer UAV-C IP address; and / or (2) the UAV-C id. The WTRU may receive messages directly from the UTM 220 and / or via the UCF. The WTRU may participate in C2 communication with the peer UAV-C 212 (e.g., communicate with the peer UAV-C) (e.g., using the UAV-C IP address).

[0116] Representative behavior of UAV service networks for on-demand connectivity

[0117] In some representative implementations, the network (e.g., network entities, network nodes, and / or network functions) can perform network-assisted UAV authentication and authorization via UTM procedures. The network (e.g., network entities, network nodes, and / or network functions) may receive WTRU id and / or UAS id in messages from UTM 220 (e.g., UAS associated authorization messages). The network (e.g., network entities, etc.) may update the WTRU context via UAS authorization information from UTM 220 (e.g., including the assigned UAS id). The network (e.g., network entities) may receive C2 communication indication and / or UAS id in messages from WTRU to set up PDU session / PDN connections, for example, to enable C2 communication. For example, the network (e.g., network entities) may allocate resources for PDU session / PDN connections. Traffic through PDU session / PDN connections may be restricted (e.g., traffic to / from external data networks may be disallowed) until authorization for C2 communication is established. The network (e.g., a network entity) may send information / indications (e.g., UAS association pending indication) indicating successful setup of the PDU session / PDN connection to the WTRU in a message. The network (e.g., a network entity) may send any of the following to the UTM 220 in a message (e.g., a UAS association authorization acknowledgment (ACK) message): (1) WTRUid; (2) UAS id; (3) UAV IP address; (4) UAV id (e.g., PEI and / or MAC address, etc.) and the current location of UAV 211 (e.g., takeoff location). The network (e.g., a network entity) may send any of the following in a message from the UTM 220 (e.g., a C2 communication authorization message): (1) WTRU id; (2) UAS id; (3) UAV-C IP address; (4) UAV-C id (e.g., PEI and / or MAC address, etc.). The network (e.g., a network entity) may update PDU session / PDN connections, for example, to allow the exchange of C2 traffic (e.g., traffic to / from UAV-C IP addresses / DNs). The WTRU may receive messages directly from UTM 220 and / or via UCF. The network (e.g., a network entity) may send any of the following to the WTRU in the message: (1) information / indication (e.g., a successful C2 communication link setup indication); (2) peer UAV-C IP address; (3) UAV-C id (e.g., PEI and / or MAC address, etc.) (e.g., via procedures for updating PDU session / PDN connections and / or during UCU procedures). The network (e.g., a network entity) may send or forward C2 traffic between UAV 211 and UAV-C 212.

[0118] Representative protocols for C2 communication links with UAV-C settings (e.g., for pre-established connectivity).

[0119] UAV / UAV-C may pre-establish connectivity with a network (e.g., a network entity) to enable C2 communication with UAV-C / UAV. WTRU may send C2 communication instructions (e.g., via UAV-C 212) to the network (e.g., a network entity) during a procedure for establishing a new PDU session / PDN connection, and may receive information / instructions (e.g., UAS association pending indication) during the procedure. WTRU may participate in and communicate with peer UAV-C 212 during C2 communication (e.g., with it) upon receiving a message from the network (e.g., a network entity) during a procedure for updating a PDU session / PDN connection, the message including any of the following: (1) a success indication (e.g., a successful C2 communication link setup indication); (2) a UAS id; and / or (3) a peer UAV-C IP.

[0120] Representative behavior of WTRU / UAV for pre-established connectivity

[0121] In some representative implementations, the WTRU can perform network-assisted UAV authentication and authorization via or using UTM procedures. The WTRU may send information / indications (e.g., C2 communication indications) in messages to the network (e.g., a network entity) to set up a PDU session / PDN connection for establishing C2 communication. This connection may sometimes be referred to herein as a backup connection. The WTRU may receive information / indications (e.g., UAS association pending indications) in messages from the network (e.g., a network entity) to indicate successful setup of the PDU session / PDN connection. The WTRU may suppress C2 application traffic through this connection until it receives subsequent indications (e.g., C2 communication link setup indications) from the network (e.g., a network entity). The WTRU may receive any of the following in a message from the network (e.g., a network entity): (1) a successful C2 communication link setup indication; (2) a UAS id; (3) a peer UAV-C IP address; and / or (4) a UAV-C id (e.g., a PEI and / or MAC address, etc.) (e.g., via a procedure for updating a PDU session / PDN connection and / or during a UCU procedure). Additionally or alternatively, the WTRU may receive any of the following in a message from the UTM 220 (e.g., a C2 communication authorization message): (1) a UAS id; (2) a peer UAV-C IP address; and / or (3) a UAV-C id. The WTRU may receive this message directly from the UTM 220 and / or via the UCF. The WTRU may participate in C2 communication with the peer UAV-C 212 (e.g., may communicate with the peer UAV-C) (e.g., using the UAV-C IP).

[0122] Representative behavior of UAV service networks with pre-established connectivity

[0123] A network (e.g., a network entity) can perform network-assisted UAV authentication and authorization via UTM procedures. The network (e.g., a network entity) may receive information / instructions (e.g., C2 communication instructions) from messages received from the WTRU, such as to set up a PDU session / PDN connection for establishing C2 communication. For example, the network (e.g., a network entity) may allocate resources for a PDU session / PDN connection (e.g., a standby PDU session / PDN connection). Traffic on the PDU session / PDN connection may be restricted (e.g., traffic to / from, for example, an external data network may be disallowed until authorization for C2 communication is established). The network (e.g., a network entity) may register the IP address of the PDU session / PDN connection with the UTM 220 (during or after the PDU session / PDN connection establishment). The network (e.g., a network entity) may send information / instructions (e.g., UAS association pending instructions) in messages to the WTRU indicating, for example, the successful setup of the PDU session / PDN connection. A network (e.g., a network entity) may send any of the following in a message from UTM 220 (e.g., a C2 communication authorization message): (1) WTRU id; (2) UAS id; (3) UAV-C IP address; (4) UAV-Cid (e.g., PEI and / or MAC address, etc.). A network (e.g., a network entity) may update PDU session / PDN connections, for example, to allow the exchange of C2 traffic (e.g., to / from UAV-C IP address / DN). A network (e.g., a network entity) may send any of the following to the WTRU in a message: (1) a successful C2 communication link setup indication; (2) the peer UAV-C IP address; (3) the UAV-Cid (e.g., PEI and / or MAC address, etc.) (e.g., via a procedure for updating PDU session / PDN connections and / or during a UCU procedure). A network (e.g., a network entity) may forward C2 traffic between UAV 211 and UAV-C 212.

[0124] Representative procedures for C2 communication link updates via UAV-C modifications

[0125] The WTRU may participate in C2 communication with UAV-C 212 (e.g., UAV-C#1). The first pair of the first UAV 211 and the first UAV-C 212 (e.g., UAV and UAV-C#1) may be identified by the identifier UAS id#1. The WTRU may participate in C2 communication with the new UAV-C#2 212, for example, during a procedure for updating a PDU session / PDN connection, provided that a message is received from the network (e.g., a network entity) including any of the following: (1) a success indication (e.g., a successful C2 communication link update indication); (2) a new UAS id#2 (which identifies the second pair of the first UAV 211 and the second UAV-C 212 (e.g., UAV and UAV-C#2); and / or (3) a new UAV-C#2 IP.

[0126] Representative behavior of WTRU / UAV

[0127] WTRU / UAV 211 can exchange C2 traffic with a first UAV-C 212 (e.g., UAV-C#1) via a network connection. The first pair (e.g., UAV, UAV-C#1) can be identified as UAS id#1. WTRU may receive any of the following in a message from the network: (1) a success indication (e.g., a successful C2 communication link update indication); (2) a new UAS id#2; (3) a new peer UAV-C#2 IP address; and / or (4) a new UAV-C#2 id (e.g., PEI and / or MAC address) (e.g., via a procedure for updating PDU session / PDN connection and / or during a UCU procedure). Additionally or alternatively, WTRU may receive any of the following in a message from UTM 220 (e.g., a C2 communication update authorization message): (1) a new UAS id#2; (2) a new peer UAV-C#2 IP address; and / or (3) a new UAV-C#2 id. The WTRU can receive this message directly from the UTM 220 and / or via the UCF. The WTRU can participate in and communicate with peers of the UAV-C 212 (e.g., UAV-C#2) via a network connection (e.g., using the new UAV-C#2 IP).

[0128] Representative behaviors of UAV service networks

[0129] In some representative implementations, the network (e.g., network entities) may forward C2 traffic between a first pair (e.g., first UAV 211 and first UAV-C 212 (e.g., UAV-C#1)) via a network connection established as described herein. The first pair (e.g., UAV, UAV-C#1) may be identified as UAS id#1. The network (e.g., network entities) may receive any of the following in a message from UTM220 (e.g., a C2 communication update authorization message): (1) WTRU id; (2) UAS id#1; (3) old UAS id#1; (4) new UAS id#2; (5) new UAV-C#2 IP address; and / or (6) new UAV-C#2 id (e.g., PEI and / or MAC address, etc.). The network (e.g., a network entity) may update the connection, for example, to allow the exchange of C2 traffic (e.g., to / from the UAV-C#2 IP address / DN) between the first UAV 211 and the second UAV-C 212 (e.g., UAV-C#2), and / or block the exchange of C2 traffic between the first UAV 211 and the first UAV-C 212 (e.g., UAV-C#1). The network (e.g., a network entity) may send any of the following to the WTRU in a message: (1) a success indication (e.g., a successful C2 communication link update indication); (2) a new UAS id#2; (3) a new peer UAV-C#2 IP address; and / or (4) a new UAV-C#2 id (e.g., PEI and / or MAC address, etc.) (e.g., via a procedure for updating PDU session / PDN connection and / or during a UCU procedure). A network (e.g., a network entity) can forward C2 traffic between a first UAV 211 and a second UAV-C 212 (e.g., UAV-C#2) via a network connection.

[0130] Representative procedures for C2 communication link switching via UAV-C modification

[0131] WTRU / UAV 211 can participate in C2 communication with the first UAV-C#1 212 via the first network connection #1. The first pair of the first UAV 211 and the first UAV-C#1 212 can be identified by the identifier UAS id #1. WTRU / UAV 211 can establish a second connection (e.g., backup connection #2) for potential C2 communication link switching to another UAV-C 212 (e.g., UAV-C#2). The WTRU may participate in C2 communication with the second UAV-C 212 (e.g., UAV-C#2) upon receiving a message from the network (e.g., a network entity) during the update of the PDU session / PDN connection protocol for the second connection #2, the message including any of the following: (1) a success indication (e.g., a successful C2 communication link switching indication); (2) a new UAS id#2 (e.g., a second pair for identifying the first UAV 211 and the second UAV-C 212 (e.g., UAV-C#2); (3) the old UAS id#1; and the new UAV-C#2 IP.

[0132] The WTRU also receives instructions (e.g., one or more policies / rules) on how to handle existing connections. In some implementations, the instructions may specify maintaining connection #1 (e.g., as a backup, having a lower priority than connection #2). In this case, connection #1 may not be released and C2 packets may be exchanged via connection #2 (because connection #2 has a higher priority). The WTRU or the network may later set connection #1 with a higher priority and switch C2 traffic back to connection #1. In some examples, the WTRU may be requested to release connection #1 associated with UAV-C#1 / UAS id #1 based on the instructions (e.g., when an authorization for C2 communication with UAV-C#1 is invoked or under these conditions). The WTRU may receive a timer that controls when an old connection (e.g., connection #1) can be released.

[0133] Similar procedures can be used to switch the C2 communication path from UAV-UAV-C#1 (e.g., direct communication or network-assisted communication) to UAV-USS / UTM (UTM navigation communication). In this scenario, USS / UTM can serve a similar function to the new UAV-C 212 (UAV-C#2) (e.g., functional / operational).

[0134] Representative behavior of WTRU / UAV for C2 communication link switching (e.g., changes via UAV-C).

[0135] WTRU / UAV 211 can exchange C2 traffic with first UAV-C 212 (e.g., UAV-C#1) via a first network connection (e.g., network connection #1). The first pair of first UAV 211 and first UAV-C 212 (e.g., UAV, UAV-C#1) can be identified as UAS id #1. WTRU may have pre-established and / or backup connections as described herein (e.g., second network connection #2). In some embodiments, connection #1 may use a direct link (e.g., where a nearby UAV-C 212 uses a PC5 link).

[0136] The WTRU may receive any of the following in a message from the network (e.g., via a procedure for updating network connectivity (e.g., PDU session / PDN connection and / or network connection #2) and / or during a UCU procedure): (1) a success indication (e.g., a successful C2 communication link switch indication); (2) the old UAS id #1; (3) the new UAS id #2; (4) the new peer UAV-C#2 IP address (e.g., the USS / UTM IP address if C2 is switched to UTM navigation); and / or (5) the new UAV-C#2 id (e.g., PEI and / or MAC address) and / or (6) an indication of the communication type (e.g., direct, network-assisted, and / or UTM navigation, etc.) and an indication of how to handle the existing connection #1 (e.g., maintain or release the existing connection #1). Alternatively or in addition, the WTRU may receive any of the following in a message from UTM 220 (e.g., a C2 communication handover authorization message): (1) the old UAS id #1; (2) the UAS id #2; (3) the new peer UAV-C#2 IP address; and / or (4) the new UAV-C#2 id. The WTRU may receive messages directly from UTM 220 and / or via UCF. The WTRU may participate in (e.g., communicate with) C2 communication with peer UAV-C 212 (e.g., UAV-C#2) via a backup and / or second network connection (e.g., network connection #2). For a handover to direct C2 communication (e.g., to enable takeover by nearby law enforcement personnel), in addition to or in place of the above backup connection #2, UAV 211 may establish a direct link (connection #3) with UAV-C#2. The WTRU can be instructed to establish a direct link with the UAV-C#2 based on instructions and / or direct communication parameters received along with link switching instructions as described herein. In some examples, the WTRU may be provided with a strategy indicating which connection to use when switching connection types (towards direct only, direct + backup network assisted, backup network assisted only / from it).

[0137] Based on existing connection handling instructions (e.g., one or more policies / rules) from the network / USS / UTM 220 and / or connection release timer, the WTRU may release or maintain the first network connection (e.g., network connection #1). If connection #1 is maintained, the WTRU may send and receive C2 packets via connection #2. The WTRU may discard any packets received via connection #1. The WTRU may resume C2 communication via connection #1, for example, when the WTRU is instructed by a subsequent link switching command from the network (e.g., control is transferred / returned to the original UAV-C) or under these conditions.

[0138] Representative behavior of UAV service networks used for C2 communication link switching (e.g., changes via UAV-C).

[0139] A network (e.g., a network entity) may forward C2 traffic between UAV 211 and a first UAV-C 212 (e.g., UAV-C#1). The first pair (e.g., UAV, UAV-C#1) may be identified as UAS id#1. As described herein, a network (e.g., a network entity) may allocate resources for a second and / or backup network connection (e.g., network connection #2). The network (e.g., the network entity) may receive any of the following in a message from UTM 220 (e.g., a C2 communication update authorization message): (1) WTRU id; (2) UAS id#1; (3) old UAS id#1; (4) new UAS id#2; (5) new UAV-C#2 IP address (or USS / UTM IP address if C2 is switched to UTM navigation), and / or (6) new UAV-C#2 id (e.g., PEI and / or MAC address, etc.), an indication of the type of communication (e.g., network-assisted, UTM navigation), and an indication of how to handle the existing connection #1 (e.g., maintain, release).

[0140] The network (e.g., network entity) may update the second and / or backup network connections (e.g., PDU session / PDN connection and / or network connection #2) for example to allow the exchange of C2 traffic (e.g., to / from UAV-C#2 IP address / DN) between UAV 211 and the second UAV-C 212 (e.g., UAV-C#2), and may block the exchange of C2 traffic between UAV 211 and the first UAV-C 212 (e.g., UAV-C#1) for example through the first network connection (e.g., network connection #1). The network (e.g., a network entity) may send any of the following to the WTRU in a message: (1) a success indication (e.g., a successful C2 communication link switching indication); (2) a new UAS id #2, a new peer UAV-C#2 IP address; and / or (3) a new UAV-C#2 id (e.g., PEI and / or MAC address) (e.g., via a procedure for updating a second / backup network connection (e.g., a PDU session / PDN connection and / or network connection #2) or during a UCU procedure). The network (e.g., a network entity) may forward C2 traffic between UAV 211 and a second UAV-C 212 (e.g., UAV-C#2) via the second / backup network connection (e.g., network connection #2). The network may initiate the release of a first network connection (e.g., network connection #1). For example, the network may trigger the release of connection #1 based on an existing connection handling indication (e.g., one or more policies / rules) from the USS / UTM 220.

[0141] A representative procedure for C2 communication link updates (e.g., via changes to UAV / UAV-C IP addresses).

[0142] WTRU / UAV 211 may participate in C2 communication with UAV-C 212 (e.g., communicate with it). A network (e.g., a network entity) may determine / determine whether the WTRU will be or may be served by another User Plane Function (UPF) (e.g., due to WTRU / UAV mobility), such as its potential proximity to WTRU / UAV 211. WTRU / UAV 211 may obtain a new IP address associated with this new serving UPF.

[0143] In some representative implementations, apparatus, systems, and / or procedures for network-assisted UAV IP address changes can be implemented. For example, UAV-C 212 can use a new UAV IP address during C2 communication upon receiving a message from the network (e.g., a network entity) that includes information / indications (e.g., a C2 communication link update indication and / or a new UAV IP address, etc.). WTRU / UAV 211 can use a new UAV IP address during C2 communication upon receiving a message from the network (e.g., a network entity) that includes a success indication (e.g., a successful C2 communication link update indication), or subsequently.

[0144] Representative behavior of UAVs used for C2 communication link updates (e.g., via changes to UAV / UAV-C IP addresses).

[0145] The operation / behavior / action of WTRU / UAV 211 may include any of the following: (1) WTRU / UAV 211 obtains a new IP address; (2) WTRU / UAV 211 triggers a C2 communication link update toward UAV-C 212; (3) WTRU / UAV 211 receives an indication from the network that the C2 communication link update was successful; and / or (4) WTRU / UAV 211 begins to use a new IP address for C2 communication (e.g., its new IP address), etc.

[0146] The operation / behavior / action of UAV-C 212 may include any of the following: (1) UAV-C 212 receives an instruction from the network (e.g., a network entity) to update the C2 communication link with a new UAV IP address; (2) UAV-C 212 updates its internal C2 communication link information (e.g., its link information); (3) UAV-C 212 acknowledges receipt of the new IP address of UAV 211 and / or the C2 communication link update; and / or (4) UAV-C 212 begins using the new IP address of UAV 211 for C2 communication, etc.

[0147] The operation / behavior / action of the network (e.g., network entity) may include any of the following: (1) the network (e.g., network entity) receives a trigger from UAV 211 to update the C2 communication link with its new IP address (e.g., alternatively, the network (e.g., network entity) may trigger the update of the C2 communication link); (2) the network (e.g., network entity) sends information / instructions (e.g., connection modification instructions) of UAV 211 to UTM 220 (e.g., information may include the new IP address of UAV); and / or (3) the network (e.g., network entity) updates the internal state of the PDU session by authorizing C2 communication with UAV-C 212 when or after receiving a connection modification response (e.g., successful connection modification response) from UAV 211 from UTM 220; and / or (4) the network (e.g., network entity) sends an instruction to UAV, for example, to allow the use of a new IP address for C2 communication.

[0148] In some representative implementations, apparatus, systems, and / or procedures for network UTM-assisted UAV IP address changes can be implemented. For example, WTRU / UAV 211 may send an indication (e.g., a C2 communication link update indication) and / or a new UAV IP address to UTM 220. WTRU / UAV 211 and / or UTM 220 may send an indication to UAV-C 212. WTRU / UAV 211 may receive confirmation of a successful C2 communication link update. UAV 211 and UAV-C 212 may begin using the new IP address of WTRU / UAV 211 for C2 communication.

[0149] The operation / behavior / action of WTRU / UAV 211 may include any of the following: (1) WTRU / UAV 211 obtains a new IP address; (2) WTRU / UAV 211 sends a C2 communication link update to UTM 220 including the new IP address of WTRU / UAV 211; (3) WTRU / UAV 211 receives an indication from UTM 220 that the C2 communication link update was successful; and / or (4) WTRU / UAV 211 begins to use the new IP address of WTRU / UAV 211 for C2 communication, etc.

[0150] The operation / behavior / action of UAV-C 212 may include any of the following: (1) UAV-C 212 receives an instruction from UTM 220 or from UAV 211 to update the C2 communication link with the new IP address of UAV; (2) UAV-C 212 updates the internal C2 communication link information of UAV-C 212; (3) UAV-C 212 confirms the receipt of the new IP address of UAV 211 and / or the C2 communication link update; and / or (4) UAV-C 212 begins to use the new IP address of UAV 211 for C2 communication, etc.

[0151] The operation / behavior / action of UTM 220 may include any of the following: (1) UTM 220 receives an indication from UAV 211 to update the C2 communication link with the new IP address of UAV; (2) UTM 220 sends information / indications (e.g., C2 communication link update indication) to UAV-C 212 (e.g., the information may include the new IP address of UAV); and / or (3) UTM 220 sends an indication to UAV 211 to allow the use of the new IP address of UAV 211 for C2 communication, for example, when or after receiving a success indication (e.g., successful C2 communication link update indication) from UAV-C 212.

[0152] It is expected that UAV-C 212 can update the IP address of UAV-C 212, and technicians will understand that UAV-C 212 can use the same or similar procedures / mechanisms to update the C2 communication link with one or more peer UAVs of UAV-C 212.

[0153] Representative procedures for setting up UTM on C2 communication links (e.g., for UTM-based navigation).

[0154] In some representative implementations, UAV 211 and / or UAV-C 212 may pre-establish connectivity with a network (e.g., a network entity) for example, to enable C2 communication with UTM 220. WTRU / UAV 211 may, for example, send information / instructions (e.g., C2 communication instructions, via UTM-based navigation modes) to the network (e.g., a network entity) during a procedure for establishing a new PDU session / PDN connection, and may, for example, receive pending instructions (e.g., UAS association pending instructions) during the procedure. WTRU may, for example, participate in C2 communication with UTM 220 upon receiving a message from the network (e.g., a network entity) during a procedure for updating a PDU session / PDN connection, or thereafter, such message includes any of the following: (1) a success indication (e.g., a successful C2 communication link setup indication); (2) a UAS id; and / or (3) a UTM IP.

[0155] Those skilled in the art will understand that the network operation / behavior of WTRU / UAV 211 and the UTM setup for C2 communication links is the same as or similar to the procedures for C2 communication link setup with UAV-C 212 as described herein. Some differences are disclosed herein.

[0156] The operation / behavior / action of WTRU / UAV 211 may include any of the following: (1) WTRU / UAV 211 is authenticated and authorized by the network and / or UTM 220; (2) WTRU / UAV 211 establishes a backup network connection to establish C2 communication as described herein (e.g., during network connection establishment, WTRU may indicate that the connection is for C2 communication and may specify the type of C2 communication (e.g., UTM navigation)); (3) WTRU / UAV 211 receives any of the following in a message from the network (e.g., a network entity): a success indication (e.g., a successful C2 communication link setup indication), a UAS id, and / or a UTM IP address (e.g., additionally or alternatively, WTRU / UAV 211 may receive any of the following in a message from UTM 220 (e.g., a C2 communication authorization message): a UAS id, a UTM IP address, and / or a port number. WTRU may receive this information directly from the UTM). 220 and / or receive messages via UCF); and / or (4) WTRU / UAV 211 participates in C2 communication with UTM 220 (e.g., communicates with it).

[0157] The operation / behavior / action of the UAV 211 service network may include any of the following: (1) the network (e.g., a network entity) authenticates and / or authorizes the UAV 211 via UTM 220; (2) the network (e.g., a network entity) allocates resources for a second and / or backup connection as described herein; (3) the network (e.g., a network entity) receives WTRUid, indication (e.g., C2 communication indication (e.g., for UTM navigation)), UAS id, UTM IP address and / or port number in a message from UTM 220, etc.; (4) the network (e.g., a network entity) updates the PDU session / PDN connection, for example, to allow the exchange of C2 traffic (e.g., to / from UTM IP address / DN); (5) the network (e.g., a network entity) sends any of the following to WTRU / UAV 211 in a message: a success indication (e.g., a successful C2 communication link setup indication) and / or UTM IP address; and / or (6) the network (e.g., a network entity) connects UAV 211 with UAV-C Sending or forwarding C2 traffic between 212, etc.

[0158] In some representative implementations, procedures, apparatus, and / or systems for navigation by UAV-C 212 can be implemented. For example, UAV-C ID and / or UAV ID can be transmitted to a USS / UTM as described herein, and the USS / UTM may not provide / expose peer UAV-C IP addresses and / or UAV IP addresses to WTRU / UAV 211. A USS and / or UTM 220 (e.g., which may act as an application server) can forward (e.g., explicitly forward / send) traffic between UAV 211 and UAV-C 212. The USS / UTM can implement changes (e.g., explicit changes) from UAV-C 212 to UAV 211, changes (e.g., explicit changes) to the UAV IP address of the corresponding UAV-C 212, and / or changes (e.g., explicit changes) to the UAV-C IP address of the corresponding UAV 211.

[0159] Representative procedures for C2 communication links with UAV-C settings (e.g., using the same PLMN)

[0160] Those skilled in the art will understand that the operation / behavior / actions of the WTRU / UAV 211 and / or network are the same as or similar to those of other C2 communication link setup procedures using / via the UAV-C 212 described herein. Some differences may include the fact that the network (e.g., network entity) may not need to / expose the UAV IP / MAC address and / or UAV-C IP / MAC address to the UTM 220, for example, to enable the UAV 211 and UAV-C 212 to establish a C2 communication link with each other.

[0161] The operation / behavior / action of the UAV service network may include any of the following: (1) the network (e.g., a network entity) authenticates and / or authorizes the WTRU (as a UAV) and / or the corresponding UAV-C 212 via UTM 220; (2) the network (e.g., a network entity) allocates resources for the UAV 211 and / or the corresponding UAV-C 212 for a second / backup connection, as described herein; (3) the network receives the UAS id, UAV WTRU id, and / or UAV-C WTRU id in a message from UTM 220 (e.g., the network may select an available second / backup PDU session / PDN connection for C2 communication with the UAV-C / corresponding UAV. The network may update the PDU session / PDN connection, for example, to allow the exchange of C2 traffic with the UAV-C / corresponding UAV); (4) the network sends any of the following to the UAV / corresponding UAV-C in a message: a success indication (e.g., a successful C2 communication link setup indication), the UAV-C IP address, and / or the corresponding UAV. IP address; and / or (5) the network forwards / sends C2 traffic between UAV 211 and UAV-C 212.

[0162] Representative procedures for C2 communication path switching (e.g., from direct to network-assisted or from network-assisted to direct).

[0163] UAV 211 may be authorized for UAV operation by the USS / UTM via a network (e.g., a network entity and / or UCF). During or after the UAV authorization procedure, UAV 211 may receive from the network (e.g., a network entity) and / or the USS one or more parameters that allow UAV 211 to establish C2 communication with UAV-C 212. The parameters may include any of the following: (1) one or more USS-assigned identities (e.g., one or more UAS IDs and / or one or more CAA-level UAV IDs, etc.), (2) one or more UAV-C identities (e.g., one or more WTRU IDs and / or one or more IP addresses, etc.), (3) one or more types of C2 communication that UAV 211 is authorized or may be authorized to use (e.g., direct type, network-assisted type, and / or UTM navigation type, etc.) and an indication of whether redundant C2 connections are permitted, preferred, and / or required / used.

[0164] UAV 211 can use received parameters (e.g., UAS id and / or UAV-C WTRU id, etc.) to discover and / or establish a direct link with UAV-C 212 (e.g., via PC5 or another direct link using another radio access technology (e.g., Bluetooth and / or WiFi, etc.)) for direct C2 communication. In some representative embodiments, UAV 211 can establish a PDU session for candidate network-assisted C2 communication based on the permitted types of C2 communication and redundant C2 connection policies / rules. UAV 211 and UAV-C 212 can notify each other via a direct link or a network-assisted link (e.g., whichever link is established first) whether the other has a ready candidate (e.g., redundant) network connection. Additionally or alternatively, UAV 211 and UAV-C 212 can negotiate via a direct link or a network-assisted link whether to establish a candidate network connection based on one or more of their respective redundant C2 connection policies. During or after the establishment of a direct link, UAV 211 and UAV-C212 may exchange and / or negotiate one or more QoS parameters, including C2 communication thresholds associated with the quality of the direct link (e.g., range and / or distance limits, latency, packet loss, signal strength, etc.).

[0165] During direct C2 communication, if the UAV / UAV-C detects that the direct link quality has decreased below a threshold / limit based on one or more of these thresholds being crossed (e.g., UAV 211 can move beyond a given range), the UAV / UAV-C may switch the C2 communication path from direct to network-assisted (e.g., subsequent C2 packets can be transmitted / received via Uu instead of PC5). During network-assisted C2 communication, if UAV 211 and / or UAV-C detects an improvement in direct link quality (e.g., based on one or more C2 communication thresholds), such as if UAV 211 moves back within the range limit, UAV 211 and / or UAV-C 212 may switch the C2 communication path from network-assisted back to direct. When UAV 211 and / or UAV-C 212 determines to switch the C2 communication path, UAV 211 or UAV-C 212 may notify its peer of the determination / decision, allowing the peer to switch the C2 communication path accordingly. If a switching notification is lost on its current communication path (e.g., a direct link), and the peer receives a C2 message from another path (e.g., a backup / redundant network connection), the peer can determine that the communication path has been switched. UAV 211 and / or UAV-C 212 can notify the USS / UTM when the C2 communication path has been switched to direct or network-assisted (e.g., via higher-layer messaging and / or application-layer messaging). This notification information can be used by the USS / UTM to determine whether the current communication path allows UAV 211 to operate in BVLOS.

[0166] In some representative implementations, the WTRU can use NAS messages to communicate with core network functions (NFs). Examples of such core NFs are the AMF / SMF in the 5GC and the MME / PGW-C in the EPC. Core NFs can communicate with the UTM 220 via the UCF or Network Exposure Function (NEF) and / or UPF in the 5GC, and via the Policy and Charging Rules Function (PCRF) in the EPC. For example, the UAV 211 can be connected via a PLMN. The UAV-C 212 can be connected via the same or a different PLMN or not at all (e.g., using a terrestrial line).

[0167] Figure 3A This diagram illustrates the procedure for selecting the initial C2 communication mode, which uses WTRU (UAE-C, as a UAS application enabler client) assisted by network entity policies (e.g., USS / UTM 220) and network control (UAE-S 221, as a UAS application enabler server). The selected initial C2 communication mode can be direct or indirect (e.g., network-assisted). Reference Figure 3A For illustrative purposes, direct C2 communication is selected first.

[0168] At Operation 3A-1a, the WTRU (e.g., UAV) may have already been authorized by a network entity (e.g., USS / UTM 220). At Operation 3A-1b, the WTRU (e.g., UAV-C 212) may have already been authorized by a network entity (e.g., USS / UTM 220). Both direct and indirect links can be used for C2 communication.

[0169] At Operation 3A-2a, the WTRU (e.g., UAV) may receive C2 communication link selection and handover policies (e.g., via the UAS Application Enabler (UAE) layer) from a network entity (e.g., USS / UTM 220). At Operation 3A-2b, the WTRU (e.g., UAV-C 212) may receive C2 communication link selection and handover policies (e.g., via the UAE layer) from a network entity (e.g., USS / UTM 220). The content of the policies may be as described herein.

[0170] At operations 3A-3a, the WTRU (e.g., UAV) can select the primary communication mode based on the C2 communication link selection and switching policy. At operations 3A-3b, the WTRU (e.g., UAV-C 212) can select the primary communication mode based on the C2 communication link selection and switching policy.

[0171] At Operation 3A-4, the WTRU (e.g., UAV 211 and / or UAV-C 212) may negotiate with its peers (e.g., via the primary link): using redundant C2 links and / or C2 link QoS thresholds as described herein based on the received policy.

[0172] At operations 3A-5a, the WTRU (e.g., UAV) may notify the network entity (e.g., USS / UTM 220) of the current active C2 communication mode (e.g., via the UAE layer). At operations 3A-5b, the WTRU (e.g., UAV-C 212) may notify the network entity (e.g., USS / UTM 220) of the current active C2 communication mode (e.g., via the UAE layer).

[0173] At Operation 3A-6, the WTRU (e.g., UAV 211 or / and UAV-C 212) can perform C2 communication with its peer (e.g., directly or indirectly) while monitoring the current C2 link for negotiated QoS thresholds for C2 handover.

[0174] Figure 3BThis diagram illustrates the procedure for C2 communication mode switching, which uses UE (UAE-C, as a UAS application enabler client) to assist network (UAE-S 221, as a UAS application enabler server) control based on network entity (e.g., USS / UTM220) policies. The UAE layer (UAE-C and UAE-S) provides an adaptation layer for the application layer, acting as UAE-C on the WTRU side and as UAE-S on the server side. (Reference) Figure 3B For illustrative purposes, the initial mode of C2 communication chosen is direct, and the WTRU switches to indirect mode for C2 communication. It should be understood that a reverse scenario (e.g., indirect to direct) is also possible using similar steps.

[0175] In Operation 3B-0, the WTRU (e.g., UAV 211 and / or UAV-C 212) can perform C2 communication (e.g., directly) with its peer.

[0176] At Operation 3B-1, the WTRU (e.g., UAV 211 and / or UAV-C 212) can detect that C2 handover conditions are met on the current C2 link, such as based on C2 link QoS threshold parameters (e.g., low signal strength) for UAV 211 to switch to another C2 communication mode (e.g., indirect).

[0177] At Operation 3B-2, the WTRU (e.g., UAV 211 and / or UAV-C 212) may send a request message to the UAS server (e.g., via the UAE layer) to perform a C2 mode handover. The request message may include information related to the handover conditions / context, such as the current C2 link QoS parameters, the target C2 link, and / or QoS parameters.

[0178] At Operation 3B-3, the UAS server can check / determine whether the WTRU (e.g., UAV 211 and / or UAV-C 212) is authorized to switch to the target C2 link based on the network entity (e.g., USS / UTM 220) policy and C2 link QoS parameters received from the WTRU.

[0179] At Operation 3B-4, the UAS server can send a response message to the WTRU (e.g., UAV 211 and / or UAV-C 212) authorizing or denying the C2 mode switch.

[0180] At Operation 3B-5, if authorized by the UAS server, the WTRU (e.g., UAV 211 and / or UAV-C 212) may notify its peers (e.g., via the UAE layer) of the switch to the new Activity C2 communication mode.

[0181] At Operation 3B-6, the WTRU (e.g., UAV 211 and / or UAV-C 212) may notify network entities (e.g., USS / UTM 220) of new activity C2 communication modes (e.g., via the UAE layer).

[0182] At Operation 3B-7, the WTRU (UAV 211 and / or UAV-C 212) can be switched to target C2 communication mode (e.g., network-assisted mode).

[0183] In some representative implementations, after a C2 communication switch in one direction, the WTRU (e.g., UAV 211 and / or UAV-C 212) may decide / determine to perform a switchback back to the original C2 communication mode, provided that its quality meets one or more negotiated C2 communication QoS thresholds after a similar procedure as described above.

[0184] Representative procedures for C2 communication links with UAV-C setup (e.g., using on-demand connectivity).

[0185] Figure 3C This is a diagram illustrating the protocol for a C2 communication link with UAV-C settings established using on-demand network connectivity. (Reference) Figure 3C The procedures may include, at operation 3C-1a, WTRU / UAV 211 performing network-assisted UAV authentication and / or authorization via and / or using UTM procedures. Similarly, at operation 3C-1b, UAV-C 212 may be network-assisted authenticated and / or authorized by UTM 220. For each of UAV 211 and UAV-C 212, UTM 220 may maintain a context that may include the UAV and UAV-C identities (e.g., their respective identities, such as UAV id, UAV WTRU id, UAV-C id, and / or UAV-C WTRU id, etc.). At operation 3C-2, UAV-C 212 may send a request message to UTM 220 for association with the UAV, for example, to establish C2 communication. The request message may include an identifier of the target UAV 211 (e.g., UAV id). In some implementations, UAVId may be provided to USS / UTM 220 earlier (e.g., during authentication and / or authorization of UTM 220, if available). In this case, the message may be skipped, and / or USS / UTM 220 may perform pairing authorization based on internal logic and / or different triggers. For example, USS / UTM 220 may detect when both UAV 211 and UAV-C 212 become online and / or ready for operation (e.g., sufficient battery level), etc.

[0186] UAV-C 212 may send messages to UTM 220 directly via the user plane or via UCF, or UAV-C 212 may send requests in NAS messages (e.g., UAV information containers, which may include UAV-related information placed and / or embedded in NAS messages), which may be forwarded to UCF by AMF. UCF can locate UTM / USS 220 and may forward requests to UTM / USS 220. When UAV-C 212 sends a request via UCF, UAV-C 212 may provide both its own UAV identifier and / or the target UAV identifier. The operations, methods, and manners described herein for how UAV / UAV-C can communicate with UTM 220 are equally applicable to other operations, methods, and manners of communication in this and other representative embodiments disclosed herein.

[0187] At Operation 3C-3, UTM 220 can check whether UAV-C 212 is authorized to be associated with or control UAV 211 identified by the UAV ID. For example, UTM 220 can check that the UAV ID requested by UAV-C 212 corresponds to UAV 211, that the UAV is authorized / available, and that its owner / pilot certificate matches the owner / user certificate of UAV-C 212. Upon successful authorization, USS / UTM 220 can assign a new UAS ID associated with UAV 211 and UAV-C 212. The UAS ID can be used as a remote ID, for example, for identification and / or tracking. The UAS ID may include the identity of the assigning entity (e.g., a specific USS) and may randomize the identity, for example, to preserve UAV operator / pilot privacy. For example, the UAS ID may be assigned as "random number@USS domain name".

[0188] At Operation 3C-4a, UTM 220 may send a message to UAV service PLMN 301a (e.g., PLMN1) that may include the UAV WTRU id and / or UAS id, which may identify the authorized UAS association if UAV-C 212 is connected via the PLMN. At Operation 3C-4b, UTM 220 may send a notification message (e.g., the same or similar notification message) to UAV-C service PLMN 301b (e.g., PLMN2) that may include the UAV-C WTRU id and / or UAS id. For example, in a representative 5GC deployment, messages may be forwarded / sent to the service AMF of WTRU / UAV 211 and / or UAV-C 212 via NEF or UCF and / or via SMF using an existing N4 session with UTM 220 (e.g., using an N4 session that may be established during Operation 3C-1).

[0189] At Operation 3C-5a, the NF (e.g., AMF or MME) in the service PLMN 301a of UAV 211 may update the context (e.g., WTRU / UAV context), for example, to authorize a UAS association identified by the UAS id. At Operation 3C-5b, the service PLMN 301b of UAV-C 212 (if any) may perform the same or similar procedures as UAV-C 212 (e.g., to perform a context update). At Operations 3C-6a and / or 3C-6b, UTM 220 may send one or more messages to UAV 211 and / or UAV-C 212, which may include a UAS id identifying the authorized UAS association.

[0190] At Operation 3C-7a, WTRU / UAV 211 may establish a PDU session / PDN connection with the service PLMN 301a (e.g., AMF / SMF) of WTRU / UAV. WTRU / UAV 211 may send the UAS ID to the service PLMN 301a of WTRU / UAV 211 during a procedure (e.g., in a PDU session establishment request message). WTRU may receive indications (e.g., UAS association pending indications) from the service PLMN 301a (e.g., AMF / SMF) during a procedure (e.g., in a PDU session establishment accept message). At Operation 3C-7b, UAV-C 212 may execute the same or similar procedures as its PLMN 301b (if any).

[0191] At Operation 3C-8a, UAV Service PLMN 301a may send a message to UTM 220 in response to or after one or more messages in Operation 3C-4a. The message may include any of the following: (1) UAV WTRU id; (2) UAS id; and / or (3) UAV IP / MAC address. UAV Service PLMN 301a may also provide location information (e.g., takeoff location) for UAV 211 at this time. Location tracking may be initiated during or after UAV authentication and authorization at USS / UTM 220. At Operation 3C-8b, UAV-C Service PLMN 301b (if any) may perform the same or similar procedures, and UAV-C Service PLMN 301b may send a message to UTM 220 in response to or after one or more messages in Operation 3C-4b. The message may include any of the following: (1) UAV-C WTRU id; (2) UAS id; and / or (3) UAV-C IP / MAC address. At Operation 3C-9, the UTM 220 can update the UAV context via the peer UAV-C address, and the contexts can be linked together via UAS associations identified by the UAS id. The UTM 220 can update the corresponding UAV-C context via the UAV address, and the contexts can be linked together via UAS associations identified by the UAS id.

[0192] At Operation 3C-10a, UTM 220 may send a message to UAV service PLMN 301a, which may include any of the following: (1) UAV WTRU id; (2) UAS id; and / or (3) UAV-C IP / MAC address, for example, to authorize C2 communication. At Operation 3C-10b, UTM 220 may send a notification message (e.g., the same or similar notification message) to UAV-C service PLMN 301b (if any), which may include any of the following: (1) UAV-C WTRU id; (2) UASid; and / or (3) UAV IP / MAC address. UAV service PLMN 301a may trigger modifications to the PDU session / PDN connection established in Operations 3C-7a and / or 3C-7b.

[0193] At Operation 3C-11a, WTRU / UAV 211 may receive either: (1) a success indication (e.g., a successful C2 communication indication); and / or (2) the UAV-C IP / MAC address of service PLMN 301a of WTRU / UAV 211 during a procedure (e.g., in a PDU session command message). At Operation 3C-11b, UAV-C service PLMN 301b (if any) may perform the same or similar procedures as UAV-C 212. At Operation 3C-12a, UAV service PLMN 301a may respond to the message in Operation 3C-10a and / or subsequently send a message to UTM 220. At Operation 3C-12a, UAV-C service PLMN 301b may respond to the message in Operation 3C-10b and / or subsequently send the same or similar message to UTM 220.

[0194] At Operation 3C-13a, UTM 220 may send a message to WTRU / UAV 211, which may include any of the following: (1) UAS id; and / or (2) UAV-C IP / MAC address, for example, for authorizing C2 communication. At Operation 3C-13b, UTM 220 may send the same or similar notification message to UAV-C 212, which may include any of the following: (1) UAS id; and / or (2) UAV IP / MAC address, etc. At Operation 3C-14, UAV 211 and UAV-C 212 may exchange C2 traffic.

[0195] Representative procedures for C2 communication links with UAV-C settings (e.g., using pre-established connectivity).

[0196] Figure 4 This is a diagram illustrating a representative procedure for a C2 communication link with UAV-C settings, for example, using pre-established network connectivity. (Reference) Figure 4Representative procedures may include, at operations 4-1a and 4-1b, the UAV / UAV-C performing network-assisted authentication and / or authorization via UTM procedures as described herein. At operation 4-2a, WTRU / UAV 211 may trigger the establishment of a PDU session / PDN connection with the WTRU / UAV's serving PLMN 301a (e.g., PLMN1), for example, to establish C2 communication. For example, WTRU / UAV 211 may send a PDU session establishment request message to the WTRU / UAV's serving PLMN 301a, which includes either: (1) an indication (e.g., a C2 communication indication); and / or (2) a UAV id, etc. At operation 4-2b, UAV-C 212 may perform the same or similar procedures as those of UAV-C 212's PLMN 301b (e.g., PLMN2, if any). At operation 4-3a, PLMN1 301a may register the PDU session IP address with UTM 220. PLMN1 301a may send a message that may include any of the following: UAV WTRU id, PDU session IP address, UAV id, and / or UAV current location, etc. The message may be sent after operation 4-2a (e.g., after the PDU session IP address is assigned on the user plane). At operation 4-3b, PLMN2 301b (if any) may perform the same or similar procedures (e.g., may send UAV-C WTRU id instead of UAV WTRU id and / or send UAV-C id instead of UAV id). At operation 4-4a, PLMN1 301a may send a PDU session establishment accept message to WTRU / UAV211 that may include a pending indication (e.g., a pending UAS association indication). At operation 4-4b, PLMN 2 301b (if available) may perform the same or similar procedures as UAV-C 212.

[0197] At operations 4-5, UTM 220 may perform authorization for the UAS association and / or allocate a new UAS id based on internal logic and / or based on a UAV-C / UAV request as described herein. At operations 4-6a, UTM 220 may send a message to PLMN1 301a, for example, to authorize C2 communication. The message may include any of the following: (1) UAV WTRU id; (2) UAS id, for example, to identify the authorized UAS association; (3) UAV-C IP address; and / or (4) UAV-C id. At operations 4-6b, UTM 220 may send a message to PLMN2 301b (if any) that may include any of the following: (1) UAV-C WTRU id, (2) UAS id, for example, to identify the authorized UAS association, (3) UAV IP address, and / or (4) UAV id.

[0198] At operations 4-7a and 4-7b, PLMN1 / PLMN2 301 may trigger modifications to the PDU session / PDN connection established at operations 4-2a and 4-2b. Modification commands may include any of the following: (1) a success indication (e.g., a successful C2 communication link setup indication); (2) a UAS id; (3) a peer UAV-C IP address; (4) a UAV-C id; and / or (5) a peer UAV IP address, etc. PLMN1 / PLMN2 301 may modify data forwarding rules in the UP gateway or function, for example, to ensure that authorized C2 traffic can or will be routed to / from the peer device of PLMN1 / PLMN2 301.

[0199] At operations 4-8a and 4-8b, PLMN1 / PLMN2 301 may send a message to UTM 220 in response to and / or after the messages in operations 4-6a and 4-6b to acknowledge these messages. At operation 4-9a, UTM 220 may send a message to WTRU / UAV 211 that may include any of the following: (1) UAS id; (2) UAV-C id; and / or (3) UAV-C IP / MAC address, for example, to authorize C2 communication, etc. At operation 4-9b, UTM 220 may send the same or similar notification message to UAV-C 212 that may include any of the following: (1) UAS id, (2) UAV WTRU id, and / or (3) UAVIP / MAC address, etc. At operation 4-10, UAV 211 and UAV-C 212 may exchange C2 traffic.

[0200] Representative procedures for C2 communication link updates (e.g., changes via UAV-C).

[0201] Figure 5This is a diagram illustrating the procedure for updating the C2 communication link triggered by a change in UAV-C 212. (Reference) Figure 5 Representative procedures may include, at operations 5-0a and 5-0b, WTRU / UAV 211 exchanging C2 traffic with a first UAV-C 212a (e.g., UAV-C#1) via a network connection. This pair of UAVs, UAV-C#1, may be identified as UAS ID #1. A second UAV-C 212b (e.g., UAV-C#2) may have already performed authentication and / or authorization via UTM procedures as described herein (e.g., assisted by PLMN2 301b). At operation 5-1, the second UAV-C 212b may send a request message to UTM 220 for association with the WTRU / UAV, for example, to establish C2 communication (e.g., due to emergency takeover). The request message may include the target UAV ID.

[0202] At operation 5-2, UTM 220 can check that UAV-C 212b (e.g., UAV-C#2) is authorized to control UAV 211 (e.g., UAV-C operated by law enforcement or otherwise) identified by the UAV ID. UTM 220 can assign a new UAS ID#2 associated with UAV 211 and UAV-C#2 212b upon or after successful authorization.

[0203] At operation 5-3a, UTM 220 may send a message to the first PLMN 301a (e.g., PLMN1) that authorizes C2 communication and may include any of the following: (1) UAV WTRU id; (2) old UAS id#1; (3) new UAS id#2; (4) PDU session IP; (5) UAV-C#2 IP / MAC address; and / or (6) UAV-C#2 id, etc. At operation 5-3b, UTM 220 may send the same or similar notification message to the second PLMN 301b (e.g., PLMN2) (if any), which may include any of the following: (1) UAV-C#2 WTRU id; (2) UAS id#2; (3) PDU session IP; (4) UAV IP / MAC address; and / or (5) UAV id, etc. At operation 5-4a, PLMN1 301a may trigger modifications to the PDU session / PDN connection for C2 communication with UAV-C#1 212a (e.g., established at operations 5-0a and 5-0b). WTRU / UAV 211 may receive any of the following from the first PLMN 301a (e.g., PLMN1) during the procedure (e.g., in a PDU session command message): (1) a success indication (e.g., a successful C2 communication update indication); (2) the UAV-C#2 IP / MAC address; and / or (3) the UAS id#2. At operation 5-4b, the second PLMN 301b (e.g., PLMN2) (if any) may execute the same or similar procedure as UAV-C#2 212b. The WTRU (e.g., the WTRU associated with UAV-C#2 212b) may receive any of the following from the second PLMN 301b (e.g., PLMN2) during the procedure: (1) a success indication (e.g., a successful C2 communication authorization indication); (2) the UAV IP / MAC address; and / or (3) the UAS id#2. At operations 5-5a and 5-5b, PLMN1 / PLMN2 301 may send a message to UTM 220 in response to and / or after the messages in operations 5-3a and 5-3b to acknowledge those messages.

[0204] At operations 5-6, UTM 220 may send a message to the UAV authorizing C2 communication and / or may include any of the following: (1) UAS id#2; and / or (2) UAV-C#2 IP / MAC address, etc. At operations 5-7, UTM 220 may send a message to UAV-C 212b authorizing C2 communication and / or may include any of the following: (1) UAS id#2; and / or (2) UAV IP / MAC address (e.g., in response to or after the message in operation 5-1). At operations 5-8, WTRU / UAV 211 may participate in C2 communication with the new peer UAV-C#2 212b via a network connection (e.g., using the new UAV-C#2 IP).

[0205] Figure 6 This is a diagram illustrating a representative procedure for the revocation of C2 communication authorization for a first UAV-C 212a (e.g., UAV-C#1) in the context of a change in UAV-C (e.g., via takeover by a higher-priority second UAV-C 212b (e.g., UAV-C#2)). Reference Figure 6 The procedure may include, at operation 6-0, WTRU / UAV 211 exchanging C2 traffic with first UAV-C 212a via a network connection. This pair of UAVs, 211 and first UAV-C#1 212a, may be identified by a UAS ID (e.g., UAS ID #1). At operation 6-1, UTM 220 may determine that second UAV-C#2 212b is authorized to take over control of UAV 211 identified by the UAV ID (e.g., by law enforcement or a UAV-C operated in another manner). UTM 220 may assign a new UAS ID #2 associated with UAV 211 and second UAV-C#2 212b upon successful authorization or thereafter.

[0206] At Operation 6-2, the UAV, UTM 220, PLMN1 301a, and UAV-C#2 212b (which may or may not be served by the PLMN) may execute the C2 communication link update / switching procedure as described herein. At Operation 6-3a, the WTRU / UAV 211 may participate in C2 communication with the new peer UAV-C#2 212b. At Operation 6-3b, the UTM 220 may send a message to the UAV-C#1 serving PLMN 301b (if any) (e.g., PLMN#2) that may revoke authorization for C2 communication and / or may include any of the following: (1) UAS id#1; (2) UAV-C#1 WTRU id; (3) PDU session IP address; and / or (4) change instruction (e.g., UAV-C change instruction). At operation 6-4, PLMN2 301b may release the PDU session, thereby providing a reason for the authorization revocation and / or failure of C2 communication. In some representative embodiments, PLMN2 301b may trigger modification of the PDU session / PDN connection used for C2 communication with UAV 211 (e.g., established at operation 6-0). WTRU (e.g., associated with UAV-C#1 212a) may receive a release indication (e.g., a C2 communication release indication) from PLMN2 301b during the procedure (e.g., in a PDU session modification command message). WTRU may delete / remove stored information (e.g., any stored, authorized C2-related information, such as UAS id, UAV address, and / or UAV id, etc.). At operation 6-5, UTM 220 may send a message that may include UAS id#1 to the first UAV-C 212a (e.g., UAV-C#1), for example, to revoke the authorization for C2 communication with the UAV.

[0207] Representative procedures for C2 communication link switching (e.g., via UAV-C changes).

[0208] Figure 7This is a diagram illustrating a representative procedure for a C2 communication link handover triggered, for example, by a change in UAV-C 212. At Operation 7-0b, WTRU / UAV 211 may establish, or may have already established, a first PDU session (e.g., PDU session #1) and a second and / or backup PDU session (e.g., PDU session #2) for C2 communication. In some examples, if PDU session #1 is established using Session and Service Continuity (SSC) mode 3, WTRU / UAV 211 may or may not establish a second / backup PDU session #2 at that time. WTRU / UAV 211 may determine to establish a second / backup PDU session using SSC mode 3 or to establish an initial PDU session, for example, to enable a “connect-then-disconnect” handover for C2 communication with another UAV-C 212. This determination may be performed based on UAV application requirements that necessitate establishment on a per UAV, per flight, and / or mission type basis. During earlier UAV authentication and authorization or C2 pairing / communication authorization operations, such application requests may be transmitted to the network and UAV 211 by the USS / UTM 220. At operation 7-0c, WTRU / UAV 211 may exchange C2 traffic with the first UAV-C 212a (e.g., UAV-C#1) via a network connection (e.g., first PDU session #1). This pair of UAVs 211 and the first UAV-C#1 212a may be identified by a UAS ID (e.g., UAS ID #1). At operation 7-0a, the second UAV-C 212b (e.g., UAV-C#2) may have already performed authentication and / or authorization via UTM procedures as described herein (e.g., assisted by the second PLMN 301b (e.g., PLMN#2)).

[0209] refer to Figure 7A representative procedure may include, at operation 7-1, UTM 220 receiving a request message from a second UAV-C 212b (e.g., UAV-C#2) for association with a UAV, such as to establish C2 communication. The request message may include an identifier (e.g., UAV id) of the target UAV 211. At operation 7-2, UTM 220 may check that the second UAV-C 212b is authorized to associate with or control UAV 211 identified by the UAV id. UTM 220 may assign a new UAS id#2 to UAV 211 and the second UAV-C#2 212b upon successful authorization or thereafter. At operation 7-3a, UTM 220 may send an authorization notification message to the UAV's service PLMN301a. The authorization notification message may include any of the following: (1) an indication that the UAV-C is to be switched; (2) the UAV WTRU id; (3) the old UAS id#1; (4) the new UAS id#2; (5) the IP of PDU session #1; (6) the IP of PDU session #2; (7) the UAV-C#2 id and / or (8) the IP of the second UAV-C#2, etc. At operation 7-3b, if the second UAV-C#2 212b is connected via PLMN 301b (e.g., PLMN2), then UTM 220 may send the same or similar notification message to the service PLMN 301b of the second UAV-C#2 212b, which may include any of the following: (1) UAV-C WTRU id; (2) UAV's PDU session #2; (3) UAS id #2; (4) UAV's IP / MAC address; and / or (5) UAV id, etc.

[0210] At operation 7-4a, the first PLMN 301a (e.g., PLMN1) may initiate a modification of the PDU session / PDN connection #2. The modification command may include any of the following: (1) a handover indication (e.g., a C2 handover indication); (2) UAS id #2; and / or (3) the UAV-C#2 IP / MAC address, etc. At operation 7-4b, the second PLMN 301b (e.g., PLMN2) may modify the PDU session of UAV-C#2212b for C2 communication. The modification command may include any of the following: (1) an authorization indication (e.g., a C2 authorization indication); (2) UAS id #2; and / or (3) the UAV IP / MAC address, etc. If PDU session #2 is not yet available, and PDU session #1 supports SSC mode 3, PLMN1 301a may initiate a PDU session modification procedure for PDU session #1 to trigger the establishment of the second PDU session #2. PLMN1 301a can specify the remaining lifetime of PDU session #1. At operation 7-5, PLMN1 301a can confirm the authorization notification in operation 7-3a. At operation 7-6a, UTM 220 can send a message to UAV 211 that may include any of the following: (1) UAS id #2; and / or (2) the IP / MAC address of UAV-C#2 authorized for C2 communication. UTM 220 can instruct UAV 211 that it may, should, or will begin using the IP / MAC address of PDU session #2 for C2 communication. At operation 7-6b, UTM 220 can send the same or similar notification message to a second UAV-C#2 212b, which may include any of the following: (1) UAS id #2; and / or (2) the UAV IP / MAC address, etc.

[0211] At operation 7-7, UAV 211 and UAV-C#2 212b can exchange C2 traffic via a new connection. At operation 7-8, the second UAV-C#2 212b can confirm the authorization notification in operation 7-6b. The confirmation message may include UAS id#2. At operation 7-9, UTM 220 can send an authorization revocation message to PLMN1 301a. The authorization revocation message may include any of the following: (1) a handover indication (e.g., a UAV-C handover indication); (2) the UAV WTRU id; (3) the IP of PDU session #1; and / or (4) UAS id#1, etc. At operation 7-10a, PLMN1 301a can release or update PDU session #1. If PLMN1 301a has specified the remaining lifetime of PDU session #1, UAV 211 may release PDU session #1 after the remaining lifetime has expired, and PLMN1 301a may not (e.g., need to) explicitly release the UAV. At operation 7-10b, UTM 220 may revoke the authorization for UAV-C#1 212a, for example, as... Figure 6 As described in [the text].

[0212] A representative procedure for C2 communication link updates (e.g., via changes to UAV / UAV-C IP addresses).

[0213] In some representative implementations, procedures, apparatus, and systems can be implemented for C2 communication link updates triggered by changes in UAV IP address / UAV-C IP address.

[0214] Representative procedures for network-assisted UAV-C modification of IP addresses

[0215] The allocation of a new UPF to a WTRU / UAV211 with an existing PDU session (e.g., in motion) can be handled differently depending on the PDU session type. In the first example, the existing PDU session can be terminated and a new PDU session can be established via the newly selected UPF. In another example, the existing PDU session can be updated with a new IP / MAC address, which can be associated with the new UPF.

[0216] Figure 8 This is a diagram illustrating a representative procedure for C2 communication involving updates via a new IP address (e.g., to establish a new PDU session). Reference Figure 8Representative procedures may include, at operation 8-1a, UAV 211 establishing a PDU session via the network, and at operation 8-1b, UAV-C 212 establishing a PDU session via the same PLMN or a different PLMN. At operation 8-1c, UAV 211 may exchange C2 traffic with UAV-C 212 via a network connection (e.g., a C2 communication link). UAV 211 and UAV-C 212 may each use their peer's IP address for C2 communication. At operation 8-2, the network (e.g., a network entity) may determine that the service UPF and / or SMF may (e.g., need to) be changed (e.g., due to WTRU / UAV mobility). The network (e.g., a network entity) may notify WTRU / UAV 211 by sending a PDU session modification command message. At operation 8-3, UAV 211 may establish a new PDU session as indicated by the network and may obtain a new IP address / prefix associated with the new UPF. At operation 8-4, UAV 211 may send a PDU session modification request to the network, which includes any of the following: (1) a request for an indication of C2 communication; (2) a UAS id; and / or (3) a new PDU session ID, etc.

[0217] At operation 8-5, the network (e.g., a network entity) may send a connectivity modification instruction for the new IP address of the UAV to UTM 220. At operation 8-6, UTM 220 may locally track and / or store the information. At operation 8-7, UTM 220 may notify UAV-C 212 associated with the UAS id of the new IP address of the UAV. At operation 8-8, UAV-C 212 may update the UAS information using the new IP address of the UAV. At operation 8-9, UAV-C 212 may reply to UTM 220 that the change has been successfully made. The reply message may include any of the following: (1) the UAS id; and / or (2) the new IP address of the UAV WTRU, etc.

[0218] At operations 8-10, UTM 220 may send (e.g., send back) an acknowledgment (ACK) of connectivity modification to the network (e.g., a network entity) and / or authorize the use of the new IP address of UAV 211 for C2 communication. The acknowledgment message may include any of the following: (1) UAS id; and / or (2) the new IP address of the UAV WTRU, etc. At operations 8-11, the network may update a new PDU session by authorizing the use of the new PDU session for C2 communication. At operations 8-12, the network may send a PDU session modification ACK to the UAV, thereby authorizing the use of the new PDU session for C2 communication. The acknowledgment message may include any of the following: (1) communication indication (e.g., C2 indication); (2) UAS id; (3) new PDU session id; and / or (4) the new IP address of the UAV WTRU, etc. At operations 8-13, UAV 211 and UAV-C 212 may use the new IP address of UAV 211 for C2 communication.

[0219] Figure 9 This is a diagram illustrating a representative procedure for C2 communication updated via a new IP address (e.g., using an existing updatable PDU session). Reference Figure 9 Representative procedures may include, at operation 9-1a, WTRU / UAV 211 establishing a PDU session over the network, and at operation 9-1b, UAV-C 212 establishing a PDU session over the same PLMN or a different PLMN. At operation 9-1c, UAV 211 may exchange C2 traffic with UAV-C 212 over a network connection (e.g., a C2 communication link). WTRU / UAV 211 and UAV-C 212 may each use their peer's IP address for C2 communication. At operation 9-2, the network (e.g., a network entity) may determine that the service UPF and / or SMF may (e.g., need to) be changed (e.g., due to WTRU / UAV mobility). At operation 9-3, the network may send a new prefix (e.g., a new IPv6 prefix) to UAV 211. At Operation 9-4, the WTRU / UAV 211 may send a PDU session modification request to the network, which includes any of the following: (1) a request for an indication of C2 communication; (2) a UAS id; and / or (3) a new PDU session ID, etc.

[0220] At operation 9-5, upon or after receiving a message from UAV 211, or autonomously, the network (e.g., a network entity) may send a connectivity modification indication for the new IP address of UAV 211 to UTM 220, which includes either: (1) UASid; and / or (2) the new IP address of the UAV, etc. At operation 9-6, UTM 220 may notify UAV-C 212, which is associated with UASid / C2 communication, of the new IP address of UAV 211 and / or receive an ACK from UAV-C 212 (e.g., as...). Figure 8 As shown in Operations 8-7 to 8-10). At Operation 9-7, the UTM 220 may send (e.g., send back) an ACK for connectivity modification to the network and / or authorize the UAV 211 with a new IP address for C2 communication. The ACK may include either: (1) the UAS ID; and / or (2) the IP address of the UAV, etc. At Operation 9-8, the network (e.g., a network entity) may update the new PDU session with authorization for C2 communication.

[0221] At operations 9-8, the network (e.g., a network entity) may authorize the use of a new PDU session for C2 communication. For example, at operation 9-9a, if operation 9-4 has been completed (e.g., if WTRU / UAV 211 has sent a PDU session modification request to the network), the network may send a PDU session modification ACK to the UAV. The ACK may include any of the following: (1) a communication indication (e.g., a C2 indication); (2) a UAS id; (3) a new PDU session id; and / or (4) a new IP address for the UAV WTRU, etc. In some or alternative embodiments, at operation 9-9b, the network may send a PDU session modification indication to WTRU / UAV 211, indicating that C2 communication is permitted using the new IP address of UAV 211, and at operation 9-9c, WTRU / UAV 211 may acknowledge the PDU session modification indication. At operations 9-10, UAV 211 and UAV-C 212 can use the new IP address of UAV 211 for C2 communication.

[0222] Representative procedures for UTM-assisted / authorized UAVs (e.g., via IP address changes)

[0223] Any of the example / implementation discussed herein can be used to establish a new PDU session or modify an existing PDU session. In some representative implementations, procedures, apparatus, and / or systems may be implemented to enable UAV 211 to notify its peer UAV-C 212 of its new IP address or to enable UTM 220 to notify UAV-C of its new IP address.

[0224] Figure 10 This is a diagram illustrating a representative procedure for C2 communication updates via a new IP address (e.g., where UTM 220 can notify UAV-C 212). Reference Figure 10 A representative procedure may include, at operation 10-1, WTRU / UAV 211 exchanging C2 traffic with UAV-C 212 via a network connection (e.g., a C2 communication link). UAV 211 and UAV-C 212 may use their peer IP addresses for communication. At operation 10-2, the network (e.g., a network entity) may decide / determine to assign another UPF to the UAV. UAV 211 may obtain a new IP address associated with the new UPF. At operation 10-3, UAV 211 may send a connectivity modification instruction specifying the new IP address of the UAV to UTM 220. UAV 211 may send a message to UTM 220 that may include any of the following: UAS id, PDU session IP address, and / or the new IP address of the UAV, etc. At operation 10-4, UTM 220 may, for example, track this information locally. At operation 10-5, UTM 220 may notify UAV-C 212, associated with UAS id / C2 communication, of the UAV's new IP address. UTM 220 may send a message to UAV-C 212 that may include any of the following: UAS id, the UAV's new IP address, and / or UAV WTRU id, etc. At operation 10-6, UAV-C 212 may update C2 communication using the UAV's new IP address. At operation 10-7, UAV-C 212 may reply to UTM 220 that the change has been successfully made. UAV-C 212 may send a message to UTM 220 that may include any of the following: UAS id, the UAV's new IP address, and / or UAV WTRU id, etc. At operation 10-8, UTM 220 may send (e.g., send back) an ACK for connectivity modification to UAV 211 and / or authorize the use of UAV 211's new IP address for C2 communication. UTM 220 can send messages to UAV 211 that may include any of the following: UAS id, new PDU session IP address, and / or UAV IP address, etc. At operation 10-9, UAV 211 and UAV-C 212 can use UAV 211's new IP address for C2 communication.

[0225] Figure 11 This is a diagram illustrating a representative procedure for C2 communication updates via a new IP address (e.g., where UAV 211 can notify UAV-C 212). Reference Figure 11A representative procedure may include, at operation 11-1, WTRU / UAV 211 exchanging C2 traffic with UAV-C 212 via a network connection (e.g., a C2 communication link). UAV 211 and UAV-C 212 may use their peer's IP address for communication. At operation 11-2, the network (e.g., a network entity) may decide / determine to assign another UPF to the UAV. UAV 211 may obtain a new IP address associated with the new UPF. At operation 11-3, UAV 211 may send a connectivity modification instruction specifying the new IP address of the UAV to UTM 220. UAV 211 may send a message to UTM 220 that may include any of the following: UAS ID, PDU session IP address, and / or the new IP address of the UAV, etc. At operation 11-4, UTM 220 may send (e.g., send back) an ACK for connectivity modification to UAV 211 and / or authorize C2 communication using UAV 211's new IP address. UTM 220 may send an ACK message to UAV 211 that may include any of the following: UAS id, PDU session IP address, and / or UAV's new IP address, etc. At operation 11-5, UAV 211 may notify UAV-C 212 of the UAV's new IP address, either using or via C2 communication. UAV 211 may send a message to UAV-C 212 that may include any of the following: UAS id, WTRU id, and / or UAV's new IP address, etc. At operation 11-6, UAV-C 212 may update C2 communication using the UAV's new IP address. At operation 11-7, UAV-C 212 may send a C2 communication modification instruction to UTM 220 specifying any of the following: (1) WTRU / UAV id; (2) UAS id; and / or (3) the new IP address of the UAV, etc. At operation 11-8, UAV-C 212 may reply to UAV 211 that the C2 communication has been successfully updated, and UAV-C 212 may indicate the UAS id. At operation 11-9, UAV 211 and UAV-C 212 may use the new IP address of UAV 211 for C2 communication.

[0226] Representative procedures for C2 communication links with UTM settings (e.g., via UTM-based navigation)

[0227] Figure 12 This diagram illustrates the protocol of a C2 communication link with UTM settings established using on-demand network connectivity. CP transmission is used to illustrate message exchange between the WTRU / UAV 211 and the UTM 220. (Reference) Figure 12 Representative procedures may be included at Operation 12-0, where WTRU / UAV 211 has performed network-assisted UAV authentication and / or authorization via UTM procedures.

[0228] Representative procedures may be triggered by: (1) at operation 12-1a, WTRU / UAV 211 sending a request message to or toward UTM 220 to establish C2 communication with UTM 220 for UTM-based navigation (e.g., the C2 communication request message (e.g., a container in a NAS transport message) may include information about either: (i) the UAV flight plan, and / or (ii) the mission type (e.g., referring to a pre-authorized flight plan) etc.), and the network (e.g., a network entity) may forward and / or send the C2 communication request message to UTM 220 (e.g., via NEF or UCF) for example, along with UAV WTRUid; and (2) at operation 12-1b, UTM 220 may check that UAV 211 is authorized for UTM-based navigation based on UAV 211 and mission information (e.g., directly after successful operation 12-0 and / or based on one or more other internal / external triggers). UTM 220 may assign a new UAS ID upon or after successful authorization. At Operation 12-2, UTM 220 may send a message to UAV service PLMN301a that may include any of the following: (1) UAV WTRU ID; (2) UAS ID identifying the authorized UAS session / task; and / or (3) UAS-specific messages (e.g., containers) that may include parameters of the task, such as: (i) the IP address of the C2 server (e.g., which may be the same as or different from the UTM IP address used by the network); (ii) flight route information and / or (iii) flight route update information.

[0229] At operation 12-3, the network function (e.g., AMF or MME) in the service PLMN 301a of UAV 211 can update the WTRU / UAV context, for example, to authorize a UAS session identified by the UAS id. At operation 12-4a, the network (e.g., a network entity) can send a message to UAV 211 that may include any of the following: (1) the UAS id and / or (2) a UAS message container, etc. In some representative embodiments, at operation 12-4b, the network (e.g., a network entity) can use a UCU procedure to update the WTRU with this information (e.g., if the procedure is triggered by UTM 220 in operation 12-1). At operation 12-5, WTRU / UAV 211 can establish a PDU session / PDN connection (e.g., AMF / SMF) with the service PLMN 301a of UAV 211 and can provide the UAS id. The network (e.g., SMF or another network entity) may configure data forwarding rules in the UP gateway and / or functions, such as ensuring that authorized C2 traffic can or will be routed to / from the C2 server IP address. At operation 12-6, the network (e.g., the network entity) may send a response message to UTM 220 (e.g., in response to or after the message in operation 12-2), which may include any of the following: (1) UAV WTRU id; (2) UAS id; and / or (3) UAV IP / MAC address, etc. The response message may confirm to UTM 220 that UAV 211 is reachable and / or ready to fly for C2 commands. At operation 12-7, UAV 211 and UTM 220 may exchange C2 traffic.

[0230] Figure 13 This diagram illustrates the protocol for a C2 communication link with UTM settings established using pre-established network connectivity. CP transmission is used to illustrate message exchange between the WTRU / UAV 211 and the UTM 220. (Reference) Figure 13 Representative procedures may be included in Operation 13-0, where WTRU / UAV 211 has performed network-assisted UAV authentication and / or authorization via UTM procedures.

[0231] At operation 13-1, the WTRU / UAV 211 can establish a second and / or backup PDU session / PDN connection, for example, to establish C2 communication with the UTM 220 as described herein. The network can register / publish the PDU session / PDN connection IP address to the UTM 220.

[0232] Representative procedures may be triggered by: (1) at operation 13-2a, WTRU / UAV 211 sending a request message to or toward UTM 220 to establish C2 communication with UTM 220 for UTM-based navigation (e.g., the C2 communication request message (e.g., a container in a NAS transport message) may include information about either: (i) the UAV flight plan, and / or (ii) the mission type (e.g., referring to a pre-authorized flight plan) etc.), and the network (e.g., a network entity) may forward and / or send the C2 communication request message to UTM 220 (e.g., via NEF) along with the UAV WTRU id; and (2) at operation 13-2b, UTM 220 may check that UAV 211 is authorized for UTM-based navigation based on UAV 211 and mission information (e.g., directly after successful operation 12-0 and / or based on one or more other internal / external triggers). UTM 220 can assign a new UAS ID upon or after successful authorization.

[0233] At operation 13-3, UTM 220 may send a message to UAV service PLMN 301a, which may include any of the following: (1) UAV WTRU id; (2) UAS id identifying the authorized UAS session / task; and / or (3) UAS-specific messages (e.g., containers) that may include task parameters such as: (i) the IP address of the C2 server (e.g., which may be the same as or different from the UTM IP address used by the network); (ii) flight route information and / or (iii) flight route update information. At operation 13-4, the network (e.g., a network entity) may trigger an update of the PDU session / PDN connection, for example, to authorize traffic to / from the C2 server IP, as described herein. At operation 13-5, the network (e.g., a network entity) may send a response message to UTM 220a (e.g., in response to or after the message in operation 13-3), which may include any of the following: (1) UAVWTRU id; (2) UAS id; and / or (3) UAV IP / MAC address, etc. The response message may confirm to UTM 220 that UAV 211 is reachable and / or ready to fly for C2 commands. The network (e.g., a network entity) may provide UAV IP to UTM 220 (e.g., because the IP address registered in operation 13-1 may have changed, or if the IP address has not been registered). At operation 13-6, UAV 211 and UTM 220 may exchange C2 traffic.

[0234] Figure 14 This is a flowchart illustrating a representative method for establishing C2 communication between UAV 211 and UAV-C 212, implemented by WTRU 102.

[0235] refer to Figure 14 Representative method 1400 may include, at block 1410, WTRU 102 sending a first message to a network entity indicating a session request for C2 communication with UAV 211. At block 1420, WTRU 102 may receive a second message indicating successful C2 communication established with the associated UAV-C 212. At block 1430, WTRU 102 may transmit C2 communication with the associated UAV-C 212.

[0236] In some representative implementations, WTRU 102 may be included in a UAV.

[0237] In some representative implementations, the first message may also include the UAS id.

[0238] In some representative embodiments, representative method 1400 may also include receiving, before receiving the second message, another message from WTRU 102 indicating whether the association between UAV-C 212 and UAV 211 is pending.

[0239] In some representative implementations, representative method 1400 may also include configuring WTRU 102 for C2 standby state of C2 communication prior to receiving the second message.

[0240] In some representative implementations, representative method 1400 may also include establishing a C2 communication link by WTRU 102, which uses a session and is routed via the network.

[0241] In some representative implementations, the second message may be a session modification command and may include information indicating any of the following: (1) the IP address of the associated UAV-C 212, (2) the UAS id and / or (3) the UAV id.

[0242] Figure 15 This is a flowchart illustrating a representative method implemented by WTRU 102 to change C2 communication from between UAV 211 and the first UAV-C 212a to between UAV 211 and the second UAV-C 212b, wherein WTRU 102 transmits C2 communication with the first UAV-C 212a via a first connection.

[0243] refer to Figure 15Representative method 1500 may include, at block 1510, WTRU 102 establishing a second connection for C2 communication to the second UAV-C212b. At block 1520, WTRU 102 may receive a message indicating a switch to the second connection associated with the second UAV-C212b. At block 1530, WTRU 102 may switch from C2 communication with the first UAV-C212a using the first connection to C2 communication with the second UAV-C212b using the second connection. At block 1540, WTRU 102 may transmit C2 communication with the second UAV-C212b after receiving a message.

[0244] In some representative implementations, a second connection may be established as a backup connection before reception.

[0245] In some representative implementations, the message may include information indicating any of the following: (1) the UAS id associated with the first UAV-C 212a; (2) the new UAS id associated with the second UAV-C 212b; (3) the IP address associated with the second UAV-C 212b; and / or (4) the new UAV-C id associated with the second UAV-C 212b.

[0246] In some representative implementations, WTRU 102 may be included in a UAV.

[0247] In some representative implementations, representative method 1500 may also include configuring WTRU 102 for C2 communication: (1) via a first session before handover, and (2) via a second session after handover.

[0248] In some representative implementations, representative method 1500 may also include establishing a C2 communication link by WTRU 102, which uses a second session and is routed via the network.

[0249] In some representative embodiments, representative method 1500 may also include releasing the first connection by WTRU 102.

[0250] Figure 16 This is a flowchart illustrating a representative method implemented by WTRU 102 for managing C2 communication directly established between UAV 211 and UAV-C 212 via a first connection, where UAV-C 212 or another control entity has established a network connection with the network via at least one network entity.

[0251] refer to Figure 16Representative method 1600 may include, at block 1610, WTRU 102 establishing a second connection to the network for C2 communication via at least one network entity. At block 1620, WTRU 102 may receive a message indicating a switch to the established second connection. At block 1630, WTRU 102 may switch from C2 communication with UAV-C 212 using the first connection to C2 communication with UAV-C 212 using the second connection. At block 1640, WTRU 102 may transmit C2 communication: (1) with UAV-C 212 via the first connection before receiving a message, and (2) with UAV-C 212 or another control entity via the second connection after receiving a message.

[0252] Figure 17 This is a flowchart illustrating a representative method implemented by WTRU 102 for managing C2 communication established between UAV 211 and UAV-C 212 or another control entity via a first connection to the network, using at least one network entity, UAV controller, or another control entity with an established network connection.

[0253] refer to Figure 17 Representative method 1700 may include, at block 1710, WTRU 102 using a second connection to establish a second connection for C2 communication directly to UAV-C 212. At block 1720, WTRU 102 may receive a message indicating a switch to the established second connection. At block 1730, WTRU 102 may switch from C2 communication with UAV-C 212 or another control entity using a first connection to C2 communication with UAV-C 212 using the second connection. At block 1740, WTRU 102 may transmit C2 communication: (1) via the first connection to UAV-C 212 or another control entity before receiving a message, and (2) via the second connection to UAV-C 212 after receiving a message.

[0254] In some representative implementations, representative method 1600 or 1700 may further include receiving one or more authorization parameters from WTRU 102 indicating whether to maintain the first connection after a handover; determining, based on the authorization parameters, to maintain the first connection as a redundant connection; and / or maintaining the first connection as a redundant connection based on the determination.

[0255] In some representative implementations, representative method 1600 or 1700 may further include receiving one or more QoS threshold parameters by WTRU 102; measuring the QoS associated with the first connection; determining, based on the measured QoS associated with the first connection and the received QoS threshold parameters, whether to trigger: (1) the establishment of a new connection and a handover to the new connection or (2) a handover to a pre-established redundant connection; and / or triggering the establishment of a second connection and a handover to the second connection based on the determination.

[0256] In some representative embodiments, representative method 1600 or 1700 may further include receiving information in a message from WTRU 102 indicating the type of C2 communication to be used to configure the second connection. For example, the C2 communication type may include one of the following: (1) direct C2 communication type, (2) network-assisted C2 communication type, or (3) UTM navigation C2 communication type.

[0257] In some representative embodiments, representative method 1600 or 1700 may further include WTRU 102 receiving information indicating one or more QoS threshold parameters; measuring the QoS associated with the first connection; determining whether to switch to the second connection based on the measured QoS associated with the first connection and the indicated one or more QoS threshold parameters; and / or, if WTRU 102 will switch to the second connection, WTRU 102 sending a handover request message to a control entity indicating a request to switch to the second connection. For example, the received message indicating a switch to the established second connection may be a handover response message indicating an authorization to switch to the second connection.

[0258] In some representative implementations, the handover request message may include information about either: (1) the measured QoS associated with the first connection and / or (2) the indicated QoS threshold parameter.

[0259] In some representative implementations, the control entity may be associated with UAE-S 221.

[0260] Figure 18 This is a flowchart illustrating a representative method for establishing C2 communication between UAV 211 and the first UAV-C 212a, implemented by WTRU 102.

[0261] refer to Figure 18Representative method 1800 may include, at block 1810, WTRU 102 sending a first message to a network entity indicating a session request for C2 communication with the UAV. At block 1820, WTRU 102 may receive a second message indicating successful C2 communication established with the associated UAV-C 212. At block 1830, WTRU 102 may transmit C2 communication with the associated UAV-C 212.

[0262] In some representative embodiments, representative method 1800 may further include switching from the first UAV-C 212a to the second UAV-C 212b for C2 communication by WTRU 102; and / or transmitting C2 communication between WTRU 102 and the second UAV-C 212b.

[0263] In some representative implementations, before the handover, C2 communication can be routed to the first UAV-C 212a using the first C2 communication link; and after the handover, C2 communication can be routed to the second UAV-C 212b using the second C2 communication link.

[0264] In some representative embodiments, representative method 1800 may also include configuring a second C2 communication link by WTRU 102 for C2 communication between UAV 211 and second UAV-C 212b.

[0265] In some representative embodiments, representative method 1800 may further include WTRU 102 determining, based on C2 switching conditions, to switch C2 communication with UAV 211 from a first C2 communication link to a second C2 communication link; WTRU 102 sending a notification to the C2 control entity indicating link information for determining the switch from the first C2 communication link to the second C2 communication link; WTRU 102 receiving information from the C2 control entity indicating the switch to the second C2 communication link; and / or WTRU 102 switching C2 communication from the first C2 communication link to the second C2 communication link.

[0266] In some representative implementations, C2 communication is routed to the first UAV-C 212a using a first C2 communication link before the handover; and after the handover, C2 communication is routed to the first UAV-C 212a using a second C2 communication link.

[0267] In some representative implementations, representative method 1800 may further include routing C2 communication to a first UAV-C 212a using a first C2 communication link before the handover; and routing C2 communication to a second UAV-C 212b using a second C2 communication link after the handover.

[0268] In some representative implementations, C2 handover conditions can be determined based on C2 communication link standards.

[0269] In some representative implementations, the C2 switching conditions can be determined based on commands received from the C2 control entity.

[0270] In some representative implementations, the first C2 communication link may be a direct C2 communication link, and the second C2 communication link may be a network-assisted C2 communication link.

[0271] In some representative implementations, the second C2 communication link may be a direct C2 communication link, and the first C2 communication link may be a network-assisted C2 communication link.

[0272] In some representative implementations, the first C2 communication link may be one of the following: (1) a direct C2 communication link; or (2) a network-assisted C2 communication link, and the second C2 communication link may be a UTM navigation C2 communication link.

[0273] In some representative implementations, the second C2 communication link may be one of the following: (1) a direct C2 communication link; or (2) a network-assisted C2 communication link, and the first C2 communication link may be a UTM navigation C2 communication link.

[0274] In some representative implementations, the C2 communication link standard may be based on one or more QoS threshold parameters.

[0275] In some representative embodiments, representative method 1800 may further include measuring the QoS associated with the first C2 communication link; and / or determining whether to switch to a second C2 communication link based on the measured QoS and QoS threshold parameters associated with the first C2 communication link. For example, received information indicating a switch to the second C2 communication link may indicate authorization to switch to the second C2 communication link.

[0276] In some representative implementations, the notification indicating link information may indicate measurement QoS information and QoS threshold information associated with the first C2 communication link.

[0277] In some representative implementations, the C2 control entity may be associated with UAE-S 221.

[0278] In some representative implementations, WTRU 102 may be included in a UAV.

[0279] In some representative implementations, representative method 1800 may also include sending information indicating a switch to a second C2 communication link from WTRU 102 to the C2 management entity.

[0280] In some representative implementations, the C2 management entity may be associated with the UTM 220.

[0281] In some representative implementations, representative method 1800 may also include disabling the first C2 communication link after the handover.

[0282] Figure 19 This is a flowchart illustrating a representative method implemented by WTRU 102 for switching C2 communication with UAV 211 from a first C2 communication link to UAV-C 212 to a second C2 communication link to UAV-C 212.

[0283] refer to Figure 19 Representative method 1900 may include, at block 1910, WTRU 102 determining, based on C2 handover conditions, to switch C2 communication from a first C2 communication link to a second C2 communication link. At block 1920, WTRU 102 may send a notification to the C2 control entity indicating link information for determining the switch from the first C2 communication link to the second C2 communication link. At block 1930, WTRU 102 may receive information from the C2 control entity indicating the handover to the second communication link. At block 1940, WTRU 102 may switch C2 communication from the first C2 communication link to the second C2 communication link.

[0284] In some representative implementations, C2 handover conditions can be determined based on C2 communication link standards.

[0285] In some representative implementations, the C2 switching conditions can be determined based on commands received from the C2 control entity.

[0286] In some representative implementations, the first C2 communication link may be a direct C2 communication link, and the second C2 communication link may be a network-assisted C2 communication link.

[0287] In some representative implementations, the second C2 communication link may be a direct C2 communication link, and the first C2 communication link may be a network-assisted C2 communication link.

[0288] In some representative implementations, the C2 communication link standard may be based on one or more QoS threshold parameters.

[0289] In some representative embodiments, representative method 1900 may further include measuring the QoS associated with the first C2 communication link; and / or determining whether to switch to a second C2 communication link based on the measured QoS and QoS threshold parameters associated with the first C2 communication link. For example, received information indicating a switch to the second C2 communication link may indicate authorization to switch to the second C2 communication link.

[0290] In some representative implementations, the notification indicating link information may indicate measurement QoS information and QoS threshold information associated with the first C2 communication link.

[0291] In some representative implementations, the C2 control entity may be associated with UAE-S 221.

[0292] In some representative implementations, WTRU 102 may be included in a UAV.

[0293] In some representative implementations, representative method 1900 may also include sending information indicating a switch to a second C2 communication link from WTRU 102 to the C2 management entity.

[0294] In some representative implementations, the C2 management entity may be associated with the UTM 220.

[0295] In some representative embodiments, representative method 1900 may further include transmitting C2 information such that (1) before the handover, C2 information is transmitted between UAV 211 and UAV-C 212 using a first C2 communication link; and (2) after the handover, C2 information is transmitted between UAV 211 and UAV-C 212 using a second C2 communication link.

[0296] In some representative implementations, representative method 1900 may also include disabling the first C2 communication link after the handover.

[0297] Figure 20 This is a flowchart illustrating a representative method implemented by WTRU 102 for switching C2 communication between UAV 211 and UAV-C 212 from a first C2 communication link to a second C2 communication link.

[0298] refer to Figure 20 Representative method 2000 may include, at block 2010, WTRU 102 determining, based on C2 handover conditions, to switch C2 communication from a first C2 communication link to a second C2 communication link. At block 2020, WTRU 102 may send a notification to the C2 control entity indicating link information for determining the switch from the first C2 communication link to the second C2 communication link. At block 2030, WTRU 102 may receive information from the C2 control entity indicating the handover to the second communication link. At block 2040, WTRU 102 may switch C2 communication from the first C2 communication link to the second C2 communication link.

[0299] In some representative implementations, before the handover, a first C2 communication link can be used to route C2 communication between UAV 211 and the first UAV-C 212a; and after the handover, a second C2 communication link can be used to route C2 communication between UAV 211 and the first UAV-C 212a.

[0300] In some representative implementations, before the handover, a first C2 communication link can be used to route C2 communication between UAV 211 and the first UAV-C 212a; and after the handover, a second C2 communication link can be used to route C2 communication between UAV 211 and the second UAV-C 212b.

[0301] In some representative implementations, the first C2 communication link may be a direct C2 communication link, and the second C2 communication link may be a network-assisted C2 communication link.

[0302] In some representative implementations, the second C2 communication link may be a direct C2 communication link, and the first C2 communication link may be a network-assisted C2 communication link.

[0303] In some representative implementations, the first C2 communication link may be one of the following: (1) a direct C2 communication link; or (2) a network-assisted C2 communication link, and the second C2 communication link may be a UTM navigation C2 communication link.

[0304] In some representative implementations, the second C2 communication link may be one of the following: (1) a direct C2 communication link; or (2) a network-assisted C2 communication link, and the first C2 communication link may be a UTM navigation C2 communication link.

[0305] In some representative implementations, C2 handover conditions can be determined based on C2 communication link standards.

[0306] In some representative implementations, the C2 switching conditions can be determined based on commands received from the C2 control entity.

[0307] In some representative implementations, the C2 communication link standard may be based on one or more QoS threshold parameters.

[0308] In some representative embodiments, representative method 2000 may further include measuring the QoS associated with the first C2 communication link; and / or determining whether to switch to a second C2 communication link based on the measured QoS and QoS threshold parameters associated with the first C2 communication link. For example, received information indicating a switch to the second C2 communication link may indicate authorization to switch to the second C2 communication link.

[0309] In some representative implementations, the notification indicating link information may indicate measurement QoS information and QoS threshold information associated with the first C2 communication link.

[0310] In some representative implementations, the C2 control entity may be associated with UAE-S 221.

[0311] In some representative implementations, WTRU 102 may be included in a UAV.

[0312] In some representative implementations, representative method 2000 may also include sending information indicating a switch to a second C2 communication link from WTRU 102 to the C2 management entity.

[0313] In some representative implementations, the C2 management entity may be associated with the UTM 220.

[0314] In some representative implementations, representative method 2000 may also include disabling the first C2 communication link after the handover.

[0315] The following references are incorporated herein by reference: (1) 3GPP TS 22.125, “Unmanned Aerial System (UAS) support in 3GPP”, V17.1.0; (2) 3GPP TR 22.825, “Remote Identification of Unmanned Aerial Systems”, V16.0.0; (3) 3GPP TR 22.829, “Study on Enhancement for Unmanned Aerial Vehicles”, V1.0.0; (4) 3GPP TS 23.501, “System Architecture for the 5G System”, V16.1.0; (5) 3GPP TS 23.502, “Procedures for the 5G System”. (5GSystem), V16.1.1; (6) 3GPP TR 23.754, “Study on supporting Unmanned Aerial Systems (UAS) connectivity, Identification and tracking”, V0.1.0; (7) 3GPP document entitled “Solution for C2 connectivity”, published to SA2 email communication mechanism, April 2020; and (8) 3GPP TR 23.754, “Study on supporting Unmanned Aerial Systems (UAS) connectivity, Identification and tracking (Release 17)”, V0.2.0, June 2020.

[0316] Systems and methods for processing data according to representative embodiments can be executed by one or more processors that execute sequences of instructions contained in a memory device. Such instructions can be read into the memory device from other computer-readable media, such as auxiliary data storage devices. Execution of the sequence of instructions contained in the memory device causes the processor to operate, for example, as described above. In alternative embodiments, hardwired circuitry may be used instead of software instructions, or hardwired circuitry may be combined with software instructions to implement the invention. Such software can run remotely on a processor housed within a vehicle and / or another mobile device. In the latter case, data can be transferred between vehicles or other mobile devices via wired or wireless means.

[0317] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0318] Furthermore, the above embodiments specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions can be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0319] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that representative embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may also support the provided methods.

[0320] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that representative embodiments are not limited to the memory described above, and other platforms and memories may also support the methods described. It should be understood that representative embodiments are not limited to the platform or CPU described above, and other platforms and CPUs may also support the provided methods.

[0321] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0322] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software can become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of deployment. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0323] The above detailed description has illustrated various embodiments of the apparatus and / or process using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include (by way of example) general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC) and / or state machine.

[0324] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described in this patent application, which are intended as examples of various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0325] It should also be understood that the terminology used herein is for the purpose of describing specific implementations only and is not intended to be limiting. As used herein, when referred to herein, the term “station” and its abbreviation “STA”, “user equipment” and its abbreviation “UE” may mean: (i) a wireless transmitting and / or receiving unit (WTRU), as described below; (ii) any of several implementations of a WTRU, as described below; (iii) equipment having wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU, as described below; (iii) equipment having wireless and / or wired capabilities configured with fewer than all the structure and functions of a WTRU, as described below; or (iv) etc. The following is relative to Figures 1A to 1DDetails of an exemplary WTRU that can represent any UE described herein are provided.

[0326] In some representative embodiments, portions of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein are, wholly or partially, equivalently implemented in an integrated circuit as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuitry and / or writing software and / or firmware code according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement that distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media (such as floppy disks, hard disks, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0327] The topics described herein sometimes illustrate different components contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same function is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to enable the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0328] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0329] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim objects, such intention will be explicitly stated in the claims, and if no such claim objects are present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the appended claims and / or the description herein may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim objects. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim objects is limited to an embodiment containing only one such claim object by using the indefinite articles “a” or “an.” This is true even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce the subject matter of a claim. Furthermore, even when a specific number of the introduced subject matter of a claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matters" without other modifiers means at least two subject matters, or two or more subject matters). Additionally, in instances where conventions such as "at least one of A, B, and C" are used, generally speaking, such constructions mean that those skilled in the art will understand that convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). In instances where conventions such as "at least one of A, B, or C" are used, generally speaking, such a construction implies that a person skilled in the art will understand that the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). A person skilled in the art should also understand that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one term, any one of the terms, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items alone or in combination with other items and / or other item categories, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Furthermore, as used herein, the term “group” or “cluster” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero.

[0330] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0331] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

[0332] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to invoke 35 U.S.SC §112. 6. The claim format is either device plus function, and any claim without the term "device for..." is not intended to be so.

[0333] The software-associated processor can be used to implement the radio frequency transceiver in a Transmitter-Receiver Unit (WTRU), User Equipment (UE), terminal, base station, Mobility Management Entity (MME), or Evolved Packet Core (EPC), or any host. The WTRU can be used in conjunction with modules and can be implemented in hardware and / or software including: Software-defined Radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keypads, etc. Modules, FM radio units, Near Field Communication (NFC) modules, Liquid Crystal Display (LCD) units, Organic Light Emitting Diode (OLED) units, Digital Music Players, Media Players, Video Game Players, Internet Browsers, and / or any Wireless Local Area Network (WLAN) or Ultra-Wideband (UWB) modules.

[0334] Throughout the disclosed content, those skilled in the art should understand that certain representative implementations may be used in alternative forms or in combination with other representative implementations.

[0335] Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a Wireless Transmit / Receive Unit (WTRU), the method comprising: It operates in a first command and control C2 communication mode to communicate with the unmanned aerial vehicle controller (UAV-C), wherein the first C2 communication mode is a direct communication mode. The triggering conditions for switching C2 communication modes are determined to be met, wherein the triggering conditions are based on the Quality of Service (QoS) and threshold of the link associated with the first C2 communication mode; Send a first message to the C2 control entity indicating that the triggering condition has been met, wherein the C2 control entity is associated with the UAS application enabler server UAE-S; Receive a second message from the C2 control entity authorizing a switch to a second C2 communication mode; and Switch the operation from the first C2 communication mode to the second C2 communication mode, wherein the second C2 communication mode is an indirect C2 communication mode.

2. The method according to claim 1, wherein, The second message indicates the measured QoS information and the threshold of the link associated with the first C2 communication mode.

3. The method according to claim 1 further includes sending information to the C2 management entity indicating a switching operation from the first C2 communication mode to the second C2 communication mode.

4. The method according to claim 1, further comprising disabling the first C2 communication mode after the switch.

5. The method according to claim 1, wherein, The WTRU is included in the unmanned aerial vehicle (UAV).

6. The method according to claim 1, wherein, The C2 control entity is associated with the UAS application enabler server.

7. The method according to claim 1, wherein, The threshold is configured via a policy.

8. The method according to claim 1, wherein, The threshold is configured via a policy provided by the network.

9. The method according to claim 1, wherein, The first C2 communication mode is a direct C2 communication mode, and the second C2 communication mode is a network-assisted C2 communication mode.

10. The method according to claim 3, wherein, The C2 management entity is associated with the traffic management of the Unmanned Aerial Vehicle System (UAS).

11. A wireless transmit / receive unit (WTRU), the WTRU comprising a processor and a transmitter / receiver, the WTRU being configured to: It operates in a first command and control C2 communication mode to communicate with the unmanned aerial vehicle controller (UAV-C), wherein the first C2 communication mode is a direct communication mode. It has been determined that the triggering conditions for switching C2 communication modes have been met, among which, The triggering conditions are based on the Quality of Service (QoS) and threshold of the link associated with the first C2 communication mode; Send a first message to the C2 control entity indicating that the triggering condition has been met, wherein the C2 control entity is associated with the UAS application enabler server UAE-S; Receive a second message from the C2 control entity authorizing a switch to a second C2 communication mode; and Switch the operation from the first C2 communication mode to the second C2 communication mode, wherein the second C2 communication mode is an indirect C2 communication mode.

12. The WTRU according to claim 11, wherein, The second message indicates the measured QoS information and the threshold of the link associated with the first C2 communication mode.

13. The WTRU of claim 11 is further configured to send information to the C2 management entity indicating a switching operation from the first C2 communication mode to the second C2 communication mode.

14. The WTRU of claim 11 is further configured to disable the first C2 communication mode after the switch.

15. The WTRU according to claim 11, wherein, The C2 control entity is associated with the UAS application enabler server.

16. The WTRU of claim 11, wherein, The threshold is configured via a policy.

17. The WTRU according to claim 11, wherein, The threshold is configured via a policy provided by the network.

18. The WTRU according to claim 11, wherein, The first C2 communication mode is a direct C2 communication mode and the second C2 communication mode is a network-assisted C2 communication mode.

19. The WTRU according to claim 13, wherein, The C2 management entity is associated with the traffic management of the Unmanned Aerial Vehicle System (UAS).

20. An unmanned aerial vehicle (UAV) comprising a WTRU according to any one of claims 11 to 19.

Images