Protocol data unit (PDU) session establishment

Abstract

Systems, methods, and instrumentalities associated with cellular communication for unmanned aerial vehicles and associated devices are disclosed. The WTRU may initiate a plurality of PDU sessions. The WTRU may initiate a first protocol data unit (PDU) session. The WTRU may receive one or more session parameters for the second PDU session. One or more session parameters for the second PDU session may be received via the first PDU session. The WTRU may initiate the second PDU session using one or more session parameters (e.g., based on authentication and authorization success associated with the first PDU session). The WTRU may transmit or receive an operational communication via the second PDU session. The operational communication may include an unmanned aerial vehicle command and control message or an unmanned aerial vehicle payload message.

Description

[0001] This application is a divisional application of the invention patent application with application number 202080075581.9 filed on October 1, 2020 and invention name “Protocol Data Unit (PDU) Session Establishment”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0004] Unmanned aerial systems (UAS) or unmanned aerial vehicles (UAV) will use various communication methods to support their operations. For example, UAS / UAV can connect to cellular networks. The number of UAV operations has continued to grow in recent years, and the applications enabled by UAVs are expanding to a variety of industries. Today, UAS can rely on direct point-to-point communications (e.g., via unlicensed ISM bands), which can limit the range of operation. Point-to-point communications can be unreliable, unsafe, and / or have low data rates. Summary of the invention

[0005] Systems, methods, and tools associated with cellular communications for unmanned aerial vehicles and associated devices are disclosed. A WTRU may initiate multiple PDU sessions. A WTRU may register with a network (e.g., the WTRU may register with the network via a network entity or function (such as an access mobility function)). The WTRU may initiate a first protocol data unit (PDU) session. The first PDU session may be associated with authentication and / or authorization of the WTRU, for example, by a (e.g., third party) authentication and authorization server (e.g., UAS service provider, UAV traffic management function). The first PDU session may be restricted or initially restricted (e.g., authentication and / or authorization, non-operational communications, etc.). The WTRU may receive one or more session parameters for a second PDU session. The one or more session parameters for the second PDU session may be received via the first PDU session. The one or more session parameters may include a data network name, a single network slice selection assistance information, and / or a service and session continuity mode. The WTRU may initiate a second PDU session using the one or more session parameters (e.g., based on successful authentication and authorization). The WTRU may send or receive operational communications via the second PDU session. The operational communications may include unmanned aerial vehicle command and control (also referred to as C2 or C&C) messages or unmanned aerial vehicle payload messages. The WTRU may modify the first PDU session, for example, based on successful authentication and authorization. The modification may include allowing one or more operational communications to be sent or received via the first PDU session (e.g., where in an example, the first PDU session does not allow operational communications before initiating / establishing the second PDU session).

[0006] The terms unmanned aerial vehicle (UAV), UAV controller (UAV-C), drone, and / or WTRU may be used interchangeably herein. Although some examples may be described using the terms WTRU, UAV, UAV-C, or drone, the examples may apply to WTRU, UAV, UAV-C, and / or drone, as appropriate. In examples, an unmanned aerial system (UAS) may refer to a combination of UAVs and C-UAVs. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0008] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the communication system shown;

[0009] Figure 1C It is shown that according to one embodiment, Figure 1AA system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system;

[0010] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0011] Figure 2 is a system diagram illustrating an exemplary system architecture for supporting WTRUs that may be used in a 5G network according to an embodiment;

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

[0013] Figure 4 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 may be used for task-related communications is shown; and

[0015] Figure 6 An example of WTRU QoS rule deployment is shown. DETAILED DESCRIPTION

[0016] Figure 1A 1 is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (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, but 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, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0019] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the 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 a desired spatial direction.

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

[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, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 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 embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0023] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0024] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may 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 embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rates for Evolution (EDGE), GSM EDGE (GERAN), etc.

[0026] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As 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.

[0027] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the specification, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

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

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive 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, the transmit / receive element 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0034] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0035] The processor 118 of the 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) display 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, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

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

[0039] The WTRU 102 may include a full-duplex radio for which 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 via hardware (e.g., choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a full-duplex radio for which 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 1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

[0043] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being 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 a CN operator.

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

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

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

[0047] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may (eg, temporarily or permanently) use a wired communications interface with a communications network.

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

[0050] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a 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 away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, wherein the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

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

[0052] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0053] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be transmitted by transmitting STA. At the receiver of the receiving STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0054] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 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 for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0055] WLAN systems that can support 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. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may 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 sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.

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

[0057] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to one embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0058] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the 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 embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0059] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0060] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the evolved Node-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0061] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0062] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 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.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via the N2 interface in the RAN 113 and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the 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] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0067] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation 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. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0068] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. 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 in order to test other devices within the communication network. The one or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0069] 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 device may be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.

[0070] Systems, methods, and tools associated with cellular communications for unmanned aerial vehicles and associated devices are disclosed. A WTRU may initiate multiple PDU sessions. A WTRU may register with a network (e.g., the WTRU may register with the network via a network entity or function (such as an access mobility function)). The WTRU may initiate a first protocol data unit (PDU) session. The first PDU session may be associated with authentication and / or authorization of the WTRU, for example, by a (e.g., third party) authentication and authorization server (e.g., UAS service provider, UAV traffic management function). The first PDU session may be restricted or initially restricted (e.g., authentication and / or authorization, non-operational communications, etc.). The WTRU may receive one or more session parameters for a second PDU session. The one or more session parameters for the second PDU session may be received via the first PDU session. The one or more session parameters may include a data network name, a single network slice selection assistance information, and / or a service and session continuity mode. The WTRU may initiate a second PDU session using the one or more session parameters (e.g., based on successful authentication and authorization). The WTRU may send or receive operational communications via the second PDU session. The operational communications may include unmanned aerial vehicle command and control (also referred to as C2 or C&C) messages or unmanned aerial vehicle payload messages. The WTRU may modify the first PDU session, for example, based on successful authentication and authorization. The modification may include allowing one or more operational communications to be sent or received via the first PDU session (e.g., where in an example, the first PDU session does not allow operational communications before initiating / establishing the second PDU session).

[0071] The terms unmanned aerial vehicle (UAV), UAV controller (UAV-C), drone, and / or WTRU may be used interchangeably herein. Although some examples may be described using the terms WTRU, UAV, UAV-C, or drone, the examples may apply to WTRU, UAV, UAV-C, and / or drone, as appropriate. In examples, an unmanned aerial system (UAS) may refer to a combination of UAVs and C-UAVs.

[0072] The WTRU may receive configuration information for a specific task (e.g., from a UAS Traffic Management (UTM) node or function) and may use the configuration to select wireless communication parameters, such as packet data unit (PDU) session parameters. The term UAS Service Provider (USS) may be used interchangeably with UTM herein.

[0073] The WTRU and the 3GPP network may receive (e.g., from the UTM) a quality of service (QoS) requirement for a particular task and may use the QoS requirement to select appropriate QoS parameters for one or more PDU sessions (e.g., in a QoS configuration). The UTM may provide a command and control message - Differentiated Services Code Point / Traffic Class (DSCP / TC) mapping configuration. The "Command and Control Message - DSCP / TC" mapping configuration may be used by the network and / or the WTRU to be able to differentiate command and control messages for QoS treatment.

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

[0075] The WTRU may receive configuration information for a particular UAV task (e.g., site survey, package delivery, etc.) (e.g., from a UTM) and may use the configuration (e.g., for selecting PDU session parameters).

[0076] The WTRU and the 3GPP network may receive QoS requirements for specific tasks (e.g., from the UTM) and may combine these requirements (e.g., in a QoS configuration). The UTM may provide a "command and control message - DSCP / TC" mapping configuration (e.g., for the network and the WTRU to be able to distinguish command and control messages for QoS treatment).

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

[0078] The WTRU may be connected to a cellular network. The number of UAV operations has continued to grow in recent years, and the number and types of applications enabled by UAVs will expand to a variety of industries. Today, UAS may rely on direct point-to-point communications (e.g., via unlicensed ISM bands), which may limit the range of operation. Point-to-point communications may be unreliable, unsecure, and / or have low data rates. Advanced cellular technologies such as LTE and 5G may be utilized (e.g., to enable beyond line of sight (BVLOS) operations).

[0079] Using a cellular network for communication may provide capabilities beyond those provided by direct point-to-point communications. For example, as a result of using a cellular network UAV / WTRU may be able to operate over a larger operating range (e.g., as may be provided by and beyond mobile network coverage). The result of using a cellular network may be relatively high bandwidth. The result of using a cellular network may be achieving relatively low latency. The result of using a cellular network may be that the network may attempt to provide QoS guarantees for communication. The result of using a modern cellular network (e.g., a 5G network) may be improved performance of UAV applications. The result of using a cellular network may be advanced security mechanisms (e.g., to address security issues involving the management of UAV applications). Using a cellular network may allow for a larger operating range, high bandwidth, low latency, guaranteed QoS, advanced communication capabilities, improved performance of UAV applications, advanced security mechanisms, and the like.

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

[0081] In such Figure 2 In the illustrated architecture, a WTRU (e.g., UAV, UAV-C, and / or drone) may communicate (e.g., via a network user plane) with a UTM (e.g., for identification, authentication procedures, authorization procedures, command and control message exchanges, and / or command and control data exchanges). A 3GPP network function (e.g., SMF, PCF) may have a direct or indirect (e.g., via a NEF) control interface with the UTM.

[0082] A cellular network-connected WTRU may be involved in various types of cellular communications (e.g., to perform its mission). Cellular communications may be between a UAS and a UTM, may be non-payload communications (e.g., command and control), and / or cellular communications may be payload communications (e.g., real-time video or sensor data).

[0083] There may be communications between the UAS and the UTM. Communications between the UAS and the UTM may be enabled for identification, authorization, command and control, and / or law enforcement activities. User plane connections may be used between the WTRU and the UTM. Control plane communications may be used between the WTRU and the UTM.

[0084] Cellular communications may be non-payload communications (e.g., command and control). Command and control messages and data exchanges may be used for UAV mission and / or safety. In an example, command and control exchanges (e.g., position and / or flight data reports) may occur between a WTRU and a UTM and / or between WTRUs (e.g., between UAVs and / or UAV-Cs).

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

[0086] Command and control messages may have a small size. Command and control messages may be sent using a low data rate. Command and control message types may have different QoS requirements (e.g., latency, data loss rate, etc.). In an example, a steering command may require real-time, while a task update may tolerate some latency.

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

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

[0089] The UAS may set up a cellular connection for UAS communications. A user plane connection may be established in a cellular network (eg, to enable cellular communications for the UAS).

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

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

[0092] The WTRU and / or the network may establish a PDU session for a UAS, trigger the establishment of various PDU sessions, check dependencies (e.g., regarding authorization results and / or the existence of its controlling peer entity), etc. When a PDU session for a UAS is established, a network-triggered release of a PDU session used by the UAS in conjunction with another PDU session for command and control communications may 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.) may be selected for the PDU session.

[0094] The network may manage the interdependencies of PDU Sessions associated with a UAS in accordance with UAS operational requirements.

[0095] QoS requirements (e.g., for UAV communications) may be device and / or mission specific. UAV-C may have relatively high DL data rate requirements. UAV may have high UL data rate requirements. UAV tasks (e.g., may involve static image transmission) may have lower data rate requirements than different tasks (e.g., tasks involving HD video streaming). In an example, when the 3GPP network determines the policy control information, the 3GPP network may not have QoS requirements (e.g., UAV mission-specific data rate requirements). An entity with QoS requirements (e.g., UTM) may dynamically affect the policy control information made by the network (e.g., PCF). QoS provisioning for UAV communications may provide differentiated QoS treatment (e.g., for various command and control messages and / or data types). Command and control messages and / or data exchanged between UAV and UAV-C or between UAV and UTM may have a communication type (e.g., UAS-UTM, command and control and / or payload communication). Each type of command and / or data may have its own meaning for QoS requirements. Telemetry reports (eg, UAV position, status, etc.) may require low data rates and may be very sensitive to data loss. Flight control commands may require reliable real-time communications.

[0096] Filtering communication types can provide differentiated QoS treatment for these various communication types (e.g., so the network can use filters to configure QoS rules). In an example, the QoS rule filter can be based on address information (e.g., IP tuple) and / or application ID that UAV command and control messages may not have. The filter can reuse QoS rules based on 5G QoS mapping. In an example, the QoS rules may lack sufficient granularity to enable differentiation between command and control messages carrying different types of information and / or serving different purposes (e.g., telemetry versus flight control).

[0097] The network may guarantee QoS (e.g., for command and control communications) given the end-to-end communication path (e.g., across corresponding PDU sessions used by the UAV and / or UAV-C for command and control communications). It may be necessary to transmit real-time flight control commands (e.g., to avoid safety risks).

[0098] The network may enforce consistent QoS treatment of command and control traffic across PDU sessions (eg, used by a UAS for command and control communications).

[0099] A PDU session may be established (e.g., for UAV mission-related communications). A cellular-capable WTRU may, for example, establish a first PDU session with the network (e.g., for initial communications between the WTRU and the UTM). The WTRU may, for example, authenticate with the UTM and obtain general authorization from the UTM before or during the PDU session establishment.

[0100] The first PDU session may be referred to as a default PDU session, an initial PDU session, or an authentication and authorization (AA) PDU session. The initial PDU session may be established during or after (e.g., immediately following) a successful registration with the network. The establishment of the initial PDU session may be triggered manually or by a command (e.g., an application layer command, such as a command from the UAV-C via sidelink communications). If a sidelink is used, registration of the UAV and the UAV-C may be required since V2X SL communications may be supported for the WTRU 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 the UTM and / or obtain authorization from the UTM. The UAV or UAV-C may (e.g., if the authorization result is successful) initiate a second PDU session for UAV mission-related communication / operational communication (e.g., to send and / or receive command and control messages and / or payload data) and / or modify the initial PDU session for mission-related communication / operational communication (e.g., mission-related communication / operational communication may not be allowed in the initial PDU session, and the initial PDU session may be modified to allow mission-related communication / operational communication, 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, which is used for command and control communication in parallel with the second PDU session (e.g., for availability and reliability of command and control communication, such as based on policy) or for remote identification and tracking (e.g., to transmit location information to the USS / UTM). The UAV or UAV-C may receive (e.g., from a UTM or UAV application server) a configuration (e.g., session parameters). The UAV or UAV-C may use the configuration in establishing the second PDU session.

[0102] Configurations (e.g., session parameters) that may be used in establishing a second PDU session may include one or more of: a mission-specific data network name (DNN), single network slice selection assistance information (S-NSSAI), and / or session and service continuity (SSC) mode, service type, temporary UAV or UAV-C identifier, identifiers or codes (e.g., for each type of command and control messages 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 time period for which the configuration (e.g., session parameters) will remain valid.

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

[0104] Configurations (e.g., session parameters) that may be used in establishing the second PDU session may include temporary UAV and / or UAV-C identifiers. The identifier may be an identifier assigned by 3GPP, such as a General Public Subscription Identifier (GPSI) or an identifier assigned by a UAV application server. Configurations (e.g., session parameters) that may be used in establishing the second PDU session 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 the UAV and / or UAV-C (e.g., to match QoS rules that use these IDs / codes as filters). Configurations (e.g., session parameters) that may be used in establishing the second PDU session may include a mapping of command and control message codes to DSCP / TC. Configurations (e.g., session parameters) that may be used in establishing the second PDU session may include a time period for which the configuration remains valid.

[0105] The UAV and / or UAV-C may receive a configuration (e.g., session parameters) that may be used in establishing a second PDU session (e.g., via a control plane). The UAV and / or UAV-C may receive a configuration (e.g., session parameters) that may be used in establishing a second PDU session during registration or AA. The AMF may retrieve a configuration (e.g., session parameters) for one or more PDU sessions from the UTM and pass it to the UAV, e.g., in a NAS message.

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

[0107] Figure 4 is an example showing initiation / establishment of two PDU sessions (eg, for UAV communication). One or more of the illustrated actions may be performed.

[0108] The WTRU may initiate establishment of a second PDU session or modification of an initial PDU session (e.g., if instructed by the UAV-C and / or UTM). The UAV-C may send a connect command, 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 may issue a connect command to the UAV and / or UAV-C via the UTM (e.g., via some other connectivity). The UAV and / or UAV-C (e.g., an application in the UAV and / or UAV-C) may instruct the 3GPP modem and / or module to establish a second PDU session and / or modify an existing PDU session for mission-related communications (e.g., operational communications).

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

[0110] If the configuration (e.g., session parameters) received from the UTM exists and is valid, the UAV or UAV-C may use the received configuration (e.g., instead of URSP rules to derive PDU session parameters). For example, if neither the configuration received from the UTM nor the URSP rules are available, the UAV or UAV-C may 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 option (PCO) including information related to the UAV, UAV-C, and / or the current mission (e.g., a temporary identifier received (e.g., previously received) from the UTM and / or the role of the device), a PDU session ID of the initial PDU session, a 3GPP identity of the peer UAV or UAV-C (e.g., MSISDN, GPSI, etc.), a tag indicating that the PDU session is connected to 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 mission-related communications (e.g., operational communications).

[0113] In the PDU session establishment request, the WTRU may include a PCO that 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 the PDU session establishment request, the WTRU may include the PDU session ID of the initial PDU session. Including the PDU session ID of the initial PDU session may enable the network to automatically release the initial PDU session if a second PDU session is established or generally maintains a connection between two PDU sessions (e.g., where the two PDU sessions are used for command and control communications, such as for availability and reliability purposes).

[0115] In the PDU Session Establishment Request, the WTRU may include the 3GPP identity (eg, Mobile Station International Subscriber Directory Number (MSISDN), GPSI, etc.) of the peer UAV or UAV-C.

[0116] In the PDU Session Establishment Request, the WTRU may include a flag indicating that the PDU session is connected to another PDU session used by a peer UAV or UAV-C.

[0117] In the PDU session establishment request, the WTRU may include one or more PDU session IDs of the peer UAV or UAV-C. The 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 by the peer WTRU with the UTM and obtained via the UTM).

[0118] Connection of a UAV to a UAV-C PDU Session may enable the network to perform PDU session management (e.g., consistent with UAS operations). Operator policy may consider paired PDU Sessions (e.g., UAV and UAV-C) that may be actively used for command and control communications, such as in 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 that is paired with another PDU Session used for command and control communications (e.g., to avoid security risks).

[0119] Connectivity of peer UAV and UAV-C PDU sessions may enable the network to check and enforce consistency (e.g., with respect to end-to-end QoS treatment of command and control traffic flows across UAV and UAV-C PDU sessions). The network may reject PDU session establishment (e.g., where the required QoS of the authorized UAS service is inconsistent with the QoS requirements of the connected established UAV or UAV-C PDU session, or if the network cannot guarantee the end-to-end required QoS (e.g., real-time command and control latency)). Such situations may occur when UAVs and UAV-Cs are authorized via separate USS / UTMs that present different QoS requirements to the 5GS. The network may modify one or more PDU sessions to make the QoS requirements of the connected PDU sessions consistent (e.g., in accordance with QoS information from a UTM, such as authorized UAS service QoS information from a UTM).

[0120] The UAV-C and / or UAV may request specific QoS treatment (e.g., during a PDU session modification procedure). The network may decide (e.g., based on operator policy and / or under UTM control) to avoid propagating similar QoS treatment updates to connected UAVs and / or UAV-C PDU sessions, to propagate QoS treatment updates to connected PDU sessions (e.g., automatically) in response to a network-requested PDU session modification, 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 treatment updates to connected UAVs and / or UAV-C PDU sessions. For example, such a decision may occur during an active flight mission (e.g., to avoid risk to ongoing command and control communications). The network may deny the PDU session modification request (e.g., with an appropriate reason).

[0122] The network may decide (e.g., based on operator policy and / or under UTM control) to propagate QoS treatment updates to connected PDU sessions (e.g., automatically) in response to a network-requested PDU session modification (e.g., to ensure consistent QoS treatment across connected PDU sessions). The network may ensure synchronization of PDU session modification procedures across connected PDU sessions (e.g., to complete a PDU session modification requested by a UAV-C that is associated with a PDU session modification command acknowledged from a UAV).

[0123] The network may decide (e.g., based on operator policy and / or under UTM control) to utilize a hybrid approach. A QoS flow may be set corresponding to a real-time oriented command, and / or modifications may not be authorized for the lifetime of a connected PDU session (e.g., any of the connected PDU sessions), e.g., until the flight mission is completed, e.g., as described above. Non-real-time QoS flow modifications may be propagated.

[0124] The SMF that handles the PDU session establishment may include the UAV communication indication 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., for additional 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). The 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 a high UL data rate requirement for the UAV and a high DL data rate requirement for the UAV-C. The PCF can provide merged policy and / or QoS control information to the SMF.

[0125] Figure 5 The initiation / establishment of a PDU session is shown. Figure 5 Initiation / establishment of a PDU session that can be used for task-related communications is shown. One or more of the illustrated actions may be performed.

[0126] The UAV may establish an initial PDU session. The UAV may use the initial PDU session to perform identification, authentication, and / or authorization, and / or retrieve configuration for mission-related communications (e.g., from the UTM). A UTM client (e.g., UAV-C or other UAV operator) may send a connect command (e.g., sent by a UTM or UAV application server to an application software running in the UAV). The application software in the UAV may instruct the 3GPP module to establish a PDU session (e.g., for UAV communications). The UAV may check a stored authorization status. If the status indicates that the device is authorized to use the network for UAV communications, the UAV may continue.

[0127] The UAV may retrieve necessary information (e.g., to prepare for PDU session establishment) from a stored configuration received from the UTM. The 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 mission (e.g., temporary identifier for a device or mission). If there is no such received configuration, the UAV may use URSP rules or pre-configuration.

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

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

[0130] The UTM may provide device and task specific QoS requirements to a network function (eg, PCF). The UTM may provide QoS requirements (eg, for each command and control message and / or data type).

[0131] The UTM may identify each type of command and control message and / or data (e.g., using an identifier or code) and may associate a corresponding QoS requirement therewith. Flight control commands may be identified (e.g., as command and control-FC), and UAV status report messages may be identified (e.g., as command and control-SR). Several types of command and control messages may share the same code (e.g., if their QoS requirements are similar). The UTM may provide corresponding IP DSCP / TC (e.g., a standard or proprietary code) or other code that may distinguish traffic classes or priorities in IP packets (e.g., for each command and control message code). A mapping between command and control codes and DSCP / TC codes may be provided to the UAV and / or UAV-C (e.g., as part of a configuration). The mapping received at the UAV or UAV-C may be passed to the application layer (e.g., so that the application layer may use the mapping to derive the DSCP / TC and mark the UL command and control packets accordingly).

[0132] The PCF may use the information provided by the UTM (e.g., to form PCC rules for command and control messages). The PCF may use a combination of an IP tuple and DSCP / TC that may correspond to various command and control message types as a service data flow filter and may associate QoS policy control information with the filter.

[0133] (e.g., when the SMF receives PCC rules for a PDU session and binds the PCC rules to a QoS flow), the SMF may use the same service data flow filters for both the packet filters in the QoS rules (e.g., to be used by the WTRU for UL traffic) and the packet filters in the PDR (e.g., to be used by the UPF for DL ​​traffic).

[0134] Figure 6 An example of WTRU QoS rule provisioning is shown. The application layer may have derived DSCP / TC using a command and control message code-DSCP / TC mapping configuration and may have marked packets (e.g., when a UAV or UAV-C needs to send a command and control message packet). The UAV or UAV-C may use a received QoS rule that has DSCP / TC as part of a packet filter (e.g., to match packets and determine a QFI for the packet). Although the application layer may not mark packets directly with DSCP / TC, the command and control message code or identifier may be indicated to a 3GPP module, which may use the received command and control message code-DSCP / TC mapping configuration to mark packets, e.g., in association with a QoS rule or before applying a QoS rule.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: Memory; and A processor, the processor being configured to: Register to the network; initiating a first protocol data unit (PDU) session associated with authentication and authorization of the WTRU, wherein the initiation of the first PDU session is triggered by a command received via a sidelink communication; receiving, via the first PDU session, session parameters for a second PDU session; Initiating the second PDU session using the session parameters based at least on the authentication and authorization success; as well as Operational communications are sent or received via the second PDU session.

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

3. The WTRU of claim 1 , wherein the operational communication comprises 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 one or more operational communications to be sent or received 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 the session parameters include: Data network name, single network slice selection assistance information or service and session continuity mode.

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

7. The WTRU of claim 1 , wherein the session parameters are derived from one or more of: a previously received configuration, a UE routing rule, or a pre-configured parameter.

8. The WTRU of claim 1, wherein the authentication and authorization are performed using at least one of: a UAS service provider (USS) or a UAS traffic management (UTM).

9. A method comprising: Register to the network; initiating a first protocol data unit (PDU) session associated with authentication and authorization of the WTRU, wherein the initiation of the first PDU session is triggered by a command received via a sidelink communication; receiving, via the first PDU session, session parameters for a second PDU session; Initiating the second PDU session using the session parameters based at least on the authentication and authorization success; as well as Operational communications are sent or received via the second PDU session.

10. The method of claim 9, wherein the operational communications include unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

11. The method of claim 9, wherein the operational communication comprises 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.

12. The method of claim 11, further comprising modifying the first PDU session based on initiating the second PDU session, wherein modifying the first PDU session comprises allowing one or more operational communications to be sent or received via the first PDU session, and wherein the one or more operational communications comprise unmanned aerial vehicle command and control messages or unmanned aerial vehicle payload messages.

13. The method of claim 9, wherein the session parameters include: Data network name, single network slice selection assistance information or service and session continuity mode.

14. The method of claim 9, wherein initiating the second PDU session comprises indicating a temporary ID associated with the WTRU.

15. The method of claim 9, wherein the session parameters are derived from one or more of: a previously received configuration, a UE routing rule, or a pre-configured parameter.

16. The method of claim 9, wherein the authentication and authorization are performed using at least one of: a UAS service provider (USS) or a UAS traffic management (UTM).

Images