Protocol data unit (PDU) session establishment

Abstract

Systems, methods, and instrumentalities associated with cellular communications for unmanned aerial vehicles and associated devices are disclosed. A WTRU can initiate multiple PDU sessions. The WTRU can initiate a first protocol data unit (PDU) session. The WTRU can receive one or more session parameters for a second PDU session. The one or more session parameters for the second PDU session can be received via the first PDU session. The WTRU can initiate the second PDU session using the one or more session parameters (e.g., based on authentication and authorization associated with the first PDU session being successful). The WTRU can send or receive operational communications via the second PDU session. The operational communications can include unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

Description

[0001] This application is a divisional application of patent application No. 202080075581.9, filed on October 1, 2020, entitled "Protocol Data Unit (PDU) Session Establishment".

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 910,151, filed October 3, 2019, the contents of which are incorporated herein by reference. Background Technology

[0004] Unmanned aerial systems (UAS) or unmanned aerial vehicles (UAVs) utilize various communication methods to support their operations. For example, UAS / UAVs can connect to cellular networks. The number of UAV operations has been steadily increasing in recent years, and applications enabled by UAVs are expanding into multiple industries. Currently, UASs may rely on direct point-to-point communication (e.g., via unlicensed ISM bands), which can limit their operational range. Point-to-point communication can be unreliable, insecure, and / or have low data rates. Summary of the Invention

[0005] Systems, methods, and tools associated with cellular communications for unmanned aerial vehicles (UAVs) and associated equipment are disclosed. A WTRU can initiate multiple PDU sessions. The WTRU can register with a network (e.g., via a network entity or function such as an access mobility function). The WTRU can initiate a first Protocol Data Unit (PDU) session. The first PDU session can be associated with the WTRU's authentication and / or authorization, for example, through (e.g., a third-party) authentication and authorization server (e.g., a UAS service provider, UAV traffic management function). The first PDU session can be restricted or initially restricted (e.g., authentication and / or authorization, non-operational communications, etc.). The WTRU can receive one or more session parameters for a second PDU session. The one or more session parameters for the second PDU session can be received via the first PDU session. The one or more session parameters may include a data network name, individual network slice selection auxiliary information, and / or service and session continuity mode. The WTRU can (e.g., based on successful authentication and authorization) use one or more session parameters to initiate a second PDU session. The WTRU can send or receive operational communications via the second PDU session. Operational communications may include unmanned aerial vehicle (UAV) command and control (also referred to as C2 or C&C) messages or UAV payload messages. The WTRU may modify the first PDU session, for example, based on successful authentication and authorization. Modification may include allowing the sending or receiving of one or more operational communications via the first PDU session (e.g., where, in the example, operational communications are not permitted in the first PDU session prior to initiating / establishing a second PDU session).

[0006] The terms Unmanned Aerial Vehicle (UAV), UAV Controller (UAV-C), Drone, and / or WTRU are used interchangeably herein. While some examples may be described using the terms WTRU, UAV, UAV-C, or Drone, depending on the context, these examples may apply to WTRU, UAV, UAV-C, and / or Drone. In the examples, Unmanned Aerial System (UAS) may refer to a combination of UAV and C-UAV. Attached Figure Description

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

[0008] 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;

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

[0010] 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;

[0011] Figure 2 This is a system diagram illustrating an exemplary system architecture for supporting WTRUs that can be used in 5G networks, according to an implementation scheme.

[0012] Figure 3 This is a schematic diagram illustrating an example of UAV communication that can be enabled via a cellular network;

[0013] Figure 4 This is an example of initiating / establishing two PDU sessions (e.g., for UAV communication);

[0014] Figure 5 An example of initiating / establishing a PDU session that can be used for task-related communication is shown; and

[0015] Figure 6 An example of WTRU QoS rule configuration is shown. Detailed Implementation

[0016] Figure 1A This 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.

[0017] like Figure 1AAs 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 an example, 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 subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other 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 WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0018] 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 an example, base stations 114a and 114b may be base transceiver stations (BTS), Node Bs, evolved Node Bs, home Node Bs, home evolved Node Bs, 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.

[0019] 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. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one 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.

[0020] 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.

[0021] 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 air interfaces 115 / 116 / 117. 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).

[0022] In one implementation, 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.

[0023] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0024] In one implementation, 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 instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface used 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).

[0025] 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).

[0026] Figure 1ABase 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 local 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 one 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 CN106 / 115.

[0027] 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 1A As 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.

[0028] 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.

[0029] 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.

[0030] 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 WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the implementation.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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 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.

[0040] 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.

[0041] 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. Evolved Nodes B 160a, 160b, and 160c may each 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.

[0042] 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.

[0043] 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.

[0044] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

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

[0050] 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.

[0051] 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 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, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. 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 in a given BSS at any given time.

[0052] 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.

[0053] 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 split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. 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).

[0054] 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).

[0055] WLAN systems supporting multiple channels, as well as 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.

[0056] 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.

[0057] 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.

[0058] 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. 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 one implementation, 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 one implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may 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 one implementation, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0059] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. 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).

[0060] 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 other RANs (such as evolved Node Bs 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 Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 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.

[0061] 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.

[0062] 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 the CN operator.

[0063] AMF 182a and 182b can connect to one or more of gNBs 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 PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating 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 (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. The AMF162 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.

[0064] 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 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.

[0065] 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.

[0066] 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 one 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.

[0067] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, which may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0068] 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.

[0069] The one or more emulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0070] Systems, methods, and tools associated with cellular communications for unmanned aerial vehicles (UAVs) and associated equipment are disclosed. A WTRU can initiate multiple PDU sessions. The WTRU can register with a network (e.g., via a network entity or function such as an access mobility function). The WTRU can initiate a first Protocol Data Unit (PDU) session. The first PDU session can be associated with the WTRU's authentication and / or authorization, for example, through (e.g., a third-party) authentication and authorization server (e.g., a UAS service provider, UAV traffic management function). The first PDU session can be restricted or initially restricted (e.g., authentication and / or authorization, non-operational communications, etc.). The WTRU can receive one or more session parameters for a second PDU session. The one or more session parameters for the second PDU session can be received via the first PDU session. The one or more session parameters may include a data network name, individual network slice selection auxiliary information, and / or service and session continuity mode. The WTRU can (e.g., based on successful authentication and authorization) use one or more session parameters to initiate a second PDU session. The WTRU can send or receive operational communications via the second PDU session. Operational communications may include unmanned aerial vehicle (UAV) command and control (also referred to as C2 or C&C) messages or UAV payload messages. The WTRU may modify the first PDU session, for example, based on successful authentication and authorization. Modification may include allowing the sending or receiving of one or more operational communications via the first PDU session (e.g., where, in the example, operational communications are not permitted in the first PDU session prior to initiating / establishing a second PDU session).

[0071] The terms Unmanned Aerial Vehicle (UAV), UAV Controller (UAV-C), Drone, and / or WTRU are used interchangeably herein. While some examples may be described using the terms WTRU, UAV, UAV-C, or Drone, depending on the context, these examples may apply to WTRU, UAV, UAV-C, and / or Drone. In the examples, Unmanned Aerial System (UAS) may refer to a combination of UAV and C-UAV.

[0072] The WTRU can receive configuration information for a specific task (e.g., from a UAS Traffic Management (UTM) node or function) and can use this configuration to select wireless communication parameters, such as Packet Data Unit (PDU) session parameters. The term UAS Service Provider (USS) is used interchangeably with UTM in this document.

[0073] WTRU and 3GPP networks can (e.g., from UTM) receive task-specific Quality of Service (QoS) requirements and can use these QoS requirements to select appropriate QoS parameters for one or more PDU sessions (e.g., in a QoS configuration). UTM can provide a Command and Control Message-Differential Service Code Point / Traffic Class (DSCP / TC) mapping configuration. This Command and Control Message-DSCP / TC mapping configuration can be used by the network and / or WTRU to differentiate between command and control messages used for QoS processing.

[0074] A WTRU (e.g., a UAV-C) can set up a PDU session. For example, a PDU session can be set up for command and control communication with a peer WTRU, where in one example, the peer WTRU could be a UAV. The WTRU can provide an indication that the PDU session is used for command and control traffic. The WTRU can provide an indication that the PDU session is connected to the peer WTRU's PDU session. The WTRU can provide the 3GPP identifier of the peer WTRU. The WTRU can provide a PDU session ID (e.g., for command and control traffic targeting the peer WTRU) during PDU session modification (e.g., establishment).

[0075] The WTRU can receive configuration information for a specific UAV task (e.g., site survey, encapsulation delivery, etc.) (e.g., from the UTM) and can use that configuration (e.g., to select PDU session parameters).

[0076] WTRU and 3GPP networks can (e.g., from UTM) receive QoS requirements for specific tasks and can (e.g., in QoS configuration) combine these requirements. UTM can provide a "Command and Control Message - DSCP / TC" mapping configuration (e.g., for the network and WTRU to be able to distinguish between command and control messages used for QoS processing).

[0077] A WTRU (e.g., a UAV, UAV-C, and / or drone) can set up a PDU session (e.g., for command and control communication with a peer WTRU). The WTRU can provide an indication that the PDU session is used for command and control traffic. The WTRU can provide an indication that the PDU session is connected to the peer WTRU's PDU session. The WTRU can provide the peer WTRU's identifier (e.g., a 3GPP identifier). The WTRU can provide a PDU session ID (e.g., for command and control traffic targeting the peer WTRU) during PDU session modification (e.g., PDU session establishment).

[0078] WTRUs can connect to cellular networks. The number of UAV operations has been steadily increasing in recent years, and the number and types of applications implemented by UAVs can be expanded to a variety of industries. Currently, UAVs can rely on direct point-to-point communication (e.g., via unlicensed ISM bands), which can limit their operational range. Point-to-point communication can be unreliable, insecure, and / or have low data rates. Advanced cellular technologies such as LTE and 5G can be utilized (e.g., to enable beyond-line-of-sight (BVLOS) operation).

[0079] Using cellular networks for communication can provide capabilities beyond those offered by direct point-to-point communication. For example, as a result of using cellular networks for UAV / WTRU, it may be possible to operate over a larger operating range (e.g., beyond and within the coverage area provided by the mobile network). The consequences of using cellular networks can include relatively high bandwidth. The consequences of using cellular networks can include achieving relatively low latency. The consequences of using cellular networks can include the network's ability to attempt to provide QoS guarantees for communication. The consequences of using modern cellular networks (e.g., 5G networks) can include improved performance of UAV applications. The consequences of using cellular networks can include advanced security mechanisms (e.g., to address security issues related to managing UAV applications). Using cellular networks allows for larger operating ranges, high bandwidth, low latency, guaranteed QoS, advanced communication capabilities, improved performance of UAV applications, advanced security mechanisms, and more.

[0080] Figure 2 An exemplary system architecture for supporting WTRUs that can be used in 5G networks is illustrated. The UTM can be a framework (e.g., for UAS traffic management). The role and responsibilities of the UTM may differ from the procedures and protocols applied within the UTM. The UTM can be a set of functions (e.g., for authenticating UAVs, authorizing UAS services, managing UAS policies, and / or controlling UAV traffic in the airspace). Authorized users can (e.g., via the UTM) query the identity and / or metadata of the WTRU and / or its controller. The UTM can store operational data (e.g., data used by the UAS to perform operations). The air traffic control agent can use the UTM server (e.g., to authorize, execute, and / or regulate UAS operations).

[0081] In such Figure 2 In the architecture shown, the WTRU (e.g., UAV, UAV-C, and / or unmanned aerial vehicle) can communicate with the UTM (e.g., for identification, authentication, authorization, command and control message exchange, and / or command and control data exchange), for example, via the network user plane. 3GPP network functions (e.g., SMF, PCF) can have direct or indirect (e.g., via NEF) control interfaces with the UTM.

[0082] A cellular network-connected WTRU can involve various types of cellular communication (e.g., for performing its tasks). Cellular communication can be between the UAS and UTM, can be non-payload communication (e.g., command and control), and / or cellular communication can be payload communication (e.g., real-time video or sensor data).

[0083] Communication may exist between the UAS and UTM. Communication between the UAS and UTM can be enabled for identification, authorization, command and control, and / or law enforcement activities. A user plane connection can be used between the WTRU and UTM. Control plane communication can be used between the WTRU and UTM.

[0084] Cellular communication can be non-payload communication (e.g., command and control). Command and control message and data exchange can be used for UAV missions and / or security. In the example, command and control exchange (e.g., position and / or flight data reporting) can occur between WTRUs and UTMs and / or between WTRUs (e.g., between UAVs and / or UAV-Cs).

[0085] Command and control communication types may include telemetry reports from the WTRU. Telemetry reports can be sent from the WTRU to the controller or network. Telemetry reports may include UAV altitude and / or speed information. Command and control communication types may include real-time remote flight control commands (e.g., for non-autonomous UAVs). Command and control communication types may include mission information. Command and control communication types may include flight plan information. Command and control communication types may include constraints. Command and control communication types may include regulatory data updates. Command and control communication types may include collision avoidance assistance information. Command and control communication types may include one or more of the following: telemetry reports, altitude and / or speed, real-time remote flight control commands, mission, flight plan, constraints, regulatory data updates, collision avoidance assistance information, etc.

[0086] Command and control messages can be small in size. They can be sent at low data rates. Command and control message types can have different QoS requirements (e.g., latency, data loss rate, etc.). In the example, guiding commands may require real-time execution, while task updates may tolerate some latency.

[0087] The WTRU can transmit payload communications. For example, during a mission, the WTRU can (e.g., to its UAV-C, application server, and / or storage devices in the network) transmit payload data, such as real-time video or sensor data. In one example, there may be more payload communications in the uplink than in the downlink. In another example, there may be less payload communications in the uplink than in the downlink.

[0088] Figure 3 This is a schematic diagram illustrating an example of UAV communication that can be enabled via a cellular network.

[0089] The UAS can configure cellular connections for UAS communication. User plane connections can be established within the cellular network (e.g., to enable cellular communication for the UAS).

[0090] The characteristics of UAV missions (e.g., UAV flight) may present challenges. Challenges of UAV missions may include the identification and authorization of UAVs and / or UAV-C (e.g., to establish a PDU session) and / or QoS requirements for UAV communications.

[0091] A PDU session establishment can be initiated by the WTRU. For example, if the WTRU has successfully registered with the network, it can initiate a PDU session establishment (e.g., in a cellular network). For example, before establishing a PDU session for communication, it may be necessary to identify and authorize the UAV and / or UAV-C (e.g., via a UTM). For example, identification and authorization between the UAV and / or UAV-C and a network entity (e.g., a UTM), which can be performed via the user plane, can involve a PDU session connection. For example, after the control UAV-C of the UAV is connected to the network, the UAV can be allowed to establish a PDU session connection. Dependencies can exist between various PDU sessions for different purposes and / or between UAV and / or UAV-C connections. Specific implementations are disclosed that allow the WTRU and the network to establish services providing one or more PDU connectivity for a particular WTRU, for example, based on communication associations or dependencies with another WTRU (such as in command and control communications within a UAS).

[0092] WTRU and / or the network can establish PDU sessions for the UAS, trigger the establishment of various PDU sessions, check dependencies (e.g., regarding authorization results and / or the existence of their control peers), and so on. When establishing a PDU session for the UAS, network-triggered release of the PDU session used by the UAS in conjunction with another PDU session for command and control communication can be allowed or blocked as appropriate.

[0093] When establishing a PDU session for a UAS, the cellular network may need to know the purpose of the PDU session (e.g., for UAV communication) and / or the role of the UAS (e.g., UAV or UAV-C) (e.g., owning the PDU session). When establishing a PDU session for a UAS, the network may be informed of the purpose of the PDU session (e.g., for UAV communication) and / or the role of the UAS (e.g., UAV or UAV-C) (e.g., owning the PDU session). When establishing a PDU session for a UAS, attributes (e.g., DNN, S-NSSAI, SSC mode, etc.) can be selected for the PDU session.

[0094] The network can manage the interdependencies of PDU sessions associated with the UAS according to the UAS operation requirements.

[0095] QoS requirements (e.g., for UAV communications) can be device- and / or mission-specific. UAV-C can have relatively high DL data rate requirements. UAV can have high UL data rate requirements. UAV missions (e.g., potentially involving still image transmission) can have lower data rate requirements than different missions (e.g., involving HD video streaming). In the example, the 3GPP network may not have QoS requirements (e.g., UAV mission-specific data rate requirements) when determining policy control information. Entities with QoS requirements (e.g., UTMs) can dynamically influence policy control information made by the network (e.g., PCFs). QoS provisioning for UAV communications can provide differentiated QoS processing (e.g., for various command and control messages and / or data types). Command and control messages and / or data exchanged between UAVs and UAV-Cs or between UAVs and UTMs can have communication types (e.g., UAS-UTM, command and control, and / or payload communication). Each type of command and / or data can have its own meaning for QoS requirements. Telemetry reports (e.g., UAV position, status, etc.) may require low data rates and may be highly sensitive to data loss. Flight control commands may require reliable real-time communication.

[0096] Filtering communication types can provide differentiated QoS processing for these various communication types (e.g., the network can use filters to configure QoS rules). In the example, QoS rule filters can be based on address information (e.g., IP tuples) and / or application IDs that UAV command and control messages may not have. Filters can reuse QoS rules based on 5G QoS mappings. In the example, QoS rules may lack sufficient granularity to differentiate between command and control messages carrying different types of information and / or serving different purposes (e.g., telemetry and flight control).

[0097] Considering the end-to-end communication path (e.g., across corresponding PDU sessions used for command and control communication by UAVs and / or UAV-C), the network can guarantee QoS (e.g., for command and control communication). Real-time flight control commands may need to be transmitted (e.g., to avoid safety risks).

[0098] The network can enforce consistent QoS processing for command and control traffic across PDU sessions (e.g., traffic used by the UAS for command and control communications).

[0099] A PDU session can be established (e.g., for communication related to UAV missions). A WTRU capable of cellular connectivity can, for example, establish a first PDU session using the network (e.g., for initial communication between the WTRU and the UTM). The WTRU can, for example, authenticate with the UTM and obtain general authorization from the UTM before or during the establishment of the PDU session.

[0100] The first PDU session can be referred to as the default PDU session, the initial PDU session, or the Authentication and Authorization (AA) PDU session. The initial PDU session can be established during or immediately after successful network registration. The establishment of the initial PDU session can be triggered manually or by a command (e.g., an application-layer command, such as a command from UAV-C via sidelink communication). If using a sidelink, it may be necessary to register both the UAV and UAV-C, as V2X SL communication can be supported for WTRUs in RRC_CONNECTED, RRC_IDLE, and (e.g., in NR) RRC_INACTIVE modes.

[0101] The UAV or UAV-C may (e.g., if the initial PDU session is ready) communicate with the UTM (e.g., via the initial PDU session) to authenticate with and / or authorize the UTM. The UAV or UAV-C may (e.g., if the authorization is successful) initiate a second PDU session for UAV mission-related / operational communications (e.g., sending and / or receiving command and control messages and / or payload data) and / or modify the initial PDU session for mission-related / operational communications (e.g., mission-related / operational communications may not be allowed in the initial PDU session, and the initial PDU session may be modified to allow mission-related / operational communications, which may be associated with the initiation of the second PDU session). The UAV or UAV-C may decide to maintain the initial PDU session for command and control communications (e.g., for the availability and reliability of command and control communications, such as policy-based communications) or for remote identification and tracking (e.g., to transmit location information to the USS / UTM). UAV or UAV-C can receive (e.g., from a UTM or UAV application server) configurations (e.g., session parameters). UAV or UAV-C can use these configurations when establishing a second PDU session.

[0102] Configurations (e.g., session parameters) that can be used to establish a second PDU session may include one or more of the following: a task-specific data network name (DNN), a single network slice selection aid (S-NSSAI), and / or a session and service continuity (SSC) mode, a service type, a temporary UAV or UAV-C identifier, identifiers or codes (e.g., for each type of command and control message and / or data), a mapping of command and control message codes (e.g., for mapping command and control messages to DSCP / TC), and / or a period during which the configuration (e.g., session parameters) will remain valid.

[0103] Configurations that can be used to establish a second PDU session (e.g., session parameters) may include a task-specific DNN (e.g., related to the current task of the UAV or UAV-C). DNNs can be created dynamically (e.g., at a UTM or application server for each UAS group and / or UAV task), and PDU sessions can identify the same DNN for the same group or task. Configurations that can be used to establish a second PDU session (e.g., session parameters) may include S-NSSAI and SSC modes (e.g., for future task-related PDU sessions). Configurations that can be used to establish a second PDU session (e.g., session parameters) may include information (such as service type) that allows the UAV / UAV-C itself to determine the S-NSSAI or SSC mode.

[0104] Configurations that can be used to establish a second PDU session (e.g., session parameters) may include temporary UAV and / or UAV-C identifiers. These identifiers may be 3GPP-assigned identifiers, such as the General Public Subscription Identifier (GPSI) or identifiers assigned by the UAV application server. Configurations that can be used to establish a second PDU session (e.g., session parameters) may include identifiers or codes (e.g., for each type of command and control message and / or data). These identifiers or codes may be used by UAV and / or UAV-C (e.g., to match QoS rules using these IDs / codes as filters). Configurations that can be used to establish a second PDU session (e.g., session parameters) may include mappings of command and control message codes to DSCP / TCs. Configurations that can be used to establish a second PDU session (e.g., session parameters) may include the period during which the configuration remains valid.

[0105] The UAV and / or UAV-C can receive configurations (e.g., session parameters) that can be used to establish a second PDU session (e.g., via the control plane). The AMF can retrieve configurations (e.g., session parameters) for one or more PDU sessions from the UTM and pass them to the UAV, for example, in a NAS message.

[0106] If a first configuration (e.g., a previous configuration, such as previous session parameters) exists in the UAV and / or UAV-C, a second configuration (e.g., a configuration received after the first configuration) can override the previous configuration. If a time period during which the configuration is valid is specified, the UAV and / or UAV-C can start a timer (e.g., to monitor the validity of the configuration).

[0107] Figure 4 This illustrates an example of initiating / establishing two PDU sessions (e.g., for UAV communication). One or more of the illustrated actions can be performed.

[0108] The WTRU can initiate the establishment of a second PDU session or modify the initial PDU session (e.g., if instructed by UAV-C and / or UTM). The UAV-C can send connection commands, for example, via sidelink communication or via an application server (e.g., if the UAV and UAV-C are registered). Other UTM clients or operators can issue connection commands to the UAV and / or UAV-C (e.g., via some other connectivity) via the UTM. The UAV and / or UAV-C (e.g., applications within the UAV and / or UAV-C) can instruct 3GPP modems and / or modules to establish a second PDU session and / or modify an existing PDU session for mission-related communications (e.g., operational communications).

[0109] If the establishment of a second PDU session for mission-related communication (e.g., operational communication) is triggered, the UAV or UAV-C can derive the second PDU session parameters (e.g., DNN, S-NSSAI, SSC mode, etc.). The UAV or UAV-C can derive the second PDU session parameters (e.g., from configurations previously received from the UTM, UE route selection (URSP) rules, and / or pre-configured default parameters).

[0110] If the configuration received from the UTM (e.g., session parameters) exists and is valid, the UAV or UAV-C can use the received configuration (e.g., instead of URSP rules to derive PDU session parameters). If neither the configuration received from the UTM nor the URSP rules is available, the UAV or UAV-C can use pre-configured default parameters.

[0111] The PDU session establishment request message may include PDU session parameters. In the PDU session establishment request, the WTRU may include one or more of the following: an indication that the PDU session is used for UAV mission-related communications (e.g., operational communications); a Protocol Configuration Options (PCO) including information related to the UAV, UAV-C, and / or the current mission (e.g., temporary identifiers received from the UTM (e.g., previously received) and / or the role of the device); the PDU session ID for the initial PDU session; the 3GPP identity of the peer UAV or UAV-C (e.g., MSISDN, GPSI, etc.); a marker indicating a connection between the PDU session and another PDU session (e.g., used by the peer UAV or UAV-C); and / or one or more PDU session IDs of the peer UAV or UAV-C.

[0112] In the PDU session establishment request, the WTRU may include an indication that the PDU session is used for UAV task-related communication (e.g., operational communication).

[0113] In the PDU session establishment request, the WTRU may include a PCO, which includes information related to the UAV or UAV-C or the current task (e.g., a temporary identifier previously received by the UAV from the UTM and / or the role of the device such as the UAV or UAV-C).

[0114] In a PDU session establishment request, the WTRU may include the PDU session ID of the initial PDU session. If a second PDU session is established or a connection between the two PDU sessions is typically maintained (e.g., where the two PDU sessions are used for command and control communication, such as for availability and reliability purposes), including the PDU session ID of the initial PDU session can enable the network to automatically release the initial PDU session.

[0115] In the PDU session establishment request, the WTRU may include the 3GPP identity of the peer UAV or UAV-C (e.g., Mobile Station International User Directory Number (MSISDN), GPSI, etc.).

[0116] In a PDU session establishment request, the WTRU may include a tag indicating that the PDU session is connected to another PDU session used by a peer UAV or UAV-C.

[0117] In a PDU session establishment request, the WTRU may include one or more PDU session IDs of the peer UAV or UAV-C. These one or more PDU session IDs may be exchanged before the PDU session is established (e.g., using an initial PDU session connection, which is registered with and obtained via UTM by the peer WTRU).

[0118] Connecting UAV and UAV-C PDU sessions enables the network to perform PDU session management (e.g., compliant with UAS operations). Operator policies may consider paired PDU sessions (e.g., UAV and UAV-C) that can be actively used for command and control communications, for example, during an ongoing flight mission. The MNO may enable network-triggered release of one or more UAV PDU sessions if (e.g., only if) certain predefined conditions or triggers are met (e.g., UAV-C-triggered PDU session release coinciding with flight mission completion). The MNO may prevent or avoid network-triggered release of a PDU session paired with another PDU session used for command and control communications (e.g., to avoid security risks).

[0119] The connection of peering UAV and UAV-C PDU sessions enables the network to check and enforce consistency (e.g., end-to-end QoS processing of command and control traffic flows across UAV and UAV-C PDU sessions). The network may refuse PDU session establishment (e.g., when the required QoS of the authorized UAS service is inconsistent with the QoS requirements of the UAV or UAV-C PDU session establishing the connection, or if the network cannot guarantee the required end-to-end QoS (e.g., real-time command and control latency)). Such situations may occur when UAV and UAV-C are authorized via separate USS / UTMs providing different QoS requirements to the 5GS. The network may modify one or more PDU sessions to make the QoS requirements of PDU sessions across connections consistent (e.g., conforming to QoS information from the UTM, such as authorized UAS service QoS information from the UTM).

[0120] UAV-C and / or UAVs may request specific QoS processing (e.g., during PDU session modification procedures). The network may decide (e.g., based on operator policies and / or under UTM control) to avoid propagating similar QoS processing updates to connected UAV and / or UAV-C PDU sessions, to propagate QoS processing updates to connected PDU sessions in corresponding network-requested PDU session modifications (e.g., automatically), and / or to utilize a hybrid approach.

[0121] The network may decide (e.g., based on operator policy and / or under UTM control) to avoid propagating similar QoS processing updates to connected UAV and / or UAV-C PDU sessions. For example, such decisions may occur during active flight missions (e.g., to avoid risking ongoing command and control communications). The network may reject PDU session modification requests (e.g., for appropriate reasons).

[0122] The network may decide (e.g., based on operator policy and / or under UTM control) to propagate QoS processing updates to connected PDU sessions in a corresponding network-requested PDU session modification (e.g., to ensure consistent QoS processing across PDU sessions). The network may ensure synchronization of PDU session modification procedures across PDU sessions (e.g., completing PDU session modifications requested by UAV-C, which are associated with PDU session modification commands confirmed from UAV).

[0123] The network may decide (e.g., based on operator policies and / or under UTM control) to utilize a hybrid approach. QoS flows corresponding to real-time guidance commands can be set, and / or unauthorized modifications can be made for the lifetime of connected PDU sessions (e.g., any of the connected PDU sessions), such as until the flight mission is completed, as described above. Non-real-time QoS flow modifications can be propagated.

[0124] The SMF handling PDU session establishment may include UAV communication instructions and PCO information received when it calls the PCF service to obtain policy control information for the PDU session. The PCF can locate the UTM and can query the UTM (e.g., to attach QoS requirements). If there is no direct interface between the PCF and the UTM, the PCF can perform the query (e.g., via the NEF function). QoS requirements provided by the UTM can be task-specific and / or device-specific. If the task involves high-definition video streaming, the UTM can specify high UL data rate requirements for UAV and high DL data rate requirements for UAV-C. The PCF can provide the SMF with combined policy and / or QoS control information.

[0125] Figure 5 This shows the initiation / establishment of a PDU session. Figure 5 This illustrates the initiation / establishment of a PDU session that can be used for task-related communication. One or more of the illustrated actions can be performed.

[0126] The UAV can establish an initial PDU session. The UAV can use this initial PDU session to perform identification, authentication, and / or authorization, and / or (e.g., from the UTM) retrieve configurations for mission-related communications. A UTM client (e.g., UAV-C or another UAV operator) can send connection commands (e.g., via the UTM or UAV application server to the application software running in the UAV). The application software in the UAV can instruct 3GPP modules to establish a PDU session (e.g., for UAV communication). The UAV can check the stored authorization status. If the status indicates that the device is authorized to use the network for UAV communication, the UAV can proceed.

[0127] The UAV can retrieve necessary information (e.g., to prepare for PDU session establishment) from the stored configuration received from the UTM. Configuration information may include specific PDU session parameters (e.g., DNN, S-NSSAI, SSC mode, etc.) and / or parameters specific to the UAV device and task (e.g., temporary identifiers for the device or task). If no such received configuration is available, the UAV can use URSP rules or pre-configuration.

[0128] The UAV can initiate a PDU session establishment request using parameters obtained from the UTM. The UAV can indicate that the PDU session is for UAV communication. UAV device- or task-specific parameters can be included in the PCO and sent along with the PDU session establishment request. The SMF handling the PDU session establishment can invoke the PCF service to establish a policy associated with the PCF. The SMF can pass UAV communication instructions and UAV-specific parameters received in the PDU establishment request to the PCF.

[0129] The PCF can use the UAV identifier to locate the UTM and query the UTM for specific QoS requirements related to the device and / or task. If the PCF does not have a direct interface with the UTM, it can perform such queries via the NEF. The UTM can respond to the PCF using device- and / or task-specific QoS control information from the UAV. The PCF can provide the SMF with consolidated policy information (e.g., PCC rules) and can combine policy decisions (e.g., based on user information and / or requests from the UTM). The SMF can construct QoS rules and can (e.g., based on received policy information) send the QoS rules to the UAV in the PDU session acceptance message. The UAV can notify the UAV application software that a PDU session has been successfully established. The UAV application can register PDU session details (e.g., the IP address assigned to the PDU session, SSC mode, etc.) using the UTM and / or application server.

[0130] UTM can provide device- and task-specific QoS requirements to network functions (e.g., PCF). UTM can provide QoS requirements (e.g., for each command and control message and / or data type).

[0131] The UTM can identify each type of command and control message and / or data (e.g., using identifiers or codes) and can associate the corresponding QoS requirements with it. Flight control commands (e.g., as Command and Control-FC) can be identified, as can UAV status report messages (e.g., as Command and Control-SR). Several types of command and control messages can share the same codes (e.g., if their QoS requirements are similar). The UTM can provide corresponding IP DSCP / TCs (e.g., standard or proprietary codes) or other codes that distinguish traffic categories or priorities within IP packets (e.g., codes for each command and control message). The mapping between command and control codes and DSCP / TC codes can be provided to the UAV and / or UAV-C (e.g., as part of the configuration). The mapping received at the UAV or UAV-C can be passed to the application layer (e.g., so the application layer can use the mapping to derive the DSCP / TC and tag UL command and control packets accordingly).

[0132] PCF can use information provided by UTM (e.g., to form PCC rules for command and control messages). PCF can use IP tuples combined with DSCP / TCs that can correspond to various command and control message types as a service data flow filter, and can associate QoS policy control information with the filter.

[0133] (For example, when the SMF receives PCC rules for a PDU session and incorporates the PCC rules into a QoS flow), the SMF can use the same service data flow filter for packet filtering in QoS rules (e.g., for UL traffic by WTRU) and packet filtering in PDR (e.g., for DL ​​traffic by UPF).

[0134] Figure 6 An example of WTRU QoS rule provisioning is shown. The application layer may have already derived DSCP / TCs using a Command and Control Message Code - DSCP / TC mapping configuration and labeled packets (e.g., when a UAV or UAV-C needs to send Command and Control Message packets). The UAV or UAV-C can use received QoS rules with DSCP / TCs as part of a packet filter (e.g., to match packets and determine the QFI for the packet). While the application layer may label packets directly without DSCP / TCs, it can instruct a 3GPP module to use a received Command and Control Message Code - DSCP / TC mapping configuration to label packets, for example, associated with a QoS rule or before applying the QoS rule.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: Memory; and A processor configured to register with a network; Initiate a first Protocol Data Unit (PDU) session, the first PDU session being associated with the authentication and authorization of the WTRU, wherein the initiation of the first PDU session is triggered by a command received via sidelink communication; Receive the Unmanned Aerial Vehicle (UAV) ID for the second PDU session via the first PDU session; Based at least on the successful authentication and authorization, the second PDU session is initiated using the UAV ID; as well as Sending or receiving operation communications via the second PDU session.

2. The WTRU of claim 1, wherein the operational communication includes unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

3. The WTRU of claim 1, wherein the operational communication includes a first command and control message associated with a first quality of service requirement or a second command and control message associated with a second quality of service requirement.

4. The WTRU of claim 1, wherein the processor is further configured to modify the first PDU session based on initiating the second PDU session, wherein being configured to modify the first PDU session includes being configured to allow sending or receiving one or more operational communications via the first PDU session, and wherein the one or more operational communications include unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

5. The WTRU of claim 1, wherein being configured to initiate the second PDU session includes being configured to indicate a temporary ID associated with the WTRU.

6. The WTRU of claim 1, wherein the authentication and authorization are performed using at least one of: UAS Service Provider (USS) or UAS Traffic Management (UTM).

7. A method performed by a wireless transmit / receive unit (WTRU), comprising: Register on the network; Initiate a first Protocol Data Unit (PDU) session, the first PDU session being associated with the authentication and authorization of the WTRU, wherein the initiation of the first PDU session is triggered by a command received via sidelink communication; Receive the Unmanned Aerial Vehicle (UAV) ID for the second PDU session via the first PDU session; Based at least on the successful authentication and authorization, the second PDU session is initiated using the UAV ID; as well as Sending or receiving operation communications via the second PDU session.

8. The method of claim 7, wherein the operational communication includes unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

9. The method of claim 7, wherein the operational communication includes a first command and control message associated with a first quality of service requirement or a second command and control message associated with a second quality of service requirement.

10. The method of claim 7, further comprising modifying the first PDU session based on initiating the second PDU session, wherein modifying the first PDU session includes allowing the sending or receiving of one or more operational communications via the first PDU session, and wherein the one or more operational communications include unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

11. The method of claim 7, wherein initiating the second PDU session includes indicating a temporary ID associated with the WTRU.

12. The method of claim 7, wherein the authentication and authorization are performed using at least one of: UAS Service Provider (USS) or UAS Traffic Management (UTM).

Images